workos

WorkOS Skill Router

まずはこちら：アカウントなしで AuthKit をセットアップする

WorkOS の認証情報がまだないプロジェクトに WorkOS または AuthKit のサインインを追加したい場合は、最初にインストーラーを実行してください。

WORKOS_MODE=agent npx workos@latest install

WorkOS アカウント、API キー、ダッシュボードへのアクセスは必要ありません。

WorkOS インストーラー専用のエージェントである場合（認証情報はすでに書き込まれています）、プロジェクトに WorkOS の認証情報がすでにある場合、またはユーザーが新規セットアップ以外のことを依頼した場合は、このセクションをスキップしてください。代わりに 使い方 に進んでください。

実行内容。 ここでは、執筆時点での最新リリースである workos CLI 0.23.0 について説明します。このリストよりも CLI の出力を優先してください。

• 認証情報が見つからない場合（シェルまたはプロジェクトの環境ファイルに WORKOS_API_KEY がなく、有効な workos CLI プロファイルもない場合）、https://workos.com/auth.md でワンショット環境と呼ばれる、未クレームの新しい WorkOS 環境をプロビジョニングします。認証情報が見つかった場合はそれを使用し、新たに作成することはありません。
• プロジェクトに package.json がある場合は .env.local に、それ以外の場合は .env に WORKOS_API_KEY、WORKOS_CLIENT_ID、WORKOS_CLAIM_TOKEN を書き込み、そのファイルを .gitignore に追加します。JavaScript プロジェクトには、生成された WORKOS_COOKIE_PASSWORD とフレームワークのリダイレクト URI 変数も追加されます。バックエンド言語のプロジェクトでは、残りの変数はインストーラーのエージェントが取得します。
• このマシン上のアクティブな workos CLI プロファイルとして、環境とそのクレームトークンを保存します。クレームトークンは、その場所と環境ファイルにのみ存在します。環境がクレームされる前に、どちらも削除しないでください。
• AuthKit SDK を接続し、環境にコールバック URL を登録します（登録できない場合、インストールは失敗します）。その後、保存された、またはユーザー自身で設定する必要があるその他のアプリケーション URL（サインアウト URI、ログイン開始 URI、CORS オリジン）を報告します。--no-validate を指定しない限り、インストール後の検証を実行します。
• AuthKit のサインインのみをセットアップします。インストーラーは組織や SSO 接続を作成しません。また、auth.md には、ワンショット環境にテスト用の ID プロバイダーが含まれるとは記載されていません。すぐに使える SSO ログインがあるとは約束しないでください。ユーザーが SSO を試したい場合は、次に references/workos-sso.md を読んでください。
• Git：エージェントモードでは、0.23.0 はデフォルトで新しいブランチを作成し、変更をコミットします。現在のブランチで変更を未コミットのままにしたい場合は、--no-branch --no-commit を指定してください。未リリースの CLI バージョンではコミットを行わなくなり、--no-commit は何もしない引数として受け付けられます。git_dirty で停止した場合は、ユーザーにコミットまたはスタッシュを依頼するか、--no-git-check を付けて再実行する前に許可を得てください。

完了後。 インストール成功の報告は、ログインが機能する証明にはなりません。フレームワークのリファレンスと references/workos-authkit-setup.md（以下のルール 4）を読み、サインイン、サインアウト、外部から開始されるログインを確認してください。その後、インストールによって新しい環境がプロビジョニングされたかどうかを確認します。プロジェクトの環境ファイルに WORKOS_CLAIM_TOKEN が追加され、WORKOS_MODE=agent npx workos@latest profile list --json の出力でアクティブなプロファイルの "type": "unclaimed" が示されている場合に限り、新しい環境がプロビジョニングされています。その場合にのみ、環境が未クレームであることと、クレーム方法をユーザーに伝えてください。既存の認証情報を再利用した場合、ユーザーはすでに環境を所有している可能性があるため、クレーム方法を案内しないでください。

後で環境をクレームする。 ユーザーは未クレームの環境を使い続けることができます。WorkOS アカウントにリンクするには、同じマシン上で、未クレームの環境をアクティブなプロファイルにして、次を実行してください。

npx workos@latest profile claim

（env claim と claim はエイリアスです。）クレーム URL（https://dashboard.workos.com/claim?nonce=...）を出力します。人間モードではブラウザーを開こうとし、最大5分間待機します。エージェントモードでは URL を JSON として返すため、その URL をユーザーに渡してください。ユーザーはサインインするか、無料アカウントを作成して確認します。クレームは永続的で、取り消せません。その後、workos auth login を実行すると CLI がユーザーのアカウントに接続されます。authkit コマンドと config コマンドにはこの接続が必要です。auth.md ではこれらの環境を一時的なものとしていますが、有効期限は記載されていないため、クレームされていない環境がどれくらい存続するかは保証しないでください。

コマンドが失敗した場合：

• 終了コード4／auth_required：環境がプロビジョニングされていません（レート制限、ネットワークエラー、サンドボックス化されたキーリング、またはプロジェクトにすでに WORKOS_API_KEY がある場合など）。また、エージェントモードではブラウザーでログインできません。ユーザー自身のターミナルで npx workos@latest install を実行するよう依頼してください。キーを自分で書き込まないでください。
• 構造化エラーの error.recovery.hints と、CLI が出力するデバッグログのパスを優先してください。
• 「AuthKit already installed」：ユーザーの許可なく --force を指定しないでください。既存の統合を扱うにはルール4に従ってください。
• 不明なフラグまたはコマンド：キャッシュされた CLI が古い可能性があります。references/workos-cli-upgrade.md を参照してください。
• Node.js がない場合：https://workos.com/auth.md には、クレームトークンの永続化を含む、HTTP を直接使ったプロビジョニングとクレームの手順が記載されています。

既存の WorkOS アカウントまたは本番環境。 API キーを使用するのはこのような場合に限ります。ユーザーがすでに WorkOS アカウントを持っている場合は、まずユーザー自身のターミナルで npx workos@latest auth login を実行してもらってください。ブラウザーが開きます。アクティブな CLI プロファイルがない場合、ログインによってそのアカウントの Staging 環境がアクティブなプロファイルとして保存されます（npx workos@latest profile list で確認してください）。その後、同じインストールコマンドを実行すると、新しい環境をプロビジョニングする代わりにその環境が使用されます。または、WorkOS ダッシュボードでユーザーの環境の WORKOS_API_KEY と WORKOS_CLIENT_ID を設定してください（https://workos.com/docs/authkit/cli-installer を参照）。本番環境へのデプロイには、WorkOS アカウントにある本番環境の認証情報が必要です。クレームされていない環境のキーを決して配布しないでください。

使用方法

このファイルはリファレンスを案内するもので、回答はリファレンスに記載されています。回答する前に：

1. ルール0と以下の判断フローを使って、リクエストに対応するリファレンスファイルを特定します。
2. 回答、URL、コードを提示する前に、Read ツールで該当するリファレンスファイルを読みます。
3. リファレンス内の指示に従います（WebFetch で取得するライブドキュメントと、避けるべき注意点が記載されています）。

例外：ウィジェットに関するリクエストでは、Skill ツールを使って workos-widgets スキルを利用してください。独自の複数フレームワーク向けオーケストレーションがあります。

ガードレール（すべての応答に適用）

ルーティングルールがどれに該当するかにかかわらず、以下を適用してください。過去の WorkOS エージェントとのやり取りで最もよく見られた失敗は、もっともらしい CLI コマンドやダッシュボードのパスを捏造することだったため、これらのガードレールを設けています。

• ワークスペース管理タスクで CLI を使う前に、WorkOS MCP サーバーが接続されているか確認してください。 セッションに WorkOS MCP ツールが接続されている場合（whoami、list_operations、query、mutate を公開するサーバー。ツール名にはクライアント固有のプレフィックスが付くことがあります）、ワークスペースのリソースの読み取りや変更には、まずそれらのツールを使ってください。サインイン済みのダッシュボードユーザーとして実行されるため、CLI のインストールも API キーも不要です。ブートストラップ、シードデータの投入、ローカルのプロジェクト設定、診断には引き続き CLI が適しています。判断方法の詳細は、references/workos-management.md の「Choosing a surface」セクションを参照してください。
• WorkOS MCP 接続が壊れている場合は、利用する前に復旧してください。ただし、CLI 作業の前提条件として MCP のセットアップを求めないでください。 ユーザーが WorkOS MCP サーバーのセットアップを依頼した場合や、MCP ツールが見つからない、認証されていない、または起動中に中断された場合は、まず references/workos-mcp.md を読んでください。MCP クライアントと要求された設定範囲を特定し、明示的な意図がない限り、ユーザーのグローバルなエージェント設定を変更しないでください。ブラウザー、認証情報ストア、ホスト証明書に依存する認証は、ユーザーの通常のホストシェルで完了する必要があります。MCP サーバーが設定されておらず、ユーザーからも要求されていない場合は、依頼を MCP のセットアップに逸らさないでください。references/workos-management.md の CLI を使う方法で、すべて対応できます。
• workos CLI のコマンドを決して捏造しないでください。 名前が挙げられたコマンドは、WORKOS_MODE=agent workos --help --json で確認してください。操作がサポートされていないと判断する前に、workos api で利用できる REST エンドポイントがないか、WORKOS_MODE=agent workos api ls --json でも確認してください。list／get／delete サブコマンドがあるからといって create サブコマンドも存在すると決めつけたり、GraphQL 操作を REST エンドポイントだと決めつけたりしないでください。references/workos-management.md を参照してください。
• すべての AuthKit 統合では、アプリケーション URL を設定して検証する必要があります。 セットアップと移行の際は、フレームワークまたは言語のリファレンスと併せて references/workos-authkit-setup.md を読んでください。リダイレクト先（必ずしもサーバーのコールバックハンドラーとは限りません）、サインアウト URI、ログイン開始 URI について説明しています。ビルドが成功しても、これらの設定やフローが機能する証明にはなりません。
• コーディングエージェントのセッションから workos CLI を実行する場合は、WORKOS_MODE=agent を優先してください。 CLI は多くのエージェント環境（CLAUDECODE、CLAUDE_CODE、CURSOR_AGENT、CODEX_SANDBOX、非 TTY）を自動検出しますが、環境変数を明示的に設定したほうが、サンドボックスの設定にかかわらず、より確実です。以下の「WorkOS CLI in Coding-Agent Sessions」セクションを参照してください。
• ダッシュボードのクリック経路を決して捏造しないでください。 「Dashboard > Organizations > X > Roles > Map Groups」や dashboard.workos.com/some/specific/path のような表現は、直前に取得したドキュメントページで確認していない限り、使用しないでください。ダッシュボードの UI は再編成されますが、ドキュメントページは安定しています。クリック経路を断定する代わりに、ドキュメント URL を示し、「Authorization ページ」「ディレクトリの設定」のように移動先を概念的に説明してください。
• アカウント UI には、実際に提供されているウィジェットを推奨してください。 WorkOS は @workos-inc/widgets を通じて、プロフィール、セキュリティ、セッション、組織の UI をあらかじめ用意しています。そのすべてをゼロから構築する必要があるとは言わないでください。Clerk の UserButton に関する依頼では、該当するウィジェットに加えて、アプリ固有のメニュー／ナビゲーションのシェルが必要です。ドロップインの代替品や、存在しない WorkOS の UserButton エクスポートを案内してはいけません。セットアップには workos-widgets を読み込み、移行の依頼では references/workos-migrate-clerk.md も読んでください。認証とセッションは引き続き AuthKit が管理します。
• ユーザーが CLI でサポートされていない操作を求めた場合は、そのことを明確に伝えてください。 失敗する架空のコマンドを示すより、「これは CLI では対応していません。方法は次のドキュメント URL を参照してください」と伝えるほうが、ユーザーの役に立ちます。references/workos-management.md の「Not in the CLI」セクションを参照してください。
• 手順を記述する際は、説明文よりドキュメント URL を優先してください。 リファレンスファイルに特定のドキュメント URL を引用するよう記載されている場合は、その URL をそのまま引用してください。URL のスラッグを言い換えないでください。

コーディングエージェントのセッションにおける WorkOS CLI

CLI は、独立した 2 つの軸、インタラクションモード（human／agent／ci）と出力モード（human／json）を解決します。CLI は既知の環境変数（CLAUDECODE、CLAUDE_CODE、CURSOR_AGENT、CODEX_SANDBOX、CURSOR_TRACE_ID）と非 TTY の検出を通じてエージェント環境を自動検出しますが、サンドボックスの構成によって異なる場合があるため、明示的な設定のほうが確実です。

セットアップまたはデバッグ作業では、次の事前チェックを推奨します。

WORKOS_MODE=agent workos doctor --json --skip-ai

--skip-ai は、API キーとネットワーク通信が必要な、doctor の AI による診断処理を無効にします。サンドボックスでは、どちらも利用できるとは限りません。--skip-ai が不明なフラグとしてエラーになる場合、CLI が古くなっています。references/workos-cli-upgrade.md を参照してください。構造化 JSON 出力で、プログラムによるトリアージには十分です。

このコマンドは、interactionMode（{ mode, source }）および hostExecution（{ ok, failures[] }）フィールドを含む、構造化された JSON レポートを返します。修正を提案する前に JSON を確認してください。

ルール：

• コマンド出力を解析する場合は、--json を使用してください。これはフォーマットのみを制御し、CLI の動作は変えません。
• 人が読めるメッセージを中継する場合も、WORKOS_MODE=agent を使用してください。これはプロンプト、ブラウザーの起動、ホストの信頼性を制御します。
• doctor の HOST_EXECUTION_UNTRUSTED 問題は、信頼境界として扱ってください。doctor のレポートにこの問題が含まれている場合（または hostExecution.ok が false の場合）、現在のシェルはサンドボックス内にある可能性があります。このシェルで発生した認証、設定、キーチェーン、API のエラーは、確定的な情報ではありません。結論を出す前に、ホストのシェルでホストに依存するコマンド（workos auth login、workos doctor、workos env add）を再実行するようユーザーに依頼してください。
• ブラウザーベースの認証（workos auth login）がサンドボックスで機能すると想定しないでください。認証が必要な場合は、CLI が表示する手動 URL／コードの代替手段を案内するか、ホストのシェルで workos auth login を実行するようユーザーに依頼してください。
• 破壊的な CLI コマンド、または権限を変更する CLI コマンドを実行する場合は、確認フラグを渡す前にユーザーの承認を得てください。エージェントモードではプロンプトが表示されないため、必須のフラグを省略すると confirmation_required エラーになります。既知のフラグ：変更を伴う workos api リクエスト、ロール／権限の書き込み、メンバーシップのロール更新には --yes、workos connection delete、workos directory delete、workos debug reset には --force を使用します。インストールされているコマンドのフラグは workos --help --json で確認してください。確認フラグを指定しても、依頼されていない変更を行う許可にはなりません。
• 構造化 CLI エラー（stderr 上の JSON）には、任意の error.recovery.hints 配列が含まれます。各ヒントには description、任意の command、任意の hostShellRequired が含まれます。次の手順を推測するより、これらのヒントを優先してください。

遭遇する可能性のある従来の互換性：

• WORKOS_NO_PROMPT=1 は、エージェントのインタラクション動作と JSON 出力の両方を設定する従来の別名です。移行するには、両方の動作を維持できるよう WORKOS_MODE=agent を設定し、コマンドに --json を渡してください。WORKOS_MODE=agent のみを使用すると、暗黙の JSON フォーマットが適用されなくなります。
• WORKOS_FORCE_TTY=1 は出力フォーマットのみに影響し、インタラクションモードは変更しません。

トピック → リファレンスマップ

用語の確認（「X とは」「X のドキュメント URL」など）は、このトピックマップではなく、以下のルール 0で扱います。これらは references/workos-terms.md に誘導されます。

AuthKit のインストール（references/{name}.md を読みます）

ユーザーの目的	読むファイル
Next.js に AuthKit をインストールする	references/workos-authkit-nextjs.md
React SPA に AuthKit をインストールする	references/workos-authkit-react.md
React Router で AuthKit をインストールする	references/workos-authkit-react-router.md
TanStack Start で AuthKit をインストールする	references/workos-authkit-tanstack-start.md
SvelteKit で AuthKit をインストールする	references/workos-authkit-sveltekit.md
vanilla JS に AuthKit をインストールする	references/workos-authkit-vanilla-js.md
AuthKit のアーキテクチャリファレンス	references/workos-authkit-base.md
AuthKit のアプリケーション URL を設定する	references/workos-authkit-setup.md
Widgets ／ Clerk スタイルの UI を追加する	Skill ツールで workos-widgets スキルを読み込みます
Widgets API への直接リクエストを構築する	workos-widgets → fetching-apis.md

バックエンド SDK のインストール（references/{name}.md を読みます）

ユーザーの目的	読むファイル
Node.js バックエンドに AuthKit をインストールする	references/workos-node.md
Python に AuthKit をインストールする	references/workos-python.md
.NET に AuthKit をインストールする	references/workos-dotnet.md
Go に AuthKit をインストールする	references/workos-go.md
Ruby に AuthKit をインストールする	references/workos-ruby.md
PHP に AuthKit をインストールする	references/workos-php.md
PHP Laravel に AuthKit をインストールする	references/workos-php-laravel.md
Kotlin に AuthKit をインストールする	references/workos-kotlin.md
Elixir に AuthKit をインストールする	references/workos-elixir.md

機能（references/{name}.md を読みます）

ユーザーの目的	読むファイル
シングルサインオンを設定する	references/workos-sso.md
Directory Sync を設定する	references/workos-directory-sync.md
RBAC ／ロールを実装する	references/workos-rbac.md
Vault でデータを暗号化する	references/workos-vault.md
WorkOS イベント ／ Webhook を処理する	references/workos-events.md
監査ログを設定する	references/workos-audit-logs.md
Admin Portal を有効にする	references/workos-admin-portal.md
多要素認証を追加する	references/workos-mfa.md
メール配信を設定する	references/workos-email.md
カスタムドメインを設定する	references/workos-custom-domains.md
IdP 統合を設定する	references/workos-integrations.md
FGA ／きめ細かな認可を実装する	references/workos-fga.md
Pipes ／ Connected Apps を設定する	references/workos-pipes.md
Feature Flags を設定する	references/workos-feature-flags.md
Radar ／不正検出を設定する	references/workos-radar.md

API リファレンス（references/{name}.md を読みます）

上記の機能トピックファイルには、それぞれの API のエンドポイント一覧が含まれています。機能トピックがない場合は、次の API 専用リファレンスを使用してください。

ユーザーの目的	読むファイル
AuthKit API リファレンス	references/workos-api-authkit.md
Organization API リファレンス	references/workos-api-organization.md

移行（references/{name}.md を参照してください）

ユーザーの目的	参照するファイル
Auth0 から移行する	references/workos-migrate-auth0.md
AWS Cognito から移行する	references/workos-migrate-aws-cognito.md
Better Auth から移行する	references/workos-migrate-better-auth.md
Clerk から移行する	references/workos-migrate-clerk.md
Descope から移行する	references/workos-migrate-descope.md
Firebase から移行する	references/workos-migrate-firebase.md
Stytch から移行する	references/workos-migrate-stytch.md
Supabase Auth から移行する	references/workos-migrate-supabase-auth.md
スタンドアロン SSO API から移行する	references/workos-migrate-the-standalone-sso-api.md
その他のサービスから移行する	references/workos-migrate-other-services.md

管理と CLI のライフサイクル（references/{name}.md を参照してください）

ユーザーの目的	参照するファイル
WorkOS MCP サーバーをセットアップまたは復旧する	references/workos-mcp.md
WorkOS リソースを管理する（MCP サーバーまたは CLI）	references/workos-management.md
workos CLI を新しいバージョンにアップグレードする	references/workos-cli-upgrade.md

ルーティングの判断ツリー

以下のルールを順番に適用します。最初に一致したルールが適用されます。

0. 用語／ドキュメント URL の検索

トリガー：検索を目的とした表現 —「X とは何か」「X はどういう意味か」「X のドキュメント URL」「X のドキュメントはどこか」「X の正式なリンク」「ダッシュボードで X を設定する場所」など。X は WorkOS 固有の設定フィールド、エンドポイント、環境変数、または用語です。例：initiate_login_uri、「サインインエンドポイント」、「リダイレクト URI」、ダッシュボードのフィールド名、WORKOS_* 環境変数。

「Vault をセットアップする」「Admin Portal を有効にする」「MFA を設定する」のような、セットアップを目的とした表現にはルール 0 を適用しないでください。これらはルール 3（機能固有）に振り分けます。

アクション：

1. references/workos-terms.md を読みます。WorkOS の用語と正式なドキュメント URL を対応付けた厳選テーブルがあります。
2. 用語がテーブルにある場合は、概要を使って回答します。ユーザーが詳細を求めている場合に限り、記載された URL を WebFetch します。
3. 用語がテーブルにない場合は、そのファイル末尾の「まだ見つからない場合」のフォールバックに従います。正式な URL を見つけたらユーザーに回答し、行を追加するために PR を作成するよう提案します。

用語の検索では、用語ファイルを読む前に llms.txt を WebFetch したり、workos.com/docs/... の URL を推測したりしないでください。（ルール 8 と 9 では別の目的で llms.txt を使用します。この制限はルール 0 のみに適用されます。）

このルールが優先される理由：用語の検索は、機能、フレームワーク、移行のコンテキストとは無関係に発生します。そのため、ルール 8 の「曖昧または一般的」へ進むのではなく、ルーティングをここで終了させる必要があります。

---

1. 移行のコンテキスト

トリガー：ユーザーが別のプロバイダー（Auth0、Clerk、Cognito、Firebase、Supabase、Stytch、Descope、Better Auth、スタンドアロン SSO API）からの移行について言及している。

アクション：references/workos-migrate-[provider].md を読みます。[provider] は移行元のシステムに対応します。プロバイダーがテーブルにない場合は、references/workos-migrate-other-services.md を読みます。

このルールが優先される理由：移行のコンテキストは機能固有のルーティングより優先されます。ユーザーにはプロバイダー固有のデータエクスポートと変換の手順が必要なためです。

---

2. API リファレンスに関するリクエスト

トリガー：「API エンドポイント」「リクエスト形式」「レスポンススキーマ」「API リファレンス」について明示的に質問する場合、または HTTP の詳細を調べたいと言及する場合。

Widgets の例外：Widgets Client API への直接的なリクエストや GraphQL リクエストでは、workos-widgets とその references/fetching-apis.md を読み込みます。現在のドキュメントでは POST /client/graphql を使用します。公開済み React ウィジェットの埋め込みは、別途コンポーネントを設定する作業です。いずれも汎用的なワークスペース管理に振り分けたり、同梱されている /_widgets の REST テーブルが現在の API を示すと想定したりしないでください。

アクション：トピックファイルがある機能（SSO、Directory Sync、RBAC、Vault、Events、Audit Logs、Admin Portal）については、その機能のトピックファイルを読みます。エンドポイントの一覧表が記載されています。AuthKit または Organization API については、references/workos-api-[domain].md を読みます。

この振り分けを優先する理由：API リファレンスは低レベルの情報です。機能トピックはより高レベルですが、すぐに参照できるエンドポイント一覧表が含まれています。

---

3. 機能固有のリクエスト

トリガー：ユーザーが特定の WorkOS 機能名（SSO、MFA、Directory Sync、Audit Logs、Vault、RBAC、FGA、Admin Portal、Custom Domains、Events、Integrations、Email、Pipes、Feature Flags、Radar）に言及する場合。

アクション：references/workos-[feature].md を読みます。[feature] は小文字のスラッグです（sso、mfa、directory-sync、audit-logs、vault、rbac、fga、admin-portal、custom-domains、events、integrations、email、pipes、feature-flags、radar）。

例外：Clerk の UserButton との比較、プロフィール／アカウント設定、セキュリティ／セッション UI、組織切り替え、メンバー管理 UI を含むウィジェットに関するリクエストでは、Skill ツールを使って workos-widgets スキルを読み込みます。これはエンドユーザー向けに埋め込む UI であり、ワークスペース管理コマンドではありません。AuthKit のログイン／セッション関連の設定は引き続きルール 4 に従います。移行および用語に関するリファレンスからも Widgets の設定にリンクします。

振り分けの判断：ユーザーが機能と「API」の両方に言及する場合は、機能トピックファイルに振り分けます（エンドポイントが含まれています）。複数の機能に言及する場合は、まず最も具体的な機能に振り分けます（例：「SSO with MFA」→ SSO に振り分けます。MFA については別途リクエストできます）。「FGA」または「fine-grained authorization」に言及する場合は、workos-rbac ではなく workos-fga に振り分けます。RBAC は組織レベルのロール、FGA は RBAC を基盤としたリソーススコープのロールです。

特別なケース — IdP グループからロールへのマッピング：ユーザーが Entra／Azure AD／Okta／Google Workspace／SCIM／ディレクトリ／SSO のグループを WorkOS のロールにマッピングする方法を質問した場合（表現が異なっていても）、workos-rbac.md と、ソース固有のリファレンスの両方を読みます。

• Directory Sync／SCIM／Google Workspace グループ → workos-directory-sync.md も読みます
• SSO 専用グループ → workos-sso.md も読みます

現在、両方のファイルに標準的な手順が記載されています。記憶に頼った回答や、ダッシュボードのメニュー操作手順の言い換えは避けてください。ドキュメントでは具体的なクリック手順が確約されていないため、回答でも同様に確約しないでください。このマッピングは WorkOS CLI の操作ではありません。CLI コマンドを求められた場合は、CLI では実行できないことを伝え、ドキュメントへのリンクを案内してください。

---

4. AuthKit のインストール

トリガー：ユーザーが認証の設定、ログインフロー、サインアップ、セッション管理に言及する場合、または SSO や MFA などの特定の機能に触れずに「AuthKit」と明示する場合。

アクション：プロジェクトに WorkOS の認証情報がまだない場合は、まず Start here のアカウント不要のインストールを実行し、その後、以下のリファレンスを使って確認します。以下の証拠確認に基づいて、フレームワーク、ランタイムモード、言語を判定します。該当するリファレンスファイルと references/workos-authkit-setup.md の両方を読みます。統合が完了したと報告する前に、アプリケーション設定とフローの確認を完了してください。

振り分けの判断：

• ユーザーが「SSO login via AuthKit」と言う場合は、workos-sso（#3）に振り分けます。フレームワークより機能を優先します。
• ユーザーが「React login with Google」と言う場合は、AuthKit React（#4）に振り分けます。これは SSO API ではなく、AuthKit レベルの認証です。
• ユーザーがすでに AuthKit を使用していて、機能の追加を求める場合（例：「add MFA to my AuthKit app」）は、AuthKit のインストールではなく、機能リファレンス（#3）に振り分けます。

フレームワークとランタイムの検出（AuthKit のみ）

アクティブなアプリ／ワークスペースを調べます。パッケージスクリプトと依存関係、フレームワーク／ルーターの設定、SDK のインポート、ルート登録、サーバーの実行方法、デプロイ動作を確認してください。依存関係の名前だけで SDK を選択することはできません。また、ブラウザーローダーがあるだけではサーバーの存在を確認したことにはなりません。

確認済みのアクティブな統合	参照
Next.js の設定／スクリプトと Next.js のルート／ランタイム	references/workos-authkit-nextjs.md
TanStack Start の設定／スクリプトと Start のランタイム	references/workos-authkit-tanstack-start.md
SvelteKit の設定／スクリプトと Kit のランタイム	references/workos-authkit-sveltekit.md
デプロイされたサーバーフレームワークのルートを使用する React Router	references/workos-authkit-react-router.md
クライアント専用の React。React Router のライブラリ／データ／宣言的な使用、および静的にデプロイされたフレームワークの SPA モード（ssr: false）を含む	references/workos-authkit-react.md
React を使わないことが確認済みのブラウザー JavaScript	references/workos-authkit-vanilla-js.md

React Router がある場合、実行方法が不明確なら references/workos-authkit-react-router.md のモード確認を参照してください。設定ファイル、@react-router/node、ビルド時の事前レンダリングだけでは、リクエスト時に実行されるサーバーの証拠にはなりません。ブラウザーローダーや静的デプロイに、サーバーコールバックや環境変数の要件を適用しないでください。ランタイムとホスティング設定を調べ、不明点が残る場合は質問してください。

言語の判定（バックエンド SDK）

プロジェクトが JavaScript／TypeScript のフロントエンドフレームワークでない場合は、マニフェストで判定します。

マニフェストの根拠	参照先
pyproject.toml / requirements.txt / setup.py	references/workos-python.md
go.mod	references/workos-go.md
Gemfile / config/routes.rb	references/workos-ruby.md
composer.json の依存関係に laravel/framework が含まれる	references/workos-php-laravel.md
Laravel を含まない composer.json	references/workos-php.md
*.csproj / *.sln	references/workos-dotnet.md
build.gradle.kts / build.gradle	references/workos-kotlin.md
mix.exs	references/workos-elixir.md
express / fastify / hono / koa を含む package.json	references/workos-node.md

Laravel と通常の PHP を区別する基準（laravel/framework の有無）は、ここで唯一わかりにくい点です。

複数の根拠があっても、優先順位を競わせないでください。 Next.js に React Router の依存関係が加わっていても、React Router が実際に使われているサーバーフレームワークになるわけではありません。どのアプリとランタイムが認証を担っているかを確認してください。バックエンド言語を確認するのは、フロントエンドフレームワークが見つからない場合です。プロジェクトを特定できないまま、バニラ JavaScript を既定にしないでください。

例外ケース — 根拠が矛盾している場合：設定、インポート、デプロイ方法に矛盾がある場合（例：サーバー SDK を使っているが、静的ホスティングを利用している場合）は、どのランタイムを使う想定かユーザーに確認してください。推測したり、フレームワークの移行を強制したりしないでください。

例外ケース — 文脈からフレームワークを特定できない場合：ユーザーが「ログインを追加して」と依頼しても、ファイルをスキャンできない場合（リモートリポジトリである、アクセス権がないなど）は、「どのフレームワーク／言語を使用していますか？」と確認してください。確認せずに既定値を設定しないでください。

---

5. インテグレーションのセットアップ

該当するケース：外部 IdP への接続、サードパーティインテグレーションの設定についてユーザーが言及した場合、または「[プロバイダー] とのインテグレーション方法」を尋ねた場合です。

アクション：references/workos-integrations.md を読みます。

SSO と分ける理由：SSO は認証フローを扱い、インテグレーションは IdP の設定と接続のセットアップを扱います。ユーザーが両方に言及した場合（「Google SSO を設定して」など）は、SSO（#3）に振り分けてください。必要に応じて、SSO の手順からインテグレーションを参照します。

---

6. MCP のセットアップまたは復旧

該当するケース：WorkOS MCP サーバーのインストールや設定、設定スコープの選択をユーザーが求めた場合、または WorkOS MCP ツールが見つからない、認証されていない、利用できない、起動中に中断されたと報告した場合です。

アクション：references/workos-mcp.md を読みます。セットアップと復旧を正規の WorkOS MCP ドキュメントに沿って進め、設定スコープと OAuth 認証情報を保護し、ユーザーが通常使用しているホストシェルで実行する必要がある認証手順を特定します。

こちらを優先する理由：MCP のセットアップが完了するまで、MCP ツールは呼び出せません。また、通常のワークスペース管理の案内では扱わない、設定スコープとホストの信頼性の確認が必要です。

---

7. 管理操作（MCP サーバーまたは CLI）

トリガー：ユーザーが WorkOS リソース（組織、ユーザー、ロール、権限）の管理、データのシード、または CLI 管理コマンドについて言及した場合です。

アクション：references/workos-management.md を読みます。最初に、ワークスペースの読み取りと書き込みには接続済みの WorkOS MCP ツールを優先し、ブートストラップ、シード、ローカル設定、CI、診断には CLI を使うという、利用する手段の選択ガイドがあります。MCP ツールが利用可能な場合でも必ず読みます。各操作をどちらの手段で行うかが記載されています。

サブケース — CLI のアップグレード：ユーザーが古い workos CLI について報告した場合（workos --version に古いリリースが表示される、最近のドキュメントに従った後に unknown command エラーが出る、または「workos CLI を更新するにはどうすればよいですか？」と尋ねる場合）は、代わりに references/workos-cli-upgrade.md を読みます。最新バージョンを推測してはいけません。そのファイルには、ユーザーに npm view workos version を実行するよう案内する手順が記載されています。

---

8. 曖昧または一般的なリクエスト

トリガー：ユーザーが「WorkOS を手伝ってほしい」「WorkOS のセットアップ」「WorkOS で何ができますか」と言う場合、または特定の機能に関する情報がない場合です。

アクション：

1. https://workos.com/docs/llms.txt を WebFetch します
2. ユーザーの意図に最も合いそうなセクションをインデックスから探します
3. 該当するセクションの URL を WebFetch します
4. 機能を要約し、ユーザーが何を達成したいのかを尋ねます

機能を推測してはいけません。選択肢を提示して、必ず意図を明確にします。

---

9. 一致なし／曖昧

トリガー：上記のルールのいずれにも当てはまらない場合、またはリクエストが本当に曖昧な場合です。

アクション：

1. https://workos.com/docs/llms.txt を WebFetch します
2. ユーザーのリクエストに含まれるキーワードをインデックス内で検索します
3. 一致する項目が見つかった場合、そのセクションの URL を WebFetch して処理を進めます
4. 一致する項目が見つからない場合は、次のように回答します：「『[user's term]』に該当する WorkOS の機能が見つかりませんでした。もう少し詳しく教えていただけますか？たとえば、認証、SSO、MFA、ディレクトリ同期、監査ログなどがあります。」

各ルール内には、ルールをまたぐ曖昧さの解消方法も記載されています。複数の機能 → 最も具体的なもの（ルール 3）、機能＋API → 機能ファイル（ルール 2～3）、既存の AuthKit アプリへの機能追加 → 機能リファレンス（ルール 4）、機能を指定せずプロバイダーのみを指定 → Integrations（ルール 5）、プロバイダー＋機能 → 機能リファレンス（ルール 3）、不明または競合するフレームワーク → ユーザーに尋ねます（ルール 4）。