AIエージェントを二体、五体、十体と増やせば、仕事も比例して進む。そう見えることがあります。しかし、各エージェントへ人が毎回指示を出し、すべての結果を読み、作業の重複や衝突を仲裁しているなら、増えたのは自律性ではなく管理負担です。
見るべき数字はエージェント数ではありません。人間の確認回数、差し戻し回数、例外の滞留時間、取り消せない操作の件数です。
複数エージェントの組織図を作る前に、各作業の権限、使ってよい情報、止める条件、実行証跡を決めます。人の役割をいきなり外すのではなく、日常的な指示係から、例外と高影響操作を判断する役へ段階的に移します。
最初に測るのは、AIの台数ではなく人の確認回数
エージェント導入前後で、次の数字を同じ一週間ずつ記録します。
人が新しく指示した回数:
人が内容を確認した回数:
人が差し戻した回数:
AI同士の重複作業:
判断待ちで止まった時間:
実行後に取り消した回数:AIが作った下書きの件数が増えても、人の確認がそれ以上に増えたなら、処理量の増加を生産性向上とは呼べません。確認の目的も分けます。
- 品質確認: 誤りや不足を直す
- 権限確認: その操作を実行してよいか決める
- 例外判断: 既存ルールで扱えない事案を決める
- 復旧判断: 失敗後に再実行、差し戻し、停止を選ぶ
この区別がないと、低リスクな下書き確認と、外部送信や削除の承認が同じ受信箱へ流れ込みます。
権限を四段階に分け、作業ごとに固定する
次の四段階は、Optiensが運用を整理するための実務テンプレートです。すべての業務へ同じ権限を与えるものではありません。
L0 提案: 候補を出す。保存先や外部状態を変えない。
L1 内部下書き: 社内の下書き領域へ保存する。公開・送信しない。
L2 可逆実行: 取り消し手段と証跡がある内部操作だけ実行する。
L3 高影響実行: 外部送信、公開、削除、決済、権限変更など。人が承認する。例えば記事制作なら、構成案はL0、原稿ファイルの作成はL1、公開前プレビューの更新は条件付きでL2、外部公開はL3です。問い合わせ対応なら、分類はL0、返信案の作成はL1、社内担当者への割り当ては可逆性を確認してL2、顧客への送信はL3に置けます。
OWASPは、AIに必要以上の機能、権限、自律性を持たせる「Excessive Agency」を主要リスクとして挙げ、利用できる機能と権限を必要最小限にし、高影響操作では人の承認を使うことを対策に含めています。便利そうだから広い権限を渡すのではなく、作業単位で一段ずつ決めます。
文脈の量より、鮮度と出所を管理する
エージェントが誤る理由は、能力不足だけではありません。参照した料金表が古い、会議で決まった例外が記録されていない、別部署の変更を知らない。こうした文脈の欠落や陳腐化でも判断は崩れます。
各作業には、最低限次の入力条件を持たせます。
参照元:
最終更新日時:
対象範囲:
正本の所有者:
有効期限:
矛盾した場合の優先順位:
不足時の停止条件:「情報が多いほど賢くなる」とは限りません。古い資料と新しい資料が混ざれば、判断理由を追えなくなります。常設ルールは正本へ、当日の依頼や一時的な例外は作業状態へ分けます。有効期限を過ぎた情報しかない場合は推測で補わず、例外キューへ戻します。
人への依頼は、例外キュー一つに集める
エージェントごとに人へ質問させると、通知が分散し、同じ確認が重複します。人が見る窓口を一つにし、AI側で次の四種類へ分類します。
BLOCKED: 必要な情報・権限・外部サービスがない
RISKY: 外部送信、削除、決済など影響が大きい
CONFLICT: ルール、依頼、データが矛盾している
UNCERTAIN: 根拠不足で確信度が低い各項目には、何をしようとしたか、現在どこまで終わったか、判断してほしい一点、放置した場合の影響、推奨案、元に戻す方法を付けます。長い経過報告ではなく、人が決めるべき差分だけを渡します。
OpenAIのエージェント構築ガイドでも、失敗回数が閾値を超えた場合や、高リスクで不可逆な操作では人へ制御を戻す考え方が示されています。人をすべての工程から外すのではなく、戻す条件を先に決める方が運用できます。
監視役には「見る権限」だけを渡す
複数エージェントを使うと、同じ調査を二重に行う、互いの出力を待つ、別々の前提で作業を進める、といった調整コストが生まれます。Anthropicの複数エージェントに関する公式記事でも、並列化に向く仕事がある一方、調整の複雑さや不要なサブエージェント生成が課題として挙げられています。
そこで、実行担当とは別に観察役を置く方法があります。ただし、観察役へ修正・削除・公開権限を渡すと、監視と実行の責任が混ざります。
観察役の出力は、次に限定します。
- 重複している作業ID
- 矛盾している前提
- 長時間更新されていない作業
- 必要な権限や情報の不足
- 予定外に増えた費用・処理回数
- 人へ戻すべき例外候補
実際の変更は、担当エージェントか人が行います。監視役は問題を見つけても、自分で権限を広げません。
一体から始め、権限を昇格・降格する
OpenAIの公式ガイドは、まず一つのエージェントで能力を最大化し、必要になった場合に複数エージェントへ発展させる段階的な方法を案内しています。複数化は開始条件ではなく、単一構成で指示やツール選択が複雑になったときの選択肢です。
導入は次の順で進めます。
- 一つの作業をL0またはL1で動かす。
- 成功、差し戻し、例外、取り消しを記録する。
- 同じ条件で安定した作業だけ、L2を検討する。
- 並列化でき、共有文脈への依存が低い作業だけ分ける。
- 重複や衝突が実際に発生したら、観察役を追加する。
- 重大な誤り、証跡欠落、文脈期限切れが起きたら一段降格する。
昇格はモデルへの信頼感ではなく、対象業務の証拠で決めます。別のモデルへ変えた、入力資料が変わった、ツールの権限が変わった場合は、以前の合格をそのまま引き継ぎません。
14日間で確認する最小運用
最初の二週間は、組織全体を作りません。一業務だけで比較します。
1〜3日目: L0/L1で実行し、確認理由と例外を記録
4〜7日目: 文脈の正本、期限、停止条件を修正
8〜10日目: 可逆な一操作だけL2で試す
11〜12日目: 例外キューを一つに集約
13〜14日目: 継続、昇格、降格、停止を決定判定時は、処理件数だけでなく、人の確認回数が減ったか、誤りを戻せたか、例外の理由を説明できるかを見ます。NIST AI RMFも、AIリスク管理を一度きりの審査ではなく、役割と責任を定めて継続的に測定・管理する反復プロセスとして整理しています。
AIエージェントの運用で目指すのは、人が何も見ない状態ではありません。日常的な指示と確認を減らし、人にしか決められない例外を、根拠と復旧手段付きで判断できる状態です。
Optiensの見方
具体的な構築・改善まで進めたい場合は、案件相談フォームから、対象業務、現在の流れ、必要な成果物をお知らせください。含む・含まない範囲、利用アカウント、責任分界、検収方法を確認してから個別にお見積もりします。