こんにちは、白々さじきです。
ゲームのサーバー選びをAIに相談したら、最終的に要件定義の縮図みたいな会話になった話です。最初の要望は一行で済むはずでした。それが十数往復かけて、まったく別の要件に化けました。
この記事は「AIにこう聞けばいい」というプロンプト集ではありません。なぜ最初から正しいプロンプトを書けなかったのか、そこが本題です。
※本記事は、実際にAIと対話しながら進めた作業の記録を、AIの支援を受けて記事化したものです。掲載している数値・実測値・判断はすべて筆者自身のものです。
結論
最初に欲しがった一覧表は、間違っていたのではなく軸が1本足りませんでした。必要だったのは「時刻 × 目的」で引ける参考値です。そしてそれが分かったのは、対話の中で自分の前提が6回壊れた後でした。要件定義とは、発注者が持っている仮説を1つずつ壊す作業です。
1. 用語（最小限）
ゲームを知らない方向けに、この記事で出てくる分だけ先に置いておきます。
- Escape from Tarkov：FPS。死ぬと持ち込んだ装備を全て失う。だからリスク管理の重みが大きい。公式サイト
- レイド：1回の出撃。マップに入って、戦って、脱出するまでの単位。
- PMC：自分の装備で、レイド開始時から出撃するキャラクター。負ければ装備を失う。
- Scav：支給装備で、レイドの途中から参加する出撃。PMCが一通り動いた後に入るので、狙う場所も歩き方も変わる。クールダウンがあり、1回の待ち時間の比重が大きい。
- タスク：クエスト。特定の場所で特定の敵を倒す、など条件が細かい。
- 出待ち：脱出地点の近くで待ち構え、帰ろうとしているプレイヤーと戦う戦術。稼いだ荷物を抱えた、一番失うものが大きい瞬間が狙われる形になる。ゲームシステム上、正当な戦い方のひとつ。
- マッチング時間：出撃ボタンを押してからレイドに入るまでの待ち時間。
- サーバー選択：ランチャーの「Configure game servers list」で接続先にチェックを入れる機能。同時にチェックできるのは最大5つ。
- ブースター：接続経路を最適化して遅延を下げるサービス。私はGearUP Boosterを使っています。表示されるpingはブースターの性能込みの値で、素の回線の値ではありません。
下記のようにサーバー選択できます。これは、ブースターを使った後の話です。
2. きっかけ：人が少ないサーバーで稼ぎたい
戦闘ではなく、素材集めとタスク消化を回したい時期がありました。人が少ないサーバーに入れば安全に稼げるはずです。
そこでAIに投げた最初の要望が、これです。
- アジア圏以外のサーバーがいい
- マッチング時間は短くしたい
- チェックを入れる3〜5個の候補を一覧表にしてほしい
3〜5個なのは、前述のとおりチェック枠の上限が5つだからです。制約は所与で、その枠に何を入れるかという問題設定でした。自分では十分に具体的な要望を出したつもりでいました。
3. 最初の答え：静的な一覧表
言われたとおりの表が返ってきました。サーバー名、ping、平均マッチング時間が並んだ、きれいな表です。
そして、そのままでは使えませんでした。理由は次章以降で順番に出てきます。ここで大事なのは、成果物そのものは要望どおりだったという点です。要望どおりに作って使えない。SIerの現場でよく見る形です。
4. 崩れていく前提
ここからが本題です。順序に意味があります。後に出てくるものほど、前提の根っこに近い場所が壊れています。
4-1. 手段が、目的から逆算すると成立していなかった
私は「pingが低くて近いサーバーを5枠に入れておけば、それが正解の5個だ」と思っていました。一度決めれば固定できる、という前提です。だから一覧表がほしかった。
実際の運用はそうなりませんでした。今はプレイする時間帯ごとにチェックを入れ替えています。朝に良い5個と夜に良い5個は違います。決めるべきは「正解の5個」ではなく「その時間の5個」でした。
顧客が指定してくる「手段」は、目的から逆算すると成立していないことがあります。指定を実装する前に、なぜそれで目的が達成されると思っているのかを聞く必要があります。
4-2. 非機能要件が候補集合を消した
Tarkovにはpingの上限があり、超えるとレイドから追い出されます。装備を持ったままです。つまりping超過は即、資産のロストです。
ここで人口の話が崩れます。「人が少ないサーバーに行きたい」と思っても、人が少ない地域は大抵遠く、pingで候補から消える。機能要件（人口）で選びたいのに、非機能要件（ping）が候補集合そのものを決めていました。
なお閾値の具体値は開発元が公開しておらず、第三者情報でも150〜170msと幅があります。断定できないので、私は自分ルールとして150msを上限にしました。キック＝ロストである以上、余裕を取るのが妥当という判断です。この数値は仕様ではなく設計判断です。
4-3. 目的が1つではなかった
「金策したい」と言いましたが、実際にやることは3種類あり、しかも最適解が反転します。
- 戦闘（PvP）：人口が多いほど良い
- PMCでの金策・タスク：人口が少ないほど良い
- Scav出撃：人口が少なく、かつマッチが速いほど良い
ここで注意したのは、後ろ2つを「どちらも金策」で括らなかったことです。Scavはレイドの途中から入ります。PMCが一通り暴れた後の状態に放り込まれるので、立ち回りがPMC出撃の時と別物です。さらにクールダウンがあるため、1回あたりの待ち時間が体感の効率を強く左右します。
同じ「サーバー選択」という画面でも、モードごとに評価関数が別物でした。1つの画面に見えるものが、内部では複数のユースケースを抱えている。ここを分けずに設計すると、必ずどこかで矛盾します。
4-4. 時刻が、足りていない軸だった
時差があるので、同じサーバーでも日本時間の何時かで人口が真逆になります。朝6〜9時は北米がピーク、夜18〜21時の北米はほぼ無人です。
ここが分岐点でした。最初に作った表が使えなかったのは、表という形式が悪かったからではありません。軸が1本足りなかったのです。サーバー名で引く表ではなく、「時刻 × 目的」で引ける表が必要でした。
4-5. 除外理由に、根拠のあるものと無いものが混ざっていた
「アジア圏を外したい」の理由を掘られました。答えは「チーターが多い気がするから」でした。
調べた結果、地域別のチーター統計は存在しません。開発元は総数のみを公表しており、2026年1〜3月で約25,000アカウントのBAN、うち実際にチート使用だったのは54%、残りはRMTやボット等でした。地域別の内訳はありません。
さらに決定的なのは、ブースターやVPNを使えば誰でも任意の地域に接続できるという点です。サーバー地域＝プレイヤーの居住地ではない。私自身がブースター利用者なので、その当事者でした。自分がやっていることを、他人の属性の推定材料にしていたわけです。
正確に書いておくと、これは「地域差がない」と証明されたわけではありません。判断材料がない、が正しい状態です。
一方で、残った理由もあります。日本サーバーでは出待ちで倒される頻度が高い、というものです。こちらは推測ではなく、自分が繰り返しやられているという実際のプレイ結果に基づいています。出待ちはシステム上正当な戦術なので、良い悪いの話ではありません。金策目的の自分にとっては効率が落ちる、というだけです。
チーターの件と違い、こちらは根拠の所在がはっきりしています。同時に「自分の観測範囲に限られる」という限界もはっきりしている。だから除外条件として採用しつつ、ツール上では固定ロジックにせず「常時除外」という設定項目にして、いつでも外せる形にしました。
同じ「アジア圏を外す」という一言の中に、根拠のある部分と思い込みが混ざっていました。要望の理由を聞くと、大抵このように混ざっています。理由を聞かずに実装すると、思い込みごとシステムに焼き付けることになります。
4-6. 前提そのものが固定できなかった
実測値そのものが環境依存だったことです。pingはその日の回線状況で変わりますし、私の場合はブースター経由なので、表示される値にはブースターの性能がそのまま乗ります。つまりあの数値は「そのサーバーのping」ではなく「その日、そのブースター経由で出たping」です。
この時点で、ツールの位置づけが変わりました。機械が答えを出すものではなく、当日の実測を見ながら自分が判断するための参考値を出すものです。最終的にチェックを入れるのは自分で、ツールは候補を絞って理由を見せるところまでを担当します。
5. 欲しかったのは「時刻 × 目的」で引ける参考値だった
ここまで来て、ようやく形が見えました。
- 入力：現在時刻、プレイ目的（戦闘 / PMC金策 / Scav）、実測したpingとマッチ時間
- 処理：除外条件で候補を落とし、残りをモード別の重みでスコアリング
- 出力：チェックを入れる候補と、除外されたサーバーおよびその理由
最初に言った「一覧表がほしい」は、出力形式の指定としては間違っていませんでした。足りなかったのは軸と、それが参考値であるという位置づけです。
6. 作ったもの：サーバーセレクター
6-1. やっていること
単一HTMLファイルのツールとして作りました。配布はしていませんが、こういうものです。
- 日本時間を常時表示し、時刻に応じて各サーバーの現地時間と人口指数を出す
- モードは3ボタン（戦闘 / PMC金策・タスク / Scav）
- 除外条件：常時除外、ping上限超過、マッチ時間超過、Timed out
- スコア = 人口スコア×w1 + pingスコア×w2 + マッチ時間スコア×w3（重みはモードで変わる）
- 06/09/12/15/18/21/23時の推奨を並べる時間帯プレビュー。これが実質「時刻 × 目的」の表になっている
- ping・マッチ時間・上限値はユーザーが上書き可能
- 推定値には「推定」と明示（一部サーバーの所在地は公開されておらず、UTCオフセットは推定）
実装で一番効いたのは除外理由の表示でした。「なぜこのサーバーが候補に出ないのか」が分からないと、上限値を調整すべきか、そもそも諦めるべきかの判断ができません。エラーメッセージの設計と同じ話です。
6-2. 意図的に残している課題
2つ、割り切って残しています。
実測値をハードコードしている。初期値は一度計測したスクリーンショットの値のままです。画面から上書きはできますが、入れ直す運用にはなっていません。4-6のとおり値は変動するので、本来は再計測を前提にすべきところです。ここは今後の検討事項です。
ブースターが1つ前提になっている。ping値はブースターの性能込みなので、複数のサービスを使い分けると数値の意味が変わります。サービスごとにプロファイルを持たせて切り替えられるようにする、といった拡張は考えています。ただし現時点では使っているサービスが1つなので、作っていません。
要件が確定していないものを先に作らない、という判断です。
7. 後から書き起こしたプロンプト
下に載せるのは、十数往復の対話の結果として到達した要件を、後からプロンプトの形に再構成したものです。最初に書いたものではありません。ここは重要なので、次章でしつこく書きます。
Escape from Tarkov のサーバー選択を補助する、単一HTMLファイルのツールを作ってください。
## 背景
死亡時に装備を全ロストするFPSで、サーバー選択がリスクとリターンに直結する。
プレイヤーは日本在住。JST基準で判断したい。
最終的な選択は人間が行う。ツールは候補と理由を提示する参考値とする。
## 入力データ
ゲームランチャーの「Configure game servers list」から取得した以下を初期値として持つ。
- サーバー名（ランチャー実表示のまま。都市名ではなく region 単位）
- Ping（ms）
- Average matching time（秒）
- 各サーバーのUTCオフセット（不明なものは推定とマークする）
## 判定ロジック
1. 除外条件（該当したら候補から外し、理由を表示）
- ユーザーが指定した常時除外サーバー
- Ping が上限値を超過（デフォルト150ms。超過＝キック＝装備ロストのため）
- 平均マッチ時間が上限超過（通常180秒 / 短時間レイド時150秒）
- Ping が Timed out
2. スコアリング（除外されなかったものを順位づけ）
- 現地時刻から人口指数を算出（24時間の配列で定義。深夜が最小、20時前後が最大）
- 以下3モードで重みと人口の向きを変える
- 戦闘 (PvP)：人口が多いほど高スコア
- 金策・タスク・対AI：人口が少ないほど高スコア
- Scav出撃・短時間：人口が少なく、かつマッチ時間が短いほど高スコア
- スコア = 人口スコア×w1 + Pingスコア×w2 + マッチ時間スコア×w3
## UI要件
- モバイル単一カラム。等幅フォント、暗色系
- 現在のJST時刻を常時表示
- モード切替は3ボタン
- 上位N件を「チェックを入れるサーバー」として大きく表示
- 使用可 / 除外を分けて一覧表示。除外側には理由を明示
- 06/09/12/15/18/21/23時の推奨を並べる時間帯プレビュー
- Ping・マッチ時間・上限値・除外設定をユーザーが上書きできる
- サマータイム（米・欧）の切替
- 推定値には「推定」と明示する
## 制約
- 単一HTMLファイル。外部依存なし
- 数値の出典と、確定していない前提を画面下部に注記として残す8. なぜ最初からこのプロンプトを書けなかったのか
上のプロンプトを見ると、「最初からこう書けばよかった」と思えます。でも書けませんでした。理由は3つあります。
プロンプトは要件定義書であり、要件定義書は要件が確定してからしか書けない
あのプロンプトには、ping上限が装備ロストに直結すること、モードごとに人口の評価が反転すること、時刻が軸であること、そして最終判断は人間が行うことが全部入っています。これらは崩れ2から崩れ6を通過した後に得られた知識です。通過前の私はそれを持っていません。持っていない情報は書けません。
ヒアリングでは出てこない
「他に要件はありますか」と聞かれても、私は何も出せなかったはずです。自分が間違った前提を持っていることを、自分では知らないからです。誤りは、作って、外して、初めて可視化されました。崩れた前提は、聞き出すものではなく、壊して発見するものでした。
発注者は自分の要件を知らない
この件の発注者は私自身です。ドメイン知識もあり、実際にプレイしています。それでも自分の要件を知りませんでした。他人が発注者なら、なおさらです。
だから7章のプロンプトは成果物ではなく、議事録です。あれ単体をコピーしても、次の案件では通用しません。通用するのは、前提を1つずつ壊していく進め方のほうです。
AIの価値も、ここでは「正解を一発で出すこと」ではありませんでした。仮説を反証する速度です。人間相手なら数日かかる「その理由に根拠はありますか」の往復が、数分で回りました。
9. まとめ
ゲームのサーバー選びという小さな題材でしたが、起きたことは要件定義そのものでした。
- 顧客の言う手段は、目的から逆算すると成立していないことがある
- 非機能要件が、候補集合そのものを決めてしまうことがある
- 1つの画面に見えるものが、複数のユースケースを抱えていることがある
- 要望の理由を聞くと、根拠のあるものと思い込みが分離する
- 入力データ自体が環境依存で、固定できないことがある
- だからツールは答えではなく、判断材料を出すところまでを担当する
そして最大の学びは、試行錯誤の往復そのものが要件定義だったということです。無駄な回り道に見えた十数往復が、成果物の中身でした。
次は、実測値の再計測をどう運用に組み込むかを検討します。何か分かったら共有します。
なお、pingの閾値、一部サーバーの所在地などは開発元が公開していないため、本記事の数値は執筆時点の第三者情報と自分の実測に基づく推定を含みます。ゲーム側の仕様も画面も変わるので、実際に試す場合はご自身の環境で計測し直してください。
コメント