Stack Overflow Developer Survey 2025 では、開発者の 84% が AI ツールを利用または利用予定と回答し、プロ開発者の 51% が日常的に AI を使用しています。一方で、Google Cloud の DORA Report 2025 は「AI は組織の強み・弱みを増幅するものであり、成果はツールそのものではなく組織・開発プロセス・基盤整備に左右される」と明確に指摘しています。「AI コーディングで開発会社は不要になる」という議論は、DORA の本意を読み違えています。本稿では、AI 時代に開発会社の価値が移る 4 領域、AI を入れたが効果が出ない組織の典型 3 パターン、そして 2026 年の開発会社選定の新基準を整理します。
なぜ「AI コーディングで開発会社不要論」は誤読なのか
「84% が AI を使う」という Stack Overflow の数字を見て、開発会社の役割が縮小するように見えるのは自然な反応です。しかし、この数字は「コードを書く時間」だけが見えていて、ソフトウェア開発の本当の工程を見ていません。
DORA Report 2025 の本質的なメッセージを整理すると、次のようになります。
| よくある誤読 | DORA 2025 の本意 |
|---|---|
| AI でコーディングが速くなれば、開発会社はいらない | AI はあくまでツール。組織・プロセス・基盤の品質に応じて成果が「増幅」される |
| AI を入れれば DevOps の高パフォーマー組織になれる | AI は強い組織をさらに強く、弱い組織をさらに弱くする |
| ツール選定が一番重要な意思決定 | ツールよりも、要件定義・設計・レビュー・品質保証・運用の体制設計が重要 |
そして、要件定義の品質、設計の妥当性、レビュー文化、テスト・品質保証の自動化基盤、運用・SRE の成熟度――これらは AI ツールが解決してくれる領域ではありません。むしろ、AI コーディングで生成されるコードが急増する時代こそ、人がレビュー・品質保証・運用の品質を上げる体制 が事業成果を分けます。
まとめ：AI コーディングは「コードを書く時間」を短縮します。しかし、要件定義・設計・レビュー・品質・運用という「成果を出す時間」は、組織の体制が決めます。開発会社の価値はここに移行します。
開発会社の価値が移る 4 領域
中堅企業（売上 100〜1,000 億、従業員 200〜3,000 名）が 2026 年に開発会社へ依頼すべき領域を、4 つに整理します。
領域 1：要件定義・設計
AI コーディングは「何を作るか」が決まっていることを前提にします。逆に言えば、「何を作るべきか」「どこまで作るべきか」「どう設計すべきか」を決められない状態では、AI を使っても無駄なコードが量産されるだけです。
| 旧来の依頼スコープ | 2026 年の依頼スコープ |
|---|---|
| 「画面仕様書を渡すので作ってほしい」 | 「業務課題を渡すので、解決方法と実装範囲を一緒に決めてほしい」 |
| 「画面遷移図を作ってほしい」 | 「ユーザー体験と業務フローを設計し、何を画面化し何を自動化するか決めてほしい」 |
| 「ER 図を作ってほしい」 | 「データモデルを将来拡張に耐える形で設計し、変更しやすい境界を決めてほしい」 |
領域 2：コードレビューと自動化基盤
AI コーディングで生成されるコードは、構文的には正しくても、(a) 既存コードベースとの整合性、(b) セキュリティ脆弱性、(c) パフォーマンス、(d) 可読性で問題を起こすことが頻繁にあります。
| レビュー対象 | AI 出力で頻発する問題 | 自動化のレベル |
|---|---|---|
| セキュリティ | SQL インジェクション、認証バイパス、機密ハードコード | SAST / SCA を CI に組み込み、AI で一次レビュー |
| パフォーマンス | N+1 クエリ、無駄なループ、巨大データの一括処理 | プロファイリング、負荷テスト自動化 |
| 既存整合性 | 同じ機能の重複実装、命名規則違反 | コードベースに対する RAG レビュー、規約 lint |
| 可読性・保守性 | 関数の肥大化、コメント不足、テスト不足 | 静的解析、コードカバレッジ、ペアレビュー |
領域 3：テスト・品質保証
AI コーディングが普及するほど、(a) 1 機能あたりのテストカバレッジ、(b) 回帰テストの自動化、(c) E2E テストの安定性、が事業価値に直結します。
| テスト種別 | AI 時代の重要度 | 自動化の効きどころ |
|---|---|---|
| ユニットテスト | 高（AI 生成コードのテストファースト化） | AI による自動生成 + カバレッジ判定 |
| 結合テスト | 高（API 変更が増えるため） | コントラクトテスト、API モック自動化 |
| E2E テスト | 中（不安定だと AI 生成の頻繁な変更で破綻） | Playwright / Cypress + AI 自己修復テスト |
| 負荷・パフォーマンス | 中（性能劣化を検知する基盤が必須） | k6 / Locust + 性能リグレッション自動化 |
| セキュリティ | 必須（AI 生成のセキュリティ穴を防ぐ） | SAST / DAST / 依存関係スキャン |
領域 4：運用・SRE・CI/CD
AI コーディングで開発スピードが上がるほど、本番運用の事故リスクも上がります。DORA Report の指標である「デプロイ頻度」「変更失敗率」「平均復旧時間」「変更リードタイム」は、運用基盤の成熟度がないと AI コーディングの効果を打ち消します。
| 運用指標 | AI 時代に求められる水準 | 開発会社の関与 |
|---|---|---|
| デプロイ頻度 | 週 1 回以上を安定運用 | CI/CD パイプライン整備、デプロイ承認フロー |
| 変更失敗率 | 15% 以下を目標 | ロールバック設計、フィーチャーフラグ |
| 平均復旧時間 (MTTR) | 1 時間以内 | 監視・アラート整備、ランブック整備 |
| 変更リードタイム | 1 日以内 | 自動テスト、CI/CD 高速化 |
まとめ：開発会社の価値は「コードを書く」から「要件定義・レビュー・品質・運用の体制を作る」に移行しています。中堅企業が依頼すべきスコープも、ここに合わせて変える必要があります。
「AI を入れたが効果が出ない」組織の典型 3 パターン
DORA の「AI は組織を増幅する」原則は、逆方向にも働きます。組織の弱点が AI でさらに増幅されるパターンを 3 つに整理します。
パターン 1：レビュー文化がない組織
コードレビューを「形だけ」「とりあえず承認」で済ませている組織が AI コーディングを導入すると、AI 生成コードのバグ・脆弱性がそのまま本番に流れます。半年後には「動かないシステム」と「障害件数の急増」が同時発生します。
パターン 2：テスト基盤がない組織
ユニットテスト・結合テストの自動化基盤がない状態で AI コーディングを使うと、(a) 生成コードがどこを壊しているか分からない、(b) 既存機能の回帰が増える、(c) リファクタリングが怖くてできない、の連鎖で開発速度がむしろ低下します。
パターン 3：運用基盤・SRE 体制がない組織
CI/CD・監視・ロールバック設計が貧弱な状態で AI コーディングを使うと、デプロイ事故率が急上昇します。DORA で言う「変更失敗率」が悪化し、結果として開発チームがリリースを怖がって AI コーディングの効果が逆に下がります。
| パターン | 症状 | 6 ヶ月後の状態 |
|---|---|---|
| レビュー文化なし | バグ件数・脆弱性件数の急増 | 顧客苦情の急増、事業損害 |
| テスト基盤なし | 既存機能の回帰、リファクタ恐怖 | 開発速度の低下、技術的負債の累積 |
| 運用基盤なし | デプロイ事故、ロールバック頻発 | リリース凍結、AI コーディング撤退 |
中堅企業の現実解：内製＋伴走＋受託のハイブリッド
中堅企業が AI 時代のシステム開発体制を作る場合、内製・伴走・受託の組合せが現実的です。
| 役割 | 担当 | 内訳 |
|---|---|---|
| 業務オーナー・要件決定 | 内製（事業部門 + 情シス） | 何を作るかの意思決定 |
| アーキテクト・設計レビュー | 伴走（外部 + 内製育成） | 技術選定、データモデル、API 設計 |
| AI コーディング・実装 | 内製＋受託 | AI ツールを使った実装、複雑領域は受託 |
| コードレビュー | 受託（開発会社） | セキュリティ、パフォーマンス、整合性 |
| テスト・品質保証 | 受託（開発会社） | 自動テスト基盤、E2E、セキュリティテスト |
| CI/CD・運用 SRE | 受託（開発会社） | パイプライン、監視、ロールバック設計 |
まとめ：内製も外注も「やめる／やめない」の二択ではありません。AI コーディングを内製で使いながら、レビュー・テスト・運用は受託に出すハイブリッドが、中堅企業の合理解です。
2026 年の開発会社選定 4 つの新基準
「ツール比較」「実績数」「単価」だけで開発会社を選ぶ時代は終わりました。2026 年の選定基準を 4 つに整理します。
基準 1：AI ツール選定力（AI を使いこなせるか）
- どの AI コーディングツール（Claude Code / Cursor / Copilot / Cline 等）を実プロジェクトで使っているか
- AI 生成コードの品質基準を持っているか
- AI を使わない領域の判断基準を持っているか
基準 2：体制設計力（要件定義・設計の品質）
- 要件定義フェーズに何 % の工数を割いているか
- アーキテクト人材が常駐するか
- データモデル・API 設計のレビュー文化があるか
基準 3：レビュー文化（成果物の品質保証）
- コードレビューの実施率・レビュー時間を提示できるか
- セキュリティレビューの自動化基盤を持っているか
- ペアプログラミング・モブプログラミングの実施実績があるか
基準 4：自動化基盤（CI/CD・テスト・運用）
- DORA 4 指標（デプロイ頻度・変更失敗率・MTTR・リードタイム）を測定しているか
- 自動テストカバレッジの実績を提示できるか
- 監視・ロールバック設計のテンプレートを持っているか
選定時の質問チェックリスト：
| 質問 | 期待される回答の方向性 |
|---|---|
| AI コーディングツールは何を使っていますか？ | 複数を比較したうえで、案件に応じて選んでいる |
| コードレビューはどの工程で誰が行いますか？ | PR 単位で必ず別エンジニアがレビュー、自動レビューも併用 |
| デプロイ頻度・変更失敗率の実績は？ | DORA 指標を計測しており、四半期ごとに改善 |
| 障害発生時の対応プロセスは？ | ランブック整備、平均復旧時間を測定 |
| 内製化支援は可能ですか？ | Phase 1〜2 は伴走、Phase 3 以降で内製比率を上げる設計 |
FAQ
Q1. 自社で内製化したい。受託は使わずに進めるべきか。
A. 完全内製化は中堅企業の規模では難しいケースが多いです。事業価値の意思決定とコア業務知識は内製が望ましいですが、レビュー・テスト・運用基盤は受託のほうがコスト効率が良いです。Phase 1〜2 で受託と組んで体制を作り、Phase 3 以降で内製比率を上げるハイブリッドが現実解です。
Q2. AI コーディングで内製チームの生産性を上げる方法は？
A. (1) AI コーディングツールの社内ガイドライン策定、(2) コードレビュー自動化（AI による一次レビュー＋人による最終承認）、(3) ユニットテスト自動生成と CI 統合、(4) 月 1 回の事例共有会、の 4 点が効果的です。これらは受託パートナーと一緒に整備するのが速いです。
Q3. 既存システムが古い。AI 時代に向けてどこから手を付けるか。
A. (1) DORA 4 指標を測定する、(2) 自動テスト・CI/CD を整備する、(3) アーキテクチャを見直してマイクロサービス化や API 化を進める、の順序が一般的です。すべてを一括改修するのではなく、Phase 1（測定）→ Phase 2（基盤）→ Phase 3（アーキテクチャ）の順で進めます。
Q4. 開発会社のレベル感をどう判断するか。
A. 4 基準のうち最も差が出るのは「自動化基盤」です。CI/CD パイプラインのデモ、自動テストカバレッジの実績、DORA 4 指標の計測有無を提案フェーズで聞いてください。これらに即答できない開発会社は、AI 時代の中堅企業の伴走パートナーには不向きです。
Q5. 単価が高い開発会社を選ぶ価値はあるか。
A. 単価ではなく「総コスト」で評価してください。レビュー・テスト・運用基盤を内製で揃えれば年 1,500〜3,000 万円の初期投資が必要です。単価が高くてもこれらをセット提供する開発会社のほうが、3 年トータルでは安くなるケースが多いです。
Q6. AI 時代に開発会社の役割は今後 5 年でどう変わるか。
A. 「コードを書く役割」はさらに縮小し、「要件定義のファシリテーター」「アーキテクト」「品質保証の自動化基盤エンジニア」「SRE」の役割が中心になります。中堅企業が選ぶべきは、これらの方向にすでに体制を作っている開発会社です。
まとめ
- Stack Overflow 2025：開発者 84% / プロ 51% が AI を日常使用
- DORA 2025：AI は組織を増幅する。ツールより組織・プロセス・基盤が成果を決める
- 開発会社の価値は要件定義・設計、レビュー、テスト・品質保証、CI/CD・運用の 4 領域へシフト
- 「AI を入れたが効果が出ない」3 パターン：レビュー文化なし、テスト基盤なし、運用基盤なし
- 中堅企業は内製＋伴走＋受託のハイブリッドが現実解
- 開発会社選定の 4 新基準：AI ツール選定力、体制設計力、レビュー文化、自動化基盤
「AI 時代に通用する開発体制」を一緒に設計しませんか？
GXO は中堅企業の AI 時代のシステム開発を、要件定義・設計から、コードレビュー自動化、テスト・品質保証基盤、CI/CD・SRE 設計まで一貫支援します。DORA 4 指標を測定可能な体制を作り、AI コーディングを安全に高速化する設計をご提案します。NDA 締結可、藤吉ダイレクト窓口で承ります。営業電話はしません。
※ 営業電話はしません ｜ オンライン対応可 ｜ 導入事例はこちら
参考文献
- Stack Overflow "2025 Developer Survey: AI" — https://survey.stackoverflow.co/2025/ai
- Google Cloud "DORA State of DevOps Report 2025" — https://cloud.google.com/devops/state-of-devops
- Anthropic "Model Context Protocol" — https://modelcontextprotocol.io/
- McKinsey & Company "The State of AI: Global Survey 2025" — https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai
追加の一次情報・確認観点
この記事の内容を社内で検討する場合は、一般論だけで判断せず、次の一次情報と自社データを照合してください。特に、稟議・RFP・ベンダー選定では「何を実装するか」よりも「どのリスクをどの水準まで下げるか」を先に決めると、見積もり比較のブレを抑えられます。
| 確認領域 | 参照先 | 自社で確認すること |
|---|---|---|
| AIリスク管理 | NIST AI Risk Management Framework | 用途、リスク、評価方法、運用責任者を確認する |
| LLMセキュリティ | OWASP Top 10 for LLM Applications | プロンプトインジェクション、情報漏えい、権限設計を確認する |
| AI事業者ガイドライン | 総務省 AI関連政策 | 説明責任、透明性、安全性、利用者保護の観点を確認する |
| DX推進 | IPA デジタル基盤センター | DX推進指標、IT人材、デジタル基盤の観点で現状を確認する |
| 個人情報 | 個人情報保護委員会 | 個人情報・委託先管理・利用目的・安全管理措置を確認する |
稟議・RFPで使う数値設計
投資判断では、導入前後で測れる指標を3から5個に絞ります。下表のように、現状値・目標値・測定方法・責任者をセットにしておくと、PoC後に本番化するかどうかを判断しやすくなります。
| 指標 | 現状確認 | 目標の置き方 | 失敗しやすい例 |
|---|---|---|---|
| 対象業務数 | 現状の対象業務を棚卸し | 初期は1から3業務に限定 | 対象を広げすぎて要件が固まらない |
| 月間処理件数 | 件数、担当者、例外率を確認 | 上位20%の高頻度業務から改善 | 件数が少ない業務を先に自動化する |
| 例外対応率 | 手戻り、確認待ち、属人判断を計測 | 例外の分類と承認ルールを定義 | 例外をAIやシステムだけで吸収しようとする |
| 正答率・再現率 | テストデータで評価 | 業務許容ラインを明文化 | 体感評価だけで本番化する |
| 人手確認率 | 承認が必要な判断を分類 | 高リスク判断は人間承認 | 全自動化を前提に設計する |
よくある失敗と回避策
| 失敗パターン | 起きる理由 | 回避策 |
|---|---|---|
| 目的が曖昧なままツール選定に入る | 比較軸が価格や機能数に寄る | 経営課題、業務課題、測定KPIを先に固定する |
| 現場確認が不足する | 例外処理や非公式運用が見落とされる | 担当者ヒアリングと実データ確認を必ず行う |
| 運用責任者が決まっていない | 導入後の改善が止まる | 業務側とIT側の責任分界をRACIで定義する |
| AIの回答品質を本番で初めて確認する | 評価データと禁止事項が未定義 | テストセット、NG例、監査ログを用意する |
GXOに相談する前に整理しておく情報
初回相談では、次の情報があると診断と提案の精度が上がります。すべて揃っていなくても問題ありませんが、分かる範囲で用意しておくと、概算費用・期間・体制の見立てを早く出せます。
- 対象業務の現行フロー、利用中システム、Excel・紙・チャット運用の一覧
- 月間件数、担当人数、手戻り件数、確認待ち時間などの概算
- 個人情報、機密情報、外部委託、権限管理に関する制約
- 希望開始時期、予算レンジ、社内承認者、決裁までの流れ
- AIに任せたい業務、任せてはいけない判断、評価に使える過去データ
GXOでは、現状整理、要件定義、RFP作成、ベンダー比較、PoC設計、本番移行計画まで一気通貫で支援できます。記事の内容を自社に当てはめたい場合は、まずは現在の課題と制約を共有してください。