「Datadog Summit Tokyo」に登壇した日本経済新聞社の若本亮佑氏。生成AI活用に向けたインフラ基盤構築についてその意義と課題を話した（写真撮影：齋藤 公二）生成AIの活用が急速に進む中、それを支えるインフラ基盤構築でもさまざまな取り組みが進んでいる。日本経済新聞社では、AIサービス開発のために社内にLLMプロトタイプ環境を構築したが、その際にも3つの課題に直面したという。
10月16日に開催された「Datadog Summit Tokyo」の基調講演に日本経済新聞社（以下、日経）情報サービスユニット データサイエンティスト 若本亮佑氏が登壇し、日経新聞における生成AI活用に向けたインフラ基盤構築の苦労を語った。
生成AI活用のメディア業界における変革はこれまでと性質が異なる
日経では、新聞を中核に、雑誌、書籍、電子メディア、データベースサービス、速報、電波、映像、経済・文化事業などを展開している。このうち、データベースサービス事業を担うのが、若本氏が所属する情報サービスユニットだ。
「情報サービスユニットでは、新聞記事のデータや企業データ、マクロ・統計に関する数値情報をデータベースとして持っていて、これらデータを加工したり、生データをお客様に届けたりしています。いまメディア業界は変革期に入っています。生成AI、特に大規模言語モデルLLMの活用の波が来ており、大きく変わろうとしています」（若本氏）
若本氏によると、メディア業界における変革はこれまでもあったが、生成AI活用の変革は性質が異なるという。
「これまでの変革は媒体に関するものでした。Web系のコンテンツが広まることにより多様な媒体を皆さまが見るようになりました。今回の変革は情報処理に関わるものです。人間が記事を読み、咀嚼（そしゃく）して何かしらの業務に使っていたものが、生成AI側で記事を読み、咀嚼して、加工するようになり、それを最終的に人間が受けとるようになっています。情報処理の組み合わせの部分でも業務が大きく変わっており、情報を売っている我々としては、事業が根底から変わりかねない脅威でもあります」（若本氏）
脅威はチャンスにも、AIサービス開発のためにLLM開発のプロトタイプ環境を構築
一方で、脅威はチャンスにもなっている。生成AIでしかできない処理を行うことで、人間が読みやすいデータに加工したり、やりやすい使い方を見つけることができるからだ。
そこで日経では、生成AIについてのさまざまな取り組みを試行錯誤しているという。
「記事データや企業データ、マクロ・統計データを検索基盤に収集分析し、『日経テレコン』『Risk & Compliance』『THE KNOWLEDGE』『NIKKEI COMPASS』などの既存製品に生成AIを統合したり連携させたりしています。また、『NIKKEI KAI』という生成AI製品を開発し、目まぐるしく変わる環境に対応できるよう継続的に強化しています」（若本氏）
こうしたAIサービス開発のために構築したのが、「LLM開発のプロトタイプ環境」だ。
「営業、企画、技術など、社内の知恵を持ち寄って、動くものをとりあえず作って、触って、磨いてみる。そのためのプロトタイプ環境を社内に構築しています。作ったサービスをまずプロトタイプ環境に乗せ、社内フィードバックやA/Bテスト、事業の意思決定などを行なっています。プロトタイプ環境では複数のLLM機能を並行して開発できるようにしています。このプロトタイプ環境の構築にあたってはいくつかの課題を乗り越える必要がありました」（若本氏）
Datadog LLM Observabilityを採用、LLM Observabilityを実現して3つの課題を解消
課題は大きく3つあった。1つめは、本番化が難しいこと。プロトタイプをつくっても、再現性のなさやバグなど、それをそのまま本番にすることが難しかった。2つめは、改善が難しいこと。フィードバックに該当する挙動の原因が生成AIなのかそうでないのかがわからず、プロトタイプの改善が進まなかった。3つめは、運用面での不安。LLMがいつどんな理由でサービスが落ちるのかがわからないことや、LLMを用いたさまざまな機能を管理する難しさがあった。
「課題の根本的な原因としては、複数のLLM推論を行っていて、それをたくさんの機能で実施しようとしていることにありました。1つのLLMだけならそこまで難しくはありません。ユーザーが何か入力したときに、LLMが1つだけなら、だいたい原因はわかりますし、仮説検証も容易だからです。プロトタイプ環境はマルチLLMで動作しており、手順や処理も複雑でした。例えば、ユーザーの意図を分類したり、どういうデータを使いたいかをLLMに判定させたり、ユーザーによる悪意のある入力がないかをチェックしたりする必要があります。また、複数のRAGに対してさまざまな検索を独立して行ったり、それらを統合したりしています。ものによってはクエリをそのまま書くなど複雑な処理をしている生成AIのノードもあったりします」（若本氏）
その結果、「どこに主原因があるか追いづらい」「再現実験にも時間がかかり、再現は保証されない」「テストを作り込むと開発スピードが落ちてしまう」といった現象にも悩まされることになった。そこで取り組んだのが、「LLMアプリケーションのログトレース」だ。
「LLMログのトレースを実現するのが、LLM Observabilityと呼ばれる機能です。LLM Observabilityは、LLMのワークフローやエージェントの管理を行うツールです。複数のLLMがあったときに入力が何で出力が何かを1つ1つトレースして残すことができるようになります。直近の発生頻度が多いエラーを確認したり、該当するログに絞り込んだり、入出力を手がかりに原因分析、改善、テストを行ったりできます」（若本氏）
日経では、LLM Observabilityを実現する製品として、Datadog LLM Observabilityを採用した。すでにインフラやバックエンドの監視にDatadogを採用しており、インフラとLLMを一元管理できることを評価した。また、集計とモニタリングで運用や改善が楽になることや、ログが軽量でありチェックが容易なことも評価した。
「LLMプロンプトは変更が激しく何が原因で落ちたのかわからなくなりますが、Datadogの場合、それらを一元管理できるうえ、LLMアプリケーションの内部ロジックやLLMの挙動そのものもモニタリングできます。また、集計機能も便利で、1つのLLMに何秒かかっているかなどがわかります。ユーザーにもどんどん触っていただきフィードバックをもらうことが重要ですが、そのためのフィードバックの手間が減りました。さらにエラー率などの指標をモニタリングすることで、『いつのまにか動かない』を防止できます」（若本氏）
LLM Observabilityを実現したことで、3つの課題を解消し、さまざまな効果を得ることができた。まず、本番化が難しいという課題については、LLMアプリの内部挙動がわかりやすくなり、本番化にかかるコストが低下した。また、改善が難しいという課題に対しては、課題を発見し、改善サイクルを回しやすくなった。さらに、運用面での不安については、アラートやダッシュボードにより、LLMアプリケーションの管理にかかる負担が減少した。
「特に、改善サイクルがまわしやすくなったことと、LLMアプリケーションの管理負担が減少したことは、Datadog LLM Observabilityを導入したことで大きな効果として実感していることです。LLMプロトタイプ開発の迅速な開発に向けて、改善スピードの向上と安定性の向上を実現できました」
ライター
