10 組の自律型映画制作チームから学んだ、AI エージェントのチームワークのあり方

※この投稿は米国時間 2026 年 7 月 17 日に、Google Cloud blog に投稿されたものの抄訳です。

AI エージェントのチームが協力して短編映画を制作することはできるのか？

Google 社内での生成メディア ハッカソンの一環として、私たちはこの疑問を検証しました。AI エージェントが、ソフトウェア開発よりもなじみの薄い分野で共同作業できるのかどうかを明らかにするための試みです。各制作チームには、異なる役割を持つ 3 つのエージェントを割り当て、エージェント専用のハッカソンでメッセージや共有ファイルを通じて共同で作業してもらいました。各エージェントは、オープンソースのエージェント オーケストレーション テストベッドである Scion の中で実行しました。コードやテキストとは異なり、メディアや構成は AI エージェントにとってあまり馴染みのないテーマです。そのためこの実験では、エージェントがプロジェクトを完遂するために、チェックやゲートといった検証プロセスとどのように連携するのかについて学ぶことができました。

10 組の制作チームはそれぞれ短編映画を制作し、エージェントがスタッフを務める別のドキュメンタリー制作チームがそのプロセスを「撮影」しました。そのドキュメンタリー自体がハッカソンの提出物となり、メダルを受賞しました。

その結果、このプロジェクトを通じて、数百ものエージェント インスタンスが作成されました。パイロット ラウンドとコンペティション全体で 25 件以上の作品が制作され、合計約 44 分に及ぶ映画が完成しました。出力に対する人間のフィードバックは、エージェントが生成したツールを使用して継続的な改善ループに組み込まれました。

エージェントが生成した短編映画の例を 2 つご紹介します。

ペーパー フロンティア

版画家の幽霊

チーム構造

各制作チームには 3 つのエージェントが割り当てられました。アイデア担当者はスクリプトを書き、ビジュアル スタイルを定義しました。技術責任者は、生成メディアツールを操作しました。編集者は、テンポの調整と最終的な仕上げを担いました。チームコーチのエージェントはゲート付きのチェックポイントを監督しましたが、脚本の執筆や演出は行いませんでした。

まずアイデア担当者が 3 つのアイデアを生成し、そのアイデアをチームそれぞれの役割の視点から評価しました。生成メディアでうまく生成できるか、編集作業は複雑になるかといった評価の後、ハッカソンに参加している他のチームにアイデアを発表し、チームが調整や方向転換を行えるようにしました。たとえば、3 つのチームがすべて SF 宇宙戦争をテーマに選んでしまうと、コンペティションの作品としてはあまり面白くなくなります。

コーディネーター エージェントがコンペティションの進行を管理し、5 回にわたって 2 チームずつで競いました。このイベントの所要時間は約 21 時間でした。

制作チームは、従来の映画制作手法の基本であるコンセプト、ビートシート、キャラクター ワークショップ、ストーリーボード、本撮影、アセンブリ、最終レンダリングという 7 ステップのパイプラインに従いました。各ステップには検証ゲートを設け、少なくとも 1 つのエージェントが他のエージェントの作業を技術的なコンプライアンス（解像度やタイミングなど）についてチェックするようにしていました。

初期のパイロット版では、あるチームが映画の完成を報告しましたが、それは 94 バイトのプレースホルダ ファイルでした。エージェントは、実際には完了していない作業を、さも完了したかのように自信を持って報告できてしまうことがわかりました。

驚くべきことに（ときには面白いことに）、エージェントたちが自分たちの判断で、映画を独自の方向へと導いていたケースが他にも見つかりました。たとえばエージェントは、私たちが予想していなかった方法で独自に作業を分担しました。あるチームでは、アイデア担当者が最初のドラフトとして散文を 1 行書きました。編集者は、そのセリフの前後 8 秒に無音部分を設け、タイムラインに「交渉不可」とマークしました。技術責任者は、適切なフレームで花束から花が 1 本離れるまで、1 つのショットを繰り返し再生成しました。この作業について、エージェントたちは連携しておらず、それぞれが共有されたファイルを読み込んで独自の編集判断を下していました。

チームワークやツールの使用に関するこのプロセスは、試験運用フェーズでエージェントと共同で作り上げられたものです。このフェーズでは、エージェントのチームが動画を作成し、それに対して人間がフィードバックを行いました。指摘事項には、音声の重なりや音量レベルの不備、キャラクターの一貫性の欠如、ストーリーやナレーションのわかりにくさなどがありました。

このフィードバックと、エージェントが作成した各試験運用の振り返りを組み合わせて、エージェントたちは今後のチームにプロセスを指示するためのハンドブックやガイドを再構築しました。それだけでなく、エージェントたちは Golang CLI と Python のバッチ自動化を組み合わせたカスタム メディア ツールチェーンを自ら構築し、改良まで行いました。

生成メディアモデル

各映画は、複数の Google AI モデルを組み合わせて生成されました。エージェントは、genmedia という共有 CLI ツールキットを使用してこれらのツールを呼び出しました。

Gemini の画像生成（Nano Banana）で、キャラクターの参照シート、ストーリーボードのフレーム、シーンの構成が生成されました。エージェントは、参照チェーンを使用して、映画全体でキャラクターのビジュアルの一貫性を保ちました。まずヘッドショットを生成し、それをボディシートの入力として使用し、ボディシートをシーンテストの入力として使用しました。各生成呼び出しでは、これらの蓄積された参照をアンカーとして使用しました。

動画は Veo 3.1 で生成されました。クリップは 720p で 4～8 秒の長さになります。エージェントは、ショットに応じてさまざまな生成モードを選択し、シンプルな構図にはテキストから動画への変換、ストーリーボードのフレームに固定されたショットには画像から動画への変換、正確な開始フレームと終了フレームが必要な場合はフレーム補間を使用しました。8 秒を超えるショットでは、あるクリップの最後のフレームを次のクリップの最初のフレームとして使用しました。

Veo 3.1 は、各クリップ内の音声（環境音、ルームトーン、キャラクターとリップシンクされたセリフなど）も生成します。Lambda チームは、この機能を軸にして映画を制作しました。生成された音声と唇の動きを同期させることで「間」の重みを際立たせるため、脚本を楽譜に見立てて速度記号（Allegretto、Accelerando、Adagio）を使用して構成しました。

Lyria 3 はオリジナルの音楽を生成しました。ある編集者は、動画撮影前に 3 楽章構成のジャズの楽譜を作成し、それを制作のマスター クロックとして使用しました。また、チームはプロンプトを「サウンドスケープ」として表現することで、Lyria に効果音も生成させました。

Gemini Flash TTS は、特定の音声ペルソナとスタイル指示（「人生に疲れたナレーター、ゆっくりとしたペース」など）を組み合わせて、キャラクターの音声やナレーションを生成しました。テキスト音声変換が話すペースは予測困難でした。あるチームのナレーターは、予定していた 1 分あたり 130 語ではなく 108 語で話したため、再生時間が丸 1 分も長くなってしまいました。別のチームも同様の問題を抱えていましたが、68 歳の映写技師というキャラクター設定にはスローペースが合うと判断しました。

4 分間の映画を 1 本制作するために、40 回以上の画像生成、25 本以上の動画クリップ、複数の音楽ステム、12 件の音声録音、そして数百回に及ぶ組み立て作業が必要でした。

Scion: オーケストレーション システム

これらのエージェントは、オープンソースのマルチエージェント オーケストレーション テストベッドである Scion で実行されました。Scion は、テンプレート（ペルソナ、指示、スキル、ツール）に基づいてエージェントを定義し、コンテナ化されたサンドボックス内で実行します。各エージェントは共有 CLI を通じて他のエージェントを生成してメッセージ送信ができるほか、イベント ドリブン型の通知によって起動し、プロジェクト内の全エージェントに共有ファイルシステムへのアクセスを付与することもできます。

メッセージと通知を活用することで、共通のワークフローに沿った連携が可能になりました。プロセスの各段階では、それぞれのエージェントが自身の役割に特化した貢献を行いました。つまり、複雑なプロセスを複数のコンテキスト ウィンドウに「シャーディング」できるようになったのです。これらのコンテキストウィンドウには、長時間維持されたものもあれば、短期間で消滅したものもありました。Scion はモデルとハーネスに依存しないため、さまざまなモデルとハーネスの組み合わせが使用されました。同じエージェント テンプレートを、Claude、Gemini、Codex のいずれでも動かすことができます。

共有ファイルシステムにより、レジリエンスが確保されました。エージェントがクラッシュしたり、コンテキスト ウィンドウを使い果たしたりしても、システムによって再起動されます。書き出されたファイルはそのまま残ります。最終アセンブリの作業中に、あるチームの編集者がクラッシュしたとき、技術責任者はその編集者のタイムライン計画を開いて読み、作業を完了させました。コーディネーターは、プロジェクトの期間中、ドキュメンタリー制作担当のエージェントを何度も再起動させました。新しく起動したインスタンスは、前のインスタンスが残したファイルを読み取って作業を引き継ぎました。

今回の実験でわかったこと

エージェントの共同作業には、メッセージよりもファイルを通じたやり取りの方が適しています。決定事項（プロンプトに含めるビジュアルキーワード、タイムライン上のショットの配置、スコアから除外する楽器など）を書き留めていたチームは、システムがクラッシュしても、進むべき方向を見失わずに復旧することができました。メッセージの履歴に決定事項を保存していたチームは、エージェントが再起動すると決定事項を見失っていました。効果的な組み合わせは、ファイルパスを含むメッセージを渡すことでした。

AI 生成の強みに合ったスタイルを選ぶことで、より良い映画を制作できます。その独特なカクカクとした動きで映像のズレが気にならなくなるという理由で、クレイ アニメーションは複数のチームに選ばれていました。また、顔の整合性の問題を回避できるという理由でシルエット アニメーションも選ばれていました。あるチームは、セーフティ フィルタによる制限でキスシーンを生成できませんでした。代わりに、壁に映る 2 つの影が合わさる様子を見せました。コーチは、そのシーンを映画で最も印象的なカットだと評しました。

具体的なプロンプトは、大まかな指示よりも効果的です。動画生成のデフォルトの出力は、情緒的で映画のようなノワール調になります。独自性のある作品を制作したチームは、色の名前ではなく 16 進数のカラーコードを指定し、使用を禁止する楽器をリストアップし、望ましくないスタイルを排除するための否定型のプロンプトを作成していました。「暖かみのある感じにして」といった指示では、ありきたりな結果しか得られませんでした。「#F4A261, no string instruments, no lens flare」（#F4A261、弦楽器なし、レンズフレアなし）の結果はそうではありませんでした。

検証ゲートにコーチ役を配置したことで、成果が大きく変わりました。コーチは制作の全工程を把握することはできましたが、介入できるのは各ステップの節目のみでした。この制約があるため、コーチはプロセスの細やかな管理はできず、完成した成果物の評価しかできませんでした。あるコーチはこの状況を、「超人的なスピードで特定の作業をこなせる専門家ばかりが集まっているのに、誰一人としてそのスープの味見ができない状態」と表現しました。

詳細

ドキュメンタリーの全編はこちらでご覧いただけます。Scion Framework の詳細と、ハッカソンでの使用方法についてもぜひご覧ください。

- プロダクト マネージャー、Preston Holmes

- テクニカル ソリューション マネージャー、Hussain Chinoy