予測精度70%のAIを本番業務に載せるということ——厦門のサプライチェーン3社の使い方を読む

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

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

Share
目次開く
  1. 要点 (出典の事実のみ)
  2. 徐 聖博の見解
  3. 開発を生業にしている会社にとって何が変わるか

シンシアへのご相談

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

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

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

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

福建日報 (fjnews) が2026年8月23日に、厦門でAIが産業応用に降りてきている状況を報じた。読みどころは技術ではなく、AIをPoCで終わらせず、サプライチェーンの業務実行レイヤーに組み込んだうえで、その成果を業務KPIで開示している点にある。ここでは、その数字をどう読むか、そして自社で同じものを作るとしたら何が難所かを整理する。

要点 (出典の事実のみ)

  • 厦門の国貿控股集団・建発集団・象嶼集団の3社が出資する厦門供応链数智创新有限公司が「国家人工智能応用中試基地」を運営している。
  • 鉄鉱石の週次・月次トレンド予測の精度は約70%で、2026年5月には値上がりの予警を出した。
  • 象嶼集団の物流では、車両と貨物のマッチング率が60%近くまで到達している。
  • 建発集団の農産物倉庫の巡回・棚卸しは30分以内、認識精度は95%超とされる。
  • 厦門市の人工知能公共サービスプラットフォームは2026年7月23日に稼働し、1か月で2,100項目以上のAIリソースを集約した。2025年末時点で国家届出を通過した大規模モデルは6件 (省内1位)。
  • 火山引擎の事例として、RTL工程で従来エンジニア3〜5名が数週間かけていた作業が18時間に短縮されたことが挙げられている。

徐 聖博の見解

私がこの記事でいちばん引っかかったのは、70%という精度を成果として堂々と出していることだ。

受託開発の現場でAI活用の相談を受けると、精度の議論はほぼ必ず「何%出れば使えるのか」に着地しないまま止まる。90%なら安心、70%なら使えない、という感覚的な線引きが先に立つからだ。だが、業務の性質によって使える精度はまったく違う。鉄鉱石の価格トレンド予測は、外れても即座に損失が確定する種類の判断ではない。人間のバイヤーが元々持っていた勝率を上回れば、それだけで調達判断の期待値は改善する。つまりこの70%は「AIの性能」ではなく「置き換え対象の人間の勝率との差分」として読むべき数字であって、絶対値で評価する対象ではない。

一方、倉庫棚卸しの認識精度95%超と30分以内という数字は、性質が違う。ここは在庫台帳という後続処理の入力になるので、誤りが下流に伝播する。同じ「AI導入」でも、誤りが人の判断で吸収される業務と、誤りがそのままデータになる業務では、必要な精度も、必要な人的チェックの設計もまったく別物になる。この記事の3社が良いのは、価格予測・配車・棚卸しという性質の異なる3種類に、それぞれ別の水準で載せている点だ。「全社でAI精度◯%を目指す」という掛け声とは対極にある。

開発を生業にしている会社にとって何が変わるか

作る側の目線で見ると、この構成でいちばん難しいのは、モデルでも精度でもない。

配車マッチングと倉庫棚卸しは、既存の基幹システム側に「AIの出力を受け取る口」がないと業務に乗らない。 マッチング率60%という数字が出るということは、提案された車両と貨物の組み合わせが、実際の配車オペレーションに投入され、成否がフィードバックとして戻る経路がすでに動いているということだ。ここが、PoCで止まる案件との決定的な差になる。デモは、モデルの出力を画面に出せば成立する。業務に乗せるには、出力を受ける既存システムの改修、例外時に人が差し戻す導線、そして結果を記録して再学習に回すパイプラインが要る。費用の大半はモデル側ではなく、この周辺に落ちる。

したがって、開発会社としてこの種の案件を受けるときに先に確認すべきは、「どのモデルを使うか」ではなく次の3点だと私は考えている。

  1. AIの出力を業務のどの意思決定に差し込むか — 人が最終判断する余地を残すのか、自動実行するのか。ここを決めないと必要精度が決まらない。
  2. 誤りが起きたときに誰がどこで気づくか — 気づく仕組みがない自動化は、精度が高いほど発覚が遅れて損害が大きくなる。
  3. 結果が記録されるか — 記録されないなら、その導入は初日が性能のピークになる。

この3点は見積もり前に決まっている必要がある。決まっていない状態で「AIを入れたい」という引き合いを受けて、モデル選定から入ると、ほぼ確実に精度議論の泥沼に入る。逆に言えば、この3点を発注側と一緒に決められることが、AI案件における開発会社の差別化ポイントになりつつあるというのが、ここ1〜2年AIエージェント事業をやってきた実感だ。単価も体制も、モデルを触れる人を揃えることではなく、業務側の設計を詰められる人を置けるかで決まる。

数字の読み方については、同じく精度を開示している高炉AIで「炉温予測90%」を出した南京鋼鉄の報道も併せて読むと、業種による水準の違いが見えると思う。「AIに任せない範囲を先に決める」という設計思想の実例としてはモノタロウが4か月で購買エージェントを出せた理由、効果測定の単位の取り方はAirbnbが予約1件あたりのサポートコストを削減した事例AIの効果測定を「利用率」から卒業する話が参考になる。自律性をどこまで許すかの設計はパナソニック アビオニクスの航空機保守事例に整理した。

なお、記事は中国国内の産業政策の文脈で書かれており、補助制度・プラットフォーム整備の部分はそのまま日本の環境に置き換えられない。参考にすべきなのは制度ではなく、業務ごとに要求精度を変えて載せているという設計の順序のほうだ。

出典: 在厦门,AI“大脑”长出专业“手脚”

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

    無料相談を予約する