メインコンテンツへスキップ
本ガイドは、QoderWork 公開マーケットプレイスに自身の機能を公開したい作成者に向けて、QoderWork の拡張機能エコシステムと 4 種類の拡張機能それぞれの掲載要件を紹介します。

​
QoderWork 拡張機能エコシステム

QoderWork は 4 種類の拡張機能を通じて、ユーザーが AI に能力・役割・外部接続を必要に応じて装着し、「汎用アシスタント」から自身のビジネスに最適化された「専属インテリジェントエージェント」へと進化させることを可能にします。4 種類の拡張機能はそれぞれ独立しつつ、相互に組み合わせることができます。Skill はアトミックな能力を提供し、Plugin は能力をエキスパートロールとしてパッケージ化し、Connector は外部システムとの接続を確立し、ワークベンチは垂直シナリオ向けの完全なインターフェースを提供します。

​
Skill — アトミック能力

Skill は QoderWork における最も基本的な能力ユニットであり、1 つの Skill は AI が再利用できる「タスク遂行メソッド」に相当します。ユーザーが該当するタスクを提示すると、AI は対応する Skill を自動的に呼び出し、組み込まれたステップ・ルール・サンプルに従って作業を完了します。これにより、特定のシナリオにおけるパフォーマンス品質が大幅に向上します。 典型的なシナリオ: PDF レポートの生成、専門的な契約書の作成、ユーザーフィードバックデータの分析、週報の整理など。 特徴: 粒度が小さく、インストール後すぐに使用可能で、複数のエキスパートキットから共有して再利用できます。上位レベルの能力を構築するための基盤となります。

​
Plugin（エキスパートキット）— バーチャルポジションエキスパート

Plugin は、実在する職種や専門的な役割を中心に構成された能力の集合体です。複数の Skill、いくつかの Connector 依存関係、およびポジション指示ドキュメントで構成されます。インストールすると、QoderWork 内に「バーチャル同僚」が加わり、そのポジションの完全なワークフローを独立して遂行できます。 典型的なシナリオ: スーパー HR（採用一括管理）、スーパー法務（契約レビュー）、スーパー経理（消込と異常分析）、スーパープロダクトマネージャー（要件企画）など。 特徴: ポジションを中心に据え、能力が相互に連動し、完全なワークフローを備えています。「一人で一チーム分の仕事」が求められる複合タスクシナリオに最適です。

​
Connector — 外部システムコネクター

Connector は QoderWork とサードパーティシステム間の標準化された接続チャネルであり、本質的には OAuth 認可をサポートする MCP Server です。インストールして認可を完了すると、AI はユーザーが許可した権限範囲内で対応システムのデータを読み書きし、外部ビジネスシステムをワークフローに組み込むことができます。 典型的なシナリオ: DingTalk、Notion、Slack、Jira、企業 CRM、または社内ビジネスシステムへの接続など。 特徴: サービス単位で管理され、ユーザー認可は制御可能です。任意の Skill やエキスパートキットから呼び出すことができ、AI が実際のビジネスデータにアクセスするための重要なエントリーポイントとなります。

​
ワークベンチ — 垂直シナリオ向けの独立した作業インターフェース

ワークベンチは QoderWork の中でも比較的重厚な拡張機能であり、特定の専門シナリオに独立した作業インターフェースと状態管理を提供します。関連する Skill、Connector、カスタム UI を 1 つのキャンバス上に統合します。汎用の会話インターフェースと比較して、ワークベンチは高頻度・状態管理が複雑・マルチタスク並行の専門的な作業シナリオにより適しています。 典型的なシナリオ: バリュエーション検証ワークベンチ、契約レビューワークベンチ、営業リードダッシュボードなど。 特徴: 独立したインターフェースと状態を持ち、単一の垂直シナリオに特化し、インタラクションフローを深くカスタマイズできます。専門職向けの「専用ファクトリー」です。

​
掲載要件

4 種類の拡張機能は同一のセルフサービス掲載チャネルを共有します: QoderWork 内で提出 → 審査通過 → 公開マーケットプレイスに掲載。審査に通過するとユーザーに公開され、「マイ公開」で継続的に管理できます。以下では、各種拡張機能の最も重要な差異化要件のみを記載します。

​
Skill 掲載要件

Skill の核心的な価値は「AI に正確に理解され、安定して再利用されること」にあるため、審査の重点はコンテンツ品質そのものに置かれます:
  • 内容が明確であること: 説明は第三者視点で Skill の役割とトリガーシナリオを記述し、ユーザーが自然言語で使用する可能性のあるキーワードを含める必要があります。これにより、AI が適切なタイミングで呼び出せるようになります。
  • 構造が合理的であること: 本文には明確な使用手順、注意事項、検証方法を含める必要があります。プレースホルダー（例: TODO、<your-token>）や直接実行できない疑似コードは含めないでください。
  • 安全で無害であること: 悪意のあるスクリプト、不審な外部リクエスト、権限を超える命令を含めてはなりません。また、サンプル内に実際の認証情報を漏洩させてはなりません。
Skill は機械審査を主体とし、人手によるスポットチェックを補助とする審査メカニズムを採用しており、通常は数分以内に結果が得られます。

​
Plugin（エキスパートキット）掲載要件

Plugin は「一人のエキスパート」の完全な能力を体現するため、審査ではキット全体としての合理性と専門性がより重視されます:
  • キット構造に準拠していること: 規定に従ってディレクトリを構成し、完全なメタデータ（plugin.json）、内蔵の Skill、および必要なロール指示ドキュメントを提供する必要があります。また、内蔵された各 Skill 自体もルールに準拠している必要があります。
  • ポジションを中心に構成されていること: キット名は実在する職種名（2〜6 文字）を直接使用することを推奨します。含まれる Skill と Connector の間には明確な協調関係が存在する必要があり、無関係な能力を単純に寄せ集めることは避けてください。
  • 依存関係が解決可能であること: キット内で参照される Connector は、マーケットプレイスに掲載済みの有効なエントリーである必要があります。
Plugin は提出前にクライアント側で構造のプリチェックが行われ、プリチェック通過後は Skill と同様の機械審査フローに入ります。

​
Connector 掲載要件

Connector は外部データアクセスとユーザー認可に関わるため、審査要件が最も厳しい拡張機能タイプです。原則として、各企業は自社サービスに対して 1 つの公式 Connector を提出できます:
  • OAuth 対応の MCP Server であること: パブリックにアクセス可能な HTTPS MCP Server であり、完全な OAuth 認可フローを実装して、ユーザーのアクセス権限が制御可能かつ取り消し可能であることを保証する必要があります。
  • 企業身元確認: 掲載申請者は対応するサービスの企業の信頼できる担当者である必要があり、提出時には公式の実名認証または企業認証に協力する必要があります。公式側から電話でアップロード者の身元を確認します。
  • 法務およびプライバシーコンプライアンス: 公開アクセス可能なプライバシーポリシーと利用規約を提供し、収集するデータの範囲と使用目的を明確に説明する必要があります。
  • セルフテストレポートの完備: 接続性検証、代表的なツール呼び出し、権限範囲、例外処理、およびサービス可用性をカバーするセルフテスト説明書を提出する必要があります。
Connector は機械審査を通過した後、人手による最終審査に統一的に進みます。自動的に承認されることはありません。

​
ワークベンチ掲載要件

ワークベンチは比較的複雑な拡張機能であり、完全なインターフェースとビジネスフローを持つため、エンジニアリング面での納品要件がより高くなります:
  • SDK 仕様に準拠していること: QoderWork 公式提供のワークベンチ SDK をベースに開発する必要があり、準拠したマニフェストファイル、UI リソース、および MCP Server 実装を含む必要があります。
  • 垂直シナリオが明確であること: 各ワークベンチは 1 つの明確な専門シナリオに焦点を当て、完全な入力・処理・出力パイプラインを備える必要があります。
  • リソース境界が明確であること: ワークベンチが依存する Skill、Connector はキット内で明示的に宣言し、SDK が提供するインターフェースを通じて統合と権限確認を完了する必要があります。
ワークベンチはインターフェースと状態の深いカスタマイズを伴うため、提出前にエンドツーエンドのウォークスルーを完了し、QoderWork 内で安定して読み込みおよび実行できることを確認することを推奨します。

​
拡張機能仕様

本章では、各種拡張機能の構造とフォーマットに関する具体的な要件を示します。上記の掲載要件を満たすと同時に、本章に記載された仕様に準拠する必要があります。

​
Skill 仕様

各 Skill は独立したフォルダを単位とし、コアファイルは SKILL.md で、その他は任意の参考資料です。 ディレクトリ構造 
<skill-name>/
├── SKILL.md          # スキル定義ファイル（必須）
└── references/       # 参考ファイルディレクトリ（任意、テンプレート・サンプル・データなどの補助資料を格納）
    ├── template.md
    └── example.json
SKILL.md フォーマット ファイル先頭に YAML Frontmatter、本文は Markdown です: 
---
name: contract-review           # スキル識別子（必須）
description: 契約条項を審査し、リスクポイントを指摘します。ユーザーが契約ファイルをアップロードして審査を依頼する際に適用されます。  # 機能説明（必須）
version: 1.0.0                  # バージョン番号（任意）
---
命名規則
  • 小文字の英字、数字、ハイフン（-）のみ使用可能です。ハイフンで開始または終了することはできません
  • 最大 64 文字まで
  • 名前はスキルの一意な識別子であり、公開後は変更できません
バージョン番号 セマンティックバージョニング（Semantic Versioning）を採用し、フォーマットは メジャー.マイナー.パッチ（例: 1.2.0）です。新しいバージョンを公開するたびにインクリメントする必要があります。 参考ファイル references/ ディレクトリは、Skill の実行中に参照される可能性のある補助資料（ドキュメントテンプレート、フォーマットサンプル、辞書データなど）を格納するために使用します。このディレクトリ内のファイルは、AI が Skill を呼び出す際にコンテキストとして提供され、追加の設定なしで機能します。

​
Plugin（エキスパートキット）仕様

Plugin はフォルダを単位とし、複数の Skill、ロール指示、MCP 依存関係を 1 つの完全なポジションエキスパートとして構成します。 ディレクトリ構造 
<plugin-name>/
├── .qoder-plugin/           # プラグインメタデータディレクトリ（必須）
│   └── plugin.json          # メタデータマニフェスト（必須）
├── skills/                  # スキルディレクトリ（コア）
│   ├── スキルA/SKILL.md
│   └── スキルB/SKILL.md
├── agents/                  # subagent ロール設定（任意）
│   ├── agentA.md
│   └── agentB.md
├── .mcp.json                # MCP Connector 宣言（任意）
├── qoder.md                 # プロジェクト指示ファイル（任意、cursor.md / claude.md と互換）
├── CONNECTORS.md            # Connector 依存関係説明（任意）
└── README.md                # プラグイン説明ドキュメント（任意）
plugin.json のポイント plugin.json は、キットの名前、バージョン、含まれるスキル一覧、およびロール情報を宣言します。名前は実在する職種名（2〜6 文字）を推奨します。 宣言型 MCP Connector 設定（任意） キット内の Skill が外部システムの呼び出しを必要とする場合、.mcp.json ファイルで必要な MCP Server 接続を宣言できます。ユーザーがキットをインストールする際に、QoderWork が対応する認可設定の完了をガイドします。 
{
  "mcpServers": {
    "DingTalk ログ": {
      "type": "streamable-http",
      "url": "{{USER_CONFIG}}",
      "_setup": {
        "configUrl": "https://aihub.dingtalk.com/#/detail?mcpId=9639",
        "guide": "上記のリンクにアクセスして DingTalk にログインし、個人用の MCP Server URL を取得してください",
        "required": true
      }
    }
  }
}
各フィールドの説明:
  • type: トランスポートプロトコル。streamable-http と stdio をサポートします
  • url: プレースホルダーとして {{USER_CONFIG}} を記入します。ユーザーのインストール時に実際のアドレスに置き換えられます
  • _setup.configUrl: ユーザーが認証情報やアドレスを取得するためのページリンク
  • _setup.guide: ユーザーに表示される設定説明テキスト
  • _setup.required: 必須項目かどうか。true に設定すると、ユーザーが設定を完了しない限り、この接続は使用できません
このファイルは任意です。キットが外部システムに依存しない場合は、提供する必要はありません。

​
Connector 仕様とガイド

Connector は本質的にパブリックネットワーク向けの MCP Server であり、以下の技術要件とコンプライアンス要件を満たす必要があります。 技術要件
  • サービスアドレスは HTTPS で、パブリックにアクセス可能な安定したドメインである必要があります（プライベート IP や一時的なトンネルは受け付けません）
  • 完全な OAuth 2.0 認可フローを実装し、ユーザー認可が制御可能かつ取り消し可能であることを保証する必要があります
  • ツール（Tool）定義には明確な名前と説明を付け、パラメータは JSON Schema で型と制約を宣言する必要があります
  • プラットフォームがサービス可用性を監視できるよう、ヘルスチェックエンドポイントの提供を推奨します

​
公開後の管理

掲載に成功した後、作成者は「設定 → マイ公開」で公開済みの拡張機能を一元管理できます。インストール数の確認、公開情報の変更、新バージョンの公開、一時的な掲載停止と再掲載などの操作が含まれます。「公開情報の変更」は軽量な機械審査のみがトリガーされ、インストール済みユーザーには影響しません。「新バージョンの公開」は完全な審査フローが再度実行され、インストール済みユーザーには更新通知が届き、アップグレードするかどうかを自主的に選択できます。 拡張機能がリジェクトされた場合、「マイ公開」で具体的な理由を確認し、要件に従って再提出できます。必要に応じて、異議申し立てを行うこともできます。作成者による自主的な掲載停止または公式による強制掲載停止のいずれも、インストール済みユーザーのローカルコピーを強制的に削除することはありません。ただし、マーケットプレイスには表示されなくなり、新規ユーザーへの配信も行われなくなります。
公開フローや掲載仕様についてご不明な点がありましたら、QoderWork 公式フィードバックチャネルを通じて審査チームにお問い合わせください。