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

本記事について

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

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

本記事のテーマについてさらに詳しく知りたい方は『エンタープライズ・アーキテクチャの基本と仕組み』も参考にしてみてください。

そもそもEAフレームワークとは何か

料理のレシピ本を思い浮かべてください。経験豊富なシェフが何十年もかけて編み出した手順と分量が体系的にまとめられています。ゼロから自己流で試行錯誤するより、先人の知恵を借りた方が圧倒的に効率的です。

EAフレームワーク（TOGAF・Zachman等）は、企業全体のIT戦略を設計するための手順書・用語集・成果物テンプレートのセットです。数十年の実践知が詰まっており、自社に合わせてカスタマイズ（Tailor）して使います。

もしフレームワークなしでEAを進めると、用語の定義から始めることになり、関係者間で共通言語が持てないまま議論が空転します。

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

第一に、ゼロから方法論を作ると破綻するからです。EAは経験則で進めるには範囲が広すぎ、既存フレームワークには数十年の実践知が詰まっています。第二に、用語と成果物の標準化です。関係者で「アーキテクチャドキュメント」と言っても意味はバラバラで、共通の用語・成果物名があると議論が効率化します。第三に、TOGAF Certified等の資格でアーキテクトの能力を客観評価でき、採用・配置判断にも使えます。

主要フレームワーク一覧

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

TOGAF（The Open Group Architecture Framework）が事実上の業界標準で、現時点ではTOGAF 10（2022年公開）が最新版です。認定資格（Foundation・Certified）はEA職の標準資格として世界で認知されています。Zachmanは6つの問い（What〜Why）×6つの視点の6×6マトリクスで整理する分類学で、方法論ではなく思考ツールとしてTOGAFと併用できます。ArchiMateはEAを図として描くモデリング言語で、TOGAFと完全に整合し、Strategy / Business / Application / Technology等のレイヤーで一貫した図が描けます（ツールはOSSのArchi、商用のBiZZdesign・Sparx EA）。BIANは銀行業務の300超の標準ケイパビリティとAPI標準を提供する業界特化モデルで、保険・通信・医療にも同種の業界フレームワークがあります。FEAF・DoDAFは米政府・国防向けで、日本では政府系・防衛案件で参照される程度です。

「TOGAFをベースにArchiMateで描き、業界特化FWを併用する」のがよくあるパターンです。

ADM（Architecture Development Method）

TOGAFの中核が、EAを段階的に進める8フェーズのADMです。

押さえておきたいのは、ADMは上から下に1回通すウォーターフォールではないという点です。実態はフェーズ間を行き来する反復的アプローチで、Phase B（BA）を進める中でビジョン（Phase A）に不備が見つかれば戻って修正する往復が前提です。また実務では全フェーズを最初からやる必要はなく、既存システムのクラウド移行ならPhase D（TA）からスタート、業務改革ならPhase B（BA）から入る、と課題に応じて入り口を選ぶのがTOGAFを現実に回す鍵です。

フレームワーク活用の現実とアジャイルEA

フレームワークは万能ではありません。「TOGAFの全フェーズを完璧に回す」と3年経っても一歩も進まない、というのが典型的な失敗です。フレームワーク原理主義には取捨選択（Tailor）で、成果物作成の目的化には「意思決定に使う」という原点回帰で対抗します。成果物を作ること自体が価値ではなく、意思決定に使われて初めて価値です。

伝統的なEA（3年計画・完璧なモデル・トップダウン・中央集権）は現代の変化スピードに追いつきません。アジャイルEA──四半期ごとの見直し・十分なモデル・各チームとの協働・意思決定重視──への転換が進んでおり、SAFeやTeam Topologiesと組み合わせた運用が増えています。

規模・業界別の使い分け

EA初導入の中小企業は、TOGAF Foundation学習 + Archi（OSS）でArchiMate図から始め、ADMはPhase A-B-Dに絞ります。アーキテクト1〜2名がパートタイムで運用し、四半期に一度の見直しで十分です。EA組織のある中堅企業はTOGAF ADMベース + ArchiMate + Sparx EA + アジャイルEAで、EA専任3〜5名がTailorしたテンプレートを運用し、Technology Radarと連動させます。金融・銀行業界はTOGAF + BIAN + FISC準拠で、BIAN Service Landscapeをベースに自社ケイパビリティを構築し、規制当局への説明資料が自動生成できる体制を作ります。政府系・防衛はDoDAF / FEAF + セキュリティ要件統合が要求されます。

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

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

「Phase A-B-Dだけ」に絞るTailoringが現実的です。1年半Phase Bから抜け出せない事例は典型的失敗で、フレームワークは入り口として使い、手順書として使わないのが死なせないための最大の鍵です。

AI判断軸 ― EA as Codeで機械可読にする

ArchiMateモデルをAIに読ませて影響分析させる

ArchiMateのモデルは構造化されたフォーマット（XML / JSON）でエクスポートできるため、AIに渡して「このシステムを廃止した場合の影響範囲を分析して」のようなクエリを実行できます。PowerPointの図では構造がAIに伝わらず、手動で影響を一つずつ洗い出す必要があります。「AIがEAを読んで分析・提案」する時代には、フレームワーク準拠の形式化モデルが競争力になります。

EA as CodeでGit管理する動き

EAモデルをPlantUML・Structurizr・ArchiMateのXMLとしてGitで管理し、PRでレビューするEA as Codeの動きが広がっています。これによりEAモデルの変更履歴が追跡可能になり、AIがモデルの変更差分を解析して影響レポートを自動生成する運用も視野に入ります。PowerPoint手書き図・個人Excelは、AI時代のEAでは淘汰されます。

やってはいけないこと

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

なお「EAは古い手法」と切り捨てるのも誤りです。古典的EAは時代遅れですが、アジャイルEAとして再生しており、AI時代にはむしろ必要性が上がっています。

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

ある日本の大手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を死なせないための最大の鍵だと示しています。完璧な地図を描くのではなく、十分な地図で歩き始めるのが正解です。

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

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

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

この記事に関連する記事

まとめ

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

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

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

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

本記事で扱った内容の詳細は TOGAF Standard も合わせて参考にしてください。

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