ゲームを公開する前に外すもの：APIキー・個人情報・開発用ファイル

アップロードしたファイルは誰でも読める

ブラウザでゲームを遊ぶとき、HTMLファイルやJavaScriptファイルはそのままクライアントに送られます。ゲームサイトを「ソースを表示」で開けば、コメントアウトされた文字列も含めてすべて読めます。ZIPでアップロードしたファイルも同様で、解凍したHTMLやJSの中身は公開後に誰でも取得できる状態になります。

これは仕様であり、ブラウザゲームの本質的な動作です。HTMLとJavaScriptはサーバーサイドのコードとは違い、実行のためにブラウザへ配信しなければなりません。そのため、「公開しても平気な情報しか書かない」という前提でファイルを組み立てることが、ゲームを公開するうえでの基本的な考え方になります。

問題になりやすいのは、開発中に便宜的に書き込んだ情報が整理されないまま公開ファイルに残るケースです。「どうせ自分しか使わない」と思っていた外部サービスのAPIキー、ローカルで動かすときに使ったメールアドレスやテスト用パスワード、デバッグ用に追加したコンソール出力などが、これに当たります。

APIキーは「後で外す」ではなく「最初から分ける」

外部サービスのAPIキーがソースコードに直接書かれている状態を、Googleのドキュメントは「bearer credentials」、つまり持っているだけで使える認証情報として説明しています。キーを知られた第三者が、あなたのアカウントの権限の範囲でAPIを呼び出せます。料金が発生するサービスであれば、意図せずコストを負担する可能性もあります。

Googleは公式ドキュメントで「APIキーをクライアントコードに含めず、コードリポジトリにコミットしない」と明確に述べています。環境変数やソースツリーの外にあるファイルに置くことを推奨しています。ブラウザゲームの場合、ビルドツール（ViteやWebpackなど）を使っているなら `.env` ファイルから変数として読み込み、ビルド後のファイルだけをアップロードする方法が典型的なアプローチです。

ビルドツールを使わず素のHTMLとJavaScriptで作っている場合、バンドル前の変数置換ができません。外部APIを呼び出す必要があるなら、キーをクライアント側ではなくサーバーサイドのプロキシ経由で使う設計を検討してください。どうしてもクライアント側に書く場合は、そのキーを「公開情報と同等のもの」として扱い、使用量制限やリファラー制限を設定してリスクを最小化します。

よくある混入パターンを挙げます。

• OpenAI、Gemini、Claude などの生成AIサービスの秘密キー（`sk-...` や `AIza...` で始まる文字列）
• Google Maps や Mapbox などの地図サービスのAPIキー
• Firebase の設定オブジェクト内にある `apiKey`（※ Firebase の `apiKey` はクライアント向けの識別子であり秘密情報ではありませんが、セキュリティルールの設定が不適切な場合は問題になります）
• Supabase の `service_role` キーや、DBへの直接アクセスに使う接続文字列
• コメントアウトされたまま残っているテスト用の古いキー

コメントアウトしていても、ブラウザのソース表示やZIP展開で読めます。「無効化したから平気」という判断も危険で、無効化を忘れている場合があります。外すか、プレースホルダーに置き換えるかのどちらかを選んでください。

個人情報・テスト用の認証情報

ゲームの開発中に自分のメールアドレスや本名をハードコードしていることがあります。問い合わせ先として書いた場合でも、スパムの標的になります。公開するファイルに入れる必要がある場合は、専用のゲーム用アドレスを作って使うか、フォームを経由する形にすることをすすめします。

• メールアドレス（問い合わせ先や開発者の連絡先として入れた場合）
• テスト用のユーザー名とパスワードの組み合わせ（動作確認に使った認証情報が残っているケース）
• 実名やハンドル名と紐づいたローカル環境のパス（例：`/Users/yourname/projects/game/` といった絶対パスがコードに混入していることがある）
• スコアランキング機能などを作った場合の、テスト時に登録した実際の名前やIDのデータ

ローカルパスは見落とされやすい項目です。開発ツールがエラーメッセージにフルパスを埋め込む場合があります。ビルド後のファイルを一度エディタで開き、自分のユーザー名が混入していないか確認してください。

ZIPに含めてはいけない開発用ファイル

ゲームをZIPで投稿するとき、プロジェクトフォルダをそのまま圧縮すると、公開に不要なファイルが含まれます。プレイに必要なファイルだけを選んで新しいフォルダにまとめ、そこから圧縮するのが基本です。

• .env / .env.local：APIキーやDB接続情報が入っている場合がある。絶対に含めない。
• node_modules/：依存パッケージが入った巨大なフォルダ。ゲームの実行には不要で、ファイルサイズも膨大になる。
• .git/：Gitのリポジトリ全体の履歴が含まれる。過去に削除したAPIキーが履歴に残っていることもある。
• *.log、debug.txt などのログファイル：開発時の出力やエラーが記録されており、内部構造が読める場合がある。
• TODO.md、notes.txt などのメモ：開発上の未解決問題、使用サービスのアカウント情報のメモなどが入っていることがある。
• 未使用のアセット・仮素材：ライセンスの不明な仮画像や音素材が残っていることがある。使用するアセットのみに絞る。

Viteなどのビルドツールを使っている場合、`npm run build` で生成される `dist/` フォルダの中身だけをZIP化するのが基本です。`src/` や `.env` をそのまま圧縮しないようにしてください。

公開前の確認手順：具体的なステップ

ファイルを投稿する前に、以下の順番で確認します。単体のHTMLファイルでも、ZIPでも同様に行います。

1. テキストエディタで全文検索する。対象ファイル（HTML・JS・CSS）を開き、`key`、`secret`、`token`、`password`、`@`（メールアドレス）を検索します。ヒットした箇所が本当に公開していいものか確認します。
2. ZIPの場合は中身を確認する。圧縮前に、フォルダ内の全ファイルを一覧表示して `.env`、`.git`、`node_modules` が含まれていないことを確認します。
3. ブラウザのデベロッパーツールで動作確認する。ゲームを動かしながらコンソールタブを開き、意図しないエラーメッセージやデバッグ出力がないか確認します。`console.log` に個人情報が流れていないかも見ます。
4. ネットワークタブで外部通信を確認する。リクエストの中に予期しないURLやパラメータが含まれていないか確認します。URLにAPIキーをクエリパラメータとして渡している場合、ここで見つかります。
5. 使っていた仮のAPIキーを無効化する。開発中に試しで使ったキーがあれば、各サービスの管理画面から削除または無効化します。公開ファイルから外した場合でも、念のため済ませておくと安全です。

この確認を経てから、アソバースの投稿フォームに進みます。公開ステップ3の確認画面には「ゲームの動作を確認しました。公開ファイルに秘密のキーや個人情報を含めず、作品固有のデータ利用や外部サービスについて必要な説明を掲載しています」というチェックボックスがあります。この確認を実際に行った状態でチェックを入れてください。

外部サービスを使う場合の説明

APIキーを外してゲームを安全に公開できたとしても、もう一つ確認が必要なことがあります。ゲームがプレイヤーのデータを外部のサービスへ送信する場合、その旨をゲームの画面やページ上で説明する必要があります。

たとえば、スコアをランキングサーバーへ送っている、AIサービスにプレイヤーの入力を送って応答を返している、分析ツールで行動ログを収集しているといった場合です。どのデータをどこへ送っているかをプレイヤーが把握できるようにすることは、ゲームを公開する作者としての基本的な責任になります。

ゲーム内に専用の説明画面を設けることが難しければ、投稿フォームの「遊び方」欄や、ゲームのロード画面に一文加えるだけでも実質的な説明になります。外部サービスを何も使っていない場合はこの対応は不要です。

アソバースのアカウントブリッジ（SDK）を使う場合、渡される情報はゲームごとにスコープされたランダムなプレイヤーIDのみです。メールアドレス・FirebaseのUID・JWTはゲームへ渡されません。この動作はSDKの設計によるものであり、作者が追加で外部へ送らない限り、SDKを使うだけでプレイヤーの個人情報が外部に漏れることはありません。