為替予約とヘッジ対象の残高を突き合わせて、過不足と指定のずれを洗い出す

処理の起点を決める

2つのトリガーを置きます。

（1）日次：毎営業日の朝8時

前日からの変化だけを見ます。新しく締結した予約、消えた債権、期日が変わった取引。 ここで拾えば、月末にまとめて驚くことがありません。

（2）月次：月初の第2営業日

全件を突き合わせます。会計システムの月次締めが終わってからでないと、残高が確定しません。 締めのタイミングは会社ごとに違うので、経理部と合わせてください。

Make のスケジュール設定では、実行の間隔として毎日・毎週・毎月などを選べます。日付を指定した月次の実行もできます。

銀行の明細が自動で取れない場合があります。 ウェブ明細を手でダウンロードする必要があるなら、ファイルが特定のフォルダに置かれたことをトリガーにしてください。 取得だけは人が行い、その後を自動にする形です。

期末には手動で走らせられるようにしてください。 決算の作業中は、何度も確認したくなります。シナリオを手で起動できる入口を1つ用意しておくと、使い勝手が大きく変わります。

入力データを集める

データの取得方法を決める

銀行ごとの書式： ここを最初に整えてください。銀行3行と取引があるなら、3つの書式の対応表を作ります。

この対応表があれば、書式の違いはAIを使わずに吸収できます。 銀行が増えたら1行足すだけです。書式の変換をAIにさせないでください。 決まった変換に生成AIを使うと、ぶれる余地を作るだけです。

対応づけの記録： 現状は表計算ソフトの備考欄にあるはずです。これを、次の形の表へ移してください。

「予約の一部だけを充てる」列が要ります。 100,000ドルの予約を、60,000ドルの債権と40,000ドルの予定取引に分けて充てることがあります。1対1で持つと、この形が表せません。

期日のずれの許容： 「予約の期日と決済予定日が7日以内なら同一の月とみなす」といった定めを、財務部で決めてください。決めずに始めると、判定の基準が毎回変わります。

前回の突合結果： 差分を出すために必須です。担当者が「これは問題なし」と確認した件は、次回から印を弱めます。 同じ件が毎月上位に出続けると、一覧が読まれなくなります。

対応づけの記録を移す作業が、この構成でいちばん重い部分です。 現状、備考欄に自由文で書かれている情報を、構造化された表へ移します。180件の建玉があれば、180行を手で作ることになります。

この作業には、副産物があります。備考欄が空の行が必ず出ます。 「この予約は何に充てるつもりだったか」を、担当者が思い出せない行です。その数を数えてください。 20行あるなら、それがこの構成を入れる理由になります。その20行は、いま誰も説明できない予約です。

移す作業は、期日の近い順に進めてください。 期日が18か月先の予約は、対応づけが決まっていないことも普通にあります。まず3か月以内に期日が来る予約から、確実に埋めてください。 全部を一度に埋めようとすると、途中で止まります。

予定取引の一覧は、事業部門から月次でもらう形が現実的です。 リアルタイムで連携できれば理想ですが、受注の見込みは事業部門の判断で更新されるため、自動で取れる形になっていないことがほとんどです。 更新日を必ず記録し、古い情報で判定していないかを確認できるようにしてください。

AIへ渡す前に整形する

1. 書式の統一 … 銀行ごとの対応表に従い、通貨・金額・期日・取引番号の形をそろえます。ここはAIを使わず、決まった変換で行います
2. 通貨の正規化 … 「USD」「US$」「米ドル」を1つにそろえます
3. 期日の月への割り当て … 期日を年月に丸め、通貨×年月の組み合わせを作ります
4. 既存の対応づけの適用 … 記録がある組み合わせを先に結びつけます
5. 完全一致の照合 … 通貨・金額・期日が一致し、対応づけもある組み合わせを「照合済み」として外します
6. 前回結果との突き合わせ … 前回あって今回ない予約、今回新しく現れた対象を抜き出します

5の段階で、220件のうち140件程度が外れます。 AIへ回すのは、残りの60〜80件です。ここを丁寧に作ると、費用と処理時間が3分の1になります。

AIに処理させる

4つの判定をさせます。

そのうえで、確認の優先度を付けさせます。

金額の計算そのものはAIにさせないでください。 合計や差は、シナリオの中で計算します。AIが担うのは、「この差が確認を要するものかどうか」の判断です。

会計上の判断もさせません。 「ヘッジ会計の要件を満たしていません」といった記述を書かせないでください。この構成が出すのは事実であって、会計上の結論ではありません。

指示内容を固定する

あなたは財務部で為替予約の残高を点検する担当者です。
下のデータについて、確認が要る点を判定してください。

【厳守事項】
- 合計や差の計算はすでに済んでいます。計算し直さないでください。
  与えられた数値をそのまま使ってください。
- 会計上の判断をしないでください。
  「ヘッジ会計の要件を満たさない」「繰延処理できない」と書かないでください。
  会計上の扱いは経理部と監査法人が決めます。
- 為替の見通しを書かないでください。
  「円安が進むため予約を増やすべき」と書かないでください。
- 予約の締結・解約を提案しないでください。
  「12月のUSDが不足しています」という事実までにとどめてください。
- 与えられていない取引を推測で補わないでください。
  対象が見つからない場合は「対象なし」としてください。
- 期日のずれは、下の「許容日数」に照らして判定してください。
  一般的な慣行で補わないでください。
- 前回の突合で担当者が「確認済み・問題なし」とした件は、
  状況が変わっていなければ優先度を「低」にしてください。

【許容日数】
{tolerance_days}

【通貨×年月ごとの集計（予約の合計、対象の合計、差）】
{aggregates}

【対応づけられた組み合わせ（予約、対象、金額、通貨、期日）】
{matched_pairs}

【対応づけの記録がない予約】
{unmatched_contracts}

【対象が消えている予約（前回はあった対象が今回ない）】
{orphaned_contracts}

【前回の突合結果と、担当者の確認内容】
{previous_result}

「計算し直さないでください」の指示が要ります。 数値を渡すと、モデルは検算を始めることがあります。そこで桁を間違えると、判定そのものが崩れます。 計算はシナリオ側で確定させ、AIには判断だけをさせてください。

「為替の見通しを書かない」も必須です。 為替の予想を書かせると、それが財務部長への報告に混ざります。この構成は相場観を扱いません。

「前回確認済みの件は優先度を低に」の指示が、運用を続ける鍵になります。 同じ件が毎月「高」で出続けると、一覧を見なくなります。担当者が一度確認した件は静かにするという設計が、読まれ続ける一覧を作ります。

ただし、「状況が変わっていなければ」という条件を必ず付けてください。 前回「予定取引が遅れているだけ」と確認した件でも、期日が近づけば意味が変わります。期日まで3か月を切ったら、確認済みでも優先度を戻すという扱いにしてください。

「予約の締結・解約を提案しない」の指示も外せません。 「12月のUSDが不足しているので、50,000ドルの予約を追加することを推奨します」という文が出ると、それが報告書に載ります。為替の予約を増やす判断には、相場の見通しと資金繰りが関わります。 財務部長の判断領域です。

「会計上の判断をしない」の指示については、具体例を書いておくことが有効です。 「ヘッジ会計の要件を満たさない」「繰延処理できない」「時価評価が必要」といった表現を、そのまま禁止語として書いてください。抽象的に「会計上の判断をするな」と書くだけでは、モデルは境界を誤ります。

出力形式を固定する

{
  "run_date": "",
  "run_type": "daily | monthly",
  "currency_periods": [
    {
      "currency": "",
      "period": "YYYY-MM",
      "contract_total": 0,
      "exposure_total": 0,
      "difference": 0,
      "priority": "high | medium | low",
      "reason": ""
    }
  ],
  "findings": [
    {
      "finding_type": "over_hedge | under_hedge | currency_mismatch | date_mismatch | missing_link | orphaned_contract | changed_since_last",
      "contract_no": "",
      "target_id": "",
      "currency": "",
      "amount": 0,
      "value_date": "",
      "detail": "",
      "priority": "high | medium | low",
      "previously_confirmed": false
    }
  ],
  "changes_since_last": {
    "contracts_added": [],
    "contracts_removed": [],
    "targets_added": [],
    "targets_removed": [],
    "amounts_changed": []
  },
  "matched_count": 0,
  "reviewed_count": 0
}

Claude API の structured outputs では、出力にスキーマを指定すると、そのスキーマに沿ったJSONが返ります。 列の抜けや型の違いを後から直す処理が減ります。

finding_type を細かく分けている理由があります。 「過不足」とひとくくりにすると、超過と不足が同じ扱いになります。この2つは対応がまったく違います。 超過は予約の一部を解約するか、別の取引に充てるかの判断が要ります。不足は新たに予約を入れるかの判断です。

previously_confirmed の列は、一覧の読みやすさを左右します。 前回確認済みの件に印を付けておけば、担当者は新しく出た件だけを見れば済みます。

changes_since_last が、この構成でもっとも価値のある部分です。 現状の突合では、前月との差分が見えません。「先月あった予約が今月の明細にない」ことに気づける仕組みは、いまありません。

システムへ連携する

結果は一覧として出すだけで、システムへの書き戻しは行いません。

会計システムへの書き戻しは絶対に行わないでください。 仕訳や残高を自動で動かす構成にすると、誤りが帳簿へ直接入ります。この構成は点検であって、記帳ではありません。

対応づけの記録の更新も、人が行います。 「この予約はあの案件に対応する」という記録は、担当者が確認して入れます。AIの推定で自動的に紐付けないでください。

Teams への通知は、優先度「高」があるときだけにしてください。 毎日通知が来ると読まれなくなります。日次の実行で何も出なければ、通知しない。 これが続ける条件です。

人が確認する

財務担当者の確認は必ず残します。

確認を速くするための設計が効きます。

• 優先度の高い順に並べる
• 前回確認済みの件は畳んで表示する
• 過不足の金額を、円換算でも併記する（感覚がつかみやすくなります）
• 同じ取引先・同じ案件の件をまとめる
• 前回からの変化を、別のシートに分ける

3つ目が効きます。 「USD 50,000の超過」と言われても大きさが分かりません。「約750万円相当」と併記すると、確認の順番を決めやすくなります。 換算に使うレートは、期末の直近レートか社内レートを明示してください。

確認の結果は必ず記録してください。 「予定取引の見込みが変わったため。対応不要」と書いておけば、翌月は優先度が下がります。この記録がないと、同じ件を毎月調べ直すことになります。

例外に対処する

「判定の件数が想定を大きく超えたら止める」は、必ず入れてください。 通常60〜80件のところ200件出たなら、データの取得か整形が壊れています。そのまま一覧を出すと、担当者が200件を見る羽目になり、翌月から使われなくなります。

記録を残す

この記録は、月次の点検の証跡になります。

• 実行日時と、実行の種類（日次／月次）
• 取得したデータの件数と、取得元ごとの取得日時
• 照合済みとして外した件数
• AIへ回した件数と、判定の結果
• 担当者の確認内容と、確認日
• 未確認のまま翌月へ繰り越した件
• 判定が誤っていた事例と、その原因

「取得元ごとの取得日時」は必ず残してください。 会計システムの残高が締め前のものだったのか締め後のものだったのかで、突合の意味が変わります。後から見返したとき、これがないと結果を解釈できません。

「判定が誤っていた事例」も記録してください。 確認が要る差異を「低」と判定していた、逆に問題のない件を「高」で出し続けていた、といった事例です。これが、許容日数や優先度の基準を直す材料になります。

記録の形は、1回の実行につき1行が基本です。 そこに、判定した件数と確認された件数を持ちます。個別の差異は別の表に、実行のIDで紐づけて持ってください。 1行に全部を詰め込むと、後から集計できません。

外貨建ての取引データは、取引先の情報を含みます。 保管場所を財務部に限定し、閲覧範囲を絞ってください。予約レートは銀行との取引条件であり、社外へ出せない情報です。

保存期間は、会計帳簿の保存期間に合わせるのが安全です。 点検の記録は、決算の裏付けとして求められることがあります。