異常を見つけてから、根拠付きで閉じるまで
運用センターの一覧を起点に、再送せず調べ、担当機能へ戻り、判断を残す。
本文の説明・図・掲載コードだけで読み進められます。出典リンクは、権限のある人向け（非公開GitHub）です。GitHubで閲覧権限がある方だけ開けます。
この記事でわかること
- 検知した事実と、原因や不正の判断を分ける
- 結果不明を失敗と決めつけて再送しない
- 問題の終了は元データと根拠を読み直して判断する
この記事の目次
一件の黄信号から、仕事を始める
架空の運用担当・高橋さんが出勤すると、運用センターに「結果不明の支払」と「照合差異」が出ていたとします。同じ色でも、取るべき行動は同じではありません。結果不明は確定したかをまだ判断できない状態、照合差異は二つの記録が一致していない状態です。色の数を減らす前に、何が観測されたのかを分けます。
v12 のセンターは例外、照合差異、AML、承認待ちを集め、各項目から担当する画面やトレースへつなぎます。キューの状態を別の場所へコピーして管理せず、元データから組み立てるため、対処したのに一覧だけ古い状態になるずれを減らします。その代わり、読取り時の計算量が増えるという交換条件があります。
返事が来ない支払を、もう一件作らない
支払の応答が返らない場合、相手側ではすでに受け付けている可能性があります。「見えないから未送金」と決めつけて再送すると、同じ用件のお金が二回動き得ます。現行の対応手順は、最初に再送を止め、支払詳細で決済側の状況を照会し、判明した事実へ状態を合わせる流れを示しています。
このシミュレーターの手順では、未着が二回確認された場合に限り、管理責任者が同じ E2E ID で再送する条件があります。これは実銀行網にそのまま適用できる一般ルールではありません。学ぶべき中心は、結果不明と失敗を分け、元の識別子を保って確認することです。件数が多い、長引く、影響が広い場合は一件ずつの処理だけでなくインシデントとしてまとめます。
支払から仕訳まで、同じ出来事をたどる
トレースは、支払、金融イベント、仕訳、口座、AML ケースやアラートを出発点に、関連する記録をつなぎます。高橋さんは「十万円の支払がある」「対応する記帳がある」「残高との照合が合う」を一つの流れとして見ます。別々の画面で似た金額を見つけただけでは、同じ出来事の証拠になりません。
照合差異のときは、どの勘定や口座で違うのかを絞り、キャッシュのずれか、記帳の欠落かなどの原因へ進みます。数値を直接書き換えて一致させると、原因と修正の履歴が消えます。専用の訂正や修復と、その確認を使うのは、元の誤りと直した事実の両方を追えるようにするためです。
アラートを、人の結論へ飛躍させない
AML の走査は元帳の取引を対象にし、短時間の頻繁な出金、口座開設後の大きな出金、急な通過、通常と異なる金額をルールで拾います。アラートには重複を避ける識別と根拠があり、口座単位の調査ケースへ進めます。検知は「調べるべき条件に合った」という事実で、犯罪や不正の断定ではありません。
調査では証拠やメモを残し、誤検知、問題なし、二次確認、上申を分けます。二次確認には別の担当者、上申の結論には責任者という条件があります。アラートを立てるだけで口座を凍結せず、送金の取消しや仕訳も作りません。実際の監視リスト照合、機械学習、当局への報告を備えた仕組みではなく、架空データで判断過程を学ぶ範囲です。
原因と解消を残してから、終了する
インシデントは OPEN から INVESTIGATING、RESOLVED、CLOSED へ進みます。解消には根本原因と対応内容が必要で、終了は管理責任者の判断です。重大度には対応目標の時間がありますが、画面上の目標があるだけで誰かへ自動通知されるわけではありません。自動起票や呼出しは v12 の実装範囲に入っていません。
法人の指定日支払のケースでも、本人の「終わりました」というメモだけで閉じず、別の担当者が支払と仕訳の根拠を読み直します。ケースが閉じたことは送金を新しく実行した意味ではありません。障害の記録、顧客の指図、金融の確定を別々にすることで、調査の手間を減らそうとして資金操作を増やす失敗を避けます。
対応記録を読む：必要な四つの説明
説明用の擬似コードです。自動で修復や送金を行う指示ではありません。
観測：いつ、どの対象で、何を検出したか
根拠：支払・イベント・仕訳はどう結び付くか
対応：誰が、どの許された操作をしたか
確認：何を再照合し、誰が終了を判断したか「いま問題がない」は、いまの確認で支える
昨日の照合が成功していても、その後に取引や設定が変われば、いまの状態の証拠にはなりません。十月三日の修復記録は、元帳検査や日次締めの鮮度の AMBER を別管理し、公開直前の新しい確認へ残しています。表示のルールを緩めて緑にするより、何が古いのかを明らかにする方が、運用には役立ちます。
全体の復旧中でも、インシデントや診断の記録を残せる一方、業務設定の変更は止まる場合があります。停止を解除して調査を楽にするのではなく、許された範囲の観測で判断を集めます。本ガイドは固定ソースの手順を説明したもので、現在の公開環境の異常を調べたり、支払を再送したり、実在人物の AML 判断を行った結果ではありません。
日次という言葉にも、異なる仕事が含まれます。v12 の記録では、会計の日次締めと、銀行の営業日を閉じたり開いたりする処理は別のものとして残っています。片方が終わった表示だけで、もう片方も終わったと判断すると、必要な照合や実行を飛ばす恐れがあります。同じように、インシデントの対応目標を超えたことと、一覧の項目が長く残っていることも、表示の意味は同一ではありません。運用センターはさまざまな仕事を一か所で見せますが、元の機能が持つ条件まで一つにまとめません。高橋さんが引き継ぐなら「黄色が二件」ではなく、どの検査がいつ行われ、何がまだ一致せず、誰の確認を待っているかを伝えます。その形なら、次の担当者は同じ画面を眺めるところから調査をやり直さずに済みます。
出典と、確認できた範囲
以下のリンクは非公開GitHubへの出典で、閲覧権限が必要です。本文はリンク先を開かなくても読める構成です。固定コード・設計資料を参照していますが、今回、この読み物のために銀行の取引やDB操作、本番試験は実行していません。実装や資料にある検査と、こちらで実施した検証を混同しないようにしています。
- v12 運用センター ↗（非公開GitHub・要権限）
元データから作るキューとインシデントの流れ - 現行の対応手順 ↗（非公開GitHub・要権限）
結果不明や照合差異ごとの案内と遷移先 - v11 AML の実装範囲 ↗（非公開GitHub・要権限）
ルール検知・ケース・二次確認と非目標 - 法人支払の調査ケース ↗（非公開GitHub・要権限）
ケースの解消と資金移動を分離する - 2026年10月3日の修復 RC 記録 ↗（非公開GitHub・要権限）
追加修復と最新記録時点の検証・未実施の範囲 - 停止境界の強化コード ↗（非公開GitHub・要権限）
業務変更の停止と診断・無効化の例外
MiniBankは学習・検証用の銀行アプリです。架空の金額や人物は、仕組みを説明するための例です。
つながる読み物
ここまで読んだ記録を、ひとつ。
自分のペースで。あとから取り消すこともできます。