Omni by xpander

処理したいプロセスをOmniに伝えれば、それをエージェントのプロジェクトに変える。コネクタを選び、指示を書き、メモリを設定し、公開前にエージェントをレビューに通す。エンジニアがAPIドキュメントを何日も読んで行う配線を代わりに済ませる。インフラは要らない。こちら側にセットアップのプロジェクトも要らない。すべてはチャットウィンドウの一文から始まる。

Omniは過去のタスクとトレースを読み、エージェントがどこで成功し失敗したかを見て、指示を書き直して改善する。先月チケットをさばいたエージェントが、今月は設定を一つも触らずにはっきりと上手く処理する。走らせるほど良くなり、誰も見なくなってから劣化する、ということがない。企業向けAIエージェントのほとんどは、この二度目の手直しを受けない。

APIやコネクタが変わると、Omniは影響を受けるエージェントをすべて見つけ、静かに壊れる前に更新する。おかげで、レポートが空で返ってきてから何日も経って破綻に気づく、という事態を避けられる。連携の多い構成でこそ効く。エンドポイントが一つ変わっただけで、それに依存するエージェントの連鎖が静かに壊れるからだ。

ClaudeやCodexでローカルに組んだエージェントは、xpanderへ持ち込み、クラウドで安定して走らせられる。作業はそのスキルとMCPコネクタごと移るので、同僚のマシンが唯一の置き場所ではなくなる。移行プロジェクトなしのAIエージェントのデプロイである。ゼロから作り直す必要はない。

Omniは同じタスクを最先端モデルとオープンモデルで走らせ、どれが最も良いかを示す。そのうえでエージェントを作り直さずに切り替えられる。モデルの更新は、計画するプロジェクトではなく、変える設定になる。モデル選びは、賭ける判断ではなく、走らせるテストになる。一つ選び、走らせ、トレースを比べる。

エージェントは設定の違いを安全に処理しながら開発から本番へ移り、それぞれが文書化される。土台のプラットフォームにあるユーザー単位の権限と監査証跡と合わせて、これが本番への移行をITチームにとって扱いやすくする。何が動くかを承認する必要があるからだ。地味な部分である。同時に、エージェントが本番に残るか、試作フォルダの中で死ぬかを決める部分でもある。

エージェントは、Slack、Teams、GitHub、社内APIなど、自社がすでに使うシステムへ手を伸ばす。MCPコネクタとAPI呼び出しは、場当たり的な回避策ではなく統制された経路を通るので、認証情報はモデルのコンテキストに入らない。この切り分けが要点だ。セキュリティチームはどんな機能一覧よりもこれを気にする。