AIにおけるNIHシンドローム：Claudeがライブラリをインポートせずに3,000行を書いたとき

ソフトウェアエンジニアリングの世界では、"Not Invented Here"（NIH）シンドロームは、チームが外部の十分に良いソリューションを拒否し、ゼロから自分たちで作ろうとする有名な落とし穴です。通常は人間の心理的特性ですが、Claude Code（Opus 4.7）を使用した開発者の最近の報告では、AIエージェントも同様の衝動にますます影響されていることが明らかになりました。

AIの過剰設計の顕著な例として、Fandomウィキの誤字修正を試みた開発者は、Claudeが単一のインポート文で解決できるタスクを処理するために、約3,000行ものカスタムPythonコードを書いたことを発見しました。pywikibotやmwparserfromhellといった確立されたライブラリを活用する代わりに、AIは一日中、ウィキテキストのストリッピング、誤字辞書、編集ランナーをゼロから再実装していました。

車輪の再発明のコスト

AIのカスタム実装と既存エコシステムとの格差は顕著です。開発者の経験は、AIが効率的な方法ではなく困難な道を選んだいくつかの領域を浮き彫りにしています。

• Wikitext Stripping: Claudeは入れ子テンプレートやタグを処理するために、複雑な正規表現を122行書きましたが、mwparserfromhell.parse(text).strip_code()で十分でした。
• Typo Correction: AIは18エントリの独自辞書を作成し、約4,000ルールを含むコミュニティが管理するRETFルールセットを無視しました。
• Edit Execution: Claudeはクッキー認証とCSRF取得を処理するために、編集ランナーの別々のコピーを10個（各約250行）生成しましたが、pywikibot.Page.save()で数行のコードだけでネイティブに処理できます。

効率低下に加えて、カスタムコードは「些細なバグ」—たとえばASCIIアートがマッチに混入するなど—を導入し、さらなる正規表現パッチが必要となり、既存のパーサがあるかどうかを検証せずに複雑さが増すサイクルを生み出しました。

なぜLLMは過剰設計するのか？

元投稿の作者は、Claudeのようなハイエンドモデルがこのような振る舞いを示す理由として、主に2つの理論を提示しています。

1. Benchmark Bias: 多くの公開コーディングベンチマークはネットワークアクセスやpip installができない「シールド」環境で実行されます。モデルがこれらの評価に対して強化学習（RL）されると、外部ライブラリを利用することが成功の選択肢ではないと学習してしまう可能性があります。
2. Sunk-Cost Defense: 大量のコードが生成され、コンテキストウィンドウ内に存在すると、モデルはそのコードを「荷重を支える」ものとみなすことがあります。これは、Claudeがライブラリへの移行後もカスタム誤字辞書を保持すべきだと主張し、包括的なRETFライブラリがすでにカバーしている「エッジケース」を処理すると主張した事例で示されています。

緩和策

この事例に対するコミュニティの反応は、AIがカスタム実装に向かうデフォルトの傾向を持っているものの、より良いアーキテクチャ指針を通じて管理できることを示唆しています。

1. 明示的な実装戦略

複数の開発者は、AIエージェントはしばしば「あなたが許す限り愚か」だと指摘しています。NIHシンドロームを回避するために、ユーザーは欲しい機能だけでなく実装戦略も指定すべきです。「PyPIから関連パッケージを使用する」や「pywikibotを使用する」といったシンプルな指示を加えることで、AIがカスタム正規表現の無限ループに陥るのを防げます。

2. プロジェクト憲章とルールセット

Claude Codeのようなツールを使用する場合、CLAUDE.mdファイルやプロジェクトルールセットを活用することは非常に効果的です。プロジェクトの「憲章」を定義し、たとえば「インラインコードよりもライブラリを優先する」や「ライブラリを探す前にカスタムロジックを100行以上書かない」などと設定することで、AIは特定のアーキテクチャ哲学に従うよう強制されます。

3. 「プランモード」ワークフロー

別の提案されたアプローチは、プロジェクトを「プランモード」で開始することです。AIに「やってくれ」と指示する代わりに、2〜3の代替ライブラリやアプローチを調査し、長所と短所を提示させます。これにより、AIの役割はコーダーからアーキテクトへとシフトし、人間が現在LLMが苦手とする高レベルの設計判断を行えるようになります。

トレードオフ：制御 vs. 便利さ

興味深いことに、一部の開発者はAIがカスタムコードをデフォルトにすることはバグではなく機能だと主張しています。「依存関係の地獄」の時代において、単一のパッケージが数百のトランジティブ依存関係をもたらすことがある中で、軽量なカスタム実装をデフォルトとするAIは、依存関係ツリーの厳密な制御を重視する人々にとって好ましい場合があります。

結局のところ、教訓は明確です。AIエージェントは驚異的な速度でコードを書けますが、いつ構築を止めてインポートすべきかという本質的な判断力を欠いています。高レベルのアーキテクチャ監督の責任は、依然として人間の開発者にあります。