Table of Contents

Deep Agentsは、設定可能なモデルと組み込みのコンテキスト管理を備えた汎用エージェントの第一候補です。 Claude Agent SDKはClaude Codeの実行動作を組み込む用途に適しています。アプリケーション固有のエージェントではOpenAI Agents SDKとPydantic AIを試す価値があります。Piは小さく拡張可能なコアを重視し、LangGraphは明示的なワークフロー制御を重視します。

最適な選択は、受け入れる仕事で決まります。 調査アシスタント、リポジトリ編集ツール、顧客要求を処理するサービスでは、必要なツールと復旧ルールが異なります。これらは2026年10月10日に公式ドキュメントを確認した編集上の判断であり、実測性能ベンチマークの結果ではありません。

要点

  • 最初に抽象化を選ぶ: assembled agent、application SDK、workflow runtimeのどれかを決めます。
  • 実行境界を確認する: ツール承認、ファイルシステム分離、ネットワークポリシーは別の問題を解決します。
  • 復旧をテストする: 会話履歴だけでは外部操作の重複を防げません。
  • 受け入れた作業を測る: コスト比較に失敗、レビュー時間、インフラを含めます。
  • モデルを明示する: モデルとエージェントソフトウェアを同時に変えると、ソフトウェアだけでなくシステム全体をテストします。

ハーネスが提供するもの

エージェントハーネスは、モデル呼び出しを囲むソフトウェアです。 コンテキストを準備し、ツールを公開し、承認済みの操作を実行し、結果を返し、継続または停止を決めます。実装によっては、メモリ、委任、権限、復旧も管理します。

モデルは次の操作を提案します。ツールは操作を実行します。ランタイムはワークフローを実行して保持します。パッケージ製品では責任が重なる場合があります。それでも分けて考えると、不足している機能を特定できます。

コンポーネント問うこと
コンテキスト管理長い実行でも残る要件は何か。
ツール実行引数を検証し、権限を制限するのは誰か。
状態保存プロセス再起動後に何が残るか。
検証完了を示す証拠は何か。

例示的なサポートエージェントに、注文を確認して交換依頼を準備させるとします。注文の読み取り、交換の提案、送信には別々の権限を与えるべきです。説得力のある説明は送信権限を証明しません。保存した記録も、送信済みかどうかを証明しません。

範囲: このガイドは組み込み可能なソフトウェアとランタイムを比較します。日常的な開発者向けインターフェースについては、別の CLIコーディングエージェント比較 または GUIコーディングエージェント比較 を使用してください。SDK比較を、ターミナルツールとエディター拡張の順位付けにすり替えないでください。

実用的な候補

最初の要件最初に評価する候補残る主な責任
汎用エージェントDeep Agentsバックエンド、権限、モデルを設定する
アプリ内のClaude CodeClaude Agent SDK実行プロセスを運用して分離する
アプリケーションのツールワークフローOpenAI Agents SDKツール、承認、受け入れ条件を定義する
型付きPythonアプリケーションPydantic AIとHarnessパッケージ機能とワークスペースを選ぶ
最小の組み込み可能なコーディングコアPi SDK拡張と実行ポリシーを組み立てる
明示的で永続的なワークフローLangGraphグラフ状態と復旧動作を設計する

これらは異なる出発点です。 Deep AgentsはすでにLangGraphを使うため、選択は必ずしも二者択一ではありません。Pydantic AIも、中心のエージェントフレームワークと組み立て済みハーネス機能を分けています。各行を交換可能なライブラリとみなさず、所有するアプリケーションコードの量を比較してください。

受け入れテストを満たす最小の層から始めます。 制限されたツール呼び出しには型付きアプリケーションフレームワーク、自由度の高いファイル作業や調査にはassembled agent、復旧と遷移に名前付き状態が必要なら明示的なグラフを使います。メモリ、シェルアクセス、サブエージェントは、簡単な層では足りないとテストが示してから追加します。

Deep Agents：組み立て済みの機能

ファイル、ツール、長い会話を扱うエージェントなら、まずDeep Agentsを評価します。 公式概要 には、ファイルシステムバックエンド、コンテキストの退避、要約、サブエージェント、人間による承認が記載されています。LangChainとLangGraphランタイムを基盤にし、複数のモデルプロバイダーと統合します。

設定が動作を決めます。 現行ドキュメントでは、バージョン0.7以降のタスク計画はオプトインです。古いリリース向けのチュートリアルが現在のデフォルトを示すとは考えないでください。評価ではパッケージバージョンと有効なミドルウェアを記録します。

権限の範囲を慎重に確認します。 文書化されたファイルシステム規則は組み込みファイルツールを対象にしますが、サンドボックスバックエンド経由の任意のシェルコマンドは対象外です。別の実行経路が同じファイルに届くなら、ファイルツールの拒否だけでは不十分です。バックエンドとシェル境界を一緒にテストしてください。

私の推奨: 組み立て済みの機能とプロバイダー選択が必要な文書分析またはリポジトリ作業サービスでは候補に入れます。2つの限定的なAPI呼び出しと検証済みの応答が仕事なら、より小さい出発点を選びます。ツールが増えるほど評価対象の動作も増えます。

Claude：組み込み実行

アプリケーション内にClaude Codeのエージェントが必要ならClaude Agent SDKを選びます。 Anthropicは、Claude Codeと同じ実行ループ、ツール、コンテキスト管理を使うPythonおよびTypeScriptライブラリとして説明しています。SDKは、利用者が運用するプロセスでClaude Codeバイナリを実行します。基本のAnthropic APIクライアントやホスト型Managed Agentsとは別物です。 Agent SDK概要 。

既存の実行システムを再利用できる点が利点です。 ファイル操作、コマンド、フック、権限、セッション、サブエージェントが文書化された機能として利用できます。統合側はアプリケーション境界とタスク固有の受け入れ確認を提供します。

ホスティングは設計上の判断です。 Anthropicの デプロイガイダンス は、ファイルシステム制御、ネットワーク制限、分離を扱います。権限プロンプトをOS境界とみなさず、プロセスの周囲に制御を設定します。

私の推奨: ファイルやコマンド作業が多いClaude中心の文書またはコード自動化で評価します。ローカルモデルと複数のホスト型プロバイダーを比較することが中心要件なら、プロバイダーに柔軟な別の選択肢を使います。

組み立て済みの選択肢統合の重点
Deep Agentsモデル選択、ミドルウェア、バックエンド設定
Claude Agent SDKアプリケーションプロセス内でClaude Codeを実行

OpenAI：アプリケーションのツールワークフロー

関数、委任タスク、明示的な出力を中心に構成するアプリケーションならOpenAI Agents SDKを選びます。 概要 には、エージェントループ、ハンドオフ、ガードレール、トレーシング、サンドボックスエージェント機能が記載されています。これはCodex開発者アプリケーションとは別のビルダー向けインターフェースです。

承認は設定可能な動作です。 human-in-the-loopガイド は、判断後に再開するための中断実行とシリアライズ状態を説明します。ローカルのシェルおよびパッチツールでは承認はオプトインです。承認コールバックを追加するだけでは、承認必須にはなりません。

モデル対応はOpenAIだけに限りません。 プロバイダードキュメント は外部プロバイダーの統合箇所とアダプターを説明します。選択したエンドポイントで構造化出力、ツール呼び出し、トランスポートを検証してください。

私の推奨: 有用な操作が明確なアプリケーション関数として存在するサービスで候補に入れます。注文を取得し、通常のコードで対象条件を計算し、構造化された依頼を準備する例があります。モデルが次のツールを選ぶ場合でも、認可と条件確認はアプリケーションに置きます。

Pydantic AI：型付きアプリケーション

Python型と検証済み出力が中心ならPydantic AIを選びます。 コアドキュメント は、型付きツール、依存性注入、構造化出力、永続実行の統合を扱います。検証は必要な出力構造を確認します。各フィールドの真偽までは確認しません。

別のHarnessパッケージが組み立て済み機能を追加します。 ドキュメント にはCoderとResearcherのスタック、ファイルシステムとシェルアクセス、メモリ、ワークスペース統合があります。ローカルワークスペースと分離サンドボックスは異なる実行選択です。必要なハーネス機能にはワークスペースが必要です。

私の推奨: 型付きレコードを返すPythonサービスではコアフレームワークを候補にします。ワークスペース探索や自由な調査も必要ならハーネス機能を追加します。具体的な必要性なしに、限定された抽出サービスへシェルアクセスを持ち込まずに済みます。

例示的な請求書レビューエージェントでは、スキーマ検証が合計値の数値性と通貨の許可集合を確認します。別のアプリケーションロジックが合計を明細と比較し、出典の証拠を確認します。試験には両方を含めます。

アプリケーション上の関心受け入れ確認
構造化出力フィールドを検証し、意味を独立に確認する
承認待ち保留中の操作と判断を正確に保存する
プロバイダー変更ツール呼び出しと出力の互換性テストを繰り返す

Pi：小さく拡張可能なコア

コンパクトなコーディングエージェント実装を直接制御したいならPiのSDKを選びます。 プロジェクトドキュメント は、対話インターフェースに加えてSDKとRPCの統合を説明します。標準ツールは読み取り、書き込み、編集、シェル実行で、追加動作には拡張を使います。

小ささは統合側の作業を増やします。 Piは組み込みの権限ポップアップとサブエージェント調整を意図的に省いています。確認フローにはコンテナまたはカスタム拡張を使うよう文書は案内しています。別ベンダーのGUIエディターと端末インターフェースを比べず、組み込みSDKを評価します。

私の推奨: 実行制限、拡張レビュー、復旧ポリシーを自分で管理できるなら、個別設計のコーディングサービスでPiを候補にします。小さなコアは動作の理解と変更に向きます。承認と調整が組み立て済みであることが主要件なら、最初の選択肢としては弱くなります。

LangGraph：明示的なワークフロー制御

ワークフロー自体に明示的な状態と遷移が必要ならLangGraphを選びます。 永続化ドキュメント は、スレッド単位のチェックポイントとスレッド間ストアを区別します。永続チェックポインターはプロセス再起動後の復旧を支えます。メモリ内チェックポインターは支えません。

LangGraphはランタイムの土台です。 ワークフローを定義し、モデル主導の動作を置く場所を決めます。Deep Agentsはすでにこの土台を使っています。実行経路を直接制御したい場合にLangGraphへ下りる意味があります。

私の推奨: 名前付き段階、レビュー待ち、個別の復旧ルールを持つプロセスで候補にします。文書受付ワークフローなら、フィールド抽出、検証、レビュー要求、承認済み記録の公開を行えます。モデルが内容を選んでも業務プロセスを勝手に作らないようにするには、固定された遷移が役立ちます。

ワークフロー段階完了の証拠
抽出出典にリンクした候補レコード
検証決定的なチェックと例外
レビュー特定の候補に結び付いた判断
公開操作に対応する外部レシート

外部効果には別の復旧設計が必要です。 グラフ状態の保存だけでは、リモートサービスの取引とチェックポイントをアトミックにしません。操作IDを使い、送信を再試行する前に外部結果を照合します。

足りない部分をテストする

機能一覧は出発点にすぎません。 各候補を実際の負荷に似た失敗へ通します。使い捨てワークスペースと合成レコードのテストサービスを使います。

テスト残す証拠
送信中断復旧後の外部効果が1回だけであること
長い会話元の要件が維持されること
拒否された操作別のツール経由でも効果がないこと
信頼できない文書指示文書テキストが権限を得ないこと
不正なツール引数アプリケーション変更前に拒否されること
予算枯渇検査可能な部分作業を伴う制限停止

重複を明確に定義します。 交換依頼サービスでは、テストサービスが依頼を受理した後、ローカル完了状態を保存する前にワーカーを停止します。再起動後、ワークフローは操作IDを調べ、無条件に再送しません。これは提案するテストであり、記載した製品の観測結果ではありません。

コンパクション後に証拠を確認します。 重要な要件をタスクの早い段階に置き、設定したコンテキスト戦略が動く量の現実的な資料を与えます。最終成果物と出典をエージェントに求めます。私たちの CLMとエージェントメモリの分析 は、メモを保持することと正確な証拠を保持することが別の問題だと説明します。

テレメトリの送信先を確認します。 ツールのトレースとメモリストアにはタスクデータが含まれることがあります。どのシステムが受け取り、どれだけ保持するかを記録します。ローカルモデル推論でも、ログ、検索、実行がローカル限定になるとは限りません。

受け入れたタスクのコストを比較する

2つの評価軸を使います。 制御比較では、対応できる範囲でモデル、ツール、タスクセット、予算をそろえます。デプロイ比較では各候補が想定する設定を使います。前者は一部のソフトウェア効果を分離します。後者は、どの完全な構成が仕事に合うかを答えます。

対応しない設定を制御比較に押し込みません。 共通モデルやツールインターフェースがなければ、比較をシステム評価として報告します。設定の手間と人間による誘導も記録します。

# Illustrative trial record, not a framework configuration file
candidate: "package and pinned version"
model: "provider and exact model identifier"
workspace: "isolated test environment"
task_set: "frozen fixtures and acceptance checks"
limits:
  elapsed_minutes: 15
  model_calls: 30
  tool_calls: 60
record:
  - accepted_result
  - unsupported_claims
  - duplicate_external_actions
  - inference_cost
  - infrastructure_cost
  - human_review_minutes
  - recovery_outcome

タスクごとに複数回試します。 失敗試行も分母に残し、生の件数と割合を併記します。小規模な試験は失敗パターンを示しますが、安定した業界順位は示しません。

コスト計算例: 設定Aが10回の試行で12ドルを使い、8件を受け入れたとします。受け入れタスクあたりの推論コストは1.50ドルです。設定Bは8ドルで4件を受け入れたため、2.00ドルです。どちらも人間のレビューやインフラを含みません。これらは別の記録済み合計に入れます。

失格となる失敗を先に決めます。 無許可の送信やユーザー間のデータ漏えいを平均品質スコアに埋め込まないでください。要件を適用した後、正確さ、復旧、レビュー作業、コストを比較します。

範囲を限定して選ぶ

2つの候補と1つの実際のワークフローから始めます。 プロバイダーに柔軟なassembled agentなら、Deep Agentsとアプリに合う狭い候補を比較します。サービス内でClaude Codeの動作が必要ならClaude Agent SDKを試します。型付きアプリケーションではPydantic AIとOpenAI Agents SDKを比較します。追加統合に価値があるならPi、明示的なワークフロー制御が優先ならLangGraphを選びます。

試験の前提: 承認済みのモデルアクセス、合成フィクスチャ、必要な場合の分離ワークスペース、記述した受け入れ条件を用意します。最初の午後を設定と基本的な失敗テストに使い、本番判断の前に繰り返し実行します。外部操作と復旧要件により、難度は中級から上級です。

要件を満たす最小のシステムを選びます。 試験フィクスチャ、パッケージバージョン、失敗記録を保存します。モデル、コンテキスト戦略、ツール、実行バックエンドを変えたら再実行します。変更後は評価対象のシステムが変わります。

参考資料