本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「エンタープライズアーキテクチャ」カテゴリ第5弾として、EA観点のテクノロジーアーキテクチャ（TA）について解説する記事です。
システムアーキテクチャ章（10系）が「プロジェクトで何を使うか」を扱うのに対し、本記事は「全社で何を許すか・標準とするか」を扱います。例えば「全社標準クラウドをAWSにする」が本記事、「EC2／ECS／Lambdaどれを使うか」が10系。本記事ではTechnology Reference Model・Tech Radar・全社標準スタック・FinOpsまで、CIO・IT戦略・インフラ部門長向けに扱います。
本記事のテーマについてさらに詳しく知りたい方は『ITアーキテクチャのセオリー』も参考にしてみてください。
この記事の結論
- シングルクラウド基調で標準スタックを5〜10個に絞る
- Technology Radarで革新と標準を共存させる
- AI基盤（GPU・LLM Gateway）を新しいTA構成要素として設計する
この記事を読む前に
本記事は会社全体のシステムをどう整理するかという話が中心で、技術用語は比較的少なめです。とは言っても、Webサービスの基本構造を知っていると読みやすくなりますので、不安な方は基礎編の「Webサービスが動く仕組み」からどうぞ。また、読んでいて分からない用語が出てきたときは用語集で調べながら読み進められます。
そもそもEA観点のテクノロジーアーキテクチャとは何か
社内の備品・設備標準を想像してください。部署ごとに別々のメーカーのPC・プリンター・ネットワーク機器を勝手に購入していたら、保守費用が爆発し、IT部門のサポートが追いつかなくなります。全社標準を決めることで、コストと管理負荷を抑えられます。
EA観点のテクノロジーアーキテクチャ（TA）は、企業全体の技術基盤を標準化する領域です。「どのクラウドを使うか」「社内標準の言語は何か」──こうした判断を企業全体の規模感で決める、技術選択の憲法です。逸脱には正当な理由が必要になります。
もしTAがなければ、部署ごとにAWS・Azure・GCPを使い始め、技術スタックが爆発して保守不能になります。技術の自由は、統制の上にしか成り立ちません。
なぜTAが必要か
第一に、技術の多様化がコストを食うからです。部署ごとに違う技術を使うと人材流動性が落ち、運用コストが膨らみます。第二に、セキュリティ・コンプライアンス対応です。全社で統一されたセキュリティ基準を適用するには技術スタックの標準化が前提で、バラバラでは監査も対応も不可能です。第三に、スケールメリットです。クラウド契約・ライセンス・サポート契約は集約すればディスカウントが得られ、数千万円〜数億円のコスト削減が可能です。
TAの主要構成要素
TAは単なる製品リストではなく、選定基準・利用ガイドライン・例外処理まで含めた総合的な設計です。
| 要素 | 内容 |
|---|---|
| クラウド戦略 | 採用クラウド・マルチ／シングル |
| 標準技術スタック | 言語・FW・DB |
| ネットワーク設計 | WAN・VPN・専用線 |
| セキュリティ基盤 | IAM・WAF・監視 |
| プラットフォーム | K8s・CI/CD・オブザーバビリティ |
| 技術標準・ガイドライン | 選定ルール・例外処理 |
クラウド戦略 — 最重要の決定事項
| 戦略 | 内容 | 向くケース |
|---|---|---|
| シングルクラウド | 1社に集中 | 中小・スピード重視 |
| プライマリ + セカンダリ | 主従 | リスク分散したい |
| マルチクラウド | 複数に分散 | 大企業・リスク許容 |
| ハイブリッド | オンプレ + クラウド | 移行期・金融等 |
マルチクラウドは聞こえは良いですが、運用3倍・コスト2倍が現実です。「やる意義」を明確にできないなら、シングルクラウド基調（主クラウド + 補助）で始めるのが現実解です。
標準スタックとTechnology Radar
全社で推奨する言語・フレームワーク・DBを定めるのが標準技術スタックです。例えばサーバ言語はPython / TypeScript / Go、フロントはReact + Next.js、DBはPostgreSQL + BigQuery、コンテナはKubernetes──という形で、5〜10個以内に絞るのが運用的に現実的です。「流行りの言語を入れる」と標準が膨れ上がるため、新技術は提案→PoC→評価→技術委員会審査→標準化→段階展開というフォーマルなプロセスで管理します。
標準化の硬直化を防ぐのがTechnology Radar（ThoughtWorks提唱）です。技術をAdopt（採用）・Trial（試用）・Assess（評価）・Hold（保留）の4象限で分類し、半期ごとに見直します。標準で安定供給しつつRadarで実験を促す──このバランスが、エンジニアの離職を防ぎながら統制を効かせる鍵です。
共通プラットフォーム（全社K8s基盤・統一CI/CD・監視基盤・API Gateway・認証基盤・データ基盤）をInternal Developer Platform（IDP、代表OSSはBackstage）として統合提供するのが現代トレンドです。ネットワーク（SD-WAN・SASE・クラウド専用線接続）とセキュリティ基盤（IdP・MDM・EDR・WAF・SIEM / SOC・CASB）もTAが全社統一で定義します。個別プロジェクトが独自に作ると穴だらけになります。
EOL管理とFinOps
技術にもライフサイクルがあります。EOL（End of Life）製品を使い続けるとセキュリティリスクになるため、Windows Server・PostgreSQL・Java等のEOLスケジュールを把握し、2年前から移行計画を立てるのがTAの仕事です。EOLが来てから対応するのでは、移行に数か月〜年単位かかるため間に合いません。
現代TAのもう一つの重要領域がFinOps（クラウドコスト最適化）です。部署・プロジェクト別のコスト可視化、予約インスタンス（30〜70%削減）、Spot Instance、オートスケール、非稼働時停止を組織的に回します。CloudHealth・Kubecost等のツールを使い、請求書を毎月見る習慣を組織文化にするのが鍵です。FinOps専任を置くと月20%の削減が普通に出ます。
規模・規制で変わる重装度
スタートアップはクラウド1社 + 言語2〜3個 + マネージドサービス活用で、TA委員会は不要（創業CTOの頭の中が標準）、FinOpsはCost Explorerの月次レビューで十分です。中堅企業は主クラウド + セカンダリ + 標準スタック5〜10個 + Technology Radarで、技術委員会を四半期開催、BackstageでIDPを構築します。大企業・規制業種（金融のFISC、医療のHIPAA等）はホワイトリスト制で許可された製品だけを使う運用になり、SIEM / SOC 24/7、EOLは2年前から移行計画という重装備です。グローバル企業は地域別TA（欧州はGDPR準拠スタック、中国は独立クラウド）と全社TAを、Identity PlatformとAPI Gatewayで統合します。
標準スタック管理の数値Gate
※ 2026年4月時点の業界相場値です。テクノロジー・人材市場の変化で陳腐化するため、定期的にアップデートが必要です。
TAは自由を許しつつ標準で縛るバランスが命です。以下が業界定番の管理指標です。
| 指標 | 推奨値 | 超えたらどうするか |
|---|---|---|
| 標準技術スタック数 | 5〜10個以内 | 技術委員会で厳格管理 |
| 使用クラウド数 | 1〜2社（主＋補助） | マルチは運用3倍コスト2倍 |
| EOL 6か月以内の稼働システム | 0件 | 緊急更新計画 |
| Technology Radar更新頻度 | 半期1回 | 陳腐化しない運用 |
| 例外技術承認率 | 10%以下 | 標準外は正当な理由必須 |
| 未使用リソース率 | 10%以下 | 夜間停止・自動削減 |
| 予約インスタンスカバー率 | 60〜80% | 継続稼働分はコミット契約 |
| パッチ適用SLA（Critical） | 72時間以内 | EOL放置は禁止 |
AI判断軸 ― GPU・ベクトルDB・LLM GatewayがTAの新構成要素
AI Gatewayが全社LLM利用の制御点になる
LLM APIの利用が社内で拡大すると、各チームが個別にOpenAI・Anthropic・Geminiを契約し、コスト把握も利用状況の監視も不可能な状態に陥ります。AI Gateway（Portkey・LiteLLM等）で全社のLLMトラフィックを一元管理し、コスト可視化・レート制限・PII検出・モデルルーティングを集中制御する設計が、TAの新しい必須要素です。
GPU基盤とベクトルDBの配置設計
自社でLLMを推論実行する場合やRAGパイプラインを構築する場合、GPU基盤（NVIDIA H100 / L4）とベクトルDB（Pinecone・pgvector・Weaviate）のキャパシティ計画がTAに加わります。クラウドのGPUインスタンスはコストが高く供給制約もあるため、事前のキャパシティ確保とコスト見積もりがTA設計に必須です。プロンプト管理・AI Observability（LangSmith等）まで含めたAIワークロード前提のTA拡張が、2026年のテクノロジーアーキテクトの仕事になっています。
やってはいけないこと
TAで事故る典型を、特に危険な6つに絞ります。どれも技術憲法なしの代償として企業を傾けます。
| 禁じ手 | なぜダメか → どうするか |
|---|---|
| 部署ごとにクラウド・言語・DBを選び放題 | 5年で3クラウド6言語4DBが混在し人材流動性ゼロ → 標準スタック + 例外承認制にする |
| マルチクラウドを運用体制なしで採用 | 両方中途半端で全部未最適化 → 明確な理由がない限りシングル基調 |
| EOLが来てから対応する | 移行に数か月〜年単位かかり間に合わない → 2年前から移行計画を立てる |
| クラウド請求書を見ない | 誰も使っていないEC2 47台・月120万円空焚きの事例 → FinOpsで月次レビューを習慣化 |
| セキュリティ基盤を部署別に構築 | Tesco Bank 2017年（1,640万ポンド罰金）のパターン → IdP・SIEM等を全社統一する |
| LLM APIの利用を野放し | 各部署の個別契約でコスト爆発・ガバナンス欠如 → AI Gatewayで一元管理する |
なお「技術標準は革新を止める」という思い込みも誤りです。Radarで実験を促しつつ標準化で安定供給する──バランスの設計がTAの腕の見せ所です。
筆者メモ — 「技術憲法なし」で破綻した企業の事例
中堅ソフトウェア企業で「開発チームの自由を尊重する」方針のもと、部署ごとにクラウドも言語も選び放題にしていた結果、5年後にAWS・Azure・GCPの3クラウド、6言語、4DBが混在し、運用チームは新人教育だけで半年、各クラウドの予約インスタンス最適化は誰もできない状態になった、という事例は業界の会食でしばしば語られます。「自由」の代償はインフラコスト倍増と人材流動性ゼロでした。AWSの月額請求を可視化したら誰も使っていないEC2が47台並んでいて月額120万円を空焚きしていた──犯人は退職した前任者のPoCインスタンスと検証後に止め忘れたGPU、という話も定番です。
もう一つ、2017年の英国Tesco Bank障害は技術標準化の欠如が原因の有名な事件です。オンラインバンキングで約4万口座から不正取引が検知され、全オンラインサービスを48時間停止、最終的に260万ポンドの顧客補償とFCAから1,640万ポンドの罰金を受けました。後の調査で、部署ごとに異なる認証・監視設定が攻撃者に抜け穴を残していたことが判明しました。
どちらもTAは自由の敵ではなく、持続可能な自由の前提であることを示します。標準があるから、その上で個別プロジェクトが本当に差別化すべき部分に集中できる──という逆説がTAの本質的な価値です。
決めるべきこと — 自分のプロジェクトでの答えは？
以下の項目について、自分のプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。
- クラウド戦略（シングル / マルチ）
- 標準技術スタック（言語・FW・DB）
- 技術選定プロセス（Radar・委員会）
- 共通プラットフォーム（K8s・CI/CD・監視）
- セキュリティ基盤（IdP・WAF・SIEM）
- FinOps体制（コスト可視化）
- AI基盤（GPU・LLM Gateway・ベクトルDB）
この記事に関連する記事
まとめ
本記事はEA観点のテクノロジーアーキテクチャについて、クラウド戦略・標準スタック・Technology Radar・FinOps・IDP・AI時代のGPU/LLM Gatewayまで含めて解説しました。如何だったでしょうか。
シングルクラウド基調で標準スタックを5〜10個に絞り、Technology Radarで革新を共存、AI基盤を新TA構成要素として設計する。これが2026年のEA観点TAの現実解です。
次回はEAフレームワーク（TOGAF・ArchiMate・Tailoring）について解説します。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
本記事で扱った内容の詳細は AWS Well-Architected フレームワーク も合わせて参考にしてください。
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（79/95）