はじめに

生成AIが話題になる中で、最近はAWS CDKを使ってインフラを生成することにハマっています。

その過程で、 IaC（Infrastructure as Code） が生成AIによってどのように進化していけるかを考えてみました。

そこで、 IaP（Infrastructure as Prompt） という新しい言葉を生み出して、この概念をうまく説明できないかと試行錯誤してみたわけです。

本記事では、IaCとプロンプトエンジニアリングの類似点を掘り下げ、IaPの可能性や現時点での課題について一緒に考えてみましょう。

そして、現時点ではIaPという概念は成り立たず、最終的な結論としてはIaCが引き続き優れた選択肢であることをお伝えします。
（ハードルを下げて、お読みくださいませ・・・）

IaC（Infrastructure as Code）と生成AIのプロンプトエンジニアリングの類似点

1. 宣言的アプローチ

IaCでは、コードを使って望むインフラの状態を宣言的に定義し、ツールがその状態を実現します。

同様に、プロンプトエンジニアリングでは、生成AIに対して望む出力を自然言語で指示します。

どちらも高レベルの指示から具体的な成果物を生成する点で共通しており、「何をしたいか」を中心に書いていきます。

2. 反復的な改良

どちらも、一回で完璧な結果を得ることは難しく、何度も改良が必要です。

IaCではインフラコードを繰り返し修正して最適化し、プロンプトエンジニアリングでもプロンプトを調整してAIの出力を改善します。

このプロセスは、まるで彫刻のように少しずつ理想の形に近づけていく作業です。

3. 再利用性とバージョン管理

コードやプロンプトをバージョン管理して再利用することで、効率を上げることができます。

この点も似ていて、一度うまくいったコードやプロンプトを使い回すことで、一貫性のある成果物が得られるのです。

4. 抽象化とモジュール化

複雑なインフラを扱う際、IaCではモジュールやテンプレートを使います。

同様に、プロンプトエンジニアリングでもテンプレート化したプロンプトを使うことで、作業を効率化しています。

このような抽象化は、実際の業務をシンプルにし、焦点を重要な部分に合わせる助けとなります。

提案： IaP（Infrastructure as Prompt）の新しい使い方

概要

IaPは、プロンプトを用いてインフラストラクチャを生成する手法です。

具体的には、　AWS CDK（Cloud Development Kit） を活用して、自然言語のプロンプトからインフラを自動生成・デプロイすることを目指しています。

これによって、技術的な知識が少ないユーザーでも、直感的にインフラを構築できるようになります。

AWS CDKとは？

AWS CDKは、プログラミング言語を使ってクラウドインフラを定義・デプロイできるオープンソースのフレームワークです。

TypeScript、Python、Java、C#など、複数の言語に対応しており、開発者が既存のプログラミング知識を活かしてインフラをコードとして管理できます。

CDKの強みは、抽象化された高レベルのコンポーネントを提供することで、インフラ構成をよりシンプルにできることです。

IaPの具体例

プロンプト入力
ユーザーが、望むインフラストラクチャを自然言語で記述します。
例：「高可用性のウェブアプリケーション環境を構築してください。ロードバランサーとオートスケーリングを含み、データベースはマネージドのPostgreSQLを使用します。」
AIによるコード生成
このプロンプトを受け取った生成AIモデル（例：GPT-4o）が、対応するAWS CDKのコードを生成します。AWS CDKの強力な抽象化機能を使うことで、複雑なインフラ構成を簡潔なコードで表現できます。
コードのレビューと修正
ユーザーは生成されたコードを確認し、必要に応じてプロンプトやコードを修正します。AWS CDKを使うことで、コードの可読性が高まり、修正も簡単に行えます。
デプロイ
最終的なコードをAWS CDKでデプロイします。CDKはCloudFormationを基盤としているため、信頼性の高いデプロイが可能です。

メリット

直感的なインフラ定義：コーディングの知識が少ないユーザーでも、自然言語でインフラを構築できます。
迅速なプロトタイピング：複雑な設定を短時間で生成できるため、アイデアを素早く形にできます。
AWS CDKの活用：高レベルの抽象化と豊富なライブラリにより、生成されたコードの品質が向上します。

デメリット

非効率性：生成されたコードが必ずしも最適でない可能性があり、手動での調整が必要になることがあります。
不確実性：AIがプロンプトを誤解し、意図しないインフラを構築するリスクもあります。

新規性

次元の異なるアプローチ：これまでのコードベースの定義から、プロンプトベースの定義に移行するという大きなパラダイムシフトです。
IaCとプロンプトエンジニアリングの融合：インフラの定義とAIの生成能力を組み合わせ、新しい開発の流れを作り出します。

IaCと生成AIのプロンプトエンジニアリングの決定的な違い

1. 決定性と非決定性

IaC：いつでも同じコードから同じインフラが作られるため、決定的です。
プロンプトエンジニアリング：非決定的で、同じプロンプトでも結果が異なることがあります。

2. 再現性と信頼性

IaC：高い再現性があり、テストやバージョン管理が容易です。
プロンプト：結果が変わりやすく、信頼性に欠けることがあります。

3. 抽象度と具体性

IaC：リソースと設定を詳細に定義します。
プロンプト：高レベルの指示を与え、具体的な実装はAIに任せる形です。

4. エラーハンドリングとデバッグ

IaC：エラーが明示的に示され、デバッグがしやすいです。
プロンプト：エラーが曖昧で、原因を特定するのが難しいことがあります。

5. バージョン管理とテスト

IaC：コードとして管理するため、バージョン管理やテストが容易です。
プロンプト：バージョン管理やテスト手法が確立されていないのが課題です。

互いのメリット・デメリット

IaCのメリット

決定性と再現性：一貫した結果が得られます。
詳細な制御：インフラのすべての側面を細かくコントロールできます。
バージョン管理とコラボレーション：コードを使ってチームでの協力が容易です。
自動化とスケーラビリティ：CI/CDに組み込んで、自動デプロイが可能です。

IaCのデメリット

学習コスト：専門的な知識が求められるため、学習には時間がかかります。
冗長性：シンプルなタスクでもコードが冗長になることがあります。

プロンプトのメリット

簡易性：自然言語で指示できるため、非技術者でも利用しやすいです。
迅速な生成：複雑な設定を短時間で生成できます。
創造性：柔軟な表現で新しいアイデアを引き出せます。

プロンプトのデメリット

非決定性：結果が予測不可能で、一貫性がない場合があります。
制御性の欠如：細かい設定や調整が難しいです。
再現性の低さ：同じプロンプトでも結果が変わることがあります。

IaP（Infrastructure as Prompt）の使い所の提案

これは生成AIの使い所でよく言われることですが、IaPとして実運用することは難しいですが、IaPの使い所を絞り出してみました。

1. 迅速なプロトタイピングとアイデア出し

用途：新しいインフラのアイデアや構成を試したいときに便利です。
メリット：自然言語で要件を記述するだけでAIが初期のインフラ構成を提案し、時間と労力を節約できます。
実装例：「高可用性のウェブアプリ環境」と書いて、AIがその要件に合ったCDKコードを生成します。

2. 非技術者とのコミュニケーションブリッジ

用途：ビジネス部門やクライアントからの要件を技術チームに伝える際の橋渡し。
メリット：非技術者が自然言語で要件を述べ、それをもとにAIが技術的なインフラ提案を生成することで、誤解が減ります。
実装例：営業チームが要件を入力し、AIがインフラ構成を生成して技術チームに渡す。

3. 教育と学習のツール

用途：クラウドインフラやIaCの学習者にとっての教育ツールとして使えます。
メリット：プロンプトから生成されたコードを分析することで、インフラ構成の理解が深まります。
実装例：学習者がプロンプトを入力し、生成されたコードを専門家が解説する。

現時点でのIaPの課題とIaCの優位性

再現性の欠如

IaCを使うにあたって一番重要なポイントである、再現性がIaPでは満たすことができません。

IaPはプロンプトに基づいてAIがインフラを生成するため、同じプロンプトでも結果が異なることがあり、信頼性の確保が難しいです。
これは、安定性を求める現場にとって大きな問題です。

信頼性と制御性の不足

IaCはコードとして明確に定義されており、エラーの特定や修正が容易です。
一方で、IaPでは生成されたコードのエラーや意図しない設定を特定するのが難しいため、信頼性に欠ける場合があります。

バージョン管理とテストの難しさ

IaCはコードとして扱われるため、バージョン管理や単体テストが簡単に行えますが、IaPではその管理手法が確立されていないため、品質を保つのが難しいのです。

セキュリティとコンプライアンスのリスク

生成AIが意図しないリソースや設定を提案してしまうリスクがあり、セキュリティ基準を満たさないインフラが構築される可能性があります。
IaCでは、これらを明示的に管理することでセキュリティリスクを軽減できます。

結論：現時点ではIaCが依然として優れた選択肢

IaPは、生成AIとIaCの融合により、インフラ構築の新しい可能性を広げる面白いアプローチだと思い考えてみましたが、成り立ちませんでした。
現段階では、IaCの要件を満たせません。

AWS CDKを活用することで、IaPの可能性を広げることができますが、信頼性と再現性を確保するためには専門家によるレビューや適切な検証が欠かせません。

そのため、現時点では安定性と信頼性を重視するインフラ構築には、IaC（Infrastructure as Code） が最も適した選択肢と言えます。
AWS CDKのようなツールを使ってIaCを学び、そのベストプラクティスを実践することが重要です。

まとめ

IaP（Infrastructure as Prompt） という新しい言葉を作り出して、成り立たないか考えてみましたが、うまくいきませんでした。
タイトルが出落ちになってしまい大変申し訳ありません。
お読みいただきありがとうございました。