AI-DLC を安全にする — プロセスの健全性は、プロダクトのセキュリティではない
緑色の監査証跡を、それで話が済んだかのように差し出される場面が続いています。確かに見事な成果物です — すべての判断、すべての承認、すべての要件が、それを実装したコードまで追跡できる。そしてそれは、 ソフトウェアが安全かどうかについて何も語っていません。
この記事の主題はその隙間です。ただし隙間の話は、方法論が実際に何をするのかを知らないと成立しません。 まずそこから始めます。
AI-DLC とは何か
AI-Driven Development Life Cycle（AI-DLC） は、AWS がオープンソースのワークフロー群として公開して いる AI ネイティブな方法論です。ルールセット、フェーズ定義、拡張の仕組みはすべて awslabs/aidlc-workflows で公開されており、以下の記述はすべて案件ではなくこのリポジトリに 基づいています。
出発点は、デリバリーにおける AI の一般的な使い方が 2 つともうまくいっていないという認識です。AI を アシスタントとして扱う — 補完、ドキュメント、テスト — 場合、プロセスは手つかずのまま残り、したがって 非効率も手つかずで残ります。逆に AI を自律的なものとして扱い、要件書からアプリケーション全体を作らせる やり方は、別の理由で失敗します。何が正解かを決めるビジネス文脈に、モデルは触れられないからです。
AI-DLC は第三の立場を取ります。AI は定義されたプロセスの中で動く構造化された協働者であり、プロセス そのものをその前提で書き直す。仕事をするのは一つのループで、それがライフサイクルのあらゆる活動で 繰り返されます。
この図のうち、方法論の重さを担っているのは 3 点です。
ループは必ず人間で終わる。 エージェントは起案し、構造化された確認質問を投げ、文脈を集め、そこで 止まります。自己承認できず、ステージを飛ばせず、曖昧なまま進めません。ゲートでの結果は 2 つだけ — 承認するか、修正を求めるか。
深さはリスクに適応する。 バグ修正は設計の儀式を飛ばしてほぼコードへ直行します。新規の顧客向け サービスはフルセットを走らせます。ワークフローには CVE 対応専用のスコープまであり、どのステージが 走るかだけでなくなぜ他を飛ばすのかまで文書化されています。プロセス上の判断について、ここまで 明示的な方法論は多くありません。
文脈はリポジトリに残る。 計画、要件、設計、そして追記のみの監査証跡が、コードと並ぶ markdown として 存在します。フェーズは累積的です。Inception が何を・なぜを決め、Construction がどうを決め、 Operation が動かす。それぞれが次へより豊かな記録を渡します。作業はエピックではなく unit of work で 組織され、サイクルは数週間のスプリントではなく数時間から数日の bolt です。
その土台にある仕組みは名前を付けておく価値があります。あとでセキュリティを扱いやすくしているのは これだからです — ガバナンスは wiki ページではありません。エージェントの挙動を制約する機械可読な ルールがリポジトリにあり、加えてステージゲートで発火する決定論的なチェックがある、という構造です。
一つの言葉に押し込まれた 2 つの性質
ここから隙間の話です。
AI-DLC はプロセスについて際立って強い。成果物は安定した識別子を持つので、要件はストーリーへ、受入 基準へ、そしてコードへ追跡できます。しかも欠落や孤立は感覚ではなく名前で報告されます。各フェーズ境界で、 方法論は次のフェーズに進む前にその連鎖を再検証します。すべての入力・判断・承認がタイムスタンプ付きで 監査証跡に残ります。
これは、私が監査してきた規制産業のプログラムが手作業で作る記録より優れています。
そして同時に、これは完全に方法についての主張です。
プロセスの健全性は「人間が判断し、それを証明できるか」に答えます。プロダクトのセキュリティは 「作ったものは実際に安全か」に答えます。前者を後者と読むのはカテゴリの誤りで、しかも心地よい誤りです。 前者は証拠を生み、後者は作業を生むからです。
これは方法論への批判ではありません。セキュリティ製品だと主張したことは一度もなく、主張しているのは 「ガバナンスを取り付ける場所が明確に定義されたプロセスである」ことです。だからこそ、その取り付け方を きちんと設計する価値があります。
速いレビューでは埋まらない
反射的な対応は、既存のセキュリティレビューを維持したまま速くしようとすることです。この反射は問題を 誤診しています。
セキュリティレビューとは、特定の成果物に対する特定時点の記述であり、成果物が変わるほど価値が減衰します。 従来型デリバリーで機能していたのは、成果物が数か月安定していてレビューが数週間で終わったからです — 判定が届いた時点でまだ真だった。bolt はこの算術を反転させます。
だから 4 週間のレビューを 1 週間に短縮しても、構造的には何も買えていません。閾値を越えずに数値を 改善しただけです。必要なのは、成果物が動いても真であり続ける性質を継続的に検証することです。
各フェーズに足すセキュリティ
というわけで、これが 3 フェーズの横に並べるのではなく、フェーズに対応づけたオーバーレイです。 どの追加も方法論が既に持っている場所に取り付き、どの追加も特定の性質を買います。
Inception — コードより先に脅威モデルを置く。 セキュリティのテネットは要件分析の段階で、助言では なくブロッキングルールとしてオプトインします。脅威モデルは生成した後、お客様自身の技術リードと一緒に 歩きます。従来型のコンポーネントには STRIDE、プロンプトインジェクション・ツールの誤用・自律的な権限 拡大が脅威になる GenAI 部分にはエージェント対応の手法を使います。データ分類は後から指摘として届くの ではなく、設計を動かせる非機能要件に落とします。
ここで買っているのは文書ではありません。脅威を列挙するチームが、そのシステムを所有するチームである という状態です。自分が特定した脅威への緩和策を議論する人はいません。
Construction — 継続的に検証し、決してブロックしない。 脅威モデルはコードを書くエージェントの コンテキストに入れます。書いている瞬間に誰も読まない脅威モデルは、書類整理です。検証はファイル保存時に 走り、具体的な行と具体的な修正を返します。静的解析はコミット時にバックグラウンドで走り、指摘が キャリブレーションされるまでビルダーの関与はゼロです。敵対的テストは本番前に、動いているビルドに対して 走ります。
最も議論になる設計判断は、これらがコミットをブロックしないことです。理由はこうです。開発中にブロック すると、チームがコストを払って取り除いたばかりの摩擦を戻すことになり、摩擦の確実な帰結は統制が迂回 されることです。指摘は見せる。コミットは通す。
そして全体を貫く一つのルール — 人間がキャリブレーションするまで、指摘はブロックできない。誤検知は 苛立ちではなく統制の失敗です。理由のないブロック 1 件で、チームは「この指摘はノイズだ」と学習し、 その信頼は安くは戻りません。
Operation — ゲートは一つ、そしてループ。 継続的な検証を経た上で、ハードゲートはちょうど 1 つ だけです。未解決の critical / high を本番へ通さないこと。敵対的テストは動いているシステムに対して 継続します。そして本番で見つかった指摘はすべて、方法論自身のガードレール機構へ昇格させます。修正が レトロスペクティブのアクションアイテムではなく、恒久的なものになるように。
3 つのレイヤー、3 つの異なる問い
一歩引くと、上記のオーバーレイは 3 レイヤーのうちの 1 つです。そして「各レイヤーがどの問いに答えるか」で 分けることは、私にとって他のどの整理よりも多くの循環議論を終わらせてきました。
レイヤー 1 は手続き的で、無償です — 受け取り、証拠として頼り、そこで止める。レイヤー 3 はアーキテクチャ 的で、文書も整っています。エージェントごとのスコープ付き ID、エージェント連鎖で認可が拡大しないための ポリシー媒介の委譲、スキーマ検証、ガードレール。AWS はエージェント型ワークフローの最小権限と ガードレールとアラインメント統制について規範的ガイダンスを公開しており、その中で私が最も 引用する一文がこれです — 指示追従だけでは強制力にならない。
レイヤー 2 が隙間であり、「目の前の成果物は今日安全か」に答える唯一のレイヤーです。
統制は段落ではなくセンサーとして書く
方法論の中で最も過小評価されているのは、正しい強制の単位が既に含まれていること、そしてそれが散文では ないことです。
AI-DLC には センサー があります。宣言された深刻度を持ち、ステージゲートで発火し、名前の付いた失敗を 出す決定論的なチェックです。そのうちの一つは、文書内の実質的な主張に解決可能な出所タグがない場合、 ステージのクローズを拒否します。出所を助言として求めるのではなく、チェックとして強制しているわけです。
だからセキュリティの基準もその形で書きます。決定論的で、ゲートに紐づき、失敗時に名前が付き、動機と なった要件まで追跡できる。方法論が既に持つ強制力を継承し、他のルールと同じようにレビューでき差分も 取れるようになります。
代替案 — そして私が繰り返し目にするもの — は、ステアリングファイルに良いセキュリティ実践を長々と 記述した節です。それは約束です。センサーは制約です。ツール境界での同じ区別については別途 書きましたが、プロセス境界でも同じだけ鋭く成立します。
適正化にも同じ前例があります。あの CVE 対応スコープの規律をそのまま真似ればよい。プロトタイプには テネットと静的解析。顧客向けの GenAI サービスには敵対的テストとエージェント特有の脅威モデリング。 すべてのサービスに同一のセキュリティ構成を当てると、安い側では演劇になり、高い側では穴が残ります。
ブロックする権利を稼ぎ、一度だけブロックする
ゲートが 1 つであることは意図した数量です。どこでもゲートを置けば承認は反射的になります。どこにも 置かなければ楽観で出荷しています。後戻りできない地点に置けば、意味が保たれます。
どこにコストが出るか
センサーには所有者が必要で、その所有者はシニアです。レビュー工数をルールセットの保守へ変換したことに なります — より良い取引ですが無料ではなく、キャパシティを計画する人の目に見える形で存在します。
ノンブロッキング検証は、決めたチームがインラインの指摘を最後まで無視してゲートで壁に当たることを許します。 対策は早くブロックし始めることではありません。bolt の初日からゲートの中身が見えている状態にすることです。
unit of work ごとに脅威モデルを生成すると、誰も読まない量の脅威モデルができます。キャリブレーションが なければ、それは所有者のいないアラートチャンネルのセキュリティ版です。
そしてこの議論全体は、リズムが実際に速いことを前提にしています。四半期リリースのチームに賞味期限の 問題は当てはまりません。従来型のレビューで十分で、この設計は私が止めに入るべき過剰です。
機能しているかの見分け方
指摘の件数ではありません。兆候は 2 つです。
セキュリティエンジニアがコードレビューをやめ、センサーと脅威モデルを編集し始めること。これがこの設計 全体が買おうとしている時間配分の転換であり、組織的には最難関です — 自動化の問題の服を着た、リスキリング の問題だからです。
そして「このサービスは安全か」と訊かれたとき、誰も監査証跡に手を伸ばさないこと。手を伸ばすのは アウトカムのカバレッジと未解決の指摘であり、そのとき彼らは 2 つの問いのどちらに答えているかを言えます。
ここで説明した方法論は公開されています。ワークフロー、フェーズ定義、スコープ、センサーについては awslabs/aidlc-workflows を、ランタイムレイヤーについては上記の AWS ガイダンスを参照して ください。3 レイヤーの分割、賞味期限の議論、フェーズ別オーバーレイ、そして統制をセンサーとして書く という提案は私自身の立場であり、自動車業界および金融サービス業界のお客様との GenAI デリバリー プログラムで形成したものです。公式なガイダンスではなく、意見です。