「AI に書かせたら 1 週間でシステムができた」――でも、要件定義は曖昧、テストは不十分、法令準拠は未確認、運用設計はゼロ。それは“動くプロトタイプ”であって“事業に使えるシステム”ではない。 AI でコードが速く書ける時代になったからこそ、要件定義 → 設計 → 開発 → テスト → 法令準拠 → 運用保守 を一貫してつなぐ開発体制が、中堅企業（年商 30-300 億）の競争力を左右する。
IPA と京都大学の研究組織 KILAP の共同研究は、AI 利活用が進む中で 法令・ガイドライン・標準とソフトウェアエンジニアリング実務をどう接続するかを整理している（IPA「AI時代のルール（法・標準）とソフトウェアエンジニアリングに関する共同調査研究報告書」）。コードを書く部分が AI で加速するほど、その前後の「ルールとの接続」「運用への引き渡し」が相対的に重要になる。
本記事は、AI 時代の開発で抜けやすい 6 工程、法・標準・運用を接続する開発体制、開発会社に確認すべき 10 項目、内製 vs 外注 vs ハイブリッドの選び方、よくある失敗、FAQ を一次ソースとともに整理する。
目次
- 「作って終わり」が通用しない理由
- AI 時代の開発で抜けやすい 6 工程
- 法・標準・運用を接続する開発体制
- 開発会社に確認すべき 10 項目
- 内製 vs 外注 vs ハイブリッドの選び方
- AI 時代の開発でよくある失敗 7 パターン
- よくある質問（FAQ 10 問）
- 参考一次ソース
「作って終わり」が通用しない理由
AI コーディングツール（GitHub Copilot / Cursor / Claude Code 等）の普及で、コードを書く工程は劇的に速くなった。しかし、システム開発の全工程のうち、コーディングは一部に過ぎない。
システム開発の全工程
要件定義 → 基本設計 → 詳細設計 → 実装(コーディング) → テスト
→ 法令準拠確認 → セキュリティレビュー → デプロイ → 運用保守
AI が加速するのは「実装」工程だけ。前段（要件定義・設計）と後段（テスト・法令準拠・運用保守）は、依然として人間の判断と体制が必要だ。
「動く」と「事業に使える」のギャップ
| 観点 | 動くプロトタイプ | 事業に使えるシステム |
|---|---|---|
| 要件 | 曖昧でも動けばOK | 業務要件を網羅、例外も考慮 |
| テスト | 手動で 1 回確認 | 自動テスト + 異常系 + 負荷 |
| 法令準拠 | 未確認 | 電子帳簿保存法 / 特商法 / 個情法 準拠 |
| セキュリティ | 未対策 | OWASP Top 10 対策、認可・認証 |
| 運用 | 設計なし | 監視 / バックアップ / 障害対応 / 継承 |
| 保守 | 属人化 | ドキュメント + 引き継ぎ可能 |
AI で「動くプロトタイプ」を量産できる時代こそ、この右側のギャップを埋める体制が差別化要因になる。
FREE CONSULTATION
この記事の内容について、専門家に相談できます
AI・DX・セキュリティに関するご質問やお見積もりなど、お気軽にお問い合わせください。
AI 時代の開発で抜けやすい 6 工程
AI 主導の開発で特に抜け落ちやすい 6 工程を整理する。
工程 1: 要件定義（業務の本質理解）
AI は「言われたものを作る」のは得意だが、「本当に必要なものは何か」を業務文脈から定義するのは人間の仕事。要件が曖昧なまま実装すると、現場で使われないシステムになる。
工程 2: 法令準拠の確認
AI 生成コードは「動く」が、日本固有の法令（電子帳簿保存法 / 特商法 / 改正個情法）への準拠は組み込まれない。要件定義段階で法令要件をチェックリスト化する必要がある。
工程 3: テスト設計（異常系・境界値）
AI は正常系のテストは書けるが、異常系・境界値・負荷テストの設計は人間の経験が必要。「動いた」で本番投入すると、想定外入力でクラッシュする。
工程 4: セキュリティレビュー
OWASP Top 10（SQL Injection / 認可漏れ等）への対策は、AI 任せでは抜ける。コードレビュー + 静的解析 + ペネトレーションテストの体制が必要。
工程 5: 運用設計（監視・バックアップ・障害対応）
「作る」と「運用する」は別。監視・バックアップ・障害対応・BCP の設計がないと、本番で止まったとき復旧できない。
工程 6: 保守・継承（ドキュメント・属人化解消）
AI で速く作るほど、ドキュメントなき属人化システムが量産される。担当者退職で保守不能になるリスク（経産省「2025 年の崖」の中堅企業版）。
6 工程の重要度（AI 時代に相対的に上昇）
コーディング工程: AI で加速 → 相対的に重要度低下
要件定義・法令・テスト・セキュリティ・運用・保守: 人間必須 → 相対的に重要度上昇
AI が実装を速くするほど、その前後の 6 工程が開発の品質を決める。
法・標準・運用を接続する開発体制
IPA × 京大 KILAP の共同研究が指摘する通り、AI 時代は 法令・ガイドライン・標準とエンジニアリング実務の接続が重要になる。中堅企業向けの体制設計を整理する。
参考: IPA「AI時代のルール（法・標準）とソフトウェアエンジニアリングに関する共同調査研究報告書」
接続すべき 3 つの「ルール」
- 法令: 電子帳簿保存法 / 特商法 / 改正個情法 / 業界規制
- ガイドライン: AI 事業者ガイドライン / セキュリティ経営ガイドライン / 各種公的指針
- 標準: ISO / OWASP / NIST / 業界標準
これらを 要件定義段階で開発要件に組み込むことが、後工程での手戻り・違反を防ぐ。
開発体制の役割分担
| 工程 | 担当 |
|---|---|
| 要件定義 + 法令・標準の組み込み | 業務担当 + 外部 CTO / 上流コンサル |
| 設計・実装 | 開発チーム（AI ツール活用） |
| テスト・セキュリティレビュー | QA + セキュリティ専門家 |
| 法令準拠の最終確認 | 顧問弁護士 + 外部 CTO |
| 運用設計・保守 | 情シス + 運用チーム + ドキュメント整備 |
「上流」と「下流」をつなぐ役割
AI 時代の開発で最も価値が高いのは、法令・業務要件（上流）とエンジニアリング実務（下流）をつなぐ役割。これは：
- 業務を理解し、要件を定義できる
- 法令・標準を実装要件に翻訳できる
- AI ツールを使いこなしつつ品質を担保できる
- 運用・保守まで見据えて設計できる
中堅企業がこの役割を内製で持てない場合、外部 CTO / 開発パートナーが担う。
FREE DOWNLOAD
AI導入チェックリスト（PoC 失敗要因 10項目）
情シス部門が PoC 前に押さえるべき失敗要因を10項目に整理した無料チェックリスト。
開発会社に確認すべき 10 項目
中堅企業がシステム開発を外注する際、開発会社に確認すべき 10 項目。
□ 1. 要件定義から運用保守まで一貫対応できるか（実装だけの会社は要注意）
□ 2. 法令準拠（電子帳簿保存法 / 特商法 / 改正個情法）を要件に組み込むか
□ 3. テスト（自動テスト + 異常系 + 負荷）の体制があるか
□ 4. セキュリティレビュー（OWASP Top 10 / 認可・認証）を実施するか
□ 5. 運用設計（監視 / バックアップ / 障害対応 / BCP）まで提案するか
□ 6. ドキュメントを納品物に含むか（属人化防止）
□ 7. AI ツールを活用しつつ品質を担保する体制か
□ 8. 保守・継承を見据えた設計か（担当者交代でも継続可能か）
□ 9. 内製化支援（自社で運用できるよう移管）に対応するか
□ 10. 過去の類似案件の実績 + 失敗からの学びを語れるか
「安くて速い」だけで選ぶと、後工程（テスト・法令・運用）が抜けて、結局トラブルとリライトでコスト増になる。上流から下流まで一貫して見られる会社を選ぶ。
内製 vs 外注 vs ハイブリッドの選び方
比較
| 方式 | メリット | デメリット | 向くケース |
|---|---|---|---|
| 内製 | 業務理解深い / 機動的 | 人材確保困難 / 属人化リスク | エンジニア採用・育成できる規模 |
| 外注 | 専門性 / 体制完備 | コミュニケーションコスト / 業務理解の壁 | 自社にエンジニアがいない |
| ハイブリッド | 上流内製 + 下流外注 等 | 役割分担の設計が必要 | 中堅企業の現実解 |
中堅企業の現実解：ハイブリッド
| 役割 | 担当 |
|---|---|
| 業務要件定義 | 内製（業務を知る社員） |
| 設計・実装 | 外注 or 内製 + 外部 CTO 監修 |
| 法令・標準の接続 | 外部 CTO / 顧問 |
| テスト・セキュリティ | 外注（専門性） |
| 運用・一次対応 | 内製 |
| 高度な保守・改修 | 外注 |
「全部内製」も「全部丸投げ」も極端。上流（業務理解）は内製、専門性が要る部分は外注、というハイブリッドが多くの中堅企業に適する。
AI 時代の開発でよくある失敗 7 パターン
- プロトタイプを本番投入: 「動いた」で本番化し、異常系・負荷でクラッシュ
- 法令準拠の見落とし: 電子帳簿保存法・特商法・個情法を後から指摘され手戻り
- テスト不足: AI 生成コードを未検証で投入し、想定外入力でバグ
- セキュリティ未対策: 認可漏れ・SQL Injection 等で情報漏えい
- 運用設計ゼロ: 監視・バックアップなしで本番運用、障害で復旧不能
- ドキュメントなき属人化: 速く作った分、引き継ぎ不能なブラックボックス量産
- 「安くて速い」だけで外注先選定: 後工程が抜けてトラブル・リライトでコスト増
これらは、「実装の速さ」だけを評価し、要件定義・法令・テスト・運用・保守を軽視することが共通の根本原因だ。
よくある質問（FAQ 10 問）
Q1. AI でシステムを作れば開発会社は不要になる？
A. コーディング工程は加速するが、要件定義・法令準拠・テスト・運用・保守は依然として体制が必要。AI は道具、それを使いこなして品質を担保する役割が重要になる。
Q2. 「動くプロトタイプ」と「事業システム」の違いは？
A. プロトタイプは「正常系で動く」、事業システムは「異常系・負荷・法令・セキュリティ・運用・保守」まで担保したもの。後者には体制とコストがかかる。
Q3. 開発会社を「安くて速い」で選ぶのはダメ？
A. 後工程（テスト・法令・運用）が抜けるとトラブル・リライトで結局高くつく。一貫対応できるかを確認すべき。
Q4. 法令準拠は開発会社に任せられる？
A. 法令準拠を要件に組み込む開発会社もあるが、最終確認は顧問弁護士 + 外部 CTOが望ましい。電子帳簿保存法・特商法・個情法は専門性が要る。
Q5. 内製化したいが人材がいない場合は？
A. 外部 CTO / 開発パートナーの伴走 + 内製化支援が現実解。設計を学びながら徐々に内製比率を上げる。
Q6. AI 生成コードの品質はどう担保する？
A. コードレビュー + 自動テスト + 静的解析 + セキュリティスキャン（OWASP ZAP / Snyk 等）の体制。AI 出力を人間がレビューする前提。
Q7. 運用設計とは具体的に何をする？
A. 監視（メトリクス・アラート）/ バックアップ（取得・検証）/ 障害対応（手順・連絡体制）/ BCP（事業継続）の設計。
Q8. ドキュメントはどこまで作るべき？
A. システム仕様書 / 運用手順書 / 障害対応書 / アーキテクチャ図。担当者交代でも継続できるレベル。AI でドキュメント生成も活用可。
Q9. 中小企業でも一貫体制は必要？
A. 必要。規模が小さいほど属人化・保守負債のリスクが致命的。最小限でも要件定義・テスト・運用・ドキュメントは押さえる。
Q10. 既存の動くプロトタイプを事業システム化するには？
A. 要件の再整理 → 法令準拠確認 → テスト整備 → セキュリティレビュー → 運用設計 → ドキュメント化、の順で「右側の工程」を補う。
参考一次ソース
- IPA「AI時代のルール（法・標準）とソフトウェアエンジニアリングに関する共同調査研究報告書」
- IPA「社会・産業のデジタル変革」
- 経済産業省「DXレポート」
- 総務省・経産省「AI事業者ガイドライン」
- IPA「情報セキュリティ10大脅威 2026」
- 経済産業省「サイバーセキュリティ経営ガイドライン Ver 3.0」
まとめ
- AI でコードが速く書ける時代こそ、要件定義・法令準拠・テスト・セキュリティ・運用・保守の前後工程が品質を決める
- IPA × 京大 KILAP 研究は 法・標準・運用とエンジニアリングの接続の重要性を示す
- 開発会社は 「一貫対応できるか」10 項目で確認、「安くて速い」だけで選ばない
- 中堅企業は 上流内製 + 専門部分外注のハイブリッドが現実解
「作って終わり」のシステムは、事業の足かせになる。AI 時代こそ、上流から運用まで見据えた開発体制が問われる。
要件定義から運用保守まで一貫した開発を相談したい方へ
GXO株式会社は、中堅企業向けに 要件定義 → 設計 → 開発 → テスト → 法令準拠 → 運用保守 を一貫対応するシステム開発を提供しています。
- 上流支援: 業務要件の定義 + 法令・標準の組み込み
- 品質担保: 自動テスト + セキュリティレビュー + コードレビュー
- 運用設計: 監視・バックアップ・障害対応・BCP
- 保守・継承: ドキュメント整備 + 内製化支援で属人化を防ぐ
著者: GXO株式会社 初回公開: 2026 年 5 月 22 日