GPT-5：AIコーディングエージェントは自己改善できるか？

AIの自己改善という概念は、しばしば機械が人間の理解を超越するイメージを想起させ、AIの安全上の懸念と結びつけられることが多いです。しかし、大規模言語モデル（LLM）が自身のパフォーマンスをどのように向上させるかを探ることは、より現実的な視点を提供します。この調査は「推論時自己改善」に深く踏み込みます。これは、モデルがコアとなる重みを更新することなく、特定のタスクにおける効率を高めるシナリオです。これは、モデルトレーニング中のアルゴリズムの進歩やデータ最適化に焦点を当てる「トレーニング時自己改善」とは異なります。ほとんどのAIエンジニアにとって、モデルをトレーナーとしてではなくユーザーとして主に操作するため、推論時にモデルが自身の運用効率を向上させる能力は、魅力的な研究分野となります。

この中心的なアイデアは、LLMが自身の内部知識、すなわち「潜在空間」から価値を引き出すための手段として、コーディングエージェントを活用することにあります。これを探るため、実験的なフローが考案されました。まず、モデルに生産性を向上させると信じる一連のツールを作成するようプロンプトを与えました。次に、これらのツールを使用して監督下でタスクを試行させました。最後に、ツールをどのように改善できるかを振り返らせました。このプロセスは主にGPT-5でテストされ、Opus 4と比較されました。

初期の調査結果では、GPT-5が開発者ユーティリティの生成に優れていることが明らかになりました。しかし、重大なパラドックスが生じました。モデルは、自身が作成したツールを使用することをしばしば拒否したのです。GPT-5がタスク後に率直に述べたように、「正直に言うと、どれも必要ありませんでした。」この観察は、Gemini 2.5 ProやGPT-4.1などの他の主要モデルとの比較を含む複数のテストで当てはまり、Opus 4がGPT-5に匹敵する唯一のパフォーマーであることが一貫して証明されました。

人間側の実験者は当初、2つの具体的なツールを依頼しました。1つ目は、並列コーディングエージェント向けに設計された高度なタスクマネージャーです。複数のAIインスタンスが個別の開発環境で動作することが多いため、変更を追跡し、依存関係を管理し、潜在的な競合を指摘するための堅牢なシステムが必要でした。これは、多数のプルリクエストを読み込む人間にとっては課題です。GPT-5のこのタスクマネージャーに対するソリューションは、特に洗練されており、同時書き込みのための先行書き込みロギング（WAL）、タスク優先順位付けのための依存関係グラフ、およびimpact_conflictのようなキーワードで全エージェントを同期させるための追記専用イベントストリームを組み込んでいました。Opus 4も機能するタスクマネージャーを生成しましたが、包括的な通知および同期機能が不足していました。

2番目に要求されたツールは「コード品質標準プレイブック」でした。これは、ESLintのような既存ツールを活用してリンティングや型チェックを行いながら、コードベースのヒューリスティックを形式化することを目的とし、さらにカスタムルールや、より定性的な標準（例：スリムなコントローラーの確保やデータベース列のインデックス化）のための特注ツールも可能にしていました。このプレイブックに対するGPT-5のMarkdownベースの計画は、Opus 4のものよりもニュアンスが豊かであると評価され、様々なコードベースにわたるコード品質ルールの分析と構造化に対する徹底的なアプローチを提供しました。

実験で最も洞察に富んだ部分は、モデルに、より生産的になるために彼ら自身が必要だと考えるものは何かを尋ねたことです。ソフトウェアエンジニアリングタスクの説明を与えられた後、GPT-5とOpus 4の両方が様々なツールを提案しました。GPT-5は、そのツールを環境チェック用のdoctor、リポジトリインデックス作成用のcode-map、シンボル検索用のcsearch、変更ファイルにリンクされたタスクを表示するimpactなど、軽量なコマンドラインインターフェースユーティリティとして概念化しました。対照的に、Opus 4は、「コンテキストアナライザー」、「クロスプラットフォームテストジェネレーター」、「バグパターン認識エンジン」といった、より記述的で擬人化された名前のツールを提案し、これらは標準のPythonスクリプトとして実装されました。両モデルは同様の機能方向へと収束しましたが、GPT-5のアプローチはより簡潔でユーティリティ指向であったのに対し、Opus 4はツールにより広範でタスク指向のスコープを与えているように見えました。

これらの自己生成ツールの実用性を評価するため、複雑なタスクが割り当てられました。既存のFlaskモノリスアプリケーション（smol-podcaster）を、TypeScript、Tailwind/ShadCNスタイリング、モジュール化されたバックエンドロジック、および包括的なテストを備えたFastAPIバックエンドとNext.jsフロントエンドに移行するというものです。GPT-5とOpus 4は、作成したツールにアクセスできたため、Pythonの依存関係の問題を解決するためのわずかな人間の助けを必要とするだけで、ほぼ一度の試行で移行を完了することができました。結果として得られたアプリケーションは完全に機能しましたが、GPT-5は元のデザイン美学を維持したのに対し、Opus 4は独自のデザイン変更を導入しました。

重要なことに、この困難な移行中にカスタムツールを使用したかどうか尋ねられたとき、両モデルは、すでに本質的に使い慣れているツールを除いて、否定的に答えました。GPT-5は、ランタイム/環境の問題は直接修正する方が速く、その移行中に「カスタムツールから恩恵を受けるようなリポジトリ全体の再構築や診断」がなかったためだと述べました。これは移行の性質を考えると驚くべき主張です。Opus 4の推論はさらなる明確さをもたらしました。モデルは、既存の知識に基づいてツールを構築したが、実際のタスクに直面したとき、外部ツールを呼び出すよりも、単に自身の固有の能力を活用する方が効率的であると感じた、と効果的に伝えました。

この観察は、AIコミュニティでの以前の議論と一致しており、モデルが運用プロセス中に早期の失敗を経験した場合、ツールを避けることを迅速に学ぶ可能性があること、またはモデルがスケールするにつれて、エージェントのための広範な「足場」が不要になる可能性があることを示唆しています。割り当てられたタスクは人間にとって数時間かかるほど困難でしたが、より複雑なタスクがモデルにカスタムツールを使用させるかどうかという疑問を提起します。

結論として、現在のLLMは洗練された開発ツールを設計する驚くべき能力を示していますが、複雑なコーディングタスク中にこれらのツールを使用する傾向は限定的です。これは、コーディングエージェントにおいて真の「推論時自己改善」を達成するには、単なるツール作成以上のものが必要である可能性を示唆しています。より堅牢な強制メカニズム、またはモデルが新しい能力を内面化し統合する方法におけるさらなる進歩が必要かもしれません。近い将来において、実用的なアプローチとしては、モデルを活用してルールベースの開発ツール（ESLintルールや自動テストなど）を洗練させ、それによって人間主導のワークフローを強化することであり、自己改善のためにモデルが自身の作成物を自発的に採用することにのみ頼るべきではありません。