Claude Code 受託開発で単価を倍にする実践戦略 — 個人開発者が法人案件を獲るまで

「工数の根拠」を構造化する

受託開発で最も削られやすいのが「工数の根拠」の説明です。「えーと、だいたい3日くらいですね」では、相手も値切りたくなります。私が今使っている構造は次のようなものです。

工数見積もりの3層構造
 
[A] 純粋な実装時間（Claude Code 補助あり）
    例: フォームコンポーネント実装 0.5人日
        → ベース実装 + UIロジック + 状態管理
 
[B] 実装周辺コスト
    例: テストコード作成 0.3人日
        ドキュメント整備 0.2人日
        コードレビュー反映 0.2人日
 
[C] プロジェクト固有の不確実性バッファ
    例: 既存コードベース理解 0.5人日
        仕様の揺れ吸収 0.3人日
        環境構築のハマり対応 0.2人日
 
合計: 2.2人日

この構造を提示するだけで、クライアントは「ああ、なるほど。テストやドキュメントもちゃんと工数として見ているんですね」と納得します。逆に「2人日です」とだけ言うと、「もうちょっと安くなりませんか」が即座に返ってきます。

私はこの3層構造を Claude Code に作業ログを書いてもらいながら逆算で組み立てています。具体的には、開発の合間に「いまの作業を3層で分類するとどうなるか」と Claude に聞き、メモを残しています。これを蓄積していくと、自分の体感工数と実工数のずれが見えてきて、見積もりの精度が一段上がります。

3層の見積もりを、終わった案件で校正する

3層構造は、書いた時点ではただの仮説です。校正しないまま使い続けると、どの層がはみ出しているのか分からないまま「なぜか利益が薄い案件」を積み上げることになります。私がしばらくそうでした。

いまは案件が終わるたびに、見積もりと実績を同じ形式で3行だけ残しています。ファイルは CSV で足ります。

# 案件終了時の追記（列: 日付, 案件, 層, 見積人日, 実績人日）
echo "2026-05-04,order-admin,A,0.5,0.6" >> ~/work/estimate_log.csv
echo "2026-05-04,order-admin,B,0.7,1.4" >> ~/work/estimate_log.csv
echo "2026-05-04,order-admin,C,1.0,0.7" >> ~/work/estimate_log.csv

数案件ぶん貯まったら、層ごとに合計して比率を出します。

import csv
from collections import defaultdict
 
rows = list(csv.reader(open("estimate_log.csv", encoding="utf-8")))
agg = defaultdict(lambda: [0.0, 0.0])  # 層 -> [見積合計, 実績合計]
 
for _date, _job, layer, est, act in rows:
    agg[layer][0] += float(est)
    agg[layer][1] += float(act)
 
for layer in sorted(agg):
    est, act = agg[layer]
    # 係数 1.0 が「読めていた」、1.5 なら見積もりが半分しか当たっていない状態
    print(f"{layer}: 見積 {est:.1f} / 実績 {act:.1f} / 係数 {act / est:.2f}")

直近10案件を通したときの出力が、次の表です。

A 層はほぼ読めていて、C 層はむしろ積みすぎていました。外していたのは B 層だけです。テストとドキュメントとレビュー反映を「実装のおまけ」として短く置く癖が自分にあったのだと気づいたのは、この3行を10案件ぶん並べてからでした。それまでは「見積もりが甘い」という漠然とした反省を、案件ごとに繰り返していたのです。

いまは B 層に係数をそのまま掛けず、1.9 ではなく 1.6 を掛けています。丸ごと掛けてしまうと、その数字に合わせて作業のほうが伸びてしまうかもしれない——そう疑っているので、四半期ごとに掛け率を見直す形にしております。

単価は交渉の場ではなく、前の案件の記録が決めています。 この順番だけは、立て込んでいる月でも崩さないようにしています。

見積もり提示時に必ず添える1ページ

見積もりを送るとき、私は金額表だけでなく必ず1ページの補足ドキュメントを添えます。中身は以下のような構成です。

• 本案件で達成したいゴール（クライアントの言葉で再記述）
• 想定スコープ（含むもの／含まないもの）
• 前提条件（OS、ブラウザ、API版数、想定アクセス数など）
• リスクと対処方針（仕様変更、サードパーティ障害、納期遅延）
• AI活用の透明性に関する注記
• 修正対応の範囲（軽微修正は何回まで無償、追加要件は別見積もり）

特に「AI活用の透明性に関する注記」は、Claude Code を使う上で重要なポイントです。私は次のような短い文面を添えています。

本案件では、設計・実装・テストの一部に Anthropic 社の Claude Code を活用します。
コードや設計の最終判断は弊方が責任をもって行い、納品物の品質・著作権・保守性については
通常の受託開発と同等の責任を負います。生成プロセスのログは、必要に応じてご提示可能です。

この1段落を入れることで、クライアントの不安（「AIが書いたコードを納品されて大丈夫なのか」）を先回りして解消できます。同時に「ちゃんと考えている専門家」という印象を与えられます。これは単価交渉の場面で大きな効果を発揮します。

ヒアリングを録画して Claude に整理させる

私が単価を上げる上で最も効いた習慣は、ヒアリングミーティングを録画（または書き起こし）して、Claude に要件整理をしてもらうことです。

具体的なフローは次の通りです。

# 1. ミーティング録画から書き起こしを生成
# (ここはWhisper等のSTTツールやZoomの自動書き起こしを使用)
# 結果として meeting_2026_05_01.txt が手元にある状態
 
# 2. Claude Code に整理を依頼
claude "次のミーティング書き起こしから、以下を抽出してください:
- クライアントの本当のゴール（明示・暗示の両方）
- 必須要件と希望要件の分離
- 触れられていないが確認すべき仕様の穴
- 想定リスクと懸念点
- 私が次のメールで聞くべき質問リスト
 
書き起こし: $(cat meeting_2026_05_01.txt)"

これを最初にやると、ヒアリングで聞き漏らした論点が必ずいくつか見つかります。「画像のアップロード時、最大ファイルサイズの想定は」「ログイン状態は何日保持する想定か」など、後から発覚すると追加工数になる要件を、契約前に潰せるようになります。

私の経験では、これだけで「あとから追加要望が出てスコープが膨らむ」事故が体感で7割減りました。スコープが固まるということは、見積もり精度が上がるということで、結果として単価を強気に提示できるようになります。

納品時の「価値の見える化」

同じ成果物でも、見せ方ひとつで評価が変わります。納品時に Claude Code と一緒に作っているのが、以下の3点セットです。

第一に、簡易的な技術選定レポート。「なぜこのライブラリを選んだか」「他の選択肢と比べて何が優れていたか」を1〜2ページにまとめたものです。

第二に、運用・保守ドキュメント。今後クライアント側でメンテナンスする可能性がある箇所、外部サービス障害時のリカバリ手順、よくあるエラーの対処法などを書いておきます。

第三に、改善提案メモ。納品スコープには含まれないが、運用していく上で考えるとよい項目を3〜5個提示します。これは次回案件の種まきにもなります。

改善提案メモの例
 
1. 現状の画像処理は同期で行っていますが、
   月間アクセスが2万を超えたあたりからキューイングを検討する価値があります。
   想定工数: 2人日。料金感: 8万円〜。
 
2. 管理画面のログイン履歴が未実装ですが、セキュリティ監査の観点で
   半年以内の追加をおすすめします。
   想定工数: 1人日。料金感: 4万円〜。
 
3. SEO面では、構造化データ（JSON-LD）の追加が有効です。
   特にサービス紹介ページとFAQページが対象です。
   想定工数: 0.5人日。料金感: 2万円〜。

この提案メモは、押し売りに見えないトーンで書くのが肝心です。「やった方がいいですよ」ではなく「今後考える価値があります」のように、クライアントの判断を尊重する書き方を意識します。これだけで継続案件率が大きく変わります。

法人案件で必ず入れておく契約条項

個人事業主が法人案件を請ける際、契約書を曖昧にしておくと後で必ず揉めます。私が必ず入れている条項を整理します。

検収期間の明確化として、「納品から〇営業日以内に検収を完了するものとし、期間内に通知がない場合は検収完了とみなす」と書きます。これがないと、いつまでも入金されない事態が起こります。

修正対応の範囲として、「納品物の軽微な修正は検収期間内に〇回まで無償で対応します。追加要件・仕様変更は別途見積もりとする」と書きます。修正と追加要件の境界を明文化することが大事です。

知的財産権として、「成果物の著作権は検収完了および対価の全額入金をもってクライアントに移転します。それまでは弊方に帰属する」と書きます。入金前にコードを使われるリスクを防ぎます。

責任範囲として、「成果物の使用によって生じた損害について、弊方の責任は本契約の対価額を上限とする」と書きます。個人事業主が無限責任を負う事態を避けるためです。

AI活用の明示として、「設計・実装・テストの一部に AI 開発支援ツール（Claude Code 等）を活用します。生成過程の記録は必要に応じて提示可能であり、最終的な品質責任は弊方が負う」と書きます。

これらの条項は、契約書テンプレートに最初から組み込んでおくと、案件ごとに考える必要がなくなります。Claude Code に「この契約条項の文面で、抜け漏れがあるかチェックしてください」と相談しながら、半年に一度見直すのが私のルーチンです。

単発案件を継続案件に変える3つの仕掛け

単価を上げるもう一つの軸が、継続案件化です。同じクライアントから複数案件を頂けるようになると、営業コストがほぼゼロになり、実質的な時間単価が大きく伸びます。

まず、納品後1週間以内のフォローメールを必ず送ります。「運用開始後、何か気になる点はありませんか」と聞くだけで、追加要望や次の相談が出てきやすくなります。

次に、月次・四半期で「気になる改善ポイントがあればお知らせします」というスタンスを取ります。実際に見て気付いた点を1〜2個メールするだけで、「こんなに見てくれているんだ」と思ってもらえます。

最後に、保守契約という形で月額化を提案します。「月額〇万円で、月〇時間までの軽微な改修・問い合わせ対応・障害発生時の一次対応を含みます」のような形です。これは個人開発者にとってフロー収入の安定化として重要です。

私自身、保守契約を持つようになってから、「来月の収入が読める」状態になり、新規案件を焦って取らずに済むようになりました。焦らないということは、強気の単価を提示できるということです。

やってはいけない値決めパターン

最後に、私自身が過去にやってしまった失敗パターンをいくつか共有します。これは反面教師として読んでいただければと思います。

「友達割引」を最初から提示してしまうのは典型的な失敗です。一度下げた単価を後から戻すのは難しく、紹介の連鎖が始まると全員に同じ単価で対応することになります。

「とりあえず受けて、後から追加見積もりで調整しよう」は、ほぼ確実に火傷します。クライアントから見れば「最初の見積もりが甘かっただけでは」と感じられ、信頼を失います。

「他社さんはいくらでやってくれましたか」と聞いてしまうのも危険です。相場を知るのは大事ですが、それを判断基準にすると自分の単価が定まりません。自分の工数構造に基づいた根拠で値段を出すのが基本です。

これらを避けるためにも、最初に書いた「工数の3層構造」と「見積もり1ページ」をテンプレ化しておくことが有効です。

個人開発者が法人案件で疲弊しないための仕事の選び方

単価を上げる話と並行して、もう一つ大切なのが「どの案件を断るか」を決める基準を持つことです。法人案件は単価が高い反面、関係者が多くコミュニケーションコストが膨らみがちで、断る判断ができないと結局時間単価が下がってしまいます。私が今使っている基準を共有します。

意思決定者と直接話せるかどうかは、最初の重要なシグナルです。担当者の上司の上司まで決裁を上げる必要がある案件は、修正のたびに往復が発生し、確実に工数が想定の倍以上に膨らみます。初回打ち合わせで「この件、最終承認は誰になりますか」と聞いて、その人と直接話せる体制が組めなければ、強気の単価を提示するか、丁寧に辞退します。

仕様書の有無や精度も判断材料です。「いい感じにお願いします」型の案件は、ヒアリングと要件定義に膨大な時間を取られます。Claude Code を使えば要件整理は速くできますが、それでも「クライアント側で何を実現したいかが定まっていない」案件は地雷です。私はこういうケースでは、要件定義フェーズと実装フェーズを別々に契約する形を提案します。

支払い条件は最重要です。「成果物納品後に検収が完了したら30日以内に支払い」が最低ライン。「2ヶ月後の月末締め翌月末払い」のような条件は、実質3〜4ヶ月の運転資金が必要になります。個人事業主にとって、キャッシュフローが詰まると次の案件に集中できなくなり、結果として単価交渉が弱気になります。

これらを踏まえて、私は新規案件には次のような優先順位をつけています。

案件評価マトリクス（5段階）
 
[A] 意思決定者と直接話せる              5点
[B] 仕様の解像度が高い                  4点
[C] 支払いサイトが30日以内              4点
[D] 既存技術スタックで実装可能          3点
[E] 1案件あたりの規模が中規模以上       3点
[F] 紹介や継続案件につながる可能性      3点
 
合計15点以上 → 即受諾を検討
合計10〜14点 → 強気の単価を提示
合計9点以下  → 丁寧に辞退、または要件再構築を提案

この機械的なスコアリングを入れるだけで、感情に流された判断が減ります。Claude Code に「いまの案件メールを上記の6項目で採点してください」と渡せば、客観的な視点も得られます。

ポートフォリオを案件獲得装置に変える

単価交渉の場面で最も強いのは、過去の納品実績を具体的に見せられることです。ただし「サイト一覧」を並べるだけでは弱いです。私は次のような構成のポートフォリオページを使っています。

各案件について、課題（クライアントが何に困っていたか）、選んだ解決策（なぜその技術構成を選んだか）、定量的な成果（速度、コスト、エラー率がどう変化したか）、運用後の振り返り（その後どうなったか）の4項目をセットで書きます。

たとえば「ECサイトの注文管理画面リプレイス」案件なら、次のように書きます。

[案件] ECサイトの注文管理画面リプレイス
 
[課題] 既存の管理画面が React 16 + Redux で、新機能追加のたびに
       既存処理が壊れる状態。リプレイス工数は社内見積もりで
       約2人月だったが、実装担当者がいなかった。
 
[解決策] React 19 + Next.js 16 + Tailwind に移行。
         Claude Code を使ってテストカバレッジ80%を維持しながら段階的に置換。
 
[成果] 全画面の移行を1人月で完了。
       本番障害ゼロでの切り替え完了。
       新機能追加の実装速度が体感3倍になったとクライアントから報告。
 
[振り返り] 移行後3ヶ月時点で追加のリファクタ案件を頂戴し、
           保守契約に発展。

この粒度で書かれた事例が10件あると、新規クライアントは「この人に任せれば、自分のところでも同じような結果が出そうだ」とイメージできます。これが単価の根拠になります。

NDAで詳細が書けない案件については、業界・規模・技術スタックだけ抽象化して書く形にしています。それでも具体性は失われません。

失注した案件から学ぶ

失注した案件の振り返りを習慣化していますか。私は失注メールを受け取ったら、必ず24時間以内に「差し支えなければ、選定の決め手と弊方の改善点を教えていただけますか」と返信しています。返信率は3〜4割ですが、得られる情報は値千金です。

返ってくる典型的な理由としては「価格が高かった」「技術スタックの相性」「実績の業界が違った」「コミュニケーションのテンポ」「提案書の具体性」などがあります。これらを Claude Code に蓄積していき、四半期ごとに「最近の失注理由をパターン分けしてください」と分析を依頼します。

すると、自分の弱点が浮かび上がってきます。「提案書がテンプレ感が強い」が3回続いたときは、提案書の作り方そのものを見直しています。「技術スタックの相性」が理由に挙がるなら、得意領域を絞り込んで打ち出すようにしています。失注を「データ」として扱いはじめると、改善のループがようやく回り出すのです。

価格を上げるタイミングの見極め方

最後に、価格を上げる具体的なタイミングについて触れておきます。私が使っている目安は次の3つです。

第一に、引き合いが「断れないほど来ている」状態が3ヶ月続いたら、新規案件のみ単価を10〜20%上げます。既存クライアントは据え置き、これは関係性を守るためです。

第二に、自分のスキルセットが明確に上がった瞬間（新しい技術領域を案件で完遂できた、より大規模な案件を成功させた、認定資格を取得したなど）にも上げます。価格はスキルへの投資の対価でもあります。

第三に、業界全体の相場が上がっているタイミングを逃さないことです。技術系の年次レポート（Stack Overflow Developer Survey、IPA の白書など）を毎年チェックして、自分の単価が市場の中央値より明らかに低いなら、迷わず上げます。

価格を上げると、必ず一定割合のクライアントは離れます。これは正常な現象です。離れるクライアントよりも、新しく来てくれるクライアントの方が、単価の高さに見合った要求をしてくれることが多く、結果として仕事の質が上がります。

次の1案件で試していただきたいこと

次に届く案件メールへ返信する前に、工数を A・B・C の3層で書き出してみてください。そして見積もりを送ったあと、その3行を捨てずに置いておきます。案件が終わったら、実際にかかった時間を同じ3行の横に書き足すだけです。

1案件では何も見えません。3案件で自分の癖が見え、10案件で係数になります。私の場合、単価を動かせるようになったのは、交渉の言い回しを覚えたときではなく、この10行が貯まった日でした。