地獄のAIエージェント開発（2025年版）
AIエージェント開発は今、まさに地獄だ。
2005年頃のWebアプリ開発の現場を知っていれば、あれがそのまま当てはめられる。
IEとFirefoxで別のCSSを書き、動くかどうかは祈りで決まり、jQueryが救世主に見えた——あの時代が、LLMとプロンプトとエージェントフレームワークの三つ巴で完全再現されている。
幸いにもこの苦労を知らない若い世代に向けて説明すると：
- フレームワークの寿命が、それを学ぶのにかかる時間より短い
- ベストプラクティスが存在しない。正確に言えば、存在するが週替わり
- 今日書いたコードが、来週には「なぜそんな古いやり方を？」と言われる世界
エージェントの定義が3回死んだ
2022年11月30日、ChatGPTが登場した。そこからLLMを使ったAIエージェント開発が模索され始めた。
2023年頃はまだ「エージェント」と呼ぶには非力で、「ReAct」などと言っていた。
プロンプト＋ツールコールの組み合わせ。推論→行動→フィードバックという段階を踏むことがエージェントだった。シンプルで、理解しやすく、トークン消費も控えめだった。
ツールの活用も原始的だったため、事前に知識を注入するRAGが狂気的に流行していた時期でもある。
この定義は、2024年のClineやManusの登場で最初の死を迎える。
エージェントループ＋タスクの自律的な実行。エージェントのライフサイクルは、それまでの「1推論が完了するまで」から「1タスクが完了するまで」に変わった。
トークン利用量が爆発的に増加したのがこのタイミングだ。課金額を見て震えた開発者は少なくないだろう。
そして2つ目の死。Computer UseとClaude Codeが引き金を引き、2025年にはエージェント開発の世界が大きく変わった。
自律的な振る舞いに加えて、OSやサービス（MCPを介して）を、LLMの持つ知識で活用する。
ブラウザを操作し、ターミナルでコマンドを叩き、ファイルを編集する。人間と同じ——いや、人間より速く正確にタスクをこなす。もはや「ツールを呼ぶ」レベルの話ではない。
あれだけ騒がれていたRAGも、このタイミングで完全に退場した。少なくとも「RAGだけで戦う」時代は、ここで終わった。
私自身、RAG関係のプロジェクトを進めていたこともあり、あの全ての努力が一瞬で陳腐化した瞬間を今もよく覚えている。
2025年の今、Claude.ai、Cursor、Gemini——トップランナーたちの作るAIエージェントはどれも、自律的に振る舞い、タスクが完了するまで死力（と、トークン）を尽くし、あらゆる手段をもってタスクに取り組む。
もはや動く場所を選んでいないというのもご存知だろうか。Claude Desktopから直接リモートランナーを起動してClaude Codeを実行したり、CursorもCloud AgentやBugbot(GitHub Actions統合)という形で、もはやエージェントはそこかしこで動き回り始めている。
3度目の死は、今まさに進行中だ。エージェントの定義は、もはや追いかけるものではなく、トップランナーたちが思いのままに書き換え続けるものになった。
開発現場で何が起きているか
エージェントアプリの要求は、日々高度なものになり続けている。
顧客は常に、最新のChatGPTやClaude.aiを引き合いに出す。
半年前に開発に着手したエージェントアプリがベンチマークとしていたのは、その当時のChatGPTだが、半年後にはそのChatGPTはすでに古く、誰も覚えていない。
1年も経たずにアプリのベストプラクティスは変わり、当然アプリの開発も変わる。フレームワークは学び終わる前に陳腐化し、磨き上げたプロンプトも変えなければならないが、アプリと密結合しており、移植は作り直しを意味する。
LangChainで組んだ社内ツールはまだ動いているか？ CrewAIのマルチエージェント設計は、本番投入した時点でもまだSOTAだったか？ 成功と呼べるプロジェクトだったか？
残念ながら、MITによれば企業のAI投資の95%は失敗しているという。我々の大半は、何らかの形で失敗を経験しているはずだ。
そしてその結末は、おおよそ「塩漬け」か「作り直し」だろう。
トップランナーたちの進化の速さに対して、尻込みするか、諦めるかの二択。まさに座して死を待つ、まな板の鯉状態になっているチームは少なくないはずだ。
プロンプトは肥大化し、誰も触れなくなる
技術的な地獄もある。
最初は綺麗だったプロンプトが、機能追加のたびに膨れ上がる。エッジケースを追加し、例外処理を追加し、「でもこの場合は」を追加する。気づけば5万トークンの小説が完成している。
そしてLLMは混乱し始める。指示Aと指示Bが矛盾し、どちらを優先すべきかわからない。長すぎるコンテキストで「注意力」が分散し、明らかに書いてある指示を無視する。
Context rotだ。トークンが増えるほど、モデルの精度は下がる。より大きなコンテキストウィンドウは解決策ではない。根本的なトレードオフだ。
そして誰もそのプロンプトを触れなくなる。「動いているから触るな」。レガシーコードと同じ匂いがする。
フレームワークに縛られ、資産は移植できない
さらに厄介なのが、フレームワーク依存だ。
LangChainで書いたエージェントを、Mastraに移植できるか？ できない。言語の問題以前に、プロンプトの構造が違う、ツールの呼び方が違う、メモリの扱いが違う。
つまり、フレームワークを選んだ瞬間、そのフレームワークと心中することが決まる。
だがフレームワークは死ぬ。あるいは、大幅に書き換わる。LangChain 0.1から0.2への移行で何人が泣いた？ 「破壊的変更」という言葉の重みを、我々は身をもって知っている。
蓄積した資産——プロンプト、ツール設計、エージェント構成——は、フレームワークの死と共に価値を失う。
だが、その苦労は開発者だけの問題だろうか？
フレームワークを乗り換えれば、エージェントの振る舞いは変わる。プロンプトを書き直せば、応答のトーンも変わる。昨日まで使えていた機能が、今日は「仕様変更」で消えている。
ユーザーから見れば、それは「改善」ではなく「改悪」かもしれない。慣れ親しんだ振る舞いが突然変わり、期待した応答が返ってこなくなる。
我々開発者は「技術的負債の返済」と呼ぶ。だがユーザーにとっては、単に「使いにくくなった」だ。
フレームワークの都合、モデルの都合、開発チームの都合——すべてがユーザー体験に転嫁される。
これが、エージェント開発の地獄がユーザーにまで波及する瞬間だ。
当然我々はこうなるリスクを知っているので、容易に手出しが出来なくなる。
REST APIをフレームワーク上で書いて居た時よりも、ずっと大きな変化へのリスクがあることは明らかだ。
もはやソフトウェア的な観点からフレームワークを選ぶのではなく、どの棺桶に入るのが心地よいかを選ぶことに変わりがない。
セキュリティは「お前の問題」
そして本番環境。マルチユーザー。セキュリティ。
従来のエージェントフレームワークは、アプリケーションプロセスの中でエージェントを動かす。つまり、エージェントはアプリと同じ権限を持つ。
「トップランナー級のエージェント」を作ろうと思えば、ファイルシステムにアクセスでき、ネットワークに出られ、環境変数を読めるくらいは必要だ。
だが、十分な考慮なしに作れば、ユーザーAのリクエストを処理中に、ユーザーBのデータにアクセスできる状態になってしまう。
リスクを恐れてエージェントに権限を与えない？ それでは、ClineやManusの時代で止まったエージェントしか作れない。
現在のSOTAエージェントは、その裏に強大なセキュリティ設計がある。
「サンドボックスを自分で作れ」「コンテナで隔離しろ」「権限を絞れ」——全部正しい。
だが、それを全部自分でやるのか？ エージェント開発の上に、インフラエンジニアリングまで載せるのか？ 何人のエンジニアを集めればそれが実現可能になる？
地獄から抜け出す道はあるのか
ここまで読んで「あるある」と頷いているなら、あなたと私は同じ地獄にいる。
同志。まだしばらく、地獄は続きそうだ。
根本的な問題は、ソフトウェアの世界では当然のことである「分離」と「境界線の定義」ができていないことだ。
なぜIEはクソだと言われていたか。MSが独自の仕様で動き、標準化に抗っていたからだ。ブラウザとWebの分離ができていないことから生じた摩擦であり、その摩擦で消耗させられたのが我々開発者だった。
エージェント開発でも同じことが起きている。それもありとあらゆる場面で。
LLMプロバイダーが「囲い込み」と「垂直統合」での競争を繰り返している。
LLMプロバイダーごとにAPIが違う。モデルの特性が違う。ツールの呼び方が違う。ギャップを埋めるためにVercel AI SDKやLangChainなどのフレームワークが必要とされる。
どこもエージェントフレームワークを作っている。OSSのエージェントフレームワークは把握しきれないほどの数があるし、恐らく把握する必要もない。
MCPは福音だった。囲い込みや垂直統合とは異なり、LLMと外部データソースやツールを接続するための標準的な方法を提供してくれた。
だがMCPだけでは足りない。ツールの接続方法が標準化されても、エージェントそのものの定義方法は標準化されていない。プロンプトの構造は各フレームワークに依存し、エージェント間の連携方法もバラバラだ。
必要なのは、エージェント開発における「境界線」の再定義だ。
- モデルとエージェントの分離: エージェントの定義は、特定のLLMプロバイダーに依存すべきではない
- エージェントとフレームワークの分離: エージェントの資産は、フレームワークが死んでも生き残るべきだ
- エージェントとアプリケーションの分離: エージェントは、実行環境から独立して定義されるべきだ
Webの世界では、HTMLとCSS、JavaScriptが分離された。ブラウザとWebサーバーが分離された。フロントエンドとバックエンドが分離された。それぞれの境界線が明確になったことで、エコシステムが爆発的に成長した。
エージェント開発には、まだこの「境界線」がない。
境界線がない世界では、技術の発展速度と密結合が掛け算になり、すべてのコードは半年でレガシーになる。だから地獄なのだ。
我々はどこへ向かうのか
正直なところ、地獄がいつ終わるかはわからない。
Webの標準化が軌道に乗るまでに10年以上かかった。HTML5が勧告されたのは2014年。jQueryが救世主に見えた2006年から数えても8年だ。エージェント開発の世界が同じ道を辿るなら、まだ入り口にすら立っていない。
だが、希望がないわけではない。
MCPのような標準化の動きは確実に進んでいる。そしてMCPがAnthropicから生まれたことは象徴的だ。トップランナーですら、囲い込みではなくオープン化を選んだ。
歴史を振り返れば、答えは見えている。
IEは死んだ。MSの囲い込みは、Web標準を推進するコミュニティに敗北した。Flashも死んだ。プロプライエタリな技術は、オープンなHTML5に置き換えられた。
勝者を決めるのは、トップランナーではない。使われ続けるものが標準になる。それを選ぶのは我々開発者だ。
OpenAIが何を決めようと、Anthropicが何を決めようと、Googleが何を決めようと、最終的にエコシステムを形作るのは、我々開発者の選択の集積だ。
使われない標準は死に、使われる標準が生き残る。それがオープンソースの、インターネットの、そしてソフトウェア開発の歴史だ。
だから、我々在野の開発者にできることは、実は限られていない。
作るか、選ぶか、声を上げるか。
作るなら、自分が正しいと思う「境界線」を定義し、その中でより良いものを作ろう。それが間違っていれば自分が地獄を作る側になるが、正しければコミュニティの一部になる。
選ぶなら、何を選ぶかをよく考えよう。使われるものが生き残る。だから、何を使うかは投票だ。その一票が、地獄を長引かせるか、終わらせるかを決める。
声を上げるなら、問題を言語化しろ。地獄を共有することで、同じ問題意識を持つ仲間が見つかる。仲間が集まれば、標準が生まれる。
2025年末の今、私はまだ地獄にいる。
2023年に開いた地獄の釜は、まだまだ底が見えない。それでも、少なくとも何が問題なのかは見えてきた。問題が見えているなら、必ず解決策も見つかるはずだ。
ホリデーシーズンに入り、トップランナー各社の立て続けの製品リリースは一通り終わった。今年の年末も休む時間はどうもなさそうだ。学ぶことは多く、やることはもっと多い。
この界隈にいる多くの開発者も、恐らく似たような師走や年末年始の過ごし方なのだろう。
それでは同志諸君、地獄で会おう。
Discussion