社内システムが使うOSSのライブラリのリリースをエージェントが毎週見回り、影響のある変更・サポート終了・必要な対応を開発の担当に届ける

処理の起点を決める

毎週月曜の朝6時に、Schedule Trigger で動かします。 各チームの週の計画の前に届けるためです。週1回にするのは、毎日届けると当番が読み切れず、まとめて読むことになるからです。ただし、実行環境のサポート終了の日付だけは、終了の90日前・30日前に当たる週に必ず出します。

Schedule Trigger は、ワークフローのタイムゾーンが無ければ n8n のインスタンスのタイムゾーンを使い、セルフホストの既定は America/New York とされています。ワークフローのタイムゾーンを Asia/Tokyo にし、保存して公開します。公開しないと Schedule Trigger は動かないとされています。週の間隔では、曜日と時刻を選べます。

このワークフローが止まったことに、人が気づける仕組みを必ず作ります。 実行が終わったら、新しいリリースがゼロでも「今週の見回り完了（新しいリリース 0件・台帳のリポジトリ 40）」を出します。通知が来ないこと自体が、止まった合図になります。 第3章の（a）は、ここで解きます。

入力データを集める

質を決めるのは、監視の対象表です。 SBOM に載るのはパッケージの名前で、そのパッケージのリリースがどの GitHub のリポジトリに出るかは、SBOM からは決まりません。 対象表に「パッケージ名 → リリースを出すリポジトリ」の対応を持たせ、重さの区分（フレームワーク・接続・認証など、必ず中身を見るもの）を付けます。

GitHub の Releases を使っていないライブラリは、対象表に変更履歴のファイルのURLを持たせて取ります。 取り方が決まっていないものは「取得方法なし」と書き、対象外の件数を毎週の完了の通知に出します。

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

GitHub の API の回数に気をつけます。 認証の無い呼び出しは1時間に60回、GitHub App のインストールのトークンでは最低5,000回とされています。認証無しでは足りないので、読み取りだけの権限を持つ GitHub App のトークンで呼びます。

コードの検索は、もっと厳しい制限があります。 公式の説明では、コードの検索は認証が必須で、1分に10回までです。さらに、既定のブランチだけが対象で、384KB より小さいファイルだけが検索できるとされています。HTTP Request の Batching で、1回に送る件数と次の送信までの待ち時間を決め、検索は1分に10回を超えないように間を空けます。

SBOM の生成は、40のリポジトリを順に回します。 generate-report で生成を始め、結果が取れるまで待ってから fetch-report を取ります。取れなかったリポジトリは、前週の台帳を使わず「今週は台帳を作り直せなかった」と通知します。

AIへ渡す前に整形する

1. パッケージ名をそろえる … npm のスコープ付きの名前、PyPI の大文字・小文字、区切りの - と _ を同じ規則でそろえ、対象表と SBOM の両方に当てます
2. 版の幅を出す … 台帳の版と新しいリリースの版を比べ、大きな版・小さな版・修正の版のどれが上がったかを機械で出します。エージェントに版の比較をさせません
3. プレリリースを分ける … prerelease が true のものは、重さの区分が「必ず見る」のライブラリだけを残し、他は件数だけにします
4. 飛ばした版を束ねる … 台帳の版から新しい版までの間に複数のリリースがあれば、その間の本文をまとめて渡します。最新の1件だけを読むと、間の版の破壊的変更を落とします
5. 本文の長さを確かめる … コミットの一覧だけで長すぎる本文は、見出し（Breaking、Deprecated、Removed など）の付近を先に切り出し、残りは要約の対象にしません
6. 実行環境の期日を計算する … eolFrom から今日までの日数を機械で出し、90日以内・30日以内の印を付けます

4番目が、この構成でいちばん効く前処理です。 台帳の版が 4.2 のまま、4.3、4.4、5.0、5.1 と出ていたら、5.0 の本文に書かれた破壊的変更を読まないと、5.1 への更新で何が壊れるかが分かりません。

AIに処理させる

させるのは、リリース1件（または束ねた数件）ごとに、変更を種類別に取り出し、依存の台帳とコードの検索を引いて、影響するリポジトリと対応の候補を挙げることです。

検索の言葉をエージェントに決めさせるのが、第4章の③への答えです。 本文に「foo() は次の大きな版で削除」とあれば foo( を検索し、当たったパスを返させます。検索の言葉は本文に書かれた名前に限り、推して作らせません。

1行目が、この構成でいちばん大事な線です。 コードの検索で当たらなかったとき、エージェントは「使っていない」と書きたくなります。動的に名前を組み立てて呼んでいる箇所、別のブランチで開発中の箇所、大きな生成ファイルの中は、検索に出てきません。

指示内容を固定する

AI Agent ノードの System Message に、次のように書きます。

あなたは社内システムの情報システム部で、依存しているOSSのライブラリの
新しいリリースを読み、社内のリポジトリへの影響を調べる担当です。
入力は、ライブラリ名、台帳の版、新しい版、版の上がり方（major / minor / patch）、
その間のリリースの本文です。

【やること】
1. 本文から変更を取り出し、種類を breaking / deprecation / removal /
   runtime_requirement / default_change / other から選ぶ。
2. 各変更について、根拠にした本文の文をそのまま evidence に写す。
3. 非推奨・削除になった関数・設定・オプションの名前が本文にあれば、
   それを検索の言葉にして、社内のコードを検索する。
4. 依存の台帳を引き、このライブラリを使っているリポジトリ、いまの版、
   担当チームを挙げる。
5. 過去の判断の記録を引き、同じライブラリの前回の判断を添える。
6. 本文に移行の手順が書かれていれば、そのまま migration_note に写す。

【厳守事項】
- 本文に書かれていない変更を書かないでください。
- 検索の言葉は、本文に書かれた名前だけにしてください。推して作らないでください。
- コードの検索で当たらなかったときは、usage を not_found にしてください。
  「使っていない」「影響なし」と書かないでください。
- 検索ができなかったとき（回数の上限、エラー）は usage を unknown にしてください。
  unknown を not_found にしないでください。
- 更新すべきか、いつ更新すべきかを書かないでください。
- 版の大小を自分で比べないでください。入力の版の上がり方を使ってください。
- 脆弱性の深刻度を評価しないでください。本文に脆弱性の修正があれば、
  種類を other にし、check_points に「脆弱性の修正の記載あり」と書いてください。
- 本文が英語なら、summary_ja は日本語で、evidence は原文のまま写してください。

【出力】指定のJSONの形で返してください。

「unknown を not_found にしない」が、この指示の要です。 検索が回数の上限で止まったリポジトリは、使っているかどうかが分かりません。分からないものを「見つからなかった」と書かせると、人が確かめる候補から落ちます。 3つの値を分けておけば、後段の規則で unknown を必ず人の確認に回せます。

出力形式を固定する

Structured Output Parser で、次の形のJSONを返させます。

{
  "package": "", "repo": "", "from_version": "", "to_version": "",
  "bump": "major | minor | patch",
  "release_ids": [""],
  "changes": [
    { "type": "breaking | deprecation | removal | runtime_requirement | default_change | other",
      "summary_ja": "", "evidence": "", "search_terms": [""] }
  ],
  "affected": [
    { "repository": "", "current_version": "", "team": "",
      "usage": "found | not_found | unknown",
      "hits": [ { "path": "", "count": 0 } ] }
  ],
  "migration_note": "",
  "previous_judgment": "",
  "check_points": [""]
}

1つ目の理由は、急ぎの度合いを規則で決められることです。 ワークフローが次の規則で付けます。

2つ目は、affected をチームごとに分けて届けられることです。 各チームのリポジトリと使用箇所だけを付けて届き、第3章の（d）はここで解けます。

3つ目は、evidence で確認が速くなることです。 当番は要約ではなく原文の該当の文を読んで判断できます。要約が原文とずれていたら、evidence を見ればすぐ分かります。

システムへ連携する

GitHub App の権限は、読み取りだけにします。 リポジトリの内容と依存関係グラフの読み取りがあれば、この構成は動きます。プルリクエストや課題を作る権限を持たせると、エージェントの判断が誤ったときに、リポジトリに跡が残ります。

エージェントの道具には、読み取りの操作だけを渡します。 判断の記録への書き込みは、エージェントの出力を受け取ったあとにワークフローの側で行います。Anthropic Chat Model ノードでは、生成の長さの上限や温度などを決められます。取り出しの仕事なので、温度は低くします。

人が確認する

1. 至急から見る … 実行環境のサポート終了が30日以内のものは、基盤の担当が移行の計画を確かめます
2. 今週の候補を確かめる … evidence を読み、found のパスを開いて使い方を見ます。unknown のリポジトリは、当番が自分で検索し直します
3. 起票を決める … 対応が要るものを課題管理に起票します。起票は人が行います
4. 記録のまとめを流し見る … 名前を見て、中身を確かめたいものがあれば本文を開きます
5. 判断を記録する … 対応する・しない・様子を見る、と理由を判断の記録に残します

2番目の unknown を省かないでください。 上限で止まったリポジトリは、調べられなかっただけです。

目標は、1件をならして3分です。 記録のものは名前を見るだけで済み、今週の候補は使用箇所を開いて10分を超えることがあります。

例外に対処する

7行目で、スキーマに合わない出力を「今週」で回すのは意図してのことです。 取り出しができなかったリリースは、影響の有無が分からないという意味で、確かめるまでは重く扱います。Tools Agent の Max Iterations は、モデルが答えを出そうとして回る回数の上限で、既定は10とされています。

記録を残す

• 実行ごとの SBOM の取得の成否と、台帳の差分（増えた依存・消えた依存・版の変化）
• 取ったリリースの識別子と本文
• エージェントのJSON出力と、呼んだ道具の順番（Return Intermediate Steps で残す）
• 人の判断 … 対応する・しない・様子を見る、理由、起票した課題、判断した日時
• リリースの公開日、見回りで拾った日時、起票した日時、更新を終えた日時

最後の行が、この構成の物差しです。 公開から起票までと起票から更新までを分けて並べます。