本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「エンタープライズアーキテクチャ」カテゴリ第4弾として、EA観点のアプリケーションアーキテクチャ（AA）について解説する記事です。
アプリケーションアーキテクチャ章（25系）が「1システムの内部設計」を扱うのに対し、本記事は「自社に何があるか」を扱います。例えば「部署AとBのシステムを統合するか」が本記事、「統合後のコードをどう設計するか」が25系。本記事ではアプリケーションポートフォリオ管理・Buy/Build/Subscribe判断・連携パターン・廃止計画まで、CIO・IT戦略部門向けに扱います。
本記事のテーマについてさらに詳しく知りたい方は『アーキテクトの教科書』も参考にしてみてください。
この記事の結論
- 全社のシステム台帳をポートフォリオとして地図化する
- SaaSファーストで差別化領域に集中する
- TIME評価で計画的に廃止（Sunset）する
この記事を読む前に
本記事は会社全体のシステムをどう整理するかという話が中心で、技術用語は比較的少なめです。とは言っても、Webサービスの基本構造を知っていると読みやすくなりますので、不安な方は基礎編の「Webサービスが動く仕組み」からどうぞ。また、読んでいて分からない用語が出てきたときは用語集で調べながら読み進められます。
そもそもEA観点のアプリケーションアーキテクチャとは何か
マンション群の全体管理を想像してください。1棟1棟の内部設計（間取り・配管）は個別の建築設計ですが、「この地域に何棟あるか」「老朽化した棟はどれか」「新築と建替えどちらが得か」を判断するのは群全体の管理です。
EA観点のアプリケーションアーキテクチャ（AA）は、企業全体で稼働している全システムの地図を描く領域です。基幹システム・業務システム・SaaS・自社開発・パッケージ──大企業なら数百〜数千のシステムが動いています。個別システムの設計が「1システムの内部構造」を扱うのに対し、AAは「自社に何があるか」を俯瞰します。
もしAAがなければ、重複システムへの二重投資やシャドーITが蔓延し、全社のIT資産が把握不能になります。「自社に何があるか」に即答できない時点で、既に管理が破綻し始めていると言えます。
なぜAAが必要か
第一に、システム重複と無駄投資の防止です。部署ごとに似たシステムを買う重複は、大企業で年間数億円の無駄を生みます。第二に、老朽化システムの棚卸しです。「使っているかわからないサーバー」「作者不明のシステム」は大企業に必ずあり、運用コストを食い、セキュリティ穴にもなります。第三に、新システム投入の整合性です。既存システムとの連携を考慮せずに新システムを入れると統合地獄になります。
アプリケーションポートフォリオ — AAの出発点
全社システムのカタログがAAの出発点です。全システムに以下の基本情報を持たせます。
| 属性 | 例 |
|---|---|
| 名称・分類 | CRM・SFA・ERP／基幹・業務・分析・SaaS |
| 所有者 | 業務部門・IT 部門 |
| 利用者数 | 月間アクティブユーザー |
| 技術スタック | 言語・FW・DB |
| 運用コスト | ライセンス・運用費 |
| SLA | 可用性目標 |
| ライフサイクル | 新規／成長／維持／廃止 |
数十規模ならExcelで十分、100〜500なら専用ツール（LeanIX・Ardoq）、500超はエンタープライズEAツール（Mega・BiZZdesign）が必要になります。
これに加えて、BAのケイパビリティマップとアプリを結びつけた機能マップ（このケイパビリティはどのシステムで実装されているか）で空白・重複・競合を発見し、インターフェイスマップでシステム間の連携を可視化します。
ケイパビリティ システム
─────────────────────────────
顧客管理 ───── CRM_A, CRM_B ← 重複
営業支援 ───── SFA
在庫管理 ───── WMS, ERP ← 重複
商品企画 ───── （なし） ← 空白連携方式はAPI（リアルタイム・疎結合）とイベント駆動（非同期・耐障害）が推奨で、ファイル連携はレガシーバッチ、DB共有は強結合で変更不能になる現代の悪手です。API・イベント経由に移行すべきパターンです。
ライフサイクル管理とTIME評価
アプリには寿命があります。導入→成長→成熟→衰退→廃止というライフサイクルを意識し、計画的に更新・廃止する必要があります。廃止は実行が極めて難しいタスクで、「使っていないはず」でも現場で使われていて止められないことがあり、計画的なSunset（日没）運用が重要です。
やめる判断を合理化する強力なツールが、GartnerのTIMEモデルです。「ビジネス価値」「技術的価値」の2軸でアプリを分類します。
| 評価 | ビジネス価値 | 技術的価値 | アクション |
|---|---|---|---|
| Tolerate | 高 | 低 | 現状維持 |
| Invest | 高 | 高 | 継続投資 |
| Migrate | 低 | 高 | 新基盤へ移行 |
| Eliminate | 低 | 低 | 廃止 |
年次でTIME評価を実施し、Eliminate対象を年10システムずつ廃止するSunset計画を運用するのが中堅以上の定石です。
SaaSファーストと統合パターン
現代のAAはSaaSと内製の組み合わせで設計されます。「差別化領域は内製・共通領域はSaaS」が基本戦略です。基幹会計・ERPはSAP / freee、CRM / SFAはSalesforce / HubSpot、人事労務はWorkday / SmartHRといったSaaSに任せ、内製リソースは差別化サービスに集中させます。
実務では「SaaS + 内製拡張」の組み合わせが現実的です。顧客管理はSalesforceを導入してコア機能は使い回しつつ、業界特化の商談プロセス（製薬業なら医師訪問の規制ワークフロー等）はApexや外部連携で独自ロジックとして実装する。汎用会計はSaaSに任せる一方、自社の強みとなる価格設計アルゴリズムは内製してAPI連携で差し込む。SaaSが用意する拡張ポイント（API・カスタムオブジェクト・Webhook）の上に自社固有のロジックを乗せるのが、差別化と効率化を両立する実装パターンです。
システム間の統合は、現代ではiPaaS（MuleSoft・Workato・Zapier等、SaaS統合をローコードで実現）が主流です。スタートアップならZapier / Makeで十分、月数百件の連携が発生してから本格iPaaSを検討します。クラウド移行の判断には6Rフレームワーク（Retain現状維持 / Retire廃止 / Rehostリフト / Replatform調整 / Refactor改造 / Repurchase＝SaaS置換）が標準的な判断基準です。
M&A・事業統合中の企業では、両社AAの突合→重複システム統廃合ロードマップ→TIME評価で残すシステムを決定、という分析が統合成否を左右します。DAのMDMと連動してマスタ統合を並行実施します。
AAポートフォリオ管理の数値Gate
※ 2026年4月時点の業界相場値です。テクノロジー・人材市場の変化で陳腐化するため、定期的にアップデートが必要です。
AAは全システムを棚卸しして数値で追うのが実務です。
| 指標 | 推奨値 | 超えたらどうするか |
|---|---|---|
| 所有者不明システム率 | 0% | 緊急に棚卸し |
| 機能重複率 | 5%以下 | 統合計画を立案 |
| 最後のデプロイ5年超 | 棚卸し対象 | TIME 評価で Eliminate 候補 |
| 年次廃止システム数 | 全体の5〜10% | Sunset 計画を運用 |
| Shadow IT 検出率（年次） | 全システムの10%以下 | CASB で継続監視 |
| API化率（全システム中） | 70%以上 | DB 共有から API 化へ |
| SaaS／内製比率 | 共通領域7割SaaS | SaaS ファースト原則 |
大企業で棚卸しすると「所有者不明52件・デプロイ7年前30件超」のような事例が頻出で、地道な棚卸しこそAA運用の土台です。
AI判断軸 ― 「AIが使えるシステム群」への進化
API化されていないシステムはAI時代に取り残される
AIエージェントがシステムを「使う」には、APIが存在する必要があります。画面操作でしかアクセスできないレガシーシステムは、AIエージェントからは操作できません。RPAでUI操作を自動化する方法もありますが、脆弱でメンテナンスコストが高いです。レガシーシステムのAPI化（ストラングラーパターンでの段階移行）は、AI活用のための最低限のインフラ投資として優先度を上げるべきです。
AIエージェントがシステム間連携を自律実行する構成
全社システムがAPI + OIDC認証で統一されていれば、AIエージェントは「顧客管理システムから情報取得→在庫システムに確認→注文システムに発注」のような横断処理を自律的に実行できます。AI駆動開発で既存システムへのラッパー・統合を素早く作れるため、システム統合コストも劇的に下がっています。「AIが使えるシステムか」が、AAの新しい評価軸です。
やってはいけないこと
AAで事故る典型を、特に危険な6つに絞ります。どれも知らない間に無駄が累積する構造を持ちます。
| 禁じ手 | なぜダメか → どうするか |
|---|---|
| 棚卸しせず「何があるか」を把握しない | 所有者不明52件という現実 → まずポートフォリオを作る |
| システム間連携にDB共有を使い続ける | 強結合で変更不能に → API / イベント駆動へ段階置換する |
| 全部内製神話を捨てられない | SaaSで済む領域に開発リソースが溶ける → 差別化領域だけ内製する |
| TIME評価でEliminate候補を実際に廃止しない | ライセンス・保守費が数億円積み上がる → 年5〜10%の廃止をSunset計画化する |
| EAツール（LeanIX等）を入れただけで放置 | データ維持体制なしで1年で陳腐化 → 収集・更新の運用をセットにする |
| M&A時に両社AAを突合せずシステム統合 | 重複・矛盾で数年の統合プロジェクトに → TIME評価で残すシステムを先に決める |
なお「システムは多いほど業務が強い」という考えも逆です。多すぎると連携不能で価値が下がり、統合・廃止こそが重要スキルです。
筆者メモ — 「棚卸ししたら半分が幽霊」だった事例
ある大企業のIT部門が全社システムの棚卸しを実施したところ、稼働中と申告されていた487システムのうち、52件が所有者不明、30件以上は最後のデプロイが7年前、という状況が浮かび上がった、という話は業界で繰り返し語り草になっています。さらに部署Aと部署Bが全く同じ機能のシステムを別々のSIerに発注していて、隣のフロアで別のベンダーが常駐している──という笑えない実例もよく報告されます。年間ライセンス料と保守費だけで数億円が消えていたことが後から判明する、という流れが典型的な展開です。
もう一つ、British Airwaysの2017年大規模障害は、密結合レガシーの危険を示す事例として引用され続けます。チェックインシステムが停電復旧時の電源投入手順ミスをきっかけに全システム連鎖停止、全世界で3日間、約75,000人の乗客に影響、推定損害額は1億ポンド超。原因を掘ると、密結合された20年来のレガシー群が電源復旧時の依存関係で連鎖失敗したことが判明しました。「AAを可視化しないまま運用していた代償」を示す象徴事例です。
どちらも「地図を持っていない組織」は、重複投資でも連鎖障害でも、予告なく打撃を受け続けることを突きつけます。
決めるべきこと — 自分のプロジェクトでの答えは？
以下の項目について、自分のプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。
- アプリケーション目録（全システム棚卸し）
- 機能マップ（ケイパビリティとの紐付け）
- インターフェイスマップ（連携の可視化）
- ライフサイクル評価（TIME分類）
- 統合パターン（iPaaS採用等）
- クラウド戦略（6R分析）
- EAツール（LeanIX・Ardoq等）
この記事に関連する記事
まとめ
本記事はEA観点のアプリケーションアーキテクチャについて、ポートフォリオ・機能マップ・TIME・SaaSファースト・iPaaS・6R戦略・AI時代のAPI疎結合まで含めて解説しました。如何だったでしょうか。
規模に応じたツール選定、SaaSファーストで差別化に集中、TIME評価で計画的Sunset、API中心の疎結合に寄せる。これが2026年のEA観点AAの現実解です。
次回はテクノロジーアーキテクチャ（TA）（クラウド標準・技術リファレンス）について解説します。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
本記事で扱った内容の詳細は AWS アーキテクチャセンター も合わせて参考にしてください。
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（78/95）