「あの人がいないと発注できない」を、まだ続けますか？

従業員30人の卸売業。発注担当は1人。その人が休むと在庫が狂う。辞めたら業務が止まる。——この構造、地方の中小企業なら見覚えがあるはずだ。

今週、この「属人化」を殺すための部品が全部揃った。AIエージェントの在庫管理ベンチマーク論文、MCPの大規模評価、そしてPython325行で動く実装例。それぞれバラバラに出てきたニュースだが、組み合わせると見える景色がある。在庫管理の自動発注が、中小企業の予算感で現実になったということだ。

結論から言う。月額5万円以下のランニングコストで、「需要予測→発注判断→発注実行」のループを自動で回せる仕組みが、今の技術スタックなら組める。300万円のパッケージシステムを買う時代は終わった。

—

AIエージェントは「在庫管理のベテラン」にどこまで迫ったか

まず事実を押さえる。arXivに掲載された「AI Agents for Inventory Control」論文が面白い。1,000以上の在庫シナリオ（需要変動パターン、リードタイムのばらつき、季節性など）をベンチマーク化し、LLM（大規模言語モデル）ベースのAIエージェントと従来のOR（オペレーションズリサーチ）アルゴリズムを比較した。

ポイントは3つ。

1. 安定した需要パターンでは、ORアルゴリズムが依然として強い。 当たり前だ。数理最適化が得意な領域は数理最適化に任せればいい。
2. 需要が不規則に変動する場面では、LLMエージェントがORを上回るケースが出た。 「先月と同じ」が通用しない状況で、文脈を読んで判断を変えられるのがLLMの強み。
3. ORとLLMのハイブリッド構成が最も安定した成績を出した。 定常時はルールベース、異常時はLLMが介入する設計。これが実務に一番近い。

ここで考えてほしい。地方の卸売業で在庫管理が属人化する理由は何か。「通常はパターンで回せるが、季節の変わり目やイレギュラーな大口注文のときに経験者の判断が必要」だからだ。まさにこの「例外処理」をLLMが担えるようになったのが、今回の論文の示す意味だ。

ベテラン担当者の頭の中にあった「なんとなくの勘」——それは実は「過去の類似パターンとの照合」だった。LLMはまさにそれが得意だ。

—

MCPが変えたのは「つなぎ」のコスト

次にMCP（Model Context Protocol）。これはAnthropicが提唱した、AIエージェントが外部ツールを呼び出すための標準プロトコルだ。カタカナで言うと難しく聞こえるが、やっていることはシンプル。AIが「Googleスプレッドシートを読む」「発注システムにAPIを叩く」「Slackに通知する」といった外部操作を、統一されたやり方でできるようにする規格だ。

arXivの「MCP-Atlas」論文では、実在するMCPサーバー群を使った大規模ベンチマークが報告された。注目すべき数字がある。

• 評価対象のMCPサーバー：50以上
• AIエージェントが「ツールを正しく選択し、正しく呼び出せた」成功率：モデルによって差はあるが、上位モデルで80%超
• 複数ツールをまたぐ「マルチステップ」タスクでも、成功率は大きく落ちなかった

これが何を意味するか。従来、AIと業務システムをつなぐには「インテグレーション」という名の高額な開発が必要だった。SIerに頼めば数百万円。それがMCPで標準化されたことで、つなぎのコストが劇的に下がった。

中小企業にとって、これは決定的に重要だ。AIモデルの性能がいくら上がっても、自社の在庫データベースや発注システムとつながらなければ意味がない。MCPは、その「つながらない問題」を月額数千円のサーバーコストで解決する。

—

325行のPythonで何が動くのか

では、具体的にどう組むのか。ここが一番大事だ。

想定するのは従業員30人の日用品卸売業。SKU（管理品目数）は500。発注先は10社。現状、発注担当1人が毎朝Excelを見ながら発注書を作っている。月の人件費換算で約30〜35万円相当の工数。

構成

処理フロー（Python 325行の中身）

1. 毎朝6時に自動起動。 在庫データをスプレッドシートから取得（MCP経由）
2. SKUごとに需要予測を実行。 過去90日の出荷データから向こう14日の予測を生成
3. 安全在庫を下回るSKUを抽出。 ここまではルールベース（ORアルゴリズム）
4. 異常値があればLLMに判断を委ねる。 「先月比200%の出荷増」など、パターンから外れたSKUについてはClaude APIに文脈（季節、過去の類似イベント、取引先情報）を渡して発注量を提案させる
5. 発注ドラフトをSlackに投稿。 担当者は「承認」ボタンを押すだけ
6. 承認されたら発注メールを自動送信。 MCPで接続したメール送信ツールが実行

この6ステップが325行に収まる。なぜか。MCPがツール接続を抽象化してくれるから、API呼び出しのボイラープレートコードが激減するのだ。

コスト比較

月30万円が月1.5万円。年間で約340万円の削減。初期投資は半年で回収できる計算だ。

しかも、これは「発注担当者をクビにする」話ではない。発注担当者が毎朝2時間かけていたルーティンが15分の承認作業になる。空いた時間で、取引先との価格交渉や新規仕入れ先の開拓など、「人間にしかできない仕事」に集中できる。

—

中小企業だからこそ勝てる構造

ここが一番伝えたいことだ。

大企業はSAPやOracleの在庫管理モジュールに年間数千万円を払っている。カスタマイズにさらに数千万円。導入に1〜2年。そして「システムに業務を合わせる」という本末転倒が起きる。

中小企業は違う。SKU500、発注先10社なら、325行のPythonで十分だ。業務に合わせてコードを変えればいい。MCPのおかげで、つなぐツールを後から差し替えるのも簡単。スプレッドシートからkintoneに変えたければ、MCPサーバーを差し替えるだけ。

小さいことが武器になる。 意思決定が速い。試して駄目なら翌週に変えられる。大企業が稟議を回している間に、中小企業は3回トライアンドエラーを回せる。

これは在庫管理に限った話ではない。請求書処理、見積作成、日報集計——「あの人しかやり方を知らない」業務は全部、同じ構造で仕組み化できる。MCPという「つなぎの標準規格」が出たことで、業務ごとにバラバラだった自動化の部品が、共通の設計思想で組めるようになった。

—

で、結局どうすればいいのか

3ステップで始められる。

1. 棚卸しする（1日）
自社の「属人化している業務」をリストアップする。判断基準は「その人が1週間休んだら止まるか？」。止まるなら、それが最優先の自動化候補だ。

2. 最小構成で組む（1〜2週間）
いきなり全SKUでやらない。売れ筋トップ50品目だけで、需要予測→発注ドラフト生成→Slack通知の流れを組む。Pythonが書けなければ、地元のフリーランスエンジニアに30〜50万円で依頼すればいい。MCPのおかげで、以前なら100万円かかった開発が半分以下になっている。

3. 2週間回して数字を見る（2週間）
予測精度、欠品率、発注工数の3つだけ追う。数字が改善していれば全品目に展開。改善していなければ、予測ロジックを調整する。コードを変えるだけだから、パッケージソフトのように「カスタマイズ費用100万円」とはならない。

最短1ヶ月で「勝手に回る発注」が手に入る。

—

まとめ：部品は揃った。あとは組むだけ

今週出た3つのニュースを並べると、こうなる。

• AIエージェント論文 → 在庫管理の判断をAIに任せられることが、1,000シナリオで実証された
• MCP-Atlas論文 → AIと業務ツールをつなぐ標準規格が、実用レベルに達したことが確認された
• 325行Python実装 → 上の2つを組み合わせた実装が、中小企業の予算感で動くことが示された

属人化を殺す仕組みの部品が、全部揃った。

問題は、これを知って「面白いね」で終わるか、来週から組み始めるかだ。地方の中小企業にとって、技術の民主化は「いつか来る未来」ではない。もう来ている。手を伸ばすかどうかだけの話だ。

—