AIチケット分析

解決済みのITSMチケットには、長年にわたり実証されてきたトラブルシューティングロジックが蓄積されています。クローズされたインシデントはすべて、チームがどのように実際の問題を診断し、解決したかの記録です。AIチケット分析は、こうした組織的な知識をエージェントが繰り返し利用できる情報へと変換します。

生のチケットデータをインポートして分類し、エージェントがすぐに使える知識に変換する。

ITSMシステムからCSVエクスポートをインポートすると、LLMはチケットフィールドを分析し、インシデントをタイプ別に分類し、カテゴリごとに2つの出力を生成します。1つは、チームがそのクラスの問題を解決するために使用したトラブルシューティング手順をまとめたナレッジドキュメント、もう1つは、エージェントが同じパターンに遭遇したときに自動的に呼び出すことができるAIプロンプトです。

レビュー、改良、公開

公開前に必ず検証を行います。チケットの種類は元のチケットと並べて表示されるため、分類を確認できます。最初の試行で修正が必要な場合は、プロンプトを再生成してください。準備ができたら、プロンプトを公開します。

あなたの病歴に基づいた診断

それ以降、AI Insightは既知のインシデントタイプに遭遇した場合、汎用的なトレーニングデータではなく、チームが検証済みの解決履歴に基づいて推論を行います。チケット履歴を多く入力するほど、エージェントはネットワークが実際に抱えている問題と、その環境で既に効果があった解決策をより具体的に理解できるようになります。

トリガーオートメーションフレームワーク（TAF）

トラブルシューティングワークフローのイベント駆動型レイヤーで、人間の介入なしに診断を実行します。TAFは、外部システムからの自動信号と、システムを開く必要のないエンジニアからのセルフサービスリクエストという2つの方向からインシデントを受け入れます。 NetBrain.

自動トリガー ServiceNow、Splunk、BMC Remedy、またはAPI呼び出しが可能なあらゆるITシステム。チケットが発行されるかアラートが発生すると、TAFはペイロードを受信し、適切な診断構成と照合して実行します。人間がディスパッチする必要はありません。

セルフサービストリガー — Microsoft Teams ボット、メール、ServiceNow アプリ、または Incident Portalエンジニアが既に参加しているチャネルで問題を説明すると、TAFがそれを検知して診断を実行します。その結果は、エンジニアがワークフローを中断することなく返されます。

どちらの経路でも、TAF は受信したインシデントを事前定義された基準と照合し、適切な Network Intent または ADT と連携し、診断を実行します。結果は、インシデント ペイン、発信元のアプリ (ServiceNow、Teams、メール)、およびダッシュボードに表示されます。

エンジニアは結果を見るのであって、派遣の過程を見るのではない。

AIパス

AIパス

必要に応じて経路を検証し、各ホップの動作を分かりやすい言葉で説明します。経路エンジンが見落とした箇所を検出する機能と、検出された箇所を説明する機能という、2つの補完的な機能を備えています。

AIパスドクター

パスの精度は、ネットワーク運用において常に潜在的なリスク要因となってきました。パスが履歴から変更されると（ホップ数、非標準設計、ルーティングテーブルなど）、それに基づいて構築されたあらゆる診断や自動化ツールがそのエラーを引き継いでしまいます。AI Path Doctorは、この基盤を改善します。

このツールは、ライブネットワークデータを使用してエンドツーエンドのパス全体を独立して計算し、それをマップ上のNB-Pathと並べて表示します。これにより、インシデント発生後のレビュー時ではなく、マップ上で明らかになった時点で、デバイスの欠落、ホップの誤り、転送ロジックのギャップなどを検証できます。  

計算は設計上、透明性が確保されています。AIパスの詳細パネルには、AIエンジンに送信されたプロンプト、ホップごとに実行されたロジック、構造化された概要（使用された送信元ゲートウェイ、ネクストホップ選択ポリシー、L2セグメント解決が適用されたかどうか、およびその理由）など、推論チェーン全体が表示されます。各ホップについて、入力インターフェース、出力インターフェース、アクティブなネクストホップIP、L2隣接MAC、ルーティングテーブル検索、CEF決定、およびポリシーチェックが示されます。ブラックボックスではなく、監査証跡です。

何かがおかしいとき、そして NetBrain エンジニアリング関連、お問い合わせ NetBrain NB-Pathデータ、AI-Pathデータ、マップトポロジー、計算中に使用されたCLIコマンド出力、および完全なAI推論ログなど、すべてをワンステップで収集します。手動での組み立ては不要です。ワンクリックで完全なパッケージが手に入ります。

ディープ診断のユースケースにおいても、この点が重要となる理由は同じです。エージェントはパスに依存しており、不正確なパスは不正確な診断結果を生み出します。AI Path Doctorは、自動化を実行する前に、正解データを検証します。

AIパスサミネーション

経験豊富なエンジニアは、パスの結果を読み取れば、それが何を意味するのか、つまりどのルーティング決定が重要だったのか、ポリシーがどこに適用されたのか、CEFエントリが何を示しているのかを即座に理解できます。しかし、それ以外の人は同じ出力を見ても、何が起こったのかを理解するのに20分も費やします。

AIパスサマリー機能は、このギャップを埋めます。パス計算結果全体を読み取り、ホップごとに整理された構造化された平易な言葉による説明を生成します。この機能は、パス詳細ペインの新しい「パスサマリー」タブに表示されます。パス上の任意のデバイスを選択すると、そのホップに関するAI生成のサマリーが表示されます。

各サマリーセクションは、パスエンジンが使用した推論ロジック、取得したデータソース、そのステップで観測された内容、そして到達した結論という同じ構成になっています。パス計算中に検出されたエラーもここに表示されます。何も抽象化されておらず、サマリーには構成の詳細、NCTテーブル、CLI出力などの基となるデータへの直接リンクが含まれているため、エンジニアは生のログを探し回る必要なく、ワンクリックで検証できます。

要約処理は段階的に実行されます。結果はデバイスごとに計算され次第表示されるため、残りの処理が完了するまでの間も結果を閲覧できます。要約はパスインスタンスとともに自動的に保存されるため、後でパスを再度開くと既に保存されており、再実行は不要です。要約処理の途中で新しいパスの計算が開始された場合、処理は正常に停止し、結果が保存されます。

複数のパスタイプ（L2、L3）とデバイス間の依存関係が存在する複雑な環境の場合、概要では各タイプを折りたたみ可能なセクションとして扱い、エンジニアが必要とする任意の深さで読み取れるようにします。

その結果、パスクエリは誰が実行したかに関わらず、すべて上級エンジニアによるデータ解釈を返すようになった。