DeNAデータアナリストが語る 「ハーネスエンジニアリング」と「AI導入」

492 Views

October 19, 26

スライド概要

概要:
ゲーム事業本部の分析部がAI導入を行った一年間を振り返り、それらから得られた知見を紹介しております。

イベントURL:https://www.geechs.com/newsrelease/20260914_seminar/

profile-image

DeNA が社会の技術向上に貢献するため、業務で得た知見を積極的に外部に発信する、DeNA 公式のアカウントです。DeNA エンジニアの登壇資料をお届けします。

シェア

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

(ダウンロード不可)

関連スライド

各ページのテキスト
1.

DeNA 事業責任者・CTO向け | ギークス株式会社 × DeNA 共催イベント DeNAデータアナリストが語る 「ハーネスエンジニアリング」と「AI導入」 DATE 2026.10.13 SPEAKER 樋富 啓央 / 浜岡 凌誠 COMPANY 株式会社ディー・エヌ・エー

2.

| 自己紹介 AI を安全に広げ続けるには、守りと蓄積を仕組みに埋め込むことが要ります。 本日はハーネスエンジニアリングの観点からお話しします。 樋富 啓央 ゲームサービス事業本部 開発運営統括部 分析部 インサイトアナリティクス第五グループ ● 2021年 DeNA に新卒入社 ● ヘルスケア事業で技術営業・データアナリスト ● ゲームサービス事業本部でデータアナリスト ● 分析部の AI 推進リード。 アナリティクスエンジニアも兼務 本日話すこと | 話す範囲・結論・前提、ハーネスの仕組み、1年間の学び © DeNA Co., Ltd. 2

3.

| 自己紹介 AI の定着には、現場で起こっていることを正しく理解することが大事でした。 本日は AI 導入・定着の観点からお話しします。 浜岡 凌誠 ソリューション本部 エンタープライズ事業部 スポーツプラットフォーム部 ● 2025年 DeNA に新卒入社 ● ゲームサービス事業本部 分析部にデータアナリストとして配属 ● 担当タイトルのアナリスト。AI 推進チームの窓口として自チームへの AI 導入を推進 ● 現在は大規模スポーツプラットフォームの開発・運用に携わる 本日話すこと | 出発点から GitHub Copilot 期・Devin 期・Claude Code 期までの経緯 © DeNA Co., Ltd. 3

4.

| 本日話す範囲 分析部の AI 導入の1年間を、導入担当だった2人の目線でお話しします。 対象はゲームサービス事業部の分析部(約30名)です。 本日お話しするのは、組織的な AI 化の立ち上げ期にあたる1年間です。 DeNA ゲームサービス 事業本部 分析部 (約30名・非エンジニア) AI 推進チーム 各チームへの導入担当 樋富と浜岡はここ © DeNA Co., Ltd. 4

5.

| 本日の内容 分析部の AI 導入の1年間を、4つのまとまりでお話しします。 1 本日の結論 本日話す範囲と、先にお伝えする結論 2 前提: DeNA と分析部が置かれた状況 AI オールイン、ゲーム事業のソフトローンチ戦略、なぜ AI 導入を始めたか 3 経緯: 3世代のツール導入で何が起きたか 出発点から、GitHub Copilot 期 → Devin 期 → Claude Code 期。各期で何に詰まり、何を足したか 4 学び この1年が成立した条件、ハーネスの4層、1年前と現在 © DeNA Co., Ltd. 5

6.

| 本日の結論 定着を起こしたのは性能と恩恵で、その後の拡大を支えたのがハーネスでした。 配布しただけでは使われませんでした。 本日はその1年を、3世代のツール導入 (GitHub Copilot → Devin → Claude Code) で辿ります。 それぞれの期で何が起き、何を加えたかを、このあと順に説明します。 GitHub Copilot 期に起きたこと 配布した 環境と手間、そして性能の壁 → 使われなかった 配布しただけでは定着しない Devin 期に起きたこと ツールの性能と恩恵 やり取りが減る。AI がレビューしてくれる → 定着した 号令ではなく、使う人に返る恩恵で使われ始めた Claude Code 期に加えたもの ハーネスを厚くした AI が仕事をするための道。渡す・させる・させない・ 貯めるの4層 → 安全に広げ続けられた 守りも蓄積も人の努力に頼らず仕組みに埋め込んだ © DeNA Co., Ltd. 6

7.

| 前提①: DeNA の AI オールインとは DeNA は 2025年2月、全社で AI にオールインすると宣言しました。 AI オールインとは、既存事業の競争力向上・新規事業の創出・全社の生産性向上の3本柱で、AI 活用を全社で進める方針です。 そして約3,000人で運営する現業を半分の人員で成長させ、残りの半分で新規事業に挑みます。 人員削減ではなく創造的な仕事へのシフトで、事業の数はこれから増えていきます。 約3,000人 現業を運営する人員 → 半分の人員で現業を成長させる AI を活用して既存事業を伸ばす 残りの半分で新規事業に挑む 10人1組でユニコーンを量産するイメージ → 事業の数が増える 第2の創業と位置づけた 出典: DeNA TechCon 2025 / AI Day (2025-02-05) 南場智子会長の発言(フルスイング by DeNA 全文書き起こし) / 3本柱はフルスイング by DeNA 「掛け声だけではない『AIオールイン』の実態」(2025-12-23)。 © DeNA Co., Ltd. 7

8.

| 前提②: ゲームサービス事業部のソフトローンチ戦略とは 多数のタイトルを先に出して検証し、基準を超えたものだけを本格運用へ進めます。 北米など特定の地域で先に配信し、初期の KPI を検証しながら磨き込みます。 大型タイトルへの先行投資ではなく、小さく検証してヒットの確率を上げるモデルです。 ゲームサービス事業本部としてソフトローンチ戦略に注力していく中で、AI オールインのもと試すタイトルの数が増えると考えました。 多数のタイトル 複数を並行して開発 → 特定地域で先に配信 北米などでソフトローンチ → 初期 KPI を検証 ユーザーの反応を見て磨き込む → 基準を超えたものだけ 本格運用へ マイルストーンで継続可否を判断 © DeNA Co., Ltd. 8

9.

| なぜ AI 導入を始めたか 増える事業に耐えられる分析組織をつくることが、AI 導入の目的でした。 複数のタイトルを並行して検証する戦略では、データで判断する場面がタイトルの数だけ増えますが、 アナリストが比例して増える保証はなく、減ることも想定していました。 分析業務は SQL やデータ基盤と重なり、コードで表せる部分が多いため、AI に任せやすい領域と考えました。 そのため、ソフトローンチ戦略を中心に AI 導入を始めました。 事業もタイトルも増える AI オールイン + ソフトローンチ戦略 ↓ データで判断する場面が増える タイトルの数だけ検証がある アナリストは比例して増えない 1人が1〜2タイトルを担当 ↓ 分析を AI に任せられる形が必要 SQL やデータ基盤と重なり、コードで表せる部分が多い 分析部の現実 (2025年春) ● 約30名。開発環境(Git・ターミナル)に触れた経験があるのは 多くても1〜3人 ● 1人が1〜2タイトルを担当。 タイトルが増えても人は増えず余力がなかった © DeNA Co., Ltd. 9

10.

| 出発点: 1年前の分析部 GitHub Copilot を配る前の分析部は、AI 以前に開発環境に触ったことがない組織でした。 分析部は約30名で、全員が非エンジニアです。 タイトルは増えても人は比例して増えないため、手一杯の状態でした。 人 開発環境に触った経験がある人は 多くても1〜3人 Git・VS Code・ターミナルのいずれも、 日常的に使う人はほとんどいなかった 型 分析の型は個人の頭の中と 手書きの文書にあった 社内文書(Confluence)に手で書き起こす。 残るかどうかは人の意思に依存していた 余力 1人あたり1〜2タイトルを担当し 手一杯だった 新しいやり方を試す時間そのものが 組織に無かった © DeNA Co., Ltd. 10

11.

| どう進めたか①: GitHub Copilot 期のはじまり 分析部ではまず初めに GitHub Copilot をチーム導入しました。 GitHub Copilot はエディタの中で動く、コード補助の AI です。 ※ GitHub Copilot の導入に伴い、GitHub 運用の導入も行いました。 GitHub Copilot チーム導入 Devin Claude Code 2025年4月 7月 10月 2026年1月 4月 7月 10月 帯の期間は各ツールの運用開始と停止の目安です (2025年4月〜2026年10月)。 © DeNA Co., Ltd. 11

12.

| 配布したが使われなかった 想定していた課題と、現場で実際に起きたことは全く違いました。 使われなかった原因は環境と手間、そして AI の性能でした。 加えて、書いたルールが守られないことも後から分かりました。 利用をしてもらうことが非常にハードルが高いことを学びました。 観点 推進側の想定 実際に起きたこと 環境 セキュリティに配慮して 仮想環境で運用すれば安全 全員がエラーで挫折し撤回した。 説明会では準備した側ですら接続に手こずった 使い勝手 使い方を教えれば使ってくれる 認証の手間と動作の重さ。 数ヶ月後に聞いたら「実は普通のチャット AI がメイン」 精度 分析を頼めば結果が返ってくる 何回もやり取りが必要で 「これなら自分で分析した方が早い」 ルール 禁止事項を文書に書けば守られる 削除禁止と書いたテーブルで試したら、 そのまま削除された 4つとも、使い始めてから分かったことだった。 © DeNA Co., Ltd. 12

13.

| どう進めたか②: GitHub Copilot 期から Devin 期へ 環境と手間、そして AI の性能を丸ごと打破してくれる AI エージェントに移りました。 必要な性能水準を満たす AI エージェントを探していたところ、 DeNA が Devin (クラウドで動く自律型の AI エージェント) を全社員に導入し、分析部でも使えるようになりました。 この期には PR を出したくなる仕組みを導入し、期の後半にはデータ基盤チームとハーネスの話も始めました。 GitHub Copilot 定着はほぼゼロ Devin 初めて定着 Claude Code 2025年4月 7月 10月 2026年1月 4月 7月 10月 選定理由 1 開発環境に触らないメンバーを そのまま引き上げられる 選定理由 2 ブラウザで完結し、 ローカル環境の壁を丸ごと回避できる 選定理由 3 当時のエージェントの中で 他を大きく上回る性能だった © DeNA Co., Ltd. 13

14.

| PR を出したくなる仕組みが回り始めた 記録のために出す PR が、レビューしてもらえるから出したい PR に変わりました。 Devin と GitHub が連携し、PR を出した瞬間に自動でレビューが返る、個人に恩恵がある PR 文化が完成しました。 ● 成果物は GitHub に PR で出す運用にした。 ルールや手順書に「成果物ができたら PR を出す」と書き、AI 自身が出すように促した。 まずは1人1リポジトリ(成果物の置き場)で、 AI の PR を自分でマージする練習から始めた ● PR を出すと Devin の GitHub 連携が起動し、 AI のレビューが即座に返る ● レビューが返るから出したくなり、 出した分だけ成果物がリポジトリに貯まる アナリスト 分析して PR を出す → PR 成果物がリポジトリに残る AI が自動レビュー 出した瞬間に返ってくる ← GitHub 連携 PR 作成を起点に起動 直して再提出 レビューがあるから出したい ↺ また出したくなる 恩恵が次の PR を生む © DeNA Co., Ltd. 14

15.

| どう進めたか③: Devin 期から Claude Code 期へ (コストの急増) 移行の引き金は性能ではなく、コストの急増でした。 チーム内の Devin 利用率が高まった次の課題として、月間の利用枠 (ACU) が枯渇する問題に当たりました。 資料の散在を直すなどの対策を打ちましたが、根本的な改善にはなりませんでした。 移行先は、コストが下がり性能を落とさないことを条件に Claude Code (ローカルで動く AI エージェント) を選びました。 GitHub Copilot Devin コスト急増 Claude Code 並走開始 2025年4月 7月 10月 2026年1月 4月 7月 10月 © DeNA Co., Ltd. 15

16.

| どう進めたか④: Claude Code 期 (現在) 導入から約1ヶ月で、チームのメンバーが Claude Code を日常利用するようになりました。 Devin 期に PR 文化と AI エージェントの活用方法が身についていたことが下地になりました。 ただし Claude Code は Devin と異なり、クラウド環境ではなくローカル環境で動きます。 そのため得意な数名が先に環境を整えてから全員に広げ、安全に使う仕組みの整備も同時に始めました。 GitHub Copilot Devin Claude Code 1ヶ月で日常利用 2025年4月 7月 10月 2026年1月 4月 7月 10月 環境は先に整えた 得意な数名が先に試して環境を整え、 そのうえで全員に広げた ローカル環境で実行 クラウド環境の Devin と違い、 個人の PC と権限で動く 仕組みの整備へ 使い始めると同時に、 安全に使うためのハーネスの整備へ © DeNA Co., Ltd. 16

17.

| ルールは文書だけでは守られない。機械で止める 止める仕組みを何重にも重ね、人間が打っても止まるようにしました。 文書のルールは AI にすり抜けられたため、Devin 期は権限を区切ることで凌ぎました。 Claude Code 期はデータ基盤チームと共に、実行そのものを止めるハーネスを整備しました。 1 コマンドの実行直前に割り込んで遮断するフック。 データ削除・破壊的な git 操作・秘密情報の読み取り・外部通信 2 許可した範囲の外にあるクラウド資源への操作を遮断するフック 3 ツール自体の拒否リスト。 認証の書き換えや回り道の実行を最初から許さない 4 サンドボックス。書き込み先とネットワークを閉じる 土台: 全操作を仕組み専用の権限(サービスアカウント)で実行し、 個人の権限を持ち込まない $ ファイルを削除するコマンド blocked: この操作は許可されていません AI が実行しても人間が打っても、同じ場所で止まる 止まる操作の一例です © DeNA Co., Ltd. 17

18.

| ハーネスの実物: 何を禁じ、実際にどう止まるか 禁止はルール(日本語)で AI に伝え、フック(コード)で実行の直前に止めます。 ルールは、何を・なぜ禁じるかを AI に伝える文書で、私たちアナリストが書いています。 文書だけでは守られる保証がないため、止める仕組みをデータ基盤チームと組んで用意しました。 AI に伝える: ルール(日本語の文書) 何を禁じ、なぜ禁じるかを書いておく ● 禁止する操作(データの削除・破壊的な git 操作・秘密情報の読み取り・ 許可外のクラウド資源) ● 禁止する理由と、どうしても必要なときの正規の手順(申請・人が実行) ● AI は作業のたびにこれを読み込んでから動く ただし文書だけでは、AI にすり抜けられることがある。 機械が止める: フック(コード) 禁止した操作は、実行される前に止まる $ rm scratch/old_file.csv blocked: rm requires explicit user reconfirmation $ bq ls --project_id=別プロジェクト blocked: project not in allow-list 止まる操作の一例です。 文書に書くだけでなく、打っても通らない状態にしてある。 全操作は仕組み専用のアカウントで実行し、個人の権限は使わない。 © DeNA Co., Ltd. 18

19.

| 分析する・貯まる・測る・直すのサイクルが完成 分析して終わりではなく、測って直し続けるからエンジニアリングと呼んでいます。 ハーネス導入後、安全に利用できる環境で以下のサイクルを回し、成果物が残る仕組みを作りました。 ● 分析する: スキル(AI への手順書)に沿って分析する。 設計書は人が承認しないと次工程へ進めない ● 貯まる: 分析フローの最後が PR 提出。 出したくなる仕組みから、出さなくても貯まる仕組みへ。 成果物が必ずリポジトリに残り、次の AI の材料になる ● 測る: 成果物が放置されていないか、 どの工程で詰まるかを週次で点検する ● 直す: 週1の改善会で詰まっている箇所から直し、 手順(スキル)と制約(ルール)を更新する 分析する スキルに沿って進める ↓ 貯まる 最後の工程が PR 提出 ↑ 測る 放置と詰まりを 週次で点検 ← 直す 週1の改善会と 週次の自動点検 貯まったものが 次の AI の材料に © DeNA Co., Ltd. 19

20.

| 学び①: この1年が成立した条件 広げられた条件は、範囲を限定した PoC・広げる人・データ基盤チームの協力の3つです。 AI 導入に関して、興味関心が高いメンバーは非常に重要な役割を担います。 この1年が成立した条件 ● 試験導入(PoC)で成功と失敗を積み上げた ● AI 推進チームのメンバーが各チームの窓口に入った ● データ基盤チームと組み、安全に使う仕組みを作った その土台 ● GitHub を業務の基盤に置いた ● トップの関心と、事業戦略の AI 化としての予算 数名 先に試す → 範囲を限定した PoC + 各チームの窓口 → 分析部の全員 約30名 約30名を超える規模での検証はしていません。 © DeNA Co., Ltd. 20

21.

| 学び②: ハーネスは4層で診断できる ハーネスを4層で見ると、自分の組織のどこが薄いかが分かります。 4層は、何を渡すか・何をさせるか・何をさせないか・どう貯めるかです。 私たちの1年では、3つの層が薄いまま使い始めて課題が出ました。 あなたの組織はどの層が薄いですか。 GitHub Copilot 期 Devin 期 Claude Code 期 コンテキスト 何を渡すか 社内文書(Confluence)を API 連携で読ませる 課題① 情報が散らばり AI が迷子に。 コスト増につながる → 対策① 意味の定義と統合リポジトリ。 読ませる情報を階層に整理 手順 何をさせるか 課題② AI の出力が増えて確認が追いつかず、 仕様書を先に書かせた → 対策② 手順書(Playbook)で 手順を全員に配布 スキルに吸収。共通スキルだけ共有 制約 何をさせないか 課題③ 禁止をルール文書に書く。 後にすり抜けられる → 対策③ サービスアカウントで 権限を区切る フックで機械的に遮断。 サンドボックスと権限分離 蓄積 どう貯めるか 変化なし 1人1リポジトリで PR の練習場。 PR に自動レビュー フローの末尾に PR 提出。 自動レビューは継続 赤地は、次の期の進め方を交えるほどの課題が出た層で、矢印はその対策です。1組織・約30名の経験を後から整理した図です。 © DeNA Co., Ltd. 21

22.

| 1年前と現在 分析の型は個人の頭の中からリポジトリへ移りました。 前半でお見せした出発点が、1年でこう変わりました。 1年前(出発点) → 現在 分析の型は個人の頭の中と手書きの文書 → 分析の型はリポジトリの スキルとルールになった AI ツールを配布しても 数ヶ月使われなかった → 新しいタイトルでも同じ型で分析を立ち上げられ、 他のプロジェクトにも仕組みを展開している 新卒が AI に任せた作業で ファイルが万単位に増えた → その新卒が異動先で AI 推進に注力 © DeNA Co., Ltd. 22

23.

DeNA ご清聴ありがとうございました SPEAKER 樋富 啓央 / 浜岡 凌誠 COMPANY 株式会社ディー・エヌ・エー