割り勘アプリを自作した話 — 決済が本業なので、広告のない自分専用のやつが欲しかった

僕はベイエリアで働く日本人ソフトウェアエンジニアで、PayPalで数年、いまはフィンテックスタートアップのAtlasで、ずっと決済をやっています。台帳、残高、突合、丸め誤差。お金の移動は文字通り本業です。

割り勘に困っていたかというと、実はそんなに困っていませんでした。友達とはwalicaみたいな既存の割り勘サービスを使うこともあったし、別のグループとはExcelのシートを回して精算していました。どちらもちゃんと機能します。

じゃあなぜ作ったのか。理由は割とシンプルです。

• 広告が嫌だった。 お金の計算をしている画面の途中に広告が挟まるのが、どうにも好きになれない
• 入力したデータが何に使われるのか分からない。 誰と、いつ、どこで、いくら使ったか。割り勘データって、よく考えるとけっこう生々しい行動履歴です。無料サービスの裏でそれがどう扱われているのかは、外からは見えません
• 履歴を自分の手元に貯めたい。 旅行や飲み会の精算記録は、あとから見返すと意外と面白い自分のログです。サービスが終了したら消えるところには置きたくない
• そして正直に言うと、決済エンジニアとして、この領域は専門ど真ん中です。精算アルゴリズムも端数処理も仕事で毎日触っている問題で、自分の道具を自分で作らない理由がなかった

もう一つ、作るからにはtechに詳しくない人にもそのまま渡せるものにしたいと思っていました。アプリのインストールもアカウント登録もなしで、リンクを1本送ったら誰でも参加できる。この設計要件はあとで効いてきます。

そうしてできたのが Settli です。この記事はその「なぜ」と、実際に何ができるのかと、中で一番楽しいエンジニアリング——散らかった支払いの山を最小限の「誰が誰にいくら払う」リストに変換する精算アルゴリズム——の話です。

「データを渡したくない」と言いながら、友達のデータを預かる矛盾について

先に、自分でも引っかかっていた矛盾を書いておきます。「既存アプリはデータの行き先が分からないから嫌だ」と言っておきながら、Settliは友達の精算データを僕のFirebaseプロジェクトに保存します。友達から見れば、僕のアプリも「よく分からない誰かのサーバー」なのでは?

考えた結果、違いは「データを預かるかどうか」ではなく、インセンティブ構造だと思っています。広告モデルのサービスは、データを活用する経済的な動機を構造的に持ちます。個人ツールにはそれがありません。マネタイズしないので、データは精算の表示以外に使い道がない。しかも預かるデータ自体を最小にしてあります——メンバーは「Yudai」「Ken」みたいな打ち込んだ名前だけで、メールアドレスも電話番号もアカウントも存在しません。運営者の顔が見えて(僕です)、聞けば何を保存しているか答えられて、そもそも大したものを保存していない。友達に説明するならこれで十分だと思っています。

Settliは実際なにものか

SettliはFirebaseを裏に持つNext.jsアプリです。設計の軸は最初に書いた要件そのままで、幹事以外は誰もログインしなくていいこと。

 幹事                                友達
 ────                                ────
 グループ作成 ─┐
 (名前, 通貨,                        リンクかQRを受け取る
  メンバー名,   │                         │
  任意の4-6桁   │                         ▼
  パスコード)   │              /tools/settli/join/A7K2M9PX
       │        │                         │
       ▼        │                         ▼
 共有コード取得 ┘─────────▶   グループページが開く。
 "A7K2M9PX"                    登録なし。インストールなし。
       │                       (パスコード設定時のみ入力)
       ▼
 支払いをその都度記録
       │
       ▼
 「精算」→ 最小限の送金リスト
 「各自1回送金して終わり」

主な構成要素です。全部いまのコードに実在します。

• アカウント不要のグループ。 グループのcreatedByフィールドの型は文字通りstring | null。匿名での作成は「おまけモード」ではなく正規ルートです。匿名の幹事には最近触ったグループがlocalStorageに残り、ログインした場合はサーバー側に履歴ページが付きます
• 共有コードとQR。 全グループに8文字の共有コードが発行されます。生成に使う文字から0/Oと1/Iをあえて除外してあります。このコードは居酒屋のテーブル越しに読み上げられるものなので、「それゼロ? オー?」はサポートで対応するんじゃなくて、アルファベット側で潰すバグです。同じ理由でQRコードのエンドポイントもあります
• 任意のパスコード。 共有コードを知っていれば誰でも見られる、では困るグループのために4〜6桁のパスコードを設定できます。サーバーはクライアントの「確認済み」フラグを信用せず、リクエストごとに再検証します
• 4種類の割り方。 均等割り(メンバーごとの重み付き)、パーセント、固定額、口数。支払いごとに、誰が払ったか・誰が参加したか・カテゴリ・日付が残ります
• 複数通貨グループ。 9通貨対応。円の支払いとドルの支払いが混ざった旅行は、2枚の独立した精算シートになります。「合意した為替レート」を知っているふりはしません

重み機能には一言足しておきます。これこそ既存アプリでは手に入らない類のもので、<!-- TODO(Yudai): 実例に差し替え — 飲まない人は少なめ、子供は0.5人分など、実際のグループのルール -->「この人はこの支出については1人前未満で数える」という、うちのグループの暗黙ルールをそのまま機能にしたものです。グループチャットの口論がプロダクトの仕様になる。自作の配当です。

楽しい部分:精算アルゴリズム

ここがエンジニアリングの核です。旅行が終わると支払いの山が残ります。素朴にやると支払い単位の精算になって、23件の支払い×5人で最悪23×5回の送金。もちろん誰もそんなことはしないわけですが、じゃあ最小は何回か?

Settliは2段階でやります。

第1段階:すべてを1人1つの残高に畳む。 各支払いについて割り方どおりに負担額を計算し、人ごとに残高 = 払った合計 − 負担すべき合計を出します。正ならグループがその人に借りがある、負ならその人がグループに借りがある。総和は構成上ゼロになります。

第2段階:貪欲マッチング。 債権者と債務者をそれぞれ大きい順に並べ、いちばん大きい債務者がいちばん大きい債権者に払えるだけ払う、を繰り返します。

interface Balance {
  memberId: string;
  amount: number; // 正 = 債権者、負 = 債務者
}

function settle(balances: Balance[]): Transfer[] {
  const transfers: Transfer[] = [];
  // これ未満は気にしない。円なら¥0.5、小数通貨なら$0.005。
  const threshold = 0.5;

  const creditors = balances
    .filter((b) => b.amount > threshold)
    .sort((a, b) => b.amount - a.amount);
  const debtors = balances
    .filter((b) => b.amount < -threshold)
    .map((b) => ({ ...b, amount: -b.amount }))
    .sort((a, b) => b.amount - a.amount);

  let i = 0, j = 0;
  while (i < creditors.length && j < debtors.length) {
    const pay = Math.min(creditors[i].amount, debtors[j].amount);
    transfers.push({ from: debtors[j].memberId, to: creditors[i].memberId, amount: pay });
    creditors[i].amount -= pay;
    debtors[j].amount -= pay;
    if (creditors[i].amount <= threshold) i++;
    if (debtors[j].amount <= threshold) j++;
  }
  return transfers;
}

(実コードの簡略版です。本番はメンバー名や通貨ごとの丸め、複数通貨のグルーピングを持ち回りますが、アルゴリズム自体はこの通りです。)

4人旅行の例で見るとこうなります。

 第1段階のあとの残高:
   Aya   +9,000   (Airbnbを払った)
   Yudai +1,000
   Ken   -4,000
   Mei   -6,000

 貪欲マッチング (最大 vs 最大):
   Mei  ──6,000──▶ Aya      (Ayaの残りは +3,000)
   Ken  ──3,000──▶ Aya      (Aya精算完了。Kenの残りは -1,000)
   Ken  ──1,000──▶ Yudai

 23件の支払い → 3回の送金。

正直に書いておくべきことが2つあります。この手の記事がだいたい盛る部分です。

1. ループの各反復で少なくとも1人が完全に精算される(ペアのうち残高が小さかった側)ので、n人に対して送金は最大n − 1回。これが貪欲法の保証です
2. 貪欲法は常に理論上の最小回数とは限りません。 残高の中に「ちょうど打ち消し合う部分集合」があるケースでは、完璧なマッチャーなら送金をもう1回減らせます。ただし真の最小を求める問題は組み合わせ爆発するし、5人の友達にとってその差は最大でも送金アプリのタップ1回分。どこで最適を諦めたかを理由付きで把握しておく——エンジニアリングの大半はこれだと思っています

決済エンジニアの余談:端数は誰が食うのか

¥10,000を3人で割ると¥3,333.33…。誰かが1円を食います。仕事では、この配賦の丸めというクラスの問題は突合レポートと殺気立った経理Slackの主成分です。割り勘アプリでも結局ポリシーは選ばないといけない。ただ、友達向けにはより平和なポリシーを選べます。

Settliのポリシーは3層です。

• 通貨ごとに丸める。 円とウォンは実用的な補助単位がないので整数に、ドル系はセントに。日本人に「¥3,333.33」を見せた割り勘アプリは、その時点で信用を失います
• 支払い単位ではなく残高レベルで丸める。 取り分は浮動小数点のまま残高に合算し、最後に一度だけ丸めます。23件の支払いをまたいで丸め誤差を蓄積させないためです
• しきい値未満のダストは黙って消す。 精算ループは¥0.5未満の残余を無視します。実質、丸めダストの債権者が黙って免除する形です。友達同士ならこれが正解——¥1の振込を受け取りたい人はいません。仕事の本番台帳でこれをやったら監査指摘です(端数は丸め勘定で追跡して決定的に配賦します)。同じ数学、違う社会契約。平日は1セントも消えないことを保証する仕事をして、週末は50銭を意図的に見逃すコードを書いている。僕はこれが本当に面白いと思っています

表示レベルのルールもあって、円建ての推奨送金額は¥10単位に丸めます。「¥4,237送って」は技術的には正しいけど、社会的には正気じゃないので。

正直なトレードオフ

自作は「より良い」という意味ではありません。コスト構造が違うだけです。手放したもの:

• モバイルアプリなし、プッシュ通知なし。 SettliはKenに「まだ¥4,000残ってるよ」と催促してくれません。それはグループチャットの仕事です。ここは既存アプリの明確な勝ち
• レシートスキャンなし、銀行連携なし。 金額は手打ちです。週末旅行なら問題なし。毎日の家計簿に使ったら嫌になると思います
• 精算は提案止まり。 誰が誰にいくら払うかは出しますが、実際のお金はVenmoかPayPayか現金で動きます。決済エンジニアの割り勘アプリが決済を動かさないのは自覚していますが、本物の送金を組み込むことはKYCとコンプライアンスと責任を背負うことで、このツールが気楽である理由のすべてはそれを背負っていないことにあります
• メンテは永遠に僕。 依存パッケージにCVEが出てもFirebaseが値上げしても、ベンダーはいません。「勝手に劣化させられない」の裏面は「起きる問題は全部僕の問題」です
• アクセス制御は信頼ベース。 共有コード+任意パスコードはケイパビリティであって、本人確認ではありません。飲み会の割り勘には正しい強度で、会社をこれで運営はしません

得たもの:友達側の手順が「リンクを踏む」だけのツール。うちのグループの実際のルール(重み)がそのまま仕様になっているツール。データの置き場所と使い道を自分で説明できるツール。広告ゼロ。そして、不満に気づいたその週に直せるツール——フィードバックフォームとメンテナが同一人物なので。

次に作りたいもの

• 送金単位の精算トラッキング — グループ全体の「精算済み」だけでなく、提案された個々の送金に「支払い済み」を付けられるように
• 単一通貨ビュー(オプトイン) — 「合意レートで全部円に換算」モードを付けて、複数通貨の旅行を1枚の精算シートに畳む
• 定期グループ — 毎月のシートを自動アーカイブする常設の「月例飲み会」グループ

ここから試せます: meetyudai.com/tools/settli — 登録不要です。それが設計の出発点だったので。

まとめ

• 自作の動機は「困っていた」より「気持ち悪かった」。 既存サービスやExcelでも精算はできていた。でも、広告と、データの行き先が見えないことと、履歴が他人のサーバーにしか残らないことが気持ち悪かった。個人ツールはその気持ち悪さを消せる
• 「データを預かる矛盾」は預かる量とインセンティブで答える。 名前しか預からない、マネタイズしない、運営者に顔がある。友達に説明できる説明を持っておく
• 貪欲min-cash-flowは30行で、送金 ≤ n−1回を保証する。 理論上の最適ではないケースを把握したうえで、理由付きで「気にしない」と決める
• 丸めは算術ではなくポリシー。 通貨ごとに丸め、残高レベルで丸め、端数は誰が食うかを明示的に決める。友達同士なら「50銭未満は誰も食わない」でいい。本番台帳ではだめ
• 自作の配当は機能ではなくフィードバックループ。 機能では既存アプリが勝つ。うちのグループのルールがそのまま仕様になること、不満がPR1本で直ること——ここで勝つ