生成AIが抱えるリスクと、プラットフォームエンジニアリングで生成AIを活用するメリット：生成AIを実務活用する際何を想定すべきか

生成AI導入の最前線に立っているのは、DevOpsチームとプラットフォームエンジニアだ。生成AIが抱えるリスクを解説したり、生成AIを活用するメリットの事例として、プラットフォームエンジニアリングにおける活用事例を紹介したりする。

[Beth Pariseau，TechTarget]

　生成AIが単なる話題から実用的な現実に変わっている。その生成AIがもたらす効率の高さというメリットを追求し、増大するリスクに対処する最前線に立っているのがプラットフォームエンジニアとDevOpsチームだ。

　2022年後半から生成AIの話題がテクノロジー業界を席巻してきた。だが、2024年はIT担当者が生成AIを運用環境に導入し始める年になると業界ウォッチャーは見ている。この導入トレンドはまだ初期段階だが、このような採用トレンドはまだ初期段階だが、一部の組織では、DevOpsチームの日常業務で生成AIチャットbotの成果が現れ始めている。大規模な言語モデル（LLM）の運用に伴うセキュリティやプライバシー、パイプライン統合、コストの課題に対処したり、新規開発者のオンボーディングなどのプラットフォームエンジニアリング・タスクの自動化に、生成AIツールの新たな可能性を見出したりしている。

　例えば、米国のコミュニケーションPaaS（Platform-as-a-Service）企業、Nylasは、2023年8月「Mendable」を利用して自社の顧客向けに生成AIチャットbotを立ち上げた。それ以降、同社の顧客基盤が30％以上広がっているにもかかわらず、同社ヘルプデスクシステムで開かれるサポートチケット数は25％減少しているという。

　Nylasで製品担当のシニアバイスプレジデントを務めるアイザック・ナシミ氏は語る。「サポートチケット数が減っているとしても、サポートチームがチケットに取り組む時間が減っているわけではない。サポートチームが繰り返し対応してきた本当にシンプルで分かりやすいチケットには『Nylas Assist』チャットbotが防波堤になる。そのため、対応が難しいチケットや興味深いチケットに取り組む時間が増えている」

　チャットbotのやりとりを取り込むことで、同社のDevOpsチームから開発プロセスにフィードバックするのに役立つデータが得られるとナシミ氏は話す。

　「実際には文字通り何千人もの顧客から話を聞かなければ得られない疑問点やフィードバックをチャットbotから得られる。製品の中で顧客が課題に直面する領域を見つけて解決するのに役立っている」（ナシミ氏）

　例えば、多くの開発者がチャットbotに何度も繰り返す質問を調べたところ、ユーザーのメールアカウントによる認証の管理方法についてもっと明確な指示を提供する必要があることが分かったとナシミ氏は語る。

チャットbot活用の注意点、生成AIのリスク

　米国の調査会社Constellation Researchでアナリストを務めるアンディ・トゥライ氏によると、チャットbotは生成AIツールで最も早期に普及したものの一つだ。理由として、会話アシスタントが人工知能（AI）研究において既にある程度成熟していたことが挙げられるという。

　「一般的には、生成AIはまだバージョン1.0の段階だ。既存の会話型エージェントの場合、問題が起きても実際のオペレーターへのエスカレーションが可能だ。生成AIは何でも答えてくれる超人間的頭脳だと思われている。だが、問題が起きたときに、その問題を人間のエージェントに委ねるタイミングに課題がある」（トゥライ氏）

　人間が見守っていなければ、顧客対応のチャットbotが犯したミスが事業に悪影響を及ぼす可能性があるとトゥライ氏は語る。同氏が例として挙げたのは、2022年11月にAir Canadaのチャットbotが顧客に誤った回答を返したとして2024年2月に同社が責任を問われたことだ。

　2022年9月以降、生成AIテクノロジーは「驚異的な飛躍を遂げている」とトゥライ氏は話す。

　「LLMに目を向けないのは間違っている。試してみるべきだ。顧客にはそう伝えている。ただし、適切なユースケースを理解しなければならない」（トゥライ氏）

　Nylasでの経歴の大半をチャットbotのLLMトレーニングで過ごしたナシミ氏は、チャットbotにはまだ改善の余地があると話す。

　「チャットbotに任せることで顧客は満足するだろうと思えるようなことはほとんどない。というのも、チャットbotは時折誤った回答を返すためだ。そうした状態は今も続いている。わずかだが、誤った助言を受け、不満がたまっているユーザーがいる。当社はそれを改善したいと考えている。それが私の仕事だ」（ナシミ氏

　チャットbotが不正確な情報を提供すること以外にもリスクがある。市場で提供されている生成AIツールが、企業内でカスタマイズあるいはホストされているLLMと直接連携するようになってきたことで、セキュリティやプライバシーに関する懸念も生まれている。例えば、IDCが2023年7月に実施した調査（※）では、回答者890人のうち44％が生成AIを利用する上での最大の障壁はセキュリティだと答え、38％はプライバシーへの懸念を第一に挙げている。

（※）「Future Enterprise Resiliency and Spending Survey」（企業の将来の回復力と支出に関する調査）

　生成AIにまつわるセキュリティの懸念には、問い掛けに対する答えによって企業の機密データが流出する恐れや、企業データがサードパーティー製LLMのトレーニングに使われることによるセキュリティとプライバシーのリスクなどがある。トレーニングデータに関する進行中の訴訟では、さまざまな潜在的ビジネスリスクの中でも、AIが生成するソフトウェアコードの法的責任の露呈やライセンス違反が争われている。

　そのためか、米国の経営コンサルタント企業EXL Serviceが2024年に実施した調査（※）によると、大手金融サービス企業および保険会社の上級幹部158人のうち58％が生成AIに深い懸念を抱いていると答え、63％が生成AIの利用を制限するポリシーを定めているという。

（※）「EXL Enterprise AI Study」（EXLエンタープライズAI調査）

LinkedInやCredit Karmaのプラットフォームチームによる生成AI活用事例

　リスクがあるとしても、アプリケーション開発プロセスに生成AIを取り込み、既にプラットフォームエンジニアリングチームの日常業務に取り入れている大手企業もある。

　LinkedInは、2023年に同社のエンジニアリングプラクティスを刷新し、「InMail」メッセージの初稿の執筆や、同社が提供する「Sales Navigator」のユーザー向けアカウント情報の要約など、エンドユーザー向けに生成AIアプリや生成AI機能をサポートしている。2024年2月に公開されたLinkedInのブログ記事によると、この刷新の一環として、同社プラットフォームエンジニアリングチームは、開発者がMicrosoftの「Azure OpenAI Service」を利用してOpenAIのモデルにアクセスしたり、社内でホストするオープンソースモデルにアクセスしたりすることを可能にしているという。

　LinkedInのプラットフォームチームは、構造化されたAPIレスポンスを標準のプロンプトに変換するライブラリを開発者向けに事前構築している。また、同社ブログ記事には「GPTといったクラウドベースの生成AIモデルとの相互作用を管理する生成AIゲートウェイも開発している。このゲートウェイは、送信リクエストのレート制限やリソースクオータの強制などの機能を備える」と記されている。

　LinkedInのプラットフォームエンジニアは、機械学習とAIのデータを統合するツールを開発者向けに作成しており、こうしたパイプラインツールの一部をオープンソースに寄贈している。2024年2月にリリースされた「FlyteInteractive」もその一つだ。同社のブログ記事によると、FlyteInteractiveは「『Kubernetes』のポッド内部にインタラクティブな環境をエンジニアに提供し、エンジニアは“本番環境に似た”環境で機械学習モデルを簡単にデバッグできる」という。

　LinkedInでAIと機械学習プラットフォームのエクゼクティブディレクターを務めるアニメシュ・シン氏はTechTargetの取材に対し「LinkedInの生成AIに関する取り組みの大半は、顧客やオープンソースコミュニティーといった社外での利用を目的とするが、プラットフォームエンジニアは効率向上を目的として、社内でも生成AIの利用を開始している」と答えている。

　「例えば、LinkedInが利用する『Slack』のチャネル内で生成AIを使用し、非常に一般的になったソフトウェア移行の典型的な取り組みに対する多くの質問に答えられるようにしている。つまり、ドキュメントがあれば、チャットbotは質問に対する答えを正確に見つけることができる」（シン氏）

　今のところ、このチャットbotは開発の初期段階にあり、利用者はチャットbotの回答に賛成票と反対票を投じることができる。だが、このチャットbotを利用して既に時間を節約している開発者もいる。同様に、LinkedInでは、生成AIアシスタントと「Jupyter Notebooks」を使って自然言語でデータベースクエリを記述している機械学習エンジニアもいる。

　LinkedInはLLMへのアクセスの一部を親会社のMicrosoftに依存している。同様に、米国のフィンテック企業Credit Karmaのプラットフォームエンジニアも、親会社であるIntuitの「GenOS AI」プラットフォーム向けに構築された開発ツール「GenStudio」など、Intuitの生成AIの取り組みを利用している。

　Credit Karmaでエンジニアリング担当のシニアディレクターを務めるジェレミー・ウンルー氏によると、同社のプラットフォームエンジニアリングにおける生成AIの活用は、初期段階ではLinkedInと同様、GenStudioにおける開発者の認証の調整といった開発者エクスペリエンスに重点を置いているという。

　「Credit Karmaの開発者はIntuitとは異なる認証を使用するため、開発側ではこの違いを吸収する自社独自のレイヤーを構築しなければならなかった。現在では、当社の開発者によるGenStudioの操作を追跡してログに記録し、誰が何を使用しているかを追跡できるようになった」（ウンルー氏）

　Credit Karmaのプラットフォームチームが次に取り組もうとしているのは、DevOpsパイプラインにおける、プルリクエストに対するAIのフィードバックを改善するスタックランキング風ツールだ。さらに、今四半期にはプラットフォームの開発者ドキュメントについての質問に答えるチャットbotの作成に取り組むことも予定している。ゆくゆくは、生成AIがプラットフォームインフラのリソースをオンデマンドで自動的に稼働できるようになる可能性があるとウンルー氏は話す。

　「検討していることはたくさんある。例えば、当社のプラットフォーム標準に基づいてさまざまな種類のリクエストに対する全ての足場を築くといったことだ。つまり『新しいマイクロサービスが必要だ』という、『GitHub Copilot』ではあまり細かく調整されないようなことだ」（ウンルー氏）

　LinkedInでは、LLMと自然言語インタフェースで強化されるAIOps主導のインシデント修復など、IT運用により重点を置く生成AIの活用が社内で進行中だとシン氏は語る。

　「こうしたモデルを組み合わせてエージェントとして機能させ、複数のエージェントが相互に連携して根本原因の分析を調整し、その根本原因に応じて対応するチームに送信するチケットなどを作成できるシナリオが幾つか浮上している。こうした手順の幾つかは、何をすべきかを把握していて、その状況内で作業をうまく遂行できる推論能力が必要という意味で、AIプログラムが非常に適している」（シン氏）

　シン氏によると、この種のAIOpsシナリオ向けのオープンソースプロジェクトには、LangChainの「Agents」やMicrosoftの「AutoGen」があるという。

生成AIの複雑なコスト

　生成AIを早期に導入した企業はコスト管理の面で課題に直面している。何よりもまず、LLMの運用にコストがかかるとシン氏は話す。機械学習モデルのトレーニングにかかるコストを削減するためにFlyteInteractiveのようなツールが開発され、開発者がトレーニングに費やす時間は既に何千時間も削減されている。

　シン氏によると、同氏が率いるチームはさらにコストをコントロールするために、自社ホスト型のオープンソースモデルとクラウドベースのLLMを対比して使い方を改善する予定だという。

　「LinkedInでは、オープンソースモデルとホスト型モデルの対比を軸に幾つか方法論を考案する予定だ。というのも、オープンソースモデルには維持費がかかり、十分な能力を備えるGPUを運用するのにもコストがかかるためだ。製品チームが高いコストをかけずに、正しい意思決定を行うのに適したデータを確実に得られるように取り組んでいる」（シン氏）

　前述のEXL Service調査に回答した大半の者には、これまでのところコスト削減がもたらされていない。この調査では、回答者をAIを先進的に活用する「リーダーグループ」とそれに追随する「努力グループ」に分類している。コスト削減を実現しているのは、各グループの半数にも満たない（リーダーグループの 46％、努力グループの37％）。

　AIがもたらす製品のコストと時間の節約を、ソフトウェアベンダーが対比して評価することは極めて難しく、LLMのトレーニングに膨大な時間を要し、人間が監督する必要性を考えると、その判断は特に難しくなるとConstellation Researchのトゥライ氏は話す。

　「生成AIがコード作成の効率を高めるとしても、その効率をどのように測定すればよいだろう。もっと重要なのは、その生産に別のクライアント企業が関与しているとしたら、高まった効率を生産にどのように換算するかだ」（トゥライ氏）