【クラウド法務】「対応可能」と書いたときに、実務で何が義務化されるのか― “できます”の一言が、通知・ログ提出・保全・復旧の「期限付き義務」に化ける瞬間 ―

※本記事は一般的な情報提供であり、個別案件の法的助言ではありません。

────────────────────────────

はじめに

────────────────────────────

情シスやクラウド運用の現場で、「対応可能」という言葉は、日常的に使われます。

・セキュリティチェックシートに「ログ提出：対応可能」

・RFP回答で「24/7監視：対応可能」

・委託先の提案書に「障害時エスカレーション：対応可能」

・運用設計書に「保全（削除停止）：対応可能」

その場では、「できるはず」「やろうと思えばできる」くらいの意味で書きます。

ところが、事故・監査・取引先照会の局面で、相手からこう言われて詰まります。

「“対応可能”って書いてありますよね。じゃあ、いつまでに出せますか？」

「“対応可能”って言った以上、追加費用なしでやってもらえますよね？」

「“対応可能”なら、誰が・何分以内に・どの形式で、ですか？」

結論から言うと、「対応可能」は便利な言葉ですが、書かれた場所と文脈によって、実務上は“義務の宣言”として扱われることがあります。

本記事では、「対応可能」と書いたときに、実務で何が義務化されるのかを、技術→法務→運用の順で整理します。

────────────────────────────

技術構成の“事実整理”：「対応可能」が現場で“契約の材料”になる経路

────────────────────────────

まず、技術現場で書いた一言が、どうやって「義務」になっていくかを、ありがちな流れで整理します。

よくある経路（テキスト図）

（1）セキュリティチェックシート／RFP回答／提案書

　「対応可能」「実施可能」「サポート可能」

　↓

（2）そのまま契約の添付資料になる（別紙、SOW、運用要件、SLA、運用設計書）

　「本書面一式は契約の一部」とされる

　↓

（3）運用開始後、監査・取引先照会・事故対応で“根拠資料”として引っ張り出される

　「書いてある＝約束」扱い

　↓

（4）“期限”と“成果物”を求められる

　「いつまでに」「何を」「どの形式で」「誰が承認して」

　↓

（5）出せない・遅れる・追加費用になると、説明が壊れる

　「じゃあ対応可能って何だったの？」になる

ポイントはここです。

「対応可能」は、技術的には“能力の話”のつもりでも、実務では“成果の話（やる義務）”として解釈されやすい、ということです。

ここまでは技術の話。

ここからが法務・説明責任の地雷です。

────────────────────────────

2. 「対応可能」と書いた瞬間に、実務で義務化されやすいもの（3つ）

────────────────────────────

「対応可能」が危ないのは、曖昧なまま外に出ると、相手が“空白”を埋めて解釈するからです。

特に義務化されやすいのは、次の3つです。

────────────────────────────

義務化されやすいもの①：期限（いつまでに）

────────────────────────────

「対応可能」と書いた側は、“やろうと思えばできる”の感覚でも、

相手は「いつまでに？」をセットで受け取ります。

典型例

・ログ提出：対応可能 → 「何営業日以内に提出できますか？」

・一次通知：対応可能 → 「検知から何分以内に通知しますか？」

・復旧：対応可能 → 「何時間で戻りますか？（RTO）」

・保全：対応可能 → 「要請から何分で削除停止しますか？」

期限が書かれていない場合、実務では

・“合理的期間”

・“業界の常識”

・“相手の社内ルール”

で埋められます。

これが一番揉めます。なぜなら、後から「そんな期限は約束していない」が通りにくいからです。

────────────────────────────

義務化されやすいもの②：成果物（何を出すか・何が完了か）

────────────────────────────

「対応可能」が“何を出す”に結びつくと、成果物義務（出す義務）になります。

典型例

・「監査ログ提出対応可能」

　→ 相手が期待する成果物：対象期間のログ、抽出者記録、形式（項目・時刻基準）、真正性の説明

・「インシデント報告対応可能」

　→ 成果物：第一報、暫定影響、タイムライン、原因分析（RCA）、再発防止策

・「保全対応可能」

　→ 成果物：削除停止の実施記録、保全対象、保全期間、アクセス制限の証跡

「対応可能」と書くと、相手は「出る前提」で動きます。

出せないと、技術力ではなく統制不備・説明不能として評価されやすいです。

────────────────────────────

義務化されやすいもの③：体制（誰がやるか・誰が責任者か）

────────────────────────────

「対応可能」は、体制の存在を前提とされます。

典型例

・24/7対応可能 → 24/7で動ける連絡網・承認者・当番・委託範囲がある前提

・SOCがある → 一次分析はできるが、封じ込め・提出・対外説明の主語が決まっている前提

・委託で回す → 委託先に“義務として”やらせる条項（SOW）がある前提

つまり「対応可能」と書くと、実務上は

「人・権限・手順・記録」が揃っている（揃える義務がある）

と見られやすくなります。

────────────────────────────

3. 「対応可能」が“義務”になるかどうかは、どこに書いたかで決まる

────────────────────────────

ここが最重要です。

同じ「対応可能」でも、置かれた場所で“重さ”が変わります。

────────────────────────────

（A）契約の一部になる文書に書いた場合：義務化されやすい

────────────────────────────

例

・SOW（作業範囲別紙）

・運用要件定義書（契約添付）

・セキュリティ要求事項（契約添付）

・RFP回答書が契約に取り込まれる形

・「本書面一式は契約の一部」とされる資料

この場合、「対応可能」は

“契約上の履行内容（やる義務）”

として扱われる可能性が高いです。

────────────────────────────

（B）契約前の提案書・チェックシートでも、あとで「根拠資料」にされる

────────────────────────────

契約前でも、相手が意思決定の根拠にしていた場合、実務上はこう言われます。

「その前提で選定した」

「それが要件として社内で通っている」

ここで“引く”と信用が落ちます。

つまり、契約前の「対応可能」でも、現場では義務のように運用されることがあります。

────────────────────────────

（C）社内文書に書いた場合でも、監査・親会社統制で“自社の約束”になる

────────────────────────────

監査や親会社統制は「自社がどう運用すると決めたか」を見に来ます。

社内運用基準に「対応可能」と書くと、監査で

「じゃあその運用が回っている証跡は？」

になりやすいです。

────────────────────────────

4. 整理のフレーム：「対応可能」を書くなら、必ずセットで決める3点

────────────────────────────

ここからが解決策です。

「対応可能」を禁止する必要はありません。

ただし、書くなら必ず “3点セット” に翻訳して書くと、説明が壊れません。

────────────────────────────

3点セット①：範囲（Scope）

────────────────────────────

最低限、これを固定します。

・対象システム（Azureのどこ？M365のどこ？テナント？サブスク？）

・対象ログ（Sign-in/Audit/Activity/Resource、SIEM側ログ等）

・対象時間（営業時間のみ／24/7）

・対象チャネル（メール、電話、チケット、会議）

・除外（できない範囲、対象外条件）

「対応可能」と言うなら、何の対応が可能なのかを一行で特定できる形にします。

────────────────────────────

3点セット②：期限（When）

────────────────────────────

期限がない「対応可能」は、後で必ず揉めます。

最低限の期限設計（段階でOK）

・受領（Acknowledge）：〇分以内

・着手（Start）：〇分〜〇時間以内

・一次報告（First report）：〇時間以内（暫定でよい）

・証跡提出（Evidence）：〇営業日以内

・原因分析（RCA）：〇営業日以内（確定困難なら暫定＋追加調査計画）

“全部確約できない”なら、段階で見通しを確約します。

これで「ベストエフォート」や「対応可能」が説明を壊しにくくなります。

────────────────────────────

3点セット③：成果物と責任分界（Deliverable / RACI）

────────────────────────────

「対応可能」は、最後はここで評価されます。

・成果物（何を出すか）：ログ、報告書、証跡、削除証明、剥奪証明…

・承認者（誰が外に出してよいと決めるか）

・実行者（誰が操作するか）

・記録（抽出者記録、タイムライン、作業ログ）

おすすめは、タスク別RACI（R=実行、A=最終責任、C=相談、I=共有）で固定することです。

特に、次は“RACIがないと必ず詰む”領域です。

・ログ削除停止（保全）

・権限剥奪（封じ込め）

・ログ提出（期限付き）

・一次通知（何分以内）

・対外説明（承認者）

────────────────────────────

5. すぐ使える言い換えテンプレ：「対応可能」を“約束の言葉”にする

────────────────────────────

ここは、提案書・SOW・運用合意の文章でそのまま使える型です（条文そのものではなく、実務合意の型）。

────────────────────────────

テンプレ①：ログ提出

────────────────────────────

NG例

「ログ提出：対応可能」

言い換え例

「対象ログ（別紙〇に定義）について、委託者からの要請受領後〇営業日以内に、合意した形式で提出する。提出にあたり、抽出者記録（実施者、日時、対象範囲、手順）を添付する。」

────────────────────────────

テンプレ②：保全（削除停止）

────────────────────────────

NG例

「保全：対応可能」

言い換え例

「保全要請があった場合、受託者は当該ログの削除・上書きを停止し、保全対象（期間・ログ種別）を固定する。保全の実施記録（対象、期間、実施者、時刻）を提供する。」

────────────────────────────

テンプレ③：一次通知

────────────────────────────

NG例

「インシデント通知：対応可能」

言い換え例

「重大度〇以上の事象を検知した場合、検知後〇分以内に一次通知を行う。通知内容には、事象概要、暫定影響、当面対応、次回更新時刻を含める。」

────────────────────────────

テンプレ④：24/7対応

────────────────────────────

NG例

「24/7対応可能」

言い換え例

「24/7の一次受付を行う。重大度〇以上については当番体制で〇分以内に受領連絡、〇時間以内に一次報告を行う。封じ込め操作は委託者の承認を前提とし、承認取得後〇分以内に実施する。」

（“誰の承認で動くか”を書かないと、事故時に止まります）

────────────────────────────

6. ケーススタディ（匿名化）：「対応可能」が“追加費用なしの義務”に化けた例

────────────────────────────

背景

・Azure＋M365運用。SOCとMSPを併用

・取引先のセキュリティチェックで「ログ提出：対応可能」「事故時報告：対応可能」と回答

・その回答が、契約添付資料として取り込まれた（本人は意識していない）

起きたこと

・取引先照会で「当該期間の証跡を〇営業日以内に提出」と要求

・社内は「SOCがあるから出せるはず」と思ったが、提出形式・抽出者記録・保全の手順が未整備

・委託先は「範囲の特定が必要」「抽出は別料金」「期限保証は難しい」と主張

・結果、「対応可能＝追加費用なしで期限内に出す義務」だと相手に解釈され、説明が割れた

立て直しで効いたこと

・「対応可能」を、範囲・期限・成果物（抽出者記録含む）に翻訳して合意

・タスク別RACI（ログ提出／保全／承認）を作り、主語を固定

・SOWに「提出期限」「形式」「保全協力」を期限付き義務として追記

・再委託（海外SOC等）の関与範囲も含め、アクセス主体と提出ルートを明文化

結果

・技術は変えずに「説明できる約束」に寄せられ、取引先対応が安定した

────────────────────────────

7. 「対応可能」と書く前に確認すべきチェックリスト

────────────────────────────

「対応可能」を書く前に、最低限これだけは確認すると事故りにくいです。

□ その文書は契約に取り込まれる可能性がある（別紙・SOW・要求事項）

□ “何に対して”対応可能か、対象範囲を一行で特定できる

□ 期限（何分以内／何営業日以内）を言える（段階でも可）

□ 成果物（何を出すか）が決まっている（ログ、報告書、証跡など）

□ 抽出者記録・保全記録など、証跡としての形を作れる

□ 誰が承認し、誰が実行するか（RACI）が決まっている

□ 委託先（SOC/MSP）に“義務として”やらせる条項（SOW）がある

□ 追加費用になる条件が整理されている（オプション化できている）

□ 再委託（国外・海外SOC）が絡むなら、範囲と監督責任を説明できる

□ 契約終了時の出口（アクセス剥奪証明、ログ返還・削除証明）が決まっている

YESが揃わない場合、「対応可能」は便利でも、将来の説明を壊す可能性が高いです。

────────────────────────────

8. まとめ：「対応可能」は“能力”ではなく“約束”として読まれる

────────────────────────────

「対応可能」は、書く側は軽い気持ちでも、読む側はこう受け取ります。

・期限付きで

・成果物を出す

・体制がある

という“約束”として。

だからこそ、書くなら必ず

範囲（Scope）／期限（When）／成果物と責任分界（Deliverable/RACI）

の3点セットに翻訳しておくことが、実務では一番安全です。

────────────────────────────

9. 全国からのご相談について

────────────────────────────

山崎行政書士事務所では、Azure / M365 / Entra ID 等のクラウド運用について、技術構成と契約・規程・監査対応をセットで整理し、

「対応可能」の一言が事故時の説明責任を壊さないよう、SOW（別紙）・責任分界（RACI）・証跡パック（提出/保全）まで落とし込む支援を行っています。

・チェックシートや提案書の「対応可能」が、契約上どこまで義務になるか整理したい

・ログ提出・保全・一次通知を期限付きで定義し、取引先照会に強くしたい

・SOC/MSP/再委託（海外SOC含む）を含め、主語が割れないRACIを作りたい

・追加費用・オプション範囲を明確にして、後から揉めない形にしたい

といったお悩みがあれば、オンライン（全国対応）でご相談を承っております。

お問い合わせの際に「対応可能の記事を見た」と書いていただけるとスムーズです。