本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「エンタープライズアーキテクチャ」カテゴリ第4弾として、EA観点のアプリケーションアーキテクチャ（AA）について解説する記事です。
アプリケーションアーキテクチャ章（25系）が「1システムの内部設計」を扱うのに対し、本記事は「自社に何があるか」を扱います。例えば「部署AとBのシステムを統合するか」が本記事、「統合後のコードをどう設計するか」が25系。本記事ではアプリケーションポートフォリオ管理・Buy/Build/Subscribe判断・連携パターン・廃止計画まで、CIO・IT戦略部門向けに扱います。
このカテゴリの他の記事
「自社に何があるか」に即答できない会社は、既に迷子
EA の3番目のレイヤー（AA）で、企業全体で稼働している全アプリケーションの構造・関係・役割を体系化します。個別システムの設計とは視点が違い、企業に存在する全システムの地図を描きます。
「基幹システム・業務システム・SaaS・自社開発・パッケージ」──大企業なら数百〜数千のシステムが動いています。これらの全体像を把握しないと、重複投資・連携不良・シャドーITが蔓延します。EA の AA はアプリケーションポートフォリオ管理の基盤です。
AA がない企業は自社に何があるかわからない。まず地図を作ります。
なぜAAが必要か
システム重複と無駄投資の防止
部署ごとに似たシステムを買う重複は、大企業で年間数億円の無駄を生みます。AA が整備されていれば、重複を検知し統合できます。
老朽化システムの棚卸し
「使っているかわからないサーバー」「作者不明のシステム」は大企業に必ずあります。運用コストを食い、セキュリティ穴にもなります。AA が可視化の前提です。
新システム投入の整合性
新しいシステムを入れる時、既存システムとの連携を考慮しないと統合地獄になります。AA で全体最適を判断します。
AAの主要構成要素
EA の AA は複数の視点で全社アプリを整理します。単に一覧するだけでなく、関係・役割・ライフサイクルを含む立体的な把握が必要です。
| 要素 | 内容 |
|---|---|
| アプリケーション目録 | 全システムの一覧 |
| 機能マップ | どの能力を実装しているか |
| インターフェイスマップ | システム間の連携 |
| ライフサイクル | 新規・維持・廃止 |
| 技術スタック | 使用言語・FW・DB |
| 運用情報 | SLA（Service Level Agreement＝サービス品質保証契約）・所有者・コスト |
アプリケーションポートフォリオ
全社システムのカタログで、EA の AA の出発点です。Excel・専用ツール（LeanIX・Ardoq 等）で管理し、全システムに対する基本情報を持たせます。
quadrantChart
title アプリケーションポートフォリオ評価 (TIMEモデル)
x-axis 業務価値 低 --> 業務価値 高
y-axis 技術品質 低 --> 技術品質 高
quadrant-1 Invest (投資)
quadrant-2 Migrate (移行)
quadrant-3 Eliminate (廃止)
quadrant-4 Tolerate (現状維持)
新CRM: [0.8, 0.9]
旧基幹: [0.7, 0.2]
シャドーIT(個人ツール): [0.2, 0.3]
社内Wiki: [0.4, 0.7]
レガシーEDI: [0.6, 0.1]| 属性 | 例 |
|---|---|
| 名称 | CRM・SFA・ERP 等 |
| 分類 | 基幹／業務／分析／SaaS |
| 所有者 | 業務部門・IT 部門 |
| 利用者数 | 月間アクティブユーザー |
| 技術スタック | 言語・FW・DB |
| 運用コスト | ライセンス・運用費 |
| SLA | 可用性目標 |
| ライフサイクル | 新規／成長／維持／廃止 |
数百〜数千のシステムを管理する組織では、専用ツール（LeanIX・Ardoq・Mega）が必須になります。
機能マップ
BA のケイパビリティマップと AA のアプリを結びつけた地図です。このケイパビリティは、どのシステムで実装されているかを可視化し、空白・重複・競合を発見します。
ケイパビリティ システム
─────────────────────────────
顧客管理 ───── CRM_A, CRM_B ← 重複
営業支援 ───── SFA
在庫管理 ───── WMS, ERP ← 重複
商品企画 ───── （なし） ← 空白重複と空白が可視化されれば、統合や新規投資の判断ができます。「この能力は機能Aで実現」と明確に示せる状態が理想です。
インターフェイスマップ
システム間の連携（API・ファイル・DB 共有）を可視化します。1つのシステムが何を送受信するかが明確になると、影響範囲・障害波及が予測できます。
ファイル API
[ERP] ──────▶ [DWH] ◀────── [EC] ※DWH＝Data Warehouse（分析用の統合データベース）
│ │
│ │
└──────── 在庫同期 ────────┘| 連携方式 | 特徴 |
|---|---|
| API（REST／GraphQL） | リアルタイム・疎結合 |
| イベント駆動（Kafka等） | 非同期・耐障害 |
| ファイル連携（CSV等） | バッチ・レガシー |
| DB共有 | 強結合・避けるべき |
DB共有は現代では悪手で、API・イベント経由に移行すべきパターンです。
ライフサイクル管理
アプリには寿命があります。導入 → 成長 → 成熟 → 衰退 → 廃止というライフサイクルを意識し、計画的に更新・廃止する必要があります。これがないとレガシーが蓄積します。
| フェーズ | 管理ポイント |
|---|---|
| 導入 | PoC（Proof of Concept＝概念実証、試験導入）・Go／No-Go 判定 |
| 成長 | 採用拡大・SLA 強化 |
| 成熟 | 運用最適化 |
| 衰退 | 後継検討 |
| 廃止 | データ移行・サービス終了 |
廃止は実行が極めて難しいタスクで、「使っていないはず」でも現場で使われていて止められないことがあります。計画的なSunset（日没）運用が重要です。
アプリケーション評価（TIME）
各アプリを4つの象限で評価するフレームワークが Gartner の TIMEモデルです。「技術的価値」「ビジネス価値」の2軸でアプリを分類し、投資判断に使います。
| 評価 | ビジネス価値 | 技術的価値 | アクション |
|---|---|---|---|
| Tolerate | 高 | 低 | 現状維持 |
| Invest | 高 | 高 | 継続投資 |
| Migrate | 低 | 高 | 新基盤へ移行 |
| Eliminate | 低 | 低 | 廃止 |
Gartner の TIME はやめる判断を合理化する強力なツールで、レガシーシステムの整理に使われます。
SaaSと内製の使い分け
現代の AA は SaaSと内製の組み合わせで設計されます。「差別化領域は内製・共通領域はSaaS」が基本戦略で、内製比率を下げて開発リソースを差別化に集中させるのが定石です。
| 領域 | 推奨 |
|---|---|
| 基幹会計・ERP | SaaS（SAP・Oracle・freee 等） |
| CRM・SFA | SaaS（Salesforce・HubSpot） |
| 人事労務 | SaaS（Workday・SmartHR） |
| 差別化サービス | 内製 |
| AI・データ分析 | SaaS 基盤 + 内製ロジック |
実務では「SaaS + 内製拡張」の組み合わせが現実的です。例えば顧客管理は Salesforce を導入してコア機能は使い回しつつ、業界特化の商談プロセス（製薬業なら医師訪問の規制ワークフロー、製造業なら見積から仕様確定までの多段承認など）は Apex や外部連携で独自ロジックとして実装します。同様に汎用会計は freee／SAP に任せる一方、自社の強みとなる価格設計アルゴリズム（需要予測ベースのダイナミックプライシング、顧客セグメント別の最適化モデルなど）は内製して SaaS に API 連携で差し込みます。全部内製も SaaS で完結もせず、SaaSが用意する拡張ポイント（API・カスタムオブジェクト・Webhook）の上に自社固有のロジックを乗せるのが、差別化と効率化を両立する実装パターンです。
「内製しなければならない」思想を捨てるのが現代的で、SaaS ファーストが標準になっています。
統合パターン
システム間の統合には複数のパターンがあります。用途・頻度・リアルタイム要求に応じて選びます。
| パターン | 特徴 |
|---|---|
| Point-to-Point | 直接連携・シンプル |
| Hub & Spoke | 中央ハブ経由 |
| ESB（Enterprise Service Bus） | 統合基盤・古典 |
| iPaaS（Integration PaaS） | SaaS 統合の現代解 |
| イベント駆動 | 疎結合・スケーラブル |
| Data Integration | バッチ統合 |
iPaaS（MuleSoft・Dell Boomi・Workato・Zapier）が現代の主流で、SaaS 統合をローコードで実現できます。
クラウド戦略とAA
AA はクラウド戦略と密接に連動します。どのシステムをいつクラウドに移すかを全体計画として持つ必要があります。6Rフレームワークが標準的な判断基準です。
| 6R | 内容 |
|---|---|
| Retain（現状維持） | クラウドに移さない |
| Retire（廃止） | 使っていないなら捨てる |
| Rehost（リフト） | そのまま移設 |
| Replatform（調整） | 小変更で移設 |
| Refactor（改造） | クラウドネイティブ化 |
| Repurchase（再購入） | SaaS に置き換え |
判断基準①:システム数
AA の整備コストはシステム数で決まります。数十規模なら Excel で十分、数百以上なら専用ツール必須です。
| システム数 | 推奨 |
|---|---|
| 〜30 | Excel／スプレッドシート |
| 30〜100 | Notion／Confluence + 図 |
| 100〜500 | LeanIX／Ardoq |
| 500+ | エンタープライズEAツール |
判断基準②:変革の必要性
DX・クラウド移行・M&Aを実行している企業は、AA が変革の成否を左右します。定常運用の企業では最小限で十分です。
| 変革度 | 推奨 |
|---|---|
| 定常運用 | 年次棚卸しで十分 |
| DX中 | AS-IS／TO-BE 詳細化 |
| M&A | 両社 AA 統合分析必須 |
| クラウド移行 | 6R 分析の事前実施 |
ケース別の選び方
スタートアップ・SaaS中心（〜30システム）
スプレッドシート1枚 + Zapier／Make で SaaS 連携。TIME 分析は不要、新しい SaaS 導入時だけ既存との重複をチェック。iPaaS 導入は月数百件の連携が発生してから。
中堅企業・DX推進中（100〜300システム）
LeanIX or Ardoq + 機能マップ作成 + 年次 TIME 棚卸し。EA 担当1〜2名で維持、iPaaS は MuleSoft／Workato でハブ化、Eliminate 対象を年10システムずつ廃止する Sunset 計画を運用します。
大企業・レガシー多数（500+システム）
エンタープライズEAツール（Mega／BiZZdesign）+ 専門 EA チーム + 6R 分析。アプリケーションポートフォリオ管理（APM）を専任化、クラウド移行計画と連動させる。DB 共有連携を API／イベント駆動に段階置換。
M&A・事業統合中
両社 AA 突合 + 重複システム統廃合ロードマップ + マスタ整合。TIME 評価で残すシステムを決定、iPaaS で過渡期の接続、データアーキテクチャの MDM（Master Data Management＝顧客・商品等の基準データの一元管理）と連動してマスタ統合を並行実施。
よくある勘違い
システムは多いほど業務が強い
逆です。多すぎると連携不能で価値が下がる。統合・廃止が重要スキル。
全部内製が誇り
内製神話は時代遅れ。SaaSで済む領域はSaaS。内製リソースは差別化に集中します。
インテグレーションはAPIさえあれば簡単
甘い。認証・エラー処理・スキーマ変化で泥沼化します。iPaaS の価値を過小評価しない。
EAツールを入れればAA完成
ツールは入れ物。データ収集・維持体制がないと陳腐化します。
大企業でアプリケーションポートフォリオの棚卸しをすると、最終的に Excel に並ぶのは487システム──そのうち「所有者不明」が52件、「最後のデプロイが7年前」が30件以上、という事例が報告されています。極めつけは、部署 A と部署 B が全く同じ機能のシステムを別々のSIerに発注して、隣り合うフロアで別のベンダーが常駐している、というケースもあります。「地図がない」とは、こういう光景を生むということを示す事例です。
AAポートフォリオ管理の数値Gate
※ 2026年4月時点の業界相場値です。テクノロジー・人材市場の変化で陳腐化するため、定期的にアップデートが必要です。
AA は全システムを棚卸しして数値で追うのが実務。以下が業界定番の管理指標です。
| 指標 | 推奨値 | 超えたらどうするか |
|---|---|---|
| 所有者不明システム率 | 0%（全て所有者を特定） | 緊急に棚卸し |
| 機能重複率 | 5%以下 | 統合計画を立案 |
| 最後のデプロイ5年超 | 棚卸し対象 | TIME 評価で Eliminate 候補 |
| 年次廃止システム数 | 全体の5〜10% | Sunset 計画を運用 |
| 新規システム投入前 PRR 実施率 | 100% | 未実施は本番投入禁止 |
| Shadow IT 検出率（年次） | 全システムの10%以下 | CASB で継続監視 |
| 平均システム寿命 | 7〜10年 | 更新計画に反映 |
| API化率（全システム中） | 70%以上 | DB 共有から API 化へ |
| SaaS／内製比率 | 共通領域7割SaaS | SaaS ファースト原則 |
TIME評価（Tolerate／Invest／Migrate／Eliminate）は年次実施が標準です。「大企業で棚卸しすると所有者不明52件・デプロイ7年前30件超」のような事例が頻出で、地道な棚卸しこそ AA 運用の土台です。
AA は「地図を持たない組織は迷子」数値で管理しないと重複投資が累積します。
AA運用の鬼門・禁じ手
AA で事故る典型パターン。どれも知らない間に無駄が累積する構造を持ちます。
| 禁じ手 | なぜダメか |
|---|---|
| 棚卸しせず「何があるか」を把握しない | 所有者不明52件・デプロイ7年前30件超という現実 |
| システム間連携にDB共有を使い続ける | 強結合、変更不能、British Airways 2017年障害（全世界3日停止、1億ポンド超損失）のパターン |
| 全部内製神話を捨てられない | SaaS で済む領域も自前開発、差別化領域にリソースが集中しない |
| EAツール（LeanIX等）を入れただけで放置 | データ収集・維持体制なし、1年で陳腐化 |
| 新システム投入時にPRRなし | 監視・SLO・Runbook 未整備のシステムが本番投入 |
| 機能マップを作らない | 空白（欠けている能力）・重複（同じ能力を複数システムで実装）が見えない |
| TIME評価でEliminate候補を実際に廃止しない | 年間ライセンス料・保守費が積み上がり数億円の無駄 |
| Shadow ITを放置 | 部署が勝手に SaaS 契約、セキュリティ穴が広がる |
| インフラをリフト＆シフトだけでクラウド移行 | オンプレのアーキを持ち込みコスト増、6R 分析で Refactor を判断 |
| M&A時に両社AAを突合せずシステム統合 | 重複／矛盾で数年の統合プロジェクト、費用爆発 |
2017年British Airways大規模障害（チェックインシステム停電復旧時の電源投入手順ミスで全システム連鎖停止、全世界3日間・7.5万人影響・1億ポンド超損失）は、AAを可視化しないまま運用していた代償を示した象徴事例です。
AA は地図を持たない組織は迷子。棚卸しと TIME 評価で計画的に廃止します。
AI時代の視点
AI 駆動開発（バイブコーディング）と AI 活用が前提になると、AA はAIで作れる・壊せるシステム群として再定義されます。AI 駆動で既存システムに対するラッパー・統合を素早く作れるため、「システム統合コスト」が劇的に下がります。
| AI時代に有利 | AI時代に不利 |
|---|---|
| API中心の疎結合 | 密結合のレガシー |
| SaaSファースト | スクラッチ自前 |
| ドキュメント・メタデータ充実 | 暗黙知に依存 |
| 標準プロトコル（OAuth／OIDC＝OpenID Connect、認証認可の業界標準） | 独自プロトコル |
AI エージェント自身が企業システムを使うユーザーになる時代も近く、API 化されていないシステムは AI の時代に取り残されます。AIが使えるシステムかが新しい評価軸になります。
AI 時代の AA はAPIで繋がっているかが価値を決める。レガシーはラッパーで拡張します。
決めるべきこと — あなたのプロジェクトでの答えは？
以下の項目について、あなたのプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。
- アプリケーション目録（全システム棚卸し）
- 機能マップ（ケイパビリティとの紐付け）
- インターフェイスマップ（連携の可視化）
- ライフサイクル評価（TIME 分類）
- 統合パターン（iPaaS 採用等）
- クラウド戦略（6R 分析）
- EAツール（LeanIX・Ardoq 等）
筆者メモ — 「棚卸ししたら半分が幽霊」だった事例
アプリケーションポートフォリオの棚卸しを初めて本気でやると、多くの大企業が我が身のレガシー資産の惨状に衝撃を受けます。
ある大企業の IT 部門が全社システムの棚卸しを実施したところ、稼働中と申告されていた487システムのうち、52件が所有者不明、30件以上は最後のデプロイが7年前、という状況が浮かび上がった、という話は業界で繰り返し語り草になっています。さらに部署 A と部署 B が全く同じ機能のシステムを別々の SIer に発注していて、隣のフロアで別のベンダーが常駐している──という笑えない実例もよく報告されます。年間ライセンス料と保守費だけで数億円が消えていたことが後から判明し、経営が「我が社のIT資産は誰が見ていたのか」と問題視する、という流れが典型的な展開です。
もう一つ、British Airwaysの2017年大規模障害は、密結合レガシーの危険を示す事例として引用され続けます。2017年5月、BA のチェックインシステムが停電復旧時の電源投入手順ミスをきっかけに全システム連鎖停止、全世界で3日間、約75,000人の乗客に影響、推定損害額は1億ポンド超。原因を掘ると、密結合された20年来のレガシー群が電源復旧時の依存関係で連鎖失敗したことが判明しました。「AAを可視化しないまま運用していた代償」を示す象徴事例として今でも参照されます。
どちらも「地図を持っていない組織」は、重複投資でも連鎖障害でも、予告なく打撃を受け続けることを突きつけます。
最終的な判断の仕方
EA 観点の AA の核心は自社に何があるかを地図にするという発想です。大企業は数百〜数千のシステムを抱え、重複・空白・シャドーIT が年間数億円の無駄を生みます。アプリケーションポートフォリオを整備し、機能マップでケイパビリティとの紐付けを可視化し、TIME モデルで「やめる判断」を合理化するのが EA 観点の AA の仕事です。内製神話を捨て、SaaS ファーストで差別化領域だけ内製、iPaaS・API で統合するのが現代の定石です。DB 共有連携は悪手で、API・イベント駆動に置換するのが標準になりました。
もう一つの決定的な軸はAIエージェントが使えるシステム群への進化です。AI 駆動開発でシステム統合コストは劇的に下がり、AI エージェント自身が企業システムの新しいユーザーになります。API 化・OAuth／OIDC 標準・メタデータ充実のシステム群は AI に拡張され、密結合レガシー・独自プロトコルは取り残されます。「AIが使えるか」が新しい評価軸です。
選定の優先順位
- 規模に応じたツール選定 — 〜30は Excel、100〜500は LeanIX、500+ は専用 EA ツール
- SaaSファーストで差別化に集中 — 共通領域はSaaS、内製は競争領域だけ
- TIME評価で計画的Sunset — 年10システムずつ廃止、レガシー蓄積を防ぐ
- API中心の疎結合 — DB 共有から API／イベント駆動、AI 時代の統合土台
「AIが使えるAAか」が価値を決める。SaaS ファースト + API 疎結合で作り直します。
まとめ
本記事はEA観点のアプリケーションアーキテクチャについて、ポートフォリオ・機能マップ・TIME・SaaSファースト・iPaaS・6R戦略・AI時代のAPI疎結合まで含めて解説しました。如何だったでしょうか。
規模に応じたツール選定、SaaSファーストで差別化に集中、TIME評価で計画的Sunset、API中心の疎結合に寄せる。これが2026年のEA観点AAの現実解です。
次回はテクノロジーアーキテクチャ（TA）（クラウド標準・技術リファレンス）について解説します。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（72/89）