TL;DR
- 全銀フォーマット（120バイト固定長）とJSON/CSVを相互変換するAPIサービスを個人開発しようとした
- 競合分析、技術設計、UI作成まで準備が進んでいた
- 全銀ネットが2030年を目標に新決済基盤の構築を検討中というニュースを見て、断念した
- 設計過程で得た知見を供養として残しておく
きっかけ
Zennで「Claude Codeに月商300万のSaaSの全コードを書かせている」という記事を読んだ。その人がやっていたのは、某海外製ERPのSOAP/XMLインターフェースをRESTful JSONに変換するプロキシサーバーで、エラーログSEOで集客しているという内容だった。
この戦略を参考に、自分も「レガシーな仕様の痛みを代行するニッチなAPI」を作ろうと考えた。いくつかの候補を検討した結果、全銀フォーマットの変換APIに決めた。
選んだ理由はシンプルで、全銀フォーマットを触ったことがある人なら全員が経験している「あの面倒さ」が明確な痛みだったからだ。120バイト固定長、CP932、半角カナ、ゼロパディング、スペースパディング、バイト長と文字数の不一致。「全銀フォーマット VBA 動かない」で検索している人がいると思われる。
既存の競合
設計を始めてすぐ、Qiitaで「Zengin-Modern Gateway API」という記事を見つけた。2026年3月に公開されたばかりで、RapidAPI上でJSON↔全銀固定長レコードの変換APIを提供していた。
分析してみると、いくつかの隙間があった。
- 入力がBase64(CP932)前提で、ユーザーが事前にエンコーディングを自力で処理する必要がある
- CSV非対応
- 最安の有料プランが月額5万円
- Web上で試せるプレイグラウンドがない
- 料金が非常に高い
ここを突けば差別化できると判断して、設計を進めた。
設計したもの
コンセプト: 「ゼロエンコーディング」
最大の差別化ポイントは、UTF-8のJSONを投げるだけで全銀ファイルが返ってくる体験。CP932変換、全角カナ→半角カナ変換、バイト長パディング、禁止文字検出をすべてAPI側で吸収する。
POST /api/v1/generate
Content-Type: application/json
{
"format": "sogo_furikomi",
"header": {
"type_code": "21",
"consignor_code": "1234567890",
"consignor_name": "カ)サンプルショウジ",
"transfer_date": "0401",
"bank_code": "0001",
"bank_name": "ミズホ",
...
},
"data": [
{
"bank_code": "0005",
"bank_name": "ミツビシユーエフジエイ",
"recipient_name": "ヤマダ タロウ",
"amount": 150000
}
]
}
全角カナで「ミツビシユーエフジエイ」と入力しても、API内部で半角カナに変換してくれる。
対応フォーマット
全銀フォーマットは種別が多い。全銀協の公式仕様書に33種類ほど定義されているが、実務で需要のほとんどをカバーする7種別に絞った。
| format値 | 種別コード | 名称 |
|---|---|---|
| sogo_furikomi | 21 | 総合振込 |
| kyuyo_furikomi | 11 | 給与振込 |
| shoyo_furikomi | 12 | 賞与振込 |
| koza_furikae | 91 | 口座振替（依頼） |
| koza_furikae_result | 91 | 口座振替（結果） |
| furikomi_nyukin | 01 | 振込入金通知 |
| nyushukkin_meisai | 03 | 入出金取引明細 |
振込系（総合・給与・賞与）はヘッダー・データ・トレーラ・エンドのレコード構造がほぼ同一で、種別コードとEDI関連フィールドの有効/無効だけが違う。口座振替はデータレコードに「振替結果コード」が追加される。振込入金通知と入出金取引明細はヘッダー構造自体が異なり、120バイトのフォーマットAと200バイトのフォーマットBが存在する。
設計を進める中で気づいたが、この仕様の複雑さ自体がビジネスの堀になる。
エンコーディング自動判定
CSV入力時、文字コードがUTF-8とは限らない問題にも対処した。日本語Windows環境のExcelで「CSV保存」するとデフォルトCP932になる。古い社内システムからのCSV出力はEUC-JPの場合もある。
encodingパラメータで auto / utf-8 / shift_jis / euc-jp を指定可能にし、auto はBOM検出→UTF-8試行→EUC-JPパターン検出→CP932フォールバックの優先順で判定する設計にした。
技術スタック
| 層 | 技術 |
|---|---|
| APIフレームワーク | Hono |
| ランタイム | Cloudflare Workers |
| DB / 認証 | Supabase |
| 決済 | Stripe Billing |
Cloudflare Workers上ではNode.jsのBufferが使えないため、TextDecoder（shift_jis、euc-jpに対応している）で文字コード変換を行う設計にした。
Webプレイグラウンド
APIだけでなく、ブラウザ上でJSON/CSVを貼り付けると全銀ファイルを生成・検証できるWebツールも設計した。5つのタブ構成。
- JSON → 全銀
- CSV → 全銀
- 全銀 → JSON
- 全銀 → CSV
- Validate
生成された120バイトレコードの各フィールドを色分けして表示するレコードビジュアライザも実装した。マウスオーバーで「委託者名 byte[14–53] 40B」のようにバイト位置が確認できる。
これはSEO的にも強力で、「全銀フォーマット 変換 ツール」「全銀フォーマット チェック」で検索した人をそのまま無料ツールとして獲得し、APIへの導線にする設計だった。
断念した理由
設計がほぼ完了し、Claude Codeに仕様書から少し実装させていた段階で、このニュースが目に入った。
全銀ネットが現行の全銀システムに代わる新たな資金決済システムの構築を検討しており、2030年の稼働を目標としている。ISO20022対応、リアルタイム決済、着金確認機能などが盛り込まれる方向だ。
記事には「既存の全銀フォーマットについても一定の継続利用を可能とする設計が検討されている」とある。つまり即座に廃止されるわけではない。しかし、新規システムへの移行は2030年以降段階的に進み、2038年には現行システムからの機能集約も検討されるとのこと。
冷静に考えると、これから新規にビジネスとして立ち上げるサービスの基盤が、4年後に縮小トレンドに入ることが確定しているのはリスクが大きい。全銀フォーマットの痛みは確かに存在するが、その痛み自体が消える方向に向かっている。
レガシーの痛みを解消するサービスは、そのレガシーが生き続ける前提で成立する。レガシーが公式に退場する計画がある場合、そこに賭けるのは筋が悪い。
学んだこと
設計の後、実装に入ってすぐに断念したが、得たものは多かった。
全銀フォーマットの仕様の深さ。表面的には「120バイト固定長」だが、掘ると33種類のフォーマット、フォーマットA(120B)/B(200B)の区別、和暦YYMMDD、銀行ごとの微妙な差異（みずほは種別コードが1970始まり、三井住友は1990始まりなど）と、想像以上に複雑だった。
エンコーディングの沼。CP932とShift_JISは同じものだと思っていたが、厳密には異なる。MySQLでもcp932とsjisは別の文字セットとして扱われている。Cloudflare WorkersのTextDecoderがshift_jis指定でCP932相当の変換をしてくれるのは助かった。
競合分析の重要性。既に似たAPIを作っている人がいたが、設計を比較することで明確な差別化ポイント（ゼロエンコーディング、CSV対応、破壊的低価格、プレイグラウンド）が見えた。競合がいること自体は悪いことではなく、むしろ市場が存在する証拠だった。
タイミングの怖さ。技術的に正しく、需要がある領域でも、外部環境の変化で成立しなくなることがある。設計にフルコミットする前にマクロトレンドを確認する癖をつけるべきだった。