AI-DLC のガバナンス 第3部：AI 支援のデリバリーが本当に安全かを見極める方法
ダッシュボードは緑です。スループットは上がっています。それでも全員が、1 年前より何かが手から離れて いると感じていて、それを示す数字を誰も指させません。指標が良いのに状況は悪い — この隙間が、この記事 の主題です。
手短に文脈を。AI-DLC は、定義されたプロセスの内側で AI エージェントが「作る」を担い、人間が 決められた地点で判断するデリバリーの進め方です。この記事は計器の話 です。実際に何を測るのか、そして針を動かすには何が要るのか。
ストーリーポイントは何のためにあったのか
アジャイル時代が与えた 2 つの計器の目的を正確に押さえておく価値があります。なぜ効かなくなったのかが そこで説明できるからです。
ストーリーポイントはキャパシティの計算単位でした。バーンダウンは、約束に対してそのキャパシティ が消費されていく予測でした。どちらも理由は 1 つ。足りなくなるのがキャパシティだったからです。
いま足りなくなるのはキャパシティではありません。エージェントを足せます。つまりどちらの計器も、潤沢 にあるものを測っています。チームが良い数字を報告しながら制御が効いていないと感じるのは、まさにこれ です。計器は嘘をついていません。誰も必要としていない問いに、丁寧に答えているだけです。
いま本当に希少なものは 2 つ。人の注意力と、ガードレールが効いているという根拠のある確信です。 測る価値があるものは、そのどちらかを測っています。
とくに重要な 2 つ
ボード上の他はすべて、この 2 つのための診断値です。
インテントあたりの人間の分数が、ストーリーポイントを置き換えます。 1 つの作業が消費した人間の 判断の分数 — 質問への回答、ゲートの承認、実際に読む時間。いまなお配給制の唯一の資源の計算単位です。 そしてこれが、そもそもプログラムが機能しているかを教えます。システムが成熟してもこれが下がらないなら、 あなたの自動化は作業を取り除かず移動させているだけです。私の経験では、ダッシュボードが全部緑の まま静かに失敗していく最も一般的な形がこれです。
リコールが、バーンダウンを置き換えます。 壁に貼るグラフです。本番に到達した問題のうち、すでに あったチェックが捕まえているべきだったものは何割か。
それで、どれが配線されているのか
もう一度ステータスの列を見てください。数字そのものより多くを語ります。
どのプラットフォームにも共通するパターン。消費は徹底的に計測し、有効性はまったく計測しない。 ステップの所要時間、トークン数、今日の価格でのコスト。ガードレールが何かを捕まえているかについての 数字は 1 つもありません。
セキュリティより先に財務のダッシュボードを作らせるのと同じ本能です。トークンには価格があります。 確信にはありません。だから誰もメーターを作らなかった。
しかしより有用なのは、黄と赤の分かれ方です。承認前に費やした時間は単に未配線なだけです。画面が 「どれだけ開いていたか」を記録すればよく、おそらく 2 週間の仕事で、承認が本物かどうかをすぐに教えて くれます。一方巻き戻し率、リコール、見逃しをチェックに変えるまでの時間は、そもそも算出 できません。誰も手が回らなかったから、ではなく。
リコールは分数で、これらのプラットフォームは分子しか集めていません。チェックが何を捕まえたかは わかります。何がすり抜けたかはわかりません。それを知るにはマージ後も見続ける必要があり、ライフ サイクルはコードを引き渡した時点で終わるからです。
つまりこれは新しい問題ではありません。欠けている運用フェーズが、別の帽子をかぶって 現れただけです。あの 1 つのループを閉じれば、リコールも学習時間も巻き戻し率もまとめて手に入ります。 このシリーズ全体で最もレバレッジの高い修正であり、指標の問いからここへ着地するとは思っていません でした。
では、どうやってリコールを動かすのか
チェックを足します。簡単そうに聞こえますが違います。「もっとチェックを書け」は方向であって技能では ないからです。その技能には名前があります。
1 本目の記事で、誰も配置しない役割を推しました。センサー作成者 — 誰かが手で繰り返して いるレビューを自動チェックに変えることを仕事にする人です。その人が実際に何を書くのかを説明します。
テストではなく、インバリアント
仕事の単位はインバリアントです。システムが到達しうるすべての状態で真でなければならないもの。 誰かがたまたま思いついた入力に対して、ある火曜日に一度だけ真だったもの、ではなく。
この区別がすべてです。
- このログインは誤ったパスワードを拒否するはテストです。標本を取ります。書き出したケースに ついてだけ教えてくれます。
- このシステムのどの部分も、暗号化されていない接続でパスワードを受け付けないはインバリアント です。列挙しなかったケースまで覆います。
ゆうべ 40 件のエージェント実行があなたのコードに触れたなら、価値があるのは 2 つ目の言い方だけです。
下にある構造、そしてそれが元を取る理由
形式検証ではよく踏み固められた地面で、そのまま移植できます。ある性質がインバリアントであるためには 3 つが成り立つ必要があります。最初に真であること。どのステップもそれを真のまま保つこと。 そして真であることが実際に安全を意味すること。
そのうえで AI-DLC が何かを見てください。ステップの連なりです。各ステップが状態の変化です。
ステップ境界でのチェックは、「どのステップも真のまま保つ」という条件そのものです。比喩では ありません。数学者の代わりに機械が果たしているだけで、義務は同一です。
これはプラットフォームの記事で私が急ぎすぎた点も正します。私は、チェックが継続的でなく ステップ境界でしか発火しないことを批判しました。この枠組みでは境界こそ正しい場所です。ステップが 変化の単位である限りにおいて。批判が効くのは、エージェントがステップの途中で性質を破れる場合だけ で、そのときは境界が粗すぎるので、チェックは作業のより近くに置くべきです。両方とも正しく、整った ほうの話だけを残すより、こう書くほうを選びます。
インバリアントはどこから来るか：あなたのポリシーから
ここが実際の作業で、聞こえるより面白い。セキュリティポリシーを取り出し、各行をインバリアントとして 言い直してみてください。起きることはきっかり 3 つです。
綺麗に変換できてチェックを書く。あるいはそれまで持っていなかった定義を発明してはじめて変換できる — そしてその定義こそが価値ある産物です。「機微データ」が共通の感覚ではなくリストを意味するように なるからです。あるいはまったく変換できない。何をもってしても反証できないからで、そのとき、何年も 監査の根拠にしてきた行が、ポリシー番号の付いた心情だったと学んだことになります。
良いインバリアントの条件。最も真剣にこれをやっている人々 — 間違えればその日の午後に金銭被害が出る スマートコントラクトの世界 — から借ります。
- まず普通の一文で書く。 一文で言えないなら、まだインバリアントではありません。コードを書いても 手に入りません。
- 「〜しない」で言う。 「決して」「常に」。肯定形の要求は積み上がります。否定形は綺麗に組み合わ さります。
- 反例 1 つで死ぬこと。そして評価コストを気にしなくていいほど安いこと。
- 判断が要らないこと。 決めるのに意見が要るならそれはレビューであってインバリアントではあり ません。それ自体は構いません。ただゲートには置かないこと。
- 少数から始める。 成熟した形は、荷重を受ける少数のルールであって、壁一面の一覧ではありません。
これは傍流の技法ではありません。AWS 自身の自動推論がまさにこれを規模でやっています。 Zelkova はアクセスポリシーを論理式に変えてソルバーで検査し、同じ系統のツールが社内で、 各サービスがセキュリティインバリアントを守っているかの検証に使われています。セキュリティの性質は 段落ではなく機械検査可能な主張であるべきだという考えは、賭け金が高いところではもう主流です。
エージェントがいると、なぜより重要になるのか
理由は 2 つ。2 つ目は意外でした。
1 つ目は量です。ひと晩に 40 の成果物を生むエージェントは、誰も書き留めなかった性質を破る機会が 40 回あるということ。人間の速度の開発には気づく時間がありました。これにはありません。
2 つ目は、モデルがあなたの代わりにルールを保持できないことです。Veracode の 2026 年の分析がまさにここに着地します。データがどこから来て、何が変え、各段階がセキュリ ティ上の性質を保ったかを追うのは、現行のモデルが持続するようにできていない種類の推論です。だから ルールはプロンプトの中には住めません。外側にあり、機械が検査し、ステップごとに再検査される必要が あります。
そしてこれがループを閉じる
私の中ですべてが噛み合った部分です。
チェックがインバリアントとして書かれているなら、リコールはインバリアント集合の完全性を測る指標に なります。 そしてインシデント後の問いは、漠然とした「チェックが捕まえるべきだったか」から、答えの 出る「どのインバリアントが欠けていたのか、弱すぎたのか、置き場所を間違えたのか」へ鋭くなります。 この問いには成果物という答えがあります。
こうして 1 つの語彙で閉じます。ポリシーはインバリアントになり、インバリアントはチェックになり、 チェックはリコールを生み、リコールの欠落が次のインバリアントを名指しする。 センサー作成者とは このループを回す人であり、「基準を引き上げる」は激励の言葉であることをやめて、差分になります。
これの代償
リコールは、最初に算出したとき悲惨な数字になります。 しかも遅行指標なので、原因を直したあとも 四半期のあいだ悲惨なままです。悪い数字を罰する場所に導入すれば、見栄えがよくなるまで静かに定義が 書き換えられます。レビューの 1 時間に予算を付け、最初の半年は目標値を置かないでください。
そのレビューの 1 時間を、誰かがやらなければなりません。 本番で見つかった問題 1 件ごとに、既存の チェックが捕まえているべきだったかを人が判断します。1 件およそ 1 時間、システム全体で最も価値の高い 1 時間であり、四半期が忙しくなると必ず最初に削られます。
完璧なリコールを狙わないでください。 誰かが犯したことのあるすべてのミスにブロッキングチェックを 置き、誰も通り抜けられないプロセスを作り、1 か月でエンジニアに迂回路を探させるやり方です。
インバリアントの数を目標にしないでください。 四半期のうちに骨抜きになり、誰にも破れないルールが 50 個できます。数字にすべきはポリシーのカバレッジとリコールで、個数は虚栄です。
もう 1 つ、これは本物の代償です。 インバリアントを追加すると、それなしに承認されたものすべてが 遡って未検証になります。ルールの集合はバージョン管理され、マージ済みの作業は照合されたバージョンの 分だけしか検査されていません。あなたはいま再検査の問題を抱えています。
月曜にやること
- リコールを 1 つ、手で出す。 直近で本番で見つかった 10 件について、「既存のチェックが捕まえて いるべきだったか」を問う。その割合があなたのリコールです。予想より悪く、どのダッシュボードより 有用です。
- セキュリティポリシーの 5 行を「〜しない」文に変換してみる。 変換できない行に注目してください。 その一覧のほうが、できた 4 行より面白い。
- 承認前に人がどれだけ時間をかけているかを測る。 ツールがそれを答えられないなら、それ自体が 発見です。
要するに
アジャイルの計器は「十分に作れるか？」に答えていました。良い答えでしたし、その問いは機械が片付け ました。
その下にある問い — 取り返しのつかないことについて、人の注意力を十分に安く使って、十分に確信を 持てるか? — には、計器がほとんどありません。それを作るのがいま面白い仕事で、始まりはこの記事の 2 つの数字と、週に 1 時間の正直な作業です。
出典と、それぞれの使いどころ
- How AWS uses automated reasoning to achieve security at scale — セキュリティの性質を 段落ではなく機械検査可能な主張として扱うことについての、最も明快な公開資料。
- Security Invariants or GTFO — Alex Smolen。セキュリティプログラムを「許容される 個数がゼロだけであるインバリアント」として表現する主張。短く、私の中に残りました。
- Spring 2026 GenAI Code Security Update — Veracode。モデルがあなたの代わりにルールを 保持できない理由、したがってモデルの外で強制すべき理由。
この分野の仕事は、進むにつれて書いています。こうしたプログラムを測ろうとしている方は、 LinkedIn で連絡が取れます。私がメンテナンスしているツールは shenril と BlueSquadron にあります。