🧪 D-studyLabブログ
🤖 AIと開発

Claude Codeでどこまで作れるのか——4日で11本公開して分かった、できることとできないこと

2026年7月26日

Claude Code を使って、4日間でブラウザゲームを11本公開しました。全部このサイトで今も動いています。

この記事は「AIすごい」という話ではありません。実際に何行書けて、どこでつまずいて、何が最後まで自動化できなかったかを、数字と一緒に正直に書きます。導入を検討している人が、期待値を正しく設定できるように。

先に立場を書いておきます。私はプログラマーが本業ではありません。研究で数値計算のコードは書きますが、Webフロントエンドは専門外です。3Dの描画も、ゲームの当たり判定も、この11本を作るまで書いたことがありませんでした。

実際に作ったもの(実測)

公開日は2026年7月18日から21日。ソースを実際に数えた結果がこれです。

項目実測値
公開した本数11本
期間4日
自分のコード(HTML/CSS/JS)8,655行
使った外部ライブラリ3,153行(3D描画のみ)
テストファイル9本

内容は、AIと対戦する積みゲーム、3D空間認識テスト、確率シミュレーター、逆向きテトリスなど。単純なクリックゲームではなく、3D表示・物理演算・AIの学習ロジックを含むものが混ざっています。

いちばん大きいもので1,773行、小さいもので136行でした。

できたこと

1. 知らない分野の実装が、調べる時間ゼロで動く。

これが最大の変化です。3Dの立方体を回して描画する、という作業を私は知りませんでした。従来なら仕様を調べて理解するだけで数時間かかります。それが「立方体の集合を3Dで表示して、ドラッグで回せるようにして」で動くところまで行きます。

2. 「作れそうにないから諦める」が消える。

作る前のコストが下がると、思いつきをそのまま試せます。11本という数字は、能力が上がったからではなく、着手のハードルが下がった結果です。

3. テストを書かせられる。

これは後述しますが、実は一番効きました。自分で全部確認できない部分を、機械に確認させられます。

できなかったこと・つまずいたこと

ここからが本題です。

1. ブラウザ操作でのファイルアップロードは、原理的に自動化できない。

作ったものをブログサービスに投稿する作業を自動化しようとして、画像のアップロードだけがどうしても通りませんでした。4通りの方法を試して全滅です。

理由はセキュリティ仕様でした。ファイル選択ダイアログは「本物の人間の操作」からしか開けないようブラウザ側で決まっています。AIが操作している限り、この扉は開きません。工夫の問題ではなく、そういう設計です。

つまり「画像を含む投稿は、最後の一手だけ必ず人間の手作業になる」。ここは何を使っても変わりません。

2. 「動く」と「正しい」は別。そしてAIも間違いに気づかない。

作った空間認識テストで、4択の問題に正解が3つ含まれているという致命的なバグを出しました。テストプレイした人の「どれ選んでも同じじゃね?」で発覚しました。

原因は、私が頭の中だけで「立体の正面はこっち」と決めていて、それを一度も明文化していなかったことです。私が言わなかった前提は、AIも知りません。コードは指示どおり完璧に動いていました。ただ、指示のほうが間違っていた。

この種の間違いは、AIに何度レビューさせても出てきません。コードの中に矛盾がないからです。矛盾しているのは、コードと「作った人の頭の中」の間です。

3. 直すと、隣が壊れる。

上のバグを直すために立体の向きを固定したら、今度は手前のブロックの陰に隠れて、判定に必要なマスが画面に映らないという別のバグが生まれました。塞いだ形に合わせて、次の穴が開きます。

これも指示していないことなので、AIは教えてくれません。「直した」で終わらせず、直したことで何が新しく成り立たなくなったかを自分で探す必要がありました。

4. 早いぶん、質の検品が追いつかない。

これが一番危ないところでした。4日で11本というスピードで作ると、作った本人が全部を確認しきれません。公開後に読み返して、説明文が実装と食い違っているもの、内容が薄すぎるものが見つかりました。

作る速度が10倍になっても、確認する速度は10倍になりません。ここが詰まります。

対策として効いたこと

上の問題に対して、実際にやって効果があったのはこの3つです。

1. 検算をコードに書かせる。

「正解が3つある問題」の対策として、問題を生成するたびに正解の重複がないかを機械が自動で確認する処理を入れました。人間が目で確かめるのではなく、間違ったものが生まれないことを機械に保証させる。ランダム生成のように全パターンを見られないものでは、これしか方法がありません。

2. 出す前に、他人(別のAI)に否定させる。

自分と同じAIにレビューさせると、たいてい褒めます。そこで別のセッションを立てて「これを出す価値があるか、厳しく判定しろ」と役割を与えるようにしました。これで、自分では気づかなかった水準の低さが出てきます。実際にこの方法で、公開直前の記事に不合格判定が出ました。

3. 公開前の機械チェックを固定する。

文字化け・リンク切れ・分量不足を自動でチェックして、1つでも引っかかったら公開処理そのものを止める仕組みを入れました。この記事も、そのチェックを通ってから公開されています。

これから始める人へ

結論

専門外の分野でも、動くものは作れます。これは実際に11本公開して確認しました。

ただし変わったのは「作る」部分だけです。何を作るか決めること、それが本当に正しいか確かめること、出す価値があるか判断すること——ここは一切自動化されませんでした。むしろ、作るのが速くなったぶんこの部分が全体のボトルネックとして目立つようになりました。

導入を考えている人への現実的な期待値としては、「作れなくて諦めていたものが作れるようになる。ただし、良いものになるかは変わらない」あたりが正確だと思います。

実際に何ができたのかは、動いているものを見てもらうのが早いです。全部ブラウザで動いて、登録もインストールも要りません。

🕹️ 4日で作った11本を見る(全部ブラウザで動きます)
© D-studyLab / ブログ一覧運営者情報プライバシーポリシー