情報感度の3段階分類
| Level | 情報の例 | 流出インパクト | 配置先 | AIコーディング支援 |
|---|---|---|---|---|
| Level 1 （低） |
業務改善スクリプト・テストコード・内部ツール | 低：汎用技術・固有性が低い | SaaS | 有効（制限なし） |
| Level 2 （中） |
BSW/CDD実装（ハンドコード） | HWとセットで価値提供。ノウハウが流出してもビジネスへの影響は限定的。 | SaaS + Content Exclusion（除外設定） | 有効（除外設定必須） |
| Level 3 （高） |
機能設計書、MBD（コアロジック、APP実装）、AUTOSAR Configuration、メカ設計、エレキ設計 | HWと独立してSWとして価値提供。流出するとビジネスへの影響大。専用ツールのバイナリ形式のためSaaSの利点も薄い。 | オンプレ / プライベートクラウド | 無効（直接参照させない。SaaSの主戦場外。） |
| Level 3 （最高） |
客先固有仕様・OEM規格 | 契約違反リスク | オンプレ / プライベートクラウド | 無効（直接参照させない） |
AUTOSAR補足：車載ECUのSW標準アーキテクチャ。
・APP層：車両制御アルゴリズム・機能実装（MBDで開発されることが多い）→ Level 3
・BSW（Basic Software）：OS・通信スタック・診断等の基盤SW（COTS製品が多い）→ Level 2
・CDD（Complex Device Driver）：BSWでカバーされないHW固有の制御ドライバ → Level 2
・RTE（Runtime Environment）：APP層とBSW層を繋ぐ通信ミドルウェア → Level 2〜3
車載SW開発では、コードだけでなく要求・試験・モデルなど多様な成果物がある。それぞれ「最も適した正本システム」が異なる。
| 成果物タイプ | 推奨配置先 | 方針 |
|---|---|---|
| ハンドコード（BSW/CDD実装・内部ツール等） | GitHub（GHEC） | 実装・差分・CI/CDの中心。Copilotの効果が最も出やすい |
| 実装近傍の設計メモ / ADR※1 | GitHub（GHEC） | コード近傍で保守することでAIが参照しやすくなる |
| テストコード / CIスクリプト | GitHub（GHEC） | 実装と一体運用 |
| Simulink / MBD モデル正本 | MBD基盤 / ALM参照 | .slxはバイナリ形式のため専用diff/merge必須。生成コード・補助スクリプトはGitHubで管理可 |
| 客先要求 / SW要件 / 試験仕様 | ALMツール（将来） | 正式要求・監査の正本。GitHubに置かないことを推奨（詳細は第4章） |
| 機能設計書・客先仕様（Level 3） | オンプレ / PLM | AIへの直接参照不可。要約のみ開示する設計が必要 |
| 周辺文書 / 業務ノウハウ | SharePoint / PLM | 原本維持。将来的に横断エージェントで参照可能にする |
※1 ADR（Architecture Decision Record）：設計判断の背景・選択肢・結論を記録した文書。なぜその設計を選んだかをコードと一緒に残すことで、後からAIが設計意図を参照できるようになる。
Copilotで今すぐ始められるのは、Level 1〜2の範囲。
次の章では、この分類を前提に「どう承認を取り、どう展開するか」の具体的なステップを示す。
Level分類に従うと、情報は必然的に複数の場所に分散する。
「分散したら、ナレッジが一元管理されないのでは？」 — これは正当な懸念だが、MCP（Model Context Protocol）を使うと、物理的に分散していても AIから見ると論理的に繋がった一つのナレッジ基盤 として見える設計が実現できる。
Anthropicが提案し、OpenAI・Google・Microsoftも支持する標準プロトコル。AIエージェントが外部のデータソース（リポジトリ・ドキュメント・DBなど）をツールとして呼び出すための共通仕様。2026年4月時点でFortune 500の数百社以上が本番稼働中（月間SDKダウンロード数9,700万回超）。GitHub公式のMCP Serverは2025年4月からパブリックプレビュー。
| 層 | 構成 |
|---|---|
| 物理層 （分散している） |
SaaS（GHEC）：BSW/CDD実装・テストコード・内部ツール オンプレ：機能設計書・客先仕様・APP実装 ALMツール（将来）：要求・試験仕様・トレース情報 |
| 接続層 （MCPで繋ぐ） |
各リポジトリにMCPサーバーを設置。AIエージェントがツール呼び出しで横断参照できる状態を作る |
| 論理層 （AIには一つに見える） |
AIエージェントの問い合わせに対して： ・SaaS側 → コード・PR・Issueを検索・参照 ・オンプレ側 → 設計書・仕様を参照（要約・属性・参照リンクのみ返す。本体は社内に残す） ・ALMツール側 → 要求ID・試験IDを参照（OSLC / REST APIで接続） |
重要：オンプレのLevel 3情報はMCPでも本体を外に出さない。
MCPサーバーはオンプレ側に設置し、AIが参照できるのは「要約・属性・参照リンク」のみ。機能設計書や客先仕様のファイル本体はSaaSに送出しない設計にする。これによりLevel 3情報のセキュリティを保ちながら、AIが「存在と概要」を把握できる状態を作れる。
MCPベースの論理一元管理は、物理構造を変えずに接続範囲だけを拡張できる。
| フェーズ | 接続範囲 | AIが参照できるもの |
|---|---|---|
| 今すぐ（フェーズ1） | GHECのみ | コード・PR・Issue・ADR |
| 中期（フェーズ2〜3） | GHEC + ALMツール（OSLC/REST API） | 上記 + 要求ID・試験ID・トレース情報 |
| 長期（最終形） | 上記 + オンプレ（MCPサーバー設置） | 上記 + 設計書・仕様の概要（本体は社内保持） |