【AI時代の個人開発】7. 課金機能は最後の仕上げではなかった話

AIを使う側から、使いこなす側へ。

※2026年7月3日更新
シリーズを書き進める中で得た気づきを反映し、リード文・構成・文章表現を見直しました。

課金機能は、サービスが完成してから最後に加えればよい。個人開発を始めた当初、私はそう考えていました。

ところが、Stripe実装を見直していくうちに、正常に決済できることと、安心して運用できることの間には大きな隔たりがあると気づきます。

課金機能は、最後に取り付ける部品ではありませんでした。

サービス全体の状態を支える、設計の一部だったのです。

課金機能を後回しにしていた

個人開発では、画面の作成や機能の実装、操作性の改善、動作確認など、やるべきことが次々に出てきます。限られた時間の中で進める以上、どこから手をつけるかを決める必要があります。

私も、まずはサービスの中核となる機能を形にすることを優先しました。利用者に価値を届けられる状態まで作り、そのあとで課金機能を加える。

課金が必要になることは分かっていましたが、最初から多くの時間を使う必要はないだろうと考えていたのです。

当時の私にとっては、ごく自然な順序でした。

比較した結果、Stripeを選んだ

課金機能の実装に着手する段階で、いくつかの決済サービスを比較しました。

重視したのは、次のような条件です。

• 小規模なサービスでも導入しやすい

• 初期費用や月額固定費を抑えられる

• サブスクリプションと無料期間に対応している

• 利用者自身で支払い方法の変更や解約ができる

• ドキュメントやサンプルコードが豊富にある

• AIを活用しながら実装を進めやすい

これらの条件に合っていたのがStripeでした。

Stripeには、決済画面を自前で作らずに済む仕組みがあります。支払い方法の変更や解約手続きを利用者自身で行えるBilling Portalも用意されており、必要な機能をすべて一から作る必要がありません。

英語の情報が中心でも、ドキュメントや事例は豊富です。AIを使って必要な情報を整理しながら進められる点も、個人開発には向いていると感じました。

選定自体に、大きな迷いはありませんでした。

Stripeを使えば、課金機能も比較的スムーズに実装できそうです。

問題は、その先にありました。

ひとまず動くところまでは順調だった

AIに依頼しながらStripe実装を進めると、申し込みから契約開始までの流れは形になりました。

• 申し込み画面から決済画面へ移動する

• 必要な情報を登録する

• 無料期間付きの契約が始まる

• 処理が完了したら元のサービスへ戻る

支払い方法の変更や解約についても、Stripeが用意した画面を利用できます。表面的には、課金に必要な流れが揃っていました。

正常系の動作を確認できた時点で、私は少し安心していました。

ひとまず課金機能は完成した。あとはリリースへ向けて、細かな調整を進めればよい。

そう考えかけていました。

Pull Requestで確認するのはコードだけではない

前回の記事では、AI時代の個人開発におけるPull Requestの役割について書きました。

Pull Requestというと、複数人でコードの変更内容を確認し、問題がなければ反映する仕組みという印象があります。もちろん、それも重要な役割です。

一方で、個人開発では別の意味も持ちます。

実装した内容が、意図した仕様になっているかを確認すること。

AIが生成したコードの細かな挙動は、テストを実行することで確かめられます。ただし、そのテストを始める前に、もうひとつ考える必要があります。

そもそも、確認すべき仕様を網羅できているのか。

課金機能についても、正常に申し込みができるところまでは確認していました。では、実施したテストは本当にそれだけで足りるのか。

当時、ここまで明確に言語化できていたわけではありません。ただ、お金を扱う機能を正常系の確認だけで終えることに、漠然とした危うさを感じていました。

「動く」と「安心して運用できる」は違う

課金機能には、申し込みが正常に完了する場面以外にも、さまざまな状態があります。

• 無料期間中である

• 有料契約が継続している

• 解約手続きが行われた

• 支払いに失敗した

• Stripe側の変更がアプリへ正しく反映されなかった

• 処理の途中で一時的なエラーが発生した

• 同じ通知を複数回受け取った

正常に申し込みが完了することは重要です。しかし、課金機能の運用では、例外が起きたあとの動きまで考える必要があります。

情報に食い違いが生じたとき、どの状態を正しいものとして扱うのか。処理が途中で止まったとき、どのように復旧するのか。想定外の事態によって、利用者にどのような影響が出るのか。

そこまで含めて初めて、安心して運用できる状態へ近づきます。

「ひとまず動く」と「安心して運用できる」の間には、想像していた以上に大きな距離がありました。

ChatGPTにレビューを依頼してみた

そこで、現在のStripe実装についてChatGPTにレビューを依頼しました。

最初は、それほど大掛かりな話になるとは思っていませんでした。実装内容を共有し、見落としている点がないか確認してもらう。問題があれば、必要な部分だけ直せばよい。

その程度に考えていたのです。

ところが、レビューを進めるにつれて、確認すべき論点が次々に見えてきました。

• 契約状態をどのように管理するのか

• Stripeから受け取った通知をどう反映するのか

• 同じ通知を複数回受け取っても問題が起きないか

• 処理の途中でエラーが起きたとき、どう復旧するのか

• Stripe側とアプリ側の状態がずれたとき、どちらを正とするのか

どれも、画面上で正常に申し込みができるかを確認しただけでは見えてこない論点でした。

詳しい実装内容については、シリーズ第９回「Stripe実装を「壊れない設計」に作り直した話」で振り返ります。

この時点で分かったのは、課金機能が最後に取り付けるだけの部品ではなかったということです。

課金は、機能ではなく設計だった

サービスを作っていると、目に見える画面や機能に意識が向きます。ボタンを押せる。必要な情報を登録できる。画面に結果が表示される。

こうした成果は分かりやすく、開発を前へ進めるうえでも大切です。

一方で、課金機能の重要な部分は、画面の裏側にあります。

• 利用者が現在どの状態にいるのか

• 契約状態が正しく反映されているか

• 支払いに失敗したとき、どう扱うのか

• 同じ処理が重複しても問題が起きないか

• エラーのあと、正しい状態へ戻せるか

決済画面を追加しただけでは、課金機能が完成したとは言い切れません。契約状態をどう持ち、変化をどう反映し、問題が起きたときにどう戻すのか。

課金は、サービス全体を支える設計の一部でした。

当初の私は、課金機能を最後に追加すればよいと思っていました。

しかし、実際に向き合ってみると、その考えだけでは足りませんでした。

課金機能は、最後の仕上げではなかったのです。

ChatGPTの使い方が、少しずつ変わり始めた

今回の経験を通じて、もうひとつ気づいたことがあります。

ChatGPTは、分からないことを質問したり、戦略を練るために壁打ちをしたりするだけのAIではありませんでした。

実装全体を俯瞰してもらう。見落としているリスクを指摘してもらう。自分だけでは足りない視点を補ってもらう。

レビュワーとして活用することで、AIの役割は大きく広がります。

ただし、AIにレビューを依頼すれば、すべてが解決するわけでもありません。何を任せ、どこを人間が判断し、どのAIにどの役割を担ってもらうのか。

個人開発では、その切り分けも設計する必要があります。

そして、この気づきはStripe実装だけに限った話ではありませんでした。

次回のサブタイトルは、
「8. AIに全部任せればOKではなかった話」
です。

AIは、とても優秀です。

だからこそ、人間が担う役割も見えてきました。

関連情報

次回：シリーズ８

前回：シリーズ６

【AI時代の個人開発】シリーズを最初から読む

創作大賞2026の選考期間中は、創作大賞2026 ビジネス部門 応募作品｜AI時代の個人開発 にも全10話をまとめています。