「みんなで育てる」と「情報の正確性」の両立 〜承認フローを組み込んだナレッジ・ガバナンス設計〜

ナレッジの自由化が生んだ「ハルシネーション」の壁

AI（RAG）を社内に導入した当初、私は「現場のエンジニアが誰でも自由にナレッジを投稿できる環境」こそが理想だと考えていました。しかし、すぐに大きな壁にぶつかりました。 担当者のうろ覚えの知識や、AIによる誤った要約がそのままデータソースとして公開されてしまい、結果としてAIが「自信満々に嘘を答える（ハルシネーション）」という、信頼性に関わる事態が頻発したのです。

この「情報の汚染」を防ぐため、私が自社環境で設計・実装した**「承認フローをコアに据えたナレッジ・ガバナンス」**の構成詳細を共有します。

信頼の境界線を引く：承認フローのアーキテクチャ

どれほどLLMの性能が向上しても、入力データそのものが間違っていれば意味がありません。 私が目指したのは、「現場の投稿スピードを落とさず、かつリーダーの検閲を確実に通す」という、相反する要件の両立です。システム的に「人間の介入（Human in the loop）」をどこに配置すべきか、試行錯誤の末に構築したフローがこちらです。

[私が実装した「ナレッジ検閲システム」の全貌]

graph TD
    A["現場が起票 / AIが下書き生成"] -->| "ステータス: 保留" | B("隔離フォルダへ格納")
    B -->| "リーダーへTeams通知" | C{ "内容をレビュー" }
    C -->| "修正が必要" | D["差し戻し・修正指示"]
    C -->| "内容OK" | E["承認フラグON"]
    E -->| "Power Automate発動" | F["**AI参照用フォルダへデプロイ**"]
    F --> G["全社AIエージェントが学習"]
    style B fill:#ffeab6,stroke:#ff9800
    style F fill:#dff,stroke:#0078d4,stroke-width:2px

🗜️ 実装で使用したパラメータとガバナンス設定

実装・検証から得られた「ガバナンス強化」の具体策

実際に仕組みを回す中で、特に効果が高かった実装のこだわりを紹介します。

1. Teams承認アプリとのAPI連携: リーダーがいちいちSharePointリストを見に行くのは現実的ではありません。私はPower Automateを使い、Teamsの「承認（Approvals）」アプリへ自動でリクエストが飛ぶようにしました。チャット上で内容を確認し、スマホから1タップで承認・即座にAIナレッジとして反映される仕組みが、運用の定着に不可欠でした。
2. E-E-A-T（権威性）の自動付与: AIが回答の引用元を選ぶ際、「公式な検証済み情報か」を判断できるよう、生成されるHTML内にメタデータとしてレビュー情報を埋め込んでいます。

   <meta name="reviewer" content="Network_Team_Leader" />
   <meta name="verification-date" content="2026-02-28" />
   

   これにより、回答の優先度が上がり、信頼性の低い情報をAIが拾いにくくなる効果を確認できました。

2026年3月に強く感じる「AIは賢くなったが、根拠管理はむしろ重くなった」現実

2026年3月の現場では、AI エージェントや RAG の精度そのものは明らかに上がっています。しかしその反面、「誰が確認したのか」「いつ時点の情報か」「この回答はどの承認済みソースに依存したのか」を説明できないと、社内展開が止まるケースが増えました。つまり今は、検索精度だけでなく説明責任のあるナレッジ流通が求められています。

そのため私が重要だと感じるのは、承認フローを重くすることではなく、承認理由と失効条件を機械可読に残すことです。レビュー担当者名、検証日、TTL、差し戻し理由まで記録できると、AI の回答品質だけでなく監査耐性も上がります。

私がよく受ける質問(FAQ)

Q: 全てのナレッジを人が確認するのは、運用が回らなくなるのでは？

A: 私もそこを懸念しましたが、実際には「正確でない情報が広まり、後で訂正に追われるコスト」の方が遥かに高いことを痛感しました。現在は、初期チェック（個人情報の有無や、コンプライアンス等）を別のAIモデルで行い、最終的な「技術的な正確性」だけを人間が確認する「AIアセッサ」形式を採用し、負荷を下げています。

Q: 古くなった情報はどのように扱っていますか？

A: 技術の移り変わりは早いため、私は「情報の賞味期限（TTL）」を厳格に設けています。古いファームウェア時代の解決策がAIによって回答されてしまうリスクを防ぐため、半年経ったナレッジは自動で警告を発報し、再承認されない限りAIの検索対象から外す自動化フローを組み込んでいます。

Q: 承認制にすると、メンバーが投稿を遠慮してしまいませんか？

A: むしろ逆の反応がありました。「自分が書いたものが間違っていてもリーダーがリカバーしてくれる」という安心感に繋がり、結果として投稿の心理的ハードルが下がり、質の高いナレッジが溜まるようになりました。重要なのは、承認（デプロイ）までのスピードをシステムで極限まで早めること（自動化）です。

Q: 承認済みでも間違っていた場合はどうしますか？

A: そのために TTL と差し戻し導線を残しています。2026年のAI運用では「一度承認したら終わり」ではなく、後から訂正しやすい仕組みの方が実際には重要です。

実際にやってみた結果のメモ

Power Automate で承認フローを構築したときの設定値と、ハマったポイントをそのまま残しておく。

Power Automate フロー構成（実録）

使ったコネクタは 3 つ: SharePoint（変更監視） + Teams Approvals（承認通知） + SharePoint（フィールド更新＋ファイルコピー）。

トリガー   : SharePoint「アイテムが作成または変更された」→ 隔離フォルダを監視
条件分岐   : 承認ステータス列 == "Pending" のみ通過
アクション : Teams「承認の開始と待機」→ 担当リーダーへ送信
承認後     : SharePoint「アイテムの更新」→ 承認ステータスを "Approved" に変更
デプロイ   : SharePoint「ファイルのコピー」→ AI参照フォルダへ移動

実測した数値:

• 投稿→承認リクエスト到達: 平均 3〜5秒（デフォルトは最大15分のポーリング遅延あり。プレミアムプランで1分以内に短縮）
• リーダーの承認操作: 1〜2分（Teams上で内容確認込み）
• 承認→デプロイ完了: 平均 10〜15秒

ハマったポイント1 – Teamsの承認アプリが届かなかった: Teams の承認アプリ（Approvals）がユーザー側でブロックされているケースがあった。IT管理センターの「Teams アプリ → 管理」で「Approvals」アプリが許可リストに入っていないと、承認リクエストがサイレントに消える。Teams 管理者に許可設定の確認を依頼するまで、しばらく原因が分からなかった。

ハマったポイント2 – ポーリング遅延問題: SharePoint トリガーのデフォルトポーリング間隔は最大 15分。投稿してすぐ承認フローが動いてほしいなら、プレミアムプランへの切り替えか、変更通知 Webhook の利用が必要になる。

TTL チェックの実装式（Power Automate）

「スケジュールされたフロー」で毎日 AM3:00 に実行。SharePoint リストで 公開日 フィールドが現在日時から 180 日以上前のアイテムを検索するフィルター式:

@less(item()?['公開日'], addDays(utcNow(), -180))

この条件に合致したアイテムの 承認ステータス を "Review_Required" に変更し、投稿者と監視チャンネルに Teams 通知を送る。確認してみたら、180 日以内でも技術バージョンが変わっているケースが多く、実運用では 90 日 に短縮したほうが効果的だった。

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

実際に運用してやってしまったミスを記録しておく。同じ轍を踏まないよう。

ミス1: 隔離フォルダにインデックス除外設定を忘れた

最初の構成で一番痛かった失敗。SharePoint の「隔離フォルダ」に AI クローラーの対象から外す設定を入れ忘れ、審査前の未承認ナレッジが検索に引っかかっていた。SharePoint 管理センター → 対象サイトの「検索とオフライン可用性」→「このコンテンツのインデックス作成を許可する」を オフ にすることで解消。この設定を忘れると承認フロー自体が無意味になるので最初に必ず確認する。

ミス2: TTL による非公開をユーザーに通知しなかった

TTL 自動非公開が走ったとき、投稿者へ何の通知もいかない設定になっていた。AI が「回答が見つかりません」と返すのに、ナレッジ自体は存在する、という混乱が発生。Power Automate の非公開処理と同時に「○○ナレッジが 180 日で非公開になりました。再レビューが必要です」と Teams チャンネルへ投稿するステップを追加して解消した。

ミス3: 承認者を 1 名だけに設定してリーダー不在でボトルネック化

承認者を 1 名にした結果、その人が休暇中は全投稿が止まる事態になった。Power Automate の Teams 承認アクションで、割り当て先を「先着順（いずれかが応答すれば通過）」モードに変更し、承認者を 2 名に設定して解消。承認アクションの「応答のオプション」を「承認/拒否」、割り当て方法を「先着順」にするだけで設定できる。

ミス4: E-E-A-T メタの reviewer にスペースを入れてしまった

<!-- NG: スペース入り -->
<meta name="reviewer" content="Network Team Leader" />
<!-- OK: アンダースコア区切り -->
<meta name="reviewer" content="Network_Team_Leader" />

RAG システム側のパーサーがスペースを区切り文字として複数値と誤解析するケースがあった。content 属性にスペースを含む値を入れるときはアンダースコアに統一するのが安全。

ミス5: 低評価カウント列で競合書き込みが発生した

SharePoint リストの「低評価カウント」列に +1 するフローを書いたが、複数ユーザーが同時に操作すると値がズレることがあった。「現在値を取得して上書き」方式ではなく、SharePoint REST API の __metadata.etag を使った楽観的ロックによる更新方式に切り替えて解消した。小さな問題だが、放置するとカウントの信頼性が崩れて自浄作用が機能しなくなる。

私の検証メモ

本記事は、自分が業務 / 自宅環境で実際にぶつかった事象に対し、検証用 VM やサブ機を使って再現・対処した一次記録です。一般論ではなく『私の環境では確かにこう挙動した』という観測をベースにしているため、構成が違えば挙動も変わります。再現できない場合は、本文中で挙げた前提条件（OS バージョン / ドライバ / BIOS / 関連サービスの状態）から差分を疑ってください。