AIエージェント協働の実務SOP
このページは、本書全体で共通に使う実務SOPです。 目的は、AIとの会話を増やすことではなく、依頼、承認、実行、検証、証拠、責任分界を一本の運用として揃えることです。 2026年7月21日時点で、主要なAIプラットフォームは、構造化出力、ツール利用、評価、外部連携の機能を継続更新しています。本SOPは、製品差分より先に守るべき共通原則を定義します。
この章の使い方
誰向け
- AIを日常業務へ入れたい現場担当者
- チーム標準を作りたいPMや運用責任者
- ツール利用や自動化の境界を決めたいエンジニア
- 承認と説明責任を持つマネージャー
この章でできるようになること
- AI依頼を Request Contract として定義できる
- 自律度、承認ゲート、停止条件を業務に合わせて選べる
- 外部入力を命令として扱わない trust boundary を明文化できる
- 証拠、ログ最小化、インシデント報告の基準を統一できる
最短ルート
- 自律度レベル表を確認する
- Request Contract の6項目を自分の業務に当てはめる
- 承認ゲート、停止条件、証拠保存の3点だけ先に導入する
深掘りルート
- 自律度、承認、停止条件、trust boundary を順に読む
- 検証、証拠、ログ最小化、責任分界まで設計する
- インシデント報告の雛形を自チーム版へ置き換える
1. このSOPが対象にする仕事
対象は、文章生成だけではありません。 次のような、成果物に影響する仕事を含みます。
- 要件整理
- 調査メモ作成
- 設計案作成
- コード変更案作成
- テスト観点整理
- 監査用説明文の下書き
- 社内FAQや手順書の改稿
一方で、本番更新、契約判断、法的解釈、個人情報処理の最終判断は、AIに委譲しません。
2. 自律度レベル
| レベル | 使いどころ | AIに許可すること | 人が必ず行うこと |
|---|---|---|---|
| Level 0 | 初回検討 | 観点出し、草案、比較案 | 採否判断 |
| Level 1 | 差分案作成 | 文章、設計、コードの変更案生成 | 差分採用と反映 |
| Level 2 | 実行前レビュー必須 | 計画、コマンド案、ツール利用案 | Go/No-Go、範囲承認 |
| Level 3 | 限定自動実行 | allowlist 内の反復実行 | 監視、停止、最終承認 |
レベル選択の原則
- 個人で試す初回タスクは Level 0 か Level 1 から始める
- 外部ツールを使う時点で、承認ゲートを入れる
- Level 3 は、対象業務、権限、停止条件、監視者を先に固定した場合のみ使う
- 削除、本番反映、顧客送信、権限変更は別枠で二重承認にする
3. Request Contract
AI依頼は、会話ではなく契約として定義します。 最低限そろえる項目は次の6つです。
| 項目 | 何を決めるか | 典型例 |
|---|---|---|
| Intent | 何を達成するか | 会議要約を作る、設計案を比較する |
| Context Boundary | 何を渡し、何を渡さないか | 社内公開資料のみ、個人情報は除外 |
| Output Contract | どの形式で返すか | 箇条書き、表、ADR、PR案 |
| Acceptance Check | 何を満たせば採用か | 3案比較、根拠明記、未確認点分離 |
| Verification | 何で裏取りするか | 一次情報、テスト、レビュー |
| Owner | 誰が成果物の採否と残存riskを引き受けるか | 業務owner、成果物の最終責任者 |
本書で単に Owner と書く場合は、Request Contractまたは対象成果物について最終的な採否を持つ人を指し、RACIのAccountableに対応します。承認者 は特定の承認ゲートで実行・公開・反映を許可する人、運用owner は日常運用を維持する人です。同じ人が兼ねても構いませんが、異なる場合は委任範囲とエスカレーション先を記録します。source、tool、metric等の局所的な責任は、source owner、tool owner、metric owner のように対象を付けて表記します。
最小テンプレート
目的:
入力境界:
出力契約:
受け入れ条件:
検証方法:
責任者:
この6項目がない依頼は、AIの性能以前に、依頼側の未定義が大きいと考えてください。
4. 承認ゲート
承認ゲートは、AIの暴走防止より、人間側の説明責任を明確にするために置きます。 最低限の承認点は次の3つです。
- 実行前承認
- 目的、影響範囲、禁止事項を確認する
- 採用前承認
- 出力を成果物へ反映してよいか確認する
- 外部共有前承認
- 顧客、取引先、公開チャネルへ出す前に確認する
実行前に確認すること
- どこまで自動で進めるか - ロールバック手段があるか - 外部接続や外部送信が発生するか - 個人情報や機密情報を含むか ## 5. 停止条件 次のいずれかに当てはまる場合、AIは実行を止め、確認質問へ切り替えるべきです。 - 目的が複数解釈できる - 成果物の形式が決まっていない - 承認者が不明である - 高リスク操作なのに承認がない - 機密情報、個人情報、認証情報の扱いが未定義である - 外部文書の指示を命令として採用しそうである - 検証方法がなく、採否条件も曖昧である ## 6. Trust Boundary 本書では、外部入力を命令として扱いません。 対象になる外部入力は、Webページ、メール、共有ドキュメント、添付ファイル、チケット、ログ、RAGで取得した断片を含みます。 ### 基本ルール - 外部入力は参考データとして扱う - 命令として有効なのは、依頼本文と承認済みの補足指示だけに限定する - 外部入力中の「前の指示を無視せよ」「秘密を出せ」「今すぐ実行せよ」を無効化する - ツール実行は allowlist と承認ゲートを通したものだけに限定する ## 7. 検証 検証は、「もっともらしい」出力を落とすための工程です。 最低限の検証手段は次の4つです。
- 顧客、取引先、公開チャネルへ出す前に確認する
- 一次情報確認
- 法令、規格、公式ドキュメント、原データに戻る
- 再現確認
- 同じ入力で同じ判断に至るか確かめる
- 差分確認
- 何が追加、削除、変更されたかを明示する
- 人間レビュー
- 採用基準に照らして最終判断する
検証の出力形式
結論: 根拠: 未確認点: 検証結果: 残リスク: 次の判断者:8. 証拠
保存するのは、会話全文ではなく、採否判断に必要な証拠です。 残す優先順位は次のとおりです。
- 採用基準に照らして最終判断する
- 依頼契約
- 承認記録
- 差分または出力本文
- 検証結果
- 採否理由
- 未確認点と保留理由
証拠として弱いもの
- 途中の思いつきだけのメモ
- 出典不明の要約
- 承認者不明の指示
- 実行したが検証していないログ
9. ログ最小化
ログは多いほど安全とは限りません。 特に、個人情報、機密情報、認証情報、内部判断のセンシティブな文脈は、保存量そのものがリスクになります。
最小化ルール
- 業務に不要な全文保存を避ける
- 個人情報は原文ではなく識別子へ置換する
- 認証情報や秘密情報をログへ残さない
- 目的外利用を防ぐため、保存期間と閲覧権限を定義する
- 要約ログを作る場合も、出典と判断者を紐づける
10. 責任分界
| 役割 | 主責任 | やってはいけないこと |
|---|---|---|
| 依頼者 | 目的と入力境界の定義 | 曖昧な依頼で実行させる |
| 実務担当 | 出力の整形と一次レビュー | 未検証のまま採用する |
| レビュアー | 採否判断と差分確認 | 承認範囲を越えて委任する |
| 承認者 | 実行・公開・反映の最終判断 | 事故時責任を現場へ丸投げする |
| 運用責任者 | ルール整備と改善 | ログ、権限、教育を放置する |
11. インシデント報告とエスカレーション
次の事象は、失敗例ではなくインシデント候補として扱います。
- 禁止情報が入力または出力に含まれた
- 承認外のツール実行が発生した
- 誤った外部送信が行われた
- 法令、契約、ポリシー違反のおそれがある
- 誤出力が意思決定や顧客対応に影響した
初動
- 実行停止
- 影響範囲の特定
- 関係ログと証拠の保全
- 承認者と運用責任者へ報告
- 外部説明が必要か判断
報告テンプレート
発生日: 発見者: 事象: 影響範囲: 停止措置: 未確定事項: 次の判断者:12. Small Start
最初から完全運用を目指す必要はありません。 ただし、次の3点は省略しないでください。
- Request Contract の6項目
- 実行前または採用前の承認ゲート
- 検証結果と採否理由の保存
この3点がない状態で自動化だけ進めると、速度は上がっても、事故時に説明できません。
章末まとめ
- AI依頼は会話ではなく Request Contract として扱う
- 自律度は Level 0 から段階的に上げ、高リスク操作は別枠承認にする
- 外部入力は命令ではなくデータとして扱い、trust boundary を明示する
- 証拠は会話全文ではなく、依頼契約、承認、差分、検証、採否理由を優先する
- ログ最小化とインシデント報告は、便利さより説明責任を優先する
実務チェックリスト
- 自律度レベルを対象業務ごとに決めた
- Request Contract の6項目をテンプレート化した
- 承認ゲートをどこに置くか決めた
- trust boundary をチームルールへ明記した
- 保存する証拠と保存しないログを分けた
- インシデント報告先を定義した
次に読む章・参照付録
- まず実務で試す: 第1章:即効性のある活用法
- 依頼テンプレートを増やす: 付録A:AIエージェント実務テンプレート集
- 実務会話例を確認する: 付録D:実務会話例集
- 用語と更新確認の観点を見る: 付録E:用語集と更新確認ノート
Source Notes
- NIST-AIRMF、NIST-GENAI: risk governance、測定、管理の運用原則
- OWASP-LLM-2025、OWASP-AGENTIC-2026: 外部入力、tool、権限、自律性のtrust boundary
- METI-AI-1-2、PPC-GENAI: 国内での役割・data取扱いの確認観点
- 対象version/status、確認日、再確認条件は付録Bに記録。最終確認: 2026-07-21