AI は増幅装置である。では、何を増幅しているのか？

ダッシュボードには現れない、静かなギャップ 

今、あなたのダッシュボードはおそらく好調に見えているはずです。アウトプットは増加し、チームは以前より速く出荷できています。そしてそのスピードの多くは、AI がコードを書き、テストを提案し、ドキュメントの草案を作成していることによるものです。数字の上では、まさに望んでいた通りの結果です。

しかし、その数字の裏には、どのグラフにも表れないものがあります。それは、開発の速さと、リリースしている成果物への確信の強さとの間にあるギャップです。そしてそのギャップは、スプリントを重ねるたびに広がっていきます。

安全性が重視される製品やシステムであればあるほど、まさに今、AI について理解しておくべきことがここにあります。

AI は、二つの側面から同時にやってきた 

自動車、医療機器、あるいは航空宇宙といった分野で開発をリードしているなら、AIはあなたの世界に、二つの側面から同時に入り込んできたはずです。

一つは、皆さんの製品そのものです。

市場は、状況を認識するシステム、状況に応じて適応するアルゴリズム、そして自ら判断して動くインテリジェントな自動化を備えた AI 機能を求めています。競合他社がすでにこうした機能を提供している以上、立ち止まるという選択肢はありません。

もう一つは、皆さんの開発現場です。

組織内の方針の有無にかかわらず、エンジニアはすでに AI を使ってコードを書いています。生産性は向上しました。それをやめさせるのは現実的ではありませんし、そもそも正しい判断でもありません。

つまり、AI を導入するかどうかを選ぶ段階はすでに終わっています。その選択はすでになされているのです。

本当に問われるべきは、今のソフトウェアの検証方法が、この二つの変化に同時に対応できるかどうかです。

AI は問題を生み出すのではなく、既存の問題を加速させる

ここが、多くの人が誤解しているポイントです。AI はコードベースに新しい種類の不具合を持ち込むわけではありません。元々あった傾向を、そのまま加速させるだけです。 

エンジニアが一日をどう過ごしているか考えてみてください。開発時間のおよそ半分は、コードを変更する前に既存のコードを理解することに費やされています。私たちはこれを理解税 (understanding tax)と呼んでいます。これは「コードの理解にかかるコスト」で、チームの全エンジニアが日々支払っています。

ここに AI が加わると、何が起こるでしょうか。 

アーキテクチャが検証され、ルールや規格が自動的に強制されている環境であれば、AI が生成したコードは、すでにチームが理解している構造の中に収まります。コードの理解にかかるコストは管理可能な範囲にとどまり、AI はそのまま加速装置として機能します。 

逆の状況では、まったく反対のことが起こります。 

アーキテクチャが2年前のスライド資料の中にしか存在せず、ルールや規格の遵守がその日レビューを担当する人の能力や注意力に依存しているとしたら、AI が生成したコードは、すでに追いきれないほど複雑だったものにさらに積み重なっていきます。生成には数分しかかからなかったコードでも、それを理解するには何時間もかかるようになります。自分たちのシステムを理解するコストは、どんどん上がっていきます。

同じツールでも、結果は正反対です。違いを生むのは、その下にある開発基盤の状態だけです。 

これが、ここでいう「AI は増幅装置」という言葉の意味です。AI はコードベースの良し悪しを判断しているわけではありません。ただ、すでに向かっていた方向への進みを速めるだけです。 

ゆっくりとした崩壊は、どのように起こるか 

ソフトウェアの劣化は、予測可能な3段階のカーブをたどります。 

フェーズ1：管理可能な段階 

技術的負債は存在するものの、管理可能な範囲にとどまっています。近道や場当たり的な対応はあっても、誰かがそれで頭を悩ませるほどではありません。チームは開発スピードを維持できています。 

フェーズ2：指数関数的に悪化する段階 

複雑さは、誰も追いつけないほどの速さで増大していきます。変更を加えるたびに、前回よりも多くの調査や分析が必要になります。脆弱な開発基盤の上で AI が最も大きなダメージを与えるのが、まさにこの段階です。AIは、開発チームが消化できる以上の速さでコードを増やしていきます。 

フェーズ3：破綻する段階  

コードベースは、安全に変更を加えられるとは誰も確信できないほど複雑になります。優れた製品はこうして終わりを迎えます。顧客が離れたからではなく、ソフトウェアが変更に耐えられなくなったからです。

フィジカルAI（現実世界で動作する自律システム）製品を開発しているなら、フェーズ2はすでにリスクそのものです。そしてフェーズ3は、製品リコールや、規制当局による措置を招きかねません。 

ほとんどの組織が陥る、誤った二者択一 

AIが登場したとき、多くの組織は二つの極端な対応のどちらかを選びました。

選択肢1：慎重すぎる対応（Paralysis） 

規格適合を守るためだと言ってAIの利用を制限しました。自分たちは慎重に行動しているのだと言い聞かせる一方で、より迅速に開発を進める競合に後れを取り、市場は先へ進んでいきました。 

選択肢2：無謀な対応（Recklessness） 

AIを積極的に導入し、開発スピードの向上を喜び、既存の開発プロセスでも対応できるはずだと思い込みました。しかし、実際にはそうはなりませんでした。

検証すべき項目は、誰にも気づかれないまま裏側で積み上がり、人間だけのチームでは到底管理しきれないペースでリスクが蓄積していきました。

どちらの対応も、同じ前提に立っています。「スピードと安全性はどちらか一方しか選べない」という前提です。

しかし、そんなことはありません。第三の道があり、それはより鋭い問いから始まります。あなたが求めるのは、どのようなスピードなのか？

手抜きや近道によるスピードは、未来からの前借りにすぎません。検証を省いたスプリントは、一つひとつが後で大きくなって返ってくる負債を積み重ねていきます。一方、信頼できる開発基盤から生まれるスピードは、逆方向に複利で効いてきて、積み重なるほど大きな効果を生みます。ソフトウェアの検証に投資した分だけ、その後に続く全てのリリースで報われるのです。 

どちらを選んだとしても、AIはその差をそのまま増幅します。 

基盤が持ちこたえられないことを示す4つの警告サイン 

自社の開発基盤が脆弱かどうかを知るために、コンサルタントに頼る必要はありません。以下に4つの警告サインを挙げます。多くのリーダーは、少なくともこのうちの一つには、すぐに心当たりがあるはずです。 

警告サイン1：目に見えない検証待ちが積み上がっている

開発は加速する一方で、検証が追いついていません。コードが完成してからリリースできる状態になるまでの間隔は、スプリントを重ねるたびに広がっていきます。それはダッシュボードには決して現れませんが、実際に出荷しようとしたその週になって、「開発完了」と「リリース可能」の間に、まだどれだけの作業が残っているかに初めて気付くことになります。 

警告サイン2：ちょっとした変更のたびに、全面的な再検証が必要になる 

AIは一見すると単純できれいな修正案を提示してくれます。しかし、検証されたアーキテクチャがなければ、その変更の影響範囲が意図した範囲に留まっていることを実証できません。どこに影響するか分からない変更は、結局すべてをテストする必要に迫られます。本来なら数日で終わるはずの作業が数週間かかるようになり、AI による生産性の向上は、再検証に費やす工数によって相殺されてしまいます。

警告サイン3：規格適合を示すエビデンスが「発掘作業」になっている

監査が近づくと、チームは資料を掘り起こす作業を始めていませんか？必要な文書を探し出し、それがまだコードと一致しているかを確認し、要件・設計・テストをつなぐトレーサビリティを一からを再構築する。それは本来であれば、必要なときにその場で生成できるレポートであるはずなのに、数週間分の手作業を費やしてしまうことになります。 

警告サイン4： アーキテクチャが誰かの頭の中にしか存在しない

あるシニアエンジニアは、システム全体がどう組み合わさっているか、どの部分がどこと通信してよいのか、そしてその理由を理解しています。では、あるコンポーネントが別のコンポーネントに影響を与えないことを、誰かが実際に実証できるか尋ねてみてください。 

その場が静まり返るなら、皆さんの安全上の境界は、コードとしてではなく、人の記憶として存在していることになります。AI は、最も優秀なエンジニアの頭の中にあるものにはアクセスできません。そのため、その境界を越えてでも、コードを「とにかく動くように」してしまいます。 

たった一つの境界が、なぜこれほど重要なのか 

たとえば、アーキテクチャ設計書に「コンポーネント A はコンポーネント B を絶対に呼び出してはならない」と定義されているとします。これは単なるスタイルの好みではありません。 

ISO 26262 のような安全規格のもとでは、その境界は、A が重要度の低い部品であり、Bがシステムの中でも特に安全性が重視される部分の一つだからこそ設けられている可能性があります。両者を隔離しておくのは、A の不具合が B を危険にさらすことがないようにするためです。 

これは Freedom from Interference（FFI / 干渉からの自由）として知られています。 

しかし、AI アシスタントはこうした設計上の制約を理解していません。AI が最適化しているのはただ一つ、「コードを動作させること」だけです。 

 A と B をつなげば機能が動くのであれば、AI は迷わずそれらをつなぎます。そしてその結果は、レビューでは一見まったく問題ないように見えてしまいます。違反は、気づかれないまま紛れ込みます。それが発見されるのは、監査の場か、あるいはもっと悪いことに、インシデントが発生した後です。 

だからこそ、「とにかく人間にレビューさせればいい」という考え方は、AI のスピードの前では通用しなくなります。

疲れたレビュアーが、AI が生成した大量の変更に目を通しても、一見もっともらしく見える微妙な境界違反を見逃してしまいます。こうした形式的・機械的なチェックにおいては、機械のほうが疲れることなく、一貫した精度で処理できます。

一方で、機械には下せない意味的な判断において、人間は代わりが利きません。人が時間を使う価値があるのは、次のような問いに対してです。

• この設計や実装は理にかなっているか 

• 実装は設計意図に沿っているか 

• この問題の構造化の仕方は適切か 

では、AI は本当は何を増幅しているのか？ 

最もコストのかかる品質問題は、突然表面化するものではありません。それは少しずつ積み重なっていくものです。 

かつては容易に変更できていたコードが、四半期を追うごとに手を加えにくくなっていきます。以前は計画どおりに進められていた認証作業が、慌ただしい駆け込み作業に変わります。そして、かつてはベテランエンジニアが全体像を把握していたアーキテクチャも、やがて誰一人として完全には説明できないものへと変わっていきます。

AI は、そのすべてを加速させます。

その基盤は、コードベースがまだ手に負える今のうちに構築することもできますし、手に負えなくなってから構築に取り組むこともできます。皆さんが下すべき決断は、結局のところそれだけです。 

プレイブック全体をご覧になりたい方へ 

eBook『AI時代における信頼性の高いソフトウェア構築』では、ここで取り上げた内容をさらに掘り下げています。信頼できるソフトウェア基盤を支える3つの柱、AIを活用して成果を上げるチームとAIが生み出す複雑さに埋もれてしまうチームを分ける4つの能力、そして、すでにアーキテクチャ設計書がある場合と、アーキテクチャリカバリーによってゼロから復元する必要がある場合、それぞれどこから着手すべきか。スピードと安全性はトレードオフだという考え方を受け入れないリーダーのために書かれた一冊です。