Phoenix: Safe GitHub Issue Resolution via Multi-Agent LLMs
Phoenixは、7層の安全制御とベースラインを意識した評価戦略を採用することで、トリアージからプルリクエスト作成までGitHubのイシューを安全に解決するマルチエージェントLLMシステムであり、厳選されたSWE-bench Liteスライスにおいて75%のオラクル解決率を達成しつつ、実世界のイシューに対して100%の正当性保持を実現しています。
原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。 免責事項の全文を読む
GitHubという、何百万もの人々が修正依頼、新機能の要望、あるいは誤字の指摘を記した付箋（メモ）を本に残している、巨大で賑やかな図書館を想像してみてください。これらのメモは「Issue（イシュー）」と呼ばれます。通常、人間の司書がそのメモを読み、本の正確なページを見つけ、何が間違っているかを判断し、テキストを書き直し、その後、その修正を棚に戻す前にシニア司書にチェックを仰がなければなりません。これは時間がかかり、非常に疲れる作業です。
Phoenixは、この仕事をするために設計されたAIロボットの新しいチームですが、非常に厳格なルールを持っています。それは、**「害を与えないこと（Do no harm）」**です。
Phoenixの仕組みを、シンプルな概念ごとに分解して説明します。
1. 専門家チーム（6人のエージェント）
一つの超高性能なロボットが一度にすべてをやろうとするのではなく（それはしばしばミスにつながります）、Phoenixは、よく整備された組立ラインのような、特化した6人の作業員によるチームを使用します。
- プランナー（計画者）: 付箋を読み、地図を描きます。どのページを変更すべきか、そしてどのように修正すべきかを決定します。
- リプロデューサー（再現者／探偵）: 何かを修正する前に、このロボットは問題の再現を試みます。「よし、もしXを行ったら、本は壊れるだろうか？」と問いかけます。もし本が壊れていることを証明できれば、次のステップへ進みます。もし証明できなければ、チームが立ち往生しないよう、このステップをスキップします。
- コーダー（プログラマー／執筆者）: 書き手です。プランナーの地図を受け取り、実際にページのテキストを書き換えます。
- テスター（検証者）: 品質検査官です。新しいテキストによって新たなエラーが発生していないかを確認するために、本を専用のマシンに通します。
- フェイラー・アナリスト（失敗分析者／医師）: 診断を行うロボットです。テスターが新しいエラーを見つけた場合、なぜそれが起きたのかを診断し、コーダーに修正方法を伝えます。彼らには2回までの修正チャンスがありますが、2回失敗した場合は停止して人間に助けを求めます。
- PRエージェント（伝達者）: メッセンジャーです。修正が完了したら、すべてをパッケージ化し、最終承認のために人間の司書に渡します。
2. 「セーフティネット」（7つの保護レイヤー）
この論文では、AIが勝手に本を書き換え始めると危険である可能性があることを強調しています。そのため、Phoenixには災難を防ぐための7つの「安全ガード」があります。
- フェンス: ロボットが図書館の壁の外側で書き込むことを防ぎます（触れてはいけないファイルを削除することを防ぎます）。
- IDバッジ: ロボットが有効な鍵（トークン）を持っているかを確認し、作業中にロックアウトされないようにします。
- クリーンアップ・クルー: ロボットが混乱しないよう、付箋から乱れた部分や紛らわしい部分を取り除き、整形してからロボットに見せます。
- 「進入禁止」ゾーン: 図書館のセキュリティシステム（ワークフローファイル）には触れないように設定されています。これらをいじると、全員が締め出される可能性があるためです。
- ストップボタン: ロボットがループに陥ったり、同じ間違いを繰り返したりした場合、システムが強制終了します。
- 単独作業者: ロボット同士が衝突しないよう、一度に一つの本しか作業しません。
- 新鮮な鍵: IDバッジの期限が切れる前に自動的に更新し、タイムアウトによって作業が止まらないようにします。
3. 「前後比較」テスト（ベースラインの認識）
これがPhoenixの最も巧妙なトリックです。時として、ロボットが手を触れる前から、すでに図書館の本が壊れていることがあります。
- 従来の方法: ロボットが誤字を修正しましたが、本はもともと壊れていたためにテストに失敗しました。その結果、ロボットは失敗の責任を負わされます。
- Phoenixの方法: ロボットが変更を加える前に、本の現在の状態の「スナップショット」を取ります。その後、ロボットが変更を加えた後、新しい状態をスナップショットと比較します。
- もし本がもともと壊れており、修正後も壊れたまま（ただし、新しいものは壊れていない）であれば、Phoenixは「成功！悪化はさせていない」と判断します。
- もし本が正常に動作していたのに、修正後に壊れた場合は、Phoenixは「ストップ！デグレ（退行）を導入した」と判断します。
4. 結果が示すもの
研究者たちは、2つの方法でPhoenixをテストしました。
- 練習走行（SWE-bench Lite）: 彼らはPhoenixに、あらかじめ定義された24個の特定の問題を与えました。Phoenixは、すでに動いているものを壊すことなく、**75%**の課題を完璧に解決しました。
- 実世界テスト（42個の実問題）: 彼らは、14の異なる実在するプロジェクトから集められた、42個の実際の問題に対してPhoenixを解き放ちました。
- 安全性: Phoenixは**100%の「正当性保持（Correctness Preservation）」**を達成しました。これは、以前はパスしていたテストを、一度も壊さなかったことを意味します。驚くほど安全でした。
- 成功率: しかし、修正されたもののうち、実際に「正しい」修正であったのは約半分でした。残りの半分は「ハルシネーション（幻覚）」であり、ロボットが間違った場所にコードを書いてしまったケースでした（例：フィクションのコーナーに修理マニュアルを書くようなもの）。ロボットは「どう直すべきか」は知っていましたが、時には「どこに問題があるか」を見つけることができませんでした。
まとめ
Phoenixは、非常に慎重で、高度な訓練を受けた見習い司人のようなものです。「事態を悪化させないこと」において極めて優秀であり、厳格なプロセスに従うことに長けています。しかし、説明文とファイル名が完全に一致しない場合、問題の正確な場所を見つけることに苦戦することがあります。
論文は、AIが実世界で役立つためには、**「スピードよりも安全性が優先されるべきである」**と結論付けています。Phoenixは、専門化されたエージェントのチームと厳格な安全ガードを使用することで、ソフトウェアを誤って壊すことなく、ソフトウェアの修正を自動化できることを証明しました。次に解決すべき主な課題は、「プランナー」ロボットが、より頻繁に「本の正しいページ」を見つけられるようにすることです。
自分の分野の論文に埋もれていませんか？
研究キーワードに一致する最新の論文のダイジェストを毎日受け取りましょう——技術要約付き、あなたの言語で。