業界紙・専門誌の記事を毎月集めて要約し、自社の事業・顧客・競合に関わる動きを経営会議の資料向けの一覧にする

処理の起点を決める

毎朝1回、Apps Script の時間主導型トリガーで動かします。 公式のページでは、時間主導型トリガーは1分ごとから月に1回まで設定でき、指定した時刻から少しずらして動くことがある（9時と指定すると9時から10時のあいだ）とされています。記事の要約は急ぐ処理ではないので、このずれは問題になりません。

月末にもう1回、別のトリガーで「話題の一覧」の案を作ります。 経営会議の資料の締めの3営業日前に動かし、担当者が確かめる時間を残します。

記事を1本ずつ即座に処理しないのは、意図してのことです。 毎朝まとめて処理すれば、前日に3名が入れた記事を1回で読ませられ、同じ日に同じ記事が2回入ったときも、その場で気づけます。 処理が終わったPDFは処理済みのフォルダへ移し、受付シートのURLには処理日を書き込みます。受付フォルダに残っている数が、そのまま未処理の数になります。

入力データを集める

質を決めるのは、照合用の一覧の「別名」の列です。 記事は「三井化学」とも「同社」とも書き、子会社の名前だけで出ることもあります。別名が無ければ、関係先は正式名で書かれた記事にしか付きません。 最初の準備は、主要な顧客と競合の上位50社について、略称・グループ会社・旧社名を足すことです。

前月までの話題は、続報を見分けるために渡します。 先月「値上げを検討」と出た話の続きで「値上げを発表」と出れば、新しい話題ではなく続報として扱えます。

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

PDFは、Gemini API の Interactions（/v1beta/interactions）に document として渡します。 公式のページでは、小さな文書はリクエストに直接入れ、大きなものや何度も使うものは Files API で上げる形が勧められています。Files API で上げたファイルは48時間保存され、利用は無料です。記事1本のPDFは数ページなので、基本は直接入れる形で足ります。

Webの記事は、URL context に読ませた後、取得の結果を必ず見ます。 公式のページでは、url_context_result のステップに、取得を試みたURLごとの状態が返るとされています。取れなかったURLを、取れたものとして要約させないために、状態が取得成功でないものは要約を捨て、受付シートに「取得できず」と書き戻します。

ファイル名の決まりは「紙誌コード_発行日_面_連番.pdf」にします。 紙誌名と日付をAIに読ませると、紙面の欄外の日付と記事中の日付を取り違えることがあります。出典の情報はファイル名から機械的に取り、AIには本文だけを任せます。

AIへ渡す前に整形する

1. ファイル名の確認 … 決まりに合わないPDFは処理せず、受付シートに「ファイル名の確認」と書いて残します
2. 重複の確認 … 同じ紙誌・同じ発行日・同じ面のPDFがすでに処理済みなら、二重に送りません
3. ページ数の確認 … 記事1本で10ページを超えるものは、特集号を丸ごと保存した可能性が高いので人に戻します
4. 大きさの確認 … 公式のページの上限は50MBですが、記事1本で数MBを超えるものは画像の解像度が高すぎることが多いので、保存し直してもらいます
5. 照合用の一覧の整形 … 正式名・別名・区分（顧客／競合／仕入先／自社の事業）を1行ずつの表にし、プロンプトに入れられる形にします
6. URLの確認 … 受付シートのURLのうち、購読している紙誌のドメインのものは有料の記事の可能性が高いので、URLで渡さず「PDFで保存してください」と書き戻します

6番目を入れておかないと、空振りが毎朝続きます。 有料の記事のURLを貼っても、URL context では読めません。貼った人に、PDFで入れ直してもらうのが早道です。

AIに処理させる

させるのは、記事1本ごとに次の6つを返すことだけです。

月末の2回目の呼び出しでは、記事一覧から「話題の一覧」の案を作らせます。 同じ関係先・同じ動きの種類で、発行日の近い記事を1つの話題にまとめ、どの記事をまとめたかの番号を必ず付けさせます。 前月までの話題と同じ流れなら「続報」と付けます。

2行目と3行目がいちばん起きやすい失敗です。 「大手樹脂メーカーが値上げ」という記事に、一覧の中の樹脂メーカーを当てはめる。「年3万トン増強」を「月2,500トン」に直す。どちらも親切のつもりで起き、どちらも原文から離れます。 指示で禁じたうえで、数字は第7章の「システム連携」の照合で機械的に確かめます。

指示内容を固定する

あなたは化学品の専門商社の経営企画部で、業界紙・専門誌の記事を読み、
経営会議の資料の候補を作る担当です。
渡された記事の本文だけを根拠にしてください。記事に無いことは書かないでください。

【返す項目】
1. summary ... 記事の事実を3行で。各行60字以内。評価の言葉（大きな影響、注目など）を使わない
2. related ... 照合用の一覧に載っている名前のうち、記事に出てくるもの
   - 一覧の「正式名」で書き、記事中の表記を matched_text に写す
   - 一覧の別名と一致した場合も、正式名で書く
3. unlisted ... 記事に出てくる会社名で、一覧に無いもの。原文の表記のまま
4. move_type ... 次の中から1つまたは2つ
   値上げ・値下げ／需給／設備投資／参入・撤退／提携・買収／規制・制度／事故・品質／その他
5. figures ... 価格・数量・能力・金額・時期を、原文の文字列のまま。単位も写す
6. quotes ... summary と figures の根拠にした原文の一文。書き換えない。1つ120字以内

【厳守事項】
- 記事に「大手メーカー」「同業他社」などとしか書かれていないとき、
  一覧の会社を当てはめないでください。related に入れず、unlisted にも入れないでください。
- 記事に明記がない項目は「不明」とし、推測で埋めないでください。
- 数字を換算・合計・計算しないでください。年の数字を月に直さない、
  前年比を自分で出さない。原文に書かれた文字列だけを figures に入れてください。
- 自社への影響、重要度、経営会議に上げるべきかは書かないでください。
- 記事の全文を写さないでください。quotes は根拠の一文だけです。
- 記事が読めない、または記事でない（広告、目次、求人）と判断したときは、
  document_status にその旨を書き、他の項目は空にしてください。

【照合用の一覧（正式名｜別名｜区分）】{watchlist}
【前月までの話題】{previous_topics}
【記事】（添付のPDF、またはURLの先）

「一覧の会社を当てはめないでください」を、例を挙げて書くのが要です。 何も言わなければ、業界の知識から「大手樹脂メーカー」を特定の会社に当ててきます。当たっていることもありますが、記事に書かれていない以上、経営会議の資料には載せられません。

「年の数字を月に直さない」も具体的に書きます。 計算を禁じるだけでは、単位をそろえる親切を計算とは思わずにやります。原文の文字列のまま写させ、照合で確かめられる形を保ちます。

出力形式を固定する

構造化出力で、次の形のJSONを受け取ります。 公式のページでは、Interactions の response_format に mime_type として application/json を、schema にJSONスキーマを指定し、enum や required などに対応するとされています。

{
  "article_id": "NK_20261002_07_01",
  "document_status": "ok | unreadable | not_article",
  "summary": ["", "", ""],
  "related": [
    { "name": "", "category": "customer | competitor | supplier | own_business",
      "matched_text": "" }
  ],
  "unlisted": [""],
  "move_type": ["値上げ・値下げ"],
  "figures": [ { "text": "", "kind": "price | volume | capacity | amount | date" } ],
  "quotes": [""]
}

1つ目の理由は、照合をスクリプトでできることです。 related の name が照合用の一覧の正式名にあるか、matched_text が quotes か記事の中にあるかを、Apps Script で確かめられます。一覧に無い名前が related に入っていたら、その行は人の確認に回します。

2つ目は、数字を引用と照らせることです。 figures の text が quotes のどれかにそのまま含まれているかを文字列で見ます。含まれていなければ、AIが言い換えたか計算したということです。

3つ目は、document_status で空振りを分けられることです。 広告や目次のページを保存してしまった場合に、要約らしきものを作らせずに止められます。

公式のページは、構文として正しいJSONでも値はアプリ側で確かめるよう書いています。上の照合は、そのための仕組みです。なお、構造化出力と URL context などの組み込みツールを同時に使えるのは Gemini 3 系のモデルだけで、プレビューとされています。Webの記事の処理で組み合わせが使えない場合は、URL context で読ませる呼び出しと、JSONに整える呼び出しを2回に分けます。

システムへ連携する

経営会議の資料へは、自動では書き込みません。 一覧の候補から何を選ぶかは人の判断で、選ばれなかった記事が資料に混ざる経路を作らないためです。

記事一覧のシートには、元のPDFへのリンクを必ず入れます。 確認する人が引用に違和感を持ったら、1クリックで原文を開けるようにします。

人が確認する

1. 「確認」の印が付いた行を先に見る … 「関係先を確認」と「数字を確認」の行です。原文を開いて、AIの書いたことが記事にあるかを確かめます
2. 話題の一覧の案を見る … 同じ話題にまとめられた記事が本当に同じ話か、続報の付け方が正しいかを見ます
3. 印の無い行は、要点と引用を流し読む … 原文は開きません。引用と要点が食い違って見えたものだけ開きます
4. 経営会議に上げる話題を選ぶ … ベテランの担当者が選び、並べ、資料に写します
5. 直したところを記録する … 関係先を足した・消した、数字を直した、を一覧の列に残します

1番目を省かないでください。 印が付くのは、AIが一覧に無い名前を当てはめたか、数字を言い換えた可能性がある行です。経営会議で誤りが見つかるのは、たいていここです。

目標は、300本をならして1本2分です。 印の付く行が2割前後という想定で、それより多い月は、照合用の一覧の別名が足りていないか、プロンプトの禁止が効いていないかのどちらかです。

例外に対処する

上から3行目までが、最初の1か月の大半を占めます。 どれもAIの問題ではなく、記事の保存のしかたの問題です。 3名で保存の決まりをそろえるほうが、プロンプトを直すより効きます。

記録を残す

• 記事のPDFと、受付シートに貼られたURL（貼った人、貼った日）
• Gemini API が返したJSONの全文と、呼び出した日時
• そのとき使った照合用の一覧の版（シートのコピーを月ごとに残す）
• 照合の結果（「関係先を確認」「数字を確認」の印）
• 人が直した記録 … 関係先を足した・消した、数字を直した
• 経営会議に上げた話題と、まとめた記事の番号

3つ目で照合用の一覧の版を残すのは、一覧が月ごとに変わるためです。 別名を足すと、先月は付かなかった関係先が付くようになります。どの版で照合したかが分からないと、関係先の付き方が変わった理由を説明できません。

5つ目の記録は、照合用の一覧を育てる材料になります。 人が関係先を足した記事の表記を見れば、一覧に足すべき別名が分かります。