自動化率85%より先に決めるのは
テストしない範囲です

刷新の提案書に自動化率が並び始めた方へ

基幹システムの移行を検討していて、複数のベンダーから「AIで◯%自動化」という提案を受け取っている。そういう段階の方に向けて書いています。

比較すべきなのは、その数字ではありません。

発表された内容

GMOランシステムが2026年8月6日、マイグレーションサービス「Migraty byGMO」の提供を開始しました（プレスリリース）。メインフレームの刷新から、PHP・Java・Railsなど旧バージョンのEOL/EOS対応までを対象としています。

数字には注記が付いています。「自社の実績に基づく参考値。対象言語・コード規模・要件により変動します」。この一文があるかどうかは、提案書を読むときの目印になります。

残りが誰の担当かで金額が変わります

自動変換70〜85%。ここだけ見ると、作業の大半が消えるように読めます。

問題は残りです。15〜30%のコードは人が書く。この部分がどこに現れるかは、事前にはわかりません。自動変換が効かないのは、たいてい独自の制御構造、外部連携、業務ロジックが埋まった箇所です。つまり移行で最も慎重さが要る部分が、まとめて残ります。

そして残った部分の作業は、量ではなく難易度で効いてきます。85%が自動化されても、工数が85%減るわけではない。実際、同じリリースの工数削減は40〜70%と、変換率より低い数字が置かれています。この2つの数字の差が、残りの重さです。

見積もりを比べるときは、自動変換率の高さではなく、この差が説明されているかを見ます。

テスト範囲の一文

このリリースで一番実務的なのは、テストについての記述です。

AIとエンジニアの分析によってテストを実施しない範囲も含めたテスト範囲を明確に決め合意します。テストケースは60〜70%自動生成し、残りは人が作成します。

「テストを実施しない範囲も含めて」合意する。

移行案件で後から揉めるのは、たいていここです。移行後に不具合が出て、その機能がテスト対象だったかどうかで解釈が割れる。ベンダーは「範囲外だった」と言い、発注側は「移行したなら動くはずだ」と言う。どちらも、契約時にその話をしていないから起きます。

やらない範囲を先に文書にすると、その場では気まずい会話になります。「この機能はテストしません」と言われて、気持ちよく合意できる発注者はいません。それでも、移行後に同じ会話をするより桁違いに安く済みます。

診断とパイロットが有料である意味

もう1つ、契約の形として見ておきたい点があります。

メインフレームについては、有料のパイロットでリスクを見極めてから本開発へ進む形が取られています。パイロットの費用は本開発費用に充当できるとされています。

これは、不確実な部分だけを先に小さく買う形です。全体をまとめて発注せず、見積もりの精度が上がらない領域を切り出して、そこだけ先に実費で確かめる。同じ構造が、実証段階のロボット技術を達成度で区切って発注する契約にも現れています。分野は違っても、わからない部分を小さく先に買う、という判断は共通しています。

無料の診断だけで本開発の見積もりが出てくる提案は、その分どこかにリスクを織り込んでいます。安く見えるとは限りません。

倍率の話は別にあります

自動化率や短縮率そのものをどう検証するかは、IBMの「9カ月を3日に」という数字が何と比べられているかで扱いました。同じ事例にIBM自身が別の比較基準を出している、という話です。

また、AIの効きが移行元によって変わることは、メインフレーム撤退で期限が切られた話に書きました。公開情報の少ない国産メインフレームでは、そもそも自動変換率が同じ水準で出ません。

提案書の数字を比べる前に、その数字が自社の移行元で成り立つかを確認する順番になります。

何を持ち帰るか

自動化率は、ベンダーの実力を測る指標としては使えます。ただし金額の根拠としては弱い。

見積もりを左右するのは、残りの15〜30%が誰の担当で、どこまでをテストし、やらない範囲をいつ合意するかです。この3つが契約書に書かれていれば、自動化率が70%でも85%でも、金額は予測できます。書かれていなければ、95%と言われても予測できません。

移行の範囲設定を、ベンダー選定の前に自社側で整理しておきたい段階でしたら、お問い合わせからご相談ください。仕様がどこにあるかを数えるところから入ります。