発注した品物の入荷予定を管理するツールを非エンジニアがClaude Codeで内製する手順｜非エンジニア向け

なぜ発注の入荷予定を内製で管理するのか

売る側の流れには、見積・受注・納品・請求という書類の連なりがあり、どこまで進んだかを後からたどれます。買う側の流れにも、稟議と請求書という両端の記録はあります。しかし、その間をつなぐ一本が通っていません。発注したことは担当者が送ったメールに、いつ届くかは先方からの返信に、届いたかどうかは現場の受け取りメモに、それぞれ別々に残ります。この状態だと、次のようなことが起きます。

• 承認は下りていたのに発注そのものが出されておらず、必要な日の直前に発覚する
• 先方から納期の返事が来ないまま日が過ぎ、こちらも忘れたまま予定日を越える
• 一部だけ届いた分を「入荷済み」として扱ってしまい、残りが誰の視界からも消える
• 届いているのに受け取りの記録が回らず、請求書と突き合わせる段階で止まる
• いつも遅れる発注先があっても、感覚で語られるだけで数字として残らない

ここで扱っているのは「頼んだものが、必要な日までに手元にあるか」という、期限と状態の突き合わせが中心の処理です。件数が多く、日付をまたいで見張り続ける必要があるので、機械に向いています。逆に「どこにいくらで頼むか」「この条件を飲むか」「支払いをどうするか」という判断は、取引の経緯と社内の決裁を知っている人にしかできません。購買や調達のパッケージには当然この機能がありますが、取引先ごとの連携や品目マスタの整備が前提になっていて、全社導入を待っているうちに現場は今日も表計算とメールで回すことになります。まずは届いていないものが見えるだけの身軽な仕組みを先に作れるのが内製の強みです。頼むと決めるまでの承認の流れは稟議・承認フローツールの作り方で扱っています。本記事はその後ろ、承認が下りてから品物が手元に届くまでを扱います。

作るツールの全体像

今回作るのは、頼むと決めたものを一件ずつ残し、手元に届くまで見張る小さなツールです。流れは次のとおりです。

• 依頼の記録：品目・発注先・必要な日・状況を、一件ずつ短く残す
• 起点の前倒し：発注した時点ではなく、頼むと決めた時点で行を作り、発注日や注文番号は後から埋める
• 届かない件の抜き出し：発注の記録がないもの、納期の返事がないもの、予定日を過ぎても届いていないものを出す
• 数量の突き合わせ：頼んだ数と受け取った数を別々に持ち、残りがなくなって初めて完了として扱う
• 発注先ごとの集計：遅れの多い発注先を数え、次に頼むときの材料として残す

この設計でいちばん大事なのは、二つ目です。台帳に行を作るのは、発注書を出した瞬間ではなく、頼むと決めた瞬間にしてください。理由は単純で、このツールで最も見つけたいのは「発注し忘れ」だからです。発注した時点で行を作る作りにすると、発注し忘れた案件は台帳に一行も現れません。一覧が知らせてくれるのは、そこに載っている行のことだけです。載っていないものを抜き出すことはできません。抜けを見張りたいのに、抜けたものだけが台帳に載らない——この矛盾を先に解いておかないと、きれいな一覧を眺めながら、いちばん困る抜けだけを見逃し続けることになります。逆に、最初から項目を増やすのは避けてください。単価・数量・税区分・支払条件・検収区分と並べたくなりますが、それらは書類側に正が置かれるもので、受け取る側の台帳で二重に持つと、更新されないまま食い違います。このツールが引き受けるのは、頼んだものが届くまでを見張るところまでです。届いた後の請求書との突き合わせは請求書照合ツールの作り方、売る側の納期管理は受注案件の納期・進捗管理ツールの作り方と役割を分けておくと、どれも軽いまま続きます。

用意するもの

準備するのは次の3つだけです。特別な開発環境は必要ありません。

• Claude Code：指示を出すと、必要なファイルを自動で作ってくれます。導入手順はClaude Codeのはじめ方を参照してください。
• 直近に出した発注の控え（10件程度で十分）：発注書の写しでも、先方に送ったメールでも、表計算に書いた依頼メモでも構いません。実際に使っているものを渡すことが大事で、整った形になっている必要はありません。
• 状況の段階の案（三つ程度）：たとえば依頼済み・発注済み・入荷済みといった程度の粗さで十分です。細かく分けるのは、しばらく使ってみてから足せば間に合います。

控えを用意するときは、滞りなく届いた件だけでなく、遅れた件・一部だけ届いた件・そもそも出し忘れていた件を必ず混ぜてください。うまくいった件ばかりを見て作ると、途中で止まっている状態を持たない台帳になり、いちばん見つけたかったものが見つからない仕組みが出来上がります。発注先の担当者名や取引条件を含むデータをAIに渡すときの考え方は業務AI利用時の情報漏えい対策で解説しています。社外との取引に関わる情報をどこまで扱ってよいかを先に確認してから進めてください。

Claude Codeへの指示と作成手順

ここからは、実際にClaude Code へ出す指示の流れを順番に見ていきます。専門用語は使わず、ふだんの言葉で頼むのがコツです。

第一段階：頼むと決めたものから記録させる。「頼むと決めたものが、必要な日までに届くかどうかを見張りたい」と目的を伝え、手元の控えを渡します。「品目・発注先・必要な日・状況の4項目を残したい」と項目を伝えたうえで、「発注書を出す前、頼むと決めた段階で行を作れるようにしてほしい」と必ず足してください。ここが本記事でいちばん大事なところです。発注日と注文番号は後から埋める欄として持たせ、空欄のままでも行が作れる形にします。この一手間を入れておくと、承認は下りたのに発注が出ていない件が、そのまま「発注日が空欄の行」として台帳の上に残ります。一覧は必要な日の近い順に並べておくと、差し迫っているものが自然に上に来ます。

第二段階：届いていないものを三つに分けて出させる。「発注すると決めたのに発注の記録がないもの、発注はしたのに納期の返事がないもの、予定していた日を過ぎても届いていないものを、それぞれ分けて出してほしい」と伝えます。三つとも次にやるべきことが違うので、まとめて一つの一覧にせず、分けて出させるのがコツです。一つ目は自社の中でやること、二つ目と三つ目は相手に連絡することです。ここで押さえておきたいのは、返事がないことを「順調」と読まないという点です。発注は出した後こちらの手を離れるので、何も連絡が来ない状態は、順調に進んでいる場合と、先方で止まっている場合の見分けがつきません。だからこそ、静かなまま日が過ぎている件を自動で名指しさせる価値があります。どのくらい過ぎたら出すかは、自社が普段どのくらいで届いているかを見て決めてください。ここに一般的な目安はありません。短くしすぎると毎日大量に並んで誰も見なくなり、長くしすぎると気づいたときには間に合いません。まず粗く決めて、しばらく使ってから直すのが確実です。抜き出しを日々の仕事に乗せるには、確認する人と時間を決めてタスク管理ツールの作り方で作った一覧に載せておいてください。

第三段階：頼んだ数と受け取った数を分けて持たせる。「頼んだ数量と、実際に受け取った数量を別々に記録して、残りがある間は完了にしないでほしい」と伝えます。発注の管理で静かに事故が起きるのはここです。分けて納品されたとき、最初に届いた分で状況を「入荷済み」に変えてしまうと、残りの分は誰の視界からも消えます。数が合わないまま完了になった件を後から掘り起こすのは、忘れた頃に現場から「足りない」と言われてからになります。あわせて「受け取った日を残せるようにしたい」と伝えておくと、後の突き合わせが楽になります。実際に何個あるかという在庫の数そのものは、この台帳では持たないでください。在庫アラートツールの作り方や棚卸しツールの作り方で扱う側と二重に持つと、必ずどちらかが古くなります。この台帳が持つのは「頼んだ分が全部届いたか」だけにして、数の管理はそちらに任せる、という線を引いておくのが長持ちのコツです。

第四段階：発注先ごとに数え、次に頼むときの材料にする。「予定していた日より遅れた件を発注先ごとに数えて、多い順に並べてほしい」と伝えます。一件ずつ見ているうちは、遅れはいつも「今回はたまたま」に見えます。数えて並べて初めて、特定の発注先や特定の品目に偏っていることが分かります。ここで出てくるのは、責める材料ではなく、次に頼むときにどれだけ余裕を見ておくべきかという材料です。発注先を見直す判断に使うなら取引先評価ツールの作り方で扱った評価の側に渡し、価格の動きを追う話は価格モニタリングツールの作り方に任せてください。契約期間や自動更新の管理も別軸なので契約更新管理ツールの作り方に寄せます。完成したら操作の流れをメモに残しておくと、担当が交代しても同じ形で回せます。

つまずきやすい点と回避策

はじめて内製する方が引っかかりやすいポイントを、先回りしてお伝えします。

発注した時点で台帳に載せる作りにしてしまうこと。これが最も多い失敗です。自然に考えると、発注書を出したものが発注の台帳に載るのは当たり前に思えます。しかしその作りにすると、このツールで最も防ぎたい「頼み忘れ」だけが、原理的に検知できなくなります。台帳に載っていないものは、どれだけ賢い抜き出しを組んでも出てきません。頼むと決めた時点で行を作り、発注日が空欄のまま必要な日が近づいている行を毎朝見えるようにしてください。承認の記録から自動で行を作れるなら、なお確実です。「まだ発注していないものを発注台帳に載せるのは気持ちが悪い」と感じるかもしれませんが、この台帳は発注の記録簿ではなく、必要なものが届くかどうかの見張り役だと考えると納得しやすくなります。

発注の可否や条件の判断まで、ツールに決めさせようとすること。どこに頼むか、いくらまでなら出してよいか、支払いの条件をどうするかは、社内の決裁の権限と取引先との契約、これまでの取引の経緯によって決まるもので、台帳の情報だけで導けるものではありません。金額の区切りによって必要な承認が変わる社内規程を持つ会社も多く、そこを自動化すると、承認を経ないまま発注が出る仕組みを作ってしまいます。決裁と取引条件の判断は人と規程が持ち、ツールが引き受けるのは、決まったものが届いたかどうかの見張りまでです。購買部門としての進め方は購買・調達がClaude Codeを使う方法でも触れています。

遅れの集計を、担当者や発注先を責める材料として使うこと。抜き出された件を「なぜ止めているのか」と問い詰める材料に使うと、次からは頼むと決めた段階で台帳に載せなくなります。届いてから、あるいは片付いてから載せる運用に静かに変わり、一覧はいつも空欄なしのきれいな状態で、実際の抜けは変わらず起き続けます。起点を前に倒す設計は、記録が正直に載ることを前提にしているので、この点は使い始める前に共有してください。同じことは品目の書き方にも当てはまります。同じ品物が担当者ごとに違う書き方をされると、発注先ごとの集計も残数の突き合わせも分散して効かなくなるので、よく頼むものは呼び方を決めておくと安定します。表記を揃える考え方は顧客リスト整理ツールの作り方が参考になります。作ったあとも運用は変わっていくので、たまに見直す時間を取ってください。長く使い続ける工夫は内製ツールの保守の進め方で解説しています。

まとめ：届いたかの見張りはツールに、頼むかどうかの判断は人に

本記事の要点を整理します。

• 発注が抜けるのは怠慢だからではなく、承認と請求の間の期間だけ記録が一本通っておらず、届いていないことに気づける場所がないこと
• 作るのは「依頼の記録→届かない件の抜き出し→数量の突き合わせ→発注先ごとの集計」の小さなツール
• 用意するのはClaude Code・直近の発注の控え10件程度・状況の段階の案の3つだけ
• いちばん効くのは台帳の起点を発注時点ではなく「頼むと決めた時点」に置くことで、頼み忘れが空欄の行として見えるようになる
• 頼んだ数と受け取った数は分けて持ち、残りがなくなって初めて完了として扱う
• 発注先・金額・取引条件の判断は人と社内規程と契約が持ち、ツールは届いたかの見張りまで

届いたかどうかの見張りはツールに任せ、どこにいくらで頼むかの判断は人が持つ——この役割分担を押さえれば、発注管理は「使おうとした日に足りないと分かる仕事」から「間に合わない気配が数日前に手元へ出てくる仕組み」へ変わります。まずは直近に出した数件をClaude Code に渡して、頼むと決めた時点で行を作るところから始めてみてください。製造の現場での使い方は製造業がClaude Codeを活用する方法、入出荷の側は物流業がClaude Codeを活用する方法、店舗の仕入の側は小売業がClaude Codeを活用する方法もあわせてご覧ください。研修費用の負担を抑えながら社内に内製できる人を増やす方法は生成AI研修に使える助成金もご確認ください。