niyaseベータ
開発者ドキュメント
公開申請·

公開申請（認定プラグイン）

開発者登録 → 名前空間 claim → niyase-plugin publish → 人手審査 → 公開 の流れ。SDK は npm 公開済み。

認定プラグイン（CERTIFIED）をマーケットプレイスで公開するまでの流れです。本ページは第三者が開発する認定プラグインが対象です。niyase 自身が作る公式プラグインは別の内部リリース経路（自動承認）を使うため対象外です。

@niyase/plugin-sdk は MIT ライセンスで npm に公開済みです。モノレポの外からでも npm install @niyase/plugin-sdk や npx @niyase/plugin-sdk new でそのまま開発を始められます（セットアップ）。

STEP 1: 開発者登録

marketplace の開発者ポータル（marketplace.niyase.com/developer、ログイン後は /me）で開発者プロフィール（表示名・slug）を登録します。

STEP 2: 名前空間を claim

プラグイン ID の @scope 部分（名前空間）を claim します。 @your-org/tasks を申請するには @your-org を所有している必要があります（先着順。@niyase は公式用に予約済み）。

STEP 3: 公開トークン（PAT）を発行

開発者ポータルで plugin.* スコープの Personal Access Token（PAT） を発行します。既存の個人アクセストークンと同じ仕組みですが、資格は明確に分離されています。plugin.* だけのトークンは通常の API を呼べず、開発者ポータル専用のルートしか通れません。

スコープ用途
plugin.publish申請の作成・提出
plugin.read.statsインストール統計参照
plugin.manageプロフィール・名前空間管理

有効期限は必須で、既定 90 日・上限 365 日です（無期限トークンは発行できません）。開発者ポータルの画面から発行すると plugin.publish + plugin.read.stats が既定で付与されます。plugin.manage が必要な場合や有効期限を変えたい場合は API を直接呼んでください。PAT を使って新しい PAT を発行することはできません（セッションログイン中のみ発行可能です）。

STEP 4: 申請

CLI でビルド・検証・申請までを一括で行います。

NIYASE_TOKEN=<your plugin.publish PAT> niyase-plugin publish
# ✓ built (sha256 …)
# ✓ manifest 検証 OK (@your-org/tasks)
# ✓ 申請を送信しました (submission ..., state=SUBMITTED)

publish は内部で次を行います: ビルド → validateManifest() → 申請作成（DRAFT）→ バンドルアップロード（multipart、sha256 付き）→ 審査依頼（SUBMITTED）。 --dry-run を付けるとビルドと検証までで停止します（ネットワークに出ません）。トークンは --token / NIYASE_TOKEN / ~/.niyaserc の順で解決され、送信先は既定で https://api.niyase.com（--registry / NIYASE_REGISTRY で変更可）です。

公開の要件

審査の対象になるには、次を満たす必要があります。

  • プラグイン ID が @名前空間/名前 の形式であること（例: @your-company/your-plugin）
  • マニフェストに niyase のカテゴリを指定していること
  • displayName / description が明確で、誇大な表現を含まないこと
  • ライセンスを明示していること（MIT・Apache 2.0 等の OSS、または商用ライセンス）
  • 外部 API を呼ぶ場合は、通信先と取得データの目的を明示すること
  • ユーザーデータの扱いがプライバシーポリシーに沿っていること

STEP 5: 審査 → 公開

申請は状態機械（plugin_submission.state）で進みます。カッコ内は開発者ポータルでの表示ラベルです。

DRAFT（下書き） → SUBMITTED（申請済） → IN_REVIEW（審査中）
  → { CHANGES_REQUESTED（修正依頼） | APPROVED（承認） | REJECTED（却下） }
CHANGES_REQUESTED → SUBMITTED（修正して再提出）
APPROVED → PUBLISHED（公開）
{DRAFT | SUBMITTED | IN_REVIEW | CHANGES_REQUESTED} → WITHDRAWN（取り下げ）

PUBLISHED / REJECTED / WITHDRAWN は終端状態です。バージョン更新は新しい申請として作成し、再審査を受けます。

niyase スタッフが manifest とバンドル（署名付き URL）を確認し、承認 → 公開でマーケットプレイスに掲載されます。修正依頼はコメント付きで差し戻され、修正して再提出できます。申請中はいつでも取り下げ（withdraw）できます。申請状況は開発者ポータルのダッシュボードから確認できます。

公式プラグイン（niyase 自身が作る @niyase/*）は別の内部スクリプトで自動承認されてリリースされます。認定プラグインは第三者のコードであるため、必ず人の手による審査を経ます。

実行基盤

認定プラグインのサーバーサイド処理はプラグイン開発企業が自社のインフラで提供します。niyase はコンピューティングリソースを提供しません。niyase が提供するのは次のものです。

提供物説明
Webhookプラグインイベントを外部サーバーに通知
API キー認証外部サーバー認証用トークン
コールバック API外部サーバー → niyase の結果返信
汎用 CRUD APIプラグイン専用テーブルへの読み書き（コア API 連携）
バンドル配信GCS からのプロキシ配信。読み込み時に sha256 を再検証（不一致は配信を拒否）

公開されたバンドルは、cloud では sandboxed iframe、desktop では <webview>、mobile では React Native WebView という、それぞれ別実行文脈で動きます（ホストの Cookie / localStorage には触れず、通信はブリッジ限定）。この配信は cloud に限定されず、cloud / desktop / mobile の 3 アプリすべてが対象です。

現時点では使えないもの（GA まで）

  • プラグインの自社サーバーへの直接連携: ブラウザ上で動くプラグイン UI から、開発者自身のサーバーへ直接 fetch する経路（niyase.partner proxy）は GA まで実装されません。ブラウザ側の bridge が使えるのは niyase.data / niyase.core のみです。自社サーバーとの連携が必要な場合は、サーバー間（あなたのサーバー → niyase のコールバック API）で完結させてください。
  • 独自ドメイン: developer.niyase.com は GA で用意予定の marketplace への vanity ドメインです。現在は marketplace 内の開発者ポータル（marketplace.niyase.com/developer）を使います。

公開後

  • バージョン更新は新しい申請として再審査されます
  • インストール数・申請状況は開発者ポータルのダッシュボードで確認できます
  • 整合性: 配布バンドルはアップロード時の sha256 と照合され、不一致なら配信されません