仕様書をAIで作成する｜生成AIに下書きさせる手順と確かめる所

当サイトの記事は編集部が国土交通省・IPA・デジタル庁などの公的機関の情報、規格や業界団体の公開情報を調べて独自に執筆しています。記事内にIT・Webエンジニアの転職サービスへの案内（広告）を含みます。

仕様書の作成にAIは使える？

仕様書は、作る物について「何を・どこまで・どんな条件で」を決めて、関係者で合意するための文書です。仕様書の基本は仕様書とは？意味と目的、設計書・要件定義書との違いでまとめています。

生成AIは、文章の型を作ったり、ばらばらのメモを表にまとめたりするのが得意です。一方で、あなたの会社の事情や、関係者の本音は知りません。

『じゃあ、AIに頼んでも意味がないの？』と思うかもしれませんね。そんなことはありません。白紙から書き始めるより、AIの下書きを直す方がずっと速いという場面はたくさんあります。

AIに任せると危ない場面

逆に、AIだけに任せると危ないのは「決めること」そのものです。予算や納期、どの機能を先に作るか、といった判断は、AIが代わりに決めることはできません。

もう一つ気をつけたいのが、もっともらしい間違いです。存在しない規格の番号や、根拠のない数字がさらっと混ざることがあるので、確かめる手間は省けないんです。

規格や公的なガイドラインの名前は、発行元のサイトで原文を開いて確かめるのがいちばん確実です。AIが挙げた出典は、あくまで探し始める手がかりと考えておきましょう。

AIに任せる所と人が決める所の役割表

『どこまでAIに頼っていいの？』という線引きが、いちばん迷うところですよね。編集部で、仕様書の項目ごとに役割を分けた表を作ってみました。

「数字の根拠」は人の仕事

例えば、「画面は3秒以内に表示する」という一文をAIが書いたとします。それらしく見えますが、その3秒は誰がどう決めたのか分かりませんよね。

数字を書く時は、業務の都合や今のシステムの実績など、根拠を人が用意します。AIには「根拠が無い数字は空欄にして、確認が必要と書いて」と頼んでおくと安心です。

生成AIに仕様書の下書きを作らせる手順

ここからは、生成AIを使って仕様書を作成する手順を順番に見ていきますね。対話型の生成AIなら、どのサービスでも考え方は同じです。

手順1：AIに渡すメモを作る

AIは、渡された材料からしか書けません。だから最初のメモの出来が、下書きの出来を左右するんです。

メモに入れたいのは、次のような事です。

手順2：骨組みを指定する

項目の骨組みは、自分で決めて渡すのがコツです。システムの要件定義書なら、デジタル庁のデジタル・ガバメント推進標準ガイドラインの考え方が参考になります。

このガイドラインでは、要件定義書に書く内容として、業務要件、機能要件（機能・画面・帳票・データ・外部インタフェース）、非機能要件、システム方式の決定が挙げられています。この並びを目次としてAIに渡すと、抜けの少ない下書きになりますよ。

項目の選び方は仕様書に書く項目と目次・表紙の作り方で詳しく紹介しています。

手順3：頼み方の例

AIへの頼み方は、短くても条件をはっきり書くのがポイントです。編集部が作った頼み方の例を表にしてみました。

「メモに無い事は書き足さない」という一言を入れておくだけで、もっともらしい作り話がぐっと減ります。ここはぜひ試してみてください。

手順4・5：人が直して、版を付けて残す

下書きが出てきたら、人が項目ごとに読んで直します。表の「両方で確かめる所」を見ながら読むと、見落としが減ります。

直し終わったら、関係者に見てもらい、合意した版に番号を付けて保存しましょう。生成AIの出力はMarkdownで受け取ると、差分を比べやすくなります。書き方は仕様書・設計書をMarkdownで書くで紹介しています。

設計書の作成・生成・レビューにAIを使う時のコツ

『仕様書より、設計書の方がAI向きじゃない？』という声もよく聞きます。たしかに、画面の項目表やテーブルの定義のように、形が決まった表はAIの得意分野なんです。

デジタル庁のガイドラインでは、画面や帳票など利用者に直接見える部分の基本設計を行った後に、機能を実現するための詳細設計を行う流れが示されています。AIで設計書を作る時も、この順番を守ると手戻りが減ります。

例えば、こんなやりとりで進めるとスムーズです。

「この要件定義書の機能一覧から、画面ごとの項目表を作って」
「項目の型や桁数が書かれていない所は、要確認にしておきますね」

設計書の種類や書き方は、設計書とは？で紹介しています。

仕様書駆動開発という考え方もある

最近は、AIに作業させる前提で、先に仕様書を書いてから実装に進む「仕様書駆動開発」という進め方も広がっています。受け入れの基準を「〜の時、システムは〜する」という形でそろえて書く記法を使うやり方もあります。

仕様書が主役になる理由は、仕様書駆動開発とは？で詳しく紹介しています。

設計書のレビューにAIを使う方法

設計書のレビューでAIが役に立つのは、あいまいな言葉や表記の揺れ、未定の項目を拾い出す所です。設計として正しいかどうかの判断は、人のレビューで行います。

『レビューの時間が足りない』という悩みは、多くの現場で聞かれますよね。人がレビューする前に、AIに一度見てもらうだけでも、指摘の数が減って本題に時間を使えます。

参考になるのが、日本の規格の書き方を決めたJIS Z 8301:2019です。要求は客観的に確かめられるものだけを書き、「十分に強い」のような表現は使わないとされています。AIに「確かめようのない表現を探して」と頼むと、この考え方に沿った見直しができますよ。

例えば、AIに見てもらうと、こんな直し方の候補が出てきます。表は編集部が作った例です。

AIの指摘は、あくまで候補です。全部を直す必要はないので、人が読んで採るかどうかを決めましょう。レビューの観点は設計書・仕様書のレビュー観点でも詳しく紹介しています。

ソースコードから設計書を自動生成する（リバース）時の注意

古いシステムを引き継いで、設計書が無くて困っている方も多いはずです。ソースコードから設計書を作る、いわゆるリバースは、AIが特に力を発揮しやすい作業なんです。

ソースコードから設計書を自動生成するフリーのツールには、関数の一覧や呼び出し関係を図や表にする物があります。生成AIで設計書をリバースする場合は、コードを読ませて処理の説明を文章にしてもらう使い方が多いですね。

ExcelのVBAで作った業務ツールでも考え方は同じで、VBAのコードから設計書を自動生成しても、業務のルールや例外の扱いは人が書き足す前提で見てください。

社外のサービスにコードを入れる前に

生成AIのサービスにソースコードや社内の文書を入れていいかは、会社のルールで決まっていることが多いです。お客様から預かったコードなら、契約で扱いが決まっている場合もあります。

使う前に、情報システム部門や上司に確かめておきましょう。リバースの手順そのものは、ソースコードから設計書を作る（リバース）で紹介しています。

AIと仕様書でよくある相談

Q&Aサイトでよく見かける相談を、内容を要約して紹介しますね。

相談1：AIでアプリがすぐ作れるなら、設計書は要らない？

『生成AIを使えば数分でアプリが作れると聞く。それなら設計書は要らないのでは』という相談です。小さな試作なら、設計書なしで作ってみるのも一つのやり方です。

ただ、仕事で使うシステムは、作った後に直したり、ほかの人に引き継いだりしますよね。何を作ったかが文書に残っていないと、AIに直してもらう時にも説明に困ります。むしろAIを使うほど、仕様書の大切さは増していくんです。

相談2：資料がほとんど無いシステムを引き継いだ

『ドキュメントがほとんど無いシステムの保守を引き継いだ。ソースを読んで機能を調べたい』という相談も、多く読まれています。こんな時こそ、ソースコードからのリバースにAIを使う出番です。

まずは画面やバッチの一覧を作り、よく使われる機能から順に処理の説明をAIに下書きしてもらいましょう。分からない所は、利用者に「この画面は何に使っていますか」と聞いて埋めていくと進めやすいですよ。

相談3：仕様書に条件分岐を全部書くのは無理では？

『プログラムの条件分岐を、仕様書に全部書くのは無理ではないか』という相談もあります。結論から言うと、仕様書に書くのは利用者から見た決まりで、コードの分岐を全部書き写す必要はありません。

ただ、例外の時にどう動くかは、書き漏れやすい所です。AIに「例外のケースを洗い出して」と頼むと、書くべき条件の候補を出してくれます。

AIを使いこなせる人は、上流工程で評価されやすい

AIの下書きを読み解いて、関係者の要望と照らして直す力は、要件定義や設計の仕事そのものです。こうした上流の経験は、上流工程を任される職場で評価されやすいんです。

今の職場で経験を積むのも、資格を取ってから動くのも、どちらも良い道です。今の担当工程から一歩進みたい方は、求人の仕事内容を比べてみると、進む先が見えてきますよ。上流工程に進む道筋は上流工程とは？で紹介しています。

よくある質問

まとめ

あわせて読みたい

仕様書とは？意味と目的、設計書・要件定義書との違い

仕様書駆動開発とは？AI時代の開発で仕様書が主役になる理由

仕様書の書き方｜誰が読んでも同じに伝わる7つのコツ