CodeGym /コース /ChatGPT Apps /ローカル実行、HTTPS トンネル、そして ChatGPT からの到達性

ローカル実行、HTTPS トンネル、そして ChatGPT からの到達性

ChatGPT Apps
レベル 2 , レッスン 2
使用可能

1. localhost はあなた専用であり、ChatGPT 用ではない

まずこのモジュールでよく起きる認知的不協和から始めましょう。あなたはブラウザで http://localhost:3000 を開き、すべてうまく動いていて、Next.js もご機嫌、ウィジェットも描画されます。 直感的にはこう思えるでしょう。「URL があるなら、ChatGPT にそのまま渡せばいいのでは?」。

問題は、localhost は「インターネット上の自分のマシンの魔法のドメイン」ではないという点です。 これは常にリクエストを出しているブラウザやクライアント自身のマシンを指す特別な名前です。 あなたのノート PC は自分自身にアクセスしています。ChatGPT が動いている OpenAI のサーバーも localhost にアクセスできますが、それはデータセンター内の彼ら自身のマシンです。 一方、あなたの Next.js は家庭用ルーターや NAT、場合によっては企業 VPN の裏側に隠れています。

この講義で行うことは次のとおりです。

  • なぜ localhost が ChatGPT から到達不能なのかを理解する。
  • localhost:3000 から公開 URL まで cloudflared で HTTPS トンネルを設定する。
  • この URL を ChatGPT の Dev Mode に接続する。
  • ウィジェットの簡単な変更で「コード → トンネル → ChatGPT」の経路を検証し、典型的な落とし穴を確認する。

ここから次の2つの単純な事実が導かれます。

  1. ChatGPT は、あなたのノート PC がどこにあるかを知りません。
  2. 仮に知っていたとしても、直接アクセスすることはできません。受信接続は閉じられています。

さらに、ChatGPT は基本的に公開された HTTPS エンドポイント(入口)にしかアクセスしません。 適切なドメインと TLS 証明書が必要です。セキュリティ上の理由から、OpenAI のサーバーは暗号化なしの任意の HTTP アドレスへはアクセスしません。 そのため、有効な証明書を持つ HTTPS ドメインが必要になります。単に http://自分の外部 IP:3000 を公開に向けて転送するだけではダメです。

したがって、必要なのは仲介役です。つまり次のようなサービスです。

  1. インターネット上で適切な HTTPS ドメインを持っている。
  2. そのドメインからあなたの localhost:3000 へ安全にリクエストを中継できる。

これが HTTPS トンネルです。

2. HTTPS トンネルとは何か:直感的モデル

難しい言葉を脇に置けば、トンネルとは、一時的(または恒久的)な公開 URL を与え、そこに来たリクエストをあなたのローカルポートへ転送するサービスです。 ネットワーク用語で言えば、クラウドに対して発信接続を維持するリバースプロキシサーバーのようなものです。

直感的なたとえ:あなたは閉じたドア(家庭用ルーター)の内側にいます。トンネルは外で「手紙はこちら」という札を持つ配達員で、裏口から時々あなたの部屋に入り、手紙を手渡してくれます。

リクエストの経路はおおむね次のようになります。

sequenceDiagram
    participant ChatGPT as ChatGPT (クラウド)
    participant Tunnel as HTTPS トンネル
(Cloudflare / ngrok) participant Dev as あなたの dev サーバー
(localhost:3000) ChatGPT->>Tunnel: HTTPS リクエスト https://xyz.trycloudflare.com へ Tunnel->>Dev: HTTP リクエスト http://localhost:3000 へ Dev-->>Tunnel: Next.js のレスポンス Tunnel-->>ChatGPT: HTTPS レスポンス

ここでの要点は次のとおりです。

第一に、トンネルサービスへの接続を開始するのはあなたです。 ユーティリティ(cloudflaredngrok など)が自らクラウドへの発信接続を確立します。 これは NAT やファイアウォールの背後でもほぼ常に許可されています。

第二に、トンネルサービスは有効な証明書付きの HTTPS ドメインをあなたに提供します。自分で自己署名の TLS を立てる必要はありません。

第三に、ChatGPT から見ると、あなたの App は HTTPS ドメインを持つ通常のウェブサービスに見えます。背後でトラフィックが誰かのノート PC に転送されているとは知りません。

3. トンネルの種類と本講座での選択

この種の用途には、ウェブ開発のエコシステムにいくつかの人気ツールがあります。

  • ngrok — 古典的存在。長らく「ローカルを外に見せる」ためのデファクトスタンダードでした。
  • Cloudflare Tunnelcloudflared)— Cloudflare のモダンで無料なソリューション。登録なしでも *.trycloudflare.com のドメインが得られます。希望すれば自分のドメインを割り当てることも可能。
  • LocalTunnel — 最小限のマジック。npm パッケージとして提供され、https://something.loca.lt のような一時的な HTTPS URL を発行します。

どれも本質的には同じ課題を解決します。ローカルサーバーに ChatGPT が利用できる公開 HTTPS ドメインを与えることです。

本講座では焦点を絞るため、「メイン」のツールとして Cloudflare Tunnel(ユーティリティは cloudflaredを採用します。理由はシンプルで、クイックトンネルに登録不要、ちゃんとした HTTPS が得られ、1 コマンドで簡単に起動できるからです。

すでに ngrok のファンでも問題ありません。コマンドは少し異なりますが、概念はまったく同じです。 ngrok http 3000 を使うだけで、 cloudflaredtunnel --url http://localhost:3000 に相当します。

わかりやすくするため、各ツールを小さな表にまとめます。

ツール 登録は必要? URL 形式 主な長所 主な短所
Cloudflare Tunnel 不要
https://*.trycloudflare.com
すぐに開始、正当な HTTPS 起動のたびに URL が変わる
ngrok 必要
https://*.ngrok.app
豊富なドキュメントとエコシステム 無料プランでは URL も変わる
LocalTunnel 不要
https://*.loca.lt
npm で導入、最小限のマジック ドメインが不安定、機能が少ない

この講義では、Cloudflare Tunnel の「クイックな使い捨てトンネル」に焦点を当てます。 これで Dev Mode の ChatGPT とあなたの Next.js を「仲良く」させるには十分です。

4. ローカルの Next.js が動いているか確認

トンネルで外に出す前に、ローカルサーバーが本当に動いていることを確認する必要があります。 さもないと、実は Next.js が起動していないのにトンネルをデバッグする羽目になります。

標準的な手順をおさらいします。

# Apps SDK テンプレートのあるプロジェクトルートで
npm install      # まだの場合
npm run dev      # Next.js の dev サーバーを起動

既定では、Next.js 16 は http://localhost:3000 で立ち上がります(ポートが空いていれば)。 ターミナルには次のような表示が出るはずです。

ready - started server on 0.0.0.0:3000, url: http://localhost:3000

ブラウザで http://localhost:3000 を開き、テンプレートのページが表示されることを確認してください。 ここがあなたの「ローカル実験室」です。ここで何か問題がある(ビルドエラー、TypeScript の警告、ポート競合など)場合は、 まずそれを直してからトンネルに進みましょう。

5. Cloudflare Tunnel を起動:localhost から公開 HTTPS へ

いよいよ本番です。インターネット上の誰でも(ChatGPT を含む)あなたの Next.js を HTTPS URL で開けるようにします。

cloudflared のインストール

インストール方法は OS によって異なります。macOS なら Homebrew が最も簡単です。

brew install cloudflare/cloudflare/cloudflared

Windows と Linux では、Cloudflare のドキュメントに従ってバイナリをダウンロードするかパッケージマネージャーを使います (リンクはこのモジュールの追加資料にあります)。

インストール確認は次のコマンドで行えます。

cloudflared --version

もしコマンドが見つからなければ、PATH を確認するかターミナルを再起動してください。

クイックな使い捨てトンネル

今の目標は最小限の動作するトンネルです。アカウント、独自ドメイン、複雑な設定は不要です。 cloudflared には quick tunnel モードがあり、 trycloudflare.com ドメインの URL を発行してくれます。

npm run dev を実行中の状態で、別のターミナルから次を実行します。

cloudflared tunnel --url http://localhost:3000

覚えておくべきシンプルなルール:外側は HTTPS、内側は HTTPcloudflared は外側に HTTPS ドメインを発行しますが、 あなたの localhost:3000 へは通常の HTTP でアクセスします。

短いログの後、次のような行が表示されます。

INF +-------------------------------------------------------------+
INF |  Your quick Tunnel has been created!                        |
INF |  https://giftgenius-1234.trycloudflare.com                  |
INF +-------------------------------------------------------------+

この https://giftgenius-1234.trycloudflare.com が、あなたのローカルアプリの新しい公開アドレスです。 トンネルはこのドメインで受けた HTTPS リクエストを http://localhost:3000 へ転送します。

重要な注意点がいくつかあります。

第一に、cloudflared を実行中のターミナルは開いたままにしておく必要があります(トンネルが必要な間)。 これを閉じる(または Ctrl+C を押す)とトンネルは落ち、URL は使えなくなります。

第二に、quick tunnel を起動するたびに URL は新しくなる可能性があります。学習用の開発では問題ありません。 このモジュールの目的は、あなたのローカル Next.js に ChatGPT がアクセスできる適当な HTTPS アドレスを提供することだからです。 ただし、そのため ChatGPT の Dev Mode 側で URL を更新する必要がある場合があります。 モジュール 7 ではトンネルの話に戻り、URL が変わらない安定した開発用ドメインを設定します。

通常のサイトとしてトンネルを確認

ChatGPT に接続する前に、インターネットから本当に開けるかを確認しましょう。

  1. 発行された https://...trycloudflare.com をブラウザで開きます。
  2. http://localhost:3000 と同じ UI が見えるはずです。
  3. npm run dev を実行しているコンソールに新しいリクエストが表示され、Next.js が外部からのアクセスに応答していることがわかります。

ページが開かない、またはエラーになる場合は、まず次を確認してください。

  • npm run dev が起動しているか。
  • トンネル起動時のローカル URL が正しいか(http://localhost:3000https:// ではなく、ポートは 3000)。
  • 発信接続が何かにブロックされていないか(厳格な企業ネットワークでは稀にあります)。

6. この URL を ChatGPT Dev Mode に渡す

これで次のチェーンを結びつける準備が整いました。

ChatGPT(クラウド) → あなたの HTTPS トンネル → ローカルの Next.js

Dev Mode の UI は前の講義で見ましたね。今回は理論上ではなく、 実際の HTTPS URL を使って同じ操作を行います。

ChatGPT 側の一般的な手順は次のとおりです。

まずブラウザで ChatGPT を開き、開発者向けのセクション(たとえば「Developer」「Apps」「My apps」など。UI の更新で名前が変わる場合があります)に移動します。

新しいアプリを作成するか、既存の開発用アプリを編集します(すでに作成済みであれば)。

App の URL を入力するフィールドには、トンネルのルートアドレスを指定します。例:

https://giftgenius-1234.trycloudflare.com/mcp

入口ポイントは /route/mcp.ts です。ChatGPT は接続時にここから始め、必要な情報を取得します。 テンプレートの README に複数アプリのときの別パス等が書いてある場合もありますが、今はトンネルのルート URL + /mcp を使う想定で構いません。

アプリの設定を保存します。このタイミングで ChatGPT はトンネル経由であなたのアプリにいくつかのリクエストを送ります。

  • App のマニフェスト(メタデータ、ツールなど)を取得。
  • MCP エンドポイントの到達性をチェック。
  • すべての tools とリソースの一覧を取得。
  • すべてのウィジェットの HTML コードをキャッシュする(!)

すべて問題なければ、あなたのアプリが Dev Apps の一覧に表示されます。もし何か壊れている(マニフェストが無効、サーバーが応答しない、トンネルが落ちた等)場合、ChatGPT は「App unavailable」のようなエラーを表示します。

重要:この同じトンネルの HTTPS URL を ChatGPT はツール呼び出し(MCP)にも、ウィジェットや静的ファイルの読み込みにも使います。次のセクションでこの 2 つの役割を分けて見ていきます。

7. リクエストの流れ:トンネルの 2 つの役割

ChatGPT がこの URL で何をしているのかを明確に理解することが重要です。 Apps SDK のアーキテクチャには主に 2 つの入口があります。MCP エンドポイントと UI ウィジェットです。

簡略化するとチェーンは次のようになります。

flowchart LR
    ChatGPT["ChatGPT(モデル)"] 
    subgraph Internet
        Tunnel[HTTPS トンネル
giftgenius-1234.trycloudflare.com] end Local["Next.js dev サーバー http://localhost:3000"] ChatGPT -- HTTP(S) リクエスト /mcp へ --> Tunnel ChatGPT -- iframe の読み込み /widget --> Tunnel Tunnel --> Local

トンネルには実質 2 つの主要な役割があります。

  • 役割 1: MCP エンドポイント(ツール)。 モデルがツール(tool)を呼び出すとき、同じトンネルのドメインにある MCP エンドポイントへ HTTP POST を送ります (テンプレートでは Next.js の app/mcp/route.ts が該当します)。
  • 役割 2: UI ウィジェットと静的配信。 モデルがウィジェットを表示するとき、あなたの URL(通常は /widget やマニフェストに指定したもの)を iframe で埋め込み、読み込みは同じくトンネル経由です。

この意味でトンネルは「何か一つ専用」ではなく、あなたのローカル App への単一の入口です。UI、MCP、静的配信のすべてが同じ公開 HTTPS ドメインを通ります。

8. 実践:チェーン「コード → トンネル → ChatGPT」を検証

本当に動いているか、図がきれいなだけではないかを確かめるため、最小の実践シナリオを試しましょう。

まず、npm run dev を起動し、 http://localhost:3000 がブラウザで開けることを確認します。

次に、cloudflaredtunnel --url http://localhost:3000 を実行して公開 HTTPS URL を取得します。 別のブラウザ、あるいは別デバイス(たとえばスマホのモバイル回線)で開いてみてください。リクエストが本当にインターネットを経由している(あなたのマシン内だけで完結していない)ことを確認できます。

それから ChatGPT を開き、Dev Mode に移動して、あなたの App がこの URL に接続されていることを確認します。 ChatGPT のコンポーザーで App を選び、対話を開始し、ウィジェットが挿入されて UI を読み込めるかを見てください。

確かにあなたのコードであることを目に見える形で確認するため、ウィジェットの何かとても簡単な箇所、例えば見出しを変更してみましょう。

// app/widget/page.tsx (例)
'use client';

export default function GiftGeniusWidget() {
  return <h1>GiftGenius トンネル経由 🚇</h1>;
}

ファイルを保存したら:

  1. Next.js の fast refresh が完了するのを待ち、
  2. ChatGPT のアプリを追加したセクションに戻って refresh(再読み込み)します。
  3. ChatGPT でその App のセッションを開く/更新します。
  4. ウィジェットの表示を依頼する新しいプロンプトを送ります。
  5. 新しい見出しテキストが ChatGPT 内に表示されていることを確認します。

これが小さな真実の瞬間です。あなたは自分のマシン上のコードを変更し、その変更がトンネルを通じて ChatGPT のクラウド UI に反映されました。

9. セキュリティについて少し:何を外部公開しているのか

どんなトンネルもおもちゃではなく、実際の公開入口です。 この学習用シナリオでは、localhost:3000(Next.js アプリが動作している)だけを中継します。 次の条件を満たす限り、比較的安全です。

  • このポートを他の用途に使っていない。
  • データベースの管理画面や phpMyAdmin、その他のデモサービスを混在させた「なんでも入りアプリ」を動かしていない。

実務的な注意点をいくつか。

トンネルは開発用のツールであり、本番運用ではありません。意図的に Dev Mode で使い、 実ユーザー向けや決済受付のために使うわけではありません。

同じポート(3000)で管理パネルやパスワードなしの DB などを起動しないようにしてください。 トンネルを通すと、そのポートで応答するものはすべて外部から見えるようになります。

trycloudflare.com の URL をむやみに配布しないでください。学習プロジェクト中に誰かが積極的にスキャンする確率は低いかもしれませんが、 「開発サーバーのリンクをどこにでも貼る」という習慣は本番で痛い目にあいます。

後で Vercel や本番環境の話に進んだら、安定したドメインと本番相当のセキュリティを持つ正規のホスティングを使い、 トンネルはあくまで開発専用のツールに留めます。

10. ローカル実行とトンネルでよくあるミス

ここまででローカルの Next.js、稼働中の HTTPS トンネル、ChatGPT の Dev Mode 接続が揃いました。最後に、最初の反復で誰もがやりがちなミスと、その迅速な切り分け方法をいくつか紹介します。

エラー No.1: http://localhost:3000 をそのまま ChatGPT で使おうとする。
初心者がこの URL を Dev Mode の設定にコピペして、ChatGPT が App に到達できないと不思議がることがあります。 繰り返しますが、localhost はリクエストを出す主体にとっての「自分自身」です。ChatGPT にとっては OpenAI のサーバーであり、あなたのノート PC ではありません。 この場合、あなたのマシンには一切リクエストが届かないため、特別なログも見えません。

エラー No.2: 存在しない/間違ったポートにトンネルを張る。
よくあるシナリオ:以前は npm run dev3000 番ポートで動かしていたが、すでにサーバーは落ちている。それなのに別ターミナルで慣れで cloudflared tunnel --url http://localhost:3000 を実行してしまう。Cloudflare はきれいな HTTPS ドメインをくれるが、開くとエラー。 診断は簡単で、ローカルサーバーが動いていません。必ず先にブラウザで http://localhost:3000 を確認し、 その後でトンネルを有効にしましょう。

エラー No.3: トンネル起動時に http://https:// を取り違える。
トンネルは外側の HTTPS を提供しますが、ローカルサーバーには HTTP で接続する必要があります(例: http://localhost:3000)。https://localhost:3000 を指定すると、 内部の TLS 周りでおかしなエラーになったり、単に到達不能になったりします。覚えておくべきルールは「外は HTTPS、内は HTTP」です。

エラー No.4: ChatGPT でテスト中にトンネルのターミナルを閉じてしまう。
これも定番です。すべて設定して ChatGPT で App が動いていたのに、うっかり cloudflared のターミナルを閉じてしまう。10 分後に戻ると ChatGPT で「App unavailable」。 原因は単純で、App の設定に URL は残っているものの、トンネル自体が止まっているのです。覚えておきましょう。 Dev Mode で App をテストしている間は、トンネルを動かしたターミナルを常に起動したままにすること。

エラー No.5: トンネル再起動後の新しい URL を自覚なく使ってしまう。
quick tunnel モードでは、Cloudflare は起動のたびに新しい *.trycloudflare.com を発行します。 cloudflared を止めて再起動したのに、ChatGPT には古い URL のまま設定していると、 ChatGPT は正直にそちらへアクセスし、タイムアウトや別サービスに当たるなどの事象が起きます。トンネルの URL が変わったら、 必ず Dev Mode の設定を更新してください。後ほど、URL 追いかけから解放される安定した開発用ドメインの作り方も説明します。

エラー No.6: 余計または危険なサービスを同じポートに同居させる。
利便性のために 3000 番ポートで Next.js だけでなく、 デバッグパネルや認証なしの実験用 API なども動かしてしまうことがあります。そのポートをトンネルで公開すると、 それらもすべて外部から見えるようになります。学習プロジェクトでは深刻な事態にならないかもしれませんが、 実案件では情報漏えい・侵入のリスクを大きく高めます。常に意識してください。トンネルに指定したポートで応答するものはすべてインターネットに面します。

コメント
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION