TONA・TIBOR・長期プライムレートの公表値を毎日取り、変動金利の借入ごとに次の適用金利の見込みと予算との差を財務の担当に知らせる

処理の起点を決める

トリガーは Schedule Trigger で、毎営業日の11時です。 ワークフローのタイムゾーンを Asia/Tokyo にします。n8n の公式の説明では、ワークフローにタイムゾーンが無ければインスタンスのタイムゾーンが使われ、自分でホストする場合の既定は America/New_York とされています。Schedule Trigger を使うワークフローは、保存して公開しないと動きません。

11時にするのは、TONA の確報が出た後に取るためです。 日本銀行のコール市場関連統計のページでは、前営業日の確報は午前10時頃、当営業日の速報は午後5時15分頃（年末日を除く月末日は午後6時15分頃）と案内されています。API のマニュアルでは、検索サイトの時系列統計データは原則8時50分頃に更新し、業務の都合で遅れる場合があるとされています。取った値の日付が前営業日でなければ、13時にもう一度取ります。

TIBOR の入力を促す通知も、同じワークフローから出します。 台帳から「確定日が翌営業日の TIBOR 連動の借入」を拾い、前日の夕方に担当者へ入力を頼みます。

入力データを集める

質を決めるのは、台帳の「計算の決まり」の列です。 これまで担当者の表計算の式に埋まっていた決まりを、借入ごとに列として書き出すことが、この構成の最初の仕事です。書き出せない決まりは、金融機関との契約書に戻って確かめます。

TIBOR には「どこから入れたか」を必ず付けます。 情報提供会社の画面か、金融機関の通知か。ウェブサイトの参考値を写したものと区別できるようにしておきます。

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

TONA の系列は、最初にメタデータAPIで確かめます。 API のマニュアルでは、メタ情報は系列コードや系列名称などの属性情報で、コードAPIのパラメータを作るときに利用できるとされています。コール市場の DB のメタ情報を一度引き、無担保コールO/N物レートの平均値（日次）の系列コードを設定に書きます。

リクエストには Accept-Encoding: gzip のヘッダーを付けます。 マニュアルでは、HTTP のレスポンスを gzip で圧縮して返す機能に対応しているとされています。HTTP Request ノードは GET を含む主要なメソッドに対応し、応答の形式（自動判別・ファイル・JSON・テキスト）や、2xx 以外でも失敗にしない設定を選べます。

長期プライムレートのページは、値が変わったときだけ取り込みます。 ページの「更新日」の文字を前回の値と比べ、変わっていれば表を読み直します。

AIへ渡す前に整形する

1. 値の日付を確かめる … TONA の最新の日付が前営業日かを見ます。月曜や祝日明けは、前営業日が何日前かを営業日の暦で数えます
2. 欠けた日を埋めない … 後決め複利の計算に要る日の値が欠けていれば、埋めずに「未取得」として計算を止めます
3. 単位をそろえる … 指標の値はすべて年％で持ち、スプレッドも年％で台帳に書きます
4. TIBOR の入力を確かめる … 前回の値から決めた幅以上に動いていれば、打ち間違いの疑いとして担当者に確かめ直してもらいます
5. 台帳の条件の欠けを拾う … 計算の決まりの列が空の借入は、計算に回さず「条件未記入」とします
6. 確定済みの利息期間を分ける … すでに金融機関の通知で金利が確定している期間は、見込みを出さずに確定値を使います

2番目と5番目は、計算を止める判断です。 欠けた値や書かれていない条件を推測で補うと、それらしい見込みが出て、誰も止められなくなります。 止めて人に知らせるほうが、後で直す手間が小さく済みます。

AIに処理させる

させるのは、借入1本ごとに、どの道具をどの順で呼ぶかを決め、結果を予算と並べて、注意点を言葉にすることです。

どの計算の道具を呼ぶかは、台帳の指標の列で決まります。 エージェントに判断させるのは、条件が足りないときに計算を呼ばずに止めることと、過去の見込みと確定値の差が大きい借入に注意を付けることです。

3行目がいちばん起きやすい失敗です。 「今後も上昇が見込まれるため」のような一文を、エージェントは自然に書き足します。その一文が経営会議の資料に写されると、相場の見通しを財務が述べたことになります。

指示内容を固定する

AI Agent ノードの System Message に次を入れます。

あなたはメーカーの財務部で、変動金利の借入ごとに、次の適用金利と利息の見込みを
まとめる立場です。計算はすべて道具が行います。あなたは計算をしません。

【手順】
1. get_loan で台帳の行を読んでください。
2. 指標（index）に応じて、使う計算の道具を1つ選んでください。
   TIBOR → calc_tibor_loan ／ TONA → calc_tona_compound ／
   長期・短期プライム → calc_prime_loan
3. get_rates で、台帳の確定日の決まりに合う期間の値を取り、計算の道具に渡してください。
4. get_budget と get_history を呼び、予算との差と、過去の見込みと確定値の差を並べてください。

【止めるとき】
- 台帳の計算の決まり（calc_rules）に空の項目があれば、計算の道具を呼ばずに
  status を "missing_terms" にし、空の項目名を書いてください。
- get_rates が返した値に欠けた日があれば、status を "missing_rates" にしてください。
  欠けた日の値を、前後の値などで補わないでください。

【書かないこと】
- 金利や利息の数字は、道具が返した値だけを書いてください。自分で計算しないでください。
- 今後の金利の上がり下がりの予想を書かないでください。
- ヘッジや借換えをすべきかを書かないでください。
- 注意点（notes）は、確定日・使った値の日付・過去の差・条件の欠け、の事実だけにしてください。

「計算をしない」を冒頭と末尾の2か所に書くのは、途中で崩れるからです。 道具が返した利息を見て、エージェントは「年に直すと」と換算を書き足すことがあります。換算も計算です。

「欠けた日を補わない」を明記しないと、前日の値で埋めます。 金融機関の計算でも休日の扱いの決まりがあり、それは台帳の計算の決まりに書かれているはずです。エージェントが独自に補うと、台帳の決まりと違う埋め方になります。

出力形式を固定する

Tools Agent の「Require Specific Output Format」を有効にし、Structured Output Parser をつなぎます。 次の形のJSONで受け取ります。

{
  "loan_id": "",
  "lender": "",
  "index": "TIBOR_3M | TONA_COMPOUND | LONG_PRIME | SHORT_PRIME",
  "status": "ok | missing_terms | missing_rates | fixed",
  "fixing_date": "",
  "rates_used": [ { "index": "", "date": "", "value": 0, "source": "" } ],
  "projected_rate": 0,
  "projected_interest": 0,
  "next_payment_date": "",
  "budget_rate": 0,
  "budget_interest": 0,
  "diff_interest": 0,
  "past_error": 0,
  "missing_items": [],
  "notes": []
}

1つ目の理由は、rates_used で根拠を確かめられることです。 使った指標の値と日付と出所が並ぶので、担当者はどの日の値で計算したかを一目で確かめられます。TIBOR の出所に「情報提供会社の画面」と出ていなければ、入力の経路を確かめます。

2つ目は、status で計算できなかった借入が一覧に出ることです。 missing_terms と missing_rates が残っている借入は、見込みの合計に入れずに別に並べます。 合計の中に推測の数字が混ざりません。

3つ目は、diff_interest をワークフローの側で検算できることです。 projected_interest と budget_interest の差が diff_interest と合わなければ、エージェントが数字を書き換えたということなので、その行は差し戻します。途中の手順は Tools Agent の Return Intermediate Steps で受け取り、計算の道具の戻り値と出力の値が同じかも確かめます。

システムへ連携する

計算のサブワークフローは、公開しておきます。 n8n の公式の説明では、Database から選んだサブワークフローは本番で動かすときに公開されている必要があり、公開されていないと「Workflow is not active」というエラーが道具の結果としてエージェントに返り、見落としやすいとされています。毎朝の一覧で、道具の呼び出しに失敗した借入を数えて出します。

台帳へは書き込みません。 確定した金利を入れるのは担当者で、見込みの値が確定値の欄に入る経路をつくりません。

人が確認する

財務の担当が見るのは、毎朝の通知と週次の一覧です。

1. 「要確認」を最初に見る … missing_terms は台帳の決まりを契約書で確かめて埋め、missing_rates は取得の失敗か休日の扱いかを確かめます
2. 「確定前」を見る … 確定日が近い借入の見込みを見て、使った値の日付が確定日の決まりに合っているかを確かめます
3. 「予算超過」を見る … 差が出た理由が指標の動きか、元本の変化かを見て、上司に伝えます
4. 確定値を入れる … 金融機関から金利の通知が届いたら、台帳に確定値を入れます。見込みとの差が記録され、次の past_error になります

2番目は、TONA の後決め複利で特に大事です。 ルックバックの日数や観測期間のずらし方を台帳と取り違えると、数日分ずれた値で複利が計算され、それらしい見込みが出ます。 rates_used の最初と最後の日付を、台帳の決まりと見比べます。

目標は、30本をならして1本10分です。 確定前と予算超過の借入は丁寧に見て、それ以外は週次の一覧を流し見ます。

例外に対処する

最後の行が、この構成を育てる場面です。 確定値との差が続けて出る借入は、台帳の決まりの書き方か、計算の道具の式のどちらかが契約と違います。

記録を残す

• 取った指標の値と日付、取った時刻と出所（API／推移のページ／担当者の入力と画面の名前）
• 借入ごとのエージェントの入力、呼んだ道具とその結果、出力のJSON
• そのとき使った台帳の版と、計算の道具の版
• 金融機関の通知で確定した金利と、見込みとの差
• 担当者が直した台帳の決まりと、直した理由

3つ目の「計算の道具の版」を残すのは、式を直したときに過去の見込みを説明するためです。 式を直す前と後で見込みが変わったとき、どちらの式で出した数字が会議の資料に載ったかを確かめられます。