はじめに
「AIがコードを書いてくれるなら、自分で技術を学ぶ意味ってあるの？」。生成AIの進化を目の当たりにして、こう感じている方は少なくないと思います。
たしかに、ChatGPTやCopilotといった生成AIは、コードの生成やドキュメントの作成をかなりの精度でこなしてくれます。数年前には考えられなかったスピードで「動くコード」が手に入る時代になりました。
でも、ここで一歩立ち止まって考えてみてください。動くコードが手に入ることと、正しいシステムが作れることは同じではありません。
コードはシステムの一部にすぎません。そのコードがどんなサーバーで動き、どのネットワークを通じてユーザーに届き、障害が起きたときにどう復旧するのか。こうしたシステム全体を見渡す力は、まさにインフラ領域の知識そのものです。
この記事では、生成AIが発展している今だからこそ、ITの基礎であるインフラ技術を学ぶべき理由を整理します。
なぜ今「インフラ」なのか
AIは局所最適が得意で、全体設計は苦手
生成AIはとても優秀なアシスタントです。「Nginxの設定ファイルを書いて」「TerraformでVPCを作って」と指示すれば、すぐにそれらしいコードを返してくれます。
ただ、こう聞いてみるとどうでしょう。
「月間100万PVのWebサービスを、ダウンタイムを最小限にしつつ、月額コスト30万円以内で設計して。将来的にはアジアリージョンへの展開も視野に入れたい」
これは単一の設定ファイルでは答えが出ない問いです。トラフィックの特性、データの整合性、コストとのバランス、セキュリティ要件、将来の拡張性。こうした複数の制約を同時に考慮して最適解を導く作業は、生成AIが苦手とする領域です。
AIは「部分的に正しいもの」を高速に生成することには長けています。でも、部分を組み合わせて全体として整合性のある設計にする判断は、依然として人間の仕事です。そしてその判断に必要なのが、インフラの知識なわけです。
パフォーマンス、セキュリティ、可用性は人間の理解が不可欠
システムの品質を決める非機能要件、たとえばパフォーマンス、セキュリティ、可用性といった領域は、コードを書くだけでは解決しません。
- 「レスポンスが遅い」原因がCPUなのか、メモリなのか、ネットワークなのか、ディスクI/Oなのかを切り分ける
- セキュリティグループの設定が適切かどうかを判断する
- 単一障害点がどこにあるかを特定し、冗長構成を設計する
これらはいずれも「なぜそうなっているのか」という仕組みの理解が前提になります。AIにコードを生成してもらうことはできても、その設定が自分たちの環境において安全かどうかを判断するのは、基礎知識を持った人間の役割です。
実装スキルの価値は「消えた」のではなく「変わった」
コードを書く作業そのものの比重が下がっている
正直なところ、「コードを1行ずつ手で書く」という作業の市場価値は、以前に比べて下がってきています。生成AIがある程度の品質のコードを瞬時に出力できる以上、コードを書くスピード自体は差別化要因になりにくくなったと言えるでしょう。
ただ、これは「実装スキルが不要になった」という意味ではありません。
重要になったのは「AIを正しく使う力」
AIが生成したコードをレビューして問題を見抜く力、AIに対して的確な指示を出す力。これらは従来の実装スキルがベースになっています。
たとえば、AIにTerraformのコードを生成させたとき。
- セキュリティグループが
0.0.0.0/0で全開放になっていないか - S3バケットのパブリックアクセスがブロックされているか
- IAMポリシーが最小権限の原則に従っているか
こうした判断は、インフラの仕組みを理解していなければできません。
生成AI時代に求められるのは、「何を作るべきか」を定義する要件定義力と、具体的な実装を抽象的な概念として捉える抽象化力です。そしてこれらの力は、基礎知識の上にしか築けません。
IT基礎とは具体的に何か
「インフラの基礎が大事」と言われても、何を学べばよいのかが見えないと動けません。ここでは、IT基礎として押さえるべき領域を具体的に整理します。
OS（Linux、プロセス、メモリ管理）
すべてのアプリケーションはOS上で動いています。Linuxのプロセス管理、メモリの使われ方、ファイルシステムの構造を理解していると、「アプリが遅い」「メモリが足りない」といった問題に対処できるようになります。
実務との接点を挙げると、たとえばEC2インスタンスのサイジングがあります。「t3.mediumで足りるのか、m5.largeにすべきか」を判断するには、CPUとメモリがそれぞれどう使われているかを理解している必要があります。
ネットワーク（TCP/IP、DNS、HTTP）
ネットワークは、すべてのサービスをつなぐ通信の基盤です。TCP/IPの階層モデル、DNSの名前解決、HTTPのリクエストとレスポンスの仕組みを知っていると、通信トラブルの切り分けができるようになります。
「ページが表示されない」という障害が起きたとき。DNS解決の問題なのか、TCP接続の問題なのか、HTTPレスポンスの問題なのかを切り分けられるかどうかで、対応速度がまったく違います。
ハードウェア（CPU、メモリ、ストレージ）
クラウドの時代でも、物理的なリソースの特性を知っていることは重要です。
- CPU: コア数が増えれば並列処理に強くなるが、シングルスレッド性能も用途によっては重要
- メモリ: 容量が足りないとスワップが発生し、性能が急激に劣化する
- ストレージ: HDDとSSDの特性の違い、IOPS（1秒あたりの読み書き回数）の概念
AWSのインスタンスタイプやEBSのボリュームタイプを選ぶ判断は、これらの知識が前提です。
セキュリティ（認証、暗号化）
セキュリティは後づけではなく、設計段階から組み込むものです。
- 認証と認可: 「この人は誰か（認証）」と「この人は何ができるか（認可）」は別の概念
- 暗号化: 通信の暗号化（TLS）と保存データの暗号化（Encryption at Rest）の両方が必要
- 最小権限の原則: IAMポリシーやセキュリティグループで、必要最低限のアクセスだけを許可する
セキュリティの不備は事業に直結するリスクです。AIが生成した設定をそのまま使うのではなく、セキュリティの観点から検証できる力が求められます。
データベース
アプリケーションのデータはデータベースに保存されます。RDB（リレーショナルデータベース）の基本であるSQLやトランザクション、インデックスの仕組みを理解していると、「クエリが遅い」問題への対処やデータ設計の判断ができるようになります。
また、RDBとNoSQLの使い分け（DynamoDB、Redisなど）は、システムの特性に応じた設計判断に直結する知識です。
分散システムと可用性設計
現代のWebサービスの多くは、複数のサーバーが協調して動く分散システムです。
- レプリケーション: データを複数拠点にコピーして冗長性を確保する
- スケールアウト / スケールアップ: 負荷に応じてサーバーを増やすか、スペックを上げるかの判断
- 単一障害点（SPOF）の排除: 1箇所が壊れてもシステム全体が止まらない設計
「可用性99.9%を担保する」と言われたとき、それが年間どれだけのダウンタイムを意味するかを理解し、それを実現する構成を考えられることが、インフラエンジニアに求められる力です。
可観測性（ログ、メトリクス、トレース）
システムの内部状態を把握するための仕組みも、重要なインフラ知識です。
- ログ: アプリケーションやミドルウェアが出力するイベント記録。障害時の原因調査に使う
- メトリクス: CPU使用率、メモリ消費量、リクエスト数などの数値データ。異常検知やキャパシティプランニングに使う
- トレース: マイクロサービス間のリクエストの流れを可視化する。どのサービスで遅延が発生しているかを特定できる
障害が起きてから「ログを仕込んでおけばよかった」と後悔するのは、インフラあるあるです。可観測性は設計段階から考慮すべき領域です。
インフラとクラウドの関係
クラウドは「インフラの抽象化」
AWSやGCPといったクラウドサービスは、物理サーバーの調達や管理をクラウド事業者に任せることで、インフラの構築・運用を効率化するものです。
ただ、ここで誤解されやすいのが、クラウドを使えばインフラの知識はいらない、という考え方です。
実際にはその逆です。クラウドはインフラの概念を抽象化したものなので、元の概念を理解していないとクラウドサービスの選定や設定を正しく行えません。
具体的な対応関係を見てみましょう。
| インフラの基礎概念 | AWSでの対応サービス |
|---|---|
| 物理サーバー | EC2 |
| ネットワーク（サブネット、ルーティング） | VPC、サブネット、ルートテーブル |
| ロードバランサー | ALB / NLB |
| DNS | Route 53 |
| ストレージ | S3、EBS、EFS |
| リレーショナルDB | RDS |
| ファイアウォール | セキュリティグループ、NACL |
| 監視 | CloudWatch |
| 認証・認可 | IAM |
左の列を理解せずに右の列だけ覚えても、応用が利きません。「VPCとは何か」を理解するには、まずサブネットやルーティングの概念がわかっている必要があります。「RDSのリードレプリカ」の意味は、レプリケーションの仕組みを知っていて初めて理解できます。
基礎概念 → クラウドサービス の順序で学ぶのが、結果的にもっとも効率的です。
AI × インフラ: 基礎があるからこそAIを活かせる
AIが得意なインフラ業務
生成AIはインフラ業務のさまざまな場面で活用できます。
- 構成コードの生成: 「VPC + パブリック/プライベートサブネットの構成をTerraformで作って」と伝えれば雛形が手に入る
- 設定ファイルの作成: NginxやPrometheus、GitHub Actionsのワークフローなど、定型的な設定の生成
- 障害ログの解析: エラーログを貼り付けて原因候補を挙げてもらう
- ドキュメントの下書き: 構成図（Mermaid記法）や手順書の初稿を作成する
- 技術のキャッチアップ: 「ALBとNLBの違いは？」のように、概要の把握を素早く行う
これらの作業をAIに任せることで、エンジニアは設計判断やレビューといった、より本質的な業務に集中できます。
ただし、基礎がないと「正しさ」を判断できない
ここが重要なポイントです。AIが出力したものをそのまま使える場面と、人間の判断が必要な場面は明確に異なります。
たとえば、AIにTerraformコードを生成させたとき。
resource "aws_security_group_rule" "allow_all" {
type = "ingress"
from_port = 0
to_port = 65535
protocol = "-1"
cidr_blocks = ["0.0.0.0/0"]
security_group_id = aws_security_group.main.id
}このコードは「すべてのポートをインターネット全体に公開する」設定です。構文としては正しいですが、本番環境でこのまま使えば重大なセキュリティリスクになります。
この問題に気づけるかどうかは、セキュリティグループの仕組みとCIDR表記の意味を理解しているかどうかにかかっています。AIが出力した「構文的に正しいもの」が「運用上も正しいか」を判断する力。これが基礎知識の価値です。
「AIがあるから学ばなくていい」への回答
最後に、よくある反論に対して整理しておきます。
「AIに聞けばわかるから、覚える必要はない」
たしかに、個別の事実（「Nginxのデフォルトポートは80番」など）をすべて暗記する必要は薄れています。調べればすぐにわかるからです。
ただ、調べた結果を理解するための土台は、自分の中に持っている必要があります。
AIに「アプリが落ちる原因は？」と聞いて「OOM Killerによってプロセスが終了されています」と返ってきたとき。メモリ管理の仕組みを知らなければ、なぜ落ちたのかすら理解できません。
知識は「暗記」と「理解」の2層に分けて考えるとわかりやすいです。
- 暗記レベルの知識: AIに任せてよい。設定値やコマンドのオプションなど
- 理解レベルの知識: 自分の中に持っておく必要がある。仕組みや概念、設計判断の根拠
AIは暗記を代替してくれますが、理解を代替してくれるわけではありません。
「AIの進化で、いずれ全部自動化されるのでは？」
将来的にAIがさらに進化する可能性は十分にあります。ただ、現時点で「いずれ不要になるかもしれないから学ばない」という判断は合理的ではありません。
理由はシンプルです。基礎を学んだ人は、AIがさらに進化したときにもっとも恩恵を受ける立場にいるからです。AIの出力を正しく評価し、より高度なタスクをAIに任せ、自分は設計や判断に集中できる。基礎があるからこそ、AIの進化をレバレッジとして活かせます。
一方、基礎がないままAIに頼り続けると、AIの出力の正誤を判断できず、問題が起きたときに自力で対処する手段がありません。
まとめ
この記事では、生成AI時代においてインフラ技術を学ぶ意義について整理しました。
ポイントを振り返ります。
- AIは局所的なコード生成は得意だが、システム全体の設計判断は苦手。全体を見渡す力はインフラの知識から来る
- 実装スキルの価値は「消えた」のではなく「変わった」。AIを正しく使うためにこそ、基礎知識が必要
- IT基礎として押さえるべき領域は、OS、ネットワーク、ハードウェア、セキュリティ、データベース、分散システム、可用性設計、可観測性
- クラウドはインフラの抽象化。基礎概念を理解してからクラウドサービスを学ぶのが効率的
- AIが出力した構成やコードの正しさを判断するには、仕組みの理解が前提になる
- 「暗記」はAIに任せてよいが、「理解」は自分の中に持っておく必要がある
生成AIは、インフラエンジニアの仕事を奪うものではなく、基礎力を持ったエンジニアの生産性を大きく引き上げてくれるツールです。
だからこそ、今のタイミングでインフラの基礎を固めておくことには価値があります。AIの進化が速い時代だからこそ、変わらない基盤を持っている人が強い。まずは自分が弱いと感じる領域から、一つずつ学び始めてみてください。
コメント