AWS の技術ブログ

全3216件

2026/04/09

コパイロットからコワーカーへ – AAAI : エージェント研究と実用化のギャップ

本記事は「 From copilots to coworkers at AAAI: the gap between agentic research and production 」を翻訳したものです。 2026 年 1 月 27 日 AAAI 2026 パネルディスカッション「From Copilots to Co-Workers: What Changes When AI Writes, Reads, and Reasons About Code?」に基づく — シンガポール AAAI 2026 の協調型 AI エージェントに関するワークショップで、Microsoft、Mistral、シンガポール国立大学（NUS）、LinkedIn、Amazon Web Services（AWS）の研究者と実務者がパネルに集まり、コーディングエージェントを本番環境に投入した際に実際に何が起こるかについて意見を交わしました。議論の焦点は「うまくいくかどうか」ではなく（その議論はすでに決着済みです）、「何が壊れるのか、何が予想外なのか、そしてその過程で何を再構築しなければならないのか」でした。パネリスト： Shengyu Fu — Microsoft CoreAI、Partner Applied Science Manager。GitHub Copilot 全般にわたるイノベーションを推進する AI for Code 応用研究チームを率い、補完機能からコーディングエージェントまで幅広くイノベーションを推進。 Abhik Roychoudhury — シンガポール国立大学コンピュータサイエンス学部 Provost’s Chair Professor。ACM フェロー、ACM TOSEM 編集長。信頼性とセキュリティを重視したソフトウェアエンジニアリンググループを率い、セマンティックプログラム修復、仕様推論、ファズテスト、AutoCodeRover などの研究に貢献。 Baptiste Rozière — Mistral AI のコード生成チームを率いる。以前は Meta AI に在籍し、Llama に貢献、Code Llama を主導。 Alborz Geramifard — LinkedIn、Distinguished Scientist Omer Tripp — AWS、Principal Applied Scientist 研究と本番環境のギャップ現在の研究は主に能力の最適化に注力していますが、本番環境では信頼性、コスト、レイテンシー、信頼、そして組織への適合性を同時に最適化する必要があります。ソフトウェア開発向け AI には、おなじみのパターンがあります。論文がベンチマークで印象的な結果を示す。チームがそれを製品化しようとする。そして本当の仕事が始まります。それはモデルに関する作業ではなく、モデルの周辺にあるすべてのものに関する作業です。どのモデルをいつ呼び出すかを決定するオーケストレーション層、大規模な推論を経済的に維持するコスト設計、開発者が待つか離脱するかを左右するレイテンシー予算、エージェントが実際に役立っているのかそれともそれらしいノイズを生成しているだけなのかを判断する評価フレームワーク、そして誰かがエージェントに実際の仕事を委任するかどうかを決定するトラストサーフェス（説明、監査証跡、中断ポイント）です。パネリストたちは繰り返し、さまざまな角度から、コーディングエージェントのデプロイにおける課題は、ラボで構築する際の課題とは根本的に異なることを指摘しました。研究は能力を最適化します。本番環境は信頼性、コスト、レイテンシー、信頼、組織への適合性を同時に最適化します。そしてこのギャップは単一の問題ではありません。それぞれが独自の苦労から得た教訓を持つ、いくつかの異なるレベルで現れます。ギャップが現れる場所ゼロからの構築：最新の研究を取り入れながら迅速にリリースする最初の課題はアーキテクチャに関するものです。モデルの能力が限られていた頃、チャットは自然なインタラクションモデルでした。Shengyu Fu（Microsoft）は、VS Code が Copilot にチャット機能を搭載した際、システムが完成したと思い込みがちだったと述べました。プロンプティングがすべてだと感じられたのです。しかし、その幻想はより高性能なモデルの登場とともに崩れます。推論能力とツール使用が向上するにつれ、エージェントはマルチステップのアクションを実行し、自律的にツールを呼び出し、自己検証を行うようになりました。課題はプロンプトエンジニアリングからオーケストレーション、システム設計、評価へと移行しました。これを早期に認識しなかったチームは、後になって手戻りという代償を払うことになりました。この現代的なエージェントパラダイムでは、アーキテクチャの専門化が有効です。例えば、GitHub Copilot はコード検索などのタスクに専用のサブエージェントを使用し、高価な推論モデルは本当に必要な場面に限定しています。しかし、この専門化には独自の問題が伴います。エージェント間のハンドオフのたびにレイテンシーが増加し、コンテキストが複数のステージを通過するにつれて情報が劣化します。数千万行規模のコードベースでは、コスト削減にはより安価なモデルへの単純な置き換えではなく、システムレベルの設計が必要です。ユーザーがレイテンシーをどう認識するかも変化しました。2025 年にはスピードが品質の代理指標でした。2026 年までに、ユーザーは複雑なプロンプトに対するより高い自律性とより包括的なソリューションと引き換えに、より長い待ち時間を受け入れるようになりました。基準は「素早く応答する」から「自分がやらなくて済むようにもっと多くを処理する」へと移りました。Abhik Roychoudhury（NUS）は、初期のエージェントチーム（自身のチームを含む）がプログラム解析技術を用いて推論コストの最適化に注力していたと述べました。多くの人を驚かせたのは、組織の準備態勢がコストを上回る制約要因として急速に浮上したことです。3 年前の International Conference of Software Engineering（ICSE）では、多くの企業が LLM を自社のコードに触れさせることは絶対にないと断言していました。しかし、開発者が生産性の向上を実感すると、その姿勢は一変しました。コストよりも意欲が重要であり、適切な足場があれば、より高い品質をより低いコストで実現できると Abhik は付け加えました。主なポイント：研究は能力を提供しますが、本番環境ではコスト、レイテンシー、品質のバランスを取るアーキテクチャが求められます。そして、そのアーキテクチャこそが実際のエンジニアリングの大部分を占める場所です。学習と評価：エージェントをより自律的にするギャップの 2 つ目のレベルは、エージェントが実際に優れているかどうかを知り、時間とともに改善していくことに関するものです。強化学習は自然な選択だが、アルゴリズムの壁よりもインフラの壁に先にぶつかる。強化学習は、環境内でアクションを実行するコーディングエージェントの訓練に最適なアプローチであるはずです。しかし実際には、最も困難な問題はエンジニアリングの問題です。Alborz は、エージェントの訓練を完全に強化学習駆動の問題として扱った LinkedIn の経験を述べました。GPU/CPU の利用率がシステム上の課題となりました。ビルドと実行は CPU 負荷が高く、GPU 中心の訓練クラスターとの不均衡が生じます。モデルの並列訓練中にトラジェクトリを収集することで、調整の複雑さが増しました。単純な報酬シグナルは報酬ハッキングを招きました。エージェントは成功したように見せるためにテストを削除することを学習したのです。さらに、スケーリングを実現するために、LinkedIn は各ポッドをクリーンな状態の仮想マシンとして使用しました。各ステップで完全な git チェックアウトを行う初期設計ではシステムが飽和しました。キャッシュと厳格なアーティファクト管理が不可欠になりました。大規模運用では、約 800 の問題をそれぞれ複数回実行し、オンラインでトラジェクトリを生成しました。Shengyu も Microsoft での同様の経験を述べました。エージェント型強化学習は、長いトラジェクトリと繰り返しのモデル呼び出しにより、補完のための強化学習よりもはるかに困難です。Baptiste も、Mistral で同じパターンが見られたことを確認しました。強化学習環境は事前学習クラスターよりもはるかに多くの CPU を必要とします。 3 つの組織すべてのコンセンサスは次のとおりです。スケーラブルな強化学習環境は、エージェント型 AI に欠けているインフラ層です。現時点では、これはアルゴリズムのフロンティアではなく、エンジニアリング上の制約です。評価ベンチマークは飽和し、現実から乖離している。 SWE-Bench は 2025 年に評価の主流でしたが、2026 年までに開発者が実際にエージェントを使用する方法と構造的に乖離するようになりました。Alborz は、ベンチマークは通常単一のリポジトリで動作するが、実際の作業は複数のリポジトリにまたがると指摘しました。Abhik は、ほとんどのベンチマークがコードの記述を測定する一方で、コードの読解、意図の理解、影響の分析も同様に重要でありながらほとんど測定されていないと強調しました。Baptiste は、正確性だけではエージェントを差別化できず、指示への追従性と汎化能力が少なくとも同程度に重要だと付け加えました。Omer は、実験室の設定ではなく本番環境の条件に最適化すべきだと主張しました。各企業はプロプライエタリなコードで内部ベンチマークを構築していますが、エージェント評価の共有基準はまだ存在せず、GitHub Copilot のようなデプロイ済みシステムでは、エージェント型ワークロードにはまだクリーンな定量的シグナルがありません。主なポイント：評価と訓練インフラが 2 つの欠けている層です。ベンチマークは単一リポジトリの正確性を超えて、コード読解、マルチリポジトリワークフロー、指示への追従性を捉える必要があります。スケーラブルな強化学習環境は欠けている訓練層であり、試みたすべてのチームがアルゴリズムの壁ではなく同じエンジニアリングの壁にぶつかっています。エージェントは単独で動作しない：人間とエージェント間インタラクションの役割 3 つ目のレベルは、エージェントの周辺で何が起こるか、つまり人間がエージェントとどのようにインタラクションし、信頼がどのように構築され、人間の役割がどう変化するかについてです。レイテンシーと監査可能性が製品を定義する。 Omer は 2 種類のレイテンシーを明確に区別しました。オートコンプリートのレイテンシー（入力中に AI が次の行を提案する際の遅延）は、既存のフローに収まるため、合理的な範囲内であれば許容されます。委任のレイテンシーは根本的に異なります。エージェントにタスク全体を渡し、複数のステップにわたって自律的に作業させる場合、もはやエージェントと並行して入力しているのではなく、ただ待っているだけです。その待ち時間は直ちに監査可能性と結びつきます。ユーザーはエージェントが何をしているのか、行き詰まっていないか、中断できるかを知りたがります。これらの問いが、システムが信頼できると感じられるか不透明に感じられるかを決定します。品質は正確性だけではない。 Abhik は、あまり注目されていない 2 つの次元で品質を再定義しました。第一に、シグナル対ノイズ比：エージェントは開発者の注意を妨げていないか、それともフィルタリングに労力を要するノイズを生成しているか？10 個の提案のうち 1 つしか有用でないエージェントは、各提案が技術的に正しくても、隠れたコストが発生しています。第二に、説明可能性：エージェントは予想外の判断を正当化できるか？推論が読み取れるものであれば、驚くべき振る舞いも許容されます。この枠組みでは、品質は信頼は切り離せません。検証は実用的な中間地点に落ち着く。形式検証はほとんどのシステムにとってまだ手の届かないものです。パネルは実用的な代替案に収束しました。仕様駆動開発（生成されたコードから仕様を抽出し、人間が実装を再確認する必要をなくす）、プロパティベーステスト（モデルはこれらの生成に適しており、実行可能な説明として機能する）、そして AI 支援コードレビュー（AI で AI をガードレールし、人間がビジネスロジックに集中できるようにする）です。人間の役割は変化しているが、消滅してはいない。聴衆からの質問が、よくある不安を捉えていました。エージェントがコードの大部分を書くようになったとき、ジュニア開発者はどのように成長すべきか？新たに求められるスキルセットは以下を中心としています。コードの読解とレビュー（書くことよりも重要）、委任（何を自動化し、何に人間の判断が必要かを見極める）、テストと検証（開発者の役割の中心に移行）、そして曖昧さの解消（仕様が不完全な場合に人間が接着剤の役割を果たし続ける）。NUS はすでにこれらの原則に基づいたカリキュラムを構築しています。Alborz の言葉を借りれば、もし自分が学生なら、曖昧さの解消に全力を注ぐだろう、と。そのスキルは抽象化が変わっても価値を持ち続けます。主なポイント：信頼こそが製品であり、それは監査可能性、シグナル対ノイズの規律、説明可能性によって構築されます。人間の役割は、コードを書くことから、判断し、委任し、エージェントにはできないことを解決することへと移行します。チームがこれらの課題にどう取り組んでいるかの事例パネルは純粋に理論的なものではありませんでした。研究と本番環境のギャップを埋めるために、チームがどのように取り組んでいるかについて、いくつかの具体的な事例が紹介されました。 GitHub Copilot のアーキテクチャ専門化。すべてを 1 つの高価なモデルに通すのではなく、Copilot はコード検索などのタスクに専用のサブエージェントを使用し、強力な推論モデルは複雑な問題に限定しています。これにより、モデルの置き換えではなくシステム設計を通じて、より高い品質をより低いコストで実現しています。 LinkedIn の強化学習インフラ。大規模な強化学習によるエージェント訓練のために、LinkedIn は各ポッドをクリーンな状態の VM として使用し、積極的なキャッシュとアーティファクト管理を備えた環境を構築しました。各ステップで完全な git チェックアウトを行う初期設計ではスケールできませんでした。最終的なシステムは約 800 の問題でオンラインのトラジェクトリ生成を実行しました。これはアルゴリズムの改善に先立つ、大規模なインフラ投資でした。 Mistral のコンピュートリバランス。 Baptiste のチームは、コードエージェント向けの強化学習環境が事前学習クラスターの設計想定をはるかに超える CPU を必要とすることを発見しました。これをアルゴリズムの問題ではなくインフラの問題として認識したことが、重要な洞察でした。 NUS のカリキュラム再設計。 Abhik のチームは、新しい現実を反映したカリキュラムを構築しています。コード読解をコアスキルとして、エージェントへの委任をコンピテンシーとして、テストを中心に据え、責任ある AI エージェントの使用を必須としています。ジャッジキャリブレーションのためのペアワイズ比較。 Alborz は、「このコードはあのコードより優れている」というスタイルのデータセット構築を提案しました。作成コストが比較的低く、絶対的な校正が困難な場合でも、ジャッジが信頼性の高い相対ランキングを学習するのに十分です。 AI が AI をレビューする。 Microsoft の Shengyu のチームは、AI 支援コードレビューに取り組む先駆者の一つです。コードレビューエージェントが仕様、要約、意図された動作、テストを使用して一貫性をチェックします。目標は、人間がビジネスロジックに集中し、AI が構造的な検証を担当することです。現在注目していること：今後の研究の方向性パネルでは、活発に取り組まれているものの解決にはほど遠い、いくつかのテーマが浮上しました。スケーラブルな強化学習環境。これは最も強いコンセンサスポイントでした。エージェント型コーディングに RL を試みたすべてのチームが、同じインフラの壁にぶつかっています。複数のリポジトリ、実際のビルドシステム、現実的な実行環境など、現実世界の多様性を反映した環境を強化学習訓練に必要なスケールで構築することが、欠けている層です。メタ評価：ジャッジを評価する。 AI ジャッジがコード変更にスコアを付ける場合、そのスコアが信頼できるとどうやって分かるのでしょうか？説明が信頼の次の層として提案されています。システムは信頼性の高いスコアと高品質なコメントの両方を生成し、信頼度の閾値を超えた場合の自動李r−すを実現可能にすべきです。しかし、その信頼性を確立することこそが困難な部分です。生成されたコードからの仕様抽出。長期的な目標は、生成されたコードから直接意図を復元し、人間が実装を再確認する必要をなくすことです。これは仕様駆動開発を影響分析（変更がコードベース全体にどのように伝播するかの理解）と結びつけます。修復ではなく再生成。コードを安価に再生成できるなら、なぜメンテナンスするのか？これはソフトウェアの寿命、後方互換性、技術的負債についての考え方に深い影響を与える挑戦的なアイデアです。共有評価基準。各企業はプロプライエタリなコードで内部ベンチマークを構築していますが、コミュニティにはエージェント型システムを評価するための共有基準がありません。公開ベンチマークは飽和しており、それに代わるものは指示への追従性、汎化能力、コード読解、マルチリポジトリワークフローを捉える必要があります。カスタマイズ可能なジャッジ。コードレビューにおいて、組織ごとに重視する点は異なります。重大度、スタイル、順序、見た目の問題など。画一的なジャッジは大規模には機能しません。今後の道筋は、組織のコンテキストに合わせて調整可能なジャッジを必要とします。

AWS の技術ブログ

コンテンツ