11月23日にTECH HUB YOKOHAMAで行われたJP_Stripes Connect 2025に参加して来ました。

・はじめに

JP_Stripesとは、決済プラットフォームを提供するStripeの日本のコミュニティです。今回初めて参加しました。

3年ほど前、うちの会社で手がけたある案件で、Stripeにはガッツリと関わりました。某宗教法人様の世界中にいる会員からの会費徴収の仕組みをkintoneとWordPress、そして、Stripeとfreeeを組み合わせて実現しました。その際、Stripeの仕様ともがっぷり取り組みました。

ただ、それ以来、Stripeとはご縁がありませんでした。別に避けていたわけではありません。その間にもkintoneと決済サービスと組み合わせる案件はいくつも手掛けました。ですが、お客様が他の決済サービスを採用するケースが続いたため、Stripeを扱う機会がなかったのです。

今回、JP_Stripesの運営メンバーである岡本さんからのDMをいただきました。良い機会なので、初めて参加しました。

ただ、私はStripe関係に知り合いがいません。岡本さんともオンライン上でやりとりしただけで、会うのは今回初めてです。
Stripeエバンジェリストの小島さんとは、各地のCLSでお会いしました。しかし、他の方は誰も知らない状態でした。

未知のコミュニティに出ると得られる効用については、
note
に書いておきました。

・コミュニティで運用を学ぶ意義

さて、ここからはJP_Stripesから得た気づきに触れます。

まず、私にとって印象に残ったのは、コミュニティでは運用が学べることです。
運用を学ぶ。実は、kintoneコミュニティでは当たり前のことです。
なぜなら、kintoneコミュニティにはユーザーの立場で参加される方が多く、そうした方々は普段から日常使いの運用が当たり前です。むしろ当たり前のように運用面の苦労が発表されます。ありふれすぎていて、運用を学んでいると認識することも稀です。

例えば、kintoneではデータさえ本番に近いものを用意できれば、アプリを簡単にテンプレートでコピーできます。なので、運用を想定したテストが容易に行えます。しかもそれらは自社内の運用であり、不特定多数の方が対象ではありません。

ですが、Stripeのような決済サービスの場合、課金や決済にまつわる運用パターンは千差万別です。サービスの質によって、扱う商品によって、扱う決済手段や入金チャネルによって変わります。
仮にリファレンスだけで実装ができたとしても、それだけでは決済サービスの基礎ができただけなのです。そこからようやく運用についてのパターンを踏まえた実装が求められます。
追体験も予測もできないため、様々なパターンをテストすることも困難で、実運用をこなしながら、様々なパターンを学び、習得し、円滑な決済運用が回るように整えていく必要があります。

これは、公開が前提の決済インターフェースとクローズドなデータ取り扱いを主とするkintoneの違いかもしれません。
そうした運用に関する知見の習得は、コミュニティでしか得られない生きた情報です。コミュニティには、様々な決済サービスに携わった方や運用上での苦労を重ねた方もおられるため、様々なケーススタディーが得られます。

kintoneコミュニティでは、上に書いたような理由で、運用のノウハウが当たり前に公表されます。が、他の技術コミュニティ、特に決済を扱うコミュニティにおいては、その知見が重宝されることに改めて気づかされました。

また、小島さんが触れておられた多様なフィードバックとエモーショナルなパワーがもらえるコミュニティの効能は、コミュニティ参加に消極的なすべての技術者に伝えたいです。

・DevOps、RevOpsについて

登壇者セッションのタイトルにRevOpsが2回ほど使われました。実はkintone界隈ではDevOpsも含め、これらの言葉を聞くことがあまりありません。

RevOpsとは、Revenue Operationsのこと。つまり、企業の収益最大化を図るため、各部門を統合した経営戦略を指します。例えば、顧客管理とマーケティング施策、売上や入金状況などの情報を統合した一群のオペレーションです。
特にオンラインサービスを提供する企業の場合、マーケティングから決済画面への誘導、そして決済からサービス開始に至るまでの流れが連動します。そして、それらを総括する必要があります。Stripeは決済サービスとして、その流れの中で重要な位置を占めます。

kintoneは、決済機能を備えていません。外部のサービスに任せる必要があります。基幹処理も別の基幹システムに任せることが多いです。オープンなWebサイトとして公開するような設計にはなっていません。つまり、kintoneの特性上、主要な業務データやサービスを連携し、主要なデータ処理の周辺や隙間を埋める用途に使われることが多いのです。
そのため、RevOpsの言葉は、kintone界隈では使われないのでしょう。

kintoneのデータ容量の制限もあり、全体のデータを俯瞰して見られないことも、kintone界隈でRevOpsが語られない理由かもしれません。

もちろん、サマライズしたデータをkintoneに渡し、ダッシュボード的に使うことはできます。
ただ、私は無理にkintoneを基幹業務に使う必要がないと思います。基幹には基幹の、kintoneにはkintoneの良さがあります。
例えば、人体にはたくさんの血管があります。動脈や静脈をそうした基幹システムに例え、それ以外の毛細血管をkintoneが担うと考えればどうでしょう。
Wikipedia
によると、人体の血管に占める90%から99%は、毛細血管が占めるといいます。
また、
看護roo
によると、
「血管の面積比において、動脈：毛細血管：静脈でおよそ1：700：2。また、全身の血液量の分布は、動脈20%、毛細血管5%、静脈75%である。」
と書かれています。それでいいと思うのです。私はkintoneが主要な血管ではなく、毛細血管の役割を担い、組織の隅々を潤していく未来を想像しています。

Stripeの場合、経営の根幹に関わる入金・決済に直結しています。ですから、このRevOpsの考えが重要なことはよくわかります。
この気づきに至れたことも、JP_Stripes Connect 2025に参加して良かったことです。

・機密データをStripeに任せる

今までに、私は幾つもの決済サービスとkintoneの組み合わせの実装に携わってきました。それらで共通して心掛けてきたのは、クレジットカード番号等の情報は一切kintoneに持たせないことです。
言うまでもなく、kintoneは堅牢です。
ただ、kintoneにそうした機密データを置くことで、うちの会社にもその管理コストがのしかかります。
それは経営体力の観点から避けたい。では、初めから機密情報は別のサービスに任せてしまう。それが私の判断でした。

今回、登壇された皆様からも、そうした知見の共有がありました。Stripeをデータベースとして使い、機密情報も含めて任せてしまう認識は、私の考えの裏付けになりました。

・その他の技術的な気づき

後は技術的な話の気づきに触れます。
まず、StripeのカスタマーポータルのページをJavaScriptでカスタマイズできることは知らなかったです。
また、AI活用もかなり進んでいることは、当然とはいえ、改めて認識を深めました。MCPサーバーではなく、ACP(Agentic Commerce Protocol)サーバーとの考えを知れたのはよかったです。
つまり、これからの決済系の構築には、決済サービスの知見が蓄積され、そこへのアクセスルートが整備されたACPサーバーを利用することで、決済関係の情報をAIと連携しましょう。そうすれば構築がより楽になる。このACPサーバーは、今後使うことになりそうです。
それと、社内用MCPサーバーの活用にも刺激を受けました。うちの会社が長年貯めてきたkintone構築のノウハウを社内限定MCPサーバーを介して取得できるような整備を急ぎます。