生成AIは、精度の向上やアプリケーションの使いやすさにより、いま世界中で注目されています。システム開発でも活用が進んでいますが、誤った判断が許されないシステム運用に活用するには、課題もあります。今回は、生成AIの特長や利用上の注意点などを踏まえ、「PagerDutyが生成AIを活用する際に重視したポイント7つ」をご紹介します。
目次
まず、生成AI（ジェネレーティブAI）とは、機械学習の手法である「ディープラーニング（深層学習）」を用いて、学習済みデータから新たなオリジナルデータを生成するAIです。
生成AIは、決められた行為の自動化を目的とした従来のAIとは異なり、生成のための自己学習が継続できます。これにより、AI自身によるオリジナルコンテンツの創造が実現しました。
生成AIにはさまざまな種類があり、おもな種類には「テキスト生成AI」「画像生成AI」「音声生成AI」などが挙げられます。
生成AIは、自動化・効率化の推進からクリエイティブ生成まで、幅広い分野での活用が期待される技術です。
生成AIが注目されるようになった理由は、コンピューター技術の進化にともなう精度の向上にあります。AIの大量学習が実現して結果の精度が上がっただけでなく、生成に要する時間も大幅に短縮され即座に結果の出力をすることが可能になりました。これにより、業務での使用も可能になっています。
さらに、アプリケーション操作が簡単で、誰でも生成AIを利用できることも大きく影響しているでしょう。AIに関する専門的知識を持たずとも、生成AIを操作してコンテンツを生成できるため、ビジネスだけでなく日常的にも利用でき、身近なものとなっています。
また、生成AIの特長による、以下のような活用メリットも注目を集めています。
生成AIにはさまざまなタイプが存在し、それぞれ異なる領域での応用が可能です。そのため、生成AIは幅広い分野での活用が進んでいます。 ここからは、システム開発・運用の分野における生成AIの活用事例を紹介します。
最近注目される使用方法として、自然言語処理技術（NLP）を活用し、人間がテキストで出す指示や要件をもとに、プログラミングコードを自動生成できます。
さまざまなプログラミング言語のコード生成や大量のコードデータベースから、言語のパターンやコマンド、文法などを学習し、関連するコードの提案も可能です。コード生成AIを利用すれば、プログラミング未経験者も基本のコード構造の学習や簡易プログラムの自動生成が可能です。
プログラミング経験者であれば、プログラミング中のコード自動補完のほか、バグ修正、リファクタリングなど、より高度な活用ができ、より効率的な開発を実現できるでしょう。
システムの開発・運用を円滑に進めるために、DevOpsの重要性が高まっています。生成AIは、インシデント対応のアシスタントとして、DevOpsの推進もサポートすることが可能です。
生成AIを用いれば、インシデントデータの収集・処理やサマリーの生成、進捗状況・課題などの洞察も自動化できます。さらに、インシデント関連のデータ収集をリアルタイムに行ない、詳細なレポートを作成させることも可能です。
生成AIは、DevOps管理ツールとの連携により、インシデント対応の迅速化や効率化、解決時間の短縮が実現できます。また、AIによる適切な対策の提案により、システムの安定稼働も可能になるでしょう。
生成AIは機械学習モデルの一つであり、その性質上、できないことや注意すべき点もあります。
生成AIの活用においては、以下が課題として挙げられます。
生成AIは学習データに基づいて生成を行なうため、学習に使用するデータが生成の質を決定づけます。
不十分なデータや偏ったデータを基にした場合には、正確な分析や予測が難しくなる可能性が高いでしょう。また、AIが偏見を持つこともあるため注意が必要です。
AIは、アルゴリズムやプログラムによって動作します。
しかし、それらには倫理観や道徳観はプログラムされていないため、生成AIでは倫理的かつ道徳的な意思決定はできません。AIはあくまでもデータが導き出した最適解を提供するものであり、その解が常に倫理的・道徳的に正しいとは限らないのです。
また、生成AIは本物との見分けがつかないほど、精度の高い偽の画像や音声、動画などのクリエイティブを作り出すことも可能です。これらの悪用により、ディープフェイクのような偽情報の拡散や個人のプライバシー侵害、詐欺などの社会的問題が生じるリスクもあります。
生成AIには、なぜその答えを出したのか、AIの思考回路がわからない「ブラックボックス問題」があります。
機械学習は、AIが自らの判断基準により学習を行なうため、AIが何を学びとったのかは人間のコントロール下になく、内部動作の把握は困難です。
AIの判断根拠となった参考資料やロジックが不明であったり、説明不足であったりする場合には、生成結果の信頼性が判断できなくなります。
AIは学習データをもとに生成を行なうため、生成されたデータの権利や責任の所在がわかりにくいことも課題です。
AI生成物は、AIが創作したものであるため、通常は著作物とは考えられません。しかし、利用者が創作の意図を持ってAIをツールとして使用した場合には、利用者が著作者になり得ます。
その際、AI生成物に学習元のデータと類似性・準拠性が認められる場合には、元の著作者の許諾なく利用すると著作権侵害になるため、権利関係で問題になることが少なくありません。
なお、著作権上は学習モデルの生成のために著作物を使用することは、問題ないとされるのが一般的です。しかし、特定の著作者や著作物を学習対象とする場合には、生成にあたり著作者の権利を侵害するおそれがあり、学習データ自体の権利について議論されることもあります。
では、リソースを無駄にせず、技術的負債を負うことなく、また顧客の信頼を失うことなく、ソフトウェアチームが生成AIを使った今注目の機能を迅速に展開するにはどうすべきでしょうか？ 実際にPagerDutyのAI生成機能の開発に携わるデータサイエンティスト、データエンジニア、製品担当者にそれぞれ話を聞きいたところ、いくつかの成功パターンが見えてきました。
目まぐるしく変化するテクノロジーには、誰もが翻弄されるものです。しかし、問題を明確にしないままソリューションを構築することほど無駄なことはありません。
PagerDutyのデータサイエンス部門のシニアディレクターMitra Goswamiは「本当に解決すべきものは“何”かを意識し、ユースケースに焦点を当てることが重要だ」と語ります。
これは達観した考え方ではなく、重要な決定にかかわります。
Goswamiは、ユースケースで要件を決める方法について、次のように述べています。
「モデルの中には大き過ぎるものもあります。例えば、GPT 3.5やGPT 4といった大型の言語モデルはたしかに素晴らしいモデルですが、非常に多くの演算を必要とし、コストも割高です。それに対し、小規模で特定の業界やビジネスに特化した言語モデルでは、よりビジネスニーズに即した結果をもたらすだけでなく、レイテンシ（待ち時間）も短縮されます。これは特にリアルタイムアプリの場合に顕著です。」
要約・チャットボット・コード生成といった課題を検討するうえで、ユースケースの特定は大切です。
しかし、さらに高い精度を求めてGoswamiが問いかけるのは「このユースケースで顧客を安心させられるか？顧客の経費を削減できるか？」という、顧客への影響です。
このような視点でユースケースを見ることは、付加価値の高いソリューション開発につながります。
生成AIへの取り組みを始めるうえでは、データ集約型機能の開発経験を持つ企業のほうが優位だと言えます。
「PagerDutyは、AIに長くかかわってきました」と話すGoswamiは、生成AIで事業のスピードを上げるために、強力なデータアーキテクチャの基礎が欠かせないと述べています。
堅牢なインフラは、LLM（大規模言語モデル）やLLMベンダーの能力を引き出すうえで必要不可欠です。
「データレイクといったストレージソリューションの確保は、モデルのトレーニングや調整に使用する、大量のテキストデータを蓄積するうえで最優先課題です。
次に重要なのが拡張性です。LLMサービスとのスムーズな統合を可能にする、優れたAPIレイヤーなどの作業負荷に対応する必要があります。包括的な監視、記録データの蓄積、コスト管理システムは、インフラの健全性の維持と投資の最適化に役立ちます。」
AIの進化は、目を見張るほどの速さです。
ChatGPTはリリース後2ヵ月を待たずしてユーザーが1億人に達し、2023年7月にMeta社がLlama 2をリリースしたことで、さらに生成AIが話題になりました。
オープンソースの参入と巨額の投資により、LLMの基盤と関連するサービスは急速な進化を続けています。
この状況は、データサイエンティストや技術者の選択肢が常に変化していることを意味します。
つまり、もはや「圧倒的な勝者」の出現を待つという選択肢はなく、その出現を待ち続けることは「やがて廃れてしまう技術でシステムを構築すること」を意味します。
したがって、変化が求められる環境下で企業が進化し続けるには、柔軟なアプローチが必要です。「PagerDutyは、非常に柔軟にモデルの選択を行なっています。」とGoswamiは述べています。柔軟性があれば、チームは将来起こり得る変化に適宜対応できます。
ただし、常に変化し続けるという意味ではありません。Goswamiは、重要なのはユースケースを重視した構築であり、変化のための変更ではないことを強調したうえで、以下のように述べています。
「環境が頻繁に変化する今日だからこそ、絶え間ない変更は無意味です。構築には確固たる目標を持ちましょう」
「Move fast and break things（素早く行動し破壊せよ）」は、開発の世界でマントラのように使われてきたフレーズです。しかし、将来的な手直しにかかるコストよりも目の前の解決策を優先するこのアプローチは、技術的負債を増やす結果になりました。
とはいえ、ややこしいアーキテクチャレビューは時間がかかり、革新どころではありません。
では、Goswamiのチームがアーキテクチャの質と開発のスピードをどう両立させたのかを見てみましょう。
「PagerDutyでは、設計文書の作成を早い段階から始めます」とGoswamiは説明しています。
設計文書とは、アーキテクチャのパターンと、各パターンがベンダーやオープンソースモデルとやり取りする方法が書かれたものです。将来に向けた柔軟性と混乱の回避を担保します。「Language Model-as-a-Service（サービスとしての言語モデル）のアーキテクチャを構築する際に、設計原理から取りかかることには、いくつかの理由があります。その理由の1つには、自然言語理解・コンテンツ生成・データ分析などの目標の種類にかかわらず、設計原理はアーキテクチャが目標に沿っているかを確認する際の指針となることが挙げられます」
「設計原理があれば、矛盾のない明確な意思決定ができるだけでなく、効率的かつ質の高いアーキテクチャを構築できます。また、デザインをユーザー重視で進められるため、ユーザー満足度の高いLLMサービスを効率的に開発することも可能です。つまり、堅牢で順応性の高いユーザー重視のLLMアーキテクチャ構築には、何よりもまず設計原理を作成することが重要になります。PagerDutyでは、データサイエンスチームとアーキテクチャストラテジーチーム、そしてチーフアーキテクトであるPhilip Jacobが緊密に連携し、LLM-as-a-Serviceのアーキテクチャを開発しています」
変更は避けられないと判断されて初めて、チームはアーキテクチャ変更の設計に取りかかります。変更にあたって重要なのは、異なるコンポーネント間のインターフェースと相互作用への配慮です。
例えば、LLMのような1つのコンポーネントを変更する場合でも、アーキテクチャの他の部分への影響を予測できる方法をとることが重要です。
また、別のブログでも書きましたが、変更の際には、テストとCI／CD（継続的インテグレーション／継続的デリバリー）が力強い味方となります。
LLMを使った新機能や新製品が発表された際に、ユーザーがまず気にするのがプライバシーです。
信頼の構築は、製品やデータサイエンスにとどまらず、多くのチームが共有する責務です。チームにその責務を遂行させる際、Goswamiはチーム向けのガイドラインの作成を勧めています。
Goswamiは次のように述べています。「データの使用には、非常に慎重になるべきです。顧客にはオプトインのオプションがある旨を伝えるようにしています」
この透明性とオプトインオプションに関しては、PagerDutyが公表しているPublic guidelines for the safe and secure use of generative AIでご覧いただけます。
また、このような動きはPagerDutyにとどまりません。PagerDutyのシニアプロダクトマネージャーであるJake Cohenはこう言っています。「AIとのやり取りを学習データとして使用しないという考えを宣言し、変更に着手しているベンダー企業が増えています」
Cohenはこう続けます。「AIと共有する情報を最低限に抑えています」
PagerDutyでは、プライバシーへの懸念だけでなく、機能面でもAIへの依存を限定しています。Cohenは、生成AI RunbooksのAI利用をどう制限しているかを説明するうえで「PagerDutyは、AIと従来のソフトウェアの使い分けについて常に慎重に検討しています」と述べています。
これまで長い間、データサイエンティストは、予測モデルには「信用スコア」を用い、予測モデルの結果の理解とランク付けには別の測定手段を用いてきました。
これをもとに、チームは正確性だけでなく、最速かつ最も効率の良い手段を追求しています。生成AIの場合も同様に、その正確さは評価の一要素に過ぎません。
これに関して、Goswamiは「測定しないことには、話は始まりません。枠組み作りを進める上で常に数値化することを心がけてきました」と断言しています。Goswamiはチームで、コスト・レイテンシー（遅延時間）・正確性といった、複数の要素を検討してきました。
「その結果に行き着いたのが枠組み作りです。枠組み作りにより、使用可能な複数のLLMの比較が容易にできるようになりました」
この枠組みは、新たなLLMや技術的選択肢が登場した際に、過去のテスト結果と比較検討できる点で役立ちます。
新たな選択肢を選ぶ際に、チームは売り込み文句を信じるのではなく、データに基づいて決定を下すことができるからです。
また、このような比較検討は、現在使用中のツールが他の選択肢より劣っていないことを、定期的に確認する機会にもなります。
アクションを正しくコード化することが求められるのは、どの自動化にもいえますが、毎回同じ方法でタスクを行なうのは、人間よりコンピューターのほうが向いています。
生成AIでビルド作業を行なう場合も同じです。オープンなコマンドフィールドとは異なり、生成AIへのアプローチの体系化が進めば、どのユーザーも専門家と同じ知識を持てます。
PagerDutyの生成AIを使ったランブックに拡張機能を持たせたのが、その例です。
AnsibleやAWSなどの利用頻度の高い他のシステムに接続する際、AIは接続を再作成するのではなく、拡張機能を再利用します。
この方法についてCohenがメリットに挙げているのが、「管理のしやすさ」です。「ワークフローをこのようなステップに分割し、拡張機能のメリットを引き出すことで、ジョブの変更・修正がしやすくなります」
ベストプラクティスの中には、アウトプットとしてではなく、ユーザー体験として残るものもあります。
Cohenは「PagerDutyがAIで生成されたジョブに対して重視しているのは『AIが生成したジョブを重大な影響が出ない環境で確認し、実際に問題なく起動することが、ベストプラクティスになる』という点です。これは、経験豊富なスタッフが新規に制作した自動化にもいえることです」と言います。AIを利用したベストプラクティスによって、経験の浅いチームメンバーでも迅速かつ安全に業務を進められます。
PagerDutyのチームは、このような方法で技術的負債を負うことなく、リソースや時間を無駄にせず、また顧客の信頼を失うことなく生成AIを使い、優れた機能を迅速に開発しています。詳細はPagerDuty’s learnings from building with LLMs for incident responseをご覧ください。
生成AIは精度の向上により、システム開発・運用においても活用が進んでいます。開発現場ではDevOpsの推進にも役立ち、生成AIによるインシデント対応の効率化も可能です。
PagerDutyでは、インシデント管理をサポートするAIアシスタントなどを加えたOperations Cloudの自動化支援セットである「PagerDuty Copilot」を提供しています。生成AIでの自動化支援により、さらに迅速で効率的なインシデント対応を実現しました。ぜひ、生成AIのチカラを活用したPagerDutyによるインシデント管理をご体験ください！
ソリューション解説動画 システムが複雑化し、その変化も加速する中、システム運用を担う現場エンジニアの負荷は日々高まっています。
「インシデント対応」を例に、具体的に現場でどのような課題があるのかをご紹介。
そして、それらの課題をPageDutyがどのように解決できるのか、デモを交えて解説します。→ PagerDutyの資料をみる（無料）
この記事が気になったら
PageDuty公式アカウントをフォロー
関連ブログ記事
人気記事
検索
タグ目次
