生成系AIとは何か、AI Opsの実現手段となるのか

インフラストラクチャにおける課題の一つは、たとえ1つのアプリケーションであっても、これを導入してセキュリティを確保するために必要な無数のデバイス、サービス、およびシステムを設定しなければならないことです。組織は平均で23の異なるアプリケーション サービスを利用しています（「As a Service」製品を除く）。

ここでは、Web App and API Protectionサービスの設定と単純な旧式のロード バランシング サービスの設定の違いについての解説は割愛します。それは、アプリケーション サービスの設定と運用の担当者に求められることは、さまざまな「言語」に精通することだからです。

AI業界は、長期にわたって言語に対処しようと努めてきました。APIを使用してあらゆるものを設定するようになると、アプリケーション デリバリ サービスやセキュリティ サービスも例外ではなくなりました。誰もが命令型APIをスターティング ポイントとしていましたが、コマンドの発行方法が大きく変わりました。CLIでコマンドを入力する代わりに、HTTP経由でAPIコマンドを送信するようになったのです。

命令型APIへの依存によって被ったAPIの代償があまりにも高いことが明らかとなるのに時間はかかりませんでした。業界は宣言型APIにシフトしました。しかし、業界のほとんどが宣言型と判断したものは実際には「JSONとしての設定」でした。そのため、「何をしたいのか教えてくれればやってあげるよ」的な宣言型の意図（この言葉は非常に大事なので忘れないでください）ではなく、「自分が欲しい設定はこれだよ。大変だけどやってくれるよね」で終わってしまったのでした。

少し違うかもしれませんが、あるソリューションに特有の運用モデルについて同等レベルの専門知識が必要であることに変わりはありません。ロード バランサで「プール」を使用するのか「ファーム」を使用するのか、業界内で意見が一致しているとはいえません。ましてや複雑な状況では、仮想サーバが実際のサーバやアプリケーション インスタンスとどのように対話するのか、意見の一致を見ることなど不可能です。結果的に業界が宣言型で行ったことは、コマンドレベルの処理をオペレータからシステムへ肩代わりさせることでした。

生成系AIがもたらすものは、ロー コード/ノー コードという形式です。これらは結果の生成を導く整形式の仕様に基づいているため、信頼性は一部の結果より高くなります。結局、質問に答える方法は無数にありますが、「hello world」を記述できる方法は限られているのです。

これは、「アプリケーションAをスケーリングするようにロード バランサを設定したい」ことを登録モデルに指示できる能力が必要となり、また、システムは設定を生成できなくてはならないことを意味します。しかし、それだけでなく、「Zを使用してシステムYにXを実行するスクリプトを渡せ」と指示できる能力が必要です。設定を生成するだけでなく、適切なシステムに展開するために必要な自動化を生成できなくてはならないのです。

以下をご覧ください。

自動化はけっして難しい作業ではありません。導入の自動化さえできそうです。朝のコーヒーを楽しんでいる間に、鼻歌を歌っている間に事は済むかもしれません。

でも待ってください。まだありました。もし、「グリーン ベイのユーザーが大量にログインしてきてパフォーマンスが低下したよ。アプリケーションAを複製してミルウォーキーのサイトに移動してくれないかな」と指示を出したらどうなるでしょうか。

大丈夫です。なぜなら、表面下では、このような指示も、API、設定、およびコマンドの網に過ぎないからです。API、設定、コマンドは目下、スクリプトによって自動化することができ、またしばしば自動化されています。これらのスクリプトはパラメータ化されていることが多く、AIプロンプトの中のパラメータは何かということとも緩やかな相関性があります。ここでは、グリーン ベイ、ミルウォーキー、アプリケーションAです。変化するのはジェネレータであり、生成できる速度です。

私は、AIと自動化は能力増強要素であると思っています。仕事の内容をテクノロジに理解させることはできませんが、人間なら理解できます。しかし、AIと自動化ならもっと早く効果的に理解することができ、生産性を効率よく向上させてTTVを短縮し、専門家が戦略的な意思決定とプロジェクトに集中できる時間を増やすことができます。そして時間とともに、AIは私たちから多くのことを学習し、私たちの能力をさらに増強して、新しい可能性を生み出します。

これはもはや空想物語ではなく、コンピュータ サイエンスがもたらす現実です。