日本で法人が銀行振込をするとき、避けて通れないファイル形式がある。
全銀フォーマット。
正式には「全国銀行協会制定 データ伝送用レコード・フォーマット」。1973年に全銀システムが稼働した頃から使われている、120バイト固定長のテキストファイルだ。
みずほ、三菱UFJ、三井住友、りそな。メガバンクから地方銀行、信用金庫まで、日本国内の預金取扱金融機関1,134機関、29,519店舗が対応している。事実上の国家標準だ。年間19.5億件、約3,474兆円の送金がこのフォーマットで処理されている。
ネットバンキングの管理画面で1件ずつ振込先を手入力する代わりに、このフォーマットのファイルをアップロードすれば、30件だろうが100件だろうが一括で振込が完了する。
問題は、この仕様を正確に理解している人が極めて少ないことだ。
経理担当者は「VBAで変換すればいい」と言われるが、VBAのコードが何をしているか分からない。エンジニアは「120バイト固定長」と聞いても、具体的にどのバイトに何が入るか知らない。銀行のマニュアルは30ページのPDFで、読みたい箇所にたどり着く前に挫折する。
この記事は、全銀フォーマットの仕様を1ページで完全に理解するために書いた。経理担当者が「何が起きているか」を理解するために。エンジニアが「正しく実装するために」。そしてExcel VBAのマクロを触る勇気が出ないすべての人のために。
目次
- 全銀フォーマットとは何か
- 歴史 — なぜ50年前の仕様がまだ現役なのか
- ファイル全体の構造
- ヘッダレコード（120バイト）
- データレコード（120バイト）
- トレーラレコード（120バイト）
- エンドレコード（120バイト）
- 種別コード一覧
- 文字コードと使用可能文字
- 文字変換ルール
- 法人格略語の完全一覧
- 実装時の落とし穴 12選
- 実際のデータ例
- 銀行ごとの差異
- 全銀EDIシステムとの関係
- よくある質問
全銀フォーマットとは何か
全銀フォーマットは、企業が銀行に振込指示を出すときのデータ形式だ。
「誰が」「どの銀行の」「どの口座に」「いくら振り込むか」を、1行120バイトのテキストで表現する。このファイルをインターネットバンキングやファームバンキング（FB）にアップロードすると、銀行がファイルの中身を読み取って振込を実行する。
使うのはこんな場面だ。
- 月末に取引先30社へまとめて支払う（総合振込）
- 毎月25日に従業員の給与を振り込む（給与振込）
- 年2回の賞与を振り込む（賞与振込）
- 顧客の口座から引き落とす（口座振替）
どの業務でも、レコードの構造はほぼ同じ。ヘッダに書く「種別コード」が変わるだけだ。
歴史
1973年：全銀システム稼働
全銀フォーマットの歴史は、全銀システムの歴史そのものだ。
1973年4月9日、全国銀行データ通信システム（全銀システム）が稼働した。NTTデータが開発・運営する、日本国内の銀行間送金を処理するオンラインネットワーク。それまで銀行間の送金は手形交換所を経由する物理的な仕組みだったのが、電子的に処理できるようになった。
このとき定められたデータ伝送用のフォーマットが、全銀フォーマットだ。
なぜ120バイトなのか
1970年代のコンピュータは、パンチカード（80桁）やラインプリンター（132桁）を基準にデータ長を決めていた。120バイトという数字は、当時の通信回線の効率とメインフレームの処理単位を考慮して決められたと言われている。
50年後の今も変わっていない。
世代を重ねるシステム
全銀システムは世代を重ねて進化してきた。
| 世代 | 稼働年 | 1日の処理能力 |
|---|---|---|
| 第1次 | 1973 | 100万件 |
| 第2次 | 1979 | 140万件 |
| 第3次 | 1987 | 500万件 |
| 第4次 | 1995 | 1,350万件 |
| 第5次 | 2003 | 1,500万件 |
| 第6次 | 2011 | 2,500万件 |
| 第7次 | 2019 | 3,000万件 |
システムは更新されても、ファイルフォーマットは変わらない。120バイト固定長のテキストファイル。1973年に書かれたフォーマットのデータを、2026年の最新システムがそのまま読み取れる。
互換性というのはこういうことだ。
2018年：モアタイムシステム
2018年10月、モアタイムシステムが稼働。それまで平日15時までだった振込の着金が、24時間365日リアルタイムになった。ただし、全銀フォーマット自体は変わっていない。
2023年：50年で初めての大規模障害
2023年10月、第7次システムへの更改時に大規模障害が発生。566万件の振込に影響。富士通メインフレーム上のCOBOLで書かれたRCプログラムの移行時に、テーブルデータの不整合が起きたのが原因だった。
この障害を受けて、第8次全銀システムの稼働は2028年5月に延期され、段階移行方式に変更された。
全銀フォーマットは消えるのか
消えない。少なくとも当分は。
全銀EDIシステム（2018年稼働）はXML形式（ISO 20022）にも対応しているが、120バイト固定長の全銀フォーマットが廃止されるわけではない。APIゲートウェイの導入も進んでいるが、ファイルアップロード方式は各銀行のIB/FBで引き続きサポートされている。
1,134の金融機関が対応しているフォーマットを廃止するのは、事実上不可能だ。
ファイル全体の構造
全銀フォーマットのファイルは、4種類のレコードで構成される。
┌─────────────────────────────────────┐
│ ヘッダレコード （データ区分: 1） │ ← 1件だけ
├─────────────────────────────────────┤
│ データレコード （データ区分: 2） │ ← 振込先の数だけ（1〜999,999件）
│ データレコード （データ区分: 2） │
│ データレコード （データ区分: 2） │
│ ... │
├─────────────────────────────────────┤
│ トレーラレコード （データ区分: 8） │ ← 1件だけ
├─────────────────────────────────────┤
│ エンドレコード （データ区分: 9） │ ← 1件だけ
└─────────────────────────────────────┘すべてのレコードが120バイト。例外はない。
レコードの先頭1バイトが「データ区分」で、そのレコードが何者かを示す。1ならヘッダ、2ならデータ、8ならトレーラ、9ならエンド。銀行のシステムはまずこの1バイトを読んで、レコードの種類を判定する。
各レコードの間にはCR+LF（改行コード）が入る。ただし、銀行によってはLFのみ、または改行なしの場合もある（後述）。
ヘッダレコード
ヘッダレコードは「誰が」「いつ」「どの銀行から」振り込むかを宣言するレコードだ。ファイルの先頭に1件だけ書く。
バイト定義（120バイト）
| 位置 | 桁数 | 属性 | 項目名 | 内容 |
|---|---|---|---|---|
| 1 | 1 | N | データ区分 | 固定値 1 |
| 2-3 | 2 | N | 種別コード | 21=総合振込, 11=給与振込 等 |
| 4 | 1 | N | コード区分 | 0=JIS, 1=EBCDIC |
| 5-14 | 10 | N | 振込依頼人コード | 銀行が採番する企業識別コード |
| 15-54 | 40 | C | 振込依頼人名 | 半角カナ、左詰め、後ろスペース埋め |
| 55-58 | 4 | N | 振込日 | MMDD形式（年は含まない） |
| 59-62 | 4 | N | 仕向銀行番号 | 統一金融機関コード（4桁） |
| 63-77 | 15 | C | 仕向銀行名 | 半角カナ、左詰め、後ろスペース埋め |
| 78-80 | 3 | N | 仕向支店番号 | 支店コード（3桁） |
| 81-95 | 15 | C | 仕向支店名 | 半角カナ、左詰め、後ろスペース埋め |
| 96 | 1 | N | 預金種目 | 1=普通, 2=当座, 4=貯蓄 |
| 97-103 | 7 | N | 口座番号 | 右詰め、前ゼロ埋め |
| 104-120 | 17 | C | ダミー | スペース（将来拡張用） |
属性の読み方：
- N（Numeric）：数字のみ。右詰め、余った桁はゼロ埋め。
- C（Character）：文字。左詰め、余った桁はスペース埋め。
各フィールドの解説
種別コード（2-3バイト目）
これが業務の種類を決める。総合振込なら21、給与振込なら11。詳細は後述の「種別コード一覧」を参照。
振込依頼人コード（5-14バイト目）
銀行との契約時に発行される10桁のコード。企業ごとに固有。このコードが間違っていると、ファイルごと拒否される。銀行によっては「会社コード」「委託者コード」と呼ぶ。
振込依頼人名（15-54バイト目）
自社の名前を半角カナで書く。40バイトと広いが、濁点・半濁点が1バイトずつ消費するので、長い社名は意外とギリギリになる。
例：ｶ)ﾐﾂﾋﾞｼｼﾖｳｼﾞ （株式会社三菱商事 → 14バイト消費）
振込日（55-58バイト目）
MMDD形式。3月15日なら0315。年は含まれない。「2026年」は別の場所（銀行との契約・通信プロトコル）で管理される。
仕向銀行番号・仕向支店番号
自分の口座がある銀行・支店のコード。三菱UFJ銀行なら0005、みずほ銀行なら0001。全国銀行協会が管理する統一金融機関コードを使う。
データレコード
データレコードは「どこに」「いくら」振り込むかを指定するレコードだ。振込先1件につき1行。30社に振り込むなら30行。
バイト定義（120バイト）
| 位置 | 桁数 | 属性 | 項目名 | 内容 |
|---|---|---|---|---|
| 1 | 1 | N | データ区分 | 固定値 2 |
| 2-5 | 4 | N | 被仕向銀行番号 | 振込先の金融機関コード |
| 6-20 | 15 | C | 被仕向銀行名 | 半角カナ、左詰めスペース埋め |
| 21-23 | 3 | N | 被仕向支店番号 | 振込先の支店コード |
| 24-38 | 15 | C | 被仕向支店名 | 半角カナ、左詰めスペース埋め |
| 39-42 | 4 | N | 手形交換所番号 | 通常 0000 |
| 43 | 1 | N | 預金種目 | 1=普通, 2=当座, 4=貯蓄 |
| 44-50 | 7 | N | 口座番号 | 右詰め、前ゼロ埋め |
| 51-80 | 30 | C | 受取人名 | 口座名義（半角カナ）、左詰めスペース埋め |
| 81-90 | 10 | N | 振込金額 | 右詰め、前ゼロ埋め（最大約100億円） |
| 91 | 1 | N | 新規コード | 1=初回, 2=変更, 0=その他 |
| 92-101 | 10 | C | 顧客コード1 / EDI情報 | 用途は識別表示による |
| 102-111 | 10 | C | 顧客コード2 / EDI情報 | 用途は識別表示による |
| 112 | 1 | C | 振込指定区分 | 7=電信振込, 8=文書振込 |
| 113 | 1 | C | 識別表示 | Y=EDI情報使用, スペース=不使用 |
| 114-120 | 7 | C | ダミー | スペース |
各フィールドの解説
受取人名（51-80バイト目）
ここが最もトラブルが多い。口座名義と1文字でも異なると振込が失敗する。
30バイトしかないのに、濁点・半濁点が1バイトずつ食う。「株式会社山田物産 東京営業所」を半角カナにすると：
ｶ)ﾔﾏﾀﾞﾌﾞｯｻﾝ ﾄｳｷﾖｳｴｲｷﾞﾖｳｼﾖ
これで28バイト。ギリギリ入る。でも「ガ」は「ｶ」+「ﾞ」で2バイト、「ブ」は「ﾌ」+「ﾞ」で2バイト。濁音が多い社名は30バイトを超えやすい。
振込金額（81-90バイト目）
10桁。最大9,999,999,999円（約100億円）。1万円なら0000010000。右詰めで前にゼロを詰める。小数点はない。日本円には銭がないので、常に整数。
新規コード（91バイト目）
初めてその口座に振り込むときは1。口座番号の変更があったら2。2回目以降で変更がなければ0。銀行によっては無視されるが、正しく設定しておくのが安全。
振込指定区分（112バイト目）
7が電信振込（テレ振込）で、現在のデフォルト。8は文書振込で、旧来の書面ベースの処理。2026年の今、文書振込を使うケースはほぼない。迷ったら7。
識別表示とEDI情報
113バイト目がYの場合、92-111バイト目の合計20バイトが「EDI情報」として扱われる。企業間取引の付加情報（請求番号、明細情報など）を格納できる。Yでなければ通常の顧客コード。
これは全銀EDIシステム（2018年稼働）に関連する機能で、使わない場合はスペースで埋めておけばよい。
トレーラレコード
トレーラレコードは、データレコードの合計を記録するレコード。チェックサムのような役割だ。
バイト定義（120バイト）
| 位置 | 桁数 | 属性 | 項目名 | 内容 |
|---|---|---|---|---|
| 1 | 1 | N | データ区分 | 固定値 8 |
| 2-7 | 6 | N | 合計件数 | データレコードの総件数 |
| 8-19 | 12 | N | 合計金額 | 振込金額の総合計 |
| 20-120 | 101 | C | ダミー | スペース |
データレコードが30件で、合計金額が1,500,000円なら：
- 合計件数：
000030 - 合計金額：
000001500000
銀行のシステムはこの数字とデータレコードを突き合わせる。件数が合わなければエラー。金額が合わなければエラー。1円でもズレたら全件拒否。
このチェックがあるから、ファイルの改竄や転送中の破損を検知できる。
エンドレコード
エンドレコードは「ファイルここまで」を示す。
バイト定義（120バイト）
| 位置 | 桁数 | 属性 | 項目名 | 内容 |
|---|---|---|---|---|
| 1 | 1 | N | データ区分 | 固定値 9 |
| 2-120 | 119 | C | ダミー | スペース |
先頭に9、残り119バイトはスペース。それだけ。
シンプルだが、省略はできない。エンドレコードがないと、銀行のシステムは「ファイルが途中で切れている」と判断してエラーにする。
種別コード一覧
ヘッダレコードの2-3バイト目に設定する、業務を識別する2桁のコード。
| コード | 業務種別 | 用途 |
|---|---|---|
11 | 給与振込（民間） | 従業員への給与支払い |
12 | 賞与振込（民間） | 従業員への賞与支払い |
21 | 総合振込 | 取引先への支払い（仕入代金、経費等） |
71 | 給与振込（官庁） | 公務員への給与支払い |
72 | 賞与振込（官庁） | 公務員への賞与支払い |
91 | 預金口座振替 | 顧客口座からの引落し |
総合振込 vs 給与振込 の違い
レコードのフォーマット自体は同じだ。種別コードが違うだけ。
ただし、ビジネス上の違いは大きい。
- 総合振込（21）：不特定多数の取引先に振り込む。振込手数料は1件ごとに発生。
- 給与振込（11）：従業員に振り込む。銀行との事前契約で手数料が安くなる（無料の場合もある）。ただし、給与の支払日が事前登録と一致していないとエラーになる銀行もある。
使い分けのルールは明確だ。従業員への給与・賞与は11/12。それ以外の支払いは21。間違えても振込自体は実行されることが多いが、手数料の優遇が適用されなくなる。
文字コードと使用可能文字
全銀フォーマットで使える文字は、驚くほど少ない。
エンコーディング
ヘッダレコードの4バイト目（コード区分）で指定する。
| コード区分 | エンコーディング | 用途 |
|---|---|---|
0 | JIS（JIS X 0201） | PCベースのシステム（ほぼ全ての場合これ） |
1 | EBCDIC | メインフレーム系（レガシーシステム） |
2026年の今、新しく実装するなら0（JIS）一択だ。JIS X 0201は半角文字のみの1バイト文字コードで、Shift_JISの半角部分と互換性がある。
使用可能文字の完全一覧
数字（10文字）
0 1 2 3 4 5 6 7 8 9英大文字（26文字）
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z小文字は使えない。aではなくA。
半角カタカナ（45文字）
ｱ ｲ ｳ ｴ ｵ
ｶ ｷ ｸ ｹ ｺ
ｻ ｼ ｽ ｾ ｿ
ﾀ ﾁ ﾂ ﾃ ﾄ
ﾅ ﾆ ﾇ ﾈ ﾉ
ﾊ ﾋ ﾌ ﾍ ﾎ
ﾏ ﾐ ﾑ ﾒ ﾓ
ﾔ ﾕ ﾖ
ﾗ ﾘ ﾙ ﾚ ﾛ
ﾜ ﾝ濁点・半濁点（2文字）
ﾞ（濁点） ﾟ（半濁点）これが最大の罠だ。「ガ」は1文字ではない。「ｶ」+「ﾞ」で2バイト消費する。「パ」も「ﾊ」+「ﾟ」で2バイト。
記号（基本）
( ) . - / ｢ ｣ (スペース)記号（拡張 — 銀行依存、使用は推奨しない）
# $ % * + : ; = ? @ { } 。 ・ _拡張記号は一部の銀行でしか使えない。安全に行くなら基本記号だけ使うこと。
使えない文字
- 全角文字は一切不可。漢字、ひらがな、全角カタカナ、全角英数字。すべてエラー。
- **半角カタカナの「ｦ」**は一部銀行で使用不可。
- **カンマ（,）**も一部銀行で不可。
文字変換ルール
日本語のデータを全銀フォーマットに入れるには、変換が必要だ。
全角カタカナ → 半角カタカナ
| 変換前 | 変換後 | バイト数 |
|---|---|---|
| ア | ｱ | 1 |
| ガ | ｶﾞ | 2 |
| パ | ﾊﾟ | 2 |
濁音・半濁音は分解される。「ガギグゲゴ」は10バイト消費する。
小文字カタカナ → 大文字カタカナ
全銀フォーマットには小文字カタカナが存在しない。
| 小文字 | 大文字 |
|---|---|
| ァ（ｧ） | ア（ｱ） |
| ィ（ｨ） | イ（ｲ） |
| ゥ（ｩ） | ウ（ｳ） |
| ェ（ｪ） | エ（ｴ） |
| ォ（ｫ） | オ（ｵ） |
| ッ（ｯ） | ツ（ﾂ） |
| ャ（ｬ） | ヤ（ﾔ） |
| ュ（ｭ） | ユ（ﾕ） |
| ョ（ｮ） | ヨ（ﾖ） |
「ニッポン」は「ﾆﾂﾎﾟﾝ」になる。小さい「ッ」が大きい「ﾂ」に変わる。
ひらがな → 半角カタカナ
ひらがなは一度全角カタカナに変換してから、半角に変換する。
「やまだ たろう」→「ヤマダ タロウ」→「ﾔﾏﾀﾞ ﾀﾛｳ」
記号の変換
| 変換前 | 変換後 | 注意 |
|---|---|---|
| 長音（ー） | ハイフン（-） | 別の文字コード |
| 中黒（・） | ピリオド（.） | 一部銀行では直接使用可 |
| 全角スペース | 半角スペース | |
| 全角括弧（） | 半角括弧() | |
| 全角数字 | 半角数字 | |
| 全角英字 | 半角英大文字 | 小文字→大文字も同時に |
法人格略語の完全一覧
口座名義に法人格が含まれる場合、括弧付きの略語に変換する。これは全銀協が定めたルール。
前株と後株
法人格が社名の前にあるか後にあるかで、括弧の付け方が変わる。
- 前株（株式会社○○）→ 閉じ括弧のみ：
ｶ)○○ - 後株（○○株式会社）→ 開き括弧のみ：
○○(ｶ
一覧
| 法人格 | 略語 | 前株の例 | 後株の例 |
|---|---|---|---|
| 株式会社 | ｶ | ｶ)ﾔﾏﾀﾞ | ﾔﾏﾀﾞ(ｶ |
| 有限会社 | ﾕ | ﾕ)ﾔﾏﾀﾞ | ﾔﾏﾀﾞ(ﾕ |
| 合同会社 | ﾄﾞ | ﾄﾞ)ﾔﾏﾀﾞ | ﾔﾏﾀﾞ(ﾄﾞ |
| 合名会社 | ﾒ | ﾒ)ﾔﾏﾀﾞ | ﾔﾏﾀﾞ(ﾒ |
| 合資会社 | ｼ | ｼ)ﾔﾏﾀﾞ | ﾔﾏﾀﾞ(ｼ |
| 医療法人 | ｲ | ｲ)ﾔﾏﾀﾞ | ﾔﾏﾀﾞ(ｲ |
| 財団法人 | ｻﾞｲ | ｻﾞｲ)ﾔﾏﾀﾞ | ﾔﾏﾀﾞ(ｻﾞｲ |
| 社団法人 | ｼﾔ | ｼﾔ)ﾔﾏﾀﾞ | ﾔﾏﾀﾞ(ｼﾔ |
| 学校法人 | ｶﾞｸ | ｶﾞｸ)ﾔﾏﾀﾞ | ﾔﾏﾀﾞ(ｶﾞｸ |
| 社会福祉法人 | ﾌｸ | ﾌｸ)ﾔﾏﾀﾞ | ﾔﾏﾀﾞ(ﾌｸ |
| 宗教法人 | ｼﾕｳ | ｼﾕｳ)ﾔﾏﾀﾞ | ﾔﾏﾀﾞ(ｼﾕｳ |
| 特定非営利活動法人 | ﾄｸﾋ | ﾄｸﾋ)ﾔﾏﾀﾞ | ﾔﾏﾀﾞ(ﾄｸﾋ |
注意点
法人格の略語自体にも濁点が含まれることがある。ﾄﾞ（合同会社）は2バイト。ｻﾞｲ（財団法人）は4バイト（ﾞで+1）。括弧も1バイト。
つまり、「財団法人山田記念財団」を半角カナにすると：
ｻﾞｲ)ﾔﾏﾀﾞｷﾈﾝｻﾞｲﾀﾞﾝ → 21バイト。30バイト制限には収まるが、思ったより消費している。
実装時の落とし穴
全銀フォーマットを実装するとき、よくハマる罠を12個並べる。
1. バイト数と文字数を混同する
これが最も多いバグだ。
プログラミング言語のstring.lengthは文字数を返す。全銀フォーマットが要求するのはバイト数。半角英数字は1文字1バイトだが、濁点付きカナは注意が必要。
JavaScriptの例：
"ｶﾞ".length // → 2（文字数としては正しい）JIS X 0201では「ｶ」が1バイト、「ﾞ」が1バイトで合計2バイト。この場合はたまたま一致するが、全角文字が混入した場合にlengthとバイト長が乖離する。
対策：文字列のバイト長を検証する関数を用意し、120バイトに収まっているか必ずチェックする。
2. 全角文字の混入
ユーザー入力をそのまま使うと、全角文字が混入する。全角スペース「 」は見た目では気づきにくい。
対策：全角→半角の変換を必ず実施し、変換できない文字が残っていたらエラーにする。
3. 改行コードの不一致
仕様はCR+LF（\r\n）だが、銀行によってはLFのみ（\n）でも受け付ける。逆に、LFだとエラーにする銀行もある。
対策：最初はCR+LFで出力し、銀行に合わなければ調整する。
4. EOF制御コード
一部の銀行は、ファイル末尾にEOF制御コード（0x1A）を要求する。MS-DOS時代の名残だ。
対策：必要な銀行にはファイル末尾に0x1Aを付加する。
5. トレーラの件数・金額の不一致
データレコードの件数と金額を手で数えて、トレーラに入れる……という実装をすると、必ずどこかでズレる。
対策：データレコードをループで回しながら件数と金額を自動集計し、トレーラに入れる。手動で値を書かない。
6. 口座名義の不一致
受取人名が実際の口座名義と1文字でも異なると、振込が失敗する。特に多いのが：
- 法人格略語の括弧位置（前株/後株）の間違い
- 長音「ー」とハイフン「-」の取り違え
- 「ヅ」と「ズ」、「ヂ」と「ジ」の混同
- 営業所名の有無（口座名義に営業所名が入っていない場合がある）
対策：初回振込時はテスト送信を行い、口座名義を銀行に確認する。
7. 銀行コード・支店コードのマスタ不備
銀行の合併・支店の統廃合で、コードが変わる。2026年現在も定期的に変更が発生している。
対策：全銀協の公式マスタデータを定期的に更新する。古いコードのまま送ると「該当支店なし」でエラーになる。
8. 金額フィールドの桁あふれ
10桁を超える金額（100億円以上）は表現できない。通常は問題にならないが、テストデータで大きな値を入れてバグを踏むことがある。
対策：入力値のバリデーションで上限チェックを行う。
9. 空ファイルの生成
データレコードが0件のファイルは不正。ヘッダ + トレーラ + エンドだけのファイルをアップロードするとエラーになる。
対策：データレコードが0件の場合はファイルを生成しない。
10. 半角カタカナの「ヲ」問題
ｦ（半角カタカナのヲ）は一部の銀行で使用不可。口座名義に「ヲ」が入っている場合（まれだが存在する）にトラブルが起きる。
対策：基本的には使わない方針で実装し、必要な場合は銀行に確認する。
11. 先頭ゼロの欠落
口座番号0123456をプログラムで数値として扱うと、先頭のゼロが消えて123456（6桁）になる。全銀フォーマットは7桁固定なので、1桁足りない。
対策：口座番号は最初から最後まで文字列として扱い、数値に変換しない。
12. Shift_JIS出力の忘れ
プログラム内部でUTF-8のまま処理して、最後のファイル出力でShift_JIS（JIS X 0201）に変換し忘れるケース。
半角英数字はUTF-8もJIS X 0201も同じバイト値なので、テスト時には気づかない。半角カタカナが入ったときに初めて文字化けする。
対策：ファイル出力の最終段階で明示的にShift_JIS（半角カタカナ部分はJIS X 0201のA1〜DF）に変換する。
実際のデータ例
30,000円をみずほ銀行丸の内支店の普通預金口座に振り込む場合の全レコードを示す。
ヘッダレコード
12100001234567890ﾐﾂﾋﾞｼｼﾖｳｼﾞ(ｶ 03150005ﾐﾂﾋﾞｼﾕｰｴﾌｼﾞ 001ﾎﾝﾃﾝ 10123456読み方：
| 位置 | 値 | 意味 |
|---|---|---|
| 1 | 1 | ヘッダレコード |
| 2-3 | 21 | 総合振込 |
| 4 | 0 | JISコード |
| 5-14 | 0001234567890 | 会社コード |
| 15-54 | ﾐﾂﾋﾞｼｼﾖｳｼﾞ(ｶ + スペース | 三菱商事株式会社 |
| 55-58 | 0315 | 3月15日 |
| 59-62 | 0005 | 三菱UFJ銀行 |
| 63-77 | ﾐﾂﾋﾞｼﾕｰｴﾌｼﾞ + スペース | 三菱UFJ銀行（カナ） |
| 78-80 | 001 | 本店 |
| 81-95 | ﾎﾝﾃﾝ + スペース | 本店（カナ） |
| 96 | 1 | 普通預金 |
| 97-103 | 0123456 | 口座番号 |
| 104-120 | スペース | ダミー |
データレコード
20001ﾐｽﾞﾎｷﾞﾝｺｳ 001ﾏﾙﾉｳﾁ 00001012345670ﾔﾏﾀﾞ ﾀﾛｳ 00000300000 7| 位置 | 値 | 意味 |
|---|---|---|
| 1 | 2 | データレコード |
| 2-5 | 0001 | みずほ銀行 |
| 6-20 | ﾐｽﾞﾎｷﾞﾝｺｳ + スペース | みずほ銀行（カナ） |
| 21-23 | 001 | 丸の内支店 |
| 24-38 | ﾏﾙﾉｳﾁ + スペース | 丸の内（カナ） |
| 39-42 | 0000 | 手形交換所（未使用） |
| 43 | 1 | 普通預金 |
| 44-50 | 0123456 | 口座番号 |
| 51-80 | ﾔﾏﾀﾞ ﾀﾛｳ + スペース | 山田太郎（カナ） |
| 81-90 | 0000030000 | 30,000円 |
| 91 | 0 | その他（既存振込先） |
| 112 | 7 | 電信振込 |
トレーラレコード
8000001000000030000（以下101バイトスペース）| 位置 | 値 | 意味 |
|---|---|---|
| 1 | 8 | トレーラレコード |
| 2-7 | 000001 | 合計1件 |
| 8-19 | 000000030000 | 合計30,000円 |
エンドレコード
9（以下119バイトスペース）銀行ごとの差異
全銀フォーマットは「全銀協制定」で標準化されているが、銀行ごとに微妙な違いがある。
改行コード
| 銀行 | 改行コード |
|---|---|
| 多くの銀行 | CR+LF（\r\n） |
| 一部のネット銀行 | LFのみ（\n） |
| 一部のFBソフト | 改行なし（120バイト連結） |
EOF制御コード
| 銀行 | EOF |
|---|---|
| ほとんどの銀行 | 不要 |
| 一部のレガシーシステム | 0x1A必要 |
拡張記号の対応
#, $, @ などの拡張記号は、銀行によって使える・使えないが分かれる。基本記号（数字・英大文字・カナ・括弧・ピリオド・ハイフン・スラッシュ・スペース）だけ使えば、どの銀行でも通る。
ファイル名
全銀フォーマットの仕様にはファイル名の規定はない。銀行によっては拡張子を.txtにしろ、.datにしろ、.zenにしろと指定してくる場合がある。アップロード画面で確認すること。
全銀EDIシステムとの関係
2018年12月、全銀EDIシステムが稼働した。これは全銀フォーマットの「次世代版」と誤解されがちだが、正確には並走する別システムだ。
背景
従来の全銀フォーマットでは、EDI情報が20バイト（データレコードの92-111バイト目）しかない。請求番号を入れたら、もう他の情報は入らない。企業間取引で「どの請求書への支払いか」を特定するのに、20バイトでは足りなかった。
全銀EDIシステムの位置づけ
- XML形式（ISO 20022準拠）で、付加情報を豊富に格納できる
- 120バイト固定長の全銀フォーマットも引き続きサポート
- 2025年に第2次全銀EDIシステムが稼働
全銀フォーマットは廃止されるか
されない。理由は3つ。
- 導入コスト：XML対応にはシステム改修が必要。中小企業にはハードルが高い。
- 十分に動いている：100億円以下の単純な振込なら、120バイトで事足りる。
- 後方互換性：1,134金融機関が対応しているフォーマットを廃止するリスクを、誰も取りたくない。
よくある質問
Q: 全銀フォーマットは無料で使えるのか？
ファイルを作ること自体に費用はかからない。テキストエディタで120バイトのファイルを書いてもいい。費用が発生するのは、インターネットバンキングやFBの利用契約の部分。
Q: 個人でも使えるか？
個人口座のインターネットバンキングでは、全銀フォーマットのアップロード機能がないことが多い。法人口座向けの機能だ。
Q: Macで作れるか？
作れる。全銀フォーマットはただのテキストファイルなので、OS依存はない。ただし、Excel VBAで作る場合はWindows前提のことが多い。
Q: データレコードの最大件数は？
仕様上は999,999件。ただし、銀行のインターネットバンキングには「1ファイルあたり500件まで」などの制限がある場合がある。
Q: 送金を取り消したい場合は？
全銀フォーマットに「取消」のレコードはない。送金後の取消は銀行に直接連絡して「組戻し」を依頼する。手数料が発生する（880円程度）。
Q: テスト送信はできるか？
多くの銀行のIB/FBには「テスト伝送」「検証」機能がある。本番の振込前に、ファイルのフォーマットチェックだけを行える。初めて全銀フォーマットを使うときは、必ずテスト伝送を行うこと。
まとめ
全銀フォーマットは、1973年から50年以上使われている120バイト固定長のテキスト形式だ。仕様はシンプルだが、半角カタカナの濁点処理、口座名義の法人格略語、銀行ごとの微妙な差異など、正確に実装するには細かい知識が必要になる。
この記事が、全銀フォーマットを理解するための入り口になれば幸いだ。
この記事に含まれる仕様情報は、全国銀行協会および各銀行が公開している仕様書に基づいています。銀行ごとの差異がありますので、実際のご利用にあたっては、お取引先銀行の仕様書を必ずご確認ください。