生成AIなどの技術革新が急速に進む現代。「ITエンジニアの仕事が奪われるのでは」と不安の声が聞かれる一方で、この技術を前提とした新しい働き方や事業の作り方が生まれようとしています。
2025年7月、スタートアップの最大級カンファレンスであるIVSの開催中に、paiza取締役会長の片山が「企画はプロトタイプ必須になった」というDeNAの方針について投稿しました。このポストは、110万インプレッションを超える大きな反響を得ています。
生成AIの急速な普及に伴い「企画はプロトタイプ必須」というルールは、エンジニアだけでなく、プロダクトマネージャー（PdM）や企画職のあり方にも変革を迫る象徴的な出来事として受け止められました。
この大胆なルールの背景にあるのが、2025年2月、株式会社ディー・エヌ・エー（DeNA）が打ち出した「AIオールイン」という大胆な方針。ベイエリアのスタートアップが数名のチームで生成AIを駆使し、圧倒的なスピードで開発を進める姿を目の当たりにしたことが、その決断のきっかけとなったと言います。
今回の記事では、「AIオールイン」のリアルな内実と、それによってエンジニアやPdM（プロダクトマネージャー）の役割がどう変わろうとしているのかをテーマに対談した内容の前編をお届けします。
参加者は、DeNAでAIイノベーション事業本部 本部長を務め、全社のAI戦略を牽引する住吉政一郎さんと、paiza取締役会長の片山良平です。AIネイティブなものづくりを進める最前線で、今、何が起きているのでしょうか——
住吉 政一郎さん プロフィール（写真右）
株式会社ディー・エヌ・エー AIイノベーション事業本部 本部長。2012年に新卒でDeNAに入社し、ゲームのサーバーサイドエンジニアとしてキャリアをスタート。ゲーム事業、新規事業、コミュニティ系の業務を経験後、ライブコミュニケーションアプリ「Pococha（ポコチャ）」の事業リーダーを約7年間務める。2025年4月より現職に就き、AIにフルコミット。新会社（DeNA AI Link）の立ち上げや、AIに特化した部隊、社内のプロダクト開発チームを統括している。
片山 良平 プロフィール（写真左）
インターネット黎明期より100を超える企業のWebデザイン、システム開発などに携わる。 その後、ITエンジニアとしてPHPとMySQLを使用したCMS、ASP型ECモールなどの自社開発を担当。 2007年より、ネットイヤーグループ株式会社にて大手通信企業のデジタルマーケティング戦略を統括。 2011年、新規事業開発の専門会社である株式会社エムアウトに入社。 2012年にエムアウトの社内新規事業としてギノ株式会社（現：paiza株式会社）を創業、代表取締役社長に就任。2025年11月、取締役会長に就任。
目次
Pococha事業リーダーからAIイノベーション本部長へ
paiza 片山： 住吉さん、本日はよろしくお願いします。
実は、先にIVSで住吉さんのお話を伺いまして、「DeNAさんではプロダクト企画は企画書ではもう通らず、プロトを作ってこないとダメになった」という内容に大変衝撃を受けました。
あの話を聞いてから、ぜひ一度DeNAの住吉さんとじっくりお話をしてみたいとずっと思っていました。今回こうして対談が実現し、とても嬉しく思っています。今日は、あのIVSでの発言の真意も含めて、詳しくお伺いできればと思います。
DeNA 住吉：ありがとうございます。 よろしくお願いします。
paiza 片山： では早速ですが、まず、住吉さんのご経歴と現在の役割について教えていただけますか。
DeNA 住吉： 私は2012年にDeNAに新卒入社し、もともとゲームのサーバーサイドエンジニアからキャリアをスタートしました。ゲーム事業や新規事業などを経験した後、2018年の頭からライブコミュニケーションアプリ「Pococha（ポコチャ）」の事業リーダーを7年ちょっと務めました。2025年4月からはAIだけにフルコミットする形になりました。
paiza 片山： 7年間のPocochaからAIへというのは大きな転身ですね。
DeNA 住吉： はい。4月からは新会社（DeNA AI Link）の立ち上げやAIに特化した部隊、そして社内でAIネイティブなプロダクト開発をするチームを見ています。
現在、AIイノベーション事業本部内の「プロダクト開発統括部」では、2月以降、「AIの新規事業をとにかくたくさん作る」というミッションのもと、社内で企画を募集し、開発を進めています。今、開発が走っているもので10本ほど、企画段階のものを含めると20本ほどの新しいAIネイティブな事業ラインが立ち上がっています。
paiza 片山： 20本とは、 すごい数ですね。チーム体制はどのような規模と構成でしょうか。
DeNA 住吉： それぞれにPO（プロダクトオーナー）がいて、開発フェーズに進むとエンジニアとデザイナーがアサインされます。例えばモバイルアプリだと、ネイティブとサーバーサイド、ものによってはAIエンジニアが入ります。チーム全体の規模感としては40〜50人ほどの体制です。
「AIエンジニア」と「ソフトウェアエンジニア」の棲み分け
paiza 片山： 「AIエンジニア」という言葉も最近は幅が広いですが、DeNAさんではどう定義されていますか？
DeNA 住吉： 我々の定義では、「AIエンジニア」は、AIのモデル自体を作ったり、いじったりできる人たちを指しています。一方で、AIを活用した開発をする人たちを「ソフトウェアエンジニア」と呼んでいます。
paiza 片山： 「モデルを作ったりいじったり」というのは、どのレベルまでを想定されていますか？
DeNA 住吉： もちろん追加学習（ファインチューニング）もできますし、中には本当にAI分野で論文を出しているようなレベルの人たちも含まれていますね。LLM自体を0から事前学習含めて開発していたタイミングもありましたし、それができるメンバーもいます。
基本的にはプロジェクトベースで、「どういうモデルを作るか、あるいは作らないか」「外部モデルをチューニングするか」といったことを、ソフトウェアエンジニアがAIエンジニアに相談しながら作っていく体制です。
なぜDeNAは「AIオールイン」へ？ ベイエリアの衝撃と現場のリアルな反応
paiza 片山： 「AIにオールインする」という方針は非常にインパクトがありました。この方針に至った背景と、なぜこのタイミングだったのかを改めてお伺いできますか。
DeNA 住吉： 2024年の12月に、ベイエリアの関係者と話す機会があったんです。その時、彼らが当時出てきたばかりの生成AIモデルを開発プロセスに組み込んだチームを作っているという話を聞きました。
当時聞いたのは、彼らはまだスタートアップサイズでしかなく、本当に10人ほど、もしくはそれ以下の規模感でした。彼らは生成AIを使ったワークフローや開発プロセスを自分たちで構築し、本当に数人で超高速に開発を回している、と。
paiza 片山： まさにAIネイティブな開発スタイルですね。
DeNA 住吉： その話を聞いて、「これは最終的に全体へ普及していきそうだな」という強い感覚がありました。そこから2月（2025年）の発表までに、オールインのコンセプトや具体的な進め方を議論し、あのタイミングでの発表に至った感じです。
paiza 片山： その発表を受けて、社内の皆さんの反応はどのようなものでしたか？
DeNA 住吉：最初は本当にそれぞれでした。既存の事業をしっかり運営しているメンバーからすると、必ずしも最新のAIを日々キャッチアップしているわけでもないので、「へえ、そうなんだ」「どうやってやるんだろう？」という受け止め方でした。
一方、AIチームからすると「今さら何？」という感じだったかなと思います（笑）。彼らからすれば「10年以上前からAIをやっています」と。しかもLLMについても「もともとずっとウォッチしていましたよ」という話もある。こうしたギャップはあったと思います。
また、この「AIオールイン」の方針には、「（社内の）リソースの半分を新しいAI事業に振り向ける」という具体的な計画も含まれていました。そのため、「どういうことですか？」みたいな問い合わせが現場から来たこともありました。しかし、背景や事情を説明すると「あ、そうなんですね」と納得してもらえた様子で、想像していたより大きなショックはなかった気がします。
「企画書だけは失敗する」 DeNAが“プロトタイプ必須”ルールの理由
paiza 片山： それでは本題の、「プロトタイプ必須」ルールについてお伺いします。 IVSでのお話（がきっかけとなったXのポスト）は大変な反響でしたが、私は特に PdMや企画職へのインパクトが非常に大きかったと感じています。
これまで、エンジニアは「AIがコードを書くようになる」という議論が当事者としてありましたが、PdMや企画職は「自分の仕事はAIに侵食されない」と、どこか対岸の火事だったと思うんです。
それが、DeNAさんのルールによって「AIに仕事を奪われる」のではなく、「AIを活用してプロトを自ら作る」ことが企画職の必須スキルになった。これで一気に「自分ゴト」になった。この危機感への転換が、あの大きな反響に繋がったのだと私は見ています。
DeNA 住吉： なるほど、社外の皆さんからは、そのように受け止められていたんですね。
paiza 片山： 改めて、その「プロトタイプ必須」ルールが生まれた背景を教えていただけますか。
DeNA 住吉： 今、プロダクト開発統括部で作っているのは、まさにAIネイティブな事業、つまりLLMの精度が上がってきて以降のプロダクト企画なんです。
必然的にLLMを使った企画が多くなるわけですが、LLMを使った企画は、当初企画書で書くのも結構難しいんですよ。「LLMを使ってこういうことをやります」「AIエージェントです」みたいな説明が企画書に書いてありました。
「良さそうだから、1回作ってみよう」となって、実際にエンジニアが作り始めると、「ちょっとうまくいかないです」という話が出てくるんです。
paiza 片山： いわゆる「作ってみたけど、なんか違った」という状態ですね。
DeNA 住吉： そうです。それを何回か見て、「あ、これダメだな」と。
特にLLMを組み込んだプロダクト企画は、「何となくここはAIエージェントで」みたいな、ぼんやりした解像度だとプロダクトとして全く成立しないんです。
というのも、LLMプロダクトのUX（ユーザー体験）は、結局LLMが返してくるテキストだったり、そのやり取り自体が体験の中心になります。そのため、企画側がその体験設計、つまりプロンプティングを自分自身でしっかりできる必要がありますし、事前にその「感触」を掴んでおく必要があったんです。
それらのケイパビリティがないとLLMを組み込んだプロダクトは上手くいかないので、その意味でも、最初から企画者自身がプロンプトも含めて自分で色々試したり、調べてみたりして、実際にある程度まで自分で作ってもらうことにしました。
「ここから先、こういうチューニングすれば多分いけますよ」というレベルまでは、やってみると、そんなに時間かからなくても到達できるな、というのが見えてきたんです。
paiza 片山： 企画の段階で、実現可能性や「触り心地」の解像度を上げてもらう、ということですね。
DeNA 住吉： その通りです。企画の段階からそれができるようにした結果、手戻りがだいぶ減りました。ある程度、企画者と開発者双方でイメージが湧いている状態からスタートできるようになったのは、本当にやってよかったなと思っています。
あえて「繋がない」。企画プロトと本番実装を”ガラガラポン”する意味
paiza 片山： 当初は「企画書レビュー」→「プロト作成」だったサイクルが、「プロト作成」→「レビュー」に変わったわけですね。
DeNA 住吉： そうなんです。「このサイクル、もう（企画者）1人で回せるでしょ？」という雰囲気になってきたので、「欲しい要求水準は伝えるから、そこまで作って持ってきてください」というリクエストに変化してきました。もちろん、マネージャーと壁打ちしながらですが、その方が早いし、精度も高くなってきたんです。
paiza 片山： 企画者が作ってきたプロトタイプと、本番のエンジニアリングの「繋ぎ」はどうされているんですか？
DeNA 住吉： そこは、繋ぎません。
paiza 片山： おお、繋がないんですね。
DeNA 住吉： 企画者が作ったプロトタイプは、あくまで「コンセプトとイメージを作る」ためのものです。そこから先、エンジニアがアサインされて以降は1回「ガラガラポン」します。
paiza 片山： なるほど。でもそっちの方が良いですよね。
DeNA 住吉： エンジニアと企画者が相談しながら、「どういう風に作るか」をゼロから決めていきます。企画者が作ったものが、そのまま本番まで持っていけるケースもゼロではありませんが、基本的にはコンセプトとして使います。
やはり、DeNAのアカウントでパブリッシュする場合のセキュリティ水準やルールからすると、プロトタイプのままでは「ちょっと大変だな」となることが多いです。
トップエンジニア伴走 「合宿」で既存事業とAI融合
paiza 片山： 「プロトタイプ必須」は新規事業チームの話かと思いますが、既存の事業本部の人たちがAIをキャッチアップするための取り組みもされていると伺いました。
DeNA 住吉： そうなんです。新規事業とは別で、既存事業のメンバー向けに「合宿」を行いました。
paiza 片山： 合宿ですか。それはどういったきっかけで実施されたんですか？
DeNA 住吉： もともとの課題感として、既存事業のPM（プロダクトマネージャー）側が「『AIをどのように使うのか』を調べても、なかなかわからない」というものがありました。
そこで、AIエンジニアのトップクラスのメンバーを各チームに入れたんです。
まず、生成AIの仕組み、つまりTransformerがどう動いているかといった根本的な部分も含めてレクチャーした上で、例えばPocochaチームのPdM 2人とAIエンジニア 2人というペアをたくさん作りました。
2泊3日で「目の前にいるAIエンジニアに何でも聞いていいよ」「何でも答えます」「実際に作りながら答えます」というのを実施したんです。
paiza 片山： それは贅沢な環境ですね！ AIの仕組みの根本から学んだ上で、トップエンジニアと壁打ちしながら実装まで試せるということですよね。ただ、新規事業チームと違い、既存事業のPdMたちにいきなり「AIで作れ」というのは、ハードルが高くなかったですか？
DeNA 住吉： はい、最初は多分みんな「え？」という感じでした（笑）。実際、プロダクト開発用にLLMを使ったことがない人たちも結構いたので。でも、触ってみるとインターフェース自体は難しくないですし、「意外といけますね」という状態になっていきました。
paiza 片山： 実際に触れる環境が大事だったんですね。合宿では具体的なアウトプットも出たんですか？
DeNA 住吉： 出ました。PocochaのトップPMは、もともと自分でプロトタイプを触ったりしていたんですが、その合宿で、AIエンジニアと一緒に「ポコチャ版のニコニコ大百科」みたいなものを開発しました。サンプルデータを見て、「Wikipediaがこんなふうに（AIによって）更新されていきます」というデモを2泊3日で行っていましたね。
paiza 片山： なるほど。具体的なアウトプットが出ると、一気に実感が湧きますね。
DeNA 住吉： 合宿から帰ってきた彼は「これはもっと使えますね」という手応えを持って帰りました。そこから社内でAIを使ったプロダクトアップデートの議論がかなり進むようになりました。合宿を行ったのが（2025年）3月なんですが、そこから一気に活用が進んだ感覚があります。
paiza 片山： やはり、具体的な事例が身近に出ると違いますね。
DeNA 住吉： 本当にそう思います。社内で具体的に使える事例が出始めると、加速度的に興味が集まっていくんです。具体的な事例がないと、「いつかは使うんだろうな」という対岸の火事のような気持ちになってしまう。でも、実際にアウトプットを1回しっかり見ると、「こういう風に使えるんだ」と一気にリアリティが増します。
paiza 片山： それでいうと、社内でのリアリティが増して活用が進んだ分野は何かありますか？
DeNA 住吉： リサーチとかはまさにそうですね。あとはプロトタイプを作る時の、プロト向けのアセットの準備とかもそうです。「準備がめちゃくちゃ早くなる」という事例ですね。
paiza 片山： なるほど。「このすごい機能が作れます」というより、「普段のあなたの仕事が早くなるよ」と見せつけるということですか。
DeNA 住吉：その通りです。 今まで1日かかっていた作業が10分位でできる、といったことがあると、みんな「使わない理由はない」というマインドになりますから。
「AIオールイン」の方針のもと、新規事業では「プロトタイプ必須」、既存事業では「合宿」を通じて、AI活用の解像度を高めてきたDeNA。 後編では「新卒がAIでコードを量産し、シニアがレビューで疲弊する」という現代的な課題への処方箋、さらに「AIを使いこなす社員」の新たな評価基準について、深く掘り下げます。＜後編URL＞
