68歳、まだ走っている【vol.16】

お客さんが来た日——shop.kitemir.jp、最初の注文

前回（vol.15）で、AIは相棒だという話を書きました。

今日は、その相棒と一緒に作ったECサイトに、本当のお客さんが来た日の話を書きます。

---

4月1日、正式オープン

2026年4月1日。

shop.kitemir.jp——「Maison Kite」というブランドのアパレルECサイトが、正式にオープンした。

エイプリルフールの日に開店するのは、少し気が引けた。でも、逆に覚えやすい。もう十分テストした。これ以上延ばす理由はなかった。

商品を登録して、Stripeの決済を本番モードに切り替えて、OGP画像を確認して、SNSに告知文を投稿した。

妻に「今日、オープンしたよ」と言ったら、「おめでとう。で、誰か来るの？」と返された。

正直に答えた。

「わからない。」

---

注文が入った

数日後。

朝、メールを開いたら、見慣れない通知が届いていた。

「【Maison Kite】ご注文ありがとうございます」

最初、テストメールかと思った。自分で送ったのか、と過去の操作を思い返した。

違った。

本物の注文だった。

管理画面にログインする。mk_ordersテーブルに、MK-20260404-0001という注文番号が入っている。ステータスはpaid。住所も入っている。商品名、サイズ、カラー、全部きちんと記録されている。

画面を見ながら、しばらく動けなかった。

1年かけて作ったシステムの、全てのパーツが動いた瞬間だった。

---

Webhookが動いた——「裏側」の話

エンジニアとして、この注文の「裏側」がどう動いたか、少し書かせてほしい。

お客さんがカートに入れて、チェックアウトに進んで、Stripeの決済画面でカード情報を入力する。決済が完了すると、StripeからWebhookが飛んでくる。

checkout.session.completedイベント。

webhook.phpがそれを受け取って、Stripe APIからセッション情報を再取得する。この時、shipping_detailsをexpandパラメータで指定して、配送先住所を確実に取得する。

そこから先は、一気に処理が走る。注文ステータスをpaidに更新、在庫を減らす、ポイントを付与する（二重付与防止チェック付き）、使用済みクーポンを記録する、在庫が少なくなったら管理者に通知する。

そして最後に、注文確認メールをお客さんに送信する。サイズとカラーのラベル付きで。

この一連の処理が、1秒もかからずに完了した。

コードの行数にすれば、Webhook処理だけで数百行。その前段にあるStripeService、AuthService、MailService、ポイント計算——全部合わせたら何千行だ。

でも、お客さんは何も知らない。

カードを入れて、確認メールが届いて、「買えた」と思うだけだ。

それでいい。それが正しい。

インフラの仕事は、見えないことが正解だ。40年前から変わらない。

---

電話番号が保存されていなかった

最初の注文で、一つ問題が見つかった。

電話番号が保存されていなかった。

Stripeのチェックアウトセッションでは、電話番号の収集をphone_number_collection: enabledに設定していた。お客さんは確かに入力している。

でも、Webhookで受け取ったデータの中に、電話番号が入っていなかった。

原因を追いかけた。Stripeのドキュメントを読み直した。APIのレスポンスをログに出した。

わかった。phone_numberフィールドは、customer_detailsの中にある。shipping_detailsとは別の場所だ。Webhookの処理コードは、shipping_detailsの住所だけを見ていて、customer_detailsのphone_numberを拾っていなかった。

修正は10分で終わった。

でも、この10分の修正に気づけたのは、実際に注文が入ったからだ。テストでは気づかなかった。テスト環境では「電話番号を含まない」テストデータで通していた。

「動くコード」と「使えるシステム」の間には、こういう隙間がある。

その隙間は、本物のお客さんが来て初めて見える。

---

「作る」と「届ける」は違う

1年間、コードを書いてきた。

データベースを設計して、決済フローを組んで、VTO（バーチャル試着）を連携させて、クーポン機能を入れて、レビューシステムを作って、在庫管理を自動化して、メール通知を整備した。

全部、「作る」仕事だった。

でも、注文が入った瞬間、世界が変わった。

「届ける」という仕事が始まった。

商品を梱包する。伝票を書く。宅配便の集荷を手配する。追跡番号を管理画面に入力して、発送通知メールを送る。

これは、コードでは自動化できない作業だった。

梱包しながら、不思議な気持ちになった。この箱の中に入っている服は、データベース上では「在庫数マイナス1」になった行だ。でも今、自分の手の中にあるのは、布と糸でできた実物だ。重さがある。温度がある。

データベースのUPDATE文と、この箱の重さ。

その間の距離を、今まで考えたことがなかった。

---

妻の一言

梱包作業をしていたら、妻が横から覗き込んだ。

「へえ、本当に売れたんだ。」

「うん。」

「嬉しい？」

少し考えた。

「嬉しいけど……なんだろう、怖いに近い。」

「怖い？」

「知らない人が、僕の作ったサイトを信用して、お金を払ってくれた。名前も住所もカード情報も入力して。その信頼に、応えなきゃいけない。」

妻は黙ってうなずいた。

「プログラムのバグは、直せる。でも、お客さんの信頼を壊したら、直すのは難しい。」

「大げさだね」と妻は笑った。「でも、そういうこと考えられるなら大丈夫だよ。」

そうだといいんだけど、と思いながら、丁寧にテープを貼った。

---

1個売れることの重み

Web4サービス、iOSアプリ4つ。全部合わせて、たぶんコードは数万行ある。

でも、1個売れたことの重みは、その数万行より重い。

コードは、理論上は正しく動く。テストも通る。画面も表示される。決済も走る。

でも、本当のお客さんが、本当のお金を払って、本当に商品を受け取るまで、そのシステムは「仮説」でしかなかった。

最初の1件が、仮説を現実にした。

基盤系エンジニアとして40年、数えきれないシステムを構築してきた。銀行のオンラインシステム、通信会社の基幹ネットワーク、大企業の業務システム。どれも「動いて当たり前」の世界だった。

でも、自分で作ったサービスに、自分のお客さんが来る。この感覚は、会社員時代には一度も味わったことがなかった。

---

運用が始まった

オープンから1週間。

毎朝、管理画面を見る習慣ができた。

アクセスログを確認する。mk_page_viewsテーブルに、昨日のPV数が記録されている。どのページが見られているか、どのデバイスからアクセスされているか。

在庫を確認する。人気の商品はどれか、在庫が少なくなっていないか。

レビューが投稿されていないか確認する。承認制にしてあるから、管理者が確認してから公開する。

Stripeのダッシュボードで、売上を確認する。

これが「運用する」ということか、と思った。

「作る」は楽しかった。毎日新しい機能が増えて、画面が変わって、できることが広がっていく。達成感がある。

「運用する」は、地味だ。毎朝同じ画面を見て、異常がないか確認する。問題があれば対処する。なければ、何もしない。

でも、この地味さに覚えがある。

基盤系エンジニア時代の、夜間オペレーション。システム監視。障害対応待機。何もなければ何もしない。でも、いつでも動けるように、常に見ている。

40年前と同じことを、68歳の今、自分のサービスでやっている。

規模は全然違う。でも、本質は同じだ。

「動き続けること」を守る仕事。

---

あなたへ

もしあなたが、何かを作っている途中なら。

「完成したら売れるだろうか」「誰も使ってくれなかったら」——そんな不安を抱えているかもしれない。

僕もそうだった。

でも、出してみないと、わからない。

お客さんは、完璧なシステムを求めているわけじゃない。欲しいものが、ちゃんと買えて、ちゃんと届くこと。それだけだ。

完璧なコードなんて、ない。

完璧な準備なんて、ない。

でも、出せば、お客さんが来る日がある。

動くコードは書けた。でも「届ける」ことの重さは、コードでは測れなかった。

その重さを知れたこと。

それが、68歳の春、一番大きな収穫だった。

---

*68歳、まだ走っている。*
*今日も管理画面を開いて、お客さんを待っている。*

*shop.kitemir.jp: https://shop.kitemir.jp/*
*マインドシード研究所: https://pyol.net/*
*Protect Your Only Life——こころに寄り添うテクノロジー*