OFXフォーマットとは？Open Financial Exchangeの解説

会計ソフトウェアがOFXファイルを求めているのに、銀行から提供されたのはPDF。見慣れないフォーマットに戸惑い、「なぜ普通の表計算ファイルではダメなんだろう？」と思っていませんか？

OFX -- Open Financial Exchange -- は、現代の金融ソフトウェアを支える、いわば「見えない標準」です。Xeroがカラムのマッピングなしで銀行取引をインポートできる理由、GnuCashが重複を検出できる理由、そしてQuickBooksのQBOフォーマットがその上に構築されている基盤でもあります。

このガイドでは、OFXとは何か、何が含まれているのか、CSVやQBOとの比較、どのソフトウェアがOFXをサポートしているのか、そしてPDFの銀行取引明細からOFXファイルを作成する方法を解説します。

OFXを一言で言うと

Open Financial Exchangeは、金融機関、ソフトウェアアプリケーション、エンドユーザー間で金融情報を交換するためのXMLベースのデータフォーマットです。これはIntuitのQBOフォーマットの基盤となっているオープンスタンダードであり、ほとんどのQuickBooks以外の会計ソフトウェアが銀行取引インポートに好むフォーマットです。

OFXを金融データの「共通語」と考えてください。銀行はこの言語を話し、会計ソフトウェアはこの言語を読み取ります。そして、単なる行と列で意味を持たないCSVとは異なり、OFXは受信側のソフトウェアに各データが何を表すかを正確に伝える構造化されたメタデータを持ちます。

OFXの歴史

OFXは1997年にMicrosoft、Intuit、CheckFreeによって作成されました。それぞれが独自の競合標準を持っていました -- MicrosoftはOFC（Open Financial Connectivity）、Intuitは独自の交換フォーマット、CheckFreeは電子請求プロトコルを持っていました。OFXはこれらを統合するための妥協案でした。

バージョンタイムライン

• OFX 1.0 (1997) -- SGML（Standard Generalized Markup Language）に基づいた最初の仕様。SGMLはタグを閉じなくてもよいため、OFX 1.xファイルは最新のXMLとは異なる見た目になります。
• OFX 1.6 (2002) -- 最も広く普及しているバージョン。依然としてSGMLベースです。OFXダウンロードを提供するほとんどの銀行は1.6ファイルを生成します。
• OFX 2.0 (2005) -- 大幅な改訂。SGMLから、閉じタグを持つ正式なXMLに移行しました。
• OFX 2.2 (2016) -- セキュリティ強化と投資取引サポートの改善。
• OFX 2.3 (現行) -- 現在のバージョン。元の創設者からガバナンスを引き継いだ業界コンソーシアムであるFinancial Data Exchange（FDX）によって維持されています。

SGMLからXMLへの移行は、解析に影響します。バージョン1.xファイルは閉じタグのないタグ（<TRNTYPE>DEBITで</TRNTYPE>がない）を使用しますが、バージョン2.xは閉じタグを持つ正式なXMLを使用します。ほとんどの最新パーサーは両方に対応しますが、バージョンの不一致はOFXインポートエラーの一般的な原因です。

OFXに含まれるもの

OFXは単なる銀行取引明細フォーマットではありません。この仕様は幅広い金融データをカバーしています。

• 銀行口座明細 -- 普通預金、貯蓄預金、マネーマーケット口座の取引。最も一般的なユースケースです。
• クレジットカード明細 -- 加盟店カテゴリコードと購入詳細をサポートする取引履歴。
• 投資・証券口座明細 -- 株式購入、配当金支払い、ファンド移管、ポートフォリオポジション（ロット単位の取得価額データ付き）。
• 請求書支払い情報 -- 受取人リスト、スケジュールされた支払い、支払い確認。
• 税務情報 -- 金融機関と税務ソフトウェア間で送信される1099フォームなどの税務書類。
• ローン明細 -- 住宅ローン、自動車ローン、個人ローンなどの取引記録と残高情報。

ほとんどの会計士や簿記担当者にとって、OFXは一つの意味を持ちます。それは、カラムのマッピングや日付フォーマットの推測なしに、会計ソフトウェアに銀行およびクレジットカードの取引をインポートすることです。

OFXファイルの中身

完全なOFX 1.6銀行取引明細ファイルは以下のようになります。これは最もよく遭遇するフォーマットであり、ほとんどの銀行や変換ツールが生成するSGMLベースのバージョンです。

OFXHEADER:100
DATA:OFXSGML
VERSION:160
SECURITY:NONE
ENCODING:USASCII
CHARSET:1252
COMPRESSION:NONE
OLDFILEUID:NONE
NEWFILEUID:NONE
 
<OFX> <SIGNONMSGSRSV1> <SONRS> <STATUS> <CODE>0 <SEVERITY>INFO </STATUS> <DTSERVER>20260228120000 <LANGUAGE>ENG </SONRS> </SIGNONMSGSRSV1> <BANKMSGSRSV1> <STMTTRNRS> <TRNUID>0 <STATUS> <CODE>0 <SEVERITY>INFO </STATUS> <STMTRS> <CURDEF>USD <BANKACCTFROM> <BANKID>021000021 <ACCTID>123456789 <ACCTTYPE>CHECKING </BANKACCTFROM> <BANKTRANLIST> <DTSTART>20260201120000 <DTEND>20260228120000 <STMTTRN> <TRNTYPE>CREDIT <DTPOSTED>20260201120000 <TRNAMT>3500.00 <FITID>20260201001 <NAME>DIRECT DEP PAYROLL <MEMO>ACME CORP PAYROLL </STMTTRN> <STMTTRN> <TRNTYPE>DEBIT <DTPOSTED>20260203120000 <TRNAMT>-87.50 <FITID>20260203001 <NAME>POS PURCHASE GROCERY <MEMO>WHOLE FOODS #10847 </STMTTRN> <STMTTRN> <TRNTYPE>CHECK <DTPOSTED>20260210120000 <TRNAMT>-1200.00 <FITID>20260210001 <NAME>CHECK 1045 <CHECKNUM>1045 </STMTTRN> </BANKTRANLIST> <LEDGERBAL> <BALAMT>4712.50 <DTASOF>20260228120000 </LEDGERBAL> <AVAILBAL> <BALAMT>4712.50 <DTASOF>20260228120000 </AVAILBAL> </STMTRS> </STMTTRNRS> </BANKMSGSRSV1>
</OFX>

ファイルの構造

ファイルは主に3つのセクションで構成されます。

1. ヘッダーブロック -- 先頭のプレーンテキスト行（<OFX>の前）は、OFXのバージョン、エンコーディング、セキュリティ設定を宣言します。これはXMLではなく、パーサーがSGML/XML本体を処理する前に読み取るシンプルなキーバリューヘッダーです。

2. サインオン応答（SIGNONMSGSRSV1） -- 認証とサーバーメタデータ。CODEが0は成功を意味します。インポートされるほとんどのファイルでは、ここにプレースホルダー値が使用されます。

3. 明細応答（BANKMSGSRSV1） -- 実際の金融データ。

• BANKACCTFROM -- 取引が属する口座（ルーティング番号、口座番号、口座タイプ）。
• BANKTRANLIST -- 開始日と終了日で区切られた取引リスト。
• STMTTRN -- 個々の取引記録。
• LEDGERBALとAVAILBAL -- 特定の日付時点での締め残高と利用可能残高。

SGML構文に注意してください：<TRNTYPE>CREDITのようなタグには閉じタグ</TRNTYPE>がありません。パーサーは次のタグの開始から値の終わりを推測します。これは有効なSGMLですが、XMLとしては無効です。OFX 2.xで閉じタグが追加された理由です。

主要なOFXタグ

銀行取引明細OFXファイルで最もよく遭遇するタグのリファレンステーブルを以下に示します。

FITID -- なぜ重要なのか

FITID（Financial Institution Transaction ID）は、会計の観点からOFXファイルの中で最も重要なタグです。これは各取引に割り当てられるユニークな識別子であり、重複検出を可能にするものです。

Xero、GnuCash、またはその他の互換性のあるソフトウェアにOFXファイルをインポートすると、そのソフトウェアは見たことのあるすべてのFITIDを保存します。同じファイルを再度インポートすると、ソフトウェアは各FITIDをデータベースと比較し、重複をサイレントにスキップします。

これが、OFXがCSVに対して持つ主な利点です。CSVにはユニークな識別子がないため、同じファイルを2回インポートすると、手動でクリーンアップする必要のある二重エントリが発生します。

OFX vs CSV

どちらのフォーマットも銀行取引を会計ソフトウェアに取り込むことができます。OFXは構造面で優れ、CSVは柔軟性で優れています。

会計インポートでOFXが優れている理由

日付フォーマットだけでも、トラブルシューティングの時間を節約できます。CSVでは、01/02/2026は曖昧です -- 1月2日か2月1日か？OFXはYYYYMMDDHHMMSSでこれを排除します。20260201120000は常に2026年2月1日です。

CSVが適している場合

CSVには正当な利点があります。

• データ編集 -- CSVをExcelで開き、エラーを修正し、カテゴリを追加して保存し直すことができます。OFXファイルにはテキストエディタとタグ構造の知識が必要です。
• Excel分析 -- 取引データに対して数式、ピボットテーブル、グラフを実行する必要がある場合、CSVは自然な中間フォーマットです。
• カスタム処理 -- プログラムスクリプトやデータパイプラインは、OFXのネストされたタグ構造よりもCSVを容易に処理します。
• 普遍的な互換性 -- 表形式データを読み取るすべてのアプリケーションがCSVを読み取ります。すべてのアプリケーションがOFXを読み取るわけではありません。

実用的なアドバイス：会計ソフトウェアへのインポートにはOFXを使用し、それ以外の場合はCSVを使用してください。

OFX vs QBO

これはほとんどの人が混乱する質問であり、答えは予想よりも簡単です。

QBO（QuickBooks Web Connect）は、異なるファイル拡張子といくつかのIntuit固有のタグを持つOFXです。基盤となるデータ構造は同一です。QBOファイルは、QuickBooksが自身のものとして認識するOFXファイルです。

主な違い

INTU.BIDタグは、Intuitの主な追加機能です。これは、ファイルがどの金融機関から来たかをQuickBooksに伝える銀行識別コードであり、インポート時に正しい銀行口座への自動マッチングを可能にします。

実際には、.ofxファイルを.qboにリネームしても、QuickBooksは通常それを読み取ります。逆も同様に機能します -- OFXを読み取るほとんどのソフトウェアは.qboファイルを処理します。しかし、クリーンなインポートのためには、各アプリケーションが期待するフォーマットを使用してください。

QFX（Quicken Financial Exchange）もあります -- 同じOFX基盤、異なるブランド、異なるファイル拡張子で、Quickenを対象としています。

OFXをサポートするソフトウェア

OFXは、会計および個人財務ソフトウェアで広くサポートされています。

Xero（推奨フォーマット）

Xeroは、手動での銀行取引明細インポートにおいて、CSVよりもOFXを明確に推奨しています。OFXファイルはカラム設定なしで自動マッピングされ、FITIDベースの重複検出が含まれ、口座メタデータを持ちます。

インポート方法： Accounting > Bank Accounts に移動し、口座を選択して、Manage Account > Import a Statement をクリックし、.ofxファイルを選択します。1ファイルあたり最大1,000件の取引。

MYOB（フルサポート）

MYOBは、銀行フィードインポートにOFXを受け入れます。プロセスはXeroと同様です -- ファイルを関連する銀行口座にアップロードすると、取引が銀行フィードに表示され、マッチングとカテゴリ分けが行われます。

GnuCash（無料、オープンソース）

GnuCashは、libofxライブラリ経由でOFXインポート機能を内蔵しています。OFXファイルを処理するための最良の無料オプションの1つです。

インポート方法： File > Import > Import OFX/QFX に移動し、ファイルを選択して、正しい口座にマッピングします。GnuCashの重複検出はFITIDを使用して二重エントリを防ぎます。

その他の互換性のあるソフトウェア

• Wave -- OFXインポートをサポートする無料の会計ソフトウェア
• Sage Business Cloud -- 銀行取引インポートにOFXを受け入れます
• FreeAgent -- OFXおよびQIFファイルアップロードをサポート
• Moneydance -- OFXダイレクトコネクトとファイルインポートを備えた個人財務ソフトウェア
• KMyMoney -- libofx経由でOFXをサポートするオープンソースの個人財務マネージャー
• Microsoft Money -- 廃止されましたが、一部で使用されています。組み込みのOFXサポートはそのコア機能の1つでした
• Reckon（オーストラリア） -- 銀行フィードインポートワークフローでOFXファイルを受け入れます

QuickBooksは特筆すべき例外です -- QBOブランドのバリアントを好み、INTU.BID識別子を含む.qboファイルでより確実に機能します。

PDF銀行取引明細からOFXファイルを作成する

ほとんどの銀行はOFXダウンロードを直接提供していません。印刷用にはフォーマットされていますが、データ交換用ではないPDFを提供します。一部の銀行は最近の取引（通常は過去90日間）のCSVエクスポートを提供していますが、過去のデータ、閉鎖された口座、またはデジタルエクスポートオプションのない銀行の場合は、PDFしか利用できません。

PDFSubの銀行取引明細コンバーターは、PDF銀行取引明細から取引を抽出し、適切な構造を持つ有効なOFXファイルを生成します。出力には、各取引のユニークなFITID、正しいYYYYMMDD日付フォーマット、適切な取引タイプを持つ符号付き金額、および口座メタデータが含まれます -- これらはすべて会計ソフトウェアがクリーンなインポートに必要なものです。

このコンバーターは、130以上の言語で20,000以上の銀行の明細書に対応しています。デジタルPDF（テキストベースの明細書）はブラウザで処理され、ファイルはデバイスから離れません。スキャンされた、または画像が多い明細書は、サーバーサイドのAI抽出を通じて処理されます。

All-In-Oneプランは、ユーザーあたり月額20ドル（年払い）または月額25ドル（月払い）で、ユーザーあたり月500ページの銀行取引明細が含まれます。すべての有料プランには7日間の無料トライアルが含まれています。結果として得られたOFXファイルをXeroにインポートする詳細なウォークスルーについては、Xero銀行取引明細インポートガイドを参照してください。

よくあるOFXの問題とその解決策

OFXファイルは構造化されていますが、万能ではありません。最も頻繁に発生する問題とその解決策を以下に示します。

1. 無効なXML/SGML構文

症状： ソフトウェアが解析エラーでファイルを拒否する。

原因： 不正なタグ、閉じタグの欠落（2.xファイルの場合）、または説明内の不正な文字。アンパサンド（&）が最も一般的な原因です -- XMLでは&としてエンコードする必要がありますが、"AT&T."のような名前ではそのまま残されることがよくあります。

修正方法： テキストエディタでファイルを開き、生の&を&に置き換えます。バージョン2.xのファイルの場合は、閉じられていないタグも確認してください。

2. FITIDの欠落または重複

症状： インポートで重複取引が作成される、またはソフトウェアが識別子の欠落を報告する。

原因： 一部の変換ツールがすべての取引に同じFITID（0や1など）を生成する、またはタグを完全に省略する。

修正方法： 各FITIDはファイル内でユニークである必要があります。一般的なパターンは、日付と連番カウンターを組み合わせたものです：20260215001、20260215002など。インポート前にテキストエディタでプレースホルダーFITIDを編集してください。

3. 間違った日付フォーマット

症状： 取引が間違った日付に表示される、またはソフトウェアが1900年または2099年の日付を表示する。

原因： DTPOSTEDの値がYYYYMMDDHHMMSSフォーマットに従っていない。YYYYMMDD（時間なし）は問題ありませんが、DD/MM/YYYYやMM-DD-YYYYは誤解析の原因となります。

修正方法： すべてのDTPOSTED値がYYYYMMDDまたはYYYYMMDDHHMMSSを使用していることを確認してください。20260215と20260215120000の両方が有効です。

4. 文字エンコーディングの問題

症状： 取引の説明に文字化け、疑問符、または欠落したアクセント記号が表示される。

原因： ファイルヘッダーは1つのエンコーディング（通常はUSASCIIまたはUTF-8）を宣言していますが、実際のコンテンツは異なるエンコーディングを使用しています。これは、ASCII以外の文字を含む国際的な銀行取引明細で特に一般的です。

修正方法： ENCODINGヘッダーを実際のファイルエンコーディングと一致するように変更します。アクセント付き文字を含む国際明細書の場合、UTF-8が最も安全な選択肢です。一部の古いソフトウェアでは、特殊文字なしのUSASCIIが必要です。

5. バージョン互換性（1.x vs 2.x）

症状： OFX 2.xを期待するソフトウェアが1.xファイルを拒否する、またはその逆。

原因： OFX 1.xはSGML（タグを閉じない）を使用しますが、2.xは正式なXML（すべてのタグを閉じなければならない）を使用します。一方のバージョン用に構築されたパーサーは、もう一方では問題を起こす可能性があります。

修正方法： ほとんどの最新会計ソフトウェアは両方のバージョンに対応しています。お使いのソフトウェアが対応していない場合は、タグを追加する（1.xから2.xへ）または削除する（2.xから1.xへ）ことでバージョンを変換します。テキストエディタの検索と置換機能で、小さなファイルの場合はこれを処理できます。

よくある質問

OFXとは何の略ですか？

OFXはOpen Financial Exchangeの略です。これは、金融機関とエンドユーザーアプリケーション間で金融データを電子的に交換するためのオープンスタンダードであり、Financial Data Exchange（FDX）によって維持されています。

OFXとQBOは同じですか？

ほぼ同じです。QBOは、QuickBooks向けのOFXのIntuitブランド版です。データ構造は同一です -- QBOは銀行識別用のINTU.BIDタグを追加し、.qbo拡張子を使用します。しばしば.ofxを.qboにリネームしても、QuickBooksは受け入れます。

ExcelでOFXファイルを開けますか？

直接構造化データとしては開けません。Excelはファイルをテキストファイルとして開き、生のSGML/XMLマークアップを表示します。OFXデータをExcelで表示するには、まずCSVまたはXLSXに変換するか、OFXタグをスプレッドシートカラムに解析するサードパーティ製アドインを使用する必要があります。

XeroにはOFXとCSVのどちらが良いですか？

OFXの方がXeroには適しています。カラムマッピングなしで自動的にインポートされ、FITIDベースの重複検出が含まれ、曖昧さのない日付フォーマットを使用し、口座メタデータを持ちます。Xero自身のドキュメントでも、手動での銀行取引明細インポートにはCSVよりもOFXを推奨しています。

銀行はOFXダウンロードを提供していますか？

一部の銀行は提供していますが、一貫性はありません。米国、英国、オーストラリアの大手銀行は、最近の取引（通常は過去90日間）のOFXまたはQFXダウンロードを提供している場合があります。多くの小規模銀行、信用組合、国際的な金融機関はPDF明細書のみを提供しています。ダウンロード期間を超える過去のデータについては、通常、PDF変換が唯一の選択肢です。

OFXは安全ですか？

OFX仕様には、送信中のSSL/TLS暗号化や、ダイレクトコネクト用の証明書ベースの認証の規定が含まれています。しかし、ディスクに保存されたOFXファイルはプレーンテキストであり、口座番号や取引詳細が読み取り可能な形式で含まれています。OFXファイルは、他の金融文書と同様に慎重に扱ってください。

OFX 1.xと2.xの違いは何ですか？

OFX 1.xはSGMLマークアップ（タグを閉じる必要がない）を使用しますが、OFX 2.xは正式なXML（すべてのタグを開いて閉じなければならない）を使用します。データ内容は同じです -- 違いは構文です。バージョン1.6は依然として最も広く生成されているフォーマットです。ほとんどの最新会計ソフトウェアは両方のバージョンを問題なく解析します。

OFXファイルを手動で編集できますか？

はい。OFXファイルはプレーンテキストであり、任意のテキストエディタで編集できます。説明を修正したり、金額を訂正したり、欠落したFITIDを追加したり、日付を調整したりできます。タグ構造を維持してください -- 閉じられていない、または一致しないタグはインポートエラーの原因となります。OFX 2.xファイルの場合は、すべての開始タグに対応する終了タグがあることを確認してください。