本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「エンタープライズアーキテクチャ」カテゴリ第1弾として、エンタープライズアーキテクチャの全体像について解説する記事です。
EA は企業全体の戦略視点を扱うため、個別プロジェクト視点の他カテゴリと対象読者が明確に違います。本章は「全社の地図を描く人」向け（CIO・CDO・経営企画・IT戦略部門・EAチーム）。中小プロジェクト中心の読者は次章「ソリューションアーキテクチャ」の方が日常業務に近いはずです。本記事ではBA/DA/AA/TAの4層、AS-IS/TO-BE、TOGAF、企業規模別の粒度まで俯瞰します。
このカテゴリの全記事一覧・各記事で学べるポイントは以下のページにまとめています。
本記事のテーマについてさらに詳しく知りたい方は『エンタープライズ・アーキテクチャの基本と仕組み』も参考にしてみてください。
そもそもエンタープライズアーキテクチャとは何か
都市計画を想像してください。個々の建物がどんなに立派でも、道路・上下水道・電力網が整備されていなければ都市は機能しません。各地区がバラバラに開発された結果、隣町と道路がつながらない・水道管が重複する・電力が足りないといった問題が起きます。
エンタープライズアーキテクチャ（EA）は企業全体のIT戦略を都市計画のように統合的に設計する領域です。個別プロジェクトの設計を超えて、会社全体でビジネスとITの整合を取ります。
もしEAがなければ、部署ごとに似たシステムを別々に作り、データが分断されて全社分析ができない状態に陥ります。個別最適の積み重ねが全体最悪を生むのです。
個別最適の足し算は、全体最悪にしかならない
EAは、企業全体のIT戦略を統合的に設計するアーキテクチャです。個別のシステムアーキテクチャを超えて、会社全体でビジネスと IT の整合を取ることが目的で、ビジネス（BA）・データ（DA）・アプリケーション（AA）・テクノロジー（TA）の4層で全体像を整理します。頭文字をとって EA と呼ばれます。
大企業で「部署ごとに似たシステムを別々に作っている」「データが分断されていて全社分析ができない」といった問題を解決するために生まれた領域で、CIO・経営企画・IT 戦略部門が中心となって扱います。個別プロジェクトのアーキテクトよりも上位の視点を求められます。
EA は「企業の地図」地図があれば個別プロジェクトが迷わなくなります。
なぜ独立したアーキテクチャとして扱うか
企業全体の整合が取れていないと重複投資が発生
部署ごとに別々の顧客管理システムを作る、似たデータを別々の DB に持つ等、EA がないと同じものを何度も作ることになります。
全社DX推進の土台
DX（デジタルトランスフォーメーション）は個別アプリ開発ではなく、業務・データ・システムを全社で再設計する取り組みです。EA の視点がないと進められません。
既存資産（レガシー）の整理が必須
大企業は数十年積み上げたシステム資産を持ちます。何を残し・何を捨て・何を作り直すかを経営判断に繋げるのが EA の仕事です。
EAの4層モデル
EA は企業を4つの層で捉えます。上から下へ降りるほど具体的・技術的になり、上位の決定が下位を規定します。
| 層 | 扱うもの | 決める主体 |
|---|---|---|
| BA（ビジネスアーキテクチャ） | 業務プロセス・組織・ケイパビリティ | 経営・業務部門 |
| DA（データアーキテクチャ） | 全社データの定義・流れ・管理 | CDO・データ部門 |
| AA（アプリケーションアーキテクチャ） | システム群・連携・ポートフォリオ | CIO・IT部門 |
| TA（テクノロジーアーキテクチャ） | インフラ・クラウド・標準技術 | インフラ部門 |
BA が変わると DA が変わる、DA が変わると AA が変わる…という上下の繋がりが EA 設計の本質です。
AS-ISとTO-BE
EA の基本動作は AS-IS（現状）と TO-BE（あるべき姿）を描き、差分（ギャップ）を埋める計画を立てることです。これを4層それぞれで行います。
例えばある企業が「顧客データを全社で一元化したい」と考えた場合は、以下のような AS-IS／TO-BE が描かれます。
- BA AS-IS：部署ごとに独立した顧客管理業務
- BA TO-BE：全社共通の顧客管理プロセス
- DA AS-IS：各部署の DB に顧客情報がバラバラ
- DA TO-BE：全社共通の顧客マスタ
- AA AS-IS：5つの独立した顧客管理システム
- AA TO-BE：統一された顧客基盤 + 各業務システム
この差分を埋める中期計画（3〜5年）を立て、個別プロジェクトに落とすのが EA の典型的な動き方です。
代表的なEAフレームワーク
EA は先人が整理したフレームワークをベースに進めるのが一般的です。完全に独自で進めるのは難易度が高く、既存フレームワークの考え方を借りるのが定石です。
| FW | 特徴 | 向くケース |
|---|---|---|
| TOGAF | 最も普及・業界標準 | 大企業・国際展開 |
| Zachman | 6×6マトリクスで整理 | 学術的・教育目的 |
| FEA | 米政府向け | 公共セクター |
| DoDAF | 米国防向け | 防衛・大規模組織 |
日本で EA を語るなら実質 TOGAF 一択で、資格（TOGAF 認定）も普及しています。
決めるべきこと①：BA／DA
| 項目 | 選択肢の例 |
|---|---|
| 業務ケイパビリティマップ | 5層・7層の階層構造 |
| 業務プロセス記法 | BPMN・UML・独自 |
| データガバナンス体制 | CDO設置・データスチュワード |
| マスタデータ管理 | 集中MDM・分散MDM |
| データカタログ | DataHub・Collibra・内製 |
| データ品質基準 | 完全性・一貫性・鮮度・正確性 |
決めるべきこと②：AA／TA
| 項目 | 選択肢の例 |
|---|---|
| システム標準 | 共通認証・共通通知・共通ID |
| 連携パターン | API・イベント駆動・ファイル連携 |
| アプリポートフォリオ | Buy・Build・Subscribe の判断基準 |
| クラウド方針 | Cloud First／Hybrid／On-prem |
| 技術標準（TRM＝Technical Reference Model） | 承認技術リスト |
| リファレンスアーキテクチャ | 典型構成の設計図 |
企業規模別のEA粒度
「EAは大企業だけのもの」という誤解が根強くありますが、規模に合わせたEAの粒度があると考えるのが正しい捉え方です。中小企業でも部署間のサイロ化や重複投資は日常的に発生しており、軽量版の EA で十分に投資対効果が出ます。
| 企業規模 | EAの粒度 | 想定工数 |
|---|---|---|
| スタートアップ（〜50人） | BA のケイパビリティマップだけ | 経営層が1週間 |
| 中小企業（50〜300人） | BA + DA（顧客マスタ統一） | 経営＋IT で1か月 |
| 中堅（300〜1000人） | BA + DA + AA ポートフォリオ | 専任1名 半年 |
| 大企業（1000人〜） | 4層すべて + TOGAF 準拠 | 専任チーム 1〜3年 |
規模が小さくても、BA + DAの2層だけで十分価値が出ます。完璧を目指して着手しないのが最悪の選択です。
ソリューションアーキテクチャとの違い
EA とよく混同されるのがソリューションアーキテクチャ（次章で扱う）です。両者は視点のスコープが違います。
| 項目 | エンタープライズアーキテクチャ | ソリューションアーキテクチャ |
|---|---|---|
| スコープ | 企業全体 | 個別プロジェクト |
| 期間 | 3〜5年の中期 | 半年〜数年 |
| 視点 | ビジネス戦略＋IT | 個別課題の解決 |
| 成果物 | 全社ロードマップ・標準 | システム設計書 |
| 関係者 | CIO・経営 | プロジェクトチーム |
EA が描いた全社方針の中で、個別プロジェクトをソリューションアーキテクトが設計する関係です。
EA成熟度の段階表
※ 2026年4月時点の業界相場値です。テクノロジー・人材市場の変化で陳腐化するため、定期的にアップデートが必要です。
EA は段階的に育てるのが定石です。いきなりフル構築は失敗します。
| フェーズ | 期間目安 | 成果物 | 投資人員 |
|---|---|---|---|
| ①着手 | 3〜6か月 | BA ケイパビリティマップ2階層 + 主要業務 BPMN | 経営 + IT 1〜2名 |
| ②基礎 | 6〜12か月 | + DA（顧客マスタ統一計画）+ AA 棚卸し | EA 兼任 2〜3名 |
| ③中規模 | 1〜2年 | + TA 標準スタック + Technology Radar | 専任 EA 3〜5名 |
| ④エンタープライズ | 2〜5年 | TOGAF フル + 業界特化（BIAN等）+ CDO 配置 | 専門組織 10人〜 |
| ⑤継続運用 | 継続的 | EA as Code + 四半期レビュー + AI 活用 | 中央 + 事業部 EA |
「Phase A〜H完全適用」で1年半 Phase B 停滞が典型失敗。Phase A-B-DにTailoring（絞る）が現実解で、「絵画展で終わらせない」には中期計画とロードマップへの接続が不可欠です。
EA は地図を描くのが目的ではなく、意思決定を速くするために存在します。
このカテゴリの知識構造
このカテゴリは全6記事で構成されています。全体像→4層の各論→フレームワークという順序で読み進める構造です。
4層の各論はBA → DA → AA → TAの上から順に読むのが鉄則です。BA（ビジネス）の変化がDA（データ）を変え、DAの変化がAA（アプリ）を変え、AAの変化がTA（テクノロジー）を変える──この上下の連鎖がEAの本質です。
フレームワーク記事（TOGAF・ArchiMate）は、4層の内容を理解してから読む方が実感を持てます。先にフレームワークの手順だけ覚えても、中身の4層が分かっていなければ手順書の丸暗記に終わります。
EA全体の鬼門
各論記事で触れた禁じ手のうち、EAレベルで押さえるべき核心を1枚に。
| 禁じ手 | なぜダメか |
|---|---|
| TOGAF ADM を完全適用（Phase A〜H全て） | 1年半 Phase B 停滞、大手 SIer の典型失敗 |
| BA／DA／AA／TA を並行着手せず4層同時に完璧を目指す | 着手不能、段階的に育てる |
| 顧客マスタを部門別に放置 | 「15種類の顧客マスタ」問題、DX が数年止まる |
| みずほ銀行型統合（3行システムをエンタープライズアーキテクチャなしに統合） | 1年で11回の障害、金融庁業務改善命令 |
| ArchiMate を描くだけで意思決定に使わない | 絵画展で終わる、成果物作成が目的化 |
| PowerPoint EAで運用 | AI 読解不能、機械可読形式へ |
| 中央EAが象牙の塔化 | 現場と乖離、アジャイル EA で現場と協働 |
| DA を後回しで AI 活用を語る | AI の精度上限はデータ整理度合いで決まる |
| TAでマルチクラウドを運用体制なし採用 | 運用3倍コスト2倍、シングル基調で |
| フレームワーク原理主義 | Tailor せず手順書扱い、死ぬほど疲弊する |
| 「EAは大企業だけのもの」と思い込む | 中小企業でもサイロ化・重複投資は発生、規模に合わせた4層で全社の地図を描く価値は同じ |
| AS-IS/TO-BEを描いて終わり | 中期計画（3〜5年）と個別プロジェクトに落とさないと絵画展、ロードマップへの接続が本番 |
| BA層を「ビジネス部門の仕事ではない」と切り離す | BA は業務プロセスと組織を扱う、IT 部門だけで完結せず経営・業務部門との共同作業が必須 |
| 独自フレームワークでゼロから進める | 成果物の粒度・品質がバラつき経営への説明が困難、TOGAF をベースにするのが合理的 |
EA は「企業の地図」であって聖典ではない。Tailor して現場で使われる形にします。
筆者メモ — 「顧客マスタが15種類」で全社DXが数年止まった事例
EA 不在の組織がどれほど重い負債を抱えるかを示す事例は、大手企業を中心に数多く語り継がれています。
日本の大手企業で「顧客データを全社統合したい」という DX 案件が立ち上がり、各部署の基幹システムを掘っていくと、社内に「顧客マスタ」と呼ばれるテーブルが15種類存在していた、という話は決して珍しくありません。同じ法人が違う顧客コードで10回登録され、どれが正かは担当者の経験則でしか分からない──。統合プロジェクトは「まずどれが真実か」の合意形成だけで1年、MDM 導入で2年、計3〜5年止まる、という事例が繰り返し報告されてきました。個別プロジェクトのアーキテクトが何人いても、この状態は直りません。
もう一つ、みずほ銀行システム障害（2021〜2022年、1年で11回の障害を記録）は、EA 不在・システム統合の失敗が経営責任問題にまで発展した象徴事例です。旧第一勧銀・旧富士銀・旧日本興業銀行という3行のシステムを十分な EA 設計なしに統合しようとした結果、20年近くにわたってシステム統合に苦しみ続け、最終的に金融庁から業務改善命令を受けるに至りました。企業の地図を後回しにした代償は数千億円単位になりうることを、日本の金融史に刻んだ事件です。
どちらも「企業全体を俯瞰する人がいなかった」という構造的な欠陥が致命傷で、EAは絵画ではなく経営の基盤であることを突きつけます。
どう選べばいいのか
EA の核心は企業全体でビジネスとITの整合を取るという発想です。部署ごとに似たシステムを別々に作る、似たデータを別々の DB に持つ、といった重複投資やサイロ化は、個別プロジェクトのアーキテクトでは解決できません。BA・DA・AA・TA の4層で企業の現在地（AS-IS）と目指す姿（TO-BE）を可視化し、差分を埋める3〜5年の中期計画に落とす──これが EA の本業です。フレームワークは実質 TOGAF 一択で、完全独自ではなく先人の整理をベースに進めるのが合理的な判断です。
もう一つの決定的な軸はAI時代の競争力はEAの成熟度で決まるという認識です。AI エージェントが業務システムを横断して使う時代、データカタログ・MDM・API ベース疎結合・IaC 運用が揃った企業は AI を全社で活かせます。逆にサイロ化・モノリス・手作業運用の企業は AI 活用が部分最適で止まります。DA 層の再設計は、今や AI 戦略の中核です。
AI時代の判断軸
AI 駆動開発（バイブコーディング）と全社 AI 活用が前提になると、EA はAIを全社でどう活かすかの戦略策定の中心になります。AI はデータ品質とアクセス可能性で精度が決まるため、EA の DA 層（データアーキテクチャ）が再評価されています。
| AI時代に有利 | AI時代に不利 |
|---|---|
| 全社データカタログ・統合DWH | 部署ごとのサイロ化データ |
| マスタデータ管理（MDM）が整備 | 顧客IDが各システムでバラバラ |
| APIベース・疎結合なシステム群 | モノリスで密結合・連携困難 |
| IaC・自動化前提の運用 | 手作業・申請ベースの運用 |
AI エージェントが業務システムを横断して使う時代には、EA レベルでの標準化（認証・API・データ定義）が必須になります。EA 不在だと AI 活用が部分最適で止まります。
AI 時代の競争力は、EAの成熟度で決まります。
選定の優先順位
- 4層を上から順に設計する — BA 変化 → DA 変化 → AA 変化の連鎖、下から積むと迷う
- TOGAFをベースに進める — 独自フレームワークは難度高、資格も整備済み
- AS-ISとTO-BEの差分を中期計画化 — 全社ロードマップに落として個別PJと接続
- DA層を最優先で整える — AI時代の競争力の土台、カタログ・MDM・品質を先に
EA成熟度がAI活用の上限を決める構造
AIエージェントが社内システムを横断利用する時代には、EAの標準化レベルがAI活用可能範囲の上限を規定します。認証がOIDCで統一されていればエージェントはSSOで全システムにアクセスでき、APIが標準化されていればエージェントはシステム間連携を自律実行できます。
逆にシステムごとに認証方式が異なり、データ形式もバラバラ、連携はファイル転送という状態では、AIエージェントは個別にアダプタを書く必要があり、統合コストが膨大になります。EA未整備の組織がAI活用で成果を出すのは構造的に困難です。
データカタログの整備がAI活用の第一歩
AIがデータを分析するには、まず「どこに何のデータがあるか」を知る必要があります。全社データカタログ（DataHub・Amundsen等）が整備されていれば、AIは「売上データはどのテーブルにあるか」「顧客IDの定義は何か」を自律的に検索し、正確な分析クエリを生成できます。カタログなしではAIにデータの場所を毎回教える必要があり、自律的な活用は不可能です。
「企業の地図」があれば個別 PJ が迷わない。AI 時代の DA 層が競争力を決めます。
まとめ
本記事はエンタープライズアーキテクチャの全体像について、4層モデル・AS-IS/TO-BE・TOGAF・企業規模別の粒度・成熟度段階・AI時代の競争力まで含めて解説しました。如何だったでしょうか。
4層を上から順に設計し、TOGAFをベースに進め、AS-IS/TO-BEを中期計画化、DA層を最優先で整える。これが2026年のエンタープライズアーキテクチャの現実解です。
次回はビジネスアーキテクチャ（業務プロセス・ケイパビリティマップ）について解説します。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
本記事で扱った内容の詳細は TOGAF Standard も合わせて参考にしてください。
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（69/89）