最近『AIネイティブ開発』って言葉をよく聞くんですけど、今までのAI活用と何が違うんですか？

今まではAIが人間を『支援する』段階。AIネイティブは、AIが開発プロセスの『中心』になる段階。設計→実装→テスト→デプロイの全工程でAIがデフォルトで動く世界だよ。

コードを書く前にAIと会話する時代

ミドリ： タツヤさん、最近「AIネイティブ開発」って言葉をよく見かけるんですけど、GitHub Copilot使ってればAIネイティブですか？

タツヤ： 全然違う。Copilotを使うのは「AI支援開発」。AIネイティブはもう一段上のレイヤーの話だよ。

ミドリ(thinking)： どう違うんですか？

タツヤ： たとえで言うと、スマートフォンの登場前後で考えてみて。ガラケーにブラウザを載せたのが「モバイル対応」。最初からタッチ操作を前提にアプリを設計したのが「モバイルネイティブ」。同じ構図がAIでも起きてるんだ。

AI支援 vs AIネイティブ：何が変わったのか

ミドリ(thinking)： もう少し具体的に比較してもらえますか？

タツヤ： 開発プロセスの各段階で比べてみよう。

工程	AI支援開発（2023〜2024年）	AIネイティブ開発（2025年〜）
設計	人間が設計、AIにレビューを依頼	AIに設計案を生成させ、人間が選択・修正
実装	AIがコード補完	AIがコードブロックを生成、人間がレビュー
テスト	AIがテストコード補完	AIがテスト戦略を設計し、テスト生成・実行
デバッグ	AIにエラーを貼り付けて質問	AIがログを監視し、異常を検知・修正提案
ドキュメント	AIにドキュメント生成を依頼	コード変更から自動でドキュメント更新
コードレビュー	AIがレビューコメントを補助	AIが全PRを事前レビュー、人間は最終判断

ミドリ： AI支援は「人間が主体でAIを呼ぶ」、AIネイティブは「AIがデフォルトで動いていて人間が判断する」ってことですか。

タツヤ： 完璧な理解。AIネイティブの本質は「AIが動いていることが前提の開発プロセス設計」なんだ。

CLAUDE.mdとAGENTS.md ── AIが読む設計書

ミドリ(thinking)： 具体的にどうやってAIネイティブを実践するんですか？

タツヤ(nodding)： まず一番インパクトが大きいのが、リポジトリにAIへの指示書を置くという習慣。

ミドリ： READMEのAI版みたいな？

タツヤ： そう。代表的なのが CLAUDE.md と AGENTS.md。

CLAUDE.md

タツヤ： Claude CodeなどのAIエージェントがリポジトリを理解するための指示書。プロジェクト固有のルールやコンテキストを書く。

# プロジェクト概要
React + Supabaseの社内ツール。TypeScript必須。

# コーディング規約
- コンポーネントは関数コンポーネント + hooks
- 状態管理はZustand
- APIレスポンスの型は shared/types/ に定義
- テストは Vitest + Testing Library

# やってはいけないこと
- any型の使用禁止
- console.logをコミットしない
- 環境変数をハードコードしない

ミドリ： これがあると、AIが「このプロジェクトではZustand使ってるんだな」って理解して、コードを生成してくれるわけですね。

タツヤ(smiling)： そう。CLAUDE.mdがないと、AIは一般的なベストプラクティスで書くから、プロジェクトの規約に合わないコードが生成される。結局人間が修正する手間が発生するんだ。

AGENTS.md

タツヤ： GitHub Copilot Workspaceなどのマルチエージェント環境向け。各エージェントの責任範囲とルールを定義する。

# code-review-agent
- PR全件を自動レビュー
- セキュリティ脆弱性の検出を最優先
- パフォーマンス問題は Warning、スタイル問題は Info で報告

# test-agent
- PRのdiffからテスト対象を特定
- カバレッジ80%未満のファイルを優先
- スナップショットテストは生成しない

ミドリ： エージェントごとに役割と制約を明文化するんですね。

タツヤ： 人間のチームにオンボーディング資料があるように、AIエージェントにも「入社マニュアル」が必要になった。これがAIネイティブ時代の開発文化だよ。

Vibe Coding ── 「雰囲気」で伝えてAIが作る

ミドリ： 最近「Vibe Coding」ってのも聞くんですけど、あれは何ですか？

タツヤ： Andrej Karpathy（元Tesla AI責任者）が2025年に提唱した概念で、コードの詳細を人間が書かずに、自然言語で「こんな感じにして」と伝えてAIがコードを生成する開発スタイルのこと。

ミドリ： それって「プロンプトエンジニアリング」と何が違うんですか？

タツヤ： プロンプトエンジニアリングは精密な指示を出す技術。Vibe Codingはもっとラフ。「ダッシュボードにグラフ追加して。売上の月次推移が見えるやつ」みたいな指示でAIが実装する。

ミドリ： いい加減すぎません？

タツヤ： そこがポイントで、Vibe Codingが成立するには条件がある。

条件	理由
CLAUDE.md等の文脈情報がある	AIがプロジェクトの前提を理解できる
テストが充実している	生成コードの品質を自動検証できる
CI/CDが整備されている	デプロイ前に問題を検出できる
型システムが厳格（TypeScript等）	コンパイル時にバグを排除

タツヤ： つまりVibe Codingは「雑に指示してOK」ではなく、それを支えるインフラが整って初めて成立する高度な開発手法なんだ。

ミドリ(confused)： 基盤が強いから雑に見える指示でも精度が出るんですね。

AI-First アーキテクチャの原則

ミドリ： AIネイティブでアプリを設計するとき、アーキテクチャはどう変わりますか？

タツヤ： 5つの設計原則がある。

原則1：小さな関数、明確なインターフェース

タツヤ： AIがコードを生成・修正しやすいように、関数は小さく、入出力の型を厳密に定義する。1関数50行以内、引数はオブジェクト型で名前付きにする。

ミドリ： これは人間にとっても読みやすいですよね。

タツヤ： そう。AIネイティブの設計原則は、実はクリーンコードの原則とほぼ一致する。AIに最適化すると自然と人間にも優しいコードになるんだ。

原則2：ドキュメントはコードと一体化

タツヤ： JSDocやTSDocでインラインドキュメントを充実させる。AIはこれを読んでコンテキストを理解する。別ファイルのドキュメントは参照されない可能性がある。

原則3：テストを「仕様書」として書く

タツヤ： テストのdescribeブロックを自然言語で丁寧に書く。AIはテストを読んで「この関数が何をすべきか」を理解して実装を生成する。

describe('calculateShippingFee', () => {
  it('注文金額が5,000円以上なら送料無料', () => { ... });
  it('離島の場合は一律500円加算', () => { ... });
  it('クール便は300円追加', () => { ... });
});

ミドリ： テストが仕様書になるから、AIに「このテストが通る実装を書いて」って言えるわけか。

タツヤ： TDD（テスト駆動開発）が、AIネイティブ時代に最も合理的な開発手法になった理由がこれだよ。

原則4：設定より規約（Convention over Configuration）

タツヤ： ディレクトリ構造やファイル命名の規約を統一する。AIはパターン認識が得意だから、規約が一貫していればプロジェクト全体の構造を瞬時に把握できる。

原則5：環境の再現性を保証する

タツヤ： DevContainerやNix、Docker Composeで開発環境を完全に定義する。AIがコードを生成して即座にテストできる環境が必要だから、「自分のマシンでは動く」は通用しない。

チームワークフローの変革

ミドリ： AIネイティブになると、チームの働き方はどう変わりますか？

タツヤ： 2025年と2026年で比較してみよう。

PR（プルリクエスト）のフロー

ステップ	従来	AIネイティブ
1. コード作成	人間が書く	AIが生成、人間がレビュー
2. テスト	人間が書く or 書かない	AIが生成、CIで自動実行
3. レビュー依頼	人間がレビュアーを指名	AI が事前レビュー完了済みで人間に回す
4. レビュー	人間が全行読む	AIのサマリーを確認、リスク箇所のみ精読
5. マージ	人間が判断	AIがリスクスコアを提示、人間が最終判断

ミドリ： 人間の作業が「生成」から「判断」にシフトしてますね。

タツヤ： これが核心。AIネイティブ開発者の価値は「コードを書く速さ」じゃなく、「AIの出力を正しく評価し、方向性を決定する能力」に移る。

開発速度の実データ

タツヤ： Stack Overflow Developer Survey 2026と各社の公開データを統合すると、こんな数字が見えてる。

指標	AI未活用	AI支援	AIネイティブ
PRマージまでの平均時間	48時間	24時間	6時間
1人あたり週間コミット数	12	22	45
バグ発見率（リリース前）	62%	78%	91%
オンボーディング期間	4週間	2.5週間	1週間
ドキュメント更新頻度	月1回	週1回	コード変更と同時

ミドリ： PRマージが48時間→6時間って、8倍速ですか？

タツヤ： AIの事前レビューが効いてる。人間レビュアーに回る時点で「スタイル問題なし、型安全性OK、テストパス」の状態だから、レビュアーはビジネスロジックだけ確認すればいい。

メトリクス：AIネイティブの効果測定

ミドリ： 経営層に「AIネイティブ開発を導入したい」って提案するとき、どんな数字を見せればいいですか？

タツヤ： DORA metricsに加えて、AIネイティブ固有の指標を追加するのがおすすめだよ。

指標	測定方法	目標値
AI生成コード採用率	AIが生成したコードのうち、レビューを通過した割合	70%以上
CLAUDE.md網羅率	プロジェクトの規約がCLAUDE.mdに反映されている割合	90%以上
テストカバレッジ	AIが生成したテストを含む全体カバレッジ	80%以上
PR事前レビュー自動化率	AIが自動レビューしたPRの割合	100%
デプロイ頻度	DORAの標準指標	1日複数回
変更リードタイム	コミットからデプロイまで	1時間以内

ミドリ(thinking)： AI生成コード採用率70%って、つまりコードの7割はAIが書いてるってことですか。

タツヤ： そう。残り30%は設計判断が必要な箇所や、AIがまだ苦手な領域。でもこの比率は年々上がっていく。大事なのは「AIに書かせる」ことじゃなく、「AIが書いたコードの品質を担保する仕組み」を作ることだよ。

導入ロードマップ

ミドリ： 今日から始めるとしたら、何からやればいいですか？

タツヤ： 4フェーズで進めよう。

フェーズ1：基盤整備（1〜2週間）

リポジトリに CLAUDE.md を作成
CIパイプラインにAIレビュー（例：Claude Code、GitHub Copilot）を組み込み
テストカバレッジの現状を計測

フェーズ2：ワークフロー統合（2〜4週間）

全PRにAI事前レビューを適用
AIによるテスト生成を導入
ドキュメント自動更新の仕組みを構築

フェーズ3：文化変革（1〜2ヶ月）

チーム全体でVibe Codingの実践トレーニング
「AIの出力をレビューする」スキルの共有
ペアプログラミングの相手がAIになるケースの運用ルール策定

フェーズ4：計測と最適化（継続的）

AIネイティブ指標の月次レビュー
CLAUDE.mdの更新頻度と品質の追跡
ROIの定量評価と経営報告

ミドリ： フェーズ3の「文化変革」が一番難しそうですね。

タツヤ(nodding)： その通り。ツールの導入は簡単だけど、「コードを書くこと」から「AIの出力を判断すること」に価値の軸をシフトするのは、エンジニアのアイデンティティに関わる話だからね。丁寧に時間をかけるべきところだよ。

まとめ：「AIを使う」から「AIと共に作る」へ

ミドリ： 今日の話をまとめるとどうなりますか？

タツヤ： 3つのポイント。

AIネイティブ開発 = AIが開発プロセスの中心にいることが前提の設計。 CopilotやChatGPTを「たまに使う」のとは根本的に違う。CLAUDE.mdやAGENTS.mdでAIに文脈を与え、テストとCIで品質を担保する仕組みが必要
Vibe Codingは基盤があって成立する。 型安全性、テストカバレッジ、CI/CDが揃って初めて「ラフな指示でも精度が出る」世界になる。基盤なきVibe Codingは単なる手抜きだ
エンジニアの価値は「コードを書く速さ」から「判断の質」へ移行。 AIが生成したコードの良し悪しを見極め、アーキテクチャの方向性を決定する能力が、2026年の開発者に最も求められるスキル

ミドリ： 怖い反面、ワクワクしますね。AIと一緒に開発するのが当たり前の時代。

タツヤ： 怖がる必要はない。自動車が登場しても馬を愛する人はいなくならなかった。ただ、馬車で通勤する人はいなくなった。AIネイティブは選択肢じゃなく、これからの開発の前提条件になるよ。

次のアクション

AIネイティブ開発を今日から始めましょう。

自分のリポジトリに CLAUDE.md を1つ作成してみる（30分でできる）
既存のPRレビューフローにAIレビューを1つ追加してみる
チーム全体のAIネイティブ開発導入支援は、Shimanto AI Solutionsの開発プロセスコンサルティングへ