ジャストインタイム型エージェント

Oakley Reid（AI/ML担当シニアプロダクトマネージャー）、Sumedh Bhattacharya（エージェント型AI担当ディレクター）

製造業における「ジャストインタイム」とは、部品を工場の現場に在庫として抱えておくのではなく、必要なときに必要な分だけ引き取ることで、組立ライン全体をより無駄なく稼働させる考え方です。Ask Albertも、これと同じ思想に基づいて構築しています。その結果、Ask Albertを支えるエージェントは、バージョンを重ねるごとに機能が充実する一方で、より高速かつ低コストになりました。本記事では、私たちのエージェントハーネスのアーキテクチャが生まれた背景と、現在の設計が研究開発の現場に何をもたらすのかをご紹介します。

Ask Albert開発の軌跡は以下の通りです。

Ask Albert v1：ベクトルデータベース上で、固定のセマンティック検索ワークフローを実行する構成です。探索には優れていましたが、利用できる場面はごく一部に限られていました。

Ask Albert v2：スーパーバイザーエージェントが、13種類の専門サブエージェントから必要なものを呼び出して作業を任せ、ワークフローを動的に組み立てる構成です。各サブエージェントの指示とツールは固定されており、変更できませんでした。このパターンは一般に「オーケストレーターループ」または「スーパーバイザーループ」と呼ばれます。これにより幅広い新たな活用が可能になり、Ask Albertは検索ツールから、アクションを実行できるアシスタントへと進化しました。

Ask Albert v3：単一のエージェントが、ワークフロー全体を自ら処理します。必要に応じて、目の前のタスクに合わせてその場でカスタマイズしたサブエージェントを生成します。作業の委任は引き続き行いますが、それは必要な場合に限られ、生成されるサブエージェントは事前定義されたものではなく動的なものです。v2でできたことをすべてカバーしたうえで、スキル、コネクタ、コード実行、ファイル解析などの機能を新たに加え、そのすべてをより速く、より低コストで実行します。

v1からv2、そしてv3への変遷は、柔軟性とユースケースの対応範囲を着実に広げてきた歩みです。目的を達成する方法をエージェント自身が決められる裁量が大きいほど、そしてより多くのリソースを提供するほど、より複雑なワークフローに対応できるようになります。v2では、エージェントに新たな多くのリソースを与えました。それが、独自ツールとドメイン知識を備えた13種類の専門サブエージェントです。しかし、これらのリソースはあらかじめパッケージ化されていました。エージェントは呼び出すサブエージェントを選ぶことはできても、その機能を変更することはできなかったのです。v3では、このパッケージ化を廃止しました。エージェントはタスクが必要とするツールと指示だけを動的に組み合わせ、作業上必要な場合に限り、その組み合わせを中心に構築したサブエージェントを生成します。

これが、私たちの言う「ジャストインタイム型エージェント」です。プロンプトにあらかじめ詰め込んでおくものは何もありません。ツール、ドメイン知識、補助機能はすべて、タスクが必要とした時点で初めて読み込まれます。その効果は明確です。v2と比較して、Ask Albert v3は、難易度の高いタスクでの精度は6%向上、プロンプトトークンの使用量は43%削減、処理速度は39%向上、1ケースあたりのコストは75%削減を実現しました。精度の向上、機能の拡充、レイテンシの低減、コストの削減を同じリリースで同時に実現することは、AI製品開発では稀です。一般的には、これらのうち多くて2つしか達成することができません。本記事の後半では、この4つすべてをどのように実現したのかをご紹介します。

Ask Albert v1：出発点

Ask Albert v1が得意としていたのは、1つのことでした。処方、原料、添付ファイル、Notebook、およびそれらに関連するコンテンツを対象としたセマンティック検索です。

これは、「この樹脂に類似した水性バインダーを探して」といった自由度の高い探索には有効でした。一方で、「プロジェクト1234で自分に割り当てられている未完了のタスクをすべて表示して」や「先週完了したタスクは何か」といった、正確で業務に即した質問には十分に対応できませんでした。これらはフィルターを使った厳密な検索であり、科学者がAlbert OSで日々行っている操作そのものです。こうした用途には、セマンティック検索だけでは適していません。

v1には構造的な限界もありました。新しい機能を追加するたびに、専用のツールを新たに構築し、その使い方を定めたワークフローをAsk Albertに追加する必要があったのです。そのため、既存の限られた検索経路以外の機能を追加するのは難しく、時間もかかりました。さらに、新しいワークフローが増えるたびに、Ask Albertがどのワークフローを使うべきかを判断する精度が低下するおそれもありました。

v1の内部の仕組み： 固定のパイプラインが質問を分解し、ベクトル検索を並列で実行し、結果をランク付けしたうえで、出典付きの回答を作成していました。

Ask Albert v2：得られた教訓

Ask Albert v2では、v1の固定パイプラインをエージェント型ループに置き換えました。スーパーバイザーエージェントがユーザーの質問を読み取り、私たちが構築した13種類のドメイン別サブエージェント（プロジェクト、原料・在庫、タスク、Notebook、Worksheet、検索、Breakthroughなど）から1つ以上を呼び出し、最終的な回答をまとめます。各サブエージェントは、専門的なドメイン指示と独自のツールセットを備えていましたが、どちらも実行時に変更することはできませんでした。スーパーバイザーはメニューから選ぶことはできても、メニューそのものを書き換えることはできなかったのです。

これにより、Ask Albert v2はv1の固定ワークフローに頼るのではなく、質問に答えるためのワークフローを自ら組み立てられるようになりました。v1では処方検索、原料検索、Notebook検索、ドキュメント検索の4つの経路しかありませんでしたが、v2では13種類のサブエージェントを使い、ユーザーに代わってさまざまなツールの組み合わせを構成できるようになりました。v1よりもはるかに優れた性能を発揮し、対応できるユースケースの数も大幅に拡大しました。

とりわけ2つの点で、程度の差にとどまらない質的な変化がありました。第一に、Ask Albertは構造化検索とセマンティック検索を同じ回答の中で組み合わせられるようになりました。たとえば、対象のプロジェクトに絞り込んだうえで、その中を検索するといったことです。第二に、さらに重要な点として、アクションを実行できるようになりました。v2は、Albert OSでユーザーが持つ権限と同じ範囲で、ユーザーに代わってタスクの作成、原料・在庫情報の更新、Worksheetの編集、目標値の設定を行えるようになったのです。この時点で、Ask Albertは単なる検索ボックスから、科学研究のアシスタントへと進化しました。

一方で、いくつかのトレードオフもありました。

コストと速度： スーパーバイザーとサブエージェントのプロンプトは膨大で、会話のターンごと、さらにスーパーバイザーからサブエージェントへの委任のたびに再送信する必要がありました。回答の精度は大幅に向上したものの、ユーザーに届くまでの時間がはるかに長くなり、コストも増加しました。

サブエージェントの分断： スーパーバイザーは、互いの作業内容を把握できないサブエージェントに作業を受け渡し続けていました。受け渡しのたびにコンテキストが失われ、複数のドメインにまたがる質問では、サブエージェントが部分的なコンテキストしか受け取れないことも少なくありませんでした。質問の内容に合った境界ではなく、事前に定めた境界に沿って作業を分割せざるを得なかったため、精度を犠牲にしていたのです。

サブエージェントのハルシネーション： サブエージェントが、別のサブエージェントのツール群にしか存在しないツールを呼び出そうとして、エラーや処理の失敗を引き起こすことがありました。

誤解のないようにお伝えすると、これらのトレードオフによってAsk Albertの性能がv1の水準を下回ったことは一度もありません。v2はv1をはるかに上回る性能を発揮していました。しかし私たちは、精度と性能にまだ取り戻せる余地があること、そしてその原因を把握していました。

Ask Albert v3：解決策

v3は、エージェント型ループを維持しながら、固定された階層構造を廃止しました。Ask Albert v3は、動的なツール探索（dynamic tool discovery）によってAlbert OS全体を横断して作業できる、単一のエージェントです。ここで、ジャストインタイムの考え方が本領を発揮します。v2は「作り置き型」でした。タスクが必要とするかどうかにかかわらず、すべてのサブエージェントが呼び出しのたびに全ツールセットと全指示を抱えていました。v3は「プル型」です。エージェントは各ターンを軽量なプロンプトで開始し、作業を進める中で必要と判明したツール、ドメイン知識、補助機能を取得します。

1つのエージェントが、何も設定されていない「シェル」のサブエージェントをいくつか手元に持っている状況を想像してみてください。ある作業に専用のサブエージェントが必要だと判断すると、エージェントはそのシェルに、その作業に特化したコンテキスト、指示、ツールへのアクセス権を与えます。v2では、スーパーバイザーは事前定義された13種類のサブエージェントの中から最も近いものを選ぶ必要がありました。v3では、Ask Albertが目の前のタスクに合わせて、本当に必要なサブエージェントを自ら作成します。サブエージェントは固定されたものではなく、動的なものになったのです。

また、この単一のエージェントは、全体としてサブエージェントに頼る頻度も大幅に減っています。v2では13種類のサブエージェントの中に閉じ込められていたドメインの専門知識を自ら取得し、そのコンテキストを直接活用できるようになったため、別のエージェントに作業を任せる必要が少なくなったのです。これにより、性能の問題とサブエージェントの分断の問題を一挙に解決しました。エージェントは必要なドメインコンテキストを必要なタイミングですべて把握でき、不要なものには一切コストをかけません。

このアーキテクチャの再構築によって、ツールキットを再び拡張する余地も生まれました。新しい機能は新たなサブエージェントを必要とせず、同じジャストインタイムの基本要素（プリミティブ）に組み込めるため、v3はv2よりもはるかに幅広いツールを搭載してリリースされました。具体的には、一般的な科学ワークフロー向けの再利用可能なスキル、パートナー企業がAlbert OSとすでに併用しているシステムとModel Context Protocol（MCP）で連携するコネクタ、データ分析と可視化のためのコード実行、スプレッドシートやドキュメント、分析機器のエクスポートデータを読み込むファイル解析などです。いずれもタスクが必要としたときにだけプロンプトに読み込まれるため、エージェントは重くなることなく、大幅に機能を強化できました。

家事代行ロボットにたとえると

Ask Albertに家の掃除を任せる場面を想像してみてください。

Ask Albert v1は、それぞれ1つの作業だけを行うようにプログラムされた4台のロボットの集まりでした。（1）皿洗い、（2）カトラリー洗い、（3）調理器具洗い、（4）乾燥です。

Ask Albert v2は、より賢い13台のプログラム済みロボットをクローゼットに備えた作業員でした。そのうち1台は「食洗機を回す」ロボットで、v1ができたことをすべてこなせました。残りの12台は「リビングの掃除」や「床掃除」といった、より大きな作業を担当していました。作業員はどのロボットを送り出すかを選べましたが、ロボットのプログラムを書き換えることはできませんでした。そのため、「リビングの掃除」と「床掃除」が同時に稼働すると、互いに連携できず、リビングの床のように担当範囲が重なる場所でぶつかってしまうこともありました。

Ask Albert v3は、その場でロボットを組み立て、プログラムできる作業員です。家の中を見て回り、何をすべきかを見極め、役に立つ場合には13台のロボットの元のプログラムも参考にします。そのうえで、「リビングの床を掃除する」という、目の前の作業にぴったり合った新しいロボットをプログラムします。そして多くの場合、作業員は自分でその作業をこなしてしまいます。

ジャストインタイム型エージェントの優れた特性は、新しい機能をほぼコストをかけずに追加できることです。ドメインを追加する際に必要なのは、バンドルといくつかのSDKメソッドをカタログに加えることだけで、新しいサブエージェントや新しいプロンプト、新たな受け渡しの工程は必要ありません。私たちはすでに、これと同じ基本要素を活用して、Ask Albertを設計・実行・分析のサイクルのより多くの領域へと拡張しています。実際の動作をご覧になりたい方は、ぜひデモをお申し込みください。

‍