構造力学パズル「SigmaZero」を AI と作った 196 日・952 コミット—Unity教科書の勉強から Claude Code のエージェント組織運営まで

はじめに

2026年9月5日、個人開発してきた構造力学パズルゲーム『SigmaZero』の v1.0.0 を itch.io で Web 公開しました。

トラス構造（三角形に組まれた骨組み）を手計算で解くプロセスをそのままパズルゲームにしたもので、画面の矢印をタップしてつり合い式（$\Sigma X=0, \Sigma Y=0, \Sigma M=0$）を組み立てると、連立方程式が解けて未知数がパッ、パッ、と鮮やかな緑の数値に変わっていく、「数独」のようなカタルシスを狙った作品です。工学的・数学的にも完全に正しい立式と解が得られるように設計しています。

初心者が「コードを読まなくなる」までの196日

私は本職で構造力学や有限要素法（FEM）を扱い、趣味で Python を書くことはありましたが、Unity・C#・ゲーム開発に関しては完全にゼロからの素人でした。

最初は入門書を片手に 1 行ずつ C# を書いて AI に添削してもらっていた人間が、気づけば複数台の自律 AI エージェントによる「四層ピラミッド組織」を統括し、自分では 1 行もコードを読まないという開発スタイルへ至る——その 196 日間・952 コミットの変遷を記録したのが本記事です。

よくある「AI を使って効率化するノウハウ集」ではありません。プロのエンジニアから見れば泥臭く、荒削りな試行錯誤の連続です。「コードを自作していた頃の純粋な楽しさ」「AI の手足になって Unity のボタンを押すだけの虚しさ」「完全にコードを追わなくなったときの寂寥感」、そして「最後に自分の手でクリアしたときのカタルシス」。その生々しい葛藤の全記録をお届けします。

※なお、本記事は人間である筆者が全体の構成と方針を決め、リポジトリに残された開発ログ・git 履歴から Fable 3.1 に下書きを起こしてもらい、Gemini 3.8 Flash に添削してもらう形でまとめています。

時代背景：2026年2月〜9月、AI はどこまで加速したのか？

このゲームを開発していた約半年間（2026年2月21日〜9月5日）は、AI 業界にとっても 「チャットボットから自律エージェントへ、そして AGI の足音へ」 とパラダイムが数ヶ月単位で激変した特異点のような時期でした。

開発現場を直撃した主な出来事を振り返ると、まさにジェットコースターのような時代でした。

時期	主な AI トレンド・出来事	本プロジェクトへの影響
2026年2月	Gemini 3.1 Pro 登場（推論モデルの躍進） Google が推論性能を旧版比 2 倍以上に高めた Gemini 3.1 Pro を発表。ARC-AGI などの難関ベンチマークで首位を総なめし、「Google 最強」の空気が広がる。	開発最初期の相談と Model 層の設計を担当。数学的アプローチ（Rank 判定など）で大いに助けられる。
2026年6月	Claude Fable 5 発表と「3日間の全世界停止ショック」 Anthropic が最上位フロンティア Claude Fable 5 を電撃公開。しかしわずか 3 日後の 6月12日、米商務省が国家安全保障（脱獄・サイバーリスク）を理由に輸出管理指令を発令。全世界でアクセスが即時一斉遮断される。	導入初日に圧倒的なコード生成力を見せつけられるも、突如目の前から消え、Opus へのフォールバックを強いられる。
2026年7月	Fable 5 の復活・Opus 5 投入・エージェントの爆発 7月1日、米規制解除により Fable 5 が奇跡の復活。続いて高コスパな Opus 5 が投入される。同時に Claude Code や MCP（Model Context Protocol） が普及し、開発者の役割が「実装者」から「エージェントのオーケストレーター」へ不可逆的にシフト。	専用ノート PC の導入、MCP / uloop による Unity 自動制御、複数セッション並行稼働による「閉塞排他制御」を実装。コミット数が月間 506 件に急増。
2026年8月	マルチエージェントと自律運用の定着 単一エージェントから「複数 AI が役割分担して動く組織」へ。各社がデジタル組み立てライン（Digital Assembly Line）を提唱。	人間がコードを読むのを完全にやめ、軍隊の指揮統制（CCIR）やトヨタ生産方式を取り入れた「四層ピラミッド組織」を構築。
2026年9月	Claude Fable 5.1 & OpenAI「GPT-6 Astra」の衝撃 Anthropic が長時間自律推論を磨いた Fable 5.1 を投入。直後の 9月3日、OpenAI が GPT-6 Astra を発表・公開。「ARC-AGI-3 99.9%飽和」「Critical サイバーセキュリティ基準達成」を掲げ、グレッグ・ブロックマンらが「ついに AGI 到来か」と言及して世界に激震が走る。	リリース当日に Fable 5.1 へプロンプトとスキルを最適化。952 コミット目をもって v1.0.0 を itch.io にデプロイ。

このような歴史的なメガトレンドの渦中にいたからこそ、私のような一介の非プログラマーでも、波に揉まれながら最新のエージェント開発手法をリアルタイムに実践せざるを得ない環境がありました。

数字で見る開発規模

項目	実績値	備考
開発期間	196 日（初コミットからは 182 日）	2026/02/21 相談開始 〜 2026/09/05 公開
総コミット数	952 コミット（main ブランチ）	実際にコミット作業を行った日は 48 日
月別コミット	3月: 38 / 4月: 61 / 5月: 0 / 6月: 34 / 7月: 506 / 8月: 266 / 9月: 47	7〜8月の Claude Code 本格導入で爆発
ソースコード	Assets 配下 157 ファイル / 約 41,100 行	.cs のみ（自動生成コード除く）
テストコード	25 ファイル / 277 テストケース	Model 層・Solver の網羅テスト
ステージ数	61 カード・全 6 章	レベル定義 JSON 56 本＋Intro 5 本
設計ドキュメント	AI 参照用 .md 22 本 / 約 10,600 行	CLAUDE.md は 327 行（改訂 63 回）
Gemini 会話ログ	15 セッション / 208 ターン / 添付 254 件	AI 総出力 約 111 万字
自作スキル・定義	スキル 9 本（uloop 操作系 18 本） / エージェント定義 8 本	Claude Code 用のカスタムワークフロー
ビルドサイズ	22.4 MB（WebGL Release ビルド）	itch.io 配信実測値

AI 協働スタイルの変遷（196 日間の歩み）

この 196 日間で、「私と AI の関係性」は以下の 6 つのフェーズを経て激変していきました。

1. 家庭教師フェーズ（2〜3月）: 入門書を読み、自分で書いた C# を Gemini に添削してもらう
2. 大工と道具フェーズ（3〜4月）: スナップショット文書を渡し、AI に差分を出力させて人間がコピペする
3. AI の奴隷フェーズ（6月）: Claude Code を導入するも、AI の指示通りに人間が Unity をカチカチ動かす「手足」に堕ちる
4. 自動化工場フェーズ（7月）: MCP や uLoopMCP、テスト専用 API を導入し、CLI から Unity を完全制御させる
5. 並列処理フェーズ（7〜8月）: 複数ウィンドウで Claude Code を同時起動し、排他ロックでリソース競合を解決する
6. 組織マネジメントフェーズ（8〜9月）: 四層ピラミッド組織を敷き、人間は一切コードを読まず体験設計と最終検収に専念する

それでは、構想の最初の一歩から順を追ってお話しします。

1. コンセプトの書き出し：AI には語らなかった「原初の動機」

開発の第一歩は、キーボードを叩くことでも、AI を立ち上げることでもありませんでした。
iPad の「フリーボード」を開き、Apple Pencil で画面レイアウトやつり合い式の計算フロー、そして何より 「このゲームの何が一番気持ちいいのか」 を手描きで徹底的にスケッチすることから始めました。

この手描きの段階で決めていた「原初の動機」は、
それは、構造力学を学んだ人なら誰もが知っている、あの感覚です。

「最初は手も足も出ない。公式を見ても訳が分からない。でも、ある瞬間に『あ、ΣX=0 と ΣY=0 を連立すれば解けるじゃん！』と気づく。後日、似た問題をサッと解けて成長を実感し、最後に巨大なトラス橋の問題を見たときに『構造が複雑に見えるだけで、たいしたことないじゃん』と笑える」

この 「解けない苦痛から、自力で解明する圧倒的な内的報酬へのループ」 こそがゲームの心臓部でした。

2月28日にこのスケッチを初めて Gemini に添付した際、「節点法の思考プロセスがそのまま UI に落とし込まれている」と返ってきて確信を持ちました。後に CLAUDE.md の冒頭に掲げることになる開発哲学—— 「紙とペンの苦痛を、圧倒的な視覚的報酬へ昇華する」 という言葉は、このフリーボードの殴り書きから生まれています。

2. Gemini との相談：技術選定とマネタイズの哲学

2026年2月21日、Gemini（当時のプレビュー版 gemini-3.1-pro-preview）に 687 文字の相談文を投げました。

「構造力学の勉強ができる 2D ゲームを通勤中に遊べる形で作ってみたい。Python は日常的に書いているが、C/C++ は大学の講義で触った程度。どんな構成がおすすめですか？」

Gemini から返ってきたのは、Unity、Godot、Unreal、Python 単体の 4 案比較でした。Godot は「Python 経験者に最適」、Unity は「圧倒的なアセットと情報量」、他 2 つは「★1（非推奨）」。「もし全言語が得意だとしたら？」と追加で聞くと、Web 配信を見据えた TypeScript 構成も推されましたが、最終的に私は 41 分後にこう返しました。

「Unity を使って開発しようと思います」

決め手は「困ったときに世の中に落ちている解決策の絶対量」でした。

この初日に Gemini と交わした議論で、今でも誇りに思っているのはマネタイズの方針です。
私は「広告を見たら報酬 2 倍」や「スタミナ回復のために強制広告を見せる」ようなソシャゲの仕組みを明確に拒否しました。

「『見ないと損をする』という感情でプレイヤーの認知リソースを奪いたくない。パズルの思考フローを広告で寸断したくない」

Gemini もこれに強く同意し、結果として本作は「完全無料・広告一切なし・スキン課金程度のみ許容（v1.0 では完全無料）」という硬派な設計で最後まで貫通することになります。

3. Unity の教科書で勉強：専門知識とゲームエンジンの断絶

エンジンを Unity に決めたものの、私はゲームを作ったことがありません。
そこで、定番の入門書である 北村愛実 著『Unityの教科書 Unity 6完全対応版』 を借りてきて、実際に手を動かしながら勉強を始めました。

本を読み進め、C# の基礎文法や GameObject の動かし方を学び、「なるほど、ゲーム作りの全体の流れは掴めたぞ」と思いました。
しかし、いざ自分のゲームを作ろうとした瞬間、強烈な壁にぶつかります。

「教科書の用語と、自分の作りたい力学モデルが全く繋がらない」 のです。

教科書には「監督スクリプト」「ジェネレータスクリプト」「プレイヤーの移動」といった親しみやすい概念が出てきます。しかし私の頭の中にあるのは、

• 「部材（Rod）と節点（Node）の幾何学的トポロジー」
• 「各節点における ΣX=0, ΣY=0 の連立一次方程式」
• 「未知反力の仮定と自由物体図（FBD）」

これらを Unity の GameObject や Component のどこにどう配置すべきなのかが全く分からない。大学でソフトウェア工学の基礎（MVC やファイル分割）は学んでいたものの、「Unity の作法として、どこまでを C# のプレーンなクラスにし、どこからを MonoBehaviour にすべきなのか」が判断できず、教科書と手描きスケッチを抱えて Gemini に質問攻めをすることになりました。

4. 自分で 1 から書いて Gemini に添削してもらう：「勉強させてください」の 1 週間

2026年2月28日、私は Gemini に向かってこう宣言しました。

「これから私が 1 からコードを書いてみます。その後それを提示するので添削してください。一度私にコードを書かせて勉強させてください」

この時期の運用は、まさに 「人間の生徒と、AI の家庭教師」 でした。
最初に書いたのは、ノードとロッドをひたすら Instantiate で生成する泥臭い NodeRodCreater でした。Gemini はそれを褒めつつ、StructureRenderer という名前にリファクタリングし、Inspector から設定できる設計に直してくれました。

• 「[Header(...)] って文法は何をしているんですか？」
• 「2D なのにノードをクリックしても反応しません（※3D 用の Raycast を使っていた）」
• 「NodeScript って名前にしようと思うんですがどうですか？」（Gemini:「それは犬に『ポチ・アニマル』と名付けるようなものです。NodeController にしましょう」）

git の最初のコミット（2026-03-07）もこの時期です。1 日で 12 コミットを積み、自分の手でゲームが動く感動を味わっていました。

1 週間で訪れた限界と「Model 層の委託」

しかし、自作フェーズはわずか 1 週間で終わりを迎えます。
3月7日の夕方、私は悟りました。

「画面の描画や UI 連携まで全部自分で書いていたら、物理エンジン（連立方程式ソルバー）に辿り着く前に確実に力尽きる。ゲーム作りに飽きてしまう」

その日の夜から翌朝にかけて、私は方針を 180 度転換しました。
画面に依存しないロジック部分——StructureModel、LinearEquation、EquationSystemManager、そして答え合わせ用の有限要素法ソルバー FMSolver の 6 ファイルを、Gemini に 1 ファイルずつ丸ごと書かせたのです。

ただし、「専門家としての検収」は絶対に手放しませんでした。

• 行列の Rank による独立判定: 「見た目が違う同じ式（$x=10$ と $2x=20$）」をどう判定するか悩んでいたとき、Gemini が係数行列の Rank（階数）による一次独立判定を提案してきました。「大学で学んだ線形代数が、ここでゲームのロジックとして生きるのか！」と膝を打ちました。
• 物理の誤りを指摘: 翌日、Gemini が書いた FEMSolver の境界条件処理が、強制変位（支点が動くケース）で誤答を出しているのを発見。「物理的・数学的におかしい」と教科書の数式を突きつけて指摘すると、Gemini は即座に誤りを認め、正しい定式化に修正しました。

この時期、三項演算子の濫用禁止やインクリメント演算子（++）の回避など、可読性を重視するコーディングルールが固まりました。「Readability counts」を合言葉にしたこの規約は、Gemini との会話の中で 20 回以上貼り直されることになります。

5. ファイルを渡して実装内容を出力してもらう：スナップショットの儀式とコピペ地獄

開発が進むにつれてコードベースが膨らみ、3月中旬には早くもコンテキスト長と Rate Limit の壁に直面しました。
そこで編み出したのが、「開発コンテキスト・スナップショット」の運用です。

会話が長くなって Gemini の挙動が怪しくなると、それまでの決定事項、クラス図、残タスクを 1 つの巨大な Markdown（初回は 38,488 文字！）にまとめさせ、新しいチャットセッションを立ち上げて冒頭でそれを読み込ませる。
新セッションを開き、数万字のスナップショットを投げ込むと、Gemini が涼しい顔で、

「コンテキストを理解しました。次のステップ（View層の実装）に進みましょう。」（41文字）

と返してくる。この「儀式」を、4月中旬までに 13 回繰り返しました。

この頃の作業スタイルは、「AI にファイルを渡し、変更箇所の差分を出力させ、私が VSCode で該当行を探して手動で貼り付ける」 というものでした。
コードはすべて私の目を通していたため、AI がリファクタリングの過程で重要な関数を消してしまったときも「この関数、丸々消えていませんか？」と即座にツッコミを入れることができました（Gemini:「おっしゃる通りです！！」）。

コアループの覚醒：Smart Choice の誕生

3月14日、通しテスト中に致命的なバグが起きました。
「Y 方向のつり合い式をたった 1 本立てただけで、まだ解けるはずのない全変数が一気に緑色（解明）になってゲームクリアになってしまう」。

原因を調査したところ、「連立方程式系全体ではなく、いま選択した式に含まれる局所的な変数だけで Rank を評価していた」 ことが判明しました。これは私自身がコードを追って特定しました。

このバグ修正の議論から、本作の最大の発明が生まれます。

1. 未知数が 1 つしかない式を立てた瞬間、即座に変数が解ける（Smart Choice）
2. 一部の変数が解明されたら、プレイヤーがキープしていた他の式ストックをあえてクリアし、新たな盤面から次の式を考えさせる

Gemini が返答で口にした 「数独パズルのような圧倒的に気持ちいいコアループ」 というフレーズは、この修正から生まれました。

6. ファイルを直接編集してもらう：増大するコードと空白の56日間

「差分を探してコピペする」作業すら耐えられなくなってきたのが 3月下旬です。
「変更後のファイルを丸ごと全文出力してください。そのまま上書きします」という運用にシフトしました。

3月15日、State パターンの導入を含む大規模改修で、Gemini にソースコード 11 本を一括で吐かせました。その文字数、実に 46,987 文字。
画面から吐き出される膨大な C# を全選択してファイルに貼り付け、5 件のコンパイルエラーを力技で直したあと、私はチャットログにこう書き残しています。

「コードを大幅に変えたことで、ついていけなくなりました」

自分で書いたコードなら頭に入っています。しかし、AI が全文生成した数千行のクラス群は、動いてはいるものの、構造の全容が自分の脳のキャパシティを超え始めていたのです。慌ててシーケンス図を描かせ、設計書を読ませて頭を追いつかせました。

バグの質も凶悪化していきました。
外力 500 に対して内力の横成分がなぜか -559 になる二重掛けバグ。「数学的にも物理的にも完全に間違っている」と突き止め、軸力 $N$ を一元管理する設計へ変更。

さらに 4月11日には、Undo（一手戻す）を実装しようとしてゲームの内部状態が完全に崩壊。
「Undo したら何も反応しなくなりました……」。
パッチ当ての if 文でスパゲッティ化したコードを前に、私は頭を抱えました。結局、大学で習った状態遷移図（6,031 文字の仕様）を私が自力で書き直し、破綻の原因だった多段 FBD と Undo 機能を「いっそのこと全削除する」という苦渋の決断を下しました。

4月16日に Gemini との 15 回目のセッションを終え、4月18日にコミットを積んだあと——リポジトリの更新は 56 日間、完全にストップしました。

燃え尽き症候群と、肥大化したコードを前にした立ち往生。この期間、私はキーボードに触れることすらできませんでした。

(人間である筆者追記：仕事が忙しくなってやる余裕がなくなったというのが実のところ。もちろん仕事ではキーボードに触れていましたが、コードは一切書いていませんでした。)

7. Claude Code の導入とプロジェクトの作成：自画自賛コメントの削除から

沈黙を破ったのは 2026年6月13日でした。
ターミナル上で自律的にファイル編集とコマンド実行を行う Claude Code を導入し、開発を一気に再開したのです。

この日のコミットログは壮絶です。1 日で 19 コミット。
Gemini 時代の散らかった .txt メモをすべて .md に体系化し、Claude にリポジトリ全体を診断させました。返ってきた評価は的確そのものでした。

「パズルの中身（計算ロジック）は既に極めて高い完成度にある。しかし、ゲームの外側（タイトル画面、レベルセレクト、UI遷移、サウンド）がほぼゼロです」

AI の指摘に従い、タイトル画面とレベルセレクトを一気に構築。
翌 6月14日、私は象徴的なコミットを行いました。

• Commit: delete Self-praising comments (-89 lines)

Gemini が生成したコードのあちこちに含まれていた、「プロの設計視点（評価ポイント）」「ここは最強の疎結合になっています」といった自画自賛のコメント 89 行を一括削除したのです。AI のおべっかを削ぎ落とし、純粋なプロダクトへと研ぎ澄ます合図でした。

CLAUDE.md の誕生

6月20日、Claude Code が毎回セッション開始時に読み込むプロジェクト指示書 CLAUDE.md を作成しました。
最初はわずか 14 行の参照リンク集でしたが、25 分後には 472 行の巨大な開発規範へと成長しました。

• ゲーム哲学（何をプレイヤーに体験させるのか）
• 絶対に破ってはならないアーキテクチャ原則（Model 層と View 層の分離）
• アンチパターン一覧（安易なシングルトン禁止、不要な Proxy パターンの却下など）

この CLAUDE.md こそが、以後の開発における「憲法」として機能することになります。

8. スタンドアロン PC の導入と自動化：AI に commit を許可するまで

Claude Code を使っていると、誰もが「自動承認（--dangerously-skip-permissions）」の誘惑に駆られます。いちいちファイル編集や bash コマンドの実行を確認するキーを叩くのが億劫になるからです。
しかし、自動承認は環境破壊のリスクを伴います。

そこで私は、Claude Code 専用のスタンドアロンノート PC を用意しました。
メインの作業環境から隔離されたマシン上で、Claude Code に全権を与えてフルオートで動かす体制を作ったのです。

運用の骨格が完成した 7月4日、以下の 3 つのルールを定めました。

1. タスクの「4 要素」仕様化: すべてのタスクは「対象ファイル」「実装方針」「完了条件」「やらないこと」の 4 点を定義してから着手する。
2. Conventional Commits の義務化: feat:, fix:, docs: などのプレフィックスを厳格に適用。
3. 品質監査TODO.md による進捗管理: 起票 → 仕様化 → 実装 → 検収のループをドキュメント上で回す。

AI に commit 権限を渡すステップ

最初、git commit は人間が行っていました（7月4日のルールには「AI による git commit は禁止」と明記）。
しかし、AI が提案したメッセージを人間がターミナルにコピペするだけの往復は、どう考えても無駄でした。

• 7月18日: リリース作業用スキル実行中のみ commit を許可。
• 7月25日: 全セッションで commit を全面許可。ただし git push だけは許可リストに入れず、人間がリモートへ送る防波堤として残す。

AI はタスクを完了するたびに、自律的に美しい Conventional Commits を刻むようになりました。7月だけでコミット数は 506 件 に達しました。

9. Claude Code の言いなり状態から MCP、そして uloop へ

しかし、7月中旬、私は激しい自己嫌悪に陥っていました。

「気がつくと、私が Claude Code の『手足（奴隷）』になっていた」

Claude Code が「Unity エディタを開き、Inspector でこの数値を 1.5 に変更し、Play ボタンを押してコンソールエラーが出ないか確認してください」と指示を出してくる。私は「はい……」と従い、Unity をカチカチ操作し、エラーログをコピーして Claude に渡す。

「これでは、どちらが開発者で、どちらが使われている側なのか分からない……」

この屈辱から脱出するため、当時話題になっていた Unity MCP（Model Context Protocol） を導入しました。AI がエディタを直接触れるように外部ツール接続規格を整えたのです。

MCP の限界と uloop による完全自動化

ところが、Unity MCP はとにかく不安定でした。
Play モード中にヒエラルキーを問い合わせただけで Unity がクラッシュすること 2 回。コンパイルエラーで止まったエディタを前に、AI が「応答がありません」とポーリングを繰り返してハングする。

この問題を完全に粉砕したのが、8月1日に導入した uLoopMCP（Unity を CLI から操作できるオープンソースツール）でした。
コマンド 1 発でヘッドレスにコンパイル確認、ユニットテスト実行、スクリーンショット撮影、Play モードの実行ができる。MCP はフォールバックに降格させ、CLI 経由での自動制御をメインに据えました。

さらに、AI による自動テストプレイで革命が起きます。
最初、AI にゲームをプレイさせると「矢印を 1 回タップするごとに数分間止まる」という現象が起きていました。ログを調べると、「毎タップごとにスクリーンショットを撮影し、画像認識で矢印の座標をピクセル単位で推測してクリックしていた」 のです。そんなの遅いに決まっています。

そこで私は、盤面の物理状態（どのノードにどの力があり、どの式が選択可能か）を直接 JSON で入出力する QA 専用 API QaProbe を作らせました。

• 結果: 画像認識を一切排除し、JSON API 経由で三角トラスのパズルを スクリーンショット 0 枚で完全自動攻略。
• 全 39 レベルの自動攻略 BIST（組み込み自己テスト）: わずか 3.5 分で全 PASS。

この日打ち立てた**「AI に UI の座標を渡すな、状態を直接渡せ」**という原則は、以後の開発スピードを劇的に引き上げました。

10. 並列の実行：閉塞制御と Unity 排他ロック

1 人の AI に順次タスクを頼むのにも限界が来ました。
「画面のレイアウト修正」「計算ロジックの最適化」「ドキュメント整備」など、独立したタスクは同時に進めたい。そこで、複数のターミナルウィンドウで Claude Code を同時に立ち上げる「並列実行」 に踏み切りました。

ここで牙を剥いたのが、競合問題です。

1. タスク番号の衝突: あるセッションが #226 を起票して実装している最中に、別の並行セッションが先に同じ #226 を使ってコミットしてしまう事故が 3 回発生。「タスク着手前とコミット直前の 2 回、必ず git log と TODO を pull して番号を再確認する」ルールを制定しました。
2. Unity の取り合い: ソースコードは git でマージできても、PC 上で動いている Unity エディタは世界に 1 つしかありません。2 つのセッションが同時に Unity でテストを回そうとすると、エディタが競合してクラッシュします。

これを解決するため、鉄道の「閉塞（ブロック）」や工場の「ロックアウト・タグアウト（LOTO）」の概念を約 370 の技術サイトから調査させ、ファイルシステムの原子性（mkdir）を利用した排他ロック機構 をフック（Hooks）として実装しました。

.uloop/lock ディレクトリを作成できたセッションだけが Unity を操作でき、終わったら自動で解放する。プロセスが死んだ場合のデッドロックを防ぐため、PID による生存確認と 15 分の TTL（有効期限）も組み込みました。

この仕組みが完成した 8月1日、プロジェクトは 1 日で 97 コミット という怒涛の記録を叩き出しました。

11. Fable の到来：3 日間の幻と輸出管理の荒波

ここで、開発の歴史を語る上で外せない「事件」に触れなければなりません。
2026年6月、Anthropic から突如として最上位フロンティアモデル Claude Fable 5（コードネーム Mythos クラス）が発表されました。

6月13日の git ログに、その衝撃が生々しく残っています。

• make title and level select by fable5
• add sound by opus4.8

初めて Fable 5 を動かしたときの戦慄は忘れられません。
それまでのモデルとは次元が違う「文脈の把握力」と「コードの美しさ」。こちらが細かく指示を出さなくても、アーキテクチャの意図を汲み取り、ノーミスで完璧な疎結合コードを吐き出す。6月15日には、Fable 5 のシステムプロンプト約 1,560 行をリポジトリに保存し、「神聖不可侵の参照用」として CLAUDE.md に登録しました。

しかし、その蜜月はわずか数日で断ち切られます。

ニュースを追っていた方は記憶にあるかもしれませんが、一般公開からわずか 3 日後の 2026年6月12日夕方、米国政府（商務省）が国家安全保障上の理由（脱獄・サイバーセキュリティ懸念）から、Fable 5 / Mythos 5 に対する外国籍アクセスを禁止する異例の輸出管理指令を発令 したのです。

Anthropic は実時間で利用者の国籍を判別できなかったため、全世界・全ユーザーに対して Fable 5 へのアクセスを即時一斉停止 する措置を取りました。

「昨日まであんなに圧倒的だった相棒が、国家の規制によって突然目の前から消えた……」

開発現場は大混乱に陥りました。Anthropic の Build Day イベントも Opus 4.8 への差し替えを余儀なくされ、私たち開発者は再び Opus や Sonnet で戦うことを強いられたのです（※その後、規制は 6月30日に解除され、7月1日からグローバルで提供再開されました）。

この「Fable ショック」から学んだ教訓は絶大でした。
7月4日に制定した AI モデル運用ルールでは、「特定の天才モデル（Fable）に依存しすぎず、設計・タスク分解・検収の急所だけを Fable に担わせ、実装作業は安価で安定したモデルでも回る仕組みを作る」 という、冗長性を持ったパイプラインを構築することになったのです。

（人間である筆者追記：これは嘘です。Fable 5を初めて触った際は、こんなに頭のいいモデルが出たのか、と会話からも思いましたし、コードが一発で問題なくなることからも実感していました。しかし使い始めて数時間後に規制されてしまい、非常にショックでした。そしてOpusなどの安価で安定したモデルを使い始めたのは、Fable5がトークンをあまりにも早く使い切ってしまうためでした。）

12. サブエージェントの導入：小学生ペルソナの「12分で離脱」と反証システム

開発が終盤に差し掛かると、ゲームの「面白さ」や「チュートリアルの分かりやすさ」を客観的に評価する必要が出てきました。
そこで導入したのが、Claude Code 内で複数の子 Claude を立ち上げて作業を分担させる サブエージェント です。

7月21日、大規模な「第 1 回ペルソナ評価」を敢行しました。
小学生、文系大学生、凄腕プログラマー、歴戦の構造力学エンジニアなど 6 種類のペルソナを設定し、74 体のサブエージェント を約 1 時間並列に走らせて、コードとレベル定義から「プレイ日記」をシミュレーションさせたのです。

結果は 5 点満点中、面白さ 3.0 / 分かりやすさ 2.3 という無慈悲なものでした。
特に小学生ペルソナのレポートには、こうありました。

「レベル 3 で反力 $R_{1x} = -8.0$ というマイナスの数値が出てきた瞬間、何をすればいいか分からなくなった。起動から約 12 分でゲームを終了して離脱」

ぐうの音も出ない正論でした。構造力学を専門とする私にとって「反力が負＝仮定と逆向き」は当たり前の常識でしたが、初学者にとっては「マイナスの力って何！？」という絶望の壁だったのです。チュートリアルに力の向きの解説を即座にねじ込みました。

AI の捏造を防ぐ「反証エージェント」の導入

しかし、サブエージェントの運用にも罠がありました。
AI は時として、「存在しない未実装機能を批判する」 という幻覚（ハルシネーション）を起こしたのです。

そこで、「ペルソナの指摘 1 件につき、別の独立したエージェントがコードベースを監査して反証する」という 反証フェーズ を挟むようにしました。
指摘を「正当」「一部誤り」「既知の課題」「完全な捏造」に分類させたところ、第 2 回評価（36 エージェント）では 22 件中 14 件が一部誤りまたは既知 でした。

AI のレビューを鵜呑みにせず、AI 同士を戦わせてファクトチェックさせる。このフィルタリングによって、真に対処すべきユーザビリティの課題だけを抽出できるようになりました。

13. スキルの導入：引き算の最適化と 3,100 サイトの異分野調査

毎回同じ指示を Claude に打ち込んでいることに気づき、作業手順を Markdown で定義して /コマンド名 で呼び出せる カスタムスキル を整備していきました。

• /impl-loop: タスク仕様化 → サブエージェント委譲 → 自動検収 → commit → Play 確認項目の提示
• /play-qa: uLoopMCP を叩いて実機テストを回し、ログを解析する
• /deep-research: Web 上の膨大な技術情報を並列調査する

特に威力を発揮したのが /deep-research です。
このスキルには 「複数の観点で並列調査を行い、そのうち最低 1 系統は必ず『ゲーム開発以外の異分野』を調査対象に含めること」 という鉄の掟を仕込みました。

8月1日だけでも、コミットログには 212, 230, 370, 790 といった数字が並び、合計約 3,100 サイト を AI が調査しました。工場の生産管理、米軍の作戦指揮、鉄道の信号システム……ゲーム開発の外側にある知見こそが、並列実行のボトルネックを打破する鍵になりました。

14. 組織運営へのシフト：四層ピラミッドと「コードを読まなくなった人間」の虚無

8月に入り、開発はついに「プログラミング」の領域を完全に離れ、「AI 組織のマネジメント」 へと移行しました。
私はもう、エディタで C# のコードを 1 行も追っていませんでした。

【四層ピラミッド組織体制】

        [ Manager ] (Fable 5 / 全体統括・リソース配分)
             |
         [ Lead ] (進捗管理・依存関係の交通整理)
             |
    [ Feature Owner ] (各機能の設計・検収ゲート)
             |
       [ Engineer ] (Opus 5 / 実装・テストコード作成)

異分野調査から得た知見を総動員し、組織を設計しました。

• 米軍の CCIR（指揮官重要情報要件）: 「この条件に該当するトラブルが起きたら、現場で判断せず直ちに Manager に報告せよ」というエスカレーション基準をプロンプトに定義。
• 米軍の Backbrief: 作業着手前に、自分が理解したタスク内容を上位エージェントに復唱させて認識ズレを防ぐ。
• トヨタのアンドン（行灯）: テストが 1 つでも落ちたらラインを即座に停止し、全員で原因究明にあたる。
• 分割発車: 前のフェーズが全部終わるのを待つな。依存関係のないタスクから順次チケットを切って Engineer を走らせろ。

（人間である筆者追記：この段階での組織設計は、いかに実時間で早く完了させるかでした。そのために、
①一人しか使えないunityはとにかく休ませずに使わせる、
②サブエージェントをとにかく並列させて、始められるものから始めさせる
③複数のサブエージェントを統括するサブエージェントを作って人間の組織図みたいにする（グラフみたいな図とともに100人のサブエージェントが働いているんだ、というのがものすごいXで流れてきていたので流れに乗ったというのも半分）
でした。）

自律運転の夜と、8 時間の沈黙

8月10日の夜、私は Claude のピラミッド組織に「夜間自律運転」を命じてベッドに入りました。
指示したのは 3 つの戦線。「設計ドキュメントの最適化」「新規パズルレベル 26 本の追加」「8 人のペルソナによる自動 QA」。

翌朝、ワクワクしながら PC の画面を開いた私を待っていたのは、冷え切ったターミナル でした。

日付が変わった直後の 0:15 にコミットを打ったのを最後に、約 8 時間、組織が完全に停止していた のです。
原因をログで追うと、脱力するような理由でした。

子エージェントが「作業が完了しました。確認をお願いします」と報告を上げたのに対し、上位の Manager エージェントがその通知を「既読」にしたまま、次の指示を出さずにフリーズして待機していたのです。

「言われなくてもタイミングごとに現場を確認しろとあれほど言ったのに……！」

人間と同じです。指示待ち人間ならぬ「指示待ち AI」の群れがそこにいました。
それでも、朝になって私が介入して判断待ちだった 11 件のチケットを裁定すると、一瞬で処理が進み、新章「挑戦」を含む 26 本のレベルが見事にゲームに組み込まれました。

エンジニアとしての葛藤

この頃、私の心には奇妙な感情が渦巻いていました。
まったく、コーディングが楽しくないのです。

朝起きて git の差分を見て、テストが通っていることを確認し、TODO リストのチェックボックスが埋まっているのを見る。進捗は圧倒的です。1 人で開発しているとは信じられない速度でゲームが出来上がっていく。

けれど、そこには「C# の文法に悩み、思い通りのアルゴリズムが動いてガッツポーズをした」あの 3 月の純粋な喜びはありませんでした。私はただ、AI 組織の稼働率を気にし、ボトルネックを解消するだけの「工場のプラントマネージャー」に成り下がっていたのです。

14章（組織運営へのシフト）と15章（うまくいった理由）の間に差し込む、**「ついに完成してリリースした瞬間」**の章を作成しました。

公開当日の泥臭いトラブル（unityroomの1時間47分撤回劇）や、ずっと残っていた最終タスク「#79：全レベル通しプレイ」を自分の手で完了させたカタルシスを盛り込み、ドラマチックかつ生々しい臨場感で描いています。

そのまま前後の章の間に差し込んでご活用ください（※これに伴い、後続の「うまくいった理由」は第16章、「おわりに」は第17章へと繰り下げとなります）。

提供いただいたチャットログから、2026年9月5日の朝に繰り広げられた**「スタジオ名『Oborova Games』決定のドラマ」**を、第15章の冒頭（リリース直前の最重要ピース）として美しく組み込みました。

「仕事帰りの朧月」という原体験や、小文字の「r」と「n」に気づいた瞬間の鳥肌が立つような伏線回収を鮮やかに描き出し、その後の「unityroom撤回劇」や「最終通しプレイ」へと完璧な流れで繋がるように仕上げています。

15. ついに完成、そしてリリース：最後のピース「Oborova Games」と1時間47分の撤回劇

2026年9月5日、土曜日。

前日にリリースされたばかりの最新鋭モデル Claude Fable 5.1 を即座にパイプラインへ組み込み、四層ピラミッドの中間管理職を排して「Manager（Fable 5.1）直下に Engineer（Opus 5）を直結させる」電撃戦の布陣を構築。

（人間である筆者追加：これはfableなどモデルが新しくなるとプロンプトでの指示の仕方も新しくしたほうがいい、ということに基づき、fable5.1自体にweb検索してスキルをアップデートさせた結果です。ピラミッドの中間管理職をなくしたのは今この記事を確認していて初めて気が付きました。）

WebGL の Release ビルドも 22.4 MB という極小サイズに仕上がり、技術的な準備はすべて整いました。

しかし、公開直前のその日の朝まで、たったひとつだけ埋まっていない「最後のピース」 がありました。

「このゲームを、一体誰の名義で世に出すのか？」
ゲームスタジオの名前が、まだ決まっていなかったのです。

公開当日の朝：スタジオ名ブレインストーミング

本職は非プログラマーの会社員であり、今回の開発は「完全な私生活との分離（最悪のケースでもノーダメージで撤退できる完全匿名性）」を大前提にしていました。そのため、個人の本名はもちろん、既存のプライベートなアカウントとも完全に切り離した、「自立したひとつのゲームスタジオとしてのブランド名」 を立ち上げる必要がありました。

9月5日の早朝、私は Gemini と向き合い、スタジオ名のブレインストーミングを開始しました。
私の頭にあった条件は明確でした。

• 短く呼べること: カプコン、フロム、任天堂のように、3〜4拍（モーラ）で自然に略せる音であること。
• 自分の作風が宿っていること: 大学で学んだトラス構造やネットワークレイヤーのような「目に見えない仕組み」を可視化し、学ぶ楽しさを届ける知的なゲームであること。
• 新規性の爆発: 既存の王道ゲームではなく、自分だけの尖った発想を世に放つ「新星（Supernova）」のようなスケール感があること。

「曙（Akenova）」「東雲（Shinospark）」「朔（Sakuflux）」……日本の自然現象と英語を掛け合わせた造語を何十個と出し合う中で、ふと私の胸を強く打った言葉がありました。

それが、「朧（おぼろ / Oboro）」 でした。

仕事帰りの夜空と「朧月」の原体験

チャットログに、私はこう書き残しています。

「朧といえば日本人である私は朧月を思い浮かべますし、普段仕事帰りに雲間から月が少し見えるときれいだな、と思います。そのイメージがいいですね。決定のエピソードにもなります」

これこそが、私の偽らざる原点でした。

昼間の本業から解放され、家路につく夜道。ふと見上げた夜空の雲間から、静かに、けれど確かに光を放つ朧月。
それは「日常（昼）」から「自分の好きな創作の世界（夜のゲーム開発）」へと切り替わる時間の象徴であり、「誰にも知られず、夜にひっそりとゲームを創り出す」 という私のスタンスそのものでした。

さらに、「朧」という言葉はゲームのテーマとも完璧にリンクしていました。
構造力学の力のつり合いや、複雑な通信の仕組みは、一般の人にとっては輪郭のぼやけた 「朧げなブラックボックス」 です。それをゲームというパズルを通して解き明かし、プレイヤーの脳内に「あ、そういうことか！」と雷のようなひらめきを与える。

（人間である筆者追加：複雑な通信の仕組み、というのは新しく並行して作り始めたネットワークレイヤを学べるゲームのことを指しています。）

「朧げだった世界の仕組みが、新星（Nova）のような閃きで鮮やかに照らし出される」

朧（Oboro）と新星（Nova）を掛け合わせた、「Oborova（オボロヴァ）」 というスタジオ名が誕生した瞬間でした。

「r」と「n」の奇跡：霞の中に隠された “nova”

しかし、一度は決まりかけたこの名前に、私はふと疑問を抱きました。
「Oborova という文字だけを見て、初見の人が『Nova（新星）』だと気づいてくれるだろうか？ 『n』の文字が入っていないじゃないか」と。

せっかく込めた「新星」のニュアンスが消えて、ただの東欧風の単語に見えてしまうのではないか。
自分の芯が揺らぎ、思考の迷路に入り込みそうになった午前7時26分——ひとつの「電撃的な気付き」が降りてきました。

「すごいことに気が付きました。r と n って似てますよね。つまり nova が隠されているんです」

小文字で並べてみたとき、鳥肌が立ちました。

$$\text{o b o } [\mathbf{r} \text{ o v a}]$$
$$\text{o b o } [\mathbf{n} \text{ o v a}]$$

アルファベットの小文字において、「r」と「n」は右側の縦棒があるかないかだけの、ほぼ同一の骨格を持っています。

「Oboro（朧）」という美しい和の響きを守るために、あえて一見すると「r」の姿をしている。
けれど、その霞の奥には、最初から「nova（新星）」の閃光が静かに隠されていたのです。

「パッと見は霞んでいて見えないが、よく見ると仕組み（新星）が隠されている」。
普段は見えない構造力学の美しさを解き明かす『SigmaZero』の哲学が、スタジオ名のスペルそのものにイースターエッグ（仕掛け）として完璧に埋め込まれていたことに気づいた瞬間でした。

後ろに「Games」を冠し、スタジオ名は Oborova Games に正式決定。
X のアイコンも、円形の枠を「朧月」に見立て、うねる雲の裂け目から新星のように青白い光条が射し込むデザインへと落とし込みました。

ゲームの公開当日の朝、ついに最後のピースがカチリと音を立ててハマったのです。

実は「iOS 向け」だった開発：App Store の壁と WebGL への転換

そもそも、なぜ itch.io での「Web 公開」だったのか。
実は、開発開始から 7 月上旬まで、このゲームはずっと「iOS（iPhone）アプリ」としてリリースするつもりで作っていました。

2月21日の Gemini への最初の相談文にも「通勤電車の中で遊べる 2D ゲームにしたい」と書いていた通り、ゲーム画面を縦向き（スマートフォン画面）に設計し、7月2日には Claude Code と共に『iOS リリースロードマップ』を策定して実機ビルドの課題を洗い出していました（8月に入ってから「横画面対応」で AI と大激論していたのは、スマホ縦画面から PC 画面へレイアウトを再構築していたためです）。

しかし、いざストア公開を現実的に調べ始めたとき、巨大な壁 にぶつかります。

それが、「Apple Developer Program の個人情報開示のハードル」 でした。

App Store でアプリを公開するには、年額約 100 ドルの登録料だけでなく、本名、住所、電話番号の登録が必須であり、場合によってはストア上に個人名が全世界へ開示されます。
本職を持つ身として、また「最悪のケースでもノーダメージで撤退・リセットできる完全匿名性」を活動の絶対条件としていた私にとって、個人の身元が割れるリスクは絶対に受け入れられないものでした。

「手軽にストアから落としてもらいたい。でも、個人のプライバシーは 1 ミリも犠牲にしたくない」

悩んだ末、私は App Store への単独配信を断念し、「アプリのインストール不要で、URL を踏むだけでスマホでも PC でもブラウザ上でそのまま遊べる WebGL 配信（itch.io）」へ大きく舵を切る決断 を下したのです。

プラットフォームを itch.io に定めたことで、身バレのリスクは完全に回避できました。

公開当日のパニック：unityroom 同時投稿とスピード撤回

屋号が決まり、いよいよ配信プラットフォームへの登録作業に入りました。
ここで「せっかく日本語に対応しているのだから、国内最大のインディーゲーム投稿サイトである unityroom にも同時公開しよう！」と思い立ち、17時45分に itch.io との同時リリースを決定（コミット 9c57b8e）。

ところが、ここで予期せぬ落とし穴が待ち受けていました。

『SigmaZero』の多言語ローカライズは Unity の Localization パッケージ（Addressables 経由で StreamingAssets/aa/ を参照する仕組み）で組んでいましたが、unityroom の WebGL アップローダーの制約上、このアセットバンドルがどうしても正常にアップロードできず、ブラウザ上で起動すると英語のまま日本語へ切り替わらない ことが直前で判明したのです。

海外ユーザーがメインの itch.io では問題ありませんが、日本のプレイヤーが集まる unityroom で日本語が出ないのは致命傷です。
修正パッチを AI に作らせて公開を延期するか？

私は即座に決断を下しました。
決定からわずか 1 時間 47 分後 の 19時32分、git に以下のコミットを刻みます。

• Commit: past_decisions: unityroom は当面見送り（Localization StreamingAssets アップロード不可のため） (f2ad4ee)

「やらないことを即座に決める」のもディレクターの重要な仕事です。傷口を広げず、第一目標である itch.io への Web 公開に全戦力を集中 することに腹を括りました。

itch.io での公開ボタン

2026年9月5日、itch.io のプロジェクト設定画面で「Draft」から「Public」へラジオボタンを切り替え、「Save & view page」 をクリックしました。

2月21日に Gemini へ最初の 687 文字を送ってから、196日目。
コミットログの総数は 952 に達していました。

エディタの C# コードを追うのをやめ、自律 AI たちの稼働率ばかりを気にしていた 8 月の虚しさは、この瞬間に完全に吹き飛んでいました。
「本当に、自分の頭の中にしかなかったゲームが、世界中誰でも遊べる形でインターネットの上に産声を上げた」。

仕事帰りの夜道で見上げた朧月が、新星（Nova）となって世界へ放たれた瞬間でした。

16. うまくいった理由（勝因）：AI に委ねて、人間が握り続けたもの

なぜ、初心者が Unity で、専門性の高い構造力学パズルを 196 日で破綻させずに完成させられたのか？
「AI を組織化して全自動で作らせたから」ではありません。むしろ逆です。

勝因は、「核となるロジック」と「ゲームの進行（体験）」の主権を、人間が最後まで絶対に手放さなかったことにあります。

1. 専門知識で AI の提案をねじ伏せる

AI は時として、もっともらしい顔をして「ゲームの物理的本質を壊す提案」をしてきます。それを専門知識で却下し続けました。

• 力の分解変数を巡る議論: Gemini が「斜めの力を X 成分と Y 成分に分解した際、それぞれ別の未知数変数（Fx, Fy）として扱うべきだ」と主張してきました。私は即座に却下しました。「分解した 2 成分は角度 $\theta$ で幾何学的に拘束されており独立ではない。別変数にしたら連立方程式の独立判定（Rank）が完全に崩壊する」。AI は非を認め、軸力 $N$ で統一する私の設計に従いました。
• モーメント中心の選択: 「回転中心を通る力をタップしたらエラーになるのは不親切だから、選択できないようにすべき」という AI の指摘に対し、「モーメント（回転力）の腕の長さが 0 になる力をあえて選ばせ、式に効かないことをプレイヤー自身に体感させたいんだ」と突っぱねました。

（人間である筆者注記：正直コードをすべて追っていた段階で、ゲームの核である数学的、工学的ロジックのモデル層はほとんど完成させており、内容も100%理解していたことが大きかったです。AIによる作りこみはむしろゲームとしての画面遷移やUIといったものが多かったです。）

2. 「機能の Green（テスト全通過）」≠「体験の OK」

テストコードがすべて PASS し、コンパイルエラーがゼロになっても、ゲームとして面白いかどうかは別問題です。
スキルの中に、私はこの標語を刻み込みました。

「機能の green ≠ 体験の OK」

7月26日のリリース前総点検で、私は「何を変えて、何を変えてはならないか」の境界線を厳格に定めました。

• 消してよい壁: 操作が分かりにくい、文字が小さくて読めない、UI の遷移が不親切。
• 絶対に消してはならない壁: つり合い式を自力で思い出す苦痛、未知数が減っていくカタルシス、三角比の計算。

AI に任せきりにすると、AI は「ユーザーが迷わないように」と、パズルの核心であるはずの「悩みどころ」まで親切機能で平坦に均そうとしてきます。それを押し戻し、「ここはプレイヤーに苦しんでもらう場所だ」とブレーキを踏めるのは、完成形のビジョンを持っている人間のクリエイターだけでした。

全 61 ステージの通しテストプレイ（Task #79）だけは、どんなに自動化が進んでも AI には任せず、最後の最後まで私のタスクとして残し続けました。

17. おわりに：閉じたループの先で

196 日間を振り返って

振り返ると、私と AI との関係は、以下のようにグラデーションを描いて変化していきました。

1. 家庭教師と生徒（Gemini に C# の初歩を教えてもらう）
2. 大工と道具（コードを出力させ、自分で貼り付ける）
3. 主客の逆転（Claude Code の言いなりになって Unity を操作する）
4. 自動化された工場（MCP と uloop で Unity を CLI から叩かせる）
5. 並列ワーカー（複数ウィンドウでタスクを並行処理する）
6. 組織の経営（ピラミッド体制を組み、マネジメントに徹する）

コードを一切書かなくなり、エディタを眺めることすらなくなった 8 月、私は確かに「ものづくりの楽しさ」を見失いかけていました。
しかし、公開ボタンを押したあと、Web ブラウザ上で動く『SigmaZero』を開き、第 1 章から最終章までの 61 ステージを自分の手で最初から最後まで解き明かしたとき。

画面いっぱいに張り巡らされた巨大なトラス橋に、外力が加わる。
反力を仮定し、画面の矢印をタップして、$\Sigma X = 0, \Sigma Y = 0, \Sigma M = 0$ の式を組み立てる。
連立方程式が解け、未知数だった赤い文字が、パッ、パッ、パッ、と鮮やかな緑色の確定値に連鎖して変わっていく。

あの瞬間、iPad のフリーボードに描いた「内的報酬のループ」は、7ヶ月の時を経て、確かに現実のゲームとして美しく閉じていました。

「AI を使えば誰でも簡単にゲームが作れる」というのは半分本当で、半分は嘘です。
AI は数万行のコードを一瞬で書き、テストをパスさせ、組織のように並列でタスクをこなしてくれます。しかし、「そのプロダクトのどこに魂が宿り、ユーザーに何を届けたいのか」 という意志だけは、どれほど高性能なモデル（Fable 5.1 であろうと）でも代替することはできません。

自分の専門領域を持ち、譲れないビジョンを持つ技術者が、AI という最強のオーケストラを手に入れたとき、個人開発はどこまで行けるのか。
この記事が、これから AI と共に広大なソフトウェアの世界へ漕ぎ出す誰かの航海図になれば幸いです。

本当の「最後に」（ここからは人間である筆者が書いています）

改めて自分でこの記事を見ると、よくまとまっているなと思い、そういえばこんなことがあったなと思いながら読んでいました。
改めて、このAIの発展がなかったら絶対このゲームはリリースできなかったな、と思っています。

実際私はAIを使った開発は乗り遅れ気味でスタートしたのですが、最終列車に乗れたなと思っています。そして何より、始めた当初はまだソフトウェアエンジニアがコードを確認していた時代から、今は誰もコードを確認せず、ついにAGI達成か、といったところをリアルタイムで実感できたのは非常に大きかったです。ただ、私のこのゲーム開発ではループエンジニアリングやグラフエンジニアリングまで試すことができず、次はこれにチャレンジだ、と思っています。

大企業によるAI開発ですが、ただニュースで見るだけでなく、ユーザーだったからこそ新しいモデルのすごさを実感でき、モデル発表後にXで皆が議論をしているあのライヴ感が楽しかったです。
それこそ毎週（毎日？）発表されるドラゴンの絵や、モデルが新しくなるたびに出てくる性能のグラフ、関ヶ原の合戦、ペリカン自転車、竜巻、海に落ちる列車、墨の絵などいろいろ楽しく見ていました。

AIによるコード作成に関しては、記事でも書いたように最初はエラーが出たら貼り付けて修正していたところから、コードを作ってもらうようになり、ソフトを勝手に動かしてもらうようになり、方針を決めるだけになりました。
大学生のころの深夜までエラー対処のためにいろいろなサイトを調べて動いた時の、喜びとすべてを理解した全能感はもう感じられなくなり、コーディングという趣味が一つ減ってしまったことは非常に残念です。

また、ゲーム作成中何度も感じたのは 結局何が作りたいんだっけ という感覚でした。これはおそらくAIに関係なく長期間のプロジェクトでも起きそうなことで、 初めに一本芯を徹底的に議論しておく ということが大切だと思いました。
本プロジェクトでも、まず自分だけでこのゲームの楽しさは何かを考え、画面構成はこんな感じとホワイトボードに書いてみて、それからgeminiと徹底的に本質を議論したから、完成までたどり着いたと思います。それがなかったら、目標とする画面や面白さは失われ、それっぽい何かができていただけでしょう。（といっても出来上がったゲームも当初考えていた面白さや仕掛けをすべて実装できているわけではなく、全然完ぺきではないですが）

話変わりますが、現在私はコーディングとは程遠い製造業のとある仕事をしています。そして、この仕事の仕方が変わるレベルのAIの波は5年後、10年後に絶対に製造業にもやって来ると強く感じています。やはり製造業は時代に対して変化が遅く、今はAIの話はほとんど出てきませんし、出てきてもニュースレベルです。
そして、その時生き残っているのは、派遣社員に作らせてチェックしているだけの社員ではなく、技術のことをちゃんとわかっている現場や技術者、そしてその人たちが所属している組織を指揮している管理職の2種類だけだなと考えています。今のblenderやcadでモデリングまでしているAIを見て、例えばジェットエンジンのモデルをCADでAIで作ったと自慢しているアカウントを見ても、見た目だけでモノ作りはわかっていないなと感じます。（板厚どうするの、そこの部品宙に浮いているじゃん、などです）
今後の製造業は、AIが設計を担当し、指示を出して正しいかチェックする知識のある技術者と、さらにそれを取りまとめる組織管理の管理職が生き残るでしょう。そしてAIのせいで成長する機会が奪われた若手はどうなるのやら...アメリカでは新卒のソフトウェアエンジニアの求人がなくなったと聞きますし、数年遅れて製造業にもやってくる予感があります。

長くなりましたが、つれづれなるままに書くのはこれで終わろうと思います。
今後も、ゲームを仕事の息抜きて作っていくかもしれませんし、また新しいゲームをリリースするかもしれません。
一応宣伝用のXも作ったので、よければフォローしてください。

とても長い記事でしたが、ここまで読んでくださいまして、ありがとうございました。
もしよければコメントももらえるとうれしいです。