AI 開発

AI Agent とは？2026 年の仕組み、Tool Calling、Function Calling と JSON 完全ガイド

JSONSort 公開 2026-09-05 更新 2026-09-05 約 16 分

2026 年の AI 製品ページはどれも「Agent」と書く。多くは チャットボット、関数を呼べるモデル、多段階ワークフローを走り切るランタイム を一つの語に畳んでいる。定義から始める：AI Agent とは何か、ループはどう回るか、Tool Calling と Function Calling の差、そして各層がなぜ JSON に着地するか。読み終わったら、長い prompt ではなく、デバッグできる呼び出し鎖が描けるはずだ。

先に要点

概念	一言	JSON の着地点
AI Agent	計画し、ツールを呼び、結果を次へ渡すランタイム	ワークフロー状態 / handoff
Tool Calling	モデルが「外部能力を呼びたい」と示す総称	`tool_calls`
Function Calling	ベンダー API 上の実装	`tools[]` / `arguments`
JSON	ステップ間で唯一安定し、検証できるオブジェクト	Schema / payload

層を分ける：Agent はランタイム、Tool Calling は能力、Function Calling は API フレーム、JSON は共有契約。

AI Agent とは何か？

AI Agent は「より上手に話すモデル」ではない。モデルはテキスト（または構造化オブジェクト）を生成するだけだ。Agent はモデルをループに入れるランタイムである：状態を観察し、次を計画し、外部ツールを呼び、結果を消化し、継続・引き渡し・終了を決める。

2026 年に出荷できる Agent は、だいたい三点セットだ：

モデル：推論、ツール選択、Structured Outputs。
ホスト：呼び出し意図の解析、実 API / DB / ファイル操作、結果返却、不正 JSON の遮断。
契約：ツール引数、戻り値、handoff、ワークフロー状態——ほとんどが JSON。

ホストがなければモデルは「提案」しかできない。契約がなければ多段フローは半正解を事実として流す。製品の境界はモデルカードではなくホスト側にある。

チャットボットや素の LLM と何が違うか

三つの語が一つの機能に貼られがちだ。本番では分ける：

素の LLM：テキスト入力、テキスト出力。ツールも跨ステップ状態もない。
チャットボット：LLM を会話 UI に繋ぐ。出力は人向け。失敗はユーザーが再試行する。
AI Agent：出力はプログラムが実行する。ツール結果、ルーティング、評価点は散文ではなくオブジェクト。

判定は単純だ。次の一手を人が読むのではなくコードが実行するなら、賢いダイアログではなく Agent が要る。実行権はホストにあり、モデルは呼び出し意図を出すだけだ。

2026 年の AI Agent はどう動くか

ループは今も observe → plan → act → observe。変わったのは、各ホップに型が付いたことだ。「返金と言った」では足りない。

Observe：ユーザーメッセージ、直前のツール結果、現在の JSON 状態をコンテキストへ。
Plan：モデルは直接回答、ツール呼び出し、別 Agent への handoff のいずれかを選ぶ。
Act：ホストが tool_calls を実行するか、handoff JSON で Agent を切り替える。
Observe again：結果は role: tool で戻り、状態オブジェクトを更新して次ターンへ。

ホストはモデルが代わりにやってくれない四つの仕事をする。tools[] の注入、arguments の再パース、Schema 検証、失敗時のショートサーキット（長い prompt の再試行ではない）。

本番スタックはすでに収束している。Assistants API は 2026 年 8 月 26 日に退役し、新規コードは Responses API + Agents SDK だ。DevDay 2026 予測は同じ流れを三層で書いた：Structured Outputs がオブジェクトを形作り、Function Calling が呼び出しを表し、Agent ランタイムが両者を編む。

多段階タスクの進捗をチャット履歴に思い出させない。現在ステップを復元可能な JSON で書く：

{
  "step": 2,
  "agent": "billing",
  "last_tool": "lookup_order",
  "state": {
    "order_id": "A-1042",
    "status": "paid",
    "amount": 99.00
  },
  "next": "create_refund"
}

まずローカルで整形と構文チェックし、先週動いた定義と JSON Diff する。ユーザーデータや秘密を含むツール応答を公開 JSON サイトへ貼らない。

Tool Calling とは何か？

Tool Calling は能力層の総称だ。モデルが適切なタイミングで「外部能力が要る」と機械可読に出す。自然言語でデータベースを引いたふりをしない。ベンダー固有のフィールド名には縛られない。

2026 年、少なくとも三実装が Tool Calling と呼ばれる：OpenAI 互換 API の Function Calling、Anthropic などの Tool Use、MCP の tools/list + tools/call。MCP Tool Schema vs Function Calling が境界を書いた：MCP はホスト横断でツールを供給し、API フレームがこのホップの意図を表す。

開発者にとって Tool Calling が答えるのは「モデルは手を伸ばせるか」だ。「伸ばしたあと、引数と戻り値を誰が検証するか」は Schema とホストの仕事だ。

Function Calling とは何か？

Function Calling（OpenAI ドキュメントは今ほとんど tools）は、Tool Calling のベンダー Chat / Responses API における具体形だ。関数定義を注入し、モデルが呼ぶと応答に tool_calls が付く。

典型的な OpenAI 風の定義はこうだ。parameters はすでに JSON Schema のサブセットである：

{
  "type": "function",
  "function": {
    "name": "lookup_order",
    "description": "Look up an order by ID",
    "parameters": {
      "type": "object",
      "properties": {
        "order_id": {
          "type": "string",
          "description": "Order ID, e.g. A-1042"
        }
      },
      "required": ["order_id"],
      "additionalProperties": false
    }
  }
}

呼び出し意図はだいたいこう返る：

{
  "tool_calls": [{
    "id": "call_3c91",
    "type": "function",
    "function": {
      "name": "lookup_order",
      "arguments": "{\"order_id\":\"A-1042\"}"
    }
  }]
}

arguments は今も文字列化された JSONだ。ホストは再度 JSON.parse し、order_id を Schema で検証する。この一段を飛ばすのが 2026 年最頻の本番事故だ。入れ子が崩れたら、まず整形と構文チェックで括弧とエスケープを見る。

Tool Calling と Function Calling をどう分け、どう重ねるか

競合製品ではない。層が違う：

Tool Calling：概念。「モデルが意図を出し、ホストが実行する」なら該当する。
Function Calling：API フレーム。フィールドは tools[]、tool_calls、role: tool。
MCP Tool Schema：供給プロトコル。フィールドは inputSchema。stdio / SSE で MCP Server へ転送する。

正しい重ね方：リポジトリに Schema を一つ置き、Function Calling の parameters と MCP の inputSchema に書き出す。prompt の散文で「ほぼ同じ」第三の引数説明を持たない。詳細は MCP Tool Schema vs Function Calling と AI Agent が JSON Schema を必要とし始めた理由。

なぜ 2026 年の Agent はすべて JSON に着地するか

自然言語はユーザー向けだ。機械同士の各ホップは検証でき、Diff でき、再生できなければならない。JSON は五種のオブジェクトを運ぶ：

ツール定義：tools[] または MCP inputSchema。
呼び出し意図：tool_calls 内の関数名と引数。
ツール結果：照会・書き込み・外部 API の戻りオブジェクト。最も欠けやすい層。
Agent handoff：意図、確信度、転送先。Agents SDK は「billing と言った」ではなくこのオブジェクトでルーティングする。
ワークフロー状態と評価：checkpoint、trace、eval fixture。長時間ジョブは JSON から再開する。チャットログから進捗を推測しない。

JSON Schema はその口径だ。口径がなければ Function Calling、MCP、A2A はそれぞれ「似た定義」へ漂う。AI Agent が JSON Schema を必要とし始めた理由は Schema を文書からランタイムゲートにした。構文の入門は JSON Schema チュートリアル。

一連の JSON パイプライン

「注文照会 → 返金」を例にする。2026 年の保守的でテスト可能な鎖はこうだ：

ホストが lookup_order / create_refund の Schema を tools[] に入れ、strict: true を付ける。
モデルが tool_calls を返す。arguments はまだ文字列。
ホストが JSON.parse し、同じ Schema で検証する。失敗ならショートし、課金系には触らない。
実照会を実行し、注文オブジェクトを得る。
role: tool で返す。散文ではなく、Schema に合う JSON が望ましい。
モデルは次のツールを呼ぶか、ユーザー / 下流 Agent 向け Structured Output を出す。
Agent を替えるなら handoff オブジェクトを書く。「billing に聞いて」とは書かない。

handoff オブジェクトはこの程度まで安定させる：

{
  "handoff": {
    "from": "triage",
    "to": "billing_agent",
    "intent": "refund",
    "order_id": "A-1042",
    "confidence": 0.91
  }
}

複数 Agent が互いを発見する必要があるとき、A2A Extensions は能力を Agent Card に書き、拡張ヘッダで交渉する。上のパイプラインを置き換えず、Agent 間の配送だけを担う。

2026 年に何を選ぶか

単体アプリ、閉じた内部ループ、ツール 10 個未満：Function Calling で足りる。先に Schema と strict: true を CI へ。
IDE / プラットフォーム / 差し替え可能な第三者ツール：供給は MCP、このホップの意図は Function Calling。
異種 Agent が発見と拡張交渉をする：私有封筒を増やさず A2A を足す。
どの道でも：ツール引数・結果・handoff を先に JSON Schema にし、アダプタを書き出す。

基調講演が「プロトコルを統一する」のを待たない。2026 年の安定策は層分けであり、勝者予想ではない。

よくある誤り

Agent をよく話す ChatGPT だと思う。 ダイアログはデモになる。本番は復元可能な状態機械が要る。
Tool Calling と Function Calling を競合製品だと思う。 一方は概念、一方は API フレーム。MCP は第三の供給層だ。
arguments を検証しない。 文字列化 JSON、数値の文字列、余分なフィールドの課金混入は、すべてこのホップで起きる。
ツール結果が自由テキスト。 次ホップは「成功っぽい」を注文状態として扱う。
1 リクエストに 50 ツール。 巨大 Schema は高く、誤選択も増える。10 を超えたらルーティングか検索を入れる。

FAQ

Agent には Function Calling が必須か？

必須ではない。Function Calling は最も多い API フレームだが、MCP Tool Use もベンダー Tool Use も Tool Calling だ。要点はホスト実行と Schema 検証であり、フィールド名が tools か inputSchema かではない。

Tool Calling は Function Calling の新しい名前か？

文書によっては混用する。きれいな分け方：Tool Calling は総称、Function Calling は OpenAI 互換の tools / tool_calls 形。アーキ図で箱を分ければ議論の大半は消える。

JSON mode だけで Schema は不要か？

JSON mode は「JSON に見える」ことだけを保証し、フィールド・型・enum の合法性は保証しない。2026 年の Structured Outputs は json_schema + strict で口径を固定する。多段 Agent では JSON mode は評価セットを通らない。

DevDay 2026 まで待つべきか？

待たない。9 月 29 日は Structured Outputs と呼び出し計画を深めるかもしれないが、「先に Schema を書く」は変わらない。今ツールと handoff を git に入れ、基調後はアダプタだけ替える。

ツールと handoff の JSON をどうデバッグするか？

ブラウザで整形し、欠けた required を確認し、前版と Diff する。JSONSort はローカル実行でアップロードしない。秘密を含むツール応答を公開サイトへ貼らない。

まとめ

AI Agent はツールと状態を持つランタイムであり、より上手に話すモデルではない。Tool Calling が手を伸ばさせ、Function Calling はその手の最も一般的な API 形、JSON は各ホップで一致しなければならないオブジェクトだ。

今日から schemas/tools/lookup_order.json を先に書く。prompt を長くするな。モデルは変わり、プロトコルは増える。先に口径を安定させよ。

AI Agent が JSON Schema を必要とし始めた理由 Tool Calling から構造化ワークフローへ
MCP Tool Schema vs Function Calling ツール JSON のプロトコル境界
A2A Extensions と JSON プロトコルマルチ Agent 相互運用の第三層
OpenAI DevDay 2026 の要点予測三層が一本の JSON 管になるまで
JSONSort ローカルツール箱整形、検証、Diff
すべての記事 JSON と AI 開発のノート

更新履歴： 2026-09-05 初回公開