はい、特定の3つの仕事に対して。AIエージェントは、システムがすでに記録している取引から再発注ポイントを最新の状態に保ち、サイクルカウントの管理（開始、追跡、結果の照合）を行い、在庫不足レポートから仕入れ先の注文を準備できます。これらは、人が中断されると漂流する仕事であり、最初に引き渡す価値のあるものです。
支出が境界です。エージェントは、システムが強制する制限内でのみ注文を出すべきであり、まるでジュニアバイヤーが権限に従って働くように、制限を超えた注文や異常に見える注文がある場合は停止して確認すべきです。安全性は、モデルが行動を思い出すことからではなく、ソフトウェアがラインを保持することから来ます。
小さなストックルームの月曜日の朝
棚には12と表示されています。システムは30と表示しています。木曜日に出るはずだった仕入れ先の注文はまだドラフトのままで、これを作成した人が出荷を担当していたからです。これらは通常の意味でのソフトウェアの失敗ではありません。失敗したのは維持管理です：数字が意味を持つために継続的に行う必要がある3つの小さな仕事であり、誰も継続的に行うために報酬を受けていません。
これらの3つの仕事は、小規模または中規模の運営における在庫管理の大部分を占めます：在庫数を正確に保ち、再発注のタイミングを知り、注文を出すことです。それぞれはルーチンであり、フロアで起こる他の何かによって中断され、各々は中断されると漂流します。この漂流が、在庫管理のためのAIエージェントがその価値を発揮する場所であり、エージェントが自分で保持できる3つの仕事のどれで、どこで停止して確認しなければならないかが有用な質問です。
再注文ポイント：簡単な計算、常に維持が必要
標準的なルールは複雑ではありません。再発注ポイントは、補充を引き起こす在庫レベルであり、仕入れ先のリードタイム中の予想消費量に対して、需要や納品の変動に備えて保持される安全在庫を加えたものとして計算されます。アイテムが週に20個売れ、仕入れ先が2週間かかり、1週間分を予備として保持している場合、再発注ポイントは60です。在庫管理に関する教科書は同じ公式を提供します。
難しいのは、すべての入力が変動することです。仕入れ先が運送業者を変更したり、倉庫を失ったりするとリードタイムが変わります。週ごとの需要は、季節、新しい顧客、または静かに販売が停止した製品によって変わります。安全在庫は両方に合わせて変動する必要があります。ほとんどのビジネスでは、再発注ポイントは一度設定され、製品が作成されたときに見直されていません。ルールは問題ありませんが、入力は古くなっています。
これはエージェントが保持できる最初の仕事です。なぜなら、入力はすでに他の作業の副産物としてシステムに存在しているからです。すべての受領書は、注文がいつ行われ、いつ到着したかを記録し、これがリードタイムを提供します。すべての出荷と販売は需要を記録します。在庫取引に対する読み取りアクセスを持つエージェントは、スケジュールに従って各アイテムの再発注ポイントを再計算し、設定した許容範囲を超えて漂流したものにフラグを立て、新しい数値を提案できます。数値自体を変更できるかどうかは許可の決定です。合理的な最初の設定は、提案し、人が受け入れることです。
カウントと不一致
2つ目の仕事は、在庫数を正確に保つことです。完全な年次カウントは高額で、1日運営を停止し、終了する頃にはすでに間違っています。サイクルカウントは、ローテーションで1日に数か所またはアイテムを数える方法であり、ほとんどの運営がこの方法に落ち着き、ほとんどの運営がこれを怠ります。なぜなら、設定した人が移動するとローテーションに所有者がいなくなるからです。
エージェントはカウントではなくローテーションに適しています。今日の期限の場所のカウントを開始し、シフトにいる人に割り当て、午後の中頃までに結果が出ていない場合は追跡し、結果をシステムの数値と比較し、小さな変動の調整を投稿し、大きな変動を取引履歴が添付された人のタスクとして挙げることができます。カウント自体は、棚の前に立っているスキャナーまたはクリップボードを持った誰かが必要です。それに関する規律は、実際に失敗する部分であり、管理的であり、委任可能です。
閾値は重要です。低価値アイテムの2ユニットの変動は調整され、記録されることがあります。40ユニットの変動は、コストがかかるものに対しては、誰も、エージェントでも人でも、再確認なしに調整すべきではありません。通常、領収書が記録されていないか、何かが建物から出て行ったことを意味します。エージェントの調整ツールがスコープされる数値として、閾値を明示的に設定してください。ルールを伝えられたエージェントは毎回それに従いますが、出荷を担当する人はそうではありません。 ￥34,200 ユニットは、エージェントまたは個人によって、再確認なしに調整されるべきではありません。通常、これは領収書が記録されていないか、何かが建物から出て行ったことを意味します。エージェントの調整ツールが対象とする数値として、しきい値を明示的に設定してください。ルールを伝えられたエージェントは毎回それに従いますが、出荷を担当する人はそうではありません。
購入注文：エージェントが支出前にどのように尋ねるか
第三の仕事は人々が心配するもので、資金をコミットします。エージェントは自由に注文を準備し、与えられた権限内でのみそれを行うべきです。これはジュニアバイヤーの働き方と同じです。制限以下では送信します。それ以上の場合、または注文に関して何かが異常な場合（以前に注文したことのないサプライヤー、通常とは大きく異なる数量、価格の変動など）、それは停止して確認します。これは、在庫とサプライヤーの記録があるワークスペースに対して実行される1つのリクエストとしてどのように見えるかです。エージェントの接続にすでに設定された承認限度額があります。
- 再発注ポイントに対する在庫レベルの読み取り
- 再発注ポイント以下のアイテムが3つ、すべてNorthwindから供給されています。
- サプライヤーのデフォルトと現在のリードタイムからドラフトされた注文
- 合計はあなたの承認限度を超えています。あなたの決定を待っています。
エージェントは許可された在庫、サプライヤー、タスクツールを使用しました。接続で設定された制限を超えたため、注文は送信されませんでした。承認されると、注文が送信され、予想される受領品が予約されるため、納品がそれに対して確認できます。
安全である理由は二つあります。一つ目は、制限がモデルによって記憶されるのではなく、システムによって強制されることです。エージェントが使用する接続には支出上限と固定されたツールセットがあり、上限を超える注文はエージェントの意図に関わらず失敗します。二つ目は、承認が記録を作成することです。承認した人、時間、そして彼らが見たドラフトがツール呼び出しと共に記録されるため、エージェントによって行われた注文の監査証跡は手動で行われた注文と同じくらい完全であり、通常はそれ以上です。
どの在庫タスクを引き継ぐか
| タスク | エージェントは所有できます。 | 人が保持する | ソフトウェアが公開する必要があるもの |
|---|---|---|---|
| 再発注ポイントの再計算 | はい、スケジュールに従って変更を提案します。 | 大きな変更の承認 | 取引履歴、受領品、在庫レベルを呼び出し可能なツールとして |
| 在庫不足の監視 | はい、継続的に | ルーチンではありません。 | 各アイテムにサプライヤーを持つ低在庫クエリ |
| サイクルカウントのローテーション | オープン、割り当て、追跡、調整 | 実地カウント | カウント開始、記録および不一致ツール |
| 小さな差異調整 | はい、閾値以下 | 大きな差異は常に | ユーザーの権限と閾値に基づく調整ツール |
| サプライヤー注文のドラフト作成 | はい | ルーチンではありません。 | サプライヤーのデフォルト、アイテムのリードタイム、オープンオーダー |
| サプライヤー注文の発注 | 支出制限以下 | それを超える場合や異常なもの | 接続ごとに強制される支出上限とログ |
| 商品の受け取り | 注文に対する受領の予約 | 玄関での配達確認 | 注文を参照する受領ツール |
右側の列は、任意の在庫システムで実行するテストです。タスクのツールが存在しない場合、エージェントはそれを所有できません。モデルがどれほど優れていても。
ソフトウェアが提供すべきもの
上記のすべては、在庫システムがエージェントが呼び出すことができるアクションとして作業を公開することに依存しています。エージェントが操作しなければならない画面ではありません。4つのことが真実でなければなりません。すべてのアクション（在庫照会、カウント開始、受領予約、注文草案）は、定義された入力を持つ名前付きツールです。各ツールは、エージェントが代表する人の権限の下で提供され、実行されるため、ストックルームリードのために行動するエージェントは、ストックルームリードが承認できない注文を承認することはできません。支出は、資金がコミットされる場所で制限されます。そして、すべての呼び出しは、その入力と結果とともにログに記録されます。
Soisでは、これが倉庫モジュールの構築方法です。ワークスペースはMCPサーバーであり、在庫ツールはその機能に基づいて名付けられています：getLowStock、getStockSummary、startStockCount、getStockDiscrepancies、receiveStock、manageGoodsReceipt、そして仕入先側は購入請求書とともに会計にあります。既に使用しているエージェント（Claude、ChatGPT、または任意のMCPクライアント）をワークスペースアドレスを追加して一度サインインすることで接続します。トークンを貼り付ける必要はありません。ツールはエージェントが見る前にあなたの役割によってフィルタリングされ、実行時に再度確認され、統合ごとに支出制限が設定され、すべてのアクションはその後追跡可能です。あなた自身のエージェントが推論を行うとき、Soisはあなたの代わりにAIを実行せず、何も料金を請求しません。
- 記録を正確にするシステム内のアイテム、サプライヤー、リードタイム、ロケーション。隣に置くのではなく、クリーンな受領書と発送の2週間があれば開始できます。
- まずエージェントに読み取りアクセスを与えてください。再発注ポイントを再計算させ、2週間のドリフトを報告させます。提案をあなたの知識と照らし合わせて確認してください。
- 閾値を設定してください。調整できるバリアンス、コミットできる支出、どちらもシステムが強制する数値として存在し、モデルが従う指示ではありません。
- 範囲を広げてください。注文をドラフトさせ、制限内で送信し、カウントローテーションを実行させてください。何も見つからなくなるまで、毎週ログを読みます。
書き込む前に読み、変更する前に提案し、支出の前に制限を設けます。この順序で従うことで、在庫数を正確に保ち、在庫が切れる前に何を注文する必要があるかを示し、決定が本当にあなたのものであるときだけ決定を求めるエージェントが得られます。
人々が尋ねる質問
AIエージェントは自分で購入注文を出すことができますか？
制限内であれば、はい。エージェントの接続にシステムによって強制される支出の上限を設定し、それ以下の注文を送信させます。上限を超える場合や、新しいサプライヤーや異常な数量などの特異な場合には、注文を準備して確認を求めるべきです。上限はソフトウェア内に存在し、エージェントの指示には含まれません。
エージェントはバーコードスキャナーや物理的なカウントを置き換えますか？
いいえ。誰かがまだ棚に立ってカウントし、スキャナーやクリップボードを使う必要があります。エージェントはカウントに関するローテーションを管理します：それを開き、割り当て、追跡し、結果を照合し、小さな調整を投稿します。その管理の規律が通常は欠けているのです。
エージェントはどのようにサプライヤーのリードタイムを把握しますか？
商品受領書からです。各受領書には注文日と到着日が記載されているため、エージェントは納品が行われるたびにサプライヤーごと、アイテムごとのリードタイムを再計算し、それを再発注点に反映させることができます。受領書が注文に対して記録されていない場合、それが最初に修正すべきことです。
システム内の在庫数がすでに間違っている場合はどうなりますか？
再発注点ではなく、カウントローテーションから始めてください。エージェントにすべての場所でサイクルカウントを一度実行させ、大きな不一致を調査するために人に報告し、小さなものは記録します。数値が信頼できるものであるときのみ、それに基づいて再発注点を計算する価値があります。
- 再発注点（Wikipedia） 標準定義：リードタイム中の消費量に安全在庫を加えたもの
- Soisドキュメント：ワークスペースMCPサーバー 実装された倉庫および会計ツールの名前、権限フィルタリング、予算上限、ログ記録
- モデルコンテキストプロトコル仕様：ツール ツールがどのようにリストされ、呼び出されるか、アクセス制御、入力検証、呼び出しを拒否できる人間の要件
- Sois: セキュリティと権限レイヤー ツールが提供される際と実行される際に強制される権限、統合ごとの支出制限、追跡可能なエージェントの活動
この文書は、記載されている製品が変更される際にレビューされます。次回の予定レビュー： 2026年12月4日.