はじめに

AIエージェントやコーディングAIが当たり前になってくると、MBSE (モデルベースシステムズエンジニアリング)や、要求・設計・テストを管理する基盤はこの先どうなるのか、というのが気になっていました。

コードはAIがかなり書いてくれるようになりつつあります。一方で、安全が問われる領域では、要求、設計、テスト、トレーサビリティをどう扱うかは簡単には消えません。

このあたりをAIと壁打ちしながら整理していたら、それなりに自分の中で見通しがよくなったので共有します。かなり調査メモ寄りですが、同じようなことを考えている人の参考になればうれしいです。

3行まとめ

モデルベースシステムズエンジニアリングも、開発情報を一元管理する基盤も消えない。むしろ希少資源になる。 AIが大量にコードを書くほど、「何を作るべきか」を曖昧さなく機械可読な形で定義する層（要求・モデル・仕様）が新しいボトルネックになる。手作業中心の旧来型は縮小し、人の役割は再設計される。
開発情報を管理する基盤の役割が「記録するためのシステム」から「AIに文脈とルールを供給し、その動きを統制する基盤」へ移る。 2025年に関連する標準が出揃い、その土台ができた。
「AIコーディングへの投資」と「モデル・トレーサビリティへの投資」は二者択一でなく補完関係。 とくに安全が問われる産業（自動車・航空・医療）では後者の重みが増す。

このレポートでの「モデル」とは — システム工学でいう"設計図"の意味で使う。要求・構造・インターフェース・振る舞いを構造化して機械可読にしたものを指し、AIそのもの（AIモデル／LLM）とは別物。本文で「モデル生成」と言えば、この設計図を作ることを指す。

1. いまの開発と、その前提変化

安全が問われる領域（自動車・航空・医療）は今も V字モデル（左で要求→設計と下り、右でテスト→検証と上る開発プロセス）が主流。本質は、トレーサビリティ（要求→設計→コード→テストのつながりを追跡できること）が、監査・認証・機能安全の"根拠"になっている点。

ここで言う 「開発情報を管理する基盤」 とは、要求・設計・テスト・変更履歴と、それらのつながり（トレーサビリティ）を一元管理するツール群のこと。業界では ALM／ELM（アプリケーション／エンジニアリングのライフサイクル管理）と呼ばれる分野で、IBM・Siemens・PTC・Jama などが製品を出している。これが開発の「単一の真実の源」を支える。

自動車では SDV（ソフトウェア定義車両＝機能をソフトで決め、出荷後もOTA無線更新する車）が前提を変えた。1億行超のコードを10年規模で保守する世界になっている。

2. AIの関与レベルと現実度（2026）

要求：曖昧性の検出・品質スコアリングは実用化（高）
システム設計：自然言語からモデル（設計図）の"骨格"生成まで。全自動はまだ（中）
実装：タスクを丸ごと委譲するコーディングが主流化（高）
テスト：要求からのテスト自動生成・トレース維持（中〜高）
運用：自己修復・原因分析はあるがリスク高（中）

重要な留保：研究では、LLMはモデルの「骨格」は作れるが致命的な誤り・不整合のため全自動生成は非推奨。McKinsey も「ツールを配るだけでは効果は出ず、ワークフローの再設計が不可欠」とし、AIで大きな利益を出せた企業は調査対象の約5%にとどまる（基準は「EBIT＝利払い・税引き前利益、≒本業のもうけ、が5%超改善」）。「AIで設計・実装が全自動になる」式の不要論への明確な反証。

3. 2025年に出揃った3つの標準

接続の標準（MCP）：AIエージェントが外部ツール・データにつなぐ規格。Anthropic発で事実上の業界標準に。
エージェント間通信の標準（A2A）：エージェント同士の連携規格。Google発。
モデル相互運用の標準（SysML v2 API）：システムのモデル（設計図）をプログラムから読み書きでき、ツール間連携を標準化。

要点：AIは"頭の中の暗黙知"は使えず、明示化・構造化された知識しか使えない。 だから構造化された要求・関係・テストの層が、AI時代にこそ効いてくる。

4. 不要論 vs 強化論（評価：強化論が優勢）

論点	不要論	強化論
設計・実装	AIが自然言語から直接生成、モデル不要	AIほど構造化された制約・境界が要る
記述	自然言語で十分	機械可読なモデル（設計図）がAIへの入力になる
トレーサビリティ	コードが真実、不要	認証・監査の根拠で不可欠

残る：要求工学、システム境界・インターフェース定義、トレーサビリティ、機能安全の論証、アーキテクチャ判断。
縮小する：手作業のモデル描画、定型テストの手書き、低レベルなコーディング。
変化する：モデル（設計図）は「人が描く図」から「AIが生成し人が検証する機械可読資産」へ。価値は「人同士の伝達」から「AIへ正確な制約を供給する」方向へシフト。

5. 将来像

開発情報を管理する基盤：単なる記録システムから、**AIエージェントの"土台"（必要な文脈を渡し、動きを統制・記録し、後から監査・巻き戻しできるようにする基盤＝エージェント運用基盤）**へ進化する。理由は ①AIへの文脈供給、②ガバナンス（自律的に動くAIの責任分界・監査・ロールバック）、③AIが大量生成する成果物のトレース自動化、の3点。
複数システムの統合設計（SoSE＝System of Systems Engineering）：それぞれ独立に作られ・運用される複数システムを束ねて、ひとつの大きなシステムとして設計する分野（例：車どうし、車と道路インフラ、複数の自律システムが連携する全体）。AIエージェントが"部品"として大量参加するほど、境界・責任分界・想定外の創発的振る舞いの管理が中核課題になる。
デジタルスレッド（全工程のデータを1本の糸でつなぐ考え方）の中心が、コードから 意図（Intent＝なぜ作るのか／要求・制約） へ移る。コードはAIが大量生成する"派生物"になり、管理価値の中心は「なぜ作るか／意図通りか」へ。コードは「モデル（設計図）の一種」に近づく。ただし安全系では検証可能性が前提条件。

6. 2035年シナリオ

S1：AI実装主導でモデル・管理基盤が縮小 — 速度最優先だがトレース喪失・認証困難。非規制領域で先行。
S2：AI実装＋人がモデルを管理（拡大・進化） — 速度と統制を両立。最も蓋然性が高い。
S3：エージェント主体で管理基盤が運用基盤化 — 意図→実行を完全統合。標準成熟待ち。

評価：規制産業ではS2が2030年前後の主流、S3が2030年代後半の到達点。非規制のWeb系ではS1的な動きが先行（汎用コーディングAIは公開GitHubコミットの数%を既に生成との報告）。安全認証と責任分界の壁が、規制産業でモデル・管理基盤を存続・強化させる構造的要因。

7. ベンダーの動き

各社とも「要求アシスタント」「テスト生成」「標準連携」へ収斂しており、方向性は似てきている。差は基盤AIと統合範囲、得意領域。生産性の数値はどこも自己申告で第三者監査ではない点に注意。 統合スイート側（IBM・Siemens・PTC・Dassault・Jama など）と、実装側から攻める汎用コーディングAI（Claude Code・Codex・Cursor など）が、補完にも競合にもなる。特定ベンダーが勝つというより、「機械可読な仕様層 × ガバナンス × エージェント運用」を誰がうまく束ねるかの競争。

8. 提言（OEM／Tier1向け）

今すぐ（0–12ヶ月）

要求とアーキテクチャの機械可読化（AIが文脈として消費できる構造化形式へ）。
文脈基盤の整備（要求・モデル・コード・テストを束ねるナレッジグラフ／ベクトルDB）。
人間の検証ループの制度化（エージェントの自律度を工程・リスクごとに定義。安全工程は人間承認を構造的要件に）。

中期（1–3年） 4. AIコーディングを非安全系から段階導入（低リスクから機能横断へ）。5. 標準準拠のモデル移行。6. デジタルスレッドを「意図中心」に再設計。

優先順位：①トレース基盤 → ②機械可読化 → ③文脈基盤 → ④AIコーディング。AIコーディングの効果は上流の構造化品質に依存するため、基盤投資が先。

やり方の転換：「人が書く→AIがレビュー」から「AIが生成→人が検証・統制」へ。エンジニアは実装者から、仕様定義・アーキ判断・検証を担うオーケストレーターへ。

注意事項

各社の生産性数値は基本が自己申告で、横並びで割り引いて読むべき。
市場規模・シナリオは調査会社や前提で大きく変わる推論。
AI生成コードの脆弱性混入が複数研究で報告されており、安全クリティカル領域での無検証採用は現時点で不可。

出典（本文で引用した主な資料）

AIの効果と組織条件（2章）

McKinsey「Unlocking the value of AI in software development」(2025-11-03)：上位2割が生産性・品質で大きな改善、ただし「ツールを配るだけでは効果は出ない」 — https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/unlocking-the-value-of-ai-in-software-development
McKinsey「The state of AI in 2025: Agents, innovation, and transformation」(2025-11-05、回答1,993社)：EBITレベルで意味ある利益を出せた企業は少数（企業レベルでEBIT効果ありは39%、うち多くは5%未満） — https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai

「LLMはモデルの骨格まで」の根拠（2章）

Rafique ほか「Enhancing Model-Based Systems Engineering with Large Language Models」INCOSE International Symposium 2025（Wiley）：LLMは"骨格モデル"は作れるが、致命的な誤り・不整合のため全モデル生成をAIだけに委ねるのは非推奨 — https://incose.onlinelibrary.wiley.com/doi/10.1002/iis2.70067

2025年に出揃った3つの標準（3章）

MCP（接続の標準）：Anthropic「Introducing the Model Context Protocol」(2024-11) — https://www.anthropic.com/news/model-context-protocol ／ Linux Foundation傘下AAIFへの寄贈(2025-12) — https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation
A2A（エージェント間通信の標準）：Google「Announcing the Agent2Agent Protocol」(2025-04) — https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/ ／ Linux Foundationによるプロジェクト発足(2025-06) — https://www.linuxfoundation.org/press/linux-foundation-launches-the-agent2agent-protocol-project-to-enable-secure-intelligent-communication-between-ai-agents
SysML v2 API（モデル相互運用の標準）：OMG「Approves Final Adoption of the SysML V2 Specification」(2025-07-21) — https://www.omg.org/news/releases/pr2025/07-21-25.htm

背景（1章の参考）

McKinsey「The economic potential of generative AI」(2023-06)：ソフトウェア工学へのAIの直接効果を年間支出の20〜45%と推計 — https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/the-economic-potential-of-generative-ai-the-next-productivity-frontier

※ 6章の「汎用コーディングAIが公開GitHubコミットの数%を生成」は各種報道ベースの数値で、単一の確定的な一次ソースはなし。