6:35 - 7:12

DevPodsの機能：複数リポジトリを統合した作業環境

起動の速さだけでは足りない

前章では、エージェントをすぐに動かせる、準備済みのDevPodを扱いました。しかし、起動が速くても、複数のリポジトリや言語にまたがる仕事を進めやすいとは限りません。必要なコードが、別々の開発環境に分かれていることがあるからです。

この章で講演者が説明するのは、DevPodsの機能をさらに広げる考え方です。Uberは、以前の言語別のdev portから、複数のリポジトリを同じ環境に置く「mega dev port」へ移っています。ここでいうdev portは、この講演で使われる、リモート開発環境の種類を指します。

つまり、エージェントの実行環境には二つの性質が必要です。準備済みの状態によって、作業を始めるまでの時間を短くすることです。そして、複数のコードベースを扱えるだけの広さを持つことです。速さは時間の問題を解決します。広さは作業範囲の問題を解決します。

複数のリポジトリを一つの環境で扱う

言語ごとに別のdev portがあると、一つのリポジトリで作業するには便利です。しかし、複数のサービスを一つの機能として変更するとき、環境の切り替えが境界になります。エージェントもエンジニアも、別の環境へ移るたびに、必要なコードや作業の前提を確認しなければなりません。

**例（教師作成）**として、ある機能が複数のリポジトリと言語にまたがっているとします。エージェントが一つのリポジトリだけに入っていると、関連する別のコードを確認しながら変更することが難しくなります。一つの共通環境に必要なリポジトリを集めれば、同じ作業場所で関係を調べ、変更を組み立てやすくなります。

ここで取り除かれるのは、環境の境界です。認可（authorization）の境界までなくなるわけではありません。共通の環境から複数のリポジトリを扱えても、誰がどのコードを読めるか、変更できるかは、別に管理する必要があります。アクセスの準備を簡単にすることと、権限を広げることは同じではありません。

図：Mega DevPodでは、言語やプラットフォームごとの領域が一つのUnified Environment（統合された環境）に集まっています。

この図は、複数の領域を一つの広い作業環境から扱うという説明を視覚的に支えます。ただし、図だけから、すべての利用者がすべてのリポジトリを変更できるとはいえません。図が示すのは環境の統合であり、認可の設定ではありません。動画の該当箇所（6:50）

ハーネスへの入口を広げる

講演では、統合された環境からエージェントのハーネス（harness）にもすばやくアクセスできると説明されています。ハーネスとは、エージェントを動かし、ツールの利用や複数ステップの処理を調整するアプリケーションです。共通の作業環境があると、コードを置く場所だけでなく、エージェントを使い始める入口もそろえやすくなります。

この入口は、ソフトウェアエンジニアだけのものではありません。講演者は、エンジニアではない人も、会社の仕事のためにエージェントのハーネスへすばやくアクセスできる点を示しています。専門的な環境を一から用意する負担が減れば、より多くの人がエージェントを使い始めやすくなります。

**例（教師作成）**として、エンジニアではない担当者が、会社の仕事でハーネスを使いたいとします。共通の環境からハーネスに入れるなら、担当者は言語別の環境を個別に準備しなくても作業を始められます。しかし、その使いやすい入口が、無制限の権限を与えるわけではありません。担当者が必要なリポジトリだけを読めるようにし、変更や実行には別の承認を求めることもできます。

この例が示す大事な点は、アクセスのしやすさと権限の範囲を別の設計問題として扱うことです。統合されたワークスペースは準備の負担を減らします。一方、認可は、利用者とエージェントが何をできるかを制御します。

まとめ

このDevPodsの機能は、エージェントを速く起動するだけではありません。複数のリポジトリと複数の言語にまたがる仕事を、一つの共通環境で進められるようにします。これは、クロスリポジトリの機能に必要な作業空間の広さを提供する仕組みです。

同時に、共通の入口は共通の権限を意味しません。環境の境界を減らしても、リポジトリごとの認可と、ハーネスが実行できる操作の範囲は保つ必要があります。講演の主張は、速い実行環境、広い作業空間、そして管理された権限を組み合わせて、エージェントを組織で使いやすくすることです。