在庫と販売機会を管理する

このページでは、FBA 在庫の状況を確認して補充・整理の判断材料を作ることと、在庫状況を踏まえて広告の強弱を検討することができます。在庫切れリスクの診断・補充発注ブリーフの作成・過剰在庫の検出まで、広告運用と地続きの在庫業務を効率化するときに使います。

このページの基本情報

項目	内容
このページでできること	FBA 在庫の一覧・在庫週数の確認、在庫切れリスク診断と補充発注ブリーフの作成、過剰在庫・滞留在庫の検出、在庫状況を踏まえた広告調整の検討、定期おトク便の欠品による機会損失の把握
対象	FBA 在庫（販売可能在庫 / 入荷作業中在庫 / 週次出荷ペース / 在庫週数）と、定期おトク便（SnS）の実績データ
必要なデータ・接続	接続済みアカウントの在庫データと定期おトク便の実績データ（追加設定は不要）
実行範囲	大半が分析・提案のみ（読み取り専用）。実際の発注・納品プランの作成は Seller Central で手動で行い、Picaro から発注が実行されることはありません。ただし在庫を踏まえた広告調整（プロンプト 4）だけは、提案を関連ページ（入札・予算）の承認フローに渡して実行します。各プロンプトの「設定変更」で個別に示します

取得したデータの読み方について（重要）

• needMoreStocks は補充推奨数・不足数として使いません。 現在の在庫数（sellableInventory）と同値が返るため、補充量の根拠になりません。推奨補充数は reorderQuantitySuggested などツールが返す値を使います。
• 在庫週数・在庫日数（weeksOfCover / daysOfSupply）の「0」は「欠品」とは限りません。 週次出荷が 0 のときも在庫があれば 0 が返るため、「在庫 0 の欠品」「週次出荷 0 で算出不能（滞留・休眠等）」「データ未取得」を必ず区別します。
• 在庫状況を踏まえた広告調整では、在庫データを ASIN 単位に合算してから判定します。 SKU 単位の行のまま判定すると、在庫が十分にある商品の広告を誤って抑制する提案になります（実測で発生）。週次出荷が 0 の商品は「判定不能」として抑制候補から除外し、分母が 0 のケースを「在庫 0 日」として扱いません。

このページで使う言葉

• FBA（フルフィルメント by Amazon） … 在庫を Amazon の倉庫に預け、保管・出荷・カスタマー対応を Amazon が代行する仕組み。
• SKU … 商品を管理する最小単位の識別コード。同じ ASIN でも出品条件ごとに SKU が分かれることがあります。
• 在庫週数 … 今の週次出荷ペースで、販売可能在庫があと何週間もつかの推定値（販売可能在庫 ÷ 週次出荷ペース）。
• 在庫日数 … 在庫週数と同じ考え方を日数で表したもの。
• リードタイム … 発注してから販売可能になるまでの日数。
• セーフティ在庫 … 需要変動や入荷遅延に備えて持っておく余裕分の在庫（日数で指定）。
• 定期おトク便（SnS: Subscribe & Save） … 買い物客が定期購入を登録し、割引価格で定期的に届く Amazon の仕組み。

こんな時に使います

• FBA 在庫の全体像を、在庫週数つきで一目で把握したい
• 在庫切れリスクを診断し、そのまま発注検討に使える補充発注ブリーフをまとめたい
• 過剰在庫・滞留在庫を見つけて、消化施策や出品整理の材料にしたい
• 在庫状況に合わせて広告の強弱（抑制 / 維持 / 強化）を決めたい
• 定期おトク便（SnS）の欠品による機会損失を把握して、補充の優先順位に反映したい

実行前に確認すること

• 接続先のアカウント … 複数アカウントを扱う場合は、対象アカウントが合っているか先に確認します。
• リードタイム・セーフティ在庫・発注サイクル … 在庫切れリスク診断（プロンプト 2）の前提になります。自社の仕入れ・納品の実態に合わせて指定します。
• 過剰在庫のしきい値 … 滞留在庫の判定（プロンプト 3）で使います。既定は「180 日超 = 過剰在庫候補」「270 日超 = 長期保管手数料の警告」で、商材の回転特性に合わせて変更できます。
• 発注は Picaro では実行しません … 補充・発注の実行は Seller Central の納品プラン作成で手動で行います。

プロンプト早見表

やりたいこと	分かること・作られるもの	設定変更	プロンプト
FBA 在庫の全体像を在庫週数つきで確認する	在庫週数つきの在庫一覧	変更なし	プロンプト 1
在庫切れリスクを診断し、補充発注ブリーフを作る	緊急補充 / 発注候補 / 監視 / 判定不能の区分表と、過剰在庫一覧つきの発注ブリーフ	変更なし（ドラフトのみ）	プロンプト 2
過剰在庫・滞留在庫を見つける	過剰在庫 / 長期保管警告の一覧	変更なし	プロンプト 3
在庫状況を踏まえて広告の強弱を決める	抑制 / 維持 / 強化の推奨一覧	変更なし（提案のみ。実行は入札・予算カテゴリ経由）	プロンプト 4
定期おトク便の欠品による機会損失を把握する	在庫切れ未配送と悪化商品の一覧	変更なし	プロンプト 5

このページは分析・提案が中心

早見表のとおり、このページのプロンプトは在庫の確認・リスク判定・ブリーフ作成までで、Picaro から発注が実行されることはありません（発注は Seller Central の納品プラン作成で手動）。在庫を踏まえた広告調整（プロンプト 4）だけは、提案を 入札単価を調整する / 予算を調整する の承認フローに渡して実行します。在庫切れ時に広告を自動停止する機構はありません。

---

プロンプト 1: FBA 在庫の全体像を在庫週数つきで確認する

FBA 在庫を一覧で確認します。販売可能在庫だけでなく、入荷作業中の在庫・週次の出荷ペース・在庫週数（今のペースであと何週間もつか）まで並べて、全体像を把握します。

こんな時に使う — 在庫の全体像を、在庫週数つきで一目で把握したいとき。

実行前に必要な情報 — なし（そのまま使えます）。在庫週数の閾値（既定は 2 週）を変えたい場合は指定します。

目的: 在庫切れリスクの早期発見のため、{{アカウント名（例: Torani）}}のFBA在庫全体を可視化する。

【取得】get_fba_inventory を account_id 指定で呼び、pagination.totalPages 分すべてのページを取得する。返却行数と pagination.totalRecords を突き合わせ、一致しない場合は明記すること（page_size は指定しても100に固定されることがある）。レスポンスの coveragePeriod と dataCreateDate を必ず冒頭に記載する（在庫週数の分母である週次出荷の集計期間なので、期間を書かずに在庫週数だけを示さないこと）。

【ASIN単位に集約】同一ASINが複数行返ることがある（SKU単位の行だが応答にSKU列が無いため行とSKUを対応付けられない）。必ずASIN単位に集約してから判定する。
- 販売可能在庫・入荷作業中在庫は ASIN 内で合算する
- 週次出荷（weeklyShipmentUnits）は同一ASINの各行に同じ値が入るASIN単位の値なので、合算せず代表値を1つ採る
- 集約後の在庫週数 =（ASIN合計の販売可能在庫）÷（週次出荷）で再計算し、MCPが行単位で返す weeksOfCover は参考値として併記する
※集約せず行単位で判定すると、在庫0のSKU行だけを見て「欠品」と誤判定する（実際にはASIN合計で十分な在庫があることがある）。

【在庫週数0の扱い — 必須】weeksOfCover=0 には意味の異なるものが混在する。0を一律に「在庫切れ間近」と扱ってはいけない。次の3区分に必ず分けて出力する。
A. 要対応（在庫切れリスク）… 週次出荷 > 0 かつ 集約後在庫週数 < {{閾値（例: 2週）}}。ASIN合計在庫が0なら「完全欠品」と明記する
B. 算出不能（分母0）… 週次出荷 = 0。在庫週数は「算出不能」と書き、0と書かない。さらに
   B-1 在庫あり・出荷0 → 滞留（過剰在庫側の論点。プロンプト 3〈過剰在庫・滞留在庫を特定する〉へ回す）
   B-2 在庫0・出荷0 → 休眠 / 廃番 / 未出品の候補
C. 健全 … 集約後在庫週数 >= {{閾値（例: 2週）}}
「在庫0（欠品）」「販売実績0」「在庫データ未取得」を必ず区別し、混同しないこと。

【出力】A区分を先頭に、集約後在庫週数の昇順で、ASIN・商品名・販売可能在庫・入荷作業中在庫・週次出荷ペース・集約後在庫週数・区分を表で並べる。B区分・C区分は件数と代表例を示す。
注意: 販売可能在庫（sellableInventory）は入荷作業中在庫を含んだ合計値なので、在庫週数は入荷予定を織り込んだ値である旨を明記する。
注意: get_fba_inventory の応答にSKU列は無い。SKUが必要な場合のみ lookup_sku_for_asin で補完し、補完できないASINは「SKU未登録」、行とSKUの対応は付けられないため「SKU非表示（API仕様）」と注記する。
注意: needMoreStocks は補充推奨数として使わないこと（在庫数と同値が返るため補充量の根拠にならない）。

最後に次の3点を出力してください。
1. 推奨アクション — A区分の優先度・理由・想定リスク（欠品・機会損失）を明記する。優先度は在庫週数の少ない順を基本としつつ、週次出荷ペースが小さいASINは欠品しても影響が小さいため、在庫週数と出荷ペースの両方で重み付けする
2. 実行方法 — A区分のASINはプロンプト 2（FBA 在庫リスク診断）に渡して補充数を確認する。B-1区分はプロンプト 3（過剰在庫・滞留在庫を特定する）へ回す
3. 測定 — {{評価日（例: 7日後）}}に在庫週数を再取得し、A区分の件数の増減を確認する

A区分が0件のときも「該当0件」と明記し、実績0と断定する前にB区分の件数とデータ取得状況（totalRecords・coveragePeriod）を確認してください。

変更できる条件 — 在庫週数の閾値（例: 2 週）／再確認する評価日（例: 7 日後）。

返ってくる内容 — 要対応 → 算出不能 → 健全の順に並んだ、ASIN × 商品名 × 販売可能在庫 × 入荷作業中在庫 × 週次出荷ペース × 集約後の在庫週数の表。在庫週数は「販売可能在庫 ÷ 週次出荷ペース」の推定値で、入荷予定を織り込んだ値です。週次出荷が 0 の ASIN は「算出不能」として区別され、在庫週数を 0 とは表示しません。SKU は既定では表示されず、必要な場合のみ個別に補完します。

設定変更 — 変更なし（読み取り専用）。

次にすること — 要対応区分の ASIN は、プロンプト 2 で在庫切れリスクを診断します。在庫はあるが出荷が止まっている（B-1 区分）ものは、プロンプト 3 で過剰在庫・滞留在庫として確認します。

---

プロンプト 2: FBA 在庫リスク診断（在庫切れリスク・推奨補充数）

ASIN 別の在庫切れリスク・推奨補充数・過剰在庫を 1 回でまとめて診断し、そのまま発注判断に使える補充発注ブリーフを作成します。欠品による売上機会損失と、過剰発注によるコストの両方を防ぐために使います。

こんな時に使う — 在庫切れリスクを診断し、そのまま発注検討に使える補充発注ブリーフをまとめたいとき。

実行前に必要な情報 — リードタイム（発注してから販売可能になるまでの日数。例では 14 日）、セーフティ在庫日数（需要変動や入荷遅延への備え。例では 7 日）、発注サイクル日数（例では 14 日）。過剰在庫のしきい値や発注ロット最小単位（例: 100 個）を添えると、判定と発注可否の精度が上がります。

目的：欠品による売上機会損失と過剰発注コストの両方を防ぐため、{{アカウント名（例: Torani）}}のFBA在庫からASIN別の在庫切れリスク・推奨補充数・過剰在庫を1回で診断し、そのまま発注判断に使える補充発注ブリーフを作成してください。

【この診断の位置づけ】
- Business Objective … 欠品による売上機会損失と過剰発注コストの両方を防ぎ、適正な補充発注を行う。
- User Decision … 今回の発注サイクルで「どのASINを・何個」発注するかを決める（発注しないASIN・保留するASINも理由付きで明示する）。
- Expected Outcome … 発注対象ASINと推奨補充数の一覧、発注を保留するASINとその理由、過剰在庫側の注意ASINが、追加の問い合わせなしに1回で揃っている状態。
- Guardrail KPI … 過剰在庫コスト／発注ロット効率。保管手数料・長期在庫保管手数料の金額はPicaro MCPから取得できないため、在庫日数・しきい値超過日数・ltsfRisk（warning/watch）での代替監視とし、金額換算は行わない。

【取得】次の2本を account_id 指定で呼ぶ。
1. detect_restock_needs（lead_time_days={{リードタイム日数（例: 14）}}／safety_stock_days={{セーフティ在庫日数（例: 7）}}／reorder_cycle_days={{発注サイクル日数（例: 14）}}／max_pages=10／include_low_confidence=true）
2. detect_overstock（同一 account_id／max_pages=10。しきい値は既定のまま、または {{過剰在庫しきい値日数（例: 180）}} を指定）
generate_restock_brief は使わないでください。critical / reorder / monitor は detect_restock_needs、overstock は detect_overstock と同一のデータを返す一方で、総件数フィールド（totalSkusEvaluated 相当）と idle の明細配列（idleItems）を返さないため、下記の件数検算と休眠SKUの分離ができなくなります。
include_low_confidence=true は必須です。false にすると idle が summary からも消え、区分件数の合計と totalSkusEvaluated が一致しなくなり、除外件数も示されません。
応答の thresholds が指定値と一致しているかを確認し、両ツールの totalSkusEvaluated と get_fba_inventory の pagination.totalRecords を突き合わせて全件評価できているかを冒頭に明記してください。salesDateRange（週次出荷の集計期間）と inventoryCreatedAt（在庫スナップショット日）も冒頭に書いてください。

【ASIN単位に集約 — 必須】detect_restock_needs は SKU 単位の行を返しますが応答に SKU 列が無く、同一ASINが複数行・複数区分に同時に現れます（在庫0の行が critical、在庫のある行が monitor に入る）。判定前に必ずASIN単位へ集約してください。
- sellableInventory・inboundWorkingQuantity は ASIN 内で合算する
- weeklyShipmentUnits・reorderPointUnits・targetStockUnits は同一ASINの各行に同じ値が入るASIN単位の値なので、合算せず代表値を1つ採る
- 集約後の推奨補充数 = max(0, targetStockUnits −（ASIN合計 sellableInventory ＋ ASIN合計 inboundWorkingQuantity））で再計算する
- 集約後の在庫切れまでの日数 =（ASIN合計 sellableInventory ÷ weeklyShipmentUnits）× 7 で再計算し、行単位の daysUntilStockout は参考値として併記する
- 集約の結果、緊急補充・発注候補から外れたASINは「同一ASINの別行に在庫あり・発注不要」として除外し、除外した件数と数量を必ず明記する
※集約せず行単位で扱うと、在庫0のSKU行だけを見て「緊急補充」と誤判定し、実際には十分な在庫があるASINに過剰発注します（検証時の実測で、緊急補充5件中2件が誤検知・約14,000個相当の過剰発注になりました）。

【0 と null の区別 — 必須】weeksOfCover / daysOfSupply は週次出荷が0のとき在庫があっても 0 を返すため、「0」を次の3つに必ず分解してください。
- 区分A 在庫0の欠品 … sellableInventory = 0。実際の欠品。緊急補充の対象
- 区分B 週次出荷0で算出不能 … weeklyShipmentUnits = 0（daysUntilStockout は null で返る）。在庫があっても 0 が返るだけで欠品ではない。滞留・休眠・終売として Idle に置き、「在庫切れまで0日」と書かない
- 区分C 健全 … 在庫・出荷ともにあり在庫日数が算出できている
weeksOfCover / daysOfSupply を在庫切れの根拠に単独で使わないでください。
needMoreStocks は使わないでください（検証した全SKUで sellableInventory と同値であり、補充推奨数ではありません）。推奨補充数は reorderQuantitySuggested（ASIN集約時は上記式で再計算した値）を使ってください。
「在庫0（完全欠品）」「販売実績0（算出不能）」「データ未取得」を必ず区別してください。

【区分】detect_restock_needs の classification を一次の区分とし、ASIN集約の結果 Critical の条件を満たさなくなったASINは Monitor へ降格してください。日数だけで再分類しないこと（Reorder は「在庫日数は残っているが販売可能在庫＋入荷作業中在庫が目標在庫を下回る」ケースを含み、日数閾値で切ると発注候補を取りこぼします）。
- 🔴 緊急補充（critical）… 販売可能在庫が発注点以下で入荷作業中在庫が無い／在庫日数がリードタイム以下
- 🟡 発注候補（reorder）… 販売可能在庫＋入荷作業中在庫が目標在庫を下回る
- 🟢 監視（monitor）… 目標在庫を満たしている
- ⚪ 判定不能・休眠（idle）… 直近出荷が無く判定不能（confidence=low・上記の区分B）
過剰在庫（detect_overstock）は補充分類と直交する別軸です。上記4区分とは合算せず別テーブルで示し、区分件数の単純合計は重複を含む旨を添えてください。

【SKUの特定】🔴と🟡の各ASINについて lookup_sku_for_asin でSKUを引き、SKU列に併記してください。
1つのASINに**複数の異なる**SKUが返る場合、各SKUの sellableInventory にはASIN合計が入りSKU別に分離できないため、「SKU特定不可・要在庫管理画面確認」と明記し、そのSKUの発注数を確定させないでください。同一SKU名が parentAsin 違いで重複して返るだけの場合（重複排除すると1件になる場合）は「特定不可」に該当しません。重複排除してから判定してください。

【出力】まず補充側を区分別テーブルで示し、次に過剰在庫を別テーブルで示してください。
- 補充側の列 … 商品名・ASIN・SKU（特定できた場合のみ）・集約後の在庫切れまでの日数・販売可能在庫・入荷作業中在庫・週次出荷数・推奨補充数・confidence・判定理由
- 過剰在庫側の列 … 商品名・ASIN・在庫日数・しきい値超過日数・販売可能在庫・ltsfRisk（warning/watch）
ASIN集約で区分が変わったものは「集約前 Critical → 集約後 Monitor（SKU行分割による誤検知）」と注記してください。

【発注ブリーフ】上記のテーブルに続けて、次の5段で要約してください。
1. What happened — 緊急補充・発注候補・過剰在庫の各件数と規模。ASIN集約後の値と集約前の生件数の両方を示す
2. Why — 欠品／過剰の要因。ただし販売データは直近1週間のスナップショットのみで時系列が無いため、出荷ペース変化・季節性は判定できません。判定不能である旨を明記し、推測で断定しないでください
3. So what — 放置した場合の欠品リスクと過剰在庫リスク。金額換算は行わず、在庫日数・しきい値超過日数・ltsfRisk までを示してください
4. What was done — 前回ブリーフ以降に実施した発注。発注履歴を返すMCPツールは存在しないため、利用者からの提供がなければ「利用者入力待ち」と明記してください（「なし」と断定しないこと）
5. What should we do next — 今回発注すべきASINとその優先度

【データ品質】次を必ず守り、検算結果を出力必須項目としてください。
- 各区分の件数の合計（critical＋reorder＋monitor＋idle）が totalSkusEvaluated と一致するかを検算し、一致しない場合は差分件数と理由（週次出荷が min_weekly_units 未満のSKUは既定で除外される／include_low_confidence の指定など）を明記する
- totalSkusEvaluated と get_fba_inventory の totalRecords が一致しない場合、または max_pages で打ち切られた場合は、総件数・確認済み件数・未確認件数を明記する（[N of M rows omitted] があれば「⚠️全X件中Y件のみ取得済み」と冒頭に明記）
- 未取得SKUは表に含めず「残りN件は未取得」と別途注記し、「同様に緊急」等の推測断定をしない（未取得は「未取得のため不明」と明記）
- 集計値（totals over N rows）からの個別ASIN・個別SKU値の逆算・捏造は禁止。取得済みの行のみ記載する

回答末尾に、使用した前提条件（リードタイム・セーフティ在庫・発注サイクル・過剰在庫しきい値、在庫スナップショット日と販売実績期間）と、PicaroのデータがFBA在庫管理画面の表示値と完全一致しない旨・最終確認は同画面で行う旨を明記してください。

最後に次の3点を出力してください。
1. 推奨アクション — 緊急補充・発注候補のうち推奨補充数が {{発注ロット最小単位（例: 100個。発注ロット・MOQ・ケース入数はPicaro MCPのどの応答にも存在しないため利用者が指定する）}} 以上のものを「今回の発注サイクルで発注すべきASIN」として、在庫切れまでの日数の昇順・推奨補充数の降順で示す。発注ロット最小単位が未指定の場合は「未指定のため発注可否は判定しない」と明記し、発注単位への丸めは行わず（「発注単位は要利用者確認」と明記）、推奨補充数の一覧のみを示す。SKUが一意に特定できなかったASINは「要SKU確認」として別掲し、発注数を確定させない
2. 実行方法 — 一覧をそのまま発注根拠として渡す（Picaro内に発注実行導線は無いため手動発注）
3. 測定 — {{評価日（例: 7日後）}}に detect_restock_needs を同じ前提条件で再取得し、緊急補充と判定したASINが critical から外れたか（新たな在庫切れが発生していないか）を確認する。weeksOfCover / daysOfSupply による回復判定は行わない（週次出荷が0に落ちた場合も0を返し、回復と誤認するため）。回復していなければ発注遅延を疑い調査する

変更できる条件 — リードタイム（例: 14 日）／セーフティ在庫日数（例: 7 日）／発注サイクル日数（例: 14 日）／過剰在庫しきい値／発注ロット最小単位。自社の仕入れ・納品の実態に合わせて変えてください。

返ってくる内容 — 区分（🔴緊急補充 / 🟡発注候補 / 🟢監視 / ⚪判定不能・休眠）× ASIN × SKU（特定できた場合のみ）× 在庫切れまでの日数 × 販売可能在庫 × 入荷作業中在庫 × 週次出荷数 × 推奨補充数の表、別テーブルの過剰在庫一覧、そして What happened / Why / So what / What was done / What should we do next の5段構成の補充発注ブリーフ。ドラフト生成のみで、実際の発注や外部への送信は行いません。

設定変更 — 分析・提案のみ（ドラフト生成のみ）。発注は実行されません。

次にすること — 発注の実行は Seller Central の納品プラン作成で行ってください。過剰在庫側をさらに深掘りする場合はプロンプト 3（過剰在庫・滞留在庫を特定する）を使います。

---

プロンプト 3: 過剰在庫・滞留在庫を特定する

推定在庫日数がしきい値を超える SKU を過剰在庫候補として検出します。滞留が長い在庫は保管手数料の負担が増えるため、値引き・広告強化・出品整理などの判断材料になります。

こんな時に使う — 滞留している在庫を見つけて、消化施策や出品整理の材料にしたいとき。

実行前に必要な情報 — なし（そのまま使えます）。しきい値は既定で「180 日超 = 過剰在庫候補」「270 日超 = 長期保管手数料の警告」です。

目的：長期保管手数料の発生と在庫コストの無駄を防ぐため、{{アカウント名（例: Torani）}}のFBA在庫から「過剰在庫」と「滞留在庫」を別々に特定してください。この2つは別概念です（過剰在庫＝量が多すぎる／滞留在庫＝動きが無い）。

【取得】
1. detect_overstock を account_id 指定で呼ぶ（overstock_threshold_days={{過剰在庫しきい値日数（例: 180）}}／ltsf_warning_days={{長期保管手数料警告日数（例: 270）}}／max_pages=10）。
2. get_fba_inventory を同じ account_id で page_size=500 を指定して呼び、応答の pagination.totalPages を見て全ページ取得する。page_size はサーバ側で押さえられ（100 で返ることがある）、指定値がそのまま使われるとは限らないので、件数の判定は常に pagination.totalRecords と totalPages で行う。
応答の thresholds が指定値と一致しているかを確認し、detect_overstock の totalSkusEvaluated と get_fba_inventory の pagination.totalRecords を突き合わせて全件評価できているかを冒頭に明記する。

【観測期間の明記 — 必須】salesDateRange（週次出荷の集計期間）と inventoryCreatedAt を冒頭に必ず書く。salesDateRange は現状7日間しか返らず、期間を指定するパラメータは存在しない。季節性のあるSKUでは単週の出荷実績からの外挿が歪む旨を明記すること。あわせて get_data_ingestion_status で salesDateRange の各日の取込状況を確認する。ただし日単位の rollup_status は確定判定に使わないこと。未出稿の広告タイプが1つでもあると、他の全レポートが completed でもその日全体が no_data に落ちる。reports[] をレポート単位で開き、在庫・売上に関係するレポートが completed かで判定し、未確定日が含まれる場合はその旨を明記する。

【過剰在庫の判定】detect_overstock の出力を使う。
- 長期保管手数料リスク … ltsfRisk="warning"（推定在庫日数が {{長期保管手数料警告日数}} 超）
- 監視継続 … ltsfRisk="watch"（{{過剰在庫しきい値日数}} 〜 {{長期保管手数料警告日数}}）

【滞留在庫の判定 — 必須・detect_overstock では取得できない】
detect_overstock は週次出荷が0のSKUで daysOfSupply に null ではなく 0 を返すため、しきい値を必ず下回り、ゼロ回転SKUを構造上1件も返さない。min_weekly_units=0 を指定しても結果は変わらない。したがって滞留在庫は get_fba_inventory の全行から自分で抽出すること。
- 滞留在庫 … weeklyShipmentUnits=0 かつ warehouseQuantity>0（在庫を抱えたまま動いていない）
- 取扱終了相当 … weeklyShipmentUnits=0 かつ warehouseQuantity=0（滞留在庫に数えない）

【0 と null の区別 — 必須】
- daysOfSupply / weeksOfCover の 0 は「在庫0の欠品」と「週次出荷0で算出不能（＝滞留）」の両方で返る。必ず warehouseQuantity を併読して分解し、どちらであるかを明示する。「在庫日数0日」と書かない。
- needMoreStocks は sellableInventory と同値が返るため、推奨補充数・不足数として使わない。
- 「該当0件」「評価対象外（出荷実績が無く算出不能）」「データ未取得」を必ず区別して書く。評価対象外のSKU数は detect_overstock が返さないため、get_fba_inventory から数えて明記する。

【ASIN重複の扱い — 必須】get_fba_inventory は SKU 単位の行を返すが応答にSKU列が無く、同一ASINが複数行に現れる。件数を報告する際は行数（SKU数）とASIN数を区別して書く。SKU名が必要な場合は lookup_sku_for_asin で逆引きを試みるが、Picaro の SKU マスタに登録が無い ASIN ではエラーになる。逆引きできなかった ASIN は「SKU不明」として扱い、推測でSKU名を埋めない。また返る sellableInventory は各SKUにASIN合計値が入るため、SKU横断で合算すると二重計上する。合算しないこと。

【指標の限界 — 必須】推定在庫日数（daysOfSupply）は現在の在庫を現在の販売速度で消化するのに要する前向きの日数であり、長期保管手数料の課金根拠である在庫の保管日齢ではない。MCPに在庫日齢・aged在庫バケット・長期保管手数料の実額を返すフィールドは存在しない。本結果は代理指標であり、実額の確認は Seller Central の在庫健全性ダッシュボードで行う旨を回答末尾に明記すること。

【出力】過剰在庫（長期保管手数料リスク／監視継続）と滞留在庫を別テーブルで、商品名・ASIN・推定在庫日数・週次出荷数・販売可能在庫・入荷作業中在庫・判定理由を明記してください。

最後に次の3点を出力してください。
1. 推奨アクション — {{長期保管手数料警告日数}}超のSKUは「販促・値下げまたは広告強化による在庫消化」、{{過剰在庫しきい値日数}}〜{{長期保管手数料警告日数}}は「監視継続」、滞留在庫は「返送・廃棄または値下げ処分の検討」として、保有数量の降順に優先度付きで示す
2. 実行方法 — 広告強化が必要なSKUは「原因診断」でROASを確認したうえで、入札調整の提案を作成し、ユーザーが確認・承認したうえで反映する。値下げ・返送・廃棄はPicaro内に実行導線が無いため手動実施と明記する
3. 測定 — {{評価日（例: 30日後）}}に同一パラメータで再検出し、ltsfRisk="warning"のSKU数と、週次出荷0かつ在庫ありのASIN数が減少したかを確認する。あわせて在庫消化施策で欠品させていないかを detect_restock_needs の classificationSummary.critical の件数で確認する（欠品率そのものはPicaro MCPから取得できないためSeller Centralで確認する。critical 件数は欠品率の代理指標である旨を明記する）

変更できる条件 — 過剰在庫・長期保管警告のしきい値（例: 180 日 / 270 日）／再検出の評価日（例: 30 日後）。商材の回転特性に合わせて変更できます。

返ってくる内容 — 過剰在庫（長期保管手数料リスク / 監視継続）の表と、滞留在庫（出荷が止まったまま在庫が残っている商品）の表を、商品名・ASIN・推定在庫日数・週次出荷数・販売可能在庫・入荷作業中在庫・判定理由つきで別々に返します。過剰在庫（量が多すぎる）と滞留在庫（動きが無い）は別概念として扱われます。

設定変更 — 分析・提案のみ（読み取り専用）。

次にすること — 広告での消化（広告強化・値引き）を検討する場合は 入札単価を調整する と組み合わせます。

---

プロンプト 4: 在庫状況を踏まえた広告調整を検討する

在庫切れリスクのある ASIN に広告費を投下し続けると、欠品と同時に広告効率が悪化します。逆に在庫に余裕がある ASIN は広告を強化する余地があります。在庫と広告実績を突き合わせて、調整候補を提案します。

こんな時に使う — 在庫状況に合わせて広告の強弱（抑制 / 維持 / 強化）を決めたいとき。

実行前に必要な情報 — なし（そのまま使えます）。在庫リスク判定のリードタイム・セーフティ在庫日数や、強化検討の ROAS 下限を変えたい場合は指定します。

目的：在庫切れ中の広告費浪費を防ぎつつ、在庫に余裕がある商品の売上機会を最大化するため、
{{アカウント名（例: Torani）}}の在庫切れリスク ASIN を特定し、その ASIN の広告実績と並べてください。

【在庫側の取得 — ASIN 単位への集約が必須】
1. 在庫リスクを detect_restock_needs（lead_time_days={{リードタイム日数（例: 14）}}／
   safety_stock_days={{セーフティ在庫日数（例: 7）}}／max_pages=10／include_low_confidence=true）で取得する。
   総件数（totalSkusEvaluated）・区分別件数・在庫スナップショット日・週次出荷の集計期間を冒頭に明記する。
2. 本ツールは SKU 単位の行を返し、同一 ASIN が複数行・複数区分に同時に現れる（在庫0の行が緊急補充、
   在庫のある行が監視に入る）。判定前に必ず ASIN 単位へ集約してください。
   - sellableInventory ・ inboundWorkingQuantity は ASIN 内で合算する
   - 集約後に緊急補充の条件を満たさなくなった ASIN は監視へ降格し、除外した件数を明記する
   - 集約せず行単位で扱うと、在庫0の SKU 行だけを見て「緊急補充」と誤判定し、
     実際には十分な在庫がある主力商品の広告を抑制する逆提案になる。これは実測で発生している
3. weeklyShipmentUnits = 0 の行は「判定不能（滞留・休眠・終売）」として抑制候補から除外し、別掲する。
   weeksOfCover / daysOfSupply は週次出荷が0のとき在庫があっても 0 を返すので、
   これを在庫切れの根拠に単独で使わないでください。「在庫0の欠品」「週次出荷0で算出不能」
   「データ未取得」を必ず区別してください。
4. needMoreStocks は使わないでください（sellableInventory と同値であり補充推奨数ではない）。

【広告側の取得 — ASIN 軸で取る】
5. 対象ASINごとに、そのASINに帰属する広告実績を ASIN 軸で取得してください。
   call_picaro_api で POST /product-analysis/product-detail/ad
   （body: amazon_account_id, from_date, to_date, code=対象ASIN, type="asin"）を呼ぶと、
   そのASINの広告費・広告売上・ROAS・ACoS・CVR・CPC がキャンペーン別の内訳と合計で返ります。
   - total ブロックの ads_spend / ads_sales / roas / acos を ASIN 単位の値として使う
   - items[] の campaign_id / campaign_name / campaign_type で、そのASINを掲載しているキャンペーンを特定する
   - ads_sales_same_sku（同一SKU由来の売上）と ads_sales（ハロ含む）を区別して示す
   - pagination.total_count と items 件数を照合し、全件取得できているかを明記する
   - 期間は get_data_ingestion_status で確認した確定日までとし、当日は含めない
6. 広告費が発生していないASINは「広告実績なし」と書き、0 と取得不可を区別してください。
7. ROAS・ACoS は上記の返却値をそのまま使い、自分で再計算しないでください。
   キャンペーン別内訳の合計が total と一致するかを検算し、一致しない場合は差分を明記してください。

【Guardrails】在庫データと広告データの取得方法を明記し、途中で切り替えた場合はその旨を開示してください。
書き込み系ツール（入札・予算変更）は一切呼び出さないでください。

最後に次の3点を出力してください。
1. 推奨アクション — ASIN 集約後に緊急補充・発注候補に該当し、かつ広告費が発生している ASIN を
   「抑制検討」として、在庫切れまでの日数の昇順で示す。在庫切れ中に使われている広告費を
   金額で示し、日割りで月額換算した浪費規模も併記する。
   監視区分かつ ROAS が {{強化ROAS下限（例: 2.0）}}以上の ASIN を「強化検討」として示す。
   該当がなければ「該当なし」と明記する。判定不能（週次出荷0）の ASIN は抑制候補に入れず別掲する
2. 実行方法 — 抑制・強化の対象キャンペーンは手順5 の items[] の campaign_id で特定できる。
   対象ASINと対象キャンペーンを併記して、提案内容をユーザーが確認・承認したうえで入札を調整する。
   ただし1キャンペーンが複数ASINを掲載している場合、そのキャンペーンを抑制すると他ASINにも
   影響するため、影響範囲を明記して人の判断を仰ぐこと。キャンペーン単位でなく
   ターゲット単位で押さえたい場合は、その旨を申し送る
3. 測定 — 在庫回復後{{評価日（例: 7日後）}}に detect_restock_needs を同じ前提条件で再取得し、
   抑制対象 ASIN が緊急補充から外れたかを確認する。あわせて同じ ASIN 軸の広告実績を再取得し、
   ROAS と広告売上で強化提案が有効だったか確認する。weeksOfCover / daysOfSupply による回復判定は行わない

変更できる条件 — リードタイム日数（例: 14 日）／セーフティ在庫日数（例: 7 日）／強化検討の ROAS 下限（例: 2.0）／再確認の評価日（例: 7 日後）。

返ってくる内容 — 抑制検討 ASIN（在庫切れまでの日数の昇順、在庫切れ中に使われている広告費と月額換算した浪費規模つき）と強化検討 ASIN（監視区分かつ ROAS が下限以上）を分けた一覧、対象キャンペーン（campaign_id）、判定不能（週次出荷 0）の別掲リスト。在庫切れによる広告の自動停止機構はないため、欠品が近い ASIN の広告は必ず人の判断で調整します。

設定変更 — このページでは分析・提案のみ（広告設定は変更しません）。実際の調整は 入札単価を調整する / 予算を調整する の承認フロー（分析 → 承認 → 実行）で行います。

次にすること — 抑制・強化を実行するときは 入札単価を調整する / 予算を調整する の承認フローを使います。

---

プロンプト 5: 定期おトク便の欠品による機会損失を把握する

定期おトク便（SnS: Subscribe & Save）は、在庫切れが起きると登録済みの定期便が未配送になり、売上機会の損失が直接発生します。商品別の「在庫切れによる未配送」を確認し、補充優先順位の判断材料にします。

こんな時に使う — 定期おトク便の欠品による機会損失を把握して、補充の優先順位に反映したいとき。

実行前に必要な情報 — なし（そのまま使えます）。直近期間と比較する前期間は、重複しない同じ長さの期間を明示的に指定します（省略すると主期間と重複した範囲が自動的に導出されるため）。

目的: 定期おトク便（SnS）の欠品による売上機会損失を早期に把握し、在庫補充の優先順位付けに使うため、{{アカウント名}} の定期おトク便の商品別実績と在庫状況を取得してください。

【指標の定義 — 先に確認すること】
list_sns_products が返す not_delivered_due_to_oos は「件数」ではなく「率（%）」です（例: "0.0%" / "88.9%" / "--"）。
未配送の件数・欠品日数・想定需要に相当するフィールドは、SnS系・在庫系のどのツールにも存在しません。
したがって機会損失を金額や件数に換算してはいけません。率で順位づけし、規模は出荷数と売上で併記してください。
率の分母は仕様に記載がないため、件数を逆算して提示しないでください。

【取得手順】
1. 直近の完了週のみで {{直近期間}} を指定し、list_sns_products を
   sort_key=not_delivered_due_to_oos / sort_order=desc / frequency=weekly で取得する。
   ※ frequency=monthly は当月が未取込のまま 0 で返るため使わないこと。
2. 同じ長さで重複しない {{前期間}} を明示的に指定し、同じ条件でもう一度取得する。
   not_delivered_due_to_oos には *_compare フィールドが無いため、1回の呼び出しでは期間比較できません。
   また比較期間を省略すると主期間と重複した範囲が自動導出されるので、必ず明示指定してください。
3. 同一ASINが複数SKU行で重複して返ることがあるため、ASINで名寄せしてから集計・順位づけする。
4. 上位候補について get_fba_inventory を呼び、sellableInventory / weeklyShipmentUnits /
   weeksOfCover を併記する。

【値の解釈ルール — 厳守】
・not_delivered_due_to_oos が "0.0%" は「欠品起因の未配送なし」、"--" は「算出不能（当該期間の出荷が0、
  またはSnSオファーが INELIGIBLE / SUSPENDED）」です。"--" を 0 と同一視しないでください。
・"--" の商品の出荷減はオファー終了が原因である可能性が高く、欠品と断定しないでください。
・get_fba_inventory の weeksOfCover / daysOfSupply は、weeklyShipmentUnits が 0 のとき
  在庫が残っていても 0 を返します。weeklyShipmentUnits=0 の行では weeksOfCover を「算出不能」として扱い、
  欠品シグナルに使わないでください。
・null / 未取得 / 0 を必ず区別して表記してください。

【データ品質の開示ルール — 最重要】
① 取得件数と product_count を冒頭に明示し、省略マーカーがある場合は総件数・確認済み件数・未確認件数を示す。
② 表に記載する行はツール結果に実在する行のみとし、省略行のASIN・商品名・数値を推測・想像で作らない
   （1行でも創作した場合はデータ不正使用として扱います）。
③ 確認済み件数が全件より少ない場合は、ランキングが確認済み範囲内でのみ成立すると明記する。
④ 因果関係（例: 欠品が原因で出荷が減った）は not_delivered_due_to_oos が正の値の場合のみ主張する。
   0.0% または "--" の場合は因果を断定しない。

【出力】
・直近期間 / 前期間それぞれの、率が非ゼロの商品を降順に並べた表（ASIN・商品名・欠品率・出荷数・SnS売上・
  SnS単価・在庫週数）。両期間に存在する商品は率の差分（%ポイント）を付す。
・率が高くても出荷数が {{最低出荷数しきい値（例: 50）}} 未満の商品は「規模が小さく補充優先度は低い」と注記する。
・非ゼロが0件の場合は「直近期間に欠品起因の未配送は検出されなかった」と明記し、無理に順位表を作らない。
・機会損失を金額換算していない理由（未配送件数・欠品期間・想定需要がMCPから取得できないこと）を1行で添える。

【判断】欠品率が前期間より上昇し、かつ出荷規模が大きい商品を、在庫補充の検討対象として優先度を上げて案内してください。
【Measurement / Follow-up】補充対応後30日で同じ2期間比較を再実行し、not_delivered_due_to_oos の率が低下したかを確認してください（件数ではなく率で比較すること）。

変更できる条件 — 直近期間／前期間／規模の目安とする最低出荷数（例: 50）。

返ってくる内容 — 直近期間・前期間それぞれの、在庫切れによる未配送率（not_delivered_due_to_oos。件数ではなく %）が高い順の表（ASIN・商品名・欠品率・出荷数・SnS 売上・SnS 単価・在庫週数）と、両期間の差分（% ポイント）。定期おトク便に登録がある商品のみが対象です（SnS 実績ベースで、広告経由売上とは別のデータです）。「0.0%」は未配送なし、「—」は算出不能（出荷実績なし、またはオファー終了等）を示し、どちらも「0」と同一視しません。

設定変更 — 分析・提案のみ（読み取り専用）。

次にすること — 補充の優先順位に反映するときは、プロンプト 1（在庫週数つきの全体像）・プロンプト 2（在庫切れリスク診断）と併せて判断します。定期おトク便の分析を深掘りする場合は 定期おトク便（SnS）を分析する を参照してください。

---

関連カテゴリ

• 入札単価を調整する — 在庫を踏まえた入札調整の実行
• 予算を調整する — 在庫を踏まえた予算調整の実行
• ダッシュボードで KPI を確認する — 日次 KPI と在庫アラートの確認
• 定期おトク便（SnS）を分析する — 定期おトク便の実績を深掘りする
• 施策と外部イベントを記録して効果を検証する — 在庫切れを外部イベントとして記録し、KPI 変動の理由を残す
• 広告戦略を立案する（プロンプト 12「悪化した指標の原因を 6 つの要因に切り分ける」） — 広告強化を検討する前の原因診断