ブログ • AI / JSON Schema

iPhone 18 の AI 機能の背後にあるデータ構造：Apple Intelligence、App Actions、JSON Schema はどう接続するか

iPhone 18 の AI 動作が App につながるのは、製品紹介の文章ではなく、Intent のパラメータに揃えた JSON Schema があるからだ。システムモデルは候補フィールドを出す。@Parameter が App の受け付けるものを宣言する。Schema はその間にあり、合わないオブジェクトは動作に入らない。

製品の話は iPhone 18 がハードウェア以上である理由。一つの指示がフレーズから API へ行く道は App Actions のデータ経路。この記事はフィールドだけ。型の対応と、拒むべき値。

• Intent のパラメータは App 側の型契約
• JSON Schema は、モデル出力を止めるための同じフィールド表
• AppEnum は enum。AppEntity は id だけを受け、表示名は受けない
• additionalProperties が false なら、余分なキーはすぐ失敗する

三つの側がどう接続するか

App が受け付ける値は Intent のパラメータに書く。説明は App Intent にパラメータを追加する。モデルは JSON オブジェクトを提案できるが、フィールド表は変えられない。

1. 1
   システム側が候補を出す

   端末上のモデルやショートカットがオブジェクトを埋める。動作名、数量、受け取り方、商品 id。これは候補であり、すでに実行された呼び出しではない。

2. 2
   App 側が型を宣言する

   各パラメータは文字列、整数、固定の列挙、または解決が必要なエンティティ。任意のパラメータは required に入れない。

3. 3
   Schema が通すかを決める

   候補は先に Schema を通る。通ってから Intent に書く。失敗したら検証で止まり、動作も API も呼ばない。

型がどう対応するか

フィールド表の外のキーは additionalProperties: false で拒む。モデルが note や user を足しても動作には入らない。

検証器に貼れる Schema

下の Schema は一つの注文動作に揃える。意図名は固定、パラメータは商品 id、数量、受け取り方。これは自分の契約であり、Apple の通信形式ではない。

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "additionalProperties": false,
  "required": ["intent", "parameters"],
  "properties": {
    "intent": { "const": "StartOrder" },
    "parameters": {
      "type": "object",
      "additionalProperties": false,
      "required": ["item_id", "quantity", "fulfillment"],
      "properties": {
        "item_id": { "type": "string", "minLength": 1 },
        "quantity": { "type": "integer", "minimum": 1 },
        "fulfillment": { "enum": ["pickup", "delivery"] }
      }
    }
  }
}

{
  "intent": "StartOrder",
  "parameters": {
    "item_id": "sku_42",
    "quantity": 1,
    "fulfillment": "pickup"
  }
}

受け取り方を自然文にする、または item_id を空にすると通らない。通ってから、前回の記事の実行経路に渡す。

拒否すべき四つの形

モデル出力に先に Schema が要る理由は AI に JSON Schema が必要な理由。この記事はその表を App の動作パラメータに接続する。

他の二本との分担

JSONNote でこの表を確認する

1. 1
   Schema を貼る

   上の Schema を JSON Schema に貼る。intent が const、fulfillment が enum であることを確認する。

2. 2
   候補を一つぶつける

   JSON 検証 に候補を貼る。空の id、余分なフィールド、誤った列挙は失敗するべきだ。

3. 3
   フィールドを変えたあと比べる

   JSON Diff で required から item_id が消えていないか見る。必須が一つ減るのは、文を直すより危険だ。

よくある質問

JSON Schema は Apple のリクエスト形式ですか？

違う。Apple は App Intent のパラメータ型で動作を表す。Schema はモデル出力と perform() の間に置く検証だ。合わなければ呼び出さない。

エンティティのフィールドを商品名にしてはいけないのはなぜですか？

名前は変わり、重複する。AppEntity の主キーは安定した id だ。Schema はその id を空でない文字列に限定する。名前は表示用だけ。

任意パラメータは Schema に書きますか？

properties には書く。required には入れない。欠けても合法で、あれば型に合わせる。

検証を通れば動作を実行してよいですか？

まだだめだ。Schema が証明するのは形だけ。エンティティ id はクエリで解決する必要がある。形が正しくても対象が無ければ注文できない。

「AI に JSON Schema が必要な理由」と同じ記事ですか？

違う。あちらはモデル出力に形が要る理由。こちらはその形を App の動作パラメータに合わせ、余分なキーや誤った列挙を拒む。

まとめ

Apple Intelligence と App の動作は、同じフィールドでつながる。動作名、型、列挙、エンティティ id。JSON Schema はその表を、失敗できる検査にする。

結論：パラメータ型を先に Schema に揃える。余分なキーは拒む。エンティティは id だけ。検証に失敗したら動作に入れない。

ブログへ戻る