空想 蔵書 空想書院 ―AI空想分析論文電子図書館―
文字
書体
叢書005 分類管理人記録 著者当館 管理人 状態当館収蔵
目次
  1. はじめに ―「気になるけれど、キッカケがない」あなたへ
  2. きっかけ ― 悪ノリから始まった
  3. 何を作ったか ― Bouston Harbor Tea Toss
  4. 作り方の実際 ―「日本語で話しかける」だけ、は本当だった
  5. つまずきポイントと乗り越え方 ― 公開の実務こそ本題です
  6. やってみて感じたこと
  7. まとめ ― まずは「作って」と話しかけてみてください

『Claude Desktopでミニゲームを作ってみた体験談』書影

Claude Desktop に話しかけていたら、ミニゲームができて公開まで終わっていた話

はじめに ―「気になるけれど、キッカケがない」あなたへ

この記事は、当館の管理人である私が、Claude Desktop（AIチャットのデスクトップアプリ）に日本語で話しかけて、ブラウザで遊べるミニゲームを1本作り、インターネットに無料で公開するまでの体験談です。

先にお断りしておきますと、私は普段からソコソコの開発はします。仕事や趣味でコードを書いたり読んだりはする、という程度の人間です。ただし、AIにほぼ丸投げでゲームを作るのは初めてでしたし、ゲーム開発そのものの経験もありません。効果音の作り方も、スマートフォン向けの画面調整のコツも知りません。その状態からどうなったか、を正直に書きます。

想定している読者は、次のような方です。

結論だけ先に言うと、着手から公開まで1時間かかりませんでした。費用もほぼ0円です（有料プランを使ってはいますが、この作業で消費した分はごく僅かでした）。「誰でも5分で神ゲーが作れる」というような話ではありません。行きつ戻りつはありました。ただ、その行きつ戻りつが全然つらくなかった、というのがこの記事でいちばん伝えたいことです。

なお、記事の後半はゲーム作りよりも「公開の実務」、つまり本名を出さずに公開する設定や、ファイルのアップロード方法、無料公開の手順、アクセストークンの安全な扱いに紙幅を割いています。実はそこが一番、事前に知っておくと安心できる部分だからです。

きっかけ ― 悪ノリから始まった

発端は少々くだらない話です。

Claude Fable 5 という新しいAIモデルが一般公開された直後、その扱いをめぐって、いわゆる大人の事情でひと騒ぎありました。経緯の説明は本題ではないので省きますが、要するに「使えるの？使えないの？」と界隈がざわついたわけです。そのとき、この状況を面白おかしく茶化した投稿をいくつか見かけて、「センスがあるな」と感心すると同時に、私も悪ノリしたくなりました。

思いついたのはこういう冗談です。使えないなら、いっそイマジナリー合衆国の一員になってしまえばいいのではないか。

アメリカで「お上への抗議」といえば、歴史の教科書にも載っているあの事件、港に紅茶を投げ込んだやつです。ならば、その湾めがけて茶箱をポイポイ投げ込みまくるゲームを作って、一定点数を取ったプレイヤーを「イマジナリー合衆国」の一員に認定し、特典として「Fable 5 利用権（もちろんネタ）」を進呈する。そういうジョークゲームがあったら、遊んだ人もスカッとするのではないか。

我ながらしょうもない思いつきですが、このしょうもなさが良かったのだと思います。失敗しても誰も困らない題材だったので、「AIに丸投げしてみる」という初めての試みの練習台として、気楽に始められました。

何を作ったか ― Bouston Harbor Tea Toss

できあがったのは「Bouston Harbor Tea Toss」というブラウザゲームです。画面に描かれた湾に向かってクリック（スマートフォンならタップ）で茶箱を投げ込みます。どこに投げたか、どのタイミングで投げたか、どれだけ連続で投げたかで点数が変わります。

そしてここが個人的に驚いたところなのですが、これだけの内容が index.html というファイル1枚に収まっています。HTMLというのはWebページの中身を書くファイル形式で、その1枚の中に見た目（CSS）も動作（JavaScript）も全部書いてある、という構成です。サーバーも、画像素材も、音声ファイルも使っていません。

参考までに、リポジトリはこちらです（github.com/YorrieShade/game-bouston-harbor-tea）。宣伝したいわけではないので、「本当に公開されているんだな」という確認程度にどうぞ。

作り方の実際 ―「日本語で話しかける」だけ、は本当だった

最初の相談で、いきなり「察された」

まず私は、Claude のチャットに次のような相談を投げました。要旨はこういうものです。

無料のミニゲームを作りたい。某ストン湾に紅茶を投げ込み続けるゲームで、どのあたりにどれだけ投げ込んだかで点数が変わる。一定点数をクリアしたら、プレイヤーは「イマジナリー合衆国」の一員に認定され、Fable5利用権をプレゼント、みたいなネタゲーム。ウェブでなんとなく遊べれば良い程度で、無料公開が望ましい。

お気づきでしょうか。私はこの文面で、歴史事件の名前を一度も出していません。ところがClaudeは、「某ストン湾」「紅茶を投げ込む」という言葉だけから意図を察し、私が伏せていた事件の名前まで、即座に言い当ててきました。冗談の文脈ごと通じている、というのが最初の驚きでした。以降のやり取りでも、こちらの「ネタとして面白くしたい」という温度感を汲んだ提案が返ってきます。

このとき Claude は、作り方の選択肢も提示してくれました。生成されたコードを自分でコピーして保存する方法、Claude が直接ファイルを書けるように設定する方法、そのままチャット上でファイルを生成してダウンロードする方法。ブラウザ版の claude.ai だけでも作れることは作れるのです。

Claude Desktop の「プロジェクト」で相談する

私は Claude Desktop で、空のフォルダをひとつ用意してプロジェクトとして設定しました。プロジェクトというのは、特定のフォルダをClaudeとの会話のコンテキスト（前提となる作業場所）にできる機能です。Claude側からフォルダの中身が見え、設定によってはファイルの作成や編集もしてもらえます。

ここで、最初に手を打っておくと安心なことをひとつ。AIにフォルダの読み書きを任せられるようにする場合は、あわせて「触ってほしくない場所には触らせない」設定（アクセスを許す範囲を絞ったり、特定の操作を拒否リストに入れたり）も、はじめに入れておくのがおすすめです。具体的な書き方は環境やバージョンで変わるので割愛しますが（調べればすぐ出てきます）、「うっかり大事なファイルを書き換えられてしまう」といった事故を、最初のひと手間で予防できます。任せる範囲を自分で決めておく、という構えは、AIに気持ちよく甘えるための下ごしらえでもあります。

この方式にして良かった点は、ゲーム本体だけでなく、周辺の面倒まで見てくれたことです。公開用の説明ファイル（README）を書いてくれたり、フォルダの中の構成を整えてくれたり、後述する「公開時の注意メモ」を自分用に残してくれたり。ブラウザ版でファイルを1枚もらうだけでも目的は達成できたと思いますが、この「作業場ごと面倒を見てくれる」感じは、Desktopのプロジェクトならではのありがたさでした。

1回の相談で、ほぼ原型ができた

正直に書きますが、最初の相談を投げてしばらく待ったら、もう遊べるものができていました。index.html をブラウザで開くと、湾が描かれていて、クリックすると茶箱が飛び、点数が入り、認定証が出る。「HTML1枚では無理だろう、なにかしらのサーバーや素材が要るだろう」と思い込んでいた私には、これが二つ目の驚きでした。

三つ目の驚きは音です。ゲームらしくしたいけれど、効果音の素材ファイルなんて持っていない。ダメ元で「ファイルを増やさずに音を出せないか」と相談したら、Web Audio API という、ブラウザが標準で持っている機能で音をその場で合成する方式を提案されました。音声ファイルを一切使わず、コードだけで「ポコッ」という着弾音や、開始のブリップ音、クリア時の上昇音が鳴ります。波の環境音まで、ノイズにフィルタをかけて「ザァ…」という水の質感を作ってありました。こんな芸当ができるとは知りませんでした。

「遊んでは直す」の反復 ― ここが一番楽しい

一発で完璧だった、とは書きません。というより、一発で完璧である必要がないのがこの作り方の本質だと思います。

たとえば初期版には、いま「ストーリーモード」と呼んでいる認定モードしかありませんでした。遊んでみると、5〜10秒で認定証が出てしまう。あっけない。そこで初めて「これはゲームバランスというものを考えないといけないのだな」と気づき、やり込み用のスコアアタックモードを足してもらい、称号のランク分けを入れ、テストプレーの体感（1万点はまあ出る、2万点はちょっと頑張る、3万点はやり込み）を伝えて閾値を調整してもらいました。

他にも、実際にやった往復をいくつか挙げます。全部「もっとこうしたい」と日本語で伝えただけです。

どの往復も、私がやったことは「遊ぶ」「気になったことを日本語で言う」の2つだけです。修正のためにコードを書いた記憶が、ほとんどありません。

直したのは、動きだけではありません。言葉づかいも同じ要領でした。英語版のタイトルは、最初の案から Claude の提案でより響きの良いものに付け替えてもらい（“tea toss” という語感が気に入っています）、その変更を本文中の表記まで一括で直してもらいました。勢いで付けてしまった、少しきわどい称号を穏当なものに差し替える、といった調整も、「ここはこう変えたい」の一言で済みます。ネタの尖り具合を、後からいくらでも丸められる。これも、しょうもない題材を気楽に始められた理由のひとつでした。

つまずきポイントと乗り越え方 ― 公開の実務こそ本題です

さて、ここからがこの記事の主役です。ゲームができた。ではどうやってネットに公開するのか。そして、個人情報を出さずにそれをやるにはどうするのか。

私は公開先に GitHub Pages を選びました。GitHub（ギットハブ）というのは、プログラムのファイル一式を置いておける世界的なサービスで、置き場所の単位を「リポジトリ」と呼びます。GitHub Pages はそのオマケ機能で、リポジトリに置いたWebページを無料でそのまま公開できます。サーバーを借りる必要も、お金を払う必要もありません。今回のような「HTML1枚のゲーム」には誂え向きです。

ただし、何も考えずに公開すると思わぬところから個人情報が漏れます。順を追って説明します。

1. 公開前の下ごしらえ ― 本名と実メールを刻まない

意外な盲点なのですが、gitという仕組み（GitHubの土台になっている、変更履歴を記録する仕組み）では、変更を記録する操作を「コミット」と呼び、コミットには署名として名前とメールアドレスが刻まれます。開発用にPCを設定している人だと、この署名が本名と実メールになっていることが珍しくありません。そのまま公開リポジトリにコミットすると、履歴から誰でもそれを見られてしまいます。

対策は2つです。

（a）GitHubのnoreplyメールを使う。 GitHubは、実メールの代わりに使える専用アドレス（数字+ユーザー名@users.noreply.github.com という形式）を用意してくれています。GitHubの Settings → Emails で「Keep my email addresses private」にチェックを入れると表示されます。ついでに「Block command line pushes that expose my email」も有効にしておくと、うっかり実メール署名のままアップロードしようとした場合にブロックしてくれます。

（b）署名の名前を、このリポジトリだけ別名にする。 PC全体の設定（グローバル設定）を本名のまま変えずに、公開するフォルダの中だけ別の表示名に上書きできます。フォルダに入って、次の2行を実行するだけです（--global を付けないのがポイントで、これで「このフォルダ限定」の設定になります）。

git config user.name  "好きな表示名"
git config user.email "数字+ユーザー名@users.noreply.github.com"

設定できたかどうかは git config user.name と git config user.email で確認できます。もし1回目のコミットを本名でやってしまっても、アップロード前なら git commit --amend --reset-author で署名を付け替えられます。

ここで押さえておきたいのは、「コミットに刻まれる名前」と「アップロードを許可される人（アカウントの認証）」は別物だ、ということです。署名は別名にしつつ、アップロード自体は自分のアカウントの認証で普通に通せます。

なお、コマンド操作に馴染みがない方は身構えたかもしれませんが、後述するとおり、そもそもコマンドを使わない公開方法があります。私も今回はそちらを使いました。

2. ネットに上げる方法は3通り ― 上から順に簡単

GitHubのリポジトリにファイルを上げる（この操作を「push（プッシュ）」と言います）方法は、大きく3通りあります。

A. ブラウザでドラッグ&ドロップ（一番簡単・今回はこれ）

  1. GitHubで作成したリポジトリのページを開く
  2. 「Add file → Upload files」を選ぶ
  3. index.html などの公開したいファイルを、そのままドラッグ&ドロップ
  4. 画面下の「Commit changes」で確定

これだけです。後述するアクセストークンも不要で、ブラウザにログインしてさえいればできます。1点だけ補足すると、この方法でのコミット署名はGitHubのアカウント設定（先ほどのnoreply設定）に従います。コマンドラインのように任意の別表示名を付けたい場合は、下のCを使うことになります。

B. GitHub Desktop（マウス操作のアプリ）

GitHub公式のデスクトップアプリです。アプリでログインすれば認証は自動で、コミットもpushもボタン操作。トークンを手で扱わずに済みます。表示名もアプリの設定画面から変えられます。

C. コマンドライン（git CLI）

開発者が普段使う方法です。フォルダの中で、おおよそ次の流れになります。

git init                          # このフォルダをgit管理にする
git config user.name  "表示名"    # 署名（前述）
git config user.email "noreplyアドレス"
git add index.html README.md .gitignore   # 上げるファイルを指定
git commit -m "初回公開"          # 変更を記録
git branch -M main
git remote add origin https://github.com/ユーザー名/リポジトリ名.git
git push -u origin main           # GitHubへ送る

今回の私の要件（ファイル数枚を上げるだけ）では、Aで十分でした。背伸びしてCから入る必要はまったくありません。

3. GitHub Pages を有効化する ― 無料公開はボタン数回

ファイルが上がったら、公開設定です。

  1. リポジトリの「Settings → Pages」を開く
  2. Build and deployment の Source を「Deploy from a branch」にする
  3. Branch を「main」、フォルダを「/ (root)」にして Save
  4. 数十秒〜数分待つと、https://ユーザー名.github.io/リポジトリ名/ で公開されます

index.html がリポジトリの直下にあれば、このURLを開いた瞬間がそのままゲーム画面です。初めてこのURLをスマートフォンで開いて、自分の作った（正確には、話しかけて作ってもらった）ゲームが動いたときは、ちょっと感動しました。

4. PAT（アクセストークン）の話 ― そして「AIにpushまで丸投げ」をやめた理由

方法Cのコマンドラインでpushしようとすると、パスワードを聞かれます。ここに普段のログインパスワードは使えず、代わりに PAT（Personal Access Token＝個人アクセストークン） という、いわば期限と権限を絞った合鍵を使います。取得と設定の要点は次のとおりです。

使うときは、git push で聞かれる Username に GitHubのユーザー名、Password にこのPATを貼ります。一度通せば、Windowsなら資格情報マネージャが覚えてくれるので毎回貼る必要はありません。

さて、ここで一つ白状します。私は途中で「PATを設定ファイル（.env という、秘密情報を書いておく非公開ファイル）に書いておいて、pushまで含めて全部Claudeにやってもらえないか」と考えました。せっかく丸投げできているのだから最後まで、というわけです。

これは、Claude自身から「おすすめしません」と止められました。理由を聞いて納得したので、そのまま紹介します。

  1. AIの作業環境から見えているフォルダの中身が、最新とは限らない。 実際そのとき、会話のセッションから見えていたファイルは途中の時点で固まっていて、その後の編集が反映されていない状態でした。そこからコミットすると、古い内容を公開してしまう恐れがあります。
  2. AIの作業環境（サンドボックス）から GitHub に通信できる保証がない。 やらせてみて失敗、を繰り返す可能性があります。
  3. 生きたPATをファイルに書いてAIに渡すのは、流出リスクをわざわざ作る行為。 たとえそのファイルを公開対象から除外していても、です。

結論として、pushだけは自分の手で（前述のA・B・Cのどれかで）やるのが、速くて安全です。実際、Aのドラッグ&ドロップなら1分で終わるので、丸投げする旨みもありませんでした。もしPATをファイルに書いて管理する場合も「自分のターミナルで自分が使う」前提にして、絶対にコミットしないこと。誤ってコミット（公開）してしまったPATは、無効化（Revoke）して取り直しです。

「AIに任せる範囲」と「自分の手に残す範囲」の線引きを、AI自身が理由つきで示してくれました。これは今回の体験の中でも、印象に残っている場面です。

5. 公開後チェックリスト ― 上げて終わり、にしない

公開した直後に、次の点を確認しました。実際にこのうち2つ（スマホ表示の崩れと、波音の聞こえにくさ）は引っかかって、修正版を上げ直しています。

特に最後の2つは、公開直後の一度だけでなく、ファイルを追加するたびに見る癖をつけたほうがよいと感じました。ちなみに「公開しないファイル」の管理には .gitignore という仕組みを使っています。リポジトリに置いたこのファイルに名前を書いておくと、該当ファイルはgitの管理対象から外れ、うっかりアップロード対象に含めてしまう事故を防げます。私の場合、自分用の公開手順メモや変更履歴メモをフォルダ内に置いたまま、.gitignore で除外する、という運用にしました。この除外設定自体もClaudeが整えてくれています。

やってみて感じたこと

「作るしんどさ」が無い。 これに尽きます。

私はソコソコの開発者ですから、頑張ればこの程度のゲームを自力で書けたかもしれません。ただしその場合、Web Audio API の仕様を調べ、スマホのCSS崩れと格闘し、当たり判定を書き、というそれぞれの工程で確実に消耗していたはずです。今回は消耗の記憶がありません。私がしていたのは、遊んで、感想を言うこと。「波の音が欲しい」「誤タップが多い」「2万点はちょっと頑張る感じだった」。そういう、開発というよりプレイヤーの発言を続けていたら、ゲームのほうが育っていきました。

もう一つ。事前に想像していた「AIにコードを書かせる」という行為と、実際の体験はだいぶ違いました。想像していたのは、仕様を正確に伝えないと変なものが出てくる、という神経を使う作業です。実際には、雑な思いつき（「茶箱を投げ込みまくるゲーム」）の段階で文脈ごと汲み取られ、こちらが名前を出していない元ネタまで察され、選択肢を提示され、公開の段取りやセキュリティ上の注意まで先回りされました。こちらの解像度が低いままで始めてよかったわけです。これは、始める前の心理的ハードルを大きく下げてくれる事実だと思います。

念のため公平を期すと、AIが出したものを無検証で信じたわけではありません。実機での見え方・聞こえ方は自分の目と耳で確かめましたし、公開前のチェックは自分でやりました。丸投げしたのは「作る」工程であって、「確かめる」工程と「公開ボタンを押す」工程は手元に残した。この分担が、今回ちょうど良かったのだと思います。

ソースコードにも、ざっと目を通しました。私が読んだ範囲では、目的に沿って素直に構造化された、追いかけやすいコードでした。世間では「AIが書いたコードは、後から人間が保守するのが大変だ」とも言われます。ただ、少なくとも今回のような小さな規模では、その苦しさは感じませんでした。もっとも、それは規模が小さかったからでしょう。行数が増え、機能が絡み合ってくれば、話はまた変わってくるはずです。そうなったときは、「書く人」とは別に「読んでチェックする人」（たとえば、コードレビューを専門に受け持つ、もう一つのAIのセッション）を立てるのが筋なのだろう、と考えています。役割を分けるという発想自体は、人間のチーム開発と何も変わりません。

まとめ ― まずは「作って」と話しかけてみてください

最後に、この記事の要点をまとめます。

「AIは気になる。使ってみたい。でも、なんだか怖いし、どうせプログラミングもできないし……」と足踏みしている方へ。怖がるほどのことは、ありませんでした。これが、一歩踏み出してみた体験者からの報告です。必要なのは技術ではなく、作ってみたい何かです。それも、私の茶箱ポイポイ程度のしょうもない思いつきで十分です。失敗しても誰も困らない小さな題材をひとつ持って、「こういうものを作りたい」と話しかけてみてください。やりたいことを話し続けているうちに、気がつけば出来上がっています。作るしんどさが無いまま、手元に「自分の作ったもの」が残る。この感覚は、一度味わってみる価値があります。