補足：Agentフレームワークの知識
主要なAgent開発フレームワーク
Agentアプリケーションが複雑になるにつれ、開発者はツール呼び出し、知識の統合、状態管理、複数Agent間の協調などの問題に対処する必要がある。これらの機能をすべてゼロから開発すると、作業量が膨大になるだけでなく、各モジュール間の接続や実行制御も複雑になる。
Agentフレームワークはこれらの共通の能力をカプセル化し、Agent開発に統一された実装方法を提供する。以下に代表的なAgent開発フレームワークを紹介する。
LangChainフレームワーク
LangChainは2022年に公開され、大規模言語モデルアプリケーション構築のための早期のオープンソースフレームワークの一つ。LangChainは当初、大規模言語モデル、プロンプト、外部データなどのコンポーネントを組織するために主に使用されていたが、徐々にツール呼び出しとAgentに拡張された。現在、LangChainはAgentをフレームワークの重要な構成要素として統合し、モデル、ツール、ミドルウェアなどのコンポーネントを提供し、ツール呼び出し能力を持つAgentを迅速に構築できるようにしている。
LangChainのコアの実行方式は、大規模言語モデルとツールをループで結びつけること。大規模言語モデルはユーザータスクと使用可能なツールを受け取り、現在の情報に基づいて直接結果を生成するか、ツールを呼び出すかを判断する。ツール呼び出しが選択された場合、フレームワークは対応するツールを実行し、ツールから返された結果を大規模言語モデルに提供する。大規模言語モデルは新しい情報に基づいて判断を続け、ツール呼び出しが不要になり最終結果が生成されるまで継続する。このプロセスは公式にAgent Loopと呼ばれている。
例えば、天気照会、地図検索、ウェブ検索などのツールを持つ旅行アシスタントを設定できる。ユーザーが「明日の杭州への日帰り旅行を計画して」と提案した場合、大規模言語モデルは天気と観光地情報の照会が必要と判断し、対応するツールを呼び出して結果を取得し、それらを組み合わせて旅程を完成させる。
ツールは外部能力を実現する重要な手段。本質的には明確な入力と出力を持つ呼び出し可能な関数で、リアルタイムデータの取得、コードの実行、データベースの照会、外部システムの操作などに使用できる。開発者が必要なツールをAgentに提供した後、大規模言語モデルは現在のタスクに基づいてどのツールをいつ呼び出すか、呼び出し時にどのパラメータを提供するかを判断できる。
このコンポーネント型のアプローチはLangChainの重要な特徴。LangChainは異なるモデルとツールに比較的統一されたインターフェースを提供し、開発者は同じフレームワーク内でこれらのコンポーネントを組み合わせることができ、異なるモデルと外部能力間の呼び出しロジックを個別に処理する必要がない。そのため、ツール呼び出し型Agentの迅速な構築に適しており、初心者がAgentの基本的な実行プロセスを理解するのに適している。
LlamaIndexフレームワーク
LlamaIndexは2022年に公開され、当初は大規模言語モデルと外部データ間の接続問題を解決するために主に使用されていた。データのロード、インデックス、検索、クエリなどの機能を提供し、企業文書、データベースなどの外部データを大規模言語モデルアプリケーションに接続できる。この基盤の上で、LlamaIndexはAgentやワークフローなどの機能を徐々に追加し、Agentがこれらのデータを使ってより複雑なタスクを実行できるようにした。
大規模言語モデル自体は、社内製品文書、ビジネスデータ、企業のデータベースなどの外部データを理解できない。Agentがこれらのデータを活用してタスクを実行する必要がある場合、まず現在のタスクに関連する情報を特定する必要がある。LlamaIndexは外部データのロード、組織化、インデックスを行い、Retriever、Query Engineなどのコンポーネントを通じて検索やクエリが可能。Query Engineは自然言語の質問を受け取り、インデックスから関連データを検索でき、Agentが呼び出せるツールとしてカプセル化することもできる。以下に示すように、Agentはユーザータスクを受け取った後、必要に応じて適切なクエリツールを選択して情報を取得し、大規模言語モデルで分析して最終結果を生成できる。この方法により、すべての外部データを直接コンテキストに配置する必要がなく、タスクの必要に応じて関連データを照会して使用できる。
例えば、企業分析Agentに製品文書照会ツールと業務データ照会ツールを設定する。ユーザーが2つの製品の機能差異の比較を要求した場合、Agentは製品資料に対応する照会ツールを呼び出す。ユーザーがさらに2つの製品の販売状況を質問した場合は、業務データ照会ツールを呼び出す。より複雑な質問の場合、Agentは複数のデータ照会ツールを連続して呼び出し、異なるデータソースの結果を総合してタスクを完了できる。
LlamaIndexはもともとAgent開発用に設計されたものではなく、データと知識の処理に特徴がある。大規模言語モデルにドキュメントを検索させるだけでなく、異なるデータとクエリ能力をAgentが選択・使用できるツールとして組織化できる。ナレッジベースのQ&A、ドキュメント分析、マルチデータソースクエリ、および多数の企業文書、ナレッジベース、構造化データへのアクセスが必要なAgentアプリケーションに特に適している。
AutoGenフレームワーク
AutoGenはMicrosoft Researchチームにより2023年に公開され、マルチAgent開発分野の代表的なオープンソースフレームワーク。Multi-Agent Conversationをコアコンセプトとし、複数のAgentが対話を通じて共同でタスクを実行できるようにする。
AutoGenはAgentを対話可能でカスタマイズ可能なエンティティとして設計。1つのAgentは大規模言語モデル、ツール、手動入力、またはこれらの能力の組み合わせで構成できる。開発者はAgent間の相互作用方法も定義でき、異なるAgentが異なる対話モードを形成できる。全体的な設計は以下に示す。
レッスン 7 / 7 0%完了
lessons.completeLesson ✓
この図はAutoGenの2つの重要な設計コンセプトを反映している。第一に、異なるAgentは異なる能力を持つことができる。第二に、複数のAgentは異なるConversation Patternで組織化され、異なる方法で通信・協力できる。
例えば、ソフトウェア開発タスクでは、要件を分析するAgent、コードを書くAgent、結果を確認するAgentを設定できる。プログラミングAgentがコードを生成した後、結果を確認Agentに送信。問題が検出された場合、確認AgentはプログラミングAgentにフィードバックを返し、タスク要件が満たされるまで修正を続ける。
現在、AutoGenは主にAgentChatとCoreの2つの能力レベルを提供。AgentChatは単一AgentおよびマルチAgentアプリケーション構築のための高レベルインターフェースで、Agent、Teamなどのコンポーネントを提供。開発者は複数のAgentをTeamにまとめ、ローテーション、次のAgentの動的選択などにより協力を組織化できる。Coreはイベント駆動方式を採用し、より柔軟でスケーラブルなマルチAgentシステムの基盤能力を提供。
AutoGenの特徴は、Agent間の通信と協力をフレームワーク設計の重点に置くこと。複数のAgentが分担して作業する複雑なタスクに適している。マルチAgentシステムではAgentの責任と協力方法の追加設計が必要で、簡単なタスクでは通常複数のAgentを使用する必要はない。
CrewAIフレームワーク CrewAIもマルチAgent協力に焦点を当てているが、より現実のチームに近い組織方式を採用。開発者は異なるAgentに役割、目標、タスクを定義し、タスクとワークフローで組織化して共同で作業できる。CrewAIは主に2つの組織方式を提供：Crewsは複数Agent間の自律的協力を強調し、Flowsは構造化されたワークフロー制御を強調。
CrewAI公式が提供するフレームワーク構造は以下に示す。
Crewでは、Agentは特定の責任を持つチームメンバー、Taskは完了する必要がある具体的なタスク、ProcessはAgentとタスクの実行方法を規定し、CrewはこれらのAgentとタスクを組織化して最終目標を達成する。
例えば、業界調査報告書を作成する場合、調査Agent、執筆Agent、査読Agentを作成できる。調査Agentは資料の検索と整理を担当し、執筆Agentは調査結果に基づいて報告書を作成し、査読Agentは報告書の問題を確認する。異なるAgentが異なる責任を負い、タスク間の連携を通じて全体の作業を共同で完了する。
Flowは予定されたプロセスに従ってタスクの実行を組織化し、条件分岐、ループ、状態管理などの機能をサポート。CrewとFlowを組み合わせることもでき、例えばFlowで全体のビジネスプロセスを制御し、その中の複雑なステップでCrewを呼び出し、複数Agentが協力してタスクを完了できる。
CrewAIの特徴は、役割、タスク、チームを通じてマルチAgent協力を組織化すること。全体的な設計は現実のチームワークに近い。役割とタスクの境界が明確なマルチAgentアプリケーション、例えば調査、コンテンツ生成、データ分析、査読などのシナリオに特に適している。
LangGraphフレームワーク LangGraphは2024年にLangChainチームにより公開され、長時間実行されるステートフルなAgentの構築と管理のための低レベルのオーケストレーションフレームワーク。事前に構築されたAgentの使用とは異なり、開発者はAgentの実行構造を明示的に定義でき、ステート、分岐、ループ、人的介入などの複雑なワークフローを含むAgentに特に適している。
LangGraphは比較的明確な実行パスを持つワークフローも、大規模言語モデルが動的に次のステップを決定するAgentも構築できる。ワークフローはタスクの実行パスを事前に定義し、シーケンシャル、並列、ルーティング、ループなどの方法で異なるステップを組織化できる。Agentは現在のステートとツールの結果に基づいて動的に次の操作を決定できる。実際のアプリケーションでは、ワークフローとAgentを組み合わせることもでき、ワークフローが全体のプロセスを決定し、Agentが動的な判断が必要なステップを担当する。
LangGraphがサポートするワークフローとAgentのモードは以下に示す。
これらの異なる実行パスを実現するために、LangGraphはグラフを使用してタスクの実行プロセスを記述。3つの基本概念はState、Node、Edge。Stateはタスクの実行中に共有する情報を保存。Nodeは具体的な処理ステップを表し、例えば大規模言語モデルの呼び出し、知識の検索、ツールの実行など。Edgeは異なるノードを接続し、次のノードを決定。
例えば、知識Q&A Agentはまずユーザーの質問を分析し、知識を検索して回答を生成し、結果を確認する。回答が確認に不合格の場合、条件分岐を通過して検索ノードに再入力。確認に合格した場合、最終出力ノードに進む。全体のプロセスで、ユーザーの質問、検索結果、中間回答などの情報はStateに保存され、異なるノード間で共有できる。
この設計は、次の操作を完全に大規模言語モデルに依存するものとは異なる。LangGraphはタスクの大まかな実行構造を事前に規定し、判断が必要なノードで大規模言語モデルを使用して意思決定を行う。これにより、Agentが実際の状況に基づいて動的に判断する能力を維持しながら、重要な実行パスを制御できる。
グラフ構造とステート管理に加え、LangGraphはDurable ExecutionやHuman-in-the-loopなどの機能も提供。長時間実行されるタスクは実行ステートを保存し、中断後も継続可能。重要な操作の前には、Agentを一時停止し、人的確認やステートの変更を待ってから実行を再開できる。そのため、公式にはLangGraphは長時間実行されるステートフルなAgentのための低レベルのオーケストレーションフレームワークと位置付けられている。
LangGraphはステートと実行パスを細粒度に制御できるが、開発者により多くのワークフロー設計が必要。簡単なツール呼び出しAgentの場合、最初から複雑なグラフを構築する必要はない。LangGraphの公式ドキュメントでは、Agentの学習を始めたばかりの場合は、まずLangChainのAgentから始めることを推奨している。
MS-Agentフレームワーク MS-AgentはModelScopeコミュニティの軽量Agent開発フレームワークで、主に自律探索とマルチステップ実行を必要とするタスクに特化。モデル呼び出し、ツール統合、マルチAgent協力などの能力を提供し、ディープリサーチ、ドキュメント分析、コード生成などのアプリケーションの構築に使用できる。
MS-Agentの基本コンポーネントはLLMAgentで、大規模言語モデルのダイアログとツール呼び出しを組織化する責任を持つ。開発者は設定ファイルでモデル、プロンプト、ツールを指定できる。ユーザータスクを受け取った後、LLMAgentはタスクと利用可能なツールを大規模言語モデルに提供し、モデルが次の操作を判断する。ツール呼び出しが必要な場合、フレームワークは対応する操作を実行し、結果をモデルに返して処理を継続。モデルがツール呼び出しを含まない応答を生成するか、設定された最大実行ラウンド数に達するまで継続。
LLMAgentの基本的な実行フローは以下に示す。設定の初期化とメッセージ準備を完了した後、Agentはモデル呼び出しとツール実行を循環し、必要に応じてコンテキストを圧縮。図のcbはコールバックを表し、開発者は対応するステップでログ記録やその他のカスタム処理を追加できる。
ツール統合はMS-Agentの重要な能力。フレームワークはファイルの読み書き、コード実行、タスク分割などの組み込みツールを提供し、MCP（Model Context Protocol、モデルコンテキストプロトコル）を通じた外部ツールの統合もサポート。開発者は既存のMCPサービスを再利用したり、カスタムツールを作成したりでき、Agentがタスクに必要なデータと外部システムにアクセスできる。
複数のステップを必要とするタスクに対して、MS-Agentはワークフローを通じた異なるAgentの組み合わせをサポート。LLMAgentは大規模言語モデルの判断と生成が必要なステップを担当し、CodeAgentはコードに従った実行の確定的な操作を担当。開発者はデータ分析、データ処理、結果生成をワークフローとして組織化し、設定ファイルで各ステップの実行関係を規定できる。
例えば、MS-AgentプロジェクトのCode GenesisはマルチAgent協力によるコード生成の例を提供。プロセスを設計とコーディング、確認と最適化の2部分に分割。アーキテクチャAgentが設計を担当し、タスク分割ツールが作業を複数のプログラミングAgentに分配。最適化フェーズに入ると、ビルドや手動確認からのフィードバックに基づいて修正タスクを分割し、プログラミングAgentが処理を継続。
Agent SDK Agent開発フレームワークの使用に加え、一部のモデルプロバイダーはSDK（Software Development Kit、ソフトウェア開発キット）の形式でAgent開発能力も提供。モデル呼び出し、ツール呼び出し、タスク実行などをインターフェース、クラス、コンポーネントにカプセル化し、開発者が自分のアプリケーションでAgentを作成・実行できるようにする。AgentフレームワークとAgent SDKの両方でAgentを構築でき、能力に重複があるが、組織方式と焦点が異なる。以下に2つの代表的なAgent SDKを紹介。
OpenAI Agents SDK OpenAIは2025年にOpenAI Agents SDKを公開。少数のコア抽象化を使用してAgentアプリケーションを構築することを強調。Agentを基本実行単位とし、Agentを中心にツール呼び出し、タスク委譲、実行制約、実行追跡などの能力を提供。Toolsはデータの照会、コードの実行、APIの呼び出し、その他の外部システムの操作に使用。Handoffsは現在のAgentがタスクをより適切に処理できる他のAgentに委譲できるようにする。GuardrailsはAgentの入力、出力、および一部のツール呼び出しをチェック。TracingはAgentの実行过程中に発生するモデル生成、ツール呼び出し、タスク委譲、Guardrailなどのイベントを記録。
OpenAI Agents SDKはAgent Visualizationも提供し、Agentと接続された他のAgent、Tools、MCP Serverのグラフ構造を生成できる。Agent間の有向接続はHandoffsを表し、ToolとAgent間の接続はツール呼び出しを表す。
例えば、カスタマーサービスシステムでは、ユーザーの問題を識別する入口Agentを設定し、オーダーAgent、返金Agent、FAQ Agentで異なる種類のビジネスを処理する。ユーザーが返金について相談した場合、入口AgentはHandoffで返金Agentにタスクを委譲。返金Agentは必要に応じてオーダー照会、返金申請などのツールを呼び出してタスクを完了。Handoffsは異なる専門Agentが異なるタスクを処理するシナリオに特に適している。
GuardrailsとTracingは実際のAgent実行における制約と観察の問題を考慮。GuardrailsはAgentの入力、最終出力、カスタム関数ツールの呼び出しの前後にチェック可能。Tracingは1回のAgent実行におけるモデル生成、ツール呼び出し、Handoff、Guardrailなどのイベントを記録し、開発者がどのステップを通過したか、問題がどこで発生したかを理解するのに役立つ。
OpenAI Agents SDKの特徴は、コアコンセプトが比較的集中していること。開。開発者は単一AgentとToolsから始め、徐々にマルチAgent協力、Guardrails、Tracingなどの能力を追加できる。LangGraphと比較すると、設計の焦点が異なる。LangGraphはステートとワークフローの細粒度な制御を強調。OpenAI Agents SDKはAgentを中心にツール呼び出し、タスク委譲、実行制約、実行追跡などの汎用能力に焦点を当てる。
Claude Agent SDK Claude Agent SDKはAnthropicが公開したAgent開発SDKで、元々Claude Code SDKと呼ばれていたが、後にClaude Agent SDKに改名。Claude CodeのAgent能力を開発者に開放し、開発者が自分のアプリケーションでツールを使用し、実行環境にアクセスし、タスクを継続的に実行できるAgentを構築できるようにする。
以前に紹介したAgent開発ツールと比較すると、Claude Agent SDKの際立った特徴は、Agentが実際の実行環境へのアクセスと操作をより重視していること。外部ツールの呼び出しに加え、ファイルの読み取り、ファイルの変更、コマンドの実行などの組み込み能力を提供し、Agentがファイルを直接処理し、プログラムを実行し、コマンドを実行でき、MCPを通じてさらに多くの外部ツールとデータに接続できる。さらに、権限制御、Hooks、Subagentsなどのメカニズムを提供。権限制御はAgentが実行できる操作を制限。Hooksはツール呼び出しなどの重要な段階でカスタム処理ロジックを挿入可能。Subagentsは一部のタスクを独立したサブAgentに委譲できる。
実行过程中、Agentは現在のタスクとコンテキストに基づいて次の操作を判断する。例えばファイルの読み取り、コードの変更、コマンドの実行など。ツール実行後、結果はAgentに返され、Agentは新しい情報に基づいて判断を続け、タスクが完了するまで継続。Claude Agent SDKはこの実行プロセスを組織化し、ツール呼び出し、権限チェック、コンテキスト渡しを処理する。
例えば、ソフトウェア開発タスクでは、Agentにプロジェクトコードを読み取り、ユーザーの要件に基づいてファイルを変更し、テストを実行させる。テストが失敗した場合、Agentはエラー情報を読み取り、タスクが完了するまで修正を続ける。このプロセスでは、大規模言語モデルがタスクの理解と次の操作の判断を担当し、Claude Agent SDKがファイルシステム、ターミナル、ツールなどの実行能力を提供し、権限とタスク実行プロセスを管理する。
Claude Agent SDKは、ファイルと実行環境へのアクセス、継続的なツール呼び出し、複数ステップタスクの実行が必要なAgentアプリケーション、特にソフトウェア開発や自動化タスクのシナリオに適している。
実際のAgent開発では、実行環境、コンテキスト管理、権限制御、タスクステート、実行フィードバックなどの能力がますます重視されている。大規模言語モデルを中心にこれらの能力をどのように組織化し、タスク実行プロセスをどのように管理・制御するかは、Agentシステム設計における重要な課題となっており、Harnessがまさに这些问题に焦点を当てている。
Harness
Harnessとは 大規模言語モデルの能力が向上するにつれ、Agentが直面する問題は「モデルが特定のタスクを実行できるか」から「モデルが実際のタスクを持続的かつ信頼性高く実行できるか」へと徐々にシフトしている。単純な質問応答では、大規模言語モデルは入力に基づいて結果を生成するだけで良いが、ソフトウェア開発、データ分析、ビジネス自動化などの複雑なタスクでは、Agentは長時間にわたり作業を継続し、複数のステップ間で進捗を保存し、異なるツールを呼び出し、実際の実行結果に基づいて後続の操作を不断に調整する必要がある。この場合、モデル自身の推論能力だけに依存しても、タスクが最終的に正しく完了することが保証されない。
例えば、コードAgentは「特定の機能を修正する」という要件を正しく理解でき、高品質のコードを生成することもできるが、実際の実行プロセスでは様々な問題が発生する可能性がある。プロジェクトの仕様を読まずにコードの修正を開始し、同時に过多なファイルを修正し、必要なステップを省略し、実行过程中に以前のタスクの進捗を失い、テストに合格していないのにタスクが完了したと判断するなど。これらの問題は完全にモデル自身の能力から来るものではなく、モデルの作業環境やタスクの実行方法に関わるものである。
Harnessは大規模言語モデルの周囲に構築された作業環境と実行メカニズムであり、モデルがどの情報を取得でき、どの操作を実行でき、タスクステートをどのように保存し、タスクが完了したとどう判断するか、問題が発生した場合にどのように処理するかを規定する。これらのメカニズムにより、モデルの一連の独立した推論や操作を、制約され、持続的に実行され、結果を検証できるタスク実行プロセスに組織化できる。
Harnessの重点は、大規模言語モデル自体の知識や推論能力をさらに強化することではなく、モデルの既存の能力を実際のタスクにより確実に適用できるようにすることにある。モデルは引き続きタスクの理解、問題の分析、次の操作の判断を担当し、Harnessはモデルがタスクを完了するために必要な作業条件を構築し、全体の実行プロセスに制約とフィードバックを課す。
実行プロセスから見ると、HarnessはAgentに持続的なループを形成させる。Agentは現在のタスクとステートに基づいて判断し、対応する操作を実行し、実行環境から新しい結果を取得。これらの結果は記録、検証、フィードバックの後、次の判断の根拠となる。結果が要件を満たさない場合、Agentは修正と実行を継続。事前に定義された完了条件を満たした場合にのみ、タスクは本当に終了する。
Harnessは単純なプロンプトやツール呼び出しとは明確に異なる。プロンプトは主に指示を通じてモデルにタスクの目標と行動要件を伝え、ツールはモデルに具体的な操作を実行させるが、Harnessはさらにこれらの指示とツールがタスク実行プロセス全体を通してどのように組織化・管理されるかを考慮する。Agentにどこから始まり、現在どこにあり、どの操作を実行でき、結果をどう検証し、いつ終了でき、タスク中断後にどう続けるかを知らせる必要がある。長時間実行され、複数ステップを実行するAgentにとって、これらのメカニズムはタスクが安定して完了できるかどうかに直接影響する。
Harnessの主要コンポーネント Harnessに統一された実行方法はなく、異なるAgentシステムはタスクの種類に応じて異なる実行メカニズムを提供する。実際のAgent実行で解決する必要がある問題の観点から、Harnessは5つの連携する部分にまとめられる。指示とコンテキスト、ツール、実行環境、ステートとタスクの連続性、検証とフィードバック。
指示とコンテキストは、Agentが現在のタスクで「何を知っている」か「何に従うべきか」を決定する。
指示にはユーザーの現在の入力だけでなく、システムプロンプト、プロジェクトルール、コード規範、ビジネス制約、タスク境界、完了条件などが含まれる。例えば、プログラミングAgentはAGENTS.md、CLAUDE.md、プロジェクト文書を通じてディレクトリ構造、開発規範、テスト方法、修正が禁止されている領域を理解できる。
コンテキストは実行过程中にモデルに提供される有効な情報であり、ユーザーの要件、過去の操作、ファイルの内容、ツールの実行結果、現在のタスクステートなどが含まれる。モデルのコンテキストウィンドウは限られているため、Harnessは通常、コンテキストを選択、圧縮、再組織化し、現在のタスクに本当に必要な情報をモデルに提供する必要がある。単に全履歴を無意味に追加し続けるのではなく。
複雑なタスクには、階層的な指示と段階的なコンテキストロードを使用できる。例えば、まずAgentにプロジェクト全体の説明を読ませ、特定のモジュールに入った後にそのモジュールのローカルルールをロードする。タスクの実行時間が長く、コンテキストが不断に増加する場合は、初期プロセスを圧縮し、重要な結論、タスクステート、今後も必要な情報のみを保持する。これらのメカニズムにより、限られたコンテキストウィンドウ内でAgentに有効な情報を継続的に提供し、指示を通じてAgentのタスク範囲と行動の境界を制約できる。
大規模言語モデルは主に理解、推論、意思決定生成を担当するが、実際に外部情報を読み取ったり、具体的な操作を実行したりするにはツールを使用する必要がある。ツールはAgentが実際に実行できる操作を決定する。
プログラミングAgentの場合、一般的なツールにはファイルの読み取り、ファイルの修正、コード検索、シェルコマンドの実行、Git操作、テストツールが含まれる。ビジネスAgentの場合、データベース照会、ナレッジベース検索、ブラウザ、ビジネスAPI、MCPを介した外部システムなどが含まれる。
Harnessはこのレベルでツールリストを維持するだけでなく、ツールの説明、パラメータの組織化、呼び出しルーティング、実行結果の返却、例外処理も処理する必要がある。例えば、大規模言語モデルが「プロジェクトテストを実行する」と判断した後、Harnessは対応するツールを呼び出し、指定された環境でテストコマンドを実行し、標準出力、エラー情報、終了ステータスを整理してモデルに返す必要がある。これにより、Agentは実行結果に基づいて次の操作を判断できる。
ツール呼び出しには適切なセキュリティと権限制御を伴う必要がある。一部のツールはファイルを読み取ることしかできず、一部のツールはコンテンツを修正できる。ファイルの削除、ネットワークへのアクセス、システムコマンドの実行、本番システムの操作には、リスクレベルに応じた制限を設け、必要に応じて手動確認を要求することもある。Hooksなどのメカニズムをツール呼び出しの前後に挿入し、パラメータのチェック、実行プロセスの記録、ルールに適合しない操作のブロックにも使用できる。
サブエージェントをサポートするシステムでは、メインAgentは一部のタスクを専門のサブエージェントに委譲することもできる。例えば、コード検索、テスト分析、資料整理などの比較的独立した作業を異なるサブエージェントに割り当て、それらの結果をまとめることもできる。これにより、単一Agentのタスク処理能力を拡張し、複雑なタスクが単一の実行コンテキストに集中する圧力を軽減できる。
ツールは「Agentが何ができるか」を答え、実行環境はそれらの操作が「どこで発生するか」を決定する。
プログラミングAgentの場合、実行環境はローカルプロジェクトディレクトリ、コンテナ、仮想マシン、クラウドのサンドボックス、または独立したGitワークツリーである可能性がある。Agentはファイルの読み取りと修正、シェルコマンドの実行、依存関係のインストール、テストの実行などを行う際に、具体的な実行環境に依存する。
Harnessは実行環境を準備・管理する必要がある。コードリポジトリの初期化、依存関係のインストール、環境変数の設定、必要なサービスの起動、現在の環境がタスク実行条件を満たしているかどうかの確認などが含まれる。長時間実行されるタスクの場合、実行过程中に依存関係の欠落、サービスの異常、リソースステートの不整合が発生しないようにする必要もある。
環境分離も実行環境管理の重要な内容。複数のAgentや複数のタスクが同時に同じプロジェクトを処理する場合、同じ作業ディレクトリを直接操作するとファイルの上書きやステートの衝突が発生する可能性がある。異なるタスクには独立したサンドボックス、コンテナ、ワークツリーを構築し、異なるタスクが比較的分離された空間で実行されるようにできる。あるタスクが失敗した場合でも、他のタスクやホスト環境への影響を軽減できる。
実行環境はリソースアクセス境界の制御も担う。例えば、Agentが指定されたディレクトリにのみアクセスでき、特定のネットワークにのみ接続でき、システムの機密ファイルを読み取れないように制限したり、異なるタスクに異なるアクセス資格情報を設定したりできる。ツールはAgentが使用できる能力を定義し、実行環境はそれらの能力が実際にどのファイル、プロセス、ネットワーク、システムリソースに作用できるかを制限する。
（4）ステートとタスクの連続性
大規模言語モデルの単一呼び出し自体には長期的なタスクステートがなく、複雑なAgentタスクは数十分、数時間、または複数のセッションにわたって続く可能性がある。タスク情報が現在のコンテキストにのみ存在する場合、コンテキストの圧縮、プロセスの中断、セッションの再起動が発生すると、Agentは以前にどの作業が完了したかを正確に判断できなくなる可能性がある。
Harnessはタスクステートを維持する必要がある。現在の目標、タスク分割の結果、完了したステップ、処理中のステップ、修正したファイル、重要なツール実行結果、次に処理する必要がある内容などが含まれる。
これらのステートはメモリに保存することも、タスクファイル、データベース、Git履歴、その他の外部ストレージに書き出すこともできる。長時間実行されるAgentにとって、永続的なステート保存は特に重要。新しいAgentセッションは以前に保存されたタスクの進捗と重要な結果を読み取り、中断した位置から実行を再開でき、タスク全体を再分析する必要がない。
ステート管理はタスクのライフサイクル全体を貫く。タスク開始時に初期ステートを確立し、実行过程中に進捗と重要な結果を継続的に記録し、タスク完了時に最終ステートを保存。タスクが異常、タイムアウト、システム再起動により中断された場合、チェックポイントメカニズムを通じて以前の実行位置に復元できる。サブエージェントを含む複雑なタスクには、各サブタスクの完了状況、実行結果、相互間の依存関係を記録できる。
ステートとタスクの連続性の重点は、継続的に更新され、永続化され、復元可能なタスク実行プロセスを維持すること。これにより、長時間実行される場合やセッションをまたいで実行される場合でも、Agentはタスクがどこまで進んだかを把握し続けることができる。
Agentが操作を実行したからといって、タスクが正しく完了したことを意味しない。例えば、Agentがコードファイルを正常に修正したが、コードがコンパイルできない場合がある。分析レポートを生成したが、重要なデータが欠落している場合がある。ビジネスインターフェースを呼び出すことに成功したが、ビジネスルールに適合しない結果を生む場合がある。そのため、Harnessは検証とフィードバックのメカニズムも構築し、実行結果をチェックし、チェック結果をAgentに再提供する必要がある。
検証方法は具体的なタスクによる。ソフトウェア開発タスクにはユニットテスト、リンタ、型チェック、コンパイル、エンドツーエンドテストが使用できる。ビジネスタスクにはビジネスルールチェック、結果比較、独立した評価者が使用できる。検証の核心は、モデル自身に「タスクが完了した」と判断させるのではなく、タスク完了のためのチェック可能な根拠を提供することにある。
フィードバックは検証結果をAgentに再提供する。例えば、テスト失敗後、Harnessはエラー情報と関連ログをモデルに返す。Agentはこれらの情報に基づいて原因を分析し、コードを修正し、再度テストを行う。これにより、「実行→検証→フィードバックの取得→修正→再検証」のループが形成される。このループにより、Agentは実際の実行結果に基づいて以前の判断を継続的に修正でき、1回の操作の後に直接タスクを終了するのではなくなる。
Harnessはこのプロセスに実行制御を追加することもある。例えば、すべてのテストに合格した後にのみコードをコミットできる。連続して複数回実行が失敗した場合、タスクを停止するか、手動処理に引き継ぐ。本番環境の変更、データの削除などの高リスク操作には、実行前にタスクを一時停止し、手動承認を要求する。確認が得られた場合は実行を継続し、確認が得られない場合は操作を終了または調整する。
これらの5つの部分が連携してAgentの持続的な実行を支える。指示とコンテキストはタスクの目標、ルール、必要な情報を提供。ツールは実際のアクション能力を提供。実行環境はこれらの操作を抱え、リソースの境界を制限。ステートとタスクの連続性はタスクの進捗を記録し、復元をサポート。検証とフィードバックは実行結果をチェックし、Agentが修正を続けるか、タスクを完了するよう促す。これらのメカニズムにより、HarnessはAgentの一連のモデル呼び出しを、持続的に実行され、制約され、結果を検証できる完全なタスクプロセスに組織化する。
HarnessとAgentの関係 AgentとHarnessは相互に置き換わる2つの概念ではなく、異なる階層にある。Agentの実行过程中、大規模言語モデルは主にタスクの理解、現在の情報の分析、次の操作の判断を担当。HarnessはAgentに指示とコンテキスト、ツール、実行環境、ステート管理、検証とフィードバックを提供し、Agentの判断が実際に実行され、実行过程中に制約と検証を受けるようにする。
両者の関係は「意思決定と実行サポート」である。Agentは現在のタスクと既存の情報に基づいて次に何をすべきかを判断。Harnessはこの操作を実行するために必要なツールと環境を提供し、実行过程中に発生するステートと結果を記録する。実行完了後、Harnessはテスト、ルールチェックなどを通じて結果を検証し、フィードバックをAgentに提供することもある。Agentは新しいステートとフィードバックに基づいて次の操作を判断し、タスクの完了条件を満たすまでこのサイクルが続く。
例えば、プログラミングAgentがlogin.pyを修正し、テストを実行する必要があると判断する。コードの分析と修正方法の判断は主に大規模言語モデルの理解力と推論能力に依存する。login.pyが修正可能かどうか、ファイルをどこから読み取るか、どのツールで修正するか、テストコマンドをどのサンドボックスで実行するか、修正の進捗をどう保存するか、テスト結果をどう検証するか、失敗後にどう続けるかは、Harnessが提供する実行メカニズムが必要になる。テスト失敗後、エラー情報がAgentに再提供され、Agentはこれらの情報に基づいて原因を分析し、次の修正計画を判断する。
Harnessの完成度はAgentが処理できるタスクの種類に影響する。シンプルなHarnessは少数のツールと基本的な呼び出しメカニズムしか提供せず、ステップが少ないタスクに適している。より完全なHarnessは、コンテキスト管理、環境分離、永続的なタスクステート、権限制御、自動検証、失敗からの回復、手動承認などのメカニズムをさらに提供し、Agentがより長く、より複雑なタスクを継続的に実行できるようにする。同じ大規模言語モデルを使用しても、異なるHarnessが提供する実行条件が異なれば、Agentの複雑なタスクにおける処理能力と安定性に明確な差異が生じる可能性がある。
HarnessとAgentフレームワークには一定の重複がある。どちらもツール呼び出し、コンテキスト管理、ステート管理、タスク実行制御に関わるが、重点が異なる。AgentフレームワークはAgent構築とタスク組織化に必要な開発能力、例えばAgent定義、ツール呼び出し、ステート管理、ワークフローオーケストレーション、マルチAgent協力などを提供することに偏向。HarnessはAgentの実行を中心に、コンテキストの組織化、ツールと実行環境の提供、タスクの連続性の維持、実行結果の検証などのサポートと制御メカニズムに関心を向ける。AgentフレームワークとAgent SDKの発展に伴い、一部のHarness能力はフレームワークやSDKに統合されるようになっており、具体的な実装において両者に絶絶対的な機能境界はない。
全体として、3者の関係は次のように要約できる。大規模言語モデルはインテリジェンスを提供し、Agentは意思決定を組織化し、Harnessは実行を保証する。
Agentが実行するタスクの複雑さが増すにつれ、Harnessの役割はより明白になる。
DeepSeek Harness 以下ではDeepSeek Harnessを例に取り、実際のAgentシステムにおいてHarnessがどのように組織化されるかを further 了解する。
DeepSeek HarnessはDeepSeekが2026年に公開したオープンソースのAgent Harnessで、プラグインベースのアーキテクチャを通じてモデルの実行に必要なツール、スキル、セッション、サンドボックス、タスク実行能力を組織化し、Agentに拡張可能な実行サポートを提供することが特徴。
DeepSeekは実行可能なAgentを次のように理解する。
Modelはタスクの理解と意思決定を担当し、Harnessはモデルがタスクを完了するために必要なツール、コンテキスト、実行環境を組織化する。
DeepSeek Harnessのコアデザインは「Everything is a Plugin（すべてがプラグイン）」。モデル、ツール、スキル、セッション、サンドボックス、ストレージ、実行ループ、タスクスケジューリング、サブエージェントなどの能力はすべてプラグインで提供でき、基盤のCordisプラグインシステムによって組織化される。Cordisはプラグインのロード、アンロード、依存関係管理、ライフサイクル管理を担当し、具体的なAgent能力は異なるプラグインによって提供される。開発者は実際のニーズに応じて異なるプラグインを組み合わせ、置き換え、拡張できる。
例えば、DeepSeek Harnessを使用してデータ分析Agentを構築する。Agentはユーザーが提供したデータファイルを読み取り、タスクに応じて対応するツールを呼び出してデータ処理と分析を実行し、特定のデータ分析タスクにはスキルを使用することもできる。タスクが複雑な場合は、作業の一部をサブエージェントに委譲することもできる。モデルは次の操作の決定を担当し、Harnessはこれらの操作を実行するために必要な能力を提供・組織化する。
プラグインベースのデザインに加え、DeepSeek Harnessはセッションと実行プロセスの記録などのメカニズムも提供。モデルが見るシステムプロンプト、ツール呼び出しとその結果、サブエージェントのスケジューリング、コンテキスト注入などの情報はセッションログに記録でき、Trajectoryで確認できる。これらの記録に基づき、タスクの復元、分岐、検索、再生が可能で、開発者がAgentの実行プロセスを観察・デバッグするのに役立つ。
現在、DeepSeek HarnessはまだDeveloper Preview段階にあり、コアプラグインとAPIは継続的にイテレーションされている。そのため、現在のインターフェースを確定した開発標準と見なすよりも、Harnessのプラグインベースのデザインと技術実装を理解するための代表的なケースとして扱うのが適切である。
