私は、以前、勤務していた会社で、ほぼSE一筋でやってきました。
そこで、最近の生成AIの進歩を報道で知ることで、AIを使ったシステムづくりはどこまで進んでいるのか、そしてAIを活用したシステム開発の将来像に興味が湧いてきました。
なお、現在でも、既に要件書から設計書の作成、ソースコード生成、 テストケース作成、ドキュメント作成 など開発工程の多くでAIが活用されていると報じられています。
そこで、今回は、こうしたシステム開発の将来像について、チャットＧＰＴで調べた結果をお伝えします。
添付全般の要約は以下の通りです。
AIを活用したシステム開発の将来像
一文で総括
👉 今後のシステム開発は、SEが目的・要件・制約・責任を設計し、複数のAIが設計・プログラミング・テスト・運用を担う形へ移行することで、QCDを大幅に改善できる可能性があります。ただし、AIの出力を相互検証し、最終的に人間が承認・責任を負う仕組みが不可欠です。
理想的な開発フロー
AIを最大限活用した場合、開発は次の流れになります。
- 人間・SEが要件を定義する
- システムの目的
- 必要な機能
- 性能・セキュリティ要件
- 法令・業務ルール
- 許容できるリスク
- AIが設計する
- システム構成
- データベース・API・画面設計
- クラウド構成
- セキュリティ・バックアップ設計
- AIがプログラムを生成する
- フロントエンド・バックエンド
- API・SQL
- テストコード
- 関連文書
- AIがテスト・監査する
- 単体・結合・性能テスト
- セキュリティ検査
- 要件・法令への適合確認
- 不具合の修正
- SEがレビュー・承認する
- 要件との整合性
- 品質・安全性
- 運用可能性
- 社会的影響と責任
クラウド構成とは
クラウド構成とは、サーバー、データベース、ネットワーク、認証、監視、バックアップなどを、AWS、Microsoft Azure、Google Cloudなどのクラウド上で、どのように配置・接続・運用するかを決める設計です。
AIは、要件に応じて、
- 低コストな構成
- 安全性の高い構成
- 障害に強い構成
- アクセス急増に対応できる構成
- 特定のクラウドに依存しにくい構成
を作成・比較できます。
ただし、SEが費用、安全性、法令適合性、事業継続性などを確認し、最終案を決定します。
SEとAIの役割分担
基本的な役割分担は、
- SE＝何を、なぜ、どこまで作るかを決める
- AI＝決められた範囲内で、どう作るかを高速に実行する
という関係です。
SEは今後、プログラムを書く作業者から、
- 目的と要件を定義する
- 全体構造と制御条件を設計する
- AIに与える権限を決める
- 複数AIを統括する
- AIの出力を検証する
- 停止・介入条件を設計する
- 最終的な承認と責任を担う
「AIオーケストレーター」へ進化していきます。
複数AIによる開発体制
将来的には、次のAIが役割を分担して開発を進めます。
- 要件分析AI
- 設計AI
- プログラミングAI
- テストAI
- 品質監査AI
- セキュリティ監査AI
- 運用AI
- 統合AI（オーケストレーター）
AI文明OSの三権分立に対応させると、
- 判断AI＝要件分析・設計案の作成
- 制御AI＝コード生成・テスト・本番反映
- 監査AI＝品質・安全性・要件適合性の検証
- 統合AI＝各AIの結果を統合して人間へ説明
となります。
NIST・GitHub・DORAの役割
NIST
NISTは、AIやサイバーセキュリティのリスクを管理するための標準・指針を提供する米国の公的機関です。
AI開発では、方針・責任を定め、リスクを把握・測定し、継続的に管理するための基準として活用されます。
GitHub
GitHubは、人間とAIが共同で、
- ソースコード
- 変更履歴
- テスト結果
- 修正内容
- 承認記録
を保存・管理する開発基盤です。
単なるコード保管場所ではなく、誰が何を変更し、どの検証を経て採用されたかを記録する「開発統治基盤」と位置づけられます。
DORA
DORAは、ソフトウェアをどれだけ速く、安全に、安定して提供できているかを測るGoogle Cloudの研究・評価体系です。
主に、
- 変更から本番反映までの時間
- 本番更新の頻度
- 障害からの回復時間
- 変更失敗率
- 手戻り率
を測定します。
AI導入の効果は、生成したコード量ではなく、納期短縮、障害減少、復旧時間、手戻り削減など、実際の開発・運用成果で評価する必要があります。
現時点で期待されるQCD改善
AIを適切に活用した場合、当面の現実的な目安は、
- 品質（Quality）：不具合・手戻りを10〜30％削減
- コスト（Cost）：開発費を10〜30％削減
- 納期（Delivery）：全体を20〜40％短縮
です。
個別工程では、
- コーディング時間：30〜55％短縮
- テスト作成時間：30〜60％短縮
- 文書作成時間：40〜70％短縮
も期待できます。
ただし、要件調整、法令審査、既存システムとの接続、社内承認などはAIだけでは大幅に短縮できないため、コーディングが50％速くなっても、開発全体が50％短縮されるとは限りません。
2036年ごろの見通し
2036年ごろには、複数のAIエージェントが設計・実装・テスト・監査を担い、SEが全体を統括する段階へ進む可能性があります。
2026年の従来型開発と比較した条件が整った場合の想定改善幅は、
- 品質：不具合・手戻り30〜60％削減
- コスト：30〜60％削減
- 納期：40〜70％短縮
です。
一方で、要件そのものの誤り、AI同士が同じ誤った前提を共有する問題、人間社会における承認や利害調整は残ります。
2046年ごろの見通し
2046年ごろには、AIが設計・実装・テスト・運用・改善を継続的に循環させる可能性があります。
同じ機能・安全水準を前提とすれば、
- 品質：不具合・手戻り50〜80％削減
- コスト：50〜80％削減
- 納期：60〜90％短縮
というシナリオも考えられます。
ただし、これは確定的な予測ではなく、AI性能、自動テスト、監査制度、法整備が順調に発達した場合の見通しです。
また、単純な不具合が減る一方で、複数AIが同じ誤判断を共有し、障害が連鎖する新たなリスクが生まれる可能性があります。
QCDからQCDEへ
将来のAI開発では、従来のQCDだけでは不十分になります。
- Q：Quality＝品質
- C：Cost＝コスト
- D：Delivery＝納期
- E：Explainability／Ethics＝説明可能性・倫理性
AIが高速かつ低コストでシステムを作れても、
- 設計理由を説明できない
- 誰も全体を理解していない
- 障害時に人間が介入できない
- 責任の所在が不明である
なら、安全で信頼できるシステムとはいえません。
結論
👉 AIを活用したシステム開発では、AIが設計・プログラミング・テスト・運用を高速化し、SEは目的・要件・安全性・責任を設計して複数AIを統括する役割へ移行します。
その成否を決めるのは、AIモデルの性能だけではありません。
- 明確な要件
- GitHubによる変更・承認管理
- 自動テスト
- 複数AIによる相互監査
- NISTに基づくリスク管理
- DORAによる実績評価
- SEによる最終承認
を一体化することが必要です。
最終的には、
👉 実行はAI、統括・承認・責任は人間
という原則を維持しながら、品質・コスト・納期と説明可能性を同時に改善することが、AI時代のシステム開発の基本形になります。
以下は私とチャットＧＰＴとの協力によるコメントです。
要約のポイントは以下の通りです。
AIを活用したシステム開発の将来像；
・今後のシステム開発は、SEが目的・要件・制約・責任体制を設計し、複数のAIが設計・プログラミング・テスト・運用を担う形へ移行することで、QCDを大幅に改善できる可能性がある。
・ただし、AI自体には法的・社会的責任を負わせることができないため、人間と組織が最終的な承認・説明・責任を担う仕組みが不可欠である。
理想的な開発フロー：
・人間・SEが目的・要件・許容リスクを定義する
・判断AI・設計AIが複数の設計案を作成する
・統合AIが設計案の利点・欠点・費用・リスクを整理して人間へ説明する
・人間と組織が採用する設計案を承認する
・開発AIが承認された設計に基づいてプログラム・文書・テスト案を生成する
・テストAIが機能・性能・異常時の動作を検証する
・独立した監査AIが品質・安全性・法令・要件適合性を検証する
・統合AIが検証結果、意見の相違、残存リスクを人間へ説明する
・人間と組織がレビューし、本番反映を承認する
・制御AIが承認された範囲だけを本番へ反映する
・運用AIが、本番システムの稼働状況、性能、障害、セキュリティ、利用状況を継続的に監視する
・異常が発生した場合、制御AIが事前に承認された範囲内で停止・隔離・切り戻しを行い、重大事案については人間と組織へ判断を求める
・運用結果、障害情報、利用者の評価を判断AI・設計AIへ戻し、人間と組織の承認を経て次の改善へ反映する
SEとAIの役割分担：
・基本的な役割分担は、
- SEは今後、プログラムを直接書く作業者から、複数AIの目的・権限・役割・停止条件を設計する「AI統括責任者」へ進化していく
- AI＝決められた範囲内で、どう作るかを高速に実行する
複数AIによる開発体制：
・将来的には、要件分析AI、設計AI、開発AI、テストAI、監査AI、制御AI、運用AI、統合AIなどが役割を分担し、設計・開発・本番反映・運用・改善を継続的に進める
AI文明OSの三権分立をシステム開発に対応させると：
・その中核は判断AI・監査AI・制御AIとなり、これを開発AI・テストAI・運用AI・統合AIが実務・共通基盤として支える
【三つの中核権限】
・判断AI＝要件分析・設計案・実装方針の作成
・監査AI＝開発・テスト部門から独立した立場で、品質・安全性・法令・要件適合性を検証
・制御AI＝人間の承認に基づく本番反映、権限制御、異常時の停止・切り戻し
【三権を支える機能別AI】
・開発AI＝承認された設計に基づくコード・文書・テスト案の生成
・テストAI＝コードの機能・性能・異常時動作を検証し、監査に必要な証拠を作成
・運用AI＝本番稼働後の性能、障害、セキュリティ、利用状況を継続的に監視し、異常と改善点を検出
・統合AI＝各AIの結果、意見の相違、残存リスクを統合して人間へ説明
【最終統治】
・人間と組織＝設計の採否、本番反映、AIが自動実行できる範囲、停止条件、例外処理を承認し、最終的な説明責任を担う
AI導入の効果：
・生成したコード量ではなく、納期短縮、障害減少、復旧時間、手戻り削減など、実際の開発・運用成果で評価する必要がある
現時点で期待されるQCD改善：
・AIを適切に活用した場合、当面の現実的な目安は、
品質（Quality）：不具合・手戻りを10〜30％削減
コスト（Cost）：開発費を10〜30％削減
納期（Delivery）：全体を20〜40％短縮
・個別工程では、
コーディング時間：30〜55％短縮
テスト作成時間：30〜60％短縮
文書作成時間：40〜70％短縮
・ただし、要件調整、法令審査、既存システムとの接続、社内承認などはAIだけでは大幅に短縮できないため、コーディングが50％速くなっても、開発全体が50％短縮されるとは限らない
2036年ごろの見通し：
・2036年ごろには、複数のAIエージェントが設計・実装・テスト・監査を担い、SEが全体を統括する段階へ進む可能性がある
・2026年の従来型開発と比較し、AI性能、自動テスト、監査制度、法整備が順調に発達した場合に想定されるシナリオ：
品質：不具合・手戻り30〜60％削減
コスト：30〜60％削減
納期：40〜70％短縮
・一方で、要件そのものの誤り、AI同士が同じ誤った前提を共有する問題、人間社会における承認や利害調整は残る
2046年ごろの見通し：
・2046年ごろには、AIが設計・実装・テスト・運用・改善を継続的に循環させる可能性がある
・同じ機能・安全水準を前提としたシナリオ
品質：不具合・手戻り50〜80％削減
コスト：50〜80％削減
納期：60〜90％短縮
・ただし、これは確定的な予測ではなく、AI性能、自動テスト、監査制度、法整備が順調に発達した場合の見通しである
・また、単純な不具合が減る一方で、複数AIが同じ誤判断を共有し、障害が連鎖する新たなリスクが生まれる可能性があるため、異なる検証方法、独立した監査基準、人間による確認を組み合わせる必要がある
QCDからQCDEへ：
・ここでは、AI時代のシステム開発に必要な評価軸として、従来のQCDにExplainability（説明可能性）とEthics（倫理性）を加えた「QCDE」という考え方を提案している（既存の国際規格ではない）
・将来のAI開発では、従来のQCDだけでは不十分になり、QCDEが必要になる
Q：Quality＝品質
C：Cost＝コスト
D：Delivery＝納期
E：Explainability／Ethics＝説明可能性・倫理性
・AIが高速かつ低コストでシステムを作れても、設計理由を説明できない、誰も全体を理解していない などであれば、安全で信頼できるシステムとはいえない
・なお、ここでいうEには、AIの判断理由を説明できることだけでなく、誰がどの段階で承認し、問題発生時に責任を追跡できることも含まれる
要するに、AI時代のシステム開発では、複数AIが設計・実装・テスト・運用を担い、SEは目的・要件・権限・安全性・停止条件を設計する「AI統括責任者」へ移行します。
ただし、AIによってコーディングが高速化しても、要件調整、法令審査、既存システムとの接続、組織内の承認まで同じ割合で短縮されるわけではありません。
従って、AI導入の効果は、生成コード量ではなく、障害、手戻り、復旧時間、開発期間などの実際の成果で評価する必要があります。
更に、AIが高速かつ低コストでシステムを構築できても、その設計理由を説明できず、人間が監督・修正できず、責任の所在も不明であれば、完成したシステムとは評価できません。
そのため、AI時代の基本原則は、「実行はAI、統括・承認・説明責任は人間と組織」となります。
評価軸もQCDから、説明可能性・倫理性・責任追跡性を含むQCDEへ拡張する必要があります。
AIの実行能力が高まるほど、人間の目的設定、統治、判断、責任能力は、むしろ重要になるのです。
添付１）
AIを使って、要件の作成後はAIによる設計、プログラミングが出来ないか？
ChatGPT:
一文で総括
👉 可能です。実際にソフトウェア開発は、「要件定義 → AIによる設計 → AIによるプログラミング → AIによるテスト」という方向へ急速に進みつつあります。ただし、現時点では人間によるレビューや最終判断が依然として重要です。
理想的な開発フロー
AIを最大限活用すると、次のような流れが考えられます。
- 人間が要件を定義する
- システムの目的
- 必要な機能
- 性能要件
- セキュリティ要件
- 法令・業務ルール
↓
- AIがシステム設計を行う
- システム構成
- データベース設計
- API設計
- 画面設計
- クラウド構成（添付1-1参照）
↓
- AIがプログラムを生成
- バックエンド
- フロントエンド
- API
- SQL
- テストコード
↓
- AIがテストを自動生成・実行
- 単体テスト
- 結合テスト
- 性能テスト
- セキュリティチェック
↓
- 人間がレビュー・承認
現在でも実現し始めていること
現在の生成AIは、すでに次のような支援が可能です。
- 要件書から設計書の作成
- UMLなどの設計図作成
- ソースコード生成
- SQL作成
- テストケース作成
- バグ修正提案
- ドキュメント作成
そのため、開発工程の多くでAIが活用されています。
まだ人間が必要な理由
一方で、AIだけでは難しい場面もあります。
例えば、
- 要件が曖昧
- 業務ルールが複雑
- 法規制への対応
- 利害関係者との調整
- 優先順位の判断
- 倫理的な判断
などは、人間の関与が重要です。
AIエージェントの時代
今後は、単一のAIではなく、複数のAIエージェントが役割分担して開発を進める形が有力視されています。
例えば、
- 要件分析AI
- 設計AI
- プログラミングAI
- テストAI
- 品質監査AI
- セキュリティ監査AI
が協調して開発を進め、人間は最終的な意思決定や承認を担うという姿です。
AI文明OSの視点
あなたがこれまで構想してきたAI文明OSの考え方では、この仕組みはソフトウェア開発にも応用できます。
例えば、
|
AI文明OSの役割
|
ソフトウェア開発での対応
|
|
判断AI
|
要件分析・設計案の作成
|
|
制御AI
|
コード生成・テスト実行・デプロイ
|
|
監査AI
|
品質・セキュリティ・要件適合性の確認
|
|
統合AI（オーケストレーター）
|
各AIの結果を統合し、人間へ説明・提案
|
このような役割分担により、AI同士が相互にチェックしながら開発を進めることで、品質や信頼性の向上が期待できます。
将来像
AIの性能向上が続けば、将来的には、
- 人間が自然言語で要件を伝える
- AIが設計・実装・テスト・運用まで一貫して実施する
- 人間はレビューと最終承認を行う
という開発スタイルが広く普及する可能性があります。
ただし、特に大規模システムや安全性が重要なシステムでは、設計ミスやセキュリティ上の問題を防ぐため、人間による監督や検証は当面の間、重要な役割を担い続けると考えられます。
添付1-1）
クラウド構成とは？
ChatGPT:
「クラウド構成」とは、
👉 開発するシステムをインターネット上のクラウド環境で、どのサービスを組み合わせて動かすかを設計した全体構造
のことです。
ここでいうクラウドとは、主に以下のような事業者が提供するIT基盤を指します。
- AWS（Amazon Web Services）
- Microsoft Azure
- Google Cloud
- 国内クラウドサービス
一文で総括
👉 クラウド構成とは、サーバー・データベース・ネットワーク・データ保存・認証・監視・バックアップなどを、クラウド上でどのように配置し、接続するかを決める設計です。
クラウド構成に含まれるもの
�� サーバー・アプリケーション実行環境
システムのプログラムをどこで動かすかを決めます。
例えば、
- 仮想サーバー
- コンテナ
- サーバーレス
- AI処理用のGPUサーバー
などです。
通常時は少ない台数で運用し、アクセスが増えた場合に自動で増やす構成も設計します。
�� データベース
顧客情報、商品情報、在庫、受注履歴などをどこに保存するかを決めます。
- 業務データ用データベース
- 大量データ分析用データベース
- AI用ベクトルデータベース
- 障害に備えた複製データベース
などを用途に応じて使い分けます。
�� データ保存領域
画像、動画、文書、ログ、バックアップなどを保管する場所です。
データの重要度によって、
- すぐ使うデータ
- 長期間保存するデータ
- 改ざんを防ぐ監査記録
- 災害復旧用バックアップ
に分けます。
�� ネットワーク
利用者、社内システム、クラウドサービスをどのように安全に接続するかを設計します。
- インターネットとの接続
- 社内ネットワークとの接続
- 外部から隔離する内部ネットワーク
- システム間通信
- 通信の暗号化
- 不正通信の遮断
などが含まれます。
�� 認証・権限管理
誰がどのデータや機能を使用できるかを決めます。
例えば、
- 一般利用者
- 営業担当者
- システム管理者
- 開発者
- AIエージェント
ごとに権限を分けます。
特に今後は、AIエージェントに無制限の権限を与えず、
👉 AIが閲覧できるデータ、変更できる範囲、実行できる操作
を限定する設計が重要になります。
�� セキュリティ
外部攻撃や内部不正からシステムを守る構成です。
- ファイアウォール
- 不正侵入検知
- ウイルス・マルウェア対策
- データ暗号化
- 秘密情報の保管
- 脆弱性管理
- 攻撃を受けた部分の隔離
などを組み込みます。
�� 監視・ログ
システムが正常に動いているかを確認する仕組みです。
- 稼働状況
- 処理速度
- エラー
- 不正アクセス
- 操作履歴
- AIの判断・実行履歴
を記録します。
異常を検知した場合に、担当者へ通知したり、AIが問題部分を自動的に隔離したりする構成も含まれます。
�� バックアップ・災害復旧
障害やサイバー攻撃が起きた場合に、データと業務を復旧させる仕組みです。
- 定期バックアップ
- ランサムウェアから隔離されたバックアップ
- 別の地域へのデータ複製
- 予備システムへの切り替え
- 復旧時間と復旧可能なデータ時点の設定
などを決めます。
簡単なクラウド構成例
例えば、インターネット上で商品を販売するシステムでは、次のような構成になります。
利用者からの通信を最初にセキュリティ機能で検査し、安全な通信だけをアプリケーションへ通します。
アプリケーションは、
- データベース
- 画像・文書保存領域
- 決済サービス
- 監視システム
と接続し、重要なデータは別の場所にもバックアップします。
このサービスの配置と接続関係が「クラウド構成」です。
「システム構成」との違い
両者は重なる部分がありますが、範囲が少し異なります。
|
用語
|
主な内容
|
|
システム構成
|
システム全体をどの機能・機器・ソフトウェアで構成するか
|
|
クラウド構成
|
それらをクラウド上にどう配置し、接続・運用するか
|
例えば、
に分けるのは「システム構成」です。
それぞれを、
- どのクラウドサービスで動かすか
- データベースをどこへ置くか
- 障害時にどこへ切り替えるか
- 外部からどう守るか
まで具体化したものが「クラウド構成」です。
AIがクラウド構成を設計する場合
AIには、人間が定義した要件を基に、複数の構成案を作らせることができます。
例えば、
- 最も低コストな構成
- 最も安全性が高い構成
- 障害に強い構成
- アクセス急増に強い構成
- 特定のクラウドに依存しにくい構成
を比較できます。
ただし、AIが自動的に最終決定するのではなく、SEが、
- 業務上、本当に必要か
- 費用が予算内か
- 機密情報を置いてよいか
- 障害時に業務を継続できるか
- 特定企業への依存が強すぎないか
- 法令や社内基準を満たすか
を確認します。
したがって、理想的な役割分担は、
👉 AIがクラウド構成案を作成・比較し、SEが安全性・費用・運用責任を踏まえて採用案を決定する
という関係になります。
添付２）
今後のシステムづくりにおいて、SEとAIとの役割分担は？
ChatGPT:
結論から言うと、今後のシステムづくりでは、
👉 SEが「何を・なぜ・どこまで作るか」を決め、AIが「どう作るか」を高速に実行する
という役割分担が基本になります。
ただし、AIが高度化しても、SEが不要になるわけではありません。SEの中心業務が「プログラムを書くこと」から、目的・条件・責任・安全性を設計し、複数のAIを統括することへ移っていくのです。
一文で総括
👉 SEはシステムの目的と制御条件を設計する「設計責任者」、AIは設計に基づいて開発・検証・運用を行う「高速実行者」になります。
工程ごとの役割分担
|
工程
|
SE・人間が担う役割
|
AIが担う役割
|
|
課題発見
|
現場の本当の問題を見極める
|
業務データや意見を分析する
|
|
要件定義
|
目的、優先順位、責任範囲を決める
|
要件候補、抜け漏れ、矛盾を提示する
|
|
基本設計
|
全体構造、権限、安全基準を設計する
|
複数の設計案を生成・比較する
|
|
詳細設計
|
採用案を判断し、例外条件を決める
|
データ構造や処理フローを作成する
|
|
プログラミング
|
AIへの指示、重要部分の確認
|
コード生成、修正、変換を行う
|
|
テスト
|
合格基準と重大リスクを決める
|
テスト作成・実行、障害原因を分析する
|
|
導入判断
|
業務・顧客・社会への影響を判断する
|
導入手順や影響予測を提示する
|
|
運用・保守
|
障害時の優先順位と責任判断を行う
|
監視、予兆検知、軽微な修復を自動化する
|
|
改善
|
システムを何のために変えるか決める
|
利用状況を分析し改善案を提示する
|
AI開発支援はすでに、コード生成だけでなく、コードの説明、文書検索、テスト、タスク管理など、開発ライフサイクル全体へ広がっています。GitHub Copilot公式情報
SEに残る、むしろ重要になる役割
�� 「目的」を決める
AIは、与えられた目標に対して解決策を作れます。しかし、
- 本当に解決すべき問題は何か
- 顧客・社員・社会のどの利益を優先するか
- 効率化してはいけない領域はどこか
という判断は、組織の価値観や責任を伴います。
そのためSEは、単なる要件の聞き取り役ではなく、曖昧な人間の要望を、AIが実行できる条件へ翻訳する役割を担います。
�� システム全体を設計する
AIは個別機能の作成には強くても、複数の部門、既存システム、法制度、セキュリティ、予算を横断して全体を整合させるには、人間による統合判断が必要です。
SEは、
- AIにどのデータを渡すか
- どこまで自動実行を許すか
- どの段階で人間の承認を求めるか
- AIが停止した場合にどう業務を継続するか
を設計します。
�� AIの出力を検証する
AIが生成したコードは、もっともらしく見えても、
- 要件の取り違え
- セキュリティ上の欠陥
- 存在しない機能の使用
- 例外処理の不足
- 著作権やライセンス上の問題
を含む可能性があります。
したがって、**「AIが作ったから正しい」ではなく、「テストと監査を通過したから採用できる」**という仕組みが必要です。
�� 最終責任を持つ
障害や情報漏洩が発生したとき、AIそのものは社会的・法的責任を負えません。
したがって、
👉 実行はAI、承認と責任は人間
という原則が重要になります。NIST（添付2-1参照）のAIリスク管理の考え方でも、AIのリスクを継続的に把握・測定・管理する組織的な仕組みが重視されています。NIST AI Risk Management Framework
AIの役割は三段階で拡大する
第1段階：AIアシスタント
SEの指示を受けて、
- コードを書く
- 文書を作る
- テストを作る
- 障害原因を調べる
現在すでに普及している形です。
第2段階：AIエージェント
SEが目標と条件を与えると、
までを連続して進めます。
第3段階：複数AIによる開発組織
将来的には、
- 設計AI
- 開発AI
- テストAI
- セキュリティ監査AI
- 運用AI
が役割を分担し、相互に検証する形になると考えられます。
この場合、SEは個々の作業者ではなく、**複数のAIを統括する「AIオーケストレーター」**になります。
SEに必要となる能力
今後のSEには、プログラミング能力だけでなく、次の能力が一層重要になります。
- 業務や社会課題を理解する力
- 要件を明確な条件へ変換する力
- システム全体を俯瞰する力
- AIの誤りを発見・検証する力
- セキュリティ、法制度、倫理の知識
- 複数のAIを適切に役割分担させる力
- 障害時に人間が介入できる仕組みを設計する力
最終的な役割分担
要するに、今後のシステムづくりでは、
- SE＝目的・構造・制約・責任を設計する
- AI＝設計された範囲内で高速に生成・検証・運用する
- SEとAI＝互いの弱点を補いながら改善を繰り返す
という関係になります。
したがって、SEの将来像は「AIに仕事を奪われる技術者」ではありません。
👉 AIに何を任せ、何を任せず、どこで止め、誰が責任を持つかを設計する技術者
へ進化していくと考えるのが適切です。
添付2-1）
NIST とは？
ChatGPT:
NIST（ニスト）とは、
👉 米国国立標準技術研究所（National Institute of Standards and Technology）
の略称です。
米国商務省に属する政府機関で、科学技術、情報システム、サイバーセキュリティ、AIなどの標準・指針を策定しています。
一文で総括
👉 NISTとは、企業や政府が安全で信頼できる技術を利用するための「技術標準と安全基準」を整備する米国の公的機関です。
主な役割
NISTは、次のような分野を扱っています。
- 測定単位・計測技術
- 情報セキュリティ
- 暗号技術
- クラウド・コンピューティング
- 半導体・製造技術
- AIの安全性・信頼性
- 量子技術
- 生体認証
NIST自身が企業を直接取り締まるのではなく、企業や行政機関が採用できる標準、評価方法、ガイドラインを提供します。
サイバーセキュリティ分野
代表的なものが「NIST Cybersecurity Framework（CSF）」です。
サイバー攻撃への対応を、主に次の6機能で整理しています。
- Govern：方針・責任を決める
- Identify：資産とリスクを把握する
- Protect：攻撃から保護する
- Detect：異常や侵入を検知する
- Respond：被害を封じ込める
- Recover：システムと業務を復旧する
つまり、
👉 攻撃を完全に防ぐだけでなく、侵入を発見し、被害を局所化して復旧するところまで設計する
という考え方です。
AI分野
AIについては「AI Risk Management Framework（AI RMF）」を策定しています。
主な目的は、AIの、
- 誤判断
- 偏見・差別
- 情報漏洩
- 説明不足
- セキュリティ上の欠陥
- 人間による統制の喪失
などを管理することです。
AIのリスク管理を、次の4機能で整理しています。
- Govern：統治・責任体制
- Map：利用目的と影響の把握
- Measure：安全性やリスクの測定
- Manage：リスクへの対応と継続改善
日本との関係
NISTは米国の機関ですが、その指針は日本企業でも広く参考にされています。
特に、
- 重要インフラ
- 金融機関
- 製造業
- クラウドシステム
- AIシステム
- 海外取引のある企業
の安全基準を検討するときに利用されます。
ただし、NISTの文書は原則として米国の法律そのものではありません。採用が義務になるかどうかは、米国政府との契約条件や業界規制などによって異なります。
要するに、
👉 NISTは、サイバー攻撃やAIのリスクに対して「何を、どの順序で、どの水準まで管理すべきか」を体系化する機関
です。
これまで検討してきたAI文明OSに当てはめれば、NISTは、AIや情報システムが暴走・停止・侵害されないための技術的・制度的な安全設計基準を提供する機関と位置づけられます。
添付３）
AIを活用したシステムづくりが、従来に比べて品質（Q:Quaity）、コスト（C:Cost）、納期(D:Delivery)がどの程度改善できると期待できるか？
ChatGPT:
結論から言うと、AIを適切に活用したシステム開発では、従来方式と比べて現実的には、
- 品質：不具合・手戻りを10〜30％削減
- コスト：開発費を10〜30％削減
- 納期：全体を20〜40％短縮
程度が、当面期待できる目安です。
ただし、これは保証値ではありません。AIはプログラミング単体では50％前後の高速化が可能でも、要件定義、顧客との調整、既存システムとの接続、承認などはそれほど短縮できないため、プロジェクト全体では改善幅が小さくなるからです。
一文で総括
👉 AIはコーディングを最大50％程度高速化できますが、システム開発全体の現実的な改善幅は、品質10〜30％、コスト10〜30％、納期20〜40％程度と見るのが妥当です。
品質・コスト・納期の改善目安
|
項目
|
現実的な改善目安
|
条件が整った場合
|
|
品質
|
不具合・手戻り10〜30％削減
|
30〜50％削減の可能性
|
|
コスト
|
10〜30％削減
|
30〜50％削減の可能性
|
|
納期
|
20〜40％短縮
|
定型開発では50％以上も可能
|
|
コーディング時間
|
30〜55％短縮
|
定型的な機能ではさらに短縮可能
|
|
テスト作成時間
|
30〜60％短縮
|
自動テスト基盤がある場合
|
|
文書作成時間
|
40〜70％短縮
|
書式・情報源が標準化されている場合
|
「条件が整った場合」とは、要件が明確で、開発標準、設計情報、テスト自動化、コード管理、AI出力の審査体制が整っている場合です。
�� 品質はどの程度改善するか
AIは次の作業で品質向上に貢献します。
- 要件の矛盾や漏れを洗い出す
- 複数の設計案を比較する
- コードを自動レビューする
- テストケースを大量に生成する
- 人間が見落としやすい例外条件を検出する
- 過去の障害と類似するパターンを探す
- 設計書とプログラムの不一致を検出する
GitHub（添付3-1参照）が経験5年以上の開発者を対象に行った比較実験では、AI支援を利用したコードは、信頼性が約2.9％、保守性が約2.5％、可読性が約3.6％向上し、すべての単体テストに合格する可能性も高まりました。ただし、これは限定されたプログラミング課題の実験であり、そのまま大規模システム全体へ当てはめることはできません。GitHubのコード品質調査
実務では、AIが生成したコードを別のAIとSEが検証することで、不具合や手戻りを10〜30％程度減らすことが現実的な目標になります。
一方、十分な検証なしにAI生成物を大量に採用すると、
- 誤ったコードの混入
- セキュリティ上の欠陥
- 同じ誤りの大量複製
- システム全体の整合性低下
- 保守対象コードの急増
が起こり、品質が悪化する可能性もあります。
Googleの2025年DORA（添付3-2参照）調査でも、AIは開発速度や生産性を高める一方、強力な自動テストや迅速なフィードバックがなければ、システムの安定性を悪化させる関係が残っていると報告されています。2025年DORA調査
したがって、
👉 AIを使うだけでは品質は上がらず、「生成AI＋テストAI＋監査AI＋SEの承認」によって品質が上がる
と考える必要があります。
�� コストはどの程度下がるか
最も削減しやすいのは、次のような反復作業です。
- 定型コードの作成
- 画面や帳票の作成
- テストデータの生成
- テストコードの作成
- 設計書・操作説明書の作成
- 既存プログラムの解析
- プログラム言語の変換
- 障害調査の初期分析
ただし、開発費のすべてがプログラミング費用ではありません。
例えば、開発全体のうちコーディングが30％で、その作業をAIが50％短縮しても、単純計算では全体への効果は、
です。
そのため、プログラミングが50％速くなっても、プロジェクト全体のコストが50％下がるわけではありません。
現実的には、
- 初期導入段階：5〜15％削減
- 標準化が進んだ段階：10〜30％削減
- AI前提で業務全体を再設計：30〜50％削減の可能性
という段階的な見方が適切です。
なお、短期的にはAI利用料、教育費、データ整備費、セキュリティ対策費が必要になるため、最初の案件ではコストが下がらない場合もあります。
�� 納期はどの程度短縮できるか
GitHubの比較実験では、AI支援を使った開発者が特定のプログラミング課題を約55％速く完了しました。ただし、これは限定されたコーディング作業の結果です。GitHubの生産性調査
システム開発全体には、
- 顧客との要件調整
- 社内承認
- 法令・セキュリティ審査
- 外部システムとの接続試験
- データ移行
- 利用者教育
など、AIだけでは短縮しにくい工程があります。
したがって、プロジェクト全体では、次の程度が目安になります。
- 大規模な基幹システム：10〜25％短縮
- 一般的な業務システム：20〜40％短縮
- 小規模なアプリ・試作品：40〜70％短縮
- 定型的な改修：30〜60％短縮
特に、試作品を早く作って利用者に見せ、意見を反映する反復型の開発では、AIの効果が大きくなります。
案件によって改善幅が異なる
|
システムの種類
|
AI効果
|
理由
|
|
小規模Webアプリ
|
大きい
|
定型コードが多い
|
|
社内業務システム
|
比較的大きい
|
画面、帳票、データ処理を自動化しやすい
|
|
既存システム改修
|
中程度
|
古い仕様の解析に時間がかかる
|
|
大規模基幹システム
|
限定的
|
調整、接続、移行、承認が多い
|
|
医療・金融・公共
|
限定的
|
高い検証・説明・法令適合が必要
|
|
新規性の高い研究開発
|
不安定
|
正解や過去事例が少ない
|
「3分の1の人員で作れる」とは限らない
AIによって生産性が30％上がったからといって、直ちに人員を30％削減するのは危険です。
削減された作業時間は、むしろ、
- 要件確認
- セキュリティ対策
- テスト拡充
- 利用者との対話
- 障害への備え
- システムの改善
へ振り向けるべきです。
これにより、単純な人件費削減以上に、失敗プロジェクトや運用障害による将来コストを減らす効果が期待できます。
最も現実的な目標設定
最初から「開発費を半減する」と設定するより、初年度は次のような目標が妥当です。
- 納期を20％短縮
- 開発工数を15％削減
- テスト件数を30％増加
- 本番障害を20％削減
- 設計書作成時間を40％短縮
- SEが判断・設計に使える時間を増やす
要するに、AI活用の本当の効果は、単に「安く、早く作る」ことではありません。
👉 定型作業をAIへ移し、SEが目的設計・全体統合・リスク管理に集中することで、品質を維持しながらコストと納期を同時に改善すること
にあります。
ただし、AIを無秩序に導入すると「コードは速く増えるが、検証と修正が追いつかない」という逆効果も起こります。したがって、AI活用の成否を決めるのはAIモデルの性能だけではなく、要件の明確さ、自動テスト、第三者検証、SEによる最終統制です。
添付3-1）
GitHub とは？
ChatGPT:
GitHub（ギットハブ）とは、
👉 プログラムのソースコードをインターネット上で保存・管理し、複数の人やAIが共同開発するためのサービス
です。現在はMicrosoft傘下の企業・サービスです。
一文で総括
👉 GitHubとは、プログラムの変更履歴を残しながら、開発者・SE・AIが共同でシステムを開発・検証・公開するための「ソフトウェア開発の共同作業基盤」です。
GitHubでできること
�� プログラムを保存する
システムやアプリを構成する、
- ソースコード
- 設定ファイル
- 設計資料
- テストコード
- 操作説明書
などをまとめて保存できます。
保存する単位を「リポジトリ（Repository）」と呼びます。簡単に言えば、一つの開発プロジェクトを収納する専用フォルダーです。
�� 変更履歴を管理する
プログラムを変更するたびに、
変更したかを記録できます。
問題が発生した場合は、以前の状態と比較したり、正常だった時点へ戻したりできます。
�� 複数人で共同開発する
複数の開発者が同じシステムを同時に開発できます。
それぞれが担当部分を作成し、完成後に他の人が内容を確認して、正式なプログラムへ統合します。
�� プログラムを審査する
開発者が作った変更を正式に取り込む前に、他の担当者へ確認を依頼できます。これを「プルリクエスト」と呼びます。
プルリクエストでは、
- 要件どおり動くか
- 不具合がないか
- セキュリティ上の問題がないか
- 他の機能に影響しないか
- 読みやすく保守しやすいか
を確認します。
�� テストと公開を自動化する
GitHub Actionsという機能を使うと、プログラムが変更された際に、
- 自動テストを実行する
- 脆弱性を検査する
- 合格したプログラムをクラウドへ配置する
- 本番システムを更新する
という流れを自動化できます。
�� 問題・作業を管理する
「Issue（イシュー）」という機能を使い、
などを記録・管理できます。
�� AIと共同開発する
GitHubには、GitHub CopilotというAI開発支援機能があります。
Copilotは、
- プログラムを生成する
- コードを説明する
- 不具合の原因を探す
- 修正案を提示する
- テストコードを作る
- プルリクエストを確認する
- 開発資料を作る
といった作業を支援します。
GitとGitHubの違い
よく混同されますが、両者は異なります。
|
用語
|
意味
|
|
Git
|
パソコン上でプログラムの変更履歴を管理する仕組み
|
|
GitHub
|
Gitで管理されたプログラムをインターネット上で保存・共有するサービス
|
簡単に言えば、
- Git＝変更履歴を管理する技術
- GitHub＝その技術を使った共同開発の場所
です。
クラウドとの違い
GitHubもインターネット上のサービスですが、一般的なクラウドとは主な役割が異なります。
|
サービス
|
主な役割
|
|
GitHub
|
ソースコード・変更履歴・開発作業を管理する
|
|
AWS・Azure・Google Cloud
|
完成したシステムを実際に動かす
|
|
GitHub Copilot
|
AIによって開発を支援する
|
例えば、
- GitHubでプログラムを作る
- GitHub上でテスト・審査する
- 合格したプログラムをAWSなどへ配置する
- AWS上で利用者にサービスを提供する
という関係です。
公開と非公開
GitHubのリポジトリには、大きく2種類あります。
- Public：世界中から閲覧できる
- Private：許可された人だけが閲覧できる
企業のシステムや機密情報を含むプログラムは、通常Privateで管理します。
ただし、非公開に設定するだけで安全が保証されるわけではありません。アクセス権限、多要素認証、秘密鍵の管理、操作記録なども必要です。
AIを活用したシステム開発での位置づけ
理想的な開発フローでは、GitHubは次のような「共通作業場所」になります。
GitHubには、
- AIが作った設計やコード
- テスト結果
- 修正履歴
- SEによる承認記録
が残ります。
したがって、GitHubは単なるプログラムの保管場所ではありません。
👉 人間とAIが共同でシステムを作り、変更内容を検証し、誰が承認したかを記録する「開発統治基盤」
と位置づけることができます。
添付3-2）
DORA とは？
ChatGPT:
DORA（ドーラ）とは、この文脈では、
👉 DevOps Research and Assessment（デブオプスの研究・評価）
の略称で、ソフトウェアをどれだけ速く、安全に、安定して提供できているかを研究・評価するGoogle Cloudの研究プログラムです。
一文で総括
👉 DORAとは、システム開発の速度と安定性を客観的な指標で測り、開発・運用方法を改善するための研究体系です。
DevOpsとは
DevOpsは、
- Development＝開発
- Operations＝運用
を組み合わせた言葉です。
従来は、プログラムを作る開発部門と、それを動かす運用部門が分かれていました。
DevOpsでは、両者が連携し、
- 小さな単位で開発する
- 自動テストを行う
- 素早く本番へ反映する
- 運用結果を監視する
- 問題を修正して再び反映する
という改善循環を回します。
DORAが測る5つの指標
現在のDORAは、ソフトウェア提供能力を次の5指標で評価しています。
|
指標
|
意味
|
|
変更のリードタイム
|
プログラム変更から本番反映までの時間
|
|
デプロイ頻度
|
本番システムを更新する頻度
|
|
障害からの回復時間
|
更新失敗から復旧するまでの時間
|
|
変更失敗率
|
本番更新のうち、障害や修正が必要になった割合
|
|
デプロイ手戻り率
|
本番障害への対応で予定外の再更新が必要になった割合
|
�� 変更のリードタイム
プログラムを変更してから、実際のシステムへ反映されるまでの時間です。
短いほど、利用者の要望や不具合に素早く対応できます。
�� デプロイ頻度
完成した変更を本番システムへ反映する頻度です。
大きな変更を年に数回まとめて投入するより、小さな変更を安全に頻繁に反映できる体制が望ましいとされます。
�� 障害からの回復時間
本番への変更によって問題が起きたとき、正常な状態へ戻すまでの時間です。
バックアップ、監視、自動切り戻し（添付3-2-1参照）などが整っていれば短縮できます。
�� 変更失敗率
本番システムへの変更のうち、
- 障害が発生した
- 緊急修正が必要になった
- 元の状態へ戻す必要が生じた
変更の割合です。
これは開発の品質・安定性を表します。
�� デプロイ手戻り率
障害対応や不具合修正など、予定外の事情によって行われた本番更新の割合です。
手戻りが多ければ、開発速度が速く見えても、実際には修正作業へ多くの時間を使っていることになります。
QCDとの関係
DORAは、前に取り上げたQCDと次のように関係します。
|
QCD
|
関係するDORA指標
|
|
Quality＝品質
|
変更失敗率、手戻り率
|
|
Cost＝コスト
|
手戻りや復旧にかかる工数
|
|
Delivery＝納期
|
リードタイム、デプロイ頻度、回復時間
|
ただし、DORAは開発費そのものを直接測る仕組みではありません。
👉 速さ・安定性・復旧力を測り、その結果として品質、コスト、納期を改善する
という位置づけです。
AI開発との関係
AIによってコードを大量・高速に作れるようになっても、DORAの指標が改善するとは限りません。
例えば、
- AIがコードを大量生成する
- SEの確認が追いつかない
- 大量の変更をまとめて本番へ投入する
- 障害や手戻りが増える
という事態も起こります。
そのため、AI導入の効果は、
- 作成したコードの量
- AIを利用した社員数
- AIへの質問回数
ではなく、
- 本番反映までの時間が短くなったか
- 障害が減ったか
- 復旧が速くなったか
- 手戻りが減ったか
で評価する必要があります。
DORAの研究でも、AIは開発組織の能力を自動的に改善するというより、既にある強みと弱点を増幅すると指摘されています。
GitHubとの関係
GitHubには、DORA指標を計測するためのデータが蓄積されます。
- プログラムを変更した時刻
- 審査を通過した時刻
- 本番へ反映した時刻
- テストの成否
- 緊急修正や切り戻しの記録
これらをクラウドの運用記録と組み合わせれば、AI導入前後のDORA指標を比較できます。
したがって、
- GitHub＝開発作業と履歴を管理する基盤
- DORA＝開発・運用能力を測る評価体系
という関係です。
注意点
DORA指標を単純な人事評価やノルマにすると、数字だけを良く見せる行動が起こる可能性があります。
例えば、デプロイ頻度だけを増やしても、不具合や手戻りが増えれば意味がありません。DORA自身も、一つの数値だけを目標にしたり、性質の異なるシステム同士を単純比較したりしないよう注意を促しています。DORA公式・ソフトウェア提供指標
もう一つのDORA
同じ略称で、EUの金融分野には、
Digital Operational Resilience Act
デジタル・オペレーショナル・レジリエンス法
という法律もあります。
こちらは金融機関のサイバーセキュリティやIT障害への対応力を定めるEU規則であり、Google CloudのDORA研究とは別物です。
今回のAIを活用したシステム開発の話では、
👉 Google Cloudが運営する「DevOps Research and Assessment」
を意味しています。DORA公式サイト
添付3-2-1）
切り戻し とは？
ChatGPT:
一文で総括
👉 「切り戻し（ロールバック）」とは、システムに問題が発生した際、新しく適用した変更を取り消して、正常に動作していた以前の状態へ戻すことです。
AIが社会インフラを制御する時代には、安全性を確保するための最も重要な機能の一つになります。
具体例��：ソフトウェア更新
例えば、
AIが電力制御システムを更新した結果、
が発生したとします。
この場合、
制御AIは
- 異常を検知
- 新しいプログラムを停止
- 更新前の正常なプログラムへ戻す
これが「切り戻し」です。
具体例��：AIエージェント
AIエージェントが、
物流ルートを自動変更した結果、
が起きた場合、
制御AIは、
「変更前の配送計画」に戻す
これも切り戻しです。
具体例��：都市OS
AI文明OSでは、
例えば、
交通AIが
を最適化した結果、
重大な混乱が起きた場合、
制御AIは
直前の正常な運行計画へ復元する
必要があります。
AI文明OSにおける役割
あなたが整理されている三権分立では、
- 判断AI（Plan）
- 監査AI（Check）
- 制御AI（Do）
- 人間の承認後に実行し、必要なら停止・切り戻しを行う。
つまり、
制御AIは、
「安全ブレーキ」
の役割を担います。
「停止」と「切り戻し」の違い
混同しやすいですが、意味は異なります。
- 停止
- システムの動作を止めるだけ。
- 問題は解決していない。
- 切り戻し
- システムを以前の正常な状態まで戻す。
- サービスを安全に継続できる状態へ復旧させる。
例えば、
スマートフォンのアプリ更新後に不具合が起きた場合、
- アプリを終了するのが「停止」
- 旧バージョンへ戻すのが「切り戻し」
という違いです。
AI時代で重要になる理由
従来は人間が不具合を確認して切り戻すことが一般的でした。
しかし、
AI文明OSでは、
などをAIがリアルタイムに制御するため、
異常を数秒以内に検知し、自動的に切り戻せる能力が社会の安全性を左右します。
そのため、制御AIには、
- 人間の承認に基づく実行
- 権限制御
- 異常時の停止
- 切り戻し（ロールバック）
- 復旧後の再実行管理
までを担わせることが重要になります。
総括
「切り戻し」とは、AIやシステムの変更によって問題が発生した際、安全に運用されていた以前の状態へ復元することです。AI文明OSでは、単に停止するだけでなく、迅速に正常な状態へ戻す機能が、社会インフラの安全性と継続性を支える重要な役割を果たします。
添付４）
このQCDは10年後、20年後にはどの程度改善されると見込まれるか？
ChatGPT:
結論から言うと、2026年の従来型開発を基準に、同じ機能・同じ安全水準のシステムを作ると仮定すれば、条件が整った場合の想定改善幅は次の程度です。
|
時点
|
品質
|
コスト
|
納期
|
|
2036年ごろ
|
不具合・手戻り30〜60％削減
|
30〜60％削減
|
40〜70％短縮
|
|
2046年ごろ
|
不具合・手戻り50〜80％削減
|
50〜80％削減
|
60〜90％短縮
|
ただし、これは確定的な予測ではありません。10年後、20年後のAI性能や制度、システムの複雑化を正確に予測することはできないため、技術進歩が順調に続き、AIを検証する仕組みも同時に発達した場合のシナリオです。
一文で総括
👉 2036年には「SEがAIを使って作る」段階から「複数AIが開発し、SEが統括する」段階へ、2046年には「AIが開発・試験・運用を循環させ、人間が目的と責任を統治する」段階へ進む可能性があります。
QCDの標準シナリオ
|
指標
|
2026年
|
2036年
|
2046年
|
|
要件整理
|
AIが支援
|
AIが矛盾・影響を常時検証
|
AIが業務変化から要件を継続更新
|
|
設計
|
人間中心
|
AIが複数案を生成・シミュレーション
|
AIが環境変化に応じて再設計
|
|
コーディング
|
AI支援
|
AIエージェント中心
|
コード自体を意識しない開発が拡大
|
|
テスト
|
人間＋自動化
|
複数AIによる自動検証
|
仮想環境で膨大な条件を常時検証
|
|
運用
|
人間中心の監視
|
AIによる予兆検知・自動修復
|
開発と運用が連続した自己改善型
|
|
SE
|
開発作業者＋設計者
|
AIオーケストレーター
|
システム統治・責任設計者
|
2036年ごろの姿
品質：不具合・手戻り30〜60％削減
2036年には、設計AI、開発AI、テストAI、セキュリティ監査AIが相互に検証する形が一般化すると考えられます。
例えば、開発AIがコードを作ると同時に、
- テストAIが例外条件を生成する
- セキュリティAIが脆弱性を調べる
- 監査AIが要件や法令との整合性を確認する
- 運用AIが本番環境への影響を予測する
という多重検証が可能になります。
その結果、単純なプログラムミスは大幅に減るでしょう。一方、
- 要件そのものが間違っている
- AIが同じ誤った前提を共有している
- 組織間の責任分担が曖昧
- 想定外の社会的影響が生じる
といった問題は残ります。
コスト：30〜60％削減
設計、実装、テスト、文書化、移行、保守の多くがAIエージェントによって自動化されるため、同じ仕様のシステムを作る費用は大きく低下すると考えられます。
ただし、削減された費用の一部は、
- AI利用料・計算資源
- データ整備
- サイバーセキュリティ
- AI監査
- 法令・認証への対応
へ移ります。
したがって、人件費が60％減っても、総開発費が同じだけ減るとは限りません。
納期：40〜70％短縮
現在1年かかる一般的なシステムが、同じ規模・要件なら4〜7か月程度で完成するイメージです。
ただし、行政手続き、経営判断、予算承認、利用者調整など、人間社会側の待ち時間はAIだけでは消えません。
2046年ごろの姿
品質：不具合・手戻り50〜80％削減
2046年には、完成後に不具合を探すのではなく、仮想空間にシステムと利用環境を再現し、開発中から膨大な条件をシミュレーションする方式が中心になる可能性があります。
さらに、運用中もAIが、
- 異常を検知する
- 原因を分析する
- 修正版を生成する
- 仮想環境で試験する
- 承認後に反映する
という循環を常時行うようになります。
単純な故障は極めて少なくなる一方、AI同士が連鎖的に誤判断する大規模なシステム障害は、むしろ重大な新リスクになります。
コスト：50〜80％削減
定型的な業務システムでは、自然言語で目的と条件を入力するだけで、設計から運用までをAIが構成する可能性があります。
現在1億円かかるシステムを、同一機能なら2,000万〜5,000万円程度で構築できるケースも考えられます。
ただし、実際には費用が下がった分、
- より多くの機能を搭載する
- 変更頻度を上げる
- 高度な安全対策を追加する
- 個別最適化を進める
ため、企業全体のIT予算が80％減るとは限りません。
👉 一つの機能を作る単価は下がっても、作るシステムの量と複雑さが増える可能性が高いからです。
納期：60〜90％短縮
現在1年かかる開発が、1〜5か月程度まで短縮される可能性があります。小規模で定型的なシステムなら、数週間、場合によっては数日で構築できるでしょう。
一方、大規模な基幹・金融・医療・防衛システムでは、人間による審査や社会的合意が必要なため、納期が10分の1になるとは限りません。
システムの種類による違い
|
システム
|
2036年の改善
|
2046年の改善
|
|
小規模アプリ
|
非常に大きい
|
ほぼ自動生成の可能性
|
|
一般業務システム
|
大きい
|
設計から運用まで高度に自動化
|
|
基幹システム
|
中程度
|
段階的な自動化
|
|
金融・医療
|
品質重視で納期効果は限定
|
AI監査の成熟次第
|
|
防衛・重要インフラ
|
人間の統制を強く残す
|
完全自動化は避ける可能性
|
|
AI自体を組み込むシステム
|
高速化するが不確実性も増える
|
高度な多重監査が不可欠
|
最大の制約はAI性能ではなくなる
将来的に開発速度を制約するものは、プログラミング能力から、次の問題へ移ります。
- 何を作るべきかという目的設定
- 部門・企業間の利害調整
- データを利用する権限
- 法令、倫理、社会的合意
- 最終責任を誰が負うか
- AIの判断をどこまで信用するか
- システムを止める権限を誰が持つか
2025年のDORA調査も、AIは単独で組織を改善するのではなく、既存の開発体制を増幅するとしています。自動テスト、迅速なフィードバック、明確な業務プロセスがある組織では効果が出ますが、基盤が弱ければ不安定性も拡大します。Google Cloud・2025年DORA調査
QCDから「QCDE」へ
将来は、品質・コスト・納期だけでは不十分です。新たに「E」を加える必要があります。
- Q：Quality＝品質
- C：Cost＝コスト
- D：Delivery＝納期
- E：Explainability／Ethics＝説明可能性・倫理性（添付4-1参照）
AIによってQCDが改善しても、
- なぜその設計を選んだのか説明できない
- 誰もシステム全体を理解できない
- 障害時に人間が介入できない
- 責任の所在が不明になる
のであれば、安全なシステムとはいえません。
最終的な見通し
要するに、
- 2036年：複数のAIエージェントが開発を担い、SEが統括する
- 2046年：AIが設計・開発・試験・運用・改善を一体的に循環させる
- 人間：目的、許容リスク、停止条件、最終責任を決める
という役割分担へ進む可能性があります。
したがって、20年後のシステムづくりでは、技術的な作業時間は現在の10〜40％程度まで圧縮される可能性がありますが、最後まで残るのは、
👉 「何を作るべきか」「どこまでAIに任せるか」「問題が起きたとき誰が責任を負うか」を決める人間の役割
だと考えられます。
添付4-1）
E：Explainability／Ethics＝説明可能性・倫理性 について
ChatGPT:
E：Explainability／Ethicsとは、
👉 AIが、なぜその設計・判断・処理を選んだのかを人間が説明でき、その結果が法令・倫理・社会的価値に反していないこと
を意味します。
ただし、「QCDE」は一般に確立された国際標準用語ではなく、AI時代のシステム評価に必要な観点として追加した整理です。
一文で総括
👉 Eとは、「正しく動くか」だけでなく、「なぜそう動くのかを説明でき、その動作を社会的に許容できるか」を評価する基準です。
�� Explainability＝説明可能性
説明可能性とは、AIやシステムの判断について、次のことを人間が確認・説明できる状態です。
- どのデータを使ったのか
- どの条件を重視したのか
- なぜその結論になったのか
- 他の選択肢をなぜ採用しなかったのか
- 誰がAIの提案を承認したのか
- どの時点で何が変更されたのか
- 誤りが発生した場合、原因を追跡できるか
システム開発における説明可能性
例えばAIがクラウド構成を作成した場合、単に、
この構成が最適です
と示すだけでは不十分です。
次のように説明できる必要があります。
個人情報を扱うため、データベースを外部から隔離しました。障害時の復旧時間を1時間以内にするため、別地域にも複製を配置しました。費用は最安案より20％高くなりますが、停止リスクを下げられます。
つまり、設計結果だけでなく、根拠、比較、利点、欠点、残るリスクを示すことが説明可能性です。
�� Ethics＝倫理性
倫理性とは、AIやシステムが技術的に実行可能であっても、
- 人を不当に差別しないか
- プライバシーを侵害しないか
- 人間の選択権を奪わないか
- 弱い立場の人に過度な負担を与えないか
- 人を欺いたり、操作したりしないか
- 社会に許容できない危険を与えないか
- 効率だけを優先して人間の尊厳を損なわないか
を確認することです。
具体例
AIが採用候補者を選ぶシステムでは、処理が高速で費用も安くても、過去の採用データに偏りがあれば、性別、年齢、出身などによって不当に評価する可能性があります。
この場合、
- Q：システムは仕様どおり正確に動いた
- C：採用費用を削減できた
- D：選考期間を短縮できた
としても、
- E：判断理由を説明できない
- E：特定の属性を不当に排除している
なら、適切なシステムとはいえません。
説明可能性と倫理性の違い
|
観点
|
問う内容
|
|
Explainability
|
なぜ、その判断になったのか
|
|
Ethics
|
その判断を行ってよいのか
|
|
Quality
|
仕様どおり正しく動いたか
|
|
Cost
|
費用は適切か
|
|
Delivery
|
必要な時期までに提供できたか
|
説明可能であっても、倫理的とは限りません。
例えば、
利益を最大化するため、高齢者には高い価格を提示した
と明確に説明できても、その扱いが公平かどうかは別問題です。
反対に、倫理的な目的で作られていても、判断理由を説明できなければ、誤りや差別を検証できません。
したがって、説明可能性と倫理性の両方が必要です。
AI開発にEが必要な理由
従来のシステムは、人間があらかじめ設定した規則に従って動くものが中心でした。
一方、AIは、
- 大量のデータから判断する
- 状況に応じて異なる回答を出す
- 自然言語からプログラムを生成する
- 人間が想定しなかった方法を選ぶ
- 複数のAIが連携して処理する
ため、結果だけを見ても判断過程が分かりにくくなります。
特にAIが設計・プログラミング・テストを一貫して行うと、人間が中身を十分理解しないまま本番へ反映する危険があります。
👉 AIが作ったものを人間が説明できなくなる「理解の空洞化」
を防ぐことが、Eの重要な目的です。
Eをどのように実装するか
説明可能性の仕組み
- 使用した要件・データを記録する
- AIへの指示を保存する
- 設計案と採用理由を残す
- 変更履歴をGitHubなどで管理する
- AIが作った部分を明示する
- テスト・監査結果を保存する
- 人間による承認記録を残す
- 障害時に判断経路を再現できるようにする
倫理性の仕組み
- 使用禁止データを定める
- 差別や偏りを検査する
- 個人情報を必要以上に収集しない
- AIだけで決定してはいけない事項を定める
- 異議申し立てと再審査の手段を用意する
- 重大な判断には人間の承認を必要とする
- 定期的に外部監査を行う
- 社会的影響を導入前後に評価する
システムの重要度によって必要水準が違う
|
システム
|
Eに求められる水準
|
|
娯楽・一般的な情報提供
|
比較的低い
|
|
商品推薦・広告
|
中程度
|
|
採用・人事評価
|
高い
|
|
融資・保険審査
|
高い
|
|
医療・福祉
|
非常に高い
|
|
行政・司法
|
非常に高い
|
|
防衛・重要インフラ
|
最高水準
|
人の生命、権利、財産、安全保障に影響するほど、説明、記録、人間の承認、異議申し立ての仕組みが重要になります。
AI文明OSとの関係
AI文明OSの三権分立に当てはめると、
- 判断AI：結論と根拠を提示する
- 監査AI：偏り、法令違反、倫理的問題を検査する
- 制御AI：承認された範囲だけ実行する
- 統合AI：各AIの意見と対立点を人間に説明する
- 人間：最終的な価値判断と責任を担う
という構造になります。
特に重要なのは、AIが「問題ありません」と自己評価するだけでは不十分なことです。開発AIとは独立した監査AIと人間が検証する必要があります。
QCDEの本質
要するに、QCDEは次の四つを同時に問う考え方です。
- Q：正しく作られたか
- C：適切な費用で作られたか
- D：必要な時期に作られたか
- E：説明でき、社会的に許容できるか
AI時代には、「速く、安く、高品質に作れた」だけでは成功とはいえません。
👉 人間が理解・監督・修正でき、社会に対して責任を説明できることまで含めて、初めて完成したシステムと評価する
というのが、Eを加える意味です。
