“AI Native”な開発って結局こういうことじゃない?を考えてみた

これは 株式会社エクスプラザ Advent Calendar 2025 の11日目の記事です。
ここ数ヶ月、「AI Nativeなプロダクト」「AI Nativeな組織」「AI Nativeな企業」という言葉をよく見かけるようになりました。
でも、「AI Nativeな開発"業務"」と言われると、それぞれ違う視点で語る方が多く、まだそこまで明確なイメージを持てていない人も多いのではないでしょうか。
この記事では、私もその定義について考えてみて、いま自分が考えている
「AI Nativeな開発業務って、たぶんこういうものでは?」
という理想像を、あえて妄想込みで言語化してみます。
ステージ0:昔ながらの開発業務
- タスクは人間が洗い出し、人間が1つずつこなす
- 実装も、テストも、レビューも、基本は人間が書いて、人間同士でやる
- ツールは Git / CI / Linter / Formatter … など、どれも人間の作業を「少しだけ効率化してくれる」存在
この世界では、ざっくり言うと
「開発とは、人間がコードを書き、ツールがその補助をする仕事」
でした。
ステージ1:AIを「相談相手」として使う世界 (AI Driven)
昨年あたりから今年の序盤まで、私はこんな感じで開発を進めてました。
LLMを賢い検索ツールとして使う
- 実装に詰まったら ChatGPT / Claude に質問する
- ちょっとしたコードを書いてもらう
- コードの一部と背景を伝えて、アドバイスをもらう
- Issue の説明文やドキュメントを整えてもらう
この世界では、AIは
「いつでも隣にいてくれる、知識豊富な情報提供者」
です。
かなり便利ですが、開発プロセス自体はまだ
- タスクは人間が決めて
- コードも基本は人間が書いて
- AIはアシスタント
という枠を出ていないステージだったなと感じます。
ステージ2:AIを「実装担当エンジニア」として扱い始めたあたり (AI Driven)
そこから一段変わったのが、Cursor などの AI Coding ツールを本格的に使い始めて、
「ちょっとした参考コード」ではなく、機能単位の実装をAIに任せる
ようになってきた段階でした。
この辺りから、AIは
コードを書くことに関しては、かなり頼れる実装担当
くらいの立ち位置になってきます。
ただ、この段階でも、プロセスはまだこんな感じです。
- タスクを見つける・分解する:人間
- タスクをAIに投げる:人間
- AIが書いたコードをレビューして採用するか決める:人間
つまり、
「AIが作業を分担してくれるようになったけど、主導権はまだ人間側にある」
という状態。
ここまでは、ツールの有無・導入度合いの差こそあれ、
似たような感覚を持っている人が多いんじゃないかなと思います。
(今の私) ステージ2.5:AIが“複数の実装案”を同時に持ち込んでくる世界 (まだ、AI Driven)
私は先月あたりから "複数のAIを競争させ、一つを選んで作業を進める" という形でほとんどの実務タスクを進めています。
ステージ2あたりまでは「AIに実装を投げる」という感覚に近かったのですが、
このステージでは
1つのタスクに対して、複数のAIが“別々の完成イメージ”で実装してくる世界
です。
ざっくり書くと、フローはこんな感じです。
- プロジェクトで決まったタスクを、それぞれのエージェントのプロンプトガイドラインに合わせて開発指示を用意
まず、それぞれの開発エージェントのプロンプトガイドラインから、開発指示プロンプトを用意します。
Codex: GPT-5.1 Codex MAX Prompting GUide
Claude Code: Claude Code best practices
- vibe-kanban のような仕組みで、複数エージェントが同時に着手する

vibe-kanbanとは、一つのディレクトリで一つのブランチで一つの作業を進める限界を越えさせるために作られたOSSツールで、それぞれの作業を別のフォルダーのGit Worktreeで同時に作業させることができる便利ツールです。
-
出来上がった それぞれの成果物 を、別の Codex セッションにレビューさせる
- 要件の満たし方
- コードの自然さ / プロジェクトルールとの整合
- 過剰な設計になっていないか(over-engineering)
の3つを中心に、簡易スコアリングしてもらう
実際の競争レビューの様子
実際のレビューを例としてざっくりClaude Codeで再現してみました。
(もっと精度の高いレビューにはもう少し具体的なレビュー基準、採点基準の提供が必要になる)
二つのフォルダーと、作業指示プロンプトを提供。

レビュー結果、一方のWorktreeでの作業物の方が優れているとのレビュー結果に。

-
人間が“最も自然な案”をひとつ選び、軽く整えて PR にする
- 仕上げは、人間がプロダクト感覚で微調整
- 余白の意思決定(UX/用語/例外処理など)は依然として人間が担う
ここまで来ると、
AIはもはや “1人のアシスタント” ではなく、
別々の視点を持つ複数の実装担当が、同時に案を持ち寄ってくる
という感覚に近くなります。
とはいえ、まだ明確な限界がある
便利さは大きくなった反面、このステージにははっきりとした限界もあります。
-
タスクの切り方はまだ人間に依存している
→ どの粒度でタスク化するか、どこからどこまで任せるかはまだ自動化できていない。 -
AIは“指示されたタスク”をこなすだけ
→ プロジェクトの変化(議事録の更新・仕様変更・ユーザーの行動)を起点に、自発的に動き出すわけではない。 -
成果物の良し悪しを判断するのは結局人間
→ スコアリングはAIが手伝えるが、「プロダクトとして自然か?」の判断はまだ人間側の感覚に依存する。 -
複数案が出るとはいえ、質のバラツキは大きい
→ 場合によっては 3 本とも微妙で、人間の方が早い、というケースもまだ普通にある。
まとめると、ステージ2.5(?)は
“AIが実装を大量生産してくれる世界”ではなく、
“AIが複数案を出してくれて、人間が方向性を選ぶ世界”
という位置づけかなと思います。
これからのステージ:AIがプロジェクトの出来事をトリガーに自走する世界 (AI Native)
自分が考える「AI Native」な開発とは
- AIエージェント群は「プロジェクトで起きた出来事」をきっかけに
「タスク分解・実装・テスト・競争レビュー・PR作成・デプロイ」を自律的に回す- 人間は「課題発見・もっといいプロダクト作り」に集中できる
という世界です。
ポイントは、
起点が「人間からAIへのお願いプロンプト」ではない
ことです。
想像している開発の流れ
例えば、Scrumのセレモニーたちの議事録などが自動で記録される仕事環境だとしましょう。
-
Sprint Planningで人間たちが議論する
- 議事録やスプリントゴールが Notion / Google Docs に自動保存される
-
AIが自動で動き始める
- 議事録の更新を監視しているエージェントが検知
- 議事録・スプリントゴール・既存コードを読み込み、タスクを自動分解
- 各タスクに対して、Codex版・Claude Code版など複数の作業が進められる
-
エージェントたちが並列で実装
- vibe-kanban のようなツールで、複数の worktree 上で同時に開発が進む
- 完了したら、レビュー専用エージェントが各作業をスコアリング
- 一番スコアの高いものが PR 化される
-
人間は朝、PRの山を見て判断する
- 「どれをマージするか」「プロダクトの方向性としてどれを採用するか」を決める
- パイプラインの改善点を学び、次に活かす
人間は「AIにお願いを送る」必要がなく、ただ普通にスプリントを始めるだけで、裏側で開発ラインが回り続けるイメージです。
エンジニアの役割はどう変わるか
このステージが実現したら、純粋な「コードを書く時間」はかなり減るのではないでしょうか。
その代わりに増えるのは、
- どうすればもっといい機能を提供できるか?
- どうすればより事業に合う優先順位を決められるか?
- どうすれば、よりよくAIエンジニアたちに仕事をお願いできるのか?
つまり、多くの人たちが予想しているように、こうなったら、
純粋なエンジニアというよりは、プロダクトマネージャーに近い仕事をどんどんしていくことに自然に繋がることになりそうだなと思いました。
おわりに
AI Nativeな開発業務を、あえてステージ0からこれからのステージまで雑なモデルで整理しつつ、
自分が理想としているパイプラインの姿を書いてみました。
今後、実際ここに書いてある”これからのステージ”を実証実験も進めたいと思っていて、その結果もまた共有したいと思います。
この記事が、
- 「AI Nativeな開発って、こういう方向性かもしれない」
- 「自分の現場ではどこまでできそうか」
を考えるきっかけになれば嬉しいです。
「プロダクトの力で、豊かな暮らしをつくる」をミッションに、法人向けに生成AIのPoC、コンサルティング〜開発を支援する事業を展開しております。 エンジニア募集しています。カジュアル面談応募はこちらから: herp.careers/careers/companies/explaza
Discussion