Vertex AI Agent Builderとは、Google Cloudの生成AIエージェント構築基盤である。
ホームセンター大手のカインズが、従業員ひとりで週の半分を吸い取られていた「190万行の表計算ファイル」運用から脱出した。Google Cloudが4月14日付の公式発表で明らかにしたもので、仕組みの中心にあるのはBigQueryとVertex AI Agent Builderの組み合わせ。数字だけ見れば一社の事例に見えますが、背景にある構造は多くの日本企業で見覚えのある光景です。需要予測システムの出力が複数ファイルに分割され、担当者がExcelで手作業につなぎ合わせていく——そんな運用に心当たりがあるなら、本記事は他人事ではないはず。
・カインズは需要予測システムの出力処理に出力だけで2日、店舗メンテナンス用データの抽出に2〜3日かかっていた
・BigQueryとVertex AI Agent Builderを組み合わせ、自然言語指示でAIエージェントがデータを直接操作できる基盤を構築
・取引先任せだった補充最適化の計算を自社で実行できるようになり、現場起点の運用変更が動き始めている
カインズが抱えていた「190万行の表計算」問題
まず押さえておきたいのが、今回の刷新前にカインズで実際に起きていた状況。Google Cloud公式発表によると、カインズでは需要予測の結果が表計算ファイル形式で吐き出される運用が続いていました。問題はそのサイズと分割構造にある、というのが発表の内容です。
需要予測システムの出力が分割される構造的な重さ
需要予測システムの出力は1回あたり190万行にのぼる表計算データ。しかも1回の出力が6〜7個のファイルに分割されるため、出力だけで2日を要していたといいます。ここで強調したいのは、データ分析に入る前の「出力」の段階ですでに丸2日消えていた、という事実。出力後に分析・加工が続くわけですから、意思決定のサイクルは週単位に引き延ばされていたはずです。
190万行という規模感は、一般的な表計算ソフトでも動作が重くなる領域。開けるだけでメモリを食い、フィルタやVLOOKUPを動かすたびに待ち時間が発生します。これを6〜7個に分割されたファイル同士で突合するとなれば、ファイル間の整合性確認だけでも相当なコストに。
一人のエンジニアが抱えていたメンテナンス負荷
発表資料によれば、この表計算ファイルのメンテナンスは一人のエンジニアが担当していました。担当者は条件データや在庫データに基づくフラグ設定、他システムのマスタデータの紐付けなどを行っており、内容の確認やテストに時間を取られて現場のニーズに迅速に応えることが難しくなっていたといいます。
さらに、店舗のメンテナンスに必要なデータ出力には2〜3日かかる状況。販促を仕掛けるタイミングで必要な数字が出せないというのは、小売業として致命的な遅延です。タイミングを逃した販促は機会損失そのもの。
Google CloudとVertex AI Agent Builderで刷新したデータ基盤
ここからが刷新の中身。カインズが選んだ構成は、データウェアハウスとしてのBigQueryと、AIエージェント開発基盤であるVertex AI Agent Builderの組み合わせでした。Google Cloudの4月14日付発表に基づいて、構成と動きを整理していきます。
BigQueryに集約しAIエージェントで引き出す構成
基本の流れはシンプルに整理できます。需要予測を含む各種データをBigQueryに集約し、その上でVertex AI Agent Builderで構築したAIエージェントが直接データを操作する——これが新しい基盤の骨格。
ポイントは、従来のように表計算ソフトでデータを加工する工程が挟まらなくなったこと。BigQueryに一度集まれば、SQLの知識があるエンジニアなら直接クエリで引き出せるのは当然ですが、今回の刷新ではその一歩先に進んでいます。AIエージェントがデータを直接操作・出力できるようになったため、表計算ソフトのメンテナンス自体が不要となった、と発表は明言しています。
自然言語インターフェースがもたらした変化
新基盤の最大の変化は、ユーザーが自然言語で質問を投げかけるとAIエージェントがBigQueryのデータを直接操作して答えを返す、という使い方が可能になった点。「◯◯店の先週の在庫推移を出して」と日本語で頼めば、AIエージェントが裏でBigQueryに問い合わせ、結果を整形して返す——ざっくり言えばそういう世界です。
この変化の本質は、データにアクセスできる人の裾野が一気に広がったこと。従来はSQLや表計算ソフトの操作に習熟した担当者しか触れなかったデータに、現場の担当者が直接問いを投げられるようになります。情報システム部門への依頼チケットを発行して数日待つ、という運用とは明らかに別次元の速度です。
表計算ファイルの「更新待ち」「出力待ち」という時間が消えることで、意思決定のサイクルそのものが短縮される。カインズの発表に具体的な短縮時間は示されていませんが、出力だけで2日・店舗メンテ抽出に2〜3日という前提が解消されたことの意味は大きい、と読み取って差し支えないでしょう。
発注・在庫の自動化で変わった現場
基盤刷新に付随して、カインズはもう一つ重要な動きを進めています。補充最適化ロジックの内製化。Google Cloud公式発表の中でも、この部分は発注・在庫管理の自動化として紹介されています。
取引先任せだった計算の内製化
発表によると、カインズは肥料などの補充における在庫の変動量を最適化する補充最適化ロジックを開発しました。注目すべきは、従来この計算は取引先企業が担っていたという点。サプライチェーンの中で、計算ロジックという知的資産がベンダー側にあった構造です。
この構造、小売以外でもよく見かけます。専門的な計算ロジックを外部ベンダーに任せて、自社は出てきた数値を受け取るだけ——という形。悪い仕組みではないのですが、計算ロジックの改良スピードがベンダー側の都合に縛られるという弱点があります。業態や顧客ニーズが変わったとき、ロジックの見直しに時間がかかる。これが意思決定のボトルネックになります。
カインズは補充最適化ロジックを自社で持ち、自社で走らせる形に切り替えました。これにより、計算そのものの改善サイクルも自社の意思で回せることになります。
現場起点の運用変更が回り始めた
発表では、今後は最適化計算のリクエスト自体もAIエージェントで実行できるようにし、シーズン商品の最適化や店舗最適化など、より複雑なビジネス領域への最適化の適用拡大も予定しているとされています。
ここが実は本丸。計算ロジックを内製化しただけなら「開発の内製化」で終わりますが、計算のリクエスト自体をAIエージェント経由にすることで、現場担当者が自分の問題意識に合わせて最適化計算を呼び出せる世界が見えてきます。販促担当が「このシーズン商品の補充ロジックをちょっと変えて試したい」と自然言語で指示する、というイメージ。
小売業の強みは現場の感覚。その感覚を計算に即座に反映できる仕組みが回り始めた、というのが今回の刷新の現場側での意味だと読めます。
ツール導入で終わらせない業務変革の教訓
カインズの動きを単なるクラウド移行や生成AI活用と捉えると、本質を見失います。ここで視野を広げるために、他社のAI活用事例から示唆を引き出していきます。
AI導入は業務フロー再設計とセットでないと続かない
ITmedia AI+の記事で紹介されているトヨタ・コニック・プロの事例では、AI PCを800台導入した際の狙いが解説されています。同社の視点は明快で、AI PCを配るだけでは業務効率化は成立せず、業務プロセス全体を見直してAIを組み込む必要がある、というもの。CopilotやGeminiのような生成AIツールは「補助」から「実行支援」へと役割が進化している、とも指摘されています。
この視点でカインズを見ると、刷新の本質が見えてきます。BigQueryとVertex AI Agent Builderを導入しただけでは、今回の変化は起きませんでした。需要予測の出力構造、補充最適化ロジックの所在、現場から計算を呼び出す仕組み——この三つを同時に動かしたことが鍵。ツールを配る以上のことをやっているのです。
業務フロー全体に踏み込む覚悟があるかどうかが、AI導入プロジェクトの成否を分ける分岐点。カインズは「表計算ファイルをクラウドDBに置き換える」だけでは終わらせず、計算ロジックの帰属まで組み替えました。ここがポイントです。
AIエージェントをどう選ぶかという観点は、AI×自動化：AIエージェントの選び方｜業務の複雑さ別に最適なツールを見極める方法でも整理しています。業務の複雑度によって最適な構成が変わるため、併せて参考にしてください。
DeNAの「3つのハードル」から読み解く
もう一つの補助線として、DeNAの「AI活用100本ノック」の整理を借ります。ITmedia AI+が伝えるところでは、DeNAは1000本以上のAI活用に取り組む中で、開発エンジニアの生産性が2倍に、商談の議事チェックで業務フローが90%効率化、品質保証ではAIがテストを自動化、などの成果を公表しています。
同社はこの取り組みから、AI活用を阻む壁を「個人」「組織」「経営」の3つのハードルとして整理している、と報じられています。個人のハードルとは知見の属人化。個人で優れたプロンプトを開発してもチーム内で共有されないまま消えていく、という問題が典型例として挙がっています。
カインズの事例をこのフレームで読み解くと、3階層が同時に動いているのが見えます。経営判断としてデータ基盤の刷新を決め、組織としてベンダー依存の計算ロジックを内製化し、個人レベルでは自然言語で計算を呼び出せる環境を整えた——。どれか一つだけ動かしても、今回のような変化は起きなかった、と読めます。
他業種が自社に応用するための視点とまとめ
カインズの事例は小売特有の話に見えて、実は多くの業種に共通する構造を含んでいます。自社に応用するためのチェックポイントを整理していきましょう。
「システム間の谷」がExcelで埋まっていないか
最初に点検すべきはここ。需要予測システムの出力を表計算ソフトで6〜7個のファイルにまとめ直していた、という運用は、システム間の連携が人力とExcelで埋められている典型例です。基幹システムとBIツールの間、基幹システムと分析用データベースの間、本社システムと店舗システムの間——こうした「谷」がExcel運用で埋まっていないか、自社の業務を棚卸ししてみる価値はあります。
製造業の生産管理、物流の配車計画、医療機関の患者データ統合——業種は違っても、システム間の谷をExcelで人力で埋めている現場は少なくありません。ここに190万行級のデータが流れ込んでいるなら、カインズの刷新は他人事ではなくなります。
ベンダー任せの計算ロジックを棚卸しする
二つ目のチェックは、専門的な計算を外部ベンダーに任せきりにしていないか。カインズが補充最適化ロジックを内製化した意義は、自社の事業判断で計算そのものを改変できるようになった点にあります。ロジックが自社にないと、事業環境が変わったときの対応が常にベンダー次第。
自社のデータが揃っており、計算の要件も自社で定義できるなら、BigQuery＋Vertex AI Agent Builderのような基盤に載せ替えて内製化する選択肢が現実的に。Google Cloudの今回の発表は、小売業のカインズがそれを実行したという事例の提示でもあるわけです。
- 採用技術
- Google Cloud BigQuery / Vertex AI Agent Builder
- 従来の負荷
- 需要予測の出力が190万行・6〜7ファイル分割・出力だけで2日
- 店舗メンテデータ抽出
- 従来2〜3日
- 刷新後の操作
- 自然言語の質問でAIエージェントがBigQueryを直接操作
- 内製化した計算
- 補充最適化ロジック（従来は取引先企業が担当）
- 今後の展開
- シーズン商品最適化・店舗最適化などへの適用拡大
- 発表元
- Google Cloud（4月14日付公式発表）
要点を押さえ直すと、カインズの刷新は「表計算ファイルをクラウドに移した」話ではありません。データの置き場所、計算ロジックの帰属、現場からの呼び出し方——この三つを同時に動かしたことで、現場の意思決定スピードが変わった事例。自社に「190万行問題」が潜んでいないか、点検する価値は十分にあります。
よくある質問
Q. カインズが採用した技術は何ですか？
Google CloudのデータウェアハウスであるBigQueryと、AIエージェント開発基盤のVertex AI Agent Builderです。Google Cloudが4月14日付の公式発表で明らかにしています。ユーザーが自然言語で質問するとAIエージェントがBigQueryのデータを直接操作・出力できる構成となっています。
Q. 刷新前は具体的にどんな運用でしたか？
需要予測システムの出力が190万行にのぼる表計算ファイルで、1回の出力が6〜7個のファイルに分割され、出力だけで2日かかっていました。担当者は条件データや在庫データに基づくフラグ設定、他システムのマスタデータの紐付けを行い、店舗のメンテナンスに必要なデータ出力には2〜3日を要していた、とGoogle Cloudは発表しています。
Q. 発注・在庫の自動化はどこまで進んでいますか？
カインズは肥料などの補充における在庫変動量を最適化する補充最適化ロジックを開発し、従来は取引先企業が担当していた計算を自社で実行可能にしました。今後は最適化計算のリクエスト自体もAIエージェントで実行できるようにし、シーズン商品の最適化や店舗最適化など、より複雑な領域へ適用拡大する予定と発表されています。
Q. 他業種でも同じ仕組みを応用できますか？
応用できる余地は十分にあります。カインズの事例の本質は、システム間の連携を表計算ソフトの人力運用で埋めていた部分をクラウドDBに集約し、計算ロジックを内製化した点にあります。製造業の生産管理、物流の配車計画など、基幹システム間の谷を人力で埋めている現場なら、同種のアプローチが成り立ちます。自社のデータ整備状況とロジックの定義力が前提になります。
Q. Google Cloudはいつ発表したのですか？
Google Cloudは4月14日付でカインズの事例を公表しました。BigQueryとVertex AI Agent Builderを軸としたデータ基盤の刷新と、発注・在庫管理の自動化の内容が公式発表の中で紹介されています。
コメント