目的・指示の層は、何を担う？
目的・指示の層は、エージェントに任せる仕事の入口です。「問い合わせ対応を楽にしたい」という要望を、そのまま操作の許可にしてはいけません。対象の問い合わせ、参照してよい情報、返す成果物、担当者へ引き継ぐ条件まで具体化します。
ここで決めるのは成果と制約です。すべての手順を細かく固定する必要はありませんが、完了条件と禁止事項は、後から検証できる形で残します。
設計する項目を、具体的に。
| 項目 | 考えること | 説明用の例 |
|---|---|---|
| 目的 | 何を、誰のために達成するか | 見積の確認に必要な下書きを作る |
| 入力 | 必須項目と参照できる情報 | 商品ID、数量、利用可能な商品台帳 |
| 完了条件 | 成果物を確認できる条件 | 金額・根拠・台帳の版がそろう |
| 禁止事項 | 任せない操作と判断 | 未承認の送信、勝手な値引き |
| 停止条件 | 追加確認へ戻す条件 | 商品が見つからない、数量が不明 |
実務では、ここを考える。
依頼と権限は別にする
「見積を作って」と言われたことが、そのままメール送信の許可になるわけではありません。作成・保存・承認・送信を別の操作として扱い、利用者ごとの権限を実装側で確認します。
完了を、成果物で定義する
「完了しました」という文章だけを成功条件にしません。下書きが保存されていること、必要な項目があること、確認可能な参照先があることなど、観察できる結果を決めます。
文書内の命令を、そのまま採用しない
参照したメールやWebページの内容は、業務上の情報です。その中に書かれた操作指示を、利用者からの指示やシステムの権限より優先しない設計が必要です。
つまずきやすい点
「売上を最大化する」のような広すぎる目的だけを渡すと、何を犠牲にしてよいかが決まっていません。値引き、顧客情報の利用、連絡先への送信などの境界を、目的とは別に定義します。
見積下書きの例で見る。
サービスAを2件、見積もる仕事を例にします。以下は仕組みを説明するための架空の条件・金額で、ROの料金表やAPIの実行結果ではありません。
REQUESTサービスAを2件、見積もりたい。
DELIVERABLE商品台帳に基づく見積下書きと、その根拠。
BOUNDARY外部送信は行わず、担当者の確認で止める。
導入前に確かめたいこと。
- 成果物と完了条件を担当者が説明できる
- 必須入力が不足したときの確認先がある
- 参照情報と操作権限が分かれている
- 禁止事項をプロンプト以外の実装でも制限している
次は、その目的に向かって「どの行動を選ぶか」を見ます。
実装例と、説明用の整理を分けて見る。
RO_APIの紹介では、見積下書きの生成・検査・承認など、ローカルデモで確認した範囲を示しています。実装状況は、各担当業務の紹介をご覧ください。
RO_APIの実装・検証範囲へ