開示書類の数値と記載を、公表前に決算数値と前期の書類へ突き合わせて点検する

処理の起点を決める

担当者が点検を依頼したときを起点にします。

自動で走らせないでください。 書類は作成の途中で何度も保存されます。書きかけの状態で点検が走ると、大量の「食い違い」が出て意味がありません。

依頼の単位は、書類のセクションにしてください。「決算短信の1〜2ページ」「説明資料の業績サマリー」といった単位です。 書類全体を一度に点検すると、指摘が数百件になります。

2つ目の起点として、確定値が変わったときがあります。 監査の過程で数値が修正されたら、その数値が出てくる箇所をすべて一覧にします。 ここは自動で構いません。

この機能が、決算期の負担をいちばん減らします。 「売上高が10百万円動いた」と分かったとき、直すべき箇所が12か所あると即座に示せます。

3つ目の起点として、公表の直前があります。 最終版について、確定値との突合をもう一度通します。修正の過程で新たな食い違いが生まれていないかの確認です。

入力データを集める

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

項目名の対応表が、この構成の質を決めます。 会計システムの「売上高」が、書類では「売上収益」「連結売上高」「Net sales」と書かれます。次の形で持ってください。

「注意点」の列がいちばん効きます。 同じ数値でも、書類によって単位が違うことがあります。「1,234百万円」と「12.3億円」は同じ値ですが、単純な文字列の比較では食い違いになります。

「出てくる書類」の列も必須です。 これがあると、数値が変わったときの影響箇所を機械的に出せます。この列を埋める作業が、この構成でいちばん時間がかかります。

表示の規則： 端数処理と単位の扱いを明文化してください。

「更新が必要な語の一覧」も整理してください。

この一覧は、過去の訂正や指摘から作ってください。 実際に更新漏れが起きた語が、いちばん確実な材料です。

AIへ渡す前に整形する

1. 書類からのテキストと表の取り出し … Word・Excel・PowerPoint それぞれから、本文と表を取り出します
2. 箇所の特定 … 抜き出した数値が、何ページの何行目・どの表のどのセルかを保持します。これがないと修正できません
3. 単位の正規化 … 億円・百万円・千円を、内部では同じ単位にそろえます。表示上の値は原文のまま残します
4. 符号の正規化 … △・▲・マイナス記号を1つにそろえます
5. 確定値の読み込み … 会計システムの出力を、項目名の対応表で書類の呼び方へ紐づけます
6. 前期書類の読み込み … 同じセクションの前期の記載を対応づけます
7. 未公表情報の確認 … 対象の書類に未公表の決算情報が含まれることを前提に、送る範囲を決めます

2の箇所の特定が、この構成の使い勝手を決めます。 「売上高が違います」だけでは、担当者はどこを直せばよいか分かりません。「説明資料P8の表の2行目」と示せて初めて使えます。

3の単位の正規化で、表示上の値を残すことが重要です。 内部で百万円にそろえて比較し、指摘には原文の「12.3億円」を示します。 換算後の値で指摘すると、担当者が書類のどこかを探せません。

AIに処理させる

生成AIにさせること：

計算処理にさせること（生成AIには任せない）：

数値の比較を生成AIにさせないでください。 「1,234百万円と1,234百万円は一致します」という判定を生成AIにさせる理由がありません。桁の読み違いが起きる余地を作るだけです。

開示の内容も判断させません。 「この項目は開示が必要です」「この表現は投資家に誤解を与えます」といった記述を禁じてください。

会計基準への当てはめもさせません。 表示区分、注記の要否は会計基準と自社の方針で決まります。

業績の評価もさせません。 「営業利益が大きく減少しています」といった記述は不要です。照合の結果だけを返させてください。

指示内容を固定する

あなたは財務部で開示書類の点検を支援する担当者です。
書類から数値と記載を抜き出し、後段の突合に渡せる形にすることが役割です。

【厳守事項】
- 数値の比較や計算をしないでください。
  「一致しています」「差額は10百万円です」と書かないでください。
  突合と計算は後段のシステムで行います。
- 単位を換算しないでください。
  書類に「12.3億円」とあれば、そのまま「12.3」「億円」として返してください。
- 数値を書き換えないでください。桁区切り、符号（△・▲）も原文のまま返してください。
- 開示の要否を判断しないでください。
  「この項目は開示が必要です」と書かないでください。
- 会計基準への当てはめをしないでください。
  「この表示区分は不適切です」と書かないでください。
- 業績を評価しないでください。
  「営業利益が大きく減少しています」と書かないでください。
- 抜き出した数値には、必ず出てくる箇所（ページ・段落または表のセル）を付けてください。
  箇所を示せない数値は返さないでください。
- その数値が当期・前期・予想のどれかを、前後の文から判定してください。
  判定できない場合は「不明」としてください。推測で決めないでください。
- 項目名の同定は、下の「項目名の対応表」に照らして行ってください。
  対応表にない呼び方が出た場合は「対応なし」としてください。
  一般的な会計用語の知識で当てないでください。
- 前期からの流用の検出は、下の「更新が必要な語の一覧」に照らしてください。
  一覧にない語について、更新が必要かどうかを判断しないでください。
- 書類に書かれていない数値を補わないでください。

【点検の対象（書類名 / セクション）】
{document_section}

【書類のテキストと表（箇所の情報つき）】
{document_content}

【項目名の対応表（会計システムの項目名 / 書類での呼び方 / 単位 / 端数処理 / 注意点）】
{item_mapping}

【更新が必要な語の一覧（語 / 更新の内容）】
{period_terms}

【前期の同じセクションの記載】
{prior_period_text}

「数値の比較や計算をしない」の指示が、この構成でもっとも重要です。 開示書類の数値の誤りは、訂正の開示につながります。比較は決定的な処理であって、ぶれる余地を作ってはいけません。

「単位を換算しない」も同じ理由です。 億円と百万円の換算をさせると、桁を間違える可能性が残ります。換算は計算で行います。

「対応表にない呼び方は『対応なし』とする」の指示も外せません。 一般的な会計用語の知識で当てさせると、自社の書類では別の意味で使っている語を取り違えます。

「当期・前期・予想の判定」は、生成AIに向く作業です。 「前連結会計年度の売上高は」という文の直後の数値は前期のものです。この判定は文脈の理解が要るため、機械的な規則では難しくなります。 ただし判定できない場合は「不明」とさせ、人が確かめてください。

出力形式を固定する

Azure OpenAI で構造化した出力を得るには、Chat Completions API では response_format に、Responses API では text.format にスキーマを定義します。 strict: true を指定すると、供給したスキーマに沿った応答が返ります。

{
  "document": "",
  "section": "",
  "extracted_values": [
    {
      "raw_text": "",
      "value": "",
      "unit": "",
      "sign": "positive | negative",
      "item_name_in_document": "",
      "mapped_item": "",
      "period": "current | prior | forecast | unknown",
      "consolidated": "consolidated | parent | unknown",
      "location": { "page": 0, "kind": "paragraph | table", "detail": "" },
      "mapping_status": "mapped | unmapped"
    }
  ],
  "period_term_findings": [
    {
      "term": "",
      "found_text": "",
      "expected_update": "",
      "location": { "page": 0, "kind": "paragraph | table", "detail": "" }
    }
  ],
  "unreadable_areas": []
}

Azure OpenAI のスキーマには制約があります。 対応する型は String / Number / Boolean / Integer / Object / Array / Enum / anyOf で、ルートのオブジェクトを anyOf にはできません。 すべてのフィールドを required に含める必要があり、任意の項目は null との共用体（"type": ["string", "null"]）で表します。

additionalProperties: false を必ず設定してください。 これを設定しないと構造化出力が使えません。

スキーマの大きさにも上限があります。 オブジェクトのプロパティは合計100個まで、ネストは5階層までです。上のスキーマは収まりますが、項目を増やすときは確かめてください。

使えないキーワードがあります。 文字列の minLength / maxLength / pattern / format、数値の minimum / maximum / multipleOf、配列の minItems / maxItems / uniqueItems などです。値の範囲をスキーマで縛ることはできないため、受け取った後に確かめてください。

キーの順序は、渡したスキーマの順序に従います。 出力の順序を変えたい場合は、スキーマの順序を変えます。

raw_text と value を分けていることが、この構成の核です。 raw_text は「△1,234」、value は「1234」、sign は negative。指摘には raw_text を示し、比較には value を使います。

period と consolidated を持たせる理由があります。 同じ「売上高」でも、当期連結・前期連結・当期個別で値が違います。これを分けないと、突合が意味をなしません。

unreadable_areas は、図やグラフの中の数値です。 PowerPoint のグラフに埋め込まれた値は取り出せないことがあります。取り出せなかった箇所を明示して、人が見る対象にしてください。

システムへ連携する

点検結果を一覧として出すだけで、書類の自動修正は行いません。

書類を自動で直さないでください。 開示書類の修正は、責任の所在が明確でなければなりません。AIが直した箇所を人が見落とすと、誰も気づかないまま公表されます。

会計システムへの書き戻しもありません。 確定値は会計システムが正です。

確定値が変わったときの通知は、自動で構いません。 「営業利益が変更されました。影響する箇所は12か所です」という通知と、その一覧です。ここは判断が要らない機械的な処理です。

外部への送信は一切行いません。 未公表の決算情報を扱うため、メールでの自動送信のような経路を作らないでください。

人が確認する

担当者の確認は必ず残します。 指摘の種類ごとに確認の深さを分けます。

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

• 箇所（ページ・段落・セル）を明示する
• 書類の値と確定値を並べて表示する
• 同じ項目の指摘をまとめる
• raw_text をそのまま見せる（換算後の値では書類を探せない）
• 修正の完了をその場で記録できるようにする

最終の読み合わせは残してください。 この構成が減らすのは、全ページの読み合わせです。指摘のあった箇所と、図表の中の数値については、これまでどおり2名で確かめてください。

unreadable_areas は特に丁寧に見てください。 取り出せなかった箇所は、点検されていないのと同じです。グラフの数値、画像として貼られた表は、人が見るしかありません。

例外に対処する

「指摘が数百件出る」は、導入初期に必ず起きます。 対応表が未整備なうちは、unmapped が大量に出ます。セクション単位で始め、対応表を育てながら範囲を広げてください。

記録を残す

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

• 点検した書類とセクション、実施日時
• 抽出した数値と、その箇所
• 確定値との突合の結果
• 前期からの流用の指摘
• 担当者の確認と、修正の有無
• 確定値が変わったときの影響箇所と、修正の完了
• 公表前の最終確認の結果

「修正の完了」を必ず記録してください。 指摘に対して修正したかどうかが追えないと、修正漏れのまま公表することがあります。

「確定値が変わったときの影響箇所と修正の完了」は、特に重要です。 決算期の混乱の中で、直し漏れがいちばん起きやすい場面です。

この記録は、開示体制の証跡としての価値があります。 どういう手順で、何を点検し、誰が確認したかを示せます。ただし「AIが点検した」ではなく「対応表に照らして照合し、担当者が確認した」という形で残してください。

未公表の決算情報を扱うため、保管と閲覧の管理が要ります。 点検結果の一覧には、公表前の数値がそのまま入ります。閲覧を開示担当に限定してください。

保存期間は、開示書類の保存方針に合わせてください。 訂正が必要になった場合、点検の経緯が問われることがあります。