曖昧な指示をAI作業指示書に改善し、期待結果と照合して修正する

原稿の管理表（13項目：記事ID・カテゴリ・要件ID・先に読むと理解しやすい記事・成果物パス・対象ツール・検証状況・最終更新日など）

管理項目	内容
記事ID	07-03
主な中カテゴリ	07-03 指示・検証・修正の手順を決める
関連中カテゴリ	07-01、07-02、02-04、08-01、09-02
関連要件ID	REQ-003、REQ-004
先に読むと理解しやすい記事	07-02（作業を小さく分ける）を読んでいると理解しやすい。未読でも本文で必要な内容は説明する
到達目標	曖昧な依頼の問題点と、成果物・期待結果・証拠・やり直し方を含む指示の構造を説明できる
3層の配置	理解する＝第3〜4節／作って確かめる＝第5〜7節／設計を判断する＝第8節
成果物パス	templates/07-03-ai-work-order_template.md、templates/07-03-ai-work-order_example.md、examples/07-03-ai-work-order/（approval-draft.js、approval-fixed.js、verify.js）、evidence_public/remediation1-2026-09-20/07-03/run_log.md
出典	第11節参照
対象ツール・バージョン	教材演習用にNode.js v24.18.0（標準機能のみ使用、追加のパッケージは導入していない）
検証状況	本文の検証コードは examples/07-03-ai-work-order/ を正本とし、Claude Codeが2026-09-20にローカルで実行して stdout・stderr・終了コードを記録済み（第7節、evidence_public/remediation1-2026-09-20/07-03/run_log.md）。人による実読・内容確認は未実施
残課題	第11節参照
最終更新日	2026-09-20（新規作成。同日、Remediation Phase 1：検証コードを examples/ の正本と一致させ、終了コードを実装に基づく実測に改めた。同日、Phase 5B-2B：読む順路・第3.3節「この検証で分かること・分からないこと」・第4節の判断項目・AI WORKFLOW・CHECKLIST・記事間の参照を追加。指示書・コード・実行結果・実行記録は不変）

この記事の会社・人物・コードはすべて架空の設定です。実在する会社や案件とは関係ありません。本文の検証コードは examples/07-03-ai-work-order/ の正本と同じもので、実行結果（stdout・終了コード）は2026-09-20にローカル環境で実際に実行して記録したものです（第7節、実行記録は第9節）。

この記事は何の話か。「承認できるようにして」という曖昧な指示を、成果物・期待結果・証拠・やり直し方を含むAI作業指示書に改善し、AIの初稿（という設定のコード）を、要件から先に決めた期待結果と照合して、不備を見つけて修正する話です。

なぜ必要か。曖昧な指示のままAIに作業を依頼すると、何を作ればよいか、どうなれば完成かが人によってもAIによっても解釈が変わり、要件を満たさない結果になりやすくなります。

この記事を読むとできるようになること。

• 曖昧な依頼の問題点と、指示に含めるべき要素（成果物・期待結果・証拠・やり直し方）を説明できる
• 曖昧な指示をAI作業指示書に改善できる
• AIの初稿を、要件から先に決めた期待結果と照合し、不備を見つけて修正を指示できる
• この検証がPASSして何が分かり、何が分からないかを言え、なぜ期待結果を人が決めるのかを説明できる

読む順路。この記事は3つの深さで読めます。全部を順に読む必要はありません。

• 基本だけ理解する：第1節→第3節（指示の構造が必要な理由、この検証で分かること・分からないこと）→第4節（判断すること）→第5.2節の指示書→第6.1節の照合結果の日本語→第9節。コードを読まなくても、指示書に何を書き、初稿のどこが要件に反していたかが分かります。
• 作って確かめる：上に加えて第5.3節（指示文）→第5.4節（初稿と検証コード）→第6節（初稿の実行結果、修正指示、修正後の実行結果）→第7節。
• 設計判断を深める：上に加えて第8節（AIの自己確認と人の独立した確認の役割分担、適用限界）。

1. 今回の業務課題と完成するもの

この記事でやることは、「承認できるようにして」という曖昧な指示を、REQ-003の条件・期待結果・確認手順・失敗時の差戻し方を含むAI作業指示書に改善し、その指示に基づいて作られた「初稿」（という設定のコード）を、期待結果と照合して不備を見つけ、修正することです。

07-02で作業を分解しましたが、それぞれの作業をAIにどう指示し、どう検証するかはまだ決めていません。この記事では、それを扱います。

この記事を読み終えると、次のものが手元にできます。

• AI作業指示書（目的、渡す資料、成果物、期待結果、証拠の形式、やり直し条件、人の確認点）
• 期待結果と実際の結果を照合する検証コードと、その実行記録（examples/07-03-ai-work-order/）

2. 前提知識と読む順路

この記事で使う言葉を先に説明します。

曖昧な指示

一言でいうと、何を作ればよいか、どうなれば完成かが明確でない依頼です。たとえば、「承認できるようにして」だけでは、誰が承認できるべきかが分かりません。

期待結果

一言でいうと、実装を作る前に、要件から先に決めておく「こうなるはず」という基準です。

これがないと、実装の出力に合わせて期待結果を書き換えてしまい、本当に要件を満たしているかを確認したことになりません。

証拠

一言でいうと、期待結果と実際の結果を照合した記録です。

読む順路：AIへ渡す資料は07-01、作業分解は07-02、受入条件は02-04（記事AのAC-001〜003）が該当します。この記事の指示書は、08-01（同じ構造の指示文で3条件の関数を頼む）、記事B（09-02）の検証の入力になります。

3. 理解する：なぜ指示の構造が必要か

3.1 曖昧な指示と改善後の指示

3.2 よくある誤解

「AIが『できました』と言えば完成」。「できた」という報告と、要件を満たしていることの確認は別です（09-02で詳しく扱います）。

「期待結果は実装ができてから決めればよい」。実装後に期待結果を決めると、実装の出力に合わせて書いてしまう危険があります。期待結果は要件から先に決めます（第5.2節）。

「AIの自己確認で十分」。AI自身がもう一度見ても、独立した確認にはなりません。要件から先に決めた期待結果との照合が必要です（第8節）。

「終了コードが0なら合格、1なら不合格」。この記事の終了コード1は「検証が壊れた」ではなく「やり直し条件に該当した」という意味で、検証としては正しく働いています（第5.4節）。逆に、不一致があるのに0で終わる検証は、見た目は検証でも通ったことにできる検証です。

3.3 この検証で分かること・分からないこと

結論から言うと、この検証で証明したいのは「初稿が、要件（REQ-003）から先に決めた期待結果3件を満たすか」です。それ以上でも以下でもありません。

なぜこの検証で不備を見つけられるのか。期待結果を実装より先に、要件から決めているからです。期待結果の2件目「提出済み・自己承認 → false」はREQ-003の「自己承認はできない」から来ています。初稿（第5.4節）は自己承認の条件を持たないので、この入力でtrueを返し、期待結果と食い違います。もし期待結果を初稿の出力を見てから書いていたら、2件目は「true」になり、不備は不備でなくなります。人が要件から期待結果を決めるのは、この一点のためです。

「3件一致・終了コード0」は「この3件で期待どおり」の証拠であり、「関数が正しい」の証拠ではありません。

4. 判断すること

指示書を作り、初稿を検証するときに人が判断することは、次の5つです。

勝手に決めてはいけないこと：期待結果を、AIの初稿の出力に合わせて後から書き換えません。07-02にない作業を、この記事で新しく作りません。検証コード（verify.js）を初稿に合わせて緩めません。

AIに任せる範囲：指示書に基づいてコードを書くこと、検証コードを実行して出力をそのまま返すこと、不一致の原因の説明はAIに任せられます。任せてはいけないのは、期待結果を決めること、やり直し条件に該当するかの判断、修正を採用するかの判断です。AIに「自分で確認して」と頼んでも、同じ前提の上での再確認であり、独立した確認にはなりません（第8.1節）。

5. 作って確かめる：AI作業指示書を作り、初稿を検証する

5.1 準備

07-01の情報セット、07-02の作業分解、02-04の受入条件を用意します。

5.2 AI作業指示書

5.3 指示文（AIへ渡す文章そのもの）

第5.2節の指示書を、AIへ実際に渡す文章にすると次のようになります。渡す資料は07-01の情報セットの該当部分だけで、秘密情報・実データは含めません。この文章は説明のために書いた例で、実際にAIへ送信した記録ではありません。

承認可否を判定する関数 canApprove(state, isSelf) を JavaScript（Node.js 標準機能のみ）で実装してください。

渡す資料：
- 05-02 状態遷移表のうち「提出済み → 承認済み（承認）」の行
- 05-03 権限表のうち「承認者」の行（割当承認者のみ承認できる。自己承認は禁止：REQ-003）

期待結果（要件から先に決めたもの。実装に合わせて変えません）：
- state が「提出済み」で isSelf が false → true
- state が「提出済み」で isSelf が true  → false
- state が「提出済み」以外            → false

返し方：
- コードだけを返してください。動作の説明は不要です。
- 「できました」という報告ではなく、上の3件それぞれについて実際の戻り値を書いてください。

してはいけないこと：
- 期待結果を書き換えないでください。
- 上に無い条件（承認済みの取消など）を追加しないでください。

5.4 AIの初稿（説明用の設定）と検証コード

AIの初稿という設定のコードです。実際のAI出力を観測したものではなく、自己承認の条件をわざと抜いた説明用の失敗例です（examples/07-03-ai-work-order/approval-draft.js）。

// 「AIの初稿」という設定の説明用の失敗例。実際のAI出力を観測したものではない。
// 自己承認を禁止する条件（REQ-003）が抜けている。
function canApprove(state, isSelf) {
  if (state !== "提出済み") return false;
  return true; // 自己承認の条件が抜けている（説明用の不備）
}
module.exports = { canApprove };

期待結果と照合する検証コードです（examples/07-03-ai-work-order/verify.js）。期待結果（cases）は第5.2節の指示書から写したもので、実装より先に決めています。検証対象のファイル名を引数で受け取るので、初稿と修正後を同じコードで検証できます。

// 教材演習用：AI作業指示書（記事 第5.2節）の期待結果と、実装の実際の結果を照合する。
// 使い方: node verify.js approval-draft.js   （初稿の検証）
//         node verify.js approval-fixed.js   （修正後の検証）
// 期待結果は実装より先に、要件（REQ-003）から決めたもの。実装の出力に合わせて書き換えない。
// 1件でも不一致があれば終了コード1で終わる（指示書の「やり直し条件」を機械的に判定できるようにするため）。
const path = require("node:path");

const target = process.argv[2];
if (!target) {
  console.error("使い方: node verify.js <検証対象のファイル名>");
  process.exit(2);
}
const { canApprove } = require(path.resolve(__dirname, target));

const cases = [
  { state: "提出済み", isSelf: false, expected: true, label: "正常な承認" },
  { state: "提出済み", isSelf: true, expected: false, label: "自己承認は拒否" },
  { state: "下書き", isSelf: false, expected: false, label: "未提出は拒否" },
];

console.log(`検証対象: ${target}`);
let failed = 0;
for (const c of cases) {
  const actual = canApprove(c.state, c.isSelf);
  const ok = actual === c.expected;
  console.log(`${ok ? "OK" : "NG"}: ${c.label} 期待=${c.expected} 実際=${actual}`);
  if (!ok) failed++;
}
console.log(`結果: ${cases.length - failed}/${cases.length} 件一致`);
if (failed > 0) {
  console.log("不一致あり。指示書の「やり直し条件」に該当する（修正して再検証する）");
  process.exit(1);
}
console.log("すべて一致。採用判断（人）へ進める");
process.exit(0);

「入力→判断・処理→出力→失敗時」の対応：

終了コードを分ける理由。画面に「NG」と出るだけでは、人が読み落とせば「できた」として次へ進んでしまいます。終了コードが 1 なら、この検証を人が目で追わなくても「不一致があった」ことを機械的に判定でき、指示書の「やり直し条件」（1件でも不一致なら修正して再検証）をそのまま自動化できます。逆に、不一致があるのに終了コードが 0 で終わる検証は、見た目は検証でも「通ったことにできる検証」です。

6. 初稿の検証結果と修正

6.1 初稿の実行結果

examples/07-03-ai-work-order/ で実行した stdout と終了コードです（整形・省略なし。stderr への出力はありませんでした）。

$ node verify.js approval-draft.js
検証対象: approval-draft.js
OK: 正常な承認 期待=true 実際=true
NG: 自己承認は拒否 期待=false 実際=true
OK: 未提出は拒否 期待=false 実際=false
結果: 2/3 件一致
不一致あり。指示書の「やり直し条件」に該当する（修正して再検証する）
終了コード: 1

「自己承認は拒否」の期待結果（false）に対し、実際の結果はtrueでした。REQ-003（自己承認禁止）を満たしていません。終了コードが 1 なので、指示書の「やり直し条件」に該当します。

6.2 修正指示

指摘：
1. 「自己承認は拒否」の期待結果（false）に対し、実際はtrueが返っています。isSelfがtrueの場合にfalseを返す条件を追加してください。

変えないこと：
- 期待結果（第5.2節）は変更しないでください。実装の出力に合わせて期待結果を書き換えることはしません。
- 検証コード（verify.js）は変更しないでください。

6.3 修正後のコードと実行結果

修正後のコードです（examples/07-03-ai-work-order/approval-fixed.js）。

// 修正指示（記事 第6.2節）を反映した修正後のコード。
function canApprove(state, isSelf) {
  if (state !== "提出済み") return false;
  if (isSelf) return false; // 修正：自己承認は拒否する（REQ-003）
  return true;
}
module.exports = { canApprove };

同じ検証コードで再検証した stdout と終了コードです（整形・省略なし。stderr への出力はありませんでした）。

$ node verify.js approval-fixed.js
検証対象: approval-fixed.js
OK: 正常な承認 期待=true 実際=true
OK: 自己承認は拒否 期待=false 実際=false
OK: 未提出は拒否 期待=false 実際=false
結果: 3/3 件一致
すべて一致。採用判断（人）へ進める
終了コード: 0

7. 確認結果

第5〜6節の内容を、実際にローカル環境で実行した結果と照合します。

実行環境：macOS 26.6.2、Node.js v24.18.0（標準機能のみ）、2026-09-20に実行。実行場所は examples/07-03-ai-work-order/。stdout・stderr・終了コードをそのまま記録した実行記録は第9節の run_log.md にあります。

この記事で検証しているのは、「初稿が、要件（REQ-003）から先に決めた期待結果を満たすか」です。確かめたことは3点です。期待結果を実装に合わせて動かしていないこと、不一致を終了コードで機械的に検出できること、修正後も同じ検証コードで再検証していること。検証コードを変えずに初稿と修正後の両方を通すことで、「修正で直った」ことと「検証を緩めて通した」ことを区別しています。

完了条件との照合：

残る制限：この検証は、教材演習用に用意した小さなコードに対するものです。「AIの初稿」は説明用の設定であり、実際のAIがこの指示文でどんなコードを返すかは観測していません。実際のアプリ全体の実装・検証は08・09で扱います。この記事の本文はClaude Codeが作成したもので、業務担当者による内容確認は行っていません。

8. 設計を判断する

8.1 AIの自己確認と人の独立した確認の役割分担

失敗の影響が大きい要件（REQ-003のような権限に関わるもの）ほど、人による確認の重みを大きくする方針とします。

8.2 適用限界

この指示書・検証は、承認可否の判定という小さな例に基づいています。実際のアプリ全体では、09（テスト・レビュー）でより広い範囲の検証を行います。

9. 持ち帰る成果物

自分の業務に使うときの手順は次のとおりです。

1. 前工程（情報セット、作業分解、受入条件）を用意する
2. 曖昧な指示を、成果物・期待結果・証拠の形式・やり直し条件を含む指示書に改善する
3. 期待結果を要件から先に決める（実装後に書き換えない）
4. 初稿を期待結果と照合し、不一致があれば修正指示を出す
5. PASSで分かること・分からないことを分けて書き、範囲外を次の記事へ渡す

10. 次工程への受渡し

次へ渡すもの：AI作業指示書、期待結果と照合する検証コード（verify.js）と実行記録。

次工程での使われ方：08-01では、この指示文と同じ構造で、割当を加えた3条件の関数を頼み、初稿を期待結果4件と照合します。09-01では、複数の壊れ方に対する検出力を確かめます。記事B（09-02）では、この検証の考え方を保存先の中身まで含む12場面に広げます。

前工程へ戻る条件：指示書が07-01・07-02の内容と食い違う場合は、それぞれの記事に戻って確認します。

11. 根拠と更新情報

• この記事の会社・人物・コードはすべて架空の設定です。
• 第5.4節の初稿は説明用の失敗例であり、実際のAI出力を観測した記録ではありません。第5.3節の指示文は、この記事のために書いた指示文の例であり、実際にAIへ送信した記録ではありません。
• 期待結果を要件から独立に決め、実装の出力に合わせて書き換えないという考え方は、記事Bの検証の考え方と一致させています。
• 制作の来歴：本文はClaude Codeが作成しました。第5.4節・第6節の検証コードは examples/07-03-ai-work-order/ を正本とし、2026-09-20にmacOS 26.6.2・Node.js v24.18.0の環境で実際に実行して、stdout・stderr・終了コードを evidence_public/remediation1-2026-09-20/07-03/run_log.md に記録しています。人（ユーザー）による実読・内容確認は未実施です。
• 2026-09-20（Remediation Phase 1）：受入監査で「掲載コードは終了コード0で終わるのに、本文は終了コード1と記載」と指摘された。初版の掲載コードには不一致件数を終了コードに反映する処理が無く、本文の終了コードは実測ではなかった。検証コードを examples/ の正本として作り直し（不一致があれば process.exit(1)）、本文のコードと実行結果を正本の実測に置き換えた。期待結果・修正指示・結論は変えていない。
• 2026-09-20（Phase 5B-2B）：読む順路（3つの深さ）、第3.2節の終了コードの誤解、第3.3節「この検証で分かること・分からないこと」、第4節の判断項目、AI WORKFLOW、CHECKLIST、記事間の参照を追加した。指示書・指示文・コード・実行結果・実行記録（Remediation Phase 1）は変えていない。
• 未確認事項：この検証は教材演習用の小さな例であり、アプリ全体の検証は08・09で行います。3件以外の入力と、自己承認以外の壊れ方に対する検出力は確かめていません（第3.3節）。