greenlight:App Storeのリジェクトを事前に潰すプリフライトCLI
greenlightは、サブミット前にAppleのReview Guidelinesに照らして違反候補を検出するGo製OSS。タグラインは「Know before you submit.」。

この記事はOSS観察・解説記事です。 RevylAI/greenlight は、App Storeへのサブミット前に、Appleのレビュアーが指摘しそうな違反を自分のマシン上で先回りして検出するプリフライトCLIです。 本稿は2026年6月21日(JST)時点で、公式リポジトリとREADMEから確認できる事実を整理し、何ができるか・どう使うか・他ツールとどう違うかを切り分けます。

iOSアプリ開発者なら誰しも、「ビルドしてTestFlightに上げ、Appleにサブミット、数日待って Rejection のメールが届く」という痛みを経験したことがあるでしょう。 リジェクト理由はPrivate APIの混入、Required Reason APIの宣言漏れ、Sign in with Apple の不備、PrivacyInfo.xcprivacy の不整合、purpose stringの曖昧さなど、事前に気づけたはずのもの が大半です。 greenlightは、その「気づけたはず」を静的に拾い切るためのツールです。

この記事のポイント
  • ・greenlightは、ソース・マニフェスト・IPA・App Store Connectの4層をAppleのReview Guidelinesに照らして事前スキャンするGo製OSS CLI。デフォルトは完全オフライン・アップロードゼロで1秒以下。
  • ・看板コマンドはpreflight。4つのスキャナを並列実行し、リジェクト傾向に該当する違反候補を一覧化する。
  • ・結果はAppleのReview Guidelinesのセクション番号付き(§2.5.1 Private API、§4.8 Sign in with Apple等)で返るため、開発者がアクションを取りやすい。
  • Claude Code / CodexのスキルとしてSKILL.mdを同梱。「GREENLITになるまで全部直して」でエージェントが自動修正ループを回せる。
  • ・まだv0.1.0。出力フォーマットは変わり得るため本番CIではタグにピン留めが無難。Android / Google Playは対象外。

このツールはGo製CLIであると同時に、AIコーディングエージェントのスキルとして動かす設計が前提に置かれています。Claude Codeをスキルやフックまで含めて運用する全体像は Claude Code|2026年版・インストールからCLAUDE.md・Hooks・本番運用までの実装手引き にまとめてあるので、エージェント連携の前提を確認したい場合はあわせて読むと理解が早まります。

1. greenlightとは何か — App Store審査の「事前検出」という発想

greenlightを一言で言うと、「Appleのレビュアーに指摘される前に、自分のマシン上で同じことをチェックする」ためのプリフライトCLIです。 コンセプトはリポジトリのタグラインに集約されています。

Know before you submit. Pre-submission compliance scanner for the Apple App Store.

つまり「サブミット前に知る」。 リジェクトのメールを3日待ってから対応するのではなく、ビルドした瞬間に違反候補を洗い出してしまおう、という発想です。

特筆すべきは、デフォルトの動作が 完全オフライン・アカウント不要・アップロードゼロ であること。 CI/CDパイプラインに組み込んでも、コードを外部に送信しません。 スキャンは1秒以下で完了し、リンタ感覚で何度でも回せます。

基本情報(2026-06-21時点)

公式リポジトリから確認できる基本情報は次のとおりです。

項目
リポジトリRevylAI/greenlight
言語Go 99.7%
ライセンスMIT
Stars / Forks約1.4k / 90
最新リリースv0.1.0(2026-02-11)
コミット数25(mainブランチ時点)
開発元Revyl(モバイル信頼性プラットフォーム)

リリースタグがv0.1.0ひとつ、コミット数も25と、プロジェクトはまだ初期段階です。 それでもStar 1.4kと勢いがあるのは、「審査リジェクトを事前に潰す」というテーマが開発者の痛点に刺さっているからでしょう。 開発元のRevylはクラウドデバイス上でAIテストを提供するモバイル信頼性プラットフォームで、後述するverifyコマンドはこのRevyl基盤と連携します。

なぜ静的検出が効くのか
AppleのReview Guidelinesは、Private APIの混入・シークレットのハードコード・マニフェストの不整合など、コードや成果物から静的に検出しやすいルールが意外と多い。greenlightはそこを起点に設計されているため、golangci-linteslintのような感覚で「リジェクトされる/されない」を機械的に拾える。

2. greenlightの主要機能 — preflightと7系統のスキャナ

greenlightのスキャナは大きく分けて4系統 +αで構成されます。 それぞれ単独コマンドとしても呼べますが、実運用の中心は全部入りのpreflightです。

2-1. preflight — 全部入りの並列スキャン

看板コマンドで、以下の4スキャナを 並列実行 します。

スキャナチェック対象
metadataapp.json / Info.plist:アプリ名・バージョン・Bundle IDの形式・アイコン・プライバシーポリシーURL・purpose strings
codescan30種類以上のコードパターン:Private API・ハードコードされたシークレット・課金違反・ATT欠落・ソーシャルログイン・プレースホルダ
privacyPrivacyInfo.xcprivacy の完成度・Required Reason API・トラッキングSDKとATT実装の整合性
ipaバイナリ:Info.plist キー・Launch Storyboard・アプリアイコン・アプリサイズ・組み込みフレームワークのプライバシーマニフェスト

これら4つが並列に走り、結果がマージされて1つのレポートになります。 最後にCRITICALの有無で「GREENLIT(サブミット可)」か「修正が必要」かが判定される、というのが基本フローです。

flowchart TD A["greenlight preflight ."] --> B["metadata スキャナ"] A --> C["codescan スキャナ"] A --> D["privacy スキャナ"] A --> E["ipa スキャナ"] B --> F["結果をマージ"] C --> F D --> F E --> F F --> G{"CRITICAL あり?"} G -->|"あり"| H["NOT GREENLIT
修正が必要"] G -->|"なし"| I["GREENLIT
サブミット可"]

2-2. codescan — コードパターン専用スキャン

Swift / Objective-C / React Native / Expoに対応し、30種類以上のパターンを検出します。 結果は AppleのReview Guidelinesのセクション番号付き で返るのが特徴です。 READMEに列挙されているチェック項目を抜粋すると以下のとおりです。

・§2.5.1 Private APIの使用 — CRITICAL
・§1.6 ハードコードされたシークレット / APIキー — CRITICAL
・§3.1.1 デジタル商品の外部決済 — CRITICAL
・§2.5.2 動的なコード実行 — CRITICAL
・§3.1.5 暗号資産マイニング — CRITICAL
・§4.8 ソーシャルログインに伴うSign in with Appleの欠落
・§3.1.1 IAPに対するRestore Purchasesの欠落
・§5.1.2 広告/トラッキングSDKのATT未実装
・§5.1.1 アカウント作成のみで削除導線が無い
・§2.1 文字列内のプレースホルダ / Expoの設定不備
・§2.3 競合プラットフォームへの言及
・§1.6 平文HTTP URL / ハードコードされたIPv4アドレス
・§5.1.1 曖昧なpurpose strings

CRITICALの指摘は、ほぼ確実にリジェクト対象となるレベルです。 「コーディング規約に違反している」ではなく「Appleにリジェクトされる」を出力単位にしているため、開発者にとってアクションが取りやすい結果になります。

2-3. privacy — プライバシーマニフェスト検証

iOS 17以降のPrivacyInfo.xcprivacy関連は実装漏れが多いポイントで、greenlightは次を相互照合します。

・マニフェストの存在と整形
・コード上で検出したRequired Reason APIと宣言の差分
・検出されたトラッキングSDKとATT実装の整合

「コードに書いてあるのにマニフェストに無い」「マニフェストにあるのにコードに無い」を自動でクロスチェックしてくれるのが地味に効きます。 ここはコードとマニフェストの両方を読まないと判定できない領域なので、単純なリンタでは拾いにくい部分です。

2-4. ipa — ビルド済みバイナリのインスペクション

ビルド済みIPAに対してチェックします。

PrivacyInfo.xcprivacy の同梱
Info.plist の完成度とpurpose stringの質
・App Transport Securityの設定
・アプリアイコンの有無とサイズ
・Launch Storyboardの有無
・200MBのセルラーダウンロード上限に対するアプリサイズ
・組み込みフレームワークのプライバシーマニフェスト

ソースだけでなく、最終成果物のバイナリそのものを検査できるのがポイントです。

2-5. scan — App Store Connect API連携

ローカルではなく、App Store Connect側に登録された状態をチェックします。

・メタデータの完成度(説明文・キーワード・URL)
・必須デバイスサイズのスクリーンショット
・ビルド処理状況
・年齢制限・暗号化申告
・コンテンツ分析(プラットフォーム参照・プレースホルダ)

事前にgreenlight auth setup(APIキー)またはgreenlight auth login(Apple ID + 2FA)が必要です。 このコマンドだけはApp Store Connect APIへの接続が前提になります。

2-6. verify — ランタイム検証(Revyl連携・opt-in)

個人的に最も面白いのがここです。 静的解析は「deleteAccountという文字列が存在する」ことしか確認できないので、ボタンが繋がっていない死んだ実装 は素通りしてしまいます。 Appleは§5.1.1(v)でその種のdead-endを弾きにかかります。

verifyは実機/クラウドデバイス上で実際にフローを走らせ、動作することを確認 します。

フローガイドライン静的解析では不可能な検証
account-deletion§5.1.1アカウントが実際に削除される
restore-purchases§3.1.1"Restore Purchases" が無音のno-opでないこと
sign-in-apple§4.8Appleサインインシートが実際に表示される

これはRevylという同社の有料プラットフォームを使うため、唯一オフライン動作しないコマンド です。あくまでopt-inで、preflightだけを使う運用とは独立しています。

2-7. guidelines — Apple ガイドライン全文検索

オフラインでAppleのReview Guidelinesをブラウズ・検索できます。

greenlight guidelines search "privacy"

リジェクト対応の調査時に、該当セクションをすぐ引けるのは地味に便利です。

3. インストールとクイックスタート

greenlightはGoバイナリ単体配布で、依存も少なく入れやすい構成です。

# Homebrew(macOS)
brew install revylai/tap/greenlight

# Go install
go install github.com/RevylAI/greenlight/cmd/greenlight@latest

# ソースからビルド
git clone https://github.com/RevylAI/greenlight.git
cd greenlight && make build
# バイナリ: build/greenlight

導入後は、プロジェクトのルートでpreflightを一発打つだけです。

# プロジェクト全部をスキャン — 1コマンド、アップロード無し
greenlight preflight /path/to/your/project

# IPA を加えてバイナリ解析もする
greenlight preflight . --ipa build.ipa

これだけで1秒以下にフルレポートが返ってきます。 アカウント登録もログインも不要で、ローカルで完結します。

4. CI/CDへの統合 — GitHub ActionsとJUnit出力

JSON出力を使えば、CIに組み込んでCRITICALでパイプラインを落とすのも簡単です。 golangci-lintをCIに入れるのと同じ感覚で、App Storeコンプライアンスチェックをマージ前のゲートにできます。

- name: App Store compliance check
  run: |
    greenlight preflight . --format json --output greenlight-report.json
    # CRITICAL があればパイプラインを落とす
    if jq -e '.summary.critical > 0' greenlight-report.json > /dev/null; then
      echo "CRITICAL issues found — fix before submission"
      exit 1
    fi

scanコマンドはJUnit形式の出力にも対応しているため、CIのTest Reportビューに結果を載せることもできます。

greenlight scan --app-id $APP_ID --format junit --output greenlight.xml
本番CIではタグにピン留めを
greenlightはまだv0.1.0で、出力フォーマットやJSONスキーマ(.summary.critical 等のキー)は今後変わる可能性がある。本番のCIに組み込む際は @latest ではなく特定リリースタグにピン留めし、アップデート時に出力構造を確認するのが無難。

5. Claude Code / Codexスキルとしての自動修正ループ

ここが他のリンタ系ツールにあまり無い特色です。 greenlightは AIコーディングエージェントが「スキャン → 修正 → 再スキャン」をループで回すためのSKILL.mdを同梱 しています。 このスキル連携の発想を理解するうえでは、エージェントにスキルを与えて思考を底上げする Addy OsmaniのAgent Skills|AIコーディングエージェントに上級エンジニアの思考を注入する20のスキル や、スキル資産をGitで管理する Agent Skill Harbor徹底解説|AIエージェントのスキル資産をGitで一元管理するOSS基盤 も参考になります。

スキルの導入は、SKILL.mdをプロジェクトにコピーするか、CLAUDE.mdから参照させるだけです。

# スキルファイルをプロジェクトにコピー
mkdir -p .claude/skills
cp /path/to/greenlight/SKILL.md .claude/skills/greenlight.md

# あるいは CLAUDE.md から参照する
echo "See greenlight skill: /path/to/greenlight/SKILL.md" >> CLAUDE.md

あとはClaudeにこう言うだけです。

“Run greenlight preflight and fix everything until it passes”

するとエージェントが以下を自律的に回します。

flowchart LR S["1. greenlight preflight 実行"] --> R["2. 全 finding を読み込み"] R --> P["3. CRITICAL から順に修正
WARN・INFO と続く"] P --> C{"4. GREENLIT?"} C -->|"未達"| S C -->|"達成"| D["完了"]

Codex向けのスキルパッケージ(codex-skill/)も同梱されており、~/.codex/skills/app-store-preflight-compliance配下にコピーして同様に使えます。 「リジェクト怖いから人力でチェックリスト消化」という時間のかかる工程を、まるごとエージェントに渡せるのがこのツールの真価です。

なぜ「リンタ+スキル同梱」が効くのか
通常のリンタは「指摘」までで止まり、修正は人間の仕事として残る。greenlightは指摘の出力単位がガイドライン違反=修正対象として明確なので、エージェントが「何をどう直せばCRITICALが消えるか」を判断しやすい。検出と自動修正の相性が良いツール設計になっている。

6. アーキテクチャと検査の4層モデル

リポジトリ直下の構成はおおむね以下のとおりです。

greenlight/
├── .claude-plugin/      Claude Code プラグイン定義
├── .github/workflows/   CI 用 GitHub Actions
├── cmd/greenlight/      CLI エントリポイント(main パッケージ)
├── codex-skill/         Codex 用スキルパッケージ
├── internal/            スキャナ本体(metadata / codescan / privacy / ipa / scan / verify など)
├── LICENSE              MIT
├── Makefile             build / install / test
├── README.md
├── SKILL.md             Claude Code 用スキル定義
├── go.mod / go.sum
└── metadata.json

スキャナはコマンドごとにinternal/配下にモジュール分割されており、preflightがそれらを並列実行して結果をマージする作りです。 .claude-plugin/codex-skill/がリポジトリ直下に並んでいることからも、AIエージェント連携が後付けではなく設計の最初から織り込まれていることが読み取れます。

scanコマンドはTier 1〜4という階層構造で、段階的に深掘りする設計になっています。

階層検査内容
Tier 1メタデータ完成度(説明文・キーワード・URL)
Tier 2コンテンツ分析(プラットフォーム参照・プレースホルダ)
Tier 3バイナリ検査
Tier 4履歴パターンマッチ

なおinternal/以下のファイル単位の詳細はREADMEに記載がないため、実装の詳細を追う場合はリポジトリ内のコードを直接参照する必要があります。 本稿で「設計」と書いている部分は、READMEのアーキテクチャ記述から読み取れる範囲に留めています。

7. 実用ユースケースと注意点

実運用での当てどころは大きく3つあります。

第一に、サブミット直前の最終チェック。 「ビルドできた、明日App Store Connectにアップロードしよう」というタイミングでgreenlight preflight . --ipa build.ipaを一発打つだけで、人間がチェックリストを確認するより圧倒的に網羅的・高速に違反候補を洗い出せます。

第二に、PRごとの予防的チェック。 GitHub Actionsに組み込み、CRITICALが出たらCIを落とす運用にすれば、Private APIの混入やシークレットのハードコードといった「マージしてから気づくと辛い」類のミスをレビュー前に弾けます。

第三に、AIエージェントによる自動修正。 Claude CodeやCodexのスキルとして組み込めるため、CRITICALを最優先に潰しつつGREENLITに持っていくワークフローをエージェントに渡せます。 加えてverifyを使えば、「Delete Accountボタンはあるが押しても何も起きない」「Restore Purchasesがno-op」といった静的解析の盲点を、クラウドデバイス上の実機テストで詰められます。

一方で、率直な課題感も書いておきます。

まず、プロジェクトはまだ初期段階 です。 リリースタグはv0.1.0ひとつのみで、API・出力フォーマットは今後変わる可能性があります。 productionなCIに組み込む際は、特定リリースタグにピン留めしておくのが無難でしょう。

次に、Appleのレビュー基準は人間判断を含む ものが多く、greenlightがGREENLITを返したからといってリジェクトされない保証は当然ありません。 あくまで「静的に検出できる範囲の典型違反を確実に拾う」ためのツールであり、UXや機能の独自性に関する§4系の指摘まではカバーできません。

verifyのRevyl依存 も留意点です。 クラウドデバイスでフローを実行する性質上、Revylアカウントと有料のデバイス時間が必要で、唯一オフライン動作しないコマンドです。 「静的スキャナとしてのpreflightだけ使う」のは完全に独立した選択肢として保たれています。

最後に、Android / Google Playは対象外 です。 greenlightはあくまでApple App Store専用で、現状そのスコープを広げる気配はREADMEからは読み取れません。

8. 類似OSSとの違い — 4層横断とエージェント前提設計

App Store関連のリンタは意外と少なく、近いカテゴリではSwiftLint(コードスタイル)、periphery(未使用コード検出)、xcprivacy系のGitHub Action(マニフェスト検証)などがありますが、いずれも対象範囲が部分的です。

ツール主な対象カバー範囲
greenlightソース+マニフェスト+IPA+ASCリジェクト要因を横断検出(ガイドライン番号付き)
SwiftLintSwiftソースコードスタイル / 規約
peripherySwiftソース未使用コード検出
xcprivacy系 Actionマニフェストプライバシーマニフェスト検証

greenlightの独自性は次の3点でしょう。

第一に、「AppleのReview Guidelinesセクション番号」を起点にチェック設計 している点。 コーディング規約ではなく「リジェクトされる/されない」を出力単位にしているため、開発者にとってアクションを取りやすい結果になります。

第二に、ソース / マニフェスト / IPA / App Store Connectの4層を1つのCLIで横断 していること。 それぞれに別ツールを用意するのに比べ、preflightで並列実行されるのは大きな運用上の利点です。

第三に、AIエージェント向けのスキル定義を最初から同梱 している点。 Claude Code / Codex双方のスキル形式に対応しており、エージェントによる自動修正ループを前提に設計されています。

まとめ

greenlightは「Appleのレビュアーになる前に、自分でAppleのレビュアーをやる」ためのGo製CLIでした。 preflight一発で静的・マニフェスト・バイナリ・App Store Connectの4層を1秒以下で横断スキャンし、完全オフライン、CIへの組み込みもJSON / JUnit出力で容易、おまけにClaude / CodexのスキルとしてAIに修正させることまでできる、という非常に欲張りなツールです。

確認できた事実を整理すると、次のようになります。

・看板コマンドはpreflight。metadata / codescan / privacy / ipaの4スキャナを並列実行し、CRITICALの有無でGREENLITを判定する
・結果はAppleのReview Guidelinesのセクション番号付きで返る。CRITICALはほぼ確実にリジェクト対象
・デフォルトは完全オフライン・アカウント不要・アップロードゼロ。例外はASC連携のscanと実機検証のverify
・SKILL.mdとcodex-skill/を同梱し、エージェントによる「スキャン→修正→再スキャン」ループを前提に設計
・Go製・MITライセンス・Star約1.4k。ただしまだv0.1.0で、本番CIはタグ固定が無難。Android / Google Playは対象外

結論
リジェクトの返り待ち時間を「リジェクトの可能性自体を事前に潰す」時間に変えてくれるという点で、iOS開発者なら入れて損は無いツール。まだv0.1.0だが設計思想がはっきりしているので、preflightをローカルとCIに入れ、CRITICALだけは確実に潰す——という最小構成から試すのがおすすめ。verifyやASC連携は必要になってから足せばよい。

参照ソース

RevylAI/greenlight(公式リポジトリ・README)
RevylAI/greenlight README(raw)
greenlight Releases(v0.1.0)
Apple App Review Guidelines(本家)
Revyl(開発元)