ジェネラティブエージェンツの大嶋です。
LLMアプリケーション・AIエージェントの開発で、フレームワークを使う？使わない？という議論が盛り上がっています。 LangChain、Strands Agents、OpenAI Agents SDK、Claude Agent SDK、その他たくさんありますが、これらはいつ使うべきなのでしょうか？ また、使うならどれを使うべきなのでしょうか？
この記事に、「AIエージェントのフレームワーク、いつ使う？どれを使う？」という疑問について、2026年2月時点での私の考えをまとめます。
実装するアプリケーションの種類によって判断が異なると考えているので、アプリケーションの種類ごとに書いていきます。
- RAGアプリケーション
- エージェンティックワークフロー
- 簡単なエージェント
- コーディングエージェント
- ファイルシステム上で動作するエージェント（コーディングエージェント）の自作
💡 LangChainに詳しいため、LangChain関係の例が多めになります。
RAGアプリケーション
RAGアプリケーションを実装する場合、フレームワークを使う必要はないことが多いと思います。
このことは以下の記事に分かりやすく書かれています。
この記事の主張の通り、単一のモデルプロバイダーのみであれば、OpenAIやAnthropicなどのクライアントライブラリを使えば十分でしょう。 ベクトルデータベースなどのアクセスも、公式クライアントライブラリを使えばよいでしょう。
もしも複数のモデルプロバイダーをサポートしたい場合、LiteLLMなどが軽量なライブラリとして候補になります。
もちろん、すでに手に馴染んだフレームワークがある場合は、それを使ってもよいと思います。
エージェンティックワークフロー
続いて、LLMを何度か呼び出すようなエージェンティックワークフローを実装する場合です。
エージェンティックワークフローの実装は、最初の一歩としてはフレームワークは不要です。 ワークフローの各ステップを関数として実装して、順番に呼び出せば十分です。
Pythonだと以下のようなイメージです。
def workflow(query: str) -> str: step1_output = step1(query) step2_output = step2(step1_output) step3_output = step3(step2_output) return step3_output
分岐・ループもプログラミング言語の機能で実装するのが分かりやすいでしょう。
チェックポイント機能を使いたい・Human-in-the-Loopを実装したい場合
エージェンティックワークフローでフレームワークの利用を検討したいのは、チェックポイント機能を使いたい・Human-in-the-Loopを実装したい場合です。
ワークフローの実行が長時間に及ぶケースでは、途中でAPIのエラーなどが発生した場合に続きから処理を再開したいことは多いです。 そんなとき、チェックポイント機能がほしくなることがあります。
簡単なチェックポイント機能であれば、自前で実装してもよいかもしれません。 しかし、ワークフローの全ステップを記録したいといった場合は、エージェンティックワークフローのフレームワークが提供するチェックポイント機能を使ったほうが便利なこともあります。
チェックポイント機能の用途には、Human-in-the-Loopもあります。 Human-in-the-Loopを含むワークフローの実装は、スクラッチだと煩雑になります。 ローカルで動かす程度の場合はメモリ上にHuman-in-the-Loopの入力待ちの状態を保持できますが、サーバーにデプロイするアプリケーションではそうはいきません。 個人のローカル環境で動かすのではなくサーバーにデプロイして動かすのであれば、Human-in-the-Loopの実装はフレームワークを使った方が簡単なことが多いです。
チェックポイント機能やその上でのHuman-in-the-Loop機能をサポートするフレームワークの例としては、LangGraphが挙げられます。
簡単なエージェント
続いて、簡単なエージェントを実装したい場合です。
ここで「簡単なエージェント」と言っているのは、モデル・ツール・システムプロンプトを設定するだけで使える、ツール呼び出しを繰り返すだけのエージェントを指しています。
たとえば、LangChainのcreate_agentです。
create_agent(
model=model,
tools=tools,
system_prompt="You are a helpful assistant."
)
このようなエージェントを実装したい場合、LangChain・Strands Agents・OpenAI Agents SDKなどいくつかの選択肢があります。
簡単なエージェントを実装したい場合、どのフレームワークを使うかは好み次第という印象です。 OpenAI Agents SDKのような、軽量なフレームワークが好まれることも多いでしょう。
ツール呼び出しの承認などのHuman-in-the-Loopを実装したい場合は、Human-in-the-Loopをサポートしているフレームワークを選択しましょう。
ただし、このような簡単なエージェントが上手にタスクを遂行できるのか？という問題があります。 最近では、このような簡単なエージェントよりも上手に働くエージェントが存在します。
コーディングエージェント
Claude Codeなどのコーディングエージェントは、汎用エージェントとして業務タスクにも活用できます。 ファイルの読み書きやプランなどの機能により、前述の「簡単なエージェント」よりも上手にタスクをこなせることが多いです。
そのため、AIエージェント自体は実装せず既製品（例：Claude Code）を使い、そのエージェントにうまく仕事をさせるためのプロンプト・ツール・スキルなどを整えればよいこともあります。
AnthropicのCoworkのように、このようなエージェントを簡単に業務で使えるようにする製品も登場し始めています。
もしClaude Codeを特定の順番で呼び出すような処理をプログラムで実装したいのであれば、Claude Agent SDKが便利です。
ファイルシステム上で動作するエージェント（コーディングエージェント）の自作
コーディングエージェントの大きな特徴は、ファイルシステム上で動作することです。
業務に必要な情報をファイルとして配置して、必要に応じて読み書きさせることができます。 追加のツールを与えたり、スキル・サブエージェントなどの設定ファイルを配置して拡張することもできます。
現在最もうまく働くエージェントは、このようなファイルシステム上で動作するエージェントではないでしょうか。 なお、コーディング以外の業務で使うことを想定して、ここでは「ファイルシステム上で動作するエージェント」という表現を使っています。
しかし、Claude Codeなどのコーディングエージェントは、あくまでソフトウェア開発のタスクに特化して実装されています。 コーディングエージェントのような動作をベースとして、システムプロンプトを変更したり、Human-in-the-Loopをサポートしたい場合があります。
そのようなファイルシステム上で動作するエージェントを自作したい場合、LangChainのDeep Agentsが選択肢となります。
Deep Agentsは、「簡単なエージェント」に、プラン・ファイルシステムの操作・コマンドの実行・サブエージェントなどの機能を搭載したものです。
LangChainのcreate_agentとMiddleware機能で構築されています。
LangChainはv1からLangGraphを基盤としているため、前述のチェックポイント機能やHuman-in-the-Loopもサポートされています。
このようなエージェントをスクラッチで実装するのはなかなか大変なので、フレームワークの便利さを実感しやすいです。 逆に、もしもスクラッチで実装すると、既存のフレームワークの再実装に近いことになりやすいです。
なお、Deep Agentsのようなエージェントをさらにカスタマイズしたい場合は、LangChainのcreate_agentとMiddleware機能で自作することも選択肢となります。
