3段階のAIプロンプトで水中サバイバル試作を計画する

水中サバイバルは、プレイヤーのルートを1つ、回収目標を1つ、分かりやすい制約を2つに絞ると試作しやすくなります。水面のドック、棚、トレンチを1つずつ用意します。合法な行動ごとに酸素消費を決め、深度への曝露を別のカウンターで見せ、失敗判定のタイミングを正確に定義します。AIへの依頼も分けます。最初はルール、次は最小限のプレイ可能部分、最後に実際の挙動を観測してから修正を依頼します。

Blueglass Reachは手計算の説明例として作った独自の架空デザインです。プロンプトは実行しておらず、プレイ可能なビルドやテストもありません。酸素とシールの値はゲーム内の架空設定であり、実際の潜水に関する指針ではありません。

1回の潜水に範囲を絞る

最初の水中試作にワールドマップ、酸素経済、拠点建設、複数種の海洋生物は必要ありません。プレイヤーが回収目標と帰還の可否を判断できる短い旅が必要です。Blueglass Reachでは、1人の潜水者と密封された調査カプセルを用意します。潜り、スキャンし、回収し、Moon Poolまで戻ります。

座標系ではなく地点の連なりとして確認できる小さなルートにします。D0はMoon Poolの水面ドック、D1はプールとトレンチの間にある岩棚、D2はカプセルがあるBlue Trenchです。移動は隣接ノード間だけ可能です。下降と帰還には同じルートを使うため、アートや別の目標を足す前に各コストを確認できます。

これは1人用、1回の潜水に限った範囲です。協力プレイの役割、継続的な成長、連結する居住地、クラフト、再生可能な資源ループは意図的に外しています。別の設計課題に答える仕組みであり、最初の帰還ルートが成立するかを見えにくくするためです。

プロンプトの前に酸素と圧力のコストを書く

ツールにシーンを依頼する前に、初期状態と行動順を決めます。この例の潜水者はD0、酸素8/8、スーツシール5/5、未スキャン、カプセルなしで始めます。合法な行動ごとに酸素を1消費します。D2で始まる、またはD2で終わる合法行動は、D1–D2間の移動でも一度だけシールを1点消費します。無効な行動は、どちらのコストも適用する前に拒否します。

現実の前提はもっと限定的です。NOAAによると、水圧は水深約33フィート（10.06メートル）ごとに約1気圧上昇します。この変化の方向は、深くなるほど難しくなるゲーム設計の参考にはなりますが、作り物のシールカウンター、その1点刻み、装備や安全に関する結論を裏付けるものではありません。NOAAの圧力解説が裏付けるのは物理的な前提だけです。

毎回同じ順で合法なターンを解決します。酸素を1減らし、移動または目標の更新を適用し、行動の始点または終点がD2ならシールを1減らし、敗北を勝利より先に確認します。回収が成功してもコストを消さず、酸素が0になった帰還を勝利扱いしないでください。リセットは初期状態全体に戻す操作であり、潜水中に無料で使える行動ではありません。

画像は回収直後の判断を示します。カプセルはソケットから外れて潜水者が持ち、上向きのルートは開いています。残るシール2点でD2からD1へ1回上昇でき、D1からD0への移動は深部ノードに触れないため最後の遊泳用に1点残ります。

ルールを3つのAIプロンプトに分ける

ワールド設定、実装、テストを1つの大きすぎる依頼に入れないでください。以下の各プロンプトは目的が異なり、結果を確認できます。いずれもそのまま使えるテンプレートで、モデル実行の記録ではありません。後の観察を特定の依頼に結び付けられるよう、プロンプト間でルールは変えません。

プロンプト1：実装仕様を求める

Blueglass Reachというオリジナルの小さな一人用水中サバイバル試作を設計する。コードを書く前に、このルートだけの簡潔な実装仕様を返す：Moon Pool D0 ↔ Shelf D1 ↔ Blue Trench D2。潜水者はD0、酸素8/8、シール5/5で開始する。密封された調査カプセルはD2にある。合法行動ごとに酸素をちょうど1消費。移動は隣接するルートの辺だけを通る。D2で1回だけScanするとカプセルを見つける。スキャン後、D2で1回だけCollectできる。Waitは合法だが進展しない。D2で始まるか終わる合法行動はシールをちょうど1消費し、無効な行動は何も消費せず何も変えない。解決順は、酸素コスト、行動の効果、該当する場合は深度曝露コストを1回、酸素またはシールが0なら敗北、それ以外はカプセルを持ってD0にいる場合だけ勝利。Resetは初期状態に戻す。状態スキーマ、行動の前提条件、遷移順、勝敗条件、簡潔なテスト表を返す。マルチプレイヤー、拠点、クラフト、酸素補給、継続的な成長、乱数、追加の地図ノードは加えない。数値は実際の潜水の指針ではなく架空の設計設定だと明記する。

返された仕様をノードグラフとコスト順に照らします。D0からD2への直行、2回目のスキャン、スキャン前の回収を、カウンターを変えずに拒否する必要があります。ルール表に無料行動が追加されていたり、D1–D2の移動でシールを2回引いていたりする場合は、ビルドを依頼する前に仕様を修正します。

プロンプト2：最小限のプレイ可能部分を依頼する

以下のBlueglass Reach仕様を使い、利用可能なゲーム実行環境で最小限の1回潜水プロトタイプを作る。三人称の潜水者、つながった深度地点3つ、D2のスキャン対象、回収可能なカプセル1つ、明確な帰還ルートを表示する。隣接地点への1段階移動、1回だけ使えるScan、条件付きCollect、進展しないWait、Resetを用意する。酸素とシールの値はシンプルなカウンターまたはピップで見えるようにする。スキャン、回収、敗北、帰還は区別しやすい状態で知らせる。行動順は厳密に守る。無効な行動はコストなしで拒否、酸素を消費、行動を適用、始点または終点がD2ならシールを1減らし、酸素／シールの敗北をD0とカプセル所持の勝利より先に判定する。拠点、別の潜水者、クラフト経済、2つ目の目標、乱数、圧力または医療シミュレーションは加えない。ビルドまたはコードと、実行方法、短い手動テストチェックリストを返す。誰かが実際に実行するまでは、すべての項目を未検証と記載する。この実行環境でプレイ可能なビルドを作れない場合は、成功を主張せず制約を述べる。

この依頼はルールを確認できる操作とフィードバックを求めますが、ツールがそれらを実装する保証ではありません。後で実際のビルドが返された場合は、ノードの辺、スキャン条件、回収、両カウンター、敗北判定順、リセットをテストします。観察していない挙動は未検証のままにします。

プロンプト3：観察結果を比較して修正を1つ依頼する

実際のBlueglass Reachビルドと、以下に提供された実行メモを確認する。設計概要から合格を推測しない。提供された各ケースについて、期待状態、観察状態、提示された証拠、合格／失敗／未検証を列挙する。まず次を比較する：(A) O8/S5からの6行動の安全ルートで、D0にカプセルを持って戻りO2/S1となる。(B) 回収後にWaitし、その後上昇するとD1でシール0になり敗北。(C) 同じ安全ルートを酸素6から開始すると、最後の行動で酸素0となり、勝利判定の前に敗北。(D) スキャン前のCollectは状態を変えず拒否。(E) ResetでD0/O8/S5/未スキャン/カプセルなしに戻る。観察がない場合は未検証と記録する。失敗があれば、仕様を回復する最小のコードまたはルール変更を提案し、再実行が必要な影響ケースだけを列挙する。機能を追加せず、提供された実行メモで目に見えて確立されていないテストを合格と報告しない。
実際の実行メモ／スクリーンショット／状態ログ：[実行後にのみ貼る。未実行の場合は空欄にして「未実行」と報告する。]

3つ目のプロンプトは証拠がある場合だけ使います。実際の実行メモがなければ、未検証項目だけを列挙し、合格を主張しないのが正しい結果です。こうすれば手計算を試作結果のように装わず、目標状態として活用できます。

帰還ルートと敗北条件を紙上確認する

コードを依頼する前に、行動を1つずつ追跡します。D0、酸素8、シール5から開始します。安全ルートは6行動です。棚へ移動、下降、スキャン、回収、上昇、帰還。D2で始まるか終わる行動だけがシールを消費し、合法行動はすべて酸素を1消費します。

潜水者がカプセルを持って戻ったとき、両カウンターが0より上に残っているためルートは成功します。スキャンと回収は別々の行動としてコストを消費します。下降と上昇はそれぞれ深度曝露行動として1回数えます。D1–D2間の移動にシール2点は使いません。

境界に近い2つのケースで終了判定の順序を確認できます。回収後にD2で待機すると、酸素は4から3へ、シールは2から1へ下がります。次の上昇で酸素は2、シールは0になり、帰還が勝利と判定される前に敗北します。同じ6行動ルートを酸素6から始めると、最後の移動で酸素0、シール1のままD0に着きます。先に失敗を判定するため敗北です。酸素7から始めればD0で酸素1、シール1が残り、記載したルールでは勝利します。

この結果画像は終端状態のコンセプト表現です。緑色のドックランプは架空の到着を示すフィードバックで、生成された試作が潜水者を帰還させた証拠でも、圧力の仕組みが動作する証拠でもありません。

実際の挙動を観察してから修正する

実際のビルドが仕様と異なる場合は、最初に食い違った状態を書き留めます。入力、開始ノード、酸素、シール、スキャンフラグ、カプセルフラグ、期待する次の状態、実際の次の状態、観察した証拠を記録します。後の失敗は、それ以前にコストやフラグが誤って変化したためかもしれません。最初からプロンプト全体を書き換えないでください。

1. Locate the first mismatch. Compare the actual result to the matching row in the paper trace, not to a vague impression that the dive felt wrong.
2. Name the smallest rule involved. Examples include adjacency, the scan prerequisite, a once-only action, the single D2 seal cost, or loss-before-win ordering.
3. Ask for one targeted repair. Keep unrelated controls, scene layout, and costs fixed so the next observation isolates the intended change.
4. Rerun only affected checks. A change to the Collect precondition needs the early-Collect case; a change to terminal order needs the zero-oxygen return case.
5. Keep the result status honest. A design table is expected behavior. A prompt is an unrun instruction. Only recorded behavior from a real build can support a pass claim.

実際のビルドと実行メモがなければ、紙上の仕様で止めます。架空のスクリーンショットを作ったり、提案した修正をテスト済みと説明したりしないでください。後で3つのプロンプトで実際のツールを使う場合は、その出力を自分で確認し、現行モデルと表示コストを見て、画面で確認できた結果を報告します。

最初の水中サバイバル試作を始める

帰還可能な潜水を1つから始めます。短いノードルート、目標1つ、明確な失敗判定順があれば、制作して確認できる小さな対象になります。手順の手計算は自分のテストの基準であり、ビルドがすでにルールに従う証拠ではありません。簡潔なブリーフができたらFree AIゲームメーカーで最初のプレイ可能案を検討し、実際に機能する点と次に直す点を確認します。生成依頼の送信前に、Workspaceで選択モデル、利用可能なKoin残高、表示された生成コストを確認してください。

よくある質問

最初に試作する水中サバイバルの最小ループは何ですか？

潜水者1人、水面地点と深い目標地点を結ぶルート1つ、帰還条件1つを使います。読みやすい少数の行動と状態値を用意し、それぞれの行動で何が変化するか追跡します。小さな範囲なら、生物、クラフト、大きな世界を追加する前に、目標、ルート、失敗条件が分かりやすいか確認できます。

シールカウンターは実際の潜水圧力を表していますか？

いいえ。D2付近でシールを1点失うのは、帰還ルートを計算しやすくするために選んだ架空のゲームルールです。NOAAが裏付けるのは、水深約33フィート下降するごとに圧力が約1気圧上昇するという大まかな物理的事実だけです。このカウンターは生理機能、装備、安全限界、水中での実践をモデル化していません。

無効な行動ではすべての値を変えない方がよいのはなぜですか？

リソースを消費する前に無効な移動や早すぎるCollectを拒否すれば、見落としたルールを明確に伝えられます。また、拒否された操作で位置、酸素、シール、フラグが変わるなら実装が仕様からずれたと分かる決定的な確認にもなります。別の拒否方法を選んでも構いませんが、そのコストを定義し、明示的にテストしてください。

プロンプトの修正を依頼するのはいつですか？

実際の観察で期待状態と実状態の最初の不一致が分かった後です。行動、開始値、期待結果、観察結果、変更するルールを1つ含めます。観察していないケースは未検証のままにし、修正を成功扱いする前に変更ルールが影響する確認項目を再実行します。

Blueglass Reachのプロンプトは実行またはプレイテストされましたか？

いいえ。これらは架空のオリジナルシナリオ向けに再利用できるプロンプトテンプレートで、ルート計算は記事のルールから手計算したものです。モデル実行、プレイ可能なビルド、プレイテストを表すものではありません。この手順は将来のビルドの合格目標に使い、実際に観察した状態だけを報告してください。