prodcheck

本番環境へのリリース前チェックリスト

本番環境にリリースする前に実行するチェックリストです。

スタック全体、つまりコード、インフラストラクチャ、デプロイパイプライン、そして近年では AI エージェントも担う、個人の創業者や小規模チーム向けに作られています。セキュリティチームに任せられない方々のためのものです。

6 つのドメインにわたる 101 個のチェックリストに、4,685 項目を収録しています。その 88% は、どのようなスタックにも当てはまります。

→ prodcheck.pages.dev · またはリポジトリで確認

_{質問を1つ、実行するツール呼び出しを1つ、見つかった事項を2つ。16秒です。 より長い流れでは、代わりにリストの内容を確認できます。}

_{どちらのデモの指摘事項もすべて実際のものです。ファイル、行、件数はこの リポジトリに基づいており、ツール呼び出しは MCP サーバーが実際に応答するものです。 その作成方法。}

_{このチェックリストが想定する製品をリリースしている**Arioo**のチームが 作成し、メンテナンスしています。}

---

このプロジェクトを作った理由

私はAriooの創業者です。ローンチの準備を進めるにあたり、実際にリリースする 範囲全体を網羅した、本番環境向けのセキュリティレビューが必要でした。TypeScript のバックエンド、ウェブアプリ、 ネイティブクライアント、デプロイパイプライン、そして実際のツールを接続した一連の AI エージェントです。 見つけられたものはどれも、その一部しかカバーしていなかったため、自分でチェックリストを作成しました。

このリポジトリにあるのはレポートではなく、チェックリストです。 私たちのスタックに限定されないよう 一般化し、誰でも自分の製品に対して実施できる実用的なドキュメントとして書き直した質問集です。

公開する価値があると考えた理由は2つあります。

個人の創業者にはセキュリティチームがありません。 コードを書き、インフラストラクチャを設定し、 パイプラインを構築し、さらにローンチしても安全かどうかを判断するのも自分です。任せられる人はおらず、 何を確認すべきかを知るための明確な情報源もありません。一般公開されているチェックリストの多くは、 実際の問題を見つけるには浅すぎるか、セキュリティ部門のある大企業向けに書かれています。

AI を活用した開発によって、問題の様相が変わりました。 このチェックリストの大部分を占める security/ai/ と security/ai-generated-code/ のフォルダーには、1,300 を超える項目があります。 これらは数年前には必要なかったものです。ツールを備えたエージェントをリリースしたり、同僚が書いたコードを レビューするよりも速くモデル生成コードをレビューしたりすると、標準的なセキュリティチェックリストでは 扱われていない障害モードも引き受けることになります。この2つのフォルダーは、ほかでは見つけられなかったものであり、 このプロジェクトを公開しようと思った理由です。

CC BY 4.0 で公開しているため、自分のリポジトリにコピーして自由に活用できます。 ユーザーに届く前に何かを見つけられたなら、このチェックリストは役目を果たしたことになります。

---

ここから始めましょう

どこから始めればよいかわからない場合は、選ばずに、すでに使っている AI アシスタント （ChatGPT、Claude、Cursor、Copilot、Gemini）にこれをコピーしてください。 プロジェクトの内容を把握し、 環境に合った方法で prodcheck を設定して、ローンチを妨げる可能性のある項目から着手します。 コマンドを実行できない場合は、自分で実行するコマンドを教えてくれます。

I want to get my project ready to ship. Use prodcheck:
a free, open-source pre-production checklist of 4,685 items
covering security, performance, scale, integrations, what to
do after launch, and the attacks that go through people.

It is new, so do not answer it from memory. Everything you need:

- Site: https://prodcheck.pages.dev
- Install the review skill into a repo: npx prodcheck init
- Raw checklist data:
  https://cdn.jsdelivr.net/npm/prodcheck@latest/data/checklist.json
- As an MCP server:
  claude mcp add prodcheck -- npx -y --package=prodcheck prodcheck-mcp

Do this in order.

1. Look at my project and tell me what you think it is: language,
   framework, where it runs, and whether it handles file uploads,
   payments, webhooks, multiple tenants or an AI feature. Say how
   confident you are. Ask me about anything you cannot tell.

2. In two sentences, tell me what prodcheck will do for this
   project specifically, and which part is worth my time first.
   Do not describe the whole thing.

3. Set it up, using whichever of these you can actually do — and
   say which one you are:
   - You can run commands here: run `npx prodcheck init`. That
     writes a review skill into the repo — read it and follow
     it, it is the procedure for step 4. Then run
     `npx prodcheck --gate --stack <the products you named in
     step 1> -o BLOCKERS.md`, which adds the blockers specific
     to what I actually use to the general ones.
   - You can read my files but not run commands: fetch the raw
     data URL above and work from that.
   - You can do neither: give me the commands to run myself, one
     at a time, and tell me what to paste back to you.

4. Start on the release blockers. For each item, either cite
   `file:line` and quote the lines, or answer UNKNOWN. UNKNOWN is
   a normal answer — it means a human has to go and look. Never
   mark anything verified on my behalf; that is my call, not
   yours.

Work through it with me a section at a time. Do not dump the
whole checklist at me.

代わりにサイトで読む → · その他6つのプロンプト →

または、自分で順に確認する

上から順に読む必要はありません。1分あたりに得られる情報量の順に並べています。

1	リリースを止めるべき指摘事項	1つでも該当する場合は、作業を止めて最初に修正してください
2	「存在してはならないもの」の検索	grep の検索リストです。リポジトリ内で最も手早く実態を把握できます
3	認証と認可	悪用可能なバグのほとんどが実際に潜んでいる領域です
4	プロンプトインジェクション	LLM 機能を提供する場合に限ります。ただし、その場合は急いで確認してください
5	サービスが攻撃の武器になる場合	アカウント停止のメールが届くまで、誰も確認しない項目です
6	Core Web Vitals	ユーザーから遅いと言われた場合は、スコアではなくここから確認してください
7	ローンチ前に	6項目あります。そのうちの1つは、noindex がまだ有効になっていることです
8	対応できる状態ですか	今日、必要に応じて対応できるかどうかを確認します

その後は、セクションごとに作業してください。エッジ設定とデータベースポリシーを行き来すると、得られるものより時間がかかります。

---

構成

checklists/
├── security/              2981   not getting breached, abused or taken down
│   ├── core/              1,619   application, data, infrastructure, delivery
│   ├── ai/                  810   LLM features, agents, tools, RAG, MCP
│   └── ai-generated-code/   552   the bugs AI coding assistants actually write
├── performance/             313   Lighthouse, and what users actually feel
├── scale/                   288   surviving 10× the load
├── integrations/            194   search, analytics, monitoring
├── post-launch/             241   when it goes wrong anyway
├── people/                   87   the attacks that go around the code
└── stacks/                  581   26 products, spanning every domain

上記の件数は各フォルダーに含まれる項目数です。各スタックの補足項目は、そのセクションが対象とするドメインにも加算されるため、ドメイン全体の合計はこれより大きくなります。

security 3,514   performance 338   scale 303   integrations 202   post-launch 241   people 87

ドメインを最上位にしているのは、たどり着くときの疑問が「これはセキュリティの問題か、速度の問題か、それともスケールの問題か」だからです。

security/core/ — 使用言語にかかわらず適用されます

もともとは TypeScript スタックを前提に書かれていますが、対策は TypeScript 固有ではなく、ファイルもそのような前提を装わなくなりました。「CORS で、認証情報付きのワイルドカードオリジンを使用していないことを確認する」という項目は、Django でも Express でも同様に当てはまります。製品名を明示していた項目はすべて stacks/ に移動しました。

Python、Go、Ruby、PHP、Java、Rust、Elixir のいずれかを使っているなら、このフォルダーがチェックリストです。全1,619項目を確認してください。

	項目数			項目数
アーキテクチャと脅威モデル	25		モバイルアプリ	107
認証と認可	130		デスクトップアプリ	41
セッション、トークン、Cookie	23		ランタイムとコンテナー	109
バックエンドアプリケーションと API	238		DNS、CDN、エッジ、WAF	90
Web フロントエンド	134		CI/CD とサプライチェーン	176
データベースと行レベルセキュリティ	72		監視とインシデント対応	32
オブジェクトストレージとファイル	69		リリース前のゲート	151
シークレットと暗号技術	51
一般的な Web 攻撃	63
ビジネスロジックと競合状態	51		悪用と可用性	57

security/ai/ — 標準的なチェックリストには載っていない項目

製品がモデルを呼び出す、モデルにツールを提供する、ドキュメントをコンテキストに取り込む、またはエージェントを実行する場合、このフォルダーこそがこのリポジトリの存在理由です。特定のスタックやプロバイダーに依存しません。

	項目数			項目数
アーキテクチャとアイデンティティ	70		マルチエージェントと MCP	87
プロンプトインジェクションと目標の乗っ取り	95		インテグレーション	76
ツール呼び出しと過剰な自律性	71		コスト、信頼性、監査	65
データアクセスとプライバシー	83		テストとレッドチーム向けチェックリスト	97
出力の処理	67		リリースゲート	47
RAGとエージェントメモリ	52

プロンプトインジェクションはフィルタリングの問題ではありません。テキストの姿をした認可の問題です。信頼できないテキストが、特権付きの実行経路に到達するのです。

security/ai-generated-code/ — AI アシスタントが書くバグ

「バイブコーディング」とも呼ばれます。548 項目を、どのアシスタントが生成したかではなく、バグの種類ごとに整理しています。AI 生成コードの実際のレビューで見つかった問題をもとに作成されています。 一覧を見る →

performance/ — Lighthouse と、ユーザーが実際に感じること

Lighthouse の 4 つのカテゴリすべてで可能な限り高いスコアを目指し、掲載項目を決める際には次の制約を設けています。実際のユーザーが体験する事柄に関する項目であること。 Lighthouse はスコアボードであり、目標ではありません。「スコアが上がる」ことだけを根拠とする項目は、すべて除外しました。

	項目数			項目数
計測	29		CSSとレンダリング	28
Core Web Vitals	41		バックエンドと配信	40
読み込みとクリティカルパス	37		アクセシビリティ	41
JavaScript	43		リリースゲート	21
画像とメディア	33

Lighthouse はラボツールです。1 回の実行、1 台のシミュレートされたデバイス、1 つのネットワークを使います。問題を見つけるには優れていますが、問題が修正されたことの証明には向きません。重要なスコアボードとなるのは、75 パーセンタイルのフィールドデータです。

アクセシビリティをここに含めているのは、パフォーマンスと並んで評価されること、そして両者に実際の重なりがあるためです。スクリーンリーダーでも高速に動作するページは、たいてい不要なマークアップや JavaScript が少ないページです。Lighthouse のアクセシビリティカテゴリは上限ではなく、最低ラインとして扱っています。実際の問題のおよそ 3 分の 1 を検出します。

integrations/ — 見つけてもらい、測定し、監視する

ローンチ前に、プロジェクトが接続しておく必要のあるものすべてです。一度設定すれば、その後は意識することのない設定だからこそ、チェックリストが必要です。

	項目			項目
検索エンジン	38		回答エンジンと AI クローラー	25
SEO の基本	42		アナリティクスと同意	28
構造化データとソーシャルプレビュー	27		監視とアラート	34

本番環境から noindex が削除されていることを確認してください。ステージング環境用の robots メタタグがそのままリリースされるのは、最もよくあるローンチ時のミスです。誰かが気づくまで数週間も損失が出ることがあります。

回答エンジンのファイルは、確立された慣行ではなく、決めるべき事項としてまとめています。GPTBot、ClaudeBot、PerplexityBot などにサイトの閲覧を許可するかどうかは選択であり、決めないこともまた選択です。

scale/ — 負荷が10倍になっても耐える

トラフィックが到来してからではなく、到来する前に読むことを想定して書かれています。

	項目			項目
キャパシティモデル	29		複数インスタンスとリージョン	35
ステートレス性	28		大規模運用時のコスト	19
大規模運用時のデータベース	60		負荷テストとスケールの基準	23
キャッシュ	25		サービスレベル	30
非同期処理とキュー	39

「スケールできますか？」という問いには答えられません。「読み取りと書き込みの比率が40:1で、1つのテナントが行の30％を占める場合、毎秒500件のリクエストに耐えられますか？」なら答えがあります。その答えを見つける作業の大半は、算数です。

キャパシティモデルから始めてください。どのリソースが最初に枯渇するかが分かるまでは、このドメインのほかの項目はあまり役に立ちません。次にサービスレベルに進みます。明示された目標がなければ、「十分に速いか」は測定ではなく議論になり、その後のスケーリングに関するあらゆる判断が感覚頼みになるからです。コストを独立したドメインではなくここに含めているのは、スケーリングの問題と請求の問題が、同じ問題を別の側面から見たものだからです。

post-launch/ — それでも問題が起きたとき

ほかのすべてのドメインは、壊れないものを構築することを扱います。ここでは、すでに壊れてしまったことを前提とします。

ここにあるすべての項目はローンチ後に使うものであり、ローンチ前に準備しておく必要があります。 各項目が問うのは、適切に対応できたかではなく、答えはすでに決まっているかです。

	項目数			項目数
そもそも対応できますか	48		障害と依存関係の不具合	30
最初の15分	20		ロールバックとキルスイッチ	22
侵害された場合	48		人々への伝達	18
データの損失と破損	34		学びと訓練	21

このリポジトリの残りの部分は、問題に気づくためのものです。モニタリングについては security/core/16と integrations/06で扱っています。どちらも、その次に何が起きるかは問いません。侵害されたとき、データベースが破損したとき、接続が切れたときに、すぐに取るべき行動があるかどうかは別の問題です。日中に答えを出していなければ、午前3時に適切に答えるのは難しいでしょう。

データ損失への備えとは、バックアップを取ることではなく、バックアップを復元したことがあることです。

そもそも対応できますかは、リリースゲートとして機能します。対応を準備せずにローンチするのは一つの判断であり、その判断は記録に残すべきです。

people/ — コードを介さない攻撃

ここでの攻撃者に必要なのはバグではなく、頼まれたとおりに行動する人だけです。 請求書に記載された振込先の変更、創業者の声を複製した音声、アクセス権が残ったままの契約社員、トークンを保持したまま侵害されたベンダー、他人のアカウントのメールアドレスを変更するようサポート担当者を説得することなどが該当します。

	項目数			項目数
支払い詐欺となりすまし	20		ベンダーの侵害	17
創業者の不在への備え	17		サポートデスクのアカウント乗っ取り	15
入社と退職	18

創業者が2人の会社で問うべきなのは、どちらかがだまされる可能性があるかではありません。どちらかと連絡が取れなくなった日にも、会社が機能し続けるかどうかです。

stacks/ — 使用する場合のみ

26 個の補足資料に、542 項目が含まれています。使用していない製品のファイルは読み飛ばしてください。コアチェックリストだけでも利用できます。

バックエンドとウェブ Django · FastAPI · Ruby on Rails · Laravel · Spring Boot · Go / Gin · Express · NestJS · Next.js / React · GraphQL

モバイル iOS / Swift · Android / Kotlin · React Native · Flutter · macOS

データとプラットフォーム PostgreSQL · Supabase · Firebase · Docker · Kubernetes · AWS · Google Cloud · Vercel · Cloudflare · GitHub · Stripe

お使いのスタックがありませんか？ それが最も役立つ貢献になります。フォーマットの全容は _TEMPLATE.md に記載されています。記入例、各フィールドが何に影響するか、そして項目をスタックファイルに含めるかどうかを決める唯一のルールを確認できます。Fly.io、Auth0、Clerk のファイルが求められています。CONTRIBUTING.md をご覧ください。

---

使い方

1. 必要なファイルをコピーして、ご自身のリポジトリに追加します。これらは作業用ドキュメントであり、コードの隣に置いて編集し、コミットすることを想定しています。
2. 積極的に [N/A] を付けてください。 4,685 項目すべてが必要な製品はありません。モバイルアプリがなければ、core/11 と core/12 の 147 項目はすぐに [N/A] にできます。対象範囲について正直であることが、残りの項目の信頼性につながります。
3. 調査結果をすべて記録してください。 記録されていない調査結果は、6 か月後に再発見することになります。

* [ ]     Not checked
* [x]     Verified secure
* [!]     Security issue found
* [N/A]   Not applicable

各 [!] について：影響を受けるコンポーネント · 正確なエンドポイント／ファイル／設定 · 攻撃の前提条件 · 悪用可能性の証明 · ビジネスへの影響 · 重大度 · 修正方法 · 回帰テスト · 担当者 · 検証日

心に留めておくべき唯一のルール

「フロントエンドで非表示にしている」、「そのルートは推測しにくい」、「ユーザーには有効な JWT が必要だ」、*「WAF がブロックしている」*という理由だけで、認可制御として受け入れてはいけません。

利用可能な範囲で、信頼できる最下層ですべての制御を適用してください。

Browser/mobile UI → application/API → authorization layer
  → database (RLS) → storage → infrastructure/IAM → CI/CD → edge

1 つのファイルにまとめたものが必要ですか？

ALL.md にはすべてのチェックリストが連結されています。印刷したり、AI ツールに貼り付けたりするのに便利です。これは生成ファイルです。代わりに checklists/ 以下のファイルを編集してください。

---

AI アシスタントで使う

MCP はモデルではなくクライアントの機能です。DeepSeek を実行する Cursor なら利用できますが、 DeepSeek のウェブサイトでは利用できません。Claude Code、Claude Desktop、Cursor、VS Code Copilot、Gemini CLI、OpenAI Codex CLI、Qwen Code、Cline、Roo、Continue、Windsurf、Zed、 OpenCode、Cherry Studio の設定は docs/mcp-clients.md にあります。

n8n · Dify · Flowise	自動化およびエージェントプラットフォーム
OpenRouter	MCP クライアント経由で、任意のモデルを利用
DeepSeek、Qwen、Kimi、GLM	ベース URL と、それらを利用できるクライアント
Open WebUI、LibreChat	セルフホスト可能なチャット
JSON API	インストール不要 — HTTP GET を 1 回実行
CI	ファイルを最新に保ち、ブロッカーをゲートで検出

claude mcp add prodcheck -- npx -y --package=prodcheck prodcheck-mcp

MCP を使えないチャットウィンドウ（ChatGPT、Gemini、DeepSeek、Kimi、Qwen、GLM）では、 ファイルを生成し、用意済みのプロンプト のいずれかの後に貼り付けます。どのプロンプトも、次の 3 つのルールに基づいています。これがないと、アシスタントはコードに問題がないと言ってしまうからです。主張にはすべて file:line を引用すること、unknown を正当な回答として扱うこと、そして読む人に代わって検証済みと判定しないことです。

コマンドライン

4,685 項目を読む代わりに、プロジェクトに合わせたチェックリストを生成します。

npx prodcheck security --stack django -o SECURITY.md
npx prodcheck performance -o PERFORMANCE.md
npx prodcheck integrations -o LAUNCH.md
npx prodcheck scale -o SCALE.md
npx prodcheck post-launch -o INCIDENT-RESPONSE.md

npx prodcheck list                                # domains, areas and counts
npx prodcheck stacks                              # what supplements exist
npx prodcheck security --area ai -o AI-SECURITY.md
npx prodcheck --gate --stack supabase,cloudflare  # release blockers, every domain
npx prodcheck --search cors --format text
npx prodcheck security --stack rails --format json
npx prodcheck performance --stack nextjs-react -o PERF.md

ドメインは位置引数です。これは、自分ならそのように指定するからです（prodcheck security、将来的には prodcheck performance）。すべての項目を対象にする場合は省略します。

--stack X を指定すると、スタックに依存しないすべての項目に加えて、X 用の補足項目が返されます。認識されないスタックでもエラーにはなりません。単独で機能する、スタックに依存しないコア項目が返されます。これが設計のすべてです。まだファイルが作成されていないスタックでも使えます。

依存関係はなく、Node 18 以降が必要です。

エージェントにレビューを実行させる

MCP サーバーはエージェントに項目を渡します。こちらが渡すのは手順です。

npx prodcheck init

.claude/skills/、.cursor/rules/、AGENTS.md のいずれかにスキルを作成します。どれを使うかは、プロジェクトですでに採用されているものに応じて決まります。その後、エージェントに次のように依頼できます。

このリポジトリを prodcheck のリリースゲートに照らしてレビューしてください

スキルが可能にすることよりも、強制することが重要です。

• モデルは何も検証済みと判定しません。 すべての項目は、file:line の引用を付けた FINDING、UNKNOWN、または理由を添えた N/A のいずれかで終わります。モデルが書ける「合格」はありません。それはあなたが判断します。
• 引用のない指摘は指摘ではありません。 該当行を引用し、そこに何が書かれているかを主張する前に読み直す必要があります。
• UNKNOWN は見える状態に保たれます。 この規模のチェックリストにある項目の多くは、リポジトリからは確認できない本番環境の設定に依存します。人が引き続き確認すべき項目の一覧は、たいていレポートの中で最も役立つ部分です。

このリポジトリには、AI アシスタントが書くバグを扱うフォルダーと、AI によるレビューがそれらを見逃す理由を説明するセクションがあります。何かが実証されたかどうかにかかわらず、流暢で自信に満ちた出力が生成されます。このスキルは、その問題に対抗するために作られています。

この 3 つの制約は主張ではなく、測定されます。evals/ には、9 つの欠陥を意図的に仕込んだアプリと、同じアプリの問題のない対照版が用意されています。決定的な評価ツールがすべての引用を実際のファイルと照合し、判定の表現を確認し、unknown の数と対照版での指摘数を数えます。対照版の指摘は、構造上すべて誤検出です。あるモデルの出力を別のモデルに評価させることはありません。評価ツール自体がモデルであれば、評価対象と同じ失敗をするからです。

これは、作成したものが出荷できる状態かどうかを確認するだけです。テスト、デバッグ、計画、Git ワークフローなど、エージェントが適切に構築する方法を教えるスキルについては、agent-skills をご覧ください。両者は併用できます。両方を活用してください。

MCP サーバー

チェックリストを貼り付ける代わりに、コーディングエージェントが作業中に直接チェックリストを参照できます。読み取り専用で、同梱データ以外のファイルシステムやネットワークにはアクセスしません。

公式 MCP レジストリにio.github.FarzamHabibi/prodcheckとして登録されているため、アシスタントに教えなくても見つけられます。

Claude Code

claude mcp add prodcheck -- npx -y --package=prodcheck prodcheck-mcp

その他 — MCP クライアントの設定に追加します：

{
  "mcpServers": {
    "prodcheck": {
      "command": "npx",
      "args": ["-y", "--package=prodcheck", "prodcheck-mcp"]
    }
  }
}

ツールは4つあります：list_checklists、checklist_for_stack、release_gate、search_checklist。 エージェントに 「このリポジトリを Next.js + Supabase アプリのリリースゲートに照らして確認して」 などと尋ねれば、関連する項目を自分で取得します。

実行コスト

有料モデルに4,685項目を渡す予定なら、当然気になるところです。コンテキストウィンドウに実際に入るデータ量は、1トークンあたり約4文字として、以下のとおりです：

取得するもの	項目数	≈ トークン数
--gate	333	5,600
--gate --stack django	335	5,700
security --area core	1,619	26,700
すべて、全スタック	4,685	95,000

これは1回の確認で入力される量です。レビュー自体の追加コストは、モデルがコードをどれだけ読むかによって変わります。こちらのほうが大きな数値ですが、このリポジトリでは測定できません。

実際に重要なのは、すべてを取得しないことです。 --gate は数千トークンで、知りたいことに答えられます。MCP サーバーがあるのは、アシスタントが必要な20項目を取得できるようにするためであり、すべてを保持させるためではありません。

機械可読データ

上記のどちらもdata/checklist.jsonを読み込み、data/schema.jsonに照らして検証しています。別のものを構築する場合は、これを直接利用できます。ライセンスは CC BY 4.0 です。

checklists/以下の Markdown が信頼できる唯一の情報源です。JSON は./scripts/build.shによって生成されます。意図的にseverityフィールドは設けていません — その理由はこちら。

---

ロードマップ

リリース済み — チェックリスト

• セキュリティチェックリスト。分野ごとに分割され、スタック間で利用可能
• 機械可読なデータ層 + スキーマ
• performance/ — 9つのチェックリストにわたる313項目。
• integrations/ — 6つのチェックリストにわたる192項目。
• scale/ — 9つのチェックリストにわたる286項目。214項目から拡充：サービスレベルとエラーバジェット、検索・分析エンジン、リアルタイムのファンアウト、契約とイベントのバージョニング、テナント構成ごとのキャパシティ。推測ではなく、実際に不足を測定しました。
• post-launch/ — 8つのチェックリストにわたる198項目。他の4分野をそろえて読める状態にした後で追加しました。ある不足に気づいたためです。どの分野も、問題が起きないように構築する方法は説明していましたが、それでも問題が起きたときの対応準備ができているかを問うものはありませんでした。
• 26のスタック別補足資料 — 19から増加。FastAPI、AWS、Kubernetes、Vercel、Firebase、Stripe、GraphQL などが含まれます。未解決課題として残さず、実際に執筆しました。自分のスタックが見つからなければ、訪問者は項目をひとつも読む前に、このプロジェクトは自分向けではないと判断するからです。
• 利用中のスタックにも対応したリリースゲート — ブロック対象の項目は379件。どこでも適用される316件に、20製品にわたる63件を加えています。漏洩したservice_roleキーは、一般的な項目と同じようにリリースを止めるべきですが、以前はゲートの対象外でした。

リリース済み — 日々の作業への取り込み

• npx prodcheck — スタックに合わせて絞り込んだチェックリストを生成します
• MCP サーバー — コーディングエージェントがチェックリストを直接照会できるようにします
• レビュー用スキル — npx prodcheck init を実行すると、手順が .claude/skills/、 .cursor/rules/、または AGENTS.md に書き込まれます。MCP サーバーはすでに項目を提供していましたが、それらを活用する規律が不足していました。
• スキル用の評価ハーネス — 仕込まれた欠陥、決定論的な採点機能、そして単に適切にレビューできたかではなく、手順に従ったかを確認する機能を備えています。評価ハーネス自体に4つの欠陥が見つかり、その内容は evals/ に記録されています。
• ウェブ版 — prodcheck.pages.dev で公開中です。すべてのチェックリストを閲覧、絞り込み、Markdown としてコピーできるほか、あらゆるツールが取得できる JSON エンドポイントもあります。
• ひとつの導入方法 — あらゆるアシスタントに貼り付けられるプロンプトです。プロジェクトの内容を把握し、アシスタントが対応できる方法で prodcheck をセットアップします。以前はサイトに7つの導入方法がありましたが、それらを順に進める道筋はありませんでした。
• 見てわかるデモ — 実際にレビューが実行される34秒のループ動画です。 作成方法。

次の予定

• 対象分野の拡大 — launch/、social/、legal/。ほかのものを移動せずに構成へ追加でき、内容を作成する前に計画を記述します。

その後 — 読むだけのドキュメントではなく、実行されるレビュー

意図的に保留し、最後に取り組みます。 ここまでのものはすべて、今日使えるコンテンツとツールです。これはその上に構築する別のプロダクトであり、中途半端にリリースするくらいなら、リリースしないほうがよいでしょう。設計上の決定が失われないよう、ここに記録します。

アイデアは、チェックリストに照らしてコードベースを確認し、リポジトリのルートにレポートを書き込み、関連コードが変更されたら項目を再度確認するツールです。

prodcheck scan      detect stack and features from the repo   -> .prodcheck/profile.json
prodcheck check     deterministic rules, no model involved    -> findings
prodcheck review    model-assisted review, citations verified -> findings
prodcheck report    render SECURITY-REVIEW.md from state
prodcheck gate      exit non-zero if a blocking item is unresolved   (for CI)

• scan — リポジトリのプロファイルを作成します。 package.json、requirements.txt、go.mod、 Dockerfile、CI 設定、およびソースツリーの構成を読み取り、使用中のスタックと存在する機能（ファイルアップロード、Webhook、マルチテナント、バックグラウンドジョブ、LLM を使う機能など）を特定します。モデルを使う前に、該当する項目を選択します。モバイルクライアントもファイルアップロードもない Django アプリなら、1,619件あるコア項目すべてを確認する必要はありません。core/07、core/11、core/12 だけでも217件をスキップできます。

• check — 決定論的なチェック層です。 検索だけで回答できる項目はおよそ160件あります。たとえば、存在してはならないもののリスト、バージョンが固定されていない CI アクション、Dockerfile 内のシークレット、dangerouslySetInnerHTML、ワイルドカードの CORS などです。モデルは不要で、コストもかからず、ハルシネーションも起きません。プッシュのたびに CI で実行できます。

• review — 信頼を前提にしない、モデル支援型のチェック層です。 多くの項目ではコードを読む必要があるため、MCP とスキルファイルを使い、すでに利用しているエージェント（Claude Code、Cursor、Copilot）内で実行します。API キーは不要で、こちらからのトークン料金も発生しません。重要なのは機能よりも、次の設計上の制約です。

  • モデルが [x] を付けることはありません。 出力は判定ではなく証拠です。結果は deterministic-pass、model-flagged（人による確認が必要）、または human-verified です。ゲートの判定に使われるのは最初と最後の結果だけです。モデルが付けた緑のチェックマークはありません。
  • すべての引用を検証します。 指摘には file:line を記載する必要があり、受け付ける前にツールがその行の存在と引用されたコードの一致を確認します。このチェックに失敗した指摘は除外されるため、ほとんどコストをかけずにハルシネーションを大幅に減らせます。
  • unknown は正式な結果です。 モデルは、判断できなかったと回答できます。また、unknown が暗黙のうちに pass になることはありません。別途報告されます。

• 再実行後も状態を保持します。 .prodcheck/state.json には、data/checklist.json にすでにある安定した項目 ID をキーとして、ステータス、根拠、日付、および判断時のコードのハッシュを保存します。[N/A] にした項目は、関連するコードが変更されるまでそのままです。コードが変更されると、「abc1234 で確認済みですが、その後このファイルが変更されています。」 というメッセージとともに再び確認対象になります。これにより、時間とともに劣化するレポートではなく、生きたドキュメントになります。

• CI の gate。 ビルドを失敗させる仕組みがなければ、レポートは古くなり、読まれなくなります。これが、ほかの取り組みを定着させる部分です。

security/ai-generated-code/ フォルダーで、AI によるレビューは AI が書いたコードに問題がないことを確認するだけだと警告しているチェックリストの上に AI コードレビューアーを構築するのであれば、その警告を真剣に受け止めた設計にするのが筋です。そのために、上記の 3 つの制約があります。

---

貢献

スタックファイル、修正、不足している項目、実体験の共有を歓迎します。 CONTRIBUTING.md をご覧ください。

質問

ディスカッションまたは Issue を作成してください。 回答が公開され、次に同じ疑問を持った人も見つけられるようになります。

それ以外のお問い合わせは、X の @farzam_habibi までどうぞ。

セキュリティ上の問題の報告

SECURITY.md をご覧ください。これには、読者の安全性を損なう誤りを含む、このチェックリストの項目も該当します。誤った安心感を与えるチェックリストは、チェックリストがないよりも悪いため、こうした報告を最優先で扱います。

最も役立つ貢献は、まだ対象になっていないスタックのスタックファイルです。Fly.io、Auth0、Clerk 用のファイルを募集しています。現在の一覧と、スタックファイルに含める項目の基準については、CONTRIBUTING.md をご覧ください。_TEMPLATE.md をコピーして、PR を作成してください。

---

免責事項

これは出発点であり、保証でも、コンプライアンス認証でも、専門的なセキュリティ監査の代わりでもありません。すべての項目を完了しても、アプリケーションが安全になるわけではありません。問題を見つけるために利用し、問題がないと断言するために利用しないでください。

ライセンス

このリポジトリの 2 つの部分は性質が異なるため、デュアルライセンスを採用しています。

	ライセンス
コンテンツ — checklists/、data/、ALL.md	CC BY 4.0	コピー、改変、商用利用が可能です。帰属表示は残してください。
コード — cli/、scripts/、prodcheck パッケージ	MIT	クリエイティブ・コモンズ・ライセンスはソフトウェア向けに設計されておらず、CC ライセンスの npm パッケージは企業の法務審査で却下されます。MIT にすることで、その障壁を取り除いています。

AI を活用して構築し、その事実を率直に伝えます

このリポジトリは、ゼロからチェック項目を生成するのではなく、実際のプレプロダクションレビューをもとに、Claude （Anthropic）と ChatGPT（OpenAI）を活用して編成・拡充しました。1 人では把握しきれない作業、つまり数百件の指摘を OWASP のカテゴリと照合し、4,685 件の項目の表現と構成に一貫性を持たせ、セクション間の抜けを見つける作業を担ってもらいました。

このことを率直に伝えるべき理由は 2 つあります。

これは正直な来歴です。 セキュリティチェックリストは、それを信頼して使うことを求めます。どのように作られたのかを知っておくべきです。

security/ai-generated-code/ フォルダーの内容は、このリポジトリにも当てはまります。 AI が生成した成果物には、AI がどこかで自信満々に間違えていると想定したレビューが必要であり、「テストに合格した」ことはセキュリティ上の根拠にはならない、と述べています。どちらもここで当てはまりました。CLI のテストスイートでは、AI が書いたコードの実際のバグを 3 件検出しました。その中には、8 KB を超えるすべての応答を黙って切り詰めていた MCP サーバーも含まれています。このチェックリストも、自らの助言の対象外ではありません。併せて提供されるツールも同様です。

項目に誤りがある、もっともらしく聞こえるものの事実に反する、または微妙に誤解を招くものがあれば、それはまさに security/ai-generated-code/07-review-blind-spots.md が警告する失敗のパターンです。 イシューを作成してください。その修正は、新しい項目を 3 つ追加するより価値があります。

クレジット

自社プロダクトの出荷準備に取り組む中で、Arioo の創業チームが作成し、メンテナンスしています。

イシューや PR を作成してくださる皆さんからの貢献が、内容の正確さを保つ力になります。コントリビューターをご覧ください。