8月4日、Mathieu Ropertが「An Honest Review of AI Programming · Mathieu Ropert」と題した記事を公開した。Claude定期購読を3ヶ月間実務で使い込んだC++／ゲーム開発エンジニアが、AIコーディングツールの実際の有用性と限界を率直に評価した内容だ。

「コードを書かせるな」——現役エンジニアの結論

記事の著者Mathieu Ropertは、ゲーム開発を専門とするC++エンジニアだ。会社からClaudeのサブスクリプションを与えられ「とにかく使え」と言われたと書いている。「AIツールに懐疑的になるのは当然の反応だ」と認めつつも、3ヶ月間の実務使用を経て「コードを書かせない限りは、それなりに使える」という結論に至った。

LLMが得意なこと：検索の代替

Ropertが最も有用だと感じたのは、コード生成ではなく情報検索の自動化だ。

特に評価しているのが、社内ナレッジベースの検索への活用だ。SlackログやConfluence、Google Driveに散らばった情報は、社内の検索機能が貧弱なため実質的にアクセス不能になっていることが多い。LLMは自然言語の質問を複数のクエリに展開し、同義語を含めて並列検索することで、この問題を緩和できる。この活用方法は、LLMを検索エンジンの上に重ねるRAG（Retrieval-Augmented Generation）と呼ばれるアーキテクチャに相当する。

入社したばかりにもかかわらず、自分の着任前に書かれた回答を複数見つけることができた。エンジン固有のエッジケースに遭遇したとき、過去に誰かが報告・議論していたかをすぐ検索できたのは本当に助かった。

技術的には、Googleが20年前に実装したインデックス手法を社内wikiに適用すれば同じことができる。ただし、現実の多くの企業ではそれが実装されていないため、高コストなLLMで代替しているという非効率な構図だと著者は指摘する。

ハルシネーションの現実

LLMの根本的な問題として、Ropertはハルシネーション（hallucination：事実と異なる回答をあたかも確実な情報として生成する現象）を挙げる。これはすべてのモデルで経験したという。

特に顕著だったのが、CMake・Vulkan・Xcodeなどのニッチな機能について質問したときだ。「できない」と答える代わりに、存在しないボタンや機能フラグを自信満々に提示してきた。著者はこれを「そのソフトウェアは詳しくないが、その問題領域には詳しい人に聞くようなもの」と表現する。他言語では.sort()がコンテナに実装されているから、C++にもあるはずだという確率論的な推論でAPIを捏造するのと同じ構造だ。

さらに深刻な事例として、Claude社内文書を検索させたところ、自分が現在執筆中のレポートを「過去の根拠ある文書」として引用してきたという体験を紹介している。自己参照ループが発生したわけだ。別のケースでは、別のLLMが生成した要約を一次ソースとして扱い、「具体的な根拠がある」と報告してきたが、実際のソースはフォーラムでの推測にすぎなかった。

コード生成が機能しない理由

Ropertが試みたコード生成タスクの例が具体的だ。Unityゲームにおける一般的なパフォーマンス最適化として、MonoBehaviour（Unityにおける基本的なスクリプトコンポーネントクラス）のUpdate()メソッドをマネージャークラスのforループに集約するリファクタリングを依頼した。

Claudeの出力はこうだった：

• GameUpdateableという基底クラスを新設
• OnUpdate()メソッドを定義
• Fooをそこから継承させ、List<GameUpdateable>として管理

依頼したのは「余計なクラス階層なしに、シンプルにList<Foo>でループを回す」という内容だった。結果は、求めていないOOP設計パターンを勝手に適用した、より複雑なコードだった。

この背景についてRopertは、ゲーム開発のコード（特にネイティブ言語）はLLMの学習データが極めて少ないことを指摘する。公開されているAAAゲームのソースコードで最新のものは、2004年リリース（記事執筆時点で22年前）のDoom 3だ。マルチスレッドすら存在しない時代のコードベースである。ほかに公開されているゲームコードは1990年代のものが中心で、ソフトウェアラスタライザやOpenGL 1.2時代の実装だ。

学習データがホビープロジェクトやゲームジャム作品に偏っている以上、LLMが商用ゲームエンジンの実務的なパターンを出力できないのは必然だという。

また、カスタムエンジンと独自スクリプト言語を持つ友人エンジニアからの話として、「LLMが生成したスクリプトは内部の書き方と全く合わない。学習データがModしか存在しないから」という声も紹介されている。

コスト面でも問題がある。出力トークンは入力トークンの5〜10倍のコストがかかる（これは著者が社内RAG用途などの実務運用で直面したコスト感覚に基づく記述であり、APIの公式料金体系とは文脈が異なる点に注意）。要約作業は入力が出力を大きく上回るため比較的安価だが、コード生成は逆転するため高コストになる。

LLMは「コーディングアシスタント」として使うべきか

記事後半では、英国の経営コンサルタントStafford Beerが提唱した管理サイバネティクス（management cybernetics：組織や系を制御・調整するための情報フローを研究する学問領域）の理論を参照しながら、LLMをコード生成ツールではなく「調査・計画のアシスタント」として位置づける方向性が示唆されている。詳細は元記事を参照されたい。

Ropertの総括は明快だ。LLMは自然言語での質問→複数ソースの並列検索→要約というワークフローで最も力を発揮する。コード生成は、学習データの質・量・コスト・ハルシネーションの観点から、現時点では実務への適用が難しい領域だ。

詳細はAn Honest Review of AI Programming · Mathieu Ropertを参照していただきたい。