AIエージェントに「道具箱」を持たせる時代へ

AIエージェントの話は以前からあった。ただ「エージェントが動く」と「エージェントが仕事をこなす」の間には、まだ大きな溝があった。その溝を埋めるピースが、短期間のうちに3つ同時に揃いつつある。

Googleが公開した「ax」は、複数のAIエージェントが互いに連携して動くためのオープンなランタイムだ。エージェント同士の呼び出し順序や状態の受け渡しを制御する「司令塔」の役割を担う。Go製で、GitHubでは7,300を超えるスターを集めている。

次に「univer」。スプレッドシート・ドキュメント・スライド・PDFといったオフィス系のファイル形式を、ひとつのランタイム環境でまとめて扱えるOSSだ。TypeScript製で15,000超のスター。「AIエージェントのためのオフィスハーネス」と銘打たれており、人間が使うというよりエージェントが操作する前提で設計されている点が興味深い。

そして「treg」。OpenRouterがAIモデルの呼び出し口を統一したように、tregはエージェントが使う「道具（ツール）」の呼び出しを統一しようとするライブラリだ。Python製で2,100超のスター。

この3つを並べると、「エージェントが複数協調し（ax）、オフィス系ファイルを操作し（univer）、必要な外部ツールを呼び出す（treg）」という構成が一気に見えてくる。個別に使えるし、組み合わせることもできる。

3つが似たような話に見えて、実際には担っている役割が違う。整理しておきたい。

axは「複数エージェントの調整役」だ。単体のAI呼び出しではなく、エージェントAがエージェントBに仕事を渡し、結果を受け取って次の判断をする、という流れを設計するためのもの。LangGraphやCrewAIのような既存フレームワークと近い領域だが、Googleが設計した点とGo製という点が差別化要素になる。サーバーサイドやバックエンド寄りの構成に向いている。

univerが狙っているのは「AIがExcelやスライドを直接触れる環境をつくる」ことだ。これまでAIにスプレッドシートを操作させようとすると、ファイルをテキストに変換してから渡す、という迂回が必要だった。univsrはその変換コストをなくし、エージェントがネイティブにオフィス形式のデータを読み書きできる環境を提供しようとしている。

tregの立場はやや異なる。コードを書いて独自ツールをつくるより先に、「既存のAPIやサービスをエージェントのツールとして登録・再利用する」ための共通レイヤーを目指している。OpenRouterがモデル選択を抽象化したように、ツール選択を抽象化するイメージだ。

コードなしでできることは今のところ限られる。ただ、tregのDiscordに入ってサンプルを眺めるだけでも、「エージェントにどんな道具を持たせるか」という設計の発想が身につく。それ自体が使う側の武器になる。

少し立ち止まって考えてみたい。なぜuniverの「AIエージェントのためのオフィスハーネス」という位置づけが重要なのか。

これまでのAI活用は、人間がファイルを用意してAIに渡し、結果を受け取って人間が判断・保存する、というサイクルが前提だった。ファイルの操作そのものは人間の仕事だった。

univerが実現しようとしているのは、その「ファイルを用意して渡す」部分をエージェント自身が担う構成だ。エージェントがスプレッドシートを開いて集計し、スライドに結果を書き込み、PDFに出力する、という一連の作業を人間の手を介さず回せる環境に近づく。

壊れないブラウザ自動化、AIが自己修復するで取り上げたブラウザ自動化の進化と合わせて見ると、「AIが使うインターフェース」の整備が着々と進んでいることがわかる。ブラウザ操作、ファイル操作、ツール呼び出し——それぞれのレイヤーで人間の仲介が不要になっていく方向に動いている。

使う側として意識しておきたいのは、「どこまでエージェントに委ねるか」の設計を自分で考えられることだ。ツールが揃っても、何を自動化してどこで人間が判断するか、というアーキテクチャの判断は依然として人間の仕事になる。