AI変革が行き詰まる理由

上記のフレームワークを用いて、実務で遭遇する一般的なAI変革の困難を再検討できる。これらの困難は通常、モデルの能力やチームの規律に帰されるが、構造的特性の分析を通じて、根本原因が構造的ミスマッチにあることが見えてくる。

「AIが書くコードは品質が低すぎる」

よくある帰属：モデルの能力が不足している、プロンプトの書き方が悪い。

本章のフレームワークのレンズで見ると、これは入力への忠実な実行という特性の直接的帰結である。Agentは入力に忠実である。出力のランダム性は仕様の曖昧さに由来し、モデルの能力とは限定的な関係しかない。より高性能なモデルに切り替えても、曖昧な仕様はやはりランダムなコードを生成する。問題の根源は入力側にある。仕様が十分に明確で、完全で、テスト可能であるかどうかだ。第2章では仕様システムを通じた対処方法を議論する。

「大きなタスクをAIに任せると崩壊する」

よくある帰属：AIは単純なタスクしかこなせない。複雑な作業はやはり人間が必要だ。

これは処理能力の限界という特性の直接的帰結である。同じAgentが小さなタスクでは良好なパフォーマンスを発揮し、大きなタスクでは崩壊する。違いはタスク規模が品質の崖を超えるかどうかにある。問題は分解戦略にある。大きなタスクをAgentが実効的に処理できる粒度にどう分割するか、分解後に全体の整合性をどう維持するかである。第4章でタスク分解とContext Engineeringの具体的手法を議論する。

「AIが同じ間違いを繰り返す」

よくある帰属：モデルが愚かで教訓を覚えられない。

これは記憶の蓄積がないという特性の直接的帰結である。Agentの記憶はセッション境界で終わる。前回のセッションで修正したエラー、到達したコンセンサス、蓄積したプロジェクト理解のすべてが、新しいセッションで完全にゼロにリセットされる。チームが口頭のコミュニケーションや日々の協働で蓄積する経験は、Agentには効果がない。第4章でセッションを横断する知識永続化メカニズムの構築方法を議論する。

「AI導入後、コードレビューがさらに疲弊する」

よくある帰属：AIのコードスタイルが悪く、チームの標準に準拠しない。

これは高スループットという特性の直接的帰結である。核心の矛盾は、出力速度がレビュー帯域幅を超えることにある。Agentの1日のコード出力がプログラマーの1週間分の出力に匹敵する場合、従来の人間によるレビュープロセスは必然的にボトルネックとなる。解決策は、主たるレビュー担当を人間から自動化システムに移行することである。第3章と第5章で、単一タスクおよびマルチAgent環境における自動化検証システムを議論する。

「コードベースが汚くなる一方なのに誰もリファクタリングしない」

よくある帰属：チームの規律の問題。コーディング規約を強化すべき。

これは結果に対する意識の欠如という特性の直接的帰結である。Agentにはコードの長期的な保守性に対する内発的関心がない。コードベースに既存のパターンを忠実に複製する。悪いパターンも含めて。マージされたコードが後続の生成の参照セットとなり、品質低下の自己強化ループが形成される。規律や標準は人間に対して有効なガバナンスツールであり、Agentに対して必要なのは外部の品質ガバナンスメカニズムである。対抗的検証、信頼境界、リスク階層化。これらのトピックは第3章と第5章で扱う。