機能を完成させました。プルリクエストはきれいです。QAは良さそうと言っています。でも、全員に一度に配信したくないのです。
その気分は、通常、Reactアプリが単純なデプロイから成長した最初の兆候です。製品が実際のユーザーに届くようになると、リリースは技術的イベントだけではなくなります。リスクの判断になります。新しい検索UIが壊れたり、チェックアウトバリエーションがユーザーを混乱させたり、モバイルビルドがcodeを実行した場合、すぐに戻すことができません。そうなら、もっと必要です。 if (process.env.NODE_ENV) そして、希望があります。
それが始まるのは Reactの機能フラグ start to matter. Not as a cute boolean in a component, but as a release control layer that lets you ship code separately from exposing it. In web apps, that means safer rollouts. In bundled apps like Capacitor or Electron, it matters even more because rollback speed is limited by store review, install lag, and slower release cycles.
Table of Contents
- モダンなReactアプリの機能フラグの重要性
- Reactアプリの機能フラグの設計
- ロールアウトとロールバック戦略の実装
- テスト観測性とフラグの負債管理
- フラグの保護とCI/CDの自動化
- Beyond the Web Feature Flags for Capacitor and Mobile Apps
モダンなReactアプリのために機能フラグは不可欠
金曜日の午後、新しい請求書のUIはすでにデプロイされており、サポートはリリースチェックリストを開いており、1つのエンタープライズクライアントは月曜まで古いフローを使用する必要があります。Webアプリではすでに緊張感があります。デスクトップインストーラーやモバイルストアを通じて配布されるバンドルされたReactアプリでは、ロールバックが数分ではなく数時間か日かかるため、状況はさらに悪化します。
Feature flags give React teams control over that moment. They let you ship the code, keep it dormant, and decide later which users should see it. That changes release work from an all-or-nothing event into a controlled operation.
デプロイとリリースは異なる作業です
デプロイは「codeが生産環境にありますか?」という答えをします。リリースは「この行動を実行できるユーザーは誰ですか?」という答えをします。
実稼働アプリが実際のトラフィック、複数の環境、収益、パーミッション、ナビゲーションをタッチする機能を持つ場合、その区別は重要になります。 チームは、早期にマージし、内部コホートでテストし、機能がすべてのユーザーに適していると信頼できるまで、徐々にアクセス範囲を拡大できます。 Capacitor アプリ、Electron アプリ、ストアでレビューされたモバイル ビルドなどのリリースが遅いプラットフォームでは、その制御はすでにユーザーの手元にあるバイナリを待たずに機能がすべてのユーザーに適していると信頼できるまで、機能をリリースすることができるため、さらに価値があります。
フラグは、常に起こる 3 つの状況で役立ちます:
- 制御されたロールアウト: 小さなグループに新しいパスを公開する
- 実験: 別々のデプロイを維持せずにバリアントを比較する
- 急いでシャットダウン: リスクのある機能を新しいビルドを待たずに無効にする
生産性の問題が逆算が高価になる場合、生産性の問題が逆算が高価になる場合、code をフラグで保護してください。
フラグの UI 条件に止まるチームは新しいフラグの UI 条件に止まるチームは多いです。 flag ? <NewUI /> : <OldUI /> フラグの UI 条件は、ユーザーに表示される部分ですが、実際の価値はオペレーショナルです。リモート構成、決定論的ターゲット、機能を急いで無効にする能力が、実稼働環境でフラグが役立つのは、リモート構成、決定論的ターゲット、機能を急いで無効にする能力です。 React アプリがアプリ全体の実行時設定も必要な場合、Capacitor アプリ用のリモート構成 プラグインを使用します。 リリース管理モデルに合う。
フラグは信頼されていない場合、役に立たなくなる。
フロントエンドコードベースで成長を見ると、同じ失敗パターンが見られる。チームはフラグを迅速に追加し、環境間で名前がずれ、フォールバック値は設定ミスを隠し、誰も「オン」がグローバルにオン、スタッフ用にオン、またはステージングでオンのみを意味するか分からなくなり、フラグシステムはリスクを生み出すのではなくリスクを軽減するのではなくリスクを生み出すようになる。
型安全性は役に立つが、問題の全てを解決するものではない。チームは明確なレジストリ、所有権、フラグを評価するための一貫した方法が必要で、それ以外では、Reactコンポーネントはロールアウト状態についてローカルな仮定を持ち、ロールアウトや部分的なロールバック中にそれらの仮定が破綻する。
違いは簡単にわかる。
| 用途 | 弱いバージョン | 強いバージョン |
|---|---|---|
| UI切替 | コンポーネントのローカルなブール値 | 所有権とロールアウトルールを持つリモートフラグ |
| リリース安全性 | 手動デプロイロールバック | リモート設定を通じて即時無効化 |
| 実験 | アドホックブランチ比較 | 安定したコホート割り当てと測定可能な露出 |
重要な考え方のシフトは単純です。Reactの機能フラグはリリースプロセスに属するものであり、JSXだけに属するものではありません。そうして、ビルドの新しいバージョンを遅く出荷するアプリでは、特に、生産が混乱したときに、爆発半径を減らすために、唯一のツールとなるのです。
Reactアプリの機能フラグのアーキテクチャ
アーキテクチャの決定は最初のフラグよりも重要です。ランダムなコンポーネントにフラグを直接接続すると、重複したロジック、ロードフリッカー、コードベースで誰も信頼できるソースを知らない状態が生じます。
ランタイムプロバイダーを使用して、散在した条件分岐を避けましょう
Reactアプリの場合、信頼できるアプローチはフラグを ランタイムデータとして扱うことです。Reactのフラグ付けに関するガイドラインでは、3つのことを推奨しています:サーバーまたはローカルSDKキャッシュでフラグを評価すること、コホート割り当てを決定論的に保存すること、そして、ユーザーが最初に間違ったデフォルトを表示しないように、ハイドレーションまたは反対のフリッカー保護を使用して、最終的なUI状態をレンダリングすることReact フラグ メソッド).
code の場所が変わる。アプリのルート近くにフラグのロードを配置する。消費を簡単にする。葉のコンポーネント内でフラグを取得するのを避ける。
実用的な形は次のようになります。
- メインの木がレンダリングされる前にフラグをロードまたはハイドレートする。
- プロバイダーを通じて公開する。
- 1 つのフックまたは 1 つのラッパーペターを通じて読み取る。
- プレゼンテーショナル コンポーネントから評価ロジックを外す。
アプリ全体の設定やフラグのためのリモート コンフィグ レイヤーが必要な場合は、 Capacitor リモート コンフィグ プラグイン は、ハイブリッド React アプリで自然にこのパターンと組み合わせることができます。
React Context とカスタム フックを使用したパターン 1
このパターンは、一般的に推奨するデフォルトです。明確でテストしやすく、後でベンダーを切り替える場合に簡単に移行できるからです。
import React, { createContext, useContext, useMemo } from 'react';
type FlagValue = boolean | 'control' | 'variant-a' | 'variant-b';
type Flags = {
newCheckout: boolean;
checkoutExperiment: FlagValue;
deleteTaskEnabled: boolean;
};
const defaultFlags: Flags = {
newCheckout: false,
checkoutExperiment: 'control',
deleteTaskEnabled: false,
};
const FeatureFlagContext = createContext<Flags>(defaultFlags);
export function FeatureFlagProvider({
flags,
children,
}: {
flags: Flags;
children: React.ReactNode;
}) {
const value = useMemo(() => flags, [flags]);
return (
<FeatureFlagContext.Provider value={value}>
{children}
</FeatureFlagContext.Provider>
);
}
export function useFeatureFlag<K extends keyof Flags>(key: K): Flags[K] {
return useContext(FeatureFlagContext)[key];
}使用は面白くない、そしてそれはあなたが望むことです:
function DeleteTaskButton() {
const enabled = useFeatureFlag('deleteTaskEnabled');
if (!enabled) return null;
return <button>Delete task</button>;
}このパターンは、コンポーネントが最終的な答えを求めるだけであるため、うまく機能します。コンポーネントは、答えがどのように計算されたかは気にしません。
2 番目のパターンは、より高階のコンポーネントを使用します。
A より高階のコンポーネント は、ルート要素、またはレガシークラスコンポーネントをすべての場所でハック呼び出しを追加せずにゲートする場合に便利です。
import React from 'react';
import { useFeatureFlag } from './FeatureFlagProvider';
export function withFeatureFlag<P>(
flagKey: 'newCheckout' | 'deleteTaskEnabled',
Fallback?: React.ComponentType<P>
) {
return function wrap(Component: React.ComponentType<P>) {
return function FeatureFlaggedComponent(props: P) {
const enabled = useFeatureFlag(flagKey);
if (!enabled) {
return Fallback ? <Fallback {...props} /> : null;
}
return <Component {...props} />;
};
};
}使用方法:
const CheckoutPage = () => <div>New checkout</div>;
const LegacyCheckoutPage = () => <div>Legacy checkout</div>;
export default withFeatureFlag('newCheckout', LegacyCheckoutPage)(CheckoutPage);欠点は、間接性です。モダンな React では、ハックはトレースが簡単ですが、HOC は DevTools でコンポーネントツリーを汚染する可能性があります。ただし、ルートレベルゲーティングの場合、綺麗です。
コンポーネントはロールアウトポリシーを決定するのを許可しないでください。コンポーネントはフラグ結果を消費するだけで、バケット化、ユーザーターゲティング、キャッシュリフレッシュルールを実装する必要はありません。
React の機能フラグパターンを比較する
| 基準 | コンテキスト + ハック | 高階コンポーネント (HOC) |
|---|---|---|
| 最も適切な使用例 | コンポーネントレベルの決定とバリアント | フルページ、ルート、またはレガシーコンポーネントをwrapする |
| 柔軟性 | 高 | 中 |
| 開発者エクスペリエンス | モダン関数コンポーネントでは強い | フックが不便な場合に役立つ |
| バンドル明確性 | 明確なインポートと直接的な読み取り | 木構造の抽象化 |
| テスト | プロバイダーを通じて簡単にモックできます | ラッピングされた統合ケース用にラッパーが必要な場合にのみ、HOCを追加してください |
| 長期的なメンテナンス | 通常は良いでしょう | sparingly使用する場合に限り、問題ありません |
Reactの機能フラグを実装する場合に初めての方は、最初は コンテキスト+フック特定のラッパー型ゲーティングの必要性がある場合にのみ、HOCを追加してください
ロールアウトとロールバック戦略の実装
機能がリリース後に不調になると、UIは新しいボタンや画面を表示するだけかもしれませんが、決定するべきことは誰が最初にそれを見るか、露出の速度がどれくらい成長するか、そして待って再デプロイするのを待たずに停止することができるかということです。そうは言っても、Reactアプリがモバイルまたはデスクトップのパッケージ内に配布されている場合、ロールバックはリモート設定に依存することが多く、App Storeのレビューまたはデスクトップ配布には時間がかかるため、もっと重要です。
パーセンテージロールアウトには、固定割り当てが必要です。
パーセンテージロールアウトは割り当てが安定している場合にのみ機能します。同じユーザーが1回の訪問で新しいチェックアウトを受け取り、次の訪問で古いチェックアウトを受け取ると、サポートは問題を再現できず、分析は雑音が混じり、ユーザーは信頼を失います。
解決策は簡単です。安定した識別子とフラグキーを加えた決定論的ハッシュでユーザーをバケット化してください。ユーザーIDは通常、適切な入力です。匿名セッションでは、インストールIDまたはデバイスIDを使用できます。必要に応じて。 Math.random() ブラウザ内では、ユーザーを予測不能に再割り当てるため、間違ったツールです。
実用的ロールアウトパスは次のようになります。
- 内部ユーザーとQAから始めます。
- 小さなコホートにリリースします。
- エラー率、変換影響、サポートチケットの確認後、意図的に段階的に拡大します。
- フラグの全生涯で割り当てを固定してください。
最後の点は、簡単に過小評価されることがあります。スティッキーコホートは、実験のみに使われるものではありません。インシデント対応を速めるため、エンジニアはすぐに基本的な質問に答えることができます:どのユーザーが影響を受けたか?
実験を実行する場合は、サイズを事前に調整してください。Optimizelyからサンプルサイズ計算ツールを使用すると、トラフィックボリューム、ベースライン変換、最小検出可能効果が必要なユーザー数を変化させることがわかります。Optimizely サンプルサイズ計算機チェックがなければ、チームはノイズを信号と見なし、機能を早すぎる段階で推進することがよくあります。
ブラウザ外の段階的な更新のための便利な参照は Capacitor ライブ更新のフェーズド ロールアウトパッケージ化されたシェル内で実行する React アプリにも、バイナリロールバックが遅い場合に同じリリース規則が適用されます。
ターゲットリリースは、爆発半径を減らすことができます。
ユーザーをロックする可能性のある請求フロー、承認プロンプト、データ移行など、特定の機能はランダムなパーセンテージから始めるべきではありません。
ターゲット リリースは、最初のアウディエンスが知られている特性で定義されている場合に機能します:
- 内部スタッフのドッグフード
- 粗いエッジに同意したベータテスター
- 特定のアカウント階層
- 法律または言語要件が異なる地域
- 機能を安全にサポートするデバイスまたはアプリのバージョン
リングベースのリリースにより、ターゲットをより実行可能にします。リング0は従業員です。リング1は信頼できる外部テスターです。後続のリングは信頼性が向上するにつれて露出を拡大します。この構造は、リスクが明らかに不均等である場合に、すべてのユーザーを1つのプールとして扱う一般的な間違いを回避するのに役立ちます。
このリリースモデルとよく相性の良い埋め込みウォークスルーはこちらです。
リスクのある機能には、機能フロー全体を無効にするトップレベルの運用フラグが必要です。プレゼンテーショナルフラグは、背景の要求、効果、ナビゲーションパスの実行が続きながら、単にエントリポイントを非表示にするだけです。
リリース前にキルSwitchを設計する:
起動時早期に評価する。
- 最後の安全な値をキャッシュする。
- フラグサービスが利用できない場合の安全なデフォルト値を選択する。
- 機能を無効にすることで、サイドエフェクトが止まるようにする。
- インシデントの際にフラグを切り替えることができるユーザーをドキュメントする。
- Webアプリのみの場合、リリースリスクを減らすことができます。モバイルとデスクトップのReactアプリの場合、軽微なインシデントとユーザーが修正されたビルドを待つことの差が生まれます。__CAPGO_KEEP_0__がすでにバンドルに含まれている場合、リモートフラグはロールバック戦略の一部になります。リリース戦略のものだけではありません。
code
テスト観測性とフラグ負債の管理
機能フラグの簡単な部分は、1つを追加することです。費用の高い部分は、多くのフラグが存在し、誰もそのうちどれがまだ重要であるかを覚えていないときに始まります。
各フラグは、信頼する状態の数を倍増させます。
マーティン・フラワーの警告はまだ有効です:機能フラグが存在する場合、チームは両方の オン オフ 状態を検証する必要があります。複数のフラグがある場合、可能な状態の組み合わせは組合せ的に増加し、バグのリスクを高めます。 マーティン・フラワーによる機能トグルに関する話これは、Reactアプリケーションに直接影響を与える: 条件付きレンダリングパスは迅速に拡散します。).
Conditional rendering paths spread quickly:
- Martin Fowler on feature toggles __CAPGO_KEEP_0__
- 複数のbranchが1つのページに存在する場合、誰も気づく前に問題が発生する可能性があります。 評価のタイミングが間違っていると、クライアントとサーバー間で意見が異なる可能性があります。
- snapshotテストだけでは、実際の問題を把握することが難しくなります。 ハッピーパスラッパーをテストするだけでは、実際の問題を把握することが難しくなります。
実際のテストスタックは以下のようになります。
- 評価ロジックの単体テストを行ってください。
- flagged branchのコンポーネントテストを行ってください。
- リスクのあるパスのみを対象にしたエンドツーエンドのカバレッジを追加してください。
- デフォルトのフォールバックを明示的に検証してください。
すべての組み合わせをテストするのではなく、ユーザーに害を及ぼす可能性のある状態やレイアウトを破壊する可能性のある状態をテストしてください。
flagの負債は実際に存在し、静かに高額のコストを生み出します。
古い旗はcodeの腐敗の形をとります。 それらは条件分岐、コメント、ダッシュボード、そしてランブックに残ります。 その後、誰かが「一時的な」ブランチを数ヶ月後に編集することになりますが、誰もそれを削除していません。
実践で機能するクリーンアップルールは簡単です:
| 問題 | 何をするか |
|---|---|
| 所有者がいない | 旗が作成されたときにチームまたは人を割り当てる |
| 終了状態がない | 旗が削除されるか、保持されるか、または設定に変換されるかを決定する |
| 旗が制御するのは多すぎる | 旗を小さく、狭い旗に分割する |
| 旗の背後にあるコアロジックが隠されている | ビジネスロジックをレンダリング条件分岐から外す |
クリーンアップルール： 最初の日には、フラグには所有者、目的、削除計画が必要です。
チームは「信頼」問題に陥ることもあります。フラグ名は存在しますが、フォールバックが間違っています。ダッシュボードエントリは変更されましたが、アプリタイプは変更されていません。code パスは死んでいるが、まだアクセス可能です。そのため、タイプ生成とレジストリ検証は、大規模システムでは、初期実装が単純に見えていても重要です。
観察性は、フラグが機能したか、ただ存在したかを教えてくれます。
ロールアウトは、フラグが完全に露出したときに完了するのではなく、チームが何が起こったかを知るまで完了する。
少なくともこれらの質問を追跡すること:
- 露出: どのユーザーがどのバリアントを視認したか?
- エラー: フラグされたパスがクライアントサイドのエラーを引き起こしたか?
- 採用: ユーザーが公開された機能を使用したか?
- ロールバック信号: どの閾値でオフにするか?
フラグプラットフォームがその質問に答えなければならない場合、リリースレビュー中でも推測することになる。
CI/CDを利用したフラグの保護と自動化
悪いデプロイは明らかだ。フラグの変更は、デプロイと同じレビューのパスを通らなくても、生産的な動作を変更するため、より静かに、そして危険である場合もある。codeのパスが実行されるかどうか、ユーザーが受け取るものが変わるなど、デプロイアクセスと同じ規制が必要だ。
フラグの変更を生産的な変更と同じように扱う
フラグはリリースの制御である。チームが生産環境でフラグを切り替えられる場合、そのチームはユーザーが受け取るもの、実行されるcodeパス、そして時々は発火する統合を変更できる。デプロイアクセスと同じ規制が必要だ。
最小限の制御は簡単だ。
- ロールベースのアクセス制御: 生産フラグの変更を制限し、読み取りアクセスと編集アクセスを分離する。
- 監査ログ: 変更者、変更時刻、変更した環境を明確に記録してください。
- 環境隔離: ステージング、プレビュー、生産用のフラグは区別してください。テスト変更が実稼働トラフィックに影響しないようにしてください。
- サーバー側のチェックは、敏感な決定には使わないでください。 クライアントフラグはUIを隠すことができますが、請求アクセス、特典、認証には使わないでください。
フラグダッシュボードを共有スプレッドシートのように扱うのはよくありません。製品は顧客に機能を有効にします。サポートは不満を止めるために機能を無効にします。エンジニアは機能が変更されていないと想定します。デプロイがなかったからです。その設定は、インシデントを説明する必要があるまで機能します。
バンドルアプリはリスクを高めます。Webアプリでは、codeの修正が迅速に配信できます。Capacitorまたはデスクトップアプリでは、codeの破損がすでにデバイスに置かれ、リモートフラグが機能を暴露するまで待っています。codeのReactモバイルアプリを開発するチームは、承認ルールを厳しくする必要があります。ロールバックは、機能を無効にする代わりにバイナリを置き換えることができないからです。 React mobile apps with Capacitor フラグが外部に存在する場合、信頼性が低くなります。同様のワークフローで機能を配信するプロセスの中で管理するのが安全なパターンです。
通常は、次のことを意味します:
__CAPGO_KEEP_0__
__CAPGO_KEEP_1__
- 機能codeのPRでフラグを生成または更新する
- CIでリモートレジストリと比較して型付きフラグ定義を検証する
- 環境ごとにデフォルト値を意図的に設定する
- 必要なフラグが欠落または不正設定の場合、リリースをブロックする
- 期限切れまたはロールアウト終了状態のフラグのクリーンアップタスクをスケジュールする
生産停止の原因となる可能性のあるフラグが原因となる生産停止の場合、CIはリリース前にセットアップを検出できるようにする必要がある。 これには、欠落したデフォルト値、キー名の変更、古い環境マッピング、codeに存在するがコントロールプレーンに存在しないフラグが含まれる。
パイプライン構造のスターティングポイントが必要な場合 Git Action CI/CD ワークフロー ビルドチェック、デプロイゲート、フラグ検証のための拡張可能な自動ステップのためのビルドチェック、デプロイゲート、自動ステップのためのGit Action CI/CDワークフローの参考
シークレットとSDKの選択肢を面白くする
フラグのセキュリティを過度に複雑にするフロントエンドチームは、明らかな部分を無視する傾向がある。 公開されたクライアントサイドSDKキーは、ブラウザ用に設計されている場合、通常問題ない。 管理用トークン、書き込みクレデンシャル、環境管理用キーは、CIまたはバックエンドサービスのみに属する。 それらは、ローカルJavaScriptに任せるべきではない。
実用的には単純である。 表示変更や低リスクの実験の場合、クライアントサイド評価を使用する。 プライシング、パーミッション、敏感なフローのキルスイッチ、ローカルJavaScriptに任せられないものは、サーバーサイド評価を使用する。
スローページング環境では、リリースの速度が遅い場合に限り、境界はより重要になります。ウェブチームは、迅速なデプロイで回復できます。モバイルとデスクトップチームは、フラグシステムを回復メカニズムとして使用する必要があることがよくあります。プロダクションフラグを間違った人々が編集できる場合、またはCIがフラグ契約を検証しない場合、ロールバックはすぐに混乱してしまいます。
Web Feature Flags for Capacitor とモバイル アプリ
ほとんどの React の機能フラグに関する記事は、即座に再デプロイできるウェブアプリを前提としています。 その仮定は、React code が Electron、 Capacitor, Electron, または別のバンドル実行環境内に存在する場合にすぐに破棄されます。
バンドル アプリはリリースの計算を変える
ハイブリッド アプリでは、ユーザーがすぐに更新しない限り、JavaScript、CSS、アセット、設定を含むパッケージをユーザーに配布します。機能はすでにデバイス上に存在する場合があります。 その場合、フラグの役割は完全に変わります。
ハイブリッド リリース ストリームに関する最近の議論では、React フラグに関する既存のコンテンツが Capacitor または Electron アプリのリリースリスク モデルを十分に捉えていないことを指摘しました。 そのチームにとって、主なニーズは、フラグ、ターゲット チャネル、ロールバック保護を組み合わせたリリース オーケストレーション レイヤーです。特に、ストア レビューの遅延を回避することが重要な場合 (ハイブリッド アプリ リリースリスク ディスカッション).
正解です。バンドル アプリでは、フラグは条件付きレンダリングよりも すでに配布された機能の遠隔アクティベーション.
モバイルまたはデスクトップのReactアプリでは、フラグはUIの表示よりもリリースタイミングを制御することが多い。
This is also why channel-based distribution matters. If you’re building hybrid apps and need the app shell plus web code release model to make sense together, creating React mobile apps with Capacitor フラグは、更新配信と組み合わせると最も効果的である。
モバイルとデスクトップのチームにとって、フラグだけではすべてのリリース問題を解決することはできない。フラグは__CAPGO_KEEP_0__パスを非表示または有効にすることができるが、既にバンドルにバグが含まれている場合に修正されたアセットやロジックを配信することはできない。
For mobile and desktop teams, flags alone won’t solve every release problem. They can hide or enable code paths, but they can’t replace shipping fixed assets or logic when the bug is already in the bundle.
__CAPGO_KEEP_0__更新を、プラットフォームが許可する場合にフルストアサイクル外で配信することである。
- deliver code updates outside full store cycles when your platform allows it,
- フラグを使用して、有効化、ロールバック、ステージドエクスポージャーを制御することである。
- ライブアップデートとフラグを組み合わせると、ハイドブリッドチームはWebスタイルのリリース制御に近いものを得ることができる。 これは、より一つのレバーしかない状況で何かが間違っている場合に、より多くのレバーを提供するだけである。
チームが__CAPGO_KEEP_0__またはElectronアプリを配信し、リリース制御層が必要な場合、
Capacitor Capgo サインされたWebバンドルをターゲットチャンネルに配信し、ロールバック保護と観察性をサポートし、機能フラグとライブ更新が互換性を持つハイブリッドアプリのワークフローに適合するため、__CAPGO_KEEP_0__は一つのオプションです。
React機能フラグ: 完全な実装ガイド
あなたが React機能フラグ: 完全な実装ガイド を使用してチャンネルルーティングとステージドロールアウトを計画する場合、 チャンネル に接続してください。チャンネルの実装詳細については、 チャンネル を参照してください。チャンネルの実装詳細については、 チャンネル を参照してください。チャンネルの実装詳細については、 ベータテスト ソリューション __CAPGO_KEEP_0__ バージョン ターゲット ソリューション __CAPGO_KEEP_1__
