2026 年 5 月、InfoQ が How GitHub Is Securing Agentic Workflows in Modern CI CD Systems を公開し、GitHub が CI/CD 内の自律エージェントを安全に運用するための多層防御アーキテクチャを詳細に発表しました。隔離（Isolation）・実行制約（Constrained Execution）・監査可能性（Auditability）の 3 軸で、プロンプトインジェクション・特権昇格・意図しない動作を抑える設計です。
弊社では、受託案件で 「お客様の本番リポジトリに AI エージェントを導入したい」というご相談が増えています。本記事では、GitHub の多層防御モデルを参考に、受託で運用するための実装パターン、契約条項、落とし穴を整理します。コスト側の最適化は GitHub Agentic Workflows のトークン効率化 で、エージェント生成 PR のレビュー側は エージェント PR レビューの標準フロー で扱っており、本記事はその セキュリティ側面の補完として位置付けています。
なぜ今「CI/CD のエージェント防御」なのか
CI/CD にエージェントを組み込む動きは過去 1 年で急加速しましたが、同時にインシデントも増えました。
| インシデント分類 | 受託案件で起きうる事象 |
|---|---|
| プロンプトインジェクション | 外部 PR の本文経由で機密 secrets を漏洩 |
| 特権昇格 | エージェントが GITHUB_TOKEN で本来権限のないリポジトリへ書き込み |
| 意図しない動作 | 「自動修正」が本番ブランチに直 push、機能を破壊 |
| サプライチェーン汚染 | 自動マージで悪意ある依存を取り込む |
これらは、「エージェントに何でもやらせる」設計で必ず発生します。GitHub の多層防御は 「やらせない領域を明確に分ける」という素朴で堅牢なアプローチです。これは npm install 任意実行と DevSecOps で扱った “サプライチェーン防御” と同じ思想を、エージェント運用層に拡張した形です。
3 軸の多層防御を受託に翻訳する
GitHub のモデルを受託の現場に翻訳すると、以下の 3 階層になります。
軸 1: 隔離（Isolation）
エージェントはホストランナー上で動かさず、短命のコンテナ / Firecracker MicroVM に閉じ込めます。
| 隔離レベル | 実装 | 受託での適用 |
|---|---|---|
| プロセス隔離 | Docker | 実装簡単、既存 Action と互換 |
| カーネル隔離 | gVisor / Kata | 業務 SaaS 案件の標準 |
| ハードウェア隔離 | Firecracker | 金融 / 医療 / 上場企業 |
特に 「外部 PR 経由のジョブ」は、必ず Firecracker レベルの隔離下で実行します。「内部 push のジョブ」と同じランナーで動かさないのが鉄則です。
軸 2: 実行制約（Constrained Execution）
エージェントが叩ける API・呼べるシェルコマンド・アクセスできる secrets を 明示的なホワイトリストで限定します。
| 制約対象 | 実装方法 |
|---|---|
| GitHub API | OIDC + 短命トークン + リポジトリ単位スコープ |
| シェルコマンド | seccomp プロファイル + apparmor |
| ネットワーク | egress を許可ホストのみに制限 |
| secrets | 環境変数経由ではなく Secret Manager から都度取得 |
これは HashiCorp Vault 2 のエージェント secrets 連携 で扱った “短命 ID + 都度取得” と組み合わせると、「漏洩しても実害が出ない」設計に近づきます。
軸 3: 監査可能性（Auditability）
エージェントの 「何を見て、何を考えて、何をしたか」を完全にログ化し、後追いで再現できる状態を維持します。
| ログ対象 | 保存先 | 保存期間 |
|---|---|---|
| 入力プロンプト + コンテキスト | 不変ストレージ（S3 Object Lock 等） | 7 年 |
| エージェントの推論ログ | 同上 | 1 年 |
| 実行コマンド + 結果 | SIEM | 1 年 |
| 影響範囲（変更ファイル / API 呼び出し） | Git ログ + CloudTrail | 永久 |
特に **「不変ストレージへの保存」は、「インシデント時に改ざんされていない証拠が出せる」**ためのもので、規制業界の受託では必須要件です。
受託で組む「エージェント運用 4 段階」
GitHub の多層防御を踏まえ、弊社では受託案件にエージェントを段階的に導入します。
[Phase 0: 観察モード]
├ エージェントは提案のみ、実行はしない
├ PR コメントで「こうします」と言うだけ
└ 1 〜 2 ヶ月、誤検知率を計測
[Phase 1: 限定実行モード]
├ Lint 修正・フォーマット・コメント生成のみ自動実行
├ ブランチは feature/* に限定
└ main / release への書き込み禁止
[Phase 2: PR 自動作成モード]
├ 依存更新・テスト追加の PR を自動作成
├ マージは必ず人間レビュー
└ 自動修正 PR にラベル付与
[Phase 3: 限定マージモード]
├ 特定条件（緑のテスト + 影響範囲小）で自動マージ可
├ ただし即時ロールバック手段を確保
└ 月次でロールバック発生率をレビュー特に Phase 0 から Phase 1 への移行を急いで失敗するケースが多く、「最低 4 週間の観察期間」を契約に明記します。これは Claude Code Auto Mode の Approval Gates で扱った段階的承認と同じ思想です。
受託契約に書く「エージェント運用条項」
エージェントを顧客リポジトリに導入する受託契約では、以下の条項を明記します。
| 条項 | 内容 | 顧客が確認すべきこと |
|---|---|---|
| 隔離レベル | プロセス / カーネル / ハードウェア隔離のどれを採用 | 業界規制との整合 |
| 権限スコープ | エージェントが触れるリポジトリ / ブランチ / ファイル | リポジトリ単位の許諾 |
| secrets アクセス | エージェントがアクセス可能な secrets 一覧 | 機密度別のラベリング |
| 実行ログ保存期間 | プロンプト / 推論 / 結果のログ保管年数 | 業界規制との整合 |
| インシデント対応 SLA | 異常動作検知から停止までの時間 | 24h / 4h / 即時のレベル選択 |
| ロールバック手順 | エージェント起因の障害時の復旧手順 | RPO / RTO |
| 責任分界 | エージェントの誤動作の責任主体 | 保険・補償の有無 |
特に 「責任分界」は最初に明文化しないと、「AI が壊した」と言われても泣き寝入りになります。「ホワイトリスト外の動作については弊社責任、ホワイトリスト内の判断は顧客責任」といった具体記述が必要です。
価格モデル — エージェント CI/CD 運用パッケージ
GitHub 多層防御を組み込んだ受託パッケージは以下のレンジです。
| プラン | 初期 / 月額 | 対象 | 内容 |
|---|---|---|---|
| Agent Lite | 80 万円 / 12 万円〜 | スタートアップ / 小規模 | プロセス隔離 + Phase 0/1 |
| Agent Standard | 280 万円 / 35 万円〜 | 中堅企業の業務 SaaS | カーネル隔離 + Phase 0/1/2 + 月次監査 |
| Agent Enterprise | 700 万円〜 / 90 万円〜 | 規制業界 / 上場企業 | ハードウェア隔離 + Phase 0/1/2/3 + 24h SOC 連携 |
特に Agent Standard は 「エージェントを入れたいが、内製のセキュリティチームが手薄」な中堅企業に刺さるレンジです。
ハマりやすい 5 つの落とし穴
CI/CD エージェントを受託で運用するときの落とし穴を共有します。
落とし穴 1: 既存の Action と同じランナーで動かす
エージェントを 「ただの Action」として扱うと、隔離が破綻します。専用ランナーラベル + 専用ネットワークで物理的に分離します。
落とし穴 2: GITHUB_TOKEN を full permission で渡す
デフォルトの GITHUB_TOKEN は権限が広すぎます。workflow ごとに permissions を最小化し、必要なら Apps Token を別途発行します。
落とし穴 3: プロンプトインジェクションのテストを怠る
外部 PR の本文経由で攻撃が成立する事象は、ステージング環境で意図的に攻撃テストしないと気付けません。月次でレッドチーム演習を契約に組み込みます。
落とし穴 4: 監査ログを「あれば良い」にする
誰も見ないログは存在しないのと同じです。月次でログのサンプリング監査を契約に組み込み、異常パターンの検知率を KPI 化します。
落とし穴 5: ロールバック手段を整備せず Phase 3 に進む
自動マージモードに進む前に、「全 PR を即時 revert できるツール + 訓練」を必ず実施します。演習なしの本番投入は事故の温床です。
まとめ — 「エージェントを動かす」から「安全に動かす」へ
GitHub の多層防御アーキテクチャは、CI/CD エージェント運用の **「動くのは知ってる、安全に動かすのが難しい」フェーズへの公式回答です。受託の現場では、「お客様リポジトリにエージェントを入れる」**ことの責任を明示的に分界する設計が必要不可欠です。
弊社では Agent Lite / Standard / Enterprise の 3 段階で 多層防御エージェント運用パッケージを提供しています。「社内エンジニアの生産性を AI で上げたいが、セキュリティが不安」「エージェントは入れたが運用が回らない」というご相談は お問い合わせフォーム からお気軽にどうぞ。
