提案書や報告書の数字と社名を、元データと突き合わせて公開前に確認する

処理の起点を決める

公開前チェックの依頼が出されたことを起点にします。

最小構成では、確認担当が依頼を受けたときに手で資料を貼ります。半自動化では、Googleフォームの送信をきっかけに Apps Script が動きます。Apps Script のインストール可能なトリガーには「フォーム送信時」があり、回答が入るたびに関数を実行できます。

依頼の締め切りを運用で決めてください。 「公開の3営業日前まで」といった決めがないと、確認の時間がなくなり、この構成があっても間に合いません。これは技術で解決できない部分です。

入力データを集める

数値台帳の作り方が、この構成の成否を決めます。 1行に1つの数値を持ち、次の列を必ず入れてください。

「定義」と「基準日」と「丸め方」の3列が要です。 これがないと、「1,240社」と「1,200社以上」のどちらも正しいのか、それとも食い違いなのかが判定できません。

台帳に載せる数値は、社外資料に実際に出てくるものだけで足ります。50〜100行から始められます。

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

資料からのテキスト抽出： 形式ごとに扱いが違います。

PowerPoint と画像がこの業務の弱点です。 数値はグラフの中に入っていることが多く、テキスト抽出では拾えません。対策は2つあります。 ひとつは、確認依頼のときにグラフの元データも添付してもらうこと。もうひとつは、画像として読ませられる生成AIに、スライドを画像で渡すことです。前者のほうが確実で、かつ元データの所在がはっきりします。

台帳類： スプレッドシートから読み込みます。最小構成では、台帳をそのままプロジェクトのナレッジに置きます。

AIへ渡す前に整形する

1. 数値の拾い出し … 資料中のすべての数値を位置（ページ・スライド番号）つきで拾います。日付、ページ番号、価格表の金額など、照合の対象外にするものを除きます
2. 表記の正規化 … 「1,200」「1200」「1.2千」「千二百」をそろえます。「％」「パーセント」「割」も同様です
3. 固有名詞の拾い出し … 社名、製品名、人名、肩書きを抜き出します
4. 引用の識別 … 「◯◯調査によると」「出典：」に続く記述を、外部統計の引用として識別します
5. 同月資料の読み込み … 公開カレンダーから、同じ月に出る他の資料の数値を用意します

AIに処理させる

AIに正しい数値を調べさせないでください。 これがこの構成の一番重要な設計方針です。

「導入社数は現在何社ですか」と生成AIに聞けば、それらしい数字が返ります。その数字に根拠はありません。 この構成でAIがするのは、「資料に書かれた数値」と「台帳の数値」を比べることだけです。台帳にない数値は、正しいとも間違いとも言わず、「台帳に対応する指標がない」として挙げます。

同じ理由で、Web検索をさせて外部統計の正しさを確かめることもしません。 外部統計については、「出典と年次が書かれているか」だけを見ます。中身の正しさは、引用元を人が見て確かめるものです。

指示内容を固定する

あなたは、社外に出す資料の公開前チェックを支援する担当者です。
資料に書かれた数値と固有名詞を、社内の台帳と突き合わせて指摘してください。

【厳守事項】
- あなたが数値を調べたり、思い出したりしないでください。
  判定に使ってよいのは、下記の台帳の値だけです。
- 台帳に対応する指標がない数値は、正誤を判定しないでください。
  status を "not_in_ledger" とし、「この数値の出どころを作成者に確認してください」
  と指摘してください。「おそらく正しい」と書かないでください。
- 台帳の値と一致しない場合は、台帳の「定義」と「基準日」を必ず添えてください。
  定義が違うために数値が違う可能性があるためです。
- 台帳の「丸め方」の指定に従っているかを見てください。
  値が正しくても、丸め方が指定と違う場合は指摘してください。
- 顧客名については、事例掲載の同意有無と、掲載可能な表現を確認してください。
  同意がない顧客名が出ている場合は severity を high にしてください。
- 外部統計の引用については、出典と年次が書かれているかだけを見てください。
  統計の中身が正しいかを判定しないでください。
- 指摘には、資料のどこ（ページ／スライド番号、前後の文）かを必ず書いてください。
- 修正案は、台帳の値をそのまま当てはめた形で書いてください。
  表現を書き換える提案はしないでください。

【数値台帳】
{number_ledger}

【顧客表記台帳】
{customer_ledger}

【製品名・用語台帳】
{product_ledger}

【引用してよい外部統計の一覧】
{external_stats}

【同じ月に公開予定の他の資料に載る数値】
{same_month_figures}

【確認対象の資料】
種別: {doc_type} / 公開予定日: {publish_date}
{document_text}

「あなたが数値を調べたり、思い出したりしないでください」の1行が、この構成の安全装置です。 これを書かないと、AIは台帳にない数値についても「一般的には妥当な範囲です」と書きます。それを読んだ確認担当が安心してしまうことが、もっとも危険な失敗です。

「表現を書き換える提案はしない」も入れてください。 文章の良し悪しは別の作業です。ここで表現の提案まで混ざると、指摘の一覧が長くなり、肝心の数値の指摘が埋もれます。

出力形式を固定する

{
  "document_id": "",
  "checked_at": "",
  "findings": [
    {
      "type": "number | company_name | product_name | citation | cross_document",
      "location": "",
      "quoted_text": "",
      "extracted_value": "",
      "ledger_value": "",
      "ledger_definition": "",
      "ledger_as_of": "",
      "status": "matched | mismatched | not_in_ledger | rounding_violation | consent_missing | citation_incomplete",
      "severity": "high | medium | low",
      "comment": "",
      "suggested_fix": ""
    }
  ],
  "summary": {
    "numbers_found": 0,
    "numbers_matched": 0,
    "numbers_not_in_ledger": 0,
    "high_severity_count": 0
  },
  "extraction_warnings": []
}

quoted_text（資料に書かれていた文）と location を必ず残します。これがないと、確認担当が該当箇所を探す手間が発生し、削減効果が消えます。

ledger_definition と ledger_as_of を指摘に添えるのは、「値が違う」のか「定義が違う」のかを、確認担当がその場で判断できるようにするためです。「1,240社（有償契約・9月1日時点）」と添えられていれば、資料の「1,180社」が7月時点の数字だと気づけます。

extraction_warnings には、PowerPointの図中テキストが取れなかった可能性などを入れます。

なお、Claude API には出力をJSONスキーマに沿わせる構造化出力の機能があります（2026-09-14時点ではベータ機能として提供）。半自動化の段階で利用できると、指摘の一覧を機械的に処理しやすくなります。

システムへ連携する

最小構成では連携はありません。指摘の一覧をそのままコメントとして作成者に返します。

半自動化では、次をつなぎます。

指摘をそのまま作成者に自動送信しないでください。 not_in_ledger の指摘は、確認担当が「これは台帳に足すべき数値」なのか「この数値は資料から削るべき」なのかを判断してから返します。自動送信すると、作成者が「台帳にないだけで正しい」と自己判断して押し戻し、確認の意味がなくなります。

人が確認する

全件、確認担当が指摘を見たうえで作成者に返します。 自動化するのは指摘の作成までです。

見る優先順位は次のとおりです。

not_in_ledger が多いことを失敗と考えないでください。 最初は指摘の半分以上がこれになります。それは「社内の数値が台帳に整理されていない」という実態を写しているだけで、1件ずつ台帳に足していけば減ります。この減り方が、この構成の進捗そのものです。

例外に対処する

記録を残す

• 確認対象の資料（版ごと）
• 指摘の一覧と、確認担当の判断
• 作成者の対応（修正した／しない理由）
• not_in_ledger として挙がった数値と、その後の扱い（台帳に追加した／削除した）
• 台帳の変更履歴（値・定義・基準日）

4つ目が資産になります。 「この指標は毎回台帳にないと言われる」が見えれば、台帳に足すべき項目が分かります。 台帳が厚くなるほど、確認は速くなります。

台帳の変更履歴も必ず残してください。 過去に公開した資料の数値が正しかったかを、後から確認する必要が生じることがあります。