【ITニュース解説】Why an AI-written change waits for CI evidence

システムエンジニアを目指す皆さんにとって、現代のソフトウェア開発において「コードの変更」がどのように安全に進められるかを理解することは非常に重要だ。特に最近では、AIがコードを書く能力を持つようになり、そのプロセスはさらに複雑になっている。今回のニュース記事は、AIが書いたコードの変更が、見た目には完璧に見えても、なぜすぐにシステムに組み込まれる（マージされる）わけではないのか、その背景にある「継続的インテグレーション（CI）」という自動検証の重要性を教えてくれる。

AIが書いたコードは、人間が見ると非常に完成度が高く見えることがある。コード自体が整合性が取れていて、その変更意図の説明も非常に説得力がある。さらに、もしレビュー担当者からの修正依頼（コメント）があったとしても、AIはそれらを迅速に解決してしまう。これだけ見ると、すぐにでもシステムに組み込めるように思えるだろう。しかし、この記事は、そうした見た目の完璧さだけでは不十分だと指摘している。なぜなら、実際にそのコード変更がシステム全体の中で、想定通りに、そして安全に動作するかどうかは、コードの見た目だけでは判断できないからだ。これを確かめるのが「デリバリーパイプライン」と呼ばれる、コードが開発からリリースされるまでの一連の自動化された検証プロセスだ。

この経験から、コード変更をシステムに組み込む際の最終的な承認ポイント、つまり「ゲート」の考え方が変わった。これまでは、特に問題がなければ承認されるという考え方もあったかもしれないが、今では「フェイル・クローズド（fail closed）」という原則が採用されている。これは、明確に「問題がない」という陽性の結果が、誰の目から見ても独立して確認されなければ、そのコード変更は絶対にシステムには組み込まれないという意味だ。もし、この確認に必要なCI（継続的インテグレーション）の証拠が「見つからない」「不完全である」「古くなっている」「検証できない」といった状態であれば、その変更はシステムに組み込まれることなく、ずっと待機し続けることになる。「検証されていないなら、まだ準備ができていない」という非常にシンプルな原則である。

なぜ、AIが自分で書いたコードを、AI自身が「OK」と判断してはいけないのだろうか。それは、「作成」と「承認」という異なる役割は、同じ存在が担うべきではないという考え方に基づいている。コードの作成プロセスは、「要求された内容が正しく理解され、もっともらしい方法で実装されたか」を問うものだ。しかし、CIが行う質問はまったく違う。「このコード変更は、リポジトリ（コードを管理する場所）で設定された様々なチェックを、制御された（予測可能な）環境でちゃんと通過したか？」という、より客観的で厳密な検証を求めるものなのだ。AI自身が自分の書いたコードの「思考プロセス」や「編集内容」、「ローカル環境でのテスト結果」をいくら確認しても、それはあくまで「作成者自身の視点」でしかない。これは、評価されるべきもの（コード）と、その評価（承認）が、同じ「信頼の境界」の中に存在している状態であり、独立した検証とは言えない。

CI証拠がコード変更の承認をサポートするためには、いくつかの厳しい要件を満たす必要がある。具体的には、次の4つの点が明確に示されなければならない。第一に「現在検討中のコード変更そのもの」が特定されていること。第二に「それに関連するCIパイプラインの実行記録」が明確であること。第三に「設定された全ての必須チェックの結果」が示されていること。そして第四に「作成者の主張とは独立して確認された、検証可能なステータス」が記録されていることだ。例えば、以前の別のコード変更がCIをパスしたとしても、それは現在のコード変更を検証したことにはならない。また、全てのチェックが完了していない「部分的な結果」も、必要なチェックが全てパスしたことを示すものではない。さらに、開発者のローカル環境で「テストがパスした」という結果や、AIが「テストはパスするだろう」と予測したとしても、それらは独立した客観的なCI証拠の代わりにはならないのである。

ニュース記事では、記録されたデリバリー活動のうち、93.2%の証拠レコードが検証され、その全てが独立した検証として分類されたと報告されている。リスクのある作業の検証には、AIモデル（claude-opus-5）も使用されるが、このAIの判断をもってしても、もしCIパイプラインの証拠そのものが不足していれば、「合格」とすることはできない。ただし、この93.2%という数字には、いくつかの限界があることも記事は正直に認めている。例えば、「証拠レコード」が具体的に何を指すのか、その証拠がどのように特定のコード変更に紐付けられるのか、あるいは「独立した検証」と判断するための基準が何なのかといった詳細が、この情報源からは不明確だ。そのため、この数字は、あくまである組織の「運用上の報告値」であり、誰でも同じように測定・再現できるような厳密なベンチマークとは言えないのである。

それでも、コード変更の承認「ゲート」の仕組み自体は非常に明確だ。もし、コードの実装とレビューが完了していても、必要なCIの結果が得られないのであれば、それまでの作業がどれほど進んでいようとも、成功したと判断することはない。コード変更はただひたすら待機する。この厳格なルールは、作業の流れを一時的に止める可能性もあるが、それ以上に重要な役割を果たす。例えば、インフラのちょっとした不具合や、CIシステムから送られるべきシグナル（信号）の欠落といった問題が、本来は失敗であるにもかかわらず、「開発成功」として誤って報告されるのを防ぐのだ。これにより、責任者は、CIの全てのチェックをパスした変更と、まだ証拠を待っている変更とを明確に区別でき、個々のケースによって品質保証のレベルが曖昧に変化してしまうことを防げる。

コードを管理する「リポジトリ」がどれだけCIをサポートできるか、という「リポジトリの準備状況」も、この問題を複雑にしている。記事によると、CIが存在するリポジトリの割合は85.7%であり、コミットされた秘密情報（パスワードなど）のチェックは28.6%、デフォルトブランチの保護は14.3%と、その導入状況に大きなばらつきがあることが示されている。これらの数値も定義が曖昧な部分があるものの、リポジトリ側の準備が不十分な場合、信頼性の高いCI証拠を生成したり、それを信用したりすることが難しくなる。しかし、だからといって、個々のコード変更に対する厳格な検証ルールを緩める理由にはならない。必要な証拠が手に入らない、そのコード変更に確実に紐付けられない、あるいは独立して検証できないといった状況であれば、コード変更は先に進めないという原則は揺るがない。

また、コードに問題が見つかった際の「修復」プロセスにも一定の制限がある。ほとんどの変更は一度の修正で済むが、一部の変更は複数回の修正（「修復サイクル」）が必要となり、中には設定された「修復予算」を使い果たしてしまうケースもある。ここでも「修復パス」や「修復予算」といった用語の具体的な定義は示されていないが、重要なのは「プロセスが設定された制限内で、受け入れ可能な証拠を生成できない場合、それ以上のAIエージェントによる活動は、信頼性の向上にはつながらない」という点だ。この制限は、未解決のコード変更が、無限に修正と再評価のループに陥ってしまうことを防ぐ役割がある。

ソフトウェア開発における「計画」「コードレビュー」「CI（継続的インテグレーション）」は、それぞれ異なる種類の質問に答える役割を担っている。コードを書く前の「計画」は、どんな機能を作るか、どう実装するかを明確にする。人間による「レビュー」は、論理的な問題点、危険な仮定、要求仕様との不一致などを見つけ出す。しかし、どちらも「実際にコードがきちんとビルドされ、テストが通り、既存のシステムと問題なく結合できるか」を保証するものではない。一方、CIパイプラインが全てのテストに「グリーン（成功）」と表示されたとしても、それは「設定されたチェックはパスした」ということを記録するだけであり、必ずしも「ビジネス上の要求がチェックの範囲を超えて完全に満たされているか」までは保証できない。それぞれが補完しあう関係にあるのだ。

記事は、自動化されたレビューが多くの問題（「所見」）を発見したことも伝えている。そのうち57.3%が「ブロックする（深刻な問題）」、29.8%が「メジャー（主要な問題）」に分類された。これらの所見を解決すれば、既知のレビュー上の問題は解消されるが、コード自体が変更されたことになるため、その変更に対して再び新しいCI証拠が必要となる。計画の段階でも、承認された計画が存在する方が、後の初版受理率が高いという関連性が示されているが、ここでも定義の曖昧さから、あくまで「関連性」であり「因果関係」は断定できないとされている。計画はあくまで「意図された作業」を記述するものであり、実装が要求されたチェックをパスしたことを証明するものではないからだ。

最終的に、記事は、提示された多くの数字（パーセンテージなど）には限界があることを繰り返している。それらの数字の根拠となる詳細なデータや定義、測定期間などが不足しているため、一般的に適用できる「ベンチマーク」として使うことはできない。あくまで、特定の組織における「運用上の観測結果」と捉えるべきだ。しかし、このデータ不足の状況であっても、開発チームの今後の焦点は明確だ。最も導入率が低かった「デフォルトブランチ保護」や「コミットされた秘密情報のチェック」、そしてAIエージェントのツール改善に力を入れる。また、証拠のギャップやレビューの所見の分類方法を厳格化し、不明な状態がいつの間にか「承認」されてしまうような事態を防ぐ。

まだ、コード変更とCI証拠の紐付け方や、「独立性」の評価基準など、詳細に定義すべき点は多く残されている。しかし、今のところ、コード変更を承認する「ゲート」は意図的に非常に厳格な姿勢を保っている。もし、必要なCIパイプラインの結果が「存在しない」「そのコード変更に確実に関連づけられない」「独立して検証できない」のどれか一つでも当てはまれば、そのコード変更はシステムに組み込まれることなく、ひたすら待ち続ける。これは、AIがコードを書く時代においても、ソフトウェアの品質と安全性を確保するための、揺るぎない基本的な原則なのである。