AWS移行エンジニアを業務委託で確保する方法｜移行方式別の人材要件

データセンターの契約満了やサーバー機器の保守終了（EOSL）が迫り、「業務システムを AWS へ移す」という方針だけが先に決まってしまう。よくある状況です。ところが社内を見渡しても AWS の移行実務を経験した人はおらず、移行支援ベンダーからの一括委託見積は予算を大きく超えている。正社員として採用しようにも「移行が終わった後、その人には何をしてもらうのか」という問いに答えられず、稟議が止まってしまう。

そこで残る選択肢が業務委託です。必要な期間だけ、必要なスキルを持つ人に入ってもらう。理屈としては最も自然に見えます。しかし手を動かそうとすると、募集要項の一行目から止まります。「AWS の移行ができる方」と書いたところで、応募してくる人のスキルが自社の移行に合っているかどうかを、社内の誰も判定できないからです。

そして、もう一段深いところに本当の不安があります。それは、移行が終わった瞬間に委託先がいなくなり、社内には「動いてはいるが誰も中身を説明できない AWS 環境」と、それを運用し続ける責任だけが残ることです。障害が起きても原因を追えない。コストが膨らんでも何を削ればよいか分からない。次の改修を頼もうにも、引き継げる資料がない。移行そのものは成功したのに、その後の数年間ずっと苦しむことになります。

この事態を防ぐ手段は、移行後の努力ではありません。発注する時点で条件として書いておくことにしかありません。逆に言えば、AWS の実務経験がなくても、何を条件として書けばよいかさえ分かっていれば、外部人材を使った移行体制は組めます。

本記事では、AWS移行を業務委託で進めるにあたり、移行方式（7R）から人材要件を導く方法、フェーズごとに変わる稼働と成果物、社内に AWS 経験者がいない状態でのスキルの見極め方、契約形態と委託先の選び方、人件費だけでは足りない費用の見方、外部エンジニアに渡す権限の絞り方、そして移行完了後に社内へ知識を残すための発注条件までを、発注する側の判断材料として順に整理します。

AWS移行エンジニアの人材要件は「移行方式」を決めないと固まらない

AWS移行 エンジニアの募集で最初につまずくのは、「どんなスキルの人が必要か」を書けないことです。しかしこれは、AWS の知識がないから書けないのではありません。移行方式が決まっていないから書けないのです。

同じ「AWS への移行」でも、既存のサーバーをそのまま持っていくのか、データベースをマネージドサービスに載せ替えるのか、アプリケーションごと作り替えるのかで、必要なスキルはまったく別物になります。方式が未決のまま募集をかけると、応募者ごとに得意領域がバラバラで比較できず、結果として「一番幅広くできそうな人」を高い単価で採る、という判断に流れがちです。

まずは方式の全体像を押さえ、自社がどの範囲に寄るのかを仮決めするところから始めます。

AWS移行の7R（6R）と、それぞれで必要になるスキルの違い

AWS は移行戦略を 7 つに分類しています（従来は 6R と呼ばれていた分類に Relocate が加わったものです）。AWS 規範ガイダンス「移行戦略について」では、Retire・Retain・Rehost・Relocate・Repurchase・Replatform・Refactor の 7 戦略が定義されています。

これを技術解説としてではなく、「どの人を探すかの分岐」として読み替えると次のようになります。

この表から読み取ってほしいのは、次の点です。

• リホスト・リロケート中心の移行では、AWS の高度な設計力よりも「既存環境を正確に把握し、止めずに運び切る」力が主役になります。オンプレのネットワークやミドルウェアの知識を持つ人が、AWS の移行ツールを扱えるようになっているタイプが適任です
• リプラットフォーム以上になると、AWS のマネージドサービスをどう組むかという設計判断が入り、さらにアプリケーション側に手を入れる判断も必要になります。ここから必要な人材のレイヤーが一段上がり、単価も上がります
• リパーチェス・リタイアは、実は AWS のスキルをほとんど必要としません。ここに含まれるシステムが多いのに AWS エンジニアを厚く発注すると、単純に費用の無駄になります

つまり、20〜30 本の業務システムを一律に「AWS 移行」と括るのではなく、システムごとにどの R に振り分けるかを先に決める。この振り分け作業そのものが、実は最初に外部へ頼むべき仕事です。AWS も、6R 移行戦略の選択は一度で確定させず繰り返し見直すものとしており、最初から完璧に決め切る必要はありません。

自社の移行方式を仮決めする3つの問い

AWS の実務経験がなくても、次の 3 つの問いに答えれば、方式の当たりはつきます。稟議前の段階では、この精度で十分です。

問い 1: 期限まであと何ヶ月あるか

EOSL やデータセンター契約満了で期限が固定されている場合、選べる方式は自動的に絞られます。残り 12 ヶ月を切っているなら、アプリケーションに手を入れる方式（リファクタリング）を全システムで採るのは現実的ではありません。まずリホストで確実に移し、最適化は移行後に回す、という順序が基本形になります。期限が動かせない以上、方式を欲張ることが最大のリスクです。

問い 2: そのシステムのソースコードに手を入れられるか

自社で改修できる、あるいは開発ベンダーの保守契約が生きているシステムは、リプラットフォームやリファクタリングの候補になります。一方、開発元が撤退している、ソースコードが手元にない、改修すると保守サポートが切れる、といったシステムは、事実上リホストかリテインしか選べません。この判定は AWS の知識がなくても社内で行えます。

問い 3: OS・ミドルウェアのサポート期限とライセンスはどうなっているか

移行対象の OS が既にサポート切れ間近であれば、そのまま持っていっても数ヶ月後に同じ問題が再発します。この場合はリプラットフォーム（OS やミドルウェアのバージョンを上げる）を検討する必要があります。また、商用ミドルウェアやデータベースのライセンスがクラウド上での利用を許諾しているかどうかは、移行方式を左右する大きな条件です。ライセンス条項の確認は法務・調達部門と進められる作業で、ここも AWS の知識は不要です。

この 3 問への回答をシステム一覧に書き込むだけで、「リホスト中心・一部リプラットフォーム・数本はリタイア」といった全体像が見えてきます。募集要項に書くべき人材要件は、この全体像から逆算して初めて決まります。

クラウド移行の人材不足のなかで、正社員採用・ベンダー一括委託・業務委託をどう使い分けるか

クラウド移行 人材不足は、自社だけの問題ではありません。IPA の調査では、DX を推進する人材の量について不足を訴える企業が 8 割を超える状態が数年にわたって続いています（IPA「DX動向2026」）。クラウド分野に限っても、人材の獲得競争は継続的に報じられています（日経クロステック「クラウド人材が足りない！採用・育成・転身」）。

つまり、「AWS移行の実務経験がある人を正社員で採用し、期限までに育て上げる」という前提が最初から成立しにくい環境にあります。そのうえで 3 つの選択肢を並べると、次のようになります。

注目してほしいのは、いちばん右下のマスです。業務委託は「知見が残らない選択肢」ではなく、「契約条件しだいで残りもするし残りもしない選択肢」です。ここを発注時に設計するかどうかが、移行後の数年を分けます。この点は本記事の後半で具体的な条件に落とし込みます。

現実的な組み方としては、次の形が多くの企業に当てはまります。

• 移行方式の決定と全体設計 → 経験豊富な人材にスポットで（週 1〜2 日など）
• 移行作業そのもの → 移行の山にあわせて稼働を厚くする
• 移行後の運用 → 社内メンバー＋必要に応じたスポット契約

つまり、常に同じ人数を張り付ける発注ではなく、フェーズごとに輪郭を変える発注です。次に、そのフェーズの分け方を見ていきます。

AWS移行の進め方をフェーズに分けると、必要な人材と稼働が変わる

AWS 移行 進め方を考えるとき、移行を 1 本のプロジェクトとして丸ごと外部に発注しようとすると、必ず 2 つの問題が起きます。ひとつは、まだ何を移すか決まっていない段階で総額を見積もらせるため、リスク分が上乗せされて高くなること。もうひとつは、契約の終点が「移行完了」に設定されるため、その後が設計から抜け落ちることです。

AWS 自身は、移行プログラムを 3 つのフェーズに分けて整理しています。AWS Migration Acceleration Program（MAP）では、評価（Assess）・準備（Mobilize）・移行とモダナイズ（Migrate & Modernize）の 3 段階が定義されています。この区分をそのまま発注の単位として使うと、フェーズごとに必要な人材・稼働・成果物が違うことが見えてきます。

同じ「AWS 移行エンジニア」という言葉で括られていても、評価フェーズで欲しい人と、移行フェーズで欲しい人は別の人です。そして、フェーズごとに稼働の必要量がまったく違います。これを 1 本の契約で平準化すると、評価フェーズでは人が余り、切替の週には人が足りない、という状態になります。

評価フェーズで必要な人材と、成果物として受け取るもの

評価フェーズの目的は、移行そのものではなく「移行の設計図を作ること」です。ここで必要なのは、手を動かす人よりも、全体を描ける人です。

具体的には、次の 3 つを成果物として受け取ります。

1. 現行資産の一覧: サーバー・データベース・ミドルウェア・連携先・利用部門・稼働時間帯・依存関係。ここが曖昧なまま移行に進むと、必ず「移行後に動かないシステム」が出ます
2. システムごとの移行方式の割り当て: 前述の 7R のどれを適用するかの一覧。リタイア候補・リテイン候補を明示させることが重要です
3. 概算コストの試算: 移行後の AWS 利用料の見込みと、移行作業そのものの工数見積

このフェーズは週 1〜2 日のスポット稼働でも成立します。棚卸しの一次情報は社内にしかないため、外部エンジニアは「何を聞き出し、どう分類するか」を担い、情報収集そのものは情シスと利用部門が行う、という分担が現実的だからです。

そして、評価フェーズだけを先に切り出して発注することには、もうひとつ大きな意味があります。この成果物が手に入れば、その先の工程を発注するときに「何を、いくつ、どの方式で移すのか」を明示して見積を取れるようになります。相見積の精度が上がり、リスク上乗せ分が減ります。

準備・移行フェーズに必要な人材と稼働の山

準備フェーズでは、AWS アカウントの構成、ネットワーク（オンプレとの接続を含む）、権限、ログ、バックアップといった土台を作ります。ここは移行対象のシステムが何本あっても一度作れば共通で使えるため、少人数の構築層で進められます。

一方、移行フェーズは稼働の山が来ます。特に注意すべきは切替（カットオーバー）です。切替は業務を止めて行うことが多く、夜間や休日に集中します。切替当日は、作業者だけでなく、動作確認を行う利用部門、判断を下す責任者、そして問題が起きたときに切り戻しを実行できる人が同時に必要です。

発注設計としては、次の 2 点を条件に含めておきます。

• 切替の実施回数と実施時間帯を契約に明記する。「移行作業一式」ではなく、「切替を◯回、うち夜間帯を◯回」という単位で稼働を握る
• 切り戻し（ロールバック）の判断基準と手順を、切替前の成果物として提出させる。切り戻しの計画がない切替は、失敗したときに現場の即興判断に委ねられます

移行作業そのものには、AWS の移行ツールを使います。サーバーの移行には AWS Application Migration Service、データベースの移行には AWS Database Migration Service（AWS DMS）、複数システムの移行状況の可視化には AWS Migration Hub が用意されています。発注側がこれらを使いこなす必要はありませんが、「どのツールを使い、なぜそれを選んだのか」を説明できる人かどうかは、後述する見極めの重要な材料になります。

AWSの運用保守は委託し続けるのか、社内に戻すのか

多くの発注が空白のまま放置するのが、移行後の運用フェーズです。しかし AWS 運用保守 委託の方針は、移行の発注設計と同時に決めておかないと、移行完了の直前に慌てて決めることになります。

判断は、次の 2 軸で整理できます。

• 委託し続ける: 監視・障害一次対応・パッチ適用・バックアップ確認などを外部に任せる。社内の負荷は下がるが、環境の中身は社内に蓄積しにくい
• 社内に戻す: 移行と並走して社内メンバーが操作を覚え、平常運用は自社で回す。負荷は上がるが、コストと環境の主導権を握れる

現実には、この二択ではなく「一次対応は社内、設計変更や障害の深掘りはスポットで外部」という中間形を取る企業が多くなります。AWS の運用保守を外部に委託する場合、料金体系は月額固定型・AWS 利用料の一定割合を支払う割合型・対応時間に応じた従量課金型などがあり、割合型では利用料の 5〜20% 程度が目安として示されています（cloudpack「AWS 保守費用の相場は？」）。割合型を選ぶ場合、AWS 利用料が増えると保守費も連動して増える点は、稟議段階で押さえておく必要があります。

継続的な委託とスポット発注をどう使い分けるかは、移行に限らず外部人材の活用全般で判断が分かれるところです。移行後の体制を決める段階では、稼働の連続性と、社内に残したい知見の量から逆算して選ぶことになります。

社内にAWS経験者がいなくてもAWS移行のスキルを見極める方法

ここからが実務の中核です。社内に AWS の実務経験者がいない状態で、応募者や委託先候補のスキルをどう判定するか。

結論から言えば、「AWS の知識で判定しよう」とするのをやめることです。評価者に AWS のドメイン知識がない以上、技術的な深さを直接測ることはできません。代わりに、資格で担当範囲の当たりを付け、経歴の数字で経験の厚みを測り、面談では回答の具体性を見る。この 3 段構えなら、AWS 未経験の評価者でも判定が成立します。

AWS認定資格（SAA・SOA・SAP・DOP・SCS）と任せられる業務範囲の対応表

AWS 認定資格 SAA をはじめとする AWS 認定は、「この人が優秀かどうか」を測る道具ではありません。「この人がどの業務範囲の語彙を持っているか」を推定する道具として使います。

なお SysOps Administrator – Associate は CloudOps Engineer – Associate へ名称が刷新されており、職務経歴書に旧称で記載されているケースもあります。同じ資格として読んで差し支えありません。

そのうえで、資格で判断できないことをはっきりさせておきます。

• 移行の実務経験の有無: 認定資格は AWS 上での設計・運用を検証するもので、「オンプレから止めずに移し切った経験」を保証しません
• 業務システムやオンプレ環境への理解: 既存の業務システムの癖、社内ネットワークの制約、利用部門との調整といった要素は資格の範囲外です
• ドキュメントを残す姿勢: 移行後に社内へ知識が残るかどうかを最も左右する要素ですが、資格とは無関係です

したがって資格は「足切り」でも「決め手」でもなく、面談で何を深掘りすべきかを決めるための入口として扱うのが適切です。

「AWSの構築経験」と「移行経験」は別物｜職務経歴書で確認する3つの数字

発注側にとって決定的に重要なのがこの区別です。「AWS で環境を構築した経験」と「既存システムを AWS へ移行した経験」は、まったく違うスキルです。

新規に環境を作る仕事は、白紙の上に理想を描けます。制約は予算と要件だけです。一方、移行は違います。今動いているシステムを、業務を止めずに、想定外の依存関係を抱えたまま、期限までに運び切らなければなりません。求められるのは設計の美しさではなく、「想定外が起きたときに戻せるか」という段取りの力です。

AWS の知識がなくても、職務経歴書から次の 3 つの数字を拾えば、移行経験の厚みは推し量れます。

数字 1: 移行したサーバー・データベースの本数

「AWS 移行案件に従事」とだけ書かれている場合、担当したのが 2 本なのか 50 本なのかで意味がまったく違います。本数が書かれていなければ、面談で必ず聞きます。本数が多いほど、移行を「作業」ではなく「反復可能な手順」として組み立てた経験がある可能性が高くなります。

数字 2: 切替（カットオーバー）を何回実施したか

移行案件に参加していても、設計だけを担当し、切替の当日に立ち会っていない人もいます。切替は移行で最も緊張度が高く、最も学びが多い場面です。実施回数がゼロなら、その人は移行の「本番」を経験していないことになります。

数字 3: 切り戻し（ロールバック）を実行した経験があるか

これは「失敗経験があるか」を聞くための質問ではありません。切り戻しを実行したことがある人は、切り戻せる計画を作る癖がついているからです。逆にこの経験がない人は、切り戻しを机上の手順としてしか知らない可能性があります。

この 3 つは、AWS の技術用語を一切使わずに確認できます。職務経歴書に書かれていなければ、書類選考の段階で追記を依頼しても構いません。

面談でそのまま使える質問と、回答の良し悪しの見分け方

面談では、次の 3 問をそのまま使えます。いずれも、評価者が AWS を知らなくても良し悪しを判定できるよう設計されています。判定の軸は、数字・固有名詞・自分の判断が回答に含まれているかです。

質問 1: 「直近の移行案件では、どの移行ツールを使いましたか。なぜそれを選んだのですか」

• 良い回答の例: ツール名を挙げたうえで、「対象が Windows Server で、アプリに手を入れられなかったのでこのツールを選んだ」「データベースだけは別のツールで移した。理由は◯◯」というように、選択肢と選定理由がセットで出てくる
• 注意したい回答: ツール名は出るが、選んだ理由が「一般的だから」「使い慣れているから」に終始する。あるいは案件ごとに使い分けた形跡がない

質問 2: 「許容できるダウンタイムはどうやって決めましたか」

• 良い回答の例: 「利用部門にヒアリングして、月末処理の時期を避けた」「◯時間までなら業務が止まっても回せると確認した」など、業務側との調整プロセスが語られる。技術の話ではなく調整の話が出てくることが重要です
• 注意したい回答: 「なるべく短くしました」「深夜にやりました」で終わる。ダウンタイムを技術的に短縮する話しかせず、業務要件から逆算していない

質問 3: 「切り戻しの計画はどう作りましたか。切り戻しを実行したことはありますか」

• 良い回答の例: 「◯時までに動作確認が完了しなければ切り戻す、という判断時刻を決めていた」「切り戻しの手順を事前にリハーサルした」など、判断基準が時刻や条件として具体化されている
• 注意したい回答: 「問題があれば戻します」という抽象的な説明のみ。誰がいつ判断するのかが決まっていない

3 問とも、専門知識ではなく回答の粒度を見ています。数字と固有名詞が自然に出てくる人は、その場に立ち会っていた可能性が高い人です。抽象的な一般論しか出てこない場合は、資料で読んだ知識である可能性を疑う材料になります。

なお、面談の場に社内の誰かひとりでも「オンプレ側の詳しい人」を同席させると精度が上がります。AWS は分からなくても、既存システムの制約を説明したときの相手の反応で、実務感覚の有無は伝わるためです。

AWS移行を業務委託するときの契約形態と委託先の選び方

クラウド移行 業務委託では、契約形態と委託先の選択が、そのまま「どこまで外部に依存するか」の設計になります。特に AWS アカウントを誰が持つかは、移行後の主導権を左右します。

準委任が向く工程・請負が向く工程

業務委託の契約形態は、大きく準委任契約と請負契約に分かれます。準委任は「作業の遂行」に対して対価を払う形、請負は「成果物の完成」に対して対価を払う形です。移行の工程ごとに、向き不向きがはっきり分かれます。

実務上のポイントは 2 つです。

第一に、調査が必要な工程を請負にしないこと。作業量が読めない工程を請負にすると、委託先はリスク分を上乗せして見積もるため、費用が高くなります。

第二に、ドキュメントは請負として別建てにすること。移行作業と一体の準委任にしてしまうと、期限が迫ったときに真っ先に後回しになり、そのまま契約終了を迎えます。ドキュメントを独立した成果物として定義し、検収の対象にすることが、移行後に知識を残す最も確実な方法です。

なお、準委任契約で外部人材に作業を依頼する場合、指揮命令の扱いには注意が必要です。契約形態と実態が乖離しないよう、作業指示の出し方は事前に整理しておきます。

フリーランス・SES/受託開発会社・AWSパートナーの3択と、AWSアカウントの所有者・請求の流れ

委託先の選択肢は、大きく 3 つあります。

ここで最も注意すべきなのが、右端の列です。

AWS アカウントを自社が直接契約している場合、請求は AWS から自社に直接届き、コンソールから利用状況をいつでも確認でき、委託先を変えてもアカウントはそのまま残ります。一方、委託先経由のリセール契約になっている場合、請求は委託先から届き、割引が適用される代わりに、委託先を変更するときにアカウントの移管交渉が必要になります。

移行という一度きりのプロジェクトのために、その後何年も使い続けるアカウントの主導権を手放してしまうと、後から取り戻すのは容易ではありません。特別な理由がない限り、AWS アカウントは自社名義で直接契約し、外部エンジニアには権限だけを付与する形が推奨されます。権限の付与方法は後述します。

3 択の選び方としては、次の整理が実務的です。

• 評価フェーズだけを切り出すなら → 設計に強いフリーランス個人へのスポット発注が費用対効果が高い
• 切替が集中する時期に人数が必要なら → SES・受託開発会社
• 社内に一切リソースを割けず、運用まで丸ごと任せたいなら → AWS パートナー企業（ただし移行後の知見は残りにくい前提で設計する）

移行方式が決まる前に全部を発注しない｜評価フェーズを切り出すフェーズ分け発注

ここまでの内容を発注の順序としてまとめると、ひとつの原則に行き着きます。移行方式が決まる前に、全工程を一括で発注しないことです。

移行方式が決まっていない段階で全体の見積を依頼すると、委託先は最も手間のかかるケースを想定して金額を出します。これは委託先が不誠実なのではなく、情報がない以上そうせざるを得ないからです。結果として、予算超過で稟議が止まります。

対して、評価フェーズだけを先に発注すれば、次のようになります。

1. 比較的少額（スポット稼働）で発注できるため、稟議のハードルが下がる
2. 資産一覧と移行方式の割り当てが手に入る
3. その情報をもとに、次の工程を精度の高い条件で相見積できる
4. 評価フェーズで一緒に働いた相手の実力も分かるため、継続発注の判断材料になる

外注のコストを抑えながら精度を上げるスコープ分割の考え方は、AWS 移行に限らず外部発注全般に共通します。詳しくは外注コストを抑えるスコープ分割・フェーズ分け発注の設計をご覧ください。

AWS移行の費用は「人件費・並走コスト・移行後の利用料」の3系統で見る

移行の費用を「委託先に払う人件費」だけで見積もると、必ず後から破綻します。AWS 移行には、人件費のほかに 2 つの費用系統があります。移行期間中だけ発生する並走コストと、移行後にずっと続く AWS 利用料です。この 3 系統で見ないと、稟議で説明したコスト削減効果が出ません。

AWSエンジニアの業務委託単価の目安と、単価に幅が生じる理由

AWS エンジニア 業務委託 単価の相場は、媒体によって示される幅が異なります。公開されている情報のひとつとして、2026 年上半期の公開案件ベースで月 60〜90 万円が中心帯、上位ゾーンで月 100〜130 万円という水準が示されています（フリコン「AWSエンジニア フリーランスの単価相場」）。これは常駐・フルタイム稼働を前提とした水準であり、週 2 日などの部分稼働であれば按分して考えることになります。

重要なのは金額そのものより、なぜこれほど幅が出るのかです。同じ調査では、単価の差は経験年数よりも担当レイヤー（運用／構築／設計／アーキテクト）と、IaC・コンテナ・セキュリティといった掛け算スキルの有無で開きやすい構造が指摘されています。

これを発注側の視点に置き換えると、次のようになります。

つまり、全フェーズを同じレイヤーの人材で埋めようとすると割高になります。評価フェーズは設計・アーキテクト層に週 1〜2 日、移行フェーズは構築層を厚く、運用は運用層または社内で、という組み方をすると、総額を抑えながら必要な質を確保できます。

なお、移行作業の人件費とは別に、AWS 環境の初期構築を外注した場合の費用相場も公開されています。検証環境で 20〜30 万円程度、本番環境で 50〜60 万円程度、大規模アクセスを想定した環境で 70 万円以上という目安が示されています（発注ラウンジ「AWSでのシステム開発や構築にかかる費用相場は？」）。構成により大きく変動する前提の数字ですが、桁感を掴む材料にはなります。

移行期間中だけ発生する二重コスト

見落とされやすいのがこの費用です。移行期間中は、オンプレミス環境と AWS 環境の両方が同時に動きます。オンプレ側の保守費・電気代・データセンター利用料は移行が終わるまで止まりませんし、AWS 側の利用料は環境を作った時点から発生します。この並走期間の費用が、見積から抜け落ちがちです。

移行期間中は旧オンプレと新クラウドの両方が動くため、その期間の電気代・保守費・クラウド料金が重なるという指摘があり、見積の際にこの並行期間を何ヶ月と置いているかを必ず確認すべきとされています（GXO「クラウド移行費用とオンプレTCO比較2026」）。

稟議資料には、次の 3 点を明記しておきます。

1. 並走期間の想定月数: 最初のシステムを AWS 上で稼働させてから、最後のシステムをオンプレから撤去するまでの月数
2. 並走期間中の月額: オンプレ側の固定費（保守・データセンター・回線）＋ AWS 利用料の合計
3. 並走が延びた場合の増加額: 1 ヶ月延びるといくら増えるかを単価として示しておく

3 番目が特に重要です。移行はスケジュールが後ろにずれることが珍しくありません。「1 ヶ月延びると◯万円増える」という数字を先に示しておけば、遅延が発生したときに追加予算の議論をゼロから始めずに済みます。

また、並走期間を短くするために移行を急ぐと、切替の失敗リスクが上がります。並走コストとリスクはトレードオフの関係にあることを、発注時点で認識しておく必要があります。

移行後のAWS利用料を発注段階で握る方法と、稟議で崩れないコスト比較の作り方

移行後の AWS 利用料は、外部エンジニアのサイジング判断に大きく左右されます。安全側に倒して大きめのインスタンスを選べば、動作は安定しますが月額は膨らみます。移行後にランニングコストが想定を超えるというのは、移行の代表的な失敗パターンとして繰り返し指摘されています（シースリーインデックス「AWS移行で後悔した会社の共通点」）。

これを発注段階で握るには、次の 3 つを条件に含めます。

• 移行後の月額 AWS 利用料の見積を、評価フェーズの成果物として提出させる。サービス別の内訳まで出してもらいます
• サイジングの根拠を文書で残させる。「なぜこのインスタンスサイズにしたのか」を後から辿れる状態にしておかないと、移行後にコストを下げようとしたときに手が出せません
• 移行後 3 ヶ月時点で見直す前提を明記する。移行直後は余裕を持たせ、実測値が取れた段階で最適化する、という段取りを最初から契約に含めます

そのうえで、稟議で崩れないコスト比較を作ります。ポイントは、3 案を同じ項目で並べることです。項目が揃っていない比較表は、必ず「本当にこれで全部か」という質問で止まります。

この表の下 3 行が、金額だけでは表せない差です。特に最終行は、次に説明する発注条件をどう書くかで変わります。空欄のまま提出すると、「安いほうでいいのでは」という結論に流れます。

外部エンジニアに渡すAWSアカウントの権限をどこまで絞るか

本番相当のデータが入った AWS アカウントに、社外の人を入れる。これに抵抗を感じるのは自然なことです。しかし「怖い」の正体の多くは、権限が全か無かの二択に見えていることにあります。権限は段階的に絞れますし、契約終了時に確実に剥がせます。

AWSのIAMで外部委託先の権限を絞る原則｜長期のアクセスキーを配らず一時的な認証情報を使う

AWS IAM 外部委託 権限の設計は、AWS が公開しているIAM でのセキュリティのベストプラクティスに沿って考えるのが確実です。発注側が押さえておくべき原則は、次の 4 点です。

原則 1: 人には ID プロバイダーとのフェデレーションを使い、長期の認証情報を配らない

AWS のベストプラクティスでは、人間のユーザーには ID プロバイダーとのフェデレーションを必須とし、ロールを引き受けることで一時的な認証情報を取得する方式が推奨されています。一方、長期的なアクセスキー（有効期限のない ID とパスワードに相当するもの）は、限られたユースケースに限定すべきとされています。

外部エンジニアに長期のアクセスキーを渡すと、そのキーがどこにコピーされたか追跡できません。ローカル PC の設定ファイル、個人のメモ、チャットの履歴。契約が終わってもキーが有効なまま残るリスクが生じます。

原則 2: 人の管理には IAM Identity Center を使う

AWS IAM Identity Center は、人によるアクセスを一元管理するための推奨ツールです。ここでユーザーを管理しておけば、契約終了時に該当ユーザーを無効化するだけでアクセスを止められます。多要素認証（MFA）の必須化もあわせて設定できます。

原則 3: 最小特権から始める

必要な権限だけを付与し、ユースケースが固まるにつれて権限を絞り込んでいく、という進め方が推奨されています。移行プロジェクトの場合、フェーズによって必要な権限が変わるため、次のような段階設計が現実的です。

原則 4: 請求情報と監査ログは別扱いにする

請求情報の閲覧権限と、監査ログ（AWS CloudTrail に記録される操作履歴）を変更・削除できる権限は、構築作業に必要な権限とは切り離して管理します。監査ログが消せてしまう状態では、「誰が何をしたか」の記録そのものが担保されません。

委託先が自社のAWSアカウントを持つ場合のクロスアカウントロールと外部ID（ExternalId）

委託先が受託開発会社や AWS パートナーで、自社の AWS アカウントを持っている場合には、別のやり方があります。相手のアカウントから自社のアカウントへ、ロールを引き受ける形でアクセスしてもらう方法です（AWS「サードパーティーが所有する AWS アカウントへのアクセス」）。

この方式には、発注側にとって明確な利点があります。

• 自社アカウント側にユーザーを作る必要がない
• 誰がロールを引き受けたかが監査ログに記録される
• 契約終了時は、ロールの信頼ポリシーから相手のアカウント ID を外すだけでアクセスが止まる

このとき必ず設定すべきなのが外部 ID（ExternalId）です。外部 ID は、ロールを引き受ける際に一致を要求する合言葉のような値で、混乱した代理問題（confused deputy problem）を防ぐために使われます。複数の顧客のアカウントにアクセスする委託先の場合、外部 ID がないと、別の顧客向けの操作が誤って自社のアカウントに向いてしまう可能性があります。

発注側としては、「クロスアカウントロールで接続する場合は外部 ID を設定する」という一文を、セキュリティ要件として発注条件に含めておけば十分です。技術的な設定は委託先が行います。

なお、初期の接続情報や各種サービスのアカウント情報など、AWS 以外の認証情報を外部エンジニアへ渡す場面も発生します。渡し方の基本ルールについては外部エンジニアへのAPIキー・認証情報の安全な渡し方を参考にしてください。

契約終了時に権限を剥がすチェックリスト

移行プロジェクトでは、フェーズごとに複数の委託先が入れ替わります。「誰にいつ何を渡したか」を記録しておかないと、剥がし忘れが必ず起きます。契約終了時には、次の項目を順に確認します。

• IAM Identity Center 上の該当ユーザーを無効化・削除した
• 発行した IAM ロールのうち、その委託先専用のものを削除した
• クロスアカウントロールの信頼ポリシーから、相手のアカウント ID を削除した
• 長期のアクセスキーを発行していた場合、すべて無効化・削除した
• 請求情報・コスト管理コンソールの閲覧権限を外した
• 委託先が作成した IAM ユーザー・ロールが残っていないか棚卸しした
• SSH 鍵・踏み台サーバーのアカウントを削除した
• 監査ログ（CloudTrail）を契約終了時点まで保全し、参照できる状態にした
• 委託先の管理端末に残る自社データの取り扱いを、契約書の条項に沿って確認した

このチェックリストは、契約書の付属資料として最初に相手と共有しておくと、終了時の作業がスムーズになります。「終わったら剥がす」ではなく、「終わったらこれを剥がす」と最初に合意しておくことが要点です。

移行が終わった後に社内へ知識を残すための発注条件

ここが本記事の中核です。冒頭に挙げた不安、つまり「移行が終わった瞬間に委託先はいなくなり、動いてはいるが誰も説明できない AWS 環境が残る」という事態を防ぐ方法を、具体的な発注条件として書き出します。

繰り返しになりますが、これは移行後に努力して解決できる問題ではありません。移行が終わってから「ドキュメントをください」と頼んでも、契約が終わっている以上は追加費用の交渉になりますし、そもそも作業中に記録を取っていなければ後から再現できません。発注時点で成果物として定義する以外に方法はありません。

AWS移行の引き継ぎで成果物として契約に書く5点

AWS 移行 引き継ぎの成果物として、次の 5 点を契約に明記します。それぞれ、欠けたときに移行後の自社に何が起きるかを対で示します。

この 5 点を書くうえでの実務的な注意点が 3 つあります。

注意点 1: 「ドキュメント一式」と書かない

「ドキュメント一式を納品する」という条項は、何が納品されれば完了なのかが定義されていないため、実質的に効力がありません。上記のように項目単位で列挙します。

注意点 2: 検収基準を書く

「構成図を納品する」だけでなく、「構成図は、自社の担当者が読んで、どのサーバーがどのサブネットに配置されているかを追跡できる粒度とする」といった水準を書きます。AWS の専門知識がない人が読むことを前提とする、と明記するのが有効です。

注意点 3: 中間納品を設定する

すべてを最終納品にすると、期限直前に作業が集中して品質が落ちます。移行フェーズの区切りごとに中間納品を設定し、その時点で読めるかどうかを確認します。読めなければ、その場で粒度の認識を合わせられます。

引き継ぎ資料に何を含めるべきかの一般的な整理は、外部エンジニア引き継ぎドキュメントの作り方でも扱っています。AWS 移行に固有の項目は上記の 5 点ですが、引き継ぎ全般の枠組みとして併せて確認しておくと、契約条項に落としやすくなります。

移行と並走して社内メンバーへ移す設計

ドキュメントを受け取っただけでは、社内に知識は残りません。書かれたものを読める状態にするには、書かれていない部分を補う経験が必要だからです。そのため、移行と並走して社内メンバーが手を動かす設計を組み込みます。

伴走期間を契約に含める

移行作業の一部を、外部エンジニアが単独で行うのではなく、社内メンバーと一緒に行う時間として設定します。「効率が落ちるのでは」という懸念はもっともですが、移行後の数年を考えれば、この時間は最も費用対効果の高い投資になります。

ペア作業の対象を選ぶ

すべてをペアで行う必要はありません。次の 3 つに絞ると効果的です。

1. 日常的に発生する操作: サーバーの起動・停止、バックアップの確認、アラート対応。頻度が高いため、覚えれば確実に自走できます
2. 切替の立ち会い: 本番の切替に社内メンバーが同席すると、システムの依存関係が体感として理解できます
3. コストの確認: AWS のコスト管理画面を一緒に見て、どのサービスにいくらかかっているかを説明してもらう

ドキュメントを「受け取る」のではなく「一緒に読む」

納品されたドキュメントを、委託先がいるうちに社内メンバーが読み、分からない箇所を質問する時間を設けます。この質問と回答の記録自体が、次の担当者への引き継ぎ資料になります。

移行完了直後の1〜2ヶ月をどう設計するか

移行が完了した瞬間に契約を終了させるのは、最もリスクの高い設計です。移行直後は、平常運用に入って初めて表面化する問題が集中する時期だからです。月次のバッチ処理が初めて動く、月末の負荷が初めてかかる、想定外の連携先から接続が来る。こうした事象は、移行の翌週ではなく翌月に起きます。

そこで、契約を次の形に切り替えます。

フル稼働から、スポット稼働への段階的な移行

移行完了後 1〜2 ヶ月を、稼働を絞った準委任契約として設計します。たとえば「月◯時間まで、平日日中の質問対応と障害の二次対応」といった形です。フル稼働の契約を延長するのではなく、稼働量を落として期間を確保するのが要点です。

この期間に扱う内容をあらかじめ決めておく

• 平常運用に入ってから発見された不具合の対応
• 実測値をもとにしたサイジングの見直し（過剰なリソースの縮小）
• 運用手順書の追記（運用して分かった不足の補完）
• 社内メンバーからの質問対応

3 番目が特に重要です。運用手順書は、運用してみるまで何が足りないか分かりません。移行完了時点の手順書を「完成品」とせず、1〜2 ヶ月運用したあとに補完する前提で契約に含めておくと、現場で使える手順書になります。

終了の条件を決めておく

延長を繰り返すと、当初の「必要な期間だけ」という前提が崩れます。「社内メンバーが月次の定期作業を単独で完了できたら終了」といった条件を先に決めておくと、判断が感情に流されません。

まとめ｜AWS移行エンジニアを業務委託で確保する判断の順序

AWS 移行を業務委託で進めるとき、判断は次の順序で行います。順序を飛ばすと、後の判断が根拠を持てなくなります。

1. 移行方式を仮決めする: 7R のうちどれを適用するかを、期限・ソースコードへの改修可否・OS とライセンスの 3 つの問いから割り当てる。ここが決まらないと人材要件が書けない
2. フェーズに分ける: 評価・準備・移行・移行後運用の 4 段階に分け、それぞれで必要な人材レイヤーと稼働量が違うことを前提に置く
3. スキルを見極める: 資格で担当範囲の当たりを付け、職務経歴書から移行本数・切替回数・切り戻し経験の 3 つの数字を確認し、面談では回答の具体性で判定する
4. 契約形態と委託先を決める: 調査を伴う工程は準委任、ドキュメントは請負として別建てにする。AWS アカウントは自社名義で直接契約する
5. 費用を 3 系統で把握する: 人件費・並走コスト・移行後の AWS 利用料。3 案を同じ項目で並べた比較表を作る
6. 権限を最小化する: 長期のアクセスキーを配らず、一時的な認証情報を使う。フェーズごとに権限を段階設計し、契約終了時のチェックリストを最初に合意しておく
7. 残す成果物を定義する: 構成図・IaC コード・移行手順と切り戻し記録・運用手順書・サイジングの根拠。この 5 点を検収基準つきで契約に書く

そして、明日から着手できる最初の一手は、評価フェーズだけを切り出して発注することです。

移行対象のシステム一覧を作り、「この範囲の資産棚卸しと、システムごとの移行方式の割り当て、移行後の概算コスト試算をお願いしたい。期間は◯週間、稼働は週◯日」という条件で発注します。金額が小さいため稟議のハードルが低く、成果物が手に入れば、その先のすべての判断が具体的な数字の上で行えるようになります。

移行が終わった後に社内へ何を残すかは、移行の最中に決めることではありません。最初の一枚目の契約書に書くことです。その一行があるかないかで、移行完了後の数年間の景色が変わります。

関連情報

引き継ぎの条件を契約に落とし込む段階では、確認すべき項目を一覧で押さえておくと漏れを防げます。失敗しないためのシステム保守の引継ぎチェックリストでは、引継ぎ前・中・後の各段階で確認すべき項目を整理しています。ご関心のある方は無料でダウンロードいただけます。

移行方式の仮決めや、外部人材を含めた体制の組み方でお悩みの場合は、お問い合わせフォームからご相談ください。要件が固まる前の整理段階からご相談いただけます。