LASSIC Media らしくメディア

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

既存のアプリケーションをコンテナに載せ替えてクラウドへ移したいが、社内にその経験がない。業務委託エンジニアに頼むとして、何をどこまで任せればよいのか分からない——。クラウド移行を控えた開発の現場では、こうした迷いが起こりがちです。クラウド移行でのコンテナ化とは、アプリケーションをライブラリなどの実行環境ごと1つの単位にまとめ、クラウドの上で動かしやすい形に作り替えることを指します。

コンテナにしておけば、同じ中身をどの環境でも動かせ、負荷に応じて台数を増やす仕組みも使えます。ただし万能ではなく、今のアプリケーションをそのまま詰め込んだだけでは、その良さはほとんど生かせません。本記事では、業務委託エンジニアを迎えてコンテナ化を進める開発マネージャーに向けて、コンテナ化で変わる作り方、任せる前にそろえる条件、社内に残す判断、レビューの体制、面談で確かめたい経験、そして外部に委託するときに確認しておきたい点を整理します。

クラウド移行でのコンテナ化とは

考え方の整理に使えるのが、デジタル庁が公開している「GCASガイド」です。国や自治体のシステムが使うクラウド基盤（ガバメントクラウド）の利用者に向けた技術資料で、その中の「ガバメントクラウドにおけるモダン化の定義」は、2025年2月14日に作られ、2025年6月27日に全体が見直されています。国の資料ですが、移すときに何を作り替えるのかの整理は民間でも使えます。

この資料は、モダン化（いまの技術に合わせた作り替え）の中身を5つに分けています。APIベースのシステム構成、ステートレスなアーキテクチャ、マネージドサービスの活用、運用のコード化と自動化、サービスレベルの定義と計測です。コンテナは2つ目のステートレスなアーキテクチャの中で扱われ、「ソフトウェアのバイナリだけでなく、ライブラリなどの実行環境を含めてパッケージングする技術」と説明されています。^*1

移行の型も2つ挙げられています。R1（Replatform、実行基盤の載せ替え）では、5つのうちマネージドサービスの活用を原則として求めます。R2（Rebuild、作り直し）では、5つすべての実現を求めます。^*1 どちらの型かで、業務委託エンジニアに頼む作業の量は大きく変わります。

コンテナに入れるだけでは済まない理由

コンテナ化というと、今のサーバーで動いているアプリケーションを丸ごとイメージ（コンテナの元になるファイル）に固めることだと考えがちです。しかしGCASガイドは、コンテナの価値を生かすための条件を2つ挙げています。ステートレス（状態を持たない）にすることと、イミュータブル（作ったあとに中身を変えない）にすることです。

ステートレスにするとは、ログイン中の利用者の情報（セッション情報）や、環境ごとに違う設定をイメージに含めないことです。セッション情報はコンテナの外に保存し、接続先などの環境ごとの設定は、コンテナを起動するときに環境変数で渡します。こうすれば、どのコンテナで処理しても同じ結果になり、1つが止まっても利用者の情報は失われません。

イミュータブルにするとは、動いているコンテナの中で直さないことです。バージョンアップやパッチの適用が必要なときは、「コンテナイメージを再ビルドしてコンテナを作り直す」とされています。^*1 この2つがそろうと、同じイメージを検証環境と本番環境の両方で使えます。CI/CD（変更を自動で検証し反映する仕組み）でのデプロイや、負荷に応じたコンテナの追加と削除もしやすくなります。

動かし方も変わります。ガイドは、コンテナを「dockerコマンドではなく、クラウドの機能またはマネージドのコンテナオーケストレーションツールで管理、運用する」としています。^*1 オーケストレーションツール（多数のコンテナをまとめて動かす仕組み）には、負荷に応じてコンテナを増減する機能と、止まったコンテナを自動で回復させる機能があります。コンテナ化は、動かし方まで含めた作り替えです。

任せる前にそろえる5つの条件

業務委託エンジニアに作業を頼む前に、社内で次の5つを決めておくと、参画の初日から作業に入ってもらいやすくなります。

1つ目の移行の型については、ガイド自身が、移行するときに「すべての項目を完全に満たす必要があるわけではない」と断っています。^*1 今回の移行でどこまでを求め、どこからを次の更新の機会に回すのかを書き出しておけば、業務委託エンジニアから出てくる提案も比べやすくなります。

3つ目の反映の方法は、運用の資料である「運用モダン化実践ガイド」が詳しく扱っています。初期構築のときだけIaC（インフラの構成をコードで書いて自動で作る方法）を使い、その後の変更を手作業で行うやり方について、ガイドは「この方式は選択すべきでない」と書いています。^*2 コードと実際の環境が食い違い、コードが設計書として使えなくなるためです。勧められているのは、変更をすべてコードで管理し、反映もCI/CDのパイプラインで自動で行う形です。

社内に残す判断

作業を任せても、決めるのは社内です。モダン化の定義の5つ目にあるサービスレベルは、その代表です。ガイドは、サービスの価値をKPI（成果を測る指標）として定義し、稼働率を99.5％にするといった計測できる値をサービスレベルとして決める例を示しています。^*1 何をどこまで守るかは事業の判断なので、業務委託エンジニアには、決めた値を測れる形に作ってもらいます。

サービスを止めてよいかの判断も社内に残ります。ガイドは、止めずにリリースできるデプロイの方式はコストが増える場合もあるとし、決めたサービスレベルの範囲でサービスの停止を許容する判断も必要だとしています。夜間に数分止めてよいかで、組む仕組みも費用も変わります。

障害が起きたときの分担も、先に決めておきます。運用モダン化実践ガイドは、国の職員と委託先の事業者の分担として、「職員は外部ステークホルダーとのコミュニケーションを、事業者は技術的な原因究明と復旧を担い」と書いています。^*2 委託先は契約の範囲で動くので、発注する側と全く対等な目線で動くことは「本質的に困難である」とも指摘しています。^*2 利用者や取引先への連絡は社内、原因の調査と復旧は業務委託エンジニア、という分け方は民間でもそのまま使えます。

コードレビューの体制

コンテナ化とIaCを進めると、インフラの設定もアプリケーションと同じようにコードとして書き、レビューしてから反映する流れになります。運用モダン化実践ガイドは、最小の構成として、コードを書いて説明する実装者と、内容を確かめて問題を指摘するレビュアーの2つの役割を挙げています。そのうえで、「少なくとも2名以上のレビュアーを確保し相互にレビューできる体制を整えることが望ましい」としています。^*2

業務委託エンジニアが実装者になるなら、レビュアーのうち少なくとも1人は社内に置いておきたいところです。全員が委託先の人だと、契約の終了とともに中身を説明できる人がいなくなります。社内の担当者がIaCに慣れていなくても、レビューで変更の理由を聞いていれば、どの設定がどこにあるかは分かるようになります。

機械で確かめられるものは、道具に任せます。ガイドは、プルリクエスト（変更の取り込み依頼）を作ったときにパイプラインで静的解析を走らせ、問題がないときだけ取り込みを認める運用を勧めています。人は、要件との整合や費用への影響など、道具では判断できない点を見ます。

面談で確かめたい経験

コンテナ化を任せる業務委託エンジニアを選ぶときは、使ったことのある道具の名前より、作り替えのどの部分を自分で決めたかを聞くほうが、経験の中身をつかめます。たとえば、セッション情報をどこに移したのか、その理由は何だったのか。環境ごとの設定を、どの段階で、どうやってコンテナに渡したのか。脆弱性の修正が出たとき、本番への反映までをどう進めたのか、といった質問です。

IaCについては、構築のあとに誰かが手で設定を変えてしまったとき、コードとの食い違いをどう見つけて直したかを聞きます。手作業とコードが混ざった環境を経験し、それを元に戻した話ができれば、運用まで考えて作った経験があると判断しやすくなります。

引き継ぎの経験も確かめます。運用モダン化実践ガイドは、IaCを使うと「IaCソースコード自体が最新の設計書として機能する」としています。^*2 一方で、その設定を選んだ理由や制約はコードだけでは表しにくいため、コードの中のコメントや同じリポジトリの文書に残すよう勧めています。前の案件で設計の理由をどこに書き残したかを聞けば、引き継ぎのときに何を受け取れるかが見えてきます。

つまずきやすい点

一つめは、イメージに設定を入れたまま作ってしまうことです。接続先のアドレスやパスワードをイメージに書き込むと、検証用と本番用で別のイメージが要り、同じイメージを両方で使う利点がなくなります。途中で一度、イメージに環境ごとの値が入っていないかを確かめてもらいます。

二つめは、知識が1人に集まることです。IaCのコードもコンテナの設定も、書いた人にしか分からない状態になりがちです。社内のレビュアーを置き、変更はすべてプルリクエストを通す決まりにすれば、誰がいつ何を変えたかが残ります。

三つめは、すべてを自動にしようとすることです。運用モダン化実践ガイドは、「実施頻度が極めて低い場合」や技術的な制約がある場合などは、自動化に要る開発と保守の費用が手作業の費用を上回ることがあるとして、慎重に判断するよう書いています。^*2 年に数回の作業まで自動化を頼むと、契約の期間がそれに消えます。

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

業務委託エンジニアを探し始める前に、コンテナ化する対象のアプリケーション、今回の移行の型、本番への反映の方法の3つを書き出しておきます。面談で聞く質問もそろえておけば、候補者どうしを比べやすくなります。

移行の前に社内で決めておく点は業務委託エンジニアにクラウド移行を頼む前に社内で決める3つの点で扱っています。

移行計画書に書く項目は業務委託エンジニアと進めるクラウド移行、移行計画に書く6つの項目にまとめました。

設計と構築の分担は業務委託エンジニアとクラウド移行、クラウド設計・構築の役割分担で整理しています。

まとめ：コンテナ化で確かめておきたい3つの点

業務委託エンジニアとクラウド移行のコンテナ化を進めるうえで、確かめておきたい点は3つに整理できます。第一に、セッション情報と環境ごとの設定をイメージの外に置き、修正はイメージの作り直しで反映する作り方を作業に含めること。第二に、構築のあとの変更もIaCとCI/CDで反映する形にし、本番に人が入らずに済む運用で受け取ること。第三に、コードのレビューに社内の担当者が加わり、2名以上で確かめる体制を作ることです。この3点を踏まえておけば、「コンテナにはなったが、中身を説明できる人が社内に誰もいない」という事態を避けやすくなります。任せる作業に合う人の探し方に迷いがあれば、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：デジタル庁 GCASガイド「ガバメントクラウドにおけるモダン化の定義」（https://guide.gcas.cloud.go.jp/modernization-guide/modernization-definition/）。出典：2025年2月14日新規作成、2025年6月27日改訂。「ガバメントクラウドにおけるモダン化の定義」の5項目とR1・R2、「2. ステートレスなアーキテクチャ」の「コンテナを活用する」「オートスケールを活用する」、「3. マネージドサービスの活用」、「4. 運用のコード化、自動化」、「5. サービスレベルの定義、計測」を参照（確認日2026年10月8日）（2026年10月確認）
2. *2　参考：デジタル庁 GCASガイド「運用モダン化実践ガイド」（https://guide.gcas.cloud.go.jp/modernization-guide/operations-modernization-guide/）。出典：2026年2月 1.0版。1.2.1「本ガイドが目指す運用の進化」、2.2.2「職員と事業者の責任共有の重要性」、3.2.2「Zero Touch Productionの実現アプローチ」、3.2.3「緊急時ログインの実装例」、3.3.1「IaC化の目的」、3.3.2「パラメータシート運用からの脱却」、3.3.4「IaCのコードレビューとチーム構成」、3.3.5「IaCの活用レベルとデプロイ方式」を参照（確認日2026年10月8日）（2026年10月確認）

Tweet