Gemini Conductor：GoogleのAIコーディング改善ツールが登場

チャンネルで取り上げてきたコンテキストエンジニアリングワークフローの流れから、GoogleがリリースしたGemini Conductorを紹介。しかし、他のワークフローより優れているとは言えず、多くの問題があることを予告している。Automataというサービスについて説明し、数百万人にAIを使った構築方法を教えた経験を活かして、アプリやウェブサイトのアイデアを実現するサポートを提供していると述べている。技術チームがない人向けに、技術的な副操縦士としてコンセプトを実際に機能するソリューションに変える役割を果たすとしている。

Conductorがどのように機能するのかを解説する前に、記事リンクを提示し、Gemini CLIで拡張機能としてインストールする方法を説明。拡張機能とは、コマンド、MCP、その他のルールをパッケージ化してホストし、他の人と共有できるようにしたものであると定義している。ClaudeにもPluginsと呼ばれる類似の機能があることに言及。コマンドを使用してインストール後、Conductorのスラッシュコマンドが利用可能になることを説明している。

Conductorを制御する5つのコマンドについて説明し、最初に使用するセットアップコマンドの動作を詳述。セットアップコマンドは既存のConductorファイルや初期化状態をチェックし、ストーリーの代わりにtracksと呼ばれるファイルを作成して1つずつ完了させる仕組みになっている。新しいGitHubリポジトリを初期化し、何を構築するかを尋ねられた際、テストのために簡単なプロジェクトを作成したと述べている。しかし、プロダクションレディで大規模ユーザー数に対応できるスケーラビリティを持つべきだと伝えたにもかかわらず、適切な推奨が得られるかをテストしたかったと説明している。

product.mdファイルが作成され、構築したいもののコンセプトが含まれたが、質問が単純的でどこにも繋がらなかったため、すべて自動生成させることにしたと述べている。プロダクトガイドを承認後、スタイリングやデザイン原則に焦点を当てたプロダクトガイドラインファイルも作成された。技術スタックを定義する段階で、ワークフローが良くなかった理由の1つとして、プロジェクト全体を把握していたにもかかわらず、提供された技術スタックが混乱しており適切な推奨がなされなかったことを指摘。修正後、技術スタックとMDファイルが承認・更新され、コードスタイルガイドというファイルも作成されたことを説明している。

プロジェクトで使用すると判断された言語が初期化中にコードスタイルガイドに追加される仕組みを説明。使用されているデフォルトのワークフローは実際にかなり良いと評価し、デフォルトで80%のコードテストカバレッジが含まれていることを高く評価している。セットアップやベースコンポーネントの作成中にテストが確実に記述され、タスク完了後にもテストが実行されていたと述べている。また、すべてのタスク後に変更をコミットし、git notesも使用しているため、何か問題が起きた場所やタイミングを実際に追跡できたことをポジティブに評価している。

初期セットアップ完了後、高レベルの製品要件が作成され、最初のtrackに取り掛かれるようになったと説明。しかし、最初のtrackは広範すぎて小さなtrackに分割する必要があり、1つのtrackで実行するには多すぎて失敗する可能性が高かったと批判している。implementコマンドを実行して作業を開始でき、tracksフォルダにはさまざまなtrackが含まれることを説明。各trackには2つのファイル（plan.mdとspec.md）があり、spec.mdには技術スタックと目標・技術的詳細が、plan.mdには1つずつ実装する必要があるタスクが含まれていると述べている。tracks.mdを参照してステータスに基づいて何をすべきかを把握する仕組みを解説している。

statusコマンドは現在進行中の状況とtrackのステータスレポートを提供し、new trackコマンドは新しいタスクのためにさまざまな質問を行うと説明。既存のリポジトリにも実装したが、既存ファイルを確認して明確化のための質問をするだけで、新しいtrackを求められなかったため少し違ったと述べている。新しい機能として自分で新しいtrackを実装する必要があったことに言及。revertという非常に賢い機能があり、実際に損害を軽減しgitを認識しているため、エージェントがどこかで失敗した場合にgitを使用して支援することを評価している。

現在のファイル管理と構造はそれほど悪くなく、新機能や既存のタスクをtrackに実装して追跡する方法は実際にかなり良いと評価。しかし、指示の書き方やコマンドファイルの書き方は改善が必要だと指摘し、その理由としてすべてをチェックする必要があるコンテキストループを適切に管理していないことを挙げている。変更があった場合にどのように変更する必要があるのかが不明確であり、初期プロセス中でさえ多くの間違いがあったと批判。最初の間違いとして、各ドキュメントの作成を求めている間、アイデアを適切に分析しなかったことを指摘している。

多くのことについてガイドする必要があり、十分だと思ったときに残りのコンテンツを自動生成させたと述べている。技術スタックを定義している間も多くのことを見落としており、オプションBは良かったものの、大規模なユーザー数に対応する完全にスケーラブルなアプリが欲しいと伝えたのに、明確化して必要だと明示的に伝えなければならなかった多くのことを見落としていたと批判。その後計画が修正されたが、最初のtrackが生成されたときにデータベーススキーマが完全に不完全で、アプリのセットアップに不可欠な多くのことが欠けており、再びガイドして正しい方向に導く必要があったと説明している。

Geminiは実際に非常に優れたモデルであるため、実装されたコマンドがこのような動作をさせている原因だと疑わざるを得ないと述べている。セットアップ自体は良好であるにもかかわらず、メインのスラッシュコマンドに多くの問題があり、特にワークフローdotMDに問題があると指摘。NPMをPNPMに変更したいと伝えた後、大きな部分を台無しにしてしまい、最初にバックアップを作成しようとしたが、NPMで作成されたファイルを削除する必要があると述べた際に、すべての計画ファイルが含まれているコンダクターフォルダ全体を削除してしまったと説明。その後継続的にフォルダを探し、見つからなかったときにコンテキストとメモリに持っているすべてのものを使用してコンダクターフォルダを再構築すると言ったことを批判している。

通常のコンテキストワークフローが行うべきこととは対照的に、すべてを書き直さなければならなかったと述べている。通常のワークフローでは、変更はメインのコンテキストファイルとその特定のタスクに関連するファイルにのみ影響するはずであり、これがBe Madが効率的に動作する方法だと説明。突然何かを変更するように頼んでいなければうまくいっていたかもしれないが、すべてのタスクを初期化していたときに最初のトラックの実装を開始するように依頼すると、プロジェクトと必要な他のコアサービスを開始して初期化したと述べている。Superbase接続の環境変数を設定する段階で、明らかにダミーキーを入れながらタスクを自動的に完了としてマークし、Superbaseプロジェクトをセットアップしたり実際のキーを提供したりするよう尋ねることさえしなかったと批判している。

自動的にデータベーススキーマをプッシュしようとしたが、実際のキーがなかったため失敗し、文字列を再確認するように求められたことで、タスクが適切に更新されておらず正しく従っていなかったと結論づけている。正直なところ、エンドツーエンドの仕様開発には現時点ではこれを使用せず、Be Madの方がはるかに優れた選択肢だと述べている。小規模プロジェクトの場合は依然として独自のコンテキストファイルを作成していると説明。視聴者にチャンネルをサポートしてこのようなビデオを作り続けるのを手伝いたい場合は、スーパーサンクスボタンを使用できることを案内し、次回またお会いしましょうと締めくくっている。