AI コーディングツール対応表

Multica は 16 個の AI コーディングツールを標準でサポートしています。これらはすべて同じインターフェース（キューへの投入、ディスパッチ、実行、結果の返却）を実装しているため、同じ Multica ボードからどれでも動かすことができます。しかし機能の詳細は大きく異なります: セッション再開が実際に動作するか、MCP をサポートするか、スキルファイルがどこに置かれるか、モデルをどう選択するか。このページがその完全な対応表です。

エージェントを作成するときにツールを選ぶ際のガイダンスは、エージェントの作成と構成を参照してください。

機能対応マトリクス

各ツールの用途

Antigravity

Google が提供します。CLI バイナリ名は agy です。Google の Antigravity サービスと連携し、Gemini ベースのデフォルトモデルが付属しています。セッション再開が動作します — --conversation <id> を通じて行われ、stdout が構造化されたイベントストリームではなくプレーンテキストであるため、デーモンが CLI のログファイルから conversation UUID をキャプチャします。モデル選択が動作します — --model flag（agy 1.0.6 で追加）を通じて行われ、デーモンが agy models でカタログを列挙し、選択された値をそのまま渡します。これらは provider/model slug ではなく Claude Opus 4.6 (Thinking) のような人間が読める表示名である点に注意してください。また agy は認識できない値を渡すと黙って空実行するため、手入力ではなく検出されたリストから選ぶことをおすすめします。スキルは .agents/skills/ に配置されます（CLI が Gemini CLI のワークスペーススキルレイアウトをそのまま継承します — Antigravity 移行ドキュメントを参照）。

Claude Code

Anthropic が提供します。新規ユーザーにとって第一の選択肢であり、最も完成度の高い機能セットを備えています: セッション再開が実際に動作し、MCP 構成を読み取り、--max-turns や --append-system-prompt のような細かな調整 flag をサポートします。Anthropic API キーが必要です。

CodeBuddy

Tencent が提供します。Claude Code 互換の CLI エージェントです — Multica は Claude Code と同じ stream-json プロトコルで駆動するため、セッション再開が動作し（--resume 経由）、MCP 構成は --mcp-config で渡されます。CodeBuddy は Claude のディレクトリを再利用せず独自の設定ディレクトリを使うため、スキルは .codebuddy/skills/ に配置され、ランタイムのブリーフは CODEBUDDY.md に書き込まれます。モデルは動的に探索されます。

Codex

OpenAI が提供します。JSON-RPC 2.0 を使用し、ステートフルな能力がより強く、よりきめ細かい承認メカニズム（exec_command および patch_apply に対する手動承認）を備えています。MCP 構成はタスクごとの $CODEX_HOME/config.toml に書き込まれます。セッション再開は動作します — Multica は Codex app-server の thread/resume で再開します。保存済み thread が見つからない、または古い場合は、新しい thread にフォールバックしてタスクを続行します。

Copilot

GitHub が提供します。モデルルーティングは GitHub アカウントの権限を経由します — ツールが直接モデルを選択するのではなく、GitHub がどのモデルを提供するかを決定します。.github/skills/ にスキルを置くのは GitHub CLI のネイティブな探索メカニズムです。

Cursor

Anysphere が提供し、Cursor エディターに対応する CLI です。セッション再開は動作します — 現在の Cursor Agent の stream-json イベントには session_id が含まれ、Multica は次回実行時に --resume <id> でそれを渡します。MCP 構成はタスクワークスペースの .cursor/mcp.json に書き込まれ、Cursor のプロジェクト approval ファイルはタスクごとの CURSOR_DATA_DIR 配下に置かれるため、管理対象 MCP server はユーザーのグローバル Cursor approvals に依存しません。

Hermes

Nous Research が提供します。ACP プロトコルを使用します（Kimi とトランスポート層を共有します）。セッション再開が動作し、MCP 構成は ACP mcpServers として渡されます。Hermes はスキルを自身のホームディレクトリ（~/.hermes/skills/）と設定済みの skills.external_dirs からのみ探索し、ワークスペース相対の探索は行いません。そのため、エージェントにスキルが割り当てられている場合のみ、Multica は HERMES_HOME をユーザーの ~/.hermes/ のタスクごとオーバーレイに向けます。実ホームはシンボリックリンクでミラーされ（auth／シークレットも含むためトークン更新が伝播します）、派生した config.yaml が既存スキルを読み取り専用の external root として参照し、割り当てられたスキルだけがその skills/ ディレクトリに書き込まれて優先されます。グローバルスキルはそのまま機能します。Multica は共有の ~/.hermes/ を直接書き換えず、読み取ってリンクするだけですが、Hermes 自身がミラーされたシンボリックリンク経由で書き込む場合（トークン更新など）は伝播します。custom_args の -p/--profile 指定は尊重されます。オーバーレイはその profile のホームからシードされ、フラグは起動コマンドから消費されるため、オーバーレイを迂回できません。タスクの記憶はタスクごとに隔離されます。新しい memories/ ディレクトリに加え、派生設定で外部 memory.provider バックエンドを無効化するので、ディスク上のメモも共有の Supermemory/Hindsight 的バンクもタスク間で共有されません（マネージドで agent スコープの記憶バックエンドは今後の別課題です）。SQLite の state.db セッションストアとジャーナルファイルもタスクローカルで、Hermes がオーバーレイ内に作成します。ホストの会話履歴はリンクもコピーもされず、Windows で稼働中の WAL ロックがセットアップを妨げることもありません。スキルが割り当てられていない Hermes タスクは実ホームのまま変わりません。なお home のプラットフォーム既定はネイティブ Windows では %LOCALAPPDATA%\hermes です。

Hermes profile を選択する。 特定の profile で Hermes を起動するには、エージェントの custom_args に profile フラグと profile 名を 2 つの独立したエントリとして設定します。たとえば research という profile を使う場合:

["-p", "research"]

"-p research" のように 1 つの文字列へまとめないでください。Multica は配列の各要素を 1 つの argv エントリとしてツールへ渡します。custom_args はエージェントごとに設定します — エージェントの作成と構成を参照してください。

Kimi

Moonshot が提供し、中国市場を対象としています。Hermes と ACP プロトコルを共有し、MCP 構成も ACP mcpServers として渡されますが、スキルパス .kimi/skills/ は Kimi CLI のネイティブな探索メカニズムであり、Hermes のフォールバックとは異なります。

Kiro CLI

Amazon が提供します。kiro-cli acp を通じて stdio 上で ACP を使用します。セッション再開は ACP session/load で動作し、MCP 構成は ACP mcpServers として渡され、モデル選択は session/set_model で動作し、スキルはプロジェクトレベルのネイティブ探索のために .kiro/skills/ にコピーされます。

OpenCode

SST が提供するオープンソースです。利用可能なモデルと model variant を動的に探索します（CLI の構成ファイルをスキャン）。セッション再開が動作し、エージェントの mcp_config フィールドを消費します。Multica は OPENCODE_CONFIG_CONTENT 環境変数でインライン注入するため、エージェントの MCP server はタスク workdir の opencode.json（エージェントまたはユーザーが所有するファイル）を書き換えずに OpenCode に届きます。モデルが variant を公開している場合、Multica はそれをエージェントの thinking selector として表示し、選択値を opencode run --variant で OpenCode に渡します。自分のモデルカタログをカスタマイズしたい、いじるのが好きなユーザーに適しています。

DevEco Code

DevEco Code は Huawei（ファーウェイ）の HarmonyOS 開発向け独立コーディングエージェント（deveco CLI、gitcode.com/openharmony-sig/deveco-code）です。OpenCode エンジンをベースにしつつ、単体で完成した成熟製品として提供され、独自のモデルカタログと provider（内蔵 deveco/GLM-5.1）、Huawei アカウント認証、専用の設定・スキル体系（~/.config/deveco/ と .deveco/skills/）を備えます。Multica は deveco run --format json で駆動し、NDJSON イベントストリームをパースします。セッション再開が動作します（--session <id> 経由）。モデルは deveco models から動的に探索され、システムコンテキストはタスクごとの AGENTS.md で渡されます。MCP サーバーは DevEco ネイティブの DEVECO_CONFIG_CONTENT チャネルで設定します。Multica 側の mcp_config 連携は開発中のため、現時点では DevEco エージェントの MCP タブは非表示になります。認証は deveco auth login（Huawei アカウント）で行います。

OpenClaw

オープンソースプロジェクトであり、CLI エージェントオーケストレーターです。MCP 構成は Multica のタスクごとの config wrapper 経由で書き込まれます。モデルはエージェント層にバインドされます（openclaw agents add --model） — タスクごとに上書きできません。構成は厳格に制御されます: ユーザーは --model や --system-prompt を渡せず、エージェント登録時の構成が決定します。

Pi

Inflection AI が提供し、ミニマルです。セッション再開の方式が独特です — セッション ID が文字列 ID ではなく、ディスク上のファイルパス（~/.pi/...）です。他のツールでは再開 id は CLI が返す文字列ですが、Pi では再開 id はセッションファイルそのものです。

Qoder

Alibaba が提供します。エージェント型のコーディング CLI です。stdio 上で ACP プロトコルを使用します（Hermes、Kimi、Kiro CLI とトランスポートを共有します）。セッション再開は ACP session/resume を通じて動作し、MCP 構成は ACP mcpServers として渡され、モデル選択は動的に探索され、スキルはネイティブ探索のために .qoder/skills/ にコピーされます。

Trae

ByteDance 公式の TRAE CLI（traecli、Trae IDE と組み合わせて使う製品で、オープンソースの bytedance/trae-agent ではありません）です。ACP ネイティブのため、Multica は traecli acp serve --yolo で stdio 経由で駆動します。Kiro や Qoder と同じトランスポートです。セッション再開は ACP session/load で動作し、MCP 構成は ACP mcpServers として渡され、モデルは動的に探索されて session/set_model でタスクごとに切り替えられます。スキルは .traecli/skills/ にコピーされます。

Grok

xAI の Grok Build CLI（grok）です。Multica は grok --no-auto-update agent --always-approve stdio で ACP 接続します。initialize の応答後、CLI が提示した方式から xai.api_key（XAI_API_KEY 設定時に優先）または cached_token を選び、authenticate の成功を待ってからセッションを作成または読み込みます。利用可能な方式がなければ明示的に失敗します。セッション再開は ACP session/load、モデルは session/new から動的に探索して session/set_model で切り替えます。grok-4.5 の reasoning effort は公式対応の low、medium、high のみです。MCP 構成は ACP mcpServers で渡されます。スキルは .grok/skills/ に書き込まれ、ユーザースキルは $GROK_HOME/skills/（既定 ~/.grok/skills/）と共通の ~/.agents/skills/ から探索されます。

セッション再開: 実際にサポートするツール

セッション再開のメカニズムはタスクで扱います。サポートされているすべてのツールがセッションを再開できます — 再開 id を渡すと、タスクは以前のコンテキストから続行します。唯一の例外は Pi で、再開 id が文字列 ID ではなくディスク上のセッションファイルへのパスです（上記の Pi を参照）。

MCP 構成: ツールごとの対応

16 個のツールのうち、mcp_config を実際に消費するのは 12 個です: Claude Code、CodeBuddy、Codex、Cursor、Hermes、Kimi、Kiro CLI、OpenCode、OpenClaw、Qoder、Trae CLI、Grok。残りの 4 個（Antigravity、Copilot、DevEco Code、Pi）はこのフィールドを受け取りますが、無視します — エラーも警告もなく、構成はただ効果を発揮しません。

接続方式はツールごとに異なります: Claude Code と CodeBuddy は --mcp-config と --strict-mcp-config で受け取り、Codex は daemon 管理の mcp_servers ブロックをタスクごとの $CODEX_HOME/config.toml に書き込み、Cursor は .cursor/mcp.json とタスクごとの CURSOR_DATA_DIR 配下のプロジェクト approval を書き込みます。Hermes、Kimi、Kiro CLI、Qoder、Trae CLI、Grok は ACP mcpServers で受け取ります。OpenCode は OPENCODE_CONFIG_CONTENT 環境変数でインライン構成を受け取り、OpenClaw は Multica のタスクごとの config wrapper 経由で mcp.servers を受け取ります。OpenCode の経路はプロジェクトの opencode.json を書き換えません。

スキルファイルが置かれる場所

各ツールはそれぞれ独自のスキル探索パスを使用します。タスクが実行される前に、Multica デーモンがワークスペースのスキルファイルを対応するパスにコピーします。

フォールバックパスを使うツールが実際にこのディレクトリを読み取るかどうかは、そのツール自体のドキュメントによって異なり、保証されません。OpenClaw でスキルが適用されない場合は、まずこの点を確認してください。

ネイティブなプロジェクトレベルのパスでは、リポジトリスコープの探索は想定された挙動です。チェックアウトされたリポジトリが対応するディレクトリをすでに含んでいる場合、基盤となるツールはそのコミット済みスキルを自分で検出できます。そのリポジトリで使うためだけに、これらの repo skills を Multica へインポートする必要はありません。Multica はそれらのリポジトリファイルをそのまま保持します。ワークスペーススキルの自然なディレクトリ名が同じ場合、デーモンは review-helper-multica のような衝突しない兄弟ディレクトリへワークスペースコピーを書き込みます。

スキルの作成と使用については、スキルを参照してください。

次へ

• エージェントの作成と構成 — エージェントに使うツールを選ぶ
• タスク — タスクのライフサイクルとセッション再開のメカニズム
• デーモンとランタイム — ツールが実行される場所と Multica への接続方法
• エージェントランタイムのインストール — サポートされる 16 個のツールそれぞれのインストールと認証