ArchiMate(エンタープライズアーキテクチャモデリング言語)

1. 概要

A. 定義

ArchiMateは The Open Group が管理するオープン標準であり、エンタープライズアーキテクチャ(EA)のビジネス・アプリケーション・技術の各領域と、それらの間の関係を単一で一貫した視覚言語(visual modeling language)で表現・分析・疎通するためのモデリング表記法である。ある組織の戦略・業務・システム・インフラを一組の共通語彙(要素と関係)で描き、異なるステークホルダーが同じ図を見て同じ意味を読み取れるようにすることを目的とする。

ArchiMate の性格を正確に理解するには、まず「方法論ではなく言語である」という点を明確にしなければならない。TOGAF の ADM が「アーキテクチャをどのような手順で作るか」を規定する方法論であるなら、ArchiMate はその手順が生み出す成果物を「どのような記号で描くか」を規定する表記法である。すなわち TOGAF が設計過程であるなら ArchiMate はその結果を収める図面規約であり、両標準がいずれも The Open Group の所管である点で相互補完を前提に設計されている。

中核的特徴は三つである。第一に、レイヤー(layer)とアスペクト(aspect)という二つの軸でエンタープライズを分解し、いかなるアーキテクチャ要素も「どのレイヤーに属するか × 能動構造・振る舞い・受動構造のいずれか」で分類する。第二に、サービス指向(service orientation)の思想を言語自体に内蔵し、上位レイヤーが下位レイヤーの「サービス」を消費する関係で全レイヤーを一貫して連結する。第三に、ビューポイント(viewpoint)機構により、同一モデルからステークホルダー別の関心事のみを抽出する選択的可視化を支援する。

ArchiMate は UML・BPMN のような特定領域専用言語とは異なり、「レイヤーを横断して(cross-layer)全社を一枚につなぐ」点に固有の価値がある。UML はソフトウェア内部を、BPMN は業務プロセスを精密に描くが、「この業務サービスがどのアプリケーションコンポーネントで実現され、そのコンポーネントがどのサーバー・ネットワーク上で動作するか」を一つのつながったモデルで示すことはできない。ArchiMate はまさにこの「レイヤー間のトレーサビリティ」を中核能力とする。

B. 登場背景と必要性

ArchiMate は 2002~2004 年のオランダ Telematica Instituut 主導の研究プロジェクトに端を発し、2008 年に The Open Group へ移管され、以後 2.0(2012)・3.0(2016)・3.1(2019)・3.2(2022)へと発展してきた。この標準が必要とされた根本的理由は、EA 実務が長らく「レイヤーごとに異なる図の言語」に分断されていた点にある。

第一の動因は表記法の分断による疎通断絶である。かつて EA 成果物は、業務はフローチャート、アプリケーションは UML、データは ERD、インフラはネットワーク図とそれぞれ別個に描かれた。各図は精密であったが相互に連結されず、「この業務が変われば、どのシステムとサーバーが影響を受けるか」という全社レベルの問いに答えられなかった。ArchiMate は全レイヤーを一つの表記体系で束ねることで、この断絶を埋めようとした。

第二の動因はビジネス–IT 整合(alignment)の可視化である。経営陣は戦略・ケイパビリティ・バリューストリームを語り、エンジニアはサーバー・ミドルウェアを語るが、その間をつなぐ「アプリケーションサービス・業務サービス」という中間の橋が明示されなければ、両者は異なる世界を想像する。ArchiMate のサービス階層化は「戦略→業務→アプリケーション→技術」がサービス消費関係で垂直に連結されるよう強制し、整合を構造的に露わにする。

第三の動因は変化影響分析(impact analysis)と意思決定根拠の確保である。デジタル変革によってシステム相互依存が激増し、特定のアプリケーションを置き換えたり規制が変わったりしたときの波及を手作業で追うことは事実上不可能になった。要素間の関係が形式規則として定義された ArchiMate モデルは、ツールを通じて「このノードに連結された上流・下流の要素」を照会でき、影響分析と投資意思決定の根拠資料となる。

第四の動因は国際標準としての相互運用性である。組織ごとに社内方言でアーキテクチャを描けば、企業間・部門間の成果物交換とツール互換が難しい。ArchiMate はオープン標準と交換フォーマット(ArchiMate Model Exchange File Format)を提供し、特定ベンダーツールに拘束されずモデルを移動・統合できるようにする。実際、国内外の公共・金融機関の EA 事業で TOGAF ADM と ArchiMate を併用し、手順と表記を同時に標準化する事例が増えている。

2. ArchiMate の中核構造 — レイヤーとアスペクト

ArchiMate の骨格は「レイヤー × アスペクト」の二次元フレームワークである。縦軸であるレイヤーは抽象化の高さ(戦略・業務・アプリケーション・技術)を、横軸であるアスペクトは要素の本性(何が行動するか・何が起こるか・何が扱われるか)を表す。この直交分解のおかげで、いかなるアーキテクチャ要素も単一のセルに分類され、重複と欠落が抑制される。

graph TD
    AM["ArchiMate フレームワーク(レイヤー x アスペクト)"]
    AM --> L["縦軸: レイヤー(抽象化の高さ)"]
    AM --> A["横軸: アスペクト(要素の本性)"]
    L --> L0["戦略(Strategy): リソース・ケイパビリティ・バリューストリーム"]
    L --> L1["ビジネス(Business): 業務アクター・サービス・プロセス"]
    L --> L2["アプリケーション(Application): コンポーネント・アプリサービス・データ"]
    L --> L3["技術(Technology): ノード・システムSW・インフラサービス"]
    L --> L4["物理(Physical): 設備・装置・資材"]
    L --> L5["実装・移行(Implementation & Migration): 作業パッケージ・プラトー"]
    A --> A1["能動構造(Active Structure): 行動主体"]
    A --> A2["振る舞い(Behavior): 遂行される活動・サービス"]
    A --> A3["受動構造(Passive Structure): 扱われる客体"]
    A --> A4["動機(Motivation): ステークホルダー・目標・要求・原則"]

A. レイヤー(Layer) — 戦略から技術までの垂直分解

ArchiMate 3.x の中核レイヤーはビジネス・アプリケーション・技術の三層であり、ここに上位の戦略(Strategy)レイヤーと、全レイヤーを横断する動機(Motivation)・実装および移行(Implementation & Migration)拡張が加わる。ビジネスレイヤーは組織が顧客に提供する価値と業務サービス・プロセス・役割を扱い、アプリケーションレイヤーはその業務を支えるソフトウェアコンポーネントとアプリケーションサービスを扱い、技術レイヤーはアプリケーションを駆動するハードウェア・システムソフトウェア・通信インフラを扱う。

レイヤーを分ける根本的理由は「抽象化水準の異なる関心事を混ぜないため」である。たとえば「保険金請求処理」という業務サービス(ビジネス)と、それを実現する「請求管理システム」(アプリケーション)、さらにそのシステムが載る「コンテナオーケストレーションクラスター」(技術)は、変化する速度と責任主体がまったく異なる。レイヤーを分離すれば、あるレイヤーの変化を他のレイヤーと独立に管理でき、レイヤー間はもっぱら「サービス」インターフェースで疎に結合される。これが ArchiMate の宣言するサービス指向の実践的含意である。

3.0 で追加された戦略レイヤーは、EA が単なるシステム地図から脱し、経営戦略と直接つながることを助ける。リソース(Resource)・ケイパビリティ(Capability)・コースオブアクション(Course of Action, Value Stream)といった要素で「我々はどのケイパビリティを確保し、どの経路で価値を届けるか」を描き、そのケイパビリティがどの業務・アプリケーション・技術で実現されるかを下位レイヤーとつなぐ。たとえばある通信事業者が「超個別化マーケティングケイパビリティ」を戦略要素として置けば、それが「CDP 構築」という業務機能、「顧客データプラットフォーム」というアプリケーションコンポーネント、「GPU 分析クラスター」という技術ノードで実現される流れを一枚に収められる。

B. アスペクト(Aspect) — 能動構造・振る舞い・受動構造

横軸であるアスペクトは、文法の品詞にたとえられる。能動構造(active structure)は行動の「主語」に当たる要素(業務役割、アプリケーションコンポーネント、技術ノード)であり、振る舞い(behavior)は「動詞」に当たる要素(業務プロセス、アプリケーション機能、サービス)であり、受動構造(passive structure)は「目的語」に当たる要素(業務オブジェクト、データオブジェクト、アーティファクト)である。ここに全レイヤーを貫く動機(motivation)アスペクトが加わり、ステークホルダー・ドライバー・目標・要求・制約・原則を扱う。

この品詞的分解が有用なのは、「誰が(能動)何を(受動)どう扱うか(振る舞い)」という叙述構造を全レイヤーで同一に反復するからである。ビジネスレイヤーの「請求審査者(能動)が請求書(受動)を審査する(振る舞い)」という構造は、アプリケーションレイヤーの「請求審査コンポーネント(能動)が請求データ(受動)を検証する(振る舞い)」にそのまま対応し、レイヤー間のマッピングとトレースが自然に行われる。動機アスペクトは「なぜこの構造が存在するか」を別次元として明示し、規制・目標・原則が特定の業務・アプリケーション要素でどう実現されるかを連結する。

アスペクト区分が実務で特に価値を持つのは規制・コンプライアンストレースである。たとえば個人情報保護法や金融業界の電子金融監督規定のような外部制約を動機アスペクトの「ドライバー(driver)」と「要求(requirement)」としてモデリングすれば、その要求がどの業務プロセス(振る舞い)とアプリケーションコンポーネント(能動構造)、どのデータオブジェクト(受動構造)で実現されるかを関係で追える。規制が改正されたとき影響を受けるシステムをモデル照会で識別できるため、アスペクト軸は単なる分類を超え、ガバナンス・監査対応の実質的根拠となる。

3. 要素と関係 — サービス指向とレイヤー連結

ArchiMate モデルは結局、要素(element)を関係(relationship)でつなぐグラフである。要素が語彙であるなら関係は文法であり、関係の種類と許容規則が厳密に定義されている点が、自由な「四角と矢印」の図と決定的に異なる。

graph TB
    subgraph BIZ["ビジネスレイヤー"]
        BS["業務サービス: 保険金請求処理"]
        BP["業務プロセス: 請求 受付-審査-支給"]
        BR["業務役割: 請求審査者"]
    end
    subgraph APP["アプリケーションレイヤー"]
        AS["アプリサービス: 請求審査 API"]
        AC["アプリコンポーネント: 請求管理システム"]
        DO["データオブジェクト: 請求データ"]
    end
    subgraph TECH["技術レイヤー"]
        TS["技術サービス: コンテナランタイム"]
        NODE["ノード: K8s クラスター"]
    end
    BR -->|"assignment: 遂行"| BP
    BP -->|"realization: 実現"| BS
    AS -->|"serving: 支援"| BP
    AC -->|"realization: 実現"| AS
    AC -->|"access: 読み書き"| DO
    TS -->|"serving: 駆動"| AC
    NODE -->|"realization: 提供"| TS

A. 関係の類型 — 構造的・依存・動的・その他

ArchiMate の関係は性格によって四つの束に分かれる。構造的関係(structural)は要素の静的構成を表し、合成(composition)・集約(aggregation)・割り当て(assignment)・実現(realization)がこれに入る。依存関係(dependency)は要素が互いに寄りかかる仕方を表し、提供(serving)・アクセス(access)・影響(influence)・関連(association)が入る。動的関係(dynamic)は時間の流れを表すトリガー(triggering)・フロー(flow)であり、その他として特化(specialization)と接合点(junction)がある。

関係が形式的に定義されている点は、実務で大きな含意を持つ。たとえば「実現(realization)」は「より抽象的な要素をより具体的な要素が実装する」という意味でのみ用いられるよう規定されており、業務サービスを業務プロセスが実現し、アプリケーションサービスをアプリケーションコンポーネントが実現するといった一貫した垂直トレースが可能である。逆に「提供(serving)」は、ある要素が他の要素に機能を提供する水平・垂直依存を意味し、アプリケーションサービスが業務プロセスを「支援」するレイヤー間連結の主要な通路となる。このように関係の意味が固定されていてこそ、ツールがモデルを照会・検証できる。

B. サービス指向とレイヤー連結の論理

ArchiMate の設計思想のうち最も重要なのが、「各レイヤーは下位レイヤーが露出するサービスを通じてのみ結合される」という原則である。アプリケーションレイヤーの内部コンポーネントがいかに複雑でも、ビジネスレイヤーはそれが露出する「アプリケーションサービス」のみを消費し、技術レイヤーもまた「技術サービス」でのみアプリケーションを支える。このサービス境界がレイヤー間の結合度を下げ、あるレイヤー内部を置き換えても露出サービスさえ同一なら上位レイヤーが影響を受けないようにする。

この原理はマイクロサービス・API エコノミー時代に特によく合致する。たとえばある銀行がレガシーメインフレームの与信システムをクラウドネイティブに再構築する際、露出する「与信審査サービス」の契約(インターフェース)さえ維持すれば、そのサービスを消費する業務プロセスとチャネルアプリケーションは変更なく維持される。ArchiMate モデルはこの「維持されるべきサービス境界」を明示的に露わにし、現代化の範囲と影響の範囲を視覚的に区画する。

4. ビューポイント(Viewpoint) — ステークホルダー別の選択的可視化

全社モデルは要素が数百~数千に達するため、そのまま見せては誰も読めない。ArchiMate はこれをビューポイント機構で解決する。ビューポイントとは「特定のステークホルダーの特定の関心事に合わせ、全体モデルから見せる要素・関係の種類を規定したレンズ」であり、そのレンズで実際に描き出した図がビュー(view)である。これはアーキテクチャ記述の国際標準である ISO/IEC/IEEE 42010 の「ステークホルダー–関心事–ビューポイント–ビュー」概念と整合する。

たとえば経営陣には戦略・ケイパビリティとそれを実現する中核業務サービスのみを収めた「ケイパビリティマップビュー」を、アプリケーションアーキテクトにはアプリケーションコンポーネントとその間の協力のみを収めた「アプリケーション協力ビュー」を、インフラ担当者にはノード・ネットワーク・システムソフトウェア中心の「インフラビュー」を提供する。同一の単一モデルから異なるレンズで抽出されるため、経営陣のケイパビリティ要素とインフラのサーバーが同じモデル内でトレース可能に連結されている点が、手作業のパワーポイント図と根本的に異なる。

標準は基本(standard)ビューポイント群を例として提供するが、組織は自らの関心事に合わせてカスタムビューポイントを定義できる。重要な実務原則は「ビューは多くてもモデルは一つ」である。ビューを増やしても、その下に敷かれた要素・関係の単一リポジトリ(repository)が一つに保たれてこそ整合性と影響分析能力が保存される。ビューごとに別個の要素を重複生成すれば、ArchiMate の中核価値は崩れる。

5. 比較 — 隣接する表記・フレームワークとの関係

ArchiMate の位置は、隣接する言語・フレームワークとの比較で明確になる。要点は「ArchiMate はレイヤーを横断する全社レベルの表記であり、UML・BPMN・ERD は特定レイヤー内部を精密に描く専用表記であり、TOGAF・Zachman は表記ではなく手順・分類体系である」という役割分担である。

区分	性格	主対象範囲	ArchiMate との関係
ArchiMate	モデリング言語(表記)	戦略・業務・アプリ・技術の全レイヤー	本主題 — レイヤー間連結に特化
TOGAF ADM	方法論(手順)	EA 開発の全過程	相互補完(手順↔表記)、同一所管
Zachman	分類体系(オントロジー)	成果物分類の座標	補完 — 「何を」分類 vs 「どう描くか」
UML	モデリング言語	ソフトウェア内部設計	アプリレイヤー詳細は UML で補完
BPMN	モデリング言語	業務プロセス詳細	業務プロセス詳細は BPMN で補完

この比較で差が生じる根本的理由は、「解こうとする問題の高さ」が異なるからである。UML・BPMN は一つのレイヤー内部の精密性を追求するため表現力が深い代わりに全社俯瞰が難しく、ArchiMate は全レイヤー俯瞰を追求するためレイヤー内部の細密な描写は相対的に浅い。実務的含意は明確である。両者は競争ではなく役割分担であり、ArchiMate で全社の地形を描いたのち、特定アプリケーションの内部は UML クラス・シーケンスで、特定業務の詳細な流れは BPMN で「拡大」する階層的文書化が推奨される。同様に ArchiMate(表記)・TOGAF(手順)・Zachman(分類)は、それぞれ異なる問い(「どう描くか・どの手順で作るか・何を分類するか」)に答えるため、併用するときに相乗効果が生まれる。

6. 深化 — 最新動向と実務適用

ArchiMate の最新バージョンは 2022 年に発表された3.2である。3.2 はバリューストリーム(value stream)・ケイパビリティ要素を戦略レイヤーでより精緻に扱えるよう改善し、方向性ある関連(directed association)の表記を明確にするなど表現力を補った。それ以前の 3.0(2016)が戦略・物理要素を導入したのが最大の構造的拡張であり、3.1(2019)・3.2(2022)はこれを磨く性格が強い。バージョンの詳細は The Open Group 仕様を根拠に確認するのが正確であり、細部の表記規則は改訂されうるため、断定より「現行仕様の確認」を前提に扱うのが安全である。

ツールエコシステムも成熟している。オープンソースの Archi をはじめ商用 EA ツールが ArchiMate を支援し、標準交換フォーマット(Model Exchange File Format)でツール間のモデル移動が可能である。近年はアーキテクチャモデルをコードのように管理(Architecture-as-Code)する流れの中で、テキストベースの DSL で ArchiMate モデルを記述し、構成管理(Git)と CI に連動して変更履歴を追う方式が実務で広がっている。これはアーキテクチャ成果物を「静的な報告文書」ではなく「生きたリポジトリ」として運用しようとする指向と接する。

実務適用の観点で、ArchiMate は特にデジタル変革・クラウド移行・レガシー現代化事業で影響分析ツールとして有用である。たとえばある公共機関がオンプレミスシステム 30 余種をクラウドへ移す際、ArchiMate モデルで各アプリケーションコンポーネントが実現する業務サービスと消費する技術サービスを追えば、「先に移してよい独立システム」と「強く結合され一緒に移すべき束」を識別できる。また実装・移行レイヤーのプラトー(plateau)・作業パッケージ要素で、現在(As-Is)から目標(To-Be)へ向かう移行段階をモデリングし、ロードマップとアーキテクチャを一つに連結できる。ただしすべての組織が全レイヤーを精密にモデリングする必要はなく、過度なモデリングはコストのみを膨らませるため、目的(影響分析・疎通・ロードマップ)に合う範囲へ適正化するのが現実的である。

7. 考慮事項および示唆点(技術士の観点)

• 適用戦略 — 目的主導の適正モデリング: ArchiMate は「全社を漏れなく描く」という完全性より、「どの意思決定を支援するか」という目的から出発すべきである。影響分析・現代化範囲の識別・ビジネス-IT 整合などの目的をまず定め、それに必要なレイヤー・ビューポイントのみを選択的にモデリングすることが過投資を防ぐ鍵である。
• トレードオフ — 全社俯瞰 対 レイヤー内の精密性: レイヤーを横断する俯瞰を得る代償として、各レイヤー内部の描写は浅くなる。したがって ArchiMate 単独で完結しようとするより、UML・BPMN・ERD などの専用表記で詳細を補完する階層的文書化戦略が望ましい。
• 連携技術 — 方法論・分類・ガバナンスとの結合: 表記法である ArchiMate は、TOGAF ADM(手順)、Zachman(分類)、EA ガバナンス(原則・審議)、構成管理・モデルリポジトリ(単一の真実の源)と結合してこそ実効がある。特に単一モデルリポジトリを維持してこそ、ビューが増えても整合性と影響分析能力が保存される。
• 展望 — Architecture-as-Code と知識グラフへの拡張: モデルをテキスト・コードとして扱い CI/構成管理に連動させ、要素-関係グラフを組織知識グラフ・データカタログと連携させようとする流れが観察される。これはアーキテクチャを生きた資産として運用しようとする方向であるが、標準化されていない試みであるため、方向性の水準で理解するのが適切である。
• リスク — 報告用の図への形式化への警戒: ArchiMate モデルが現実と遊離した死文書になれば価値は消える。運用実体との整合を定期的に検証し、アーキテクチャを実際の意思決定(投資・現代化・規制対応)に用いるガバナンスループを確保しなければならない。
• 組織能力 — 表記の習熟とステークホルダー参加: 関係の意味を正確に守らなければ、モデルは「きれいな四角の図」に成り下がる。アーキテクトの表記習熟、ステークホルダー別ビューポイントの合意、そしてモデルを読み意思決定に用いる組織文化が揃ってこそ、ArchiMate は初めて機能する。

参考資料

• The Open Group, "ArchiMate 3.2 Specification" — https://pubs.opengroup.org/architecture/archimate3-doc/
• The Open Group, ArchiMate Overview — https://www.opengroup.org/archimate-forum/archimate-overview
• Archi(オープンソース ArchiMate モデリングツール) — https://www.archimatetool.com/

---

一言まとめ: ArchiMate は The Open Group のオープン標準であり、戦略・業務・アプリケーション・技術の全レイヤーを「レイヤー × アスペクト」と形式定義された要素・関係で一貫して描き、レイヤー間のトレースと影響分析を可能にする EA モデリング言語であって、手順(TOGAF)・分類(Zachman)・専用表記(UML・BPMN)と結合して用いるときに真価を発揮する。