AIネイティブ開発とは——AI支援開発との違いと、発注側が押さえる4つの判断軸 ‣ はてなベース株式会社

「AIネイティブ開発」という言葉が、2025年10月のGartnerの年次トレンド発表と、2026年度から適用を広げるNTTデータの方針の両方に出てきました。開発会社からの提案書にも載り始めています。ところが、Copilotでコードを補完する話と、要件定義からテストまでAIが担う話が、同じ言葉で語られている。この差を知らないまま発注すると、期待と納品物がずれます。

結論を先に書きます。AIネイティブ開発とは、AIが手伝う開発ではなく、AIが作業する前提で開発の工程と体制を組み直したものです。違いは使うツールではなく、要件定義からテストまでのどこにAIが入り、人が何を担うかにあります。

AIネイティブ開発は「AI支援開発」の延長ではない。AIが要件定義からテストまで作業を担い、人は仕様を決め、結果を判定する側に回る。発注側が見るべきは、開発会社が使うツールの名前ではなく、仕様の書き方、自動テストの有無、承認と記録の仕組み、見積りの単位の4つ。
この記事の要約

AI支援開発との違いは、AIがどこまで作業を持つか

2026年時点で「AIを使った開発」は、少なくとも3段階に分かれます。人が書き、AIが補う段階。AIが書き、人が直す段階。AIが工程を通しで進め、人が判定する段階。世の中で「AIネイティブ」と呼ばれているのは3つ目です。

	AI支援開発	AI駆動開発	AIネイティブ開発
AIが入る工程	実装（コード補完）	実装＋テスト	要件定義から設計、実装、テスト、リリースまで
作業の主体	人。AIは提案するだけ	AIが下書き、人が確認して修正	AIが工程を通しで実行。人は仕様と判定を担う
工程は変わるか	変わらない	実装工程だけ短くなる	工程そのものをAI向けに組み直す
代表例	GitHub Copilotの補完	Claude CodeやCodexに機能単位で任せる	NTTデータの「AI-Native開発」、GartnerのAIネイティブ開発プラットフォーム

AI支援開発、AI駆動開発、AIネイティブ開発の3段階を並べ、AIが担う工程と人の役割の違いを示した図 — AIがどこまで作業を持つかで3段階に分かれる。右へ行くほど人の仕事は「作る」から「決める・判定する」へ移る

米国の開発会社HatchWorksは2026年4月の記事で、AI支援開発を「変わらない工程にAIを後付けしたもの」と定義し、AIネイティブ開発を「要件定義からリリース後の保守まで全工程にAIが組み込まれ、人は判断と検証に回るもの」としています。区別の基準は「ツールを入れたか」ではなく「やり方を変えたか」です。

この定義で見ると、Copilotを全員に配っただけの会社はAIネイティブではありません。逆に、使っているツールが1種類でも、要件を受け入れ条件つきで書き、AIが実装とテストを回し、人がレビューだけをする体制なら、AIネイティブ開発に近い。

「AIエージェント」との関係

AIネイティブ開発で作業を担うのは、目標を渡すと複数のファイルを読み書きし、テストを実行して自分で直すタイプのAI（コーディングAIエージェント）です。エージェントそのものの仕組みはAIエージェントとは何かの解説、ツールの種類はAI開発ツール35種の見分け方に整理しています。

言葉の出所は2つ。Gartnerの2026年トレンドと、NTTデータの方針

日本で「AIネイティブ開発」が広まった経路は2つあります。

1つ目はGartnerです。2025年10月に発表した「2026年の戦略的テクノロジートレンド10選」の5番目に「AIネイティブ開発プラットフォーム」を入れました。生成AIで従来より速く簡単にソフトウェアを作る環境を指し、業務部門に入り込んだエンジニアが業務の専門家と一緒にアプリケーションを作る働き方とセットで説明されています。Gartnerは、このプラットフォームによって2030年までに8割の企業が、大規模な開発チームをAIで補強した小規模なチームへ組み替えると予測しています。

2つ目はNTTデータです。2026年5月の自社媒体で「AI-Native開発」を次のように定義しました。

AIを開発の主体に据え、AIが最大限の能力を発揮できるよう、開発環境そのものを最適化するアプローチ
NTTデータ DATA INSIGHT「AI-Native開発で広がるSIerの可能性」（2026年5月28日）

同社は2023年度下期から製造工程にAIを入れ、2025年度から要求分析、設計、製造、テストをAIエージェントでつなぐ段階に移りました。適用プロジェクトは累計500件を超え、2027年度に開発工程全体で最大70％の生産性向上を目標に掲げています（日経ビジネス電子版 SPECIAL）。2026年度は100万行規模のシステムで実践する計画です。

両者に共通するのは、「人が書く工程をAIで速くする」ではなく「AIが作業する前提で工程と体制を作り直す」という発想です。ここが名前の由来で、スマートフォン前提で設計されたサービスを「モバイルネイティブ」と呼ぶのと同じ使い方です。

工程ごとに、人の仕事はどう変わるか

NTTデータが公開している工程別の変化を、発注側から見た形に並べ直します。

工程	従来	AIネイティブ開発	人が担うこと
要件定義	ヒアリングを文書化し、合意してから設計に進む	AIが先に動く画面（モック）を作り、そこから要件を逆算して確定する	モックを見て「これでよいか」を判断する
設計	設計書を人が書き、レビューする	文書を起点にAIが設計案を出し、整合性を機械的に確認する	設計上の判断（何を優先するか）
実装	人が書き、AIが補完する	AIが書く。人はコードをほぼ書かない	差分を読み、受け入れるか戻すか決める
テスト	テスト設計とテスト実行を人が行う	テストコードと文書に導出元を記録し、AIエージェントが参照すべき成果物を自分で判断できるようにする	テストの網羅性と結果の妥当性を判定する
品質管理	レビュー会と検収	AIがどの資料を見て何をしたかの作業履歴を残し、成果物だけでなく過程を確認できるようにする	最終判定と承認

表の右端を見ると、人の仕事が「作る」から「決める」「判定する」に寄っています。Gartnerは2026年7月の発表で、役割と能力がAIによって圧縮される結果、ソフトウェアエンジニアが「プロダクトエンジニア」に近づくと表現しました。開発会社の側では、要件定義からリリースまでの一巡を経験する回数が増えます。NTTデータの担当者は、20年の在籍で5案件ほどだった大規模開発の経験に対し、今回は半年で開発サイクルを10回以上回せたと説明しています。

どこまで本当に進んでいるか、数字で見る

予測・実績	数値	出典
小規模な開発チームを本格採用する組織の割合	2026年の15％から2029年に60％へ	Gartner（2026年7月7日）
AIネイティブ開発プラットフォームで開発チームが小さくなる組織	2030年までに8割の企業	Gartner（2025年10月20日）
小規模チームの典型的な人数	4〜5人。2〜3人で回す組織もある	Gartner（2026年7月7日）
NTTデータのAI適用プロジェクト数	累計500件超	日経ビジネス電子版 SPECIAL（NTT DATA）
NTTデータの生産性目標	2027年度に開発工程全体で最大70％向上	同上

Gartnerの発表で見落とされやすいのは、人数の話です。小規模チームはコスト削減の手段ではなく、人とAIの得意分野に合わせた組み直しだと明記されています。同じ発表で、ソフトウェアエンジニアリング部門の責任者の4分の3が、人員は横ばいか増えると答えています。減るのは1チームあたりの人数で、チームの数とアプリケーションの数は増える、という見立てです。

この4〜5人のチームに必要な役割として、Gartnerはプロダクトマネージャー、UXとエージェント体験の設計者、そして少なくとも1人の「AIネイティブなソフトウェアエンジニア」を挙げています。AIネイティブ開発は、ツールの話であると同時に、どんな人を揃えるかという体制の話です。

発注側が押さえる判断軸は4つ

開発会社から「AIネイティブ開発で進めます」と提案されたとき、確認する項目はツール名ではありません。次の4つを聞くと、その会社がやり方を変えているのか、ツールを足しただけなのかが分かります。

1. 仕様は、AIが読んで実行できる形で書かれるか

AIが工程を担う開発では、仕様の質がそのまま成果物の質になります。HatchWorksがある顧客の課題管理データを分析した例では、受け入れ条件（何ができれば完了とみなすか）を有効に使っていた作業項目は15％未満で、進行中の作業の10〜15％が手戻りや差し戻しになっていました。同社は別途、顧客の課題管理データの分析から「制約は開発の速さではなく、入力の質にある」と結論づけています。

聞くべきことは単純です。要件を「〜ができること」の一覧で書くのか、「〜という条件で〜すると〜になる」まで書くのか。後者でなければ、AIが速く作った分だけ手戻りも速く増えます。

2. 自動で走るテストがあるか

AIエージェントの強みは、テストが失敗したら原因を読んで自分で直す動きを何周も回せることです。裏返すと、自動テストがないプロジェクトでは、この動きが最初から成立しません。既存システムの改修でAIネイティブ開発を提案された場合は、そのシステムに自動テストがどれだけあるかを先に確認します。テストがなければ、テストを整える工程が見積りに入っているかを見ます。

3. 承認と記録の仕組みがあるか

AIがファイルを書き換え、コマンドを実行する以上、どの操作を人が承認し、どの操作を自動で通すかの線引きが要ります。NTTデータの担当部長も、AIネイティブな手法は統制（ガバナンス）とセットで考える必要があると述べています。Gartnerのアナリストも、作るアプリケーションが増えるぶん、セキュリティの制約を開発工程に組み込む必要があると指摘しています。承認の設計はAIエージェントの権限と承認の考え方、統制の観点はコーディングAIのセキュリティと統制に分けて書いています。

発注側が確認するのは3点です。AIが自動で通せる操作と人が承認する操作の線引きが文書化されているか。AIの操作履歴が残るか。顧客データや認証情報をAIに渡さない運用になっているか。

4. 見積りの単位は何か

従来の見積りは人月が基本で、工数は「人が書く量」から積み上げられていました。AIが書く前提では、この積み上げが成り立ちません。実装工程が短くなる一方で、仕様を詰める時間、レビューの時間、AIの利用料が増えます。人月のまま出てきた見積りは、やり方が変わっていない可能性があります。工程ごとに人の時間とAIの利用料を分けて出しているか、成果物単位で価格を出しているかを見ると、開発会社の実態が分かります。

「AIネイティブ」の名前だけで判断しない

上の4つのうち1つも答えられない提案は、従来の開発にAI補完ツールを足しただけの可能性があります。逆に、4つに答えられる会社なら、使っているツールがClaude CodeでもCodexでもCopilotでも、結果は大きく変わりません。ツールの選び方は別記事のGartner Magic Quadrant 2026の読み方で扱っています。

よくある2つの誤解

1つ目は「AIが全部やるので、こちらの手間はなくなる」という期待です。実際は逆で、発注側の仕事は増えます。要件を受け入れ条件まで書き、モックを見て判断し、差分を読んで受け入れるか決める。作る手間がAIに移った分、決める手間が発注側に寄ります。ここを開発会社に丸投げすると、AIが速く作った「頼んでいないもの」を受け取ることになります。

2つ目は「エンジニアが要らなくなる」という見方です。Gartnerの発表では、チームは小さくなるが、部門の責任者の4分の3は人員が横ばいか増えると見ています。小さいチームに必要なのは、仕様を書け、AIの出力を判定でき、統制を設計できる人です。この人材は従来の「コードを書く人」とは別の技能を求められます。社内にシステム担当を置いている会社は、この技能の育成を今から始めることになります。