Multicaの紹介＋初心者ループエンジニアリング

はじめに

つい最近、ようやっとAI駆動開発に手を出し始めた者です！

Claude Code、Codex、Cursor。使えるエージェントは増えたのですが、増えるほどターミナルのタブも増えていきます。誰が何をやっていて、どこで止まっているのか、だんだん自分でも分からなくなってきました。

そこで見つけたのが Multica です。ひとことで言うと、コーディングエージェントをチームメンバーとして扱えるワークスペースです。

この記事では、まずMulticaの導入と機能をひととおり紹介して、最後に少しだけ、話題の「ループエンジニアリング」を試した話を書きます！

※記事中の仕様や数値は、2026年8月時点の公式ドキュメントに基づいています。

Multicaとは

Multica は、コーディングエージェントをチームメンバーとして扱うオープンソースのワークスペースです。
「次に採用する10人は、人間ではないかもしれません。」（原文は "Your next 10 hires won't be human."）という強めのキャッチフレーズを掲げています。

出典: Multica 公式サイト / Core concepts | Multica Docs

イシューがあって、カンバンボードがあって、コメント欄があって、担当者がいる。そこまでは見慣れたプロジェクト管理ツールなのですが、担当者の欄に人間だけでなくAIエージェントが並びます。

モデルを持たない

まず押さえておきたいのが、Multicaはモデルを持ちません。

すでにインストール済みのCLIを検出して駆動するだけで、Claude Code、Codex、Cursor など20種類以上（公式の比較表では23種類）に対応します。課金も認証も、いま使っているツールのものがそのまま使われるので、APIキーを取り直す必要も、使い慣れたツールを捨てる必要もありません。

出典: AI coding tools comparison | Multica Docs / Install AI coding tools | Multica Docs

おかげで、プロバイダーの切り替えが移行ではなくドロップダウンで済みます。このエージェントはClaude Code、あっちはCodex、という混在も普通に組めます。これは後半のスクワッドの話につながります。

どこまでがローカルで、どこからがサーバーか

自分のマシンでコードを書かせるので、どこに何が置かれるのかは最初に確認しておきたいところです。

置かれる場所	中身
ローカル	コード、ツールの認証情報、実際の実行
サーバー	イシュー、コメント、エージェント設定、実行記録

コードもツールの認証情報も手元に残り、サーバーが持つのは調整と記録の層だけ、という切り分けです。公式の言い方だと「Multica records and coordinates the work; connected computers execute it.」となっています。

出典: How Multica works | Multica Docs

ただし例外がひとつあって、エージェントのカスタム環境変数（custom_env）はサーバーのDBに平文で保存され、実行時にランタイムへ渡されます。閲覧できるのはワークスペースのオーナーと管理者だけで、アクセスは監査記録に残る仕組みですが、ドキュメント自身が「本番の認証情報は置かず、権限を絞ったキーを使うこと」と警告しています。「ローカル実行だから全部手元」と読み替えるのは危ないところです。

出典: Create and configure an agent | Multica Docs / Security model | Multica Docs

セルフホストもできる

サーバー側に何が置かれるかが気になる場合、そのサーバーごと自分で持ってしまう手もあります。Multicaはオープンソースなので、まるごと自前のインフラに立てられます。

一番手軽なのは Docker Compose で、make selfhost でサービスを起動して、あとは各マシンをCLIで繋ぐだけです。Kubernetes に載せたい場合は Helm チャートも用意されています。

用意するものはこれくらいです。

• Docker Engine もしくは Docker Desktop（docker compose v2 が必須。旧 docker-compose v1 は非対応）
• Git、Make、curl、OpenSSL
• ポート 3000 と 8080

出典: Self-host quickstart | Multica Docs

中身は Go ＋ PostgreSQL 17（pgvector）＋ Next.js 16 という構成です。連携先のGitホスティングも GitHub / GitLab / Gitea / Forgejo に対応していて、こちらもセルフホストしたものを指定できます。

ライセンスは Apache License 2.0 をベースに、ホスティングサービス・商用組み込み・ブランディングについての条項を足した独自の「Multica License」です。社内で立てて使う分には問題なさそうですが、これを再販するような使い方をするなら原文を読んでおいたほうがよさそうです。

出典: multica-ai/multica | GitHub / Self-hosted Git providers | Multica Docs

導入とランタイム設定

クラウド版を使う場合、自分のマシンでやることは2つのコマンドだけです（macOS / Linux）。

curl -fsSL https://raw.githubusercontent.com/multica-ai/multica/main/scripts/install.sh | bash
multica setup

1行目でMultica CLIが入り、multica setup を実行するとブラウザが開いてサインインが完了し、そのままデーモンがバックグラウンドで動き続けます。デスクトップアプリ（Multica Desktop）を使う場合は、アプリがデーモンを自動で起動してくれます。

出典: Quickstart | Multica Docs

デーモンは起動すると PATH 上のコーディングツールを検出し、ランタイムとして登録してくれます。検出は起動時に走るので、あとからツールを入れた場合は multica daemon restart で再起動が要ります。デーモンは15秒ごとにハートビートを送っていて、落ちるとおよそ3分以内にオフライン表示へ変わります。状態は multica daemon status で確認できます。

出典: Daemon and runtimes | Multica Docs

エージェント・スクワッド

突然ですが我らがAIメンバー（エージェント）を紹介するぜー！

バッファロー！

カエルー！

イカー！

ショーン！

全員揃って「AIチーム」！（スクワッド）

……と、こんなふうに愛着の湧くエージェントを作成できます。

エージェントは、ランタイム（どのCLIを使うか）、権限、指示を束ねた単位です。Access は「自分のみ / ワークスペース全体 / 特定メンバー」から選べます。変更できるのは作成者だけで、ワークスペースの管理者でも上書きできないのが特徴です。

出典: Create and configure an agent | Multica Docs / Members and roles | Multica Docs

そしてタスクにはエージェント・スクワッド・人間を割り当てます。
エージェント単体でももちろん進めてくれますが、スクワッドにすると、適したエージェントへの作業の割り振りなどを進めてくれて便利です。

スクワッドはリーダーエージェントが1体いて、その下にメンバーが並ぶ構成です。メンバーにはエージェントだけでなく人間も入れられます。イシューをスクワッドに割り当てても全員が一斉に動くわけではなく、まずリーダーだけが起動し、内容を読んで担当を決め、@メンション付きのコメントで委任します。委任されたメンバーが返してくると、リーダーが再評価して次を委任するか、ゴールに達していればイシューを レビュー中 に移します。並列実行は自動ではありませんが、リーダーが1つのコメントで複数人に同時委任できます。

出典: Squads | Multica Docs

ここで、さきほどのドロップダウンが効いてきます。エージェントは1体ずつランタイム（＝どのマシンのどのCLIか）を選ぶ作りなので、スクワッドの中でエージェントごとにプロバイダーを変えられます。実装はClaude Code、レビューはCodex、という組み方ができるわけです。

出典: Create and configure an agent | Multica Docs / Squads | Multica Docs

これが大事なところで、生成と評価を同じモデルにやらせないための構造になっています。答案を書いた人が採点すれば甘くなります。同じモデルが自分の出力を評価すれば、同じバイアスが乗ります。実装担当とレビュー担当を別プロバイダーにできるというのは、それをワークスペース側で解いているということです。

イシューとタスク

最初にややこしい点をひとつ。画面のサイドバーで「タスク」と表示されているのは、英語版では「Issues」、つまりこの節でいうイシューです。以下では、ボードに並ぶカードを「イシュー」、エージェントの1回の実行を「タスク」と呼び分けます。

エージェントを作ってイシューを割り当てると、カンバンボードでカードが動き始めます。
AIを並行稼働しているときは、この見やすいボードが便利です。

イシューは バックログ → 未着手 → 進行中 → レビュー中 → 完了 と遷移します（ほかに ブロック中 と キャンセル）。ひとつ注意点があって、バックログ にいる間はエージェントが動きません。担当に割り当てても、未着手 に動かして初めてタスクが生まれます。

そして裏側で走るタスクのほうは、queued → dispatched → running → completed / failed という別の状態を持っていて、その全部が記録されます。エージェントが行き詰まったときは agent_blocked という失敗理由で自ら報告するので、何時間も経ってから何も進んでいなかったと気づく事故が起きにくくなっています。

出典: Issues | Multica Docs / Tasks | Multica Docs / Put agents to work | Multica Docs

もうひとつ、イシューとタスクが別物なのがポイントです。ドキュメントの言い方だと「イシューはゴール・議論・担当・最終ステータスを持ち、タスクはエージェントの1回の実行を記録する」もので、リトライや担当替えのたびに1つのイシューに複数のタスクが積み上がっていきます。イシューを開けば、これまでどのエージェントが何回走って何を報告したのかが時系列で読めます。

出典: Tasks | Multica Docs

人間とエージェントのカードが同じボードに並ぶので、「AIに任せているタスク」と「自分が持っているタスク」を別のツールで管理しなくて済むのも良いところです。ビューはボードのほかにリスト・テーブル・ガント・スイムレーンがあります。

GitHub連携を入れておくと、イシューに紐づいたPRの状態（Open / Draft / Merged / Closed）とCIの結果がイシュー側に表示されます。ブランチ名やPRタイトルにイシュー識別子が入っていれば自動で紐づきます。

出典: Issues | Multica Docs / GitHub integration | Multica Docs

オートパイロット

オートパイロットは、人間が割り当てなくてもエージェントを起動させる仕組みです。スケジュール（5フィールドのcron記法＋IANAタイムゾーン）またはWebhook（JSONで最大256KiB）で発火し、Runbookに書いた手順をエージェントに実行させます。Runbookには「毎回エージェントが読む、ゴール・背景・制約・手順」を書きます。

ちなみにエージェントを動かす方法はオートパイロットのほかに、イシューの割り当て・コメントでの@メンション・ダイレクトチャットがあります。

出典: Autopilots | Multica Docs / Put agents to work | Multica Docs

出力モードが2つあって、無人で動かすときはこの違いが結果を大きく左右します。

出力モード	挙動
イシューを作成	先にイシューを作ってエージェントに割り当てる。ランタイムがオフラインでもイシューは残り、タスクはキューで待つ
実行のみ	イシューを作らずタスクを直接作る。ランタイムが無ければ実行は「スキップ」と表示され、待機イシューも残らない

朝起きて何も起きていなかった、という事故はだいたい後者から生まれます。夜間に走らせるなら「イシューを作成」を選んでおくのが無難です。

出典: Autopilots | Multica Docs

そしてもうひとつ、見落としやすいけれど大事な利点があります。定期スケジュール実行の強みは、毎回まっさらなセッションで始まることです。同じセッションで動かし続けるとコンテキストが膨張して序盤の指示を見失いますが、毎回起動し直せば膨らみません。代わりに前回の状態が失われるので、記憶をコンテキストウィンドウの外（ファイルやチケット）に置け、というのが定石になります。

Multicaでこれを読むと、その「外」がイシューになっています。毎回新しいタスク＝新しいセッションを起動しながら、議論と状態はイシューに残る。さきほどの「1つのイシューに複数のタスクが積み上がる」構造が、ここで活きてきます。コンテキスト膨張対策が、プロダクトの構造として実装されているわけです。（ここは私の解釈です）

上限とリトライ

自分のマシンで長時間エージェントを走らせるので、止める側の作りも見ておきました。

• 同時実行上限：デフォルトで「1つのデーモンは同時に最大20タスク、各エージェントは最大6タスク」。小さいほうが実効値になります。エージェント設定と MULTICA_DAEMON_MAX_CONCURRENT_TASKS で変更できます
• タイムアウトと反復上限：デーモンの agent_timeout、上限に当たると iteration_limit という理由で失敗します
• 自動リトライ：インフラ起因の失敗はデフォルト最大2回、ツールのネットワーク中断は最大3回まで自動で再試行されます
• 記録：実行ログとイシューのタイムラインに逐次流れます。Usage画面ではエラー傾向・失敗の種類・手のかかっているエージェントが見られます

出典: Daemon and runtimes | Multica Docs / Tasks | Multica Docs

コスト爆増と、詰まった状態でトークンを垂れ流し続ける事故。この2つが最初に心配だったので、デフォルトで上限が入っているのは安心材料でした。ただしこれは実行の回数や時間の上限で、金額やトークン量の上限ではありません。お金の上限は、各CLIやプロバイダー側の設定で掛けておく必要があります。

また、全部が自動で拾われるわけではありません。認証エラー・クォータの使い切り・設定ミスといったエージェント側のエラー（agent_error.*）は自動リトライの対象外で、原因を解消してから手動でリトライする分類になっています。インフラ障害は拾ってくれますが、クォータ切れは拾いません。

出典: Tasks | Multica Docs

そのほか、ドキュメントを読んで気をつけたいと思ったところです。

• キューは2時間で失効する。誰にも取られないまま2時間を超えたタスクは queued_expired として失敗で終わります
• 並列実行はディレクトリを取り合う。作業ディレクトリは ~/multica_workspaces/ 配下にタスクごとに切られますが、ロックの取り合いになると waiting_local_directory で待たされます
• 完了はゴールではない。ドキュメントにも「Completedは1回の実行サイクルが終わったことを示すのであって、イシューの作業が解決したとは限らない」と明記されています
• サンドボックスではない。タスクはデーモンを動かしているOSユーザーの権限そのままで動きます。ファイルシステムの分離はセキュリティ保証として提供されていないので、専用ユーザーやコンテナで囲うのは利用者側の責任です

出典: Tasks | Multica Docs / How Multica works | Multica Docs / Security model | Multica Docs

---

ここまでがMulticaの機能紹介です。ここからは少しだけ、実際に何を回してみたかを書きます！

少しだけ、ループエンジニアリングを試す

ループエンジニアリングとは

新参者の理解ですが、次の一手を出す役を人間からシステムに移す設計です。「タスクを見つける → 実行する → 検証する → ダメなら直す → 次を決める」を、人間ではなくシステム自身が回します。

A→B→Cと一方向に受け渡して終わる流れは、リレー（パイプライン）であってループではありません。そして人間が要所でレビューして「次はこれをやって」と返す形も、バトンを人間が渡し続けているのでリレーです。

プロンプトに「3回検証ループを回して」と書けば、それでループになるわけではありません。

• 3回目なら良い、という確証がない
• 「検証」という言葉が曖昧で、AIの認識が都度変わる
• 失敗するテストの実行を、AIが避けている可能性もある

ちゃんとやるなら、起動条件・作業範囲・権限・完了判定・予算・停止条件・記録を決めておく必要があります（loop contract と呼ばれるやつです）。自分で組むと全部自前になる部分ですが、Multicaの機能に対応づけるとこうなりました。

loop contract	Multicaでの実装
Trigger（起動条件）	オートパイロット（スケジュール / Webhook）、割り当て、@メンション
Scope（作業範囲）	プロジェクトに紐づけたリポジトリ、ローカル作業ディレクトリ
Permission（権限）	エージェントのAccess（自分のみ / 特定メンバー / ワークスペース全体）、ロール
Verification gate（完了判定）	レビュー列、PRのCI状態表示、スクワッドのレビュー担当
Budget（予算）	同時実行上限（デーモン20 / エージェント6）、agent_timeout、iteration_limit（※金額の上限は無し）
Stop / Escalation（停止）	agent_blocked（行き詰まりの自己報告）、Inbox通知
Reporting（記録）	実行ログ、イシューのタイムライン、Usage（エラー傾向・失敗の種類）

Budgetだけは実行量の上限でお金の上限ではありませんが、それ以外の項目にはだいたい置き場があります。たいへんそうだと思っていた部分が、だいたい設定画面になっていました。

出典: Autopilots / Create and configure an agent / Squads / Daemon and runtimes / Tasks / Inbox and subscriptions

実際に回したループ

最初の実践として、ひとつの機能追加をスクワッドに丸ごと投げてみました。組んだ構成はこうです。

役割	ランタイム	担当
PMエージェント（リーダー）	Claude Code	要件をサブタスクに分解し、担当を決め、差し戻しを判断する
実装エージェント	Claude Code	コードを書く
レビューエージェント	Codex	実装を評価し、通すか差し戻すかを返す

実装はClaude Code、レビューはCodexと分けているので、前半で書いた「生成と評価を同じモデルにやらせない」形になっています。

実際のコメント欄では、PMが実装とレビューのあいだに立ち、結果を受け取るたびに次の担当へ指示を出していました。人間が割り当てたのは最初のイシューだけです。

指示は簡素ですが、各エージェントには指示文が書いてあるので、ちゃんと動いてくれます。

会話だけに縮めると、こんなやり取りです。

PM「#19を既存設計に沿って実装し、再現できる検証結果を添えてください」
実装「PR #48を作成しました。テストは通り、25,000件のデータでの性能も基準内です」
QA「まだ受入不可です。本番DBへの安全策と、実ルートを通した検証が足りません」
PM「指摘の4点を修正し、結果をそろえてもう一度レビューへ回してください」
実装「安全策と不足テストを追加し、CIを含めて再検証しました」
QA「全項目を確認しました。残る注意点は手順化されているため、受入可です」

流れとしては、PM → 実装 → レビュー、と進んで、レビューが差し戻したら実装に戻ります。通るまでこの区間を往復して、通ったらPMが仕上げて完了になります。

イシューを割り当てたあと、最後のPRレビューまで、私がやったことは何もありません。ボードを眺めていただけです。

もし私がレビュー結果を読んで「ここ直して」と打ち直していたら、それはリレーでした。バトンを渡しているのが人間だからです。次の一手を出す役がシステムに移っている以上、これはループだと判断しました。

まだ使用して日が浅いのでチュートリアル程度のループですが、慣れれば洗練されたループを維持できるようになると思います。

ハーネスを育てるループ

次に組んだのが、週に一度、Claude Codeの履歴を参照して CLAUDE.md とスキルを更新するオートパイロットです。
参考にしたのはこちらのYouTube動画（「保存版」5分で実践！超簡単ループエンジニアリング／ギリギリ開発会議 by ボイスアップラボ）です。
https://www.youtube.com/watch?v=ifAt7nkaTww&t=1135s

これはコードを書くループではありません。他のループが走る環境（ハーネス）を改善するループで、いわばメタなループになります。CLAUDE.mdとスキルはすべての実行が毎回読み込む前提なので、そこを自動で育てれば、他のすべてのループの精度も上がっていくはずです。

履歴の読み方は単純です。デーモンは自分のマシン上で、自分のOSユーザーの権限で動くので、エージェントはローカルの ~/.claude/ 配下にあるClaude Codeの履歴をそのまま読めます。裏を返せば、手元のプロンプト履歴をエージェントに読ませているということなので、履歴に機密情報が混ざっていないかは気にしておきたいところです。

設定はこうしました。

• トリガー：スケジュール（週1）
• 出力モード：イシューを作成
• Runbook：直近1週間のプロンプト履歴を読み、繰り返し・過介入・催促のパターンを抽出させる
• 反映方法：エージェントにPRを出させ、マージは自分がやる

ポイントは最後の2つです。

まず、抽出したパターンをそのまま全部ループ化しません。同じ指示を繰り返してしまう原因は一つではないからです。

繰り返しの原因	効く打ち手
本当に反復的な定型作業	ループ化・スキル化
AIが毎回ズレて同じダメ出しをさせられている	ルールファイル（CLAUDE.md）の整備
一度きりの判断・探索	自動化しない（人間判断で残す）

この切り分けまで含めて提案させています。つまりこれは「ループ化すべきかどうかを判定するループ」です。

そして書き込みはPR経由にしました。CLAUDE.mdはこれ以降の全実行に効くファイルで、毎週エージェントが直接追記していけば、確実に膨らみますし、古いルールと新しいルールが矛盾し始めます。「改善」が積み上がってノイズになる、という失敗の形です。人間はループの外側で、ゴールと止め方と例外判断を持つ。定義に忠実な形に落ち着きました。

組んだばかりなので、これが半年後にどうなっているかはまだ分かりません。次に足すつもりなのは Reporting で、CLAUDE.mdの行数とスキル数を毎回記録させたいと考えています。膨張が数字で見えれば、削る判断ができます。

おわりに

Multicaを触ってみて一番良かったのは、エージェントの仕事に置き場ができたことでした。

誰が何を持っていて、どこで詰まって、何回やり直したのか。CLIを直接叩いていたときは自分の頭とシェルの履歴にしかなかった情報が、ボードとイシューと実行記録に出てきます。モデルを持たないので、いま使っているCLIをそのまま載せられるのも入りやすいところでした。

そしておまけで手を出したループエンジニアリングですが、「たいへんそう」の正体は、ループそのものではなく置き場がなかったことでした。置き場さえあれば、あとは設定するだけです。

ぜひ「Multica×ループエンジニアリング」試してみてください！！