AIで仕様書を作成する方法：新規開発と既存システムの手順、精度を上げる執筆ルール

「仕様書をAIに書かせたい」というご相談は、大きく2つに分かれます。これから作るシステムの要件定義書や設計書をAIで書きたいという新規開発の話と、動いているシステムの仕様書が残っていないのでソースコードから起こしたいという既存システムの話です。入力するものも、AIに任せられる範囲も、確認の仕方も異なります。

この記事では、両方の手順を整理したうえで、当社が仕様書化の案件で実際に使っている執筆ルールを紹介します。AIへの指示の組み立て方、AIが書いた仕様書に出やすい癖と直し方、人による確認の進め方、仕様書をコードと乖離させない運用も扱います。既存システムの仕様書化で何が出て何が出ないか、費用の目安はソースコードから仕様書をAIで作成するで、ツール・専用製品・委託の違いは仕様書の自動生成は自社でやるか委託するかで扱っているので、あわせてご覧ください。

AIで作成できる仕様書の範囲

生成AIが仕様書の作成に使えるようになった一番の変化は、コードや要件を読んで文章の仕様書を出せるようになったことです。以前のツールが出力していたのは呼び出し関係やCRUD図のような構造情報で、読むにはプログラミングの知識が必要でした。

ただし、仕様書の種類によってAIに任せられる度合いは異なります。

共通しているのは、AIが出せるのは材料から導ける事実と草案であって、決めることは人に残るという点です。新規開発なら要件や業務ルールを決めるのは発注側で、AIはその決定を促す論点を並べます。既存システムなら、コードに書かれている事実はAIが網羅的に起こせますが、なぜそうなっているかは業務担当者様にしか答えられません。

新規開発の仕様書をAIで書く手順

入力を揃える：
AIに「受注管理システムの要件定義書を書いて」とだけ頼めば、一般的な受注管理の要件が返ってきます。それは貴社の要件ではありません。業務フロー、現行の画面や帳票、既存のデータ項目、困っていることの一覧を先に集め、AIにはそれらを読ませたうえで書かせます。入力が足りない箇所は、AIに「決めるために必要な情報」を質問として出させると、ヒアリングの抜けも減ります。

段階ごとに生成する：
概要、基本設計、詳細設計を一度に書かせると、要件定義書にAPIの引数が混じり、詳細設計書に業務の目的が繰り返し再掲されます。段階ごとに入力を分け、前の段階の成果物を次の入力にします。各段階で何を書き何を書かないかの線引きは、後述する執筆ルールの中心です。

決めたことと決めていないことを分けて書く：
生成AIは空欄を嫌い、決まっていないことも自然な文章で埋めてしまいます。締め日の扱いや例外時の運用のように未決定の事項は「確定範囲外とする」と書き、確認先を添えます。曖昧なまま自然な文で書かれた仕様書は、実装段階で解釈の食い違いを生みます。

レビューする：
抜け、矛盾、実装可能性、用語の統一の4点を見ます。AIは同じ対象を別の言葉で言い換える癖があり、「得意先」と「顧客」が混在した仕様書はそのまま実装の混乱になります。用語表を先に作り、AIにも読ませておくと防げます。

既存システムの仕様書をAIで起こす手順

4つの情報源を集める：
ソースコード、データベース定義、画面と帳票の実物、ログの4つです。コードだけでも機能一覧や処理フローは起こせますが、画面のレイアウトは実物と突き合わせないと仕上がらず、使われていない機能の判定にはログが必要です。本番と同じバージョンのコードを揃えることが最初の作業になります。

暫定仕様書を生成する：
AIが4つの情報源を突き合わせ、機能一覧、画面・帳票ごとの仕様、データ項目定義、処理フロー、外部システムとの依存関係を暫定版として起こします。このとき、記述の根拠になったコードの位置を併記させます。後で疑問が出たときにコードへ戻れるためで、レビューの効率が大きく変わります。

確認事項を抽出する：
コードから読めない箇所は、AIが正しそうな形に直すのではなく確認事項として一覧にします。「取引区分が9の得意先を除外している理由」「納品日が受注日より前でも登録できる挙動は仕様であるか」といった項目です。当社の経験では、業務上の意図に関わる確認事項の多くは、業務担当者様なら数分で答えられるものです。難しいのは答えることではなく、洗い出すことです。

読み合わせで確定する：
業務担当者様との読み合わせで確認事項を解消し、仕様書を確定させます。どこまで埋めるかで費用と納期が変わります。出せるもの、出ないもの、費用の目安はソースコードから仕様書をAIで作成するにまとめています。当社ではAI仕様書作成サービスとしてこの手順で承っています。

AIへの指示の組み立て方

手順が決まっていても、AIへの指示が「仕様書を書いて」の一言では、上で述べた段階の混在や未決定の埋め込みがそのまま起きます。当社が指示に含めている要素は次の5つです。

• 役割と読み手。「業務システムの詳細設計書を書く技術者」として、読み手は「業務知識のない新規参画エンジニア」と明示する
• 入力の範囲。今回読ませるコードやDB定義のパスを列挙し、それ以外から推測しないよう指示する
• 出力の書式。節の名前と順序を固定し、表の列名まで指定する。書式が固定されていると、複数の画面やAPIをまたいで比較しやすくなる
• 書かないこと。実装の再掲、生成事情、他の段階の内容、認証情報の値
• 確認事項の出し方。コードから判断できない箇所は本文に推測を書かず、「確認事項」の節に、何が分からないか、誰に確認すべきかを書く

書式の指定は、Excelの設計書テンプレートをそのまま渡すより、節の名前と表の列名を文字で列挙するほうが安定します。AIが読みやすいのは、見た目より構造です。

精度を左右する執筆ルール

AIに仕様書を書かせると、最初の出力はそれらしく整っています。読み進めると、段階が混ざり、コードの再掲が続き、「重要です」のような水増しが目につきます。当社が数十万行規模のシステムの仕様書化を手がける中で固めた執筆ルールは、AIに与える指示であると同時に、人がレビューするときの観点でもあります。原則は5つです。

段階を混ぜない：
概要レベルに詳細レベルを持ち込みません。要件定義書にAPIの引数を書かず、詳細設計書に全体像を再掲しません。次の図は、各段階でAIに渡す入力と、書くこと・書かないことの線引きです。

存在理由が説明できないものは書かない：
コードを読めば分かることの再掲は避け、なぜ、どこまで、何のために、を書きます。「この関数はorderテーブルを更新する」はコードに書いてあります。仕様書に必要なのは「受注確定時に在庫を引き当て、引当に失敗した場合は受注を保留にする」という業務上の意味です。

仕様本文と生成事情を混ぜない：
「資料が不足しているため」「抽出元のコードでは」「レビュー未実施」といった、仕様書を作る側の事情は本文に書きません。AIはこの種の但し書きを好んで入れますが、読み手にとっては仕様として読めない文です。確定できないことは「確定範囲外とする」と境界だけを書き、事情は作業メモに分けます。

標準的な仕様書表現を使う：
日本の業務システムで一般的な設計書の語彙と文体に寄せます。「重要です」「注意が必要です」「〜と考えられます」「まずは」のような説明の水増しは、「留意点」「前提」「制約」「対象外」「確認事項」に置き換えます。

簡潔化と説明省略を区別する：
削るのは水増しと再掲であって、業務文脈の説明ではありません。「誰が、いつ、何のために使うか」を業務の言葉で述べたリード文は、冗長に見えても残します。仕様書は参照資料であると同時に、新しく参画する人の学習資料でもあるからです。

具体的な書き方の規則

5原則を、AIへの指示とレビュー観点に落とした規則の一部です。

• 実装識別子を主語にしない。「orderFlgが1のとき」ではなく「受注確定（orderFlg=1）のとき」と日本語の状態名を先に立て、識別子は括弧で併記する
• 表や図の前に、それが何を示しどう読むかを1〜2行の文章で書く。表だけの節を作らない
• 「行わない処理」と、その処理がどこで担保されるかを書く。APIが所有者確認をしないなら、画面側の権限チェックで担保していることまで書く
• 網羅性を曖昧にしない。「代表的な項目」で済ませず、全件を載せるか、全件一覧の所在と載せた範囲を明記する
• 認証情報の値を仕様書に複製しない。コードに埋め込まれていても、存在の事実と実装位置だけを書く

いずれも、指示がなければAIが逆の書き方をしやすい項目です。

AIが書いた仕様書に出やすい癖と直し方

執筆ルールを指示しても、初版には一定の癖が残ります。当社がレビューで繰り返し直している癖を、例とあわせて整理します。

次の図は、こうした指摘を一覧にしたレビュー資料のイメージです。

※実案件のものではなく、当社で作成したサンプル資料です。

癖の多くは機械的に検出できます。当社では「重要です」「代表的」「資料が不足」のような語句の検索と、識別子が文頭に来る文の抽出を自動化し、人のレビューは業務上の意味と責務の境界に集中させています。

AIが書いた仕様書の確認の進め方

コードと実物との突き合わせ：
既存システムの仕様書では、記述と実際のコード、データベース定義、動いている画面を突き合わせます。根拠になったコードの位置が併記されていれば、この作業は大幅に短くなります。セキュリティ会社のラックが2023年に公開した検証記事では、同じソースコードに同じ指示を与えても生成AIの出力は毎回言い回しが変わり、確認には対象言語を読める人が必要だったと報告されています。出力をそのまま確定版にせず、突き合わせを前提に運用します。

業務担当者様による確認：
確認事項への回答には、開発の知識がなくても業務を説明できる方に加わっていただきます。回答者と期限を決め、確認事項の一覧を共有の管理表で追うと、確認の往復で全体の期間が延びるのを防げます。Zennに公開されたログラスの技術ブログでも、AIにコードから仕様書を書かせる取り組みで、複雑な業務の文脈をコードから読み解く精度は低く、人のヒアリングで補ったと報告されています。誰が確認するかを最初に決めておく点は、規模を問わず共通です。

新規開発のレビュー観点：
抜け、矛盾、実装可能性、用語の統一の4点に加え、決めていないことが自然な文で埋められていないかを見ます。AIの仕様書は読みやすいぶん、未決定の事項が確定事項のように見えます。確定範囲外の宣言があるかを確認します。

仕様書をコードと乖離させない運用

仕様書は作った瞬間から古くなり始めます。改修のたびに更新されなかった設計書が実装と食い違い、誰も信用しなくなる状態は、仕様書がない状態と同じ問題を生みます。JUASの企業IT動向調査2025では、システム開発の内製化の課題として「現行システムの仕様がわからない」を挙げた企業が24.6%ありました。仕様書があっても現行と合っていなければ、この数字に含まれます。

AIで仕様書を作る利点は、更新もAIに任せられることです。ソースコードの変更差分から、影響を受ける仕様書の箇所を特定し、更新案を出させ、人がレビューして反映します。当社ではこの流れを、仕様書を閲覧するWikiと組み合わせて運用しています。更新の単位は画面・API・バッチといった仕様書の分冊単位に揃え、差分が小さいときはAIの更新案をそのまま採用し、業務ルールに関わる変更は確認事項として扱います。

新規開発でも考え方は同じです。仕様書をAIが読める形式で管理しておけば、実装後にコードから仕様書を検証し、食い違いを検出できます。

自社実施と委託の判断基準

社内にコードを読めるエンジニアがいて、対象が数千行から数万行の規模なら、汎用のAIツールで自社で進める選択肢があります。対象が数万行を超える、業務上の意図まで文書にしたい、確認事項の洗い出しから任せたい、という場合は委託が現実的です。ツール、専用製品、委託の違いは仕様書の自動生成は自社でやるか委託するかで整理しています。

当社のAI仕様書作成サービスでは、NDAを締結のうえソースコードの一部をお預かりし、出せる仕様書の種類と粒度、確認事項の量の見込み、概算費用を無料診断でご提示しています。仕様書作成のみのご依頼に対応しており、費用は規模と目的により数十万円から数百万円が目安です。

まとめ

AIで仕様書を作成するときの手順は、新規開発なら入力を揃え、段階ごとに生成し、未決定を明示し、レビューする、既存システムなら4つの情報源を集め、暫定仕様書を生成し、確認事項を抽出し、読み合わせで確定する、という流れです。精度を決めるのはAIの性能より、段階を混ぜない、コードの再掲をしない、生成事情を混ぜない、標準的な表現を使う、簡潔化と説明省略を区別する、という執筆ルールと、それに沿ったレビューです。

AIが書いた仕様書の癖は決まっており、機械的に直せます。人のレビューは業務上の意味と責務の境界に集中させ、確認事項に答える業務担当者様を最初に決めておくことが、期間と品質の両方に効きます。

よくある質問

Q. ChatGPTだけで仕様書は作れますか？

小さな対象なら可能です。関数やファイル単位の説明、画面1つ分の項目一覧は、コードを渡せば出てきます。数十画面を超える規模で体系立てた仕様書にするには、段階ごとの入力の整理、出力の検証、確認事項の管理が必要になり、エンジニアの作業量が増えます。

Q. AIが書いた仕様書をそのまま納品物や監査資料にできますか？

そのままでは推奨しません。コードとの突き合わせ、業務担当者様による確認事項の回答、人のレビューを経て確定させたものを納品物にします。当社では確定前の版に「暫定」の表示を付け、確定した版と区別しています。

Q. 仕様書の形式はExcelとMarkdownのどちらがよいですか？

AIに読ませて更新し続けるならMarkdownが扱いやすく、社内での配布や監査への提出はExcelが求められることが多くあります。当社ではMarkdownを基本にし、必要に応じてExcelへ変換してお渡ししています。閲覧用にWiki形式で提供することも可能です。