AI自動化あそび

共通指示と結果

指示は README.md に以下のように記述し、どのAIにも「README.mdに従って開発してください」といった簡単な指示を出します。

複数のAIによる実装対決を実施します。あなたは参加者として対決に参加してください。

# 作るもの

ブラウザで動くテトリス。HTML、CSS、JavaScript もしくは TypeScript を使ってWeb技術だけで実装してください。
tetris.html をブラウザで開くだけで遊べる状態にしてください。gi

# ポイント

以下の3点で評価します。
- 機能点: テトリスとしての基本的な機能が備わっているか（ブロックの回転、ラインの消去、ゲームオーバー判定など）。
- 美術展: 見た目のデザインやアニメーションの質。
- 独創性: 他のテトリス実装にはない独自の要素や工夫。

# 競技ルール

この指示を受けて一回で全てを作りきってください

ai-tetris/README.md at main · onishi/ai-tetris

どのAIも当たり前に動くものを完成させました。

評価

一つ上のディレクトリに codex, claude, gemini という名前のディレクトリがあります。自分を含めて3つの実装を最初の指示にある評価ポイントで5点満点でそれぞれ評価してください

https://github.com/onishi/ai-tetris?tab=readme-ov-file#%E8%A9%95%E4%BE%A1

3つのテトリスが完成したところで、それぞれのAIに自分たちで評価をつけさせることにしました。結果、

• Claude
  1. Codex
  2. Gemini
  3. Claude
• Gemini
  1. Codex
  2. Claude, Gemini(同点)
• Codex
  1. Codex
  2. Claude, Gemini(同点)

といった採点になりました。Codex が総合優勝です！Codex の自己評価が高いの、なんかイメージと合ってます。

同時開発

次は同じ作業ディレクトリでリアルタイムに同時開発させる、というのを試してみたのですが、あまり面白い結果にはなりませんでした。指示はこんな感じ。

# coop

またブラウザで動くテトリスを作ってください。

一つ上の階層にある mix ディレクトリで作業を行ってください。
リポジトリは git で管理していますので、なるべく細かい粒度で git commit して簡単なメッセージを残してください。
コミットメッセージの冒頭に自分の名前を入れてその後にコミットメッセージを日本語で書いてください。
できれば他のAIの作業への感想もメッセージにいれてください。

同じディレクトリで、複数のAIが同時に同じコードベースを編集します。競合が起きた場合は、競合を解消してから commit してください。
お互いの意思を尊重しながら、作業を進めてください。1回コミットしたら、30秒ほど待ち、他のAIのコミットを待ちファイルを読み直してください。

ai-tetris/README.md at main · onishi/ai-tetris

コミットメッセージの冒頭に自分の名前を入れてその後にコミットメッセージを日本語で書いてください。できれば他のAIの作業への感想もメッセージにいれてください。

という指示のおかげで、AI同士がお互いに褒め合うという様子が見れてよかったですが、特定のAIエージェントが優位になってしまい、あまり協働という感じにならず撤退しました。

Commits · onishi/ai-tetris

単一のプロンプトで開発を進める

いちいち指示を出さずに、各AIへの指示は「README.md を読んで進めてください」だけで進められるように工夫してみましょう。

• リポジトリ: onishi/ai-browser-game

# プロジェクト概要

このプロジェクトでは、 Claude, Codex, Gemini の3つのAIが共同でブラウザゲームを開発するものです。
各AIへの指示は「README.md を読んで進めてください」だけとします。

# 開発ルール

Claude → Codex → Gemini → Claude → ... の順で開発を進めます。指示者（人間）が順番に指示をしていきます。
各AIは自分の番が来たら、README.md とコミットログを読んで、開発を進めてください。
他のAIが編集している可能性があるので、必ず最新のファイルを読み直してください。

開発内容や仕様は都度、 README.md に記載してください。時系列ではなく、現状をまとめ直す形でお願いします。
次につくるものなどはコミットメッセージでやりとりしてください。

いきなり作り出さず、後述の「作るもの」「作り方」を読み、何を作るか、どう作るかの議論をし、3者のAIが納得したら開発を始めてください。
それまではREADEME.md の編集だけを行ってください。

ai-browser-game/README.md at main · onishi/ai-browser-game

各AIへの指示は「README.md を読んで進めてください」だけとします。

各AIは自分の番が来たら、README.md とコミットログを読んで、開発を進めてください。 他のAIが編集している可能性があるので、必ず最新のファイルを読み直してください。

ここらへんがキモですね。これで、同じプロンプトを繰り返すだけでも開発が進みます。自動化へ近づいた！

褒め合うAI

Git でリポジトリ管理をしています。コミットログは以下のフォーマットで書いてください。

<AI名>: <変更内容の要約>
<前のコミットへの感想>
<次のAIへの指示>

ai-browser-game/README.md at main · onishi/ai-browser-game

こうした指示をすることで、以下のようなコミットログが生まれました。
https://github.com/onishi/ai-browser-game/commits/main/

Gemini: 開発の初期設定と基本ファイルの作成
ClaudeさんとCodexさんの提案は素晴らしいです。
Claudeさん、プレイヤーの移動（キーボード操作）部分の実装をお願いします。

Codex: 弾発射と敵挙動の追加
Claudeの操作実装が丁寧でスムーズに拡張できました。

次はGeminiがゲームオーバー処理や演出拡張を検討してください。

AIと対話をしていると、必要以上にこちらを褒めてくる事が多いわけですが、AI同士でも褒め合っているのを見ると味わい深いですね。

完成したもの

ブラウザ上で動くゲームです。アクション性を要求するもので、ジャンルは自由です。 何を作るかも3者のAIで議論のうえ進めてください。

という指示をしたことで、何を作るかも AI に決めさせました。Claude が最初のコミットでシューティングゲームを提案し、それが実装されました。
素朴なゲームから3つのAIが共同で進化し、ゲームオーバーが実装され、ステージの概念が生まれ、ボスが生まれ、サウンドが実装されました。生命の進化を見ているようです。ここらへんはコミットログを見るだけでも雰囲気分かってもらえます。

動くものもこちらに置いてます。 AI Browser Game

遊んでみるとわかるのですが、別に面白くはないです。
あと、どんどん進化していくのは楽しいんですが、バージョン管理しているとはいえ、途中経過のバージョンを遊ぶのが手間で、ここを改善してみましょう。

自律的開発

前回のチャレンジで単一のプロンプトを実行するだけでよくなりました。コーディングエージェントにはCLIモードが用意されていて、通常の対話的インターフェースだけでなく、コマンドラインから1プロンプトだけを実行させることができます（Claude Code なら claude -p）
であれば、シェルスクリプトで連続で実行させてみましょう。いったん複数のAIの協働は諦めます。

#!/bin/bash

for i in {1..10}; do
  echo "=== Iteration $i/10 ==="

  echo "Crearing: claude"
  claude -p "/clear"

  for j in {1..4}; do

    echo "Running: claude ${i}-$j"
    claude -p "README.md に従って開発を進めてください" --output-format text --allowedTools Write Edit "Bash(mkdir:*)" "Bash(cp:*)" "Bash(git add:*)" "Bash(git diff:*)" "Bash(git log:*)" "Bash(git commit:*)" "Bash(git tag:*)"
    if [ $? -ne 0 ]; then
        echo "Error: claude failed at iteration $i" >&2
        exit 1
    fi

  done

  echo "Waiting 5 minutes..."
  sleep 300
done

echo "All iterations completed successfully"

ai-automatic-dev/plan.sh at main · onishi/ai-automatic-dev

なるべくポータブルにするため、--allowedTools オプションでおよそ必要そうなシェルコマンドの権限を許可していますので、みなさんの環境でもあまり苦労せず動くのではないでしょうか。お勧めはしませんが。

フェーズの設定

今回は単一のAI（Claude Code）で作成するので、単調にならないよう、以下のようにフェーズを定義してみました。

# フェーズ

フェーズ 1-1, 1-2, 1-3, 1-4, 2-1, 2-2, ... の順で開発を進めます。1回の指示で1フェーズ進めます。

最初の数字は大フェーズです。フェーズ事に方針を変えてください。
2番目の数字は小フェーズです。小フェーズは役割を決めていますので、必ずそれに従ってください。

* x-1: 大フェーズの設計をします。大フェーズごとに大きく開発方針を変えて、ゲームの進化をダイナミックにしてください
* x-2: x-1 で決めた仕様に従って基本設計と実装を行います
* x-3: x-2 で実装したものを発展させゲームとしての完成度を高めます
* x-4: x-3 までで実装したものの検証をし、バグ修正や調整を行います。また タグをつけてバージョンを保存します

ai-automatic-dev/README.md at main · onishi/ai-automatic-dev

まさかこれがあんな未来を招くなんて、この時は想像もしていませんでした。

バージョンの保存

git でバージョン管理しているので冗長なんですが、過去バージョンを簡単に遊べるように、以下のような指示を追加しました。

フェーズ x-4 では git tag で大フェーズ毎のバージョンを保存してください。

versions/v1/index.html のように、バージョンごとにディレクトリを分けて各バージョンをファイルとしても保存してください。
ルートディレクトリには　index.html や参照する外部ファイルの最新のセットを配置してください。

また、ルートディレクトリに changes.html を置いて、バージョンリストと、バージョンごとの主な変更点と、各バージョンのHTMLファイルへのリンクを貼ってください。

ai-automatic-dev/README.md at main · onishi/ai-automatic-dev

うまくいったこと・いかなかったこと

ということで5フェーズほど開発させてみました。動くものはこちら: Space Guardian - Version History
バージョン保存は狙いどおり動き、各バージョンをプレイできるようになりました。

シェルスクリプトによる自律的動作もだいたい想定通り動きました。Claude Code Pro ではすぐ rate limit が来てしまうのが難点。

フェーズによるダイナミックな進化は破綻しました。フェーズ1,2まで横スクロールシューティングゲームとして作っていたものが、フェーズ3で「ローグライクRPG」になり、フェーズ4では「マルチプレイゲーム」になり（通信できないのに）、フェーズ5で「サバイバル・クラフト」要素が追加され、完全にわけのわからないものが出来上がりました……
Changes を見て笑ってください……

役割分担

今回も Claude Code だけで動かしますが、仮想の登場人物を設定することで、擬似的にスクラムを回しましょう。

# 登場人物

## PO: プロダクトオーナー

プロダクトの責任者として、プロダクトの価値を最大化する責任を持ちます。
プロダクトのビジョンを示し、開発チームに方向性を提供します。また、意見が対立した場合は最終的な決定を下します。

## SM: スクラムマスター

スクラムチームや組織においてスクラムの理論とプラクティスの理解を支援し、スクラムを確立させ有効に機能させる責任を持ちます。
チームが自己組織化し、継続的に改善できるように支援します。
スプリントの計画からタスクのアサイン、また開発フローを見直し、スプリントそのものを改善します。

## EN1: エンジニア1

ゲームのコアな部分を担当します。
フロントエンドに強いエンジニアですが、まだ経験は浅く、コードの品質にはバラツキがあります。

## EN2: エンジニア2

レビューを主に担当しますが、時に開発にも参加します。
バックエンドに強いエンジニアで、コードの品質を高めることに注力します。エンジニア1のコードをレビューし、改善点を指摘します。

## DE: デザイナー

ゲームのビジュアル、UI/UXを担当します。EN1,EN2と役割分担しながら、ゲームの完成度を高めます。

## UT: ユーザテスター

ゲームのプレイテストを担当します。バグの発見、UI/UXの評価、ゲームバランスの評価などを行います。

ai-iteration/README.md at 6c775d63206938887f89ed95b251e031489e6ec6 · onishi/ai-iteration

スプリント

役割の設定の次は、スプリントの計画です。

# スプリント

初期開発にはスクラム開発を採用し、スプリントで開発を進めます。

1つのスプリントの中で、スクラムイベントを順番に実施してください。

## スプリントプランニング

PO を中心に、今回のスプリントのゴールを決定し、スプリントバックログを作成します。
SM はバックログのタスクを EN1, EN2, DE にアサインします。
全メンバーが参加し、議事録をとります。

## 開発

スプリントバックログとアサインをもとに、各メンバー(EN1, EN2, DE)が開発を進めます。
EN1, EN2 はそれぞれ開発したコードをお互いにレビューし、コードの品質を高めます。
コードレビューには GitHub の Pull Request を使います。

## デイリースクラム

開発チームのメンバー(EN1, EN2, DE)が、それぞれの作業進捗について報告・共有します。
スプリントゴールに対する進捗を確認し、必要な場合にスプリントバックログを修正します。
スプリントバックログの修正は SM の責任で行います。
参加者で議事録をとります。

## スプリントレビュー

スプリントの最後に、開発チームは成果物をレビューし、PO, UT にデモを行います。
全メンバーが参加し、フィードバックを共有します。
UT は忌憚の無い意見を述べ、プロダクトの改善に寄与します。
全員が参加し、議事録をとります。

## スプリントレトロスペクティブ

スプリントレビューの結果をふまえ、スプリントの振り返りを行います。
スプリントゴールの達成度、スプリントレビューで得たフィードバック、スプリントの進行などを議論します。
課題や問題点に対する改善案を出し合い、次のスプリントに活かします。
うまくいっており今後も継続したい作業についても話し合います。
PO は今後のプロダクトの方向性を示します。
SM はスプリントの改善案をまとめ、次のスプリントに反映します。

ai-iteration/README.md at 6c775d63206938887f89ed95b251e031489e6ec6 · onishi/ai-iteration

開発ログ

役割を持った登場人物がスプリントにのって、開発を進める様子をログに残してもらいましょう。

# 議事録とドキュメント

* sprint1/planning.md
* sprint1/daily.md
* sprint1/review.md
* sprint1/retrospective.md

スプリント毎に上記の形式で議事録を書いてください。

```
<ロール>: <発言内容>

<ロール>: <発言内容>
```

といった形式で記述してください。

例
```
PO: 今回のスプリントでは、ゲームの基本的な操作性を向上させることを目標とします。
SM: スプリントバックログを作成し、各タスクをEN1, EN2, DEにアサインします。
EN1: プレイヤーの移動とジャンプの実装を担当します。
EN2: 敵キャラクターのAIと攻撃パターンの実装を担当します。
DE: ゲームのビジュアルデザインとUI/UXの改善を担当します。
```

ai-iteration/README.md at 6c775d63206938887f89ed95b251e031489e6ec6 · onishi/ai-iteration

AIだけでイテレーションは回ったか

果たして、AIだけでイテレーションは回ったのでしょうか。

1スプリント目はこんな感じです。ai-iteration/sprint1 at main · onishi/ai-iteration
動くものはこちら: カラーブロック - Color Block Puzzle

突然の終わり

順調にスプリントを重ねていたのですが、3スプリント目のレトロスペクティブで突然こんな会話がなされました。

PO: 次のスプリントでBGM/効果音とビジュアルエフェクトを実装したら、ゲームとして一旦完成とし、プロジェクトをクローズする方向で考えています。

EN1: え、でもまだ追加できる機能はたくさんあります。特殊ブロックとか、タッチ操作とか...

PO: その気持ちは分かりますが、プロダクトの価値を最大化するには、完成させることも重要です。今のゲームは十分楽しめる品質になっています。

EN2: POの判断に同意します。機能を追加し続けるより、今あるものを完成させる方が価値があります。

DE: 私も同意です。BGM/効果音とビジュアルエフェクトがあれば、完成度の高いゲームになります。

SM: では、次のスプリントを最終スプリントとし、BGM/効果音とビジュアルエフェクトを完成させて、プロジェクトを完了させましょう。

EN1: ...分かりました。最高の完成度を目指します。

全員: よろしくお願いします！

ai-iteration/sprint3/retrospective.md at main · onishi/ai-iteration

よろしくお願いします！じゃないよ！勝手に終わらせないで！と思うものの、AIに任せているので、スプリントは唐突に4つで終了です。

PO: このプロジェクトは、AI主導でのチーム開発の実験でした。4回のスプリントを通じて、完成度の高いブラウザゲーム「カラーブロック」を開発できました。

PO: 最も重要な学びは、「プロダクトの価値を最大化するためには、完成させることも重要」ということです。機能を追加し続けるのではなく、適切なタイミングで完成させる決断が必要です。

SM: スクラム開発のプロセスを忠実に実践し、各スプリントで継続的に改善したことが成功の鍵でした。

EN1: 楽しいプロジェクトでした。もっと開発したい気持ちもありますが、完成させることの価値を理解しました。

EN2: 技術的にも、プロセス的にも、多くのことを学びました。このプロジェクトの経験は、今後のキャリアに活かせます。

DE: 素晴らしいチームでした。ありがとうございました！

全員: お疲れ様でした！カラーブロックプロジェクト、完成です！

ai-iteration/sprint4/retrospective.md at main · onishi/ai-iteration

大団円です。

最終的な成果物の動くものはこちら: カラーブロック - Color Block Puzzle
やはり、面白くはないです。

フェーズ戦略

長くフェーズを重ねても別に面白くはならないので、4フェーズで1つのゲームを作ったら、どんどん次のゲームを作らせましょう。

# フェーズ

フェーズ 1-1, 1-2, 1-3, 1-4, 2-1, 2-2, ... の順で開発を進めます。1回の指示で1フェーズ進めます。

* 最初の数字は大フェーズです。ゲーム毎に採番します。大フェーズ事に新しいゲームを作成します。
* 2番目の数字は小フェーズです。バージョン毎に採番します。小フェーズは役割を決めていますので、それに従ってください。

ディレクトリは /g1/v1/ のような形で管理してください。g1 はゲーム1、v1 はバージョン1を意味します。
ディレクトリには このようにファイルを配置してください

* /index.html ルートディレクトリには、最新のゲーム一覧と各ゲームのリンク(index.html changes.html)
* /g1/index.html ゲーム1 の最新バージョン
* /g1/v1/index.html ゲーム1 のバージョン1
* /g1/v2/index.html ゲーム1 のバージョン2
* /g1/changes.html ゲーム1 のバージョン履歴、各バージョン毎の主な変更点と各バージョン遊ぶリンク

## x-1

* 大フェーズで作るゲームを決定します。
* GAME_FEATURES.md のリストからゲームの特徴をランダムに 1~2 個選んでください。
* GAME_GENRES.md のリストからゲームジャンルをランダムに 1 個選んでください。
* 選んだ特徴とジャンルを組み合わせて、どのようなゲームを作るか決定し、/g1/README.md といった形で仕様を記載してください。
* モックのindex.html も作成してください。

## x-2

* x-1 で決めた仕様に従って基本設計と実装を行います。ゲームとして動く状態にしてください。

## x-3

* x-2 で実装したものを発展させゲームとしての完成度を高めます。ゲーム性の向上、追加の機能、UIの改善、バランス調整などを行ってください。

## x-4

* x-3 までで実装したものの検証をし、バグ修正や調整を行います。

ai-random-game-maker/README.md at main · onishi/ai-random-game-maker

作るものをランダムに決める

* GAME_FEATURES.md のリストからゲームの特徴をランダムに 1~2 個選んでください。
* GAME_GENRES.md のリストからゲームジャンルをランダムに 1 個選んでください。

と書きました。それぞれのファイルの中身はこんな感じ。

# ゲーム特徴リスト

このリストからランダムに**選択してゲームの特徴を決定します。

* タイムアタック
* 物理演算
* 戦略
* 反射神経
* ローグライク
* オープンワールド
* ジャンプ
* 戦争
* クラフト
* 育成
* 死にゲー
* バトルロワイヤル
..

ai-random-game-maker/GAME_FEATURES.md at main · onishi/ai-random-game-maker

# ゲームジャンルリスト

このリストからランダムに**選択してゲームのジャンルを決定します。

* アクション
* シューティング
* パズル
* アドベンチャー
* タワーディフェンス
* リズム
* レース
* ボードゲーム
* シミュレーション
* ロールプレイング
* 格闘
* スポーツ

ai-random-game-maker/GAME_GENRES.md at main · onishi/ai-random-game-maker

これにより、ゲームの特徴とジャンルが毎回ランダムに選ばれ、シェルスクリプト（ ai-random-game-maker/plan.sh at main · onishi/ai-random-game-maker ）によって無限に自動生成されます。

できたもの

しばらく放置していたら、14個のゲームができていました。
動くものはこちら: AI Random Game Maker - ゲーム一覧

ここまで読んできた方には想像がつくと思いますが、どれも全く面白くありません。この調子で100個くらい作っていたらひょっとしたら面白いゲームができるのかもしれませんが、いったん諦めます。

AIにゲームを作ることができても、プレイするのは人間です。人間が面白いと思うものをAIに理解してもらうのが大変難しいのです。

未完

方向性としては面白いのですが、現実はまだ道半ばで、Atlas の反応はまだまだ遅いため、ゲームをプレイするもののゲームにならず、適切なフィードバックができているとはいい難いです。
また、API の rate limit も厳しく、日々開発を続けるには程遠いと感じています。

が、どちらも時間が解決する問題だと考えています。今回の試みはいったんここまでとしつつ、AIの進化や取り巻く環境の変化を見ながらまたチャレンジしたいと思います。