生成AIとは何か、AIOpsへの道となるのか？

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

そうかもしれません。従来の検索エンジンを脅かしたり、高校の小論文や広告コピーを書いたりするだけでなく、より幅広い用途があることは確かです。

生成AIとは

生成AIは、自然言語のプロンプトからテキスト、画像、音声など、さまざまなコンテンツを生成できる機械学習の応用技術です。ChatGPT（OpenAIのプロジェクト）の登場をきっかけに広く普及し、さまざまな業界で新たな用途が急増しました。

ChatGPTをまだ試したことがない方は、少し時間を取って、いくつか質問してみることをお勧めします。たとえば、ご自身や歴史上の人物について尋ねたり、何かの仕組みを説明してもらったりしてみてください。ChatGPTの回答は常に正しいとは限らないため注意が必要ですが、これは新しい体験であり、新たな発見をもたらしてくれます。

ChatGPTは、生成AIの概念実証となりました。これにより、私たちの働き方がどのように変わり得るか、その可能性を垣間見ることができました。また、F5 Office of the CTOにとっては、生成AIをアプリケーションデリバリとセキュリティにどう応用できるかを探る興味深い機会にもなりました。

命令型から宣言型、そして生成型へ

インフラストラクチャにおける課題の1つは、たった1つのアプリケーションを配信し、保護するためにも必要となる無数のデバイス、サービス、システムを構成することです。「as a service」型のサービスを除いても、組織は平均23種類のアプリケーションサービスを利用しています。

言うまでもなく、WebアプリとAPIの保護サービスの設定は、従来のロードバランシングサービスの設定とは異なります。つまり、アプリサービスの設定と運用を担当する人には、十数種類もの異なる「言語」に精通することが求められる場合があります。

業界では長年にわたり、この課題への対応が進められてきました。あらゆるものの設定にAPIを使用することが主流になると、アプリケーションデリバリサービスやセキュリティサービスも例外ではありませんでした。当初は命令型APIが採用されましたが、変わったのはコマンドの発行方法だけです。CLIでコマンドを入力する代わりに、HTTP経由でAPIコマンドを送信するようになりました。

ほどなくして、命令型APIへの依存によって生じる「API税」は負担が大きすぎることが明らかになり、業界は宣言型APIへと移行しました。しかし残念ながら、業界の大半は、宣言型を「JSONによる構成」と捉えました。その結果、宣言型の本来の意図（この「意図」という言葉が重要です。覚えておいてください）である「何をしたいかを伝えてくれれば、こちらで実行します」ではなく、「必要な構成はこれです。あとはそちらで手間のかかる作業をしてください」という形になってしまいました。

これはまったく同じとは言えず、依然として各ソリューション固有の運用モデルについて同等レベルの専門知識が必要でした。ロードバランサーで「プール」と「ファーム」のどちらを使うかについてさえ、業界で合意に至ったことがあるのか疑問です。まして、仮想サーバーが実サーバーやアプリケーションインスタンスとどのように連携するかという、より複雑な詳細についてはなおさらです。結局、宣言型への移行によって業界が行ったのは、コマンドレベルの作業をオペレーターからシステムへ移したことだけでした。

ここで、生成AIがもたらすのは、ローコード／ノーコードの一形態です。これは、結果の生成を導く適切に定義された仕様に基づいているため、ほかの一部の生成結果よりも信頼性が高くなります。結局のところ、「hello world」の書き方は限られていますが、質問への答え方は何百万通りもあります。

つまり、トレーニング済みのモデルに「App Aをスケールできるようにロードバランサーを構成したい」と伝えれば、システムが構成を出力できるはずです。さらに、「Zを使ってシステムY上でXを実行するスクリプトを作って」と指示すれば、あっという間に、構成だけでなく、それを適切なシステムにデプロイするために必要な自動化まで生成できるはずです。

なんと、すでに実現しています。

もちろん、これは本番環境で使用できるコードではありません。IPも認証情報も有効ではなく、選ばれた言語もPythonでした（私にとって第1、第2、第3の選択肢ですらありません）。それでも、公開されているドキュメントと驚くほど簡単なプロンプトだけで、完成までの90%に達しています。プロンプトが詳細であるほど、結果も向上します。生成されたスクリプト全体は長いため、以下には冒頭部分のみを掲載します。

繰り返しになりますが、まだデプロイできる状態ではありません。それでも、実用可能な状態にはかなり近づいており、私がトレーニングを行わなくても、生成には文字どおり15秒もかかりませんでした。

生成から自動化へ

しかし、これは簡単な部分にすぎません。さらに、「ああ、そうそう。ついでにデプロイしておいて」と指示できるべきです。そうすれば、朝のコーヒーを楽しんでいる間に、すべて済ませてくれるはずです。できれば、ちょっとした歌も歌ってくれるとうれしいですね。

しかし、まだ続きがあります。さらに将来、生成AIシステムに「グリーンベイのユーザーからのログインが集中してパフォーマンスが低下しているので、App Aを複製してミルウォーキーの拠点に移して」と指示できるようになったら、どうでしょうか。

そして、実際にそのとおりに動作します。内部では、これらすべてがAPI、構成、コマンドの組み合わせにすぎず、現在でもスクリプトで自動化でき、実際に自動化されることも少なくありません。こうしたスクリプトは多くの場合パラメーター化されており、私のAIプロンプトに含まれるパラメーター、つまりGreen Bay、Milwaukee、App Aとおおむね対応しています。したがって、変わるのは生成手段と生成速度です。

私はよく、AIと自動化は力を何倍にも高めるものだと話しています。テクノロジー自体は何をすべきかを理解しておらず、それを理解しているのは私たちです。しかし、AIと自動化を活用すれば、必要な作業をはるかに迅速かつ効率的に実行できます。その結果、生産性が向上し、価値実現までの時間が短縮されるほか、専門家が戦略的な意思決定やプロジェクトに注力する時間を確保できます。さらに、AIは時間とともに私たちから学習し、私たちの能力を一層高め、新たな可能性を切り開くことができます。

これはもはやSFではなく、コンピューターサイエンスが実現した現実です。

生成AIが、求められるAIOpsを実現

現在のAIOpsソリューションの多くは、98%の組織に不足しているインサイトの提供だけに重点を置いています。

従来の問題には対応できても、将来のニーズには応えられません。

セキュリティサービスのように、より自律的に動作できるAIOpsプラットフォームでさえ、既存の構成や、あらかじめ適切に定義された対応に大きく依存しています。一般に、異種混在するアプリケーションデリバリとセキュリティの各レイヤーにまたがって、運用をより自律的に実行できるようにする目的ではAIを活用していません。AIは、データを分析し、人間には見いだす能力や時間がないインサイトを明らかにするために活用されています。しかし、少なくともネットワークより上位のレイヤーや、十分に理解されているセキュリティ上の問題については、多くの場合、そこで活用が止まっています。

そこで生成AIの出番です。アプリケーションデリバリとセキュリティを「驚くほど簡単」にするため、このテクノロジーの可能性をどこまで広げられるか、徹底的に探究したいと考えています。

AIという氷山の一角へようこそ。

著者について

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。

Lori Mac Vittieのその他のブログ記事