ブログ • AI / Agent

Siri AI は AI Agent になるか？Apple Intelligence、App Actions、API と JSON の仕組み

Siri AI と聞くと、ChatGPT のように自分でツールを選び、API を組み立てる Agent を想像しやすい。Apple が WWDC 2026 で出したのは、その種類ではない。

Siri AI はシステム Agent になりつつある。個人コンテキストを理解し、画面上の内容を見て、App をまたいで App Actions を実行する。オープン Agent ではない。モデルは REST パスを発明できず、サーバに勝手な JSON を書けない。

この記事では：

• Apple Intelligence と Siri AI がそれぞれ担う層
• App Actions が開発者側で何に対応するか（App Intents + App Schemas）
• 一度のクロス App タスクでデータがどう流れるか
• JSON が現れるホップ、現れないホップ
• Function Calling / MCP Agent との比較、および JSONNote で動作引数を検証する方法

先に答え：システム Agent であり、オープン Agent ではない

Agent という言葉は今、使い古されている。ある人は「会話する助手」、ある人は「ツールをループして仕事を終えるランタイム」だと思っている。Siri AI は後者に近い。ただしツールの出所は、オープン Agent とまったく違う。

オープン Agent（ChatGPT、Claude、自前 Runtime）はだいたいこう動く。モデルが会話を見て、tools 一覧から name と arguments を選び、Runtime が実行し、結果を会話に戻す。ツールカタログは自分で書く。JSON Schema が入力契約で、MCP が発見と実行を担うことが多い。本サイトの別記事がこの四層を分解している：

2026 AI Agent 技術スタック：LLM、MCP、Function Calling、JSON Schema はどう組み合わせる？

Siri AI のループはシステムの中で起きる。ユーザーが Siri に話すか、画面上の「これ」を指す。システム側のモデル（端末上、または Private Cloud Compute）が意図を理解し、インストール済み App が公開した動作カタログから選ぶ。あなたの App は会話の主人ではない。呼ばれる側にすぎない。

だから答えは「はい」か「いいえ」ではない。Siri AI は計画し、スロットを埋め、App をまたいで連続して仕事をする。これはすでに Agent の振る舞いだ。好きな MCP Server を載せられるオープンランタイムにはならない。どちらのチェーンも App、API、JSON に触れる。ただし誰が会話を持ち、誰が引数を生成するかは同じではない。

Apple Intelligence と Siri AI はそれぞれ何か

まず製品名を分ける。混ぜると、この先の App Actions と JSON の置き場が無くなる。

Apple Intelligence はプラットフォームだ。生成モデルを iPhone、iPad、Mac のシステム能力に埋め込む。執筆、画像、通知要約、Visual Intelligence、そして一部の端末外推論がこの層に掛かる。端末外のリクエストは Private Cloud Compute を通り、普通のパブリッククラウドのログではない。公式入口は

Apple Intelligence。

Siri AI は 2026 年 6 月の WWDC で発表された次世代 Siri で、次世代 Apple Intelligence が駆動する。Apple 自身の言い方はこうだ。より会話でき、個人コンテキストがあり、世界知識があり、画面を感知でき、システム全体でより多くの App Actions を呼べる。あわせて、デバイスをまたいで会話を振り返る独立した Siri アプリも増えた。ニュースは

Apple が Siri AI を発表。

開発者テストは WWDC 当日から始まり、iOS 27、iPadOS 27、macOS 27、visionOS 27 をカバーする。2026 年 9 月初旬時点では、秋のシステムテスト周期の中にいる（8 月末に iOS 27 developer beta 8）。この記事を書く時点で、全ユーザー端末で既定オンの完成品だと思わないこと。

三つ目のチェーンもある。Siri と混ぜないでほしい。App の中で Foundation Models を使って自分でセッションを起こす。そのときモデルは自分のプロセスで走り、ツールは自分で注入する。システムは「どの App を開くか」を代わりに選ばない。フレームワーク説明は

Foundation Models。

WWDC 2026 は Gemini を、従来の ChatGPT と並ぶ選択可能な外部基盤モデルに加えた。ユーザーにとっては「世界知識を聞くときの出口が一つ増える」。開発者にとっては App Actions の契約はほとんど変わらない。外部モデルは、宣言していない Intent に触れられない。

App Actions：Siri はどうあなたの App を呼ぶか

ユーザーが聞くのは App Actions：Siri がこの App に何ができるか。開発者が実装するのは App Intents。Siri AI に動作を組ませるには、さらに App Schema（assistant schema）に揃える。システムの事前学習モデルが「これはどの種類の動作か」を認識するためだ。

Apple の WWDC26 の言い方は率直だ。Siri が強くなったのは Apple Intelligence。開発者が Apple Intelligence に参加する手段は App Intents。セッション

Build intelligent Siri experiences with App Schemas

は Siri の能力を三つにまとめる。Entity へのアクセス、Intent による実行、画面上の文脈の理解。

App Intents は能力カタログ

システム Agent にとって、App は「開いて眺める」ものではない。発見可能な能力カタログだ。AppIntent で動作名、自然言語の説明、引数の型、結果を宣言する。Spotlight、Shortcuts、Siri、Apple Intelligence がこのカタログを共有する。ユーザーが「この請求書を支払済みにする」と言ったら、システムは MarkInvoicePaidIntent に対応させるのであり、モデルに UI を適当にタップさせない。

ドキュメント：

App Intents

および

Siri と Apple Intelligence に actions をつなぐ。

App Schemas が Siri に種類を教える

普通の App Intent はすでに Shortcuts に出せる。Siri AI に自然言語で呼ばせるには、Intent、Entity、Enum をどれかの assistant schema に紐づける。photos.openAsset、notes.createNote など。Schema には固定の引数の形がある。Xcode がコンパイル時に揃っているかを見る。

ここがオープン Agent との最大の差だ。オープン Agent のツール名は自分で付ける。Siri AI のツール名は、Apple が事前学習した領域語彙に落とす必要がある。より「創造的」な動作名に替えると、システムが選べないことがある。

@AppIntent(schema: .finance.markInvoicePaid)
struct MarkInvoicePaidIntent: AppIntent {
    @Parameter var invoice: InvoiceEntity
    @Parameter var paidAt: Date

    func perform() async throws -> some IntentResult {
        try await InvoiceService.markPaid(
            id: invoice.id,
            paidAt: paidAt
        )
        return .result()
    }
}

上の断片に JSON は無い。Siri が渡すのは型付き引数だ。業務は perform() で行う。ネットワークが必要なら、ドメインサービスがそこで JSON を組む。

テストは Siri から始めない。Apple は AppIntentsTesting を提供しており、隔離環境で Intent を呼び、引数を渡し、結果をアサートできる。次に Shortcuts で形を見て、最後に Siri でエンドツーエンドを試す。この順を逆にすると「モデルが暴走した」ように見えるが、実際は schema が揃っていない。

一度のクロス App タスクのデータフロー

具体的な依頼で層をつなぐ。ユーザーがメッセージで「金曜は持ち寄り、サラダ担当で」を見て、その文を指して Siri に言う。メモに残して、買い物リストにレタスとオリーブオイルを足して。

1. 1
   画面コンテキストがシステムに入る

   Siri は onscreen awareness で「これ」が 1 通のメッセージだと知る。ビューを App Entity につなげておかないと、システムは指示を解決できず、モデルがピクセルを当て推量することになる。

2. 2
   モデルは計画と選定だけ

   システムモデルは発言を二段に分ける。Notes の作成動作、Shopping の項目追加動作。URL を組み立てず、SQL も書かない。

3. 3
   Schema に沿って引数を埋める

   タイトル、日付、項目名が型付き値になる。スロットが欠けていれば Siri がもう一度聞く。このステップの契約は assistant schema であり、OpenAPI ドキュメントではない。

4. 4
   各 App が perform() を実行

   Notes と Shopping がそれぞれ自分の Intent を走らせる。サーバ同期が必要なとき、ここで初めて HTTP JSON が現れる。

5. 5
   結果がシステム会話に戻る

   Siri は Intent の結果で返答を組む。クロス App の Entity 受け渡しは Transferable でよく、会話に JSON 一式を流し込まなくてよい。

このチェーンで開発者が踏みやすい穴。Intent を「何でもやる」万能関数にする。description が広すぎて、何でもその動作に来る。あるいは perform() で注文 JSON 一式を返し、システムのコンテキストを膨らませすぎる。より良いのは要約を返し、詳細は id で二番目の動作から取る。

このチェーンでの JSON の三層の役割

Swift 型はコンパイル時の契約、JSON は実行時の契約だ。Siri のホップに JSON は無くてよい。動作が今のプロセスを出た瞬間——バックエンド、ファイル、テストフィクスチャの再生、別 Agent の再利用——形は言語非依存のテキストになる。

JSON は少なくとも三層の役割を担う。うち二層を混ぜると、「parse はできるが、フィールドが全部違う」になる。

第一層がいちばん見落とされる。Xcode の App Intents Console は呼び出しと引数を出す。同じ呼び出しを JSON オブジェクトに書けないと、障害対応に再生が無い。第二層は請求と認証が本当に起きる場所だ。第三層は 2026 年に多くのチームがすでにやっている。同じ markPaid を Siri にも、社内 Claude Agent にも出す。

JSON Schema は App Schema の代わりにならない。App Schema はシステムモデル向けの領域契約。JSON Schema はバックエンド、テスト、外部モデル向けのデータ契約だ。フィールドは揃える。Siri が OpenAPI ファイルを読むと思わないこと。AI 側がこの契約を広く必要とする理由は

AI に JSON Schema が必要な理由

Function Calling / MCP と何を比べるか

比べるのは一件だけ。意思決定が何にシリアライズされるか。

オープン Agent では、モデル API が返すのは一段の JSON だ。選んだツール名と、parameters に合う arguments。Runtime が検証してから実行する。MCP は同じ形を inputSchema / structuredContent に載せる。詳細は

AI Agent に JSON Schema はなぜ必要？Tool Calling から Structured Output まで完全解説。

{
  "type": "function",
  "function": {
    "name": "mark_invoice_paid",
    "description": "Mark one invoice as paid.",
    "parameters": {
      "type": "object",
      "required": ["invoice_id", "paid_at"],
      "properties": {
        "invoice_id": { "type": "string" },
        "paid_at": { "type": "string", "format": "date-time" },
        "amount_cents": { "type": "integer", "minimum": 0 },
        "currency": { "type": "string", "enum": ["USD", "CNY", "EUR"] }
      },
      "additionalProperties": false
    }
  }
}

Siri AI 側にこの JSON は無い。等価物は @AppIntent(schema:) と @Parameter だ。モデルはなお「動作を選び、スロットを埋める」。シリアライズ形式がシステムの型付き呼び出しに変わっただけだ。

だから App Intent を「Siri に JSON を出させる」層でもう一度包まない。プロンプトを一層足してもシステムは安定せず、障害対応から型検査が消えるだけだ。欲しい安定は perform() のあとにある。ドメインサービスが受け取ったオブジェクトが、上の arguments にロスなくエンコードできるか。

選択も具体的だ。ユーザーがすでに Apple 端末にいて、動作をシステムカタログに収められるなら Siri AI。Android、Web、社内 Slack ボットで再利用するなら Function Calling と MCP。「うちにも Agent がある」ために、二本のチェーンを一枚の万能図に描かない。

HTTP API に届いたときの JSON の形

Intent はネットワークを直接打つべきか。短い動作は perform() で終わらせてよい。認証、ページング、冪等が出てきたら、perform() は「引数の検証 + ドメインサービスの呼び出し」だけ。JSON リクエストはドメインサービスが送る。

以下は「請求書を支払済みにする」がバックエンドに落ちたときのペイロードだ。フィールド名は社内課金システムでよく見る書き方。数字は例であり、どこかの銀行の実在 API ではない。

{
  "action": "invoices.markPaid",
  "source": "siri-ai",
  "idempotency_key": "inv_1842:paid:2026-09-09",
  "arguments": {
    "invoice_id": "inv_1842",
    "paid_at": "2026-09-09T02:14:00Z",
    "currency": "USD",
    "amount_cents": 12800
  }
}

このオブジェクトがあれば、三つの問いに答えられる。誰が起動したか、再実行できるか、金額が合うか。idempotency_key が無いと、Siri が一度再試行しただけで二度支払済みになる。amount_cents が文字列になると、あとの帳簿が全部漂う。

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "required": ["action", "source", "idempotency_key", "arguments"],
  "properties": {
    "action": { "const": "invoices.markPaid" },
    "source": { "type": "string", "enum": ["siri-ai", "shortcuts", "app"] },
    "idempotency_key": { "type": "string", "minLength": 8 },
    "arguments": {
      "type": "object",
      "required": ["invoice_id", "paid_at"],
      "properties": {
        "invoice_id": { "type": "string", "minLength": 1 },
        "paid_at": { "type": "string", "format": "date-time" },
        "amount_cents": { "type": "integer", "minimum": 0 },
        "currency": { "type": "string", "enum": ["USD", "CNY", "EUR"] }
      },
      "additionalProperties": false
    }
  },
  "additionalProperties": false
}

システム Agent は REST パスを知る必要が無い。必要なのは Intent の成功か失敗だ。パスを知る必要があるのはこちらだ。監査と再試行が API 層にあるから。Intent 引数を「JSON オブジェクトに書ける」フィールド集合にしておけば、あとでオープン Agent をつなぐときのアダプタが一層省ける。

JSONNote で Action 引数を検証する

遅い部分は、めったに Swift マクロではない。遅いのは二回の呼び出しの JSON が合わないことだ。Siri の再試行がフィールドを一つ足し、Shortcuts が enum を一つ落とし、内部 Agent が amount_cents を 128.00 と書く。JSONNote はブラウザローカルで処理する：

1. 1
   まず一度の呼び出しを整形する

   App Intents Console やバックエンドログのオブジェクトをJSON フォーマットに貼り、インデントと構文のノイズを落とす。

2. 2
   Schema で必須フィールドを固定する

   上の草案をJSON Schemaページに貼り、action、idempotency_key、invoice_id が残っているか確認する。

3. 3
   Siri とオープン Agent の二回の呼び出しを比べる

   JSON Diffで source が siri-ai から mcp に変わったか、arguments が漂っていないかを見る。

4. 4
   同僚が必要なときだけ共有する

   Hash 共有でサンプル（秘密は入れない）を URL fragment に載せる。サーバには届かない。

よくある質問

Siri AI は AI Agent ですか？

システム Agent であり、オープン Agent ではありません。App をまたいで動作を選び、引数を埋め、流れをつなげます。ただしツールカタログは App Intents と App Schemas で固定され、モデルは API を自分で発明できません。

App Actions と App Intents は同じものですか？

同じ製品名ではありません。App Actions はユーザーとシステム側の言い方で、Siri が App に何ができるか。開発者が実装するのは App Intents です。App Schema に揃えて初めて、Siri がその種類の動作を認識します。

Siri は自分の REST API を直接打ちますか？

いいえ。Siri は宣言した Intent だけを呼びます。HTTP は perform() の中で自分で打ちます。システム Agent が欲しいのは成功か失敗の意味であり、請求、認証、再試行は API 層にあります。

Apple は Swift 型を使うのに、なぜ JSON Schema が必要ですか？

Swift 型はコンパイル時を担います。動作がプロセスを出た瞬間——バックエンド、ログ、テスト再生、外部 Agent の再利用——形は言語非依存の JSON になります。Schema が検証するのはこのホップであり、Siri のホップではありません。

Siri AI を使うべきか、自分で Function Calling Agent を組むべきか？

ユーザーがすでに iPhone にいて、動作をシステムカタログに収められるなら Siri AI。クラウドやプラットフォームをまたぐ、またはモデルを自分で選ぶなら Function Calling と MCP。同じドメイン関数を両チェーンに出せます。替えるのはアダプタ層だけです。

まとめ

Siri AI は Agent になる。ただし OS の中の Agent であり、好きなツールを載せられるオープン Runtime ではない。

Apple Intelligence がモデルを出し、App Actions（App Intents + App Schemas）が組める動作を出し、JSON はこれらの動作がデバイスを出たあとの契約だ。

まず Intent 引数を JSON オブジェクトに書けるフィールドに設計し、Siri チェーンと Function Calling チェーンに同じ Schema を載せる。モデルとシステム入口はまだ変わる。検証層がデモから本番への防波堤だ——これらの JSON は JSONNote でローカルに整形、検証、比較できる。アップロードは不要。

← ブログに戻る