OpenAI の UX‑guidelines: いつ App を表示し、どうすれば会話を「乗っ取らない」か

1. Chat‑first: ChatGPT はまずチャット、アプリはその次

最初の6モジュールで、UI や MCP からデバッグやデプロイまで、アプリのあらゆる側面を扱ってきました。ここからは同じ要素をもう一段深く見ていきます。もちろん、そんなに単純ではありませんよね？

まずは UX、より正確には公式の UI 要件と UX ガイドラインから。ストアのレビューを通したいですよね？ では一番おもしろいところから始めましょう。SPA/Next.js に慣れたフロントエンド開発者に必要なマインドセットの転換です。 ChatGPT は何よりも対話インターフェースであり、App はその会話の中のゲストです。逆ではありません。

OpenAI のガイドラインではこう述べられています。アプリはユーザーができることを会話の流れを壊さずに拡張します。ウィジェットは新しいブラウザタブではなく、テキストだけでは厳しくなってきた場面にそっと差し込む補助的な挿入物です。

役割分担で覚えるのがいちばん簡単です。

GPT と App の役割

ChatGPT の中には 2 人の「登場人物」がいます。

GPT は主たる語り手であり続けます。今から何が起きるか、なぜ App を提案するのか、ボタンの意味は何か、そしてウィジェットの結果を言葉で要約します。一方 App はビジュアルとアクションに集中します（選択、フィルタ設定、ウィザードのステップ進行など）。

とても重要なルールがひとつあります。何度でも唱えてください。 重要な意思決定は、ユーザーが UI をクリックしていても、GPT のテキスト応答で明示的に言語化すること。ユーザーにはウィジェットのすべての文言を読む義務はありません。主要な結果や影響（例:「注文を確定しました」「選択されたパラメータはこれです」）はチャットで伝えるべきです。

2. いつ App が本当に必要か: 表示の基準

技術的には、どのメッセージでもウィジェットを呼び出せます。しかし UX 的には、これは input に文字を 1 つ入力するたびにフルスクリーンダイアログを開くようなものです。動くことは動きますが、快適ではありません。

OpenAI と Apps SDK はシンプルな原則を勧めています。App は、テキストだけよりも考えるのがラクになるときにふさわしい。

構造があり再現的なシナリオのリクエスト

App は、ユーザーのリクエストがすでに構造を示唆しているときに特に有効です。

• 「同僚向けに $50 以内でギフト候補を 5 つ挙げて」。
• 「この 3 つの料金プランを比較して」。
• 「東京を 3 日で回るルートを作成して」。
• 「今週の自分のタスク一覧を表示して、優先度付けを手伝って」。

これらはいずれも、操作すべき明確なエンティティ（ギフト、料金、旅程の日、タスク）があり、選ぶ・絞る・比較する・確定するというステップがあります。カード、チェックボックス、フィルタのある UI はここで正当化され、むしろ救いになります。

GiftGenius の例

おなじみの GiftGenius を使いましょう。典型的なリクエストは次のとおりです。

異なる予算と興味を持つ 10 人の結婚式ゲストに合うギフトを選びたい。

GPT がテキストだけで 10 個のリストを列挙することはできますが、読む側はつらいでしょう。ずっと心地よいのは次のような形です。

• ゲスト、予算、興味のテーブルを見せる。
• 「安い/高い」でフィルタできるようにする。
• 各ゲストに対するカードセットを表示する。

ここでは App はほぼ必須です。エンティティとパラメータが多すぎて、テキストだけで保持するのは難しいからです。

対照的に、次のような場合は:

兄に 5000 ₽ で何を贈ればいい？

これは 1 ステップの小さな質問です。GPT は 3〜5 個のアイデアをテキストで返せます。ユーザーが「趣味や年齢でフィルタできるように候補を見せて」と頼んだときに初めて、穏やかに App に移行すれば十分です。

ミニヒューリスティック

次のような簡単な表を頭に置いておくと便利です。

inline と fullscreen の詳細は次回以降に扱いますが、今の段階でもはっきりしています。App は構造化された多段タスクのための道具であって、「なんだか憂うつ、どうしたらいい？」のような毎回の雑談用ではありません。

3. いつ App が邪魔になるか: 「話したい」モードと熟考

どんな場合に App が会話の構造化に役立つか見てきましたが、逆に UI が邪魔になる状況もあります。

「UI を描こう」という話ばかりしていると、「あ、ユーザーが何か聞いた——もうウィジェットを起動しよう」という反射が生まれがちです。これはストアのレビューで UX 減点を食らうポイントです。

App がしばしば有害になるリクエストのクラスがあります。

1. ユーザーが「話したい」モードにいる。 哲学的な考察、個人的な質問、キャリアの悩み、セラピー的な対話などです。こうしたシナリオでは、ユーザーはテキストでの会話、確認質問、時には共感を期待します。ここでカードやフィルタを差し込むとスパムバナーのように感じられます。
2. サービスの導入的な質問。 「GiftGenius って何ができるの？」と書いてきた人は、まず概要を望んでいます。いきなり UI ではありません。GPT はまず App の目的を簡潔に説明し、例をいくつか示し、その後で控えめにウィジェットを試す提案をするのがよいでしょう。
3. 一般的・理論的な質問。 「内向的な人に贈るギフトはどう選ぶ？」や「店舗のロイヤルティシステムはどう機能する？」といったものは、トランザクションではなく学習のシナリオです。GPT はテキストで良い回答ができますし、最後に「よければ GiftGenius を開いて具体的な候補をいくつか選びましょう」と控えめに加える程度で十分です。

UI が新しい価値を生まず、テキストを繰り返すだけの場面では、チャットにとどまるのが良いでしょう。これこそが UX の大家がよく言う「ユーザーの意図への敬意」です。

4. App の提案方法: auto‑launch と「控えめな引き継ぎ」

App が適切だと確信していても、「どう起動するか」という問題は残ります。粗いやり方は、予告なくいきなりフルスクリーンのアプリを開くこと。正しいやり方は、まず GPT が言葉で説明し、同意を取るか少なくとも通知することです。

UX ドキュメントでは ChatGPT Apps に 2 つのパターンが示されています。auto‑launch と suggestion（humble handoff） です。

Auto‑launch: ユーザーが明示的に頼んだとき

ユーザーの意図が明確なときは auto‑launch が適切です。

GiftGenius を起動して。
GiftGenius の設定を開いて。
GiftGenius で自分のギフトカートを見せて。

ルールはシンプルです。

1. GPT が「GiftGenius を開きます…」のように短く書く。
2. モデルはすぐにツール／ウィジェットを呼び出す。

会話は次のようになります。

ユーザー: GiftGenius を起動して。友だちに贈るギフトを選びたい。
GPT: ギフト選びのために GiftGenius を開きます。
[GiftGenius のウィジェットが inline または fullscreen で表示される]

ユーザー自身が「開いて」と依頼しているので、余計な確認なしの自動起動が正当化されます。

Suggestion（humble handoff）: 意図が不明瞭なとき

多くの場合、ユーザーはあなたのアプリの存在を知りません。例えば次のように書きます。

同僚の誕生日に何か考えたい。予算は少なめ。

ここでの正しいパターンは次のとおりです。

1. GPT がリクエストを分析し、App が役立つと判断する。
2. GPT が 1〜2 個の確認質問をするか、まずはテキストで App を提案する。
3. 同意や明示的な合図があって初めてウィジェットを起動する。

例:

ユーザー: 同僚の誕生日に何か考えたい。予算は少なめ。
GPT: 私がそのままアイデアを提案することも、GiftGenius を開いて予算や興味で候補を絞り込むこともできます。テキストでの助言とアプリ、どちらがよいですか？
ユーザー: アプリで。
GPT: ギフト候補を選ぶために GiftGenius を開きます。
[ウィジェットが表示される]

このアプローチは、主導権はあくまでユーザーにあることを強調します。App は選択肢であって、押しつけのバナーではありません。これは UX ガイドラインの「Respect user’s intent」という原則とよく整合します。

ミニ例: TypeScript による「意図分類器」

あなたのバックエンド側で、ユーザーのリクエストをざっくり分類しているとします（GPT 本体とは別の補助ロジックです）。

// ユーザー意図の簡略化タイプ
type UserIntent = 'chat' | 'ask_gift_advice' | 'open_app';

// App に使いたいトリガー
type AppTrigger = 'auto' | 'suggest' | 'avoid';

function decideAppTrigger(intent: UserIntent): AppTrigger {
  if (intent === 'open_app') return 'auto';      // 「GiftGenius を起動して」のような明示
  if (intent === 'ask_gift_advice') return 'suggest'; // 曖昧な依頼
  return 'avoid';                                // 通常のチャット（App なし）
}

このロジック自体はウィジェットを呼び出しません。UX アプローチを形式化するためのものです。あとはこれらのルールを system‑prompt と App の説明に反映し、モデルが同じ流儀で振る舞うようにします。

5. 会話を「乗っ取らない」ために: よいパターン／悪いパターン

OpenAI のドキュメントや ChatGPT Apps の UX 記事では、「会話を奪わない」ことが明確に示されています。つまり、チャットをあなたの UI の販促チャンネルにしないということです。

アンチパターン

もっとも厄介なのは 「サプライズ・ウィジェット」です。ユーザーが深い対話をしている最中に、突然フルスクリーンのアプリが画面を占有する——そんなものは望んでいません。文脈もコントロール感も失われます。

もうひとつのよくある過ちは、App を広告として使うことです。たとえば理論的な質問に対し、モデルが「まずは当社のスゴいウィジェットを開きます。全部そこに書いてあります」と答え、UI の半分がマーケ文句なケース。公式ガイドラインではこうしたシナリオを「poor use cases」と名指ししています。

3 つ目のアンチパターンは、UI とテキストの不要な頻繁切り替えです。小さな確認のたびに App を開閉すると、会話は点滅するイルミネーションのよう。特にモバイルではすぐに疲れてしまいます。

ベストプラクティス

それでも App を開くシナリオでは、次の 3 つのシンプルなルールに従ってください。

第一に、事前に知らせること。GPT に「これから GiftGenius を開いて、カード形式で候補をお見せします」のように明示させましょう。たった 1〜2 行ですが、遷移の印象が大きく変わります。

第二に、UI で何をすればよいか説明すること。新しいインターフェースに慣れていないユーザーもいます。GPT が「下にギフトのカードが表示されます。ページ送りができ、どの候補でも『詳細を見る』を押せます」のように補足できます。ウィジェットに「さらに N 件を表示」や独特なフィルタなどがあるなら、言葉で説明しておくと良いでしょう。

第三に、結果をテキストで要約すること。App が処理（選ぶ、計算する、送信する）を行った後、GPT は「ギフト候補を 3 つ選びました。最初の 2 つは $50 以内、3 つ目はやや高いですが配送が早いです。さらに絞り込みますか？」のように短く説明します。特にモバイルや音声シナリオでは重要です。UI を見ていなくても、テキストの要約は耳に入ります。

6. UX を制御するうえでの system‑prompt と App 説明の役割

すでに見たように、system‑prompt は App の「人格」やツールの使い方を規定します。ここにさらにUX ルールを加えましょう。App をいつ提案するか、どうアナウンスするか、いつ控えるか、です。

system‑prompt に書くべきこと

GiftGenius の system‑prompt には「対話と UX」という節を含められます。ドキュメントや記事では、個別のルールとして構造化して書くことが推奨されています。

例（擬似コードだが実運用に近い）:

### 対話と UX

1. ユーザーがギフトの条件（対象者、予算、目的）を与えた場合、
   まず 1〜2 個の確認質問をテキストで行う。
2. 確認後に App GiftGenius を開く提案をする:
   "ギフト候補を表示するために GiftGenius を開けます。開きますか？"
3. ユーザーが明確に「GiftGenius を起動して」や「ギフト一覧を見せて」と言った場合、
   "GiftGenius を開きます..." と答え、追加の質問なしにすぐ App を呼び出す。
4. 理論や一般的な助言（例: "ギフトの選び方"）を求められた場合は、
   テキストで答え、ユーザーが求めるまで App を開かない。
5. ユーザーが「アプリを開かないで」や「テキストだけで」と言った場合、
   以降この対話では App を提案しない。
6. App の処理後は常に、結果をテキストで（簡潔に）要約する。

ここに chat‑first、ユーザーの拒否尊重、auto‑launch と suggest の違い、テキスト要約の必須化など、私たちの UX 原則が凝縮されています。

TypeScript の設定で自分を助ける方法

実プロジェクトでは、これらのルールの一部を構造化して保存しておくと便利です（後でプロンプトのテキストを手で探さなくて済みます）。例えば簡単な設定を用意できます。

// App の UX トリガー設定の仮の型
type AppUxRule = {
  intent: 'gift_selection' | 'theory' | 'open_app';
  trigger: 'auto' | 'suggest' | 'avoid';
  askConfirmation?: boolean;
};

export const giftGeniusUxRules: AppUxRule[] = [
  { intent: 'open_app', trigger: 'auto' },
  { intent: 'gift_selection', trigger: 'suggest', askConfirmation: true },
  { intent: 'theory', trigger: 'avoid' },
];

この設定自体をモデルが読むわけではありません。プロダクト／デザインの取り決めを 1 か所に集約し、あとで system‑prompt、App の説明、ドキュメントにきれいに反映するためのものです。

7. 例: GPT が GiftGenius をアナウンスし、会話を奪わない振る舞い

アプリとつなげてみましょう。ユーザーが初めてチャットに書いたとします。

同僚向けのギフトを探しています。だいたい 3000 ₽ まで。ボードゲームが好きです。

私たちの system‑prompt を踏まえた良い返答例:

了解です。まずは少し条件を確認して、アイデアを絞り込みましょう。

相手のだいたいの年齢と、形式的な贈り物か、親しい友人からの贈り物かを教えてください。

（お答えいただいたら、GiftGenius を開いてカード形式で候補を見られるようにできます。）

確認の後、GPT はこう書きます。

十分な情報がそろいました。

これから GiftGenius を開きます。カード形式でいくつかの候補をお見せし、詳細を確認したり、予算やゲームのタイプで絞り込んだりできます。

それから初めて App を起動します。「サプライズ」は一切ありません。すべて言葉で説明されています。

ウィジェット内の「App アナウンス」用の小さな React コンポーネント

コードの観点では、ウィジェットは呼ばれたらレンダリングするだけが普通です。でも、すでに開いているとしても、UI に「コンテキストを奪わない」哲学を織り込めます。

例えば GiftGenius の最初の画面を、とてもシンプルにできます。

// app/components/GiftGeniusIntro.tsx
export function GiftGeniusIntro() {
  return (
    <section style={{ padding: 16 }}>
      <h2 style={{ fontSize: 20, marginBottom: 8 }}>
        GiftGenius でギフトを選ぶ
      </h2>
      <p style={{ marginBottom: 12 }}>
        カード形式でいくつかの候補を表示します。気に入ったものを選べば、
        ChatGPT が長所・短所を説明します。
      </p>
      <p style={{ fontSize: 12, color: '#666' }}>
        いつでも通常のチャットに戻って、議論を続けられます。
      </p>
    </section>
  );
}

このコンポーネントは技術的に「強力な」ことはしませんが、UX 的には重要です。チャットは消えていないこと、GPT の役割が中心にあることをユーザーに思い出させます。

このイントロ画面から、ギフトのカード、ウィザードなどへ進みます。詳しくは次回の講義で扱います。

8. 実践と練習

ここまでで「chat‑first」「ユーザーの意図を尊重する」「auto‑launch と App 提案の違い」といった原則を整理しました。「いつ・どう App を見せるか」という発想を定着させるために、実際のリクエストを考え、App が必要な場面と不要な場面を分けてみましょう。宿題として小さな練習を 2 つ用意します。

まずは GiftGenius について、ユーザーのリクエストを 5〜7 個考えてください。それぞれに対して、正直にこう答えてください。

• ここですぐに App を開く提案をすべきか。
• App をオプションとして言及するだけにすべきか。
• あるいは回答を App とまったく結びつけないほうがよいか。

例:

1. 「妻への結婚記念日のギフト、予算は $1000 まで」——まずはテキストで 1〜2 個の確認質問、その後で App を開く提案。
2. 「ギフトをおしゃれに包装するには？」——純粋に理論的な質問なので、App なしでもよい。
3. 「GiftGenius を起動して。チーム全員分のギフトを選びたい」——明確な auto‑launch。

2 つ目の練習は、App 起動のアナウンステキストです。GPT がユーザーに App への遷移を説明するための短い 1〜2 フレーズを書いてみましょう。よりフォーマル（「GiftGenius を開きます…」）なトーンと、よりフレンドリー（「GiftGenius を試してみましょう。候補の比較が楽になります」）なトーンを比較してみてください。

こうして、開発者としてだけでなく、対話の作者としても考えられるようになります。

9. 「いつ App を見せるか」の UX でよくある間違い

誤り №1: テーマに言及されたら何でも App を出す。
ありがちな極端さです。たとえば App がギフト向けだとして、会話に「ギフト」という単語が出た瞬間にウィジェットをトリガーしてしまう。ユーザーが「上司に失敗しないギフトは？」と尋ねているのに、生きた助言の代わりにカード UI を見せるのは、広告のように受け取られ、真の意図を無視します。これは公式 UX ガイドラインや「Respect user’s intent」に真っ向から反します。

誤り №2: 予告なしのフルスクリーン。
突然フルスクリーンで画面を占有する「サプライズ・ウィジェット」は、体験を台無しにする確実な方法です。特に長い会話の途中で、テキストから UI への急な遷移は悪目立ちします。OpenAI のガイドラインでも悪い実践とされています。遷移は必ずアナウンスし、可能なら同意を取りましょう。

誤り №3: 回答の代わりに UI を使う。
作者が「テキストで答える必要はない。美しい UI があるから」と考えてしまうことがあります。その結果、GPT がほとんど何も言わず、すべての「回答」がウィジェットの中に閉じ込められてしまう。特に音声やモバイルでは重要な情報に気づかないことも。正しい姿勢は、UI は回答を補完し、置き換えないということです。App は詳細や選択肢を見せ、GPT はそれが何を意味するかを説明します。

誤り №4: ユーザーの App 拒否を無視する。
ユーザーが「アプリは開かないで」や「テキストだけで」と明言したら、App は対話が終わるまでそれを厳守すべきです。2 メッセージごとに App を勧め続けるのは、しつこい「評価してください」ポップアップのようなもの。UX を悪化させ、ストアのレビューにも響きます。system‑prompt に拒否の尊重を明記しておきましょう。

誤り №5: auto‑launch と「提案」を区別しない。
明示と暗黙の意図を区別できないと、ユーザーがはっきり頼んでいるのに App を決して起動しなかったり、単に「いつか試してもいいかも」と言っただけで毎回起動してしまったりします。そこから「単語がそれっぽいから」と自動で開く誤作動が生まれます。トリガー（auto / suggest / avoid）の形式化と、system‑prompt の丁寧なロジック設計で、この混乱を防げます。

誤り №6: system‑prompt に UX ルールがまったくない。
UX の判断が「チームの頭の中」にだけあり、system‑prompt が「あなたは GiftGenius のアシスタント。ギフトを手伝って」程度にとどまっているケースがあります。結果、モデルは App を提案したり忘れたり、的外れなタイミングで開いたりします。構造化された UX ルールを system‑prompt とドキュメントに記録することは、ツールの JSON スキーマと同じくらい重要な成果物です。

誤り №7: 「UX はあとから」で済ませようとする。
まず「動くもの」を作り、あとで UX を考える——よくあるアプローチです。しかし ChatGPT Apps の場合、すでにツール呼び出しのパターンに結び付いてしまい、system‑prompt や GPT の振る舞いを変更するのが難しくなります。最低限の UX ガイドライン（chat‑first、拒否の尊重、App 表示の明確な基準、「サプライズ・ウィジェット」を避ける）は最初から組み込みましょう。そうすれば、その後の発展（inline パターン、fullscreen、voice）も健全な土台の上に築けます。