本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「エンタープライズアーキテクチャ」カテゴリ第1弾として、エンタープライズアーキテクチャの全体像について解説する記事です。
EAは企業全体の戦略視点を扱うため、個別プロジェクト視点の他カテゴリと対象読者が明確に違います。本章は「全社の地図を描く人」向け（CIO・CDO・経営企画・IT戦略部門・EAチーム）。中小プロジェクト中心の読者は次章「ソリューションアーキテクチャ」の方が日常業務に近いはずです。本記事ではBA/DA/AA/TAの4層、AS-IS/TO-BE、TOGAF、企業規模別の粒度まで俯瞰します。
このカテゴリの全記事一覧・各記事で学べるポイントは以下のページにまとめています。
本記事のテーマについてさらに詳しく知りたい方は『エンタープライズ・アーキテクチャの基本と仕組み』も参考にしてみてください。
この記事の結論
- BA→DA→AA→TAの4層を上から順に設計する
- AS-IS / TO-BEを中期計画に落とす
- AI時代はDA層（データ）を最優先で整える
この記事を読む前に
本記事は会社全体のシステムをどう整理するかという話が中心で、技術用語は比較的少なめです。とは言っても、Webサービスの基本構造を知っていると読みやすくなりますので、不安な方は基礎編の「Webサービスが動く仕組み」からどうぞ。また、読んでいて分からない用語が出てきたときは用語集で調べながら読み進められます。
そもそもエンタープライズアーキテクチャとは何か
都市計画を想像してください。個々の建物がどんなに立派でも、道路・上下水道・電力網が整備されていなければ都市は機能しません。各地区がバラバラに開発された結果、隣町と道路がつながらない・水道管が重複する・電力が足りないといった問題が起きます。
エンタープライズアーキテクチャ（EA）は企業全体のIT戦略を都市計画のように統合的に設計する領域です。個別プロジェクトの設計を超えて、会社全体でビジネスとITの整合を取ります。ビジネス（BA）・データ（DA）・アプリケーション（AA）・テクノロジー（TA）の4層で全体像を整理し、CIO・経営企画・IT戦略部門が中心となって扱います。
もしEAがなければ、部署ごとに似たシステムを別々に作り、データが分断されて全社分析ができない状態に陥ります。個別最適の積み重ねが全体最悪を生むのです。EAは「企業の地図」──地図があれば個別プロジェクトが迷わなくなります。
なぜ独立したアーキテクチャとして扱うか
第一に、企業全体の整合が取れていないと重複投資が発生するからです。部署ごとに別々の顧客管理システムを作る、似たデータを別々のDBに持つ等、EAがないと同じものを何度も作ることになります。
第二に、全社DX推進の土台だからです。DXは個別アプリ開発ではなく、業務・データ・システムを全社で再設計する取り組みで、EAの視点がないと進められません。
第三に、既存資産（レガシー）の整理です。大企業は数十年積み上げたシステム資産を持ちます。何を残し・何を捨て・何を作り直すかを経営判断に繋げるのがEAの仕事です。
EAの4層モデル
EAは企業を4つの層で捉えます。上から下へ降りるほど具体的・技術的になり、上位の決定が下位を規定します。
| 層 | 扱うもの | 決める主体 |
|---|---|---|
| BA（ビジネスアーキテクチャ） | 業務プロセス・組織・ケイパビリティ | 経営・業務部門 |
| DA（データアーキテクチャ） | 全社データの定義・流れ・管理 | CDO・データ部門 |
| AA（アプリケーションアーキテクチャ） | システム群・連携・ポートフォリオ | CIO・IT部門 |
| TA（テクノロジーアーキテクチャ） | インフラ・クラウド・標準技術 | インフラ部門 |
BAが変わるとDAが変わる、DAが変わるとAAが変わる…という上下の繋がりがEA設計の本質です。決める項目は、BA / DA層では業務ケイパビリティマップ・業務プロセス記法（BPMN等）・データガバナンス体制（CDO・データスチュワード）・マスタデータ管理・データカタログ・データ品質基準、AA / TA層ではシステム標準（共通認証・共通ID）・連携パターン（API / イベント駆動）・アプリポートフォリオ（Buy / Build / Subscribe）・クラウド方針・技術標準・リファレンスアーキテクチャです。各層の詳細はこのカテゴリの各論記事で扱います。
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を語るなら実質TOGAF一択で、最も普及し資格（TOGAF認定）も整備されています。その他、6×6マトリクスで整理する学術的なZachman、米政府向けのFEA等がありますが、独自フレームワークでゼロから進めると成果物の粒度・品質がバラつき、経営への説明が困難になります。
EAとよく混同されるソリューションアーキテクチャ（次章）は、視点のスコープが違います。EAは企業全体・3〜5年の中期・全社ロードマップと標準が成果物でCIO・経営が関係者。ソリューションアーキテクチャは個別プロジェクト・半年〜数年・システム設計書が成果物です。EAが描いた全社方針の中で、個別プロジェクトをソリューションアーキテクトが設計する関係です。
企業規模別の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成熟度の段階表
※ 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 |
TOGAF ADMの「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層が分かっていなければ手順書の丸暗記に終わります。
AI判断軸 ― AI時代の競争力はEAの成熟度で決まる
EA成熟度がAI活用の上限を決める構造
AIエージェントが社内システムを横断利用する時代には、EAの標準化レベルがAI活用可能範囲の上限を規定します。認証がOIDCで統一されていればエージェントはSSOで全システムにアクセスでき、APIが標準化されていればエージェントはシステム間連携を自律実行できます。
逆にシステムごとに認証方式が異なり、データ形式もバラバラ、連携はファイル転送という状態では、AIエージェントは個別にアダプタを書く必要があり、統合コストが膨大になります。EA未整備の組織がAI活用で成果を出すのは構造的に困難です。
データカタログの整備がAI活用の第一歩
AIがデータを分析するには、まず「どこに何のデータがあるか」を知る必要があります。全社データカタログ（DataHub・Amundsen等）が整備されていれば、AIは「売上データはどのテーブルにあるか」「顧客IDの定義は何か」を自律的に検索し、正確な分析クエリを生成できます。AIはデータ品質とアクセス可能性で精度が決まるため、EAのDA層（データアーキテクチャ）が再評価されています。DA層の再設計は、今やAI戦略の中核です。
EA全体の鬼門
各論記事で触れる禁じ手のうち、EAレベルで押さえるべき核心を6つに絞ります。
| 禁じ手 | なぜダメか → どうするか |
|---|---|
| TOGAF ADMを完全適用（Phase A〜H全て） | 1年半Phase B停滞が典型失敗 → Phase A-B-DにTailoringする |
| 4層同時に完璧を目指す | 着手不能になる → BA + DAの2層から段階的に育てる |
| 顧客マスタを部門別に放置 | 「15種類の顧客マスタ」問題でDXが数年止まる → DA層でMDMを最優先に |
| AS-IS / TO-BEを描いて終わり | 絵画展で終わる → 中期計画と個別プロジェクトに接続する |
| PowerPoint EAで運用 | AI読解不能・更新されない → 機械可読形式（EA as Code）へ |
| 中央EAが象牙の塔化 | 現場と乖離して誰も従わない → アジャイルEAで現場と協働する |
なお「EAは大企業だけのもの」という思い込みも誤りです。中小企業でもサイロ化・重複投資は発生し、規模に合わせた粒度で全社の地図を描く価値は同じです。
筆者メモ — 「顧客マスタが15種類」で全社DXが数年止まった事例
日本の大手企業で「顧客データを全社統合したい」というDX案件が立ち上がり、各部署の基幹システムを掘っていくと、社内に「顧客マスタ」と呼ばれるテーブルが15種類存在していた、という話は決して珍しくありません。同じ法人が違う顧客コードで10回登録され、どれが正かは担当者の経験則でしか分からない──統合プロジェクトは「まずどれが真実か」の合意形成だけで1年、MDM導入で2年、計3〜5年止まる、という事例が繰り返し報告されてきました。個別プロジェクトのアーキテクトが何人いても、この状態は直りません。
もう一つ、みずほ銀行システム障害（2021〜2022年、1年で11回の障害を記録）は、EA不在・システム統合の失敗が経営責任問題にまで発展した象徴事例です。旧3行のシステムを十分なEA設計なしに統合しようとした結果、20年近くシステム統合に苦しみ続け、最終的に金融庁から業務改善命令を受けるに至りました。企業の地図を後回しにした代償は数千億円単位になりうることを、日本の金融史に刻んだ事件です。
どちらも「企業全体を俯瞰する人がいなかった」という構造的な欠陥が致命傷で、EAは絵画ではなく経営の基盤であることを突きつけます。
まとめ
本記事はエンタープライズアーキテクチャの全体像について、4層モデル・AS-IS/TO-BE・TOGAF・企業規模別の粒度・成熟度段階・AI時代の競争力まで含めて解説しました。如何だったでしょうか。
4層を上から順に設計し、TOGAFをベースに進め、AS-IS/TO-BEを中期計画化、DA層を最優先で整える。これが2026年のエンタープライズアーキテクチャの現実解です。
次回はビジネスアーキテクチャ（業務プロセス・ケイパビリティマップ）について解説します。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
本記事で扱った内容の詳細は TOGAF Standard も合わせて参考にしてください。
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（75/95）