手元のClaude CodeをそのままSlackに"招待"する — 開発者5人+AI45体を回すOSS基盤「Switch」

この半年、「Slackに常駐するAI社員」の類は数え切れないほど出てきた。YasmineやViktor、Scarlett——どれもベンダーが用意した一体のエージェントを"雇う"感覚のツールだ。月額を払うと、Slackに新しいメンバーが一人増える。そういう世界観だった。

Switch は、その発想をひっくり返してくる。雇うのではなく、自分の手元で動いているエージェントを、そのままチャットに"招待"する。ノートPCで走らせているClaude Code、同僚のマシンで動くCodex、サーバーに置いた自作のLangChainエージェント——それらを一つのSlackチャンネルに呼び込んで、人間と同じ部屋で会話させる。そういうツールだ。

作っているのは量子・AI企業のSandboxAQ（Flint AIブランド）。9月にProduct HuntでProduct of the Day 1位を獲得して話題になった。日本語の解説はまだほとんど無い。

「AI社員を雇う」ではなく「自分のエージェントを持ち込む」

ここがいちばん誤解されやすいので先に潰しておきたい。SwitchはAI社員ではない。**エージェントをチャットツールに接続するための土管（インフラ）**だ。

Yasmineのような従来型のツールは、エージェント本体もモデルもベンダー側にある。ユーザーは出来上がったAI同僚をSlackに招くだけで、中身をいじる余地はほとんどない。手軽な反面、「どのモデルで、どんな権限で、どこのデータを触って動いているのか」はベンダーの設計に委ねることになる。

Switchは逆で、エージェント本体を持ち込むのはこちら側だ。Claude CodeでもOpenAIのCodexでも、GoogleのADKでもLangChainでも、あるいは自分でゼロから書いたエージェントでもいい。公式ドキュメントの表現がわかりやすい——「あなたのノートPCで動くClaude Code、同僚のマシンのCodex、あなたのサーバーで動くLangChain製のHRエージェント。プロトコルさえ喋れれば、部屋に入れる」。

つまりSwitchが担うのは、エージェントそのものではなく、バラバラの場所で動く複数のエージェントと人間を、一つの共有された会話空間に集める役割である。単体AIを一体だけ置きたいならYasmineの方が早い。「チームがすでに使っている複数のエージェントを束ねたい」「モデルもホスティング先も自分で決めたい」なら、Switchの土俵になる。

対応チャネルと対応エージェント

つなげる先のチャットは主要どころを一通り押さえている。Slack、Microsoft Teams、Discord、Telegram、そしてOSS派に人気のMattermostの5つ。それぞれ専用のアダプタを持ち、チャンネルとSwitch本体の間でメッセージを双方向にやり取りする作りだ。

エージェント側はモデル・フレームワーク非依存を掲げていて、Claude Code、OpenAI Codex、GoogleのエージェントフレームワークやLangChainベースのエージェントに対応する。それ以外でも、Switchが定める「Agent Protocol」を喋れるものなら自作エージェントを差し込める。この"プロトコルさえ守れば何でも"という設計が、特定ベンダーへの囲い込みを避けたいエンジニアには効く。

面白いのは、エージェントが単なるBotの返信ではなく、それぞれ独自の名前とアバターを持った参加者としてチャンネルに現れる点だ。会話の履歴（ルーム）はPostgreSQLに保存され、人間・エージェント・サービスの全員が同じ履歴を見る。誰が何を言ったか、どのエージェントがどこまで文脈を持っているかが、そのままSlackのログとして残る。「AIとのやり取りが個人のDMに閉じて、チームから見えない」という、ありがちな属人化を構造的に避けられるわけだ。

なぜ"OSS・セルフホスト"であることが効くのか

Switchはオープンソースで、ライセンスはApache 2.0にCommons Clauseを足したもの。ざっくり言えば、社内利用や個人利用は自由だが、Switchそのものを再販するような商用転売には制限がかかる、という立て付けだ。自社のサーバーに丸ごと立てて、コードを読んで、必要なら手を入れられる。

これが地味に大きい。エージェントは往々にして、社内のコードベースやドキュメント、顧客データに触れる。そういう文脈で「会話もエージェントの実行環境も全部ベンダーのクラウドを経由します」という構成は、セキュリティやコンプライアンスに厳しい組織ほど飲み込みにくい。Switchなら、チャットの中継基盤も、つなぐエージェントも、動かす場所も自分の管理下に置ける。データが外に出る境界を自分で引けるのは、規制業種や機密性の高いチームにとって現実的な採用理由になる。

もう一つ、OSSだからこそ広がる使い方も想像できる。Switchはあくまで"接続層"なので、たとえば社内で育てた独自エージェント——就業規則に精通したHR担当、過去のインシデントを覚えたSRE担当——を、それぞれ別のチャンネルに常駐させる、といった構成が組める。将来的にMCP対応のツール群と組み合わさっていけば、「部署ごとに専門エージェントが常駐する共有ワークスペース」を、ベンダーロックインなしに自前で構築できる可能性がある。ここは現時点の完成度というより、OSS基盤ゆえの伸びしろの話だ。

セットアップは実質デスクトップアプリ1つ

「セルフホストのOSS」と聞くと身構えるが、入り口は思ったより軽い。ローカルで試すだけなら、Switch Consoleというデスクトップアプリ（macOS / Linux / Windows対応）を入れるところから始まる。

大まかな流れはこうだ。Consoleをインストールしてローカルサーバーを起動し、最初のエージェントを登録する（名前・作業ディレクトリ・プロバイダを指定するだけ）。あとはチャンネルを作れば、もう人間とエージェントの会話が始められる。チーム全体で運用する場合は、公式の「リモートホスティング」のドキュメントに沿ってサーバーへデプロイする形になる。

内部的には、エージェントとやり取りする「Agent Bridge」（HTTP＋Server-Sent Events）、SlackやTeamsごとのアダプタを束ねる「Collaboration Bridge」、権限やルームを管理する「Gateway API」といった部品で構成されている。この辺りの構造がドキュメントとコードで全部見えるのは、OSSならではの安心感だ。中身がブラックボックスのSaaSでは、こうはいかない。

5人の開発者と45体のエージェント、という運用例

Switchの説得力を裏打ちしているのが、開発元自身の使い方だ。Flint AIは「うちのチームはいま開発者5人とAIエージェント45体で構成されていて、全員がSlackにいる」という運用を公開している。人間の数を、エージェントの数が大きく上回っている構成である。

この数字を額面通りの生産性として受け取る必要はない。ただ、「一人が複数のエージェントを飼い、それらがチャンネル上で人間と地続きに会話する」働き方が、少なくとも作り手の日常では回っている、という一次情報としては十分に面白い。エージェントを一体ずつ手元で走らせる段階から、チーム全体で束ねて運用する段階へ——Switchが埋めようとしているのは、まさにこの隙間だ。

正直な評価

素直にいいと思うのは、思想の潔さだ。「エージェントは各自が持て、我々は集める場所だけ提供する」という割り切りは、乱立するAI社員ツールの中で明確に立ち位置が違う。モデルもホスティングも自分で決められる自由と、会話がチームに残る透明性は、エンジニア中心のチームにとって本質的な価値がある。

一方で、正直に言えば万人向けではない。Yasmineのように「入れて2分で動くAI同僚」を期待して来ると、面食らうはずだ。Switchは接続基盤なので、つなぐエージェント側は自分で用意して動かし続ける必要がある。Claude CodeやCodexを日常的に回している開発者にはむしろ自然だが、「AIに詳しくないけど業務を任せたい」層には、セルフホストの運用コストが重くのしかかるだろう。ここは向き不向きがはっきり分かれる。

Commons Clause付きライセンスの扱いも、社内で商用プロダクトに深く組み込む前には一度確認しておきたい点だ。純粋なApache 2.0のつもりで使うと、想定と違う可能性がある。

まとめると、Switchは「単体のAI社員」ではなく「自分たちのエージェント群を、自分たちの管理下で、チームのチャットに集約する道具」だ。手元でエージェントを動かすのが当たり前になったチームが、次に踏む一歩として理にかなっている。逆に、まだエージェントを一つも動かしていないなら、先に単体ツールで感触を掴んでからで遅くない。コードはGitHubで公開されているので、気になる人はまずローカルで一体つないでみるのが早い。