2026/10/31
AI活用
Claudeで在庫CSVから滞留在庫の確認表を作る――計算より難しい「判定ルール」を整理する実務手順
対象読者：中級者向け
月末の在庫確認で表計算を開いてから始まる仕事
月末の午後、卸売会社の商品管理担当者が基幹システムから在庫CSVを出力し、表計算ソフトで滞留在庫を確認する場面を考えます。目的は、長期間動いていない商品を見つけ、次回の発注量や販売施策を検討できる確認表を作ることです。担当者は商品コード、商品名、現在庫数、最終出庫日、仕入単価、商品区分などを並べ、滞留日数と確認区分を追加します。
AIを使わない場合でも、すべてを手作業で処理するわけではありません。既存のExcelテンプレート、日付の差を求める数式、商品マスタを参照する関数などを利用している会社は多いでしょう。典型的な流れは、CSVの列を確認し、前月のテンプレートへ転記し、商品コードをキーに区分や担当者を補い、基準日から最終出庫日までの日数を計算するというものです。その後、90日以上、180日以上といった社内基準に沿って分類し、件数や在庫金額を集計します。
この仕事で時間を取られやすいのは、計算式の入力そのものより、データと判定条件のずれを整える工程です。CSVの列名が変わっていれば参照先を直し、日付が空欄の商品があれば原因を調べます。返品、受注生産品、季節商品、販売終了品を一律に滞留扱いしてよいかも判断しなければなりません。商品コードの重複やマスタ未登録が見つかれば、元データへ戻って確認します。
完成物に求められるのは、単に色が付いた一覧ではありません。元の在庫行を追跡できること、判定理由が分かること、区分別の合計が元データと一致することが品質条件になります。Claudeを使う場合も、この入力、成果物、品質条件は変えません。変更するのは、列の点検、日数計算、条件別分類、集計表の下書きをまとめて依頼できる点です。発注を止めるか、値引きするか、在庫を維持するかという業務判断は、引き続き担当者が担います。
滞留日数より先に決める判定ルール
滞留在庫表を作る前に、社内で使う言葉をデータ上の条件へ置き換える必要があります。「しばらく売れていない商品」という表現だけでは、同じCSVから複数の答えが生まれます。最終出庫日から90日経過した商品を対象にするのか、入庫日や受注日を見るのかで結果が変わるためです。基準日を実行日任せにすると、同じファイルを翌日に処理しただけでも境界の商品が別区分へ移ります。
この記事では、架空の社内ルールとして、基準日を2026年10月31日に固定し、現在庫数が1以上の商品だけを確認対象にします。最終出庫日から基準日までが90日未満なら通常、90日以上180日未満なら滞留候補、180日以上なら重点確認とします。最終出庫日が空欄の場合は日数を推測せず、要確認へ分けます。未来の日付、負の在庫数、商品コードの欠落も計算対象にせず、データ不備として扱う設計です。これは実在企業の基準ではなく、手順を試すための例示です。実務では自社の会計方針、商品特性、発注周期に置き換えてください。
例外条件も先に言語化しておきます。季節商品は次の販売期まで保有する可能性があり、受注生産品は通常在庫と同じ回転基準で評価できない場合があります。販売終了品は重点確認の対象になりやすいものの、保守部品として保持する契約があれば処分できません。このため、日数による機械的な区分とは別に、例外フラグと確認メモの列を設けます。
判定ルールを文章にする作業は省略できません。Claudeへ曖昧なまま判断を委ねると、もっともらしい基準を補ってしまう可能性があるからです。担当者が決めるべきなのは、基準日、対象在庫、日数の境界、空欄の扱い、例外区分です。Claudeには、その決定済みルールを全行へ一貫して適用し、矛盾や不足を指摘する役割を持たせます。この分担が、確認可能な成果物を作る土台になります。
Claudeでまとめられる工程と人に残す判断
Claudeの公式案内では、CSVやTSVなどをアップロードしてデータ分析や可視化に利用でき、Excel形式のファイルも作成できます。複数ファイルを一つの会話で扱うことも案内されています（出典: Anthropic Support）。そのため、在庫CSVの点検、滞留日数の計算、条件別分類、区分別集計、確認用Excelの作成を一連の依頼として組み立てられます。
ただし、Claudeへファイルを渡せば発注判断まで自動的に正しく決まるわけではありません。適した使い方は、定義済みのルールに従って確認表の下書きを作り、異常値と不明点を人へ返すことです。同じ在庫CSV、同じ基準日、同じ分類条件、同じ出力列を使って従来手順と比較すると、何が変わったのかを捉えやすくなります。
| 工程 | AIを使わない場合 | Claudeを使う場合 | 人が担当すること |
| --- | --- | --- | --- |
| 列の確認 | CSVを開いて列名や型を目視する | 列一覧、空欄、日付異常、重複候補を整理させる | 異常の原因と修正可否を判断する |
| 日数計算 | 数式を追加して全行へ反映する | 固定した基準日と計算規則を全行へ適用させる | 境界日の扱いを確認する |
| 条件別分類 | 関数やフィルターで区分を付ける | 指定した条件で区分と判定理由を付けさせる | 例外商品の区分を決める |
| 集計 | ピボット表や集計式を作る | 区分別の件数、数量、在庫金額をまとめさせる | 経営判断に使う集計軸を選ぶ |
| 確認表作成 | 列幅や見出しを整えて保存する | 指定構成のExcelを作らせる | 元データとの一致を検証して承認する |
省略しやすいのは、同じ規則を繰り返し適用する操作です。列ごとの点検結果を別紙へ転記したり、区分ごとにフィルターして件数を数えたりする工程も、一つの依頼にまとめられます。反対に、ルールの妥当性、空欄の業務上の意味、商品を処分できるかといった判断はまとめられません。
中級者向けの実践では、最初から完成表を一度で要求せず、データ点検、ルール確認、ファイル作成、修正という複数段階に分けます。チャットの基本操作に加え、CSVの列の意味と自社の集計ルールを説明できれば取り組めます。コードや開発環境の操作は必要ありません。
アップロード前に整えるファイルと安全条件
用意する中心ファイルは在庫CSVです。商品コード、商品名、現在庫数、最終出庫日、仕入単価、商品区分、担当部門が含まれていると、確認表を作りやすくなります。商品区分や例外情報が別管理なら、商品コードを共通キーにした商品マスタCSVも用意します。どの列が税込みか、在庫数の単位が個数かケース数かなど、ファイルだけでは判断できない情報は短いデータ説明書へまとめておくとよいでしょう。
架空の在庫CSVは、次のような構成を想定します。実在する顧客名、仕入先名、担当者の個人情報は含めません。
| 商品コード | 商品名 | 現在庫数 | 最終出庫日 | 仕入単価 | 商品区分 |
| --- | --- | --- | --- | --- | --- |
| P-101 | 保存容器A | 24 | 2026-09-18 | 480 | 通常商品 |
| P-205 | 卓上扇風機B | 12 | 2026-05-02 | 3200 | 季節商品 |
| P-310 | 交換部品C | 8 | 空欄 | 1250 | 保守部品 |
Claudeでファイルを作成・編集する機能は、利用環境の設定や組織管理者の方針によって有効化状況が異なります。公式案内では、CSVなどの分析とExcelファイルの作成に対応し、アップロードとダウンロードは1ファイル当たり最大30MBと説明されています（出典: Anthropic Support）。作業を始める前に、自分の環境でファイル作成機能を利用できるか、会社の規程上どのデータを外部AIへ渡せるかを確認してください。
入力データは必要な列に絞ります。滞留判定に不要な顧客情報、仕入先の連絡先、自由記述の社内メモなどは削除または匿名化します。商品コードも外部共有できない場合は、検証用の仮コードへ置き換え、結果を社内で対応付ける方法が考えられます。これはClaudeの操作ではなく、利用企業側で決める情報管理手順です。
外部から受け取ったファイルには、AIへ不適切な操作を促す文言が紛れ込む可能性もあります。公式資料も、外部ファイルやWebサイトを介した指示によって情報が意図しない相手へ送られるリスクを挙げ、予期しないデータ利用やアクセスがないか監視するよう勧めています（出典: Anthropic Support）。在庫分析では外部アクセスを必要としないため、組織で選択できるならネットワーク接続を抑えた環境から検討し、アップロード後の動作も担当者が確認します。
点検、分類、Excel作成を4段階で依頼する手順
対象ファイルをClaudeの新しい会話へ追加したら、いきなり滞留在庫表を作らせず、データの点検から始めます。ここで使う「お願い文」は、一般にプロンプトと呼ばれる指示文です。以下は架空データで試すための提案例であり、列名と社内ルールは実際のファイルに合わせて置き換えてください。
第1段階では、計算を行わず、ファイルの状態だけを報告させます。列名、行数、空欄、重複、日付として解釈できない値、負の在庫数などを確認します。
コピーして使うお願い文:
添付した在庫CSVを読み、まだ滞留判定やファイル作成は行わないでください。
最初に次の点を確認してください。
・列名と各列の意味の推定
・総行数と商品コードの重複候補
・現在庫数、最終出庫日、仕入単価の空欄や不正な値
・基準日より未来の最終出庫日
・判断に必要だが不足している情報
推定した内容と、私に確認すべき質問を分けて示してください。
不明な値を補完しないでください。
第2段階では、Claudeから返された質問に答えながら、分類ルールを確定します。基準日、対象行、90日と180日の境界、空欄の扱い、季節商品などの例外を明記します。Claudeには、作業前にルールを箇条書きで復唱させます。復唱内容が社内基準と違えば、この段階で直せるため、完成後の手戻りを抑えやすくなります。
第3段階で確認表を作らせます。公式資料ではClaudeがExcelファイルを作成できると案内されていますが、シート名や列構成は次のお願い文で指定する提案例です（出典: Anthropic Support）。
コピーして使うお願い文:
確認した在庫CSVを、次の架空ルールで処理してください。
基準日は2026年10月31日です。
現在庫数が1以上の行だけを確認対象にしてください。
最終出庫日からの経過日数が90日未満は通常、
90日以上180日未満は滞留候補、180日以上は重点確認とします。
最終出庫日が空欄なら日数を推測せず要確認としてください。
未来日、負の在庫数、商品コード欠落はデータ不備へ分けてください。
季節商品と保守部品には例外確認フラグを付け、日数による区分は残してください。
元データの列を保持したまま、経過日数、判定区分、判定理由、例外確認、担当者メモの列を追加してください。
Excel形式で、滞留在庫一覧、区分別集計、確認メモの3シートを作成してください。
区分別集計には件数、在庫数量、現在庫数と仕入単価から計算した在庫金額を含めてください。
処理件数、除外件数、データ不備件数も確認メモへ記録してください。
外部サイトへのアクセスや不足値の推測は行わないでください。
返ってくる一覧の内容は、たとえば次の形になります。数値と判定は架空の例です。
| 商品コード | 経過日数 | 判定区分 | 判定理由 | 例外確認 |
| --- | --- | --- | --- | --- |
| P-101 | 43 | 通常 | 90日未満 | なし |
| P-205 | 182 | 重点確認 | 180日以上 | 季節商品 |
| P-310 | 空欄 | 要確認 | 最終出庫日が空欄 | 保守部品 |
第4段階では、誤りを自分で直接直すだけでなく、修正理由を伝えて再作成させます。「90日ちょうどの商品が通常に入っているため、90日以上を滞留候補に直してください」「在庫金額に空欄単価の商品を含めず、別件数として表示してください」のように、対象、問題、正しい条件を一緒に示すと確認しやすくなります。
元データとの突合と例外商品の承認
Claudeが作ったExcelは、意思決定に使う前の確認表です。見た目が整っていても、元データと一致しているとは限りません。担当者は、処理対象の件数、個別行の計算、区分別集計、例外商品の扱いを順に確認します。ここを省くと、前工程で減らした転記作業が、誤発注や必要在庫の処分という別の手戻りへ変わりかねません。
確認は次の観点に分けると進めやすくなります。
- 元CSVで現在庫数が1以上の行数と、確認表の対象行数および除外行数の合計が一致するか確認します。
- 90日と180日の境界付近、最終出庫日が空欄の商品、未来日などを選び、基準日からの日数と区分を手計算または既存の表計算式で照合します。
- 区分別の在庫数量と在庫金額を合計し、一覧側の合計と集計シートが一致するか確かめます。単価空欄をゼロとして扱ったのか、集計から除外したのかも見ます。
- 季節商品、保守部品、受注生産品、販売終了品を業務担当者へ回し、機械的な日数区分とは別に対応方針を承認します。
件数が少ない場合は全件を突合できます。件数が多い場合でも、重点確認、データ不備、例外フラグの行は優先して確認し、通常区分からも無作為に選んで元データと照らす方法が考えられます。抽出確認だけで十分かどうかは、在庫金額、監査要件、誤判定時の影響に応じて会社側が決める必要があります。
発注見直しでは、滞留日数だけを根拠にしません。未出荷の受注残、次期キャンペーン、最低発注数量、仕入先との契約、保守義務などを確認します。Claudeには「重点確認の商品を在庫金額順に並べ、担当者が記入する確認欄を追加する」といった整理を依頼できますが、発注停止や廃棄の承認は担当者と責任者が行います。
修正が発生したら、Excelだけを直接直して終わらせず、元CSVの問題、判定ルールの不足、Claudeの適用誤りのどれかを記録します。ルールの不足なら次回のお願い文へ反映し、元データの問題なら基幹システム側の修正担当へ戻します。この記録がなければ、翌月も同じ例外を一から調べることになるでしょう。
効率化を工程別に測る小さな試行
Claude導入の効果は、完成までの所要時間だけでは判断しにくいものです。ファイルの匿名化、ルールの説明、出力の突合、修正依頼にも手間がかかるため、それらを除外すると実態より有利な比較になります。従来手順とClaudeを使う手順で、同程度の行数と同じ品質条件を設定し、工程ごとの作業を記録します。
記録する項目は、準備、データ点検、計算と分類、集計表作成、突合、修正、承認までの各工程です。時間に加えて、判定条件の確認回数、元データへ戻った件数、分類の修正件数、未解決の例外件数も残します。Claudeで下書きが速く作れても、修正件数が増えたなら、お願い文か入力データを見直す必要があります。反対に、所要時間の差が小さくても、空欄や未来日を早い段階で一覧化できたなら、点検工程では意味のある変化があったと評価できます。
| 確認する工程 | 記録する内容 | 見直しの手掛かり |
| --- | --- | --- |
| 入力準備 | 削除した列、匿名化、ルール整理の手間 | 毎回同じ準備なら説明書を定型化する |
| データ点検 | 空欄、重複、不正日付の検出件数 | 見逃しや誤検出を元CSVと照合する |
| 分類と集計 | 完成までの修正回数 | 境界条件と例外条件を具体化する |
| 人の確認 | 突合件数、差異、承認保留 | 高リスク区分の確認範囲を調整する |
| 次の判断 | 発注見直し候補と未決事項 | AIの分類と業務判断を混同しない |
定例化を検討するのは、同じ列構成と判定ルールで複数回処理し、差異の原因を説明できるようになってからです。CSVの形式が毎月変わる、担当部門ごとに滞留の定義が違う、例外商品の比率が高いといった状況では、完全な定型化より、データ点検と確認表の下書きだけをClaudeへ任せる方が扱いやすい場合もあります。
最初の試行では、本番データ全体を渡す必要はありません。個人情報や社外秘を除いた架空データ、または社内規程に沿って加工した少数行のCSVを用意し、90日と180日の境界、日付空欄、季節商品の行を含めます。点検、ルール復唱、Excel作成、元データとの突合までを一度通し、どの工程で修正が生じたかを記録してください。その記録をもとに、自社では列点検だけに使うのか、集計表の下書きまで任せるのかを決めることが、無理のない導入の一歩になります。