責任分界点 銀行・ツール PFS構築 御社
銀行明細の取得は BizHawkEye（NTTデータ）、振込データの作成は board（Web21 更新系API） を使います。PFSが担うのは、その「加工・繋ぎこみ」（テキスト→全銀CSV変換・口座別分割・振込データ作成・監視）です。本モックに出てくる画面は、この中央の帯（②）だけです。
「ツールを契約すれば全部つながる」— つながりません。その"最後の1マイル"をPFSが構築します。
各ツールが担うのは BizHawkEyeが全銀テキストで明細を出す／boardが振込データを作る「あと一歩手前」まで。その先の テキスト→全銀CSV変換・口座別のファイル分割・約1,600口座のループ制御・振込データの組み立て・止まらない仕組み・監視 はツール側の機能ではありません。Power Automate で内製されていたのがこの②で、PFSの見積対象はこの②だけです。
① 銀行・ツール領域SMBC／BizHawkEye（明細）／board（振込）
SMBC 口座・振込の受付・実行電子証明書付き専用端末3台
BizHawkEye（NTTデータ）で明細取得全銀形式で取得・蓄積 → テキストで出力
board（Web21 更新系API）で振込データ作成都度の振込・振替に対応
Web21画面での振込承認SMBC公式に「承認はWeb21画面で実施」と明記
ツール自体のセキュリティ・可用性BizHawkEyeはNTTデータがデータ保管・担保
テキスト/データ
本モックが再現する範囲
② PFS 構築領域マクロ／n8n（ローカル完結・買い切り中心）で構築
加工・連携の構築（マクロ／n8n）ローカル完結・約1,600口座のループ制御
月初：テキスト→全銀CSV変換・口座別分割会計取込の必須条件を満たす／中身は不変
月5回：振込・振替データ作成会計課CSV→board様式へ整え作成（承認は人）
セキュリティ・データ保護ローカル完結・データ非流出・AI不使用
自動リトライ・監視・通知止まっても復旧する／止まったら気づける
運用保守・伴走／内製化支援「半分お任せ」の運用体制
CSV / 納品
ツール／銀行との契約（BizHawkEye・board 等）契約・審査は御社側
組合会計課CSVの作成作成ロジックは御社業務（スコープ外）
独自会計システムへの手動取込API口なし・無改修（自動化対象外）
工程別 担当・費用の出方・モック有無
見積の読み方がそのまま分かる表
| 工程 | 担当 | 実現手段 | 費用の出方 | 本モック |
|---|
| SMBC口座への接続・認証 | 銀行 | SMBC（電子証明書付き専用端末） | SMBC利用料 | 画面なし |
| 入出金明細の取得（月1回） | ツール | BizHawkEye（全銀テキスト） | BizHawkEye 月額 | 画面なし |
| 振込・振替データの受付（月5回） | ツール | board（Web21 更新系API） | board 月額 | 画面なし |
| 加工・連携環境の構築（マクロ／n8n・ローカル） | PFS構築 | ローカル設置＋疎通確認 | 初期構築費（買い切り） | あり |
| 約1,600口座のループ処理・進捗記録 | PFS構築 | マクロ／n8n | 初期構築費（買い切り） | あり |
| テキスト→全銀CSV変換・口座別分割（月1回） | PFS構築 | マクロ／n8n | 初期構築費（買い切り） | あり |
| 口座別ファイルの整形・指定フォルダ格納 | PFS構築 | マクロ／n8n ＋ 口座マスタ参照 | 初期構築費（買い切り） | あり |
| 会計課CSV→board様式へ振込データ作成（月5回） | PFS構築 | board（API）＋マクロ／n8n | 初期構築費（買い切り） | あり |
| 失敗時の自動リトライ・通知（n8n採用時） | PFS構築 | n8n エラーハンドリング | 初期構築費（買い切り） | あり |
| セキュリティ設計（ローカル完結・非公開） | PFS構築 | ローカル完結設計＋堅牢化 | 初期構築費（買い切り） | あり |
| 稼働監視・障害一次対応（スポット） | PFS構築 | 監視＋スポット保守 | スポット／都度 | あり |
| 独自会計システムへの取込 | 御社 | 組合会計課が手動（無改修） | — | 対象外 |
| 振込の最終承認・実行 | 御社 | Web21画面で担当者が承認 | — | 対象外 |
この表の使い方：「PFS構築」の行だけが弊社の見積対象です。加工・連携は初期構築費のみの"買い切り"で、以降のランニングは発生しません（保守は必要時のみスポット・概算提示）。BizHawkEye／board／SMBC の利用料は各社へ直接お支払い（弊社を経由しません）。
なぜ「API完全自動化」が成立しなかったか／BizHawkEye＋boardに至った理由
2026-07-29 更新
初版は MoneyLook＋board＋n8n、第2版は SMBC公式API（Web21）一本化 をご提案しましたが、各社を当たり切った結果、API での完全自動化は御社の条件（全銀形式CSV必須・約1,600口座・オンプレ・低コスト）では成立しないことが分かりました。現実解は 明細＝BizHawkEye（全銀テキスト）＋PFSが全銀CSVへ加工／振込＝board（Web21 更新系API・承認は人） です。
| 当たった手段 | 調査結果（御社・弊社の合同調査） |
|---|
SMBC公式API
Web21 サーバー接続サービス | 非現実的・見送り 御社専用口の構築に 初期550万円＋月額22万円＋従量課金。約1,600口座では桁が合わず実現見送り（社長報告用の参考見積りのみ） |
MoneyLook BIZ
SBIビジネス・ソリューションズ | 機能・費用で不可（確定） 参照系のみ・振込不可・全銀CSV取得不可。仮に使えても1,600口座で 月約106万円 |
外部API各社・AnserBizSOL API
SMBC紹介の連携各社／NTTデータ | 全銀形式に非対応 会計事業者向けで 自社独自項目のみ。独自会計にそのまま入らない |
BizHawkEye
NTTデータ／マルチバンクWeb | 明細の突破口 唯一、全銀形式で明細取得可（ただしCSV不可・テキストのみ）→ PFSがCSVへ加工・口座別分割 |
board
ヴェルク／Web21 更新系API | 振込のメイン 振込・振替データの作成が可能（都度対応・SMBCが唯一紹介）。承認は人が実施 |
結論：API での完全自動化は、
費用（Web21）・機能（MoneyLook／外部APIが全銀CSV非対応）・承認（人手必須）のいずれかで壁があり成立しませんでした。そこで
明細＝BizHawkEye（全銀テキスト）＋PFSが全銀CSVへ加工、
振込＝board（承認は人） という現実解に至りました。対抗馬の AnserDATAPORT はバッチ伝送専用で都度の振込・振替には非対応のため対象外です。
→ 選定・比較レポートで詳しく見る
よくある誤解
「ツールを契約すれば、あとは全部自動で片付く」
→ 片付きません。BizHawkEye が出せるのは 全銀テキストで明細を出す ところまで、board が出せるのは 振込データを作る ところまで。そこから先の「テキストを全銀CSVへ変換する」「約1,600口座を口座別のファイルに分割する」「用途ごとに指定フォルダへ格納する」「会計課のCSVを board 様式へ組み立てる」は各ツールの機能ではないため、必ず構築作業が発生します。Power Automate を組んでいたのは、まさにこの部分です。
実際の切り分け
「全銀形式の明細取得」はBizHawkEyeが、「取り込める形への加工・繋ぎこみ」はPFS（マクロ／n8n）が担う
→ 明細は BizHawkEye が全銀形式で確実に取得（NTTデータがセキュリティ担保）。その全銀テキストを独自会計に取り込める全銀CSVへ変換・口座別分割し、失敗したら自動で再実行し、上限を超えたら担当へ通知するのがPFS構築部分の仕事です。加工はマクロ／n8n でローカル完結・買い切り。RPA（Power Automate）は原則残しません。
本モックについて：本モックはコンセプトを可視化した参考資料であり、機能・運用はあくまでも現時点の仮定です。実際のシステムでこのUI画面を作るわけではありません。本案件の開発対象は 加工・連携処理（マクロ／n8n のバックエンド処理） で、専用UI・管理画面の作り込みは今回のスコープ外です（当面はツール標準UIで代替／ご要望があれば別途お見積り）。実運用の詳細は御社とのお打ち合わせで確定します。
連携ワークフロー（マクロ／n8n） PFS構築
実現手段は 単純な変換ならマクロ（Excel/VBA）、条件分岐・大量ループ・監視まで含むなら n8n（オンプレ・セルフホスト） を選びます。ここでは n8n の例で、BizHawkEye が出力した全銀テキスト を「全銀CSVへ変換 → 口座別に分割 → 指定フォルダ保存 → 通知」まで一連で処理します（＝月初フロー）。大量処理の途中で失敗しても、自動リトライ＋通知 で人が張り付かなくても完走します。マクロ／n8n とも ローカルで起動し、データを外に出しません（サーバー常時稼働・オンライン接続を前提としません）。RPA（画面自動操作）は使いません。
月初ワークフロー定義 — 変換から保存・通知まで
正常稼働中
PFS
全銀CSVへ変換
テキスト→CSV（約1,600口座）
左端の
グレー破線ノード は BizHawkEye（PFS構築対象外）。それより右の
6ノードすべてがPFSの構築物 です。「実行する」を押すと
大量変換処理が途中で中断する障害をわざと発生 させ、n8n が
検知 → 自動リトライ → 復旧 → 通知 する流れをその場で再現します。
※単純な変換で足りる場合は、サーバー不要のマクロ（Excel/VBA・ローカル実行）を選びます。変換後の口座別分割・仕分け（会計課の手動取込へ渡すだけ）は
月初：明細加工で詳しく再現します。
実行ログ
ライブ
待機
右上の「実行する」でワークフローを起動してください。
※障害発生 → 自動リトライ → 復旧までを再現します
ここがPFSの構築価値（＝各ツールに無いもの）
自動リトライ＆エラー通知（n8n採用時）
大量処理が途中で失敗しても間隔を空けて再実行し、担当へ即アラート。人が張り付かなくても復旧する。
全銀CSV変換・口座別分割
BizHawkEyeの全銀テキストを全銀CSVへ変換し、口座別のファイルに分割。金額など中身は一切変えない。
約1,600口座のループ制御・進捗記録
どの口座まで終わったかを記録し、失敗した分だけ再実行。月初フローと月5回の振込作成を一連で自動化。
ローカル完結（データ非流出・買い切り）
マクロは完全ローカル、n8n はオンプレにセルフホスト。AI不使用・外部非公開。初期構築費のみで以降のランニングなし。
明細取得の安定性は
BizHawkEye（NTTデータ）が、後工程（変換・分割・保存／振込作成）の安定性は
PFS（マクロ／n8n）が保証します。
→ セキュリティを見る
セキュリティ ・ データ保護 PFS構築・設計
「情報漏洩は絶対に避けたい・社内AIは禁止・USBも禁止」というご方針に、本構成（マクロ／n8n のローカル完結）がどう適合するかをまとめました。明細を蓄積する BizHawkEye は NTTデータがセキュリティを担保します。ネットで見つかる「n8nの脆弱性」記事への回答も、事実ベースで正直に記載します。
大前提：加工処理は社内で完結し、データを社外に出しません
弊社が担う テキスト→全銀CSV変換・口座別分割・振込データ作成 は 社内PC（またはオンプレ社内サーバー）だけで動作します。マクロは完全にローカル、n8n を使う場合もセルフホスト（オンプレ）・インターネット非公開です。外部SaaS・外部AIにデータを預けません。また銀行データの中身（金額など）は改変せず、形式変換と分割のみ行います。報道されている n8n の重大脆弱性（未認証で管理者権限・任意コード実行に至る類）は、いずれも 「n8nを外部公開している場合」 に成立するため、本件は攻撃の到達経路そのものが存在しません。
データはどこにあるか ― BizHawkEye（NTTデータ）＋ ローカル完結
| 観点 | 本件（BizHawkEye ＋ PFSのローカル加工）での扱い |
|---|
| 明細データの一次保管 | BizHawkEye 上 NTTデータが提供・運用し、セキュリティを担保（国内大手） |
| PFSの加工処理 | 社内で完結 社内PC／オンプレで ローカル動作・外部非公開（常時オンライン接続を前提としない） |
| 外部SaaS・外部AIへの送信 | なし AIノードを使わないため外部AIへデータは出ません |
| 銀行データの中身 | 改変しない 形式変換（テキスト→全銀CSV）と口座別分割のみ |
| n8n を使う場合 | オンプレ・セルフホスト インターネット非公開（マクロならサーバー自体が不要） |
明細を蓄積する BizHawkEye は国内大手 NTTデータが運用・保管するため、情報管理の観点で安心材料になります。そこから先の 「テキスト→CSV加工」以降は社内で完結し、弊社の処理範囲で外部にデータが出ることはありません。
データ非流出
加工処理・データはすべて社内（社内PC／オンプレ）で完結。ローカルで起動でき、常時オンライン接続を前提としない。
AIを一切使わない
スケジュール・データ連携・分岐・保存のみで完結。AIノードは使わないため外部AIへデータは出ません。
外部非公開（閉域）
n8n採用時も管理画面ポートを外部に晒さない。社内ネットワークの内側のみ。マクロならサーバー自体が不要。USBレス・外部リモート不可の運用とも整合。
認証情報は暗号化
口座認証などは暗号化キーで暗号化してDB格納。キーは別管理でDBが漏れても復号不可。
「n8nの脆弱性」記事への回答 — 正直に開示します
オープンソースゆえ情報が公開されている
| ご覧になった記事の脆弱性 | 成立条件 | 本件での扱い |
|---|
未認証で管理者権限・任意コード実行
例：CVE-2026-21858（CVSS 10.0）等 | インターネット公開時のみ
Webhook/フォームが外部到達可能 | 到達不能 外部非公開のため経路なし |
編集権限者によるOSコマンド実行
社内の悪意ある操作を想定 | ワークフロー編集権限が必要 | 限定 管理者を絞り一般利用者に編集権限を与えない |
| 上記いずれのCVEも | 旧バージョン | 修正版あり 最新版へのアップデート運用で解消 |
誠実にお伝えします：n8nはオープンソースゆえ脆弱性情報が公開されます（＝隠されないので対処できる）。重要なのは「公開されているか」ではなく「外部公開しない・管理者を絞る・最新版を保つ」という運用で、これらは本件のオンプレ前提と完全に一致します。なお、単純な形式変換で足りる場合はマクロ（VBA）を選べば、そもそもサーバーもネットワーク公開も不要です。
PFSが実施する堅牢化（本件構成）
外部非公開：管理ポートを社内閉域のみに限定（最重要）
認証強化：強固なパスワード＋管理者へ多要素認証（MFA）
最小権限：一般利用者に編集権限を与えない（RBAC）
認証情報の暗号化キーを安全に分離保管
最新版へのアップデート運用を月額保守で継続
ネットワーク分離＋ファイアウォールで隔離
n8n社（提供元）のセキュリティ体制
セキュリティ管理を SOC 2 フレームワークに整合させ、独立監査人の年次監査を実施（SOC 3レポートを一般公開）
RBAC（役割別権限）／SSO・SAML・LDAP（上位プラン）
監査ログを12か月以上保持
クラウド版は保存時暗号化（AES256）。本件はセルフホストのため自社管理
「SOC 2 Type II 取得」等の正式表記は最終提案前にn8n公式へ確認します（本モックはあくまで仮定を含みます）。
他社の導入事例（公開情報）
n8nは3,000社超が利用
| 企業 | 用途 | 効果 |
|---|
| Vodafone | セキュリティ脅威対応の自動化 | 約£2.2M削減 |
| Delivery Hero | IT運用ワークフロー自動化 | 月200時間超削減 |
| K33 | AML（アンチマネロン）業務自動化 | 金融コンプラ |
| StepStone | 毎日200超の業務連携 | 2週間→2時間 |
金融・バックオフィス文脈の海外大手が中心です。国内の名前を出せる事例は商談時に口頭で補足します（某大手警備会社 等）。
RPA（画面操作） vs n8n（API/連携） の安全性
| 観点 | RPA / Power Automate | n8n（本件） |
|---|
| 動作方式 | 画面のボタンを操作 | API/ファイルに直接連携 |
| 安定性 | UI変更で止まる | UI変更の影響を受けにくい |
| 認証情報 | 画面上に露出しうる | 暗号化して保管 |
| 監査 | ログが粗い | 実行ログで追跡可能 |
今回は 明細＝BizHawkEye（取得）／振込＝board（作成） を用い、加工はマクロ／n8n（ローカル）で行うため、常時の画面操作（RPA）は原則不要です。board への一括投入可否など最終確認は導入前に行います（保険として現行RPA継続／ブラウザ制御も残せます）。
運用監視 ・ アラート PFS構築・保守
Power Automate で一番つらかった「止まったことに気づけない」を解消する画面です。実行状況・失敗・リトライ結果をここに集約し、閾値を超えたら担当者へ通知します。一次対応はPFSが月額保守で実施します。
今月のワークフロー成功率
99.4%
失敗5件はすべて自動リトライで復旧
通知までの平均時間
18秒
検知 → Teams / メール
一次対応
PFS 保守
平日 9:00–18:00（応答目標 1営業日以内）
直近の実行履歴
監視中
| 日時 | ワークフロー | 件数 | 所要 | 結果 | 対応 |
|---|
| 07/11 09:00 | 月初 全銀CSV変換 → 分割・保存 | 96 | 42秒 | 成功 | — |
| 07/10 10:00 | 月5回 振込データ作成 | 34 | 51秒 | 成功 | — |
| 07/03 09:00 | 月初 全銀CSV変換（処理中断） | 76 | 2分18秒 | リトライ後 成功 | 自動復旧(2回目) |
| 07/02 10:00 | 月5回 振込データ作成 | 41 | 44秒 | 成功 | — |
| 07/01 09:00 | 月初 全銀CSV変換 → 分割・保存 | 88 | 39秒 | 成功 | — |
| 06/28 10:00 | 月5回 振込データ作成（承認画面応答なし） | 4 | — | 失敗 | |
アラート設定（PFSが初期設計・以後は保守で調整）
直近14日の実行結果
通知先は 御社担当者＋PFS保守窓口 の両方。まずPFSが一次対応し、御社の判断が必要なものだけエスカレーションします（＝「半分お任せ」）。
Power Automate（現状） と PFS構築部分 の運用比較
| 観点 | Power Automate（現状） | PFS構築（n8n） | 誰が担う |
|---|
| 月初混雑・サイト変更で止まる | 止まる 都度張り付き | 自動リトライで続きから復旧 | PFS |
| 処理が失敗したとき | 気づけない 手動で確認 | 自動リトライ＋即通知 | PFS |
| 障害の一次対応 | 中務様が調査 属人化 | PFS保守が一次対応 | PFS |
| リカバリデータ作成 | 手作業で毎回作成 | 不要（続きから再実行） | PFS |
| フローの改修 | 自社で作り直し | 月額保守に含む／内製も可 | PFS |
| 振込の最終承認・実行 | 社内 | 社内（変更なし） | 御社 |