Claude Managed Agents を利用して Linear/GitHub Issue で PR 作成からレビューループまで回す方法
#SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。
本記事では、Linear / GitHub Issue の読み込みから PR 作成・レビューループの自動解消までを Claude Managed Agents で実現する方法を解説します。
開発者が手作業によるコンテキストスイッチから解放され、Issue ドリブンな開発フローをより滑らかにするための実践例として紹介します。
Issue 対応の手作業をどうにかしたい動作デモ1. Issue URL または Number を入力する2. コーヒーを飲みながら待つ3. 完了maestro とは何かシステムの構成と動作フロー全体アーキテクチャWeb UI からの起動Orchestrator の動作PR 作成とレビューループこのワークフローが解決すること複数リポジトリを前提に実装実画面で見る Web UI1. リポジトリを登録する2. Issue を入力して Run を開始する3. 実行履歴とリアルタイム進捗を見る4. プロンプトを Web UI から育てられる5. MCP Client 設定を Web UI で管理できる6. リポジトリごとのチャットで、Run 前に相談できる実装のこだわり終わりに
この記事は AI で出力した後に筆者が添削しています。
Issue 対応の手作業をどうにかしたい
ソフトウェア開発において、Issue が積まれるたびに内容を読み込み、実装し、PR を作成し、レビューコメントに対応するというサイクルは非常に手間のかかる作業です。
特に、コードレビューツールが複数のコメントを返してくるたびに修正と再レビューを繰り返す場面では、開発者のコンテキストスイッチが頻発し、生産性が下がるという問題があります。
この課題を解決するために開発されたのが、maestro です。
動作デモ
E2E テストで利用しているリポジトリがあるので実際の PR をご覧ください。
1. Issue URL または Number を入力する
2. コーヒーを飲みながら待つ
3. 完了
maestro とは何か
maestro は、Linear Issue または GitHub Issue の URL を Web UI から入力するだけで、Issue の読み込みから PR 作成、さらにレビューループの解消までを自動化するエージェントワークフローです。
Anthropic が提供する Claude Managed Agents は、長時間稼働のタスクをクラウド上のサンドボックスで実行するためのインフラです。
セッションは状態を持ち続け、ツール実行・ファイルシステム・会話履歴がサーバー側に永続化されます。
開発者は自分でエージェントループやサンドボックスを構築する必要がなく、タスクの定義と成功条件を宣言するだけで、エージェントが結果に向けてイテレーションします。
システムの構成と動作フロー
全体アーキテクチャ
このシステムは、Parent coordinator と Child implementer に役割を分ける二層構造で設計されています。
Parent は Issue の読み取り・分解・進行管理を担い、Child は割り当てられたサブタスクの実装に集中します。
デフォルト設定では、parent model に claude-fable-5、child model に claude-sonnet-4-6 を使います。
この分担により、司令塔はタスクの分解・検証・PR 作成に集中し、実装担当はコード変更に集中できます。
大きな Issue をそのまま 1 つのプロンプトに投げるのではなく、追跡可能な単位へ落とし込むのがポイントです。
また、parent/child agent は Anthropic 側の Agent registry でバージョン管理され、system prompt や MCP server の構成変更を次回以降の実行へ反映しやすい設計になっています。
Web UI からの起動
ユーザーは Web UI から Linear Issue または GitHub Issue の URL を貼り付けて実行します。
入力された URL をトリガーとして、Orchestrator がセッションを開始します。
Orchestrator の動作
Orchestrator は Issue の内容を解析し、実装に必要な子 Issue を自動で生成します。
GitHub / Linear のsub-Issue 機能を活用することで、大きなタスクを管理可能な単位に分解し、各タスクの進捗を追跡できるようにします。
その後、Sonnet 4.6 による実装セッションが起動し、子 Issue の内容に従ってコードが生成されます。
PR 作成とレビューループ
実装が完了すると、Orchestrator は GitHub に対して PR を自動作成します。
PR が作成されると、Greptile などによる AI コードレビューが実行されます。
Orchestrator は AI レビューが残っている限り、修正と再レビューのサイクルを自動で繰り返します。
レビューコメントがゼロになった時点でループが終了し、PR がマージ可能な状態になります。
ただ指摘されたレビューを鵜呑みにせず、一旦サブエージェントで検証させてからその指摘が Valid であれば修正するというプロンプトを埋め込んでいます。
このワークフローが解決すること
従来の開発フローでは、Issue を確認してから PR がレビュー通過するまでの間に、人間が何度も介入する必要がありました。
このシステムは以下の作業をすべて自動化します。
- Issue の解析と子 Issue への分解
- コード以外のコンテキスト収集
- CLAUDE.md, AGENTS.md, .claude/rules などのルール
- MCP によるドキュメントなどの調査
- コードの実装
- PR の作成
- レビューコメントへの対応と再プッシュ
- レビュー、テストが通過するまでのループ制御
Claude Managed Agents では Agent（モデル・system prompt・tools・MCP server などの定義）と Session（実行単位）が分かれており、実行履歴や tool use、multi-agent thread の状態をイベントとして追跡できます。
Web UI ではこのイベントを SSE で受け取り、進捗をリアルタイムに表示します。
一方で Claude Managed Agents はベータ機能のため、無制限に自動化できる前提ではなく、roster や同時 thread 数などの制約があります。
この記事で紹介している構成も、人間が最終判断しやすいように Issue・PR・レビュー履歴を GitHub / Linear 上に残す設計にしています。
複数リポジトリを前提に実装
実行画面には、どのリポジトリで作業するのかが記載されていないことに気づかれたかと思います。
例えば Issue 内容によって A リポジトリだけでなく、Terraform や Helm などを管理している別リポジトリの変更も必要になると思います。
そのため、どのリポジトリで、どの順番で実装をすべきかを考慮し複数のリポジトリで実装できるようにしています。
実画面で見る Web UI
記事だけで読むと抽象的に見えますが maestro は CLI だけの実験ツールではなく、Issue を投入して進捗を追える HTTP サーバー型の WebUI を持っています。
1. リポジトリを登録する
最初に登録するのは 形式の対象リポジトリです。
前述した複数のリポジトリで実装するために、必要な作業となります。
Claude Managed Agents は登録されたリポジトリと Issue 内容からどのリポジトリで作業するかを決定します。
登録済みリポジトリは SQLite に保存され、GitHub trigger poller もこの一覧を参照します。
これにより、環境変数だけに依存せず、運用中に監視対象リポジトリを追加・停止しやすくなっています。
2. Issue を入力して Run を開始する
新規実行画面では GitHub Issue または Linear Issue を指定して Run を作成します。
GitHub Issue であれば issue number と repo、Linear であれば URL / identifier を起点にできます。
Dry-run を使えば、いきなり PR 作成まで進めずに、まず decomposition plan だけを確認できます。
3. 実行履歴とリアルタイム進捗を見る
Run が始まると、セッション ID、フェーズ、sub-issue、ログ、完了 / 失敗イベントが記録されます。
WebUI は の Server-Sent Events を使って進捗を表示するため、長時間の実装でも “いま何をしているか” を追いやすくなっています。
Claude Console の方が詳細に表示されるので、そちらの方が良かったりします 🐶
4. プロンプトを Web UI から育てられる
/ の system prompt は Web UI から編集できます。
maestro は Agent 更新ごとにバージョンが作られ、Session は作成時点のバージョンに固定されるため、実行中の Run を壊さず次の Run 向けに改善しやすいように実装しています。
5. MCP Client 設定を Web UI で管理できる
MCP サーバー画面では、MCP server name、URL、token env var、permission policy、enabled / disabled を Web UI から登録できます。
クレデンシャルは maestro を実行しているコンテナに与えられた環境変数名を指定します。
トークン実値ではなく環境変数名だけを持つ設計なので、秘密情報を Web UI の DB に直接保存しません。
Claude Managed Agents 公式ドキュメント上も、Agent 定義には server name / URL を置き、認証情報は Vault 側で扱う整理です。
6. リポジトリごとのチャットで、Run 前に相談できる
リポジトリ詳細から を開くと、その repo 専用の read-only chat が使えます
画面上では、リポジトリ設定、MCP 利用状況、リポジトリ内容、最近の実行をコンテキストに含めるか選べます。
いきなり Issue を agent に投げる前に、“この repo の設定は足りているか”、“MCP は使える状態か”、“最近の失敗はあるか” を確認できる導線です。
実装のこだわり
- Bun + Hono + SQLite の小さな構成: WebUI、Run API、イベント保存、Prompt 管理を 1 つの HTTP サーバーにまとめています。ローカルでも Fly.io でも動かしやすい構成です。
- GitHub App 前提の repo-scoped token: 対象リポジトリごとに installation token を解決するため、複数リポジトリを扱う運用でも権限を絞りやすくなっています。
- Parent / Child の multi-agent coordinator: Parent が decomposition と最終 PR を担当し、Child が実装を担当します。役割分担が明確なので、プロンプト設計と責務分離を記事で説明しやすい構成です。
- custom tool を最小限に限定: Parent に公開される custom tool は と が中心です。MCP tool は DB の MCP server 設定から agent definition に入るため、アプリ側の custom tool が肥大化しにくくなっています。
- Prompt Management: / は WebUI から編集でき、runtime template は read-only です。運用しながらプロンプトを改善する導線があります。
- 観測可能性: session event、thread event、tool use / result を保存し、SSE で画面へ流します。エージェントがブラックボックスになりすぎない点は、導入検討者にとって重要です。
終わりに
Claude Managed Agents は現在 Claude Platform 上でパブリックベータとして提供されており、利用には Anthropic の API キーが必要です。
Issue ドリブンな開発フローを自動化したい方や、レビューループの解消に時間を取られている方にとってはぜひ触っていただきたいツールとなっています。
利用開始までのハードルは低いので、ぜひ使ってみてください。
Issue / PR も歓迎です！
SRG では一緒に働く仲間を募集しています。
ご興味ありましたらぜひこちらからご連絡ください。