Writing Tools API：アプリがApple IntelligenceのWriting Toolsレイヤーに接続する仕組み

Apple Intelligenceの文章作成レイヤーであるWriting Toolsは、Apple Intelligenceが有効化されたiOS 18以降のすべてのデバイスに搭載されています。ユーザーがテキストを選択してWriting Toolsメニューをタップすると、校正、リライト（フレンドリー、プロフェッショナル、簡潔）、要約、リストおよびテーブル生成、そしてiOS 18.2以降は生成的な文章作成までもが利用できます¹。この機能は特定のアプリではなくシステムレイヤーに存在しており、ユーザーはすべてのテキスト入力で動作することを期待しています。

UITextView、NSTextView、WKWebViewを使用しているアプリは、テキストビューがTextKit 2上で動作していれば、コードを書くことなく統合が完了します²。カスタムテキストエンジンを持つアプリでは、テキストストレージとレンダリングをWriting Toolsの体験に接続するためにUIWritingToolsCoordinator APIが必要となります。本稿ではAppleのドキュメントを基にAPIの概観を整理し、3つの導入ティアを示し、オプトアウトすべき場面（生成的なリライトを受け入れるべきでないテキスト入力もあるため）について解説します。

TL;DR

• TextKit 2上の標準テキストビュー（UITextView、NSTextView、WKWebView）は、アニメーション付きインラインリライトを含む完全な体験を、コードを書かずに利用できます²。
• カスタムテキストビューはUITextInteractionを採用することで、追加のコードなしにコールアウトやコンテキストメニュー統合が得られます。完全なインライン統合にはUIWritingToolsCoordinator APIが必要です³。
• UIWritingToolsBehaviorは体験ティアを制御する単一の列挙型プロパティであり、.complete、.limited、.noneの値を取ります⁴。.default値はシステムが実行時に上記3つのいずれかに解決するリクエストであり、4つ目のティアではありません。機密性の高いテキスト（パスワード、ソースコードエディター、リライトされたくないチャットフィールド）には.noneを設定します。
• allowedWritingToolsResultOptionsを使えば、アプリが受け入れる出力形式（プレーンテキスト、リッチテキスト、リスト、テーブル、iOS 26では.presentationIntent）を宣言でき、Writing Toolsはアプリがレンダリングできないコンテンツを返さないようになります⁵。
• エージェントワークフローとの関連：Writing ToolsはApp IntentsやFoundation Modelsと同じくApple Intelligenceの表面ですが、アクション層ではなくテキスト入力層で動作します。

Writing Toolsが実際に行うこと

iOS 18以降のWriting Toolsメニューは、選択されたテキストに対する一連の操作を提供します。Appleの開発者向けドキュメントとWWDC 2024での紹介に基づく現行の公開セットは以下の通りです⁶。

校正（Proofread）。 文法、スペル、句読点、語選択を修正します。ユーザーは差分を確認し、受け入れ・却下・順次確認できます。

リライト（Rewrite）。 3つのプリセットトーン（フレンドリー、プロフェッショナル、簡潔）に加え、「変更内容を記述する」カスタムプロンプトが利用できます。モデルは選択したテキストを指定されたトーンでリライトします。

要約（Summarize）。 長いテキストを短くまとめます。バリエーションには「サマリー」「要点」「リスト」「テーブル」があり、ユーザーが形式を選択します。

作成（Compose）。 プロンプトからの生成的な文章作成（iOS 18.2以降）。ユーザーが望むものを記述すると、モデルは既存のテキストをリライトするのではなく、新しいテキストを生成します。

Writing Toolsを動かすモデルは、対応ハードウェア上ではAppleのオンデバイス基盤モデルであり、より大きなリクエストにはプライベートクラウドへのフォールバックが用意されています¹。ユーザーのテキストが第三者に渡ることは決してありません。プライバシー設計が価値提案の一部となっているのです。

3つの導入ティア

アプリは、Writing Tools統合の必要度に応じて3つのカテゴリのいずれかに分類されます。

ティア1：標準テキストビュー（コード不要）

UITextView、NSTextView、WKWebViewをテキスト入力に使用しているアプリは、テキストビューがTextKit 2を使用していれば、コードを書かずにWriting Toolsを利用できます²。メニュー、インラインリライトのUI、アニメーション、校正のインラインハイライトはすべてシステムが処理します。アプリの仕事は標準テキストビューを使用することだけです。

let textView = UITextView()
textView.text = "Original content."
textView.isEditable = true
// Writing Tools just works.

TextKit 2の要件が重要なのは、TextKit 1がインラインリライトのアニメーションをサポートしない異なるレイアウトアーキテクチャで動作するためです。iOS 18以降を対象とする新しいアプリはTextKit 2をデフォルトとすべきであり、レガシーアプリには移行ステップが必要になる場合があります。UITextViewは、Interface Builderまたはモダンなイニシャライザーで初期化された場合、iOS 16以降ではTextKit 2をデフォルトとします。

ティア2：UITextInteractionによるカスタムテキストビュー（コールアウトのみ）

カスタムテキストビューを持つアプリは、UITextInteractionを採用することで、追加のコードなしにコールアウトバーとコンテキストメニューでWriting Toolsを利用できます⁷。ユーザーはWriting Toolsを呼び出し、校正・リライト・要約のパネル形式インターフェースを表示し、結果を受け入れまたは却下できます。結果は標準のペースト／置換フローを通じてアプリに渡されます。

統合は部分的なもので、アプリはインラインアニメーションや校正のインラインハイライトは得られません。それらには完全なコーディネーターが必要です。カスタムテキストビューを持つほとんどのアプリでは、UITextInteractionの採用で十分です。

ティア3：UIWritingToolsCoordinator（完全なインライン体験）

カスタムテキストストレージで完全なWriting Tools体験を望むアプリは、UIWritingToolsCoordinator（macOSではNSWritingToolsCoordinator）を採用します³。コーディネーターは、Writing Toolsとアプリ間の双方向の対話を管理します。

• アプリはテキストコンテキスト（現在の選択を表すNSAttributedStringと、オプションで周囲の段落）をコーディネーターに提供します。
• コーディネーターはパネルUIとインラインアニメーションを管理します。
• コーディネーターはデリゲートを通じてコールバックし、アプリのテキストストレージにテキスト変更を挿入、置換、アニメーション表示します。

iOS 26 SDKヘッダーで検証されたUIWritingToolsCoordinator.Delegateの主要なデリゲートメソッドは以下の通りです³。

• writingToolsCoordinator(_:requestsContextsForScope:completion:)。インテークメソッドです。Writing Toolsは指定されたスコープ内で関連するテキストコンテキスト（それぞれNSAttributedStringと選択範囲）をアプリに要求します。アプリはテキストストレージからコンテキストを構築し、返却します。
• writingToolsCoordinator(_:replaceRange:inContext:proposedText:reason:animationParameters:completion:)。テキスト変更の主役メソッドです。Writing Toolsはコンテキスト内の範囲に対して新しいテキストを提案し、アプリは変更をストレージに適用して確認します。
• writingToolsCoordinator(_:finishTextAnimation:forRange:inContext:completion:)。ある範囲に対するテキストアニメーション（オリジナルとリライト後のテキスト間のモーフィング）が完了したときに呼ばれます。セッション終了の信号ではありません。
• writingToolsCoordinator(_:willChangeToState:completion:)。セッションライフサイクルの信号です。コーディネーターは状態（idle、interactive、noninteractiveなど）を遷移し、各遷移の前にデリゲートに通知します。アプリはここで「セッション開始」と「セッション終了」に応答します。

コーディネーターAPIは、シリアライズされたテキストエンジン（TextKitスタイル）、ドキュメント形式のエディター、部分的な統合を望むコードエディター向けに設計されています。WWDC 2025のセッション「Dive deeper into Writing Tools」⁸では、複数段落・複数スタイルのケースが解説されています。なお、UIWritingToolsCoordinatorは公開APIとしてはiOS 18.2で初めて出荷されたものであり、iOS 26はそれを導入したのではなく深化させたものとなります。

振る舞いプロパティ：UIWritingToolsBehavior

最も重要なオプトイン／オプトアウト制御は、UITextView、UITextField、およびUITextInputTraitsに準拠する任意のビューにあるwritingToolsBehaviorプロパティです⁴。

textView.writingToolsBehavior = .complete   // full inline experience
textView.writingToolsBehavior = .limited    // panel-only (no inline rewrite)
textView.writingToolsBehavior = .none       // disabled entirely
textView.writingToolsBehavior = .default    // request system default

3つの値は実際の体験ティアを表し、.defaultはシステムがテキスト入力の特性に基づいて他の3つのいずれかに解決するリクエストです。

• .complete。 インラインリライトのアニメーション、インライン校正ハイライト、パネルを含む完全なWriting Tools体験です。長文テキストエディター（メール作成画面、メモ、ドキュメントエディター）に最適です。
• .limited。 パネルのみの体験です。ユーザーはメニューでWriting Toolsを利用できますが、リライトはインラインではなくパネル内で行われます。インラインアニメーションが過剰に感じられる短いテキストフィールドに最適です。
• .none。 このテキスト入力に対してWriting Toolsは無効化されます。機密性の高いコンテンツに使用します。
• .default。 ティアではなくリクエストです。ヘッダーには解決後の値が常に.none、.limited、.completeのいずれかであると記載されており、読み取り専用のbehaviorプロパティが.defaultを返すことはありません。明示的にオーバーライドする理由がない限り、ほとんどのアプリではプロパティを.defaultのままにしておくべきです。

オプトアウトすべき場面

.noneが正解となるテキスト入力には3つのカテゴリがあります。

パスワードと機密性の高い認証情報。 パスワードフィールドが「これをフレンドリーなトーンでリライト」というオプションを提供すべきではありません。ユーザーは変換されてはならない文字通りのテキストを入力しているのです。AppleのUITextFieldはisSecureTextEntry = trueの場合、デフォルトでWriting Toolsを無効化しますが、明示的な.noneは念には念を入れた指定となります。

ソースコードエディター。 SwiftUIコードエディターや技術的なコンテンツ用のMarkdownエディターは、選択されたコードを「プロフェッショナル」なトーンでリライトするよう求められても改善されることはありません。Writing Toolsのリライトパスは構文構造ではなく自然言語向けに調整されています。コンテンツが自然言語ではないテキストビューには.noneを設定します。

リライトが意図を変えてしまうチャットフィールド。 メッセージングアプリや、ユーザーの正確な言葉が（トーン、声、説明責任のために）重要となるコメントフィールドでは、校正は維持しつつリライトは省略したい場合があります。Writing Toolsの現行APIはアクション単位でのゲーティングを許可していません。.none値は体験全体を無効化します。リライトが時に適切ではあるもののインラインのデフォルトとすべきでないフィールドでは、.limited（パネルのみで、ユーザーが意図的に呼び出す必要がある）が現実的な選択です。

allowedWritingToolsResultOptionsはアプリがレンダリングできるものを宣言する

より繊細な制御としてUITextInputTraits.allowedWritingToolsResultOptions（UITextView.allowedWritingToolsResultOptionsとしても公開）があります⁵。このプロパティはUIWritingToolsResultOptionsオプションセットで、アプリのテキストビューがレンダリングできるコンテンツ形式を宣言します。

• .plainText。テキストビューはプレーンテキスト（書式属性なし）をサポートします。
• .richText。書式付きテキスト（太字、斜体など）をサポートします。
• .list。リストレンダリング（箇条書き、番号付き）をサポートします。
• .table。テーブルレンダリングをサポートします。
• .presentationIntent（iOS 26以降）。FoundationフレームワークのPresentationIntent型を使用した、リッチな意味的インテントマークアップ（見出し、引用ブロック、コードブロック）をサポートします。これはプレーンなリッチテキストよりも豊かな表現が可能です。

設定された場合、Writing Toolsはアプリが受け入れる形式に出力を制限します。.plainTextのみを宣言したプレーンテキストエディターは「これをテーブルにする」提案を受け取りません。.richTextと.listを宣言しつつ.tableを宣言しないリッチテキストエディターは、リスト出力は受け取りますがテーブル出力は受け取りません。

デフォルト値は.defaultで、システムがテキストビューの特性に基づいて選択します。自動検出が誤った形式を生成する場合（リッチテキストをレンダリングできるが、アプリのデータモデルがプレーンしか保存しないテキストビューなど）には、プロパティを明示的に設定します。

出力の届き先

ティア1のアプリ（標準テキストビュー）では、出力は標準テキストビューの仕組みを通じて選択範囲をインラインで置換します。アプリのコードは関与しません。

ティア2のアプリ（UITextInteractionを持つカスタムビュー）では、出力は標準のペーストフローを通じて到達します。テキストビューのUITextInputプロトコル実装が変更を処理します。UITextInputを正しく実装しているアプリは、UITextInteractionを追加するだけで「無料で」統合を得られます。

ティア3のアプリ（完全なコーディネーター）では、出力はデリゲートのreplaceRange:メソッドを通じて到達します。アプリは変更をテキストストレージに適用し、新しいテキスト境界を完了ハンドラーで返し、コーディネーターが視覚的な遷移を処理します。アプリはテキストストレージの単一の真実の源（source of truth）であり続けます。

WWDC 2025のディープダイブで追加されたもの

WWDC 2025のセッション「Dive deeper into Writing Tools」⁸では、iOS 18 APIを以下の3つの軸で拡張しています。

複数段落のコンテキスト。 アプリはコーディネーターにより多くの周辺コンテキストを提供できるようになり、Writing Toolsは周囲の段落に依存する選択（例：意味が前段落に依存する文）に対して動作できるようになりました。

カスタムリライトプロンプト。 iOS 18.2のベータで導入された「変更内容を記述する」パスが完全に公開され、ユーザーのプロンプトをモデルに渡す前に検査または変換したいアプリ向けのデリゲートフックが提供されています。

混在コンテンツのより良い処理。 複数のスタイルにまたがる、または埋め込まれた画像を含むテキスト選択は、埋め込みコンテンツが不透明な範囲として保持された状態でコーディネーターを流れるようになりました。コーディネーターはインライン画像をリライトしようとはせず、それを保持しつつ周囲のテキストをリライトします。

これらの差分はiOS 18モデルの置き換えではなく拡張です。iOS 18 Writing Tools APIを採用したアプリは引き続き動作し、iOS 26では必要なアプリのために、より深い統合が解放されます。

エージェントワークフローとの接続

Writing Toolsは、サードパーティアプリが統合できる3つのApple Intelligence表面の1つです。

Writing Tools。 テキスト入力レイヤー。ユーザーがテキストを選択し、システムに変換を依頼すると、結果がインラインで返ってきます。アプリは整形されたテキストビューを公開し、（オプションで）コーディネーターを実装することで参加します。呼び出すのはユーザー、結果を受け取るのはアプリです。

App Intents。 アクションレイヤー。ユーザー（またはエージェント）はApple Intelligenceにアクションの実行を依頼し、システムはそのリクエストをアプリに登録されたインテントにルーティングします。アプリはAppIntent型、パラメータースキーマ、結果型を宣言することで参加します。詳しくは App IntentsはAppleのアプリへの新しいAPIで解説しています。

Foundation Models。 ランタイムLLMレイヤー。アプリはアプリ内生成のために、Foundation Modelsフレームワークを通じてオンデバイスLLMを直接呼び出します。詳しくは Foundation ModelsオンデバイスLLMで解説しています。

3つの表面は組み合わせ可能です。メモアプリは、Writing Tools（ユーザーの選択ベースのリライト用）、App Intents（「昨日のメモを要約」用）、Foundation Models（自動タグ付けなどのアプリ内生成機能用）を使い分けるかもしれません。各レイヤーは独自のユーザーメンタルモデルを持つ別個の統合となります。

App Intents対MCP Toolsの記事では、App Intents（Apple Intelligence）を通じてアクションを公開すべき場合と、MCPサーバー（汎用エージェント）を通じて公開すべき場合について解説しています。Writing Toolsはその問いの外側にあります。これはシステムレベルの表面であり、本クラスターのカバー範囲においてサードパーティエージェントの同等物を持ちません。

このパターンがiOS 26以降のアプリにとって意味するもの

要点は3つです。

1. 標準テキストビューとTextKit 2をデフォルトとする。 ほとんどのアプリにコーディネーターAPIは不要です。アプリのテキスト入力がUITextViewまたはWKWebViewであれば、Writing Toolsはコードなしで動作します。アプリがまだTextKit 1を使用している場合、作業はTextKit 2への移行となります。

2. 機密性の高い入力にはwritingToolsBehavior = .noneを意識的に設定する。 パスワード、コードエディター、正確なテキストフィールド。デフォルトは適切な動作を試みますが、明示的な設定はチームが説明できる擁護可能なプロダクト判断となります。

3. UIWritingToolsCoordinatorに手を伸ばすのは、アプリのテキストエンジンが本当にカスタムである場合のみ。 Markdownエディター、コードエディター、カスタムレンダリングを持つドキュメントアプリ、ターミナル形式のテキストビュー。コーディネーターは本格的なエンジニアリング投資です。ほとんどのカスタムビューにはティア2（UITextInteraction）で十分です。

Apple Ecosystemクラスターの全体像：型付きのApp Intents、MCPサーバー、ルーティングの問い、Foundation Models、ランタイムとツーリングLLMの区別、3つの表面、単一の真実の源パターン、2つのMCPサーバー、Apple開発のためのフック、Live Activities、watchOSランタイム、SwiftUI内部、RealityKitの空間メンタルモデル、SwiftDataスキーマの規律、Liquid Glassパターン、マルチプラットフォーム出荷、プラットフォームマトリクス、Visionフレームワーク、Symbol Effects、Core ML推論、書かないと決めていること。ハブは Apple Ecosystem Seriesにあります。AIエージェントを使ったiOS開発のより広い文脈については、iOS Agent Developmentガイドをご覧ください。

FAQ

アプリでWriting ToolsをテストするにはApple Intelligenceが必要ですか？

完全なユーザー体験をテストするには必要です。ユーザー向けのWriting Toolsメニューは、Apple Intelligenceが有効化されたデバイス（iPhone 15 Pro以降、M1 Mac以降、iOS 18以降／macOS 15以降）でのみ表示されます。開発目的では、テキストビューがisWritingToolsActiveを公開しデリゲートメソッドが正しく接続されているかを確認することで、iOS 18以降の任意のシミュレーターまたはデバイスでAPI統合をテストできます。Apple Intelligenceが利用できない環境では、システムメニューは表示されないだけです。

iOS 18以降のアプリでWriting Toolsについて何もしなかった場合どうなりますか？

標準テキストビュー（UITextView、WKWebView）の場合、Writing Toolsは自動的に表示されます。UITextInteractionを持たないカスタムテキストビューの場合、Writing Toolsはメニューに現れず、ユーザーはアプリ内のテキストに対して呼び出せません。Writing Toolsが不適切なビュー（パスワードフィールド、コードエディター）では何もしないことが擁護可能なデフォルトとなります。一般的なテキスト入力では、何もしないことはユーザーが探すシステム機能を欠くことを意味します。

.completeと.limitedの違いは何ですか？

.completeはWriting Toolsのリライトをインラインで実行し、オリジナルのテキストをリライト後のテキストにモーフィングするアニメーションと、インライン校正ハイライトを伴います。.limitedはWriting ToolsをパネルUIで実行します。ユーザーはリライトを別の表面で確認し、適用するかどうかを決めます。インラインアニメーションが編集フローを強化する長文テキストエディターには.completeを、パネルが適切に感じられる短いテキストフィールドには.limitedを使用してください。

Writing Toolsのプロンプトやモデルの動作をカスタマイズできますか？

モデルとプロンプトはシステム制御です。アプリはWriting Toolsメニューにカスタムリライト動作を注入できません。アプリ固有の生成的な文章作成機能には、Foundation Modelsフレームワークを直接使用し（Foundation ModelsオンデバイスLLMで解説）、独自のUIで機能を提供してください。

Writing Toolsは混在選択（テキスト＋画像）をどう扱いますか？

WWDC 2025の「Dive deeper into Writing Tools」⁸によると、埋め込みコンテンツ（画像、添付ファイル）を含む混在選択は、埋め込みコンテンツが不透明な範囲として保持された状態でコーディネーターを流れます。Writing Toolsは周囲のテキストをリライトしますが、埋め込みコンテンツの変換は試みません。コーディネーターを使用するアプリでは、デリゲートは埋め込みコンテンツの範囲が変更なしとマークされた提案テキストペイロードを受け取ります。

References