APIキーを利用者に持ち込んでもらう設計と責任

生成AIを使うアプリを個人で配るとき、一番の問題はAPIの利用料を誰が払うかです。

自分が払う形にすると、使われるほど赤字が増えます。 かといって課金の仕組みを作ると、決済の実装も、返金対応も、税金の処理も付いてきます。

そこで、利用者に自分のAPIキーを用意してもらう形にしました。

どういう仕組みか

• アプリのコードにAPIキーを一切埋め込まない
• 利用者が自分でキーを発行し、アプリの設定画面に貼る
• キーはその端末の中（IndexedDB）にしか保存しない
• サーバーを持たないので、キーがどこかへ送られることもない

結果として、課金はそれぞれのアカウント持ちになります。

この設計の利点

• 運営側にコストが発生しない。 何人に配っても費用は増えない
• 課金の実装が要らない。 決済も返金も請求書もない
• キーを預からない。 漏洩の責任を負わずに済む
• 利用者が使いすぎても、影響はその人の枠だけに閉じる

個人開発で「無料で配りたいが、赤字は困る」という状況にはよく合います。

代わりに増えた責任

利点ばかりではありません。他人の枠を使わせてもらっている状態になります。

無料枠には1日の呼び出し回数の上限があります。 アプリが無駄に呼び出すと、その人がその日使えなくなります。

そこで、開発ルールにこう書きました。

APIの呼び出し回数を増やす変更は、必ず理由と増加量を説明する。

自分の財布で動かしていると、呼び出し回数は「速度」の話でしかありません。 持ち込み型では、呼び出し回数が機能の可用性そのものになります。

工程ごとに上限を決める

実際に、処理の種類ごとに最大呼び出し回数を決めています。

工程	最大回数	内訳
命令表	3回	読み直しを含む。別経路へは落ちない
法則性・暗号	4回	読み取り1回＋別経路3回

読み直しを入れているのは片方だけです。 もう片方は読み直しても改善する見込みが薄いと測って分かったので、 効果の分からない再試行で他人の無料枠を使わせないという判断をしました。

「精度が上がるかもしれないからもう1回呼ぶ」は、自分持ちなら妥当でも、 持ち込み型では正当化しにくい選択になります。

使用回数を利用者に見せる

もう1つ入れたのが、実際の呼び出し回数を画面で確認できる機能です。

利用者は自分の枠を消費しているので、あとどれくらい使えるかを知る権利があります。 モデル別に実際のHTTP呼び出し回数を数え、無料枠のリセット時刻に合わせて表示しています。

「気付いたら今日はもう使えない」という状態を作らないための機能です。

向いている場合と、向いていない場合

向いているのは、

• 利用者が技術に明るく、キーの発行が負担にならない
• 無料で配ることが目的で、収益化しない
• 使う人数が読めない

向いていないのは、

• 利用者がキーの発行方法を理解できない
• 「開いてすぐ使える」ことが重要
• 収益化を前提にしている

実際、家族向けに作った議事録アプリのほうは持ち込み型にしていません。 使う人に「APIキーを取ってきて」と言っても現実的でないからです。 そちらは運営側でキーを持ち、代わりに合言葉でアクセスを制限しています。

同じ作者でも、使う人に応じて設計は変わります。 持ち込み型は万能な答えではなく、利用者層とセットで選ぶものだと考えています。