2人のインディー開発者が同じAIツールを活用して同じジャンルのプラットフォーマーを作っている。しかし、数日後、二人はまったく異なる結果を受け入れます。
道具も与えられた時間も同じだった。他のものはAIに対する態度、正確には仕事を「任せたのか」「させたのか」だ。
1年ぶりに古くなった言葉、「バイブコーディング」
アンドレイ・カッパシが「バイブコーディング」という言葉を作ったのは2025年2月だ。そして1年後の2026年2月初め、彼はその言葉がすでに古いものだと専門家たちは「エージェンティックエンジニアリング」という名前をさらに好むと明らかにした。
彼が付けた説明が興味深い。 「エージェント」は、開発者がコードを直接書く時間はほとんどなく、ほとんどの時間をエージェントを調整して監督するのに使うという意味だ。 「エンジニアリング」は、そこにも技術と科学、専門性が必要だという意味だ。つまり、雰囲気に身を任せてAIが出すコードを受け入れた時期は過ぎ、今は学んで練習しなければならない「オーケストレーションすなわち指揮の技術」が開発のデフォルト値になったという宣言だ。
インディーの開発者にとって、この変化は機会であり罠です。一人でもチームのように働けるようになったという点では機会だ。しかし、指揮する方法を身につけていないまま仕事を丸ごとめくと、速く作られるが最後までプレイされないゲームが出てくる。
早くなったのは開発であり、完成ではない
現業開発者が共通にわかる限界がある。 AIで機械的に動作するゲームは驚くほど速く作れる。しかし、それを楽しい最終結果に整えていく過程はまだ簡単ではないということだ。
最も一般的な錯覚は「開発が早くなったこと」を「ゲームが完成しやすくなったもの」と受け入れることだ。コードを書く時間は減ったが、何が面白いかを定義し、プレイして判断し、何を捨てるか選ぶ時間は減らなかった。むしろ作ることができるものが多くなっただけに捨てなければならないことも多くなった。
判断は握り、文書化する
AIに「OOジャンルゲーム作り」と言う瞬間、企画の判断まで一緒に渡る。何が楽しいのか、どこまで作るのか、何を引くかをAIが決める。開発者が楽しさをコントロールする領域はすでに通り過ぎる。一方、「この分析結果をOO様式の企画書でまとめてくれ」と言えば判断は私の手に残り、AIは文書化という作業を引き受けて進行することになる。
そのため、筆者はAIと働く核心を一文でまとめる。基準をまず文書にすること。基準があれば検証できる。検証できれば間違った部分だけ選んで修正できる。部分だけ修正できれば決定権は最後まで人に残る。基準がなければ気に入るまで最初からやり直すことになり、その都度AIは少しずつ別のゲームを出す。
この方向はソフトウェア業界全体が行く道でもある。ゲーム開発に移せば順番はこうだ。企画書を渡した後、すぐに実施をさせない。まずAIに企画書を要約させ、あいまいな部分について質問させる。正しく理解していることを確認してから実装を行い、検証されたスケルトンを維持したままその上でコンテンツを変形して拡張する。
「感覚の領域」を翻訳すること、分解
すでに検証されたゲーム企画書とソースがあれば、AIを通じて瞬時に作品を作り出すことができる。しかし、ゲーム開発を初めて試みる開発者なら、果たしてどのように近づくべきか？筆者は白紙で始まらず、ジャンル代表作を逆企画するように勧める。ゲームデザインの二軸であるコアメカニズムとレベルデザインを分解して数値とデータに切り離し、私が直接調整できるようにすることだ。
よい教材がある。 「セレスト」開発陣は約5,400ジュールに達するプレイヤークラスコードを公開し、共同開発者マディ・ソソンはセレストの「寛容(forgiveness)」デバイスを直接まとめて公開した。そのリストを見ると、「操作感」という漠然とした感覚がどのような装置で構成されるのかがそのまま明らかになる。
- コヨーテタイム– 足場から離れた直後、しばらくの間はまだジャンプします。
- ジャンプバッファ– 着地直前に押したジャンプ入力を覚えて着地する瞬間実行する。
- 頂点重力を減らす– ジャンプボタンを押し続けると、ジャンプ頂点区間で重力が半分に減り、空中で方向をとる余裕があります。
- コーナー補正– ジャンプするコーナーに頭をつけたり、ダッシュするコーナーに引っ掛かったりすると、そっと横または上にスライドさせます。
- 寛大な壁ジャンプ判定– 壁から2ピクセルほど離れていても壁のジャンプを許可します。
「ユーザーが期待するジャンプ」は、このような名のついた数値の合計だ。そしてこのように名前をつけて分解する瞬間、AIとの対話が変わる。 「操作感がより良く」というAIが毎回違うように解釈するが、「コヨーテタイムをオンにして値をスライダーで露出して」はまさに1つと解釈される。
ここでもう一つ勧めたい習慣がある。ゲームを作る前にチューニングパネルから作らせることだ。
ジャンプ・重力・ダッシュ関連数値を全て上段定数で除き、 プレイ中にスライダーに切り替えるデバッグパネルを貼り付けてください。 調整値はプリセットJSONで保存・読み込み。
この指示ひとつでAIとのコラボレーションユニットが「感」から「値」に降りてくる。 「より良い操作感」が「重力スライダー範囲を広げてくれ」になる。そして、手の味を探すこと、つまり楽しさを判断することは、再び人の手に戻る。
レベルはコードではなくデータです。
レベルデザインも同じ原理だ。幸い、逆企画を一人で最初からする必要はない。人気ゲームのファンコミュニティにはすでにレベルを部屋単位に分解しておいたウィキ資料が積まれている。 AIにその内容を表にまとめさせ、人は直接プレイしてその分析が正しいか検収すればよい。
そしてその結果は必ずしもコードではなくデータファイルとして残さなければならない。レベルがコードに埋め込まれている場合は、修正するたびにAIにコードを修正させる必要があり、そのたびに他の場所が壊れる危険があります。データに分割されていると、人が直接修正することができ、AIが作成したレベルが規則に合うかどうかを機械的に検査することもできます。
ここで企画者に本当に大きなプレゼントが一つ出てくる。ツールです。以前は、企画者が書くレベルエディタ一つを得るためにはツールプログラマーにお願いし、順序を待たなければならなかった。これで、企画書にデータ形式のみが定義されていれば、AIに専用エディタを作成させることができる。そのエディタはまもなく企画書を目で見せる道具となる。
結び：最後の判定は私が直接プレイして下す
バイブコーディングがインディー開発者に与えたのは「一人でもチームのように働ける力」だ。しかし、そのチームは自然に働かない。仕事を任せると、チームは私のゲームではなくAIの平均値を作ります。私が明確に仕事をさせたら、チームは私の基準に沿って動きます。
させる人になるというのは結局3つを置かないことだ。何が楽しいか決める判断、その判断を数値とデータと文書に移す分解、そして結果を自分の手でプレイして見て下る最後の判定。コードはAIが書くことができる。しかし、そのゲームが面白いかは最後まで人だけ答えることができる。
AIに仕事を任せないでください。
文：チョン・ムシク教授（ガチョン大学ゲーム映像学科副教授／工学博士）
政務式教授は？
1994年にトリガーソフト創業メンバーとして出発し、NCソフトディレクター、ナスダック上場会社のグラビティの社外取締役、ルノーソフトの副社長を歴任した大韓民国第1世代ゲーム開発者だ。 2003年韓国初のインディーゲーム公募展を企画、開催した以来、国内インディーゲームの育成に長年の関心と支援を続けており、現在文化体育観光部ゲーム物管理委員会委員/理事、城南市第4次産業特別委コンテンツ/デジタル/空間分課長などを引き受け、国内ゲーム産業の発展と件。
