本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「エンタープライズアーキテクチャ」カテゴリ第5弾として、EA観点のテクノロジーアーキテクチャ（TA）について解説する記事です。
システムアーキテクチャ章（10系）が「プロジェクトで何を使うか」を扱うのに対し、本記事は「全社で何を許すか・標準とするか」を扱います。例えば「全社標準クラウドを AWS にする」が本記事、「EC2／ECS／Lambda どれを使うか」が10系。本記事ではTechnology Reference Model・Tech Radar・全社標準スタック・SoR/SoE/SoIの分離まで、CIO・IT戦略・インフラ部門長向けに扱います。
このカテゴリの他の記事
技術の自由は、統制の上にしか成り立たない
EA の4番目のレイヤー（TA）で、企業全体の技術基盤（インフラ・ネットワーク・プラットフォーム）を設計・標準化します。個別システム構築時の技術選定とは違い、企業の技術スタンダードを決めるのが役割です。
「どのクラウドを使うか」「社内標準の言語は何か」「DB は何を使うか」──こうした判断を企業全体の規模感で決めるのが TA です。TA がないと、部署ごとに勝手に AWS・Azure・GCP を使い始め、技術スタックが爆発します。
TA は企業の技術選択の憲法。逸脱には正当な理由が必要です。
なぜTAが必要か
技術の多様化がコストを食う
部署ごとに違う技術を使うと、人材流動性が落ち、運用コストが跳ね上がります。標準化することで人材配置・調達・運用を最適化できます。
セキュリティ・コンプライアンス対応
全社で統一されたセキュリティ基準を適用するには、技術スタックの標準化が前提です。バラバラでは監査も対応も不可能です。
スケールメリットの享受
クラウド契約・ライセンス・サポート契約は、集約すればディスカウントが得られます。TA の標準化で数千万円〜数億円のコスト削減が可能です。
TAの主要構成要素
TA は企業全体で使う技術基盤を体系化します。単なる製品リストではなく、選定基準・利用ガイドライン・例外処理まで含めた総合的な設計です。
| 要素 | 内容 |
|---|---|
| クラウド戦略 | 採用クラウド・マルチ／シングル |
| 標準技術スタック | 言語・FW・DB |
| ネットワーク設計 | WAN（Wide Area Network＝広域ネットワーク）・VPN・専用線 |
| セキュリティ基盤 | IAM（Identity and Access Management＝認証認可基盤）・WAF・監視 |
| プラットフォーム | K8s（Kubernetes＝コンテナ管理基盤）・CI/CD（継続的インテグレーション／デリバリー）・オブザーバビリティ |
| エンドユーザ環境 | PC・モバイル・MDM（Mobile Device Management＝モバイル端末管理） |
| 技術標準・ガイドライン | 選定ルール |
クラウド戦略
最も重要な TA の決定事項がクラウド戦略です。マルチクラウドは聞こえは良いですが、運用複雑性が跳ね上がるため、現実的には主クラウド + 補助クラウドが多いです。
| 戦略 | 内容 | 向くケース |
|---|---|---|
| シングルクラウド | 1社に集中 | 中小・スピード重視 |
| プライマリ + セカンダリ | 主従 | リスク分散したい |
| マルチクラウド | 複数に分散 | 大企業・リスク許容 |
| ハイブリッド | オンプレ + クラウド | 移行期・金融等 |
マルチクラウドは運用3倍・コスト2倍が現実で、「やる意義」を明確にしないと負担ばかりで効果が出ません。
標準技術スタック
全社で推奨する言語・フレームワーク・DB を定めるのが標準技術スタックです。複数のスタックを持つ場合もありますが、5〜10個以内に絞るのが運用的に現実的です。
flowchart TB
STD([全社標準スタック])
LANG[サーバ言語<br/>Python / TypeScript / Go]
FE[フロントエンド<br/>React + Next.js]
MOB[モバイル<br/>React Native / Swift]
DB[(DB<br/>PostgreSQL / BigQuery)]
CACHE[(キャッシュ<br/>Redis)]
MQ[メッセージング<br/>Kafka]
INFRA[コンテナ基盤<br/>Kubernetes]
STD --> LANG
STD --> FE
STD --> MOB
STD --> DB
STD --> CACHE
STD --> MQ
STD --> INFRA
BAD[尖った新興言語/<br/>独自FW]
BAD -.|技術委員会で却下| STD
classDef root fill:#fef3c7,stroke:#d97706,stroke-width:2px;
classDef tech fill:#dbeafe,stroke:#2563eb;
classDef bad fill:#fee2e2,stroke:#dc2626;
class STD root;
class LANG,FE,MOB,DB,CACHE,MQ,INFRA tech;
class BAD bad;| 領域 | 例（仮想企業） |
|---|---|
| サーバ言語 | Python、TypeScript、Go |
| フロントエンド | React + Next.js |
| モバイル | React Native、Swift |
| DB | PostgreSQL、BigQuery |
| キャッシュ | Redis |
| メッセージング | Kafka |
| コンテナ | Kubernetes |
「流行りの言語を入れる」と標準が膨れ上がるため、技術委員会で厳格に管理する必要があります。
技術選定プロセス
新しい技術を標準入りさせるフォーマルなプロセスを設けます。個別プロジェクトが勝手に採用するのを防ぎ、評価・検証・合意を経て標準化します。
| ステップ | 内容 |
|---|---|
| 1. 提案 | 誰かが候補技術を提案 |
| 2. PoC | 小規模で検証 |
| 3. 評価 | コスト・運用・人材等 |
| 4. 委員会審査 | 技術委員会で議論 |
| 5. 標準化 | ガイドライン作成 |
| 6. 展開 | 段階的に採用拡大 |
| 7. レビュー | 定期的な見直し |
Technology Radar
ThoughtWorksが提唱した技術トレンドを可視化する手法で、多くの企業が社内版を作っています。採用・試用・評価・保留の4象限で技術を分類し、企業の技術戦略を共有します。
| 象限 | 意味 |
|---|---|
| Adopt（採用） | 標準技術として使う |
| Trial（試用） | プロジェクトで実験 |
| Assess（評価） | 情報収集中 |
| Hold（保留） | 避けるべき |
半期ごとに見直し、技術トレンドを組織に浸透させる仕組みとして機能します。
プラットフォーム（共通基盤）
TA は社内の共通プラットフォームも定義します。各プロジェクトが個別に作るのではなく、共通基盤を使って効率化します。これが Platform Engineering の領域です。
| 共通基盤 | 内容 |
|---|---|
| Kubernetes Platform | 全社コンテナ実行基盤 |
| CI/CD Platform | 統一したデプロイパイプライン |
| Observability Platform | 全社監視基盤 |
| API Gateway | 統一API入口 |
| Identity Platform | 認証・認可基盤 |
| Data Platform | DWH・データレイク |
Internal Developer Platform（IDP）として統合提供するのが現代トレンドで、Backstage が代表的な OSS です。
ネットワーク設計
企業全体のネットワーク構成も TA の範疇です。グローバル WAN・拠点間接続・クラウド接続を体系化します。
| 要素 | 内容 |
|---|---|
| グローバルWAN | 拠点間を繋ぐ |
| SD-WAN | ソフトウェア定義のWAN |
| SASE | セキュリティ統合WAN |
| クラウド接続 | Direct Connect・ExpressRoute |
| VPN／ZTNA（Zero Trust Network Access＝ゼロトラスト方式のリモート接続） | リモートアクセス |
| DNS戦略 | 社内外のDNS管理 |
セキュリティ基盤
全社で統一適用するセキュリティ基盤を TA が定義します。個別プロジェクトが独自に作ると、穴だらけになります。
| 基盤 | 内容 |
|---|---|
| IdP（Identity Provider＝認証基盤） | Okta・Azure AD等 |
| MDM | 端末管理 |
| EDR（Endpoint Detection and Response＝端末の脅威検知と対応） | エンドポイント検知 |
| WAF（Web Application Firewall＝Webアプリ保護） | Web保護 |
| SIEM（セキュリティログ統合分析）／SOC（Security Operation Center） | 監視・対応 |
| CASB（Cloud Access Security Broker＝SaaS利用監視） | SaaS利用管理 |
| SSE／SASE（ネットワーク＋セキュリティ統合サービス） | セキュリティ統合 |
セキュリティの標準化はコンプライアンスと効率性の両面で重要です。
ライフサイクル管理（技術）
技術にもライフサイクルがあります。EOL（End of Life）製品を使い続けるとセキュリティリスクになるため、計画的な更新が必要です。
| 状態 | 対応 |
|---|---|
| 最新 | 推奨採用 |
| サポート中 | 採用可 |
| EOL予告 | 更新計画 |
| EOL済 | 緊急更新必要 |
| EOS（Support終了） | 即対応 |
Windows Server・PostgreSQL・Java──各製品の EOL スケジュールを把握し、先回りして更新計画を立てるのが TA の仕事です。
FinOps（クラウドコスト最適化）
現代 TA の重要領域が FinOps（Financial Operations）です。クラウドコストは放っておくと際限なく増えるため、組織全体で可視化・最適化する仕組みが必要です。
| FinOpsの活動 | 内容 |
|---|---|
| 可視化 | 部署・プロジェクト別コスト |
| 予約インスタンス | 長期契約でディスカウント |
| Spot Instance | 余剰リソース格安利用 |
| オートスケール | 需要に応じた自動縮減 |
| 非稼働時停止 | 夜間・週末停止 |
CloudHealth・Kubecost・CAST AI などの FinOps ツールが普及しています。コスト意識を組織文化として浸透させるのが鍵です。
判断基準①:企業規模
TA の詳細度は企業規模で決まります。スタートアップでは過剰、大企業では必須です。
| 規模 | 推奨 |
|---|---|
| スタートアップ | クラウド1社・言語2〜3個 |
| 中堅 | 標準スタック + 例外ルール |
| 大企業 | フル TA + 技術委員会 |
| グローバル | 地域別TAと全社TAの整合 |
判断基準②:規制・セキュリティ要件
金融・医療・政府系はTAの重装度が跳ね上がります。技術選定も自由度が下がり、許可された製品だけを使う運用になります。
| 業種 | TAの厳しさ |
|---|---|
| 金融・保険 | 極めて厳格（FISC＝金融情報システムセンター安全対策基準 準拠等） |
| 医療 | 極めて厳格（HIPAA＝米国医療情報保護法 等） |
| 政府系 | ホワイトリスト制 |
| 一般企業 | 標準 + 例外処理 |
| スタートアップ | 緩め・速度重視 |
ケース別の選び方
スタートアップ・シングルクラウド
AWS or GCP 1社 + 言語2〜3個 + マネージドサービス活用。TA 委員会は不要、創業 CTO の頭の中が標準。FinOps は CloudHealth 無料枠 or AWS Cost Explorer で月次レビュー、EOL 管理はスプレッドシート1枚。
中堅企業・プライマリ＋セカンダリ
AWS 主 + Azure でセカンダリ + 標準スタック5〜10個 + Technology Radar。EA 兼技術委員会を四半期開催、Backstage で IDP を構築、LLM Gateway は Portkey／LiteLLM で一本化。
大企業・マルチクラウド・規制対応
3クラウド + ホワイトリスト制 + 専門技術委員会 + FinOps チーム。各クラウドに専門チーム、SIEM／SOC 24／7運用、FISC や HIPAA 準拠製品のみ採用。EOL は2年前から移行計画、AI 基盤はオンプレ GPU + 社内 LLM ゲートウェイ。
グローバル大企業
地域別 TA + 全社 TA + データレジデンシー対応。欧州は GDPR（EU一般データ保護規則）準拠スタック、中国は独立クラウド（阿里云等）、共通は Identity Platform と API Gateway で統合。Platform Engineering 組織を中央配置し各地域に専門家配属。
よくある勘違い
技術標準は革新を止める
バランスが重要です。Radarで実験を促しつつ、標準化で安定供給します。
マルチクラウドは安全
運用コストが爆発し、結果的に全部中途半端になることも。目的を明確に。
EOLは来たら対応すればいい
移行には数か月〜年単位。2年前から計画が現実的です。
クラウドは自動で最適化される
逆。放置すると無駄が爆発します。FinOpsは能動的活動。
AWS の月額請求を可視化したら誰も使っていないEC2が47台並んでいて、月額120万円ほど空焚きしていた──という事例が報告されています。犯人は「退職した前任者が PoC で立てたインスタンス」と「検証が終わったのに止め忘れた GPU」クラウドは蛇口を開けっぱなしにすると、静かにプールが水浸しになる。FinOps は「水道メーターを毎日見る人」を置かないと回らない、と示す典型例です。
標準スタック管理の数値Gate
※ 2026年4月時点の業界相場値です。テクノロジー・人材市場の変化で陳腐化するため、定期的にアップデートが必要です。
TA は自由を許しつつ標準で縛るバランスが命。以下が業界定番の管理指標です。
| 指標 | 推奨値 | 超えたらどうするか |
|---|---|---|
| 標準技術スタック数 | 5〜10個以内 | 技術委員会で厳格管理 |
| 使用クラウド数 | 1〜2社（主＋補助） | マルチは運用3倍コスト2倍 |
| EOL 6か月以内の稼働システム | 0件 | 緊急更新計画 |
| Technology Radar更新頻度 | 半期1回 | 陳腐化しない運用 |
| 例外技術承認率 | 10%以下 | 標準外は正当な理由必須 |
| クラウドコスト対売上比 | 5%以下（業種次第） | FinOps で最適化 |
| 未使用リソース率 | 10%以下 | 夜間停止・自動削減 |
| 予約インスタンスカバー率 | 60〜80% | 継続稼働分はコミット契約 |
| パッチ適用SLA（Critical） | 72時間以内 | EOL 放置は絶対禁止 |
| FinOpsレビュー頻度 | 月次 | 請求書を毎月見る習慣 |
マルチクラウドは運用3倍・コスト2倍が現実です。「やる意義」を明確にできないなら、シングルクラウド基調で始めるのが現実解です。月額数百万のクラウドコストは FinOps 専任で月20%の削減が普通で、放置すると請求書爆発で経営が揺らぎます。
マルチクラウドは明確な理由がある時だけ。運用できない規模で選ぶのは破綻ルートです。
TA運用の鬼門・禁じ手
TA で事故る典型パターン。どれも技術憲法なしの代償として企業を傾けます。
| 禁じ手 | なぜダメか |
|---|---|
| 部署ごとにクラウド・言語・DBを選び放題 | 5年で3クラウド6言語4DBが混在、人材流動性ゼロ、運用コスト倍増 |
| EOL来てから対応する | 移行には数か月〜年単位、2年前から計画が現実 |
| クラウド請求書を見ない | 誰も使っていないEC2 47台・月120万円空焚きの事例 |
| 予約インスタンスを買わずオンデマンド固定 | 30〜70%のコスト削減機会を逃す |
| セキュリティ基盤を部署別に構築 | Tesco Bank 2017年の障害パターン、1,640万ポンド罰金 |
| Technology Radarを作らず革新機会を逃す | 標準化の硬直化、エンジニア離職 |
| マルチクラウドを運用体制なしで採用 | 両方中途半端、全部未最適化 |
| AIワークロードを従来TAで扱う | GPU要件・ベクトルDB・LLM Gateway が欠落 |
| LLM APIの利用を野放し | 各部署で個別契約、コスト爆発とガバナンス欠如 |
| Internal Developer Platform（IDP）を作らず各チームが独自運用 | 標準化されず非効率、Backstage 等で統一 |
2017年 Tesco Bank障害（オンラインバンキング全停止48時間、約4万口座不正取引、260万ポンド補償+1,640万ポンド罰金）は、バラバラのセキュリティ基準が攻撃者に抜け穴を残した事例として語り草です。
TA は自由の敵ではなく、持続可能な自由の前提。標準があるから差別化に集中できます。
AI時代の視点
AI 駆動開発（バイブコーディング）と AI 活用が前提になると、TA はAIエージェントの実行基盤としての側面が加わります。AI ワークロードは GPU・メモリ・通信の要件が特殊で、従来の TA では捌けないため、AI特化の基盤設計が必要になっています。
| AI時代に追加 | 内容 |
|---|---|
| GPU基盤 | NVIDIA H100・L4等 |
| ベクトルDB | Pinecone・Weaviate |
| LLM APIゲートウェイ | 中央管理・コスト可視化 |
| プロンプト管理 | 全社で統一管理 |
| AI Observability | LangSmith等 |
LLM API の利用を中央管理し、OpenAI・Anthropic・Gemini の使い分けと課金を統合するAI Gatewayが新しい TA の構成要素です。
AI 時代の TA はGPU・ベクトルDB・LLMを前提にした拡張が必要です。
決めるべきこと — あなたのプロジェクトでの答えは？
以下の項目について、あなたのプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。
- クラウド戦略（シングル／マルチ）
- 標準技術スタック（言語・FW・DB）
- 技術選定プロセス（Radar・委員会）
- 共通プラットフォーム（K8s・CI/CD・監視）
- セキュリティ基盤（IdP・WAF・SIEM）
- FinOps体制（コスト可視化）
- AI基盤（GPU・LLM Gateway・ベクトルDB）
筆者メモ — 「技術憲法なし」で破綻した企業の事例
TA が不在で技術スタックが爆発した組織がどうなるかを示す事例は、IT 業界に繰り返し現れます。
中堅ソフトウェア企業で「開発チームの自由を尊重する」方針のもと、部署ごとにクラウドも言語も選び放題にしていた結果、5年後に AWS・Azure・GCPの3クラウド、Java・Ruby・Python・Node.js・Go・Scalaの6言語、MySQL・PostgreSQL・MongoDB・DynamoDBの4DBが混在し、運用チームは新人教育だけで半年、各クラウドの予約インスタンス最適化は誰もできない状態になった、という事例は業界の会食でしばしば語られます。「自由」の代償はインフラコスト倍増と人材流動性ゼロでした。
もう一つ、2017年の英国 Tesco Bank障害は技術標準化の欠如が原因の有名な事件です。2016年11月、オンラインバンキングで約4万口座から不正取引が検知、Tesco Bank は全オンラインサービスを48時間停止、最終的に260万ポンドの顧客補償と FCAから1,640万ポンドの罰金を受けました。後の調査で、バラバラのセキュリティ基準（部署ごとに異なる認証・監視設定）が攻撃者に抜け穴を残していたことが判明しました。「技術の自由を技術憲法なしに許すと、セキュリティ穴になる」ことを突きつけた事例です。
どちらもTAは自由の敵ではなく、持続可能な自由の前提であることを示します。標準があるから、その上で個別プロジェクトが本当に差別化すべき部分に集中できる──という逆説が、TA の本質的な価値です。
最終的な判断の仕方
TA の核心は企業の技術選択の憲法を作るという発想です。部署ごとに勝手な技術選定をすると、スタック爆発・人材流動性低下・セキュリティ統一不可で、大企業では年間数億円の無駄を生みます。クラウド戦略・標準スタック・共通プラットフォーム・セキュリティ基盤を全社で体系化し、逸脱には正当な理由を求めるのが TA の仕事です。ただし硬直化させず、Technology Radar で実験を促しつつ標準化で安定供給、という両立が重要です。マルチクラウドは運用3倍コスト2倍が現実で、「やる意義」を明確にしない限り負債化します。
もう一つの決定的な軸はAIワークロード前提のTA拡張です。GPU 基盤・ベクトル DB・LLM API ゲートウェイ・プロンプト管理・AI Observability は、従来 TA には存在しなかった新しい構成要素です。OpenAI・Anthropic・Gemini の使い分けと課金を統合する AI Gateway（Portkey／LiteLLM）の中央管理は、コスト可視化とガバナンスの両面で必須装備になりました。
選定の優先順位
- シングルクラウド基調で現実的に — マルチは運用爆発、主＋補助の現実解
- 標準スタックは5〜10個以内に絞る — 技術委員会で厳格管理、膨張防止
- Technology Radarで革新を共存 — Adopt／Trial／Assess／Hold、半期見直し
- AI基盤を新TA構成要素として設計 — GPU・ベクトルDB・LLM Gateway・AI Observability
「技術選択の憲法、革新はRadarで促進」AI 時代は GPU・LLM Gateway が新構成要素です。
まとめ
本記事はEA観点のテクノロジーアーキテクチャについて、クラウド戦略・標準スタック・Technology Radar・FinOps・IDP・AI時代のGPU/LLM Gatewayまで含めて解説しました。如何だったでしょうか。
シングルクラウド基調で標準スタックを5〜10個に絞り、Technology Radarで革新を共存、AI基盤を新TA構成要素として設計する。これが2026年のEA観点TAの現実解です。
次回はEAフレームワーク（TOGAF・ArchiMate・Tailoring）について解説します。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（73/89）