開発に集中したい
ゲームを一人で作っていると、自分がいくつもの役職を兼任することになる。
プログラマーとして実装して、プロデューサーとしてスケジュールを管理して、マーケターとしてSNSの投稿を考えて、ライターとして技術メモを書いて……。
「一人開発」と言うと聞こえはいいが、実態は全部署を一人で回している零細企業に近い。
実装そのものも大変だが、実際にしんどいのはそれだけではない。
進捗を整理する、判断の根拠を残す、あとから見返せるように技術メモを書く、発信用の素材も貯めておく。そういった散らばった情報を整理し続けることが、じわじわ効いてくる。
実装は進んでいるのに、頭の中だけが先に散らかっていく。
昨日できていたこと、試したこと、やめたこと、その理由。そういうものが蓄積されないまま進むと、同じことを何度も考え直すことになる。
今回書くのは、その状態をどうにかしようと思って試したことだ。
「AIチームを雇う」という発想
AIを使ってゲームを作るといえば、コードを書いてもらう・アイデアを出してもらうといった使い方が多いと思う。
自分がやったのは、もう少し違うアプローチだ。
AIを「会社の社員」として組織化する。
利用したのは、Claude Codeで月額２０ドルのProプランだ。
月額２０ドルでPM担当、技術ドキュメント担当、マーケティング担当、秘書を雇えると思うとかなり安い。
具体的には、Claude Code（ターミナルで動くClaude）に対して、こういうルールを設定した。
あなたは私の「専属秘書」をリーダーとする、開発支援チームです。
報告内容に基づき、以下の部署のファイルを自律的に更新してください。
- PM担当：pm/progress.md を更新し、全体の進捗率を管理する
- ドキュメント担当：docs/ 内に技術マニュアルとして整理する
- マーケティング担当：blog_drafts/ にブログ案、twitter_posts.md にX投稿案を作る要するに、AIを単発の相談相手として使うのではなく、役割ごとに仕事を持つチームとして運用する、という考え方だ。
フォルダ構成はこんな感じ。
GameProject_Office/
├── CLAUDE.md ← 会社のルールブック
├── pm/
│ ├── todo.md
│ └── progress.md
├── docs/ ← 技術マニュアル置き場
├── marketing/
│ ├── blog_drafts/
│ └── twitter_posts.md
└── secretary/
├── todos/ ← 秘書の日次ログ
├── inbox/ ← 長いログの一時保管
└── handoff/ ← Gemini引き継ぎ文書（後述）
CLAUDE.md が会社のルールブックで、各フォルダがそれぞれの部署に対応しているイメージだ。
こうしておくと、どこに何があるのかが明確になる。
進捗は pm/、技術情報は docs/、発信用の下書きは marketing/、そして日々の記録や他AIへの橋渡しは secretary/ に集約される。
Notion、Google Docs、メモ帳、頭の中……と情報が散らばらないだけでも、かなり楽になる。
運用のながれ
使い方はシンプルだ。
自分がやること： 今日やったことを秘書（Claude）に話す。
「ダンジョン入口システムを実装した。
Eキーを押すとUIが出て、出発ボタンを押すとサーバーRPCが走って、
DA（Dungeon Architect）でダンジョンが生成されてワープする。
ハンドシェイク方式でローディング同期も解決した。」
Claude がやること：
secretary/todos/2026-03-18.mdに「今日のログ」として記録pm/todo.mdの完了タスクにチェックを入れるpm/progress.mdの進捗率を更新docs/dungeon_entrance_implementation.mdに技術マニュアルを作成marketing/blog_drafts/にブログ草稿を書くmarketing/twitter_posts.mdにX投稿案を追加
つまり、自分はただ「今日やったこと」を話すだけでいい。
するとAI側が、進捗管理、技術記録、発信準備までまとめて回してくれる。
この仕組みの何がいいかというと、実装した事実が、そのまま会社の資産として蓄積されていくことだ。
普通の一人開発だと、実装した時点で満足して終わりがちだ。
でも本当は、その内容を記録し、整理し、次に活かせる形に変えてはじめて、開発は加速する。
一人開発でしんどいのは、実装そのもの以上に、こうした散らばった情報を整理し続けることだ。
その部分をAIに肩代わりしてもらえるだけで、かなり楽になる。
一番助かっている機能：Gemini引き継ぎ文書の自動更新
実装はGoogleのAI Studio（Gemini）でUE5のBlueprintを貼り付けながら進めている。
ところが、トークン数の上限があるので、機能ごとにチャットを切り替えなければならない。そのたびに「このゲームはこういう仕様で、FCSはこういうパターンで、ここまで実装してある」という背景をまた説明し直すのが、じつに面倒だった。
そこでClaudeに頼んだ。
「新しいGeminiチャットにコピペするだけで、すぐ実装を続けられるレベルの引き継ぎ文書を、実装報告のたびに自動で更新してほしい」
これが secretary/handoff/gemini_context.md だ。
中身はこんな構成になっている。
【1】プロジェクト概要（ゲーム仕様・技術スタック）
【2】アーキテクチャ絶対ルール（4条）
【3】FCSで判明した仕様・パターン
【4】DAで判明した仕様
【5】実装済みシステム一覧（フロー図つき）
【6】躓きポイントと解決策（Pitfalls集）
【7】次の実装項目
【8】Geminiへのお願い事項Geminiの新チャットを開いたら、このファイルをまるごとコピペして「上記を踏まえて〇〇を実装したい」と続けるだけ。
実装中に「そういえばこのアセットの仕様はこうだった」とわかったことも、実装報告として話すとPitfalls集に自動で追加されていく。
つまり、単なる日報ではなく、次のAIとの会話コストを下げるための知識ベースとして蓄積されていく。
今日もClaudeに報告したら、ちゃんと更新されていた。
この「話したら整理される」感覚は、一度体験するとかなり便利だ。
やってみてわかったこと
よかったこと
記録が自然と溜まる
「今日何をやったか」を話すだけで、技術メモ、進捗管理、マーケ素材が同時に出来上がる。
これが地味に大きい。
後から「あのとき何が問題だったっけ」と振り返れる記録が、ほぼ自動で蓄積されていく。
意識してドキュメントを書くというより、開発のついでに記録が増えていく感覚に近い。
判断の軸が言語化される
「ここでどう設計すべきか迷ったとき、どのドキュメントを見ればいいか」がはっきりした。
特に、アーキテクチャ絶対ルールの文書を作ったのが大きかった。
これがあることで、毎回「これは正しいのか」とゼロから悩まなくてよくなった。
一人開発だと、判断基準そのものが頭の中にしかないことが多い。
それを文書に落とすことで、設計のブレが減った。
一人なのに「確認する相手」ができた
「この設計、間違っていませんか」と聞ける相手がいるのは、思っていたより安心感がある。
もちろんAIの返答をそのまま信じるわけではない。
それでも、一度言語化して返してもらうだけで、自分の考えの曖昧な部分が見えてくる。
一人開発は自由だが、同時に「相談相手がいない」ことでもある。
そこを埋めてくれる存在として、かなり助かっている。
情報を一元管理できる
今までは、Notion、Google Docs、GitHub などを使って、実装内容や進捗をバラバラに管理していた。
それぞれ便利ではあるが、記録先が分散すると、それだけで手間になる。
今は、実装内容をまとめて報告するだけで、
- 進捗管理
- 技術メモの作成
- 記事草案の作成
- 引き継ぎ文書の更新
まで自動で行ってくれる。
このフォルダを見れば、今の状態がだいたい把握できる。
管理のための管理を減らせたのはかなり大きい。
気をつけていること
Claudeが書いた内容が正しいとは限らない。 今日も「サーバーがダンジョン生成する」という誤った記述が技術マニュアルに入り込んでいた。正しくは「各クライアントがSeed値をもとにローカルで生成する」。実装した本人が確認して修正する必要はある。
まり、AIが作るドキュメントは便利ではあるが、そのまま正史にはできない。
実装した本人が確認し、必要なら修正する前提で運用している。
だから、自分の中ではドキュメントはあくまで下書きだ。
最終確認は自分がする。そのスタンスは崩さないようにしている。
AIに任せると楽にはなるが、責任まで渡せるわけではない。
ここを履き違えないことは大事だと思う。
今の状態
ダンジョン入口システムの実装が完了して、全体進捗は15%になった。
次は帰還サイクルの実装だ。「自由なダンジョン」の核心である「撤退してちゃんと村に戻れる」を成立させる。
AIチームを連れて、引き続き開発を進める。
次回：帰還システムの実装
