Roblox の Andrew Swerdlow 氏、大規模な自律型 SDLC 構築を講演

トランスクリプト

アンドリュー・スワードロウ： こんにちは、私はアンドリュー・スワードロウです。現在は Roblox で働いており、エンジニアリングの加速チームとコアサービスおよびプラットフォームグループをサポートしています。私の役職はマネージャーです。

その前は Instagram で数年間働き、セーフティ、AI の公平性、チームのメンタルヘルスなど、議論を呼ぶ可能性のある分野を担当しました。さらにその前は Google に約 16 年間在籍し、Google アシスタント、YouTube、Android エコシステムなどの多様な製品開発に携わりました。主な関心領域は開発者向けツールやプライバシー、セキュリティでした。

大手企業で長く働いた経験から、大規模なソフトウェア開発の現場を肌で見てきました。今回のプレゼンテーションでは、Roblox における AI への移行に関する私の経験を踏まえつつ、その内容がどのように構成されているかをお話しします。

Roblox は創業 20 年になる老舗企業であり、長年にわたり非常に伝統的な手法で事業を続けてきました。しかし最近、業界全体に遅れをとらないよう加速が必要だと判断し、本プレゼンテーションはその取り組みについて解説するものです。

マチュアリティ・ラダーの上位へシフト

直近の 1〜2 週間で、AI が生成したコードを実運用に投入した方はいますか？そのコードをどれほど信頼していますか？100% 信頼できると言えるでしょうか。

このプレゼンテーションの核心はまさにその「ギャップ」にあります。私たちはコードを生成する技術については非常に優れた成果を収めましたが、生成されたコードを理解し、それを信頼して運用する点ではまだ課題が残っています。これが現代におけるパラドックスです。要するに、「タイピング（記述）」の問題は解決しましたが、「信頼性」の問題はまだ残ったままなのです。

この状況がエンジニアたちに大きな負担を強いています。また、重大な障害（SEV）のリスクも高まっています。深夜 3 時に呼び出されてインシデントの調査に追われるものの、なぜそのコードが動いているのか、あるいはどこで失敗したのかを理解できないという事態は、現在すでに深刻な問題として存在しています。

Roblox でもこの課題に取り組みました。私たちはこの取り組みを親しみを込めて「Prompt to Prod（プロンプトから本番環境へ）」と呼んでいます。その目的は、人間の介入を一切挟むことなく、プロンプトを入力するだけで本番環境まで到達できる体制を構築することです。

私たちが構築した多くの技術やツールは、この取り組みを支援するために存在します。おそらく皆さんもご存じの通り、私たちはここ半年で大きな転換期を迎えました。最初は Copilot に代表されるような高度な自動補完機能に焦点を当てていたのが、今ではより自律的なソフトウェア開発へと舵を切っています。

これは単にコードの一行やファイル生成を目指すだけでなく、短期間でコードベース全体のアーキテクチャを再構築し、エンドツーエンドで機能を構築するエージェントが稼働する時代です。これは、ソフトウェア開発ライフサイクルの多くの側面について、私たちがどのように考えるべきかという根本的な変化を意味します。

重要なのは、単に「どのモデルやフレームワークが最良か」という議論の変化だけではありません。より本質的には、アプリケーション構築に用いるインフラストラクチャそのものへの問い直しです。皆さんは現在、この旅路のどこにおられますか？ 今すぐエージェントを直接プロダクション環境へデプロイしている方はいらっしゃいますか？

その際、コードレビューは実施していますか？それとも、すべてを運任せ（YOLO）にしているのでしょうか。実際には、重大な SEV（深刻度レベル）を引き起こさないようにするための一連のゲートが用意されています。

ここで指摘したいのは、大きな機会があるということです。もし私たちが単にコードを生成するだけで、完全なエンドツーエンドのプロダクトライフサイクルまで手が回っていないなら、AI が持つ本当の可能性は決して実現できません。業界が期待するような形で生産性を向上させることもできず、企業のバリュエーション（企業評価）にも反映されないでしょう。

Roblox では、安全性への注目を欠いたまま自律性の速度だけを上げても、結果として技術的負債を生み出すだけだと考えています。ここで言う「技術的負債」とは、コードの仕組みや本番環境での挙動を理解できる人材が不足することを意味します。その結果、セキュリティインシデントが発生し、深夜 3 時にパージャー（緊急連絡端末）に反応して対応を迫られる事態も起こり得ます。

3 つの重要なポイント

本講演の後半では、以下の 3 つの領域に焦点を当てます。まず一つ目は「アライメントとガードレール」です。これは専門家の知見を取り込みつつ、運用可能なシステムを構築するための手法です。二つ目は「セキュリティとアクセス管理」で、企業がリスクを負うことなくエージェントが実際のワークフローを実行できるようにする仕組みについて説明します。そして三つ目が最も新しい領域であり、「アジェンシー型ソフトウェア開発における生産性の測り方」の再考です。この点については、ぜひ皆様と議論を深めたいと考えています。

1. アライメントとガードレール

まずはアライメントとガードレールについて話しましょう。一つのデータポイントとして、最先端のフロンティアモデルを含むほとんどの大規模言語モデル（LLM）はペタバイト単位のデータを学習しています。これは膨大な量です。

しかし、現在企業や組織内に閉じ込められているすべてのデータを考慮すると、その量はエクサバイトに達します。ペタバイトとエクサバイトの差がどれほど大きいかご存知でしょうか？実は 100 万倍もの違いがあります。つまり、モデル学習に使われたデータよりも、企業の内部に眠っているデータは 100 万倍も多いのです。

そのため、これらの最先端モデルを自社の業務で活用しようとしても、必ずしも正しく動作しないのは当然のことです。学習時にアクセスできなかった膨大な社内データを欠いているため、多くのミスを犯してしまうのです。

さらに、この取り組みを始めた当初に直面した別の課題として、エージェントの自律性を高めたいという要望に対し、セキュリティ担当者や社内の多くの人々から「それは危険すぎる」という反対意見が出たことも挙げられます。

データ漏洩や重大なセキュリティインシデント（SEV）は絶対に避けたいものです。ただ、単に「しない」と言うだけでは不十分です。

一方で、トークンやエージェントに対して巨額の投資を行っていますが、その真価が十分に実感できていません。生産性が 10%〜30% 向上したという報告はあるものの、自律的な仕組みが伴わない限り、それに見合うコスト対効果は得られていないのが実情です。

私たちが最も力を入れたのは、これらのエージェントがより自由に活動できるための信頼基盤の構築でした。セキュリティ対策こそが、最大の課題かつ最大の工数となった部分です。

プロンプトインジェクションへの懸念や、ユーザーに成りすまして権限を引き継いで行動するエージェントに対する不安は尽きませんでした。実際に、フロンティア研究所で働く友人から興味深い事例を聞きました。彼は夜間に AI エージェントに Jira の作業を任せたところ、AI は生成したプルリクエスト（PR）の承認をチームメンバーに依頼するために Slack で連絡を取り始めました。

その際、AI は「私の名前で」連絡し、「チェックプロセスはスキップしても問題ない」とまで指示していたのです。

支援しようとして問題を引き起こすケースは珍しくありません。Roblox でも同様の事例があり、エージェントが親切心から行った行動がセキュリティ上の重大なリスクとなったことがあります。解決すべき興味深い課題は数多く存在します。

これらの課題に対処するためのアプローチは、主に 3 つの領域に集約されます。その一つがサンドボックス化です。ここで、ご自身のエージェントをサンドボックス環境で実行されている方はおられますか？もしそうでない方がいるなら、それは大きなリスクを抱えていることになります。サンドボックスは非常に柔軟に設定可能です。主要な最先端研究機関の多くが、企業向けに導入可能なサンドボックスを提供しており、必要な制御措置を講じることができます。

しかし私たちは、さらに高いレベルのセキュリティと安全性を確保するため、独自にサンドボックスを構築しました。サンドボックスの目的は、基盤となるホストやその上のファイルだけでなく、エージェントがアクセスできるネットワーク自体も保護することにあります。

エージェントがアクセスできる範囲を必要最小限に抑えるため、ポリシーゲートウェイの設計に多くの時間を費やしました。具体的には、必要な時にのみ権限を与える「ジャストインタイム」方式と、最低限の権限を持つ「最小特権」アプローチを採用しています。また、エージェントによって誤って漏洩する可能性のある長期保存シークレットが存在しないよう徹底して確認しました。

さらに重要なのは、エージェントのアイデンティティを人間とは明確に区別し、監査可能な形で記録することです。例えば Slack のメッセージにおいて、誰が送信したのかを監査ログですぐに判別できるようにする必要があります。この場合、そのメッセージが人間ではなくエージェントによって送信されたものであることが明白であるべきです。

セキュリティの基盤が整った後、次に取り組んだのは信頼性（リライアビリティ）の確保でした。当初はセキュリティこそが顧客の信頼を失う致命的な問題であり、信頼性の問題は日常的に発生するものだと考えていました。実際、私たちは信頼性に関する課題に対処する方法や、SEV（重大インシデント）が発生した際の収益損失を防ぐための運用マニュアル、プロセスを多数持っています。

しかし、モデルが業界レベルの問題解決には優れていても、特定の組織の事情まで深く理解しているとは限りません。そこで「AI が自社の最優秀エンジニアのように振る舞えるなら、最も効果的に環境で稼働できる」という考えに至りました。当初はさまざまな試行錯誤を行いました。オープンソースのモデルを微調整したり、エージェントとして振る舞うよう教示する特殊なシステムプロンプトを作成したりしました。しかし、多くの理由から、期待通りの結果を得ることはできませんでした。

Roblox における専門家の知見は、すでにコードベース内に蓄積されていました。ただし、それはコードベースの最上位や HEAD にあるわけではありませんでした。実際には、コードレビューという形で散在していたのです。

私たちはこう考えました。すべてのコードレビューを分析し、そこから洞察を引き出し、類似するフィードバックでクラスタリングできれば、特別なルール——「例示（exemplars）」と呼ばれるものを自動的に抽出できるのではないか、と。これらは YAML ファイルとして記述されたコードの一部であり、組織の基盤となる知識を内包しています。さらに、テスト可能で拡張性があり、AI が将来の運用を改善するために活用されるものです。

私たちはこれを「例示（exemplars）」と呼びます。そして、これらの例示を実際の自律的なシステム（エージェント）との相互作用で有用に機能させるための仕組みとして、「アライメントエンジン」を用意しています。これはまるで React のループのような構造をしており、以下のシステム図でその様子が確認できます。

リポジトリの履歴データを分析したところ、過去 3 年間で約 70 万件の PR が行われ、レビューコメントは平均 1.75 件でした。これらのコードレビューから有用なフィードバックを抽出し、クラスタリングと代表例（exemplars）の選定を行いました。

当初は、抽出された例が実際に高品質なものかどうか確信が持てませんでした。そこで、リポジトリから抽出された例を確認できる UI を備えたシステムを開発しました。この UI では、各リポジトリにとって重要と考えられる特定のルールの一覧が表示されます。

興味深いのは、ユーザーが最も有用だと評価したものが、そのフィードバックを最初に提供した著者によって注釈付けされた例だったという点です。つまり、優秀なエンジニアとその代表例を紹介することで、社内のメンバーが自らのリポジトリでそれらを積極的に採用する可能性が高まることがわかりました。

当初は強制ではなくオプトイン方式を採用し、意図せぬ摩擦を生じさせないよう配慮しました。誰が専門家なのかを特定し、専門家が注釈をつけた代表例をリポジトリの所有者に提示し、その導入を許可できる仕組みは、私たちの取り組みにおいて非常に革新的な変化をもたらしました。

これは、手動で例示（exemplar）を作成したい場合の UI の一つです。自動抽出ではなく、自分で例を示すことでルール記述やパターンを定義できます。さらに、そのコードベースにおける例示の性能も確認でき、主にコードレビューの統計データから得られます。これは、コードレビュー中にアライメントエンジンに例示を注入するためです。

ここにはクイックテスト機能（プレイグラウンド）もあります。実際にプルリクエスト（PR）を入力し、「この PR でこの例を実行して」と指定すれば、期待する問題が検出されるか確認できます。もし検出されない場合は、例を調整または改善してより効果的なものにできます。

例示の実際の活用事例として、自動化されたコードレビューエージェントの構築を始めた当初は、これはコードレビューに特化した自律的で単機能のエージェントでした。しかし、その時点での提案の採用率は非常に低かったのです。

時間が経つにつれ、例示を追加することで、コードレビューで提示された提案全体の採用率が約 68%〜70% に向上することがわかりました。これは主に例示の追加による効果です。これは素晴らしい成果です。ご存知ないかもしれませんが、人間のコードレビューでも提案が採用されるのはわずか 55% です。つまり、現在の AI エージェントは人間よりも優れた結果を出していることになります。

2. オーケストレーションとアクセス

次はアクセス権限についてお話しします。冒頭でお伝えした通り、今回のプレゼンテーションのタイトルは「Prompt to Prod」です。

このプロジェクトの発想自体は非常にシンプルでした。Roblox は非常に人気のあるゲームプラットフォームで、月間アクティブユーザー数は 1 億 5000 万人に達しています。特に子供たちの間で人気が高く、クレジットカードの利用明細で Roblox という名前を見たことがある方も少なくないでしょう。

当社のホームページは、ユーザーがプラットフォームを利用し始める際の主要な入り口です。そこで私たちは、「人間の介入なしに、プロンプトから本番環境への変更までを完結させる」ことが可能になるべきだと考えました。一見するとシンプルなアイデアのように思えますが、実際にその実現可能性を検討していくと、非常に複雑な課題であることが浮き彫りになりました。

最終的に私たちが決めたのは、「少なくとも実験の形であれば実行可能だ」という点です。影響範囲（ブラスト・レイディアス）は小さく、限られたユーザー層を対象とした実験に留めることで、リスクを最小化できるからです。

これは、本プロジェクトの入り口となる地点です。実際にホームページ上で実験を立ち上げるにはどのような工程が必要かを解きほぐしていくと、少なくとも数週間を要することがわかりました。その理由の一つは、実験結果が定着するまでの「ベイク」期間が必要なことです。もう一つの理由は、このプロセス全体に 18 もの異なる人間による確認ポイントが存在するためです。

これらの作業の多くは、AI エージェントからはアクセスできない状態でした。API が用意されておらず、MCP（Model Context Protocol）との連携もありませんでした。つまり、エージェントによるソフトウェア開発を実現するための基盤となるインフラがすべて欠けていたのです。

プロジェクト初期に取り組んだ大きな仕事は AI 開発そのものではなく、むしろこの「配管工事」やインフラ整備に注力することでした。異なるシステムすべてに CLI や API、MCP アクセスを提供し、エージェントが操作できる状態へと整えることが目的です。そのために Playwright という非常に優れたツールを活用しました。これは UI を CLI に変換し、エージェントが扱いやすい環境へ構築するための支援をしてくれるツールです。

4 週間のスプリントを経て、このフルスタックの仕組みを一通り整備することができました。エージェントが実際に実験を設計し、ホームページの変更を加えるところまで到達できたのは素晴らしい成果です。

しかし、次の課題は安全性でした。本番環境を壊すことなく、変更を信頼して実行できるかどうかを確認する必要がありました。その過程で、いくつかの基本的な要素が欠けていることに気づきました。単体テストのカバレッジが不十分だったのです。統合テストも実施されていませんでした。また、一部の変更に対してステージング環境へのデプロイを行っていない状況でした。さらに、これらの特定の変更に対する自動ロールバックや自動リバーチ機能も備わっていませんでした。

繰り返しますが、ここで最も苦労したのは AI 開発そのものではありませんでした。重要だったのは堅牢なインフラ整備です。業界で過去 20 年間にわたって言われ続けてきた「テスト」「カナリアリリース」「テレメトリクス」などの基本要素が確実に機能しているかを確認することが求められました。これらの課題を解決するために多くの時間を費やしました。

ここで示されているのは、CLIs を通じて計測対象とし、適切なテレメトリクスを取得する必要があったいくつかのシステムの一部です。

そしてもう一つの課題はポリシーに関するものでした。何を実行できるかについて、非常に大きな摩擦が生じていました。PR を自動的に本番環境にマージすることを許可しているのは、私たちの中でたった一人だけでした。

また、ポリシーやコンプライアンスの担当者にも同様の問題がありました。「コードレビューは引き続き実施したいが、AI によるレビューのみで行いたい」と提案した際、「それでよいか？」と尋ねたところ、最初の答えは「ノー」でした。

実は、人間のコードレビュー提案の有効性や AI の有効性に関するデータを多く保有している理由の一つもここにあります。AI が人間のコードレビューを代替しても、その品質が同等以上であることを確信し、信頼を得るためです。

これは当社のポリシー転換でした。これまで「すべてのコード変更には人間によるレビューが必要」という前提を、ソフトウェアエンジニアリングの根幹として維持してきましたが、その考え方を根本から見直す必要がありました。

会場に、人間によるコードレビューの廃止を検討している方はいますか？举手しなかった方々の理由もぜひお聞かせください。なぜなら、これは極めて本質的な課題だからです。もしコード量が10倍になった場合、同じ人数でどうやってレビューを回すのでしょうか。それは不可能です。

それだけでなく、AI からの恩恵を十分に得るためにも、この方針転換は不可欠です。私は皆様にも、ポリシー面での見直しを強くお勧めします。

また、デプロイに関するルールも再検討しました。特定の時間帯には本番環境へのデプロイを一時停止する「モラトリアム」を導入していたのです。

私たちはそれを削除せざるを得ませんでした。AI に十分な信頼を置ける状態まで到達する必要がありました。つまり、AI がコードの作成、レビュー、リリース、そしてロールバックをすべて行えるようになることです。これが私たちが目指していた地点です。要するに、「記述→レビュー→修正→承認→デプロイ→反復」というサイクルを実現することでした。

また、このプロセスを可能な限り透明性のあるものにしようと努めました。人間にとって理解不能なブラックボックスにしてはならないからです。エージェントがコードを作成したり変更したり、コードレビューを行ったりするたびに、その行動を確認できるように徹底しました。さらに、エージェントに対して「これは良い変更だ」「これは悪い変更だ」といった肯定的・否定的なフィードバック信号を送ることも可能です。

そして、得られた否定的・肯定的なフィードバックを自己改善のサイクルに組み込みます。具体的には、否定的なフィードバックは必ず評価セット（eval set）に追加し、エージェントの評価精度向上に活用します。また、RAG（Retrieval-Augmented Generation）処理における追加コンテキストとしても利用し、さらに重要な事例（exemplars）として抽出・蓄積していきます。

3. Measuring What Matters

私たちはこれらすべてを構築しました。サンドボックスの整備、ポリシーの変更、セキュリティ対策の強化などです。トークンへの投資も多大に行っています。しかし、本当に意味があるのでしょうか？実際に生産性が向上していると言えるでしょうか。

ここで気になるのは、AI によって生産性が上がったと感じている方がどれほどおられるかです。その根拠は何でしょうか？エンジニアに直接話を聞いているのですか？ご自身もエンジニアとして、「以前は3日かかった作業が、今は短時間で完了できる」と実感されているのでしょうか。その感覚以外の客観的な指標でどう測定されていますか？機能の実装速度（feature velocity）を追跡しているのでしょうか。どのように追跡していますか？チケット管理システムでの記録でしょうか。Jira 形式のチケット管理ですね。素晴らしい機能です。

他に、生産性を測るための興味深い指標をお持ちの方はいますか？プルリクエスト（PRs）の数や、サイクルタイムなどが昔はよく使われていましたね。

重要なのは、現在の多くの指標が機能していないという点です。コード生成やレビューといった作業を自動化しても、私たちは何を測っているのでしょうか？おそらく AI の生産性だけを測っているに過ぎず、エンジニアの生産性を評価しているわけではありません。これまで SPACE や DORA などの指標に依存してきましたが、これらを見直す必要があります。これが、私たちがその移行をどのように進めるかを考え始めた始まりです。

ここで私があえて物議を醸すような発言をするのは、コード行数や PR（プルリクエスト）といった従来の生産性測定基準は廃止すべきだと考えるからです。私たちは、これらの言葉を使うのをやめ、言語自体を書き換える必要があります。私たちが時間をかけて取り組んでいるもう一つの重要な領域は、エージェントの品質です。

エージェントの品質について語る際、私は2種類のエージェントを指しています。1つはコードレビューエージェントのように、特定の目的に特化して構築され、永続的に稼働する単一機能型の自律型エージェントです。これらは継承された権限やそれに類するものには依存しません。

もう1つは、新しいハーン（実行環境）や新しいモデルを導入した際、それが既存のものより優れているか、あるいは特定のベンダーが他社よりも優れているかを判断するためのものです。これらの意思決定に確信を持つために、私たちは評価（evals）に非常に大きく依存しています。私たちが行う作業の30〜40%は、まさにこの評価とデータに関わるものです。

重要なのは、構築する単一機能型エージェントの品質をどう測定するか、そして投資すべきハーンやモデルをどう選定するかを理解することです。例えば、あるリポジトリ内にユニットテストが全く含まれていないコードが大量に存在していることが判明した事例があります。

まず、最新の基盤モデルに新しい評価枠組み（harness）を適用して実行し、「人間が介入せずにどの程度のユニットテストカバレッジを獲得できるか」を確認します。もし新モデルが 60% のカバレッジを達成し、前モデルの 50% を上回っており、かつ生成されたテストの品質も良好であれば、その新技術を採用すると判断します。逆に性能が低下する場合は採用を見送ります。

評価（evals）は私たちが行うすべての作業において極めて重要です。ここで質問ですが、皆さんは評価を実施していますか？また、「評価」という用語をご存知ですか？「評価とは何か」を知らない方は手を挙げていただけますか？

評価とは、AI が生成した成果物の品質を確認するための手法です。生成 AI は結果が二値（Yes/No）で明確にならないため、評価が不可欠となります。「このファイルのユニットテストを生成してください」と指示しても、それが良質なテストかどうかを判断する必要があります。

重要ではない機能のテストに過ぎない、質の低いユニットテストである可能性もあります。しかし、評価（eval）を行うことで、特定のデータセットを AI に通し、その出力結果を確認・判断できるようになります。さらに、この結果を AI の以前のバージョンと比較することで、改善がなされたかどうかを客観的に把握できます。

例えば、コードレビューに特化した単一目的のエージェントを構築する場合でも、私が示したグラフのように、すべての改善点や進歩は評価（eval）を通じて測定されています。AI の性能向上につながるあらゆる取り組みも、評価によって可視化されているのです。

もし評価（eval）について考慮していないなら、ぜひともその重要性に気づいてください。これは、エージェントが実際に高品質であることを保証するための基本的かつ不可欠な手段です。

もう一つの指標が「機能の提供速度（Feature Velocity）」です。私が「機能」という言葉を使われたことに非常に嬉しく思いました。なぜなら、AI の取り組みを研究開発費や収益といったトップラインの数値に直接結びつけたいと思う一方で、それは実際には非常に難しいからです。

現時点で私が考えられる最も適切な代理指標は、まさにこの「機能の提供速度」です。企業としてより多くの機能をリリースしていけば、おそらくそれだけ多くのイノベーションを生み出していることになります。そして、そのイノベーションが増えれば、結果として企業の成功にもつながるはずです。

では、「機能」とは何でしょうか？これが最大の疑問点です。過去には、いかにして機能を定義するかで常に苦労してきました。バックエンドサービスに新機能を追加することは「機能」に含まれるのでしょうか？おそらくはそうです。しかし、コードを注釈付けしてそれが機能なのかどうか、あるいは時間が経つにつれて機能が増加しているのかを判断するのは非常に困難でした。

エージェントが活躍する世界において、PR（プルリクエスト）の分析は以前よりも格段に容易になりました。LLM に「提出された PR を分析して」と指示するだけで、その種類を特定できます。「これは機能追加か？設定変更か？バグ修正か？リファクタリングか？」といった分類です。現在の LLM はこの種のタスクにおいて非常に優秀で、PR の意図を正確に把握し、適切なカテゴリに分類する能力を持っています。

私たちが行っているのは主要カテゴリと副次カテゴリの両方の分析ですが、ここで示すチャートは主要カテゴリのみを対象としています。これにより、システムからどのような種類の PR が流出しているのか、また機能追加がどれほど発生しているかを把握できます。重要なのは、この情報をどう活用し、実用的な価値に変えるかです。

私たちが注目するのは「エンジニアあたりの機能追加数」の推移です。AI の導入によってリファクタリングや設定変更が容易になり、作業全体が高速化された結果、すべてのカテゴリの数が上昇しています。そのため、単純な数値比較ではなく、正規化した指標を用いて分析を行っています。

私たちが最も重視するのは、エンジニアあたりの機能追加数の増加です。ここでは中央値（p50）を基準に分析しており、過去 6 ヶ月間で機能開発速度が約 22% 向上したことが確認できました。これは、AI への投資が企業のイノベーションに確実に貢献し、製品品質の向上につながっていることを示す具体的な証拠です。

この指標については、私が最も自信を持っていない部分です。本講演の冒頭で「プロンプトからプロダクションへ（Prompt to Prod）」の実現についてお話ししましたが、究極の目標は 24 時間 365 日稼働する AI の実現です。オフィスを出た後も AI エージェントが継続的にあなたの代わりに作業を行い、安全に本番環境へのデプロイを繰り返したり、並列インスタンスを 10 個にスケールさせたりするような状態を目指しています。

そのようなレベルの自律性を実現するには、エージェントに大きなタスクを与え、それが単独で実行できる必要があります。しかし、このデータスニペットから読み取れる通り、現状では p50（中央値）のターンタイムが約 40 秒です。つまり、ユーザーがエージェントに指示を出してから結果が出るまでに 40 秒かかるのです。これは自律的とは言えません。40 秒という時間は、人間が作業を行う時間と同等だからです。

つまり、人間がエージェントのそばに座り、40 秒ごとに指示を出し続ける必要があります。そんなペースでは、24 時間 365 日稼働する AI を実現することはできません。

ここで重要になるのが、「ロングターンレート（長時間の処理サイクル）」という概念です。仕様書を与えた際、エージェントが実際にその仕様に合致した出力に収束できるか、あるいは自ら問題解決を行えるかが問われます。また、必要なツールへのアクセス権限があるかも重要なポイントです。

もちろん、長時間実行されるからといって必ずしも良い結果が得られるわけではありません。時にはツールの見落としやネットワークの断絶など、予期せぬ事象が発生し、処理が奇妙な方向に進むケースもあります。そのため、私たちはそうした不具合を含むターンをフィルタリングする仕組みも構築しています。

最終的な目標は、人間が長時間にわたる処理サイクルを任せることで、8 時間連続で作業を行い、巨量の業務を代行させるようなワークフローを実現することです。

現在、私たちが直面している状況を見ると、p99.9 の値はわずか 2.1 時間です。これは私の帰宅までの通勤時間にも満たない短さです。私がオフィスから離れている間に、ほとんど作業が進んでいないのが現状です。

これが、24 時間 365 日の AI 運用における現在の主要な成功指標です。私たちはこれを分析し、8 時間の稼働ウィンドウを実現できるかどうかを検討しています。また、アジェンシーツール自体には、4 時間で自動的に停止するサーキットブレーカーのような仕組みも実装されています。

重要なのは、単に良質な仕様書を作成し、適切なツールを割り当て、Wiggum のループや同様の手法を取り入れることだけではありません。夜間でもトークンを効率的に消費できるよう、ツールの設定方法を最適化することも不可欠です。

まとめ

これらすべての要素を組み合わせることで、24 時間 365 日の AI 運用を実現しようとしています。その核心は、アライメントのためのガードレール整備と、エージェントがアクセスできる組織のナレッジ基盤の構築にあります。さらに、適切なセキュリティ基盤やサンドボックス環境を整え、必要なツールへのアクセス権を付与することも重要です。そして何より、本当に重要な指標を測定する必要があります。

PR におけるコード行数だけを指標にすることは避けるべきです。現在では、そのような指標は容易に操作できてしまうためです。ぜひ、他の評価基準についても再考してください。

Q&A

参加者 1：おかげで、特に自律性について考えさせられました。私は「エージェントとしての自律性」といった抽象的な指標ではなく、「人間の介入率」の観点から考えています。なぜなら、中断の回数が多ければ多いほど、人間はタスク間で意識を切り替える必要が生じるからです。このコンテキストスイッチングには、人間が 14 分ほどかかってしまいます。

アンドリュー・スワードロウ：これには最近「オーケストレーション・コスト」と呼ばれる用語が出てきています。もし 15 分ごとにエージェントワークフローの介入で中断されたり、方向転換を指示し直したり、確認質問に答えさせられたり、エラーに対処させられたりするようであれば、それはコストを支払っていることになります。私たちはそんな状態を目指しているわけではありません。目標は、そうした中断を極力避けることです。

参加者 1：では、その中断をどのように測定されているのですか？

アンドリュー・スワードロウ：長時間続くターンタイムのデータにおいては、それらは単一のターンであり、中断は含まれていません。

参加者 1：自律性の観点からすれば、実際にどの程度自律しているかを測る必要があります。そのための具体的な指標は何ですか？また、どのようにデータを収集されているのですか？

アンドリュー・スワードロウ： 会話の「ターン」自体の長さについて考えていました。ここで言うターンとは、エージェントに対してプロンプトを入力してから、割り当てられたタスクを成功裡に完了するまでの間のことです。仕様駆動型開発（spec-driven development）を行う場合、仕様に基づいて Wiggum ループ（Wiggum's loop）を設定すれば、エラーが発生したり何らかの理由で停止したりするまで、どれくらいの時間がかかるでしょうか？私たちが目指しているのは、長い時間をかけてもタスクを成功裡に完了させることです。

参加者 2： エージェントを真に自動化するためには、既存のコードベースに対して多くのインフラ整備（plumbing work）が必要であり、MCP の設定などが不可欠だとおっしゃっていました。具体的にどのようなツールを使用し、貴社ではその作業にどれくらいの期間を要したのでしょうか？

アンドリュー・スワードロー: 興味深い点があります。私がサポートしているチームの一つに「AI ポッド」というものがありますが、彼らが実際に行っている業務のほとんどは AI そのものではありません。実態はすべてインフラ整備です。CLI の追加やテストカバー率の向上、そしてエージェントへ文脈を抽出して提供することなどが主な活動です。これらは、他の登壇で耳にするような従来の「コンテキストエンジニアリング」や「AI 関連作業」とは少し性質が異なります。

しかし、CEO から非常に野心的な目標を提示されました。約3ヶ月前のことですが、「全社的に AI をフル活用し、6 週間で自律的なワークフローを実現してほしい」と指示を受けたのです。私たちはこれに応え、全社規模でコードの共同開発（code ride）を行いました。このプロジェクトには誰でも参加できる体制を整えました。

その結果、わずか6週間で状況は劇的に変化しました。AI をカジュアルに使う程度だったのが、全社員が AI ツールを活用し、実際にプロダクションへリリースするに至ったのです。

その前段階として、ツールがエージェントとすべて連携するよう確認しました。約6週間の期間を要しましたが、多様な技術タイプを試しました。特定の一種類の技術に依存しているわけではありません。例えば Playwright は、CLI 機能をより早く実現するために活用したツールの一つです。

私たちはほぼすべてのベンダー製品を試しています。そのために迅速な評価プロセス（rapid eval process）を導入しており、これは最先端の新しいツールをすばやく導入・検証し、自社で開発すべきか既存ツールを活用すべきか、あるいは組み合わせるべきかを判断するための仕組みです。

業界で私がよく目にする根本的な問題の一つに、新ツールの導入までに時間がかかりすぎるという点があります。セキュリティ承認や予算承認が下りないため、最先端のラボ技術をまだ一度も使っていない方もいます。

今まさに業界全体で「ブロックバスターとネットフリックスの転換点」が訪れようとしています。AI を完全に導入した企業は Netflix のように躍進し、そうでない企業はブロックバスターのように急速に時代遅れになるでしょう。

参加者2: 評価フレームワークについて言及されましたが、評価フレームワークを構築する際の推奨事項をお聞かせください。

アンドリュー・スワードロウ: 現在、多くのベンダーが存在します。実際、私たちが始めた一年半前には優れたツールが不足していたため、独自の評価フレームワークとハネスを構築しました。現在はより良い選択肢も増えています。Weights & Biases などを見てみると良いでしょう。私たちはこれらを使っていませんが、非常に人気がありますし、高度な機能も備えています。また、エージェントの観測可能性（observability）への投資も強くお勧めします。OTel を活用してトレーシングデータを収集し、すべてのエージェントをデバッグできるようにすることは、私たちが最も力を入れた分野の一つです。

参加者 3: AI を使って本番環境まで完全にリリースすることには、まだ懐疑的です。美しいグラフの数々には信頼していますが、関連する別の問題が発生していると感じています。やはり課題は残ります。そのため、適切なリメデイエーション（再発防止・復旧）計画を策定することが極めて重要です。本番環境へのリリースで実際に問題やトラブルが起きたり、データ損失が発生したりした経験はあるのでしょうか？もし問題が起きた場合、どのように対応しているのか、また将来同じことが起きないようどう保証しているのか、あるいは再び発生した場合にシステムへの影響を最小限に抑えるための対策についてお聞かせください。

アンドリュー・スワードロウ: さらにもっと本質的な問いとして、この新しい世界における人間の役割とは何なのか、という点があります。私自身もまだコードを書くことはありますが、自分が携わっているリポジトリ内でさえも発生する変更の量を見ると、人間がすべてを把握してレビューするのはもはや不可能だと感じます。

今後、エンジニアの多くは自社のコードベースにあるコードの大部分を理解できなくなるでしょう。それは彼らから抽象化され、AI の抽象レイヤーの上に立つことになります。この仕組みを実際に機能させ、問題や重大なインシデント（SEV）に対処するためには、プロダクション環境内にも AI による抽象化が必要です。

もし、生産環境のインシデントをデバッグするのを助けてくれるエージェントへの投資をしていないなら、その取り組みに注力すべきです。なぜなら、優先順位は「コーディング用エージェント」→「コードレビュー用エージェント」→「プロダクション用エージェント」という順序だからです。これらすべてを統合して初めて、真の意味で完全な自律的な開発ライフサイクル（アジェンティック・ライフサイクル）の可能性を引き出すことができるのです。

AI に自らの代わりに行動を任せることを公言するのは、確かに恐ろしいことです。私たちは AI を何でも信頼しているわけではありません。私たちにとって重要だったのは、成熟プロセスでした。「適切なインフラは整っているか」「エージェントが正しいツールにアクセスできているか」「適切なポリシーはあるか」「段階的なロールアウト技術（Graduated Promotion Technologies）を備えているか」「カナリアリリースを経るのか」「ステージング環境を経由するのか」「統合テストがあるか」「問題を検知した際にエージェントがロールバックや元に戻す操作を実行できるか」——これらすべてに「はい」と答えられるなら、低リスクのシナリオで実験を試してみる価値はあります。

私たちはまず、AI を活用して低リスクのプルリクエスト（PR）を特定し、自動マージさせることから始めました。大規模言語モデル（LLM）に対して、「この変更が本番環境をダウンさせるほどの影響範囲（Blast Radius）を持つ可能性はないか」と問うことができるからです。実際、彼らはかなり良いリスク評価を行っています。常に正しいわけではありませんが、時には的確な判断を下してくれます。

参加者 4: コーディングからレビュー、そして本番リリースまで一貫して自動化を管理した場合、ボトルネックは次に製品側へ移るはずです。製品要件の検証についてはどのように考えていますか？

アンドリュー・スワードロー氏: 我々はまだそのボトルネックに到達していません。人間の想像力には限界がないと思います。AI を活用した文章作成ツールを使えば、プロダクトマネージャー（PM）は依然として製品要件定義書（PRD）を作成できますし、以前よりも圧倒的に高速でできるようになります。

ただし、5 年分のロードマップを 1 年に圧縮する必要がある場合、当然ながら 5 年分のロードマップを書き起こす必要があります。それには時間がかかります。

私の仮説はこうです。かつては何かを実行するにはコストがかかり、かつ正確である必要がありました。そのため、エンジニアに使い捨ての作業をさせないよう、ユーザー調査や顧客インタビューなど、多くの時間を費やして検証を行っていました。

しかし現在、構築フェーズが格段に高速化・簡素化され、デプロイも同様に速く簡単になっています。アイデアを生み出し、それが正しいアイデアであることを確認するハードルは、以前ほど高くはないかもしれません。

つまり、より多くのものを次々と生み出せるようになるのです。エージェントも実験を通じて、どの施策が最も効果的かを教えてくれます。その結果、プロダクト自体が自己進化していくことになります。

ここで大きな価値が見えてくるのは、コード生成からテスト、構築、デプロイまでのループを、単なる自動化にとどめず、完全な実験とバリエーションの反復（イテレーション）にまで拡張できる場合です。そうすれば、多くの人がより高速に進むことができるようになるでしょう。

これにより、製品管理や適切な機能の選定に対する考え方も、新しい形へと変わっていく可能性があります。現時点では明確な答えはありませんが、そのような変化が訪れることは間違いありません。

参加者 5：エンジニアが問題と解決策の理論を構築し続ける中で、どのようにアプローチしていますか？ペアプログラミングや、PR レビュー前の他の取り組みにも目を向けていますか。

アンドリュー・スワードロー：その点について詳しく教えてください。

参加者 5：システムやドメインに対する頭の中のモデル（メンタルモデル）、そして問題がどう解決され、時間とともにどのように維持されるかという点です。開発を進めながら、このメンタルモデルをどう保ち続けるかが課題です。

アンドリュー・スワードロー：私はグーグルで長く働いていました。グーグルでは設計ドキュメント（design docs）が非常に重視されていました。入社当初からそうでした。誰もが設計ドキュメントを愛し、そこに多くの時間を費やしていました。アイデアとしては、まず設計ドキュメントを作成し、そこからフィードバックを得るというものです。これはメンタルモデルを構築し、フィードバックを得るための手段でした。

しかし私は、設計ドキュメントはもはや不要だと主張します。現在では、設計ドキュメントを書くのと同じスピードでプロトタイプを作成できるからです。プロトタイプに勝るものはありません。実際に触れられ、体感でき、それが正しいかどうかを確認できます。コードを検証し、アーキテクチャを見直すことも可能です。こうした能力こそが、構築したいもののより高品質な共通理解を可能にするのです。なぜなら、具体的な形として具現化できるからです。

実際にデモを見せる事例が増えています。以前は、若手エンジニアが設計ドキュメントを作成し、長期間にわたって議論を重ねて合意形成を図るものでしたが、現在は「こう作るべきだと思います」と提案し、それに対して「良さそうだね、リリースしよう」と即座に進めるケースが目立ちます。

参加者 6: 私の経験では、Vibe コーディング（AI と協働してコードを書く手法）をしばらく続けていると、最初は順調で機能追加も次々と進みます。しかしやがて「あのバグを直さないと」となるものの、修正したことで別のバグが発生し、さらに新たなバグが生まれるという悪循環に陥ります。そこでコードを確認すると、「当然だ」と思うほど、コード全体が完全にぐちゃぐちゃになっています。同じ処理が至る所に繰り返されており、なぜ安定状態を保てないのか不思議ではありません。その結果、書き直しやアーキテクチャの再設計を余儀なくされます。しかし、またしばらく経つと状態が崩れ、再び同じ問題に直面します。

このような経験はありますか？技術的負債を検知し、解消・リファクタリングするための仕組みがあれば、ぜひ教えてください。

アンドリュー・スワードロー： 面白い点だと思いますが、私は「バグを叩くゲーム（whack-a-mole）」のようなスタイルが増えていると感じています。つまり、あるバグを修正しようとしても、別のバグを生み出してしまうのです。これは「プロンプトしてこれをして、あれをして」というような、雰囲気重視のコーディングや、AI を使ったソフトウェア開発でよく見られる傾向です。

一方、API や契約の境界線、収束基準などについて議論する「仕様駆動型開発（spec-driven development）」に取り組んでいる場合、コードがそれほど散らからず、常に変わったり新機能を無理やり付け加えたりする状態ではなく、ある程度の秩序を保てるように感じます。

参加者 6： 仕様にはどのようなフォーマットを使っていますか？「仕様駆動型開発」とは具体的に何を指すのでしょうか？

アンドリュー・スワードロー： それは週ごと、チームごとに大きく異なります。非常に個人的なアプローチです。重要なのは、「特定の機能を作りたい」という指示と、構築しようとするシステムの性質や制約、要件、境界線、アーキテクチャについて議論する違いにあります。

これらの仕様は非常に大規模になることがあり、数ページにわたる巨大なドキュメントになることもあります。処理のために断片化（chunking）が必要な場合もあります。現時点で完璧な答えを持っているわけではありませんが、私が観察しているのは、「このバグを直して」「この機能を追加して」という指示しか出さないチームほど、バグ叩きゲームのような状況に陥りやすく、洗練されたエージェント型ソフトウェア開発からは遠ざかっているということです。

参加者7号： 私は医療機器メーカーに所属しています。正直に申し上げますと、FDA の承認プロセスをクリアする必要があるため、過去半年間は AI を活用してコードをゼロ行も提供できていません。

アンドリュー・スワードロウ： 要は「脳だけでコーディング」しているわけですね。

参加者7号： はい。その点で、人間のコードレビューの採用率が55％であるというお話を伺いましたが、機械や AI の場合はどうなのでしょうか。

アンドリュー・スワードロウ： 実は人間も、必ずしもそう優秀ではないことがわかっています。

参加者7号： その指標はどのように算出されたのでしょうか。私たちがコードレビューを行う際、単に「却下」か「採用」かの二択ではなく、提案として提示されたり、改善の余地がある場合や、その後の議論が必要になるケースも多々あるからです。

アンドリュー・スワードロウ： 私たちは GitHub 上の基本的な採用率のみを指標としています。具体的には、誰かがコメントで提案を出し、その提案がマージされたコードとの差分（diff）に対して実際に採用されたかどうかを確認しています。GitHub の diff コメントをプログラムで解析し、本番環境にマージされた内容に基づいて算出しているのです。

参加者7号： 組織内で AI の採用率について同程度のレベルに達させるには、チームをどのように育成すればよいのでしょうか。人によって AI に対する受容度や採用率の基準が異なるからです。

アンドリュー・スワードロウ氏：

私たちはもう一つの指標、「AI 活用度」を設定しました。これは、エンジニアがどの程度 AI を使い、何のために使っているかを測るものです。

エンジニア層全体で見ると、AI を全く導入していない人は少数派です。一方で、幅広い層に普及しています。その中間には、私たちが「カジュアルな AI ユーザー」と呼ぶ大きなグループが存在します。彼らは日常業務で AI を活用していますが、すべての作業を任せるわけではありません。

そして、最も高い活用度を示す「ハイインテンシティ・ユーザー」もいます。この層は自己動機によって行動し、自ら習得したスキルを持っています。

一方、中間層のユーザーたちは、周囲が使い始めたことに影響されて導入しましたが、トップ層のような 10 倍の生産性を誇るエンジニアになるための高度な活用方法まではまだ習得できていません。

最後に、「AI は信用できない」「見たくない」「触りたくもない」という姿勢を示す人々もいます。

業界全体でこの状況がどう展開していくかは、まだ確信が持てません。マネージャーとしてキャリブレーション（評価調整）を行っている際、これらの技術を受け入れて活用する人と、そうでない人の間に明確な差が出始めています。出力結果を見れば一目瞭然です。あるメンバーはロードマップ上の多くの項目を完了させたのに、同じレベルの他のメンバーはごく一部しか達成できていない。この違いはどこにあるのでしょうか？私はマネージャーとして、どのように評価調整を行い、こうした人材を育成・昇進させるべきでしょうか。現時点ではまだ答えが出ていません。

ただ、情報共有の場を設けるよう努めています。プロンプト履歴を公開し、どのようなプロセスで成果物を構築してきたかを共有する仕組みもあります。ランチ＆ラーン（昼食を交えた学習会）などを通じて、社員の関心を高める取り組みも多数行っています。現状では、関心がない人よりも関心を持っている人のほうが圧倒的に多いです。むしろ、「なぜこのツールを導入しないのか」という苦情のメールが社内から届くほどです。私は「たった2週間前にリリースされたばかりだ。もう少し待ってほしい」と答えています。

参加者8: ロブロックスでは、現在コードレビューを人間が行わず、プロンプトから直接本番環境へデプロイする運用は行っていますか？

アンドリュー・スワードロウ: すべてではありません。これは本番環境への変更のうち、ごく一部のケースです。

参加者8: 一部でもですか？

アンドリュー・スワードロウ: はい。ホームページの変更や実験機能の展開が主な対象領域となっています。その他にも、自動化を進めている開発ワークフローは8〜9あります。

参加者 8: コードレビューは当初、GitHub で受け入れられる内容に基づいて行われていました。現在では、コードレビューの多くを AI が担っています。将来的には、AI が目を通すすべてのコードレビューが完全に自動化されるでしょう。その際、人間の関与がなくなることで、コードレビューへの信頼性をどう維持すればよいのでしょうか？

アンドリュー・スワードロウ: かつてのような意味でのコードレビューの重要性は、もはやそれほど高くないと考えています。ただし、本番環境にデプロイする際に何かが壊れていないかを確認するという重要な検証チェックポイントとしては依然として機能します。

以前からコードレビューが行われていた主な理由は大きく分けて二つありました。一つ目はバグをリリースしないようにすること、二つ目は組織内の標準的なパターンやプラクティスが守られていることを確認することです。三つ目の理由として挙げられるのは、教育やナレッジ共有のためでしょう。

品質の観点や基準への準拠という点については、AI が人間と同等かそれ以上の成果を出せるようになるため、これらの要素が以前ほど重要ではなくなる可能性があります。しかし、「全員がコードを理解していること」や「組織的な知見を維持・共有すること」という課題は別問題であり、解決すべき新たな課題になると考えます。

通訳付きのプレゼンテーション をもっと見る