2．AI-Native開発とは何か

AI-Native開発とは、AIを既存プロセスの補助として使うのではなく、AIを中心に開発の前提そのものを設計し直す考え方です。NTT DATAでは、このAIを全面的に活用した新しい開発スタイルを2025年から採用しています。

ここでいう「ネイティブ」は、主体と環境の間に翻訳を必要としない状態のことです。従来は、人間の開発者が情報を解釈し、設計や実装として表現してきましたが、AI-Native開発では、AIが直接情報を読み取り、出力を生成し、その結果を人間が確認するという流れへと転換します（図1）。そのため、開発に必要な要件や設計、手順、判断基準をテキスト形式で整理し、成果物もテキストベースで管理することが不可欠になります。

図1：従来型環境とAI-Native 環境の比較

ホワイトペーパーでは、環境整備に加え、AIを中心に開発を再設計するための見取り図として、全体像をPPT（Process、People、Technology）という3つのフレームワークで整理しました（図2）。要点は、（1）プロセス、（2）人の役割／スキル、（3）技術基盤の三要素を、AIを中心に最適化することです。

図2：AI-Native 時代における PPT フレームワークの入れ子構造

3．商用システム開発における4つの責務

ここからは、AI-Native開発を前提とした商用システム開発において求められる責務について、整理します。

まず整理すべきは「何を満たす必要があるか」という責務です。商用システムは単に動けばよいのではなく、その振る舞いを説明し、責任を果たせる形で提供される必要があります。

従来は人間が設計・実装の主体であることを前提に、これらの責務が暗黙的に担保されてきました。しかし、AIが実装やテストに加え、設計上の判断にも関与するようになると、この前提は成立しません。誰が何を担い、誰が最終的に責任を持つのかを明示的に設計する必要があります。

ホワイトペーパーでは、執行（第一ライン）、監督（第二ライン）、監査（第三ライン）という三層で役割分担を捉えるスリーラインモデルを用いています。開発に適用すると、成果物の生成、品質の担保、最終的な説明責任を切り分けて考えることができます（図3）。

図3：ソフトウェア開発におけるスリーラインモデル

その上で、商用システム開発に求められる責務は、次の4つに整理できます。

• 機能性：必要な機能が実現されていること
• 品質：安定して期待通りに動作すること
• 透明性：生成過程を後から追跡できること
• アカウンタビリティ：根拠に基づき説明・正当化できること

これらは階層的な関係にあり、「機能性」と「品質」の上に「透明性」が成り立ち、さらに「アカウンタビリティ」が確保されます。これまでは、この前提のもとで人が各責務を担うことで全体の整合性が保たれてきました。しかし、AIの導入により、この構造の重要度のバランスは変化します。AIは機能性や品質の実現を加速させますが、だからと言って透明性やアカウンタビリティが確保されるわけではありません。むしろ判断過程のブラックボックス化により、これらは意識的に設計しなければ成立しなくなります。したがって、AI-Native開発では、「どのように作るか」に加え、「どのように説明できる状態を保つか」を設計対象とする必要があります。

問題は、これらの責務を誰が担うかです。AIが担う範囲は拡大していきますが、最終的なアカウンタビリティは依然として人に残ります。

4．責務分担の段階的な変化

この前提のもとで、責務はどのように移っていくのでしょうか。ホワイトペーパーでは、この変化を3つの段階で整理しています（図4）。重要なのは各段階を「どの責務をAIが担うか」という観点で捉えることです。

図4：AI-Native ソフトウェア開発成熟度レベル

第1段階の「AI-Generated」は、AIが実装やテスト生成などを担い、主に機能性の実現を支援する段階です。この段階では、人が従来の役割分担を前提に品質を担保します。

第2段階の「AI-Verified」は、AIが検証や品質判定にも関与する段階です。AIが品質基準に基づいて成果物をチェックするため、人は個々の成果物のレビューにかける比重を下げ、品質基準やプロセス全体の設計・管理にシフトします。

第3段階の「AI-Explainable」は、AIが開発プロセスの全体を透明化し、判断理由や生成過程を提示する段階です。人は整合性や規制要件の観点から事後的に監査し、最終的な説明責任を果たします。成果物の生成から検証、透明性の提供まで、大部分が自動化されることになります。

このように、機能性、品質、透明性といった責務は段階的にAIへと移行していきます。一方で、最終的なアカウンタビリティは人に残り続けます。AIがどれだけ高度化しても、「なぜそのシステムをその形で提供したのか」を説明する責任は、組織として負う必要があるためです。

重要なのは、自組織がどの段階にあるかを見極め、責務分担を段階的に設計し、組織内で共通認識を醸成することです。開発プロセスにおいて「誰も説明できない状態」を生じさせないことは、AI-Native開発における重要な前提となります。

5．責務分担を踏まえた設計のポイント

導入の出発点は、「どの責務をAIに任せ、どの責務を人が担うか」を定義することです。以下の設計ポイントは、それぞれ特定の責務を成立させるためのものです。実務上はこれらを並行して進める必要がありますが、本稿では責務の観点から整理します。

まず、機能性を確実に実現するために、要件と高レベル設計を先に固めることが重要です。AIが下流工程を担うほど、上流の曖昧さはそのまま品質リスクになります。受入条件やモジュール間の責務、変更可能な範囲をあらかじめ明確にすることで、AIエージェントの分担や作業範囲も設計しやすくなります。

次に、品質を担保するためには、品質基準とレビュー観点を明文化することです。人間が暗黙知として持っていた「この実装は危ない」「このテストでは足りない」といった判断を、AIも参照できる形にしなければなりません。コーディング規約、テスト方針、セキュリティー上の禁止事項、承認が必要な条件などを、言語化して共有する必要があります。

その上で、透明性を確保するために、既存資産をAIが読める形に整えることが重要です。特に既存システムの保守や改修では、設計書、運用手順、過去の判断理由が人の頭の中に閉じているケースが少なくありません。こうした暗黙知をテキスト化し、AIが参照できる状態にしていくことが、導入の前提になります。

最後に、アカウンタビリティを支えるために、判断理由と変更履歴を証跡として残すことが重要です。後から説明できる状態をつくるには、どの指示で、どのファイルを、なぜ変更したのかを追える必要があります。

6．おわりに

AIを活用したシステム開発の議論では、生産性向上の話に目が向きがちです。しかし、商用システムで本当に問われるのは、速く作れるかではなく、説明可能な形で運用できるかです。だからこそ今必要なのは、AIを導入することそのものではなく、AIを前提に、開発をどう設計するかを考えることです。

同時に重要なのは、特定のプロセスに固執することではありません。技術の進化に応じて、必要な統制を保ちながらプロセスそのものを適応させていく姿勢が、これからの商用システム開発には求められます。本記事では、公開したホワイトペーパーの考え方を要点に絞って紹介しました。より詳しく確認したい場合は、ホワイトペーパー「アカウンタビリティを軸としたAI-Native開発のデザイン戦略」もあわせて参照してください。