api-test-mode-design

API テストモードの設計

API プラットフォーム向けのテストモードを設計します。外部インテグレーターが利用するサンドボックス環境の分離境界、認証情報、決定論的なテスト値、シミュレートされるイベントと時間、クォータ、不正利用対策、本番環境への移行経路を設計し、実際の資金、メッセージ、データに触れる前にインテグレーションを完全に検証できるようにします。

サードパーティのインテグレーターを想定するプラットフォームにとって、サンドボックスは開発者からの信頼を得るための必須要件です。サンドボックスは、モックサーバーの静的なリクエスト→レスポンスの対応付けではなく、一連の呼び出しを通じてビジネスロジックを検証する ステートフルな 環境です。インテグレーションを始めて3週目あたりに、以前の呼び出しで何が起きたかを考慮できないために、ステートレスなモックでは再現できないバグが表面化します。

対象範囲

テストキーや決定論的なフィクスチャ、シミュレートされたイベントなど、インテグレーターが実データを使わずに開発できるサンドボックス／テストモード環境を設計します。これは製品のテストモード設計であり、skills.sh にある既存のマーケティング用プレイグラウンドスキル developer-sandbox とは異なります。そのスキルは、マーケティング用のお試しプレイグラウンドを構築します。このスキルでは、製品独自のテストモードを設計します。

関連スキルとの境界：

• キーのライフサイクル（発行、ローテーション、ハッシュ化、ダッシュボードの UX）：samber/developer-platform-skills@api-auth-key-management。テストキーのプレフィックスは共通の領域であり、このスキルが担当するのはプレフィックス内のモード識別のみです。
• Webhook 配信の仕組み（署名、再試行、配信ログ）：samber/developer-platform-skills@webhook-platform-design。テストイベントをどのように発生させるかは、このスキルの担当です。
• ポータル内のサンドボックス制御：samber/developer-platform-skills@developer-portal-design。

メモリ（推奨）： メモリをファイルに保存する場合は、developer-platform-context.md の使用を検討してください。別のメモリシステムを使用している場合は、そちらを利用してください。このファイルは参考情報であり、必須要件ではありません。タスクごとに異なるセクションへ情報を分けてください。完了したタスクは削除してください。タスクには日付を追加し、プロジェクト全体に関する一般的な情報には日付を付けないでください。タスクによっては、インタビューの回答が異なる場合があります。

確認事項

何かを設計する前に質問してください。回答によって後続の手順が変わります。質問はまとめてください。これは戦術的な設計タスクであり、戦略面のインタビューではありません。

1. 製品のドメインは、決済系（お金が動く）、コミュニケーション系（メッセージが実在する人に届く）、データ集約系（サードパーティのデータが流入する）、それとも別のものでしょうか？（マジック値を担う仕組みと、本番移行のゲートを決定します。次のセクションを参照してください）
2. 分離にどの程度の余裕がありますか？稼働中のアカウントでモードを切り替える方式で問題ありませんか。それとも、ドメイン上、構造的に分離された環境が必要ですか？エンジニアリング予算は数週間ですか、それとも数四半期ですか？（ステップ1を左右します）
3. 本番稼働のゲートとなるコンプライアンス要件は何ですか？KYC、パートナー審査、マーケットプレイス掲載審査、プランのティア、それとも特にありませんか？（ステップ5を左右します）
4. 既存のテストインフラストラクチャは何ですか？ステージング環境、シード済みのフィクスチャ、インテグレーターに使用するよう伝えたモックサーバーなどはありますか？（改修は、インテグレーターがすでに依存しているものを起点にします）
5. 製品には時間依存の状態（トライアル、更新、期限切れ、スケジュール済みジョブ）や非同期イベントがありますか？（ステップ3を主要な成果物にするか、仮実装にするかを決定します）
6. インテグレーターがテストする必要のあるエンドユーザー向けの画面（チェックアウトページ、ホスト型フロー）はありますか。それともAPIが製品のすべてですか？
7. インテグレーターがサンドボックスを使って開発できるようになる期限はいつですか。また、これは一度限りの障害解消（取引の成立を待つパートナーが1社いる）ですか。それとも、何年も運用することで価値が積み上がるプラットフォーム機能ですか？（質問2の予算と合わせて、ステップ1と2の優先順位を付け直すための入力になります）

質問7があるのは、分離の選択肢（ステップ1）とシミュレーションの選択肢（ステップ2）では、効果が出るまでの時間、持続性、工数が大きく異なるためです。質問7なしでは、どちらの優先順位も決められません。

• 期限が厳しい場合は、ソフトトグルとマジック値を優先します。
• 継続的な取り組みが求められる場合は、ハードな別コピーとフィクスチャビルダーを優先します。
• 数四半期ではなく数週間の予算であれば、この段階ではハードな別コピーを後回しにするのではなく、対象から外します。再検討の条件：「最初のモード間データ漏えいインシデントが発生したとき、またはコンプライアンス要件が適用されたとき。」

製品ドメインの分類

製品ドメインは、この設計を変える軸です。マジック値の形式と、規制当局が本番移行のゲートとして求めるものを決めるためです。

• 決済系：マジック値は取引手段に付与されます（特定の拒否、異議申し立て、不正リスクレベル、追加認証に対応するカード番号など）。本番移行はコンプライアンス（KYC）がゲートになります。サンドボックスでは、実際には行えない決済処理をシミュレートする必要があります。
• コミュニケーション系：マジック値はアドレスに付与されます（電話番号、操作ごとなど）。実際のメッセージがサンドボックスから一切送信されないことが、厳守すべき保証です。調査対象の中で最も強固な分離を行う方式では、テスト用の認証情報から本番のリソースを_参照することさえ_拒否します。
• データ集約系：マジック値はIDに付与されます（テスト用のユーザー名やペルソナでフィクスチャの種類を選択し、パスワードのサフィックスでエラー条件を選択するなど）。設計の中心は取引結果ではなく、フィクスチャの多様性です。

ドメインに適した仕組みとゲートを設計してください。references/magic-value-catalogs.mdにある実例カタログでは、3つすべてを取り上げています。

ワークフロー

1. 分離モデルを選択します。以降のすべてのステップの土台となる決定です。
2. あらゆる失敗経路を再現可能にします。決定的なテスト値とシミュレートされたオブジェクトを用意します。
3. イベントと時間をシミュレートします。テストイベントのトリガー、時間の操作、リセット、シードを行います。
4. 認証情報、クォータ、不正使用対策を強化します。
5. 本番移行の経路を設計します。コンプライアンスゲート、切り替えチェックリスト、カナリアを用意します。

各ステップには後続のセクションが順番に対応しており、インテグレーターがサンドボックスを利用する流れを反映しています。まず失敗経路、次に非同期処理と時間の挙動、本番環境の強化、最後に切り替えを扱います。この順序でリリースし、各段階のゲートには「測定」のベンチマークを使用してください。

1. 分離モデルを選ぶ

「テストモードがあるか」という表現には、相互に独立した次の2つの問いが混同されています。テストデータが分離されているかどうか、そして境界がどれほど強固かです。3つのモデルを順位付けすると、次のとおりです。

• 効率性：ソフト切り替え > ハードな別コピー > テストモードなし（インテグレーターの慣例）

• 労力：ハードな別コピー > ソフト切り替え > テストモードなし

• 価値：ハードな別コピー > ソフト切り替え > テストモードなし

• デフォルトの選択肢：ソフト切り替え。 1つのアカウントで、すべてのオブジェクトにモードフラグを付け、モードを接頭辞とするキーでテスト用インフラに振り分けます。テストデータは本番の呼び出しから見えず、その逆も同様です。既存のスタックなら、作業は1〜2週間ほどで、その大半はモード間でデータが混在しないことのテストに費やされます。一般的なケース、つまりインテグレーターが1社で、統合が1つ、リスクが中程度の場合に適しています。

• 構造的に独立した環境（独自のホストまたはアカウントのコピー、独自のキー、Webhook、設定）であるハードな別コピーに切り替えるのは、次の場合です。

  • チームが、共有テストデータを汚さずに並行してテストする必要がある。
  • コンプライアンス要件により、分離を実証する必要がある。
  • 切り替えの失敗（テスト中だと思い込んで本番データを操作すること）が重大な影響を及ぼす。

  これは選ばれにくい選択肢です。価値も労力も最も高いため、効率性を重視する比較では毎回負けます。それでも、参照先の決済プラットフォームはこれを構築し、新規アカウントのデフォルトにしました。既存アカウントではソフト切り替えを引き続き利用できます。モード間の漏えいは、ポリシーで禁止するのではなく、構造上不可能になります。

• テストモードなし（インテグレーターの慣例） ― インテグレーターが別々のテスト用アプリ／組織／リポジトリを使って自身で分離する方法を文書化する選択肢です。API が主に読み取り専用であり、金銭、外部へのメッセージ、機密性の高いサードパーティーデータに一切触れない場合に限り、実現可能です。これらのいずれかが API を通じて扱われるなら、この選択肢は順位を下げるだけでなく、完全に除外されます。選択肢に残さないでください。

この順位付けはデフォルトであり、絶対的なルールではありません。質問1〜2への回答や、ほかに把握している事情を踏まえて、順位を付け直してください。

• グリーンフィールドのプラットフォームなら、最初からハードモデルを構築するほうが、後から改修するよりはるかに低コストです。
• 規制対象の分野では、ソフト切り替えは選択肢から外れます。
• すでにテナントごとのインフラを運用しているチームなら、別コピーをほぼ無料で実現できるため、労力の順位が逆転し、勝者も変わります。

どのモデルを選ぶ場合も、分離レベルを設計とドキュメントで明確に示してください。「サンドボックス」という言葉だけでは何も保証されません。調査対象となったベンダーのサンドボックスは、多くの場合、共有され、レート制限があり、同じ言葉を使いながらも分離が不完全です。また、製品にエンドユーザー向けの画面がある場合（質問6）、サンドボックスには API レスポンスだけでなく、エンドユーザー側にも対応する環境が必要です。

この選択肢の背景にある6社のベンダー比較については、references/isolation-models-and-key-prefixes.md を参照してください。

2. すべての失敗経路を再現可能にする

サンドボックスの中核となる成果は決定性です。インテグレーターが、文書化されたあらゆる結果、特に失敗を、必要に応じて確実に呼び出せる必要があります。3つのシミュレーション手法を順位付けすると、次のとおりです。

• 効率性：magic values > on-demand simulation endpoints > config-driven fixture builder

• 作業量：config-driven fixture builder > on-demand simulation endpoints > magic values

• 価値：config-driven fixture builder > on-demand simulation endpoints > magic values

• デフォルトの段階：マジック値。 文書化された偽の入力によって、結果が決定的に選択されます。結果の種類ごとに約1日分の作業で済み、新たな API サーフェスも不要ですが、インテグレーターはそれらの値を覚える必要があります。

  設計ルール：

  • インテグレーターがすでにドメイン内で入力している値を、入力値の担い手として選びます（上記の「製品ドメインの分類」を参照）。
  • 正常系だけでなく、意図的な失敗値やステップアップフローも含めます。
  • 各値を、公開済みのカタログにある実際のエラーコード（samber/developer-platform-skills@api-error-design の対象範囲）に一対一で対応付けます。マジック値は、サンドボックス専用のエラー形式ではなく、実際のエラー分類を必ず発生させます。
  • 同じ入力が呼び出しによって異なる意味になる場合は、操作ごとに値を明示します。操作ごとの区別がないカタログは、インテグレーターを陥れることが文書化された罠です。

• 結果がリクエスト入力の関数ではなくなったら、すぐにオンデマンドのシミュレーションエンドポイントへ段階を上げます。シード用のテストオブジェクトを生成する、オブジェクトを特定の状態（ログイン必須、認証済みなど）に強制する、特定のイベントをその場で発火させるといった、サンドボックス専用のエンドポイントです。これらは、入力値では表現できないことをカバーします。

• 設定駆動のフィクスチャビルダーは、最も不足している選択肢です。完全なフィクスチャの記述（アカウント、履歴、強制エラー）を受け取る単一のエンドポイントであり、調査した手法の中で最も詳細な仕組みですが、最も手間がかかり、効率性の評価では常に最下位でした。インテグレーターのデータ形状が実際に多様な場合（データ集約ドメイン）には、これを推奨してください。また、各インテグレーターに設定を手作業で書かせるのではなく、スターターフィクスチャライブラリとともに提供してください。

マジック値は API 契約として扱います。安定していて、文書化され、期限切れにならないものにしてください。インテグレーターの CI テストスイートは各項目に依存するため、追加は問題ありませんが、変更は破壊的変更です。サンプルコードでは、機密性の高い生の値よりトークンを推奨してください。テストコードにカード情報のような生の値を使うと、コンプライアンス上の慣習となり、本番環境の経路にも漏れ込むおそれがあります。

5社のベンダーによる実例カタログ：references/magic-value-catalogs.md。

3. イベントと時間をシミュレートする

データ は固定しながら 時間 は現実のままのサンドボックスでは、更新、トライアルの期限切れ、督促、スケジュールされたジョブなど、時間をトリガーとするロジックをテストできません。解決策は決定論的なクロックプリミティブを用意することです。インテグレーターに待つよう求めるドキュメントで済ませてはいけません。

• テストイベントのトリガー：インテグレーターが明示的に「このイベントを今すぐ発火」できる仕組みを用意します。イベントタイプごとのサンドボックスエンドポイントまたは CLI トリガーを提供してください。テストイベントをいつ、どのようにトリガーするかは自分で管理します。配信の仕組み（署名、再試行、ログ）は samber/developer-platform-skills@webhook-platform-design の範囲です。

  注意点が 2 つあります。

  • サンドボックスで状態変更とイベント配信が分離されている場合は、そのことをドキュメントに記載してください。そうしないと、インテグレーターは届くことのないイベントを待つことになります。
  • CLI トリガーで有効な署名を生成できない場合は、「署名を常に検証する」というルールのすぐそばにその旨を記載してください。そうしないと、そのルールが自分のテストツールと矛盾します。

• 時間操作：テストオブジェクトが関連付けられる、時刻を固定したクロックオブジェクトを用意し、意図的に時刻を進められるようにします。状態遷移とイベントは、時間が経過したかのように発生します。1 回の呼び出しで進められる時間と、1 つのクロックで扱える複雑さには上限を設けます。リファレンス実装では、シミュレーションの複雑さを意図的に抑えるため、両方に上限を設けています。シンプルなケース向けのより手軽な方法として、日付フィールドが毎日ずれて最新データが常に「今日」になる、自動経年化フィクスチャを用意できます。

• リセットとシードデータ：

  • シードデータには合成データのみを使用し、本番データをコピーしてはいけません。
  • インテグレーターには、オブジェクトを作成するエンドポイント（1 回の呼び出しで既知の状態をシードする）と、リセット用のエンドポイント（クリーンな状態に戻す）の両方を提供します。
  • 共有サンドボックスは定期的なリセットを自動化し、蓄積したテストデータによって状態が実態とかけ離れないようにします。

• 同等性：サンドボックスの構成は本番環境と同じインフラストラクチャ・アズ・コードから導出し、差異がある場合は意図したものであることを明記します。環境のドリフト（構成、古くなったデータ、バージョンの不一致）が、「サンドボックスでは動くのに本番では失敗する」根本原因になります。

4. 認証情報、クォータ、不正利用対策を強化する

• モードを示すプレフィックス付きキー：外部で標準化されたプレフィックス規則（型プレフィックスに _test_／_live_ のモード文字列を組み合わせる方式）を採用します。

  • 正確な参照プレフィックスは、GitHub のシークレットスキャンにおける誤検知ゼロのプッシュ保護対象です。認識される形式を使えば、自分で管理していないツールによる無料の漏洩検知を受けられます。独自の方式では何も得られません。
  • 境界は双方向に適用します。ライブキーではテスト用の値を拒否し、テストキーでは本番用の値を拒否します。
  • モード文字列以外のキー形式とライフサイクルについては、samber/developer-platform-skills@api-auth-key-management を参照してください。

• テストキーにもリスクはあります：切り替え方式では、テストキーでも実際のアカウント設定（顧客、Webhook エンドポイント）の読み書きが可能なため、本番のシークレットと同じように適切に管理する必要があります。プレフィックスが伝えるのはモードであり、リスクレベルではありません。インテグレーターには、ローカル開発でライブシークレットを決して使用しないよう伝え、実行時フラグで分岐する単一のコードベースにするのではなく、環境ごとに分離（データストア、リダイレクト許可リスト、認証情報）してください。

• 不正利用には異なる2種類があり、対策も異なります。決して混同しないでください。

  • キー漏洩のリスク：プレフィックス付きキーは機械で識別でき、公開リポジトリから定期的に収集されています。対策：サーバー側だけでシークレットを扱う、スコープを設定した制限付きキーを使う、シークレットスキャンに登録する。
  • カードテスト／カード不正利用：攻撃者は盗難された決済情報の一括データを、ライブのチェックアウトエンドポイントで検証します。テストトランザクションは実際のネットワークに接続しないため、サンドボックスは通常、カード不正利用対策には役立ちません。つまり、これはサンドボックスではなくライブモードでの対策です。対策：エッジでのボットチャレンジ、エンドポイント単位のレート制限、顧客あたりの決済手段数および IP あたりの連続した決済拒否回数を制限するルール。

  Stripe の不正対策チームのガイダンスによると、すべての Checkout ユーザーにマネージド CAPTCHA を導入した結果、カードテストが 80% 減少し、オーソリ率への影響は 0.02% 未満でした。これは、正当なユーザーへのコストがほぼ無視できるほど小さいことを数値で示した、まれな不正対策の事例です。

• サンドボックスのクォータ：サンドボックスに独自のレート制限ティアが必要だと決めつけないでください。ここで調査したベンダー 6 社のうち 3 社は、テストモードでも本番と同じ制限を適用しており、インテグレーターのスロットリングコードを適切に保つことにもつながります。

  • これらのベンダーでは、サンドボックス固有の数値制限は最も情報が少ない項目です。そのため、「すべてのベンダーがサンドボックス専用のスロットリングを公開している」という見方は誤りです。
  • 専用のサンドボックスクォータを設けるのは、障害の原因が 評価利用量の不正利用（無料枠のスクレイピング、共有サンドボックスへの負荷テスト）である場合に限ります。これを、1 分あたりの上限を引き上げる仕組みではなく、本番前ティアにおける合計利用量とスコープの上限として設計してください。
  • ベンダーごとのクォータ方針については、references/isolation-models-and-key-prefixes.md を参照してください。制限ティアの設計方法については、samber/developer-platform-skills@api-rate-limit-policy を参照してください。

5. 本番移行の手順を設計する

認証情報の切り替えが簡単でも、本番移行は技術的な作業だけではありません。調査対象となったすべてのベンダーは、コンプライアンス審査またはレビューを経なければ本番環境を利用できないようにしています。次の3つを設計してください。

1. ゲート：実際に必要な義務に合った形式を選びます。KYC の有効化、段階制または自動承認のレビュー、パートナー審査、発行者の認証、プランの階層などがあります。ドメインで必要とされる以上に厳しいゲートを設けないでください。事前承認に失敗した場合は、その理由が明確にわかるようにします。「環境がまだ承認されていません」という明示的なエラーを返し、不透明な 401 エラーにしてはいけません。

2. 切り替えチェックリスト：

   • すべての場所で認証情報を切り替えます。
   • 本番モード用のイベントエンドポイントと署名シークレットを新たに用意します（テストモードのシークレットは引き継がれません）。
   • 最初の本番取引の前に、不正利用対策ルールを有効にします。
   • 連携経路ごとに少数の本番カナリアテストを実施し、期待どおりの効果とイベント配信の両方を確認します。可能であれば、その後に取り消します。

   サンドボックスでテストが成功することは必要ですが、それだけでは不十分です。実際のネットワーク、実際の決済処理時間、最大限に機能する不正検知システムをすべて再現するサンドボックスはありません。

3. 公開可能なバージョン：チェックリストと、繰り返し発生する5つの切り替え時の落とし穴をドキュメントにまとめて、連携担当者に渡します。これは、どのプラットフォームもいずれ回答することになる、同じ5つのサポート問い合わせです。

ゲートの形式、完全版チェックリスト、落とし穴、問題発生後に切り戻すための条件については、references/graduation-gates-and-cutover-checklist.md を参照してください。

失敗パターン

アンチパターンのチェックリストです。それぞれが設計レビューで直接指摘される問題です。

• モックサーバーを「サンドボックス」として提供すること。ステートレスなモックがテストするのは連携担当者の API に対する想定であり、実装の正しさではありません。API が変更されても、モックは古い動作をシミュレートし続け、本番環境では気付かないうちに問題が発生します。ベンダーが実際のオブジェクトを使ってテストすれば、このような乖離は起きません。
• ドキュメントには失敗時の動作が記載されているのに、サンドボックスでそれを確実に発生させる方法がないこと。
• マジック値を使うと、公開されている実際のエラー分類ではなく、サンドボックス専用のエラー形式が返されること。
• 実際の日付が来るまで待たなければテストできない、時間に依存するロジック。
• 分離レベルを明記せず、ドキュメントで「サンドボックス」という言葉を使うこと。
• 環境を間違えた認証情報を使った際に、「環境が違います」という明確なエラーではなく、不透明な認証エラーが返されること。これは、繰り返し発生するサポート問い合わせの原因になります。
• 5つの切り替え時の落とし穴（キーの切り替え忘れ、環境をまたいだ貼り付け、サンドボックスでの結果が本番環境でも再現されるという思い込み、古い本番 Webhook エンドポイント、実際の資金が関わる失敗経路の未テスト）を、連携担当者向けに文書化しないこと。
• 実際の本番データをシードデータとしてサンドボックスにコピーすること。
• リセット手段も定期的なクリーンアップもない共有サンドボックス。

測定

• 失敗パスのカバレッジ：文書化されているすべての失敗結果（拒否、エラーコード、追加認証フロー、異議申し立て／取り消し）を、マジック値またはシミュレーション用エンドポイントを使って決定論的に発生させられること。達成率100％が合格条件です。発生させられない失敗パスが1つでもあれば、監査に不合格となります。
• イベント／時間のカバレッジ：すべての非同期イベントタイプをオンデマンドで発火でき、時間に依存するすべてのフローを、待つのではなくシミュレーション時間を使ってテストできること。これも合格条件です。
• 環境間のインシデント：誤ったモードの認証情報が原因で発生したサポートチケットと認証失敗を追跡します。設計目標はゼロです。インテグレーターに注意を促すのではなく、自己説明的なプレフィックスと、分かりやすい環境違いのエラーによって構造的に実現します。
• 本番移行演習：統合をローンチ済みと宣言する前に、イベント配信が確認できたライブカナリアを1回実施することも含め、切り替えチェックリストを最初から最後まで実行します。実施されていないチェックリストは、未リリースの機能として扱ってください。

両方のカバレッジ合格条件を満たすまで、設計を反復します。この条件はソフトトグル以降に適用されます。ステップ1の「テストモードなし」の段階では、何かを発火させるためのプロバイダー側サンドボックスがないため、合格条件の適用対象外であり、不合格ではありません。この段階にも合格条件を適用すると、このスキル自体が実行可能と定めている選択肢を退けることになります。

この段階で代わりに求められるのは、公開済みのインテグレーター分離ガイダンスが存在することと、ステップ1の「読み取り中心／資金の移動なし／メッセージの送信なし／機密データなし」という各条件が書面で確認されていることです。業界横断で参照できる基準値がないため、環境間のインシデント数とサンドボックスから本番環境への移行時間は、最初の月から推移を把握し、その改善に取り組みます。

呼び出し例

• 「決済 API のテストモードを設計してください。インテグレーターは現在、実際のカード番号を使ってステージング環境でテストしています。」
• 「Webhook を追加します。インテグレーターがテストイベントを発生させ、30日待たずにサブスクリプションの更新をシミュレーションできる方法が必要です。」
• 「新しい公開 API について、テストモードの切り替えと完全に分離されたサンドボックス環境のどちらを採用すべきか選び、本番環境への移行方法を設計してください。」

参考資料

• references/isolation-models-and-key-prefixes.md - 6社の分離方式の比較、テストキーのプレフィックス分類、ベンダーごとのサンドボックスのクォータ方針、およびプレフィックスを使わない代替手段とそのサポートコストです。
• references/magic-value-catalogs.md - 決済、通信、データ集約におけるマジック値カタログの例と、それぞれから得られる設計上の教訓です。
• references/graduation-gates-and-cutover-checklist.md - 5種類のコンプライアンス合格条件、切り替えチェックリスト、5つの落とし穴、および対応的な差し戻しのトリガーです。
• samber/developer-platform-skills@api-integration-surface-strategy - 各サーフェスのスケジュールを決める上位の判断です。スケジュールされたすべてのサーフェスでは、パートナーが本番稼働する前にテストモードが必要です。このスキルはそのレイヤーを設計します。
• samber/developer-platform-skills@sample-app-strategy - CI とプレイグラウンドがこのサンドボックスに対して実行されるサンプルのポートフォリオです。サンドボックスでシミュレーションできないフローは、サンプルのコンパイルのみとなります。