インフラエンジニア、AIエージェントに技術力で負けてた話【役割が変わった】

この記事の内容

• クラウドインフラエンジニアは、AIエージェントがすでに技術的に上回っている現実を解説します
• Claude Codeを使い、Azure上にTODOアプリを設計・構築するデモを紹介します
• AIエージェントが行う設計ドキュメント作成・計画・実装の一連の流れを追います
• インフラエンジニアの役割がどのように変わりつつあるかを考察します
• AIエージェントをうまく使うために今すぐ取り組むべきことを提言します

AIエージェントはクラウドインフラ領域で「すでに」強い

インフラエンジニア、特にクラウドを主戦場にしているエンジニアの方に向けて、まず率直に伝えたいことがあります。AIエージェントは、クラウドインフラの領域においてすでに技術的に人間を超えています。まだ気づいていない方が大多数だと思いますが、これは現実です。

なぜクラウドなのかといえば、クラウドにはきちんと整備されたAPIとコマンド、そして常時更新される公式ドキュメントがあるからです。物理的なものがない中で、コードを書いて構成を自動化できる世界観が元から備わっています。アプリケーションを作ることと本質的には同じ話であり、AIエージェントはその世界観と非常に相性が良いのです。

私たちの仕事はどう変わったか

かつてインフラエンジニアの仕事は、ポータル画面でどう操作するか、どの設定が必要かを把握して手を動かすことでした。しかし今は違います。

• 何をどのように作るべきかを考える
• セキュリティを守るための設計はどうあるべきか
• そのためにどの技術を使うかを選択し、AIに明確な指示を出す
• 要件をきちんとドキュメントに落とし込み、AIに実装させる
• テストが適切かどうかを確認・判断する

このレイヤーになると、インフラかアプリケーション開発かという区別はほぼなくなります。フルスタックなAIエージェントを複数束ねて管理する立場、いわばAIの管理職としての振る舞いが求められる時代になっています。

さらにその上では、ビジネスとして何をどう回すか、どういうビジネスモデルにするかという視点を持ち、全体を設計してAIに適切に指示できる人が一人いれば、あとは回るという状況になりつつあります。

デモ：Claude Codeにクラウドインフラを丸ごと作らせる

事前準備：複数テナント切り替えコマンド「azt」

複数のAzureテナントを管理している場合、認証の切り替えが煩雑になりがちです。そこで、aztというコマンドを自作しました。これを使うと、対話形式で複数のテナントを簡単に切り替えられます。このような仕組みを作っておくことで、AIエージェントが複数テナントをまたいで作業する際の摩擦を大幅に減らせます。

なお、aztコマンドはAIエージェントに「作って」と指示すれば作ってもらえます。

Claude Codeへの指示内容

Claude Codeに対して、以下のような内容を口頭ベースで指示しました。

• アプリ: コンテナベースのTODOアプリ（フロントエンド + バックエンド）
• インフラ: Azure Container Apps + Azure Database for PostgreSQL Flexible Server
• セキュリティ: アプリ〜DB間はPrivate Endpointで接続、パブリック通信は使わない
• 認証: Managed Identityを使い、シークレットをコードに持たせない
• IaC: Bicepでコードとして表現
• CI/CD: GitHub Actionsでパイプラインを構成、テストも含める
• リポジトリ: GitHubのパブリックリポジトリを使用

指示の仕方はWindowsの標準音声認識でダラダラと喋っただけです。日本語として多少不完全な部分もありましたが、Claude Codeは正確に意図を汲み取りました。

ステップ1：アーキテクチャードキュメントの自動生成

まず「ドキュメントを書いてから実装に入りなさい」と指示したところ、Claude Codeはアーキテクチャードキュメントを自動生成しました。内容は以下の通りです。

• Azure Container Apps（サーバーレスコンテナ、VNet統合対応）
• Azure Database for PostgreSQL Flexible Server（Entra ID認証ネイティブ対応）
• Private EndpointとPrivate DNSゾーンを使ったDB接続、パブリックアクセスは完全無効
• System-Assigned Managed IdentityによるパスワードレスDB接続
• Bicep（6モジュール構成）
• GitHub Actionsの2ワークフロー（PRテスト + mainプッシュ時デプロイ）
• Log Analyticsワークスペースによる監視（指示していなかったが自動的に追加）
• 月額コスト見積もりの記載

アーキテクチャ図はASCIIアートで生成されましたが、MermaidなどのDSLを指定すれば綺麗な図も出力できます。

その後「日本語化してWordの文書にしてください」と指示すると、PythonコードでWord文書を生成し、11章構成の設計書を作り上げました。

ステップ2：実装計画（プランモード）

「実装の計画をしてください」と指示し、プランモードに入らせました。Claude Codeはサブエージェントを起動し、以下を並行して実施しました。

• Azureの各リージョンで利用可能なサービスの確認
• Microsoft Docs MCP経由で最新の公式ドキュメントを参照
• Bicepの最新パターンの確認

リサーチの結果、アーキテクチャドキュメントから以下の変更が提案されました。

計画は5フェーズで提示されましたが、「先にCDパイプラインを作成してからすべてをパイプライン経由で構築するように順序を変えてください」「テストファーストで開発してください」と追加指示したところ、計画を即座に書き直してくれました。

最終的な計画はCI/CD First + TDD（テスト駆動開発）アプローチとなりました。

ステップ3：実装

計画後、コンテキストをクリアして実装を開始させました。GitHub ActionsのワークフローをBicepと合わせて構築し、テストを先に書いて失敗させながら（RED）実装を進め、Azure環境へのデプロイまでを自動で行いました。

最終的にリソースグループ、Container Apps、Managed Identity、Log Analyticsワークスペース、Private Endpointなどが順次作成されていくことが確認できました。

オンプレミス環境はどうなのか

今回の話は「クラウドが前提」として書いていますが、オンプレミスでも本質は同じです。ただし、AIエージェントが操作できるAPIやインターフェースが整備されていないオンプレミスシステムでは、そもそもAIエージェントが動けません。

逆に言えば、AIエージェントがスムーズに動ける環境を持っている組織が「クラウドネイティブになっていた」と評価される時代になりつつあります。AIエージェントを動かそうとして初めて、既存システムのAPIの欠如やアクセス制限がボトルネックとして露わになるケースも増えてくるでしょう。

AIエージェントを賢くする仕組み：スキル化と継続学習

Claude Codeには「スキル」という仕組みがあり、繰り返し使えるパターンをドキュメントとして記録できます。

たとえばAzureへのデプロイを繰り返す中で「まず公式ドキュメントをMCP経由で確認してから実装しなさい」という指示を加えると失敗が減ったとします。そのノウハウを「スキルとして記録しておいて」と一言伝えるだけで、Claude Codeがスキルファイルを自動生成し、以降のセッションで同じ失敗を繰り返さなくなります。

さらに「Continuous Learning」というスキルを使えば、セッション内で得た再利用可能なパターンを自動的に抽出してドキュメント化してくれます。使えば使うほど賢くなる、そういう仕組みが実現できています。

テナント切り替えと環境整備こそが重要

今の自分が注力していることは、個々のAzureサービスの仕様を覚えることではありません。AIエージェントが最新情報をMCPで取得できる環境を整え、複数のテナントを認証切り替えなしにシームレスに操作できる仕組みを作ることです。

1回目の認証だけ人間が行えば、その後はEntra IDのリフレッシュトークンを使ってAIが自動的に認証を維持し続けるような仕組みを構築しています。こうした「AIが動きやすい環境整備」こそが、今のインフラエンジニアに求められているスキルだと考えています。

まとめ

• クラウドインフラはAPIが整備されており、AIエージェントが最も能力を発揮しやすい領域です
• インフラエンジニアの仕事は「手を動かすこと」から「AIに適切な指示を出し、その品質を担保すること」に移行しています
• Claude Codeは、口頭での曖昧な指示から設計ドキュメント・実装計画・Bicepコード・CI/CDパイプライン・Azureへのデプロイまでを一気通貫で実行できます
• スキルによる継続学習の仕組みを活用することで、AIエージェントは使うほど賢くなります
• 今すぐ取り組むべきは「AIエージェントが動きやすい環境整備」であり、個別サービスの仕様暗記ではありません
• デモの成否よりも「こういうことがもうできる時代になっている」という前提に立ち、自分の役割をどう再定義するかを考えることが重要です

車が登場した時に「徒競走で競う」という選択をした人はいないはずです。AIエージェントという「車」が自分の専門領域に入ってきた今、その車をいかにうまく運転するか、安全に自動走行させるか、複数台を同時に管理するかという視点にシフトすることが、これからのエンジニアに求められる姿勢ではないでしょうか。