倉庫40拠点にAIエージェントを載せる — CJ Logistics × OneTrack「AiOn」を、作る側として読む

AI開発・生成AI活用公開日:2026年8月28日
徐 聖博
徐 聖博

株式会社シンシア 代表取締役社長

Share
目次開く
  1. 要点 (出典の事実のみ)
  2. 「エージェントのOS層」という売り方をどう見るか
  3. 開発を生業にしている会社にとって、これは何の話か

シンシアへのご相談

自社のAI活用・開発体制について相談する

AIをどこまで内製するか、どの業務から着手するか、体制をどう組むか。開発会社・SIer・事業会社の開発部門の方からのご相談を無料で承っています。同じ問題を自社でも解いている立場としてお話しします。

AI活用の進め方を相談する

まだ検討段階の方は 質問だけでもOK(電話番号は任意)

北米の3PL大手 CJ Logistics America が、OneTrack.AI のエージェンティックAI基盤「AiOn」を40拠点超の倉庫にパイロットから本番展開へ広げる、と2026年8月27日に発表した。物流の自動化ニュースとして読むこともできるが、私が気になったのはそこではない。既存の業務システム群の上に「AIエージェントのOS層」を置くという売り方そのものである。これは、業務システムを受託で作っている会社の事業構造に直接効く話だ。

要点 (出典の事実のみ)

  • CJ Logistics America (米国・メキシコ・カナダで展開する3PL) が、OneTrack.AI の「AiOn」を40拠点超の倉庫ネットワークに展開する。パイロットから本番運用への拡大で、7年間のパートナーシップの延長線上にある。
  • AiOn は WMS・LMS・ERP・Snowflake データウェアハウス・AI映像センサー・ロボティクスを一つのレイヤーに束ね、その上でAIエージェントが権限設定と完全な監査証跡つきで動作する基盤と説明されている。
  • 用途は、タスク間のギャップタイム把握、個別化されたインサイトによる労務パフォーマンス管理、ドキュメント自動生成を伴う安全・コンプライアンス対応、移動距離・ゾーニング・スロッティングの最適化分析。
  • 基盤モデルは xAI・Anthropic・OpenAI のものを使い、AWS Bedrock と xAI Inference API 経由で提供される。
  • 公表されている数値は、出退勤のギャップタイム45%削減、ネットワーク全体の人時生産性 (units per hour) 18%向上、ネットワークのロストタイム19.7%圧縮。
  • CJ Logistics America COO の Brad Nuffer 氏は「AiOn がそれを変える。機会のほうから浮かび上がってきて、現場はそれを探しに行くのではなく、対処するだけでよくなる」と述べている。

「エージェントのOS層」という売り方をどう見るか

私はこの発表を、モデルの話としてではなく統合レイヤーの所有権の話として読んだ。AiOn がやっていると説明されていることは、要素技術としては新しくない。WMS からデータを引き、Snowflake に溜め、映像で現場を見て、示唆を出す。ここまでは、私たちが受託で組んできたデータ基盤とBI、あるいは既存のRPA/分析案件と地続きだ。新規なのは、その束ね方を製品として先に持ち込み、その上でエージェントに権限と監査を与えている点である。

作る側として難所を挙げるなら、モデル選定ではない。40拠点それぞれで WMS のマスタ運用も現場のオペレーションも微妙に違うはずで、「同じ指標が全拠点で同じ意味になる」状態を作る部分が一番重い。ギャップタイム45%削減という数字が成立するには、そもそも全拠点で出退勤とタスクのイベントが同一の粒度で取れていなければならない。この記事で語られていない7年間の大半は、おそらくそこに費やされている。デモが動くことと業務に乗ることの差は、いつもここに出る。

もう一点、権限と監査証跡を機能として前面に出しているのは正しい設計判断だと考えている。労務パフォーマンス管理という用途は、人の評価に触れる領域だ。AIが「この人の手が空いている」と示唆する仕組みは、監査可能でなければ現場が受け入れない。ここを後付けにすると、技術的には動いても導入が止まる。

開発を生業にしている会社にとって、これは何の話か

受託開発をやっている立場から言うと、この構図は他人事ではない。基幹システムの周辺に「統合レイヤー」を製品として置かれると、これまで個別開発で受けていた連携・帳票・分析の案件が、その製品の設定作業に置き換わる。しかも置き換わるのは、単価が出ていた部分から順にではなく、繰り返し発生していた保守寄りの部分から順に、である。売上構成のどこが薄くなるかは、事前に見積もっておいたほうがいい。

では何が残るか。私は二つあると考えている。一つは、上で書いたイベント設計とマスタ整備。製品を入れても、業務側の粒度を揃える仕事は誰かがやらねばならず、これは業務理解がないとできない。もう一つは、「その製品を入れない」判断ができる立場だ。拠点が3つの会社に40拠点向けの統合基盤は要らない。どこまでが既存システムの改修で足り、どこからがレイヤーの導入かを線引きできることが、発注側にとっての価値になる。

自社でAIエージェント事業をやっていて実感するのは、顧客が最初に聞きたいのは「何ができるか」ではなく「これは自分たちの規模で意味があるのか」だということだ。今回のような大規模事例は、参考にはなるが、そのまま持ち込めるものではない。数字の前提 (拠点数・データの揃い方・7年の助走) をセットで読むべきである。

(編集レンズ: 作る側の目線 / 実装・運用視点 / 発注側と開発会社への含意)

出典: CJ Logistics America Chooses OneTrack's AiOn to Deploy Agentic AI Across 40+ Warehouses

Share

シンシアへのご相談

自社のAI活用・開発体制について相談する

AIをどこまで内製するか、どの業務から着手するか、体制をどう組むか。開発会社・SIer・事業会社の開発部門の方からのご相談を無料で承っています。同じ問題を自社でも解いている立場としてお話しします。

AI活用の進め方を相談する

まだ検討段階の方は 質問だけでもOK(電話番号は任意)

徐 聖博のプロフィール写真

この記事の書き手に直接相談する

徐 聖博株式会社シンシア 代表取締役社長

記事の内容について、より具体的に自社のケースで聞きたいことがあれば、徐 聖博を指名してご相談いただけます。営業担当ではなく、 実際に手を動かしている本人が回答します。

シンシアの開発事例

株式会社Atsumell様|サービスを止めずにデータ基盤を刷新したBPマッチングプラットフォームの開発事例

**約11ヶ月・のべ4名のリレーで、機能開発を止めることなく基盤の刷新を完了しました。** 参画時期の重なりは最大2〜3名で、メンバーは1ヶ月の短期集中から5ヶ月の継続稼働までさまざまです。それでも積み上げが効いたのは、**先に入ったメンバーが構造を残していたから**でした。2025年7月に導入された Repository 層の上で、半年後に別のメンバーが移行作業を進めています。認可条件はコード上の仕様コメントとして、スナップショット方式はアーキテクチャドキュメントとして残り、いずれも「引き継いだ人が読んで分かる」形になっています。 この期間に手掛けた業務機能は、協力会社のラベル分類機能、パートナー企業管理画面、CSV による一括招待とデータ出力、案件辞退フロー、ステータス変更通知メールなど多岐にわたります。基盤刷新と機能開発は、どちらかを止めて行ったものではありません。 > 大規模な基盤刷新は「一度止めて作り直す」以外にも方法があります。呼び出し側を壊さない層を挟み、テーブル単位で少しずつ移し、移行と改善を混ぜない。この3つを守れば、リリースを止めずに土台は入れ替えられます。事業を止められないプロダクトほど、この進め方の価値が出ます。 ### この事例からの示唆 **稼働中のサービスでも基盤は入れ替えられる。** 前提は、呼び出し側の契約(戻り値の形)を保つ中間層を挟むこと、移行単位をテーブルや画面まで小さく割ること、そして移行と機能改善を同じコミットに混ぜないことの3点です。この3つが崩れると、不具合が出たときに原因が移行なのか改善なのか切り分けられなくなり、結果として一度止めるしかなくなります。 **メンバーが入れ替わる前提の体制では、成果物より「残る構造」が価値になる。** 短期参画のエンジニアを増やしても積み上がらないプロジェクトは、設計判断が個人の記憶に閉じていることが原因であるケースが多いです。この事例では、認可条件をコード上の仕様コメントとして、データ設計をアーキテクチャドキュメントとして残す運用を徹底しました。開発体制の失敗パターンについては[システム開発の失敗から立て直す方法](https://blog.xincere.jp/articles/system-development-failure-patterns)でも整理しています。 **要件が固まりきらない領域ほど、データ設計で制約を表現する。** 「協力会社が人材情報を編集したら応募内容が変わってしまう」といった問題は、運用ルールやUIの注意書きでは再発します。スキーマとトリガーで表現すれば、アプリ側の実装漏れがあっても壊れません。要件を仕様に落とす工程そのものについては[要件定義の進め方](https://blog.xincere.jp/articles/requirements-definition-process)を参照してください。 ### よくある質問 **Q. 稼働中のサービスを止めずに基盤刷新はできますか。** A. できます。この事例では約11ヶ月にわたり、機能リリースを継続しながらデータアクセス基盤の移行と主キー変更まで実施しました。ただし「一斉に切り替える」やり方では現実的に困難で、呼び出し側を壊さない中間層を用意して段階移行する設計が前提になります。 **Q. 途中でメンバーが入れ替わる体制でも品質は保てますか。** A. 設計判断がドキュメントとコードに残っていれば保てます。この事例では参画時期の重なりが最大2〜3名、1ヶ月だけの参画者もいる体制で、前任の導入した層の上に後任が半年後の移行作業を積み上げています。 **Q. どのくらいの規模・期間の支援ですか。** A. 約11ヶ月、のべ4名(同時稼働は最大2〜3名)です。プロジェクトの規模や費用感の考え方は[システム開発とは](https://blog.xincere.jp/articles/what-is-system-development)で解説しています。 ### 関連する支援領域 - [システム刷新の進め方|検討・計画から移行までの方法](https://blog.xincere.jp/articles/core-system-renewal-guide) — 稼働中システムを止めずに刷新する判断基準 - [業務システム開発の要件定義とは?進め方・手順を7ステップで解説](https://blog.xincere.jp/articles/business-system-development-requirements-definition-steps) — 要件を仕様に落とす工程 - [システム開発の失敗から立て直す方法](https://blog.xincere.jp/articles/system-development-failure-patterns) — 体制・引き継ぎで詰まったときの選択肢 同じように「稼働を止められないプロダクトの基盤を作り替えたい」という課題をお持ちでしたら、[開発のご相談](https://blog.xincere.jp/contacts)からお問い合わせください。現状のコードとデータ構造を確認したうえで、段階移行の設計からご一緒します。

株式会社Atsumellの事例を読む →

この記事が役に立ったら、Google で優先表示を

Google 検索の「優先するソース」に blog.xincere.jp を追加すると、シンシアの新着記事がトップニュースなどで見つけやすくなります。

Google で優先ソースに追加

著者について

徐 聖博のプロフィール写真
徐 聖博
株式会社シンシア 代表取締役社長

株式会社シンシア(Xincere, Inc.)代表取締役。中国生まれ・3歳から日本で育ち、日本語・中国語・英語を操るトリリンガル。大学院でコンピュータサイエンス(進化型ニューラルネットワーク)を研究し、GREE・メドレー・カウンティア・Indeed Japan などで検索エンジン開発やスタートアップの立ち上げ・グロースを経験。2020年に「人の価値をテクノロジーで最大化する」という想いでシンシアを創業した。エンジニア歴15年以上、代表でありながらほぼ毎日コードを書く現役エンジニアとして、基幹システム開発からAIエージェント活用まで顧客の事業成長に並走している。創業に込めた思いはnoteの創業ストーリーに綴っている。

人気記事

    お問い合わせ

    システム開発やAI推進についてのご相談はこちらから

    無料相談を予約する