「承認可否」を判定する最小の関数を作り、入力を変えて確かめる

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

管理項目	内容
記事ID	08-01
主な中カテゴリ	08-01 最小の処理を動かす
関連中カテゴリ	06-01、07-03、08-02、09-01
関連要件ID	REQ-003
先に読むと理解しやすい記事	07-03（指示・検証・修正の手順を決める）を読んでいると理解しやすい。未読でも本文で必要な内容は説明する
到達目標	変数・型・条件分岐・繰り返し・関数の役割を、「状態が提出済みなら承認できる」という判定文で説明できる
3層の配置	理解する＝第3〜4節／作って確かめる＝第5〜7節／設計を判断する＝第8節
成果物パス	templates/08-01-minimal-example_template.md、templates/08-01-minimal-example_example.md、examples/08-01-minimal-example/（approval.js、approval-draft.js、run.js）、evidence_public/phase5b1-2026-09-20/08-01/run_log.md
出典	第11節参照
対象ツール・バージョン	教材演習用にNode.js v24.18.0（06-01で確認済み。標準機能のみ使用、追加のパッケージは導入していない）
検証状況	本文のコードは examples/08-01-minimal-example/ を正本とし、Claude Codeが2026-09-20にローカルで実行して stdout・stderr・終了コードを記録済み（第6〜7節、evidence_public/phase5b1-2026-09-20/08-01/run_log.md）。第5.3節の指示文と初稿は説明用の例であり、実際にAIへ送信・観測した記録ではない。人による実読・内容確認は未実施
残課題	第11節参照
最終更新日	2026-09-20（新規作成。同日、Phase 5B-1：Build型のPilotとして、読む順路・第4節の判断項目・第5.3節「AIに最小の関数を頼む」（渡す情報・指示文）・第6節の初稿→人のレビュー→修正→再実行の流れを追加。run.js に検証対象を引数で指定できる機能を足し、初稿（approval-draft.js）と修正後（approval.js）を同じ手順で実行した実測に置き換えた。判定条件・修正後のコード・完了条件は不変）

この記事の会社・人物・数値はすべて架空の設定です。実在する会社や案件とは関係ありません。本文のコードは examples/08-01-minimal-example/ の正本と同じもので、実行結果は2026-09-20にローカル環境で実際に実行して記録したものです（第6〜7節、実行記録は第9節）。第5.3節の指示文と第5.4節の初稿は説明用の例で、実際のAI出力を観測したものではありません。

この記事は何の話か。「依頼の状態が提出済みで、割り当てられた承認者で、自己承認でなければ、承認できる」という判定を行う最小の関数を、AIに作らせ、初稿の不備を人が見つけて直させ、実際に動かして確かめる話です。

なぜ必要か。いきなりアプリ全体を作ろうとすると、何が正しく動いているかを確認しづらくなります。まず最小の処理を作り、動きを確かめてから広げていきます。また、AIに頼めば速く書けますが、「書けた」と「要件どおり」は別です。最小の例で、AIの初稿を人が確認して完成させる流れを身につけます。

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

• 変数・型・条件分岐・繰り返し・関数の役割を、判定文の例で説明できる
• AIに最小の関数を頼むときに、何を渡し、何を指示し、初稿の何を確認するかを決められる
• 入力を変えて出力を確認し、期待結果と照合して不備を見つけ、修正させて再確認できる
• 最小例をアプリ全体に広げるときに何が足りないかを説明できる

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

• 基本だけ理解する：第1節→第3節（判定文を分解する）→第4節（判断すること）→第5.2節（判定の設計）→第6.2節の照合表（初稿のどこが違ったか）→第9節。コードを書かなくても、「変数・条件分岐・関数」が判定文のどの部分かと、AIの初稿を人がどう見つけたかが分かります。
• 作って確かめる：上に加えて第5.3節（渡す情報と指示文）→第5.4節（初稿と修正後のコード）→第5.5節（入力を変えて確認するコード）→第6節（初稿の実行結果、レビュー、修正指示、修正後の実行結果）→第7節。
• 設計判断を深める：上に加えて第8節（アプリ全体に広げるときに足りないもの、適用限界）。

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

この記事でやることは、依頼の状態・割当承認者かどうか・自己承認かどうかを入力にして、承認できるかどうか（true／false）を返す最小の関数を作り、いくつかの入力パターンで実際に動かして確認することです。関数はAIに書かせ、人は「何を渡すか」「初稿のどこを確かめるか」「直ったか」を担当します。

07-03で「AIへの指示と期待結果との照合」という考え方を扱いましたが、その対象は状態と自己承認の2条件だけでした。この記事では、記事AのREQ-003（割り当てられた承認者だけが承認でき、自己承認はできない）を3条件に分けた判定関数を作ります。

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

• 承認可否を判定する最小の関数と、初稿（説明用の失敗例）、入力を変えて確認する実行コード（examples/08-01-minimal-example/）
• 最小の動作例・説明（目的、入力、処理の説明、出力、実行環境、実行確認済み／未検証）
• AIに最小の関数を頼むときの渡す情報と指示文

2. 前提知識と読む順路

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

変数

一言でいうと、値に名前を付けて一時的に覚えておく仕組みです。たとえば、判定結果をoutputという名前で覚えておきます。

データ型

一言でいうと、値がどんな種類か（真偽値、文字列など）の分類です。たとえば、この記事の関数が返す値は「true」か「false」のどちらかで、これを真偽値（boolean）と呼びます。

条件分岐

一言でいうと、「もし〜なら」という条件によって、処理を変えることです。たとえば、「状態が提出済みでなければ、承認できないと判定する」というのが条件分岐です。

繰り返し

一言でいうと、同じ処理を複数のデータに対して繰り返すことです。たとえば、複数の入力パターンに対して、同じ関数を繰り返し呼び出すことです。

関数

一言でいうと、入力を受け取り、決まった処理を行い、出力を返すひとまとまりの処理です。

たとえば、この記事のcanApproveは、状態・割当・自己承認の3つを受け取り、承認できるかどうかを返します。

これがないと、同じ判定のロジックをあちこちに書き散らすことになり、修正のたびにすべての箇所を直す必要が出てきます。

システム開発では、こうした部品を関数（function）と呼び、画面や保存処理から呼び出して使います。08-03のサーバーが、権限判定をこの形の関数で行うのはその例です。

読む順路：作業環境は06-01、AIへの指示・検証は07-03が該当します。この記事の最小例は、08-02（入力・計算・保存をつなぐ）、09-01（個々の処理を確認する）で使います。

3. 理解する：判定文を分解する

3.1 「状態が提出済みなら承認できる」を分解する

実際の判定は、07-03・05-03で確認したとおり、状態だけでなく権限も関わります。REQ-003を判定文にすると「状態が提出済みで、かつ割当承認者で、かつ自己承認でないなら、承認できる」です。

3.2 よくある誤解

「最小の例だから、権限までは考えなくてよい」。最小の例であっても、REQ-003（自己承認禁止）のような重要な条件は含めます。省略してよいのは、保存・履歴・通信など、この記事の範囲外の部分です（第8節）。

「動けば正しい」。動くことと、要件を満たしていることは別です。この記事の初稿は、4パターンすべてがエラーなく動きますが、1パターンで要件に反する結果を返します（第6.1節）。

「AIが書いたコードは、AIが確認している」。AIは「動作確認しました」と返しますが、確認した範囲はAIが思いついた範囲です。割当外の承認者という場面を渡していなければ、その場面は確認されません（記事B）。

4. 判断すること

AIに関数を頼む前に、人が決めることが3つあります。

4.1 この記事で判断すること

4.2 勝手に決めてはいけないこと

• 05-02の状態遷移表、05-03の権限表にない条件を、この記事で追加しません。
• 期待結果を、初稿の出力に合わせて書き換えません。
• この最小の関数だけで、アプリ全体の権限・保存・履歴が保証されたことにしません（第8節）。

4.3 AIに任せる範囲

判定条件を関数の形に書くこと、入力を変えて実行するコードを書くこと、実行して出力をそのまま返すことはAIに任せられます。任せてはいけないのは、判定条件と期待結果を決めること（第4.1節）と、初稿の出力を期待結果と照合して採用・修正を決めること（第6.2節）です。AIに「自分で確認して」と頼んでも、同じ前提の上での再確認であり、独立した確認にはなりません。

5. 作って確かめる：最小の関数をAIに頼み、入力を変えて確認する

5.1 準備

06-01で確認したNode.jsの実行環境、07-03で扱った期待結果の考え方（AI作業指示書の「期待結果」欄）、05-02・05-03の設計を用意します。

5.2 判定の設計と期待結果（実装より先に決める）

REQ-003を、入力3つと出力1つの関数として設計します。

期待結果は、実装を見る前に、要件から次の4パターンで決めます。

5.3 AIに最小の関数を頼む

渡す情報と、渡さない情報を先に決めます。

指示文は次のとおりです。07-03の指示文と同じ構造（渡す資料・期待結果・返し方・してはいけないこと）です。これは説明のために書いた例で、実際にAIへ送信した記録ではありません。

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

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

入力と出力：
- state：依頼の状態（文字列）。isAssignedApprover：割当承認者か（真偽値）。isSelf：依頼者本人か（真偽値）
- 承認できるなら true、できないなら false を返す。例外は投げない

期待結果（要件から先に決めたもの。実装に合わせて変えません）：
- 提出済み・割当承認者・本人でない → true
- 下書き・割当承認者・本人でない → false
- 提出済み・割当外・本人でない → false
- 提出済み・割当承認者・本人 → false

返し方：
- approval.js（関数を module.exports で公開）と、上の4パターンを順に呼び出して結果を表示する run.js の2ファイルを返してください。
- 「できました」という報告ではなく、run.js を実行した出力をそのまま貼ってください。

してはいけないこと：
- 保存・履歴・通信は書かないでください。判定だけです。
- 期待結果を書き換えないでください。
- 上に無い条件（承認済みの取消など）を追加しないでください。

5.4 AIの初稿（説明用の設定）と修正後のコード

AIの初稿という設定のコードです。実際のAI出力を観測したものではなく、割当承認者の判定をわざと抜いた説明用の失敗例です（examples/08-01-minimal-example/approval-draft.js）。エラーなく動き、4パターンのうち3つは期待どおりになる、という「見た目は正しい」不備にしています。

// 「AIの初稿」という設定の説明用の失敗例。実際のAI出力を観測したものではない。
// 割当承認者かどうかの判定（isAssignedApprover）が抜けている。
function canApprove(state, isAssignedApprover, isSelf) {
  if (state !== "提出済み") return false;      // 条件分岐1：状態を判定
  if (isSelf) return false;                     // 条件分岐2：自己承認でないかを判定
  return true;                                  // 割当承認者かどうかを見ていない（説明用の不備）
}
module.exports = { canApprove };

修正後のコードです（examples/08-01-minimal-example/approval.js）。第6.3節の修正指示を反映し、条件分岐が3つになっています。

// 依頼の状態と操作者の役割を入力に、承認可否を返す最小の関数（教材演習用）
function canApprove(state, isAssignedApprover, isSelf) {
  if (state !== "提出済み") return false;      // 条件分岐1：状態を判定
  if (!isAssignedApprover) return false;        // 条件分岐2：割当承認者かを判定
  if (isSelf) return false;                     // 条件分岐3：自己承認でないかを判定
  return true;
}
module.exports = { canApprove };

「入力→判断・処理→出力→失敗時」の対応（修正後）：

5.5 入力を変えて確認するコード

初稿と修正後を同じ手順で確かめられるよう、検証対象のファイル名を引数で受け取ります（examples/08-01-minimal-example/run.js）。このコードは出力を表示するだけで、期待結果との照合は行いません。照合は人が第6.2節で行います。照合を機械的に行う形は07-03のverify.js、より広いテストは09-01で扱います。

// 検証対象のファイル名を引数で受け取る（省略時は approval.js）。
// 使い方: node run.js                    （修正後の approval.js を確認）
//         node run.js approval-draft.js  （初稿の説明用の失敗例を確認）
const path = require("node:path");
const target = process.argv[2] || "approval.js";
const { canApprove } = require(path.resolve(__dirname, target));

// 入力を変えて出力を記録する（繰り返し処理）
const inputs = [
  { state: "提出済み", isAssignedApprover: true, isSelf: false, label: "正常な承認" },
  { state: "下書き", isAssignedApprover: true, isSelf: false, label: "未提出" },
  { state: "提出済み", isAssignedApprover: false, isSelf: false, label: "割当外の承認者" },
  { state: "提出済み", isAssignedApprover: true, isSelf: true, label: "自己承認" },
];

console.log(`検証対象: ${target}`);
for (const i of inputs) {
  const output = canApprove(i.state, i.isAssignedApprover, i.isSelf); // 変数に結果を保持
  console.log(`${i.label}: state=${i.state}, isAssignedApprover=${i.isAssignedApprover}, isSelf=${i.isSelf} => ${output}`);
}

6. 初稿の確認と修正

6.1 初稿の実行結果

examples/08-01-minimal-example/ で初稿を実行した stdout と終了コードです（整形・省略なし。stderr への出力はありませんでした）。エラーは出ず、終了コードも0です。

$ node run.js approval-draft.js
検証対象: approval-draft.js
正常な承認: state=提出済み, isAssignedApprover=true, isSelf=false => true
未提出: state=下書き, isAssignedApprover=true, isSelf=false => false
割当外の承認者: state=提出済み, isAssignedApprover=false, isSelf=false => true
自己承認: state=提出済み, isAssignedApprover=true, isSelf=true => false
終了コード: 0

6.2 人のレビュー：期待結果と照合する

「動いた」だけでは判定できません。第5.2節で先に決めた期待結果と、1行ずつ照合します。

「割当外の承認者」で、期待結果falseに対して実際はtrueでした。REQ-003の「割り当てられた承認者だけが承認できる」を満たしていません。コードを見ると、isAssignedApproverを受け取っているのに、どの条件分岐でも使っていません。エラーにならず、他の3パターンは正しいため、期待結果を先に決めて照合しなければ見逃す不備です。

6.3 修正指示

指摘：
1. 「割当外の承認者」（state=提出済み, isAssignedApprover=false, isSelf=false）で、期待結果 false に対して true が返っています。isAssignedApprover が false の場合に false を返す条件分岐を追加してください。

変えないこと：
- 期待結果（4パターン）は変更しないでください。
- run.js は変更しないでください。同じコードで再確認します。
- 保存・履歴・通信は追加しないでください。

6.4 修正後の実行結果

同じrun.jsで修正後のコードを実行した stdout と終了コードです（整形・省略なし。stderr への出力はありませんでした）。

$ node run.js
検証対象: approval.js
正常な承認: state=提出済み, isAssignedApprover=true, isSelf=false => true
未提出: state=下書き, isAssignedApprover=true, isSelf=false => false
割当外の承認者: state=提出済み, isAssignedApprover=false, isSelf=false => false
自己承認: state=提出済み, isAssignedApprover=true, isSelf=true => false
終了コード: 0

4パターンすべて一致したので、修正後のコードを採用します。採用したのは「この4パターンで期待どおり」という範囲であり、保存・履歴・通信を含めた動作は未検証です（第8節）。

7. 確認結果

実行環境：macOS 26.6.2、Node.js v24.18.0（標準機能のみ）、2026-09-20に実行。教材演習用のフォルダ（examples/08-01-minimal-example/）の中で行いました。stdout・stderr・終了コードをそのまま記録した実行記録は第9節の run_log.md にあります。

完了条件との照合：

残る制限：この最小の関数は、状態と権限の判定だけを行うものです。保存・履歴の記録・通信は含まれていません。これらは08-02・08-03で扱います。「AIの初稿」は説明用の設定であり、実際のAIがこの指示文でどんなコードを返すかは観測していません。この記事の本文はClaude Codeが作成したもので、業務担当者による内容確認は行っていません。

8. 設計を判断する

8.1 最小例をアプリ全体に広げるときに足りないもの

この最小例の結果（4パターンで期待どおりの出力になったこと）は、この関数単体の動作を確認したものであり、保存・履歴・通信を含めたアプリ全体が正しく動くことを保証するものではありません。

8.2 人のレビューをどこまで機械化するか

この記事では、期待結果との照合を人が表で行いました（第6.2節）。4パターンなら目で追えますが、パターンが増えると見落とします。照合を機械化する段階は次のとおりです。

機械化しても、期待結果を決めるのは人です。機械化されるのは照合の作業であって、判断ではありません。

8.3 適用限界

この最小例は、承認可否の判定という一部分だけを対象にしています。アプリ全体の動作確認は、08-02〜08-04、09（テスト・レビュー）で行います。

9. 持ち帰る成果物

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

1. 前工程（実行環境、設計の該当部分、期待結果の考え方）を用意する
2. 判定したい条件と期待結果を、実装より先に決める（第5.2節）
3. 渡す情報と指示文を決めてAIに頼む（第5.3節）
4. 初稿を入力3通り以上で実行し、期待結果と1行ずつ照合する（第6.2節）
5. 不一致があれば修正を指示し、同じ手順で再確認する（第6.3〜6.4節）
6. 実行環境と未検証の範囲を書く

10. 次工程への受渡し

次へ渡すもの：最小の関数（承認可否の判定）、期待結果4パターン、初稿と修正後の実行記録。

次工程での使われ方：08-02（入力・計算・保存をつなぐ）では、この関数に保存処理をつなげます。09-01（個々の処理を確認する）では、この関数をより広いテストケースで確認し、第6.2節の照合を機械化します。

前工程へ戻る条件：この最小例が05-02・05-03の設計と食い違う場合は、それぞれの記事に戻って確認します。期待結果を決められない条件が見つかったら、記事Aの受入条件に戻ります。

11. 根拠と更新情報

• この記事の会社・人物・データはすべて架空の設定です。
• 判定の条件（状態、割当承認者、自己承認）は、05-02の状態遷移表・05-03の権限表と、記事AのREQ-003に基づきます。
• 第5.3節の指示文は、この記事のために書いた指示文の例であり、実際にAIへ送信した記録ではありません。第5.4節の初稿（approval-draft.js）は説明用の失敗例であり、実際のAI出力を観測した記録ではありません。
• 期待結果を要件から先に決め、実装の出力に合わせて書き換えないという考え方は、記事Bと07-03に一致させています。
• 制作の来歴：本文はClaude Codeが作成しました。第5〜7節のコードは examples/08-01-minimal-example/ を正本とし、2026-09-20にmacOS 26.6.2・Node.js v24.18.0の環境で実際に実行して、stdout・stderr・終了コードを evidence_public/phase5b1-2026-09-20/08-01/run_log.md に記録しています。人（ユーザー）による実読・内容確認は未実施です。
• 2026-09-20（Phase 5B-1）：Build型のPilotとして、読む順路（3つの深さ）、第4節の判断項目、第5.2節「期待結果を先に決める」、第5.3節「AIに最小の関数を頼む」（渡す情報と指示文）、第5.4節の初稿（approval-draft.js、新規）、第6節の初稿の実行結果→人のレビュー→修正指示→修正後の実行結果、第8.2節、記事間の参照を追加した。run.js に検証対象を引数で指定できる機能を足し（省略時の動作は従来どおり）、初稿と修正後を同じ手順で実行した実測に置き換えた。判定条件・修正後の approval.js・完了条件は変えていない。
• 未確認事項：保存・履歴・通信を含めたアプリ全体の動作は、この記事の時点では確認しておらず、08-02以降で扱います。