目次
  1. 「AIで刷新期間を短縮できます」と言われた方へ
  2. 何が2日で終わったのか
  3. 2日のうち、動いていたのは4時間です
  4. 速さの条件は、渡す前にありました
  5. 公式発表に「2年→2日」は書かれていません
  6. 割ると、つなぎ直しが要ります
  7. やったのは社内の2人です
  8. 提案を受けたときに確認すること
  9. 聞くのは倍率ではなく、渡す前の担当です

「AIで刷新期間を短縮できます」と言われた方へ

基幹システムの刷新を検討していて、提案書やニュースで「AI駆動開発なら期間が何分の1になる」という話に出会った方に向けて書いています。

題材は2026年6月に公表された常石造船の事例です。数字は本物です。ただし短縮されたのがどの工程で、何が律速だったのかを読まないと、自社の見積もりには使えません

何が2日で終わったのか

広島県福山市の常石造船は、15年以上運用してきた資機材の調達・在庫を一元管理する調達システムを刷新しています(常石造船 2026年6月10日)。仕様を知る担当者の高齢化が進み、ドキュメントも十分に整っていない、典型的なレガシーシステムでした。

@ITの報道によると、17年間塩漬けにされてきたこのシステムの現状分析およびリファクタリングが2日間で完了しました。従来の人為的な手法では約2年、2億円程度を要すると見積もられていた作業です(@IT 2026年6月23日)。

先に確認しておきたいのは、2日で終わったのが調査と再設計の工程だという点です。刷新そのものが2日で終わったわけではありません。

2日のうち、動いていたのは4時間です

同じ記事に、この2日の内訳が書かれています。

トークン使用量が上限に達したために2日という日数になったのであって、実際に処理が動いていたのは4時間だった、とされています。

つまり律速はモデルの賢さではありません。上限に当たって止まっていた時間のほうが長い。この比較には、性能ではなく契約プランが混ざっています。

速さの条件は、渡す前にありました

では4時間で数千本規模のプログラムを読めた理由は何か。

報道が挙げているのは、長年の拡張を重ねたモノリス構造をビジネスドメインごとに9つへ分割してマイクロサービス化したことです。データとプロセスのコンテキストを分離し、LLMが読み込むべき範囲を明確にした。文脈が整理されるとハルシネーションが起きにくい構造になる、という説明です。

順番を確かめてください。9つに割ってから、AIに渡しています

どこで割るかを決めるのは、業務を知っている人間の設計判断です。調達の業務を購買・発注・在庫管理とどの粒度で切るか。この工程は短縮されていません。

短縮されたのは、どちら側か 人が決める 業務の境界を9つのドメインへ割る 割った後のつなぎ直しも設計する 渡す AIが読む 数千本規模のプログラムを解析する 実際に動いた時間は4時間 2年から2日になったのは、右の枠です 左の枠を誰がやるかは、提案書に書かれていないことがあります
分割済みのシステムを渡せば速く読めます。分割されていないシステムを渡すと、境界のない数千本を一度に読ませることになります。

公式発表に「2年→2日」は書かれていません

常石造船自身のリリースを読むと、載っている数字が違います。

記載されているのは設計・実装・テスト工程の70%以上削減見込みです。2年から2日という比較は出てきません。この比較を語ったのはAPI管理基盤を提供したKongの記者説明会で、それを@ITが報じています。

どちらかが嘘なのではありません。ただ、発注側が自社の計画に写すべきなのは見込みと書かれているほうです。70%以上削減は工程全体を指していて、達成済みの実績ではなく見込みとして書かれています。

同じ事例に複数の比較基準が並ぶ構造は、IBMのレガシー刷新AIは9カ月を3日にしたのかでも扱いました。派手な倍率を見たら、まず誰がどの範囲を測ったのかを探します。

割ると、つなぎ直しが要ります

9つに分けたことで別の作業が生まれています。

分割したドメイン間でトランザクションの不整合が起きないよう、分散データ基盤が整合を保つレイヤーとして置かれ、サービス間の通信を統制するAPI管理基盤も採用されています。割るという判断は、割った後をつなぐ仕組みとセットでしか成立しません

やったのは社内の2人です

受託開発をしている私たちにとって、この事例のいちばん重い事実はここにあります。

作業を担ったのは、常石造船の社内から出た20代のIT担当者2人でした。同社は完全内製化を選んでいて、リリースには外部依存からの脱却が目的だと明記されています。ITの主導権を自社が握ることが不可欠だった、という執行役員のコメントも載っています。

外部に出す前提で読むと見誤ります。この事例が示したのは、AIを使えば発注しなくて済む、ということではありません。境界を決められる人が社内にいれば、実装工程は外へ出さなくても回る場合があるということです。

現場メモ

私たちが刷新の相談を受けたとき、最初に見るのは既存システムの規模ではなく、業務の境界がどこで切れているかです。切れていない場合、AIへ渡す前の作業は人がやることになります。その工数を提案書に書くと、AIによる短縮幅は他社より小さく見えます。

見劣りするのを承知で内訳を出しているのは、この工程を飛ばした案件で、後から境界をまたいだ不整合が出るのを見てきたからです。割った後のつなぎ直しまで含めて見積もると、短縮幅は控えめになります。そのかわり、後で足す費用が減ります。

提案を受けたときに確認すること

AI駆動開発の短縮率を示されたときの4つの質問

  • 短縮されたのはどの工程ですか。調査・分析か、実装か、テストか

  • その数字に待ち時間は含まれますか。トークン上限や承認待ちを含むかで倍率が変わります

  • 渡す前の分割は誰がやりますか。業務の境界を決める作業は誰の工数として積んでありますか

  • 割った後のつなぎ直しは入っていますか。ドメイン間の整合を保つ仕組みの費用と担当

    刷新提案のレビュー、相見積もりの比較シートにそのまま転記して使えます

聞くのは倍率ではなく、渡す前の担当です

「AIで何倍速くなりますか」は、答えが返ってきても使えません。返ってくるのは、その会社が測った範囲の倍率だからです。

聞くべきなのは渡す前の作業を誰がやるかです。ここに答えられる会社は、境界の設計を仕事として認識しています。答えが「そこもAIがやります」なら、境界のない数千本を一度に読ませる計画になっています。

自社のシステムがどこで切れているのかを整理する段階でしたら、お問い合わせからご相談ください。分割の設計と、割った後のつなぎ方からご一緒します。


出典

このテーマで相談するAIネイティブ開発支援を見る