restock

在庫補充

2つのスキルを連携させ、発注が忘れられたメールで終わるのではなく、帳簿に記録されるようにします。inventory-plannerが購入する商品を決め、ap-processorがその費用を記録する準備をします。

この連携で解決するのは、小さくても高くつく問題です。再発注の内容が決まり、POが作成され、メールが送信されます。しかし、その後は何も記録されないため、6週間後に請求書が届いても、価格や数量が正しかったか誰にも分かりません。

ステップ1 — 購入する商品を決める（inventory-planner）

inventory-plannerを呼び出します。

• 入力： Shopify、Square、NetSuiteから取得した販売履歴と手持ち在庫、またはその両方をまとめたアップロード済みCSV。
• 出力： 商品ごとの7日間および28日間の販売速度、保守的に見積もった在庫切れ日、金額を含む60日分の適正な再発注内容、別途まとめた動きの遅い商品のリスト。

計算はすべてinventory-plannerが担います。2つの期間での販売速度、歪みへの対処、リードタイムとの比較、季節性のルールが含まれます。ここで計算し直さないでください。

連携の中で特に重要なルールが2つあります。

• 販売速度がゼロの商品は、再発注候補になりません。 その商品に資金が拘束されているものとして、動きの遅い商品に分類されます。売上がないなら、仕入れを増やすのではなく、仕入れを止めます。
• 在庫切れの期間は、需要がゼロだったことを意味しません。 需要が抑制されていたということであり、ゼロとして扱うと、いつまでも発注数が不足します。

確認ポイント — 発注リスト。 何かを作成する前に、合計金額と、まもなく在庫切れになる商品の数を提示します。オーナーはリストを承認するか、項目を削るか、数量を変更します。各項目には販売速度、在庫日数、リードタイム、数量、費用が記載されているため、作り直しではなく、1分で判断できます。

ステップ2 — POと仕入先へのメールを作成する（inventory-planner）

承認された項目について、inventory-plannerが仕入先ごとの発注書と、それに添えるメールをオーナーの文体で作成します。

確認ポイント — どちらもステップ1とは別に、それぞれ明示的な承認を待ちます。 発注リストの承認は、何を発注するかの合意です。POの送信は、資金を使い、仕入先との関係に影響する決定です。確認を求める前に、仕入先、明細、合計金額を提示してください。

メールコネクター（GmailまたはMicrosoft 365）が接続されていない場合、POとメールはオーナーが手動で送信するファイルになります。それで一連の作業は完了です。

ステップ3 — 将来届く請求書と照合できる記録を残す

ここでは2つの異なる処理が行われ、どちらのスキルが担当するかが重要です。

inventory-plannerは発注書そのものを保管します。 承認済みPOはinventory-plannerの書類です。仕入先、明細、数量、価格、予定日が記載されます。ステップ2で保存され、オーナーに渡されます。これが発注内容の記録になります。

ap-processorに渡すのは、POではなくコードを割り当てたメモです。 仕入先、PO番号、合計金額、予定日、支出に該当する勘定科目、クラス、ジョブを渡します。ap-processorは台帳に発注書を作成しません。請求書が届いたときにPOを読み取り、請求書、PO、納品受領書の3点照合を行います。このステップで必要なのは、照合先となる場所にコードを割り当てた記録を残すことです。

• 入力： 仕入先、PO番号、合計金額、予定日、コード。
• 出力： 仕入先に紐づけてファイリングされた、コードを割り当てたメモ。6週間後に請求書が届いたとき、価格と数量を実際に承認された内容と照合できます。

確認ポイント — コードの承認。 これはap-processor独自の確認ポイントで、ここで処理を止めます。オーナーが承認するまで台帳には何も記録されず、請求書として記録されることはあっても、支払いとして処理されることはありません。このコマンドでは一切、資金は動きません。届いた商品の支払いには/pay-the-billsを使います。

新しい仕入先のコードに確信が持てない場合、ap-processorは推測せずに質問します。今ひとつ質問するほうが、1年分の誤ったコード付けを防げます。

台帳コネクターが接続されていない場合、コードを割り当てたメモは、POとともにインポートファイルと概要として出力されます。3点照合は後で、実在する記録を使って手動で行えます。

ステップ 4 — リズムにする

Ray Okonkwo は Okonkwo Mechanical を経営しており、何かが足りなくなったときに確認する部品棚を頼りにしていますが、気づくのはいつも手遅れです。Google Calendar を接続したら、オーナーが便利だと感じた補充の後に一度だけ、再発注を判断するための定期ブロックをカレンダーに設定することを提案します。

緊急対応よりも、リズムとして定着させるほうがずっとうまくいきます。一度だけ提案します。断られた場合や返答がない場合は、それ以上勧めません。

代替手順

販売 CSV と在庫数の組み合わせも、完全にサポートされている入力です。多くの事業者はクリップボードで数を数えており、それも正当なデータです。販売速度、在庫切れ日、再発注量、PO、ベンダーへのメールは、どの入力方法でも同じように作成されます。帳簿への記録はインポートファイルになります。

してはいけないこと

• 承認なしに PO を送信したり、ベンダーにメールを送ったりしないでください。 前者はお金を使い、後者は信頼を損ないます。
• 購入リストの承認を、送信の承認として扱わないでください。 承認の関門は二つあり、判断も二つです。
• 販売速度がゼロの商品を再発注しないでください。
• すでに入荷予定の数量を差し引かずに再発注量を決めないでください。 動きの遅い商品を二重発注すると、何年も資金を寝かせることになります。
• 販売速度、リードタイム、在庫切れ日を捏造しないでください。 履歴が不十分な場合は、SKU ごとに報告します。
• ここでは何も支払わないでください。 PO は準備するだけで、支払いません。支払いには /pay-the-bills を使います。
• 金額を示さずに数量だけを報告しないでください。 オーナーが判断するのは現金についてであり、個数ではありません。

出力

再発注計画は、オーナーが保存した出力設定に従って提供してください。デフォルトで Markdown ファイルを選んではいけません。 ## Business context ブロックの Output preference を確認してください（共有スタイルガイドのルール、../../shared/artifact-style.md）。

• ビジュアルアーティファクト（デフォルト）： ハウススタイルに沿った HTML ページとして計画を作成します。コミット済み総額を先頭の金額タイルとして表示し、各 SKU は販売速度、在庫切れ日、再発注量を tabular-nums で示す行にし、すでに入荷予定の商品にはピルを付けます。PO 文書とインポートファイルは作業ファイルとして添付し、二つ目の成果物にはしません。
• docx / md / notion / canva の指定： 同じ内容を指定の形式で提供します。DOCX または Markdown ファイル、コネクター経由で作成する Notion ページ（保存先を指定し、既存のページを上書きしない）、または Canva コネクター経由で作成する Canva Doc（実行ごとに新しいデザインを作成し、日付を付けた名前にする。表はリストに変換する）を使います。Notion または Canva が接続されていない場合はビジュアルアーティファクトに切り替え、その理由を伝えます。
• このスキルに最適： ビジュアルアーティファクトを使います。この出力は購入判断のためのものであり、文章の作成が目的ではありません。

実行後

PO は送信済みで、請求書と照合するためのコード化された記録が待機しています。請求書が届いたら、自然な次のステップは「請求書を支払う」です。/pay-the-bills は照合、現金確認、支払いの承認ゲートを実行します。関連する項目として、確定した発注が今後 60 日間に与える影響を確認する「キャッシュ予測」（cash-flow-snapshot）と、期間終了時の「月次締め」（/close-month）もあります。提案は最大三つまでとし、オーナーがこのセッションですでに断った提案は繰り返さないでください。

一覧にないツールを使う場合

このスキルで指定されているコネクターは、テスト済みの手順であって、利用可能な範囲を制限するものではありません。オーナーが、未接続または一覧にないツールをこのワークフローで使いたい場合は、build-connector を提案してください。まずコネクターディレクトリを確認し、見つからなければ Zapier 経由で接続します。生の API を使った手作業での構築は決して行いません。接続後、そのツールは他の任意のコネクターと同様に、同じ承認ゲートのもとでこのスキルに加わります。