ゲームのNPCにAIを使うとどうなるか：会話する敵
遊びを見つける執筆にClaudeを使用しています。
ゲームに登場する敵キャラクター（NPC）は、これまで「スクリプト」と呼ばれるあらかじめ書かれた動作手順に従って動いていました。プレイヤーが近づいたら攻撃する、体力が減ったら逃げる、特定の条件で会話のセリフが切り替わる——そういったルールの集まりが、いわゆる「敵の行動」でした。 ところが近年、敵NPCの「会話部分」に大規模言語モデル（LLM）を組み込む実験的な取り組みが増えています。LLMとは、テキストの入力に対して文脈を読んで自然な言葉を返すAIの仕組みで、ChatGPTなどが代表例です。これを敵キャラクターに使うと何が起きるのか、どんな可能性と課題があるのかを、ゲームを作る側・遊ぶ側の両方の視点から整理します。 この記事が想定するのは、「NPCにAIを使う」という言葉を聞いて興味を持った保護者、学習者、ゲームに関心のある人です。技術的な前提知識がなくても読めるよう、専門語はその都度説明しながら進めます。
「スクリプト敵」と「会話AI敵」はどう違うか
スクリプトで動く敵は、作者がすべての反応をあらかじめ書いておく必要があります。「プレイヤーが話しかけたら『黙れ、冒険者め』と言う」という一文があれば、必ずその一文が返ってきます。セリフの数を増やせば多様に見えますが、パターンは有限です。
会話AIを使った敵は、プレイヤーの入力をそのつど解釈して応答を生成します。「今日は天気がいいですね」と話しかければ「戦場に天気など関係ない」のような文脈に沿った返答が出てきます。プレイヤーが「実は君の目的に共感している」と言えば、それを受けた返答が生まれます。同じゲームを2回プレイしても、会話内容が変わります。
この違いは「没入感」に直結します。スクリプト敵は「ゲームの中の人形」という感覚を与えやすく、会話AI敵は「相手が考えている」という錯覚をプレイヤーに与えます。ただし、これが必ずしも「より良い体験」につながるとは限らない点が、実装上の最大の論点です。
会話AI敵が体験を変える具体的な場面
尋問・交渉シーン
RPGやアドベンチャーゲームでよくある「敵幹部を捕まえて情報を聞き出す」場面を想像してください。スクリプトでは、正しい選択肢を選ぶと情報が出る「謎解き」になります。会話AIを使うと、プレイヤーが自分の言葉で交渉でき、敵が「どこまで話すか」を文脈に応じて変えられます。同じ結果に至るルートが無数になります。
戦闘中の煽り・挑発
戦闘中に敵が何かを言うシーンは多くのゲームにあります。通常は固定セリフですが、AIを使うと「プレイヤーの直前の行動に言及した挑発」が生成できます。「さっきの回避は運だったな」のように、ゲームの状態を参照した発言は、緊張感とリアリティを高めます。
敵の「説得」による攻略ルート
「戦わずに敵を説得して仲間にする」ルートをLLMで実現する実験も行われています。プレイヤーが用意された選択肢を選ぶのではなく、自分の言葉で語りかけ、NPCがその内容を評価して態度を変える仕組みです。この場合、攻略の「正解」を作者が完全には制御できなくなります。
実装上の課題と失敗しやすい点
会話AIをNPCに組み込む際には、技術的・体験的な課題がいくつかあります。
キャラクターの一貫性を保つことが難しい。LLMはプロンプト（指示文）によって人格を設定できますが、会話が長くなると設定から外れた発言をすることがあります。「冷酷な敵将軍」のはずが、プレイヤーに優しい言葉をかけてしまうといった事態です。これを防ぐには、プロンプトの設計と、出力を検査するフィルタリング処理の両方が必要になります。
不適切な発言のリスクがある。LLMは入力に応じて自由に文章を生成するため、ゲームの文脈から外れた内容や不適切な表現が出力される可能性があります。子ども向けのゲームや公開プラットフォームでは、出力のフィルタリングと人間によるテストが欠かせません。
応答速度とコストの問題がある。LLMへのAPI呼び出しには通信時間と費用がかかります。1回の会話ごとにAPIを呼ぶ設計だと、多くのNPCが同時に会話するシーンでは遅延や費用の増大につながります。軽量なローカルモデルを使う、会話の頻度を制限する、といった設計上の工夫が必要です。
プレイヤーの期待値のずれ。会話AIが入っていると知ったプレイヤーは、あらゆることが通じると期待します。しかし実際にはゲームの状態をAIが完全に把握しているわけではなく、「さっきそこで拾ったアイテムについて話せる」とは限りません。できることとできないことを明示しないと、プレイヤーが混乱します。
作る側が判断すべきこと
ゲームにNPC会話AIを入れるかどうかは、「面白そうか」だけで決めるべきではありません。次の観点で判断することをおすすめします。
その会話はゲームの核心か。探索や謎解きが主体のゲームで、敵との会話がオマケなら、スクリプトで十分です。逆に「交渉・説得・情報収集」がゲームの中心にあるなら、AIによる生成的な会話はゲーム体験を本質的に変えられます。
フィルタリングとテストに時間を割けるか。会話AIを使う場合、出力の品質管理は開発作業の大きな部分を占めます。公開前に多様な入力でテストし、不適切な出力が出た場合の対処方針を決めておく必要があります。
コスト構造を理解しているか。外部のLLM APIを使う場合、プレイヤーが増えるほど費用が増えます。マネタイズの仕組みや費用上限を事前に設計しておかないと、公開後に予算が破綻することがあります。
スクリプトとの組み合わせで十分ではないか。すべての会話をLLMに任せるのではなく、重要なイベントのセリフはスクリプトで固定し、それ以外の雑談部分だけをAIに生成させる「ハイブリッド方式」は現実的な選択肢です。
ゲームを遊ぶ側から見た「会話する敵」
プレイヤーとして会話AI敵と接するときに知っておくと役立つことがあります。
まず、AIが返す言葉は「本当に考えている」わけではありません。文脈から自然に続く言葉を統計的に予測して生成しています。「共感してくれた」と感じても、それはテキストパターンの産物です。この点を理解したうえで楽しむと、期待と失望のギャップが小さくなります。
一方で、スクリプト敵では得られない「自分の言葉でキャラクターを動かした感覚」は本物の体験です。会話AIをうまく使ったゲームは、プレイヤーが「自分だけのプレイ記録」を持ちやすく、それがゲームの記憶を深くします。
子どもが遊ぶ場合、保護者は「どんな言葉を入力しても返答がある」仕組みだと知っておくと安心です。開発者がフィルタリングをしていても完全ではないことがあるため、ゲームの対象年齢や開発者の安全対策の説明を確認することをおすすめします。
次の行動
ゲームにNPC会話AIを試してみたい場合は、まず小さなスコープ——1体の敵との1シーンだけ——でプロトタイプを作り、出力の品質と費用感を確かめることが出発点です。使いたいLLM APIの料金体系とレート制限は公式サイトで最新の条件を確認してください。作ったゲームをアソバースに投稿すれば、HTMLやZIPファイル形式でそのまま公開でき、実際のプレイヤーからフィードバックを集められます。
参考資料
- OpenAI API 公式ドキュメント（プロンプト設計・モデレーション機能の解説）
- Google DeepMind 研究ブログ（ゲームAIに関する技術解説）
- GDC（Game Developers Conference）公式アーカイブ（NPCとLLMの組み合わせに関するセッション）
