AIチャットゲームプラットフォーム

00 / 概要

2025年7月から2026年5月までの契約業務です。プレイヤーがゲームシナリオの中でAIキャラクターと会話するコンシューマー向けプロダクトを、新規立ち上げから主導しました。20名のクロスファンクショナルなチームで、プロジェクトリードとしての役割とフルスタックでの実装を兼ね、報告先は代表取締役社長とプロジェクトマネージャーでした。

01 / 背景

シナリオはプレイヤーの発言に応じて変化しますが、全体の流れはシナリオの意図どおりに保たれます。このプロダクトの本当の主題は、会話そのものです。AIキャラクターによくある弱点は、何にでも同意してしまうことです。本プロダクトでは、各返答を複数のAIエージェントからなる小さなエコシステムが組み立てます。キャラクターが無理なく拒否できるようにするためですが、それでも返答は速く返る必要があります。

1年以上前に開発者1名が書いた既存のコードベースはありました。ただし今回の規模の土台にはほとんどならず、プラットフォームは実質的に新しくつくり直すことになりました。

チームはエンジニア、デザイナー、コンテンツ担当、AI開発者、プロジェクトマネージャーで構成されていました。

02 / 制約

速度とリアルさの両立。 返答は複数のAIエージェントに依存していましたが、途切れる会話は会話として成り立ちません。
コンシューマー規模。 非常に大規模なユーザー数になり得る前提で計画されていたため、ユーザー単位で発生するインフラ費用が最初から効いてきます。
複数プロダクトの前提。 プラットフォームは将来さらにAIと対話するアプリケーションを載せる構想だったため、初期の意思決定はそれに耐える必要がありました。

03 / 意思決定

PoCを経て選んだバックエンドのGo

バックエンドの言語は、好みではなく複数のPoC（技術検証）を経て選定されました。評価基準はスケーラビリティ、保守性、速度、そしてAI支援開発とコードベースの相性です。この4つのバランスが最も良かったのがGoでした。スタックの他の部分も同様の方法で選定されました。

マネージドID基盤ではなくKeycloak

Amazon CognitoやAuth0のようなマネージドID基盤は、ユーザー数に応じた課金です。非常に大規模なユーザー数を前提とするコンシューマー向けプロダクトでは、この課金方式が大きなコストになっていたはずです。Keycloakにはユーザー単位の課金がありません。その代わりに受け入れたトレードオフは、認証サーバーが外部から購入するサービスではなく、チーム自身が運用するシステムの一部になることです。

アプリ単位ではなく、プラットフォーム単位のサインイン

Keycloakはアプリケーションの内部ではなく、独自のドメイン上で動かしました。1つのサインインと1つのデータベースを共有するAI対話アプリケーション群、つまりプラットフォーム全体の単一の入口として想定されていたものです。ただし、この契約期間中、その広いプラットフォームは設計上の構想であり、実際に提供されたシステムではありませんでした。

04 / システム

リクエストは、上の図に示した4つの層を通ります。

React、TypeScript、Viteで構築したWebクライアント。データ取得と状態管理にはTanStack。
別ドメイン上で認証と認可を担うKeycloak。
AWS LambdaとAPI Gateway上で動く、Goで書かれたAPI。
データストアとしてのPostgreSQL。

AWSのインフラはTerraformで定義し、開発環境と検証環境を手作業ではなく再現可能な形にしました。

クライアント側で私が実装したのは、チャットのインターフェース、ゲーム進行の画面、そして会話とシナリオの状態を同期させるロジックです。サーバー側では、GoのAPIがチャット履歴の保存、セッション制御、AIの返答を生成する呼び出しを担いました。

05 / AIとの会話

会話そのものがプロダクトであるため、AI側は統合作業ではなく設計の問題でした。私が担ったのはやり取りの形そのものです。モデルに安定して任せられることを前提にチャット体験を設計し、キャラクターを役割から外さないためのプロンプトエンジニアリングを行いました。拒否もでき、それでも人と話しているように感じられる速さで返答することが条件でした。

06 / 進め方

プロジェクトリードとして、計画、技術的な意思決定、コードレビュー、開発標準、技術選定、リリースを担当しました。開発はスプリント単位で進め、実装と並行して計画とタスク管理を行いました。

プロダクトとしての成果はクロスファンクショナルなチーム全体のものであり、リリース状況や結果についてはここでは扱いません。

07 / 振り返り

いま同じ状況なら、AI支援開発のワークフローをチームとして最初から標準化します。共通のワークフローがないために、成果物がチームの共通の期待に届かず手戻りが必要になることが多く、全体の品質が下がりました。Goの選定はAI支援開発を見据えたものでしたが、その周辺のワークフローにも同じだけ意図的な設計が必要でした。