フリーランスエンジニアの提案書と料金表｜1枚で伝わる構成と単価の見せ方

対象読者と前提

本記事は、次のような読者を想定しています。

• 実務経験3年以上のフリーランスエンジニアで、エージェント経由から直請け（エンドクライアント直接契約）にシフトしたい方

• Web／モバイル／インフラ／SaaS／データ基盤のいずれかで開発・設計・運用の実務経験がある方

• 提案書を作った経験がない、または既存テンプレを使い回して反応が悪い方

• 業務委託契約（準委任・請負）を前提に、単発〜数か月の案件を狙う方

対象は個人事業主・法人成りしたひとり社長のいずれも含みます。SES常駐案件の営業ではなく、フォームからの新規営業・紹介経由・SNS経由での直請けが主な用途です。

提案書の役割｜スキルシート・営業メール・見積書との違い

結論：提案書は、営業メールで接触し、スキルシートで経歴を渡し、見積書で金額を確定するまでの中間フェーズで使う営業資料です。役割が違うため、1つで代用できません。

営業書類の使い分けは次のとおりです。

営業メールが「返信をもらう」ためのもの、スキルシートが「経歴で信用してもらう」ためのものだとすれば、提案書は「この案件で選んでもらう」ための資料です。相手の要件に合わせて中身を差し替える前提で作ります。

なぜ提案書が単価を左右するか

直案件で単価が伸びる場面は、相手が「金額の妥当性」を判断できるときです。スキルシートは過去実績、営業メールは意欲を伝えますが、その案件でどのくらいの価値を出せるかを提示できるのは提案書だけです。金額の裏付けを1枚ものに集約すると、相手側の稟議・上長説明が進みやすくなります。

エージェント経由でも、担当営業が使う社内資料の一部として提案書相当のサマリが必要になるケースがあります。エージェント担当と単価交渉する際にも役立ちます。詳しくはフリーランスエンジニアの単価交渉のコツ｜タイミング・伝え方・根拠の作り方を参照してください。

直案件で通る提案書に必要な6つの構成要素

結論：直案件で通る提案書は次の6要素で構成します。課題認識→解決策→体制→料金→契約条件の順に読み進められる構造が基本です。

1. 表紙・見出し：案件名・提案先・提案日・自分の名前と肩書き

2. 課題認識：相手の要件を1〜3行にリライトし、こちらがどう理解しているかを提示

3. 提供価値・解決策：課題に対する具体的アプローチ、担当できる範囲

4. 体制・稼働・スケジュール：稼働時間、開始日、想定スケジュール

5. 料金表：単価・内訳・オプション・変動費

6. 契約条件：契約形態、成果物、権利、支払サイト、秘密保持

各要素の役割は次のとおりです。

分量は目安です。要素5と6を省略した提案書は「話が進まない」まま止まりやすいため、必ず含めます。

6要素を配置する順序

配置は「相手が読む順」で並べます。相手が最初に確認するのは「何の話か（表紙）」→「要件を理解しているか（課題認識）」の2点です。単価は3番目以降で構いません。単価だけを冒頭に置くと、要件を理解していないまま金額を提示している印象になります。

提案書の型｜A4 1〜2枚の1枚もの構成テンプレ

結論：直案件用の提案書はA4 1〜2枚（PDF）が実用的です。相手が印刷して社内共有しやすく、ページ数が多いと読まれずに終わります。

1枚もの構成の基本レイアウト

A4 1枚に収める場合のレイアウト例は次のとおりです。

A4 2枚にする場合は、1枚目にご要件〜料金、2枚目に契約条件〜実績サマリを配置します。相手側の担当者が上長に説明しやすい単位に分けるのが目安です。

1枚もので守る5つの原則

1. PDFで送付（先方指定がない場合）：レイアウト崩れを防ぐため、WordやPowerPointのままではなくPDF化する。先方から指定フォーマットがある場合はそちらに従う

2. ファイル名に案件名と提案日を入れる：例「提案書_〇〇社_XX案件_2026XXXX.pdf」

3. 図・アイコンは最小限：装飾より情報密度を優先する

4. 金額は税別・税込を明示：「税別」「税込」の表記漏れは減点材料になりやすい

5. 書体・色数を絞る：本文はゴシック体1種、色は2〜3色まで

テンプレを流用する場合の注意

ネット上の提案書テンプレを流用する場合、次の4カ所は必ず個別化します。

• 表紙（案件名・提案先）

• 課題認識（相手の要件のリライト）

• 提供価値（担当範囲）

• 料金表（単価・オプション）

これ以外の契約条件・支払サイトはテンプレをベースにできますが、相手先の取引条件（支払サイト・検収・NDA運用など）は案件ごとに確認して調整します。テンプレのまま使い回すと、支払サイトのずれや検収条件の見落としが実害につながります。表紙と課題認識をコピペのまま送ると即座に「使い回し」と判定されるため、この2カ所は毎回書き換えます。

「できること」の見せ方｜スキル・実績・体制の翻訳

結論：直案件の相手は「技術スタック名」より「その技術で何を解決した経験があるか」を見ます。実績は課題→アプローチ→成果の3要素に翻訳して書きます。

実績の翻訳フォーマット

過去案件は次のフォーマットで整理します。

「Rails経験10年」と書くより、「Railsを使ったECサイトの決済再設計で障害を減らした」の方が具体性で勝ります。技術名は使用技術欄に集約し、本文は課題と成果で構成します。

スキルシート側で職務経歴を網羅する前提で、提案書にはこの案件の課題に関係する2〜3件の実績だけを抜粋します。スキルシートの詳細な書き方はスキルシートで単価を上げる書き方｜評価される定量表現と実績の翻訳も参考にしてください。

「担当範囲」の書き方

提供内容は「できること」を並べるより、この案件で何を担当するかを書きます。相手は「担当範囲が広くて曖昧」より「範囲が絞られていて責任が明確」を選びます。

• ❌「フロントエンド・バックエンド・インフラすべて対応可能」（範囲が広すぎる）

• ✅「主担当：バックエンド設計・実装（Rails 7）／副担当：フロント（Next.js）は既存メンバーのレビューまで」

「主担当」と「副担当」を分けると相手側で分業設計しやすくなります。全部やれると書くと「本当に全部できるのか」と警戒されるケースもあります。

定量表現のコツ

体制規模・工数・成果指標は数値で書きます。数値は社内観測ベース／目標値／実測値を書き分けます。

• 体制規模：「5〜8名のチーム」（数値）

• 工数：「月80h想定／週4稼働」（数値）

• 成果指標：「レスポンス時間を30%程度短縮（社内観測ベース）」（数値＋観測範囲）

数値の観測範囲を書かないと、相手側で「実測値なのか、感覚値なのか」判断できません。「社内観測ベース」「本人記憶ベース」「案件終了時の集計値」など、どの粒度の数字かを併記します。

料金表の作り方｜単価の内訳と見せ方

結論：料金表は基本単価＋追加スコープ単価＋変動費の3層で提示します。1つの金額を出すだけだと交渉の起点がなく、金額幅を広く提示すると「相場観がない」と見られます。

3層構造の内訳例

基本単価は「稼働単位」を必ず添えます。「月額100万円」だけだと稼働時間が不明で、相手が比較できません。「週4／月80h想定」まで書いて初めて時間換算が可能になります。

単価の水準感を掴む

提案する単価が妥当か判断するには、市場水準の把握が前提になります。エージェントの公開案件の相場観と、自分のスキル・経験年数を照合します。

体系的な単価水準の考え方はフリーランスエンジニアの単価相場と単価の上げ方で整理しています。自分がどのくらいの単価を狙えるか気になる方は、無料のフリーランスエンジニア単価診断で現在の市場単価の目安を確認できます。

幅で提示するか、1点で提示するか

結論：稼働条件が固まっているなら1点、要件がまだブレるなら上下2〜3割程度の幅で提示することが多いです。幅の目安は案件特性で変わるため、固定ルールではなく相手側の意思決定に合わせて調整します。

• 1点提示：週4／月80h・スコープ確定・6か月契約など、条件が確定している場合

• 幅提示：スコープが未確定、稼働日数が相手の状況で変わる場合

幅で提示する場合、上限値の根拠を添えます。「フルスコープ担当・追加業務込み」など、上限側の条件を明示しないと相手が下限値を基準に交渉してきます。

単価根拠の書き方

料金表の下に単価の根拠を1〜2行添えます。相手側の稟議で「なぜこの金額か」を説明できるようにするためです。

• 例：「本単価は主要フリーランスエージェント数社の公開案件（Rails・週4準委任・首都圏）を参考にした水準です。実務経験〇年・PM経験ありの前提で提示しています」

根拠なしで金額だけ出すと、相手側で削減交渉の起点にされやすくなります。参考にした情報の性質（公開案件／面談情報／エージェント提示）と対象案件の類型（週4準委任／首都圏など）まで書くと、金額の裏付けが伝わります。

稼働別のレンジ表

稼働時間と稼働形態が変数の場合、次のようなレンジ表を提示します。以下は首都圏中心のWeb系開発案件（実務経験3〜7年・準委任・公開案件と面談情報の観測ベース）を想定した目安で、案件のスキル要件や職種で上下します。自身の実績・スキル帯で数字を調整してください。

フルリモート／一部出社／常駐で単価が変わる場合は列を分けます。相手側で「自社の条件だといくらか」を一目で判断できるようにします。

消費税・源泉徴収の扱い

料金表には次の2点を明記します。

• 税別／税込の表記：「月額100万円（税別）」など。省略すると認識ずれの原因になります

• 源泉徴収の有無：一般的なシステム開発・保守の業務委託報酬は源泉徴収の対象外とされることが多いですが、業務内容や報酬名目（原稿料・デザイン料・講師料など）で対象になるケースもあります。支払側の運用と契約内容で扱いが変わるため、事前に発注者と確認します。対象範囲の詳細は国税庁：源泉徴収が必要な報酬・料金等とはを参照してください

インボイス登録の有無も、料金表の脚注に書くと相手側で経理処理がスムーズになります。

契約条件の書き方｜稼働・支払・成果物・権利

結論：契約条件は契約形態・成果物・権利・支払サイト・秘密保持の5点を提案書に載せます。契約書はこのあと別途締結しますが、主要条件を提案書段階で提示しておくと契約締結が早くなります。

契約形態（準委任 vs 請負）

契約形態は準委任と請負で権利義務が大きく変わります。

Web開発・SaaS・運用支援の直案件では準委任で進むケースが多く見られます（公開案件・面談情報ベースの傾向）。請負は検収条件や納品単位の設計が必要で、準委任より報酬条件の整理に手間がかかりやすい契約形態です。単発の受託開発・成果物単位で切れる案件では請負が選ばれます。提案書には「契約形態：準委任」と1行で書けば十分です。

成果物の定義

準委任でも「提供物」を明示します。定義がないと納品可否で揉めます。

• 例：「週次進捗レポート、担当実装コード（Gitリポジトリへプッシュ）、設計ドキュメント（Notion／Confluence等の指定ツールへ格納）」

「成果物」ではなく「提供物」と書くと、請負契約と混同されにくくなります。

権利（著作権・知的財産）

成果物の著作権帰属は、提案書段階で「譲渡／使用許諾／共有」のいずれかを明示します。著作権の帰属は当然に決まるものではなく、契約で定める事項です。実務では発注者帰属を求められるケースが多く見られますが、契約前に確認が必要です。

• 著作権譲渡：納品時点で著作権を発注者に譲渡（発注者帰属を求められるケースが多い）

• 使用許諾：エンジニア側に著作権を留保し、発注者に使用許諾を出す

• 共有：双方で共有（実務上あまり使われない）

著作者人格権の不行使特約を求められるケースもあります。この特約は再利用・改変・氏名表示の可否に影響が大きい条件のため、内容が不明な場合は契約前に弁護士・専門家へ確認するのが安全です。提案書には「著作権：貴社に譲渡（詳細は契約書にて）」と1行書き、具体的な条件は契約書で詰めます。

支払サイト

支払条件は提案書に明記します。キャッシュフローに直結する項目です。

• 例：「月末締翌月末払い（30日サイト）」「月末締翌月20日払い」

60日以上の支払サイトは提示された時点で交渉するのが実務です。フリーランス法（特定受託事業者に係る取引の適正化等に関する法律）の適用対象となる取引では、発注者が特定業務委託事業者に該当する場合、報酬支払期日を成果物受領日から60日以内に定める義務があります。適用可否や例外は取引形態・発注者側の要件で変わるため、詳細は公正取引委員会：フリーランスの取引適正化に向けた公正取引委員会の取組の一次情報を確認してください。実務上は翌月末払い（30日サイト）を目安に交渉するケースが多く見られます。

秘密保持・NDA

秘密保持は「別途NDA締結」と1行書くのが標準です。NDAは案件開始前に締結し、提案書段階ではNDAが未締結でも構いません。

• 例：「秘密保持：業務開始前にNDAを別途締結」

提案書自体を機密扱いにする場合は、フッターに「本提案書は貴社内での検討目的にのみご使用ください」と1行加えます。

契約書に引き継ぐ流れ

提案書で合意した条件を、契約書段階で改めて確認します。契約書の詳細確認ポイントは業務委託契約書の確認ポイント｜フリーランスエンジニアが締結前に見る条項とチェックリストにまとめています。

提出後の運用｜面談・改訂・NG例

結論：提案書は送って終わりではありません。送付から1営業日以内の返信、7営業日以内の初回面談を目安に運用します。

フォローアップのタイミング

送付後の運用は次のとおりです。

• 送付当日：メール本文で「ご不明点あればご連絡ください」を添えて送付

• 3営業日後：返信がない場合、1回だけリマインド（内容確認の問い合わせ）

• 7営業日後：返信がない場合、案件そのものが動いていない可能性が高い

3営業日で返信がない案件は、社内検討で止まっているか、優先度が下がっているケースが多く見られます。企業規模や決裁フローによってはさらに時間がかかることもあるため、案件規模で判断します。しつこく追いかけるより、次の案件の営業に時間を回すのが実務的です。

面談での提案書の使い方

初回面談では提案書を画面共有しながら課題認識→提供価値→料金の順に説明します。所要時間は15〜30分程度が目安です。

• 説明順は提案書と同じ（読みながら口頭で補足する形）

• 単価は面談中に必ず口頭でも伝える（テキストだけだと双方の認識ずれが起きやすい）

• 相手の反応で単価幅の上下を口頭で示唆する（「週4なら〜、週5なら〜」）

面談後は提案書を改訂して再送します。改訂版は変更履歴（version 1.1、変更点：稼働週数の追加）を明示します。

よくあるNG例

提案書でありがちな失敗は次のとおりです。

「応相談」だけの料金表は、相手側で稟議を進められないため、実務では避けます。

改訂の管理

複数案件で提案書を運用する場合、案件ごとにバージョン管理します。

• ファイル命名例：「提案書_A社_XX案件_2026XXXX_v1.0.pdf」

• 案件ごとにフォルダを分ける

• 送付日時と改訂履歴をメモ管理する

雑に運用すると、A社に送るはずの提案書をB社に誤送するリスクがあります。ここは事故につながるため、機械的に管理します。

直案件を取るための提案書運用の流れ

結論：提案書は「営業活動全体」の中間資料です。単体で完結せず、接触→提案→契約→稼働の流れの中で位置づけます。

直案件全体の営業手順はフリーランスエンジニアの直案件の取り方｜エージェント以外の獲得ルート7選と契約・営業の注意点にまとめています。営業を仕組み化する考え方はフリーランスエンジニアの営業を仕組み化｜案件を切らさない継続受注、面談から稼働までの流れはフリーランス応募の流れ｜職務経歴の棚卸しから書類提出後の管理まで7ステップを参照してください。

案件探しから始める方はフリコンの案件一覧で公開案件をチェックしつつ、無料のフリーランスエンジニア単価診断で狙える単価水準の目安を確認しておくと、提案書の単価設定が現実的になります。

まとめ

• 直案件で通る提案書は「1枚ものサマリ＋料金表」の2部構成。核は課題認識→解決策→稼働・単価・契約条件

• 営業メール・スキルシート・見積書とは役割が別。この案件向けにカスタマイズした1枚ものが提案書

• 6要素（表紙・課題認識・提供価値・体制・料金表・契約条件）をA4 1〜2枚に配置する

• 料金表は基本単価＋追加スコープ単価＋変動費の3層で提示し、単価根拠を添える

• 契約条件は契約形態・成果物・権利・支払サイト・秘密保持の5点を提案書段階で載せる

• 送付から1営業日以内の返信、7営業日以内の面談を目安に運用する

• テンプレを流用する場合も、表紙・課題認識・提供価値・料金表の4カ所は必ず個別化する

提案書は営業活動の中間資料であり、単体では完結しません。接触→提案→契約→稼働の流れの中で位置づけ、営業メール・スキルシート・見積書と役割を分けて使い分けます。自分の狙える単価水準は無料のフリーランスエンジニア単価診断で確認しつつ、直案件の獲得ルート全体はフリーランスエンジニアの直案件の取り方｜エージェント以外の獲得ルート7選と契約・営業の注意点を参照してください。

参考リンク

• 公正取引委員会：フリーランスの取引適正化に向けた公正取引委員会の取組

• 厚生労働省：フリーランスとして業務を行う方・フリーランスの方に業務を委託する事業者の方等へ

• 国税庁：源泉徴収が必要な報酬・料金等とは