PR-Agentとは？使い方・GitHub Actions/Docker導入と料金【v0.48対応】

PR-Agent（PRエージェント）は、GitHubやGitLabのプルリクエスト（PR）をLLMに読ませ、説明文の作成・レビュー・修正提案を自動化するオープンソースのツールです。説明文は既定ではPR本文に反映され、レビューや修正提案はコメントとして投稿されます。ライセンスはMITで、本体は無料です。費用は自分で契約するLLMのAPI料金と、GitHub Actionsやサーバーなどの実行環境代だけです。

2026年4月に開発元のQodo（旧CodiumAI）がプロジェクトをコミュニティへ移管し、リポジトリは The-PR-Agent/pr-agent、Dockerイメージは pragent/pr-agent、ドキュメントは docs.pr-agent.ai に移りました。日本語の解説記事の多くは移管前の qodo-ai/pr-agent 時代のものです。本記事は2026年10月16日公開のv0.48.0を基準に、Python 3.12環境で設定読み込みとOpenAI互換スタブへの送信内容を確認した結果を交えて説明します。この検証は通信内容と処理の確認であり、実際のLLMのレビュー精度を測ったものではありません。

まとめ：PR-Agentの要点

• PR-AgentはPRを読んでコメントを返すOSS。/describe（説明文）、/review（レビュー）、/improve（修正提案）、/ask（質問）が中心
• 2026年4月からコミュニティ運営で、Qodoの有料製品（旧Qodo Merge、現Qodo）とは別物
• 導入はGitHub Actionsが最短。ワークフローを1本置き、OPENAI_KEY をSecretsに登録する
• v0.48.0から pip install pr-agent だけではGitHubへ接続できない。pip install "pr-agent[github]" のようにGitサービス名のextrasを付ける
• 既定の出力は英語。.pr_agent.toml に response_language = "ja-JP" を書くと日本語になる
• LLMにはPRの差分・タイトル・説明や、存在する場合は AGENTS.md などが送られる。関連Issueの内容や、設定で追加したコンテキストも送信対象になる。/improve は提案を生成した場合、自己評価でもLLMを呼び出す
• v0.46以前から上げるときは、コミット追加時の再実行の書き方、ツール失敗時にActionが赤くなる挙動、リポジトリから変えられなくなった設定の3点を先に確認する

PR-Agentの現在地：Qodoからコミュニティへの移管

リポジトリ・Dockerイメージ・ライセンスの移り変わり

2026年4月21日の公式アナウンスによると、QodoはPR-Agentをオープンソースコミュニティへ寄贈し、プロジェクトはGitHubのPR-Agent組織に移りました。旧URLの github.com/qodo-ai/pr-agent は新リポジトリへ転送されますが、Dockerイメージは転送されません。

ライセンスはLICENSEファイルの履歴で2段階に変わっています。2026年5月20日にAGPL-3.0からApache License 2.0へ、7月9日にApache 2.0からMITへ変更されました。AGPL時代の「改変版をサービス提供するとソース公開義務が生じる」という注意は、現行版には当てはまりません。

イメージ名が codiumai/pr-agent のままだとv0.31までの旧版しか取得できません。リリースはほぼ毎週出ており（v0.47.0が10月2日、v0.48.0が10月16日）、古い手順ほど差が大きくなります。

Qodo Merge（現Qodo）との違い

READMEは冒頭で「QodoがOSS向けに提供している製品ではない」と明記しています。Qodo Mergeはもともと「PR-Agentのホスト版」でしたが、Qodo 2.0に作り替えられて別製品になり、現在はPR-AgentのGold Sponsorです。APIキーと実行環境を自分で用意するのがPR-Agent、GitHubアプリを入れるだけで使えるマネージドサービスがQodoです。Qodo側の機能と料金はQodo Mergeの使い方・料金・PR-Agentとの違いで扱っています。

PR-Agentのコマンド一覧と出力内容

PRのコメント欄に /review のように書くと、結果がコメントで返ります。同じ処理はCLIからも呼べます。

/help_docs（リポジトリ内のドキュメントを根拠に回答）もありますが、認証情報が漏れる不具合（Issue #2445）の修正待ちで、v0.36.1から無効化されたままです。v0.47.0からはGitLab・Bitbucketでも、コメントが / で始まらない限りツールは動きません。

旧版の解説に出てくる pr-agent summarize・pr-agent explain・pr-agent label・pr-agent custom は存在しません。v0.48.0の pr-agent --help が受け付けるサブコマンドは次の18個で、要約は describe、ラベル付けは generate_labels が担います。

{auto_review,answer,review,review_pr,describe,describe_pr,improve,improve_code,ask,ask_question,ask_line,update_changelog,config,settings,help,similar_issue,add_docs,generate_labels}

PR-AgentがLLMに送る内容とレビューの仕組み

差分の形式とAGENTS.mdの読み込み

v0.48.0のCLIをOpenAI互換のスタブサーバーに向け、SQLのプレースホルダを文字列連結に書き換えた1ファイルの変更で review を実行し、LLMに届いたリクエストを記録しました。中身は次の3つです。

• ユーザーメッセージ：PRのタイトル・ブランチ名・説明（localモードではコミットメッセージ）と、ファイルごとの差分。差分は __new hunk__（変更後のコードに行番号付き）と __old hunk__（変更前）に分けて渡される
• システムメッセージ：レビューの指示と出力スキーマ（YAML）に加え、リポジトリ直下の AGENTS.md が「instruction_files」として丸ごと入る
• パラメーター：model は既定の gpt-5.6、reasoning_effort は medium

AGENTS.md に書いた「SQLはプレースホルダを使う」は、そのままプロンプトに入りました。規約を extra_instructions にも書くと同じ指示を二重に送ることになります。localモードでは現れませんが、GitHubなどのPRでは、タイトル・本文・ブランチ名から参照されたIssueの内容もチケット情報として追加されます。読み込むファイルは config.repo_context_files（既定 ["AGENTS.md"]、最大500行）で変えられ、CLAUDE.md を足すことも、[] で無効にすることもできます。

大きなPRの圧縮とトークン上限

差分は、各変更の前後3行を文脈として広げてから送られます。実行ログには「Tokens: 1759, total tokens under limit: 32000」と出ており、既定の上限は config.max_model_tokens = 32000 です。モデル側のコンテキストがもっと長くても、この値で頭打ちになります。

上限を超える大きなPRでは、圧縮戦略のドキュメントの順で削られます。バイナリや画像を除き、リポジトリで多く使われている言語のファイルを優先し、削除だけのhunkは落として、削除ファイルは名前の一覧にまとめます。それでも入らないファイルは「other modified files」として名前だけが渡ります。/review を分割して複数回呼ぶ enable_large_pr_chunking は既定で無効です。

/improveの自己評価とスコアによる絞り込み

/improve は、提案を生成したあと、その提案一覧をもう一度モデルに渡して0〜10点で採点させます（Self-Reflection）。スタブで提案1件を返したところ、LLMへの呼び出しは2回で、出力には「importance: 9」と採点結果が付きました。提案が0件なら自己評価は呼ばれません。0点の提案は捨てられ、pr_code_suggestions.suggestions_score_threshold（既定0）を上げると低い点の提案も出なくなります。設定ファイルの注記は、関連性の高い提案まで削れるとして8より上にしないよう勧めています。

GitHub ActionsでPR-Agentを導入する手順

ワークフローとSecretsの設定

公式ドキュメントのGitHub導入手順が最初に勧める方法で、サーバーは要りません。v0.48.0のドキュメントでは contents の権限が read です。

# .github/workflows/pr_agent.yml
on:
  pull_request:
    types: [opened, reopened, ready_for_review]
  issue_comment:
jobs:
  pr_agent_job:
    if: ${{ github.event.sender.type != 'Bot' }}
    runs-on: ubuntu-latest
    permissions:
      contents: read
      issues: write
      pull-requests: write
    steps:
      - name: PR Agent action step
        uses: docker://pragent/pr-agent:0.48.0-github_action
        env:
          OPENAI_KEY: ${{ secrets.OPENAI_KEY }}
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          github_action_config.auto_review: "true"
          github_action_config.auto_describe: "true"
          github_action_config.auto_improve: "false"
          config.response_language: "ja-JP"

1. 上のファイルを .github/workflows/pr_agent.yml として置く
2. Settings → Secrets and variables → Actions で OPENAI_KEY を登録する（GITHUB_TOKEN はGitHubが自動で発行する）
3. デフォルトブランチへマージし、次にPRを開くと github-actions ボットがレビューを投稿する

issue_comment を入れておくと、PRのコメント欄に書いた /ask や /improve にも反応します。環境変数は セクション.キー か セクション__キー の形で設定ファイルの項目に対応し、真偽値は "true" のように文字列で、配列は '["opened", "reopened"]' のようにJSON文字列で書きます。

自動実行するツールとコミット追加時の再実行

auto_review・auto_describe・auto_improve は、未設定だと3つとも「PRを開いたときに自動実行」になります。上の例で auto_improve を切っているのは、修正提案によってコメント量が増えやすく、提案を生成した場合は自己評価の追加呼び出しも発生するからです。必要なときに /improve と書けば足ります。

コミットを追加するたびに走らせる方法は2つあり、どちらもワークフローの pull_request.types に synchronize を足すことが前提です。

• github_action_config.handle_push_trigger: "true"：push_commands（既定は /describe と /review）だけを実行する。マージコミットとボットのコミットは既定で無視される
• github_action_config.pr_actions に synchronize を足す：PRを開いたときと同じ自動ツール一式を実行する

v0.48.0の公式サンプルは types に synchronize を含めていますが、どちらの設定も無ければ、コミットのたびにジョブが起動するだけで何も実行されません。費用を抑えるなら前者を選び、push_commands を /review だけに絞ります。

バージョンの固定とツール失敗時の扱い

上の例はDockerイメージのタグで0.48.0に固定しています。公式ドキュメントの例は uses: the-pr-agent/pr-agent@main で、常に最新のmainブランチを使うため、週次リリースの破壊的変更もそのまま入ります。版を上げるときはタグの数字を書き換え、リリースノートを確認してからマージします。

より厳密にするなら docker buildx imagetools inspect でダイジェストを調べ、pragent/pr-agent@sha256:… の形で指定します。イメージにはGitHub Artifact Attestationsが付いており、gh attestation verify で出どころを検証できます。

v0.47.0からは、ツールが内部で失敗するとActionも失敗（赤）になります。従来どおり緑で終わらせたい場合はワークフローの環境変数に github_action_config.fail_on_tool_errors: "false" を足します。コメントの引数では変更できません。

GitHub Appによる組織導入と認証設定

リポジトリが多い組織では、PR-AgentをGitHub Appとして自前のサーバーで動かす方式もあります。DeNAは2025年8月の全社導入の記事で、organizationに一度インストールすれば配下のリポジトリで使えること、LLMのAPIキーを一元管理できることを理由にGitHub Appを選んでいます。

v0.48.0で自前ホストする場合、Webhookシークレットは必須です（GITHUB.WEBHOOK_SECRET が未設定だとすべてのWebhookが403で拒否されます）。組織共通の設定リポジトリ（pr-agent-settings）も既定では読まれなくなったので、使うならホスト側の設定に config.global_settings_repo = "pr-agent-settings" を書きます。

DockerとCLIでPR-Agentをローカル実行する方法

docker runによる既存PRのレビュー

既存のPRで1回試すならDockerが手軽です。LLMのAPIキーとGitサービスの個人アクセストークンを渡します。

# GitHub
docker run --rm -it \
  -e OPENAI__KEY=$OPENAI_API_KEY \
  -e GITHUB__USER_TOKEN=$GITHUB_TOKEN \
  pragent/pr-agent:0.48.0 --pr_url https://github.com/OWNER/REPO/pull/123 review

# GitLab（セルフホストなら -e GITLAB__URL=https://gitlab.example.com を追加）
docker run --rm -it \
  -e OPENAI__KEY=$OPENAI_API_KEY \
  -e CONFIG__GIT_PROVIDER=gitlab \
  -e GITLAB__PERSONAL_ACCESS_TOKEN=$GITLAB_TOKEN \
  pragent/pr-agent:0.48.0 --pr_url https://gitlab.com/GROUP/PROJECT/-/merge_requests/45 review

OPENAI__KEY なら [openai] の key、CONFIG__GIT_PROVIDER なら [config] の git_provider に対応します。GitHub Enterprise Serverは -e GITHUB__BASE_URL=https://github.mycompany.com/api/v3 を足します。Docker Hubには latest・0.48.0 のほか、0.48.0-github_action・0.48.0-github_app・0.48.0-gitlab_webhook・0.48.0-github_lambda など用途別のタグがあり、CLIとして使うのは latest か版番号だけのタグです。

pipによるCLI導入とv0.48のextras

pr-agent 0.48.0は requires_python >=3.12 で、GitHub・GitLabなどのSDKが本体の依存から外れてextras（追加インストール指定）に分かれました。Python 3.12の仮想環境で確かめると、pr-agent==0.48.0 だけでは import github が ModuleNotFoundError になり、pr-agent[github]==0.48.0 で入れ直すと読み込めました。

uv venv -p 3.12 .venv
uv pip install -p .venv/bin/python "pr-agent[github]==0.48.0"
export OPENAI__KEY=sk-...
export GITHUB__USER_TOKEN=ghp_...
.venv/bin/pr-agent --pr_url https://github.com/OWNER/REPO/pull/123 review

extrasは github・gitlab・bitbucket・azure・codecommit・gitea・google などで、従来と同じ一式は pr-agent[all] です。Dockerイメージは最初から all 入りなので影響を受けません。

環境変数名にも注意が要ります。READMEのCLI例は export OPENAI_KEY=… ですが、0.48.0のCLIで設定値を読み出すと、OPENAI_KEY では openai.key が空のまま、OPENAI__KEY（アンダースコア2つ）なら値が入りました。OPENAI_KEY を読むのはGitHub Action用の起動処理だけです。

PRを作らずにブランチ差分をレビューするlocalモード

CONFIG__GIT_PROVIDER=local を付けると、GitHubやGitLabのPRが無くても、手元のブランチと比較先ブランチの差分をレビューできます。Gitサービスのトークンは要らず、LLMのキーだけで動きます。--pr_url にはURLではなく比較先のブランチ名を渡します。

cd /path/to/repository
git status --short   # 未コミットの変更が無いことを確認
CONFIG__GIT_PROVIDER=local OPENAI__KEY=sk-... \
  .venv/bin/python -m pr_agent.cli --pr_url main review

スタブサーバー相手に review・describe・improve を順に実行すると、リポジトリ直下に review.md・description.md・improve.md が書き出されました。比較されるのはコミット済みの HEAD と、比較先ブランチとのマージベースです。作業中の変更は対象外なので、先にコミットしておきます。PRを出す前の自己チェックに使えます。

GitLab・Bitbucket・Azure DevOps・Giteaでの対応範囲

ここではGitHub・GitLab・Bitbucket・Azure DevOps・Giteaの5サービスを比較し、ツールごとの差は公式のSupported platformsで次のようになっています。

「コメント」は、ラベルやファイルを直接変えられないため結果をPRコメントで投稿する、という意味です。GerritとAWS CodeCommitもプロバイダーとして登録されており、describe・review・improve・ask・add_docs・helpが動きます。

v0.47・v0.48では、Webhookの認証が厳しくなりました。Giteaは gitea.webhook_secret、Azure DevOps Serverは webhook_username と webhook_password、Bitbucket Serverは webhook_secret が未設定だと、すべてのWebhookを403で拒否します。GitLabの具体的な導入手順と方式の選び方はGitLabでPR-AgentのAIコードレビューを導入する手順にまとめています。

.pr_agent.tomlによる日本語化・モデル変更・出力形式の設定

設定ファイルの置き場所とリポジトリから変えられない設定

リポジトリ単位の設定は、デフォルトブランチのルートに置いた .pr_agent.toml から読まれます。PRのブランチに置いただけでは反映されません。設定ファイルのドキュメントは、既定値の configuration.toml を丸ごとコピーせず、変えたい項目だけを書くよう勧めています。

# .pr_agent.toml
[config]
response_language = "ja-JP"
model = "anthropic/claude-opus-5"
fallback_models = ["anthropic/claude-haiku-4-5-20251001"]

[pr_reviewer]
extra_instructions = """\
- テストの追加が無いPRには、その旨を1行で書く
"""

[pr_code_suggestions]
suggestions_score_threshold = 6

[ignore]
glob = ["vendor/**", "**/*.lock", "docs/generated/**"]

v0.48.0では、リポジトリ側から変えられる範囲が狭まりました。APIの接続先（openai.api_base など）、名前が key・token・secret・url で終わる項目、認証方式やTLSの設定は、.pr_agent.toml やコメント引数に書いても警告付きで無視され、ホスト側（ワークフローの環境変数やサーバーの設定）でしか効きません。PRを出せる人が接続先を書き換えて差分を外部へ送る攻撃を防ぐためです。pyproject.toml の [tool.pr-agent] も読まれなくなったので、.pr_agent.toml へ移します。

response_languageによる日本語出力の設定

既定の response_language は "en-US" です。"ja-JP" にするとLLMが生成する本文は日本語になりますが、ラベルや表の見出しなどの固定文言は英語のまま残る、とドキュメントに書かれています。GitHub Actionsだけで済ませるなら、前述のワークフローのように環境変数 config.response_language: "ja-JP" で渡しても同じです。

OpenAI以外のモデルへの切り替え設定

v0.48.0の既定モデルは gpt-5.6、フォールバックは gpt-5.6-terra です。LiteLLM経由でAnthropic・Gemini・Azure OpenAI・Amazon Bedrock・Vertex AI・OpenRouter・Ollamaなどに切り替えられます。Anthropicなら上の例のように model と fallback_models を書き換え、キーはGitHub Actionsの環境変数 ANTHROPIC.KEY: ${{ secrets.ANTHROPIC_KEY }} で渡します（公式のClaude用サンプルと同じ組み合わせ）。

model だけ変えて fallback_models を既定のまま残すと、失敗時の切り替え先はOpenAIの gpt-5.6-terra のままです。OpenAIのキーが無い環境では切り替えに失敗するので、2つは必ずセットで書き換えます。

説明文の投稿先と修正提案の形式

DeNAの記事でも調整されていた、出力の出し方に関わる2項目です。

• pr_description.publish_description_as_comment（既定 false）：/describe の結果は、既定ではPR本文を書き換える。true にするとコメントとして投稿し、作者が書いた本文には触れない
• pr_code_suggestions.committable_code_suggestions（既定 false）：/improve の提案は、既定では表形式の1コメントにまとまる。true にすると、GitHubの「Commit suggestion」で直接取り込める行コメントとして出る

v0.47.0で commitable_code_suggestions は綴りを直した committable_code_suggestions に改名されました。旧名は1.0まで警告付きで使えます。

レビュー対象から外すファイル

[ignore] の glob に書いたパスは差分から除かれます。既定では vendor/** だけです。ロックファイルや自動生成コードを外すと、LLMに送るトークンが減り、32,000トークンの上限に押し出されて本題のファイルが「名前だけ」になる事態も防げます。protobufなど言語・フレームワーク別の生成物は ignore_language_framework でまとめて外せます。

PR-Agentの料金とLLM APIコストの抑え方

PR-Agent本体はMITライセンスで、利用料やユーザー数課金はありません。支払いが発生するのは次の2つです。

• LLMのAPI料金：PRの差分・説明・AGENTS.md が入力トークンとして課金される
• 実行環境：GitHub Actionsの実行時間（標準のGitHubホステッドランナーはパブリックリポジトリで無料、プライベートでは無料枠を超えた分が課金対象）、GitHub AppやWebhookサーバーを立てる場合はそのホスティング費用

規模の目安として、DeNAの公開事例では1日1,000〜1,500回の実行、約40のorganizationと約200のリポジトリでの利用に対し、AWSが月約150ドル、Azure OpenAI（gpt-4.1）が月約500ドルでした。2025年8月時点のモデルと単価での数字なので、現在のモデルでは同じ額にならない点に注意してください。

API代は、モデルの単価、入出力のトークン数、呼び出し回数で決まります。GitHub Actionの既定ではPRを開くたびにdescribe・review・improveが動き、improveは提案があれば自己評価でもう1回呼びます。/improve --extended は差分を最大3チャンクに分けて提案を生成します（max_number_of_calls = 3）。自己評価や失敗時の再試行は別に発生するため、LLMへの総呼び出し回数が3回以内になるという意味ではありません。下げる手は、自動実行をreviewとdescribeに絞る、[ignore] で生成物を外す、[model_routing] で小さいPRを安いモデルへ回す、の3つです。

[model_routing]
enable = true
rules = [
  { max_hunks = 3, model = "gpt-5.6-luna" },
  { max_hunks = 15, max_files = 6, model = "gpt-5.6-terra" },
]

model_routing は既定で無効です。ルールは上から順に評価され、どれにも当てはまらない大きなPRは config.model で処理されます。対象はreview・improve・generate_labels・add_docsです。

v0.46以前からアップグレードするときの確認項目

v0.47.0とv0.48.0のリリースノートには、既存の環境が止まる変更が「Breaking Changes」としてまとまっています。@main や latest を使っている環境は、すでにこの変更を受けています。影響の大きいものを抜き出しました。

非root化の対象はwebhook・app・pollingなどのサービス用イメージで、UID/GIDは10001、ホームは /home/pragent です。GitHub Action・CLI・Lambda用のイメージは引き続きrootで動きます。merge_recommendation は safe_to_merge が no_concerns_found に、merge_with_caution が needs_review に変わりました。レビュー結果を機械的に読んで後続処理を分けている場合だけ影響します。

PR-Agentを入れる前に確認すべき条件と運用上の落とし穴

フォークからのPRとSecretsの扱い

OSSのように外部からPRを受けるリポジトリでは、pull_request イベントだとフォーク元のPRにSecretsが渡らず、PR-AgentはAPIキーを読めずに失敗します。公式の解決策は pull_request_target への切り替えですが、これはベースリポジトリの権限とSecretsを持ったままワークフローが動く設定です。PR-AgentはGitHub APIで差分を取るので actions/checkout は不要で、ドキュメントも省略を勧めています。PRのコードを取得して、Secretsや書き込み権限を持つ同じジョブでビルド・テスト・インストールを行うと未信頼のコードが動くため、ドキュメントは警告を付けています。PR-Agent用のワークフローは、ビルドやテストのジョブと分けて単独のファイルにしてください。

設定を読むブランチを変える --config-branch（環境変数 PR_AGENT_CONFIG_BRANCH）にも注意が要ります。ここに ${{ github.head_ref }} のようなPR由来の値を入れると、PRを出した人が自分の .pr_agent.toml でレビューを操作できてしまいます。ドキュメントは、管理者が固定したブランチ以外を指定しないよう明記しています。

LLM事業者へのコード送信と利用条件

READMEのData Privacy節は「自分のOpenAI APIキーでホストするなら、データの扱いはあなたとOpenAIの間の話」と書いています。PR-Agentの運営側にコードは送られませんが、前述のとおり差分・PRの説明・AGENTS.md はそのままLLM事業者へ渡ります。外部送信に制限があるコードでは、社内規程と契約で許可されたAzure OpenAIやAmazon Bedrock、またはOllamaのローカルモデルを指定するのが前提です。

PR-Agentが向かないチーム

次のどれかに当てはまるなら、PR-Agentより先に別の選択肢を検討したほうが早く立ち上がります。

• ワークフローとAPIキーの管理を担う人がいない：GitHubアプリを入れるだけのQodoやCodeRabbitの導入手順と.coderabbit.yaml設定のほうが早い
• 既にGitHub Copilotの有料プランを契約している：利用枠を確認したうえでGitHub Copilotのコードレビューを先に試せる
• リポジトリ全体の依存関係を踏まえた指摘が欲しい：PR-Agentが送るのは差分と周辺の文脈で、コードベース全体を索引化するGreptileとは設計が違う
• 週次リリースの追従を誰も見られない：v0.47・v0.48のように破壊的変更が続くため、版を固定して定期的に上げる担当が要る

逆に、モデルと送信先を自分で選びたい、プロンプトや出力形式を細かく変えたい、GitHub以外のGitサービスでも同じ仕組みを使いたい、という条件ならPR-Agentが合います。Claude Codeの中でPRを見直すならpr-review-toolkitもあります。CI/CDへのレビュー自動化の組み込みを社内で進めにくい場合は、DevOps・CI/CD導入支援で設計から相談できます。

PR-Agentに関するよくある質問

PR-Agentは無料で使えますか？

本体はMITライセンスのOSSで無料です。OpenAIやAnthropicなどLLMのAPI料金は自分の契約で発生し、GitHub Actionsで動かす場合はプライベートリポジトリで実行時間が無料枠を超えると課金されます。

PR-AgentをDockerで動かすにはどうすればよいですか？

pragent/pr-agent:0.48.0（または latest）に、OPENAI__KEY とGitサービスのトークン（GitHubなら GITHUB__USER_TOKEN）を環境変数で渡し、--pr_url とツール名を付けて docker run します。旧イメージの codiumai/pr-agent はv0.31で更新が止まっています。

pip install pr-agent のあとGitHubに接続できないのはなぜですか？

v0.48.0からGitサービスのSDKがextrasに分かれ、pip install pr-agent だけではGitHub用のライブラリが入らないためです。pip install "pr-agent[github]" のように使うサービス名を付けるか、pr-agent[all] で入れ直してください。Python 3.12以上も必要です。

PR-Agentのレビューを日本語で出せますか？

出せます。.pr_agent.toml の [config] に response_language = "ja-JP" を書くか、GitHub Actionsの環境変数に config.response_language: "ja-JP" を足します。LLMが生成する文章は日本語になり、ラベルや表の見出しは英語のまま残ります。

the-pr-agent/pr-agentは公式のリポジトリですか？

公式です。2026年4月にQodoがPR-Agentをコミュニティへ寄贈し、開発の本拠が The-PR-Agent/pr-agent に移りました。旧 qodo-ai/pr-agent のURLは新リポジトリへ転送されます。Qodo（旧Qodo Merge）はこれとは別の製品です。

関連記事

• GitLabでPR-AgentのAIコードレビューを導入する手順｜CI・Webhook・Qodo Merge Proの選び方
• Qodo Mergeとは？現Qodo 2.xの使い方・料金とPR-Agentとの違い【2026年9月】
• CodeRabbit（コードラビット）とは？AIコードレビューの仕組み・料金・安全性【2026年10月】
• GitHub Copilotのコードレビュー｜依頼方法・自動化・日本語化と料金
• Greptileとは？料金・使い方・CodeRabbitとの違い【2026年9月・v5対応】