AIに「計器の校正期限を管理するツールを作って」と頼めば、それらしいものは返ってきます。でも、動くだけで意図とズレた道具になりがちです。そうならないために、コードを書く前に「何を作るか」を固める——その最初の一歩が要求仕様書です。この記事では、計器の校正期限管理を例に、決まったプロンプト1つで要求仕様書を作るところまでを、実際の手順そのままに見ていきます。
この進め方（プロンプト仕様駆動開発）の全体像は、土台の記事にまとめています。まだの方は先にこちらをどうぞ。
1. どういう困りごとか
今回の仮想事例は、品質保証部で計器の校正管理を担当する方の悩みです。校正対象の計器は約200台。種類も、校正の周期（6・12・24か月）も、依頼先の業者もバラバラ。これを紙とエクセルで、一人で管理しています。
いちばん怖いのは、期限切れの計器をうっかり使ってしまうことです。校正の切れた計器で測った値は信頼できないので、その計器で測ったところまで製品をさかのぼって、妥当性を評価し直す——時間も神経も持っていかれる、重い手戻りが発生します。これを根っこから無くしたい、というのが今回の仮想事例です。
やっかいなのは、運用が宙に浮きやすいこと。計器の校正期限の管理を品質保証部が行っていたとしても、でも実際に計器を使うのは製造部門です。担当が分かれているので、連絡が漏れると事故につながる。しかも業者の点検予約にはリードタイムがあり、期限の直前に気づいても予約が間に合いません。ここで言う点検予約は予約の申し出期間＋点検実施期間＋計器の返却期間を含みます。期限から逆算して、いつ動くべきかを先に知る必要があるわけです。
2. 要求仕様プロンプトで、困りごとを具体的な条件にする
困りごとは見えていても、それを「ツールの条件」に落とすのは、非エンジニアには難しい作業です。そこで使うのが、要求仕様書を作成するためのプロンプトになります。これをWeb版のClaudeに渡して、チャットして質問に回答しながら要求仕様書を作っていく構成です。細かいルール条件など詳細に話すうちに、要求仕様書の内容が固まっていきます。
あなたは、非エンジニアの私から「作りたい道具」の要求を問診で引き出し、
最後に「要求仕様書」まで書き上げる相談相手です。
私はまだ、何をどう書けばいいか分かっていません。あなたの質問に答えるうちに、
要求仕様書に必要な項目が自然に埋まり、そのまま要求仕様書になる——そんな進め方をしてください。
【最終的な成果物】
問診で集めた内容をもとに、下の「要求仕様書の構成」に沿った要求仕様書を出力する。
これが、後の設計・テスト工程に渡す「種」になります。
【問診の進め方】
- 一度に聞くのは1〜2項目まで。私が答えやすいよう、噛み砕いて聞く。
- 専門用語は使わない。私の言葉で返す。
- 私の答えが曖昧・抽象的なときは、具体例や数字を促して掘り下げる。
- 私が機能を欲張りそうなときは、「それは今回やらないことに回せませんか」と提案する。
- 判断に事実が要るとき（業界の相場・実態など）は、調べることを提案する。
- 矛盾や抜けに気づいたら、その場で指摘する。
- 結論を押し付けない。最後に決めるのは私。選択肢と、あなたの推しを添える。
【問診で埋める11項目】
1. 誰のための、何の道具か
2. いま何に困っているか（具体・数字）
3. この道具で何をしたいか（ゴール）
4. なぜ今ある方法では足りないか
5. 何人で使い、画面はどんな方針か
6. 何を渡すか（入力：ファイル形式・項目名・型まで）
7. 何が返ると嬉しいか（出力：形式・見せ方）
8. 判定や計算で使う基準・ルール（数字で決めたいこと）
9. うまくいかない入力（不備）をどう扱うか
10. 今回やらないこと
11. 使う人に持たせたい安心
【要求仕様書を書くとき守ってほしいこと】
- まず最小構成で考える。いま一番困っていることだけを解決し、欲張らない。
- 専門用語を避け、私（非エンジニア）が読める言葉で書く。
- 後の工程（設計・テスト）が、この要求仕様書だけを読んで進められるよう、
入力・出力・判定基準を具体的に書く。
【要求仕様書の構成】
1. このツールは何か
2. 背景と困りごと
3. このツールがやること
4. 入力と出力
5. やらないこと
6. なぜ既存ツールでは足りないか
7. 使う人に持たせる安心
【流れ】
1. まず、確認したいことを1〜2問ずつ聞いて、11項目を埋めていく。
2. 全項目がそろったら、私に一度内容を確認させる。
3. OKが出たら、「要求仕様書の構成」に沿って要求仕様書を出力する。
砂糖さん質問に答えていくだけで、条件が固まっていくんですね。
渡した台帳（デモデータ）の中身
Web Claudeに相談する中で、実際に管理しているエクセルデータを渡すことで具体的なコードの仕様を固めることができます。事前に作成した計器の管理台帳のデモデータを渡して具体性を高めました。台帳は2枚のシートでできています。
| シート1：計器台帳（約200台） | シート2：業者リードタイム |
|---|---|
| 管理番号／計器名／種類 | 業者名 |
| 前回校正日／校正周期(月)／業者 | 予約リードタイム(日) |
| 例：QA-001／温度ロガー01／温度ロガー | A計測サービス=30・B校正センター=45 |
| 例：2024-01-15／12／A計測サービス | C技研=14・社内校正=7 |
またデモデータには、わざと入力不備が2台を混ぜて置きました。データを取り扱う上で整理されていない情報も想定して作るべきだからです。こういう不備のあるデータを持つデータこそ、管理が曖昧になり放置され、事故につながる。あとで「これをどう扱うか」を決めることも設計に組み込みます。
ここからは、実際の要求仕様書を作成する過程をみていきます。Web Claudeとのやり取りで要求仕様書が具体的に固まっていきます。AIに丸投げするのではなく、人が決めて、Claudeが補強する——その様子そのままです。
論点①：校正期限の出し方（月末に丸める）
MATSU校正期限は「前回校正日 ＋ 校正周期」で出したいです。ただ、日ぴったりではなく、その月の末日にしてほしい。たとえば2025年10月1日に校正した周期12か月の計器なら、期限は2026年10月31日、という具合です。
Web Claude承知しました。「(前回校正日＋周期)が入る月の末日」を校正期限とする、ですね。月末に丸めるルールとして固定しておきます。
論点②：データを見ての発見（リードタイム最長45日・不備2台）
Web Claude台帳を読ませていただきました。業者リードタイムの最長がB校正センターの45日であることと、入力不備が2台あることを確認しました。私は「予約は長くて1か月くらい」という感覚でいたので、45日（1か月半）というズレは、ここで初めてはっきりしました。
MATSU不備のある計器はそのままにせず、穴埋めを依頼するように毎回、製造部門に連絡したいです。
論点③：日付ではなく「月」で拾う工夫
MATSUこのツールは月に1回しか動かしません。「今日からX日先まで」で見ると穴が開くんです。自社点検（リードタイム7日）に余裕14日を足しても、7月31日に切れる計器を7月1日に見たら、21日先までしか見ない。月末に切れるものを取りこぼします。
Web Claudeその心配は当たっています。期限そのものではなく、〈動くべき日 ＝ 校正期限 −（リードタイム ＋ 14日）〉を計器ごとに出して、その日が来る月で拾えば、取りこぼしは原理的に起きません。リードタイムの長い業者も前倒しで拾えます。
MATSU余裕の14日は、品質保証部から製造へ連絡して動いてもらう分です。これで確定でお願いします。
論点④：ある月を開いたとき、何を出すか
Web Claudeある月を表示したとき、出すものに2案あります。A案＝その月に「動くべき（予約を出すべき）」計器。B案＝その月に「校正期限が来る」計器。Bだと、リードタイムの長い業者が手遅れになります。推しはAです。
MATSUAでお願いします。それと、各行に「何をすべきか」を言葉で出してほしい。予約を出すのか、もう切れているのか、なぜ今月なのかが、ひと目で分かるように。
Web Claudeでは状態を3つに分けます。黄＝今月予約を出す／赤＝すでに期限切れ／グレー＝入力不備。それぞれに一文の説明を添えます。
論点⑤：出力と、今回やらないこと
MATSU出力は、紙でそのまま配れるレイアウトのエクセル1ファイル。それを自分でメールに添付して製造へ送ります。操作はボタンだけにしたいです。CLIは苦手なので。
Web Claudetkinterで、ファイル選択・計算・月の切り替え・エクセル出力まで、すべてボタンで組めます。追加で入れるのは openpyxl くらいで、小さく作れます。
MATSU今回やらないことも決めます。メールの自動送信、台帳エクセルの編集、製造部門が触る画面は作らない。使うのは私一人です。
3. 問診の答えが、そのまま要求仕様書になる
論点が出そろったところで、Claudeが一度、全体を並べて「これでOKですか」と確認を挟みました。内容を見て問題なかったので、そのまま要求仕様書に書き上げてもらいました。問診で固めた条件が、そのまま仕様書になる——出来上がった要求仕様書は、次の7つで構成されています。
- このツールは何か
- 背景と困りごと
- このツールがやること（計算ルール・状態の色分け）
- 入力と出力（エクセルの列・型まで）
- やらないこと
- なぜ既存ツールでは足りないか
- 使う人に持たせる安心
計算ルールのところに実データで計算した正解値の表が具体的な値として入っているなど、後発になる設計・テストで活用できる形になっている。実際の要求仕様書は、下のボタンから読めます。
4. まとめ
- コードを書く前に、要求仕様プロンプト1つで「何を作るか」を固めた
- 質問に答えるうちに、困りごとが数字とルールのある条件に変わった
- 実データ（最長45日・不備2台）を見て決めた
- 判断は人、補強はClaude。固まった条件が、そのまま要求仕様書になった
次回は、この要求仕様書を「種」にして、計算と判定の中身（コア）と画面（UI）をどう作るか——設計の段階に進みます。要求仕様書がしっかりしていれば、設計はそれを読んでたどるだけ。出発点が固まった今が、いちばん大事な一歩でした。
使用しているデータ・業者名・計器名はすべて架空のものです。実在の企業・校正機関とは関係ありません。
コメント