責任分界と構成図
このページで学ぶこと
Section titled “このページで学ぶこと”- 技術構成図をPMが読む理由
- クラウド事業者、クライアント、制作会社、外部サービス事業者の責任の違い
- 契約者、管理者、作業者、障害対応者を分けて考える方法
- 外部サービスが増えたときの管理漏れを防ぐ方法
- 責任分界を見積・契約・運用へ落とし込む方法
現在のWebサイトは、一社・一台のサーバーだけで完結しないことが増えています。
flowchart LR
U[利用者]
DNS[DNS事業者]
CDN[CDN・WAF事業者]
HOST[ホスティング事業者]
CMS[CMS事業者]
API[外部API事業者]
MAIL[フォーム・メール事業者]
U --> DNS
DNS --> CDN
CDN --> HOST
HOST --> CMS
HOST --> API
HOST --> MAIL
各サービスに、契約者、管理者、費用、利用規約、障害窓口があります。
PMはプログラムを実装しなくても、どの要素が止まると何が使えなくなり、誰が対応するかを整理する必要があります。
構成図には二つの役割がある
Section titled “構成図には二つの役割がある”技術の接続関係を示す
Section titled “技術の接続関係を示す”- 利用者からWebサイトまでの経路
- ファイルやデータの保存場所
- CMSやAPIの接続
- 認証・フォーム・検索などの外部サービス
- ログ・監視・バックアップ
管理と責任の関係を示す
Section titled “管理と責任の関係を示す”- 契約者
- 管理権限を持つ組織
- 設定変更を行う担当
- 障害時の一次連絡先
- 費用負担者
- 更新期限
- 保守範囲
技術構成図だけでは、担当者や契約が分かりません。責任分界表とセットで管理します。
「契約者」「管理者」「作業者」は同じとは限らない
Section titled “「契約者」「管理者」「作業者」は同じとは限らない”たとえば、クライアント名義でCloudflareを契約し、制作会社が設定し、別の保守会社が監視することがあります。
| 役割 | 内容 |
|---|---|
| 契約者 | サービス利用契約を持つ。請求・解約に関わる |
| 所有者 | ドメインやデータ等の権利を持つ |
| 管理者 | 管理画面や設定変更の高い権限を持つ |
| 作業者 | 日常の更新・設定・公開作業を行う |
| 承認者 | 本番変更や費用発生を承認する |
| 一次対応者 | 障害を受け付け、状況を確認する |
| 復旧担当 | 技術的な復旧作業を行う |
| 利用部門 | コンテンツ更新や業務上の利用を行う |
「クライアント管理」「制作会社管理」とだけ書くのではなく、具体的な担当を分けます。
クラウドの責任共有
Section titled “クラウドの責任共有”クラウド事業者は、データセンター、物理サーバー、共通ネットワーク、仮想化基盤などを管理します。
利用者は、選んだサービスに応じて、アカウント、権限、設定、アプリ、データ、CMS、APIキーなどを管理します。
flowchart TB
subgraph クラウド事業者
P[施設・物理機器]
N[共通ネットワーク]
V[仮想化・サービス基盤]
end
subgraph "クライアント・制作側"
A[アカウント・権限]
S[サービス設定]
C[ソース・コンテンツ]
D[データ・個人情報]
O[監視・業務運用]
end
ただし、境界はサービスによって変わります。仮想マシンではOS管理が利用者側に残りやすく、SaaSでは事業者へ任せる範囲が増えます。
Web制作案件の責任分界例
Section titled “Web制作案件の責任分界例”| 対象 | 主な確認事項 | 責任を持つ候補 |
|---|---|---|
| ドメイン | 所有、更新、移管、期限 | クライアント |
| DNS | レコード変更、メール影響、切戻し | クライアント／制作会社 |
| CDN・WAF | キャッシュ、ルール、証明書、ログ | 制作会社／保守会社 |
| ホスティング | 配信、ビルド、権限、料金 | クライアント／制作会社 |
| CMS | コンテンツ、権限、API、契約 | クライアント／制作会社 |
| ソースコード | リポジトリ、レビュー、引継ぎ | 制作会社／クライアント |
| 外部API | 仕様、キー、料金、SLA | クライアント／API事業者 |
| フォーム | 個人情報、通知、保存、スパム | クライアント／制作会社 |
| ログ | 保存期間、閲覧権限、個人情報 | クライアント／保守会社 |
| バックアップ | 対象、頻度、復元テスト | サービス事業者／保守会社 |
| 障害対応 | 検知、一次対応、復旧、報告 | 契約で定義 |
この表に唯一の正解はありません。案件ごとに合意することが重要です。
構成図の作り方
Section titled “構成図の作り方”PM向け構成図は、細かなネットワーク記号より、関係者が読めることを優先します。
必ず入れたい要素
Section titled “必ず入れたい要素”- 利用者
- ドメイン・DNS
- CDN・WAF
- Webサイトの配信先
- CMS
- API・外部サービス
- データ保存先
- 管理者・契約者
- 本番・検証環境
- 主なデータの流れ
図に書きすぎない
Section titled “図に書きすぎない”一枚にすべてのポート番号、サブネット、ライブラリ名まで書くと、非技術者が読めなくなります。
必要なら次のように分けます。
- 全体構成図
- データ連携図
- 運用・責任分界図
- 公開手順図
- 障害時連絡フロー
外部サービス一覧を作る
Section titled “外部サービス一覧を作る”構成図とは別に、次の台帳を持つと管理しやすくなります。
| 項目 | 記載内容 |
|---|---|
| サービス名 | 正式名称 |
| 用途 | CMS、検索、フォーム、分析等 |
| 契約者 | 会社・部門 |
| 管理URL | 管理画面 |
| 管理者 | 氏名・チーム |
| 権限 | 管理者、編集者等 |
| 料金 | 月額・従量・無料枠 |
| 更新期限 | ドメイン、証明書、年間契約等 |
| 障害情報 | ステータスページ、連絡先 |
| データ | 保存内容、個人情報の有無 |
| 解約時 | データ出力、削除、移行方法 |
| 備考 | 制約、規約、SLA等 |
パスワードや秘密鍵そのものは台帳へ記載せず、承認されたパスワード管理手段を使います。
障害時の切り分けと責任
Section titled “障害時の切り分けと責任”外部サービスを使うと、「制作会社で直せない障害」が発生します。
しかし、直せないことと、何もしなくてよいことは別です。
flowchart TD
A[障害を検知] --> B[影響範囲を確認]
B --> C[自社設定・実装を確認]
C --> D{外部サービス障害か}
D -->|いいえ| E[制作・保守担当が復旧]
D -->|はい| F[事業者の障害情報を確認]
F --> G[代替表示・利用者告知]
G --> H[復旧確認・事後報告]
PMは、次を事前に決めます。
- 誰が障害を検知するか
- 誰が一次切り分けするか
- サービス事業者へ誰が問い合わせるか
- 復旧までの代替表示は何か
- クライアント・利用者へ誰が連絡するか
- 復旧後に何を確認するか
- 障害報告書を作るか
権限設計も責任分界の一部
Section titled “権限設計も責任分界の一部”管理権限を一人や一社へ集中させると、退職・契約終了・緊急時に問題になります。
一方、全員を管理者にすると誤操作や漏えいリスクが増えます。
- クライアントが所有すべき契約はクライアント名義にする
- 制作会社は必要な作業権限だけを持つ
- 個人アカウントの共有を避ける
- 多要素認証を有効にする
- 退場時に権限を削除する
- 緊急用管理者の扱いを決める
- 本番変更の記録を残す
契約・見積へ落とす
Section titled “契約・見積へ落とす”責任分界が曖昧だと、公開後に無償対応が膨らみます。
見積・契約では、少なくとも次を明記します。
- 初期構築に含む設定
- クラウド・SaaS利用料の負担者
- 日常監視の有無
- 障害の受付時間
- 一次切り分けの範囲
- 外部事業者への問い合わせ
- CMS・ライブラリ更新
- バックアップ・復元
- 設定変更回数
- ログ調査
- セキュリティ対応
- 緊急対応
- 契約終了時の引継ぎ
「保守一式」という表現だけでは、期待値がずれます。
実案件ではどう考えるか
Section titled “実案件ではどう考えるか”クライアント管理のAWSへ制作する
Section titled “クライアント管理のAWSへ制作する”- アカウントや権限の発行方法
- 請求・予算アラート
- 設定変更の承認
- ログの閲覧権限
- 公開作業者
- 障害時のAWS問い合わせ権限
- 制作会社退場時の権限削除
を決めます。
制作会社名義のSaaSを利用する
Section titled “制作会社名義のSaaSを利用する”契約終了時に、クライアントが管理を継続できない可能性があります。所有権、データ移行、請求切替、管理アカウント移管を確認します。
外部APIを利用する
Section titled “外部APIを利用する”API事業者が停止した場合、制作会社はAPI自体を復旧できません。しかし、タイムアウト、代替表示、キャッシュ、監視、利用者告知はWebサイト側で設計できます。
PMチェックリスト
Section titled “PMチェックリスト”- 全体構成図があり、非技術者も読める
- サービスごとの契約者・請求先を把握している
- 管理者・作業者・承認者を分けている
- 本番・検証・開発環境の責任者を決めている
- ドメイン・DNS・証明書の更新責任を決めている
- クラウド・CMS・API等の障害窓口を把握している
- 監視・一次切り分け・復旧担当を決めている
- 外部障害時の代替表示と告知方法を決めている
- 管理権限に多要素認証を設定している
- 契約終了・担当変更時の権限削除手順がある
- サービス解約時のデータ出力・移行方法を確認している
- 保守契約に含む範囲と含まない範囲を明記している
よくある誤解・失敗
Section titled “よくある誤解・失敗”「契約者がクライアントなら、制作会社は責任を持たない」
Section titled “「契約者がクライアントなら、制作会社は責任を持たない」”契約責任と、設定・実装・運用責任は別です。実際の役割を明記します。
「サービス事業者がバックアップしているから復元できる」
Section titled “「サービス事業者がバックアップしているから復元できる」”バックアップが存在しても、保存対象、保持期間、復元単位、復元依頼方法が要件に合うとは限りません。
「管理者アカウントを共有すれば簡単」
Section titled “「管理者アカウントを共有すれば簡単」”誰が操作したか分からず、退場者のアクセスも止めにくくなります。個人アカウントと適切な権限を使います。
「障害はエンジニアに任せればよい」
Section titled “「障害はエンジニアに任せればよい」”障害時には技術対応だけでなく、影響判断、クライアント連絡、告知、優先順位、復旧判定が必要です。PMの役割が大きい領域です。
「構成図は納品時だけ作ればよい」
Section titled “「構成図は納品時だけ作ればよい」”要件・見積段階で構成図を作ることで、漏れているサービス、費用、責任、障害点を早期に発見できます。
理解度チェック
Section titled “理解度チェック”Q1. 契約者、管理者、作業者は同じでなければならないでしょうか。
Section titled “Q1. 契約者、管理者、作業者は同じでなければならないでしょうか。”回答と解説
同じである必要はありません。誰が契約を所有し、誰が高権限を持ち、誰が日常作業をするかを分けて明記することが重要です。Q2. 外部APIの障害を制作会社が復旧できない場合、制作会社側でできることはありますか。
Section titled “Q2. 外部APIの障害を制作会社が復旧できない場合、制作会社側でできることはありますか。”回答と解説
あります。監視、タイムアウト、代替表示、キャッシュ、利用者への案内、復旧後の再確認などを設計できます。Q3. クラウド事業者が物理サーバーを管理している場合、利用者は何を管理しますか。
Section titled “Q3. クラウド事業者が物理サーバーを管理している場合、利用者は何を管理しますか。”回答と解説
利用サービスによりますが、アカウント、権限、設定、アプリケーション、コンテンツ、データ、秘密情報、運用などが利用者側に残ります。Q4. なぜ構成図に契約者や管理者も書くとよいのでしょうか。
Section titled “Q4. なぜ構成図に契約者や管理者も書くとよいのでしょうか。”回答と解説
障害・更新・契約終了時に、誰が設定変更や問い合わせを行えるかが分かるためです。技術関係だけでは運用できません。Q5. 保守契約の責任分界を明確にするため、何を記載しますか。
Section titled “Q5. 保守契約の責任分界を明確にするため、何を記載しますか。”回答と解説
監視、受付時間、一次切り分け、復旧作業、外部問い合わせ、バックアップ、更新、緊急対応、費用、対象外事項などを具体的に記載します。- AWS「責任共有モデル」
https://aws.amazon.com/jp/compliance/shared-responsibility-model/
クラウド事業者が担う「クラウド自体のセキュリティ」と、利用者が担う「クラウド内の設定・データ等」を分けて考えるための公式資料。 - AWS Well-Architected Framework「Shared responsibility」
https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/shared-responsibility.html
選択するサービスによって利用者の責任が変わることを確認するための公式資料。 - 本教科書付録「案件開始時の技術確認」
docs/appendix/project-checklist.md - 本教科書付録「公開・移行チェックリスト」
docs/appendix/release-checklist.md