> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/ja/2025/w22-differences-between-c-side-and-b-side.md).

# W22-C向けとB向けの違い

消費者向け、つまりCの視点を取り入れて、事業者向けのBの特殊性を理解し、整理する。これは今後も続けるべき仕事だ。さまざまな切り口を洗い出して抽象化し、B向けへの認識を深め、適切な時点で長期の発展に有利な技術判断を下せるようにする。

事業の本質的な複雑さという観点では、先週の田さんの言葉が的確だった。「Cの武器は決済、Bの武器は精算だ」。最終目標は同じで、トラフィックの利用を口座の利用へ変えることにある。ただし道筋が異なる。Cの出発点は加盟店決済の利用で、Bの出発点は精算の利用だ。「帳簿」「残高」「カード」といった重要な概念の認識は、BのほうがCより強い。それが「商売の帳簿」「統一残高」「ビジネスカード」といった製品の基盤にもなっている。

役割の分類でも、BはCより複雑だ。ユーザー層の区分を加えなくても、役割だけでKA、SMB、経営者、従業者、加盟店、履行者、ブランド企業、サービス事業者、サプライヤーなど、多くの軸がある。一つのアカウントを実際に操作しているのは、経営者かもしれないし、店舗のレジ担当者かもしれない。そのため、Cには対応する形がないB向け製品も多く、理解が難しい。配達員向けのサービス料の代理支払い、サービス事業者向けの分配精算などがそうだ。

供給側には厳しい事業コンプライアンスが求められ、その基準は上がり続けている。Cでは「消費のコンプライアンス」を考える場面はほぼなく、その概念さえない。一方、Bの「事業コンプライアンス」は、多面的で複雑な体系だ。複数の監督主体が関わり、資格、決済口座、税務など、それぞれの遵守が必要になる。Cにも決済口座やマネーロンダリング対策の事例はあるが、日々の仕事の主軸にはならない。多くの詐欺や資金洗浄は、最終的には精算経路から資金を引き出すことを目指す。実効性のある対策は、やはりこの経路で行うことになる。

事業範囲とサービス構成も、CとBではかなり異なる。私はこの違いの多くが、組織構造に由来する人為的な複雑さだと考えている。たとえば今のBには「基盤サービス」と「ウォレット」という二つの製品チームがある。しかしウォレットチームの役割は、すでに「ウォレットのトップページのトラフィック」を超えている。基盤サービスにも、Cでは対応先のない製品機能が多い。

フロントエンドで最も価値があり、難しい仕事は、コンテナーと基盤に集中している。長期の構想は、業務を接続する統一SDKを作り、すべてのサービスを標準的な動的拡張コンテナーEHCで動かすことだ。EHCはさまざまな拡張機能を提供し、KNBやRecceといったエンジン間の違いを吸収する。