サービスデスクや運用チームがFAQ、手順書、既知エラー、障害対応メモを蓄積しても、問い合わせのたびに担当者へ聞き直しているなら、ナレッジは十分に機能していません。 検索しても似た記事が並ぶ、前提となる製品バージョンが分からない、古い手順が残る、更新できる人が限られる。こうした状態では、記事数が増えるほど見つけにくさと誤利用のリスクも増えます。

ITIL 4はKnowledge Managementを、組織全体で情報と知識を効果的、効率的、便利に利用できるよう維持・改善するプラクティスと位置付けています。 PeopleCertは2026年のAIとナレッジ管理に関する公式論考で、AIエージェントの判断品質も、参照する知識が正確で、構造化され、最新であるかに左右されると注意を促しています。

重要なのは、完成した文書を大量に登録することではありません。問い合わせや障害対応の流れで知識を探し、使い、直し、足りないときだけ作り、利用状況から全体を改善することです。 本記事では、ITIL 4の目的とKnowledge-Centered Service（KCS）の実践を組み合わせ、経営者、IT責任者、実務担当者が同じ方向で進める5ステップを整理します。

課題：ナレッジ作成が日常業務の外にある

よくある運用は、問い合わせ対応が終わってから、別の担当者が「重要そうな案件」を記事化する形です。この方法では、利用者が使った言葉、発生環境、判断の分岐、実際に有効だった解決策が抜けやすく、公開までの間に情報も古くなります。 一方、担当者へ記事作成数の目標だけを置くと、既存記事を探すより新規作成が優先され、重複や未検証の記事が増えるおそれがあります。

KCS Practices Guideは、知識を問い合わせ対応の副産物として捉え、対応の中で検索、再利用、改善し、存在しなければ作成する考え方を示しています。 個々の対応で回すSolve Loopと、利用パターンからナレッジ全体の健全性を改善するEvolve Loopを分けることで、「目の前の解決」と「組織としての学習」を両立させます。

基本構造：「対応のループ」と「改善のループ」をつなぐ

対応のループでは、担当者が最初にナレッジを検索し、適合する記事を使います。記事が不十分ならその場で直すか、修正が必要であることを記録し、見つからなければ新しく作ります。 ここで残すのは個別の顧客情報ではなく、再利用できる課題、環境、解決、必要に応じた原因です。KCSは、依頼者固有の情報をインシデント記録へ残し、再利用部分と分けることを勧めています。

改善のループでは、検索語、再利用、修正、重複、未解決、評価、エスカレーションの傾向をまとめて見ます。利用の多い記事を優先的に整え、重複を統合し、対象外になった記事を廃止し、繰り返し発生する課題は問題管理やサービス改善へ渡します。 Google Cloudの運用ガイダンスも、既知の問題、解決策、トラブルシューティングを集約し、インシデント記録の傾向を見ながら定期的に更新することを推奨しています。

実践手順：再利用される運用をつくる5ステップ

1．対象サービスと利用場面を一つに絞る

最初から全社の文書を統合せず、問い合わせ量があり、担当者間で回答差が出ているサービスを一つ選びます。利用者、一次対応、専門チームのどこで使うかを決め、ナレッジで改善したい結果を明確にします。 たとえば、自己解決を増やす、一次対応で解決できる範囲を広げる、エスカレーション時の調査やり直しを減らす、重要インシデントの初動をそろえる、といった具体的な利用場面です。

2．検索を先に行い、簡単な構造で残す

問い合わせを受けたら、回答を考え始める前に、利用者の表現と環境条件で検索します。見つかった記事が使えれば記録へ関連付け、違いがあれば修正候補を残します。なければ、対応中に分かった範囲で作成します。 テンプレートは、課題・質問、環境、解決、必要に応じた原因、対象読者、更新日程度から始めます。最初から多くの必須項目を設けず、見つけられ、使えるために必要な構造へ絞ります。

3．信頼度、公開範囲、変更権限を分ける

作成中、未検証、検証済み、廃止などの状態を定義し、誰が参照できるか、誰が変更できるかを組み合わせます。実際の対応で再利用され、内容が確かめられた記事は信頼度を上げます。 管理者権限、個人情報、セキュリティ対応、契約条件を含む手順は、利用者向けの案内と内部限定の実行手順を分離します。公開範囲を広げることと、操作権限を広げることを同じ判断にしないことが重要です。

4．「再利用した人」が直せる流れをつくる

記事の利用者が、誤り、前提不足、読みにくさ、対象外を見つけたとき、その場で修正できる範囲と、確認依頼へ回す範囲を決めます。専門家だけが更新する中央集権型では、変更待ちが積み上がります。 一方で、すべてを自由編集にする必要もありません。影響の小さい表現改善は現場で、操作手順や統制に関わる変更は指定したレビューへ、といったリスク別の変更経路にします。

5．作成数ではなく、利用と成果の組み合わせで改善する

記事作成数だけで個人やチームを評価しません。問い合わせと記事の関連付け、既存記事の再利用、修正、重複、検索しても見つからなかった割合、利用者からのフィードバック、一次解決やエスカレーションの傾向を組み合わせて見ます。 KCSは、単一の活動量を目標化すると数字自体が目的になり得るため、行動と成果を複数の指標で対話するよう注意しています。数値は人を順位付けするためではなく、検索や更新が業務へ組み込まれていない場所を見つけ、コーチングや仕組みの改善へ使います。

注意点：AI導入より先に、知識の境界を整える

  • 古い文書を一括投入しない：重複、期限切れ、権限の異なる文書をそのまま検索AIへ接続すると、誤った回答を速く広げる可能性があります。
  • インシデント記録をそのまま公開しない：個人、顧客、構成、認証、脆弱性などの固有情報を、再利用できる知識から分離します。
  • 公開日だけで鮮度を判定しない：サービス変更、製品更新、障害、利用者の指摘、再利用時の不一致を更新契機にします。
  • 万能な記事を作らない：環境や原因によって解決策が変わる場合は、適用条件を明確にし、必要なら記事を分けます。
  • ツール導入を運用設計の代わりにしない：検索、関連付け、権限、状態、更新、廃止の役割と判断基準を先に決めます。

最初の90日で作るべき成果物

最初の30日で、対象サービス、利用者、代表的な問い合わせ、既存ナレッジ、情報区分を確認し、簡単な記事構造と状態を決めます。次の30日で、少人数の一次対応チームが検索、関連付け、修正、作成を実際の対応の中で試します。 最後の30日で、再利用された記事、見つからなかった検索、修正待ち、重複、エスカレーションの例を振り返り、テンプレート、権限、レビュー経路、指標を調整します。

成果物は大規模なナレッジ移行計画ではなく、対象サービスの利用場面、最小テンプレート、状態と公開範囲、変更ルール、週次の改善レビュー、評価指標の組み合わせです。 この一式が動いてから対象を広げる方が、文書庫を新しい文書庫へ移すだけの投資を避けやすくなります。

まとめ

ナレッジ管理の価値は、記事が何件あるかではなく、必要な場面で見つかり、適用条件が分かり、使った人によって更新され、不要になれば安全に廃止されることにあります。 対応のループで検索・再利用・改善・作成を回し、改善のループで全体の健全性とサービス成果を見直す。この二つを日々の仕事へ組み込むことが、ITIL 4のKnowledge Managementを実務へ落とし込む近道です。

FourthWallは、サービスデスク、インシデント管理、問題管理、ナレッジ管理を分断せず、利用場面の選定、ワークフロー、権限、指標、段階導入までを支援します。 AI活用を検討している組織も、まず一つのサービスで「検索してから解決し、使った知識を直す」流れを確立することが、安全で持続的な第一歩です。

参考資料

KCS®はConsortium for Service Innovationのサービスマークです。本記事は公開資料に基づく一般的な情報提供を目的とし、特定の製品選定、契約、法務、セキュリティに関する個別助言ではありません。実際の運用では、対象サービス、情報区分、権限、法令・契約、セキュリティ要件を関係専門家と確認してください。

FW

WRITTEN BYFourthWall Consulting Teamテクノロジーと経営の両面から、企業変革を支援しています。

← 技術ブログ一覧へ戻る