Antigravity エージェントを商品化して売る完全ロードマップ — 個人開発者がAgentKit 2.0で月収を作る90日設計図

前編のAgentKit 2.0 で作ったAIエージェントを売る5つの収益化パスで、5つの配布チャネルの長所と落とし穴をお話ししました。この記事はその続編で、「実際に商品として完成させ、初の収益を上げるまで」の90日ロードマップを具体化します。

私が複数のエージェントを動かして痛感したのは、AgentKit 2.0 で技術的に動くエージェントを作るのは、商品化全体の20%程度の作業に過ぎないということです。残りの80%は、価格設計、配布チャネル選び、ランディングページ、決済、ユーザーオンボーディング、運用改善です。「動くエージェントを作る」と「売れるエージェントを作る」の間には、明確な境界線があります。

この記事は、私がもう一度0からエージェント商品をローンチするならこうやる、という具体的な90日ロードマップです。

なぜ2026年が「個人がエージェントで稼ぐ」最適期なのか

AgentKit 2.0 と Gemma 4 のローンチ以降、個人がエージェントを作る速度と買い手側の理解がほぼ同時に成熟しました。1年前は技術はあっても買う側が「エージェント」という単語の意味を分かっていませんでした。今は、消費者も法人も「AIエージェント」がどういうものかを理解した上で価格を見られます。

加えて、Antigravity の上で動くマルチエージェント構成（複数のエージェントが連携してタスクを完結させる）が現実的に作れるようになりました。これは個人開発者にとって**「1人で大企業のAI部門が出すような商品」を作れる**ことを意味します。今のうちに先行者として商品を出しておくと、来年以降の競合が増えてきても優位を保てます。

Phase 1（Day 1-15）— エージェントを『商品』として設計する

エージェント開発で最も多い失敗が、技術ありきで作ってしまい、ユーザーが買う理由を後付けしようとして詰むパターンです。最初の2週間は技術を1行も書かず、商品設計のみに使ってください。

5つの判断軸でエージェントを定義する

私が必ず最初に書くテンプレートがあります。次の5項目を、絞った言葉で1ページに収めるところから始めます。

誰の何を解決するか: 「個人のEC運営者が、商品ページの英訳に毎月10時間費やしているのを、月¥1,000で30分に短縮する」のような具体性
既存の選択肢と何が違うか: ChatGPT・Claude・既存翻訳ツールではダメな理由を1文で説明できるか
エージェントが行う具体的なステップ: 入力→処理→出力の各段階を箇条書きで明示
失敗するケースと対処: 入力が想定外のとき、エージェントがエラーで止まるとき、どう振る舞うか
値付けの根拠: 解決する時間 × ユーザーの時給 × 妥当な利益率 = 価格

これが書けるまで、コードは1行も書きません。書けないなら、それは商品としてまだ未成熟だということです。

マルチエージェント or シングルエージェントの判断

AgentKit 2.0 ではマルチエージェント構成が組みやすいですが、最初の商品は必ずシングルエージェントから始めてください。マルチエージェントは複雑度が指数的に上がり、デバッグが難しく、ユーザーへの説明も複雑になります。

私は最初の商品でマルチエージェント構成にしてしまい、3週間デバッグに費やしました。シングルエージェントなら2日で済んだ機能です。

Day 15時点の成果物

5項目テンプレートが埋まった1ページの商品定義書
競合3社のURLと差別化ポイント
価格仮説（前編の5パスのうちどれを選ぶか含む）
ターゲットユーザー1人の具体的な人物像

Phase 2（Day 16-30）— 本番運用に耐える AgentKit 2.0 実装

Phase 2では、本番運用を見据えた実装を2週間で完成させます。重要なのは「動くだけ」ではなく「壊れにくい」ことです。

推奨スタック

エージェント基盤: Antigravity AgentKit 2.0
モデル: Gemini 2.5 Flash（デフォルト）+ Pro（プレミアム機能のみ）+ Gemma 4（ローカル/オンプレ向けオプション）
バックエンド: Next.js 16 + Cloudflare Workers
DB: Cloudflare D1 / KV
認証: NextAuth.js
決済: Stripe Checkout

エージェント呼び出しのエラー処理

本番運用で最も多いエラーは「外部API呼び出しが途中で失敗する」ものです。AgentKit 2.0 のエージェントは複数のツールやモデル呼び出しを内部で行うため、失敗しやすい箇所が多くあります。

import { Antigravity } from '@google/antigravity-agent-sdk';
 
const ag = new Antigravity({ apiKey: process.env.ANTIGRAVITY_API_KEY });
 
async function runAgent(input: AgentInput, opts: { retries?: number } = {}) {
  const maxRetries = opts.retries ?? 3;
 
  for (let attempt = 1; attempt <= maxRetries; attempt++) {
    try {
      const session = await ag.agents.create({
        agentId: 'translation-agent',
        inputs: input,
        timeout: 60_000,
      });
 
      const result = await session.waitForCompletion();
 
      if (result.status === 'failed') {
        throw new Error(`Agent failed: ${result.error}`);
      }
 
      return result;
    } catch (e: unknown) {
      // リトライ可能なエラーかを判定
      const retryable = isRetryableError(e);
      if (!retryable || attempt === maxRetries) {
        await logAgentError({ input, error: e, attempt });
        throw e;
      }
 
      // 指数バックオフ
      await sleep(Math.pow(2, attempt) * 1000);
    }
  }
}
 
function isRetryableError(e: unknown): boolean {
  if (!(e instanceof Error)) return false;
  return /timeout|503|429|network/i.test(e.message);
}

このリトライ + エラーログの構造は、本番運用が始まる前に必ず入れてください。私は最初これを省略して、ユーザー1人につき月10件のエラー報告対応に追われました。

コスト制御の最低限実装

エージェントは1回の実行で複数のモデル呼び出しをするため、原価が予想以上に膨らみます。次の3点を最初から実装してください。

1ユーザー1日あたりの実行回数上限: DBにカウンターを置く
1回の実行あたりの最大トークン数上限: 暴走を防ぐ
モデルの自動選択: 簡単な入力にProを使わない

async function selectModel(input: string): Promise<string> {
  const inputLength = input.length;
 
  // 簡単な入力は Flash で十分
  if (inputLength < 1000) return 'gemini-2.5-flash';
 
  // 中程度の長さは Flash + 構造化指示
  if (inputLength < 5000) return 'gemini-2.5-flash';
 
  // 長文や複雑な指示のみ Pro
  return 'gemini-2.5-pro';
}

Day 30時点の成果物

動作するエージェント（リトライ・エラー処理込み）
ユーザー認証
1日5回までの無料試用枠
内部的なログとモニタリング

Phase 3（Day 31-45）— 配布チャネルの選定と実装

前編で説明した5つの配布パスから、最初は1つに絞って実装します。私が個人開発者に最も推奨するのは、自社サイトでの直接販売 + マーケットプレイス出品の併用です。

自社サイト側の最低限実装

商品ページ、決済ページ、エージェント実行ページの3つを作ります。商品ページの構成は次の通りです。

ヒーローセクション: 「誰の何を解決するか」を1文で
デモ動画/スクリーンショット: 実際にエージェントが動く30秒動画
使い方の3ステップ: 入力→実行→結果のフロー
価格表: 1回購入・月額Pro・買い切りPremium
FAQ: 開発者が実際につまずくポイント1〜2問だけ
CTA（お申込みボタン）: ヒーロー直下と価格表直下に2回

マーケットプレイス出品の準備

Antigravity 公式マーケットプレイス（または周辺の第三者マーケットプレイス）に出品するときは、以下を揃えます。

エージェント説明文: 100文字程度で機能を説明
アイコン: 256×256 のシンプルなロゴ
デモGIF: 5〜10秒の動作デモ
価格設定: 自社サイトと同じか、やや安め（マーケットプレイス手数料を吸収）
サポート連絡先: メール or Slack コミュニティへのリンク

ここで重要なのは、自社サイトとマーケットプレイスで価格を全く同じにしないことです。マーケットプレイスは流入用の入口と割り切って、コアな機能は自社サイトの月額に置きます。これで両チャネルが食い合わずに済みます。

Day 45時点の成果物

商品ページが完成し、自社サイトで決済ができる
マーケットプレイス出品（審査待ち含む）
Webhook によるStripe決済結果のハンドリング
友人2〜3人による有料プラン購入テスト

Phase 4（Day 46-60）— Stripe統合と価格テスト

Phase 4では、本格的な決済統合と最初の価格テストを行います。

個人エージェントの3層プラン

私が推奨するのは次の構成です。

1回購入（Tip / One-shot）: ¥250〜¥500、エージェントを1回だけ使いたい人向け
月額Pro: ¥980〜¥1,980、定期的に使う個人向け
買い切りPremium: ¥4,800〜¥9,800、長期的に使う & サブスク嫌いユーザー向け

エージェントは「1回使えば結果が出る」タイプの商品なので、サブスクより1回購入や買い切りが売れやすい傾向があります。最初から3層併売することで、ユーザーの心理的なハードルに応じた選択肢を提供できます。

Stripe Checkout の実装

// app/api/checkout/route.ts
const session = await stripe.checkout.sessions.create({
  mode: planType === 'one-shot' ? 'payment' : 'subscription',
  line_items: [{
    price_data: {
      currency: locale === 'ja' ? 'jpy' : 'usd',
      unit_amount: priceMap[planType][locale],
      recurring: planType === 'monthly' ? { interval: 'month' } : undefined,
      product_data: {
        name: productNames[planType][locale],
        description: productDescriptions[planType][locale],
        images: ['https://yourdomain.com/images/agent-product.png'],
      },
    },
    quantity: 1,
  }],
  metadata: {
    userId: user.id,
    planType,
    agentId: 'translation-agent',
  },
  success_url: `${origin}/${locale}/agent/${agentId}?thanks=${planType}`,
  cancel_url: `${origin}/${locale}/agent/${agentId}`,
});

metadata.agentId を入れておくのは、後から複数のエージェントを売るときに「どのエージェントが買われたか」をWebhookで判別するためです。

Webhook での権限付与

// app/api/stripe/webhook/route.ts
if (event.type === 'checkout.session.completed') {
  const session = event.data.object;
  const planType = session.metadata.plan_type;
  const userId = session.metadata.userId;
  const agentId = session.metadata.agentId;
 
  switch (planType) {
    case 'one-shot':
      await grantOneShotAccess({ userId, agentId, expiresAt: addDays(new Date(), 1) });
      break;
    case 'monthly':
      await grantSubscription({ userId, agentId, plan: 'monthly' });
      break;
    case 'lifetime':
      await grantLifetimeAccess({ userId, agentId });
      break;
  }
}

Day 60時点の成果物

3層プラン全ての決済が動作
決済完了後の権限付与とお礼バナー
Stripe ダッシュボードでの売上確認

Phase 5（Day 61-75）— ローンチ準備とPR

ここまでで「動くエージェント + 商品ページ + 決済」が揃いました。次の2週間でローンチ準備をします。

ローンチ前のチェックリスト

ローンチ前に必ず確認すべきことを箇条書きで挙げます。

商品ページのコピーが「ユーザーの悩み」から始まっているか
デモ動画が30秒以内で、価値が伝わるか
価格表が3層になっており、ユーザーの心理的選択肢になっているか
FAQ が必要最小限（1〜2問）に絞られているか
決済フローが本番モードで動作確認済みか
解約フローが実装されているか（サブスクの場合）
メール通知が動作するか（決済完了、解約、エラー時）
エージェントの実行ログが保存され、ユーザーが過去履歴を見られるか
カスタマーサポートの連絡先が明記されているか

コミュニティへの告知

個人開発者がローンチ時に必ずやるべき発信は以下です。

X（旧Twitter）でのローンチ投稿: スクリーンショット付き、デモGIF付き
note や Zenn での技術記事: 開発過程の振り返り
Linktree への追加: 既存のSNSフォロワーへの告知
マーケットプレイスでの「新着」枠への露出: 出品時のオプションを確認
個人ブログでのローンチ記事: SEOへの貢献

私の場合、X でのローンチ投稿が想定の3倍リツイートされたことで初日に5件の購入がありました。これは運の要素もありますが、ローンチ投稿のスレッドを「開発の苦労」「個人開発者ならではの工夫」「価格設定の理由」の3部構成にすると拡散しやすいです。

Day 75時点の成果物

ローンチチェックリストが全てクリア
ローンチ投稿の準備（テキスト・画像・動画）
初の有料ユーザー獲得（運がよければ5〜10名）

Phase 6（Day 76-90）— 運用と改善ループ

Phase 6では、ローンチ後の運用と継続的な改善のループを作ります。

観察すべき3つの指標

ローンチ後、私が毎日見るのは次の3つです。

新規ユーザー数: 自社サイト + マーケットプレイス合算
転換率: 訪問者のうち課金に至った割合
エラー率: エージェントが想定通りに動作しなかった割合

転換率が1%を切る場合、商品ページかデモ動画に問題があります。エラー率が5%を超える場合、エージェントの実装に問題があります。これらの数字を毎日見ることで、改善の優先順位が自然と決まります。

価格テストの実践手順

ローンチから1ヶ月後、価格テストを始めます。

2週間ごとに、Premium価格を¥500〜¥1,000ずつ上下: 解約率と新規購入率を観察
キャンペーン価格の出し方: 「期間限定¥1,480」のようなバナーで転換率を測定
3ヶ月後、ヘビーユーザー向けの追加プランを設置: 月額Proの上限を超えるユーザー向け

撤退ラインの設定

これは個人開発で最も大切なのに最も無視されがちな要素です。私は次のいずれかが3ヶ月続いたら撤退、と決めています。

月の純利益がインフラ費を割る
週次の運用時間が10時間を超える
ローンチから3ヶ月経っても月¥10,000の売上に届かない

エージェント商品は「ぱっと見魅力的だけど誰も使わない」というケースが多発します。3ヶ月で売上が立たないものは、ピボットか撤退の判断を下してください。サンクコストに縛られないことが、長く続けるための最大のコツです。

Day 90時点の到達点

1日30分以下の運用負荷
純利益・時間・心の3軸ダッシュボード
改善ループ（新規ユーザー、転換率、エラー率の毎日確認）
月収¥30,000〜¥80,000程度（運がよければ）

エージェント商品化で私が学んだ3つの教訓

最後に、私が複数のエージェント商品を出してきて学んだ教訓を3つ。

教訓1: 「複雑なエージェント」は売れない

技術者は複雑なマルチエージェント構成に魅力を感じますが、ユーザーは『1つの明確な仕事を、毎回確実にやる』エージェントに課金します。複雑なものは「説明できない」=「売れない」です。商品名・説明・価格すべてが、3秒で理解できるシンプルさを目指してください。

教訓2: コミュニティを作るのが実用的の防御

個人開発のエージェント商品は、いつか必ず大手の汎用エージェントと競合します。そのときに守ってくれるのは、ユーザーコミュニティです。Discord か Slack で月1回でもユーザーミーティングをやることで、競合がコピーしても乗り換えられない関係性を作れます。私の場合、これを早期に始めたエージェントだけが2年目まで生き残りました。

教訓3: モデル切り替えは半年に1回

Gemini や Claude のモデルは半年ごとにアップグレードされます。新モデルの方が安く、賢いことが多いので、半年に1回、本番のモデル指定を見直すルーチンを入れてください。これだけで原価が10〜30%下がります。私は3ヶ月に1回見直しています。

90日のロードマップは、あくまで「最短ルートの一例」です。本業がある人は倍の180日かけても問題ありません。速度より、続けられる構造を優先してください。

エージェント時代の収益化は、技術と販売の両輪が必要です。技術だけ得意な人も、販売だけ得意な人も、片輪では遠くまで走れません。両方を学ぶ覚悟を持った個人開発者だけが、この時代の本当の果実を手にできます。

明日、Phase 1の5項目テンプレートから始めてみてください。1週間後の自分は、今の自分より少しだけエージェント商品化に近づいています。