あなたは、壮大で複雑な城を設計するために長年を捧げてきた、熟練の建築家であると想像してください。そして、その城の改修を手伝ってもらうために、非常にスマートで驚くほど速いロボットの助手を採用したと想像してください。あなたの目的は、城の仕組みを変えることではありません――例えば、キッチンから寝室へ移動する際に床を突き抜けて落ちてしまうようなことがあってはならないのです――そうではなく、廊下を広くし、部屋を明るくし、構造をメンテナンスしやすくすることです。これが**コード・リファクタリング（code refactoring）**の世界です。これは、実行されるソフトウェアを壊すことなく、コードをより良くするために、コンピュータのコードをクリーンアップし、再編成するプロセスです。

長い間、コードの整形ミスや明らかな間違いを指摘する、基本的なスペルチェッカーのようなツールが存在してきました。しかし最近、新しい種類の「ロボット」が登場しました。それが**大規模言語モデル（LLM）**です。これらは、あらゆる本、マニュアル、指示書を読み込んだAIアシスタントのようなものです。彼らは新しい物語を書いたり、壊れた文章を直したりすることには非常に長けています。しかし、彼らに複雑な城（ソフトウェアプロジェクト）の改修を頼むと、時として少しばかり独創的になりすぎてしまうことがあります。屋根を支えている壁を動かしてしまったり、ドアの名前を誰もがキッチンを見つけられなくなるような名前に変えてしまったりすることがあるのです。科学者やエンジニアにとっての大きな疑問は、これらのAIロボットに安全に改修作業を任せられるのか、それとも人間の監督者がその仕事をダブルチェックする必要があるのか、ということです。

これは、論文**「RefactorAssist: Agentic Refinement for Reliable Code Refactoring」**が調査している内容そのものです。研究者のジョナサン・コルデイロ、シャヤン・ノエイ、イン・ゾウは、これらのAIロボットがソフトウェアを壊さずにコードを修正できるのか、そしてもし壊してしまった場合、賢い「修理エージェント」がロボットのミスを直せるのかどうかを調べたいと考えました。

ロボットの最初の試み：賛否両論の結果

チームは、いくつかの異なるAIモデル（StarCoder2のようなオープンソースのものから、GPT-4oのような強力な商用モデルまで）に対し、実際のJavaソフトウェアプロジェクトに対して改修を行うよう依頼しました。彼らはソフトウェアを、**ユニットテスト（unit tests）**と呼ばれる「健康診断」システムを備えた生き物のように扱いました。これらのテストは一連のチェックポイントのようなものです。コードが正しく変更されていれば、ロボットはテストに合格します。もしロボットが誤って機能を壊してしまったら、テストは失敗します。

結果は、少なからず衝撃的なものでした。GPT-4oのような最高のAIモデルでさえ、改修を正しく完了できたのは約80.8%の時だけでした。つまり、およそ5回に1回の割合で、AIはコードを改善しようとして、誤って何かを壊してしまい、ソフトウェアの健康診断を失敗させてしまったのです。研究者たちは、単にAIに改修方法の例を多く与えること（「フューショット・プロンプティング」と呼ばれる手法）は、あまり効果がないことを発見しました。問題は、AIが改修の方法を知らないことではなく、微妙で危険なミスを避けるための*文脈（コンテキスト）*を十分に理解できていなかったことでした。

なぜロボットは失敗したのか？

何が間違っていたのかを突き止めるため、研究者たちは「犯罪現場」を調べる探偵のように、失敗したコードを検証しました。彼らは、AIのミスが主に8つのカテゴリーに分類されることを発見しました。最も多かったのは以下の通りです：

1. ハルシネーションと文脈の混乱 (24.3%)： AIがコードの物語を誤解したために、新しい機能を捏造したり、変える必要のない部分を変更したりしました。
2. 不一致な名前変更 (15.3%)： AIがある場所で変数（例えば「ドア」を「ゲート」と呼ぶなど）の名前を変更したものの、他のすべての場所でその名前を更新することを忘れ、コードを混乱させてしまいました。
3. 新しい要素の追加 (13.7%)： 本来そこにあるべきではない変数や関数を、誤って追加してしまいました。
4. 不完全なコード (11.3%)： コードの記述を途中で止めてしまい、欠落した部分を残してしまいました。
5. 構文および構造のエラー (9.7%)： 閉じ括弧やセミコロンを忘れるといった基本的なミスです。
6. エッジケース (9%)： ユーザーが数字の代わりにゼロを入力した場合など、稀な状況への対処を忘れてしまいました。
7. 型の扱い (8.7%)： テキストメッセージを数値ボックスに入れようとするなど、異なるデータ型を混同しました。
8. スコープの問題 (8%)： 変数が存在しない場所で使用しようとしました。

RefactorAssistの登場：スーパー・インスペクター

研究者たちは、単にAIにもう一度やり直させるだけでは不十分であることに気づきました。ミスを検知し、自動的に修正できるシステムが必要でした。そこで、彼らは2段階の品質管理インスペクターとして機能するスマートな「修理エージェント」、RefactorAssistを構築しました。

ステージ1：クイック・フィックス（静的修復）
AIに再び考えさせる前に、RefactorAssistは高速なルールベースのチェックを実行します。これは、物語を理解する必要はなく、文法だけをチェックするスペルチェッカーのようなものです。不足しているインポート、バランスの取れていない括弧、単純な型の誤りといった明らかな問題を修正します。このステップは、重いAIの脳を使わないため、安価で高速です。驚くべきことに、この単純なステップだけで、構文をクリーンアップすることにより、成功率を66.1%から74.4%（最適な構成では80.3%）へと大幅に向上させました。

ステージ2：探偵の仕事（エージェンティック修復）
（クイック・フィックスの後でもなお）残っている壊れたコード（失敗したコード）に対して、RefactorAssistは「エージェント・モード」に切り替わります。それは、失敗したテストからのエラーメッセージ、AIが行った具体的な変更点（「差分/diff」）、そして周囲のコードの文脈といった、あらゆる証拠を集めます。そして、強力なAI（GPT-4oなど）に「探偵」として振る舞うよう依頼し、なぜコードが失敗したのかを説明させ、修正案を提示させます。この探偵は単に推測するのではなく、証拠を用いて修理を導きます。

この2段階のプロセスの結果は目覚ましいものでした。最初のAIによる試行、静的修復、そして反復的な探偵による作業を経て、成功率は**94.2%**まで上昇しました。決定的なのは、RefactorAssistは、最初の静的修復ステップの後に残っていた失敗の**70.8%**を修正できたことです。これは、AIが失敗し、文法チェックでは修正できなかった改修のサブセットにおいて、RefactorAssistの探偵エージェントが大多数を回収し、総成功率をほぼ完璧なレベルにまで引き上げたことを意味します。

何がうまくいかなかったのか？

研究者たちは、助けになるかもしれないと考えて試みたものの、あまり役に立たないと判明したアイデアについてもテストを行いました。例えば、AIにより多くの背景情報を与えるために、プロジェクト全体を検索して追加の文脈を提供する「リトリーバル（検索）」システムを導入してみました。これは、修正の最初の数秒間には多少の助けにはなりましたが、最も困難な問題を解決する上では、長期的に見てAIの助けにはなりませんでした。論文は、膨大な量の追加の文脈を持つことよりも、何が壊れたのかという明確で正確な説明（「診断」）を持つことの方がはるかに重要であると示唆しています。

まとめ

この論文は、AIが単独でコードを完璧にリファクタリングできると主張しているわけではありません。実際、AIは助けなしでは約**20%**の確率でミスを犯すことを証明しています。しかし、シンプルな高速な「文法チェック」と、証拠に基づいたスマートな「探偵エージェント」を組み合わせることで、それらのミスの大部分を修正できることを示しています。

主な知見は、RefactorAssistが、乱雑で壊れたAI生成の改修を、成功率**94.2%**で安全で動作するコードの更新へと変えられるということです。これは、ソフトウェアエンジニアリングの未来が、単に「より賢いAI」を持つことではなく、AIが重労働を行い、特化した修理エージェントがユーザーに届く前にエラーを捕まえるという、「チーム」を構築することにあることを示唆しています。これは、たとえ超スマートなロボットであっても、最高の仕事をするためには優れた品質管理チームが必要であるということを思い出させてくれます。