> For the complete documentation index, see [llms.txt](https://developer.eagle.cool/plugin-api/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.eagle.cool/plugin-api/ja-jp/plugin-review/criteria/configuration-and-reviewability.md).

# リリース設定と審査可能性

すべての提出物は安全に開くことができ、審査に必要な基本設定と情報を備えている必要があります。展開できないパッケージ、必須設定がないパッケージ、開発用設定のままのビルドは、現在の提出を不合格にします。

## 有効なパッケージを提出する

Eagleを使用して `.eagleplugin` を作成し、次の点を確認してください。

* 破損や欠落がなく、正常に開いて完全に展開できる。
* 重複パス、危険なリンク、プラグインディレクトリ外へ書き込む可能性があるパスを含まない。
* 別形式のアーカイブの拡張子を変更したものではなく、最終リリース用のパッケージである。
* ダウンロードや移動の後でも正常にインストールできる。

無効、破損、または安全に展開できないパッケージは、後続の審査へ進めません。既存の `.eagleplugin` を手動で変更せず、クリーンなリリースディレクトリから再構築してください。

## `manifest.json` をプラグインのルートに配置する

リリースは少なくとも次の要件を満たす必要があります。

* プラグインのルートに `manifest.json` がある。
* ファイルに有効なJSONオブジェクトが含まれている。
* `id` と `name` が空でない文字列である。
* `devTools` が `true` に設定されていない。

その他の項目も、プラグインタイプと実際の動作に一致させてください。完全な形式は[manifest.json 設定](/plugin-api/ja-jp/tutorial/manifest.md)を参照してください。

## リリースビルドを提出する

リリースでは開発者ツールを有効にせず、開発者のコンピューターにしか存在しないパス、サービス、環境変数に依存しないでください。提出前にパッケージをインストールし、元のプロジェクトディレクトリなしで動作することを確認してください。

特定のOS、Eagleバージョン、ファイル形式、補助ソフトウェアだけをサポートする場合は、ストアの紹介文で明記してください。制限自体が不合格理由になるとは限りませんが、主要機能を使えなくする制限を説明しないことは問題です。

## 再現可能な審査手順を提供する

特別な設定なしで利用できる場合、通常は追加の審査文書は不要です。次の条件がある場合は、提出時の注記またはルートの `README` に手順を記載してください。

* ログイン、API Token、ライセンスキー、審査用アカウントが必要。
* サーバー、第三者アプリケーション、ローカル連携ツールが必要。
* システム設定の変更や追加権限が必要。
* 特定のテストファイル、データ形式、操作順序が主要機能に必要。
* 支払い、サブスクリプション、試用プランがテストに必要。

審査担当者が主要フローを再現できる情報を提供してください。審査用アカウントは審査期間中に有効である必要があります。テスト用認証情報は提出ページから提供し、実際の認証情報、秘密鍵、ユーザーデータをパッケージに含めないでください。

## 主な不合格理由

* ルートに `manifest.json` がない、または解析できない。
* `id` または `name` に有効な値がない。
* リリースで `devTools` が `true` に設定されている。
* `.eagleplugin` が破損している、または安全に展開できない。
* 認証や特別な環境が主要機能に必要だが、利用可能な審査方法が提供されていない。

問題を修正した後、新しいパッケージを作成し、最初からインストールテストを行ってから再提出してください。