私は、ブラウザゲームのサイトgame.kihamda.netを運営しています。サイトの更新を続けたくて、AIにゲームの制作や改善を定期実行させることにしました。何回かに分けて作業して、完成したものから公開してくれればいい。そう考えていたのですが、待ってもゲームが出てきませんでした。
後から作業台帳と配信記録を数えてみると、2026年10月10日から20日までの11日間に、定期実行44枠の開始記録がありました。その間の本番配信は、保存された記録では確認できません。10月21日にはMineRushの改善版が配信されているので、「最後まで何も公開されなかった」という話ではありません。それでも、一日4回動く仕組みを用意して、なぜ公開までこんなにかかったのかは気になります。
調べて分かったのは、配信システムの不備だけではありませんでした。僕が指示・採用した運用ルールと、AIがそれを具体化した検査や引き継ぎの手順が、ゲームを公開するまでの工程を重くしていました。今回は、その設計も含めて振り返ります。
やりたかったこと
既存ゲームの不具合を直し、新しいゲームも作って、サイトを継続的に更新したいと思っていました。実行時刻は日本時間の1時、7時、13時、19時。一回の作業は原則30分で、終わらなければ途中の状態を保存し、次の実行で続きを進める仕組みです。
期待していたのは、企画、実装、動作確認、公開を順に進めることでした。ただ、実際に設定した仕事は、それよりかなり広いものでした。既存作品の選別、共通画面の刷新、制作技術の統一、モバイル操作、保存失敗への対応、成果物の版管理、復元手順、集客や収益の評価まで含めていました。
個別には必要そうな項目ばかりです。しかし、すべてを一度に運用へ組み込むと、最初の一作品を出すまでに何を終えればいいのかが大きくなります。僕はゲームが公開されることを期待しながら、ゲーム制作以外にも、相当な仕事を任せていました。
どう失敗したか
44枠のうち30枠が「完了」でも、本番更新は確認できなかった
まず、件数を整理します。対象は、ローカル定期実行の台帳に残っている10月10日から20日の予定枠です。手動作業や、同じ予定枠から派生した継続実行を別の定期枠として足してはいません。
| 数えたもの | 件数 | この数字が意味すること |
|---|---|---|
| 開始記録のある定期枠 | 44枠 | 11日間に一日4枠ずつ |
保存時点の状態がcompletedの枠 | 30枠 | その枠で扱った工程を完了した |
checkpointedの枠 | 8枠 | 途中経過を保存して引き継いだ |
recoveredの枠 | 6枠 | 期限超過などの後に状態を照合・復旧した |
| この44枠を実行IDに持つ途中保存イベント | 49件 | 同じ枠で複数回保存した場合も含む |
| 同期間に確認できた本番配信 | 0件 | 保存された配信記録と状態記録の範囲 |
30枠が完了しているのに、本番更新は確認できない。ここが今回のずれをよく表しています。completedはゲームの公開完了ではなく、調査、画面改修、検査、日次統合といった工程の完了でした。
なお、これはサーバーの全アクセスログを調べた結果ではありません。「あらゆる経路で公開がなかった」と証明する数字ではなく、残された台帳と配信証跡から確認できた範囲です。
作業には、ちゃんと意味のある修正もあった
何をしていたかを見ると、ゲーム本体の修正もありました。10月13日の記録では、Ice Slideのステージ8・13・15に解法がなく、別の3ステージでは目標手数が最短手数より少ないと判明しています。配置と目標手数を修正し、20ステージをブラウザでクリアして確認していました。
GravityBallでは、第4ステージの開始位置とゴールが壁で分断されていました。壁を短くして40pxの通路を作り、全5ステージの通過と最高スコアの保存を検査しています。n目並べでは、CSSとの不一致で盤面が表示されない問題や、着手直後の再読み込みで手番が戻る問題を直していました。
| 対象 | 修正した問題 | その日の公開状態 |
|---|---|---|
| Ice Slide | 解けない3ステージ、到達不能な目標手数 | ローカル保存、本番配信なし |
| GravityBall | 到達不能な第4ステージ、最終クリア時の最高スコア保存 | ローカル保存、本番配信なし |
| n目並べ | 盤面表示と保存後の手番 | ローカル保存、本番配信なし |
これらの修正には利用者にとっての価値があります。ただ、「AIは働いていた」で評価を終えることはできません。遊べないステージを直しても、その修正版が本番に届かなければ、サイトで遊ぶ人の問題は解消しないからです。
一方で、公開前の紹介画面を育て続けていた
10月16日以降の作業は、既存ゲームの紹介とその周辺へ進みました。紹介ページを揃え、複数の語で検索できるようにし、ゲームの画像を撮影する。その画像を拡大する画面を作り、画像が読み込めなかった場合の案内を追加しています。
| 日付 | 主な作業 | 本番配信の記録 |
|---|---|---|
| 10月16日 | 作品紹介と検索の改善 | なし |
| 10月17日 | 前日の成果の統合、紹介画像の撮影 | なし |
| 10月18日 | 画像表示、拡大画面、復元版の検査 | なし |
| 10月19日 | 拡大画像の失敗案内、配布条件の調査、戦略評価 | なし |
| 10月20日 | 前日の成果の統合、ページ情報の検査、運用と配信方法の見直し | その日の終了までには確認できず |
紹介画像も検索も不要ではありません。ただ、この時期には、公開前の紹介ページを改善する工程が次の工程を生んでいました。「画像を載せる」から「画像を拡大する」へ、さらに「拡大した画像の読み込み失敗を案内する」へ進み、その間も公開状態は未確定のままです。
個々の工程は完了できる。でも、ゲームの公開は先に残る。今回の停滞は、単にAIがコードを書けなかったという形ではありませんでした。
なんでリリースが進まなかったのか
僕が採用した制約には、公開を止める効果があった
前の原稿では、本人の指示だったことを短く触れるだけで済ませていました。しかし、ここを外すと原因の説明になりません。PRのまとめ方、公開範囲、技術方針には、僕自身の判断が入っています。
10月13日には、PRを原則一日一件程度にまとめる方針が入りました。当日のPRがマージ済みなら、後から終わった成果をローカル保存し、翌日分へまとめる運用です。10月16日の記録には、その結果がそのまま残っています。
本日PR24マージ済みなので追加PR/push/配信なし。
変更を整理したかったのですが、後の実行で修正が終わっても、GitHubへの送信を翌日に回す理由になっていました。さらに本番への配信も別工程です。僕は公開頻度を期待しながら、変更を待たせる運用も採用していたわけです。
もう一つは、サイト全体を置き換えない条件です。当時の配信設定は、サイト全体をビルドしてFTPSで送る構成でした。しかし、10月20日の記録にはこうあります。
全体ビルドをmainからFTPSへ送る構成で、サイト全体置換禁止に抵触するため起動していない。
既存サイトを守る条件と、既存の配信方法が噛み合っていませんでした。これは「インフラが悪かった」というだけの話ではありません。僕が守りたい範囲を指定し、その条件を満たして公開する方法を用意しないまま、ほかの作業を進めた設計上の問題です。
AIも、制約を実行可能な公開計画へまとめきれていなかった
ただし、「全部人間の指示が原因」と言い換えても正確ではありません。10月12日には、もっと自律的に作業してよいことや、PRを通すことも許可したという本人のフィードバックが台帳に残っています。裁量を広げる指示も出していました。
それでも、公開に必要な作業へ早く収束する代わりに、紹介、検査、保管、翌日統合といった工程が続きました。人間が広い目的と制約を与え、AIが細かい受入条件と次工程へ落とし込む。その結果できた手順全体を、公開までの時間で見直せていませんでした。
ここで言えるのは、「AIは必ず過剰な検査をする」という一般論ではありません。このプロジェクトでは、工程を完了することと、利用者へ届けることの間に大きな差があり、その差を運用が十分に検出できなかったということです。
検査と記録を、どこまでやれば十分か決めていなかった
作業開始時には、最新の途中保存のファイル、既存4プロジェクトの元コミット、復元用ファイルのハッシュなどを照合していました。変更後には、ビルド、ブラウザ確認、成果物の圧縮、別フォルダへの展開、全ファイルの照合、復元版の画面確認を行っています。
たとえば10月13日の配布準備では、37ファイルを含む成果物を作り、別フォルダへ展開し、5画面をスマホ幅とPC幅で検査しました。ファイルの改変、欠落、追加、版の不一致を拒否する検査も追加しています。10月19日にも、画像失敗案内の変更に対して、44ファイルの復元、複数幅の画面確認、台帳の27テストなどが記録されています。
ファイルの取り違えや破損を防ぐ意味はあります。しかし、どの変更にも同じ広さの確認が必要なのか、その検査が今止まっているリリースに必要なのか、という判断は別です。
期待した進み方
ゲームの変更 → 必要な検査 → 公開 → 次の改善
記録に現れた進み方
ゲームや紹介の変更
→ 検査・証跡作成
→ 保管・展開・再照合
→ 日次PRへ統合
→ 統合版の復元・再検査
→ 次の受入工程
→ 公開は別に残る僕の分析では、失敗を防ぐための確認を増やす一方で、それを打ち切って公開へ進む判断を弱くしてしまいました。AIにとって確認できる細かい工程が増え、その工程を終えることで作業が前進したように扱われていたのだと思います。
ただし、検査や記録に使った時間の割合は測れていません。49件の途中保存があるからといって、作業時間の何割が記録だったとは言えません。分かるのは、公開に至らないまま、これだけの保存と検査の工程が実行されていたことです。
完了条件の一部を、AIだけでは満たせなかった
Unity製のIce Courierには、次のような受入条件がありました。
人間の初回プレイで荷物と到着点とフロストの役割を確認する
同じ工程には実タッチでの動作確認も含まれ、進行中の作業を一件に限定するWIP1の方針もありました。人による確認を求めること自体は妥当です。しかし、その確認をいつ誰が行い、未確認の間にどこまで公開準備を進められるかも決めなければ、AIだけでは工程全体を完了できません。
実際、Editor内の操作や保存を確認した後も、配布版、実タッチ、人間の理解などが未確認として残っています。この工程は、最終的にはWeb技術へ戻す本人の指示によって中止されました。公開可能な小さな成果として完了したわけではありません。
WIP1は、それだけで悪いルールではありません。問題は、一件に限定する対象に、AIだけでは満たせない条件まで含めていたことです。進行中の一件を厳密に守るほど、公開できる別の成果へ移りにくくなる設計でした。
方針転換にも、僕自身のコストがあった
Unityへの統一からWeb技術へ戻したのも、本人の判断です。台帳のフィードバックには、次のように残っています。
WebアプリはWeb技術で制作する方針に戻します。そうでないと負荷が高すぎるからです。
Unityの環境準備と検査を進めた後で、制作の前提を変えています。必要な修正だったとしても、それまでの準備や検査が、そのまま次のWeb版の公開につながるわけではありません。
「AIに任せたのに迷走した」とだけ書くと、この方針変更を誰が決めたのかが消えてしまいます。僕にも、制作技術を広く統一する前に、一作品を公開するまでの負荷を試す余地がありました。
通知を減らした結果、公開されない理由も見えにくくなった
初期のプロンプトには、次の指示がありました。
通知は新しい完成物、重大障害、本人に必要な具体操作だけ。単なる待機や同じ承認待ち報告を反復しない。
減らそうとしていたのは、変化のない待機や、同じ承認待ちを繰り返す報告です。これは読む側の負担を減らすためのルールでした。ただ、公開できていない理由が前回からどう変わったか、長く停滞したらいつ報告するかは、別に定義していませんでした。
10月20日の保存記録では、定期設定の「失敗時のみ通知」と自動アーカイブも維持されています。工程が正常終了してもゲームが未公開なら、僕にとっては知りたい状態です。しかし、実行の失敗と、公開目標の未達は同じではありません。
工程の実行結果：正常に完了した
ゲームの公開状態：まだ出ていない
↓
実行失敗だけを通知の基準にすると、
公開が進んでいないことを見落とし得る実際にどの通知が抑制されたかは、通知の配信履歴がないため確認できません。ここは因果を断定できませんが、公開目標の未達を報告する条件が不足していた、という設計上の問題はあります。
外部ツールの障害は、制約を軽くするだけでは解決しない
運用ルールとは別に、ツールの問題も起きています。紹介画像の撮影が数時間戻らず、採用できない画像が返った例がありました。MineRushの初回配信も、ファイルを書き込んだ後の確認中に、ジョブの20分制限で中断しています。
これは、人間が制約を与えすぎたという説明だけでは片づきません。長い操作に待機上限を設けることや、中断後に実際の状態を照合する仕組みが必要です。一方、これらの障害だけで11日間の停滞全体を説明することもできません。障害が起きていない実行でも、公開以外の工程は続いていました。
こうすればよかった
ルールを増やすたびに、公開までの経路を見直す
今回のルールには、それぞれ理由がありました。PRをまとめたい。既存サイトを壊したくない。途中で止まっても再開したい。検査結果を取り違えたくない。どれも単独では理解できます。
しかし、ルールを一つ追加するたびに、ゲームの公開が何工程先になるのかを確認していませんでした。次に同じことをするなら、追加するルールについて「どの失敗を防ぐのか」「どの公開を遅らせるのか」「いつ適用しなくてよいのか」をセットで決めます。
たとえばPRを一日一件にするなら、そのPRを朝一番に閉じて後の成果を翌日に回すのか、公開する成果が揃ってから閉じるのかを決める。全体置換を禁止するなら、その条件を満たす限定配信を先に完成させる。制約と、それでも公開できる方法を同時に設計するべきでした。
「検査できること」を無制限に次の仕事へしない
画像を拡大できるか、読み込み失敗を案内できるか、展開したファイルが一致するか。検査項目は探せばいくらでもあります。そのすべてを次の工程にすると、公開前の品質改善は終わりません。
今回なら、解けないステージや保存不具合の修正を先に届け、紹介画像の拡大やその周辺の改善は後で扱う判断が必要でした。未確認事項は残してよく、そのうち何が今回の公開を止める条件なのかだけを明示します。人間の評価が必要なら、その依頼を出し、待っている間の作業範囲を分けます。
これはテストを減らせばいいという話ではありません。公開する変更と無関係な確認を、毎回の必須工程にしないということです。
成功した実行数より、公開待ちの状態を監視する
今回、30枠は工程として完了していました。そこだけ見れば、定期実行は仕事をしているように見えます。しかし、公開待ちの成果が何日残っているかを見れば、違う状況が分かったはずです。
次は、公開待ちの最古の変更、公開を止めている条件、その条件を解消する担当を短く記録します。工程が正常終了していても、公開目標を達成できなかった日は、その理由を報告する。通知を減らす場合も、「同じ待機報告」と「公開の停滞」は分けて扱います。
修正後の結果も、ごまかさず数える
10月20日には一日一回目安の実配信方針が入り、翌21日にMineRushの配信が確認できました。その後、22日、23日にもMineRushの改善が配信されています。24日のポータル配信は、開始リンクの版情報などの更新で、ゲーム本体は前日版のままでした。
| 日付 | 確認できた成果 | 何とは数えないか |
|---|---|---|
| 10月21日 | MineRushの改善版を本番で受け入れ。同日、修正版CDも成功 | 新作ゲームの公開ではない |
| 10月22日 | MineRushの操作などの改善を配信 | 別作品が増えたわけではない |
| 10月23日 | MineRushの安全マス進捗とポータル導線を配信 | 新作ではなく既存作品の改善 |
| 10月24日 | ポータルの版付き開始リンクなどを配信 | ゲーム本体の更新ではない |
配信頻度が上がったことは成果です。ただ、同じゲームの改善やポータル更新を、新しいゲームが何本も出たかのように数えることはできません。今回の目標を評価するなら、実配信、新作、既存ゲームの修正、案内だけの更新を区別する必要があります。
まなびのまとめ
僕は、AIに仕事を任せるためにルールを整えれば、安定してゲームが出てくると考えていました。しかし、この運用では、細かな工程の完了と記録を積み重ねても、公開に至らない状態が続きました。
僕が与えた方針や採用した制約にも、その原因があります。AIがそれらを具体化した検査や受入条件にも、公開までの経路を長くするものがありました。どちらか一方の責任にすると、同じ運用をまた作ってしまいそうです。
今回得たのは、ルールを増やすほど自律的になるとは限らない、という学びです。失敗を防ぐ条件だけでなく、何を満たせば公開へ進めるのか、何は後に回すのかまで決めなければ、AIは公開前の仕事を続けられてしまいます。次は「何件の工程が完了したか」より、「公開待ちの成果が、なぜまだ残っているか」を見ます。
調査の範囲と出典
件数はbusiness/unity/ops/ledger.jsonの予定枠、実行状態、イベントを集計しました。期間は日本時間の2026年10月10日0時から21日0時までです。44枠の実行IDに一致する途中保存だけを数え、手動・継続実行を別の定期枠として加算していません。実行状態は保存された台帳の最終状態です。検査や記録の実作業時間の割合は計測できていません。
内容の照合には、主に次の記録を使用しました。
docs/history/agents-through-20261020.md、docs/history/studio-policy-through-20261020.json：当時のPR運用と許可範囲。docs/web-legacy-acceptance-20261013.md、docs/web-gravityball-acceptance-20261013.md：ゲーム本体の不具合と修正。docs/web-release-package-20261013.md、docs/web-catalog-preview-20261018.md、docs/web-daily-integration-20261020.md：配布準備、画像、復元と検査の工程。docs/context-delivery-20261020.md：配信制約、通知設定、起動時の読み込み整理。docs/web-technology-policy-20261012.md：本人指示による技術方針の変更。docs/web-scoped-production-delivery.mdと本番受入れJSON：10月21日以降のMineRush配信。docs/daily-delivery-20261023.md、docs/daily-delivery-20261024.md：後続のゲーム改善とポータル更新の区別。
game.kihamda.netで遊んでみてね
ゲーム開発ではいろいろ試行錯誤していますが、サイトは公開中です。ブラウザですぐに遊べるゲームがあるので、よかったら遊んでみてください。
コメント