なぜ自律型AI開発は失敗するのか。PydanticAIで堅牢なシステムを構築する理由

SNS運用を自動化しませんか？

ThreadPostなら、投稿作成・画像生成・スケジュール管理まで全てAIにお任せ。

AIエージェントのデモはもう飽きた

AIエージェントのデモは華やかだ。「勝手に考えて動く」「自律的にタスクをこなす」。GitHubのスター数は爆増し、SNSでは開発者の仕事がなくなると騒がれる。いざ自分のプロダクトに組み込むと、途端に動かなくなる。

ReActと呼ばれる自律ループは、本番環境では脆い。コストは跳ね上がり、出力は安定せず、無限ループの恐怖が付きまとう。AIに任せるという言葉の裏で、開発者の妥協が牙を剥く。今、必要なのは自由なAIではなく、型にハマったAIだ。

PydanticAIがバージョン1.0に到達した。このフレームワークが示しているのは、自律性の追求ではない。決定論的なワークフローと、確率的なLLMの境界線を引くことだ。その設計思想が、本番で動くAIシステムを作る道になる。

構造化出力という武器

PydanticAIが注目を集めている。バリデーションライブラリとして有名なPydanticの開発元が作ったフレームワークだ。2024年末に公開され、2025年9月にはバージョン1.0に到達した。Thoughtworksのテクノロジーレーダーでも、試すべき技術として評価を上げている。

最大の特徴は、構造化出力の強化だ。出力型にPydanticモデルを指定するだけで、LLMの回答を型安全なオブジェクトとして受け取れる。PydanticAIの真髄は、バリデーション失敗時の自動リトライにある。

LLMが型に合わないデータを返したとする。真偽値を求めているのに「完了」という文字列が返ってくる。PydanticAIは、そのエラー内容をLLMにフィードバックし、即座に再生成を命じる。開発者が泥臭いエラーハンドリングを書く必要はない。型定義そのものが、LLMの品質を矯正するフィルターとして機能する。

また、ベンダーニュートラルであることも特徴だ。OpenAIやAnthropic、Googleのモデルを同じインターフェースで扱える。特定のプラットフォームにロックインされるリスクを減らせる。各社固有の高度な機能を使い切るには、プロバイダーごとの設定が必要になる場面もある。

しんたろー：
賢いAIよりも壊れないシステムが欲しい。デモで1回動くことよりも、本番で1万回エラーを出さずに動くことの方が100倍価値がある。PydanticAIを触っていると、その実務の重みをわかっていると感じる。

※この記事は、Claude Codeで1人SaaS開発しているしんたろーが、海外AI最新情報を開発者目線で解説する「AI活用Tips」です。

開発者が直面する「自律性の幻想」

ReActという手法がある。思考と行動をループさせ、LLM自身に次は何をすべきかを判断させるやり方だ。2022年に提案されたこの手法は、未知の環境を探索するには向いている。業務システムに持ち込むと、扱いづらいものになる。

業務には監査や承認ワークフロー、ロールベースのアクセス制御が必要だ。AIが勝手に判断しましたでは、責任の所在が不明確になる。SLAを守ることも難しくなる。自律エージェントの製品説明に、これらの業務用語が出てこないのは、本番運用を射程に入れていない証拠だ。

業務を4つの象限で整理する。1つ目は、決定論的な自動化。帳票の転記やデータ整形など、スクリプトで十分な領域だ。2つ目は、古典的な最適化。配送ルートの計算など、アルゴリズムが解決する領域だ。3つ目は、判断を伴う業務。法務相談や診断補助など。人間が主役で、AIは知識の検索と整理を担う。4つ目が、決定論的パイプラインの中の意味判断だ。

業務AIの主戦場はこの意味判断にある。フローの8割はコードで固め、残りの2割の意味的な解釈だけをLLMに任せる。prompt chainingやroutingといった、事前に経路が決まったパターンだ。LLM自身に経路を決めさせてはいけない。経路は人間が書き、LLMはそこを通るパーツとして使う。

Claude Codeを使って開発していても、この感覚は鋭くなる。AIに全部やってと頼むよりも、このファイルをこの型に従って修正してと指示する方が速い。自律性を高めるほど、コントロールを失う。PydanticAIが提供するRunContextによる依存性注入は、制御のための仕組みだ。既存のデータベース接続や認証情報を、安全にAIの処理の中に持ち込める。

しんたろー：
Claude Codeでコードを書いていると、自律エージェントの危うさがわかる。勝手に判断してファイルを消されたらたまったもんじゃない。開発者がここまではやっていいという境界線を型で定義するのが一番安心できる。自由すぎるAIは、不安定なプログラムでしかない。

ここまで読んだあなたに

今なら無料で全機能をお試しいただけます。設定後は完全放置でプロ品質の投稿を毎日生成。

無料で始める

リアルタイム体験と接続管理の罠

ユーザー体験を語る上で、ストリーミングは欠かせない。長い回答を待たせるストレスを軽減する。開発者にとってストリーミングは、リソース管理の課題だ。

通常のAPIリクエストは一瞬で終わる。ストリーミングは、回答が終わるまで接続を維持し続ける。ここで接続のクローズを忘れると、サーバーのリソースが食いつぶされる。Pythonであれば、with文によるコンテキスト管理が必須だ。エラーが起きても、正常に終わっても、確実に接続を閉じる。

また、flush=Trueの設定も重要だ。これがないと、バッファにデータが溜まり、リアルタイムに表示されない。ユーザーは止まっていると勘違いし、ブラウザを閉じてしまう。ストリーミング実装は、UIの装飾ではなく、インフラ運用の一部だ。

PydanticAIは、このストリーミングと構造化出力を両立させようとしている。途中の経過を表示しつつ、最終的には型に沿ったデータを受け取る。この過程と結果の両立が、実用的なAIアプリには求められる。特に、ツール呼び出しを伴うループをストリーミングで返すのは、実装の難易度が高い。標準的なアダプターは増えているが、独自のフローを組むなら、イベント分岐を自前で書く必要がある。

しんたろー：
ストリーミングの実装でflush=Trueを忘れて、数分間悩んだことがある。原因はいつもこういう地味なところにある。with文でしっかり囲むのも、基本だけど一番大事。派手なAI機能よりも、こういうお作法を守る方が開発者としては信頼される。

実務で勝つためのアクションアイテム

自律エージェントの幻想を捨て、本番で動くシステムを作るために何をすべきか。まず、業務フローの棚卸しだ。どの部分が手順が決まっているコードで、どの部分が意味判断が必要なLLMなのか。これを明確に切り分ける。LLMにフローの制御を渡してはいけない。

次に、型定義の徹底だ。Pydanticを使って、LLMの入出力を厳格に定義する。バリデーションエラーを恐れる必要はない。エラーが出ることでLLMの出力を矯正できる。output_retriesの設定を適切に行い、システムが自動でリトライする仕組みを組み込む。

そして、テスト戦略の転換だ。AIシステムのテストは、単体テストよりもインテグレーションテストに寄る。プロンプトを少し変えるだけで、結果が激変するからだ。PydanticAIのようなフレームワークを使い、モックやテスト用のアダプターを活用する。ストリーミングやマルチターンのテストはまだ手薄な領域だが、そこをカバーしたチームが勝つ。

最後に、依存性の管理。AIの処理をブラックボックスにせず、RunContextなどを通じて明示的にデータを渡す。グローバル変数や隠れた状態に頼ると、デバッグが不可能になる。型安全な境界線を引くことが、開発者の精神衛生を守る武器になる。

よくある質問への核心回答

Q1: ReActエージェントを避けるべき業務とはどのようなものですか？

請求書照合、チケット振り分け、住所正規化など、処理手順が明確で次に何をすべきかがルール化されている業務です。これらはLLMに判断を委ねるのではなく、決定論的なパイプラインでフローを制御し、例外的な意味判断のみをLLMに任せるべきです。ReActはループが回るため、コスト予測が困難で、監査ログの追跡も複雑になるため、業務システムには不向きです。

Q2: PydanticAIを使う最大のメリットは「型」だけですか？

いいえ、最大のメリットはバリデーション失敗時の自動リトライと依存性注入（RunContext）の統合です。LLMの出力が期待した型と異なる場合、エラーを投げるだけでなく、その内容をLLMにフィードバックして再生成を促すループが自動化されています。これにより、アプリ側で複雑なエラーハンドリングを書く必要がなくなり、コードの堅牢性が向上します。

Q3: ストリーミング実装で最も注意すべき点は？

接続のクローズ漏れです。ストリーミングはリクエストとレスポンスが分断され、接続を張り続けるため、Pythonのwith文を使用して、正常終了時だけでなくエラー発生時にも確実に接続を閉じる設計が必須です。また、flush=Trueを忘れるとバッファにデータが溜まり、リアルタイム表示のメリットが消えるため注意してください。