2026年8月1日

自走する仕組みを、どこで検証するか

AIに任せる範囲が広がると、経営が見るべき対象は成果物から、成果物を生む仕組みへ移る。だがその仕組みは、壊れて止まるとは限らない。壊れたまま正常を報告し続ける。自社の開発で1週間に4件見つけた事例から、検証すべき4つの点を示す。

Anthropicは自社の開発工程を説明する中で、この数年の変化を一文で言い切っている——「セキュリティ技術者の仕事は、不具合を監視することから、ループを監視することへ変わる」。見るべき対象が、成果物から、成果物を生む仕組みへ移ったということだ。

問題は、その仕組み自体に落とし穴があることにある。仕組みは、壊れて止まるとは限らない。壊れたまま、正常を報告し続ける。我々は自社の開発で、1週間のうちにその状態を4件見つけた。統制の仕組みを作ることを生業にしている組織で、である。

本ブリーフィングが扱うのは1点。経営者と事業責任者がPMOと連携し、AI稼働を前提に組織とプロダクトを管理するとき、「自走する仕組み」の何を検証すべきか。

主要な判断: 統治対象は成果物から仕組みへ移った。仕組みは「動いている」ことを自ら証明できなければ、統制とは呼べない

状況: AI前提の運用では、統制の数は減らない。減るのは、統制を見ている人間のほうである

いま2つのことが同時に起きていて、その組み合わせが効いている。

1つはAIの実装が進んだこと。報告作成、統制レビュー、リスク分析——PMOの定型業務は順に自動化されつつある。もう1つは、統制それ自体が意図的に軽くされていること。報告は短く、様式は薄く、統制水準は複雑性に見合う程度に。どちらも正しく、どちらも遅すぎたくらいだ。

だが重ねると、特定の露出が生まれる。統制ごとに見ている人間は減り、自動で回る統制は増え、深く覗き込まないことが方針として選ばれている。 運用としては健全である——統制が実際に動いていれば。動かなくなったことを教えてくれる仕組みは、このモデルのどこにも入っていない。

そして、静かに止まった統制は、正常に動いて何も見つけなかった統制と見分けがつかない。健全な組織では、ほとんどの統制はほとんどの期間、何も見つけない。沈黙こそが期待される出力なのだ。

ここに、PMOの側の装備の問題が重なる。業界標準の教育課程を見ると、たとえばHouse of PMOの「Practical AI Skills for the PMO」は、受講要件として Microsoft Copilot・ChatGPT・Google Gemini のいずれかへのアクセスを挙げ、統制・保証レビューやプロンプト集を扱う。課程自体は「自動化ではなく拡張に焦点を当てる」と明言しており、その範囲では正しい。問題は、拡張の話が終わった先にある。自社の開発や運用が「人が指示しなくても回る仕組み」に移った瞬間、ブラウザの対話画面から統制を効かせるという前提そのものが届かなくなる。仕組みを検証するには、仕組みの内側に入る必要がある。

なお、ここで流行に振り回されないことが要る。「ループはもう古い、次はグラフだ」といった売り文句は今後も出続ける。監視すべきは型の名前ではなく、型そのもの——エージェントのループ、権限分離、単一目的のアイデンティティ、ダッシュボード——である。

分析: 自走する仕組みは、壊れて止まるわけではない。壊れたまま正常を報告し続ける

検証点の図解 — 「実行して何も見つからなかった」統制と「そもそも実行されていない、あるいは別の対象を見ていた」統制は、同じ「異常なし」という出力になる。両者を切り分けるのが4つの検証点

我々は自分たちの最初の顧客なので、証拠は自社の開発から採る。4つの検証点を、実際に起きたことと対にして示す。

1. その統制に「実行された証拠」を出させられるか

設定が正しいことと、統制が動いていることは別である。

我々は開発基盤に対し、機密情報検知の追加設定を有効化するよう要求した。要求は成功を返した。設定は無効のままだった。別の日に単発で再実行し、状態コードではなく応答の中身を読んで、ようやく気づいた。状態コードだけを見る——つまり、スクリプトが見るのと同じ見方をする——限り、この統制は「有効」として記録され続ける。

同種のものはもう1つあった。導入手順が正しく設定を書き込みながら、その設定のせいで検査そのものが1つも読み込まれない、という状態である。導入時の出力は、最後まで成功を報告していた。AIが検査を実装し、有効化しないまま「検査は問題なく機能している」と報告する事故は、これと同じ形をしている。

2. 「該当なし」と「見ていない」を分離できているか

依存関係の脆弱性通知を有効化したところ、指摘はゼロだった。健全に読める。健全ではなかった。その通知は、対象を一度も解析していなかった。解析は特定の操作を契機に走る設計で、その操作がまだ起きていなかっただけである。次の変更が入った瞬間、ゼロは約1分で3件に変わった。有効化直後のゼロは、無害なゼロと同じ顔をしている。

同じ週、ファイル群が正しく複製されたかを検証する手順が、両方の観点で「合格」を報告した。その手順は、存在しない場所を検証していた。環境変数が2つの工程で違う値に解決されていたためである。対象の不在が、正常時と同じ出力になっていた。正しい場所で再実行すると本当に合格したが、最初の報告は、すべてを保証したと述べながら何一つ保証していなかった。

3. 検知の方式そのものが、想定する失敗を捉えられるか

これが最も高くつく問いである。統制の数ではなく、統制の視野の問題だからだ。

我々の公開リポジトリで、ある識別子が意図した面とは別の面に現れた。原因を追うために設定ファイル群を調べ、すべて正しいことを確認した。だがその操作は、設定を経由せず値を直接渡していた。つまり設定を読む検査は、何が起きていようと、この失敗を検知できない。検査は正常を返し、正常であることは正しく、それでも問いには答えていなかった。「調べた結果、異常なし」ではなく、「調べた場所に、答えはそもそも存在しない」。

同じ形の、より高くついた例がある。公開した製品に対し、必須の自動検査9件がすべて緑だった。その製品は、顧客が導入する手順で導入すると即座に起動に失敗した。検査は「我々がビルドしたもの」を検証していて、「顧客が受け取るもの」は誰も検証していなかった。現在は、成果物を白紙の状態から導入して実際に起動させる検査を追加してある。それこそが、欠けていたために不良品が出荷された統制だった。

4. 変更を重ねた後も、その統制はまだ生きているか

初期に動いていた統制は、変更が積み重なるうちに黙って死ぬ。死んだことは、誰かが実際に鳴らしてみるまで分からない。ここに定期点検の対象を置いていない組織は、統制の生死を運に委ねている。

評価: これはAI固有の問題ではない。オフショア開発とPMOの忖度で、我々が既に知っている構造である

新しさに惑わされないほうがよい。「報告は正常、実態は未実施」はオフショア開発でもマルチベンダー統制でも繰り返されてきた。遠くの実行主体、確認しづらい実態、整った報告——条件が揃えば、実行主体が人間かAIかは本質ではない。

PMOの文脈ではもっと馴染み深い。見積、リスク分析、完了報告といった意思決定の材料に忖度が混ざることで状況が悪化する事例は、繰り返し確認されてきた。悪意ではない。期待に沿う出力のほうが選ばれやすい、というだけのことだ。

AIは、これを不誠実さなしに行う。空の結果と未実施の結果を区別する手段を持たないまま、善意で、自信を持って、整った形式で報告する。「自信があり、整っていて、中身がない」——これが特徴的な出力である。そして中身に対する下流の品質検査は、すべて通過する。検査すべき中身が存在しないからだ。

だから、流行を追うほど破綻する。むしろオフショア開発とマルチベンダー統制の学びを持ち込み、基本に返るほうが、本来的な意味での仕組み検証に早く到達する。 遠隔の実行主体に対して我々が昔から要求してきたもの——実行の証拠、抜き取り検査、否定的な結果の実物——は、そのままAIエージェントに対する要求になる。

提言: 統制はプロンプトではなく環境と構造に作り込み、「不在」を大きな音で鳴らす

自走ループへの介入点の図解 — 計画・指示、エージェントの実行、統制の実行、報告と意思決定という循環に対し、4つの検証点がそれぞれどの地点で介入するかを示す。プロンプトの層ではなく、環境と構造の層に統制が置かれる

我々自身がたどった移行を先に述べておく。最初は指示の改善で品質を上げようとした。届かなかった。指示は再現されず、監査されず、次の対話に持ち越されない。良い指示は良い一回を生むが、統制にはならない。だから作業を、指示の層から環境と構造の層へ移した——検査は環境が実行し、権限は構造が分離し、記録は人が書かなくても残る。プロンプト集は統制ではない。これは我々の反省であると同時に、AI導入計画に組み込むべき順序でもある。

そのうえで、経営とPMOが明日から使える問いを5つ挙げる。新しい道具も、実装の理解も要らない。

  1. 「この統制が最後に『否』を返したのはいつか」 生涯にわたり一度も否定的結果を出していない統制は、壊れているとは限らないが、動作が未実証である。実証されるまでは未実証として扱う。この一問で、我々の5件のうち3件は捕まえられた。
  2. 「設定ではなく、実行の証拠を見せてほしい」 設定は設定画面が示す。実行は、時刻・件数・記録行が示す。両者の隙間に、我々の5件はすべて住んでいた。実行を示せない統制は、それが答えである。
  3. 「我々が作ったものを検証しているのか、顧客が受け取るものを検証しているのか」 別物である。出資者が実際に開く報告書、役員が実際に見る画面、顧客が実際に導入する成果物——検証すべきはそちらだ。
  4. 「空の結果は『正常』と表示されているか、『不明』と表示されているか」 最も安価な構造的対策である。指摘ゼロの表示と、データなしの表示は、見た目から異なっているべきだ。既定でそうなっている道具はほとんどない。要求すれば済む。
  5. 「統制を軽くしたとき、何を外したのか」 統制の軽量化は正しい。罠は、統制を残したまま注意だけを外すことにある。それは、ここで述べた「存在するが不活性」な状態そのものだ。誰も見ない統制を残すより、正直に外すほうが安全である。少なくとも全員が現在地を把握できる。

PMOのAI導入計画には、1行を足しておきたい。自動化する統制ごとに「本物の否定」がどう見えるかを事前に定義し、実際に一度、それを見ること。新しく自動化した統制がまだ何も指摘していないなら、それが機能するかどうかは、まだ何も分かっていない。分かったのは、それが静かだということだけである。

最後に、解決していない課題も記しておく。設定を迂回する操作は、我々の既存のどの検査からも見えない。ファイルの中身を読む検査にも、記録文を読む検査にも、成果物を読む検査にも届かない。機械的に捕まえるなら、送信の瞬間に別の対象を見る仕組みが要る。それを作る価値があるかは、まだ判断していない。この種の失敗は、気にかけることでは捕まらない。不在を成功と見間違えられないようにする仕組みによってのみ捕まる。

出典: Anthropic「How Anthropic secures its AI-native software development lifecycle」、House of PMO「Practical AI Skills for the PMO」course outline (v2.0)。本稿の事例はすべて、自社の公開リポジトリ logic の開発で実際に起きたものであり、その履歴に記録されている。