AIエージェントによるフォークメンテナンスの自動化 | Cohere

あなたはフォークを維持している。アップストリームが動く。同期すると、何かが壊れ、それを修正し、検証し、リリースする。数週間後、アップストリームが再び動く。このサイクルが繰り返される。

本稿では、AIコーディングエージェントを使用してこのサイクルを自動化する一般的な方法を説明します。この方法をCohereのvLLMフォークに適用し、定期的なアップストリームリリースがCohereのcohere-transcribe-03-2026 ASRモデルを静かに壊し、修正がvLLMのPRとしてアップストリームに還流した具体例を示します。

実際には、このアプローチにより、新しいアップストリームリリースを吸収する時間が数週間から数日に短縮され、人間は最終結果をレビューするだけです。このワークフローを支えるスキルは、cohere-ai/vllm-skillsでオープンソース化されています。

問題

活発に開発されているプロジェクトの長期フォークを維持することは、継続的なコストです。しかし、アップストリームリリースには、新機能、パフォーマンスの改善、バグ修正も含まれており、これらは必要です。同期を維持することはメンテナンスであるだけでなく、フォークを改善し続ける方法でもあります。問題は、すべてのアップストリームリリースが混乱（マージ競合、API変更、関数削除、新しい依存関係、テストの失敗）をもたらすことです。フォークメンテナの仕事は、その混乱を吸収し、正常な状態を回復することです。

この作業の構造は常に同じです。

1. 新しいアップストリームバージョンをフォークに同期する。
2. テスト、ベンチマーク、評価を実行して何が壊れたかを測定する。
3. 競合を修正し、API変更に適応し、テストを更新する。
4. すべてが合格するまでステップ2〜3を繰り返す。
5. 更新されたフォークをリリースする。

これはフィードバックループです。フォークを維持するすべてのチームにすでに存在しますが、遅くて手動です。CohereのvLLMフォークでは、典型的なアップストリームリリースの吸収に以前は数週間の断続的な開発者の注意が必要でしたが、以下に説明する作業の目標は、これをほとんど無人で稼働するエージェント時間の数日に短縮することです。

フィードバックシステム

制御理論では、閉ループシステムは出力を基準と継続的に比較し、ギャップを埋めるために調整します。しかし、実際のシステムは外乱にも直面します。システムを望ましい状態から遠ざける外部入力です。

• r(t)は基準、システムが生成すべき望ましい値。
• y(t)は出力、システムが実際に生成する値。
• e(t)は誤差、基準と測定値の差（r(t) − measured_output）。
• d(t)は外乱、出力を基準から遠ざける外力。

コントローラは誤差を使用してシステムを調整し、フィードバックによって出力を目標に近づけます。適切に設計されたフィードバックループは、基準を追跡するだけでなく、出力への影響を検出して誤差を手動介入なしにゼロに戻すことで外乱を抑制します。

クルーズコントロールが典型的な例です。希望速度（基準）を設定し、車がそれを維持しますが、丘や向かい風（外乱）が現れます。優れたコントローラは速度低下に気づき、自動的にスロットルを調整します。

フォークメンテナンスはまったく同じ構造を持っています。

フォークメンテナンス：

• r(t)：最新のアップストリーム上でカスタム変更が正しく動作すること
• d(t)：新しいアップストリームリリース（競合、API変更、破壊的変更）
• コントローラ：競合解決、パッチ更新、テスト修正
• システム：フォーク自体（コード、テスト、CI）
• y(t)：同期後のフォークのランタイム動作
• 測定：テストスイート、ベンチマーク、評価
• 誤差：期待される動作と実際の同期後の動作の差

目標はループ全体（同期、測定、修正、繰り返し）を自動化し、最小限の人間の介入でアップストリームの改善を吸収することです。

エージェント以前のプロセス

フォークをアップストリームと同期する方法はいくつかあります。マージ、チェリーピック、リベースが最も一般的です。マージは両方の履歴を保持しますが、カスタム変更とアップストリームを区別しにくい乱雑なコミットグラフを生成します。チェリーピックは正確な制御を提供しますが、アップストリームがリリースごとに数百のコミットを移動する場合にはスケーリングしません。結局、同期がずれる増え続けるピックリストを維持することになります。リベースはカスタムコミットを新しいアップストリームタグの上にリプレイし、カスタムパッチが明確に上部にあるクリーンで線形の履歴を生成します。トレードオフは、リベースが履歴を書き換え、フォースプッシュを強制することですが、高速に動くアップストリームの上に少数のカスタムコミットがあるフォークでは、明確さに見合う価値があります。

Cohereでは、早期にリベースに落ち着きました。以下に説明するエージェントベースのワークフローの前に、私たちのパイプラインはすでにスクリプト自動化と手動作業を組み合わせていました。

• リベース：GitHub Actionsワークフローがターゲットアップストリームタグへのリベースを試み、共有git rerereキャッシュから以前に解決された競合をリプレイします。
• 競合解決：ワークフローの自動リベースが失敗すると、開発者がローカルで引き継ぎ、残った競合を手動で解決し（多くの場合LLMアシスタントを使用）、CIを検証し、更新されたrerereキャッシュをアップロードします。
• 検証とリリース：リベースされたブランチでCIがグリーンになると、それがフォークの新しいベースになります。

このプロセスはすでに複数の種類の自動化を組み合わせています。git rerereは既知の解決策をリプレイし、GitHub Actionsはリベース試行とCIを実行し、LLMは個々のコーディングおよびデバッグタスクを支援します。しかし、人間は依然としてコントローラの一部であり、ピースをまとめ、どの修正を適用するかを選択し、いつ再実行するかを決定します。フィードバックループは機能していますが、遅いだけです。以下に説明するエージェントベースのワークフローは同じ構造を維持しますが、エージェントにコントローラの役割を任せることで、反復がマシンスピードで行われ、人間は端でのみ介入します。

各コンポーネントの自動化

この方法はループを3つのエージェント自動化可能なコンポーネントに分解し、それぞれを制御図の一部にマッピングします。

1. 外乱注入

エージェントスキルが新しいアップストリームリリースを検出し適用します。フォークを新しいタグにリベースし、マージ競合を自動的に解決します。これがシステムに入る外乱です。一時的に物事を壊すことがわかっている意図的な自動アクションですが、できるだけ早く吸収したいものです。

スキルに必要なこと：

• フォークが現在ベースとしているアップストリームタグを検出する
• 新しいタグが存在するか確認する
• git rebase --ontoをフォークのカスタムコミットで実行する
• 競合を解決する（アップストリームの差分コンテキストを使用して情報に基づいた決定を行う）

2. 測定収集

リベース後、フォークは未知の状態にあります。測定によって、目標（すべてのカスタム動作が無傷の動作フォーク）からどれだけ離れているかがわかります。それがなければ、エージェントは盲目的に飛ぶことになります。

測定自体（テスト、ベンチマーク、評価）はプロジェクトによって定義され、自動化の前にすでに存在しています。エージェントが自動化するのはその収集です。環境のセットアップ、検証スイートの実行、結果の報告方法を知っているテストランナースキルです。

• テスト：ユニットテスト、統合テスト、正確性テスト
• ベンチマーク：パフォーマンスチェック（スループット、レイテンシ、リソース使用量）
• 評価：ドメイン固有の品質指標（精度、 perplexity、タスクスコア）

出力は誤差信号です。どのテストが失敗し、どのベンチマークが後退し、どの評価が低下したか。測定が豊かで信頼性が高いほど、コントローラは速く収束できます。テストスイートが薄いフォークは弱い信号を与え、エージェントは何が壊れているか、完了にどれだけ近いかを知りません。

3. コントローラ

エージェントスキルがループを閉じます。リベースが完了し測定結果が戻ってきた後、スキルは：

• テストとベンチマークの結果を読み取る
• 失敗と後退を特定する
• 修正を適用する（ビルドエラーの解決、壊れたテストの更新、API変更への適応）
• 測定を再実行する
• すべての測定が合格するまで繰り返すか、人間にエスカレーションする

これが誤差をゼロに駆動するコントローラです。重要な洞察は、エージェントが最初の試行でリベースを正しく行う必要はなく、反復すればよいということです。開発者とまったく同じです。

ケーススタディ：vLLM

vLLMはオープンソースのLLMサービングエンジンです。Cohereでは、モデル開発中のRLロールアウトや評価から本番環境でのユーザーリクエスト処理まで、推論スタック全体で使用しています。私たちは、カスタムコミット（追加モデルサポート、カスタムカーネルと最適化、変更されたエントリポイント、追加テスト）を保持するためにフォークを維持しています。これらの一部はアップストリームに提案中であり、他は当社の特定のニーズに固有のものです。課題は、これらのコミットを各新しいアップストリームリリースに何も壊さずにリプレイすることです。アップストリームは約数週間ごとにリリースをカットし、それぞれが大規模で、タグ間の差分は多くの場合数百のファイルに及びます。

スキルスタック

私たちは5つのスキルを構築し、cohere-ai/vllm-skillsでオープンソース化しました。これらは一般的なパターンを具体化したものです。各スキルはマークダウンドキュメントであり、コーディングエージェントが読み取り、インタラクティブに実行します。エージェントはターミナル、ファイルシステム、および必要なツールにアクセスできます。

• install-vllm：環境設定。uv仮想環境を作成し、vLLMを編集可能モードで正しいプリコンパイル済みCUDAホイールとともにインストールします。
• local-test-runner：測定。NVIDIA GPU上でローカルにBuildkite CI相当のテストを実行し、.buildkite/test_areas/*.yamlを解析し、HuggingFaceトークンを管理し、ログをキャプチャします。
• detect-upstream-base：外乱検出。git merge-base + git describeを介してフォークが現在ベースとしているアップストリームタグを見つけます。
• rebase-assistant：コントローラ。カスタムコミットをv1からv2にリベースし、アップストリームの差分をコンテキストとして使用して競合を解決し、test-runnerで結果を検証します。
• Orchestrator：ghを介して新しいアップストリームリリースをチェックし、detect-upstream-baseとrebase-assistantをエンドツーエンドで呼び出します。

リベースの実行方法

このセクション：v1/v2は古い/新しいアップストリームタグ、b1/b2はリベース前後のフォークブランチ。

典型的な呼び出し：「/auto-rebase sync the current branch with the latest upstream release and make sure passes.」

auto-rebaseは前提条件（gh auth status）をチェックし、detect-upstream-baseを呼び出してv1（例：v0.19.0）を見つけます。 アップストリームタグをフェッチし、v2（v0.19.1）を発見します。ユーザーにリリースを提示し、確認を待ちます。 ユーザーから検証チェックを収集します（例：pytest tests/entrypoints/openai/correctness/test_transcription_api_correctness.py）。 rebase-assistantを呼び出します。rebase-assistantは：

• b1上のカスタムコミットを分析します（git log v1..HEAD）
• 最初にb1でテストが合格することを確認します（local-test-runnerとv1ホイールを使用）。これは既知の良好なベースラインを保証するゲートです。
• b1をバックアップし、b2を作成し、必要に応じてカスタムコミットをスカッシュします
• git rebase --onto upstream/v0.19.1 HEADを実行します
• upstream/v1..upstream/v2の差分を比較して何が変更されたかを理解し、競合を解決します
• b2でテストを実行します（local-test-runnerとv2ホイールを使用）
• テストが失敗した場合：失敗を検査し、v1ベースラインと比較し、修正を適用し、再実行します（内部フィードバックループ）
• すべてのチェックが合格すると、auto-rebaseはサマリー（リプレイされたコミット、解決された競合、テスト結果）を表示し、プッシュを提案します。

スキルインタラクションのシーケンスとして：

• 内部ループは、コントローラがb2で反復することです。local-test-runnerが失敗を報告し、rebase-assistantが修正を適用して再実行し、テストが合格するまで続けます。

実例：Cohere Transcribe on v0.19.1

これは、このループのエンドツーエンドの実際の呼び出しです。

セットアップ：フォークはcohere-transcribe-v0.19.0にあり、アップストリームv0.19.0の上に1つのカスタムコミットがあり、Cohereのcohere-transcribe-03-2026 ASRモデルの正確性テストを有効にします。vLLMはv0.19.0でこのモデルアーキテクチャのサポートを追加しましたが、ウェイトがまだ公開されていなかったため、アップストリームテストはコメントアウトされていました。カスタムコミットは1行のコメントを解除するだけです。

テストはearnings-22検証セットのフィルタリングされたスライスでモデルを実行し、WER ≤ 11.92をアサートします。この単一の数値が測定信号y(t)です。フォークが健全な場合、数値は11.92付近に留まります。何かが壊れると、数値は急上昇します。

外乱：アップストリームがv0.19.1をカットしました。

（原文はAIコスト制御のため省略されています。）