GitHub の Pull Request レビューを Hermes Agent に任せる構成は、Nous Research 公式の User Stories に「リファレンス実装」として掲載されており、PRの差分を取得して LLM でレビューコメントを生成し、GitHub に投稿するまでを自動化できます。実装はcron版とwebhook版の2系統が公式に紹介されており、運用要件で使い分けます。本記事では、株式会社Fyveの法人視点で、この公式事例の仕組み・選定軸・実務落とし込みまでを整理します。コーディング支援領域でAIエージェントを定常稼働させたい組織にとって、最も「型」が揃っている用途のひとつです。

事例の概要 — cron版とwebhook版の使い分け

Nous Research の公式ドキュメント（User Stories & Use Cases）には、GitHub Pull Request 自動レビューの構成例が、運用形態の異なる2バージョンで紹介されています。どちらも「PRの差分を取得→Hermes Agent がレビュー文を生成→GitHub APIでコメント投稿」という骨格は共通で、トリガー方法だけが違います。

この構成が公式リファレンス入りした意味は大きいです。AIエージェントの用途は無数にありますが、「公式が責任を持って示した運用パターン」はまだ少なく、PRレビューはその数少ない筆頭格です。私たちが法人向けに導入支援する際も、最初の自動化テーマとして提案しやすい題材です。

cron版 — 定期巡回で取りこぼしを防ぐ

cron版は、指定した間隔（たとえば15分ごと）でリポジトリのオープン中PRを巡回し、まだレビューしていないPRに対して順次レビューを実行します。Hermes Agent には組み込みのcronスケジューラがあり、外部のジョブスケジューラを使わずに「平日9時から18時、30分ごとに巡回」といった指定を自然言語で設定できます。

• 強み: 受信側のインフラ（webhook受信用のエンドポイント・公開URL）が不要。閉じた環境でも動かせる
• 強み: 巡回時に「前回レビュー以降に追加されたコミット」をまとめてレビューできる。差分の文脈が太い
• 弱み: レビューがリアルタイムではない。最大で巡回間隔ぶんの遅延が出る
• 弱み: PRが多いリポジトリだと、毎回全件チェックする処理コストが無視できなくなる

webhook版 — PRが立った瞬間にレビュー

webhook版は、GitHub の pull_request イベントを Hermes Agent 側で受信し、PRが open / synchronize（追加コミット）された瞬間にレビューを走らせる構成です。レビュー結果はそのPRのコメント欄に即座に投稿されます。

• 強み: リアルタイム性が高い。PRを作った直後にAIレビューが付くので、レビュアー人間が見る前の「下読み」として機能する
• 強み: イベント単位なので、レビュー対象が明確。コストの予測がしやすい
• 弱み: webhook 受信用の公開エンドポイントが必要。社内ネットワークから出せない環境ではトンネリング等の工夫が必要
• 弱み: webhook の取りこぼし（ネットワーク障害等）に備える再送・冪等性の設計が必要

仕組み解説 — GitHub APIとHermes Agentの連携

この事例の核は、Hermes Agent の「ビルトインツール」と GitHub API の組み合わせ方にあります。Hermes Agent には標準で70以上のツールが用意されており、その中にはターミナル実行・HTTP取得・ファイル操作などが含まれます。GitHub PR レビューは、これらを「PRレビューという1つのスキル」として束ねた構成になります。

パイプラインの全体像

cron版・webhook版いずれも、内部のパイプラインは概ね次の流れです。

1. PR情報の取得: GitHub API の GET /repos/{owner}/{repo}/pulls/{number} でPRのメタ情報を取得
2. 差分の取得: GET /repos/{owner}/{repo}/pulls/{number}/files で変更ファイル一覧と patch を取得
3. レビューコメント生成: 差分・コミットメッセージ・PR本文を LLM に渡し、レビューコメントを生成
4. 投稿: POST /repos/{owner}/{repo}/issues/{number}/comments で総評コメントを投稿、または POST /repos/{owner}/{repo}/pulls/{number}/reviews で行単位のレビューを投稿
5. 記録: どのPRをどのコミットまでレビューしたかを Hermes Agent の永続記憶に保存

5番目の「記録」が地味に重要です。Hermes Agent は3層メモリのうち永続記憶層に「最後にレビューしたPR番号とコミットSHA」を保持できます。これにより、再起動しても二重レビューを起こさず、追加コミットだけを正しくレビュー対象にできます。

レビュー品質の制御

AIレビューでよくある失敗は、レビューの粒度が一定にならないことです。あるPRでは細かい指摘が10件、別のPRでは曖昧な総評1行、といったバラつきが出るとレビュアー人間からの信頼を失います。公式リファレンスではこの問題に対し、いくつかの制御点を置いています。

• レビュー観点の明文化: 「セキュリティ・パフォーマンス・可読性・テスト網羅性」のような観点をスキルのプロンプトで固定する
• 重大度ラベルの付与: 各指摘に blocker / major / minor / nit のラベルを付けさせる。これがあると人間レビュアーが優先順位を即判断できる
• 差分の範囲指定: 巨大PRに対しては最初に「変更ファイル一覧の要約」を返し、特定ファイルに踏み込むときだけ全文を読む。これがコンテキスト枯渇を防ぐ
• 成功基準の明示: 「変更がない箇所には言及しない」「テストファイルの変更だけのPRには軽量レビューを返す」など、ネガティブな成功基準を書く

Hacker News のディスカッション（item ID 47726913）でも、Hermes Agent ユーザーの間で「explicit success criteria を書けば self-grading の問題はだいたい解決する」というコメントが共有されています。AIにレビューさせる際、何を「良いレビュー」とみなすかをスキル側に書き込むことが、品質の最大要因です。

私たちの解釈 — なぜPRレビューが「最初の自動化」に向くのか

株式会社Fyveとしてこの公式事例を見ると、PRレビュー自動化は「AIエージェント導入の最初の一手」として非常に筋が良い題材です。理由は3つあります。

1つ目は、評価軸が明確であることです。AIエージェントの導入で最大の壁は「効果が見えにくい」点にありますが、PRレビューは「指摘の鋭さ・取り違えの少なさ・速度」が即座に可視化されます。レビュアー人間と並走させて1〜2週間運用すれば、人間側が「これはAIに任せて良い」と判断できる領域が見えてきます。

2つ目は、失敗のコストが低いことです。AIレビューが的外れだった場合でも、それはコメント1件として残るだけで、ビルドを止めるわけでもデプロイを失敗させるわけでもありません。「AIエージェントに対する不安」を解消する最初のステップとして、低リスクで効果が見える題材は重要です。

3つ目は、永続記憶との相性が良いことです。Hermes Agent の永続記憶層には、リポジトリ固有のコーディング規約・過去に議論されたトレードオフ・チームが「これは指摘しなくて良い」と合意した観点などを蓄積できます。導入から1〜2ヶ月経過すると、レビューの粒度がチームの規約に自然と寄っていきます。

逆に言えば、PRレビューを永続記憶なしのセッション型AIで運用すると、毎回同じ初歩的な指摘を繰り返すことになります。私たちが「AIエージェントを業務資産化するなら永続記憶レイヤーが必須」と提案する根拠のひとつが、この用途です。

実務落とし込み — 社内コードベースへの導入手順

公式リファレンスは「動く骨格」を示していますが、社内モノレポやプロダクトコードへ実導入するには、いくつかの追加設計が必要になります。私たちが法人向けに導入する際の手順を、4ステップに整理します。

ステップ1: パイロットリポジトリの選定

いきなり全リポジトリに適用するのは禁物です。最初は次の条件を満たすリポジトリを1本だけ選びます。

• PR数が週5件前後（少なすぎず、多すぎず）
• テストカバレッジが一定以上ある（AIレビューの当たり外れを人間が検証しやすい）
• レビュアー人間が1〜2名に絞られている（フィードバックループが回しやすい）

このパイロット段階での目標は「2週間でAIレビューの精度感を掴むこと」です。指標としては、AIが出した指摘のうち人間レビュアーが採用した割合（採用率）を記録します。50%を超えるとレビュー補助として実用域です。

ステップ2: CODEOWNERS連携

GitHub の CODEOWNERS ファイルと組み合わせる設計が重要です。AIレビューはあくまで「最初の下読み」であり、最終承認は人間が行う運用にします。具体的には、次のような流れを推奨します。

1. PRが open される
2. webhook が Hermes Agent に通知 → AIが30秒以内にレビューコメントを投稿
3. CODEOWNERS で指定された人間レビュアーが、AIコメントを下敷きにレビュー
4. 人間レビュアーの approve が必須でマージできる設計（branch protection）

AIに approve 権限を渡さないことが鉄則です。これは技術的な制約というより、責任所在を明確にするための運用ルールです。経済産業省の「AI事業者ガイドライン」でも、AIによる業務判断には人間の最終承認を組み合わせることが推奨されています。

ステップ3: スキルへの社内規約の埋め込み

Hermes Agent のスキルファイル（SKILL.md形式）に、社内コーディング規約を明示的に書き込みます。具体的には次のような項目です。

• 命名規則（変数・関数・ファイル）
• 禁止されているライブラリやパターン
• テストの粒度に関する合意
• 過去のインシデントから生まれたチェック項目
• 「指摘しなくて良い」観点のリスト

最後の「指摘しなくて良い観点」が特に効きます。たとえば「設計判断としてマジックナンバーを残している箇所」「歴史的経緯で残っているTODOコメント」などを明示しておくと、AIが何度も同じ指摘をする問題を防げます。

ステップ4: セキュリティ境界の設定

Hermes Agent は公式 Issue #7826 でセキュリティ監査が公開されており、Critical 4件・High 9件の指摘が出ています。PRレビュー用途では、特に次の3点をデフォルト設定で固める必要があります。

• read_file の deny list: .env・credentials・SSH鍵などを読めないよう明示的に禁止
• ターミナル実行の制限: PRレビュー用途ではシェル実行は基本不要。disable するか、許可コマンドを allowlist で絞る
• GitHub PAT のスコープ最小化: 対象リポジトリへの read/write のみ。Organization 全体への管理権限を持たせない

関連事例 — 開発支援領域の他のリファレンス

PRレビュー以外にも、Hermes Agent の公式・準公式リファレンスには開発支援領域の事例が複数あります。組み合わせると「コードを書く前」から「マージ後」までの一連のフローをカバーできます。

ローカル記憶層（@hackafterdark）

Xユーザー @hackafterdark は、Hermes Agent のローカル記憶層を使って「自分が過去に書いたコードの設計判断」を蓄積する運用を公開しています。PRレビューの精度を上げる土台として、この記憶層への蓄積が効きます。

トークン消費プロファイラ（@Bichev）

同じくXユーザー @Bichev は、Hermes Agent のAPI呼び出しを計測したところ「73%が固定オーバーヘッド」だったという発見を公開しました。PRレビュー用途では1日数十回〜数百回の呼び出しが発生するため、このプロファイリング知見はコスト最適化に直結します。

MCPサーバー化（@buray）

Xユーザー @buray は hermes mcp-server という形で Hermes Agent の機能を9つのツールとして MCP（Model Context Protocol）公開しました。これにより Claude Desktop や Cursor から Hermes Agent のスキル群を呼び出せます。社内に Hermes Agent 1台を立て、複数の開発者ツールから共有する構成が現実的になります。

関連する深掘り記事は以下をご参照ください。

Hermes AgentHermes Agentの3層メモリと永続記憶｜育つAIの仕組み

Hermes AgentHermes・OpenClaw・LangGraph 比較｜選定軸

まとめ

• Nous Research が公式リファレンスとして掲載するGitHub PR自動レビューは、cron版・webhook版の2系統がある
• cron版は閉じた環境でも動かせて差分の文脈が太い。webhook版はリアルタイム性が高くコストが予測しやすい
• パイプラインの核は「PR取得→差分取得→LLM生成→GitHubコメント投稿→永続記憶への記録」の5ステップ
• レビュー品質の制御には、観点の明文化・重大度ラベル・差分範囲指定・成功基準の明示が効く
• 導入は「パイロットリポジトリ選定 → CODEOWNERS連携 → スキルへの規約埋め込み → セキュリティ境界の設定」の4ステップで進める
• AIに approve 権限を渡さず、人間レビュアーの最終承認を必須とする運用設計が鉄則
• 関連事例（ローカル記憶層・トークンプロファイラ・MCPサーバー化）と組み合わせると、開発フロー全体をカバーできる

出典:

• Hermes Agent — User Stories & Use Cases（Nous Research 公式）
• GitHub: NousResearch/hermes-agent
• 公式セキュリティ監査 Issue #7826
• Hacker News discussion (item ID 47726913)
• 経済産業省「AI事業者ガイドライン」