クロスプラットフォームJSチーム向けアプリケーションインフラストラクチャの解説

あなたは、きれいなCapacitorアプリをリリースした。Reactスクリーンは安定し、Electronデスクトップビルドは正常に動作し、早期の採用は急上昇している。すると最初の重大なインシデントが訪れる。問題はコンポーネントcodeにない。ユーザーは古いJavaScriptバンドルをロードしている、Electronのアップデートが一部のインストールで動作しない、またはApp Storeのレビュープロセスで待たされている重要な修正が待っているのである。

その時点で、チームはコードベースがリリースされたアプリケーションの全体的な構造の一部であることを発見する。 アプリケーションインフラストラクチャ どのビルドがユーザーに届くか、クライアントが変更を受け取る方法、データが保存される場所、エラーが検出される方法、チームがインシデントを悪化させずに回復できるかどうかなど、モバイル配布の規模により、運用上重要な決定が必要です。Apple App Storeは2026年に2.42百万アプリと304,000のゲームをホストしていました 2.42百万アプリ2.3百万アプリ Business of AppsのApp StoreマーケットプレイスデータによるとクロスプラットフォームのJavaScriptチームにとって、難しいのはウェブ__CAPGO_KEEP_0__、ネイティブシェル、ストア、ランタイムの更新、バックエンドサービスとの境界です。この インフラストラクチャ計画ガイド.

実際の問題は、codeまたはElectronプロジェクトでそれらの部分がどのように接続するかです。この図は定義から始まり、レイヤー、設計、リリースメカニズム、ライブアップデート、スタックに対するオーディットに進みます。 目次 なぜアプリケーションインフラストラクチャがCapacitorよりも重要か

context

• Why App Infrastructure Matters More Than the Code
  • 実際の製品はインストールされたコピー
• アプリケーションインフラストラクチャとは実際に何を意味するか
  • クロスプラットフォームチームが見るのはシーム
• モダンアプリスタックの基本コンポーネント
• アーキテクチャパターンとそのトレードオフ
  • ネイティブシェルパターンが優位な理由
• CapacitorとElectronアプリのスタックの構築
  • ソースから署名済みアーティファクトまで
  • ストアリリースと実行時リリースを分離
  • データはUIタイミングとは独立
• ライブアップデートプラットフォームの位置づけ
  • ライブアップデートが置き換えるものとは何
• チームを後で苦しめる一般的な誤解
• 自社のスタックを検証するための実用的なチェックリスト
  • 構築と配信
  • 更新と実行時互換性
  • サービスとデータ
  • 観測性、セキュリティ、復旧

アプリケーションインフラストラクチャはCodeよりも重要な理由

ローカルビルドはすべてのテストを通過しても、リリース後に失敗する可能性があります。署名ミスはインストールをブロックする可能性があります。間違ったチャネルでは、互換性のないJavaScriptバンドルを配信する可能性があります。ネイティブプラグインでは、異なるインターフェイスを想定する可能性があります。キャッシュでは、古いアセットを提供する可能性があります。ユーザーは、1つのメッセージを表示します。「アプリケーションは破損しています」、リポジトリは健康ですように見えます。

クロスプラットフォームのJavaScriptアプリケーションでは、インフラストラクチャは インストールされたアプリケーションの全体的な配信システム。コミットから署名されたアーティファクトに接続し、各ユーザーにどのリリースを提供するかを選択し、実行中のクライアントをサポートし、エンジニアに変更を観察、停止、または逆転させる方法を提供します。Cloudflareはそのシステムの1つのレイヤーだけです。

インストールされたコピーは実際の製品です

ユーザーはGitブランチを実行しません。代わりに、以下の特定の組み合わせを実行します。

• ネイティブシェル: iOS、Android、macOS、またはWindowsコンテナ、コンパイル済みプラグインを含む。
• JavaScriptバンドル: WebアセットをCapacitorまたはElectronランタイムが読み込むもの。
• 構成: 環境変数、機能フラグ、APIエンドポイント、およびリリースチャンネル割り当て。
• リモート依存関係: API、認証プロバイダー、データベース、オブジェクトストレージ、第三者SDK。
• ローカル状態: キャッシュデータ、クレデンシャル、キューイングされた書き込み、およびオフラインレコード。

それらは契約を形成します。JavaScriptの変更は1つのネイティブシェルと共に動作し、別のシェルでは失敗する可能性があります。バックエンドのマイグレーションは新しいクライアントをサポートするかもしれませんが、古いインストールされたコピーを破壊する可能性もあります。Electronパッケージは有効であるかもしれませんが、更新パスは一部のユーザーがアプリを起動できないようにする可能性もあります。したがって、完了したビルドは、実行可能なアーティファクトが生成されたことを証明するのみであり、目的のユーザーが受け取ったかどうか、実行できたかどうかは証明しません。

実践ルール: リリース前に回復設計を行う。チームは影響を受けるバージョンを特定し、チャンネルを停止し、知られている良好なバンドルを復元できるようにする必要があります。ライブアップデートサービスとしてCapgoは、JavaScriptの修正が互換性のあるインストールに到達するまでの時間をどのように変えるかは変えますが、ネイティブの互換性、署名、またはストアの制約を削除することはありません。

アプリストアは、特にネイティブバイナリの場合、リリースパスの形を決定し続けています。 ビジネスアプリのアプリストアの概要, explains why one release-control error can spread widely. A platform such as インフラストラクチャ計画ガイド helps map the handoffs between build artifacts, runtime updates, stores, and supporting services. The useful question is not whether the code works in isolation, but whether this entire chain can deliver, observe, and recover the installed app.

アプリインフラストラクチャの実際の意味

An app can pass its tests and still fail users at delivery, startup, update, or recovery. アプリはテストを通過しても、配信、起動、更新、または回復の際にユーザーに失敗する可能性があります。 It determines which code reaches users, how that code changes, where application data is maintained, which dependencies are available, and how the team finds and repairs failures.

バックエンドインフラストラクチャは通常、サーバー、API、キュー、データベース、ネットワーキング、そしてアクセス制御を説明します。アプリインフラストラクチャには、システムが含まれ、インストールされたクライアントとその配布チャネルに拡張されます。Capacitorプロジェクトでは、ネイティブバイナリ、パッケージされたWebディレクトリ、アップデーター、ストアリスト、リモートサービスは、1つの運用図に属します。Electronプロジェクトでは、デスクトップパッケージとそのアップデートパスがチェーンに追加されます。

アプリケーションcodeは、関係をより見やすくする建物です。インフラストラクチャは、配線、給水、換気、ドア、警報、そしてメンテナンスアクセスです。良い家具は、電気系統が故障したり、修理を妨げるドアがロックされたりすることは補償できません。

クロスプラットフォームチームが見るシームズの理由

クロスプラットフォームのJavaScriptアプリには、複数の配布パスがあります。1つの共有Webバンドルは、異なるメカニズムを通じて次のパスを辿ります。

• iOSとAndroidストア 署名されたネイティブパッケージを配布し、プラットフォームポリシーを強制します。
• Electronチャネル インストーラー、署名されたパッケージ、デスクトップオートアップデートシステムを使用します。
• ランタイム配布 JavaScript、HTML、CSS、そしてアセットを置き換えることができますが、ネイティブシェルを置き換える必要はありません。プラットフォームの規則とチームのセキュリティ制御に従います。
• バックエンドデプロイ すべての互換性のあるクライアントの動作を変更します。チームが再構築できなくなったバージョンも含まれます。

各パスには独自の障害モードがあります。ストア配布はネイティブの修正を遅らせることができます。デスクトップの更新はパーミッションまたはダウンロードの中断により失敗する可能性があります。ランタイムの更新は古いプラグインと競合する可能性があります。バックエンドの変更は長期間オフラインだったクライアントを破壊する可能性があります。

「アプリケーションがデプロイされている」という表現は、さまざまな状態を表すことができます。バイナリはストアに存在するかもしれません。バンドルはチャネルに割り当てられているかもしれません。APIは実行中のプロダクション環境にありますが、ユーザーのインストールされたコピーは古いまままたはローカルデータの移行ができません。インフラストラクチャは、リリースを制御し、結果を観察し、パスが失敗したときに復元できるように、さまざまな状態を接続します。ライブアップデートプラットフォームであるCapgoは、互換性のあるインストール用にJavaScriptのリリースパスを短縮できますが、ネイティブの互換性、署名、ストアの制約は依然として適用されます。

モダンアプリケーションスタックの基本コンポーネント

実用的なスタックには 9つの関連する層がありますただし、チームは同じサービスでいくつかの層を実装することもできます。各層の役割を定義する前に、製品を選択することは、責任の欠如を隠すことになります。

1. ビルドとCI/CD ソースcodeを再現可能なアーティファクトに変換します。依存関係をインストールし、テストを実行し、JavaScriptをバンドルし、ネイティブシェルをコンパイルし、パッケージを署名し、リリースのために使用された精確な入力を記録します。信頼できる デプロイメントの自動化フロー すべてのターゲットプラットフォームで同じステップを繰り返すようにする。

2. リリースと更新の配信 アーティファクトがユーザーに届く方法を決定する。 提出、企業向け配布、サイドローディング、デスクトップインストーラー、実行時バンドル配信など、各コントロールは異なる。 リリース層にはバージョニング、ターゲットアウディエンス、承認、必須と任意の更新の明確な区別が必要です。

3. 実行時更新戦略 バイナリを置き換えることなく変更できるものを決定する。 JavaScript バンドルはしばしばネイティブ code から独立して置き換えられるが、更新されたバンドルはまだインストールされたシェルで利用可能なネイティブ API とプラグイン契約と一致する必要があります。

4. バックエンドサービス HTTP エンドポイント、認証、ビジネス ルール、ウェブフック、統合を提供する。 クライアントはこれらのサービスをバージョン管理された依存関係として扱う必要があります。 フロントエンドとは無視できない拡張機能として扱うのではなく。

5. データ同期 ローカル パERSISTENCE、オフライン ワーク、キュー化された書き込み、紛争解決、ステート プロパガシオンを処理する。 ノートアプリケーションと支払いフローは両方とも API を使用できますが、同期保証と修復手順は大きく異なります。

6. 観察性 クラッシュ レポート、ログ、パフォーマンス テレメトリ、リリース マーカー、ユーザー ディアギスティクスを組み合わせる。 ログだけでは例外が発生したことを示すかもしれませんが、観察性は例外をデバイス、アプリケーション バージョン、バンドル、リクエスト、ロールアウト グループと関連付けます。

7. セキュリティと法的合致 セキュリティ、アイデンティティ、データ、パッケージの更新、プラットフォームのパーミッションを保護します。 また、codeのハードニング、依存関係のレビュー、保持ポリシー、地域要件、診断システムにおける敏感情報の取り扱いもカバーしています。

8. ロールバックと修復 チームにロールアウトを停止する、前のバンドルを復元する、悪い構成を無効にする、損傷したローカル状態を移行する、または安全なバイナリリリースにユーザーを誘導する方法を与えます。ロールバックは、削除されたデプロイと同じではありません。オフラインまたは部分的に更新されたクライアントを考慮する必要があります。

9. インフラストラクチャホスティング サービスを実行するために必要なコンピュート、ストレージ、ネットワーキング、キュー、コンテンツ配信など、Webアプリケーションをサポートするサービスを実行します。ホスティング層は重要ですが、上記のクライアントリリース制御を置き換えるものではありません。

これらのレイヤーは相互に作用し、チェックリストとして動作するのではなく、ビルドパイプラインはバンドルを作成し、リリースシステムはチャンネルに割り当て、実行時はチェックし、バックエンドは互換性のあるデータを提供し、オブザーブリティは変更が成功したかどうかを確認します。1つのレイヤーにギャップがあれば、他のレイヤーを信頼することが難しくなります。

アーキテクチャパターンとそのトレードオフ

アーキテクチャの決定は、実際に配信されたアプリケーションの形状を比較することで明らかになります。チームは、codeをほとんど一緒に保つ、特徴ごとに分割する、ネイティブシェル内にパッケージする、またはリモートで制御されるサービスに機能を移すなど、さまざまな方法でアーキテクチャを実装できます。

The 単一のJavaScriptモノリシック は理解しやすい。1つのリポジトリから1つの主なバンドルが生成され、開発者は機能を画面からAPI呼び出しまで追跡できます。コストは、小さな変更が広範なリリースを強制したり、起動時間が増加したり、無関係なチームが同じcodeパスで衝突したりするときに現れます。

モジュラー モノリシック は、機能をパッケージまたはドメインに分離しながら、展開を簡素化します。所有権とテストを改善することができますが、境界は慣習でなければなりません。ビルドシステムがそれらを強制する場合に限ります。チームはまだ、共有ランタイムと共有リリースを調整する必要があります。 ネイティブシェルパターンが優位な理由

__CAPGO_KEEP_0__とElectronは、ネイティブシェルプラスJavaScriptバンドルのパターンを実用化します。シェルはプラットフォーム統合、権限、ファイルシステムアクセス、通知、ネイティブプラグインを提供します。JavaScript層は共有インターフェイスと製品ロジックの多くを提供します。その分離は、UIと互換性のあるロジックがネイティブ機能よりも速く進む有用なリリース境界を創出します。

Capacitor and Electron both make the Native shell pattern __CAPGO_KEEP_0__

__CAPGO_KEEP_1__

モバイルアプリの技術アーキテクチャについてのより広範な議論 モバイルアプリの技術アーキテクチャ モノリシックが良し、サービスが悪しという選択肢ではありません。どの障害モードをチームが運用できるかという質問です。

完全に分離された設計では、チームが独立してリリースできるようになりますが、リモート依存関係ごとにバージョン交渉、障害処理、観察性の作業が必要になります。運用の成熟度が柔軟性を正当化するときにのみ使用してください。ただし、配布速度だけが魅力的であると感じるだけではありません。 モノリシックとマイクロサービスアーキテクチャの比較 境界と所有権の観点からではなく、ファッションの観点からではなく、決定をフレームすることができます。

CapacitorとElectronアプリのスタックの構築

コミットからユーザー端末までの変更を追跡することができます。パスは、静的アーキテクチャ図が隠す責任を明らかにします。特に、同じJavaScriptcodeがモバイルシェルとデスクトップランタイムをサポートする場合です。

ソースから署名済みアーティファクトまで

CIジョブでは、ロックされた依存関係をインストールし、ユニットテストと統合テストを実行し、Vite、Webpack、または別のビルドツールと組み合わせてJavaScriptをバンドルします。Capacitorは、XcodeまたはGradleがプラットフォームアーティファクトを作成する前に、ウェブ出力をネイティブプロジェクトにコピーします。Electronは、デスクトップのターゲットに対応するインストーラーに、メインプロセスとレンダラーのバンドルをパッケージします。

ビルドパイプラインに署名は含まれるべきであり、開発者のチェックリストではありません。iOSおよびmacOSのビルドでは、Appleの署名識別子とプロビジョニングコントロールを使用します。Electronの配布では、プラットフォームに適した署名と信頼できる更新パスが必要です。コミット、依存関係セット、ネイティブシェルバージョン、バンドルバージョン、署名結果を含むメタデータを保存してください。

アーティファクトリポジトリは、ラベルが付いたBOXのように振舞います。署名済みパッケージと実行時バンドルを不可変バージョン識別子で保存してください。リリースシステムは、環境ごとに再構築するのではなく、知られているアーティファクトをプロモートできます。

実行時リリースとストアリリースを分離する

Capacitorの場合、バイナリ内に含まれるウェブディレクトリは、初期実行時サーフェイスです。ElectronのレンダラーBundleは似た役割を果たします。署名済みパッケージ内にそのBundleを保持するか、起動後に互換性のある置き換えを検索する制御された実行時更新メカニズムを追加してください。

リリースタイプには異なる影響があります:

• バイナリリリース: ネイティブプラグイン、パーミッション、エンタイトルメント、埋め込まれたフレームワーク、またはプラットフォーム構成を変更します。通常は、関連するストアまたはインストーラプロセスに従います。
• JavaScriptリリース: 互換性のあるウェブcode、スタイル、コピー、構成、資産を変更します。プラットフォームポリシーとチームのセキュリティモデルが許可する場合、別の配信パスで取り扱うことができます。
• バックエンドリリース: すべての接続可能クライアントのサーバー動作を変更します。互換性と移行計画は古いアプリバージョンを考慮する必要があります。

Electronの自動更新ライブラリは、新しい署名済みデスクトップパッケージを配信できますが、それはバイナリワークフローが残っています。Capacitorチームは、ネイティブの変更と共に、ストアのサブミッションを実行可能なbundleの配信と組み合わせることができます。実用的な クロスプラットフォーム開発のための実用的な ガイドも、共有層とプラットフォーム固有の責任の境界を明確にするのに役立ちます。

データはUIのタイミングから独立させる

APIゲートウェイは、認証、ルーティング、レート制御、サービス境界を一元化できます。デバイス上では、SQLiteは構造化オフラインデータとトランザクションワークフローに適しており、IndexedDBはブラウザのようなローカルストレージに適しています。ライブラリは答えに何が起こるかという質問よりも重要です: 同じレコードがローカルとリモートでどのように変更されるか?

オフライン書き込みを有効にする前に、紛争ルールを定義する必要があります。キューは1つの操作で安全にリトライし、別の操作では財務的なアクションを複製することができます。 pendding、accepted、rejected、reconciledの状態を説明するメタデータを保存し、それらの状態をサポートと診断に公開する

__CAPGO_KEEP_0__のための繰り返し continuous integration setup for Capacitor ライブアップデートプラットフォームの位置づけ

Where Live Update Platforms Fit In

A live-update platform sits between the build pipeline and the application runtime. The CI job creates a JavaScript bundle, assigns it to a release channel, and uploads it. The installed app checks that channel at runtime, downloads a signed compatible bundle, verifies it, and applies it according to the update policy. A phased rollout then limits exposure while telemetry shows whether the change behaves as expected.

The release calculus changes because a compatible JavaScript fix doesn’t necessarily need to wait for a full store resubmission. That can matter when a team needs to correct a UI regression, update copy, adjust a configuration value, or repair web-layer logic. A channel model also lets teams separate development, staging, beta, production, or customer-specific audiences without creating a different native binary for every group.

Capgo is one option in this layer. It provides signed JavaScript, CSS, copy, configuration, and asset bundles for CapacitorJS and Electron apps, with channel targeting, CI/CD integrations, differential delivery, per-device logs, adoption and failure metrics, version history, and rollback protection. Teams can assess those capabilities alongside self-hosted update servers, Electron auto-update tooling, or a store-only process. A broader comparison of available approaches appears in this guide to live update tools for Capacitor apps.

ライブアップデートは置き換えられない

ランタイム配信はネイティブリリースパスを置き換えるものではない。ネイティブのcode、権限、特権、埋め込まれたSDK、プラットフォームの動作を変更した場合でも、ストアへの提出と署名が必要です。ストアポリシーに従い、配信するコンテンツのセキュリティレビューも実行する必要があります。

互換性の境界は明確でなければなりません。新しいネイティブプラグインAPIで構築されたバンドルは、プラグインを含まないシェルに安全にターゲットすることはできません。ネイティブキャパシティーマニフェスト、最小シェルバージョン、ステージドチャンネル、フォールバックバンドルを使用して、高速配信メカニズムが互換性のない配信の高速な方法になるのを防ぎます。

ライブアップデートは有効なcodeのパスを短縮しますが、リリースの統治の必要性を排除するものではありません。

したがって、ライブアップデートが「App Storeワークフローより優れている」かどうかという質問ではなく、どの変更がどのパスに属するかを尋ねるべきです。プラットフォームのキャパシティ変更を署名バイナリに保管し、コントロールされたランタイムチャネルを通して互換性のあるウェブ層の変更を実行します。どちらのパスも逆行可能にするために、観察性とロールバックを使用します。

ライブアップデートの誤解

ミスコンセプション1、ストアへの提出は仕事を終了する そうではない。ストアはパッケージを配信できるが、チームは起動失敗の監視、API互換性の監視、更新の採用、ローカルマイグレーション、サポートレポートの監視が必要です。Capacitorアプリはレビューを通過しても、古いアセットをロードしたり、ネイティブプラグインが予期せぬペイロードを受け取った場合に失敗する可能性があります。

第2の神話、OTA更新はすべてのレビューを回避します。 ランタイム配信は、有効なJavaScriptの変更に対して、フルストアの再提出を回避するかもしれませんが、プラットフォームポリシー、セキュリティ、互換性の義務は消えません。アプリの基本目的を変更したり、承認されていない機能を追加したり、安全でない動作を導入したりするbundleは依然として非合法性や信頼性の問題を引き起こす可能性があります。

第3の神話、ログは観察可能性と同じです。 エラーの単一の行は、問題の原因となるリリースを特定したり、ユーザーが受信したかどうかを判断したり、失敗が1つのプラットフォームに限定されているかどうかを判断したり、ロールバックが成功したかどうかを判断したりするのに十分ではありません。観察可能性はログ、クラッシュ、パフォーマンス、リリースメタデータ、ユーザー コンテキストを組み合わせた決定システムです。ギャップは一般的です。2026年の調査では 組織の85％は観察可能性を使用していましたが、46％は統合されたインフラストラクチャとアプリケーション観察可能性を生産環境で実行していました。TierPointのデジタルインフラストラクチャのトレンドレポートによると 第4の神話、JavaScriptは自動的にネイティブより安全です。.

JavaScriptはcodeキーを露出させたり、トークンを適切に扱わなかったり、診断情報を通じて個人情報を漏洩させたり、未検証のbundleに依存したりする可能性があります。ランタイムの選択は攻撃面を変えるだけで、署名されたアーティファクト、シークレットの管理、依存関係のレビュー、最小限の特権、慎重なデータハンドリングの必要性は変わりません。 JavaScript can expose API keys, mishandle tokens, leak personal data through diagnostics, or trust an unverified bundle. The runtime choice changes the attack surface, not the need for signed artifacts, secret management, dependency review, least privilege, and careful data handling.

アプリケーションスタックを自社で検証するための実用的なチェックリスト

A Practical Checklist to Audit Your Own Stack

実際のCapacitorまたはElectronプロジェクトに対してこのオーディットを実行してください。yesまたはnoの答えを出し、各yesに対して証拠としてのアーティファクト、ダッシュボード、ポリシー、またはランブックを記録してください。

ビルドと配信

• 再現性のあるビルド: CIがコミットとロックされた依存関係セットからリリースを再現できるか?
• 署名管理: プラットフォーム署名資格情報は保護されており、監査可能なパイプラインを通じて使用されているか?
• アーティファクトの特性: 各バイナリとJavaScriptバンドルはソースリビジョンとネイティブシェルバージョンに接続できるか?
• リリースのプロモーション: テスト済みアーティファクトをプロモートするのではなく、再構築するのではなく、プロダクションデプロイはどのように行われるか?

アップデートと実行時互換性

• チャンネル所有権: アップデートチャネルごとに所有者、対象者、プロモーションルールが存在するか?
• 互換性境界: アプリが利用できないネイティブ機能を必要とするバンドルを拒否できるか?
• ロールバック速度: 1時間以内にストアリリースなしでJavaScriptバンドルをロールバックできるか?
• バイナリーフォールバック: ランタイムアップデートが失敗したり、デバイスがオフラインになった場合にアプリが安全なパスを持つか?

サービスとデータ

• API互換性: ロールアウト中でも古いインストール済みクライアントがバックエンドを使用できるか?
• オフライン時の動作: アプリがキュー化された、失敗した、同期された変更を説明するか?
• 対処方法: オフライン書き込みワークフローごとに、merge と rejection のルールが定義されているか?
• マイグレーション修復: サポートは、ユーザーに無謀に再インストールを求めることなく、ローカル状態を回復できるか?

観測性、セキュリティ、回復

• リリース可視性: クラッシュとログを、バイナリ、バンドル、プラットフォーム、チャンネルでフィルタリングできるか?
• ユーザー診断: サポートは、不要な個人データを収集することなく、影響を受けたインストールを特定できるか?
• シークレット保護: クライアント バンドルと診断出力から、クレデンシャルが除外されているか?
• インシデント再現: チームは、配信停止、ロールバック、そして破損したリリースのコミュニケーションを実践しているか?

メンタルモデルは単純です: アーティファクトをビルドし、そのルートを制御し、その行動を観察し、修復パスを開けておく.

CapgoはCapacitorJSとElectronチーム向けのライブアップデート層を提供し、CIアップロードと署名されたバンドル、ターゲットチャネル、実行時配信、ロールアウトの可視性、ロールバックコントロールを接続します。アプリケーションインフラストラクチャを検証し、完全なバイナリーフローの外で互換性のあるJavaScriptリリースを管理する具体的な方法を探している場合は、 Capgo コンテキスト: HTMLテキストフラグメント (親キー `submitting_a_pr_to_capgo`)。ページ/エリア: Capgoマーケティングウェブサイト。役割: ウェブサイトコピー文句。見られる場所: page contributing.astro。Capgo製品/ブランドと開発者用語を完全に保持する。