AIに「検査データを集計するツールを作って」と頼めば、それらしいものは返ってきます。でも、動くだけで意図とズレた道具になりがちです。そうならないために、コードを書く前に「何を作るか」を固める——その最初の一歩が要求仕様書です。この記事では、複数ロットの検査成績書を集計する道具を例に、決まったプロンプト1つで要求仕様書を作るところまでを見ていきます。とくに今回の山場は、様式がバラバラな成績書をどう安全に読むかを、要求仕様の段階で決めきるところです。
この進め方（プロンプト仕様駆動開発）の全体像は、土台の記事にまとめています。まだの方は先にこちらをどうぞ。
1. 困りごとは「10ロットを1ファイルずつ開いて、手で集計している」こと
今回の仮想事例は、中小製造業で品質・検査を担当する方の悩みです。製品のロットごとに、検査成績書がExcelの別ファイルとして保存されています。月次や四半期で品質の傾向を見たいとき、10ロット分のファイルを1つずつ開いて、平均値をコピペで集計表に転記し、グラフを手作業で作っている——これを解決したい。
データの集計には単純に時間がかかります。転記の途中でミスも出ます。「フォルダに入れた複数ロットの成績書を、まとめて1つの表とグラフにしたい」という単純な作業ですが、手作業のままだと、毎回の重い仕事になってしまうわけです。下記の図のようにロットデータをファイルごと読み込んで、一気に統計・トレンドまで出力することを目標にします。
フォルダごと読み込み、統計・トレンドを自動化してしまえば、コピペ作業で発生する数字が1つ静かにズレても、グラフは平気で描けてしまうことも改善します。
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に相談するとき、実際の成績書に近いデモデータを渡すと、設計の確かさが段違いになります。今回はあえて3品目（六角ナット・シャフト・プレート）でフォーマットを変えて、各10ロット分を用意しました。品目ごとにフォルダを分けてあります。
| A：六角ナット | B：シャフト | C：プレート | |
|---|---|---|---|
| 測定値の並べ方 | 横並び（1項目=1行、測定が横に） | 縦並び（1項目=1列、測定が縦に） | 積み上げ（1行=1測定、項目名を繰り返す） |
| メタ情報の位置 | 左上 | 右上 | 左上 |
| 基準値の列 | あり | なし | なし |
| 平均の出し方 | 各行の右端 | 一番下の行 | 別枠の「集計」 |
実際に各ロットのエクセルの中身をみてみるとよくわかります。
製品Aのテンプレート
製品Bのテンプレート
製品Cのテンプレート
同じ「検査成績書」でも、現場や製品が違えば様式はこれくらい変わります。きれいに揃ったデータだけを前提にすると、現場の実物が来た瞬間に動かなくなる。だから最初から、揃っていないデータを想定して設計します。
3. 要求仕様の設計ポイント──バラバラなデータを安全に読む
やり取りの中身に入る前に、この要求仕様の何が設計ポイントなのを先に整理しておきます。今回いちばんの難所は、ロットや品目ごとに成績書の様式がバラバラなことでした。これに対して、要求仕様の段階で2つの工夫をいれて一括処理できるようにします。
設計ポイント①：生成AIの読み込みに頼らず、数式の足跡を辿る
フォーマットが一定ではないデータは生成AIに読み込ませることはできます。——一見スマートですが、構造がバラバラだと誤読が紛れ込みデータが読み込めないときがあります。この問題を解決する方法として、平均を出すために入れた AVERAGE 数式に注目しました。数式が指す範囲は、「測定値はここだ」と人が既に宣言した足跡です。それを逆に辿れば、横並びでも縦並びでも積み上げでも、測定値とサンプル数に確実に届く。今回データを抽出するための戦略になります。
設計ポイント②：フォーマットが異なるからこそ、安全装置を仕様に組み込む
様式がバラバラだということは、それだけ読み取りを取り違える余地が大きいということです。このツールのチャレンジングなところは、フォーマットを選ばず、データを読み取るところにあります。データを読み取る正確性を以下のように設計しました。
- AVERAGE関数が示す範囲をもとに各データを取得する。
- 「値1」などラベリングされたデータに対してデータを取得する。
- 1と2が独立して取得した値が一致するか確認し、一致したらOK、一致しない場合は警告
独立した2つの経路からデータを取得することでデータ取得における正確性を担保する。読み間違えを最大のリスクと捉えて設計することにしました。
4.Web Claudeとのやり取り
この2つの設計ポイントに、どうやって行き着いたのか。Web Claudeとのやり取りを、要点だけ振り返ります。AIに丸投げするのではなく、人が決めて、Claudeが補強する——その様子です。
MATSU品目ごとにフォーマットが違うんです。品目ごとにフォルダへまとめてあるので、それを一気に読み込んで、集約表・基本統計・トレンドグラフのExcel1ファイルにしたい。実物に近いサンプルを3つ渡します。
Web Claude開いてみて、はっきりしました。これは「列が少し違う」程度ではなく、測定値の並べ方そのものが3つとも違います——横並び・縦並び・積み上げ。人が見れば同じ成績書でも、機械には別物です。ここで「どんなExcelも自動で読む」道具にすると、測定値を取り違えても、それらしいグラフが描けてしまう。「動く≠正しい」が一番怖い形で出ます。
MATSUなら、平均の AVERAGE 数式が参照している範囲を逆に辿るのはどうでしょう。当てずっぽうで測定値を探すより、確実な気がします。
Web Claudeその発想、筋がいいです。数式は「測定値はここだ」と人が残した足跡ですから。口だけでは失礼なので3ファイルで動かしたところ、横・縦・積み上げの3構造すべてで測定値もサンプル数も取れました（各 n=10）。構造が違っても、足跡を辿るだけで全部に届く。まずはこれを軸に据えましょう。
MATSUただ、その数式が本当に測定値を指している保証は、どこにあるんでしょう。数式とは別の方法でももう一度測定値を取って、突き合わせれば、取り違えを自分で見つけられませんか。
Web Claudeいい発想です。そこで2系統にします。数式を一切見ず、「測定」のラベルだけを頼りに測定値を探す別経路を作って、数式経路と突き合わせる。両方が同じ値に届けば採用、食い違えば取り違えの疑いで警告、片方しか取れなければ照合できないとして除外する。LLM同士の確認のように相関した検証ではなく、性質の違う別系統で照らし合わせる形です。実際に2経路を独立に走らせたら、3構造すべてで同じ測定値に届いて完全一致しました。
MATSUそれで確定で。出力は、集約表・基本統計・項目ごとのトレンドグラフを埋め込んだExcel1ファイル、並びは検査日順。合否判定や、Cp・Cpk・管理図といった工程管理は今回やりません。そこは欲張らない。
こうして固まった要求仕様書は、「このツールは何か／背景／やること／入力と出力／やらないこと／なぜ既存ツールでは足りないか／安心」の7つで構成されています。市販のSPC（統計的工程管理）ソフトのように高機能な計算を実装に載せずに、むしろSPCにデータを渡す前処理をメインとしたシステムとして作ることにしました。このツールは、その集約の手前だけを安く確実に埋めます。実際の要求仕様書は、下のボタンから読めます。
5. まとめ
- 今回の難所は、ロットや品目ごとに成績書の様式がバラバラなこと
- 生成AIの読み込みに頼らず、人が残した数式の足跡を辿って測定値を取る設計にした
- フォーマットが異なるからこそ、独立した2つの経路で測定値を取り、一致を確かめる安全装置を仕様に入れた
- 判断は人、補強はClaude。実データで確かめた条件が、そのまま要求仕様書になった
次回は、この要求仕様書を「種」にして、測定値をどう取り出し・どう集計するかの中身（コア）と、フォルダを選んで実行する画面（UI）を、どう設計するか——設計の段階に進みます。要求仕様書がしっかりしていれば、設計はそれを読んでたどるだけ。出発点が固まった今が、いちばん大事な一歩でした。
使用しているデータ・品名・測定値はすべて架空のものです。実在の企業・製品とは関係ありません。
コメント