AIにWebツールを頼む前に書く一枚仕様書：入力・出力・やらないことの決め方

曖昧な依頼文だと何が起きやすいか

たとえば次のような依頼です。

勉強会の時間管理に使えるWebツールを作ってください。

人間同士なら聞き返せますが、AIは多くの場合、足りない部分を推測で埋めて作り始めます。このとき起こりやすいのは次のようなズレです（編集部の見立てで、計測した結果ではありません）。

• 想定していない機能が増える（ログイン、保存、共有、グラフなど）
• 入力の形が自分の使い方と違う（1人ずつ入力する画面なのに、貼り付けで一括入力したかった、など）
• 出力が使えない（画面表示だけで、参加者に送れる文章になっていない）
• 直したい箇所を言葉にできず、修正依頼が「なんか違う」になる

原因は、AIの性能よりも「完成の基準」が自分の頭の中にしかないことです。基準を書き出したものが、一枚仕様書です。

一枚仕様書のテンプレート

コピーして、各項目を埋めてください。全部で10〜15行ほどに収まる量が目安です。

【ツール名】
【目的】（誰の、どんな手間や迷いを、どう減らすか。1文）
【使う人】（自分だけ／身近な数人／不特定多数。パソコンかスマホか）
【入力】
 - 項目名：形式（文字／数字／時刻など）、必須か任意か、例
 - 
【出力】
 - 何が、どんな形で出るか（表／文章／ボタンでコピー など）
 - 出力の例（実際の1件分を書く）
【うまくいったと言える状態】（自分で確認できる条件を2〜3個）
【対象外（やらないこと）】
 - 
 - 
【制約】（無料の範囲／ファイル1つで動く／外部サービスを使わない など）

各項目で迷いやすい点

目的は機能の羅列ではなく、手間の削減として1文で書きます。「時間管理ツール」ではなく「登壇者ごとの開始時刻を手計算せずに出す」のようにします。

使う人は、画面の作り方に直結します。自分だけが使うなら、デザインや説明文は最小限で済みます。他の人に配るなら、使い方の説明やスマホ表示が仕様に入ります。

入力は、項目名だけでなく例を必ず添えます。「登壇者名と持ち時間」ではなく、「田中 10」のような1行の見本を書くと、AIが入力欄の形を推測しなくて済みます。入力の上限や形式（数字のみ、必須など）を決めておくと、HTMLの標準機能で一部をチェックできます。MDNのフォーム検証の解説では、required、min／max、maxlength、type などの属性で入力条件を指定できると説明されています。つまり「持ち時間は1〜60の数字、必須」と書けば、ブラウザ側の入力チェックを指定する指示になります。サーバーへデータを送る場合は、ブラウザ側の検証だけでは安全性を確保できず、サーバー側でも検証が必要です。

出力は、1件分の完成見本を書くのが一番確実です。表なのか、チャットに貼れる文章なのかで、作るものが変わります。

対象外は、仕様書の中で最も効果が出やすい欄です。次の節で詳しく説明します。

「やらないこと」を決める判断表

AIは親切に機能を足しがちです。足された機能は、読んで確認する量を増やし、不具合の入る場所も増やします。次の表で、初回に入れるかを判断してみてください。

• ログイン・会員登録、初回に入れる？：入れない、理由の考え方：自分用なら不要。認証は初学者が確認しにくい
• データの保存、初回に入れる？：必要なら最小限、理由の考え方：ブラウザ内保存でよいか、保存しないかを先に決める
• 他の人との共有URL、初回に入れる？：入れない、理由の考え方：サーバー側の仕組みが必要になりやすい
• 入力のエラー表示、初回に入れる？：入れる、理由の考え方：使えるかどうかに直結する
• 見た目の凝った装飾、初回に入れる？：後回し、理由の考え方：動作確認のあとで依頼する
• 複数言語対応、初回に入れる？：入れない、理由の考え方：使う人が決まっているなら不要

保存については一点だけ注意があります。ブラウザに保存できる localStorage は手軽ですが、MDNのWeb Storage APIの解説では、プライベートブラウズでは localStorage が sessionStorage のように扱われ、ブラウザやタブを閉じると保存データが削除されると説明されています。保存が必要なら、どのデータをどの範囲で保存するかを仕様に書いておきましょう。

また、入力チェックをブラウザ側だけで行う場合、MDNは、クライアント側の検証は使いやすさのための仕組みで、安全性の確保にはならない（サーバー側の検証が別に必要）としています。ブラウザだけで完結する自分用ツールでは大きな問題になりにくいものの、「不特定多数に公開する」「サーバーにデータを送る」ことを仕様に入れた時点で、難易度が上がることは知っておいてください。初回は対象外にするのが現実的です。

記入例：登壇タイムテーブル作成ツール（説明用の例）

以下は説明用に作った例です。

【ツール名】登壇タイムテーブルメーカー
【目的】勉強会の主催者が、登壇者ごとの開始・終了時刻を手計算せずに出す
【使う人】自分だけ。パソコンのブラウザで使う
【入力】
 - 開始時刻：時刻、必須、例 19:00
 - 登壇者リスト：1行に「名前 分数」、必須、例 田中 10
 - 入れ替え時間：数字（分）、任意、初期値2、0〜10
【出力】
 - 表（順番／名前／開始／終了）
 - 出力例：1 | 田中 | 19:00 | 19:10
 - 「チャット用にコピー」ボタンで同じ内容を文章化
【うまくいったと言える状態】
 - 3人分の例を入れて、手計算の結果と一致する
 - 分数が空欄や文字のときにエラー文が出る
 - 日をまたぐ場合は扱わない旨が表示される
【対象外】
 - ログイン、保存、共有URL
 - 日をまたぐ時間割
 - 見た目の装飾（動作確認後に別途依頼）
【制約】HTMLファイル1つで動く。外部サービスは使わない

「うまくいったと言える状態」は、そのまま自分の確認手順になります。AIが作ったものを動かしたとき、この3項目を順に試せば、合否が判断できます。

AIに渡す依頼文と、返ってきたあとの確認

仕様書ができたら、次の形で渡します。

以下の仕様書どおりにWebツールを作ってください。

- 仕様書にないことは、勝手に追加しないでください。
- 分からない点や、仕様が足りない点があれば、作る前に質問してください。
- 作ったあと、仕様書の「対象外」を守れているかを一覧で報告してください。
- 初心者なので、HTMLファイル1つにまとめ、使い方を3行で書いてください。

（ここに仕様書を貼る）

「作る前に質問してください」の一文は、仕様の穴を見つけさせるために入れています。質問が返ってきたら、答えを仕様書に書き足してから進めると、あとで依頼を読み返しやすくなります。

返ってきた結果は、次の順で自分が確認します。

1. 仕様書の「うまくいったと言える状態」を、1項目ずつ実際に試す
2. 入力例どおりに入れて、出力例と同じ形で出るかを見る
3. 対象外にした機能（ログイン欄、保存ボタンなど）が画面にないかを見る
4. 直したい点は、仕様書の該当行を書き換えて再依頼する

AIの説明文だけを読んで「動いているはず」と判断せず、必ず自分のブラウザで動かして確認してください。機密情報や実在の名簿は、確認の段階では入れず、架空の名前に置き換えて試すのが安全です。

書けないときの対処

入力や出力の例が書けない場合は、まだ作りたいものが固まっていないサインです。その場合は、仕様書を書く前に、次のようにAIへ質問させる方法があります。

作りたいツールの目的は「（1文）」です。
一枚仕様書（目的・使う人・入力・出力・対象外）を作るために、
私に5つ以内で質問してください。

質問に答えながら埋めていけば、テンプレートがそのまま完成します。仕様書の分量が増えすぎた場合は、対象外に回せる機能がないかを見直してください。最初の一枚は小さいほど、確認しやすくなります。