Web制作の単価を上げる方法｜スコープと責任範囲が価格を決める

受託のWeb制作を続けながら「もっと高く受けられないか」と感じている人は多いでしょう。単価の問題は、技術の熟練度だけで決まるわけではありません。この記事では、単価が上がらない構造的な要因と、何を変えると価格交渉の余地が生まれるのかを整理します。

単価が上がらない構造的な原因

Web制作の市場では、「デザイン＋コーディング＋WordPressカスタマイズ」というセットはすでにコモディティ化しています。同じ成果物を提供できる制作者が多数存在する領域では、価格競争が起きやすくなります。

これは技術力の問題というより、提供物の希少性の問題です。同じ機能・同じ範囲を提供できる制作者が市場に多ければ、クライアントは選択肢を複数持ちます。選択肢が多い状況では、価格が選択基準の上位に来やすくなります。

逆に言えば、「この制作者に頼まないと実現できない、あるいは他の人に頼むと大きなコストがかかる」という状況を作れれば、価格交渉の余地が生まれる可能性があります。

技術スコープが単価に影響する理由

単価に影響する要素として、技術スコープの広さ（何を自分で実装できるか）は重要な変数です。

決済フローの実装

ECサイトにカード決済を組み込む場合、ShopifyやStripe Elementsを使えば対応できる制作者は多くいます。しかし、PAY.JPのようなAPIを直接叩き、EMV 3Dセキュアの認証フロー（charge作成→認証ページへのリダイレクト→コールバックで確定、失敗時の在庫返戻）まで実装できる制作者は限られます。

クライアントが「既製サービスには乗らず、自社のNext.jsアプリに組み込みたい」という要件を持ったとき、この差がそのまま選択肢の差になります（Next.js App Routerで個人ECサイトを作る全手順も参考になります）。

セキュリティ実装

WordPressのセキュリティプラグインを導入するレベルと、自前でWAF層を実装するレベルは異なります。

後者の例として、Next.jsのミドルウェアにIP自動BAN・レート制限（毎分300リクエスト）・ログイン5回失敗で15分ロック・ファイルアップロード時のマジックバイト検証を実装するケースがあります。さらにClamAVをサーバーに導入してcronで毎朝4:30にスキャンを実行するような構成は、対応できる制作者が少ない領域です。

こうした実装は、セキュリティ要件の厳しいクライアント（EC・医療・金融系）から見ると、「他の制作者では対応できない」選択肢になりえます。

インフラ・運用の自己完結

Cloudflare Tunnelとsystemdを使って自宅Linuxサーバーを本番運用するような構成（ポート開放なし、トンネル経由で外部公開）は、インフラの知識がなければ対応できません。「制作だけでなく、本番環境の構築・維持まで引き受けられる」という幅が、発注側の依頼先の分散を防ぐ可能性があります。

希少性が高い領域ほど「代わりを見つけにくい」状況が生まれます。これが価格交渉の余地に繋がる可能性があります。

「一回作って終わり」から「継続的な関与」へ

単価の問題は、プロジェクト単価だけでなく、月額・年額での継続的な関与を構造に組み込めるかどうかとも関係しています。

制作完了で関係が終わると、次の案件を都度取りに行く必要があります。対して、保守・運用・改善の継続契約があれば、稼働が安定します。

Webアプリに近い実装をしているほど、「誰かが継続して面倒を見る必要がある」という状態を自然に作れます。既製品サービスと違い、カスタム実装のシステムは作った人が一番早く対応できます。技術スコープの広さが「継続依頼の理由」にもなります。

AIツールと単価の関係を冷静に見る

「AI活用で生産性を上げれば単価が上がる」という主張を目にします。しかし、これは条件付きの話です。

AI活用が差別化になるかどうかは、クライアントがその価値を認識できるかによる部分が大きいと考えられます。Figma→STUDIOのコーディングレス制作やAI画像生成を使っていても、成果物が「コーポレートサイト」として見える限り、クライアントには区別がつきにくくなります。

価格に繋がりやすいのは、AI活用がシステムや自動化として可視化されるケースです。たとえば、Claude Code CLIをPythonのsubprocessから呼び出して記事生成をバッチ自動化するような仕組みを「納品物」として組み込む場合、クライアントは「これが欲しかった」と具体的に認識できます。

AI副業で稼げない理由でも整理されているように、「AIが使える」自体は差別化の根拠として薄まりつつあります。使い方の具体性と、クライアントに何が変わるかの説明が問われています。

単価を動かすための実際的な手順

1. 自分のスコープを棚卸しする

HTMLコーディングからインフラ構築まで、現時点で引き受けられる範囲を書き出します。その中で「他の制作者が対応しにくい領域」を特定します。

2. 希少性が必要なクライアント層を探す

セキュリティ要件の強いECサイト、カスタム決済フローが必要なサービス、Webアプリに近いシステム——これらはWordPress制作と違う文脈で要件が出てきます。クラウドソーシングより、業界コミュニティや紹介経由でアプローチしやすい領域です。

3. 保守・継続関与の提案を案件設計に組み込む

制作完了後の「誰がこれを維持するか」問題をあらかじめ提案に含めます。月額での保守対応を含む構造のほうが、クライアントにとって予算計画しやすい面があります。

4. 価格を変える前に、提案書のスコープ記述を変える

価格だけ上げようとしてもスコープが同じでは根拠がありません。セキュリティ実装の内容、使用する技術スタック、運用体制を提案書レベルで明示すると、価格の根拠が伝わりやすくなります。

まとめ

Web制作の単価が上がるかどうかは、技術力の絶対値より「その技術が市場でどれだけ希少か」と「引き受ける責任の範囲の広さ」によって変わる部分が大きいと考えられます。

「作れます」が多数の制作者に当てはまる状況では、価格競争から外れにくくなります。決済フローの実装、セキュリティ構成、インフラ運用など、対応できる制作者が限られる領域にスコープを広げることが、価格交渉の余地を生む可能性があります。

次に取る行動として、自分が対応できる技術の中で「他の制作者が断るかもしれないもの」を一つ特定し、次の提案書にその内容を具体的に明記することを試してみてください。提案の言語化が変わると、受注する案件の属性も変わる可能性があります。