米金融サービスのTIAAが、IT資産の8割超がEOL（サポート終了）基盤に載っていた状態から基幹刷新を進め、技術負債をほぼ半減させた事例が公開されている。数字そのものより、どの順番で何を測ると取締役会と合意したかが読みどころだ。基幹システムの刷新をこれから始める、あるいは途中で止まっている会社に向けて、受託開発をやっている側から読み解く。
要点（出典の事実のみ）
- 2022年時点で、TIAAのITワークロードの80%超が分断されたEOL基盤に載っていた
- 2023年開始のフェーズ1で共通プラットフォーム10個を導入。2024年後半開始のフェーズ2で87のユースケースへ展開した
- 技術負債はほぼ半減、製品ローンチは35%高速化、デザインシステムは17個から1個へ統合
- メインフレームのアプリとデータセンター基盤をクラウドへ移行し、複数のミドルウェアとデータレイクを統合した
- 責任者の Sastry Durvasula 氏（Chief Operating, Information, and Digital Officer）は「これはテック施策であると同時に、大規模な文化と人の変革だ」と述べている
数字より、KPIの置き方が本質だ
私がこの事例で一番効くと思ったのは、87という展開数ではない。Durvasula 氏の「最初の1年目、2年目にどのKPIを出せるのかについて正直になれ。事業インパクトが本当に出始めるのはいつなのかも含めて」という一節だ。
基幹刷新の相談を受けると、初回の議題はたいてい「どのパッケージか」「クラウドか」になる。だが実際に案件を殺すのは技術選定ではなく、測定の時期を握れていないことのほうが多い。1年目に事業KPI（売上・リードタイム）で評価される契約になっていると、まだ土台を作っている段階で「効果が出ていない」と判断され、予算が細る。TIAAがフェーズ1で出したのは「共通プラットフォーム10個」という足場の数であり、87ユースケースや35%高速化という事業側の数字はフェーズ2で出している。この順番が、取締役会との合意事項として最初から設計されている。
「今日の問題」と「昨日の問題」を同時に解く
もう一つ実務的なのは、「我々の規模の会社なら当然だが、昨日・今日・明日の問題を同時に解いている」という認識だ。EOL基盤の8割超という状態は、放置してきた昨日の問題である。一方で事業側は新商品を出したい。両方を同時に進める前提で計画を切ったからこそ、刷新の途中でも MyChoice のような新商品や、パートナー連携用の API 基盤（TIAA Gateway）を出せている。
刷新プロジェクトが止まる典型は、「まず全部を新しくしてから新機能を作る」という直列の計画を立てることだ。並列にすると管理は面倒になるが、事業側の成果が途中で1つも出ない計画は、途中で殺される。
開発を生業にしている側にとって何が変わるか
これは発注側だけの話ではない。受託・SIerとして基幹刷新を受ける側の見積と契約の切り方に、そのまま効く。
- フェーズを分けるだけでは足りない。 フェーズごとに「この期間に測る指標」を提案書に書き、発注側の決裁ラインと合意しておく。技術負債の削減率やEOL資産の残数は、事業KPIが出る前の年度でも説明できる数字になる。
- 一括請負で全体を握るより、要件定義と第1フェーズを分けて契約するほうが、双方の期待値がずれにくい。 当社でも要件定義だけの依頼は受けている。刷新の全体像が見えていない段階で総額を握ると、後から必ず揉める。
- 「文化と人の変革」の工数を見積に載せる。 TIAAはレガシー担当者のアップスキリングと職種転換、部門横断の変更管理チームまで実施している。ここを発注側の自助努力として見積から外すと、稼働後に使われないシステムが残る。受け手としては、教育・移行支援を独立した項目として出したほうが誠実だ。
AI についても同じ構図だと私は見ている。TETRIS では AI の導入がスキル向上の必要性を組織に認識させる契機になった、とされている。AIツールを入れること自体より、データが1か所に集まっていること、権限とログが整理されていることが前提になる。基幹刷新はその前提を作る作業でもある。順番を飛ばしてAIだけ載せても、載る場所がない。
この記事を読んだあとに
基幹システムそのものの定義や、刷新の一般的な進め方は次の記事にまとめている。
製造業で、基幹を残したまま現場側の仕組みを足す構成を検討している場合は、基幹・ERPを残したまま現場システムをつなぐ設計に、連携方式と「どちらを正とするか」の決め方を整理した。
出典: Inside TIAA's massive IT transformation to fuel business growth
シンシアの開発事例
**2026年2月の開発着手から約5.5ヶ月で、アパレル企業向けAIクリエイティブ基盤としてプレスリリース公開まで到達しました（2026年7月29日発表）。**
Cloverse様の発表によれば、Clovia Enterprise は PUMA社・ルック社をはじめとする**30社以上のアパレルブランドとの検証**を経ており、現在は先行導入企業（Founding Partner）を限定募集する段階に入っています。
開発規模は次のとおりです（2026年7月29日時点、リポジトリ実測値）。
| 指標 | 実績 |
|---|---|
| 開発体制 | エンジニア4名 |
| 開発期間 | 2026年2月13日〜（継続中） |
| コミット数 | 約1,480 |
| プルリクエスト | 373本 |
| 対応イシュー | 428件 |
| 実装計画ドキュメント | 162本 |
| データモデル | 83テーブル |
### この事例からの示唆
**生成AIプロダクトの難所は、モデルではなく業務側にある。** 画像を1枚生成すること自体は、いまや誰でもできます。事業として成立させるために必要だったのは、マスター管理・制作進行・レビュー・権限・課金・非同期処理といった、業務を回すための地味な設計でした。83テーブルという規模は、その事実を素直に表しています。
**未知の業界のプロダクトは、業務を理解した側が設計しないと形にならない。** アパレルEC制作の工程を知らないまま「AIで画像生成する機能」を作っても、現場では使われません。ヒアリング・R&D・プロトタイプ・提案までを開発チームが担ったのは、そうしないと仕様が決まらない領域だったからです。この構造は[「使われないシステム」が生まれる要件定義の失敗](https://blog.xincere.jp/articles/why-unused-systems-are-born-requirements-definition)とちょうど裏返しの関係にあります。
**モデル選定に正解が無い領域では、検証を設計プロセスに組み込む。** どの生成モデルを使うかは半年で変わります。だからこそ、モデルを差し替えられる構造と、検証結果を機能設計に反映し続ける進め方の両方が必要でした。
### よくある質問
**Q. 生成AIを使ったプロダクトの開発は、通常のシステム開発と何が違いますか。**
A. 最も違うのは、着手時点で仕様が確定できない点です。どのモデルがどの品質を出せるかは検証しないと分からないため、R&Dとプロトタイプを設計工程に組み込む必要があります。一方で、組織・権限・課金・非同期処理といった土台は通常のSaaS開発と同じ設計が求められます。
**Q. 業界知識がない領域でも開発支援を依頼できますか。**
A. できます。この事例ではアパレルEC制作の業務理解から入り、ヒアリングとプロトタイプを通じて要件そのものを一緒に作りました。仕様が固まっていない段階からのご相談のほうが、むしろ手戻りが少なくなります。
**Q. どのくらいの体制・期間の支援ですか。**
A. エンジニア4名、2026年2月から継続中です。プレスリリース公開までは約5.5ヶ月でした。規模や費用感の考え方は[システム開発とは](https://blog.xincere.jp/articles/what-is-system-development)で解説しています。
### 関連する支援領域
- [AIシステム開発とは？開発の流れ・費用相場・失敗しない進め方](https://blog.xincere.jp/articles/ai-system-development-guide) — 生成AIプロダクト開発の全体像
- [AI PoCの進め方5ステップ｜「PoC止まり」を防ぎ本番導入につなげる実践手順](https://blog.xincere.jp/articles/ai-poc-how-to-proceed) — 検証を本番に接続する設計
- [FDE（Forward Deployed Engineer）が示す、上流から伴走できるエンジニアの価値](https://blog.xincere.jp/articles/fde-forward-deployed-engineer-upstream-value) — 本事例の進め方の背景
生成AIを使った新規プロダクトの立ち上げや、仕様が固まりきっていない段階からの開発支援については、[開発のご相談](https://blog.xincere.jp/contacts)からお問い合わせください。
**出典:** [アパレル企業向けAIクリエイティブ基盤「Clovia Enterprise」提供開始（株式会社Cloverse / PR TIMES, 2026-07-29）](https://prtimes.jp/main/html/rd/p/000000024.000139250.html)
株式会社Cloverseの事例を読む →
