大企業基幹系 ― 新しい技術より組織で成立する設計 ― 生成AI時代のアーキテクチャ超入門

本記事について

当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「ケーススタディ」カテゴリ第4弾（最終回）として、大企業基幹系のケースについて解説する記事です。

従業員1,000人超のERP／人事／会計／販売管理、または金融／医療／公共の規制領域では「速さ」より「安定・監査・ガバナンス」が最優先。技術選定より前に「誰が何を承認するか」が設計対象です。本記事では監査可能性・変更容易性・長期サポート、レガシー連携、ベンダー選定、SoR/SoE分離まで扱います。

本記事のテーマについてさらに詳しく知りたい方は『エンタープライズ・アーキテクチャの基本と仕組み』も参考にしてみてください。

そもそも大企業基幹系のアーキテクチャとは何か

ホテルチェーンの経営を想像してください。個人の民泊とは違い、「監査対応」「法令遵守」「10年単位の設備計画」「数千人のスタッフ教育」が前提です。最新のおしゃれな内装より、安全基準を満たし長期運用に耐える設計が最優先になります。

大企業基幹系のアーキテクチャも同じで、速さより安定・監査・ガバナンスが最優先です。パッケージ（SAP・Oracle等）の標準機能に業務を合わせるFit to Standardが主流で、フルスクラッチはほぼ選ばない時代です。

もし大企業が最新技術を追い求めて独自実装すると、保守人材が確保できず、監査に通らず、5年後に負債化します。

なぜ大企業基幹系の設計が特殊なのか

技術的な最適解より「組織で成立する設計」が求められるから

大企業基幹系では、技術的に最も優れた選択肢が最善の選択とは限りません。数千人の開発者・数百のチーム・複数のベンダーが関わる中で、「誰が承認するか」「誰が保守するか」「10年後にも人材がいるか」が技術選定より先に来ます。

監査・法令遵守が設計を規定するから

金融・医療・公共などの規制業種では、監査証跡・変更承認フロー・データ保持期間が法律で規定されており、設計の自由度が大きく制約されます。もしこれを軽視すると、システムが完成しても監査に通らず使えないという最悪の事態になります。

レガシーとの共存が前提になるから

大企業には10〜20年稼働しているレガシーシステムが必ず存在し、ビッグバン刷新ではなくStrangler Figパターンで段階的に移行するのが現実解です。新システムだけを設計するスタートアップとは根本的にアプローチが異なります。

選定の基本方針

この領域の核心は監査可能性・変更容易性・長期サポートの3点で、最新技術より枯れた技術が選ばれる傾向が強くなります。ベンダーの保守期間・SLA・既存資産との互換性・人材市場の広さが、技術的な優秀さより重視されます。

代表的なプロファイルは、ERP、会計システム、人事給与、販売管理、金融コアシステム、医療情報システム。「新しいから選ぶ」は大企業基幹系で最も危険な根拠です。

推奨スタック（全体像）

大企業基幹系は、パッケージ採用が前提（SAP・Oracle・Salesforce 等）で、カスタムは「どうしても既製品で吸収できない業務」に限定するのが現代の王道です。フルスクラッチはほぼ選ばない選択肢になりました。

カスタム開発はパッケージで吸収できない差別化要素のみで、全体の2〜3割に抑えるのが理想です。

システム・デプロイの選択

パブリッククラウドへの移行が進む現代でも、大企業基幹系ではハイブリッドクラウドが現実解であるケースが多数です。既存のオンプレ資産、データ主権要件（個人情報を国外に出せない等）、既存 ERP ベンダーとの契約関係が、フルクラウド移行を阻む実際的な障壁になります。

新規開発部分はパブリッククラウド（AWS／Azure）+ コンテナ + IaC で構築し、既存システムとは API／イベント連携で繋ぐのが段階的移行の定石です。一気に置き換えるビッグバン移行は失敗率が高く、Strangler Figパターン（既存の周りを新しい実装で包んで徐々に置き換える）で進めます。

大企業基幹系で全面刷新・数百億円規模の大型プロジェクトは失敗率が極めて高く、段階移行が定石です。

ソフトウェア・データの選択

カスタム部分の言語は Java／C# が主流で、人材プール・LTS 期間・エンタープライズ向けフレームワーク（Spring／.NET）の厚みから変わりません。TypeScript+Node.js も選択肢ですが、業務ロジックが重い領域では Java が強い傾向が続いています。

データベースは Oracle／SQL Server／PostgreSQL のいずれかで、ACID 整合性が絶対条件です。会計・在庫・金融系では結果整合性は許されず、強整合トランザクションが必要です。NoSQL・イベントソーシング・CQRS は「どうしても必要な領域」に限定で、基幹系の中核では使いません。

会計・在庫の整合性要件で NoSQL を選ぶのは、ほぼ全てのケースで誤選定です。

フロントエンド・認証の選択

社内業務アプリの画面は React／Vue／Angular のいずれでも良く、既存組織のスキルセットに合わせて選びます。Angular は大企業で根強い人気があり、TypeScript 標準・DI・ルーティング統合で大規模アプリに向いています。React を選ぶ場合も、Next.js より社内でアクセス可能なSPAで十分なケースが多く、認証は社内 IdP と統合します。

認証は Azure AD（Entra ID）／Okta + SAMLで社内 AD に統合するのが大企業の標準で、ユーザーは社員 ID でログインします。多要素認証（MFA）は全社員で必須化するのが現代のコンプライアンス要件で、Passkey 対応も進めるのが近年の流れです。

社内システムで独自認証を作るのは、セキュリティ事故の温床。必ず社内 IdP に寄せましょう。

データ・ガバナンスの選択

基幹系のデータは正本（SoR＝System of Record）として扱われ、全社分析・BI・AI 活用の源泉になります。マスタデータ管理（MDM）・データカタログ（Collibra／DataHub）・データリネージの整備は、この規模では必須装備です。個人情報（PII）のマスキング、GDPR／個人情報保護法対応、監査証跡は設計段階から組み込みます。

分析系は DWH（Snowflake／BigQuery／Redshift／Azure Synapse）に集約し、Row Level Security・列レベル暗号化・アクセスログで細かく制御します。業務系 → 分析系の ETL／ELT は dbt で標準化し、データ品質テストを自動化するのが現代の標準です。

大企業で「顧客マスタが部門ごとにバラバラ」は典型的なアンチパターン。MDM 整備で解決しましょう。

セキュリティ・監視の選択

大企業基幹系のセキュリティは、ゼロトラスト + コンプライアンス監査対応が前提になります。ネットワークの内外という古い境界型モデルは崩れており、全リクエストを認証・認可する設計が必須です。SOC 2（サービス組織のセキュリティ等を監査する米国基準）／ISO 27001／PCI DSS（クレジットカード業界のデータ保護基準）等の監査要件に応じて、ログ保管期間・アクセス制御・データ暗号化の水準を決めます。

監視は Datadog／Dynatrace／Splunk 等のエンタープライズ製品が主流で、SLA 付きサポート契約と24／365のベンダー対応が前提です。障害時のインシデント対応プロセス、RTO／RPO、BCP のシミュレーションも年次で実施します。

大企業基幹系で監査対応は設計の前提条件。後付けすると設計が歪みます。

大企業基幹系の数値Gate

※ 2026年4月時点の業界相場値です。テクノロジー・人材市場の変化で陳腐化するため、定期的にアップデートが必要です。

大企業基幹系は桁違いの数値で運用する領域。以下が業界標準です。

Lidl SAP eLWISプロジェクト（5億ユーロ損失）・Hershey Halloween事件（1億ドル損失）のような数百億円規模の失敗が業界の相場感を作っています。大企業基幹系は「枯れた技術・段階移行・Fit to Standard」が鉄則。

やってはいけないこと

大企業基幹系で事故る典型パターン。どれも経営を揺るがすレベルの破壊力です。

Lidl SAP eLWIS（2011〜2018、5億ユーロ損失）、Hershey Halloween事件（1999年、1億ドル損失）、Healthcare.gov 2013年ローンチ失敗（20億ドル追加投入）──これらは技術選定より組織で成立する設計の重要性を示した教科書的失敗です。

大企業基幹系は技術論理より組織論理。役員承認プロセスを通らない設計は承認されません。

| 「技術的に正しければ通る」と技術論理だけで提案 | 人材・調達・監査プロセスを全て通る設計でなければ却下 | | 「スタートアップの成功構成」を安易に真似る | 監査・ガバナンス要件で半年後にやり直し、文脈の違う正解は毒 |

AI判断軸

1. 組織的に成立すること — 人材・ベンダー保守・監査対応
2. Fit to Standard — パッケージを中心に据え、カスタムを抑制
3. 段階的移行 — Strangler Figで既存資産を活かす
4. データ資産化 — DWH・カタログ・MDMで整備

レガシーシステムのAI活用は「データカタログ整備」から始まる

大企業がAI活用を試みる際、最初の壁はレガシーシステムのデータ構造が誰にも把握できていないことです。30年前のCOBOLバッチで更新されるテーブルのカラム名がローマ字略称で、ドキュメントが存在しない──こうした状態ではAIにデータを活用させることも、AI生成コードでレガシーに接続することもできません。

第一歩はデータカタログの整備です。テーブル定義にCOMMENT（日本語の業務説明）を追加し、カラムの意味・値域・関連テーブルをメタデータとして記録する作業を地道に進めます。この作業自体にもAIを活用できます。既存のバッチ処理コードやSQLをAIに入力し、「このテーブルの各カラムの意味を推定せよ」と指示すれば、初期ドラフトを生成できます。

完全な正解は人間（業務有識者）の確認が必要ですが、AIでドラフトを生成→人間がレビュー・修正のサイクルを回すことで、ゼロから手作業でカタログを作るよりも大幅に時間を短縮できます。

Strangler Figパターンとの組み合わせ

大企業の基幹刷新でAIを活用する場合、既存システムを一括で置き換えるのではなく、Strangler Figパターンで段階的に新システムに移行する際にAIを組み込む設計が有効です。

具体的には、新規部分をAPI化して構築する際にAI生成コードを活用し、既存レガシーとの接続インターフェース（Anti-Corruption Layer）は人間が設計・レビューする分担です。既存システムの仕様は暗黙知が多くAIの精度が低い領域ですが、新規構築部分は標準技術を選べるためAIの支援を最大限受けられます。

この段階的移行の各フェーズをIaCとCI/CDで管理し、新旧システムの切り替えをFeature Flagで制御する構成にしておくと、移行リスクを最小化しながらAI活用の恩恵を新規部分で享受できます。

筆者メモ — 「パッケージを曲げた」代償の事例

ドイツの大手小売 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・Strangler Fig段階移行・ハイブリッドクラウド・データ資産化・組織で成立する設計まで含めて解説しました。如何だったでしょうか。

枯れた技術を選び、段階的に移行し、Fit to Standardで組織を通し、データを資産化する。これが2026年の大企業基幹系設計の現実解です。

そしてこれが「ケーススタディ」カテゴリの最終回でした。次回からは新しいカテゴリ（付録）の解説に入ります。アンチパターン集・ベストプラクティス集・重大インシデント事例集を通じて、本シリーズ全体で語ってきた判断軸を実用的なリファレンスとして整備します。

シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方

本記事で扱った内容の詳細は AWS エンタープライズ も合わせて参考にしてください。

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