子会社から毎月届く連結パッケージの増減コメントを前月・前年同月の数値と照らして点検し、説明不足と数字の合わない説明を拾って照会文の案を作る

処理の起点を決める

子会社がパッケージを受付ライブラリに提出したことを起点にします。 「ファイルの作成時 (プロパティのみ)」のトリガーは、ライブラリに項目が作成されたときに動き、ライブラリの列のプロパティだけを返します。中身は、返ってきたファイル識別子で「ファイル コンテンツの取得」を呼んで取ります。

提出期限の後にまとめて動かすことはしません。 40社のうち早い会社は2営業日目に出してきます。届いた順に点検しておけば、照会も届いた順に出せ、回答を待つ時間が締めの日程に重なりません。

同じ会社が出し直したときは、新しい版だけを点検します。 ファイル名に会社コードと対象月を入れる決まりにし、同じ会社・同じ月の点検の一覧が既にあれば、前の版の判定に「差し替え」の印を付けてから点検し直します。

入力データを集める

質を決めるのは、科目の関連表です。 第1章の「ほかの科目の動きと矛盾している」は、どの科目とどの科目を並べて読むかが決まっていないと判定できません。 全科目を全科目と並べると、AIは関係の薄い動きまで矛盾として挙げます。関連表にある組だけを渡します。

前月のコメントは、文面が同じかどうかを見るために持ちます。 増減の金額が変わっているのに前月と一字一句同じコメントは、書き直していない可能性が高いので、それだけで照会の候補にします。

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

前月のコメントは、その会社の分だけを引きます。 「アイテムを取得」は OData のフィルター クエリで返す項目を絞れるので、会社コードと前月の対象月で絞ってから読みます。全社分を引いてフローの中で探すと、件数が増えたときに取りこぼします。

パッケージの書式は全社で1つにそろえておきます。 子会社ごとに列の位置が違うと、読み出しの段で科目と値がずれます。ずれたまま増減を計算すると、存在しない大きな増減が出ます。

AIへ渡す前に整形する

1. 書式の確認 … 決められた列見出しがそろっているか、科目コードがマスタにあるかを確かめます。そろわなければ止めて、子会社に出し直しを頼みます
2. 増減の計算 … 科目ごとに、前月比と前年同月比の金額と率を計算します。計算はすべてフローで行い、機能通貨のまま扱います
3. 基準との比較 … 会社の規模の区分に応じた基準で、コメントの要る科目に印を付けます
4. コメントの有無の確認 … 印の付いた科目にコメントが無ければ、AIに渡さずに「コメントなし」とします
5. 前月と同じ文面の確認 … 前月のコメントと文字列で比べ、一致すれば印を付けます
6. 関連する科目の値を添える … 関連表にある組の、相手の科目の増減の金額と率を並べます
7. AIに渡す単位を作る … 1社につき、印の付いた科目だけを、計算済みの値と関連する科目の値と一緒に1つにまとめます

4番目でコメントの無い科目をAIに渡さないのは、判定の余地が無いからです。 渡すと、AIは表の動きから理由を推測し、「コメントは無いが、売上の増加によると考えられる」と書きます。 子会社が書いていない説明を、本社が作ってしまうことになります。

2番目で通貨を換算しないのは、比べる相手が同じ通貨だからです。 前月も前年同月も機能通貨の値で持っています。円に換算すると為替の動きが増減に混ざり、子会社のコメントが説明していない差が出ます。

5番目は、文字列が完全に一致したときだけ印を付けます。 数字だけを書き換えたコメントは別の文面として扱い、AIの判定に回します。似ているかどうかの判断までフローでやろうとすると、基準があいまいになります。

7番目でまとめる1科目分は、次のような形です。AIが見る値は、すべてフローが計算したものです。

科目: 1310 売掛金（機能通貨: USD、単位: 千）
当月 18,420 ／ 前月 16,950 ／ 前年同月 15,880
前月比 +1,470（+8.7%） 基準超過 ／ 前年同月比 +2,540（+16.0%） 基準超過
関連科目: 4110 売上高 前月比 -320（-3.1%） ／ 前年同月比 +610（+6.5%）
コメント: Increase due to higher sales to Customer B in September.
前月と同じ文面: いいえ

この例では、売掛金の増加を売上の増加で説明していますが、売上高は前月比で減っています。AIはこの1行の並びを見て contradicts を選び、related_account に 4110 を入れます。

AIに処理させる

させるのは、コメントごとに「増減の説明になっているか」を4つの区分で判定し、コメントに書かれた数字を抜き出し、照会の要るものに照会文の案を書くことです。

数字は判定させずに、抜き出させるだけにします。 コメントの中の「120 百万円」「前年同月比 15％」を、どの比較（前月比／前年同月比）のどの値として書かれているかと一緒に抜き出させ、表の値と照らすのはフローが行います。

指示内容を固定する

あなたは本社の連結決算の担当として、子会社が書いた科目ごとの増減コメントを点検します。
渡された値とコメントだけを見て判定してください。

【判定すること】
科目ごとに、コメントが増減の説明になっているかを、次の4つから1つ選んでください。
- explained ...... 増減の向きと主な理由が書かれ、増減の金額の大部分を説明している
- partial ........ 理由は書かれているが、増減の一部しか説明していない
- not_explained .. 増減の理由になっていない（「増加」「通常の変動」「特になし」など）
- contradicts .... 関連する科目の増減と矛盾している
迷ったときに explained を選ばないでください。

【厳守事項】
- 増減の金額と率は、渡された値（計算済み）を使ってください。自分で計算しないでください。
- コメントに書かれた数字は、numbers に、書かれたままの文字列と、
  どの比較（mom＝前月比／yoy＝前年同月比／unknown）の値として書かれているかを入れてください。
  数字が合っているかは判断しないでください。
- 通貨を換算しないでください。値はすべて機能通貨です。
- contradicts を選ぶときは、どの関連科目の、どの動きと矛盾するかを reason に書いてください。
  関連科目として渡されていない科目を理由にしないでください。
- コメントに書かれていない理由を推測で補わないでください。
- 判定が explained 以外のときは、照会文の案を書いてください。
  照会文は、コメントの言語（{language}）で書き、
  何が足りないかを具体的に1〜2文で尋ねてください。子会社を責める表現にしないでください。
- 子会社の数値が正しいか、連結修正が要るかは書かないでください。

【会社の情報】{company}
【点検する科目（計算済みの増減と、関連する科目の増減付き）】{lines}

「迷ったときに explained を選ばない」と書くのは、短いコメントでも理由らしい語があれば通してしまうからです。 「需要増による」は理由の形をしていますが、どの製品のどの需要かが無ければ partial か not_explained です。 第3章の（b）で担当者ごとに分かれていた線を、ここで1本にします。

照会文を「責める表現にしない」と書くのは、子会社との関係のためです。 照会は毎月何十件も出ます。詰問の調子が続くと、子会社はコメントを短くして照会を避けるようになります。

出力形式を固定する

次の形のJSONで受け取ります。 Azure OpenAI の構造化出力を使い、JSON Schema に沿った形で返させます。

{
  "company_code": "",
  "period": "2026-09",
  "lines": [
    {
      "account_code": "",
      "verdict": "explained | partial | not_explained | contradicts",
      "reason": "",
      "related_account": null,
      "numbers": [
        { "text": "120百万円", "basis": "mom | yoy | unknown" }
      ],
      "inquiry_draft": null
    }
  ]
}

1つ目の理由は、verdict と basis を enum で縛れることです。 構造化出力は enum に対応しているので、判定が5つ目の区分に増えることも、比較の種類が自由な文になることもありません。 一覧で区分ごとに数えられます。

2つ目は、照会文と関連科目を「無いときは null」で表せることです。 構造化出力ではすべての項目を必須にする決まりがあり、任意の項目は null との組み合わせの型で表します。explained の科目は inquiry_draft が null で返り、照会文を書き忘れたのか、要らないのかが区別できます。

3つ目は、numbers を照合に回せることです。 フローは basis が mom なら前月比の値、yoy なら前年同月比の値と照らし、単位をそろえたうえで一致しなければ number_mismatch の印を付けます。 unknown は照合せず、照会の候補にします。

最終的な照会の要否は、フローが次の規則で決めます。

システムへ連携する

照会の下書きは、会社ごとに1通にまとめます。 科目ごとに1通ずつ置くと、子会社の経理担当に1日で十数通が届きます。宛先は会社の情報のリストにある照会先から入れ、本文には照会の要る科目を表にして並べます。

下書きのまま置き、送信のアクションは使いません。 Outlook のコネクタには送信のアクションもありますが、照会の文面を連結担当が確かめずに送ると、判定の誤りがそのまま子会社に届きます。

人が確認する

連結担当が見るのは、照会が「要」になった科目と、その照会の下書きだけです。 照会が「不要」の科目は、一覧で件数を見るだけにします。

1. contradicts を先に見る … 関連する科目の動きと並べて、本当に矛盾しているかを確かめます。子会社側の説明が正しく、関連表の組み方が粗いこともあります
2. number_mismatch を見る … 単位（百万円／千円）や、前月比と前年同月比の取り違えがほとんどです
3. partial と not_explained の照会文を直す … 子会社の事情を知っていて照会が要らないと判断したものは、理由を書いて外します
4. 下書きを送る … 会社ごとの1通を開き、宛先と本文を確かめて送ります
5. 判定を覆したら記録する … どの判定を、どちらに変えたかを残します

3番目で「照会が要らない」と外すときに理由を書かせるのは、基準をそろえるためです。 外した理由がたまると、「この会社のこの科目は季節で動く」のような事情が見えてきます。 それは関連表か基準の側に戻します。

目標は、40社をならして1社30分です。 照会の要る科目が1社あたり数件という想定で、それより多い会社が続くなら、基準が厳しすぎるか、その会社のコメントの書き方を直してもらう時期です。

例外に対処する

上から4行目までは、AIを呼ぶ前に止めます。 どれも、計算や比較の前提が崩れている状態です。前提が崩れたまま判定させると、AIはもっともらしい区分を返し、誤りが一覧に紛れます。

記録を残す

• 提出されたパッケージの版と、受け付けた日時
• フローが計算した増減の金額と率、基準と比べた結果
• Azure OpenAI に渡した指示と、返ってきたJSONの全文
• 数字の照合の結果
• 連結担当が判定を覆した記録と、照会を外した理由
• 送った照会の文面と、子会社の回答
• 会社ごとの照会の件数の推移

5つ目が、基準と関連表を直す材料になります。 同じ会社の同じ科目で照会を外し続けているなら、その科目の基準か関連表の組が実態に合っていません。 四半期に一度、外した理由を見直します。

最後の行は、子会社の経理との話し合いに使います。 照会の件数が減っていく会社は、コメントの書き方がそろってきた会社です。