受託の全体フロー — 初回連絡から月額運用まで
Antigravity 受託案件は、初回問い合わせから月額運用フェーズに入るまで、概ね次の8ステップで進みます。ここで扱うのは各ステップで個人開発者がぶつかる実務上の壁と、それぞれの対処パターンをご紹介します。
| ステップ | 期間目安 | 主な成果物 |
| 1. 初回ヒアリング | 1日〜1週間 | 案件メモ |
| 2. 概算見積り | 2〜3日 | 価格レンジの提示 |
| 3. 要件定義 | 1〜2週間 | A4 仕様書(3〜5枚) |
| 4. 契約締結 | 3〜7日 | 業務委託契約書 |
| 5. 開発 | 2〜6週間 | 実装物・動作デモ |
| 6. 受入テスト | 1〜2週間 | 受入合意書 |
| 7. 納品・初期運用 | 1〜2週間 | 運用マニュアル |
| 8. 月額運用フェーズ | 継続 | 月次レポート |
それぞれのステップを順番に見ていきます。
ステップ1: 初回ヒアリング — 「自動化の境界」を最初に聞く
初回のヒアリングでもっとも重要なのは、「人間が担当し続ける部分」と「自動化したい部分」の境界を確認することです。Antigravity エージェントは「全部自動化できそうに見える」ので、クライアントの期待が膨らみやすい領域です。
私が初回ヒアリングで必ず聞いている質問は次の5つです。
第一に、「この業務を毎日・毎週・毎月、誰が、どれくらいの時間かけて行っていますか」と聞きます。これで業務のボリューム感と、自動化による時短効果のおおよその金額換算ができます。
第二に、「自動化されたら、その時間で何をしたいですか」と聞きます。これは表面的な質問に見えますが、答えに窮するクライアントは「実は自動化を本気で求めていない」可能性があります。
第三に、「過去にこの業務を自動化しようとしたことはありますか」と聞きます。あった場合、なぜ続かなかったかを聞くと、技術的な失敗より人間側の運用課題が見えてきます。
第四に、「この業務でいちばん起きてはいけないミスは何ですか」と聞きます。これが、自動化の精度設計とエラーハンドリング設計の根拠になります。
第五に、「予算感を伺ってもよろしいですか」と直接聞きます。最初に予算レンジを共有してもらえると、その後の見積りでの認識ズレを防げます。
ステップ2: 概算見積り — 価格を「3層」で積み上げる
価格設定は受託で最も悩む部分です。私が使っている価格の積み上げロジックは、「初期構築費」「月額運用費」「想定リスクバッファ」の3層です。
初期構築費の計算
初期構築費 = (実装工数 × 時間単価) + (要件定義工数 × 時間単価) + (検証工数 × 時間単価) × 1.2(バッファ)
時間単価は個人で受ける場合、Antigravity の専門性込みで¥8,000〜¥15,000/時間が現実的なレンジです。これより安いと、運用負荷で精神的に追い詰められます。
月額運用費の計算
月額運用費 = (月次対応工数の上限 × 時間単価) + (Antigravity / Gemini API 想定コスト × 1.5)
API コストにバッファを乗せるのは、ユーザーの想定外利用で API コストが膨らんだときに、自分の負担にならないようにするためです。
提示価格の作り方
クライアントに提示するときは、上記2つを足したうえで、最終的に初期費用と月額の比率を3対1〜5対1にするのが、心理的に受け入れられやすい比率です。たとえば初期¥30万なら月額¥6万〜¥10万、というイメージです。
ステップ3: 要件定義 — A4で3〜5枚に収める
要件定義書は、長くしすぎないのが鉄則です。クライアントが読んで理解できる分量に抑えます。私のテンプレートは次の構成です。
- 背景と目的: なぜこの自動化が必要か(半ページ)
- 対象業務の現状: 現在どんな手順で行われているか(1ページ)
- 自動化後のフロー: Antigravity エージェントが何をするか、人間が何を確認するか(1ページ)
- 入出力の仕様: どんなデータを入れたら、どんなデータが返るか(1ページ)
- 例外処理: エラー発生時の挙動(半ページ)
- 運用体制: 誰が日々の運用を見るか、月次レポートの内容(半ページ)
このテンプレートを使うと、A4で3〜5枚に自然と収まります。10ページを超える要件定義書はクライアントが読まないので、最終的に「思っていたのと違う」と言われる確率が上がります。
ステップ4: 契約締結 — 個人開発者が必ず入れるべき5条項
業務委託契約書は、テンプレートをそのまま使うのではなく、Antigravity 受託に固有の5条項を必ず入れます。
条項1: 検収基準の明示
「成果物が要件定義書記載の入出力仕様を満たした時点で検収完了とする」と明記します。これがないと、クライアントの主観で「まだ完成していない」と言われ続けるリスクがあります。
条項2: 仕様変更の追加費用
「契約締結後の要件追加・変更については、別途見積りを提示し合意のうえで実施する」と明記します。これがないと、後から無償で機能追加を求められます。
条項3: API 仕様変更時の責任範囲
「外部 API(Gemini API、Antigravity プラットフォーム等)の仕様変更により成果物が動作しなくなった場合の対応は、月額運用費の範囲内で実施します。ただし、抜本的な再設計を要する変更は別途見積り対象とする」と明記します。Antigravity のような新しいプラットフォームでは、半年に1度のペースで仕様変更が起きます。
条項4: データ取り扱いと守秘
「業務遂行に伴って取得したクライアントの業務データは、契約期間中および終了後5年間、第三者に開示しない」と明記します。Antigravity に渡すデータの取扱いは、クライアントの業界によって規制が変わるので、事前確認が必須です。
条項5: 解約条件
「月額運用契約は、双方とも30日前の書面通知により解約できる」と明記します。これがないと、解約時にクライアントから「次の業者が決まるまで延長してほしい」と言われ続けます。
ステップ5〜6: 開発と受入テスト — 「動くデモ」を中間で見せる
開発期間中に最も重要なのは、1〜2週間に1度、動くデモをクライアントに見せることです。最終納品まで一切見せないと、納品時に「思ったのと違う」と言われる確率が劇的に上がります。
Antigravity エージェントの場合、動作デモには Web UI を作る必要があるので、私は最初から gradio や Streamlit のような最小限の UI を立ち上げて、クライアントが自分で触れるようにしています。これだけで認識ズレが大幅に減ります。
受入テストは、クライアント自身に運用を想定したシナリオで触ってもらうのが鉄則です。エンジニア視点でテストケースを書くと、現場で実際に起きることを見落とします。
ステップ7: 納品 — 運用マニュアルで自分を守る
納品時に必ず作るのが、1ページの運用マニュアルです。これがないと、納品後の問い合わせが「使い方が分からない」レベルから始まり、月額運用費の中で消化される時間が膨大になります。
運用マニュアルに書くのは次の5項目です。
- エージェントが自動で動くタイミング(毎日朝9時、など)
- 人間が確認すべきポイント(エージェントが返した結果のうち、確認が必要なケース)
- エラーが出たときの対処(自分で再起動できる範囲)
- 連絡先と対応時間(月額運用費の範囲内であることを明記)
- 月額運用費に含まれないこと(仕様追加、新機能、深夜対応など)
5番目が特に重要です。これがないと、何を依頼されても「月額の中で対応すべき」と思われがちです。
ステップ8: 月額運用フェーズ — 受託の本当の利益はここから
多くの個人開発者が見落としているのが、月額運用フェーズが受託案件の真の収益源である点です。初期構築の利益率は20〜40%程度ですが、月額運用は工数が安定すれば利益率70〜90%まで上がります。
月額運用で起きる3つのトラブルと対処
トラブル1: スコープ拡大の依頼
「ついでにこれも自動化してくれない?」という依頼は、丁寧に断るのが鉄則です。「現契約のスコープ外なので、追加見積りを作成いたします」と返します。1度受けると2度目が来るので、最初に線を引きます。
トラブル2: 外部 API の仕様変更
Gemini API も Antigravity も、年に数回は破壊的変更が起きます。月額運用費の範囲内で対応すべきものと、別途見積りすべきものの線引きを、契約条項3に従って判断します。具体的には、実装が10時間以内で済むなら月額内、それ以上なら別途見積りを目安にしています。
トラブル3: 担当者の交代
クライアント側の担当者が交代すると、引き継ぎが不十分で「最初から説明してほしい」となることが多いです。これも30分以内なら月額内、それ以上は別途見積りで対応します。新担当者向けのオンボーディング資料を別途販売する形(¥3万〜¥5万)も実務的です。
月次レポートの作り方
月額運用費に見合った価値を感じてもらうには、月次レポートが効きます。レポートに書くのは次の3項目です。
- 当月のエージェント実行回数と成功率
- 想定される時短効果(時間 × 時給換算)
- 改善提案1件(次月の追加見積りにつながる種)
このレポートがあるかないかで、解約率が大きく変わります。私の経験では、月次レポートを送ったクライアントは平均1.5年継続するのに対し、送らなかったクライアントは平均8ヶ月で解約します。
受託案件の年間計画 — 個人開発で年収¥1,000万を狙う場合
Antigravity 受託で年収¥1,000万を目指す場合の現実的な計画は、次のような構成になります。
| 内訳 | 件数 | 単価 | 年間 |
| 初期構築(パターン1: 営業自動化) | 4件 | ¥40万 | ¥160万 |
| 初期構築(パターン2: 経理自動化) | 3件 | ¥50万 | ¥150万 |
| 初期構築(パターン3: マーケ量産) | 6件 | ¥20万 | ¥120万 |
| 月額運用(13社合計) | 13社 | 平均¥4.5万/月 | ¥702万 |
| 合計 | | | ¥1,132万 |
ポイントは、初期構築だけで¥1,000万を目指すと案件数が多すぎて回らないことです。月額運用フェーズの積み上げが、年間収益の半分以上を占める設計にする必要があります。
受託1年目から SaaS 化への移行プラン
受託で1年活動して、月額運用が10社以上溜まってきたら、SaaS 化を検討するタイミングです。移行プランは次の3段階で進めるのがスムーズです。
第一段階(受託1年目後半)は、複数のクライアントに共通する機能を抽出し、内部的に共通モジュール化します。これだけで月額運用の工数が減ります。
第二段階(受託2年目前半)は、共通モジュールを Web 上で公開し、新規受注は「カスタマイズ可能な SaaS」として位置づけます。価格は受託より安く、月額¥5万→¥3万に下げる代わりに、初期構築費を¥30万→¥10万に下げます。
第三段階(受託2年目後半以降)は、完全 SaaS として独立させ、新規受注を停止します。既存クライアントは特別契約として継続しつつ、新規顧客には SaaS のセルフサーブモデルを案内します。
この3段階移行を経ることで、受託で築いた関係性を SaaS に流用しつつ、徐々にレバレッジの高いモデルに移行できます。
個人開発者の視点から(実体験メモ)
さいごに
Antigravity 受託案件は、技術的な難易度よりも、価格設定・契約・運用設計の実務が成否を分けます。最初の3案件で「価格を上げ切れない」「契約条項が曖昧」「運用負荷が膨らむ」のいずれかで疲弊する方が多いですが、この記事のフローに沿って準備を進めれば、その大半は防げます。
ご自身の最初の受託案件を、この記事のテンプレートを使って始めてみてください。来週中にクライアント候補を3名リストアップし、再来週中に1社目との初回ヒアリングを設定するところから始めるのが、もっとも現実的な進め方です。