海外の業界メディアのニュースを毎朝集めて日本語に訳して要約し、自社の事業に関係の深い記事だけを経営企画のチャットに配る

処理の起点を決める

平日の朝6時に1回動かします。 Make のスケジュールは、一定間隔・毎日（複数の時刻を指定できる）・平日・週次・月次・日付指定・オンデマンドから選べます。「平日」で6時を指定し、始業前に配信が出ている状態にします。

新しい記事が出るたびに動かす形にはしません。 1件ずつ Teams に流すと、チャネルが一日中鳴り続け、事業部長がまとめて読む時間に読めなくなります。 朝に1本の投稿へまとめることが、読まれるための条件です。

月曜の朝だけは、取り出す範囲を土日を含む3日分にします。 欧米の媒体は週末にも記事を出します。Retrieve RSS Feed Items の Date from に「前回の実行の日時」を渡しておけば、曜日を意識せずに抜けなく取れます。前回の実行の日時は、記事ログの最終行から取ります。 シナリオが失敗した日があっても、翌日の実行が前回の成功から取り直します。

入力データを集める

質を決めるのは事業キーワード表です。 列は事業部ごとに「製品群」「顧客の業界」「競合」「規格・規制」「除外したい語」の5つにします。最後の「除外したい語」が効きます。 同じ略語が別の業界で別の意味に使われる場合や、社名が一般名詞と同じ綴りの場合に、ここで外します。

要旨は、媒体がRSSに載せている説明文をそのまま使います。 媒体によって、1文だけのものも、本文の冒頭の数段落が入っているものもあります。本文を取りに行かないので、要旨が短い媒体の記事は判定の材料が少なくなります。 その媒体は、媒体の一覧で優先度を下げるか、判定で迷ったら「中」に倒す扱いにします。

用語集は、訳のゆれを止めるために持ちます。 競合の社名をカタカナにするか原綴りのままにするか、規格名を訳すか、を決めておかないと、同じ会社が日によって別の名前で配信されます。 検索もできなくなります。

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

事業キーワード表と用語集は、記事ごとに読み直しません。 シナリオの最初に1回読み、文字列にしておいて全記事の指示に差し込みます。記事ごとに読むと、1日100件の記事で同じシートを100回引くことになります。

処理済みの判定は、リンクで行います。 同じ記事が見出しを直して再配信されることがあり、見出しで照合すると二度訳します。リンクの末尾の追跡用のパラメータ（?utm_ で始まる部分）を落としてから照合します。 落とさないと、同じ記事が別のリンクとして扱われます。

1回の実行で返す記事の上限は、媒体ごとに30件程度にします。 RSS アプリの説明どおり、大きくしすぎると相手側でタイムアウトが起きることがあります。上限に達した媒体は記事ログに印を付け、翌日の実行で残りを取ります。

AIへ渡す前に整形する

1. HTMLの除去 … 要旨にHTMLのタグや画像の参照が入っている媒体があります。タグを外し、文字だけにします
2. 長さの切り詰め … 要旨が本文の数段落ぶんある媒体は、先頭の600字程度で切ります。関係の判定に要るのは冒頭だけです
3. 広告・定型文の除去 … 「この記事は○○に最初に掲載されました」「購読はこちら」のような定型の末尾を、媒体ごとの決まり文句の一覧で落とします
4. 言語の確認 … 媒体の一覧の言語の列を指示に渡します。英語以外の媒体（ドイツ語・中国語など）が混ざっても、同じ指示で訳せます
5. リンクの正規化 … 追跡用のパラメータを落とし、記事ログとの照合に使います
6. 同じ話題の束ね … 同じ発表を複数の媒体が報じることがあります。この段階では束ねず、判定の後で同じ会社・同じ日の記事を並べて表示します

2番目の切り詰めは、費用のためだけではありません。 長い要旨をそのまま渡すと、AIが本文の細部まで要約に入れ、「要旨の訳」ではなく「記事の翻訳」に近いものが配信に乗ります。 配るのは要旨までという線を、入力の側で守ります。

AIに処理させる

させるのは、見出しと要旨の訳と、事業キーワード表に照らした関係の判定です。

理由を「当たった語」で書かせるのが要点です。 「市場動向として重要」のような理由は、確かめようがありません。事業キーワード表のどの語と、記事のどの語が対応したかを書かせれば、外れたときに表のどこを直すかが分かります。

1行目がいちばん起きやすい失敗です。 見出しに社名があると、AIはその会社について知っていることを要約に混ぜます。要旨に書かれていない話が日本語の要約にだけ載り、読んだ人はそれを記事の内容だと受け取ります。

指示内容を固定する

あなたは産業機械の部品メーカーの経営企画部で、海外の業界ニュースを社内に配る担当です。
RSSの見出しと要旨だけを見て、日本語に訳し、自社の事業との関係を判定してください。

【やること】
1. 見出しを日本語に訳す（title_ja）
2. 要旨を2〜3文の日本語にする（summary_ja）
3. 事業キーワード表に照らして、関係の深さを決める（relevance）
4. 関係する事業部を選ぶ（business_units）
5. 当たった語を書く（matched_terms）
6. 記事の種類を選ぶ（category）

【relevance の選び方】
- high ..... 事業キーワード表の「競合」「主要顧客の業界」「規格・規制」の語が、
             記事の主題として出てくる
- medium ... 表の語が出てくるが、記事の主題ではない。または要旨が短く主題が分からない
- low ...... 業界の話だが、表のどの語にも当たらない
- none ..... 業界と関係が無い。または「除外したい語」にだけ当たる
迷ったら low ではなく medium にしてください。

【厳守事項】
- 要旨に書かれていないことを summary_ja に足さないでください。
  会社について知っていることを補わないでください。
- 社名・製品名・規格名は用語集の表記にそろえてください。
  用語集に無いものは原綴りのまま残してください。カタカナにしないでください。
- 金額・数量・日付・割合は、要旨の数字と単位をそのまま写してください。
  通貨や単位を換算しないでください。
- 自社にとって良い話か悪い話かを書かないでください。
- matched_terms には、事業キーワード表の語と、それに対応した記事の語を
  組にして書いてください。当たった語が無ければ空の配列にしてください。
- 要旨が空、または見出しと同じ文だけの場合は、summary_ja を空にし、
  relevance は見出しだけで判断して、note に「要旨なし」と書いてください。

【媒体】{source_name}（言語：{language}）
【見出し】{title}
【要旨】{description}
【事業キーワード表】{business_terms}
【用語集】{glossary}

「用語集に無いものは原綴りのまま」を明記しないと、AIは社名をカタカナにします。 カタカナの社名は検索に引っかからず、同じ会社が別の記事で別の書き方になります。 原綴りのままのほうが、読む人も記事ログで探す人も迷いません。

「迷ったら medium」を書くのは、落とすほうの失敗が重いからです。 「中」の記事が多少増えても読む側で飛ばせますが、「低」に落とした記事は配信に乗らず、誰の目にも触れません。

出力形式を固定する

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

{
  "link": "https://example.com/news/...",
  "source_name": "",
  "published_at": "",
  "title_ja": "",
  "summary_ja": "",
  "relevance": "high | medium | low | none",
  "business_units": ["第1事業部"],
  "matched_terms": [
    { "term_in_list": "", "term_in_article": "" }
  ],
  "category": "new_product | partnership_mna | plant_investment | regulation_standard | earnings_market | people | other",
  "note": ""
}

1つ目の理由は、relevance で配信と記録を分けられることです。 high と medium は配信に、全件は記事ログにと、後段の分岐を Make のフィルターだけで書けます。 自由文で「関係あり」と返されると、表現のゆれで分岐が崩れます。

2つ目は、business_units で事業部ごとにまとめられることです。 Array aggregator の Group by に事業部を指定すると、事業部の値ごとに1つのまとまりが出ます。 これを並べて1本の投稿にします。複数の事業部に当たった記事は、それぞれの見出しの下に出ます。

3つ目は、matched_terms が表の手入れの材料になることです。 週1回の見直しで落とした記事が見つかったとき、その記事の matched_terms が空なら表に語が無い、語があるのに low なら指示の書き方の問題、と切り分けられます。

Teams への投稿は次の形にします。

【海外業界ニュース 10/8（水）】高 4件・中 6件　（全 87件中）

■ 第1事業部
［高］〈媒体名〉見出しの訳
　要旨の訳（2〜3文）
　当たった語：競合 Example Corp ／ 規格 ISO 0000
　元の記事 → リンク

■ 第2事業部
…

記事ログ（低・なしを含む全件）→ シートへのリンク

先頭の行に「全何件中」を入れます。 配信に乗らなかった記事があることを、読む人が毎朝目にします。気になる人は記事ログを見に行けます。

システムへ連携する

媒体のサイトには、RSSを読む以外のことをしません。 本文のページを取りに行かず、ログインの要る有料の記事にも入りません。本文を自動で取りに行く機能を後から足したくなったら、その媒体の利用規約と購読の契約を先に確かめてください。

Teams への投稿は、配信用のアカウントから出します。 担当者の個人のアカウントで接続すると、その人の異動や退職でシナリオが止まります。

人が確認する

投稿は確認を待たずに出します。 配るのは公開されている記事の見出しと要旨の訳で、誤りがあっても元の記事へのリンクで確かめられます。その代わり、確認は3つの場面に置きます。

1. 始業時の流し見（毎日） … 担当者が投稿を読み、固有名詞の訳がおかしい記事、場違いな記事があればスレッドに訂正を書きます。投稿そのものは消さず、訂正を返信で残します
2. 落とした記事の見直し（週1回） … 記事ログで low と none の見出しを流し見します。1週間で数百件ありますが、見出しの訳を読むだけなので短く済みます
3. 事業キーワード表の手入れ（週1回） … 2番目で落とした記事が見つかったら、その記事に出てくる語を表に足します。事業部から「この話も拾ってほしい」と言われた語も足します

2番目を省かないでください。 選別の外れは、配信された側からは見えません。「低」に落ちた記事は誰も読まないので、見に行かない限り外れていたことが分かりません。

事業部長が投稿に返信で質問したときは、担当者が元の記事を読んで答えます。 AIの要約を根拠に答えないでください。

例外に対処する

最後から2行目を軽く見ないでください。 投稿が無い朝は、「関係の深い記事が無かった」のか「シナリオが止まった」のかが区別できません。0件の日も必ず投稿し、止まったことに気づける状態にします。

構造化出力は、応答が refusal や max_tokens で止まったときにはスキーマに沿わないことがあるとされています。Make のフィルターで relevance が4つの値のどれでもない記事を拾い、判定失敗として扱います。

記録を残す

• 記事ログ（全件） … リンク、媒体名、公開日時、原文の見出し、見出しと要旨の訳、relevance、business_units、matched_terms、配信の有無
• 事業キーワード表の変更履歴 … いつ、誰が、どの語を足したか、どの記事がきっかけか
• 投稿への訂正 … Teams のスレッドの返信として残る。週1回、記事ログの該当行に「訂正あり」の印を付ける
• 取得失敗と判定失敗の記録 … 媒体ごとの件数

原文の見出しも記事ログに残します。 訳だけを残すと、後で同じ記事を媒体のサイトで探すときに手がかりがありません。

2つ目の変更履歴は、選別の基準が担当者の頭から表に移った記録です。 担当が替わっても、何の語がなぜ足されたかが追えます。