銀行取引明細日本語ExcelMUFGみずほ銀行国際

日本の銀行取引明細をExcelに変換（MUFG、SMBC、みずほ銀行など）

2026年3月2日

PDFSub Team

日本の銀行取引明細は、漢字の説明、Shift_JISエンコーディング、半角カタカナ、日本の元号日付が混在し、日本のExcel以外では破損します。正しく変換する方法はこちら。

MUFGからの取引明細（取引明細）はPDFでは完璧に構造化されているように見えます。しかし、日本国外のExcelで開くと問題が連鎖します。漢字は文字化けし、令和8年3月2日の日付は英語の表計算ソフトでは意味をなさず、半角カタカナの送金者名「ﾔﾏﾀﾞﾀﾛｳ」は読めない記号になり、全角数字「１２３，４５６」は半角のUnicode文字とは異なるため計算できません。

根本的な問題は、日本の銀行業務が、日本語ロケールのシステムを前提とした文字エンコーディングとフォーマットの慣習に基づいていることです。1日あたり約650万件の取引と12兆円を処理する全銀ネットワークは、歴史的にすべての名前に半角カタカナを要求していましたが、これは現代の銀行取引明細にも残っています。そのデータを日本国外のコンピューターに移動すると、エンコーディングの破損はほぼ避けられません。

東京在住の外国人の方が、母国での税務申告のためにMUFGの明細を処理する場合でも、税理士がfreeeやマネーフォワードに顧客データをインポートする場合でも、国際的なビジネスで日本子会社のデータを統合する場合でも、あるいはフリーランサーが青色申告の記帳を管理する場合でも、根本的な問題は同じです。それは、日本の銀行取引明細PDFから、構造化された、表計算ソフトで利用可能なデータを抽出することです。

このガイドでは、日本の明細特有のフォーマットの課題、遭遇する可能性のある主要な銀行、そしてそれらを正確に変換する方法について説明します。

なぜ日本の銀行取引明細はExcelで破損するのか

日本の銀行取引明細は、単純な数値フォーマットを超えた、特有の課題を生み出します。問題は、文字エンコーディング、数値システム、日付の慣習、そしてレガシーな銀行間フォーマットにまたがります。

1. Shift_JIS vs. UTF-8 エンコーディング（文字化け）

これは、日本国外で日本の金融データを処理する上で最も大きな問題です。

ほとんどの日本の銀行は、UTF-8より前のエンコーディング標準で、日本語文字のみをカバーするShift_JIS（コードページ932）でCSVファイルをエクスポートします。UTF-8を想定しているシステムでShift_JISファイルをUTF-8として開くと、すべての日本語文字が破損します。日本にはこの現象を表す言葉があります：文字化け、「文字の変換」を意味します。

表示されるべきもの	UTF-8で表示されるもの
振込カ）ヤマダタロウ	æŒ¯è¾¼ã‚«ï¼‰ãƒ¤ãƒžãƒ€
三菱UFJ銀行	ä¸‰è±UFJéŠ€è¡Œ
口座振替電気代	å£åº§æŒ¯æ›¿ é›»æ°—ä»£

逆もまた真なり：日本語ロケールのExcelで開かれたUTF-8ファイルも、異なる文字化けを引き起こす可能性があります。

Shift_JISファイルにはバイトオーダーマーク（BOM）がないため、問題はさらに複雑化します。ソフトウェアにどのエンコーディングを使用すべきかを伝えるヘッダーがありません。特にファイルに日本語文字とラテン文字（すべての銀行取引明細に含まれる）が混在している場合、自動検出は信頼性が低くなります。

2. 全角 vs. 半角文字

これは日本特有のもので、ほぼすべての非日本人開発者を戸惑わせます。

日本のコンピューティングでは、多くの文字に2つの幅が使用されます。全角文字はラテン文字2文字分のスペースを占め、半角文字は1文字分のスペースを占めます。

全角	半角	同じ文字か？
１２３，４５６	123,456	同じ数字、異なるバイト
カード	ｶｰﾄﾞ	同じ単語（「カード」）、異なるエンコーディング
，（コンマ）	, (comma)	同じ句読点、異なるバイト
（スペース）	(space)	同じスペース、異なるバイト

「１２３，４５６」（全角）を含むセルは画面上では「123,456」と同一に見えますが、Excelはその全角バージョンを数値ではなくテキストとして扱います。SUM関数を使ったり、並べ替えたり、数式に使用したりできません。標準の検索と置換でコンマを置換しようとしても、全角コンマは一致しません。

銀行取引明細では、金額は半角、説明文は全角文字を使用するなど、幅が混在する可能性があります。コンバーターは、計算のためにすべてを一貫した半角に正規化する必要があります。

3. 全銀システムからの半角カタカナ

日本の国内決済基盤である全銀システムは、歴史的に、すべての名前を20文字の制限内で半角カタカナで送信することを要求していました。

これにより、特定の課題が生じます。銀行取引明細では、送金者名は「山田太郎」ではなく、「ﾔﾏﾀﾞﾀﾛｳ」のように表示されます。ネイティブの日本人でも、半角カタカナは読みにくいと感じます。

さらに悪いことに、半角カタカナでは、濁点（ダクテン）は別々の文字になります。全角の「ガ」は1文字ですが、半角では「ｶ」と「ﾞ」の2文字になります。これにより、濁音を含む名前の表示上の長さが倍になり、文字数をカウントするテキスト処理が破損します。

4. 日本の元号日付（和暦）

日本は、グレゴリオ暦と並行して独自の元号ベースのカレンダーを使用しています。現在の元号は令和で、2019年5月1日に始まりました。

和暦	グレゴリオ暦相当
令和8年3月2日	2026年3月2日
R8.03.02	2026年3月2日
令和7年12月15日	2025年12月15日

英語のExcelには、日本の元号の概念がありません。「令和8年」を2026年として解析できません。短縮形式の「R8.03.02」でさえ認識できません。

良いニュース：日本は年・月・日順（大きいものから小さいものへ）を使用しており、これはISO 8601に準拠しています。明細が西洋の日付を使用する場合、2026/03/02のように表示され、ヨーロッパのDD/MM/YYYY形式よりも曖昧さが少なくなります。課題は、元号日付が使用されている場合にのみ発生します。

元号の境界問題： 2019年の過去の明細は、平成から令和への移行（平成は2019年4月30日に終了）にまたがる可能性があります。同じ年である2019年は、平成31年でもあり、令和元年でもあります。コンバーターは両方の元号を正しく処理する必要があります。

5. 通貨の整数（小数点なし）

円には補助通貨がありません。セントはありません。日本の銀行取引明細のすべての金額は整数です：1,234,567円は正確に1,234,567円を意味します。

これは実際には、変換の1つの側面を単純化します（小数点処理の必要なし）が、他の側面をもたらします：

大きな数字は普通です。 月給は通常300,000～500,000円です。家賃は80,000～200,000円かもしれません。数字はしばしば6桁または7桁に達します。
10,000単位の考え方。 日本人は万単位で考えます。3,000,000円の給与は、頭の中で「300万円」となります。しかし、銀行取引明細には完全な数字が表示されます。
明細の3桁ごとのコンマ — 日本の数値システムは4桁（万、億）でグループ化しますが、金融文書は国際的な慣習に従います。

6. 入金と出金の別々の列

西洋の銀行取引明細は単一の金額列（クレジットは正、デビットは負）を使用するのに対し、日本の明細は通常2つの別々の列を使用します：

入金 — クレジット
出金 — デビット

各取引について、一方の列は常に空です。Excelに変換する際、次のいずれかの選択肢があります：2列形式を維持するか、単一の符号付き金額列にマージするか？どちらの選択肢でも、コンバーターは日本の列構造を理解する必要があります。

主要な日本の銀行とその明細

MUFG（三菱UFJ銀行）

資産規模で日本最大の銀行（約2.9兆ドル）、個人預金口座数は約5,700万口座。三菱UFJフィナンシャル・グループ傘下。オンラインバンキング（法人向けBizSTATION、個人向け三菱UFJダイレクト）を通じてPDF明細とCSVエクスポートを提供。CSVエクスポートはShift_JISエンコーディングを使用。

SMBC（三井住友銀行）

日本第2位の商業銀行で、個人顧客は約2,700万人。三井住友フィナンシャルグループ傘下。オンラインバンキング（SMBCダイレクト）でPDFおよびCSVダウンロードを提供。

みずほ銀行

第3のメガバンクで、個人顧客は約2,400万人、オンラインバンキング契約者は1,260万人。オンラインバンキング（みずほダイレクト）で取引ダウンロードを提供。

ゆうちょ銀行

口座数で日本最大で、顧客口座数は約1億2,000万口座、総資産は約205兆円。約24,000の支店（主に契約郵便局）を通じて運営。日本国内のほぼすべての自治体にリーチ。ユニークな口座番号システムで、標準的な日本の銀行口座番号とは異なります。

楽天銀行

日本最大のネット銀行で、1,760万口座以上、預金残高は13兆円超。預金はメガバンクの3.8%に対し、年率16.5%で成長。完全にデジタル化されており、CSVエクスポート機能を提供。

地方銀行

日本には約97の地方銀行があります — 第1地方銀行61行、第2地方銀行36行。通常、各都道府県には、その県庁所在地に本社を置く地方銀行が少なくとも1行あります。例：横浜銀行、千葉銀行、静岡銀行。明細のフォーマットは地方銀行によって大きく異なります。

SBI新生銀行 / ソニー銀行

SBI新生銀行とソニー銀行は、英語対応のオンラインバンキングを提供している点で注目されています — 日本では珍しいです。このため、日本在住の外国人に人気があります。両行ともPDFおよびCSVエクスポートを提供。

方法1：PDFSubを使用する（推奨）

PDFSub は、上記のエンコーディングやフォーマットの課題を含む、日本の銀行取引明細をネイティブに処理します。

仕組み

取引明細書をアップロード — 20,000以上のサポートテンプレートから、日本のどの銀行のフォーマットでも自動検出します。PDFSubにPDFをドラッグ＆ドロップします。
自動フォーマット処理 — コンバーターは自動的に以下を行います：
- Shift_JISエンコーディングを検出し、UTF-8に変換します。
- 全角数字（１２３）を半角（123）に正規化し、計算可能にします。
- 全角コンマ、スペース、句読点を標準文字に変換します。
- 元号日付（令和8年3月2日）を標準日付（2026-03-02）に解析します。
- 半角カタカナの送金者名を読みやすい全角に変換します。
- 入金/出金列をマージするか、別々の列として保持します。
- 日本語の銀行用語（振込、振替、口座振替など）を認識します。
レビューと検証 — プレビューで抽出された取引を確認します。残高は、明細の開始残高と終了残高に対して検証されます。
ダウンロード — Excel（.xlsx）、CSV（UTF-8）、QBO（QuickBooks）、OFX（Xero、Wave）、QFX（Quicken）、またはJSONとしてエクスポートします。

PDFSubが日本の明細に対応できる理由

133言語（日本語を含む）。 抽出エンジンは、日本語の銀行用語（振込、振替、入金、出金、口座振替、手数料、利息）を理解し、構造化されたフィールドにマッピングします。

エンコーディングは自動処理。 Shift_JISとUTF-8間の手動検出や変換は不要です。PDFSubはエンコーディングを識別し、漢字、ひらがな、カタカナ、混合幅文字を適切に処理しながら、すべてをUTF-8に正規化します。

主要な日本の銀行すべてに対応。 3つのメガバンク（MUFG、SMBC、みずほ）からゆうちょ銀行の1億2,000万口座、楽天銀行、全国47都道府県の地方銀行、SBI新生銀行やソニー銀行のような英語対応銀行まで。

ブラウザファーストのプライバシー。 オンラインバンキングからのデジタルPDFの場合、テキスト抽出は完全にブラウザ内で行われます。ファイルはデバイスから離れません。スキャンされた文書や通帳の写真のみ、サーバーサイド処理が使用されます。

全角正規化。 数字、コンマ、スペース、句読点はすべて全角から半角に自動正規化され、金額が表計算ソフトでテキストではなく数値として扱われることを保証します。

方法2：銀行のCSVエクスポート

ほとんどの主要な日本の銀行は、オンラインバンキングを通じてCSV形式の取引ダウンロードを提供しています。以下が期待できる内容です。

入手できるもの

エンコーディング： ほぼ常にShift_JIS（UTF-8ではない）
区切り文字： 標準のコンマ（,）
日付フォーマット： 通常はYYYY/MM/DD（西洋式）。ただし、一部の銀行は元号日付を使用します。
列：通常は日付、摘要、入金額、出金額、残高

制限事項

Shift_JISエンコーディング。 日本国外のシステムでCSVを開くと、文字化けが発生します。インポート時にエンコーディングを明示的に設定する必要があります：Excelでは、「データ」→「データの取得」→「テキスト/CSVから」→「日本語（Shift-JIS）」エンコーディングを選択します。

半角カタカナの名前。 送金者/受取人の名前は、全銀システムからの半角カタカナで表示されます。これらはネイティブの日本人でも読みにくく、非話者には不可能です。

履歴の制限。 オンラインバンキングのCSVエクスポートは、通常3〜12ヶ月をカバーします。より長い履歴が必要な場合は、各期間ごとに明細を個別にダウンロードする必要があります。

標準化されたフォーマットがない。 ドイツのCAMT.053/MT940やフランスのCAMT.053/FEC標準とは異なり、日本の銀行CSVには普遍的なフォーマットがありません。各銀行は独自の列順序、命名、構造を使用します。

説明文中の全角文字。 取引の説明文には、分析前に正規化が必要な全角数字や句読点が含まれる場合があります。

方法3：手動コピー＆ペースト（非推奨）

日本の明細では問題が深刻です：

漢字やカタカナ文字がアプリケーション間で正しく貼り付けられない場合があります。
エンコーディング変換がサイレントに失敗します — 正しく見える文字が間違ったUnicodeコードポイントである可能性があります。
全角数字は計算できないテキストとして貼り付けられます。
半角カタカナの名前は貼り付けられますが、非日本語システムでは読めません。
元号日付は、英語Excelでグレゴリオ暦日付に自動変換されません。
入金/出金列が別々で、手動でのマージが必要です。
開始/終了残高に対する検証がありません。

取引量が多い場合、このアプローチは現実的ではありません。

知っておくべき日本の金融システム

全銀システム

1973年に設立された、日本の主要な国内銀行間決済ネットワーク。日本国内のほぼすべての民間銀行を接続し、1日あたり約650万件の取引を処理し、総額は約12兆円に達します。

全銀ファイルフォーマットは、名前の半角カタカナエンコーディングを使用した固定長120バイトレコードを使用します。このレガシーフォーマットが、銀行取引明細の送金者/受取人名が漢字ではなく半角カタカナで表示される理由です。新しいZEDI（Zengin EDI）システムは、全漢字をサポートし、ISO 20022準拠のXMLメッセージングに向けて進んでいますが、多くの明細にはレガシーフォーマットが残っています。

青色申告 vs. 白色申告

日本の税務申告には2つのレベルがあります：

特徴	青色申告	白色申告
申請	事前に申請が必要	デフォルトステータス
記帳	詳細な複式簿記	単純な収入/支出
特別控除	最大650,000円（e-Tax利用時）	なし
赤字の繰越	あり、最大3年間	なし

より大きな税額控除を受けられる青色申告者は、詳細な財務記録の維持が義務付けられており、正確な銀行取引明細の変換が記帳に不可欠です。

インボイス制度（適格請求書等保存方式）

2023年10月1日に開始されたこの制度では、消費税の仕入税額控除を受けるために、事業者は「適格請求書発行事業者」として登録する必要があります。以前は、年間課税売上高1,000万円未満の事業者は消費税が免除されていました。この変更により、中小企業やフリーランサーの間で正確な財務記録保持の必要性が大幅に高まりました。

日本の会計ソフトウェア

ソフトウェア	主要統計	対象
freee	約60万契約者	中小企業、フリーランサー、スタートアップ
マネーフォワード	SaaS ARR 279.6億円	中小企業、個人
弥生	24年連続デスクトップ会計ソフトNo.1	中小企業、個人事業主
TKC	約11,500の税理士事務所が利用	税理士事務所

主要な3つのクラウドプラットフォーム（freee、マネーフォワード、弥生オンライン）は、銀行取引データのCSVインポートをサポートしています。PDFSubのExcelおよびCSVエクスポートは、これらのツールに直接インポートできます。

日本の銀行取引明細の変換が必要なのは誰か？

税理士。 日本には約82,276人の登録税理士がいます（2025年12月現在）。彼らは、記帳、税務申告、監査準備のために顧客の銀行取引明細を処理します。TKC全国会だけでも11,500の会員事務所があります。

日本在住の外国人。 2025年6月現在、396万人の外国人が日本に居住しており、2012年の水準のほぼ倍です。ほとんどの銀行取引明細は完全に日本語で、英語オプションはありません。日本在住の外国人は、母国での税務申告、ビザ更新、海外機関への財務書類送付のために、変換された明細を必要とします。

青色申告を行うフリーランサー。 個人事業主やフリーランサーで青色申告ステータスを維持している人は、詳細な複式簿記の記録を保持する必要があります。銀行取引明細をExcelに変換することは、事業経費の分類と650,000円の特別控除額の計算の出発点となります。

国際的な企業。 日本の子会社を持つ企業は、日本の銀行データをグローバルな会計システムと統合する必要があります。3つのメガバンクは、日本企業の19.3%のメインバンクを collectively に務めており、法人バンキングは通常、MUFGのBizSTATIONなどのポータルを通じて行われます。

学生およびワーキングホリデービザ保持者。 日本は2024年に3,000万人以上の外国人観光客を受け入れました。長期の学生やワーキングホリデービザ保持者は、日本の銀行口座を開設し（多くの場合、最もアクセスしやすいゆうちょ銀行で）、財務管理や母国での税務申告を行う際に明細を処理する必要があります。

Excelで日本の財務データを扱うためのヒント

まず文字化けを確認する。 日本語テキストが破損した文字（Ã¤、â€、Ã©など）として表示される場合は、ファイルが間違ったエンコーディングで開かれたことを意味します。Shift_JISエンコーディングを使用して再インポートするか、PDFSubのUTF-8 Excelエクスポートを使用して問題を回避してください。

数値タイプを確認する。 インポート後、金額が実際の数値であることをテストします。セルをクリックして、数式バーに数値が表示されるか確認するか、列に=SUM()を試します。SUMが0を返すもののセルに数値が表示される場合、その値は数値を装った全角テキストです。

2列形式を理解する。 日本の明細は、入金と出金の列を別にしています。分析で単一の符号付き金額が必要な場合は、数式を作成します：=IF(deposit_cell<>"", deposit_cell, -withdrawal_cell)。

元号日付を変換する。 元号日付を受け取った場合：令和の年 + 2018 = グレゴリオ暦の年。したがって、令和8年 = 2026年、令和7年 = 2025年。平成の日付（2019年5月より前）の場合：平成の年 + 1988 = グレゴリオ暦の年。

元のPDFを保管する。 日本の税法では、財務記録の保持が義務付けられています。青色申告者は、元の銀行取引明細（または通帳）が証拠書類となります。必ずPDFを変換されたExcelファイルと一緒に保管してください。

混合幅文字に注意する。 ソートまたはフィルタリングで予期しない結果が生じる場合は、同じ列に全角と半角の文字が混在していないか確認してください。半角文字のみのセルに単一の全角スペースがあると、不一致が発生します。

よくある質問

MUFG（三菱UFJ銀行）の明細をExcelに変換できますか？

はい。MUFGは日本最大の銀行で、約5,700万の個人口座を持っています。PDFSubはMUFGのPDF明細をネイティブに処理し、日本語フォーマット（Shift_JISエンコーディング、半角カタカナの送金者名、別々の入金/出金列を含む）をクリーンでUTF-8エンコードされたスプレッドシートデータに変換します。

文字化けした日本語文字（モジバケ）を修正するにはどうすればよいですか？

モジバケは、Shift_JISエンコードされたファイルがUTF-8として（またはその逆で）開かれた場合に発生します。PDFSubはエンコーディングを自動検出してUTF-8でエクスポートすることで、これを完全に回避します。生のCSVファイルを扱っている場合は、Excelにインポートする際に「日本語（Shift-JIS）」エンコーディングを指定してください：データ → データの取得 → テキスト/CSVから → エンコーディングを選択。

日本の銀行PDFにはOCRの問題がありますか？

オンラインバンキングからダウンロードされた明細は、ネイティブのデジタルPDFでテキスト選択が可能です — 抽出は高速かつ正確です。OCRは、スキャンされた紙の明細または通帳の写真に必要です。日本の通帳文化により、多くのユーザーはPDFをダウンロードする代わりに通帳のページを写真に撮ります。PDFSubは、デジタルPDFとスキャンされた文書の両方を処理します。

通帳の記帳についてはどうですか？

物理的な通帳は日本ではまだ一般的ですが、銀行が新しい通帳に手数料を課しているため（MUFGは年間550円）、使用率は低下しています。通帳の記帳は、オンライン明細PDFよりも短縮されていることが多く、短縮された説明のみが表示されます。通帳のページを写真に撮る場合、PDFSubのOCRモードで取引を抽出できます。

日本の銀行データをfreeeやマネーフォワードにエクスポートできますか？

PDFSubはExcel、CSV（UTF-8）、QBO、OFX、QFX、JSONにエクスポートします。日本の会計ソフトウェア（freee、マネーフォワード、弥生）の場合、CSVにエクスポートし、ソフトウェアの組み込み銀行取引インポート機能を使用してインポートします。PDFSubからの適切にエンコードされ正規化されたデータは、文字化けやフォーマットの問題なしにクリーンなインポートを保証します。

日本の元号日付（令和）をどう扱いますか？

PDFSubは、日本の元号日付を標準のグレゴリオ暦日付に自動的に変換します。手動変換の場合：令和の年 + 2018 = グレゴリオ暦の年（令和8年 = 2026年）。平成の年 + 1988 = グレゴリオ暦の年（平成31年 = 2019年）。元号の変更は2019年5月1日でした。

PDFSubはいくつの日本の銀行をサポートしていますか？

PDFSubは世界中で20,000以上の銀行フォーマットをサポートしており、3つのメガバンク（MUFG、SMBC、みずほ）、ゆうちょ銀行、楽天銀行、全国47都道府県の地方銀行、SBI新生銀行やソニー銀行のような英語対応銀行など、すべての主要な日本の銀行が含まれます。

複数の日本の明細を一度に変換できますか？

はい。複数の取引明細書をアップロードすると、PDFSubはそれらを順番に処理します。各明細は、異なる銀行の異なるレイアウトやエンコーディングの慣習であっても、独立して自動検出および変換されます。

PDFSubを7日間無料でお試しください — 銀行取引明細コンバーターと77以上のPDFツールにフルアクセスできます。いつでもキャンセル可能。