【GCC2026】大規模言語モデルを活用した内製検索サービスの社内展開や業務活用

2026年3月28日(土)に行われた『GAME CREATORS CONFERENCE ’26』の講演資料です。

ChatGPTに代表される大規模言語モデル（LLM）サービスの登場以降、ゲーム開発の現場では、業務への活用や内製サービスの開発が進んでいることと思います。

バンダイナムコスタジオでは、LLMの活用が将来の開発現場の効率化に広く浸透していくと考え、職種や組織を横断した導入活動を行っています。その一例として、社内ナレッジを検索するRAGサービスをグループ企業と共同で内製して展開しています。このサービスは、大量のドキュメントから必要な情報を取得や読解の支援ができるよう機能を提供するものとなっています。具体的には、各種規約ドキュメントの検索、仕様の検索、日々の会議の意思決定の過程の検索や要約、内容理解を支援しています。

本セッションでは、バンダイナムコスタジオ内で展開している社内サービスを通したLLMサービスの活用事例をご紹介しながら、皆様の現場でも業務効率の改善やクリエイティブ支援につながるアイデアなどの参考になれば幸いです。

Transcript

1. 大規模言語モデルを活用した 内製検索サービスの 社内展開や業務活用 株式会社バンダイナムコスタジオ 髙橋 誠史 1
2. 自己紹介 髙橋 誠史 株式会社バンダイナムコスタジオ（2024～） テックスタジオコアテクノロジー 第２グループコアテクノロジー部先端技術課 マネージャー 株式会社バンダイナムコゲームス入社(2009) 株式会社バンダイナムコスタジオ(2012～2019) 株式会社バンダイナムコ研究所(2019～2024) ゲームAIチームのマネージャ、先端技術R&Dディレクター/プロ デューサー、社内のLLM活用の推進など 「新しくてよくわからないけど取り組みましょう」というものを 担当させられることが多い 2
3. バンダイナムコスタジオとは 設立 ２０１２年４月２日 代表 代表取締役社長 内山 大輔 従業員 1,057名 拠点 東京／マレーシア 3
4. 本日の話題 4
5. 本日のアジェンダ • 前振り • バンダイナムコスタジオの大規模言語モデル(LLM)活用につい て • サービス内製化する理由 • 事例紹介 ▪ 社内検索システムNAVICOT導入と運用した知見について ▪ 社内にあるドキュメントに関して回答してくれるシステム の構築 • おわりに • LLMサービスの自社運営 • ローカルLLMについて • まとめ 5
6. 本日の発表のターゲット • 内製したLLM活用サービスの紹介 • LLMを活用した社内サービスを展開してい る方へ • 社内にLLMを活用したサービスを導入を検 討している方へ • 「AIでいい感じにやってくれ」みたいな のをトップダウンで振られてなにからやる か悩んでる方へ • 登壇者のメッセージ • LLMのゲーム開発業務への導入のヒント • 同じようなシステムを構築している方への 手助けになれば幸いです 6
7. バンダイナムコスタジオに おけるLLMサービス活用 7
8. LLMサービスブームの中で • 現在の世の中 • ChatGPTやGeminiなど高性能なLLMサービスをAPIを 通じて社内業務フローに組み込んで使えるようになり ました • バンダイナムコスタジオでは様々な開発業務にお ける文書やドキュメントの検索用途にLLMサービ スを導入し、効率化を図っています 8
9. 開発における文書業務へのLLMサービスの活用 • 本日の中心となる話題 • RAGを使ったナレッジ検索 • 社内規定の検索やワークフローの理解 • 仕様やドキュメントの検索の活用 • 設定の検索への活用 • チーム開発時の各種記録（議事録、日報)など意思決定の記録の検索 • 本日の話題でしないこと • LLMによるコーディング支援周りは本日の話題からは除外してお ります • ソースコードに対して何をやってますか？ • 本日はこちらの話題はしません 9
10. RAGとは • Retrieval-Augmented Generation(RAG) • 検索拡張生成と呼び、大規模言語モデル（LLM）が回答を生成 する際に、社内文書や最新の外部データベースなどの情報源を 検索し、その情報を基に回答を生成する技術 • 利点 • LLM単体では答えられない専門的な質問や最新の情報にも、正 確かつ根拠のある回答を生成できるようになる • LLM単体でおきるハルシネーション（事実に基づかない情報を 生成すること）を抑制し、信頼性を高めることができます • 欠点 • 事前に必要な文書を収集してデータベースを構築する手間があ る 10
11. 内製化する理由 • 製品プロジェクトへの適用を考えた場合 • ゲームの開発情報は外部のAIベンダーに渡せない情報が多い • 進行中のプロジェクトならなおさら外部にはできない • 外部ベンダーのソリューションの活用は性能を高めたりするまでのPoC期間 が長くなりそうな判断 • すぐ使えるものかどうか？ • 長引くと費用がかさむ • いくつかRAGパッケージの検討や評価は行った際の課題 • ニーズ：いつも使ってるサービスを自動クロールしたい • データ整形、フォーマット変更はお客様では厳しい… • ファイルをアップロードする方式は更新時に面倒 • ゲームプロジェクトの資料が一般的なRAGパッケージに入れるには巨大す ぎる • 数1000を超えるの大規模な非構造なドキュメントには対応しない • AIプロジェクトについては納得する性能を出せるまで時間がかかる • 外部で費用が掛かる場合、初日から最高性能出て欲しいと…と思う利用者 • 内製なら育ててく部分で忍耐できる部分も • 蓄積したノウハウが横展開に 11
12. なんでも内製化ではない • Copilot StudioやNotebookLMなどで済みそうなものはやら ない • 数人規模で使うものなら◦ • 不満を感じる規模になるまでは • 利用者数が少なく、利用用途的に深くないナレッジ検索用途 は内製しない • 作るコストとの費用対効果を考える • すぐ立ち上げられるサービスの活用をお願いする 12
13. LLMサービス導入に期待するもの • 開発効率の向上 • プロジェクトや組織フローへの導入 • 調べものや検討の時間の短縮 • 考える時間の短縮、検討の質の向上 • 開発業務におけるドキュメント業務へ の活用 • 職種を問わずに広く活用できるもの • 「誰かが書いた文章は別な人が読む」 ということである 13
14. 社内RAGシステムを内製 して運用した知見について 14
15. 導入前夜 • 日々の業務の中で大量のドキュメントが存 在する • 規程、仕様書、マニュアルなどなど • 知りたい情報がどこにあるのか？ • 知ってる人に聞く • 自分で総当たりで探す • 読んでもよくわからない • 詳細ではあるんだけど… • 複数の資料からの比較や読み比べ 15
16. 求められたもの • 開発の大規模ドキュメントや非構造化データから、あい まいな検索ワードで資料を探したい • 標準の検索機能が弱い お困りのようですね • 検索ができない仕組みで置いてしまっている • 正確にマッチするワードが必要 • 必要な情報を文章化して要点を知りたい • 複数のソースを対象にした比較検討も • ワークフローなど手順をまとめた文章にしてほしい • ドキュメントがどこにあり、内容も一度に知りたい 16
17. NAVICOT…愛称ナビコちゃん • 目標 • 社内でコントロールできるドキュメントであればあらゆるものをLLM サービスと接続してエージェントが回答できる仕組みにしましょう • バンダイナムコスタジオで運用 • 2024年度から開始 • バンダイナムコ研究所で開発したものを導入し知見の蓄積 • 髙橋の役割は開発プロデューサー • 予算、進行、プロジェクト展開など • マスコットキャラはナビコちゃん • 社内コンペで決定 • 自社サービスに自社アーティストのキャラクターを載せるのが社 内で愛されるサービスに育つ第一歩 17
18. 回答機能 Slack版 • Slackでの利用の画面 • Web版もあり • 大量なドキュメントの中からあいまいな文章で検索ができ、要点をまとめて回 答 • 複数のドキュメントにまたがる質問の場合は取り込みながら回答 LLMによって生成した回答 根拠となる関連社内文書 LLMの中にある一般的な知識の回答も可能ですが、注意下記を表示 18
19. 回答機能 Web版 • 簡易検索と深堀レポート(Deep Research)版があります • どちらもSlackの回答よりも長文での回答ができます • 深堀レポートは複数の文献を参照したレポート型の回答 をします • 長文での回答ができるので複数のドキュメントからワークフ ローのようなものをまとめることが可能 • Slack外なのでSlackに入れない協力企業などへの展開も可能 • 社外協力会社の利用を許可してます • Entra IDによる認証を設定ができ、アクセスコントロールが できます • IPによるアクセス元を社内に限るなども対応 • プロジェクトではSlackがお手軽なので利用ケースは少ない • IDEやゲームエンジンのビューに統合して使用している ケースが若干例 Web版の例 19
20. 導入の歴史 • FY2024 • FY2025 プロジェクトへの展開を開始 • コーポレートでの導入からスタート • FY2024に試験的に１プロジェクトで検証 • 元々、社内のフローに関してERPパッケージ企業の • 検証導入でノウハウを掴み展開開始 チャットサービスを導入 • 質問と回答を手入力で登録するシステム • あいまいな検索に弱い • LLMが導入される前のシステムでイマイチだった • 導入後 • 月間1,000件程度のやり取り • 1日40～50件程度、月20日程度の営業日 • DMでも利用可 • 冠婚葬祭などプライベートな規定への質問はオー プンな場で聞きにくいので • 「そんなことも知らないのか」と思われないよう にこっそり聞ける • コーポレートチャットでは9割がプライベート利 用 １月の利用統計 20
21. システム基本構成 自動クロールでDB更新 データベース （自動定期更新） 各種資料 検索 結果 Azure AI Search 問い合わせ 指定チャンネルのログ 検索結果 相談／質問 検索結果 ＋ 相談／質問 回答 回答 @navico-chan Azure OpenAI Service 21
22. システム構成 • Azureを中心としたクラウド基盤で整備 • Azure AI Search • Azure OpenAI Service • Azure Blob Storage ほかのクラウドサービスでも 同じような構成はできるかと 思います • ドキュメントクローラー…内製 • 社内のイントラネット内で自動的に指定したドキュメントを収集 • Confluence,SharePoint,Web,Perforce,RedMineなどに対応 • 月数回のクロール • 収集後はチャンク化やRAG用DBの構築しやすい形式に変換 • Microsoft OfficeやPDF、テキスト、htmlなど対応 22
23. クローラーについて • 社内に設置したPCで実行 • クローリング • Confluence • APIを駆使したページ取得 • SharePoint • Graph APIを駆使した実装 • Jenkins • Perforceなどのデータの取得 ほかのクラウドサービスでも 同じような構成はできるかと 思います • 収集後は基本はAzureのサービスでテキスト抽出やチャンキングをしてい る • 収集したファイルを置くAzure Blob StorageやAzure AI Searchでテ キストの抽出、チャンク化などを行う仕組みがある • ここで不満がある用であれば別途検討する 23
24. NAVICOTの適用分野 • コーポレート規定検索 • 社内規定、規約や既定検索や理解支援 • 申請ワークフローの理解 • 組織ナレッジ 幅広い用途に 展開しています • 社内オープンソース、社内プラグイン検索 • エンジニア組織各種定例会議事録検索 • 技術ナレッジ文書の検索 • 日報、議事録検索 • 仕様書検索、ドキュメント、理解支援 • Confluence仕様ドキュメント検索 • Excel仕様書検索 • 設定、用語検索、理解支援 • 独自の世界設定、用語集からの検索 • 検索用語があいまいでも、かなり的確にドキュメントを 24
25. 組織ナレッジの検索 • エンジニア組織の横断会議の数年分の議事録 • 毎週開催 x 数年分 • 同じエンジンを使ってるプロジェクトの過去事例など • 「UEであれどうやったんだろう」「誰が担当してたの？」 など • 家庭用製品のプロジェクトの各リードエンジニアの情報交換の 定例の議事録など たくさんの整理されてない 情報へのアクセスが楽に • 社内オープンソース、社内プラグイン検索 • 誰かが作った便利なツールなどの検索 • １ページ１トピックで150ページ以上存在する • Confluenceに作成者のTipsや紹介を集約している • リポジトリとは別に見出しとなる紹介ページ • 各種社内勉強会の開催記録 • 資料にあたれる 25
26. プロジェクトのナレッジ検索 • 仕様書検索 • Confluenceに書いてあるものはまだよい • Confluence標準の検索でひっかかるかもしれ ない このシステムの構築で 手を付けたかったのが 仕様書検索でした • 大量のExcel(600ファイル以上)をPerforce で管理してるプロジェクトが存在 • 検索できない • 知ってる人がいればラッキー • 有用性がわかってきたら仕様書の保管や 記述方法について議論して効率化したい 26
27. Excel仕様検索 • Perforceから自動でドキュメントを取得して ベクトルDBの構築を定期スケジュールでやる • 導入プロジェクトでの事例 検索ができなかったものが 検索できるようになりました • ファイル数は600～を超える数 • 検索後の参照にHelix Swarmのリンクを返す • すぐにブラウザで資料の参照ができる • 利用プロジェクトの声 • Perforceで大量のExcelを管理していたが、検索手 段が皆無だったためこの仕組みの構築が大変重宝 されました 27
28. 余談：手ごわいExcelの話 • 歴史あるプロジェクトへの対応の課題 • Excel仕様書が多い 社外のRAGソリューション で対応が難しいのはココ • Excel方眼紙…ではなく • セルにデータがおさまってるならマシ • 問題になりがちなもの • 多用されるエディットボックス • セルに収まってない • 差し込まれる大量の画像や図 • 将来の視覚言語モデル(VLM)の発展に期待 • Gemini 3 FlashのAgentic Visionなどは注視中 • 現状 • 様々なオープンソースや独自開発ツールなどで対応 28
29. エージェンティックな検索 • シリーズものでは複数のRAG DBを構築した運用 • 大規模バージョンアップ型のプロジェクトの場合 • 運営型でバランス調整などの参考に前のバージョンを参照したりなどする検索 • ワンショットで返すのではなく、内部でLLMに検証などもさせることで精度をあげる バージョンAでの仕様は… バージョンBでの仕様では… バージョンAの◦◦の仕様 では技パラメータは どうなってますか？ バージョンBの△ △の仕様 では技パラメータは どうなってますか？ バージョンA RAG DB 問い合わせ バージョンB RAG DB プロジェクト Peforce （Excel) バージョンC RAG DB 仕様のRAG DBはバージョンごとに構築し、問い合わせ時に検索を切り替える 29
30. プロジェクトでのシステム構築事例 • 意思決定に関わる会議や日報シリーズものでは複数のRAG DBを構築した運用 • 長く記録を取るが、古い情報はRAGのDBから外さないと古い情報が出がち • シナリオ、設定辞典は確定情報のみを載せることで日報や議事録などの用語ブレのない回答に役立つ • パートごとの仕様とは、各パートの担当仕様や作業状況やタスクリストなどが入っている • 作業進捗や進捗漏れの確認などにも便利 ◦◦の町の人口は 9,000人です バトルの仕様の決定は どの会議で決まりましたっけ？ ◦◦の町の人口の設定は？ バトルの仕様の決定は ◦◦月△△日の会議です 日報、議事録 RAG DB 問い合わせ シナリオ 設定辞典 RAG DB Confluence パートごとの仕様 RAG DB 仕様のRAG DBはバージョンごとに構築し、問い合わせ時に検索を切り替える 30
31. 事例集：会議議事録・日報検索 • プロジェクト内での意思決定や作業取り組みの検索 • あれはどういう経緯で決まったのか？ • 作業状況の把握 • チケットの漏れがないか？ • チケット化されてないタスクの追跡 • 課題 • 長い開発期間中は用語が変わることがあるので用語リストなど別途 あった方がよい • LLM側が自動で置換をしてくれない • ワンショットで検索ではなく、一回用語集を通して質問内 の用語を最新に直して問い合わせを修正などはありかもし れない • 古い情報は取り込まないようにもしている • NotebookLMのようなタイムライン作成などがあるとよいかも 秘伝の部分は実は クローラーの部分なんです 31
32. アクセス権を分ける • 現状：単一のRAGシステムではない • 理由：知っていい情報が従業員ごとに違う Entra ID ベースでアクセス権を制御 しています • 全従業員アクセス可なのはコーポレートチャットのみ • ただし、コーポレートチャットには開発関連ナレッジは入れな い • プロジェクトや組織単位（職種組織など）で立ち上げ • Slackアプリを利用できる箇所で制限する • 認証をかける(Entra IDベース) • SlackでもDM利用時には対応 • Web版 • Slackに入れない協力企業にも実は提供実績あり 32
33. 開発ドキュメントやマニュアルへの取り組み • 内製ゲームエンジン『SOL-AVES（ソルアヴェス）』との連携 • マニュアルや開発ガイドについて回答するサービスを取り組み中 • インハウス独自のナレッジはインターネットから拾えないため、社内 で整備の必要 • LLMサービスとの組み合わせによって開発者の理解を支援 • ソースコード自体の取り込みは現在非対応 サポートやドキュメントの 改善への活用も一緒に やりたいです • 社内開発環境のドキュメントへの対応での活用案 • ドキュメント製作者側への活用 • LLMにドキュメントに不足している情報などのアドバイス…「足りな い情報はありますか？」「より分かりやすくするにはどうしたらいい ですか？」 • 古い用語の洗い出し • サポートチームへの活用 • ログを保有することでサポートへ活用する • 質問が多い箇所の分析 • LLMによる回答があまり上手じゃない箇所のドキュメントの充実化な ど 33
34. MCPは？ 自動クロールでDB更新 データベース （自動定期更新） 各種資料 検索 結果 Azure AI Search 問い合わせ 検索結果 相談／質問 検索結果 ＋ 相談／質問 回答 回答 MCPでの接続も可 34
35. MCPサーバ機能は？ • 試験的に実装はされているがまだ利用事例は無し • Azure OpenAI ServiceはMCP対応もしやすいので 実装対応は容易 • 現状は検索後にそのままエージェントに何かタスク を投げたり作業させたりがないのでMCPの旨味が少 ない • まだまだMCPを活用しながらの開発スタイルを導入 できている人は限られている • 対象とするドキュメント形式が、非エンジニア職種の利 用が多いためチャット形式が好まれています 皆様のMCP活用の事例 ぜひ聞かせてください 35
36. うまく導入するには？ • コーポレートチャットから導入開始 • 総務、経理、人事の社内手続き、規定の検索 • マニュアルがしっかり揃っていたが探すのは大変 • Confluence、SharePoint • あいまいな検索への対応 プロジェクトに導入する前に 全社で有用性が確認 できる機会が大事 • 全社で使えるのでRAGというものを理解してもらうのによかった • 「AIって便利だな」の機運を作る • 誰でも効果がわかるものから • 最初の取り組みで「がっかり」させない • プロジェクト側からの導入の場合、なかなか横で知ってもらうの が難しかった • プロジェクトで閉じた使い方をするため 36
37. うまくいくために大事だったもの • プロジェクトの導入は負担はできるだけ小さく • 実は「RAGそのものよりも自動ドキュメントクローラーの成果が 大きい」 • 頻繁に更新されるドキュメントを手作業でアップしては無理 • CI/CD連携ができるようであればその方がよい • ユーザーがファイルをアップする方式は手間がかかる • バージョン管理も • Copilot StudioやNotebookLMの導入もここでつまづく • もう手を入れない完成したドキュメントにはよいが • プロジェクト側の導入負担を以下に小さくするかが大事 秘伝の部分は実は クローラーの部分なんです • 用語集ページはあるとよい • 由来や変遷などがあるとよい • ワンショット検索ではなく、一回用語集はさむなど 37
38. 将来に向けた検討事項 • 検索から先へ…応用事例の検討や要望として出てるもの • 開発ドキュメントのチェック • レギュレーションに反していないかのチェック？ • プログラマがやるようなコードレビュー的な仕組みの開発 • 意思決定の過程の可視化 • 「いつ、何がきまったか」 • 「どういう経緯で決まったか」 • 元のドキュメントにミスや変更があったらいっそ直して欲しい 要望は多いんですが 何から対応するといいでしょうね • LLMサービスと連携しやすいドキュメントの書き方、設置手法 • クローラーの開発を頑張らなくてよい方法 38
39. おわりに 39
40. LLMサービスを自社運営してみて • 自社開発・運営してみてよかった点、得られたこと • 社内でコントロールできるドキュメントであればLLMで回答するシステムを気軽に展開 できるようになった • 運用ノウハウが蓄積して立ち上げが早くなりました • Confluence内だけなら数日でサービス開始 • ゲーム開発業務における文書に関する適用は様々な分野で効果がではじめた • ドキュメント担当者が活用されるイメージを掴みやすくなった • 内製（グループ内技術の活用も含む）したことで応用が様々できました • 開発会社自身でサービスの構築など取り組んでおくと応用の幅が広がる • 将来どう広げていくかなども考えれるようになる • 課題 • たまたま社内に人材や専門のグループ企業がいたが、専任で業務するメンバーの確保、 育成が課題 40
41. 世の中の開発ドキュメントにお願い • LLMと紐づけた検索サービスがあると公式に展開が あるとありがたいです • ゲームエンジンの企業などではスタートしてい る …が、しかし運営コストは高いので • RAGなどの構築のためにダウンロード可能な形で 配布いただけるとありがたいです • Webオンリーのドキュメントではない形があり がたいです 41
42. ローカルLLMの話題 • 社内では基本クラウド型でサービスを提供しています • プロジェクト、業務数が多いため今のニーズをカバーする速度にはクラウドが速い • サービスをすぐ立ち上げるため • 物理GPUサーバの対応がきつい • ハードウェア調達の問題 • • 2026年現在、PC、GPU、メモリが高い • 消費電力の大きなものを24時間稼働させるの執務エリアでは禁止 設置場所問題 • 推論ではなく、大規模学習用途にはオンプレを確保したりします • ローカルLLMの検証はしている • 1台のPCでは全社的なサービスカバーはきつい • DGX-SparkやAMD Ryzen • AI Max+マシンなど 開発用途には持ってると便利 • ニッチなデータを扱う特殊なAIモデルが必要な時などは出番あり • ゲームそのものが呼び出すLLMやSLMの検証などサービスとは別に検証機はあると 良い • ゲームエンジンと同時に動かせる AMD Ryzen AI Max+ 395 PC VRAM 96GB割り当て可能 42
43. おわりに • 「社内文書 + LLMサービス」の接続で恩恵を受けられる領域は 多い…自社での取り組みは価値がある • 膨大なドキュメントが既存のソリューションで効果的に性 能が出せないケースが多かったので、内製することで自分 たちの欲しいものを作りました • 社内でコントロールできるドキュメントをなんでもLLMチャッ トで回答できる仕組みを推進 • 自社内ナレッジの活用をスムーズに展開 • 自社内で開発でき、ノウハウの蓄積ができたことで活用の幅を 広げていける • より複雑なタスクができるように改善、改良 • 視覚言語モデルの発展 • マルチモーダルのエンベディングモデルの発展など • Gemini Embbedding 2など 43
44. 共同開発者・謝辞 • 株式会社バンダイナムコ研究所 • 竹内大五郎 • 日下部鉄平 44
45. ご清聴ありがとうございました 45