Webアプリのアクセス制御・認証・認可の実装はすべてこのスキルを使う。遮断だけならCloudflare Access、アプリ内identity・role・session・WebSocket等が必要ならBetter Authとする単一決定表の正本。「認証を付けて」「ログイン機能」「Googleでログインできるように」「社員だけに限定」「特定企業だけに公開」「許可リスト/招待制」「メール+パスワード認証」「セッション管理」「ロール・権限管理」「OAuth設定」「redirect_uri_mismatchを直す」「認証のセキュリティレビュー」などの文脈で、ユーザーが「認証」と明示しなくてもログイン要件が含まれるなら必ず読む。特にNext.js App Router＋OpenNext＋D1、Hono、素のWorkersでのBetter Auth＋Google OAuth導入を自動化し、Google Cloud Consoleで人間にしかできない操作は日本語のクリック手順と直リンクへ切り分ける。
インストール方法を見るインストールする前に、エージェントに与えられる指示の中身を確認できます。
Cloudflare上のアプリへGoogle認証を導入する。既定はGoogle Workspaceの単一組織限定とし、個人Gmail・別Workspace・グループアドレス・メールエイリアスをログイン主体として扱わない。
wrangler.jsonc、NEXT_PUBLIC_*へ出さない。hd claimをBetter AuthのsocialProviders.google.hdで検証する。auth.api.getSessionを検証する。v0/v1 の呼び方で分岐させず、アプリが利用者のidentityを必要とするかで決める。
| 要件 | 採用方式 | v1 での扱い |
|---|---|---|
| 社内利用者以外をエッジで遮断するだけ。全員が同じデータを使い、アプリ内のidentity・role・session・ユーザー単位データが不要で、WebSocketも使わない | Cloudflare Access | そのまま継続可。Better Auth への移行を残課題にしない |
| アプリ内のidentity、role/認可、session、ユーザー単位データのいずれかが必要、または WebSocket を使う | Better Auth | v0 から必須。Access だけを一時利用して後送りにしない |
Access で利用者を識別してアプリの所有者・権限に使う折衷案は採用しない。Cf-Access-Jwt-Assertion の識別実装が必要となった時点で Better Auth の行を選ぶ。Access の遮断範囲・バージョン別プレビューURL・許可/拒否の実機検証は cloudflare-secure-deploy に従う。Access の行を選んだら本Skillの Better Auth 実装手順はここで終了する。
Better Auth の行を選んだ場合は、以降の手順を実行する。
references/free-tier-guardrails.mdとreferences/known-pitfalls.mdのD1セッションコストを確認する。最初に次を実行する。
node <skill-dir>/scripts/inspect-project.mjs --project <project-root>
結果から経路を選ぶ。
| 検出結果 | 読むファイル |
|---|---|
| Next.js + OpenNext + D1 | references/nextjs-opennext-d1.md（既定） |
| Honoまたは素のWorker + D1 | references/hono-workers-d1.md |
| 既存Better Authあり | 上記該当リファレンス＋references/security-and-testing.mdで差分監査 |
| Cloudflareでない／DBがD1でない | 勝手に移行せず、現在の構成と変更範囲を説明して確認する |
既存アプリの構成を変更しない。Next.js + OpenNext + D1 と判定した場合は、APIをNext.js Route Handlerで実装し、Honoを追加しない。 Honoのリファレンスは、Honoまたは素のWorker構成として判定されたプロジェクトだけで使用する。
依存バージョンやCLI構文は変わり得る。実装前にreferences/official-sources.mdを読み、公式ドキュメントを再確認する。
コードやWrangler設定から取得できない値は、既存のサービス名、git remote、公開設定、メールドメインから可逆な仮説を置く。仮説値を明記したsecret-freeの実装、テスト、設定ガイドを先に生成し、Google Cloudの本人操作や組織ドメインなど本人しか確定できない境界だけを最後に1回で確認する。
APP_NAME=Google同意画面とサインイン画面に出す名称
PRODUCTION_ORIGIN=https://app.example.com（パス・末尾スラッシュなし）
WORKSPACE_DOMAIN=example.co.jp
LOCAL_ORIGIN=http://localhost:3000（通常は既定値）
Client ID、Client Secret、BETTER_AUTH_SECRETの値をチャットで尋ねない。Workspace限定でない要件でも、既定は閉じた構成のままローカル成果物を作り、許可主体とリスクを具体化してからhdを外す一点だけを確認する。
該当リファレンスに従い、次を実施する。
better-auth、D1/ORMアダプター、Wrangler/OpenNext依存を既存package managerで導入する。baseURL、固定trustedOrigins、Google providerのhd、emailVerified、DB-backed rate limit、cf-connecting-ipを設定する。/api/auth/[...all]、auth client、サインインUI、サインアウト、保護ページ/APIのサーバー側検証を配線する。not_found_handling: "single-page-application"で配る構成（Hono／素のWorker + 別ビルドSPA）なら、assets.run_worker_firstに/api/*を入れる。入れないとOAuthコールバック（ブラウザのトップレベル遷移=Accept: text/html）がSPAフォールバックに横取りされ、Better Authが実行されずログインが完了しない。fetchは届くので気づけない。cloudflare-secure-deploy §2・§10が正本。本Skillでは再定義しない)。.dev.varsまたは.envの一方だけを使い、.gitignoreへ含める。ローカル値はユーザーがエディタへ直接入れるか、安全な対話入力を使う。.gitignoreへ.dev.varsを追加後、ローカル設定がなければ次で安全に初期化する。
node <skill-dir>/scripts/setup-local-vars.mjs --project <project-root>
このスクリプトはローカルBETTER_AUTH_SECRETを自動生成して値を表示しない。既存.dev.varsや.envがあれば変更せず停止する。
資材をコピーする場合はassets/nextjs-opennext-d1/を出発点にする。__APP_NAME__、__WORKSPACE_DOMAIN__、__LOCAL_ORIGIN__、__PRODUCTION_ORIGIN__を置換し、プロジェクトの既存パス、DB schema、UIへ適合させる。既存ファイルを無確認で上書きしない。
新規Next.js/OpenNextアプリで対象ファイルがまだ存在しない場合は、安全な雛形をCLI生成できる。
node <skill-dir>/scripts/render-nextjs-templates.mjs \
--output <project-root> \
--app-name "<APP_NAME>" \
--workspace-domain "<WORKSPACE_DOMAIN>" \
--production-origin "<PRODUCTION_ORIGIN>" \
--d1-name "<D1_DATABASE_NAME>" \
--d1-id "<D1_DATABASE_ID>"
1つでも同名ファイルがあれば、スクリプトは何も上書きせず停止する。既存アプリはagentが差分を読んでapply_patchする。
実装直後に次を実行し、プロジェクト直下へ案内書を生成する。
node <skill-dir>/scripts/generate-user-guide.mjs \
--app-name "<APP_NAME>" \
--production-origin "<PRODUCTION_ORIGIN>" \
--workspace-domain "<WORKSPACE_DOMAIN>" \
--output auth-google-setup.md
Pagesの場合は--cloudflare-target pages --cloudflare-project-name <name>を追加する。複数Workerや環境指定が必要な場合だけ--worker-nameまたは--cloudflare-envを追加する。生成先には案内書と.better-auth-google/setup-secrets.mjsが作られる。
生成物をユーザーへクリック可能なローカルファイルリンクで渡す。会話上では次の3点だけを提示する。
node .better-auth-google/setup-secrets.mjs生成するMarkdownはreferences/google-cloud-manual.mdとassets/google-cloud-beginner-guide.md.templateを使う。案内書へ絶対パスやOS固有操作を入れない。Client ID/Secretは生成されたプロジェクト内スクリプトへ一度だけ非表示入力させ、ローカルとCloudflare本番へ同時登録する。
この段階だけはユーザー操作を待つ。ユーザーにはSecretを貼らせず、Terminalで登録後に「登録した」とだけ返してもらう。
ユーザーがGoogle Clientを発行したら、プロジェクト内Terminalで次を一度だけ実行させる。
node .better-auth-google/setup-secrets.mjs
このスクリプトはOSや個人の絶対パスへ依存しない。Client ID/Secretを一度だけ非表示入力し、.dev.varsまたは既存.envとCloudflareへ登録する。BETTER_AUTH_SECRET、Git除外、ファイル権限も自動処理する。値入りファイルを生成物、回答、Gitへ含めない。
実装後に次を実行する。
node <skill-dir>/scripts/check-auth-readiness.mjs \
--project <project-root> \
--production-origin "<PRODUCTION_ORIGIN>" \
--workspace-domain "<WORKSPACE_DOMAIN>"
その後、プロジェクト固有のtest、typecheck、buildを実行する。Cloudflareログイン済みなら--remoteでもreadinessを実行し、Secret名とD1 migration状態を読み取り確認する。
デプロイ前にreferences/security-and-testing.mdの必須項目を全確認する。デプロイ後は以下を検証する。
/sign-inが200で表示される。curl -H "Accept: text/html" -H "Sec-Fetch-Mode: navigate" "$ORIGIN/api/me"がWorkerの応答を返す（index.htmlが返るならOAuthコールバックが横取りされる）。実アカウントを使うGoogle画面の操作はユーザー本人に依頼するか、明示許可されたブラウザ操作で行う。認証成功を未確認のまま「完了」と報告しない。
次の順番で簡潔に報告する。
実装済み: 変更した認証機能
自動実行済み: install / schema / migration / secrets / test / build / deploy
あなたの操作: Google Consoleで残っている操作（なければ「なし」）
リンク: 案内書、本番サインイン、Google設定画面
Redirect URI: 開発、本番
検証結果: 許可・拒否・保護API・Secret漏えい
未確認: 実アカウント操作など、残っている事実だけ
references/nextjs-opennext-d1.md: このチャットで完成した構成を一般化した標準実装references/hono-workers-d1.md: Hono／素のWorker向け構成references/google-cloud-manual.md: ユーザー作業の説明規約assets/google-cloud-beginner-guide.md.template: 非ITメンバー向けの完全なMarkdown手順書assets/setup-secrets.mjs.template: OS共通・プロジェクトローカルのSecret登録コマンドreferences/security-and-testing.md: セキュリティ不変条件と受入テストreferences/known-pitfalls.md: Better Auth×Cloudflareの既知バグ・redirect_uri_mismatch・SPA横取り対策references/free-tier-guardrails.md: Workers/D1無料枠の数値とクエリ設計ガードレールreferences/acceptance-and-operations.md: 受入条件・トラブルシューティング早見表・運用（月次チェック/Secretローテーション/ログ設計）references/official-sources.md: 現行仕様を確認する一次情報scripts/inspect-project.mjs: 認証構成の安全な読み取り調査scripts/render-nextjs-templates.mjs: 新規Next.js/OpenNext向け雛形の非上書き生成scripts/setup-local-vars.mjs: ローカルSecretと.dev.varsの安全な初回作成scripts/setup-google-local-secrets.sh: Google Client値を非表示入力で.dev.varsへ安全に保存scripts/generate-user-guide.mjs: クリック可能な日本語手順書生成scripts/setup-cloudflare-secrets.sh: Wrangler Secretの安全な対話登録scripts/check-auth-readiness.mjs: ローカル／本番readiness検査まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
アプリ・Webサービス・業務ツールの制作を、証拠分析→確定的な初稿→要件定義→体験設計→機能分解→実装→品質ゲート→リリース判定の手順ゲート制で進めるスキル。質問で要件を埋めるのではなく、依頼文・既存コード・資料・ログから最有力案を選び、動く成果物を先に出して差分で改善する。ユーザーが「アプリを作りたい」「ツールを作って」「〜を自動化したい」「システム化したい」「要件定義」「仕様を決めたい」「UI/UXを設計して」「体験を良くしたい」「機能を洗い出して」「MVPを決めたい」「品質チェック」「リリースしていいか判断して」などと言ったら必ず使用する。外部データの取込・マスタ・締め処理を伴う業務システムでは references/data-lifecycle.md も併用する。新規・既存を問わずアプリの制作・改善・リニューアルで使用する。
Webアプリの準備→要件定義→設計→実装→公開→品質ゲートを実行する内部オーケストレーター。Claude Codeの /build-app /improve-app、Codexの $build-app / $improve-app から明示的に委譲された場合、custom agent起動時、または利用者が $app-orchestrator を明示した場合だけ使用する。一般のアプリ相談から暗黙起動しない。
run-extract-blueprint が生成した章別ブループリントの忠実性を独立 context で評価したいとき、事実/推測区別と粒度と被覆を検証し draft_hash に束縛した PASS/FAIL verdict をローカル品質ゲート (C01 の周回内の受入判定・差し戻し) へ渡したいときに使う。
確認点で利用者が見る深さを選んだあと打ち合わせ資料を作り手とは別の目で確かめたいとき、正確さ・言葉・見た目・シンプルさの指摘を資料の編集なしで受け取りたいときに使う。
生成した handout 資料が初心者に伝わるか読みやすさレビューを依頼したいとき、独立 context のレビュアーから指摘と根拠つきの verdict を回収したいときに使う。
Notion ページを描画する直前に粒度を検証したいとき、info-collector-agent ページと同等の section 充足度を section_canonical_map 基準で機械検証したいときに使う。