審査部門におけるシフトレフトの取り組み

GREE Tech Conference 2026で発表された資料です。
https://techcon.gree.jp/2026/session/TrackB-5

1. 審査部門における シフトレフトの取り組み 株式会社WFS App Reviewチーム 松本 夏樹・三枝 慧
2. プロダクト 松本 夏樹 株式会社WFS App Review（審査）チーム マネージャー • • 2009年にグリー株式会社（現：グリーホー ルディングス株式会社）に入社、プラット フォームの投稿監査やメディアの記事監査 などの業務に従事 2021年よりグリーグループの各プロダクト における企画や表示内容を確認し、リスク を未然に防ぐ審査業務を担当。現在はマ ネージャーとしてチームのマネジメントを 担う。 2
3. 三枝 慧 株式会社WFS App Review（審査）チーム リードクオリティリスクコンサルタント • • 2011年にグリー株式会社（現：グリーホー ルディングス株式会社）に入社以降、一貫 して審査業務に従事 2018年からマネージャーを担当し、2026 年よりリードクオリティリスクコンサルタ ント（スペシャリスト領域）にキャリア チェンジ 3
4. アジェンダ • 審査とは • 審査部門におけるシフトレフトとは • ◦ 過去に取り組んだシフトレフト ◦ 直近のシフトレフト事例 ▪ 1. データ引用とAIチェックによる品質強化、効率化 ▪ 2. 倫理情報の発信によるリスク未然防止 まとめ 4
5. 審査とは 5
6. 審査とは • • ゲーム内の販売物や仕様にリスクがないかを審査する部門 主な業務は企画/仕様を事前に確認する「企画審査」、不当表示リスクを 確認する「表示検証」の二つ 企画審査 これからリリースをする予定のゲーム内の企 画や新しい仕様にリスクがないかを審査 表示検証 リリース直前の開発環境でその施策に不当表 示のリスクがないかを審査 6
7. 審査とは ▪企画審査 • 新しい企画を実施する際に、各種法令、業界ガイドライン、社内ルールに 則って確認を行いリスクがないかを審査する業務 ◦ リスクとは法令に違反するもの、または社内外のルールへの抵触するものを指す ガチャの仕様を変えたい 豪華景品があたるキャン ペーンを実施したい 新しい商材をアプリ内で 販売したい etc 各種法令 • 提供する景品の価格に問題はないか等 業界ガイドライン • ガチャの提供割合の表示方法は適切か等 社内ルール • お客さまに不利益が発生する仕様がないか • 倫理観点で表現に懸念がないか等 7
8. 審査とは ▪表示検証 • • 有償で提供されるガチャや販売物について、リリース前に実機で表示を確 認し、不当表示リスクがないかを審査する業務 QAと似ているが、表示に特化して法令を根拠にチェックを行うという点 が大きな違いとなる QA 「動作」と「表示」を確認 「仕様書」を根拠に検証し、開発の意図し た通りの挙動・表示であるかを確認 表示検証 「表示」に特化して確認 「法令」を根拠に検証し、不当表示のリス クがないかを確認 8
9. 審査の基本的な流れ 企画段階で企画内容について審査を行い、実装後に表示を検証する2段階の 審査フローで、リスクがないことが確認できればリリース承認となる流れ リリース承認 事業部 事業部 審査部門 事業部 審査部門 事業部 ゲーム・ キャンペーン 企画 企画FIX 企画審査 実装 表示検証 施策リリース 9
10. 審査の役割と目指している姿 • 品質を守りつつ事業部の価値を最大化するためのサポート役 ◦ • リスクを未然に防止しつつ、開発スピードを落とさずにリリースできるようサポートを 行っている 高品質な運営で事業を守り、 事業貢献のための付加価値を創出することを 目指している ◦ 審査の働きのおかげで「無事にリリースできた」「やりたいことができるようになった」 と言ってもらえるように様々な取り組みを試みている 高品質運営による 事業部のやりたい リスク未然防止 ことの実現 10
11. 今回のテーマ リスクの未然防止を行いつつ、スムーズな施策リリースを実現できるように 取り組んだシフトレフトを、これまで行ってきたことと直近の事例で紹介 • 審査部門におけるシフトレフトとは • 過去に取り組んだシフトレフト • 直近のシフトレフト事例 1. データ引用とAIチェックによる品質強化、効率化 2. 倫理情報の発信によるリスク未然防止 11
12. 審査部門におけるシフトレフトとは 12
13. 過去に取り組んだシフトレフト 13
14. 企画審査のタイミングについて 実装開始前にリスクの検知ができるように事業部で企画が決まった段階で企 画審査を実施していた リリース承認 事業部 事業部 審査部門 事業部 審査部門 事業部 ゲーム・ キャンペーン 企画 企画FIX 企画審査 実装 表示検証 施策リリース 企画にリスクを検知した場合、プランナーにFBを行い 差し戻し 14
15. 「出来てから」では手戻りが大変 • 企画や設計が完成した後の「最後の砦」として審査するだけでは、実装前 のフェーズであってもリスクが発覚した時の修正のための「手戻り」コス トが膨大になり、リリースブロッカーになってしまう • 企画の草案レベルで「ダメそうなのか行けそうなのか」を上流で確認する 工程が必要 15
16. 「出来てから」では手戻りが大変 • 企画や設計が完成した後の「最後の砦」として審査するだけでは、実装前 のフェーズであってもリスクが発覚した時の修正のための「手戻り」コス トが膨大になり、リリースブロッカーになってしまう • 企画の草案レベルで「ダメそうなのか行けそうなのか」を上流で確認する 工程が必要 企画がFixするよりも早いタイミング（開発工程の上流）で 審査が入ることをシフトレフトと定義 16
17. より早い段階で確認する体制へ 企画の草案段階で審査を実施、より早いタイミングで企画を調整し、審査と 調整済みの内容で企画をFIXすることで手戻り工数の短縮を図る リリース承認 Before ゲーム・ キャンペーン 企画 企画FIX After ゲーム・ キャンペーン 企画 企画 審査 企画 FIX 企画審査 実装 表示検証 施策リリース 企画 承認 実装 表示検証 施策リリース ※手戻り自体極力発生しないように調整するので、あくまでイメージ 17
18. 具体事例 企画段階では提供ができないガチャ仕様が発覚したケースでは 以下のような実装直前での対応が発生していた Before このタイミングで審査 ガチャの 企画を策定 企画の詳細までFIX 実装に向けて 進めている状態 このままでは リリースできない懸念 を検知 実装直前に 仕様変更・調整 など関係者を巻き 込んで対応 18
19. 具体事例 より早いタイミングで審査を実施できるようシフトレフトに取り組み、 企画に懸念が発生した際も一定余裕を持った対応が可能となった After ガチャの 企画を策定 企画初期段階から審査 懸念があれば企画がFIX する前に指摘し調整 審査と調整済みの内容 で企画の詳細までFIX 直前にバタバタと 調整が入ることな く実装へ進む 19
20. 導入の結果 • • 企画を早期に提出いただくよう事業側にも協力を得る必要があったが、相談ポ イントの明示や勉強会（後にeラーニング化）をすることで徐々に浸透 結果として、手戻りが減り一部スムーズに開発進行できるようになった 相談ポイント、納期の一覧化 定期的なeラーニングの実施 20
21. 導入の結果 • • 企画初期段階から仕様を確認する取り組みは定着し、一定効果を得られた しかし「早期に仕様をキャッチアップする」だけであると、アクションとして 受け身な部分が大きい ◦ 手戻りのないスムーズな審査のために他に取り組めることがないか検討 21
22. 導入の結果 • • 企画初期段階から仕様を確認する取り組みは定着し、一定効果を得られた しかし「早期に仕様をキャッチアップする」だけであると、アクションとして 受け身な部分が大きい ◦ 手戻りのないスムーズな審査のために他に取り組めることがないか検討 • より能動的なアクションとして、開発部門やマーケの制作/開発の運用に働き かけて、プロセス全体の品質向上・効率化を目指すことができるのでは？ と考え、これも審査部門としての「シフトレフト」と定義 制作/開発 審査 （表示検証） より踏み込んだ働きかけ リリース 22
23. 直近のシフトレフト事例 23
24. 直近のシフトレフト事例 1. データ引用とAIチェックによる品質強化、効率化 2. 倫理情報の発信によるリスク未然防止 24
25. 1. データ引用とAIチェックによる品質強化、効率化 SNS投稿の作成フロー見直しによる手戻りの抑止 ▪SNS投稿のプロセス ゲーム仕様 の策定 仕様をもと にSNS投稿 を作成 投稿内容 FIX 審査確認 審査の指摘 事項を修正 修正確認 承認 審査承認 済みの内容 で投稿 25
26. 1. データ引用とAIチェックによる品質強化、効率化 具体的なリスク事例 以下仕様のガチャがある • 全部で3周回せるステップアップガチャ • 最高レアリティのキャラクターが「3ステップ目のみ」で1体確定する SNSの投稿文で 「最高レアキャラが確定！」 という訴求内容で文章を作成し た ・1体確定するのは3ステップ目 のみ であることを記載しないと 不当表示になる為、修正が必要 26
27. 1. データ引用とAIチェックによる品質強化、効率化 SNS投稿の作成フロー見直しによる手戻りの抑止 ▪SNS投稿のプロセス ゲーム仕様 の策定 仕様をもと にSNS投稿 を作成 投稿内容 FIX 審査確認 審査の指摘 事項を修正 修正確認 承認 審査承認 済みの内容 で投稿 修正内容にもリスクが残っている場合は再度指摘を行うが 投稿予定日も近いため指摘→修正のラリーが続くと猶予がない 27
28. 1. データ引用とAIチェックによる品質強化、効率化 SNS投稿の作成フロー見直しによる手戻りの抑止 ▪SNS投稿のプロセス ゲーム仕様 の策定 仕様をもと にSNS投稿 を作成 投稿内容 FIX 審査確認 審査の指摘 事項を修正 修正確認 承認 審査承認 済みの内容 で投稿 投稿直前のここの ラリーを減らしたい 28
29. 1. データ引用とAIチェックによる品質強化、効率化 SNS投稿の作成フロー見直しによる手戻りの抑止 ▪SNS投稿のプロセス ゲーム仕様 の策定 仕様をもと にSNS投稿 を作成 投稿内容 FIX 審査確認 審査の指摘 事項を修正 修正確認 承認 審査承認 済みの内容 で投稿 このタイミングにおいて 「間違いが起こりづらい仕組み」 を作ることができると後工程での 指摘→修正のラリーを減らせる 29
30. 1. データ引用とAIチェックによる品質強化、効率化 SNS投稿において間違いが起こる要因を分析 考えられる要因 • SNS投稿のもとになっているゲーム仕様自体に誤りがある • ゲーム仕様は適切だが、投稿文に落とし込む際に齟齬が発生している • ゲーム仕様との齟齬はないが、表現に問題が生じている 30
31. 1. データ引用とAIチェックによる品質強化、効率化 SNS投稿において間違いが起こる要因を分析 考えられる要因 • SNS投稿のもとになっているゲーム仕様自体に誤りがある • ゲーム仕様は適切だが、投稿文に落とし込む際に齟齬が発生している 仕様自体はSNSとは別で事前に審査を行ってい • るため、SNS投稿のタイミングで誤りが検知 されるケースは少ないと想定 ゲーム仕様との齟齬はないが、表現に問題が生じている 31
32. 1. データ引用とAIチェックによる品質強化、効率化 SNS投稿において間違いが起こる要因を分析 考えられる要因 • SNS投稿のもとになっているゲーム仕様自体に誤りがある • ゲーム仕様は適切だが、投稿文に落とし込む際に齟齬が発生している • ゲーム仕様との齟齬はないが、表現に問題が生じている この2つのケースに着目し「誤りなく投稿文に落とし込む」 「最終的な表現から懸念を排除する」ことができないかを検討 32
33. 1. データ引用とAIチェックによる品質強化、効率化 やったこと ①ゲーム仕様は適切だが、投稿文に落とし込む際に齟齬が発生している • 投稿文作成の補助ツールを作成 33
34. 1. データ引用とAIチェックによる品質強化、効率化 やったこと ①ゲーム仕様は適切だが、投稿文に落とし込む際に齟齬が発生している • 投稿文作成の補助ツールを作成 仕様→投稿文に落とし込む際にコピペミスや入力ミスなどの ヒューマンエラーが起こりづらいように、仕様書から基本仕様を引用し 投稿文を作成することができるツールを用意 34
35. 1. データ引用とAIチェックによる品質強化、効率化 やったこと ②ゲーム仕様との齟齬はないが、表現に問題が生じている • 作成した投稿内容をAIチェック 35
36. 1. データ引用とAIチェックによる品質強化、効率化 やったこと ②ゲーム仕様との齟齬はないが、表現に問題が生じている • 作成した投稿内容をAIチェック 作成した投稿内容はAIによって審査観点でチェックされ 投稿作成者がセルフチェックして早いタイミングで リスクの検知と修正をできるようなツールにした 36
37. 1. データ引用とAIチェックによる品質強化、効率化 ツールを利用した制作の流れ 投稿作成者がツール上で投稿予定の施策の 基本情報や該当の仕様書を選択する 37
38. 1. データ引用とAIチェックによる品質強化、効率化 ツールを利用した制作の流れ 選択した施策の情報が 仕様書から関数で引用される 38
39. 1. データ引用とAIチェックによる品質強化、効率化 ツールを利用した制作の流れ 引用された情報を確認し、それをもとにツール上で文章を 作成するとAI関数にて審査観点でのチェックも同時に行い 必要な注意事項などを指摘する 39
40. 1. データ引用とAIチェックによる品質強化、効率化 まとめ 現在導入中のツールによって • 細かい情報も仕様書から自動で引用され、投稿文に反映することが可 能になることが期待できる • どういった注意や免責が必要かをAIが即時に指摘を行うため作成時に すぐに検知が可能になる 40
41. 1. データ引用とAIチェックによる品質強化、効率化 まとめ 現在導入中のツールによって • 細かい情報も仕様書から自動で引用され、投稿文に反映することが可 能になることが期待できる • どういった注意や免責が必要かをAIが即時に指摘を行うため作成時に すぐに検知が可能になる ヒューマンエラーによるミスを抑止しつつも、ゲームの基本情報を自動で反映 できるようにすることで制作・審査双方の工数も同時に削減 後工程でリスクを検知するだけではなく、そもそも間違いや指摘が起こらない運 用にするためにどうすれば実現できるかを考え「シフトレフト」して提案 41
42. 直近のシフトレフト事例 1. データ引用とAIチェックによる品質強化、効率化 2. 倫理情報の発信によるリスク未然防止 42
43. 2. 倫理情報の発信によるリスク未然防止 取り組み説明の前に • 審査で防ごうとしているリスクには、法令等の他に、倫理や国際問題、歴 史問題等に関するいわゆる「炎上」も含まれる これまでの体制 • 企画審査時にリスクをフィードバック • 確定後に修正することは基本なかったものの、修正やモチーフ変更は発生 ゲーム・ キャンペーン 企画 企画 審査 企画 FIX 企画 承認 リスクをフィードバック 43
44. 2. 倫理情報の発信によるリスク未然防止 取り組み説明の前に • 審査で防ごうとしているリスクには、法令等の他に、倫理や国際問題、歴 史問題等に関するいわゆる「炎上」も含まれる これまでの体制 • 企画審査時にリスクをフィードバック • 確定後に修正することは基本なかったものの、修正やモチーフ変更は発生 企画開始時点でリスクが認識 されていれば、そもそも フィードバック自体が不要。 修正、モチーフ変更も不要 ゲーム・ キャンペーン 企画 企画 審査 企画 FIX 企画 承認 リスクをフィードバック 44
45. 2. 倫理情報の発信によるリスク未然防止 • 業界内外での炎上事例や、文化的/歴史的にセンシティブな出来事をslack で定期配信 #倫理アンテナ 45
46. 2. 倫理情報の発信によるリスク未然防止 課題 • 人力での調査、発信には限界がある、、、、 • 一度始めると簡単には辞められない まずやってみたこと • Google Alertで炎上に関するキーワードを登録 • 結果をRSSでslackに自動投稿 46
47. 2. 倫理情報の発信によるリスク未然防止 課題 • 人力での調査、発信には限界がある、、、、 • 一度始めると簡単には辞められない まずやってみたこと • Google Alertで炎上に関するキーワードを登録 • 結果をRSSでslackに自動投稿 • ほしい情報を拾ってくれない • いらない情報までたくさん拾ってくる 47
48. 2. 倫理情報の発信によるリスク未然防止 試行錯誤の結果、、、 • AIを活用して調査、レポート化 1. AI：Gemini （調査・プロンプト実行） 2. AI：Gemini Notebook（整理・検証） 1調査Gemの作成: 予め設定した調査用のGemを作成 1結果のインポート: エクスポートした調査結果を取り込み 2DeepResearch: 思考モードを活用して深掘り調査 2サマリー作成: 要約レポートの作成を指示 3プロンプト投入: 試行錯誤し精度を高めた文章を使用 3ファクトチェックの徹底 ・ 引用リンク検証: 参照元が実際に存在するか確認 4セルフチェック指示: ハルシネーションの有無を自主検証 ・ 日付整合性: 時系列や日付データの正確性を確認 5Docsエクスポート: 調査結果をGoogle Docsへ送出 48
49. 2. 倫理情報の発信によるリスク未然防止 • • ポジティブ ◦ 通常業務の片手間で対応可能に（1配信あたり1h程度） ◦ チャンネル作成数日で300名弱参加 ◦ 開発メンバーから「とても有益なので運用化したい（ので元データが ほしい）」という声掛けをいただく 課題 ◦ チャンネル参加者 ＝ 閲覧数ではない。定量的なKPIが取りづらい ◦ 具体的にどのように役立ったのか、どうしても定性的になりがち 49
50. 2. 倫理情報の発信によるリスク未然防止 • • ポジティブ ◦ 通常業務の片手間で対応可能に（1配信あたり1h程度） ◦ チャンネル作成数日で300名弱参加 ◦ 開発メンバーから「とても有益なので運用化したい（ので元データが ほしい）」という声掛けをいただく 課題 ◦ チャンネル参加者 ＝ 閲覧数ではない。定量的なKPIが取りづらい ◦ 具体的にどのように役立ったのか、どうしても定性的になりがち 定性的であっても「有用だ」という声をいただけているので、定量化は継続して模索 50
51. まとめ 51
52. 振り返りと今後の展望 振り返り ◦ 「より早く情報をキャッチアップすること」だけだと、できることに限りが ある ◦ 時には業務範囲を超えた取り組みも必要 ▪ それによって、「審査」の垣根を越え、開発サイクル全体の改善に繋げ ることができる ▪ 注意点 • 業務範囲を超える ≒ 責任範囲を超えることにもなるので、慎重に コミュニケーションして決める必要がある 今後の展望 ◦ 今回紹介したシフトレフト事例は、取り組みとして定着したわけではなくま だまだ模索していくフェーズ ◦ 成功事例を蓄積し、シフトレフトを当たり前に取り組める組織にしていきた い 52
53. ご清聴ありがとうございました 53