---
title: "PR-Agentとは？使い方・GitHub Actions/Docker導入と料金【v0.48対応】"
url: "https://www.issoh.co.jp/tech/details/7152/"
published: 2025-06-09
updated: 2026-10-20
categories: ["GitHub"]
publisher: "株式会社一創"
---

# 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](https://github.com/The-PR-Agent/pr-agent/releases/tag/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日の[公式アナウンス](https://github.com/The-PR-Agent/pr-agent/discussions/2337)によると、QodoはPR-Agentをオープンソースコミュニティへ寄贈し、プロジェクトはGitHubのPR-Agent組織に移りました。旧URLの `github.com/qodo-ai/pr-agent` は新リポジトリへ転送されますが、Dockerイメージは転送されません。

| 項目            | 移管前（〜2025年）                 | 現在（2026年10月）                   |
| ------------- | --------------------------- | ------------------------------ |
| リポジトリ         | qodo-ai/pr-agent            | The-PR-Agent/pr-agent          |
| GitHub Action | qodo-ai/pr-agent@main       | the-pr-agent/pr-agent@main     |
| Dockerイメージ    | codiumai/pr-agent（v0.31で凍結） | pragent/pr-agent               |
| ドキュメント        | qodo-merge-docs.qodo.ai     | docs.pr-agent.ai               |
| ライセンス         | AGPL-3.0                    | MIT（2026年7月9日から）               |
| PyPI          | pr-agent                    | pr-agent 0.48.0（Python 3.12以上） |

ライセンスは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との違い](/tech/details/6871/)で扱っています。

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

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

| コメント               | CLI               | 出力                      |
| ------------------ | ----------------- | ----------------------- |
| /describe          | describe          | PRタイトル・種別・要約・ファイル別説明    |
| /review            | review            | 懸念点・セキュリティ・テスト有無・レビュー工数 |
| /improve           | improve           | コードの修正提案と重要度スコア         |
| `/ask "質問"`        | `ask "質問"`        | PRについての自由質問への回答         |
| /add\_docs         | add\_docs         | 説明の無い関数等へのドキュメント追加      |
| /generate\_labels  | generate\_labels  | 変更内容に応じたラベル             |
| /update\_changelog | update\_changelog | CHANGELOG.mdへの追記        |
| /similar\_issue    | similar\_issue    | 類似Issueの検索（Issue上で実行）   |
| /help              | help              | 使えるツールの一覧               |

`/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では、[圧縮戦略のドキュメント](https://docs.pr-agent.ai/core-abilities/compression%5Fstrategy/)の順で削られます。バイナリや画像を除き、リポジトリで多く使われている言語のファイルを優先し、削除だけの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導入手順](https://docs.pr-agent.ai/installation/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月の[全社導入の記事](https://engineering.dena.com/blog/2025/08/pr-agent/)で、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](https://docs.pr-agent.ai/overview/supported%5Fplatforms/)で次のようになっています。

| ツール                               | GitHub | GitLab | Bitbucket | Azure DevOps | Gitea |
| --------------------------------- | ------ | ------ | --------- | ------------ | ----- |
| describe / review / improve / ask | ○      | ○      | ○         | ○            | ○     |
| コード行への質問                          | ○      | ○      | －         | ○            | －     |
| generate\_labels                  | ○      | ○      | コメント      | ○            | －     |
| update\_changelog                 | ○      | ○      | ○         | コメント         | コメント  |
| similar\_issue                    | ○      | －      | －         | －            | －     |
| Actions・パイプライン実行                  | ○      | ○      | ○         | ○            | －     |

「コメント」は、ラベルやファイルを直接変えられないため結果を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コードレビューを導入する手順](/tech/details/2575/)にまとめています。

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

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

リポジトリ単位の設定は、デフォルトブランチのルートに置いた `.pr_agent.toml` から読まれます。PRのブランチに置いただけでは反映されません。[設定ファイルのドキュメント](https://docs.pr-agent.ai/usage-guide/configuration%5Foptions/)は、既定値の `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` を使っている環境は、すでにこの変更を受けています。影響の大きいものを抜き出しました。

| 版      | 変更                         | 対処                     |
| ------ | -------------------------- | ---------------------- |
| 0.47.0 | ツール失敗でActionが赤になる          | fail\_on\_tool\_errors |
| 0.47.0 | GitLab等は先頭 / のコメントのみ反応     | コメントの書き方を周知            |
| 0.47.0 | Gitea Webhookにシークレット必須     | gitea.webhook\_secret  |
| 0.47.0 | commitable → committable   | 設定名を修正                 |
| 0.48.0 | pipでGit SDKが入らない           | pr-agent\[github\] 等   |
| 0.48.0 | pyproject.tomlの設定を読まない     | .pr\_agent.tomlへ移す     |
| 0.48.0 | 接続先・キー系はリポジトリで設定不可         | ホスト側へ移す                |
| 0.48.0 | 組織共通設定が既定で無効               | global\_settings\_repo |
| 0.48.0 | Webhook用イメージが非root実行       | マウントの権限を確認             |
| 0.48.0 | merge\_recommendationの値が改名 | 出力を解析する処理を修正           |

非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設定](/tech/details/17349/)のほうが早い
- 既にGitHub Copilotの有料プランを契約している：利用枠を確認したうえで[GitHub Copilotのコードレビュー](/tech/details/6229/)を先に試せる
- リポジトリ全体の依存関係を踏まえた指摘が欲しい：PR-Agentが送るのは差分と周辺の文脈で、コードベース全体を索引化する[Greptile](/tech/details/9024/)とは設計が違う
- 週次リリースの追従を誰も見られない：v0.47・v0.48のように破壊的変更が続くため、版を固定して定期的に上げる担当が要る

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

## 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の選び方](/tech/details/2575/)
- [Qodo Mergeとは？現Qodo 2.xの使い方・料金とPR-Agentとの違い【2026年9月】](/tech/details/6871/)
- [CodeRabbit（コードラビット）とは？AIコードレビューの仕組み・料金・安全性【2026年10月】](/tech/details/5812/)
- [GitHub Copilotのコードレビュー｜依頼方法・自動化・日本語化と料金](/tech/details/6229/)
- [Greptileとは？料金・使い方・CodeRabbitとの違い【2026年9月・v5対応】](/tech/details/9024/)

---

出典: [PR-Agentとは？使い方・GitHub Actions/Docker導入と料金【v0.48対応】](<https://www.issoh.co.jp/tech/details/7152/>)（株式会社一創）