--- title: "AI対応テレメトリの6つの柱" page_name: "AI対応テレメトリの6つの柱" type: "blog" slug: "six-pillars-ai-ready-telemetry" published_at: "2026-09-02" modified_at: "2026-10-30" url: "https://www.sumologic.com/ja/blog/six-pillars-ai-ready-telemetry" canonical: "https://www.sumologic.com/ja/blog/six-pillars-ai-ready-telemetry" markdown_url: "https://www.sumologic.com/ja/blog/six-pillars-ai-ready-telemetry.md" lang: "ja" excerpt: "AI対応テレメトリの6つの柱を学び、統一された、正規化された、コンテキスト化された、最新の、調査可能な、そして説明責任のあるデータがなぜAIエージェントにとって重要なのかを理解します。" taxonomy_blog_category: - "SecOps とセキュリティ" - "AI" --- [ すべてのブログ ](https://www.sumologic.com/ja/blog "ブログ")[SecOps とセキュリティ](https://www.sumologic.com/ja/blog/secops-security), [AI](https://www.sumologic.com/ja/blog/ai) # AI対応テレメトリの6つの柱 [Chas Clawson](#blog-author-block-78)[Bogdan Kireeve](#blog-author-block-383) September 2, 2026 10 min read [SecOps とセキュリティ](https://www.sumologic.com/ja/blog/secops-security), [AI](https://www.sumologic.com/ja/blog/ai) ##### 目次 「AI対応」という言葉は今、ほぼすべてのカテゴリーのあらゆる製品に付けられています。このキャッチーなラベルはめったに具体的な意味を持たず、ベンダーが「AI-native」であると主張する場合も同様に疑問の余地があります。マーケティング用語をすべて整理した後には、標語ではなく標準が必要です。そして、その定義はデータの用途によって異なります。データウェアハウス向けのAI対応と、ライブ運用テレメトリ向けのAI対応は、同じ問題ではありません。 [テレメトリデータ](http://www.sumologic.com/glossary/telemetry)には計り知れない価値があり、AI セキュリティを販売するすべてのベンダーは同じ主張をしています。つまり、当社のモデルはより優れているということです。しかし、整理されていないデータを読むより優れたモデルは、悪い日には単により速く幻覚を見るだけです。良い日には、膨大な量のトークンを消費し、非構造化データに構造を追加します。本当の問題は、エージェントがどれほどインテリジェントであるかではありません。そもそもテレメトリがエージェントに消費されるために構築されたかどうかです。 ## テレメトリをAI対応にするものは何ですか？ AI対応テレメトリは単一の特性によって定義されるのではなく、それぞれが前のものの上に構築される6つの次元によって定義されます。これらが一緒になって、テレメトリデータレイクがすでに到来しているエージェント型ワークフローに対応する準備ができているかどうかを定義します。セキュリティとオブザーバビリティスタックの上にボルトで留められた機能ではなく、その下にあるデータの標準です。これら6つの特性がAI対応テレメトリを定義していると考えています。 1. **統一**：データは1つのクエリ可能なプレーンに存在します。 2. **正規化**：データは一貫した構造と意味を持ちます。 3. **相関/コンテキスト化**：シグナルは相互に接続され、それらを理解するために必要な知識で充実しています。 4. **最新**：データは必要な時に、最近のタイムフレームと過去のタイムフレームの両方で利用可能です。 5. **調査可能**：プラットフォームはデータを有用な回答に変えることができ、単に生のデータを返すだけではありません。 6. **説明責任**：AIの推論とアクションは、事後に理解、管理、追跡できます。 運用テレメトリは静止していないため、課題は増幅されます。メトリクス、イベント、ログ、トレース（MELTデータと呼ばれることもあります）は、AIエージェントが後で読む可能性があることを知らないシステムによって継続的に生成され、機械消費用に設計されていない量と形式です。そして、このデータを読むAIはますます、チャットボット用の事実を取得しているのではなく、ライブインシデントを診断し、アクティブな脅威を調査し、増加する数の展開では、実際の結果を伴うアクションを取っています。 実際には、各機能がどのように見えるかを示します。 ## 統一：すべてを支配する1つのプレーン 最初の要件は最も基本的であり、最も一般的に失敗するものです。ログ、メトリクス、トレース、セキュリティイベントは、誰かまたはエージェントが手動でクロスリファレンスする必要がある4つの別々のツールではなく、単一のクエリ可能なプレーンに存在する必要があります。フェデレーション検索、堅牢なAPI、MCPが有効なワークフローの進歩があっても、重要なデータを異なる形式の複数のサイロに分散させたままにすることは、理想的な最終状態ではありません。エージェントが問題を解決するために必要だと思うデータの断片を組み立てることを信頼する必要がある場合、それが間違っている可能性はなくなりません。ただ、それを見つけるのが難しくなるだけです。 インシデント中の中規模フィンテック企業のオンコール エンジニアを想像してください。エラー率メトリクスは1つのダッシュボードにあり、ログは2番目のツールにあり、トレースデータは3番目にあり、セキュリティイベントは完全に4番目のシステムにあります。このシナリオでは誰も責任がありません。各ツールは、その仕事に完璧に適しているかもしれません。しかし、インシデント中、エンジニアの仕事は調査ではなく、タブの切り替えと精神的な翻訳になります。 同じ断片化に直面するAIエージェントは、そのエンジニアより魔法のようにスマートになることはありません。アクセスできないシステムに存在する画像の部分を見ることができないため、単により速く失敗するだけです。 [Open Cybersecurity Schema Framework](https://ocsf.io/)と[AWS Security Lake](https://aws.amazon.com/security-lake/)のようなサービスは、業界がセキュリティと運用データが数十のベンダーに分散していることが管理不可能になっていることを認識したために存在します。現在、Security Lakeだけで50以上のベンダーが統合されており、それぞれが調整が必要なもう1つの形式を提供しています。統一する本能は、Sumo Logicの意見ではなく、業界全体で今や一般的です。機械速度と機械規模で動作する時代には、これは交渉の余地がありません。 統一は、すべてに対して1つのベンダーを意味するのではなく、「何が起きたのか？」という質問を一度にすべてに対して尋ねることができる1つの場所を意味します。そして、その統一されたデータレイクが統一されたエンティティモデルと統一された制度的記憶も持っている場合、エージェントはデータを持つだけではなく、責任を持って推論するために必要なコンテキストを持っています。 ## 正規化：手動ではなく自動的に適用される構造 上記でこれに触れましたが、それ自体の柱に値します。すべてを1つの場所に入れることは、問題の半分を解決します。もう半分は、生のテレメトリが一貫性のない形式の混乱であるということです。 すべてのアプリケーション、すべてのチーム、インフラストラクチャのすべての時代は、強制されたスキーマなしで、わずかに異なる方法でログを書き込みます。この問題は新しいものではありません。有名な[XKCDコミック](https://xkcd.com/927/)が捉えたように、競合する標準があることに誰かが気付くたびに、彼らはもう1つの標準を追加するという素晴らしいアイデアを得ます。楽観的には、OCSFとECSと広範な業界の支持により、正規化の戦いに最終的に勝つかもしれません…そして戦争にも。 厳密に言えば、パイプラインには3つの異なるステップがあります。正規化とは、取り込み時に構造が自動的に適用されることを意味します。解析からフィールド抽出、スキーママッピングまで、新しいデータソースが現れるたびにカスタム統合プロジェクトを必要とするのではなく、自動的に処理されます。やや直感に反しますが、これは人間よりもAIにとってはるかに重要です。人間は少し形式が崩れたログ行を見て、その意味を推測することができます。同じデータに対して推論を行うモデルは、確実に推論するために一貫した構造が必要です。そうでなければ、ノイズに対するパターンマッチングになってしまいます。推論を進めることができたとしても、そこに到達するまでに不要なトークン消費が発生します。 正規化はデータ衛生プロジェクトではありません。データをクリーニングすることは、ドキュメントのタイプミスを校正することです。解析と正規化は、5つの異なる言語で書かれたドキュメントを1つの共有言語に翻訳することです。フィールド名がソース間で異なる場合、AIエージェントはアクターとターゲットを確実に区別する方法がありません。 あるファイアウォールログは送信元と宛先のIPを異なるフィールドに格納し、ラベルが付いていないこともあります。クラウド監査ログでは、アクションを実行した人物をuserIdentity.arnと呼びます。エンドポイントログではTargetUserNameと呼びます。正規化されたスキーマがなければ、横展開アラートを調査するエージェントは、攻撃者と被害者を入れ替えたり、間違ったユーザーを間違ったアセットと相関させたり、宛先を侵害の発信元としてフラグを立てたりする可能性があります。 ここでの主な懸念は、それが間違いを修正しないということです。完全な確信を持ってそれを提示し、アナリストはそれに基づいて行動します。これを「誰が何を誰にしたのか」が異なる方法で表現されるすべてのログソースに対して乗算すると、AIが調査を加速させていないプラットフォームが得られます。それは、機械速度で、もっともらしく、よくフォーマットされた間違った答えを製造しているのです。正規化とは、すべてのソースがエージェントに触れられる前に1つのスキーマにマップされることを意味します。そのため、「src」は常にソースを意味し、「dst」は常に宛先を意味し、アクターは常にアクションを開始したエンティティを意味します。どのベンダーのログであるかに関わらず。 ## 相関とコンテキスト化：タイプとシステム全体でリンクされたシグナル 統一され正規化されたデータを持つことで、AIエージェントはそれらのピースにアクセスできます。次の課題は、それらのピースがどのように組み合わさるかを理解するのを支援することです。これには相関とコンテキストの両方が必要です。 **相関**は、テレメトリ全体で因果関係を共有するシグナルを接続します。トレースIDは、それが生成したログ行にリンクし、それらが説明するメトリック異常にリンクします。調査者（人間またはAI）は、手作業で組み立てるのではなく、症状から根本原因までのチェーンをたどることができます。相関は「何が起きたのか、そしてそれの原因は何か？」という質問に答えます。必要なすべてのものはすでにデータストリームのどこかに存在します。問題は、ピースを見つけてリンクすることです。 **コンテキスト**は、データストリームにまったく存在しない知識です。それは、このサーバーがCFOのラップトップであるという事実です。IPレンジが先週金曜日にオフボードされた契約業者に属しているという事実です。サービスが移行の途中であり、チームは木曜日までエラー率の上昇を予想しているという事実です。アラートパターンが前四半期に2回調査され、両方とも既知の誤検知として終了したという事実です。 昔の世界では、この知識はアナリストの頭の中、Slackスレッド、誰も更新しないwikiページ、または同時にコーヒーを飲んでいた2人のエンジニア間の廊下での会話に存在していました。それは実在し、重要でしたが、建物内のあらゆる自動化システムに対して完全に見えませんでした。 この区別は、トレーススパンをそれを引き起こしたログエラーまでたどることができるAIエージェントが、影響を受けるサービスが計画されたメンテナンスウィンドウ内にあることを知らない場合、調査を解決していないため、認識する価値があります。それは技術的に正確で、運用上は無用なアラートを生成しています。エージェントは両方が必要です。つまり、プラットフォームは両方を表示する必要があります。テレメトリ全体の相関のための因果リンクと、アセット所有権、ビジネス重要度、変更スケジュール、過去の調査結果、脅威インテリジェンスエンリッチメントなどの組織知識。エージェントがクエリできる構造にエンコードされ、誰かの機関記憶に閉じ込められていません。 ## 現在：以前に起きたことではなく、今起きていることを反映 このシナリオを想像してください。脅威ハンティング後に重大なセキュリティ問題を特定しました。関連する主要なエンティティの1つは、過去6か月間、あなたの環境で見られています。6か月間そこにあったのであれば、さらに前はどうでしょうか？残念ながら、積極的に支払っている保持期間は6か月だけです。それより古いものは凍結された状態、アーカイブ、またはより冷たいデータ層に固定されています。 検索を開始する前に、このデータを再度ハイドレートする必要がありますが、処理する必要があるボリュームが多いため、時間がかかります。M.E.L.T.氷河を溶かすまでに時間がかかるため、分析を実行できないため、手が縛られています。インシデントは現在、人間が追うことができるより速く展開します。それらを説明するデータは、解凍を待つ冷蔵庫に座っていることはできません。なぜなら、M.E.L.T.氷河を溶かすまでに、攻撃者は移動しているからです。 レイテンシは通常、リアルタイムの問題としてフレーム化されます。新しいイベントが発生した後、どのくらい速くクエリ可能になるかです。しかし、レイテンシには2つのタイプがあります。 - **取り込みレイテンシ**：新しいデータがどのくらい速く利用可能になるか。 - **履歴クエリレイテンシ**：すでに存在するデータをどのくらい速く検索できるか。 侵害されたサービスアカウントを調査するエージェントは、最後の1時間の認証ログだけが必要ではありません。このアカウントが過去1年間で同様の動作を示しているかどうかを確立する必要があります。同じIPが6か月前に異なるコンテキストで現れたかどうか、およびエンティティのアクセスパターンが徐々にドリフトしたのか、それとも一夜にして変わったのかを確認する必要があります。これらの質問に答えるために長い再ハイドレーションジョブが必要な場合、エージェントの調査は、履歴コンテキストが転換点になったであろう正確なポイントで停止します。 AIエージェントが調査タイムラインを構築する場合、リアルタイム取り込みレイテンシと履歴クエリレイテンシの両方が同等に重要です。 合理的な範囲内で、データはいつでもアクセス可能である必要があります。すべてのテレメトリとソースの集約ビューを、任意の時間枠で持つことは、今日の環境でより多くのアクティビティを生成しているエージェント、人間、マシン間の行動パターンを理解するために不可欠です。これは、クラウドネイティブなセキュリティとオブザーバビリティデータレイクの概念が、エグゼクティブチームと運用チームの両方に共鳴している場所です。 AIエージェントが氷山の一角だけでなく、すべてのデータに基づいて推奨事項を行うようにしたいのです。より完全なデータ、より正確な答え、より迅速な修復。 ## 調査可能：データを保存するだけでなく、答えを生成するために構築 最初の4つの柱は、データのプロパティを説明しています。統一、正規化、相関、現在。プラットフォームについて何も知らなくても、データを見ることで各柱を検証できます。 調査可能性は異なります。それは、誰かまたは何かがデータを使用しようとするときに何が起こるかについてです。柱1～4を完璧にすれば、調査可能性は単なる自然な結果だと主張することもできます。絶対にそうではありません。完全に統一、正規化、相関、リアルタイムのデータセットを、45秒で結果を返すクエリエンジン、10,000個のランク付けされていない結果を返す、エンティティによるスコーピングの概念がない、最初の答えに基づいて後続の質問をする方法を提供しないクエリエンジンの背後に置くことができます。 データは完璧です。調査体験は無用です。美しくアーキテクチャされたデータウェアハウスと恐ろしいBIツールを使用したことがある人は誰でも、この正確な問題を経験しています。 柱1～4をレシピ、柱5をオーブンと考えてください。悪いオーブンは完璧なレシピを毎回台無しにしてしまい、材料の質がいくら良くても補うことはできません。成熟した顧客にとって、オーブンはしばしばAIエージェントのデプロイメントが実際に失敗する場所です。モデルは推論できます。データはあります。しかし、プラットフォームやAIハーネスが、調査に必要な時間内にエージェントが有用な処理を行うために十分な速度で、十分に厳密なスコープで、十分なコンテキストを付与して、適切なデータスライスを提供することができません。 プラットフォームレベルでは、調査可能性には以下が必要です： - 結果セットではなくタイムラインを返すエンティティスコープのクエリ。 - すべての回答に事前相関されたコンテキストが付与されているため、エージェントが見ているものを理解するために2回目のラウンドトリップが不要です。 - 最初の結果が最も可能性の高い答えであり、単に最新のマッチではないようにランク付けされた関連性。 - 人間の読み込みスピナーへの忍耐ではなく、エージェントの推論ループ内に収まる応答時間。 データをよく保存するプラットフォームと調査可能なプラットフォームの違いは、図書館と研究アシスタントの違いのようなものです。どちらも同じ本にアクセスできます。一方は開いたページをあなたに手渡します。 ## 説明責任と推論 最後の柱は、AIエージェントがアクションを提案することから実行することへ移行する瞬間に重要になります。または運用モデルの言語で言えば、すべてのステップで人間が関与する状態から、人間がループの外側にいる状態へ、そして最終的には人間が完全に外れた状態へ移行する時点です。 推奨エンジンは大きな結果を伴わずに間違うことができます。本番環境へのアクセス権を持ち、自律的に動作するエージェントは別の問題です。その推論とアクションは、コンプライアンスの事後対応ではなく、運用上の要件として、事後に再構築可能である必要があります。 これはまさに業界の注目が集まっている場所です。エンタープライズテクノロジーリーダーシップを研究するアナリストは、「[AIの実現と保護](https://www.evanta.com/resources/ciso/survey-report/top-3-priorities-for-cisos-in-2026)」を今年のセキュリティリーダーの最優先事項として特定しており、エージェント型リスクの存在を単に主張するのではなく、それに対する制御を証明することに重点を置いています。[エンジニアリングリーダーシップに関する別の調査](https://www.mintmcp.com/blog/ai-agent-security-statistics)では、テクノロジーリーダーの大多数がすでにAIエージェントを、付与されるアクセスの広さに対して適用される監視の不足が原因で、セキュリティリスクの増加と見なしていることがわかっています。最近の[Hugging Face](https://www.securityweek.com/what-the-hugging-face-incident-teaches-security-leaders-about-ai-agent-access/)インシデントはこの例です。一部のアナリストは、10年の終わりまでに、エンタープライズセキュリティインシデントの相応の割合が、従来の攻撃ベクトルではなく、[AIエージェントの悪用](http://www.sumologic.com/ja/resources/agent-kill-chain-framework)に遡ることになると予測しています。 説明責任はまた、エージェントが行うすべてのことによって残される痕跡を意味します。慣例ではなくプラットフォームレベルで管理されるアクセス。エージェントが何を見たか、何を決定したか、何をしたかの耐久性のある、クエリ可能な記録であり、アクション自体とは別のものなので、6か月後に「なぜこれが起きたのか？」という質問に実際の答えがあります。そして重要なことに、それはフィードバックループを意味します。間違いが一度起きたら、それはAIのせいです。同じ間違いが2回起きたのに、誰もモデルを再トレーニングしたり、プロンプトを改善したりしなかったら、それは私たちのせいです。説明責任は単なる監査証跡ではありません。それは証跡が読まれ、対応されることを確認するシステムです。 ## 基準を実際に満たすことがどのように見えるか このフレームワークは、[Sumo Logic Platform](http://www.sumologic.com/ja/platform)が設計されている内容を説明しており、私たちは自分たち自身が最初の顧客です。当社の[SOCは当社のエージェントを使用してアプリとインフラストラクチャを保護しています](http://www.sumologic.com/ja/blog/building-ai-first-soc-customer-zero)。[Mobot](http://www.sumologic.com/ja/blog/mobot-your-log-analysis-partner)、[SOC Analyst Agent](http://www.sumologic.com/blog/soc-analyst-agent-for-soc-team)、およびより広いエージェントチームアーキテクチャは、これら6つの柱に依存しています。これらなしでは機能しません。どのエージェントも機能しません。 [Mobot](http://www.sumologic.com/ja/demo/mobot-walkthrough)が単一の会話フロー内でログ、メトリクス、トレースを調査する能力は、基盤となるプラットフォームがそれらを3つの別々の製品を事後に接着したものではなく、1つの統一された正規化されたサーフェスとして扱うためにのみ機能します。メトリクスの異常から、それを説明する特定のログ行とトレーススパンへ移動する場合、それは相関が機能しています。影響を受けるサービスが特定のチームによって所有されており、2時間前にデプロイされたことを知っている場合、それはコンテキストが機能しています。 そしてSOC Analyst Agentが検出結果の表示から対応へ移行するにつれて、説明責任は抽象的な原則ではなく、その自律性がセキュリティチーム、監査役、または取締役会の前で実際に防御可能であるかどうかを決定するものになります。 AIの状況は変わり続けるでしょう。モデルはより速く、より安く、より能力的になるでしょう。エージェントは増殖するでしょう。それらを構築するベンダーは来ては去るでしょう。 しかし、生き残るプラットフォームは、データを正しく処理したプラットフォームです。なぜなら、データはそれで訓練されたすべてのモデル、それについて推論するすべてのエージェント、そしてそれをより賢くしたと主張するすべてのベンダーより長く存在するからです。6つの柱は競合他社に対する堀ではありません。それらはその上に構築されたすべてのものを信頼できるものにする基盤です。そしてAIを使用したセキュリティ運用では、信頼が現在の戦場です。 Sumo Logicがこれを実際に行う方法を確認してください。[デモをリクエストしましょう](http://www.sumologic.com/ja/request-demo)。 ### FAQs Mobotとは？+Mobotは、Sumo Logic DojoAIの統合会話インターフェースであり、ユーザーを専門的なエージェントに接続し、自然言語のリクエストを素早く直感的に実用的なインサイトに変換します。 非構造化ログの分析にMobotを使用できますか？+はい。Mobotはクエリ エージェントを活用して、非構造化ログから重要な情報を検索・抽出し、調査中に重要な分析情報を見逃さないようにします。 Sumo Logic DojoAIとは？+Sumo Logic DojoAIは、インテリジェントなセキュリティ運用とインシデント対応を実現するために構築されたマルチエージェントAIプラットフォームです。進化する脅威に継続的に適応しながら、自律的に対応するように設計されています。 DojoAIにはヒューマン・イン・ザ・ループがありますか？+はい。DojoAIはアナリストが日常的なタスクと推奨事項をサポートしますが、人間がレビュー、検証、およびアクションをガイドして、精度、コンプライアンス、および信頼を確保します。 ### 記事タグ - [SecOps とセキュリティ](https://www.sumologic.com/ja/blog/secops-security) - [AI](https://www.sumologic.com/ja/blog/ai) Chas Clawson Field CTO, Security As a technologist interested in disruptive cloud technologies, Chas joined Sumo Logic’s Cyber Security team with over 15 years in the field, consulting with many federal agencies on how to secure modern workloads. In the federal space, he spent time as an architect designing the Department of Commerce ESOC SIEM solution. He also worked at the NSA as a civilian conducting Red Team assessments and within the office of compliance and policy. Commercially, he has worked with MSSP practices and security consulting services for various fortune 500 companies. Chas also enjoys teaching Networking & Cyber Security courses as a Professor at the University of Maryland Global College. Bogdan Kireeve Solutions Engineer Bogdan has been a Solutions Engineer at Sumo Logic for three and a half years, helping security and observability teams centralise their operations in one platform to help improve operational efficiency, security posture and manage the new agentic landscape. With a background spanning cyber security as well as application development and cloud and on-premises architecture, he spends a lot of time talking to businesses about the most important factor underpinning all of modern operations today – data, and why it’s important to have a rock solid data foundation for DevSecOps. [](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Fwww.sumologic.com%2Fja%2Fblog%2Fsix-pillars-ai-ready-telemetry "Share on Facebook")[](https://twitter.com/intent/tweet?text=AI%E5%AF%BE%E5%BF%9C%E3%83%86%E3%83%AC%E3%83%A1%E3%83%88%E3%83%AA%E3%81%AE6%E3%81%A4%E3%81%AE%E6%9F%B1&url=https%3A%2F%2Fwww.sumologic.com%2Fja%2Fblog%2Fsix-pillars-ai-ready-telemetry "Share on X")[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.sumologic.com%2Fja%2Fblog%2Fsix-pillars-ai-ready-telemetry "Share on LinkedIn")[](https://api.whatsapp.com/send?text=AI%E5%AF%BE%E5%BF%9C%E3%83%86%E3%83%AC%E3%83%A1%E3%83%88%E3%83%AA%E3%81%AE6%E3%81%A4%E3%81%AE%E6%9F%B1%20https%3A%2F%2Fwww.sumologic.com%2Fja%2Fblog%2Fsix-pillars-ai-ready-telemetry "Share on WhatsApp")[](https://www.sumologic.com/feed?post_type=blog "RSS Feed") [前のブログ Mobotがレベルアップ：自然言語でインシデント対応プレイブックを構築](https://www.sumologic.com/ja/blog/mobot-incident-response-playbooks)[次のブログ SOC Analyst Agentが調査時間を4時間から14分に短縮する方法](https://www.sumologic.com/ja/blog/soc-analyst-agent-cuts-investigation-time) この記事を読まれた方は、こちらもご覧になっています [ Sumo LogicでPHP2Shell関連のアクティビティを調査する方法 October 23, 2026 ](https://www.sumologic.com/ja/blog/investigate-php2shell-activity)[ Root Cause Agent：オブザーバビリティへのエージェント型アプローチ October 13, 2026 ](https://www.sumologic.com/ja/blog/root-cause-agent-agentic-approach-to-observability)[ DojoAI クレジットのご紹介：スケーラビリティを実現する柔軟で予測可能なAI料金体系 October 13, 2026 ](https://www.sumologic.com/ja/blog/dojoai-credits-flexible-ai-pricing)[ SaaS セキュリティのための CASB 対 SIEM September 30, 2026 ](https://www.sumologic.com/ja/blog/casb-vs-siem-saas-security) [AI Instructions](https://www.sumologic.com/ai-instructions.md)