APIでChatGPTの画像生成を使う──キーの扱いと従量課金の使い方

2026年7月6日

画像の生成や文章の要約に、月額で契約しているAIサービスを使っています。ただ、契約した機能のうち実際に使うのは一部で、使う頻度も月額の費用に見合っていません。ほとんど使わない月でも、同じ額を払い続けています。

必要な機能を、使った分だけ払う形で使えないか。その手段が、APIです。今回は画像の生成だけを切り出して、使った分だけ課金される道具を、自分用に作ります。作り方には、機能が一つで失敗しても戻せるツールのための軽い進め方（単機能モード）を使います。

ChatGPTのようなサービスは、一部の機能だけをAPIで切り出して使える

APIは、必要な処理だけを頼む窓口

砂糖さん

APIって、よく聞くけど何ですか。難しそうで身構えてしまいます。

MATSU

サービスの機能を一つだけ、外から頼める窓口だと思ってください。全部を契約しなくていいんです。

APIは、あるサービスの機能の一つだけを、外から呼び出して使うための窓口です。ChatGPTには、対話・文章の要約・画像の生成といった多くの機能がありますが、その全部をまとめて契約しなくても、画像の生成という一つの機能だけを切り出して頼めます。銀行に例えると分かりやすいです。用件を伝えて手続きを頼む窓口や、必要な操作だけを自分で済ませるATMがあります。どちらも銀行の全業務を契約するのではなく、その時に必要な処理だけを頼んでいます。APIも同じで、サービスの一部だけを、必要なときに呼び出します。

月額の定額ではなく、使った分だけ払う

APIを使うには、まずキーを発行します。キーは、そのサービスを有料で受け取るための、利用者ごとの合鍵です。キーを発行し、支払い方法を登録すると、呼び出した分だけが課金されます。支払いの形は、月額の定額ではありません。毎月決まった額を払うプラス会員のような契約ではなく、呼び出した回数と処理の重さに応じて、使った分だけが積み上がる出来高払いになります。だから、使う頻度が低い月は、その分だけ安く済みます。

スクロールできます

	月額のサブスク	API（従量課金）
支払い	毎月一定額	使った分だけ
ほとんど使わない月	同じ額がかかる	ほぼかからない
向いている使い方	毎日たくさん使う	時々・必要なときだけ使う

単機能モードは、要求仕様書と期待値表で作る

単機能モードでは、設計仕様書を作りません。作るのは、要求仕様書と期待値表の2つです。要求仕様書で「何を作るか」を決め、期待値表で「何を正しいとするか」を決めます。この2つがそろえば、あとの実装はClaude Codeに任せられます。

問診に答えるうちに、要求仕様書ができる

要求仕様書は、自分でゼロから書く必要はありません。Web版のClaudeに問診プロンプトを渡すと、Claudeが聞き手になり、質問に答えていくうちに要求仕様書のかたちに整っていきます。専門用語は使わず、誰のための道具か、何を渡して何が返ってほしいか、うまくいかない入力をどう扱うか、といった項目を一つずつ埋めます。今回はここでmode: 単機能を宣言し、設計仕様書を作らない軽い進め方に決めています。

問診プロンプト

あなたは、非エンジニアの私から「作りたい道具」の要求を問診で引き出し、
最後に「要求仕様書」まで書き上げる相談相手です。
私はまだ、何をどう書けばいいか分かっていません。あなたの質問に答えるうちに、
要求仕様書に必要な項目が自然に埋まり、そのまま要求仕様書になる——そんな進め方をしてください。

【最終的な成果物】
問診で集めた内容をもとに、下の「要求仕様書の構成」に沿った要求仕様書を出力する。
これが、後の設計・テスト工程に渡す「種」になります。

【入力と出力は「実物」で挟む ── このプロンプトで最重要のルール】
- 入力：どんなファイルで、どこ（セル／列・行）に何の値が入り、見出し・ラベルの文字列は何か、
  レイアウトのパターン（様式）は何種類あるか、数式があればその形まで詰める。
  実サンプルが1つでもあれば添付してもらう（テストの基準になる）。無ければ、
  後工程がテスト用データ（フィクスチャ）を作れる粒度まで、形式を一緒に確定する。
- 出力：完成イメージ（人が手で作った、こういう出力が欲しいという実物のファイル）を、
  作れるなら1つ用意してもらう。無ければ、シート構成・各シートの中身・グラフの種類・桁・
  ファイル名の規則まで、言葉で確定する。
- 理由：入力サンプルは「現実の入力」を、出力の完成ファイルは「欲しい結果」を、それぞれ一意に決める。
  2つが揃えば、要求は「この入力から、この出力を作る」と実物で挟んで定義でき、文字の仕様が
  取りこぼす細部（桁・レイアウト・グラフの形・ファイル名）まで固まる。ここが曖昧だと、
  テスト工程で「入力データが作れない」「期待値が決まらない」という手詰まりになる。

【問診の進め方】
- 一度に聞くのは1〜2項目まで。私が答えやすいよう、噛み砕いて聞く。
- 専門用語は使わない。私の言葉で返す。
- 私の答えが曖昧・抽象的なときは、具体例や数字を促して掘り下げる。
- 私が機能を欲張りそうなときは、「それは今回やらないことに回せませんか」と提案する。
- 要求の中に、**権限・認可／金銭が動く連携／組織外への公開・送信／自動送信**のいずれかが出てきたら、
  その場で立ち止まり、次の三択を私に提示する：(a) その機能を削る、(b) 安全弁で影響を引き下げる
  （例：使用量の上限で金銭を頭打ちにする、送信せずファイル生成で止めて人が確認して送る）、
  (c) 自作の範囲外と判断して外部に任せる。(b) を選んだ場合、その安全弁のロジックを要求仕様に明記し、
  「最優先のオラクル対象」と付記する（弁が壊れたら致命傷に戻るため、後工程で最も厳格に検証する）。
- 判断に事実が要るとき（業界の相場・実態など）は、調べることを提案する。
- 矛盾や抜けに気づいたら、その場で指摘する。
- 結論を押し付けない。最後に決めるのは私。選択肢と、あなたの推しを添える。
- 入力と出力は、上の【実物で挟む】ルールに従い、問診の中で最も具体的に詰める。

【問診で埋める13項目】
1. 誰のための、何の道具か
2. いま何に困っているか（具体・数字）
3. この道具で何をしたいか（ゴール）
4. なぜ今ある方法では足りないか
5. 何人で使い、画面はどんな方針か
6. 何を渡すか（入力データ）。ファイル形式・項目名・型に加えて、様式まで——【実物で挟む】の粒度で。
7. 何が返ると嬉しいか（出力：形式・見せ方）。完成イメージを——【実物で挟む】の粒度で。
8. 判定や計算で使う基準・ルール（数字で決めたいこと）
9. うまくいかない入力（不備）をどう扱うか
10. 今回やらないこと
11. 使う人に持たせたい安心
12. 前提にする技術・道具（要求から事実上決まるもの）。画面の作り方（ローカルのデスクトップ画面なら
    tkinter など）、入出力のファイルを扱うライブラリ（Excelの読み書き・グラフなら openpyxl など）、
    クラウドを使わない等の制約。「既存のツールと揃えたいか」も聞く。
    ここを決めておかないと、設計フェーズで技術選定を聞かれ、テスト設計でも入力フィクスチャを
    作るライブラリや、手動確認する画面の種類が定まらなくなる。
13. モードの判定（単機能／多機能）。次の2つを私に確認する：
    ①この道具の機能は1つか（単一機能か）。
    ②失敗したとき、影響が小さく自力で戻せるか（金銭・機微データ・組織外公開・自動送信・権限認可の
      いずれかに触れないか）。
    ①②とも満たせば `mode: 単機能`、どちらかを満たさなければ `mode: 多機能`
    （**単機能でも、戻せない failure case に触れるなら多機能**）。判定に迷ったら単機能でよい——
    これは着手時の宣言であって確定ではなく、確定はテスト実行（Phase 6）の関門が行い、
    必要なら要求仕様のアップデートで昇格する、と私に伝える。

【要求仕様書を書くとき守ってほしいこと】
- まず最小構成で考える。いま一番困っていることだけを解決し、欲張らない。
- 専門用語を避け、私（非エンジニア）が読める言葉で書く。
- 後の工程（設計・テスト）が、この要求仕様書だけを読んで進められるよう、
  入力・出力・判定基準を具体的に書く。
- 入力・出力の様式は、【実物で挟む】の粒度で書く。実サンプル・完成ファイルがあれば添付し、
  その様式を仕様の基準にする（出力の完成ファイルはテストの期待値の基点になる）。
- 前提にする技術・道具を書く。画面の作り方（例：ローカルのデスクトップ画面なら tkinter）、
  入出力のファイルを扱うライブラリ（例：Excelの読み書き・グラフなら openpyxl）など、
  要求（ローカル完結・既存スタックと揃える・入出力の形式）から事実上決まるものは、要求仕様書に明記する。
  これが無いと、設計で技術選定を聞かれ、テスト設計でフィクスチャのライブラリや手動確認の画面の種類が定まらない。
- 「やること」を、大・中・小の3階層に整理し、それぞれにIDを振る。
  ・大項目＝この道具で何ができるか（例：測定値を正しく取り出す）
  ・中項目＝テストで1つの観点として確かめられる、1つのふるまい（例：2系統で照合して採否を決める）
  ・小項目＝具体的な分岐・動作（例：一致なら採用／不一致なら除外）
  IDは「REQ-2」「REQ-2.2」「REQ-2.2.1」のように、大・中・小で桁を増やす。
  中項目を決める基準は「これはテストで1観点として確かめられるか?」の一つだけ。
- 処理の流れを、上から下へのワークフロー図（簡単な箇条書きの流れでよい）にし、
  各ステップに対応するIDを添える。この図を要求仕様書の中に置く。これが後の設計・テストの原図になる。

【要求仕様書の構成】
1. このツールは何か
2. 背景と困りごと
3. このツールがやること（大・中・小の3階層＋ID）
4. 入力と出力（【実物で挟む】の粒度で。実サンプル・出力の完成ファイルがあれば添付）
5. 処理の流れ（ワークフロー図＋各ステップのID）
6. やらないこと
7. なぜ既存ツールでは足りないか
8. 使う人に持たせる安心
9. 前提にする技術・道具（画面の作り方・入出力のライブラリ・制約など、要求から決まるもの）
10. ID辞書（全IDの一覧表：ID／階層（大中小）／実現すること）

【流れ】
1. まず、確認したいことを1〜2問ずつ聞いて、12項目を埋めていく。
2. 全項目がそろったら、私に一度内容を確認させる。
3. OKが出たら、「要求仕様書の構成」に沿って要求仕様書を出力する。
   出力は .docx（Word）形式のファイルで行う。冒頭に必ずモード表記（`mode: 単機能` または `mode: 多機能`）を置く。
   **多機能モードのときだけ**、ID辞書と同じ内容を docs/spec_ids.json（後の整合チェックが読む機械可読な
   ID一覧）としても出力する。形式は [{"id":"REQ-2","level":"大","desc":"…"}, …]。
   **単機能モードでは spec_ids.json を出力しない**（設計・テスト設計・整合チェックを使わないため、
   突き合わせ相手が存在しない。要求仕様書本文のID辞書だけで足りる）。
   （途中で、項目を【　】で埋めただけの中間プロンプトは作らない）
4. 要求仕様書ができたら、下の「仕上げ確認」で定義不足を洗い出し、必要なら埋めてから設計へ渡す。

あなたは、非エンジニアの私から「作りたい道具」の要求を問診で引き出し、
最後に「要求仕様書」まで書き上げる相談相手です。
私はまだ、何をどう書けばいいか分かっていません。あなたの質問に答えるうちに、
要求仕様書に必要な項目が自然に埋まり、そのまま要求仕様書になる——そんな進め方をしてください。

【最終的な成果物】
問診で集めた内容をもとに、下の「要求仕様書の構成」に沿った要求仕様書を出力する。
これが、後の設計・テスト工程に渡す「種」になります。

【入力と出力は「実物」で挟む ── このプロンプトで最重要のルール】
- 入力：どんなファイルで、どこ（セル／列・行）に何の値が入り、見出し・ラベルの文字列は何か、
  レイアウトのパターン（様式）は何種類あるか、数式があればその形まで詰める。
  実サンプルが1つでもあれば添付してもらう（テストの基準になる）。無ければ、
  後工程がテスト用データ（フィクスチャ）を作れる粒度まで、形式を一緒に確定する。
- 出力：完成イメージ（人が手で作った、こういう出力が欲しいという実物のファイル）を、
  作れるなら1つ用意してもらう。無ければ、シート構成・各シートの中身・グラフの種類・桁・
  ファイル名の規則まで、言葉で確定する。
- 理由：入力サンプルは「現実の入力」を、出力の完成ファイルは「欲しい結果」を、それぞれ一意に決める。
  2つが揃えば、要求は「この入力から、この出力を作る」と実物で挟んで定義でき、文字の仕様が
  取りこぼす細部（桁・レイアウト・グラフの形・ファイル名）まで固まる。ここが曖昧だと、
  テスト工程で「入力データが作れない」「期待値が決まらない」という手詰まりになる。

【問診の進め方】
- 一度に聞くのは1〜2項目まで。私が答えやすいよう、噛み砕いて聞く。
- 専門用語は使わない。私の言葉で返す。
- 私の答えが曖昧・抽象的なときは、具体例や数字を促して掘り下げる。
- 私が機能を欲張りそうなときは、「それは今回やらないことに回せませんか」と提案する。
- 要求の中に、**権限・認可／金銭が動く連携／組織外への公開・送信／自動送信**のいずれかが出てきたら、
  その場で立ち止まり、次の三択を私に提示する：(a) その機能を削る、(b) 安全弁で影響を引き下げる
  （例：使用量の上限で金銭を頭打ちにする、送信せずファイル生成で止めて人が確認して送る）、
  (c) 自作の範囲外と判断して外部に任せる。(b) を選んだ場合、その安全弁のロジックを要求仕様に明記し、
  「最優先のオラクル対象」と付記する（弁が壊れたら致命傷に戻るため、後工程で最も厳格に検証する）。
- 判断に事実が要るとき（業界の相場・実態など）は、調べることを提案する。
- 矛盾や抜けに気づいたら、その場で指摘する。
- 結論を押し付けない。最後に決めるのは私。選択肢と、あなたの推しを添える。
- 入力と出力は、上の【実物で挟む】ルールに従い、問診の中で最も具体的に詰める。

【問診で埋める13項目】
1. 誰のための、何の道具か
2. いま何に困っているか（具体・数字）
3. この道具で何をしたいか（ゴール）
4. なぜ今ある方法では足りないか
5. 何人で使い、画面はどんな方針か
6. 何を渡すか（入力データ）。ファイル形式・項目名・型に加えて、様式まで——【実物で挟む】の粒度で。
7. 何が返ると嬉しいか（出力：形式・見せ方）。完成イメージを——【実物で挟む】の粒度で。
8. 判定や計算で使う基準・ルール（数字で決めたいこと）
9. うまくいかない入力（不備）をどう扱うか
10. 今回やらないこと
11. 使う人に持たせたい安心
12. 前提にする技術・道具（要求から事実上決まるもの）。画面の作り方（ローカルのデスクトップ画面なら
    tkinter など）、入出力のファイルを扱うライブラリ（Excelの読み書き・グラフなら openpyxl など）、
    クラウドを使わない等の制約。「既存のツールと揃えたいか」も聞く。
    ここを決めておかないと、設計フェーズで技術選定を聞かれ、テスト設計でも入力フィクスチャを
    作るライブラリや、手動確認する画面の種類が定まらなくなる。
13. モードの判定（単機能／多機能）。次の2つを私に確認する：
    ①この道具の機能は1つか（単一機能か）。
    ②失敗したとき、影響が小さく自力で戻せるか（金銭・機微データ・組織外公開・自動送信・権限認可の
      いずれかに触れないか）。
    ①②とも満たせば `mode: 単機能`、どちらかを満たさなければ `mode: 多機能`
    （**単機能でも、戻せない failure case に触れるなら多機能**）。判定に迷ったら単機能でよい——
    これは着手時の宣言であって確定ではなく、確定はテスト実行（Phase 6）の関門が行い、
    必要なら要求仕様のアップデートで昇格する、と私に伝える。

【要求仕様書を書くとき守ってほしいこと】
- まず最小構成で考える。いま一番困っていることだけを解決し、欲張らない。
- 専門用語を避け、私（非エンジニア）が読める言葉で書く。
- 後の工程（設計・テスト）が、この要求仕様書だけを読んで進められるよう、
  入力・出力・判定基準を具体的に書く。
- 入力・出力の様式は、【実物で挟む】の粒度で書く。実サンプル・完成ファイルがあれば添付し、
  その様式を仕様の基準にする（出力の完成ファイルはテストの期待値の基点になる）。
- 前提にする技術・道具を書く。画面の作り方（例：ローカルのデスクトップ画面なら tkinter）、
  入出力のファイルを扱うライブラリ（例：Excelの読み書き・グラフなら openpyxl）など、
  要求（ローカル完結・既存スタックと揃える・入出力の形式）から事実上決まるものは、要求仕様書に明記する。
  これが無いと、設計で技術選定を聞かれ、テスト設計でフィクスチャのライブラリや手動確認の画面の種類が定まらない。
- 「やること」を、大・中・小の3階層に整理し、それぞれにIDを振る。
  ・大項目＝この道具で何ができるか（例：測定値を正しく取り出す）
  ・中項目＝テストで1つの観点として確かめられる、1つのふるまい（例：2系統で照合して採否を決める）
  ・小項目＝具体的な分岐・動作（例：一致なら採用／不一致なら除外）
  IDは「REQ-2」「REQ-2.2」「REQ-2.2.1」のように、大・中・小で桁を増やす。
  中項目を決める基準は「これはテストで1観点として確かめられるか?」の一つだけ。
- 処理の流れを、上から下へのワークフロー図（簡単な箇条書きの流れでよい）にし、
  各ステップに対応するIDを添える。この図を要求仕様書の中に置く。これが後の設計・テストの原図になる。

【要求仕様書の構成】
1. このツールは何か
2. 背景と困りごと
3. このツールがやること（大・中・小の3階層＋ID）
4. 入力と出力（【実物で挟む】の粒度で。実サンプル・出力の完成ファイルがあれば添付）
5. 処理の流れ（ワークフロー図＋各ステップのID）
6. やらないこと
7. なぜ既存ツールでは足りないか
8. 使う人に持たせる安心
9. 前提にする技術・道具（画面の作り方・入出力のライブラリ・制約など、要求から決まるもの）
10. ID辞書（全IDの一覧表：ID／階層（大中小）／実現すること）

【流れ】
1. まず、確認したいことを1〜2問ずつ聞いて、12項目を埋めていく。
2. 全項目がそろったら、私に一度内容を確認させる。
3. OKが出たら、「要求仕様書の構成」に沿って要求仕様書を出力する。
   出力は .docx（Word）形式のファイルで行う。冒頭に必ずモード表記（`mode: 単機能` または `mode: 多機能`）を置く。
   **多機能モードのときだけ**、ID辞書と同じ内容を docs/spec_ids.json（後の整合チェックが読む機械可読な
   ID一覧）としても出力する。形式は [{"id":"REQ-2","level":"大","desc":"…"}, …]。
   **単機能モードでは spec_ids.json を出力しない**（設計・テスト設計・整合チェックを使わないため、
   突き合わせ相手が存在しない。要求仕様書本文のID辞書だけで足りる）。
   （途中で、項目を【　】で埋めただけの中間プロンプトは作らない）
4. 要求仕様書ができたら、下の「仕上げ確認」で定義不足を洗い出し、必要なら埋めてから設計へ渡す。

問診で固まった要求

入力：
プロンプト（文章）。編集したいときは、手元の画像（JPEG／PNG／SVG／webp）も渡す
出力：
指定フォルダに、日時を名前にした画像を保存。webpが既定で、png／jpegも選べる
使うAPI：
OpenAIの画像生成（gpt-image-2）。キーは.envに分け、ソースに直書きしない
モード：
単機能。機能は画像生成の一つで、失敗しても手元でやり直せるため、設計仕様書は作らない

要求仕様書をダウンロード

実装の前に、何を確かめるかを期待値表で決める

要求仕様書ができたら、実装に入る前に期待値表を作ります。期待値表は、ある入力に対して「正しい出力は何か」を先に決めておく表です。ここで決めた正しさが、あとのテストの基準になります。表は、確定・保留・対象外の3つに分けます。「サイズが範囲外なら弾く」「失敗しても止まらない」のように正解が一つに決まるものは確定に入れ、テストで機械的に確かめます。一方、生成された画像そのものの良し悪しは、正解が一つに定まりません。だから対象外にして、最後に人が見て判断します。この期待値表も、要求仕様書と同じように、専用のプロンプトをWeb版のClaudeに渡して作ります。

期待値を引き出すプロンプト

あなたは、確定した要求仕様書と設計仕様書を入力に、私（オラクルを保有する当事者）から
「各入力に対する正しい出力＝期待値」を問診で引き出し、期待値表にまとめる相談相手です。
設計の基礎、とくに「11. オラクル」を守ります。あなたが正しい出力を計算・推定して決めることは
絶対にしません（基礎11）。あなたの役割は、取りこぼしが出ないよう問診の網を張り、
「この入力なら正解は何ですか」と私に問い、私の答えとその出所を記録することです。

【入力にするもの】
確定した要求仕様書（計算例つき）・設計仕様書（多機能モードのみ。単機能では無し）・設計の基礎。
これだけを根拠にする（基礎1の独立性）。
入力サンプル・出力完成イメージがあれば、実際に開いて中身を確かめる。

【網羅の担保：この6カテゴリを必ず一巡する】
各カテゴリで「該当あり／なし」を私に確認する。「なし」も明言させてから次へ進む（黙って飛ばさない）。
入力（試す値）はあなたが作ってよい。正解（期待される出力）は作らない——空欄のまま私に問う（基礎11）。
1. 正常系：代表的な入力の正しい出力。要求仕様の計算例に対応。
2. 境界：しきい値ちょうど・直前・直後／月末・0件・上限下限。設計仕様の各関数の境界を見て、
   「この境界の正解は何か」「境界値はどちら側に含めるか」を1つずつ問う（含む側は私が定義する）。
3. 異常系：空欄・欠損・想定外の型・全角混じり・重複・順序違い。「この不正入力のとき正しい振る舞いは何か
   （弾く／除外／警告／続行）」を問う。
4. 定義で一意化する非一意：丸めの桁・単位・日付形式・同点時の順序など。「どう決めますか」と問い、決定を記録。
5. オラクル対象外：人によって割れる、または私が根拠を持って一意に答えられないもの（主観的な良し悪し）。
   期待値表に入れず「対象外」に分離し、テストの外へ送る。無理に正解を作らせない（基礎11）。
6. 未言語化オラクルの予告：いま問診では答えが出ないが、動くものを見れば「違う」と気づきそうな箇所を
   私に挙げさせる。「保留（現物照合で回収）」と記す。言語化を無理に迫らない。

【全数を人に答えさせない（基礎11）】
同じ扱いになる入力は同値分割で1つに代表し、正解の出方が切り替わる境目だけ個別に問う。
判定ルールが1つでパラメータ（規格値など）だけ違う場合は、私にパラメータの一覧表を渡すよう頼む
（100件でも100回問わない）。

【各期待値で必ず記録すること】
- 入力（具体値。あなたが作ってよい）／期待される正しい出力（私が答える。空欄で問う）／
  正解の出所（手計算／実測・実データ／規格・公式／私が定義、のいずれか。私が答える）。
- 出所が「AIが計算した」しか無い期待値は採用しない。私が独立に出し直すか、保留にする。

【進め方】
- 一度に問うのは1〜2件。専門用語を避ける。私が即答できないときは、答えを先回りせず、
  計算に必要な材料（式・しきい値・対象データ）を整理して見せて、私が出しやすくする（あなたは答えない）。
- 6カテゴリを一巡したら、設計仕様の各関数・各要求IDに対して「正解の割り当てが無いもの（穴）」が
  残っていないか照合し、穴を私に報告する（ここで網羅性を点検する）。

【要求仕様書との矛盾を見つけたとき】
私の答えた期待値が、要求仕様書の計算例・記述と食い違う場合、どちらかに黙って合わせない。両方を並べて
提示する：「要求仕様書は◯◯（計算例の出所）、いまの回答は△△（あなたの出所）。どちらが正しいですか」。
私が判定した結果、
・要求仕様書側が誤り（オラクルが正しい）なら：期待値表には私の答えを「確定」で記録し、要求仕様書の
  該当箇所を、出力末尾の「要求仕様書への反映事項」に一覧で溜める（どの計算例・記述が、どの期待値と
  どう食い違い、私がどちらを正しいと判定したか）。この一覧は、あとで枝番改訂プロンプトに渡して
  要求仕様書をマイナー改訂する材料になる（この工程では要求仕様書を直接いじらない＝検出と修正を分ける）。
・私の答えが誤りなら：出し直して記録する。
判定と修正の向きを、あなたが決めることは絶対にしない（基礎11：正解の所在は人）。

【出力】
**期待値表を、ファイル（期待値表.md、または .xlsx）として出力する**（対話で表を見せて
終わりにしない——後工程のテスト生成・実装がこのファイルを入力に取るため、成果物として必ず残す）。
表の列は カテゴリ／入力／期待出力／出所／状態。状態は「確定／保留／対象外」の3つに分ける（基礎11）。
確定行だけがテスト生成（Phase 4）へ渡る。保留・対象外は同じファイルに分離して残す。
末尾に、要求ID×状態の対応表（確定・保留・対象外の内訳と、割り当ての無い穴）を付ける。
要求仕様書との矛盾があった場合は、末尾に「要求仕様書への反映事項」を一覧で付ける（無ければ「なし」と記す）。
出力したファイルは、人が最新版フォルダの docs/ に置く（このチャットはファイルを生成するだけで、版フォルダには直接書かない。要求仕様書・設計仕様書と同じ受け渡し）。

あなたは、確定した要求仕様書と設計仕様書を入力に、私（オラクルを保有する当事者）から
「各入力に対する正しい出力＝期待値」を問診で引き出し、期待値表にまとめる相談相手です。
設計の基礎、とくに「11. オラクル」を守ります。あなたが正しい出力を計算・推定して決めることは
絶対にしません（基礎11）。あなたの役割は、取りこぼしが出ないよう問診の網を張り、
「この入力なら正解は何ですか」と私に問い、私の答えとその出所を記録することです。

【入力にするもの】
確定した要求仕様書（計算例つき）・設計仕様書（多機能モードのみ。単機能では無し）・設計の基礎。
これだけを根拠にする（基礎1の独立性）。
入力サンプル・出力完成イメージがあれば、実際に開いて中身を確かめる。

【網羅の担保：この6カテゴリを必ず一巡する】
各カテゴリで「該当あり／なし」を私に確認する。「なし」も明言させてから次へ進む（黙って飛ばさない）。
入力（試す値）はあなたが作ってよい。正解（期待される出力）は作らない——空欄のまま私に問う（基礎11）。
1. 正常系：代表的な入力の正しい出力。要求仕様の計算例に対応。
2. 境界：しきい値ちょうど・直前・直後／月末・0件・上限下限。設計仕様の各関数の境界を見て、
   「この境界の正解は何か」「境界値はどちら側に含めるか」を1つずつ問う（含む側は私が定義する）。
3. 異常系：空欄・欠損・想定外の型・全角混じり・重複・順序違い。「この不正入力のとき正しい振る舞いは何か
   （弾く／除外／警告／続行）」を問う。
4. 定義で一意化する非一意：丸めの桁・単位・日付形式・同点時の順序など。「どう決めますか」と問い、決定を記録。
5. オラクル対象外：人によって割れる、または私が根拠を持って一意に答えられないもの（主観的な良し悪し）。
   期待値表に入れず「対象外」に分離し、テストの外へ送る。無理に正解を作らせない（基礎11）。
6. 未言語化オラクルの予告：いま問診では答えが出ないが、動くものを見れば「違う」と気づきそうな箇所を
   私に挙げさせる。「保留（現物照合で回収）」と記す。言語化を無理に迫らない。

【全数を人に答えさせない（基礎11）】
同じ扱いになる入力は同値分割で1つに代表し、正解の出方が切り替わる境目だけ個別に問う。
判定ルールが1つでパラメータ（規格値など）だけ違う場合は、私にパラメータの一覧表を渡すよう頼む
（100件でも100回問わない）。

【各期待値で必ず記録すること】
- 入力（具体値。あなたが作ってよい）／期待される正しい出力（私が答える。空欄で問う）／
  正解の出所（手計算／実測・実データ／規格・公式／私が定義、のいずれか。私が答える）。
- 出所が「AIが計算した」しか無い期待値は採用しない。私が独立に出し直すか、保留にする。

【進め方】
- 一度に問うのは1〜2件。専門用語を避ける。私が即答できないときは、答えを先回りせず、
  計算に必要な材料（式・しきい値・対象データ）を整理して見せて、私が出しやすくする（あなたは答えない）。
- 6カテゴリを一巡したら、設計仕様の各関数・各要求IDに対して「正解の割り当てが無いもの（穴）」が
  残っていないか照合し、穴を私に報告する（ここで網羅性を点検する）。

【要求仕様書との矛盾を見つけたとき】
私の答えた期待値が、要求仕様書の計算例・記述と食い違う場合、どちらかに黙って合わせない。両方を並べて
提示する：「要求仕様書は◯◯（計算例の出所）、いまの回答は△△（あなたの出所）。どちらが正しいですか」。
私が判定した結果、
・要求仕様書側が誤り（オラクルが正しい）なら：期待値表には私の答えを「確定」で記録し、要求仕様書の
  該当箇所を、出力末尾の「要求仕様書への反映事項」に一覧で溜める（どの計算例・記述が、どの期待値と
  どう食い違い、私がどちらを正しいと判定したか）。この一覧は、あとで枝番改訂プロンプトに渡して
  要求仕様書をマイナー改訂する材料になる（この工程では要求仕様書を直接いじらない＝検出と修正を分ける）。
・私の答えが誤りなら：出し直して記録する。
判定と修正の向きを、あなたが決めることは絶対にしない（基礎11：正解の所在は人）。

【出力】
**期待値表を、ファイル（期待値表.md、または .xlsx）として出力する**（対話で表を見せて
終わりにしない——後工程のテスト生成・実装がこのファイルを入力に取るため、成果物として必ず残す）。
表の列は カテゴリ／入力／期待出力／出所／状態。状態は「確定／保留／対象外」の3つに分ける（基礎11）。
確定行だけがテスト生成（Phase 4）へ渡る。保留・対象外は同じファイルに分離して残す。
末尾に、要求ID×状態の対応表（確定・保留・対象外の内訳と、割り当ての無い穴）を付ける。
要求仕様書との矛盾があった場合は、末尾に「要求仕様書への反映事項」を一覧で付ける（無ければ「なし」と記す）。
出力したファイルは、人が最新版フォルダの docs/ に置く（このチャットはファイルを生成するだけで、版フォルダには直接書かない。要求仕様書・設計仕様書と同じ受け渡し）。

どこを期待値にしたか

リクエストの固定値：
モデルと品質（high）が、必ず送られているか
保存の挙動：
指定フォルダに、日時の名前で、1枚だけ保存されるか（webp／png／jpeg）
サイズの範囲：
16の倍数・縦横比・最大寸法の内と外。範囲外は弾き、わずかな外れは丸めるか
入力の不備：
空欄のプロンプトや、非対応・破損の画像を弾くか
失敗したとき：
原因を表示し、その1枚は保存せず、ツールは止まらないか
対象外：
生成された画像そのものの良し悪し。正解が一つに決まらないので、人が見て判断する

「動いた」と「正しい」が別物である、という考え方そのものは、別の記事にまとめています。

コードを書く前に、期待値表からテストを作る

実装に入る前に、もう一つやることがあります。テストを作ることです。コードはまだ書きませんが、テストは先に用意します。実装を見てからテストを書くと、テストが実装に引きずられ、間違ったまま緑になってしまうことがあるからです。だから、テストは実装より前に作って置きます。作り方は、Web版のClaudeに、期待値表と要求仕様書を渡して依頼します。

テストを作るプロンプト

添付の「期待値表（確定行）」と「要求仕様書」から、pytest のテストコードを生成してください。
- 期待値表の確定行を、1行1テストに落とす（入力→期待される出力を assert する）。実コードは見ない・書かない。
- @verify タグ・トレーサビリティマトリクス・テスト設計仕様書は作らない（単機能モードのため）。
- 外部API・ネットワーク・課金を伴う呼び出しは、テスト内でモック（偽の応答）に置き換える。API が返す
  中身そのもの（生成画像など、正解が一意に定まらないもの）は検証対象にしない——検証するのは、API を
  呼ぶ前の入力検証と、API から返った後の加工・保存・命名など、オラクルが一意に決まる部分だけ。
- フィクスチャ（テスト用の入力）はテストコードの中で組み立てる（できあいのバイナリ頼みにしない）。
- 出力は test_*.py。これを最新版フォルダの tests/ に置く（実装者は中身を触らない）。

添付の「期待値表（確定行）」と「要求仕様書」から、pytest のテストコードを生成してください。
- 期待値表の確定行を、1行1テストに落とす（入力→期待される出力を assert する）。実コードは見ない・書かない。
- @verify タグ・トレーサビリティマトリクス・テスト設計仕様書は作らない（単機能モードのため）。
- 外部API・ネットワーク・課金を伴う呼び出しは、テスト内でモック（偽の応答）に置き換える。API が返す
  中身そのもの（生成画像など、正解が一意に定まらないもの）は検証対象にしない——検証するのは、API を
  呼ぶ前の入力検証と、API から返った後の加工・保存・命名など、オラクルが一意に決まる部分だけ。
- フィクスチャ（テスト用の入力）はテストコードの中で組み立てる（できあいのバイナリ頼みにしない）。
- 出力は test_*.py。これを最新版フォルダの tests/ に置く（実装者は中身を触らない）。

テストコードをダウンロード

Claude Codeに要求仕様書と期待値表を渡して実装する

要求仕様書と期待値表がそろったら、実装はClaude Codeに任せます。Claude Codeは、コードを書く作業を担うAIです。人はコードを書かず、この2つの成果物を渡して依頼します。何を作るか（要求仕様書）と、何を正しいとするか（期待値表）が決まっているので、依頼する側は流れの指示だけで済みます。

要求仕様書、期待値表、テストコードを渡して、実装を依頼する

Claude Codeに、要求仕様書と、期待値表から起こしたテストを渡し、planモードで実装を依頼します。フォルダの構成や、途中で止まる条件といった細かい作法は、CLAUDE.mdという常駐ファイルに書いてあります。作りたいフォルダを指定して、v1フォルダを作成し、その中に要求仕様書、期待値表、テストコードを全てまとめたら、CLAUDE.mdに従ってClaude Codeが自動的に実装してくれるようになっています。

実装プロンプト

最新版フォルダ（vN/）で、コードの実装だけを行うチャットです。CLAUDE.md のルールに従います。
実装の細かい作法（土台の置き方・依存順・タグ・土台コメント・安全のための停止）は CLAUDE.md に
常駐しているので、ここでは流れの指示だけにします。

【承認の受け取り方（このチャット全体の共通ルール）】
作業を止めて承認や判断を仰ぐときは、必ず AskUserQuestion を使い、選択肢（「はい／いいえ」や、
用意した候補）で提示する。自由記述での回答を求めない。ユーザーがボタンを押すだけで進められるようにする。
確認は、まとめられるものは1回にまとめる（一つずつ細切れに聞かない）。

【説明のしかた（このチャット全体の共通ルール）】
ユーザーに向けた地の文（計画の提示・報告・確認・進行中の説明）は、非エンジニアにも伝わる言葉で書く。
計画を出すときだけ平易にして、途中の報告や節目の報告を専門語のままにしない。チャット全体で同じ平易さを
保つ。初めて出す専門用語・コマンド・ファイル名・タグ（pytest／dataclass／extract・check／
structure.json／@spec・@id など）は、名前はそのまま示したうえで、それが何をするものかを短く一言添える
（名前は言い換えない。一度説明したら以後は繰り返さない）。平易にするのはユーザーに向けた会話だけで、
コードの中身・タグの記法・設計仕様書の契約といった成果物そのものは規約どおりに書く。

このチャットは3つの工程を、この順に行います。最初は【版フォルダの判定と引き継ぎ】で、どの版で作業する
かを確定します。次が【立ち上げ工程】で、環境を整えます。最後が【実装工程】で、設計どおり黙々と進めます
（節目と安全弁でだけ止まる）。前の工程が済んでから、次の工程に入ってください。

【版フォルダの判定と引き継ぎ（最初に必ず行う）】
作業対象は「最新版フォルダ」とする。まず、プロジェクトのルート直下にある版フォルダ（v1／v2／… の形の
フォルダ）を全て挙げ、番号が最大のものを最新版フォルダとみなす。ユーザーが作業対象の版を明示している
場合は、それを優先する。
最新版フォルダを決めたら、その中身の状態を、次の三つのどれかに判定して報告する。
- (A) 中身が揃っている（docs／tests／src が在り、その版だけで pytest が回せる。多機能ではさらに spec_ids.json。単機能に spec_ids.json は無いのが正常）：
  そのまま作業対象として、立ち上げ工程へ進む（整っていれば確認だけで飛ばしてよい）。ただし、変更フローの版で
  tests に差分テスト（今回追加分）しか無く、前版の既存テストが欠けているなら、これは「揃っている」ではなく
  (B) として扱い、前版の既存テストを引き継ぐ。
- (B) フォルダは在るが空、または中身が不完全（最大番号の版なのに docs や tests が無い、または振り分け前、
  または tests に差分テストしか無く前版の既存テストが欠けている）：
  一つ前の版（番号が一つ小さいフォルダ）から、この版に無いもの（実装 src／土台 pytest.ini 等／入力サンプル）
  を引き継ぐ。**テストも引き継ぐ**：前版 tests/ の既存テスト（test_*.py）のうち、テスト設計変更プロンプトの
  差分サマリーで「廃止・置換した観点（V-）」に挙がった分だけを除いて、この版の tests/ にコピーする。
  除外する V- は、テストの中身（assert・期待値）を読まずに、差分サマリーの記載だけで判定する（独立性を保つ）。
  この版が自前で持つ新しい成果物（新仕様書・差分テスト）は上書きしない——前版から運んだ既存テストに差分
  テストが加わって、リグレッション確認ができる完全な集合（例：V01〜V40＋差分 V46〜）になる。差分テストが
  既に在るからといって、前版の既存テストの持ち込みを省かない（省くと据え置くべき既存観点が丸ごと未検証に
  落ちる）。docs／src／tests への振り分けと、各ファイルの版文字列（.py 先頭の `# spec_version:`）の統一まで行う。
  これらの引き継ぎ計画を一つにまとめ、AskUserQuestion で「この引き継ぎを実行してよいか（はい／いいえ）」
  と一度だけ問う。「はい」なら一括実行し、「vN を vN-1 から引き継いで自己完結させました」と報告して
  立ち上げ工程へ進む。細かい移動ごとに個別の承認は取らない。
- (C) 版フォルダが一つも無い（新規プロジェクト）：v1 を作業対象とし、立ち上げ工程で構成を新規に整える。

判定の要点：最大番号の版フォルダが空でも、そこを最新版として扱い、前版から引き継いで埋める。中身のある
古い版（v1 など）を勝手に最新版とみなして、そこへ実装しない。どこへ実装するかを取り違えないために、この
工程を必ず最初に通す。

【立ち上げ工程（新規プロジェクトや、まだ構成が整っていない版フォルダのとき）】
手順の実体は CLAUDE.md の「立ち上げ」に定義してある（フォルダ構成の整理／psdd.py と pytest.ini の配置／
.venv の作成／requirements.txt の起こしと導入／外部サービスの SETUP.md 化／エディタ設定／起動スクリプト／
pytest の空回し確認）。このチャットでは、それを次のやり方で実行する：
- まずプロジェクトのルートと最新版フォルダの状態を確認し、不足を洗い出す。
- 何をするか（作るフォルダ・置くファイル・入れる依存など）を一つの計画にまとめて提示し、AskUserQuestion で
  「この立ち上げを実行してよいか（はい／いいえ）」と一度だけ問う。「はい」なら一括で実行し、終わったら
  「環境が整いました」と、何をしたかの結果を報告する。ステップごとに個別の承認は取らない。
- 例外として、外部サービス（Ollama・モデル取得・GPU など）に実際に触れる操作と、共通 .venv への
  ライブラリ導入（pip install）だけは、システムを変える度合いが大きいので、実行の直前に AskUserQuestion で
  もう一度だけ確認する（導入する依存の一覧を見せ、「入れてよいか（はい／いいえ）」）。ここも自由入力は
  求めない。

ここまで済んでいる版フォルダ（構成も .venv も整っている）なら、この工程は確認だけで飛ばしてよい。

【読むもの】
- vN/docs/ の要求仕様書・設計仕様書を読む。設計仕様書には契約（名前・引数・戻り値）と日本語の手順だけがあり、
  中身（コード）は無い。あなたがその契約と手順に従って中身を実装する。
- vN/tests/ のテストコード（test_*.py）は、別の担当（Web Claude）が契約と期待値から独立に書いて
  配置済み。書かない・置き直さない・書き換えない。import が通らないのはテスト側で直さない。実装側（下記の
  土台）の名前を揃えれば通る。直す向きは常に実装側。
- 実装チャットでは、テストの中身（assert・期待値・テスト本文）は読まない。走らせて赤・緑の結果だけ受け取る。
  赤になってもテストに合わせて実装を寄せない。設計仕様書と要求仕様書の計算例だけを根拠に実装を見直す。

【実装工程（ここから黙々と。CLAUDE.md の「実装の進め方」に従う）】
1. まず実装側の土台を置く：設計仕様書の全データ構造（dataclass など）と、全関数の空シグネチャ
   （中身は NotImplementedError）。空シグネチャには @spec を付けない。
   これで配置済みテストの import が通り、全テストが「赤（失敗）」で始まる（正しい出発点）。
2. 中項目（REQ-x.x）を依存順（下位のロジックを先に、上位を後に）で実装し、各関数に @id（DES-）と
   @spec（REQ-）を付ける。土台の行には3点ルールの日本語コメントを書く。各中項目で赤→緑を確認しながら進む。
   pytest は必ず .venv のもので走らせる。自己チェックの pytest は `pytest -q --tb=no`
   （合否と件数だけの表示）で走らせ、失敗の詳細（assert の中身・期待値）を画面に出さない
   （「テストの中身を読まない」を、失敗時の出力経由でも守るため。詳細はテスト実行チャットで見る）。
3. 大項目（REQ-2／3／4・5 など）の節目で、その大項目のテストが全部緑になったか、
   psdd.py extract と check の結果をまとめて報告し、一度止まる。この節目の停止は残す（甘い実装を
   素通りさせないため）。報告のうえで先へ進んでよいかは、AskUserQuestion で「次の大項目へ進むか
   （はい／いいえ）」と選択式で問う。
   例：python psdd.py extract vN/src vN/tests > vN/structure.json
       python psdd.py check  vN/structure.json vN/docs/spec_ids.json
   （この構造抽出・整合チェックは多機能モードのみ。単機能モードでは structure.json・spec_ids.json・タグが
   無いので実行しない＝この報告項目自体が無い。）
- 既存の通っているテストが、そのまま緑のままであることを各段階で確認する（リグレッションを起こさない）。
  差分対象のテストだけを赤→緑にする。既存の関数の契約は、変更対象でないかぎり変えない。
- 新規導入（v1）のときは、この項は該当しない（まだ保つべき既存の緑が無い）。

【止まる（安全弁）】
- 契約どおり実装してもテストが赤のまま／仕様に書かれていない判断が要る／テストか契約を変えるしかない、
  と感じたら、節目を待たず即座に止まって報告する。設計どおり実装したのに赤のままなら、自分で判定せず止まる。
  仕様にない判断は勝手に決めない。この安全弁の停止も残す。判断を仰ぐときは AskUserQuestion で、取りうる
  選択肢を示して問う（自由入力を求めない）。
実装チャットの目的は、設計どおりにコードを実装すること。最終的な「正しさの通し確認」は、別の
テスト実行チャットで行う。ここでの赤→緑確認は、その手前の自己チェックに留める。

最新版フォルダ（vN/）で、コードの実装だけを行うチャットです。CLAUDE.md のルールに従います。
実装の細かい作法（土台の置き方・依存順・タグ・土台コメント・安全のための停止）は CLAUDE.md に
常駐しているので、ここでは流れの指示だけにします。

【承認の受け取り方（このチャット全体の共通ルール）】
作業を止めて承認や判断を仰ぐときは、必ず AskUserQuestion を使い、選択肢（「はい／いいえ」や、
用意した候補）で提示する。自由記述での回答を求めない。ユーザーがボタンを押すだけで進められるようにする。
確認は、まとめられるものは1回にまとめる（一つずつ細切れに聞かない）。

【説明のしかた（このチャット全体の共通ルール）】
ユーザーに向けた地の文（計画の提示・報告・確認・進行中の説明）は、非エンジニアにも伝わる言葉で書く。
計画を出すときだけ平易にして、途中の報告や節目の報告を専門語のままにしない。チャット全体で同じ平易さを
保つ。初めて出す専門用語・コマンド・ファイル名・タグ（pytest／dataclass／extract・check／
structure.json／@spec・@id など）は、名前はそのまま示したうえで、それが何をするものかを短く一言添える
（名前は言い換えない。一度説明したら以後は繰り返さない）。平易にするのはユーザーに向けた会話だけで、
コードの中身・タグの記法・設計仕様書の契約といった成果物そのものは規約どおりに書く。

このチャットは3つの工程を、この順に行います。最初は【版フォルダの判定と引き継ぎ】で、どの版で作業する
かを確定します。次が【立ち上げ工程】で、環境を整えます。最後が【実装工程】で、設計どおり黙々と進めます
（節目と安全弁でだけ止まる）。前の工程が済んでから、次の工程に入ってください。

【版フォルダの判定と引き継ぎ（最初に必ず行う）】
作業対象は「最新版フォルダ」とする。まず、プロジェクトのルート直下にある版フォルダ（v1／v2／… の形の
フォルダ）を全て挙げ、番号が最大のものを最新版フォルダとみなす。ユーザーが作業対象の版を明示している
場合は、それを優先する。
最新版フォルダを決めたら、その中身の状態を、次の三つのどれかに判定して報告する。
- (A) 中身が揃っている（docs／tests／src が在り、その版だけで pytest が回せる。多機能ではさらに spec_ids.json。単機能に spec_ids.json は無いのが正常）：
  そのまま作業対象として、立ち上げ工程へ進む（整っていれば確認だけで飛ばしてよい）。ただし、変更フローの版で
  tests に差分テスト（今回追加分）しか無く、前版の既存テストが欠けているなら、これは「揃っている」ではなく
  (B) として扱い、前版の既存テストを引き継ぐ。
- (B) フォルダは在るが空、または中身が不完全（最大番号の版なのに docs や tests が無い、または振り分け前、
  または tests に差分テストしか無く前版の既存テストが欠けている）：
  一つ前の版（番号が一つ小さいフォルダ）から、この版に無いもの（実装 src／土台 pytest.ini 等／入力サンプル）
  を引き継ぐ。**テストも引き継ぐ**：前版 tests/ の既存テスト（test_*.py）のうち、テスト設計変更プロンプトの
  差分サマリーで「廃止・置換した観点（V-）」に挙がった分だけを除いて、この版の tests/ にコピーする。
  除外する V- は、テストの中身（assert・期待値）を読まずに、差分サマリーの記載だけで判定する（独立性を保つ）。
  この版が自前で持つ新しい成果物（新仕様書・差分テスト）は上書きしない——前版から運んだ既存テストに差分
  テストが加わって、リグレッション確認ができる完全な集合（例：V01〜V40＋差分 V46〜）になる。差分テストが
  既に在るからといって、前版の既存テストの持ち込みを省かない（省くと据え置くべき既存観点が丸ごと未検証に
  落ちる）。docs／src／tests への振り分けと、各ファイルの版文字列（.py 先頭の `# spec_version:`）の統一まで行う。
  これらの引き継ぎ計画を一つにまとめ、AskUserQuestion で「この引き継ぎを実行してよいか（はい／いいえ）」
  と一度だけ問う。「はい」なら一括実行し、「vN を vN-1 から引き継いで自己完結させました」と報告して
  立ち上げ工程へ進む。細かい移動ごとに個別の承認は取らない。
- (C) 版フォルダが一つも無い（新規プロジェクト）：v1 を作業対象とし、立ち上げ工程で構成を新規に整える。

判定の要点：最大番号の版フォルダが空でも、そこを最新版として扱い、前版から引き継いで埋める。中身のある
古い版（v1 など）を勝手に最新版とみなして、そこへ実装しない。どこへ実装するかを取り違えないために、この
工程を必ず最初に通す。

【立ち上げ工程（新規プロジェクトや、まだ構成が整っていない版フォルダのとき）】
手順の実体は CLAUDE.md の「立ち上げ」に定義してある（フォルダ構成の整理／psdd.py と pytest.ini の配置／
.venv の作成／requirements.txt の起こしと導入／外部サービスの SETUP.md 化／エディタ設定／起動スクリプト／
pytest の空回し確認）。このチャットでは、それを次のやり方で実行する：
- まずプロジェクトのルートと最新版フォルダの状態を確認し、不足を洗い出す。
- 何をするか（作るフォルダ・置くファイル・入れる依存など）を一つの計画にまとめて提示し、AskUserQuestion で
  「この立ち上げを実行してよいか（はい／いいえ）」と一度だけ問う。「はい」なら一括で実行し、終わったら
  「環境が整いました」と、何をしたかの結果を報告する。ステップごとに個別の承認は取らない。
- 例外として、外部サービス（Ollama・モデル取得・GPU など）に実際に触れる操作と、共通 .venv への
  ライブラリ導入（pip install）だけは、システムを変える度合いが大きいので、実行の直前に AskUserQuestion で
  もう一度だけ確認する（導入する依存の一覧を見せ、「入れてよいか（はい／いいえ）」）。ここも自由入力は
  求めない。

ここまで済んでいる版フォルダ（構成も .venv も整っている）なら、この工程は確認だけで飛ばしてよい。

【読むもの】
- vN/docs/ の要求仕様書・設計仕様書を読む。設計仕様書には契約（名前・引数・戻り値）と日本語の手順だけがあり、
  中身（コード）は無い。あなたがその契約と手順に従って中身を実装する。
- vN/tests/ のテストコード（test_*.py）は、別の担当（Web Claude）が契約と期待値から独立に書いて
  配置済み。書かない・置き直さない・書き換えない。import が通らないのはテスト側で直さない。実装側（下記の
  土台）の名前を揃えれば通る。直す向きは常に実装側。
- 実装チャットでは、テストの中身（assert・期待値・テスト本文）は読まない。走らせて赤・緑の結果だけ受け取る。
  赤になってもテストに合わせて実装を寄せない。設計仕様書と要求仕様書の計算例だけを根拠に実装を見直す。

【実装工程（ここから黙々と。CLAUDE.md の「実装の進め方」に従う）】
1. まず実装側の土台を置く：設計仕様書の全データ構造（dataclass など）と、全関数の空シグネチャ
   （中身は NotImplementedError）。空シグネチャには @spec を付けない。
   これで配置済みテストの import が通り、全テストが「赤（失敗）」で始まる（正しい出発点）。
2. 中項目（REQ-x.x）を依存順（下位のロジックを先に、上位を後に）で実装し、各関数に @id（DES-）と
   @spec（REQ-）を付ける。土台の行には3点ルールの日本語コメントを書く。各中項目で赤→緑を確認しながら進む。
   pytest は必ず .venv のもので走らせる。自己チェックの pytest は `pytest -q --tb=no`
   （合否と件数だけの表示）で走らせ、失敗の詳細（assert の中身・期待値）を画面に出さない
   （「テストの中身を読まない」を、失敗時の出力経由でも守るため。詳細はテスト実行チャットで見る）。
3. 大項目（REQ-2／3／4・5 など）の節目で、その大項目のテストが全部緑になったか、
   psdd.py extract と check の結果をまとめて報告し、一度止まる。この節目の停止は残す（甘い実装を
   素通りさせないため）。報告のうえで先へ進んでよいかは、AskUserQuestion で「次の大項目へ進むか
   （はい／いいえ）」と選択式で問う。
   例：python psdd.py extract vN/src vN/tests > vN/structure.json
       python psdd.py check  vN/structure.json vN/docs/spec_ids.json
   （この構造抽出・整合チェックは多機能モードのみ。単機能モードでは structure.json・spec_ids.json・タグが
   無いので実行しない＝この報告項目自体が無い。）
- 既存の通っているテストが、そのまま緑のままであることを各段階で確認する（リグレッションを起こさない）。
  差分対象のテストだけを赤→緑にする。既存の関数の契約は、変更対象でないかぎり変えない。
- 新規導入（v1）のときは、この項は該当しない（まだ保つべき既存の緑が無い）。

【止まる（安全弁）】
- 契約どおり実装してもテストが赤のまま／仕様に書かれていない判断が要る／テストか契約を変えるしかない、
  と感じたら、節目を待たず即座に止まって報告する。設計どおり実装したのに赤のままなら、自分で判定せず止まる。
  仕様にない判断は勝手に決めない。この安全弁の停止も残す。判断を仰ぐときは AskUserQuestion で、取りうる
  選択肢を示して問う（自由入力を求めない）。
実装チャットの目的は、設計どおりにコードを実装すること。最終的な「正しさの通し確認」は、別の
テスト実行チャットで行う。ここでの赤→緑確認は、その手前の自己チェックに留める。

CLAUDE.mdの中身や、Claude Codeの導入手順は、別の記事にまとめています。

できたコードは、何をしているか

できたコードは、入力を確認し、APIに渡し、返ってきた画像を保存する、という一本の流れです。画面から受け取ったプロンプトや画像を確かめ、サイズが範囲外なら弾き、モデルと品質を固定してリクエストを組み立て、APIを呼びます。成功したら、指定の形式に変換し、日時の名前で指定フォルダに保存します。失敗したら、原因を表示して、その1件は保存せず次を待ちます。ここではソフトが動く筋だけを追います。動かすのに必要なキーの用意は、次の見出しで扱います。

どこまでテストしたか

単機能モードなので、コードにタグを付けたり、要求とテストの対応表を作ったりはしません。期待値表の確定した行を、そのまま1行1テストのpytestに落としました。pytestは、Pythonのテストを自動で走らせる道具です。テストしたのは、APIを呼ぶ前の入力の確認（空欄・非対応・サイズの内と外）と、APIから返った後の保存・命名・固定値です。API本体は、テストの中では偽の応答に差し替え、実際には呼びません。だから、生成された画像そのものはテストしていません。画像の正解が一つに定まらないからです。

APIキーは、発行して、隠して使う

ここまでで、道具の中身はできました。あとは、APIを呼ぶための鍵を用意すれば動きます。この鍵をAPIキーと呼びます。キーは有料サービスを受け取るための合鍵なので、発行の手順と、他人に渡さないための置き方を押さえます。

OpenAIでアカウントを作り、キーを発行する

APIキーは、OpenAIのアカウントを作り、支払いを登録すると発行できます。支払いは前払いのチャージ方式で、登録した残高の範囲内だけで使えます。次の4つの手順で、キーを手に入れて、道具から読める場所に置くところまで進めます。金額の確認や上限の話は、次の見出しでまとめて扱います。

別のサイト、別の方が書いた記事になりますが、こちらが参考になります。最新情報を検索して参照してください。

STEP

アカウントを作る

OpenAIの開発者向けサイト（platform.openai.com）で、APIプラットフォームにログイン、またはアカウントを作ります。

STEP

支払いを登録する

クレジットカードを登録し、前払いで残高をチャージします。以後は、この残高の範囲内でだけ課金されます。

STEP

キーを発行する

APIキーを1つ発行します。キーの全体は発行の直後にしか表示されないので、その場で控えます。

STEP

キーを.envに置く

控えたキーを、ソースコードとは別の.envファイルに書きます。道具は、このファイルからキーを読んで動きます。

画面の名称やボタンの位置は、時期によって変わることがあります。実際の画面と見比べながら進めてください。

キーは.envに置き、ソースに直書きしない

.envは、設定値を書いておく隠しファイルです。名前がドットで始まり、キーのような秘密を、コード本体から分けて置くために使います。道具は、python-dotenv（.envなどを読み込むためのpythonのライブラリー）を通じて、この.envからキーを読み込みます。ここで守るべきことは一つで、キーをコードに直書きしないことです。コードに値を直接書き込むことをハードコードと言いますが、これをやると、コードを共有したり配布したりしたときに、キーごと他人へ渡ってしまいます。
　画像は.env.exsampleのファイル内容です。.env.exsampleを.envにファイル名を書き換えてOpenAIで発行したAPI_KEYをコピーペーストして使います。わからないときはClaude Codeに聞いてみると対応してくれます。

注意

APIキーは、コードやbatファイルに直接書かないでください。GitやSNS、配布物にコードを載せたとき、キーごと他人に渡り、無断で使われて課金されます。キーは.envに分け、.envは共有・アップロードの対象から必ず外します。

キーを置いたら、動かして確認する

キーを.envに置いたら、道具を起動します。起動はbatファイルから行い、黒いコンソール窓は非表示にしてあります。画面が立ち上がったら、作りたい画像のプロンプトを入れて、生成します。うまくいけば、指定したフォルダに、日時の名前で画像が保存されます。保存された画像を開いて、狙いどおりのものが出ているかを、自分の目で確かめます。

実際に作った画像が以下の画像になります。シンプルな図を生成してしまいましたが、ChatGPT Image 2.0の画像生成機能と同等なので、もっと複雑な画像生成も対応できます。また画像を添付してその画像をもとに修正や変更もリクエストできる仕様です。

お金が絡む処理には、安全装置を効かせる

このツールは、使うたびにお金がかかります。だから、使いすぎを防ぐ仕組みを効かせておきます。今回は、前払いの残高がその役目を果たします。仕組みそのものは特別なものではありませんが、お金が絡む道具では、どこかに歯止めがある状態にしておく、という考え方が大事です。

使った金額は、OpenAIのサイトで確認する

いくら使ったかは、OpenAIのサイト「Usage」のタブで確認できます。日ごとの使用量や、これまでにかかった金額、残っている残高を見る画面があります。ツールの中に金額を表示する仕組みは持たせず、お金の管理はこのサイト側に任せます。使い始めのうちは、その日にいくら使ったかをときどき見ておくと、感覚がつかめます。

前払いだから、チャージ残高で自動的に止まる

このAPIは前払いです。先にチャージした残高の範囲でしか使えず、残高が尽きればそこで止まります（オートチャージ機能もあるので気をつけて）。だから、使いすぎて青天井になることはありません。ツールの中に金額の上限を計算する仕組みを入れていないのは、このためです。OpenAIのサイト側には使用量の上限を設定する機能もあり、これも安全装置として使えます。

ポイント

お金が絡む処理は、どこかに安全装置がある状態にしておきます。今回はそれが前払いの残高です。ツールに上限を持たせなくても、残高が尽きれば止まる、という歯止めが常に効いています。

複数回まとめて呼ぶなら、ツール側にも歯止めが要る

今回のツールは、1回の操作で1枚だけ生成します。だから、暴走する余地はほとんどありません。ただし、ソフトウェアを発展させて、複数のプロンプトを一括で回したり、繰り返し自動で生成したりする形に広げると、話が変わります。何度もリクエストが飛び、意図しないうちに残高を使い切ることがあります。コードのバグ、エージェントに実行依頼を出すことで意図せず、複数回APIを使うなどの潜在的なリスクがあります。機能を拡張するとき、安全装置は、動かす側にも置いておくと安心です。

注意

複数回・自動で回す拡張をするときは、前払い残高だけに頼らず、ツール側にも歯止め（回数の上限など）を入れてください。1回1枚のうちは要りませんが、まとめて呼ぶ形にした瞬間、リスクの大きさが変わります。

この道具は、次にどう伸ばせるか

今回作ったのは、プロンプトから1枚の画像を生成して保存するだけの、小さな道具です。ただ、APIで画像生成を切り出せたことで、次に伸ばせる方向がいくつか見えてきます。どれも、いまの1機能に何かを足すかたちで広げられます。

会議の要約から、内容を一枚にまとめたサマリー画像を作る。文章では読み飛ばされがちな結論を、絵にして残す。
複数のプロンプトを一括で渡し、まとめて生成する。挿絵の候補を一度に何枚も出して、あとから選ぶ。
プロンプトのメモリー機能を追加して、ブログの挿絵の定型プロンプトをテンプレート化し、同じ調子の絵をそろえて量産する。
生成した画像を、手元の画像加工の流れにそのまま渡し、幅や形式を整えるところまで自動でつなぐ。

もう一歩進めると、別のAPIや別のシステムと掛け合わせる道もあります。たとえば、会議の音声を文字起こしするAPIで要約を作り、その要約からサマリー画像を生成する、というように、複数のAPIをつなぐ使い方です。ただし、こうして機能が増えると、今回の単機能モードでは収まらなくなります。掛け合わせで工程が増える作り方は、設計仕様書やテスト設計を戻す多機能モードの領分です。次のショーケースでは、2つのAPIをつなぐ最小の例を扱います。