AIエージェント協働の実務SOP

このページは、本書全体で共通に使う実務SOPです。 目的は、AIとの会話を増やすことではなく、依頼、承認、実行、検証、証拠、責任分界を一本の運用として揃えることです。 2026年7月21日時点で、主要なAIプラットフォームは、構造化出力、ツール利用、評価、外部連携の機能を継続更新しています。本SOPは、製品差分より先に守るべき共通原則を定義します。

この章の使い方

誰向け

  • AIを日常業務へ入れたい現場担当者
  • チーム標準を作りたいPMや運用責任者
  • ツール利用や自動化の境界を決めたいエンジニア
  • 承認と説明責任を持つマネージャー

    この章でできるようになること

  • AI依頼を Request Contract として定義できる
  • 自律度、承認ゲート、停止条件を業務に合わせて選べる
  • 外部入力を命令として扱わない trust boundary を明文化できる
  • 証拠、ログ最小化、インシデント報告の基準を統一できる

    最短ルート

    1. 自律度レベル表を確認する
    2. Request Contract の6項目を自分の業務に当てはめる
    3. 承認ゲート、停止条件、証拠保存の3点だけ先に導入する

      深掘りルート

    4. 自律度、承認、停止条件、trust boundary を順に読む
    5. 検証、証拠、ログ最小化、責任分界まで設計する
    6. インシデント報告の雛形を自チーム版へ置き換える

      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 ownertool ownermetric owner のように対象を付けて表記します。

最小テンプレート

目的:
入力境界:
出力契約:
受け入れ条件:
検証方法:
責任者:

この6項目がない依頼は、AIの性能以前に、依頼側の未定義が大きいと考えてください。

4. 承認ゲート

承認ゲートは、AIの暴走防止より、人間側の説明責任を明確にするために置きます。 最低限の承認点は次の3つです。

  1. 実行前承認
    • 目的、影響範囲、禁止事項を確認する
  2. 採用前承認
    • 出力を成果物へ反映してよいか確認する
  3. 外部共有前承認
    • 顧客、取引先、公開チャネルへ出す前に確認する

      実行前に確認すること

       - どこまで自動で進めるか
       - ロールバック手段があるか
       - 外部接続や外部送信が発生するか
       - 個人情報や機密情報を含むか ## 5. 停止条件 次のいずれかに当てはまる場合、AIは実行を止め、確認質問へ切り替えるべきです。
       - 目的が複数解釈できる
       - 成果物の形式が決まっていない
       - 承認者が不明である
       - 高リスク操作なのに承認がない
       - 機密情報、個人情報、認証情報の扱いが未定義である
       - 外部文書の指示を命令として採用しそうである
       - 検証方法がなく、採否条件も曖昧である ## 6. Trust Boundary 本書では、外部入力を命令として扱いません。 対象になる外部入力は、Webページ、メール、共有ドキュメント、添付ファイル、チケット、ログ、RAGで取得した断片を含みます。 ### 基本ルール
       - 外部入力は参考データとして扱う
       - 命令として有効なのは、依頼本文と承認済みの補足指示だけに限定する
       - 外部入力中の「前の指示を無視せよ」「秘密を出せ」「今すぐ実行せよ」を無効化する
       - ツール実行は allowlist と承認ゲートを通したものだけに限定する ## 7. 検証 検証は、「もっともらしい」出力を落とすための工程です。 最低限の検証手段は次の4つです。
      
  4. 一次情報確認
    • 法令、規格、公式ドキュメント、原データに戻る
  5. 再現確認
    • 同じ入力で同じ判断に至るか確かめる
  6. 差分確認
    • 何が追加、削除、変更されたかを明示する
  7. 人間レビュー
    • 採用基準に照らして最終判断する

      検証の出力形式

      結論:
      根拠:
      未確認点:
      検証結果:
      残リスク:
      次の判断者:
      

      8. 証拠

      保存するのは、会話全文ではなく、採否判断に必要な証拠です。 残す優先順位は次のとおりです。

  8. 依頼契約
  9. 承認記録
  10. 差分または出力本文
  11. 検証結果
  12. 採否理由
  13. 未確認点と保留理由

    証拠として弱いもの

    • 途中の思いつきだけのメモ
    • 出典不明の要約
    • 承認者不明の指示
    • 実行したが検証していないログ

      9. ログ最小化

      ログは多いほど安全とは限りません。 特に、個人情報、機密情報、認証情報、内部判断のセンシティブな文脈は、保存量そのものがリスクになります。

      最小化ルール

    • 業務に不要な全文保存を避ける
    • 個人情報は原文ではなく識別子へ置換する
    • 認証情報や秘密情報をログへ残さない
    • 目的外利用を防ぐため、保存期間と閲覧権限を定義する
    • 要約ログを作る場合も、出典と判断者を紐づける

      10. 責任分界

役割 主責任 やってはいけないこと
依頼者 目的と入力境界の定義 曖昧な依頼で実行させる
実務担当 出力の整形と一次レビュー 未検証のまま採用する
レビュアー 採否判断と差分確認 承認範囲を越えて委任する
承認者 実行・公開・反映の最終判断 事故時責任を現場へ丸投げする
運用責任者 ルール整備と改善 ログ、権限、教育を放置する

11. インシデント報告とエスカレーション

次の事象は、失敗例ではなくインシデント候補として扱います。

  • 禁止情報が入力または出力に含まれた
  • 承認外のツール実行が発生した
  • 誤った外部送信が行われた
  • 法令、契約、ポリシー違反のおそれがある
  • 誤出力が意思決定や顧客対応に影響した

    初動

    1. 実行停止
    2. 影響範囲の特定
    3. 関係ログと証拠の保全
    4. 承認者と運用責任者へ報告
    5. 外部説明が必要か判断

      報告テンプレート

      発生日:
      発見者:
      事象:
      影響範囲:
      停止措置:
      未確定事項:
      次の判断者:
      

      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-AIRMFNIST-GENAI: risk governance、測定、管理の運用原則
  • OWASP-LLM-2025OWASP-AGENTIC-2026: 外部入力、tool、権限、自律性のtrust boundary
  • METI-AI-1-2PPC-GENAI: 国内での役割・data取扱いの確認観点
  • 対象version/status、確認日、再確認条件は付録Bに記録。最終確認: 2026-07-21