使っているSaaSの仕様変更と提供終了の告知を毎週巡回して、影響を洗い出す

処理の起点を決める

毎週月曜の決まった時刻を起点にします。週の初めに一覧が届き、その週のうちに対応を決められる形にします。

日次にしないでください。 告知の頻度に対して過剰です。毎日通知が届くと読まれなくなります。週1回で、見落としが致命的になるほど急な変更はまれです。

ただし例外があります。障害・緊急メンテナンスの告知は、週1回では遅すぎます。 これは別の経路（サービスのステータスページの監視）で扱ってください。この構成の対象は、計画された変更です。

もう1つの起点として、利用部門から「使えなくなった」という連絡が来たときに、そのサービスの告知を臨時に巡回する形が考えられます。原因が仕様変更かどうかを、すぐ確かめられます。

入力データを集める

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

SaaS管理台帳が、この構成の土台です。 台帳がなければ何も始まりません。次の項目を必ず持ってください。

「使っている機能」の把握が、もっとも手間のかかる準備です。 45サービスすべてについて詳細に書く必要はありません。主要な5〜10機能を書くだけで、除外の精度が大きく上がります。

告知の取得は3通りに分かれます。

Web での取得には限界があります。 ログインが必要なページ、JavaScriptで描画されるページは取得できません。取得できないサービスは台帳に印を付け、担当者が手で見る対象として残してください。 全部を自動化しようとしないことが、この構成では重要です。

AIへ渡す前に整形する

1. 巡回対象の絞り込み … 契約が終了したサービス、試用中で本番利用していないサービスを除きます
2. 告知の場所の確認 … URLが変わっていないかを月1回確かめます。リリースノートのURLは移動します
3. 既読の判定 … 前回の巡回で取得した告知のURLと見出しを保持し、新規のものだけを残します
4. 告知の言語 … 英語のみで出るサービスがあります。翻訳してから判定するか、原文のまま判定させるかを決めます
5. 重複の統合 … 同じ変更が、リリースノートとメールの両方で告知されることがあります。サービス名＋変更の日付＋見出しで突合します

AIに処理させる

影響の「大きさ」までは判定させません。 「業務が止まる」かどうかは、その機能を実際にどう使っているかで決まります。告知の文面からは分かりません。 出せるのは「自社が使っている機能に関係する変更である」までです。

対応の可否や代替サービスの提案もさせません。 「別のサービスへの移行を推奨します」といった記述を書かせないでください。

指示内容を固定する

あなたは情報システム部のSaaS管理を支援する調査担当です。
下のサービスについて、指定した場所から新しい告知を探し、
自社への影響を判定してください。

【調査の範囲】
- 下の「告知の場所」に含まれるページのみを対象にしてください。
- 検索は最大 {max_searches} 回までにしてください。
- 下の「前回までに取得済みの告知」に含まれるものは除外してください。

【厳守事項】
- 取得したページに書かれている内容だけを根拠にしてください。
  そのサービスについての知識で補わないでください。
  **特に、日付・プラン名・機能名を記憶から書かないでください。**
- 各告知には、必ず出典のURLと、告知の掲載日（分かる場合）を付けてください。
  出典のない告知を載せないでください。
- 変更の種類を、下の区分からのみ選んでください。判断できない場合は "その他" とし、
  理由を書いてください。
- 影響の判定は、下の「自社の契約プラン」と「使っている機能」に照らして行ってください。
  - 使っていない機能の変更は impact を "none" にしてください。
  - 契約していないプランのみの変更も "none" にしてください。
  - 判断に必要な情報が告知から読み取れない場合は "unknown" にしてください。
    **迷ったときに "none" にしないでください。見落としにつながります。**
- 期限（変更日、対応期限）は、告知に明記されている場合だけ書いてください。
  「近日中」「今後」といった表現を日付に変換しないでください。
- 必要な対応は、告知に「管理者が行う」と書かれていることだけを写してください。
  自分で対応案を考えないでください。
- 代替サービスの提案、移行の推奨を書かないでください。判断は情報システム部が行います。
- 影響の大きさ（業務が止まる、軽微 など）を評価しないでください。

【サービス】
{service_context}

【告知の場所】
{notice_urls}

【自社の契約プラン】
{plan}

【使っている機能】
{used_features}

【連携しているシステムと使っているAPIの版】
{integrations}

【前回までに取得済みの告知（URLと見出し）】
{known_notices}

「迷ったときに none にしない」の1行が、この構成でもっとも重要です。 見落としを防ぐことがこの業務の目的なので、判断に迷うものは人へ回すほうが正しい設計です。 none を多く出すほど確認は楽になりますが、その分だけ見落としの危険が増えます。

「日付・プラン名・機能名を記憶から書かない」も必須です。 サービスの仕様は変わります。モデルが学習した時点の情報で「Enterpriseプランでは既定で有効です」と書かれると、それが事実かどうか確かめようがありません。 取得したページに書かれていることだけを使わせます。

出力形式を固定する

{
  "service_name": "",
  "crawled_at": "",
  "notices": [
    {
      "title": "",
      "url": "",
      "published_on": "",
      "change_type": "機能追加 | 仕様変更 | 提供終了 | 価格改定 | 障害・メンテナンス | その他",
      "target_plans": [],
      "target_features": [],
      "target_regions": [],
      "effective_date": "",
      "action_deadline": "",
      "admin_action_required": "",
      "impact": "affected | none | unknown",
      "impact_reason": "",
      "integration_impact": "",
      "excerpt": ""
    }
  ],
  "crawl_status": "ok | partial | failed",
  "crawl_note": "",
  "searches_used": 0
}

JSON Schema を指定して出力を固定します。OpenAI API の Structured Outputs は text: { format: { type: "json_schema", "strict": true, "schema": … } } の形で指定し、strict: true にすると、供給したJSONスキーマに必ず沿った応答が返ります。 必須項目の欠落や、スキーマにない項目の混入が起きなくなります。

crawl_status を必ず持たせてください。 ログインが必要で取得できなかった、ページの構造が変わって読めなかった、といったことが起きます。取得できなかったことを「告知がなかった」と誤読すると、見落としになります。

excerpt には、判定の根拠になった原文を入れます。 「Enterpriseプランのみが対象」と判定したなら、その記述を抜き出します。担当者が確認するとき、ページを開かずに済みます。

システムへ連携する

変更一覧を Microsoft Lists に作ります。1告知1行です。

impact が none のものも、この一覧に残します。 ただし既定では非表示にし、必要なときだけ見られるようにします。「見落としたのか、判断したのか」を後から区別するためです。

期限のあるものは、タスクとして登録します。 「2027年3月31日に提供終了」という告知は、記録しただけでは忘れます。期限の3か月前、1か月前、2週間前に通知が届く形にしてください。

利用部門への連絡は、人が行います。 「◯◯の機能が変わります」という通知を自動で全社へ流すと、関係のない人まで読むことになります。誰に伝えるべきかは、利用状況を知っている情報システム部が決めます。

人が確認する

affected と unknown は全件、none は抜き取りで確認します。

none を全件確認すると、この構成の効果が消えます。ただしまったく見ないのも危険です。月に1回、none の中から20件を無作為に選んで、判定が妥当かを確かめてください。 誤って none にされているものが見つかれば、プロンプトか台帳の「使っている機能」を直します。

確認を速くするための設計が効きます。

• change_type が「提供終了」のものを最上部に固定する
• integration_impact に記述があるものを次に出す（連携の停止は影響が大きい）
• action_deadline の近い順に並べる
• impact が unknown のものを別に集める
• crawl_status が partial または failed のサービスを別に集める（取得できていない = 見えていない）
• excerpt を一覧上に表示する（ページを開かずに判断できる）

5つ目が見落としの温床です。 取得に失敗したサービスが毎週同じなら、そのサービスは実質的に巡回できていません。台帳に「手動確認」の印を付けて、担当者が月1回見る対象にしてください。

例外に対処する

記録を残す

この記録は、対応の遅れが起きたときに経緯を追う材料になります。

• 巡回した日時と、サービスごとの crawl_status
• 取得した告知の全件（none のものも含む）
• 影響の判定と、その根拠の引用
• 情報システム部の判断と、実施した対応
• 期限のあるものの、期限と対応日
• 台帳の「使っている機能」の更新履歴

crawl_status の履歴が重要です。 「このサービスは3か月間、一度も取得できていなかった」と分かれば、見落としの原因が特定できます。判定の誤りより、そもそも見ていなかったことのほうが多いはずです。

none と判定した告知を残すことも省かないでください。 後から問題が起きたとき、「告知は取得していたが影響なしと判断した」のか「そもそも取得できていなかった」のかで、直すべき場所が変わります。