Releaseを取る工程と、『記事を直す変更か』を判断する工程を分けます。
APIのrelease IDを取得単位にし、通常版候補、prerelease、draftと意味上の同一版を別々に分類します。 変更がなければETagによる304を利用し、変更があれば公式リリースノートを人が確認します。取得したコードを自動実行したり、記事を自動公開したりはしません。
- 取得endpoint・版を固定
- 分類draft・pre・通常版
- 比較ID・tag・本文差分
- 判断人が記事へ反映
/latest、Release一覧、Git tagは同じ「最新版」ではありません。
GitHub REST APIには、1件のlatest releaseを取るエンドポイントと、Release一覧を取るエンドポイントがあります。さらにGitのtag一覧は別です。監視したい対象を決めずに「最新」と呼ぶと、prereleaseを見落としたり、Releaseが作られていないtagを混ぜたりします。
endpointはAPIの取得先、queryは件数などの条件です。この記事の「通常版」はdraft=falseかつprerelease=falseの候補を指し、stableというAPI項目はありません。後のtag_name=stableはn8n固有の名前です。
| 取得方法 | 含むもの | 含まない・注意するもの | 使いどころ |
|---|---|---|---|
/releases/latest | draftでもprereleaseでもないReleaseのうち、公式定義上のlatest | prerelease、draft。最高のSemVerとは限らない | 通常版の更新候補を1件見る |
/releases | アクセス権の範囲にあるRelease一覧 | Releaseと関連付かない通常のGit tag | 通常版とprereleaseを分けて比較する |
| Git tag一覧 | リポジトリのtag参照 | Release本文やdraft・prereleaseの編集区分 | Release未作成のtagも監視したい場合 |
/latestはGitHubがlatestとして返す通常Releaseです。公式GET説明にはcreated_atによる選択の記載がありますが、公開側にはmake_latestや「Set as latest release」で指定する機能もあります。監視側で日時やSemVerだけから再現せず、APIの返り値と公開側の方針を確認します。
公開リポジトリのReleaseは、認証なしで取得できるエンドポイントがあります。一方、非公開リポジトリや高い上限が必要な監視では権限を最小化した認証が必要です。公開情報の確認だけで、新しいOAuth接続や個人トークンを増やす必要はありません。
ID、tag、公開区分、3つの日付を別々に保存します。
比較に使う項目を先に決めると、同じRelease本文を何度も精読せずに変化を追えます。機械的な同一性と、編集上「同じ版か」を分けるのがポイントです。
id と tag_namerelease IDはAPI上のReleaseを識別する軸、tagは版名の候補です。同じ文字列だと仮定しません。
draft と prerelease公開前の下書きと、公開された先行版を分けます。安定版の読者へprereleaseを自動で勧めません。
created_at・published_at・updated_at対象commitの作成、Releaseの公開、Release本文等の更新を表す日時です。latestの判断に使われる日時と、読者へ公開された日時を混ぜません。
target_commitish対象branchやcommitの手掛かりです。同じ値でも同じReleaseとは限らず、重複除去キーにはしません。
タイトル、本文、URLは記事候補を理解するために使えますが、Release本文に書かれた機能が自分の環境で動く証明ではありません。互換性、料金、移行手順は、対象製品の公式ドキュメントと実環境で別に確認します。
公開APIを2回読み取り、200から304への変化を確認しました。
2026年9月18日8:09 JST、公開リポジトリn8n-io/n8nのRelease一覧をper_page=3で取得しました。API版は2026-03-10、認証なしのGETです。最初の応答のETagを付けて同じURLへ再取得すると、200から304へ変わりました。
自分の端末で、まず1回だけ読む
以下はmacOSなどcurlが使えるターミナル用です。公開情報を読み取るだけで、GitHubへの書き込み・通知送信・ソフトのインストールはしません。トークンは不要です。先にHTTP状態とヘッダー、その後にJSON配列が表示されるか確認してください。
curl --silent --show-error --include \
--connect-timeout 10 --max-time 20 \
--header 'Accept: application/vnd.github+json' \
--header 'X-GitHub-Api-Version: 2026-03-10' \
'https://api.github.com/repos/n8n-io/n8n/releases?per_page=3'| tag_name | release ID | prerelease | この時点の分類 |
|---|---|---|---|
stable | 390518107 | false | 移動名。具体版との対応は別確認 |
n8n@2.39.7 | 390518095 | false | 通常版候補 |
n8n@1.123.81 | 390526448 | false | 別系列の通常版候補 |
この3件だけでも、stableという名前と2.x・1.x系列が混在します。先頭を取るだけで「すべての利用者が入れるべき版」は決まりません。実装では取得時のID・URL・公開区分・日時を保存し、導入中の系列と公式リリースノートを照合します。
ETagと次ページを示すLinkも取得できました。認証なしの304を「回数を消費しない」とは扱いません。この確認は同じURLへの2回の読み取りまでで、全履歴・定期実行・通知・障害復旧は未検証です。
重複除去はrelease ID、意味上の統合は人間の確認へ分けます。
二重通知を防ぐだけなら、既に処理したrelease IDを記録する方法が基本です。一方、stableのような移動する名前と、具体的なバージョン名を1件にまとめる作業は、プロジェクトごとの公開方法を理解する必要があります。
| 比較 | 自動処理 | 人が確認すること |
|---|---|---|
| 同じrelease ID | 処理済みなら同じ通知を作らない | 公開後に本文が更新された場合の扱い |
| 同じtag_name、IDが違う | 自動統合せず要調査 | 削除・再作成、履歴、公式案内 |
| tagは違うが版・本文が近い | alias候補として並べる | プロジェクト固有のstable運用 |
| 同じtarget_commitish | 重複根拠にしない | 異なるReleaseが同じbranchを指す可能性 |
| prereleaseが新しい | 通常版と別キューへ | 先行版として紹介する価値と注意書き |
SemVerの数字だけで並べる処理も注意が必要です。すべてのリポジトリが同じ命名規則を使うとは限らず、v、製品名、日付、stableなどが混ざります。まずGitHubの公開区分を保存し、版の意味は対象プロジェクトの案内へ戻します。
ETagを保存し、同じ取得条件でIf-None-Matchを送ります。
一定間隔で全件を処理し直す代わりに、前回レスポンスのETagを保存し、次回の条件付きリクエストへ使えます。リソースが変わっていなければ304 Not Modifiedが返り、本文を解析する必要がありません。
2回目は、初回のETagをそのまま渡す
初回200のetag:の右側をコピーし、下の「ここを初回のETag全体へ置換」だけを書き換えます。W/や二重引用符も含めてコピーし、外側の一重引用符は残します。初回のJSONも手元に残してください。ETagがなければ、この試行はせず通常GETで比較します。
curl --silent --show-error --include \
--connect-timeout 10 --max-time 20 \
--header 'Accept: application/vnd.github+json' \
--header 'X-GitHub-Api-Version: 2026-03-10' \
--header 'If-None-Match: ここを初回のETag全体へ置換' \
'https://api.github.com/repos/n8n-io/n8n/releases?per_page=3'同じURL・件数・API版のまま実行し、304で本文が空なら初回のJSONを再利用します。間にReleaseが変われば200が返るので、そのJSONとETagを新しい組として扱います。これは手動の2回比較です。自動監視では、次節のfirstPageSnapshotに最後の成功したJSON配列を保存します。空配列も有効な応答で、未保存のnullとは別です。
- 初回200結果とETagを保存
- 次回GETIf-None-Matchを送る
- 304前回表現を再利用
- 200比較後に基準を更新
GitHubのベストプラクティスでは、正しく認証された条件付きリクエストが304になった場合、primary rate limitを消費しないと案内されています。ただし、ETagを付ければすべて無料・無制限という意味ではありません。URL、query、認証、API versionなど取得条件をそろえ、レスポンスの実ヘッダーを観測します。
304が示すのは「その条件で取得した表現が変わっていない」ことです。製品のWebサイト、通常tag、Issue、ドキュメントまで変更がないとは言えません。監視したい情報源ごとに対象を明記します。
URL、headers、保存状態、status分岐を1本のループにします。
以下は監視処理を実装するための疑似コードです。そのままターミナルへ貼るコードではありません。前節では3件の条件付きGETを確認しましたが、この100件監視ループや通知処理は実装していません。
未実行の疑似コード：先頭100件だけを条件付き取得
url = https://api.github.com/repos/{owner}/{repo}/releases?per_page=100&page=1
state = {
firstPageEtag, lastSuccessfulAt,
firstPageSnapshot, // 最後に200で読み終えたJSON配列。初回はnull
releaseById: { tagName, draft, prerelease, createdAt,
publishedAt, updatedAt, targetCommitish, bodyDigest, htmlUrl }
}
headers = {
Accept: application/vnd.github+json,
User-Agent: my-release-monitor,
X-GitHub-Api-Version: 2026-03-10,
If-None-Match: state.firstPageEtag // 保存済みの場合だけ
}
304 -> 保存済み本文があれば、確認成功時刻だけ記録
本文がなければ条件ヘッダーを外して取り直す
200 -> 配列として読み終えた後、IDごとにtag・draft・prerelease・
updated_at・本文digestなど保存した項目を比較
-> 比較成功後に、JSON配列・ETag・状態をまとめて保存
429 / rate-limit 403 -> Retry-Afterがあれば、その秒数待つ
なければremaining=0のときreset時刻まで待つ
それ以外は最低1分。再発時は指数的待機＋回数上限
401 / permission 403 / 404 -> 権限・URLを確認し、連打しない
HTTP応答なし -> DNS・TLS・timeoutを記録し、接続を切り分ける
5xx -> 上限付きで待って再試行
other / non-JSON -> 確認失敗。前回値を「変更なし」にしない
範囲外：101件目以降と、先頭100件から外れた過去Releaseの編集
禁止：取得したコードの実行、記事の自動公開、失敗時の基準上書き例では2026年9月18日にサポート中と確認した2026-03-10を指定しました。実装時もAPI versionと変更点を再確認し、URL、query、認証条件を前回とそろえます。
ETagは、同じURLとqueryで得る1つの表現に対応します。複数ページを追うならページごとの取得状態を管理するか、「新規Releaseは先頭ページ、過去Releaseの本文更新は別監査」のように監視範囲を明示します。
2回目の比較結果は、statusとrelease IDを組み合わせて決めます。
| 2回目の観測 | 比較結果 | 次の動作 |
|---|---|---|
304 | 同じ取得条件の表現は未変更 | 確認成功時刻だけ更新 |
200・同じID・保存した比較項目が一致 | 既知のRelease | 通知を増やさない |
200・同じID・比較項目に差分 | 公開後の編集・区分変更候補 | 本文やprerelease等の差分を人へ渡す |
200・新ID | 新Release候補 | prereleaseを分けて調査 |
429／制限による403 | 取得頻度の制限 | 待機情報に従い、基準を保持 |
権限403／404 | 権限または取得先の問題 | 自動再試行せず設定を確認 |
| HTTP応答なし | DNS・TLS・接続timeoutなど | 前回値を保ち、接続経路と実行環境を確認 |
5xx | サーバー側の一時障害候補 | 上限付き再試行後に失敗記録 |
200でも比較やページ取得が途中で失敗したら、新しいETagを保存しません。前回の成功状態を保ち、部分的な取得を「全件確認済み」と誤認しないようにします。
通信できないときと、403・429が返ったときは、直す場所が違います。
「取得できなかった」を一括で再試行すると、TLS設定の問題にAPIトークンを作り直したり、利用制限中に連打したりします。最初に、GitHubのHTTP応答を受け取れたかを確認します。curlの終了コードとHTTP statusは別物です。
まず通信経路
DNS・TLS・接続timeout
実行環境と接続先を確認
制限か権限か
応答本文とヘッダー
待機指示・権限を確認
取得結果を比較
JSON・保存済み本文
成功した範囲だけ更新
HTTP応答がない：DNS・TLS・timeoutを分ける
curlでHTTP状態が出ず、名前解決やSSL/TLSのエラーが出たら、そのメッセージを残します。同じ端末でもブラウザーと自動化ツールは異なる証明書ストアやプロキシを使うことがあります。監視を動かす環境の接続先・プロキシ・curlや実行基盤の版を確認してください。
GitHubは2026年9月15日にHTTPS接続でのSHA-1対応終了を告知しました。古いクライアントの署名アルゴリズムが該当するかは候補の1つです。すべての接続失敗の原因ではなく、Gitのcommit IDをSHA-1から変更する話でもありません。
証明書エラーにcurl -kなどの検証無効化を常用したり、HTTPへ切り替えたりしません。クライアントや信頼する証明書の更新は管理者の手順に従います。新しいトークンではDNS・TLSの失敗を直せません。timeoutを再試行する場合も上限を決め、続くなら停止して調べます。
403・429：本文と3つのヘッダーを読む
- Retry-Afterがある指定された秒数以上待ちます。
- なければ、remaining=0か
x-ratelimit-resetのUTC epoch秒で示す時刻まで待ちます。 - それ以外のsecondary制限最低1分待ち、続く場合は待機を指数的に延ばします。再試行回数の上限で停止します。
この待機ルールは、応答本文などでrate limitと確認できた場合のものです。権限不足の403や認証エラー401は、対象repo・期限・必要権限を確認します。404も「存在しない」だけでなく非公開リソースへの権限不足の場合があるので、削除と決めつけて保存データを消さないでください。
再開の目安：原因確認後に1回だけ取得し、200と想定したJSON、または手元に保存済みの本文に対応する304を確認します。200でもJSON解析やページ取得が途中で失敗したら、今回の確認は失敗のままです。保存済み本文がない304では、条件ヘッダーを外して取り直します。
第三者repoはPolling、管理できるrepoはrelease Webhookも選択肢です。
Pollingは決めた間隔で取りに行き、Webhookは対象イベントの配信を受けます。速報性だけで選ばず、対象repoを管理できるか、失敗をどう検知するか、必要な頻度はどの程度かで決めます。
管理権限のない公開repoを読む、複数repoを同じ間隔で比較する、速報性が分単位で不要な場合です。ETagと失敗時の待機を組み合わせます。
自分で管理できるrepoや組織、または適切に導入されたGitHub Appで、Release活動をイベントとして受けたい場合です。必要なイベントだけを購読します。
GitHub公式では、repository Webhookの作成にrepo所有者または管理者アクセスが必要です。管理権限のない第三者repoへ設置できるとは考えず、その場合はREST APIのPollingを使います。
releaseイベントはrepository、organization、GitHub Appで利用でき、GitHub Appには少なくともContentsのread権限が必要と案内されています。Webhookでも署名検証、配信IDの重複対策、失敗時の再照合が別途必要です。
GitHub公式のprimary rate limitでは、公開データを認証なしで取得する代表的な上限はIPあたり1時間60回、通常の認証ユーザーは1時間5,000回です。GitHub Apps、Enterprise Cloudなどは条件が異なり、secondary rate limitもあります。契約や実行環境に合わせてレスポンスヘッダーを確認します。
- 取得方式を記録Pollingの間隔か、権限を確認したWebhookの対象イベントを明記する
- ページを最後まで確認一覧の
per_pageは既定30・最大100。Linkヘッダーを使い、3件取得を全件と呼ばない - rate-limit 403・429で待つRetry-After → remaining=0ならreset → その他は最低1分、の順で判断。権限403は設定確認へ分ける
- 再試行に上限を置く短時間に並列取得を増やさず、失敗を隠す無限ループを作らない
- API versionを固定・再確認ヘッダーと公式のサポート期間を確認し、古い応答形を永久に前提にしない
取得失敗時に前回データを表示する場合は、「変更なし」ではなく「今回の確認に失敗」と区別します。古い情報を最新と表示するより、最終成功日時と失敗理由を残す方が、記事更新の判断に使えます。
新Releaseを3つに仕分け、取得失敗は別の状態で残します。
更新監視の価値は、APIの結果を並べることではなく、古くなった記事を早く見つけることです。ただし、Release本文の語句だけで既存記事を書き換えると、先行版、破壊的変更、環境差を誤って一般化できます。
記事に書いたAPI、廃止日、設定方法へ直接影響する通常版。公式ドキュメントと移行情報まで人が確認します。
prerelease、説明が短い変更、環境依存の不具合。検証条件を作り、現行記事へ速報として混ぜません。
対象外機能、内部修正、同じ版のalias候補。取得記録は残しても読者向け更新を増やしません。
前回値を最新と断定せず、確認日時を止めます。自動公開・自動削除・コードの自動実行は行いません。
GitHub Releases 監視メモ
対象owner／repo：
取得日時とタイムゾーン：
endpoint／query：
API version：
HTTP status：
HTTP応答の有無／通信エラー（DNS・TLS・timeout）：
Retry-After／x-ratelimit-remaining／x-ratelimit-reset：
最終成功日時（今回の試行日時とは別）：
ETag／Last-Modified（取得できた場合）：
前回のrelease id／tag_name：
今回のrelease id／tag_name：
draft／prerelease：
created_at／published_at／updated_at：
差分：
分類（新通常版／prerelease／修正／alias候補／変更なし／要調査）：
記事への影響：
公式リリースノートで確認した内容：
人間の判断／次回確認：
※トークン、Cookie、非公開URL、顧客データは記録しない最終的な記事更新では、Release URL、対象版、確認日、実際に試した範囲を明記します。自分で試していない機能は「使えた」と書かず、公式発表とローカル検証を分けます。
GitHub Releases APIの更新監視で、よくある疑問
/releases/latestは、数字が最大の安定版ですか？
そうとは限りません。GitHubがlatestとして返す通常Releaseで、公開側がlatestを指定する機能もあります。日時やSemVerだけで自前再現せず、APIの返り値とプロジェクトの案内を確認します。
Release一覧を取れば、すべてのtagを監視できますか？
できません。GitHub公式は、Releaseと関連しない通常のGit tagをRelease一覧が含まないと説明しています。tag自体も必要なら別エンドポイントを設計します。
他社の公開リポジトリへrelease Webhookを付けられますか？
repoの所有者または管理者アクセスがなければ、repository Webhookは作成できません。管理していない公開repoはAPIでPollingし、GitHub Appを使う場合も導入先と必要権限を確認します。
304なら製品に変更はありませんか？
その条件付きリクエストが示す表現に変更がない、という範囲です。別endpoint、tag、ドキュメント、Webサイトの変更まで否定しません。
TLSエラーが出たらトークンを再発行しますか？
HTTP応答前のTLS失敗は、トークンの再発行では解決しません。実行環境・プロキシ・証明書・クライアントの対応を確認します。証明書検証を無効化して監視を続行しません。
Releaseの取得と、読者へ伝える変更の判断を分離する。
通常版だけなら/latest、prereleaseも比較するならRelease一覧、Release未作成のtagも必要ならtag一覧を使います。release IDを機械的な同一性の軸にし、stable名などの意味上のaliasは人が確認します。
ETag、ページネーション、rate limit、失敗時の最終成功日時まで記録して、初めて継続監視へ進めます。新しいReleaseを見つけても、公式資料と対象環境を確認するまでは記事を自動公開しません。
最新情報を記事へ反映する前の確認手順
公式資料、版、地域、料金プラン、確認日をそろえ、古い情報をどう残すかを解説しています。
GitHub公式資料と、今回の確認範囲
endpoint、latest、条件付きリクエスト、制限、ページネーション、Webhookの権限はGitHub公式資料を基準にしています。実測は公開Release3件のGETと、同じURLへの条件付きGETまで。定期監視やエラー復旧、通知送信は確認していません。
- GitHub Docs：REST API endpoints for releases
- GitHub Docs：REST APIのベストプラクティス
- GitHub Docs：REST APIのレート制限
- GitHub Docs：REST APIのページネーション
- GitHub Docs：REST APIのバージョン
- GitHub Docs：release Webhookイベント
- GitHub Docs：Webhookの作成
- GitHub Docs：REST APIのトラブルシューティング
- GitHub Docs：Releaseの管理とlatestの指定
- GitHub Changelog：HTTPSのSHA-1対応終了（2026年9月15日）
AIを競合調査、公式仕様の照合、構成、実装、検品に使用しています。2026年9月18日に認証なしの公開APIを2回読み取り、HTTP状態とヘッダーを記録しました。実測結果と監視の設計例は分けて掲載しています。