業務で使う海外SaaSの英文のリリースノートを毎週訳し、社内への影響と対応の要否を部署別の要点にまとめて配る

処理の起点を決める

毎週月曜の朝を起点にします。 Apps Script のインストール型トリガーのうち、時間主導型トリガーを使い、「毎週月曜 9時」のように設定します。公式ドキュメントでは、9時に設定すると9時から10時の間のどこかで動き、その時刻は以後そろうとされています。配る時刻を分単位で決めたい場合は、配信だけを別の手順にします（本構成では第5章の8番目が人の操作なので、ここは問題になりません）。

週1回にするのは、毎日動かすと確認の一覧が細切れになるからです。 週の最初にまとめて作り、その週のうちに配ります。

トリガーは、作った人のアカウントで動きます。 担当者個人のアカウントで作ると、その人が異動したときに止まります。情報システムの共用のアカウントで作り、失敗したときの通知メールもそこに届くようにします。 Apps Script は、トリガーが失敗すると実行の詳細を書いたメールを送るとされています。

入力データを集める

質を決めるのは、2行目の「部署ごとの使い方」です。 「営業：商談の記録と見積の作成に使う。ゲストは使わない」のように、部署ごとに使っている機能を1〜2文で書きます。 ここが空だと、影響する部署を決める材料がなく、全部の項目が「全社」になります。

用語集には「訳さない語」の列を持たせます。 製品名、機能名、画面の表記のうち、英語のまま使っているものを並べます。 社内で「ワークスペース」と呼んでいるものは、訳語の列に書きます。

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

フィードの取得は、まとめて送ります。 UrlFetchApp には、複数のURLへのリクエストをまとめて送り、それぞれの応答を配列で返す fetchAll があります。muteHttpExceptions を有効にすると、失敗の応答でも例外で止まらずに応答が返るとされています。15サービスのうち1つのサイトが落ちていても、残りの14サービスは処理を続けられます。

UrlFetchApp のリクエストは一定のIP範囲から送られるとされています。接続元を絞っている環境では、その範囲を許可します。

URL コンテキストで読んだページは、取得の結果が返ります。 レスポンスには、URLごとに取得できたかどうかの状態が含まれるとされています。取得に失敗したURLの項目を「今週は新しい項目なし」として扱わないよう、状態を必ず確かめます。

AIへ渡す前に整形する

1. 新しい項目の選び出し … 処理済みの一覧と、項目のURLと見出しで照合し、新しいものだけを残します
2. 項目への分割 … 1つの投稿に複数の変更が箇条書きで並ぶものは、箇条ごとに分けます
3. 公開日の確認 … 2週間より前の公開日の項目は、処理済みの一覧に漏れがないかを確かめてから扱います
4. 販促の文の除去 … 導入事例、イベントの告知、ブログ記事の紹介は、変更の項目から外します
5. 台帳の付与 … サービスごとに、契約プラン、使う部署、部署ごとの使い方を付けます
6. 用語集の絞り込み … そのサービスの行だけを取り出して渡します
7. 原文の保持 … 訳す前の原文と項目のURLを、確認用の一覧のために残します

2番目を省くと、1つの投稿の中の廃止の予告が、新機能の紹介に埋もれます。 「New features this week」の見出しの下に、最後の1行だけ「The legacy API will be retired」と書かれている、という形はよくあります。箇条ごとに分ければ、その1行が1件として仕分けられます。

6番目で用語集を絞るのは、別のサービスの訳語を当てはめるのを防ぐためです。

AIに処理させる

させるのは、項目ごとに次の6つを埋めることです。

適用の時期と条件を、訳文とは別に原文の語句で写させるのが要です。 「in the coming weeks」を「数週間以内に」と訳すのは正しくても、訳文だけを読むと、日付が決まっているかのように読めることがあります。 原文の語句を並べておけば、担当者が確かめるときに一目で分かります。

影響する部署は、根拠の語と一緒に返させます。 「営業」と返すなら、台帳の営業の行の「見積の作成」に当たった、という語を添えさせます。根拠の無い割り当ては、担当者が確かめられません。

1行目がいちばん起きやすい失敗です。 「starting next month」と書かれた項目に、公開日から計算した日付を入れます。それらしい日付が一覧に並ぶと、担当者はその日付で段取りを組んでしまいます。

指示内容を固定する

あなたは情報システム部門で、業務で使う海外SaaSのリリースノートを
社内の利用部署に向けて日本語にする立場です。
渡された項目と台帳と用語集だけを根拠にしてください。推測で補わないでください。

【訳し方】
- 用語集の「訳さない語」は英語のまま書いてください。
- 画面に表示される英語（メニュー、ボタン、設定の名前）は英語のまま書き、
  初出だけ括弧で日本語を添えてください。例：Workspace settings（ワークスペースの設定）
- 用語集に訳語がある語は、その訳語を使ってください。
- 利用部署の人が読む前提で、1項目を2〜3文で訳してください。
  開発者向けの細かい仕様（APIのパラメータ名など）は、訳文では省いてかまいません。

【change_type の選び方】
new_feature（新機能）／change（仕様変更）／deprecation（廃止・終了）／
bug_fix（不具合の修正）／admin_setting（管理者の設定）／pricing（料金・プラン）
どれにも当たらない、または決められないときは unknown にしてください。

【effective と conditions】
- 適用の時期は、原文の日付や語句をそのまま effective.source_text に写してください。
- 原文に具体的な日付があるときだけ effective.date に YYYY-MM-DD で入れてください。
  「next month」「in the coming weeks」から日付を計算しないでください。
- プラン、地域、既定で有効かどうかは、原文の語句を conditions に写してください。

【影響する部署】
- 台帳の「部署ごとの使い方」と突き合わせ、当たった部署を返してください。
- 部署ごとに、当たった根拠の語（台帳の語と原文の語）を evidence に書いてください。
- 台帳に無い部署名を作らないでください。全員に関係するときは all_users、
  決められないときは unknown にしてください。

【action の選び方】
- required ... 利用者の操作が変わる、機能が無くなる、設定を変えないと使えなくなる
- notify ..... 利用者に知らせたほうがよいが、何もしなくても使い続けられる
- none ....... 自社の契約プランや使い方では関係しない
- unknown .... 原文の情報だけでは決められない
迷ったときに none を選ばないでください。

【厳守事項】
- 原文に無い影響や評価（便利になる、改善される など）を書き足さないでください。
- 設定を変えるべきかの結論を書かないでください。action の候補と理由だけにしてください。
- 原文が英語以外のときは、訳さずに source_language にその言語を書いてください。

【項目】{release_items}
【台帳】{service_profile}
【用語集】{glossary}

「迷ったときに none を選ばない」を明記しないと、対応不要が増えます。 リリースノートの多くは本当に自社に関係ないので、何も言わなければ多数派の区分に寄ります。対応が要るものを対応不要に落とすほうが、逆より高くつきます。

「日付を計算しない」は、2か所で念を押します。 日付の欄に書かないよう求めても、訳文の中で「10月から」と書くことがあります。訳文と欄の両方で原文の語句を保たせます。

出力形式を固定する

次の形のJSONで受け取ります。

{
  "service": "",
  "items": [
    {
      "item_url": "",
      "title_ja": "",
      "summary_ja": "",
      "change_type": "new_feature | change | deprecation | bug_fix | admin_setting | pricing | unknown",
      "effective": { "date": "", "source_text": "" },
      "conditions": "",
      "departments": [
        { "name": "", "evidence": "" }
      ],
      "action": "required | notify | none | unknown",
      "action_reason": "",
      "source_language": "en"
    }
  ]
}

1つ目の理由は、区分を enum で固定できることです。 change_type と action は、スキーマで選択肢を決めておきます。「重要」「要確認」のような語が混ざらないので、区分ごとの並べ替えと配り分けがそのまま機械でできます。

2つ目は、effective を2つに分けられることです。 date は日付が書かれていたときだけ、source_text は必ず埋めます。date が空で source_text が「in the coming weeks」なら、日付は決まっていないということです。

3つ目は、値の検証を Apps Script で書けることです。 返ってきたJSONについて、次を確かめます。

2行目の検証が、上の「させないこと」の1行目を機械で止める仕組みです。 指示で禁じても日付を作ることはあるからです。

システムへ連携する

配信は、着信 Webhook で一方向に送ります。 公式ドキュメントでは、Webhook は外部のサービスからチャットのスペースへ一方向・非同期の通知を送るもので、利用者のメッセージに応答することはできないとされています。部署の人からの質問は、スペースの中で担当者が受けます。 Business または Enterprise の Google Workspace のアカウントが必要です。

1つのスペースに送れるのは、1秒に1件までです。 この上限はスペースの中の全 Webhook で共有されるとされています。部署ごとに要点を1通にまとめて送り、項目ごとに送りません。 1通にまとめるほうが、受け取る側も読みやすくなります。

サービスごとにスレッドを分けます。 Webhook では threadKey でスレッドを指定できるとされ、サービス名をキーにすれば、同じサービスの変更が週をまたいで1つのスレッドにたまります。 SaaSの管理画面には何も書き込みません。

人が確認する

確かめるのは、情報システムの担当者です。

1. required を先に見る … 原文と訳を並べ、effective.source_text と conditions を原文で確かめます。自社の契約プランで本当に当たるかを、台帳と照らします
2. unknown を片付ける … 区分と部署を担当者が決めます。決められないものは、ベンダーのヘルプを見に行く項目として残します
3. notify を流し見る … 部署の割り当てが合っているかだけを見ます
4. none は件数とサービスだけを見る … 1件ずつ開きません
5. 配信の印を付ける … 設定の変更が先に要るものは、変更の後に配ります

1番目を省かないでください。 「required」の項目は、部署の人に行動を求めます。プランの条件を読み違えた1件は、関係のない部署に操作を変えさせます。

目標は、60件をならして1件12分です。 required と unknown が2割前後という想定で、残りは流し見です。それより多い週は、台帳の「部署ごとの使い方」が薄いか、用語集が足りていません。

例外に対処する

1行目がいちばん大事です。 取得できなかったサービスが、一覧の上で「新しい変更なし」と同じに見えると、その週の変更は誰にも読まれないまま過ぎます。

4行目も同じ性質です。 フィードの形式が変わると、エラーにならずに項目が0件になります。3週続けて0件のサービスは、壊れているものとして扱います。

記録を残す

• 取得した原文と、取得の状態（成功・失敗・読めない）
• Gemini API に渡した項目、台帳、用語集の該当行
• 返ってきたJSONの全文と、検証で直した箇所
• 担当者が確定した区分と、AIの候補から変えた箇所
• 配信した日時、配信先のスペース、配信した文面
• サービスごとの required の件数の推移

4つ目は、指示文と台帳の改善の材料になります。 同じサービスで同じ種類の直しが続くなら、台帳の「部署ごとの使い方」か、用語集のどちらかに理由があります。

最後の行は、契約の見直しの材料になります。 required が毎月出るサービスは、運用が変更に振り回されているということです。