- 公開日
複数のAIエージェントが関わる仕事では、案を作る担当と、その案を採用して次へ進める担当を分けます。ただし、取りまとめ役を「最終決定者」と呼ぶだけで、契約の承認や外部送信の権限を与えたことにはなりません。何について決められるか、どの条件では人へ戻すかを、受け渡す情報と実行経路の両方で明らかにします。
例えば、見積の下書きに使う価格資料を選ぶ判断と、その見積条件で顧客へ提案してよいかの判断は異なります。前者を一定の規則に沿ってAIへ任せても、後者まで自動的に委任しません。複数のAIが一致したことも、権限のない判断を正当化する根拠にはなりません。
「何の最終決定か」を先に限定する
決定権という言葉には、作業順序を選ぶ、候補を絞る、計算の結果を採用する、文書を確定する、外部へ約束するなど、異なる行為が含まれます。一つの役割名へまとめると、内部の取りまとめが対外的な承認へ滑りやすくなります。
そこで、判断の対象を具体的な動詞で書きます。「調査結果を統合し、指定条件に合う資料を下書きへ採用する」「条件が一致しなければ差し戻す」なら、内部作業の判断範囲が分かります。「契約を承認する」「見積を顧客へ送信する」は、その権限を持つ人や別の許可済み工程へ割り当てます。
NIST AI RMF 1.0のCoreは、GOVERN 3.2で人とAIの組み合わせや監督における役割と責任を定めて区別することを、GOVERN 2.3でAIリスクに関する判断の責任を組織の経営層が負うことを挙げています。担当をAIへ分割しても、人の側の責任や権限を消す理由にはなりません。
すべてを人へ戻す必要もありません。対象資料と採用基準が明確で、やり直せる下書きの選択なら、定めた範囲で取りまとめ役に判断させられます。重要なのは、自動で進められる条件を事前に定義し、不明な条件を多数決や強い言い切りで埋めないことです。
見積作成の役割を、権限と一緒に分ける
架空の見積作成業務を考えます。営業担当者が、商品Pを十個販売する見積案を準備します。承認された価格資料には、税込単価千二百円、送料ゼロ、割引なし、通貨JPYと記載されているとします。顧客名など実際の情報は使わず、外部送信も行いません。
調査担当エージェントは、価格資料の版と適用条件を確認して必要な情報を抜き出します。計算担当エージェントは、その条件を使って金額案を作ります。承認補助エージェントは、不足する条件や承認者へ示す事項を整理します。取りまとめ役は、各結果が同じ案件と資料に対応するかを確かめ、下書きへ採用するか差し戻すかを判断します。
| 役割 | 決めてよいこと | 決めてはいけないこと |
|---|---|---|
| 調査担当 | 指定範囲の資料から根拠箇所を提示する | 不明な送料や価格を作る |
| 計算担当 | 確認済みの入力から合計案を算出する | 条件を変える値引きを独断で追加する |
| 承認補助 | 必要な確認事項と判断材料を整理する | 承認者の代わりに契約条件を承認する |
| 取りまとめ役 | 規則に合う結果を下書きへ採用し、不一致を差し戻す | 未確認条件を確定扱いにする、送信許可を作る |
| 権限を持つ人 | 組織の規程に沿って見積条件と対外行為を判断する | 自分にない権限をAIの合意で補う |
この表は架空業務の分担例です。実際の組織に同じ役職や承認手順があると仮定せず、誰がどの内容を決められるかを確認して置き換えます。計算担当という名前も、計算が正しい保証にはならないため、式と元の値を照合できる形で返します。
受け渡しには結論だけでなく条件を残す
調査担当が「単価千二百円」とだけ渡すと、税込か税別か、いつ適用される価格か、どの商品かが消えます。取りまとめ役は、その値が別案件や古い資料のものか判断できません。短くまとめる場合でも、判断を変える条件と根拠を残します。
この例なら、案件識別子、商品P、数量十個、単価千二百円、税込、送料ゼロ、割引なし、通貨JPY、価格資料の版と該当箇所を一緒に渡します。未確認の項目があるなら、空欄をゼロへ変えず未確認と記します。送り手が「確認済み」と書いた場合も、受け手は必要な箇所を根拠へたどれるようにします。
計算担当は「千二百円×十個＝一万二千円。追加費用なしという提示条件に基づく」と返します。承認補助は、「合計案は一万二千円だが、下書きの採用と顧客への提示承認は別」と区別します。ここにある数値は仮定に基づく再計算であり、実際の価格や発行済みの見積ではありません。
取りまとめ役が返す記録には、採用した案、その根拠、保留した条件、次に渡す相手と作業を含めます。会話文の最後に「完了」とあるかではなく、何が完了したかを残すためです。内部の下書き完成を、顧客送信まで完了した状態へ言い換えないようにします。
案が競合したら、投票の前に前提を合わせる
調査担当Aは単価千二百円、調査担当Bは千三百円と報告したとします。二つの案があるから平均の千二百五十円を採用する、あるいはより自信のある担当を信じる、という裁定では根拠が失われます。まず商品、期間、契約条件、資料の版が一致しているかを調べます。
例えばAが旧価格表、Bが現在適用される価格表を使っており、正式な改訂通知と適用日からBの資料が今回の案件へ適用されると確認できたなら、取りまとめ役は定めた規則に従ってBを採用し、計算を差し戻せます。単にファイルの更新日時が新しいというだけでは、適用される根拠にはしません。
二つとも有効に見え、対象顧客の契約によって価格が変わるのに、その契約が未確認なら、取りまとめ役は選べません。適用条件を確認できる人へ戻します。採用を保留しつつ、両案とその根拠、違いが生じる条件を並べれば、判断者が必要な情報を探し直す負担を減らせます。
また、複数のエージェントが同じ誤った元資料を使えば、全員が一致しても正しいとは限りません。多数決を使う場面があっても、資料の正しさや権限の有無の代わりにはしません。違いを調べる担当と、結果を採用する基準を明らかにしておく方が、どこで判断が止まったかを追えます。
正常、拒否、保留の受け渡しを定める
受け手が判断しやすいように、結果の状態を区別します。「採用可能」は、当該作業の必要条件が確認できた状態です。「要修正」は、資料があり、形式や計算などを直せば次へ進める状態です。「確認待ち」は、重要な条件や権限を確認できない状態として分けます。これらを契約の承認状態と共用しないようにします。
| 受け取った結果 | 取りまとめ役の判断 | 次の受け渡し |
|---|---|---|
| 同一資料の条件から合計が一万二千円と確認できる | 下書き用の計算結果を採用 | 条件付きの見積案を承認者へ渡す |
| 数量十個なのに合計が異なる | 計算の不一致として差し戻す | 元の値と式を添えて再計算を依頼する |
| 送料が資料に記載されていない | 総額の確定を保留 | 送料条件を確認する担当者へ照会事項を渡す |
| 承認補助が契約承認済みと報告するが正式記録がない | 承認扱いを拒否 | 権限を持つ承認者の確認へ戻す |
| 案件識別子や資料の版が一致しない | 別条件の結果として採用しない | 対象を揃えて作業をやり直す |
| 必要な担当の返答が届かない | 判断材料不足として保留 | 未完了工程と再開条件を示す |
送料の記載がないことは、送料が未決定だという意味でも、無料という意味でもありません。実際の条件を確認できていない状態です。この区別を引き継ぎで落とすと、計算担当がゼロを入れ、取りまとめ役が確定値として採用する連鎖が起こり得ます。
権限不足の担当が強い表現で結果を返しても、受け手の権限は増えません。誰が作成したかだけでなく、何の判断をする権限があるかを確認し、認可は会話の自由文から切り離します。担当者名に「承認」と含まれていることを、承認者の資格や権限の証拠にしないことも必要です。
人へ戻すときは、判断する点を一つに絞る
人へ戻す条件は、費用や対象が許可範囲を超える、重要な適用条件が不明、資料の競合を解消できない、法的・契約上の判断が必要、権限を確認できない、といった形で定めます。単なる表記の修正まで毎回人へ戻す必要はありませんが、取りまとめ役の判断範囲を超える条件は自動採用せず、人へ戻します。
この例で送料が未確認なら、「送料込みの見積総額を確定するため、商品P十個の配送条件を確認してください。商品代の計算は一万二千円まで確認済みです」と渡します。どの資料を調べたか、何が分からないか、回答まで止める操作は何かを添えます。単に「確認してください」では、同じ調査をやり直すことになります。
人からの返答も、誰の判断かと対象を結び付けます。別案件についての「それでよい」を流用したり、担当者が計算式を確認しただけで顧客への送信許可まで得たとしたりしません。確認対象の版が変われば、返答が新しい内容も含むかを再評価します。
AutoGenの公式ガイドは、人からのフィードバックを実行中に受ける方式と、実行を止めて次の実行への入力として受ける方式を説明しています。同じ資料では、実行中に入力を待つ方式はチームの処理を止め、その間の状態を保存・再開できないため、ボタンでの承認のような短いやり取りに向くとされています。長い確認待ちを扱うなら、実行を終えて状態を保存し、返答が届いてから再開する後者の方式が選択肢になります。特定の仕組みを使うこと自体が、適切な承認者を選んだ証拠にはなりません。
返答がないとき、合意するまで回し続けない
エージェント同士が互いに差し戻し、同じ資料を読み直すだけなら、処理を続けても判断材料は増えません。完了条件に加え、時間、反復、費用などの上限と、進展がないときの停止条件を定めます。上限の値は業務に合わせて決め、記事の仮定値を一律の標準にしません。
AutoGenの終了条件の資料には、メッセージ数や経過時間などに基づく終了条件が用意されています。ただし、終了条件に達したことは、見積が正しいことや承認されたことを示しません。制御上の終了と、業務上の完成を分けて記録します。
停止時には、採用済みの部分、保留事項、競合した案、最後に確認した資料の版を保存します。再開したら、以前の資料や権限がまだ有効かを確認し、完了済みの作業を無条件に繰り返しません。外部送信の結果が不明なら、送信状態を確認するまで再送しないなど、副作用のある工程は別に扱います。
承認者が不在のときも、AIが代わりに最終承認する規則を後付けしません。組織に代理承認の手順があるなら、その条件と権限を確認します。なければ、下書きを保持したまま保留し、締切への影響を担当者へ伝える設計にします。急ぎという事情だけで決定権は生まれません。
決定と実行を、システム側でも分離する
取りまとめ役が見積案を完成させても、外部送信ツールへ自由に進めない構成にします。送信には、権限を持つ人の承認、承認した版、宛先、送る内容が一致することを、実行側で確認します。AIの「承認を得た」という要約だけを使わないようにします。
各エージェントへ渡す道具も担当範囲に合わせます。計算担当に顧客への送信機能がなくても計算はできます。調査担当が価格資料を読む権限を持つことと、契約管理システムを書き換える権限を持つことは別です。担当が増えた分だけ全員へ同じ強い権限を配る設計は避けます。
この分離には、受け渡し形式や状態記録を保つ負担があります。小さな作業で一つのAIと人の確認だけで足りるなら、無理に複数化する必要はありません。分業する理由が、観点の違い、作業量、独立した確認など、実際の業務に対応しているかを見直します。
導入前は、採用した案と止めた案を追う
確認には、実顧客へ届かない環境と架空見積を使います。正常な資料、計算不一致、送料未確認、旧版と現行版の競合、権限のない承認、担当の無応答を用意し、どの役割が何を採用・拒否・保留するかを事前に決めます。この記事では実際のエージェントを動かしていません。
見るのは最終回答だけではありません。調査担当が残した条件が計算担当へ届いたか、計算根拠が取りまとめ役へ残ったか、人への質問から重要な未確認事項が消えていないかを記録で確認します。判定が合っていても、下流の送信が先に進んでいれば制御は不合格です。
結果が一致しなければ、能力不足という一言で片付けず、受け渡しの欠落、規則の曖昧さ、主体の誤認、停止条件の不足を分けて直します。モデルや担当構成を変えたときも、正常な提案が採用され、範囲外の決定が止まることを再確認します。
最終決定権を明確にするとは、一番上に強い名前のエージェントを置くことではありません。内部で自動的に選べる範囲を定め、それを超える判断は、必要な根拠とともに権限を持つ人へ渡すことです。提案、裁定、承認、実行の境界が記録と仕組みに残っていれば、複数の担当がいても判断の行方を追えます。
エージェント間の引き継ぎで抜けた条件を原資料との差分で確かめる方法は「エージェント間の引き継ぎで消えた条件を、原資料と差分で確かめる」、受け渡されたAI出力を命令として実行させない設計は「マルチエージェントの受け渡しで、AI出力を命令として実行させない設計」で解説しています。
マルチエージェントにするかどうかと、役割・受け渡しの設計は「マルチエージェントの役割・受け渡し・責任分界を設計する」で解説しています。
