AI-DLC のガバナンス 第2部：AI デリバリー基盤のセキュリティの穴と、その塞ぎ方
ゆうべ、6 つのリポジトリで 40 件のエージェント実行が終わりました。何かがそれを承認しました。何かが 「どれに先に人間が必要か」を決めました。その決めた何かを見せてください。それを変更できるのは誰かを 見せてください。そして誰かが変更したことに、あなたがどうやって気づくのかを見せてください。
3 つ目の問いに、私はいまだ良い答えをもらえていません。そしてこれはコンプライアンスの話ではほとんど ありません。単純な運用上の問いです。あなたのチェックの一覧はどこにあり、誰かがそれを編集するのを 何が止めていますか。
はじめての方へ。AI-DLC は、定義されたプロセスの内側で AI エージェントが「作る」を担い、人間が 決められた地点で判断するデリバリーの進め方です。それが何でどうセキュアにするかは別に書きました。この記事は、それを動かすために作られ始めた プラットフォーム — とくに 1 つ — と、そこに欠けているガバナンス層についてです。
大部分は、すでに誰かが作っている
AWS が本気の実装を出荷しています。Collaborative AI-DLC です。early preview のサンプルで あり、これから批判しますが、それは褒め言葉です。この領域で、きちんと批判するに値する出来にたどり 着いた最初のものだからです。
平たく言えば、コーディングエージェントの上に乗ってそれらを統率する層です。インテントを書くと、 システムがそれを計画に変え、ステージを順に歩き、各ステージごとに隔離されたサンドボックスでコーディング エージェントを走らせます。エージェントは出力をチャット画面ではなく共有のグラフに書き込むので、 セッションが終わっても何も失われません。git の操作はすべてプラットフォームが握ります。人間は質問に 答え、承認し、実行中に軌道修正もできます。
私が姿勢を正したのは、彼らが私の主張してきたものを実装していた点です。
各ステップに独立した 3 つの安全網。曖昧さは推測されるのではなく実行を止めます。要求からコードまでの 完全な追跡可能性。ステップ単位のコスト、所要時間、トークン使用量。
これは真剣な設計です。今日何かを選ぶなら、この形を選んでください。以下は避ける理由ではありません。 あなたが自分で足すことになるものの一覧です。
自分の答案を採点する
新しく不満のリストを作るより、すでに公開した基準で測るほうが公平です。前回の記事で私は AI-DLC へのセキュリティの追加を提案し、それぞれが名前の付いた性質を 1 つ買うものでした。方法論を 実装したプラットフォームは、それが現れるべき場所そのものです。
というわけで、出荷されたものに対して自分の答案を採点します。
2 つが届いています。残りは、高くつく順に。
運用フェーズがありません。 ライフサイクルは計画・構築・デリバリーと進み、プルリクエストで止まり ます。しかし実装元の方法論はその先も続いていて、そこにこそ最も価値あるルールがありました。本番で 見つかったすべての問題が恒久的な新しいチェックになる、というルールです。修正が 1 回きりのもので なくなる。このループがなければ、プラットフォームは自分のインシデントから永遠に学べません。
チェックはゲートで走り、継続的には走りません。 判定の対象が変わったあとに届く判定は、遅い判定 ではなく無効な判定です。ステップ境界での検査は何もないよりは良く、その問題を小さく再輸入しています。
ノイズの多いチェックを誰も調整できません。 チェックは合格か不合格か。人がブロックし始める前に 調整する方法は文書化されていません。このルールこそ元記事で最も重要でした。誤検知は苛立ちではなく 統制の失敗であり、根拠のない最初のブロックが「ここの所見はノイズだ」とチームに教えるからです。
事前の脅威モデリングがなく、スコープにセキュリティの次元もありません。 良い知らせは構造的です。 これは組み合わせ可能なブロックから作られるワークフローなので、脅威モデリングのステップは再設計では なく追加で済みます。
そして最も重要な行と、この節がここに置かれている理由。彼らが最もうまく実装したガードレールは自動 チェックでした。決定論的で、ゲートに紐づき、失敗時に名前が付く — まさに主張どおりです。しかしその 推奨には後半がありました。その形の統制は「他のルールと同様にレビュー可能で差分可能になる」という 後半です。その半分は届かず、それが他のすべての蝶番でした。
それで、承認ゲートの変更は誰が承認するのか
この記事の残りがぶら下がっている一文を、プロジェクト自身のドキュメントから引きます。
ワークフローはビルディングブロックのライブラリ — ステップ、エージェントペルソナ、ルール、 チェックそのもの、スコープ — から組み立てられ、プラットフォーム管理者はドキュメントの言葉どおり 「ブロックをフォークし、ビジュアルコンポーザーでカスタムワークフローを構成」できます。
作業を走らせるエンジンとしては、これは機能であり、良い機能です。再デプロイなしに流れを変えられます。 統制を定義するものとしては、これが問題のすべてです。
プロダクトへのすべての変更は、あの丁寧に作られたパイプラインを通ります。どのチェックが存在するか を決める変更は、管理画面を通ります。プルリクエストなし。第二の承認者なし。それが統治している当の システムの追跡グラフにも、記録なし。
つまり「このステップはチェックされていますか」への正直な答えは「はい」ではありません。「はい、誰かが 最後に見た時点では。そして変わったかどうかは、私には言えません」です。
以前、存在し、レビューもされ、一度も効いていなかった統制 について書きました。これは同じ系列の 1 段上です。あちらでは統制が作動していませんでした。こちらでは 見事に作動していて、管理者ロールを持つ誰でも静かに取り外せます。そしてその取り外しは、痕跡を残す ために作られたシステムに痕跡を残しません。
残る 3 つのギャップ、高くつく順に
エージェントは 1 つの鍵を共有しています。 エージェントの認証情報はユーザーログインとは別に パラメータストアに置かれています。サンドボックスは隔離されていて、それは良いのですが、認証情報は 全員共通です。だからグラフは「どのステップがどの成果物を生んだか」を答えられても、「どのエージェント のアイデンティティが、誰の委譲した権限で動いたか」は答えられません。
まさにそれを規制当局が名指しし始めました。シンガポールのエージェント型 AI のための枠組みは 2026 年 1 月公開で、エージェントのために書かれた最初のものです。そこでは各エージェントが検証可能な アイデンティティを持ち、「どのエージェントが誰の承認のもとで行動したか」の監査証跡を持つことが求め られています。Cloud Security Alliance のギャップ調査はその距離を数字にしています。92% の 組織が自社の AI アイデンティティを完全には可視化できておらず、95% が侵害されたエージェントを検知・ 封じ込めできるか疑わしいと答えています。
追跡グラフは証跡ではありません。 グラフはナビゲーションには優れています。要求からそれを実装した コードまで追える。しかし書き込み可能で、プラットフォームが書き込み、エクスポートや署名の仕組みは 文書化されていません。以前の記事で、トランスクリプトと アクションログの線を引きました。一方は文脈、もう一方は証拠です。これはこの領域で私が見た中で最も 豊かな文脈であり、それでもなお文脈です。
コストは計測され、権限は計測されていません。 これはほとんど笑い話で、組織が既定で何を測るのかを よく示しています。
1 つの作業がいくらかかったかは 1 セント単位でわかります。それが何を許されていたかはわかりません。 そして実行の到達範囲は完全に計算可能です。各ステップが触れられるものを足し合わせるだけです。その 数字を金額の隣に置くことは、私が書けるどんなポリシー文書よりも設計会議を変えるはずです。
ツールは何にならなければいけないのか
置き換えではありません。1 つ目と並ぶ 2 つ目の層であり、その大半はすでにやり方を知っているもので できています。
- ワークフローは git に置く。 プルリクエストでレビューし、署名し、実行時に固定する。チェックの 変更それ自体がチェックされる変更になる。他は任意です。これだけは違います。
- 実行ごとのアイデンティティ。 短命で、帰属可能で、その作業に限定される。共有のプラット フォーム鍵は使わない。この実行は、この人のために、これらのことを 11 分間できたと言えるように。
- すべての行為に権限を記録する。 行為だけではなく。誰が何を許したかの連鎖こそ、インシデントが 必要とし監査人が求めるものです。
- 追記専用の記録。 作業用グラフとは別に、エクスポート可能で署名済みのもの。
- 到達範囲を数値として、コストの隣に、ステップ単位とインテント単位で。
- 再検査のトリガー。 ワークフローが変わったら、旧版で承認されたものは誰かが確認するまで未検証。
1 番はリポジトリ 1 つとブランチ保護ルール 1 本です。今四半期にできます。
これの代償
ワークフローを git に置くと、ワークフローの変更が遅くなります。 それが目的のすべてですが、 それでも人は苛立ちます。90 秒で調整できたステップがレビュー待ちになります。「小さな」変更を例外に してほしいという要望が必ず出ますし、その例外が次のインシデントの出どころになると見ておくべきです。
実行ごとのアイデンティティは、識別基盤における本物の作業です。 そしてその基盤がデリバリーの クリティカルパスに載ります。ここで群を抜いて高価な項目です。
そして影響範囲の小さいものを出荷する小さなチームには、ほとんどが過剰です。 エージェントが本番 データに届かず、お金も動かせないなら、プラットフォームは出荷されたまま動かし、ワークフローだけ git に置いて、残りは状況が変わるまで飛ばしてください。いつもどおりガバナンスは結果の大きさに比例 させること。社内ツールに 6 つ全部を当てるのは演劇であり、演劇はエンジニアに「この助言は場合を区別 しない」と教えます。
月曜にやること
- チェックを定義している成果物を見つけて、変更管理下に置く。 プラットフォームが何であれ、 どこかにその一覧があります。見つけ、コミットし、ブランチを保護し、第二の承認者を必須にする。 管理画面の裏のデータベースにあるなら、毎晩エクスポートして差分を取る。正しい答えの劣化版ですが、 半日で終わります。
- 1 つのインテントの到達範囲を手で出す。 各ステップが触れられるものを足す。その数字を、それを 所有するチームに見せる。これで誰の考えも変わらなかったことはありません。
- 管理者ロールを持つのは誰かを確認する。 そしてそれが「本番のゲートを消していい人」の一覧と 同じかどうかも。たいてい同じではありません。
Gartner はエージェント型 AI プロジェクトの 40% 超が 2027 年末までに中止されると予測し、 コストの膨張、価値の不明確さ、リスク統制の不足を理由に挙げています。3 つ目が 2 つ目を招いていると 私は見ます。エージェントが何を許されていたかを示せないプログラムは支出を正当化しづらく、正当化でき ないプログラムは中止されます。
結局のところ
私たちは、ソフトウェアデリバリーを出資者に読み取れるようにするため、ひと世代ぶんのツールを作りま した。チケット、ボード、バーンダウン — すべては、その場にいなかった人が何が起きたかを知るために。
そのエージェント版はより難しく、より面白い。読み取れるようにすべき対象がもう進捗ではないからです。 それは権限です。何が許されていたのか、誰によって、どのルールのもとで、そしてそのルールはあなたが 思っていたものだったのか。
Collaborative AI-DLC は大部分までたどり着き、最後の扉を開けたままにしています。early preview の サンプルとしては妥当な止まり方です。あなたの止まる場所としては妥当ではありません。その扉は、 もうあなたのビルドパイプラインの中にあるからです。
ワークフローを git に置いてください。他はプロジェクトですが、これは半日です。そしてそれが、ゲートが あることと「ゲートがあるという噂」の違いです。
出典と、それぞれの使いどころ
- Collaborative AI-DLC とそのドキュメント（AWS Samples）— 本文で論じた プラットフォームであり、引用した 2 つの表現の出典。early preview なので、本番リポジトリに向ける 前にコードを読んでください。
- Model AI Governance Framework for Agentic AI — シンガポール IMDA、2026 年 1 月。 モデルではなくエージェントのために書かれた最初の規制枠組みで、エージェントの監査証跡に何が含まれる べきかについて最も明快な公開文書です。
- The AI Agent Governance Gap — Cloud Security Alliance。アイデンティティの統計の 出典であり、既存の AI 枠組みが自律エージェントに届かない理由の良い説明でもあります。
- Gartner のエージェント型 AI 中止予測 — 2025 年 6 月。見出しの数字より、挙げられて いる原因のほうが有用です。
この分野の仕事は、進むにつれて書いています。こうしたプログラムのガバナンスを立ち上げようとしている 方は、LinkedIn で連絡が取れます。私がメンテナンスしている ツールは shenril と BlueSquadron にあります。