企業でもAIやLLMを活用できる“仕組み”を作る。CygamesのAI導入手順と運用アーキテクチャ【CEDEC2025】

登壇したのは、株式会社Cygamesの開発運営支援部署マネージャー、エンジニア2部部長を歴任し、2024年4月よりAIテクノロジー 専門役員に就任した金井 大氏、AIテクノロジー エンジニアとして社内AIチャットサービスTaurusの開発と運用を担当する笠原 達也氏、同じくAIテクノロジー エンジニアとして社内AIチャットサービスTaurusの運用やLLMを用いた業務改善検証を担当する築地 圭太氏の3人です。

AIテクノロジー 専門役員の金井 大氏（左）、AIテクノロジー エンジニアの笠原 達也氏（中央）と築地圭太氏（右）

Cygamesでは急速に進化する生成AIに対応すべく、全社横断的な活動を担う「GenerativeAI活用委員会」とAI専門部署「AIテクノロジー」を設立し、ゲーム開発における生成AIの可能性と限界を明確化する取り組みを進めています。

本講演では、LLM（大規模言語モデル）を活用した業務効率化の成果、特に社内AIチャットサービス「Taurus」が、社内のナレッジ（AIが回答生成時に参照する、社内資料やウェブ情報などの知識源）やデータベースなどのさまざまな業務情報を用いた回答を実現したこと、その開発と運用を通じて社内のAIリテラシー向上と業務効率改善に役立ったことが紹介されました。

また、これらの取り組みの中で発生したさまざまな課題と解決策、Microsoft Azure 、OpenAIのPTU（※）環境やAmazon Bedrockなどを用いたLLMベースにおける開発事例が技術面にフォーカスして解説されました。
※　Provisioned Throughput Units。プロンプト処理などにかかるスループットを事前に定めておくことができ、リクエストが急増した場合にも安定したパフォーマンスの維持が期待できる

セッション冒頭では、金井大氏がCygamesにおける生成AIの導入と利用を推進するための組織的な取り組みについて説明しました。金井氏は、生成AIを推進する側はリスクを、利用する側は不安を感じることが多いため、それを解消する戦略的アプローチが必要であるとし、そのための3つの柱を示しました。

1. 生成AIを主業務とする組織の構築

まず第一に、生成AIに関わる人員が他と兼任だと主業務が優先されてしまう課題を解決するため、生成AIを主業務とする組織を設立しました。

2023年4月には、情報システム部門など複数の部署が参加する「生成AI活用委員会」を発足。この委員会が、生成AIの利用促進、ナレッジ蓄積を通じた社内のAIリテラシー向上、ゲーム開発と運用における安心・安全な生成AI利用、そして業務効率化の可能性の明確化と全社的な導入・利活用を推進していきます。

活動内容としては、後に詳述する「生成AI利用ガイドライン」を策定しました。ChatGPT、GitHub Copilot（AIによるプログラミング支援ツール）、Microsoft Azure、OpenAI API、AWS Bedrockなどのさまざまな生成AIサービスやツール、そして各LLMモデルの利用可否判断もしています。

社内広報サイトでの連載記事やSlackチャンネルでの互助会といった利用促進施策。そして生成AIを用いたツール開発や検証支援を行いました。

さらに、兼任による専門性の問題や主業務優先の課題を解決するため、2024年2月にはAI専門部署「AIテクノロジー」を設立しました。この部署は、以下のチームで構成されています。

これらの専任チームがAIを用いた具体的なゲーム開発支援やWebサービス、ツール上の検証・実証を行っています。調査研究実証を行うことで、より高度な課題を解決できるようになったとのこと。

2. 生成AIを安全に使うためのルール策定

組織構成に続いて、利用のためのガイドラインと問い合わせ窓口が整備されました。これは「生成AIを自由に試してみてください」という方針では、逆に使いにくさが生まれるためです。

「生成AIガイドライン」では以下の資料のように、 生成AIへの入力に関するルール、生成AIの使用判断基準、生成AIからの出力に関するルールを明確化し、Confluence（情報共有のためのコラボレーションツール）にて全スタッフが閲覧できるようにしました。

また、ガイドラインの徹底と生成AIの現状への対応のため、2025年4月には全社的な生成AI研修を実施し、99%以上の受講率を達成しました。研修は管理職向け（メンバーのAI利用管理）と一般職向け（安心・安全な利用方法）に体系を分け、生成AIの仕組み（「文脈の断片を何度も出力し回答を作る」など）を分かりやすく解説したそうです。

3. 安心して生成AIを使うための環境整備

ガイドライン整備後は、それに沿ったツールや利用に関する情報を発信し、スタッフが安心して安全にAIを利用できる環境を整備しました。

2023年当初はエンタープライズ契約（法人向けの大規模契約）がない生成AIが多く、利用にさまざまなリスクがあったため、自社でAIチャットツールを開発・運用することで業務改善と生成AIの研究開発を両立させる方針を取りました。

具体的には、2023年5月に社内Slackアプリ「Cygnus」をリリースし、入力が学習に使われず全スタッフが安心して利用できる環境を提供。さらに2023年11月には、RAG（検索拡張生成）により社内ナレッジと連携して業務効率を改善する社内Webアプリ「Taurus」の開発をスタートしました。

各AIチャットツールの利用状況（2025年6月時点）によると、「Cygnus」と「Taurus」は全社展開されており、その他に「ChatGPT」（1,000シート）、「Gemini」（全社展開）が導入されています。さまざまな役割のスタッフが業務内容に対応できるように各種AIチャットツールが展開されており、全スタッフ平均では1日あたり平均2回は利用しているとのことです。

続いて、笠原氏が社内AIチャットツール「Taurus」について、開発の経緯から説明しました。

「Taurus」は、業務ナレッジや社内報などの社内リソース、および外部ウェブサイトの情報を横断的に検索し、AIが社員の質問に対して的確に回答するサービスです。

CygamesスタッフのAIリテラシー向上と業務効率化を目的として社内開発され、スタッフが安心・安全に生成AIを利用し、業務で体験する機会を増やすことでAIリテラシー向上に貢献することを目指しています。例えば、有給休暇について質問すると、社内ドキュメントを検索して回答を生成します。

ChatGPTやGeminiのようにチャット風インターフェイスで使用できる

「Taurus」はGPT-4oなど、数多くのLLMを利用可能です。社内情報源にもアクセスでき、RAGによって情報源を横断して検索し、的確に回答を生成します。また、ゲーム会社ならではの機能として、キャラクターの口調の再現も可能とのことです。

「Taurus」のアーキテクチャ

「Taurus」はウェブアプリとして開発され、バックエンドはAWS（Amazon Web Services）上で稼働しています。利用するLLMは種類に応じて使い分けられており、具体的にはOpenAIのモデルはAzure OpenAI ServiceまたはOpenAI公式APIを通じて、AnthropicのモデルはAWS Bedrockを通じて利用されています。

資料内で説明されているTaurusの構成要素は以下の通りです。

LLMモデルの運用と管理

Cygamesは、Microsoft Azure OpenAIを導入、特に高性能なGPT-4oモデルを社内で安定して、かつ効率的に利用するための工夫をしています。そのポイントは「PTU契約」と「Azure API Management」の組み合わせです。

まず複数のOpenAIモデル（GPT-3.5、GPT-4、GPT-4oなど）の管理にMicrosoft Azure OpenAIを使い、各モデルのデプロイ、リクエスト数、レートリミット、コストを一元的に管理します。特にGPT-4oは、PTU契約により処理能力を確保し、大量のリクエストに対する安定運用を実現しているとのこと。

PTUによりコスト管理と安定運用を両立しようとしている

また、Azure API Managementを活用することで、PTUを全社利用する際にレートリミットを超過する問題へ対応。オーバーしたときに従量課金（PAYG）へ切り替わる設定や、部門や部署ごとの適切なレートリミット設定により、複数の用途での優先順位付けが可能となり、PTUの一元的な利用が実現されています。

PTU契約のメリットとしては、安定した性能、低レイテンシ、コスト予測可能性を、デメリットとして初期費用、契約コミット、利用量減少時のコスト効率悪化などを挙げていました。

なお「Taurus」はAWSでバックエンドを構築しているため、Claud Sonnet（Anthoropic系のLLMモデル）を早期に、かつ簡単に導入できることにも触れられていました。

RAGの精度向上アプローチ

LLMが最新情報や社内固有の知識を持たないこと、そしてハルシネーション（AIがもっともらしく嘘をつくこと）が生じる課題に対し、主に2つのアプローチを採ったそうです。

「Taurus」では質問に応じたデータソースを検索、その結果をプロンプトに含めることでRAGを実装しているとのこと。その適切なデータソースの選択や、検索APIごとのパラメータ決定をTool Useで実現しています。また、アクセス範囲が異なる利用者ごとに適切なRAGを行うため、個人単位のアクセス制御をConfluence、全社共通のアクセス制御にその他のナレッジを使っています。

RAGの検索精度の課題と解決策

Confluence APIの検索機能は、キーワードと文章内の文言が一致しないと目的の情報に到達できない（例：「夏期休暇」で検索しても「夏休み」ではヒットしない）という課題がありました。

これに対し、当初はマルチクエリ検索を検討しましたが、LLMによるマルチクエリ生成が安定しなかったため、根本解決には至りませんでした。

そこで、ベクトル検索（言葉の意味に基づく検索）を導入。これはテキストデータをベクトル（多次元座標）に変換し、意味の類似性（座標の近さ）で検索する手法です。具体的にはAzure Blob Storageにファイルを格納し、ファイルごとにembedding（※）を含めたインデックスを作成することで、Azure AI Searchでのベクトル検索を可能にしました。
※　テキスト・画像・音声などのさまざまなデータを多数のベクトルを持つ数値座標で表現すること。データ同士の座標の近さで類似度を測ることが可能になる

ただ、Azure AI SearchではConfluenceのページごとの認可を解決できないため、最終的なアプローチとして、限定公開のページをConfluence APIを用いた従来型検索、パブリックなページをベクトル検索を使い、組み合わせることで解決を試みました。この結果、半数以上のユーザーが「検索精度が改善された」と回答したそうです。

運用面の取り組みと利用状況

「Taurus」の開発は、まずRAGを搭載したAIチャットアプリを開発し、スタッフに利用してもらうことから始まりました。

運用開始後、スタッフからの「生成AIへの期待と実機能との差異」や「回答の精度・生成速度」に関するフィードバックが多数寄せられました。また、スタッフ間での生成AIツールへの習熟度の違いも明らかになりました。

これらの課題に対し、ユーザーフィードバックによる機能改善と、社内広報・啓蒙活動といった施策を開始。Slackの互助会チャンネルで要望を募集し投票数の多いものから対応しました。また「Taurus」にGood / Badコメント機能を搭載したところ、月に約100件のフィードバックが寄せられました。

利用方法に関するナレッジ不足、検索精度、ハルシネーション判断に関する情報の提示不足といった課題を特定し、改善に活かしました。

アクティブユーザーも順調に増加しており、5月時点でのMAUは約1,400人（全スタッフの約4割）に達した

「Taurus」今後の展望

「Taurus」自体はChatGPTなどのAIチャットサービスと競合するため、無計画な機能拡張は難しく、開発と運用の継続には目的を明確にする必要があると認識しているそうです。

今後は、社内カレンダーや業務情報との密な連携など、社内開発のメリットを最大限に生かしつつ、生成AIに関する研究開発の場として活用を進める方針です。

また、システムの拡張に伴う保守コストが課題となるため、MCP（※）やエージェントなどの新しい技術を活用してシステムを疎にし、一定の保守性を保つ必要があるとまとめました。
※　「Model Context Protocol」の略称。Claudeの開発会社で知られるAnthropicが提唱した、AIモデルと外部システムを連携するための共通規格

続いて、都筑氏がCygamesにおけるLLMの活用事例として、「バグチケット作成効率化」「投稿内容のポジネガ分析」、そして「画像モデレーション」を紹介しました。

1.バグチケット作成効率化

築地氏たちは、ゲームのデバッグ時にバグチケットを起票における入力の手間を削減するため、LLMを活用してバグチケット名から過去の類似チケットを参考に本文を自動生成するウェブアプリを開発しました。

当初はチケットを起票するデバッグチームがカスタムGPTを作成して使用していましたが、利用者数のスケール問題やChatGPTの挙動が変わることによる出力の不安定さから、専用アプリ開発を決断。OpenAI APIのコスト優位性やモデルバージョン固定のメリットを選んだそうです。

開発工数軽減のため、RAGのような複雑なプロンプトエンジニアリングを使うことも想定したそうですが、参照する過去チケット数を大幅に削減（約11万行、2.15Mトークン → 約2,300行、40Kトークン）しても期待した出力が得られることが分かり、シンプルなプロンプトで目的の出力が可能となったそうです。

どんなプロンプトを出すのかなど、精査は利用者に移譲し、利用してもらいながら検討をお願いしているとのこと

プロンプトでLLMに報告分を作成する指示を与える。項目の概要や文体のルール、カテゴリごとの手順に続き、実際のバグチケット例が2,000行程度続く

運用面ではAWS App RunnerとSimple Storage Service（S3）を採用し、マネージドサービスで工数を削減。このアプリは4タイトルで導入・検証中であり、1件あたりにかかる時間を5分から2分に短縮。2025年1月から5月で合計283件の利用、約14.15時間の時間短縮を達成しています。

この取り組みから得られた知見として、プロンプトの管理を利用者に移譲することで、エンジニアと利用者双方の工数削減が可能であること、また複雑なプロンプトエンジニアリングなしでも入力データを見直すことで開発工数を下げられる場合があることが挙げられました。

2. 投稿内容のポジネガ分析

次に、SNSなどの大量のユーザー投稿から、ゲーム要素ごとのポジティブ・ネガティブ・ニュートラルな感情を分析する課題に対し、LLMの活用を行った例が紹介されました。

目標としては、その投稿全体がポジティブかネガティブか、操作感やシナリオ、マッチングなどカテゴリごとのポジネガを分類することと設定。分析手法として、100件の手動ラベリングデータを用いたFew-shot prompting（※）を実施しました。
※　AIの学習において、LLMにいくつか例を呈示することで、出力の精度を上げる技法

システムプロンプトでAIの役割を定義し、判定結果例を与え、ユーザープロンプトで入力テキストと分析観点、出力フォーマットを指定している

結果として、38,750件（うち900件以上が英語）の投稿を分析し、全体判定で86.5%、カテゴリ判定で81.5%の精度を達成。約4営業日分の時短効果（約33時間）を実現しました。

これにより、基本的な感情分類であれば汎用LLMでも十分に解決可能であり、「Taurus」のようなチャットUIだけでなく、LLMをバッチ実行できる環境があれば、さらなる効率化の可能性があるとの知見が得られました。

3. 画像モデレーション（検証中）

さらに、画像コンテンツが倫理面や海外の文化に違反していないかを目視でチェックする負担を軽減するため、LLMによる自動指摘の検証も進められているとのこと。

画像からリスク度合い・理由・対策を説明するフィードバック文章の生成を目標とし、バグチケットと同様にウェブアプリ形式で提供されています。

実行例として、骸骨の表現が中国の倫理規定で禁止される可能性があるため「リスク：中」と判定し、具体的な理由と「骸骨表現を避けるか変更する」「抽象化する」などの対策が提示されました。

この分野における知見として、なぜNGなのかを言語化してクリエイターにフィードバックできるLLMの能力が重要であること、そしてプロンプトを利用者がカスタマイズできるように実装することが、出力やチェック項目の柔軟な調整に繋がることが述べられました。

このように、プロンプトやシステムの一部を利用者（現場の担当者）が管理・修正可能にすることで、エンジニアと利用者双方の工数削減、および検証・開発を高速化できるそうです。

ただし、そのためには現場のスタッフにも生成AIの理解とAIリテラシーが求められ、企業としてはスタッフが安心して生成AIを試行錯誤できる環境を提供する必要があります。

セッションではCygamesにおける生成AIの導入と利用を進めるための組織的な取り組みにより、生成AIの不安とリスクを取り除く必要があったことが伝えられました。その例として、社内AIチャットツール「Taurus」のしくみと運用、およびゲーム開発におけるLLMの活用事例を紹介。最後は「AIでクリエイターの力を引き出す！」という力強いメッセージで締めくくられました。

今回の発表内容は同時に、一般企業や個人が生成AIを導入する場合に直面する、情報流出のリスク・情報の学習利用に関する是非・技術的導入障壁・コストの問題などのハードルについて示唆を含んだものでもあります。

AIによる効率化が、社会全体や個人のあり方へ与える影響、そして多様なプレイヤーが共存できるバランスをいかに見出していけるかが、今後の社会の課題となるはずです。

髙橋 祐介

ゲームメディアや、劇場アニメのプログラム（いわゆるパンフレット）などに関わるようになり四半世紀。「クリエイターがどのように考え、作品を作っているのか」はつねに大きな関心事です。

インディゲームの文化的側面や、クラウドやAIなどゲーム周辺の技術にも興味アリ。