Claude Codeのバックグラウンドエージェントとは｜PRで安全に成果を受け取る

「バックグラウンドで動かしたエージェントが、勝手にコミットしてリモートにプッシュしていた」——無人でAIにコードを任せ始めたとき、多くの人がこの手放しの不安を抱えます。

結論から言うと、Claude Codeのバックグラウンドエージェントは、いまや作業を終えると自分でcommit・push・ドラフトPR（プルリクエスト）まで進めるようになりました。便利さと引き換えに「無人で本番に触れる」怖さも生まれます。安全に使う鍵は、成果をPRという“提案の箱”で受け取る設計にあります。

株式会社Fyveは、SNS発信やSEO記事の下書きを毎日無人のClaude Codeエージェント（社内では「Smith」と呼ぶ常駐ジョブ群）に走らせています。この記事では、その実運用で確立した「無人エージェントの成果を事故なく受け取る」型を、1人〜少人数の運用目線でお伝えします。

バックグラウンドエージェントが「commit・push・ドラフトPR」まで進むようになった

Claude Codeのバックグラウンドエージェントとは、対話画面の裏で独立して作業を進めるエージェントのことです。従来は、コードを書き終えると「コミットしていいですか？」と手を止めて確認を待っていました。

ここが2026年7月1日リリースのv2.1.198で変わりました。claude agents から起動したバックグラウンドエージェントが、Gitのworktree（作業ツリー）＋GitHubリモートという条件のもとで作業を終えると、自動でコミット・プッシュし、ドラフトPRを開くようになったのです（現行は v2.1.205）。手番が1つ減り、結果だけがPRとして届く、という体験です。

「止まって聞く」から「PRにして置いておく」へ

この変化の本質は、AIの働き方が「作業のたびに人を待つ」から「成果をまとめて差し出す」へ移ったことです。人はPRの一覧を見て、できあがったものだけを後からレビューできます。無人で長時間動かす運用と相性が良い設計です。

ドラフト（下書き）止まりという“わざと引いた線”

重要なのは、エージェントが開けるのはドラフトPRだけという点です。ドラフトPRは自動マージされず、レビュアーの自動割り当てもかかりません。「レビュー可」に昇格させてマージする最後の一手は、必ず人間が行う——この境界は意図的に引かれており、設定でオフにはできません。

実際、GitHubのIssueには「この自動push・自動PRを無効化する設定が欲しい」という要望も上がっています。それだけ「機械にどこまで任せ、どこで人が受け取るか」の線引きが、現場の関心事になっているということです。

1人運用で怖いのは「勝手にpushされる」こと

便利な一方で、無人エージェントが本番のブランチに直接コミット・プッシュできる状態は、1人運用ほど危険です。レビューする同僚がいないぶん、間違ったまま push されたものが、そのまま本番の記録になってしまうからです。

私自身、無人ジョブの本番運用で痛い目を見たことがあります。テストでは踏まなかったバグが、実際に1本走らせて初めて表面化したのです。あるジョブが、記録用の台帳ファイルを本来と違う場所へ書き込んでいた——手動確認では気づけず、無人で走らせた1回で露見しました。

ここから得た教訓は明確です。「無人化は、本番を1本通してみて初めて安全性がわかる」。だからこそ、AIが触れてよい範囲と、人が受け取る関所を、あらかじめ仕組みで縛っておく必要があります。

読者特典・無料ダウンロードClaude Codeを「素のまま」使うな無料でダウンロード →↓

無人エージェントの成果を安全に受け取る4つの設計

私が無人のClaude Codeエージェントを毎日走らせるうえで守っている、4つの原則を紹介します。バックグラウンドエージェントのPR自動化を使うかどうかに関わらず、無人運用の土台になる考え方です。

① 書き込む場所を「物理的に」境界化する

いちばんの学びは、「◯◯だけ触っていい」という指示は、文章で書いただけでは強制力がゼロだということです。プロンプトにルールを書いても、エージェントの判断ひとつで越えられてしまいます。

そこで私は、無人ジョブの共通ランナーに「境界関所」を実装しました。成功時のコミット対象を、全体（git add -A）から指定フォルダ（git add smith/）だけに絞ったのです。範囲外の変更はコミットされず、次回のリセットで自動的に破棄されます。さらに、範囲外への書き込みを検知したら通知を飛ばす。「指示」ではなく「仕組み」で境界を守らせる、という発想です。

② 単一書き手にして、衝突をそもそも起こさない

複数のセッションやジョブが同じファイルを別々に書き換えると、統合時に衝突が起きます。私は、ある領域の台帳やデータは「書き手を1つのジョブに固定する」ルールにしました。誰が書くかを一意にするだけで、無人運用の衝突事故は激減します。

③ pushを一元化して、日中は本番に流さない

複数のエージェントが並走する前提では、各セッションは日中コミットまでに留め、リモートへの統合（push）は1日1回・決まったタイミングに一元化しています。無人エージェントに「その場でpushさせない」だけで、本番が予期せぬ状態になる事故を構造的に防げます。

④ 「機械は下書きまで、公開は人」を徹底する

この記事自体、無人のSEO執筆ジョブが書いた下書きです。ただし、そのジョブが持つ権限は下書き保存（draft）だけに絞ってあり、公開のAPIは構造的に叩けません。公開の最終判断は、必ず人間が別のセッションで行います。

これは、先ほどのドラフトPRの思想とまったく同じです。機械は「提案」まで、承認と公開は人。この一線を守るかぎり、無人化を進めても取り返しのつかない事故は起きません。

PRで受け取る運用に落とすと、何が変わるか

ここまでの4原則を、Claude Codeのバックグラウンドエージェント＋ドラフトPRという新機能に重ねると、役割分担がきれいに揃います。

• エージェント側：worktreeで作業し、終わったらコミット・プッシュしてドラフトPRを開く（＝提案を差し出す）
• 人間側：PRの一覧を見て、内容を確認し、「レビュー可」へ昇格させてマージする（＝承認して受け取る）

1人運用でも、この形は効きます。自分が書いた同僚のように、後から落ち着いてPRをレビューし、納得したものだけを本番へ入れる。ドラフトPRは、無人エージェントと自分の間に置く“承認の関所”そのものだからです。

逆に言えば、この機能を安全に使う前提は「本番へ直接触らせない・提案として受け取る」という運用設計側にあります。機能をオンにするだけでは足りず、①〜④のような境界を自分の環境に用意しておくことが、事故なく無人化を伸ばす条件になります。

関連記事

バックグラウンドで放置しても作業が進む仕組みの基本は、こちらで解説しています。

Claude CodeClaude Codeのバックグラウンドセッション｜放置で進む

無人で任せても事故りにくくするための安全側の設計は、Auto Modeの強化と併せて読むと理解が深まります。

Claude CodeAuto Modeの安全強化｜AIに任せても事故りにくい理由

バックグラウンドで動くサブエージェントの権限を、本体に集約して安全に放置する考え方はこちらです。

Claude CodeClaude Codeのバックグラウンドsubagent、権限確認が本体に集約｜放置運用が安全に

まとめ：機能はオン、境界は自分で引く

Claude Codeのバックグラウンドエージェントが、commit・push・ドラフトPRまで自走するようになったのは、無人運用を大きく前に進める変化です。ただし、その力を安全に活かせるかどうかは、「機械は提案まで、承認と公開は人」という境界を、仕組みとして用意できているかにかかっています。

場所を物理的に区切り、書き手を1つにし、pushを一元化し、下書きまでで止める。私（株式会社Fyve）が毎日の無人運用で守っているのは、この4つだけです。バックグラウンドエージェントを使い始める前に、まず自分の環境に“受け取りの関所”を置くところから始めてみてください。