テクノロジーアーキテクチャ ― 企業の技術選択の憲法 ― 生成AI時代のアーキテクチャ超入門

本記事について

当サイトを閲覧いただきありがとうございます。本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「エンタープライズアーキテクチャ」カテゴリ第5弾として、EA観点のテクノロジーアーキテクチャ（TA）について解説する記事です。

システムアーキテクチャ章（10系）が「プロジェクトで何を使うか」を扱うのに対し、本記事は「全社で何を許すか・標準とするか」を扱います。例えば「全社標準クラウドを AWS にする」が本記事、「EC2／ECS／Lambda どれを使うか」が10系。本記事ではTechnology Reference Model・Tech Radar・全社標準スタック・SoR/SoE/SoIの分離まで、CIO・IT戦略・インフラ部門長向けに扱います。

本記事のテーマについてさらに詳しく知りたい方は『ITアーキテクチャのセオリー』も参考にしてみてください。

ITアーキテクチャのセオリーAmazonで見る →

そもそもEA観点のテクノロジーアーキテクチャとは何か

社内の備品・設備標準を想像してください。部署ごとに別々のメーカーのPC・プリンター・ネットワーク機器を勝手に購入していたら、保守費用が爆発し、IT部門のサポートが追いつかなくなります。全社標準を決めることで、コストと管理負荷を抑えられます。

EA観点のテクノロジーアーキテクチャ（TA）は、企業全体の技術基盤を標準化する領域です。「プロジェクトで何を使うか」（10系）ではなく、「全社で何を許すか・標準とするか」を決める技術選択の憲法です。

もしTAがなければ、部署ごとにAWS・Azure・GCPを使い始め、技術スタックが爆発して保守不能になります。

技術の自由は、統制の上にしか成り立たない

EA の4番目のレイヤー（TA）で、企業全体の技術基盤（インフラ・ネットワーク・プラットフォーム）を設計・標準化します。個別システム構築時の技術選定とは違い、企業の技術スタンダードを決めるのが役割です。

「どのクラウドを使うか」「社内標準の言語は何か」「DB は何を使うか」──こうした判断を企業全体の規模感で決めるのが TA です。TA がないと、部署ごとに勝手に AWS・Azure・GCP を使い始め、技術スタックが爆発します。

TA は企業の技術選択の憲法。逸脱には正当な理由が必要です。

なぜTAが必要か

技術の多様化がコストを食う

部署ごとに違う技術を使うと、人材流動性が落ち、運用コストが膨らみます。標準化することで人材配置・調達・運用を最適化できます。

セキュリティ・コンプライアンス対応

全社で統一されたセキュリティ基準を適用するには、技術スタックの標準化が前提です。バラバラでは監査も対応も不可能です。

スケールメリットの享受

クラウド契約・ライセンス・サポート契約は、集約すればディスカウントが得られます。TA の標準化で数千万円〜数億円のコスト削減が可能です。

TAの主要構成要素

TA は企業全体で使う技術基盤を体系化します。単なる製品リストではなく、選定基準・利用ガイドライン・例外処理まで含めた総合的な設計です。

要素	内容
クラウド戦略	採用クラウド・マルチ／シングル
標準技術スタック	言語・FW・DB
ネットワーク設計	WAN・VPN・専用線
セキュリティ基盤	IAM・WAF・監視
プラットフォーム	K8s・CI/CD・オブザーバビリティ
エンドユーザ環境	PC・モバイル・MDM
技術標準・ガイドライン	選定ルール

クラウド戦略

最も重要な TA の決定事項がクラウド戦略です。マルチクラウドは聞こえは良いですが、運用複雑性が格段に上がるため、現実的には主クラウド + 補助クラウドが多いです。

戦略	内容	向くケース
シングルクラウド	1社に集中	中小・スピード重視
プライマリ + セカンダリ	主従	リスク分散したい
マルチクラウド	複数に分散	大企業・リスク許容
ハイブリッド	オンプレ + クラウド	移行期・金融等

マルチクラウドは運用3倍・コスト2倍が現実で、「やる意義」を明確にしないと負担ばかりで効果が出ません。

標準技術スタック

全社で推奨する言語・フレームワーク・DB を定めるのが標準技術スタックです。複数のスタックを持つ場合もありますが、5〜10個以内に絞るのが運用的に現実的です。

領域	例（仮想企業）
サーバ言語	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	リモートアクセス
DNS戦略	社内外のDNS管理

セキュリティ基盤

全社で統一適用するセキュリティ基盤を TA が定義します。個別プロジェクトが独自に作ると、穴だらけになります。

基盤	内容
IdP	Okta・Azure AD等
MDM	端末管理
EDR	エンドポイント検知
WAF	Web保護
SIEM／SOC	監視・対応
CASB	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 組織を中央配置し各地域に専門家配属。

標準スタック管理の数値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 等で統一
「技術標準は革新を止める」と思い込む	Radarで実験を促しつつ標準化で安定供給、バランスが重要
「マルチクラウドは安全」と信じて導入	運用コストが爆発し全部中途半端、目的を明確にしないと負債化
「EOLは来たら対応すればいい」と放置	移行には数か月〜年単位、2年前から計画が現実的
「クラウドは自動で最適化される」と放置	逆に無駄が爆発する、FinOpsは能動的活動

AWS の月額請求を可視化したら誰も使っていないEC2が47台並んでいて、月額120万円ほど空焚きしていた──という事例が報告されています。犯人は「退職した前任者が PoC で立てたインスタンス」と「検証が終わったのに止め忘れた GPU」クラウドは蛇口を開けっぱなしにすると、静かにプールが水浸しになる。FinOps は「水道メーターを毎日見る人」を置かないと回らない、と示す典型例です。

2017年 Tesco Bank障害（オンラインバンキング全停止48時間、約4万口座不正取引、260万ポンド補償+1,640万ポンド罰金）は、バラバラのセキュリティ基準が攻撃者に抜け穴を残した事例として語り草です。

TA は自由の敵ではなく、持続可能な自由の前提。標準があるから差別化に集中できます。

決めるべきこと — 自分のプロジェクトでの答えは？

以下の項目について、自分のプロジェクトの答えを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時代の判断軸

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 API ゲートウェイ・プロンプト管理・AI Observability は、従来 TA には存在しなかった新しい構成要素です。OpenAI・Anthropic・Gemini の使い分けと課金を統合する AI Gateway（Portkey／LiteLLM）の中央管理は、コスト可視化とガバナンスの両面で必須装備になりました。

AI 時代の TA はGPU・ベクトルDB・LLMを前提にした拡張が必要です。

選定の優先順位

シングルクラウド基調で現実的に — マルチは運用爆発、主＋補助の現実解
標準スタックは5〜10個以内に絞る — 技術委員会で厳格管理、膨張防止

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設計に必須です。 3. Technology Radarで革新を共存 — Adopt／Trial／Assess／Hold、半期見直し 4. 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時代のアーキテクチャ超入門』の歩き方

本記事で扱った内容の詳細は AWS Well-Architected フレームワークも合わせて参考にしてください。

それでは次の記事も閲覧いただけると幸いです。