- qmは、スタートアップのメンバーがそれぞれ隔離された作業空間を使いながら、Slackチャンネル、グループメッセージ、プロジェクトで一緒にエージェントと協業できるマルチプレイヤー・エージェントハーネス
- 人とチャットルームごとに、メモリ、ファイル、キーチェーン、権限、予約タスク、Webアプリ、永続サンドボックスを分離し、SlackとWebで同じアイデンティティと設定を維持する
- Pi、OpenCode、Codex、Claude Codeを同一のコアに接続でき、セッションストア、サンドボックス、メモリもインターフェースの背後に配置することで、特定のモデルやプロバイダーへの依存を避ける
- Strict、Auto、Dangerousのセキュリティモードを提供し、すべてのモードで再帰削除や破壊的SQLのような操作に対するコマンドポリシーと強制拒否を適用する
- 組織別の設定とインフラは、別のデプロイ用リポジトリまたは通常のクローンで作成した非公開リポジトリに保持し、運用者が自身のFly.ioまたはAWSアカウントに直接デプロイする必要がある
組織単位のエージェント作業空間
- 個人アシスタント型エージェントを会社全体に適用する際に生じる複雑さを減らすため、個人および共有スコープを基本単位として設計している
- 従業員ごとに独立した作業空間で、他の人に影響を与えずに作業できる
- Slackチャンネル、グループメッセージ、プロジェクトでは、複数人が同じエージェントと協業できる
- 各人とチャットルームは、別々のメモリ、ファイル、キーチェーンのビュー、権限、予約タスク、Webアプリ、永続サンドボックスを持つ
- SlackとWebアプリの間で同じアイデンティティと構成を使用する
- 管理者は組織レベルの設定、セキュリティ体制、利用可能なハーネスとモデルを制御できる
- 技術スキルはスコープが所有し、権限付与によって共有できる
- 組織全体への昇格には管理者の承認が必要
- Gitリポジトリからスキルパックを取得できる
- 予約タスク（cron）と監視タスク（watch）は、ユーザーが見ていなくてもバックグラウンドで実行される
サポートする業務
- 内部メモ、メール、文書、データベース、Webをまとめて検索し、社内ナレッジを参照できる
- 内部Webアプリを作成して必要な人に公開し、データを最新の状態に保てる
- 過去の送信履歴からユーザーの文体を学習したうえで、スケジュールに従って受信トレイを分類し、ラベルと返信の下書きを作成できる
- 既存リポジトリでテスト実行、PR作成、CI監視、システムログ確認を行える
- 共有チャンネルでプロジェクトを追跡し、進捗状況とフォローアップ作業を投稿できる
コアと実行構造
- すべてのリクエストはヘッドレスコアを通過し、さまざまなモデルとハーネスで応答を生成する
- Postgresがユーザーデータ、セッション履歴、キュー、メモリなどの永続状態を保存する
- エージェントが使用するツール面は小さく固定されており、
executeツールはそのスコープの隔離されたサンドボックスでコマンドを実行する
- サンドボックスは各スコープが所有する永続的なコンピューターとして動作する
- インストールしたツールは次の作業でも維持される
- Web UI、管理者パネル、公開ポータルは、コアのHTTP API上にインストールする任意のプラグイン
- Slackは、コアがサービスクライアントとして直接起動し監督する任意のインプロセスプラグイン
- コアはNodeでTypeScriptを直接実行し、HTTPにはFastifyを使用する
- SlackプラグインはBoltを使用する
- Web UIはViteでビルドし、Litでレンダリングする
- ハーネス、セッションストア、サンドボックス、メモリはそれぞれインターフェースの背後にあり、本番実装は1つの配線ファイルで差し替えられる
組織別デプロイモデル
- 会社別の構成、カスタムツールとスキル、サンドボックスイメージ、インフラは、コアと分離されたデプロイディレクトリに置く
qm CLIがデプロイディレクトリを検証し、デプロイする- 組織所有のリポジトリで
@yc-software/qmに依存したうえで、次のように初期化できる
npm exec --yes --package=@yc-software/qm@latest -- \
qm init . --org <slug> --target <fly-or-aws>
npm install
- 初期化プロセスは、インフラ、Webログイン、コネクターの認証情報、任意のSlackアクセス、デプロイ、実際の検証を案内し、ソースのチェックアウトは不要
- デプロイは運用者自身のクラウドアカウントで実行される
- 初期化はデプロイCIを作成または有効化せず、qmリポジトリにも本番デプロイワークフローはない
- 具体的な手順は
deployment.mdにまとめられている
セキュリティと秘密情報
- エージェントは、一緒に作業する人の認証情報と権限で行動し、実行したすべての作業が監査ログに残る
- 組織は1つのセキュリティ体制を選び、より狭いスコープではそれを緩和せず、強化のみできる
- Strict: 効果のない2種類のターン終了処理を除き、すべてのハーネスツール呼び出しを人の承認があるまで停止する
- Auto: デフォルトモードで、出所ラベルが付いた外部データとツール結果をモデルに渡す前に分類器が検査する
- Dangerous: コンテンツ検査やツール呼び出し間の一時停止がない
- 事前宣言されたコマンドポリシーはすべてのセキュリティモードに適用される
- 承認ルールとともに、再帰削除や破壊的SQLのようなコマンドを強制的に拒否する
- Dangerousモードも例外ではない
- 脅威モデル、運用者の前提条件、既知の制限は
SECURITY.mdで確認できる
非公開カスタムリポジトリ
- デプロイリポジトリだけでは不十分な組織は、コアと非公開のカスタムコードを1か所で読めるように非公開クローンリポジトリを運用できる
- GitHubのFork機能ではなく、通常のクローンで作成する必要がある
- 公開リポジトリのGitHubフォークは非公開に切り替えられない
- GitHubフォークは元リポジトリとオブジェクトネットワークを共有するため、フォークにプッシュしたコミットが公開側からSHAで参照される可能性がある
- 通常のクローンリポジトリではこの問題はないが、upstreamのCIワークフローが組織アカウントで実際に実行される
- 必要な秘密情報を提供するか、不要なワークフローを無効化する必要がある
- 組織別の構成、サンドボックスツールとスキル、プラグインイメージ、インフラは
deploy/layers/<org>/に保管する
- コアをupstreamとバイト単位で同一に維持し、マージ規模を減らす
- 2つのスキルが、公開コアと非公開カスタム領域の境界を管理する
update-qmはupstreamのqmを非公開リポジトリにマージし、同期PRを作成するupstream-prはupstream/mainからブランチを作成し、組織に依存しない修正をqmへ送る- プッシュ前にdiff、コミットメッセージ、スクリーンショットから組織識別子を検査する
deploy/layers/以下のファイルはupstreamへ送信しない
コントリビューションとライセンス
- コントリビューションはコードではなく、人が書いた
.txtまたは.md文書として受け付ける
- 脆弱性は公開Issueではなく、
SECURITY.mdの手順に従って非公開で報告する必要がある
- 別途記載がない部分はMIT Licenseで提供される
1件のコメント
Hacker Newsのコメント
LLM時代に新しいUIの基本要素と概念が現れているのは興味深いが、創造的なアプリが多すぎるうえ説明も不足していて、それぞれが何をするものなのか把握しにくい。
HermesのエージェントWebページでは機能をまったく理解できず、qmのページをしばらく探してようやく適切な説明を見つけた。最近はコーディングセッション管理にYC支援のOrcaを愛用しているが、PostgreSQLベースのセッションデータベースが不足しているのでqmは試す価値がありそうだ
Buzzと並んでこういう方向性が出てきたのはうれしい。マルチユーザーエージェントで最も難しい部分はエージェントループではなくスコープ設定であり、QMの個人別スコープと共有ルームは全社向けアシスタントに対する理にかなった解法だ。
チームでClaude CodeとCodexを同時に走らせるマルチユーザーコーディングツールAQ(aq.dev)を作っているので、YCが業務向けマルチユーザーエージェントツールを出したのは方向性を裏付ける一方で、少し非現実的にも感じる
すでに似た製品が多いのに、なぜClaude Coworkではなくこれを使うべきなのかわからない。Coworkの方がシンプルで完成度も機能も高く見えるので、
QM vs Coworkの比較が必要だ組織全体のコンテキストとセキュリティをどう実装したのか確認する必要がある。現状、個人に最適なAIインターフェースを提供する自分のコーディングツールと非常に相補的に見えるので、いくつかの大きなチケットだけで全社アーキテクチャと生産的な個人向けコーディングインターフェースの両方を持てるとよい
Hermesが以前使っていたOpenClaw系エージェントの中で最良の選択なのか、上級ユーザーはこうしたシステムを実際に何に使っているのか気になる
単純なCI失敗の自動修正、本番アラート受信後の根本原因分析と修正PRの作成、遅いデータベースクエリの定期点検と最適化、単発のデータ質問に答えるチャート作成などに使っている。移動中のコーディングにも使ったが、コードを直接確認できる対話型エージェントの方をより好んでいる
ソフトウェアを作ること自体と完全なコントロール権が好きで、基本のエージェントループ自体は実際それほど特別ではない。コアループの外側に調整できる要素が非常に多く、さまざまな拡張方法を試すのが楽しい。収益化や汎用性を気にせず必要な機能だけ追加すればよく、無限にプラグイン可能にする必要もない。nanoclawとHermesがコアアイデアを教えてくれたことには感謝しているが、今は自分流に変えたい
補助的なRSSフィードやニュースレターを読ませ、自分に重要な情報だけを選別してニュースや市場動向を届ける用途で使っている
Buzzに奪われる領域を最小化するためにYCが急いで公開した社内ツールのように見える。両者を実際に比較した評価が気になる
yc softwareが何を意味するのか気になるテンプレートっぽく見えないインターフェースを作らせる**
anti-slopデザインスキル**まで配布しているのは興味深い。高級消費財ではAIがよく使うカラーパレットを禁止し、ランディングページやポートフォリオは視覚的なプロダクトなので、偽のスクリーンショット領域だけあるテキストページを低品質な成果物と見なしている。 https://github.com/yc-software/qm/blob/7f2c916360f1797a8ff2a...
タイトルは
qm - a multiplayer agent harness for workのように、ツールの用途がわかる方が有用だ