App Intentsは、あなたのアプリへのAppleの新しいAPIです

2026年2月8日の朝、私は手をキッチンのシンクの下に入れたまま、Apple WatchからSiriに8オンスの水を記録するよう頼みました。水は記録されました。Watchのダイアログには残り32オンスと表示されました。画面には一切触れていません。¹

その11週間前、私は自分の水分補給トラッキングiOSアプリ「Water」に、たった1つのSwiftファイルを追加していました。LogWaterIntent.swiftです。AppIntentに加えて、3つのSiriフレーズのバリエーションを宣言するAppShortcutsProviderを含む、80行のコードでした。今やそのファイルは、私が所有する中で最もホットなAPIサーフェスとなっています。²

ここが、私が腑に落ちるまでしばらくかかった部分です。App IntentsはSiriの機能ではありません。 これは、サードパーティアプリがApple Intelligenceと結ぶ「契約」なのです。Apple IntelligenceはAppleがiOS 18で展開を始め、iOS 26まで構築を続けてきたシステムAIのサーフェスです。³ もしあなたがiOSアプリを出荷しているのに、App Intentsをいまだに「あったら嬉しい」音声機能として扱っているなら、Appleが築き上げたものを読み違えています。App Intentsは、AppleのAIがユーザーに代わってあなたのアプリとして動作することを可能にするAPIです。それ以外のすべて（Siri、Spotlight、Shortcuts、Apple Intelligenceによる要約、WatchやVision Proのサーフェス）は、その契約の下流に位置します。iOS 26で出荷されたオンデバイスLLMであるFoundation Modelsは、アプリ内のツール呼び出し用に別個のToolプロトコルを公開しています。これはApp Intentsを介するのではなく、App Intentsと並行して動作します。

TL;DR

• App Intentsは、あなたのアプリが何をできるのかを、AppleのAIが直接呼び出せる型付きで構造化された形で宣言します。Appleがサードパーティアプリに提供するツール利用APIです。
• 実際の本番環境の例を1つ挙げると、WaterのLogWaterIntentです。80行で、完全なSwiftDataの書き込み、HealthKit同期、ロケールに応じた単位変換、構造化されたSiriダイアログ応答を備えています。
• iOS 26はAppleのオンデバイスLLMであるFoundation Modelsを追加しました。Foundation Modelsはアプリ内のツール利用のために独自のToolプロトコルを公開しますが、App Intentsは依然としてSiri / Spotlight / Apple Intelligenceがアプリ横断で呼び出す正規のサーフェスであり続けます。方向性は同じで、契約が2つ並行している形です。
• 2026年において、App Intentsを持たないアプリはApple Intelligenceからは見えません。AIのファブリックは、あなたが宣言したインテントを経由するか、さもなければあなたのアプリを迂回して競合へとルーティングします。
• Appleは3年間、私たちにこのことを伝え続けてきました。命名（App Intents、App Shortcuts、Apple Intelligence）は意図的なものです。この契約はWWDCを迎えるたびに、スタックを1段ずつ上がっていきます。

App Intentsフレームワークのリファレンス画像。出典：Apple Developerドキュメント。⁵

App Intentとは実際に何なのか

2026年2月8日のコミットe398c58で出荷されたLogWaterIntentの全ソースコードです。²

import AppIntents
import SwiftData

struct LogWaterIntent: AppIntent {
    static var title: LocalizedStringResource = "Log Water"
    static var description: IntentDescription = "Log a glass of water to your daily intake"

    @Parameter(title: "Amount", default: 8)
    var amount: Int

    static var parameterSummary: some ParameterSummary {
        Summary("Log \(\.$amount) oz of water")
    }

    func perform() async throws -> some IntentResult & ProvidesDialog {
        let container = try ModelContainer(for: WaterEntry.self, DailyLog.self, UserSettings.self)
        let context = ModelContext(container)

        let settingsDescriptor = FetchDescriptor<UserSettings>(
            predicate: #Predicate { $0.id == "user-settings" }
        )
        let settings = try context.fetch(settingsDescriptor).first ?? UserSettings()

        let amountMl: Double
        if settings.unitSystem == .imperial {
            amountMl = Double(amount) * 29.5735
        } else {
            amountMl = Double(amount)
        }

        let todayKey = DailyLog.todayKey()
        let logDescriptor = FetchDescriptor<DailyLog>(
            predicate: #Predicate { $0.dateKey == todayKey }
        )
        let log: DailyLog
        if let existing = try context.fetch(logDescriptor).first {
            log = existing
        } else {
            log = DailyLog(date: .now, goalAmount: settings.dailyGoal)
            context.insert(log)
        }

        let entry = WaterEntry(amount: amountMl)
        log.entries.append(entry)
        try context.save()

        if settings.healthKitEnabled {
            try? await HealthKitService.shared.logWater(amount: amountMl, date: entry.timestamp)
        }

        let unit = settings.unitSystem == .imperial ? "oz" : "mL"
        let totalDisplay = settings.formatAmount(log.totalAmount)
        return .result(dialog: "Logged \(amount) \(unit). Today's total: \(totalDisplay)")
    }
}

struct WaterShortcuts: AppShortcutsProvider {
    static var appShortcuts: [AppShortcut] {
        AppShortcut(
            intent: LogWaterIntent(),
            phrases: [
                "Log water in \(.applicationName)",
                "Add water in \(.applicationName)",
                "Drink water in \(.applicationName)",
            ],
            shortTitle: "Log Water",
            systemImageName: "drop.fill"
        )
    }
}

（Waterの現在の本番バージョンでは、このファイルのダイアログをさらに改良し、目標達成／残量を条件分岐させています。上記の2月8日出荷時のコードが、私がキッチンのシンクでテストしたものです。)

ここで名前を挙げて触れておく価値があるのは3点です。ほとんどの「App Intentsチュートリアル」はこれらを軽く流してしまうからです。

@Parameterがスキーマです。 AppleのAIは、デフォルト値8を持つamount: Intを認識します。Siriが「log 12 oz of water」を解析すると、LogWaterIntent(amount: 12)を生成し、perform()を呼び出します。私の側での文字列パースは一切ありません。型システムこそがスキーマなのです。⁵

parameterSummaryは、パラメータを自然言語で反映したものです。 Appleはこれを使って、Shortcutsのインターフェース上、ダイアログ内、そしてますます増えているApple Intelligenceの確認パネル内でアクションを描画します。このサマリーはユーザーに向けて読み上げられます。間違えればユーザーは不自然な文を聞くことになり、正しく書けばそのサーフェスはネイティブのように感じられます。⁶

perform()はIntentResult & ProvidesDialogを返します。 これが構造化された戻り値です。AIサーフェスは成功／失敗だけでなく、ユーザーが聞くダイアログ文字列も受け取ります。AppleはProvidesDialog、ProvidesView、ReturnsValueをますます期待するようになっており、その結果はSiri、Spotlight、Watch、そして（iOS 26では）Apple Intelligenceの応答チェーンへと組み込まれていきます。⁷

一番下にあるAppShortcutsProviderブロックが、Siriのフレーズを登録する部分です。\(.applicationName)トークンは、Siriが自動的に「Water」を挿入する箇所です。同じインテントを持つ3つのフレーズのバリエーションを用意することで、フレーズ辞書を保守することなく、AppleのNLパーサーがユーザーの言い回しにマッチする余地が広がります。systemImageNameは実在するSF Symbolsの名前であり、Spotlight、Shortcuts、Apple Intelligenceがそのアクションのアイコンを描画する方法でもあります。

Apple Intelligenceは、App Intentsを経由してユーザーのリクエストをルーティングし、オンデバイスのAI機能を提供します。出典：apple.com/apple-intelligence。

なぜこれがSwiftUI以来、最も重要なiOS APIなのか

iOS APIには2つの形があります。アプリが自身をどう描画するかに関わるもの（UIKit、SwiftUI、Metal)。そして、アプリがシステムとどう統合するかに関わるもの（URLスキーム、Universal Links、widgets)。App Intentsは第3の形です。すなわち、AppleのAIがどのようにあなたのアプリを使うか、です。それらwidgetやControl Centerのサーフェスは、それ自体がApp Intentsのサーフェスであり、同じインテントが多くの場所で描画されたものです。この点はThe iOS 26 Widget Surfaceで追っています。

この変遷を辿る価値があります。

• iOS 10（2016年) はSiriKit Intents（INIntent）を導入しました。サードパーティアプリが音声で呼び出される最初の機会でした。そのサーフェスは狭いものでした。固定されたドメインのリスト（メッセージング、決済、配車手配）に、厳格なスキーマが課されていました。⁸
• iOS 12（2018年) はSiri Shortcutsでサーフェスを広げました。どのアプリもNSUserActivityやINIntentを提供（ドネート）し、Siriが提案してくれることを期待できるようになりました。
• iOS 13（2019年) はアプリ内でのインテント処理を追加し、システムのSiri UIへバックグラウンド移行することなく、ショートカットの呼び出しに応答できるようになりました。
• iOS 16（2022年) はApp Intentsフレームワークを導入しました。型付きで宣言的、@ParameterとAppShortcutsProviderを備えています。先行するINIntentは、新規開発においては事実上置き換えられました。⁹
• iOS 18（2024年) はApple Intelligenceを導入し、可能な限りSiriのリクエストをApp Intents経由でルーティングし始めました。Apple Intelligenceの「パーソナルコンテキスト」機能は、App Entities（App Intentsのデータ版)から読み取ります。¹⁰ iOS 27はこれをさらに推し進め、App Schemasを導入しました。これにより、いかなるトレーニング用フレーズも不要で、Siriがすでに理解している言葉であなたのエンティティを推論し、それらに対して動作できるようになります。こちらで取り上げています。
• iOS 26（2025年) はAppleのオンデバイスLLMであるFoundation Modelsフレームワークを導入しました。Foundation Modelsはアプリ内のツール呼び出しのために別個のToolプロトコルを公開します。App IntentsはApple Intelligenceにとってアプリ横断の正規サーフェスであり続け、Toolは直接のLLM呼び出し用のアプリ内サーフェスとなります。この2つの契約は並行して動作します。⁴

この契約はリリースのたびにスタックを上へと拡張してきました。当初、App Intentの利用者はShortcutsをタップする人でした。次にSiriの音声。次にSpotlight。次にApple Intelligenceの要約。そして今や、Apple IntelligenceのLLM搭載システムサーフェスが、ユーザーのリクエストに対して動作するためにそれらを使います。あなたが2026年に出荷するApp Intentのサーフェスは、iOS 27、28、29でApple Intelligenceが呼び出すことになるものなのです。

上記のパターンこそ、App IntentsはSiriの機能ではないと私が言うときに意味しているものです。これはApple AIファブリック全体のための、構造化ツール利用APIなのです。SwiftUIが最も重要なUI APIだったのは、それがvisionOS、watchOS 10以降、iOS 17以降でアプリを書く唯一の方法になったからです。App IntentsはAIの側で同じ軌跡を辿っています。すなわち、Appleがすべての賭けを置いているサーフェスなのです。

Foundation Modelsが出荷された今、何が変わるのか

Foundation Modelsは、すべてのApple Intelligence対応デバイスに搭載されるフレームワークです。ハードウェアの足切りは、Apple Intelligenceのリストと同じです。iPhone 15 Proおよび15 Pro Max（A17 Pro)、iPhone 16シリーズ、iPhone 17シリーズ、iPhone Air、iPhone 17e、M1以降を搭載したiPad Pro、M1以降を搭載したiPad Air、A17 Proを搭載したiPad mini、M2以降を搭載したVision Pro、そしてM1以降を搭載したMacです。注目すべきは、ベースモデルのiPhone 15 / 15 Plusが含まれていないことです。⁴¹²

これが意味するのは、Appleのシステムサーフェス（Siri、Spotlight、Apple Intelligence）があなたのアプリを呼び出すのであれば、それらはApp IntentsとApp Entitiesを経由して呼び出すということです。システムAIファブリック内のサードパーティアプリ向けにsetSystemPrompt(...)のようなAPIは存在しません。あるのはインテントのレジストリです。Foundation Modelsは、自前のオンデバイスLLM機能を望む開発者のために、並行するアプリ内のToolサーフェスを追加します。アプリ横断の契約（Apple IntelligenceとSiriがあなたのアプリを見つけるために使うもの）は、App Intentsを経由します。

アプリ開発者にとって、具体的な帰結が3つあります。

関連するApp Intentを持たないアプリは、そのカテゴリにおいてSiriの音声コマンドから到達できません。 Apple Intelligenceは「Hey Siri, log my water」のようなフレーズを、マッチするインテントを先に宣言したアプリへとルーティングします。私はWaterのインテントを2026年2月に出荷しました。フレームワークの方向性に対する私の読みでは、2027年にインテントを出荷する水分補給アプリは、ルーティングの重みがすでに早期参入者に蓄積された市場に足を踏み入れることになります。同じ論理が、買い物リスト、ワークアウト記録、カレンダー入力、写真検索にも当てはまります。私は、インテント宣言における先行者利益が複利的に効いていくと予想しています。 他のAppleプラットフォーム賭けのAPI（HealthKitカテゴリ、Spotlightのリッチ結果、Live Activitiesのトークン)でそうだったのと同じように。

Apple Intelligenceのパーソナライゼーションは、インテントだけでなくApp Entitiesから読み取ります。 AppEntityは「このアプリにはこの形のデータがある」と宣言します。ユーザーが「読書リストに最後に追加した本は何だっけ」と尋ねると、Apple Intelligenceはインストール済みのすべてのアプリにわたって、BookにマッチするあらゆるAppEntityを検索します。もしあなたのアプリに読書リストがあるのにBookEntityを宣言していなければ、あなたのデータはAppleのAIサーフェスからは見えません。Apple Intelligenceはあなたのデータを取得することも参照することもできないのです。¹¹

IntentResult & ProvidesDialogという戻り値の形が、ますます重要になっています。 Apple IntelligenceはSiri、Spotlight、Watchにわたって、インテントの結果をより長い応答へと組み合わせています。構造化されたダイアログなしに成功だけを返すperform()は、システムが一貫した返答に組み込むのがより困難になります。ProvidesDialogとProvidesViewはオプションの礼儀ではありません。あなたのアクションがユーザーのAIサーフェスにおける引用元（citation）になるための手段なのです。

私なら何を違う形で作るか

Waterでの11週間分の本番ログが、もっと早くやっておくべきだったことを3つ教えてくれます。

必要だと思うよりも多くのインテントを出荷すること。 私は1つだけ出荷しました。4つ出荷すべきでした。LogWaterIntent、CheckTodaysProgressIntent、AdjustGoalIntent、ShowHistoryIntentです。それぞれが、ユーザーが実際に試すSiriフレーズに対応します（「今日はどれくらい水を飲んだっけ」は私のアプリのデータではなく、Appleの汎用AIへとルーティングされていました)。出荷し損ねたインテント1つ1つが、Apple Intelligenceが私を迂回してルーティングするクエリなのです。

ダイアログ文字列はメールの本文ではありません。 私は最初からProvidesDialogを持っていましたが、初期のダイアログは散文でした。CarPlayやAirPodsを通じてそれを聞くユーザーには、短く、具体的で、事実を先頭に置いた構造が必要です。「8オンス記録しました。あと32オンスです」というように。Watchのサーフェスは特に、容赦なく文字列を切り詰めます。会話調のダイアログは、自信に満ちた事実ベースのダイアログよりも悪いユーザー体験です。私は4週目に自分のものを書き直しました。²

App Entitiesは私が思っていたよりも重要です。 私はWaterEntryというSwiftDataモデルを持っています。WaterEntryEntity: AppEntityと、その相棒であるWaterEntryQuery: EntityQueryも宣言すべきです。そうすればApple Intelligenceが「昨日いつ水を飲んだか見せて」に答えられます。最小限のブリッジはこうなります。¹¹

struct WaterEntryEntity: AppEntity {
    static var typeDisplayRepresentation: TypeDisplayRepresentation = "Water Entry"
    static var defaultQuery = WaterEntryQuery()
    var id: UUID
    var displayRepresentation: DisplayRepresentation {
        DisplayRepresentation(title: "\(amount) oz at \(timestamp.formatted())")
    }
    @Property(title: "Amount") var amount: Int
    @Property(title: "Timestamp") var timestamp: Date
}

struct WaterEntryQuery: EntityQuery {
    func entities(for identifiers: [UUID]) async throws -> [WaterEntryEntity] {
        // Fetch matching entries from SwiftData
    }
    func suggestedEntities() async throws -> [WaterEntryEntity] {
        // Recent entries Apple Intelligence can suggest
    }
}

2つの小さなSwift型に、SwiftDataのフェッチをつなぐグルーコードを加えるだけです。各エントリーをSpotlight内で個別に表示可能にする（ユーザーが「water」で検索したときに正しいエントリーにたどり着けるようにする)には、エンティティをIndexedEntityに準拠させ、書き込み時にインデックスの更新を提供（ドネート)します。これが、むき出しのAppEntityの公開を超えてAppleのSpotlightパイプラインが期待するものです。

同じ形は私の他のアプリにも当てはまります。私の買い物リストアプリであるGet Bananasは、すでに@Attribute(.unique) var id: UUID、name、amount、section、isCheckedに加え、iCloud Drive同期用のlastModifiedフィールドを持つSwiftDataの@Model ShoppingItemを備えています。¹³ それをShoppingItemEntity: AppEntityとしてラップし、いくつかのインテント（AddShoppingItem、CheckOffItem、ShowList）を出荷すれば、Get Bananasがすでに.mcpbのMCPサーバーを通じてClaude Desktopに公開しているのと同じ永続化レイヤーを、Apple Intelligenceにも公開できます。¹⁴ 2つのLLMエコシステム、2つの異なる契約、同じ買い物リストです。これが、1つの出荷済みアプリとしての並行契約テーゼなのです。 SwiftDataモデルがデータ、App IntentsがAppleの契約、MCPがAnthropicの契約であり、両方のサーフェスが同じ信頼できる単一の情報源（source of truth)に対して動作します。

App Intentを出荷すべきでないとき

拒否することも設計の一部です。

もしあなたのアプリが純粋に消費駆動型（ユーザーの写真を読み込む、ニュースを表示する、音声を再生する）で、変更可能なユーザー状態を持たないのであれば、App Intentsには公開すべきものが何もないかもしれません。AppleのフレームワークはOpenIntent（あるコンテキストでアプリを開くだけ）をサポートしていますが、唯一の有用なアクションが「アプリを開く」だけなら、そのインテントはオーバーヘッドです。持っているという事実のためだけに出荷してはいけません。

もしそのアクションが、抽象化するのが難しいUIのアフォーダンス（複雑な多段階のキャンバスツール、3D編集アプリ)に依存するなら、インテントが必要とするparameterSummaryは、誰も実際には口にしない曖昧な疑似自然言語へと劣化します。Siriのフレーズ「ぼかしツールを強度7で写真を編集して」は技術的には可能ですが、それを口にする人間はいません。そのインテントのサーフェスは、見返りのない税金になります。

正しいルールはこうです。App Intentがその維持コストに見合うのは、そのアクションを引き起こす、ユーザーが自然に言うであろう文が存在するときです。「8オンスの水を記録して」はその文です。「レイヤー3にシグマ2.4のガウシアンぼかしを適用して」はそうではありません。もしあなたのアプリのアクションが後者のパターンに集まっているなら、インテントはあなたのコンバージョンのレバーにはなりません。

締めくくりの見解

3年間、Appleは「iOSのシステムAIファブリックはApp Intentsを経由する」とシグナルを送り続けてきました。WWDC 2024はApple Intelligenceのルーティングをそれらを経由させる形で追加しました。WWDC 2025はFoundation Modelsを別個のアプリ内ツール呼び出しサーフェスとして並列に追加し、App IntentsをSiri / Spotlight / Apple Intelligenceが使い続けるアプリ横断の契約として残しました。すべてのシグナルが同じ方向を指しています。すなわち、型付きで宣言的なApp Intentが、サードパーティアプリが今やシステムと結ぶ契約であるということです。

ほとんどのiOSアプリは、いまだにApp IntentsをSiri Shortcutsとして扱っています。時間があれば出荷する機能、というわけです。私の読みでは、その捉え方はまずい形で古びていくでしょう。Apple Intelligenceのシステムサーフェスが拡張していくにつれ（今日すでにSiri、Spotlight、Shortcuts、Apple Intelligenceの要約を経由しています)、インテントを宣言していないアプリは、ルーティンググラフの外に自分がいることに気づく可能性が高いのです。私がAppleの他のプラットフォーム賭けを見てきた経験では、先行者のサーフェスは複利的に効いていきます。

Waterは11週間にわたってLogWaterIntentを出荷してきました。App Intentを出荷するコード量は、1つのファイルに収まるほど小さいものです。それを出荷しないコストは、Apple Intelligenceのリリースごとに膨らんでいきます。

もしあなたが2026年にiOSアプリを出荷していて、App Intentを少なくとも1つも宣言していないのなら、あなたのロードマップには抜け落ちた項目があります。追加しましょう。

FAQ

iOS開発におけるApp Intentとは何ですか?

App Intentとは、あなたのアプリのアクションの1つをAppleのシステムAIサーフェスに公開する、型付きで宣言的なSwiftの構造体です。@Parameterを介してパラメータを、parameterSummaryを介して自然言語のサマリーを、そして処理を実行して構造化された結果を返す非同期のperform()本体を宣言します。AppleのSiri、Spotlight、Shortcuts、Apple Intelligenceがそれを呼び出せます。Foundation Models（AppleのオンデバイスLLM)は、直接のアプリ内ツール呼び出しのために別個のToolプロトコルを使います。

App Intentsは、古いINIntentとどう違うのですか?

App Intents（iOS 16、2022年に導入)は、Appleの主要なインテントフレームワークとしてINIntentを置き換えました。この新しいフレームワークは完全にSwiftネイティブで、@Parameterのようなプロパティラッパーを使い、AppEntityを介した型安全なエンティティクエリをサポートし、Siri、Spotlight、Shortcuts、Apple Intelligenceが呼び出すサーフェスです。古いINIntentは依然としてサポートされていますが、新たな機能開発は受けていません。

App Intentを出荷するにはiOS 26が必要ですか?

いいえ。App IntentsはiOS 16以降で利用できます。iOS 26はFoundation Modelsフレームワークを並列に追加しますが、App Intentの宣言そのものはiOS 16以降で動作します。上記のサンプルコードはSwiftData（iOS 17以降)を使っているため、デプロイメントターゲットはあなたのperform()本体が何をインポートするかに依存します。むき出しのApp IntentsはiOS 16まで遡って動作し、SwiftDataに支えられたものはiOS 17が必要です。

App IntentとApp Entityの違いは何ですか?

App Intentはアクション（動詞)です。App Entityはあなたのアプリが知っているデータ（名詞)です。LogWaterIntentはインテントです。WaterEntryがクエリ可能な型になったものがエンティティです。Apple Intelligenceは両方を使います。アクションを起こすためにインテントを、応答内でデータを取得・参照するためにエンティティを使うのです。

App IntentsはFoundation Modelsのツール呼び出しとどう関係しますか?

Foundation Modelsは、直接のアプリ内LLMツール呼び出しのために独自のToolプロトコルを公開します。App Intentsは、Apple Intelligence、Siri、Spotlightが呼び出す正規のアプリ横断サーフェスであり続けます。方向性は同じ（型付きで宣言的なツール利用)で、契約が2つ並行している形です。システムのAIサーフェスから到達可能になりたいアプリはApp Intentsを出荷し、カスタムツールで自前のオンデバイスLLMを呼び出したいアプリはToolへの準拠を出荷します。多くのアプリは両方を出荷することになるでしょう。

App Intentsは機能ではありません。契約です。インテントを最初に出荷したアプリがそのサーフェスを獲得し、後から出荷したアプリはそのサーフェスがすでに別の場所へとルーティングされていることに気づきます。11週間前、私はWaterに1つ出荷しました。複利はすでに効き始めています。

Apple Ecosystemシリーズからのその他の記事

このエッセイは入り口です。残りの4本が、アーキテクチャスタックの残りをカバーします。

• Two Agent Ecosystems, One Shopping List：Get Bananasが、iCloud Drive内の1つのJSONファイルを通じて、同じデータをApple Intelligence（App Intents)とClaude Desktop（MCP)の両方にどう公開しているか。
• Liquid Glass in SwiftUI: Three Patterns From Shipping Return：iOS 26のビジュアルレイヤーの本番パターン。
• Five Apple Platforms, Three Shared Files：マルチプラットフォーム出荷戦略、コードを共有すべきときとターゲットを分岐すべきとき。
• HealthKit + SwiftUI on iOS 26：認可フロー、サンプルタイプ、そしてユーザーをあなたのアプリから締め出してしまう罠という、データソースのレイヤー。

または、フルハブに直接飛んでください：Apple Ecosystemシリーズ。AIエージェントを伴うiOSのより広い文脈については、iOS Agent Development guideをご覧ください。

References