塩漬け“17年”のレガシー刷新作業を「2年→2日に短縮」 常石造船の事例で見えた、AIプロジェクトの成否：API管理の経験からKongが指摘

AIエージェントの活用が本格化する中、レガシーシステム刷新の工程が、AIエージェントを活用することで2年から2日に短縮するという事例も生まれた。一方で多くのAIプロジェクトではPoCで止まり、本番運用への障壁を乗り越えられていないという現状もある。API管理ベンダーKongが事業戦略説明会で語った常石造船の事例などを踏まえて、成否の条件を考える。

[遠藤文康，＠IT]

　AIエージェントの活用が急速に進展する中、それを支えるシステム基盤や運用体制の整備が一段と重要になりつつある。17年間運用されてきたレガシーシステム刷新の工程を、AIエージェントを使うことで2年から2日に短縮するという事例も日本で生まれ始めた。だが一方では、AIプロジェクトの多くが本番運用に移行できていないという現状もある。どうすれば成果創出につなげられるのか、そのための基盤整備の在り方が現実的な問題として問われている。

　経済産業省のレポート「DXの現在地とレガシーシステム脱却に向けて」によると、日本の大企業の74％に依然としてレガシーシステムが残存している。

大企業の74％にレガシーシステムが残存（経済産業省資料より引用）

　API管理の視点からモダナイゼーションやAI活用の共通基盤整備などを支援するKongが2026年6月11日に開催した記者説明会でも、AI活用の障壁となり得る課題の一つとして、このレガシーシステムの存在が指摘された。一方で、生成AIやAIエージェント自体が、モダナイゼーションの突破口を開く存在でもあり、AIエージェント活用拡大とともにレガシーシステム刷新の機運が高まっている状況だという。もっとも、優秀なAIモデルを導入しさえすればいいわけではない。

　自律的に動作するAIエージェントの性質上、適切に制御されていなければコストやセキュリティの問題を生み、それがAIプロジェクトを頓挫させる一因になる。では何が必要なのか。それ探る上での参考になる先行事例としてKongが挙げたのが、広島県福山市の常石造船におけるレガシーシステムのモダナイゼーションだ。

　17年間塩漬けにされてきたシステムの刷新工程を、AIエージェントを活用することでわずか2日まで短縮したものだ。従来の人為的な手法では約2年、2億円程度を要すると見積もられていた案件だった。この事例がどのように実現されたのかを踏まえながら、AIプロジェクトが失敗する原因や、本番フェーズへと進めて成功させるために何が必要なのかを考える。

レガシー刷新の作業を「2年→2日に短縮」　何が成功要因だったのか

　常石造船の資材調達システムは、仕様を知る担当者の高齢化も進み、ドキュメントも十分に整っていなかったという。刷新の必要性はあっても触れられない典型的なレガシーシステムだった。

　このシステムの刷新には、分散データ管理基盤を手掛けるScalarがAIコーディングエージェント「Claude Code」をベースに独自構築したAIエージェントが使われた。2年かかると見積もられていた工程だったが、現状分析およびリファクタリングをわずか2日間で完了。トークン使用量が上限に達した形だったため、実質的な処理時間はわずか4時間だったという。常石造船では社内から20代の2人のIT担当者がこのAI駆動開発による作業を担い、内製化を推進している。

　モダナイゼーションでは長年の拡張を重ねてきたモノリス（一枚岩）構造のレガシーシステムをビジネスドメインごとに細分化し、9つのドメインに分割してマイクロサービス化した。このAI駆動開発による刷新が成功した要因として、幾つかのポイントがある。

　まず、データやプロセスのコンテキスト（文脈・境界）を分離し、LLM（大規模言語モデル）が読み込むべきデータの範囲を明確にしていることだ。データの文脈が整理されることでAIのハルシネーションが起きにくい構造になる。共通基盤の設計までをAIエージェントが自動的に出力できる状態を整えている点も挙げられる。

モノリス構造のレガシーシステムを9つのビジネスドメインに分割してマイクロサービス化（Kongプレスリリースより引用）

　分散したドメイン間のトランザクションにおいて不整合が生じるのを防ぐレイヤーとしてScalarの分散データ基盤管理製品「ScalarDB」が使われ、またサービス間の通信を統制、制御するAPI管理基盤として「Kong Konnect」が採用されている。こうしたマイクロサービス基盤の設計を含めて、ScalarのAIエージェントがあらかじめ自動生成するように組まれており、インフラ構築の工数が抑えられ、マイクロサービスアーキテクチャの実装における障壁を下げている（関連記事）。

Kong日本法人代表取締役社長
有泉大樹氏

　こうしてレガシーシステムの刷新においてAIエージェント活用が大きな効果を上げ始めていることを踏まえて、Kong日本法人の有泉大樹氏（代表取締役社長）は、マイクロサービス化とAIエージェントの導入は「同じ波長に乗っている」とする。マイクロサービス化によってデータのコンテキストが適切に分離される結果、AIエージェントのハルシネーションが抑制され、AIエージェントによる自律的な動作をミッションクリティカルなプロセスに適用しやすくなるという関係性があるからだ。有泉氏は「常石造船の事例はその可能性を示した先行事例になった」と語る。

AIプロジェクトが本番に至らないケース

　成功事例が生まれている一方で、成功を阻む障壁が指摘され始めてもいる。例えば調査会社Gartnerは、AIエージェントの利用が本格化していくことに現状の企業のインフラでは対応できていないとして、2027年末までにエージェント型AIプロジェクトの40％が失敗する可能性があると指摘している。

　Kongのデービッド・カーレス氏（アジア太平洋・インド・日本担当バイスプレジデント）は、AIプロジェクトが失敗する原因はAIモデルでも推論でもなく「つなぎの部分にある」と指摘する。AIエージェントが外部のデータやツールにアクセスするための標準プロトコルであるMCP（Model Context Protocol）による連携、AIゲートウェイの導入などで構成が複雑に広がり、統制を失う結果、コスト増大やセキュリティリスクの問題が生じるのはその一例。実際、Uber Technologiesが会計年度の最初の2、3カ月で年間のAI予算を使い果たしたといったケースも報告されている。

Kongアジア太平洋・インド・日本担当バイスプレジデント
デービッド・カーレス（David Carless）氏

　AIエージェント特有の問題としては、アイデンティティーの増殖もある。エージェントが別のエージェントを生むといった形でアイデンティティーが増える構造について、カーレス氏は「いま規制上の問題として世界中で問われ始めている」とした上で、「データへのアクセス権限とその責任が連鎖的に広がっていくことの責任は全て人間の側にある」と指摘。こうした状況も一定の統制下に置いていく必要があるということだ。

　問題を集約すると、カーレス氏は「コスト」「主権・コントロール」「技術トレンドの変遷」「セキュリティの影響範囲」「ガバナンス」に分類できるとする。

　前述のGartnerの調査についてカーレス氏は、「AIエージェントが必要なコンテキストにアクセスし、利用できるようにする中間レイヤーのような存在」が、プロジェクト失敗の要因を考える上での焦点になると語る。バックエンドのAPIやイベントストリーム、データベースなどを安全に保護し、統一された管理下に置きながら、AIエージェントが必要なデータを見つけて利用できる状態にするためのものだ。Gartnerはこれを「Context Mesh」と呼んでいるが、Kongとしても同様の考え方を「AIコネクティビティー」という概念で製品化していると同氏は説明する。

AI本番運用時代に求められるインフラ

　一方で日本企業が直面している状況について、有泉氏は「PoCはやったが現場が使えるレベルになかなか到達しないといった声を耳にしている」と語る。有泉氏はAIプロジェクトが本番移行に至らない原因を大きく2つに整理する。

　一つはレガシーシステムの限界で、AIエージェントを制御するための設計には向いていないという問題。もう一つは、共通基盤の欠如だ。マルチLLMの拡大、AIエージェントの普及、MCPの台頭といったように技術が変遷する中で、コスト管理や認証・認可、オブザーバビリティー（可観測性）など整備すべき要素も多様になってくる。これらを効率的に提供、運用するためのインフラ（共通基盤）が整っていなければ、AIエージェントに対して社内データを安全かつ効率的につなぐという本番運用は現実的なものにならない。こうした壁を乗り越えた事例として示されたのが、まさに先に紹介した常石造船のケースだと言える。

Kongグループバイスプレジデント 兼 インターナショナル部門責任者
カール・マットソン（Carl Mattsson）氏

　日本市場では「前年比300％以上の成長を達成している」（有泉氏）として、AI関連のプロジェクトとレガシーシステム刷新のニーズが追い風になっているという。特に金融、製造、小売りが注力の市場になるとする。いずれも基幹システム刷新のニーズが強いことに加えて、LLMのコスト管理やガバナンスが関心事として大きくなってきている。

　また事業戦略説明会では、Kongのカール・マットソン氏（グループバイスプレジデント 兼 インターナショナル部門責任者）が、同社として重視してきた市場の3つの変化について語った。第一の変化はオンプレミスからクラウドへの移行。第二の変化はモノリシックなアプリケーションからマイクロサービスへの移行。第三の変化がAIの台頭だ。こうした変化については、日本市場でもマイグレーションとAI本格利用の波が同時発生的に発生し、“共通基盤”へのニーズが高まり同社の急激な成長につながっている状況がうかがえる。

　なおマットソン氏は、「Kong」という社名の由来についても説明した。Kongの以前の社名は「Mashape」（2010年創業）で、当時はAPIマーケットプレースを提供していた。Mashapeの文字列に“ape”（類人猿）が含まれていたことから、あの有名な“巨大な類人猿”にちなんでKongと名付けることにしたという。「著作権の関係で“前の部分”は使えなかったためシンプルにKongとした」としている。APIマーケットプレースを運用する中で開発したAPI管理基盤をKongとしてオープンソース化したのが2015年で、社名がKongに変わったのは2017年のことだ。

---

　生成AI、AIエージェントの活用もいよいよ本格的に本番運用のフェーズへと差し掛かり、PoCから先へ進むための仕組みや体制を構築できるかどうかが問われる。レガシーシステムが足かせになる現実は依然として重くのしかかるが、一方でAIを使ってその壁を突破できるという手応えも確実にある。常石造船における事例で「2年が2日」に短縮されたというのはその象徴だ。

　AIモデルの性能よりも「つなぎ方の設計」が成否を左右するというのは、決して誇張ではないだろう。自律的な判断でデータへのアクセスや処理を実行するAIエージェントが、さらに別のAIエージェントを生みその影響範囲が容易には追跡しにくくなっていく可能性があるからこそ、安全性やコストを考慮したつなぎ部分の設計が、なおさら問われるようになると考えられる。