公開前のAIコードレビューで何を見る？秘密情報・保存・通信の点検手順

AIの点検結果を「保証」にしない理由

生成AIにコードを渡して「問題がないか確認して」と聞くと、多くの場合は問題点を列挙してくれます。しかし、AIは自分が生成したコードの全文脈を保持していない場合があり、会話セッションをまたぐと前提条件を忘れることもあります。また、「問題なし」という返答は「私が確認した範囲では重大なパターンが見当たらなかった」という意味であり、網羅的なセキュリティ検査とは異なります。

そのため、AIによる点検は「最初に全文を高速で読む補助」と位置づけ、指摘された箇所を人間が実際のコードで確認することが重要です。AIが何も指摘しなかった箇所も、次のセクションで示す3つの観点から自分で目を通す習慣をつけると、見落としが減ります。

1. 秘密情報の埋め込みを探す

最も深刻な見落としの一つが、APIキーやアクセストークンなどの秘密情報がコードにそのまま書かれているケースです。OWASP（Open Worldwide Application Security Project）の資料によれば、開発者が機密情報をソースコードや設定ファイルに直接書き込むことは、セキュリティインシデントの主要な原因のひとつとして記録されています。

特に注意すべきパターンを以下に示します。AIに点検を依頼する際も、この観点を明示して渡すと回答の精度が上がります。

• const API_KEY = "sk-..." のように文字列リテラルでキーが書かれている
• firebase.initializeApp({ apiKey: "..." }) などの初期化コードに実際の値が入っている
• fetch("https://api.example.com/data?token=実際のトークン") のようにURLに秘密情報が入っている
• コメント行に「// 本番用キー: xxxxxx」のような形で残っている

AIへの点検依頼文の例として、「このコードの中に、APIキー・アクセストークン・パスワード・秘密キーが文字列として直接埋め込まれている箇所があれば、行番号と変数名を挙げてください。その値が本物でなくてもパターンとして指摘してください」というように、探してほしいものを具体的に指定します。

ブラウザのみで動くゲームでも、スコアランキングなど外部サービスに接続している場合は秘密情報が含まれます。「このゲームはサーバーに繋がない」と思っていても、開発中に追加した計測・ログ機能が残っている場合があるので確認します。

秘密情報が見つかった場合は、公開後に修正しても遅いケースがあります。OWASPのDevSecOpsガイドラインは、コードをリポジトリに一度でも公開してしまうと、削除後もウェブ上にインデックスが残る可能性があると指摘しています。ゲームをZIPにまとめてアップロードする前に、この点検を必ず行います。

2. ブラウザストレージの使い方を確認する

ゲームの進行状況や設定をブラウザに保存するとき、localStorage や sessionStorage を使うことがあります。これらはJavaScriptから自由に読み書きできるため、クロスサイトスクリプティング（XSS）と呼ばれる攻撃が成立した場合、同じページで動く悪意あるスクリプトに内容を読み取られるリスクがあります。

ゲームのセーブデータとして使う分には多くの場合問題になりませんが、以下の内容をストレージに保存しているコードがあれば、AIに指摘してもらったうえで人間が判断します。

• パスワードや認証トークン（ログイン用の文字列）
• 個人を特定できる情報（メールアドレス・本名・電話番号など）
• 外部APIにそのまま渡す形で使うアクセスキー

セーブデータとしてスコア・ステージ進行・設定値（音量など）を保存することは一般的な方法です。これらに個人情報が混在していないかを確認します。たとえば、プレイヤー名の入力欄があるゲームで、入力値をそのままストレージに保存している場合、プレイヤー自身が意図せず本名を入力することもあります。入力文字数の制限や、保存前の確認メッセージを加えるかどうかは、ゲームの設計に合わせて判断します。

AIへの点検依頼では「localStorage.setItem および sessionStorage.setItem が呼ばれている箇所を全部挙げ、保存している値の種類と、そこに個人情報や認証情報が含まれる可能性があるかを教えてください」という形が具体的です。

3. 外部との通信を把握する

ゲームが外部サーバーと通信する場合、どこに何を送っているかを把握しておく必要があります。生成AIが書いたコードには、デバッグ用や機能検証用に一時的に追加した通信処理が残っていることがあります。

点検で確認する主な観点を以下に整理します。

• 送信先のURL：fetch() や XMLHttpRequest、WebSocket などが接続しているURLをリストアップし、それぞれが既知の必要な接続先かどうかを確認します。
• 送信内容：リクエストボディやクエリパラメータに、プレイヤーが入力したテキストやブラウザ情報がそのまま含まれていないかを確認します。
• HTTPS：外部通信が http:// で始まる場合、通信内容が暗号化されません。本番環境で使う接続先は https:// を使います。
• サードパーティのスクリプト：広告・分析・フォントなど外部スクリプトを読み込んでいる場合、そのスクリプトも通信を行います。どのスクリプトを読み込んでいるかを把握します。

AIへの点検文の例として「このコードで fetch、XMLHttpRequest、WebSocket、および外部スクリプトの読み込み（script src）が発生する箇所を全部挙げてください。それぞれの接続先URLと、送信されるデータの概要を教えてください」と指定します。AIの回答を受け取ったら、リストに見知らぬURLが含まれていないかを人間が確認します。

AIに渡す点検依頼のひな型

以下は、ゲームコードを公開する前にAIに送る点検依頼のひな型です。コード全文を貼り付けた後、この依頼文を添えます。AIの返答は保証ではなく一次フィルターです。指摘された箇所は必ず自分でコードを確認します。

以下のゲームコードを公開前にセキュリティの観点で点検してください。

確認してほしい3点：
1. APIキー・アクセストークン・パスワード・秘密キーが文字列リテラルとして
   コードに直接書かれている箇所があれば、行番号と変数名を挙げてください。
   実際の値でなくてもパターンとして疑われる部分を含めてください。

2. localStorage.setItem / sessionStorage.setItem が呼ばれている箇所を
   すべて挙げ、保存している内容の種類と、個人情報・認証情報が含まれる
   可能性があるかを教えてください。

3. fetch / XMLHttpRequest / WebSocket および外部スクリプト読み込み
   （script src）が発生する箇所を全部挙げてください。接続先URLと送信される
   データの概要を添えてください。

指摘は「問題なし」も含めて各項目ごとに答えてください。
確認の保証ではなく一次点検として使います。

コードを貼り付ける際は、実際の秘密情報（本番のAPIキーなど）が含まれていないことを先に確認してから貼ります。AIサービスの入力欄に秘密情報を貼り付けること自体が漏洩につながります。

点検後、公開に進む前の最終確認

AIによる点検と人間の確認が終わったら、公開前の最終チェックとして次の手順を踏みます。

1. ゲームフォルダ全体をテキストエディタまたは検索ツールで開き、"password"・"secret"・"token"・"key" などのキーワードで全文検索する。
2. ブラウザの開発者ツール（DevTools）のNetworkタブでゲームを動かし、実際に発生しているリクエストのURLと内容を目で確認する。
3. Applicationタブ（Storageタブ）でlocalStorageに保存されている内容を確認し、不要なデータが残っていないかをチェックする。
4. 公開するファイルのリストを最終確認し、.env ファイル・設定ファイル・README などに秘密情報が入っていないかを確認する。

これらを一通り確認したうえで、ゲームのHTMLファイルまたはZIPをアップロードします。点検を通じて見つかった問題は、その場で修正してから再点検するのが確実です。「軽微だから後で直す」と考えて公開すると、修正のタイミングを見失いやすくなります。

AIが生成するコードの品質は、指示の明確さとレビューの丁寧さに比例します。この点検フローを一度手順として書き出しておくと、次のゲームを作るときに迷いなく使えます。点検済みのコードを確認できたら、アソバースのスタジオへのアップロードに進みます。