業務の困り事を、実装と確認ができる要件へ変える

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

管理項目	内容
記事ID	SAMPLE-A
主な中カテゴリ	02-01 困り事を業務要件へ変える
関連中カテゴリ	01-02、02-02、02-03、02-04
関連要件ID	REQ-001〜REQ-005、REQ-007（業務上の条件のみ。改訂版で追加）
先に読むと理解しやすい記事	00-03（企画から運用までの全体像）、01-02（現状の流れと困り事）を読んでいると理解しやすい。未読でも本記事内で必要な用語は説明する
到達目標	曖昧な希望を「誰が・どの条件で・何をできる／できない」に分解し、確認できる受入条件まで書ける
3層の配置	理解する＝第3〜4節／作って確かめる＝第5〜7節／設計を判断する＝第8節
成果物パス	templates/requirements_template.md、templates/requirements_example.md、templates/ai_request_template.md、templates/ai_request_example.md
出典	第11節参照
対象ツール・バージョン	特定ツールに依存しない。AIへの指示例は汎用の文章
検証状況	本文・ひな形・記入例は Claude Code が作成。GPTによる別環境での技術・編集レビューを受け改訂（2026-09-18）。Phase 4D-R2〜R4.1の改善後、ユーザーによる実読を実施し、Design型の基準として採用（Freeze）。この記事にコード実行は含まない（記事Bで実行する）
残課題	第11節参照
最終更新日	2026-09-19（改訂版 rev2：AC-009の前提と要件数の表記を修正。Phase 2 着手時に第7節の件数表記1か所を修正。Phase 4D-R：非エンジニア向けに導入と説明の順序を改善。要件・受入条件・結論は不変）。2026-09-21（Final Content Audit：読む順路の「本文は今後制作予定」（全項目に本文がある現在は誤り）を削除。本文は不変）

この記事の会社・人物・数値はすべて架空の設定です。実在する会社や案件とは関係ありません。

この記事は何の話か。要件定義の話です。要件定義とは、どんなシステムを作れば完成なのかを、作る前にはっきり決めることです。そのために、「誰が使うのか」「何ができるのか」「どんな条件ならOKなのか」を具体的に決めます。

なぜ必要か。これを決めずに作ると、動くシステムはできても、欲しかったシステムにならないことがあります。作る人（またはAI）が、決まっていない部分を自分の想像で埋めるからです。

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

• 「困っている」と「何ができれば完成か」の違いを、自分の言葉で説明できる
• 自分の職場の申請・承認業務について、決めること、勝手に決めてはいけないこと、あとで確かめる条件を、ひな形に書き出せる
• AIに要件の下書きを頼むときに、何を渡し、何を自分で確認するかを決められる

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

• 基本だけ理解する：第1節→第3節→第4節→第5.3〜5.5節の表→第9節。コードは出てきません。ここまでで「困り事と要件の違い」「決めてよいこと・いけないこと」「受入条件の形」が分かり、ひな形を埋め始められます。
• 作って確かめる：上に加えて第5.6節（AIへの依頼）→第6節（失敗例と直し方）→第7節。
• 設計判断を深める：上に加えて第8節（作らない案との比較、不変条件、変更の影響、適用限界）。

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

この記事でやることは、総務部門の「困っている」という言葉を、システムとして決められる言葉に書き換えることです。書き換えた結果が要件です。

「困っている」は出発点であって、注文書ではありません。「進捗が見えるようにしてほしい」と言われても、何が誰に見えればよいのかが決まっていなければ、作る人は何を作ればよいか分かりません。この記事は、その決まっていないことを一つずつ決めていく手順です。

題材は、架空企業「みらい業務サービス」の総務部門です。会議室の機材手配や名刺の発注などの依頼が、メールとチャットに分かれて届きます。たとえば、佐藤さんがメールで会議室のプロジェクタを頼み、承認する立場の鈴木さんがチャットで「OKです」と返します。数日後、総務の担当者は「その依頼、承認されましたか？」と聞かれ、メールとチャットを行き来して探します。

この表の右の列が、要件のもとになります。「見えるようにする」ではなく、「誰が」「何を」「どんな条件で」見られるかまで決めると、作ることも、できたかを確かめることもできます。経費精算や稟議など、「誰かが申請し、誰かが承認する」業務なら、同じ書き換えができます。

この題材で扱う「進捗」は、依頼が下書きから承認済みになるまでの状態のことです。承認されたあとの実際の作業の完了、納品、取消の管理は初版の範囲に含めません。状態は4つ（下書き・提出済み・差戻し・承認済み）に固定し、記事ごとに勝手に増やしません。

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

• 聞き取った言葉を「現象」「原因の仮説」「希望」に分けた整理表
• 確認しないと決められない事項と、勝手に決めてはいけない事項の一覧
• 「誰が・どの条件で・何をできる／できない」の形に書き直した業務要件（6項目）
• 正常な操作だけでなく、権限がない・入力が足りない・状態が合わない場合を含む受入条件
• AIに下書きを頼むときに渡す資料と指示文
• 業務改善だけで済ませる案と、アプリを新しく作る案の比較

そして、これらを自分の業務に置き換えて埋め始められる空欄のひな形と記入例です。

2. 前提知識と読む順路

この記事で使う4つの言葉を先に説明します。言葉を覚える必要はありません。「何のことを言っているか」が分かれば十分です。

要件

一言でいうと、「作るものは、これができなければならない」という約束です。

たとえば、「承認者は、自分に割り当てられた提出済みの依頼を承認できる」が1つの要件です。

これがないと、作る人が「たぶんこうだろう」で作ります。できあがってから「思っていたのと違う」となっても、何と比べて違うのかを示すものがありません。

システム開発では、これを要件（requirement、リクワイアメント）と呼びます。作る人と使う人が合意した文章で、番号（要件ID）を付けて、設計・実装・テスト・運用手順まで同じ番号で追いかけます。

受入条件

一言でいうと、「こう操作したら、こうなればOK」という答え合わせの条件です。

たとえば、「割当外の承認者が承認しようとしたら拒否される。状態も記録も変わらない」が1つの受入条件です。

これがないと、「できました」と言われても確かめようがありません。動いたように見えて、実は権限のない人も承認できてしまう、という不具合を見逃します。

システム開発では、これを受入条件（Acceptance Criteria、アクセプタンス・クライテリア）と呼びます。「誰が、どんなデータに、何をしたら、何が起きるべきか」まで書きます。要件が「約束」なら、受入条件は「約束が守られたかを確かめる方法」で、あとでテスト（プログラムで自動的に確かめる作業）に変換されます。

状態

一言でいうと、依頼が今どの段階にいるかを表すものです。

たとえば、書類に押す「下書き」「提出済み」「差戻し」「承認済み」のスタンプです。この教材では、この4つに固定しています。

これがないと、「この依頼はもう承認してよいのか」を誰も判断できず、下書きを承認するような操作を止められません。

システムでは、この状態を依頼と一緒に保存しておき、次にできる操作を判断するのに使います。

役割

一言でいうと、その人が「できること」の区分です。

たとえば、この教材では「依頼者」「承認者」「運用管理者」の3つです。同じ人でも、依頼を出すときは依頼者、他人の依頼を承認するときは承認者になります。

これがないと、誰でも他人の依頼を承認したり書き換えたりできてしまい、承認の意味がなくなります。

システムでは、利用者ごとに役割を持たせ、操作のたびに「この役割にこの操作を許すか」を判断します。この判断の仕組みを、システム開発では認可（Authorization）と呼び、設計は05-03で扱います。

全体の工程のなかでの位置は、企画（01）で「何に困っていて、作る価値があるか」を確かめたあと、要件定義（02）で「何を作るか」を決める最初の段階です。

工程の全体像が初めての方は 00-03、聞き取りのやり方そのものは 01-02 が該当します。この記事だけでも進められるように、必要な説明は本文に含めています。

3. 理解する：なぜ「困り事」のままでは作れないのか

3.1 困り事と要件の違い

「依頼の進捗が見えない」は困り事です。これをそのままAIに渡して「進捗が見えるアプリを作って」と頼むと、AIは何か作ります。ダッシュボードかもしれないし、通知メールかもしれません。それが役に立つかどうかは運次第です。AIが悪いのではなく、「見える」が何を指すかを誰も決めていないからです。

要件は、困り事を「確かめられる約束」に変えたものです。次の3つが入っていると、要件として使えます。

1. 誰が（役割）
2. どの条件で（データの状態、入力の有無、時間など）
3. 何をできる、または何をできない

「承認者は、自分に割り当てられ、かつ提出済みの依頼だけを承認できる。自分が出した依頼は承認できない」と書けば、作る側は判断の条件が分かり、使う側は「できてしまったらおかしい操作」を確かめられます。

この1文が、アプリの中でどう働くかを想像してみます。承認者の鈴木さんが承認画面を開き、依頼「会議室プロジェクタ手配」の「承認」ボタンを押します。そのときアプリは、押した人が鈴木さんであること、この依頼の承認者が鈴木さんに決まっていること、依頼の状態が「提出済み」であること、依頼者が鈴木さん本人でないこと、の4つを確かめてから、状態を「承認済み」に変えて記録を残します。どれか1つでも違えば、承認は成立しません。要件の「誰が・どの条件で・何を」は、そのままアプリが確かめる項目になります。

このように「誰が何をしてよいか」をシステム側で確かめる仕組みは、開発では権限の判定（認可、Authorization）と呼ばれ、設計は05-03で扱います。この記事では、その判定の元になる約束を業務の言葉で決めるところまでを行います。

ここで重要なのは、この承認の例そのものではなく、困り事を「確かめられる約束」の形に変えることです。形が同じなら、経費精算でも勤怠の申請でも同じように書けます。

3.2 よくある誤解

「要件は箇条書きで機能を並べればよい」。「承認機能」「一覧機能」「通知機能」と並べても、承認機能が誰の何を許すのかが決まっていなければ、作る人が勝手に決めることになります。機能名ではなく、許す操作と拒否する操作で書きます。

「正常な流れだけ書けばよい」。依頼が出されて、承認されて、終わり。これだけ書くと、承認者でない人が承認ボタンを押せてしまう、件名が空でも提出できてしまう、といった問題が「要件に書いていないから仕様どおり」になります。うまくいかない場合の振る舞いも要件です。

「AIに聞取りメモを渡せば要件が出てくる」。AIは下書きを作るのが得意ですが、社内で誰が承認者になるべきか、自己承認を認めるかどうかは、AIには決められません。決めるのはその業務の責任者です。AIには「決めるべき事項を洗い出して」と頼めますが、「決めて」と頼んではいけません。

「要件を書いたら変えてはいけない」。試作やテストで「この条件では困る」と分かったら、要件に戻って直します。この記事の順路は一方通行ではありません。ただし、直したときは要件IDを付けたまま記録し、何がなぜ変わったかを残します。

4つに共通するのは、「決めていないことは、誰かが勝手に決めることになる」という点です。決めるのはアプリを作る人でもAIでもなく、その業務に責任を持つ人です。

3.3 架空の聞取りメモ

出発点になる聞取りメモです。総務課長と総務担当者の2人から聞いた、という設定です。

総務課長：依頼の進捗が見えない。承認したつもりが記録に残っていなくて、あとで「承認されてないですよ」と言われた。承認を簡単にしたい。

総務担当：依頼がメールとチャットにばらばらに来る。誰が今の担当か分からず、同じ依頼に2人で対応したことがある。急ぎかどうかも本文を読まないと分からない。

このメモには、現象、原因の仮説、希望が混ざっています。次の節で分けます。

4. 判断すること：何を決め、何を決めてはいけないか

4.1 聞いた言葉を分ける

なぜ、聞いた言葉をそのまま要件にしてはいけないのでしょうか。医師の問診に似ています。「頭が痛い」（起きていること）、「寝不足のせいだと思う」（本人の推測）、「薬がほしい」（希望）を分けずに、希望どおり薬を出すだけでは、原因が別にあったときに治りません。聞取りメモも同じで、起きていること、本人の推測、希望が混ざっています。

聞取りメモを、ひな形の整理表（第1節）に写します。ポイントは、聞いた言葉をそのまま残すことと、それが「現象（起きていること）」「原因の仮説（なぜ起きているかの推測）」「希望（こうしたい）」のどれかを分けることです。言葉をそのまま残すのは、あとで「本当にそう言ったか」に戻れるようにするためです。

M-2「簡単にしたい」は、このままだと要件になりません。「探す手間」なら一覧の要件、「判断」なら依頼の内容項目の要件、「記録」なら履歴の要件になります。聞き返して分解する必要があります。

4.2 確認事項と、勝手に決めてはいけない事項

整理表を眺めると、決めないと先に進めないことが出てきます。ひな形の第2節に書き出し、「確認前に仮置きしてよいか」を付けます。「仮置き」とは、正式な回答を待たずに、いったんこう決めたことにして先に進むことです。

なぜ「仮置きしてよいか」を分ける必要があるのでしょうか。たとえばQ-2「自分の依頼を自分で承認する場面はあるか」を、作る側が「たぶん無いだろう」と仮置きして作ったとします。あとで「課長は自分の依頼を自分で承認していた」と分かれば、承認の意味そのものが変わり、作り直しになります。逆に、実は自己承認できる仕様のまま使われていれば、監査で「この承認は誰が判断したのか」を説明できません。

仮置きしてよいのは、あとから変えても影響が小さいことです。仮置きしてはいけないのは、権限、データの扱い、責任に関わることです。

この記事では、Q-1〜Q-5は次のように決まったという架空の設定で進めます。承認者は依頼ごとに1名を指定する。自己承認は禁止し、役割を兼ねる人も禁止。承認済みは初期版では編集不可。差戻し理由は必須。件名・内容以外の必須項目はなし。

Q-6は未回答のままにします。未回答の事項があること自体は普通です。大事なのは、未回答のQに依存する要件（添付ファイル、公開範囲、保存期間など）を作らないことです。

4.3 AIに任せる範囲

この工程でAIに任せてよいのは、次の作業です。

• 聞取りメモから、確認すべき事項の候補を洗い出す
• 決まった事項をもとに、要件と受入条件の下書きを作る
• 要件の書き方が「誰が・どの条件で・何を」の形になっているかを点検する
• 見落としがちな失敗の場面（権限なし、入力不足、状態外、重複）の候補を出す

任せてはいけないのは、Q-1〜Q-6のような業務上の決定です。AIが「一般的には自己承認は禁止です」と言ったとしても、それはこの会社の決定ではありません。

5. 作って確かめる：要件と受入条件を書く

5.1 準備

必要なものは、聞取りメモ整理表（4.1）、確認事項の回答（4.2）、ひな形 templates/requirements_template.md です。特別なツールは要りません。表が書ければ、文書でも表計算でも構いません。

5.2 利用者と役割、対象データと状態を先に固定する

要件を書く前に、登場人物とデータを固定します。ここがぶれると要件が書けません。

まず、アプリが動いている場面を思い浮かべます。依頼者の佐藤さんが依頼作成の画面を開き、件名「会議室プロジェクタ手配」と内容を入力し、承認者に鈴木さんを選んで「提出」を押します。アプリはその依頼を「提出済み」として保存し、承認者の鈴木さんの一覧に表示します。鈴木さんが依頼を開いて「承認」を押すと、状態が「承認済み」に変わり、「鈴木・承認・いつ」という記録が1行残ります。佐藤さんの一覧では、その依頼が「承認済み」と表示されます。

この場面に出てくる「人」「データ」「段階」を、それぞれ役割・データ・状態として先に固定します。

役割は3つです。

データは「依頼」と「履歴」の2つです。依頼はID、依頼者、件名、内容、状態、承認者を持ちます。履歴は、依頼に対して誰がいつ何をしたかを、追記だけで残します。

状態は4つで、変わる条件も決めます。

この表があるだけで、「下書きを承認する」「承認済みを差し戻す」が「表にない操作＝できてはいけない操作」だと分かります。アプリの側では、この表がそのまま「操作を受け付ける条件」になります。表にない組み合わせは、ボタンを押しても処理が拒否されるように作ります。本当に拒否されるかを確かめる方法は、記事Bで扱います。

ここで重要なのは、役割・状態の中身そのものではなく、要件を書く前に登場人物と段階を固定することです。ここを固定しないまま要件を書くと、「承認者」が誰を指すのかが文によって変わり、作る側も確かめる側も迷います。

5.3 不十分な要件と、改善した要件

同じ内容を、不十分な書き方と改善した書き方で並べます。左の列は、業務の側から見れば十分に通じる言葉です。しかし作る側の立場で読むと、「承認機能をつける」だけでは、誰のボタンを、どの依頼に、どの条件で有効にすればよいかが分かりません。

右の列は、そのまま受入条件に変換できます。左の列はできません。この違いが「実装と確認ができる要件」かどうかの分かれ目です。

5.4 業務要件一覧（6項目）

改善した要件を、要件IDを付けて一覧にします。要件IDとは、要件1つずつに付ける通し番号です。商品の品番のように、このあと設計・実装・テスト・運用手順で同じ番号を使い続けます。番号があると、「REQ-003を変えたら、どのテストと手順を直す必要があるか」を追いかけられます。

「一意のID」とは、同じ番号が2つ存在しないIDのことです。社員番号や注文番号と同じで、件名が同じ依頼が2件あっても取り違えないための土台になります。REQ-001は「見分けられる」ことの要件であり、全員が全件を見られるという意味ではありません。誰がどの依頼を見られるかはREQ-002が決めます。

REQ-007は設計書の要件のうち、要件定義の段階で「業務としてどうあるべきか」だけを先に決めておくものです。「状態を変える」と「記録を残す」は業務上ひとまとまりで、片方だけが残った依頼を正常とは呼ばない、という約束です。どうやってそれを実現するか（トランザクションという仕組み）は記事Bで扱います。

5.5 受入条件（正常・権限なし・入力不足・状態外・重複）

要件ができたら、次は「要件どおりに作れたかを、あとでどう確かめるか」を先に決めます。これが受入条件です。作る前に答えを用意しておく、答え合わせの用紙のようなものです。作ったあとに「動いたから大丈夫」と言うのではなく、「この操作をしたら、こうなるはず」を先に書いておき、実際にそうなるかを見ます。

受入条件は、要件ごとに「前提」「操作」「期待結果」をデータの具体例で書きます。ここで登場する人物とデータは架空の設定です。

• 佐藤、田中：依頼者
• 鈴木、高橋：承認者
• REQ-A01：佐藤の依頼「会議室プロジェクタ手配」、提出済み、承認者は鈴木
• REQ-A02：佐藤の依頼「名刺の追加発注」、下書き、承認者は鈴木
• REQ-A03：鈴木自身の依頼「備品棚の移設」、提出済み、承認者も鈴木（自己承認の検査用）
• REQ-A04：佐藤の依頼「社用車の予約」、承認済み、承認者は高橋

表の「種類」の列を、業務の言葉で言い直すと次のとおりです。

期待結果には「状態がどうなるか」と「履歴がどうなるか」の両方を書きます。「エラーが出る」だけでは足りません。エラーが出たのにデータが変わっていた、という失敗を見つけられないからです。

受入条件の「種類」は、正常／権限なし／入力不足／状態外／重複／途中失敗の6種になりました。ここで重要なのは、正常な流れだけでなく、「できてしまったらおかしい操作」を先に書き出すことです。アプリの不具合の多くは、正常な操作ではなく、想定していなかった操作で起きます。

これらの受入条件は、記事Bでテストに変換されます。テストとは、受入条件の「操作」をプログラムで実行し、「期待結果」と実際の結果を機械的に照合する作業です。ただし、受入条件とテストは粒度が違います。受入条件は業務の言葉で「何が起きるべきか」を書き、テストはそれを「どのデータに、どの関数を呼び、保存内容がどうなっているか」まで落とします。同じ番号を共有しているのではなく、次の表で変換しています。

記事Bで確かめるのは、この表でTが付いた7件（AC-001、002、003、004、006、008、010）だけです。AC-005、007、009は記事Bの範囲外で、未検証のまま次工程に渡します。

5.6 AIに下書きを頼む

ここまでの材料がそろうと、AIに要件一覧と受入条件の下書きを作ってもらうことができます。AIがするのは、渡された資料を読んで、決まった形式の文章に整えることです。決めるのは人で、AIは「決まったことを文章にする」役です。逆に、材料がないままAIに頼むと、AIは足りない部分を一般論で埋めるため、その会社の事情と合わない要件ができます。

渡す資料、制約、返してほしい形式、完成条件、人が確認することを、ひな形 templates/ai_request_template.md に書き出してから指示します。記入例は templates/ai_request_example.md です。

指示文の要点は次のとおりです。

• 添付する資料を列挙する（聞取りメモ整理表、Q表の回答、役割表、状態表、ひな形）
• 未回答のQ-6に依存する要件を作らないよう、制約として明記する
• 対象外（代理承認、承認取消、取り下げ）を要件に混ぜないよう明記する
• 各要件に根拠の聞取りメモ番号（M-1など）を添えるよう頼む
• 判断できない点は要件にせず「不明点一覧」にするよう頼む

この依頼を含む、AIと進める流れの全体と、人とAIの分担は次のとおりです。

6. 初稿・失敗例・修正

AIの下書きは、そのまま使えるとは限りません。ここでは、下書きに混ざりやすい不備を4つ示し、どう見つけ、どう直すかを説明します。ここに示す「初稿」は、教えるために意図的に不備を入れた説明用の失敗例です。実際のAIの出力を観測したものではありません。

失敗例1：勝手に決めている

REQ-006 依頼者は、依頼にファイルを添付できる。添付ファイルは1件5MBまで。

Q-6（個人情報・社外秘の扱い）が未回答なのに、添付機能を要件にしています。容量の数値も根拠がありません。制約に「Q-6に依存する要件は作らない」と書いていれば防げますし、書いていなくても、人がQ表と照合すれば見つかります。修正：削除し、不明点一覧に「添付の要否はQ-6の回答後に判断」と移す。

失敗例2：機能名で書いている

REQ-003 承認機能を提供する。

誰が、どの条件で、が抜けています。修正：「割り当てられた承認者は、提出済みの依頼を承認できる。依頼者本人は承認できない」に書き換える。

失敗例3：受入条件が正常系だけ

AC-001 承認者が承認すると承認済みになる。

これだけだと、割当外の承認者や自己承認が「できてしまう」実装を見逃します。修正：AC-002〜004（権限なし、自己承認、状態外）を追加する。

失敗例4：効果の数値を作っている

この機能により承認にかかる時間が50%削減される。

測っていない数値です。要件でも受入条件でもありません。修正：削除する。効果を書くなら「架空の仮定」と明記し、01-03（目的・評価指標）の成果物に置く。

見つけ方は共通しています。Q表・対象外一覧・ひな形の完成条件と、1項目ずつ照合することです。AIに「自分で点検して」と頼むこともできますが、同じAIの再確認は独立した保証にはなりません。最後は人が照合します。

7. 確認結果

この記事の成果物は文章と表なので、コードの実行はありません。代わりに、ひな形の完成条件と照合した結果を示します。完成条件とは、ひな形に書いてある「ここまで埋まっていれば次の工程に渡せる」という採点基準です。

残る制限：この記事の要件は架空ケースのものです。読者が自分の業務に適用するときは、Q表を自分の職場で聞き直す必要があります。受入条件が実際に「確認できる」かどうかは、記事Bで実装に対して試して初めて分かります。この記事の本文と記入例はClaude Codeが作成したものです。非エンジニアの読者による実読はPhase 4D-R2〜R4.1で実施し読みやすさを確認しましたが、実際の業務担当者による内容確認（自分の職場の申請・承認業務に当てはめて使えるかの確認）は行っていません。

8. 設計を判断する

8.1 業務改善だけで済ませる案と、アプリを作る案

要件を書き終えたら、「そもそも作るべきか」に一度戻ります。作らない選択肢と比べて初めて、作る理由が説明できます。多くの職場では、共有の表計算ファイルや市販の申請サービスで済んでいる業務もあります。新しく作るのは、それらでは要件を守れないと分かったときです。

比較は、前提を置かないと結論が出ません。この架空ケースでは次の前提で比べます。前提が変われば結論も変わります。

• 費用には、ソフトウェアの料金だけでなく、担当者が設定・運用・集計に使う時間も含める。
• 案Aと案Bは、編集権限を人ごとに分けず、専用の履歴機能も置かない前提とする（それらを足せば、案Bは案Dに近づく）。
• 案Cでも、設定、利用者の登録と削除、業務ルールの運用は自社に残る。
• 案Dは、要件どおりに作れる可能性はあるが、作ったものが要件を満たしていることは記事Bのような検証をして初めて言える。

この記事の要件では、REQ-002（役割ごとの範囲）とREQ-003（自己承認禁止）とREQ-005（履歴）が「譲れない」とされているため、上の前提のままでは案AとBでは守れません。案Cと案Dの比較は、03-02（作り方の候補の比較）と03-03（技術とサービスの選定）で、費用・社内ルール・保守担当を含めて行います。この記事では「この前提ではA・Bで要件が守れない」ことまでを判断します。製品固有の機能や価格は調べていません。

「作る」と決めても、要件は変わりません。要件はどの案を選んでも満たすべき約束であり、案の選択は「どうやって満たすか」の話です。

8.2 上級層：曖昧さ、不変条件、例外、変更の影響

ここからは、要件を書いたあとに設計や運用で効いてくる、少し進んだ観点です。基本だけ理解する順路の方は飛ばして構いません。

曖昧さの検出。要件の中の形容詞・副詞（「簡単に」「すぐに」「適切に」「必要に応じて」）は、そのままでは確認できません。数値か、具体的な操作か、対象外の宣言に置き換えます。「すぐに」なら「操作後の画面再表示で反映される」など、確認の方法まで書きます。

不変条件。一言でいうと、「いつ見ても守られているべき約束」です。経理の例なら、「承認済みの伝票には必ず承認印がある」「支払済みの請求書には必ず対応する支払記録がある」がそれにあたります。このように、処理の確定後や失敗の取消後など、外から見えるどの時点でも守られているべきルールを、不変条件（invariant、インバリアント）と呼びます。処理の内部で一時的に途中の状態を通ることはあります（状態を変えた直後、履歴を書く前など）。この教材で守るのは、処理が確定したあと、または失敗して取り消されたあとに、外から見える業務の状態が整っていることです。内部の更新順序の話は記事Bのトランザクションで扱います。

この教材の要件から抜き出すと、次の3つがあります。

1. 承認済みの依頼には、承認の履歴が必ず1件以上ある（REQ-005、REQ-007から導かれる）
2. 承認を成功させた操作者は、その依頼の依頼者ではない（REQ-003）
3. 承認済みの依頼の内容は変わらない（5.2の状態表で「承認済み→編集」が存在しない）

2番は「依頼に設定された承認者が依頼者と別人である」というデータの制約とは少し違います。記事Bでは、あえて依頼者＝承認者の異常なデータ（REQ-A03）を用意して、処理が承認を拒否することを確かめます。守りたいのは「承認が成立するときは必ず別人である」ことで、異常なデータが存在しないことではありません。

不変条件を書き出しておくと、テスト（記事B）では「操作のあとに不変条件が壊れていないか」を確かめる観点になり、復旧（記事C）では「復元後に不変条件が守られているか」を照合する観点になります。記事Cの復元確認では、1番の不変条件を「承認履歴のない承認済み依頼の件数が0か」として実際に確かめています。

例外の網羅。受入条件の「種類」列を、正常／権限なし／入力不足／状態外／重複／途中失敗の6種で埋めていくと、抜けが見えます。「途中失敗」は初版では扱っていませんでしたが、改訂版でAC-010として業務上の条件だけを加えました。どうやって片方だけの結果を防ぐか（トランザクション）は記事Bで扱います。上級層の読者は、途中失敗のほかに「再実行」（失敗のあと同じ操作をやり直したとき）についても、受入条件を加えることを検討してください。AC-008（重複）はその一部です。

変更時の影響。要件IDを付ける理由は、変更の影響をたどるためです。品番があれば、その部品を使っている製品を全部洗い出せるのと同じです。たとえばQ-2の決定が「役割を兼ねる人は自己承認を許す」に変わったら、REQ-003、AC-003、5.2の状態表の条件、記事Bのテスト、権限表、運用手順が影響を受けます。要件IDがなければ、この追跡は人の記憶頼みになります。

規模と安全性の限界。この記事の要件は、社内の低リスクな作業依頼を対象にしています。金銭の支払、人事評価、個人情報を含む依頼を扱う場合は、権限の分離、監査の要件、法令や社内規程の確認が加わり、この記事の5要件では足りません。適用限界として明記しておきます。

9. 持ち帰る成果物

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

1. 聞取りメモを、言葉をそのまま残して整理表に写す
2. 決めないと進めないことをQ表に書き、「仮置き不可」を業務の責任者に確認する
3. 役割表と状態表を先に固定する
4. 要件を「誰が・どの条件で・何を」で5つ以上書く（この記事の例では6つ）
5. 要件ごとに、正常と失敗の受入条件を書く
6. 対象外を明記し、未回答のQに依存する要件がないか照合する

10. 次工程への受渡し

次へ渡すもの：業務要件一覧、受入条件一覧、対象外一覧、未決の確認事項（Q-6）、そして「この要件で進めてよい」と判断した責任者の名前。

次工程での使われ方：02-02（機能の優先順位）では要件一覧を最小・追加・対象外に分けます。05-02（保存・更新のルール）では状態表がそのまま状態遷移の設計になります。05-03（権限）では役割表が権限表になります。09-02（記事B）では受入条件がテストの期待結果になります。

前工程へ戻る条件：Q-6の回答で「社外秘を含む」と分かったら、01-04（作る必要性の判断）に戻り、保存先や公開範囲の制約を含めて作り方を見直します。試作で「承認者を1名に固定すると業務が回らない」と分かったら、Q-1に戻って要件を直します。

11. 根拠と更新情報

• この記事の会社・人物・依頼・決定事項はすべて架空の設定です。
• 第6節の初稿は説明用の失敗例であり、実際のAI出力を観測した記録ではありません。
• 要件ID（REQ-001〜005）、役割、状態、自己承認禁止のルールは、教材設計書 AI_SYSTEM_DEV_BLUEPRINT_v0.1.md 第5節に基づきます。これは教材ケースの定義であり、実在企業の承認制度や外部の一般基準ではありません。
• 「受入条件」「不変条件」の説明は、この教材の中での定義として書いています。外部の標準文書の引用ではありません。
• AIへの指示の書き方（渡す資料を具体的にする、完成条件と確認方法を与える、決めるべきことと作業を分ける）は、Claude Code公式「Best practices for Claude Code」（https://code.claude.com/docs/en/best-practices 、2026-09-18確認）の「Provide specific context in your prompts」「Give Claude a way to verify its work」の趣旨を、特定ツールに依存しない形で言い換えたものです。
• 制作の来歴：本文・ひな形・記入例はClaude Codeが作成。2026-09-18にGPTによる別環境での技術・編集レビューを受け、改訂版（rev1）でREQ-001とREQ-007の受入条件の追加、比較表の前提の明記、不変条件の説明の修正、読む順路の追加を行った。人（ユーザー）による実読・内容確認は未実施。
• 2026-09-19（Phase 4D-R）：ユーザーの実読で「本文の抽象度が高く非エンジニアに理解しにくい」との指摘を受け、導入（第1節）、用語の説明順序（第2節）、各節の冒頭に業務の場面・理由・平易な説明を追加した。要件ID・受入条件・表・結論・成果物は変更していない。改善後の本文の実読による確認は未実施。
• 2026-09-19（Phase 4D-R2〜R4.1）：結論ファースト（冒頭30秒で「何の話か・なぜ必要か・できるようになること」を示す）、用語導入順（一言→たとえば→これがないと→システム開発では）、本文優先のReading UX（記事領域864px・文章752px・記事内目次のdrawer化）の改善を重ね、ユーザー実読で「見やすくなりました」との評価を得た。要件・受入条件・表・結論・成果物は変更していない。以降、この記事をDesign型の基準として採用（Freeze）。
• 未確認事項：Phase 4D-R2〜R4.1のユーザー実読で読みやすさは確認したが、非エンジニアの読者が第3〜5節だけで実際に自分のひな形を埋め始められるかの行動観察は未実施。AC-005、007、009は記事Bで検証していない。