Claude Codeでサイトマップと要件定義書を下書きする──議事録の次の工程、ページ構成と要件の構造化、抜け漏れの検査、人が決める線

この記事は、Claude Codeを使って、Webサイトのサイトマップと要件定義書を下書きし、抜け漏れを検査する手順を扱います。

打ち合わせの録音と議事録づくりは、別の記事で扱いました。この記事はその次、たまった議事録と資料から「作るものの一覧」を組み立てる工程の話です。

▶ Web制作の要件定義をAIの議事録で速くする──「言った言わない」を減らす録音の同意の取り方、当日中の確認の手順、版を重ねる要件書の型

議事録は5回分あるのに、作るものの一覧がない

打ち合わせの議事録は、きちんと残っている。
けれど、ページの一覧も、フォームの項目も、5つのファイルに散らばっていて、どれが最新の決定なのか誰にもわからない。

半日かけて表にまとめても、公開の前に「採用ページのエントリーフォームは？」と言われて、一覧から漏れていたことに気づく。

散らばった決定を、一つの構造にまとめ、抜けを探す作業は、人よりAIに向いた部分があります。

AIでの要件定義の下書きとは、議事録と資料からページ構成と要件を構造化し、出典をつけて一覧にし、抜け漏れの候補を洗い出させる作業であり、決めるのは人である

黒字化の外科医です。サイトマップと要件定義書の下書きを、Claude Codeに任せる範囲と人が決める範囲に分けて解剖します。

この使い方を勧める理由は、三つあります。

第一に、Claude Codeは、コード以外のフォルダでも動くから。
公式ドキュメントには、メモや文書のフォルダ、Markdownのファイル群の中で動かし、コードと同じように検索・編集・整理ができると書かれています。議事録のフォルダをそのまま作業場にできます。

第二に、構造化と照合は、読む量が多いほど人が疲れる作業だから。
議事録とページ一覧の突き合わせは、AIに下書きさせ、人が確かめるほうが速く、漏れも減ります。

第三に、「決まっていないこと」を一覧にできるから。
結論のない話題が、次の打ち合わせで聞くことになります。

Claude Codeで使う機能、公式で確認できたこと

2026年10月29日に、公式ドキュメント（code.claude.com/docs の Common workflows、Skills）で確認した内容です。

・コード以外のフォルダ（メモ、文書、Markdownの集まり）でも使える
・@ファイル名 で、ファイルやフォルダを会話に含められる
・プランモード：ファイルを読んで計画を示し、承認するまで編集しない
　（Shift+Tab で切り替え、または claude --permission-mode plan で起動）
・サブエージェント：別の文脈でファイルを読み、要約だけを返させられる
・Skills：手順を .claude/skills/〔名前〕/SKILL.md に書いて、チームで共有できる

作業フォルダの形

案件名_要件/
├── CLAUDE.md          ← この案件の決まり（下に例）
├── 01_議事録/          ← 確認済みの議事録だけを置く（日付つきのファイル名）
├── 02_資料/            ← お客様の資料、現行サイトのページ一覧、画面のスクリーンショット
└── 03_出力/            ← サイトマップ、要件一覧、未決事項の一覧

CLAUDE.md には、この案件で守らせることを短く書きます。

# この案件の決まり
・01_議事録 と 02_資料 にない事実を足さない。推測は「推測」と明記する
・すべての要件に、出典（ファイル名と該当の見出し）をつける
・議事録同士で食い違う場合は、日付の新しいほうを採り、食い違いとして一覧に残す
・費用、工数、優先度は決めない（人が決める）
・03_出力 以外のファイルは編集しない

議事録に個人情報や秘密の情報がある場合は、AIに読ませてよいかを先に確かめます。

手順：4回に分けて頼む

一度に全部を頼まず、プランモードで始めて、段階ごとに確かめます。

1回目（プランモード）：読ませて、作業の計画だけを出させる
2回目：サイトマップの下書き（階層つきの一覧、各ページの目的、出典）
3回目：要件一覧の下書き（業務・機能・機能以外の要件に分け、ID・出典・状態をつける）
4回目：抜け漏れの検査（下の検査表で照合し、候補と質問を出させる）

要件の分け方は、国の調達の手引きの考え方を借りると整理しやすくなります。デジタル庁「デジタル・ガバメント推進標準ガイドライン解説書」（DS-110、2026年6月12日版、2026年10月29日確認）では、業務要件・機能要件・非機能要件に分け、業務要件は「システムの機能を定義するものではない」ことに留意するとされています。

今すぐ試せる：要件一覧と抜け漏れ検査のプロンプト

@01_議事録 と @02_資料 を読み、03_出力/要件一覧.md を作ってください。

【書き方】
・要件を「業務（誰が何のために何をするか）」「機能（画面・フォーム・管理画面）」
　「機能以外（表示速度、対応ブラウザ、セキュリティ、更新の体制）」に分ける
・各要件に、ID（例：F-01）、内容、出典、状態（決定／未決／食い違い）をつける
・推測で足した要件は作らない。必要そうだが出典のないものは「確認したい点」に分ける

【検査】
・サイトマップの各ページに、対応する要件があるか
・各フォームに、送信先・自動返信・保存の有無・迷惑投稿対策が書かれているか
・〔お客様が触れていないが、この種のサイトでよく抜ける項目〕が出てきていない場合、
　「確認したい点」に質問の形で挙げる

最後に、次の打ち合わせで聞く質問を、優先順に10個以内で出してください。

要件下書き工場：抜け漏れの検査表

AIに照合させ、最後は人が目で確かめる表です。

□ ページ：サイトマップの全ページに「目的」と「更新する人」があるか
□ フォーム：項目、必須、送信先、自動返信、保存、迷惑投稿対策
□ 管理画面：お客様が自分で更新する範囲と、権限の分け方
□ 外部との連携：予約、決済、地図、分析タグ、広告タグ
□ 既存サイトから：残すページ、消すページ、URLを変えるページと転送
□ 機能以外：対応する端末とブラウザ、表示速度の目安、アクセシビリティの方針
□ 素材：原稿、写真、ロゴを誰がいつ用意するか
□ 運用：公開後の更新の頻度、保守の範囲
□ 未決事項：決める人と、決める期限が書かれているか

構造的なリスク

逆説を指摘しておきます。

AIが作った要件一覧は、見た目が整っているぶん、「全部そろった」と錯覚させます。
けれど、AIが拾えるのは議事録に書かれたことだけです。

だから、出典のない要件を足させないこと、そして「確認したい点」を次の打ち合わせで必ずお客様に聞くことを、手順に入れてください。決定にするのはお客様との確認であって、AIの下書きではありません。

よくあるQ&A

Q. ディレクターでもClaude Codeを使えるか？

コードを書かない使い方なので、使えます。ディレクターが使う範囲の考え方は、こちらで扱っています。

▶ Claude Codeをディレクターが使う範囲は「読む・聞く・小さく直す」の3段で決める──修正の影響範囲の下調べ、エンジニアに渡す前の確認、触らない線

Q. 要件一覧から、そのまま見積もりを出してよいか？

要件のIDを工程にひも付けて、根拠の表にするのが次の工程です。

▶ 見積の根拠をAIで可視化する、Web制作の値引き交渉を範囲の話に変える──工程・前提・除外を要件とひも付ける根拠表、AIに照合させる3つの検査、計算例

最後に

サイトマップと要件定義書の下書きは、AIに「構造化」と「照合」を任せ、人が「確認」と「決定」を持つと、速さと確かさが両立します。

出典のない要件を作らせず、未決事項を次の打ち合わせに返した会社だけが、公開直前の「それも入っていると思っていた」を減らせるのです。

要件定義書の目次、記入例、抜け漏れの検査表、Claude Code用の雛形は、キットにまとめました。

▶ RFP・要件定義テンプレキット、制作会社がお客様に渡して一緒に埋める一式──RFPの雛形、評価表、要件定義書の目次と記入例、抜け漏れ検査表、見積根拠表、支援の見積書、Claude Code用の雛形

これまでの記事は、メンバーシップ「黒字化オペ室」でまとめて読めます。月額1,980円、記事2本分の金額です。詳しくはプロフィールから。

#Web制作会社 #ClaudeCode #要件定義 #サイトマップ #ディレクション #AI活用 #上流工程 #生成AI #制作会社経営 #中小企業