Developer Mode vs Store

1. はじめに

前回までの講義では、ChatGPT App とは何か、どんなレイヤーで構成されているか、旧来のプラグインや単なる OpenAI API のボットと何が違うのかを話しました。今回はそのアプリのライフサイクルという重要なテーマに進みます。

数年でもウェブサービスを作っていれば、“lifecycle” という言葉は怖くないでしょう。どんなプロダクトにも基本の道筋があります。「ローカルで実装 → staging にデプロイ → production にデプロイ → たまに壊す → 直す」。ChatGPT と App のエコシステムでも基本は同じですが、いくつかの違いがあります。ChatGPT 本体に Dev Mode が現れ、さらに Store という別のエンティティが存在します。

次の2つのレイヤーをはっきり分けるのが重要です。

1. 物理的にあなたのコードがどこで動いているか: ローカルの Next.js サーバー、Vercel、あるいはどこかの Kubernetes クラスター等。ここはあなたの世界で、あなたが支配します。
2. ChatGPT があなたの App をどう認識するか: メタデータ、URL、権限の集合として、Developer Mode で接続するか、Store で完成品として扱うか。ここは OpenAI 側の世界で、独自のルール、レビュー、そしてユーザーがいます。

この講義はまさに後者のレイヤーについてです。皆さんが慣れ親しんだ環境モデル（dev / staging / prod）を土台にしつつ、ChatGPT の視点で見ていきます。目標は、いつでも次の問いに答えられる状態になることです。今この瞬間、どのコードが私の App を動かしているのか？誰がそれを見られるのか？安全に実験するには？そして Store で「App を更新する」とは具体的に何を意味するのか？

2. Developer Mode: ChatGPT 内の個人用サンドボックス

まずは開発者にとって一番気楽な場所、壊してもほぼ誰にも迷惑をかけないサンドボックスから始めましょう。

Developer Mode は ChatGPT 内の特別なモードで、ChatGPT Apps を URL で直接接続できます。レビュー不要、Store で App を公開する必要もなく、世界に向けて App を露出しません。感覚的にはブラウザの localhost:3000 に近いですが、舞台が ChatGPT の世界です。

概念的にはどのような見え方か

最も簡単には、次のような図で捉えられます。

flowchart TD
    User("ChatGPT UI (Dev Mode)")
    AppConfig["App の Dev 設定 (URL + メタデータ)"]
    AppServer["あなたの App サーバー (Next.js + Apps SDK)"]

    User -->|チャットでのリクエスト| ChatGPTCore[GPT]
    ChatGPTCore -->|App が必要| AppConfig
    AppConfig --> AppServer
    AppServer -->|UI/ツール| ChatGPTCore
    ChatGPTCore --> User

開発者であるあなたは、Developer Mode の設定で ChatGPT に「これが私の App、これがその URL、名称とできることはこれ」と伝えます。ChatGPT はその URL をあなたのアプリのソースとして扱い始めます。Store に App を提出するまでは、あなた（と、開発者として追加したチームメンバー）が見られるだけです。

接続の技術的詳細（HTTPS トンネル、Vercel など）は後ほど解説します。ここでのポイントは、Dev Mode は ChatGPT が呼び出せる、あなたの dev サーバーへの「動的なショートカット」のようなものだということです。

Developer Modeを有効にする方法

ローカルサーバーをChatGPTインターフェースに「接続」できるようにするには、設定で対応するスイッチを有効にする必要があります。

• リンク https://chatgpt.com/#settings/Connectors/Advanced にアクセスするか、Settings -> Connected apps -> Advanced に移動してください。
• Developer Mode - ON

これを行うとすぐに、Create App ボタンが表示されます。

Dev Mode が production とどう違うか

違いは一般的なウェブ開発における dev と production の違いに近いのですが、いくつか特有の点があります。

まずは 可視性。Dev Mode の App は、通常の ChatGPT ユーザーからは基本的に見えません。見えるのはあなた、あるいは組織内の権限を持つメンバーだけです。半壊れの UX に偶然遭遇される心配なく、自由に実験できます。

次に 安定性と実験。Dev Mode では、コードを2分おきに変えても、ローカルサーバーを上げたり落としたりトンネルを再起動したりしても構いません。ChatGPT は指定の URL にアクセスし続けますが、時々 500 を返したり、応答しなかったりしても咎められません。dev とはそういう場所です。

さらに 権限とポリシー。Dev Mode ではさまざまな構成を試しやすい一方で、コンテンツと基本的な安全性のポリシーは dev でも無効になりません。ChatGPT は、あなたが突然「全方位ハッキング App」になることは許しません。ただし Store のレビュー枠組みはここではまだ有効化されません。完璧なリスティングや美しいロゴ等は不要です。

最後に、Dev Mode は通常、診断が容易です。ロジックをすばやく変え、ChatGPT からあなたのサーバーへどんなリクエストが来ているかを確認し、「ユーザー移行」を気にせず挙動を調整できます。

Dev Mode をアプリ向けの個人用サンドボックスとして見てきました。次は Store を視野に入れつつ、App のライフサイクルをわかりやすい「ステートマシン」に落とし込みます。

3. ChatGPT App の状態: 下書きから公開停止まで

ここでは App のステートマシンを定義します。大きく4つの状態を仮定します: Draft / Dev-only、Under review、Published、Paused/Removed。

ライフサイクルのステートマシン

図にすると、次のようになります。

stateDiagram-v2
    [*] --> Draft

    Draft: Dev Mode / 下書き
    Review: Under review (Store)
    Published: Store に公開、ユーザーが利用可能
    Paused: Paused / Removed

    Draft --> Review: レビューに提出
    Review --> Draft: 却下 / 修正して戻る
    Review --> Published: 承認
    Published --> Paused: 一時停止 / 取り下げ
    Paused --> Draft: dev モードで再開
    Draft --> Published: Store を介さない社内ロールアウト (組織向け)

Draft の状態では、あなたの App は dev リソースとしてのみ存在します。Developer Mode に接続し、さまざまな機能を試せますが、Store には露出しません。

人に見せられる段階だと判断したら、つまり Under review に送るときです。ここでは OpenAI（または組織内のレビューシステム）がポリシー準拠、安定性、基本的な安全性、UX の妥当性を確認します。

問題がなければ、App は Published に移行します。Store に掲載されるか、企業シナリオなら組織のユーザーに公開されます。ここから実ユーザーが使い始めるため、コードや構成の変更はより慎重な計画が必要です。

一時的に App を非公開にしたい場合は、Paused/Removed に移せます。Paused の場合、新規ユーザーからは見えなくなりますが、既存セッションでは動作を続ける場合や完全停止する場合があり、詳細はプラットフォーム実装や設定に依存します。

4. Store: App が製品になるとき

Developer Mode はあなたのガレージ。Store は正規ディーラーのショールームです。ここからはユーザー、評価、リスティングのルール、レビューが関わってきます。

Store に行くと何が変わるか

第一に、あなたの App は「製品」になります。名前、説明、アイコン、カテゴリ、ときには対話の初期プロンプトといったリスティングが必要です。これらのメタデータに基づき、ChatGPT の Store はユーザーにあなたのアプリを検索・推薦し、モデル自身もどんなシナリオでその App が有用かを理解します。

第二に レビューとポリシー。App が Store に現れる前に、安全性・コンテンツ・UX の要件に合致しているかチェックされます。つまり:

• 余分な個人情報をこっそり収集してはいけない;
• App がやらないことを約束してはいけない;
• 許容カテゴリを逸脱するコンテンツに踏み込んではいけない。

ポリシーとサンドボックスについては別講義で詳しく扱いますが、Store は比較的「しつけの行き届いた」バージョンだけを持ち込む場所だと捉えておくと良いでしょう。

第三に 安定性への責任。Dev Mode で遊んでいる間の障害は自分たちの問題です。しかし Store では、適切な可用性、妥当なレイテンシ、ウィジェットに「赤い死の画面」を出さないことが期待されます。後続のモジュールでは、SLO・メトリクス・Store レビューをこの文脈で扱います。

バージョン: dev と production

よくある質問は「コードを更新したら、ユーザーは何を見るのか？」。ChatGPT Apps の世界では、常に2つの「枝」を意識すると有益です。

• dev ブランチ — Developer Mode に接続され、IDE の隣にある dev サーバーを指すことがある;
• production ブランチ — Store に公開された構成に紐づき、安定した URL を指す。

アーキテクチャ的には、プロジェクトの中で次のような小さな TypeScript 型で表現してもよいでしょう。

type AppStage = 'dev' | 'production';

interface ChatGPTAppConfig {
  id: string;
  stage: AppStage;
  endpointUrl: string;
}

const giftGeniusDev: ChatGPTAppConfig = {
  id: 'giftgenius',
  stage: 'dev',
  endpointUrl: 'https://dev.giftgenius.example.com',
};

const giftGeniusProd: ChatGPTAppConfig = {
  id: 'giftgenius',
  stage: 'production',
  endpointUrl: 'https://app.giftgenius.example.com',
};

現実には、構成を保持するのはあなたのコードではなく ChatGPT プラットフォームですが、このような構造は、同じ App の2つの「像」を頭に置いておく助けになります。

ChatGPT App のリリースは、サイトの軽い更新というより Apple App Store のアプリリリースに近いものです。あなたのウィジェットや mcp-tools は毎回、アプリのリリース時にキャッシュされます。レビューは2週間かかることもあります。つまり「本番に出してからテストで詰めよう」は通用しません。レビューに出す時点で、十分にテストされ安定したアプリにしておく必要があります。

5. 組織的な文脈: 個人アカウント vs 会社

ここまでで App を dev・production の2本立てで捉え、Store にどう反映されるかを見ました。ライフサイクルのもう1つの重要な軸は、組織的に「どこ」に所属するかです。

最も単純なのは、個人の ChatGPT Plus で個人として App を作るケースです。Dev Mode は純粋にあなた専用、Store もあなたのアカウント配下。比較的シンプルです。自分用に作って公開して、世界に喜んでもらうだけ。

しかし多くの場合、ChatGPT Apps は企業コンテキストで生きます。この場合、いくつかの追加ロールが現れます。組織の管理者がいて、どの App を社員に許可するか、ブロックするか、パイロットグループだけに開放するかを決めます。あなたの App は全世界ではなく、特定の会社、あるいはその中の特定部門だけに公開されることもあります。

このシナリオでは、ライフサイクルは次のように進みます。最初はチーム内の dev プロジェクトとしてのみ存在し、その後「社内の production」が現れ、例えば営業部門だけにパイロットとして公開されます。うまくいけば、最終的にグローバルな Store に送って外部プロダクトにしていくこともあります。

これはアーキテクチャ上も重要で、App を内製ツールとしても、パブリック製品としても適切に動くよう設計する必要があることを意味します。ときにはフィーチャーフラグ、「身内限定」モード、別個の認証設定が必要になります。

6. 実用的なシナリオ: GiftGenius のライフサイクル

抽象論に終わらないよう、コース全体で取り上げるギフト提案アプリ GiftGenius を例に見ていきます。

ステップ1. Dev Mode でのアイデアと粗いプロトタイプ

GiftGenius を作ると決めます。これは、誰へのプレゼントか、予算はいくらか、相手の興味は何かを尋ね、あなたの商品カタログを使って候補を提案する App です。

最初のステップでは次を行います。

1. 最小のウィジェットを備えた簡単な Next.js プロジェクトを立ち上げる。
2. ChatGPT で Developer Mode を有効にし、dev サーバーの URL を追加する。
3. いくつか試験的な対話を行う。たとえば GPT に「友だちのゲーマー向けに $50 以内でプレゼントを選ぶのを手伝って」と頼み、App の呼び出し、ウィジェットのレンダリング、UX の見え方を観察する。

この段階では Store、レビュー、見栄えのよいアイコンのことは考えません。アイデアがそもそも機能するか、ChatGPT プラットフォームで望むシナリオが実現できるかを自分とチームに証明するのが目的です。

ステップ2. プロトタイプの強化と社内アルファ

基本シナリオが動くと確信したら、「強化」段階に入ります。次を行います。

• ロジックをわかりやすい構造に整える;
• App に本当に必要な権限やデータは何かを検討する;
• たとえば商品カタログが応答しない場合など、エラー時の挙動を確認する。

依然として Dev Mode 中ですが、もう単独ではありません。チームメンバーを開発者またはテスターとして追加し、彼ら自身の ChatGPT に App を接続できるようにします。この段階のライフサイクルは依然として Draft を中心に回ります。コードを素早く更新し、UX パターンを試し、チーム内でフィードバックを議論します。

ステップ3. Store とレビューの準備

ここで「GiftGenius は外部ユーザーに見せても十分だ」と判断します。焦点はコードからプロダクトとしての体裁へ移ります。

• App の正直でわかりやすい説明を書く;
• 権限を設定する。App がどのデータにアクセスし、なぜ必要かを説明する;
• UX が誤解を招かず、App が不可能なことを約束していないことを確認する。

これは Draft から Under review への移行点です。App をレビューに提出し、しばらくは中間状態で過ごします。プライバシーポリシーの明確化、文言の修正、権限の絞り込みといった指摘が戻ってくるかもしれません。Draft に戻って修正し、再提出します。

ステップ4. 公開と「本番の生活」

承認されると、GiftGenius は Published 状態になります。Store でユーザーが見つけられるようになり、ChatGPT が適切なクエリで推薦することもあります。ここから実際のフィードバックや利用状況を観測し、スケールを考え始めます。

以降、コードの変更は「ちょっと機能を足す」ではなく、ミニリリースです。後方互換性やマイグレーションを考え、可能ならまず dev 版を変更して検証し、その後に production 構成を更新します。

必要に応じて、一時的に App を Paused にすることもできます。たとえば重大な脆弱性が見つかった場合や、バックエンドが負荷に耐えられない場合です。理想は、Published ブランチを段階的に育てつつ、実験用に dev 環境を忘れないことです。

7. 開発者が環境をどう考えるか: dev・staging・production + Dev Mode

GiftGenius を例に、Dev Mode のアイデアから公開済みの App までを辿りました。これを開発者に馴染みのある dev/staging/production の環境スキームに当てはめ、Dev Mode や Store とどう対応づくかを見ていきます。

頭の中では、次のようなマトリクスで整理すると便利です。

Developer Mode は本質的に、あなたの dev / staging インフラに貼り付く形になります。ChatGPT がテストに使う一時的な URL を公開します。一方、Store の構成は成熟した production-URL を指します。

今後、Vercel へのデプロイやトンネルの話に進むと、このマトリクスは具体的な手順のセットに落ちていきます。現時点で大事なのは、現在の ChatGPT からのリクエストが、あなたの dev サンドボックスなのか、ユーザーがアクセスする本番環境なのかを常に把握しておくことです。

8. ライフサイクルに関する小さな「コード片」

馴染みのある TypeScript 流儀に結びつけるため、プラットフォームではなくあなたのツーリング側で App のライフサイクルを表す簡単な型を書いてみましょう。リポジトリに置いて、異なる状態を忘れないようにできます。

type AppLifecycleState = 'draft' | 'under_review' | 'published' | 'paused';

interface LifecycleSnapshot {
  id: string;
  name: string;
  state: AppLifecycleState;
  lastDeployedAt: Date | null;
  devUrl?: string;
  prodUrl?: string;
}

const giftGeniusLifecycle: LifecycleSnapshot = {
  id: 'giftgenius',
  name: 'GiftGenius – プレゼント選び',
  state: 'draft',
  lastDeployedAt: null,
  devUrl: 'https://dev.giftgenius.example.com',
};

このオブジェクトを ChatGPT に送ることはありませんが、チームが同じ文脈を共有する助けになります。すべての App の状態を表示する簡単な CLI を作るのもよいでしょう。Store に載っているものと下書きを取り違えないようにするためです。

次のモジュール以降でも、このライフサイクルモデルに繰り返し立ち返ります。トンネルや Vercel へのデプロイの設定、MCP サーバーとエージェント系シナリオの設計、commerce フロー、Store レビューの準備などです。Dev Mode と Store を、同じシステムの両極として考えてください。前者は実験のためのサンドボックス、後者は成熟した製品のショーケースです。

9. Dev Mode と Store でありがちなミス

よくあるミス1: 「すぐに Store に出して、そこで何とかする」。
できるだけ早く「市場を獲りたい」と、半分しか動かないプロトタイプの段階で App を Store に出したくなることがあります。これはほぼ確実に、悪いレビュー、利用統計の悪化、レビューでの追加質問に繋がります。まずは Developer Mode で何度かイテレーションを回し、同僚や友人からフィードバックを集め、基本 UX を安定させてから Store に行く方が健全です。

よくあるミス2: dev と production 環境の混同。
典型例は、Dev Mode を production と同じ URL に向けてしまい、「軽いデバッグ変更」を実ユーザーが突然目撃してしまうケースです。dev と prod の URL を分離するのは、通常のウェブサービスと同じくらい慎重であるべきです。ChatGPT App の構成で production-URL が設定されているなら、「夜の軽い実験」に使ってはいけません。

よくあるミス3: 状態の明確な共通理解がない。
開発者が App の現在の状態（Draft、Under review、Published、Paused）を把握していないと、妙な行き違いが起こります。ある人は App がすでに Store にあると思い、別の人はまだローカルプロトタイプだと考えている、といった具合です。最低限、プロジェクトの README に現在の状態と、次の段階に進むための手順を書いておきましょう。

よくあるミス4: ポリシーとレビュー準備を最後まで後回し。
一部のチームは App を「ただのサイト」のつもりで作り、ポリシー・権限・Store 要件を提出前日に思い出します。結果として、データ収集・保管の大幅な作り直しや説明文の書き換え、権限の縮小が必要になりがちです。最初から枠組みを意識し、Dev Mode でも、正直で最小限の権限で実験するのが良いです。

よくあるミス5: 内部利用と外部公開の戦略を分けない。
もともと社内ツールとして作り始めた App を後でパブリック製品にしたくなった場合、対象ユーザーを取り違えがちです。社内では多少「無骨」な UX や複雑なシナリオでも許容されますが、外部の Store では別のレベルの使いやすさが期待されます。今どのモードにいるのかを理解していないと、公開 App が社内管理ツールのように見えたり、社内パイロットが、早すぎる外部志向のせいで停滞したりします。

よくあるミス6: Dev Mode と可観測性を結びつけない。
Developer Mode はデバッグに最適ですが、その利点を活かす必要があります。ログを見ず、dev 環境で ChatGPT があなたの App にどんなリクエストを送っているかを記録しないと、本番で不愉快な驚きが待っているかもしれません。Dev Mode を、ウィジェットがビルドできるかの確認だけでなく、モデルとユーザーの実際の振る舞いを学ぶ場として活用しましょう。