Honeycomb CTOのCharity Majorsが、AI推進派とAI懐疑派の対立構造を分析した論考を発表した。「どちらも間違っていない」と認めながら、真の問題はこの2グループをつなぐフィードバックループが存在しないことだと指摘している。

AI推進派の「時間との戦い」

AI推進派の主張は切実だ。AIに積極的なチームが実際に非連続な能力向上を遂げているのは事実であり、「落ち着くまで待つ」という姿勢が通用する普通の技術サイクルとは異なる。競合他社がAI活用で先行する中で傍観し続ければ、落ち着く前に事業が立ち行かなくなるリスクがある。これは現実的な実存的脅威だ。

AI懐疑派の「エントロピーとの戦い」

一方、AI懐疑派の懸念も正当だ。エンジニアが読み切れないスピードでコードをリリースし、全体像を誰も把握していないまま開発を進めることは、長年かけて積み上げた信頼の貯金を取り崩す行為に等しい。

  • 信頼性の低下: 誰も完全に理解していないシステムが積み重なる
  • 制度知識の蒸発: 「なぜこう実装したのか」を知っている人間がいなくなる
  • オンコールの崩壊: 障害対応が人を消耗させ続ける地獄になる

Majorsはこれを「products burbling into incoherence（製品がつぶやきながら崩壊していく）」と表現した。こちらも組織にとって現実的な実存的脅威だ。

本質的な問題：フィードバックループの不在

Majorsが指摘する最重要ポイントは「2つのグループをつなぐ自然なフィードバックループが存在しない」という点だ。

推進派と懐疑派はしばしば同じチームの中にいながら、共有された現実認識のギャップを埋める仕組みがない。推進派が「どんどん使えばいい」と言う一方、懐疑派は「昨日のコードが理解できない」と悲鳴を上げている。この断絶を放置すると、組織は機能不全に陥る。

Majorsはこれをリーダーシップ課題と工学的課題の両面で捉えることを推奨する。

実務への影響

日本のIT現場でも、この対立は深刻化している。特に以下のシナリオで問題が顕在化しやすい。

AI推進が先行しているケース: 意欲的なエンジニアがAIを積極活用し、短期的に生産性が向上した。しかしコードレビューが形骸化し、障害原因の特定に時間がかかるようになったというケースが増えている。

懐疑的な現場のケース: 「品質が下がる」「責任が取れない」という理由でAI活用を制限した結果、競合との開発速度の差が広がり続けている。

両方の現場に共通して必要なのは、フィードバックループの意図的な設計だ。具体的な例を挙げると：

  • AIが生成したコードのレビュー品質を計測する仕組みを導入する
  • スプリントごとに「AI活用による生産性向上」と「技術的負債の蓄積度」を並べて可視化する
  • 懐疑派の懸念を「制動力」として組織の意思決定に組み込む構造を設計する
  • 推進派と懐疑派が同じメトリクスに基づいて議論できる場を定期的に設ける

Majorsが強調するのは「自然には生まれないため、意図的に設計する必要がある」という点だ。放っておいて解決する問題ではない。

筆者の見解

この論考で提示された構造は、多くの日本企業が直面しているリアルな課題を正確に言語化していると感じた。

特に共感するのは「どちらも間違っていない」という視点だ。AI推進をためらう組織に対して「遅れてる」と言うだけでは何も解決しない。同時に、スピードだけを称えてコードの可読性や組織知識を軽視するのも持続可能ではない。

筆者が実際にAIエージェントを使い続けて感じることは、「エージェントが自律的に動けば動くほど、人間が設計するフィードバックループの重要性が増す」という逆説だ。エージェントが速く動くほど、その動きを評価・是正する仕組みを意図的に作らなければ、組織は制御を失う。これはAIを使いこなそうとするすべての組織が直面する本質的な課題だと思う。

日本のIT現場で今最も必要なのは「AIを使うか使わないか」の議論ではなく、「AIが生み出すアウトプットをどう検証・統制するか」のアーキテクチャを設計することではないか。Majorsの論考はそのための重要な示唆を与えてくれている。

懐疑派の声を「抵抗勢力」と見るのではなく、品質と信頼性を守るための制動力として機能させる──そういう組織設計ができるかどうかが、AI時代のエンジニアリングの差になると筆者は考えている。

出典: この記事は AI enthusiasts are in a race against time, AI skeptics are in a race against entropy の内容をもとに、筆者の見解を加えて独自に執筆したものです。