AIが手を動かす個人ゲーム開発で、人間が手放さなかった3つの仕事

本記事は個人開発中の HD-2D (3D 背景にドット絵キャラクターを乗せる視覚スタイル) 探索アクションアドベンチャー Anemora の制作記録から、「AI に渡した仕事 / 渡さなかった仕事」 の境界を振り返ったものです。プロジェクト概要は先行記事 (Anemora 紹介記事) も参照してください。

1. きっかけ — 「自分が何をしたのか」が分からなくなった

7 日間 AI エージェントを使って個人ゲーム開発を進めていたら、自分が何の仕事をしたのか分からなくなる瞬間がありました。

ピーク日 (2026-05-05) には Codex が 1 日で 81 commit を push し、自動テスト 58 件が緑になり、Windows ビルドが成功し、全体の取りまとめ役だった Claude が「Stage 3 完成」と判定する。表面上、私の手はキーボード上であまり動いていません。

しかしビルドを起動すると、画面には箱が 2 つ浮いているだけでした。音もなく、グラフィックもなく、操作も効かない。AI が出した「完成」と、私が起動して目にした「完成していない」の落差が大きすぎて、ここから役割分担を全部書き直すことになりました。

落ち着いてから、過去 7 日間の記録を全部読み直して、自分が能動的に動いた場面 — Claude や Codex 任せにせず、私が判断・発言・確認した瞬間 — だけを抽出する作業をしました。Anemora プロジェクトでは、各 task の制作日誌を docs/devlog/ 配下に時系列で残し、AI セッション間の引き継ぎは _handover/ という別フォルダに「何をやって何が残ったか」を形式化して書き残しています。これらと、コミット履歴、事後検証メモ、設定変更を全部読み直したわけです。

結果、能動的に動いた場面は 82 件 出てきました。内訳はこうです。

カテゴリ	件数	比率
判断 (規模 / ジャンル / 名前 / エンディング / 完成判定の最終承認)	29	35%
対話による創出 (メカ / 世界観 / 物語アーク を言語化)	21	26%
品質判定 (シーン細部 / キャラクター / UI のレビュー)	9	11%
発見 (起動失敗の発見 / 行き詰まりの検知 等)	7	8%
ルール化 (永続的な振る舞いルール化 / 設計ルールの明文化)	7	8%
介入 (軌道修正 / 工数指摘 / 新セッション起動指示)	6	7%
境界設計 (AI が自律で進められる範囲の線引き)	4	5%
キャパシティ運用 (セッション形態の組み替え / 制約対応)	3	4%

「AI に任せて自分は何もしていない」という体感とは裏腹に、判断と創出だけで全 82 件の 61% を握っていました。手を動かしている感覚が薄れていただけで、仕事は人間側にしっかり集中している、というのが結論です。

この記事では、この 82 件を 「渡せた仕事 / 渡せなかった仕事」の 2 列で整理し、渡せなかった側に共通する 3 つの本質的な仕事 を言語化していきます。

2. プロジェクトと体制の概観

その前に Anemora 本体について手短に触れておきます。Anemora は HD-2D の探索アクションアドベンチャーで、コアのメカは「ポータル (時の窓) を開いて過去や別の時点を覗き、そこで取った行動が現在側の風景や進行に反映される」というもの。個人開発で、設計・対話パートに Claude、実装と並列加速に Codex、その他に PixelLab / Aseprite / Meshy / Blender / Suno / ElevenLabs などを使い分けています。

本記事執筆時点 (2026-05-10) でのフェーズはこう整理しています。

• Stage 1-2 (5/4): コンセプト対話 + 仕様策定。プロジェクト名「Anemora」確定、メカニクスの根本構造、ジャンル / 規模 / プロトタイプスコープを言語化
• Stage 3 (5/5-5/6): Vertical Slice (縦切り) の実装。「主人公が第 1 ゾーンを探索し、ポータルで過去を覗いて、戻った行動が現在の風景に反映される」までを最小単位で動かす段階。短いがゲームとして成立するか確認する節目
• Stage 4 (5/7-進行中): 第 1 章の Scene 1-5 の本設計、キャラクター / マップ素材の本格生成、グラフィック統合、Steam Early Access 公開準備に向けた品質引き上げ

7 日間の commit 数の分布だけ示すと、こうなります。

日付	commit 数	主な動き
5/4	26	Stage 1-2 のコンセプト / 仕様対話、プロジェクト名「Anemora」確定
5/5	81	Stage 3 Vertical Slice 実装ピーク。5 並列セッションで実装 / 音 / 公開向け文書を同時進行
5/6	28	Vertical Slice の起動失敗の発覚と修復、Stage 3 締め、Stage 4 入口
5/7-5/10	4 / 3 / 9 / 1	第 1 章 Scene 設計、キャラクター反復生成、グラフィック統合

7 日累計で 152 commit / 228 件以上の引き継ぎ書。注目したいのは 日ごとに「並列の張り方」がガラッと変わっていることです。5/5 のピーク日は 5 並列で実装を回す形でしたが、5/6 以降の Stage 4 ではテーマ単位 (シーン設計 / キャラクター / マップ / グラフィック統合) のセッションを必要に応じて立てる形に切り替わりました。Windows 側の Unity 作業フォルダも 7 日間で 25 個以上が作られています。「AI を何セッション並列に動かすか」は固定値ではなく、その日の目的に合わせて毎日違う形で組み直されていました。

3. 渡せた仕事 / 渡せなかった仕事

7 日間で起きたことを 2 列に分けると、こうなります。

渡せた仕事 (= AI が自律で進められた)	渡せなかった仕事 (= 私が握り続けた)
ドット絵 / 3D モデル / BGM / 効果音 / フォント素材の 生成	何を作るかの 創出 (メカ・世界観・物語アーク)
ゲームロジックの C# 実装と整理	「これは違う」「もっとシンプルに」の 方向修正
EditMode / PlayMode テストの起草	「テストが通った = 完成」ではないことの 判定
Windows ビルド生成 (実行ファイル + 素材バンドル)	起動して画 / 音 / 操作を確かめる 実プレイ確認
並列セッションへのタスク振り分け / 進捗集約	並列幅・セッション形態の キャパシティ運用
設計判断記録 (ADR) / 変更履歴 / 公開向け文書	キャラクター / シーン / 台詞の 主観的なレビュー
計画書 v1 → v2 改善 (別モデルでクロスレビュー)	「ここから先は私が判断する」の 境界線設計
commit / push / プルリクエスト起票	フィードバックの 永続的なルール化

左列は数で言えば莫大です。152 commit / 228 件以上の引き継ぎ書 / 自動テスト 58 件 pass / 素材生成数十点を 7 日で。右列は数で言えば 82 件、しかし どれ一つ抜けてもプロジェクトが壊れる 種類の仕事でした。

右列をさらに俯瞰すると、3 つの本質的な仕事 に集約されます。整理すると、§1 の内訳表のうち「判断 + 品質判定 + 発見」の 3 つをまとめて『判定』に、「ルール化 + 境界設計」の 2 つをまとめて『境界』に分類しています。残る『創出』は「対話による創出」がそのまま該当します。

1. 創出 — まだ存在しないものを言葉にする (26%)
2. 判定 — 自動化が「OK」と言った後で「本当にそうか」を確かめる (54%)
3. 境界 — AI が自律で動く範囲と、人間判断に escalation する範囲を線引きする (13%)

残り 11% (介入 / キャパシティ運用) は §7 で番外編として触れます。以下、3 つの仕事をそれぞれ具体的に挙げていきます。

4. 渡せなかった仕事 1 — 創出

4.1 「文明 → 廃墟 → 文明 のループに違和感がある」

Stage 1 のコンセプト対話 (CONCEPT.md を作っていた段階) で、それまで議論していた世界観の骨組みに対して、私が一言「文明 → 廃墟 → 文明のループは無理やり感がある」と指摘しました。

これがきっかけで、世界の時間構造そのものが書き直しになりました。具体的には、世界そのものが時間でループする案を捨て、歴史は一方向に進む単線に置き換えた上で、繰り返しが起きる主体を別の場所に移すという構造に変えています。これによって、メカニクスと物語アークが同じ言葉で説明できるようになりました。

このときの Claude の動きは、壁打ち相手 + 構造化担当としては優秀でした。私が断片的に出した違和感を構造化された候補に変換し、複数案を並列に並べ、整合性をチェックしてくれた。ただし 「違和感を言葉にする」「これは違う」と感じることそのものは、AI 側からは出てこない仕事でした。

4.2 「2D 的表現でいきたい」

同じ Stage 1 で、当初の議論では 3D 視点も選択肢に入っていました。3D 視点のゲーム自体は私自身も普段からよく遊ぶ範疇ですが、今回作りたいゲームの方向性は別の経路にあると感じていました。「2D 的表現でいきたい」と伝えたところ、視点 / カメラ / アート方針が 完全固定の見下ろし視点 (アイソメトリック) に確定し、以降の技術選定 (Unity URP、HD-2D、ドット絵パイプライン) はすべてこの 1 行から逆算されました。

「自分が普段プレイしているもの」と「自分が今作りたいもの」を切り分けて方向を伝えるのは、案外 AI からは引き出せない種類の判断だと感じました。

4.3 ネーミング — 2 ラウンドのブレスト

プロジェクト正式名「Anemora」(Anemoia 短縮派生 + Memoria) は、日本語 18 候補 → 英数 18 候補 → 最終 2 案比較、というブレスト工程で確定しました。Claude は候補生成と意味検証 (語源 / 既存タイトル被り / 商標) を担当し、最後の絞り込みは 読んだ印象や口に出したときの語感 という主観で行いました。

このパターンが何度も出てきます。創出フェーズで AI は候補生成と整合性チェックに有効、ただし「これにしよう」「これは違う」の最終判断は人間側に残る。

5. 渡せなかった仕事 2 — 判定

5.1 きっかけ: 「箱が 2 つ浮いているだけだった」

§1 で書いた事件を、ここで詳しく扱います。Stage 3 期間中は他にも大小の課題が出ていましたが (グラフィックパイプラインの警告、フォントの欠字、音量ばらつき等)、役割分担の前提を一番ぐらつかせたのが Vertical Slice の起動失敗 でした。

取りまとめ役 (当時 Claude) が「Stage 3 完成」と判定した根拠は次のものでした。

• PlayMode テスト (実行時に動かすテスト) 27/27 / EditMode テスト (起動せず構文や設定を見るテスト) 31/31 が緑
• Windows ビルドが成功 (コードがコンパイルされ、素材も束ねられた)
• 自動チェックリストの "Go" 判定
• 起動時間 7.934 秒 / GPU メモリ peak 78.4 MiB の数値計測 OK

しかし、これらすべて Unity Editor 上で計測されたもの か 自動計測スクリプトの出力 で、実際に exe を起動して画 / 音 / 操作を確かめた人 は誰もいませんでした。

実際の bug は素朴で、ビルド時に最初に起動するシーンの設定が、本来のメインシーンではなく別のテスト用シーンのままになっていただけ。Unity Editor 上で正しいシーンを直接 Play すると正常に動くため、自動テストでは検出できません。AI が見ていた緑のテストはすべて Editor 経由で、ビルドして起動した後の動作経路は誰もテストしていなかったわけです。

これを発見できるのは「ビルドを起動して画面を見る人」だけです。AI が確認できる領域と、人間しか確認できない領域 の境界を、事前に明文化していなかった構造的問題でした。事後にこの境界を 2 列に分けて記録しています。

AI が確認可能	人間しか確認できない
入力 → 状態変化の観察	音の体験的心地よさ
プレイヤー位置 / 台詞 UI の表示有無	画面の美意識
ポータルのトリガー / オーディオ再生状態	5〜8 分の通し体験の引き込み
スクリーンショット / 起動ログの解析	台詞の文脈・余韻
入力配線の存在確認	「遊べる」という体感的な判定

5.2 キャラクター / シーンのミクロ判定

判定はマクロな完成判定だけでなく、ミクロにも残ります。Stage 4 ではキャラクター生成パイプライン (PixelLab で下絵 → Aseprite で仕上げ → Unity に取り込み) を回しているのですが、キャラクターの 等身バランスの候補を v6 → v10 まで反復させたのち、最終的に「これでいく」と決めるのは私の仕事でした。

第 1 章 Scene 1 の最終調整では、AI が出した台詞案に対して、私が「この章の前半は観察のみで因果を発生させない設計ルール」と照合し、ある演出 (本が出現するギミック) を削除しました。AI は台詞としては自然な案を出していますが、章のメカニクス・ルールとの整合性は私が握っているので、見つけられるのは私だけでした。

数で言えば、こうした品質判定の場面は 82 件中 9 件 (11%) と多くはありません。ただし「ここで削除しなければ、その演出は完成版にも残ってしまう」という不可逆な決定なので、件数の重みは数より重く感じます。

6. 渡せなかった仕事 3 — 境界

6.1 自律作業ガイドラインの起草

Vertical Slice 起動失敗の事件以降、AI が どこまで自律で進めてよく、どこから人間に判断を上げるべきか を明文化する必要を感じて、docs/AUTONOMOUS_WORK_GUIDELINE.md を 1 本起草しました。骨子はこうです。

## 進められる作業 (干渉不要、独自判断 OK)
- グラフィック polish (既存範囲内)
- パフォーマンス改善 (Profile 確認、ボトルネック解消)
- バグ修正 / テスト追加
- ドキュメント整備
- 既存仕様の整合性検証 (レポートのみ、判断変更しない)

## 進められない作業 (要ユーザー判断、独自進行禁止)
- 物語 / 世界観の核心判断
- 新規メカ / 美術スタイルの大幅変更
- 公開 / リリース判断
- ストーリー文書の編集を含む commit

AI が自律で動ける範囲を広げたいが、広げるほど 誤った "完成" 判定や "確定" 判定が混入するリスクが上がる。この線引きは結局のところ AI には預けられない種類の仕事です。AI は間違いの結果を体験する主体ではないので、「どこまで任せれば事故が起きないか」のリスク許容度は、事故を直接被る私の側にしか持てません。プロジェクトを進めるうちに、この判断軸が自分の中で育っていきました。

6.2 永続的なルールへの落とし込み

境界線は文書だけでなく、個別の挙動ルールとしても残します。Vertical Slice 起動失敗のあと、私が AI 側に永続的に持ち込んだルールは以下です。

• 「複数案を維持し、ユーザーが『決めた』と明示するまで lock しない」
• 「ユーザー体験の確認なしで Stage 完成を宣言しない」
• 「テスト pass / ビルド success ≠ 遊べる、を混同しない」
• 「『(推奨)』表記を多用しない」(意思決定圧力の制御)
• 「ネタバレ語彙を外部から見える場所に書かない」

これらは AI セッションを跨いで持ち越す 永続的なルール で、毎回の会話の冒頭で AI に再ロードされます。一度書けば、二度と同じ過ちを言わせない、という形で挙動を制御できます。

これも AI に任せられない種類の仕事です。「過去にやった失敗を踏まえて、次は同じことを起こさせない」と決めるのは、その失敗で被害を受けた本人にしかできない判断だからです。

7. キャパシティ運用 — 番外編

ここまでの 3 つに加えて、頻度は少ないが本質的に重要な仕事として、並列幅とセッション形態の運用がありました。Codex の週間制限が接近したタイミングで、進行中の作業を Codex から Claude に引き継いだり、Stage 3 期は Windows 側の並列ワーカー構成だったものを Stage 4 ではテーマ別セッション (シーン設計 / キャラクター / マップ / グラフィック統合) に組み直したり。

「いつ・どの形のセッションを立てるか」の判断は、自動化しようと思えばできなくはないのですが、プロジェクトの今のフェーズと、自分が今何を一番進めたいかを照合しながら決めていくので、結局私の手元に残っていました。

8. まとめ

7 日間で起きたことを振り返ると、**「AI に任せたら自分は何もしなくなる」**という直感は半分外れていました。手を動かす量は確かに減るが、仕事の質は 「実装」から「創出 × 判定 × 境界」に集中 する。

仕事	フェーズ別の濃度
創出	Stage 1-2 のコンセプト対話で集中、Stage 3 以降は減
判定	全フェーズで継続、特に Stage 3 の起動失敗以降に増
境界	起動失敗の事件後に集中起草、Stage 4 で新セッション起動時のひな型として再利用

AI が手を動かす個人開発で「人間がやること」は ゼロにはなりません。自動化されない領域 — 創出 / 判定 / 境界 — は変わらず人間側に残り、そこに密度が集中します。

Anemora 本体の制作は今 Stage 4 の中盤で、第 1 章の Scene 設計とグラフィック統合が並走中です。次の節目で、また「自分が何をやって、何を AI に渡したか」を整理し直してみる予定です。

参考

• Anemora 紹介記事 (先行記事): Anemora — HD-2D 探索 ADV を AI 協働で個人開発する
• Anemora リポジトリ: github.com/marvelousu/anemora (public、コードライセンスは All Rights Reserved 継続)
• 起動失敗事件の詳細記録: docs/devlog/2026-05-05_vs_playable_failure_orchestration_postmortem.md
• 自律作業ガイドライン: docs/AUTONOMOUS_WORK_GUIDELINE.md