Fujitsu Application Transform 代替5方式と無料で試す手順 (2026年版)

Fujitsu Application Transform代替5方式と無料で試す手順 (2026年版)

この記事のポイント Fujitsu Application Transform powered by Fujitsu Kozuchiは、COBOLなどのレガシーなソースコードを読み取って設計書を自動で起こすSaaSです。2026年3月30日に国内提供が始まりました。ただ公開価格が出ておらず、まず見積り相談から入る形になります。「その前に自分たちで試したい」「もっと安く済ませたい」という要望に対しては、汎用のAIコーディングエージェント、オープンソースの静的解析、社内資料を読ませて答えさせる仕組み(RAG)、他社のモダナイゼーション支援、上位サービスへの移行という5つの代替ルートがあります。この記事では判断軸と、無料で始める検証手順を整理します。

「設計書が残っていないCOBOLの塊があって、誰も中身を説明できない」。この状況にいる情シスの方が、富士通の新サービスの名前で検索して、ここに辿り着いているはずです。答えを先に置きます。いきなり見積りを取る前に、手元の汎用AIエージェントで1本だけ設計書を起こしてみるのが最短です。 そこで出てきた品質が、あらゆる見積りの評価基準になります。

Fujitsu Application Transformとは、どんなサービスなのか

Fujitsu Application Transform 代替5方式と無料で試す手順 (2026年版) 図2

Fujitsu Application Transform powered by Fujitsu Kozuchiとは、既存システムのソースコードを生成AIで解析し、設計書を自動で作り直すSaaSです。富士通の発表によると、国内提供の開始は2026年3月30日で、設計書生成にかかる時間を約1/30まで縮められるとされています。

もとになっているのは、アプリケーション資産からプログラム仕様書やジョブフロー図を起こす「設計書リバースサービス」です。そこに生成AIを載せ、SaaSとして誰でも申し込める形にした、という位置づけになります。

対象として名前が挙がっているのはCOBOLです。ここが重要なポイント。汎用のAIツールが最も苦手とする領域を、正面から狙っているサービスです。

さらに2026年度中には、既存ソースコードを将来に向けて作り直す機能なども順次追加される予定が示されています。つまり「読む」だけで終わらず「書き換える」ところまで伸ばしていく設計になっています。

項目内容
提供形態SaaS（日本国内向け）
提供開始2026年3月30日
主な対象COBOL等のレガシーなソースコード
主な出力プログラム仕様書、ジョブフロー図などの設計書
訴求効果設計書生成の時間を約1/30に短縮
今後の拡張2026年度中に既存ソースコードのリビルド機能などを追加予定
公開価格出ていない（問い合わせベース）

つまり、機能の方向性ははっきりしている一方で、価格の見通しが立てにくいサービスです。ここが代替を探す動機の中心になります。

なぜ「代替」を探す人が多いのか

Fujitsu Application Transform 代替5方式と無料で試す手順 (2026年版) 図3

代替検索が発生する理由は、機能不足ではなく「入口の重さ」に集中しています。価格が読めない、稟議が通らない、ソースを外に出す判断が降りない、の3つです。

問い合わせから見積り、PoC(試験導入)の合意まで進むと、動き出すまでに数週間から数か月かかります。その間、レガシーシステムの担当者は何も前に進められません。

もうひとつが、ソースコードの持ち出し判断です。金融や公共の案件では、コードを社外のSaaSに送る時点で稟議が止まります。ここは技術の話ではなく、社内規程の話。ツールを変えても解けません。

そして規模の問題。数万ステップの小さな資産に対して、大規模モダナイゼーション向けの体制を組むのは、正直オーバースペックです。

富士通側も上位の選択肢を用意しています。2026年7月14日には、Kozuchiと自社の大規模言語モデルTakane、さらにAnthropicのClaudeを含む外部モデルを組み合わせた「Fujitsu AI-Driven Modernization Service」の国内提供が発表され、レガシー刷新を40%加速すると打ち出されました。大規模な刷新なら、Application Transform単体ではなくこちらが本命になります。

小さく速く試したいのか、全社刷新を任せたいのか。ここで道が分かれます。

代替を選ぶ前に決めるべき3つのこと

Fujitsu Application Transform 代替5方式と無料で試す手順 (2026年版) 図4

代替選びで失敗する人は、ツールから入ります。先に決めるべきは、ソースを外に出せるか、誰が読む設計書か、資産の規模はどれくらいか、の3点です。

ソースコードを社外に送れるか。 送れるならAIエージェントもSaaSも全部候補です。送れないなら、候補は一気に「オンプレで動くOSS」と「閉域で動く商用サービス」の2つに絞られます。この1問で選択肢の半分が消えます。

設計書を読むのは誰か。 保守メンバーが読む内部資料なら、多少ラフでも動きます。発注仕様書として外に出すなら、用語の統一と体裁の一貫性が必須になり、AI任せでは足りません。

資産の規模。 1万ステップと100万ステップでは、必要なものが違います。前者は指示文の工夫で片付き、後者は解析基盤とワークフローの話になります。

判断軸「小さく試す」向き「本格導入」向き
ソース持ち出し可（社内規程で許容）不可、または閉域必須
設計書の読み手保守チーム内部発注先・監査・第三者
資産規模〜数万ステップ数十万ステップ以上
予算月数千円〜数万円個別見積り
期待する成果中身の把握、棚卸し刷新計画そのもの

この表で右側に3つ以上当てはまるなら、代替を探すより本家や上位サービスの見積りを取るほうが早いです。左側が多いなら、以下の方式が効きます。

代替は5方式に分かれる

Fujitsu Application Transform 代替5方式と無料で試す手順 (2026年版) 図5

代替候補は、汎用AIエージェント、オープンソース構成、RAG構成、他社の支援サービス、上位サービスへの移行という5つに整理できます。それぞれ得意な規模とコストがまったく違います。

まず全体像を置きます。

方式中身初期コスト向く規模弱点
① 汎用AIエージェントClaude Code等にコードを読ませて設計書を書かせる無料〜月額数千円/人〜数万ステップCOBOL方言と長大ファイルに弱い
② OSS静的解析+図生成構文解析で呼出関係を抽出し図に起こす無料（人件費のみ）規模を選ばない「何をする処理か」の言語化は不可
③ RAG構成既存の断片資料+コードを検索対象にして答えさせる数万円/月〜資料が散在する現場構築に技術者が要る
④ 他社モダナイゼーション支援国内SIerの解析・移行サービス個別見積り数十万ステップ以上入口の重さは本家と同じ
⑤ 上位サービスへ移行Fujitsu AI-Driven Modernization Service等個別見積り全社刷新小規模には過剰

つまり、①と②を組み合わせて自前で回すのが、最も安く速い入口になります。以降はこの2つを掘り下げます。

無料で始めるならどの方式が現実的？

無料で成果が出るのは①の汎用AIエージェントです。既存の開発環境にそのまま入れられて、その日のうちに1本目の設計書が出ます。

具体的には、Claude Code のようなターミナルで動くエージェント、GitHub Copilot や Cursor のようなエディタ統合型、Cline や Continue のようなオープンソース寄りの拡張が候補です。無料枠の広さと、扱えるコード量の上限で選びます。

やることは単純。1本のプログラムを丸ごと読ませて、「このプログラムの入力・出力・処理条件・呼び出す外部資源を、表形式の仕様書にまとめてください」と指示するだけです。

ここで出てきた結果が、判断のすべてになります。読める設計書が出たなら、その延長で数十本まで一気に処理できます。出なければ、②や④の出番です。

ツール種別代表例無料での試しやすさレガシー言語の耐性
ターミナル型エージェントClaude Code中（サブスク前提）長いファイルを分割処理しやすい
エディタ統合型GitHub Copilot / Cursor高（無料枠あり）補完は強いが一括解析は苦手
OSS拡張Cline / Continue高（自分のAPIキーで従量）設定次第。ローカルLLMも可
資料読み込み型NotebookLM高コードより既存ドキュメント向き
自律開発型Devin低（有料前提）改修まで任せる用途

要するに、エディタ統合型でまず感触を掴み、本番の一括処理はターミナル型に寄せるのが安全な進み方です。ツールの選び分けをもう少し詳しく見るなら、AIコーディングのカテゴリ一覧に主要な選択肢がまとまっています。

オープンソースだけで組むとどこまでできる？

OSSだけでも「構造」は完全に取り出せます。取り出せないのは「意味」です。ここの線引きを間違えると、時間を溶かします。

構文解析器でソースを読み、呼び出し関係やファイルI/Oを抽出して、図に起こす。この部分はOSSの独壇場です。tree-sitterやANTLRのような構文解析基盤、GnuCOBOLのCOBOL処理系、Doxygenの相互参照生成、PlantUMLやMermaidの図生成を組み合わせれば、ジョブフロー相当の図はかなりの精度で出ます。

しかも決定的な利点がひとつ。コードが1バイトも外に出ません。 持ち出し禁止の現場では、これがそのまま採用理由になります。

一方で「この処理は月末の締め判定をしている」という業務的な言語化は、構文解析からは出てきません。そこはAIか人間の仕事です。

  • 構造の抽出（呼出関係、変数の流れ、ファイルI/O）→ OSSで十分
  • 図の生成（ジョブフロー、モジュール関連図）→ OSSで十分
  • 業務的な意味づけ → AIか人間が必要
  • 用語の統一と体裁 → テンプレート整備で人が担保

現実解は、OSSで骨格を作り、意味づけの文章だけAIに書かせる分業です。この形なら、外に出るのはコードそのものではなく、抽象化された構造情報だけにできます。

日本語の設計書はどこまでの品質で出せる？

日本語の出力自体は問題になりません。詰まるのは、社内の用語と設計書の体裁に合わせる部分です。

主要なAIモデルはどれも日本語の技術文書を書けます。「入力項目」「処理概要」「異常系」といった見出しで表を作らせれば、そのまま読める形で出てきます。

問題は揺れです。同じ処理を「締め処理」と書いたり「クロージング処理」と書いたりする。この揺れは、社内の用語集を先に渡すことで大きく減らせます。

具体的には、既存の設計書を1本だけ「お手本」として与え、「この体裁と用語に合わせて出力してください」と指示します。ゼロから書かせるより精度が上がります。

つまずき症状対処
用語の揺れ同義語が混在する用語集と既存設計書1本を先に渡す
粒度の不統一本ごとに詳しさが違う見出し構成をテンプレート固定
推測の混入根拠のない業務説明が入る「コードから読み取れない事は不明と書く」と明示
長いプログラムの欠落後半が要約されて消える段落単位に分割して処理

最も危ないのは3つ目の推測混入です。AIがそれっぽい嘘をつくこと(ハルシネーション)は設計書でも起きます。「不明と書く」ルールを最初に明示するだけで、レビューの負荷が変わります。

ここまでの整理: 代替の中心は①汎用AIエージェントと②OSS静的解析。前者は意味づけに強く、後者は構造抽出と持ち出し禁止に強い。日本語品質は指示文の設計でほぼ決まる。残るリスクはCOBOL固有の事情とコストです。

COBOL資産で特に気をつけたい点

汎用AIエージェントがCOBOLでつまずく原因は、言語そのものより「方言」と「ファイルの長さ」にあります。本家サービスがこの領域を明示的に狙っているのは、そこが難所だからです。

メーカー独自の拡張構文、COPY句で分散した定義、JCLとの連携。これらは学習データに乏しく、AIの推測が当たりにくい領域です。

対処は3つ。COPY句を先に展開してから読ませる。JCLを設計書の入力に含める。1本を機能単位に分割してから処理する。この前処理をやるかどうかで、出力の質が大きく変わります。

それでも精度が出ない場合、無理に汎用ツールで押し切らないほうが賢明です。数十万ステップ規模で方言が濃い資産は、④や⑤の商用サービスが素直に効きます。時間を買う判断。

社内システムの棚卸しという文脈では、内部監査AIツールの選び方が参考になります。監査の観点で「何が資産として残っているか」を整理する手順は、レガシー棚卸しとほぼ同じ発想です。

費用はどう変わる？見積もりの考え方

代替方式のコストは、ライセンス料ではなく「人が何時間触るか」で決まります。ここを見誤ると、無料のはずが一番高くつきます。

汎用AIエージェントの直接費は、1人あたり月数千円から数万円の範囲に収まります。API従量課金を使う場合も、数十本の設計書生成で大きな金額にはなりません。

効いてくるのは、前処理とレビューの人件費です。分割・COPY句展開・出力チェックを含めると、1本あたり30分から1時間はかかります。100本なら50時間から100時間。

コスト要素① AIエージェント② OSS構成④⑤ 商用サービス
ライセンス月数千円〜/人0円個別見積り
初期構築ほぼ不要数日〜数週間ベンダー側
1本あたり作業30分〜1時間15分〜30分（自動化後）ほぼ不要
レビュー必須必須必要（軽い）
立ち上がり即日数週間数週間〜数か月

つまり本数が少ないうちは①が圧倒的に安く、本数が増えると②の自動化投資が回収され、さらに増えると④⑤の一括委託が有利になります。分岐点はおおむね「数百本」あたり。自社の資産本数を数えるところから始めてください。

セキュリティと持ち出し可否をどう線引きするか

ソースコードを外部サービスに送れるかどうかは、技術ではなく社内規程で決まります。ここを曖昧にしたまま進めると、PoCの後で全部ひっくり返ります。

確認すべきは3点です。送信データが学習に使われないこと、保存期間、そしてデータの所在国。主要な法人向けプランはいずれも学習利用の除外を明示していますが、契約書の該当条項を情シスとして押さえておく必要があります。

送れない場合の現実解は2つ。ローカルLLMを Cline や Continue 経由で使う構成か、②のOSS構成で構造だけ抽出する形です。前者は精度が落ち、後者は意味づけが出ません。それでも規程を破るよりはるかにまし。

AIまわりのセキュリティ製品を横に眺めたいなら、AIセキュリティのカテゴリに関連ツールがまとまっています。

4週間で判断するための検証手順

ベンダー選定に何か月もかける前に、4週間で自社の資産がAIで読めるかどうかを確かめられます。この結果があると、見積りの評価が一気に楽になります。

進め方はこうです。

週やること判断すること
1週目代表的なプログラム3本を選び、汎用AIエージェントで設計書を生成読める品質か、まったく駄目か
2週目用語集と既存設計書を与えて再生成、テンプレートを固定揺れが許容範囲に収まるか
3週目20本に拡大、前処理（分割・COPY句展開）を自動化1本あたりの所要時間
4週目全資産本数×所要時間で総工数を試算、商用見積りと比較自前かベンダーか

3週目で1本30分を切れたなら、自前で回す価値があります。1本に2時間以上かかるなら、商用サービスの見積りを取るべき段階です。

この検証で作った設計書のサンプルは、ベンダーとの商談でもそのまま使えます。「これと同等以上の品質が出るか」を具体物で聞ける。ここが効きます。

リサーチの進め方そのものを効率化したいなら、Feloの完全ガイドで日本語の情報収集を高速化する手順を確認しておくと、ベンダー比較の下調べが短くなります。

AI PICKS編集部の判定

Fujitsu Application Transform powered by Fujitsu Kozuchiは、COBOL資産を抱える大規模な現場にとっては筋の良いサービスです。設計書生成を約1/30に縮めるという訴求は、レガシー刷新の律速が「中身の把握」にあることを正しく突いています。2026年度中にリビルド機能まで伸ばす計画も含めて、方向性は正しい。

ただし、数万ステップ規模で「まず中身を知りたい」だけの現場が最初に触るサービスではありません。 公開価格が出ていない以上、入口は必ず商談になります。そこに数週間かけるより、手元の汎用AIエージェントで3本試すほうが圧倒的に早い。1日で答えが出ます。

判断はシンプルです。資産が数百本を超え、方言の濃いCOBOLで、社内に読める人が残っていないなら、本家か上位のAI-Driven Modernization Serviceに相談する一択。それ以外は、汎用AIエージェントとOSSの組み合わせで十分に戦えます。

そして自前検証をやった側は、商談でも強い。品質の基準を自分の手元に持っているからです。無料で作れる交渉材料を使わない手はありません。

よくある質問（FAQ）

Q. Fujitsu Application Transformの料金はいくらですか？

公開されていません。富士通の発表資料には提供開始日と機能の説明はありますが、価格表は出ていないため、問い合わせベースの個別見積りになります。予算感を掴みたい場合は、自社の資産本数と対象言語を整理してから相談すると話が早く進みます。

Q. 無料で同じことができますか？

設計書の生成という一点に絞れば、汎用のAIコーディングエージェントの無料枠でかなりのところまでできます。ただし前処理とレビューの人手は必ず必要です。「無料」はライセンス費のことであって、工数まで無料になるわけではありません。

Q. オープンソースだけで完結できますか？

呼び出し関係やジョブフロー相当の図までは、OSSの構文解析と図生成ツールで作れます。作れないのは「この処理が業務上どういう意味を持つか」という説明文です。そこはAIか、業務を知る人が埋める必要があります。

Q. 日本語の設計書として使える品質が出ますか？

出ます。ただし用語の揺れが必ず起きるので、既存の設計書を1本お手本として渡し、体裁と語彙を固定してください。この一手間で品質が大きく変わります。

Q. COBOL以外のレガシー言語でも使えますか？

汎用AIエージェント側は、PL/IやVB6、古いJavaなども読めます。むしろCOBOLより情報量が多いぶん精度が出やすい傾向があります。COBOLで苦戦した現場でも、他の言語では素直に動くことが珍しくありません。

Q. ソースコードを外部に送れない場合はどうすればいいですか？

OSSの静的解析で構造を抽出し、そこから作った抽象化済みの情報だけをAIに渡す構成が現実的です。あるいはローカルで動くモデルを使います。精度は落ちますが、規程を守りながら前に進めます。

Q. 富士通の上位サービスとの違いは何ですか？

2026年7月14日に国内提供が発表されたFujitsu AI-Driven Modernization Serviceは、KozuchiとTakane、そしてClaudeを含む外部モデルを組み合わせ、レガシー刷新全体を40%加速すると打ち出されています。設計書生成に絞ったApplication Transformより、刷新プロジェクト全体を任せる位置づけです。全社規模の刷新ならこちらが本命になります。

Q. 生成した設計書をそのまま発注仕様書に使えますか？

そのままは避けてください。コードから読み取れない業務背景が抜けているため、必ず人のレビューを挟む必要があります。たたき台としての価値は高い、という理解が正確です。

関連する比較・代替を見る

自前検証で使うエージェントを選ぶときは、下の比較が判断材料になります。

ツール選定の「型」は分野が変わっても同じです。無料枠の広さ、日本語対応、オープンソースの有無で絞る流れは、AIイラストツールの比較やComfyUIとStable Diffusionの比較でも同じ形を取っています。商用サービスとOSSのどちらに寄せるかで悩んでいるなら、後者の記事の考え方がそのまま応用できます。

大手プラットフォーム側のAI戦略を押さえておきたいなら、Meta AIのガイドでモデル公開の流れを確認しておくと、オープンソース側の選択肢がどこまで伸びるかの見通しが立ちます。

次に読むならこれ。社内システムの棚卸しという同じ課題を別角度から扱った内部監査AIツールの選び方です。設計書を作る前に「何を対象にするか」を決める部分が、実は一番時間を食う工程だからです。

各ツールの公式サイト（一次情報）

料金・機能・対応範囲は各社公式が一次情報です。本記事は公開時点の検証に基づきますが、最新かつ正確な条件は必ず各公式ページで確認してください。