【ITニュース解説】I Gave Claude Code a Brain. Its Mistake Rate Went to Zero.

システムエンジニアを目指す皆さんへ。最近、大規模言語モデル（LLM）であるClaude Codeに「記憶」の機能を追加することで、その間違い率が劇的にゼロになったという、非常に興味深い研究結果が発表された。これは、AIを活用した開発の未来を考える上で重要な進展だ。

この研究が解決しようとした課題は、現在のLLMが時に自信満々に誤った推奨をすることだ。特に厄介なのは、コマンドがエラーにならないが、実際には何も機能せず、表面上は成功したように見えてしまうケースである。このような間違いは発見が難しく、開発時間の無駄につながるため、非常にコストが高い。また、LLMはチームの過去の意思決定、例えば特定のライブラリバージョンが固定されている理由や過去の障害情報といった「暗黙の知識」を持っていない。これらの情報は、人々の頭の中や古い履歴にしか存在しないことが多く、モデルが直接アクセスできないため、最適な解決策を導き出すのが難しいという問題があった。

そこで、この研究ではClaude Codeに「RE-call」と呼ばれる記憶メカニズムを追加することを試みた。これは、外部の知識ベースから関連情報を検索し、それをLLMの思考プロセスに組み込む、RAG（Retrieval Augmented Generation：検索拡張生成）と呼ばれる技術の一種だ。LLMが何かを考える際に、必要に応じて過去の出来事やプロジェクトの特定の情報が記録された「記憶」を参照できるようにするイメージだ。

実験の設計は非常に厳密に行われた。記憶メカニズムを持たないClaude Codeと、記憶メカニズムを持つClaude Codeの2つのセッションに、全く同じタスクを実行させ、その結果を比較したのだ。両セッションは同じLLMモデル、同じ一連のタスク、そして基本的なプロジェクトファイルである「CLAUDE.md」をバイト単位で全く同じように読み込んだ。唯一の違いは、記憶メカニズムを持つセッションだけが、プロジェクトに関する厳選された「記憶」を検索できる点にあった。

タスクの内容も工夫されていた。プロジェクトが過去に実際に遭遇し、解決してきた10種類の「ハザード」（問題点や落とし穴）がそれぞれ隠されていた。例えば、CPUの制限設定が機能しない、存在しない画像レンダラを使うことを推奨する、といったプロジェクトの歴史を知らないと引っかかる具体的な罠が再現されている。

これらのハザードについて、エージェント（Claude Code）がそれに引っかかったかどうかは、決定論的なチェッカーによって評価された。これは、エージェントの行動履歴を読み取り、特定のパターンが見られた場合に「ハザードに陥った」と判断する仕組みで、モデル自身の判断は介入しない。さらに、各ハザードタスクはそれぞれ10回ずつ実行された。AIの応答は常に一定ではないため、一度の結果だけでは何も証明できないという考えから、統計的な信頼性を高めるための重要なステップだ。

そして、最も注目すべき結果が明らかになった。記憶メカニズムなしのClaude Codeは、実行されたタスクの52.5%で間違いを犯したのに対し、記憶メカニズムありのClaude Codeは、なんと0%の間違い率を達成したのだ。これは「間違いが減った」というレベルではなく、40タスク中40タスクすべてで正解という、劇的な改善を示している。

回答の品質に関しても、同様に大きな向上が見られた。この評価にはRagasというLLMアプリケーション向けのオープンソース評価ツールが使われた。Ragasは、事前に用意された正しい「参照回答」と、エージェントの実際の回答を比較し、「AnswerCorrectness」（参照回答のどれだけをエージェントが正しくカバーしているか）と「FactualCorrectness」（エージェントの回答に含まれる主張が参照回答とどれだけ一致しているか）という二つの指標で数値化する。結果として、記憶メカニズムを追加したことで、回答の正答率と事実の正確性が共に約2倍に向上した。

この結果が単なる偶然ではないことを示すため、厳密な統計分析も行われた。統計的な指標である「p値」が0.0003以下であったことは、この効果が偶然ではなく、記憶メカニズムが実際に機能したことを強く裏付けている。

実験の信頼性を高める工夫は他にもある。例えば、エージェントの回答を評価する「審査員」には、テスト対象のClaude Codeとは異なる種類のモデル（GPTモデル）が使われた。これは、自己評価を防ぐためだ。また、すべての参照回答は実験開始前に作成され、後から都合の良いように変更されることはなかった。

さらに、非常に重要な「コントロールテスト」も実施された。これは、回答がすでにCLAUDE.mdファイル内に記載されているタスクも実行するというものだ。この場合、記憶メカニズムが追加の情報を得る必要がないため、両方のエージェントのパフォーマンスに差が出るはずがない。実際に、このコントロールテストでは両者の結果は完全に一致し、差はゼロだった。この事実は、記憶メカニズムが、本当に情報が必要な場所でのみ効果を発揮し、そうでない場所では無駄な干渉をしないという、研究結果の信憑性を裏付ける強力な証拠となっている。

この研究で特に意外だった発見は、記憶メカニズムの使いどころだ。当初、一般的なRAGの考え方として、既存のドキュメントを記憶メカニズムで「置き換える」ことで効果が得られると予測されていた。しかし、実際に試してみると、この方法では回答の品質はほとんど改善しなかった。一方で、既存のドキュメントはそのまま残し、それに「加えて」記憶メカニズムを利用したところ、回答の品質がほぼ2倍になったのだ。これは、外部の記憶が、既存のドキュメントでは補いきれない、より深い文脈や過去の経験といった情報を提供することで、LLMの能力を最大限に引き出すことを示唆している。

もちろん、この記憶メカニズムにはわずかなコストもかかる。セッションあたり約15,000トークン（LLMが処理する情報の最小単位）の追加入力と、数秒程度の処理時間の増加だ。記憶が役に立たないタスクでは、余計な検索を行うためにわずかに遅くなることもある。しかし、記憶なしのエージェントが、過去の経緯を知っていれば回避できたはずの罠にはまり、7分間も無駄な作業を続けたことがあったことを考えると、このわずかなコストは、潜在的な大きな損失を防ぐための十分な投資と言えるだろう。

現時点でのこの研究が証明しているのは、記憶メカニズムが特定の種類の間違い、特にプロジェクトの歴史や文脈に関する間違いを排除し、プロジェクトに関するLLMの回答を大幅に正確にするということだ。これは、エージェントが「一般的に賢くなる」というよりも、より「知識豊富になる」という表現が適切かもしれない。記憶が追加する情報がないタスクでは、何も追加の効果はなかったというコントロールテストの結果も、この点を裏付けている。

ただし、この研究はまだ「実際の作業がより高い成功率で完了するかどうか」までは証明していない点には注意が必要だ。今回のタスクは、あくまで「正しい推奨を生成できるか」を評価するものであり、実際にコードを書き、テストスイートを実行し、プロダクトを出荷するといった、より複雑な開発プロセス全体での効果はまだ検証されていない。

しかし、この研究の著者たちは既に次の段階の実験を進めている。次の実験では、より実践的なシナリオで、実際のコードリポジトリにおいて、テストスイートの合否によって成果を評価するという、さらに厳しい検証が行われる予定だ。これにより、記憶メカニズムが開発プロセス全体でどれほどの価値をもたらすかが明らかになるだろう。

この成果は、AIをシステム開発の現場でより信頼性の高いパートナーとして活用するための重要な一歩と言える。特に、過去のプロジェクトの経験や暗黙の知識が蓄積された記憶を活用することで、AIがより文脈を理解した上で正確な判断を下せるようになる可能性を示している。