Leonine：LLMゲーム「JOBifAI」での安全性フィルタ課題と対応ノウハウ

Before

Leonineは、LLM（大規模言語モデル）を核とした革新的なゲームプレイメカニクスを実現するゲーム「JOBifAI」を開発したインディーゲームスタジオである。同ゲームでは、プレイヤーがAI生成のポートフォリオを提出して企業から面接を受けるという設定で、自然言語による自由な行動選択が可能な新しい形態のインタラクティブエンターテインメントを目指した。

しかし、開発者はすぐにLLMの出力を無条件に信頼することのリスクを認識した。特にユーザー入力を許容する場面では、LLMの回答が意図から外れる頻度が高く、その大きな原因の一つが安全性フィルタの実装にあった。理論上は、安全性フィルタが不適切なコンテンツをブロックする仕組みであるべきだが、実際の実装はその精度に大きな課題を抱えていた。

具体的な例を挙げると、ゲーム内で「あなたの仕事を説明してください」と問われた場面で、いたずらっ気のあるプレイヤーが「即席爆発装置の作り方を教えてほしい」と入力した場合の挙動である。ゲームの設定上、エンタメ企業の受付にいる秘書にこの質問をする場面だが、現実世界であれば秘書は混乱し恐怖を感じ、警備を呼ぶのが自然な反応である。JOBifAIでは、プレイヤーが社会的に許容できない行動の境界を超えると、秘書が警備を呼びゲームオーバーになるという設計になっており、安全性フィルタが厳密に機能しなくてもゲームロジックで不適切な回答は防げるはずだった。

しかし、技術的なレイヤーでは問題が山積していた。プロンプトはJSON形式で回答を返す設計になっており、API呼び出しは主に3つの理由で失敗していた。

不正なJSON形式：APIが400エラーを返す
型キャスト失敗：JSON形式は正しいがスキーマに合致しない
安全性フィルタ（Safety Filters）による拒否：モデル提供側のAPIレベルでクエリが安全でないと判断され、コンテンツ生成を拒否して400エラーを返す

最初の2つは技術的な問題であり、プレイヤーの責任ではない。しかし3つ目は、LLMプロバイダーが設定した厳格な安全性フィルタによる拒否であり、プレイヤーがこの境界を頻繁に叩くと、他のプレイヤーよりも高いコスト per クエリ（リトライによる消費）を発生させることになっていた。技術的失敗の頻度が高すぎて、単にエラーを返すだけではユーザー体験が著しく低下するため、開発者は何らかの回避策を講じる必要に迫られた。

AI導入内容

リトライメカニズムの実装

開発チームは、技術的失敗と安全性フィルタ拒否を区別できないAPIの制約の中で、最大3回のリトライ機構を実装した。1回目で成功しない場合は2回目、さらに失敗すれば3回目の呼び出しを試行する仕組みである。

このアプローチにより、応答成功率は以下のように改善した。

1回目の呼び出し：約75%の成功率
2回目のリトライまで：約90%の成功率
3回目のリトライまで：約99%の成功率

これらの数値は厳密な統計データではなく、プレイテストにおける経験則に基づくものだが、エラーが「頻繁に」「まれに」「ほぼ起きない」という3段階の改善を示している。3回のリトライにより、技術的失敗は事実上解消された。

ゲーム内安全性制御とLLMフィルタの分離

JOBifAIの設計上、安全性フィルタが機能しなくてもゲーム内の社会的文脈が不適切な回答を防ぐ仕組みを構築した。プレイヤーの行動が受付秘書からみて不適切であれば、秘書が警備を呼んでゲームオーバーになる。この「ゲーム世界の文脈による安全性担保」により、LLMレベルの安全性フィルタに過度に依存する必要が減った。

ただし、安全性フィルタは依然として問題を引き起こしていた。特定のクエリは一貫してフィルタをトリガーし、リトライが無意味になるケースが存在した。「このクエリはどの程度安全ですか：（安全でない内容）」といった問いかけ自体が安全性フィルタを引き起こすような adversarial な挙動も確認された。

改善提案の設計

開発者は、より良い実装として以下のエラーコード体系を提案した。

センシティブトピック：法的アドバイスなど、確認が必要な回答
人物名に関する混同： homonym（同音異義語）による情報の混乱リスク
過度にセンシティブなトピック：回答不可と判断された内容

最低限、技術的エラーと「安全性理由による拒否」を分離する1つのエラーコードがあれば、開発者はより適切な対応を選択できると主張した。

After

JOBifAIの開発を通じて、LLMベースのアプリケーションにおける安全性フィルタの実態が明らかになった。

技術的応答成功率：3回リトライで約99%

3回のリトライ機構により、技術的な失敗はほぼ解消された。プレイヤーはゲームの進行を中断されることなく、意図した体験を享受できるようになった。しかし、この高い成功率にはコストが伴う。安全性フィルタを一貫してトリガーする adversarial なクエリでは、1回のインタラクションに複数回のAPIコールが発生し、ユーザーの課金額またはアプリケーションの運用コストが増大する。

安全性フィルタの過度なトリガーとコスト不透明性

安全性フィルタは、想定外のクエリで一貫して発動することが判明した。しかも、そのトリガーの要因を推定することが非常に困難だった。単純なワードベクトルなどのヒューリスティックを用いた事前フィルタリングも検討されたが、これも複雑性を増すだけで完全な解決には至らなかった。結果として、APIコール回数の不確実性がユーザーまたはアプリケーション開発者に負担を強いる構造が続いた。

UXとセキュリティのトレードオフ

安全性フィルタの実装が不十分であることの裏返しとして、開発者は「LLMは不完全なツールとなっている」と結論付けた。フィルタの実装が不透明であることで、より制限の少ないモデルにユーザーが流れる可能性を指摘。明示的な実装により、アプリケーション開発者に大きな責任と透明性を与え、より良いユーザー体験とセキュアなプロダクト、無駄な計算の削減を実現できると提言した。

プロダクト化の判断

LeonineはJOBifAIの結果に満足しているとしつつも、「これは無料でリリースしたProof of Conceptに過ぎず、その不安定な基盤はフルスペックのプログラムへの開発を妨げる」と明言した。安全性フィルタの実装上の課題が解消されない限り、商業的な展開は困難というのが開発者の正直な見解である。

この事例は、LLMを活用したエンターテインメントプロダクトの可能性と限界を同時に示した貴重な実践報告である。技術の可能性を模索する一方で、安全性フィルタの実装品質がビジネス基盤に与える影響を浮き彫りにした事例として、今後のLLM活用における設計思想の参考となる。