米Odyssey Logisticsが、Microsoft Access/VBAに残っていた業務ロジックを、AIソフトウェアエンジニア「Devin」と7人のチームでクラウドネイティブに作り直し、本番稼働させました。従来方式と比べて純コスト37%削減という数字が目を引きますが、受託開発とAIエージェント事業の両方をやっている立場から見ると、この事例の核心は削減率ではなく「全変更を人間の技術責任者がレビューして署名する」という体制の設計にあります。この記事では、レガシーシステムの移行にAIエージェントを使うとき、開発会社の事業判断として何が変わるのかを整理します。
要点(事実のみ)
- Cognizant と Cognition は2026年9月23日、Odyssey Logistics で自律型AIエンジニアリングを本番運用に乗せたと発表した。
- 対象は、受注入力と出荷ライフサイクルのワークフローロジックを抱えた Microsoft Access / VBA のフォーム群。これを OdysseyONE プラットフォーム上のクラウドネイティブなアプリケーションとして再構築した。
- 7人の Cognizant チームが Devin を使ってレガシー変換を担い、コードと並行してテスト、デプロイパイプライン、ドキュメントも生成した。
- 結果は従来方式比で純コスト37%削減、開発スループットは約3分の1向上。発表文は「固定予算と厳しい納期が、従来型の書き直しを選択肢から外した」と説明している。
- すべての変更は、マージ前に Cognizant の技術リードまたはアーキテクトがレビューし承認した。先行した別プロジェクトはキックオフから21日でクローズし、その結果を受けて輸送管理プラットフォームへ同じモデルを適用した。
徐 聖博の見解
「5〜6倍」ではなく「約3分の1」だったことに意味がある
私が最初に引っかかったのは、同じリリースの中にある2つの数字の差です。Cognizant社内の取り組みでは、Devinで新規開発(グリーンフィールド)が5〜6倍に加速したと書かれています。一方、Odysseyのレガシー刷新ではスループット向上は約3分の1にとどまります。
私はこの差を、AIが弱いからではなく、レガシー移行という仕事の中身が「書くこと」ではなく「今の挙動を理解し、同じであることを確かめること」に偏っているからだと読んでいます。Access/VBAのシステムは、仕様書が無く、業務ルールがフォームのイベントやクエリに埋め込まれていることが多い。コードの生成が速くなっても、「この画面のこのボタンは、どの条件で何を更新していたのか」を確定させる作業は残ります。この事例で、テストをコードと同時に生成させている点は、その確認作業をAI側に寄せる工夫だと考えます。
ボトルネックはレビューする人の数に移る
全変更に技術リードかアーキテクトの署名が必要、という体制にした時点で、プロジェクトの速度の上限は「AIが書ける量」ではなく「責任を持ってレビューできる人の処理量」で決まります。私たちも開発でコードレビューを人とAIで併用していますが、実感として、AIが出す差分が増えるほどレビュー側の集中力が先に尽きます。7人という小さなチームで成果が出ているのは、人数を絞ったからではなく、レビューで判断できる人を中心に構成したからだと私は推測しています(チーム構成の内訳はリリースに書かれていません)。
Odyssey側のCIOが「重要な判断は人間が握る」と語っているのも、ここと整合します。AIに丸投げしたのではなく、説明責任の所在を先に決めたうえでAIを入れた。順番が逆ではない点が、本番稼働まで行けた理由だと思います。
開発会社の事業判断にどう効くか
SIerや開発会社の経営側から見ると、この事例は技術の話より先に、値付けと体制の話です。
- 人月の請求モデルとは相性が悪い。 37%削減がそのまま工数削減なら、人月で請求している会社は売上が減ります。この事例が「固定予算」の案件で成立していることは象徴的で、成果物単位・固定価格で受ける会社ほどAIの効率化が利益に残ります。
- 必要な人材の比率が変わる。 手を動かす人より、既存業務の挙動を読み解き、差分の正しさを判定できる人の比重が上がります。一方で、若手がレガシーコードを読みながら業務を覚える、という従来の育成経路は細ります。育成をどう設計し直すかは、採用人事に関わってきた私から見て、効率化以上に重い論点です。
- 見積もりの前提を開示できるかが競争力になる。 リリースは「従来方式比37%」としていますが、比較対象の見積もり前提は読み取れません。発注側がこうした数字を見て相見積もりを取るようになると、「何と比べて何%なのか」を説明できる会社が選ばれるはずです。
Access/VBAの業務ロジックはどこから移すべきか
私が同じ案件を受けるとしたら、最初にやるのはコード変換ではなく、現行システムの挙動を固定するテストを作ることです。入力と出力の組を実データから集め、「新システムでも同じ結果になる」ことを機械的に確かめられる状態を先に作る。そのうえで、変換はAIに任せ、差分の妥当性判断は人が持つ。Odysseyの事例も、先行の小さなプロジェクトを21日で閉じてから本丸に進んでいます。いきなり全体を移さず、小さく回して体制の妥当性を確かめる順番は、規模にかかわらず真似できる部分です。
レガシー刷新は、以前は「数年がかりの大工事」か「触らずに延命」の二択になりがちでした。AIエージェントは第三の選択肢を現実的にしましたが、それを成り立たせるのは道具ではなくレビュー体制と契約形態だ、というのが私の結論です。
あわせて読みたい
- レガシー×Claude Codeで露わになった「人間の主体性」の本質——4ステージパイプラインから学ぶ
- 設計書なし・コード一部消失の基幹システムを、AIが2カ月で解析——カクヤスの事例から見えること
- コード生成AIの選び方と実務での使い方｜レビューが追いつかない問題をどう設計するか
- 基幹システム刷新は「何年目に何を測るか」で決まる——TIAAが技術負債を半減させた順番
- 請負vs準委任（ラボ型）どちらが速い？要件の確定度で変わる正しい選び方
- 基幹システム開発にラボ型開発が向いている理由｜段階的に進める成功の鉄則
出典: Cognizant and Cognition put autonomous AI engineering into production at Odyssey Logistics, with a 37 percent net cost saving (PR Newswire, 2026-09-23)
