OpenClaw を使用した AI 在庫管理エージェント

在庫は、財務 (在庫に結びついた運転資金)、業務 (履行速度と正確さ)、販売 (販売可能性)、および調達 (サプライヤーとの関係とリードタイム) といった、あらゆる主要なビジネス機能の交差点にあります。一方的に管理を誤ると、在庫切れが発生し、売上が減少し、顧客との関係が損なわれます。もう一方の管理を誤ると、過剰な在庫が発生して現金が拘束され、倉庫のスペースが占有され、販売する前に期限切れまたは陳腐化する可能性があります。

従来の在庫管理は、固定再注文ポイント、固定安全在庫レベル、手動レビュー サイクルなどの静的パラメーターに依存しています。これらのパラメータは一度設定すれば、在庫切れや在庫過剰が発生して注意が必要になるまで、ほとんど再検討されません。 OpenClaw AI エージェントは、静的なパラメーターを動的で継続的に適応する在庫インテリジェンスに置き換え、需要パターンの変化、サプライヤーの信頼性の変化、市場シグナルにリアルタイムで対応します。

重要なポイント

• OpenClaw 需要予測エージェントは、より高い精度を実現するために外部シグナル (季節性、プロモーション、市場トレンド) を強化した販売履歴の時系列モデルを使用します。
• 再発注点と安全在庫のパラメータは、需要パターンの変化に応じて自動的に再計算されます。パラメータを手動で更新する必要はありません。
• サプライヤー調整エージェントは、RFQ の配布、発注書の作成、配送追跡、および品質検査の調整を自動化します。
• 複数拠点の在庫バランスにより、1 つの拠点で動きの遅い在庫が特定され、再注文する前に需要の高い拠点に移動できます。
• 有効期限および陳腐化の管理により、リスクのある在庫を積極的に特定し、値下げまたは再配布アクションをトリガーします。
• エージェントは、OpenClaw ツール層を通じて Odoo、SAP、NetSuite、Fishbowl、およびカスタム ERP/WMS システムと統合されます。
• すべてのエージェントの決定には推論チェーンが含まれており、パラメータ、信号、計算は完全に透過的で監査可能です。
• ECOSIRE は、メーカー、流通業者、複数拠点の小売業者向けに OpenClaw 在庫管理システムを構築します。

---

在庫管理アーキテクチャ

OpenClaw インベントリ スタックには 5 つの専門エージェントがあります。

[ Sales History + External Data ]
              ↓
[ Demand Forecasting Agent ]   — forecast per SKU per location per week
              ↓
[ Parameter Optimization Agent ] — calculate optimal reorder points and safety stock
              ↓
[ Replenishment Agent ]        — trigger POs, transfers, or production orders
              ↓
[ Supplier Coordination Agent ] — RFQ, PO, delivery tracking, receipt coordination
              ↓
[ Exception Agent ]            — stockout risk alerts, overstock alerts, expiry alerts

すべてのエージェントは、Webhook 経由で ERP/WMS から更新を受信するリアルタイム インベントリ データ ストアを共有します。エージェントの決定は、推奨事項 (人間によるレビュー) またはアクション (ポリシー構成に応じて自律的に実行) として ERP に書き戻されます。

---

需要予測エージェント: 必要なものを予測する

正確な需要予測は、在庫管理におけるすべての基礎です。 30% 間違った予測は、30% 間違った再発注点、30% 間違った安全在庫、および間違った数量の発注書を生成します。

OpenClaw の予測エージェントはモデルの階層を使用します。各 SKU に選択されるモデルは、その需要履歴の長さと安定性によって異なります。

指数平滑法 (ETS): 少なくとも 12 か月の履歴と比較的安定した需要がある SKU 用。このモデルは、レベル、トレンド、季節性のコンポーネントをキャプチャします。

SARIMA: 強い季節的パターンと十分な履歴 (2 年以上) を持つ SKU の場合。 ETS よりも複雑な季節サイクルをうまく処理します。

機械学習 (勾配ブースティング): 外部シグナル (プロモーション、天候、経済指標) の影響を受ける SKU の場合。時系列自体を超えて特徴入力を受け取ります。

移動平均: 履歴が 3 か月未満の新しい SKU の場合。より洗練されたモデルに十分な履歴が存在するまで、シンプルでバイアスの低いベースライン。

export const ForecastDemand = defineSkill({
  name: "forecast-demand",
  tools: ["erp", "analytics", "external-data"],
  async run({ input, tools }) {
    const salesHistory = await tools.erp.getSalesHistory({
      productId: input.productId,
      locationId: input.locationId,
      weeks: 104, // 2 years of weekly data
    });

    const externalSignals = await tools.externalData.getSignals({
      productCategory: input.category,
      signals: ["seasonality-index", "market-trend", "promotion-calendar"],
    });

    // Model selection
    const model = selectForecastModel(salesHistory.length, externalSignals.hasPromoCalendar);

    const forecast = await analytics.forecast({
      model,
      history: salesHistory,
      signals: externalSignals,
      horizonWeeks: 13,
      confidenceIntervals: [0.80, 0.95],
    });

    return {
      productId: input.productId,
      locationId: input.locationId,
      forecastWeeks: forecast.weeks,
      // Returns point estimate + confidence intervals per week
    };
  },
});

予測誤差の監視: エージェントは毎週、SKU ごとに実際と予測を追跡し、MAPE (平均絶対誤差率) を計算します。モデルのパフォーマンスが一貫して低い (MAPE > 25%) SKU には、手動レビューまたは更新された機能によるモデルの再トレーニングのフラグが立てられます。

---

パラメータ最適化エージェント: 動的安全在庫と再注文ポイント

正確な予測を利用して、パラメーター最適化エージェントは、各拠点の各 SKU の統計的に最適な安全在庫と再注文ポイントを計算します。

安全在庫の計算式: エージェントは、ターゲットのサービス レベルに合わせて調整された統計的安全在庫の計算式を使用します。

Safety Stock = z × σ_LT × √(L + R)

場所:

• z = ターゲット サービス レベルの Z スコア (例: 95% の場合は 1.65、99% の場合は 2.33)
• σ_LT = リードタイム中の需要の標準偏差
• L = サプライヤーのリードタイム (週単位)
• R = 週単位のレビュー期間

サービス レベルの目標は、製品カテゴリごとに構成できます。動きが鈍くて利益率の低い商品は 90% を使用する可能性があります。動きの速い、利益率の高い製品、またはリードタイムが長い品目では、99% が使用される可能性があります。

export const OptimizeParameters = defineSkill({
  name: "optimize-inventory-parameters",
  tools: ["erp", "analytics"],
  async run({ input, tools }) {
    const [forecast, supplierData, currentParams] = await Promise.all([
      tools.analytics.getForecast({ productId: input.productId, locationId: input.locationId }),
      tools.erp.getSupplierLeadTime(input.productId),
      tools.erp.getCurrentInventoryParams(input.productId, input.locationId),
    ]);

    const serviceLevel = getServiceLevelTarget(input.productCategory);
    const z = getZScore(serviceLevel);

    // Calculate demand variability during lead time
    const demandDuringLeadTime = forecast.weeks.slice(0, supplierData.leadTimeWeeks);
    const meanDemand = mean(demandDuringLeadTime.map(w => w.pointEstimate));
    const stdDevDemand = stdDev(demandDuringLeadTime.map(w => w.pointEstimate));

    const safetyStock = Math.ceil(z * stdDevDemand * Math.sqrt(supplierData.leadTimeWeeks + 1));
    const avgWeeklyDemand = mean(forecast.weeks.map(w => w.pointEstimate));
    const reorderPoint = Math.ceil(avgWeeklyDemand * supplierData.leadTimeWeeks + safetyStock);
    const economicOrderQty = calculateEOQ(avgWeeklyDemand, input.orderingCost, input.holdingCostRate, input.unitCost);

    const recommendation = {
      safetyStock,
      reorderPoint,
      economicOrderQty,
      currentSafetyStock: currentParams.safetyStock,
      currentReorderPoint: currentParams.reorderPoint,
      changeSignificant: Math.abs(reorderPoint - currentParams.reorderPoint) / currentParams.reorderPoint > 0.15,
    };

    if (recommendation.changeSignificant) {
      // Significant change — flag for human review before applying
      await flagForReview(recommendation, input);
    } else {
      // Minor adjustment — apply automatically
      await tools.erp.updateInventoryParams(input.productId, input.locationId, { safetyStock, reorderPoint });
    }

    return recommendation;
  },
});

パラメータ変更ポリシー: 大きなパラメータ変更 (再注文ポイントまたは安全在庫に対する 15% を超える調整) は、自動的に適用されるのではなく、人間によるレビューのためにフラグが立てられます。微調整は中断することなく適用されます。これにより、予測モデルがフィルタリングすることをまだ学習していない短期的な需要の急増に基づいて、システムが劇的な変更を行うことが防止されます。

---

補充エージェント: 適切なタイミングで適切なアクションをトリガーする

在庫が再注文ポイント以下になった場合、補充エージェントは適切なアクションを決定します。それは必ずしも発注書であるとは限りません。

補充のためのディシジョンツリー:

1. 在庫は別の所有拠点で利用可能ですか? 利用可能であり、転送コストが発注コストよりも低い場合は、拠点間の転送を開始します。
2. この製品に対して既存のオープン発注書はありますか? あり、予想される受領書でニーズが満たされている場合は、重複を作成するのではなく、必要に応じて発注書の数量を更新します。
3. 注文書は適切ですか? 最小注文要件に合わせて調整された経済的な注文数量を使用して PO を作成します。
4. これは見込生産製品ですか? 発注書ではなく製造オーダーを作成します。

export const TriggerReplenishment = defineSkill({
  name: "trigger-replenishment",
  tools: ["erp", "warehouse"],
  async run({ input, tools }) {
    const neededQty = input.reorderPoint + input.economicOrderQty - input.currentStock;

    // Check inter-location transfers
    const otherLocations = await tools.erp.getStockByLocation(input.productId, {
      excludeLocation: input.locationId,
      minAvailable: neededQty,
    });

    if (otherLocations.length > 0) {
      const source = otherLocations.sort((a, b) => b.available - a.available)[0];
      const transferCost = await estimateTransferCost(source.locationId, input.locationId, neededQty);
      const orderCost = await estimateOrderCost(input.productId, neededQty);

      if (transferCost < orderCost * 0.7) {
        await tools.erp.createInternalTransfer({
          productId: input.productId,
          fromLocationId: source.locationId,
          toLocationId: input.locationId,
          qty: neededQty,
        });
        return { action: "TRANSFER_CREATED", sourceLocation: source.locationId };
      }
    }

    // Create purchase order
    const bestVendor = await selectBestVendor(tools.erp, input.productId, neededQty);
    const po = await tools.erp.createPurchaseOrder({
      productId: input.productId,
      vendorId: bestVendor.id,
      qty: Math.max(neededQty, bestVendor.minimumOrderQty),
      price: bestVendor.price,
      expectedDelivery: addDays(new Date(), bestVendor.leadTimeDays),
    });

    return { action: "PO_CREATED", poId: po.id, qty: neededQty, vendor: bestVendor.name };
  },
});

---

複数の場所の在庫バランス調整

複数の倉庫や小売店を持つ企業では、在庫の不均衡がよく起こります。場所 A には製品 X が 200 個あり、ほこりをかぶっている一方で、場所 B は在庫切れで発注書が出ています。バランシング エージェントは、これらの機会を毎週特定します。

バランスアルゴリズム:

1. 現地の需要予測に基づいて、各拠点での予測供給週数を計算します。
2. 供給が 8 週間を超えている (需要に対して在庫が過剰である) 場所を特定します。
3. 供給が 3 週間未満 (在庫不足) の場所を特定します。
4. すべての拠点を目標供給週数に達させる移動量を計算します。
5. 転送コストが、受信場所に新しい注文書を発行するコストよりも低いかどうかを確認します。
6. 経済的に正当な転送のための転送オーダーを作成します。

---

有効期限と陳腐化の管理

製品ライフサイクルが短い生鮮食品や電子機器には、積極的な有効期限管理が必要です。 Expiry Agent はリスクのある在庫を監視し、タイムリーな介入をトリガーします。

生鮮食品の場合:

• 有効期限の 60 日前: 優先ピッキングのフラグ (FEFO - 有効期限先着順)。
• 有効期限の 30 日前: プロモーション価格で利用可能な在庫を営業チームに通知します。
• 有効期限の 14 日前: 値下げ価格の推奨または寄付/廃棄の承認を作成します。

動きが遅い製品の場合:

• 在庫速度 (月あたりの販売数) と現在の供給月数を計算します。
• 供給期間が 12 か月を超え、供給速度が低下傾向にある製品には、過剰としてフラグが立てられます。
• エージェントは、推奨されるアクション (値下げ、サプライヤーへの返品 (返品契約が存在する場合)、または清算) を含む超過 SKU のリストを生成します。

---

サプライヤーのパフォーマンスの監視

サプライヤー調整エージェントは、納期厳守率、数量精度 (納品数量と注文数量に対する)、品質合格率の 3 つの側面にわたってサプライヤーのパフォーマンスを追跡します。これらの指標は、新しい注文書を作成する際のベンダー選択の決定に反映されます。

export const UpdateSupplierPerformance = defineSkill({
  name: "update-supplier-performance",
  tools: ["erp"],
  async run({ input, tools }) {
    const receipt = await tools.erp.getPurchaseReceipt(input.receiptId);
    const po = await tools.erp.getPurchaseOrder(receipt.poId);

    const onTime = receipt.receivedDate <= po.expectedDelivery;
    const qtyAccuracy = receipt.receivedQty / po.orderedQty;
    const qualityAcceptanceRate = receipt.acceptedQty / receipt.receivedQty;

    await tools.erp.updateSupplierScore(po.vendorId, {
      deliveryId: receipt.id,
      onTime,
      qtyAccuracy,
      qualityAcceptanceRate,
      leadTimeActual: daysBetween(po.createdDate, receipt.receivedDate),
    });

    return { vendorId: po.vendorId, onTime, qtyAccuracy, qualityAcceptanceRate };
  },
});

ベンダー スコアは納品ごとに更新され、補充エージェントでのベンダーの選択に影響します。納期厳守が一貫して低いベンダーは、選択アルゴリズムで加重が下げられ、将来の発注者をより信頼性の高い代替品に誘導します。

---

よくある質問

新しい SKU の需要予測モデルが正確になるまでにどれくらい時間がかかりますか?

販売履歴のない新しい SKU は、少なくとも 4 週間のデータを必要とする移動平均モデルから始まります。 12 週間後、エージェントは指数平滑法に切り替わります。 52 週間を過ぎると、季節のパターンを組み込むことができます。最初の 12 週間は、モデルの調整中に在庫切れを防ぐために、安全在庫が控えめに設定されます (製品カテゴリの業界平均変動を代用として使用)。予測精度は通常、16 ～ 24 週間以内に目標範囲 (安定した製品の場合は MAPE が 15% 未満) に達します。

システムは、需要が集中している商品 (断続的、不定期な販売) をどのように処理しますか?

一時的な需要 (スペアパーツ、B2B 製品、季節限定品などに一般的) は、標準的な時系列予測には適合しません。集中的な需要 (Croston の方法を使用した場合、需要間の間隔が 1.3 を超える) があると識別された SKU の場合、エージェントは、断続的な需要向けに設計された Croston の方法または Syntetos-Boylan 近似に切り替えます。集中需要製品の安全在庫の計算では、より大きな変動性を考慮して、より広い信頼区間が使用されます。

システムは 3PL の WMS と統合できますか?

はい。サプライヤー調整および補充エージェントは、公開 API (ほとんどの主要 3PL が REST API を提供します) を介して 3PL と通信するか、3PL に最新の API がない場合は EDI を介して通信します。 API アクセスのない 3PL の場合、エージェントは文書処理パイプラインを使用して、電子メールで送信された ASN (Advance Shipping Notice) および在庫レポート ファイルを自動的に処理できます。

プロモーションや 1 回限りのイベントによって需要が促進される製品を、システムはどのように処理しますか?

プロモーション イベントは外部信号データ ソースに登録されます。既知のプロモーションの前に、エージェントは同様のプロモーションの過去の上昇率 (利用可能な場合) または構成可能な上昇乗数を使用して予測を上方調整します。プロモーション後、エージェントはプロモーション後の需要の落ち込みを検出し、それに応じて補充を調整して、プロモーション後の需要の過剰構築を回避します。履歴データのない 1 回限りのイベントの場合、エージェントはイベント計画期間中の手動予測調整のために関連する SKU にフラグを立てます。

補充アクションを実行する必要があるときに ERP がオフラインの場合はどうなりますか?

補充エージェントは、補充タスクを永続メッセージ キューに入れます。 ERP 接続が復元されると、エージェントはキューに入れられたタスクを順番に処理します。時間制限のある補充 (在庫がゼロで優先度の高い顧客注文が保留中の製品) の場合、エージェントは調達チームにもアラートを送信するため、システム接続が復元されている間に手動で発注できるようになります。

---

次のステップ

静的な在庫管理では、予測が容易な製品の過剰な安全在庫、不安定な製品の不十分なカバーなど、あらゆる方向にお金が残ることになります。 OpenClaw 在庫エージェントは現実に合わせて継続的に再調整し、在庫切れのリスクと維持コストの両方を同時に削減します。

ECOSIRE の OpenClaw 実装サービス には、需要予測の調整、パラメータの最適化セットアップ、補充ポリシーの構成、ERP 統合など、在庫管理の完全な自動化が含まれています。当社の運用チームは、サプライ チェーンの深い知識と OpenClaw エンジニアリングを組み合わせて、目に見える運転資本の改善を実現するシステムを構築します。

ECOSIRE に連絡 して在庫管理の課題について話し合い、カスタム自動化の提案を受けてください。