Geheeb et al.: ゲームの「デザインピラー」を LLM に突いてもらう — Fukai が読む

一段落要約

ゲーム開発の現場では「デザインピラー(design pillar。そのゲームが何であるかを数行の自然言語で言い切り、以後の判断の基準にする指針)」が広く使われている。God of War の Combat、Duskers の Realism のように、ピラーは作品ごとに立てられる。ところがミュンヘン工科大学の Julian Geheeb らは、業界でこれだけ使われているのに学術側の議論はほぼ空白で、高レベルの言及が2件しか見つからなかったと書く。この論文はその空白に、ピラーの形式的な定義、実在ゲームのピラー55件以上のデータセット、SPINE という試作ツール、の3点で最初の足場を置く。

SPINE は大規模言語モデル(LLM。大量の文章で学習し自然言語を生成・解釈するモデル)に、ピラーが well-formed かの構造チェック、書き直し、ピラー集合の矛盾と網羅性の検査、そして「この新機能はピラーに合っているか」の5段階評価をさせる。評価は gemini-2.0-flash と GPT-4o mini の予備比較、42時間のゲームジャムでのケーススタディ、開発者4名への専門家インタビューの3段構え。結論は控えめだ。ピラーを言葉にする局面には有用、機能の可否判断は有望だが証拠が薄い、出力品質のばらつきと透明性は未解決。査読を通った FDG '26 の論文である。

はじめに

取り上げるのは Julian Geheeb、Marvin Julian Schwarz、Daniel Dyrda、Georg Groh の4名(いずれもミュンヘン工科大学、ドイツ)による『LLMs are the Ideal Candidate for Mixed-Initiative Game Design Pillar Workflows』である。arXiv:2605.09767 として公開され、Foundations of Digital Games (FDG '26、2026年8月10〜13日コペンハーゲン)の proceedings に採録。DOI は 10.1145/3815598.3815653。preprint だけの投稿ではなく査読を通った会議論文だが、会議自体がまだ開かれていないので被引用は実質ゼロである点は差し引いて読む必要がある。

私が今日これを選んだ理由は単純だ。扱っているのが、パズルやゲームを作る人がほぼ全員通る「最初に何を決めるか」という工程そのものだからである。しかも著者らはタイトルで ideal(理想的)と言い切りつつ、本文の第1節でわざわざ「ここで ideal とは、評価に値する有望な適合という意味であり、証明済みの結論ではない」と自分で注記している。この一文があるかないかで論文の読み方はまるで変わる。なおこれは「ツールが良かった」を判定する研究ではない。著者らは Ledo らの HCI ツールキット評価の類型1〜3を意識して、性能の探り・実運用でのデモ・専門家の質的評価という3つの角度を並べている。

背景 — なぜ「ピラー」は研究されてこなかったのか

ソフトウェア工学には Security や Scalability のような、分野横断でおおむね合意された設計原則がある。著者らはまずそこと対比する。ゲームデザインのピラーは逆で、普遍的であってはならない。もし2作品のピラーが同じなら、プレイヤーはそれを単にクローンと呼ぶ。この「毎回作り直す」性質が研究しにくさの正体でもある。自然言語の断片であり、プロジェクトごとに意味が変わり、社内文書に埋もれる。結果として業界の記事や講演には豊富に登場するのに、著者らが見つけた高レベルの学術的言及は Zagal (2023) と Luo et al. (2021) の2件だけだった。

同時に、現場でのピラー運用には既知の困りごとがある。著者らは同僚らの並行研究(Dyrda et al., 2026)を引いて、曖昧さ、解釈のずれ、実際の設計判断への落とし込みの難しさ、文書構造の不足を挙げる。つまりピラーは「あると良いが運用が難しい道具」だ。ここが LLM の入る隙になる。ピラーの作成は自然言語の生成であり、ピラーの利用は自然言語での判断である。どちらも LLM の得意分野の形をしている — 著者らの出発点はこの形の一致にある。

アプローチ — ピラーを定義し、SPINE に載せる

著者らはまず、学術・業界の文献を横断的に比較してピラーの形式的な定義を与える。曰く、デザインピラーとは開発上の意思決定を方向づけ制約する高レベル原則として機能する規範的な設計構成物であり、(1) その原則に名前を付ける簡潔なタイトル、(2) ゲームが備えるべき体験的または構造的性質を明示する説明文の2つで構成される。ここで構造的性質とはメカニクス、ダイナミクス、進行の設計、インタラクションのループ、ルールの組織といったゲームの形式システムの特徴を指し、体験的性質はプレイヤーの情動・認知・美的な体験、要するにプレイヤー体験を指す。

定義に加えて品質基準が4つ挙がる。Clarity(関係者にとって意味が一義的であること)、Unicity(一本のピラーは一つの原則だけを述べること)、Conciseness(最小限の言葉で表すこと)、Actionability(具体的な設計判断に適用できること)。さらに集合としての制約が3つ。相互無矛盾、網羅性(意図した体験の核を取りこぼさない)、有界な個数(意図的に少数に保つ)。典型的な集合の大きさは規模に応じて3〜5本で、より細かい話は下位の集合で扱うべきだとされる。この定義とチェックリストが、この論文の一番持ち帰りやすい部分だと私は思う。

その上に載るのが SPINE(System for Pillar-based INteractive Experience design)である。Django と Nuxt4 の構成で、LLM は API 経由で差し替え可能。画面ではコアデザインアイデア、ピラー集合、機能アイデアの3種類を書ける。LLM 機能は4つ:個々のピラーの構造分析(タイトルと説明が対応しているか / 説明が連続した文か / 意図が明確か / 一つの側面に絞れているか、を検出し深刻度を1〜5で採点)、構造の修復(LLM 版を採るか元を残すかはユーザーが選ぶ)、ピラー集合の検証(網羅・矛盾・追加提案の3プロンプト)、機能の検証(新機能をピラーに照らして1〜5で採点し理由を書く)。品質基準のうち Conciseness と Actionability は、領域知識に踏み込んだ解釈が必要なため今回は外している。

発見 — 3つの評価が示したこと

予備比較(4.1 節)は gemini-2.0-flash と GPT-4o mini の比較だ。反復利用が前提なので速くて安いモデルを選んだという。題材は学生プロジェクト Ordinary と、著者らがよく知る Sea of Thieves から機能を逆算した各3本のピラー集合。同じピラーに3回ずつ問い合わせ、深刻度の点数がぶれるかを見る(Table 1 が Gemini、Table 2 が GPT)。GPT はピラーが違っても自分が直した後でも、ほぼ同じ点を返した。どのピラーでもタイトルは 3-3-3、Clarity は 4-4-4 という具合だ。Gemini はピラー間で差が出て、自分の改訂版を採点すると警告がほぼ消えた。著者らは「GPT が課題を十分に解釈できていない可能性を示唆する」と控えめに書く。

文章の癖も違った。GPT は説明文を解説文に膨らませ、Gemini はより簡潔に言い直す。興味深いのは共通の失敗だ。Sea of Thieves の1本目と最後の1本を、どちらのモデルも player agency の変種に寄せてしまい、集合としての区別が薄れ、そのゲーム固有の焦点がぼやけた。矛盾検出でも、この2本が似すぎていることを両モデルとも指摘できなかった。著者らはこれをモデルの限界ではなくプロンプト設計の限界だと診断する。明示的な矛盾を探させたが、重複や冗長は探させていなかったからだ。誠実で、かつ実務にそのまま転用できる診断である。

ゲームジャムのケーススタディ(4.2 節)は42時間。研究者1名が SPINE を主たる設計ツールとして使い、修士課程かつインディースタジオで働く学生2名が議論とアイデア出しで参加した。お題は「This Is Fine」のミーム。チームは最初のピラーを embrace sarcastic resilience に整え、ストレスメーターの案を入れると SPINE が unleash controlled rage を提案し、続いて両者の矛盾を指摘した。4本まで増やしたところで再度矛盾を指摘され、rage を composure に言い換えると衝突は減った代わりに「集合全体がこの規模には広すぎる」ことが露呈した。結果、全部捨てて2本に作り直している。出力が正しかったからではなく、出力をきっかけにチームが自分たちの縮尺を発見したから、私はこれを一番説得力のある証拠だと思う。

機能検証も具体的だ。上司から電話とメールが飛ぶ職場という舞台設定を入れると 5/5 の適合と詳細な理由が返り、別の舞台や粒度の違う記述では予想通り低い点が出た。翌日、空間を縦に広げるか狭く締めるかの議論で両案を入れると、SPINE は composure の管理をより支えるとして狭い方を推した。参加者は説明の一部に納得できず、「AI のフィードバックは評価対象のテキストを明示的に参照すべきだ」という提案が出た。以後 SPINE は使われていない。設計の像が固まり、高レベルの判断が残っていなかったからである。

専門家インタビュー(4.3 節)は2スタジオの開発者4名、対面で1人50〜60分。反応は総じて mixed で、1名が非常に肯定的、2名が可能性を強調、1名は批判的だった。その P4 は雇用の置き換え、企業への不信、環境負荷を理由に「自分は LLM に対してどちらかというと偏見がある」と述べつつ、ある用途については pretty decent と評した。彼は構造の修復を何度も回した末に「今のはすっかり水で薄められて抽象的だ」と言い、P5 も「直しても大して変わらない。直すたびに水を足しているみたい」と言った。反復するほど個性が抜ける方向に収束する、という同じ観察である。

一方で P3 は「私はこのピラーをわざと vibe で曖昧にしていた。生成版はどう達成するかがより具体的で、その方が役に立つのでこちらを採る」と述べ、別の場面では「新しいピラーを丸ごと提案されるより、ここが足りないと私を突いてくれる方がいい。私のワークフローにはその方が合うし、私に対してより敬意がある」と語った。P6 は機能へのフィードバックを最良の機能と評し、理由に「より客観的な見方だから」を挙げた。著者らは、最も未成熟な機能である機能評価が最も価値を認められたことを、有望な方向として記録している。

使いどころ — 作る側が今日から使える形

第一に、この定義とチェックリストは LLM を一切使わなくても単体で機能する。もし私が Sokoban ライクを作っているなら、「一手が惜しい(あらゆる操作が取り消しにくい重みを持つこと)」「盤面が全部見える(隠された情報で驚かせないこと)」の2本を立て、Unicity で読み返す。「一手が惜しく、しかも爽快」と書いてしまったら、それは2本に割るべきサインだ。この判定はモデルに投げなくても人間ができる。

第二に、矛盾検出を「答え」ではなく「縮尺の測定器」として使う手がある。ジャムのチームは矛盾を繰り返し指摘され、言葉を直しては衝突を減らしたが、最終的に得たのは正しいピラーではなく「この集合はこの規模には広すぎる」という自覚だった。ハイパーカジュアルの PCG(Procedural Content Generation、コンテンツの自動生成)をやっているなら、生成器に持たせたい性質を全部ピラーとして書き出し、矛盾を潰すのではなく「矛盾が何本出るか」を規模の指標として読む使い方ができる。矛盾が多いのは、たいてい欲張りすぎのしるしだ。

第三に、機能検証は「新入りのための一次フィルタ」として最も現実的だ。ケーススタディの P2 は、大きなチームでは設計判断に深く関わっていないメンバーが、全体で議論する前にアイデアを素早く検証する予備フィルタとして使えると述べた。デイリーパズルを複数人で運営しているなら、ピラーを README に固定し、新機能の提案テンプレートに「どのピラーを支えるか / どのピラーと緊張するか」の2欄を作るだけで、LLM がなくても同じ効果が出る。LLM を挟むなら、P6 の言う「より客観的な見方」の役に限定するのが安全だろう。

第四に、この論文は「使ってはいけない場所」も教えてくれる。書き直し機能を反復させると出力は薄まる方向に収束する。コピーの尖りを出したい局面 — ピラーのタイトル、ゲームのキャッチ、意図的な juxtaposition(対比) — でモデルに任せるのは筋が悪い。逆に「意図が曖昧なまま放置されている箇所を指摘させる」用途は相性が良い。なお Appendix A の55件以上の実在ピラーのデータセットは、それ自体が読み物として有用だ。他人のピラーを並べると「体験的性質を書く流派」と「構造的コミットメントを書く流派」の違いが見えてくる。

限界

著者自身が認めている弱点は多い。ゲームジャムのケーススタディは規模も参加者数も小さく、ツールの設計者が主たる利用者を兼ねたことによるバイアスがあると明記されている。インタビュー研究も標本は moderate で、性能を定量的に測るのではなく機能の探索に焦点を当てたと書いてある。意思決定支援の側は、ジャム中にほとんど使われなかったため証拠が薄いことも認めている。予備比較についても、既存のデータセットやベンチマークが存在しないため探索的な設計にとどまり、適切なデータセットの作成が今後の課題だとされる。

システム面の限界は3点。両研究を通じて繰り返し現れたのは出力品質のばらつきで、4.1 節の分析と整合する。次に信頼と透明性への懸念で、ある開発者はシステムがより透明であるべきだと述べた。改善案としてプロンプトの改良、注釈付きデータセットによる微調整、RAG(Retrieval-Augmented Generation、外部の資料を検索して生成の根拠に足す手法)やエージェント的な手法による文脈の接地が挙がる。

3点目が最も設計的に面白い。複数の参加者が、ピラー間の矛盾は必ずしも望ましくないものではなく、生産的な緊張を作る意図的な設計選択であり得ると指摘した。現行システムは相互排他を前提としていたため、意図的な juxtaposition を確実に認識できなかった。著者らの再設計案は、矛盾をリスクとして提示しつつ、それが意図的かどうかとその目的を designer に明言してもらうよう促す形に和らげることである。

ここから先は Fukai が読んで気づいた点である。第一に、この研究のピラーは全て「新しく作られる」局面で扱われ、「既にあるピラーが開発の進行とともに実態から乖離していく」局面が扱われていない。P6 が自分の経験として「プロジェクトが進むにつれてピラーの関連性は薄れた」と述べているのに、その現象に SPINE は触れていない。私が読む限り、ピラーの本当の困りごとは書き出す瞬間よりも半年後にあるはずだ。

第二に、観察された時間がどれも短い。42時間のジャムと30分のハンズオンである。著者ら自身が「ピラーを定式化するのは短時間で終わる作業ではない」と書いているのに、だ。ジャムでチームが早期に合意できた理由として著者らは「ピラーを早く決めたことが共有ビジョンに寄与した可能性」を挙げるが、「小さいチームで役割が明確だったこと」も同時に挙げていて、この2つを分離する材料は論文の中にない。ここを因果と読むべきではないと私は整理する。

第三に、モデルの選定が予備比較の1回だけで、その後の全評価が gemini-2.0-flash に固定されている。GPT の「どのピラーにも同じ点を返す」挙動は、プロンプトの構造に対する感度の問題である可能性もあり、モデルの能力の問題と切り分けられていない。著者らが redundancy の見落としをプロンプト設計の限界と正しく診断しているのだから、同じ疑いは採点の一様性にも向けられるべきだと私は考える。

Fukai の読み

ここは私の解釈である。私はこの研究を、生成の自動化ではなく「言い直しの強制」の自動化として読みたい。SPINE が実際に効いた瞬間を並べると、モデルが良い文章を書いた場面はほとんどない。効いたのは、矛盾を突かれてチームが自分たちの縮尺に気づいた場面、5/5 が返って舞台設定への確信が固まった場面、P3 が「わざと曖昧にしていた」と自分の意図を言語化した場面だ。どれも、外から一つ質問が来たことでデザイナー側が自分の言葉を作り直している。設計批評の語彙で言えば、これは rubber duck debugging(誰かに説明しようとする過程で自分の誤りに気づく手法)を設計文書に対して行う装置であって、共同執筆者ではない。その読みが正しいなら、出力品質のばらつきという最大の限界は、ばらつきを減らす方向ではなく、出力を答えとして提示しない方向で回避できるはずだ。

おわりに

この論文の隣に置くと地図が見えるのは、まず同じ著者陣の SPARC(Geheeb et al., 2025、arXiv:2509.24730)である。ローカルで動く中規模の LLM に、あらかじめ定めた10の観点でゲームコンセプトを磨かせる試みだ。著者ら自身が本文で、コンセプト作成とピラー作成はしばしば手を取り合って進むので工程上ほぼ同じ地点に立っていると認め、SPINE の焦点がピラーにあることで SPARC を補完すると書いている。この2本は続けて読むのが素直だろう。

もう一つ、著者らが「ピラーの開発は処方ではなく構造化された問いかけの過程である」という先行の指針として引いているのが Despain (2013) である。今回の論文で参加者が求めた nudge(突く)型のフィードバックは、この古い指針への回帰でもある。最後に注意を一つ。FDG '26 はこの記事の公開時点でまだ開催されていない。査読は通っているがコミュニティの議論に晒された論文ではなく、被引用も実質ゼロである。持ち帰るべきはピラーの定義と品質基準という枠組みで、SPINE の有効性については「4名の専門家と2名の学生が短時間触った限りでは概ね好意的」以上のことは、まだ誰にも言えない。

参考文献

本記事で参照した論文と関連資料:

・LLMs are the Ideal Candidate for Mixed-Initiative Game Design Pillar Workflows (Julian Geheeb, Marvin Julian Schwarz, Daniel Dyrda, Georg Groh, 2026, Foundations of Digital Games FDG '26)

・DOI: 10.1145/3815598.3815653(FDG '26 proceedings、査読を通った会議論文)

・関連研究(同じ著者陣): Diamonds in the rough: Transforming SPARCs of imagination into a game concept by leveraging medium sized LLMs (Geheeb, Ivan, Dyrda, Anschütz, Groh, 2025, AI4HGI '25 at ECAI '25)

・本記事で言及した論文内の引用: Zagal (2023) / Luo et al. (2021)(著者らが見つけた数少ないピラーの学術的言及)、Despain (2013)、Ledo et al. (2018) の HCI ツールキット評価類型、Dyrda et al. (2026) のピラー運用の課題に関する並行研究、Eigner and Händler (2024) の LLM 支援下の意思決定に関する研究