Centaur：チームで使う“マルチプレイヤーAIエージェント”のためのオープンソース基盤

「マルチプレイヤー型」AIエージェント

現在の多くのAIアシスタントは、1人のユーザーとAIの1対1の関係で設計されています。

Centaurでは、AIエージェントをチームの共有メンバーのような存在として扱います。

SlackのスレッドやAPIを通じて、エージェントは次のような処理を行います。

• ユーザーの指示を理解する
• 社内ツールや外部APIを呼び出す
• 複数ステップのワークフローを実行する
• 作業進捗をSlackに報告する

エージェントは共有されているため、同じスレッド内でチームメンバーが作業を確認したり、途中で指示を追加したりできます。こうした仕組みにより、エージェントは**“仮想チームメイト”のように機能する**と説明されています。

また、企業の内部サービスを**型付きツール（typed tools）**として公開することで、データベース、API、社内ダッシュボードなどに安全にアクセスさせることも可能です。

数時間〜数日動き続けるワークフロー

Centaurは、短い質問応答だけでなく長時間のタスク処理を前提に設計されています。

エージェントは次のような動作が可能です。

• 数時間〜数日間のワークフロー実行
• システム再起動後の処理再開
• 複数ツールを組み合わせた段階的処理

この仕組みにより、継続的な監視や段階的な分析など、時間のかかる業務プロセスを自動化できます。

PostgreSQLによる状態管理

Centaurでは、エージェントの状態やイベント履歴をPostgreSQLデータベースに保存します。

記録される主な情報は次の通りです。

• ユーザーのリクエスト
• 実行環境の割り当て
• 実行イベントやストリーム出力
• 最終結果や終了状態

これらの情報が永続化されることで、システム再起動後も処理を再開でき、エージェントの行動履歴を追跡することもできます。

資格情報（APIキーなど）の安全な扱い

AIエージェントが実務を行う場合、APIキーなどの認証情報を扱う必要があります。

Centaurでは、エージェントが直接秘密情報を取得できない仕組みが採用されています。

具体的には、資格情報はリクエスト時にネットワーク層で注入され、エージェント自身には生のキーが渡らない設計になっています。

この仕組みによって、次のようなリスクを軽減します。

• プロンプトインジェクション攻撃
• 外部データによる悪意ある指示
• APIキーの漏洩

Centaurは、エージェントが不正なコードや悪意ある入力に接触する可能性を前提に設計されており、実行環境の隔離やツールアクセス制御を重視しています。

Paradigm社内での利用例

Centaurは公開前からParadigm社内で運用されていました。

同社によると、次のような業務領域で利用されています。

• 投資・リサーチ
• エンジニアリング
• デザイン
• 採用・リクルーティング
• イベント運営
• カスタマーサポート

これらの部門で共通のAIエージェントを共有する仕組みを導入したことで、チームの働き方が大きく変わったとされています。

ツールやワークフローの拡張

Centaurは企業ごとに拡張可能な設計になっています。

組織は次のような形でカスタマイズできます。

• 社内APIをPythonツールとして公開
• ワークフローの追加
• 組織固有のプロンプトやスキルを導入

拡張は「overlay」と呼ばれる仕組みで管理でき、ベースシステムを変更せずに企業独自の機能を追加できます。

オープンソースAIエージェント基盤の新しい潮流

AIエージェントの実用化が進むにつれ、企業では次の課題が重要になっています。

• 長時間実行の信頼性
• セキュリティ
• チーム協働
• ワークフロー管理

Centaurはこれらを統合したチーム向けエージェント基盤として位置づけられています。

多くのエージェントフレームワークが実験的な自律AIに焦点を当てるのに対し、Centaurは

• 永続メモリ
• セキュアな資格情報管理
• ワークフローオーケストレーション
• チーム共有エージェント

といった運用レベルの機能に重点を置いています。

このような「エージェント実行基盤」は、コンテナ管理におけるKubernetesのように、将来的にAIソフトウェアの重要なインフラ層になる可能性も指摘されています。

企業のAIが単なるチャットツールではなく、実際の業務を継続的に処理するソフトウェアシステムへと変わる中で、Centaurのようなプラットフォームが登場し始めています。