この記事はバイブコーディングをある程度、経験している人に向けた記事です。バイブコーディングについてまだ経験していない方は以下の記事を参考にしてください。
毎日、在庫を見て、足りない原材料を発注する。地味ですが、切らすと製造が止まる、重い仕事です。これを楽にするツールを自分で作る、というのが今回のテーマです。
この連載では、菓子・パン製造業の発注ツールを題材に、仕様書から作って・動かして・テストするまでを通しでやります。ただ、生成AIに「作って」と頼むだけでは、動くけれど意図とズレた道具になりがち。だからこのシリーズは、コードを書く前に仕様書を書きます。第1回は、その出発点——何を作るかを決める回です。
1. 今回の困りごと（誰のための、何の道具か）
今回の仮想事例は、中小の菓子・パン製造業で、原材料の在庫管理と発注を担当する生産管理の方の悩みです。生産管理部門が、製造部門で使う原材料の在庫を一手に引き受けて、1人で発注を回しています。
今のやり方は「在庫がこの数を割ったら発注する」という発注点だけの管理です。ところが発注点は、製造計画と連動していません。だから、製造が立て込む時期に欠品し、逆に作らない時期は在庫を抱えて廃棄が出る。欠品と廃棄が、同時に起こる。製造現場のあるあるです。
さらに厄介なのが、同じ原材料が複数の製品にまたがって使われることです。たとえば強力粉もバターも、食パンとクロワッサンの両方で使う。すると「強力粉がいつ足りなくなるか」は、複数の製品の製造計画を足し合わせないと分かりません。
この足し合わせを、品目数 × 製造日数のぶんだけExcelで目で追うのは、現実的ではない。見落とせば、欠品か、原材料の廃棄です。
複数の製品をまたいで「この原材料はいつ切れるか」を積み上げる——ここが表計算の苦手な部分で、自分で道具を作る価値があるところです。
2. なぜ「作って」の前に、仕様書を書くのか（SDD）
生成AIに「発注を楽にするツールを作って」と頼めば、それなりのものは出てきます。ただ、生成AIコーディングの黎明期によくあったのは、動くけれどバグだらけで、意図しない動作をして、かえって時間を取られるツールでした。自分で書くより遅くなることさえあった。
原因は、指示の具体性です。AIは、こちらがはっきり指定しなかったところを「だいたいこんな感じだろう」と確率的に埋めてしまう。だから、動くけれど意図とは微妙に違うものが、平気で出来上がる。詳しくは関連コラムをどうぞ。
砂糖さんでも、動いてるなら、後から直せばよくない？
家でたとえると分かりやすいです。ノリとアドリブで建てた家を、後から法律や規格に合わせて直すのは、膨大な費用と時間がかかります。先に設計図を引いて建てれば、それが避けられる。動いているプログラムを途中から直すのも、これと同じです。
先に「何を・どういう判断で作るか」を決めておけば、AIはその通りに作りやすい。その決めたことを書き出したものが、仕様書です。先に仕様（spec）を固めてから作る——この進め方を、プロも使うSpec-Driven Development（仕様書駆動開発、SDD）と言います。
3. 仕様はWeb Claudeと、実装はClaude Codeと
この連載で使うAIは2つあります。役割がはっきり違うので、最初に分けて押さえておきます。
- Web Claude（ブラウザで使うClaude） … 仕様の相談相手。「こういう道具が欲しい」を伝え、抜けや矛盾を一緒に潰しながら、仕様書に落としていく。
- Claude Code … 実装の実行者。出来上がった仕様書を渡すと、コードを書き、テストを走らせてくれる。
仕様書をWeb Claudeと作り、それをClaude Codeに渡して実装する。この2段階に分けることで、コードが書けなくても、自然言語のままSDDが実践できます。
この記事で配る仕様書も、実際にWeb Claudeと相談しながら作りました。やり方そのものを隠さず見せていきます。同じ手順をなぞれば、あなたの現場の道具も同じように作れます。
4. 仕様書は6種類。今回はその出発点「要求仕様書」
仕様書と言っても、1枚ではありません。役割ごとに分けます。可能な限り齟齬を減らすことをテーマに、次の6つに分けました。
- 要求仕様書 … 何を作ってほしいか（業務の言葉で書く）
- システム構成図 … 全体像を1枚の図で（今回は作らない。必要に応じて作る）
- コア設計仕様書 … 判定・計算の中身
- UI設計仕様書 … 画面と操作
- デモデータ＋解説 … 動作確認用の架空データ
- テスト仕様書 … 仕様どおり動くかを確かめる検証項目
なぜ細かく分けるのか。1枚に全部詰め込むと、何を作っているのか見通せなくなるからです。特に、プログラムの核になる計算（コア設計仕様書）と、人が操作する画面（UI設計仕様書）を分けておくと、「作って確かめる」サイクルを小さく回せます。正直に言えば、記事が長くなりすぎるので分けた、という事情もあります（笑）
第1回の今回作るのは、出発点の「要求仕様書」です。中身は、こんな構成になっています。
- 誰が使う
-
生産管理担当者（製造部門全体の原材料発注を1人で担う）
- 入れるもの
-
3つのリスト（在庫リスト・製造計画・配合表）
- 出るもの
-
発注が必要な品目を、在庫切れが近い順に並べたExcel。あわせて画面に、優先順位の表（危険＝赤・注意＝黄）と在庫の推移グラフ
- やらないこと
-
取引先への自動発注や、製造計画そのものの予測（入力された計画は信じて使う）
「3つのリストを入れると、いつ何を発注すべきかが出てくる」。まずはこの一文に集約される道具だと思ってください。
この要求仕様書も、Web Claudeにこう相談しながら作りました（プロンプトは一例です。実際に使ったものに差し替えてください）。
中小の菓子・パン製造業で、生産管理担当が原材料の発注を1人で回しています。
これを楽にするツールを作りたいので、まず「要求仕様書」を一緒に作ってください。
- 業務の言葉で、「誰が使う／何を入力／何を出力／やらないこと」を整理したい。
- 製造計画と在庫を突き合わせ、複数の製品をまたいで「原材料がいつ切れるか」を出すのが核です。
- 私が曖昧なところは決め打ちせず、質問してください。抜けや矛盾も指摘してください。
まずは、確認したい点を箇条書きで挙げてください。詳しい中身は、下のボタンから要求仕様書をダウンロードして確認できます。
5. この連載の進み方
- 第1回（今回）：何を作るか（要求仕様）と、仕様書から作るという考え方
- 第2回：計算の中身（コア）をClaude Codeで実装する
- 第3回：画面（UI）を実装して、コアとつなぐ
- 第4回：テストで「仕様どおり動くか」を確かめる
- 第5回以降（発展）：作ったものを壊さずに拡張する
各回で、設計図（仕様書）を成果物として配ります。コードが読めなくても、どこまで検証された道具なのかが分かるように進めます。
6. まとめ
- AIに「作って」と言うだけだと、動くけれど意図とズレたものができやすい
- だから、コードを書く前に仕様書を書く（SDD）。仕様書はAIへの正確な指示書
- 仕様はWeb Claudeと、実装はClaude Codeと、役割を分ける
- 今回はその出発点「要求仕様書」を配布。次回から、これをもとに作っていく
次回は、この要求仕様をもとに、複数の製品をまたいで「原材料がいつ切れるか」を予測する計算——この道具の心臓部であるコアを、Claude Codeで実際に作っていきます。
使用しているデータ・製品名・取引先名はすべて架空のものです。実在の企業・原材料供給網とは関係ありません。仕様・画面は解説用で、料金や各ツールの仕様は記事公開時点のものです。
コメント