チームのアプリはリリースされているが、リリースごとに重さが増している。月曜日にホットフィックスを出した直後、同じビジネスルールが3つのビューコントローラー、1つのストア、そして誰も信頼しなくなったヘルパーにコピーされていたため、サポートが2つの無関係な画面で奇妙な挙動を報告し始めた。通常、チームリードがモバイルアプリアーキテクチャをcode的な議論として捉えるのをやめ、コスト、速度、復旧を形作るデリバリーシステムとして認識し始める瞬間である。
市場規模だけでも、この変化を無視することはできない。2023年のグローバルモバイルアプリ市場の規模は 2,528.9億米ドル そして、〜に達すると予測されています 2030年までに6,263.9億米ドル年平均成長率（CAGR）は CAGR 14.3% 2024年から2030年にかけてであり、そのためアーキテクチャの選択は非常に大規模で高コストなライフサイクルの中に位置します（分析のインサイト）。適切に実装されたパターンで開発時間を 35% 削減し、メンテナンスコストを 40% アプリのライフサイクル全体で削減できるなら、コードベースの構造も単なる開発者の好みではなく、予算の意思決定でもあります（分析のインサイト).
だからこそ、正しいメンタルモデルが重要です。アプリを巨大な画面の寄せ集めではなく、レイヤー、境界、リリースパスとして捉えられるようになれば、プロダクト、財務、サポート、コンプライアンスに対してトレードオフを説明しやすくなります。
目次
- モバイルアプリのアーキテクチャがビジネス上の意思決定である理由
- モダンなモバイルアプリに共通する3つのレイヤー
- MVC、MVVM、Flux、Clean、Hexagonalの選び方
- スタック全体における状態管理とデータ管理
- オフライン動作と同期をアーキテクチャのファーストクラスとして扱う
- セキュリティ、コンプライアンス、Live Update デリバリー
- パフォーマンス、スケーラビリティ、チームベロシティの両立
- エンタープライズモバイルチーム向けの推奨パターン
モバイルアプリのアーキテクチャがビジネス上の意思決定である理由
中規模のプロダクトチームが金曜の午後にホットフィックスを出します。目の前のバグは消えますが、別の3つの画面がエラーを起こし始めます。価格ルールが、ボタンの描画、バリデーション、API の呼び出しを担う同じ View Controller 内にあったためです。サポートはチケットのトリアージを始め、エンジニアはレイヤーをまたいでログを比較し、リリースマネージャーはロールバックでオフラインの下書きが壊れないか確認しなければなりません。
こうしたインシデントは、コードベースのせいで影響範囲が必要以上に広がるため、コストがかさみます。ビジネスロジックがエントリーポイントのコンポーネント内にあると、すべての変更が賭けになり、バグの切り分けも難しくなります。優れた モバイルアプリケーションアーキテクチャは、 画面の責務をビジネスルールやデータアクセスから分離することで、その影響範囲を抑えます。だからこそ、アーキテクチャは機能デリバリーと同じくらい、インシデントからの復旧にも影響するのです。
デリバリーの経済性こそが議論の核心
本当に価値のある議論は「どのパターンが美しいか」ではなく、「この構造が毎月、重複した作業、リグレッションリスク、メンテナンスコストとしてどれだけの負担をかけるか」です。この視点を持つことが重要なのは、アプリが今や主要なソフトウェア資産であり、境界が曖昧なコストはエンジニアリング内に留まらないからです。それはサポート時間、リリース遅延、そしてチームが同じ問題を何度も解きほぐすうちにずれていくロードマップとして現れます。
GoogleのAndroidガイドラインでは、少なくとも2つのレイヤー、すなわち UIレイヤー と データレイヤー、およびそれらの間に任意の ドメインレイヤー を推奨しています。また、自己完結型コンポーネント、一方向データフロー、エントリポイントコンポーネントからの状態分離（Androidアーキテクチャのガイドライン）を強調しています。これは、業界がアクティビティ中心のcodeから、保守性とチーム規模に対応した構造へと移行したことを示す明確な兆候です。
ステークホルダーに説明する実用的な方法は、美しさではなく「デリバリーの経済性」について話すことです。境界が明確であれば、無関係な5つの画面を触らずに1つの機能をリリースしやすくなり、緊急修正やリグレッション調査に費やす時間が減ります。また、live update チャンネルがデリバリーモデルの一部である場合、アーキテクチャはチームのリリース処理にも影響します。境界が小さければ、迅速にパッチを適用できるものと、フルネイティブリリースが必要なものを判断しやすくなるためです。
有効な経験則はシンプルです。アーキテクチャがすべてのリリースをテストしやすく、ローカライズしやすく、ロールバックしやすくするなら、それは十分に元が取れています。新機能のたびに「このロジックはどこに置くべきか？」を一から議論する羽目になるなら、チームは技術的負債の隠れた利息を払っているのです。
だからこそ、モバイルアーキテクチャに関する議論は、しばしば モノリスとマイクロサービスの考え方のトレードオフに似たものになります。同じ考え方は、アプリ内部、CI/CD、インシデント復旧にも現れます。最初は大きな境界の方がシンプルに感じられますが、通常はリスクが同じ場所に集中しがちです。一方、境界を小さく分けることで、エンタープライズチームは作業の割り振り、アップデートの配信、問題発生時の復旧において、より柔軟に対応できます。
モダンなモバイルアプリに共通する3つのレイヤー
リリースは単純な理由で失敗することがあります。画面は正常に見え、API も応答しているのに、プレゼンテーション、ビジネスルール、ストレージの責務が同じ場所で混在しているためにバグが発生する、といったケースです。だからこそ、モバイルアプリケーションアーキテクチャは「スタイルの議論」ではなく「デリバリーの経済性」に関する意思決定として扱うべきです。code の構造は、live update チャネルとネイティブリリースが連携する必要があるとき、チームがどれだけ迅速にリリース、パッチ適用、復旧を行えるかに影響します。
有用なモデルは、アプリを次の3つのレイヤーに分けることです。 UIレイヤーこの ドメインレイヤー、および データレイヤー。 UIレイヤー はユーザーが見る部分です。 ドメインレイヤー はアプリが何をすべきかを決めます。 データレイヤー ストレージ、API、その他の外部システムと通信します。
レストランの比喩は、具体的であれば依然として役立ちます。ダイニングルームは料理を提示し、キッチンはその組み立て方を決定し、パントリーとサプライヤーが食材と在庫を提供します。アプリでは、UIは状態を提示し、ドメインはビジネス判断を行い、データレイヤーはストレージ、リモート呼び出し、調整を処理すべきです。これらの役割が曖昧になると、タップ1つでリトライポリシー、キャッシュルール、同期動作の決定が始まり、codeを変更する際に副作用なしで対応するのが難しくなります。
専門用語に惑わされないUI・ドメイン・データ
この UIレイヤー 画面に表示されるもの、つまりローディングインジケーター、フォームエラー、現在のビューなどを管理します。データを要求し、結果をレンダリングするだけです。ビジネスルールを計算したり、データの取得方法を決定したりすべきではありません。
この ドメインレイヤー 画面と外部世界の間に位置します。アプリのビジネスロジック、例えばバリデーションルール、ワークフローの判断、iPhone、Android、またはCapacitor内のwebviewで実行される場合でも同じであるべき変換などが含まれます。
この データレイヤー fetch、永続化、リコンシリエーションを担当します。リポジトリやAPIクライアントは通常この層に置かれます。クロスプラットフォームプロジェクトでは、この層がネイティブと共有の関心事の交わる場所になり、各画面がデータの出どころを意識する必要はありません。この分離についての実践的なまとめは、以下でも紹介されています： Capgoによるハイブリッドモバイルアプリケーションの概要.
実践的なルール： 画面をレンダリングせずにビジネスルールをテストできないなら、そのルールは間違ったレイヤーにあります。
単一方向データフローが実際にもたらすもの
単方向データフローは、実際にバグが起きるまで抽象的でピンとこない。ユーザーが操作し、UIがイベントを発行し、ドメインがそれを処理し、データレイヤーが取得や保存を行い、レスポンスが同じ経路を通って戻ってくる。これによりチームが追う方向は1つになり、障害対応のときに効いてきます。経路が少なければ、stateがずれる場所も少なくなるからです。
混乱はたいてい「state（状態）」という言葉から始まります。一時的なUI状態、セッション状態、キャッシュデータ、永続化されたレコードは、それぞれ挙動が異なります。ローディングスピナーはオフラインキューと同じ場所に置くべきではありませんし、ビジネス上の判断が行われる場所にも置くべきではありません。明確に分離することで、実体のないUI更新や古いデータがコンポーネント全体に広がるのを防げます。
前述のとおり、 Androidアーキテクチャのガイドライン ネイティブの文脈で同じ中核的な分離を説明しています。この考え方はエンタープライズのモバイルチームにもそのまま当てはまります。アプリには依然として、ユーザーインタラクション、ビジネスルール、データアクセスのための場所が必要だからです。デリバリーモデルは変わっても、レイヤー分割の問題は変わりません。
状態（State）は、チームが一文で説明できる場所に置くべきです。もし説明に3つのレイヤーとスクリーンショットが必要なら、その境界は間違っている可能性が高いです。
同様の境界の問題は、リリース計画でも出てきます。変更がデータレイヤーだけに触れるなら、チームは live update チャネル経由でパッチを当てられるかもしれません。ネイティブ依存関係やセキュリティ上重要なフローを変更するなら、完全なネイティブリリースの方が安全です。その違いは、 アプリの決済方法がブロックされる問題の修正 アプリの決済方法がブロックされる問題の修正に関するセクションが、code の構造と同じアーキテクチャの議論に含まれる理由の1つです。デリバリーの制約が、各レイヤーが安全に変更を吸収できる範囲を決めるからです。
MVC、MVVM、Flux、Clean、Hexagonalの選び方
チームリードがこの決断に直面するのは、通常、デリバリーが苦しくなってきたときです。画面は頻繁に変更され、バグの追跡には時間がかかるようになり、リリースの経路ももはや一直線ではありません。その瞬間、アーキテクチャはスタイルの議論ではなく、リリースを遅らせず、復旧を困難にすることなく、チームがどの程度の変化を吸収できるかという問いに変わります。
これらのパターンはトーナメントのライバルではありません。それぞれが異なる配信課題を解決します。小規模なアプリは調整コストが低いため、軽量な構造でも健全に保てます。エンタープライズアプリは通常、より強い分離が必要です。コードベースやチーム数、リリースのプレッシャーが増えるほど、共有ロジックに触れるコストが上がるからです。
これが最も短く、正直な要約です。
| パターン | コアアイデア | 最適な用途 | 主なトレードオフ |
|---|---|---|---|
| MVC | Model、View、Controllerの責務を分離する | 小規模アプリ、素早い立ち上げ、シンプルなチーム | Controllerはすぐに肥大化しがち |
| MVVM | ロジックが重いViewではなく、ViewModelにUIをバインドする | テスト可能なUIワークフロー、リアクティブなインターフェース | 抽象化とセットアップの増加 |
| Flux | 一方向のアクションで状態変更を予測可能に | イベント中心のアプリ、複雑なインタラクション | ボイラープレートと状態オーケストレーションのオーバーヘッド |
| クリーン | ビジネスルールを内部に集約し、依存関係を分離 | 長期的なライフサイクルを持つエンタープライズアプリ | レイヤーと規律の増加 |
| Hexagonal | コアロジックをプラットフォームアダプターから独立させる | プラットフォームの頻繁な変化や複数のエントリーポイントにさらされるアプリ | 境界を厳密に保つ規律が求められる |
真のボトルネックを解消するパターンを選ぶ
MVCは、純粋さよりもスピードが重視され、コントローラーが肥大化しない程度にアプリが小さいうちは適しています。動く製品にたどり着く最短ルートであり、多くのチームがここからスタートします。リスクは後になって顕在化します。ビューのロジック、リクエスト処理、ビジネス上の判断が同じクラスに詰め込まれ、あらゆる変更がリスクに感じられるようになった時です。
MVVMは、画面をビジネスルールから切り離しつつ、UIに予測可能なバインディングとテスト容易性が必要な場合に適しています。プレゼンテーション層に明確なコントラクトを与えるため、デザイナーと開発者が同じフローを反復改善する際に役立ちます。トレードオフは構造が増えることで、その構造を維持するには、ビューモデルを新たな「何でも詰め込む場所」にせず、境界をクリーンに保とうとするチームの意識が必要です。
Fluxは、イベント、アクション、状態遷移を明示的に保つ必要がある場合、特にユーザー主導の更新が多いアプリではより適した選択肢です。制御されたメッセージ経路のように機能し、各変更が既知のパスを通るため、結果を追跡しやすくなります。どの画面が何を変更したかを推測するのではなく、アクションの連鎖を辿れるので、インシデントからの復旧もシンプルになります。
Clean ArchitectureとHexagonal Architectureがエンタープライズで選ばれるのは、ビジネスコアを保護すべきものとして扱うからです。Clean Architectureは依存関係を内側に向け、Hexagonal Architectureはアダプターを介してアプリケーションコアをプラットフォームの詳細から分離します。SDKの変更、新しい配信チャネル、複数チームが同じロジックに触れる状況をアプリが乗り越える必要があるとき、これは重要です。リリースシステムとcodeの構造が相互依存し始めるからです。
選定の決め手となる要素
決定打となるのは、パターンの図解ではありません。チーム構成、経験、リリースのプレッシャーの方がはるかに重要です。頻繁にリリースする小規模チームはより軽量なパターンで済みますが、複数のリリーストレインを抱える大規模組織では、チーム間の衝突を減らし、ロールバックを考えやすくする構造が必要です。
また、アーキテクチャはデリバリーのコスト構造にも影響します。変更がプレゼンテーションアダプターやデータアダプター内に完全に収まるなら、チームはlive updateチャネルでリリースできるでしょう。同じ変更がネイティブ依存関係、決済フロー、セキュリティに敏感なcodeに触れる場合は、適切なレビューとリカバリ手順を伴うフルネイティブリリースが安全です。これと同じ理由で、 アプリの決済方法がブロックされる問題の修正 アーキテクチャの議論に含めるべきです。リリース制約が、どのレイヤーが変更を吸収でき、どのレイヤーができないかを決めるからです。
データ安全性も同じ議論の一部です。パターンによって機密レコード、トークン、ローカルキャッシュがUIに近すぎる場所に置かれるなら、チームは後でデバッグやコンプライアンス対応でツケを払うことになります。その境界の実用的な参考例は Capacitor アプリにおける SQLite の暗号化です。永続データをどこに置くべきか、そのどこまでをプレゼンテーション層に公開すべきかという問いにも自然にフィットします。
最も妥当な選択は、チームが説明・テスト・進化させられ、スプリントごとに同じ設計議論を蒸し返さずに済むものです。ホワイトボードに境界を描き、リリースリスクの所在に合意できるなら、そのパターンはおそらく役割を果たしています。
スタック全体における状態管理とデータ管理
状態とデータフローは、2つの別々の問題ではなく、1つのアーキテクチャ上の問題として扱うべきです。UIが一部の状態を持ち、ストアが別の状態を持ち、ネットワークインターセプターが裏で認証トークンを変更していると、アプリの動作を把握するのがすぐに難しくなります。
基本的な分割から始めましょう。 一時的なUI状態 はビュー層に属します。選択中のタブやフォームの展開状態などです。 セッション状態と機能状態 はビューモデルやストアに属します。 永続データ リポジトリの背後に置き、ソースがローカルストレージかリモートサービスか、あるいはその両方かをアプリが判断できるようにします。
クロスプラットフォームチームがついズレるポイント
クロスプラットフォームチームは、画面ごとに永続化や認証ロジックを分散させて時間を節約しようとすることがあります。これにより、各画面がデータの有効性やリフレッシュの仕組みについて独自の前提を持つようになり、気づきにくいバグが発生します。クロスプラットフォームでの推奨構成はよりクリーンで、共有ドメイン層、プラットフォーム対応のプレゼンテーション層、標準化されたデータ層、そしてデバイス固有の作業のための独立したネイティブ統合境界です（クロスプラットフォームアーキテクチャのガイダンス).
この構成により、ネットワークアクセスが集中管理され、画面間の不整合な処理を回避できます。また、状態遷移のパスが何通りにも分かれず1つになるため、競合解決やローカルファーストの挙動をはるかに管理しやすくなります。
なぜこれが重要なのか： 認証と永続化のパスを1つに統一することは、フレームワークの選択よりもバグを減らします。状態の管理が複雑になる箇所の重複ロジックを削減できるためです。
クライアントにセキュアな永続化が含まれるなら、後回しにせずアーキテクチャ計画に入れてください。実用的な補足ガイドは CapgoによるCapacitorアプリでのSQLite暗号化に関するメモ特にアプリがトークンや下書き、キャッシュしたレコードをローカルに保存している場合はなおさらです。
シンプルなオーナーシップのルール
チームが行き詰まったときに、このルールを使ってください。
- UIレイヤー: 一時的な表示状態とユーザー操作を管理します。
- Store または ViewModel: セッション状態、ワークフロー状態、画面間の連携を管理します。
- リポジトリ: 読み取り、書き込み、キャッシュ、データの整合性を担います。
- ネイティブ境界: 上位レイヤーに漏れないデバイス固有の統合を管理します。
この構造なら状態を説明可能なまま保てます。また、各レイヤーをアプリ全体ごとテストハーネスに持ち込むことなくテストできるため、テストが格段に楽になります。
オフライン動作と同期をアーキテクチャのファーストクラスとして扱う
オフライン対応は、単なる仕上げ作業として扱うべきではありません。倉庫、クリニック、電車のトンネル内、フィールドサービスの巡回先などでアプリを使うなら、オフライン時の動作は製品の信頼性の中核を成す要素であり、「あれば便利」な機能ではありません。
優れたオフライン対応クライアントには、通常4つの要素が必要です。まず、 ローカルファーストなデータストア、 冪等性を持つ書き込みキュー、 ドキュメント化された競合ポリシーを持つ同期エンジン、および 認証リフレッシュの境界 が、進行中の処理を予期せず止めないこと。どれか一つでも欠けていると、デモでは問題なく見えても本番では不具合が出ます。
フィールド技術者が最も明確なテストケースです
技術者がデバイスに信号がない状態で作業指示書を入力したとします。アプリはレコードをローカルに保存し、書き込みをキューに積んで、ユーザーが作業を続けられるようにする必要があります。接続が回復したら、同期エンジンは保留中の書き込みを安全な順序で送信し、チームが事前に文書化したルールに従って競合を解決する必要があります。
だからこそ、オフライン設計はアーキテクチャ図に含めるべきです。認証レイヤーが書き込み中に期限切れになったり、同期パスが画面に分散していたりすると、ユーザーは半端に保存されたデータと、再現が難しいサポートチケットを抱えることになります。Capacitorでローカルファースト画面を構築するチームにとって、実装パターンは Vue、Angular、Reactでオフライン画面を作成する アーキテクチャの視点を補完する有用な要素です。
同期システムは、目に見える形で失敗すべきで、独創的に失敗すべきではありません。書き込みに何が起きたかアプリが説明できなければ、ユーザーは失われたと考えるでしょう。
現在のアプリで確認すべきこと
最も手早い監査はシンプルです。
- すべてのオフライン書き込みは1つのキューに入りますか？
- 書き込み操作は繰り返しても安全ですか？
- 文書化された競合ポリシーは1つありますか？
- 認証のリフレッシュは、保留中の書き込みを中断するのではなく保護しますか？
- サポートは、デバイスからサーバーまでの同期失敗を追跡できますか？
どれか1つでも「いいえ」なら、それは単なる同期バグではありません。アーキテクチャのギャップです。
同期に関する顧客向けコミュニケーションも重視するチームにとって、関連する運用面の要素は 通知システムが壊れるのを防ぐ方法。プッシュ通知とオフライン復旧は、同じリリースサイクルで同時に失敗することが多いからです。
セキュリティ、コンプライアンス、Live Update の配信
セキュリティとコンプライアンスは通常ポリシー文書で語られ、リリース配信はエンジニアリングのランブックに書かれます。モバイルアプリでは、これらの関心事は重なります。更新パスは信頼境界の一部なので、アーキテクチャでは code がどう移動し、シークレットがどう保護され、変更がどう制御されるかを記述する必要があります。
まず基本から。機密値は画面やログではなく安全なストレージに置くべきです。シークレットをクライアントの code に散在させてはいけません。証明書ピンニングのようなネットワーク信頼制御を使う場合、その判断はクライアントの動作とインシデント対応の両方に影響するため、アーキテクチャ文書に含めるべきです。
リリースの仕組みをアーキテクチャ図に含めるべき理由
エンタープライズチームは、アプリのセキュリティ、監査可能性、リリースタイミングを独立したもののように分けて考えがちです。しかし実際は違います。制御された更新パスが重要なのは、App Store のレビューサイクルや段階的ロールアウトが問題への対応速度を左右し、ロールバック機能が不良リリースを短いイベントで済ませられるか長引かせるかを決めるからです。
Capacitor と Electron のチームにとって、live update チャネルは、ストアのレビューを待たずに JavaScript、CSS、コピー、設定、アセットの修正を配信するための実用的な方法です。Capgo はそのモデルの一例で、署名付きバンドル、チャネルのガードレール、デバイス別ログ、CapacitorJS と Electron アプリ向けのロールバック対応を備えています。この種の配信経路は単なるツールではなくアーキテクチャとして捉えるべきです。クライアントが何を、いつ信頼するかが変わるからです。
規制対象チームがドキュメント化すべきこと
アーキテクチャの注記は具体的にする。
- シークレットの保存場所とローテーション方法
- ライブ更新できるアセットとできないアセット
- 更新バンドルの署名と検証方法
- ロールバックのトリガー条件
- 監査証跡がリリースをデバイスやチャネルに紐付ける方法
- クライアントのどの部分がストアレビューで管理され、どの部分がライブ配信で管理されるか
法務、サポート、エンジニアリングが活用できるレベルの詳細です。また、SOC 2、GDPR、リリース運用を3つの別々のドキュメントではなく、同じ会話の中で扱えるレベルでもあります。
ライブ更新の運用面をより深く知りたいチームは、 Capgo のモバイルアプリのライブ更新に関するセキュリティベストプラクティス このリリースモデルと直接関連しています。
パフォーマンス、スケーラビリティ、チームベロシティの両立
パフォーマンス向上に役立つモジュール境界は、チームのスループット向上にも寄与します。起動時に重要なcode、レンダリングロジック、状態管理、永続化が分離されていると、アプリの他の部分に影響を与えることなく、各レイヤーをチューニング、プロファイリング、置き換えやすくなります。
これが重要なのは、大規模なモバイルプログラムは一人で保守されるものではないからです。依存性注入を使えばチームは実装をクリーンに差し替えられ、レイヤーごとのオブザーバビリティでインシデントを切り分けやすくなり、CI/CDパイプラインは毎回のリリースをフルリライト扱いせず、変更された部分だけをビルド、テスト、リリースできます。
モジュール境界がリリースシステムをシンプルにする
アーキテクチャがモジュール化されていれば、リリースシステムもモジュール化できます。デプロイ単位が小さくなるため差分更新がより現実的になり、各レイヤーが自身の動作を報告するため、サポートはロールアウトをより正確に説明できます。これがエンジニアリング品質とインシデント復旧を結ぶ架け橋です。
エンタープライズ向けのポイントはシンプルです。優れたアーキテクチャは、各レイヤーを個別にオブザーバブル、置き換え可能、リリース可能にします。弱いアーキテクチャは、すべてのリリースを部門横断的なイベントにしてしまいます。
エンタープライズモバイルチーム向けの推奨パターン
今四半期にチームを改善したいなら、スローガンではなく意思決定に集中してください。まず、明示的な UI、ドメイン、データレイヤーを 単方向フローで定義し、それを新規開発のデフォルトとして扱います。次に、オフライン時と同期の挙動を標準化し、機能ごとに独自のキューやリトライルールが生まれないようにします。
3つ目に、ストアリリース、Live Updates、あるいはその両方を使う場合でも、アップデート配信チャネルとロールバック手順をドキュメント化します。4つ目に、レイヤーごとのオブザーバビリティを追加し、サポートがどこで障害が始まったかを特定できるようにします。5つ目に、CI/CDはアーキテクチャに沿って組み込み、その周りを迂回させないようにして、パイプラインがbundle、channel、変更の境界を理解できるようにします。
ここではシンプルな成功指標が役立ちます。ある機能チームが他の3チームに許可を取らずに1つのレイヤーをリリースできるなら、そのアーキテクチャは役割を果たしています。
モバイルのロードマップのリリースが難しくなってきたなら、署名付きLive Updates、チャネルベースのロールアウト、ロールバック保護、そして Capacitor や Electron アプリ向けのデバイスレベルのオブザーバビリティを実現する選択肢として、Capgo を評価する価値があります。詳しくは Capgo そのリリースパスがレイヤー化されたモバイルアーキテクチャやインシデント復旧計画にどう当てはまるか、チームに聞いてみてください。
