構成図を描き、故障時の影響と復旧の方針を決める

原稿の管理表（13項目：記事ID・カテゴリ・要件ID・先に読むと理解しやすい記事・成果物パス・対象ツール・検証状況・最終更新日など）

管理項目	内容
記事ID	05-04
主な中カテゴリ	05-04 構成と障害・復旧の方針を決める
関連中カテゴリ	05-03、06-02、12-03、12-04
関連要件ID	REQ-008
先に読むと理解しやすい記事	05-03（権限と外部連携を設計する）を読んでいると理解しやすい。未読でも本文で必要な内容は説明する
到達目標	画面・処理・保存先の分担、故障の影響、バックアップ、復旧目標の関係を説明でき、「保存したこと」と「復元できること」が別であることを言える。復旧時間の目標と許容するデータ損失の範囲を、費用・複雑さと比較して方針と限界を書ける
3層の配置	理解する＝第3〜4節／作って確かめる＝第5〜7節／設計を判断する＝第8節
成果物パス	templates/05-04-architecture-recovery_template.md、templates/05-04-architecture-recovery_example.md
出典	第11節参照
対象ツール・バージョン	特定のクラウドサービス・製品名は挙げない
検証状況	本文・ひな形・記入例はClaude Codeが作成。2026-09-20、ユーザーによる実読でPASS
残課題	第11節参照
最終更新日	2026-09-20（新規作成）。2026-09-21（Final Content Audit：読む順路の「本文は今後制作予定」（全項目に本文がある現在は誤り）を削除。本文は不変）

この記事の会社・人物・数値はすべて架空の設定です。実在する会社や案件とは関係ありません。この記事の復旧目標の数値は、すべて架空の仮定であり、実測値ではありません。

この記事は何の話か。05-01〜05-03で設計してきたアプリの構成（画面・処理・保存先）を図にし、どこかが故障したときに何が困るか、どこまで戻せるようにしておくかの方針を決める話です。

なぜ必要か。構成や復旧の方針を決めずに作ると、実際に障害が起きたときに「どこまでデータが戻るのか」「どれくらいの時間で使えるようになるのか」が分からず、利用者に説明できません。

この記事を読むとできるようになること。

• 画面・処理・保存先の分担、故障の影響、バックアップ、復旧目標の関係を説明できる
• 「保存したこと」と「復元できること」が別であることを説明できる
• 復旧時間の目標と許容するデータ損失の範囲を、費用・複雑さと比較して方針と限界を書ける

読む順路。この記事は3つの深さで読めます。全部を順に読む必要はありません。

• 基本だけ理解する：第1節→第3節→第4節→第5.2節の構成図→第9節。ここまでで「構成の分担」と「復旧方針の形」が分かり、ひな形を埋め始められます。
• 作って確かめる：上に加えて第5.5節（AIへの依頼）→第6節（失敗例と直し方）→第7節。
• 設計判断を深める：上に加えて第8節（復旧時間とデータ損失の比較、適用限界）。

1. 今回の業務課題と完成するもの

この記事でやることは、05-01〜05-03で設計してきたアプリの構成（画面・処理・保存先）を図にし、それぞれが故障したときに何が困るかを整理し、バックアップと復旧の方針を決めることです。

権限や状態遷移が決まっても、「保存先が読めなくなったらどうするか」が決まっていなければ、実際に障害が起きたときに対応できません。この記事では、構成図と復旧方針を、架空の仮定として整理します。

この記事を読み終えると、次のものが手元にできます。

• 構成図（画面・処理・保存先、それぞれの役割）
• 故障箇所ごとに影響する操作の一覧
• バックアップ対象・頻度・復旧目標（架空の仮定）

2. 前提知識と読む順路

この記事で使う言葉を先に説明します。基礎用語（構成図・バックアップ・復旧目標）は、まだ独立した記事がないため、ここで平易に説明します。

構成図

一言でいうと、アプリがどんな部品からできていて、それぞれが何をするかを図にしたものです。この記事では、画面（利用者が見る部分）・処理（判断や更新を行う部分）・保存先（データを保存する部分）の3つに分けます。04-02・05-03でも、この3つの分担（画面で隠す、処理で拒否する、保存先で制限する）を扱いました。

これがないと、どこかで問題が起きたときに、影響がどこまで広がるかを予測できません。

バックアップ

一言でいうと、ある時点のデータの写しを、別の場所に取っておくことです。写しを取った時刻を基準時点と呼びます。

これがないと、保存先が壊れたときに、データが完全に失われます。

復旧目標

一言でいうと、「どの時点のデータまで戻せるようにしておくか」「どれくらいの時間で使えるようにするか」という、あらかじめ決めておく目安です。

これがないと、実際に障害が起きたときに、どこまで頑張って復旧すればよいかの基準がなく、対応が場当たり的になります。

「保存したこと」と「復元できること」は別

データを保存しているからといって、実際にそこから復元できるとは限りません。復元の手順を試したことがなければ、いざというときに手順が間違っている、写しが壊れている、といった問題に気づけません。この考え方は、12-03（SAMPLE-C）で実際に復元を演習する内容につながります。

読む順路：権限設計は05-03が該当します。この構成図・復旧方針をもとにした環境分離は06-02、実際の復元演習は12-03（SAMPLE-C）・12-04が該当します。この記事だけでも進められるように、必要な説明は本文に含めています。

3. 理解する：なぜ構成と復旧の方針を先に決めるか

3.1 構成を分けて考える理由

3.2 「保存したこと」と「復元できること」は別、という考え方

バックアップを取っているだけでは、復元できることの証明にはなりません。復元の手順を試し、基準時点のデータと一致するかを確かめて初めて、「復元できる」と言えます（12-03で扱う内容）。

3.3 よくある誤解

「バックアップさえ取っていれば安心」。バックアップの写しが壊れていたり、復元の手順を間違えたりすると、実際には戻せません。定期的に復元を試すことが重要です（この記事の範囲外、12-04で扱います）。

「復旧目標は決めなくても、できるだけ早く直せばよい」。目標がないと、どこまで頑張ればよいかの基準がなく、利用者への説明もできません。目標は架空の仮定であっても、明示しておく必要があります。

「バックアップから戻せば、障害前の状態に完全に戻る」。基準時点より後の変更は、バックアップには含まれていません。「元どおり」ではなく「基準時点どおり」です（12-03で詳しく扱います）。

「AIに復旧目標を決めさせればよい」。AIは一般的な復旧目標の目安を提示できますが、この業務でどこまでの目標を採用するかは、費用や複雑さとのバランスから人が判断します（第4.3節）。

4. 判断すること

4.1 何を確認すればよいか

4.2 勝手に決めてはいけないこと

• 復旧目標の数値（どの時点まで、どれくらいの時間で）を、実測したかのように断定しません。架空の仮定として明記します。
• 05-01〜05-03で決めた設計を、この記事で変更しません。
• 12-03（SAMPLE-C）で扱う具体的な復元演習の内容を、この記事で先取りして詳しく説明しません（この記事は事前設計にとどめます）。

4.3 AIに任せる範囲

一般的な構成図の描き方、復旧目標の一般的な目安の提示はAIに任せられます。しかし、この業務でどの復旧目標を採用するかは、費用・複雑さとのバランスから人が判断します。

5. 作って確かめる：構成図と復旧方針を作る

5.1 準備

05-01のデータ項目表、05-02の状態遷移表、05-03の権限表を用意します。

5.2 構成図

[画面]  ── 利用者の入力・閲覧（04-02）
   │
   ▼
[処理]  ── 権限の確認、状態遷移の実行（05-02・05-03）
   │
   ▼
[保存先] ── 依頼・利用者・履歴のデータ（05-01）

5.3 故障箇所ごとの影響

5.4 バックアップと復旧目標（架空の仮定）

これらの数値は、実際に測定した値ではなく、この記事が演習のために置いた架空の仮定です。

5.5 AIに復旧方針の下書きを頼む

構成図・データ項目表をもとに、復旧方針の下書きをAIに作らせます。

依頼・承認管理アプリの構成は、画面・処理・保存先の3つに分かれています。保存先には依頼・利用者・履歴のデータがあります。

依頼：
1. 画面・処理・保存先それぞれが故障した場合に、影響を受ける操作を整理してください。
2. バックアップ対象・頻度・復旧目標の案を、架空の仮定として示してください。

してはいけないこと：
- 復旧目標の数値を、実測したかのように断定しないでください。「架空の仮定」と明示してください。
- 特定のクラウドサービス・製品名を挙げないでください。

6. 初稿・失敗例・修正

6.1 説明用の失敗例（AIの初稿という設定）

AIへの依頼の結果、次のような下書きが返ってきた、という設定にします（実際のAI出力を観測したものではありません）。

• 「復旧時間は99.9%の可用性で実現できます」と、実測していない性能数値を断定的に記載
• 「〇〇クラウドのバックアップ機能を使えば安心です」と、正本に存在しない具体的なサービス名を記載

6.2 見つけ方と直し方

• 実測していない性能数値の断定：確認していない数値です。「架空の仮定」に修正します。
• 具体的なサービス名の記載：正本に存在しません。削除し、一般的な仕組みとして説明します。

指摘：
1. 復旧時間・可用性の数値は実測していません。「架空の仮定」として明記してください。
2. 特定のクラウドサービス名は挙げないでください。

変えないこと：
- 05-01〜05-03の内容そのものは変更しないでください。

6.3 修正後の復旧方針

修正後の構成図・復旧方針は、第5.2〜5.4節のとおりです。

7. 確認結果

第5.2〜5.4節の内容を、完了条件と照合します。

残る制限：この構成図・復旧方針は架空の設定に基づく一例であり、実際に復元を試したものではありません。復元演習は12-03（SAMPLE-C）で扱います。この記事の本文と記入例はClaude Codeが作成し、2026-09-20にユーザーによる実読でPASSしましたが、実際の業務担当者による内容確認は行っていません。

8. 設計を判断する

8.1 復旧時間とデータ損失の範囲を、費用・複雑さと比較する

架空企業「みらい業務サービス」の小規模な社内利用という規模を踏まえ、データ損失の可能性をある程度許容しても、運用の手間・費用を抑える1日1回のバックアップを採用します。これは架空の仮定に基づく判断であり、実際の業務では、依頼の件数や重要度に応じて頻度を見直す必要があります。

8.2 適用限界

この構成図・復旧方針は、架空企業「みらい業務サービス」の小規模な社内アプリを前提にしています。復旧目標の数値はすべて架空の仮定であり、実測・実運用で確かめたものではありません。実際の企業では、業務の重要度・法令や契約上の要求に応じて、復旧目標を改めて確認・決定する必要があります。

9. 持ち帰る成果物

自分の業務に使うときの手順は次のとおりです。

1. 前工程（データ項目表、状態遷移表、権限表）を用意する
2. 構成図を画面・処理・保存先に分けて描く
3. 故障箇所ごとに、影響を受ける操作を整理する
4. バックアップ対象・頻度・復旧目標を、架空の仮定として明記する

10. 次工程への受渡し

次へ渡すもの：構成図、故障箇所ごとの影響、バックアップ・復旧目標（架空の仮定）。

次工程での使われ方：06-02（環境分離）では、この構成図をもとに開発・実行環境を分けます。12-03（SAMPLE-C）・12-04では、この復旧方針を前提に、実際の復元演習を行います。

前工程へ戻る条件：構成図を作る中で、05-01〜05-03の設計に不足が見つかったら、それぞれの記事に戻って見直します。

11. 根拠と更新情報

• この記事の会社・人物・構成図・復旧目標の数値はすべて架空の設定です。
• 第6節の初稿は説明用の失敗例であり、実際のAI出力を観測した記録ではありません。
• REQ-008（復元後の照合、戻らない変更の説明）は、教材設計書AI_SYSTEM_DEV_BLUEPRINT_v0.1.md第5.4節に基づきます。
• 「保存したこと」と「復元できること」は別、「元どおり」ではなく「基準時点どおり」という考え方は、SAMPLE-C（障害から復旧し、業務を再開できるか確認する）の結論と一致させています。この記事はSAMPLE-Cの内容を繰り返すものではなく、その前段階の設計（事前に構成と方針を決める）を扱います。
• 制作の来歴：本文・ひな形・記入例はClaude Codeが作成しました。作成時点（2026-09-20）では人による実読・内容確認は未実施でした。
• 更新履歴：2026-09-20、ユーザーによる実読でPASS。本文・構成図・復旧方針の内容は変更していません。
• 未確認事項：バックアップ頻度・復旧目標の数値は架空の仮定であり、実測・実運用での検証は行っていません。業務担当者による内容確認も未実施です。