エージェントがPRを作成した瞬間に文脈が切れる — Nxが埋めるCI自動化の隙間

PRは作成されたのに、赤いCIはまた人の仕事です

AIエージェントが機能を実装し、ローカルテストを経てPRまで作成しました。しかし、リモートCIでのみ失敗が起きると、流れが途切れます。人が通知を確認し、ログをコピーして、失敗した文脈をもう一度説明して初めて、エージェントは次の修正を始められます。

Nxが埋めようとしている隙間はコード生成ではなく、PR後の情報の断絶です。ローカルエージェントがNx Cloudのパイプライン状態、失敗したタスクの出力、Self-Healing CIの修正提案を再び取得できるようにする仕組みです。 nx +1

ただし、1つのコマンドですべての失敗を自動解決する機能ではありません。ローカルでのNx実行、Nx CloudとVCSの接続、CIのfix-ciステップ、エージェントのMCP・スキル構成を順に準備する必要があります。修正提案が作成される条件と、その提案が自動適用される条件も別々に確認する必要があります。 nx +1

エージェントが受け取るのは失敗後の文脈です

Nx MCPは、現在のブランチのCI状態を確認するci_information、個別タスクの出力を取得するci_task_output、Self-Healing提案を適用または却下するupdate_self_healing_fixを提供します。 つまり、人がCI画面とエディタの間で伝えていた情報を、エージェントが直接取得できるようになります。 nx

ここで名称を1つ訂正しておく必要があります。初期の公式記事ではci-monitorと書かれていますが、現在の公開リポジトリのスキルパスとメタデータで確認できる名前はmonitor-ciです。 古い名前のままインストールパスやスキル名を探すと、現在の構成と一致しない可能性があります。 nx +1

Self-Healing CIは、失敗ログとNxのプロジェクトグラフを使って原因を分析し、修正案を作成した後、元々失敗したタスクを再実行して修正できたかを検証します。 これは特定の失敗タスクに対する検証です。コード全体の業務上の正確性やPRをマージできることまで保証する結果ではありません。 nx

まず新しいチェックアウトでNxが実行できるか確認してください

この手順は、nx.jsonがあり、package.jsonにNxが含まれる既存ワークスペースを対象にしています。Nxのないリポジトリで初期化から実行すると依存関係と設定ファイルが変わるため、別の導入作業として扱う必要があります。 nx +1

1. リポジトリで指定されたNode.jsとパッケージマネージャーを準備します。
   package.json、ロックファイル、バージョン管理ファイル、既存のCI設定を確認してください。正確なNode.jsバージョンとインストールコマンドは、そのリポジトリの設定に従います。
2. ロックファイルに合うプロジェクト依存関係のインストールコマンドを実行します。
   インストールが終わったら、ワークスペースのルートでnpx nx --version、またはリポジトリが普段使うNxタスクを実行してください。ローカルのNxが正常に起動することが最初の成功基準です。
3. Nxがなければ接続作業を中断します。
   nx.jsonもなく、package.jsonにもNxがなければ、configure-ai-agentsから実行しないでください。npx nx@latest initはNxの依存関係と設定を追加するため、チームがレビューすべき別の変更です。 nx +1

Nx CloudとCIを先に接続します

エージェントを構成する前に、リモートCIが状態と修正提案を残せる経路を作る必要があります。Nx Cloudアカウント、サポートされるVCS連携、ワークスペースとCI設定を変更する権限が必要です。 nx

1. Self-Healing CIの設定ドキュメントを開き、ワークスペースを接続します。
   ワークスペースのルートでnpx nx@latest connectを実行し、ブラウザ認証を完了してください。 nx
2. Nx CloudでVCS接続を確認します。
   公式ドキュメントでサポート対象として案内されているGitHub、GitLab、Azure DevOps、またはBitbucketのリポジトリを接続し、Workspace SettingsでSelf-Healing CIを有効にします。 nx
3. 正しいCI jobの末尾にnpx nx fix-ciを追加します。
   Nxタスクを開始するmainまたはorchestrator jobに配置し、前のステップが失敗しても実行されるよう設定してください。GitHub Actionsではif: always()、他のCIではそれに相当する条件が必要です。BYOC構成の場合は、main jobだけでなく各agent jobにも同じ処理が必要です。 nx

エージェント構成はインストールと動作を分けて確認してください

Nx Cloudの接続が終わったら、コーディングクライアントにNx MCPとmonitor-ciスキルを構成します。公式の設定コマンドは既存のNxワークスペースを確認した後、クライアント別のルール、MCP、スキルファイルを作成します。 nx

1. 使用するクライアントを指定して構成を生成します。
   npx nx configure-ai-agentsを実行して対話的に選択するか、自動化環境ではnpx nx configure-ai-agents --agents <claude|codex|copilot|cursor|gemini|opencode> --no-interactive形式を使用してください。 nx
2. 生成された変更を確認します。
   ルールファイルとMCP・スキル設定が想定したクライアントの場所に追加されたか、diffを確認してください。リポジトリに直接コミットする前に、組織のルールや既存設定と競合しないかも確認します。
3. インストール状態を検査します。
   npx nx configure-ai-agents --check=allを実行してください。rules、MCP、skillsの検査が通れば、構成ファイルのインストールは成功です。 この検査は、リモートCIの照会まで成功したことを意味しません。 nx
4. VCS認証と権限を確認します。
   エージェントにPR作成まで任せる場合、コミット・プッシュ・PR作成に必要な認証と権限が必要です。これらの権限がなければ、人がPRを作成して監視だけを依頼してください。
5. デフォルトブランチではなくPRブランチから最初の入力を送ります。
   PR作成権限がある場合は、公式例のCommit the work, create a PR and monitor CI.を入力できます。 最初から自動適用を前提にせず、まずエージェントがNx Cloudのパイプライン状態を取得できるか確認してください。 nx

提案生成と自動適用は別々のゲートです

Self-Healingの提案がないからといって、すぐにAIの信頼性が低いと解釈してはいけません。提案が作成される段階と、作成された提案が自動適用される段階には、異なる条件があります。 nx

提案が生成されない場合は、PRでCIが実行されたか、Self-Healingが有効か、デフォルトまたは保護ブランチで実行したのではないか、失敗タスクがeligible taskまたは除外パターンに該当したかを確認してください。 反対に提案は表示されても自動適用されない場合は、auto-applyパターンと信頼度、再実行検証の結果を別途確認する必要があります。 nx

monitor-ciは、成功、修正する内容なし、環境問題、タイムアウトなどの結果を区別して処理するよう公開されています。 したがって、最初のPRのCIが最初から通過した場合、修正提案がなくても正常です。エージェントがその実行状態を照会できたなら、モニタリング接続という最初の目標は達成されています。 github

さらに深く掘り下げるなら

End to End Autonomous AI Agent Workflows with Nx は、PR後に人が再び呼び出される問題と、エージェントがCIを監視する全体フローを説明する出発点です。 nx.dev

AI-Powered Self-Healing CI では、VCS接続、fix-ciの配置、提案生成の範囲、自動適用の条件を分けて確認できます。 nx.dev

Integrate Nx with your Coding Assistant では、サポートされるクライアント、非対話型構成、--check=allの検査手順を確認できます。 nx.dev