【通算089｜要求AI 06】指示を「4つの視点」で構造化したら、Kiroの要件定義はどう変わったか
雑な一文「経費申請を承認できるようにしたい」をKiroに渡したら、業務の質問は一度も来ないまま、「一般的な経費承認」の要件定義書が生成された。4つの視点で評価すると、目標×・人間△・システム◎・データ△。
指示が雑だったのだから、当然。では、最初の指示を「4つの視点」で構造化して渡したら、結果はどう変わるのか。 今日はそれを検証する。
Kiroに関するこれまでの記事。
今回Kiroに渡した指示（全文）
前回との違いは指示だけ。ツールも題材も同じ、経費申請の承認だ。
経費申請の承認機能を作りたい。要求を以下に整理する。
【目標】承認の滞留を減らし、月次締めまでに全申請の処理を完了させる。
監査時に「誰がいつ何を承認したか」を追跡できる記録を残すことが必須。
【人間】使うのは3種類: 申請者(全社員)、承認者(申請者の直属上長)、経理担当。
上長が不在のときは代理承認者を指名できる必要がある。
【システム】申請は上長承認→経理確認の2段階。ただし5万円未満は上長承認のみで完了。
差し戻しされた申請は修正して再提出できる。締め日(毎月25日)以降の申請は翌月扱い。
【データ】記録すべきもの: 申請(日付・金額・費目・目的・証憑画像)、承認履歴(操作者・日時・コメント)。
費目は経理の勘定科目に対応させる。証憑は法令対応のため7年保存。
10分で書ける分量に抑えた。
実は、この指示にはわざと書いていないことが2つある。
下書き保存 — 前回Kiroが用語集に定義しながら、要件化し忘れた項目
承認後の後工程（精算・支払・会計連携） — スコープ外だと明示していない
構造化した指示を渡してもなお、書かれていないことについて質問が出るか。前回は「プロセスの質問2・業務の質問0」だった。ここが今日の観察ポイントだ。
質問は、増えなかった
Specワークフローに構造化指示の全文を投入。Autopilotはオフのまま
送信すると、前回とまったく同じ2つのプロセス質問が返ってきた。「新機能かバグ修正か」「何から始めるか」——今回は日本語表示になっていたが、中身は同じだ。
1問目。前回は英語だったが、指示が日本語だったためか今回は日本語で聞いてきた
2問目も前回と同一。「要件定義から始める」が推奨マーク付き
そして2問に答えると、Kiroはこう言った。
「経費承認システムの要件が明確ですね。要件ドキュメントの作成を始めます」
質問はゼロのまま、生成に直行。 わざと書かなかった下書き保存にも後工程にも、触れずに進んだ。指示を構造化しても、Kiroの質問は増えない——最初の観察結果だ。
今回の実行結果
前回と違ったのは、２点ある。
１点目は要件定義（書）の内容が変わった。
２点目は、後続の設計書作成とタスクリスト作成の実行を行った。
→ 次回記事で内容紹介する
１点目は要件定義（書）の内容がどうかわったかを見ていく。
要件を書いたあと、Kiroは「要件の分析」を自動で回し始めた。分析→修正→再分析というループが画面を流れていく。
書いた要件を自分で分析し、見つけた問題を修正して、また分析にかける
そして分析の中から、今回は質問が2つ出てきた。
質問1「不備のある申請でも提出時に即通知するか、検証を通ってからにするか」
質問2「エラーメッセージ機構が故障していても、不正なアップロードは拒否すべきか」
どちらも前回の分析（金額の上限チェック）より一段深い質問だ。ただし注意が必要。2問ともシステムの視点の質問である。「この会社の締め日はいつか」「経理は何人いるのか」——そういう業務の質問は、最後まで来なかった。
今回、作成された要件定義（書）(requirements.MD)は以下のとおり（全文をそのまま貼り付けた：長いのでざっと見てください）
# Requirements Document
## Introduction
本機能「経費申請の承認機能」は、社内の経費申請プロセスをデジタル化し、承認の滞留を解消することを目的とする。申請者（全社員）、承認者（直属上長）、経理担当の3種類のユーザーが関与する2段階承認ワークフローを提供する。月次締め（毎月25日）までに全申請を処理できる仕組みを実現し、監査対応として誰がいつ何を承認したかを追跡可能な承認履歴を保持する。証憑画像は法令要件に基づき7年間保存する。
---
## Glossary
- **Expense_Request（経費申請）**: 申請者が作成する経費の申請レコード。日付・金額・費目・目的・証憑画像を含む。
- **Applicant（申請者）**: 経費申請を作成・提出する全社員。
- **Primary_Approver（直属上長）**: 申請者の直属の管理職。一次承認権限を持つ。
- **Proxy_Approver（代理承認者）**: Primary_Approver が不在時に指名される代理の承認者。
- **Accounting_Staff（経理担当）**: 二次確認権限を持つ経理部門の担当者。5万円以上の申請に対して最終確認を行う。
- **Approval_History（承認履歴）**: 各承認・差し戻し・確認操作の操作者・日時・コメントを記録した監査ログ。
- **Expense_Category（費目）**: 経理の勘定科目に対応する経費の分類。
- **Receipt（証憑）**: 経費を証明する領収書等の画像データ。
- **Closing_Date（締め日）**: 毎月25日。この日以降に提出された申請は翌月扱いとなる。
- **Workflow_Engine（ワークフローエンジン）**: 承認ステータスの遷移と通知を管理するシステムコンポーネント。
- **Notification_Service（通知サービス）**: 関係者への通知を送信するシステムコンポーネント。
- **Storage_Service（ストレージサービス）**: 証憑画像を保存・管理するシステムコンポーネント。
---
## Requirements
### Requirement 1: 経費申請の作成と提出
**User Story:** 申請者として、経費申請を作成・提出することで、経費の精算手続きを開始したい。
#### Acceptance Criteria
1. THE Expense_Request SHALL 申請日・金額・費目・目的・証憑画像を必須項目として含む。
2. WHEN Applicant が申請を提出する, THE Workflow_Engine SHALL 申請ステータスを「一次承認待ち」に設定する。
3. WHEN 申請提出日が Closing_Date（毎月25日）以降である, THE Workflow_Engine SHALL 申請の対象月を翌月として記録する。
4. WHEN 申請提出日が Closing_Date より前である, THE Workflow_Engine SHALL 申請の対象月を当月として記録する。
5. WHEN Applicant が申請を提出する, THE Notification_Service SHALL Primary_Approver（または Proxy_Approver が指名されている場合は Proxy_Approver）に承認依頼通知を送信する。
6. IF 必須項目のいずれかが未入力の場合, THEN THE Expense_Request SHALL 申請の提出を拒否し、未入力項目を示すエラーメッセージを返す。
7. IF Expense_Category が有効な勘定科目に対応しない場合, THEN THE Expense_Request SHALL 申請の提出を拒否し、無効な費目である旨のエラーメッセージを返す。
---
### Requirement 2: 証憑画像のアップロードと保存
**User Story:** 申請者として、証憑画像をアップロードすることで、法令要件を満たした経費申請を行いたい。
#### Acceptance Criteria
1. WHEN Applicant が証憑画像をアップロードする, THE Storage_Service SHALL 画像を受け付け、申請レコードに関連付けて保存する。
2. THE Storage_Service SHALL Receipt を申請承認後7年間保持する。
3. IF アップロードされたファイルが対応フォーマット（JPEG、PNG、PDF）以外の場合, THEN THE Storage_Service SHALL アップロードを拒否し、対応フォーマットを示すエラーメッセージを返す。
4. IF アップロードされたファイルサイズが上限（10MB）を超える場合, THEN THE Storage_Service SHALL アップロードを拒否し、サイズ上限を示すエラーメッセージを返す。
---
### Requirement 3: 一次承認（直属上長による承認）
**User Story:** 承認者として、経費申請を承認または差し戻すことで、部下の経費使用を管理したい。
#### Acceptance Criteria
1. WHEN Primary_Approver または Proxy_Approver が申請を承認する, THE Workflow_Engine SHALL 承認操作を Approval_History に操作者・日時・コメントとともに記録する。
2. WHEN Primary_Approver または Proxy_Approver が金額5万円未満の申請を承認する, THE Workflow_Engine SHALL 申請ステータスを「承認済み（確定）」に設定し、Applicant に承認完了通知を送信する。
3. WHEN Primary_Approver または Proxy_Approver が金額5万円以上の申請を承認する, THE Workflow_Engine SHALL 申請ステータスを「二次確認待ち」に設定し、Accounting_Staff に確認依頼通知を送信する。
4. WHEN Primary_Approver または Proxy_Approver が申請を差し戻す, THE Workflow_Engine SHALL 差し戻し操作を Approval_History に操作者・日時・コメントとともに記録し、申請ステータスを「差し戻し」に設定し、Applicant に差し戻し通知とコメントを送信する。
5. IF Primary_Approver が不在かつ Proxy_Approver が指名されていない場合, THEN THE Workflow_Engine SHALL エスカレーション通知を管理者に送信する。
---
### Requirement 4: 代理承認者の指名
**User Story:** 直属上長として、不在時に代理承認者を指名することで、申請の滞留を防ぎたい。
#### Acceptance Criteria
1. WHEN Primary_Approver が Proxy_Approver を指名する, THE Workflow_Engine SHALL 指名された Proxy_Approver を申請の代理承認者として登録し、代理期間（開始日・終了日）を記録する。
2. WHILE Proxy_Approver の代理期間が有効である, THE Workflow_Engine SHALL 一次承認権限を Proxy_Approver に委譲する。
3. WHEN 代理期間が終了する, THE Workflow_Engine SHALL 一次承認権限を Primary_Approver に戻す。
4. THE Workflow_Engine SHALL Proxy_Approver の指名・解除操作を Approval_History に記録する。
5. IF 指名された Proxy_Approver が同一申請の Applicant である場合, THEN THE Workflow_Engine SHALL 指名を拒否し、利益相反の旨のエラーメッセージを返す。
---
### Requirement 5: 二次確認（経理担当による確認）
**User Story:** 経理担当として、5万円以上の経費申請を最終確認することで、適切な会計処理を行いたい。
#### Acceptance Criteria
1. WHEN Accounting_Staff が5万円以上の申請を確認・承認する, THE Workflow_Engine SHALL 確認操作を Approval_History に操作者・日時・コメントとともに記録し、申請ステータスを「承認済み（確定）」に設定し、Applicant に承認完了通知を送信する。
2. WHEN Accounting_Staff が申請を差し戻す, THE Workflow_Engine SHALL 差し戻し操作を Approval_History に操作者・日時・コメントとともに記録し、申請ステータスを「差し戻し」に設定し、Applicant に差し戻し通知とコメントを送信する。
3. WHILE 申請ステータスが「二次確認待ち」である, THE Workflow_Engine SHALL 一次承認者（Primary_Approver または Proxy_Approver）が追加の変更を加えることを拒否する。
---
### Requirement 6: 差し戻し申請の修正と再提出
**User Story:** 申請者として、差し戻された申請を修正して再提出することで、経費精算を完了させたい。
#### Acceptance Criteria
1. WHEN 申請ステータスが「差し戻し」である, THE Workflow_Engine SHALL Applicant が申請内容（金額・費目・目的・証憑画像）を修正することを許可する。
2. WHEN Applicant が差し戻し申請を修正して再提出する, THE Workflow_Engine SHALL 申請ステータスを「一次承認待ち」に戻し、再提出操作を Approval_History に記録し、Primary_Approver（または Proxy_Approver）に承認依頼通知を再送する。
3. IF 差し戻し申請の再提出日が Closing_Date 以降である場合, THEN THE Workflow_Engine SHALL 申請の対象月を翌月として更新する。
4. THE Workflow_Engine SHALL 差し戻し前の申請内容を Approval_History で参照可能な形で保持する（上書き禁止）。
---
### Requirement 7: 承認履歴の記録と参照
**User Story:** 経理担当および監査担当として、誰がいつ何を承認したかを追跡することで、監査要件を満たしたい。
#### Acceptance Criteria
1. THE Approval_History SHALL 各操作（提出・承認・差し戻し・確認・代理指名）について、操作者ID・操作日時・操作種別・コメントを記録する。
2. THE Approval_History SHALL 記録された情報を変更・削除不可（イミュータブル）として保持する。
3. WHEN 権限のあるユーザー（Accounting_Staff または管理者）が申請の Approval_History を参照する, THE Workflow_Engine SHALL 当該申請に関するすべての操作履歴を時系列順で返す。
4. IF 権限のないユーザーが他者の申請の Approval_History を参照しようとする場合, THEN THE Workflow_Engine SHALL 参照を拒否し、権限不足のエラーメッセージを返す。
---
### Requirement 8: 月次締め処理と未処理申請の管理
**User Story:** 経理担当として、月次締め日までに未処理申請の状況を把握することで、月次処理を期日内に完了させたい。
#### Acceptance Criteria
1. WHEN Closing_Date（毎月25日）の5営業日前になる, THE Notification_Service SHALL 未処理の申請（「一次承認待ち」または「二次確認待ち」）を持つ Primary_Approver および Accounting_Staff にリマインダー通知を送信する。
2. WHEN Closing_Date になる, THE Workflow_Engine SHALL 当月の未処理申請件数と申請者リストを Accounting_Staff に通知する。
3. THE Workflow_Engine SHALL Accounting_Staff が当月の未処理申請一覧を任意のタイミングで参照できる機能を提供する。
前回の「漏れ」は、ほぼ埋まった
生成された要件定義書(requirements.MD)は8要件。前回欠けていた項目と突き合わせると:
金額による承認者の分岐 — ✅ 5万円未満は上長のみ、以上は経理の二次確認へ
代理承認 — ✅ 丸ごと1要件に。しかも指示に書いていない「代理期間の管理」「代理人が申請者本人なら利益相反で拒否」まで足してきた
締め日 — ✅ 当月/翌月の振り分けに加え、「締め日5営業日前の未処理リマインダー」を設定
7年保存・監査 — ✅ 証憑の保存期限、履歴は変更・削除不可（イミュータブル）
たとえば金額分岐は、EARS記法でこう書かれている。
WHEN Primary_Approver または Proxy_Approver が金額5万円未満の申請を承認する, THE Workflow_Engine SHALL 申請ステータスを「承認済み（確定）」に設定する
EARS記法について簡単に紹介（Codex利用）
EARSは、正式には Easy Approach to Requirements Syntax と呼ばれる、自然言語の要件を一定の型に当てはめて記述する方法です。
日本語では「簡易要件構文」「構造化要件記法」などと説明できます。2009年にAlistair Mavinらが発表した手法で、曖昧・複雑・冗長・検証不能になりやすい自然言語要件を、5種類のテンプレートで整理します。原論文の書誌情報と概要
EARSの基本構造
一般形は次のようになります。
＜前提条件＞＋＜トリガー＞
THE ＜システム名＞ SHALL ＜システムの応答＞
日本語にすると、おおむね次の意味です。
＜特定の状態・条件＞で、＜イベント＞が発生したとき、 ＜システム＞は＜観測可能な動作＞を実行しなければならない。
前回「無い」と書いた項目が、指示に4項目書いただけで、ここまで具体化された。
セッション終了時。26ツール実行・2.59クレジット。
同じものさしで再評価してみる
目標 — X → ○。文書の冒頭に「滞留の解消・月次処理・監査対応」が明記された。ただしこれは私の指示の写しで、Kiroが聞き出したものではない
人間 — △ → ○。3つの役割と代理承認者が要件に織り込まれた。利益相反の拒否はKiroの加点。ただし「誰が誰の上長か」をどう知るかは未定義のまま
システム — ◎ → ◎。前回から引き続き厚い。今回は指示した業務ルールが正確に反映された
データ — △ → ○。費目は勘定科目対応、証憑は7年保存、履歴には操作時の金額スナップショットまで入った
全視点が改善した。ただし——改善したのは、指示に書いた分のみ。
わざと書かなかった2つは、どうなったか
下書き保存 — 今回も要件なし。ただし前回のような内部矛盾（用語集にだけ存在する）も消えた。
承認後の後工程 — 今回も無言でスコープ外。「精算や支払はスコープ外でよいか」という確認は来ない
そして予想外の発見がひとつ。前回の要件にあった「申請の取り下げ」が、今回は消えていた。指示に書かなかったからだ。構造化した指示は反映の精度を上げる。だが書き漏らしたものは、そのまま漏れる。指示の質が上がるほど、Kiroは指示に忠実になる——良くも悪くも。
今日のまとめ
指示を4つの視点で構造化しても、Kiroからの業務の質問は増えない（プロセス質問2＋システム視点の分析質問2のみ）
生成される要件定義書は劇的に改善した。前回の「無いものリスト」がほぼ埋まり、利益相反チェックやリマインダーなど指示以上の提案もあった
ただし改善は「指示に書いた分だけ」。書き忘れた取り下げ機能は静かに消えた
10分で書ける構造化指示に、これだけの効果がある。要求を4つの視点で整理する側の技術が、AI時代にそのまま通用する
タグ
#AIエージェント #Kiro #AWS #要件定義 #要求定義 #スペック駆動開発 #システム開発 #SE #生成AI #50代
