EAフレームワーク ― TOGAF+ArchiMateをTailorして使う ― 生成AI時代のアーキテクチャ超入門

本記事について

当サイトを閲覧いただきありがとうございます。本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「エンタープライズアーキテクチャ」カテゴリ第6弾（最終回）として、EAフレームワークについて解説する記事です。

フレームワークはそのまま使わない──自社に合わせてTailorするのが鉄則で、「TOGAFを完全適用」する企業は少数派です。本記事では TOGAF・Zachman・FEAF・DoDAF の比較、TOGAF ADM の Phase A〜H、Phase A-B-D に絞る現実解、絵画展で終わらせない運用まで解説します。

このカテゴリの他の記事

概要 ― 企業の地図を描く4層モデル ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-ea-overview/

ビジネスアーキテクチャ ― 事業を技術と接続可能な形にする ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-ea-ba/

データアーキテクチャ ― 全社データを戦略資産として設計する ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-ea-da/

アプリケーションアーキテクチャ ― 全社システム群を地図化する ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-ea-aa/

テクノロジーアーキテクチャ ― 企業の技術選択の憲法 ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-ea-ta/

なぜEAフレームワークが必要か

ゼロから方法論を作ると破綻する

EA は経験則で進めるには範囲が広すぎます。先人の知恵を借りる方が効率的で、既存フレームワークには数十年の実践知が詰まっています。

用語と成果物の標準化

関係者で「アーキテクチャドキュメント」と言っても、意味はバラバラです。共通の用語・成果物名があると議論が効率化します。

認証・資格との連動

TOGAF Certified 等の資格で、アーキテクトの能力を客観評価できます。採用・配置判断にも使えます。

主要フレームワーク一覧

EA フレームワークは複数存在しますが、用途・重点が違います。1つに絞る必要はなく、複数から取捨選択するのが現代的な使い方です。

フレームワーク	特徴	位置付け
TOGAF	方法論中心・最も普及	業界標準
Zachman Framework	分類学・古典	思考整理用
FEAF	米国連邦政府用	政府系で使用
DoDAF	米国防省用	軍事・航空宇宙
ArchiMate	モデリング言語	図を描く標準
BIAN	銀行業界特化	金融業界

TOGAF

The Open Group Architecture Framework の略で、事実上の業界標準です。1995年に初版が公開され、現時点では TOGAF 10（2022年公開）が最新版です。ADM（Architecture Development Method）という段階的な進め方が中核です。

TOGAFの主要要素	内容
ADM（方法論）	8フェーズで EA を進める
Architecture Content Framework	成果物の定義
Enterprise Continuum	参照モデル集
Reference Models	産業別テンプレート
Capability Framework	組織能力の定義

TOGAF認定資格（Foundation・Certified）があり、EA 職の標準資格として世界で認知されています。

ADM（Architecture Development Method）

TOGAF の中核で、EA を段階的に進める8フェーズです。Phase A → H を反復しながら進め、継続的に EA を成熟させるのが設計思想です。

flowchart TB
    PRE[Preliminary<br/>準備・原則策定]
    A[A. Architecture Vision<br/>目標像]
    B[B. Business<br/>BA設計]
    C[C. Information Systems<br/>DA/AA設計]
    D[D. Technology<br/>TA設計]
    E[E. Opportunities<br/>実装機会]
    F[F. Migration<br/>移行計画]
    G[G. Implementation<br/>実装統制]
    H[H. Change Management<br/>変更管理]
    REQ((要件管理<br/>中央))
    PRE --> A --> B --> C --> D --> E --> F --> G --> H
    H -.反復.-> A
    REQ -.- A
    REQ -.- B
    REQ -.- C
    REQ -.- D
    REQ -.- E
    REQ -.- F
    REQ -.- G
    REQ -.- H
    classDef pre fill:#fef3c7,stroke:#d97706;
    classDef phase fill:#dbeafe,stroke:#2563eb;
    classDef req fill:#fae8ff,stroke:#a21caf,stroke-width:2px;
    class PRE pre;
    class A,B,C,D,E,F,G,H phase;
    class REQ req;

ここで押さえておきたいのは、ADMは上から下に1回通すウォーターフォールではないという点です。フェーズ名が順番に並んでいるため「AからHまで順番にこなすプロセス」と誤解されがちですが、実態はフェーズ間を行き来する反復的アプローチです。Phase B（BA）を進める中でビジョン（Phase A）に不備が見つかれば戻って修正し、Phase D（TA）で見えた制約から Phase C（DA／AA）を描き直す、といった往復が前提に組み込まれています。また実務では、Phase A〜H を最初から全部やる必要はなく、特定のフェーズから始める実践パターンも一般的です。既存システムのクラウド移行なら Phase D（TA）からスタート、業務改革なら Phase B（BA）から入る、といった具合に課題に応じて入り口を選ぶのが TOGAF を現実に回す鍵になります。

Phase	内容
Preliminary	準備・原則策定
A. Architecture Vision	目標像・スコープ設定
B. Business Architecture	BA の設計
C. Information Systems	DA・AA の設計
D. Technology Architecture	TA の設計
E. Opportunities & Solutions	実装機会の特定
F. Migration Planning	移行計画
G. Implementation Governance	実装統制
H. Architecture Change Management	変更管理

「Phase B から始める」ことも可能で、状況に応じて適応できる柔軟性があります。

Zachman Framework

分類学的アプローチのフレームワークです。1987年に John Zachman が提唱し、「6つの問い（What・How・Where・Who・When・Why）」を「6つの視点（経営者・マネージャ・設計者・開発者・実装者・利用者）」で掛け合わせた6×6マトリクスを描きます。

軸	内容
What（何が）	データ
How（どう）	機能
Where（どこで）	ロケーション
Who（誰が）	人・組織
When（いつ）	時間・プロセス
Why（なぜ）	目的・戦略

方法論ではなく分類学なので、EA の全体像を整理する思考ツールとして使います。TOGAF と併用可能です。

ArchiMate

EA を図として描くためのモデリング言語で、The Open Group が策定しました。TOGAF と完全に整合しており、EAの標準記法として広く使われています。

レイヤー	内容
Strategy	戦略・目標
Business	業務プロセス・サービス
Application	アプリ・コンポーネント
Technology	物理基盤
Physical	装置・設備
Implementation & Migration	移行計画

ツールは Archi（OSS）、BiZZdesign Horizzon（商用）、Sparx EA。描画ツールが豊富で、図の一貫性が得られます。

FEAF・DoDAF

米国政府向けのフレームワークです。日本で使われることは少ないですが、政府系システム・軍事関連を扱う場合は参考になります。

フレームワーク	用途
FEAF	米国連邦政府機関
DoDAF	米国防総省
MODAF	英国国防省
TEAF	米国財務省

セキュリティ・相互運用性の要件が組み込まれているのが特徴で、大規模組織の EA に応用できるノウハウがあります。

BIAN（業界特化）

銀行業界特化のフレームワークです。Banking Industry Architecture Network の略で、銀行のビジネスケイパビリティを標準化したリファレンスモデルを提供します。

提供物	内容
Service Landscape	銀行業務のサービス地図
Business Capabilities	300+ の標準ケイパビリティ
Reference Scenarios	業務シナリオ
API Standards	銀行APIの標準

金融業界以外にも、業界特化フレームワーク（保険・通信・医療等）が存在し、業界知識の蓄積を活用できます。

フレームワーク選定

どのフレームワークを使うかは目的・業界・組織成熟度で決めます。単一選定ではなく、複数組み合わせが現実的です。

目的	推奨
初めてのEA	TOGAF Lite
全体像の整理	Zachman 思考ツール
図化・可視化	ArchiMate
業界標準活用	BIAN 等業界特化
政府系	FEAF・DoDAF

「TOGAFをベースにArchiMateで描く」がよくあるパターンです。

フレームワーク活用の現実

フレームワークは万能ではなく、落とし穴も多いです。「TOGAFの全フェーズを完璧に回す」と3年経っても一歩も進まない、というのは典型的な失敗です。

落とし穴	対策
フレームワーク原理主義	取捨選択・Tailor する
成果物作成が目的化	意思決定に使う
現場乖離	プロジェクト単位で実践
学習コスト	TOGAF 認定で最低限共通化
時代遅れ	アジャイル EA と併用

成果物を作ること自体が価値ではなく、意思決定に使われて初めて価値です。

アジャイルEA

伝統的な EA は計画重視・大規模設計ですが、現代の変化スピードに追いつきません。アジャイル的にEAを進める考え方が広がっています。

伝統的EA	アジャイルEA
3年計画	四半期ごとに見直し
完璧なモデル	十分なモデル
トップダウン	各チームと協働
成果物重視	意思決定重視
中央集権	分散・コミュニティ

SAFe（Scaled Agile Framework）や Team Topologies と組み合わせた運用が増えています。

判断基準①:企業の成熟度

EA を導入する企業の成熟度でアプローチが変わります。未経験ならシンプルから、成熟企業なら本格的に。

成熟度	推奨
EA未経験	TOGAF Foundation を学ぶ
初期導入	TOGAF Lite + ArchiMate
運用数年	TOGAF フル + 業界特化
グローバル大企業	カスタム + 複数フレームワーク

判断基準②:規制要件

政府系・金融・医療など規制の厳しい業種では、認定を要求されることもあります。

業種	要求される可能性
政府案件	TOGAF Certified
金融	BIAN・業界標準
米軍関連	DoDAF
医療	HL7（医療情報交換規格）・HIMSS（医療情報管理成熟度評価）

ケース別の選び方

EA初導入・中小企業

TOGAF Foundation 学習 + Archi（OSS）で ArchiMate 図。Zachman は思考整理に使う程度、ADM の全フェーズは回さず Phase A-B-D に絞る。アーキテクト1〜2名がパートタイムで運用、四半期に一度の見直しで十分です。

中堅企業・EA組織あり

TOGAF ADM ベース + ArchiMate + Confluence／Sparx EA + アジャイル EA。EA 専任3〜5名、Tailor したテンプレート運用、Technology Radar と連動、SAFe／Team Topologies と組み合わせる。TOGAF Certified 取得を推奨します。

金融・銀行業界

TOGAF + BIAN + ArchiMate + FISC（金融情報システムセンターの安全対策基準）準拠。BIAN Service Landscape をベースに自社ケイパビリティを構築、規制当局への説明資料が自動生成できる体制。API 標準も BIAN に準拠します。

政府系・防衛

DoDAF／FEAF + セキュリティ要件統合。軍事関連は DoDAF ビュー（OV／SV／TV）必須、相互運用性と機密区分をモデルに組み込む。TOGAF Certified + 国内資格（IPA等）も要求されることが多いです。

よくある勘違い

TOGAFを完璧に適用する

完全適用は非現実的。自社向けにTailorするのが正しい使い方。

ArchiMateが描ければEA

図は手段。意思決定に使われてこそ価値。描いただけは無意味です。

EAは古い手法

古典的 EA は時代遅れだが、アジャイルEAとして再生中。必要性は上がっています。

フレームワークは1つ選べば十分

目的別に複数併用が現代的。TOGAF + ArchiMate + 業界特化などが一般的。

EA立ち上げの初年度に「TOGAF ADM を Phase A から H まで全部回す」という計画を立て、結果として1年半たってもPhase B（BA）から抜け出せない、という事例が報告されています。延々とビジネスケイパビリティマップを磨き続け、現場は「EA って絵を描く部署でしょ？」と距離を置く。フレームワークを入り口として使うのは正解ですが、手順書として使うと死ぬ、と示唆する事例です。翌年「Phase D（TA）から入り直して、クラウド移行だけをスコープに」と Tailor し直し、半年で成果が出て組織内の信頼も回復したというケースもあります。

EAフレームワーク活用の段階別ロードマップ

フレームワークは段階的に導入するのが鉄則です。いきなり全適用は破綻します。

フェーズ	期間目安	活用範囲	投資人員
①学習	3〜6か月	TOGAF Foundation 取得・Zachman 理解	1〜2名
②Lite導入	6〜12か月	TOGAF Phase A〜D のみ、ArchiMate 描画	EA 1〜2名
③定期運用	1〜2年	TOGAF ADM 全フェーズ + 四半期レビュー	EAチーム3〜5名
④業界特化	2年〜	BIAN／DoDAF 等の業界FW 併用	専門EA組織
⑤EA as Code	継続的	ArchiMate + Git + API 公開、AI 連携	CTO 直轄

「Phase A-B-Dだけ」に絞る Tailoring が現実的です。1年半Phase Bから抜け出せない事例は典型的失敗で、「TOGAF完全適用」は3年経っても現場に届きません。

フレームワークは入り口として使い、手順書として使わない。Tailor しないと必ず疲弊します。

EAフレームワーク運用の鬼門・禁じ手

EA フレームワーク運用で事故る典型。どれも絵を描いて終わり、意思決定に使われないパターンです。

禁じ手	なぜダメか
TOGAF ADMをPhase AからHまで完全適用	1年半 Phase B から抜け出せない、300ページのケイパビリティマップで現場は置き去り
フレームワークを手順書として使う	原理主義で硬直化、変革機会を逃す
ArchiMateを描くだけで意思決定に使わない	図は手段、意思決定で使われないなら価値ゼロ
PowerPoint EAで運用	AI 読解不能、機械可読形式で残すのが現代
業界特化FW（BIAN等）を活用せず自力でゼロから	業界知識の蓄積を無視、車輪の再発明
TOGAFを1つだけで全てを解決しようとする	目的別に TOGAF + ArchiMate + 業界特化の組み合わせが現代
計画を3年固定で変更禁止	事業変化に追従不能、アジャイル EA の時代
成果物作成がKPI化	300ページのドキュメントが誰にも読まれない
現場プロジェクトと乖離した中央EA	EA が象牙の塔化、現場から無視される

Spotifyのアジャイル EA（Tribe／Squad／Chapter／Guild モデル、後に “Spotify Model” として世界に拡散）は、中央集権の完璧なモデルではなく、“十分なモデル”で数百チームの整合性を保った成功例。日本の大手 SIer の TOGAF 完全適用1年半 Phase B 停滞事例と対照的な教訓です。

フレームワークは地図であって歩くのはあなた。完璧な地図より十分な地図で歩き始めます。

AI時代の視点

AI 駆動開発（バイブコーディング）と AI 活用が前提になると、EA フレームワークはAIが理解できる構造化されたアーキテクチャ記述として再評価されます。ArchiMate のような形式化されたモデルは、LLM（Large Language Model＝大規模言語モデル）で解析・生成・変換が容易です。

AI時代に有利	AI時代に不利
ArchiMate等の形式化モデル	PowerPoint の手書き図
コード化されたEA	紙の文書
Gitで管理されるモデル	個人のExcel
APIで参照可能	ファイルで共有

「AIがEAを読んで分析・提案」する時代には、フレームワーク準拠の形式化モデルが AI 時代の競争力になります。EA as Code（EA をコード化）の動きが始まっています。

AI 時代の EA は機械が読める形式で残す。PowerPoint EA は淘汰されます。

決めるべきこと — あなたのプロジェクトでの答えは？

以下の項目について、あなたのプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。

主要フレームワーク（TOGAF・Zachman等）
モデリング記法（ArchiMate等）
適用範囲（Tailorの内容）
業界特化フレームワーク（BIAN等の活用）
ツール選定（Archi・Sparx EA等）
資格・教育（TOGAF Foundation等）
運用サイクル（四半期・年次）

筆者メモ — 「フレームワーク原理主義」で組織が疲弊した事例

EA フレームワークを手順書のように扱って失敗する組織は、業界に繰り返し現れます。

ある日本の大手 SIer で、大規模顧客案件のために TOGAF ADM を Phase A から H まで完全適用する方針を立てた結果、Phase B（BA）だけで1年半を費やし、ケイパビリティマップを300ページ近く作成、現場からは「EAは絵を描く部署」と距離を置かれ、最終的にプロジェクトは凍結されました。その後、「Phase D（TA）から入り、クラウド移行のみをスコープに」と Tailor し直したところ、半年で具体的な移行計画が出て、組織の信頼を取り戻した──という話は EA 界隈で教訓として語られ続けています。

対照的に、Spotifyのアジャイル EAは成功例としてよく引用されます。Spotify は初期からアジャイル思想で EA を運用し、「Tribe／Squad／Chapter／Guild」という分散アーキテクチャ組織モデル（後に “Spotify Model” として世界に拡散）を作りました。中央集権の完璧なモデルではなく、各Squadが自律的にアーキテクチャ決定し、Chapterが全社標準を緩やかに調整する──という”十分なモデル”の運用で、数百チームの整合性を保ったまま高速開発を両立しました。

どちらも「フレームワークは入り口として使い、手順書として使わない」ことが、EA を死なせないための最大の鍵だと示しています。完璧な地図を描くのではなく、十分な地図で歩き始めるのが正解です。

最終的な判断の仕方

EA フレームワークの核心はそのまま使わず、自社に合わせてTailorするという発想です。TOGAF を完璧に全フェーズ適用すると3年経っても一歩も進まない、という失敗は典型的です。先人の数十年の実践知を使って効率化しつつ、Phase A-B-D に絞る等の取捨選択が現実解になります。TOGAF + ArchiMate + 業界特化（BIAN等）の組み合わせが現代のスタンダードで、単一フレームワーク原理主義は時代遅れです。成果物を作ること自体が価値ではなく、意思決定に使われて初めて価値になる──これがフレームワーク活用の鉄則です。

もう一つの決定的な軸はEA as Codeで機械可読にするという要請です。AI が EA を読んで影響分析・提案する時代、PowerPoint 手書き図・個人 Excel は淘汰されます。ArchiMate 等の形式化モデルを Git 管理し、API で参照可能な状態にしておく企業だけが、AI 時代の EA を活かせます。伝統的 EA の計画重視から、アジャイル EA（四半期見直し・各チーム協働）への転換も並行して進みます。

選定の優先順位

TOGAF + ArchiMateを軸にする — 業界標準、資格整備、描画ツール豊富
Tailorして取捨選択する — 完全適用せず Phase A-B-D に絞る、原理主義禁物
業界特化FWを併用 — BIAN（金融）・DoDAF（政府）等、業界知識を活用
機械可読・Git管理・アジャイル化 — EA as Code、四半期見直し、AIが読める形

「TOGAF + ArchiMateをTailor、Git管理で機械可読」PowerPoint EA は淘汰されます。

まとめ

本記事はEAフレームワークについて、TOGAF・Zachman・ArchiMate・BIAN・FEAF/DoDAF・ADMのTailoring・アジャイルEA・EA as Codeまで含めて解説しました。如何だったでしょうか。

TOGAF+ArchiMateを軸に、Tailorして取捨選択、業界特化FWを併用、機械可読でGit管理する。これが2026年のEAフレームワーク活用の現実解です。

そしてこれが「エンタープライズアーキテクチャ」カテゴリの最終回でした。次回からは新しいカテゴリ（ソリューションアーキテクチャ）の解説に入ります。

シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方

それでは次の記事も閲覧いただけると幸いです。