Media > AI活用ユースケース > マーケティング > 媒体社から届く掲載実績のPDFレポートを読み取って、広告主ごとの統合レポートに転記する

媒体社から届く掲載実績のPDFレポートを読み取って、広告主ごとの統合レポートに転記する

実装ステータス:構成例 技術的に実現可能な構成として設計したもの。自社未検証

媒体社から届く掲載実績のPDFの表を読み取り、広告主ごとの統合レポートに転記します。読み取った数値はレポートの合計行と発注の内容で検算し、合わないものだけを担当者に回します。

サマリー
生成AI
ChatGPT/Claude/Gemini
AIサービス
AWS Textract/Azure AI/Google Document AI
連携・自動化
Google Apps Script/Make/Python
対象業界
不動産/小売/広告/教育
対象部門
マーケティング
対象業務
データ入力・転記/内容確認・チェック
主な課題
人手が足りない/入力作業が多い/確認ミスが多い
AIで行う処理
読み取り(OCR)
主な効果
入力漏れ削減/対応スピード向上/工数削減
導入難易度
★★☆☆☆
実装レベル
半自動化
費用感
API連携(中)
人間の確認
条件付き
現在工数
80h/月
AI導入後
20h/月
想定削減
75%
年間削減
720h
モデル条件による試算値です。実在企業の実績ではありません。

01導入前 / 導入後の業務フロー

導入前(Before)
  1. 媒体社から、掲載実績のPDFがメールで届く
  2. 担当者がPDFを開き、どの広告主の、どの発注の実績かを特定する
  3. 発注台帳を開き、その発注の内容(掲載の期間、回数、面数、費用)を確かめる
  4. PDFの表を見ながら、統合レポートのスプレッドシートに数値を打ち込む
  5. 打ち込んだ数値の合計が、PDFの合計行と合うかを電卓で確かめる
  6. 発注した回数と掲載された回数が合っているかを見る。合わなければ媒体社に問い合わせる
  7. 全媒体がそろったら、統合レポートを広告主へ送る
導入後(After)
  1. 自動媒体社からのメールに付いたPDFを、決めたラベルから1時間ごとに取り出し、受領フォルダに保存する
  2. 自動PDFを Google Document AI の Form Parser に送り、表とキーと値の組を読み取る
  3. 自動読み取った内容から、媒体社・広告主・発注番号を特定する
  4. 自動その媒体社の列の対応表があれば、対応表で列を統合レポートの列に対応づける
  5. 自動対応表が無いか、列の名前が変わっていれば、AIに対応づけの案を作らせ、担当者の確認待ちにする
  6. 自動数値をセルからそのまま写し、各行の合計と合計行を検算する
  7. 自動掲載の期間・回数・面数を発注台帳と突き合わせる
  8. 自動検算と突き合わせが通ったものは統合レポートに転記し、通らないものは確認の一覧に回す
  9. 人担当者が確認の一覧と、対応づけの案を確かめる
  10. 人発注と実績の食い違いがあれば、媒体社に問い合わせる
  11. 人全媒体がそろった統合レポートを見直し、広告主へ送る
各工程の詳しい説明を読む
  1. 媒体社から、掲載実績のPDFがメールで届く
  2. 担当者がPDFを開き、どの広告主の、どの発注の実績かを特定する
  3. 発注台帳を開き、その発注の内容(掲載の期間、回数、面数、費用)を確かめる
  4. PDFの表を見ながら、統合レポートのスプレッドシートに数値を打ち込む
  5. 打ち込んだ数値の合計が、PDFの合計行と合うかを電卓で確かめる
  6. 発注した回数と掲載された回数が合っているかを見る。合わなければ媒体社に問い合わせる
  7. 全媒体がそろったら、統合レポートを広告主へ送る

(a)転記が作業の大半を占める。 20分のうち半分以上は、PDFとスプレッドシートを並べて数字を打ち込む時間です。Web媒体の日別の表示回数のように、行が30行を超えるレポートもあります。 判断らしい判断はほとんどありません。

(b)桁の打ち間違いが残る。 表示回数の「125,400」を「12,540」と打つ、列を1つずらして打つ。5番目の電卓での検算は、忙しい週ほど省かれます。 広告主から「この媒体だけ数字がおかしい」と指摘されて気づくことがあります。

(c)発注と実績の食い違いに気づくのが遅い。 交通広告で10面を発注したのに8面しか掲出されていない、新聞で3回の予定が2回だった。6番目の確かめは、担当者が発注の内容を覚えているかどうかで決まります。 気づくのが統合レポートを送った後だと、媒体社との調整も広告主への説明も後手に回ります。

(d)書式を覚えている人が限られる。 40社の媒体社のレポートのどこに何が書かれているかを知っているのは、長く担当している人です。その人が休むと、締めの週の作業が止まります。

  1. 【自動】 媒体社からのメールに付いたPDFを、決めたラベルから1時間ごとに取り出し、受領フォルダに保存する
  2. 【自動】 PDFを Google Document AI の Form Parser に送り、表とキーと値の組を読み取る
  3. 【自動】 読み取った内容から、媒体社・広告主・発注番号を特定する
  4. 【自動】 その媒体社の列の対応表があれば、対応表で列を統合レポートの列に対応づける
  5. 【自動】 対応表が無いか、列の名前が変わっていれば、AIに対応づけの案を作らせ、担当者の確認待ちにする
  6. 【自動】 数値をセルからそのまま写し、各行の合計と合計行を検算する
  7. 【自動】 掲載の期間・回数・面数を発注台帳と突き合わせる
  8. 【自動】 検算と突き合わせが通ったものは統合レポートに転記し、通らないものは確認の一覧に回す
  9. 【人】 担当者が確認の一覧と、対応づけの案を確かめる
  10. 【人】 発注と実績の食い違いがあれば、媒体社に問い合わせる
  11. 【人】 全媒体がそろった統合レポートを見直し、広告主へ送る

6番目と7番目の2つの検算が、この設計の中心です。 6番目は読み取りが正しいかを、7番目は掲載が発注どおりだったかを確かめます。どちらかが通らないものだけを人が見ます。

5番目で、AIの提案をそのまま使わないのも意図してのことです。 列の対応を1つ取り違えると、その媒体社のレポートは毎月、同じ列を間違えて転記し続けます。 対応表に入る前に、必ず担当者が確かめます。

02今回想定するシステム構成

構成図
媒体社からのメール(PDF添付)
   ▼【トリガー】1時間ごと(決めたラベル)
Google Apps Script ── 受領フォルダへ保存
   ▼
Google Document AI(Form Parser)
   │   表(headerRows / bodyRows / cells)、キーと値の組、信頼度
   ▼
Google Apps Script ── 媒体社・広告主・発注番号を特定
   ├── 対応表あり ──▶ 対応表で列を対応づけ
   └── 対応表なし・列が変わった ──▶ Claude API(対応づけの案)──▶ 担当者が確認
   ▼
Google Apps Script ── 数値をセルから写す
   ├──▶ 各行の合計と合計行の検算
   └──▶ 発注台帳との突き合わせ(期間・回数・面数)
   ▼
通過 ──▶ 統合レポートへ転記
不通過 ──▶ 確認の一覧
   ▼
【担当者が確認・媒体社へ問い合わせ・広告主へ送付】
役割想定する製品代替候補
OCRGoogle Document AI(Form Parser)Azure AI Document Intelligence、AWS Textract
生成AIClaude API(列の対応づけの案)OpenAI API、Gemini API
差異計算Google Apps Script(合計の検算と、発注台帳との突き合わせ)Python
連携Google Apps Script(メールの取り出し、転記)Python、Make
保管Google ドライブ(受領フォルダ、処理済みフォルダ)Microsoft SharePoint

土台になるのは、Google Document AI の Form Parser です。 文書からキーと値の組、チェックボックス、表、11種類の一般的な項目(日付・金額・数量・組織名など)を取り出すプロセッサで、200を超える言語に対応しています。入力はPDFと画像です。

生成AIを使った Custom Extractor を選ばないのには理由があります。 Custom Extractor は生成AIで項目を取り出せるプロセッサですが、生成AIの版は英語のみとされています。日本語の媒体社のレポートを読む本記事では、表をそのまま取り出す Form Parser を使います。

ページ数の上限に気をつけます。 Form Parser は、1回の同期の処理(オンライン処理)で15ページまで、まとめて送るバッチ処理で100ページまでとされています。掲載実績のレポートは多くが数ページですが、日別の数値を何か月分も載せたものは15ページを超えることがあり、その場合はページを分けるかバッチ処理に回します。

呼び出しは、Apps Script から REST の :process を呼ぶ形です。 要求の本文の rawDocument に、Base64で符号化したPDFの中身と mimeType を入れ、OAuth 2.0 のアクセストークンを付けて送ります。同期の処理なので、1回の呼び出しで読み取り結果が返ります。

03どうやって実装するのか

Step1

処理の起点を決める

Apps Script の時間主導のトリガーで、1時間ごとに動かします。 Gmail で媒体社からのメールに自動でラベルが付くようにしておき、ラベルの付いた未処理のメールからPDFを取り出して受領フォルダに保存します。 取り出したメールには「処理済み」のラベルを付け直します。

届いたときに即座に動かす形にはしません。 統合レポートの締めは月に1回で、1時間の遅れは問題になりません。 時間主導のトリガーは、たとえば9時に設定しても9時から10時のあいだで実行時刻が少しずれるとされていますが、この業務では影響がありません。

インストール型トリガーは、作った人のアカウントで動くとされています。メディア部門の誰が受け取ったメールでも処理できるよう、媒体社からのメールを受ける共用のアカウントで作ります。 担当者の個人のアカウントで作ると、その人が異動したときに止まります。

締めの週だけ、担当者が手で動かす入口も用意します。 スプレッドシートのメニューから「いますぐ取り込む」を実行できるようにし、急ぐ広告主の分をその場で処理できるようにします。

Step2

入力データを集める

データ中身取得元
掲載実績のPDF媒体社のレポート。表と、広告主名・案件名・期間などの見出し媒体社からのメール
読み取り結果表のヘッダ行と本文の行、セルの文字と信頼度、キーと値の組Google Document AI
媒体社の一覧媒体社コード、名称、差出人のメールアドレス、レポートの書式の特徴スプレッドシート
列の対応表媒体社ごとに、レポートの列の名前と統合レポートの列の対応、確かめた日と人スプレッドシート
発注台帳発注番号、広告主、媒体社、掲載の期間、回数、面数、費用スプレッドシート
統合レポート広告主ごとの月次のシートスプレッドシート

質を決めるのは、列の対応表と発注台帳です。 対応表が無ければ、毎月AIに対応づけを提案させることになり、確認の手間が減りません。発注台帳に回数や面数が入っていなければ、掲載が発注どおりだったかを確かめる先がありません。

媒体社の特定は、差出人のメールアドレスから行います。 レポートの中の媒体社名は、ロゴの画像だったり略称だったりして、読み取りでは確実に取れないことがあります。 差出人で引けないとき(転送されてきたときなど)に限り、読み取った本文から探します。

Step3

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

取るものどこから何に使うか
表pages の中の tables(headerRows と bodyRows、その中の cells)列の名前と、行ごとの数値
キーと値の組formFields(fieldName と fieldValue)広告主名、案件名、発注番号、期間
全文text表やキーと値の組に出なかった項目を探す
信頼度各要素の layout の confidence検算が合わなかったときに、どのセルを疑うか

表のセルの文字は、text の位置で引きます。 読み取り結果では、全文の text が「正本」になっていて、表のセルやキーと値の組は、textAnchor の開始と終了の位置で text の一部を指しています。セルの中身を取るには、この位置で text を切り出します。

発注番号は、キーと値の組から取ります。 媒体社のレポートの多くに「御社発注番号」「オーダーNo.」のような欄があり、formFields に出ます。欄の名前が媒体社ごとに違うので、媒体社の一覧に欄の名前を持たせておきます。 発注番号が無いレポートは、広告主名・媒体社・期間で発注台帳を引きます。

Step4

AIへ渡す前に整形する

  1. ファイルの形式を確かめる … PDFと画像だけを受け付けます。ExcelやCSVで届いたものは、読み取りをせずに直接取り込む経路に回します
  2. ページ数を確かめる … 15ページを超えるものは、ページを分けて送るか、バッチ処理に回します
  3. パスワード付きのPDFを分ける … 開けないものは確認の一覧に回し、媒体社にパスワードを確かめます
  4. 同じレポートの重複を検知する … 媒体社・発注番号・期間が同じものが既にあれば、差し替え版か重複かを担当者に確かめます
  5. 統合レポートの列の一覧を用意する … 対応づけの先になる列(媒体、期間、回数、面数、表示回数、クリック数、費用など)を固定の名前で持ちます

4番目は、媒体社が訂正版を送ってくるときに効きます。 「先日のレポートに誤りがありました」と訂正版が届いたとき、両方を転記すると数値が倍になります。 同じ発注・同じ期間のものは自動で上書きせず、担当者が差し替えを決めます。

Step5

AIに処理させる

させるのは、レポートの表の列の名前を、統合レポートの列に対応づける案を作ることだけです。 数値には触れさせません。

させること中身判断できないときの扱い
列の対応づけレポートの各列が、統合レポートのどの列に当たるか当たる列が無ければ unmapped
単位の読み取り「千回」「千円」「税込」「税抜」など、列の名前や注記にある単位書かれていなければ unknown
合計行の特定表のどの行が合計・小計か決められなければ unknown
対応の根拠対応づけの理由(列の名前、注記、他の列との関係)-

単位の読み取りを分けているのが、この表の要点です。 媒体社によっては表示回数を「千回」単位で、費用を「税抜」で載せています。列の対応が正しくても、単位を取り違えると数値が1,000倍ずれたり、税の分だけずれたりします。 単位が書かれていなければ推測させず、担当者に確かめてもらいます。

させないこと理由
数値の転記数値はセルからプログラムが写す。AIを通さない
数値の補完読み取れないセルを、前後の行や合計から埋めない
単位の推測「表示回数なら普通は回」と決めない
発注との食い違いの評価掲載の不備かどうかは媒体社への確認で決まる
対応表への直接の登録担当者が確かめてから登録する

1行目と2行目が、この構成の要です。 AIに数値を転記させれば、表の読み取りから転記まで1回で済むように見えます。しかし、読み取れなかったセルをAIが前後から補うと、第1章の検算が合ってしまいます。 検算が合うように埋められた数値は、もう検算では見つかりません。

Step6

指示内容を固定する

あなたは広告代理店のメディア部門で、媒体社から届いた掲載実績の
レポートの表を、自社の統合レポートの列に対応づける立場です。
渡す表のヘッダと、先頭の3行だけを見て判断してください。
推測で補わないでください。

【やること】
1. レポートの表の各列について、統合レポートの列の一覧の
   どれに当たるかを target に書いてください。
   当たるものが無ければ "unmapped" にしてください。
2. 各列の単位を unit に書いてください。
   列の名前か、表の注記に書かれている単位だけを使ってください。
   (例:「回」「千回」「円」「千円」「税込」「税抜」)
   書かれていなければ "unknown" にしてください。
3. 表の中で、合計や小計に当たる行があれば、その行番号を
   total_rows に書いてください。
4. 対応づけの根拠を reason に1文で書いてください。

【厳守事項】
- 数値を書き写さないでください。数値を計算しないでください。
- 単位を推測しないでください。「表示回数なら回」のように、
  一般的な単位を当てはめないでください。
- 1つの列を、統合レポートの2つの列に対応づけないでください。
- 統合レポートの2つの列に、同じレポートの列を対応づけないでください。
- 列の名前が似ていても、意味が違うと考えられる場合は
  "unmapped" にし、reason に理由を書いてください。
  (例:「掲出面数」と「掲出枚数」、「配信数」と「表示回数」)

【媒体社】{media_name}
【統合レポートの列の一覧】{target_columns}
【前回までの対応表(あれば)】{previous_mapping}
【レポートの表のヘッダ】{header_rows}
【レポートの表の先頭3行】{sample_rows}

渡すのが「ヘッダと先頭の3行だけ」なのは、数値を扱わせないためです。 表の全部を渡すと、AIは数値にも目を向け、合計が合わないことに気づいて「おそらくこの値の読み取りの誤り」と補正しようとします。 列の意味を決めるのにヘッダと数行で足りるなら、それ以上は渡しません。入力が短くなるので、費用も抑えられます。

「似ていても意味が違う列」の例を名指しで書いているのは、媒体の業界で実際に混ざりやすいからです。 交通広告の「面数」は掲出した場所の数、「枚数」はポスターの枚数で、1面に2枚貼ることもあります。 Web媒体の「配信数」と「表示回数」も、媒体社によって定義が違います。

Step7

出力形式を固定する

次の形のJSONで受け取ります。 Claude API の構造化出力で、スキーマに沿った形で返させます。

{
  "media_code": "",
  "columns": [
    {
      "source_index": 0,
      "source_name": "",
      "target": "media | period_start | period_end | insertions | faces | impressions | clicks | cost | unmapped",
      "unit": "",
      "reason": ""
    }
  ],
  "total_rows": [],
  "notes": ""
}

1つ目の理由は、そのまま列の対応表の行になることです。 担当者が確かめて承認すると、columns がその媒体社の対応表に登録され、翌月からはAIを呼ばずに、この対応表で転記します。

2つ目は、source_index で、読み取り結果の表の列の位置と結びつくことです。 Document AI の表のセルは行と列の順に並んでいるので、列の位置が決まれば、各行のセルからその列の文字を取り出せます。 数値の転記は、この位置を使ってプログラムが行います。

3つ目は、total_rows で検算の相手が決まることです。 合計行を明示させておくと、合計行を1行の実績として転記してしまう失敗を防げます。

たとえば地域のWeb媒体のレポートなら、対応づけは次のようになります。

レポートの列対応づけ(target)単位(unit)根拠(reason)
配信期間period_start / period_end-「〜」で開始と終了が書かれている
掲載面media-媒体内の掲載位置の名前が並ぶ
表示回数(千回)impressions千回列の名前に単位が書かれている
クリックclicks回表の注記に「単位:回」とある
実施金額costunknown税込か税抜かの記載が無い
CTRunmapped-統合レポートの列に当たるものが無い

5行目の unknown が出たら、担当者が媒体社の請求書や発注書を見て決めます。 決めた単位は対応表に書き込み、翌月からは確かめ直しません。CTRのように統合レポートに列の無いものは、転記しません。 率は統合レポートの側で、表示回数とクリック数から計算し直します。

転記の後の検算は、プログラムの側で行います。

検算通らなかったときの扱い
各行の数値の合計 = 合計行確認の一覧へ。信頼度の低いセルに印を付けて示す
掲載の期間が発注の期間の中に入っている確認の一覧へ
掲載回数・面数 = 発注の回数・面数確認の一覧へ。媒体社への問い合わせの候補
費用 = 発注の費用確認の一覧へ。単位(税込・税抜)を先に疑う
単位が unknown の列がある転記せずに確認の一覧へ
Step8

システムへ連携する

つなぎ先方式内容
GmailApps Script(時間主導のトリガー)ラベルの付いたメールからPDFを取り出す
Google ドライブApps Script受領フォルダと処理済みフォルダに保存する
Google Document AIREST の :process(Apps Script から呼ぶ)表・キーと値の組・信頼度を返す
Claude APIApps Script から呼ぶ列の対応づけの案をJSONで返す
発注台帳スプレッドシートの読み取り期間・回数・面数・費用を引く
統合レポートスプレッドシートへの書き込み検算を通った数値を転記する

発注台帳には書き込みません。 発注と実績の食い違いを見つけても、発注台帳を直すのは発注を担当した人です。この構成から台帳を書き換えると、何が発注で何が実績かが分からなくなります。

統合レポートへの書き込みは、検算を通ったものだけです。 通らなかったものは、担当者が確認の一覧で直してから転記します。広告主へ送るのは人です。

Step9

人が確認する

  1. 対応づけの案を確かめる … 新しい媒体社か、書式が変わった媒体社のときだけです。単位の列を最優先で見ます
  2. 検算が合わなかったレポートを開く … 信頼度の低いセルに印が付いているので、PDFの該当箇所と見比べます
  3. 発注との食い違いを確かめる … 読み取りの誤りでなければ、媒体社に問い合わせます
  4. 統合レポートを見直す … 全媒体がそろった時点で、前月と比べて極端に違う数値が無いかを見ます
  5. 判定を直したら記録する … どのセルを、どの値に直したかを残します

1番目は、最初の数か月に集中します。 40社の媒体社の対応表がそろえば、それ以降は書式が変わったときだけになります。

目標は、ならして1件5分です。 検算も突き合わせも通ったレポートは、統合レポートに転記された結果を流し見るだけで、開くのは検算が合わなかったものと食い違いのあったものです。

Step10

例外に対処する

起きること対応
表の中にセルの結合があるForm Parser の表は結合のない通常の表だけを認識する。結合のある書式の媒体社は、読み取り後の列の位置を担当者が確かめる
15ページを超えるページを分けて送るか、バッチ処理に回す
パスワード付きのPDF確認の一覧へ。媒体社にパスワードを確かめる
媒体社が特定できない確認の一覧へ。推測で媒体社を決めない
発注台帳に該当する発注が無い確認の一覧へ。発注の登録漏れか、別の広告主の実績かを確かめる
同じ発注・期間のレポートが二度届く自動で上書きせず、差し替えか重複かを担当者が決める
ExcelやCSVで届く読み取りをせず、対応表で直接取り込む
Document AI がエラーを返す受領フォルダに残し、次の回に再び送る。処理済みへ移すのは成功時だけ
表が画像として貼られていて読み取れない確認の一覧へ。担当者が手で転記する
1つのPDFに複数の広告主の実績が載っている広告主名の列か見出しで行を分け、分けられなければ確認の一覧へ
数値の中に「-」「※」などの記号がある数値として写さず、そのセルに印を付けて確認の一覧へ
対応表の列の名前がレポートに見当たらない書式が変わったとみなし、AIに対応づけの案を作らせて確認待ちにする

1行目は、媒体の業界では珍しくありません。 交通広告のレポートで、路線名のセルが複数の駅の行にまたがって結合されている、という書式です。読み取り結果の説明では、Form Parser の表の抽出は行や列にまたがるセルの無い通常の表だけを認識し、rowSpan と colSpan は常に1になるとされています。結合のある書式の媒体社は、対応表に印を付け、読み取った行の路線名が空になっていないかを必ず確かめます。

Step11

記録を残す

  • 受け取ったPDFと、差出人・受信日時
  • Document AI が返したJSONの全文
  • AIへ渡した入力と、返ってきた対応づけの案
  • 対応表の変更の履歴 … いつ、誰が、どの列の対応を確かめたか
  • 検算と突き合わせの結果
  • 担当者がセルの値を直した記録 … どのセルを、どの値からどの値へ
  • 媒体社への問い合わせと、その回答

対応表の変更の履歴を残すのは、転記の誤りが見つかったときに遡るためです。 ある媒体社の数値が数か月ずれていたと分かったとき、いつの対応表の変更から始まったかが分かれば、直す範囲が決まります。

04実装レベルの3段階

最小構成:PDFを手でAIの画面に貼り、列の対応づけだけをさせる。転記は手で行う / 列の意味の確かめ
半自動化:上記+Apps Script でメールからPDFを取り出し、Document AI で読み取り、対応表で転記し、検算まで行う / 受け取りから転記と検算まで
本格構成:上記+媒体社への問い合わせ文の下書き、訂正版の差し替えの半自動化、広告主向けの送付の準備 / 受け取りから送付の準備まで

最小構成では、第4章の②は減りません。 転記は手で行うからです。確かめるための段階です。 半自動化で②と③がなくなり、この段階が本記事の想定です。 本格構成は急がないでください。 媒体社への問い合わせの文面は、その媒体社との取引の経緯で変わります。半自動化で食い違いの件数と型を数か月見てから、下書きを足すかを決めます。

05工数削減シミュレーション

前提値(モデル条件)
対象人数
5 名
月間件数
240 件
1件あたり現在時間
20 分
1件あたり導入後時間
5 分
現在  240件 × 20分 ÷ 60 = 80 時間/月
導入後 240件 × 5分 ÷ 60 = 20 時間/月
月間削減時間
60h
削減率
75%
年間削減時間
720h
年間金額換算(時間単価3,000円)
216万円
モデル条件による試算であり、実際の効果は業務内容・運用方法によって異なります。

自社条件で導入効果を整理したい方へ

このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。

AI活用について相談する

06向いている企業・向いていない企業

向いている
  1. 広告主1社について複数の媒体社に出稿しており、媒体社ごとに書式の違う掲載実績のPDFを毎月受け取って、広告主向けの統合レポートにまとめている広告代理店。APIで数値を取れない交通広告、新聞、雑誌、地域のWeb媒体などへの出稿が多い場合。転記を担当者の手で行っており、桁の打ち間違いや、発注した回数と掲載された回数の食い違いに気づくのが遅れている場合。Google Workspace を使っている場合。
向いていない
  1. 出稿先がAPIで数値を取れる大手のWeb広告の媒体だけの場合。媒体社から届くレポートがCSVやExcelで、読み取りが要らない場合。月に受け取るレポートが数十件で、手で転記して足りる場合。なお、掲載の不備について媒体社に補償を求めるか、広告主にどう説明するかは、この構成では決めません。

07最小構成で試す方法

  1. 先月受け取った掲載実績のPDFから、媒体社の違う10件を選ぶ(セルの結合がある書式と、単位が千回・千円の書式を必ず入れる)
  2. 当時の統合レポートの、その10件の数値を用意する
  3. 手元のAIサービスに、PDFを1件ずつ貼り付け、「この表の各列が、媒体・期間・回数・面数・表示回数・クリック数・費用のどれに当たるかを答えてください。単位が書かれていれば書き、無ければ不明としてください。数値は書き写さないでください」と指示する
  4. 出てきた対応づけを、当時の統合レポートの転記と見比べる
  5. 別に、Google Document AI の Form Parser の画面で同じPDFを読み取り、表が正しく行と列に分かれるかを見る

4番目と5番目を分けて確かめます。 対応づけが正しくても、表の読み取りが崩れていれば転記は誤ります。

出てきた内容判断
対応づけも表の読み取りも正しいApps Script での組み立てに進む
単位を推測で埋めた指示の書き方で直る。構成は有効
セルの結合のある表で行がずれたその媒体社は対応表に印を付け、確認を残す
表が画像で読み取れないその媒体社にPDFの作り方を相談する

08実装時につまずきやすいポイント

問題対策
AIが読み取れないセルを補って検算が合ってしまう数値をAIに通さない。 セルからプログラムが写す
単位を取り違えて1,000倍ずれる単位を推測させず、unknown は転記しない
「面数」と「枚数」を取り違える似ていて意味が違う列を指示に名指しする
セルの結合で行がずれるForm Parser は通常の表だけ。結合のある媒体社は確認を残す
日本語のレポートに Custom Extractor を使おうとする生成AIの版は英語のみ。Form Parser で表を取る
15ページを超えて処理できないページを分けるか、バッチ処理に回す
合計行が実績の1行として転記されるtotal_rows で合計行を明示させる
訂正版が届いて数値が倍になる同じ発注・期間は自動で上書きしない
トリガーが担当者の異動で止まる共用のアカウントで作る
対応表が確かめないまま登録される担当者の承認を経てから登録する

上の2行が、この構成の失敗のほとんどです。 どちらも、転記の途中に推測が入ることで起きます。数値を写す経路から推測を締め出しておくかどうかで、運用に乗るかが決まります。

09セキュリティ・AIガバナンス上の注意点

この構成で扱うデータ: 広告主の出稿の内容と費用、媒体社との取引の条件、発注台帳です。個人情報はほとんど含みませんが、広告主ごとの費用は取引上の秘密です。

  1. 生成AIへ渡すのは、表のヘッダと先頭の数行だけにする … 費用の列の数値まで渡す必要はありません。渡す範囲を絞ることが、精度と秘密の両方を守ります
  2. 学習に使われない設定と契約で使う … AIのAPIの利用条件を確かめ、入力が学習に使われない形で使います
  3. Document AI を使う Google Cloud のプロジェクトの権限を絞る … 読み取りを呼べるアカウントと、結果を見られる人を限ります
  4. 広告主どうしのデータを混ぜない … 統合レポートは広告主ごとに分け、共有する範囲をその広告主の担当者に限ります
  5. 媒体社への問い合わせを自動で送らない … 掲載の不備を指摘するかどうかは、取引の関係に関わります。送るのは担当者です
  6. 受け取ったPDFを原本として残す … 統合レポートの数値の根拠として、媒体社から受け取ったままのファイルを保存しておきます

誤りが起きた場合のリスクは、数値を誤って広告主へ報告することと、掲載の不備を見落とすことの2つです。 前者は合計行の検算で、後者は発注台帳との突き合わせで守ります。

10まず何から始めるか

1週目:発注台帳を確かめる

発注台帳に、掲載の期間、回数、面数、費用の列がそろっているかを確かめます。空欄の多い発注があれば、この機会に埋めます。突き合わせる先が無いと、第5章の7番目の突き合わせが働きません。

2週目:10件で試す

媒体社の違う10件のPDFで、手元のAIサービスに列の対応づけをさせ、Document AI の画面で表の読み取りを確かめます。セルの結合のある書式と、単位が千回・千円の書式を最優先で見ます。

3週目:対応表を作る

取引の多い上位10社の媒体社について、列の対応表を作ります。AIの案を担当者が確かめて登録する流れを、ここで一度通しておきます。

4週目:メールから転記までをつなぐ

Apps Script で、ラベルの付いたメールからPDFを取り出し、Document AI で読み取り、対応表で転記して検算するところまで作ります。この時点では統合レポートに直接書き込まず、別のシートに書き出して当時の転記と見比べます。

2か月目: 検算を通ったものを統合レポートに書き込み始め、確認の一覧に回った件数を数えます。3か月目以降: 対応表を残りの媒体社に広げ、1件20分が何分になったかを実測します。全媒体社の対応表がそろい、生成AIを呼ぶのが書式の変わったときだけになった時点で、この構成は完成です。


11関連ユースケース

12この仕組みを理解するための記事

13技術仕様の確認日・参考情報

技術仕様確認日:2026-09-29/最終更新:2026-09-29
確認した内容情報源確認日
Form Parser がキーと値の組、チェックボックス、表、11種類の一般的な項目を取り出し、200を超える言語に対応し、入力がPDFと画像であること。オンライン処理で15ページ、バッチ処理で100ページまでであること。Custom Extractor の生成AIの版が英語のみであることGoogle Cloud: Processor list2026-09-29
読み取り結果の text が正本で、他の要素が textAnchor の位置で参照すること。表が headerRows と bodyRows と cells で表され、Form Parser の表は行や列にまたがるセルの無い通常の表だけを認識し rowSpan と colSpan が常に1であること。formFields の fieldName と fieldValue。各要素に confidence があることGoogle Cloud: Handle the processing response2026-09-29
オンライン処理の要求が :process の REST エンドポイントに送られ、rawDocument に Base64 の中身と mimeType を入れ、OAuth 2.0 のアクセストークンで認証すること。バッチ処理が Cloud Storage を使うことGoogle Cloud: Send a processing request2026-09-29
Apps Script のインストール型トリガーに時間主導のものがあり、実行時刻が少しずれることがあること。作った人のアカウントで動くことGoogle for Developers: Installable triggers2026-09-29
構造化出力がJSONスキーマに沿った応答を返す機能で、output_config.format で指定することClaude Docs: Structured outputs2026-09-29

掲載の不備を媒体社にどう伝えるかは、媒体社との取引の条件と自社の方針で決めてください。 本記事は上記の公開情報で確認できた範囲だけを扱っています。

実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。

自社の業務に使えるAI活用候補を整理します

このユースケース(UC-0301)についてのご相談はこちらから。

AI活用について相談する
目次