🤖 Multica とは — コーディングエージェントを「同僚」にするオープンソースの Managed Agents プラットフォーム

🧭 はじめに

Multica は、GitHub 上で multica-ai/multica として公開されているオープンソースのプラットフォームです。スローガンは「Your next 10 hires won't be human.（あなたの次の 10 人の採用者は人間ではない）」で、コーディングエージェントを「人間の同僚と同じように Issue をアサインできる存在」として扱うのがコンセプトになっています。

公式 README の紹介文を要約すると、Multica は次のような立ち位置のプロダクトです。

• オープンソースの Managed Agents プラットフォーム — Apache License 2.0 をベースとする 修正ライセンス で配布されている（単一組織内利用は OK だが、第三者向けにホスト型サービスとして提供したり商用製品/サービスに組み込む場合は別途商用ライセンスが必要、apps/web/ 配下の LOGO・著作権表示は保持義務あり。詳細はリポジトリ内 LICENSE を参照）
• コーディングエージェントを Issue 単位でアサインする — 人間に対する Jira/Linear の Issue アサインと同じ体験で、エージェントへタスクを委譲できる
• マルチエージェント対応 — Claude Code / Codex / OpenClaw / OpenCode / Hermes / Gemini / Pi / Cursor Agent の 8 種をネイティブサポート
• ベンダニュートラル — クラウド版（multica.ai/app）とセルフホスト版の両方を提供。Docker Compose と Helm の構成例がリポジトリに含まれる
• チームでの利用を前提 — 複数ユーザーのロール・パーミッション、ワークスペース単位の隔離、ボード上での会話など、組織での運用機能が中心

本記事では、Multica がどのようなアーキテクチャで何を提供しているのか、Issue ライフサイクルと Skills システムがどのように噛み合っているのか、そしてセルフホストする際の構成要素を、Notion 上の社内ナレッジとして整理することを目的とします。

💡 用語メモ：本記事で「Agent」（エージェント）と表記しているものは、Claude Code・Codex・OpenClaw 等の コーディング CLI を Multica が「人間の同僚」のように扱える形でラップしたものを指します。Multica の Web UI 上では、人間と同じようにプロフィール画像・名前・コメントを持って表示されます。

💡 なぜ Multica が必要なのか

Claude Code や Cursor Agent のようなコーディングエージェントは、単独で使う限りは「対話するもの」です。プロンプトをコピーペーストし、結果を読み、また指示を出すというサイクルが基本です。チームに 1 人の AI を加えるとなると、次のような課題が出てきます。

• 誰が何を任せたかが追跡できない
• 同じプロンプトを繰り返し書いて時間を浪費する
• バックグラウンド実行を放置すると、終わったかどうか分からない
• 複数のエージェントを併用すると、どのタスクをどれに任せるかの管理が複雑化する

Multica は、この問題を 「エージェントを Issue Tracker に乗せる」 というアプローチで解決します。エージェントには名前・プロフィール・実行ランタイムが紐づき、Issue ボード上に人間と同じように現れ、Issue にアサインされ、コメントを残し、ブロッカーを報告する、という設計です。

エージェントを「ツール」ではなく「チームメンバー」として扱うのが Multica の中心思想です。README に掲載されているスクリーンショットでは、Issue にエージェントがアサインされている UI が「人間と同じ並び」で表示されており、設計上の割り切りがそのまま画面に出ています（一覧上、人間とエージェントを区別するアイコンはあるものの、操作面はほぼ統一されています）。

🏗 アーキテクチャの全体像

公式 README に掲載されている構成図を Mermaid で再構成すると、次のようになります。

各レイヤの役割は次のとおりです。

レイヤ	技術スタック	役割
Frontend	Next.js 16（App Router）	ボード UI、エージェント管理、Issue 編集
Backend	Go（Chi router、sqlc、gorilla/websocket）	API、認証、ライフサイクル管理、リアルタイム配信
Database	PostgreSQL 17 + pgvector	Issue・コメント・スキル・ベクトル検索の永続化
Agent Runtime	ローカルデーモン or クラウドランタイム	エージェント CLI を実行する計算環境

押さえておきたい点は次のとおりです。

• バックエンドが Go で書かれている — Next.js + 何らかのサーバレスではなく、Chi router ベースの Go 製サーバを採用しています。WebSocket は gorilla/websocket、SQL の型安全アクセスには sqlc を使用
• PostgreSQL は pgvector 拡張を有効化 — 後述する Skills の検索や類似 Issue マッチングで、意味検索を行う基盤
• エージェント実行は別プロセス — バックエンドは「タスクをディスパッチする」ことに専念し、実際にコーディングエージェントを起動するのは Agent Daemon が担う

apps/、server/、packages/ でモノレポ構成になっており、pnpm-workspace.yaml と turbo.json で workspace を統合管理しています。Docker 化された開発環境（docker-compose.yml）とセルフホスト構成（docker-compose.selfhost.yml、Dockerfile.web）も整備されているので、社内で動かす分には選択肢が複数ある形です（Helm チャートが充実しているわけではないので、Kubernetes へ載せる場合はもう一手間かかる印象でした）。

🧩 中核コンセプト

Multica を理解するうえで重要なコンセプトは、Runtime / Agent / Issue / Skill / Workspace の 5 つです。概念整理せずにダッシュボードを開くと、似たような言葉の羅列で迷子になりやすいため、最初にこの 5 つを押さえておくと運用がスムーズになります。

⚙️ Runtime（ランタイム）

Runtime は エージェントタスクを実行する計算環境 です。実体としては、ローカルマシンで動く multica daemon か、あるいはクラウド上のランタイムインスタンスです。

各ランタイムは「自分の PATH 上で利用可能な CLI（claude、codex、openclaw、opencode、hermes、gemini、pi、cursor-agent）」を Multica に報告します。Multica はこの情報をもとに、特定のエージェントタスクをどのランタイムにルーティングできるかを判定します。

たとえば「Claude Code 専用のエージェント」を作ると、claude バイナリが PATH 上にあるランタイムでしか実行されません。これがチーム運用上のリソースプーリングを支えていて、「メンバーの誰のマシンにどのエージェントが入っているか」を全員で共有する形になります。

🤖 Agent（エージェント）

Agent は、特定のランタイムとプロバイダ（Claude Code / Codex / 他）に紐付いた、Multica 上の人格 です。Web UI の Settings → Agents → New Agent から作成し、ランタイムとプロバイダを指定し、表示名を付けます。

作成されたエージェントは、Issue ボード上で人間と同じく以下の操作の対象になります。

• Issue にアサインされる
• Issue にコメントする
• 別の Issue を新規作成する
• ブロッカーを報告する

「ブロッカー報告」をエージェント側からできる、というのが地味に効くポイントだと思います（人間も「分からなくなったら聞く」をやってほしいわけで、そこを構造化してくれているのは助かります）。

🎫 Issue

Issue はタスク単位で、Web UI またはコマンドラインの multica issue create で作成します。アサイン先は人間でもエージェントでも構いません。エージェントにアサインされた Issue は、後述するライフサイクルに従って自動実行されます。

📦 Skill

Skill は、エージェントが過去に解決した手順を 再利用可能な単位 として保存したものです。デプロイ手順、マイグレーション、コードレビュー観点といった「やり方」を全社で共有することで、チーム全体の能力が複利的に積み上がるように設計されています。

リポジトリには skills-lock.json がコミットされており、これは npm の lockfile に相当する Skills のバージョン固定情報です（厳密には Multica 独自のロック形式ですが、computedHash でバージョン固定する性質は npm/pnpm のロックファイルと近いです）。チームメンバー間で同じバージョンの Skill が読み込まれるよう保証する仕組みになっています。

🗂 Workspace

Workspace はチームや組織単位の 隔離境界 です。各ワークスペースが独自のエージェント、Issue、設定を持ち、ロール・パーミッションもワークスペース単位で管理されます。複数のクライアント案件を 1 つの Multica インスタンスで運用する際の境界線になります。

🔄 Issue のライフサイクル

エージェントが Issue を処理する際の状態遷移は、以下の 5 つです。

各状態の意味は次のとおりです。

状態	意味
Enqueued	Issue が作成され、エージェントへアサインされた直後の待機状態
Claimed	対象ランタイムの Daemon が Issue を引き取った状態
Started	CLI（Claude Code 等）の実際の実行が開始された状態
Completed	エージェントがタスクを完了した状態
Failed	エラーまたはブロッカー報告で停止した状態

これら状態遷移はバックエンドが管理し、WebSocket でリアルタイムにフロントエンドへ配信 されます。gorilla/websocket による双方向接続を使うことで、ブラウザ上のボードがエージェントの進捗をライブストリーミングで表示できる構造です。

ユーザーから見ると、Issue にエージェントをアサインしてからは「眺めているだけで進捗が更新されていく」体験になります。コメントもリアルタイムに流れ、ブロッカー報告は自動的にステータス変更とともに通知されます（Linear や Jira を使ったことがある人なら、人間に Issue をアサインするのと同じ感覚で AI に任せられる構造です）。

🚀 インストールとセットアップ

Multica の利用フローは大きく 2 種類あります。

☁️ クラウド版を使う場合

multica.ai/app の Web UI にアカウントを作成し、ローカルマシンに CLI を入れて Daemon を起動するだけで、自分のマシンを Runtime として登録できます（Cloud のサインインフローは SPA で構成されており、ブラウザでクライアントサイドルーティングされる挙動です。curl で直接叩くと初回 HTTP 応答が 404 になることがあります）。

# macOS / Linux（Homebrew）
brew install multica-ai/tap/multica

# あるいはインストールスクリプト
curl -fsSL https://raw.githubusercontent.com/multica-ai/multica/main/scripts/install.sh | bash

# Windows（PowerShell）
irm https://raw.githubusercontent.com/multica-ai/multica/main/scripts/install.ps1 | iex

# 設定 → 認証 → Daemon 起動 を一気に行う
multica setup

multica setup は対話的に Multica Cloud のアカウントへログインし、ローカル Daemon をバックグラウンド起動します。Daemon は PATH 上の claude / codex / openclaw / opencode / hermes / gemini / pi / cursor-agent を自動検出し、利用可能な CLI のリストを Multica へ報告します（インストールされていない CLI は自動的にスキップされ、利用可能なものだけがリストに上がります）。

🏠 セルフホストする場合

社外に Issue 内容や生成コードを出したくない組織向けに、セルフホスト構成が用意されています。インストールスクリプトに --with-server を渡すと、ローカルでサーバ全体を立ち上げる構成にスイッチします。

curl -fsSL https://raw.githubusercontent.com/multica-ai/multica/main/scripts/install.sh \
  | bash -s -- --with-server
multica setup self-host

docker-compose.selfhost.yml を見ると、PostgreSQL（pgvector 入り）+ Go バックエンド + Next.js フロントエンドの 3 サービスが定義されています。docker-compose.selfhost.build.yml を併用すれば、GHCR のイメージではなく自分でビルドしたイメージで起動できます（GHCR 上の最新タグがまだ公開されていないタイミングがあって、その場合は make selfhost-build で自前ビルドにフォールバックする手順がリポジトリの Makefile に書かれています）。

セルフホストの詳細は SELF_HOSTING.md と SELF_HOSTING_ADVANCED.md に分かれていて、HTTPS 終端、リバースプロキシ、データベース外出し、AI モデルキーの注入方法などが含まれます。HTTPS 終端・リバースプロキシ・DB 外出しが章として明示的に分かれているため、SRE が見慣れた構成で組める情報の整理になっています。

⌨️ CLI の主要コマンド

Multica の CLI は、ローカルマシンと Multica（クラウド or セルフホスト）を結ぶエンドポイントです。よく使うコマンドを抜粋します。

コマンド	役割
multica login	ブラウザでの認証フローを開始
multica daemon start	ローカル Agent Daemon を起動
multica daemon status	Daemon の状態確認
multica setup	クラウド向けのワンコマンドセットアップ（設定 + ログイン + Daemon 起動）
multica setup self-host	セルフホスト向けのワンコマンドセットアップ
multica issue list	ワークスペース内の Issue 一覧
multica issue create	新規 Issue 作成
multica update	CLI 自体のアップデート

完全なコマンドリファレンスは CLI_AND_DAEMON.md にあって、ボードを開くまでもない作業（コマンドラインからの Issue 作成、Daemon ヘルスチェック、トークン管理など）はすべて CLI で完結できます。Issue の作成も CLI からできるのは、エディタから抜けたくない人には嬉しいポイントだと思います。

🧠 Skills システム — チームに知識が積み上がる仕組み

Multica の Skills は、過去のエージェント実行を再利用可能な手順としてカタログ化する仕組みです。

PostgreSQL の pgvector 拡張 がここで効いてきます。Skill には説明文・適用条件・ステップが付与されており、ベクトル化されたうえで保存されます。新しい Issue が立ち上がった際、過去の類似 Skill が意味検索でマッチングされ、エージェントへ初手の手順として供給される、という流れです。

skills-lock.json がリポジトリにコミットされていることから、Skill のバージョン管理も npm パッケージのような体験で行われていると読み取れます。チームメンバー間で同じバージョンの Skill を共有することで、「あの人のマシンでだけ動く Skill」のような環境差異を防いでいます（地味ですが、これがあると新メンバーがチームに入ったときの立ち上がりが速くなります）。

💡 Skill は 言語非依存ではない です。Claude Code 用に書いた Skill を Codex で呼び出すような使い方は想定されていません（CLI 固有のオプションや出力フォーマットがあるため）。ただし、概念としての手順自体は人間も読めるため、エージェントが入れ替わっても再利用しやすい設計になっています。

🏢 Multi-Workspace — 複数チームを 1 インスタンスで運用する

エンタープライズ運用や複数クライアントを抱えるエージェンシー向けに、ワークスペースごとに完全分離した運用ができます。

各ワークスペースは独立したエージェント定義・Issue・Skill・設定を持ち、メンバーシップとロールもワークスペース単位で管理されます。「クライアント A の Skill が、誤ってクライアント B のエージェント実行で参照される」事故が構造的に防がれている点が、エンタープライズ要件に対する回答になっています。コンサル/受託をやっているチームには、ここがいちばん刺さりそうです。

🆚 Multica と Paperclip の違い

公式 README には、隣接プロダクトである Paperclip との比較表が掲載されています。同じ「AI エージェントを管理するプラットフォーム」を名乗る場合でも、フォーカスがどう違うかを把握しておくと判断しやすくなります。以下は README の英語表を日本語訳したものです。

観点	Multica	Paperclip
フォーカス	チームによる AI エージェント協業プラットフォーム	ソロで AI エージェント会社をシミュレートする（solo company simulator）
ユーザーモデル	ロール・権限つきのマルチユーザーチーム	ボードオペレーター 1 人
エージェントとの対話	Issue + チャット会話	Issue + ハートビート
デプロイ前提	クラウドファースト	ローカルファースト
管理の深さ	軽量（Issues / Projects / Labels）	重めのガバナンス（組織図 / 承認 / 予算）
拡張性	Skills システム	Skills + Plugin システム

Multica は「人間 + AI のチームで、現実のプロジェクトを進める」ことに最適化されています。一方の Paperclip は「1 人の人間が AI エージェントを多数雇って会社運営をシミュレートする」というロールプレイ寄りの設計で、競合というより別の問題を解いているプロダクトと見るのが正確だと思います。

💼 ユースケース

実際にどう使うかを、典型例で整理します。

ユースケース 1：単発タスクの委譲

ユースケース 2：マルチ AI のリソースプール

異なる種類の Issue（バックエンド改修・UI 修正・調査タスク）を、それぞれ得意なエージェントへ振り分ける運用です。Multica は Runtime ごとに利用可能な CLI を把握しているため、たとえば「UI 修正は Cursor Agent」「バックエンドは Claude Code」「調査は Codex」のように、Issue のラベルに応じてアサインを切り替える運用が可能です。UI/バックエンド/調査タスクが入り混じる現場で「適材適所」を組み立てられる柔軟性は、導入時の大きな利点になります。

ユースケース 3：Skill を全社知識として育てる

「同じバグを 3 回直したらそれは Skill にする」という運用が現実的に効きます。Skill の検索・呼び出しコストが低いため、エージェントは過去の解決パターンを毎回ゼロから再発明せずに済みます（地味ですが、これがエージェントを「育てる」感覚につながります）。

🛠 開発と貢献

Multica の開発に参加する場合の前提は次のとおりです。

• Node.js v20 以上
• pnpm v10.28 以上
• Go v1.26 以上
• Docker

make dev

make dev は環境（メインチェックアウトか worktree か）を自動判別し、.env ファイル生成、依存関係のインストール、データベース起動、マイグレーション実行、全サービス起動までを一気に行います。

詳細は CONTRIBUTING.md にまとまっていて、worktree でのパラレル開発、テストの走らせ方、トラブルシューティングが記述されています。コントリビューションのハードルとしては、Go と Next.js の両方を読める人なら入りやすい構成だと思います。

⚖️ 評価と注意点

ここまで読んできた印象を率直にまとめます。

良いと思ったところ

• Issue ベースのメンタルモデル — 既存の Jira/Linear ユーザーがそのまま使える「タスクをアサインする」体験で、AI エージェントを管理できる
• マルチプロバイダ対応 — Claude Code 以外の 7 種類の CLI を同列に扱え、ベンダロックインが弱い
• セルフホスト前提の設計 — Apache License 2.0 をベースとする修正ライセンス（単一組織内利用は許諾済み）と、docker-compose.selfhost.yml 等の構成サンプルが整備されており、社内導入が現実的
• Skills が pgvector で検索される — 単なるテンプレートではなく、意味検索でマッチする「育つ知識ベース」として設計されている

注意したいところ

• エージェント実行は別マシン — Daemon を起動するマシンが必要です。CI 上で完結させたい場合は別途構成が必要
• CLI バイナリが PATH に必要 — claude、codex 等を Daemon 側マシンにインストールしないと、そのエージェントは利用できません
• Skill のバージョン管理は人間の責任 — skills-lock.json が同期されるとはいえ、Skill 内容自体を腐らせないためのレビューサイクルは別途必要
• 比較的新しいプロダクト — README が pgvector や Next.js 16 の採用を示唆するように、新興スタックを採用しているため、長期運用の知見はこれから蓄積されるフェーズです（社内導入する場合は、半年〜1 年単位での運用見直しを覚悟しておくと安全です）

💡 ライセンスは Apache License 2.0 の修正版で、商用ホスティング・組み込み利用と LOGO 保持に関する追加条件があります（単一組織内利用は許諾済み、第三者向け SaaS 化や OEM 組み込みは要商用ライセンス）。導入時はリポジトリ最新の LICENSE ファイルを必ず確認してください。

🎯 いつ使い、いつ使わないか

Multica が向くケース

• 複数の人間 + 複数のエージェントでプロジェクトを進めたい
• エージェントの成果を Issue として残し、追跡・レビューしたい
• セルフホストで社内のコードや会話を外に出したくない
• Skill を全社で共有し、エージェントを「育てる」運用をしたい

Multica を回さなくてよいケース

• 1 人の開発者が IDE 内で完結させる小規模な作業
• すでに Linear/Jira + 独自エージェント連携を高度にカスタマイズしている
• AI エージェントを使う頻度が週に数回以下で、単発のチャット UI で十分

判断軸は「エージェントを継続的にチームへ組み込み、Issue で追跡したいか」です。ここに Yes と答えられるなら、Multica は導入候補に入ります。

📝 まとめ

Multica を読んでみて、一番伝えたいのは「これは AI エージェント版の Linear / Jira だと思って読むと、急に納得感が出る」ということです。

「コーディングエージェントをチームメンバーとして運用したい」と思っている組織の数だけ、独自実装のオレオレ運用ボードが生まれかけているはずですが、Multica はそこにオープンソースで先回りした形になっています。技術スタック（Next.js 16 + Go + PostgreSQL/pgvector）も、社内 SRE が読みやすい組み合わせです。

社内導入時の現実的なステップは次の 4 つです。

1. クラウド版（multica.ai/app）でアカウントを作成し、Daemon をローカルに 1 台立ち上げて 1 つの Issue をエージェントに任せる
2. 試行が回り始めたら、Skill を 2〜3 個育てて全社で共有する
3. 機密性の要件が出てきたタイミングで docker-compose.selfhost.yml ベースのセルフホスト構成に切り替える
4. ワークスペースを案件単位に分割し、ロールと権限を整える

「コーディングエージェントを単発のツールから、追跡可能なチームメンバーへ昇格させる」ためのインフラとしては、現時点で Multica はかなり真面目な選択肢だと感じました。AI エージェントの利用頻度が「週に何度か」を超えてきたチームなら、検討する価値は十分あります。

📚 参考

• multica-ai/multica — GitHub — 本記事の主要参照元（README、CLI_AND_DAEMON.md、SELF_HOSTING.md ほか）
• Multica Cloud — クラウド版アプリケーション
• Multica Website
• Self-Hosting Guide
• Self-Hosting Advanced
• Contributing Guide