新人エンジニアにAWS設計を任せる前に、生成AIとの距離感を一度決めておきたい

Posted at 2026-06-26

はじめに

ChatGPTやAIコーディングアシスタントが当たり前の存在になってから、新人エンジニアの学び方も大きく変わったと感じています。
わからないことがあれば、先輩に聞く前にAIに聞く。設計に迷ったら、AIに「いい感じの構成」を出してもらう。これ自体は悪いことではなく、調べ物のスピードは確実に上がっていると思います。

ただ、AWSの設計・構築を仕事にしている立場から見ていると、「新人がAIにどこまで任せるか」については、もう少し慎重に線を引いた方がいいのではないかと感じる場面が増えてきました。

この記事では、「新人社員には、OJT期間中だけ生成AIへの依存をなるべく抑えてほしい」という立場から、その理由と、ありがちな反論への考えをまとめてみます。AIを使うこと自体を否定する記事ではないので、その点は先に断っておきます。

この記事の主張

結論を先に書くと、こうです。

OJT期間中（基礎力が育つまでの一定期間）は、AWS設計・構築の実装作業において、生成AIへの依存を意図的に制限すべき

ポイントは「期間限定」というところです。永久に使わせないという話ではなく、「自力で考えて、詰まって、調べて、直す」というサイクルを一定期間積んでから、生成AIを本格的に使い始めてほしいという順番の話です。

調べ物や用語の理解のためにAIを使うのは、この期間でも特に止める必要はないと思っています。問題にしたいのは、「実装や構築の判断そのものをAIに委ねてしまう」使い方です。

なぜ「なるべく使わせない」のか

AIの提案を検証する力が、まだないと見抜けない

生成AIは、文法的に正しく、一見ちゃんと動くコードや設定を出してくれます。ただ、それが「動く」ことと「安全」「正しい」ことは別問題です。この区別ができるかどうかは、本人がどれだけAWSのアンチパターンを知っているかに依存します。

ここでは、新人がAIに丸投げした場合に起こりがちな状況を、よくあるパターンとして3つ挙げてみます（実際に見聞きした事例ではなく、典型例として組み立てた仮想のシナリオです）。

ケース1: IAMポリシーのワイルドカード権限

新人が「Lambda関数からS3バケットに書き込みたい」とAIに伝えると、次のようなポリシーが返ってくることがあります。

{
  "Effect": "Allow",
  "Action": "s3:*",
  "Resource": "*"
}

これは確かに「動く」ポリシーです。しかし、対象バケットを1つに絞るどころか、アカウント内のすべてのS3バケットに対する全操作を許可してしまっています。AIは「要件を満たす最短の答え」を出すことには強いですが、最小権限の原則を踏まえて絞り込むかどうかは、聞き方や検証次第です。新人がポリシーのResource欄の意味を理解していなければ、これがそのまま本番に乗ってしまう可能性があります。

AWS公式のIAMにおけるセキュリティのベストプラクティスでも、必要な権限だけを許可する最小権限の原則が一貫して強調されています。

ケース2: セキュリティグループのポート全開放

「EC2にSSHでログインできるようにしたい」という相談に対して、AIが次のようなインバウンドルールを提案することがあります。

タイプ	プロトコル	ポート	ソース
SSH	TCP	22	0.0.0.0/0

これも「SSHでログインできる」という要件は満たしています。ただ、ソースを全世界に開放しているため、インターネット上の誰でも接続を試行できる状態になります。セキュリティグループが「ステートフルなファイアウォール」であるという感覚がないと、この設定の危なさにそもそも気づけません。

AWS公式のセキュリティグループによるトラフィック制御でも、インバウンドルールで必要な通信だけを許可する考え方が前提になっています。本来は、自社のオフィスIPや踏み台経由など、接続元を限定するのが筋です。より大きな方針としては、AWS Well-Architected Framework のセキュリティの柱でも「多層防御」「最小権限」が設計原則として挙げられています。

ケース3: S3バケットのパブリックアクセス設定

「画像をWebから見られるようにしたい」という要望に対し、AIがバケットポリシーで全員に読み取りを許可する設定を提示するケースもあります。要望自体は間違っていませんが、配信方法には選択肢があります。たとえばCloudFront経由で配信する構成なら、OAC（オリジンアクセスコントロール）とバケットポリシーで特定のディストリビューションからのアクセスだけに絞り、バケット自体は非公開のままにできます。それを「全世界からの直接アクセス」にしてしまうと、意図しないデータまで公開範囲に含まれてしまうリスクが出てきます。

AWSはS3のセキュリティベストプラクティスで、明示的に外部公開が必要な場合を除き、パブリックアクセスブロックを有効にしておくことを推奨しています。「とりあえず見られるようにする」という最短ルートと、「公開範囲を絞った上で見られるようにする」という安全なルートは、AIへの聞き方ひとつで分かれてしまいます。

「動く」と「安全・正しい」を区別する力が育たない

3つのケースに共通しているのは、いずれも「要件としては満たしている」という点です。動くという意味では正解で、テストも通ってしまうかもしれません。

この「動くけど危ない」を判断するには、AWSの各サービスがどういう前提で設計されているか、何がデフォルトで安全で、何がデフォルトで危険なのかを知っている必要があります。AIに最初から完成形を出してもらう癖がついていると、この感覚を養う機会そのものが失われてしまうのではないかと思っています。

トラブルシューティング能力は、自分で詰まった経験からしか育たない

これは個人的な実感に近い話ですが、AWSの運用で本当に役立つ力は、「障害やエラーに遭遇したときに、何から確認すればいいかが分かる」という勘所だと思っています。この勘所は、エラーメッセージを読んで、ドキュメントを当たって、試して、また失敗して、という地味な繰り返しの中でしか育ちません。

AIに聞けばエラーの原因と解決策がすぐ返ってくる環境にいると、この「自分で追いかける」プロセスを経験する機会が減ります。一度や二度ならいいのですが、これが習慣化すると、AIの答えがない・的外れな場面で手が止まってしまう、という状態になりがちです。

それでも反論はある

ここまで「制限すべき」という立場で書いてきましたが、当然反論もあると思っています。いくつか想定して、考えを書いておきます。

「AIを禁止したら学習スピードが落ちるのでは？」

短期的には、その通りだと思います。AIに聞けば数秒で終わることを、自分で調べると数十分かかることもあります。

ただ、ここでの主張は「禁止」ではなく「期間限定の距離感」です。調べ物や概念理解のためにAIを使うことは止めていません。制限したいのは、実装・構築の判断をAIに委ねる部分です。むしろ、この期間に自力で詰まった経験こそが、後々の学習スピードを上げる投資になると考えています。

「今の時代にAIを使わないのは、むしろ非効率では？」

これも一定は同意します。実務に出た後は、AIを使いこなせる方が圧倒的に生産性が高いのは間違いありません。

ただし、それは「AIの提案を検証する目」を持っている前提での話です。検証する目を持たないままAIに頼ると、間違いに気づけないまま効率だけが上がってしまいます。OJT期間は、その「検証する目」を育てる期間だと位置づけています。

「最初からAIと協働する力を育てた方がいいのでは？」

これも筋の通った意見だと思います。実際、AIとの協働スキルは今後ますます重要になっていくはずです。

ただ、協働には「相手の出した答えが正しいかを判断できる」という前提が必要です。判断軸を持たないままの協働は、AIの言うことをそのまま受け入れるだけの関係になりやすく、これは協働とは呼べないのではないかと思っています。順番として、まず自力で判断軸を作ってから、協働のフェーズに入るのが安全だと考えています。

現場でどう線を引くか

実際にOJTの現場で運用するとしたら、次のような線引きが現実的かなと思っています。

調査・学習目的の利用は可：用語の意味、サービスの概要、エラーメッセージの意味を調べるような使い方は妨げない
設計・実装の最終判断はAIに委ねない：IAMポリシーやセキュリティグループの設定など、実際に手を動かす部分は自分で考え、自分の言葉で「なぜこの設定にしたか」を説明できる状態にする
AIを使った場合は、理由をセットでレビューに出す：コードレビューの場で「AIにこう聞いたら、こう返ってきた」だけでなく、「なぜそれが正しいと判断したか」まで説明させる
一定期間後は制限を解く：基礎的なアンチパターンを一通り経験し、AIの提案を自分で検証できるようになったら、利用を解放していく

このあたりは、チームの状況や新人の習熟度によって調整する前提の、あくまで一例です。

さいごに

生成AIは、AWSの設計・構築の現場でも間違いなく強力な道具になっています。否定する気はまったくなく、むしろ使いこなせる人がどんどん増えてほしいと思っています。

ただ、道具を正しく使いこなすには、その道具が出してくる答えを検証できる土台が必要です。新人のうちは、その土台を作ることを優先してほしい、というのがこの記事の主張です。

「なるべく使わせない」というのは、AIを否定する言葉ではなく、順番の話だと捉えてもらえると嬉しいです。

参考リンク

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up