これからのAIエージェント開発

はじめに

みなさんはAIエージェントを、どんなロジックで開発していますか？

この記事では、AIエージェント開発のこれまでを振り返り、現在の状況をまとめて、今後どうなっていくのかを考えてみようと思います。

わかりやすくなるように、極端に簡略化している部分や個人的な見解でまとめている部分があります。あらかじめご了承ください。

なお、「AIエージェントって何？」という方は、よろしければ先にこちらの解説スライドを！

1. AIエージェント開発の歴史

LLMが登場して、人間の書くような文章を生成できるようになりました。そして、文章を作らせるだけでなく人間にようにいろいろな仕事をやらせよう！AIエージェントを作ろう！という研究が活発になりました。

ここからは、AIエージェント開発に対する人類の試行錯誤を、主要な論文を確認しながら振り返ってみます。

（2021年12月）LLMに専用ブラウザを操作させた「WebGPT」

LLMは文章を生成するだけでしたが、その文章として「ブラウザを操作するコマンド」を生成させて、その通りにブラウザを操作してあげることでLLMにネット検索をさせられないか？という挑戦をしたのが「WebGPT」です。

ブラウザといっても、みなさんがお使いのようなChromeやSafariやEdgeのようなものではなく、研究用のテキストベースのブラウザで、それを操作するためのコマンドが用意されています。下の表はコマンドの一覧で、たとえば「検索」とか「指定したIDのリンクをクリックする」とか「下にスクロールする」といったものの集まりです。

LLMに対して調べたいことを入力すると、ブラウザを操作するためのコマンドが生成されます。そのコマンドをプログラム側で実行してあげて結果をLLMに返すと、また次に操作すべきコマンドが生成されます。これを繰り返し、最後に調べた結果が返ってくるような流れです。

Function CallingやTool Callingみたいだね、と思われた方、正解です！ただし、まだ汎用的ではありません。この論文で使っているLLMはGPT-3というモデルで、それに対して追加学習を実施することにより、どんな時にどんなブラウザのコマンドを生成すべきかを覚え込ませています。そのため、専用ブラウザ以外のツールを操作させることはできませんし、使うLLMが変わってしまったらこのファインチューニングもやり直しになります。

（2022年5月）プロンプトでツールを教えることに成功した「MRKL」

「MRKL」は、複数のツールの使えるようにしたものです。

WebGPTはブラウザしか使えませんでしたが、複数のツールが使えるようになりました。この論文では、気象情報サービスと連携して天気を調べたり、通貨変換の機能と連携したりといった実験をしています。ツールの説明はプロンプトで伝えていますが、設定によっては精度を上げるためにファインチューニングも一部併用しています。

この連携の考え方はFunction Callingと同じです。ただし、LLMの機能としてFunction Callingが実際に登場したのは2023年6月¹なので、この論文より1年くらい後になります。

（2022年10月）ツール利用がきまぐれにならないようLLMに考え方を指示した「ReAct」

LLMにツールの仕様を伝えても、ツールを使わずにいきなり結論を生成してしまったり、ツールで検索せずに思い込みで答えてしまったりといったことが起きます。これを改善するために考案されたのが「ReAct」です。

ReActでは、いきなりツールを使ったり結論を生成させるのではなく、まず思考（Thought）して、次に行動（Act）し、その結果を観察（Obs）するという手順を繰り返すようにプロンプトで指示しています。下の図の（1d）は、そのような手順を指示すると難しい質問にも答えられたという例です。思考（Reasoning）と行動（Action）を繰り返すので「ReAct」という訳ですね。

（2023年4月）タスクを分解させて優先順位を考えながら行動させる「BabyAGI」

これは論文ではないのですが、LLMに対して自律的に仕事をやらせる実装パターンとして「BabyAGI」が考案されました。

これは、ゴールに向けてまずタスクを分解し、そのタスクの中で優先順位の高いものを実行し、その結果を後続タスクが再利用できるように保存し、タスクの優先順位も見直して再びタスクを実行する、という下の図のようなシンプルなループを繰り返すことで、ゴールに向けて自律的に処理を進める形になっています。

一見うまくいくように思えるのですが、実際には次のような課題に気づくきっかけとなりました。

• ループにハマってしまうことがある
• 状態管理が難しく、タスクリストが破綻してしまったり、誤りがメモリに記憶されてしまって後続に悪影響が出る
• ループによってコンテキストが肥大化し、コストや精度に影響してしまう
• 使えるツールが足りない、検索くらいしかできない

どんな仕事でもこなせる「汎用型」のAIエージェントの実現は、かなり難しいことが見えてきました。

2. AIエージェント開発の最近

この頃から、仕事の進め方までLLMに考えさせるのではなく、特定の仕事に特化した固定のワークフローを組んでしまい、そのタスクの中でLLMを使うというアプローチが増えてきました。

（2024年1月）競技プログラミング専用のAIエージェント「AlphaCodium」

競技プログラミングの問題を解くことに特化した「AlphaCodium」は、あらかじめ仕事のフローをプログラムで固定しています。

フローは下の図のようになっています。
まず、前処理として問題の要点を整理し、公開テストの意図を推論します。そして、解法の候補を生成し、それをランク付けし、追加のAIテストを生成します。
そして、実際にコードを生成し、公開テストで繰り返し評価と修正を繰り返し、AIテストでも評価と修正を繰り返してコードを完成させます。

このAIエージェントはこのフロー通りにしか処理できませんが、精度を改善することができました。

（2025年4月）研究を自動で進めるAIエージェント「The AI Scientist v2」

同様に2024年8月に発表された研究を自動で進めるAIエージェント「The AI Scientist」も、仕事のフローをプログラムで固定したものです。

2025年4月には後継の「The AI Scientist v2」も発表されました。

The AI Scientist v2のフローは下の図のようになっています。
まず、LLM によって研究仮説やアイデアを生成し、既存論文を検索して新規性をチェックしたうえで、それらを評価し、有望なアイデアを選抜します。
次に、選ばれたアイデアを起点として、実験コードの実装をノードとする木構造の探索を行います。ここでは、バリエーションを分岐させながら並列に実験を実行し、性能の良いノードを選びつつ探索を進めます。具体的には、まずアイデアの基本的な妥当性を確認する予備的検証を行い、その後、ベースライン性能を引き上げるためのハイパーパラメータ調整を実施します。続いて、本命となる仮説検証を繰り返し、どの要素が効果的だったのかを分析します。
最後に、実験結果から図表を作成し、論文の構造に沿って原稿を執筆します。生成された論文は、別のLLMによって査読・評価され、その結果が次の探索や改善の判断材料として用いられます。

このAIエージェントもこのフロー通りにしか処理できませんが、ワークショップの査読を通過するような論文を生成できています²。

3. AIエージェント開発のいま

このように、AIエージェントの研究当初は「汎用型」を目指していたのですが、最近は目的に特化した「ワークフロー型」のものが増えてきました。

汎用型の方が当然ながら適応能力が高いのですが、どうしてもLLM任せになってしまうので制御が難しくなってしまいます。これに対して、ワークフロー型はワークフローから外れたことはできないので適応能力は下がるものの、コントロールはしやすくなります。

（2025年12月）本番稼働AIエージェントの調査

2025年12月に、「Measuring Agents in Production」という調査レポートが公開されました。これは、実際に本番・パイロット稼働しているAIエージェントの実態を調査したもので、対象データはAIエージェントを積極的に構築している306人への調査と、そこから抽出した86件のデプロイ済みAIエージェントの調査結果、そして20件の詳細なケーススタディです。

この中で特徴的だったのは、詳細ケーススタディ20件のうちの80%が構造化された制御フロー（structured control flow）、つまりワークフロー型だったことです。詳細ケーススタディが20件しかないので全体を語ることはできないかもしれませんが、まだ汎用型のAIエージェントを本番で使うのは少数派のようです。

他にもいくつか気になる結果が載っていました。

• デプロイ済みAIエージェントの68%が10ステップ未満で処理が終わるような小規模な仕事で利用されている
• デプロイ済みAIエージェントの74.2%は人間の評価をフローの中に挟んでいる
• 詳細ケーススタディの85%はサードパーティのフレームワークを使わず自作している

ご興味がありましたらぜひレポートをご参照ください。

4. AIエージェント開発のこれから

現時点では、AIエージェントとして汎用型を目指しつつも、本番活用する場合はワークフロー型にするのが現実的といった状態のようです。

ただ、コーディングエージェントであるAnthropic Claude Codeの進化が、この状況を打破し始めたように感じているので、ここからはそんなお話を少ししてみます。

「Claude Code」は汎用型のAIエージェントとして使える

Anthropic Claude Codeはプログラムを開発してくれるAIエージェントです。すでに利用されている方も多いでしょう。

このClaude Codeは、コーディングに特化したワークフロー型のAIエージェントかと思いきや、実は汎用型のAIエージェントとして使えます。たとえば、MCPでツールを渡せばいろいろなことができ³、コーディング以外のこともさせることができます。

そうなのです。実は汎用型のAIエージェントに相当するものが、すでに本番環境としてみなさんのお手元で使えるのです。灯台下暗し。

Claude Codeは汎用型AIエージェントの課題を解消中

おさらいになりますが、汎用型AIエージェントの進化がつまずいてしまった理由として、以下のような課題をあげました。

• ループにハマってしまうことがある
• 状態管理が難しく、タスクリストが破綻してしまったり、誤りがメモリに記憶されてしまって後続に悪影響が出る
• ループによってコンテキストが肥大化し、コストや精度に影響してしまう
• 使えるツールが足りない、検索くらいしかできない

これはClaude Codeでも発生することですよね。でも、Claude Codeでは、MCP対応やコンテキストの自動圧縮、スキル、スラッシュコマンド、サブエージェントなどの機能でこれらの解決に向けて進化しています。

弊社でもClaude Codeをコーディング以外で活用中

ちなみに私の所属しているジェネラティブエージェンツでも、Claude Codeを汎用型のAIエージェントとして活用しています。

先日開催されたJAWS-UG Presents - AI Builders Dayで、同僚の @ruzia さんが「AgentCore BrowserとClaude Codeスキルを活用した『初手AI』を実現する業務自動化AIエージェント基盤」というタイトルでお話しています。ご興味ありましたらこちらをぜひ！

実はAnthropic本家もコーディング以外に使っている

これはAnthropicのブログなのですが、Claude Codeをコーディング以外にも活用していて、マーケや法務のような非エンジニアの方も汎用AIエージェントとして活用されているそうです。

この感じだと、AIエージェントのPoCの第一歩は、開発などせずにClaude Codeのような汎用型のAIエージェントでちょっとやってみよう！みたいな形になっていきそうですね。

また、汎用型のAIエージェントであればエンジニアではない方でも進められるようになりそうなので、事業部門の内製化なども進んでいきそうな予感です。

おわりに

AIエージェント開発のこれまでを振り返り、現在の状況をまとめて、今後どうなっていくのかを考えてみました。

当初は汎用型を目指していたAIエージェントがさまざまな課題でつまずき、最近は用途特化のワークフロー型が増えてきました。しかし、Claude Codeのような汎用型のAIエージェントの進化が加速したことで、再び汎用型が中心になっていきそうな予感がする、というお話でした。

この記事が、AIエージェント開発における何かの参考になりましたら幸いです。
最後までお読みいただきありがとうございました。

（おまけ）

これから汎用型のAIエージェントを学ぼうという方には、Claude Codeを学ぶことをおすすめします。前述のように汎用型AIエージェントの課題を解消するための機能がどんどん搭載されており、それを実感しながらAIエージェントをキャッチアップできます。

また、「実践Claude Code入門 ―現場で活用するためのAIコーディングの思考法」が2025年12月26日に発売されます。この本はClaude Codeの使い方の解説だけでなく、汎用型AIエージェントの仕組みも学べる内容になっていてホントおすすめです！

1. OpenAI社の発表：Function calling and other API updates ↩

2. Sakana AIの発表：The AI Scientist Generates its First Peer-Reviewed Scientific Publication ↩

3. MCPは信用できるもののみ設定してください。また、書き込み系のツールは環境を破壊してしまうことがあるので、段階的な許可やsandboxでの利用をおすすめします。 ↩