動画記事 · AI Engineer
Netflix ラジャット・シャー氏:AI エージェントで開発加速、コスト削減へ
動画の文字起こしと公開情報をもとにAIで要約・構成しています。 正確な発言は元動画と時間位置で確認してください。
まず要点
Netflix のエンジニアが、AI エージェントを活用してプロファイリングデータを分析し、コードのボトルネックを特定・修正するワークフローを実践した事例と、段階的な自動化アプローチについて解説している。
動画をもとにした日本語記事
Netflix がAIエージェントに「プロファイリングデータ」を食らわせた理由:開発速度とコストのジレンマを解く新戦略
Netflix のラジャット・シャー氏は、生成 AI によるコード記述が飛躍的に加速した現代において、「パフォーマンス最適化」が追いつかず、結果としてインフラコスト増や非効率を招く深刻な課題があると指摘します。この問題を解決するために同社が導入したのは、LLM エージェントにプロファイリングデータ(呼び出しスタックや CPU 使用率など)を読み込ませる手法です。
人間が数十分かけて手作業で行っていたボトルネック特定プロセスを自動化した結果、シャー氏は「学習済みモデルの汎用的な最適化パターン認識能力」と「組織固有のパターンを蓄積する中央集権的な記憶」を組み合わせたアプローチの有効性を証明しました。完全自律型エージェントへの移行を急ぐのではなく、まずは分析ツールとして導入し、段階的に自動化レベルを高めるという実践的なロードマップは、エンタープライズ企業が AI を安全かつ効果的に活用するための重要な指針となります。
開発速度の加速が招く「パフォーマンスの罠」
生成 AI の登場により、コード記述速度はかつてないほど向上しました。しかし、このスピードアップには代償があります。AI エージェントは「速くコードを書くこと」に特化しており、必ずしも「高速なコード」を生み出すわけではありません。
特に重要なのは、AI が組織固有のプラットフォームやフレームワーク、内部コードベースのパターンを完全に理解していない点です。そのため、外部でよく見られるパターンや、エンジニアが想定していなかった新しいパターンを安易に採用してしまい、結果としてパフォーマンスの低いコードが量産されるリスクがあります。
「計算コストも同様に増加しています。AI エージェントは速くコードを提出するようにチューニングされているからです。」
シャー氏は、この「新しい広範なコーディング時代」において、パフォーマンスエンジニアリングのスケーラビリティに問題が生じていると分析します。従来の人間によるパフォーマンスエンジニアリングは、以下の手順を踏むため、非常に時間がかかる手作業でした。
- 本番環境のインスタンスでプロファイラーを実行する
- 出力された生データ(JSON 形式の呼び出しスタックや CPU 使用率など)をダウンロードし、可視化ツールで開く
- 膨大なデータの中から「ホットパス(ボトルネック)」を探す「宝探し」を行う
- コードベースを検索して根本原因を特定し、修正コードを作成・レビューする
このプロセスは学習コストが高く、多くの時間を要するため、通常は「深夜に CPU がパンクした」といった緊急事態が発生した場合に限って行われるのが実情でした。組織全体で多数のコードベースやパスを対象にするのは現実的ではありません。
プロファイリングデータを直接読み込ませる実験
Netflix は、「LLM エージェントがプロファイリングデータを読み込み、人間が 20 分かけて行うホットパス特定を短縮できるか」という問いに答えを出すため、実サービスでの実験を行いました。この実験の前提には、2 つの重要な仮説がありました。
1. プロファイラーは言語を問わない共通言語で話す
Java、Python、Go など、どのランタイムや言語を使用しているかに関わらず、プロファイラーが出力するデータ(呼び出しスタック、自己 CPU 時間、包括 CPU 時間など)の構造は非常に似ており、LLM エージェントにとって扱いやすい形式であるという点です。
2. AI は一般的な最適化パターンを既に知っている
学習済みモデルは、公開されたコードソースを通じて「O(N^2) のループ」「ループ不変量の移動」「オブジェクトの過剰な割り当て」「競合のバッチ処理」など、一般的なパフォーマンス悪化のパターン(コードスモーク)を認識する能力を持っています。
シャー氏は実験で、プロファイリングデータを LLM エージェントに与えたところ、エージェントが呼び出しスタックから「これは二次アルゴリズムだ」と即座に特定できることを確認しました。これは、ソースコードそのものを解析するのではなく、実行時のデータからパターンを抽出した結果です。
さらに、エージェントは以下のステップを自動で実行し、修正提案まで行うことができました。
- プロファイルされたメソッドが定義されている Git リポジトリを検索
- 本番環境で稼働中の特定のコミットをチェックアウト
- 該当コードパスの完全な呼び出し経路を追跡
- コードレビューを生成
この一連のプロセスは、強力なコードエージェントであれば5 分以内に完了しました。実際の実績では、あるケースで CPU 時間の 8.8% を消費していたボトルネックが特定され、最適化により CPU とレイテンシの両面で明確な削減効果を確認できました。
「長期記憶」による組織全体の知識共有とスケーリング
単一のサービスでの改善にとどまらず、Netflix のアプローチは「組織全体での知識共有」に重点を置いています。シャー氏が提案するのは、中央集権的なカタログ(Git リポジトリ)を活用した「長期記憶」の実装です。
組織固有のパターンやアンチパターンを Markdown ファイルとして蓄積し、ステートレスな LLM エージェントがこれを参照できるようにします。これにより、あるサービスで見つかった問題が、他のサービスでも同じパターンのコードで発生している可能性を即座に検出できます。
実験では、ある「ホットパス」で生成されるカウンターオブジェクトの不適切な使用というパターンを特定した際、エージェントは複数のリポジトリを検索し、7 つの異なるサービスで同様の問題が見つかりました。これらすべてを修正すれば、CPU サイクル全体で 0.5% から 4.6% の削減が可能になると試算されました。
「学習済みモデルの汎用的な最適化パターン認識能力と、組織固有のパターン・アンチパターンを蓄積する中央集権的なカタログを組み合わせたアプローチが、全社的な知識の共有と再利用を実現します。」
この手法は、属人化していたパフォーマンス最適化の知見を組織全体で標準化し、AI エージェントを通じて自動的に適用可能にする画期的なモデルです。
段階的自動化とセキュリティガバナンスの重要性
シャー氏は、いきなり完全自律型(レベル 3)のエージェントを目指すのではなく、段階的なアプローチを強く推奨しています。
- レベル 1: LLM を分析補助ツールとして導入。人間がプロファイリングデータを提示し、エージェントにパターン認識や原因特定を依頼する。
- レベル 2: ツール連携を強化したワークフローへ。Git やコード検索ツールと連携させ、より自律的な調査を行う。
- レベル 3: 完全自律型への移行。最終的に修正提案から適用までを自動化するが、その前段階として堅牢な基盤が必要となる。
また、AI エージェントが自律的にコードを修正・実行する際には、セキュリティリスクも無視できません。プロンプトインジェクション対策や、安全なサンドボックス環境の整備など、堅牢なガバナンス基盤の構築が不可欠であると強調しています。
まとめ
Netflix のラジャット・シャー氏が示したのは、生成 AI を単なる「コード作成ツール」ではなく、「パフォーマンスエンジニアリングの自動化プラットフォーム」として再定義する道筋です。プロファイリングデータと組織固有の知識を組み合わせることで、開発速度の加速に伴うコスト増というジレンマを解決し、安全かつ効率的なインフラ運用を実現する方法が提示されました。これは、大規模組織が AI を導入する際の標準的なプラクティスとして、今後広く採用される可能性が高い重要な知見です。
Original Source
元動画で発言を確認

プレイヤーは必要になるまで読み込みません。YouTubeのCookieと通信も再生を選ぶまで開始しません。
時間位置から根拠を確認
章や引用を選ぶと、元動画をその位置から再生します。