Drupalサイトの管理会社へ渡す、モジュールと保守範囲の一覧

Drupalサイトの管理会社へ渡す、モジュールと保守範囲の一覧。この記事は2026年10月21日に確認できた公式情報を起点に、Drupalサイトの管理会社へ渡す、モジュールと保守範囲の一覧という疑問に答えるための確認手順を整理します。自社で対象か分からない項目は推測で埋めず、管理担当や提供元へ確認してください。

管理会社へ渡す情報の全体像と目的

一覧作成の基本要件は何か

対象モジュールとそのバージョン、保守範囲を明示した一覧は、抜け漏れ防止の第一歩です。まずはDrupal本体と利用中のコアモジュール、業務で必須と判断した追加モジュールを列挙し、各項目に「対象」「対象外」「保守対象」のタグを付けます。

タグ付けは、社内のシステム担当と管理会社の双方で合意した基準に沿って行い、後からの変更が容易になるようにします。さらに、一覧には作成日と最終更新日を記載し、定期的に見直すスケジュールを設定すると、バージョンアップや新規導入時の情報更新がスムーズになります。

経営者が確認すべき成果物の形態

成果物はPDFとExcelの二形態で用意すると、閲覧と編集の両方に対応できます。PDFは最終版として管理会社へ提供し、改ざん防止のために電子署名やページ番号を付与します。Excelは項目ごとにフィルタやコメントを付けられるため、社内でのレビューや追加要望の記録に便利です。

引き渡し手順としては、まずドラフト版を社内で確認し、修正点をまとめた上で最終版を作成します。その後、管理会社へメールで送付し、受領確認と合わせて「受領証明書」や「確認メール」の写しを保管しておくと、後日のトラブル防止につながります。

管理会社に期待する保守範囲の範囲設定

保守範囲は「障害対応」「パッチ適用」「定期点検」の３つに分けて整理すると、担当者が何をすべきかが見えやすくなります。ただし、復旧までの時間目標や責任者への連絡先を一律に決めてしまうと、実際のシステム構成や利用状況に合わないことがあります。まずは、現在の障害対応フローや連絡体制を担当者に確認し、どのようなケースでどの部署が関与するかを把握してください。

パッチ適用については、誰が責任者か、適用後にどのような報告を求めるかを事前に合意しておくと、作業の透明性が保たれます。そこで、担当者に「パッチ適用の担当者は誰か」「適用完了時に提出してほしい資料は何か」を具体的に聞き、過去に同様の作業を行った記録があるかどうかも確認してください。

定期点検は、チェック項目やレビューの頻度を決めることで継続的なセキュリティ維持につながりますが、項目を過度に細分化すると負荷が高くなる恐れがあります。担当者には「現在実施している点検項目は何か」「レビュー会議の参加者と開催頻度はどのように設定しているか」を質問し、実務に即した範囲で調整できるよう情報を集めてください。

対象モジュールの選定と除外基準

必須モジュールと任意モジュールの区別方法

必須モジュールはDrupalコアが提供する機能や、業務フローに直結するものを指します。たとえば、ユーザー管理やコンテンツタイプ、ビューなどは多くのサイトで不可欠です。一方、任意モジュールは装飾的な機能や、過去に一時的に利用したが現在は不要なものです。

区別の基準としては「業務上の必須要件」「利用頻度」「開発・保守の継続性」の三点をチェックリスト化し、社内の担当者と管理会社が共同で評価します。除外例としては、開発が停止しているモジュールや、ライセンスが不明確でサポートが受けられないものが挙げられます。

バージョン情報の正確な取得手順

バージョン情報の取得方法については、実際にどの手段で確認できるかを担当者に確認する必要があります。まず、管理画面のどこでバージョン一覧が表示されるか、またはコマンドラインを利用する場合にどのような手順が用意されているかを担当者に尋ねてください。

その際、取得した情報をどのように記録し、誰がいつ取得したかを明確に残す方法についても確認しておくと、後日の監査や変更履歴の確認がスムーズになります。

具体的に担当者に聞くべきことは次のとおりです。
・現在利用しているシステムでバージョン情報を確認できる画面やコマンドはどこか。
・取得した情報を正式に記録する際に必要な項目（取得日時や取得者の氏名など）は何か。
・取得したデータの保管方法や、監査時に提示できる形態はどのようにすればよいか。

これらの質問を通じて、実際に利用できる手段と記録の取り方を把握し、根拠のある情報として管理できるようにしてください。なお、具体的な操作手順や数値は公式のマニュアルや担当者の説明に基づいて確認することが重要です。

除外対象となるサードパーティモジュールの例外条件

除外対象は、サポートが終了しているもの、ライセンスが商用で追加費用が発生するもの、または既知の高リスク脆弱性が報告されているものです。JPCERT/CCの週報で指摘されたモジュールは、まず脆弱性情報を確認し、修正パッチが提供されていない場合は除外の検討材料とします。

また、開発元が明示されていないモジュールや、利用実績が極めて少ないものも、保守コストの観点から除外対象とすることが一般的です。除外の判断は、リスク評価シートに根拠を記載し、管理会社と合意したうえで一覧に「除外」マークを付けて管理します。

保守範囲の具体的項目と担当者への質問例

パッチ適用の責任分担は誰か

Drupal の脆弱性情報（例：2026‑10‑21 の JPCERT/CC 週報）では、修正済みバージョンへの更新が推奨されています。まず、管理会社に対して「脆弱性が報告されたモジュールのパッチ適用は、どのフェーズで実施し、完了をどのように証明しますか？」と確認してください。

適用手順書や適用後のバージョン情報のスクリーンショットを提出してもらうことで、経営者側でも適用の有無を客観的に判断できます。さらに、適用作業の責任範囲（テスト環境での検証、ステージングへの反映、本番へのデプロイ）を文書化し、合意した上で契約書に明記しておくと、後日のトラブル防止につながります。

障害時の連絡フローとエスカレーション先

脆弱性が悪用された場合や、パッチ適用後に不具合が生じた際の対応は、事前にフローを定めておくことが重要です。管理会社に「障害が発生した際の一次連絡窓口は誰か、対応開始までの目安時間はどれくらいか」を質問し、緊急時の連絡先（電話・メール）と責任者への連絡先（上位担当者や外部提供元）を一覧化してください。

報告書のフォーマット（障害概要、影響範囲、対応経過、再発防止策）も合わせて提示してもらうと、経営者が進捗を把握しやすくなります。定期的にテスト連絡を実施し、実際にフローが機能するかを確認することも忘れないでください。

定期点検項目と結果のレビュー方法

日常の管理方法を見直す際は、利用版の確認や必要な検査を、実際の構成と業務への影響に合わせて担当者と計画します。ここではJPCERT/CCが特定の点検頻度や方法を定めたと説明するものではありません。

管理会社に対しては「月次／四半期ごとの点検項目（ログ監視、使用モジュールのバージョン確認、脆弱性スキャン結果）と、結果をどのように報告するか」を具体的に質問し、報告書のテンプレートを受領してください。

レビュー会議は、点検結果を経営者が確認できる形で、例えば 30 分程度のオンラインミーティングで実施し、課題と改善策を議事録に残すと効果的です。点検項目が抜けていないか、スキャンツールのバージョンが最新かも併せて確認しましょう。

引き渡し後の検収と失敗時の対処策

納品物の検収チェックリスト作成手順

管理会社から受け取る一覧や保守計画書は、検収チェックリストで体系的に確認します。まず、チェックリストに「モジュール名・バージョン」「保守範囲の記載」「パッチ適用証明書」「点検報告書」の項目を設け、各項目に対して「完了」「未完了」のステータスと担当者署名欄を用意してください。

未達項目があれば、具体的な再作業依頼と期限を明示したメールを送付し、相手の回答を記録します。チェックリストは PDF で保存し、社内のリスク管理フォルダに保管すると、後日の監査にも対応できます。

保守範囲外の作業が発生した場合の対応

保守契約に含まれない作業（例：サードパーティモジュールの新規導入や大規模カスタマイズ）が必要になった際は、まず「追加作業の見積もり依頼」と「作業開始前の合意取得」のプロセスを確認してください。管理会社に対しては「作業内容、工数、費用、納期」を明示した見積書を提出してもらい、社内の承認フローを経て正式に発注します。

合意書には、作業範囲と費用上限を明記し、予算超過を防止する仕組みを組み込みましょう。

検収失敗時の再委託・契約見直しポイント

検収で不備が残った場合は、再委託や契約見直しの条件を事前に整理しておくとスムーズです。管理会社に「再作業の期限」「違約金の有無」「次回契約時の改善項目」を質問し、書面で合意します。期限内に修正が完了しない場合は、別の提供元への再委託も検討できるよう、予備の業者リストを用意しておくと安心です。

契約更新時には、今回の教訓を踏まえて保守範囲や評価基準を見直し、次回以降のリスクを低減させる方策を盛り込んでください。