作ったツールを、壊さずに育てる ── 検査集計ツールに3つの機能を、要求仕様から版を上げて足す

2026年6月30日2026年7月1日

前回、品目ごとに様式の違う検査成績書を、取り違えずにまとめて集計するツールを、プロンプト仕様駆動開発（以下、PSDD）で一周作りました。

アプリは、使ってみて初めて直したい所が見えてくる

どれだけ丁寧に要求を固めても、使う前にすべての要望を出しきることはできません。実際に毎月の集計でツールを動かし、出てきた帳票を眺めて初めて、「ここが少し不便だ」「ついでにこれも見たい」という気持ちが立ち上がってきます。これは設計の失敗ではなく、ものを作って使う以上、自然に起こることです。

MATSU

不具合・バグだって直さなければいけないですね。どんなに作り込んでも改善する事項はどうしても上がってくるものです。

ツールの改善はどうやって行えばいいのか。前回のツールを作成したときに展望として残した課題をそのまま実装することにしたいと思います。まずはこの3つの改善が、それぞれどういう項目なのかを紹介します。後の章で見るとおり、この3つは直し方の「重さ」がそれぞれ違います。

グラフをもっと見やすくしたい

前回のツールは、検査項目ごとにトレンドグラフを描きます。実際に出してみると、線の引き方や軸の見せ方に、もう少し整えたい所が出てきました。もともと散布図を想定したが、点を結ぶ線が突いてくる散布図として出力されてました。この線を除去しようと思います。

これは見た目だけの話で、測定値の取り方や平均の計算には一切触れません。間違えても、グラフを見れば一目でおかしいと気づけます。表示の手直しは、3つの中でいちばん軽い変更です。

品目が多いので、まとめて処理したい

いまのツールは、品目フォルダを一つ選んで実行し、その品目ぶんのExcelを出す作りです。品目が数個ならこれで十分ですが、前回の事例では取り扱う品目が数十から百近くにのぼることを想定しています。一つずつ選んで実行を繰り返すのは、品目が増えるほど苦しくなります。

そこで、親フォルダを一つ選べば、その配下にある品目フォルダをまとめて処理する形にしたいです。いわゆるバッチ処理です。これは見た目ではなく、処理の流れに手を入れる変更ですが、測定値を読む心臓部そのものは前回のまま使い回せます。既存の処理の外側に、繰り返しを足す変更です。

測定値が揃ったので、Cp・Cpkも出したい

前回、平均値だけでなく、個々の測定値を一つも取りこぼさずに確保しました。その狙いの一つが、この先で工程能力指数（Cp・Cpk）を計算するための土台を残しておくことでした。測定値の台帳が手元にある以上、規格の上限・下限を与えれば、Cp・Cpkは計算できます。

これは表示でも処理の流れでもなく、集計したあとに新しい計算ロジックを足す変更です。間違えても、それらしい数字が静かに出てしまうので、目で見て気づくことができません。3つの中でいちばん重く、慎重に扱うべき変更です。

Cpkを計算するために上限値・下限値が必要です。エクセルのフォーマットも変更したものを使います。

大きな変更を伴う要望は、要求仕様に戻してから足すと壊れにくい

3つの要望のうち、グラフの手直しは表示だけの軽い変更なので、思いついたその場でツールを直接いじっても問題ありません。間違えても、グラフを見ればすぐ気づけるからです。

一方で、バッチ処理やCp・Cpkのように、処理の流れや計算ロジックに踏み込む変更は、話が違います。これらを思いつきで実装へ直接足していくと、動きはするのですが、要求仕様書や設計仕様書に書いてあることと、実際の中身が少しずつずれていきます。半年後に開いたとき、「なぜこの処理がここにあるのか」を、仕様書から辿れなくなる。前回せっかく、なぜそう作ったかを辿れる状態を築いたのに、それが崩れてしまいます。

そこで、大きな変更を伴う要望は、いったん要求仕様に戻してから足す。これを勧めます。「必ずそうしなければならない」という強制ではありません。そのほうが壊れにくく、後から辿れる状態を保てるから、勧めるのです。具体的には2つの道具を使います。版をフォルダごと分けて管理することと、変更を引き出す専用のプロンプトです。

版を上げるときは、フォルダごと分けて管理する

変更を加える前のツール一式を、フォルダごとまるごと残しておきます。いまの状態を「v1」というフォルダに固めたまま手をつけず、新しく「v2」というフォルダを用意して、変更はv2の中だけで進めます。前の版を上書きせず、版ごとにフォルダを分けて並べる、というのがこの方式の肝です。以下のようなフォルダ構成をイメージしてください。

検査自動化フォルダ/
  psdd.py                  ← 版に依存しない共通ツール（ルートに1本）
  v1/                      ← 前の版。手をつけず残す
    docs/
      要求仕様書.docx
      設計仕様書.docx
      テスト仕様書.docx
    src/
      ui.py             　 画面
      core.py           　 読み込み・照合・集約・統計
    tests/
      test_core.py      　 コアのテスト
  v2/                      ← 新しい版（構成はv1と同じ形）
    docs/                  　 ここに新版の仕様書を入れる
    src/
    tests/

仕様書（docs）・プログラム（src）・テスト（tests）は、すべて版フォルダの中に収めます。v1のsrcには、画面・中核ロジックなどのプログラムが入っていて、testsにはその中核をテストするファイルがあります。v2は、この同じ形のフォルダを新しく作り、docsに新版の仕様書を入れるところから始めます。こうしておくと、過去の版が手つかずで残るので、いつでも前の状態に戻れます。

変更プロンプトで、足したいことを問診として引き出す

要求仕様に戻す、といっても、ゼロから書き直すわけではありません。前回、要求を問診形式のプロンプトで引き出したのと同じように、変更のための専用プロンプトを用意してあります。確定済みの前の版の要求仕様書を出発点として渡し、「今回は何を足したいのか」を、対話で一つずつ引き出していく作りです。

このとき守るのが、IDの扱いです。前回作った要求や設計には、一つずつ番号（ID）が振ってあります。既存のIDは絶対に変えず、追加するものだけ続き番号で足す。やめる機能があっても、番号を消すのではなく「廃止」と印を付けて残します。こうすることで、要求から設計、テストへとつながる線（トレーサビリティ）が、版を上げても切れません。前回のトレーサビリティマトリクスが、今回の変更でも生き続けるということです。

要求仕様・設計仕様・テスト仕様を、版を上げて作り直す

ここからが実際の作業です。やること自体は、前回とまったく同じです。要求仕様を決め、設計仕様に落とし、テスト仕様を書き、最後に実装する。この順番は、新しく作るときも、すでにあるものを変えるときも変わりません。違うのは、ゼロからではなく、前の版を出発点にして差分だけを積むという点だけです。

まずは、3つの変更がそれぞれツールのどこに、どんな形で入るのかを見ておきます。

3つの変更には、重さの違いがある

前回のツールは、フォルダから検査成績書を読み込み、2つの独立した経路で測定値を照合し、検査日順に集計する、という流れでできています。この読み込み・照合・集計が、ツールの中核です。今回の3つの変更は、いずれもこの中核には手を加えません。加えるのは、その手前（入力の選び方）と、その後ろ（集計のあとの計算と、結果の見せ方）だけです。だから、前回正しく動いていた中核は、そのまま生き続けます。

3つの変更が、それぞれどこに入るかを並べると、重さの違いがはっきりします。

変更	入る場所	加わるロジック	間違えたとき	重さ
グラフの修正	結果の見せ方（出力）	散布図を点だけにする。縦軸・横軸にラベルと目盛りを出す	グラフを見ればすぐ気づく	軽い（外側）
バッチ処理	入力の選び方（中核の外側）	親フォルダを選んだら、配下の品目フォルダを順に回す繰り返しを足す	処理されない品目があれば気づける	重い（内側）
Cp・Cpk	集計のあと	規格の上下限を読み、ばらつきと工程能力を計算する	それらしい数字が静かに出てしまう	いちばん重い（内側）

グラフの修正は、計算には一切触れない見た目だけの話です。だから要求仕様には「散布図は点だけ、両軸にラベルと目盛り」と一行書き足すだけで足り、設計やテストを作り直す必要はありません。これがいちばん軽い変更です。

一方、バッチ処理とCp・Cpkは、処理の流れや計算ロジックそのものが増えます。特にCp・Cpkは、間違えても静かにそれらしい数字が出てしまうので、いちばん慎重に扱います。これらは、要求仕様だけでなく、設計仕様とテスト仕様まで版を上げて、何をどう計算するのかを、テストが書けるところまで詰めます。次の節から、その実際の進め方を見ていきます。

要求仕様を、版を上げて変更する

まず要求仕様です。ここでも前回と同じく、プロンプトに問診してもらいます。違うのは、前回が白紙から要求を引き出したのに対し、今回は確定済みの第1版の要求仕様書を出発点として渡し、「そこから何を変えたいか」だけを引き出す点です。そのための変更用プロンプトが、これです。

要求変更のプロンプト

あなたは、すでにある要求仕様書を出発点に、私が変えたい点を問診で引き出し、
版番号を一つ上げた更新版の要求仕様書まで書き上げる相談相手です。
設計の基礎、とくに「10. 変更するとき（版を上げる）」の共通ルール
（版を上げる／既存IDは振り直さない・追加は続き番号・廃止はマーク／既存を壊さない／
外側・内側で進め方を分ける／差分サマリーを最初に出す）を、すべて守ります。
このプロンプトには、要求フェーズ固有のことだけを書きます。共通の原則は設計の基礎を見てください。

【最初にやること】
添付の「現行の要求仕様書（確定版）」と、あれば spec_ids を読み、いまの構造を把握する：
やること（大・中・小＋ID）／やらないこと／入力と出力／前提技術。現行の版番号も確認する。
把握したら、現状の骨格を5〜6行で短く要約して見せ、「ここから何を変えるか」の土台にする。

【変更点を引き出す問診】
- 一度に聞くのは1〜2点まで。専門用語を使わず、私の言葉で。
- 3方向で聞き出す：足したい機能／変えたい・直したい挙動／「やらないこと」からやることへ移したいもの。
- 答えが曖昧なときは、具体例や数字で掘り下げる（どの出力をどう変えたいか・どの入力が増えるか）。
- 変更点が挙がるたび、外側／内側に仕分けて進め方を私と合意する（基礎10）。
- 内側の変更は、新規と同じ粒度まで詰める：入力が増える/変わるならその様式まで
  （テスト用データを作れる粒度。新しい基準値があればどこから・どんな値か）。出力が変わるなら完成イメージまで。
- 私が欲張りそうなら「それは今回やらないことに残せませんか」と引き戻す。結論は押し付けない。

【出力】（基礎10の差分サマリー → 本体 の順）
1. 変更の差分サマリー（追加ID／廃止ID＋理由／文言だけ直したID／波及した既存範囲／各変更の外側・内側）。
2. 版番号を一つ上げた更新版の要求仕様書（.docx。章立ては現行を保ち、変えた箇所だけ更新。冒頭に版番号・更新履歴）。
3. spec_ids を更新（追加・廃止を反映。版はファイル名 spec_ids_vN.json で表す。中身は配列のまま）。
4. できたら、新規と同じ「仕上げ確認」を、今回変えた範囲を重点に投げて、定義の穴を潰す。

あなたは、すでにある要求仕様書を出発点に、私が変えたい点を問診で引き出し、
版番号を一つ上げた更新版の要求仕様書まで書き上げる相談相手です。
設計の基礎、とくに「10. 変更するとき（版を上げる）」の共通ルール
（版を上げる／既存IDは振り直さない・追加は続き番号・廃止はマーク／既存を壊さない／
外側・内側で進め方を分ける／差分サマリーを最初に出す）を、すべて守ります。
このプロンプトには、要求フェーズ固有のことだけを書きます。共通の原則は設計の基礎を見てください。

【最初にやること】
添付の「現行の要求仕様書（確定版）」と、あれば spec_ids を読み、いまの構造を把握する：
やること（大・中・小＋ID）／やらないこと／入力と出力／前提技術。現行の版番号も確認する。
把握したら、現状の骨格を5〜6行で短く要約して見せ、「ここから何を変えるか」の土台にする。

【変更点を引き出す問診】
- 一度に聞くのは1〜2点まで。専門用語を使わず、私の言葉で。
- 3方向で聞き出す：足したい機能／変えたい・直したい挙動／「やらないこと」からやることへ移したいもの。
- 答えが曖昧なときは、具体例や数字で掘り下げる（どの出力をどう変えたいか・どの入力が増えるか）。
- 変更点が挙がるたび、外側／内側に仕分けて進め方を私と合意する（基礎10）。
- 内側の変更は、新規と同じ粒度まで詰める：入力が増える/変わるならその様式まで
  （テスト用データを作れる粒度。新しい基準値があればどこから・どんな値か）。出力が変わるなら完成イメージまで。
- 私が欲張りそうなら「それは今回やらないことに残せませんか」と引き戻す。結論は押し付けない。

【出力】（基礎10の差分サマリー → 本体 の順）
1. 変更の差分サマリー（追加ID／廃止ID＋理由／文言だけ直したID／波及した既存範囲／各変更の外側・内側）。
2. 版番号を一つ上げた更新版の要求仕様書（.docx。章立ては現行を保ち、変えた箇所だけ更新。冒頭に版番号・更新履歴）。
3. spec_ids を更新（追加・廃止を反映。版はファイル名 spec_ids_vN.json で表す。中身は配列のまま）。
4. できたら、新規と同じ「仕上げ確認」を、今回変えた範囲を重点に投げて、定義の穴を潰す。

3つのうち、いちばん多く問い返されたのはCp・Cpkでした。工程能力指数を計算するには、いまの検査成績書にない情報や、結果を左右する決め事が必要だからです。プロンプトは、それらを一つずつ質問してきました。実際のやり取りは、おおむね次のようなものでした。

Web Claude

必要なことは細かく聞かせていただきます

Cp・Cpkで聞かれたことと、答えたこと

規格の上限・下限はどこから手に入りますか
　→　各様式のExcelに規格欄を追記して、そこから読む
ばらつきは標本（n−1）か、母集団（n）か
　→　全体から一部を抜き取って測る前提なので、標本（n−1）
Cp・Cpkは、ロットごとに出して平均するか、全ロットを合算して1つ出すか
　→　ある期間の工程能力を見たいので、全ロットを合算して1つ出す
規格が片側だけの項目はありますか
　→　今回は全項目が上下限の両側そろっているので、両側だけ対応（片側は次版へ）
同じ品目でロットごとに規格値が食い違ったらどうするか
　→　規格が定まらず計算できないので、その品目はまるごと処理せず、その旨を表示する

ここを一つずつ決めておかないと、後でテストの期待値が決められません。たとえば「標本か母集団か」が曖昧なままだと、計算結果が変わるので、何をもって正解とするかが定まらないのです。プロンプトは、思いつきで実装に入る前に、こうした分かれ道を先に潰してくれます。

変更点が固まると、プロンプトは出力の前に、まず差分サマリーを見せます。何を足し、何を廃止し、どの既存項目に波及するか、それぞれ外側か内側か。今回は次のように整理されました。

変更の差分サマリー（第1版→第2版）

グラフ修正（外側）：
既存のREQ-5.3.2の文言を「点のみ＋両軸ラベル」に具体化。IDは新設しない。
バッチ処理（内側）：
起点だったREQ-1.1（1フォルダ＝1品目）を廃止し、新しくREQ-6（親フォルダ配下を一括処理）を続き番号で新設。
Cp・Cpk（内側）：
新しくREQ-7（統計量の算出）を新設。規格値の入力定義も各様式に追記。

大事なのは、既存のIDは一つも振り直さず、廃止するREQ-1.1も行を消さずに「廃止」と理由を残し、追加は続き番号で起こしたことです。これで、前回作った要求から設計・テストへの線（トレーサビリティ）が、版を上げても切れません。差分サマリーで全体像を確認してから、版番号を上げた第2版の要求仕様書が出力されます。

最後に、プロンプトは「仕上げ確認」として、変更した範囲に定義の穴がないかを点検してくれました。今回は2つ見つかりました。測定値が全て同じでばらつきがゼロになると、Cp・Cpkが計算できない（ゼロで割ることになる）こと。規格値が片側しか入っていないと、両側前提のCp・Cpkが出せないこと。どちらも、思いつきで実装していたら見落とし、エラーで落ちるか、おかしな数字が出ていた箇所です。要求の段階で穴として拾えたので、「その場合は算出不可と表示する」と決めて先へ進めました。

MATSU

従来のプログラミングと明らかに違うのはわからないことはAIに聞くことができる点。わからない→質問→理解→判断→実装or辞める
この判断ができるようになったのが凄く大きいです。

設計仕様とテスト仕様も、版を上げて変更する

要求の第2版が固まったら、その差分を設計とテストにも流します。ここでも考え方は要求のときと同じで、確定した前の版を出発点として渡し、増えた要求に対応する分だけを足します。設計には設計用の、テストにはテスト用の、それぞれ変更プロンプトを使います。

設計仕様書変更のプロンプト

あなたは非エンジニアの開発相談相手です。
すでにある設計仕様書を出発点に、更新された要求仕様書の差分に対応する設計だけを積み増し、
版番号を一つ上げた更新版の設計仕様書（.docx）を作ってください。
設計の基礎、とくに「10. 変更するとき（版を上げる）」の共通ルールを、すべて守ります。
このプロンプトには、設計フェーズ固有のことだけを書きます。共通の原則は設計の基礎を見てください。
判断の根拠は、添付の文書とデータ（更新後の要求仕様書・現行の設計仕様書・入力サンプル・
出力完成ファイル・設計の基礎）だけにし、会話の記憶を根拠にしない。Excel 等は実際に開いて確かめる。

【最初にやること】
添付の「更新後の要求仕様書」「現行の設計仕様書」「設計の基礎」を読む。現行の設計の版番号を確認する
（冒頭に、対応する要求仕様書の版も記録する）。要求の差分（追加・廃止・意味変更のID）を特定し、
現状の設計の骨格を5〜6行で要約して見せる。

【このフェーズでやること】
- 要求の差分に対応する設計だけを、追加・変更・廃止する。要求で変わっていない設計は据え置く。
- 外側（表示・グラフの形）は、対応する既存関数の記述を一行更新する程度。関数の契約は変えない。
  内側（計算・判定・入力定義）は、関数の取り決め・判定計算の手順・物理表現を、テストを書ける粒度まで詰める。
- 既存の関数の契約（名前・引数・戻り値）は、変更対象に挙がらないかぎり変えない（基礎10のリグレッション）。
  契約を変えるしかないときは、勝手に変えず、なぜ必要か・どの既存テストに波及するかを報告して止まる。
- 新しい関数に設計ID（DES-）を続き番号で振る。要求ID→設計ID対応表を更新し、新しい要求IDすべてに担当を割り当てる。
- 要求の「やらないこと」を超えない。最小構成。

【書き終えたら自己チェック】
- この設計の次版だけで、テスト設計者が、追加・変更された要求のテストを書けるか。
- 変えていない既存関数の契約が、現行から動いていないか（既存テストが通り続ける形か）。

【出力】（基礎10の差分サマリー → 本体 の順）
1. 設計の差分サマリー（追加DES／廃止DES＋理由／記述だけ更新したID／対応する要求ID／外側・内側／波及した既存範囲）。
2. 版番号を一つ上げた更新版の設計仕様書（.docx。現行の章立てを保ち、変えた箇所だけ更新。
   冒頭に版番号・更新履歴・対応する要求の版）。構成は現行の設計仕様書と同じ
   （全体像／コア2-1〜2-7／UI／設計ID一覧／要求ID→設計ID対応表／使う技術とやらないこと／確定待ち）。

あなたは非エンジニアの開発相談相手です。
すでにある設計仕様書を出発点に、更新された要求仕様書の差分に対応する設計だけを積み増し、
版番号を一つ上げた更新版の設計仕様書（.docx）を作ってください。
設計の基礎、とくに「10. 変更するとき（版を上げる）」の共通ルールを、すべて守ります。
このプロンプトには、設計フェーズ固有のことだけを書きます。共通の原則は設計の基礎を見てください。
判断の根拠は、添付の文書とデータ（更新後の要求仕様書・現行の設計仕様書・入力サンプル・
出力完成ファイル・設計の基礎）だけにし、会話の記憶を根拠にしない。Excel 等は実際に開いて確かめる。

【最初にやること】
添付の「更新後の要求仕様書」「現行の設計仕様書」「設計の基礎」を読む。現行の設計の版番号を確認する
（冒頭に、対応する要求仕様書の版も記録する）。要求の差分（追加・廃止・意味変更のID）を特定し、
現状の設計の骨格を5〜6行で要約して見せる。

【このフェーズでやること】
- 要求の差分に対応する設計だけを、追加・変更・廃止する。要求で変わっていない設計は据え置く。
- 外側（表示・グラフの形）は、対応する既存関数の記述を一行更新する程度。関数の契約は変えない。
  内側（計算・判定・入力定義）は、関数の取り決め・判定計算の手順・物理表現を、テストを書ける粒度まで詰める。
- 既存の関数の契約（名前・引数・戻り値）は、変更対象に挙がらないかぎり変えない（基礎10のリグレッション）。
  契約を変えるしかないときは、勝手に変えず、なぜ必要か・どの既存テストに波及するかを報告して止まる。
- 新しい関数に設計ID（DES-）を続き番号で振る。要求ID→設計ID対応表を更新し、新しい要求IDすべてに担当を割り当てる。
- 要求の「やらないこと」を超えない。最小構成。

【書き終えたら自己チェック】
- この設計の次版だけで、テスト設計者が、追加・変更された要求のテストを書けるか。
- 変えていない既存関数の契約が、現行から動いていないか（既存テストが通り続ける形か）。

【出力】（基礎10の差分サマリー → 本体 の順）
1. 設計の差分サマリー（追加DES／廃止DES＋理由／記述だけ更新したID／対応する要求ID／外側・内側／波及した既存範囲）。
2. 版番号を一つ上げた更新版の設計仕様書（.docx。現行の章立てを保ち、変えた箇所だけ更新。
   冒頭に版番号・更新履歴・対応する要求の版）。構成は現行の設計仕様書と同じ
   （全体像／コア2-1〜2-7／UI／設計ID一覧／要求ID→設計ID対応表／使う技術とやらないこと／確定待ち）。

設計の基礎（設計変更のプロンプトと同時にわたす）

# 設計の基礎（このプロジェクトの共通ルール）

設計・テスト設計・実装の全フェーズで守る、共通の原則。
各フェーズのプロンプトは、このファイルを一緒に渡して「設計の基礎に従う」として参照する。

## 1. 設計とテストは独立に作る（独立性）
- 各フェーズは、前フェーズの成果物（要求仕様書・設計仕様書などの文書）だけを唯一の入力とする。
  会話の履歴・記憶を根拠にしない。穴・確定待ち・矛盾の判断も、渡された文書に書いてあるか・いないか
  だけで決める。「前に会話でこう言った」を持ち出すと、確定済みの事項を曖昧と誤判定したり、
  文書に無い穴を作り出したりする（幻の穴）。だから各フェーズは独立したチャットで行う。
- 設計仕様書には実装の中身（コード）を書かない。書くのは日本語の手順と、各関数の取り決めだけ。
- テストは、実コードを見ず・走らせず、設計の取り決めと要求仕様書の期待値から書く。
- テストとコードは、実装フェーズで初めて出会う（pytest 実行）。これで「動く」でなく「正しい」を確かめる。
- テストの期待値は、要求仕様書の計算例（人間が確認済みの正解）に紐づける。コードから逆算しない。

## 2. 取り決め（関数の入口と出口の約束）は物理表現まで定義する
各関数の取り決め（名前・受け取るもの・返すもの）には、テスト設計者がこれだけでテストを書ける粒度まで：
- 関数名・引数（名前と型）・戻り値
- 戻り値や受け渡すデータの物理表現：dataclass か dict か、フィールドの英語名と型
  （例：LotResult は dataclass。属性 lot_no:str, mean:float, status:str）
- モジュール構成：ファイル名＝import名（例：コアは core.py ＝ import core）
- 値の決まり：日付の入力形式、丸めの桁、状態を表す文字列の値（"採用"／"除外" など）
取り決めが曖昧だと、テストを書く人と実装する人が別々の名前・戻り値を想定して噛み合わない。
中身（アルゴリズム）は書かず、表面の取り決め（何を受け取り何を返すか）は具体的に共有する。

## 3. UIに判断を置かない
- コア（計算・判定）とUI（画面）は役割を分ける。UIはコアを呼ぶだけ。
- 判断（中断する／警告する／弾く／続行する など）は、画面のボタンやイベントに紐づくものでも、
  コア側の関数に切り出す。UIはそれを呼んで結果を表示するだけ。
- UIに残してよいのは、純粋な画面操作（要素の配置・表示・入力の受け渡し）だけ。
- 守らないと、判断がUIに埋もれて自動テストできず、「画面操作だから手動確認」で逃げてしまう。

## 4. ファイルは増やしすぎない
- 原則 models（データ構造）・core（読み込み・計算・判定・出力の全関数）・ui（画面）の3つに収める。
- 設定値（しきい値など）が多ければ config を足してよい。
- 「関心を関数で分ける」ことと「ファイルを分ける」ことは別もの。reader／validator／writer のように
  機能ごとにファイルを増やさない。役割ごとの関数はコメントで区切って同じ core に並べる。
- テストも同じ。tests/ は原則 test_対象.py の1ファイルにまとめ、観点が増えても機能ごと・版ごとに
  ファイルを分けない（フィクスチャ・定数・ビルダーの重複を防ぎ、全観点を1ファイルで一望できる）。
  既存の運用中テストへ後から足す変更フェーズ（基礎10）だけは、この限りではない。

## 5. 正常系以外を必ず定義する
正常に動く場合だけでなく、次の5つを定義する（抜けると実装もテストも決められない）：
- 失敗・例外の経路：開けない・壊れている・権限がない・想定外の構造のとき、例外を投げるのか、
  エラーを表す戻り値（status 等）に畳むのか。技術的な失敗（I/O・破損・ロック）も。
- 値の境界・特殊値：空・欠損・非数値・エラー値・ゼロ・極端な値のとき、どう扱うか。
- 状態とデータの整合：ある状態（不整合・除外など）のとき、保持するデータの中身は何か。
- 件数・重複の境界：0件・1件・重複のとき、どうふるまうか。キーが衝突したら誰がどう止めるか。
- 結果に影響する技術前提：ライブラリの動作モードで結果が変わる箇所は前提を明記
  （例：Excel を数式の文字列で読むのか、計算済みの値で読むのか）。

## 6. 検証できる形になっているか
- 各要求を検証する情報が、関数の戻り値やデータ構造に乗っているか。乗っていなければ、
  実装が何を入れても通ってしまう（＝検証不能）。例：「不整合のセル番地を報告する」要求なのに、
  抽出関数が値しか返さず番地を持たないなら、その要求はどの戻り値からも確かめられない。
- 本文と、データ構造・対応表が、互いに矛盾していないか。

## 7. 確定待ち（勝手に埋めない・リスクで仕分ける）
- 決められない点は、勝手に仮定で埋めず「確定待ち」として、何を決めれば埋まるかと一緒に明記する。
- それが本来は要求仕様書にあるべき穴（様式・ふるまい）なら、要求側の穴である旨を明記する。
- 各確定待ちに、リスクの大きさを添える。リスクは「影響度 × 発生頻度」で見積もる。
  ・影響度：大＝間違った結果が正しく見えるまま出る（静かなデータ破損）／中＝目に見えて止まる
    （気づける失敗）／小＝見た目が変わる程度。
  ・発生頻度：正しく運用されたデータで、どれくらい起きるか（よく／たまに／ほぼ起きない）。
    頻度は要求の文言だけで決めず、添付された実データ（入力サンプル・完成ファイル）を実際に見て
    見積もる。実データで起こりうるか確かめてから強度を決める（例：要求に「表記ゆれを正規化」とあっても、
    添付サンプルにゆれが無ければ頻度は「ほぼ起きない」）。実データを見れば消えるリスクを文言だけで
    過大計上しない。確かめる実データが無ければ【未検証】と明記する。
- リスク大→要求仕様書に戻って定義／リスク中→既定で進め次バージョンで検討と記録／
  リスク小→既定のままでよい（要求に戻さない）。最終判断は人間。
- 全部を要求仕様書に戻さない。リスクと労力で線を引く。静かなデータ破損（影響度大）だけは、
  頻度が低くても軽視しない。

## 8. 要求とのつながり
- 要求仕様書は仕上げ確認を通った確定版とみなす。要求で決まっていることは再確認しない。
- 要求IDごとに、それを実現する関数／確かめるテストを割り当て、全IDに担当があることを確認する。

## 9. ID体系（要求・設計・テストをつなぐ）
- 要求ID（REQ-x.x）：要求仕様書が幹。唯一の採番元。大・中・小の階層。
- 設計ID（DES-）：関数を一意に指す。モジュール大・関数中（core→DES-C01…／ui→DES-U01…／models→DES-M01…）。
- テストID（V-）：観点を主軸に振る（V-01…）。種類（単体／結合／手動）は観点の属性（列）にし、分類軸にしない
  （1観点が単体と手動にまたがるため）。
- 3者は多対多（1関数が複数要求／1要求に複数関数）。番号一致では表せず、トレーサビリティマトリクスで結ぶ。
- コードに刻む：実装の関数は「@id: DES-Cxx ＋ @spec: REQ-x.x（一言）」、テストは「@id: V-xx ＋ @verify: REQ-x.x（一言）」。
  タグは関数の本体の中の「# コメント行」に書く（docstring の中には書かない。整合チェックが拾えず未検証と誤判定される）。1行に1つのIDだけ（複数は行を分ける）。

## 10. 変更するとき（版を上げる）── 既存を壊さず差分を積む
確定版ができたあと、7の「次バージョンで検討」とした宿題や、新しい要望を取り込むときの約束。
初版を新規に作るときは、この章は該当しない（版を上げる元がないため）。
- 各仕様書は自分の版を持つ。変更のたびに版番号を一つ上げる（要求仕様書 第N版→第N+1版。
  設計仕様書・テスト設計仕様書も同様）。設計・テストの仕様書には、対応する要求仕様書の版を
  併記する（どの要求版に紐づくかを残す）。変更後の要求仕様書の次版を、新たな確定版として扱う
  （8の「確定版とみなす」は、その時点の最新版を指す）。
- 既存のIDは振り直さない（REQ・DES・V すべて）。番号は資産。変えると過去のトレーサビリティが切れる。
- 足すIDは、既存の続き番号で起こす。
- やめるIDは、行を消さず「廃止」と印を付け、理由を一言添える（過去のロットや記録から辿れるように）。
- 意味が変わるIDは、原則 旧IDを「廃止」にし、新IDを起こす。
  単なる文言の整理（意味は同じ）は、同一IDのまま直す。
- 既存の関数の契約（名前・引数・戻り値）は、変更対象に挙がらないかぎり変えない。既存の通っている
  テストが、そのまま通り続けることを前提に置く（リグレッションを起こさない）。契約を変えるしか
  ないときは、勝手に変えず、なぜ必要か・どの既存テストに波及するかを報告して止まる。
- 変更は「外側／内側」で進め方を分ける（リスクで仕分け＝7の影響度と同じ考え）。
  ・外側＝表示・レイアウト・グラフの形など、間違っても目で気づけるもの。対応箇所を直接直し、
    結果を上流の仕様書へ一行追記する（差分の逆輸入）。設計・テストは作り直さない。
  ・内側＝計算・判定・入力定義など、間違っても静かに通ってしまうもの。要求仕様書から見直し、
    設計・テストの仕様書も版を上げて改訂する。
- 各フェーズの変更は、最初に差分サマリーを出す：追加したID／廃止したID（理由）／
  記述だけ直したID／波及した既存の範囲。波及しない箇所は触らない（最小構成）。

# 設計の基礎（このプロジェクトの共通ルール）

設計・テスト設計・実装の全フェーズで守る、共通の原則。
各フェーズのプロンプトは、このファイルを一緒に渡して「設計の基礎に従う」として参照する。

## 1. 設計とテストは独立に作る（独立性）
- 各フェーズは、前フェーズの成果物（要求仕様書・設計仕様書などの文書）だけを唯一の入力とする。
  会話の履歴・記憶を根拠にしない。穴・確定待ち・矛盾の判断も、渡された文書に書いてあるか・いないか
  だけで決める。「前に会話でこう言った」を持ち出すと、確定済みの事項を曖昧と誤判定したり、
  文書に無い穴を作り出したりする（幻の穴）。だから各フェーズは独立したチャットで行う。
- 設計仕様書には実装の中身（コード）を書かない。書くのは日本語の手順と、各関数の取り決めだけ。
- テストは、実コードを見ず・走らせず、設計の取り決めと要求仕様書の期待値から書く。
- テストとコードは、実装フェーズで初めて出会う（pytest 実行）。これで「動く」でなく「正しい」を確かめる。
- テストの期待値は、要求仕様書の計算例（人間が確認済みの正解）に紐づける。コードから逆算しない。

## 2. 取り決め（関数の入口と出口の約束）は物理表現まで定義する
各関数の取り決め（名前・受け取るもの・返すもの）には、テスト設計者がこれだけでテストを書ける粒度まで：
- 関数名・引数（名前と型）・戻り値
- 戻り値や受け渡すデータの物理表現：dataclass か dict か、フィールドの英語名と型
  （例：LotResult は dataclass。属性 lot_no:str, mean:float, status:str）
- モジュール構成：ファイル名＝import名（例：コアは core.py ＝ import core）
- 値の決まり：日付の入力形式、丸めの桁、状態を表す文字列の値（"採用"／"除外" など）
取り決めが曖昧だと、テストを書く人と実装する人が別々の名前・戻り値を想定して噛み合わない。
中身（アルゴリズム）は書かず、表面の取り決め（何を受け取り何を返すか）は具体的に共有する。

## 3. UIに判断を置かない
- コア（計算・判定）とUI（画面）は役割を分ける。UIはコアを呼ぶだけ。
- 判断（中断する／警告する／弾く／続行する など）は、画面のボタンやイベントに紐づくものでも、
  コア側の関数に切り出す。UIはそれを呼んで結果を表示するだけ。
- UIに残してよいのは、純粋な画面操作（要素の配置・表示・入力の受け渡し）だけ。
- 守らないと、判断がUIに埋もれて自動テストできず、「画面操作だから手動確認」で逃げてしまう。

## 4. ファイルは増やしすぎない
- 原則 models（データ構造）・core（読み込み・計算・判定・出力の全関数）・ui（画面）の3つに収める。
- 設定値（しきい値など）が多ければ config を足してよい。
- 「関心を関数で分ける」ことと「ファイルを分ける」ことは別もの。reader／validator／writer のように
  機能ごとにファイルを増やさない。役割ごとの関数はコメントで区切って同じ core に並べる。
- テストも同じ。tests/ は原則 test_対象.py の1ファイルにまとめ、観点が増えても機能ごと・版ごとに
  ファイルを分けない（フィクスチャ・定数・ビルダーの重複を防ぎ、全観点を1ファイルで一望できる）。
  既存の運用中テストへ後から足す変更フェーズ（基礎10）だけは、この限りではない。

## 5. 正常系以外を必ず定義する
正常に動く場合だけでなく、次の5つを定義する（抜けると実装もテストも決められない）：
- 失敗・例外の経路：開けない・壊れている・権限がない・想定外の構造のとき、例外を投げるのか、
  エラーを表す戻り値（status 等）に畳むのか。技術的な失敗（I/O・破損・ロック）も。
- 値の境界・特殊値：空・欠損・非数値・エラー値・ゼロ・極端な値のとき、どう扱うか。
- 状態とデータの整合：ある状態（不整合・除外など）のとき、保持するデータの中身は何か。
- 件数・重複の境界：0件・1件・重複のとき、どうふるまうか。キーが衝突したら誰がどう止めるか。
- 結果に影響する技術前提：ライブラリの動作モードで結果が変わる箇所は前提を明記
  （例：Excel を数式の文字列で読むのか、計算済みの値で読むのか）。

## 6. 検証できる形になっているか
- 各要求を検証する情報が、関数の戻り値やデータ構造に乗っているか。乗っていなければ、
  実装が何を入れても通ってしまう（＝検証不能）。例：「不整合のセル番地を報告する」要求なのに、
  抽出関数が値しか返さず番地を持たないなら、その要求はどの戻り値からも確かめられない。
- 本文と、データ構造・対応表が、互いに矛盾していないか。

## 7. 確定待ち（勝手に埋めない・リスクで仕分ける）
- 決められない点は、勝手に仮定で埋めず「確定待ち」として、何を決めれば埋まるかと一緒に明記する。
- それが本来は要求仕様書にあるべき穴（様式・ふるまい）なら、要求側の穴である旨を明記する。
- 各確定待ちに、リスクの大きさを添える。リスクは「影響度 × 発生頻度」で見積もる。
  ・影響度：大＝間違った結果が正しく見えるまま出る（静かなデータ破損）／中＝目に見えて止まる
    （気づける失敗）／小＝見た目が変わる程度。
  ・発生頻度：正しく運用されたデータで、どれくらい起きるか（よく／たまに／ほぼ起きない）。
    頻度は要求の文言だけで決めず、添付された実データ（入力サンプル・完成ファイル）を実際に見て
    見積もる。実データで起こりうるか確かめてから強度を決める（例：要求に「表記ゆれを正規化」とあっても、
    添付サンプルにゆれが無ければ頻度は「ほぼ起きない」）。実データを見れば消えるリスクを文言だけで
    過大計上しない。確かめる実データが無ければ【未検証】と明記する。
- リスク大→要求仕様書に戻って定義／リスク中→既定で進め次バージョンで検討と記録／
  リスク小→既定のままでよい（要求に戻さない）。最終判断は人間。
- 全部を要求仕様書に戻さない。リスクと労力で線を引く。静かなデータ破損（影響度大）だけは、
  頻度が低くても軽視しない。

## 8. 要求とのつながり
- 要求仕様書は仕上げ確認を通った確定版とみなす。要求で決まっていることは再確認しない。
- 要求IDごとに、それを実現する関数／確かめるテストを割り当て、全IDに担当があることを確認する。

## 9. ID体系（要求・設計・テストをつなぐ）
- 要求ID（REQ-x.x）：要求仕様書が幹。唯一の採番元。大・中・小の階層。
- 設計ID（DES-）：関数を一意に指す。モジュール大・関数中（core→DES-C01…／ui→DES-U01…／models→DES-M01…）。
- テストID（V-）：観点を主軸に振る（V-01…）。種類（単体／結合／手動）は観点の属性（列）にし、分類軸にしない
  （1観点が単体と手動にまたがるため）。
- 3者は多対多（1関数が複数要求／1要求に複数関数）。番号一致では表せず、トレーサビリティマトリクスで結ぶ。
- コードに刻む：実装の関数は「@id: DES-Cxx ＋ @spec: REQ-x.x（一言）」、テストは「@id: V-xx ＋ @verify: REQ-x.x（一言）」。
  タグは関数の本体の中の「# コメント行」に書く（docstring の中には書かない。整合チェックが拾えず未検証と誤判定される）。1行に1つのIDだけ（複数は行を分ける）。

## 10. 変更するとき（版を上げる）── 既存を壊さず差分を積む
確定版ができたあと、7の「次バージョンで検討」とした宿題や、新しい要望を取り込むときの約束。
初版を新規に作るときは、この章は該当しない（版を上げる元がないため）。
- 各仕様書は自分の版を持つ。変更のたびに版番号を一つ上げる（要求仕様書 第N版→第N+1版。
  設計仕様書・テスト設計仕様書も同様）。設計・テストの仕様書には、対応する要求仕様書の版を
  併記する（どの要求版に紐づくかを残す）。変更後の要求仕様書の次版を、新たな確定版として扱う
  （8の「確定版とみなす」は、その時点の最新版を指す）。
- 既存のIDは振り直さない（REQ・DES・V すべて）。番号は資産。変えると過去のトレーサビリティが切れる。
- 足すIDは、既存の続き番号で起こす。
- やめるIDは、行を消さず「廃止」と印を付け、理由を一言添える（過去のロットや記録から辿れるように）。
- 意味が変わるIDは、原則 旧IDを「廃止」にし、新IDを起こす。
  単なる文言の整理（意味は同じ）は、同一IDのまま直す。
- 既存の関数の契約（名前・引数・戻り値）は、変更対象に挙がらないかぎり変えない。既存の通っている
  テストが、そのまま通り続けることを前提に置く（リグレッションを起こさない）。契約を変えるしか
  ないときは、勝手に変えず、なぜ必要か・どの既存テストに波及するかを報告して止まる。
- 変更は「外側／内側」で進め方を分ける（リスクで仕分け＝7の影響度と同じ考え）。
  ・外側＝表示・レイアウト・グラフの形など、間違っても目で気づけるもの。対応箇所を直接直し、
    結果を上流の仕様書へ一行追記する（差分の逆輸入）。設計・テストは作り直さない。
  ・内側＝計算・判定・入力定義など、間違っても静かに通ってしまうもの。要求仕様書から見直し、
    設計・テストの仕様書も版を上げて改訂する。
- 各フェーズの変更は、最初に差分サマリーを出す：追加したID／廃止したID（理由）／
  記述だけ直したID／波及した既存の範囲。波及しない箇所は触らない（最小構成）。

設計のプロンプトには、要求の第2版と、確定済みの設計の第1版を一緒に渡します。プロンプトは要求の差分を読み取り、増えた機能に対応する関数だけを足してきます。今回でいえば、規格値を読む関数、規格がロット間で食い違っていないか検査する関数、統計量を計算する関数、フォルダの種別を判定してバッチで回す関数。これらに新しい設計ID（DES-）を続き番号で振ります。

ここで肝心なのが、既存の関数の取り決め（名前・受け取る引数・返す値）を変えないことです。たとえばExcelを書き出す関数には統計量の欄を足す必要がありますが、新しい引数は「省略してもよい」形で追加します。こうすると、これまでこの関数を呼んでいた箇所は、引数を渡さなければ前のとおりに動きます。前から動いていた部分の取り決めを動かさないからこそ、次に見るテストで、前の機能が壊れていないことを確かめられます。

テスト仕様書変更のプロンプト

あなたは非エンジニアの開発相談相手です。
すでにあるテスト設計仕様書を出発点に、更新された要求・設計の差分に対応するテストだけを積み増し、
版番号を一つ上げた更新版のテスト設計仕様書（.docx）を作ってください。
設計の基礎、とくに「1. 独立性」（実コードを見ない・走らせない、期待値は要求仕様書の計算例に紐づける）と
「10. 変更するとき（版を上げる）」の共通ルールを、すべて守ります。
このプロンプトには、テストフェーズ固有のことだけを書きます。共通の原則は設計の基礎を見てください。
判断の根拠は、添付の文書とデータ（更新後の要求仕様書・更新後の設計仕様書・現行のテスト設計仕様書・
入力サンプル・出力完成ファイル・設計の基礎）だけにし、会話の記憶を根拠にしない。Excel 等は実際に開いて確かめる。

【最初にやること】
添付の「更新後の要求仕様書」「更新後の設計仕様書」「現行のテスト設計仕様書」「設計の基礎」を読む。
現行のテスト設計の版番号を確認する（冒頭に、対応する要求・設計の版も記録する）。
要求・設計の差分（追加・廃止・意味変更のID）を特定し、現状のテストの骨格を5〜6行で要約して見せる。

【このフェーズでやること】
- 要求・設計の差分に対応するテストだけを、追加・変更・廃止する。変わっていないテストは据え置く。
- 外側（表示・グラフの形）は、手動確認の観点を一行更新する程度。
  内側（計算・判定・入力定義）は、観点・入力・期待値を、テストを書ける粒度まで詰める。
  期待値は、更新後の要求仕様書の計算例（人間が確認済みの正解）に紐づける（実コード・実装を見ない＝基礎1）。
- 既存の通っているテストは、そのまま緑のまま（基礎10のリグレッション）。差分対象のテストだけを赤→緑にする。
  既存テストの assert・期待値は触らない。
- 新しい観点にテストID（V-）を続き番号で振る。やめる観点は行を消さず「廃止」＋理由を添える（基礎10）。
- トレーサビリティマトリクスを更新し、新しい要求IDすべてにテストが割り当たっているか確認する。
  手動確認に逃がしてよいのは純粋な画面操作だけ（判断はコア関数として自動テスト＝基礎3）。
- 要求の「やらないこと」はテストしない。

【書き終えたら自己チェック】
- この次版だけで、追加・変更された要求のテストが書けるか。
- 変えていない既存テストが、現行から動いていないか（そのまま緑で通り続ける形か）。

【出力】（基礎10の差分サマリー → 本体 の順）
1. テストの差分サマリー（追加V／廃止V＋理由／記述だけ更新したID／対応する要求・設計ID／外側・内側／波及した既存範囲）。
2. 版番号を一つ上げた更新版のテスト設計仕様書（.docx。現行の章立てを保ち、変えた箇所だけ更新。
   冒頭に版番号・更新履歴・対応する要求・設計の版）。
3. テストコード（.py。pytest・@id／@verify付き）。現行のテストコードを出発点に、差分のテストだけを足す
   （白紙で起こさない。既存テストは触らない＝基礎10）。テストは1ファイルのまま増やさない（基礎4。
   版フォルダ方式では、現行版を複製した次版フォルダの中の1ファイルに差分を足す）。
4. トレーサビリティマトリクス（.xlsx）を更新（追加・廃止を反映。多対多なので表の行で結ぶ）。

あなたは非エンジニアの開発相談相手です。
すでにあるテスト設計仕様書を出発点に、更新された要求・設計の差分に対応するテストだけを積み増し、
版番号を一つ上げた更新版のテスト設計仕様書（.docx）を作ってください。
設計の基礎、とくに「1. 独立性」（実コードを見ない・走らせない、期待値は要求仕様書の計算例に紐づける）と
「10. 変更するとき（版を上げる）」の共通ルールを、すべて守ります。
このプロンプトには、テストフェーズ固有のことだけを書きます。共通の原則は設計の基礎を見てください。
判断の根拠は、添付の文書とデータ（更新後の要求仕様書・更新後の設計仕様書・現行のテスト設計仕様書・
入力サンプル・出力完成ファイル・設計の基礎）だけにし、会話の記憶を根拠にしない。Excel 等は実際に開いて確かめる。

【最初にやること】
添付の「更新後の要求仕様書」「更新後の設計仕様書」「現行のテスト設計仕様書」「設計の基礎」を読む。
現行のテスト設計の版番号を確認する（冒頭に、対応する要求・設計の版も記録する）。
要求・設計の差分（追加・廃止・意味変更のID）を特定し、現状のテストの骨格を5〜6行で要約して見せる。

【このフェーズでやること】
- 要求・設計の差分に対応するテストだけを、追加・変更・廃止する。変わっていないテストは据え置く。
- 外側（表示・グラフの形）は、手動確認の観点を一行更新する程度。
  内側（計算・判定・入力定義）は、観点・入力・期待値を、テストを書ける粒度まで詰める。
  期待値は、更新後の要求仕様書の計算例（人間が確認済みの正解）に紐づける（実コード・実装を見ない＝基礎1）。
- 既存の通っているテストは、そのまま緑のまま（基礎10のリグレッション）。差分対象のテストだけを赤→緑にする。
  既存テストの assert・期待値は触らない。
- 新しい観点にテストID（V-）を続き番号で振る。やめる観点は行を消さず「廃止」＋理由を添える（基礎10）。
- トレーサビリティマトリクスを更新し、新しい要求IDすべてにテストが割り当たっているか確認する。
  手動確認に逃がしてよいのは純粋な画面操作だけ（判断はコア関数として自動テスト＝基礎3）。
- 要求の「やらないこと」はテストしない。

【書き終えたら自己チェック】
- この次版だけで、追加・変更された要求のテストが書けるか。
- 変えていない既存テストが、現行から動いていないか（そのまま緑で通り続ける形か）。

【出力】（基礎10の差分サマリー → 本体 の順）
1. テストの差分サマリー（追加V／廃止V＋理由／記述だけ更新したID／対応する要求・設計ID／外側・内側／波及した既存範囲）。
2. 版番号を一つ上げた更新版のテスト設計仕様書（.docx。現行の章立てを保ち、変えた箇所だけ更新。
   冒頭に版番号・更新履歴・対応する要求・設計の版）。
3. テストコード（.py。pytest・@id／@verify付き）。現行のテストコードを出発点に、差分のテストだけを足す
   （白紙で起こさない。既存テストは触らない＝基礎10）。テストは1ファイルのまま増やさない（基礎4。
   版フォルダ方式では、現行版を複製した次版フォルダの中の1ファイルに差分を足す）。
4. トレーサビリティマトリクス（.xlsx）を更新（追加・廃止を反映。多対多なので表の行で結ぶ）。

設計の基礎（テスト変更のプロンプトと同時にわたす）

# 設計の基礎（このプロジェクトの共通ルール）

設計・テスト設計・実装の全フェーズで守る、共通の原則。
各フェーズのプロンプトは、このファイルを一緒に渡して「設計の基礎に従う」として参照する。

## 1. 設計とテストは独立に作る（独立性）
- 各フェーズは、前フェーズの成果物（要求仕様書・設計仕様書などの文書）だけを唯一の入力とする。
  会話の履歴・記憶を根拠にしない。穴・確定待ち・矛盾の判断も、渡された文書に書いてあるか・いないか
  だけで決める。「前に会話でこう言った」を持ち出すと、確定済みの事項を曖昧と誤判定したり、
  文書に無い穴を作り出したりする（幻の穴）。だから各フェーズは独立したチャットで行う。
- 設計仕様書には実装の中身（コード）を書かない。書くのは日本語の手順と、各関数の取り決めだけ。
- テストは、実コードを見ず・走らせず、設計の取り決めと要求仕様書の期待値から書く。
- テストとコードは、実装フェーズで初めて出会う（pytest 実行）。これで「動く」でなく「正しい」を確かめる。
- テストの期待値は、要求仕様書の計算例（人間が確認済みの正解）に紐づける。コードから逆算しない。

## 2. 取り決め（関数の入口と出口の約束）は物理表現まで定義する
各関数の取り決め（名前・受け取るもの・返すもの）には、テスト設計者がこれだけでテストを書ける粒度まで：
- 関数名・引数（名前と型）・戻り値
- 戻り値や受け渡すデータの物理表現：dataclass か dict か、フィールドの英語名と型
  （例：LotResult は dataclass。属性 lot_no:str, mean:float, status:str）
- モジュール構成：ファイル名＝import名（例：コアは core.py ＝ import core）
- 値の決まり：日付の入力形式、丸めの桁、状態を表す文字列の値（"採用"／"除外" など）
取り決めが曖昧だと、テストを書く人と実装する人が別々の名前・戻り値を想定して噛み合わない。
中身（アルゴリズム）は書かず、表面の取り決め（何を受け取り何を返すか）は具体的に共有する。

## 3. UIに判断を置かない
- コア（計算・判定）とUI（画面）は役割を分ける。UIはコアを呼ぶだけ。
- 判断（中断する／警告する／弾く／続行する など）は、画面のボタンやイベントに紐づくものでも、
  コア側の関数に切り出す。UIはそれを呼んで結果を表示するだけ。
- UIに残してよいのは、純粋な画面操作（要素の配置・表示・入力の受け渡し）だけ。
- 守らないと、判断がUIに埋もれて自動テストできず、「画面操作だから手動確認」で逃げてしまう。

## 4. ファイルは増やしすぎない
- 原則 models（データ構造）・core（読み込み・計算・判定・出力の全関数）・ui（画面）の3つに収める。
- 設定値（しきい値など）が多ければ config を足してよい。
- 「関心を関数で分ける」ことと「ファイルを分ける」ことは別もの。reader／validator／writer のように
  機能ごとにファイルを増やさない。役割ごとの関数はコメントで区切って同じ core に並べる。
- テストも同じ。tests/ は原則 test_対象.py の1ファイルにまとめ、観点が増えても機能ごと・版ごとに
  ファイルを分けない（フィクスチャ・定数・ビルダーの重複を防ぎ、全観点を1ファイルで一望できる）。
  既存の運用中テストへ後から足す変更フェーズ（基礎10）だけは、この限りではない。

## 5. 正常系以外を必ず定義する
正常に動く場合だけでなく、次の5つを定義する（抜けると実装もテストも決められない）：
- 失敗・例外の経路：開けない・壊れている・権限がない・想定外の構造のとき、例外を投げるのか、
  エラーを表す戻り値（status 等）に畳むのか。技術的な失敗（I/O・破損・ロック）も。
- 値の境界・特殊値：空・欠損・非数値・エラー値・ゼロ・極端な値のとき、どう扱うか。
- 状態とデータの整合：ある状態（不整合・除外など）のとき、保持するデータの中身は何か。
- 件数・重複の境界：0件・1件・重複のとき、どうふるまうか。キーが衝突したら誰がどう止めるか。
- 結果に影響する技術前提：ライブラリの動作モードで結果が変わる箇所は前提を明記
  （例：Excel を数式の文字列で読むのか、計算済みの値で読むのか）。

## 6. 検証できる形になっているか
- 各要求を検証する情報が、関数の戻り値やデータ構造に乗っているか。乗っていなければ、
  実装が何を入れても通ってしまう（＝検証不能）。例：「不整合のセル番地を報告する」要求なのに、
  抽出関数が値しか返さず番地を持たないなら、その要求はどの戻り値からも確かめられない。
- 本文と、データ構造・対応表が、互いに矛盾していないか。

## 7. 確定待ち（勝手に埋めない・リスクで仕分ける）
- 決められない点は、勝手に仮定で埋めず「確定待ち」として、何を決めれば埋まるかと一緒に明記する。
- それが本来は要求仕様書にあるべき穴（様式・ふるまい）なら、要求側の穴である旨を明記する。
- 各確定待ちに、リスクの大きさを添える。リスクは「影響度 × 発生頻度」で見積もる。
  ・影響度：大＝間違った結果が正しく見えるまま出る（静かなデータ破損）／中＝目に見えて止まる
    （気づける失敗）／小＝見た目が変わる程度。
  ・発生頻度：正しく運用されたデータで、どれくらい起きるか（よく／たまに／ほぼ起きない）。
    頻度は要求の文言だけで決めず、添付された実データ（入力サンプル・完成ファイル）を実際に見て
    見積もる。実データで起こりうるか確かめてから強度を決める（例：要求に「表記ゆれを正規化」とあっても、
    添付サンプルにゆれが無ければ頻度は「ほぼ起きない」）。実データを見れば消えるリスクを文言だけで
    過大計上しない。確かめる実データが無ければ【未検証】と明記する。
- リスク大→要求仕様書に戻って定義／リスク中→既定で進め次バージョンで検討と記録／
  リスク小→既定のままでよい（要求に戻さない）。最終判断は人間。
- 全部を要求仕様書に戻さない。リスクと労力で線を引く。静かなデータ破損（影響度大）だけは、
  頻度が低くても軽視しない。

## 8. 要求とのつながり
- 要求仕様書は仕上げ確認を通った確定版とみなす。要求で決まっていることは再確認しない。
- 要求IDごとに、それを実現する関数／確かめるテストを割り当て、全IDに担当があることを確認する。

## 9. ID体系（要求・設計・テストをつなぐ）
- 要求ID（REQ-x.x）：要求仕様書が幹。唯一の採番元。大・中・小の階層。
- 設計ID（DES-）：関数を一意に指す。モジュール大・関数中（core→DES-C01…／ui→DES-U01…／models→DES-M01…）。
- テストID（V-）：観点を主軸に振る（V-01…）。種類（単体／結合／手動）は観点の属性（列）にし、分類軸にしない
  （1観点が単体と手動にまたがるため）。
- 3者は多対多（1関数が複数要求／1要求に複数関数）。番号一致では表せず、トレーサビリティマトリクスで結ぶ。
- コードに刻む：実装の関数は「@id: DES-Cxx ＋ @spec: REQ-x.x（一言）」、テストは「@id: V-xx ＋ @verify: REQ-x.x（一言）」。
  タグは関数の本体の中の「# コメント行」に書く（docstring の中には書かない。整合チェックが拾えず未検証と誤判定される）。1行に1つのIDだけ（複数は行を分ける）。

## 10. 変更するとき（版を上げる）── 既存を壊さず差分を積む
確定版ができたあと、7の「次バージョンで検討」とした宿題や、新しい要望を取り込むときの約束。
初版を新規に作るときは、この章は該当しない（版を上げる元がないため）。
- 各仕様書は自分の版を持つ。変更のたびに版番号を一つ上げる（要求仕様書 第N版→第N+1版。
  設計仕様書・テスト設計仕様書も同様）。設計・テストの仕様書には、対応する要求仕様書の版を
  併記する（どの要求版に紐づくかを残す）。変更後の要求仕様書の次版を、新たな確定版として扱う
  （8の「確定版とみなす」は、その時点の最新版を指す）。
- 既存のIDは振り直さない（REQ・DES・V すべて）。番号は資産。変えると過去のトレーサビリティが切れる。
- 足すIDは、既存の続き番号で起こす。
- やめるIDは、行を消さず「廃止」と印を付け、理由を一言添える（過去のロットや記録から辿れるように）。
- 意味が変わるIDは、原則 旧IDを「廃止」にし、新IDを起こす。
  単なる文言の整理（意味は同じ）は、同一IDのまま直す。
- 既存の関数の契約（名前・引数・戻り値）は、変更対象に挙がらないかぎり変えない。既存の通っている
  テストが、そのまま通り続けることを前提に置く（リグレッションを起こさない）。契約を変えるしか
  ないときは、勝手に変えず、なぜ必要か・どの既存テストに波及するかを報告して止まる。
- 変更は「外側／内側」で進め方を分ける（リスクで仕分け＝7の影響度と同じ考え）。
  ・外側＝表示・レイアウト・グラフの形など、間違っても目で気づけるもの。対応箇所を直接直し、
    結果を上流の仕様書へ一行追記する（差分の逆輸入）。設計・テストは作り直さない。
  ・内側＝計算・判定・入力定義など、間違っても静かに通ってしまうもの。要求仕様書から見直し、
    設計・テストの仕様書も版を上げて改訂する。
- 各フェーズの変更は、最初に差分サマリーを出す：追加したID／廃止したID（理由）／
  記述だけ直したID／波及した既存の範囲。波及しない箇所は触らない（最小構成）。

# 設計の基礎（このプロジェクトの共通ルール）

設計・テスト設計・実装の全フェーズで守る、共通の原則。
各フェーズのプロンプトは、このファイルを一緒に渡して「設計の基礎に従う」として参照する。

## 1. 設計とテストは独立に作る（独立性）
- 各フェーズは、前フェーズの成果物（要求仕様書・設計仕様書などの文書）だけを唯一の入力とする。
  会話の履歴・記憶を根拠にしない。穴・確定待ち・矛盾の判断も、渡された文書に書いてあるか・いないか
  だけで決める。「前に会話でこう言った」を持ち出すと、確定済みの事項を曖昧と誤判定したり、
  文書に無い穴を作り出したりする（幻の穴）。だから各フェーズは独立したチャットで行う。
- 設計仕様書には実装の中身（コード）を書かない。書くのは日本語の手順と、各関数の取り決めだけ。
- テストは、実コードを見ず・走らせず、設計の取り決めと要求仕様書の期待値から書く。
- テストとコードは、実装フェーズで初めて出会う（pytest 実行）。これで「動く」でなく「正しい」を確かめる。
- テストの期待値は、要求仕様書の計算例（人間が確認済みの正解）に紐づける。コードから逆算しない。

## 2. 取り決め（関数の入口と出口の約束）は物理表現まで定義する
各関数の取り決め（名前・受け取るもの・返すもの）には、テスト設計者がこれだけでテストを書ける粒度まで：
- 関数名・引数（名前と型）・戻り値
- 戻り値や受け渡すデータの物理表現：dataclass か dict か、フィールドの英語名と型
  （例：LotResult は dataclass。属性 lot_no:str, mean:float, status:str）
- モジュール構成：ファイル名＝import名（例：コアは core.py ＝ import core）
- 値の決まり：日付の入力形式、丸めの桁、状態を表す文字列の値（"採用"／"除外" など）
取り決めが曖昧だと、テストを書く人と実装する人が別々の名前・戻り値を想定して噛み合わない。
中身（アルゴリズム）は書かず、表面の取り決め（何を受け取り何を返すか）は具体的に共有する。

## 3. UIに判断を置かない
- コア（計算・判定）とUI（画面）は役割を分ける。UIはコアを呼ぶだけ。
- 判断（中断する／警告する／弾く／続行する など）は、画面のボタンやイベントに紐づくものでも、
  コア側の関数に切り出す。UIはそれを呼んで結果を表示するだけ。
- UIに残してよいのは、純粋な画面操作（要素の配置・表示・入力の受け渡し）だけ。
- 守らないと、判断がUIに埋もれて自動テストできず、「画面操作だから手動確認」で逃げてしまう。

## 4. ファイルは増やしすぎない
- 原則 models（データ構造）・core（読み込み・計算・判定・出力の全関数）・ui（画面）の3つに収める。
- 設定値（しきい値など）が多ければ config を足してよい。
- 「関心を関数で分ける」ことと「ファイルを分ける」ことは別もの。reader／validator／writer のように
  機能ごとにファイルを増やさない。役割ごとの関数はコメントで区切って同じ core に並べる。
- テストも同じ。tests/ は原則 test_対象.py の1ファイルにまとめ、観点が増えても機能ごと・版ごとに
  ファイルを分けない（フィクスチャ・定数・ビルダーの重複を防ぎ、全観点を1ファイルで一望できる）。
  既存の運用中テストへ後から足す変更フェーズ（基礎10）だけは、この限りではない。

## 5. 正常系以外を必ず定義する
正常に動く場合だけでなく、次の5つを定義する（抜けると実装もテストも決められない）：
- 失敗・例外の経路：開けない・壊れている・権限がない・想定外の構造のとき、例外を投げるのか、
  エラーを表す戻り値（status 等）に畳むのか。技術的な失敗（I/O・破損・ロック）も。
- 値の境界・特殊値：空・欠損・非数値・エラー値・ゼロ・極端な値のとき、どう扱うか。
- 状態とデータの整合：ある状態（不整合・除外など）のとき、保持するデータの中身は何か。
- 件数・重複の境界：0件・1件・重複のとき、どうふるまうか。キーが衝突したら誰がどう止めるか。
- 結果に影響する技術前提：ライブラリの動作モードで結果が変わる箇所は前提を明記
  （例：Excel を数式の文字列で読むのか、計算済みの値で読むのか）。

## 6. 検証できる形になっているか
- 各要求を検証する情報が、関数の戻り値やデータ構造に乗っているか。乗っていなければ、
  実装が何を入れても通ってしまう（＝検証不能）。例：「不整合のセル番地を報告する」要求なのに、
  抽出関数が値しか返さず番地を持たないなら、その要求はどの戻り値からも確かめられない。
- 本文と、データ構造・対応表が、互いに矛盾していないか。

## 7. 確定待ち（勝手に埋めない・リスクで仕分ける）
- 決められない点は、勝手に仮定で埋めず「確定待ち」として、何を決めれば埋まるかと一緒に明記する。
- それが本来は要求仕様書にあるべき穴（様式・ふるまい）なら、要求側の穴である旨を明記する。
- 各確定待ちに、リスクの大きさを添える。リスクは「影響度 × 発生頻度」で見積もる。
  ・影響度：大＝間違った結果が正しく見えるまま出る（静かなデータ破損）／中＝目に見えて止まる
    （気づける失敗）／小＝見た目が変わる程度。
  ・発生頻度：正しく運用されたデータで、どれくらい起きるか（よく／たまに／ほぼ起きない）。
    頻度は要求の文言だけで決めず、添付された実データ（入力サンプル・完成ファイル）を実際に見て
    見積もる。実データで起こりうるか確かめてから強度を決める（例：要求に「表記ゆれを正規化」とあっても、
    添付サンプルにゆれが無ければ頻度は「ほぼ起きない」）。実データを見れば消えるリスクを文言だけで
    過大計上しない。確かめる実データが無ければ【未検証】と明記する。
- リスク大→要求仕様書に戻って定義／リスク中→既定で進め次バージョンで検討と記録／
  リスク小→既定のままでよい（要求に戻さない）。最終判断は人間。
- 全部を要求仕様書に戻さない。リスクと労力で線を引く。静かなデータ破損（影響度大）だけは、
  頻度が低くても軽視しない。

## 8. 要求とのつながり
- 要求仕様書は仕上げ確認を通った確定版とみなす。要求で決まっていることは再確認しない。
- 要求IDごとに、それを実現する関数／確かめるテストを割り当て、全IDに担当があることを確認する。

## 9. ID体系（要求・設計・テストをつなぐ）
- 要求ID（REQ-x.x）：要求仕様書が幹。唯一の採番元。大・中・小の階層。
- 設計ID（DES-）：関数を一意に指す。モジュール大・関数中（core→DES-C01…／ui→DES-U01…／models→DES-M01…）。
- テストID（V-）：観点を主軸に振る（V-01…）。種類（単体／結合／手動）は観点の属性（列）にし、分類軸にしない
  （1観点が単体と手動にまたがるため）。
- 3者は多対多（1関数が複数要求／1要求に複数関数）。番号一致では表せず、トレーサビリティマトリクスで結ぶ。
- コードに刻む：実装の関数は「@id: DES-Cxx ＋ @spec: REQ-x.x（一言）」、テストは「@id: V-xx ＋ @verify: REQ-x.x（一言）」。
  タグは関数の本体の中の「# コメント行」に書く（docstring の中には書かない。整合チェックが拾えず未検証と誤判定される）。1行に1つのIDだけ（複数は行を分ける）。

## 10. 変更するとき（版を上げる）── 既存を壊さず差分を積む
確定版ができたあと、7の「次バージョンで検討」とした宿題や、新しい要望を取り込むときの約束。
初版を新規に作るときは、この章は該当しない（版を上げる元がないため）。
- 各仕様書は自分の版を持つ。変更のたびに版番号を一つ上げる（要求仕様書 第N版→第N+1版。
  設計仕様書・テスト設計仕様書も同様）。設計・テストの仕様書には、対応する要求仕様書の版を
  併記する（どの要求版に紐づくかを残す）。変更後の要求仕様書の次版を、新たな確定版として扱う
  （8の「確定版とみなす」は、その時点の最新版を指す）。
- 既存のIDは振り直さない（REQ・DES・V すべて）。番号は資産。変えると過去のトレーサビリティが切れる。
- 足すIDは、既存の続き番号で起こす。
- やめるIDは、行を消さず「廃止」と印を付け、理由を一言添える（過去のロットや記録から辿れるように）。
- 意味が変わるIDは、原則 旧IDを「廃止」にし、新IDを起こす。
  単なる文言の整理（意味は同じ）は、同一IDのまま直す。
- 既存の関数の契約（名前・引数・戻り値）は、変更対象に挙がらないかぎり変えない。既存の通っている
  テストが、そのまま通り続けることを前提に置く（リグレッションを起こさない）。契約を変えるしか
  ないときは、勝手に変えず、なぜ必要か・どの既存テストに波及するかを報告して止まる。
- 変更は「外側／内側」で進め方を分ける（リスクで仕分け＝7の影響度と同じ考え）。
  ・外側＝表示・レイアウト・グラフの形など、間違っても目で気づけるもの。対応箇所を直接直し、
    結果を上流の仕様書へ一行追記する（差分の逆輸入）。設計・テストは作り直さない。
  ・内側＝計算・判定・入力定義など、間違っても静かに通ってしまうもの。要求仕様書から見直し、
    設計・テストの仕様書も版を上げて改訂する。
- 各フェーズの変更は、最初に差分サマリーを出す：追加したID／廃止したID（理由）／
  記述だけ直したID／波及した既存の範囲。波及しない箇所は触らない（最小構成）。

テストも同じ要領です。確定した前の版のテストを出発点に、増えた要求・設計に対応するテストだけを足します。今回は、規格値の取得、規格の一致検査、統計量の計算、特殊なケース（ばらつきがゼロ、規格が片側）、フォルダ種別の判定、バッチでの繰り返し、サマリーへの統計量の出力——これらに新しいテストID（V-）を続き番号で足しました。前の版のテストには、一切手を加えません。

ここで「動く≠正しい」が効いてきます。たとえばCp・Cpkのテストで、何をもって「正しい」とするか。実装したプログラムが出した数字を正解にしてしまうと、間違った実装を間違ったまま追認することになります。そこで期待値は、要求仕様に書いた計算例——人が手で検算して確かめた数字——に紐づけます。プログラムの出力ではなく、人が確かめた正解と突き合わせる。これが、足した機能が本当に正しいかを見る土台です。

そして、前の版から引き継いだテストを、新しい版でも一緒に走らせます。引き継いだテストがそのまま緑で通れば、3つの機能を足しても前の機能を壊していない、という証拠になります。新しく足したテストが緑になれば、足した機能が正しく動いている。前のぶんと合わせて、両方が緑であることをもって、はじめて「育てたが壊していない」と言えます。これが、場当たりに実装へ足していくやり方との、いちばんの違いです。

版を上げた仕様で実装し、実際に動かしてみる

要求・設計・テストの第2版がそろいました。あとは、この仕様どおりにClaude Codeで実装し、動かして確かめるだけです。ただ、動かしてみて初めて分かったこともありました。順に見ていきます。

仕様をもとに、Claude Codeで実装する

実装は、前回と同じくClaude Codeに任せます。違うのは、白紙のフォルダではなく、前の版を残した上で用意したv2フォルダの中で作業すること、そして渡すのが第2版の設計・テスト仕様だという点です。いきなり書かせず、まず何をどう変えるかの計画（プラン）を立てさせ、それを確認してから実装に進みます。

Claude Code：実装依頼プロンプト

実装プロンプト

docs/ の要求仕様書と設計仕様書を読んでください。CLAUDE.md のルールに従います。
設計仕様書には実装の中身は無く、各関数の契約（名前・引数・戻り値）と日本語の手順があります。
あなたが、その契約と手順に従って中身を実装します。

【テストには触れない（最優先の境界）】
- テストコード（tests/ の test_*.py）は、別の担当（Web Claude）が契約と期待値から独立に書いて、
  すでに配置されています。あなたは、これを書かない・置き直さない・書き換えない。走らせるだけ。
- import が通らないのをテスト側で直そうとしない。import は、あなたが実装側（下記の土台）の
  名前を揃えれば通る。直す向きは常に実装側。テストは正しさの基準なので動かさない。

【まず実装側の土台を置く（中身は書かない）】
- 設計仕様書の物理表現（2-5）の全データ構造（dataclass など）を、そのまま models 等に置く。
- 設計仕様書の全関数を、契約どおりの「空のシグネチャ」で置く（中身は実装せず、NotImplementedError
  を投げるだけ）。この土台には @spec を付けない（まだ何も実現していないため）。
- これで、既に配置されているテストの import が通り、全テストが「赤（失敗）」で始まる。
  ここが正しい出発点。配置するのは models と空シグネチャだけ。テストファイルは触らない。

【ここから中身を実装する（依存順・大項目の節目で報告）】
- 中項目（REQ-x.x）を、依存順で実装する。依存順とは、他の関数に依存される下位のロジック
  （読み込み・計算の土台）を先に、それを使う上位（集約・UI）を後に、の順。
- 設計仕様書の関数の契約（名前・引数・戻り値）のとおりに中身を実装する（契約は変えない）。
- 実装した関数に、設計ID（@id）と要求ID（@spec）を併記する
  （# @id: DES-Cxx ／ # @spec: REQ-1.1.1 tkinterの画面を表示する。設計IDは設計仕様書の
  設計ID一覧で関数名と突き合わせる）。空シグネチャの段階では付けない。
- 要求IDに対応しない土台の行には、3点ルール（いつ・どうする・無いと何が起きるか）の
  日本語コメントを書く。
- 各中項目を実装したら、その REQ のテストを走らせて「赤→緑」を確認しながら進む。中項目ごとには
  止まらない。**大項目（REQ-2／REQ-3／REQ-4・5 などの節目）まで実装したら、そこで一度止まる**。
  節目では、その大項目に含まれるテストが全部緑になったか、psdd.py extract と psdd.py check の結果を
  まとめて報告する。
- ただし、次のときは節目を待たず、すぐ止まって報告する（安全弁）：
  ・契約どおり実装したのにテストが赤のまま通らない（契約かテストが仕様を取り違えているサイン）。
  ・仕様に書かれていない判断が必要になった。
  ・テストを通すにはテストか契約を変えるしかない、と感じた（変えてはいけないので必ず止まる）。
仕様に書かれていない判断が必要なときは、勝手に決めず、止まって質問してください。

docs/ の要求仕様書と設計仕様書を読んでください。CLAUDE.md のルールに従います。
設計仕様書には実装の中身は無く、各関数の契約（名前・引数・戻り値）と日本語の手順があります。
あなたが、その契約と手順に従って中身を実装します。

【テストには触れない（最優先の境界）】
- テストコード（tests/ の test_*.py）は、別の担当（Web Claude）が契約と期待値から独立に書いて、
  すでに配置されています。あなたは、これを書かない・置き直さない・書き換えない。走らせるだけ。
- import が通らないのをテスト側で直そうとしない。import は、あなたが実装側（下記の土台）の
  名前を揃えれば通る。直す向きは常に実装側。テストは正しさの基準なので動かさない。

【まず実装側の土台を置く（中身は書かない）】
- 設計仕様書の物理表現（2-5）の全データ構造（dataclass など）を、そのまま models 等に置く。
- 設計仕様書の全関数を、契約どおりの「空のシグネチャ」で置く（中身は実装せず、NotImplementedError
  を投げるだけ）。この土台には @spec を付けない（まだ何も実現していないため）。
- これで、既に配置されているテストの import が通り、全テストが「赤（失敗）」で始まる。
  ここが正しい出発点。配置するのは models と空シグネチャだけ。テストファイルは触らない。

【ここから中身を実装する（依存順・大項目の節目で報告）】
- 中項目（REQ-x.x）を、依存順で実装する。依存順とは、他の関数に依存される下位のロジック
  （読み込み・計算の土台）を先に、それを使う上位（集約・UI）を後に、の順。
- 設計仕様書の関数の契約（名前・引数・戻り値）のとおりに中身を実装する（契約は変えない）。
- 実装した関数に、設計ID（@id）と要求ID（@spec）を併記する
  （# @id: DES-Cxx ／ # @spec: REQ-1.1.1 tkinterの画面を表示する。設計IDは設計仕様書の
  設計ID一覧で関数名と突き合わせる）。空シグネチャの段階では付けない。
- 要求IDに対応しない土台の行には、3点ルール（いつ・どうする・無いと何が起きるか）の
  日本語コメントを書く。
- 各中項目を実装したら、その REQ のテストを走らせて「赤→緑」を確認しながら進む。中項目ごとには
  止まらない。**大項目（REQ-2／REQ-3／REQ-4・5 などの節目）まで実装したら、そこで一度止まる**。
  節目では、その大項目に含まれるテストが全部緑になったか、psdd.py extract と psdd.py check の結果を
  まとめて報告する。
- ただし、次のときは節目を待たず、すぐ止まって報告する（安全弁）：
  ・契約どおり実装したのにテストが赤のまま通らない（契約かテストが仕様を取り違えているサイン）。
  ・仕様に書かれていない判断が必要になった。
  ・テストを通すにはテストか契約を変えるしかない、と感じた（変えてはいけないので必ず止まる）。
仕様に書かれていない判断が必要なときは、勝手に決めず、止まって質問してください。

テスト実装プロンプト

tests/ に、Web Claude が契約と期待値から書いたテストコード（test_*.py）が配置されています。
あなたはそれを書き換えず、実装した実コードに対して pytest で走らせてください。
- テストの期待値や assert を、通すために緩めない。テストもコードも甘くしない。
- 落ちたら、(a) 実装が契約や仕様を外したか、(b) テストの期待値が仕様を読み違えたか、を
  切り分けて報告する。自分でどちらかを勝手に直さず、まず報告する。
- psdd.py check を実行し、@verify と @spec が spec_ids.json と合うか、未検証のIDが無いかを報告する。
テストを通すこと自体を目的にしない。目的は、実コードが仕様どおりかを確かめることです。

tests/ に、Web Claude が契約と期待値から書いたテストコード（test_*.py）が配置されています。
あなたはそれを書き換えず、実装した実コードに対して pytest で走らせてください。
- テストの期待値や assert を、通すために緩めない。テストもコードも甘くしない。
- 落ちたら、(a) 実装が契約や仕様を外したか、(b) テストの期待値が仕様を読み違えたか、を
  切り分けて報告する。自分でどちらかを勝手に直さず、まず報告する。
- psdd.py check を実行し、@verify と @spec が spec_ids.json と合うか、未検証のIDが無いかを報告する。
テストを通すこと自体を目的にしない。目的は、実コードが仕様どおりかを確かめることです。

実装で大事にしたのは、前の版から動いていた部分のコードに、できるだけ手を入れないことです。設計の段階で、既存の関数の取り決め（名前・引数・戻り値）を変えない方針にしてあったので、Claude Codeも、既存の処理はそのまま残し、新しい関数を足す形で実装してくれました。

完了報告ではなく、ログを見て初めて気づいたこと

実装は問題なく終わり、Claude Codeからは「テストはすべて緑」という完了報告が返ってきました。数字の上では成功です。ところが、念のため作業のログをたどっていて、報告には出てこない変更が一つ混じっていることに気づきました。今回足したかった3つの機能とは関係のない、既存の読み取りロジックが、書き換えられていました。

中身はこうでした。Cp・Cpkのために各様式のExcelに規格欄を追記したとき、C様式は集計ブロックの並びが変わり、平均値の入るセルが前の版から動いていました。この入力の変化に合わせて、平均を読む場所を直す必要が生じていた。実は、この修正自体は設計仕様にもテストにも、変更点として書かれていました。だからClaude Codeは設計どおりに、既存の読み取りを書き換え、対応するテストを緑にした。指示を破ったわけではありません。

もとをたどれば、これは上流の見落としです。規格欄を足したことでC様式の並びが変わる——この入力データの変化を、変更の問診（足したい機能を聞く問い）の中に項目として置いていませんでした。入力が変われば、それを読む既存の処理も変わります。なぜ見落としたのか、どう防ぐのかは、最後のまとめで振り返ります。

MATSU

端的に言えば要求仕様になくて、設計、テスト仕様書には存在した変更があったということになります。原因は要求変更の段階で、サンプルデータの引き渡しをしなかったことになります。

テストを通し、まとめて処理とCp・Cpkを実機で動かす

ログで見つけた変更の中身を確認し、これでよいと判断したうえで、改めてテストを見ます。v2のフォルダでテストを走らせると、前の版から引き継いだ37本と、今回足した11本が、まとめて実行されます。引き継いだ37本がそのまま緑で通れば、3つの機能を足しても前の機能を壊していない、という証拠です。そのうえで、足した11本も緑になれば、新しい機能が仕様どおり正しく動いていることになります。

テストが通ったら、最後は実機です。テストでは確かめにくい、画面の操作と見た目を、実際に動かして目で確認します。親フォルダを一つ選んで、配下の複数品目がまとめて処理され、最後に結果がまとめて報告されること。出てきたExcelのサマリーに、平均・標準偏差・分散・Cp・Cpkが並んでいること。グラフが点だけになり、両軸にラベルと目盛りが出ていること。

テストで中身の正しさを固め、実機で見た目と操作を確かめる。この二段構えで、3つの機能を足したツールが、前の機能を保ったまま、ひととおり動くところまで来ました。

仕様書のダウンロード

参考までに作成したv2の仕様書をダウンロードできるようにしてあります。

仕様書_v2のまとめ.zip

使いながら育てる——今回の課題と、次の改善

3つの機能を足して、ツールはひととおり動くようになりました。ただ、今回の作業の中で、進め方そのものに一つ課題が見つかりました。先にそれを共有してから、これからの育て方の話に移ります。

要求仕様と中身がずれないように、変えた実物データも一緒に渡す

今回の見落としは、こうでした。Cp・Cpkのために検査成績書へ規格欄を足したところ、その副作用でC様式の並びが変わり、平均値の入る位置が動きました。ところが、要求仕様を変える段階で、その変更後の実物のExcelを渡していませんでした。だから要求を問診で詰めるとき、この位置の変化は表に出ず、設計とコードだけが実物に合わせて先に進みました。

砂糖さん

開発と同時にデモデータを作っていたこの記事ならではの失敗事例ということもありますが。。。

結果として、要求仕様書には古い位置、実際のコードには新しい位置、という食い違いが生まれました。これは見過ごせません。仕様を土台にして「なぜそう作ったか」を後から辿れることが、この進め方のいちばんの価値です。その土台である要求仕様が、現物とずれていたら、辿る先が間違ってしまいます。

原因ははっきりしています。要求を変えるときに、変わった実物のデータを渡していなかったこと。だから教訓も単純です。仕様を変えるときは、変わった実物のデータも一緒に渡す。入力そのものが変わるなら、その変更後のサンプルを要求の段階で渡しておけば、ずれは最初に表へ出て、下流まで持ち越されません。

それでも、もし要求仕様とコードがずれてしまったら。そのときは、Claude Codeにコードと要求仕様の差分を出させ、それをもとに要求仕様の側を直します。新しい機能を足すわけではないので、版を大きく上げるのではなく、小さな修正として要求仕様を実物に合わせ直す。ずれを見つけたら、必ず土台（要求仕様）の側に戻して直す——これが、土台を正しく保つ考え方です。

MATSU

最新版のプロンプト仕様駆動開発ではこの点を修正したものを提供しますので良ければ記事を見てください。

使ってみないと、次の改善点は見えてこない

冒頭の3つの「こうしたい」は、「こうなった」に変わりました。グラフは点だけになり、品目はまとめて処理でき、工程能力も一度に出る。けれど、これでツールが完成したわけではありません。使い続ければ、また次の「ここを直したい」が出てきます。

それでいいのだと思います。使ってみないと、次の不満は見えてきません。そして見えてきた不満は、今回見せた進め方——要求仕様に戻して版を上げ、前の版を壊さずに足す——で、安全に解消できます。一度この流れに乗せてしまえば、ツールは使いながら少しずつ育てていけます。

今回は、1つのフォルダを選んで集計する、単独で完結するツールでした。けれど、自動化できる場所は他にもあります。たとえば、集計したExcelの結果を、そのままWordの報告書に流し込む。複数のソフトをつないで、手で転記していた部分をなくす。こうした連携も、また別の要求から始めて、同じように仕様へ積み上げていけます。一度に大きな仕組みを作ろうとせず、要望を聞きながら、自動化できるところを少しずつ広げていく。これが、現実的なやり方だと思います。