DeNAの​Claude Code活用事例を​解説 ──仕様から​モックまで​「2週間→1〜2日」に​なった​仕組み

気になるAIの話を、分かりやすく ｜ 最新動向を、現場目線で

2026年7月14日、DeNAが公式エンジニアブログで、Claude Code（AIコーディングエージェント）をチーム全員で使う事例を公開した^[1]。先に結論を言うと、この事例で速くなったのは「AIがコードを書く」部分ではない。議事録→仕様書→デザイン→実装という"チームの受け渡し"が速くなり、仕様確定までのサイクルが従来の2週間〜1ヶ月から1〜2日になった——DeNAはそう説明している。

Claude Code活用事例は世界中にあるが、この記事で取り上げる理由は3つ。①国内大手の実名事例であること、②エンジニアだけでなくPdM（企画職）とデザイナーも使っていること、③速くなった場所が「コーディング」ではなく「チームの合意形成」だったこと。AI導入を検討している会社にとって、参考になる部分がとても多い。

この記事では、①何が公開されたのか ②何がどう速くなったのか ③速さの正体 ④非エンジニアが使うための工夫 ⑤真似する前の注意点——の順に、専門用語なしで見ていく。私たち電脳技巧集団（AI職人ギルド）も開発を全面的にAIエージェントで回している側なので、現場感で軽く一筆添える。

01何が​公開されたのか ──3つの​職種が、​同じ​AIを​使う

公開されたのはDeNAエンジニアブログのインタビュー記事で、登場するのはひとつの開発チームだ。特徴は、Claude Codeを使っているのがエンジニアだけではないこと。職種ごとに任せている仕事が違う^[1]。

職種	Claude Codeに任せていること
PdM（企画）	会議の議事録から仕様変更を拾い出し、仕様書（PRD）を自動更新。Slackでの議論もドキュメントに反映
デザイナー	UIモックアップ（動く試作画面）の作成、デザインデータへの変換、部品の生成
エンジニア	仕様書・技術文書の生成、コード生成、GitHub上の詳細仕様のブラッシュアップ

※ DeNA公式ブログの記載に基づく整理。CAG自身の検証ではない。

ポイントは、3職種が同じ場所（GitHub）にある同じドキュメントを介して働いていることだ。仕様書とコードを同じ場所で管理し、AIがその間の変換を担う。「PdMのメモ」「デザイナーのファイル」「エンジニアのコード」がバラバラの場所にある会社との、いちばん大きな違いがここにある。

02​何が​どう​速くなったのか ──2週間〜1ヶ月が、​1〜2日に

DeNAが挙げる数字はシンプルだ。仕様が確定して動くモックを確認できるまでのサイクルが、従来の2週間〜1ヶ月から1〜2日に短縮された^[1]。

なぜそんなに縮むのか。従来のやり方を思い出すと分かる。会議で決めたことを誰かが文章の仕様書にまとめ、関係者がそれを読んで解釈し、認識合わせの会議をもう一度やり、デザインを起こし、また確認する——各工程のあいだに「書く待ち」「読む待ち」「すり合わせ待ち」が挟まる。しかもテキストの仕様書は人によって読み方がずれるので、手戻りが起きる。

DeNAのチームは、この確認の仕方自体を変えた。文章で仕様をすり合わせる代わりに、AIがすぐ作った「動くモック」を全員で見て判断する。実物が目の前にあれば、解釈のずれは起きようがない。

03速さの​正体 ──AIは​「翻訳係」と​して​効いている

この事例でClaude Codeが担っているのは、実は同じ1つの役割だ。「ある職種の言葉を、次の職種が使える形に翻訳する」こと。議事録（話し言葉）を仕様書に、仕様書をモックに、モックをデザインデータやコードに——形を変えているだけ、とも言える。

従来この翻訳は、各職種の人が手作業でやっていた。だから翻訳のたびに待ち時間が生まれ、翻訳者の解釈がずれれば手戻りになった。DeNAのチームはこの翻訳をAIに任せ、人間は翻訳結果（実物）を見て判断する側に回った。

これは、AIの扱う単位が「質問への回答」から「仕事の成果物」へ移っているという大きな流れの、チーム版と言える。

関連記事 ｜ 同じ流れの「個人・会社」版ChatGPT Workとは何か ──AIが資料まで作って仕事を「完了」させる新機能を解説 →

04非エンジニアが​使う​ための​工夫 ──ここが​一番​真似しどころ

「PdMやデザイナーもAIコーディングツールを使う」と聞くと、全員が黒い画面（ターミナル）と格闘している姿を想像するかもしれない。実際は逆で、DeNAのチームは非エンジニアが安全に使えるように、エンジニアが専用のアプリを用意した^[1]。使う人に合わせて道具の側を整える——この一手間が、職種横断で定着した理由のひとつだ。

もうひとつの工夫が、週1回の職種横断の共有会。「AIにこれを任せたらうまくいった」という発見を職種を越えて交換する場を、仕組みとして持っている。個人の裏技で終わらせず、チームの標準に変える回路だ。

• 道具を整える：非エンジニアには、安全な範囲だけ操作できる専用アプリを提供（ガードレール）。
• 場所を揃える：仕様書とコードをGitHubで一元管理し、AIがその間を行き来する。
• 知見を回す：週1の共有会で、職種を越えて使い方を標準化する。

05真似する​前の​注意 ──DeNA自身が​挙げる​課題

いい話だけではない。記事の中でDeNAのチーム自身が、率直に課題を挙げている^[1]。ここが一番参考になる。

• 暗黙知を書き物にしないと、AIの出力の質が落ちる。「うちのやり方」が頭の中にしかない状態では、AIはそれを守れない。ルールとして明記する手間が先に要る。
• 運用ルールをAI前提で設計し直す必要がある。既存の仕事のやり方にAIを後付けしただけでは、ドキュメントの精度が下がる場面があった——と振り返っている。
• 動くモック＝確定仕様ではない。実物はすり合わせを速くするが、何を「決定」とするか、誰が承認するかの線引きは人間側の設計が要る。

私たちCAGも開発を全面的にAIエージェントで回しているので、1つ目の課題は毎日実感している。効いているのは、チームのルール・判断基準・過去の失敗を「AIが毎回読む書き物」にしておくことだ。人間の新人に口頭で教えることを、AIには文書で渡す。地味だが、ここをやるかどうかで出力の安定感がまるで違う。

06まとめ ──速くしたいのは、​コーディングか、​受け渡しか

DeNAの事例が示しているのは、「AIで開発が速くなる」の中身だ。コードを書く時間より、職種のあいだの待ちと解釈ずれのほうが、ずっと大きなコストだった。そこにAIを当てたから、2週間〜1ヶ月が1〜2日になった。

自社で考えるときの問いはこうなる。うちの仕事で一番時間を食っているのは、作る時間か、それとも受け渡しの待ち時間か。後者なら、この事例の型——場所を揃える・翻訳をAIに任せる・実物で確認する——は、開発以外の仕事にも応用が利く。

観点	従来の受け渡し	DeNAのチームの受け渡し
すり合わせの材料	文章の仕様書（解釈がずれる）	動くモック（実物を見て判断）
職種間の翻訳	各職種の人が手作業で変換	AIが変換し、人は判断に回る
情報の置き場	職種ごとにバラバラ	GitHubに仕様とコードを一元管理
非エンジニアの環境	同じ道具を我慢して使う	安全な専用アプリを用意（ガードレール）
知見の広げ方	個人の裏技で終わる	週1の職種横断共有会で標準化
仕様確定まで	2週間〜1ヶ月	1〜2日

※ DeNA公式ブログの記載に基づく整理。数字はDeNA自己申告であり、CAG自身の検証ではない。