生成AIのユースケース：ナレッジ活用からチケット管理まで
ハイト氏がすぐに利用できる具体的なユースケースとして紹介したのが、以下の5つである。
コード生成
運用チームは、開発チームと比べてコードを書く機会は少ないが、スクリプト作成はあるはずだ。また、テンプレート作成やワークフロー作成もあるだろう。あるいは、コードを利用し、ITインフラ運用やプロビジョニングを自動化する「Infrastructure as Code（IaC）」の手法を採用しているかもしれない。このような場合に、生成AIを適用できるかを検証する価値はある。
文書生成
運用チームも開発チームと同様に、業務上での文書作成を好まない傾向が見られる。パフォーマンス評価の材料になるのでなければ、自発的にはやりたくないのが本音かもしれない。しかし、生成AIを使えば、ログを検証して、オペレーションに関する文章を出力してくれる。また、Slackを使ってインシデントに対応している場合、会話の内容をインプットにし、レポートを作成する使い方もある。面倒な作業の手間を軽減してくれるのが生成AIだ。
仮想サポートエージェント
ヘルプデスクでインシデントのチケット発行を行うとき、通常はエンドユーザーにいくつかの質問をする。この時のチケット内容の質は、得られる情報の精度に比例する。ここで生成AIベースのチャットボットを配置すれば、担当者によるバラツキを減らし、チケット内容の充実が期待できる。また、プロンプトに「改善点があったら教えて」と構成図と共に入力し、具体的な提案を得る使い方は、特定のアプリケーションの運用性を高めることに役立ちそうだ。
チケットサポート
ITインフラ運用に伴う作業を自動化する「サイトリライアビリティエンジニアリング（SRE）」の方法論が注目されている。同じインシデントが起きないよう、チケットのレビュー、インシデントレポートのレビュー、スクリプト作成、自動化のためのアーティファクト作成などで、生成AIを利用できる。また、ログファイルから運用上の問題を分析する使い方も出てきた。「何か異常はないか、チェックして」と入力すると、将来、問題になるかもしれない予兆とその対策を提案してくれる。
コンテンツ分析と要約
データ分析とレポート作成は運用チームにとって負担の大きい仕事だ。2024年7月にはCrowdStrikeの大規模障害が社会問題になった。事前に生成AIにアドバイスを求める使い方ができていたら、事態はどう変わっていただろうか。また、いろいろな問題が繰り返し発生することがあるが、ナレッジを蓄積しておくことで、クエリーへの回答として提供できるようになる。関係者に話を聞くよりもこちらの方が合理的だ。
対コスト効果で考える生成AI投資の成功ポイント
実際の運用チームの生成AI採用では、組織起点とベンダー起点の2つがあるとハイト氏は説明していた。仮想サポートエージェントのユースケースで紹介した構成図の分析のように、既存の製品ではできないことがある反面、生成AIの機能が組み込まれている既存の製品で対応できることもある。「ユースケースの特定にベンダーの力を借りるのは悪いことではないが、ベッタリ依存することはお勧めできない。ベンダーにサポートを依頼する場合、どうしても視点が偏る懸念がある」と指摘した。
代わりにハイト氏が推奨したのが、図5に示すプリズムモデルを使うことだ。「プリズムモデルは、自社の想定ユースケースはどのカテゴリーに当てはまるか、自分たちの立ち位置はどこかを確認する時に役立つ。立場の違う人たちからの意見がそれぞれに異なっていたとしても、漫然と聞き流すことなく、良く検証してほしい。ディスカッションツールとして使う想定で用意した」と述べた。
今後に向けては、マルチエージェント時代の到来が予想される中、AIテクノロジーは自律型に向かうだろう。ハイト氏は、自動運転車の実用化プロセスと同様に、「Human in the Loop（プロセスの始まる時に人間が中に入る）」から、「Human on the Loop（プロセスで行われたタスクの検証を人間が行う）」を経て、最終的には「Human out of the Loop（プロセスの最初から最後まで人間が関わらない）」へと、段階的にAIが進化していくと予測している。
今は運転時にハンドルから手を離せないが、手を離しても安全に運行する。さらにその先には、ただクルマの中で座っていれば目的地に着く。AIができることが増えれば、もしかしたらデータセンターも自動運転になる時代が来るかもしれない。あるいは、サーバーラックの中のロボットが自律的に仕事をするようになるかもしれない。ユースケースを厳選して導入したら、価値を証明する。そして戦略的に導入を拡大していくことが、AIの進化と並行しての現実的な活用戦略になりそうだ。
