業界団体の事務局が、官公庁の発表と業界のニュースを Gemini で要約し、会員向けの月次の会報の原稿にまとめる

処理の起点を決める

起点は2つあります。毎朝の定時実行と、月末に担当者が押す原稿作成の実行です。

毎朝の実行は、Apps Script の時間主導のトリガーで動かします。公式のページでは、時間主導のトリガーは毎分から月1回までの間隔で設定でき、実行の時刻は少しずらされることがある（9時に設定すると9時から10時のあいだのどこか）とされています。朝の出勤までに終わっていればよいので、7時台に設定します。

毎朝の実行で行うのは、一覧の取得と、本文の取得と、要約までです。要約を毎朝少しずつ進めておくと、月末に120本をまとめて読む作業がなくなります。 担当者が手で足したURLも、翌朝に同じように処理されます。

月末の実行は、担当者がスプレッドシートのメニューから押し、載せるものに印が付いた行だけを会報のひな形に流し込みます。

インストール型のトリガーは作った人のアカウントで動くとされています。個人のアカウントで作ると異動で止まるので、事務局の共用のアカウントで作ります。

入力データを集める

質を決めるのは、真ん中の2つです。 会報の書き方の決まりが無ければ、AIは毎回それらしい別の書き方をし、担当者ごとの違いがAIごとの違いに置き換わるだけです。 前任者から口頭で伝わっている決まりを、ここで初めて文字にします。

会員の区分の説明は、「誰に関係するか」を決める材料です。 「空調：冷媒の規制、省エネの基準に関心」のように1行で書きます。

報道の行には、本文を入れません。 業界紙の記事は見出し、媒体名、掲載日、URLだけを候補の一覧に書きます。本文を貼り付ける欄そのものを作らないことで、誤って本文がAIに渡る経路をなくします。

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

一覧と本文の取得は、Apps Script の UrlFetchApp で行います。 公式のページでは、fetch は HTTP または HTTPS のリクエストを送って応答を返し、muteHttpExceptions を true にすると、失敗を示す応答でも例外を投げずに応答を返すとされています。失敗した行を記録して先へ進むために、muteHttpExceptions を有効にします。

一覧からは、題名とリンクだけを取ります。 キーワードに当たらなかった題名も別のシートに残し、担当者が週に一度ながめて、拾い漏らしに気づくたびにキーワードを足します。

発表の本文には、添付のPDFが付いていることが多くあります。 この構成では、まずページの本文だけを要約の材料にします。ページの本文が数行しか無く、中身がPDFにあると分かったものは、needs_attachment の印を付けて担当者に回します。 担当者がPDFの必要な部分の文字を候補の一覧の別の欄に貼ると、次の実行で要約されます。

新しく足された行だけを取りに行き、同じページを何度も取りません。 取得した本文は、取得日時と一緒に別のシートに保存します。

AIへ渡す前に整形する

1. 重複の除去 … 同じURL、または同じ題名が前月までの一覧にあれば、新しい行を作りません
2. タグの除去 … HTMLのタグ、メニュー、ページの上下の共通部分を取り除き、本文だけにします
3. 公表日の取り出し … 一覧のページの日付を、その行の公表日として持たせます。本文の中の日付と混ぜません
4. 長さの確認 … 本文がごく短いものは needs_attachment、非常に長いものは前半だけを渡さず担当者に回します
5. 種別による振り分け … 報道の行は本文の取得も要約もしません。寄稿は要約せず、体裁の整えだけに回します
6. 利用ルールの確認 … 種別が団体で、利用ルールの確認結果が空の行は、要約に進めません

3番目を軽く見ないでください。 報道発表の本文には「令和8年10月1日〜5日現在」の調査時点、会議の開催日、申込の締切など、日付がいくつも出てきます。公表日を本文から拾わせると、どれが公表日かをAIが選ぶことになります。 公表日は一覧のページの日付で決め、AIには本文の中の日付だけを扱わせます。

6番目は、最初に一度だけ手を動かす作業です。 団体ごとに「出典を書けば加工可」「転載は要許諾」のように設定のシートに書いておけば、以後は自動で入ります。

AIに処理させる

させるのは、1本の資料について、会員向けの要約を書き、日付と対象を原文から写し、関係する会員の区分を選ぶことです。

右端の列が、この構成でいちばん大事なところです。 本文に書かれていない日付や会員の対応を、AIが常識から補うと、会報が発表に無いことを言い出します。 空のまま返してよいことを、指示の側で何度も伝えます。

3行目がいちばん起きやすい失敗です。 会報の決まりが「西暦で書く」なら、AIは「令和8年10月26日」を「2026年10月26日」に直して書きます。直した文字列は原文に無いので、突き合わせで本当に正しいかを確かめられなくなります。 AIには原文のまま写させ、会報の表記への変換はプログラムで行います。

指示内容を固定する

あなたは業界団体の事務局で、会員向けの会報の原稿を準備する立場です。
渡された資料の本文だけを読み、決められた形式で返してください。
本文に書かれていないことを、常識や推測で補わないでください。

【会報の書き方の決まり】
{style_rules}

【会員の区分と、それぞれの関心事】
{member_segments}

【返すもの】
1. headline：内容が分かる見出し（「〜について」で終わらせない）
2. summary：会員が知っておくべきことを3〜5文で
3. dates：施行日・締切・開催日・調査時点など。種類と、本文の文字列のまま
4. figures：金額・件数・割合など。本文の文字列のまま
5. segments：関係する会員の区分（一覧から選ぶ。無ければ none）
6. relevance：high / medium / low
7. member_action：申請・届出・応募など、会員がすることが本文に書かれていれば写す

【厳守事項】
- dates と figures の text には、本文の文字列を一字一句そのまま写してください。
  和暦を西暦に直す、全角を半角に直す、「〜」を「から」に直すことをしないでください。
- 本文に日付が書かれていなければ dates は空の配列にしてください。
  公表日は別に管理しているので、書き出さないでください。
- 施行日・締切が本文に無いときに、「近日中」「今後」などの言葉で補わないでください。
- member_action は本文に書かれていることだけです。
  書かれていなければ空にし、「早めの対応を」などの助言を足さないでください。
- 出典、URL、発表した府省の名前を summary の中に書かないでください。
- 本文が短く、要約するだけの中身が無いときは summary_status を insufficient にし、
  summary は空にしてください。
- relevance は並べ替えの目安です。迷ったときは medium にしてください。
- 資料が会報の対象と無関係（人事異動の一覧だけ、など）なら relevance を low にし、
  その理由を note に1文で書いてください。

【資料の題名】{title}
【資料の本文】{body}

「公表日を書き出さない」を明記しないと、本文の冒頭にある日付を拾います。 報道発表のページには日付が何度も出てきて、そのうちどれが公表日かは本文だけでは決めにくいからです。公表日は一覧のページで決め、AIの仕事から外します。

「助言を足さない」のは、会報が団体の公式の文書だからです。 会員にどう勧めるかは、事務局長が原稿の段階で書き足します。

出力形式を固定する

構造化出力で、次の形のJSONを返させます。 公式のページでは、response_format に type を text、mime_type を application/json とし、schema に JSON Schema を置くとされています。

{
  "headline": "",
  "summary_status": "ok | insufficient",
  "summary": "",
  "dates": [
    { "kind": "effective | deadline | event | survey_point | other", "text": "" }
  ],
  "figures": [
    { "label": "", "text": "" }
  ],
  "segments": ["piping | hvac | sanitary | electrical | design | none"],
  "relevance": "high | medium | low",
  "member_action": "",
  "note": ""
}

1つ目の理由は、dates と figures を突き合わせに回せることです。 返ってきた text を本文の中で検索し、見つからなかったものに not_in_source の印を付けます。 文章の中に日付が埋まっていると、この突き合わせができません。

2つ目は、enum で値を縛れることです。 公式のページでは、文字列の enum とオブジェクトの required が使えるとされています。segments と relevance を一覧の中の値に限ることで、会員の区分に無い言葉が混ざりません。 一方で、minLength と maxLength は強制されず黙って取り除かれるとされているので、要約の長さはプログラムの側で数え、長すぎるものに印を付けます。

3つ目は、任意の項目の並べ方です。 公式のページでは、任意の項目が長く続くと 400 INVALID_ARGUMENT になることがあり、必須の項目をあいだに挟むと解消するとされています。この形では headline・summary_status・relevance を必須にし、任意の項目のあいだに置きます。

突き合わせの後、プログラムが出典の行を組み立てます。

1行目の「をもとに〇〇協会作成」は、加工したことを示す一文で、省きません。

システムへ連携する

会員への配信は、この構成から行いません。 原稿の下書きを作るところまでで、PDFにして配信するのは事務局長が確定させた後に人が行います。 配信まで自動にすると、確かめていない要約が会員に届きます。

ひな形は毎月複製して使い、過去の号を上書きしません。 流し込む順は「行政の動き」は公表日の順、「業界の動き」は関係の強さの順にし、担当者が並べ替えます。

人が確認する

人が手を入れるのは2か所です。 候補の一覧で載せるものを選ぶところと、原稿の下書きを原文と見比べるところです。

1. 載せるものを選ぶ … 関係の強さで並べた一覧を上から見ます。low の行も題名だけは目を通します
2. 報道に一言を書く … 見出しの横に、会員にとっての意味を1〜2文で書きます。記事の本文を写しません
3. not_in_source の印を先に見る … 日付や数字が原文に見つからなかったものです。原文を開いて正しい文字列に直します
4. 要約を原文と見比べる … 見出しと要約が発表の中身からずれていないかを読みます
5. 事務局長が確定させる … 会員への勧めを書き足すのはこの段階です

3番目を省かないでください。 会員が会報から拾うのは日付です。要約の文章が少し硬いことより、日付が1つ違うことのほうがはるかに重いので、印の付いたものから先に見ます。

目標は、120本をならして1本5分です。 載せないと決めた行は題名と要約を読んで数十秒で終わり、載せる行は原文と見比べるので数分かかります。not_in_source が多い月は、本文の取り方（タグの除去）がうまくいっていない可能性があります。

例外に対処する

上から3行目まで、本文を取る段階の問題が大半を占めます。 取れなかったものを黙って飛ばさず、行に理由を残します。

4行目は、気づかないと月末まで続きます。 一覧のページの作りが変わると、エラーにならずに題名が0件のまま毎朝終わります。0件の日が続いたら止まっていると見なし、担当者に知らせます。

記録を残す

• 候補の一覧の全行（題名、URL、種別、取得日、利用ルールの確認結果）
• 取得した本文と、取得日時。要約したときに見ていた本文がそのまま残るように
• Gemini API の出力のJSONと、突き合わせの結果（not_in_source の有無）
• 担当者が直した後の要約と、直した人
• 載せる・載せないの印と、事務局長が確定させた原稿の版
• 配信したPDFと配信日

2つ目で本文を残すのは、発表のページが後から変わるためです。 訂正や差し替えでページが変わると、会報に書いたことの根拠が後から確かめられなくなります。 会員から「会報の日付が違う」と言われたとき、当時のページに何が書かれていたかを示せます。

4つ目は、決まりを育てる材料です。 毎回同じ直しをしているなら、決まりに足します。