Claude Codeで受託Web制作を要件定義から引き渡しまで回す手順

監修者_SD以外

監修者プロフィール

森下浩志

日本最大級のAI情報プラットフォーム「romptn ai」編集長。著書に「0からはじめるStable Diffusion」「0からはじめるStable Diffusion モデル・拡張機能集編」など、AmazonベストセラーのAI関連書籍を多数執筆。AIにおける情報の非対称性を解消するための社内研修や出張講義も行う。

受託1案件を通す全体像と本記事の地図

受託のWeb制作を回す流れは、大きく分けて4つの段で進みます。要件定義 → 雛形生成 → デプロイ → 引き渡しの順で、本記事はこの4段をそのまま地図として使います。

この地図で一番伝えたいのは、各段に「Claude Code に任せていい部分」と「人が担保する部分」の線が引けることです。手を止めてしまう不安の多くは、操作の難しさではなく、この線引きが見えていないことから来ます。

4つの段は、それぞれ次のような役割を持ちます。

本記事の射程は、副業層が受けやすいLP・コーポレートサイトに絞ります。ECサイトや込み入ったWebアプリは同じ考え方を応用できる場面もありますが、判断材料が変わるため本記事では深追いしません。

まずは各段の土台になる、Claude Code の基本的な進め方から押さえていきます。

Claude Codeで作る基本ループとPlan Mode

工程の地図を描く前に、まず Claude Code で Web サイトを作るときの一番小さな単位を押さえておきましょう。受託のどの段でも、結局この小さなループを回し続けることになります。

基本は 「要件を伝える → 生成させる → 自分で確認して直しを指示する」 の反復です。一発で完成させる道具ではなく、こちらの指示と確認を挟みながら少しずつ仕上げていく、対話型の作り方だと考えると感覚がつかみやすいです。

この「確認して直しを指示する」部分が受託では特に大事になります。生成された見た目や文言をクライアントの要望と照らし合わせて、ずれていれば言葉で修正を伝える。ここを人が握っているからこそ、AI に作らせても成果物の責任を持てる形になります。

もう一つ覚えておきたいのが Plan Mode です。これは、いきなりコードを書かせる前に「何を・どういう構成で作るか」という計画段階を先に詰めるための使い方です。

作り始めてから「思っていたのと違う」と気づくと、手戻りが大きくなります。先に計画として方針をすり合わせておけば、認識のずれを早い段階で潰せます。次の章で扱う要件定義とも、この計画を詰める動きはそのまま地続きになります。

要件定義で任せる線と人が担保する線

ここでは案件の入口、要件定義のフェーズを扱います。叩き台づくりは Claude Code に任せ、クライアントとの合意は人が担保する、という線を最初に引いておくと迷いません。

ヒアリングで集めた断片的な要望を、ページ構成や機能の一覧として整理し直す作業は Claude Code が得意です。「相談された内容をサイト要件の草案にまとめて」と依頼すれば、抜けや矛盾を含んだ叩き台が短時間で出てきます。

この草案は、あくまでたたき台として扱います。優先順位の判断や、予算・納期に対してどこまで含めるかというスコープの線引きは、案件の文脈を知る人が決める領域です。

要件がある程度固まったら、実装前に計画を詰める Plan Mode を要件合意のフェーズに当てると効きます。いきなりコードを書かせる前に、何をどう作るかの計画を出させて読み合わせる使い方です。

この段で計画と要件の齟齬を潰しておくと、後工程の作り直しが減ります。「実装はまだしないで、作る計画だけ先に出して」と区切ってから内容を確認する進め方が、合意形成のフェーズと相性よくはたらきます。

任せる線と担保する線を整理すると、次の通りです。

この線引きが決まれば、要件を入力品質として次の雛形生成へ渡せます。次の章では、その雛形生成に何を揃えて渡すかを見ていきます。

雛形生成に渡す前提情報の揃え方

雛形生成の精度は、Claude Code に渡す前提情報の整い方でほぼ決まります。要件を伝えてから生成させる流れなので、渡す材料が曖昧だと出力も曖昧になり、修正の往復が増えてしまいます。

LP やコーポレートサイトの雛形を頼むとき、最低限そろえておきたい材料は次の3つです。

この3つのうち、ここでは入口になりやすい「ページ構成の渡し方」と「デザイン雛形の繋ぎ方」を、続く2つの章で順に見ていきます。スタックの選び方は引き渡し方式とも関わるため、後ほどの『デプロイと引き渡しの2ルートを選ぶ』の章であわせて扱います。

材料がそろっていれば、前の章で固めた要件をそのまま雛形生成の入力に流し込めます。逆にここを飛ばすと、生成された雛形がクライアントの要望とずれ、要件定義からやり直しになりやすい点に注意してください。

① ページ構成を要件として渡す

雛形を作らせる前に、まずどんなブロックがどの順で並ぶサイトなのかを、文章ではなくリストの形で渡します。コーポレートサイトであれば、ヘッダー・ファーストビュー・サービス紹介・実績・問い合わせ・フッターといった構成を、上から順に1行ずつ並べるだけで十分です。

このやり方は机上の理屈ではありません。デザインカンプから Claude Code だけでサイトを実装した制作会社の事例でも、コーポレートサイトは「ページ構成を要件として渡して作る」のが基本の進め方とされています。受け取った構成リストをそのまま指示に落とせるので、副業で1案件を回す規模でも同じ形を真似できる、というのが執筆時点での想定です。

渡すときは、各ブロックに「何を載せるか」を一言ずつ添えると、意図どおりの雛形になりやすくなります。たとえば次のような骨組みで書くと、Claude Code 側が迷わずに雛形へ起こせます。

コーポレートサイトの雛形を作ってください。
ページは縦1枚で、上から次の順に並べます。

1. ヘッダー: サイト名(社名表示)+ ナビ(サービス / 実績 / 問い合わせ)
2. ファーストビュー: キャッチコピー + 申し込みボタン
3. サービス紹介: 3項目をカードで横並び
4. 実績: 取引先名または事例を3〜6件
5. 問い合わせ: 名前 / メール / 内容の入力フォーム
6. フッター: 会社情報 + コピーライト

まずはこの構成で骨組みだけ作ってください。

ポイントは、最初から細部まで盛り込まず「骨組みだけ」と区切ることです。構成が合っているかを先に確認してから、各ブロックの中身を順に詰めていくと、後戻りが減ります。ここで渡す構成リストの質が、このあとの仕上がりをそのまま左右します。

② Claude Designでデザイン雛形を繋ぐ

ページ構成を言葉で固めたら、次は見た目の雛形を用意する段です。少し前まで、この段はデザインツールで誰かが画面を起こすか、自分で当たりを付けてからコードを書き始めるのが普通でした。

ここに新しい選択肢として加わったのが Claude Design です。執筆時点では、チャットで「こういうLP・コーポレートサイトにしたい」と伝えると、その場で画面の雛形を起こしてくれるものとして案内されています。デザイン専用のソフトを別に立ち上げなくても、文章のやりとりだけで形が見えてくるのが特徴です。

受託で効いてくるのは、そこから先の Handoff to Claude Code という渡し口です。起こした雛形をそのまま Claude Code 側の実装に引き継げるため、「デザインの雛形を作る人」と「コードを書く人」の間で起きがちな手戻りや認識ずれを、ひとつの流れの中で吸収しやすくなります。

この渡し方が向くのは、本記事が射程にしている LP・コーポレートサイトのような、ページ構成がはっきりしている案件です。前の章で整理したヘッダーやFV、サービス、問い合わせといった枠組みを言葉で渡しておくほど、雛形の方向もぶれにくくなります。

デプロイと引き渡しの2ルートを選ぶ

雛形が形になったら、次はサイトを公開し、クライアントへ渡す段です。ここで多くの人が「正解の引き渡し方は1つ」と思い込みがちですが、受託では大きく2つのルートがあり、どちらが優れているという話ではありません。

分かれ目は、公開後の更新を誰が担うかです。制作側が責任を持って面倒を見るのか、クライアント本人が手元で直していくのか。ここを案件ごとに選ぶと、引き渡し後のトラブルがぐっと減ります。

判断のコツは、契約時に「公開後、誰が・どのくらいの頻度で中身を変えるか」を握っておくことです。ここが曖昧なまま納品すると、想定外の更新依頼や保守の押し付け合いに繋がります。

それぞれの繋ぎ方と引き渡し方式は、続く2つの章で具体的に見ていきます。

① 静的ホスティングへ繋ぐ

出来上がった LP やコーポレートサイトを、Vercel や Netlify といった静的ホスティングに載せて公開するルートです。クライアントには運用を触らせず、制作側でデプロイまで完結させたいときの基本形になります。

この構成では、Claude Code のチャットからデプロイ用のコマンドを実行したり、ホスティングサービスを MCP 連携で繋いだりして、ビルドから公開までを同じ作業画面で回せます。ターミナルとブラウザを行き来する手間が減り、修正してすぐ再公開という反復が速くなります。

引き渡し前にそろえておきたい確認は次のとおりです。

このルートは制作側で公開まで握れる反面、公開後の文面差し替えなどはそのつど自分が動く前提になります。クライアント自身に更新を任せたい案件は、次の『クライアントが更新できる構成』の章で扱う渡し方を選びます。

② クライアントが更新できる構成

こちらは、引き渡した後にクライアント自身がお知らせやサービス内容を書き換えたい案件に向いたルートです。前のルートが運用を触らせず制作側で完結させるのに対し、ここでは「どこまでを本人に任せ、どこを自分が担保するか」を構成の段階で決めておくのが肝になります。

更新できる形は、クライアントの操作に慣れている度合いと、更新したい範囲の広さで選び分けます。判断の目安を整理しておきます。

上の管理画面付きほど本人ができることは広がりますが、その分レイアウトを崩すリスクも増えます。逆に手順書方式は安全な代わりに、毎回クライアントが文字を探して書き換える手間がかかります。LP やコーポレートサイトなら、更新したいのは連絡先やお知らせなど一部であることが多いので、まず「どこを触りたいか」をヒアリングで絞ってから方式を決めると過不足が出ません。

Claude Code には、この方式に合わせた構成を作らせます。たとえば「お知らせの本文を分離して、ここだけ編集すれば反映される形にして」と指示すれば、編集箇所を1つにまとめた構造を組んでくれます。

どこまで本人に開放するかは、引き渡し後の修正依頼の量にも直結します。広く開放するほど自由度は上がりますが、崩れた時の問い合わせも増えます。最初は触れる範囲を狭く渡し、慣れてきたら広げる前提で合意しておくと、引き渡し後のトラブルを抑えられます。

有償納品の不安に品質保証層を挟む

ここは「AI に作らせたものを有償で渡して、自分が責任を持てるのか」という、この受託で一番重い不安に向き合う段です。

答えは、生成された成果物をそのまま渡さないことです。Claude Code が作ったものと、あなたが引き渡すものの間に、検収のためのチェック層を1枚はさむと決めてしまえば、不安はかなり具体的な作業に変わります。

まず、LP・コーポレートサイトで最低限はずせないチェック項目を決めておきます。これを毎回同じ順番で通すだけでも、納品の足元は安定します。

このチェック自体を Claude Code に手伝わせることもできます。「上の観点でこのコードを点検して、直すべき箇所を挙げて」と依頼すれば、レビューや簡単なテストの下書きを任せられます。

納品物の合否ラインも、作る前にクライアントと合わせておくと安全です。「どのページが、どの端末で、どう動けば完成とするか」を受け入れ基準として先に言葉にしておけば、引き渡し後の「これは直してくれるんですか」という認識のズレを大きく減らせます。

商用で納品してよいか、生成コードの著作権やライセンスの扱いについては、断定できる確かな一次情報がそろっていないため、ここでは各自で利用条件や契約条件を必ず確認する前提として扱います。判断材料が必要な論点なので、後ほどの『本番運用を支えるツールと注意点』の章でも、要確認の枠として改めて触れます。

本番運用を支えるツールと注意点

ここまでの工程を、毎回ゼロから手で回す必要はありません。受託で繰り返し使う土台を Claude Code 側に持たせておくと、案件が増えるほど楽になります。

その土台になるのが、役割の違う3つの仕組みです。まず全体像を一目で掴んでから、それぞれの使い分けに進みます。

この3層を併用するのが、執筆時点での本番運用の標準的な組み立て方です。Skills で自分の受託フローそのものをテンプレ化し、MCP で繋ぎ込みを自動化し、Subagents で納品前の確認層を分ける、という割り当てになります。

注意したいのは、呼び出し方やコマンド名、つなげられる外部サービスの範囲は更新が早い領域だという点です。具体的な書式や利用できる接続先は固定で覚えず、着手のたびに公式ドキュメントで現時点の表記を確認してください。本記事でも個別のコマンド名までは踏み込まず、役割の地図だけを示しています。

もう一つ、受託ならではの確認事項があります。それが、AI が生成したコードを有償で納品してよいかという著作権・ライセンス・利用条件まわりです。

ここは「大丈夫」とも「ダメ」とも言い切れる段階ではありません。業務での利用や納品の可否は、Anthropic の利用条件と、あなたとクライアントの間の契約を必ず各自で確認してください。本記事を含む第三者の解説を、確定した法的判断の代わりにはしないでください。

判断材料が曖昧なまま進めないために、案件の見積り段階で「成果物の権利と責任の所在」を発注側とすり合わせ、書面に残しておくと安全です。これは Claude Code の機能というより、受託として当たり前に踏むべき手順だと捉えてください。

よくある質問

受託Web制作を回す手順のまとめ

ここまで、LP・コーポレートサイトの受託1案件を、要件定義から引き渡しまで通す流れを追ってきました。最後に全体を1枚に振り返り、あなたの案件にそのまま当てはめられる形に畳んでおきます。

軸はずっと同じで、各段で「任せていい部分」と「人が担保する部分」を分けて回すことでした。要点を工程順に並べると次のようになります。

この線引きが腹落ちすれば、受託特有の「有償で他人に納品し、引き渡し後も責任を持てるか」という怖さは、工程ごとの具体的な担保に分解できます。操作の習熟よりも、まずこの分担を自分の言葉で言える状態を目指してください。

まずは小さく1件、見積りから引き渡しまでをこの地図に沿って通してみるのがおすすめです。最初の案件で「どこを任せ、どこで自分が止めるか」を体に入れると、2件目以降の見積りと進行が一気に楽になります。

なお、AI に生成させたコードを有償で納品してよいか、著作権やライセンスの扱いについては、本記事では確定した事実として断定していません。実際の案件では、利用しているツールの利用条件や案件の契約条件を必ず各自で確認したうえで進めてください。

ここで描いた地図は、ECサイトや Web アプリの受託にも応用の余地はあります。ただし扱う機能やデータが増えるほど担保すべき範囲も広がるため、本記事の射程はあくまで LP・コーポレートサイトに置いています。まずは射程の合う案件で「任せる線と人が担保する線」を一度引いてみることが、次の一歩になります。