AI仕様書の作り方｜Kakusillで揃える5項目
目次
はじめに
たとえば、架空の受注管理案件で、生成AIに次の依頼をしたとする。
「受注管理を効率化したい。承認もできるようにしてほしい」
この2行を渡すと、ログイン、検索、承認通知まで補った仕様書が短時間で返ることがある。見栄えはいい。だが、承認者は誰か。差し戻し後はどの状態へ戻るのか。月末にアクセスが集中しても耐えられるのか。肝心なことは決まっていない。
流暢な文章と、合意できる仕様は別物である。AIによる仕様書作成で怖いのは、空欄が残ることではない。未確定事項が、もっともらしい確定事項に変わることだ。
AI仕様書の作り方で先に整えたいのは、長いプロンプトではない。目的、利用者、業務フロー、例外、品質条件の5項目である。Kakusill（カクシル）を使う場合も、この順番は変わらない。
AI仕様書を丸投げすると、未確定事項が確定事項に変わる
生成AIは文章の下書きや論点出しが得意だ。一方、社内だけで通じる言葉や、会議で言い切らなかった前提までは保証できない。
CyberAgentの仕様書作成・レビュー事例では、仕様書のフォーマットに加え、サービス用語集や過去仕様のアーカイブを整えている。AIへ「仕様書を書いて」と頼むだけでは、形式も観点も毎回ぶれるからだ。
実務では、AIの補完をすべて止める必要はない。補完した箇所を仮説として区別できればよい。「不明なら空欄」「推測したら要確認と表示」という境界を置く。AIに仕様書を生成させる際の注意点でも、仕様と要望、将来予定を分ける考え方が示されている。
2026年9月時点のKakusillは、要求整理と仕様書管理を二つの面から支援している。要求整理では、目的や粗い依頼と、ワークスペースの「資料集」へ登録したPDF・Office文書・テキストなどを材料にAIがヒアリングし、業務フローや要件定義書などの成果物へまとめる。仕様書管理エディタでは、ページを編集し、AIへ修正を依頼しながら、履歴・差分や共有状態を確認できる。
大切なのは、資料を入れただけで正しい仕様が自動確定するわけではない点だ。根拠のある事実、仮説、未決事項を人が確認する。この先では機能紹介を広げず、Kakusillへ渡す情報をどう準備するかに絞る。詳しい機能はKakusillのプロダクトページで確認できる。
AI仕様書の作り方｜先に揃える5項目
ここからは架空の「受注管理システム」を例にする。最初のメモは「Excel管理をやめ、承認を早くしたい」だけだ。この状態から、5項目を順に埋めていく。
1. 目的と成功条件
「効率化したい」では測れない。何がどう変われば成功かを置く。
- 月末の受注集計を2営業日から半日に短縮する
- 二重入力をなくし、転記ミスを月1件以下にする
- 申請から一次承認までを4営業時間以内にする
数字は例であり、現場の実測値に置き換える。AIに目標値を決めさせてはいけない。事業側が引き受ける判断だからだ。
IPAの要件定義ガイドは、要件定義で起きる問題を48項目、解決の勘どころを128項目に整理している。仕様書は機能一覧ではない。背景、要求、関係者の合意をつなぐ文書である。
2. 利用者と権限
次に「誰が何を見て、どこまで操作するか」を決める。
受注担当は申請できる。営業部長は100万円以上を承認する。経理は確定済みデータを閲覧できる。ただし、申請内容は変更できない。退職者の権限は当日中に停止する。
役割名だけでは足りない。閲覧、登録、更新、承認、削除、出力を分ける。代理承認や兼務も忘れやすい。あなたのチームでは、担当者が休んだ日の承認を誰が引き継ぐだろうか？
3. 正常系の入力・判断・出力
業務を「入力→判断→出力」で一本につなぐ。
受注担当が顧客、商品、金額、納期を入力する。顧客コードの存在と金額を検証する。100万円未満なら課長へ、以上なら部長へ送る。承認後は受注番号を発行し 、基幹システムへ連携する。
この粒度なら、画面、API、データ、テストへ展開しやすい。逆に「承認機能を実装する」だけでは、設計者もAIも空白を埋めるしかない。仕様の読みやすさをさらに整えるなら、AIが読める仕様書の3つの設計原則もあわせて確認してほしい。
4. 例外処理と未確定事項
正常系だけの仕様書は、デモでは動く。運用で止まる。
- 顧客コードが見つからない
- 承認者が不在で期限を超えた
- 基幹システムとの連携に失敗した
- 承認後に金額が変更された
- 同じ受注が二重送信された
各例外に「検知方法」「利用者への表示」「再実行」「連絡先」を付ける。ただし、その場で決められないこともある。その場合は「要確認：経理部、9月3日まで」のように残す。空欄を恥じる必要はない。勝手な確定より、期限付きの保留の方が安全だ。
5. 品質条件と受け入れ条件
機能が同じでも、同時利用10人と1,000人では設計が変わる。利用時間、応答時間、データ量、復旧時間、監査ログ、保存期間を具体化する。
IPAの非機能要求グレードは、非機能要求を網羅的に分類し、重要な項目から段階的に要求レベルを合意する方法を示している。一度に全項目を埋めるのではない。業務への影響が大きい順に決めるのが現実的だ。
受け入れ条件は「正しく表示される」ではなく、観察できる文にする。たとえば「承認済みの受注は5分以内に基幹システムへ連携される」「連携失敗時は受注担当と運用担当へ通知され、管理画面から再実行できる」と書く。ここまで決まると、テストの入口が見えてくる。
Kakusillで会話を仕様に変える4ステップ
前の5項目は、仕様書に必要な情報の箱だ。ここからの4ステップは、その情報をKakusillの要求整理と仕様書管理エディタで集め、関係者と確認する進め方である。清書だけで終わらせず、不足論点の確認と変更履歴までつなげる。
素材を加工せずに集める
議事録、現行Excel、業務マニュアル、既存仕様書を集める。最初から一つの美しい文書へ直す必要はない。ただし、最新版と参考資料は区別する。古い資料が混ざるなら、日付と利用可否を付ける。
最初の入力 は、次のような短いメモで十分だ。
- 目的：月末集計の転記を減らす
- 利用者：受注担当、課長、部長、経理
- 現行業務：Excel入力後、メールで承認依頼
- 困りごと：差し戻し理由と最新版が追えない
- 未定：金額別の承認者、保存期間
この時点では、5項目を埋め切らない。事実と不足を並べ、次の質問を作れる状態にする。
AIの質問に「事実・仮説・未定」で答える
「承認は部長です」は事実か、担当者の記憶か。規程で確認できるか。回答の確度を分けると、AIが断定しにくくなる。Kakusillのヒアリングで不足論点が出たら、分からない項目も未定と明示する。
たとえば「100万円以上は部長承認ですか？」への回答を、「仮説：現行Excelでは部長印が多い。要確認：経理規程、担当は営業企画」と残す。すると、権限の仕様と未決事項が混ざらない。
章ごとに担当者へ返す
業務フローは現場担当、権限は管理者、非機能要件は情シス、成功条件は責任者へ返す。一人のレビューで全部を確定しない。ステークホルダーの分析で決める5項目を先に整理すると 、確認先が曖昧になりにくい。
承認と変更を残す
誰が、いつ、何を確認したかを残す。未決事項も消さない。Kakusillの仕様書管理エディタでは、ページの履歴と差分を確認でき、関連する仕様ページもワークスペース内で管理できる。文章を完成させるより、変更前後と判断の根拠を追える状態を作る方が大切だ。
AIが作った仕様書を15分で確認するチェックリスト
初稿が出たら、次の7点を短時間で確認する。
- 元資料にない固有名詞や数値が増えていないか
- 同じ言葉を部署ごとに違う意味で使っていないか
- 正常系だけで、失敗時の扱いが抜けていないか
- 閲覧者、更新者、承認者が分かれているか
- 「迅速に」「適切に」など測れない表現が残っていないか
- 未確定事項に担当者と期限があるか
- 受け入れ条件を第三者が判定できるか
一つでも答えに詰まったら、文章を直す前に関係者へ聞く。正直なところ、AIに再生成させるだけでは合意は増えない。AIが誤解する仕様書のアンチパターンも、レビュー観点として役立つ。
仕様書作成の一般的な5ステップを扱う解説は、生成AIの用途として壁打ち、ドラフト生成、抜け漏れや矛盾の確認を挙げている。AIを使うほど、承認者の役割は薄くならない。むしろ明確になる。
仕様書の完成は、文章が埋まった時ではない
AI仕様書の作り方はシンプルだ。目的、利用者、業務フロー、例外、品質条件を揃える。Kakusillのヒアリングで不足を洗い出し、仕様書管理エディタで変更を重ねる。出力後は、根拠、保留、確認者を確かめる。
完成の基準は、全ページが埋まったことではない。決まったことと未決事項が区別され、次の設計者が迷わず判断できることだ。
Atsumellでは、Kakusillを使った要求整理から、要件定義、設計、AI駆動開発までを一緒に組み立てている。既存資料が散らばり、どこから仕様にすべきか迷っているなら、まずは素材の状態から相談してほしい。
