完全ガイド
空のワークスペースから始めて、個人サイトのプロジェクトで Multica のコアフローを一通り実践します。エージェントの作成、イシューによる成果物の提供、スクワッドの編成、スキルの蓄積、自動化の設定を扱います。
Multica は、人と AI エージェントが一緒に働くためのプラットフォームです。このガイドではゼロから始めて、次のことを行います。
- 自分のワークスペースを構築する
- 人とエージェントの協働、そしてエージェント同士の自動的な協働を実現する
- 繰り返しの作業を自動化に任せる
- 有効なやり方をスキルとして蓄積し、エージェントを継続的に改善する
このガイドでは個人サイトをサンプルプロジェクトとして、Multica の全体の流れとコア機能を一通り確認します。
始める前に必要なもの：
- Multica のアカウント（multica.ai で登録）
- Claude Code や Codex など、AI コーディングツールを少なくとも 1 つインストールしてログイン済みのコンピュータ。対応ツールの一覧はAI コーディングツールをインストールするを参照してください
ワークスペースを作成する
ワークスペースはチームが仕事をする場所です。イシュー、プロジェクト、エージェントはいずれかのワークスペースに属します。登録後のガイドに従って最初のワークスペースを作成できます。チームに招待された場合は、ログインするとそのチームのワークスペースに直接入ります。
このガイドでは新しいワークスペースを作成して説明します。サイドバー上部のワークスペース名をクリックし、ワークスペースを作成 を選択します。
作成時に入力する項目は 2 つです。
- ワークスペース名：メンバーに表示される名前です。後から変更できます。
- ワークスペースURL：ワークスペースのアドレスに使う slug です。たとえば
multica.ai/my-teamのmy-teamの部分で、作成後は変更できません。
作成が完了すると新しいワークスペースに入ります。左側がサイドバーで、以降の操作はすべてここから始めます。中央のイシュー一覧はまだ空です。これからの数ステップで、エージェントにここを埋めてもらいます。
コンピュータを接続する
エージェントは接続したコンピュータ上で作業を実行します。使うのは、そのコンピュータにインストールされている AI コーディングツールです。
このガイドでは Multica Desktop を使って説明します。ダウンロードしてログインすると、このコンピュータが自動的にランタイムとして登録され、インストール済みの AI コーディングツールが検出されます。サイドバー下部の 設定 → ランタイム を開き、このコンピュータがオンラインになっていることを確認します。
このコンピュータを開くと、検出されたツールを 1 つずつ確認できます。
Desktop を使わない方法もあります。ランタイムのページで コンピュータを追加 をクリックし、案内に従ってコマンドラインからインストールすると、デーモンがバックグラウンドで常駐します。詳しくはデーモンとランタイムを参照してください。
最初のエージェントを作成する
エージェントはワークスペースの正式なメンバーです。イシューを割り当てたり、コメントを書いたり、あなたと会話したりできます。最初のエージェントとして、ワークスペース内の日常業務を担当する helper を作成します。このガイドの以降の操作の多くは、このエージェントに任せます。
サイドバーの エージェント を開き、新規エージェント をクリックして 空白から始める を選び、3 つの項目を入力します。
- 名前：
Multica helper。 - ランタイム と モデル：前のステップで接続したコンピュータと AI コーディングツールを選び、そのツールが対応するモデルから 1 つ選びます。このガイドでは Claude と Sonnet を使います。
- 指示：実行のたびにエージェントへ渡されるプロンプトです。何を担当し、何を担当しないかを明確に書きます。
You are the helper of this workspace.
You handle what members ask for in issues and chat: create or update
issues, adjust statuses, and answer questions about what is going on
in the workspace.
Keep replies short. After finishing something, reply with a one-line
summary of what you did. Do not touch code or repositories. If a
request is ambiguous, ask before acting.
残りの項目はデフォルトのまま、作成をクリックします。エージェント ページに戻ると、Multica helper はすでにオンラインで、仕事を受けられる状態です。
2 体目のエージェント：チャットで作成する
サイトを作るには、コードを書けるエンジニアが必要です。今回はフォームを入力しません。ワークスペースにはすでにエージェントが 1 体いるので、作成そのものを任せられます。
サイドバーの チャット を開き、Multica helper を選んで指示します。同じランタイム上に Engineer という名前のエージェントを作成し、モデルは Opus、担当は個人サイトの構築と保守、という内容です。Multica helper はこのコンピュータ上で作成を実行し、新しいエージェントの名前とモデルを返します。新しいエージェントは、デフォルトでは作成者だけが実行できます。このガイドではデフォルトのままで構いません。
エージェント → Engineer を開いて結果を確認します。モデルは Opus で、指示は Multica helper が生成しています。職責の範囲、リポジトリのコードを取得する方法、変更を提出するときの要件が含まれ、後からいつでも変更できます。
サイトのリポジトリを用意する
サイトのコードは GitHub リポジトリに置きます。リポジトリの作成と紐づけも同じくエージェントに任せます。前提として、このコンピュータに GitHub CLI がインストールされ、ログイン済みである必要があります。
チャット で Engineer を選び、次のように指示します。自分の GitHub アカウントに personal-website という名前の空のリポジトリを作成し（このコンピュータには GitHub CLI があります）、multica repo add でこのワークスペースに登録する、という内容です。Engineer はローカルにリポジトリを作成し、ワークスペースに登録して、リポジトリのアドレスを返します。メッセージで公開範囲を指定していないため、Engineer はデフォルトのまま作成し、その内容を返信で説明します。公開でも非公開でも、以降のステップには影響しません。
設定 → リポジトリ を開いて確認します。personal-website がすでに一覧に入っています。以降、エージェントがタスクを実行するときは、ここからリポジトリを選びます。
GitHub CLI を使わない場合は、自分で GitHub にリポジトリを作成し、同じページで手動で追加しても結果は同じです。
最後に同じページで GitHub に接続 をクリックし、案内に従ってこのリポジトリを許可します。接続すると、イシュー番号を参照した pull request が対応するイシューへ自動で紐づき、PR のステータスと CI の結果がイシュー内に直接表示されます。
最初のイシュー：サイトを作る
設定はここまでですべて完了です。ここからは Multica の日常的な進め方になります。要件をイシューとして書き、エージェントに実行させます。
サイトはゼロから組み立てるのではなく、shadcn の公式テンプレートから始めます。テンプレートには技術スタックと基本設定が含まれているため、Engineer はその上で内容とデザインを作ります。
サイドバー上部の 新規イシュー をクリックします（ショートカットは C）。デフォルトのエージェントモードでは、タイトルを入力する必要はありません。作成者 で Engineer を選び、要件をそのまま説明に書くと、タイトルは作成時に自動生成されます。手動モードに切り替えて、タイトルと内容を自分で記入することもできます。説明は次のとおりです。
Work in the personal-website repository registered in this workspace.
Start from a template instead of scaffolding from scratch:
pnpm dlx shadcn@latest init --preset b5rR41Mtnc --template next --pointer
Run the command, commit the template as-is, then build on top of it.
The site is for a photographer. It needs:
- Introduction — who I am and what I shoot
- My work — a selection of photos
- Contact — an email link that is easy to find
- Pricing — decide where a pricing table fits and how to present it
- Use placeholder images (Unsplash or picsum.photos) wherever a photo
belongs, and list where I should replace them with my own work
Design:
- Pick a style that fits a photography portfolio. It should feel
refined and understated; express that through layout, typography
and spacing, and never use words like "premium" or "high-end"
in the copy.
- Choose the fonts.
Open a pull request when it is ready.この説明には 3 種類の情報が含まれています。制約（指定したテンプレートから始める）、内容の要件（項目ごとに列挙）、余白（スタイルの検討は Engineer に任せる）です。要件には意図と境界を書き、実現方法はエージェントに任せます。
送信すると、Multica がイシューを作成し（番号は MUL-1、タイトルは自動生成）、Engineer を担当者に設定します。Engineer はすぐに実行を開始し、ステータスが進行中に変わります。イシューの右側には、そのイシューのすべての動きが表示されます。ステータス、担当者、紐づいた pull request、実行ログです。
実行には数分かかります。進捗を見る入口は 2 つあります。タイトル横の作業ステータスのバッジと、右側の 実行ログ です。現在の実行を開きます。
実行ログには、この実行の一つひとつのステップが記録されています。Agent の行はエージェントの説明、Bash、Read、Edit は実行したコマンドと読み書きしたファイルです。このスクリーンショットの時点では、Engineer は作成したページのスクリーンショットを撮って自己確認しており、価格表の区切り線がそろっていないことに気づいたところです。右上の ⓘ をクリックすると、この実行で使ったコンピュータ、AI コーディングツール、作業ディレクトリを確認できます。
受け入れ確認：イシュー内で対話する
実行が終わると、Engineer はステータスをレビュー中に変更し、通知がインボックスに届きます。Engineer はイシューに完了コメントを書き、作成したページのスクリーンショットを添えています。
スクリーンショットでおおよそは分かりますが、受け入れ確認はブラウザで開いて行います。サイトはあなたのコンピュータ上でビルドされているので、Engineer にローカルサーバーを起動させればアクセスできます。また、右側の Pull requests の領域はまだ空です。イシューでは PR の提出を明確に求めていたので、この点もそのまま質問します。
今回はコメント欄を使いません。画面右下にチャットボタンがあり、ワークスペースのどのページからでも開けます。サイドバーの チャット と同じ機能です。
開いたら Engineer を選び、@ を入力して現在のイシューを参照します。会話にこのイシューのコンテキストが加わるので、先ほどの 2 点をそのまま送ります。
Engineer の返信は 2 つに分かれます。1 つは、ローカルサーバーを起動してアクセス用のアドレスを提示したこと。もう 1 つは、PR は実際にはすでに提出されているものの、タイトル、ブランチ名、本文のいずれにも MUL-1 がなく、自動の紐づけが一致しなかったことです。その後、Engineer は PR のタイトルに番号を追加しました。
提示されたアドレスをブラウザで開くと、サイトが表示されます。
イシューに戻ると、右側の Pull requests の領域にも PR カードが現れ、ステータスと変更の規模が表示されます。クリックすると GitHub 上の PR が直接開きます。CI を設定したリポジトリでは、check の結果も表示されます。
フィードバックを指示に書き込む
今回の受け入れ確認で、Engineer の 2 つの作業習慣が見えました。1 つは、完了後に何度もスクリーンショットを撮って自己確認し、実行時間をかなり使うこと。もう 1 つは、PR を提出するときにイシュー番号を付けず、紐づかないことです。どちらも今回だけの偶発的なミスではなく、毎回繰り返される進め方です。直すべきなのはこのイシューではなく、Engineer の指示です。
指示を自分で書き換える必要はありません。エージェントは multica CLI で自分の設定を更新できます。先ほどの会話を続けて、Engineer に 2 つのルールを伝えます。完了後にスクリーンショットでの自己確認は不要で、受け入れ確認はブラウザで行うこと。PR のブランチ名かタイトルに必ずイシュー番号を入れること。そのうえで、自分の指示に書き込むよう依頼します。
Engineer は multica agent update で更新を行い、指示に作業ルールのセクションを追加しました。あわせて 1 つ目のルールの代償も指摘しています。スクリーンショットでの自己確認をやめるため、ページ上の見た目の問題はあなたがブラウザで見つける必要があります。
エージェント → Engineer を開くと、指示にこの 2 つが追加されています。
以降の実行では、この 2 つのルールが指示とともに毎回適用されます。これがエージェントを調整する基本の方法です。繰り返し起きる問題を見つけたら、毎回口頭で注意するのではなく、修正内容を指示に書き込みます。
3 体目のエージェント：Reviewer
Engineer は最初の版を提出しましたが、自分では気づけない問題もあります。レビューは新しいエージェントに任せます。まっさらなコンテキストで、イシューの要件と照らし合わせてコードの品質を確認する役割です。
作成はやはり Multica helper に任せます。Reviewer という名前のエージェントで、今回は Codex と GPT-5.6 Sol モデルを選び、Engineer が使うツールともモデルとも別にします。レビューだけを行ってコードは変更せず、結論はイシューのコメントとして書きます。指示は今回も helper が生成します。PR の実際の状態を読んでからレビューする、指摘はファイルの位置を添えてコメントに書く、コードは決して変更しない、という内容です。
レビューのために新しいイシューを作る必要も、担当者を変える必要もありません。MUL-1 のコメント欄に戻り、@Reviewer と入力して @メンションし、やってほしいことを書いて送信します。コメント欄の下には、送信すると Reviewer が実行を開始する旨が表示されます。
数分後、レビューのコメントが返ってきました。結論は、マージ前に修正が必要というものです。5 件の指摘は 2 つのグループに分かれます。コーディング規約が 3 件、要件との適合が 2 件で、それぞれにファイルと行番号が付いています。要件との適合の 2 件は、まさに Engineer 自身が気づけなかった問題です。価格表が架空の価格、手付金、税務条項を正式な内容として表示していて、未定であることを示す注記がまったくないこと。連絡先に、確認していない Instagram のリンクが置かれていることです。コメントの末尾では、自分が検証した範囲も説明しています。typecheck、lint、build はいずれも通過しました。
修正にも新しい手順は不要です。コメント欄で @Engineer し、指摘された問題をすべて直すよう伝えます。送信すると Engineer はすぐに実行を開始し、タイトル横のバッジと右側の実行ログの両方で確認できます。
数分後、Engineer が報告します。5 件すべてを修正し、同じ PR に反映しました。両者は同じタイムラインを共有しているため、報告は指摘に対して 1 件ずつ結果を述べるだけで済み、背景を繰り返す必要はありません。
もう一度 Reviewer を @メンションして再確認してもらいます。結論は、5 件の指摘はすべて解消されマージ可能、残るのは優先度の低い今後の提案が 2 件、というものです。
開発とレビューはこのように往復します。問題を見つけ、問題を直し、1 周ごとにサイトの定義が少しずつ確かになります。1 つのイシューに 2 体のエージェントがいて、Engineer が実装し、Reviewer がレビューします。あなたは短いコメントを数件書くだけで、このサイクル全体を動かせます。
マージして仕上げる
マージも同じくコメント 1 件で指示します。Engineer に PR をマージし、イシューを確実に完了へ移すよう伝えます。Engineer はマージし、ブランチを削除し、マージ後の main でチェックを再実行してから報告します。イシューのステータスは完了になり、インボックスに完了通知が届きます。
最初のイシューはここで一周しました。要件の記述からマージによる反映まで、実装、レビュー、修正、受け入れ確認、マージのすべてが同じタイムラインに記録されています。
スクワッドを編成する
MUL-1 のサイクルは一通り回りましたが、つなぎ目はすべてあなたが起こしていました。受け入れ確認のあとに Reviewer を @メンションし、レビューのあとに Engineer を @メンションする。調整そのものがあなたの仕事になっていました。この層の仕事も任せます。Multica がそのために用意している組織の形が スクワッド（squad）です。エージェントとメンバーに名前を付けた集合で、1 体のリーダーエージェントが率います。イシューをスクワッドに割り当てると、受け取るのはリーダーです。イシューを読み、仕事を振り分け、ステータスを進めます。メンバーから返信があるとリーダーは自動的に起こされ、次のステップを決めます。仕上げには、あなたへ成果物を報告します。リーダーが引き受けるのは、まさに先ほどまでのあなたの役割です。
スクワッドは、すでにある分担にリーダーを 1 体加えたものです。
- Lead（新規作成）：リーダーです。管理を担当し、タスクの割り振り、イシューのステータスの更新、あなたへの成果物の報告を行い、自分では手を動かしません。
- Engineer（既存）：開発を担当します。
- Reviewer（既存）：すべての PR をレビューします。
- あなた：最終的な受け入れ確認を行います。
メンバーはエージェントに限りません。各メンバーには 1 行のロールの説明が付き、リーダーが仕事を振り分けるときに参考にします。
この構成は Multica helper に説明するだけで済みます。スクワッドとリーダーを作成し、メンバーにそれぞれの職責を持たせ、Lead と Engineer にスキルを 1 つずつ紐づけ（次のセクションで説明します）、スクワッドの指示にワークフローを書きます。開発は Engineer に振る、PR がレビューを通ってから提出する、あなたの受け入れ確認のあとに Engineer がマージする、という内容です。helper は CLI で設定を一度にすべて完了します。
サイドバーの スクワッド → Website Team を開いて結果を確認します。リーダー、メンバー、ロールの説明がそろっています。スクワッドはこのページのフォームからも作成できます。仕組みの全体はスクワッドのドキュメントを参照してください。
スキル：再利用できる方法
先ほどフィードバックを指示に書き込んだのは、1 体のエージェントの問題を解決するためでした。指示はそのエージェントだけのものです。1 つの方法を複数のエージェントで共有したい場合や、ほかの人がすでに書いた方法をそのまま借りたい場合は、スキルを使います。
スキルはエージェントのための知識パッケージです。1 つの SKILL.md と任意の補助ファイルで構成され、ある種類の仕事に対してどう考え、どう進めるかをエージェントに伝えます。Multica は Anthropic Agent Skills のオープン標準を採用しており、仕様に沿ったスキルはそのままインポートできます。エージェントに紐づけると、実行時に自動でランタイムへ同期されます。スキル ページを開くと、先ほどインポートした 2 つが表示され、右側にはそれぞれ紐づいたエージェントが並びます。
開くと、スキルのすべてのファイルを確認できます。
この 2 つのスキルは、一方が進め方を、もう一方が伝え方を扱います。
- tdd は Engineer に紐づけた、エンジニアリングの方法です。まず失敗するテストを書き、次にそれをちょうど通すだけの実装を書きます。
- i-have-adhd は Lead に紐づけた、報告のスタイルです。1 行目は必ず実行できる次のステップで、手順が複数あるときは番号を振り、進捗が見えるようにします。リーダーの成果物はすべてあなたへの報告なので、このスキルがあなたの読むものを決めます。
チームの進め方をスキルとして蓄積しておけば、新しいエージェントは紐づけるだけで引き継げます。インポートだけが入手方法ではありません。新規スキル には、手動で作成する、URL からインポートする、ローカルのランタイムからコピーする、という 3 つの方法があります。ここでは詳しく触れません。スキルのドキュメントを参照してください。
サードパーティのスキルをインポートする前に、そのファイルに一度目を通してください。Multica はサンドボックスによる隔離を行わず、スキルの内容はそのまま AI コーディングツールへ渡されます。
2 つ目のイシュー：スクワッドに任せる
スクワッドに 1 つのまとまった仕事を渡します。サイトを汎用のテンプレートに変える、という内容です。実在の氏名をプレースホルダーの写真家の名前に置き換え、実在のメールアドレスを hello@example.com に置き換え、レイアウトと内容の構成は変更しません。今回はイシューを自分で書く必要はありません。チャットで Lead に要件を伝え、エージェントで作成 でそのまま作成します。担当者はスクワッドです。スクワッドはエージェントやメンバーと同じように、どの担当者の欄にも指定できます。
生成されたイシューでは、要件が構造化された説明に整理されています。タイトル横のバッジは、リーダーがすでに引き受けたことを示しています。
ここから先はすべてリーダーの仕事です。振り分けのコメントは単なる転送ではありません。イシューにはなかった制約を 2 つ補っています（プレースホルダーの人物情報をサイト全体で統一する、洗い出しの範囲をメタデータと README まで広げる）。そのうえで Engineer に渡します。Engineer は完了後、同じタイムラインに PR を報告します。
レビューでの指摘はゼロで、Lead はすぐに提出します。あなたを @メンションして受け入れ確認を求め、1 行目は結論、その下に PR のリンク、変更の説明、あなたの判断が必要な 2 点が続き、最後に一言、あなたが承認しなければマージしない、と書かれています。
要件の整理、方針の確認、開発、レビュー、提出報告まで、このイシューではあなたがつなぐ必要のあるステップは 1 つもありません。受け入れ確認の方法は MUL-1 と同じです。ローカルサーバーを起動させてブラウザで確認することもできますが、ここでは詳しく触れません。完了への変更は引き続きあなたに残ります。マージするよう返信するか、手動でステータスを変更します。タイムラインのすべてのステップが記録され、人間のチームのイシューと変わりません。変わるのは実行する側だけです。
自動化：オートパイロット
ここまでのトリガーはすべてあなたが起こしていました。割り当て、@メンション、チャットです。オートパイロット は 4 つ目のトリガー方法で、時間に応じて自動的に作業を開始します。
設定は一言で済みます。Multica helper に、毎週月曜の朝 9 時に Reviewer がサイトのコードベースを全面的に点検するよう伝えます。冗長なコードやデッドコード、不合理な構造、より規約に沿えるところを対象とし、見つけた内容はイシューのコメントに書き、コードは変更しない、という内容です。
オートパイロット ページを開くと、実行担当、プロンプト、スケジュール（cron とタイムゾーン）がすべて設定済みです。実行モードは 2 つあります。
- イシューを作成（デフォルト）：トリガーのたびにまずイシューを作成します。仕事がボード上に現れ、履歴もコメントも通常のイシューとまったく同じです。
- 実行のみ：イシューを作らずに直接実行し、記録はオートパイロットの実行履歴だけに残ります。今回の点検で問題が見つからなければ、実行後には何も残りません。
定期的な点検には「イシューを作成」モードを使います。月曜まで待たずに試すには、今すぐ実行 をクリックしてその場で 1 回トリガーします。
イシューがすぐに作成され、Reviewer が点検を始めます。以降は毎週月曜の時刻になると、同じ点検が新しいイシューを自動で作成し、誰かがトリガーする必要はなくなります。
トリガーはスケジュールのほかに webhook にも対応し、実行担当をスクワッドにすることもできます。オートパイロットのドキュメントを参照してください。
複数人での協働
ここまで、ワークスペースの人間のメンバーはあなた 1 人だけでした。設定 → メンバー でメールアドレスを使ってほかの人を招待すると、招待された人もあなたと同じようにイシューを作成し、エージェントを @メンションし、スクワッドに参加できます。複数の人と複数のエージェントが、同じイシュー群の上で協働します。
おわりに
イシューが増えてきたら、整理するための仕組みもあります。プロジェクト は関連するイシューを 1 つのグループにまとめ、1 つの単位として追跡します（プロジェクトのドキュメントを参照）。同様の整理の仕組みは今も増えており、Space も近く利用できるようになります。
ここまでの道のりを振り返ります。空のワークスペースから始め、コンピュータを 1 台つなぎ、4 体のエージェントを作り、2 つのイシューのライフサイクルを最後まで回し、調整をリーダーに、定期的な点検をオートパイロットに任せました。あなたの関与は段階的に後退し、最後に残るのは 2 つだけです。要件を説明することと、結果を受け入れ確認することです。
エージェントは一級のメンバーであり、協働のすべてがイシューのタイムラインに残ります。これが Multica の提供する働き方です。Multica は今も速いペースで改良が続いています。ほかの機能はドキュメントを参照してください。