月額0円から始めるAI業務管理秘書たすきば｜3プラン全公開と「続けるための課金」
価格表を作るのに、6 ヶ月の中で一番悩んだ
正直に書きます。たすきば Knowledge Relay の開発で、私が一番悩んだのは技術選定でも UI でもなく、 価格表 でした。
「いくらにすれば、ちゃんとサービスが続けられて、しかも使う人が罪悪感なく入れるのか。」 ——この問いの前で、Excel のシートを何枚も作り、消し、また作り、を繰り返しました。最終的に行き着いたのが、今日書く 「儲けるための課金ではなく、続けるための課金」 というスタンスです。
そもそも私は、たすきばで利益を出すこと自体を目的にしていません。 連載第 1 回 で書いた通り、私はサービスの価値そのものに賭けていて、 多くの人に使ってもらいたい と思っています。
それでも課金を導入する理由はひとつだけ。 このサービスを 10 年続けるための事業継続性を確保するため です。「儲けるため」ではなく「続けるため」——書いてみると当たり前に聞こえますが、価格表を作っている時間の半分以上は、この二つを混同しそうになっている自分との戦いでした。
今日は、この信念が 3 プランの設計と従量課金の細部にどう落ちているのか、 『お金の使い方の科学』ノート で考えた「何のためにお金を使うのか」を反対側（受け取る側）から書く形で、整理します。
3 プランの全体像
| プラン | 席数 | 月額固定 | 従量課金（Project upsert） | 自動タグ抽出モデル |
|---|---|---|---|---|
| Beginner | 5 席まで | ¥0 | プロジェクト作成 / 更新 月 50 回まで無料、それ以降は課金 | Haiku |
| Expert | 無制限 | ¥0 | ¥10 / call | Haiku |
| Pro | 無制限 | ¥0 | ¥15 / call | Sonnet（「なぜ?」機能 = LLM Re-ranking 対応） |
※上表の従量課金は LLM 利用（タグ抽出・「なぜ?」説明）の単価です。embedding（資産入力・チャット意味検索）は別枠で Beginner 月 100 件まで無料 / Expert・Pro ¥5 / call。DB 容量・ファイルストレージも従量課金（後述）。
設計の根底にあるもの
- どのプランも月額固定 ¥0 — 使わない月はゼロ円。アイドル時に請求が発生しない
- 従量課金は「業務操作 1 回」単位 — 内部で複数 API を呼んでも、ユーザに見える課金は 1 回
- 席数で割増しない — 大規模チームに罰金を課す構造にしない（Expert / Pro は席数無制限）
「Project upsert は月 50 回まで無料」の意図
Beginner プランは「プロジェクト作成 / 更新を月 50 回まで無料、それ以降は課金」という、ちょっと変則的な設計です。
これは、 悪用防止と利用促進のバランス を取った結果です。
- 悪用防止: プロジェクトを大量作成して LLM コストを爆発させる行動を防ぐ
- 利用促進: 通常利用（月数件〜十数件のプロジェクト管理）では完全無料
50 という数字は、私自身の利用ログから 「個人 / 小規模チームが現実的に作るプロジェクト数の倍数」 として設定しています。普通に使っていれば 50 回には到達しません。到達したら、それは「Expert に移ってよい規模」というシグナルです。
Beginner プランへのダウングレードは禁止
これは ADR-0013 で決めたルールです。
一度 Expert / Pro プランにしたテナントは、Beginner プランへ戻せない。
理由は、悪用防止です。
- Expert で大量にプロジェクト作成 → Beginner にダウングレードして無料枠を享受 → また Expert に戻す——というサイクルの悪用を防ぐ
- Beginner は「初めて使うユーザの入り口」として明確に位置づけており、リッチユーザの避難先ではない
ダウングレードを禁止することで、 Beginner プランを “真に新規ユーザのための無料枠” として守る 設計にしました。
ここは、 B-4 で書く「ユーザに主導権を返す UI」 の例外にあたります。例外を作るときは、 なぜそれが例外なのかを正直に書く ——これがたすきばの設計運用ルールです。
DB 容量・ファイルストレージも従量課金
プラン外で発生するコスト要素として：
- DB 容量 — ADR-0020 で従量課金化。1 GB 単位で月額料金が加算
- ファイルストレージ — ADR-0021 で従量課金化。1 GB 単位で月額料金が加算
これらは 「使った分だけ、後から払う」 設計です。
なぜ前払いではなく後払いかというと、ユーザにとって 「今月使った分だけ請求される」 のが直感的で、無駄な前払いを発生させないからです。
「儲けるための課金」なら、月額前払いで使わない分も払わせる設計のほうが安定収入になります。たすきばは、 その方向を採らない という選択をしています。
解約とダウングレードは UI から完結
プラン変更・解約・Storage Add-on のダウングレード—— すべてセルフサービス にしています。
- 解約: テナント設定画面の「解約する」ボタンで完結。運営との往復不要
- ダウングレード: 同じ画面のスライダーで操作可能
- 解約後の再加入: 既存のメールアドレスで即時可能
「来るものも出るものも拒まない」 ——このスタンスを、操作レベルまで落とし込んでいます。詳細は明日の B-4 で。
透明性のための仕組み — 請求 invariant
たすきばは、課金根拠データを ダッシュボード遷移時に再集計 + 再集計ボタン併設 で常に最新化する設計にしています。
cron キャッシュに依存させない理由は、 誤請求のリスクを物理的に排除する ためです。
ユーザが「今月の請求額」を見たとき、それが過去のスナップショットだったら、ユーザは不安になります。 「いま、リアルタイムでこの金額です」 と即答できる UI が、信頼の土台になります。
ApiCallLog → 画面表示 → 請求書 → CSV → Stripe API 連携 まで、 すべての経路で同じ真値（ApiCallLog SUM） を使う設計にしています。これが、たすきばの「事業継続性の根本となる請求 invariant」です。
まとめ
たすきばの課金体系を、一言に圧縮するなら：
使った分だけ、必要な操作にだけ、単価に応じて透明に請求する。システムの自動処理と学習支援は、無料に保つ。
利益最大化を目指す競合のスタンスと、明確に違う場所に立っています。これは数字を見て選んだ立ち位置でもあり、価値観として選んだ立ち位置でもあります。
明日は B 章の最終回。 「ユーザに主導権を返す UI」 というスタンスが、具体的にどんな画面に落ちているかを書きます。
関連記事
- 提案機能でできること — “気づかなかった過去” を画面に並べる — 連載第 8 回・提案機能
- 『お金の使い方の科学』 — 何にお金を使うかが、人生満足度を決める — 「何のために課金するか」の発想の出どころ
- 競合と何が違うのか — たすきばが選んだ 6 つの差別化軸 — 「続けるための課金」が差別化軸の 1 つになっている理由
たすきば について
たすきば Knowledge Relay は、3 プランすべてが月額 ¥0 から始められる業務 SaaS です。 プロダクトページ からプラン詳細と従量課金の数式を確認できます。
