WordPress構築の見積もりの作り方｜あとで足せない項目

2026年2月10日

朝比奈蒼

この記事のポイント

✓WordPress構築見積もりの出し方を
✓そして着手後には追加できない項目まで
✓受注側の実務として整理します

WordPress構築見積もりの出し方で失敗する原因は、金額の付け方ではありません。結論から書くと、原因は項目の立て方です。着手してから膨らむ作業は、ほぼ例外なく「見積書に項目として存在しなかった作業」です。項目がなければ、それは追加ではなく漏れとして扱われ、無償で引き受けることになります。この記事では、見積書に立てるべき項目、前提条件の書き方、そして着手後には追加できなくなる項目を、受注側の実務手順として整理します。

見積もりが後から崩れる仕組み

WordPressは世界で最も使われているCMSです。その普及度が、見積もりの難しさに直結しています。

WordPressの良い点はたくさんありますが、一番のメリットは「世界中で多くの利用者とそれをサポートする開発者たちがいる」という点かもしれません。実際、IT関連の調査を実施する『W3Techs』によれば、全世界のWebサイトの43.2%にWordPressが採用されているとのこと。出典: giginc.co.jp

これだけ広く使われていると、発注側は「WordPressで作る」という言葉から、まったく違うものを想像します。ブログを1つ立ち上げることを想像している人もいれば、会員機能と多言語対応を含むサイトを想像している人もいる。同じ言葉で違うものを指しているのに、見積書の項目が「WordPress構築一式」だと、そのずれが表に出ません。

「一式」は必ず膨らむ

見積書で最も危険な表記が「一式」です。一式は、書いた側にとっては想定した範囲を指しますが、読んだ側にとっては「必要なものが全部入っている」という意味になります。この解釈の差は、着手後に必ず表面化します。

正直なところ、一式表記は受注のためのテクニックとして使われることがあります。項目を細かく書くと金額の内訳が見えて比較されやすいので、まとめて出す。しかし比較を避けた見積もりは、範囲の合意も避けています。避けた合意は、後で必ず請求されます。

発注側は見積もりを比較のために読んでいる

発注側は複数の見積もりを並べます。並べたときに見ているのは総額だけではありません。何が含まれているかの一覧です。項目が細かく書かれた見積書は、総額が高くても選ばれることがあります。理由は単純で、判断できるからです。

判断できない見積書は、総額でしか比較されません。総額でしか比較されない土俵に立つと、勝つ方法が値下げしかなくなります。項目を細かく書くことは、値下げ以外の勝ち方を作る作業でもあります。

見積もりは相手の社内で回覧される

窓口担当者は、受け取った見積書をそのまま上司や決裁者に回します。回覧される先には、Web制作の知識がない人がいます。その人が読んで意味が分かる書き方になっているかどうかで、決裁の速度が変わります。

専門用語を並べた見積書は、担当者が説明を求められて止まります。項目名の横に一行の説明を入れておくだけで、この停滞は消えます。見積書は金額の連絡ではなく、社内を通すための資料です。

見積もりを作る前に確定させる情報

情報が足りない状態で出した見積もりは、後から必ず修正が必要になります。修正した見積もりは、値上げとして受け取られます。だから、出す前に確定させます。

何のために作るのか

サイトの目的が、必要な機能を決めます。問い合わせを増やしたいのか、採用の応募を集めたいのか、既存顧客への情報提供なのか、社内で更新できるようにしたいのか。目的が違えば、同じページ数でも作るものが変わります。

目的が言語化されていない場合、それを引き出すこと自体が工程です。この工程を見積書に項目として立てるかどうかで、後の展開が変わります。立てなければ、無償の打ち合わせとして何度も繰り返されます。

ページ数ではなく、機能で数える

「トップと下層5ページ」という数え方は、見積もりの根拠になりません。同じ1ページでも、テキストと画像を並べるだけのページと、条件で絞り込める一覧ページでは、工数が違います。

数えるのは機能です。固定ページのテンプレート数、投稿の種類、一覧の絞り込み条件、フォームの項目数と分岐、外部サービスとの連携、多言語の有無。この単位で数えると、後から「ページが1つ増えました」と言われたときに、それがテンプレートの追加なのか、既存テンプレートへの流し込みなのかを判断できます。

既存サイトの中身を確認する

リニューアルなら、既存サイトの状態が工数を大きく左右します。現在のCMSは何か、記事数はどのくらいか、URLの構造を維持するのか、独自に作り込まれた機能があるか、サーバーとドメインの管理権限を誰が持っているか。

特に管理権限は、着手できるかどうかを決めます。前の制作会社が契約者のままで連絡が取れない、というケースは実際にあります。この整理は制作者の仕事ではありませんが、誰がやるかを決めずに見積もると、なぜか制作者が代行することになります。

素材の準備状況を聞く

原稿と写真を誰が用意するかで、工程の長さが変わります。相手が用意する前提なら、いつまでに、どの形式で出すかまで確認します。用意できないなら、制作を範囲に含めるか、範囲外として明記するかを決めます。

ここを曖昧にした見積もりは、後で必ず揉めます。相手は「サイトを作ってもらう」という認識なので、中身も含まれていると考えるのが自然です。含まれないなら、含まれないと書くしかありません。

公開後に誰が更新するか

社内の担当者が更新するなら、管理画面の調整とマニュアルが必要になります。これは見た目に出ない作業なので、項目として立てないと存在しないことになります。存在しない作業に対して工数を使うと、そのぶんが丸ごと持ち出しです。

更新する人のスキルも聞いておきます。日常的にパソコンで文書を作っている人と、スマートフォンしか使わない人では、用意すべき管理画面が違います。前者なら標準に近い状態で足りますが、後者なら入力項目を絞り、選択式にし、崩れない構造にする必要があります。同じ「更新できるように」でも、工数は大きく変わります。

決裁の経路と確認者の人数

見積もりを誰が承認するのか、デザインを何人が確認するのかを聞きます。確認者が多いほど、修正の往復が増えます。往復の回数は工数に直結するので、人数を知らずに回数を設定すると外れます。

確認者が多い案件では、確認の進め方そのものを提案するのが有効です。個別に意見を集めるのではなく、一度に集まって決める形にする。この提案は相手の社内の話ですが、提案した側の工程を守ります。

見積書に立てる項目の分解

項目の粒度は、相手が判断できる細かさに合わせます。細かすぎると読まれないので、工程の区切りで分けるのが実務的です。

要件整理と設計

打ち合わせ、要件の整理、サイト構成の設計、ワイヤーフレームの作成。ここを項目として立てていない見積書が非常に多い。立てていないと、この工程は「見積もりを出すための準備」として無償になります。

要件整理を有償の工程として切り出すと、相手の本気度も測れます。ここに払う意思がある相手は、その後の工程でも判断が早い。

デザイン

テンプレートの種類ごとに数えます。トップページ、一覧ページ、詳細ページ、固定ページ。あわせて、確認と修正の回数をこの項目に書きます。回数を書かないデザイン項目は、終わりのない工程になります。

実装

テーマの実装、投稿タイプとカスタムフィールドの設計、フォームの実装、検索や絞り込みの実装、外部サービスとの連携。機能ごとに行を分けます。分けておくと、予算が合わなかったときに、どの機能を落とすかという議論ができます。一式で出していると、落とす議論ができず、全体の値引き交渉になります。

コンテンツの流し込み

既存記事の移行と、新規原稿の入力を分けて書きます。移行はデータの状態次第で工数が変わるので、件数の範囲と、範囲を超えた場合の扱いを前提条件に書いておきます。

テストと公開作業

表示確認、フォームの送信テスト、対応ブラウザと端末での確認、公開時のサーバー作業、公開後の初期確認。ここも項目にしないと、無限に続く微調整として扱われます。

環境の準備

テスト環境の構築、本番サーバーの初期設定、SSLの適用、バックアップの設定。作業としては短くても、確実に発生する工程です。項目に立てておかないと、準備に使った時間が見えません。

既存サイトが稼働している場合、本番に影響を与えずに作業する環境を用意する必要があります。この準備を省くと、作業中のサイトが公開状態で見えてしまう事故につながります。工数としては小さいので、削らずに残しておく価値があります。

納品物とマニュアル

何を納品するのかを書きます。管理画面のアカウント、操作マニュアル、設定情報の一覧、デザインデータの受け渡しの有無。デザインデータやソースコードの権利の扱いも、必要なら一行入れておきます。

着手後には足せない項目

ここが本題です。見積書に書き忘れると、後から追加請求が事実上できなくなる項目があります。理由は、相手が「当然含まれている」と考えるからです。

要件整理の工数

打ち合わせが増えても、それを後から請求するのは難しい。最初に回数の目安を書いておくのが唯一の防御です。「オンライン打ち合わせ3回まで含む」と書いておけば、4回目の扱いを話し合えます。書いていなければ、何回でも含まれます。

修正の回数

デザインと実装の修正を、無償で何回まで受けるか。これを後から制限するのは、実務上ほぼ不可能です。すでに何度も無償で応じた後で「次から有償です」と言うと、態度が変わったと受け取られます。

回数の設定は、相手を縛るためではありません。指示の質を上げるためです。回数に上限があると、相手は指摘をまとめて出すようになります。まとまった指示のほうが、結果的にいいものができます。

原稿と写真の制作

サイトに載せる文章と画像を誰が作るかは、最初に決めるしかありません。着手後に「原稿がないので書いてもらえますか」と言われた時点で、断りにくい空気ができています。範囲外と書いてあれば、別の見積もりとして出せます。書いていなければ、サービスとして期待されます。

既存データの移行と整形

記事の移行は、量だけでなく状態で工数が決まります。文字コードの混在、画像リンクの切れ、独自タグの混入。着手して初めて分かる要素が多いので、前提条件に「データの状態により追加工数が発生する場合がある」と書いておきます。

さらに実務的なのは、見積もり前に一度データを取り込んで様子を見ることです。取り込むまで、実際の汚れ具合は分かりません。ここに少し時間を使うと、後で発生する追加工数の大半を先に潰せます。

表示速度とスマホでの見え方の水準

「速く」「スマホでもきれいに」は、達成の基準がない要求です。基準がないと、相手が満足するまで続きます。目標値を書くか、対応する範囲を書くか、どちらかにします。書いていない性能要求は、後から無限に出てきます。

対応するブラウザと端末

どのブラウザのどのバージョンまで、どの画面幅まで対応するか。書いていないと、相手の環境で崩れた場合の修正が全部含まれます。古い環境の対応は工数が跳ね上がるので、範囲を明記する価値があります。

権限設計と管理画面の調整

社内で複数人が更新する場合、権限を分けたり、不要なメニューを隠したり、投稿の型を固定したりする作業が発生します。これは「使いやすくしておいてください」という一言で依頼されがちですが、実際は設計の作業です。

公開後の保守と更新

公開して終わりではありません。プラグインと本体の更新、不具合の対応、バックアップ。これらを含むのか含まないのかを書かないと、公開の数か月後に連絡が来て、無償の緊急対応になります。含めないなら、含めないと書く。含めるなら、期間を区切る。

放置された更新は脆弱性として残ります。問題が起きたとき、契約上の責任がなくても、連絡は作った人に来ます。だからこそ、担当しないと決めたなら、その旨を納品資料に残す必要があります。

検索まわりの初期設定

タイトルの設定、構造化データ、サイトマップの登録、計測ツールの導入。これらは「入れておいてくれるもの」として期待されやすい作業です。含めるなら項目に立て、含めないなら範囲外に書きます。

範囲を書かないまま公開すると、公開後に「検索で出てこない」という相談が来ます。この相談は制作の話ではなく運用の話ですが、範囲を書いていなければ切り分けができません。

サーバーとドメインの契約作業

代行するのか、相手が契約するのか。代行する場合、契約名義を誰にするかまで決めます。名義が制作者のままだと、関係が終わった後も請求と管理責任が残ります。ここは金額の大小に関係なく、必ず書いておく項目です。

工数の置き方

項目が立ったら、それぞれに時間を置きます。ここで感覚に頼ると、案件ごとに精度がばらつきます。

過去の実績から数える

同じような作業を過去にやっているなら、その実績が最も信頼できる根拠です。逆に言えば、実績を記録していないと根拠が持てません。作業ごとにかかった時間を残しておくと、次の見積もりが早くなります。

記録するのは、工程名と実際にかかった時間、そして想定との差だけで足ります。差が大きく出た工程が、自分が読み違えやすい領域です。何度か記録すると、自分の癖が数えられる形で見えてきます。

不確実な工程には幅を持たせる

初めて触る機能、既存データの移行、外部サービスとの連携。これらは着手するまで正確に読めません。読めない工程に単一の数字を置くと、外れたときに丸ごと持ち出しになります。

対処は2つです。ひとつは、幅を持たせて上限側で見積もること。もうひとつは、その工程だけを先に切り出して調査の工程として提案することです。後者は、相手にとっても全体の金額が読めるようになるので、受け入れられやすい。

待ち時間を工数に入れない

確認待ちや素材待ちの期間は、作業時間ではありません。ただし、日程には影響します。工数と日程を分けて書かないと、待ちの期間が作業しているように見え、後から進捗を疑われます。

見積書には作業工数を、工程表には待ちを含む日程を書く。この2つを分けておくと、遅れが発生したときの説明が簡単になります。

自分の稼働率を織り込む

1日の全部を制作に使えるわけではありません。問い合わせ対応、打ち合わせ、事務作業、他案件の確認対応。これらを差し引いた時間が、実際に手を動かせる時間です。

この差し引きをせずに日程を出すと、構造的に間に合わない見積もりになります。稼働できる時間を控えめに置いて日程を出したほうが、結果として信頼を落としません。

案件の種類で変わる組み方

同じWordPress構築でも、案件の種類によって見積書の重心が変わります。

新規に一から作る場合

重心は要件整理とデザインにあります。既存の資産がないぶん、決めることが多い。決める工程を項目として立て、確認の回数を明記します。素材がまったくない状態から始まることも多いので、原稿と写真の扱いを前提条件の最上段に書きます。

既存サイトのリニューアル

重心は移行にあります。既存データの量と状態、URLの維持、現在動いている機能の再現。着手前の調査を工程として切り出すのが最も安全です。調査なしで出した見積もりは、ほぼ確実に外れます。

URLの構造を変えるかどうかは、公開後の検索流入に直結します。維持するのか、変更して転送するのか、変更して転送もしないのか。この判断は相手が下すものですが、判断材料を出すのは制作側の仕事です。項目として立てておくと、後から「聞いていない」が起きません。

稼働中サイトの部分改修

重心はリスク管理です。動いているサイトに手を入れるので、失敗したときの影響が大きい。テスト環境の用意、バックアップ、公開作業の手順、切り戻しの準備。これらを項目として立てます。作業そのものは小さくても、周辺の準備が工数の大半を占めることがあります。

制作会社の下請けとして入る場合

重心はやりとりの経路です。エンドクライアントと直接話せるのか、すべて元請け経由か。経由の場合、質問の回答が返るまでの日数が工程を支配します。この待ち時間を前提条件に書いておかないと、遅れの責任が自分に寄ってきます。

検収の主体も確認します。元請けが検収するのか、エンドクライアントのOKが必要か。後者なら、支払期日の起点をどこに置くかを先に決めておきます。

見積書の体裁

項目が正しくても、書き方で伝わらないことがあります。体裁で押さえるのは3点です。

前提条件を先頭に書く

金額の下ではなく、項目の前に置きます。素材の提供時期、確認の返答期限、既存データの状態、決裁者と確認回数。前提が崩れたら金額と日程が動く、という一文も入れます。

前提条件を先頭に置くと、相手はそれを読んでから金額を見ます。後ろに小さく書いてあると、読まれないまま合意されます。読まれていない前提は、存在しないのと同じです。

範囲外を明記する

含まれないものを、含まれるものと同じくらい丁寧に書きます。原稿制作、写真撮影、ロゴ制作、サーバーとドメインの契約、公開後の保守、広告運用。書いてあれば、相手は別途の相談として持ってきます。書いていなければ、含まれているものとして持ってきます。

専門用語に一行の説明を添える

投稿タイプ、カスタムフィールド、テスト環境、リダイレクト。制作側の日常語は、相手にとって未知語です。項目名の横に一行の説明を入れるだけで、決裁の速度が変わります。

説明は短くします。「カスタム投稿タイプの設計（実績やお知らせなど、記事とは別の形式で管理するための仕組みの設定）」。この程度で、社内の誰が読んでも意味が通ります。

有効期限と支払いの区切り

見積もりの有効期限を書きます。半年前の見積もりで発注される事態を防げます。支払いは工程に紐づけて区切ります。着手時、デザイン確定時、公開時のような形です。一括後払いは、完成の定義が揺れたときに全額が宙に浮きます。

フリーランスとして業務委託を受ける取引では、発注者が取引条件を明示する義務や、報酬の支払期日に関する規律が定められています。制度の内容はe-Govで条文を確認できます。

相見積もりに並んだときの考え方

複数社の見積もりが並ぶ場面では、総額だけで判断されるとは限りません。判断されるのは、この金額で何が起きるかが分かるかどうかです。

比較されて負ける見積書には共通点があります。項目が粗い、前提条件がない、範囲外の記載がない。この3つが欠けていると、相手は判断材料を持てないので、結局は安いほうを選びます。逆に、粗い見積もりが並ぶ中に細かい見積もりを1つ出すと、そこだけ議論の質が変わります。

値下げを求められたときも、項目が分かれていれば対応できます。落とす機能を相手と決める形にすれば、金額は下がっても工数は下がります。一式で出していると、同じ作業量のまま金額だけを削ることになります。

見積もりを出した後のやりとり

出して終わりではありません。返ってくる反応への対応も、見積もりの一部です。

金額の根拠を聞かれたとき

項目が細かく分かれていれば、この質問には答えられます。どの作業に何時間かかるか、なぜその時間が必要か。説明できない項目があるなら、それは自分でも根拠を持てていない項目です。

答えるときは、作業の難しさではなく、作業の内容を説明します。「難しいので時間がかかります」は説明になりません。「投稿の型を固定して、担当者が入力を間違えても崩れない状態にする作業です」のほうが伝わります。

値引きを求められたとき

金額だけを下げる回答をしないことです。下げるなら、範囲も一緒に下げます。「この機能を次のフェーズに送れば、この金額になります」という形にする。相手にとっても、何を諦めたのかが分かるほうが納得しやすい。

一度だけ例外的に下げる、という判断もあります。その場合は、なぜ今回だけなのかを書面に残します。残さないと、次回も同じ金額が基準になります。

発注が決まらないまま時間が過ぎるとき

見積もりを出したまま連絡が途絶えることがあります。有効期限を書いてあれば、期限を理由に一度連絡できます。期限を過ぎた場合は再見積もりになると伝えれば、相手の社内で判断が動くことがあります。

追わないという選択もあります。決まらない案件を追い続けるより、条件の合う引き合いに時間を使うほうが、結果的に稼働が埋まります。追う対象を決めておくと、この判断が早くなります。

要件が変わって再提出になったとき

再提出のときは、前回との差分を明示します。何が追加され、何が外れたか。差分がないと、単なる値上げに見えます。差分が書いてあれば、相手は自分たちの要望が金額に反映された結果として読みます。

市場を見てきた立場からの観察

20年この市場を見てきた立場から言うと、見積もりで消耗している人ほど、見積書を「金額を伝える紙」だと思っています。実際には、見積書は取引の設計図です。設計図が粗い取引は、着手後に必ず現場で調整が発生し、その調整コストを受注側が全部かぶります。長く続いている人の見積書は、例外なく前提条件と範囲外の記載が厚い。

もうひとつ、運営者として見てきた限りでは、間に会社が入る取引ほど、見積書の項目が抽象的になります。伝言を重ねるうちに要件が丸められ、丸められた要件がそのまま一式表記になる。直接取引の利点は、受け手の手取りが厚くなることだけではありません。依頼の中身が原型のまま届くので、項目を具体的に立てられる。手数料0%の構造が効くのは、金額の話としてより、見積もりの精度が上がるという実務の話としてです。

職域データから見る、見積もりの守備範囲

見積もりが膨らむ最大の原因は、自分の職域を超えた工程を抱え込むことです。範囲を切るには、隣の職域が何をする仕事かを知っている必要があります。

開発寄りの工程についてはソフトウェア作成者の年収・単価相場で職種としての役割を確認できます。原稿制作を範囲外にするなら、著述家，記者，編集者の年収・単価相場が扱う編集職の守備範囲を把握しておくと、切り分けの説明がしやすくなります。集客や広告運用まで含む相談ならAI・マーケティング・セキュリティのお仕事の領域として別の担い手に渡すほうが、結果が出ます。実装量が大きく開発寄りに振れる案件は、アプリケーション開発のお仕事として工程を分けたほうが、見積もりの精度が上がります。

見積書や提案書の書式そのものに不安があるなら、ビジネス文書検定が扱う文書の型が実務にそのまま効きます。読み手が判断できる資料を作る技術は、才能ではなく型です。

見積もりは、受注のための営業資料ではありません。着手後に自分を守る唯一の記録です。項目を立てるのに使った時間は、後で発生する無償作業を丸ごと減らします。どの項目を書き忘れたかは、着手してからしか分かりません。だからこそ、書き忘れやすい項目を先に一覧として持っておく価値があります。