NW運用自己進化型FAQ AI 構築実録：SharePointエージェントと構造化HTMLの格闘

ネットワーク運用の「現場の知恵」をAIにどう喰わせるか

これまで社内に散らばっていた対応メモ、同僚たちの断片的なチャット履歴、Excelに埋もれた障害対応記録。これらを活用するため、「NW運用自己進化型FAQ AI」 の構築に挑んだ。

単にAIを導入するだけなら簡単だが、ネットワークインフラという「機密情報の塊」を扱う以上、DLP（データ損失防止）の制約を守りながらAIの回答精度を高める必要があった。試行錯誤の末にたどり着いた「構造化HTML」という答えと、実際に構築してみた過程を記録する。

直面した課題：DLPの壁と「情報の曖昧さ」

最初にぶつかったのは、企業としての「セキュリティ境界」だ。NW構成情報やコマンドの生ログを、外部のパブリックなAIへ転送することは許可されていない。そのため、Microsoft 365 のセキュアなテナント内 で完結するRAG（検索拡張生成）システムを基盤に選んだ。具体的には SharePoint Online + Copilot Studio（旧Power Virtual Agents）の組み合わせだ。

次にハマったのは、AIの「回答のブレ」問題だ。プレーンテキストのままだと、AIは情報の重要度を判断できず、機器コマンドの一部を省略したり手順を間違えて提示したりすることがあった。これを解決するために採用したのが、セマンティックなHTMLへの構造化だ。

graph TD
    A[Teamsでの対応完了/自動要約] -->|Power Automate| B{構造化変換エンジン}
    B -->|h1, h2, preタグ付与| C[**AI最適化HTML文書**]
    C -->|SharePoint経由| D[社内AIエージェント]
    D -->|根拠ある高精度回答| E[現場の対応が爆速化]
    E -->|新たな知見をフィードバック| A
    style C fill:#dff,stroke:#0078d4,stroke-width:2px

🗜️ スペック：構築に使用した技術スタックとKPI

実録：私が踏んだ「高精度化」の4つのステップ

ゼロから構築・検証を繰り返した際の手順を記録する。

ステップ1: AIによる「一次フィルタリング」の自動化

Teamsに投稿された対応内容をAIに命じ、以下の5項目へ厳密に分解・要約するプロンプトを運用した:

1. タイトル（機器名_事象_日付）
2. 事象（何が起きたか）
3. 原因（なぜ起きたか）
4. 解決コマンド（実行したコマンドを一字一句）
5. 注意点（次回やる人が気をつけること）

最初はプロンプトが甘くて「原因」と「解決コマンド」が混在した要約が生成されてしまい、ここを何度も修正した。要約の質が後の回答精度に直結するため、プロンプトの作り込みは最初にしっかりやった方が良い。

ステップ2: HTMLタグでの「情報のカプセル化」

抽出された要素を Power Automate で HTML にパッケージングする。構造の例:

<h1>Cisco 9300 - STP ループ発生による L2 通信断（2025-03-15）</h1>
<h2>事象</h2>
<p>フロアスイッチ間でブロードキャストストームが発生。L2通信が全断した。</p>

<h2>原因</h2>
<p>ポートチャネル設定ミスによりSTPトポロジが不正な状態になった。</p>

<h2>解決コマンド</h2>
<pre><code>
SW01# show spanning-tree vlan 10
SW01# debug spanning-tree events
SW01(config)# interface port-channel 1
SW01(config-if)# shutdown
SW01(config-if)# spanning-tree portfast trunk
SW01(config-if)# no shutdown
</code></pre>

<h2>注意点</h2>
<p>portfast trunkはアクセスポートには使用しない。トランクポート専用の設定。</p>

特に苦労したのが <pre><code> タグの扱いだ。AIがコマンドを「意味のある文章」として理解しようとして、独自解釈で書き換えてしまう問題があった。<pre><code> タグで囲むことで「この中は変えるな」という強い制約を持たせられる。インデントのズレが実際の機器コマンドでエラーを引き起こす可能性があるため、インデント保持ロジックを Power Automate 側に組み込んだ。

ステップ3: メタデータによる「重み付け」の調整

SharePointに保存する際、以下のルールを設けた:

ファイル名: {機器名}_{事象カテゴリ}_{YYYYMMDD}.html
例: Cisco9300_STPLoop_20250315.html
    Juniper_BGP_RouteFlap_20250401.html

HTML内にも作成日時と対応者情報を埋め込んだ。これでAIエージェントが「類似事象の中でも新しい情報を優先して検索・回答」するようにチューニングされた。旧い対応手順より新しい対応手順が優先されるのは、インフラ運用では特に重要だ（コマンド体系がバージョンで変わるため）。

ステップ4: 「即時アップデート」体制の確立

AIが間違った答えを出した場合、そのソースとなったHTMLファイルを直接修正する運用を徹底した。「AIが間違えた → ソースファイルを直す → 5分後には正しい回答を出す」というループが現場に定着することで、AI自体が日々賢くなっていく。

最初は「AIが間違えるなら使えない」という声もあったが、「間違えたらファイルを直すだけ」というシンプルさが受け入れられ、今では現場が自主的にHTMLを更新してくれるようになった。

実際にやってみてよかったこと・ハマったこと

よかったこと:

• 深夜の障害対応で「このアラートのコマンドは？」と聞いたら、過去の事例に基づいた正確なコマンドが返ってきた。以前は先輩に電話していたところが自己解決できるようになった
• 新人が同じ質問を繰り返さなくなった。対応コストが体感で半分以下になった
• 「AI回答の根拠となったドキュメント」がSharePointリンクとして回答に含まれるため、答えが信頼できるかどうかを確認できる

ハマったこと:

• Power Automate の文字列処理でシングルクォート（'）がHTMLエンティティに変換されてしまい、コマンド内の文字列が壊れた。replace() 関数で ' → ' への変換処理を追加して解決した
• SharePoint のクローラー更新頻度はデフォルトで遅い（最大24時間）。検索インデックスの即時更新は管理センターから「再インデックス」ボタンを押す必要があった。Power Automateのフローの最後にSharePoint REST APIで再インデックス処理を呼ぶことで自動化した

# SharePoint 再インデックス API 呼び出し（Power Automate HTTP コネクタ）
POST https://{tenant}.sharepoint.com/sites/{site}/_api/site/RebuildIndexedPropertyBag
Authorization: Bearer {token}
Content-Type: application/json

補足：Markdown vs HTML、どちらを選ぶか

試してみた結果を整理するとこうなった:

M365環境でRAGを構築する場合はHTMLに軍配が上がる。SharePointのクローラーはHTMLのセマンティクスを理解してインデックスに反映するため、<h1> に書いたタイトルはプレーンテキストよりも検索ヒット率が高くなることを確認した。

よくある質問（FAQ）

Q: マークダウン（MD）じゃダメなんですか？

A: 実際に最初はMDで検証した。しかしM365（SharePoint）のクローラーとの相性を調べたところ、HTMLタグ（h1〜h6）の方が検索エンジンに対する重み付けが遥かに強く反映されることが分かった。特に <h1> のタイトルが検索クエリとマッチする確率はMDの見出しより高かった。RAG精度の改善を実測した結果、HTMLへの移行を決めた。

Q: コマンドの誤変換は本当に起きないですか？

A: <pre><code> タグによる保護と、AIプロンプトレベルでの「コードブロックの引用における非改変指示」を組み合わせることで、当方の環境ではコマンドの1字1句・インデントのズレによる実行エラーはほぼゼロになった。ただし完全にゼロではないため、クリティカルな変更コマンドは必ず人間がソースを確認する運用は維持している。

Q: 構築にはどのくらいの期間がかかりましたか？

A: 一人でプロトタイプを作るのに2週間、チームに展開してナレッジが回り始めるまで1ヶ月ほどだった。一度仕組みを作ってしまえば、現場が普通に仕事をするだけでAIが自動的に賢くなっていく。今では構築前には想定していなかった「過去障害の横断検索」「類似インシデントの自動推薦」まで動いていて、運用の自動化が少しずつ広がっている。

よくやらかす失敗パターンと対処法

実際に構築・運用の中でハマった失敗と、その対処法をまとめておく。

パターン1: Power Automateでシングルクォートがエスケープされてコマンドが壊れた

症状: <pre><code> ブロック内のCiscoコマンドが show spanning'tree のようにエンティティ変換されていた。機器にコピペしたらシンタックスエラーになった。

対処: Power Automateの「作成」アクションで文字列処理する際に replace(variables('html_body'), ''', '''')のような明示的な変換を追加する。シングルクォート以外にも、パイプ記号（|）や角括弧も事前にチェックしてエンティティ変換が起きないか確認するのが確実。

パターン2: SharePointのクローラー更新を待たずに「反映されない」と焦った

症状: HTMLファイルを更新したのにAIの回答が古いままで「システムが壊れた」と思い込んだ。確認するとSharePointのデフォルトクロール間隔が最大24時間だった。

対処: Power AutomateのフローにSharePoint REST APIの再インデックス呼び出し（POST /_api/site/RebuildIndexedPropertyBag）を組み込む。ファイル更新から5分以内に反映されるようになる。

パターン3: <h1> タグのタイトルが複数ファイルで重複していた

症状: AIが「同じ機器・同じ事象に複数の対応記録がある」と混乱して誤回答した。確認すると古いファイルと新しいファイルで同じ <h1> タイトルが使われていた。

対処: <h1> には必ず「機器名_事象_日付」の一意な文字列を入れる。タイトルの重複はRAG精度の大敵。ファイル名の命名規則と <h1> の内容を同期させると管理しやすくなる。

パターン4: AIの誤回答を「AIだから仕方ない」と放置した

症状: 同じ間違いをAIが繰り返すようになり、現場の信頼が急速に低下した。最初の導入フェーズで特にこれをやってしまった。

対処: 「AIが間違えた → ソースHTMLを直す → 5分後に正しい回答が出る」というループをチーム全員に体験させる。この文化が根付かないとシステムは死蔵化する。onboarding資料に「間違えたらHTMLを直す」のフローを最初から入れておくことが重要だった。

パターン5: インデントのズレで機器設定エラーが起きた

症状: AIの回答をコピペしてネットワーク機器に適用したら、インデントのズレが原因でシンタックスエラーになった。Cisco IOSのconfファイルはインデントに敏感だ。

対処: <pre><code> タグによる保護と、AIプロンプトに「コードブロック内のインデントを変更禁止」を明記する。クリティカルな変更コマンドは必ず人間が目視確認する運用は省略しない。特にinterface設定やポリシーマップなど、インデント構造があるコマンドは要注意。

補足：知っておくと助かるポイント

• ファイル命名規則の統一が精度を左右する: 機器名_事象カテゴリ_YYYYMMDD.html の規則が崩れると、AIが「新しい情報を優先して参照する」チューニングが崩れる。onboarding資料に命名規則を必ず明記し、チーム全員が同じルールを守れる状態にしておく。運用が長くなるほどここの統制が精度に効いてくる。

• Copilot Studioの検索スコープを絞るとコスト削減になる: AIエージェントが1回の回答生成で参照するHTMLファイルが多すぎるとトークンコストが増加する。SharePointライブラリを「現役記録（直近2年）」と「アーカイブ（それ以前）」に分けてスコープを絞ると、コスト抑制と精度向上が同時に達成できる。試してみたら月間トークン消費量が約30%削減できた。

• SharePointのバージョン管理を活用する: SharePoint Onlineはデフォルトでファイルのバージョン履歴を保持している。誤ってHTMLを書き換えてしまっても、バージョン履歴から元に戻せる。ただしバージョン保持数にデフォルト上限があるため、ライブラリ設定（「バージョン管理の設定」）で上限を増やしておくと安心。クリティカルな対応手順が含まれるファイルは特に確認しておくことを勧める。

自分が踏んだ落とし穴と回避策

書いている内容は、私が実際に踏んだトラブルとその回避策が中心です。対処手順だけ書いて終わるのではなく、『なぜ最初の選択肢を捨てたか』『どのログを見て判断したか』も残すようにしています。製品アップデートで前提が変わったときに、この記事を読み直して自分でも辿り直せる形にしておくのが目的です。