プログラム未経験からPSDDで作る作業指示書の差し込み生成ツール

Excelに並べた一覧から、Wordの作業指示書を一括で作る道具を、PSDDという進め方で一から作ります。品名やロット番号を1枚ずつ手で打ち直していた作業が、ファイルを2つ選んでボタンを押すだけになります。しかも、出てきた文書が1枚ずつ正しいことを、数の表と突き合わせて確かめます。
PSDDは、プログラムを書けない人でも、正しさを確かめられる道具を作るための手順です。仕様を先に固め、正解となる値を人が決め、実装とテストをAIに任せます。手を動かす相手は2つあります。仕様を一緒に固めるWeb版のClaudeと、実際にコードを書いて動かすClaude Codeです。
PSDDのセットアップ方法は以下のリンクから確認できます。

この記事でつくった各仕様書、デモデータについては最後にダウンロードできます。
※この記事のデータ・品名・数値はすべて架空です。
アプリ作成の全体の流れ
PSDDは、決まった順にフェーズを踏みます。この道具も、次の6ステップで作り、動かして気づいた点をあとから直します。
Web版のClaudeで/psdd+要求仕様とうち、要求の問診を始める。何を作るかを決め、要求仕様書という文書にまとめます。それをシードにして、期待値表、テストコードを順番に作成する。
要求仕様書と、正解を書いた期待値表をもとに、Claude Codeが実装し、テストを走らせます。
テストが通ったら、実際に自分の手で動かして、思ったとおりかを目で確かめます。
動かして気づいた「ここを変えたい」を、思いつきではなく仕様書に書き足します。
変えた分だけをClaude Codeが実装し、元のテストが壊れていないかも含めて確かめます。
もう一度自分の手で動かし、設計意図どおりになったことを確かめて仕上げます。
Web版Claudeを使って、問診から始める仕様書作成
最初にやるのは、コードを書くことではなく、仕様を固めることです。何を作るか(要求)、正しい出力は何か(設計)、それをどう確かめるか(テスト設計)。この3つを、Web版のClaudeに合言葉を送って順に作ります。コードはまだ書きません。
Web Claudeでの対話はモデルOpus 4.8を使用しています。
今回作成するアプリ
Wordテンプレート(.docx)と差し込みリスト(.xlsx)を読み込み、リストの各行をテンプレートに差し込んで、作業指示書の .docx ファイルを一括生成するデスクトップツールを作ります。
製造現場で使う作業指示書を、現在は1枚ずつ手作業でWordファイルとして作成している。ロットごとに製品名・品番・ロット番号・担当者などの値を書き換える作業をアプリとして代替するイメージです。
テンプレートになるWordファイル

差し込むデータが書かれているExcelファイル

データの差し込みが完了したWordファイル

「要求」で要求仕様書を作る
要求フェーズの合言葉は「要求」です。Web版のClaudeに次のように送ります。
/psdd 要求
送ると、Claudeが1つずつ質問してきます。誰が使うのか、入力するファイルは何か、うまくいかない入力が来たらどう扱うか。答えられる範囲で返すだけでよく、技術の用語をこちらから出す必要はありません。聞かれるのは「どう作るか」ではなく「何が欲しいか」なので、プログラムを知らなくても答えられます。
実際の問診で聞かれた項目と、それに答えた内容は次のとおりです。この表と同じように答えれば、似たアプリにたどり着けます。
| 聞かれたこと | 答えた内容 |
|---|---|
| ① 誰のための、何の道具か | 製造現場の担当者向け。作業指示書を一括で作る道具 |
| ② いま何に困っているか | 作業指示書を1枚ずつ手作業でWord作成している。枚数が多いと時間がかかり、転記ミスも起きる |
| ③ この道具で何をしたいか(ゴール) | テンプレートと差し込みリストから、作業指示書をまとめて生成したい |
| ④ なぜ今ある方法では足りないか | Wordの差し込み印刷はあるが、.docxを1枚ずつ保存する用途には手順が煩雑で、非エンジニアには使いにくい |
| ⑤ 何人で使い、画面はどうするか | 現場の担当者が1人で使う。Windowsのローカル画面で、ファイルを選ぶダイアログだけのシンプルな画面 |
| ⑥ 何を渡すか(入力) | Wordテンプレート({{項目名}}の形で空欄を置く)と、Excelの差し込みリスト(1行目が見出し、2行目以降が1枚分のデータ)。項目は文書番号/製品名/品番/ロット番号/製造数量/製造ライン/作業日/担当者/承認者/特記事項 |
| ⑦ 何が返ると嬉しいか(出力) | 差し込み済みのWord(.docx)。ファイル名は「作業指示書_文書番号.docx」。出力先は差し込みリストと同じフォルダ |
| ⑧ 判定や計算で使う基準 | 空セルはそのまま空文字で差し込む。出力ファイル名には文書番号を使う |
| ⑨ うまくいかない入力の扱い | 同じ名前のファイルが既にあれば、その行は上書きせず飛ばす。空セルはエラーにせず、そのまま空で出す |
| ⑩ 今回やらないこと | PDF変換・印刷・メール送信・テンプレートの編集機能・リストの編集機能 |
| ⑪ 使う人に持たせたい安心 | 上書き防止(同名は飛ばす)。元のテンプレートとリストは読み取り専用で、一切変更しない |
| ⑫ 前提にする技術・道具 | Python/tkinter(画面)/python-docx(Word操作)/openpyxl(Excel読み取り)/PyInstallerでexe化/Windowsローカル |
| ⑬ モードの判定 | 機能が1つで、失敗しても戻せる(金銭・機微データ・外部送信に触れない)ため「単機能」 |
どんなアプリをどれほど作り込むか、大きな区分として「単機能」「多機能」を設けています。判断基準は機能とリスクの大きさです。そのアプリが取り扱う情報がリスクが大きいのかも考慮します。個人で開発する場合、リスクの低いところから徐々に開発していくことをおすすめします。今回はシンプルな機能であるので「単機能」という区分を選択しました。
わからなければそのままClaudeに質問してください。エージェントをフルに活用しながら作りたいアプリを具体化していけます。
問診が全て完了したら、要求仕様書と版管理票
出力された要求仕様書

入力するファイル
- デモデータ x 3件
出力されるファイル
- wdm_要求仕様書_第1.0版.docx
- wdm_版管理票.md
MATSU版管理票は人間にもAIにとってもどの文書があって、どんな状態なのかわかる道標になります。全ての作業で最新の版管理票を渡したり、出力してもらうように設計しています。
古い版管理票は不要としてどんどん上書き更新する設計です。
「設計」で正解を決める
次は設計フェーズです。合言葉は「設計」です。
/psdd 設計
設計に取り掛かる前に要求仕様書作成のチャットで出てきた成果物を渡す必要があります。全て案内してくれるので覚える必要はありません。
設計フェーズでは、ある入力に対して「こういう出力になるはず」という正解を、1件ずつ決めます。Claudeは候補を並べますが、どれが正解かを決めるのは人です。正常なとき・変わった入力のとき・おかしな入力のときと、観点を分けて穴なく問われます。具体的にみたほうが早いです。



正解も、Claudeに決めてもらえば早いのでは?



正解はClaudeには判断つかないです。ただし、要求仕様を読み取って、おすすめとなる正解は提案してくれるのでこれを基準に考えることもできます。
| 観点 | 試した入力 | 聞かれたこと(正解の候補) | 確定した答え |
|---|---|---|---|
| 正常系 | 製造数量が 5000(整数) | 「5000」でよいか(カンマは付けない) | 「5000」(カンマは付けない) |
| 正常系 | 作業日が 2026-07-14 | 「2026-07-14」でよいか(時刻は付けない) | 「2026-07-14」(時刻は付けない) |
| 正常系 | 5行すべて問題なし | 「5件生成しました」と知らせてよいか | 「5件生成しました」と知らせる |
| 定義で一意化 | 製造数量が 5000.0(小数) | 「.0」を落として「5000」にするか、そのまま出すか | 「5000」(.0 は落とす) |
| 異常系 | セルが空 | 空のまま置き換えるか、警告を出すか | 空のまま置き換える |
| 境界 | データが0行 | 1枚も作らないでよいか | 1枚も作らない |
| 上書き防止 | 同じ名前のファイルが既にある | その行を飛ばすか、上書きするか | その行は飛ばす |
代表的なものとして聞かれるのは、「正常」な動きのときどうするのか、「境界」の値のときどうするか、「異常」な動きのときどうするのか。これらにおける正解とされる動きをここで定義しておき、後のテストを作る工程にこの正解は使われます。実際に出力される期待値表は以下のとおりです。
完成した期待値表


設計チャットでは以下の成果物を受け取ります。
入力するファイル
- デモデータ x 3件
- wdm_要求仕様書_第1.0版.docx
- wdm_版管理票.md
出力されるファイル
- wdm_期待値表_第1.0版.docx
- wdm_版管理票.md(最新:上書き前提で管理されるファイルなので個別保存しなくてOK)
「テスト設計」でテストを作る
最後にテスト設計フェーズです。合言葉は「テスト設計」です。
/psdd テスト設計
単機能では、期待値表をもとにそのまま自動テストのコードに変えます。人間側は生成されるテストコードを受け取るだけで、問診などの対応は不要です。テスト設計においても必要な成果物を渡す必要があります。要求仕様書作成チャットの成果物+設計仕様書作成の成果物をそれぞれ貼り付けてください。
最終的にテスト設計で得られる成果物は以下のテストコードのみです。各成果物を集めて、Claude Codeに渡して実際のコードを実装してもらうことになります
入力するファイル
- デモデータ x 3件
- wdm_要求仕様書_第1.0版.docx
- wdm_期待値表_第1.0版.docx
- wdm_版管理票.md(最新のもの)
出力するファイル
- wdm_test.py
- wdm_版管理票.md(最新のもの)
Claude Codeによる実装とテスト実行
仕様が固まったら、ここからはClaude Codeの出番です。Claude Codeは、指示を受けてコードを書き、実際に動かして確かめるAIです。要求仕様書とテストを渡して実装させます。PSDDでは実装とテスト実行を、別々のチャットに分けて実行していきます。
仕様書類はinputフォルダを作って置く
実装に入る前に、置き場所を用意します。やることは3つだけです。
- コードを実装する作業用の親フォルダを1つ作る
- その中に input という名前のフォルダを作る
- これまでに作ったファイルを、まとめて input に入れる
inputに入れるのは、ここまでのフェーズで作った成果物です。整理はしなくてよく、まとめて置くだけです。
作業フォルダ/
└─ input/
├─ wdm_要求仕様書_第1.0版.docx
├─ wdm_期待値表_第1.0版.xlsx
├─ wdm_test.py
└─ wdm_版管理票.md
使う人は、inputに入れるところまでやればよいだけです。フォルダを分けたり、ファイル名を整えたりする必要はありません。実装作業をClaude Codeが実行したときに勝手にフォルダ分けしてくれます。
合言葉「/psdd-code」で実装させる
実装は、Claude Codeで合言葉を呼んで始めます。次のように送ります。
/psdd-code
呼ぶと、進めたい作業のボタンが並びます。この中から「実装」を選びます。


「実装」を選ぶと、Claude Codeがinputの中身を読み取り、各仕様書をもとにコードを書き始めます。作業を行うとき、常にユーザーに確認を求めてくる場合があります。フォルダの操作など、既存の状態から変更を加えるときはユーザーに許可をもらう、安全設計になります。実装のあいだに起きることは、次のとおりです。
- inputに置いたファイルを、docsやtestsなど決まったフォルダへ自動で仕分けする
- 名前などの軽微な問題は自動で直して(リネームして)整える
- 要求仕様書をよりどころに、差し込みの本体と、ファイルを選ぶ画面をsrcに作る
仕分けが終わると、作業フォルダは次のように整います。フォルダの整理やファイル名の調整を、使う人が手でやる必要はありません。
作業フォルダ/
└─ v1/
├─ docs/ 要求仕様書・期待値表・版管理票
├─ src/ wdm.py(本体)・ui.py(画面)
├─ tests/ wdm_test.py(テスト)
├─ input/ 実行時に読み込むテンプレートと差し込みリスト
└─ data/ テスト用のサンプル
実際にClaude Codeが実装を始める元になるのは、Web Claudeと作成した要求仕様になります。要求仕様を読み取ってコードの実装を行います。
別のチャットでテストを実行する
テストは、実装したチャットとは別のチャットで走らせます。別のClaude Codeチャットを開き、/psdd-codeを入力して、テスト実行を選択して走らせます



実装したチャットで、そのままテストも動かせばよくない?



Claude Codeは指示に対して以下に最小の手数で実行するかを考えて行います。テストを通すように実装するならそのテストをみたら最小の手数になりますよね。エージェントが実装を編集してテストが通り易く改変することを考慮してあえて実装とテスト実行をわける設計にしました。
期待値表から作った11件のテストが、すべて緑(合格)になりました。1件でも赤(不合格)なら、実装が期待値表と食い違っていると通知します。自動テストだけになるので全てを網羅した完全なテストにはならないのですが自動でできる範囲ではテスト成功になります。


Ver.1の完成とヒューマンチェック
テストが緑になったら、Ver.1(最初のバージョン)の完成です。ただし、機械のテストで確かめられることには限りがあります。最後に、人が自分の目で確かめます。
テストが通るとVer.1がクローズする
Claude Codeは、11件のテストがすべて緑になったのに加えて、機械的な安全確認もします。危ない書き方が混じっていないか、パスワードなどの秘密が直接書かれていないか、互換性がないなど弱点のあるライブラリを使っていないか。これらがすべて問題なしなら、Claude Codeが版管理票(作業の台帳)を自動でクローズします。
ここまでで、正解表どおりに動くことは機械的に確かめられました。
自分の手で動かして目で確かめる
ただし、機械のテストで確かめられないことが1つ残っています。差し込んだあとのWordで、書式(太字・罫線・文字の大きさ)が崩れていないか。これは「正しい値か」ではなく「見た目が崩れていないか」「最終的に意図したものと違うものができていないか」なので、正解表に数で書けません。人が目で見るしかないところです。



テストが全部緑なら、もう完成でいいのでは?



値が正しいことは確かめました。ただ、見た目が崩れていないかは数で表せません。そこは人が最後に目で見ます。
今回完成したアプリを実際に動かします。手順は次のとおりです。
- 道具を起動する(通常はrun.batなど起動ファイルが生成されます)
- テンプレート(.docx)を選ぶ
- 差し込みリスト(.xlsx)を選ぶ
- 生成すると、フォルダに作業指示書が5つできる
- 1つ開いて、値と書式を目で確かめる
- 値 … 製品名・数量・日付などが、リストのとおりに差し込まれているか
- 書式 … 太字・罫線・文字の大きさが、テンプレートのまま崩れていないか
出力前のファイル構成


出力後のファイル構成


アプリの育て方
Ver.1を動かして、「出力する前に、どれが作られてどれが飛ばされるかを一覧で確認したい」と思ったとします。これは間違い(バグ)ではありません。使ってみてこう使えたら便利だと新しい要求がでてきました。PSDDではアプリが改善・新しい要求に対応できるように2つの選択肢を提供します。
- マイナーな変更:
要求仕様書を変更しなくても大丈夫なもの。 - メジャーな変更:
Web Claudeに要求変更を依頼し、追加したい内容を伝える
どの程度の変更が要求仕様書に影響を与えるか、Claude Codeが推奨を判断してくれます。今回はメジャーな変更を例にしてアプリの育て方を解説します。まず、Web版のClaudeに戻り、要求仕様書に書き足し、そこから正解表・テストへと順に反映させます。新規のときと同じ3つの合言葉の、変更版を使います。



コードを直接直したほうが早くない?



思いつきで直すと、何をどう変えたかが残りません。仕様書に足せば、変更が正解表とテストまで筋を通って伝わります。
「要求変更」で要求を足す
Ver.1は完成(クローズ)済みです。完成した道具への変更は、Web Claudeで/psddと合言葉「要求変更」で始めます。
/psdd 要求変更
これがVer.2の出発点になります。要求仕様書に、新しい要求を足します。前のバージョンで作成したファイルと版管理票を渡します。変更においてもどんなことを変更するのか問診から始まります。こういうことを対話形式で追加、変更、削除はないか対話しながら回答すれば新しい要求仕様書が完成です。
| 聞かれたこと | 答えた内容 |
|---|---|
| ① 足したい機能はあるか | 起動してすぐ出力するv1に、生成前の「出力予定一覧」を確認する画面を挟みたい。何件出て・何件飛ばして・なぜ飛ばすかを見てから出力ボタンを押したい(→ REQ-1.6) |
| ② 変えたい・直したい既存の挙動はあるか | 差し込み生成の本体(生成そのもの)は変えない。これまでの振る舞いはそのまま維持する |
| ③「やらないこと」から、やることへ移したいものはあるか | なし。逆に「出力先フォルダの変更」を「やらないこと」に明記して固定する |
| ④ 入力の実物(テンプレート.docx/差し込みリスト.xlsx)の列・行・並びは変わるか | 変わらない。同じ様式のまま使う。既存の読み取り位置には影響しない |
| ⑤ 出力は増える・変わるか。既存の出力と重複しないか | 生成される.docxはv1と同じ。画面に確認一覧の表示が増えるだけで、ファイル出力の重複や矛盾はない |
| ⑥(試行で判明)v1で実装済みのスキップ条件を、要求として正式に収録するか | 文書番号が空の行・ファイル名に使えない文字を含む行のスキップ(REQ-1.4.2・REQ-1.4.3)を、確認画面に理由表示するため要求に明記する。根拠:試行(VALIDATED) |
入力するファイル
- wdm_要求仕様書_第1.0版.docx
- wdm_版管理票.md
出力されるファイル
- wdm_要求仕様書_第2.0版.docx
- wdm_版管理票.md
「設計変更」で正解表を直す
要求が変われば、正解も変わります。合言葉「設計変更」で期待値表を更新します。
/psdd 設計変更
Ver. 1の期待値表作成時に行った問診を再度します。対象は差分に当たる部分だけ。既存の期待値に変更がなければ差分の期待値だけ、追加の問診を対応する設計になります。
| 区分 | 対象 | 変更内容 |
|---|---|---|
| 追加 | No.13(異常系) | 文書番号セルが空の行を含むリスト → 該当行をスキップする(生成件数に含めない)。REQ-1.4.2 に対応 |
| 変更 | No.3(境界・データ0行) | 旧:「0件生成しました」とメッセージを表示 → 新:出力する行が0件だと「出力する」ボタンが無効になり(REQ-1.6.4)、生成そのものが走らず完了メッセージも出ない、に書き直し |
| 削除 | なし | 削除された期待値行はない |
入力するファイル
- wdm_要求仕様書_第2.0版.docx
- wdm_期待値表_第1.0版.docx
- wdm_版管理票.md(最新のもの)
出力されるファイル
- wdm_期待値表_第2.0版.docx
- wdm_版管理票.md(最新のもの)
「テスト設計変更」でテストを直す
期待値表が変わったので、テストも合わせます。合言葉「テスト設計変更」で、更新した正解表からテストを作り直します。
/psdd テスト設計変更
新しい正解の行が、そのままテストに加わります。元からあったテストは残したままなので、これまで正しかったところが壊れていないかも、続けて確かめられます。
入力するファイル
- wdm_要求仕様書_第2.0版.docx
- wdm_期待値表_第2.0版.docx
- wdm_test.py
- wdm_版管理票.md(最新のもの)
出力されるファイル
- wdm_test.py
- wdm_版管理票.md
Claude Codeによる再実装と再テスト
仕様書・正解表・テストを更新したら、あとはVer.1と同じ流れです。Claude Codeに差分を実装させ、別のチャットでテストを実行します。違うのは、確かめることが1つ増える点です。新しい機能が正しいことに加えて、これまで動いていたところを壊していないこと。この2つを見ます。また、同じようにinputフォルダに出力したファイル全て入れておく点も同じです。
「/psdd-code」で差分を実装する
Ver.2の更新した仕様を使って、Claude Codeにもう一度実装させます。呼び方はVer.1と同じです。合言葉を呼んで「実装」を選びます。
/psdd-code


Claude Codeは、変わった分だけを実装します。Ver. 2のファイルはVer. 1からエージェントが自動でコピーします。差し込み機能部分は、Ver.1から変えずに追加部分、画面の実装などを行います。変える範囲を最小にして、壊す危険を小さくします。
別のチャットでテストを実行する
テストは、Ver.1と同じく別のチャットで走らせます。今度は、新しく足したテストと、Ver.1から引き継いだテストを、まとめて実行します。



元のテストも一緒に走らせます。そうすれば、今回の変更で古い部分を壊していないか、まで一度に確かめられます。
結果は、12件すべて緑になりました。新しく足した1件が通り、Ver.1から引き継いだ11件も緑のままです。これは、今回の変更でこれまで動いていたところを壊していない、という意味です。作り直しても後戻りが無い、と確かめられます。
完成
新しいテストも、引き継いだテストも緑になりました。あとはVer.1と同じ仕上げです。票をクローズし、もう一度自分の手で動かして、狙いどおりになったかを確かめます。
Ver.2がクローズする
Claude Codeが、12件の緑と機械的な安全確認を確かめ、版管理票を自動でクローズします。これでVer.2が正式に完成です。正解表どおりに動くことは、ここまでで機械的に確かめられています。
もう一度動かして、狙いどおりか確かめる
最後に、自分の手で動かします。手順はVer.1とほぼ同じですが、生成ボタンを押す前に、確認の一覧が出るようになりました。
- 道具を起動する
- テンプレートと差し込みリストを選ぶ
- 生成の前に、確認の一覧が出るか確認する
- よければ生成する
- できたWordを1つ開いて、値と書式を確かめる
動かして気づいた「出力の前に中身を確認したい」が、実際に手元で動くようになりました。生成した文書の値と書式も、Ver.1で確かめたとおり崩れていません。
差し込みリスト選択前の画面


差し込みリスト選択後の画面


出力ボタンを押すと出力される


番外編:exeファイル化で配布する
番外編として、配布できる形式にして出力する方法を紹介します。exe化とは何か。どんな環境でもつくったプログラムが動くとは限りません。つくったコードや動かすために必要なライブラリーをまとめてPC環境に依存せず、動くファイル(.exe)として配布することができます。これでどんなPCでも動作させることができるようになります。
Claude Codeのチャットで/psdd-codeを入力して配布(exe化)を選択します。


アプリ名を聞かれるの回答します。


アイコンを設定できるようにしました。アイコンがあったほうが誤操作防止できるため、アイコンを付けることをおすすめします。


後は自動で全て実行してくれます。distフォルダにexe化されたファイルがあります。


設定したアイコンでアプリとして作られました。


フォルダごと配布しないと必要なコードやライブラリーが読み込めないのでフォルダごと配布すれば起動できます。アプリに連携するデータについてもこのフォルダの中に入るのでデータを参照するときはこのフォルダの中に入る構造です。
余談になりますが、アイコンは以下のサイトより使用させていただいています。
まとめ
プログラムを書かずに、作業指示書を一括で作る道具を、正しさを確かめながら作りました。さらに、使ってみて出てきた「変えたい」も、仕様から入れて安全に直しました。振り返ると、大事なところは3つに絞れます。
- 仕様と正解を先に置く … 何を作るか(要求)と、正解(期待値表)を先に固め、実装とテストをAIに任せる
- 実機で確かめる … 自動テストで完成ではなく期待値表に書かれたとおりに動くか確認する
- 変更は仕様から入れる … コードを直接いじらず、仕様→正解→テストと順に反映すれば、これまで動いていたところを壊さずに直せる
この進め方の芯は、正しさの判断を人が握ることにあります。作るのはAIに任せても、何が正解かは人が決め、正解表とテストで機械的に確かめる。だから、コードを読めなくても、動くだけでなく正しい道具にたどり着けます。
ここまでで作った一式(要求仕様書・期待値表・テスト・完成プログラム・README)は、まとめてダウンロードできます。









コメント