🔧 集客より先に直すべきことが2つあった

「準備が整ったら、次は集客だ」と思っていた時期がありました。

マーケットプレイスの仕組みはできていた。AIで自動化できる「社員」を売り買いする場所です。出品フォームもあって、決済もつながっている。購入者向けのページも作ってあって、コンテンツを少しずつ整えながら、「そろそろSEOや告知を本格的に考えよう」と思っていた矢先のことでした。

ちょうどその週、2つのことが同時に見えてしまったんです。

1つは「決済の記録が落ちている可能性がある」こと。もう1つは「出品者のプロフィールが日本語しか読めない」こと。どちらも、集客を強化してたくさんの人が来ても、取引が成立しないまま終わってしまうレベルの問題でした。今日は、その2つを直した話を書きます。技術の話というより、「ひとりで全部やる」ということの意味を、初めてちゃんと理解した週の話です。

コンテンツを整えて、いよいよ集客を考えはじめた週

「もう少ししたら本格始動しよう」と思っていた

マーケットプレイスを作ったとき、最初にやったのは「最低限動く」状態を作ることでした。出品できる、購入できる、メールが届く。その3つがあれば、まずはスタートできると思っていたんです。

実際、それで動き始めて、少しずつ記事を書いたり、SNSで発信したりしていました。でも正直に言うと、「もう少し準備が整ったら、ちゃんと集客しよう」という気持ちがずっとありました。あと少し、あと少し。そういう気持ちで過ごしていた週に、ちょうどその「あと少し」を突き崩す出来事が重なりました。

この感覚、自分でサービスを運営している方には共感していただけるかもしれません。「次の記事を書いたら」「もう少しデザインを整えたら」「もう1つ機能を足したら」——そうやって「そろそろ」を先送りし続けているうちに、実は足元に穴が開いていた、という話です。

ある朝、ログを見ていて気づいた

朝、いつものようにシステムのログを眺めていたんです。ログというのは、システムが何をしたか記録したメモのようなものです。私の場合、サービスのバックエンドが動いているサーバーに、定期的にアクセスして状態を確認する習慣があります。

そこで、少しおかしな動きに気づきました。Stripeからの通知を受け取るエンドポイント（/webhook/stripe のような処理の入り口）への着信ログがあるのに、その後の「購入完了」を記録するログが飛んでいないケースが散見されたんです。

ログに残っていたのはこんな形の記録でした（実際の値は伏せています）：

[INFO] Received Stripe event: payment_intent.succeeded
[INFO] Processing webhook...
[ERROR] Timeout: handler did not complete within limit

つまり、「通知は来ました」「処理を始めました」「でも時間内に終わりませんでした」という流れです。「もし今まで取引があったとして、記録が落ちていたら？」という不安が一瞬頭をよぎりました。

後で調べてわかったのですが、Stripeはwebhookの応答が一定時間以内に返ってこない場合、失敗として扱います。そして数回リトライしてくれるのですが、それでも応答が来ない場合はそこで終わります。「記録されていない取引が存在するかもしれない」という状況は、ユーザーさんへの影響を考えると、一番先に手を打たなければいけないものでした。

📕 AIエージェントと自動化の全工程をまとめた総集編 手順・コード・テンプレをそのまま渡しています 🤖【完全版】月商160万円の「寝てても回る仕組み」をゼロから30日で組む全工程｜2026年10月版・Claude Code×AIエージェント・特典40ファイル・毎月更新

「決済の記録が落ちる」とはどういうことか

webhookを噛み砕いて説明します

少しだけ説明させてください。「webhook（ウェブフック）」という言葉、聞いたことがありますか？

簡単に言うと、「何かが起きたら教えてね」という仕組みです。たとえば、誰かが商品を購入した瞬間、決済サービス（今回はStripeというサービスを使っています）が「購入されましたよ！」とこちらのシステムに通知を飛ばします。その通知を受け取って「記録しました、ありがとう」と返すのが一連の流れです。

もう少し具体的に書くと、Stripeは payment_intent.succeeded（支払い成功）や checkout.session.completed（チェックアウト完了）のようなイベントをHTTPリクエストとして送ってきます。こちら側はそれを受け取って、データベースに「購入済み」として記録し、購入者にメールを送り、サービスへのアクセスを付与する——という一連の処理を走らせます。

この一連の処理が全部終わって初めて「受け取りました（HTTP 200）」を返す必要があります。でも処理が重かったり、途中でエラーが起きたりすると、返事が遅れたり返せなかったりする。そういうときに記録が落ちるんです。

実際に何が問題だったか

今回のケースで起きていたのは、処理の中の一部——購入後の通知メール送信——に時間がかかりすぎていることでした。メール送信は外部のサービスを呼び出しているので、そのサービス側の応答が遅いときに処理全体が詰まってしまっていたんです。

本来、webhookの応答は「必要最低限の記録だけをすぐやって、時間のかかる処理は後回しにする」という設計が正解です。「受け取りましたよ」と素早く返してから、メール送信などは別のキュー（処理待ちの列）に積んで非同期でやる、という形です。

私のコードではその分離ができていなくて、全部の処理が終わるまで返事をしない作りになっていました。普段は問題ないのですが、メールサービスが少し重い時間帯には、タイムアウトになってしまっていたわけです。

どうやって直したか

直し方は、処理を2段階に分けることでした。

1. 通知が届いたら、まず「どの購入か」をデータベースに記録して、即座に「受け取りました（200 OK）」を返す
2. メール送信や権限付与などの後続処理は、バックグラウンドで非同期に実行する

技術的には「キューに積む」という言い方をしますが、要は「急いで返事して、詳細は後でやる」という発想です。飲食店で言えば、「ご注文承りました！」とすぐに返事して、実際の調理は後でやる、みたいな感じです（笑）。

修正後に確認したのは、Stripeのダッシュボードにある「Webhookイベント」のページです。ここには送信されたイベント一覧と、それぞれが成功したか失敗したかが表示されています。修正後しばらく観察して、「Failed」の件数がゼロになっていることを確認しました。また、ローカルでも stripe listen --forward-to localhost:3000/webhook/stripe というコマンドを使ってテストイベントを流し、処理が正常完了することを確認しました。

「動いているはず」ではなく、「動いていることを確認した」。この差は、ひとりで全部やる場合に特に大事だと感じました。

先回りQ&A：「記録が落ちた取引」はどうなるの？

これ、自分でも気になって調べました。

Stripeの場合、「支払いが完了した」という事実はStripe側に残ります。つまり、ユーザーさんのカードから引き落とされた記録はStripeに存在しています。問題はこちら側のシステムに「購入済み」として記録されていないこと。

確認方法として、Stripeのダッシュボードで成功した支払い一覧を出して、自分のデータベースに記録がある購入と照合する、という方法があります。今回は幸い、タイムアウトが起きていたのはシステム全体が不安定だった短い期間で、その間に完了した取引の記録が抜けていないかをStripeのエクスポートと突き合わせて確認しました。

もし抜けがあった場合は、Stripeのイベントを手動で再送することで記録を補完できます。Stripe CLIを使うと stripe events resend <event_id> で特定のイベントを再送できるので、こういうときのために覚えておくと便利です。

同じ週に見えてきた、もう1つの問題

プロフィールが日本語しか読めない

webhookの問題を調べながら、もう1つ気になることが出てきました。出品者プロフィールのページです。

このマーケットプレイスには、AIサービスを出品している人のプロフィールページがあります。どんな人が何を提供しているか、購入者が確認できるページです。

ところが、これが日本語しか書かれていない状態だったんです。英語圏や中国語圏の方が見ても、何も読めない。「誰が何を売っているのか」が伝わらないまま購入を判断しなければいけない、という状態でした。

自分でアクセスしてみたとき、「あ、これ読めないじゃん！」と素直に驚きました（笑）。作っている本人は日本語話者なので気づかなかったんですが、言語を英語に切り替えてページを見た瞬間、「この状態で海外向けに発信してたのか…」とちょっと恥ずかしい気持ちになりました。

言葉が読めなければ、信頼できない

購入するとき、相手のことが全くわからない状態で「買う」ボタンを押せるでしょうか。私はちょっと怖いと思います（笑）。

特にデジタルサービスの場合、「この人は信頼できるの？」という不安は大きいはずです。プロフィールに何も読めない言語で書いてあったとしたら、そこで離脱してしまうのは自然なことだと思います。

実際、これはECサイトや海外向けサービスで「ローカライゼーション（現地化）」と呼ばれる問題の一部です。翻訳があるかどうかではなく、「読める状態になっているかどうか」が、購入意思を左右する大きな要因です。

せっかく集客して、プロフィールページまで来てもらっても、言葉が届かなければ終わりです。これも、人が来る前に直すべきことでした。

具体的に何をしたか

プロフィールの多言語化で実装したのは、大きく2つです。

1つ目は、出品者が「プロフィール英語版」と「プロフィール中国語版」を入力できるフィールドをデータベースとフォームに追加したこと。日本語版のフィールドはすでにあったので、それに並べる形で bio_en、bio_zh のような列を追加しました。

2つ目は、購入者が使っているブラウザの言語設定を読み取って、対応する言語のプロフィールを表示するロジックを実装したこと。ブラウザの言語設定は Accept-Language ヘッダーから取得できます。英語設定なら英語版を、中国語設定なら中国語版を、それ以外や対応していない言語なら日本語版をフォールバックとして表示する、という形にしました。

一番気をつけたのは、「翻訳がない状態でもページが壊れない」ことです。今いる出品者が全員すぐに英語プロフィールを書くわけではないので、フィールドが空欄のときは日本語版を表示する、というフォールバックの処理をきちんと書きました。翻訳を入れない場合でも最低限読めるページが出る、という状態にしてから公開しました。

確認は、ブラウザの言語設定を英語・中国語・日本語と切り替えながらページを開いて、それぞれ正しく表示されることを目視で確認しました。開発者ツールのネットワークタブで Accept-Language ヘッダーの値も確認して、意図した言語が送られていることも見ました。

先回りQ&A：翻訳は自動でやらないの？

「自動翻訳（DeepLやGoogle翻訳のAPIとか）を使えばいいんじゃないの？」と思う方もいると思います。実際、私もそれを最初に検討しました。

でも今回は見送りました。理由は、自動翻訳は精度が高くても「本人が確認していない文章」がプロフィールとして表示されることになるからです。特に、得意なことや実績を伝えるプロフィールの文章は、ニュアンスが少しズレるだけで信頼感が変わります。「機械が訳した感」がある文章よりも、出品者本人が書いた文章の方が、購入者の信頼につながると判断しました。

将来的には「自動翻訳で下書きを作って、本人が確認・修正する」という補助機能は入れてもいいと思っています。でも今の段階では、「本人が書いたものを表示する」という設計を選びました。

同じ1週間に、2つを直した

優先順位のつけ方

2つの問題を同時に発見して、最初に考えたのは「どちらを先にやるか」でした。

どちらも「先」と言えるくらい大事な問題でした。でも順番をつけるなら、決済の安定性を先にしました。理由はシンプルで、「取引が記録されない」は直接お金に関わる問題だからです。多言語化は信頼に関わる問題ですが、記録が落ちることと比べると、被害が表に出るまで少し時間がかかります。

判断基準を言葉にするなら、「ユーザーさんが損をするか、こちらが損をするか」です。記録が落ちると、ユーザーさんはお金を払ったのにサービスを受けられない可能性があります。これは絶対に先に直すべきです。多言語化の未対応は、ユーザーさんが「読めないから買わない」という判断をする問題で、機会損失ではありますが、既存のユーザーさんへの直接的な被害ではない。だから優先度は後でした。

とはいえ、同じ1週間の中で2つとも進めました。片方を終わらせてから、というよりは、午前中は決済まわり、午後は多言語化、という形で並行して進めました。

「直した」ことをどうやって確認したか

どちらも、「動いているはず」だけで終わらせないように気をつけました。

決済については前述の通り、Stripeダッシュボードのwebhookイベント一覧でFailedがゼロになっていることを確認しました。加えて、自分でテスト用のカード番号を使って実際に購入のフローを走らせて、購入完了メールが届くか、データベースに記録が残るかを確認しました。

多言語化については、ブラウザの言語を手動で切り替えてページを確認した他に、HTTPクライアント（curlやPostman）で Accept-Language: en のヘッダーをつけてAPIを叩いて、英語版のデータが返ってくることを確認しました。「ブラウザで見たら大丈夫だった」だけでなく、「APIレベルで正しいデータが返ってきている」ことまで確認することで、表示ロジックにバグがあっても拾えるようにしました。

この確認の手順は、後で再現できるようにメモとして残してあります。次に何かを変更したとき、同じ手順で動作確認ができるようにするためです。

会社にいた頃との「違い」を痛感した

担当が分かれていた時代

この2つの問題を直しながら、ふと思い出していたことがありました。

以前、会社に勤めてマーケティングをやっていたとき、決済まわりの話はエンジニアチームの管轄でした。多言語対応も、必要であればローカライズの担当者か、現地チームが動いていました。集客・コンテンツは私が担当していて、決済や多言語がどうなっているかは、「他の誰かがやってくれる」という状態が当たり前でした。

担当が分かれているとき、その分かれ目は見えません。「集客担当の私は集客をやればいい」という意識で、他のことはあまり気にしていなかった、というのが正直なところです。「決済ってどう動いてるんですか？」と聞くと「エンジニアに確認してみます」という返答が来て、それで終わっていた。それが普通の環境でした。

もちろん、チームで動くことのメリットは大きいです。専門家がそれぞれの領域を深く掘れる。1人ではカバーできないスピードとクオリティが出せる。それは本当にそうです。でも同時に、「自分が見ていない領域に何があるかわからない」というリスクが常に存在していました。

ひとりになって初めてわかった「全部自分」の意味

ひとりでやるようになって初めて、その分かれ目が全部自分の中にあることに気づきました。

決済を整えるのも、多言語に対応するのも、コンテンツを書くのも、SNSで発信するのも、全部「Lilyの仕事」です。誰かに聞けばやってくれる部門もないし、「それは私の担当じゃないです」と言える場所もない。

これ、最初は正直きつかったです。「どこまで自分でやらなきゃいけないの？」という気持ちになることがありました。ログを読んでエラーを直して、データベースの設計を変えて、翻訳フォームを作って——それをやりながら記事も書かないといけない、SNSも更新しないといけない。「全部やる」って言葉では知っていたつもりでしたが、実感したのはこのときでした。

でも今は、少し違う見え方をしています。「全部自分の責任範囲」というのは、「全部自分が気づける」ということでもある、と。

会社にいたとき、決済が不安定でも私は気づけなかったと思います。プロフィールが読めない言語になっていても、「担当じゃないから」で終わっていたかもしれない。ひとりだからこそ、全部見える。それは大変さでもあるけれど、強さでもあるんだと、少しずつ思えるようになってきました。

「ひとりで全部やる」のに必要な習慣

この経験から、自分の中で取り入れるようになった習慣が1つあります。週に1回、30分だけ「外から自分のサービスを点検する時間」を作ることです。

点検といっても大げさなことではなく、こんなことをやっています。

• StripeのダッシュボードでWebhookのFailedが出ていないか
• ページを英語に切り替えて、読める状態になっているか
• フォームを実際に送信して、メールが届くか
• エラーログに見慣れない記録が増えていないか

これ、1人でやっていると「問題が起きるまで気づかない」が起きやすいんです。チームがあれば誰かが「最近このエラーよく出てません？」と気づいてくれることもありますが、1人では能動的に見に行く習慣を作らないと、問題がどんどん積み上がります。

直してから、何が変わったか

数字より「安心感」が先に来た

正直に言うと、この2つを直したことで劇的に何かが変わった、という感じはまだありません。

取引の記録が安定したことで、「もし何かあっても追えるようになった」という安心感は生まれました。多言語化したことで、海外の方が来てくださったときに「読める状態」になった、という感覚があります。

ただ、1つ確実に変わったことがあります。集客の話を考えるときの気持ちが、少し軽くなりました。「来てもらっても、ちゃんと動かない部分があるかもしれない」という不安を抱えながら発信するのと、「最低限は整った」という感覚で発信するのは、全然違います。発信するときの後ろめたさみたいなものが、なくなった感じです。

以前と比べると、発信の回数と内容のどちらも変化がありました。前は「もう少し直してから書こう」という気持ちがブレーキになっていたんですが、今はそのブレーキがなくなった感覚があります。

「器」を整えてから、はじめて注ぐ話

今回の経験を通じて、自分の中で整理できた考え方があります。

集客は「水を入れる」作業だとすると、決済の安定性や多言語対応は「器を整える」作業です。器に穴が開いていたり、形がおかしかったりしたら、どれだけ水を入れても流れ出てしまいます。

「器が整ったら集客を始めよう」と思っていたのに、いつの間にか「集客に使えるコンテンツを作ること」が「器を整えること」に化けていて、本当の穴を見落としていた、というのが今回の正直なところです。

コンテンツを書くのは「水を入れる」作業で、「器を整える」作業ではなかった。この分類を頭の中でちゃんとやらないと、見た目は動いているのに実は全然整っていない、という状態が生まれます。

仕組みをAIで動かすための設定や構成の詳細は、別にまとめた有料記事に全部書いています。「どう動かしているか、何を使っているか」は仕組みの全部をそちらで公開していますので、気になる方はフッターのリンクからどうぞ。

集客より先にやるべきことがある、ということ

「最低限」の定義がずれていた

今回、自分の中で「最低限動く」の定義がずれていたと気づきました。

「出品できる、購入できる、メールが届く」。これは「最低限動く」と言えます。でも「取引の記録が必ず残る」と「誰でも読める状態になっている」は、そこに含まれていませんでした。

売買が成立するための最低限は、「ボタンが押せること」じゃなくて、「押した結果がきちんと記録されること」と「相手がその取引相手を信頼できること」だったんです。そのレベルまで含めて「最低限」と定義しないといけなかった、というのが今回の学びです。

チェックリストにするとこんな感じです。これ、自分のサービスを作ったときに確認してみてほしいです。

• ユーザーが何かアクションをしたとき、その結果がデータベースに記録されているか
• 決済完了の通知が100%記録されているか（Stripeならwebhookイベントのログ）
• エラーが起きたとき、ユーザーへの影響は何か、気づける仕組みがあるか
• ページを日本語話者以外が見たとき、読める状態になっているか
• 外部サービスが一時的にダウンしても、処理が中断されない設計になっているか

「全部OKです」と言えるまで集客を始めなくてもいいわけではありませんが、この中に1つでも「ちょっと怪しいかも」があるなら、先に確認した方がいいです。

今日できる1歩

もし自分で何かサービスやコンテンツを作っていて、「そろそろ集客しようか」と思っている方がいたら、こんなことを一度確認してみてほしいです。

「人が来て、行動した結果が、ちゃんと記録されているか？」

フォームの送信が届いているか、決済の完了が記録されているか、登録のメールが届いているか。これが怪しい状態で集客を強めても、その人たちの行動は見えないまま終わってしまいます。確認する方法はサービスによって違いますが、「実際に自分でやってみて、記録が残っているかを見る」が一番簡単です。自分のサービスの購入者になってみて、記録の端から端まで追ってみる。これだけで、かなりの問題が見えます。

もう1つ、「自分のサービスを、自分以外の人が見たら読めるか？」

日本語しか使えない状態でも、日本語圏の読者だけを相手にするなら問題はないかもしれません。でも、もし少しでも広く届けたいなら、読める言語になっているかを確認するのは早いほど良いです。具体的には、ブラウザの言語設定を英語に切り替えて自分のサービスを見てみること。そこで何も読めなかったら、要対応です。

この2つを整えてから、集客の話を考えるのが順番だと、今は思っています。

先回りQ&A：結局どのくらい時間がかかったの？

「直すのに何日もかかるなら、自分には無理かも」と思う方もいると思うので書いておきます。

webhookの修正は、問題の特定に半日、実際の修正と動作確認に半日、合計1日弱でした。多言語化は、データベースへのフィールド追加・フォームの修正・表示ロジックの実装・確認で、2日弱かかりました。合計3日前後です。

ただ、「問題に気づかなかったら、どのくらい損をし続けていたか」を考えると、この3日間は確実にコストパフォーマンスが高い時間でした。記録が落ちたまま取引が積み上がっていれば、後から全部手動で修正する羽目になっていました。多言語化をしないまま海外向けに発信を続けていれば、来た人が全員プロフィールページで離脱する状態が続いていました。

問題の修正は「コスト」ではなく「先行投資」です。特に基盤に関わる部分は、早くやるほどリターンが大きいです。

最後に

今週の体験を書いていて、改めて思ったのは「問題は見ようとしないと見えない」ということです。

集客に頭が向いているとき、決済の安定性やプロフィールの言語は、視野の外に出てしまいます。意識して「今のサービスに何か落ち穴はないか」を見に行く時間を作らないと、気づかないまま進んでしまう。

ひとりでやっているからこそ、定期的に「自分のサービスを外から見る目」を持つことが大切だと、この週に強く感じました。「担当が違う」とは言えない分、自分で見に行くしかない。でも逆に、自分で見に行けば、全部わかる。それは会社にいたときにはなかった視点でした。

集客より先に直すべきことがあった。でも気づけてよかった、と今は思っています。それだけ書いておきたくて、この記事を書きました。読んでくださって、ありがとうございます。

📕 この記事の内容を、実装まで全部まとめた有料記事があります 手順・コード・テンプレをそのまま渡しています AIで「寝てても回る仕組み」をゼロから30日で組む全手順