“動いた”と“正しい”は違う ── 発注ツールをテストで検証する（Claude Code・pytest編）

ここまでで、発注ツールは画面までそろい、「動いた」ことは確認しました。でも、立ち止まってほしいんです。「動いた」と「正しい」は、別のこと。たまたま今のデータで動いただけかもしれない。今回は、正常・境界・異常の3つの観点でテストして、この道具を「信頼できる」ところまで引き上げます。その作り方も、正直にお見せします。

1. 「動いた」では、なぜ足りないのか

デモデータを入れて、それらしい表が出た。これは「動いた」です。でも現場のトラブルは、たいてい“普通でない”ところで起きます。在庫がちょうど0になった日、閾値ぴったりの残り日数、列が一つ欠けた壊れたCSV——境界と異常こそが、現場のトラブル源です。

「ちゃんと動くか」を、こういう際どい入力まで含めて確かめる。それがテストです。一度きりの目視ではなく、何度でも自動で再現できる形で残しておく。製造でいう検査・検証と同じ発想ですね。

2. 何をテストするか（2つの層 × 3つの観点）

テストは2つの層で考えます。単体テストは、関数1つの動きを個別に確かめる（掛け算は合っているか、0で切れと判定するか）。結合テストは、3つのCSVを読む→計算する→Excelを出す、までの通し動作を確かめる。部品単位と、組み上げ単位の両方を見るわけです。

そして、それぞれで3つの観点を意識します。

観点	何を試すか	例（このツールなら）
正常値	想定どおりの入力で、正しい答えが出るか	食パン3ロットで強力粉30kg。同じ材料を使う製品はちゃんと合算される
境界値	ぎりぎりの値で、線引きが正しいか	在庫ちょうど0の日を「切れ」とするか。危険閾値ちょうど（残り3日）を危険とするか
異常値	壊れた入力で、黙って誤動作しないか	配合表に無い製品、列が欠けたCSV、Shift_JIS（cp932）のCSV

この観点を、1件ずつの合格基準にまとめたものが、テスト仕様書——いわば「テストのメニュー」です。では、このメニューを、どう作るのか。ここが今回の勘どころです。

3. テスト仕様書の作成ガイド

正直に言います。このメニュー、全部を自分の頭でひねり出したわけではありません。叩き台はWeb Claudeに作らせ、自分は現場の目で検証して、抜けを足した。

テスト仕様書作成の流れ

流れは以下の通りになります。

ここで一つ、大事なところがあります。なぜ、実装したClaude Code自身にテストを書かせるだけではダメなのか。AIは「自分の書いたコードは正しい」前提でテストを書くので、正常系に偏るからです。言ってしまえば、コード生成AIも自分が作ったコードだし、テキストとして残っている部分から考えると大丈夫だろう、と判断してしまう傾向がある。だから、コードを書いたのとは別のWeb Claudeに、要求仕様“だけ”からメニューを作らせる。Web Claudeにはコードの保存がないため、境界も異常も遠慮なく出せます。

そのうえで、最後は現場を知る人は以下の内容が重要と感じます。

テスト仕様書

こうしてできたメニューが、今回配るテスト仕様書です。Web Claudeに同じことを頼めば、あなたのツール用のメニューも作れます。

正直なところ、エンジニアでも手ではここまで書かないことが多いと思います。検査の粒度って一般化できないですし、網羅の深さは、システムの重要度次第です。ただ——叩き台をAIが作るようになって、これまで手書きでは割に合わなかった網羅性が、短時間で手に入るようになった。だから、安全側に倒すコストは小さいんです。

「自分で全部のケースを設計した」とは言いません。叩き台はAI、判断は自分。AI時代の人間の仕事は、作ることから“確認すること”へ移っています。何が壊れるかを知っているのは、その現場で材料を発注してきた人です。どんな事で困ったのか経験することでテストがブラッシュアップされていく。これこそ、AIには代われない価値になります。

4. テスト：Claude Codeで実装・実行する

メニュー（テスト仕様書）が固まったら、PlanモードでClaude Codeに渡して、そのとおりのテストコードを書かせます。実装までできたので、あとは走らせるだけ。途中、コード生成AIからテスト環境の確認と出力形式がWordファイル（.docx）にした場合、追加のライブラリをインストールする必要があると言われました。今回は結果の出力は厳密に問わなかったため、テスト結果をマークダウンファイル（.mdの拡張子）として出力するように指示を出しました。

pytestの実行結果

実際にテストを走らせた結果が、こちらです。

気になるポイントのケース——在庫ちょうど0、閾値ちょうど、未登録製品、壊れたCSV、Shift_JIS——も、すべて緑でした。「動いた」だけでなく、際どいところまで「正しい」と言える状態になりました。このほか、実装側が自動生成した補助テスト（UIスモーク等）も確認しています（PASSED 4／表示環境に依存する1件はSKIPPED・補助扱い）。

1件ずつの明細（25件のID・項目・結果、異常系・境界の結果と所感）は、テスト結果レポートにまとめました。下からダウンロードできます。

5. まとめ

第5回以降（発展編）では、ここまでで気づいた課題——緊急度のしきい値も、選んだ3つのファイルも、毎回やり直しで「覚えていない」。前回の設定を外部のファイルに保存して、次の起動で戻せるようにします。加えて、改善したほうが良い点を追加していきます。

使用しているデータ・製品名・取引先名はすべて架空のものです。コードは解説用の実装例で、各ツールの仕様・料金は記事公開時点のものです。