れい｜AWSエンジニアコーチ

AWS特化のエンジニアコーチ / IT企業CEO
「知っている」→「実務で使える」に変えるのが仕事

▶ AWS研修「Enginear」運営（法人/個人）
▶ SIer・SES若手エンジニアの育成に全振り
▶ 採用する側のリアルな視点で発信中

キャリア戦略 / AWS考察 / エンジニアの育て

[れい｜AWSエンジニアコーチ @enginear_coach]

はじめまして、れいです。

IT企業の代表をしながら、AWSエンジニアの育成をしています。

自分自身がSIerで苦労した経験があるからこそ、
「知ってる」と「使える」の間にある壁を壊す研修を作っています。

このアカウントでは
・AWSの実務で使える考察
・エンジニアの育て方のリアル
・採用する側が本当に見ているポイント

を発信していきます。

同じように「エンジニアの成長」に関わっている方、
ぜひ繋がりましょう。あなたは普段どんな立場でエンジニアと関わっていますか？

[れい｜AWSエンジニアコーチ @enginear_coach]

海外の求人で「AIスキル」を求める割合が、2022年の8%から2026年に42%まで跳ね上がった。

しかも、AIスキルを持つエンジニアの平均報酬は、持たない人より50%以上高いというデータも出ている。

ここで勘違いしてはいけない。「AIスキル」=ツールを使えること、ではない。
求められているのは「AIに何をやらせ、その出力をどう検証し、設計に組み込むか」を語れる力だ。
ChatGPTを開ける、では誰も評価しない。

あなたが言う"AIを使える"は、どのレベルの話ですか？

[れい｜AWSエンジニアコーチ @enginear_coach]

研修で「設計時の概算コスト」と「実際にかかったコスト」を、必ず突き合わせさせている。

構成を作るとき、みんな月額の概算は出す。
でも1週間動かした後の「実測」と比べる人は、ほとんどいない。

差分を見ると気づく。「NAT Gatewayの通信費を見落としていた」「ログの保存料が想像の3倍だった」。
この"ズレた経験"が、現場でコストを語れるエンジニアを作る。
見積もりは、当てるためじゃなく、外して学ぶためにやるものだ。

あなたは自分の設計、実測と突き合わせたことがありますか？

[れい｜AWSエンジニアコーチ @enginear_coach]

AIエージェントが「経験から学んで賢くなる」段階に入った。

今月、Amazon Bedrock AgentCoreに「エピソード記憶」と継続学習が加わった。
これまでのエージェントは毎回ゼロから考えていた。これからは過去の対応を覚え、次の判断に活かす。

実務で言えば、障害対応や運用作業を「やるたびに賢くなるAI」が支える時代だ。
ただし、何を覚えさせ、何を覚えさせないかを設計するのは人間。AIの"教師役"は結局エンジニアが担う。

あなたなら、AIに何を学習させて、何を止めますか？

[れい｜AWSエンジニアコーチ @enginear_coach]

SESを経営していて、客先から降りてくる作業の「質」が静かに変わってきた。

数年前まで、若手向けに「手を動かすだけの作業」がたくさんあった。
今はそういう作業がAIや自動化で消え、客先に残るのは「判断が必要な仕事」ばかりだ。

つまり、SESとして売るものが「手の数」から「判断できる頭の数」に変わった。
未経験をどう即戦力にするか、その育成設計を変えないと、単価の出る仕事に人を乗せられなくなる。

経営者なら、自社が客先に売っているのは"手"ですか、"頭"ですか？

[れい｜AWSエンジニアコーチ @enginear_coach]

海外で、若手エンジニアの新規採用が前年比70%以上も減った。これは日本の駆け出しにも他人事じゃない。

2026年の海外データでは、エントリーレベルの技術職採用が激減している。
理由は明確で、これまで新人がやっていた「チケットをコードに変える」作業を、AIが巻き取り始めたからだ。

逆に言うと、AIに任せられない領域──設計判断、要件の言語化、障害対応──に早く軸足を移せた人だけが残る。
作業の量で勝負する時代は、静かに終わりかけている。

あなたの今の仕事、どこまでAIに巻き取られますか？

[れい｜AWSエンジニアコーチ @enginear_coach]

「選んだ設計」より「捨てた設計」を書かせると、急に伸びる研修生がいる。

うちの研修では、構成図を出すとき「採用した案」だけでなく「検討して捨てた案と、捨てた理由」を1行ずつ書かせている。

最初はみんな書けない。「これしか思いつかなかった」が本音だからだ。
でも捨てた案を言葉にできる人は、現場で「なぜこの構成にしたのか」を説明できる。
設計は、正解を選ぶ作業じゃなく"消去法の記録"だと思っている。

あなたは直近の設計で、捨てた案を1つ言えますか？

[れい｜AWSエンジニアコーチ @enginear_coach]

AWSが「AIに正しくAWSを触らせる道具箱」を出した。日本ではまだほとんど話題になっていない。

先週GAになったAgent Toolkit for AWSは、AWS MCP Serverの後継だ。
20種類以上の「AWSスキル」を持ち、Claude CodeやKiroが300以上のAWS APIを、より少ないトークン・より少ないミスで叩けるようになった。

つまりこれから駆け出しは「AIに正しくAWSを触らせる」前提で学ぶ時代に入る。
手で全部叩く練習より、AIの出力を"設計判断で検証できる力"が効いてくる。

あなたはAIに任せた設計、自分で良し悪しを判断できますか？

[れい｜AWSエンジニアコーチ @enginear_coach]

「忙しくて勉強する時間がない」は、半分本当で、半分は順番が逆だ。

現場が忙しいということは、実務という最高の教材の真ん中にいるということ。
時間がないんじゃなく、「実務を学びに変換していない」だけのことが多い。

れいがおすすめしているのは、1日の終わりの15分だけ。
今日やった作業を振り返って、こう書く。

・なぜその手順を選んだか
・他にどんな手があったか
・次に似た場面で何を変えるか

これだけで、こなした作業が"教材"に変わる。
机に向かう勉強より、現場の言語化のほうが、駆け出しの成長を速くする。

今日の業務で、あなたが「学びに変えた」瞬間はありましたか？

[れい｜AWSエンジニアコーチ @enginear_coach]

うちの研修で、1日の終わりに「明日詰まりそうな所」を予測して書かせている。

たった2〜3行でいい。
「明日はVPCピアリングをやる。たぶんルートテーブルの設定で詰まる気がする」

そして翌朝、答え合わせをする。
当たっていたら、なぜ事前に分かったのか。外れたら、何を見落としていたのか。

これを続けると、研修生に"先読み"の感覚が育つ。
現場で評価されるのは、起きた問題を直せる人より、起きる前に「ここ危ないですよ」と言える人だ。

障害対応をAIが下書きする時代でも、「どこが危ないか」を先に嗅ぎ取る勘は、人の経験からしか育たない。

あなたは、明日の自分が詰まりそうな所を、今言えますか？

[れい｜AWSエンジニアコーチ @enginear_coach]

SES経営で一番難しいのは「客先で見えない努力を、どう評価するか」だ。

客先での働きは、単価という形で見える。
でも社内での貢献──ドキュメントの整備、後輩のフォロー、ナレッジの共有──は、数字に出にくい。

れいは「客先評価」と「社内貢献」を分けて評価することにした。

理由はシンプルで、社内貢献を評価しないと、優秀な人ほど"自分だけ"が伸びる動き方になる。
そして気づけば、チームに何も残らない。

会社に残したい人ほど、数字に出ない貢献を見て、言葉にして伝える。
「あの手順書、後輩がめちゃくちゃ助かってたよ」の一言が、定着率を変える。

経営者のあなたの会社は、「数字に出ない貢献」を評価できていますか？

[れい｜AWSエンジニアコーチ @enginear_coach]

「会社の環境でしかAWSを触ったことがない」人は、伸びしろを1つ捨てている。

れいが伸びる人に共通して見るのは、"自分の財布"でクラウドを触った経験だ。

会社のアカウントだと、コストの痛みも、権限を壊す怖さも、どこか他人事になる。
誰かが許可をくれて、誰かが請求を払ってくれる。

自腹で月数千円のアカウントを持つと、世界が変わる。
請求に怯えながらリソースを消し、権限を間違えてヒヤッとする。この"自分事の経験"が、現場での判断の速さに直結する。

資格より、自分名義のAWSアカウントを1つ持つこと。
壊して、直して、請求書を見る。これ以上の教材はない。

あなたは、自分名義のAWSアカウントを持っていますか？

[れい｜AWSエンジニアコーチ @enginear_coach]

うちの研修で、構成図を「手描き」で書かせる時間を必ず入れている。

きれいなAWSアイコンも、作図ツールも、最初は禁止だ。
紙とペンで、自分の頭の中だけで構成を描かせる。

理由は1つ。
ツールで描くと"並べただけ"でも図が完成してしまう。だから理解していなくても、それっぽく見える。

手描きだと、ごまかせない。
「ここのサブネット、どう繋がってたっけ」で手が止まる瞬間が、理解の穴そのものなんだ。

描けた図がきれいかどうかは、どうでもいい。
止まった場所が、その人がまだ分かっていない場所。そこを次の学習テーマにする。

あなたは今の現場の構成を、何も見ずに手で描けますか？

[れい｜AWSエンジニアコーチ @enginear_coach]

AWSが「AIボットからお金を取る」仕組みを出した。日本ではまだ話題になっていない。

先週のAWS Summit ニューヨークで、AWS WAFのBot Controlに"AI traffic monetization"が追加された。
コンテンツ提供者が、AIボットやエージェントのアクセスを計測して、課金・徴収できる仕組みだ。

背景はシンプルで、AIが勝手にサイトを読んでデータを吸う問題が深刻化している。
これからは「AIに読ませる＝有料API」が当たり前になる流れだ。

実務的な意味は大きい。
Webを作る側は、これまでの「人間向けのUI」だけじゃなく、「AIエージェント向けの有料アクセス」を分けて設計する時代に入る。

設計の前提が、また1つ変わる。

あなたのサービス、AIエージェントのアクセスを"想定"した設計になっていますか？

[れい｜AWSエンジニアコーチ @enginear_coach]

単価交渉は「契約更新の3ヶ月前」に動かないと、ほぼ負ける。

SESを経営していて、これは何度も痛感してきた。
多くの会社が更新の直前にバタバタ動く。そして足元を見られて据え置きになる。

れいは更新の3ヶ月前から客先とこう握る。
「この期間で何を任せてもらい、何を成果として見せるか」

単価は技術力だけじゃ動かない。"見せ方とタイミング"で動く。
同じ仕事でも、成果が言語化されて見えている人の単価は上がる。

だからエンジニア本人にも口酸っぱく言う。
「やった成果を、客先が分かる言葉で残しておけ」と。交渉材料は前もって貯めるものだ。

経営者のあなた、次の契約更新、いつから準備を始めていますか？

[れい｜AWSエンジニアコーチ @enginear_coach]

「2年目で急に成長が止まった気がする」という相談をよく受ける。

これは、たいてい止まっていない。見えにくくなっているだけだ。

1年目は覚えることだらけで、成長を毎日実感できる。
2年目は同じ作業の"精度が上がる"フェーズに入る。だから自分では伸びを感じにくい。

本当に危ないのは、ここで「作業の精度」に満足して「設計判断」に進まない人だ。
踊り場は、休む場所じゃなく"登り方を変える"場所だと思っている。

やることはシンプル。
任された作業に毎回「なぜこの構成を選んだか」を1つ足す。言われたことに、自分の判断を1つ重ねる。

直近の仕事で、あなたは「言われた以上」を1つ足せましたか？

[れい｜AWSエンジニアコーチ @enginear_coach]

うちの研修で「コマンドを打つ前に、何が起きるかを声に出す」習慣を入れた。

apply する前に、delete を叩く前に、一言。
「これを実行すると、このリソースがこう変わるはず」

たったこれだけで、研修生の事故が激減した。

理由は2つ。
①自分の"想定"が言語化されるから、結果とのズレに気づける
②そもそも「何が起きるか分からないまま叩いていた」自分に気づく

現場で怖いのは、コマンドが打てないことじゃない。
「何が起きるか分からないまま、本番で叩ける」状態だ。

AIが手順を出してくれる時代だからこそ、実行前に一拍おいて予測する。この一拍が、止められるエンジニアと止められないエンジニアを分ける。

あなたは直前のコマンド、結果を予測してから叩きましたか？

[れい｜AWSエンジニアコーチ @enginear_coach]

S3が「ファイルに付箋を貼れる」ようになった。日本語ではまだほぼ情報が出ていない。

先週のAWS Summit ニューヨークで、Amazon S3のオブジェクトに最大1GBの"注釈(annotations)"を直接つけられる機能が発表された。

これまでメタデータは数KBが限界だった。
これからはAIエージェントが読む文脈──要約・タグ・処理履歴──を、ファイル本体に同梱できる。

実務的な意味はこうだ。
RAGや自律エージェントが「このファイルは何で、どう使うか」をS3だけで完結できる。別のDBを立てる前提が崩れていく。

新サービスは"設計の前提"を変える。覚える知識じゃなく、設計判断の更新として捉えたい。

あなたの現場、ファイルの"文脈"はいまどこに保存していますか？

[れい｜AWSエンジニアコーチ @enginear_coach]

エンジニアが1人辞めると、実は数百万円が静かに溶ける。

SES経営をしていて痛感する。
採用コスト、立ち上がりの数ヶ月、そして客先からの信頼。
これを全部足すと、1人の離職は想像よりずっと高くつく。

だから「辞めそうな兆候」に先に投資する方が、結局は安い。

れいが見ている兆候は2つ。
・質問が減る
・自分の成果を語らなくなる

辞める人は不満を言わない。静かに準備して、ある日「お話が」と来る。
だから定期的な1on1で"市場価値"の話を先にこちらからする。会社の外も含めて。

経営者のあなた、直近で部下に「最近どう？」と聞いたのは、いつですか？

[れい｜AWSエンジニアコーチ @enginear_coach]

先週のAWS Summit ニューヨークを見て、駆け出しの戦い方が変わったと確信した。

DevOps、FinOps、検索…エージェントが「標準機能」として次々に発表された。
つまり「APIや手順を覚える」勝負は、もう終わりに近づいている。

ではどこで差がつくか。
海外2026のデータでは、同じ経験年数でも"専門特化した人"はジェネラリストより30〜50%報酬が高い。

AIに浅く広く聞ける人より、一点を深く検証できる人。
「エージェントが出した答えを、根拠から疑って直せる」力にこそ市場価値が移っている。

広く触るのは入口。これからは「ここなら誰にも負けない」を1つ作れるか。

あなたの"深い一点"は、いま何ですか？

[れい｜AWSエンジニアコーチ @enginear_coach]

うちの研修で、レビューの「ダメ出し」を禁止にした。

ルールはシンプルで、間違いを指摘するときは必ず代案をセットにする。

NG：「ここ、設計が間違ってます」
OK：「ここがこうだと、障害時にこう困る。だから代わりにこうしては？」

理由は、現場で評価される指摘は"批判"じゃなく"前進"だからだ。
代案を出すには、相手の設計意図と要件を理解しないといけない。だから一番設計力が伸びる。

最初は代案が出せずに黙る研修生が多い。
でもその沈黙こそ「まだ自分も理解できていない」というサインなんだ。

直近のレビューで、あなたは"代案つき"で指摘できましたか？