「おはようございます。ブルック、ありがとう。皆さんと一緒にここにいられて本当に嬉しいです。

クリスティーナの基調講演は私たちに大きな刺激を与え、興奮を誘いました。これから45分ほどかけて、IT運用の変革と、最新のデータセンターの運用支援に関するビジョンについて掘り下げていきます。クリスティーナが提示したハイレベルのビジョンよりも少し深く掘り下げ、製品とエンジニアリングの観点から、お客様が日々、最新のデータセンターを管理し、運用していく上でどのような取り組みをしているのかについてお話しします。

それでは、現代のデータセンターについて少しお話ししましょう。LogicMonitorの設立当初から、私たちが注力してきたのはまさにこのデータセンターです。

当社はクラウドとマルチクラウドの可視性の必要性を強調してきましたが、当社の根本は、IT 環境全体、つまりすべてのインフラストラクチャにわたる可視性を提供することにあります。

そして、AI の時代においては、それがさらに重要になります。

AIのニーズとお客様のAIイニシアチブ、そして皆様が組織で計画しているイニシアチブ、オンプレミスでの機械学習モデルのトレーニング、GPUの直接活用、Bedrockのような生成プラットフォームの活用、あるいは、自社環境でのAIの活用方法、組織のニーズ、そしてこれら全てをどのように組み合わせるかを模索している段階など、様々な状況に対応します。AIの探求が進むこの時代において、お客様がどこにいても、私たちはお客様を全力でサポートいたします。インフラストラクチャの柔軟性と拡張性こそが最も重要な要素であり、LogicMonitorはお客様を支援するのに最適なソリューションです。このプラットフォーム基調講演の残りの部分では、この点について詳しく説明していきます。

私たちのプラットフォームは、ここ数年で大きく進化しました。LogicMonitorを長年ご利用いただいている方は、数年前にログ、クラウド、オンプレミスといった異なる製品を導入した時のことを覚えていらっしゃるかもしれません。当時はそれぞれ別々の製品でしたが、ここ数年でそれらは統合され、一つのプラットフォームへと進化しました。ですから、今日LogicMonitorを初めてご利用になる方は、長年の開発期間を経て実現した成果を目の当たりにすることになるでしょう。そして、AIとGentec AI Opsへの投資によって、可観測性の新たな時代を切り開くことができました。この取り組みについては、本日のセッションを通して詳しくお話しさせていただきます。

それでは、クラウドについて少しお話ししましょう。クリスティーナがSaaSをめぐる盛り上がりについて触れていましたが、10年から15年前、Salesforceをはじめとする彼らが行っていたSaaS関連の取り組みは、まさに刺激的な時代でした。当時のクラウドインフラについて考えると、データセンターはもう必要なくなるかもしれない、オンプレミスのすべてを廃止して、クラウドでIaaSだけを使うようになるかもしれない、という議論がありました。

Salesforceを使い始め、SaaSアプリも使い始めるという、おそらく一方通行の計画だったでしょう。そうすると、オンプレミスのデータセンターのラックにサーバーを積んだインフラはなくなり、クラウド、あるいはPaaS（プラットフォーム・アズ・ア・サービス）のインフラにすべてが集約されるでしょう。オンプレミスのサーバーは廃止するつもりでした。オンプレミスのサーバーもデータセンターももう必要なくなる、そうでしょう？

そうですね、一部の組織ではその通りになりました。クラウドネイティブでクラウドで生まれ、オンプレミスのデータセンターを一度も立ち上げなかった組織もあります。Salesforceのように、ワークロードによってはクラウドに移行し、二度と戻らなかったものもあります。

SaaSアプリケーションは確かに急増していますが、クラウドでの作業やクラウドへの移行は、10年や15年前には想像もできなかったような片道の道のりよりもはるかに複雑になっていることを、私たち大多数は実感しています。LogicMonitorでは、ワークロードの回帰、オンプレミスへの回帰、データセンターの拡張、オンプレミスデータセンターをクラウドテクノロジーでオーケストレーションし、それら全てを統合してメリットを享受するといったトピックについて、皆様から様々なご意見を伺ってきました。ハイブリッドワークロードは既に存在し、複数のクラウドワークロードが存在します。様々なクラウド間でのデータのやり取りは、今後も続くでしょう。つまり、クラウドへの移行は、10年や15年前に考えていたよりもはるかに複雑になっているのです。

クラウドカバレッジは、現代のデータセンターにとって非常に重要な鍵となります。現代のデータセンターはマルチクラウドです。選択肢が不可欠です。AWSだけでなく、Azure、GCP、その他のパブリッククラウド、プライベートクラウドも利用できる必要があります。現在、お客様の約40%がLogicMonitorを使用してクラウドインフラを監視しており、この割合は急速に増加しています。1年後、あるいはそれよりも短い期間で、この割合は逆転し、50%、60%、70%のお客様がLogicMonitorを使用してクラウドを監視するようになると確信しています。

また、マルチクラウドの導入が継続的に増加していることも確認しています。LogicMonitorで複数のクラウドを監視できるのは25%です。この数字は実際にはかなり低い数字だと思います。LogicMonitorで複数のクラウドを監視できていない場合は、何が障害になっているのかをお知らせください。クラウドの完全な可視性を実現できるようお手伝いいたします。複数のクラウドを単一の画面で管理できるのは非常に強力で、ベンダー独自のツールに縛られることはありません。こうすることで、すべてを単一の画面で把握できるようになります。私たちは、その実現をお手伝いします。この数字も、今後も増加していくと予想しており、ここ数年で劇的な成長を遂げています。

お客様は私たちと共に成長し、共に投資してくださっています。私たちのクラウド分野における成長率は驚異的で、過去3年間で77%に達しています。この機会に、私たちと共にクラウドの道を歩んでくださった皆様に心から感謝申し上げます。

そして、お客様が当社のクラウド、当社のクラウド サービスを通じて継続的に価値を獲得し、その存在感を拡大し続けていることがわかりました。

そしてAI。これは流行語であり、大いに宣伝されています。私たちはいつもAIの話を耳にしています。

しかし、AIはすでにここに存在し、AIの一部であり、今日のIT環境の一部です。LogicMonitorでは、私と私のチームが毎日AIを使っており、それを実現するために社内のIT運用担当者の力を借りています。AIツールがなければ、仕事は遅くなってしまいます。私たちは既にAIをすべてのワークフローに取り入れており、皆さんの組織のユーザーにも同じようなことが起きているのではないでしょうか。

LogicMonitorのお客様は、AIサービスを常に評価し、ほぼ毎日のように新たなAIイニシアチブを立ち上げています。そのため、私たちは単なる監視にとどまらず、このAI時代において、効率的で信頼性が高く、拡張性の高いインフラストラクチャを設計する必要があります。

これまでお話ししてきたクラウド、AI、最新のデータセンターなど、すべてはネットワークに大きく依存しています。そのため、無線アクセスポイント、様々なカバレッジ、SD-WANの導入など、ネットワークの近代化は継続的に進んでいます。これらの数字は増加の一途を辿っており、より豊富なテレメトリとより深い洞察を提供し、皆様とそのチームにリアルタイムの価値を提供することが重要です。私たちは、この傾向が今後も続くと確信しています。

さて、最後にサラに話を伺いたいと思います。この製品基調講演の残りの部分では、3つの領域、つまり製品とエンジニアリングの観点から私たちが取り組んでいるすべてのものを動かす3つのテーマについてお話ししたいと思います。1つ目は、プラットフォームへのデータ取り込みを非常に容易にすることです。これは、コレクターベースのアプローチで常に実現してきました。そして、今後もこれを拡張していきます。

データがプラットフォームに取り込まれたら、トラブルシューティングを非常に簡単にし、何が起こっているのかのコンテキストを提供したいと考えています。私たちの目標は、ロジックモニター内の単一の画面で、問題のトラブルシューティングに必要なすべての情報を把握できるようにすることです。複数のツールにログインしたり、ログにアクセスするためにチケットを提出したりといった手間は不要です。単一の画面から、コンテキストに基づいたトラブルシューティングを非常に簡単に行えるようにしたいと考えています。

そしてもちろん、私たちはAgentic AI Opsソリューションで未来を切り拓き、この豊富なオブザーバビリティデータセットとプラットフォームに蓄積されたあらゆるテレメトリを統合することで、次世代のAgentic AI Opsを実現します。これについては、Karthikが後ほど詳しくお話しします。これが私たちの製品とエンジニアリングの取り組みの指針となっています。本日の基調講演の残りの部分とブレイクアウトセッションで、素晴らしい成果をいくつかお見せする予定です。これについて、皆さんとさらに詳しくお話しできることを大変楽しみにしています。

それでは、当社の製品管理担当副社長である Sarah Terry に、この件についてさらに詳しく説明してもらいましょう。

皆さん、ようこそ。ここに来られて嬉しいです。それでは、AndrewがLogicMonitorデバイスの使い方について説明してくれました。

そして現在では、約 450 万台のデバイスにわたるカスタム時系列データベースで、1.1 兆を超えるメトリックを確認しています。

そこで、この規模のビジネスをどのようにサポートしているか、舞台裏で少しお見せしたいと思います。普段はお客様事例を重点的にご紹介しており、今日もきっとたくさんの事例をお伝えできると思います。約束します。しかし、今回は少し趣向を変えて、LogicMonitorでのLogicMonitorの活用方法についてお話ししたいと思います。

それでは、デモを開始したいと思います。

わかりました。ここでご覧いただいているのは、LogicMonitorがIT運用チームにどのように貢献しているかという点です。これは、LogicMonitorのIT運用チームがJira、Slack、Confluence、そして各拠点のオンプレミス機器などを監視するために使用しているアカウントです。

もちろん、これらのリソースの可用性は従業員の効率に直接関係するため、最大の懸念事項です。

ここではリソース エクスプローラーを使用していますが、まずこのアカウントで監視している範囲を詳しく分析することから始めます。

では、まずプロバイダー別にグループ化し、次にリソースの種類別にグループ化して、何があるか確認してみましょう。物理サーバー、ファイアウォール、スイッチ（これらはローカルオフィス用です）が多数あること、そしてクラウド上にもリソースが多数あることがわかります。

それでは、これらのクラウド リソースの 1 つを見てみましょう。

本番環境の Jira インスタンスをサポートするこのリソースを確認し、監視対象を確認します。

アラートが発生しているのがわかります。これについては後ほど詳しく説明します。まずは、ここに表示されているメトリクスの幅広さから見ていきたいと思います。このEC2インスタンスについては、CloudWatch APIからのデータも取得していますが、メモリ使用量やTomcatの統計情報など、CloudWatchがレポートしていない部分を補うために、ロジックモニターコレクターからのデータも活用しています。

情報タブでは、このデバイスが自動的に認識され検出されたため、AWS とコレクターから取得した豊富なメタデータがすべて表示されます。

さらに進むと、このリソースのログも実際に確認することができ、メトリックと組み合わせることで、このリソースで何が起こっているのか、そしてその理由についてより包括的なビューが得られます。

それでは、メトリック、ログ、メタデータがどのように組み合わされてこのアラートに役立つかを見てみましょう。

Tomcatのリクエスト時間に問題があることがわかります。青色の網掛け部分を見ると、このリソースの過去の値と比較すると、表示されているリクエスト時間は実際には異常ではありません。

グラフ タブでは、Tomcat インスタンスの他のメトリックをいくつか確認できます。

すると、ログに確認すべき異常が表示されます。今のところ異常はないようです。また、「すべてのログ」に切り替えて、このEC2インスタンスのすべてのログを取得することもできます。何が起こっているのかを解明するのに役立つかもしれません。

マップタブは、影響範囲を素早く把握するのに役立ちます。このインスタンスの可用性は影響を受けていないように見えますが、ダウンストリームEBSボリュームが存在することがわかります。

履歴タブには、このアラートが過去にどれくらいの頻度で発生したかが表示されます。ご覧の通り、かなり頻繁に発生しています。そのため、このケースでは、アラートをトリガーした静的しきい値を確認する必要があるかもしれません。LogicMonitorの動的しきい値を活用することも検討してみてください。動的しきい値は、リクエスト時間の値が青い範囲外にあり、真に異常な場合にのみアラートをトリガーします。

このように、メトリック、ログ、メタデータが統合され、IT 運用チームがトラブルシューティングを迅速化するための洞察が得られます。

それでは別の例を見てみましょう。LogicMonitorがプラットフォームエンジニアリングチームにどのように役立つかをお見せします。

ここでは、当社の技術運用チームが実際に Element Vision プラットフォームをサポートするために使用するこのアカウントについて見ていきます。

もちろん、可用性も重要ですが、パフォーマンスも重要です。アプリケーション、ロジックモニター、そしてビジョン製品が皆様にとってスムーズに動作していることを確認したいのです。そのため、チームはこの点に常に注目しています。ここではリソースエクスプローラーを使用しています。監視対象の範囲から始めるのではなく、少し異なる視点から始めましょう。サポート対象のアプリケーションでタグ付けされたすべてのリソースを確認し、アプリケーション名ごとにリソースをグループ化して表示します。

これにより、ElementVision プラットフォームをサポートする監視対象のすべてのアプリケーションを非常によく把握できるようになります。

かなりたくさんあることがわかります。

実際に行うことは、これらのアプリケーションの 1 つにアクセスして、何を監視しているのかを確認することです。

メトリクスプロセッサを選択できます。これはバックエンドのアプリケーションで、環境内のすべてのコレクターから取得したメトリクスを実際に処理します。

先に進み、この特定のメトリック処理アプリケーションを実行している Kubernetes ポッドの 1 つを見てみましょう。

前回と同様に、実際に何を監視しているのか見てみましょう。

今回は、まず情報タブから始めて、豊富なメタデータを確認していきます。データ収集をサポートするために、多くのカスタムプロパティが設定されています。

Kubernetes APIからは、Helm Chartのバージョン、アプリケーションのラベルなど、メタデータも取得できます。さらに、名前空間、ノード名、ポッド名などの情報も取得できます。これらのメタデータはすべて、リソースエクスプローラーやダッシュボードのフィルタリングなどの機能に活用されています。

では、ここで監視しているメトリクスを見てみましょう。Kubernetes APIからのメトリクスやkube stateメトリクスなど、様々なメトリクスが表示されているのが分かります。

ここで注目すべきは、ここに表示されているアプリケーションメトリクスです。このグループを展開したところです。このメトリクス処理アプリケーションのパフォーマンスに関する洞察を提供する、膨大なアプリケーションメトリクスが存在していることがわかります。

私たちのチームは、すべてのアプリケーションにカスタムデータソースを作成し、メトリクスを通して、つまりシンプルにメトリクスを通して洞察を得ています。このメトリクス処理アプリケーションでは、処理している複雑なデータポイントの数と、平均でどれくらいの時間がかかっているかを把握します。

ここで、ポッド レベルに戻ると、この Kubernetes リソースに送信されるログも確認できます。

これにより、アプリケーションのパフォーマンスに関する非常に優れた洞察も得られます。

多くの貴重なアプリケーションデータがログに書き込まれることは周知の事実です。ここには、アプリケーション自体が書き込むログも含め、ポッドのすべてのログが表示されています。そして、これまでと同様に、これをメトリクスと組み合わせることで、アプリケーションとその基盤となるインフラストラクチャで何が起こっているかを、より包括的に把握できるようになります。

マップタブでは、このメトリクス処理ポッドが何に関連しているかを確認できます。メトリクス処理コンテナが稼働していることがわかります。なるほど、納得です。メトリクス処理サービスもサポートしています。それでは、そのサービスを見てみましょう。

これは実はService Insightによって実現されています。Service Insightを使うと、集約的なサービスレベルビューを取得できます。つまり、メトリクスプロセッサアプリケーションを実行している10個程度のポッドを調べて、それらのポッド全体でアプリケーションのパフォーマンスを全体的に把握するのではなく、Service Insightを使って重要なメトリクスを集約し、メトリクス処理アプリケーション全体のパフォーマンスを示す統合ビューを取得できるのです。

ステータス ページでは、指定したメトリックを使用して、アプリケーションが正常かどうかを判断します。

そして、グラフ タブでは、このアプリケーションによって実際に処理されているさまざまな種類のデータ ポイントの数など、重要な集計メトリックの一部を取得できます。

また、このアプリケーションを実行しているコンテナの総数を示すヘルスメトリクスも用意しており、約13個のコンテナがあることがわかります。また、このアプリケーションのパフォーマンスを監視するためにチームが特に重視している主要なKafkaメトリクスもいくつか用意しています。

したがって、このサービス レベル ビューを使用すると、サービスまたはアプリケーションが全体としてどのように実行されているかを統合的に表示できるため、リソースごとに細かく分析する必要がなくなります。

このようなアプリケーションを検討する際にチームが活用するダッシュボードの 1 つを見てみましょう。

同じ例に沿って進めていきましょう。メトリクス処理アプリケーションを見て、地域別のダッシュボードの1つを見てみましょう。

ここで、チームがこのアプリケーションで重視している点に注目する際に、特に重視するウィジェットがいくつかあることがわかります。

CPU やメモリから、ポッドがこのアプリケーションを再起動した回数、実際に実行されているコンテナの数、本当に重要なメトリック処理時間の一部、主要な Kafka メトリックの一部、実際に実行されているレプリカの数などの Kubernetes メトリックの一部まで、あらゆる情報が含まれます。

下にスクロールしていくと、水平ポッド自動スケーリングの仕組みや、このメトリック処理アプリケーションを実際に実行しているポッドに関するアラートなど、いくつかの詳細情報が表示されます。また、パフォーマンスが最適であることを確認するためにチームが特に注目したいその他の KPI も表示されます。

一番上までスクロールすると、ダッシュボードフィルターが使用されていることがわかります。このダッシュボードフィルターを使うと、表示するデータの範囲を特定のポッドに絞り込むことができます。これは非常に便利な機能で、ここに表示されているすべての値ごとにダッシュボードを再作成することなく、特定のポッドに範囲を絞り込んだ動的なダッシュボードを即座に作成できます。これらのダッシュボードフィルターは、チームの効率性を高め、時間を節約するのに非常に役立っています。

最後に、可用性とパフォーマンスの最大化以外に、LogicMonitorがどのように私たちのチームのビジネス価値向上に貢献しているのか、注目していただきたいと思います。その一つが、昨年リリースした新しいコスト最適化製品です。それでは、マルチクラウド支出の概要と、それがどのようなものなのかを見てみましょう。

LogicMonitor では、クラウド プロバイダー全体にわたる優れた課金概要が提供され、支出対象のリソースの種類、支出対象のリージョン、環境、アプリケーション、所有者、ビジネス ユニットなどの重要なタグ別など、いくつかの重要なディメンションごとに分類されていることがわかります。

これらは、クラウド支出がさまざまな支出方法にどのように割り当てられているかについての洞察を提供することを目的としています。

では、上部にある週次トレンドを見て、支出が時間とともにどのように変化しているかを見てみましょう。増加していますか？減少していますか？月末にはどうなるでしょうか？これらは、私たちのチームがAWSにどれだけの支出があり、どのように調整する必要があるかを実際に監視するために使用しているビューです。

複数のAWSアカウントを使用しており、支出が分散しているため、プロバイダー別、アカウント別のビューがあることがわかります。これらのビューにより、調整が必要な箇所を詳細に把握できます。

それでは、この支出を最小限に抑えるために実際にどのような調整を行うことができるかについて、LogicMonitor が提供する推奨事項を見てみましょう。

LogicMonitorは、パフォーマンスデータとコストデータを組み合わせて、支出を削減できる箇所を提案してくれます。例えば、利用率の低いインスタンスのサイズを変更できるかもしれません。

いくつかのインスタンスをクリーンアップし、アタッチされていない、あるいは忘れ去られたEBSボリュームをいくつかクリーンアップできるかもしれません。年間で節約できる金額は左側に表示されています。これらの行を展開すると、推奨対象のインスタンスと、この推奨を行う理由を説明するコンテキストデータが表示されます。

このトピックや、このデモで紹介した他の内容については、多数のブレークアウト セッションがありますので、ご興味があればぜひご参加ください。

しかし、これで、LogicMonitor が LogicMonitor を使用して IT 運用およびプラットフォーム エンジニアリング チームをサポートし、効率と効果の向上にどのように役立っているかについて、ご理解いただけたかと思います。

さて、プラットフォームの現在の機能について説明してきましたが、プラットフォームをさらに改善するために、今年のロードマップで私たちが行っている取り組みについて少しお話ししたいと思います。

今年、私たちが提供したいと考えている主要なソリューションは 5 つあります。複雑なハイブリッド環境に対するクラス最高の可視性を維持するためのカバレッジの拡大から、環境が複雑化し、データ量が増えていく中でトラブルシューティングを加速できるように支援する方法まで、多岐にわたります。

Edwin AI を使用してこれを次のレベルに引き上げ、さらに迅速に進める方法についてお話します。

そして、ダッシュボードとレポートをより動的かつインタラクティブにし、同時により使いやすくして、より有意義なビューを実現できるようにするにはどうすればよいでしょうか。

そして最後に、アプリケーショントレースのような高額なコストや煩雑な設定を必要とせずに、十分なアプリケーション可視性を提供するにはどうすればよいでしょうか？これは、先ほどビデオでご紹介した内容とほぼ同じです。私たちはメトリクスとログを用いてアプリケーション可視性を実現しており、ご覧のとおり、非常に包括的なものでした。

先月3月に上半期のローンチを発表したばかりなので、具体的にどのような発表をしたのかお話ししたいと思います。特に最初の3つのソリューションに注力しました。午後の基調講演では、残りの2つのソリューションについて詳しく説明し、今年残りの期間の取り組みについてもお話ししますので、ぜひご参加ください。

それでは、上半期のリリースで発表した内容について説明しましょう。

カバレッジの拡大に関しては、4つの重要な発表がありました。1つ目は、コスト最適化製品の機能強化です。これについては後ほど詳しく説明します。また、AIハードウェアとサービスの監視カバレッジの追加についても発表しました。

これは、皆様のAIスタックの可視性を高めることを目的としています。これにより、皆様がより自信を持ってAIを導入し、AI導入を加速していただけることを願っています。

クラウドとコンテナの監視範囲の拡大を発表しました。

さらに、IT インフラストラクチャの監視についても、特にクラウド管理ネットワークに重点を置いた記事を今後さらに掲載する予定です。

それでは早速、これらの機能について見ていきましょう。コスト最適化に関しては、LogicMonitorダッシュボード内で参照できる新しいダッシュボードウィジェットが登場します。このウィジェットは、先ほどデモでご紹介したコスト請求ビューを表示するために使用できます。ダッシュボードでは、パフォーマンス、健全性、可用性といった指標と並んで、このビューを確認できます。これらは、コストデータを確認する際に期待されるBIのようなドリルイン/ドリルアウトを容易にする新しいウィジェットタイプです。

また、これらのコスト最適化推奨事項の推奨事項ライフサイクルも発表しており、導入する予定です。

右側には、無視、スヌーズ、確認のボタンがあります。

これらは、これらの推奨事項と推奨事項のリストがチームにとって長期にわたって関連性を保つことを保証するのに役立ちます。

AIハードウェアとサービスの新たな監視範囲については、3つの層に分けて考えています。一番下、つまりインフラから始まります。

LogicMonitor は優れたインフラストラクチャ監視機能を備えていることはご存じのとおりですが、最近、NVIDIA GPU 向けの新しい監視機能を発表・リリースしましたので、それについてご説明いたします。

LLMレイヤーでは、トークンの使用状況や支出状況など、活用しているLLMに関する洞察を確実に得られるようにしたいと考えています。そこで、OpenAI向けの新しいモニタリング統合をリリースし、その情報を明らかにしました。

そして、アプリケーション層では、Amazon Q との新しいモニタリング統合を導入しました。また、従来のメカニズムでは得られないトークンの使用状況に関する洞察を提供するために、OpenTelemetry を通じて動作する OpenLit との統合もリリースする予定です。

つまり、GPU モニタリングに関しては、これは収集できるもののスナップショットです。

GPU 使用率、メモリ使用率、温度など、おそらく表示されると思われる多くのメトリックがあります。

これは、活用している AI をサポートする AI スタックについての洞察を提供し、より自信を持って AI を導入し、AI の導入を加速できるようにすることを目的としています。

クラウドとコンテナの監視に関しては、非常に包括的な Kubernetes 監視ソリューションを提供しています。

ただし、Helm経由でクラスターに直接独自のアプリケーションをインストールする必要があります。そして、皆さんとお話させていただいた中で、クラスターに直接アクセスできない場合もあることがわかりました。

そこで私たちがリリースするのは、Amazon と Azure のクラウド プロバイダー API (AKS と EKS) を介したゼロ タッチ モニタリング オプションです。このオプションを使用すると、クラスター自体にアクセスすることなく、これらのクラウド プロバイダー内の Kubernetes クラスターに関する洞察が得られます。

これにより、クラスター内で何が実行されているかについて、詳細な情報が得られます。アプリケーションレベルまでは詳細に把握できませんが、デプロイは非常に簡単です。

ITインフラストラクチャ監視に関しては、数枚前のスライドで述べたように、特にクラウドマネージドネットワークに注力しています。この分野の主要ベンダーすべてを網羅できるよう努めています。

昨年、Cisco Merakiとの連携を大幅に刷新することを発表しました。今年は、Aruba、特にArubaの中央管理型アクセスポイント向けの新しい監視機能をリリースしました。年内には、Juniper Mistのアップデートに加え、アクセスポイント分野でも複数の新規ベンダーの製品に対応予定です。

以上が、監視範囲の拡大に関する発表内容です。次に、トラブルシューティングの迅速化をどのように支援しているかについて少しお話しします。

ダウンタイムはコストがかかることを私たちは理解しています。ツールを切り替えたり、ロジックモニターの外でスイッチを操作する手間を省きたいと考えています。そこで、その負担を軽減するために私たちが行っている取り組みをご紹介します。

当社では、ログ ソリューションを改善して、より迅速に洞察を明らかにし、トラブルシューティング プロセスを迅速化できるよう努めています。

真ん中の柱は、前半の終わりにベータ版としてリリースされる新しい詳細な診断機能に関するものです。この機能では、アラート発生時に通常はLogic Monitorの外部で取得する必要がある追加情報（例えば、CPU使用率が高いアラートを受け取った際にCPUを最も多く消費しているプロセスは何かなど）を収集できるようになります。こうした情報を収集し、Logic Monitor内で直接表示することで、トラブルシューティングを迅速化したいと考えています。

最後に、アラート詳細のUIを刷新します。SMSメッセージからでもEdwinからでも、最も関連性の高い詳細情報を提供し、より迅速にトラブルシューティングできるよう努めています。

もちろん、当社のログ製品には、ログデータの何が異なっているのか、何に注意が必要なのかといった洞察を的確に抽出する異常検出機能があります。また、ログ分析機能では、自然言語処理によって大量のログデータ全体における主要な感情やキーワードを、非常に視覚的かつインタラクティブな方法で表示します。ここでも、複雑なクエリを記述することなく洞察を抽出できるようにすることが目的です。

これは先ほどお話しした改良されたアラートUI、特にグラフタブです。先ほどデモでお見せした内容からお分かりいただけるかもしれません。ここでの狙いは、アラートに入力されたデータポイント以外のグラフも表示することです。つまり、この例ではTomcatのグラフだけでなく、CPUとメモリも表示できたはずです。これにより、アラートUIを長時間表示できるようになり、トラブルシューティングの迅速化につながります。

ログ製品については、上半期末に「クエリリストログ」という機能をベータ版として導入する予定です。この機能では、ログクエリを自然言語で入力できます。入力されたログクエリは、当社のログクエリ言語に翻訳されます。

最終的には、これにより、探しているログをより速く見つけ、トラブルシューティングのためにそれらの分析情報をより速く提供できるようになることを願っています。

また、クエリ共有ライブラリにも改善を加え、毎回複雑なクエリを最初から構築しなくても、必要なクエリやログを簡単に見つけられるようにします。

最後に、ログページに新しい視覚化機能が追加されます。ログデータの解釈がより迅速になります。現在は棒グラフと折れ線グラフが中心ですが、今後は円グラフ、大きなウィジェット、ドーナツグラフなどのオプションも追加される予定です。これにより、ログデータの解釈がさらに迅速化し、トラブルシューティングのスピードアップにつながるはずです。

以上が、トラブルシューティングの加速に関する上半期の発表です。

上半期のローンチにおける3つ目の柱であるKarthik氏にステージに上がっていただき、お話ししたいと思います。

おはよう。

今朝、クリスティーナから、私たちがどれほど素晴らしい旅をしているかを聞きました。そして、アンドリューが来て、クラウドが私たちが考えていた以上に複雑であることが判明したことについて話してくれました。

AIは、全く違う旅になるだろうと教えてくれます。このAI生成画像には、一部正確な部分もあると断言できます。

私はベイエリアに住んでいるので、AI広告を一面にたくさん見ることができます。確かにそうです。ドローンもたくさん飛んでいます。でも、高速道路がこんな風になるなんて、ベイエリアでは考えられません。

では、AIの現実に目を向けてみましょう。そうでしょう？現在、市場ではAIによる歪曲が盛んに行われています。Charge epdが発売されてから2年が経ちました。そして、明らかに、この狂乱的な駆け引きが起こっています。

誰もがAIに取り組んでいて、「自分もAIを持っている」と自負しています。しかし、顧客にとって、ノイズをかき消して何が真実なのかを見極めるのは非常に困難です。そうでしょう？ 今年は、すべてのAIが同じように作られているわけではないという点について議論する時期だと思います。

そうですか？AIを導入したからといって、必ずしもROIが得られるとは限りません。本当にROIが得られるわけではないので、これまで以上に多くの疑問が生じています。CIO（最高情報責任者）からも話を聞いていますが、彼らはPOC（概念実証）を減らしています。AIのPOCは、もう終わりにしつつあるようです。

ある企業の例を挙げたいと思います。今年の初めに起こった出来事です。大手金融機関です。

大規模な停電とサービス停止が5日間近く続いたんだ。そうだろ？銀行のことか？

それが日常の消費者にとって何を意味するか考えてみましょう。

入金もできませんし、出金の確認もできません。

そして調査を行ったところ、問題は彼らではなくベンダーにあることが判明しました。

ベンダーは、ハードウェアを使用しているデータ センターで停電を経験しました。つまり、バックアップはないのかと疑問に思うでしょう。

バックアップも失敗しました。そうですよね？ では、このような混乱にはどう対処するのでしょうか？ ところで、この企業はAIの最前線に立つ企業の一つです。

彼らはすでにマイクロサービスを導入しているのに、どうして5日間の停止を経験できるのでしょうか？

そうですよね？もちろん、そうなると何が起こるかはご存じの通りです。多くの顧客が離脱し、訴訟に発展するでしょう。しかし、私がこの例を挙げたのは、AIを扱っているからといって、それが万能薬ではないからです。クラウドの事例のように、根本に立ち返る必要があるのです。

あなたのデータ戦略は何ですか？ガバナンス戦略は何ですか？どのようなユースケースを解決していますか？LogicMonitorをご覧になった時点で、私たちはすでに最高のデータを持っていることがわかりました。

ハイブリッドで収集するデータについて考えてみると、これらはすべて非常にミッションクリティカルなデータです。そして、その上にAIを導入する方が、企業が単にAIを後付けするよりもはるかに簡単です。この点について簡単に説明したいと思います。これはAIだけの問題ではなく、収集するデータにも関係します。

AI運用について考えたとき、昨年、皆さんやアナリストの方々とたくさんお話をしましたが、明らかに多くの不満がありました。そこで私たちは、「では、これを単なる追加機能ではなく、根本から実現するにはどうすればいいでしょうか？」と考えました。そして、多くのお客様がAIツールを購入しても、AIを管理するために2人もの人材を雇わなければならないことに不満を抱いているという話を耳にしました。一体何の意味があるのでしょうか？

だから完全に違うものでなければなりません。

まずはエージェンティック。昨年流行語になる前から、私たちはエージェントについて語ってきました。

エージェントの重要な点は、人間が80%の作業を行うのに対し、AIが80%の作業を実行できるようになったことです。つまり、逆転したということです。

私たちが収集したすべてのデータは、オンプレミスのデータセンターで最も収集が難しいデータの一部です。私たちが持つコレクター技術は並外れています。

これを、企業内のあらゆるデータ、つまりインシデントデータ、変更データ、問題データ、オンコール記録、ナレッジベース、外部ナレッジベースと組み合わせ、すべてを統合します。なぜでしょうか？それはまさにお客様が求めているからです。お客様は、単に可観測性データとインシデントデータをサイロ化した状態で見るのではなく、それらを統合したいと考えています。これは難しい問題ですが、AIの観点から言えば、すべてのお客様がまさにこのように考えています。

そして最後に、つまり、昨日顧客が私に尋ねたんです、「ねえ、どうやって価格を決めるんですか？」

それで、それはアラートノイズによるものなんですか？ アラートノイズで料金を請求するビジネスではありません。成果を上げるお手伝いをしたいんです。

箱の大量生産でもヘルスケアでも、どんなビジネスでも、私たちはこのAI技術をお客様の成果に結び付けたいと考えています。もちろん、方法は様々ですが、この技術をお客様のビジネス成果に結び付けることが私たちの真のコミットメントであることを明確にしておきたいと思います。

そこでEdwin AIを購入しました。これは、エージェント型AIオペレーションに対する私たちの答えです。Edwinについて考えていた当時、興味深かったことの一つは、これが単なるチャットボットではないということです。そうでしょう？チャットボットはテーブルステークス（最低限の必須機能）のようなものです。私たちはEdwinを、アクションへと導くものにしたいと考えています。

そこで私たちは、3 つのユースケースでこれに取り組みました。

1 つ目は、私たちの主な仕事である、データ センター内のノイズをいかに低減するかということです。

そこにはたくさんのノイズがあります。ご存知のように、これはロジック モニターですでに実現されていますが、他のツールもあります。

APMツール、ログツール、クラウド監視ツールをご利用かもしれません。

ネットワークやフロントレイヤーだけでなく、スタック全体にわたってイベントインテリジェンスを実現します。これがお客様からのご要望です。ドメイン間の相関関係を分析できる単一のツールが欲しいのです。

すでにデータを収集しているので、これは私たちにとって非常に簡単です。お客様のインフラネットワークデータはすでに取得済みです。それをAPMベンダーのデータと組み合わせるのは非常に簡単です。そして、お客様は突如として貴重な洞察を得ることになります。

ネットワークが遅かったのは承知しています。それがサービスに関する洞察とどのように関連しているのでしょうか？

右？

ここにいらっしゃるお客様と、次のレベルのイノベーションに取り組んでいます。BGPピアの監視や理解の強化といった、高度なネットワーク相関技術の活用について検討しています。これはまさに私たちが革新を進めている分野で、多くのお客様に導入いただいています。そして、ご存知の通り、私たちはGenAIに注力しています。そうですよね？

GenAIエージェントは、私たちの次の取り組みです。チームの生産性を本当に向上させる方法についてお話しします。クリスティーナから聞いたように、何が起こるかというと、45分が戻ってくるんです。これは画期的なことですよ、皆さん。

他にできるプロジェクトを全部考えてみてください。そうでしょう？つまり、これはあなたのデータに対するChargebeeインターフェースに他なりません。

そうですか？そしてループを閉じるために、私たちが本当に投資したいのは自己修復型データセンターです。

これは長い間約束されてきましたが、私たちのテクノロジーが本当に成熟したため、これまで以上にこれに近づいています。

皆さんからお話を伺い、お客様と連携してきたエージェントの皆さんが全員、本日ここに来られることをお知らせします。そうですよね？ 実は、もっと良いものにしたいと思っています。彼らは今日ここにいます。

そうですか？これらのエージェントへの早期アクセスを申請できますよ。デモブースもいくつかありますので、ぜひお試しいただけます。もしご興味があれば、ぜひお気軽にお問い合わせください。

お客様の環境に合わせて設定できます。これらのエージェントは本当に魅力的です。

汎用 IT 運用チャットボットについて話すことができます。

そうですか？IT運用に関することなら何でも。公開されている情報でも構いません。Slackに障害は発生していますか？Ciscoに障害は発生していますか？Webにアクセスして、リアルタイムの障害情報を取得できます。

あなたの洞察について話してください。私のデータについて話してください。いいですか？この洞察はどうなっているのですか？何が起こったのか、時系列で教えてください。

すべてにダッシュボードを作る必要はありません。これらの質問を分かりやすい言葉で問いかけるだけで、答えを得ることができます。

複雑なアラートがあったので、要約して、ずっと質問してきたチームに送れるように手伝ってほしい。そうでしょう？皆さんは、どれくらい「このPのステータスはどう？」って通知を受け取ったりしますか？

要約だけください。上司に送れます。

そして最後は、チャートやフィルターとして本当にエキサイティングです。

皆さんの中に、構築すべきダッシュボードのバックログを抱えている人はどれくらいいますか？そうですよね？常に新しいダッシュボードが待ち受けています。AIを使えば、文字通り質問をするだけで、それをクエリに変換し、即座にダッシュボードを構築できます。

これはまだ始まりに過ぎません。これから多くのエージェントが、先ほどお話ししたSaratayやServiceNowの類似インシデント、自動化プラットフォームのプレイブックなどを使ってログを作成していくのが見られるでしょう。では、実際にどのようなものなのか、デモで見てみましょう。

Edwinのインターフェースには、実際に質問できるクエリがあります。デバイスやCIごとのアラートをいくつか表示してほしいと言えば、そのクエリがバックグラウンドで理解できる形に分解され、文字通り即座にチャートが作成されます。

それはどれくらい涼しいですか？

これで、このチャートを操作して、例えばフォローアップの質問をすることができるようになりました。では、ServiceNow でこのチャートに作成されたインシデントは何件ありますか？

ServiceNow とは言っていませんが、理解しています。

次に、ServiceNow テーブルをクエリして、インシデントがいくつ取得されたかを確認します。

追加の質問をして、「では、これらのうち相関関係のないアラートはいくつありますか？」と尋ねることができます。それらは単なる単一のアラートです。

そして、2番目のチャートを作成します。

そうですか？つまり、これらは非常に高度な推論モデルのようなもので、具体的にどのようにこのデータを分析して次のステップに進むかを考えるのです。

そうですか？ですから、質問をすることでチームの生産性がどれだけ向上するかを真剣に考えてみてください。これはほんの始まりに過ぎません。私たちは、Gen AIの概要など、簡単に実行できるユースケースを用意したいと思っています。これは非常に多くの要望があるものです。もう少し詳しく教えてください。このインサイトで何が起こっているのでしょうか？タイムライン全体を教えてください。

そうですか？それをコピーして貼り付けて、チケットに入れてください。

「どうすれば直りますか？ 誰かが以前に修正した方法はありますか？ 知りません。私はこの会社に新しく入ったば​​かりです。」と尋ねることもできます。

そして、AI がステップごとのランブックを生成します。

ランブックをお持ちなら素晴らしいです。お持ちでない場合は、この問題を解決する方法をステップバイステップで詳しく説明します。

皆さん、それについて考えてみてください。

つまり、今はネットワークエンジニアになりたいんです。

そうですか？そしてもちろん、ServiceNowで事後分析レポートを作成してプッシュすることで、ループを閉じることができます。つまり、お客様のインシデントインテリジェンスを非常に充実させているということですね。

インシデントはプレースホルダーです。収集した豊富なデータを活用して、インシデントを充実させていきます。

さあ、未来に戻って、これから何が起こるのか考えてみましょう。いいですか？例えば、お客様が「Edwinは気に入っているけど、TeamsとSlackで使えるの？」と尋ねたとします。というのも、ユーザーはTeamsとSlackに集まっているし、CIOはポータルにログインすることはないからです。もちろん、できます。

Edwin は Slack や Teams 内で操作できるエージェントです。エージェント同士の将来はどうなると思いますか?

従業員エクスペリエンスまたは顧客エクスペリエンスのためにすでに社内にエージェントを展開している場合は、これらのエージェントが互いにどのように通信するかについて考え始めることになります。

これらの従業員エージェントのほとんどは、当社が収集するデータにアクセスできません。

だから、絶対に必要です。IT関連のよくあるトラブルで「ネットワークがダウンしています」という人がいたとします。一体何がネットワークダウンなのでしょうか？みんなネットワークのせいにしますが、ネットワークの問題ではありません。

エドウィンはネットワークの問題ではないと言うでしょう。

そうですね？インシデントを減らして、ネットワークエンジニアに任せましょう。余計な雑音で煩わせないでください。ここで例を挙げましたが、私たちが本当に目指しているのは、自動化です。

YAMLプレイブックを使えば、何かあれば検索して見つけ出すことができます。また、ランブックをリアルタイムで生成することもできます。これはまさに自己修復型データセンターへの第一歩です。これはSFの世界ではなく、現実のものです。

私達はそれをすることができます。

舞台裏で何が起こっているのか、少し説明させてください。本当にワクワクしています。エンタープライズソフトウェアとして、お客様の生産性向上に貢献できると考えています。ですから、数百のエージェントをリリースする予定です。

間違いありません。そうでしょう？さて、先ほどお見せしたように、インサイトエージェント、メトリックエージェント、ログエージェントがリリースされる予定です。これらをリリースし続けていきます。

これらすべてが、私たちが収集したツールとサードパーティのツールを包み込みます。

私たちが本当にやりたいのは、サービス プロバイダーや顧客向けにエージェント スタジオを公開することです。

当社のプラットフォーム上で構築できるようになりました。

独自のデータ ソース、つまり独自のデータ ソースがある場合は、このプラットフォームでエージェント ワークフローを構築することをお勧めします。

別のツールを使ってつなぎ合わせようとするのではなく、AIの出力をカスタマイズできるプラットフォームを提供します。お客様独自のAIソリューションを構築できるプラットフォームを提供します。なぜなら、最先端のAIプラットフォームを一元的に構築できる必要があると考えているからです。Logic Monitorで全てを実現できるわけではありませんが、このプラットフォーム上で構築していただければ幸いです。

これが、私たちがあなたに代わって重労働を担うエージェント AI オペレーションのビジョンです。

私たちはこれらのコネクタを構築しています。

なぜでしょうか？ お客様が本当に求めているのはこれだからです。新たなコネクタを開発する気はありません。

これは必須事項のようなものです。できるだけ多くのデータを構築したいのです。そこで、これらのコネクタを構築していきます。すでにいくつかのコネクタの開発に着手しており、今後はチェーンシステム、オンコールトランスクリプト、ランブック、ナレッジベースなどを構築していく予定です。

非常に幅広いデータが得られます。さらに、ネットワークの奥深くまで掘り下げていきます。パケットデータを調べることはできますか？合成分析はできますか？

皆さん、まだ表面をなぞっただけです。全てを理解したわけではありませんが、進むべき方向は分かっています。そして、この問題に取り組み続けるつもりです。そして第二層はセキュリティです。こんなものを作りたくはありません。

保証します。本当に大変です。時間がかかります。つまり、私はこれを5年間やってきましたが、まだ模索中です。そうですよね？

安全なラックソリューションを構築するのは本当に難しいです。従業員がナレッジベースにアクセスできないようにするにはどうすればいいのでしょうか？

1 つの LLM ベンダーに縛られないようにするにはどうすればよいでしょうか?

LLM ベンダーを変更したい場合はどうすればよいでしょうか?

ご存知の通り、新しいLLMが登場して、皆が慌てふためくような状況が起こりましたね。そんな時、どうすればいいでしょうか？LLMゲートウェイを構築するということですね。

システム内の独自の情報にアクセスできるように RAG を構築する必要があります。

これらすべてのデータを繋げるナレッジグラフを構築したいですよね。これらはすべて重要な構成要素であり、私たちのビジョンは、これらの構成要素を提供し、その上に構築できるようにすることです。

そこから、今年初めに発表したOpenAIをはじめとする、私たちが取り組んでいるエキサイティングなイノベーションについてお話ししたいと思います。彼らはエージェント・イノベーションの最前線に立っています。

私たちと彼らが行っているパートナーシップの一部は、テクノロジーへのアクセスを得ることです。

そのため、古いモデルのような推論モデルであれ、GPD モデルの一部であれ、当社のチームは緊密に連携して、市場に出るずっと前にこれらのプレビューを開始できるようにしています。

そうですか？そして、私たちはまだリリースされていないものにもアクセスして、その技術の一部についてフィードバックも提供しています。

私がお話しするのが楽しみな 2 つ目の話題は、まだ初期段階ではありますが、Red Hat と今後について話しているところです。

データセンターとハイブリッドについて言えば、これらのパターンの知識をどのように活用してランブックの生成を支援するかという点で、これは非常に適したソリューションです。そこで、ロジックモニタープラットフォームとAnsibleプラットフォームの一部をより緊密に統合する方法について、Red Hatチームと直接話し合っています。

AIの話はもう十分です。次は顧客について話しましょう。そうでしょう？これこそがまさに肝心なところです。

昨年Edwinをリリースして以来、生産現場で驚くべき成功を収めています。まだ導入を検討しているお客様もいらっしゃると思いますが、SyngentaのChris Manning氏もEdwinのすぐに使える機能をいくつか使ってみて、その価値実現までの時間の長さに驚かれたようです。

彼らがその価値を理解し始めるまでにかかった時間は 1 時間でした。

そうですか？実際、エドウィンはチームが3年間見落としていた設定変更を指摘してくれたそうです。

そしてエドウィンは、そのことを本当に可視化してくれました。

アジア太平洋地域最大級の小売業者であるChemist Warehouse。2つのデータセンターを所有し、6,000台以上のデバイスを保有していると思います。

そして、データセンターの騒音が 88% 削減された状態で稼働を開始しました。

彼らはGenAIで私たちと連携しています。つまり、彼らは本当にそこに取り組んでいるということです。例えば、どうやって要約を出すんですか？ 後ほどジェシーから、彼らがどれほど興奮しているかを聞きます。

そして、サービス プロバイダーについて言えば、最大手のサービス プロバイダーの 1 つである Nexon は、1 か月あたり 140 万件のイベントを受け取っています。

ServiceNowのチケット数を70%削減しました。一人ひとりにどれだけの時間を節約できたか、そして顧客体験について考えてみてください。

毎月確認する必要のあるチケットが 70% 減少します。

Devotingは8週間で稼働を開始しました。これは導入に1年もかかるようなものではありません。

8週間です。

そして、Markelはご存知の通り、従来型のAROベンダーを利用しています。彼らは私たちの方向性を理解し、Logic Monitorとの連携を決定したのです。そうですよね？

そこで、ビデオをご覧いただき、Edwin がお客様のビジネスにどのような影響を与えているかについて、直接お話を伺いたいと思います。

ああ、期待以上でした。結果は劇的でした。おっしゃる通り、Edwin AI を有効にしてからアラートの量が88%も減少しました。

私たちにとって、これは単なる数字ではなく、チームの日々の生活の質の向上です。ですから、おそらく最も大きな影響は、問題解決に費やす時間が減ったことだと思います。

私たちは現在、ビジネスのための新しいソリューションの構築と、既存のソリューションの改善に重点を置いています。

つまり、ビジネスに真の価値をもたらすのです。

LogicMonitorプラットフォームの重要なメリットの一つは、Edwin AIと呼ばれるAIモジュールです。このモジュールは、予測分析だけでなく、自己修復、イベント相関分析など、多くの価値をもたらします。

ほぼ1時間も経たないうちに、チケット件数が著しく減少し始めました。私たちが処理していたチケットの説明欄には、実際に何が起こっているのかを正確に示すデータが含まれていました。これにより、影響度も把握できました。なぜなら、影響度を測定するのは非常に難しい場合が多いからです。私たちが望んでいるのは、エンジニアがデータの分析に膨大な時間を費やすのではなく、問題の解決に集中してもらうことです。ですから、Edwinがすぐに提供してくれた機能の一つが、データのより詳細な分析でした。

クリスの言葉で一番好きなのは、彼が25年くらいネットワーキングに携わってきたって言ってたことです。「ネットワーキングがまたクールになったんだ」って。ほら、今は本当にエキサイティングな時代だよ。それに、新しい働き方だって言える。つまり、これは本当にプレッシャーの大きい仕事だと僕は思っているんだ。

ご存知の通り、AIは様々な機能がありますが、その中でも特に苦労が多いのがこれです。冗長性が多く、膨大な作業量があります。負担軽減が必要です。そうでしょう？もしあなたがAI導入に迷い、傍観者でいるなら、「自分はまだAI導入の準備ができていない」と思うかもしれません。

もう十分です。何人かのお客様とお話できます。彼らの旅がどんなものだったか。そうでしょう？

しかし、これらのインシデントの分析に20分、30分も費やしていることを考えると、その苦痛は計り知れません。高度に技術的な情報であり、解釈が非常に困難です。非常に人間的な問題です。

最高のエンジニアたちに頼って、なんとか救おうとしているんですよね？

そして戦略会議の部屋について考えてみましょう。

君たちはいくつの戦略会議に出席したことがあるんだ？ ね？ ショーン、ワークショップをやるんだけど、ワークショップの直前に彼は戦略会議に入らなきゃいけなかったんだ。確か40人か50人くらいだったと思うけど。

挙手してください。皆さんがこれまで参加した最大の作戦会議室の規模はどれくらいでしたか?

40人に勝てる人はいるでしょうか？

うん？

サイズはどれくらいですか？

150ですか？

9,900 ですか？私が聞いたのは正しいですか？

何が起こったのか？

あるお客様から、1000人以上になるという話を聞きました。クラウドストライキのせいです。なるほど、説明がつきましたね。つまり、これが新しい働き方になるということですね。エージェントは隣り合って働くことになります。入れ替えるわけではありません。

基本的に、並んで座っているだけで生産性が高まります。私たちは日常業務でこれを使用しています。

これは新しい働き方です。エージェントと連携して生産性を高める方法を学ぶための新しい方法です。チケットのトリアージに時間を費やす必要はありません。それは実際には付加価値のある仕事ではありません。

実際、警告すら見ていないのではないでしょうか。多くのお客様は警告を見ずに、「何かが重大になるまで待とう」という態度を取っています。もししきい値が適切でなかったらどうなるのでしょうか？適切なしきい値をどうやって判断するのでしょうか？

AI は、デバイスに設定する適切なしきい値などを教えてくれるようになりました。

そうですか？エンジニアリングチームとSRE、そしてエージェントが協力して作業できる、本当にエキサイティングな時代が来ていると思います。

そして、価値について話しましょう。そうでしょう？これは非常に重要です。多くのAIが存在します。皆さんも様々な部門でAIに取り組んでいると思います。

しかし、このユースケースは ROI の点で非常に優れています。

つまり、これはあらゆる角度からビジネスに影響を与えます。OPEX（運用コスト）の効率化にもつながります。サービスプロバイダーであれば、少ないコストでより多くの成果を上げることができます。70%の削減でその成果を実感していただけます。従業員の生産性も向上し、30～45分で改善されます。カスタマーエクスペリエンスも向上します。万が一、サービス停止が発生した場合でも、復旧に努め、数百万ドルのコスト削減を実現します。

そして、なんと！ケーキの上にも見えます。ツールの統合とライセンスコストの削減をお手伝いします。

ぜひ、このビジネス価値の一部について私たちと一緒に取り組んでください。私たちがお手伝いします。最後に、Logic Monitorを選ぶにせよ、他のベンダーを選ぶにせよ、これは将来を見据えたAIベンダーをどう選ぶかという問題です。そうですよね？多くのお客様とお話してきた中で、私は3つのポイントに絞りました。

AI ネイティブ製品は AI アドオンに勝つでしょう。

AIをただ追加して「よし、勝利宣言だ」なんて言えません。そんな風にはいきません。全てのレイヤーについて考える必要があります。エージェントは全く異なるスタックです。

SaaSについて考えてみてください。SaaSが登場した当時は、アーキテクチャには様々なレイヤーがありました。まさに同じことです。私たちはそれらのレイヤーを構築しているのです。

メモリはどれくらいですか？ストレージはどれくらいですか？エージェントの可観測性はどうですか？

これは私たちがEdwinで行ってきたことです。AIネイティブアプリです。

LLMをただ付け足して「AIを習得しました」なんて言うわけにはいきません。そんな風にはいきません。次に、多くのお客様が「自分で作った方がいいのか、それとも買った方がいいのか？」と悩んでいるのです。

そしておそらく答えは両方でしょう。

これがコアコンピテンシーではない業界にいる場合は、これを構築することはお勧めしません。

金融サービス業界であれば、信用モデルを構築したいと考えるのは当然です。しかし、これがIT運用であり、相関分析や根本原因分析がコアコンピテンシーでない場合は、テクノロジーの変化が激しいため、取り組む価値はありません。

だから私は、プラットフォームを活用して、その上に構築していくべきだと言います。しかし、そこに入り込んで「構築する機会がない」と言うわけにはいきません。だから私たちは両方を考えています。そうでしょう？そして最後に、本当に重要なのは、冒頭で述べたように、AIは万能薬ではないということです。必要なのはデータです。

右にシフトする企業もありますが、私たちは左にシフトすることを選びました。ログ、メトリクス、メタデータにさらに近づくことで、エンジニアが問題をより早く解決するために必要な情報を提供できるようにしたいのです。

問題を先送りするだけのコマンドセンターはもう不要です。エンジニアに時間を与え、問題を解決するための情報をジャストインタイムで提供し、システムを復旧させたいと考えています。そのため、ロジックモニターとハイブリッドな可観測性をEdwinと組み合わせることで、お客様が必要とする次のレベルの可観測性を実現します。ありがとうございます。

うわー。

吸収するには多すぎました。Karthik と Sarah からは本当に素晴らしいものが得られました。

簡単にまとめると、私たちの製品、私たちのプラットフォームについてたくさん話しましたが、結局のところ、皆さんに理解していただきたいのは 3 つの重要なテーマです。

ハイブリッドカバレッジを拡大し、プラットフォームにできるだけ多くのデータを簡単に取り込めるようにしています。

Sarah からは、コストの最適化、AI ワークロードのサポート、コンテナの監視、クラウド管理ネットワークの強化など、その時代におけるあらゆる進歩についてお聞きいただきました。

データがプラットフォームに取り込まれたら、それを活用してトラブルシューティングを迅速化することが私たちの使命です。ログを活用してテレメトリをすべて取り込むことで、複数の異なるシステムにログインする必要がなくなります。従来の監視ツールは不要になり、クラウドワークロードごとにベンダー固有のツールを使用する必要もありません。トラブルシューティングを迅速化できます。

そして、未来のKarthikさんからお話を伺いました。

私たちはIT運用のエージェントです。Karthikがお話ししたように、エージェントは今日ここにいます。私たちは、このエージェント型AI運用の未来を切り拓いています。製品とエンジニアリングの観点から私たちが行っていることはすべて、皆様を支援するために設計されています。これについては、本日の残りのブレイクアウトセッションで詳しくお話しします。午後には、Sarahが今後の展望、今後の展開、そして今年後半に私たちに期待できることについてお話しします。そして、Andreaが、これがMcKessonのオブザーバビリティの姿勢をどのように変革しているかについてお話しします。

これまでお話ししてきたこと、クラウド、ネットワークへの継続的な投資、AIイニシアチブのサポート、トラブルシューティングワークフローの改善、ダッシュボードとレポートの最新化、サービスインサイトとログの新たなレベルへの引き上げ、IT運用におけるアプリケーションの可視性の向上、そしてもちろん、将来的にはEdwinとAgentic AI運用への取り組みなど、すべてにおいて私たちが取り組んでいます。私たちは、IT運用のヒーローである皆様とCIOの皆様が、AI時代の最新のデータセンターをうまく活用できるよう、全力でサポートいたします。