agentic-sdlc-controls

エージェント型 SDLC の統制

パイプライン内のエージェントは、あなたの認証情報を使い、機械の速度で、反復作業に疲れることなく動作します。それがエージェントの目的であり、同時に脅威モデルでもあります。確認すべきはエージェントの意図ではなく、境界です。

書き込み権限を持つすべてのコーディングエージェントに適用されます。Claude Code、Codex、Cursor、OpenCode、あるいはモデルを呼び出す CI ジョブも対象です。ここに記載する内容は、どのエージェントを使うかに左右されません。

1. エージェントが実際にアクセスできる範囲を把握する

見解を述べる前に、まず棚卸しをします。各エージェントや自動化について、次の点を確認してください。

• ID：どのユーザーの認証情報で実行されますか？名前付きのサービス ID ですか、それとも個人のトークンですか？
• リポジトリ：読み取り、書き込み、管理者のどの権限がありますか？デフォルトブランチにプッシュできますか、それとも PR を開くだけですか？
• 環境：ステージング、本番環境、顧客データにアクセスできますか？
• シークレット：実行時の環境にどの値があり、そのうちタスクで実際に必要なものはどれですか？
• ネットワーク：任意の外部呼び出しができますか、それとも送信通信は制限されていますか？

これらを表にまとめてください。よくある問題は、微妙な設定ミスではなく、そもそも誰も一覧を把握していないことです。

2. 可逆な操作と不可逆な操作を分ける

エージェントが実行できる操作をすべて分類してください。

分類	例	統制
可逆で影響範囲が限定される	ファイルを編集する、テストを実行する、PR を開く	実行させる
可逆で可視性がある	ブランチをプッシュする、イシューにコメントする	実行させ、ログに記録する
元に戻すのに時間がかかる	main にマージする、パッケージを公開する、スキーマを移行する	人間の承認ゲート
不可逆	データを削除する、本番環境の認証情報をローテーションする、外部にメールを送信する、金銭を支出する	委任しない

守るべきなのは3行目です。重要なのは操作がどれほど危険に聞こえるかではなく、可逆性です。

3. プロンプトではなくランタイムでゲートを強制する

何かをしないようにという指示は、単なる希望です。エージェントが回避できない統制こそが境界です。

• エージェントが内部で実行する仕組みを優先してください。実行前フック、許可／拒否リスト、ローカル設定で上書きできない管理対象の設定などです。
• エージェントを非対話モードで実行した場合にもゲートが機能することを確認してください。承認プロンプトの多くは、CI では気づかれないまま通過します。
• 拒否経路がテストされているか確認してください。テストされていないゲートは、誰も開いているかどうかを知らないゲートです。
• エージェントが、自身を制限するファイルを編集できないことを確認してください。

次の点を直接確認してください。エージェントが権限範囲内で最悪の操作を試みた場合、何がそれを止めますか？また、それが機能するところを誰かが確認しましたか？

4. 認証情報の範囲をタスクと影響範囲に合わせる

• エージェントの目的ごとに ID を割り当て、個人のトークンを共有しない
• 長期間有効なキーではなく短期間有効な認証情報を使用し、タスクの所要時間に合わせて有効期限を設定する
• 環境階層に応じて自律性を変える。サンドボックスでは広く、ステージングでは狭く、本番環境では最小限にする
• タスクで可能な場合は、デフォルトで読み取り専用にする。多くのレビューエージェントやトリアージエージェントには、書き込み権限は不要です。
• 実行環境を隔離し、侵害されたエージェントや混乱したエージェントがワークスペースの外にアクセスできないようにする

5. エージェントへの入力を信頼できないものとして扱う

エージェントは、イシュー、PR の説明、依存関係の README、ウェブページ、ツールの出力を読み取ります。これらのいずれにも指示が含まれている可能性があります。

• タスク中に取得したコンテンツによって、タスクで許可されている操作の範囲を拡大できないようにする
• エージェントのツール結果が、ゲートなしで特権操作に反映されるかどうかを確認する
• エージェントが読み取るソースに無害な指示を注入してテストし、それに従って動作するかを観察する

6. 経緯を再構成できるようにする

エージェントが作成した変更について、監査担当者やインシデント対応担当者が、何が依頼され、何が作成され、誰が承認し、どの設定が適用されたかを確認できる必要があります。

• プロンプト、計画、仕様を差分とともにバージョン管理する
• エージェントの設定（権限、フック、モデル、スキルセット）は、変更時点のものを記録し、後から HEAD から読み込まない
• 承認は、ボタンをクリックした人の記憶ではなく、イベントとして記録する

これらが不十分な場合は、ai-change-evidence スキルと組み合わせてください。監査証跡に変換する方法を解説しています。

対象範囲と実施ルール

自分が所有する、または書面で評価を許可されているパイプラインのみをレビューしてください。ゲートのテストでは、制御によって阻止されるべき操作を試みます。オーナーの合意を得たうえで、サンドボックスまたは予定された時間帯に実施し、独断で本番環境を対象にしてはいけません。インジェクションテストでは無害なマーカーを使用し、制御が失敗した場合に害を及ぼすものは仕込まないでください。

出力

各検出事項について、エージェントがアクセスできる対象、不足または適用されていない制御、その制御を試す具体的な手順、そして問題を解消する最小限の変更を報告してください。「エージェントが現時点で実行できること」と「より望ましいベストプラクティス」を分けてください。それぞれの問題についてオーナーを明記してください。オーナーのいない制御は、制御とは言えません。