【前編】「AI時代のプラットフォーム変革!」 - 確信を生む"コード×AI×プラットフォーム"の実践知
本記事は 2024/11/12 開催イベント 「プラットフォーム✕コード✕AI - AI時代にそのプラットフォームで大丈夫?」 の内容をもとに執筆されました。
「コード×AI ー ソフトウェア開発者のための生成AI実践入門」(以降「コードAI本」)の著者である 服部佑樹 と、「入門Terraform クラウド時代のインフラ統合管理」を執筆された 草間一人さん(@jacopenさん) が、AI時代のプラットフォーム をテーマに対談した本記事は二部構成の後編です。(以降敬称略)
本記事は二部構成のうちの前編となります。
プラットフォームエンジニアリングの本質 - 開発者体験の抜本的向上
服部:まず草間さんに伺いたいのですが、プラットフォームエンジニアリングって具体的にどういったものなんでしょうか?
草間:プラットフォームエンジニアリングの本質は、開発者の認知負荷を下げることにあります。クラウドネイティブ技術の進化に伴い、開発者が対応すべき技術の範囲と深さは増す一方です。これが開発生産性の低下を招いているんですね。
服部:なるほど。その課題に対してプラットフォームエンジニアリングはどうアプローチするんでしょうか?
草間:共通基盤を作って開発者の負担を減らすというアプローチです。ただし、単に技術的な基盤を作るだけではなく、組織論的な視点も重要です。開発者のニーズに寄り添った、実際に使ってもらえる基盤を作ることが肝心なんです。
AIとプラットフォームの融合ポイント - インテリジェント基盤の可能性
服部:AIとの関係性について、具体的にはどういった接点があると思いますか?
草間:大きく2つの方向性があると思います。1つは「AIを動かすためのプラットフォーム」。例えばOpenAIやAnthropicのような大規模AIサービスは、実はKubernetesの上で動いているんです。膨大な計算リソースを効率的に管理するには、クラウドネイティブなプラットフォームが不可欠なんですね。
服部:なるほど。もう1つの方向性はどうでしょう?
草間:もう1つは、既存のプラットフォームエンジニアリングをAIで強化する方向です。例えば、AIを使ってKubernetesのマニフェストやTerraformのコードを書くといった使い方は、もう当たり前になってきていますよね。
服部:確かにそうですね。今日もInfrastructure as Codeのコードを書く時にどうやってAIを使ったらいいのかは聞こうと思ってたんです。ちなみに運用面での活用事例はありますか?
草間:面白い例として、CNCFのサンドボックスプロジェクトのk8sgptがあります。これはKubernetesクラスタのトラブルやエラーログをAIで分かりやすく説明してくれる仕組みです。プラットフォームに組み込まれることで、運用の質が自動的に向上していくんです。
服部:これはいいですね!私は前職がMicrosoftで、そこで草間さんと絡みがあったわけですけど、当時はクラウドのログを扱うのも多く大変でした。新人エンジニアの学習曲線も緩やかになりそうですね。
草間:そうなんです。従来なら熟練エンジニアの経験が必要だった判断も、AIのサポートがあれば新人でもより早く成長できる。これは大きな変化だと思います。
服部:他はどうでしょう?例えば、プラットフォームエンジニアリングにおける**「セルフサービス」**の重要性について、もう少し詳しく聞かせていただけますか?
草間:従来は開発環境の準備にも運用チームへの申請が必要で、時間もかかっていました。これをポータル経由で自動化し、開発者が自分で必要なリソースを調達できるようにする。これがセルフサービス化の本質です。
服部:今後、AIがセルフサービス化をどう変えていくと思いますか?
草間:クラウドサービスの設定項目は年々増加の一途です。AWSやAzureのコンソールを見ても、初心者には何を選べばいいのか分からない。ここでAIが適切な選択肢を提案してくれれば、より使いやすいプラットフォームが実現できるはずです。
Infrastructure as Code × AI の可能性と課題 - 新たな生産性ブースト
服部:Infrastructure as Code(IaC)とAIの組み合わせについて、率直なところどう思われますか?個人的には、まだまだ課題が多いように感じています。特にAIが扱えるトークン長や精度の問題が大きいと思います。
草間:ええ、確かに現状では課題が山積みですね。例えば、PulumiがリリースしているPulumi AIという製品があります。これは自然言語でインフラ構成を指示すると、自動的にコードを生成してくれる機能なんですが…正直なところ、まだまだ発展途上という印象です。
服部:そうですよね。「こういう環境が欲しい」と一言で伝えても、本当に求めているものが出てくることは稀ですよね。でもAIにただ聞くよりも良さそう!(実際に触って)
草間:その通りです。インフラストラクチャには無数のパラメータや複雑な依存関係が存在します。それを自然言語で一発で正確に表現するのは現状困難なんです。
ただし、興味深いのは、AIが生成するコード自体の質はそれほど悪くないんですよ。明らかな誤りは少なく、基本的には動作するコードを出力してくれます。問題は…
服部:それが本当に求めているものかどうか、ですよね。
草間:はい。例えば「Example」という名前のリソースが生成されたとして、実際のプロダクション環境では全く別の命名が必要になってきます。結局のところ、人間とAIの対話を通じて、徐々に精度を高めていく必要があるんです。
Infrastructure as CodeからInfrastructure as Softwareへ - コードの次なる進化
服部:Terraformのファイル構成について、AI時代になって何か変化は起きそうでしょうか?
草間:面白い質問ですね。ここで少し視点を変えて、Pulumiのアプローチについてお話ししたいんです。Pulumiは自身のことを「IaC」ではなく「IaS (Infrastructure as Software)」と呼んでいるんです。
服部:それは具体的にどういった違いなんでしょう?
草間:Pulumiの特徴は、TypeScriptやJavaScriptといった一般的なプログラミング言語でインフラを定義できる点にあります。これにより、より抽象的な概念でリソースを作成できるんです。
例えば、Terraformの場合、EC2インスタンスを作成するには、EC2本体だけでなく、NIC、Elastic IP、サブネット、VPCなど、5,6個のリソースを明示的に定義する必要があります。一方、IaSの考え方では、「VMが欲しい」という抽象的な指示で、必要なリソースを一括で作成できるんです。
服部:AIは現状「正確に多くの依存関係を扱う」のが難しいですよね。Terraform の場合も適切にファイルを分割したりして工夫をしながらAIとの連携を考える必要があると思っています。
草間:コードは確かにシンプルになりますが、暗黙的に作成されるリソースが多くなり、最終的にどういうインフラが構築されるのか一目では把握しづらくなります。AIが情報を把握するだけでなく、人間側がAIが生成したコードをどう把握するのかも課題です。
服部:AI時代になって、その部分がどう変わるか楽しみですね。
草間:Terraformは冗長で記述量が多いことが課題でしたが、AIがコード生成を支援してくれれば、その負担は大幅に軽減されます。むしろTerraformのように「コードに書かれているものだけが作られる」という明示的な性質が、より価値を持つようになるかもしれません。AIによってコーディングの手間が減れば、多少冗長でも明示的なアプローチのメリットが際立つわけですね。
服部:AI時代だからこそ、明示的なアプローチの価値が高まる可能性があるというのは納得ですね。結局「コード」や「テキスト」になっていることが、「予測可能性」や「透明性」に繋がるわけです。
草間:はい。インフラ構成の「予測可能性」「透明性」は本番環境で極めて重要です。AIがコーディングの負担を減らせば、冗長で明示的なアプローチもそれほど問題にならなくなる。AI時代のIaCは、インフラ定義の在り方自体に影響を与える可能性を秘めているんです。
AIとTerraformコードと依存関係 - 分割と連携の新視点
服部:依存関係の扱い方について、深掘りしてみたいです。IaCのコードを書く時、依存関係は悩ましいですよね。例えば、最近TerraformのGitHub Providerを使っていたんですが、ユーザー名やチーム、リポジトリなどの設定を別ファイルに分けたくなるんですよ。でも、AIに投げようとすると、依存関係のある5つくらいのファイルを全部持っていかないといけなくなったりして。
草間:そうですね。クラウドの簡単な構成なら1ファイルに全部書いて、トークン制限に収めて投げやすいけど、実際の開発では依存関係を考慮してファイルを分割する必要が出てきます。
服部:Terraformって .tf ファイルを全部まとめて実行してくれるのは分かりやすくていいですよね。でも、生成AIに投げる時は、複数ファイルを投げられるとはいえ、1ファイルで完結させたほうが効率的かもしれない。どこで分割するかは悩ましいところです。
草間:目的に応じて柔軟にする必要がありますね。例えば「一つの動作するサービス単位」で分けるなど、新しい分割の仕方もある。適度な分割は必要だと考えています。
服部:なるほど。1万行とかになると人の目でのチェックも大変だから、やはり小さいチャンクで分割するプラクティスはIaCでも同じですね。
草間:そうなんです。デプロイも難しくなりますから、疎結合は必要不可欠。ただ、AIのために特別な書き方をするのではなく、人間にとってのベストプラクティスを維持しながらAIが適応していくのが望ましい。
服部:確かに。最近はRAGで複数ファイルを理解できるAIツールもあるので、無理に1ファイルにまとめる必要はないかもしれません。
草間:Terraformではステートファイルのサイズも考慮が必要です。あまりに大きなIaCファイルは、ステートファイルも肥大化しますから、やはり適度な分割が良いかもしれません。
服部:あと、Terraformのコードを生成AIに書かせると、たまに古いパラメータや存在しない設定が出てきますよね。
草間:それは大きな課題ですね。AIが過去データを基に学習しているので、非推奨な設定を提案してしまうこともあります。ここでVSCodeの拡張機能を使えば、すぐに無効なパラメータを検出できますよ。
服部:なるほど。それは強力なガードレールになりますね。コードAI本でも型アノテーションを利用してエラーを事前に発見する方法を紹介していますが、IaCでも同じ発想が使えるわけですね。
草間:はい。特にメジャーなプロバイダーならリアルタイムで問題を指摘してくれるので、とても有効です。
服部:AI時代の開発環境を考えると、どこまでAIに頼るべきか悩ましいですね。
草間:プラットフォームやインフラの自動化は慎重に進める必要があります。アプリコードならバグがあっても影響は限定的かもしれないけど、インフラコードで間違えるとクラウド破産とか…(笑)
服部:それは怖い!(笑)
草間:AIが誤って大量のリソースを作ったり、セキュリティグループを誤って公開してしまったり…。そのリスクは無視できません。でも、InfraCostのような拡張機能でコスト見積もりも可能だし、Terraform Enterpriseにも見積もり機能があります。コストを確認してからAIの提案を受け入れるようにしましょう。
服部:AIが提案するインスタンスタイプがオーバースペックだったりしますよね。やはりHuman in the Loopは必須ですね。現時点のベストプラクティスは、AIの提案を参考にしつつ、ツールでダブルチェックを行う形でしょうか。
草間:はい。最終的な責任は人間側にあります。完全自動化は魅力的ですが、インフラ周りは慎重に。効率化と安全性のバランスを取ることが重要です。依存関係も、人間の保守性や安全性を軸にAIが適応する形が望ましいですね。
服部:そうですね!
後編ではAIと組織やガバナンスの関係性について取り扱います。お楽しみに!
AIとの協働について書いた**コードAI本、そしてTerraformの入門書**も好評発売中です。ぜひご一読ください!