Y Combinatorが自社で使ってきたAIエージェント基盤「qm」がGitHubで9,500スターを超え、公開から数日でHacker Newsのトップに座り続けています。
面白いのは、コメント欄には「マルチプレイヤーって何?」「anti-slopスキルが22Kトークンで冗長」「QEMUと名前がかぶってる」といった皮肉混じりの声が半分近く並んでいることです。
その懐疑を眺めながらnpm exec一発で手元とFly.ioに立てて社内ツールを1日で組んでみたので、Claude Codeで動かした感触も含めて実装ハンズオンとして共有します。
qmとは何か YCが社内運用してきたマルチプレイヤーAIエージェント基盤
qmは「Quartermaster」の略で、船内の物資と秩序を管理する役職から取られた名前です。
Y Combinatorが自社の業務で回してきたエージェント基盤をOSS化したもので、ライセンスはMIT、公開直後にスター9,500・フォーク1,000・未解決issue24件という速度で伸びています。
コアはTypeScript/Node.jsで、Fastify、PostgreSQL、Slack Boltという構成。
Web UIはViteとLitで書かれていて、CLI一発でFly.ioかAWSに投げられます。
肝はエージェント本体を差し替えられる点で、Pi、OpenCode、Codex、Claude Codeの4つが同じコアに刺さります。
「モデルをClaudeで使いたいけど、来月はCodexに乗り換えたいかも」がベンダーロックインなしで通せる設計です。
YC公式の位置づけ Hermes AgentやOpenClawに似ているが会社全体で使える
公式サイトの説明を借りると、qmの立ち位置は「Hermes AgentやOpenClawに似ているけど、会社全体で使えるように作った」というものです。
つまり自分専用のAIコンパニオンではなく、「営業さん専用」「エンジニアA専用」といったスコープを組織単位で並列に立てる基盤です。
Hermes AgentやOpenClawとの違いは個人アシスタント型かマルチプレイヤー型か
Hermes AgentとOpenClawが「1人の作業を延長するアシスタント」だとすれば、qmは「複数人が並列に別のエージェントを持ち、それぞれの記憶とツール権限が混ざらない」設計です。
比較しやすいように整理すると次のような形になります。
Hermes Agentについては別記事で仕組みを分解しているので、そちらと並べて読むと違いが見えやすいはずです。
qmはこの「個人単位ではなく役割単位で切る」というだけで、記憶の混線問題やツール権限の暴走リスクが構造的に消えます。
1人で使う分にはこの嬉しさは見えづらいですが、副業でチームを持っている人や、社内で小さなAIチームを作りたい人にとっては地味に効きます。
スコープごとに隔離されたサンドボックスと記憶の仕組み
qmのアーキテクチャで一番よくできていると感じたのはスコープの隔離です。
スコープというのは、YC文脈では「営業チーム」「サポートチーム」「エンジニア個人」といった単位を指します。
同じqmインスタンスの中で、これらを完全に分けて動かせます。
各スコープが持つもの
スコープごとに独立して持てるのは以下の要素です。
- ファイルシステム(他スコープから見えない)
- 記憶(PostgreSQLに永続化、スコープIDで分離)
- ツール権限(Slackチャネル、DB接続、APIキーごとに割り当て)
- cronジョブ(スコープ内でスケジュール実行)
- webhook受け口(スコープ単位のエンドポイント)
- キーチェーン(シークレット管理)
要するに、各スコープは「個別のミニOS」として振る舞います。
営業スコープが顧客DBを読める権限を持っていても、サポートスコープからは触れない、みたいな切り分けが標準機能で入っています。
Claude Codeユーザーから見たときのqmの位置
Claude Codeユーザー目線で言うと、qmはClaude Codeを「エージェントとして呼び出すサーバー基盤」に当たります。
ローカルのターミナルでClaude Codeを叩くのはそのまま、qmはそのClaude CodeプロセスをFly.io側でスコープごとに複数立てて、Slackやweb UIから並列に触らせてくれる、というイメージが近いです。
Claude Codeとqmで社内ツールをセットアップしてみる
ここからが実際に手を動かすパートです。
Fly.ioアカウントを持っている前提で、npmとflyコマンドだけあれば動きます。
npm exec 一発で初期化
npm exec --yes --package=@yc-software/qm@latest -- qm init . \
--org my-startup \
--target fly--target awsにすればAWS ECR/ECSデプロイの雛形も生成されます。
生成されるのはinfra定義(fly.toml、DBスキーマ)、Slack Boltハンドラ、web UI雛形、AGENTS.md(CLAUDE.mdはここへのシンボリックリンク)、skills-seed/のスキル雛形です。
Claude Codeをqmのエージェントとして繋ぐ
qm initが終わったら、config/agents.tsでエージェント側を指定します。
export const agents = {
default: {
driver: 'claude-code',
model: 'claude-opus-5',
apiKey: process.env.ANTHROPIC_API_KEY,
},
}driverをopencode codex piに変えれば、他のエージェントに切り替えられます。
Fly.ioへデプロイ
fly launch --config fly.toml
fly secrets set ANTHROPIC_API_KEY=sk-ant-...
fly deployこれで営業スコープ、サポートスコープの雛形が立ち上がり、それぞれにSlack Botとweb UIが紐付きます。
ここまでで大体30分から1時間、初回でも半日は超えないくらいで動く水準でした。
Slackから話しかけて業務を任せる流れ
qmで一番気持ちが良いのが、Slackから直接エージェントに話しかけられる部分です。
Slack Boltが最初から組み込まれているので、/qm askで該当スコープのエージェントを叩けます。
/qm ask sales 昨日流入した問い合わせを、優先度順に並べて要約してエージェントは営業スコープの記憶とツール権限だけを使ってこの依頼を処理します。
サポートスコープの顧客DBは覗きにいきません。
実際にやったこと 副業案件の見積もりbotを1日で立てた
私が試したのは「副業案件の見積もりbot」で、Notion上の過去見積もりを読み込んで新規案件の想定工数を返す用途です。
- スコープ名
freelance-quote - ツール権限 Notion API読み取り、Slack投稿
- cron 毎朝9時にNotionの新規案件をチェック
- 記憶 過去見積もりのパターンをPostgreSQLに蓄積
これをClaude Codeエージェントで動かして、Slackから/qm ask freelance-quote 今日の新規案件を見積もってと打つと、5分後には投稿されます。
自作Slack Botで似たものを組もうとすると、Slack Boltの認証、DBスキーマ設計、cronワーカー、シークレット管理を全部自分で書くことになります。
qmを噛ませるとこの周辺基盤が全部お膳立てされていて、書くのはNotion API連携のスキル定義だけで済みました。
HNで指摘されていた気になる部分 導入前に知っておきたいこと
提灯記事にならないよう、Hacker Newsで挙がっていた懸念にそのまま触れます。
165件のコメントの中で繰り返し出ていたのは以下の3点でした。
multiplayerという言葉の定義が曖昧
「マルチプレイヤーって、複数エージェントが協調するの? それとも複数人が別々のエージェントを持つの?」という質問が繰り返し出ていました。
答えは後者(複数人が別スコープを持つ)ですが、公式ページの説明ではここが最初はっきりしません。
導入するときは「うちの場合、マルチプレイヤーは役割ごとに独立エージェント」と自分で言い換えておくと、社内説明がぶれません。
anti-slopスキルが22Kトークンで冗長
qmには「AI出力がslop(低品質な生成物)にならないようにする」内蔵スキルがあります。
これがなんと22Kトークン。
「1Kトークンで書き直したもの貼るわ」と対案を投稿したコメントが上位に来ていて、正直これは同意です。
skills-seed/を眺めると確かに冗長で、初回セットアップ時に自分のプロジェクト向けに整理し直したほうが料金面でも実行速度でも効きます。
QEMUのqmコマンドと名前がかぶる
qmという3文字コマンドは、QEMU(仮想化ツール)の管理コマンドと衝突します。
Proxmox環境で運用している人には結構痛い衝突なので、alias qmc=qmのような形で自分の環境では別名にしておくのが安全です。
セキュリティは3モードあるが「実験的」の但し書きに注意
セキュリティモードはStrict、Auto、Dangerousの3段階です。
- Strict 全ツール呼び出しに人間承認が必要
- Auto(デフォルト) 外部データをモデルに渡す前に分類器でスクリーニング
- Dangerous スクリーニングなし
READMEには「早期・実験的段階」と明記されていて、脅威モデルとして「bypassable command policy」「plaintext credentials during use」「incomplete content screening」なども開発元自身が認めています。
本番の機密データを扱うスコープはStrictで運用しつつ、Dangerousは検証用に絞るのが無難です。
qmが向いている場面 個人開発者と小規模チームの向き合い方
qmは「1人で使うシングルアシスタント」用途では、Hermes AgentやOpenClawのほうがセットアップが軽くて向いています。
qmが刺さるのは以下のような場面です。
- 副業でチームを持っていて、メンバーごとに別スコープでエージェントを立てたい
- 社内に3〜10人のチームがあって、役割ごとに別エージェントを回したい
- Claude Codeを試したけど、複数タスクを並列で走らせる基盤が欲しくなってきた
- 将来Codex、OpenCodeに切り替える可能性を残しておきたい
逆に、以下のような場面ではqmを噛ませない方が早いです。
- 個人利用でエージェントは1つで十分
- 社内にDevOps担当がおらず、Fly.io、AWSの運用が回せない
- 本番の機密データを扱う予定で、実験的段階という但し書きが呑めない
OpenAgents記事では「複数エージェントを一元管理する」思想の別実装を紹介しているので、qmと合わせて読むと「マルチエージェント基盤」というジャンルの選択肢の広さが見えるはずです。
コミット44、issue24件のフェーズなので、今は「試して自分の用途に合うか判断する」タイミング。
MITライセンスで手元でも動くので、Fly.ioに10分だけ立てて壊してみるくらいの気軽さで触ってみると、次のエージェント基盤選びの目線が変わります。


💬 コメント
ログイン か 会員登録 するとコメントできます