統制・評価の層は、何を担う？
エージェントは、誤った情報を参照したり、期待と違うツールを選んだりする可能性があります。統制・評価の層では、その影響を抑えるために、許可する操作、確認する条件、停止する条件を設計します。安全性をプロンプトの注意書きだけに任せません。
人の承認も、何となく「はい」と答えるだけでは不十分です。担当者が、対象・金額・送信先・版などを確認し、承認した内容が実行時に変わっていないことを検査できる仕組みにします。
設計する項目を、具体的に。
| 項目 | 考えること | 説明用の例 |
|---|---|---|
| 実行前 | 権限・入力・対象の確認 | 承認者がその案件を扱えるか |
| 実行中 | 時間・回数・費用の制限 | 想定外の再試行を停止する |
| 実行後 | 結果と成果物の検証 | 金額・台帳の版・保存内容を照合する |
| 承認時 | 人が確認すべき条件 | 下書きの版と承認結果を対応づける |
| 障害時 | 停止と復旧 | 影響範囲と実行済み処理を確認する |
実務では、ここを考える。
検査を、モデルの自己申告から切り離す
計算、形式、権限、台帳の版などは、ルールやコードで検査できます。文章の妥当性は別の評価手段や人の確認を組み合わせます。検査を増やせばすべての誤りがなくなる、という意味ではありません。
不明なときは、勝手に通さない
単価が不明、承認記録がない、送信済みか分からない、といった状態は成功と扱いません。担当者に状況と未確認事項を返し、必要な操作だけを再開できるようにします。
止めた後の、戻り方まで決める
停止ボタンだけでなく、処理中のジョブ、すでに変更したデータ、外部送信の有無を調べる手順が必要です。取り消せない操作は事前の確認を強め、影響に応じて段階的に導入します。
つまずきやすい点
検証用データで動いたことを、本番環境の安全性や顧客への導入効果と同一視しません。権限、実データ、障害条件、運用担当者の対応まで確認し、公開する検証結果には実施範囲と限界を添えます。
見積下書きの例で見る。
サービスAを2件、見積もる仕事を例にします。以下は仕組みを説明するための架空の条件・金額で、ROの料金表やAPIの実行結果ではありません。
VALIDATE小計・税額・合計、商品台帳の版を検査する。
APPROVE担当者が下書き v1を確認する。変更後は再確認する。
RECOVER送信結果が不明なら、再送する前に送信履歴を確認する。
導入前に確かめたいこと。
- 権限と重要条件を実装側で検査している
- 承認する担当者・対象・版が明確になっている
- 失敗・未確認・成功を区別して報告できる
- 停止後の影響確認と復旧の担当・手順がある
5つの役割は、単独で完結せず、ひとつの業務の中で組み合わさります。
実装例と、説明用の整理を分けて見る。
RO_APIの紹介では、見積下書きの生成・検査・承認など、ローカルデモで確認した範囲を示しています。実装状況は、各担当業務の紹介をご覧ください。
RO_APIの実装・検証範囲へ