AgentKit 2.0 で作ったAIエージェントを売る5つの収益化パス — 個人開発者が選ぶべき販売チャネルの判断軸

アプリの課金まわりを見直していた夜、私は「ストア経由の売上」と「自社サイト経由の売上」を同じ表に並べて、思わず手が止まりました。手元に残る額も、お客さまの顔が見えるかどうかも、まるで違ったのです。

エージェントを作り終えたあとに待っているのは、これとまったく同じ分かれ道です。どこで売るかによって、運営の手間も、収益の上限も、学べることも変わります。

最初にお伝えしたいのは、技術より先に「誰と、どんな距離で取引したいか」を決めると、チャネルは自然に絞れるということです。5つのパスを判断軸つきで整理し、自社販売で必要になる課金コードと利用上限の設計まで書き残します。

なお、特定のマーケットプレイスの手数料率や審査条件は変わります。本文の数字は考え方を示す例であり、実際の出品前には必ず各公式の規約をご確認ください。

5つのパスを比べる前に、物差しを3本決めます

比較表を作る前に、物差しを先に決めておくと迷いません。私が使っているのは次の3本です。

• 手取りの割合: 売上のうち、手数料と原価を引いて手元に残る割合
• 顧客との距離: 解約理由や要望を直接聞けるか
• 立ち上がりの速さ: 最初の1円が入るまでの期間

パス1 — エージェントマーケットプレイスへの出品

公式または周辺のマーケットプレイスに出品し、利用に応じた収益を受け取る形です。App Store や Google Play のエージェント版と考えると分かりやすいでしょう。

向いているのは、翻訳・要約・文書整形のように業界を選ばない汎用エージェントです。集客の仕組みを持たない個人にとって、流入を連れてきてくれる点は大きな助けになります。

一方で、手数料がかかる代わりに、ユーザーの顔が見えません。解約理由も、次に欲しい機能も、ストア越しにはほとんど届かないのです。

ストアアプリを長く運用してきた経験から言えば、この「顔が見えない」という性質は、レビュー欄の短い一文を頼りに改善を重ねるような作業になります。入り口として使い、メールアドレスや自社サイトへの導線を規約の範囲で設けておく——それが私の線引きです。

パス2 — 自社サイトでの直接販売

自分のドメインでエージェントをホストし、Stripe などで直接課金する形です。手数料は決済代行の分だけになり、価格設計も解約導線も自分で握れます。

代わりに、集客はすべて自分の仕事です。ブログや SNS で読者を抱えていない状態から始めると、最初の数か月は売上がほとんど立たないと覚悟しておく必要があります。

課金の入り口は、次のように小さく作れます。Checkout Session を作り、どのユーザーのどのプランかを metadata に残しておくだけです。

import Stripe from "stripe";
 
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!);
 
export async function POST(req: Request) {
  const { userId, priceId } = await req.json();
 
  const session = await stripe.checkout.sessions.create({
    mode: "subscription",
    line_items: [{ price: priceId, quantity: 1 }],
    success_url: "https://example.com/billing/success",
    cancel_url: "https://example.com/billing/cancel",
    client_reference_id: userId,
    subscription_data: { metadata: { userId } },
  });
 
  return Response.json({ url: session.url });
}

エージェント本体の呼び出しは、お使いの SDK や API に合わせて差し替えてください。肝になるのは、課金の確認と利用回数の記録を、エージェントを起動する前に必ず通すことです。この順序は後半の「利用上限」で詳しく扱います。

Next.js と Cloudflare Workers の上に Stripe を載せる実装は、Antigravity で SaaS を作る Stripe 連携ガイドに手順をまとめています。

パス3 — 既存 SaaS への組み込み

Slack や Notion、Shopify などのアプリストアを通じて、相手のサービス内で動くエージェントを配布する形です。

利用者層が明確で、エージェントが単体では使いにくい——そういう道具ほど、このパスで価値が出ます。個人にとっては、1つのプラットフォーム上の少数の法人ユーザーだけで成り立つ点が魅力です。

注意したいのは、導入までの時間です。法人の稟議を通すには数週間から数か月かかることが珍しくなく、即売上が立つマーケットプレイスとは速度がまるで違います。審査・手数料・データの扱いは各プラットフォームの規約に従うことになるため、依存先が方針を変えたときの逃げ道も、あらかじめ考えておきたいところです。

パス4 — 受託から商品化へ

最初は企業向けの受託としてエージェントを作り、複数案件に共通する部分を切り出して製品にする形です。キャッシュフローが最も早く、お客さまの現場の言葉を直接聞けます。

進め方は次の順序です。

1. 1社目の受託で、現場の業務をそのまま自動化します
2. 同じ業界の2〜3社に展開し、共通する要件を棚卸しします
3. 共通部分だけを切り出して、汎用の製品にします
4. 製品版へ既存案件を移し、運用の手間を下げます

最大の落とし穴は、受託のまま止まってしまうことです。1社目が決まると嬉しくて、製品化の時間を後回しにしがちになります。受託は3社までと先に決め、それ以降の時間は製品化に回します。 この線引きを最初に書き出しておくことをおすすめします。

関連して、受託の現場で時間を削る工夫はAgentKit での受託ワークフローにまとめています。

パス5 — サブスクリプションエージェント

エージェント単体に月額を設定し、回数や機能でプランを分ける形です。毎日使われる道具で、使うほど手になじむものに向いています。

AI エージェントのサブスクで最も事故が起きやすいのは、原価が利用量に比例するという点です。固定費の SaaS と違い、ヘビーユーザーが1人いるだけで、その月の利益が API 料金に消えてしまうことがあります。

そこで、プランを決める前に次の計算を済ませておきます。数字はあくまで例です。

この表で見ているのは、いちばん使われた月でも赤字にならないかどうかです。平均ではなく最悪のケースで試算する——それだけで、無制限プランの誘惑にかなり強くなれます。

利用上限は、課金確認の直後、エージェントを呼ぶ前の位置に置きます。

type Plan = { name: string; monthlyLimit: number };
 
const PLANS: Record<string, Plan> = {
  free: { name: "Free", monthlyLimit: 10 },
  pro: { name: "Pro", monthlyLimit: 200 },
};
 
export async function guardUsage(userId: string): Promise<boolean> {
  const user = await getUser(userId);
  const used = await countUsageThisMonth(userId);
  const limit = PLANS[user.plan].monthlyLimit;
  return used < limit;
}

上限を超えたときは、単に拒否するのではなく、追加購入への導線を出すところまで作っておくと、ヘビーユーザーがむしろ収益の柱になってくれます。

上限の考え方そのものは、並列エージェントのクォータ予算設計でも、別の角度から書いています。

5つは排他ではなく、組み合わせて使います

実際には2〜3のパスを併用する人がほとんどです。よく見る組み合わせは次の3つです。

• 自社販売とマーケットプレイスの併用（入口と、利益率の高い本線を分けます）
• 受託と製品化の併用（キャッシュフローを確保しながら、製品比率を少しずつ上げます）
• SaaS 組み込みとサブスクの併用（B2B の導線と、個人向けの自社課金を並べます）

どれを選ぶにしても、いま思えば私は出口の設計を後回しにしがちでした。顧客の声が自分に届く出口を、1つは必ず残します。 これを私の原則にしています。

販売戦略や出品の段取りを90日の計画に落とし込んだものは、エージェント商品化のロードマップに続きを書きました。

まずは今日、手元のエージェントについて「最もよく使われた月の原価」を1行だけ計算してみていただければと思います。その数字が、どのパスを選ぶかの出発点になります。