LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

クラウド移行の設計と構築を、業務委託エンジニアにまとめて頼みたい。けれども、任せたあとに社内で何をすればよいのかがはっきりしない——。総務省のガイドラインは、クラウドの設定には、設定を直接行う人と、最終的な確認と設定の維持に責任を持つ人の2つの役が要るとしています。頼めるのは前者の作業で、後者の役は社内に残ります。

本記事では、クラウド移行のクラウド設計・構築を業務委託エンジニアに頼むマネージャーに向けて、総務省のガイドラインと内閣官房国家サイバー統括室のガイダンスをもとに、社内に残す役割を整理します。

設定者と設定管理者

総務省が2022年10月に公表した「クラウドサービス利用・提供における適切な設定のためのガイドライン」は、クラウドの設定ミスによる情報漏えいを防ぐための指針です。このガイドラインは、環境の設定を直接実施する者を「設定者」、「最終的な設定の確認を行い、また、正常な設定の維持に責任を持つ者」を「設定管理者」と呼んでいます。^*1

クラウド設計・構築を頼む場面に当てはめると、業務委託エンジニアが設定者、頼む側の会社が設定管理者です。ガイドラインは、利用者が動作環境の設定をシステムの構築を請け負う事業者（ガイドラインの呼び方ではSIer）に頼む場合について、「大きな意味では SIer が設定者、クラウドサービス利用者が設定管理者となる」と書いています。^*1

こうした頼み方は珍しくありません。ガイドラインはMM総研の2021年の調査を引いて、クラウドサービスを利用する企業等の約60%が、クラウドの運用支援の全部または一部を構築や運用を支援する事業者に委託していると紹介しています。^*1 頼むこと自体は自然な選択で、問題になるのは、設定管理者の役まで頼んだつもりになってしまうことです。

最終責任が社内に残る理由

ガイドラインは、構築を請け負う側は作業について責任を持ち、正しく環境の設定を行って利用者に引き渡す必要があるとしたうえで、発注者である利用者には管理・監督の責任があり、「最終責任はクラウドサービス利用者となる」と述べています。^*1 同じ総務省が2024年4月に出したガイドブックも、SI事業者の設定ミスによる事故が実際に起きていることに触れ、「SI事業者が行った設定であっても、最終的な責任は利用者が負うことになる」と書いています。^*2

内閣官房国家サイバー統括室のガイダンスも、同じ立場です。全ての設定や実装を利用者だけで行えるケースは少ないとしつつ、根本的な実装責任はクラウド事業者側の仕様変更などを除いて利用者にあり、外部の支援を受ける場合でも「より主体的に実装に携わらなければならない」としています。^*3

ガイドラインが挙げる設定ミスの事例には、業務委託先がサーバーからクラウドサービスへデータを移す際にストレージを公開の設定にしていて、長い期間にわたって機密情報が公開されていた、というものがあります。 クラウド移行の作業中に起きた事例です。ガイドラインは、こうした事例の要因の1つに、委託先の管理などの体制面の不備を挙げています。頼んだ作業の結果を社内で確かめる仕組みが要るのは、このためです。

責任分界の確かめ方

設定管理者として最初に確かめたいのは、クラウド事業者と自社の間の責任分界です。ガイドラインによると、利用者が責任を持つ範囲は、借りるサービスの形によって変わります。サーバーなどの基盤を借りる形（IaaS）では、利用者は仮想環境の上で動くOSを含めたすべてのソフトウェアを管理し、OSやミドルウェアの層での障害対応、ミドルウェアへのパッチの適用も利用者の責任です。 完成したソフトを借りる形（SaaS）であれば、利用者の責任はデータとアプリケーションの管理の一部になります。

実際の構成は、1つの形で済まないことがほとんどです。ガイダンスは、データベースはPaaS、WebサーバーはIaaS、認証の仕組みはSaaSというように、外から見て1つのサービスでも中身は複数の要素の組み合わせだと説明しています。複数の事業者のサービスを組み合わせた構成を外部の事業者が構築する場合でも、利用者には事業者ごとに責任範囲をはっきりさせ、理解することが求められるとしています。

そのため、クラウド設計・構築の最初の段階で、使うサービスごとに「事業者の責任」「自社の責任」「業務委託エンジニアに頼む作業」を一覧にしておくと、話が早くなります。一覧づくりは手伝ってもらえますが、決めるのは社内です。あわせて、利用規約の免責事項も読んでおきます。ガイドラインは、事業者との利用契約における免責事項を確かめることも、利用者が方針に含めておく内容の1つに挙げています。 契約の読み方に迷う点があれば、法務の担当や専門家に確かめてください。

設計の判断を誰がするか

設計の段階で社内が決めることは、大きく2つあります。1つは、何のためにクラウドを使い、どの形のサービスで何を動かすかです。ガイダンスは、組織としてなぜクラウドサービスを使うのか、目標や目的を明確にしてから最もふさわしいサービスを選ぶ、という順番を示しています。 もう1つは、既存のセキュリティの方針や規程と、クラウドの使い方が食い違わないかどうかです。

業務委託エンジニアには、設計案と、判断に使う材料をそろえてもらいます。ガイダンスは、外部の委託や支援を受けて実装する場合、クラウドサービスの設計思想などを実装の初期の段階から共に理解を深めることが望ましいとしています。 設計案を受け取るだけにせず、なぜその構成にしたのかを説明してもらう場を設けると、社内にも判断の筋道が残ります。

判断をする人は、名前で決めておきます。ガイダンスは運用の体制として、相談や連絡ができる窓口を把握したうえで、クラウドサービスを含むシステム運用の責任者を任命するよう求めています。責任者は、インシデントが起きたときにサービスの利用を止める判断や、重要な更新が生じたときの判断を担います。その下に、作業の指示や現場の監督を担う担当者を置きます。

構築作業の確認の仕組み

構築の段階では、業務委託エンジニアが行った設定を、別の目で確かめる仕組みを先に作っておきます。ガイドブックは設定ミスの対策として、「少なくとも設定をする人と、設定をチェックする人を置くことが必要です」と書いています。^*2 ガイドラインも、設定者と設定管理者によるダブルチェックの手順を作業手順に組み込み、チェックリストの形にして両者の証跡を残すことを勧めています。

設定の手順は、できるだけ文字にして残す形で頼みます。ガイドラインは、構築を請け負う事業者などに向けて、IaaSやPaaSの設定をIaC（インフラの構成をコードで書く手法）のツールなどでコード化し、レビューして繰り返し使うことを勧めています。コードで書かれていれば、社内の人が差分を見てレビューすることもできます。

管理者の権限の扱いも、ここで決めます。ガイドラインは特に重要な設定項目として、管理者や特権アカウントには多要素認証と複数人でのチェック体制をとり、特権アカウントの利用者や特権に昇格できるアカウントは最小限とするのが望ましいとしています。 構築の作業のために業務委託エンジニアへ管理者の権限を渡す場合は、作業が終わったあとにその権限をどうするかまで決めておきます。

ガイドラインは、構築を請け負う側から、セキュリティ事故を起こさないための設定について「責任分担やデフォルト値の設定変更の有無などについて説明を聞く」ことも挙げています。^*1 既定値から変えた設定を一覧で出してもらうと、確認が楽になります。

構築後の検証

構築が終わっても、すぐに本番で使い始めるのは避けます。ガイダンスは、構築者などが実装した環境が、クラウド事業者の提供する情報に基づいて適切に構築できているかを、利用者が主体となって検証するとしています。利用できる状況になったら直ちに使い始めるのではなく、オンプレミスのシステムと同じように検証の工程を設けるという考え方です。

検証は、できる限り第三者に頼むのが望ましいとされています。ガイダンスは、設定不備や脆弱性の診断、ペネトレーションテストなどによって、インシデントが起きない状態かどうかを確かめるとしています。 構築した本人の確認だけで終わらせず、別の目を入れると見落としに気づきやすくなります。

検証は一度で終わりではありません。クラウドサービスは事業者の側で定期的に仕様が変わるため、ガイダンスは運用の段階でも定期的に検証することが望ましいとしています。構築の契約が終わったあとに誰が見直しを担うのかも決めておきます。

引き継ぎで受け取るもの

クラウド移行の最後に待っているのが引き継ぎです。ガイドブックは、システムのことが分かるのが1人だけの状態の問題として、「その人が退職すると誰もシステムの設定を変更できなくなる」ことを挙げています。^*2 業務委託エンジニアは契約の期間が終われば離れるので、同じことが起こりやすい立場です。

受け取るものとして、まず手順書とコードがあります。ガイドラインは、環境の設定に関するノウハウの属人化を避けるため、共有と蓄積の方法をマニュアルにすることを勧めています。 構築に使った手順書、IaCのコード、既定値から変えた設定の一覧は、社内の保管場所に置いてもらいます。

次に、設定の理由です。ガイドラインは、設定後にチェックしても、設定者がなぜその設定にしたのか、理由や経緯を覚えていないことがあると指摘しています。 本人がいるうちに、主な設定ごとに「なぜそうしたか」を一言ずつ書き残してもらうと、後任が変更の判断をしやすくなります。

最後に、協議の記録です。ガイダンスは、利用者と運用者や構築者がサービスの更新などについて協議した内容や資料は議事録を残し、少なくともサービスを利用している間は保管し続けるよう勧めています。設計の打ち合わせで決めたことも同じように残しておきます。

外部に委託するときに確認しておきたい点

業務委託エンジニアを探す前に、社内の設定管理者を誰にするかを先に決めます。候補者に求める経験を書くときも、「設計案を出し、判断の材料を説明できる」「手順をコードで残せる」「引き継ぎの資料を作れる」のように、社内に残す役割と対にして書くと、頼む範囲が伝わりやすくなります。

移行の全体の計画は、クラウド移行の移行計画に書く6つの項目で、移行後に何を動かすかの決め方は業務委託エンジニアにクラウド移行を頼む前に社内で決める3つの点で整理しています。あわせてご覧ください。

まとめ：クラウド設計・構築で社内に残す3つの役割

クラウド移行でクラウド設計・構築を業務委託エンジニアに頼むとき、社内に残す役割は3つに整理できます。第一に、設定の最終的な確認と維持を担う設定管理者を社内に置き、事業者ごとの責任分界を確かめること。第二に、どのサービスの形で何を動かすか、いつ使い始めるかといった判断を社内の責任者が行い、構築した設定を別の目で確かめること。第三に、検証を終えてから使い始め、手順書やコード、設定の理由、協議の記録を受け取って引き継ぎを終えることです。任せる作業に合う人の探し方に迷いがあれば、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：総務省「クラウドサービス利用・提供における適切な設定のためのガイドライン」（2022年10月・PDF）（https://www.soumu.go.jp/main_content/000843318.pdf）。出典：総務省「クラウドサービス利用・提供における適切な設定のためのガイドライン」（2022年10月）。Ⅰ.2（ガイドラインの位置付け）、Ⅰ.6（用語の定義：設定者・設定管理者）、Ⅱ.1.2（IaaS・SaaSの設定における責任分界）、Ⅱ.1.3（IaaS等の設定をSIerに外部委託する場合）、Ⅱ.2.1（事例3）、Ⅲ.1.1.1、Ⅲ.1.4.1、Ⅲ.2.1.2、Ⅲ.2.1.3、Ⅲ.3.1.1、Ⅲ.3.2.1、Ⅲ.4.1.1、Ⅲ.4.3.1、Ⅳ.5.3を参照（確認日2026年9月29日）（2026年9月確認）
2. *2　参考：総務省「クラウドの設定ミス対策ガイドブック」（2024年4月・PDF）（https://www.soumu.go.jp/main_content/000944467.pdf）。出典：総務省「クラウドの設定ミス対策ガイドブック」（2024年4月）。「SI事業者と設定ミス」、体制の整備（設定をする人とチェックする人、「ひとり情シス」の問題）、マネージドサービスによるリスクの移転を参照（確認日2026年9月29日）（2026年9月確認）
3. *3　参考：内閣官房国家サイバー統括室「クラウドを利用したシステム運用に関するガイダンス」（令和7年7月1日・PDF）（https://www.cyber.go.jp/pdf/policy/infra/cloud_guidance.pdf）。出典：内閣官房国家サイバー統括室「クラウドを利用したシステム運用に関するガイダンス」（令和7年7月1日）。3.2のコラム（クラウドサービスの類型）、4.（冒頭）、4.1.3〜4.1.6（構築時の注意点）、4.2.1（体制）、5.1.1（利用者と運用者）を参照（確認日2026年9月29日）（2026年9月確認）

Tweet