【CEDEC2025】LLMを活用したゲーム開発支援と、生成AIの利活用を進める組織的な取り組み

by Cygames

Slide 1

Slide 1 text

1/84

Slide 2

Slide 2 text

2/84 はじめに本セッションでは、大規模組織への生成AI導入と利活用に必要となる組織的な取り組みと、LLMを活用したゲーム開発支援機能の開発事例を紹介します。組織が大規模になるほど、生成AIの導入や活用には様々な困難が伴います。これらの課題を乗り越えるためには、戦略的かつ全社的な取り組みが不可欠です。本講演では、Cygamesにおける具体的な事例を交えながら、そのアプローチと成果をご紹介します。

Slide 3

Slide 3 text

3/84 自己紹介金井大 AIテクノロジー / 専門役員 2014年、株式会社Cygamesに合流。研究開発に従事した後、マネージャーおよびエンジニア2部の部長を歴任。 2024年4月からは専門役員として、ゲーム開発におけるAI技術の研究開発と利活用の推進を統括している。笠原達也 AIテクノロジー / エンジニア 2023年より株式会社Cygamesに合流。 Unityエンジニアとしてコンテンツ開発に従事し、現在はAIエンジニアとして社内AIチャットサービスTaurusの開発と運用に取り組んでいる。都築圭太 AIテクノロジー / エンジニア 2015年に株式会社Cygamesへ合流。入社後はデータ分析基盤の運用開発や運用タイトルの不正対策などに従事。現在は社内AIチャットサービスTaurusの運用やLLMを用いた業務改善の検証に取り組んでいる。

Slide 4

Slide 4 text

4/84 アジェンダ • 会社紹介 • 生成AIの導入と利用を推進する組織的な取り組み • 社内AIチャットツール「Taurus」のしくみと運用 • ゲーム開発におけるLLMの活用 • まとめ

Slide 5

Slide 5 text

5/84 会社紹介

Slide 6

Slide 6 text

6/84 株式会社Cygamesについて社名：株式会社Cygames 設立：2011年5月住所：東京都渋谷区南平台町16番17号住友不動産渋谷ガーデンタワー15階事業内容：モバイルゲーム/コンシューマーゲーム/漫画/アニメ/ライツ/eスポーツ/技術研究/投資支援最高のコンテンツを作る会社

Slide 7

Slide 7 text

7/84 ミッションステートメントみんなでたくさんゲームをやる常に「チームサイゲームス」の意識を忘れない最強のブランドを目指す

Slide 8

Slide 8 text

8/84 生成AIの導入と利用を推進する組織的な取り組み

Slide 9

Slide 9 text

9/84 生成AIの導入と利用における課題 • 使い方や技術的な詳細がよくわからない • 既存のワークフローが大きく変わってしまう • 自分たちの仕事がなくなってしまうかも？ • 倫理的もしくは法律的な懸念がある • そもそも使って良いの？生成AIの導入は大きな変化＝不安とリスクこれらを戦略的に取り除く必要がある

Slide 10

Slide 10 text

10/84 不安とリスクを取り除くための取り組み 1. 生成AIを主業務とする組織をつくる – 兼任すると、どうしても主業務が優先されてしまう – 生成AIを主業務とする組織を作ることで、この課題を解決する 2. 生成AIを安全に使うためのルールの策定 – 「自由に使ってください」は逆に使いにくい – 利用のためのガイドライン、問い合わせ窓口を整備する 3. 安心して生成AIを使うための環境の整備 – ガイドラインに沿ったツールや利用に関する情報を発信 – 安心・安全に利用できるようにする

Slide 11

Slide 11 text

11/84 生成AIを主業務とする組織をつくる

Slide 12

Slide 12 text

12/84 「生成AI活用委員会」について 2023年４月に「生成AI活用委員会」を発足情報システム部門など複数の部署が参加生成AIの利用を促進、ナレッジを蓄積し社内のAIリテラシーを向上ゲーム開発と運用にて生成AIを安心/安全に利用できるように業務効率化が生成AIで可能か、どこまでできるか明らかにする生成AIの全社的な導入と利活用の推進を開始

Slide 13

Slide 13 text

13/84 生成AI活用委員会の活動内容 1. 生成AI利用のガイドライン策定 2. 様々な生成AIサービスやツールの利用可否の判断 – ChatGPT/GitHub Copilot/etc.. – Microsoft Azure/OpenAI API/Amazon Bedrock/etc.. – LLMなどのモデルも含む 3. 社内における利用促進施策の実施 – 社内広報サイトによる連載記事 – Slackチャンネルによる互助会 4. 生成AIを用いたツール開発や検証の支援

Slide 14

Slide 14 text

14/84 生成AI活用委員会における活動の課題 1. 委員会メンバーには主業務が存在しており、繁忙期にはそちらが優先される 2. メンバーはAIスペシャリストではないため、専門性が高い要素がわからない AI専門部署「AIテクノロジー」を設立

Slide 15

Slide 15 text

15/84 AI専門部署「AIテクノロジー」について専門役員 AIテクノロジークリエイティブチーム画像や動画生成AIといったクリエイティブな生成AIの研究チーム部署 LLMチーム LLMやエージェントの研究開発とゲーム開発業務への応用先端コンテンツチーム先端技術を活用したコンテンツ開発と支援強化学習チーム強化学習を活用したゲームのバランス調整やデバッグ 2024年2月設立、AIサービスの開発やAIの研究開発を行う

Slide 16

Slide 16 text

16/84 AIテクノロジーの活動内容 1. AI技術やAIサービスの調査・研究・実証 – 最新AI技術や既存AIサービスの研究調査や技術の進展の分析 2. AIによる具体的なゲーム開発支援 – AIを用いたWebサービスやツールの開発と運用 3. Webサービスやツール上での検証や実証専門性が高いメンバーが作業を専任することでより高度な課題が解決できる

Slide 17

Slide 17 text

17/84 生成AIを安全に使うためのルールの策定

Slide 18

Slide 18 text

18/84 生成AIガイドラインの策定上記を元にガイドラインを明文化し Confluenceにて全スタッフが閲覧可能とする生成AI 生成AIへの入力に関するルール生成AIからの出力に関するルール • どの生成AIの利用を許可するか？ • データセットの出自や学習の有無をもって判断 • 生成AIの出力を適応できる業務領域と範囲（コンテンツに含めない） • 出力結果の確認と編集、トレーサビリティ • 業務情報の入力をどこまで許可するか • 著作権法や個人情報保護法などへの法令順守

Slide 19

Slide 19 text

19/84 全社的な生成AI研修の実施ガイドラインの徹底と生成AIの現状に対応するため、 2025年４月に全社的な生成AI研修を実施（受講率は99%以上）管理職・一般職に向けて研修体系を分ける生成AIの仕組みをわかりやすく解説

Slide 20

Slide 20 text

20/84 安心して生成AIを使うための環境の整備

Slide 21

Slide 21 text

21/84 安心して生成AIを使うための環境 2023年当初はEnterprise契約がない生成AIが多く、利用において様々なリスクがあった。 AIチャットツールを開発・運用することで業務改善と生成AIの研究開発が両立可能に 2023年5月にSlackアプリ「Cygnus」をリリース入力が学習に使われず、全スタッフが安心して生成AIを利用可能 2023年11月には、Webアプリ「Taurus」の開発をスタート RAGにより社内ナレッジと連携して業務効率を改善

Slide 22

Slide 22 text

22/84 組織の設立とAIチャットツールの導入 2023年4月「生成AI活用委員会」が発足 2023年11月 Webアプリ「Taurus」アルファ版公開 2024年2月「AIテクノロジー」部署の設立 2025年4月「Gemini Pro」を全社へ展開 2023年5月 GPT-3.5搭載の Slackアプリ「Cygnus」社内公開 2024年1月 ChatGPT Team を導入 2025年1月 ChatGPTを Enterpriseへ移行

Slide 23

Slide 23 text

23/84 各AIチャットツールの利用状況（2025年6月）様々な業務内容に対応できるよう幅広いスタッフへAIチャットツールを展開各サービスにおけるライセンス状況 ChatGPT：1000シート Gemini 全社展開 Cygnus：全社展開 Taurus ：全社展開 :

Slide 24

Slide 24 text

24/84 各AIチャットツールの利用状況（2025年５月）全スタッフで換算すると、一日２回は何らかのAIチャットツールを利用している各サービスにおける１か月あたりの利用回数（リクエスト数） ChatGPT：70551回 Gemini : Cygnus：24525回 Taurus ：53664回 27136回

Slide 25

Slide 25 text

25/84 このパートのまとめ • 生成AIの導入と活用には、不安とリスクを取り除き、利用者が生成AIを安心して利用できる環境を整備する必要があります • 環境整備は、スタッフ個人の活動に頼るのではなく、組織的なサポートを行う必要があります • 委員会のような全社横断で活動する組織だけでなく、 AIについて専門的に活動する組織を設立することで、生成AIの利活用を加速させることができます

Slide 26

Slide 26 text

26/84 社内AIチャットツール「Taurus」のしくみと運用

Slide 27

Slide 27 text

27/84 アジェンダ • Taurusのシステム概要 • RAGの精度を上げるためのアプローチ • 運用面の取り組みと利用状況 • 今後の展望

Slide 28

Slide 28 text

28/84 Taurusのシステム概要

Slide 29

Slide 29 text

29/84 Taurus(タウラス)とは？ CygamesスタッフのAIリテラシーの向上と、業務の効率化を目的として社内で開発された、 AIチャットを行なうWebサービスのこと。自社で開発した生成AIツールを用いることで、スタッフが安心・安全に生成AIを利用でき、業務で生成AIを体験する機会が増えることで AIリテラシーの向上に寄与する

Slide 30

Slide 30 text

30/84

Slide 31

Slide 31 text

31/84 Taurusが持つ機能以下の情報へ接続 • 社内報 • スタッフ情報 • フロアマップ • 会社近辺の飲食店情報 • ソフトウェア利用可否 • 書籍管理システム • フローティングライセンス管理以下のLLMを利用可能 • GPT-4o • GPT-4.1 • o4-mini • o4-mini-high • o3 • Claude 3.7 Sonnet • Claude Sonnet 4

Slide 32

Slide 32 text

32/84 Taurusが持つ機能について社内のナレッジベースやスタッフ情報、外部Webサイトの情報を RAGにより横断的に検索し、LLMにより的確な回答を行うことが可能。ゲーム会社ならではの機能も搭載会話履歴の保存・読込画像の認識キャラクター口調の再現

Slide 33

Slide 33 text

33/84 認証 Taurusのアーキテクチャバックエンド Elastic Load Balancing Amazon EC2 Amazon RDS モニタリング Amazon Cloudwatch LLM Azure AWS Amazon Bedrock Anthropic Claude ナレッジ Confluence + Azure API Management Azure OpenAI Service 社内情報 PTU PayG Azure AI Search Datadog Bing Web Search API Confluence API Microsoft Entra ID Amazon ElastiCache Amazon S3 ユーザー OpenAI OpenAI API • 社内報 • スタッフ情報 • フロアマップ • 書籍管理システム • etc…

Slide 34

Slide 34 text

34/84 Microsoft Azure OpenAIについて GPT-3.5、GPT-4、GPT-4oといった複数モデルの管理のために導入。各モデルのデプロイと、リクエスト数やrate limit、コストを管理している。特にGPT-4oについて、PTU(Provisioning Throughput Unit) 契約を行い処理能力を確保することで、大量のリクエストに対して安定した運用を実現 ※処理能力 = 入出力トークン数 * リクエスト数 PTU契約によりスループットを確保し社内のGPT-4oの利用を一元化 Azure API Management Azure OpenAI Service PTU PayG Azure

Slide 35

Slide 35 text

35/84 Azure API Managementについて PTUはバーストを許容するが、1PTUを全社利用するとrate limitを超える可能性がある。 API ManagementによりPayG(従量課金) へのフォールバックを設定したエンドポイントを用いることで、この問題を回避する。 API Managementにてエンドポイントごとに適切なrate limitを設定することで、１つのPTU を複数の用途で利用する際に、優先順位の設定が可能となる。 Azure API Management Azure OpenAI Service PTU PayG Azure

Slide 36

Slide 36 text

36/84 PTUのメリットとデメリット ● 安定した性能・低レイテンシ – スループットプロビジョンによりピーク時でも遅延が少なく、安定したパフォーマンス・高スループットが得やすい ● コスト効率 – 支払い金額がトークン数やリクエスト数に依存しない ● SLA – ビジネス利用における信頼性が高い ● 初期費用と契約コミット – 月額固定費用が発生する。契約は最低月間ベース、利用が減るとコスト効率が悪化する ● ワークロード予測と運用負荷 – 適切なPTU数の算出には、1分あたりのトークン処理数の見積りが必要 ● 柔軟性 – 自動スケールしない。リージョン別のクォータやPTU割り当てが必要

Slide 37

Slide 37 text

37/84 Amazon Bedrockについて AWSが提供するフルマネージド・サーバーレスの生成 AI基盤。複数のファウンデーションモデル（Anthropic、 Cohere、Stability、Meta、Amazonなど）を単一APIで利用可能。 Anthropic系のLLMに関してモデルの追従速度が速く (Claude Sonnet 3, 3.5, 3.7, 4 は全て即日対応) 、EC2、Lambdaなどの AWSサービスを利用している場合、迅速かつ容易な導入が可能 Amazon Bedrock Anthropic Claude TaurusはAWSでバックエンドが構築されており、容易にClaude対応が可能 AWS

Slide 38

Slide 38 text

38/84 RAGの精度を上げるためのアプローチ

Slide 39

Slide 39 text

39/84 RAGとTool Useについて RAG（Retrieval Augmented Generation）とはプロンプトに対して、外部データを検索して得られた情報を付加する手法のこと Tool Useとはプロンプトに応じて、利用すべきツールとパラメータを LLMが選択する機能のこと LLMが知らない知識を外部データで補い回答のハルシネーションを抑制する RAG（Retrieval Augmented Generation）とは Tool Useとは

Slide 40

Slide 40 text

40/84 TaurusにおけるRAG Taurusでは質問に応じたデータソースを検索し、結果をプロンプトに含めることで、RAGを実装している。検索するには、1. 正しいデータソースを選択し、2. 検索キーワードなど、検索APIごとのパラメータを決める必要がある。TaurusではTool Useを利用して、これを実現している。 LLMが検索するデータソースと APIのパラメータを選択検索結果を LLMが受け取る Tool Use ユーザーが会議室のルールが知りたいと質問ユーザーはデータに基づいた回答を受け取る RAG 検索を実行 Confluence … 社内報データソース 1 2 4 3 6 LLMは受け取った結果に基づいて回答を生成 5

Slide 41

Slide 41 text

41/84 適切なRAGを行うための認可 RAGの対象となる情報は、利用者ごとにアクセスできる範囲が異なるため、適切な認可を行う必要がある。 Taurusでは、大きく全社共通のアクセス制御と個人単位のアクセス制御に分けて認可を行うナレッジ種別認可認可方式備考 Confluence 個人単位 OAuth 2.0 ページごとに権限が異なるその他のナレッジ全社共通 Microsoft Entra ID 社員であれば全員同一権限

Slide 42

Slide 42 text

42/84 ConfluenceへRAGを行うための認可 Cygamesが利用するConfluence Data Center製品にて、 Confluence全体をRAGの対象とできるよう、個人やチームメンバーなどアクセスが制限されているページについても適切に検索できる認可が必要となった OAuth 2.0にて認可したアクセストークンで「Confluence REST APIによる検索」を行い、ユーザーがアクセスできるページのみをRAG対象とする

Slide 43

Slide 43 text

43/84 Confluenceにおける検索精度の課題 Confluence APIにおける検索機能では、検索キーワードと文書内の文言が完全一致しないと目的のページへ到達できないため、Confluence内に情報があるにもかかわらずユーザーがその情報へ辿り着けないという課題がある「夏休みっていつから？」を質問 ● ～… ● ～… ● ～… LLMが検索ワードとして「夏休み」を決定「夏休み」では検索にヒットせず LLMは「情報なし」と判断 Confluenceの情報に到達できない夏期休暇について 1 2 3 5 4

Slide 44

Slide 44 text

44/84 マルチクエリ検索の検討検索のヒット率向上のため、複数の検索クエリを生成して並列に検索、それらの検索結果を統合するアプローチ（マルチクエリ検索）を検討したが、 LLMによるクエリ生成が安定せず、結局欲しい情報が得られなかったり、逆にノイズを生み出すパターンもあった一定の改善が見られたが根本解決に至らず、対応は見送り単3電池が欲しい時の問い合わせ先を教えて「単3電池問い合わせ」「単3電池購入」「単3電池調達」乾電池の利用案内「単3電池」ではヒットせず夏休みっていつから？「夏休み期間」「夏期休暇時期」「サマー休暇いつ」夏期休暇について「夏期休暇」でもヒットする

Slide 45

Slide 45 text

45/84 ベクトル検索（意味に基づく検索） Azure Blob Storageへファイルを格納し、ファイルごとにembeddingを含めたIndexを作成することで、Azure AI Searchによるベクトル検索（意味に基づく検索）が実行可能となる。ただし、Azure AI SearchではConfluenceのページごとの認可を解決できないため、publicなページのみをIndex化して対処する必要がある Confluence Azure Blob Storage データ取り込み＋Index化 Azure AI Search ベクトル検索（意味に基づく検索）により「単3電池」「乾電池」のような表記揺れを解決した検索が可能となる

Slide 46

Slide 46 text

46/84 Taurusにおける最終的なアプローチベクトル検索だけではprivateページへのアクセス問題を解決できないため、Confluence APIを用いた従来型の検索と組み合わせることで、解決を試みる privateなページ(限定公開) は OAuth認証による認可に基づき Confluence APIで検索する publicなページ(全体公開) は Azure AI Searchを用いたベクトル検索を行う 2つの検索結果を組み合わせる事で認可の問題に対応

Slide 47

Slide 47 text

47/84 ハイブリッドアプローチの結果検索精度の改善に関してユーザーにアンケートを実施半数以上のユーザーが改善されたと回答非常に改善されたやや改善された変わらないやや悪化した非常に悪化された以前の検索機能を使用していないので比較できない 42.1％ 21.1％ 18.4％ 2.6％ 5.3％ 10.5％

Slide 48

Slide 48 text

48/84 LLMの性能向上に伴うRAG精度の改善 LLMの性能向上に伴い、検索対象やキーワード選定の精度が向上、自発的に複数の対象を検索したり、キーワードを変えながら検索するなど、 RAGの検索精度が向上することがわかっている。一方で、検索精度の向上を LLMのみに依存することは、検索時間の増大やトークンの消費にもつながる検索応答性やトークン消費改善にベクトル検索は必要。 LLMは複数から選択できると良い

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

50/84 開発方針と運用開始初期の状況取り急ぎRAGを搭載したAIチャットアプリを開発し、それをスタッフに使ってもらうことから開始。運用を開始すると、スタッフの生成AIへの期待と実機能との差異や、回答の精度や生成速度に関するフィードバックが多数寄せられた。また、スタッフ間で生成AIツールへの習熟度の違いもあったため、ユーザーからのフィードバックによる機能改善や、社内広報や啓蒙活動といった施策を開始

Slide 51

Slide 51 text

51/84 ユーザーフィードバックと機能改善のプロセス追加機能などの要望をSlackの互助会チャンネルにて募集し、要望への投票を呼びかけて投票数の多いものから順次対応 Good, Badやコメントを送れるフィードバック機能をTaurusに搭載。月に約100件のフィードバックが寄せられた Taurusの利用方法に関するナレッジの不足、検索精度の課題や、ハルシネーションを判断するための情報の提示が足りない事がわかり、改善に生かすことができた

Slide 52

Slide 52 text

52/84 社内広報と啓蒙活動 • Taurusの使い方、生成AIに関する解説記事と動画を複数リリース • Slackの互助会チャンネルにてユーザーからの情報発信を促進 • Taurusの利用に関するアンケートを実施 • 社内カンファレンスでTaurusの開発に関する講演を実施

Slide 53

Slide 53 text

53/84 月毎の投稿数とアクティブユーザー数 0 200 400 600 800 1000 1200 1400 1600 0 10000 20000 30000 40000 50000 60000 7月 8月 9月 10月 11月 12月 1月 2月 3月 4月 5月 2024年7月のリリース以後、順調に利用件数が増加 2025年5月時点のMAUは約1400人(全スタッフの4割程度) (回) (人)

Slide 54

Slide 54 text

54/84 今後の展望

Slide 55

Slide 55 text

55/84 今後の展望 Taurus自体はChatGPTなどのAIチャットサービスと競合するため、無計画な機能拡張は難しく、開発と運用の継続には目的を明確にする必要がある社内カレンダーや業務情報との密な連携など、社内開発のメリットを最大限に生かしつつ、生成AIに関する研究開発の場として活用を進めるシステムの拡張を続けるとその保守コストが課題となるため、 MCPやエージェントなどの新しい技術を活用してシステムを疎にし、一定の保守性を保つ必要がある

Slide 56

Slide 56 text

56/84 ゲーム開発におけるLLMの活用

Slide 57

Slide 57 text

57/84 アジェンダ • バグチケット作成効率化 • 投稿内容のポジネガ分析 • 画像モデレーション（検証中）

Slide 58

Slide 58 text

58/84 バグチケット作成効率化

Slide 59

Slide 59 text

59/84 バグチケット作成効率化: 概要バグチケット起票時に、複数の項目を手動で埋める必要があり、手間がかかる。 ※チケット起票時に記入する項目チケット内容の一部は過去チケットと類似している。そこを自動で埋められれば効率化できる？課題仮説発生箇所, 再現手順, 正しい挙動, 再現バイナリ, 再現バージョンなど

Slide 60

Slide 60 text

60/84 チケット名チケット本文チケット名から、過去のチケットを参考に指定のフォーマットに合わせてチケット本文を生成するバグチケット作成効率化の目標キャラXがシーンYでメガネをかけてない ■詳細: キャラXがシーンYでメガネをかけていないことを確認しました。こちらご確認のほどよろしくお願いいたします。 ■発生箇所: シーンY ■手順 1.デバコマ＞シーン移動＞キャラビュアーに遷移 2.「キャラX」> 「シーンY」＞の順にタップ ■正しい挙動: メガネをかけていること ■発生頻度: 3/3 ■発生したバイナリ: yyyy/mm/dd 開発版

Slide 61

Slide 61 text

61/84 最終的に作ったもの起票をサポートする専用アプリを開発し、利用者へ提供

Slide 62

Slide 62 text

62/84 アプリ開発までの経緯当初はチケットを起票するデバッグチームがカスタムGPTを作っていた。利用者が試行錯誤しやすくするため。カスタムGPTでもある程度機能したが、以下の課題があった課題解決のため、AIテクノロジーで専用アプリを開発 • 利用者数をスケールさせることが難しいカスタムGPTの利用にはChatGPTのアカウント発行が必要なため • カスタムGPTの出力が安定しない Web版ChatGPTの挙動が急に変わることがあるため。

Slide 63

Slide 63 text

63/84 専用アプリ開発のメリット/デメリット • ChatGPTのアカウント料金と比べて、 OpenAIのAPIの方が安い。特に、Azure OpenAIのPTUを利用する場合、定額利用できる • API利用であればモデルのバージョンを固定できるメリットデメリット • 実装と運用の開発に工数がかかる

Slide 64

Slide 64 text

64/84 アプリ実装上の工夫データを精査して、単純に実装する • 当初は過去チケット情報が全て必要と思われていたため、 RAGなどの対応が必要になる想定だった • しかし、参照するチケット数を削減しても期待した出力が得られることがわかった。結果、複雑なプロンプトエンジニアリングが不要となり、実装工数を削減できた – 見直し前: 約11万行, 2.15Mトークン – 見直し後: 約2,300行, 40kトークン

Slide 65

Slide 65 text

65/84 実際に利用しているプロンプトシンプルに1つのプロンプトを実行するだけの実装 • 参考とする過去チケットはRAGなど使わず全てプロンプトに含める • 再現バージョンなど日々変わるものは、実行時に固定値として入れるあなたは不具合の情報を伝えるAIです。以下の指示に従って、報告文を作成します。【概要】チケットに記載する項目の概要【不具合報告文作成のルール】文体のルール【手順】カテゴリごとに決められた確認手順の方法【参考チケット】実際のチケットを縦に並べたもの。2000行程度プロンプトのイメージ

Slide 66

Slide 66 text

66/84 アプリ運用上の工夫マネージドサービスを採用して、運用工数を下げる AWS App Runner + S3 の構成で提供 AWS App Runner: コンテナなどのホスティングサービス AWS App Runner Amazon S3 ユーザーアプリへのアクセスデータの保存・取得 • EC2やECSと比較して、必要な設定が少なく手軽に利用できる。 • デプロイ時のダウンタイムが少ない。裏で新バージョンを準備し、準備できたら自動でルーティングが切り替わる

Slide 67

Slide 67 text

67/84 アプリの導入結果 • 4タイトルで導入・検証中 • ツール導入の効果: 0.3人日/月程度 • 2025年1月~5月で合計283件の利用 • 1件あたりの短縮時間: 3分/件（5分→2分） • 283件 x 3分/件 ≒ 14.15時間

Slide 68

Slide 68 text

68/84 バグチケット作成効率化: 得られた知見 • プロンプトやシステムなど、全てをエンジニアが管理するのではなく、プロンプトを利用者が管理することで、エンジニア・利用者ともに工数を削減することができる • RAGなどのプロンプトエンジニアリングを使わずに、入力データを見直すことで、開発工数を下げられる場合がある。

Slide 69

Slide 69 text

69/84 投稿内容のポジネガ判定

Slide 70

Slide 70 text

70/84 ※ ゲームの要素の例課題仮説ストーリー・難易度・マッチングなど投稿内容のポジネガ分析: 概要 SNSなどに寄せられた投稿から、ユーザがゲーム内のどの要素に対してどう感じているのかを分析したい。しかし、投稿数が多くて大変。 LLMを使えば、専用の機械学習モデルなどなしでも分類できるのでは？

Slide 71

Slide 71 text

71/84 投稿内容から全体としてのポジネガと、カテゴリごとのポジネガを分類する投稿内容のポジネガ分析: 目標アクションが楽しい！マッチングに時間かかるのだけなんとかして欲しいけど、おすすめはできる。シナリオも熱かった感想の投稿 • 全体: ポジティブ • ポジティブなカテゴリ: 操作感, シナリオ • ネガティブなカテゴリ: マッチング判定結果

Slide 72

Slide 72 text

72/84 投稿内容のポジネガ分析: 利用プロンプト 100件のデータについて手動でラベリングを実施し、それをプロンプトに加えるfew-shot promptingを実施したあなたは[タイトル]の感想を判定するAIです。 # 判定の定義: - ポジティブ: 好意的な意見を述べている場合。 - ネガティブ: 否定的な意見を述べている場合。 - ニュートラル: 特に好意的でも否定的でもなく、客観的な情報や意見を述べている場合。またはゲームと無関係なことを述べている場合。 # 判定結果例: (以下100個ほど縦に並ぶ）テキスト: [実際の投稿] 判定: ポジティブなカテゴリ: ネガティブなカテゴリ: システムプロンプトのイメージ # 入力テキスト [実際の投稿] # 分析する観点 [分析対象のカテゴリ] # 出力フォーマット {{ "explanation": str(日本語), "positive_categories": ["str"], "negative_categories": ["str"], "sentiment": "pos" | "neg" | "neutral” }} ユーザープロンプトのイメージ

Slide 73

Slide 73 text

73/84 投稿内容のポジネガ分析: 結果 • 実施件数: 38750件（900件以上が英語） • 分析精度: 概ね8割程度 • ポジ/ネガ/ニュートラルの判定 86.5% (173/200) • カテゴリの判定 81.5% (163/200) • 効果: 約4営業日分の時短効果 • 約20件/分（0.05 分/件）かかる作業を自動化 • 38750 件 * 0.05分/件 ≒ 約33時間 ≒ 4営業日

Slide 74

Slide 74 text

74/84 投稿内容のポジネガ分析: 得られた知見 • 基本的な感情分類であれば、汎用LLMでも十分に解決可能 • TaurusのようなチャットUIだけでなく、 LLMをバッチ実行できる環境があれば、より効率化を進められる可能性がある

Slide 75

Slide 75 text

75/84 画像モデレーションの効率化

Slide 76

Slide 76 text

76/84 画像モデレーションの効率化: 概要 LLMにチェック項目を指示することで、人間のような違反項目の指摘が実現できる？課題仮説画像コンテンツについて、倫理面や海外の文化に違反していないかなどのチェックが必要。現状、専門チームが目視でチェックしており、大変なので効率化したい。

Slide 77

Slide 77 text

77/84 画像からその画像のリスクの度合いと、その理由や対応方針を説明するフィードバック文章を生成する画像モデレーションの効率化: 目標画像フィードバック文章リスクレベル: 中地域によっては、骸骨表現が不適切とされます。他の表現に置き換えられないか、検討してください

Slide 78

Slide 78 text

78/84 画像モデレーションの効率化: 提供ツール入力画像のチェックツールを作成し、検証中

Slide 79

Slide 79 text

79/84 画像モデレーションの効率化: 実行例検証中ではあるが、プロンプトで指示した内容が指摘できる ▼事案：骸骨表現 ▼リスク：中 ▼理由：中国の倫理規定では骸骨をモチーフにしたキャラクターやデザインが禁止される場合があります。特に中国市場向けのコンテンツでは、骸骨表現が不適切とされる可能性が高いです。 ▼対策： 1. 中国市場向けの場合、骸骨モチーフを避けるか、別のデザインに変更することを検討してください。 2. 骸骨のデザインを抽象化し、骨の形状を直接的に連想させない形に修正する。 3. コンテンツの文脈やターゲット市場を明確にし、必要に応じて注意喚起文を追加する。

Slide 80

Slide 80 text

80/84 画像モデレーションの効率化: 知見 • モデレーションの結果はクリエイターへフィードバックする必要があるため、なぜNGなのかを言語化できることが重要。 LLMを利用することで、修正が必要な理由を説明できる • プロンプトを利用者が修正できるように実装を行うことで、出力やチェック項目を利用者が主体的にカスタマイズできる

Slide 81

Slide 81 text

81/84 このパートのまとめ • 課題を持つスタッフがプロンプトを触ることで検証・開発のスピードを高速化することができる • 上記の実現には、課題感をもつスタッフにも生成AIの理解とAIリテラシーが必要となる • その上で、生成AIをスタッフが安心して試行錯誤できる環境を提供する必要がある

Slide 82

Slide 82 text

82/84 本セッションのまとめ

Slide 83

Slide 83 text

83/84 本セッションのまとめ生成AIの導入と利用を進めるために組織的な取り組みを行い、不安とリスクを取り除く必要があることを述べました。社内AIチャットツール「Taurus」のしくみと運用について紹介し、開発効率を改善するためのシステムとその構造を説明しました。ゲーム開発におけるLLMの活用事例を紹介しました。

Slide 84

Slide 84 text

84/84