Skip to content

Latest commit

 

History

History
635 lines (438 loc) · 42.5 KB

File metadata and controls

635 lines (438 loc) · 42.5 KB

OpenCode MoA

🌐 言語: 英語 · 中文 · 日本語 · 한국어 · Español · Français · Deutsch

License: MIT PRs Welcome OpenCode

🔥 ホット (2026-07): フラッグシップフューズが Kimi K3 にアップグレード — 2.8T パラメータ、1M コンテキスト、トップティアのフロンティアモデル。OpenCode Go のクォータは 7/24 まで 2倍 (140 → 280 / 5h、その後 140 に戻る)。MoA の品質の上限は現在、最前線にあります。

1つの会話エントリーポイント、22の専門モデルが自動的にコラボレーション。簡単なタスクは Flash (安価) を使用し、複雑なタスクはフラッグシップ (高価) を呼び出します。簡単なタスクが作業負荷を支配し、フラッグシップの呼び出しが最小限に抑えられると、コストは最大で約90%削減されます (すべてフラッグシップと比較) — 実際の節約はタスクの組み合わせによります; コード品質は大幅に向上します。

OpenCode MoA アーキテクチャ

OpenCode MoA は OpenCode のためのエージェントの混合構成パッケージです。複数のモデルが 同じ問題について同時に考える ことを可能にし、単一のモデルでは達成できない出力品質に融合します。ツールを切り替えたり、コードを書いたり、APIのクォータを持ったりする必要はありません — ファイルをプロジェクトにドロップして OpenCode を再起動するだけです。

22のエージェント · 5つのコマンド · 3つのスキル · 30秒でデプロイ


なぜこれが必要なのか?

デフォルトでは OpenCode は最初から最後まで単一のモデルを使用します。1文字を変更することやシステムアーキテクチャを設計することは、同じプロンプト、同じ温度、同じコンテキストを使用します。労働の分担はありません。

3つの問題:

  1. コストが制御不能 — 簡単なタスクも高価なモデルを使用し、月々の請求が高くなります
  2. 品質のボトルネック — 単一のモデルは1つの考え方しか持たず、盲点に簡単に陥ります
  3. フォールトトレランスがない — モデルがダウンするとフリーズし、フォールバックがありません

MoAの解決策:


You: メッセージキューソリューションの設計を手伝ってください

    ┌─ flag-arch (Qwen3.7 Max)  ─── 建築家の視点からの計画
    ├─ flag-plan (GLM 5.2    )  ─── PMの視点からの計画
    ├─ flag-eng  (MiniMax M3 )  ─── 実装者の視点からの計画
    └─ flag-fuse (Kimi K3    )  ─── 各モデルの最良の部分を取り入れた最適な解決策

コストが最大90%削減

3つの異なるモデルからの3つの独立した計画が自然に「コンセンサス + ダイバージェンス」の構造を形成します。フュージョンモデルはコンセンサスを特定し、それを保持し、異なる部分で最良のものを取り入れます — これは単一のモデルではできません。


前提条件

必須

要件 チェックコマンド メモ
OpenCodeがインストールされている opencode --version >= 1.3.4 (エージェントレベルの reasoningEffort/hidden/task サポート; openai-compatible プロバイダーは推論を透過的に渡し、forceReasoning は不要)、インストール
OpenCode Go プラン opencode.ai コンソール サブスクライブ、最初の月は $5、その後は $10/月
Gitがインストールされている git --version リポジトリをクローンするために使用
OpenCode Go API キー opencode.ai コンソールで作成 Zen コンソール (opencode.ai) で作成

オプション (インストールスクリプトで必要)

要件 チェックコマンド メモ
PowerShell Core pwsh --version install.ps1 に必要、Windows にバンドルされているか、brew install powershell でインストール
jq jq --version JSON マージのために install.sh に必要、apt install jq / brew install jq でインストール

pwsh/jq がなくても大丈夫 — メソッド 1 (AI 自動デプロイ) またはメソッド 3 (手動マージ) を使用できます。

デスクトップ vs CLI

  • CLI: すべてのメソッドがサポートされています
  • デスクトップ: メソッド 1 (AI 自動デプロイ) が最も便利です; メソッド 2/3 は最初にターミナル操作が必要です

⚠️ システムレベルのキーのパスを間違えるのは簡単です — 以下の「デプロイ前に読む」で正しいスペルを確認してください。間違ったパスは「デプロイメントは成功するがすべてのエージェントが接続できない」につながります。

⚠️ デプロイ前に読む: キーパスを間違えないでください プロバイダー + キーを プロジェクトレベルの opencode.json (デフォルト、自己完結型) または システムレベル の共有パスのいずれかに配置します — 1つ を選択してください。 システムレベルを使用する場合、正しいパスは次のとおりです:

  • Linux/macOS ~/.config/opencode/opencode.json
  • Windows %USERPROFILE%\.config\opencode\opencode.json (ではなく %APPDATA%\opencode) 間違ったシステムレベルのパスは「デプロイメントは成功するがすべてのエージェントが接続できない」につながります。

30秒デプロイ

方法 1: AI自動デプロイ(推奨)

  1. docs/opencode-moa.en.mdをダウンロードします。
  2. OpenCodeにそのドキュメントをアップロードし、次のように送信します:

このマニュアルから現在のプロジェクトに22のエージェント、5つのコマンド、3つのスキルをデプロイします。

  1. AIがすべてのファイルを自動的に作成します。完了したらOpenCodeを再起動します。

手動でファイルを作成する必要はありません。デプロイマニュアル自体がインストーラーです。

方法 2: ワンクリックインストールスクリプト(スクリプト版 · CLIフレンドリー)

# リポジトリをクローン
git clone https://github.com/ZenHG/opencode-moa.git

# プロジェクトディレクトリに移動
cd your-project

# リポジトリから.opencodeディレクトリをコピー
cp -r ../opencode-moa/.opencode/ .

# インストールスクリプトを実行(設定を自動マージし、APIキーを保持)
# Windows:
pwsh ../opencode-moa/install.ps1
# Linux/macOS:
bash ../opencode-moa/install.sh

インストールスクリプトは元のopencode.jsonを自動的にバックアップし、プロバイダーとAPIキーを保持しながらMoAの設定をマージします。

注意: この方法では、リポジトリにバンドルされている.opencode/をそのままコピーします — エージェントは中国語の表示名を持っています。英語名のエージェントが必要な場合(@english-nameを使用できるように)、方法1を使用してください。

任意のモデルをカスタマイズ

MoAは汎用テンプレートです — 各エージェントのモデルは変更可能なIDに過ぎません。各エージェントファイルは次のように始まります:

model: opencode-go/<model-id>

モデルを変更するには、.opencode/agents/<agent>.mdのその1行を、アクセス可能な任意のprovider/model-idに編集します(例: opencode-go/kimi-k2.7-code, opencode-go/glm-5.2)。再インストールは不要です。自由に組み合わせて使用できます — テンプレートに縛られることはありません。

方法 3: 手動インストール

# 1. リポジトリをクローン
git clone https://github.com/ZenHG/opencode-moa.git

# 2. .opencodeディレクトリをコピー
cp -r opencode-moa/.opencode/ your-project/

# 3. opencode.jsonを手動でマージ(直接置き換えないでください!)
# opencode.jsonを開き、MoAのpermission.taskとagentセクションをマージします
# 既存のプロバイダーとモデルの設定を保持します

⚠️ **cat >>**を使用して追加しないでください — JSON形式が壊れます。直接置き換えないでください — APIキーを失います。

注意: この方法では、リポジトリにバンドルされている.opencode/をそのままコピーします — エージェントは中国語の表示名を持っています。英語名のエージェントが必要な場合(@english-nameを使用できるように)、方法1を使用してください。

デプロイが成功したかどうかを確認するには?

  1. OpenCodeを再起動した後、Tabを押してエージェントを切り替え(WindowsデスクトップクライアントではCtrl+.も機能します)、「concierge-router」を確認します。
  2. @tool-handlerと入力すると応答があります。
  3. 検証スクリプトを実行します: pwsh .opencode/tests/T0-static-verify.ps1(デプロイ中に手動でBlock 5.5によって生成されたもの)、すべてPASSが期待されます(FAIL=0; システムレベルのキーを使用している場合、WARNもPASSとしてカウントされます)。

ワンクリックロールバック

rm -rf your-project/.opencode/
# 手動でopencode.jsonを復元します(インストールスクリプトは自動的に.bakファイルをバックアップします)

使い方は?

何も学ばず — ただ話してください。 コンシェルジュルーターは自動的にタスクの複雑さを判断し、対応するエージェントチェーンを派遣します。

あなたの言うこと コンシェルジュルーターがすること 使用されるエージェント
"この変数の名前を変更して" 簡単なタスクとして判断 swift (Flash)
"ユーザー認証モジュールを書いて" ツール層が収集 → 3つの中間層並列 → 融合 tool-handler + mid-tier trio + fuse
"マイクロサービスアーキテクチャを設計して" ツール層が収集 → 3つのフラッグシップ並列 → 融合 → 実装 → QA full-chain 6 agents
"このスクリーンショットのUIを復元して" 3人のフロントエンド専門家が並列 → リーダーが最適なものを選択 frontend quartet
スクリーンショット付きのメッセージ ビジョントランスレーターがテキストに変換 → 通常のルーティング vision-translator
エラーログ / 図 / 複雑なコンテンツ付きのメッセージ ビジョントランスレーターがコンテンツを分解 → 通常のルーティング vision-translator (フォールバック役)

直接@コール:

@swift help me write a hello world
@tool-handler search all TODOs in the project
@flag-arch design a message queue solution

ワンクリックコマンド:

コマンド シナリオ
/moa-quick 簡単なタスク、翻訳、設定変更
/moa-medium 機能モジュール、バグ修正、単一ファイルのリファクタリング
/moa-flagship システムアーキテクチャ、大規模リファクタリング
/moa-frontend UI復元、CSS、スクリーンショット修正
/moa-describe スクリーンショット/画像をテキストに変換

アーキテクチャ

                      concierge-router (Flash)
                                 │
                ┌────────────────┼─────────────────┐
                ▼                ▼                 ▼
             ツール層         意見層             融合層
             Flash + MiMo   3つの並行意見が最良を選択
             (~80% 呼び出し)   (~18% 呼び出し)        (~2% 呼び出し)

ツール層 (Flash + MiMo) — コードを読み、ファイルを検索し、スクリーンショットをテキストに変換。安価で迅速、自由に呼び出せる。

意見層 (MiniMax / DeepSeek Pro / Qwen / MiMo-Pro) — 異なる視点からの計画。3つの意見が自然に「合意 + 分岐」の構造を形成する。

融合層 (Kimi K3 / Qwen-Max / GLM / DeepSeek Pro フォールバック) — 合意を維持し、分岐の中から最良を選択し、融合が失敗した場合は DeepSeek V4 Pro にフォールバックする。フラッグシップの融合は現在 Kimi K3 (2.8T パラメータ、1M コンテキスト、トップティアのフロンティアモデル) で動作しており、MoA の品質の限界を前進させている。

⚠️ 以下の呼び出しボリューム比率 (~80% / ~18% / ~2%) は 設計目標 であり、測定された統計ではありません。実際の比率はタスクの複雑さによって異なります。


22 エージェント

英語名は論理的な役割を示し、括弧内の中国語は .opencode/agents/ 下の 正確なファイル名 です — @ で呼び出します (例: @门童路由员)。

concierge-router (门童路由员, Flash)
 │
 ├── ツール層 ─────────────────────────────────────────────
 │   tool-handler      (工具人, Flash    ) コードを読み、ファイルを検索 [+ マテリアル自己チェック]
 │   tool-handler-mimo (工具人-mimo, MiMo) 信頼性のあるファイル読み取り (フォールバック + 並行) [隠し]
 │   swift             (闪电侠, Flash    ) 単純なタスクを一度で
 │   vision-translator (视觉翻译官, MiMo ) スクリーンショット/UI→テキスト; ログ/図/文書→分解
 │
 ├── 残差提取者  (残差提取者,  Flash     ) 計画間の分岐を分析
 ├── 置信度评估者 (置信度评估者, DS Pro    ) 融合結果の信頼度を評価
 │
 ├── 中級意見層 ─────────────────────────────────────────────
 │   mid-eng      (中级·工程, Kimi K2.6 ) エンジニアリングビュー
 │   mid-creative (中级·创意, Qwen3.7 Plus) 創造的ビュー
 │   mid-coder    (中级·码农, Flash     ) 実用的ビュー
 │   mid-fuse     (中级·融合, Kimi      ) 3つの計画を融合 [max_tokens: 16384]
 │
 ├── フラッグシップ意見層 ─────────────────────────────────────────────
 │   flag-arch (旗舰·架构, Qwen3.7 Max ) トップレベルのアーキテクチャ
 │   flag-plan (旗舰·规划, GLM 5.2     ) 構造化された計画
 │   flag-eng  (旗舰·工程, MiniMax M3  ) 大規模な実装
 │   flag-fuse (旗舰·融合, Kimi K3     ) 3つのアーキテクチャ計画を融合 [max_tokens: 16384]
 │   flag-impl (旗舰·实现, Flash       ) 融合された計画ごとに実装 [隠し]
 │   flag-qa   (旗舰·质检, DeepSeek Pro) 計画レビュー + コード受け入れ [max_tokens: 16384]
 │
 └── フロントエンド意見層 ─────────────────────────────────────────────
     fe-restore (前端·还原, MiMo       ) ピクセルパーフェクトなUI復元
     fe-logic   (前端·逻辑, Qwen3.7 Plus) コンポーネントアーキテクチャ & 状態管理
     fe-motion  (前端·动效, MiMo-Pro   ) インタラクション & モーション
     fe-lead    (前端·总工, GLM-5.2    ) 3つのフロントエンド計画の中から最良を選択 [max_tokens: 16384]

フォールバックエージェント (上記のルーターチェーンには含まれず、融合が失敗したときのみ呼び出される):

fallback (融合·保底, DeepSeek V4 Pro) — 同じ残差強化融合を使用し、flag-fuse / mid-fuse / fe-lead が失敗したときに使用

フォールトトレランス設計

ツール層フォールバックチェーン

ツール層が失敗してもフリーズしない — 自動的にダウングレードする:

tool-handler (Flash) が失敗 → すぐに1回再試行
  → 再試行成功 → 通常通り返す
  → 再試行失敗 → tool-handler-mimo (MiMo) が失敗 → すぐに1回再試行
    → 再試行成功 → 通常通り返す
    → 再試行失敗 → ユーザーに尋ねる:
      A. 数分待って再試行
      B. ツール層をスキップし、意見層を直接呼び出す (コストが高い)
      C. 無料モデルに切り替える

ほとんどのプロバイダーエラー (502/503/タイムアウト) は一時的であり、迅速な再試行は通常成功します。

融合層フォールバック

プライマリ融合エージェントが失敗した場合 (STUCK / ERROR_PROVIDER / タイムアウト / 空の結果)、concierge-router は自動的に @融合·保底 (DeepSeek V4 Pro, フォールバック) にフォールバックします:

flag-fuse (旗舰·融合, Kimi K3) が失敗
  → task(@融合·保底) (DeepSeek V4 Pro) → フォールバック結果を出力
mid-fuse (中级·融合, Kimi) が失敗
  → task(@融合·保底) (DeepSeek V4 Pro) → フォールバック結果を出力
fe-lead (前端·总工, GLM-5.2) が失敗
  → task(@融合·保底) (DeepSeek V4 Pro) → フォールバック結果を出力

フォールバックエージェントは同じ残差強化融合プロセスを使用します。

意見層部分失敗耐性

個々の意見エージェント (アーキテクチャ/計画/エンジニアリング、フロントエンド復元/ロジック/モーション、中級エンジニアリング/クリエイティブ/コーディング) は、空の結果を返したり、独立してタイムアウトすることがあります。システムはこれを優雅に処理します:

3つの並行意見エージェントが派遣される
  → いずれかのエージェントが空の結果を返す → そのエージェントを1回再試行
    → 再試行成功 → 通常通り続行
    → 再試行失敗 → "劣化" としてマークし、N/3 の入力で進む
      → 残差提取者は利用可能な入力のみで動作
      → 旗舰·融合は劣化した融合ルールを適用
      → 出力には "[Partial] N/3 inputs" ラベルが付く
      → 信頼度スコアは下方修正される

劣化した融合ルール (N < 3):

  • 合意カバレッジの分母は N であり、3 ではない
  • 欠落した視点には [Missing: perspective name] とラベル付けされる
  • 合意カバレッジ < 50% は "低信頼度の劣化した融合" 警告をトリガーする
  • 単一ソース融合 (N=1) は 0.7 の信頼度ペナルティファクターを適用する

これは、1つの意見エージェントが失敗したときにパイプラインが停止するのを防ぎます (STUCK) — 一般的なユーザーの不満です。

宣言的エージェント前提条件

エージェントのアクティベーションは、ハードコーディングされたルーティングルールではなく、宣言的な precondition メタデータによって管理されます。各エージェントは、いつアクティブになるべきかを宣言します:

エージェント 前提条件
闪电侠 常に
工具人 コードベースのコンテキストが必要
视觉翻译官 プライマリ: screenshot; フォールバック: error_log OR diagram OR long_document OR ambiguous_intent
中级·工程 エンジニアリングの複雑さが必要
中级·创意 創造的な複雑さが必要
中级·码农 実装の複雑さが必要
旗舰·架构/规划/工程 システム設計の複雑さが必要
前端·还原/逻辑/动效 フロントエンドタスクが必要
融合·保底 融合層が失敗したとき、または意見層が部分的な結果を返したときにアクティブ化される

条件のアクティベーションはショートサーキットロジックに従います: 前提条件が満たされる → アクティブ化; いずれも満たされない → ユーザーに確認を求める。これは、ハードコーディングされたトリガールール (例えば "スクリーンショットが利用可能 → @vision-translator") を、エージェントが宣言した自己文書化された前提条件に置き換えます。

パイプラインステージの可視化

すべてのルーティング決定はステージ識別子を出力し、ユーザーが内部のステップ番号を学ぶことなくパイプラインの進行を追跡できるようにします:

[Stage: ツール層] → [Stage: 意見層] → [Stage: 融合層] → [Stage: 実装層]

ステージとフェーズのマッピング:

  • ツール層 — マテリアル収集フェーズ
  • 意見層 — 並行計画設計フェーズ (中級 / フラッグシップ / フロントエンド)
  • 融合層 — 計画の融合と検証フェーズ
  • 実装層 — コード実装と受け入れフェーズ

統一された進捗報告

成功と失敗の両方のパスは同じ報告形式に従い、内部エージェント名を決して公開しません:

[Pipeline] mode=<lite|balanced|strict>  stage=<ツール層|意見層|融合層|実装層>  status=<idle|in_progress|complete|degraded|stuck>
  reason: <なぜこのステージ>
  path: <ツール層|中級チェーン|フラッグシップチェーン|フロントエンドチェーン>
  fallback: <回復戦略>

ステータスインジケーター:

  • in_progress — 現在のステージを実行中
  • complete — ステージが正常に終了
  • degraded — 部分的な入力で実行中、信頼度が低下
  • stuck — すべての回復パスが尽き、ユーザーの介入が必要

闪电侠 パラレルショートカット

メインパイプラインが実行中のとき、闪电侠は独立した単純なサブタスクのために並行して派遣できます:

メインパイプライン: ツール層 → 意見層 → 融合層 → 実装層
並行レーン: 闪电侠 (常に準備完了、メインパイプラインと並行して実行)

トリガー条件 (いずれか1つ):

  • ユーザーの指示が明示的に並行作業を要求する ("Xを同時に行う", "Yもすぐに確認する")
  • メインパイプライン実行中に単純なサブタスクが発生する (例: アーキテクチャ計画が設計されている間にTODOを検索する)
  • ユーザーが直接 @闪电侠 を呼び出す

スコープ制限:

  • ✅ メインパイプラインの出力に依存しない独立したタスク
  • ✅ 単純な操作: ファイル検索、grep、設定クエリ、フォーマット
  • ❌ メインパイプラインの入力を生成するタスク
  • ❌ 意見融合タスク (直列でなければならない)
  • ❌ 実装およびQAタスク (直列でなければならない)

もし闪电侠がメインパイプラインよりも早く終了した場合、結果は保持され、最後に一緒に返されます。メインパイプラインが先に終了した場合、闪电侠の結果は即座に返されます。闪电侠の失敗はメインパイプラインの実行に影響を与えません。

MCP パーミッションアイソレーション

意見層のエージェントは、コードを直接読み取ることを禁止されています (read: deny + bash: deny)、これにより、ツール層をバイパスしてマテリアルを自分で取得することを防ぎます:

  • ツール層: コードを読み、ファイルを検索できる ( read/bash アクセスあり)
  • 意見層: read: deny + bash: deny、ツール層からのマテリアルに基づいてのみ計画できる
  • 融合層: 同じ制限があり、3つの意見に基づいてのみ融合できる

注: このプロジェクトは、MCPサーバーを構成していません。「MCPパーミッションアイソレーション」という用語は、エージェントレベルのツール制限 (read: deny / bash: deny) を指し、MCPサーバーレベルのアイソレーションではありません。

マテリアルなしフォールバック

意見層が呼び出されるがマテリアルがない場合 (ツール層が完全に失敗)、ユーザーに尋ねます:

  • "計画を直接提供" を選択 → 要件の説明に基づく純粋な論理的推論 (コードを読み取らない)
  • "ツール層を待つ" を選択 → WAITING を出力し、ツール層が回復した後に再試行

エラー分類

ツール層は失敗時に明確なエラーカテゴリを出力し、盲目的に再試行するのではなく:

  • ERROR_PROVIDER — サーバー 502/503/タイムアウト
  • ERROR_AUTH — 認証失敗
  • ERROR_UNKNOWN — その他のエラー

コスト

約90%の節約理由

MoAはコールボリューム加重ミックスによって請求されます:約80%ツールレイヤーFlash、約18%ミッドティア、約2%フラッグシップ。このセクションのコストテーブルにある単位価格を使用して、効果的な出力単価を推定します:

重要:80/18/2の比率はアーキテクチャによって設計された予想コールボリューム分布であり、測定されたコスト比率ではありません。実際の使用はタスクの種類や複雑さに依存します。

レイヤー シェア 出力単位価格 /1M 加重
ツールレイヤー 80% $0.28 $0.224
ミッドティア 18% ~$2.10 (MiniMax $1.20 / DeepSeek Pro $3.48 / Qwen Plus $1.60 / Kimi K2.7 $4.00 mid-fuse 平均) $0.378
フラッグシップ 2% ~$6.00 (Qwen/GLM/MiniMax ~$4-7 + Kimi K3 $15.00 flag-fuse) $0.12

ブレンドされた効果的出力単価 ≈ $0.72 / 1M。 "全フラッグシップGLM $7.50"と比較して→約10% → 約90%の節約; "全ミッドティアDeepSeek Pro $3.48"と比較して→約21% → 約79%の節約。"90%の節約"という主張はフラッグシップの基準に対する実際の価値です。

OpenCode Goプラン

MoAはOpenCode Goプランに基づいており、最初の月は$5、その後は$10/月です。

使用制限:

時間ウィンドウ クォータ
5時間ごと $12
週間 $30
月間 $60

制限はドル価値によって定義されています。安価なモデル(Flash)はより頻繁に使用でき、高価なモデル(GLM)はそれほど頻繁には使用できません。

レイヤーごとの月間クォータ

レイヤー モデル 単位価格 (in/out per 1M) 月間クォータ コール頻度
ツールレイヤー Flash $0.14 / $0.28 158,150 ~80%
ツールレイヤー MiMo-V2.5 $0.14 / $0.28 150,400 (自由に使用)
オピニオン MiniMax M3 $0.30 / $1.20 16,000 ~18%
オピニオン DeepSeek V4 Pro $1.74 / $3.48 17,150
オピニオン Qwen3.7 Plus $0.40 / $1.60 21,600
フュージョン Kimi K2.7 Code $0.95 / $4.00 9,250 ~2% (ミッドティアフューズ)
フュージョン Kimi K3 $3.00 / $15.00 280 ~2% (フラッグシップフューズ)
フュージョン GLM-5.2 $1.40 / $4.40 4,300 ~2% (フロントエンドリード)

すべてのモデルIDは宣言のみです;お好みのモデルに置き換えてください。

OpenCode Go 5時間ごとのクォータ

制限に達した後

  • 無料モデルのフォールバック — Goが制限に達した後は、無料モデルを引き続き使用できます
  • Zenバランスのフォールバック — コンソールで「バランスを使用」を有効にします;Goの制限後、自動的にZenバランスを使用します

無料モデル

OpenCode Zenは最後の手段として無料モデルを提供します:

モデル 特徴
DeepSeek V4 Flash Free 高速ですが、コンテキストが制限されます
MiMo-V2.5 Free より良い品質ですが、遅くなる可能性があります
North Mini Code Free Cohereによって提供されます
Nemotron 3 Ultra Free NVIDIAの無料エンドポイント

⚠️ 無料モデルの制限:小さいコンテキストウィンドウ、応答が遅くなる可能性、データはトレーニングに使用される可能性があります、限られた期間無料です。


セキュリティ

保護 効果
グローバルキャッチオール 未宣言のツールコール → ポップアップ確認
エージェント権限の分離 各エージェントは許可されたツールのみを使用できます
MCP権限の分離 オピニオンレイヤーはコードの読み取りを禁止されています(読み取り:拒否 / bash:拒否)、ツールレイヤーのバイパスを防ぎます(プロジェクトにはMCPサーバーが構成されていません;ここでの「MCP」はエージェントレベルのツール制限を指します)
タスクホワイトリスト コンシェルジュルーターは宣言されたエージェントのみを呼び出すことができます
フォールバックチェーン ツールレイヤーが失敗 → ユーザーに確認 → 待機/スキップ/無料モデル
ワンクリックロールバック .opencode/を削除して復元します

ローカルモデル

Ollama / LM Studioのようなローカルモデルの混合をサポートしています:

# .opencode/agents/mid-coder.md
model: ollama-local/qwen3-coder

docs/opencode-moa.mdの付録Aを参照してください。


検証

リポジトリには、.opencode/tests/の下に3つのチェックスクリプトが含まれています。レイヤー0は完全自動です。レイヤー1〜2は、OpenCode内で進むガイド付きチェックリストです。

# レイヤー0 — 静的チェック(自動、0トークン)
pwsh .opencode/tests/T0-static-verify.ps1
# 期待される結果: すべてPASS / FAIL=0(システムレベルのキーで、WARNもPASSとしてカウントされます)

# 3つのレイヤーを一度に実行
pwsh .opencode/tests/run-all.ps1
スクリプト レイヤー 何をするか モード
T0-static-verify.ps1 0 ファイル構造、エージェント/コマンド/スキルのカウント、READMEアンカー、キーのパスの正確性をチェック 自動
T1-behavioral-guide.ps1 1 ルーティング / 意見 / 融合の動作のためのステップバイステップのチェックリストを印刷 手動(OpenCode内)
T2-moa-smoke-guide.ps1 2 /moa-* コマンドのエンドツーエンドのスモークテストチェックリストを印刷 手動(OpenCode内)
run-all.ps1 0–2 T0を実行した後、T1/T2のガイド付きチェックリストを印刷 混合

FAQ

インストール

Q: すでにopencode.jsonがありますが、上書きされますか?
A: いいえ。インストールスクリプトはMoAのpermissionagentdefault_agent設定のみをマージし、既存のprovidermodelなどは保持します。元のファイルは自動的に.bak.timestampとしてバックアップされます。

Q: Windowsにはcpコマンドがありませんが、どうすればいいですか?
A: Copy-Itemまたはxcopyを使用してください:

# PowerShell
Copy-Item -Recurse -Force opencode-moa\.opencode .\.opencode
# CMD
xcopy opencode-moa\.opencode .\.opencode /E /I /Y

Q: pwsh/jqなしでインストールできますか?
A: はい。方法1(AI自動デプロイ)または方法3(手動設定マージ)を使用してください。

Q: デスクトップアプリでのインストール方法は?
A: 方法1が最も便利です — docs/opencode-moa.en.mdをチャットボックスにドラッグしてAIに自動デプロイさせます。方法2/3は最初にターミナル(CMD/PowerShell/Terminal)で操作する必要があります。

使用法

Q: "concierge-router"が見えませんか?
A: "30秒デプロイ → デプロイ成功の確認方法"の下にある3つのチェックを参照してください:プロジェクトルートのopencode.json.opencode/agents/の下の22 .md、再起動後にTabで切り替え(WindowsデスクトップクライアントではCtrl+.も機能します)。

Q: @tool-handlerが応答しませんか?
A: .opencode/agents/tool-handler.mdが存在し、フロントマターの形式が正しいことを確認してください。

Q: "model not found"エラー?
A: モデルIDの形式はprovider/model-idである必要があります(例:opencode-go/kimi-k2.7-code)。対応するプロバイダーを設定ファイルに登録してください(システムレベルの~/.config/opencode/opencode.jsonまたはプロジェクトのopencode.json)、その後TUI内で/modelsを使用して利用可能なモデルを確認します。

Q: 元のビルド/プランエージェントに戻すにはどうすればいいですか?
A: Tabを押して切り替えます(WindowsデスクトップクライアントではCtrl+.も機能します)、または/build/planと入力します。MoAは組み込みエージェントに影響を与えません。

Q: 自分のモデルを使用したいのですが、Goプランではなく?
A: エージェントのmodelフィールドを変更するだけです:

# .opencode/agents/mid-eng.md
model: opencode-go/glm-5.2

Q: デプロイ後にリポジトリを削除できますか?
A: はい。MoAはすでにプロジェクトの.opencode/ディレクトリにコピーされていますので、元のリポジトリは削除できます。

Q: 複数のプロジェクトにデプロイするにはどうすればいいですか?
A: 各プロジェクトを個別にデプロイしてください。.opencode/はプロジェクトレベルの設定であり、他のプロジェクトには影響しません。

フォールバック

Q: ツールレイヤー全体がダウンしています、どうすればいいですか?
A: 上記の"フォールトトレランス設計 → フォールバックチェーン"を参照してください:MoAはユーザーにA. 数分待つ / B. ツールレイヤーをスキップして意見レイヤーを直接呼び出す(コストが高くなる)ように求めます。

Q: 無料モデルはどこにありますか?
A: 上記の"コスト → 無料モデル"を参照してください:/modelsを使用してモデルリストを開き、"Free"とタグ付けされたものを選択します(WindowsデスクトップクライアントではCtrl+'も機能します)(DeepSeek V4 Flash Free、MiMo-V2.5 Free、North Mini Code Freeなど)。無料モデルはコンテキストが制限されており、遅くなる可能性があり、データはトレーニングに使用される場合があります。


メンテナーツール (エンドユーザーには必要ありません)

以下のファイルはリポジトリのメンテナのためのものであり、MoAのデプロイには使用しません。エンドユーザーは無視して構いません。

ファイル 目的
deploy-sync.ps1 メンテナのみ — リポジトリをGitHubに同期し、opencode-moaスキルをSkillHubにアップロードします。-SkipGit / -SkipSkillHub / -DryRunをサポートします。
scripts/hooks/pre-commit ローカルgitフックのリマインダー: CHANGELOG.mdの変更をステージすると警告します(これはmasterにプッシュすると自動的にリリースされます)。
scripts/hooks/pre-push ローカルgitフックのリマインダー: CHANGELOG.mdの変更をmasterにプッシュする前にバージョンを確認します; 非対話型/CI環境では自動的に進行します。

これらのフックは自動的にインストールされません。リマインダーが必要な場合は、.git/hooks/にシンボリックリンクを作成してください。例: ln -s ../../scripts/hooks/pre-push .git/hooks/pre-push


貢献

PRとIssuesを歓迎します。詳細はCONTRIBUTING.mdを参照してください。


ライセンス

MIT · OpenCode MoA