責任を持ってエージェントを活用する
Vercelは、AIエージェントが生成するコードを盲目的にデプロイすることの危険性を指摘し、エンジニアがコードの所有権を維持しながらAIを活用する責任あるフレームワークを提案している。
キーポイント
AIエージェント生成コードの危険性
AIエージェントはテストを通過する完璧に見えるコードを生成するが、本番環境の現実（トラフィックパターン、障害モード、インフラ制約）を理解せず、重大な問題を引き起こす可能性がある。
「依存」と「活用」の根本的な違い
AIに「依存」することは、テスト通過を安全の証と盲信する危険な姿勢であり、「活用」とは、エンジニアが出力の完全な所有権を維持しながら迅速に反復する責任ある使用法である。
グリーンCIの安全性神話の崩壊
エージェントの世界では、CIパイプラインを通過することは、エージェントが変更を安全だと説得する能力の反映に過ぎず、本番環境でのインフラ劣化を防ぐ保証にはならない。
責任ある所有権の重要性
プルリクエストに名前を付けることは「このコードを読み、何をするか理解した」という意味であり、本番インシデントの責任を負えるかどうかが単純なリトマス試験となる。
閉じたループシステムの構築
エージェントが高い自律性で動作できるように、環境を標準化し、検証を容易にし、デプロイメントをデフォルトで安全にする閉じたループシステムを構築する必要がある。
実行可能なガードレール
運用知識をドキュメントではなく実行可能なツールとしてエンコードすることで、エージェントが自律的に従い、人間が暗記する必要がなくなる。
インフラ自体の厳格化
エンジニアがすべての変更に特別な厳密さを適用するのではなく、インフラ自体が厳格で、爆発半径を封じ込め、継続的に検証し、優雅に劣化し、ベストプラクティスを実行可能なデフォルトとしてエンコードする世界を目指す。
影響分析・編集コメントを表示
影響分析
この記事は、AIコーディングエージェントの急速な普及に伴う新たなリスクを明確に指摘し、業界全体に責任ある開発プラクティスの必要性を喚起している。単なる技術的警告を超え、エンジニアリング文化とプロセス変革の必要性を示唆しており、AI支援開発の成熟段階における重要な議論を提供している。
編集コメント
AI生成コードの盲信に警鐘を鳴らす実践的な警告であり、急速に普及するコーディングエージェント利用において、多くの開発チームが直面する根本的な課題を鋭く指摘している。
改善版翻訳文
以下はVercelで行われた内部講演に基づいています。ここで説明されている問題は私たちに特有のものではなく、このフレームワークはエージェントを用いて開発を行うあらゆるチームにとって有用であるため、公開します。
コーディングエージェントは前例のない速度でコードを生成します。規律あるエンジニアの手にかかれば、生産性の倍増装置となります。しかし、厳格な判断が伴わなければ、誤った前提を直接本番環境にリリースする非常に効率的な手段になってしまいます。
チームがエージェント生成コードを盲目的にデプロイすると、その影響は即座に深刻なものとなる可能性があります。完璧に見えるプルリクエスト（PR）が、テストは通過するものの本番環境では全行をスキャンするクエリをリリースするかもしれません。正しく見えるリトライロジックが、下流サービスでスラッシングハードを引き起こす可能性があります。そしてTTLのないキャッシュは、Redisがダウンするまで静かに肥大化し続けるかもしれません。
CI（継続的インテグレーション）がグリーンであることは、もはや安全性の証明ではありません。エージェントが主流となる世界では、CIを通過することは、たとえその変更が大規模に適用されれば即座にインフラを劣化させるものであっても、エージェントがパイプラインを説得して変更を安全だと信じ込ませる能力の反映でしかありません。
誤った自信
エージェント生成コードは危険なほど説得力があります。洗練されたPR説明文が付き、静的解析を通過し、リポジトリの規約に従い、妥当なテストカバレッジを含んでいます。表面上は、経験豊富なエンジニアが書いたように見えます。
しかし、エージェントはあなたの本番環境を理解していません。あなたのトラフィックパターン、障害モード、共有インフラストラクチャの暗黙的な制約を知りません。Redisインスタンスが容量限界に近いこと、データベースが特定のリージョンにハードコードされていること、機能フラグのロールアウトが下流システムの負荷特性を根本的に変えることを知らないのです。
「このPRは正しそうだ」と「このPRはリリースして安全だ」の間のギャップは、以前から存在していました。エージェントは、本番環境の現実に対して完全に盲目でありながら、これまで以上に完璧に見えるコードを生成することで、そのギャップを広げます。
活用と依存
AIに依存することと、AIを活用することには根本的な違いがあります。
依存とは、エージェントが書いたコードでテストが通れば、リリース準備が整っていると想定することを意味します。作成者は変更に対するメンタルモデルを構築しません。結果として、作成者もレビュアーもコードが実際に何をするのか明確に把握していないため、隠れた前提に満ちた巨大なPRが生まれ、レビューが不可能になります。
活用とは、出力に対する完全な責任を維持しながら、エージェントを用いて迅速に反復することを意味します。あなたはコードが負荷下でどのように振る舞うかを正確に知っています。関連するリスクを理解しています。それらのリスクを引き受けることに不安はありません。
プルリクエストに自分の名前を付けることは、「私はこれを読み、その内容を理解している」という意味です。もし自分のPRを読み直して、それが本番環境にどのような影響を与えるかを説明しなければならないなら、エンジニアリングプロセスは失敗しています。
リトマス試験はシンプルです：このプルリクエストに関連する本番インシデントの責任を負うことに、あなたは安心できますか？
本番環境を守る
答えはエージェントの使用を止めることではありません。生産性の向上は否定できず、モデルはさらに進化するだけです。AI支援のコードレビューと分析は、人間が見逃しがちなバグを捕捉し、リスクを表面化させる非常に強力なツールです。
しかし、人間によるものであれAIによるものであれ、レビューだけに依存することは、エージェント生成コードの膨大な量に対して勝ち目のない戦いです。私たちは、実装が豊富にある転換点に達しました。希少な資源はもはやコードを書くことではなく、何をリリースして安全かの判断です。すべてのインフラストラクチャは、この新しい現実に対応しなければなりません。
これは開発ライフサイクルを官僚的な手続きで縛ることではありません。エージェントが高い自律性を持って行動できる閉ループシステムを構築することです。その環境が標準化され、検証が容易で、デプロイがデフォルトで安全だからです。
組織原則はシンプルです：正しいことをすることを容易にすることです。
- 自動運転デプロイ: あらゆる変更は、ゲート付きパイプラインを通じて段階的にロールアウトされます。カナリアデプロイで問題が発生した場合、ロールアウトは自動的に停止し、ロールバックされます。システムはエンジニアがダッシュボードを監視することに依存しません。問題を捕捉し、トラフィックの一部に封じ込め、元に戻します。何か問題が起きても、それは全体ではなく隔離された範囲で起こります。
- 継続的検証: インフラはデプロイ時だけでなく、継続的に自己テストします。負荷テスト、カオス実験、障害復旧訓練が継続的に実行されます。Vercelでは、昨年夏に本番環境でリハーサルしたデータベースのフェイルオーバーがあったからこそ、今年発生した実際のAzure障害がお客様にとって何事もない一日で済んだのです。圧力に耐えるシステムとは、意図的に負荷をかけられてきたシステムです。
- 実行可能ガードレール: Vercelでは、運用ノウハウをドキュメントではなく、実行可能なツールとしてコード化しています。安全なロールアウトの「スキル」とは、機能フラグの仕組みを説明するNotionページではありません。フラグを設定し、ロールバック条件付きのロールアウト計画を生成し、期待される動作を検証する方法を指定するツールです。ガードレールが実行可能であれば、エージェントは自律的にそれに従い、人間が暗記する必要はなくなります。
最終目標は、エンジニアがあらゆる変更に並外れた厳密さを適用する世界ではありません。インフラ自体が厳密である世界です。システムが爆発半径を封じ込め、継続的に検証し、優雅に劣化し、ベストプラクティスを実行可能なデフォルトとしてコード化しているため、高速なリリースがデフォルトで安全である世界です。
私たちが投資していること
私たちは単に理論を語っているだけではありません。コアプラットフォームチームは、以下のようなガードレールを共有インフラに積極的に組み込んでいます：
- 共有インフラ周りのより強力なガードレール。デプロイパイプラインの各段階でのランタイム検証を含む。
- PR作成時点でのより厳格な静的チェック。特に機能フラグ周り。
- ステージング環境での、本番環境を模倣したエンドツーエンドテスト。
- 本番環境でシステム不変条件を継続的に検証する読み取り専用エージェント。生成エージェントが行った前提を監査するための専門エージェントの使用。
- プラットフォーム全体でリスクが高まっていることを可視化するための、欠陥コミット対欠陥エスケープ比率などのメトリクス。
エージェントを活用し、リスクを所有せよ
私たちの基準は：エージェントに依存せず、活用することです。
低品質なコードは、かつては低品質なコードのように見えました。今はそうではありません。AIツールはより強力になるだけです。変更の規模はより大きくなり、コードはより説得力を持ち、出力を盲目的に信頼する誘惑は増大します。成功するエンジニアは、最も多くのコードを生成する人ではありません。自分たちがリリースするものに対して、厳しい判断を維持できる人たちです。
次のPRを開く前に、自分自身に問いかけてください：
- これは何をしますか？一度ロールアウトされたら、どのように振る舞いますか？
- これは本番環境や顧客に、どのような悪影響を与える可能性がありますか？
- このコードに関連するインシデントの責任を負うことに、安心できますか？
答えが「イエス」なら、あなたはAIを活用しています。リリースしてください。
答えが「ノー」なら、あなたにはやるべきことがもっとあります。
原文を表示
The following is based on an internal talk given at Vercel. We're sharing it publicly because the problem it describes isn't unique to us, and the framework is useful for any team shipping with agents.
Coding agents generate code at unprecedented speeds. In the hands of disciplined engineers, they are a productivity multiplier. But without rigorous judgment, they are a highly efficient way to ship bad assumptions directly to production.
When teams deploy agent-generated code blindly, the fallout can be immediate and severe. A flawless-looking pull request can ship a query that passes tests, but scans every row in production. Retry logic that seems correct can cause a thundering herd on a downstream service. And a cache with no TTL can quietly grow until Redis dies.
Green CI is no longer proof of safety. In an agentic world, passing CI is merely a reflection of the agent's ability to persuade your pipeline that a change is safe, even if it will immediately degrade your infrastructure at scale.
False confidence
Agent-generated code is dangerously convincing. It comes with a polished PR description, passes static analysis, follows repository conventions, and includes reasonable test coverage. On the surface, it looks like it was written by an experienced engineer.
But an agent doesn't understand your production environment. It doesn't know your traffic patterns, your failure modes, or the implicit constraints of your shared infrastructure. It doesn't know that a Redis instance is near capacity, that a database is hardcoded to a specific region, or that a feature flag rollout will fundamentally change the load profile of a downstream system.
The gap between "this PR looks correct" and "this PR is safe to ship" has always existed. Agents widen that gap by producing code that looks more flawless than ever, while remaining entirely blind to production realities.
Leveraging vs. relying
There is a fundamental difference between relying on AI and leveraging it.
Relying means assuming that if the agent wrote it and the tests pass, it's ready to ship. The author never builds a mental model of the change. The result is massive PRs full of hidden assumptions that are impossible to review because neither the author nor the reviewer has a clear picture of what the code actually does.
Leveraging means using agents to iterate quickly while maintaining complete ownership of the output. You know exactly how the code behaves under load. You understand the associated risks. You're comfortable owning them.
Putting your name on a pull request means "I have read this and I understand what it does." If you have to re-read your own PR to explain how it might impact production, the engineering process has failed.
The litmus test is simple: would you be comfortable owning a production incident tied to this pull request?
Guarding production
The answer isn't to stop using agents. The productivity gains are undeniable and models will only get better. AI-assisted code review and analysis are incredibly powerful tools that catch bugs and surface risks humans miss.
But relying solely on review, whether human or synthetic, is a losing battle against the sheer volume of agent-generated code. We've hit an inflection point where implementation is abundant. The scarce resource is no longer writing code, it's the judgment of what is safe to ship. All infrastructure must match that new reality.
This isn't about wrapping the development lifecycle in red tape. It's about building a closed-loop system where agents can act with high autonomy because their environment is standardized, verification is easy, and deployment is safe by default.
The organizing principle is simple: make the right thing easy to do.
Self-driving deployments. Every change rolls out incrementally through gated pipelines. If a canary deployment degrades, the rollout stops and rolls back automatically. The system doesn't rely on an engineer babysitting a dashboard. It catches the problem, contains it to a fraction of traffic, and reverses it. When something goes wrong, it goes wrong in isolation, not globally.
Continuous validation. The infrastructure tests itself continuously, not just at deploy. Load tests, chaos experiments, and disaster recovery exercises run on an ongoing basis. At Vercel, the database failover we rehearsed in production last summer is the reason a real Azure outage this year was a non-event for our customers. The systems that hold up under pressure are the ones that have been deliberately stressed.
Executable guardrails. At Vercel, we are encoding operational knowledge as runnable tools instead of documentation. A safe-rollout skill isn't a Notion page explaining how feature flags work. It's a tool that wires the flag, generates a rollout plan with rollback conditions, and specifies how to verify expected behavior. When guardrails are executable, agents follow them autonomously and humans don't have to memorize them.
The endgame isn't a world where engineers apply extraordinary rigor to every change. It's a world where the infrastructure itself is rigorous. Where shipping fast is safe by default because the system contains the blast radius, validates continuously, degrades gracefully, and encodes best practices as executable defaults.
What we're investing in
We aren't just theorizing. Our core platform team is actively building these guardrails into shared infrastructure:
Stronger guardrails around shared infra, with runtime validation at every stage of the deployment pipeline
Stricter static checks at PR time, especially around feature flags
Production-mirroring end-to-end testing in staging
Read-only agents that continuously verify system invariants in production, using specialized agents to audit the assumptions made by generative agents
Metrics like defect-commit vs. defect-escape ratios to surface when risk is increasing across the platform
Leverage agents, own the risk
Our bar: leverage agents, don't rely on them.
Low-quality code used to look like low-quality code. That's not the case anymore. AI tools are only going to get more powerful. The diffs will get larger, the code will get more convincing, and the temptation to blindly trust the output will grow. The engineers who thrive won't be the ones who generate the most code. They'll be the ones who maintain ruthless judgment over what they ship.
Before you open your next PR, ask yourself:
What does this do? How does it behave once rolled out?
How can this adversely impact production or customers?
Am I comfortable owning an incident tied to this code?
If the answer is yes, you're leveraging AI. Ship it.
If the answer is no, you have more work to do.
Read more
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み