積み上がった20年弱をほどく ― 長期運用プロダクトへの生成AI適用の泥臭い試行錯誤

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

Transcript

1. 積み上がった20年弱をほどく ― 長期運用プロダクトへの生成AI適用の泥臭い試行錯誤 株式会社グリー 川合 悠生
2. 生成AIツールを試してみた。作業が楽になった。 でも、チームには広がっていない。 2
3. AIにスクリーンショットを渡して、画面のデザインを起こしてもらったら、 ガラケー時代のデザインになった。 3
4. 川合 悠生 株式会社グリー GREE事業本部 エンジニアリングマネージャー 経歴 2019年にグリー株式会社（現 グリーホールディングス株式会 社）へ新卒として入社。 GREEプラットフォーム上で20年近く運用が続く長期運営タイ トルの開発チームにて、サーバーサイド開発を中心に設計・実 装を担当。 2022年より同チームのマネージャーとして、開発から運用まで のフロー改善と技術的意思決定をリードしている。 4
5. 今日話すこと 1. 長期運用プロダクト「探検ドリランド」の現実と、社内の3つのフェーズ 2. フェーズ1：汎用チャットでの Good / Bad 3. フェーズ2：参照ファイルでのGood / Bad 4. フェーズ3：コードとハーネスでの Good / Bad 5. 気づき：AIへの手本の渡し方 6. 結果とまとめ 5
6. 「探検ドリランド」運用20年弱、月平均30施策 • GREEプラットフォーム上で サービス展開しているWebソーシャルゲーム 月ごとの施策数（2026年） • 39 2012年リリース。前身ゲームを含めて20年弱 35 • 月平均 約30施策が並行。4週サイクルで毎週メ 31 30 34 32 30 29 29 27 インイベントが入れ替わる 20 • 施策1本＝仕様作成→データ入稿→QA →告知→リリース→振り返り 10 1月 2月 3月 4月 5月 6月 7月 8月 9月 イベント ガチャ キャンペーン 6
7. 業界トレンドと社内展開 フェーズ1→3 2024 2025 ◂ ChatGPT公開 2022/11〜 MCP発表 2024/11 業界トレンド 2026 「context engineering」 OpenAI「Harness engineering」 2025/6 2026/2 Claude Code Anthropic「harness」 2025/2 2025/11 プロンプトエンジニアリング コンテキストエンジニアリング ハーネスエンジニアリング 書き方を工夫する 何を渡すか どう動かすか 社内のツール導入 Gemini 全社導入 2025/2 Next… Claude ほぼ全員 2026/7 Claude 希望者 2025末〜26頭 社内への展開 フェーズ1 フェーズ2 社内にツールの波及 汎用チャットを各自で 業務データは渡せない 連携データの整備 リスクを確認しながらSaaSサービス利用 （株式会社グリー） 連携データは継続して整備 フェーズ3 エージェント型ツールと並走 Claude Code など 動かし方を自分で設計 現場でできたこと （本発表の事例） 文章の推敲・壁打ち 知っていることのアシスト クエリ・仕様質問のチャッ トbot 参照ファイル化 ＋ハーネス／コード適用 分析・仕様書・振り返り 実装・影響調査・障害調査 7
8. フェーズ1: まずは生成AIサービスを試してみる • • • • • Good フェーズ1 メールの添削や資料の整備 仕様書の文章化、企画の壁打ち 生成AIに渡して良い情報が整備される前 できるのは「知っていることのアシスト」まで 知らないことを頼むには、お手本が要る 8
9. フェーズ1: 便利ツールで少し試してみる • Bad フェーズ1 生成AIのAPI × スプレッドシートのリファレン ス × GASで動くチャットbot • 分析クエリの作成、仕様の質問に答える • リファレンスも更新も、 メンバーからはブラックボックス • 積み上がる仕様に対応できていない • 学び：リファレンスは、 チャットbot：依頼文からクエリを組み立てて返す 一人で作って渡すものではない → フェーズ2へ：リファレンスを、みんなで作る 9
10. フェーズ2: リファレンスを渡して精度をあげてみる • Good フェーズ2 分析基盤：スキーマ表を「知識」に渡す → 存在しないカラムが消えた • 仕様書：前回のページを複製し、 変わる項目だけ空欄に • ガチャ売上振り返り：手順を一本化。 比較対象は人が承認してから • • チケット棚卸しの通知、告知文の文体ルール 「前回」を唯一の正解に固定した瞬間、 Gemini Gem：スキーマのスプレッドシートを「知識」に渡したクエリ作成用Gem 実用的になった • 小さくて、毎週必ず発生する作業から 10
11. フェーズ2: ゼロから生成させてみる • 仕様書のゼロベース生成：定常仕様まで書き換わり、レビュー工数が高くつく • 「ハルシネーション」の検証コスト • 仕様が変われば、渡したお手本も更新が必要。スプシやGemは誰が直していく？ • 作った人しか直せないリファレンスは、作った時点から古くなる • 学び：作るだけでは足りない。管理し続ける仕組みが要る Bad フェーズ2 → フェーズ3へ：リファレンスを、みんなで管理する 11
12. フェーズ3: コードもAI（Claude Code）に書かせてみる • • Good フェーズ3 施策実装：統一した実装指針に従う 影響調査・障害調査： 古い実装から仕様を掘り起こす • • 調査とレビューはサブエージェントに分離 効いた理由： 繰り返しの多さ × 一貫した技術方針 • • 「同じことを、同じ方針で、何度も」は資産 参照ファイル＝何を手本に、 左：CLAUDE.md（常時読み込むルール） 右：Claude Codeが配布用PRを作成（内部情報はマスク） ハーネス＝どこを調べるか 12
13. フェーズ3: ハーネスを開発リポジトリに置いてみる • CLAUDE.md：常に読むルールのサマリー • skills：必要なときだけ自動で読む手順書 • agents：調査とレビューを別文脈に • commands：定型フローの入口 • hooks：機械的に止める（次のスライド） フェーズ3 Good CLAUDE.md セッション開始時に必ず読むサマリー skills/ agents/ commands/ hooks/ 必要なときだけ 自動で読む手順書 調査 explorer レビュー reviewer /implement /review … 機械的にブロック implementation/ event/ review/ plan/ コードから読み取れない意図・背景・規約・計画だけを書く • • コードで分かることは書かない 全部リポジトリに置いて、みんなで直す 分析用リポジトリ：全ロール向けのAI基盤も同様の構成に。分析結果は analysis/ に、知見は knowledge/ に残し、みんなで更新する 13
14. hook: 「使うな」と書くのではなく、使えなくする • Good フェーズ3 AIがツールを呼ぶ 問題：EUC-JPのファイルをAIの編集ツールで Edit / Write / sed -i … 触ると文字化けする • 「使うな」と書いても、守られる保証はない • hook：ツール実行の直前に必ず走り、判定 • 拒否時はAIが自分で直せるよう代わりの手順を PreToolUse hook 対象ファイルは EUC-JP か？ LC_ALL=C なしの sed -i か？ NG 理由と代替手順を返す LC_ALL=C sed／iconv／python OK そのまま進む 提示 実例：分析用リポジトリの「SELECT のみ許可」 • 宣言と実装をずらさない • 必ず抜け道を試して塞ぐ 先頭のキーワードしか見ておらず、複文「SELECT 1; ALTER TABLE …」が通る穴が あった → 抜け道を試して検出し、スクリプト側の判定と設定で塞いだ 14
15. フェーズ3: 分析用リポジトリ（全ロール向け） • 利用者はCS・QA・企画・PM・アート。 Good CS ／ QA ／ プランナー ／ PM ／ アート ／ エンジニア 非エンジニアが主役 • 入口はスラッシュコマンド （CS調査・分析・QA観点・月次レポート etc） • フェーズ3 入口：スラッシュコマンド /cs-investigate /analyze /qa-testcases /monthly-report … agents skills knowledge 重い調査を 別文脈で 業務別の手順を 自動で参照 用語・データ源 調査の作法 成果物もリポジトリに保存。 知見は knowledge/ に追加 成果物もリポジトリへ analysis/ • 仕様は開発リポジトリの .claude/ を一次参照 • やりきったら「ナレッジ化」と「再発防止」を提案 • 作る人と使う人が同じ場所を見る cs/ code-review/ （生成時点のスナップショット） 再利用する知見は knowledge/ へ 既定は読取専用：補填やデータ変更は「提案」まで、実行は人間 15
16. フェーズ3: フロントエンドも同じやり方で試してみる • 症状：ガラケー時代のデザインで実装 • 原因：ガラケー時代の実装が未だ同居している • バックエンド＝揃っている／ Bad フェーズ3 フロントエンド＝混ざっている • 試したこと：参照先の限定、お手本指定、 禁止ルール • 今も解決しておらず、デザイナーがFBしやすい ツールをAIにて生成中... • AIにとっては正しい実装 16
17. AIは、目の前のリポジトリをお手本にする • 生成AIは、目の前のコードと ドキュメントをお手本に書く • • • • 20年の積み上げが、そのままお手本になる 揃っている領域 → 強い 共通 効く お手本が揃っている スキーマ／前回の仕様書／同じ形の実装 そのまま真似すれば正解になる 混ざっている領域 → 混ざったまま真似する 精度の問題ではない。渡しているお手本の問題 混ざる お手本が混ざっている 時代の違う実装が同居 混ざったまま、忠実に真似する 17
18. 成功したのは、2つの条件を両方満たしたところだけ • 縦：正解が1つに決まっているか （技術の条件） • 正解 （技術の条件） 1つに 決まっている 横：メンテ性が高いか （運用の条件：直し続けられるか） • 成功したのは、 共通 メンテ性（運用の条件） 高い：直し続けられる 低い：直せない ◎ 成功 △ 使われず 参照ファイル・コード 正解が決まっていて、 みんなで直し続けている チャットbot 正解は決まっていたが、 作った人しか直せなかった × 動かない × 手が出ない フロントエンド 直せる形にはあるが、 時代の違う実装が混ざる 書かれていない手順 正解もお手本もない。 まず手順書に書くところから 両方を満たした左上だけ • • AIに渡す前に、人が正解を1つに決める 混ざって いる 決めた正解は、直し続けられる形で置 く 18
19. 結果 • • • • • • • • 共通 仕様書の作成時間 （1本あたり・概算） 開発：コードの99%をAIが書くように 上がった効率は、プランニング（企画・設計） に回せるように 参照ファイル化した作業：メンバーの7割が利 用、毎日実行 仕様書：作成 約120分→約5分 約120分 99% AIが書いた 影響調査・一次切り分け：作業を並行しながら 分析の足並みが揃った：誰がやっても同じ観点 に 20年分から「正解」を選び出したことが、一番 の変化 選ばれたものも、守られてきた方針も、AIが無 くても価値がある 約5分 開発コードの内訳 AI 99%／人 1% AI導入前 参照ファイル化後 人の1%＝正解が分かっている小修正と、 障害対応で急ぐとき 参照ファイル化した作業の利用状況 メンバーの 7割 が利用 未利用 3割 利用者は毎日実行。誰がやっても同じ観点でアウトプット創出 19
20. まとめ • AIは、様々な情報から生成するため、精度をあげるにはお手本を整備 • 決める：人が正解を1つに決めてから渡す • 置く：みんなで直し続けられる場所に • 確認を組み込む：根拠・下書き・人の承認・機械的なガードを手順に • 守る：決めた方針を守り続ける。一貫した積み重ねが、次のAIの手本 • 一歩目は、日々の小さな作業を手順書に。書けなかった部分が暗黙知 • さらに長期運用を続けていく挑戦ができる余力ができたことが最大の成果 共通 20
21. あなたの現場で、いま AIのお手本は、揃っていますか。 21
22. ご清聴ありがとうございました 22