AIエージェントの「乱立」を標準仕様で解く：Standard Agent Specificationの全体像
企業ごとに個別実装されたAIエージェントは互いに再利用も連携もできない。Standard Agent Specification（以下、Standard Agent仕様）は、エージェントをTypeScriptのコードとして定義し、npmパッケージとして配布・インストール・合成できるようにするオープンソース仕様である。
本記事は、Standard Agents社の共同創業者 Justin Schroeder氏の講演「Every Company Is Building Agents That Can’t Work Together」の内容を、仕様サイトと同氏のAI Engineer講演の情報で補って整理する。要点は次の3つ。
- 企業がエージェントを自作する理由は、統合（Integration）・信頼（Trust）・効力（Efficacy）の3つ
- 問題はエージェントを作ることではなく、ハーネス（実行基盤）を各社がばらばらに作り、共有も合成もできないこと
- Standard Agent仕様は、汎用エージェント1体にツールを足し続ける設計ではなく、ドメイン特化エージェントを部品として組み合わせる設計を前提にする
企業が独自エージェントを作り続ける3つの理由
MCPサーバーやMarkdownの指示書（Skills）を汎用エージェントにつなぐだけでは、業務プロセスを任せられない。Schroeder氏はその理由を次の3つに整理している。
| 理由 | 内容 | 具体例 |
|---|---|---|
| 統合（Integration） | 自社のデータと業務フローの中で、決められた手順どおりに処理させる必要がある | 保証請求の管理、スケジューリング |
| 信頼（Trust） | 何でもできるエージェントは、無関係なサイトの参照や範囲外の操作を行うリスクを抱える。動作範囲を事前に限定する必要がある | 許可済み操作だけを持つエージェント |
| 効力（Efficacy） | 速さよりも、特定タスクをどれだけ正確にこなすかが問われる。評価テスト（Eval）の通過率で測る | 業務別Evalでの精度改善 |
この3つは、汎用エージェントに機能を足すほど満たしにくくなる。そのため企業は、役割を絞ったエージェントを自作する方向に進む。
現在のエージェント開発が抱える課題
各社が異なる言語・ツール・ループ構造でエージェントを作っているため、ハーネスを毎回イチから作り、他の環境と共有できず、スケールしない。
Schroeder氏はエージェントを「モデルの非決定的な出力を、目的に向けて制御する決定的なソフトウェア」と定義し、エージェントとハーネスを一体のものとして扱う。デモが動いた段階では、ハーネス側の次の課題が未解決のまま残る。
| 課題 | 内容 |
|---|---|
| エージェントループ | モデル応答・ツール呼び出し・次の判断の繰り返しを、プロバイダーごとの差異を吸収して正しく回す |
| 耐障害実行（Durable execution） | 途中で障害が起きても状態を失わずに再開する |
| 検証と停止条件 | どの操作を許可するか、いつ終了するかを決める |
| 可観測性 | 各ステップでモデルに何を送ったかを追跡できる |
| 可搬性 | 作成者の環境以外でも動く |
| 合成可能性 | 作ったエージェントを別のアプリケーションから再利用できる |
これらを各社が独自に解いている結果、エージェントは作った場所でしか動かず、他社のエージェントとも連携できない。
Standard Agent Specificationの概要
Standard Agent仕様は、可搬・合成可能なドメイン特化エージェントを作るためのオープンソース仕様で、仕様サイトの現行版はv0.2.0、ライセンスはMITである。仕様に準拠したエージェントは公開・インストールでき、他のStandard Agentと組み合わせられ、準拠ランタイムであればどこでも同じように動くことを目標にしている。
仕様が掲げる原則は次の5つ。
| 原則 | 意味 |
|---|---|
| ベンダー非依存（Vendor-agnostic） | 特定のクラウドやモデル提供者に縛られない |
| ドメイン特化（Domain-specific） | 1つのエージェントは1つの業務領域だけを担う |
| モデルとの結合（Coupled to a model） | プロンプト・ツール・フックを使用モデルに合わせて調整し、その組み合わせごと品質を保証する |
| 合成可能（Composable） | 他のエージェントから、通常のツール呼び出しと同じ形で呼べる |
| 可搬（Portable） | 準拠ランタイムであれば実行環境を問わない |
「ベンダー非依存」と「モデルとの結合」は両立する。仕様やランタイムは特定ベンダーに依存しない一方で、個々のエージェントは使用モデルを固定して精度を詰める、という役割分担である。モデル定義にはフォールバックチェーンも含まれる。
実行を担うランタイムは、コンテキストの組み立て、ツールの実行、停止条件の適用、状態の永続化を担当する。TypeScriptを実行できるなら、ランタイム自体は任意の言語で実装してよい。
仕様を構成する7つの要素
v0.2.0は、エージェントを次の7要素の組み合わせとして定義する。いずれもTypeScriptで記述する。
| 要素 | 役割 |
|---|---|
| モデル（Model） | 使用するLLM、その能力・価格、障害時のフォールバックチェーン |
| プロンプト（Prompt） | システム指示、参照するモデル、使えるツール、リクエストごとの振る舞い |
| ツール（Tools） | モデルが呼べる能力。関数・プロンプト・エージェントの3種類 |
| サブエージェント（Subagents） | 親から起動される子エージェント。それぞれ独立したスレッドで動く |
| フック（Hooks） | 実行ライフサイクルに割り込み、検証・変換・副作用を加える |
| エフェクト（Effects） | 遅延通知やバックグラウンドの後片付けなど、予約実行される副作用 |
| スレッド（Threads） | 固有のID・ストレージ・ライフサイクルを持つエージェントの実行単位。メッセージ、ファイルシステム、コード実行、実行状態、エンドポイントを持つ |
このほか、プロバイダー、ハンドラー、エージェント、ユーザー（ドラフト）、型レジストリも定義されている。
v0.1.0では、必須要素を「モデル・プロンプト・エージェントルール」の3つ、任意要素を「ツール・フック・エンドポイント」の3つとしていた。エージェントルールはステップ数の上限やツール呼び出しの検証といった実行ポリシーを指す。仕様はまだv0系で、構成は版ごとに変わり得る。
サブエージェントとは別に「ハンドオフ」もある。両者の違いはスレッドの扱いである。
- ハンドオフ：同じスレッドの制御を、人と対話する別のエージェント（
ai_human型）に移す - サブエージェント：新しい子スレッドを作り、AI同士で対話するエージェント（
dual_ai型）に実行させる
なぜTypeScriptか、MCP・Skillsと何が違うか
Standard Agent仕様はエージェント全体をTypeScriptのコードとして定義し、自己完結したnpmパッケージとして配布する。そのためバージョン管理・パッケージ化・共有・インストールが、通常のソフトウェアと同じ手順で行える。
仕様のFAQが示すTypeScript採用の理由は2つ。
- JavaScriptはほぼどこでも実行でき、サンドボックス化もできる。フルスタックのサーバーに依存しない共通の実行基盤になる
- 型検査が、人間が書いたコードにもLLMが生成したコードにも当たる。独自のバリデーターを用意する必要がない
ツールはランタイム内で直接実行され、別サーバーを立てずにスレッドの状態にアクセスできる。カスタムツール1つのためにMCPサーバーを立ち上げる必要はない。
MCP・Skillsとの違いは、「何を単位に組み合わせるか」にある。
| 方式 | 組み合わせる単位 | 限界 |
|---|---|---|
| MCP | 1体の汎用エージェントに渡すツール群 | ツールが増えるほど選択を誤りやすくなり品質が下がる |
| Skills | 汎用エージェントに足すMarkdownの文脈 | 解釈と問題解決は実行時の汎用モデル任せ。文脈を増やしても組み合わせの品質は保証されない |
| Standard Agent | モデル・プロンプト・フック・ツールを一体で調整したエージェント | エージェント単位の設計・調整コストがかかる |
Schroeder氏は、汎用エージェントに責任を足し続ける設計をオブジェクト指向の「継承」、独立したエージェントを組み合わせる設計を「コンポジション」と対比している。MCPは否定されていない。各ドメインエージェントの内部で外部システムへの接続手段として使う余地は残る。
ドメイン特化エージェントと再帰的な合成
Schroeder氏が想定する構成は、コーディネーターが自然言語で専門エージェントに依頼し、専門エージェントがさらに別の専門エージェントを呼ぶ再帰的な合成である。各専門エージェントは、固有のシステムプロンプト・知識・ツール・ループ・短いメッセージ履歴を持つ完全なエージェントで、単なるツールサーバーではない。
講演の例では、Salesforceエージェントが上位の営業担当者を取得し、Google Workspaceエージェントと連携してスプレッドシートを作る。法務エージェントは、GDPRやOSHAに関する質問を専用のサブエージェントに振り分ける。
この構成には4つの利点がある。
- コンテキスト：各エージェントは自分の領域の情報だけを持つ。講演では仮に45MBのGDPR関連情報を例に、コーディネーターがそれを抱える必要がないことを示している
- コスト：タスクが狭いほど安価なモデルで足りる。講演ではトークン効率80%超、DeepSeek V4 FlashがFable 5よりタスク当たり137倍安いという数字が示されたが、比較の条件は示されていない。安価なモデルが失敗を繰り返せば優位は消える
- 権限：各エージェントは事前承認された操作だけを持つため、IT部門が許可範囲を把握しやすい
- 実行環境：各エージェントは独立した小さな実行環境で、固有のファイルシステムとサンドボックス化されたコード実行を持つ
ツールには、コードを実行する関数ツール、指示を差し込む・モデルを呼ぶプロンプトツール、別のエージェントに委譲するエージェントツールの3種類がある。フックは状態の変更や副作用の追加に使い、講演では現在時刻をメッセージ履歴に差し込む例が示されている。
Standard Agent Builderとデモ
仕様の最初の公開ランタイムが、Standard Agents社の「Standard Agent Builder」（仕様のFAQではAgentBuilder）である。Standard Agent仕様はフレームワークではなく仕様であり、AgentBuilderはその実装の1つという位置づけになる。
講演では、バッテリーの保証請求を処理するエージェントを約5分で作成し、運用・管理するまでを実演している。保証請求は、自社の条件に沿った処理（統合）、操作範囲の限定（信頼）、判定の正確さ（効力）がそろって問われる業務であり、冒頭の3つの理由にそのまま対応する題材である。
Standard Agents社はまだ利用者を限定して公開を進めており、早期アクセスは standardagents.ai から申し込む。仕様への貢献はGitHubのIssueとPR、議論はDiscordで行われている。
他の標準化の動きとの違い
エージェント定義の標準化は、Standard Agent仕様だけの動きではない。Oracleが中心となって公開した「Open Agent Specification（Agent Spec）」は、JSON/YAMLによる宣言的な記述でエージェントとワークフローを表現し、AutoGenやLangGraphなど複数のフレームワークで実行することを目指す。
| 観点 | Standard Agent仕様 | Open Agent Specification |
|---|---|---|
| 記述方法 | TypeScriptのコード | JSON/YAMLによる宣言的定義 |
| 可搬性の作り方 | 実行基盤をTypeScriptに揃える | 定義を各フレームワークの内部表現に変換する |
| 配布単位 | npmパッケージ | 定義ファイル |
| 重点 | ドメイン特化エージェントの合成 | 既存フレームワーク間の相互運用 |
Open Agent Specificationは「一度定義して複数のフレームワークで動かす」方向、Standard Agent仕様は「実行基盤そのものを共通化してエージェントを部品として流通させる」方向である。前者はツールや検証ロジックの中身を各フレームワーク側に任せ、後者はそれらもコードとしてエージェントに含める。
まとめ
Standard Agent仕様の核心は、エージェントを「モデル・プロンプト・ツール・フックを一体で調整した配布可能な部品」として扱うことにある。
- 企業がエージェントを自作するのは、統合・信頼・効力の3つを汎用エージェントでは満たせないためである
- 課題はハーネス（ループ、耐障害実行、停止条件、可観測性）を各社が独自に作り、可搬性と合成可能性がないことである
- Standard Agent仕様は、TypeScriptとnpmで実行基盤と配布単位をそろえ、ドメイン特化エージェントをツール呼び出しと同じ形で組み合わせられるようにする
残る論点もある。仕様はv0.2.0で構成要素が版ごとに変わっており、公開ランタイムもまだ限定公開である。講演内のトークン削減率やコスト比は測定条件が示されていない。採用を検討する場合は、自社の業務でEvalを用意し、汎用エージェント＋MCPの構成と通過率・トークン消費を比較するのが確実である。