はじめに こんにちは。ZOZOでアプリバックエンドブロックのブロック長をしている湯川です。以前公開した記事では、ZOZOTOWNアプリ用APIのリプレイスの初期の開発・課題・解決方法などについて紹介しました。 techblog.zozo.com 今回はその続編として、商品詳細APIリプレイスをどのように進めたのかを紹介します。今回のリプレイス対象は、約5,000行のコードと約410項目のレスポンスを持つ巨大なAPIでした。長年の機能追加によって複雑化し、いわゆる「秘伝のタレ」と呼ばれる状態になっていました。 しかし本記事でお伝えしたいのは、単なるAPIリプレイスの話ではありません。 限られた期間の中で、以下に着目して大規模リプレイスを進めるための技術とマネジメントの取り組みについて紹介します。 巨大なモノリスをどう理解したのか 並列開発が可能な構造をどう作ったのか なぜ3チームでの開発が可能になったのか 目次 はじめに 目次 迫る期限と見えない全体像 「どんな手段を使ってもいい」 突破口となったフィーチャー分割 依存関係を可視化する 構造を見てから戦略を立てる スケールできた理由 あえて改善しない 結果 まとめ 迫る期限と見えない全体像 商品詳細APIリプレイスの着手時点で、私たちには大きな課題がありました。リプレイス前のAPIサーバーはオンプレで稼働しており、その縮退スケジュールは既に決まっていました。一方で、商品詳細APIは長年の改修によって巨大化しており、全体像を把握できるメンバーは誰も居ない状態でした。 価格、在庫、商品画像、サイズなど、多数の機能が単一APIに集約されていました。変更の影響範囲は広く、機能間の依存関係も複雑です。先述の通りコード量は約5,000行、レスポンス項目は約410項目もありました。 当然ながら、「どれくらい時間がかかるのか」すら正確には分からない状態でした。 「どんな手段を使ってもいい」 そんな状況の中で、上司から言われた言葉があります。 「どんな手段を使ってもいいので、達成方法を考えてほしい」 振り返ると、この一言が大きな転換点でした。 通常であれば、今いるチームで進めることを前提に考えがちです。既存の役割分担を維持し、既存の開発プロセスに合わせるのが普通です。 しかし、この言葉によって私自身がその前提を外せるようになりました。 チーム構成も変えていい。 担当範囲も変えていい。 進め方そのものを変えていい。 ならばまず、「この巨大な塊をどう攻略するか」を考えるべきだと思いました。 突破口となったフィーチャー分割 私は本案件の開発をリードするカイルさんに「どうにかしたいから対応方法を検討してほしい」と依頼しました。 カイルさんは 前編で紹介したフェーズ3からリプレイスにJOIN したメンバーで、このプロジェクトではアーキテクトも担当しています。 様々な切り口で分割を検討した結果、彼が提案したのは フィーチャー単位での分割 でした。この分割方法を掘り下げるため、カイルさんにインタビューしてきました。 湯川：最初に「どうにかしたいから対応方法を検討してほしい」とお願いしましたが、どうやってフィーチャー分割という発想に至りましたか？ カイル：最初はUIコンポーネント単位、レスポンスオブジェクト単位、データソース単位なども検討しましたが、レガシーエンドポイントのためコンポーネント間やオブジェクト間の依存関係が複雑です。開発単位として独立できないと思いました。その時、「このAPIをアジャイルでゼロから作った場合、どの粒度でどの順番で作っていくんだろう」と想像してみました。そうすると、ECサイトの商品ページに絶対必要なコアな機能と、一旦MVPができた状態で後から追加する細かい機能という粒度で分けられることに気づきました。 湯川：商品詳細APIは機能が多いですが、具体的にはどう整理しましたか？ カイル：そうですね、全部で41フィーチャーになりました。これだと依存関係や開発する順番を整理するのが大変そうだったので、細かい機能をさらに「基本機能」「商品タイプ」「追加機能」などカテゴリに分類しました。それぞれのカテゴリをひとつのフェーズとして順番に開発していくイメージです。 湯川：振り返ってみて、分割の観点で学びはありましたか？ カイル：「商品タイプ」のフィーチャーは様々な機能に横断して影響することが多く、分割観点としてあまりよくなかったかもしれません。後のショップ詳細APIでは、商品の属性ではなく機能の軸で分割するようにしました。例えば「◯◯ショップの商品」ではなく「特定ショップの専用UI」や「特定ショップのカテゴリ」というふうに細かく分けています。 このようにして、巨大なAPIを構造で捉えることができるようになりました。 さらに、分割のアウトプットとして、各フィーチャーごとに以下の情報もまとめてありました。 レスポンス項目 既存コードで該当箇所がわかるコメントをうったコミット 利用している外部API・マイクロサービス一覧 これらの対応によって、1チームで進めた場合は 約1年規模 という見積もりが出ましたが、並行開発という選択肢を取れるようになりました。ただし、並行開発を実現するためには、フィーチャー間の依存関係を明確にする必要がありました。 依存関係を可視化する 次に取り組んだのは依存関係の詳細な整理です。 依存度の高いフィーチャー 独立性の高いフィーチャー どちらが先に必要か、どこがボトルネックになるかを構造として把握できるように再度コードを解析し、各フィーチャーごとの依存関係を明確にしました。 NotebookLMを使って、依存関係を動的に可視化できるインフォグラフィックも作りました。 私たちはこの作業を通じて、「どう実装するか」ではなく、 「どこなら並列化できるか」 を考えられるようになったのです。 構造を見てから戦略を立てる ここでようやく組織の話になります。一般的には、先に体制を決めてから仕事を割り振ります。 しかし今回は逆でした。まず構造を理解し、次に依存関係を整理し、最後に組織を設計します。 つまり、組織に合わせてアーキテクチャを作るのではなく、アーキテクチャに合わせて組織を設計しました。 依存度の高い基本機能は特定チームが担当し、独立性の高い機能は別チームに任せます。 スプリントごとに担当フィーチャーを計画しながら、3チーム並列での開発体制を構築しました。 スケールできた理由 もちろん、人を増やしただけでは成功しません。むしろ、「人月の神話」の通り、遅くなることもあります。そこで私たちは、仕様理解のコストを下げることに注力しました。 実は商品詳細リプレイスの数か月前から、別チームがUIとレスポンスを紐付けた仕様書を整備していました。この仕様書が、フィーチャー分割、開発、テストのすべての基準になりました。 さらにレガシーAPIのリプレイスを進めていく中で、タスクテンプレートを整備し、チーム間でタスク粒度をある程度統一していました。 結果として、3チーム並列でもタスクの粒度が揃っているため、開発の相談ごとが発生しても連携がスムーズでした。 あえて改善しない もう1つの成功要因があります。それは、 改善しないことを決めた ことです。商品詳細APIには改善余地が数多くありました。せっかくリプレイスする・作り変えるのであれば、「不要と思われる仕様をなくしたい」「レスポンス構造も整理したい」「より適切なエラーハンドリングをしたい」と思います。 しかし、それを始めると終わりが見えません。これは今までのリプレイスプロジェクトで得た知見でした。 今回の目的は改善ではなくリプレイスです。 そのため、 現行をそのまま置き換える ことに徹底的に集中しました。この意思決定によって議論が減り、スピードが大きく向上しました。 結果 最終的に、以下の様々な良い結果を得ることができました。 3チームによる並列開発を実現 約1年規模だった開発を約3か月で完了 サイクルタイムを50％改善 レイテンシーを50％改善 リプレイス前のAPIサーバーのCPU負荷を70％削減（ピーク時） 不具合による切り戻しは0件 品質とスピードを両立しながら、オンプレサーバー縮退にも大きく貢献できました。 まとめ 今回のリプレイスを振り返ると、成功要因はやはりこのフィーチャー分割です。 このフィーチャー分割がきっかけで、後続のリプレイスも順調に進行しました。分割方法も改善を重ね、より細かくユーザーストーリーにあわせた分割ができるようになりました。そして、何より3チームのみんなで同じ目標に向かって開発を進めていくことができたのも大きな成果でした。 今回のプロジェクトは、まさにZOZOが大切にしている「想像」と「創造」を体現した取り組みだったと感じています。 この経験が、同じように大規模リプレイスへ挑戦する方々の参考になれば幸いです。 ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 corp.zozo.com

LINEヤフーの技術カンファレンス「Tech-Verse 2026」の公式記事です。AIでのコーディングで難しいのは、もはやコードを出すこと自体ではありません。課題はその周辺にあります。意図を正確な仕...

AWS では、AI を活用した新しいソフトウェア開発手法「 AI-DLC（AI-Driven Development Life Cycle） 」を提唱しています。AI-DLC は、AI を単なる補助ツールとしてではなく、要件定義から設計・実装・テストまでの開発ライフサイクル全体に組み込みながら、人間が主導権を握る（Human-in-the-Loop）ことを前提とした開発手法です。そして、この AI-DLC を 3 日間で体験・実践いただくワークショップが「AI-DLC Unicorn Gym（以下 UG）」です。 2026 年 5 月 18 日〜20 日、日立のオフィスにて「日立グループ合同 AI-DLC UG」を開催しました。本記事では、その開催レポートをお届けするとともに、ワークショップを企画・伴走した AWS Japan カスタマーソリューションズ マネージャー 早川 康平が、日立グループ社内で AI 駆動開発ワーキンググループの立ち上げを牽引されるキーマン、株式会社日立製作所 デジタルシステム＆サービス AI＆ソフトウェアサービスビジネスユニット マネージド＆プラットフォームサービス事業部 チーフクラウドアーキテクト 早川 裕志 氏にお話を伺いました。 1. 日立グループ合同 AI-DLC Unicorn Gym 開催レポート 日立グループ合同 AI-DLC Unicorn Gym（2026 年 5 月 18〜20 日）。3 社・8 チーム・52 名が参加した 今回の合同開催に先立ち、2026 年 1 月には株式会社日立産業制御ソリューションズが AI-DLC Unicorn Gym に参加され、従来 3 人月規模の開発を、わずか 2 日間で動くものとして作り、AWS にデプロイするところまで完了させるという成果を出されています（詳細は こちらの記事 ）。この先行事例での手応えが、今回の日立グループ合同開催へとつながりました。 当日は、日立製作所 デジタルシステム＆サービス AI＆ソフトウェアサービスビジネスユニット マネージド＆プラットフォームサービス事業部 事業主管 鈴木 肇 氏、AWS Japan エンタープライズ事業統括本部 Hitachi事業部本部長 吉井の開会の挨拶から始まりました。 今回の UG には、日立製作所、日立ハイテク、日立産業制御ソリューションズの 3 社・8 チーム・52 名にご参加いただきました。顧客向け Web ポータル、半導体製造向け検査支援ツールなど、各チームが実際の業務テーマを持ち寄りました。 各チームに AWS のメンバーが伴走し、実テーマの開発を進めた 開催後のアンケートでは、他社での UG 実績と比較しても非常に高い評価をいただきました。 全体満足度：5 点満点中 4.67 日立グループへの推奨意向：回答者の 100% が「ぜひ／強く薦めたい」 「AI-DLC は働き方を変える可能性がある」：回答者の 92% が肯定 開発工数の削減について、回答者の 90% が「70% 以上の削減」を、72% が「85% 以上の削減」を体感 回答者の 95% が、3 日間で「動作する成果物」に到達または部分到達 参加者からは「AI 駆動開発の威力に驚いた（推論プロセスの追跡や影響範囲の可視化）」「製造スピードが段違い」といった声が寄せられた一方、「Coding Agent の社内払い出しの簡素化」「大規模開発のプラクティス」「品質保証との両立」といった、本番適用に向けた改善の要望もいただきました。 この結果は、日立グループが掲げる成長エンジン「Lumada 3.0」をより高速に生み出すための開発手法の 1 つとして、AI-DLC の可能性を示すことができたものと考えています。 2. 推進キーマンインタビュー ここからは、AI-DLC UG にも参加され、日立グループ展開に向けた AI 駆動開発ワーキンググループの立ち上げを牽引される早川 裕志 氏と、今回の AI-DLC UG をリードした AWS Japan カスタマーソリューションズ マネージャー 早川 康平との対談をお届けします。 株式会社日立製作所 デジタルシステム＆サービス AI＆ソフトウェアサービスビジネスユニット マネージド＆プラットフォームサービス事業部 チーフクラウドアーキテクト 早川 裕志 氏 アマゾン ウェブ サービス ジャパン合同会社 カスタマーソリューションズ マネージャー 早川 康平 想像を超えた、社内の反響 早川 康平（AWS） では、お願いします。「早川対談」、ようやく実現しましたね。 早川 裕志（日立） 早川 × 早川、楽しみにしていました（笑）。 早川 康平（AWS） ブログにするときは、お二人が区別しやすいように工夫します（笑）。では、さっそく。第 1 回となる日立グループ合同 AI-DLC UG、開催後の反響はいかがでしたか。 早川 裕志（日立） 実は私どもでもアンケートを取らせていただいたのですが、満足度は 5 点満点で 4.7 を超えていました。社内で改善というと「2 割」「15%」といった数字が並ぶなかで、 開発工数が大幅に減ったという結果は劇的で、インパクトがすごかった 。一方で、数字が大きすぎたことで「小さなテーマだからそうなんでしょ」という声も生まれました。それをどう払拭していくか、というところに、むしろモチベーションが湧いてきた感覚です。 早川 康平（AWS） 先日、今回ご参加いただいたチームの本部長の方にもご報告したのですが、同じような反応をいただきました。「2 カ月の開発が 2 日になった、と聞いたが、本当なのか」と。ここは正直にお伝えしています。今回 UG で各チームが取り組んだのは、実際の業務テーマで動くものを作り、AWS にデプロイするところまでで、その速さは確かな成果です。ただ、それをお客様に提供する本番システムとして世に出すには、日立が積み上げてこられた品質保証の工程──テスト、承認、レビューなど──を通す必要があります。つまり 「動くものをデプロイするまでの速さ」と「本番リリースまでの工数」は別物 で、今回の数字は前者にあたります。だからこそ、その品質保証の工程まで織り込んだ「日立版 AI-DLC」にしていく必要がある、と考えています。 最大の壁は、技術ではなくマインドセット 早川 裕志（日立） 今回、参加者の多くが AI-DLC にとても前向きで、感銘を受けました。その一方で、「AI に仕事を奪われるのではないか」という、いわば積み重ねてきたアイデンティティへの不安を抱える人もいます。どんなにいいと思っていても、どこかに反発するラインがある。そこをどう越えるかは、トップダウンでもボトムアップでも、 技術だけでは解決できない問題だと感じています 。 早川 康平（AWS） 大事なのは発想の転換だと思っています。たとえば 10 人で 1 年かけて 1 つのプロダクトを作っていたなら、これからは同じ 10 人で 1 年に 10 プロダクト作ろう、と。リリースと改善のスピードを何倍にも上げていく。とくに AI 時代はあらゆるプレイヤーが一気に立ち上がる群雄割拠の世界です。これまでのリリーススピードのままでは、もう他社に太刀打ちできない。AI-DLC は、 人を減らすための手法ではなく、生み出す価値を増やしスピードを上げるための手法 です。そういうポジティブな方向に向けられたら、と思っています。 早川 裕志（日立） UG を見学していて、最初はみんなギクシャクしているなと感じました。でも、どこかで一気に盛り上がるラインがある。AI-DLC UG では、ビジネスサイド（PdM）とエンジニアが膝を突き合わせて、常に議論しながら一緒に意思決定していきます。「誰が何を、どう決めるか」というプロセスそのものが従来と変わるので、最初は慣れないんですね。でも、そのラインを越えると一気に変わります。その場で議論して決めたことが、すぐ目の前で形になっていく。 役割の壁を越えて一緒に作っている感覚 があって、見ていてもチームが生き生きしてくるのが分かりました。この協働の体験そのものが、何よりの価値だと思いました。 AI-DLC は「品質を犠牲にスピードを出す」手法ではない 早川 康平（AWS） ここはよく誤解されるところなので、この場でもはっきり言っておきたいのですが、AI-DLC を「品質を犠牲にして生産性を爆上げする手法」だと捉える方がとても多い。それは違います。 AI-DLC の本質は、人間が開発の主導権を握り続けること（Human-in-the-Loop）にあります 。AI が計画や実装の草案を担い、何を作るか・採用するかという重要な判断は人間が下す。だからこそ、AI が解釈した「それっぽいもの」ではなく、意図したとおりのものを、速く作れるのです。 では、どこで品質を担保するのか。AI-DLC では開発ステップを明確化し、工程ごとに人間の承認ゲートを設けます。AI が作るのはあくまで草案で、承認を経て初めて人間の成果物になる。速さのために品質を犠牲にしているわけではなく、 むしろ人間が要所を押さえることで、速さと品質を両立させる ──ここは正確にお伝えしていく必要があると考えています。 早川 裕志（日立） そこは私も強く共感するところです。今後、必ず「AI が生成するコードの品質はどうなんだ」という指摘が出てきます。ただ、これは「人間のほうが AI より品質が高い」という単純な話ではないんですよね。日立には、長年積み上げてきた品質保証のプロセスがあります。事業部によってそのかたちは違いますが、その積み重ねこそが私たちの強みです。AI に任せきりにするのではなく、 その品質保証のプロセスを AI-DLC の進め方そのものに織り込んでいく 。そこができて初めて、日立として安心して本番に使える、と言えるのだと思います。 早川 康平（AWS） おっしゃるとおりで、まさにそこが「日立版 AI-DLC」の肝になります。 「日立版 AI-DLC ワークフロー」を、各現場で育てる 早川 康平（AWS） そのために、日立版の AI-DLC ワークフローを作る必要があります。AWS が GitHub で公開している AI-DLC Workflows をベースに、まずは日立として最低限守るべきものを 1 つの「汎用版」として整える。 それを各事業部・グループ会社が Fork（複製）して、それぞれに合わせてカスタマイズしていく ──というのが現実的だと考えています。 早川 裕志（日立） 日立グループは幅広いんです。SIer としての顔もあれば、事業会社としての顔もある。金融、公共、鉄道……それぞれ品質基準がまったく違います。共通化できる「ベーシックなライン」は AI-DLC で一緒に作り、 最後のカスタマイズ（ラストワンマイル）は各現場が地道に埋めていく 。そのバランスが大事だと思っています。 日立 AI 駆動開発ワーキンググループの構想を語る 早川 裕志 氏 日立 AI 駆動開発ワーキンググループの立ち上げ 早川 康平（AWS） その推進母体として、日立社内に AI 駆動開発ワーキンググループを立ち上げる、と。 早川 裕志（日立） はい。詳細は今後発表していきますが、特定の事業部に閉じず、各 BU・グループ会社から広くメンバーを集めたいと考えています。AI-DLC を一緒にやりたいと言ってくれている熱意あるフロントのメンバー、そして品質保証の担当者を巻き込んで。「小さく始めて大きくする」とよく言いますが、私はむしろ 「広く、小さく」始めたい 。熱意のある人たちで、AI 駆動開発をグループ全体に広めていきましょう。やり方はいくつもありますが、そのなかでも最も有力なアプローチとして、AI-DLC を使って始めていく考えです。 もう「AI を活用するかどうか」を議論する時代は終わった と思っています。AI が当たり前になる時代です。AI の効果は複利で効きます。早くやらないと本当についていけなくなるし、早く動けば、その分だけ事業リターンも大きい。だからこそ、AWS さんには単に支援していただくというより、 日立グループのための AI 活用パートナーになってほしい 。ぜひ、ご一緒させてください。 3. AWS の今後の支援 日立グループの AI 駆動開発を、ともに前へ進めていく AWS は、日立グループの AI 活用パートナーとして、全力で支援してまいります。 まず認知を広げるために、今後日立グループ向けの AI イベントを毎月企画していきます。Coding Agent（Kiro、Claude Code）のハンズオン、AWS Ambassadors と連動した社内向けイベント、AI 活用事例の紹介などを予定しています。あわせて、人材育成の研修プログラムについても提案していきます。 認知の次は実践です。UG の定期開催で実プロジェクトへの適用を進め、日立版 AI-DLC ワークフローの策定にも並走します。日立グループの AI 活用を全力で支援し、日立が掲げる Lumada 3.0 の実現に向けたパートナーとして、これからもご一緒させていただきます。 早川 裕志 氏、本日はありがとうございました。 本記事は、2026 年 5 月 18〜20 日に開催した「日立グループ合同 AI-DLC Unicorn Gym」の開催レポート、および 2026 年 6 月 9 日に実施した開催後インタビューをもとに構成しました。 著者 早川 康平 アマゾン ウェブ サービス ジャパン合同会社 カスタマーソリューションズ マネージャー。金融勘定系システムの PM、Web エンジニア、SaaS プロダクトマネージャー、ソリューションアーキテクトを経て現職。幅広い経験を活かし、日立グループ専任の CSM として、SaaS アプリケーション開発や AI 活用を含むクラウド活用と開発プロセスの変革を支援している。宮城県仙台市出身。