第1回では「何を作るか」を要求仕様として決め、要求仕様書を配りました。今回はいよいよ、この道具の心臓部——在庫切れを予測する計算（コア）を作ります。画面はまだ作りません。計算だけです。使うのは、第1回で触れたコア設計仕様書と、実装役のClaude Codeです。
1. 今回作る「コア」とは
第1回で、計算の中身（コア）と画面（UI）は分けて設計する、と決めました。今回作るのはそのコアだけ。3つのCSV（在庫リスト・製造計画・配合表）を受け取り、計算して、「発注すべき品目」を返す部分です。人が触る画面は次回（第3回）です。
コアの中でデータはこう流れます。
製造計画 × 配合表 → 原材料の予定消費量 → 現在庫から日々引く → 在庫切れ予定日 → 緊急度（危険・注意） → 推奨発注数
コアとなる部分の作成が難しいのであれば、Web Claudeを使って自然言語でロジックを作成してください。そのときに必ず、第1回で作った要求仕様書を渡してあげてください。何故がわかれば、AIはどうやって何を作ればいいのかがわかります。AIに相談しながらコア設計仕様書を作ってください。
2. コアの中身 ── 4つの計算（コア設計）
コアは、4つの計算に分かれます。順に見ていきます。
予定消費量の関数
製造計画の「ロット数」と、配合表の「1ロットあたり使用量」を掛けて、原材料ごと・日付ごとに足し合わせます。同じ強力粉でも、食パンとクロワッサンの両方から消費が積み上がる——この足し合わせが、Excelの目視では破綻する部分で、コアの核心です。
実装予定のコード例
def planned_usage(plan, recipe):
# (日付, 品目コード) → その日の使用予定量 を積み上げる
# 使用量 = ロット数 × 1ロットあたり使用量
usage = {}
for row in plan:
for r in recipe:
if r["product_code"] == row["product_code"]:
key = (row["date"], r["item_code"])
usage[key] = usage.get(key, 0) + row["lots"] * r["usage_per_lot"]在庫切れ予定日のロジック
現在庫から、①で出した日々の予定消費を順に引いていき、初めて在庫が0以下になった日を在庫切れ予定日とします。残り日数も、起点日との差で出します。
緊急度の関数
残り日数が「危険閾値」以下なら危険、「注意閾値」以下なら注意、それ以外は色なし。閾値は現場ごとに変えられる数字にしておきます。
実装予定のコード例
def risk_label(days_left, DANGER_DAYS, WARN_DAYS):
if days_left is None:
return "" # 期間内に在庫切れにならない
if days_left <= DANGER_DAYS:
return "危険" # 行を赤
if days_left <= WARN_DAYS:
return "注意" # 行を黄
return "" # 色なし推奨発注数のロジック
計画期間の総消費に安全在庫ぶんを足し、現在庫を引いた「必要量」を、取引先の発注ロット単位に切り上げます。在庫が足りているなら0（過剰発注しない）。
この4つを定義したものが、今回配るコア設計仕様書です。実装に入る前に、ここまでを固めておきます。
砂糖さんう…こんなプログラムが入った仕様書。作ることができない。
MATSUプログラムのロジックが書けなくてもWeb Claudeに相談しながら、「〇〇のときは、こう処理してほしい」と伝えるだけでも作ることができます。大切なのはプログラムではなく処理条件の網羅的な洗い出しになります。プログラム部分はWeb Claudeにまかせて大丈夫。
3. デモデータを見る（入力する3つの表）
計算に通す前に、入力となる3つのデータを見ておきます。今回はパン班（食パン・クロワッサン）のぶんです。単位はkg／L、製造計画はロット（仕込み）単位です。
在庫リスト（原材料）
会社全体の在庫。パン班が使わない原材料も載っています。
| 品名 | 保管 | 現在庫 | 発注ロット | 単位 |
|---|---|---|---|---|
| 強力粉 | 常温 | 850.3 | 25 | kg |
| 薄力粉 | 常温 | 217.0 | 25 | kg |
| グラニュー糖 | 常温 | 291.2 | 25 | kg |
| バター | 冷蔵 | 142.3 | 10 | kg |
| 全卵 | 冷蔵 | 123.7 | 10 | kg |
| 生クリーム35% | 冷蔵 | 51.4 | 12 | L |
| 生クリーム47% | 冷蔵 | 18.8 | 12 | L |
| 生イースト | 冷蔵 | 8.6 | 1 | kg |
| 栗ペースト | 冷蔵 | 72.5 | 5 | kg |
| バニラエッセンス | 常温 | 3.3 | 1 | L |
| チョコレート | 常温 | 20 | 10 | kg |
製造計画
いつ・どの製品を・何ロット作るか。平日と週末で数量が変わります。
| 製造日 | 班 | 製品 | ロット数 |
|---|---|---|---|
| 2026-06-09 | A | 食パン | 5 |
| 2026-06-09 | A | クロワッサン | 4 |
| 2026-06-10 | A | 食パン | 5 |
| 2026-06-10 | A | クロワッサン | 4 |
| … | … | … | … |
| （14日分。金・土は食パン7・クロワッサン6に増える） | |||
配合表
製品を1ロット（1仕込み）作るのに、どの原材料をどれだけ使うか。
| 製品 | 原材料 | 1ロットあたり | 単位 |
|---|---|---|---|
| 食パン | 強力粉 | 10 | kg |
| 食パン | バター | 0.8 | kg |
| 食パン | 生イースト | 0.32 | kg |
| 食パン | グラニュー糖 | 0.6 | kg |
| クロワッサン | 強力粉 | 4.0 | kg |
| クロワッサン | バター | 2.5 | kg |
| クロワッサン | 生イースト | 0.30 | kg |
このうち生イーストは在庫が薄く、計算に通すと最初に危険になります（結果は次の節で）。動作確認に使うこの3つのデータも配っておきます。なお、正常・境界値・異常値を仕込んだ検証用のデータは、第4回（テスト編）で扱います。
デモデータ
上記で説明したデモデータは以下のリンクからダウンロードできます。
4. コア設計仕様書をClaude Codeに渡して実装
Planモードによるコアプログラムの実装
やり方はシンプルです。プロジェクト用のフォルダを作り、シードとして、前回作った要求仕様書、コア設計仕様書とデモCSVを置く。あとはClaude Codeを起動して、こう頼みます。
docsフォルダ内にある要求仕様書、コア設計仕様書、3つのデモデータを参照してください。コア設計仕様書の通り、コアプログラムを実装してください。またデモデータを使って動作確認まで実施してほしい。いきなり全部書かせず、まずPlan mode（段取りだけ先に出させるモード）で「どう作るつもりか」を確認します。仕様と段取りがかみ合っていたら、実装に進ませる。ズレていたら、ここで直す。
砂糖さん仕様書を渡すだけで、ほんとに作れるの？
仕様が具体的なら、かなり作れます。逆に曖昧だと、足りない部分をAIが勝手に埋めてしまう——第1回で話したとおりです。だからこそ、先に仕様書を固めておく。仕様書が具体的であるほど、実装はそのまま通る。これがSDDの効果です。
実際の操作画面
何故、要求仕様書も同時に渡すか
プログラムに関係するコア設計仕様書はhowまたはwhatの部分を担当しています。何故、そのプログラムを作らなければいけないのかを渡せていません。つまり、whyの部分を伝えられていない。planモードで計画をたてるとき、whyがあれば何故の部分をコード生成AIが埋めなくて済むことになり、意図したものができる事が多くなります。
実装したコアプログラムの動作確認
できたコアに、先ほどのデモデータ（パン班のデータ）を通します。結果はこうなりました。
危険日判定が３日以下、注意判定が７日以下の設定で実行しているため、在庫切れまでの日数が11日の強力粉、9日のバターは緊急度が何も表示されていない状態です。続けて「危険日判定が３日以下、注意判定が12日以下」でClaude Codeに依頼した結果がこちらになります。
強力粉とバターの緊急度がちゃんと「注意」に変更されました。判定ロジックそのものは十分機能しているということでした。機能としては十分です。ただ、実際に使うとなると危険、注意の日数を変更して使うケースを想定しなければいけません。今、不便なことに日数の規定値がコードに埋まっている状態です。
危険判定、注意判定の既定値はコード（config.py）の中にあり、コードを変更しないと変えられないという不便さがあります。
この不便さは第6回（発展編）で、外部の設定ファイルから読めるようにして直します。
5. まとめ
- コアは「3つのCSV → 計算 → 発注すべき品目」を返す、計算だけの部品
- 計算は4つ：予定消費量・在庫切れ予定日・緊急度・推奨発注数（＝コア設計仕様書）
- 要求仕様書（why）も一緒に渡すと、AIが意図を踏まえて実装できる
- デモで動作確認：発注対象3件、生イーストが危険（残り3日）。正しさの検証は第4回。閾値の調整は第6回へ。
次回は、このコアに画面（UI）をかぶせて、人が使える道具にします。コアはこのまま一切変えずに、上から画面をつなぐだけ——第1回で「分けておいた」設計が、ここで効いてきます。
使用しているデータ・製品名・取引先名はすべて架空のものです。コードは解説用の実装例で、各ツールの仕様・料金は記事公開時点のものです。
コメント