ローカル AI エージェント用 Python フレームワーク 7 選

image

導入

すべての判断をクラウド API に委ねるエージェントは、いわば「知能を借りている」状態です。API キーが必要で、トークン数に応じて請求が発生し、回答が返ってくる前にデータがあなたのマシンから外部へ送信されてしまいます。

一方、ローカル環境で動作するよう設計されたエージェントなら、そうした手間やコストは一切不要です。モデルをダウンロードすれば API キーは不要になり、実行後は 1 回の呼び出しごとの費用もかかりません。さらに、ユーザーが明示的に指示しない限り、データがネットワーク外へ流出することもありません。

ただし、すべてをローカルで動かすには、クラウドの API の向こう側にあるモデルではなく、自社のハードウェア上に置かれたモデルと実際に通信する方法を理解した「オーケストレーション層」が必要です。

以下に紹介するのは、2026 年の現在、エンジニアたちが実際に活用している Python ツール 7 つです。モデル自体を配信するランタイムから、エージェントがそのモデルを使って何を行うかを決定するフレームワークまで、ローカルインフラ上でエージェントを構築・調整・実行するためのツール群をご紹介します。

1. Ollama

ローカルで何かをオーケストレーションする前に、まずはモデルを実行できる環境が必要です。Ollama は、オープンソースの大規模言語モデル（LLM）を自分のマシン上で動かすための軽量ランタイムです。いわば LLM 向けの Docker のような存在と言えます。

コマンド 1 つでモデルをダウンロードし、別のコマンドでローカル API を経由して提供開始できます。Python 環境の構築も不要ですし、手動で CUDA ドライバーをインストールする必要もありません。

このリストにあるほぼすべてのフレームワークの基盤となっている Ollama の特徴は、ある特定の設計思想にあります。それは OpenAI と互換性のある API を公開している点です。これにより、カスタムアダプターを組むことなく、ほとんどのエージェントフレームワークにそのまま組み込むことができます。さらに、データがローカルマシンから流出しないというプライバシーのメリットや、モデルをダウンロードした後はリクエストごとにコストがかからないという経済的なメリットも併せ持っています。

ただし、Ollama は生来のスループット性能を追求して作られたものではないため、単一の開発者のノートパソコンを超えてスケールする際にはその点を理解しておく必要があります。高並列なワークロードに対応する必要がある場合、チームは開発段階では Ollama のシンプルさを活かしつつ、パフォーマンスが必要になった際に vLLM の PagedAttention によるサービングと組み合わせるという戦略をとることが一般的です。その際も、上層のエージェントオーケストレーションレイヤーはそのまま維持します。

# 2. Smolagents

エージェントが何をしているのかを、抽象化の層を掘り下げることなく正確に把握したいなら、Hugging Face が提供する smolagents が最適です。このライブラリでは、エージェントのロジック全体をおよそ 1,000 行のコードで完結させつつ、生コードの上に最小限の抽象化レイヤーを設ける設計になっています。また、モデル非依存であり、ローカルの transformers や Ollama モデルに加え、数十ものホスト型プロバイダーにも対応しています。

このフレームワークの最大の特徴は、エージェントの動作に関する独自の哲学にあります。smolagents は「コードエージェント」を第一級としてサポートしており、アクションを事後に生成するのではなく、コードそのものとして記述・実行できる点が特徴です。安全性のために、Docker や E2B、Modal を介したサンドボックス環境での実行にも対応しています。

知っておくべき重要なトレードオフは、小規模なオープンソースモデルでは性能が急激に低下し、パラメータ数が 70 億未満の領域になるとバグが頻発することです。したがって、このツールは限られたリソースで動作する極小モデルよりも、ある程度能力のあるローカルモデルを動かす場合にこそ真価を発揮します。

# 3. PydanticAI

ツールを呼び出したり構造化データを渡したりするエージェントの信頼性は、出力される形式に依存します。 大規模言語モデル（LLM）がたまに不正な JSON を返してしまうと、パイプライン全体が静かに破綻する恐れがあります。このギャップを埋めるために、Pydantic の開発チームが PydanticAI を構築しました。

PydanticAI は、Python の型ヒントを活用して、エージェントの入力・出力、およびツール呼び出しをすべて型安全にします。 LLM の出力が期待される構造と一致しない場合でも、自動的なスキーマ検証と自己修正機能によって対応可能です。

この特徴により、データの整合性が特に重要なタスクを扱うローカルエージェントに、このライブラリは非常に適しています。PydanticAI はデータを構造化し、検証し、信頼性を確保します。これは金融や医療などコンプライアンス要件が厳しい業界において決定的に重要です。また、あらゆる OpenAI 互換エンドポイントと動作するため、ローカルの Ollama サーバーを指す場合も、別個の統合作業を行う必要はなく、単に接続先を変更するだけで済みます。

プロジェクトは開発スピードが速く、Pydantic コアチームの主導により、2026 年 4 月にはバージョン 1.85.1 に達しました。レビュー担当者は一貫して、型安全性の高さと依存関係の少なさを目玉機能として挙げています。

# 4. CrewAI

単一のエージェントであれば、これまでの設定で十分です。しかし、複数のエージェントがタスクの異なる部分を協力して処理したいとなった瞬間、CrewAI が最初に選ばれるフレームワークとなります。その最大の理由は、動作する状態に素早く到達できる点にあります。

エージェントには役割と目標を定義し、それらを「クルー」というグループにまとめれば、あとは自動的に協働が始まります。ローカルモデルとの連携においては、おそらく最も手軽に使い始められるエージェントフレームワークと言えるでしょう。

ローカルモデルの活用も、単なる後付けの機能ではありません。CrewAI は LangChain や他の外部エージェントフレームワークへの依存を意図的に避け、自己完結型のソリューションとして位置づけられています。デフォルトでは OpenAI モデルをサポートしつつ、Ollama を介したローカル実行環境にも明確に対応しています。さらに、Model Context Protocol (MCP) に対して stdio、SSE、ストリーミング HTTP トランスポートのすべてをサポートしているため、CrewAI のローカル設定であっても、標準化されたツールサーバーにアクセス可能でありながら、基盤となるモデルはローカルファーストを維持したままです。

# 5. AgentScope

前出のフレームワークが「すぐに使い始めること」の最適化を目指しているのに対し、AgentScope は最初から本番環境での利用を想定して設計されています。ローカル展開は例外扱いではなく、第一級オプションとして扱われています。

AgentScope 2.0 は、ワークスペースとサンドボックス機能を備えた本番対応のエージェントフレームワークです。ツールやコードの実行を隔離された環境で行うことができ、ローカル実行、Docker、E2B をサポートする組み込みバックエンドを搭載しています。GitHub で 27,300 星以上を獲得し、その設計思想は 2 つの査読済み論文によって裏付けられています。実際に製品としてリリースする必要のあるマルチエージェントシステムを構築するチームにとって、これは非常に包括的な選択肢の一つです。

プライバシーへの配慮は、単なるおまけではなく明確な設計思想です。エージェントはローカルサーバーや自社クラウドなど、ユーザーが管理するインフラ上で完全に動作します。データが AgentScope のサーバーに送信されることはなく、モデル抽象化レイヤーにより、機密性の高いワークロードでもエージェントコードを書き換えることなく、ローカルまたはプライベートモデルへ容易に切り替えられます。

マルチエージェント間の調整は、同フレームワークが「メッセージハブ」と呼ぶ仕組みによって行われます。エージェントは共有された暗黙的な文脈ではなく、構造化されたメッセージの受け渡しを通じて通信します。これにより、やり取りが透明性を持ち、監査可能になります。これは、どのエージェントがどの決定に影響を与えたのか不明瞭なマルチエージェントシステムのデバッグに苦労した経験がある方にとって、大きな違いとなります。

# 6. LangGraph

LangGraph は、これまでにエージェントオーケストレーションの解説でも取り上げられてきましたが、その理由も納得です。状態管理（ステートフル）、分岐処理、回復機能が必要なあらゆるケースにおいて、事実上のデファクトスタンダードとなっています。

特に注目すべきは、ローカルモデルへの対応です。LangGraph は OpenAI 互換のバックエンドであれば何でも扱えるため、プランニングやツール呼び出しのためにグラフをローカルの Ollama インスタンスに接続する際も、一行の書き換えで済みます。クラウド上で LangGraph を信頼できるものにしているチェックポイント機能——一時停止と再開、タイムトラベルデバッグ、マルチインスタンスでのスケーリング——は、背後にあるモデルが最先端 API であっても、ユーザー自身の GPU で動作するモデルであっても、全く同じように機能します。

単一のプロンプトに答えるだけでなく、より高度な処理を必要とするローカルエージェントにとって、これは特に重要です。信頼性の高いローカルエージェントのループには、予測可能な構造が不可欠です。つまり、モデルが計画を提案し、一度に一つのツールアクションを実行し、その結果を観察して次のステップを決定するという流れです。さらに、このループがクラッシュやステップ間の長時間の待機状態に耐える必要がある場合、LangGraph の永続化レイヤーが、毎回ゼロからやり直すことなく状態を維持する役割を果たします。

# 7. Microsoft Agent Framework

大規模なエンジニアリング組織で期待されるガバナンス機能やミドルウェア機能を必要としつつ、すべてをローカルインフラ上で実行したい場合、Microsoft Agent Framework は知っておくべき存在です。これは、同じチームによって開発され、2025 年 10 月に発表された Microsoft の次世代オーケストレーション SDK です。

AutoGen と Semantic Kernel を統合した統一版であり、AutoGen が持つ対話型のマルチエージェント抽象化と、Semantic Kernel が提供するセッションベースの状態管理やミドルウェア、テレメトリといったエンタープライズ機能が組み合わされています。これにより、両者の利点を兼ね備えた強力な基盤が提供されます。

このリストに選定された理由は、直接かつ明示的なローカルモデルのサポート機能にあります。これは後付けのものではなく、最初から備わっているものです。

このフレームワークは Python パッケージとして提供されており、Microsoft Foundry、Azure OpenAI、OpenAI、Anthropic、Amazon Bedrock、Google Gemini、そして Ollama に対応しています。つまり、エンタープライズ向け機能に特化してこのフレームワークを採用するチームでも、機密性の高いワークロードやオフライン開発のためにローカル環境でエージェントを完全に実行する選択肢を手放す必要はありません。

ただし、広く導入する前に知っておくべき点として、コミュニティからの報告では Azure OpenAI の標準的なパスから外れるプロバイダーアダプターに関する課題が集中していることが挙げられます。Ollama や Microsoft 以外のインフラを主に利用するチームは、本格的な採用前にプロバイダーとの統合を十分に検証しておく必要があります。

# Wrapping Up

これら7つのツールは、同じ仕事を巡って競い合っているわけではありません。Ollama はほぼすべての他のツールが乗る基盤です。smolagents と PydanticAI は、完全なオーケストレーションの一段階下で動作します。前者は最小限の抽象化と「コード＝アクション」を最適化したものであり、後者は型安全性を重視し、出力に不具合があっても許容されないケース向けです。

CrewAI は、ローカル環境でのマルチエージェントのプロトタイプを最速で立ち上げることができます。AgentScope と Microsoft Agent Framework は、ローカル展開において本番グレードの構造、監査証跡、ガバナンスをもたらします。LangGraph はその中間に位置し、ローカルエージェントが単なる応答と停止を超えて複雑な処理を行う必要がある場合、上記のいずれにも耐久性のあるチェックポイント付きのバックボーンを提供します。

適切な選択は、どのフレームワークが「最高か」ではなく、あなたが実際に解決しようとしている制約次第です。プロトタイピングの速度、厳格なデータ検証、本番環境でのガバナンス、あるいは長期間の状態管理など、目的に応じて選定する必要があります。ローカルで実行することと、機能面で妥協することはもはや同じ意味ではありません。重要なのは、あなたが提供したいものに最も影響を与える制約に合わせて設計されたフレームワークを選ぶことです。