Tesuji手筋
投稿
記事を投稿ノードを投稿

LOG 2026.10.29 · CONSTELLATION · 1 STARS

AIでアプリを作った。その次に決める「誰に、何で課金するか」

利用者・有料の価値・利用頻度から、月額/従量/単発の課金を考える。架空の費用表でAI処理・決済・サポートの負担を確認し、最初の支払い意思の検証を一枚にまとめられる。

AIでアプリを作り、公開まで進められた。ところが、料金を付けようとすると手が止まる。月額にするのか、一回ごとに売るのか。それ以前に、お金を払ってまで使う人はいるのか。

まず決めたいのは、料金表の見た目より、誰が、どんな場面で、何を受け取る対価として払うのかです。アプリが動くことと、売る単位が決まっていることは別の到達点。小さく作れた強みを、商売の仮説を確かめる速さに使いましょう。

機能を「払う理由」に言い換える

たとえば、面談メモから提案書を作るアプリを考えます。以下の用途と金額は、すべて考え方を説明するための仮定です。実在する製品や顧客の実績ではありません。

「AIが文章を生成する」は機能の説明です。「一人で営業する人が、面談の翌日までに、抜け漏れを確認できる提案書の下書きを整える」と書けば、使う人と場面が見えます。

その人はいま、何で代用しているでしょうか。手書きのテンプレート、既存のAIチャット、同僚への依頼。そこから乗り換える理由は、生成の速さだけでなく、毎回同じ形式になること、情報を探し直さなくてよいことかもしれません。自分の予想と、利用者が実際に困ったことを分けてメモします。

問い書く内容
誰が払うか利用者本人か、所属する会社か
いつ使うか毎日の作業か、案件が来たときか、一度きりか
何を受け取るか文書、処理済みの件数、継続して使える環境など
何と比べるか現在の道具、外注、人の作業、何もしない選択
なぜ続けるか次の仕事でも同じ価値が必要になる理由

月額・従量・買い切りを、利用のリズムから選ぶ

課金方法には複数の形があります。Stripeの公式資料も、定額、利用人数、利用量などを分けています。これは実装できる選択肢の整理であって、自分のアプリで売れる形を保証するものではありません。Stripe:継続課金のモデル

形合いやすい仮説先に確かめること
月額同じ人が継続して使い、毎月価値を受け取る使わない月にも払う理由、含まれる利用量
従量処理件数など、価値と利用量の関係が分かりやすい一回の定義、失敗時の扱い、請求額の見通し
買い切り・単発一つの成果物や、区切りのある作業を受け取る購入後の利用範囲、更新・保守・AI利用の費用

継続課金と従量課金は組み合わせられます。たとえば「月額に一定量を含め、超過分を追加する」という考え方です。一方、単発で受け取った料金からAIの利用費を無期限に払い続ける約束をすると、長く使われるほど負担が増える可能性があります。

「商品として何を売るか」と「いくら・どの頻度で払うか」を分けると整理しやすくなります。Stripeも商品と価格を別に扱い、価格には単発と継続の区分を設けています。Stripe:商品と価格の考え方

売上から、使われるほど増える費用を引く

価格を考えるときは、AIの料金だけでなく、人の確認や問い合わせ対応も含めます。次は、月額プランの利用者一人・一か月分を想定した架空の計算です。決済手数料を含め、各社の現行料金を示していません。

項目仮定
売上2,000円
AI処理費20回 × 20円 = 400円
決済・請求にかかる費用100円
保存・転送など利用に応じた費用100円
サポートの作業費換算10分 × 30円 = 300円
上記を引いた残り1,100円

この1,100円は利益ではありません。開発費、固定のサーバー費、集客費などをまだ引いていません。計算を単純にするため税の影響も含めていません。また、自分がサポートすれば現金支出はなくても、使った時間は残ります。

同じ仮定で、AI処理が100回なら処理費だけで2,000円になり、他の費用を引く前に売上を使い切ります。この比較から、含める利用量、超過時の扱い、処理の効率化を検討できます。ただし、原価が収まる価格でも、利用者が価値を感じるとは限りません。費用と支払い意思は別々に確認します。

最初の実験は、料金表を増やさず一つに絞る

いきなり複数プランを作る前に、一人の利用者像、一つの用途、一つの提示価格で試します。まず、過去にその作業をした人に、何が面倒だったか、どう終わらせたか、何に時間や費用を使ったかを聞きます。

次に、提供できる範囲、価格、受け取れるものを示し、試用してもらいます。「面白い」という感想と、実際の業務で使うこと、料金を払うことは分けて記録します。未提供なら募集・予約段階だと明示し、完成済みのように扱わないようにします。

Paul Grahamは、初期には作り手自身が利用者を見つけ、一人ずつ使える状態にする重要性を述べています。ここから取り入れたいのは、人数の大きさより、使う場面を直接観察する姿勢です。Do Things that Don't Scale

AIには料金案の比較表、質問の下書き、費用計算の整理を任せられます。支払い意思や利用実績をAIに推測で埋めさせず、提供範囲と約束は自分で確認します。

今日の一手は、値札の下に一文を書くこと

「__の人が、__の場面で、__を受け取るために、__円を払う」。まずこの一文と、利用者一人分の費用表を作ってみてください。空欄が残るなら、次に聞くことが分かります。

使ってもらう入口も考えたい人は、Tesujiの記事一覧から集客や公開後の改善の手筋もたどってみてください。作る、届ける、続けるを、一つずつ確かめていきます。

編集・運営:NexA/Tesuji。AIで作ったものを、使われる仕事と事業へ育てるための実務メディアです。

自分のブックマーク

読み込み中…

NEXT MOVE — 次の一手