仕様書のテンプレート｜AIが読める7つの項目

仕様書のテンプレートを探すと、画面項目、機能一覧、データ定義など、立派なひな形がいくつも見つかる。ところが、空欄を埋めただけでは開発が始められないことがある。

「申請を登録する」と書いてあっても、誰が登録できるのか。承認前後で編集できるのか。入力が欠けたら止めるのか。ここが決まっていなければ、実装者もAIも都合よく補完する。

必要なのは、ページ数の多い文書ではない。目的、権限、入力、判断、出力、例外、合格条件がつながった仕様書だ。まずは1機能につき1枚でよい。

ここで扱う7項目は、1機能の機能仕様をレビューするための最小セットである。性能、可用性、セキュリティ、監査、運用、データ定義、外部インタフェースは別紙で管理し、この1枚から関連先をたどれるようにする。

仕様書のテンプレートは「項目数」で選ばない

仕様書は、読む人が同じ判断へたどり着くための道具である。IPAの要件定義ドキュメントでも、業務、データ、状態遷移、外部インタフェース、非機能要件など、複数の成果物を関連づけて不整合を防ぐ考え方が示されている。

だから、すべてを一つの巨大な表へ押し込む必要はない。大切なのは、各項目のつながりを追えることだ。

たとえば「経費申請を登録する」という機能なら、次の関係を確認する。

• 目的を達成するために、誰が操作するか
• 操作時に、何を入力するか
• 入力と現在の状態から、何を判断するか
• 判断の結果として、何を保存・表示・通知するか
• どの条件では進めず、人へ戻すか
• 何を確認できれば、完成とみなすか

必要な関係を追跡できれば、画面仕様やAPI仕様へ展開しやすい。超上流の成果物事例も、業務フロー、データ、画面・帳票、外部接続を別々に見ながら関係を確かめる構成になっている。

AIが読める仕様書に必要な7つの項目

以下の7項目を、1機能ごとに整理する。最初から完璧を狙わず、未決事項は「未定」と書き、決める担当者と期限を添える。

1. 目的

機能の名前ではなく、利用者が達成したい状態を書く。

悪い例は「経費申請機能を作る」。良い例は「従業員が領収書と利用目的を登録し、承認者が支払可否を判断できるようにする」だ。

目的があると、後から追加された項目が本当に必要か判断できる。目的に寄与しない機能は、別の仕様へ分ける候補になる。

2. 利用者と権限

役割ごとに、閲覧、作成、更新、承認、取消の可否を書く。「管理者は全部できる」では粗すぎる。

この表があると、画面の表示制御だけでなく、API側で拒否すべき操作も見える。

3. 入力

項目名だけでなく、型、必須条件、入力元、例をセットにする。

項目: 利用日

型: 日付（YYYY-MM-DD）

必須: はい

入力元: 申請者

制約: 未来日は不可

例: 2026-08-20

「日付を入力」の一行では、時刻やタイムゾーン、空欄、未来日の扱いが残る。AIへ渡すなら、正常例と拒否例を一つずつ置く。どの条件で解釈が分かれたかをレビューしやすくなる。

4. 状態と判断条件

状態、次へ進むきっかけ、判断条件を同じ行にする。

状態だけを書いても動作は決まらない。「誰が、どの条件で動かすか」まで書く。状態設計を深める場合は、状態遷移を先に決める方法も使える。

5. 出力と保存先

画面表示、保存データ、通知、外部連携を分ける。

• 画面: 申請番号と現在の状態を表示する
• 保存: 入力値、申請者、申請日時、仕様の版を保存する
• 通知: 承認担当へ申請番号と期限を通知する
• 外部連携: 承認済みだけを会計連携の対象にする

「通知する」だけでは、宛先、タイミング、再送、失敗時の扱いが未定のままだ。出力先ごとに成功と失敗を決める。

6. 例外と停止条件

正常系より先に、進めてはいけない条件を書く。

• 申請者に所属部門がない場合は送信しない
• 承認者が未設定なら担当窓口へ戻す
• 同じ領収書番号が存在したら重複候補として止める
• 外部連携が失敗しても、自動で申請を取消ししない

AIは空欄をそれらしく補いやすい。止める条件が明示されていれば、未確定の判断を勝手に埋めにくくなる。例外条件を先に決める考え方も、権限、状態、外部接続の3方向から整理している。

7. 受け入れ条件

最後に、正常系だけでなく、権限違反・入力不備・外部連携失敗も合格条件として再現できる形で書く。例外条件にはIDを振り、受け入れ条件から対応先を追えるようにする。

仕様の先頭には、版、状態、責任者、承認者、関連チケットも置く。クラウド設計の公式ガイドでも、下書き・レビュー中・承認済みといった状態、バックログ上の主要作業項目、関連仕様、意思決定者をテンプレートへ含めるよう勧めている。

変更履歴は7つの仕様項目とは別の管理情報として置く。本文を上書きするだけでなく、「何を」「なぜ」「誰が承認したか」を残し、受け入れ条件も同じ版で更新する。

そのまま使える1機能仕様テンプレート

次の形をコピーし、1機能から試す。

# 機能名

• 版:
• 状態: 下書き / レビュー中 / 承認済み
• 責任者:
• 承認者:
• 関連チケット:
• 要件ID:
• 展開先: 基本設計 / 詳細設計 / テスト仕様
• 責任分界: 発注者 / 元請 / 協力会社

1. 目的

• 利用者:
• 達成したい状態:

2. 利用者と権限

3. 入力

4. 状態と判断条件

5. 出力と保存先

• 画面:
• 保存:
• 通知:
• 外部連携:

6. 例外と停止条件

• 止める条件:
• 人へ戻す条件:
• 失敗時の戻し先:

7. 受け入れ条件

変更履歴

このテンプレートの狙いは、文章を増やすことではない。判断に必要な項目と未決事項を見分け、要件IDから設計書・テスト仕様書まで追跡できる状態にすることだ。SIer案件では、変更要求ごとに顧客承認者と影響を受ける成果物を紐づけると、元請と協力会社の責任分界もレビューしやすい。

記入前と記入後を比べる

たとえば、記入前の仕様が次の一行だったとする。

承認者へ通知する。

7項目で整理すると、少なくとも次の形まで具体化できる。

対象: 状態が「申請中」へ変わった申請

宛先: 申請者の所属部門に設定された承認者

内容: 申請番号、申請者、申請日、確認期限

送信回数: 状態遷移1回につき1件

停止条件: 承認者が未設定なら送信せず、担当窓口へ戻す

受け入れ条件: 通知履歴に申請番号と宛先を記録する

差は文章量ではない。対象、宛先、重複防止、停止、確認方法を追える点にある。既存の仕様書へ7項目を一度に追加する必要もない。まず曖昧な一文を選び、記入前と記入後を並べてレビューする。

テンプレートをレビューする順番

レビューでは誤字より先に、つながりを見る。

1. 目的に対して利用者が合っているか
2. 権限外の操作を拒否できるか
3. 入力から判断条件を再現できるか
4. 判断結果と出力が一対一で対応しているか
5. 例外時に止まり、人へ戻せるか
6. 受け入れ条件で正常・異常の両方を確認できるか
7. 変更したとき、関連する項目を追えるか

AIへレビューを頼む場合も、「不足を探して」だけでは弱い。各入力について、判断、出力、例外、受け入れ条件が存在するかを表で返させる。こうすれば、人とAIが同じ観点で確認できる。

仕様が複数の文書に散らばっている場合は、Kakusillで要件を構造化する流れも参考になる。Kakusillは、議事録や既存資料から要求を整理し、要件・設計・テストのつながりや変更影響を確認しやすくする。AIの出力をそのまま確定せず、人が不足事項と判断条件をレビューする前提で使う。

仕様書のテンプレートは、埋めるための帳票ではない。実装前に判断の穴を見つけ、変更後も同じ基準で確認するための作業台だ。まず一つの機能を7項目で整理する。そこで決め切れなかった項目が、次のヒアリングで確認すべき論点になる。

自社の仕様書をAIが読める形へ整理したい場合は、株式会社Atsumellへ相談することもできる。既存文書の棚卸しから、要件・設計の構造化まで支援している。

関連記事

• AIが読める仕様書の書き方
• AI要件定義ツールを選ぶ5つの軸
• API仕様書の書き方｜5つの契約