優れた ChatGPT アプリの条件

DevDay では、製品を ChatGPT の会話から直接使えるようにする新しい仕組み、ChatGPT アプリを発表しました。この記事では、その発表を踏まえ、開発者、プロダクトマネージャー、デザイナーに向けて、適切なユースケースを選び、公開後にユーザーの役に立つアプリを設計する方法を紹介します。特に、製品の強みを、目的と範囲が明確な機能に落とし込む方法を取り上げます。そうした機能があれば、モデルはさまざまな会話で、ユーザーの意図に合わせて製品の強みを活かせます。発表時に紹介した実装手順は、Apps SDK クイックスタートと開発者向けドキュメントをご覧ください。

この記事で扱う内容は次のとおりです。

• ChatGPT アプリの役割と、従来のアプリとの違い
• アプリがユーザーに価値を提供する 3 つの方法
• 会話の中で機能を見つけて使えるようにする設計
• アプリが実際に役立っているかを確かめる方法
• 具体例とスクリーンショットのヒント

ChatGPT アプリの役割

チームが初めて ChatGPT アプリを作るとき、出発点になりがちなのが次の発想です。

       「すでに製品があるのだから、それを ChatGPT でも使えるようにしよう」

そこでよく試みるのが、既存の Web アプリやモバイルアプリの画面、メニュー、操作の流れをチャット向けに作り直すことです。長年にわたり、ページやナビゲーション、UI の枠組みが「ソフトウェア」の前提だったことを考えれば、自然な発想です。

ただし、ChatGPT アプリが使われる環境は違います。ユーザーはアプリを「開いて」ホーム画面から操作を始めるわけではありません。ユーザーはすでに何かについて話していて、モデルがその会話のどのタイミングでアプリを呼び出すかを判断できます。ユーザーがアプリに触れるのは、会話の途中です。 この環境で役立つアプリは、一見すると驚くほど機能が少ないものです。製品全体を再現しようとはしません。ユーザーが ChatGPT でアプリを使うときに、いくつかの特定の機能を利用できるようにします。製品が最も得意とし、モデルがどんな会話でも活用できる機能です。

ChatGPT の外では、多くの場合、ユーザーはアプリ自体を目当てにやってきます。ユーザーは次の手順をたどります。

1. アプリのアイコンをタップします。
2. アプリの画面に入ります。
3. 画面の移動方法や UI の操作に慣れていきます。

製品設計に関わる判断の多くは、「画面全体を自分たちで設計できる」という前提に基づいています。ユーザーがそのアプリの中で時間を過ごすからこそ、レイアウトや初回利用時の案内、情報設計に力を注げます。

ChatGPT の中では、アプリの役割が変わります。

• アプリは、モデルが呼び出せる機能です。会話に必要なコンテキストを提供することも、画面を通じてユーザーとやり取りすることもできます。
• アプリは、進行中の会話の中に現れます。
• アプリは、モデルが組み合わせて使える複数のツールの一つです。

つまり、アプリの価値を測る基準は、利用体験全体よりも、必要なタイミングでモデルとユーザーが何を達成できるかにあります。

実務上は、次のように定義できます。

ChatGPT アプリとは、タスクの実行、ユーザーとのやり取りの開始、データへのアクセスができる、役割の明確なツールの集まりです。

この定義を設計に当てはめると、次のことが分かります。

• すべての機能を移植する必要はありません。
• ナビゲーションの階層をすべて用意する必要もありません。
• 必要なのは、明快でコンパクトな API です。呼び出しやすく、次の処理につなげやすい少数の操作を用意します。

ChatGPT アプリは、ユーザーが特定の種類の問題に直面したとき、モデルが手に取る道具箱だと考えてみてください。それぞれの道具で何ができるかが明確なほど、会話の流れに沿って使いやすくなります。

アプリを「製品のミニ版」ではなく「モデルが組み合わせて使える機能」と捉えると、設計の判断がしやすくなります。「次にどの画面に進んでもらうか」ではなく、「今ここで何を手伝えるか」を考えるようになります。

ユーザーに価値を提供する 3 つの方法

アプリのアイデアは、次の 3 つの問いで検討できます。

• 知る： ChatGPT だけでは見られないコンテキストやデータを、ユーザーが活用できるようになりますか？
• 実行する： アプリはユーザーに代わって実際に操作を行いますか？
• 見せる： テキストだけの場合よりも、情報を理解しやすく、次の行動に移りやすい UI で提示できますか？

この考え方は、仕事に役立つ生産性アプリにも、ゲームのように楽しむためのアプリにも当てはまります。ゲームで報告書の提出が早まることはなくても、ベースモデル単体ではうまく扱えない処理を担えます。たとえば、ゲームの状態を保持しながらロジックを実行する、進行状況を記録する、ルールを適用する、ゲームの世界を魅力的に描画するといった処理です。ゲームの価値は楽しさや夢中になれることにありますが、その価値を生み出す仕組みは同じです。

1) 新しく得られる情報

アプリを通じて、ChatGPT の会話で新たなコンテキストを利用できます。

• 最新の価格、空き状況、在庫
• 社内の指標、ログ、分析データ
• 専門分野のデータセット、購読者限定のデータセット、ニッチな分野のデータセット
• ユーザー固有のデータ（アカウント、履歴、好み、利用権限）
• センサーデータ、ライブ映像

実装では多くの場合、正確で最新のデータを管理し、アクセス権限を設定しているシステムにアプリを接続します。アプリがその分野でモデルの「目と耳」となることで、モデルは確かな根拠をもって質問に答えられます。

2) 新たに実行できること

アプリはユーザーに代わって次のような操作を実行します。

• 社内ツールのレコードを作成、更新
• メッセージ、チケット、承認、通知を送信
• 日程調整、予約、注文、設定
• ワークフローを起動（デプロイ、エスカレーション、データ同期）
• 対話型ゲームを進行（ルールの適用、ターンの進行、状態の追跡）
• 現実世界の機器を操作（IoT 機器やロボットの制御など）

ここでのアプリは、信頼できる情報源というよりも、ユーザーに代わって動く「手」です。ユーザーの意図をくみ取り、チームが普段使っているシステムに実際の変更を加えます。ゲームなら、ルールに沿ってゲームの状態を更新することで、プレイヤーは一貫性や公平さを実感できます。こうしてアプリは、実際に行動するエージェントとしての役割を担います。

3) より分かりやすい情報の見せ方

アプリは ChatGPT の会話の中で GUI を使い、ユーザーが情報を理解しやすく、行動に移しやすい形で提示できます。

• 絞り込んだ候補の一覧、比較、ランキング
• 表、タイムライン、グラフ
• ユーザーの役割や判断内容に合わせた要約
• ゲームの状態を視覚的に、または項目ごとに整理して示す画面（盤面、所持品、スコア）

この見せ方は、ユーザーが選択肢を比較し、何を優先するか判断するときに特に役立ちます。アプリがあれば、モデルはウィジェットを使って情報の関係を表現できます。列や行、スコア、図を使って、人が実際に判断するときの考え方に合わせて情報を整理できます。ゲームなら、プレイヤーがゲームの世界での「現在地」を把握できるように表示します。

知る・実行する・見せるの少なくとも一つで明確な改善がなければ、ユーザーは ChatGPT だけでできることにアプリが何を加えたのかを実感しにくくなります。不満を口にする人はいないかもしれませんが、仕事用でも遊び用でも、もっと役に立てる機会を逃していることになります。

アプリによって何が変わるのか、例を見てみましょう。

この回答は参考になりますが、ユーザーはその話題について会話を続けながら、実際に掲載されている物件を直接見てみたいかもしれません。そんなときに、物件を検索できるアプリが役立ちます。

Zillow アプリを使うと、チャット内で最新の物件情報を検索し、条件で絞り込み、各物件の詳しい情報まで確認できます。

物件をじっくり探せる全画面モード

ここでは、モデルから詳しい背景情報を得ながら、希望に応じて表示が変わるアプリも使えます。特定の地域にある住宅を探したくなったら、そのままモデルに頼めます。Zillow アプリでは、モデルが Zillow の MCP サーバー上のツールを呼び出し、UI を再描画します。

製品の移植から機能の選定へ

まず製品の機能をすべて書き出して、「どうすればこれらを ChatGPT で使えるようにできるか」と考えるのはよくあることです。

一見すると漏れのない進め方です。しかし実際には、機能の範囲が広がり、それぞれの役割が曖昧になりがちです。モデルはどれを使えばよいか判断しづらく、ユーザーも何ができるのか理解しづらくなります。アプリで何ができるかを一文で説明するのが難しければ、モデルにとっても理解は難しくなります。

次の手順で考えると、機能を選びやすくなります。

1. ユーザーが達成したい主なことを書き出します。 製品を使う人が、どの作業を終えたいのか、どんな結果を得たいのかを具体的に挙げます。それこそが、そもそも製品が存在する理由です。ここから始めると、機能を一覧にして確認することに気を取られず、ユーザーが得たい結果に集中できます。
   例：

   • 住まい選びを手伝う
   • アイデアを完成度の高いプレゼンテーションに仕上げる
   • ユーザーの希望に沿って、楽しみながら新しいものを見つけられるようにする
   • 生データを、分かりやすく共有しやすいレポートにまとめる

2. それぞれについて、次のように問いかけます。

   「アプリがなければ、ユーザーは ChatGPT の会話の中で何ができないだろうか？」

   よく挙がるのは次のような答えです。

   • リアルタイムデータや非公開データへのアクセス
   • 自社システムでの実際の操作
   • ユーザーが必要とする、構造化された結果や視覚的な結果の取得

3. ここで、自社のアプリならではの価値が見えてきます。「技術的に何を公開できるか」から、「自分たちだからこそ役に立てるのはどこか」へと問いが変わります。

4. アプリなしではできなかったことを、名前から用途が分かる操作に落とし込み、数を絞ります。たとえば、次のような操作です。

   • search_properties – 候補となる住宅を構造化されたリストで返します。
   • explain_metric_change – 関連データを取得し、指標が変化した主な要因として考えられるものを要約します。
   • generate_campaign_variants – メタデータ付きの広告案を複数作成します。
   • create_support_ticket – チケットを起票し、概要とリンクを返します。

こうして定義した操作には、次の特徴があります。

• モデルが迷わず選べるほど具体的
• 会話中のほかのステップと組み合わせやすいほどシンプル
• 製品全体の機能構成ではなく、ユーザーが得る価値に直結

別の角度から考えてみましょう。チームの誰かに「このアプリで必ずうまくできるようにしたいことを 3 つ挙げるとしたら？」と聞かれたとき、その答えと製品が提供する機能は、ほぼ一対一に対応するはずです。

たとえば、ChatGPT の Canva アプリでは、プレゼンテーション全体の下書きを生成できます。全画面モードに切り替えれば、普段スライドを見るときと同じ感覚でページをめくれます。一方、スライドごとの細かな編集には、引き続きフル機能の Canva エディターを使います。

会話の中で機能を見つけて使える設計

MCP サーバーでは、description を定義できます。ここに、どのタイミングでツールを呼び出すべきか、特定のタスクにはどのツール呼び出しが必要かを記述すると、モデルが判断に使うコンテキストになります。これにより、ユーザーの意図をツールの操作に結び付けやすくなります。

a) 意図が曖昧な場合

どこに住むか、一緒に考えてください。

この場合、アプリには次のような応答が適しています。

• それまでの会話に関連する情報があれば活用します。
• 確認が必要な場合も、質問は 1 つか 2 つまでにします。
• すぐに具体的な候補を示します。たとえば、いくつかの都市を挙げ、それぞれに短い説明を添えます。

ユーザーが最初に感じるべきなのは、何段階もある初期設定が始まったということではなく、住まい選びが一歩進んだということです。役立つ情報を見るまでに 5 つも質問に答える必要があれば、多くの人はそこでやめてしまいます。

実際に Canva アプリの対応を見てみましょう。

本格的なプレゼンテーションを作るには、背景情報が必要です。Canva アプリは追加の質問を通じて、ユーザーがどのようなプレゼンテーションを作りたいのかを整理できるようにします。

b) 意図が具体的な場合

シアトルで、評判のよい小学校の近くにある、寝室が 3 つで 120 万ドル未満の住宅を探してください。

この場合、ユーザーに同じことをもう一度説明してもらう必要はありません。アプリは次のように処理します。

• 依頼の内容を解析します。
• 適切な機能を呼び出します。
• 条件に合う結果を絞り込み、ユーザーが活用しやすい形に整理して返します。

「通勤のしやすさと学校の評価のどちらを重視しますか？」といった絞り込みを提案してもかまいません。ただし、必須の設定ではなく、希望に応じて結果を調整できる選択肢として提示します。

Canva の例：

ユーザーの意図が明確になり、プレゼンテーションを生成してほしいという依頼があれば、モデルは Canva を呼び出すタイミングと使うべき機能を特定できます。

次の例では、ツールがいくつかの案を提示し、ユーザーがさらに調整したい場合に備えて、希望を掘り下げる質問もしています。

c) ユーザーがブランドを知らない場合

ユーザーが自社のことを知っているとは限りません。

最初の実質的な応答では、次のことを意識します。

• アプリの役割を一文で説明します（「最新の物件情報と学校の評価を取得して、候補を比較できるようにします」）。
• 役立つ結果をすぐに提示します。
• 次に何ができるかを具体的に示します（「通勤時間、エリア、予算のうち、どの条件で絞り込みたいか教えてください」）。

何も知らない状態から使い始めるユーザーを想像してみてください。アプリが何をするものか、なぜ役に立つのか、どう使えばよいのかを、わずか 1、2 通のメッセージで伝えます。

ユーザーとモデルの双方を考慮した設計

設計では、次の両者を考慮します。

• チャットを使っている人
• いつ、どのようにアプリを呼び出すかを判断するモデルの実行環境

ほとんどのチームは、前者を意識した設計には慣れています。後者は比較的新しい設計対象です。しかし、アプリに何ができるのか、どう使うのかをモデルが理解できなければ、せっかく設計した画面や機能がユーザーの前に現れる機会も少なくなります。

同じくらい重要な観点がもう一つあります。モデルがアプリを呼び出したとき、どのようなユーザーデータがアプリを通るかです。優れたアプリ設計では、機能を明確にするだけでなく、どのデータを求めるか、どう利用するかについても慎重に判断します。

• 用途が明確な操作とパラメーター： アプリが役立つ場面と呼び出し方を明確にします。用途が伝わる名前（search_jobs、get_rate_quote、create_ticket）を使い、各パラメーターが必須か任意か、どの形式で指定するかを明記します。曖昧さがあると、モデルは呼び出し先を選びにくくなります。

• 設計段階からのプライバシー保護： 必須にするのは、本当に必要なフィールドだけにします。余分なコンテキストまでひとまとめに受け取るパラメーターは避けます。入力は必要最小限に絞って構造化し、「会話全体をそのまま送ってください」といった指示は使わないでください。

• 予測可能な構造化出力： スキーマを安定させ、ID と分かりやすいフィールド名を含めます。短い要約（「予算と通勤時間の条件に合う 3 件です」）と、機械で処理しやすいリスト（[{id, address, price, commute_minutes, school_rating, url}, …]）を一緒に返します。これにより、モデルは個々のデータを正確に参照しながら、自然な言葉で説明できます。

• 何を返さないかも意識した設計： 「念のため」という理由で機密性の高い内部情報を含めないでください。ユーザーから見える箇所には、トークンやシークレットが出ないようにします。元のデータを詳細まで示す必要がなければ、該当箇所を伏せるか、集計して提示します。

• 収集する情報と目的の明示： 求める情報はタスクの実行に必要な最小限に絞ります。アカウントへのアクセスなど、機密性の高い情報や権限が必要な場合は、その理由を一文で説明します。何がどこに送られるのかが分かるように、操作とスキーマを設計します。

ほかのアプリと連携できる設計

実際の ChatGPT セッションで、使われるアプリが自社のものだけということはまれです。モデルは同じ会話の中で複数のアプリを呼び出すことがあります。

ユーザーから見れば、一連のやり取りです。開発者にとっては、自社のアプリが単独で完結する製品ではなく、エコシステムの一部であることを意識すべき場面です。

設計では、次の点を意識します。

• 操作は小さく分け、目的を絞ります。

  • search_candidates、score_candidates、send_outreach のように分けます。
  • run_full_recruiting_pipeline という一つの操作にすべてをまとめるのは避けます。

• 出力は次の処理に渡しやすくします。

  • 安定した ID、分かりやすいフィールド名、一貫した構造を使います。
  • 重要な情報を自由記述のテキストだけに埋め込まないようにします。

• 長く一本道の操作フローを避けます。

  • アプリが担う作業を終えたら、会話に制御を戻します。
  • 次のステップをどのツールに任せるかは、モデルが判断できるようにします。

ほかのアプリや自社アプリの将来のバージョンが出力を再利用しやすければ、エコシステムのほかの部分で機能が向上したとき、それと競合するのではなく、その恩恵を受けられます。

簡易チェックリスト

開発前にも開発後にも使えるチェックリストです。

• 1. 新しくできること

  • 知る・実行する・見せることのいずれかで、アプリによって新しく何ができるようになるかは明確ですか？
  • 想定している利用場面でアプリが動かなくなったら、ユーザーは気付きますか？

• 2. 機能の範囲

  • 製品全体を再現しようとせず、提供する機能を少数に絞っていますか？
  • 各機能の名前と範囲は、ユーザーが実際に達成したいことに明確に対応していますか？

• 3. 初回のやり取り

  • 曖昧なプロンプトにも具体的なプロンプトにも適切に対応できますか？
  • 初めてのユーザーが、最初の実質的な応答からアプリの役割を理解できますか？
  • 最初のやり取りで役に立つと実感できますか？

• 4. モデルからの使いやすさ

  • 操作とパラメーターは明確で、解釈が分かれる余地はありませんか？
  • 出力は、次の処理に渡したり再利用したりできるように構造化され、一貫性がありますか？

• 5. 評価

  • アプリが適しているケース、適していないケース、境界的なケースを含む、よく吟味した少数のテストケースがありますか？
  • アプリを使った回答が、アプリを使わない ChatGPT の回答よりも優れている割合を、おおよそ把握していますか？

• 6. エコシステムとの適合性

  • ほかのアプリやユーザーが、アプリの出力を無理なく次の作業に活用できますか？
  • 一連の作業をすべて引き受けず、複数のアプリが連携する中で一つの役割を担うことを受け入れられますか？

公開の時点で、すべての項目を完璧に満たしている必要はありません。ただし、ほとんどの問いに「はい」と答えられるなら、製品を ChatGPT の中で使えるようにしただけではありません。製品が得意とする分野で、ChatGPT がユーザーのために実際にできることを増やせています。そうしたアプリこそ、ユーザーにとって欠かせない存在になっていきます。