Pydantic AI入門｜型安全なAIエージェント開発2026

GitHubスター16,500超、2026年4月時点でv1.84.1。Pydantic AIはPythonの型バリデーションライブラリPydanticの開発チームが手がけるAIエージェントフレームワークで、2025年9月のv1.0リリース以降、本番投入するチームが急増している。

FastAPIがWebフレームワークの書き味を変えたように、Pydantic AIはエージェント開発の「型で守る」体験を持ち込んだ。LangChainの700以上あるインテグレーション群とは設計思想が異なり、最小限の依存で型安全を最優先にしている。実際にチャットアプリを4フレームワークで書き比べたベンチマークでは、実効コード行数160行と最も少なく、開発者体験スコアも8/10で首位だった。

このPydantic AI入門では、インストールから本番運用まで、コード付きで一気に通す。LangChainやCrewAIとの使い分け判断に迷っている人にも、比較表と選定基準を用意した。

Pydantic AIとは — FastAPIの系譜を継ぐエージェントフレームワーク

Pydantic AIを一言で説明するなら「LLMの出力をPydanticモデルで受け取るエージェント基盤」になる。Webアプリ開発でFastAPIがリクエスト/レスポンスの型定義を強制し、バリデーションエラーを実行前に潰してきたのと同じ発想だ。

開発元とライセンス

開発元はPydantic社（Samuel Colvin率いるチーム）。PydanticはPython界で月間3億ダウンロードを超えるバリデーションライブラリで、FastAPI・LangChain・OpenAI SDK内部でも使われている。そのチームが「エージェントでも型安全を当たり前にする」と作ったのがPydantic AI。ライセンスはMIT、完全無料で商用利用に制限はない。

なぜ「型安全」がエージェント開発で効くのか

LLMは自然言語を返す。JSON形式を指定しても、キーが欠けたり型が違ったりする出力が混じる。LangChainでは出力パーサーをチェーンに挟んで対処するが、パーサーの定義と実際のプロンプトが乖離するバグが起きやすい。Pydantic AIはレスポンスの型をPydanticモデルとしてAgentに直接渡すため、IDEの補完が効き、型チェッカー（mypy/pyright）がビルド前にエラーを検出する。

ある比較検証では、開発中に型安全が捕捉したバグが23件。これらは他のフレームワークなら本番に到達していた。ランタイムエラーが減る分、デバッグ時間を別の作業に回せるのが実務上の最大メリットだ。

対応モデルとプロバイダー

モデル非依存設計を掲げ、2026年4月時点で主要プロバイダーをほぼ全て押さえている。

リストにないプロバイダーでも、カスタムモデルクラスを数十行書けばつながる。主要AIサービスの料金比較も参考にしてほしい。

Pydantic AIの主要機能6つ

6つの主要機能を表で俯瞰する。

筆者がとくに評価しているのは依存性注入。テスト時にモックを差し込む設計が最初から入っているため、CIパイプラインにエージェントのユニットテストを組み込める。LangChainでこの設計をやろうとすると、かなり自前で仕組みを作る必要がある。

環境構築とインストール手順

Pydantic AI入門の最初のステップはインストール。Python 3.10以上が必須で、仮想環境を切ってから始める。

基本インストール

# 仮想環境の作成と有効化
python -m venv .venv
source .venv/bin/activate

# Pydantic AIのインストール
pip install pydantic-ai

# 特定プロバイダーのみインストール（軽量化）
pip install "pydantic-ai[openai]"
pip install "pydantic-ai[anthropic]"
pip install "pydantic-ai[google]"

全プロバイダーを一括で入れたい場合は pip install "pydantic-ai[all]" でいい。ただし依存パッケージが増えるので、本番環境では使うプロバイダーだけ指定するほうが安全だ。

APIキーの設定

環境変数でプロバイダーのAPIキーを渡す。.envファイルとpython-dotenvの組み合わせが実務では多い。

# .env ファイル
OPENAI_API_KEY=sk-proj-xxxxx
ANTHROPIC_API_KEY=sk-ant-xxxxx
GEMINI_API_KEY=AIzaSyXxxxx

最初のエージェントを動かす — 10行で完成するHello World

Pydantic AI入門の核心はAgent作成。設計がFastAPIに似ている、と言葉で聞いてもピンとこない。コードを見たほうが早い。

最小構成のAgent

from pydantic_ai import Agent

# モデルとシステムプロンプトを指定してAgentを生成
agent = Agent(
    'anthropic:claude-sonnet-4-6',
    instructions='日本語で簡潔に回答してください。',
)

# 同期実行
result = agent.run_sync('Pydantic AIの特徴を3つ挙げて')
print(result.output)
# => 1. 型安全な構造化出力 2. 依存性注入 3. マルチモデル対応

Agent()がFastAPIのapp = FastAPI()に対応する。モデル文字列のフォーマットはプロバイダー名:モデル名で統一されている。OpenAIならopenai:gpt-4o、Geminiならgoogle-gla:gemini-2.5-pro。

非同期実行とストリーミング

Webアプリに組み込むなら非同期版を使う。FastAPIのエンドポイント内でそのままawaitできる。

import asyncio
from pydantic_ai import Agent

agent = Agent('openai:gpt-4o', instructions='簡潔に回答')

async def main():
    # 非同期実行
    result = await agent.run('Pythonの利点は？')
    print(result.output)

    # ストリーミング
    async with agent.run_stream('長めの解説をお願い') as stream:
        async for chunk in stream.stream_text():
            print(chunk, end='', flush=True)

asyncio.run(main())

検証してみると、run_syncはスクリプトやCLIツール向き、run（async）はWebサーバー向き、run_streamはチャットUIやリアルタイムフィードバックが必要な場面向き、と棲み分けが明確。使い分けで迷うことはほぼない。

ツール定義で外部APIとつなぐ

Pydantic AI入門の中でも実用性が高いのがツール定義。Pythonの関数にデコレータを付けるだけでツール化できる。関数のdocstringがツール説明文としてLLMに自動送信され、引数の型ヒントからJSONスキーマを生成する。手動でスキーマを書く手間がゼロ。

基本のツール定義

from pydantic_ai import Agent, RunContext
import httpx

agent = Agent('openai:gpt-4o', instructions='天気情報を調べて回答して')

@agent.tool
async def get_weather(ctx: RunContext[None], city: str) -> str:
    """指定された都市の現在の天気を取得する"""
    async with httpx.AsyncClient() as client:
        resp = await client.get(
            f'https://api.weatherapi.com/v1/current.json',
            params={'key': 'YOUR_KEY', 'q': city}
        )
        data = resp.json()
        return f"{city}: {data['current']['temp_c']}℃, {data['current']['condition']['text']}"

result = agent.run_sync('東京の天気を教えて')
print(result.output)

@agent.toolデコレータで登録完了。LangChainの@toolと違うのは、型ヒントからOpenAI互換のfunction callingスキーマを自動生成する点だ。args_schemaを別途書く手間がゼロになる。

もう1つは第1引数のRunContext。ここに依存性注入された値（DB接続、APIクライアントなど）が入ってくる。テスト時にモックを差し込む入口がここ。

依存性注入（Dependencies）の実践

FastAPIのDepends()と同じ考え方。データベース接続やHTTPクライアントをAgentの外から注入する。

from dataclasses import dataclass
from pydantic_ai import Agent, RunContext

@dataclass
class Deps:
    api_key: str
    db_url: str

agent = Agent(
    'anthropic:claude-sonnet-4-6',
    deps_type=Deps,
    instructions='ユーザーのデータを検索して回答して',
)

@agent.tool
async def search_user(ctx: RunContext[Deps], name: str) -> str:
    """ユーザー名でデータベースを検索する"""
    # ctx.deps.db_url でDB接続にアクセス
    return f"ユーザー '{name}' の情報: エンジニア歴5年"

# 実行時にDepsを渡す
deps = Deps(api_key='sk-xxx', db_url='postgresql://...')
result = agent.run_sync('田中さんの情報を教えて', deps=deps)

この設計の何が嬉しいか。テストではDepsにモック値を渡すだけで、実際のAPIやDBを叩かずにエージェントの振る舞いを検証できる。CI/CDでエージェントのテストを自動化するなら、この仕組みは必須に近い。AIコーディングツール比較2026でもテスト容易性は評価軸の1つにしている。

構造化出力 — LLMの返答をPydanticモデルで型チェック

Pydantic AIの真骨頂がここ。LLMに「JSON返して」と頼むだけでは、キーの欠落や型の不一致が頻繁に起きる。Pydantic AIは出力型をPydanticモデルとして定義し、LLMの返答を自動でバリデーションする。

from pydantic import BaseModel
from pydantic_ai import Agent

class JobPosting(BaseModel):
    title: str
    company: str
    salary_min: int
    salary_max: int
    skills: list[str]
    remote: bool

agent = Agent(
    'openai:gpt-4o',
    output_type=JobPosting,
    instructions='求人情報を構造化して返してください',
)

result = agent.run_sync('Pythonエンジニア、年収600-800万、リモートOK、AWS経験必須')
posting: JobPosting = result.output

# IDEで補完が効く
print(posting.title)       # => "Pythonエンジニア"
print(posting.salary_min)  # => 6000000
print(posting.skills)      # => ["Python", "AWS"]
print(posting.remote)      # => True

output_type=JobPostingを指定した瞬間、result.outputの型がJobPostingになる。mypyやpyrightが「salary_minはintなのにstrとして扱っている」といったバグをエディタ上で即座に指摘してくれる。

筆者が転職サイトのスクレイピングデータを構造化するプロジェクトで試したところ、LangChainのOutputParserで書いていたバリデーションコード約80行がPydantic AIでは0行になった。モデル定義だけで完結する。

型で出力が確定する。次の問いはフレームワーク選定だ。

LangChain・CrewAIとの比較 — どう使い分けるか

エージェントフレームワークを選ぶとき、現実的に候補に挙がるのはPydantic AI・LangChain（LangGraph）・CrewAIの3つ。同じチャットアプリを4フレームワークで実装した比較ベンチマークのデータを元に整理する。

選定基準 — 自分ならどう選ぶか

結論から言う。自分なら新規プロジェクトはPydantic AIで始める。理由は3つ。

LangChainは「何でもできるが、何をしても依存が増える」という構造上の課題がある。Pydantic AIの依存は最小限で、必要なプロバイダーだけ追加する設計。もったいないと感じるのが、Pydantic AIのマルチエージェント機能がまだ手動寄りな点。CrewAIの「Crew」概念のような宣言的なマルチエージェント定義が来れば、選択肢としてさらに強くなる。AIエージェント完全ガイド2026でフレームワーク全体の動向も解説している。

MCP・A2Aプロトコル対応でエージェント間連携

Pydantic AIはMCP（Model Context Protocol）とA2A（Agent2Agent）プロトコルにネイティブ対応している。これが日本語の競合記事ではまだ取り上げられていない差別化ポイントだ。

MCPサーバーとの接続

mcp_serversリストにサーバーを渡すだけで、そのサーバーが公開する全ツールをエージェントが使えるようになる。

from pydantic_ai import Agent
from pydantic_ai.mcp import MCPServerStdio

# MCPサーバーをstdioトランスポートで接続
server = MCPServerStdio('npx', ['-y', '@modelcontextprotocol/server-filesystem', '/tmp'])

agent = Agent(
    'anthropic:claude-sonnet-4-6',
    mcp_servers=[server],
    instructions='ファイルシステムを使ってタスクを実行して',
)

async with agent:
    result = await agent.run('/tmpディレクトリのファイル一覧を教えて')
    print(result.output)

mcp_serversパラメータにMCPサーバーのリストを渡す。サーバーは複数同時に接続できる。MCPサーバーおすすめ2026で紹介しているContext7やPlaywrightとも組み合わせられる。

A2Aプロトコルによるエージェント間通信

A2A（Agent2Agent）はGoogleが提唱したエージェント間通信の標準規格。異なるフレームワークで作られたエージェント同士が情報をやり取りできる。Pydantic AIはA2Aクライアント・サーバー両方に対応しており、Pydantic AIエージェントからLangGraphエージェントにタスクを投げる、といった構成を組める。

MCPが「エージェントとツールをつなぐ」プロトコルなら、A2Aは「エージェントとエージェントをつなぐ」プロトコル。両方に対応しているフレームワークはまだ少なく、Pydantic AIの先行優位性がある。Microsoft Agent FrameworkもA2A対応を進めている。

本番運用のポイント — Logfire連携とデュラブルエージェント

エージェントの本番投入で最初にぶつかるのがコスト監視と障害復旧。Pydantic AIにはLogfire・デュラブル実行・TestModelの3つが揃っている。

Pydantic Logfireで可観測性を確保する

Pydantic Logfireは同じPydantic社が提供するOpenTelemetry互換のオブザーバビリティプラットフォーム。Pydantic AIとの統合は数行で完了する。

import logfire
from pydantic_ai import Agent

# Logfireの初期化（環境変数 LOGFIRE_TOKEN を設定済み前提）
logfire.configure()

agent = Agent('openai:gpt-4o', instructions='質問に回答して')
result = agent.run_sync('Pydantic AIの利点は？')

# これだけで以下が自動記録される:
# - リクエスト/レスポンスの全文
# - トークン使用量とコスト
# - ツール呼び出しの引数と返り値
# - レイテンシ（各ステップの所要時間）

Logfireのダッシュボードでは、エージェントが何回ツールを呼んだか、各呼び出しに何ミリ秒かかったか、トークンコストがいくらかまで1リクエスト単位で追跡する。月間APIコストの内訳を把握するだけでも導入価値がある。

Logfire自体にはフリーティアがあり、個人プロジェクトや小規模チームなら無料で始められる。

デュラブルエージェント — 障害を跨いで実行を再開

外部APIのレート制限やネットワーク障害でエージェントの実行が中断されるのは日常茶飯事。Pydantic AIのデュラブル実行機能は、進捗をチェックポイントとして保存し、障害発生後に途中から再開できる。

長時間実行のバッチ処理（100件の求人データを順次構造化する等）では、50件目で失敗しても51件目から再開できる。この機能がなければ最初からやり直しになり、APIコストも2倍かかる。LangGraphにも類似のチェックポイント機能はあるが、Pydantic AIはフレームワーク本体に組み込まれているため追加設定が少ない。

TestModelでAPIを叩かずにテストする

本番運用の信頼性を支えるのがテスト。Pydantic AIにはTestModelという専用のテスト用モデルがあり、実際のLLM APIを叩かずにエージェントの振る舞いを検証できる。

from pydantic_ai import Agent
from pydantic_ai.models.test import TestModel

agent = Agent('openai:gpt-4o', instructions='質問に回答')

# テスト時はTestModelに差し替え
with agent.override(model=TestModel()):
    result = agent.run_sync('テスト質問')
    # APIを叩かずに実行される
    # ツール呼び出しの順序や引数を検証可能

CI/CDパイプラインでエージェントのリグレッションテストを回せる。APIキーもトークンコストも不要。ここは見落としがちだが、エージェントを本番運用するチームには決定的に重要な機能だ。Claude Agent SDKやMicrosoft Agent Frameworkにも類似のテスト機能はあるが、Pydantic AIの実装は最もシンプル。

よくある質問

まとめ — Pydantic AI入門の次にやるべきこと

型安全、最小依存、テスト容易性。FastAPIがそうだったように、この3点が本番運用コストの差に直結する。

エコシステムの広さではLangChainに、マルチエージェントの手軽さではCrewAIに譲る部分はある。それでも新規プロジェクトで��ージェントを組むなら、自分はPydantic AIから始める。理由は単純で、型安全とテスト容易性が本番運用のコストを下げるから。

v1.0リリースから半年以上が経過し、APIの安定性も確認されている。2025年末から2026年にかけてMCP・A2A対応が加わり、単独エージェントだけでなくマルチエージェント構成やツール連携の選択肢も広がった。AIエージェントの全体像を把握した上で、Pydantic AIを候補に入れてみてほしい。

公式ドキュメント: ai.pydantic.dev / GitHub: pydantic/pydantic-ai