2人のインディー開発者が、同じAIツールを使って、同じジャンルのプラットフォーマーを作っている。しかし数日後、2人はまったく異なる成果物を手にすることになる。
ツールも、与えられた時間も同じだった。違ったのはAIに向き合う姿勢——正確に言えば、仕事を**「丸投げした」のか、それとも「指示した」のかだ。
わずか1年で古びた言葉、「バイブコーディング」
アンドレイ・カルパシー氏が「バイブコーディング」という言葉を生み出したのは、2025年2月のことだ。そして1年後の2026年2月初め、彼はその言葉はすでに古くなったとして、専門家たちは「エージェンティック・エンジニアリング」という呼び名を好んでいると述べた。
彼が添えた説明が興味深い。「エージェンティック」とは、開発者が自らコードを書く時間はもはやほとんどなく、大半の時間をエージェントの調整と監督に費やすという意味だ。「エンジニアリング」とは、そこにも技術と科学、そして専門性が必要だという意味である。つまり、ノリに身を任せてAIが出してくるコードを受け入れていた時期は過ぎ去り、今や**学び、練習すべき「オーケストレーション、すなわち指揮の技術」**が開発のデフォルトになった——という宣言なのだ。
インディー開発者にとって、この変化はチャンスであると同時に落とし穴でもある。1人でもチームのように働けるようになったという意味では、紛れもなくチャンスだ。しかし、指揮の仕方を身につけないまま仕事を丸ごと渡してしまえば、素早く作られはするものの、最後まで遊ばれないゲームが出来上がる。
速くなったのは「開発」であって、「完成」ではない
現場の開発者たちが口をそろえて指摘する限界がある。AIを使えば、機械的に動作するゲームは驚くほど速く作れる。しかし、それを面白い最終成果物へと磨き上げていく過程は、依然として容易ではないということだ。
最もありがちな勘違いは、「開発が速くなった」ことを「ゲームが完成しやすくなった」ことだと受け取ってしまうことだ。コードを書く時間は減ったが、何が面白いのかを定義し、遊びながら判断し、何を捨てるかを選ぶ時間は減っていない。むしろ、作れるものが増えたぶん、捨てなければならないものも増えた。
判断は手放さず、ドキュメント化を指示せよ
AIに「〇〇ジャンルのゲームを作って」と言った瞬間、企画の判断まで一緒に手渡してしまうことになる。何が面白いのか、どこまで作るのか、何を削るのかをAIが決めてしまう。開発者が面白さをコントロールできる領域は、その時点で通り過ぎてしまうのだ。一方、「この分析結果を〇〇形式の企画書にまとめて」と言えば、判断は自分の手に残り、AIはドキュメント化という作業を引き受けて進めることになる。
だからこそ筆者は、AIと仕事をするうえでの核心を一文でこうまとめている。「まず基準をドキュメントにすること」。基準があれば検証できる。検証できれば、間違った部分だけを選んで直せる。部分的に直せれば、最終的な決定権は最後まで人間に残る。基準がなければ、気に入るまで最初からやり直させることになり、そのたびにAIは少しずつ違うゲームを出してくる。
この方向性は、ソフトウェア業界全体が進んでいる道でもある。ゲーム開発に置き換えると、手順は次のとおりだ。企画書を渡したら、すぐに実装させない。まずAIに企画書を要約させ、曖昧な部分について質問させる。正しく理解したことを確認してから実装を指示し、検証済みの骨組みを維持したまま、その上でコンテンツを変形・拡張していく。
“感覚の領域”を翻訳する作業——それが「分解」
すでに検証済みのゲーム企画書とソースがあれば、AIを使って一瞬で作品を作り上げることもできる。では、初めてゲーム開発に挑む開発者は、どうアプローチすべきだろうか。筆者は、白紙から始めるのではなく、ジャンルの代表作を「逆企画（リバースプランニング）」することを勧めたい。ゲームデザインの二本柱であるコアメカニクスとレベルデザインを分解し、数値やデータとして切り出して、自分の手で調整できるようにするのだ。
格好の教材がある。『Celeste』の開発陣は約5,400行におよぶプレイヤークラスのコードを公開しており、共同開発者のマディ・ソーソン氏は、『Celeste』の「寛容さ（forgiveness）」を支える仕掛けを自らまとめて公開している。そのリストを見れば、「操作感」という漠然とした感覚が、どのような仕掛けで成り立っているのかがそのまま見えてくる。
- コヨーテタイム — 足場から落ちた直後のわずかな間は、まだジャンプを受け付ける。
- ジャンプバッファ — 着地直前に押されたジャンプ入力を覚えておき、着地した瞬間に実行する。
- 頂点での重力軽減 — ジャンプボタンを押し続けていると、ジャンプの頂点付近で重力が半分になり、空中で方向を定める余裕が生まれる。
- 角の補正 — ジャンプ中に角に頭をぶつけたり、ダッシュ中に角に引っかかったりすると、少し横や上へ押し出してくれる。
- 甘めの壁ジャンプ判定 — 壁から2ピクセルほど離れていても、壁ジャンプを許容する。
**「プレイヤーが期待するジャンプ」**とは、こうした名前の付いた数値の集合体なのだ。そして、このように名前を付けて分解した瞬間、AIとの会話が変わる。「もっと操作感を良くして」はAIが毎回違う解釈をするが、「コヨーテタイムを有効にして、値をスライダーで公開して」は、ただひとつの意味にしか解釈されない。
ここで、もうひとつお勧めしたい習慣がある。ゲームを作る前に、まずチューニングパネルを作らせることだ。
ジャンプ・重力・ダッシュ関連の数値をすべて冒頭の定数に切り出して、
プレイ中にスライダーで変更できるデバッグパネルを付けて。
調整値はプリセットJSONで保存・読み込みできるように。この指示ひとつで、AIとの協業の単位が「感覚」から「数値」へと降りてくる。「もっと良い操作感に」が「重力スライダーの範囲を広げて」に変わる。そして手触りを探る作業、つまり面白さを判断する作業は、再び人間の手に戻ってくる。
レベルは「コード」ではなく「データ」である
レベルデザインも同じ原理だ。幸い、逆企画をひとりでゼロから行う必要はない。人気ゲームのファンコミュニティには、すでにレベルを部屋単位で分解したWiki資料が蓄積されている。AIにその内容を表にまとめさせ、人間は実際にプレイしながら、その分析が正しいかどうかを検収すればいい。
そして、その成果物は必ずコードではなくデータファイルとして残すべきだ。レベルがコードの中に埋め込まれていると、直すたびにAIにコードを修正させる必要があり、そのたびにほかの箇所が壊れるリスクが生じる。データとして分離されていれば、人間が直接修正でき、AIが作ったレベルがルールに沿っているかどうかを機械的にチェックすることもできる。
ここで、プランナーにとって本当に大きな贈り物が生まれる。ツールだ。かつては、プランナーが使うレベルエディターをひとつ手に入れるにも、ツールプログラマーにお願いして順番を待たなければならなかった。今では、企画書にデータ形式さえ定義されていれば、AIに専用エディターを作らせることができる。そのエディターは、そのまま企画書を目に見える形にするツールになる。
結びに：最後の判定は、自分の手でプレイして下す
バイブコーディングがインディー開発者にもたらしたのは、「1人でもチームのように働ける力」だ。しかし、そのチームは勝手には動いてくれない。仕事を丸投げすれば、チームは”自分のゲーム”ではなく”AIの平均値”を作る。自分が明確に仕事を指示すれば、チームは自分の基準どおりに動く。
「指示する人」になるということは、結局のところ、次の3つを手放さないことだ。何が面白いのかを決める判断、その判断を数値・データ・ドキュメントに落とし込む分解、そして結果を自らの手でプレイして下す最後の判定。 コードはAIが書ける。しかし、そのゲームが面白いかどうかに答えられるのは、最後まで人間だけだ。
AIに仕事を丸投げするな。指示せよ。
本コラムのポイント
| キーワード | 要点 |
|---|---|
| 丸投げ vs. 指示 | 「〇〇を作って」は企画判断ごとAIに渡してしまう。「この形式でまとめて」なら判断は人間に残る |
| 基準のドキュメント化 | 基準があれば検証でき、部分修正が可能になり、決定権が人間に残る |
| 実装前の確認 | 企画書を要約させ、曖昧な点を質問させてから実装へ（仕様駆動開発） |
| 逆企画と分解 | 代表作のメカニクスとレベルを数値・データに分解（例：『Celeste』のコヨーテタイム、ジャンプバッファ） |
| チューニングパネル | ゲームより先に調整用デバッグパネルを作り、AIとの協業単位を「感覚」から「数値」へ |
| レベルはデータ | レベルはコードに埋め込まずデータファイルで管理し、AIに専用エディターを作らせる |
| 最後の判定 | 面白さの判断だけは、最後まで人間が自らプレイして下す |
文：チョン・ムシク教授（ガチョン大学ゲーム映像学科副教授／工学博士）
정무식(Jung Musik)教授は？
1994年にトリガーソフト創業メンバーとして出発し、NCソフトディレクター、ナスダック上場会社のグラビティの社外取締役、ルノーソフトの副社長を歴任した大韓民国第1世代ゲーム開発者だ。 2003年韓国初のインディーゲーム公募展を企画、開催した以来、国内インディーゲームの育成に長年の関心と支援を続けており、現在文化体育観光部ゲーム物管理委員会委員/理事、城南市第4次産業特別委コンテンツ/デジタル/空間分課長などを引き受け、国内ゲーム産業の発展と件。
