順豊控股の約1.5万AIエージェント|次の難所は「数」ではなくエージェント同士の協調にある

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

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

Share
目次開く
  1. 要点(出典の事実のみ)
  2. 私の見解
  3. 開発を生業にしている会社にとって、これは何を意味するか
  4. よくある誤解
  5. 関連記事

シンシアへのご相談

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

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

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

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

中国の物流大手・順豊控股(S.F. Holding)が2026年8月28日夜に発表した半期報告で、6月末時点のAIエージェント(智能体)数が約1.5万個に達したと開示した。本稿は、この数字と「エージェント同士の協同調用」という段階を、AIエージェントを作って納める側としてどう読むかを整理する。全社導入をPoCから先へ進めたい経営・DX責任者、そして同じものを受注する開発会社の意思決定者に向けて書いている。

要点(出典の事実のみ)

  • 順豊控股は2026年8月28日夜に2026年上半期の半期報告を開示。営業収入1,555億元(前年同期比5.9%増)、扣非帰属母公司純利益50億元(同9.3%増)。
  • 粗利額209.1億元(同7.7%増)、粗利率13.4%(前年比0.2ポイント上昇)。扣非純利益率は3.2%(同0.1ポイント上昇)。営業活動によるキャッシュフローは112億元。
  • サプライチェーン及び国際業務の営業収入は395.8億元で全体の25.5%、増収率15.6%。国際快逓・越境EC物流は60%成長。
  • 「AI技術応用の規模化落地」により内部の効率化・コスト削減を進めたとし、6月末時点で智能体(AIエージェント)数が約1.5万個に達したと記載。適用領域は市場営銷(マーケティング)、服務履約(サービス履行)、財務・従業員管理、研発創新(研究開発)。
  • 「逐步实现智能体之间的协同调用」 — エージェント間の協調呼び出しを段階的に実現しているとしている。自社大規模モデル「丰知大模型」を用いた「サプライチェーン全リンクAI智能予測・調度プロジェクト」は2026 IDC中国人工知能創新奨を受賞。

私の見解

1.5万という数字は、たしかに目を引く。ただ私がこの開示で本当に重いと思ったのは数ではなく、「智能体之间的协同调用」という一行のほうだ。

エージェントを1つ作るのは、いまや難しくない。難しいのは、業務を「エージェントに渡せる粒度」まで分解し、入力と出力と失敗時の扱いを定義し続けることだ。1.5万個という数は、モデルの性能ではなく、その分解作業をどれだけの人数で何か月回し続けたかの指標として読むのが正しい。裏返せば、これはモデルを買えば追いつく差ではない。業務定義の在庫を持っているかどうかの差である。

そして、その次に来るのが協調だ。ここが本当の難所だと私は考えている。単体のエージェントは、失敗しても人間が気づいて直せる。エージェントAの出力をエージェントBが入力として使い始めた瞬間、誤りは静かに伝播する。呼び出し順序、権限、途中で止めた場合の巻き戻し、そして「どのエージェントの判断でこの結果になったか」を後から辿れること。受託でAIエージェントを納めていると、要件定義のたびにこの話になる。順豊が「逐步(段階的に)」と書いているのは、慎重さの表明であって、遠慮ではないはずだ。

もう一点、経営数値の読み方には注意がいる。上半期の増収増益や粗利率0.2ポイント改善は、AI単独の成果ではない。サプライチェーン・国際事業が15.6%伸び、越境EC物流が60%伸びていることのほうが、構成比25.5%という規模から見て利益への寄与は大きい。開示は「AIで内部の提効降本」と書いているが、そこから逆算して「1.5万エージェントで利益が9.3%増えた」と読むのは誤りだ。AI施策の効果は、全社の損益ではなく業務単位で測るしかない。

(編集レンズ: 作る側の評価 / 実装・運用視点 / 発注側の意思決定)

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

受注ポイントが移動する、というのが私の見立てだ。

これまでのAI案件は「エージェントを1体作る」の集合だった。1体あたりの単価は下がり続けている。生成そのものが安くなっているので当然だ。一方で、順豊のような段階に入った企業が次に必要とするのは、エージェントの実行基盤である。登録・権限・呼び出しの依存関係・監査ログ・評価とロールバック。これは業務知識とインフラ設計の両方が要る領域で、モデルの進化で消えない。単価も落ちにくい。

したがって、いま自社の提案を組むなら、「業務ヒアリングして1体作ります」ではなく「10体目・100体目を足すときに壊れない置き場を先に作ります」と言えるかどうかで差がつく。前者は内製に食われる。後者は内製でやるほど設計負債の怖さがわかるので、外に出したくなる。人材育成の観点でも、後者のほうがチームに残る技術が多い。

もう一つ、日本企業がこの事例をベンチマークにするときの現実的な注意を書いておく。順豊は自社の大規模モデル(丰知大模型)を持ち、物流現場・データ・設備を自社で握っている。この垂直統合を前提にした数字なので、そのまま「うちも1.5万個」と目標に置くと必ず滑る。真似すべきは数ではなく順序、業務の分解を先に、協調の設計をその次に、という順序のほうだ。

よくある誤解

「エージェントの数が多い=AI活用が進んでいる」ではない。 数は分解作業量の指標であって、成果の指標ではない。成果を測るなら、業務単位の処理時間・エラー率・単位あたりコストを見る。全社の利益率と紐づけると、必ず他の施策の効果を混ぜて読むことになる。

「協調は最後にやればいい」ではない。 単体エージェントを増やしてから後付けで連携させるのが一番高くつく。呼び出しと権限の置き場だけは、2体目を作る時点で決めておくほうが安い。

関連記事

出典: 顺丰控股上半年扣非归母净利润同比增长9.3% 供应链及国际业务全面提速

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推進についてのご相談はこちらから

    無料相談を予約する