月次の業績報告に各部門が書くコメントを、表記と数値の言い方の決まりに沿って校正し、数値表と食い違う箇所を洗い出す

処理の起点を決める

経営企画の担当がスクリプトを実行したときに動かします。 部門の提出は締めの日の夕方に集中しますが、提出のたびに自動で動かすと、部門が直して出し直すたびに一覧が増え、どれが最新か分からなくなります。 第3営業日の正午と夕方の2回、担当が実行する運用にします。

実行すると、提出用のフォルダにある様式のうち、前回の実行から更新されたものだけを読みます。ファイルの更新日時と、前回の実行の記録を比べて決めます。出し直した部門は、その部門の一覧だけが作り直されます。

締めの日を過ぎても出ていない部門は、一覧の先頭に「未提出」として並べます。校正の仕組みが、提出の督促の一覧も兼ねます。

入力データを集める

質を決めるのは、いちばん下の2つです。 表記の決まりに正しい例と誤った例が無いと、AIは決まりの文だけから判断し、直す箇所の挙げ方が月ごとに揺れます。 指標の呼び名の一覧が無いと、「出荷高」と書かれた数値をどの指標と照合すればよいか決まりません。

表記の決まりは、たとえば次のような形で持ちます。

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

様式と数値表は、Python で表計算のファイルを直接読みます。 様式はセルの位置が決まっているので、部門名・対象の月・6つの欄を位置で取ります。欄の位置を書き手が動かしていないかは、見出しのセルの文字で確かめます。 見出しが違えば、その様式は読まずに「様式の崩れ」として一覧に出します。

数値表は、部門ごとに「指標 × 比べる相手」の値を辞書の形に組み直します。

比率は数値表の計算済みの列を使い、スクリプトで計算し直しません。 計算し直すと、端数の扱いが数値表と1桁ずれ、正しいコメントを食い違いとして挙げてしまいます。

AIへ渡す前に整形する

1. 様式の確認 … 見出しのセルの文字が決まりどおりかを見ます。違えば読まずに一覧に出します
2. 対象の月の確認 … 様式の月が今回の締めの月と一致するかを見ます。先月のファイルの出し直しを今月として読まないためです
3. 空の欄の扱い … 欄が空なら AI に渡さず、「未記入」として一覧に出します
4. 数値の表記の正規化（照合用の写しだけ） … 全角数字を半角に、「千」「万」「億」の混じった金額を百万円に換算した値を、照合用に別に持ちます。本文そのものは変えません
5. 数値表の行の特定 … 部門名で数値表の行を引きます。引けなければ「数値表に行が無い」として一覧に出します
6. 呼び名の付け合わせ … 指標の呼び名の一覧を、プロンプトに入れる形にします

4番目で本文を変えないのが大事です。 本文を正規化してから AI に渡すと、「12億3,450万円」と書かれていたという事実が消え、R-03 の直しが挙がらなくなります。

AIに処理させる

させるのは、2つの作業です。 1つ目は、欄の文の中で表記の決まりに当たる箇所を挙げ、決まりの番号と直し方の候補を付けること。2つ目は、文中の数値を部品に分けて書き出すことです。

2行目がいちばん起きやすい失敗です。 「前年比8％増」と書かれていると、AIはたいてい前年同月比と読んで部品を埋めます。そうすると R-01 の直しが挙がらず、照合も前年同月比の列で行われ、本当は前月比の8％だった場合に食い違いが見えなくなります。 書かれていないものは not_stated と書かせ、照合のスクリプトの側で「比べる相手が書かれていない」として扱います。

部門への確認は、直しとは別の欄に出させます。 「増益」と書いてあるのに数値表の営業利益が減っている、というような文は、表記の直しではなく、部門の書き間違いか数値表の誤りかのどちらかです。 どちらかはAIにも経営企画にもすぐには分からないので、問い合わせとして扱います。

指示内容を固定する

あなたは製造業の経営企画部で、各部門が書いた月次の業績コメントを
社内の表記の決まりに照らして点検する担当です。
渡された1つの欄の文だけを見てください。数値表は渡しません。

【やること】
1. 表記の決まりに当たる箇所を、文の中からすべて挙げてください。
   - quote には、当たる文字列を本文からそのまま写してください。
   - rule_id には決まりの番号を入れてください。迷うときは unknown。
   - suggestion には、決まりに合わせた直し方を1つ書いてください。
     直すのは決まりに当たる部分だけです。前後の文を書き換えないでください。
2. 文中の数値をすべて、部品に分けて書き出してください。
   - metric は【指標の呼び名の一覧】の正式名に置き換えてください。
     一覧に無い指標は、本文の呼び方のまま入れ、metric_known を false に。
   - basis は 前年同月比／前月比／予算比／実績値／not_stated のどれか。
     「前年比」とだけ書かれていても、前年同月比と決めつけないでください。
     本文に書かれた比べる相手がそのまま決まらないときは not_stated です。
   - value は本文に書かれた数字をそのまま文字列で入れてください。
     換算、四捨五入、計算をしないでください。
   - direction は 増／減／記載なし のどれか。
3. 部門に確認したほうがよい文を挙げてください。
   - 「増収」「増益」「改善」「悪化」などの言葉と、数値の増減の向きが
     本文の中で食い違っているもの。
   - 主語や指標が分からず、何の話か読み取れないもの。

【してはいけないこと】
- 数値が正しいかどうかを判断しないでください。数値表は見ていません。
- 増減の理由が正しいか、妥当かを書かないでください。
- 「一過性」「構造的」「一時的」などの部門の判断の言葉を言い換えないでください。
- 欄の全文を書き直した文章を出さないでください。
- 決まりに当たらない言い回しの好みを挙げないでください。

【表記の決まり】{rules}
【指標の呼び名の一覧】{metric_names}
【部門名】{department}　【欄】{section}
【本文】{text}

「数値表は見ていません」と最初と禁止の両方に書くのは、AIが照合の結果のような書き方をしやすいからです。 何も言わないと「この数値は妥当です」のような一文を suggestion に入れてきます。AIの出力に照合の結論が混ざると、プログラムの照合結果と並んだときに、どちらを信じるかで迷いが生まれます。

「前年同月比と決めつけない」を指示に名指しで書くのも同じ理由です。 製造業の月次では前年同月比がいちばん多く使われるので、AIはそちらに寄せて埋めます。埋めたこと自体が、直すべき箇所を消します。

出力形式を固定する

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

{
  "department": "第二事業部",
  "section": "利益",
  "findings": [
    { "quote": "前年比8％増", "rule_id": "R-01",
      "suggestion": "前年同月比8.0％増（比べる相手を要確認）" }
  ],
  "numbers": [
    { "quote": "前年比8％増", "metric": "営業利益", "metric_known": true,
      "basis": "not_stated", "value": "8", "unit": "％", "direction": "増" }
  ],
  "questions": [
    { "quote": "増益を確保した", "reason": "同じ欄で営業利益の減少を述べている" }
  ]
}

1つ目の理由は、照合のスクリプトが numbers を項目名で読めることです。 スクリプトは metric と basis で数値表の値を引き、value と比べます。比べ方は規則で決まっています。

basis_unknown で3つすべてと比べるのは、書き手が何と比べたつもりかを経営企画が推し量れるようにするためです。 8％が前年同月比の7.8％にも前月比の12.1％にも合わなければ、比べる相手の問題ではなく数値の誤りです。

2つ目の理由は、構造化出力のスキーマの制約に合わせて形を決められることです。 公式のページでは、構造化出力ではすべての項目を必須にし、オブジェクトには additionalProperties: false を置く必要があり、任意の項目は null との組み合わせで表すとされています。また、文字列の pattern・maxLength、配列の minItems・maxItems などのキーワードはサポートされないとされています。findings が0件の欄も空の配列で返るので、件数の下限をスキーマで縛る必要がありません。 値の形の確かめ（basis が決まった値か）は、enum で縛り、スクリプトでもう一度見ます。

3つ目は、quote で本文の位置に戻れることです。 スクリプトは quote が本文にそのまま含まれるかを確かめ、含まれないものは「本文に無い引用」として一覧から外し、別に記録します。 言い換えて写した quote を通すと、直す場所が分からなくなります。

システムへ連携する

様式にも数値表にも書き込みません。 校正の一覧を別のファイルに出し、直しを採るかどうかは人が様式の側で反映します。 スクリプトが様式を直接書き換えると、部門が出したものと資料に載ったものの差が後から追えなくなります。

校正の一覧は、部門ごとに次の3つの表を並べます。

人が確認する

人が見るのは、一覧の3つの表です。 欄の本文を頭から読み直すのは、mismatch か「部門への確認」がある欄だけにします。

1. 数値の照合の mismatch と basis_unknown を先に見る … 数値表を開き、本当に合わないかを確かめます。数値表の側の誤りであることもあります
2. 部門への確認を見る … 問い合わせるか、経営企画で判断できるかを決めます
3. 直す箇所を見る … 直し方の候補を採るかを決めます。採るのは決まりに当たる部分の直しだけです
4. 採らなかった直しに理由を付ける … 決まりの側を変えるべきかを、翌月に見直す材料にします

1番目で数値表の誤りを疑うのを省かないでください。 部門は自部門の実績をよく知っており、コメントの数値のほうが正しいことがあります。数値表を直したら、それを使う全部門のコメントを照合し直します。

目標は、120欄をならして1欄5分です。 直しの候補が無く数値がすべて match の欄は一覧で流して数十秒、mismatch や部門への確認がある欄は数値表を開いて十数分かかります。

例外に対処する

6行目は製造業の月次で起こりえます。 公式のページでは、プロンプトと応答は有害な内容の種類について即時に評価され、設定したしきい値に従って生成が絞り込まれるとされています。安全・環境の欄に労働災害の経緯を書く部門があるなら、止まった欄を自動でやり直さず、人に回します。

記録を残す

• 実行した日時と、読んだ様式のファイル名・更新日時
• 欄ごとの AI の応答の全文（findings、numbers、questions）
• 照合に使った数値表のファイル名と、そのときの値
• 照合の結果（match ／ rounding ／ mismatch ／ basis_unknown ／ metric_unknown）
• 人が直しを採ったか、採らなかったかと、採らなかった理由
• 部門に問い合わせた内容と、部門の回答
• 決まりの番号ごとの、月ごとの件数

3つ目で「そのときの数値表の値」を残すのは、締めの後に数値表が直ることがあるためです。 照合の結果だけが残っていると、mismatch がコメントの誤りだったのか、直す前の数値表の誤りだったのか、後から分かりません。

最後の行は、決まりの浸透を測る材料です。 R-01 の件数が毎月同じ部門で出るなら、その部門の書き手に決まりを説明し直します。件数が減らない決まりは、決まり自体が分かりにくい可能性もあります。