Claudeで課題を構造化する手順:長い資料から原因を洗い出す
この記事の要点
Claudeで課題を整理するときは、棚卸し報告書や運用マニュアルをプロジェクトに登録し、資料の食い違いから原因の候補を出させます。店舗と倉庫の在庫差異を例に、掘り下げの止め方と着手する課題の絞り方を、プロンプト例つきで解説します。
結論
在庫が合わないという状態は、入出庫のどこかで記録と現物がずれた結果で、原因は工程ごとに別々に存在します。Claudeには棚卸し報告書や運用マニュアル、システムの操作手順書といった長い資料をプロジェクトに登録できるので、資料の中の食い違いから原因の候補を先に拾わせ、そこに現場の話を足していく順番が向いています。掘り下げは差異の伝票を1枚たどれる粒度で止め、着手する1つは自部門で止められるかどうかを軸に選びます。
在庫差異は「原因を挙げてください」では割れない
「在庫が合わない。原因を挙げてください」と頼むと、検品漏れ、入力ミス、誤出荷、返品処理の遅れ、盗難といった項目が並びます。在庫管理の教科書に載っている一覧と同じもので、自社のどれが起きているかは分かりません。
在庫差異には他の課題にはない性質があります。差異は必ず記録として残ることです。棚卸しの差異一覧、システムの入出庫履歴、店舗からの修正依頼。原因を推測する前に、すでにある記録が何を語っているかを読ませるほうが早く進みます。
| 進まない頼み方 | 材料になる頼み方 |
|---|---|
| 在庫差異の原因を挙げてください | 登録した資料から、差異が発生しうる工程を順に並べてください |
| 対策を提案してください | 対策の前に、各工程で記録に残る痕跡を列挙してください |
| 課題を構造化してください | 大分類を4つ以内で出し、そこで止めてください |
| どこから手をつけるべきですか | 判断に使う軸の候補を5つ出してください |
この記事では、衣料品を扱う小売チェーンを例にします。直営が40店舗、物流センターが1か所、システム上の在庫と実地棚卸しの数が合わない店舗が増えていて、業務改善を担当する本部の社員が原因を整理し、半期の施策を1つ決めるところまでを想定します。
全体の流れは6つです。
- 資料をプロジェクトに登録し、読み違いを潰す
- 工程の順に大分類を出させ、そこで止める
- 選んだ工程だけを2階層下ろす
- 重なりと抜けを点検する
- 記録で確かめられる原因と、聞き取りが要る原因を分ける
- 評価軸を作り、着手する1つを選ぶ
資料をプロジェクトに登録し、読み違いを先に潰す
この種の案件では、手元に別々の部署が作った文書が集まります。棚卸しの実施要領、差異一覧、店舗向けの入出庫マニュアル、システムの操作手順書、物流センターの作業指示書。案件ごとのプロジェクトに登録しておくと、会話を分けても同じ資料を見たまま続きから作業できます。
登録したら、原因を頼む前に読み違いを潰します。
このプロジェクトに登録した資料を確認してください。
この段階では原因を書かないでください。
次を教えてください。
1. 登録されている資料の一覧。作成年と、何のための文書かを一行ずつ
2. 商品が仕入れ先から届いて店頭に並び、売れるか返品されるまでの流れ。
どの作業をどの部署が行い、どこでシステムに数量を入力するかを含めて
3. 同じ作業について、資料の間で手順や責任者の記述が食い違っている箇所
4. 資料に出てくるが意味が説明されていない社内用語の一覧
5. 資料からは読み取れなかった作業と、埋めるために誰に聞くべきか
各項目について、根拠にした資料名と該当する見出しを併記してください。
推測で書いた箇所は、推測だと明記してください。
3番目の食い違いが、そのまま原因の候補になります。棚卸し実施要領には「差異は当日中にシステムへ反映する」とあるのに、店舗向けマニュアルには「翌週の締めまでに本部へ報告」と書かれている。この種のずれは現場に聞いても出てきません。両方を読んだ人がいないからです。
プランや時期によって使える機能が異なるため、最新の仕様は公式情報で確認してください。資料に取引先名や社員名が含まれる場合の扱いは、自社の生成AI利用ルールに従います。原因の切り分けには固有名詞は不要なので、記号に置き換えてから登録すれば足ります。
手順1:工程の順に大分類を出させ、そこで止める
在庫差異は工程で切るのが扱いやすく、対策の担当部署もそのまま決まります。
在庫差異の原因を整理します。この段階では下位の原因を書かないでください。
【条件】
・登録した資料から読み取った業務の流れに沿って、大分類を5つ以内で並べる
・大分類は部署の名前ではなく、数量が動く工程の名前にする
・各大分類について、そこで差異が生じた場合に
どの記録にどんな痕跡が残るはずかを1行で書く
・痕跡が残らない工程があれば、それを明記する
・資料に根拠がある記述と、一般的な在庫管理の知識から補った記述を
それぞれ区別して示す
私が「次へ」と書くまで、下の階層に進まないでください。
痕跡を書かせる条件が、あとの検証で効きます。入荷検品で差異が出たなら仕入伝票と入荷実績の数量が食い違うはずで、店頭での紛失なら記録は何も残らないはずです。この違いをはじめに書かせておくと、記録で追える工程と追えない工程が分かれます。
痕跡が残らない工程を明記させるのも外せません。ここが対策の設計に直結します。記録が残らないなら、原因を特定しようとするより、記録が残る仕組みを先に入れるほうが早いからです。
手順2:選んだ工程だけを2階層下ろす
5つの工程を同時に展開させると出力が膨らみ、どれが実態に近いか判断できなくなります。差異の多い工程から1つずつ頼みます。
「店舗での入荷検品」の大分類だけを掘り下げてください。
他の大分類にはまだ触れないでください。
【条件】
・下に2階層だけ展開する。3階層目には進まない
・第3階層は、差異の伝票を1枚選んだときに
それが当てはまるかどうかを判定できる粒度まで下ろす
・各項目の末尾に、確かめ方を1つ書く。
確かめ方は「どの記録を突き合わせるか」または「誰に聞くか」にする
・登録した資料に根拠がある項目には資料名を、
資料にない項目には頭に「仮」と付ける
返ってくるのは、たとえばこういう形です。
店舗での入荷検品
├─ 検品の数量と実際の数量がずれる
│ ├─ 箱単位で受け取り、中身を開けずに数量を確定している
│ │ 確かめ方: 入荷実績の登録時刻と、開梱の記録を突き合わせる
│ └─ 仮 繁忙日は検品を後回しにし、記憶で入力している
│ 確かめ方: 差異の発生日と店舗の売上の高い日を重ねる
└─ 検品したが、システムへの反映が遅れる
├─ 入荷登録が店長の端末でしかできず、不在日は翌日以降になる
│ 確かめ方: 入荷日と登録日の差を店舗別に集計する
└─ 仮 一部店舗が紙で控えてからまとめて入力している
確かめ方: 差異の多い5店舗の店長に手順を聞く
手順3:重なりと抜けを点検する
工程で切ると、同じ事象が2つの工程にまたがって書かれることがあります。全体を書き直させず、指摘だけを出させます。
いま出ている課題ツリーを点検してください。
【点検する内容】
1. 実質的に同じことを言っている項目の組。どちらに寄せるかの案も出す
2. 2つの工程にまたがっていて、どちらに置くか決まっていない項目
3. 原因ではなく結果を書いている項目。たとえば「管理が甘い」など
4. 工程で切ったために視野に入らない原因。あれば別枠で挙げる
5. 登録した資料の記述と矛盾している項目
【条件】
・指摘は7点以内に絞り、影響の大きい順に並べる
・各指摘について、直した形を該当部分だけ書く
・ツリー全体を書き直さない
5番目が、資料を登録している利点です。現場の印象で書いた項目が、マニュアルの記述と矛盾していることがあります。矛盾はどちらかが間違っているという意味ではなく、たいていは規定と運用がずれている証拠なので、それ自体が原因の候補になります。
4番目では、工程の外側にある原因が挙がります。システムの仕様、商品マスタの重複、値引きや返品の処理区分、店舗の人員配置。今回の範囲に入れるかは人が決め、外したものも別の見出しで残します。
具体例1:差異一覧を読ませ、記録で追える原因だけを残す
ここまでに出たのは可能性の一覧です。差異一覧を読ませ、記録で追えるかどうかを判定させます。
プロジェクトに登録した差異一覧を確認してください。
店舗コードと商品コードは記号に置き換えてあります。
いま出ている原因の候補それぞれについて、判定してください。
【出力】
表にしてください。列は次の5つです。
原因の候補 / この差異一覧で追えるか / 突き合わせる記録と集計の仕方 /
結果がどうなっていれば原因として支持されるか / 追えない場合に必要なもの
【区分】
A. この差異一覧だけで追える
B. 入出庫履歴など別の記録と突き合わせれば追える。必要な記録名も書く
C. 記録が残らないため、聞き取りか現地確認でしか確かめられない
D. 今の仕組みでは確かめる方法がない
【条件】
・Cに入れた項目を、無理にAやBへ寄せない
・この段階では集計を実行せず、判定の表だけを返す
・列の意味が分からないときは推測で埋めずに質問する
区分Dに落ちる項目が、在庫差異では必ず出ます。店頭での紛失、売場での破損の未報告、レジ通過時の数量誤り。これらは追跡の記録がないので、原因の特定に時間をかけても答えが出ません。Dに入った時点で、対策の方向が「原因を突き止める」から「記録を残す仕組みを足す」に変わります。この切り替えが早いほど、無駄な調査を省けます。
区分AとBは集計させます。集計の進め方そのものは、購買・調達のデータ集計・分析をAIで行う手順に詳しく書いています。区分Cは聞く相手ごとにまとめ、差異の多い店舗を回るときに一度で聞ける形にします。
支持されなかった原因は消さずに残します。「入荷登録の遅れは全店舗で平均1日以内で、差異の多い店舗と相関しなかった」という記録は、同じ議論が蒸し返されたときに効きます。
掘り下げをどこで止めるか
止める目安を決めておくと、際限なく伸ばさずに済みます。
| ツリーの状態 | 判断 |
|---|---|
| 差異の伝票を1枚選び、当てはまるか判定できる | 底。止める |
| 直す対象がシステムの画面名や帳票名で指せる | 止める |
| 次に割ると「意識が低い」「教育が足りない」になる | その手前で止める |
| 確かめ方の欄が空のまま2階層続いている | 掘らずに、確かめ方を先に探す |
3行目は在庫の現場で頻出します。人の性質に行き着いた枝からは対策が作れないので、ひとつ上に戻して言い換えます。
いまの第3階層のうち、次の項目について確認します。
・店舗の在庫管理への意識が低い
・検品作業が丁寧でない
これらを、作業の設計や記録の仕組みの言葉に言い換えてください。
【条件】
・1項目につき言い換えの案を3つ出す
・言い換えた結果が、何を作れば着手できる状態かを1行で書く
・言い換えても本部の手に負えないと判断した場合は、そう書いて理由を述べる
返ってくるのは、検品の完了を端末で記録していない、開梱と数量確定が同じ画面で完結しない、といった形です。ここまで下りると、対策が作業手順とシステムの話になり、半期の施策として設計できます。
具体例2:成果物を別画面に出し、着手する1つを絞る
会話の中でツリーを扱うと、修正のたびに全体が出力し直され、差分が追えなくなります。Claudeには成果物を別画面に出す機能があり、ツリーをそこに置くと本体が1つ残り、枝ごとに直せます。差異一覧の集計結果が出るたびに、該当する枝の確かめ方の欄を検証済みに書き換えていくと、資料がそのまま報告書に育ちます。
別画面のツリーが固まったら、着手する1つを選びます。ここでも採点を先に頼みません。
記録で支持された原因だけを対象に、着手する1つを選ぶ評価軸を作ります。
【手順】
1. まず評価軸の候補を5つ出す。
当社の状況に即した軸にし、一般的な言い方のままにしない
2. 各軸について、高い低いをどう判断するかの目安を書く
3. 私が軸を3つ選ぶまで、採点はしない
【軸に入れてほしい観点】
・本部の業務改善だけで進められるか、システム改修や店舗運営部の合意が要るか
・40店舗すべてに展開する場合の負担
・効果を差異の数字で測れるか
3つ選んで採点させると、上位に残るのはたいてい入荷登録の運用変更のような、店舗の手順だけで完結する施策です。システムの改修は効果が大きく見えますが、予算と開発の順番待ちで半期には収まりません。数店舗で試し、差異が減ったことを示してから改修の要望を出すほうが通ります。
選んだ課題を仕組みの入れ替えで解くと決めたなら、Claudeで要件定義を整理する手順がそのまま次の工程になります。
Claudeが資料から挙げた原因を、事実として扱わないために
長い資料を読ませたあとの出力は、根拠があるように読めます。資料に書かれていないことを一般論で補った箇所が混ざっていても、文章の調子が同じなので見分けがつきません。社内に出す前に3つを踏みます。
項目ごとに、根拠にした資料名と見出しを書かせます。書かせたら、影響の大きい項目から順に、実際にその箇所を開いて読みます。全部を照合する必要はなく、5つも確かめれば、その回の出力がどれくらい資料に忠実かが分かります。
「仮」と付いた項目は、差異の多い店舗の店長に読んでもらいます。読ませるのは原因の一覧ではなく、確かめ方の一覧にします。「入荷登録は誰の端末で、いつ行っているか」と聞くほうが、原因の当否を尋ねるより正確な答えが返ります。
報告書にするときは、記録で確かめた原因、聞き取りで確かめた原因、まだ確かめていない原因を分けて載せます。同じ表に混ぜると、読んだ人は全部が調査済みだと受け取ります。
同じ整理を他のツールで進める手順は、ChatGPTで課題を構造化する手順とGeminiで課題を構造化する手順にまとめています。
うまくいかないときの対処
大分類を頼んだのに第3階層まで書かれる。 「次へと書くまで進まない」という指示は会話が長くなると効きが弱まります。掘り下げを頼む直前に、同じ1行をもう一度書き添えてください。
資料にない手順が書かれている。 「その記述の根拠になった資料名と見出しを示してください。資料にない場合はそう答えてください」と聞き返します。答えられない項目は仮説に移します。
枝が増えて絞れない。 「今回の目的は半期の施策を1つ決めることです。関係しない枝を外し、残す枝を6本以内にしてください」と範囲を狭めます。外した枝は別の会話に退避させます。
項目の粒度がそろわない。 「各項目は、差異の伝票を1枚見たときに当てはまるか判定できる粒度にしてください」と、判定の場面を指定して言い直します。
会話が長くなって条件が崩れる。 確定したツリーをファイルに書き出してプロジェクトに戻し、新しい会話で続きから進めます。
まとめ
棚卸しの差異一覧と、店舗向けの入出庫マニュアル、システムの操作手順書の3点をそろえるところから始めてください。Claudeにプロジェクトを作って登録し、原因を頼む前に資料の食い違いと読み取れなかった作業を出させます。工程の順に大分類を5つ以内で並べ、差異の多い工程を1つだけ2階層下ろし、各項目に確かめ方を書かせて記録で追えるものから集計します。記録が残らない工程は原因の特定をやめ、記録を残す仕組みを作る側に振り替えます。残った原因に軸を3つ当てて採点し、店舗の手順だけで終わる1つを数店舗で試します。
よくある質問
Claudeに棚卸し報告書や運用マニュアルをまとめて読ませて課題を整理できますか?
長い文書を読み込ませて内容を参照させられます。案件ごとのプロジェクトに資料を登録しておけば、会話を分けても同じ資料を見たまま作業を続けられます。読み込める分量や形式はプランと時期によって変わるため、最新の仕様は公式情報で確認してください。
Claudeが資料から挙げた原因は、そのまま会議で共有してよいですか?
共有する前に、項目ごとに資料の何ページのどの記述を根拠にしたかを書かせ、その箇所を自分で開いて確認してください。資料に書かれていない事柄を一般論で補うことがあり、その補いは体裁が整っているぶん見分けにくくなります。根拠のない項目は仮説として別に分けます。
在庫データや取引先名をClaudeに入力してもよいですか?
自社の生成AI利用ルールに従ってください。原因の切り分けには取引先名や社員名は不要で、店舗コード、商品区分、差異の数量と符号、発生日といった列があれば足ります。個人名と取引先名は記号に置き換え、入力してよい範囲を情報システム部門に先に確認するのが確実です。