AIエージェントは「一人に一台」でいいのか？チーム用基盤qmが問う次の常識

「AIエージェントが仕事を変える」——そんな言葉をよく耳にする。しかし冷静に考えてみると、いま世に出回っているエージェントのほとんどは個人向けの私設秘書として設計されている。一人が使うには便利だが、チーム全員に展開しようとした途端、設定の複雑さが爆発的に膨らむ。

それを正面から問題にしたのが、オープンソースプロジェクト「qm」（yc-software）だ。GitHubで短期間に大きな注目を集め、Hacker Newsでも活発な議論が起きた一本である。

そもそもqmは何を解決しようとしているのか

qmのREADMEには、こう書いてある。

“Most agents are designed like personal assistants. You can make one work for a whole company, but it quickly gets complex."（ほとんどのエージェントは個人秘書として設計されている。一社全体に使わせることはできるが、すぐに複雑になる）

たとえばSlackに社員20人がいるスタートアップで、全員がAIエージェントを使いたいとする。全員が同じエージェントを共有すると、Aさんの設定がBさんに影響する。かといって全員分を個別に立ち上げると、管理が煩雑になる。qmはこの「n人の壁」を突き破ることを狙っている。

「マルチプレイヤー」とは何か

qmのキャッチコピーは “Multiplayer agent harness for work”（仕事用マルチプレイヤー・エージェント基盤）。ここで言う「マルチプレイヤー」は、ゲームの対戦機能ではなく、複数の人間が同じシステム上でそれぞれ独立した作業環境を持てる仕組みを指す。

具体的には、社員それぞれが「自分だけのワークスペース」を持ちながら、SlackチャンネルやプロジェクトではAIを共有リソースとして呼び出せる。個人スコープ（自分だけ）と共有スコープ（チーム全体）が明確に分離されており、Aさんの操作がBさんの環境に干渉しない設計だ。

どんなことができるのか

qmが想定している主なユースケースはこんな感じだ。

• 社内メモ・メール・ドキュメント・データベースとWebを横断して検索する
• 「会社の頭脳」（社内知識ベース）から情報を引き出す
• 社内向けカスタムアプリを作成し、適切な人だけに公開する
• 過去のメールから文体を学習し、受信トレイのラベリングや返信下書きをスケジュール実行する
• 共有チャンネルでプロジェクトを追跡し、進捗や次のアクションを自動投稿する

一言でいえば、「会社の業務フローにAIエージェントを組み込む基盤」だ。

ハーネスとは何か、なぜ複数対応が重要なのか

qmが面白いのは、特定のAIモデルやツールに縛られていない点だ。ここで「ハーネス」（harness）という言葉が出てくる。これはエージェントが実際に動くための「制御フレーム」のようなもので、いわばエンジン部分を差し替えられる仕組みだと思えばいい。

qmが対応しているハーネスとして明記されているのは、Pi、OpenCode、Codex、そしてClaude Codeの4つ。これらを同じコア上で切り替えられるため、「このデプロイはCodexを使う」「あのチームはClaude Codeで動かす」といった選択ができる。特定ベンダーに縛られないオープンな設計は、スタートアップにとって長期の身動きやすさを意味する。

利用するハーネスやAPIによって、呼び出すAIモデルの種類やコストも変わる。高精度な判断が必要な場面と、ルーティンな自動化で十分な場面では、モデルを使い分けることでコストの最適化も図れる（高性能モデルほど1回の応答あたりの料金が高い傾向にある）。

セキュリティの設計が正直すぎて逆に信頼できる

企業でAIエージェントを運用するとき、一番怖いのはセキュリティだ。qmはこの点に対して、3段階のセキュリティ姿勢（Security Posture）を用意している。

「Dangerous」という名前が物騒だが、それだけ正直に書いているとも言える。なお、「再帰的な削除」や「破壊的なSQL（データベース操作）」など、あらかじめ宣言した禁止コマンドポリシーはどの姿勢でも必ず適用される。

設計思想として重要なのは、**エージェントが「誰として動くか」**という点だ。qmは「エージェントは操作している本人の権限・認証情報で動く」という原則を取る。これはOpenCode、Codex、Claude Codeといったローカル型エージェントと同じ考え方で、「エージェントが会社全体の管理者権限を握る」という危険な状況を避けている。

アーキテクチャを平たく言うと

技術的な詳細に踏み込みすぎずに言えば、qmの中核はTypeScript（JavaScriptに型安全性を加えた言語）で書かれており、Node.js上で動く。セッション履歴やタスクキューの永続化にはPostgres（定番のデータベース）が使われている。

「ハーネス」「セッションストア」「サンドボックス（隔離された実行環境）」「メモリ」それぞれがインターフェースの裏に隠れており、本番環境では別の実装に差し替えられる。デプロイ先はFlyまたはAWSが公式に案内されている。

ウェブUI、管理パネル、Slack連携はいずれも「オプショナルなプラグイン」として設計されており、必要なものだけ組み合わせられる。

「スタートアップ向け」とはどういう意味か

qmのREADMEには「designed for startups（スタートアップ向けに設計）」とある。この言葉は単なるターゲット設定ではなく、設計思想に直結している。

大企業がゼロから作るような専用AIインフラは、スタートアップには重すぎる。かといって個人向けエージェントを人数分並べるだけでは、チームとして機能しない。qmはその中間を狙っている——チームで使えるが、過剰に重くない。

オープンソースであることも重要だ。ベンダーロックインを嫌う組織が自社でデプロイして運用できるよう、デプロイ設定ファイルを組織固有のリポジトリとして管理する仕組みが設計に組み込まれている。

まだ答えが出ていない問い

qmは有望なアプローチを提示しているが、疑問も残る。

「全員が同じインフラを使いながら干渉しない」設計は、言うは易し行うは難しだ。セキュリティのスコープ分離が実際の運用でどこまで堅牢かは、利用が広まってからでないと分からない。スキルのバージョン管理や、エージェントが誤った判断をしたときのロールバック手順など、長期運用に必要な機能の成熟度も今後の課題だろう。

Hacker Newsのコメントが百件を超えたのは、技術的な関心だけでなく「チーム向けエージェントがまだ正解を出せていない領域だ」という共通認識の表れでもある。qmがその正解に近い一手なのか、それとも次の問いを投げかける一石なのかは、実際に使ってみたチームの声が蓄積されてから判断するのが正直なところだ。

以上です。なるほどラボでは、こうしたAIを"自分の環境で動かしたい・24時間働かせ続けたい"という方向けの情報を発信しています。自分に合った動かし方が気になる方は、無料の診断をどうぞ。