ゲーム開発でのJitera活用ガイド

ゲーム開発では、企画・設計・実装・運用の各工程で大量のコードやドキュメントが蓄積されます。プロジェクトが長期化するほど、開発の背景や設計意図が担当者の記憶に依存し、チームの入れ替わりによって知識が失われやすくなります。

Jiteraは、既存のソースコードやドキュメントをコンテキストとして活用し、ゲーム開発に関わる仕様の可視化、ドキュメント整備、フロントエンド実装、インフラ引き継ぎなどを支援します。本記事では、ゲーム開発会社の開発担当者、情シス、DX推進担当者が検討しやすい活用方法を紹介します。

ゲーム開発現場の課題

大規模・長期プロジェクトによる開発経緯のブラックボックス化

ゲーム開発では、運用開始後も機能追加や改修が続くサービスがあります。時間の経過とともに、なぜその仕様になったのか、どのような判断で現在の構成になったのかが分かりにくくなります。

特に、複数のチームや関連組織が関わるプロジェクトでは、ソースコード、仕様書、不具合対応の履歴などが別々に管理され、現状を把握するために複数の情報源を確認しなければならないことがあります。

担当者交代・退職のたびに発生する引き継ぎコスト

担当者の異動や退職、部署再編が発生すると、過去の開発経緯や運用上の判断を知る人がいなくなることがあります。後任者は、コードや関連資料を一から読み解きながら、現在の仕様と設計意図を把握しなければなりません。

インフラ運用でも、構成自体はコードに残っていても、なぜその構成を採用したのかという意図まで記録されているとは限りません。その結果、引き継ぎのたびに調査や確認が必要になります。

AIツールの個人利用が進む一方、組織として統一・管理できていない

エンジニアがそれぞれ異なるAIツールを利用すると、個人の作業効率は高められる一方、利用状況や成果物を組織として把握しにくくなります。チームに蓄積されたコードやドキュメントを共通のコンテキストとして扱えなければ、AI活用の知見も個人に閉じてしまいます。

情シスやDX推進担当者にとっては、現場の利便性だけでなく、チームで共有できる利用環境や、継続的に知識を蓄積できる仕組みを整えることが重要です。

JiteraをゲームIP開発に使う

既存コードベースのリバースエンジニアリング

既存のソースコードをJiteraに読み込ませることで、コードの構造や処理の関係を確認し、仕様の可視化を進められます。長期運用されているゲームIPや会員基盤など、開発当初の資料が十分に整理されていないシステムでも、現在のコードを起点に仕様を把握できます。

活用の流れは次のとおりです。

1. 対象となるリポジトリや関連ドキュメントを整理する
2. Jiteraにソースコードを読み込ませ、構成や処理の関係を確認する
3. コードから仕様や設計内容を整理し、ドキュメントとして残す
4. 仕様書や不具合対応の履歴などを加え、組織の認識と現在の実態とのギャップを確認する
5. 把握した課題をもとに、改修や運用改善の優先順位を検討する

この方法により、単にコードの説明を生成するだけでなく、現場が認識している仕様と、実際のコードや運用との違いを確認できます。設計書や仕様書の整備が追いついていないプロジェクトでは、既存コードから設計内容を整理する入口として活用できます。

Figmaデザインからのフロントエンドコード生成

Webサイト、イベントページ、キャンペーンページなどのフロントエンド開発では、Figmaで作成したコンポーネントをもとに実装を進める場面があります。Jiteraを活用すると、デザインの意図や既存プロジェクトの構成を踏まえながら、フロントエンドコードの生成を支援できます。

例えば、ボタンに特定のアクションを追加したい場合、必要なモジュールを調査し、実装コードの作成まで進められます。既存のコードベースやドキュメントをコンテキストとして参照することで、プロジェクトのルールに沿った実装を検討しやすくなります。

コンポーネント単位のドキュメント化とテスト整備

コンポーネントごとに仕様や利用方法をドキュメント化し、その内容をもとにコードを生成する運用を整えると、実装とドキュメント整備を別々の作業にしにくくなります。

さらに、コンポーネントの利用条件や想定される入力を整理したうえで、テストケースの作成や検証を支援できます。これまで時間の制約から後回しになっていたドキュメント化やテスト整備を、開発サイクルに組み込みやすくなります。

インフラ・DevOpsへの活用

IaCコードの解析・ドキュメント自動生成

IaC（Infrastructure as Code）で管理されたコードをJiteraに読み込ませると、クラウドリソースの関係性や構成内容を整理し、ドキュメント化できます。

インフラコードには構成そのものが記録されていますが、なぜその構成を採用したのか、どの制約や要件を考慮したのかまでは残りにくいことがあります。コードの解析結果に、既存の設計資料や運用上の背景を組み合わせることで、構成の意図を後任者が読み取りやすい形に整理できます。

生成された内容は、クラウドサービスの公式ドキュメントや実際の環境と照らし合わせて確認することが重要です。特に、変更の影響が大きいクラウドリソースについては、AIの出力をそのまま適用せず、担当者が内容を確認してから利用します。

DevOpsパイプラインのプロジェクトをまたいだ再利用

過去のプロジェクトで構築したDevOpsパイプラインは、そのまま別のプロジェクトへ移植できるとは限りません。利用するサービスや実行環境、権限設定などの違いを確認し、再利用できる部分と変更が必要な部分を整理する必要があります。

Jiteraで既存のパイプラインコードを解析・最適化し、構成や処理の意図をドキュメント化すると、プロジェクトをまたいだ再利用を検討しやすくなります。コンテナ化された実行環境と組み合わせれば、生成コードの動作確認も効率化できます。

導入事例：株式会社カプコン

株式会社カプコンでは、長期プロジェクトの開発経緯やインフラの構成意図を、担当者の記憶だけに依存しない形で整理するためにJiteraを活用しています。株式会社カプコン様の導入事例はこちら。

課題：担当者交代による開発経緯のブラックボックス化

CAPCOM IDでは、立ち上げメンバーの異動や関連組織の体制変更があり、プロジェクトの経緯や背景を十分に把握できない状態から開発に参加するケースがありました。運用開始から5年以上にわたって改修や機能追加が続く中で、現在の仕様を把握するために、コードや関連情報を読み解く必要がありました。

また、エンジニアがAIツールを個人で利用していた一方、組織として利用環境を統一・管理できていないことも課題でした。

活用：リバースエンジニアリングから認識と現実のギャップ確認へ

まずソースコードをJiteraに読み込ませ、リバースエンジニアリングによって仕様を把握しました。その後、社内の情報共有ツールに蓄積された仕様書や不具合対応の経緯などもコンテキストとして読み込ませ、組織が認識している内容と現在の実態とのギャップを確認する活用へ発展しています。

第三者的な視点でコードや関連情報を捉えることで、自分たちが課題だと考えていたことが本当に課題なのか、見えていない問題がないかを客観的に検討できるようになりました。

活用②：IaCコードの解析・ドキュメント化

IaCコードを解析・ドキュメント化し、クラウドリソース間の関係性や構成の意図を、人が読みやすい形に整理しています。これにより、担当者が変わった場合にも、次の担当者が構成を理解しやすくなり、インフラの引き継ぎコストの低減につながっています。

DevOpsパイプラインについても、過去に構築したコードを解析・最適化し、プロジェクトをまたいだ再利用を進めています。

活用③：Figmaからのコード生成と開発成果物の整備

Figmaで作成したコンポーネントをコードに落とし込むフロントエンド開発や、スクリプトで完結するロジックの実装にJiteraを活用しています。

コンポーネントごとにドキュメントを作成し、その内容をもとにコードを生成するサイクルを整えることで、実装と同時に保守性の高いドキュメントを整備しています。コンポーネント単位のドキュメント化やテスト整備など、以前は「やった方がよいと分かっていてもできなかった」取り組みも実現できるようになりました。

効果：解析工数を減らし、エンジニアの役割を変える

リバースエンジニアリングによる仕様の可視化により、ブラックボックス化したコードの解析工数を大幅に削減しています。IaCコードの解析・ドキュメント自動生成によって、インフラ引き継ぎの負担も低減しました。

さらに、これまで実現できなかったドキュメント化やテスト整備が可能になり、チームの開発活動そのものが大きく改善しています。エンジニアの役割も、作業を人に依頼するだけでなく、プロジェクト全体を俯瞰してタスクを整理し、AIに指示を出す動きへと変化しています。結果として、より高付加価値な判断や設計業務に集中しやすい体制づくりにつながっています。

カプコン様の事例を象徴する言葉が、「5年分の暗黙知をAIに引き継ぎ」です。また、Jiteraの活用を通じて、チームとして「課題を正確に言語化する力」を育てているという実感も語られています。

まとめ

ゲーム開発におけるJiteraの活用は、コード生成だけにとどまりません。既存コードから仕様を可視化し、設計意図や運用知識をドキュメントとして残し、担当者交代による知識の断絶を抑えるための仕組みとして活用できます。

開発担当者にとっては、リバースエンジニアリング、フロントエンド実装、テスト整備を支援する開発基盤として、情シスやDX推進担当者にとっては、個人利用に分散したAI活用をチームのコンテキスト共有へ広げる基盤として検討できます。

まずは、長期運用されているゲームIP、担当者交代が発生したシステム、設計意図が残りにくいインフラコードなど、知識の可視化効果が大きい領域から始めるとよいでしょう。AIの出力は担当者が確認し、必要に応じて公式資料や実際の環境と照合しながら、段階的に活用範囲を広げることが重要です。