本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「ケーススタディ」カテゴリ第4弾（最終回）として、大企業基幹系のケースについて解説する記事です。
従業員1,000人超のERP／人事／会計／販売管理、または金融／医療／公共の規制領域では「速さ」より「安定・監査・ガバナンス」が最優先。技術選定より前に「誰が何を承認するか」が設計対象です。本記事では監査可能性・変更容易性・長期サポート、レガシー連携、ベンダー選定、SoR/SoE分離まで扱います。
このカテゴリの他の記事
選定の基本方針
この領域の核心は監査可能性・変更容易性・長期サポートの3点で、最新技術より枯れた技術が選ばれる傾向が強くなります。ベンダーの保守期間・SLA・既存資産との互換性・人材市場の広さが、技術的な優秀さより重視されます。
| 優先する | 後回しでいい |
|---|---|
| 監査ログ・証跡・承認フロー | 市場投入速度 |
| 長期サポート（LTS 5年以上） | 最新バージョン追随 |
| ACIDトランザクション | 結果整合性の複雑な扱い |
| 既存システムとの連携 | グリーンフィールド設計 |
| ベンダー保守・SLA契約 | フルOSSで運用 |
代表的なプロファイルは、ERP、会計システム、人事給与、販売管理、金融コアシステム、医療情報システム。「新しいから選ぶ」は大企業基幹系で最も危険な根拠です。
推奨スタック（全体像）
大企業基幹系は、パッケージ採用が前提（SAP・Oracle・Salesforce 等）で、カスタムは「どうしても既製品で吸収できない業務」に限定するのが現代の王道です。フルスクラッチはほぼ選ばない選択肢になりました。
flowchart TB
USER([社員 / 顧客])
AD[Azure AD / Okta<br/>SAML SSO]
subgraph CORE["基幹パッケージ (8割)"]
SAP[SAP S/4HANA<br/>会計/生産]
SF[Salesforce<br/>顧客]
ORACLE[Oracle EBS<br/>人事]
end
subgraph CUSTOM["カスタム (2-3割)"]
APP[Java/C#/TypeScript<br/>差別化要素のみ]
end
subgraph DATA["データ層"]
ORADB[(Oracle / SQL Server<br/>ACID保証)]
end
USER --> AD
AD --> CORE
AD --> CUSTOM
CORE --> ORADB
CUSTOM --> ORADB
GOV[ガバナンス<br/>TOGAF / ArchiMate / ADR]
GOV -.- CORE
GOV -.- CUSTOM
classDef user fill:#fef3c7,stroke:#d97706;
classDef auth fill:#dbeafe,stroke:#2563eb;
classDef pkg fill:#fae8ff,stroke:#a21caf;
classDef custom fill:#dcfce7,stroke:#16a34a;
classDef data fill:#f0f9ff,stroke:#0369a1;
classDef gov fill:#fee2e2,stroke:#dc2626;
class USER user;
class AD auth;
class CORE,SAP,SF,ORACLE pkg;
class CUSTOM,APP custom;
class DATA,ORADB data;
class GOV gov;| 領域 | 推奨 | 理由 |
|---|---|---|
| 基幹パッケージ | SAP S/4HANA、Oracle EBS、Salesforce 等 | 業務知識が製品に内包 |
| カスタム部分の言語 | Java／C#／TypeScript | LTS長期・人材確保容易 |
| DB | Oracle／SQL Server／Postgres | ACID・ベンダー保守 |
| インフラ | AWS／Azure（EU域内はEU、ハイブリッド可） | コンプライアンス・データ主権 |
| 認証 | Azure AD（Entra ID）／Okta + SAML | 既存社内ADとの統合 |
| 監視 | Datadog／Dynatrace／Splunk | エンタープライズSLA |
| ガバナンス | TOGAF／ArchiMate／ADR | 意思決定の文書化 |
カスタム開発はパッケージで吸収できない差別化要素のみで、全体の2〜3割に抑えるのが理想です。
システム・デプロイの選択
パブリッククラウドへの移行が進む現代でも、大企業基幹系ではハイブリッドクラウドが現実解であるケースが多数です。既存のオンプレ資産、データ主権要件（個人情報を国外に出せない等）、既存 ERP ベンダーとの契約関係が、フルクラウド移行を阻む実際的な障壁になります。
新規開発部分はパブリッククラウド（AWS／Azure）+ コンテナ + IaC で構築し、既存システムとは API／イベント連携で繋ぐのが段階的移行の定石です。一気に置き換えるビッグバン移行は失敗率が高く、Strangler Figパターン（既存の周りを新しい実装で包んで徐々に置き換える）で進めます。
| 選ぶ | 避ける |
|---|---|
| ハイブリッド構成（既存オンプレ + 新規クラウド） | ビッグバンのフルクラウド移行 |
| Azure（MS系統合済みなら）／AWS | AWS + Azure + GCPの3クラウド |
| Terraform／BicepでIaC化 | GUI手動構築のまま |
| Strangler Figで段階移行 | 全面刷新プロジェクト |
大企業基幹系で全面刷新・数百億円規模の大型プロジェクトは失敗率が極めて高く、段階移行が定石です。
ソフトウェア・データの選択
カスタム部分の言語は Java／C# が主流で、人材プール・LTS 期間・エンタープライズ向けフレームワーク（Spring／.NET）の厚みから変わりません。TypeScript+Node.js も選択肢ですが、業務ロジックが重い領域では Java が強い傾向が続いています。
データベースは Oracle／SQL Server／PostgreSQL のいずれかで、ACID 整合性が絶対条件です。会計・在庫・金融系では結果整合性は許されず、強整合トランザクションが必要です。NoSQL・イベントソーシング・CQRS は「どうしても必要な領域」に限定で、基幹系の中核では使いません。
| 選ぶ | 避ける |
|---|---|
| Java（Spring Boot）／C#（.NET） | マイナー言語・独自FW |
| Oracle／SQL Server／Postgres | NoSQLのみで基幹系運用 |
| モジュラーモノリス | 早すぎるマイクロサービス |
| パッケージ + カスタム連携 | フルスクラッチ全面開発 |
会計・在庫の整合性要件で NoSQL を選ぶのは、ほぼ全てのケースで誤選定です。
フロントエンド・認証の選択
社内業務アプリの画面は React／Vue／Angular のいずれでも良く、既存組織のスキルセットに合わせて選びます。Angular は大企業で根強い人気があり、TypeScript 標準・DI・ルーティング統合で大規模アプリに向いています。React を選ぶ場合も、Next.js より社内でアクセス可能なSPAで十分なケースが多く、認証は社内 IdP と統合します。
認証は Azure AD（Entra ID）／Okta + SAMLで社内 AD に統合するのが大企業の標準で、ユーザーは社員 ID でログインします。多要素認証（MFA）は全社員で必須化するのが現代のコンプライアンス要件で、Passkey 対応も進めるのが近年の流れです。
| 選ぶ | 避ける |
|---|---|
| Angular／React（社内スキル依存） | 最新FW（Svelte／Qwik等）採用 |
| 社内IdP統合（Azure AD／Okta + SAML） | 独立した認証DB |
| MFA必須化（Passkey対応） | パスワードのみ |
| 既存UIガイドラインに準拠 | 独自デザインシステム構築 |
社内システムで独自認証を作るのは、セキュリティ事故の温床。必ず社内 IdP に寄せましょう。
データ・ガバナンスの選択
基幹系のデータは正本（SoR＝System of Record）として扱われ、全社分析・BI・AI 活用の源泉になります。マスタデータ管理（MDM）・データカタログ（Collibra／DataHub）・データリネージの整備は、この規模では必須装備です。個人情報（PII）のマスキング、GDPR／個人情報保護法対応、監査証跡は設計段階から組み込みます。
分析系は DWH（Snowflake／BigQuery／Redshift／Azure Synapse）に集約し、Row Level Security・列レベル暗号化・アクセスログで細かく制御します。業務系 → 分析系の ETL／ELT は dbt で標準化し、データ品質テストを自動化するのが現代の標準です。
| 選ぶ | 避ける |
|---|---|
| DWH集約 + ELT（dbt） | 各部門で個別に抽出 |
| データカタログ（Collibra／DataHub） | Excel管理のマスタ |
| PIIマスキング + 監査ログ | 個人情報の無管理 |
| MDMで顧客・商品マスタ統合 | 部門ごとに別マスタ |
大企業で「顧客マスタが部門ごとにバラバラ」は典型的なアンチパターン。MDM 整備で解決しましょう。
セキュリティ・監視の選択
大企業基幹系のセキュリティは、ゼロトラスト + コンプライアンス監査対応が前提になります。ネットワークの内外という古い境界型モデルは崩れており、全リクエストを認証・認可する設計が必須です。SOC 2（サービス組織のセキュリティ等を監査する米国基準）／ISO 27001／PCI DSS（クレジットカード業界のデータ保護基準）等の監査要件に応じて、ログ保管期間・アクセス制御・データ暗号化の水準を決めます。
監視は Datadog／Dynatrace／Splunk 等のエンタープライズ製品が主流で、SLA 付きサポート契約と24／365のベンダー対応が前提です。障害時のインシデント対応プロセス、RTO／RPO、BCP のシミュレーションも年次で実施します。
| 選ぶ | 避ける |
|---|---|
| ゼロトラスト + MFA全社必須 | VPN内は信頼する旧モデル |
| Datadog／Dynatrace／Splunk | OSSのみ（SLA契約なし） |
| SOC 2／ISO 27001 監査対応 | コンプラ要件を後回し |
| BCP年次シミュレーション | 計画書があるだけ |
大企業基幹系で監査対応は設計の前提条件。後付けすると設計が歪みます。
大企業基幹系の数値Gate
※ 2026年4月時点の業界相場値です。テクノロジー・人材市場の変化で陳腐化するため、定期的にアップデートが必要です。
大企業基幹系は桁違いの数値で運用する領域。以下が業界標準です。
| 指標 | 推奨値 | 理由 |
|---|---|---|
| 可用性SLO | 99.99%（月4.3分） | 金融・決済は99.999%以上 |
| プロジェクト期間 | 2〜5年 | ビッグバン刷新は失敗率高 |
| プロジェクト予算 | 数十億〜数百億円 | 段階移行を基本に |
| 監査ログ保存 | 7年（J-SOX準拠） | PCI DSSは1年、医療は6年 |
| MFA必須化 | 全社員 | 例外なし |
| LTS要件 | 5年以上 | 10年運用が前提 |
| パッケージカスタム率 | 2〜3割以下 | Fit to Standardが原則 |
| Strangler Fig移行期間 | 5〜10年 | ビッグバン禁止 |
| RTO／RPO | 業務影響で決定 | 1時間／5分が目安 |
| 調達プロセス | 半年〜1年 | 役員承認・入札要 |
Lidl SAP eLWISプロジェクト（5億ユーロ損失）・Hershey Halloween事件（1億ドル損失）のような数百億円規模の失敗が業界の相場感を作っています。大企業基幹系は「枯れた技術・段階移行・Fit to Standard」が鉄則。
大企業基幹系の鬼門・禁じ手
大企業基幹系で事故る典型パターン。どれも経営を揺るがすレベルの破壊力です。
| 禁じ手 | なぜダメか |
|---|---|
| ビッグバン刷新で全システム3年で一新 | Hershey 1999年 Halloween事件（1億ドル損失）、Healthcare.gov 2013（20億ドル追加投入）のパターン |
| パッケージをフルカスタマイズ | Lidl SAP eLWIS（5億ユーロ損失、プロジェクト中止）、Fit to Standard 原則違反 |
| 早すぎるマイクロサービス化 | トランザクション整合性・運用負荷で破綻、モジュラーモノリスから |
| 最新技術（LTS期間短）を業務システムに採用 | 10年運用で保守人材枯渇、技術的負債化 |
| OSSのみで監査要件を満たそうとする | SLA付きサポートなしでは監査・インシデント対応が不能 |
| Excelマスタ・属人管理を放置 | 部門ごとの個別最適が全社最適を阻害、MDM整備必須 |
| データ主権要件を無視してパブリッククラウド一択 | 個人情報の国外出しで規制違反、ハイブリッド現実解 |
| BCP計画書を作ってシミュレーションなし | 実際の災害時に機能しない、年次訓練必須 |
| 技術論理だけで提案書作成 | 人材・調達・監査プロセスを通らず却下 |
| ZTNA（ゼロトラスト）を導入せずVPN中心運用 | 内部侵害で全社に波及、2021年 Pulse Secure 事件パターン |
Lidl SAP eLWIS（2011〜2018、5億ユーロ損失）、Hershey Halloween事件（1999年、1億ドル損失）、Healthcare.gov 2013年ローンチ失敗（20億ドル追加投入）──これらは技術選定より組織で成立する設計の重要性を示した教科書的失敗です。
大企業基幹系は技術論理より組織論理。役員承認プロセスを通らない設計は承認されません。
AI時代の視点
大企業基幹系での AI 活用は既存データの資産化が最初のステップで、スキーマが明示された RDB・メタデータ整備された DWH が前提になります。スタートアップと違い、過去10〜20年分のデータ資産があるため、これを整理すれば AI 活用の価値は巨大ですが、整理されていないと「データがあるのに使えない」状態が生まれます。
カスタム開発の部分は IaC + 標準プロトコルで AI 駆動開発の恩恵を受けられますが、SAP／Oracle 等のパッケージ側は AI と相性が悪い部分が残ります。ここは「パッケージ側は最小限、連携部分はAI時代の標準構成」という切り分けが合理的です。
| AI時代に有利 | AI時代に不利 |
|---|---|
| データカタログ + メタデータ整備 | 部門別Excel・属人管理 |
| MDMで統合されたマスタ | 部門ごとに別マスタ |
| 標準プロトコル（OIDC／OpenAPI） | 独自APIゲートウェイ |
| IaC化された新規構築部分 | GUI運用のレガシー |
大企業の AI 活用は「データ整理」から始まる。整理されていないデータは AI も救えません。
よくある失敗
大企業基幹系で頻出する失敗パターンを整理します。いずれも組織規模・コンプライアンス・既存資産という制約を軽視した結果で、スタートアップや中小 SaaS の成功例を安易に持ち込むと破綻します。
ビッグバン刷新
「全システム3年で刷新」プロジェクトは失敗率が極めて高く、Strangler Figによる段階移行が定石です。
最新技術の採用
LTS 期間が短い FW・マイナー言語は保守人材が枯渇し、5年後に技術的負債になります。
パッケージをフルカスタマイズ
SAP 等の標準機能を大幅にカスタムすると、バージョンアップ不能になります。Fit to Standard（業務をパッケージに合わせる）が原則です。
早すぎるマイクロサービス
基幹系をいきなり数十サービスに分割すると、トランザクション整合性・運用負荷で破綻します。モジュラーモノリスから始めます。
OSSのみで監査要件を満たそうとする
SLA 付きサポートがないと、監査・インシデント対応で問題になります。
Excelマスタ・属人管理の放置
MDM・データカタログを整備せず、部門ごとの個別最適が全社最適を阻害します。
大企業で「技術的に優れた選択」と組織的に成立する選択は、しばしば別物です。
大手企業の基幹刷新で、技術的には申し分ない提案書を出したのに、会議の最後で役員室から「このベンダーは我が社との取引年数が短い」「この言語は弊社の研修センターが対応できない」という理由で却下された──という話はよく聞かれます。技術論理ではなく、人材・研修・調達・監査という組織の臓器をすべて通る設計でなければ、大企業では承認されません。大企業向け提案書には「人材確保戦略」「既存調達プロセスとの整合」のスライドが必須、技術だけの提案書は大企業では紙飛行機にしかならない、と示唆する典型例です。
筆者メモ — 「パッケージを曲げた」代償の事例
ドイツの大手小売 Lidl は、SAP をベースにした基幹システム刷新プロジェクト「eLWIS」を2011年から進めましたが、2018年に5億ユーロ（約650億円）を特別損失として計上し、プロジェクトを中止しました。原因は、Lidl 独自の商品コード体系（仕入れ値を基準にする内部慣行）に合わせて SAP を大幅にカスタマイズしようとした結果、パッケージ標準との乖離が巨大化し保守不能になったことでした。「業務をパッケージに合わせる（Fit to Standard）の原則を無視した代償」として、SAP 界隈で今も語り草になっている事例です。
米国の製菓大手 Hershey は1999年、ハロウィーン直前の最需要期にSAPのビッグバン移行を敢行──受注システムが機能停止し、約1億ドル相当のチョコレートを出荷できず、四半期売上が前年比12%減となりました。業界では「Hershey Halloween事件」として、ビッグバン移行の危険性と段階的移行（Strangler Fig）の必要性を説く際の定番事例になっています。大企業基幹系が「枯れた技術・段階移行・Fit to Standard」を基本線に据えるのは、こうした数百億円規模の失敗が業界の常識として蓄積されてきた結果だと言えます。
決めるべきこと — あなたのプロジェクトでの答えは？
以下の項目について、あなたのプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。
大企業基幹系の選定は、数か月単位で議論し、正式な承認プロセスを経て決定します。以下は経営・法務・セキュリティ・IT 部門の合意形成が必要な項目です。
- パッケージ vs カスタムの切り分け（Fit to Standard原則）
- クラウド戦略（ハイブリッド／パブリック／データ主権）
- 認証基盤（社内IdP統合／MFA／Passkey対応）
- データガバナンス（MDM／データカタログ／PII管理）
- 監査・コンプライアンス水準（SOC 2／ISO 27001等）
- BCP／DR（RTO／RPO の数値定義）
- EAフレームワーク（TOGAF／ArchiMate等）
- 移行戦略（Strangler Fig／ビッグバン）
最終的な判断の仕方
大企業基幹系の選定の核心は技術的優秀さより、組織的に成立する選択という発想です。最新技術が優れていても、人材確保・ベンダー保守・既存資産との互換性・監査対応が整わなければ採用できません。Fit to Standard・枯れた技術・長期サポート・既存 IdP 統合といった、スタートアップでは考えない論点がここでは主役になります。
もう一つの決定的な軸は段階的移行 + データ資産化の2本柱です。全面刷新の大型プロジェクトは失敗率が極めて高く、Strangler Fig で既存資産を段階的に置き換えるのが定石です。同時に、蓄積された業務データを DWH・データカタログ・MDM で整理することで、AI 時代の資産として活用可能な状態に変換していきます。
選定の優先順位
- 組織的に成立すること — 人材・ベンダー保守・監査対応
- Fit to Standard — パッケージを中心に据え、カスタムを抑制
- 段階的移行 — Strangler Figで既存資産を活かす
- データ資産化 — DWH・カタログ・MDMで整備
「新しい技術 < 組織で成立する設計」これが大企業基幹系の鉄則です。
まとめ
本記事は大企業基幹系のケースについて、Fit to Standard・Strangler Fig段階移行・ハイブリッドクラウド・データ資産化・組織で成立する設計まで含めて解説しました。如何だったでしょうか。
枯れた技術を選び、段階的に移行し、Fit to Standardで組織を通し、データを資産化する。これが2026年の大企業基幹系設計の現実解です。
そしてこれが「ケーススタディ」カテゴリの最終回でした。次回からは新しいカテゴリ（付録）の解説に入ります。アンチパターン集・ベストプラクティス集・重大インシデント事例集を通じて、本シリーズ全体で語ってきた判断軸を実用的なリファレンスとして整備します。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（83/89）