Siri AI は AI Agent になるのか？Apple Intelligence、JSON、API、Tool Calling と App Actions

先に答える：仕事はする。開放 Agent にはならない

発表会の形容ではなく工学定義で締める。Agent には目標、知覚、行動が要る。モデルが次のツールと引数を選び、ランタイムが実行して観察を書き戻す。旧 Siri は多く「一文を聞き、ショートカットかシステム機能を開く」だけで、「結果を見てから決める」循環はほとんどなかった。2026 年の Siri AI はその環を閉じ始める。App Intents の目録から動作を選び、画面文脈で「これをメモに保存」を解釈し、App をまたいで次の Intent にエンティティを渡せる。振る舞いはシステム級 Agent に近づいている。

それでも IDE やサポート卓で組む開放 Agent ではない。差はモデルの賢さではなく、ツール境界を誰が引くかだ。開放 Agent の一覧はあなたが注入する。OpenAI tools[]、Anthropic tool_use、MCP tools/list。arguments はほぼ常に JSON。システム Siri の一覧は、端末に宣言済みで、できれば App Schema に沿った Intent。引数は Swift の型であり、自分で parse する自由テキストではない。プライバシーの柵も違う。端末と Private Cloud Compute が、どの文脈を出せるかを決める。「連絡先を読んでよい」とシステムプロンプトに書く話ではない。Siri を「関数をぶら下げられる別の ChatGPT」と読むと、誤った移行になる。App Intents を消す、iOS から Gemini API を呼んで「本家に揃える」などだ。

一文にする。Siri AI はシステムの中の Agent になる。あなたが所有する Agent ランタイムにはならない。制御できるのは、システムに出す動作の形と、動作が HTTP に落ちたあとの JSON だ。次の二節で製品層と契約層を分け、「仕事ができる」を「開放ツール循環」と読まないようにする。

2026 年の Siri AI が実際に増えた三つのこと

Apple の開発者文書と WWDC26 の公式説明は、Siri の App Intents 能力を三つに畳む。Agent に見える理由と、JSON Schema を貼って終わりにできない理由の両方を説明する。

1. 内容に届く。業務オブジェクトを App Entity にし、Entity Schema に沿わせ、Spotlight の意味索引へ出す。Siri は個人文脈で「あの支払済み注文」を見つけられる。ホーム画面を開くだけではない。
2. 動作を実行する。Intent が Intent Schema（商務、写真、通信など事前学習領域）に沿えば、自然言語が perform() に届く。言い回しごとの発動フレーズは不要。公式が繰り返す app actions がこれだ。
3. 画面を理解する。View Annotations や NSUserActivity で眼前のビューをエンティティにする。ユーザは「これ」「それ」と言える。跨 App の要求は多くここから始まる。自前の多段 planner からではない。

三つが重なると、ユーザは「Siri が仕事をする」と感じる。開発者は、自分の App がシステム Agent のツールボックスになったと感じる。WWDC26 の Build intelligent Siri experiences with App Schemas はテスト順も固定する。まず Intent の業務論理、次にショートカットで引数の形、次に Spotlight の索引、最後に Siri のエンドツーエンド。前三段を飛ばして音声だけで当たると、切り分けのコストが大きい。

モデル層も動いている。それを製品のすり替えと読まない。2026 年 1 月の共同声明は次世代 AFM の基盤を Gemini 技術に掛けた。6 月、Private Cloud Compute はより重い agentic tool-use のために Google Cloud へ広がった。ユーザが見るのは今も Siri / Apple Intelligence であり、Gemini ブランドでも Google Assistant でもない。戦略の分解は Apple が Gemini に頼る理由。ChatGPT 拡張との層分けは 三社比較。あなたにとって変わるのは、クラウドモデルがどれだけ大胆に多段動作を組むかであり、パラメータ表の姓ではない。

三層：Apple Intelligence、モデル、開発者面

「Siri が Agent になった」を一層に潰すと、あとの判断がすべて傾く。少なくとも三つに分ける。人が見る製品、推論が走る場所、コードが実装する契約。

Foundation Models は別線だ。App は端末（および文書が書く PCC 経路）で LanguageModelSession を走らせ、Tool で App 内 tool calling をし、構造化生成で出力を縛る。これは「自分の App が Agent ランタイムになる」話であり、「システム Siri が Agent で Intent に入る」話ではない。多くの App は両方出す。Siri / Spotlight / ショートカットに見つけてもらうなら App Intents。端末モデルに在庫照会やフォーム入力をさせるなら Tool。HTTP へのつなぎは Apple AI Agent が App と API に届く方法。

ショートカットが層を接着する。Apple Intelligence は自然言語から多段自動化を組める。App Intents を採用すると、動作は Use Model などと並ぶ生態に入る。ユーザは「支払済み注文を調べてメモに書く」と述べられる。編成者は今もシステムであり、サーバ上の planner ではない。各 Intent の引数は単独で成立しなければならない。システムは一 hop だけ走らせることも、順を入れ替えることもある。

App Intents、App Schemas、App Actions

App Intents は「Siri に音声を足す」ではない。第三者 App と Apple Intelligence の契約だ。出せる内容と実行できる動作を宣言し、いつ呼ぶかはシステムが決める。iOS 18 から広がり、2026 年には Siri、Spotlight、Widget、ショートカット、システム Agent に同時に供給する。App Intents を任意だと思っているチームは、システム AI の玄関を誤読している。

App Schema はその契約の事前学習された形だ。Entity Schema は注文、写真、会話だと教え、意味索引に入れる。Intent Schema は検索、開く、共有だと教え、維持する発動コーパスなしに自然言語を当てる。Xcode のマクロが適合スタブを出し、コンパイル時に確かめる。領域がずれると、Siri は動作を普通のショートカットとして扱い、システム Agent が優先するツールにはしない。WWDC26 はより長い Intent、取消、デバイス間同期エンティティも足した。循環らしくはなるが、スケジューリングはシステムのままだ。

App Actions という語が最も飛びやすい。Apple の開発者ページの app actions は、App Intents 経由で Siri AI とシステム面が実行する能力だ。Google Assistant の歴史的な App Actions プロトコルでも、Android の intent filter でもない。どちらも「助手が App を呼ぶ」が、フィールド、一覧、プライバシー模型は一致しない。設計書では「App Intents / App Schema」と書き、「App Actions」はユーザ向けの言い方に残す。混ぜると、バックエンドが存在しない Google 風 JSON-RPC を探し始める。

Tool Calling：システム Agent と App 内 Tool

業界の Tool Calling / Function Calling は一つの仕組みだ。モデルはデータベースに触らず、「この関数をこの引数で呼んで」と出し、ランタイムが実行する。2026 年、シェルは違う。arguments は JSON object のまま。Siri 側では同じことが型付き Intent になる。システムモデルが findOrders を選び、email / status / limit を埋め、perform() に入る。perform() が自前 HTTP API を叩くなら、そこで JSON に編む。二つの hop で「とにかく parse」を共用しない。

ゴールデンペイロードは意図層に置く。モデル商標の下には置かない。下の JSON は、誰が始めたか、どの schema、どの動作、どの引数だけを書く。runtime.onDevice はログでよい。業務検証には入れない。端末の縮退とクラウド全量は同じ arguments を受けねばならない。

{
  "source": "siri-ai",
  "schema": "commerce.findOrders",
  "intent": "findOrders",
  "arguments": {
    "email": "ada@example.com",
    "status": "paid",
    "limit": 5
  },
  "runtime": {
    "surface": "siri",
    "onDevice": false
  }
}

同じ業務フィールドが、自分の開放 Agent に出ると、各社の tool_calls シェルを着る。arguments はしばしば文字列だ。先に JSON.parse、同じ Schema で検証。Siri から入るときはそのシェルは見えず、型付きパラメータだけが見える。自前 API へ出したとき、再び JSON が見える。

{
  "id": "call_8f3a",
  "type": "function",
  "function": {
    "name": "findOrders",
    "arguments": "{\"email\":\"ada@example.com\",\"status\":\"paid\",\"limit\":5}"
  }
}

対照は明快だ。名前はどちらも findOrders。キーは同じ Schema から来るべきだ。システム経路に tool_call id はなく、開放経路に App Schema ドメインはない。Gemini generateContent、OpenAI tools[]、App Intent のパラメータ表を互いのデフォルトにしない。Structured Output は最終回答の形であり、この hop の入力引数ではない。ファイルを分ける理由は AI Structured Output。

JSON、API、ローカル検証

Siri が Agent に近づくと、失敗も Agent に近づく。多 hop、任意フィールドが埋まる、列挙が飛ぶ、端末縮退でキーが二つ足りない。強いモデルは検証を不要にしない。見逃しを高くするだけだ。外向き hop は今も parse → Schema → 業務規則。

1. Intent パラメータを JSON にしたらすぐ parse する。失敗なら intent 名と生フィールドを残し、再試行可能な誤りを返す。Swift の例外原文をユーザに投げない。
2. 同じ Draft 2020-12 Schema で型、列挙、required を固定する。additionalProperties は false がよい。クラウド段が足したキーを下流へ漏らさない。
3. 業務ゲート：権限、外部キー、日付範囲。通ってから注文サービスへ。システム Agent が再試行するなら、API は冪等でなければならない。

三つの JSON を並べる。Siri / ショートカットが入してきたパラメータ、HTTP に出す body、サーバが実際に使ったオブジェクト。形が違えばほぼアダプタ層。ブラウザではJSON フォーマッタでフィールドを見、JSON Schema 検証で型を固定し、JSON Diffで端末縮退とクラウド全量の欠けを見る。valid / missing-field / wrong-enum を CI と Siri 実機で共有する。

関連：Apple AI Agent と JSON、AI Agent とは、AI JSON エラーガイド、MCP と JSON Schema。

よくある質問

まとめと次の一手

Siri AI は AI Agent になる。システムの柵の内側で。Apple Intelligence が個人文脈、app actions、画面認識を出し、モデル層は Gemini 技術と重い PCC を借りられ、開発者は今も App Intents で動作を渡し、Foundation Models Tool で App 内ループを回す。開放 Tool Calling の JSON シェルはシステム要求には出ない。自前 API には出る。

次は具体的だ。揃える App Schema を列挙し、Intent パラメータと HTTP body を同じ Schema で書き、JSONVue で valid / 欠フィールド / 誤列挙を再生する。モデル商標は変わる。動作の形はついて変わってはならない。