AIコーディングエージェントに任せる範囲を4段階で決める実行境界表

AIコーディングエージェントを導入するとき、「コード作成に使ってよいか」だけでルールを作ると、必要な判断が残ります。同じ不具合修正でも、リポジトリを読むこと、修正案を表示すること、テストを動かすこと、共有ブランチや本番環境を変えることでは、影響範囲が異なるためです。利用の可否を一つにまとめず、AIが実際に行う操作ごとに決めることを提案します。

最初の区分は、①読む、②案を作る、③ローカルで検証する、④共有環境を変更する、の4段階です。操作が後ろの段階に進むほど、対象ファイル、接続先、実行前の承認、人による最終操作を具体的にします。全チーム共通の禁止事項だけで済ませず、対象業務ごとに実行境界表へ記入してください。

例：軽微な表示不具合の修正では、担当開発者が指定したリポジトリ内のコードとテストを読むこと、修正案とテストコードを作ること、個人のローカル環境でテストすることまでは候補にできます。一方、共有ブランチへの反映、本番デプロイ、アクセス権の変更は、AIの自動操作の対象から外し、レビュー後に人が実施する設計にします。

AWSの解説では、Codexは開発者のワークステーションでタスクループを実行し、ローカルファイルを読み取り、ローカルのサンドボックスと承認設定の範囲内で承認済みのツールを実行すると説明されています。また、LiteLLMはモデル認証、ルーティング、予算、レート制限、ゲートウェイテレメトリを共通で管理するコントロールポイントとされています。 [1]

この役割分担を使い、管理項目を二つに分けてください。一つは、誰がどのモデルをどの経路で利用できるか、利用量をどう把握するかという「モデル呼び出し」の管理です。もう一つは、AIがどのファイルを読み、どのコマンドや接続先を使い、変更をどこへ反映できるかという「作業実行」の管理です。前者が整っていても、後者の承認条件を省略しないことが重要です。

例：組織の承認済みモデルだけを利用する設定でも、開発端末で実行するテストコマンドが外部サービスへ接続する場合があります。この場合は、モデル利用の許可とは別に、接続先、利用する認証情報の扱い、通信を許可する条件、実行結果の確認者を実行境界表に記入します。

表を作る担当は、AI利用の共通窓口だけにせず、対象業務を理解する開発リーダーと、そのリポジトリや環境の管理担当を含めます。まず、障害調査、単体テストの追加、依存関係の更新、設定変更、デプロイ準備など、実際にAIへ依頼したい業務を一行ずつ出してください。一行に複数の目的を混ぜないほうが、後の承認条件を決めやすくなります。

各業務について、AIに渡す入力と、渡さない情報を先に決めます。入力には、対象ディレクトリ、関連する仕様、再現手順、許可したテストデータを記します。含めない情報には、本番の認証情報、不要な顧客データ、他案件の設定ファイルなどを具体名で書きます。「機密情報を入れない」という抽象的な表現だけでは、依頼者が判断しにくいためです。

次に、ファイル、コマンド、ツール、接続先を操作別に限定します。読む段階では対象パスを指定し、案を作る段階では差分の提示までに留めます。ローカル検証を認める場合は、実行可能なテストコマンド、使用してよいダミー環境、ネットワーク接続の要否を記します。共有環境の変更を扱う場合は、AIに実行させるのか、人が差分を反映するのかを明記してください。

承認者は役職名だけで終わらせず、どの時点で何を確認するかを決めます。実行前には、依頼内容が対象業務に一致すること、渡す入力に含めない情報が入っていないこと、許可されたツールだけを使うことを確認します。反映前には、差分、テスト結果、既存機能への影響、ロールバック方法を確認する担当を置きます。

自動実行を許可しない停止条件も、あらかじめ表に書きます。たとえば、権限の付与・変更、秘密情報を含む可能性があるファイルへのアクセス、データ削除を伴うコマンド、外部サービスへの書き込み、本番環境への反映、想定外のディレクトリ変更は、AIの処理を止めて人へ渡す条件にできます。停止後に誰へ連絡するかも同じ欄に記載してください。

例：依存関係の更新では、AIに更新候補と影響を受けるファイルの一覧を作らせ、ローカルテストまでを許可します。ロックファイルの変更内容、脆弱性対応の必要性、ライセンスや互換性の確認が必要になった時点では自動反映を止め、レビュー担当者が採否を決める流れにします。

記録は会話全文を保管することだけを目的にせず、次の担当者が再判断できる最小単位に絞ります。少なくとも、対象業務、依頼者、操作区分、AIに渡した資料の版、許可したコマンドや接続先、実行時刻、変更差分、テスト結果、承認者、保留・停止の理由を残す方法を提案します。記録場所も、リポジトリのレビュー、チケット、変更管理票などから一つを決めます。

公開前には、表を作成していない別の開発者に、表だけを渡して判断してもらいます。その人が、AIに渡してよい情報、実行可能な操作、停止すべき条件、反映前の確認者を同じように答えられなければ、表の表現が不足しています。この再現確認を、対象業務の追加時やツール設定の変更時にも行ってください。

週次または変更の区切りで、停止した操作と人が差し戻した理由を見直します。許可範囲を広げる判断は、単に利用回数が増えたことではなく、差分確認とテスト結果の確認が継続して回ったか、停止条件が実務に合っていたかを材料に行うことを提案します。

対象業務ごとに、次の項目を一行ずつ記入します。業務の目的、入力、操作、承認、停止条件、記録を同じ表で確認できるようにしてください。

AIエージェントの実行境界表

• 対象業務：＿＿＿＿＿＿＿＿／依頼者：＿＿＿＿＿＿＿＿／利用するリポジトリ・環境：＿＿＿＿＿＿＿＿
• AIに渡す入力・資料の版：＿＿＿＿＿＿＿＿／含めない情報・ファイル：＿＿＿＿＿＿＿＿
• 操作区分ごとの許可範囲：読む＿＿＿＿＿＿＿＿／案を作る＿＿＿＿＿＿＿＿／ローカル検証＿＿＿＿＿＿＿＿／共有環境変更＿＿＿＿＿＿＿＿
• 許可するファイル・コマンド・ツール・接続先：＿＿＿＿＿＿＿＿／利用不可の操作：＿＿＿＿＿＿＿＿
• 実行前の承認者：＿＿＿＿＿＿＿＿／承認方法・確認項目：＿＿＿＿＿＿＿＿
• 自動実行を止める条件：＿＿＿＿＿＿＿＿／停止時の連絡先・最終判断者：＿＿＿＿＿＿＿＿
• 実行後の確認担当者：＿＿＿＿＿＿＿＿／確認する差分・テスト結果・反映内容：＿＿＿＿＿＿＿＿
• 残す記録の場所：＿＿＿＿＿＿＿＿／見直し日：＿＿＿＿＿＿＿＿／別担当者による再現確認者：＿＿＿＿＿＿＿＿

出典・参考資料

1. AWS（確認日：2026-10-22）