30日間、AIに依存関係アップデートを任せてみた

設定

2026年2月1日、私はパッケージ管理を自律型AIエージェントに引き継ぎました。私は支払いルーティングとユーザー分析を扱うミドルサイズのTypeScriptリポジトリを4つ管理しています。これらを常に最新の状態に保つのに毎週約6時間かかっていました。LLM駆動のアップデータが本当にその時間を減らしつつ、プロダクションを壊さないのかを確かめたかったのです。

私はGitHub Actionsとローカルのエージェント実行基盤の上に、軽量なラッパーを作りました。このシステムはpackage.jsonとロックファイルを読み取り、npmレジストリを確認し、変更履歴（changelog）の要約を添えたプルリクエストを下書きします。また、大きなメジャーバージョンの更新を手動承認なしでは許さないという厳格なルールを追加しました。エージェントは、読み取り専用のリポジトリアクセスを持つ隔離コンテナ内で動作させています。

以下は、挙動を制約するために私が使用した中核となるプロンプト設定です：

agent_config:
  scope: [dependencies, devDependencies]
  allowed_actions:
    - read_registry
    - diff_lockfiles
    - generate_pr_body
  blocked_actions:
    - bump_major_versions
    - remove_pinned_versions
    - modify_ci_workflows
  validation_steps:
    - run_type_check
    - execute_unit_suite
    - check_bundle_size_delta
  max_concurrent_prs: 3
  fallback_policy: request_human_review_on_type_error

この設定により、エージェントはプルリクエストを開く前から型定義を検証することが強制されます。あわせて、同時に走らせるブランチ数を上限（3）にして、ステージング環境を圧倒しないようにしました。

1週目

最初の1週間は意外なほど順調でした。エージェントは、すべてのリポジトリにまたがって合計14件のプルリクエストを作成しました。そのうち9件は初回で問題なくマージされました。5件はTypeScriptの型定義に軽微な調整が必要でした。私は変更内容のレビューと承認に合計約45分を使いました。

自動生成されたサマリーは、実際に役に立ちました。以前のように生のgitログを貼り付けるのではなく、エージェントが破壊的なAPI変更を強調し、具体的な移行ガイドへのリンクも付けてくれたのです。セキュリティパッチと機能更新を別枠でまとめる傾向があることに気づきました。この整理はスクロールの手間を減らしてくれました。

Axiosのインシデント

2週目で重大な見落としが露呈しました。エージェントはネットワーククライアントに対するパッチを押し込みましたが、それがタイムアウト処理ロジックを静かに変更していました。支払いゲートウェイは、2秒を超えて処理がかかるリクエストでタイムアウトし始めました。テストスイートは通りました。モックサーバーが即時に応答していたためです。

私は2月12日のステージングデプロイ中にこの問題を見つけました。変更をロールバックし、ネットワークスタックのデバッグに3時間を費やしました。AIは、実行環境の制約を理解していませんでした。changelogだけを読み取り、パッチは安全だと決めつけていたのです。メンテナーがマイナーリリースで微妙なタイムアウトの変化を明記することは稀です。

失敗の原因は、実行時の検証よりもテキスト解析を信頼したことでした。私は、エージェントには実際のネットワーク遅延をシミュレートする手段がないことに気づきました。エージェントは成功したHTTPレスポンスをすべて同一のものとして扱っていました。私たちのプロダクションのトラフィックは、まったく別の挙動をします。

3週目の修正

私はパイプラインにより厳格な検証ルールを追加しました。プロダクションの遅延を模倣するローカルのDockerインスタンスに対して統合テストを実行することを、エージェントに強制しました。また、すべての生成ブランチについて、セマンティックなコミットメッセージとテストカバレッジの差分を明示することを求めました。成功率は劇的に改善しました。

その週のプルリクエスト数は10件まで減りました。マージ率は90％に達しました。さらに、何かをマージする前にフルのエンドツーエンド（e2e）スイートを実行する、必須のステージングデプロイ手順も導入しました。このステップで、ユニットテストをすり抜けた破壊的変更を2件検出できました。加えて、各パイプラインに約8分の時間が追加されました。

余計な待ち時間は、必要な負担だと感じました。午前0時のロールバックを直すより、グリーンになったパイプラインを待つ方がよいからです。エージェントは不満もなく、遅いペースに適応しました。前の更新がステージングをクリアした後に、次の更新をキューに積むだけです。

最終的な数字

2月の終わりまでに、はっきりした全体像を描くための十分なデータが集まりました。私はすべての更新、ビルド時間、インシデントを追跡しました。指標は、どこで自動化が役に立ち、どこで摩擦を生んだのかを正確に示しています。

エージェントはセキュリティパッチの対応が非常に優れていました。CVEsを公開から数時間以内に優先して処理してくれます。さらに、2024年以来ずっと放置されていた未使用の開発用依存関係も整理してくれました。私はその月に合計およそ14時間節約できました。その時間は、キャッシュ層のリファクタリングに直接投入しました。

一方で課題だったのは、マイナーアップデートで起こる実行時の挙動変更です。AIにはシステムアーキテクチャに対する直感がありません。すべてのパッケージ更新を、単独のテキスト置換のように扱います。その前提は、依存関係が内部状態を共有していたり、未ドキュメントの環境変数に依存している場合に崩れます。

実際にうまくいったこと

2026年のAIエージェントはテキストを読むのが得意です。しかしシステムの状態を理解するのは得意ではありません。安全策（セーフティネット）がなければ、プロダクションの判断を任せることはできません。私は、何かをマージする前にフルのe2eスイートを実行する必須のステージングデプロイ手順を追加しました。このステップで、ユニットテストをすり抜けた破壊的変更を2件検出できました。

本当の価値は、自動生成される変更履歴（changelog）の統合（シンセシス）にありました。以前はGitHubのリリースを突き合わせるのに何時間もかけていました。今は、エージェントが破壊的な変更を3つの箇条書きで要約します。要約に非推奨（deprecated）になったAPIが言及されているときだけ、リリースノート全文を読みます。このフィルタで、毎月少なくとも2時間は節約できます。

また、エージェントは時間とともに良くなっていくことにも気づきました。4週目には、コンパイラを実行する前に型の不一致を予測し始めました。初期の週に失敗したプルリクエストから学習したのです。この改善ループが機能したのは、私はすべての却下理由を記録するように強制したからです。

私の結論

30日間の実験で、私の取り組み方は変わった

関連記事（Further Reading）: 私はAIオートメーションとオープンソースのツールを試しています。より多くのガイドはPi Stackで見つかります。