13:18 - 14:15
CIの前にMinionで構築する
計画をコードに渡す
前の章では、スタジアムでの乗車場所を案内する機能について、調査、要件、デザイン、そしてコードの対応関係を整理しました。ここでCortanaは、作った計画をMinionへ渡します。MinionはUberのクラウド上で動くコーディングエージェントです。
この二つのエージェントは、同じ役割ではありません。Cortanaは、何を作るかを調べて整理する役割を担います。要件、画面デザイン、既存コードとの関係を、実装できる形にまとめます。Minionは、その計画を受け取り、コードを変更する役割を担います。
これは、単に「長いプロンプトを一つのモデルに渡す」という考え方とは違います。計画を作る仕事とコードを作る仕事を分けることで、それぞれに合った情報と実行環境を用意できます。
図1 CortanaからMinionへ、要件とデザインが引き継がれています。
画面上で確認できる要件やデザインなどの成果物は、Minionが何もない状態から推測するのではなく、準備された仕様からコードを書き始めることを示しています。これは画面から読み取れる点です。実際にどの内部データ形式で引き継いだかまでは、この画面だけでは分かりません。
Minionの二つの動き方
Minionは、複数のリポジトリを扱える完全なDevPodの中で動きます。DevPodは、エージェントの作業用に用意されたリモート開発環境です。今回の機能は、モバイル側とサービス側など、三つのリポジトリに関係します。そのため、一つのリポジトリだけを開く環境ではなく、リポジトリをまたいで作業できる環境が必要です。
エンジニアは、Minionを二つの方法で使えます。
- 対話型（interactive）：エンジニアが途中で指示を出し、方針や変更を確認しながら進めます。
- 自律型（autonomous）：エージェントが、設定された目標に向かって、より少ない介入で進めます。
対話型では、人が細かく方向を調整できます。自律型では、人が毎回の操作を行わなくても、Minionが複数の手順を続けて実行できます。ただし、自律性が高いことは、マージや本番デプロイの権限を持つことを意味しません。どちらの方法でも、生成した変更には検証と承認が必要です。違うのは、作業中に人がどのくらい頻繁に介入するかです。
例：対話型と自律型を選ぶ
これは説明のための例です。小さな設定変更なら、エンジニアがMinionに一手ずつ確認させる対話型が適しています。三つのリポジトリにまたがる定型的な変更なら、まず自律型で進め、最後に成果物を人が確認する方法も考えられます。どちらを選んでも、確認できる証拠を省いてはいけません。
CIの前で止める理由
デモでは、Minionは変更を作った後、三つのドラフトPRを作るところで止まります。PR（プルリクエスト）は、コードを取り込む前にレビューするための変更提案です。ドラフトPRは、変更を他の人に見せられますが、まだマージの準備ができていない状態です。
ここでは、共有CIをまだ起動していません。CI（継続的インテグレーション）は、提案された変更をビルドしてテストする、チーム共有の自動処理です。大きな変更をいきなりCIへ送ると、まだ明らかな問題がある段階でも、共有の計算資源や待ち時間を使います。
そこでドラフトPRを境界にします。Minionがまず変更を作り、関係する人が差分を見て、早い段階の検証を行います。問題があれば、共有CIを使う前に修正できます。問題がなければ、その後にCIへ進めます。この停止点は、単なる作業上の都合ではありません。早期の確認と、共有CIの負荷の抑制を同時に行うための設計です。
図2 三つのドラフトPRが作られていますが、CIはまだ起動していません。
画面にある「draft」の状態と、CIがまだ実行されていない状態は、デモが共有CIの前で止まっていることを具体的に示します。ここから分かるのは、検証の順序と状態です。この仕組みが常にどれだけCIの負荷を減らすかという効果までは、この画面だけでは判断できません。
この章の要点
Minionの価値は、コードを生成できることだけではありません。計画を専門のコーディングエージェントへ渡し、複数リポジトリを扱える環境で実行し、対話型または自律型の進め方を選べます。そして、ドラフトPRでいったん止めることで、共有CIの前に変更を確認できます。
つまり、自律的な生成と、無制限の権限は別のものです。生成を速くしても、検証、レビュー、承認の境界は残ります。次の段階では、コード、画面、フロントエンドとバックエンドの連携を、共有CIの前にさらに検証する方法へ進みます。