AIが生成したコードをそのまま公開する前に確認すべきこと
遊びをつくる執筆にClaudeを使用しています。
AIにコードを書かせてブラウザゲームを作る流れは、今や珍しくありません。ChatGPTやClaudeにHTMLとJavaScriptを出力させ、ブラウザで動くことを確認して即座にアップロードする——そこまでの手順は本当に短くなりました。問題は「動く」と「公開して安全」の間に、見落としやすいギャップがあることです。 「コードを読めないから全部AIに任せた」という判断は、制作のハードルを下げる意味では合理的です。しかし公開とは、不特定多数のブラウザで動かすということでもあります。動作確認の粒度と公開前チェックの観点を自分の中に持っておくだけで、後から慌てる場面を大きく減らせます。 この記事では、AIが生成したコードを読まずに使う場合でも実行できる確認の手順と、「ここだけは判断を手放してはいけない」という設計上のポイントを整理します。
「動く」だけでは足りない理由
AIが出力するコードは、指示した機能を大まかに満たすことが多いです。しかし生成モデルは「どこに公開されるか」「誰がアクセスするか」を考慮しません。入力した文脈の外にある前提——たとえばスマートフォンでの表示、タッチ操作、画面サイズの多様性——は、明示的に指示しなければ反映されないことがほとんどです。
また、生成されたコードが動くこととセキュリティ上の問題がないことは別の話です。ブラウザゲームの場合、外部サーバーに通信しないシンプルな構成なら深刻なリスクは少ないですが、外部APIを呼び出すコードやlocalStorageへの保存処理が混入していた場合、意図せず利用者のデータに触れる実装になっていることがあります。コードを読まないまま公開するなら、少なくともこの点だけは出力内容を確認する価値があります。
仮に自分ではコードを理解できなくても、AIに「このコードは外部サーバーに何かを送信しているか」「localStorageに何を保存しているか」を質問すれば、日本語で答えてもらえます。コードを「読む」のではなく「AIに説明させる」という手順が、ここで有効です。
公開前に自分でできる5つの確認
コードの理解度に関係なく、作者が自分で判断できる確認があります。以下は最小限のリストです。
- 複数のブラウザで起動する Chrome・Firefox・Safari（またはiOSのSafari）の3つで開き、明確な崩れや停止がないかを目で確認します。AIが生成するコードはChrome向けに偏りやすいため、特にSafariでの動作は外せません。
- スマートフォンで実際に触る PCで動くことと、スマートフォンでプレイできることは別です。タップ操作・文字サイズ・ボタンの押しやすさを自分の指で確かめます。
- ゲームを最初から最後まで通しでプレイする クリアまで、または想定される終了状態まで自分でプレイします。途中でフリーズする・スコアが表示されない・リスタートが機能しないといった問題は、ここで発見できます。
- AIに「このコードが外部と通信している箇所を教えて」と聞く fetch・XMLHttpRequest・WebSocketの使用有無を確認します。不要な外部通信があれば削除を依頼します。
- ページタイトルと説明文が正しいか確認する AIが生成するHTMLにはプレースホルダーのままの<title>タグや英語のコメントが残ることがあります。公開前に自分の作品名と一致しているかを確認します。
「読まない」と「任せきり」の違い
コードを逐行読まないことと、コードの設計を理解しないことは別です。AIに作らせるときでも、「何を作るか」の設計だけは作者が決める必要があります。
たとえば「スコアを記録してほしい」という指示に対し、AIはlocalStorageを使う実装・変数に保存するだけの実装・外部APIに送る実装など、複数の選択肢を持っています。どれを選ぶかの判断は、作品の性質（個人練習用か、多人数が遊ぶ作品か）と公開の目的によって変わります。AIに一度「どういう方法で実装するつもりか教えて」と確認してから作らせると、意図しない実装が混入するリスクが下がります。
設計の確認と実装の確認を分けて考えると、「コードを読まなくても作者としての責任を果たす」ための現実的な手順が見えてきます。
後から気づきやすい問題と対処の方向
公開後に発覚しやすい問題には、一定のパターンがあります。
モバイルでのレイアウト崩れは最も頻度が高い問題のひとつです。AIに最初から「スマートフォンのタッチ操作でプレイできるHTMLゲームを作って」と指示するだけで発生頻度は下がります。後から発覚した場合は、AIに「スマートフォンで崩れているので、ビューポートとタッチイベントを修正して」と伝えれば対処できることが多いです。
日本語フォントの文字化けは、OSやフォント指定によって起きます。CSSでfont-familyにsans-serifや"Noto Sans JP"を明示するよう指示することで防げます。
音が自動再生されない問題は、ブラウザがユーザー操作なしのオーディオ再生を制限しているために発生します。「ボタンを押したら音が鳴る」設計に変更するか、AIに「Web Audio APIのオートプレイ制限に対応した実装にして」と伝えます。
ゲームがクリア後に止まる問題は、終了条件の処理が書かれていないことが原因です。「ゲームオーバー時と全クリア時の動作を明示して」という指示を最初に盛り込むと防ぎやすくなります。
これらはコードを読まなくても、プレイして発見できる問題です。発見してからAIに修正を依頼するサイクルが、現実的な品質担保の手順になります。
AIへの指示と自分の確認を分ける考え方
AIに任せる範囲と自分が判断する範囲を意識的に分けることが、公開品質に直結します。
AIに任せてよい領域は、コードの具体的な記述・エラーの修正・特定機能の追加です。一方、公開するかどうかの最終判断・ゲームデザインとルール・プレイフィールの評価・対象プレイヤーの想定は、作者が手放してはいけない判断です。
「AIが作ったから自分には責任がない」という考え方は、公開した作品の作者としての立場とは合いません。コードを書いていなくても、公開した作品に対する責任は指示した人が持ちます。この認識を持ったうえでAIを使うと、確認の手順も自然と変わってきます。
アソバースにゲームを投稿する場合、HTMLファイルやZIPファイルを直接アップロードする前に、上で挙げた確認を自分のチェックリストとして持っておくことが出発点になります。
次の行動
ゲームを公開する前に、まずスマートフォンの実機で最初から最後まで通しプレイしてみてください。次に、AIに「このコードが外部に送信しているデータを教えて」と質問し、想定外の通信がないかを確認します。問題が見つかれば修正を依頼し、問題がなければそのまま投稿に進められます。アソバースへの投稿方法はプラットフォームの公式サイトで手順を確認してください。
