取引銀行へ毎月出す業況報告の資料を、会計データと受注状況から組む

処理の起点を決める

月次の締めが確定した時点を起点にします。 日付を固定した定時実行にはしません。締めが1日ずれた月に、確定していない数字で資料が組まれるからです。

締めの確定は、会計システム側の状態か、経理担当が押す「締め確定」のフラグで判定します。フラグを人が押す形でかまいません。 重要なのは、確定していないものを動かさないことです。

受注残と工事の進捗は会計の締めより早く固まるため、先に取っておいて締めの確定を待って結合します。取った時刻も記録し、資料に載る受注の数字がいつ時点のものかを言えるようにします。 締めのあとに振替伝票が入った月は、元データを作り直してから資料を組み直します。 第3章の（a）の事故は、資料だけを直すところから起きます。

入力データを集める

下の2つが、この構成の質を決めます。 前月の資料が残っていなければ第3章の（c）は直らず、様式定義表が無ければAIは様式を推測します。様式定義表は、次の形で持ちます。

この表を作る作業が、導入で最も時間のかかるところです。AIの有無にかかわらずやっておく価値があります。

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

抽出は Python で行います。APIがあれば呼び、無ければ定型のCSV出力を読み、どちらでも読み取り専用の接続にします。取り方の要は、元データを1つしか作らないことです。 銀行ごとに抽出を回すのではなく、4行に必要な項目をすべて含んだ元データを1回だけ作り、そこから切り出します。

識別子を4行に同じ値で埋め込んでおくと、あとから突合できます。 銀行から「先月いただいた数字と違うようだ」と言われたとき、その資料がどの元データから出たものかを引けます。

前月の資料は、保管先から対象月を指定して読み込みます。説明文の本文と、そのとき載せた数字の両方を読みます。 文章だけでは、続いているかを判定できません。

AIへ渡す前に整形する

1. 締めの確認 … 仮伝票が残っていないか、未承認の仕訳が無いかを確かめます
2. 3期のそろえ … 当月・前月・前年同月の科目が同じ体系で並んでいるかを確かめます。科目を追加した月はここで止まります
3. 変化の計算 … 科目ごとに増減額と増減率を出し、金額の閾値と率の閾値の両方を超えたものを変化として拾います
4. 大口の入出金の抽出 … 金額の上位と、閾値を超えた入出金を明細ごとに取り出します
5. 受注と失注の切り出し … 当月に確定した受注と失注を、相手先・金額・理由とともに取り出します
6. 工事の進捗の差分 … 進捗率の変動と、完成予定日が動いた工事を取り出します
7. 前月の説明文の読み込み … 「一時的」「一過性」「今月限り」といった言い回しを抽出し、どの科目について書かれたかを対応づけます
8. 材料の紐付け … 3番で拾った変化に、4番から6番の記録を候補として結び付けます
9. 様式定義表の検証 … 元データに無い項目名が定義に混ざっていないかを確かめます

3番の閾値を金額と率の両方にするのが、実務上の分かれ目です。 率だけで拾うと残高の小さい科目が毎月すべて引っかかり、金額だけで拾うと規模の小さい科目の大きな変動が落ちます。

7番と8番が、AIに渡す材料を作る工程です。 何も結び付かなかった変化が needs_fact の候補になります。先に機械で結び付けることで、AIは「材料を探す」仕事から外れます。

AIに処理させる

させるのは2つだけです。材料の付いた変化の説明文を下書きすることと、それを銀行ごとの様式へ振り分けることです。

させないことの2行目が、いちばん起きやすい失敗です。 「仕入高が前月比で増加」という事実だけを渡すと、AIは「受注増に伴う材料調達の前倒しによるもの」という、もっともらしい一文を返します。それが本当かを知っているのは、仕訳の摘要と受注の記録だけです。 材料が結び付いていなければ、書かせずに人へ回します。

指示内容を固定する

あなたは中小企業の経理部門で、取引銀行へ毎月出す業況報告の説明文を下書きする立場です。
渡された材料だけを根拠にしてください。

【あなたの仕事】
1. 変化の一覧の各項目について、説明文の下書きを1つずつ作る
2. 材料と変化が結び付かない項目に needs_fact を付ける
3. 下書きを様式定義に沿って項目へ振り分け、粒度と字数を合わせる
4. 見通しの項目に、渡された前提を言葉にして添える

【status の選び方】
- drafted ..... 材料の内容だけで説明文を作れた
- needs_fact .. 材料が無い、または変化の理由として結び付かない
迷ったときに drafted を選ばないでください。材料が弱ければ needs_fact です。

【厳守事項】
- 数字を書かないでください。増減額も増減率も残高も本文に入れず、「増加しました」
  という方向の記述までにとどめてください。数値は後段のプログラムが埋めます。
- 材料に無い理由を推測しないでください。「受注増に伴う」「季節要因により」といった、
  材料に根拠の無い言い回しを使わないでください。
- 材料が複数ある場合は金額の大きいものから順に並べ、主因を断定しないでください。
- prev_month が渡されている項目では、前月の記述と今月の動きの関係を1文で書いてください。
  前月「一時的」とされた項目が今月も同じ方向に動いていれば、その事実を必ず書いて
  ください。前月の文章を書き直さないでください。
- 見通しの項目では、渡された assumption をそのまま前提として書き添え、
  「確実です」などの断定をしないでください。
- 様式定義に無い項目を作らないでください。置き場が無い情報は unplaced に入れてください。
- 字数の上限を超える場合は金額の小さい材料から落とし、取引先名は材料のとおりに
  写してください。

【変化の一覧】{changes}
【材料】{evidence}
【前月に出した説明】{prev_month}
【見通しの数字と前提】{outlook}
【銀行ごとの様式定義】{bank_formats}

「数字を書かない」を先頭に置いているのは、ここが崩れると設計全体が崩れるからです。 文章の中に数値があると、元データを直したときに本文だけが古い数字のまま残ります。「主因を断定しない」も意図して入れています。 材料が3つあるとき、AIはいちばん語りやすいものを主因に選ぶからです。

出力形式を固定する

次の形のJSONで受け取ります。

{
  "period": "2026-08",
  "dataset_id": "",
  "changes": [
    {
      "change_id": "",
      "account": "",
      "direction": "increase | decrease",
      "status": "drafted | needs_fact",
      "draft": "",
      "evidence_used": [""],
      "carryover": "continued | resolved | none"
    }
  ],
  "bank_views": [
    {
      "bank_code": "",
      "fields": [
        { "field_name": "", "text": "", "source_change_ids": [""], "char_count": 0 }
      ],
      "unplaced": [""]
    }
  ],
  "outlook_notes": [
    { "item": "", "assumption": "", "text": "" }
  ]
}

数値の項目が char_count しか無いのが、この形の狙いです。 金額も率も残高もAIの出力には現れず、資料に入る数字はすべて dataset_id の指す元データから来ます。

changes と bank_views を分けているのは、説明を1回だけ作るためです。 同じ変化を4行ぶん書かせると4通りの言い方が生まれます。bank_views は changes を参照して粒度を合わせるだけにし、source_change_ids をたどれば4行が同じ下書きから出ていることを確かめられます。

人が先に見るのは、status が needs_fact のものと carryover が continued のものです。unplaced に値が出続ける項目は、定義表が銀行の求める形に追いついていないということです。

システムへ連携する

承認は Power Automate の「承認 - 開始して承認を待機」アクションで組めます。 公開情報では、このアクションを任意のフローに追加することで承認を管理でき、承認者は承認センターからでも電子メールの受信ボックスからでも要求に返信できるとされています。

承認要求の「詳細」フィールドは Markdown で書式を設定できます。 変化の一覧と needs_fact の件数を承認のメールに表として入れておけば、役員が資料を開かなくても、何を承認しようとしているかが分かります。

実行が30日を超えうる場合は、承認データを Microsoft Dataverse に保存し、要求を送るフローと「承認の作成」のアクションに基づいて応答で処理を実行するフローの2つに分ける構成が案内されています。 取り消しも同じアクションでサポートされ、取り消した要求は「履歴」タブで確認できます。

人が確認する

人が見るのは、needs_fact と carryover が continued のものが先です。 それ以外の下書きは、承認の画面で一覧として読みます。

1. needs_fact を調べる … 担当者が仕訳を見に行き、現場に聞きます。見つからなければ、その項目は説明を載せずに数字だけ出します
2. continued の書き方を決める … 前月「一時的」とした項目が続いているとき、今月どう書くかを決めます
3. 経理部長が全体を読む … 4行ぶんの文章が、同じ事実について同じことを言っているかを確かめます
4. 役員が承認する … 承認されていないものは送信されないようにフローを組みます

3番を省かないでください。 source_change_ids でたどれるのは同じ下書きから出ているかどうかまでで、粒度を合わせる過程で言い回しが変われば、同じ事実の説明が4行で違って読めることがあります。

目標は、4件をならして1件55分です。 needs_fact が2件から3件という想定で、その調査に時間の大半を使います。

例外に対処する

上から2行目が、この構成で最も守るべき点です。 資料だけを直すと元データと資料の数字が食い違い、識別子で突合しても一致しない状態になります。

記録を残す

• 元データ一式（識別子、作成時刻、抽出元と抽出時点）を月ごとに残す
• 変化の一覧と材料の紐付け（どの変化に、どの記録が結び付いたか）
• AIの出力のJSON全文（changes、bank_views、outlook_notes）
• 人が直した記録（どの下書きをどう直したか。needs_fact をどう解決したか）
• 承認の記録（承認者、承認した時刻、コメント、差し戻しの有無）
• 銀行へ出した資料そのもの（4行ぶん。識別子が埋め込まれた完成版）

目的は2つです。次月の照合と、銀行から聞かれたときの根拠です。 次月は前月の説明文と数字を読んで carryover を判定します。この記録が無いと、第3章の（c）は導入後も直りません。 「あのとき一時的と説明されたものはどうなったか」は数か月後に問われるので、当時の元データと紐付けまでさかのぼれるようにしておきます。