temporal-ops

スキル：temporal-ops

概要

このスキルは Temporal 環境の運用と診断を行います。モードは 2 つあります。

• 運用： ユーザーが何かを実行したい場合です。たとえば、ネームスペースの作成、キーのローテーション、キャパシティの確認、異常なワークフローの特定、バッチのキャンセル、エクスポートの設定などです。このスキルは適切なコマンドを実行し、出力を解釈します。
• 診断： ユーザーが症状を示して相談に来た場合です。たとえば、ワークフローの停止、証明書エラー、接続タイムアウト、非決定性によるパニックなどです。このスキルは、根本原因を信頼度スコアとともに特定するまで、階層的かつボトムアップで調査を進めます。

ワークフローやアクティビティの書き方は説明しません（その場合は skill-temporal-developer を使用してください）。網羅的な CLI フラグ一覧も再掲しません。これらについては temporal <cmd> --help を実行し、コマンド間で共通する CLI の規約については cli-conventions.md を参照してください。ユーザーが稼働中の Temporal 環境の管理やトラブルシューティングを必要としている場合、このスキルが適用されます。

対象外

• ワークフロー、アクティビティ、SDK コードの作成 → skill-temporal-developer。
• 網羅的な CLI フラグ／コマンドリファレンス → temporal <cmd> --help を実行してください。コマンド間で共通する CLI の規約 → cli-conventions.md。
• ワーカーのパフォーマンス調整、サイジング、キャパシティプランニング → skill-temporal-workertuning。
• セルフホスト環境の Helm、Kubernetes、データベース管理、監視スタックの設定 は対象外です。CLI の範囲を超えます。

会話がこれらの領域に逸れた場合は、即興で対応せず、適切な関連スキルに引き継いでください。

基本方針

オペレーターとしての規律

ユーザーが運用タスクの実行を希望する場合：

1. 意図とバックエンドを確認します。 これは Cloud の操作（tcld）ですか、それともセルフホスト環境の操作（temporal operator）ですか？ データプレーンの操作（temporal workflow、temporal batch など）はどちらでも実行できます。バックエンドが不明な場合は、処理を進める前に確認してください。Cloud かセルフホストかを決めつけず、判明するまでは環境固有のコマンドを出力しないでください。
2. コマンドを実行し、出力を解釈します。 ドキュメントに記載されたコマンドを実行し、結果を読み、その意味を報告します。ユーザーが操作を依頼した場合は、その操作を実行します。読み取り専用コマンド（get、list、describe、count、show）はそのまま実行できます。破壊的な操作 に記載された操作は、事前にユーザーへ提案します。
3. 結果を検証します。 変更を伴う操作の後に、新しい状態がユーザーの意図と一致していることを確認します。

破壊的な操作

操作が取り消し不能（tcld namespace delete）、稼働中の ID のアクセス権を取り消す（tcld apikey delete）、本番トラフィックを移動する （tcld namespace failover）、または一致するすべての対象に対して実行される （--query を使う形式）場合、その操作はこの階層に属します。目の前の操作にこの基準を適用してください。これは一覧ではなくルールです。このスキル内のいずれの一覧にもコマンドが載っていないからといって、この階層の対象外になるわけではありません。

この階層に属する操作では、証拠を集めて提案してください。自分の判断で実行してはいけません。また、どのような動作になるかを調べるために実行してはいけません。各コマンドのリファレンスファイルには、そのコマンド固有の影響範囲が記載されています。提案する前に確認してください。

1. 影響範囲は説明ではなく数値で示す。 --query を使う形式では、まずバイト単位で完全に一致するクエリを使って temporal workflow count --query '<query>' を実行し、その結果を提案に含めてください。ExecutionStatus="Running" 以外に対象を絞り込む述語がないフィルターは、Namespace 内のすべてのオープンな Execution に一致します。
2. 対象を明示する。 正確なコマンド、対象、およびそのコマンドが解決する Namespace を明記してください。接続設定は TEMPORAL_* 環境変数や設定ファイルのプロファイルから取得される場合があるため、対象がコマンドの記述から判別できないことはよくあります。バックエンドや Namespace をユーザーの明示ではなく文脈から推測した場合は、そのことを伝えてください。破壊的なコマンドが誤った Namespace に向けられることが、最もよくある失敗です。
3. 明示的に確認を求めてから、完了するまで実行する。 コマンド、対象、および --query を使う形式の場合は手順 1 の件数を、ユーザーに直接質問として提示し、回答を待ってください。承認されたら、--query を使うバッチ形式では --yes を付けて実行してください。承認済みのバッチを最後まで実行するにはこのフラグが必要です。対話型プロンプトにはターミナルが必要なため、ターミナルがない場合は、コマンドは user denied confirmation と報告して何も実行しません。--yes を付けるのはユーザーが承認したコマンドだけです。プロンプトに失敗したコマンドの再試行に付けてはいけません。単一の対象に対する workflow terminate --workflow-id をループで実行する方法に置き換えてはいけません。承認が適用されるのは、1 つの対象に対する 1 つのコマンドだけです。次のコマンド、対象を広げたクエリ、または 2 つ目の Namespace には引き継がれません。
4. 確認し、中断方法を把握する。 対応する get、describe、または count を再実行してください。バッチジョブは非同期で処理されます。 temporal batch describe --job-id <id> で進捗を確認でき、 temporal batch terminate --job-id <id> で、残りの一致対象に到達する前に停止できます。

同じ目的を達成できる可逆的な関連操作がある場合は、併せて提案してください。cancel では terminate では実行されない Workflow のクリーンアップコードを実行できます。apikey disable は可逆ですが、delete は元に戻せません。accepted-client-ca add は追加しますが、set は置き換えます。

環境内の何かが自分に代わって破壊的なコマンドを止めてくれるとは考えないでください。認証情報のスコープ、コマンドの拒否リスト、確認プロンプトは設定されている場合も、されていない場合もあります。存在する可能性があるからといって上記の手順を省略してはいけません。ユーザーが頼りにしている安全策はあなたです。

診断の原則

ユーザーが障害や異常を報告した場合：

1. 下位層から診断します。 上位層を疑う前に、下位層を確認します。下から上への各層は次のとおりです。

   1. DNS／ネットワーク経路
   2. TCP／ポートへの到達性
   3. TLS ハンドシェイク
   4. 認証（API キーまたは mTLS クライアント証明書）
   5. gRPC ヘルスチェックと Temporal フロントエンドへの到達性
   6. Temporal の名前空間、タスクキュー、ワーカー
   7. ワークフローのコード（決定性、シグナル、タイマー、子ワークフロー）

   診断手順の全体像は、diagnostic-ladder.md を参照してください。

2. 推測に基づいて修正を提案するのではなく、必ず次の上位層も確認します。 TLS が機能しているなら、ワークフローを疑う前に認証が機能していることを確認します。ポーラーが存在するなら、ワーカーを疑う前にワークフローの最後のイベントを確認します。

3. 提案する診断にはすべて、確信度（1～10）を添えます。

   • 9～10：症状、操作、確認シグナルが明確に一致しています。
   • 6～8：十分な証拠はありますが、少なくとも一つの代替原因が考えられます。
   • 1～5：問題はまだ特定できていません。「修正」ではなく、原因を絞り込むための次の確認事項を示します。

4. 曖昧さを明示します。 context deadline exceeded のようなエラーだけでは原因を特定できません。また、RESOURCE_EXHAUSTED のような単一のコードが、複数の状態（アカウント上限によるスロットリングや、Workflow ごとのロック競合など）を示すこともあります。その点を明らかにし、より多くの情報を集めて、次の手順の範囲を絞り込みます。

これらはスキル上の規約であり、ドキュメントから導かれた事実ではありません。

意図の振り分け

運用

ユーザーの意図に一致する行を探してください。コマンドと手順は参照ファイルに記載されています。

意図	カテゴリ	リファレンス
Cloud 名前空間の作成、取得、一覧表示、削除	Cloud 名前空間管理	cloud-namespace-admin.md
リージョンの追加／削除、フェイルオーバー、HA 設定	Cloud 名前空間管理	cloud-namespace-admin.md
保持期間、タグ、codec-server、接続ルールの設定	Cloud 名前空間管理	cloud-namespace-admin.md
Cloud 検索属性の追加または名前変更	Cloud 名前空間管理	cloud-namespace-admin.md
現在の APS／容量モードの確認	Cloud 容量	cloud-capacity.md
On-Demand ↔ Provisioned の切り替え、TRU の設定	Cloud 容量	cloud-capacity.md
APS／RPS／OPS の上限とスロットリングについて確認	Cloud 容量	cloud-capacity.md
API キーの作成、無効化、有効化、削除	Cloud IAM	cloud-iam.md
ユーザーの招待、一覧表示、削除、ロール／権限の設定	Cloud IAM	cloud-iam.md
ユーザーグループとサービスアカウントの管理	Cloud IAM	cloud-iam.md
mTLS 証明書の生成、CA のアップロード、証明書フィルターの設定	Cloud 証明書	cloud-certs.md
mTLS 証明書のローテーション	Cloud 証明書	cloud-certs.md
Workflow History Export（S3／GCS）の設定	Cloud 名前空間管理	cloud-namespace-admin.md
PrivateLink／PSC の設定、接続ルールの管理	Cloud 接続	cloud-connectivity.md
セルフホストクラスターの健全性確認、詳細表示、名前空間の CRUD	セルフホスト管理	self-hosted-admin.md
セルフホストの検索属性、Nexus エンドポイント	セルフホスト管理	self-hosted-admin.md
Cloud Nexus Endpoint の呼び出し元 Namespace 許可リスト（デフォルトの呼び出し元数 1,000 件を含む）の確認または管理	Cloud 名前空間管理	cloud-namespace-admin.md#tcld-nexus-endpoint-allowed-namespace
リストクエリで停止／ハング／異常なワークフローを検索	ワークフローの健全性	workflow-health.md
タスクキューポーラーの状態、ワークフロー数	ワークフローの健全性	workflow-health.md
ワークフローのキャンセル、終了、リセット	ワークフローの復旧	workflow-stuck.md#recovery-commands
ワークフローに対する一括／バッチ操作（--query）	CLI の規約	cli-conventions.md
スケジュールの CRUD、時間指定、操作	CLI の規約	cli-conventions.md
アクティビティを外部から完了または失敗させる	CLI の規約	cli-conventions.md
Cloud Ops API アクセス、レート制限、Go SDK	Cloud Ops API	cloud-ops-api.md
請求の確認、請求レポートの生成、コストの割り当て	Cloud 請求	cloud-billing.md
監査ログの表示、API 経由のクエリ、シンク（AWS/GCP）の設定	Cloud 監査ログ	cloud-audit-logs.md
Terraform プロバイダー：Namespace/User/SA/API Key/Nexus の CRUD	Cloud Terraform	cloud-terraform.md
有効期限アラート（証明書、API キー、クレジット）、ステータスページ	Cloud 通知	cloud-notifications.md
SAML SSO、SCIM プロビジョニング、IdP 統合	Cloud SAML/SCIM	cloud-saml-scim.md
セルフホストから Cloud への移行（自動または手動）、Cloud リージョン間の移行	Cloud 移行	cloud-migration.md
エンドツーエンドの運用プレイブック（セットアップ、ローテーション、監査、請求、Terraform）	運用レシピ	ops/recipes.md

診断

ユーザーの症状に該当する行を探します。最初の確認項目から調査を始め、リンク先のリファレンスを読んでください。

症状	カテゴリ	最初の確認事項	リファレンス
connection refused、フロントエンドに到達できない	接続性	nc -zvw10 <host> 7233	connectivity.md#connection-refused
no such host、DNS 解決に失敗する	接続性	dig +short <host> または nslookup <host>	connectivity.md#dns
tls: handshake failure、サーバーがハンドシェイクを拒否する	証明書	openssl s_client -connect <host>:7233 -servername <host> </dev/null	certificates.md#handshake-failure
x509: certificate has expired または not yet valid	証明書	openssl x509 -enddate -noout -in cert.pem	certificates.md#expired-or-not-yet-valid
x509: certificate signed by unknown authority	証明書	openssl verify -CAfile ca.pem client.pem	certificates.md#unknown-authority
tcld のセッション／認証に失敗する、Cloud のロールが不明	認証	tcld account get	authentication.md#cloud-role-and-permission-model
UNAUTHENTICATED、API キーが拒否される	認証	env | grep -i TEMPORAL_API_KEY を実行し、次に tcld apikey get --id <apikey_id>	authentication.md#things-to-check-when-unauthenticated-is-returned-with-an-api-key
namespace not found／API キー使用時の Namespace 文字列が間違っている	認証	Regional Endpoint の形式が <region>.<cloud_provider>.api.temporal.io:7233 であることを確認	authentication.md#address-form-for-api-key-connections
RESOURCE_EXHAUSTED gRPC ステータス	レート制限	どの制限に達したかを特定します。Cloud v1 ではスロットルのメトリクス、v0／セルフホストでは resource_exhausted_cause ラベルを確認します	rate-limits.md#identifying-which-limit-was-hit
タスクキューにポーラーが表示されない	ワーカーの健全性	temporal task-queue describe --task-queue <q>	worker-health.md#what-no-pollers-looks-like
保留中のアクティビティ／タイマー／子ワークフロー／シグナルでワークフローが停止している	ワークフローの停止	temporal workflow describe --workflow-id <id>	workflow-stuck.md#the-primary-inspection-command-temporal-workflow-describe
NondeterminismError、WorkflowTaskFailed が繰り返し発生する	非決定性	Event History で直近の WorkflowTaskFailed の原因を特定します	non-determinism.md#the-wft-failure-signature-of-non-determinism
ローカルではリプレイに失敗するが、本番環境ではワークフローが実行されていた	非決定性	履歴を取得し、SDK リプレイヤーを 1 つのテストで実行します	replay.md#step-2--run-the-sdk-replayer-all-supported-sdks
HA フェイルオーバー後、トラフィックがフェイルオーバー先のリージョンにルーティングされなかった	HA フェイルオーバー	tcld namespace get --namespace <ns>.<acct> と DNS CNAME を比較します	ha-failover.md#start-here-establish-ground-truth
Serverless Worker（AWS Lambda）が Namespace のフェイルオーバー後に処理を停止した	HA フェイルオーバー	FailoverNamespace 監査イベントを確認し、新しいアクティブリージョンと Worker Deployment Version の Lambda ARN を比較します	ha-failover.md#symptom-serverless-workers-kept-running-in-the-old-region-after-failover
context deadline exceeded（どのレイヤーか不明）	ランタイムエラー	どの操作と SDK で発生したかを特定します	runtime-errors.md#deadline-exceeded
1 つの Workflow へのシグナル／更新／クエリで Workflow is busy／ResourceExhausted が発生する（BusyWorkflow）	ランタイムエラー	アカウント制限によるスロットリングを除外してから、temporal_cloud_v1_resource_exhausted_error_count を operation で分割します	runtime-errors.md#workflow-lock-contention-busyworkflow
PAYLOADS_TOO_LARGE、exceeds size limit、ペイロード／gRPC blob サイズエラー	blob サイズ制限	問題がペイロード（2 MB）か gRPC メッセージ（4 MB）かを確認します	blob-size-limits.md
ワークフローが見えないリトライループで停止する（gRPC メッセージが大きすぎる）	blob サイズ制限	Worker のログで ResourceExhausted を確認し、バッチサイズを小さくします	blob-size-limits.md
スケジュールから開始までのレイテンシーが高い、タスクスロットが枯渇する、Workflow Tasks が遅い	パフォーマンスのボトルネック	temporal_workflow_task_schedule_to_start_latency の P95 を確認します	performance-bottlenecks.md
リプレイのレイテンシーが高い、キャッシュのエビクションが発生する、デッドロックが検出される	パフォーマンスのボトルネック	workflow_task_replay_latency とスティッキーキャッシュのメトリクスを確認します	performance-bottlenecks.md
スケジュールが実行されなかった、キャッチアップ可能な期間を逃した	スケジュールアクションの未実行	temporal_cloud_v1_schedule_missed_catchup_window_count に対してアラートを設定します	schedule-missed.md
症状が表に当てはまらない場合は、diagnostic-ladder.mdから始め、最後に正常と確認されたレイヤーから順に遡ってください。

プロセス

運用の流れ

ステップ 1：意図とバックエンドを特定する

ユーザーが何をしたいのか、対象がどのバックエンドなのかを確認します。

• Temporal Cloud → tcld コマンドを使用します（tcld loginが必要です）
• セルフホストクラスター → temporal operator コマンドを使用します
• データプレーン（どちらのバックエンドでも） → temporal workflow、temporal batch、temporal scheduleなどを使用します

コンテキストからバックエンドが明確な場合（.tmprl.cloudアドレス、tcldコマンド、Cloudのネームスペース形式ns.accountならCloud、Kubernetes/Helm、docker-compose、セルフホストの設定ファイルならセルフホスト）は、質問せずに進めてください。それ以外の場合は、環境固有のコマンドを出力する前に作業を止め、「Temporal Cloudとセルフホストのどちらをお使いですか？」と尋ねてください。 どちらかの環境を既定として選ばないでください。回答がわかったら、今後の会話で再度尋ねないよう、メモリーに保存してください。

ステップ 2：実行して結果を解釈する

上記の運用表で該当する意図を確認します。正確なコマンド、フラグ、想定される出力については、リンク先のリファレンスファイルを読んでください。コマンドを実行し、結果をユーザーにわかりやすく説明します。

ステップ 3：確認する

変更を伴う操作（作成、更新、削除、ローテーション）の後は、新しい状態を確認します。

• 対応するgetまたはdescribeコマンドを再実行します
• 出力がユーザーの意図どおりであることを確認します
• 結果を報告します

診断の流れ

ステップ 1：症状を特定する

ユーザーに、エラーの正確なテキストをコピーして貼り付けてもらいます。言い換えは受け付けないでください。正確な文字列から、該当するレイヤーがわかることがよくあります（例：x509:プレフィックスはTLS/証明書レイヤー、RESOURCE_EXHAUSTED:プレフィックスはgRPCレート制限、NondeterminismErrorはワークフローのリプレイレイヤーを示します）。RESOURCE_EXHAUSTEDだけでは、どの条件が発生したかはわからない点に注意してください。アカウント制限によるスロットリングと、ワークフローごとのロック競合（Workflow is busy、つまりBusyWorkflow）は、どちらも同じコードを使用します。フリーテキストのメッセージを解析するのではなく、リソース枯渇メトリクスをラベルで分割してください（Cloud v1系列ではoperation、v0およびセルフホストではresource_exhausted_cause）。

先に進む前に、次の3点を確認してください。

• どのコマンドを実行したか、またはどのSDK呼び出しでエラーが発生したか。
• どの環境で発生したか（ローカル開発サーバー、セルフホストクラスター、Temporal Cloud）。コンテキスト（アドレス、コマンド、ネームスペース形式）から明らかな場合は尋ねないでください。ただし、不確かな場合は、診断を進める前に必ず尋ねてください。 今後の会話のために、回答をメモリーに保存してください。
• 最近何が変わったか（新しいデプロイ、新しい証明書、新しいネームスペース、新しいリージョンなど）。

ステップ 2：コンテキストを収集する

調査に必要なコンテキストは、カテゴリによって異なります。最低限、次の情報を集めてください。

• Cloudの認証／接続性に関する問題全般： 認証方式（APIキーまたはmTLS）、正確なアドレス、正確なネームスペース、SDKとそのバージョン。エンドポイントの系列は認証方式によって異なります。connectivity.md#endpoint-formatsを参照してください。プライベート接続（PrivateLink／PSC）の場合、TLSサーバー名のオーバーライドも認証方式によって異なります。cloud-connectivity.mdを参照してください。
• 停止しているワークフロー： ネームスペース、ワークフローID、実行ID、およびtemporal workflow describe --workflow-id <id>の出力（保留中の操作状態はここにあり、Event Historyだけでは確認できません）。temporal workflow showによるEvent Historyは、補足的な確認手段です。
• ワーカーのヘルスに関する問題： ワーカーログ（登録エラー、認証エラー、パニック）、temporal task-queue describe --task-queue <q>の出力、およびワーカーごとの詳細を確認するためのtemporal worker describe --task-queue <q>の出力。
• 非決定性エラー： エラーを含むワーカーログの行、ワークフロータイプ名、リプレイ用の履歴JSONへのアクセス。

ステップ 3：貼り付けられた SDK 設定を検証する（該当する場合）

ユーザーが SDK の接続コードを貼り付けている場合は、アドレス／名前空間／認証フィールドだけであっても、診断の階層を下る前にsdk-snippet-review.md と照合してください。エンドポイントの種類が誤っている、名前空間が短い、認証方式が一致していないといった問題があると、それより下のレイヤーには問題がないにもかかわらず、以下のネットワークレイヤーのプローブがすべて失敗しているように見えます。

ユーザーが以前から確立している、動作実績のある設定を使っていて、症状が新たに発生した場合は、このステップをスキップしてください。問題の原因はスニペットではなく、環境の変化です。それ以外の場合は、スニペットの検証をレイヤー 0 として扱ってください。

ステップ 4：診断の階層を下る

diagnostic-ladder.md を使って、適切な開始レイヤーを選んでください。目安は次のとおりです。

• 認証／接続／証明書の症状 → レイヤー 1（DNS）から開始し、上へ進みます。
• ワーカー／タスクキューの症状 → レイヤー 6（名前空間 + ポーラー）から開始します。
• 停滞したワークフロー／決定性の症状 → レイヤー 7（ワークフローコード）から開始しますが、まずレイヤー 6（ワーカーが実際にポーリングしていること）を確認してください。

各レイヤーには、正常であることを確認するコマンドと、問題がそのレイヤーにあるのか、それより上にあるのかを判別する失敗の兆候があります。

ステップ 5：修正して検証する

根本原因に絞った修正を提示してください。その後、そのレイヤーの正常性確認コマンドを再実行し、可能であれば元のユーザー操作も再実行して検証してください。診断には確信度スコアを添えてください。

修正したレイヤーより上のレイヤーでも問題が解決しない場合は、ステップ 4 に戻り、上へ進み続けてください。最初に見つかった問題のあるレイヤーだけが原因であることは、ほとんどありません。

前提条件

• Temporal CLI（temporal）— データプレーン操作およびセルフホスト環境の管理に必要です。インストール方法：brew install temporal または Temporal CLI のドキュメントを参照してください。
• tcld — Cloud 操作に必要です。インストール方法：brew install temporal-cloud-cli または tcld のドキュメントを参照してください。使用前に tcld login で認証してください。

参照ファイル

運用

• cloud-namespace-admin.md — tcld による Cloud 名前空間のライフサイクル管理：作成、取得、一覧表示、削除、フェイルオーバー、リージョン追加、保持期間、タグ、codec-server、HA 設定、接続ルール、検索属性、accepted-client-ca、証明書フィルター、エクスポート、および tcld nexus endpoint allowed-namespace による呼び出し元の許可リスト（Access Policy の上限は呼び出し元 1,000 件）。
• cloud-capacity.md — キャパシティモード（On-Demand／Provisioned）、APS／RPS／OPS の定義、TRU、tcld namespace capacity update、デフォルトの上限、スロットリング、APS 管理のベストプラクティス。
• cloud-iam.md — API キーのライフサイクル（tcld apikey）、ユーザー（tcld user）、ユーザーグループ（tcld user-group）、サービスアカウント、アカウント操作（tcld account）、ロール、名前空間の権限。
• cloud-certs.md — mTLS 証明書の管理：tcld generate-certificates による証明書の生成、CA のアップロード、証明書フィルター、証明書のローテーション、mTLS と API キーの切り替え。
• cloud-connectivity.md — プライベート接続（AWS PrivateLink／GCP PSC）、接続ルール：セットアップ、ルールのパラメーター、tcld コマンド、名前空間へのルールの適用。
• cloud-migration.md — 移行パス：セルフホストから Cloud への自動移行（S2S プロキシ、tcld migration コマンド、5 つのフェーズ）、セルフホストから Cloud への手動移行（クライアントの変更、ワークフロー戦略）、Cloud 内のリージョン間移行（HA のリージョン追加／フェイルオーバー）。
• cloud-ops-api.md — Cloud Ops API：HTTP および gRPC エンドポイント（saas-api.tmprl.cloud）、Go SDK、protobuf のコンパイル、レート制限（アカウントあたり 160 RPS、ユーザーあたり 40、SA あたり 80、非同期処理の同時実行数 10）、API バージョンヘッダー、ユースケース。
• cloud-billing.md — Cloud の請求：Billing Center（請求書、クレジット、プラン、名前空間ごとのコスト）、Usage Dashboards、Billing API：非同期 CSV レポート生成、FOCUS 対応形式、27 列のレポートスキーマ、日付範囲の制約。
• cloud-audit-logs.md — Cloud Audit Logs：サポート対象のコントロールプレーンイベント（アカウント、API キー、接続ルール、名前空間、エクスポート、Nexus、サービスアカウント、ユーザー、ユーザーグループ）、JSON 形式、API アクセス（保持期間 30 日）、AWS Kinesis および GCP Pub/Sub のシンク設定。
• cloud-terraform.md — Terraform プロバイダー：セットアップ（TEMPORAL_CLOUD_API_KEY）、temporalcloud_namespace／temporalcloud_user／temporalcloud_service_account／temporalcloud_apikey／temporalcloud_nexus_endpoint の CRUD、インポート、データソース（リージョン、名前空間）、制限事項（API キーはインポート不可、Account Owner は管理不可）。
• cloud-notifications.md — Cloud の通知：証明書の有効期限（15／10／5 日前）、API キーの有効期限（30／20／10 日前）、クレジットの消費／有効期限に関するアラート、プラン変更、フェイルオーバーイベント、受信者ロール、送信元 [email protected]。
• cloud-saml-scim.md — SAML SSO（Entra ID、Okta）：エンティティ識別子（urn:auth0:prod-tmprl:ACCOUNT_ID-saml）、コールバック URL（login.tmprl.cloud）、IdP の設定手順、サポートチケットのワークフロー。SCIM：サポート対象ベンダー、前提条件（先に SAML を設定）、10 分間の同期ウィンドウ、グループとロールのマッピング。
• self-hosted-admin.md — temporal operator によるセルフホスト型コントロールプレーンの管理：クラスターの健全性確認／詳細表示、名前空間の CRUD、検索属性の作成／一覧表示／削除、Nexus エンドポイントの CRUD。
• workflow-health.md — データプレーンの健全性クエリ：List Filters を使った temporal workflow list、temporal workflow describe／show／count、ポーラーの状態を確認する temporal task-queue describe。
• cli-conventions.md — temporal CLI の全コマンド共通規約：接続／ID（TEMPORAL_* 環境変数と --address／--namespace／--api-key、--identity の対応）、出力／書式設定（--output、--time-format、ペイロードの省略記法）、--query からバッチジョブへの橋渡し（temporal batch describe/list/terminate を使用）、スケジュールの時間指定形式。データプレーンの各操作を担当ファイルに案内する、操作→コマンドの索引で締めくくります。詳細なフラグについては temporal <cmd> --help を参照します。
• ops/recipes.md — エンドツーエンドの運用手順：新しい名前空間のセットアップ、APS の確認、キャパシティモードの切り替え、停止したワークフローの検索、API キーのローテーション、アクセスの監査、mTLS 証明書のローテーション、セルフホストの健全性確認、請求の確認／請求レポートの生成、監査ログシンクの設定、Terraform によるリソースのプロビジョニング、SAML SSO のセットアップ。

Diagnosis

• sdk-snippet-review.md — 貼り付けられた SDK 接続スニペットを対象とするレイヤー 0 の設定チェックです。認証方式ごとのエンドポイント形式、ネームスペース形式、認証／TLS の要件、TEMPORAL_* 環境変数、よくある設定ミスを確認します。診断の段階的な手順に進む前に実行してください。
• diagnostic-ladder.md — 下位層から上位層へ進む 7 層モデルです。各層の標準コマンドと、関連トピックの詳細ページへの相互リンクを掲載しています。
• connectivity.md — DNS、TCP、エンドポイントの種類（mTLS 用の Namespace Endpoint と API キー用の Regional Endpoint）、ファイアウォール／プロキシの構成、PrivateLink／PSC、簡易診断スクリプトを扱います。
• certificates.md — x509 と TLS のアラート文字列、有効期限切れ／認証局不明／ホスト名不一致／キー不一致の診断、tcld namespace accepted-client-ca による Cloud の許可クライアント CA セット、Cloud の mTLS 証明書要件、ローテーションと有効期限の通知、openssl の使用例を扱います。
• authentication.md — UNAUTHENTICATED と PERMISSION_DENIED の違い、API キーのライフサイクル（tcld apikey コマンド、環境変数の伝播、必須の Regional Endpoint 形式）、TLS 確立後の mTLS（証明書フィルター、ID とロールのマッピング）、Cloud のアカウントレベルのロールとネームスペースレベルの権限を扱います。
• workflow-stuck.md — Workflow Execution Status の値、主要な調査コマンドとしての temporal workflow describe、temporal workflow show による Event History の確認、保留中のアクティビティ／子ワークフロー／シグナル／Nexus 操作／Workflow Task、WorkflowTaskFailed の再試行ループ、復旧コマンド（シグナル送信、終了、キャンセル、リセット、一時停止／再開）を扱います。
• non-determinism.md — 決定性の定義、WFT 失敗の特徴、非決定性を引き起こすコードパターン、SDK ごとのエラー形式、Event History からの非決定性の特定、ローカルでのリプレイによる再現、Worker Versioning／パッチ／リセットによる修正を扱います。
• worker-health.md — temporal task-queue describe を使ったポーラー不在時の対応手順、到達可能性とバージョニング、ワーカーレベルの describe、スケジュールから開始までのレイテンシ、ワーカーのタスクスロット、スティッキー実行とスティッキーキャッシュ、ワーカーのハートビート、Cloud のネームスペースレベルのポーラー制限、ワーカーログの特徴を扱います。
• rate-limits.md — RESOURCE_EXHAUSTED が意味すること（および意味しないこと）、On-Demand と Provisioned の容量モードにおける Cloud の APS／RPS／OPS、セルフホスト環境での frontend.rps／frontend.namespaceRPS 動的設定、スロットルメトリクス（Cloud v1）または resource_exhausted_cause ラベル（v0／セルフホスト）による適用制限の特定、アカウント制限によるスロットリングと単一リソースの枯渇の切り分けを扱います。
• ha-failover.md — Namespace Endpoint の CNAME による Cloud HA ルーティング、アクティブリージョンの確認（コントロールプレーンの tcld namespace get と DNS の表示の比較）、フェイルオーバーに追従しなかったクライアント、フェイルオーバー後の PrivateLink、フェイルオーバーが実行されないケース、ハンドオーバー期間中のエラー、プラットフォームの制限、RPO／RTO の意味、コンピューティングプロバイダーの設定がリージョン単位であるためフェイルオーバーに追従しない Serverless Workers（AWS Lambda）を扱います。
• runtime-errors.md — 操作別および呼び出し元別の deadline-exceeded の切り分け、アカウント制限によるスロットリングと区別し operation の内訳で確認する Workflow ロック競合（BusyWorkflow）、no pollers／INVALID_ARGUMENT／詳細不明の UNAVAILABLE の対応先を扱います。
• replay.md — SDK クライアントを使った Event History の取得（代替手段としての CLI エクスポート）、サポート対象の各 SDK（Go、Python、TypeScript、Java、.NET、Ruby、PHP）での SDK リプレイヤーの実行、TEMPORAL_DEBUG とデッドロック検出器、差異のあるリプレイと正常なリプレイの解釈、TypeScript 専用の VS Code 拡張機能を扱います。
• blob-size-limits.md — ペイロードサイズ制限（2 MB）と gRPC メッセージサイズ制限（4 MB）、エラーメッセージ、SDK ごとの動作（Python 1.23.0+ とその他の SDK）、クレームチェックパターン、External Storage（プレリリース）、バッチサイズの縮小を扱います。
• performance-bottlenecks.md — SDK メトリクスによるレイテンシとスループットの診断を扱います。スケジュールから開始までのレイテンシ、ワークフロータスク実行レイテンシ、リプレイレイテンシ、アクティビティ実行レイテンシ、タスクスロットの枯渇、ネットワークリクエストメトリクス、スティッキーキャッシュメトリクスを確認できます。
• schedule-missed.md — スケジュールアクションの未実行を扱います。temporal_cloud_v1_schedule_missed_catchup_window_count／schedule_missed_catchup_window によるアラート、temporal schedule list と temporal schedule describe による調査、DescribeSchedule のフィールド（missedCatchupWindow、overlapSkipped、bufferDropped）、デフォルトのキャッチアップ期間（1 年）、根本原因、オーバーラップポリシー（6 種類）、バックフィルによる修正を説明します。
• recipes.md — エンドツーエンドのトリアージ手順を 4 つ紹介します。午前 3 時に停止したワークフロー、証明書の有効期限切れでオフラインになったワーカー、タスクキューのバックログの原因不明、プロダクション環境で検出された非決定性です。

このスキルに関する問題の報告

このスキルの説明が不明瞭、誤解を招く、または重要な情報が不足していると（AI が）判断した場合は、遭遇した問題と、何があれば役立ったかを説明する GitHub Issue の本文を作成し、ユーザーに https://github.com/temporalio/skill-temporal-ops/issues/new から投稿するよう依頼してください。Issue を自動で投稿しないでください。