【2026年2月】AIエージェントのフレームワーク：いつ使う？どれを選ぶ？LangChain？Claude Agent SDK？
AIエージェント開発におけるフレームワーク（LangChain、Claude Agent SDK等）の選択基準と使用タイミングについて、アプリケーションの種類に応じた判断を解説。
キーポイント
RAGアプリケーションでは単一モデルプロバイダーの場合は公式クライアントライブラリで十分で、複数プロバイダー対応にはLiteLLMなどの軽量ライブラリが適している
エージェンティックワークフローでは基本的にフレームワーク不要だが、チェックポイント機能やHuman-in-the-Loopが必要な場合はLangGraphなどのフレームワークが有用
ファイルシステム上で動作するコーディングエージェント（Claude Codeなど）は汎用エージェントとして業務活用でき、既製品を活用するアプローチも有効
影響分析・編集コメントを表示
影響分析
この記事は2026年2月時点でのAIエージェント開発の実践的指針を提供しており、フレームワーク選択の判断基準を明確化することで、開発者の意思決定を支援する内容となっている。特に「フレームワークを使わない選択肢」を正当化している点が実務的価値が高い。
編集コメント
フレームワーク過熱の中で「使わない選択肢」を冷静に論じた実践的な記事。2026年時点の状況を想定しているが、現状（2024年）でも参考になる判断基準が多い。
【2026年2月】AIエージェントのフレームワーク、いつ使う？どれを使う？LangChain？Claude Agent SDK？
ジェネラティブエージェンツの大嶋です。
LLMアプリケーション・AIエージェントの開発で、フレームワークを使う？使わない？という議論が盛り上がっています。 LangChain、Strands Agents、OpenAI Agents SDK、Claude Agent SDK、その他たくさんありますが、これらはいつ使うべきなのでしょうか？ また、使うならどれを使うべきなのでしょうか？
この記事に、「AIエージェントのフレームワーク、いつ使う？どれを使う？」という疑問について、2026年2月時点での私の考えをまとめます。
実装するアプリケーションの種類によって判断が異なると考えているので、アプリケーションの種類ごとに書いていきます。
エージェンティックワークフロー
ファイルシステム上で動作するエージェント（コーディングエージェント）の自作
💡 LangChainに詳しいため、LangChain関係の例が多めになります。
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
このようなエージェントをスクラッチで実装するのはなかなか大変なので、フレームワークの便利さを実感しやすいです。 逆に、もしもスクラッチで実装すると、既存のフレームワークの再実装に近いことになりやすいです。
なお、Deep Agentsのようなエージェントをさらにカスタマイズしたい場合は、LangChainのcreate_agent
原文を表示
ジェネラティブエージェンツの大嶋です。
LLMアプリケーション・AIエージェントの開発で、フレームワークを使う？使わない？という議論が盛り上がっています。 LangChain、Strands Agents、OpenAI Agents SDK、Claude Agent SDK、その他たくさんありますが、これらはいつ使うべきなのでしょうか？ また、使うならどれを使うべきなのでしょうか？
この記事に、「AIエージェントのフレームワーク、いつ使う？どれを使う？」という疑問について、2026年2月時点での私の考えをまとめます。
実装するアプリケーションの種類によって判断が異なると考えているので、アプリケーションの種類ごとに書いていきます。
エージェンティックワークフロー
ファイルシステム上で動作するエージェント（コーディングエージェント）の自作
💡 LangChainに詳しいため、LangChain関係の例が多めになります。
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
このようなエージェントをスクラッチで実装するのはなかなか大変なので、フレームワークの便利さを実感しやすいです。 逆に、もしもスクラッチで実装すると、既存のフレームワークの再実装に近いことになりやすいです。
なお、Deep Agentsのようなエージェントをさらにカスタマイズしたい場合は、LangChainのcreate_agent
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み