私たちがデザインエージェントをどのように構築したか

主なポイント

味わいは文脈から生まれる。モデルはすでに優れたコードを生成できるが、あなたのデザインの原則や、AIによる乱雑な出力に対するガードレール、そしてフィードバックの背後にある理由付けがなければ、あなたらしい仕上がりにはならない。

エージェントにデザイナー用のコンピューターを提供しましょう。Slack の各スレッドには独自のサンドボックスが用意され、エージェントはターンごとにプロジェクトを保持し、ビデオエンジンや画像ツール、共有キャンバスを横断して作業を行い、自身のレンダリングを検査します。

モデルが改善するにつれてルールを削除します。モデルの弱点を補うためのルールは期限切れになるため、設計原則を維持し、モデルが向上するにつれて回避策を除去してください。

長時間実行されるエージェントには、マルチプレイヤー型のUXが必要です。大規模なタスクは非同期サブエージェントで数時間にわたって実行されるため、Slackのスレッドでは計画やリアルタイムの進捗、そして本番リリース前の承認が表示され、チーム内の誰でも実行中にエージェントを調整できます。

フォークできます。オープンソースのリポジトリにはフルハーネスが含まれており、Managed Deep Agents はそれをチームの Slack にデプロイします。

上記のプロモーションは、Slack の単一のプロンプトだけで動画やソーシャルグラフィック、再構築された UI イメージ、スライドデッキなどを生成できる当社のデザインエージェントである Content Studio によって作成されました。このエージェントが生成するすべてのアセットはコードで記述されています。

Content Studioは、Managed Deep Agents上で社内開発により完全に構築されました。現在では当社内で最も広く活用されているGTMエージェントの一つとなっていますが、当初はそうではありませんでした。初期のフィードバックは……あまり芳しくありませんでした。

では、どうしてこれほど低品質からここまで進化したのでしょうか？

私たちは4か月にわたり、Content Studioに自社のセンスとデザイン原則を教え込んできました。そのほとんどは、全社員の前で同ツールが誤った判断を下す様子を見守ることによって行われました。

この記事では、当社のGTMエンジニアリングチームがデザインチームと協力してContent Studioをゼロから構築する過程を紹介します。具体的には、私たちにとって優れたデザインとは何か、どのようにエージェントに自社のセンスを学習させたか、そして静止画からローンチ映像まであらゆるコンテンツを生成できる仕組みについて説明します。

当社は自社のデザインエージェントをオープンソース化しました。オープンソースリポジトリをフォークし、ブランドのトークンやフォント、スキルを追加したうえで、Managed Deep Agentsを用いてチームのSlackにデプロイしてください。その後、10月28日に開催されるGTM Engineering Liveにぜひご参加ください。本イベントでは、ハーネスとUXの内部構造を詳しく解説し、今回の記事には収まりきらなかった取り組みもご紹介します。

スケールに適したデザインエージェントの構築

LangChainは迅速に進化しています。私たちは常に製品のローンチキャンペーン、ウェビナー、ブログ記事、イベントを展開しており、それぞれの取り組みには、ブログのヘッダー画像や図解からプレゼン資料、動画、広告クリエイティブに至るまで、多様なアセットが必要です。デザインチームは人員が逼迫しており、繰り返しの依頼に追われて、戦略的で革新的な業務が十分に進められない状況でした。スリムなスタートアップとして、社内の誰もが高品質でブランドイメージに沿った成果物を低摩擦で作れる仕組みが求められていました。

これらのニーズに対応するため、Slack 内に常駐するデザインエージェントである Content Studio を構築しました。チームメンバーは自分の要望を伝え、関連するコンテンツやブリーフを添付すると、エージェントがブランドに沿った完成済みのファイルを返してくれます。Content Studio の構築には、次の3つの要素が必要でした：

当社のデザイナーによる専門的な判断が、エージェントのスキルとチェック項目に組み込まれており、良好な状態がどのようなものかをエージェントが理解できるようになっています。

モデルを取り巻くカスタム環境には、デザイン作業の各層に対応したツールを備えたビデオ編集用パソコンも含まれます。

適切なUXにより、チーム全員が1つのSlackスレッドから数時間にわたるプロジェクトで協働できます。

Managed Deep Agentsは、当社内でContent Studioを本番環境に導入するために必要なすべてを提供してくれました。管理型のLangSmith Sandbox、Slackとの統合、管理型ツール、スコープ付きのエージェントメモリ、そしてエージェント実行のスケジューリングです。これにより、小さなチームは、インフラ構築の手間ではなく、設計作業やスキル、ツール、Slackでの体験に時間を割くことができます。

主な結果

Content Studioは、社内全体で3,000を超えるアセットを提供しており、その中には80を超えるスライドデッキも含まれています。そのうちの1つのデッキは、当社で最も視聴回数の多いオーガニックYouTube動画でも使用されました。

その作品を投稿した記事は、Xで約450万回の閲覧数を獲得しました。

LangChainアカウントでは、ビジュアルを用いた投稿は、他の投稿に比べていいね数が約2倍、ブックマーク数が3.7倍となっています。

現在、4件に3件のリクエストはマーケティング部門外から寄せられており、利用者の75％が毎週戻ってくるリピーターです。

現在、中央値のリクエストにかかるモデル費用は約50セントで、9月中旬の約8ドルから低下しています。マネージド・ディープエージェントへの移行後、当社独自のコードサイズは約80％削減されました。

AIは本当にデザインが得意なのか？

ビルドに取り掛かる前に、まずは世紀の論争に答えましょう：AIは本当に優れたデザインを生み出せるのでしょうか？

このモデルはもともと実行力に優れており、HTMLやCSSの記述、仕様書の作成、アニメーションのタイムラインの生成なども行えました。しかし、私たちの文脈を理解していなかったため、慣れ親しんだパターンに頼ってしまい、アンソロピックが「分布的収束」と呼ぶ状態に陥りました。その結果、見た目は洗練されていても、他の何百もの例と変わらないように見えたり、美しくアニメーション化されていても肝心なメッセージが伝わらなかったりするのです。慣れているからといって必ずしも悪いわけではありませんが、私たちはエージェントに、自らの目的に沿った選択を行わせたいと考えていました。

Stripeのデザイン部門責任者であるケイティ・ディルは、有益な比較を示しています。第二次世界大戦後、迅速な開発が求められるなかで、建築家たちはモダニズムの洗練された形状と無駄のない表面を何度も模倣してきました。しかし、その模倣は見た目だけを再現する一方で、背後にある思想や個性を失わせてしまっています。彼女の警告は、AIがソフトウェアに対しても同様のことをしてしまう可能性があるというものです。彼女はこれを「ゾンビUI」と呼び、「あなた自身の視点を持たなければ、AIがそれを代わりに与えてしまう」と述べています。

私たちは、AIがデザインを苦手だとは考えていません。AIには、あなたが与えない限り視点がなく、私たちの視点を与えることは、すなわち私たちの好みを教え込むことでもあります。

デザインエージェントに味覚を学習させる

味覚とは、正しい仕事と優れた仕事を区別する判断力である。デザインにおいては、二つのレイアウトが適切なフォント、色、余白を用いていても、そのうち一方だけが目的を的確に伝えられることがある。味覚とは、ディルが「気づきを極める」ことから生まれるのだ。

その気づきこそが、私たちがAIのデタラメを見抜く方法であり、それは多くの場合、簡潔な指示文がエージェントに判断を委ねる際に現れます。

例えば、下の左側の画像は、当社のブランドスキル（色、フォント、ロゴなどを含む）を用いてローカルなコーディングエージェントが作成したものですが、最終的な仕上がりには、正しいロゴの組み合わせやテキストの配置、さらに当社のプライマリカラーとセカンダリーカラーの区別といった重要な要素が欠けていました。

同じプロンプトが、Content Studioでまさにブランドイメージにぴったりの画像を生成しました。これは、ローカルエージェントがブリーフでカバーされていなかった各判断を、最もよく見かけた事例に基づいて埋めたためです。この手法により、Content Studioも同様のギャップを当社の選択肢で埋めました。

私たちがContent Studioに提示したガイドラインは、カラートークン、フォントの太さ、間隔、配置といった基本事項から始まりました。しかし、大幅な改善は、その上に加えた要素によるところが大きかったです。私たちは、各フレームに一つの焦点を置くことや、よく見られるAIデザインパターンに対するガードレール、さらには各フィードバックの背後にある理由といった設計原則を導入しました。これらと、より優れた基盤モデルを組み合わせることで、Content Studioはデザイナーのように考え、コミュニケーションを取る能力を一段と高めることができました。

当初はそうではありませんでした。初期のモーショングラフィックスのひとつでは、鳥が画面外へ飛び去り、その背後にはわずか1秒にも満たない光のリボンが残ります。鋭いエッジは不要と伝えましたが、最初のバッチは不格好で、角が丸く柔らかい仕上がりでした。デザイナーなら私たちの意図を理解できたでしょう。エッジはやわらかくし、尾部は鳥の進行方向とは逆側へと細くなりながら徐々に消えていくべきでした。

後のバージョンでは、エージェントはその細部をデザイナーの視点で評価するようになっていました。鳥の尾羽の位置を特定するために手早くスケッチを用い、リボンがしっかりと付いたままになっていることを確認するためのフレームごとのチェックを自ら構築しました。ほとんどの視聴者はその細部を意識的には気づかないかもしれませんが、何かが違っていると感覚的に感じ取るでしょう。

測定可能な問題は最も解決しやすかった。以前はレビューでデフォルトの大文字化が頻繁に指摘されていたが、現在では自動チェックによりすべての事例が捕捉されるようになった。一方、より難しい判断は主観的な要素が強く、たとえばキャンペーンのアイデアが十分に強力か、メッセージが明確に伝わるか、あるいは実行がターゲット層に響くかといった点である。デザイナーがそうした判断を下す際には、その理由をスキルとして記録し、エージェントが今後の案作成に活用できるようにしている。

Content Studioは、デザイン業務を誰が行えるかを変更しました。PMやエンジニア、あるいは創業者がSlackでエージェントに指示を出し、ブランドに沿った完成度の高い成果物を手にしてプロジェクトを終了できるようになりました。現在では、依頼の4分の3がマーケティング部門外から寄せられています。デザイナーにとっても、その役割は自らすべてのアセットを制作するのではなく、方向性を定め、仕上がりをレビューするという、クリエイティブディレクターに近いものへと移行しています。

設計上の判断を正しく下すことは、プロセスの一環にすぎません。また、エージェントがその判断を実行できるよう、必要なツールと環境も整える必要がありました。

メディアハーネスの構築

デザイナーは、静止画用のPhotoshopやモーション用のビデオエンジンから、プロトタイプ作成とコラボレーションのための共有キャンバスに至るまで、複数のツールを横断して活用します。また、ブランドガイドライン、デザインアセット、社内ドキュメントにも依存しています。

エージェントにも、作業に使用するコンピューター、設計プロセスの各段階に対応したツール、そしてデザイナーが業務に持ち込む文脈といった、同様の環境整備が必要です。ハーネスはこれらの要素を一元的に統合します。Deep Agents は、エージェントループ、計画機能、ファイル管理、サブエージェント、文脈管理などを含む基盤となるハーネスを提供します。Managed Deep Agents は、これをパッケージ化し、本番環境で実行します。私たちはその周囲に適切な環境を構築し、エージェントがプロジェクトを維持し、複数のツール間で作業を行い、結果を確認できるよう、専用のコンピューターを用意しました。

harness_v1

当社のそのハーネスの最初のバージョンは、モデルのデザインを代行しようとしていました。初期のモデルでは、納品したいモーショングラフィックやローンチ映像を作るのに多くの支援が必要でした。彼ら自身でまだ見いだせない部分を補うため、当社の直感としては、指示やコードに自社のデザイン判断をより多く組み込むことでした。

そこで、タイトル、レイアウト、アニメーションに関する115の再利用可能なUIコンポーネントに加え、それらの使用タイミングと方法を示すガイドラインを備えたデザインシステムを構築しました。これにより、モデルは既存のデザインを基盤として活用できるようになり、ゼロから創造的な判断を下す必要性が大幅に軽減されました。

それによりブランドの一貫性が保たれましたが、エージェントは各フレームでほとんど変化を加えずに、同じレイアウトとアニメーションを繰り返すだけでした。

私たちは、いずれこれらのモデルがこのタスクにおいて優れた性能を発揮することを予見していたため、その瞬間のために環境の構築を継続し、その過程でスキルやツールについても試行錯誤を重ねてきました。時には、モデルの理解を助けるために参照情報や詳細な指示を追加することもありました。また、逆にそれらを完全に削除して、モデルが自力でどこまでできるかを確認することもありました。

しかし、結果は依然として私たちの望む水準には達しておらず、その差を埋めるためにはますます多くのエンジニアリング作業が必要でした。私たちはスキルにルールを追加し、さらに多くのモーションコードを書き、モデルが対応できない部分を補うためにより多くのコンポーネントを構築し続けました。

その後、Opus 5.5が登場し、品質が一気に向上しました。私たちは再びスキルを見直し、ハードコーディングされたルールの大部分を削除して、設計原則と高レベルな指針は維持しました。その結果、バリエーションが増え、繰り返しが減少するなど、さらに改善が見られました。ついに、これまで事前に組み込もうとしていた創造的な判断を、モデル自身が下すようになっていました。

これが私たちの「苦い教訓」でした。モデルの弱点を補うために設計されたルールは、モデルが進化するにつれてその有用性を失っていきます。長く残るのは、モデルを取り巻く環境であり、使用するツールや参照する文脈、さらには人々がその働きをどのように導くかといった要素です。私たちは、あらかじめ創造的な判断を組み込むのではなく、各世代のモデルの進化を活かせるよう、フレームワークを十分に柔軟にすることに注力しました。

デザイナーのコンピューター

ハーネスの実際の動作を示すため、Content Studio に依頼して、ビデオプロジェクトをエンドツーエンドでどのように運用するかを紹介する映像を作成しました。その結果は、ピクセルのジャングルにいるインコが登場し、デイヴィッド・アッテンボロー風のナレーション（ElevenLabsによる音声合成）で語られる作品です。この映像を使って、ハーネスの各層――コンピュータ、ツール、そしてその仕組みの背景――を順に解説していきましょう。

デザインは反復的です。何かを作り、それを確認して修正を加え、しばしば何度も繰り返します。そのため、エージェントには会話全体にわたって作業を続けられるコンピューターが必要です。各Slackスレッドには独自のLangSmith Sandboxが用意され、ファイルシステムとシェルを備えた隔離されたLinuxマシンとして機能し、プロジェクトはそのスレッドの存続期間中、そこに置かれます。

エージェントが作成するものはすべてコードで構築されており、スライド用のHTMLページであれ、グラフ用のデータ仕様書であれ、動画用のアニメーションタイムラインであれ、同じです。これにより、最初からやり直すことなく簡単に反復作業が行えます。もし誰かがオウムをもっと早く登場させたいと要望した場合でも、エージェントはタイミングの値を一つ変更するだけで再レンダリングでき、アートワークやテキストには影響を与えません。一方、静止画や生成されたビデオクリップの場合、わずかな編集ですらアセット全体を再作成しなければならないことがあります。

短編、プラン、シーンコード、オーディオ、レンダリングはすべて、作業に携わる各サブエージェントが共同で作業する1つのプロジェクトフォルダー内にリアルタイムで保存されます。

さらに、私たちはデザイナーが作業の各層で必要とするツールを導入しました：

モーションは最も難しいレイヤーです。それは2つのエンジンで動作します：

編集用のHyperFrames：HeyGenのオープンソース動画フレームワークであるHyperFramesは、動画をウェブページに変換します。クリップ、画面録画、字幕、テキストなどはすべてそのページ上の要素であり、GSAPのタイムラインによってそれらを自在に配置・移動できます。そのため、ウェビナーに字幕を付ける依頼や製品デモのカット編集を行う際、エージェントはまるでウェブページを編集するかのように作業を行います。そのCLIはまさにエージェントの編集スイートであり、構成をチェックし、フレームを抽出して確認し、カットをレンダリングするといった操作が可能です。さらに、HeyGen公式のスキルも導入することで、エージェントはそれを開発したチームから直接フォーマットを学ぶことができます。

アニメーション用のmotion-studio：ウェブページでは、高速な動きをぼかしたり、物体に光を当てたり、ロゴを3Dに変形させたりすることはできませんが、それこそが私たちがオリジナルのアニメーションに求めていた仕上がりでした。そこで、独自のキャンバスエンジンを構築しました。エージェントは各フレームのすべてのピクセルを描画するコードを生成し、エンジンはカメラのシャッターが動きをぼかすのと同じ原理で、1フレームに最大16コマの動きを合成します。オウムの映像は、この方法で制作されました。

両方のエンジンは、各フレームをタイムスタンプに基づいてレンダリングするため、10秒目のフレームは、いつレンダリングされても同じ見た目になります。これにより、エージェントは映画全体をレンダリングすることなく個々の瞬間を確認できるほか、複数のフレームを並列にレンダリングすることも可能です。オーディオも同じタイムライン上で動作し、ナレーション、音楽、効果音を映像と同期させることができます。

この設定では、エージェントはほぼあらゆるものを生成できます。しかし、追加の指示がなければ、私たちの意図ではなくモデル自身の設計方針に従うことになります。次の課題は、当社のブランドおよびデザイン基準に沿って動作するよう学習させることでした。

デザイナーの脳

エージェントの知識を、それぞれ明確な目的を持つ四つの異なる機能に整理しました。スキルは特定のタスクの実行方法を示し、Wikiは当社に関する背景情報や優れた成果のあり方を提供します。測定可能な項目はすべて、コードで記述された決定論的なチェックであるゲートによって処理されます。また、別途設けたメモリ層には、人々が時間の経過とともにエージェントに教え込んだ内容を蓄積します。

エージェントがリクエストを受け取って最初に行うのは、その依頼がどのような業務なのかを判断することです。この処理は当社のメディア制作スキルが担っています。これをルーター・スキルと呼ぶのは、その大部分が1つのテーブルで構成されているためです。各行は、ある種類の依頼（キャンペーン、リスタイル、サムネイル、投稿、YouTubeパッケージ、ローンチ映像、短編アニメーションなど）を、それを処理するパスおよび専門スキルにマッピングしています。また、ルーターはその業務に共有のビジュアルキャンバスが必要かどうかを判断し、小さな修正はフルプロセスから除外します。

上記のような映画の場合、ルーターは大規模なモーション制作の演出に特化した「launch-film」スキルを選択します。当社の48種類のスキルは、全体で約1,000ファイルに及びますが、いずれもテーマではなくタスクに応じて定義されているため、その説明文は、使用すべきでない場合も含めて、まるでルーティング規則のように記されています。

スキルは互いに繰り返すのではなく、組み合わせて構成されます。launch-film が演出を担当し、motion-studio が映像と音声を制作するため、アニメーション制作のプロセスは一度だけ記述すれば済みます。また、launch-film には、開始するサブエージェント向けの役割説明書や、実際に撮影した88秒のローンチ映画をコードで一コマずつ再構築した事例も含まれています。この事例を通じて、エージェントは映画を複数のサブエージェントに分割する方法を学びました。具体的には、場面転換が激しい箇所では適切に分割し、あるサブエージェントだけでカメラの連続した動きを維持し、誰かが並列作業に入る前に共有コードを凍結します。

ツールにとっても、スキルと同様に説明文は重要です。コンテキストの使用を抑えるため、MCP ツールは組み込みの検索機能の背後に配置しています。エージェントは最初に自社製のツールのみを搭載し、必要に応じてツール名や説明文を対象としたキーワード検索を通じて追加のツールスキーマをロードします。

スキルは作業のやり方を説明し、Wikiはそれをうまくこなすために必要な文脈や参考資料を提供します。ブランドトークン、グラフィック言語、声の特徴から、プラットフォーム、キャンペーン、製品情報に至るまで、あらゆる要素を網羅しています。さらに、専用のモーションWikiでは、演出、技術、音響、レビューに関する情報を扱うほか、70本の参考映画の詳細分析も掲載されています。

この情報を各スキルに重複して記載するのではなく、ウィキに直接リンクします。これにより、共有される知識を一箇所にまとめ、更新作業を容易にできます。フォントに関するルールのようなものが変更された場合でも、一度だけ更新すればよく、すべてのスキルが最新版を参照できるようになります。

私たちの作業プロセスを理解したからといって、モーションデザインが必ずしも安くなるわけではありません。誤ったクリエイティブな判断は、依然として何時間ものレンダリングコストを招く可能性があります。

仕様主導の設計

モーションは、レンダリング時間とトークンの両面で、誤りが生じると特にコストがかかります。ストーリーボードの1フレームをレンダリングするのに約50ミリ秒かかるのに対し、完成した映像の1秒を生成するには8〜40秒かかります。サブエージェントが各アクションを執筆・レンダリング・レビューするため、これらのコストはすぐに膨らんでしまいます。そのため、エージェントはまずストーリーボード上でアイデアを練り、安価にさまざまな方向性を検討したうえで、方針が承認されてから本格的な制作へと移行します。

その探求を支援するため、私たちはエージェントに参考映像のライブラリを与え、まるでデザイナーがムードボードを基に作業するかのように、そこからインスピレーションを得られるようにしました。適切なビジュアルが見つからない場合、画像モデルを用いて新たな参照素材を生成し、まず手早く下書きを作成した後、最も有望な候補を洗練させていきます。これらの画像はビジュアルの方向性を定めるのに役立ちますが、ストーリーボードや最終的な映像は依然として、実際のタイポグラフィーやブランド資産を用いてコード上で構築されます。

一度方向性が決まれば、承認された絵コンテが、映画の残りの部分が基づく仕様書となります。その後、プロジェクトは三つの段階を経て進行します：

ビジュアルの構想、コピー、カットを合意するためのストーリーボード。

アニメティック、つまり音声に合わせた粗編集版で、静止画では分からないテンポを確認します。

プロダクションでは、サブエージェントが承認済みのショットを構築し、確認し、レンダリングします。

この順序は当初、スキルの指示書で説明されており、エージェントは時間を節約するためにレビューを省略することもありました。現在では、パイプラインがコードでこれを強制しているため、アセンブリはすべてのアクションがレビューに合格するまで待機し、一方で指示書は依然としてクリエイティブな呼び出しをガイドしています。常に守られるべき順序はコードの中にあり、判断はプロンプトに留められています。

ポイント、プロンプトは不要

それらの方向性の中から選ぶのはチームの判断です。Slackは作業の依頼や承諾には適していますが、スレッドは線形なテキストであり、ストーリーボードは空間的なため、フィードバックは対象を指し示すのではなく、その位置を説明するものになってしまいます。また、たとえ一語の修正であっても、変更は新たなプロンプトとしてエージェント経由でやり取りしなければなりません。

Paperはこれを解決してくれました。これはエージェントを想定して設計されたデザインキャンバスで、MCPサーバーがエージェントにファイルへの直接的な制御権を与えます。ユーザーは同じファイル上で作業を行い、各方向の案を横並びで比較したり、特定のフレームにコメントを残したり、自ら編集を行ったりできます。キャンバスが共有されているため、エージェントは後からそのファイルに戻り、これらのコメントや編集内容を参考にして次の反復を進めることができます。

課題は、Paperのエージェントツールがデスクトップアプリ内でのみ動作するのに対し、当社のエージェントはクラウド上のサンドボックスで動作することでした。このギャップを埋めるため、常時稼働するLinuxベースのワーカー上でPaper Desktopをヘッドレスで実行し、仮想ディスプレイと認証済みブリッジを用いて両者を接続しています。ひとつの設定でチーム全体をサポートします。

承認後であっても、絵コンテを完成した映画に仕上げるには数時間かかることがあります。その段階になると、作業は小さなプロジェクトのようなものになり、同時に進行する複数の要素がひとつにまとまる必要があります。これらすべてを調整するのは、単独のエージェントのターンだけでは到底対応しきれません。

スタッフ長としてのエージェント

先ほどのオウムの映画を考えてみてください。Slack上で制作の途中段階にあります。ある人がリファレンスを共有し、別の人が異なるオープニングを提案し、さらに別の人がフレーム4についてフィードバックを残します。その間も、エージェントはまだ制作を進めています。まるで、メモを取る人が映画の制作にも責任を持つようなブレインストーミングのようです。同期型サブエージェントではうまく機能しません。なぜなら、メインエージェントは彼らが作業を終えるのを待たなければならないため、その間に他の人々がそれに参加する手段がなくなるからです。

これを解決するために、サブエージェントを非同期化し、メインエージェントの役割を実行者からチーフ・オブ・スタッフへと変更しました。これにより、複雑なプロジェクトをより小さく分離されたタスクに分割し、それらをサブエージェントに割り当てて並列に処理します。同時に、状況が変化するたびにチームに情報を共有し、人々が引き続きフィードバックを提供してプロジェクトを方向付けることができるようになります。

各タスクについて、メインエージェントは、その役割、関連する文脈、ファイルの所有権、および作業の検証方法を明確に示した簡潔な概要を含むサブエージェントプロファイルを作成します。また、タスクの複雑さに基づいて、使用するモデルと作業負荷のレベルを選択します。

また、メインエージェントが作業を調整するための小型のツールセットも追加しました：

start_task は、バックグラウンドでサブエージェントに部品を渡します

check_tasksは、実行中のタスクを表示し、完了したレポートを読み取ります

cancel_task および resume_task は、もはや要件に合致しなくなった作業を中止し、または中断した箇所から再開します

report_progressを使用すると、サブエージェントはジョブの実行中に更新情報を送信できます

schedule_wakeup は、メインエージェントに別の実行をトリガーし、ジョブを継続するためのタイマーを設定します

内部では、各サブエージェントは通常のDeep Agentsタスクツールとしてバックグラウンドタスクとして実行されています。処理が完了すると、当社のコードは結果を含むメインエージェントの新たな実行をキューに登録します。また、作業中に到着したメッセージは次のモデル呼び出しの前に挿入されるため、ユーザーは実行中のメインエージェントを途中で制御することも可能です。サブエージェント間の連携はプロジェクトフォルダーを通じて行われ、各エージェントは自身が所有するファイルのみを書き込み、進捗状況をディスク上に保持します。

バックグラウンドで作業が進行中であるため、スレッドには現在の状況を示す必要があります。メインエージェントは、計画と残り時間の推定（ETA）、実行中のサブエージェントやレンダリングの進捗・消費時間に関するリアルタイムステータスライン、各編集に対する確認応答、そして公開前に必要な承認カードを用いて、常に最新情報を維持します。

このアプローチの最も明確な検証の一つは、52枚のスライドからなるプレゼンテーションの外観を一新する一晩がかりの作業で得られました。エージェントはまず3枚のサンプルスライドを作成し、自身の成果を確認したうえで、残りのスライドを番号付きのバッチごとに進め、承認を得ました。その過程で新たに2枚のスライドも追加しました。一晩の間に、メインエージェントは約1時間稼働し、サブエージェントたちが合計6時間以上にわたり作業を続けましたが、いずれも会話の進行を妨げることはありませんでした。

自己改善型ハーネス

数か月にわたりチームと協働してきたデザイナーは、チームの好みを把握しており、同じフィードバックを二度聞かなくても済みます。記憶がなければ、エージェントは新しいスレッドごとに一から始めることになってしまいます。これを回避するため、私たちは二つの学習ループを構築しました。高速ループは、ユーザーがフィードバックを提供する際にそれを即座に取り込み、一方で低速ループは、バックグラウンドで完了したプロジェクトから学習します。

高速ループ：誰かがルールや好みを共有すると、エージェントはその情報を同じターンで保存します。Managed Deep Agentsは、メモリを2層のプレーンファイルとして格納し、1つはチーム全体で共有され、もう1つは各ユーザー固有のものです。

個人の好みはスレッド間で引き継がれますが、共有された標準が優先され、企業チャンネル用に作成された内容は企業の声色に従います。各レイヤーには、モデル呼び出しのたびに読み込まれる AGENTS.md ファイルがあります。初期バージョンでは50万トークンにまで膨らんでしまったため、現在はこれらのファイルを200行までのインデックスに制限しています。

スローループ：各ジョブの終了後、当社の learn_from_job ツールは軽量なサブエージェントを起動し、証拠に基づく教訓を最大5つ抽出して、使用したスキルと関連付けます。その後、今後のジョブでこれらの教訓が読み込まれて評価され、さらに週に一度、バックグラウンドエージェントが有用であると判断された教訓をスキルやウィキに反映します。

次は何ですか

あの初期のレビューを覚えていますか？最大の改善は、レビューのスレッドに散らばったままだったデザイナーの判断を、エージェントが学べる共有環境に集約したことにありました。その過程で、私たちはデザイン業務をより多くの人々が利用しやすいものにしました。

次に、エージェントにはキャンペーンのライフサイクル全体を管理してもらいたいと考えていますが、その一部はすでに機能しています。承認者が署名すると、Buffer を介して企業のソーシャル投稿を公開し、従業員が自身のアカウントから共有できる投稿を下書きし、さらに、引用に値する投稿を提案する毎日のレビューを含むスケジュール済みのルーチンを実行します。

私たちの目標は、これをさらに進化させることです。そうすることで、一度承認されたクリエイティブ方針が、ひとつのスレッドからキャンペーン全体を統括できるようになります。エージェントはブリーフを作成し、各チャネル向けの素材を制作し、投稿スケジュールを設定し、チームによる拡散を支援するとともに、パフォーマンスデータを次回のキャンペーン立案に活かします。なお、公開前にすべての内容を依然として人手でレビュー・承認する仕組みは維持されます。

独自のデザインエージェントを構築しましょう。オープンソースのリポジトリには、本記事で紹介したハーネスが含まれています。具体的には、サンドボックスコンピューター、スキル、Wikiとメモリ、非同期サブエージェント、そしてSlack向けのUXです。これをフォークし、自社のブランドトークンやフォント、スキルを追加して、Managed Deep Agentsを活用してチームのSlackにデプロイしてください。その後、10月28日に開催されるGTM Engineering Liveにぜひご参加ください。ハーネスとUXの内部構造を詳しく解説し、本記事では収まりきらなかった取り組みもお見せします。

情報源

LangChain

情報源

関連テーマ