こんにちは。代表のあいび〜です。
先日、ivybot.jp と ryujin-mist.com の2サイトに、仮想通貨決済（BTC/ETH/XRP/LTC/BCH）を追加しました。今回は少し視点を変えて、この機能をどう開発したのか、技術的な裏側を紹介したいと思います。
なぜ仮想通貨決済を追加したのか
クレジットカードや銀行振込に加えて、より多様な決済手段を選べるようにしたい――というのが出発点でした。特に仮想通貨決済は、対応できる事業者がまだ限られている中で、ユーザーの選択肢を広げる意味でも取り組む価値があると判断しました。
開発のパートナーとしてのClaude Code
今回の実装では、Claude Code を使ってコードを書き進めました。要件を言葉で伝えると、それを実装に落とし込んでくれる、という体験は正直かなり新鮮でした。
大まかな流れとしては、
- 「どの通貨に対応するか」「どのサイトで使うか」といった要件をまず整理する
- Claude Codeに実装方針を相談しながら、コードを書いてもらう
- 出てきたコードを実際に動かして確認し、気になる点はその場でフィードバックして直してもらう
というサイクルを繰り返しました。人間が一からすべて書くのに比べて、実装のスピードが大きく変わったのはもちろんですが、それ以上に「設計の選択肢を一緒に検討できる」ことが助かりました。
「複数通貨・複数サイト対応」の設計もClaudeでスムーズに
今回の開発で一番頭を悩ませたのは、決済ゲートウェイのような外部サービスを使わず、各ブロックチェーンのノードやウォレットと自社で直接連携する形を選んだことです。
BTC・ETH・XRP・LTC・BCHはそれぞれ仕組みが異なります。たとえば、
- 着金の確認方法や、必要な承認（コンファメーション）の数がチェーンごとに違う
- アドレスの生成やウォレットの管理方法もチェーンごとに別々の実装が必要
- 手数料の考え方や反映タイミングも通貨によって異なる
といった違いを、共通の決済フローの中にどう吸収するかが設計上の一番のポイントでした。
ここでは、「通貨ごとの個別処理」と「サイト共通の決済フロー」を分けて設計する方針を採りました。通貨固有のロジック（ノードとの通信、着金判定など)は通貨ごとのモジュールに閉じ込め、注文管理や決済ステータスの更新といった共通処理とは切り離す形です。こうすることで、ivybot.jpとryujin-mist.comという2つのサイトでも、共通のフローに乗せつつ、サイトごとの設定(.envと)と実行ライブラリだけを追加すれば済むようにしました。
こうした設計方針も、実はClaude Codeとやり取りしながら固めていきました。「この通貨を増やすときに、どこまで既存コードに手を入れずに済むか」といった観点で、何度か実装を出してもらっては比較する、という試行錯誤を重ねています。
Claudeを使ってみて感じたこと
今回開発を進めてみて感じたのは、Claudeは単に「コードを書いてくれる」だけでなく、設計の相談相手としても機能してくれる、ということです。特に今回のように「複数の異なる仕様を、なるべくシンプルな共通構造にまとめたい」というような、正解が一つに定まらない設計判断において、複数の案を出してもらいながら検討できたのは大きかったです。
もちろん、最終的な設計判断や、セキュリティ・お金を扱う部分の確認は人の目でしっかり行っています。ただ、実装のスピードと、設計を検討する際の思考の幅、その両方を広げてくれるパートナーとして、今後も開発にうまく取り入れていきたいと考えています。
おわりに
今回追加した仮想通貨決済が、少しでも多くのユーザーの選択肢を広げるものになれば嬉しいです。今後も、こうした開発の裏側についても機会があれば発信していきたいと思います。
