Claude Managed Agents を利用して Linear/GitHub Issue で PR 作成からレビューループまで回す方法

2026/6/13 1:112026/6/15 15:48

投稿日

2026/6/12

タグ

Managed Agents

執筆者

imageTakuya Hasegawa

メディア統括本部 サービスリライアビリティグループ（SRG）の長谷川（@rairureluis）です。

#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 は、長時間稼働のタスクをクラウド上のサンドボックスで実行するためのインフラです。

セッションは状態を持ち続け、ツール実行・ファイルシステム・会話履歴がサーバー側に永続化されます。

開発者は自分でエージェントループやサンドボックスを構築する必要がなく、タスクの定義と成功条件を宣言するだけで、エージェントが結果に向けてイテレーションします。

システムの構成と動作フロー

全体アーキテクチャ

Claude Managed Agents から外部の Remote MCP（Model Context Protocol）を接続するために Zero Trust を利用しているため複雑に見えてしまっていますが、案外シンプルです。このシステムは、Parent coordinator と Child implementer に役割を分ける二層構造で設計されています。

Parent は Issue の読み取り・分解・進行管理を担い、Child は割り当てられたサブタスクの実装に集中します。

デフォルト設定では、親モデルに claude-fable-5 を、子モデルに 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（Web ユーザーインターフェース）を持っています。

💡

1. リポジトリを登録する

最初に登録するのは owner/name 形式の対象リポジトリです。

前述した複数のリポジトリで実装するために、必要な作業となります。

Claude Managed Agents は、登録済みのリポジトリと Issue の内容を基に、どのリポジトリで作業を行うかを判断します。

Run が始まると、セッション ID、フェーズ、サブイシュー、ログ、完了/失敗イベントが記録されます。

Web UI は /api/runs/:runId/events の Server-Sent Events (サーバー送信イベント) を使って進捗を表示するため、長時間の実装でも「いま何をしているか」を追跡しやすくなっています。

💡

Claude Console の方が詳細に表示されるので、そちらの方が良かったりします 🐶

4. プロンプトを Web UI から育てられる

parent.system / child.system のシステムプロンプトは 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 前に相談できる

リポジトリ詳細から Repository chat (リポジトリチャット) を開くと、その repo 専用の読み取り専用チャットが使えます。

画面上では、リポジトリ設定、MCP 利用状況、リポジトリ内容、最近の実行をコンテキストに含めるか選べます。

いきなり Issue を Agent に投げる前に、「この repo の設定は足りているか」「MCP は使える状態か」「最近の失敗はあるか」を確認できる導線です。

実装のこだわり

• Bun + Hono + SQLite の小さな構成：WebUI、Run API、イベント保存、プロンプト管理を 1 つの HTTP サーバーにまとめています。ローカルでも Fly.io でも動かしやすい構成です。
• GitHub App 前提のリポジトリスコープトークン：対象リポジトリごとにインストールトークンを解決するため、複数リポジトリを扱う運用でも権限を絞りやすくなっています。
• Parent / Child のマルチエージェントコーディネーター：Parent が分解と最終 PR を担当し、Child が実装を担当します。役割分担が明確なので、プロンプト設計と責務分離を記事で説明しやすい構成です。
• カスタムツールの最小限への限定：Parent に公開されるカスタムツールは create_sub_issue と create_final_pr が中心です。MCP ツールは DB の MCP サーバー設定からエージェント定義に入るため、アプリ側のカスタムツールが肥大化しにくくなっています。
• プロンプト管理：parent.system / child.system は WebUI から編集でき、ランタイムテンプレートは読み取り専用です。運用しながらプロンプトを改善する導線があります。
• 観測可能性：セッションイベント、スレッドイベント、ツールの使用・結果を保存し、SSE で画面へ流します。エージェントがブラックボックスになりすぎない点は、導入検討者にとって重要です。

終わりに

Claude Managed Agents は現在 Claude Platform 上でパブリックベータとして提供されており、利用には Anthropic の API キーが必要です。

Issue ドリブンな開発フローを自動化したい方や、レビューループの解消に時間を取られている方にとってはぜひ触っていただきたいツールとなっています。

利用開始までのハードルは低いので、ぜひ使ってみてください。

Issue / PR も歓迎です！

SRG では一緒に働く仲間を募集しています。

ご興味ありましたらぜひこちらからご連絡ください。