富士通「AIドリブンモダナイゼーション」で移行40%短縮は本当か｜経営者が鵜呑みにする前の検証観点とセカンドオピニオンの使いどころ

結論：40%短縮は「工程の一部が速くなる」という自社主張であり、刷新全体の成否は上流の判断で決まる

2026年7月14日、富士通は「Fujitsu AIドリブンモダナイゼーションサービス」の国内提供を開始したと発表しました（富士通ニュースリリース）。老朽化した既存システムのリライト（プログラムの書き換え）とリホスト（基盤の載せ替え）を中心に、生成AIでレガシー刷新を自動化・最適化し、「工程期間を約40%短縮することが可能」と謳っています。自社AIプラットフォーム「Fujitsu Kozuchi」と大規模言語モデル「Takane」を軸に、案件のセキュリティ要件等に応じてAnthropicの「Claude」やOpenAIの「GPT」も組み合わせる"マルチAI型"のアプローチと、レガシー技術に精通した専門エンジニア「モダナイゼーションマイスター」の実践知を融合させる、というのが売り文句です。想定顧客は法改正の多い金融・公共・医療分野と、業務が複雑な製造業・流通業。価格は非開示です。

まず数字の性格を正確に押さえてください。「約40%短縮」は富士通が自社サービスの効果として掲げる主張であり、あらゆる案件で同じ短縮率が再現されることを保証するものではありません。短縮が効くのは主に「解析・変換・テストコード生成」といった工程であって、刷新プロジェクト全体の期間そのものが一律4割縮むという意味ではない、と読むのが安全です。基幹刷新の総工数のうち、AIが肩代わりできる純粋なコード変換の割合は案件によって大きく変わります。ブラックボックス化した仕様の掘り起こし、業務側との合意形成、データ移行、受け入れテスト、本番切替の段取り——ここは相変わらず人と組織の仕事であり、AIで自動的に4割速くなる領域ではありません。

だからこそ経営としての結論はこうです。「AIで移行が40%速くなる」という提案を受け取ったら、速さを喜ぶ前に「どの工程が、なぜ速くなるのか」「自社のシステムはAIが効く型か、効かない型か」を分解して確認する必要があります。本記事は、この富士通の新サービスのGA（一般提供開始）という製品ニュースを起点に、大手ベンダーからAI移行提案を受けたときに発注側がどこを検証すべきか、リホスト・リライト・リビルドの違い、上流判断の見極め方、ベンダーへの質問テンプレ、そして中堅企業が過剰投資を避けるためのスコープの絞り方を整理します。なお、AI自動変換の技術そのもの（COBOL→Javaの変換品質をどう検証するか）は既報富士通×IBM COBOL→Java自動変換の実像で扱っています。本稿はそこに重複させず、「サービスの採否と移行方式の判断」に絞ります。

この記事を読むべき人

• 大手ベンダーやSIerから「AIでレガシー刷新を高速化する」提案を受けており、その妥当性を自社で判断できずにいる経営者・役員
• 20〜30年もの基幹システム（COBOL・メインフレーム・古いオープン系）を抱え、刷新の必要は分かるが「どの方式で・どこまでやるか」を決めきれない事業責任者
• 社内にIT意思決定力が弱く（情シス0〜1名・兼任）、ベンダー提案を鵜呑みにするしかない状態に不安を感じている実務決裁者
• 過去にPoCや部分刷新が本番化せず頓挫した経験があり、次こそ失敗を避けたい経営層
• 「40%短縮」「AIで自動移行」といった数字が独り歩きしており、投資判断の前に第三者の目を入れるか迷っている方

何が発表されたのか：事実を正確に押さえる

まず一次情報ベースで、今回発表された内容を整理します。ここは富士通の公式リリースに書かれている事実のみを記載し、推測は分けて後述します。

ポイントは、これが「複数のAIを使い分けるマルチAI型」で「人の実践知と融合させる」と明示している点です。裏を返せば、AI単体で全自動移行が完結するわけではなく、レガシーに精通した人の知見が前提になる、と富士通自身が認めている構図です。これは技術的に誠実な設計思想ですが、発注側にとっては「結局その人の知見に品質が依存する」という意味でもあります。二次報道でも同様の内容が報じられています（IT Leaders、DXマガジン）。

「40%短縮」を経営者が鵜呑みにする前に確認すべきこと

刷新プロジェクトで最も高くつく失敗は、「速く・安く・自動で」という言葉に引かれて発注し、後工程で想定外の追加費用と遅延が噴出することです。40%という数字を投資判断に使う前に、次の3点を必ず分解してください。

1. 「工程期間」の分母は何か

40%短縮の対象が「解析・変換・テストコード生成」なのか、「要件定義から本番稼働までの全工程」なのかで、経営インパクトはまったく違います。一般に基幹刷新の総工数のうち、純粋なコード変換が占める割合はそれほど大きくありません。現行仕様の掘り起こし、業務部門との調整、データ移行設計、受け入れテスト、移行リハーサルと本番切替——これらが工数の多くを占めます。もしAIが効くのが変換工程だけなら、その工程が4割速くても、プロジェクト全体では1〜2割程度の短縮にとどまる可能性があります。提案を受けたら「40%の分母はどの工程か、全体スケジュールでは何%か」を最初の一問にしてください。

2. 自社のシステムは「AIが効く型」か

AI変換が効きやすいのは、仕様書が残っていて、ロジックが素直で、外部連携が少なく、テストデータが整っているシステムです。逆に、仕様書が失われていて担当者しか動作を知らない、業務ルールがコードの中に暗黙的に埋め込まれている、他システムとの連携が複雑に絡み合っている——こうしたシステムでは、AIは「書いてあるコード」は読めても「なぜそう書いたか」は読めません。40%短縮が効く領域と効かない領域を、自社システムの現実に当てはめて評価する必要があります。

3. 短縮の対価として何を差し出すか

移行を速くするために「現行踏襲（今の仕様をそのまま新環境へ移す）」を選ぶと、確かに変換は速くなりますが、古い業務プロセスと技術的負債もそのまま新環境に持ち込むことになります。速さを取れば刷新の質が犠牲になり、質を取れば速さの一部を手放す——このトレードオフを理解せずに「速い」だけで飛びつくと、数年後に「刷新したのに古いまま」という二重投資に陥ります。

AI移行の成否を分けるのは「変換精度」ではなく「上流の判断」

ここが本記事で最も伝えたい点です。AI移行プロジェクトの成否は、自動変換ツールの精度で決まるのではありません。プロジェクトの一番上流で下す4つの判断で、8割方が決まります。

判断軸1：現行踏襲かFit to Standardか。 今の業務のやり方をそのままシステムに写す（現行踏襲）のか、標準的な業務プロセスに業務側を合わせる（Fit to Standard）のか。前者は移行が速く現場の抵抗も少ないが、負債を温存します。後者は業務改革を伴うため重いが、刷新の効果は大きい。AIで変換を速くする話は、この根本方針が決まって初めて意味を持ちます。方針が曖昧なまま「速い移行」に飛びつくと、何を目指した刷新なのか分からなくなります。

判断軸2：仕様のブラックボックス度。 現行システムの仕様がどれだけ文書化されているか、担当者の頭の中にしかない暗黙知がどれだけあるか。ここが移行難易度とAIの効き方を大きく左右します。ブラックボックス度が高いほど、AI変換の前段で「仕様の掘り起こし」に人手と時間がかかり、40%短縮の前提が崩れます。

判断軸3：データ移行の設計。 古いシステムのデータは、形式・文字コード・欠損・重複・業務上の例外値が入り乱れていることが珍しくありません。プログラムの変換が終わっても、データが正しく移らなければシステムは動きません。データ移行はAIで自動化しづらく、しばしばプロジェクト最大の難所になります。提案書にデータ移行の工程と検証方法が具体的に書かれているかを必ず確認してください。

判断軸4：テストの網羅性。 AIが変換したコードが「動く」ことと「業務として正しく動く」ことは別です。変換後のシステムが現行と同じ業務結果を出すことを、どう網羅的に検証するのか。テスト設計・テストデータ・現新比較（旧システムと新システムの出力を突き合わせる検証）の計画が、品質の最後の砦です。ここが薄い提案は、本番後にトラブルが噴出します。

この4つはいずれもAIが肩代わりできない、発注側と実装側が一緒に汗をかく領域です。自動変換の華やかさに目を奪われず、この上流の設計にどれだけの工数と人が割かれているかを見てください。

リホスト・リライト・リビルドの違いと、40%短縮が効く領域

移行方式の言葉が曖昧なまま議論すると、期待値がずれます。代表的な3方式を整理します。

富士通の新サービスは「リライト・リホストを中心」と明示しています。つまり40%短縮が最も効くのは、リライト工程のコード変換とテストコード生成です。逆に、業務そのものを作り変えるリビルドや、上流の要件定義・合意形成、データ移行、受け入れテストといった領域では、この数字はそのまま当てはまりません。「うちは業務プロセスから見直したい」という会社が、リライト前提の高速化提案をそのまま受けると、目的と手段がずれます。自社が本当に必要としているのがどの方式かを、提案を受ける前に整理しておくことが重要です。

「AIが読めない仕様」をどう扱うか

AI移行で最も過小評価されるのが、「AIが読めない仕様」の存在です。ソースコードに書かれているロジックはAIが読めます。しかし次のようなものは、コードには残っていません。

• 「月末の特定条件のときだけ手作業で数値を補正している」という運用でカバーされてきた例外処理
• 「この項目は使っていないように見えるが、年に一度の決算処理でだけ参照される」という滅多に動かない業務
• 「なぜこの計算式なのか」という、当時の業務判断や法制度の背景
• 別システムやExcel、紙の帳票と暗黙的に連携している業務の流れ

これらは現行コードを完璧に変換しても引き継がれません。むしろ「コードには無いが業務には有る」ため、変換後に「前は動いていた処理が動かない」という形で顕在化します。AI移行を検討するなら、変換の前に「コードに書かれていない業務知識」を棚卸しし、誰がそれを知っているか、退職・異動でその知識が失われていないかを確認する工程が不可欠です。この棚卸しを省いた高速移行は、速く失敗するための近道になりかねません。

大手ベンダーのAI移行提案を受けたときの、ベンダー質問テンプレ

提案を受ける立場の経営者・実務決裁者が、そのまま使える質問集を用意しました。技術に詳しくなくても、これらを尋ねてベンダーの回答の具体性を見れば、提案の質はかなり見極められます。

1. 「40%短縮の分母はどの工程ですか。全工程で見ると何%の短縮になりますか」 ——分母をぼかす回答なら要注意です。
2. 「当社のシステムのうち、AI変換が効く部分と効かない部分をどう見積もっていますか」 ——一律に「全部効く」という回答は現実を見ていません。
3. 「現行仕様のうち文書化されていない部分を、どの工程で・誰が掘り起こしますか」 ——ここが曖昧なら後で追加費用が出ます。
4. 「データ移行の設計・検証はどの工程で、どれだけの工数を見ていますか」 ——提案に具体的な記載がなければ、最大の難所が見えていません。
5. 「変換後の品質検証（現新比較・受け入れテスト）はどう設計しますか。テストデータは誰が用意しますか」 ——テストの主語が発注側に丸投げされていないか確認します。
6. 「AIが変換したコードの著作権・保守性・可読性はどうなりますか。将来、御社以外でも保守できますか」 ——新たなベンダーロックインを避ける質問です。
7. 「本番切替の方式（一括か段階か）と、切り戻し（失敗時に元へ戻す）計画はありますか」 ——切替の段取りは工数と危険の両方が集中します。
8. 「価格が非開示とのことですが、当社規模での概算レンジと、追加費用が発生する典型条件を教えてください」 ——価格の透明性はそのままベンダーの誠実さの指標です。

これらの質問への回答が具体的で、リスクを正直に語るベンダーは信頼できます。逆に、すべてを「AIが解決します」「やってみないと分かりません」で流すベンダーは、契約後にトラブルの火種を抱えることになります。

中堅企業が過剰投資を避けるための、移行スコープの絞り方

売上10〜100億円規模の中堅企業にとって、大手向けのフルスペックな刷新提案をそのまま受けるのは、しばしば過剰投資です。過剰投資を避ける鍵は、「全部を一度に刷新しない」ことです。

• 止血と刷新を分ける。 「サポート切れで動かなくなる」といった差し迫った危険（止血）と、「業務を良くする」ための刷新は、緊急度が違います。まず止血すべき範囲だけを最小コストで対処し、業務改革は別プロジェクトとして計画する方が、投資も危険も分散できます。
• 使われていない機能を運ばない。 長年の基幹システムには、実際にはもう使われていない機能が大量に眠っていることがあります。それを丸ごと変換するのは、使わないものにお金を払う行為です。移行前に「本当に使っている機能」を棚卸しし、変換対象を絞るだけで、費用も期間も圧縮できます。
• 段階移行を前提に区切る。 一括で全システムを切り替えるビッグバン移行は、失敗したときの被害が最大化します。業務の区切りごとに段階的に移すことで、各段階で学びを得ながら危険を抑えられます。AIによる高速化は、この各段階の変換工程で効かせるのが現実的です。
• 「速さ」で決めず「戻せるか」で決める。 速い移行より、失敗したときに戻せる移行の方が、経営としては安全です。切り戻し計画が具体的な提案を優先してください。

これらは大手ベンダーの提案を否定するものではありません。むしろ、優れたツールとエンジニアを持つベンダーに対して、発注側が「自社にとって適正なスコープ」を主体的に定義できるかどうかが、投資対効果を左右します。

よくある質問（FAQ）

Q. 富士通の「40%短縮」は信じてよい数字ですか。 A. これは富士通が自社サービスの効果として掲げる主張であり、あらゆる案件で同じ短縮率が保証されるものではありません。短縮が効くのは主にリライト工程のコード変換・テストコード生成であり、要件定義・データ移行・受け入れテスト・本番切替を含む全工程がそのまま4割縮むという意味ではないと読むのが安全です。自社システムの型に当てはめて評価してください。

Q. AIで移行すれば、社内にIT人材がいなくても刷新できますか。 A. 富士通のサービスも「レガシーに精通した専門エンジニアの実践知と融合する」と明示している通り、AI単体で全自動移行が完結するわけではありません。特に、コードに書かれていない業務知識の棚卸しや、変換後の業務レベルでの品質検証は、発注側の関与が不可欠です。IT人材が薄い会社ほど、発注前の要件整理と、第三者による提案の妥当性チェックが効いてきます。

Q. リホストとリライトのどちらを選ぶべきですか。 A. 目的次第です。差し迫ったサポート切れの回避（延命）が主目的ならリホストが速く安価ですが、古い負債を温存します。技術的負債を解消し将来の保守性を高めたいならリライトですが、変換品質の検証が重要になります。業務そのものを作り変えたいならリビルドで、これはAI高速化の恩恵が限定的です。まず「何のための刷新か」を先に決めてください。

Q. 価格が非開示ですが、どう予算を考えればよいですか。 A. 富士通は今回のサービスの価格を公表していません。予算を考える際は、変換工程だけでなく、仕様の掘り起こし・データ移行・受け入れテスト・本番切替まで含めた全体像で見積もりを取ること、追加費用が発生する典型条件（未文書仕様の掘り起こし、想定外のデータ不整合など）を事前に確認することが重要です。

Q. 既に大手ベンダーから提案を受けています。第三者に見てもらう価値はありますか。 A. 提案の技術力そのものではなく、「自社の目的とスコープに提案が合っているか」「40%短縮の前提が自社に当てはまるか」「見えていない工数や危険がないか」を客観的に確認する意味で、第三者の視点は有効です。特にIT意思決定力が薄い会社ほど、ベンダーの提案を評価する軸を持てないまま契約に進むリスクが高いため、発注前のセカンドオピニオンが効きます。

Q. AIが変換したコードは、将来ほかの会社でも保守できますか。 A. これは提案時に必ず確認すべき点です。特定ベンダーの独自技術や独自ツールに深く依存する変換は、新たなベンダーロックインを生みます。変換後コードの可読性・保守性・ドキュメント整備の方針を、契約前に質問してください（本テーマの技術的な検証観点は、既報の富士通×IBM COBOL→Java自動変換の実像でも整理しています）。

GXOに相談すべきタイミング

大手ベンダーからAI移行の提案を受けたとき、その提案の技術力を疑う必要はありません。問題は、提案を評価する軸を発注側が持てているか、です。次のような状態にあるなら、契約に進む前に第三者を入れる価値があります。

• 「40%短縮」「AIで自動移行」という言葉に魅力を感じているが、その前提が自社に当てはまるかを判断できない
• 社内にIT意思決定力が弱く、ベンダー提案の妥当性を評価できないまま話が進んでいる
• 現行システムの仕様がブラックボックス化しており、何を刷新対象にすべきか自社で棚卸しできていない
• 過去にPoCや部分刷新が本番化せず頓挫した経験があり、今度こそ失敗を避けたい

こうした場面では、まず自社の現状とAI移行の妥当性を客観的に測るAI導入の妥当性診断（AIアセスメント）を入り口にするのが有効です。「そもそもAIで刷新すべきか」「どの方式が自社に合うか」を、特定ベンダーの製品ありきではなく中立的に評価します。刷新の方式選定や移行計画の具体化まで踏み込むならレガシーモダナイゼーションの進め方を、要件定義から実装までを含めた開発の設計を第三者の目で確認したいならシステム開発のセカンドオピニオンをご覧ください。

「この提案を受けてよいか、発注前に一度整理したい」という段階でのご相談を歓迎します。契約後に追加費用や遅延で困ってからではなく、判断の前に構造を整理することが、中堅企業にとって最も費用対効果の高い一手です。GXOへのご相談はこちらから、現状とお悩みをお聞かせください。

参考文献

• 富士通「AIを活用し既存システムのモダナイゼーションを支援する新サービスを提供開始」
• IT Leaders「富士通、レガシーシステムのリライト/リホストを生成AIで支援、移行期間を4割短縮」
• DXマガジン「古いシステムを自動で現代のプログラムに書き換える！富士通の最新マルチAI移行サービスとは？」