DevDay で、プロダクトを ChatGPT の会話に直接組み込む新しい方法として、ChatGPT アプリを紹介しました。本記事では、その発表を踏まえ、適切なユースケースを選び、公開後に実際に役立つアプリを設計するための実践的な指針を、開発者、PM、デザイナーの皆さんにお伝えします。焦点を当てるのは、プロダクトの強みを、モデルがさまざまな会話やユーザーの意図に応じて活用できる、役割と範囲が明確な機能に落とし込む方法です。具体的な開発手順をお探しの場合は、Apps SDK クイックスタートと開発者向けドキュメントを直接ご覧ください。
本記事では、次の内容を扱います。
- ChatGPT アプリとは何か、そして何ではないのか
- アプリが確かな価値を加える 3 つの方法
- 会話と発見を支える設計の方法
- アプリが実際に役立っているかを見極める方法
- 具体例とスクリーンショットの提案
ChatGPT アプリの本質
チームが初めて ChatGPT アプリを作るとき、出発点となるのは、多くの場合こんな考えです。
「すでにプロダクトがある。それを ChatGPT に組み込もう」
多くの場合、既存のウェブやモバイルの画面、メニュー、操作の流れを、チャット向けに作り直すところから始まります。これは自然な発想です。長年にわたり、「ソフトウェア」といえば、ページやナビゲーション、UI の枠組みを意味してきたからです。
しかし、ChatGPT 向けのアプリ開発では、前提となる環境が異なります。ユーザーはアプリを「開いて」、ホームページから使い始めるわけではありません。何かについて会話している最中に、モデルがアプリをその会話に組み込むタイミングを判断できます。ユーザーは会話のある時点でアプリを使い始めるのです。 こうした環境では、優れたアプリほど、外から見ると驚くほど小さく見えます。プロダクト全体を再現しようとはしません。代わりに、ChatGPT 内でアプリを使うユーザーに、いくつかの 特定の機能 を提供します。それは、そのプロダクトが最も得意とする具体的な機能であり、モデルがどんな会話でも再利用できるものです。
ChatGPT の外では、アプリそのものがユーザーの目的地となることが一般的です。ユーザーは次のように利用します。
- アプリのアイコンをタップ
- アプリの環境に入る
- ナビゲーションや UI の操作パターンを覚える
プロダクトに関する判断の多くは、「画面全体を自分たちで設計できる」という前提に基づいています。ユーザーがそのアプリの環境でじっくり操作するため、レイアウトやオンボーディング、情報設計に多くの労力を注げます。
ChatGPT の中では、アプリは異なる役割を担います。
- コンテキストの取得や視覚的なやり取りのために、モデルが呼び出せる 機能 です。
- 進行中の会話の 中に 登場します。
- モデルが連携させて使える複数のツールの 1 つです。
つまり、「価値の単位」となるのは、アプリが提供する体験全体というよりも、適切なタイミングでモデルやユーザーが具体的に何を達成できるようになるかです。
実用的には、次のように定義できます。
ChatGPT アプリとは、タスクの実行、やり取りの開始、データへのアクセスを担う、明確に定義されたツールの集合です。
この定義から、いくつかのことがわかります。
- すべての機能を移植する必要はありません。
- 完全な階層型ナビゲーションは必要ありません。
- 一方、明確でコンパクトな API は 必要です 。呼び出しやすく、後続の処理にも利用しやすい、少数の操作を用意します。
ChatGPT アプリは、ユーザーが特定の種類の問題に直面したときに、モデルが手に取るツールキットだと考えられます。そのツールキットが明確に定義されているほど、会話の流れの中で使いやすくなります。
アプリを「プロダクトの小型版」ではなく、「モデルが組み合わせて使える機能」と捉えると、設計の判断がしやすくなります。「ユーザーを次にどこへ誘導するか」ではなく、「ここで何を手伝えるか」を考えるようになるのです。
確かな価値を加える 3 つの方法
どんなアプリのアイデアにも使える、シンプルな判断基準があります。
- 知る： そのアプリがなければ ChatGPT で参照できない、新たなコンテキストやデータをユーザーが活用できるようになりますか？
- 実行する： アプリはユーザーに代わって実際の操作を行いますか？
- 見せる： アプリは、プレーンテキストよりもわかりやすく、行動につなげやすい UI で情報を提示しますか？
これは、 「実務向け」 の生産性アプリにも、ゲームのような 「純粋に楽しむため」 のアプリにも当てはまります。ゲームはレポートの提出を早める役には立たないかもしれませんが、それでもモデル単体ではうまくできないことを実現します。状態を保持するゲームロジックの管理、進捗の追跡、ルールの適用、ゲーム世界の魅力的な描画などです。提供する価値は楽しさや夢中になれる体験ですが、根底にある仕組みは同じです。
1) 新たに知ることのできる情報
アプリによって、ChatGPT の会話で新たなコンテキストを利用できるようになります。
- リアルタイムの価格、空き状況、在庫
- 社内の指標、ログ、分析データ
- 専門的なデータセット、サブスクリプション契約者限定のデータセット、ニッチな分野のデータセット
- ユーザー固有のデータ（アカウント、履歴、好み、利用権限）
- センサーデータ、ライブ映像ストリーム
実際には、正確で最新のデータを保持し、アクセス権限を管理しているシステムとの橋渡しをすることが多くなります。アプリは、その分野におけるモデルの「目と耳」となり、より確かな根拠に基づいて質問に答えられます。
2) 新たに 実行できること
アプリはユーザーに代わって操作を行います。
- 社内ツールのレコードを作成または更新
- メッセージ、チケット、承認、通知を送信
- 予定の設定、予約、注文、各種設定
- ワークフローを起動（デプロイ、エスカレーション、データ同期）
- インタラクティブなゲームをプレイ（ルールの適用、ターンの進行、状態の追跡）
- 現実世界での操作（IoT、ロボット制御など）
ここでアプリが担うのは、正しい情報を提供する役割というよりも、実際に手を動かす役割です。ユーザーの意図を受け取り、チームが日常的に使うシステムに具体的な変更を加えます。ゲームなら、一貫性と公平さを感じられる体験になるように、ゲームの状態を具体的に変化させます。こうしてアプリは、実質的にエージェントとしての役割を担うようになります。
3) より良い見せ方
アプリは ChatGPT の会話内で GUI を使って情報を提示し、より理解しやすい形や行動につなげやすい形にできます。
- 絞り込んだ候補の一覧、比較、ランキング
- 表、タイムライン、グラフ
- 役割や意思決定の内容に応じた要約
- ゲームの状態を視覚的または構造化された形で表示（盤面、所持アイテム、スコア）
これは、ユーザーが何かを選んだり、トレードオフを検討したりするときに特に役立ちます。アプリは、情報を構造化して表現する手段をモデルに提供できます。列、行、スコア、視覚要素を備えたウィジェットを使い、人が実際に判断する方法に合わせて情報を示せます。ゲームであれば、ゲーム世界での「現在の状況」を把握する方法に合わせられます。
知る・実行する・見せるの少なくとも 1 つで明確な改善をもたらさなければ、そのアプリは、ユーザーがすでに ChatGPT でできることに価値を加えていないと感じられがちです。ユーザーがはっきり不満を口にしなくても、仕事用か遊び用かを問わず、より意味のある価値を提供する機会を逃していることになります。
アプリによって体験がどのように向上するか、例を見てみましょう。
ChatGPT の回答例この回答は役立ちますが、ユーザーは、コンテキストを切り替えたり会話を離れたりせずに、追加機能を持つアプリで実際の物件を直接見たいと思うかもしれません。
Zillow アプリを使った回答
Zillow アプリを使うと、チャットを離れることなく、最新の物件情報を検索し、条件で絞り込み、詳しい物件情報を確認することもできます。
より充実した物件探しのための全画面モード
ここでの価値は、モデルから豊富なコンテキストを得ながら、自分の意図に応じて動的に反応する、より充実したアプリ体験も得られることです。特定の地域の物件を探すよう頼みたい場合はどうでしょうか。Zillow アプリでは、モデルが Zillow の MCP サーバー上のツールを呼び出し、UI レイヤーを再描画します。
プロダクトの移植ではなく、できることの厳選
最初によく思いつくのは、プロダクトの全機能を列挙して「これらをどうやって ChatGPT に組み込もうか」と考えることです。
机上では、抜け漏れのない方法に思えます。しかし実際には、提供する機能の範囲が広く曖昧になり、モデルには使い分けにくく、ユーザーには理解しにくいものになりがちです。アプリで何ができるかを一文にまとめるのに苦労するなら、モデルにとっても理解が難しくなります。
より効果的な進め方は次のとおりです。
-
ユーザーが実現したい主なことを洗い出す： ユーザーが取り組んでいる具体的なタスクや目指している成果のうち、自分たちのプロダクトが実現を支援できるものを特定します。それこそが、そもそもプロダクトが存在する理由です。ここから始めれば、機能のチェックリストではなく、ユーザーの成果に軸を置けます。
例：- 住まい選びの支援
- アイデアを洗練されたプレゼンテーションに仕上げる支援
- ユーザーの意図に沿った、楽しく発見のある体験の提供
- 生データから、わかりやすく共有しやすいレポートへの変換
-
ユーザーが実現したいことごとに、次のように問いかけます。
「アプリがなければ、ChatGPT の会話の中でユーザーができないことは何か？」
よくある答えは次のとおりです。
- リアルタイムのデータや非公開データへのアクセス
- 自社システム内での実際のアクションの実行
- ユーザーが必要とする、構造化された出力や視覚的な出力の取得
-
ここで、独自の価値が見え始めます。「技術的に何を公開できるか」ではなく、「自分たちだからこそ役立てるのはどこか」と考えるようになります。
-
こうした不足を補うために、 わかりやすい名前を付けたオペレーションを少数に絞って用意します。たとえば、次のようなものです。
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 つで $1.2M 未満の住宅を探してください。
この場合、アプリはユーザーに同じことを繰り返し説明させるべきではありません。次のように対応します。
- クエリを解析します。
- 適切な機能を呼び出します。
- 結果を絞り込み、使いやすい構造で返します。
「通勤のしやすさと学校の評価では、どちらを重視しますか？」といった絞り込みの提案はできます。ただし、必須の設定ではなく、任意の調整だと感じられるものであるべきです。
Canva の例：
ユーザーの意図が明確になり、プレゼンテーションの生成を依頼すると、モデルは Canva をいつ呼び出し、どの機能を使うべきかを的確に判断できます。
以下のように、ツールはいくつかの選択肢を提示し、ユーザーがさらに調整したい場合は、より詳しく希望を尋ねます。
c) ブランドが知られていない場合
ユーザーが自分たちのことを知っているとは限りません。
最初の実質的な応答では、次のことを行うべきです。
- アプリの役割を一文で説明します（「最新の物件情報と学校の評価を取得し、候補を比較できるようにします」）。
- 役立つ結果をすぐに提示します。
- 次にできることを明確に示します（「通勤、エリア、予算で絞り込みたい場合は、お知らせください」）。
これは、アプリをまだ知らないユーザーに使い始めてもらうための課題です。わずか 1〜2 件のメッセージで、 どのような アプリなのか、 なぜ 役立つのか、 どう 使うのかを伝える必要があります。
ユーザーとモデルの両方を考慮した設計
設計では、次の 2 者を考慮する必要があります。
- チャットを利用する人
- アプリを呼び出すタイミングと方法を決めるモデルのランタイム
多くのチームは、前者を考慮した設計には慣れています。後者は比較的新しい視点です。しかし、モデルがアプリの機能や使い方を理解できなければ、ユーザー向けに設計した体験を提供する機会も限られてしまいます。
同じくらい重要な第 3 の視点があります。それは、 モデルがアプリを呼び出したときに、どのようなユーザーデータがアプリを通るかです。 優れたアプリ設計には、機能のわかりやすさだけでなく、 何を 要求し、それを どう 使うかを厳格に管理する姿勢も求められます。
-
内容が明確に伝わるアクションとパラメータ： アプリが役立つ場面と呼び出し方が、すぐにわかるようにします。わかりやすい名前（
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 が実際に力を発揮できるようにしていると言えます。そこから、アプリはなくてはならない存在になっていきます。