2人のインディー開発者が、同じAIツールを使って、同じジャンルのプラットフォーマーを作っている。しかし数日後、2人はまったく異なる成果物を手にすることになる。
ツールも、与えられた時間も同じだった。違ったのはAIに向き合う姿勢——正確に言えば、仕事を「丸投げした」のか、それとも「指示した」のかだ。
わずか1年で古びた言葉、「バイブコーディング」
アンドレイ・カルパシー氏が「バイブコーディング」という言葉を生み出したのは、2025年2月のことだ。そしてちょうど1年後の2026年2月、彼はその言葉はもう古いとして、「エージェンティック・エンジニアリング」という新たな呼び名を打ち出した。ノリに身を任せてAIが書いたコードを受け入れていた時期は過ぎ去り、今やコードを自ら書くのではなく、エージェントを指揮し、監督することが開発のデフォルトになった——という宣言である。
インディー開発者にとって、この大きな変化は落とし穴であると同時に、もうひとつのチャンスでもある。1人でもチームのように働けるようになったという意味では、紛れもなくチャンスだ。しかし、指揮と監督を学ばないまま仕事を丸ごと渡してしまえば、素早く作られはするものの、誰も最後まで遊ばないゲームが出来上がる。
速くなったのは「開発」であって、「完成」ではない
現場の開発者たちが口をそろえて指摘する限界がある。AIを使えば、機械的に動作するゲームは驚くほど速く作れる。しかし、それを面白い最終成果物へと磨き上げていく過程は、依然として容易ではない。
最もありがちな勘違いは、「開発が速くなった」ことを「ゲームが完成しやすくなった」ことだと受け取ってしまうことだ。この2つはまったく別の話である。コードの完成は速くなったが、何が面白いのかを定義し、実際に遊んで判断し、何を捨てるかを選ぶ時間は減っていない。むしろ、作れるものが増えたぶん、捨てなければならないものも増えた。つまり、AIが作るスピードが上がるほど、人間が判断する仕事の重みは増していくのだ。
判断は手放さず、ドキュメント化を指示せよ
AIに「〇〇ジャンルのゲームを作って」と言った瞬間、企画の判断まで一緒に手渡してしまうことになる。何が面白いのか、どこまで作るのかまで、AIが決めてしまうのだ。一方で、その面白さを感じ取るのは、紛れもなく人間の領域である。
逆に「この分析結果を、このフォーマットの企画書にまとめて」と言えば、判断は自分の手に残り、AIはドキュメント化という作業だけを担う。
だからこそ筆者は、AIと仕事をするうえでの核心を一文でこうまとめている。「まず基準をドキュメントにすること」。基準があれば検証できる。検証できれば、間違った部分だけを選んで直せる。部分的に直せれば、最終的な決定権は最後まで人間に残る。基準がなければ、その逆だ。気に入らないたびに最初からやり直させることになり、そのたびにAIは少しずつ違うゲームを出してくる。
だから順序が重要になる。企画書を渡したら、すぐに実装させない。まずAIに企画書を要約させ、曖昧な部分について質問させる。AIが正しく理解したことを確認してから、実装を指示する。そして、検証済みの骨組みを維持したまま、その上でコンテンツを変形・拡張していく。ソフトウェア業界で「仕様駆動開発（スペック駆動開発）」と呼ばれる流れと同じ方向性だ。
“感覚の領域”を翻訳する作業——それが「分解」
では、企画書には何を盛り込むべきか。初めてゲームを作る開発者なら、白紙から始めるのではなく、ジャンルの代表作を「逆企画（リバースプランニング）」することを勧めたい。ゲームデザインの二本柱であるコアメカニクスとレベルデザインを分解し、数値やデータとして切り出して、自分の手で調整できるようにするのだ。
格好の教材がある。『Celeste』の開発陣は、約5,400行におよぶプレイヤークラスのコードを公開している。そこには、「操作感」という漠然とした感覚が、どのような仕掛けで成り立っているのかがそのまま表れている。足場から落ちた直後のわずかな間はまだジャンプを受け付ける「コヨーテタイム」、着地直前に押されたジャンプ入力を覚えておく「ジャンプバッファ」、ボタンを押した時間によって変わるジャンプの高さ、ジャンプの頂点で一瞬ゆるむ重力——。**「プレイヤーが期待するジャンプ」**とは、こうした名前の付いた数値の集合体なのだ。
このように名前を付けて分解した瞬間、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次産業特別委コンテンツ/デジタル/空間分課長などを引き受け、国内ゲーム産業の発展と件。
