フリーランスエンジニアの直接受注｜コネゼロから始める5ステップ受注

エージェントから届く請求書を見て、「またマージンで20万円以上引かれている」とため息をついた経験はないでしょうか。月単価80万円の案件で手数料25%なら、年間で240万円もの差が生まれます。同じ稼働で手取りを増やすには、エージェント以外の経路、つまり「直接受注」に手を伸ばすしかない、と感じている方は多いはずです。

ただ、いざ動こうとすると壁にぶつかります。「コネがない」「営業をしたことがない」「契約書もまともに作れない」。SNSでは「直接案件で年収+200万円」のような発信が目に入りますが、自分が同じ場所に立てる気はしません。「直接受注はハイレベルなフリーランスだけのもの」という思い込みが、最初の一歩を止めてしまいます。

実際のところ、直接受注は「コネ」ではなく「順序」で取れます。中小企業やスタートアップは、エージェント経由ではなく個人エンジニアを直接探す状況が日常的にあり、その需要に対して「自分はここにいます」と発信する仕組みを整えていけば、コネゼロの状態からでも最初の1件にたどり着けます。問題は、その順序が並列に語られる「方法N選」型の記事では見えにくいことです。

この記事では、フリーランスエンジニアの直接受注を「Day1 〜 Month3」の時系列ロードマップで整理します。エージェント経由との4軸比較、発注側の需要パターン、コネゼロから始める5ステップ、信頼資産の整備手順、プル型 × プッシュ型のファネル設計、最初の1件を継続化する設計、そしてフリーランス新法を踏まえた契約リスクの回避策まで、実務目線で解説していきます。

読み終わる頃には、「今週GitHubのプロフィールを30分だけ整える」「来週ターゲット候補10社をリスト化する」というレベルにまで、行動の解像度を上げられるはずです。「いつか動こう」を「今週から動く」に変えるためのロードマップとして、ぜひ最後までお読みください。

フリーランスエンジニアの直接受注とは｜エージェント経由との違い

直接受注とは、エージェントやクラウドソーシング、案件マッチングプラットフォームを介さず、発注企業とフリーランスエンジニアが直接契約を結ぶ取引形態を指します。間に仲介者が入らないため、報酬・契約条件・コミュニケーションのすべてを当事者間で決められる点が最大の特徴です。

「直接受注は特別な営業力を持つ人だけのもの」というイメージを持たれがちですが、実態はもう少し地味です。中小企業やスタートアップが、コネのないフリーランスにメールで打診し、面談を経て契約する、というのは日常的に起きています。ここでは、直接受注の入口として「契約形態の選択肢」と「エージェント経由との4軸比較」を押さえておきましょう。

直接受注の3つの契約形態

エンジニアが直接受注で結ぶ契約は、おおむね以下の3形態のいずれかに収まります。

エージェント経由でこれまで稼働してきたエンジニアは、「準委任型の業務委託」に慣れているケースが多いはずです。直接受注でも入り口は同じ準委任型から入り、信頼が積み上がってから請負・顧問へと派生させていくのが現実的なルートです。

エージェント経由との4軸比較

直接受注とエージェント経由の違いを、4つの観点で整理します。

裁量と手取りを取りに行く代わりに、営業の自走が必要になる、というのが直接受注の本質です。次のセクションで、この「営業の自走」がペイするかどうかを数字で確かめてみましょう。

直接受注のメリット・デメリット｜手数料削減効果を具体的に試算

直接受注を語るうえで、最初に押さえたいのは「行動する動機が数字で立つかどうか」です。ここでは、月単価80万円で稼働しているエンジニアを想定したモデルケースで、手数料カット効果と、その裏返しとして発生する自走コストを比較してみます。

メリット5つ｜手数料削減効果を数値で見る

直接受注の代表的なメリットは次の5つです。

1. 手数料削減の直接効果: エージェント手数料が仮に25%だとすると、月単価80万円の案件では月20万円、年間で240万円が手元に残ります。仲介手数料が0%になることで、年収ベースで200万円以上動くケースは珍しくありません
2. 単価交渉の自由度が高い: 中間事業者を介さないため、自分のスキルと発注側のニーズに対して、適正な単価を直接交渉できます
3. 契約条件の柔軟性: 稼働日数・リモート可否・契約期間・成果物の範囲を、相手と直接調整できます。エージェントの標準契約に縛られず、自分の働き方に合わせた条件設計が可能です
4. 継続率・関係構築の深さ: 発注者と直接やり取りするため、信頼関係が深まりやすく、継続契約や追加案件への発展が起こりやすい傾向があります
5. スキル開示・実績公開の自由度: エージェント経由では NDA で縛られる範囲も、直接契約なら「公開可否」を交渉できます。実績公開ができれば、それが次の案件獲得の信頼資産になります

特に1つ目の手数料削減効果は、年単位で見ると数百万円規模のインパクトです。フリーランスエンジニア向け案件マッチングサービスの調査では、2025年12月時点のフリーランスエンジニア月額平均単価は78.3万円と報告されており（エン・ジャパン プレスリリース）、平均単価帯のエンジニアが手数料20%を削減できれば、年間180万円以上の差になります。

デメリットと回避策｜営業・契約・与信のリアル

一方で、直接受注には次のようなデメリット・リスクも存在します。

エージェント以外の案件獲得ルートを横断的に整理した記事として、エージェント以外の案件獲得方法も参考になります。直接受注に絞る前に、クラウドソーシング・コミュニティ経由・知人紹介などの選択肢を俯瞰しておくと、自分に合うルートが見えてきます。

手数料削減の損益分岐点｜営業工数とのトレードオフ

「年間240万円の削減効果」と「月数十時間の営業工数」を、同じテーブルに置いて考えてみましょう。

仮に、月20時間（週5時間）を営業活動に充てたとします。月稼働160時間で時間単価5,000円のエンジニアにとって、月20時間は機会費用換算で10万円、年間120万円相当です。

つまり、年間120万円の機会費用を払って年間240万円の手数料を取り戻す、というのが直接受注の経済モデルです。差し引き120万円のプラス。最初の1件にたどり着くまでは投資期間として赤字に見えますが、軌道に乗れば営業時間はぐっと減り、プラス幅は拡大します。

「営業の手間が惜しい」と感じるなら、それは直接受注に向いていないというより、ロードマップが見えていないからかもしれません。次のセクションから、その順序を具体化していきます。

コネなしでも直接受注が来る｜企業が直接エンジニアを探す3つの状況

「コネのない自分に、直接依頼なんて来るわけがない」。直接受注を躊躇する最大の理由は、この認知の壁です。ただ、この壁は発注側の事情を知ると、思いのほか簡単に崩れます。発注企業がエージェント経由ではなくフリーランスを直接探す場面は、実は日常的に存在します。ここでは代表的な3つのパターンを紹介します。

非IT中小企業の単発開発ニーズ

製造業・サービス業・小売業など、IT専任担当が社内にいない中小企業では、業務効率化のための小規模システム開発・既存システムの改修ニーズが定期的に発生します。

このとき、企業側は次のような事情を抱えています。

• 社内に技術選定ができる人がいないため、エージェントから提案を受けても判断できない
• SIerに見積もりを取ると数百万円単位になり、予算が合わない
• 知り合いの社長や同業者から「フリーランスに頼んでいる」と聞き、自社でも探してみたい

このタイプの企業は、「相手の顔が見える」「直接話せる」エンジニアを好みます。エージェント経由よりも、X(旧Twitter)・LinkedIn・Wantedly・コーポレートサイトの問い合わせフォームで個人に直接連絡を入れるケースが多くあります。

スタートアップの即戦力エンジニア需要

シード〜シリーズA初期のスタートアップは、MVP（最小プロダクト）の立ち上げや、PMF前後のプロダクト改修で「数ヶ月だけ手を貸してくれるエンジニア」を必要とします。

正社員採用には時間がかかり、エージェント経由では「採用フィー前提の高単価人材」しか紹介されません。スタートアップ側は、次のような動機で直接探しに動きます。

• スピード優先で、「今週から動ける人」を即決したい
• 採用フィーや高い手数料を上乗せした単価では予算が合わない
• 経営陣が技術出身で、エンジニアの実力を直接見極めたい

このタイプの企業は、CTO や技術顧問の SNS 経由でつながりを作ったり、自社の技術ブログ・GitHub の貢献履歴を見て個別に DM を送ったりします。「技術的な発信があるエンジニア」は、明確に発見されやすいポジションにいます。

事業会社の内製化補強ニーズ

中堅以上の事業会社では、近年「内製化」「DX 内製シフト」が経営課題になっており、SIer や元請けエージェント経由ではなく、フリーランスを直接迎えて内製チームに混ぜる動きが広がっています。

発注側の事情は次のとおりです。

• 大手SI 経由だと「孫請け・ひ孫請け」のエンジニアが入ってきて、コミュニケーションコストが高い
• エージェント経由だと手数料分の単価上乗せが必要で、同じ単価で直接契約できれば質を上げられる
• 既存社員が育成のために「直接やり取りできるエンジニア」と一緒に働きたい

このパターンでは、エンジニア採用担当・PdM・CTO クラスが、Wantedly・LinkedIn・技術カンファレンス登壇者リストなどから候補を探し、個別にコンタクトを取りに来ます。

これら3パターンに共通するのは、「企業側もコネのないフリーランスにアプローチしている」ことです。フリーランスエンジニアと直接契約すれば、品質を落とさずに2〜3割のコスト削減が実現する、と発注側の解説記事でも語られています（X-Network）。需要は確かに存在します。あとは「自分はここにいます」と発見可能な状態を作ればいいだけです。

コネゼロから始める直接受注の5ステップ

ここからが本記事の中核です。直接受注を「方法◯選」の並列リストではなく、「Day1 〜 Month3」の時系列ロードマップとして整理します。各ステップで「何を」「いつまでに」「どこまで」やるか、目安所要時間と典型的な失敗パターンも併記します。

全体像は次のとおりです。

各ステップは厳密に時系列ではなく、Step1 〜 3 は並行進行が前提です。Step1 を「整備しきってから次へ」と完璧主義に陥ると、3ヶ月で何も動かないままになります。「7割で先に進む」を意識してください。

Step1: 信頼資産の整備｜GitHub・ポートフォリオ・技術記事の優先順位

最初の1〜2週間で着手するのは、発見されたときに「この人に任せられそう」と判断してもらうための土台作りです。整備すべき資産と優先順位は、以下の順で進めるのが効率的です。

各資産の具体的な整備手順は、次のセクション「直接受注の信頼を支える4つの資産」で詳しく解説します。Step1 では「何を整備するか」の優先順位を押さえ、最低限のラインまで一気に到達させることを優先してください。

典型的な失敗: 「ポートフォリオサイトを完璧に作り込もう」として、Step1 だけで2ヶ月使ってしまうパターン。サイト作成は最後でも構いません。Step1 では GitHub と技術記事を最優先にします。

Step2: ターゲット30社リスト作成｜Wantedly・Green・コーポレートサイトの探索術

Step1 と並行して、アプローチ候補のリストを作ります。ここで重要なのは「闇雲に100社」ではなく、「自分が貢献できる確度の高い30社」に絞ることです。

リスト作成の探索源は次のとおりです。

リストに含める情報は、企業名・URL・採用情報のURL・業界・技術スタック・連絡先（採用窓口・問い合わせフォーム）の6項目を最低限揃えます。スプレッドシートで管理し、後述の Step4 でアプローチ実施有無・反応の有無を記録できる構成にしておくと、改善サイクルが回せます。

典型的な失敗: 「興味がある」だけで100社リストを作って、結局1社にもアプローチしないパターン。30社に絞り、「2週間で全社にアプローチする」と決めるほうが、最初の1件にたどり着く確率は高くなります。

Step3: 接点設計｜SNS発信・コミュニティ参加・登壇

リストへの直接アプローチ（Step4）と並行して、認知を広げる「プル型」の動きも進めます。プル型は時間がかかりますが、半年後・1年後の継続的な案件獲得につながります。

接点を作る代表的なアクションは次のとおりです。

• X（旧Twitter）での発信: 週3〜5回、自分の専門分野に関する技術的な気づき・成果・学びを投稿する。1ヶ月続けることで「この人は◯◯の人」と認知され始める
• 技術記事の継続投稿: 月1〜2本のペースで Zenn・Qiita に技術記事を投稿する。検索流入経由で発注者の目に触れる機会が増える
• コミュニティ参加: 自分の専門分野の Slack コミュニティ・Discord サーバー・勉強会に参加する。「困っている人を助ける」発信が、後日の案件相談につながる
• 登壇・LT: 小規模な勉強会で 5〜10 分の LT を月1回行う。「人前で話せるエンジニア」は発注側から見て信頼度が高い

SNS発信は短期的な「いいね」「フォロワー数」では測りにくい資産ですが、専門分野での発信が積み上がると、企業担当者や同業者から問い合わせ・紹介を受ける機会が自然と増えていきます。能動的なアプローチ（プッシュ型）だけに依存せず、待ち側のチャネル（プル型）も並行で育てることで、半年〜1年スパンで「向こうから声がかかる」状態を作れます。

典型的な失敗: SNS発信を「フォロワー数」「いいね数」で評価してしまうパターン。直接受注の文脈では、フォロワー1,000人未満でも案件相談は来ます。「何の専門家か」が明確であることのほうが、フォロワー数より重要です。

Step4: 問い合わせ・1次面談｜メール文例と面談で押さえる5項目

Step2 で作った30社リストに対して、実際にアプローチを実行するフェーズです。最初の1件にたどり着くまでに、30社へのアプローチで2〜5件の打診、1〜3件の1次面談、1件の契約、というのが現実的な歩留まり感です。

アプローチメールの基本構造

問い合わせフォーム経由・LinkedIn DM 経由・X DM 経由のいずれでも、基本構造は同じです。

件名: 業務委託のご相談｜[自分の専門分野]の[実績要約]

[企業名] [担当者名] 様

突然のご連絡失礼いたします。フリーランスエンジニアの[氏名]と申します。

貴社の[技術ブログ記事タイトル / 採用情報 / プロダクト紹介]を拝見し、
[自分の専門領域]の業務委託として貢献できる可能性を感じ、ご連絡しました。

[実績要約: 3行以内]
- [プロジェクト1]: [技術スタックと成果]
- [プロジェクト2]: [技術スタックと成果]

GitHub: [URL]
ポートフォリオ: [URL]
技術記事: [代表的なURL]

業務委託の余地がございましたら、一度オンラインでお話しさせていただけませんでしょうか。
ご検討のほど、よろしくお願いいたします。

ポイントは、「相手の何を見て」連絡したかを冒頭で示すこと、そして実績を3行以内に絞ることです。長文の自己紹介は読まれません。

1次面談で押さえる5項目

打診を受けて1次面談に進んだ際、エンジニア側から確認しておくべきことを5項目に絞ります。

1. 発注の動機と緊急度: なぜ今フリーランスを探しているのか。緊急度が高いほど契約までのスピードが上がります
2. 想定スコープと期間: 単発か継続か、月稼働何時間程度を想定しているか
3. 既存チームの体制: PM・他エンジニア・デザイナーがいるか、どのレイヤーを担当するか
4. 想定単価レンジ: 「予算感はどの程度を想定されていますか」と聞き、自分の希望レンジと突き合わせる
5. 意思決定者と決裁プロセス: 担当者の上に意思決定者がいるか、契約締結までに必要なステップは何か

これらを1時間の面談で確認できれば、その後の提案フェーズが圧倒的に楽になります。

典型的な失敗: 自分の実績を一方的に話して終わるパターン。1次面談は「相手の課題を理解する場」だと割り切ったほうが、提案が刺さりやすくなります。

Step5: 提案・契約締結｜見積もり・契約書のテンプレ整備

1次面談で相手の課題が見えたら、提案書と見積もりを準備します。エージェント経由では不要だった工程ですが、テンプレを一度作ってしまえば、2回目以降は30分〜1時間で準備できます。

提案書の構成

A4 で 2〜4 ページ程度の提案書を、PDF または Google スライドで用意します。

• 1ページ目: 課題理解の確認（面談で聞いた相手の状況を要約）
• 2ページ目: 提案内容（自分が担当する範囲・進め方・期間）
• 3ページ目: 見積もり（月額単価・想定稼働・契約期間）
• 4ページ目: 自己紹介・実績ハイライト

契約書テンプレ

業務委託契約書は、以下の項目を含む雛形を1つ用意しておきます。

• 業務内容・委託期間
• 報酬・支払条件（支払いサイト・締め日・振込手数料の負担者）
• 秘密保持・知的財産権の帰属
• 損害賠償の上限・免責事項
• 契約解除条件・更新条件
• 反社会的勢力の排除条項

専門家に1度レビューしてもらった雛形を持っておくと、毎回ゼロから作る必要がなく、安心して契約締結に進めます。

典型的な失敗: 「契約書は相手企業の雛形でいいや」と相手任せにするパターン。相手の雛形は当然相手有利に書かれています。自分の雛形を持って交渉のテーブルに乗せることが、対等な条件を引き出す第一歩です。

直接受注の信頼を支える4つの資産（GitHub・技術記事・SNS・ポートフォリオ）

Step1 で整備する信頼資産を、4つに分解して具体的な整備手順を見ていきます。先のステップ5項目を実行する前に、ここで紹介する資産が一定レベルに整っていることが、アプローチ・面談の成功率を左右します。

GitHub: プロフィール最適化と公開リポジトリの選び方

GitHub は「現役のコードが書けるか」を発注側が確認するために、最も多く見られる資産です。

プロフィール README（GitHub の特殊リポジトリ）

<自分のユーザー名> という名前のリポジトリを作り、README.md に以下を書きます。

• 専門分野（例: Web バックエンド開発、TypeScript / Go / Rust）
• 業務委託対応可否と稼働可能時間
• 主要な公開実績・技術記事へのリンク
• 連絡先（メール・X・LinkedIn）

Pinned リポジトリの選定

プロフィールに固定表示する「Pinned リポジトリ」を、4〜6本選びます。優先順位は以下のとおりです。

1. 自分が作ったオリジナルのプロダクト（小規模でも可）
2. OSS への継続的なコントリビューション
3. 技術検証・サンプル実装（README が丁寧に書かれているもの）
4. 業務委託で公開可能になっている成果物（NDA 範囲確認必須）

「スター数が少ないから」と公開リポジトリを隠す必要はありません。READMEが丁寧に書かれていれば、スター数1〜2でも「コードの品質」と「ドキュメント力」を伝えられます。

技術記事: Zenn / Qiita / 個人ブログの使い分け

技術記事は「検索流入経由で発見される」「面談時に話のきっかけになる」「専門性を客観的に示せる」の3つの効果を持つ重要な資産です。

直接受注の最初の1年は、Zenn または Qiita のどちらか1つに集中することをおすすめします。両方やろうとすると更新頻度が下がり、結果としてどちらも中途半端になります。

執筆する記事の方向性は、「自分の専門分野の Tips・トラブルシューティング・ベストプラクティス」が安全です。「フリーランス論」「営業論」を書く前に、まず技術記事で「コードが書ける人」というポジションを取りに行ってください。

SNS（X）: 直接受注に効く発信パターン

X（旧Twitter）は、フォロワー数よりも「専門性の明確さ」と「継続性」が直接受注に効きます。

プロフィール bio の整備

bio に含めるべき要素:

• 専門分野（例: バックエンドエンジニア / Go・TypeScript）
• 現在の活動（例: フリーランス / 業務委託受付中）
• 主要な実績（例: SaaS スタートアップでテックリード経験）
• 主要なリンク（GitHub・Zenn・ポートフォリオ）

発信パターン

直接受注に効く発信は、以下の3パターンが中心です。

「フォロワー数を増やす」ことが目的化すると、バズ狙いの抽象的な発信に流れがちです。直接受注を狙うなら、専門領域のフォロワー数百人で十分に案件相談は来ます。

ポートフォリオサイト: 作るべきか・最低限の構成

ポートフォリオサイトは「あったほうが良い」資産ですが、最優先ではありません。GitHub と技術記事が整い、Step4 のアプローチを実行する段階で「もう少し情報をまとめたページがあれば」と感じたら作る、という順序で十分です。

最低限の構成は以下のとおりです。

• トップページ（自己紹介・専門分野・連絡先）
• 実績一覧（プロジェクト3〜5件、各5行程度の要約）
• スキル一覧（技術スタック・経験年数）
• 連絡先（問い合わせフォーム or メールアドレス）

Vercel + Next.js で半日、Notion 公開ページなら1時間で立ち上がります。「サイト作成自体が信頼資産になる」と考えすぎず、情報のまとめ場所として割り切るのが効率的です。

コネゼロからの直接営業ファネル設計（プル型 × プッシュ型）

5ステップの中で、Step3（接点設計）と Step4（問い合わせ・面談）は、それぞれ性質の異なる営業活動です。前者は待ちの「プル型」、後者は攻めの「プッシュ型」と整理できます。直接受注を続けていくには、この2系統を組み合わせる必要があります。

プル型ファネル: SNS発信 → 技術記事流入 → DM・問い合わせ

プル型は、自分が「いる場所」に発注者が向こうから来てくれるファネルです。

SNS発信・技術記事 → 検索 / SNSタイムラインで発見 → プロフィール閲覧 → DM / 問い合わせ

特徴は以下のとおりです。

• 時間がかかる: 効果が出始めるまで3〜6ヶ月
• 質が高い: 相手が自分を選んで連絡してくるため、ミスマッチが起きにくい
• 継続性が高い: 一度立ち上がれば、発信を続ける限り問い合わせが入る
• 単価交渉に有利: 「他のエンジニアと比較」されにくく、希望単価が通りやすい

プル型は半年から1年スパンで育てる前提のため、「最初の1件」をプル型で取りに行くのは現実的ではありません。

プッシュ型ファネル: 求人ウォッチ → 直接メール → 面談

プッシュ型は、自分から発注候補にアプローチするファネルです。

ターゲット30社リスト → 個別アプローチメール → 1次面談 → 提案 → 契約

特徴は以下のとおりです。

• 即効性がある: 1〜3ヶ月で初受注の可能性がある
• 歩留まりが低い: 30社にアプローチして契約まで進むのは1件程度
• 疲弊しやすい: 返信なしや断りが続くと心理的負担が大きい
• 単価交渉が難しい: 他候補と比較される構造になりやすい

プッシュ型は短期決戦の手法です。週単位で動かないと、リストが古くなって機会を逃します。

最初の1件はプッシュ型、継続化はプル型の二段構え

実務的なおすすめは、次の二段構えです。

1. 最初の1件はプッシュ型で取る: Step2 で 30社リストを作り、Step4 で機械的にアプローチする。3ヶ月以内に最初の1件を狙う
2. 稼働しながらプル型を育てる: 最初の1件と並行して、SNS発信・技術記事の継続投稿を始める。6ヶ月後には、プル型からの問い合わせが月1〜2件入る状態を目指す
3. 2年目以降はプル型中心: 信頼資産が積み上がれば、プッシュ型のアプローチ数を減らしても問い合わせが入り続ける状態になる

「いきなりプル型」を狙うと、半年間収入がない状態に耐えられない可能性があります。プッシュ型で食いつなぎながら、プル型を育てる二段構えが現実解です。

初受注後の継続化と紹介展開｜単発で終わらせない設計

最初の1件を受注したら、それを「単発」で終わらせないことが、直接受注を持続可能にする鍵です。継続契約と紹介ルートを設計しておけば、半年後・1年後の営業負担が大幅に減ります。

単発案件を継続契約に切り出すヒアリング設計

単発案件を継続契約に発展させるには、プロジェクト終了の1ヶ月前から「次の課題」を聞き出すヒアリングを意識的に行います。

具体的には以下のような問いかけが有効です。

• 「今回の開発で見えてきた、次に取り組みたい課題は何でしょうか」
• 「運用フェーズに入った後の改善・拡張のロードマップはありますか」
• 「私が支援できる形があれば、引き続き関わらせていただきたいです」

「営業臭い」と感じるかもしれませんが、相手も「次の人を探す手間」を惜しんでいるケースが多く、自然な形で継続提案ができれば歓迎されます。プロジェクト終盤の振り返りミーティングが、この問いかけの自然な場になります。

既存クライアントから紹介を引き出す依頼の仕方

既存クライアントからの紹介は、最も信頼度が高く、契約までのリードタイムが短い案件獲得ルートです。紹介依頼は、プロジェクトが順調に進み、相手から好意的な評価を受けたタイミングで行います。

切り出し方の例:

• 「もし社内外で同じような課題を抱えている方がいらっしゃれば、ご紹介いただけると嬉しいです」
• 「業務委託で動けるエンジニアを探している方がいたら、お声がけください」

ポイントは、紹介を「重い依頼」にしないことです。「もしいたら」程度の温度感で、自然に伝えるだけで十分です。3〜4社で関係を構築できれば、年に1〜2件の紹介案件が入る状態を作れます。

紹介ルートで単価を下げない交渉

紹介経由の案件は、「知り合い価格」「お友達価格」で単価を下げられがちです。これを防ぐには、初回のヒアリング段階で次のような前置きをしておきます。

• 「通常、月稼働80時間で◯◯万円のレンジでお受けしています」
• 「ご紹介いただいた方には、他のクライアントと同じ条件でご提案しています」

紹介者の顔を立てつつ、市場単価を維持する。これが2年目以降のフリーランスエンジニアにとって、収入を安定させる重要な交渉力です。

直接受注でつまずきやすい4つの落とし穴と対処法

直接受注に踏み出した後、実務面で多くのフリーランスエンジニアがつまずくポイントを4つ整理し、それぞれの回避策を示します。

契約書なし稼働のリスクと最低限の書面

「信頼関係があるから契約書なしで OK」というのは、トラブルが起きていない期間だけ成立する話です。スコープの解釈違い・成果物の知的財産権・支払い遅延などは、契約書がない状態で起きると解決手段が極端に減ります。

最低限、以下の書面は揃えるべきです。

「契約書を交わすことが面倒で発注を渋られないか」と心配する必要はありません。むしろ契約書を出せるフリーランスのほうが、発注側から見て安心感があります。

支払いサイト・与信管理

直接受注では、支払いサイト（請求書発行から入金までの期間）が長いと、資金繰りが厳しくなります。フリーランス新法（後述）により60日以内に短縮される方向ですが、運用では「30日サイト」を交渉できるかが分岐点です。

与信管理のための実務的な工夫は以下のとおりです。

• 初回取引は1〜3ヶ月の短期契約から始め、支払い実績を確認してから長期契約に移行する
• 与信に不安がある相手には、月末締め翌月末払い（30日サイト）を依頼する
• 大口取引（月額100万円超）の場合は、与信調査サービスや帝国データバンクの簡易レポートを利用する

スコープ・工数管理

直接受注で最も多いトラブルが「スコープの拡大」と「工数の超過」です。エージェント経由では、エージェントが緩衝材になっていた部分を、自分で管理する必要があります。

対処の基本は以下のとおりです。

• 契約書にスコープを明記する: 「Webアプリの開発」ではなく「ログイン機能・管理画面・◯◯API の開発」のように粒度を上げる
• 追加要望は別見積もりで対応する: 「これも入れてほしい」と言われた瞬間に「個別見積もりとしてご提案します」と返す
• 稼働時間を週次で共有する: 上限時間を契約で定め、超過しそうな週は事前に相談する

「相手との関係を悪くしたくないから」と曖昧にすると、月末に「想定の倍以上働いていた」状態になります。早めの線引きが、長期的な関係を守ります。

フリーランス新法・インボイス対応

2024年11月1日に施行された「フリーランス・事業者間取引適正化等法」（フリーランス新法）は、直接受注のフリーランスにとって追い風となる法律です。発注事業者には以下の義務が課されます（政府広報オンライン、フリーランス・事業者間取引適正化等法リーフレット）。

• 書面交付義務: 業務内容・報酬・契約期間などを書面（またはメール等の電磁的方法）で明示する義務
• 報酬支払期日の制限: 発注した物品等を受け取った日から60日以内のできる限り短い期間内で支払期日を設定する義務
• 不当な行為の禁止: 受領拒否・報酬減額・返品・買いたたき等の禁止
• 募集情報の的確表示・育児介護等への配慮・ハラスメント対策

書面交付義務やインボイス対応の実務的な準備事項は、フリーランス新法の対応ポイントで整理しています。書面の保管・請求書フォーマットの整備など、稼働前に揃えておくべき準備を確認しておいてください。

インボイス制度との関係では、適格請求書発行事業者として登録するか否かが論点になります。発注側が課税事業者である場合、適格請求書を発行できないと相手側で消費税の仕入税額控除ができないため、契約条件の交渉で不利になることがあります。事業規模・取引先の構成を踏まえ、税理士に相談したうえで判断するのが安全です。

よくある質問

直接受注を始めるうえで、フリーランスエンジニアの皆さんからよく寄せられる質問を整理します。

Q1. 副業の状態から直接受注はできますか？

可能です。むしろ「副業状態のうちに、土日や夜の時間を使って直接受注の小さな案件を獲得しておく」のは、独立前のリスクヘッジとして優れた戦略です。月10〜20時間の小規模案件から始めて、稼働実績と人脈を積み上げてから独立に踏み切ると、独立直後の収入の谷を回避しやすくなります。

Q2. 直接受注の単価交渉、相場感はどう掴めばいいですか？

公開されている調査データを複数組み合わせて、相場感の輪郭を作るのが現実的です。例えば、フリーランスエンジニア向けマッチングサービスの定点調査では、2025年12月時点の月額平均単価は78.3万円と報告されています（エン・ジャパン プレスリリース）。同種の調査を3〜5本確認し、自分の経験年数・技術スタック・職種別の中央値を掴むのが第一歩です。そのうえで、エージェントから提示されている自分の単価に手数料分（15〜25%）を上乗せした金額が、直接受注での適正単価レンジの目安になります。

Q3. エージェントとの併用はOKですか？

多くのエージェントで併用は許容されています。ただし、エージェント経由の案件で稼働している期間中に、同じクライアントから直接契約の話を持ちかけられた場合、エージェントとの契約上「引き抜き条項」に抵触する可能性があるため、契約書の該当条項を必ず確認してください。新規の直接案件をエージェント案件と並行で持つこと自体は、ほぼ問題ありません。

Q4. 直接受注のほうが本当に手取りが増えますか？

単純な手取り比較では増えるケースがほとんどです。ただし、営業時間・契約管理・経理処理に費やす時間も含めた「時間あたり実質報酬」で比較すると、初年度は同等か若干低くなることもあります。2年目以降、プル型ファネルが機能し始めると、営業時間が減って実質報酬がエージェント経由を上回るのが一般的な軌道です。

Q5. 直接受注は法人化したほうが有利ですか？

年商1,000万円を超えるあたりから、法人化のメリット（節税・対外信用・社会保険）が見え始めます。直接受注を始めたばかりの段階では、個人事業主のまま青色申告で進めるのが事務負担が軽く、有利です。法人化の判断は税理士に相談しながら、年単位で見直していくのが安全です。

まとめ｜今週から始める直接受注の3アクション

ここまでフリーランスエンジニアの直接受注を、エージェント経由との違い、発注側の需要パターン、コネゼロから始める5ステップ、信頼資産の整備、プル × プッシュのファネル設計、継続化・紹介展開、そして契約リスクの回避策まで一通り見てきました。

最後に、この記事を読み終えた今週から着手できる「3つのアクション」に集約します。

1. GitHub プロフィールを30分で整備する: プロフィール README に「専門分野」「業務委託対応可」「連絡先」を書き、Pinned リポジトリを4本選んで固定する
2. ターゲット候補10社のリストアップを始める: Wantedly・Green・カンファレンス登壇企業から、自分が貢献できそうな10社を選び、スプレッドシートに記録する
3. 技術記事を1本書いて公開する: Zenn または Qiita で、自分の専門分野の Tips を2〜4時間で1本書き、X で告知する

最初の1件にたどり着くのは、3ヶ月先かもしれません。ただ、今週の30分の GitHub 整備と、来週の10社リスト化を実行しているかどうかで、3ヶ月後の景色は確実に変わります。

「直接受注はコネがある人だけのもの」という思い込みは、需要側の事情を知るだけで崩れます。あとは順序通りに動くだけです。Workee は、フリーランスエンジニアの皆さんの「次の1件」を支える情報発信を続けています。今後も契約・営業・継続化のリアルな実務を発信していきますので、ぜひ参考にしてください。