本文へスキップ
September 3, 2026

GitHub Issueからプルリクエストまで：Ivy Tendrilにおける計画のライフサイクル

Ivy Tendrilでは、GitHubのIssueが一定のステージ遷移を経てプルリクエストへと昇華します。Webhook経由でIssueがInboxに到着し、エージェントが計画のドラフトを作成し、開発者が計画をレビュー・承認し、エージェントが独立したGit worktree内で実装を実行し、自動検証が走り、開発者がdiffを確認し、エージェントがプルリクエストをオープンします。人間が介入するのは「計画の承認」と「diffの承認」の厳密に2箇所のみです。それ以外の工程はすべてエージェントが自律的に処理し、多数のチケットが同時にこのパイプラインを流れていきます。本記事では、1つのチケットが辿る各ステージを追跡します。

ライフサイクルの概要

Ivyではこのワークフローを「ソフトウェアファクトリー」と呼んでいます。エージェントが作業を推進し、人間が所定のチェックポイントで品質を検査する固定シーケンスです。各ステージ、担当主体、および完了条件は以下の通りです。詳細はライフサイクルドキュメントをご参照ください。

ステージ 実行主体 完了条件
Inbox エージェント（Webhook） Issueのタイトル、本文、ラベル、リンクが保存される
Draft plan エージェント（CreatePlan） 目標、スコープ、変更対象ファイル、検証手順を定めた計画ドラフトが存在する
Plan review（チェックポイント1） 人間 開発者が計画をレビューし、注記や加筆を経て承認する
Execute エージェント（ExecutePlan） エージェントが自身のworktree内で計画の完了を報告する
Verify エージェント テストと静的解析（lint）が実行され、diffがレビュー可能な状態になる（検証ゲート）
Diff review（チェックポイント2） 人間 開発者がdiffを承認する
Pull request エージェント（CreatePr） プルリクエストREST API経由で、計画のブランチに対するPRがGitHub上に作成される
マージとクリーンアップ 人間がマージ、エージェントが掃除 worktreeが削除され、得られた知見がメモリに記録される

Issueの到着から計画承認まで

Issueの到着

ユーザーがリポジトリにIssue #418（「Export to CSV drops rows with commas in the description field.」）を起票しました。GitHub連携により、Webhookを通じてTendrilのInboxに届きます。この時点ではコード実行は行われません。Inboxは受信タスクの一覧であり、どの項目を計画に昇格させるかは開発者が判断します。jam.devからのバグ報告も同様にInboxへ届きます。

CreatePlanによる計画のドラフト作成

開発者はIssueを選択し、「Create plan」を実行します。CreatePlanのpromptwareがIssue本文、リポジトリに関する蓄積メモリ、および関連コードを読み込み、ドラフトを作成します。典型的なドラフトには、達成目標、変更予定ファイル（src/export/csv.tsおよび対応するテストファイル）、実装アプローチ（RFC 4180に準拠し区切り文字を含むフィールドをクォートで囲む）、検証手順（説明フィールドにカンマを含むテストケースを追加し、既存のCSVテストを実行する）が記載されます。作成されたドラフトはDrafts一覧に表示されます。

チェックポイント1：開発者による計画レビュー

これが2つある人的チェックポイントの1つ目です。開発者がドラフトを精読したところ、1点問題が見つかりました。計画では説明フィールドのみをクォートする提案になっていましたが、実際にはすべての自由入力文字列カラムに同じ不具合が波及するためです。手動で計画全体を書き直す代わりに、開発者は該当段落を選択してアノテーションを追加します。「Apply the quoting to all string columns, not just description.（説明だけでなく、すべての文字列カラムにクォートを適用すること）」。UpdatePlanのpromptwareがこの指示を取り込んで計画を瞬時にリライトし、改訂版ドラフトが再提示されます。

ドラフトの具体性が足りない場合はExpandPlanを実行できます。また、アノテーションによって単一チケット内に2つの異なる作業（バグ修正と、CSVモジュールの共通ライブラリへの移行）が含まれていることが判明した場合、SplitPlanによって独立した2つの計画に分割できます。内容に納得した段階で開発者が承認（Approve）します。承認された計画はその実行における確定仕様となり、エージェントが元の曖昧なIssue文面を再解釈することはありません。

実行と検証

ExecutePlanが独立したworktreeで実行

承認を受けると、Tendrilは計画専用のGitブランチとGit worktreeを自動生成し、その中で指定されたエージェントを起動します。エージェントは計画ごとに選択可能です（Claude Code、OpenAI Codex CLI、GitHub Copilot CLI、Google Gemini CLI、OpenCodeなど）。どのエージェントを選択してもワークフロー自体は同一です。

他の計画が同時に並行実行されるため、worktreeによる隔離は不可欠です。各計画が個別の作業ディレクトリとブランチを保持するため、ある計画の仕掛かり中の変更が他の計画を破壊することはなく、レビューが完了するまでメインブランチは一切変更されません。この設計思想の詳細は並列AIエージェントのためのGit worktreesで解説されています。

エージェントが作業を進める間、Jobs画面には出力やツール呼び出しがリアルタイムでストリーミングされます（読み込んだファイル、実行したシェルコマンド、テストの成否、消費トークン数やコストなど）。開発者は進捗を見守ることも、別の計画のレビューに移ることも自由です。Cloudflare Quick Tunnelを有効にすれば、外出先からスマートフォンで同一の実行ログを追跡することも可能です。

自動検証の実行

エージェントが作業完了を報告すると、worktree内で自動検証が実行されます。テストスイートとlinterが実行され、生成されたdiffがレビュー用に収集されます。結果はReview画面の3つのタブ（tests、lint、diff）に整理されます。テストの失敗やlintエラーは、人間がコードを目視確認する前に自動的に検出されます。ProおよびEnterpriseプランでは、CI環境から検証結果をインポートすることも可能です。検証を単なる推奨ではなく厳格なゲートとして扱うべき理由については、AI生成コードのための検証ゲートで詳しく論じられています。

レビュー、プルリクエスト、クリーンアップ

チェックポイント2：開発者によるdiffの確認

これが2つ目の人的チェックポイントです。開発者はReview画面で、計画内容および検証結果と突き合わせながらdiffを精査します。Issue #418の場合、diffはsrc/export/csv.tsを更新してエスケープ用ヘルパー関数を追加し、テストファイルに3つのケース（カンマ、クォート、フィールド内改行）を追加しています。全テストがパスし、lintもエラーゼロです。開発者はdiffを承認します。

もしdiffの内容に問題があれば、承認を保留し、不足要件を計画に追記して再実行させます。この人間による明示的な承認なしにコードがGitHubへ送られることはありません。

CreatePrによるプルリクエストの作成

CreatePrのpromptwareが、計画ブランチからGitHubプルリクエストを自動作成します。ここからは、チームの通常のGitHub上でのコードレビューおよびマージ手順へとシームレスに移行します。TendrilのPull Requests画面では、このフローで作成された全オープンPRのステータスが集約管理されます。

マージ後の処理

PRがマージされると、Tendrilは該当のworktreeをディスクから自動削除します。続いてExecutePlanのpromptwareが、今回の作業で得られた知見をメモリに保存します。このチケットの場合、「The export module has an integration test that needs the fixtures in test/fixtures/export/; run it with pnpm test:export」のような知見が記録され、将来エクスポートモジュールを変更する別の計画が開始される際に自動参照されます。

この規模のチケットであれば、全工程にかかる時間はわずか数分のエージェント処理と、人間の2回のごく短い確認作業のみです。Ivyの自社開発チームでは、この2箇所のチェックポイントを厳格に維持したまま、1日あたりのプルリクエスト作成数が従来の約10件から100件以上へと拡大しました。

導入手順

Tendrilをインストールし、GitHub連携を設定してIssueがInboxに自動連携されるようにします。まずは単一エージェントで1つのチケットを完走させ、その後に並列運用へ移行することをお勧めします。

curl -sSf https://cdn.ivy.app/install-tendril.sh | sh

Windowsの場合は irm https://cdn.ivy.app/install-tendril.ps1 | iex を実行してください。Functional Source Licenseのもとでソースコードが公開されている無料版でも、ライフサイクルの全機能を利用できます。ProおよびEnterpriseプランでは、チーム機能、CI検証連携、オンプレミスホスティングなどが提供されます。

よくある質問

変更規模が極小の場合、チェックポイントをスキップできますか？

スキップできません。2つのチェックポイントはすべての計画に等しく適用されます。1行の修正であっても、通常の計画と同様に計画承認とdiff承認を経由します。規模の小さい計画であれば、レビューにかかる時間もわずかです。

2つの並列計画が同一ファイルを変更した場合はどうなりますか？

各計画は独立したworktreeとブランチで動作するため、実行中に競合が発生することはありません。競合は2つ目のプルリクエストをリベースまたはマージする際に顕在化し、通常のGit手順に従って解消されます。モジュール単位で計画を適切に分割しておくことで、競合の発生確率を大幅に低減できます。

IssueはGitHubからしか取り込めませんか？

いいえ。手動入力したテキスト、jam.devのバグ報告、CLI、REST API、またはMCPサーバー経由でも計画を開始できます。GitHubのWebhookはInboxへの入力経路の1つに過ぎません。

Ivy Tendrilで開発を加速する

開発者レベルの並列エージェントオーケストレーションを体験しませんか？

Written by

Ivy Team