全銀フォーマットの作成をPythonで：120バイト固定長と半角カナの詰まりどころ｜Claude Codeで振込ファイルを実装【2026年】

全銀フォーマットの作成で僕に必要だったのは、1行120バイトを最後まで崩さない仕組みでした。Claude Code に書かせた Python は、全角カナを半角に直し、小さい「ッ」を大きく直したうえで、1行ずつバイト数を数えます。合わなければファイルを作らずに止まります。

ファイルより先に、2026年9月6日には銀行の側で止まりました。取り込む先のネット銀行の総合振込が、電子証明書方式で登録されていたのです。所要日数が読めなかったその日のうちに、その月の支払いは総合振込に賭けないと決めました。

この記事では、レコードの並びと桁の詰め方、半角カナで詰まった4か所、Python の要点、銀行の操作を人に残した分け方まで書きます。「振込ファイルって、結局どこで間違えやすいの？」と思っている方に向けた記録です。

全銀フォーマットの作成で守るのは「1行120バイト」と4種類のレコードの順番

全銀フォーマットのファイルは、ヘッダ・データ・トレーラ・エンドの4種類のレコードを、この順に並べたテキストです。どのレコードも120バイトで、データのレコードだけが振込の件数ぶん続きます。

ここでいう全銀フォーマットとは、全国銀行協会連合会が定めた、銀行とのデータのやり取りに使うファイルの形です。ある信用金庫の資料では、テキスト形式なのでメモ帳などでも編集できると説明されています。

4種類の役割を並べます。先頭の1桁（データ区分）で、そのレコードが何かを見分けます。

僕なら、最初にこの4種類を1行ずつ作る関数に分けます。トレーラはデータから計算して作るので、手で書かない形にしておくと合計のずれが起きません。

改行・EOF・文字コードは銀行の仕様書で確かめる

改行と最後の印の扱いは、銀行で違います。ある地方銀行の資料では、改行は CR+LF・CR・LF のどれでもよく、改行なしでも受け付け、エンドの後の改行と EOF（0x1A）は任意です。

僕の会社が使ったネット銀行の仕様書は、120バイトに CR+LF を付けた122バイトで1レコード、最後に EOF でした。スクリプトの冒頭にもこの3点を書いてあります。

文字コードの書き方も違い、その地方銀行の資料は「JISコード」、僕の会社が使ったネット銀行の資料はシフトJISでした。Python では cp932 で書き出しています。

数字は右詰めで0、文字は左詰めで空白：ヘッダとデータの桁の詰め方

項目は「数字」と「文字」の2種類で、数字は右に寄せて前を0で埋め、文字は左に寄せて後ろを空白で埋めます。桁が余っても足りなくても、その行の120バイトが崩れます。

ヘッダでは、種別コードの「21」が総合振込、コード区分の「0」が JIS を表します。委託者コードは10桁で、銀行が決めて渡す番号です。委託者名は40桁、取組日は月日の4桁（MMDD）です。

データのレコードは、次の16項目で120桁になります。桁は2つの資料で同じでした。

2つの資料では、銀行名・支店名はどちらも書く欄でした。僕の会社のスクリプトはこの2つを空白で出しているので、埋めるかどうかは使う銀行の仕様書で確かめてください。

トレーラは、合計件数6桁・合計金額12桁・空き101桁です。エンドは「9」のあとに空白が119桁続くだけなので、ここで迷うことはありませんでした。

全角カナから半角カナへの変換で詰まった4つのところ

詰まったのは、濁点・小さいカナ・長音・英字の4つでした。どれも画面で見ると正しいのに、バイト数か使える文字のどちらかでずれます。

濁点の付いたカナは、1文字が2バイトになる

半角カナの「ｶﾞ」は、「ｶ」と「ﾞ」の2文字です。受取人名の30桁は文字数ではなくバイト数なので、濁点の多い名前ほど早く桁があふれます。

もう1つの落とし穴は、Python の正規化（NFKC）が半角カナを全角に直す向きにしか働かないことです。全角から半角へ戻す標準の関数は無いので、半角カナを全角にした結果から逆引きの表を作りました。

小さい「ッ」「ャ」は大きいカナに直した

僕の会社のスクリプトは、「ｧｨｩｪｫｬｭｮｯ」を「ｱｲｳｴｵﾔﾕﾖﾂ」に置き換えてから書き出します。小さいカナをどう扱うかは銀行と入力の方法で違うので、使う銀行の仕様書で確かめてください。

長音「ー」はハイフンにした

全角の長音は半角の「ｰ」になりますが、スクリプトではさらにハイフン「-」に置き換えています。全角のハイフンや空白、かっこも半角に直す対応表に入れました。

英字は大文字にそろえ、使えない文字は止める

英数字は正規化で半角にし、英字は大文字にそろえます。変換の後に、数字・英大文字・半角カナ・一部の記号・空白以外が残ったら、エラーにしてファイルを作りません。

黙って文字を消すと、受取人名が口座の名義と食い違うおそれがあります。止まれば、どの名前のどの文字かが画面に出るので、人が直してからやり直せます。

Claude Code で書いた Python の要点：1行ずつ120バイトを数えて、合わなければ止める

Python で全銀フォーマットを作るときに大事なのは、文字列の長さではなくバイト数で数えることです。僕の会社のスクリプトは、レコードを作るたびに cp932 でのバイト数を数え、120でなければ止まります。

流れは、振込先の一覧を JSON で渡す → ヘッダ・データ・トレーラ・エンドを作る → 1行ずつ検査する → CR+LF を付けて書き出す、の4段です。トレーラの件数と合計は、データから足し上げます。

スクリプトは Claude Code に、銀行が公開している全銀協規定形式の仕様書（PDF）を根拠に書かせました。2026年9月10日の手順書には、全レコードが120バイトであることと、トレーラの合計が一致することを確かめたと残しています。

下は要点だけを抜き出した短い例です。値はすべて架空で、銀行コード「0000」・口座番号「0000000」・受取人「株式会社サンプル」・金額1,000円にしています。

import unicodedata

# 半角カナを全角にした結果から、全角→半角の逆引きの表を作る
HAN = [chr(c) for c in range(0xFF66, 0xFFA0)]
Z2H = {unicodedata.normalize("NFKC", h): h for h in HAN}
SMALL = str.maketrans("ｧｨｩｪｫｬｭｮｯ", "ｱｲｳｴｵﾔﾕﾖﾂ")

def kana(s):
    s = unicodedata.normalize("NFKC", s).upper()   # 英数字を半角・大文字に
    s = "".join(Z2H.get(ch, ch) for ch in unicodedata.normalize("NFD", s))
    return s.translate(SMALL).replace("ｰ", "-")

def C(s, width):   # 文字の項目：左詰めで後ろを空白
    b = kana(s).encode("cp932")
    if len(b) > width:
        raise ValueError(f"{s} は {width} バイトに入りません")
    return b + b" " * (width - len(b))

def N(v, width):   # 数字の項目：右詰めで前を0
    t = str(v)
    if not t.isdigit() or len(t) > width:
        raise ValueError(f"{v} は数字 {width} 桁に入りません")
    return t.zfill(width).encode("cp932")

data = (b"2" + N("0000", 4) + b" " * 15 + N("000", 3) + b" " * 15 + b"0000"
        + N(1, 1) + N("0000000", 7) + C("カ）サンプル", 30) + N(1000, 10)
        + b"0" + b" " * 20 + b" " + b" " + b" " * 7)
assert len(data) == 120

NFD で濁点を分けてから表を引くのが、この例のいちばんの工夫です。「ガ」は「カ」と濁点に分かれ、それぞれ「ｶ」と「ﾞ」になります。全体を1つのファイルにするときは、各行の後ろに b"\r\n" を付け、最後に b"\x1a" を足します。

僕のスクリプトは、EOF ありの本命と、EOF だけを外した予備の2つを同時に書き出します。本命の取込でエラーが出たときに、予備で同じ手順をやり直せるようにするためです。

Claude Code にほかにどんな実務を任せているかは、Claude Codeでできること｜非エンジニアの活用事例にまとめています。

2026年9月、総合振込は電子証明書方式で登録されていて、その月は使えなかった

ファイルを作れても、取り込む銀行の画面に入れなければ使えません。僕の会社では、2026年9月の便でちょうどそこが止まりました。経理の記録にある流れを、日付の順に並べます。

申込のときの認証方式が電子証明書方式で、そのネット銀行の FAQ では、Mac では証明書方式でログインできないとされていました。変更の申請から完了までは、約1営業日でした。

案内のメールでは、認証方式を見分けられなかった

9月6日の利用開始の案内メールには、ログインIDとパスワードを登録したと書かれていました。僕の会社ではこれを、ID とパスワードで入る方式の証拠だと読んでいました。

記録には、この文面は証明書方式でも同じで、その読み方は誤りだったと残しています。方式は、実際にログインしてみるまで判別できませんでした。

所要日数が読めないので、9月の支払いは従来の振込にした

9月6日の時点では、方式の変更に何日かかるかが公開情報に見当たりませんでした。外注先への支払いが遅れると信用に直結するので、9月の支払いを総合振込に賭けないと決めています。

変更は9月10日に終わり、少額のテスト便を9月17日に出す計画を立てました。ところが9月28日の記録では、そのテスト便は実行されておらず、対象の振込は月末の本番の便にまとめています。

手順書にはテスト便の当日に出金を確かめる行がありましたが、未実行に気づいたのは9月28日の明細の確認でした。銀行側の一周を確かめないまま月末を迎えたのが、この月の失敗です。

振込データを作った後は人が確かめて承認する：銀行の操作をAIに任せない分け方

僕の会社では、Claude Code が作るのは振込データのファイルまでです。銀行の画面での取込・確定・承認は、すべて人が行います。

2026年9月10日に決めた分け方では、ファイルの取込と確定は社内の担当者、承認は僕です。担当者は件数・合計・振込指定日を画面で確かめ、承認者に僕を選んで確定します。

スクリプトは、振込ファイルと一緒に確認用の一覧も書き出します。件数・合計・相手の一覧で、口座番号は下4桁だけを見せ、残りは伏せています。承認の前に、この一覧と銀行の画面を見比べる手順にしています。

委託者コードと口座番号の入った入力ファイルと振込ファイルは、Git の同期から外したフォルダに置いています。記事やコードの例に本物の値を書かないのも、同じ理由です。

使ったネット銀行の規定では、振込の資金は振込日の前日までに口座へ入れ、承認は振込指定日の当日12時までに終える必要がありました。僕の会社の手順では、承認を前日中に終える段取りにしています。

請求書を出す側の自動化は、freee API・マネーフォワード APIで請求書自動化に分けて書いています。この記事は、その反対側にある支払いの話です。

業務で使うときの注意：EOF・文字コード・委託者コードは銀行の仕様書に合わせる

全銀フォーマットは共通の形ですが、細かいところは銀行ごとに違います。この記事の桁と書き方は2つの資料と僕の会社の記録の範囲なので、最後は使う銀行の仕様書で確かめてください。

1つ目は EOF と改行です。任意の銀行もあれば、付ける前提の銀行もあります。両方の版を作っておくと、取込で止まったときの切り分けが速くなります。

2つ目は文字コードと使える文字です。JIS と書く資料、シフトJIS と書く資料があり、小さいカナや記号の扱いも同じではありません。受取人名は、初めての振込先ほど口座の名義と照らし合わせています。

3つ目は委託者コードと認証方式です。委託者コードは銀行から渡される番号で、僕のスクリプトは形が合わなければ先に止めます。認証方式は、申し込むときに Mac で使える方式かを確かめておくと、僕の会社のような足止めを避けられます。

金額が0円以下の行があっても、スクリプトはファイルを作らずに止まります。銀行の画面に進む前に、ファイルの側で間違いに気づける形にしています。

まとめ

• 全銀フォーマットの作成は、ヘッダ・データ・トレーラ・エンドを120バイトずつ並べる作業で、数字は右詰めで0、文字は左詰めで空白
• 半角カナは、濁点で2バイトになる・小さいカナ・長音・英字の4つでずれやすい。Python では全角から半角への逆引きの表を自分で作る
• 1行ごとにバイト数を数え、合わなければファイルを作らずに止める。EOF ありとなしの2つを用意すると切り分けが速い
• 2026年9月は、銀行側の認証方式（電子証明書方式）で足止めされた。ファイルより先に、銀行の画面で一周できるかを確かめる
• 僕なら、まず少額のテスト便を1回出し、明細で出金を確かめてから本番の振込データを流します