AIコーディングエージェントの進化と課題：Cloud Codeの光と影

導入：AIコーディングエージェントとの出会い

2025年の春、友人のArmen Rona氏が私にこう言いました。「マリオ、あのコーディングエージェントが、ついに本当に使えるようになったぞ」と。私は半信半疑でしたが、その言葉に背中を押され、Armen氏と共に24時間体制でClankers、Wipe Code、Wipe Slopといったツールに没頭しました。この経験は私たちの働き方を一変させ、それ以来、私たちは睡眠時間を削って多くのものを開発し続けています。

当時のAIエージェントの性能は目覚ましく、手作業では考えられなかった量のコードを短期間で生み出すことができました。しかし、この急速な進化の中で、私は既存のコーディングエージェントやそのフレームワーク、いわゆる「ハーネス」と呼ばれるものに対する不満を募らせていきました。そして、「自分で作ってみたらどうなるだろう？」という疑問が、私を次のステップへと突き動かしたのです。

本記事では、私の個人的な経験に基づき、AIコーディングエージェントの進化の軌跡、特にCloud Codeを中心としたツールの変遷と、その過程で私が得た学びや直面した課題についてお話しします。これらの知見が、AIを活用した開発に携わる皆様の一助となれば幸いです。

AIコーディングエージェントの夜明け：ChatGPTからCopilotへ

2023年初頭、多くの開発者にとってAIを活用したコーディングの始まりは、ChatGPTからのコードの「コピー＆ペースト」でした。生成されるコードはしばしば不完全で、単一の機能に特化したものが多く、実用には手直しが必要な場面がほとんどでした。

その後、GitHub Copilotが登場し、開発者のワークフローに大きな変化をもたらしました。Visual Studio Code内で「トントン」とキーを叩くだけでコードが補完され、時には「幸福」をもたらすこともありました。しかし、その一方で、John Carmack氏の逆平方根アルゴリズムのようなGPL（General Public License）コードを平然と提示するなど、ライセンスに関する問題も指摘されていました。

この時期には、AdirやAutoGPTといった初期のプロトタイプ的なエージェントも存在しましたが、これらはまだ本格的な実用レベルには至っていませんでした。

Cloud Codeの登場と「自律的検索」の衝撃

2024年11月にベータ版としてリリースされ、2025年2月～3月頃に本格的に普及し始めたCloud Codeは、AIコーディングエージェントの分野に革新をもたらしました。Cloud Codeの開発チームは、その後の業界の方向性を決定づける「自律的検索（autonomic search）」という概念を打ち立てたのです。

従来のAIエージェントがコードベース全体を事前にインデックス化しようとするアプローチとは異なり、Cloud Codeは強化学習されたモデルがファイルツールやBashツールを駆使し、必要に応じてアドホック（その場限り）にコードベースを探索し、コードを理解し、そして変更するという手法を採用しました。このアプローチは非常に効果的で、当時の開発者たちは「睡眠時間を忘れて」コードを量産できるようになりました。シンプルで予測可能なその振る舞いは、私のワークフローにも完璧にフィットしていたのです。

進化の影：Cloud Codeの課題と複雑化

しかし、Cloud Codeもまた、多くのAIツールが陥りがちな罠に足を踏み入れてしまいました。それは、「エージェントが膨大なコードを書けるなら、考えうる限りのあらゆる機能を盛り込んでしまおう」というものです。この結果、Cloud Codeはまるで「ホーマー・シンプソンの宇宙船」のように、機能過多の巨大なツールへと変貌を遂げていきました。

現在では、Cloud Codeが提供する機能のうち、実際にユーザーが利用するのはわずか5%程度、知っているのは10%に過ぎず、残りの90%は「AIのダークマター」として、誰もその実態を把握できていない状態だと私は感じています。私個人としては、エージェントが何をしているのかを理解できるべきだと考えており、このような不透明さは非常に問題だと感じていました。

オブザーバビリティとコンテキスト管理の難しさ

Cloud Codeは、オブザーバビリティ（可観測性）やコンテキスト管理の面で課題を抱えていました。エージェントがどのような思考プロセスでコードを生成・変更しているのかが分かりにくく、意図しない挙動が発生しても原因の特定が困難でした。

ターミナルUIの「ちらつき」問題と過剰な複雑化

また、ターミナルユーザーインターフェース（TUI）における「説明不能なちらつき」も大きな問題でした。開発チームのメンバーが「我々のTUIは今やゲームエンジンだ」と発言したことには、ゲーム開発のバックグラウンドを持つ私としては非常に違和感を覚えました。実際のところ、これはReactをTUIに利用しているが故に、UIグラフの再描画に12ミリ秒もかかるという、単純なパフォーマンス問題でした。Ghostyの開発者であるMitchell氏も指摘するように、ターミナル自体は非常に高速な描画が可能であり、問題はCloud Codeのコードの実装にあるのです。

バックエンドの不安定性と予測不可能なワークフロー

Cloud Codeは、バックエンド側で頻繁な変更が行われ、ユーザーのコンテキストに予期せぬ追加テキストが注入されることがありました。2025年夏には、私がバックエンドへのリクエストを傍受するツールを作成し、どのような追加テキストが裏で注入されているかを調査した結果、これが日々、あるいは2日おきに変わっていることが判明しました。

このような頻繁かつ無通知の変更は、開発者が安定した予測可能なワークフローを構築しようとする際に、大きな障害となります。ツールのベンダーが裏側で小さな変更を加えるたびに、LLM（大規模言語モデル）の挙動が狂い、既存のワークフローが破壊されてしまうのです。大規模なユーザーベースを持つツールにおいて実験が必要であるという彼らの視点は理解できるものの、その負担がすべてユーザーに強いられる形となっていました。

シンプルなツールへの回帰

Cloud Codeの努力と成果、そして彼らがこの分野の先駆者であることは疑いの余地がありません。しかし、私個人としては、予測可能でシンプルなツールを好む人間であり、Cloud Codeの進化は私のワークフローやニーズに合わなくなっていきました。

頻繁なバックエンドの変更によるコンテキストの操作、そしてそれに伴うワークフローの不安定さは、開発者にとって大きなフラストレーションとなります。我々が求めるのは、魔法のように何でもこなす「宇宙船」ではなく、安定して予測可能で、開発者がその挙動をコントロールできる、信頼性の高い「道具」なのかもしれません。

まとめ

AIコーディングエージェントの進化は目覚ましいものがあり、私たちの生産性を飛躍的に向上させる可能性を秘めています。しかし、その進化の過程で、ツールの複雑化や不透明性が、かえって開発体験を損なう可能性も浮上しました。

本記事を通じて、私は「シンプルで予測可能なツール」の価値、そしてエージェントの挙動に対する「透明性」と「オブザーバビリティ」の重要性を再認識しました。今後のAIコーディングエージェント開発においては、単に多くの機能を詰め込むだけでなく、開発者が安心して利用できる安定した基盤と、エージェントの思考プロセスを理解できるインターフェースの提供が鍵となるでしょう。AIとの協働がより効果的で快適なものとなるよう、ツールの設計思想にもっと目を向けるべき時が来ているのではないでしょうか。

参考動画: https://www.youtube.com/watch?v=Dli5slNaJu0