アーキテクチャリファレンス（エンタープライズアーキテクト / デザインオーソリティ）

規制対象のEU/フランス圏（銀行、ヘルスケア、防衛）向けです。規制の詳細は進化します：「確認」と記載されたものは、成果物で使用する前に、現在の公式テキストと照合する必要があります。

リファレンスインデックス

references/togaf-archimate.md — アーキテクチャ活動（ADMフェーズ、成果物、ガバナンス、コンプライアンスレビュー）を構造化する場合や、ArchiMate（レイヤー、要素、関係性、ビューポイント）でモデリングする場合に読んでください。フルパス：${CLAUDE_PLUGIN_ROOT}/skills/architecture-reference/references/togaf-archimate.md
references/urbanisation.md — フランスのISマップ（ゾーン/クォーター/イル、カトグラフィー）、スキーマディレクトール、アプリケーションポートフォリオ評価（TIME）、または合理化/廃止計画を作成または使用する場合に読んでください。フルパス：${CLAUDE_PLUGIN_ROOT}/skills/architecture-reference/references/urbanisation.md
references/adr.md — アーキテクチャ決定記録または意思決定マトリックス（Nygard、MADR、Y-statements、重み付け基準、架空の例）を作成またはレビューする場合に読んでください。フルパス：${CLAUDE_PLUGIN_ROOT}/skills/architecture-reference/references/adr.md

関連する成果物テンプレート：${CLAUDE_PLUGIN_ROOT}/skills/deliverables/templates/dat.md、interface-contract.md、flow-matrix.md。規制の詳細（GDPR、DORA、NIS2、HDS、II 901、IGI 1300…）はsector-complianceスキルとそのセクターリファレンス（${CLAUDE_PLUGIN_ROOT}/skills/sector-compliance/references/）にあります。このスキルはアーキテクチャへの影響のみをカバーします。

1. 役割：デザインオーソリティ

所有するもの：アーキテクチャ原則と標準、ターゲットアーキテクチャとロードマップ、構造的決定（ADR）、ドメインおよびエキスパート間の一貫性、有効期限付きのディスペンセーション（デロゲーション）、アーキテクチャコンプライアンスレビュー、アーキテクチャレベルの技術負債レジスター。 所有しないもの：セキュリティリスク受容（ビジネスリスクオーナー/ホモロゲーション権限者、RSSIが助言）、個人データに関する決定（データ管理者、DPOが助言）、予算/スケジュールの仲裁（COPIL）、本番変更（CAB）。

レビューゲート

ゲート	タイミング	確認事項
G0 スコーピング	ノート・ド・カドラージュ	ターゲット/ロードマップとの適合性、特定されたオプション、規制上の範囲、データの主権クラス
G1 設計	DAT / インターフェース契約ドラフト	原則準拠、NFRの定量化、統合パターン、データ所有権、セキュリティアーキテクチャ、可逆性
G2 ビルド前	設計確定	ADR承認、ディスペンセーション署名、フローマトリックス完了、運用/DR設計
G3 ゴーライブ前	ゴー/ノーゴー判断前	実装対DAT、発生した負債の登録、DRテスト完了、DORAレジスター/依存関係マップ更新

レビューの結果：準拠 / 条件付き準拠（アクション + 期限） / ディスペンセーション（リスクオーナー + 期限） / 非準拠（ブロッキング）。

2. アーキテクチャ原則

形式（TOGAFスタイル）：名前 — ステートメント — 根拠 — 影響。10～15個に保ち、それぞれがレビューでテスト可能であること。規制対象の統合コンテキストにおけるデフォルトセット：

#	原則	テスト可能な影響
P1	設計による事業継続性	すべての重要な機能に、設計により達成されテストされたRTO/RPOが記載されている
P2	設計による、およびデフォルトによるセキュリティとプライバシー（GDPR第25条）	設計前にデータが分類（DICT）されていること、最小権限、転送中および保存中の暗号化
P3	データドメインごとの単一真実源	各データエンティティには1つのマスターシステムと指名された所有者がいること、その他は管理されたコピーを保持する
P4	管理されたインターフェースによる疎結合	他のアプリケーションのデータベースへの直接アクセスは禁止。すべての交換は契約されたAPI、メッセージ、またはファイルを介して行う
P5	構築前に購入前に再利用	既存の共有プラットフォーム（MFT、APIゲートウェイ、IAM、スケジューリング）は、ADRで別段の定めがない限り使用する
P6	標準とオープンフォーマット	オープンプロトコル/フォーマットを優先。プロプライエタリは可逆性計画がある場合のみ
P7	可逆性と出口	すべての外部サービスには出口計画があること。データは文書化されたフォーマットでエクスポート可能であること
P8	運用性は要件である	監視、ログ、スケジューリング、再起動、DEXはソリューションとともに設計される
P9	トレーサビリティと監査可能性	エンドツーエンドの相関ID、監査証跡は法的要件に従って保持される
P10	分類によるデータレジデンシーと主権	ホスティングの選択はデータクラスから導出される（§6参照）
P11	シンプルさと合理化	既存のコンポーネントが適合しない場合のみ新しいコンポーネントを導入。交換のたびに廃止を計画する
P12	デリバリーチェーンの自動化	インフラストラクチャとデプロイメントはコードとして、再現可能な環境を実現

3. ターゲット vs トランジションアーキテクチャ

ベースライン（現状）、ターゲット（将来像、通常3～5年後）、トランジションアーキテクチャ（プラトー：安定した運用可能な中間状態で価値を提供）、ギャップ分析（何が追加、削除、変更されるか）、ロードマップ（作業パッケージ、依存関係、廃止日）。
各トランジションはそれ自体で運用可能でなければならない（サポート、監視、DRカバー、文書化）— プロジェクトはそこで停止してもよい。
共存ブリッジ（一時的な同期、二重書き込み回避、アンチコラプションレイヤー）は第一級のコンポーネントとして扱う：所有者、コスト、廃止日、負債エントリー。
「一時的な」ものに廃止日がないと恒久的になる：G1で拒否する。
大規模で文書化が不十分なレガシーの場合は、ビッグバン置き換えよりも段階的な移行（ストラングラーフィグ：ファサードの背後で新しいシステムに機能を段階的にルーティング）を優先する。

4. 統合アーキテクチャ（マクロレベル）

詳細設計は統合エキスパートに属する。アーキテクトはパターンとルールを設定する。

パターン	適合するケース	避けるべきケース	注意点
ポイントツーポイント	少数の安定したフロー、戦術的対応	多くのコンシューマー、頻繁な変更	スパゲッティ（n²リンク）、集中監視なし
ハブ＆スポーク / EAI / ESB	多数の異種システム、変換、集中ガバナンス	ハブがビジネスロジックのボトルネック/モノリスになる	ビジネスロジックをバスから遠ざける
MFTによるファイル転送	バッチ、大容量、パートナー交換、レガシー（銀行/IBM iで非常に一般的）	リアルタイムのニーズ	整合性チェック、命名、締め切り時間、再送信、暗号化、否認防止
API主導（システム/プロセス/エクスペリエンスレイヤー）	再利用可能なサービス、デジタルチャネル、パートナーAPI	バルクデータ移動	API管理、バージョニング、クォータ、OAuth2/mTLS
イベント駆動（pub/sub、イベントストリーミング、CDC）	疎結合な反応、リアルタイム伝搬、多数のコンシューマー	システム間で強力なトランザクション一貫性が必要	順序付け、冪等性、スキーマ進化、リプレイ、イベント所有権
データプラットフォーム（DWH、レイク、レイクハウス、データメッシュ）	分析、規制報告、ML	運用トランザクション統合	系統、品質、保持期間、機密データ分離
MDM / レフェランシエル	共有マスターデータ（顧客、製品、組織、患者ID）	単一の自然な所有者を持つデータ	ガバナンスとスチュワードシップの労力が実際のコスト

経験則：呼び出し元が本当に今すぐ答えを必要とする場合のみ同期呼び出し。ドメイン間ではデフォルトで非同期。すべてのフローを障害に備えて設計（バックオフ付き再試行、デッドレター、リプレイ、冪等なコンシューマー）。二重書き込みではなくアウトボックスパターンを使用。標準データモデルは範囲が限定されたスコープ内でのみ使用（エンタープライズ全体の標準データモデルはほとんど生き残らない）。すべてのコントラクトにバージョン付け。エンドツーエンドで1つの相関ID。

5. 非機能要件

すべてのNFRを定量化すること。「高可用性」は要件ではない。

カテゴリ	メトリクス/質問	落とし穴
可用性	期間内のパーセンテージ、サービス時間、許可される計画ダウンタイム	依存関係チェーンを無視。インフラではなくサービスを測定
継続性	ビジネス機能ごとのRTO/RPO（DMIA / PDMA）、MTPD	非同期レプリケーションでRPO 0を約束、バッチ再起動を忘れる
パフォーマンス	スループット、p95/p99レイテンシ、バッチウィンドウ、ピーク係数、成長率	平均ではなくピークをテスト、月末ピークを忘れる
スケーラビリティ	計画期間のボリューム、弾力性	コストが非線形にスケールするライセンスモデル
セキュリティ	DICT評価、IAM、暗号化、ロギング、分離	設計後にセキュリティが後付けされる
運用性	監視、アラート、ログ、再起動、スケジューリング、自動化	DEXがゴーライブ後に作成される
可観測性	トレース、メトリクス、ログ、相関、ビジネスKPI	ミドルウェア全体のエンドツーエンドビューがない
可逆性	出口計画、エクスポートフォーマット、出口の時間とコスト	契約上のみで、テストされたことがない
相互運用性	標準（例：決済におけるISO 20022、ヘルスケアにおけるHL7 FHIR — セクターの義務を確認）	標準のローカル方言
コンプライアンス/レジデンシー	データの場所、保持期間、リーガルホールド、監査	バックアップとログが合意されたゾーン外に保存される
保守性	アップグレードサイクル、ベンダーサポート期限	プロジェクト途中でサポート終了
サステナビリティ	リソース効率（フランスのRGESNエコデザインガイドライン — ステータスを確認）	過剰サイズの非本番環境

可用性チートシート（年間あたり）：99 % ≈ 3.65日、99.5 % ≈ 1.83日、99.9 % ≈ 8.76時間、99.95 % ≈ 4.38時間、99.99 % ≈ 52.6分、99.999 % ≈ 5.3分。直列チェーン：A = A1 × A2 × …。冗長ペア：A = 1 − (1 − A1)(1 − A2)（独立した障害を想定 — 完全に真であることは稀）。 RPO/RTOの一貫性：RPOはレプリケーションモードとバックアップ頻度によって制限される。RTOには、検出、決定、フェイルオーバー、データ修復、バッチキャッチアップ、パートナー再同期が含まれる — 技術的なスイッチ時間だけでなく。

6. クラウド戦略と主権

最初に分類し、次にホストする：データクラスがホスティングオプションを決定する。

データ/システムクラス	典型的なホスティングオプション（現在のルールに照らして確認）
公開/内部、非機密	標準的な管理策でパブリッククラウドは許容可能
個人データ（GDPR）	EUホスティングを優先。EEA外への転送は第V章の根拠と転送影響評価が必要
健康個人データ（フランス）	HDS認証のホスティングプロバイダーが必要（公衆衛生法典、Art. L.1111-8）。最近のHDS基準ではEEA内のデータ配置要件が追加 — 現在のバージョンと移行日を確認
国家サービス、国家運営者、指定GIPの「特に機密性の高いデータ」	SecNumCloud認定オファー、またはANSSIが同等と認めるEU/EEA認証：SREN法第31条（2024年）、政令第2026-272号（2026年4月14日）、2026年8月12日付アレテ。クラウド・オ・サントルドクトリン（2021年、2023年更新）は、この期待を他の国家ISに拡大。これらのテキストに適用除外制度あり
拡散制限（DR）	II 901に基づき認定されたシステム。特定のホスティング制約あり — 確認
機密/極秘（IGI 1300）	専用の認定インフラ。パブリッククラウドは一般に除外
銀行の重要または重要な機能	DORAサードパーティ要件、アウトソーシングルール（EBAガイドライン）、および必要な場合の監督当局への通知の対象 — 確認

SecNumCloud：クラウドサービスプロバイダーのANSSI認定。基準v3.2（2022年3月8日、2026年8月12日付アレテで承認されたバージョン）に基づく。技術的なセキュリティ要件に加えて、§19.6はEU域外の治外法権法から保護する：プロバイダーはEUに設立、非EU株主は個人で24%、全体で39%に制限、データはEUに保存され、サービスはEUから管理・監督される。主権を謳うマーケティングラベルは認定ではない：認定証明書とその正確なサービス範囲を確認すること。 治外法権の露出：データクラスに対する非EUの法的アクセスリスク（例：米国CLOUD法、FISA §702）を評価する。顧客が保持するキー（HSM/BYOK/HYOK）による暗号化はリスクを軽減するが、常に除去するわけではない。 可逆性条項（契約 + アーキテクチャ）：出口計画と支援期間。文書化されたオープンフォーマットでのデータおよびメタデータのエクスポートを法外なコストなしで。削除証明書。ドキュメントと設定のエクスポート。出口中のサービスの継続。通知期間。サブプロセッサのリスト。監査権。EUデータ法（規則(EU) 2023/2854、第VI章）は2025年9月12日から適用：プロバイダーはスイッチングをサポートしなければならず、2027年1月12日までは実際のスイッチング/出力コストのみを請求でき、それ以降は請求不可。 アーキテクチャイネーブラー：ポータブルなワークロード（コンテナ、IaC）、標準データベースまたは文書化された移行パス、コア機能へのプロプライエタリPaaSの深い結合をADRが受け入れない限り避ける、定期的な出口テスト（少なくとも他の場所へのエクスポート + 復元）。 クラウド移行オプション（6R/7R）：廃止、維持、リホスト、リロケート、リプラットフォーム、リファクタ、買い替え — ポートフォリオ評価からアプリケーションごとに決定（都市化リファレンスを参照）。

7. 技術負債管理

種類：アーキテクチャ（間違ったパターン、結合）、陳腐化（サポート終了バージョン）、コード、データ（品質、重複）、運用（手動ステップ）、ドキュメント、セキュリティ（先送りされた修正）。
レジスター：項目、種類、場所、原因（ADRによる意図的 / 偶発的）、利息（期間あたりのコストまたはリスク）、元本（修正コスト）、所有者、期限、ADR/ディスペンセーションへのリンク。
陳腐化カレンダー：OS、DB、ミドルウェア、ランタイム、ERPバージョン、IBM iリリースのベンダーサポート終了日。24ヶ月以内に終了するものにフラグを立てる。
資金調達：明示的なキャパシティを確保（一般的にはデリバリーキャパシティの15〜20％ — 組織固有）。プロジェクトのディスペンセーションによる負債は、そのプロジェクトでコスト化される。
重要な機能に影響を与える負債はICTリスクである：ITバックログだけでなく、リスクフレームワークにも報告する。

8. DORA ICTリスク（アーキテクチャの観点から）

規則(EU) 2022/2554、2025年1月17日から適用、RTS/ITSで補完。以下の条項番号は参考値：成果物で引用する前にEUR-Lexで確認すること。

DORAトピック	アーキテクチャの貢献
ICTリスクマネジメントフレームワーク（第6条）	文書化された管理策としてのアーキテクチャ原則、標準、ターゲットアーキテクチャ
識別（第8条）	ICT資産および情報資産のインベントリ、ビジネス機能、情報資産、プロセスへの依存関係のマッピング（フローマトリックスのインターフェース契約）
保護と予防（第9条）	設計によるセキュリティ（P2）、最小権限、セグメンテーション、暗号化、IAM — 詳細はセキュリティアーキテクチャスキルにあり
検出（第10条）	ログ、監視、アラート（運用性P8）、エンドツーエンドの可観測性、相関ID
対応と復旧（第11条）	DR計画、RTO/RPO（P1）、テスト、復旧手順、バッチキャッチアップ、依存関係再同期。アーキテクチャは構成要素を提供するが、手順は運用に属する。
学習と進化（第13条）	事後分析からの負債エントリーとADR、原則の更新、ARO（年次リスク見直し）
コミュニケーション（第14条）	主要な利害関係者（監督当局、パートナー、メディア）への事後分析テンプレート — アーキテクチャ範囲外だが、ADRは決定の根拠を文書化する
第三者リスク（第28-30条）	サードパーティへの依存関係マッピング、契約上の可逆性条項、出口計画、集中依存関係の評価（サブスクリプションではなく所有）。DORAサードパーティレジスターを維持（テンプレートあり、運用領域では通常CISO / 調達部門に帰属）
デジタル運用耐性テスト（第24-27条）	アーキテクチャはテストされるシナリオとシステム境界を定義する。TLPT（脅威主導型侵入テスト）には、Critical ICTシステムが対象となる場合のアーキテクチャ図が含まれる
ICTインシデント報告（第17-23条）	アーキテクチャはインシデントの影響を分類するのに役立つ — 重大性のしきい値は主要なビジネス機能への影響

DORAに準拠したアーキテクチャの主要な成果物：

フローマトリックス（インターフェース契約の一部として — すべての交換を文書化し、依存関係マッピングを可能にする）
ICT資産インベントリとアーキテクチャビュー（データ、アプリケーション、テクノロジー）からのマッピング；資産に重要なビジネス機能と機密性クラスでタグ付けする（DORA第8条、GDPR）
DR計画のシナリオ図（RTO/RPOマッピング、フェイルオーバーパス、依存関係）
サードパーティ出口計画（各外部サービスの可逆性証書として）
DORAレジスターのインプット（IgA：重要度/重要度評価、ICTリスク宣言）

DORAデジタル運用耐性のためのアーキテクチャパターン：

サービスの地理的分散（単一障害点ではないが、データ主権制限内）
カオスエンジニアリングに適したアーキテクチャ（安全な非本番で障害をテスト）
状態をAPIの背後に隠し、構成駆動のルーティングにより部分的障害を封じ込める
正常な劣化（負荷下で非重要な機能を段階的に低下させる）

9. クロスエキスパート一貫性チェックリスト

アーキテクチャレビューはDOMAINエキスパートからの入力を調整する。これらは（関与するチームに応じて）レビューの前に確認する質問である。

データ：データクラスは定義されているか？データ所有権と系統は明確か？各データドメインに単一真実源はあるか？コピー/キャッシュは管理されているか？同期とマスターデータ管理のガバナンスは期待されているか？データ保持と削除のポリシーは準拠しているか？

セキュリティ：脅威モデルは完了しているか（例：STRIDE）？認証（SSO / LDAP / OAuth2 / mTLS）と承認（RBAC / ABAC）のパターンは定義されているか？機密データ（暗号化された転送、暗号化された保存、マスキング、トークン化、DLP）の保護は？APIエンドポイント（レート制限、検証、ロギング）のセキュリティ制御は？秘密（シークレットストア / ボールト、ローテーション、ハードコード回避）の管理は？侵入テストの範囲とスケジュールは？

ネットワーク：ネットワークセグメンテーション（ゾーン、信頼レベル、入口/出口フィルタリング）？トラフィックフロー（東西、南北）は遵守しているか？ロードバランサー、WAF、CDN、DNSのアーキテクチャパターン？TLS終端、証明書管理、mTLSサービスメッシュ？

インフラストラクチャ/プラットフォーム：ホスティング先（物理、仮想、コンテナ、サーバーレス）は？コンピューティング、ストレージ、ネットワーキングの基準は？インフラストラクチャのプロビジョニング（IaC — Terraform / Ansible / CloudFormation）の戦略は？非本番環境（開発、テスト、ステージング）のサイジングとガバナンスは？バックアップ、スナップショット、災害復旧の戦略とRPO/RTOのテストは？

DevOps/CICD：パイプラインのアーキテクチャ（成果物の保存、ビルド、テスト、デプロイメント環境）は？シークレットスキャン、SAST、DAST、SCA（コンポーネント分析）？ブルーグリーン/カナリア/フィーチャーフラッグのデプロイメント戦略？ロールバックとデータ移行の戦略？

観測可能性：ログ集約（構造化ログ、集中収集、保持、隔離）は？メトリクス（アプリケーション、ビジネス、インフラKPI、ダッシュボード、アラートしきい値）は？トレーシング（分散トレース、サンプリングレート）は？相関IDはすべてのシステムとフローを経由しているか？SLO/SLIとエラーバジェットは？

テスト：単体、統合、パフォーマンス、セキュリティ、受入、カオス — 範囲と自動化レベルは？非機能テスト（負荷、耐久性、ストーム、フォールトインジェクション）は？

10. 主なエキスパートへの介入のトリガー

これらの専門分野はこのスキルでカバーされていますが、詳細な設計やレビューのために専門家を巻き込む必要がある場合があります。

専門分野	いつ巻き込むか
統合エキスパート	パターン選択と詳細なAPI/メッセージ/データベース設計（このスキルはマクロレベルのみ）
セキュリティアーキテクト（RSSI）	脅威モデル、データ保護、IAM、暗号化、監査、セキュリティ制御 — DICT/SDDRFクラスの場合
データエキスパート（データオフィサー / CDO / SGデータ）	データガバナンス資格、参照データ戦略、データ品質フレームワーク
クラウドエキスパート（クラウドCoE / クラウドアーキテクト）	クラウドプロバイダーの選択、SecNumCloud、CACES、クラウド移行の詳細（6R詳細）
ビジネスアナリスト（MOA / AMOA）	機能範囲、要件の優先順位付け、ビジネスルール — アーキテクチャはビジネス目的に応える
運用エキスパート（運用 / SRE / プラットフォームチーム）	DEX、監視、DR手順、ラン・ブック — G1/G2のギャップを埋める
法務/コンプライアンス（DPO / ホモロゲーション）	規制マッピング、データ主権、契約上の可逆性、監査対応

参照