AWS認定の週末だけで回せる範囲

2026年1月7日

長谷川奈津

この記事のポイント

✓AWS認定を持っている人が
✓週末と平日夜の稼働だけで完結させられる在宅案件の工程と
✓どうしても回らない工程を切り分けます

AWS認定を持っているのに、平日は本業でふさがっていて手が出せない。副業として案件を探すと「週3日常駐」「日中の定例会議に参加できる方」ばかりが並ぶ。この状態で止まっている方から相談を受けることが増えました。結論から言うと、AWSまわりの在宅案件は「案件そのもの」ではなく「工程」で切ると、週末と平日夜だけで完結する部分がはっきり残ります。逆に、どれだけ調整しても週末稼働では回らない工程もあります。この記事では、その境目を工程単位で示したうえで、単価の相場、契約の形、稼働時間をどう約束すれば揉めないかまでを整理します。

週末稼働で回るかどうかは「案件」ではなく「工程」で決まる

副業の案件情報を見ていると、募集の単位が大きすぎて判断できないことがよくあります。「AWS環境の構築および運用保守」という一行だけでは、週末に回るのかどうかは誰にも分かりません。判断の軸は、その作業が同期を必要とするかどうか、つまり相手が同じ時間帯にいないと進まないかどうかの一点です。

同期が要る工程は、平日日中に人が張り付く前提で設計されています。本番環境の切り替え、障害発生時の一次対応、関係部署を集めた設計レビューの場、監査対応の立ち会いなどがこれにあたります。反対に、成果物を渡せば完了する非同期の工程は、作業時間が土曜の午前でも火曜の深夜でも成立します。構成図の作成、コスト最適化の試算、IaC（インフラをコードで管理する仕組み）のコードレビュー、手順書の執筆などです。

ここを工程で切らずに「週末できる案件はありますか」と聞いてしまうと、募集要項の稼働条件だけで弾かれます。実際に発注側の立場で考えると分かりやすいのですが、発注者が本当に困っているのは「手が足りない」ことであって、「その人が平日にいること」自体が目的であるケースは意外と少ない。困りごとを工程まで分解して、そのうち非同期で切り出せる部分だけを引き受ける提案をすると、通る確率が変わります。

これ、知らない人が本当に多いんです。副業の入り口で躓く人の多くは、スキルが足りないのではなく、案件を丸ごと引き受けようとして稼働条件に負けています。工程を切って提案するのは、発注者にとっても親切です。丸ごと任せられる人が見つからないまま止まっている案件は、部分的にでも進むほうがありがたいからです。

週末と平日夜だけで完結する工程

AWS認定を持っている人が、非同期のまま完結させやすい工程を具体的に挙げます。ここに挙げたものは、いずれも成果物が明確で、レビューを1往復か2往復すれば終わる形に落とし込めます。

構成レビューと構成図の作成

すでに動いている環境の構成を読み解き、単一障害点、権限設計の甘さ、バックアップの欠落などを指摘して図に起こす仕事です。読み取りだけの権限を発行してもらえれば、深夜でも土日でも作業できます。成果物は構成図と指摘一覧で、期日は1週間から2週間で切られることが多い。

この工程は、AWS認定の学習範囲がそのまま効きます。Well Architected の観点で機械的に洗い出すだけでも、社内に専任がいない会社にとっては十分な価値があります。逆に言うと、指摘の根拠を「なんとなく」で書くと次がありません。どのドキュメントのどの推奨に基づく指摘なのかを、指摘ごとに一行添えるだけで受け取り方が変わります。

コスト最適化の棚卸し

請求データとリソースの一覧を突き合わせ、使われていないボリューム、止まっていないはずの検証環境、購入したまま使い切れていない割引プランを洗い出す仕事です。金額という分かりやすい成果が出るため、発注者の納得を得やすく、継続にもつながりやすい工程です。

作業自体は完全に非同期で進みます。請求とタグ付けの情報を渡してもらえれば、あとは一人で黙々と数字を追う時間になります。月次で2時間から4時間の定額で契約している例もあり、週末稼働との相性はかなり良い部類です。

IaCのコードレビューと部分実装

Terraform や CloudFormation のコードを読み、命名規則の統一、権限の絞り込み、モジュール分割の見直しを提案する仕事です。プルリクエストのやり取りで完結するため、相手と時間を合わせる必要がありません。差分に対してコメントを残す形なので、着手と中断が自由にできるのも週末向きです。

部分実装まで引き受ける場合は、対象を明確に区切ることが重要です。「監視まわりのモジュールだけ」「タグ付けの標準化だけ」というように、他の人の作業と衝突しない範囲に限定する。範囲が曖昧なまま実装を引き受けると、平日日中の調整が必ず発生します。

手順書と運用ドキュメントの整備

環境は作ったが手順書がない、という会社は本当に多い。障害時の切り分け手順、バックアップからの復旧手順、権限申請のフローなどを、実際の環境を見ながら文書に落とす仕事です。書く力とAWSの理解が両方要るため、単価が下がりにくい領域でもあります。

この工程はライティング案件としても募集されます。技術文書の書き手を探している発注者は多く、専門ライターの領域と地続きです。書く仕事の広がりについては、著述家，記者，編集者の年収・単価相場に職種全体の水準がまとまっているので、値付けの目安として見ておくと判断しやすくなります。

監視とアラートの設計

どの指標をどのしきい値で拾い、誰にどう通知するかを設計して実装する仕事です。実装後の検証で一時的に同期が必要になる場面はありますが、設計そのものは非同期で進められます。既存のアラートが多すぎて誰も見ていない状態を整理する依頼は、季節を問わず一定数あります。

週末稼働では回らない工程を先に伝える

引き受けられない工程を先に言うと案件が減ると思われがちですが、実際は逆です。あとから断るほうが信用を失います。次の工程は、週末と平日夜の稼働では原則として成立しません。

本番環境の切り替え作業は、業務が止まる時間帯に合わせて実施されます。深夜帯の作業なら週末稼働と両立できる場合もありますが、切り替え後の監視期間まで含めると平日日中の待機が必ず発生します。障害の一次対応も同じで、連絡から30分以内の応答を求められる契約は、本業を持っている人には務まりません。

顧客との定例会議への出席、監査法人やセキュリティ監査への同席、他部署を巻き込む要件定義のワークショップも、平日日中に固定されます。これらを含む案件は、募集の時点で見送ったほうが双方のためです。

もうひとつ見落とされやすいのが、緊急のスケジュール変更に追随できるかどうかです。前日に「明日の午後に打ち合わせを入れたい」と言われて動けないなら、その旨を契約前に文書で伝えておく。ここを曖昧にしたまま始めると、稼働時間ではなく「連絡が取れない」という理由で関係が切れます。

単価の相場と、週末稼働で現実的な金額

AWSまわりの副業案件は、常駐や週数日の稼働を前提とした募集が単価の基準を作っています。まずその水準を押さえたうえで、週末稼働に引き直すのが順序です。

フリーランスHubに掲載されているAWSの副業案件は、60万～70万円のものが多い傾向です（2025年11月18日時点）。単価は本人の実績やスキル、経験年数などでも変動する可能性があります。出典: freelance-hub.jp

この金額はフルタイムに近い稼働を前提としたものです。週末と平日夜だけとなると、稼働時間は月20時間から40時間程度に収まります。同じ時間単価で計算すれば月10万円前後になりますが、初回から工程を丸ごと任されることは少ないため、最初の数か月はもっと小さい金額から始まります。

副業未経験者の場合、実績ができるまでは案件を獲得しにくいことも多いため、最初は「月3～5万円程度」を目標にするのがおすすめです。出典: jobs.qiita.com

エンジニア職全体の水準を把握しておくと、提示された金額が妥当かどうかの判断が速くなります。ソフトウェア作成者の年収・単価相場には職種単位の相場がまとまっているので、時給換算した自分の基準線を作る材料になります。

値付けで揉めやすいのは、時間精算と成果物精算のどちらで契約するかです。構成レビューやコスト棚卸しのように成果物が明確な工程は、成果物単位の固定額にしたほうが週末稼働と噛み合います。時間精算にすると、稼働できない平日に問い合わせが溜まり、結果として実働時間が読めなくなります。

契約の形を先に決めておく

ここからは法務の話です。副業でAWS案件を受けるとき、揉めるのはほぼ例外なく契約書を交わしていないケースです。

準委任か請負かを明示する

構成レビューや技術的な助言は、成果物の完成そのものを約束しない準委任の性質を持ちます。一方、手順書の納品やIaCの実装は、完成して初めて報酬が発生する請負に近い。どちらの性質かを契約書に書かないまま進めると、「まだ動いていないから払えない」という主張が出てきます。つまり、何をもって完了とするかを文章で決めておく、ということです。

完了条件は、できるだけ機械的に判定できる形にします。「レビュー結果を文書で提出し、発注者が受領した時点」「対象リポジトリへのプルリクエストが作成された時点」といった書き方です。「発注者が満足した時点」のような主観的な条件は、絶対に受けないでください。

フリーランス保護新法で押さえるべき点

事業者から業務委託を受ける個人には、特定受託事業者に係る取引の適正化等に関する法律、いわゆるフリーランス保護新法が適用されます。発注者には取引条件を書面や電子メールなどで明示する義務があり、報酬は原則として給付を受領した日から起算して60日以内のできる限り短い期間内に支払う必要があります。受領後に「イメージと違う」と言って支払いを止める行為は、この枠組みの中で問題になり得ます。

副業として受ける場合でも、業務委託であればこの法律の対象になります。会社員だから関係ない、と考えている人が多いのですが、そこは雇用か業務委託かで決まる話です。トラブルの芽を摘む意味でも、条件明示の書面は必ずもらってください。もらえない相手とは取引しない、という線引きで問題ありません。

本業の就業規則と競業避止

副業を始める前に、本業側の就業規則を確認します。届出制なのか許可制なのか、競合他社への役務提供が禁じられていないか、勤務時間との重複がどう扱われるか。AWSの案件は本業と業種が近くなりやすいため、競業避止の条項に触れる可能性が他の副業より高い領域です。判断に迷う内容であれば、社内の人事に確認するか、弁護士に相談してください。

秘密保持と環境へのアクセス

本番環境の認証情報を個人の端末で扱う以上、秘密保持契約は必須です。あわせて、どの端末で作業するか、ログをどこに残すか、契約終了時に何を削除するかまで決めておく。ここを詰めておくと、発注者側の情報システム部門の承認が通りやすくなり、結果として案件が取りやすくなります。

週末稼働を続けるための運用の型

契約が整っても、運用の約束がないと続きません。長く続いている人ほど、次の3つを最初の打ち合わせで文書にしています。

ひとつめは、連絡への応答時間です。「平日は21時以降に確認し、翌朝までに返信する」「土日は午前中に確認する」と書いておく。即応できないことを弱みとして隠すのではなく、いつ返ってくるかが確定していることを価値として示します。発注者が本当に困るのは遅いことではなく、いつ返るか読めないことです。

ふたつめは、作業ログの残し方です。何をどこまで進めたかを、相手が非同期で読める場所に置く。チケットのコメントでも、共有ドキュメントの更新履歴でも構いません。週末しか動かない人が信用を得る唯一の方法は、動いていない時間に相手が状況を確認できることです。

みっつめは、引き受けない工程の再確認です。障害対応や本番切り替えを引き受けないと決めたなら、その代わりに誰がやるのかを最初に握っておく。ここを空白にすると、いつの間にか呼び出される関係になります。

先日、あるインフラエンジニアの方から相談を受けました。週末だけの約束で構成レビューを受けたのに、半年後には本番障害の連絡が休日の昼に飛んでくるようになっていた、という内容です。契約書には稼働時間の記載がなく、口頭の合意だけでした。こうなると法的な整理も難しく、関係を解消するしか手がありませんでした。最初の一枚の書面で防げた話です。

資格の書き方と、名乗り方の注意

AWS認定は民間のベンダー資格であり、国家資格のような業務独占はありません。認定を持っていなければAWSの構築や運用ができない、という法的な制限は存在しないということです。逆に言えば、認定があるからといって法的に守られた独占領域が生まれるわけでもありません。

一方で、認定名やロゴをどう表示してよいかは、AWS側の商標やブランドの利用ルールに従う必要があります。提案書やプロフィールにバッジを貼る場合は、利用条件を確認してから使ってください。ここは資格ごとに扱いが変わる部分なので、断定せずに一次情報を当たるのが安全です。

案件の入り口としては、どの認定を持っているかよりも、その認定の範囲で何を任せられるかを書いたほうが伝わります。たとえばAWS認定クラウドプラクティショナーの範囲であれば、コスト構造の説明や請求データの読み解きといった、非エンジニア相手の翻訳役として価値が出ます。上位の認定であれば、設計判断の妥当性を検証する側に回れます。認定名を並べるのではなく、認定と工程を対応づけて書く。これだけで問い合わせの質が変わります。

なお、他社の環境に踏み込む仕事である以上、指示の受け方によっては請負ではなく労働者派遣に該当すると判断される場面もあります。作業の進め方を発注者から細かく指揮命令される形になっていないか、契約の実態として確認してください。労働者派遣事業の適正な運営の確保及び派遣労働者の保護等に関する法律の枠組みに関わる話なので、迷う場合は専門家に確認するのが確実です。

在宅案件の探し方と、独自データから見える傾向

週末稼働を前提に案件を探すなら、募集の稼働条件で絞るより、工程で切り出せる依頼が集まる場所を見るほうが早い。技術相談やアドバイザリーの依頼は、キャリア・副業・人生相談のお仕事のように相談そのものを仕事として扱うカテゴリに集まる傾向があります。セキュリティ設計やクラウド活用の助言といった依頼は、AI・マーケティング・セキュリティのお仕事の領域と重なります。募集の文面が「常駐」でなくても、実質的に工程を切り出したい依頼はこうした場所に紛れています。

隣接分野の需要を眺めておくのも有効です。技術者が受託の入り口を広げる例として、SEO対策・MEO対策の副業で稼ぐ方法｜必要なスキルと案件相場のように、専門知識を持つ人が助言型の仕事に横展開している分野があります。AWSの知識を、開発ではなく判断材料の提供という形で売る発想は、週末稼働と相性が良い考え方です。

20年この市場を運営してきた立場から言えば、週末だけの稼働で長く続いている人には共通点があります。単発の作業を積み上げるのではなく、「この人に聞けば判断が早く済む」という関係を作っていることです。月に数時間しか動かないのに3年以上同じ相手と続いている例では、たいてい相談窓口としての役割が定着しています。作業量ではなく、意思決定の速さを提供している形です。

もうひとつ、運営者として見てきた限りでは、手取りの厚さが継続の可否を左右します。仲介手数料が引かれる経路で月5万円の仕事を受けると、実際に残るのはそれより少ない。手数料0%の直接取引であれば、同じ予算で発注者はより多くの工程を頼めますし、受け手の手取りも厚くなります。週末しか動けない人にとって、限られた時間あたりの手取りが厚いかどうかは、続けられるかどうかそのものです。金額の大小より、この構造の差のほうが効いてきます。

最後に、週末稼働で最も伸びるのは技術力そのものではありません。工程を切り分けて言語化する力です。相手の困りごとを聞いて、そのうち非同期で片づく部分を見つけ、期日と完了条件を添えて提案する。この一連の動きができるようになると、稼働時間の制約は交渉のテーブルから消えます。法律はあなたの味方ですが、味方になってもらうには、約束を文章にしておく必要があります。

週末の時間割を先に固定する

工程を切り出して契約まで漕ぎ着けても、時間の使い方が決まっていないと数か月で息切れします。本業を持ちながら続けている人を見ていると、稼働の中身を曜日ごとに固定している例が目立ちます。土曜の午前に手を動かし、日曜の夜に成果物をまとめて送る。平日は返信と読み込みだけに限る。こうした型を最初に決めておくと、その週の負荷が読めるようになります。

固定するときの目安は、月あたりの稼働を30時間以内に収めることです。これを超えると本業の睡眠時間を削る形になり、品質が落ちます。品質が落ちると手戻りが増え、手戻りが増えるとさらに時間を取られる。この悪循環に入ると、報酬の多寡にかかわらず続けられなくなります。

もうひとつ効くのが、受ける工程を同時に2件までに絞ることです。3件を並行させると、それぞれの環境の前提を思い出すだけで時間が溶けます。AWSの案件は環境ごとに命名規則も権限設計も違うため、切り替えのコストが他の在宅仕事より重い。少ない件数を深く見るほうが、結果として時間あたりの手取りが厚くなります。

繁忙期の扱いも先に決めておきます。本業の決算期や大型リリースの時期は、稼働をゼロにする月として最初から伝えておく。年間で2か月ほど休む前提で契約しておけば、いざその時期が来ても謝る必要がありません。休めない契約は、長期的にはどちらにとっても不利益になります。

最初の1件をどう取るか

工程を切り出す発想が身についても、実績がない状態では提案が通りにくいのは事実です。ここで多くの人が単価を下げて勝負しようとしますが、その方向は勧められません。安く受けた実績は次の交渉で足かせになりますし、安いから雑に扱ってよいと考える発注者を引き寄せます。

代わりに有効なのは、範囲を極端に小さくすることです。「環境全体のレビュー」ではなく「IAMの権限設計だけを見る」、「コスト全体の最適化」ではなく「使われていないリソースの洗い出しだけ」。範囲が小さければ発注側のリスクも小さく、判断が速くなります。金額を下げずに心理的な障壁だけを下げる、という考え方です。

提案書に書く内容も決まった型があります。何を見るのか、何を成果物として渡すのか、いつまでに渡すのか、そのために何を貸してほしいのか。この4点を箇条書きで示すだけで、返信率は明確に変わります。技術的な自己紹介を長く書くより、相手が判断できる材料を並べるほうが効きます。

そして、初回の仕事では期日を必ず守ってください。週末稼働の人が信用を積む方法は、これしかありません。期日通りに、約束した形式で、約束した内容が届く。この一回が積み上がると、次からは相手のほうから工程を切り出して相談してくるようになります。相談の段階から関われるようになれば、稼働条件は交渉の前提ではなく調整項目に変わります。

週末稼働でよく起きる行き違いと、その防ぎ方

相談として持ち込まれる行き違いは、種類が驚くほど限られています。ひとつめは「連絡がつかない」という不満です。稼働時間を伝えていても、相手が読んでいなければ意味がありません。契約書とは別に、応答時間を一行だけ書いた運用メモを共有し、打ち合わせの冒頭で口頭でも確認する。二重に伝えておくと、後から食い違いが起きにくくなります。

ふたつめは、成果物の粒度に対する認識のずれです。構成レビューと言っても、指摘一覧だけを想定している発注者と、改善後の実装まで期待している発注者がいます。着手前に、想定している成果物の見本を一枚見せてしまうのが確実です。文章で説明するより、同じ形式の過去の成果物を匿名化して見せたほうが早く合意できます。

みっつめは、環境へのアクセス権をめぐる遅れです。作業に必要な権限が発行されないまま日数だけが過ぎ、結局こちらの納期だけが圧迫される。これを防ぐには、契約時に「アクセス権の発行日から起算して10営業日」といった書き方で納期を定義しておきます。発注者側の準備が遅れた分は、こちらの責任ではないことを最初に明確にしておく。

よっつめは、追加作業がなし崩しに増えることです。レビュー中に見つかった別の問題を「ついでに」と頼まれる場面は必ず来ます。その場で断る必要はありませんが、「今回の範囲外なので、別途お見積もりします」と一言返すだけで、無償の作業が積み上がるのを止められます。ここを流すと、月10時間のつもりが25時間になり、時間単価が半分以下まで落ちます。

これらはいずれも、技術の問題ではなく合意の問題です。週末しか動けないという制約は、合意さえきちんと作っておけば弱点になりません。むしろ、条件を明文化する習慣が身につく分だけ、平日フルタイムで動ける人より揉めにくい関係を築けている例をよく見ます。