社内文書は入れたら終わりではない｜AIが古い版を答える前に

マイクロソフトが公開している検索サービスの手引きには、少し意外なことが書かれています。変更の検知は自動で行われるが、削除の検知はそうではない、索引を作る仕組みは元のデータでの削除を追跡しない、という一文です。さらに、削除を見つけるための設定は最初の巡回より前に入れておく必要があり、あとから足して作り直しても、それ以前に消された分は索引に残り続ける、とも書かれています。消したはずの文書が答えに出てくるのは、道具の不調ではなく、仕様として先に書かれている動きです。

「規程を改訂したのに、社内のAIが前の版の条文を答える」「もう使っていない手順書が、検索でいちばん上に出てくる」——社内の文書をAIに読ませ始めて半年ほど経った会社から、決まって届く声です。足りていないのは更新の手間ではありません。本当は、その文書がいつ効力を失うのかが、文書の側に書かれていないことが原因です。この記事では、入れたあとの鮮度をどう保つかを、版の入れ替え、失効、棚卸しの周期という順に整理します。

入れて半年たった社内AIに、実際に起きること

社内の文書を読ませた直後は、たいてい評判が良いものです。読ませた資料がその時点で最新だからです。難しいのは、そこから先です。鮮度の問題は、導入の失敗としてではなく、時間差で来る不具合として現れます。半年後、1年後に、答えの中身だけが静かにずれていきます。

ずれ方は文書の型によって違います。規程は年に1回改訂され、価格の表は四半期ごとに差し替わり、手順書は道具が変わるたびに書き換えられます。様式は改訂のたびに新しい版が置き場に足されますが、古い版が消されることはまずありません。改訂した担当者は新しい版を置くところまでが仕事で、古い版を抜くところは誰の仕事にもなっていないからです。

利用者の側から見ると、この現象は「AIが嘘をついた」に見えます。しかし実際には、AIは正しく読んでいます。根拠として引いた文書が古いだけです。原因が読み取りの精度ではなく置き場の状態にあるため、道具を入れ替えても直りません。ここを取り違えると、別のサービスに乗り換えて同じ不具合を繰り返すことになります。

消したはずの版が答えに出続ける、仕組みの側の理由

仕組みを2つに分けて考えると、理由がはっきりします。文書の原本が置いてある場所と、検索のための索引は別物です。索引は原本を定期的に巡回して、写しと目印を作ります。答えを組み立てるときにAIが引くのは、原本ではなくこの索引です。原本と索引の間には、必ず時間差と、追いきれない差分が生まれます。

変更は比較的簡単に追えます。最終更新日時が動くからです。ところが削除は違います。無くなったことは、無くなった側からは何も知らせてくれません。だから先ほどの手引きでは、取り残された検索文書を作らないために、まず検索側の文書を消し、置き場の実体を消すのは2段目にする、という順番が勧められています。やり方は2つで、置き場そのものが持つ論理削除の仕組みに任せる方法と、文書に削除済みを示す項目と値を付けて索引側にそれを読ませる方法です。

ここに落とし穴があります。索引の側は、論理削除の状態にある文書を巡回で実際に処理したときにだけ、検索の文書を消します。だから手引きには、論理削除の保持期間は巡回の間隔よりずっと長く設定するように、と書かれています。保持期間が短いと、巡回が回ってくる前に実体だけが消えます。消える順番が逆になると、原本の無い答えだけが手元に残ります。

「最初の1回目」を逃すと、あとから設定しても戻らない

同じ手引きの中で、実務にいちばん効くのは次の一文です。削除を見つける方法は、最初の巡回より前に適用しなければならない。設定する前に消された文書は、あとから設定を足して作り直しても索引に残る。そうなってしまった場合は、新しい索引を新しく作り直すことが勧められています。順番を間違えると、あとから直す道がほとんど残りません。

この一文は、読ませる前のチェックリストを1行増やすだけで守れます。どの文書を入れるかを決めるときに、削除をどうやって索引に伝えるかも同時に決めておく。それだけです。入れる設計と、抜く設計を、同じ日に決める。抜く設計を後回しにした会社が、半年後にいちばん困ります。

逆向きの事故もあります。いったん消した文書を元に戻したのに、答えに出てこないという状態です。手引きによると、論理削除を取り消しても最終更新日時は更新されないため、巡回はすでに処理済みだと判断して読み直しません。対処として、中身を変えなくても付随情報を保存し直して最終更新日時を動かす、という方法が案内されています。フォルダの名前を変えた場合も同じで、配下の文書の最終更新日時は動かないため、そのままでは読み直されません。

• 削除の伝え方は、最初の巡回より前に決めておく（あとから足しても過去分は残る）
• 論理削除の保持期間は、巡回の間隔よりずっと長くしておく
• 戻した文書は、最終更新日時を動かさないと読み直されない
• 1件の文書を複数に割って入れている場合は、論理削除が効かず明示的な削除の要求が要る

更新日を見ても、鮮度は分からない

実務でいちばん多い誤解が、更新日の新しい順に並べれば最新版が上に来る、という前提です。これは当たっているように見えて、当たりません。更新日が示しているのは、誰かがその文書を触ったという事実だけです。中身が正しいかどうかとは、そもそも別の情報です。

触っただけで更新日が動く例は、いくらでもあります。様式の体裁を整えた、誤字を1文字直した、開いて何もせずに保存した、保存場所を移した。逆に、内容が完全に古びても、誰も触らなければ更新日は何年も動きません。しかも、更新日が古い文書ほど危ないとも言い切れません。法令の条文をそのまま引いた社内規程は、5年前の版でも正しいことがあります。

つまり、更新日は鮮度の代わりになりません。鮮度を測りたいなら、更新日ではなく、いつまで有効かという別の情報を文書に持たせるしかありません。ここを飛ばして並べ替えの条件だけを調整しても、上位に出てくる文書が入れ替わるだけで、古い版が消えるわけではないのです。

• 更新日の新しい順に重みを付ける：体裁を直しただけの文書が上位に来る
• 一定の期間より古い文書を一律に外す：何年も正しい規程まで落ちる
• 改訂したら更新日が動くはずだと考える：別名で保存されると前の版の日付は残る
• 最終更新日時を鮮度の指標として利用者に見せる：見た人が正しさの根拠だと誤解する

鮮度は文書の側に書く：失効の期日と、次に見直す日

打ち手はひとつに収束します。文書そのものに、鮮度を決める情報を持たせることです。持たせるのは3つで十分です。効力を失う日（または次に見直す日）、所管（見直しの責任を持つ部署または役割）、そして置き換え先（この文書が置き換えられたときに、代わりに読むべき文書）です。

効力を失う日を書くと、鮮度の判断が人の記憶から外れます。「この文書は更新されていますか」と聞かれて答えられる人は社内にいませんが、「期日を過ぎていますか」は機械が答えられます。人に覚えさせるのをやめて、文書に覚えさせる、という置き換えです。所管を書くのは、期日が来たときに誰に尋ねるかを決めておくためです。所管が空欄の文書は、期日が来ても誰も動きません。

3つ目の置き換え先は、見落とされがちですが効きます。契約や検査の記録のように、古い版を消せない文書があるからです。消せない文書ほど、置き換え先を書いておく必要があります。置き換え先が書いてあれば、AIがその文書を引いたときに、置き換えられた版であることと、代わりに読むべき文書の名前を、答えと一緒に出せます。消さずに、誤読だけを防ぐ形です。

1. 効力を失う日、または次に見直す日を入れる（空欄を許さない）
2. 所管を、個人名ではなく部署または役割の名前で入れる
3. 置き換えられたときの行き先を、文書の名前で入れる

社内文書を4つの型に分けてから、周期を置く

すべての文書を同じ周期で見直そうとすると、まず回りません。件数が多すぎるからです。先に型で分けて、型ごとに鮮度の決まり方を変えます。分け方は、内容ではなく置き換わり方で決めるのがこつです。

文書の型	例	鮮度の決まり方	抜き方の置き方
失効があるもの	料金の表、キャンペーンの案内、年度の計画	期日が来た時点で無効になる	期日を文書に書き、過ぎたら索引から外す
改訂で置き換わるもの	規程、手順書、様式、仕様	新しい版が出た時点で前の版が無効になる	版を上げた日に、前の版を同じ工程で抜く
積み上がるもの	議事録、月次の報告、事例	古くなっても無効にはならない	抜かない。いつの時点の話かを必ず付ける
一度きりの記録	契約、検査の記録、届出の控え	そもそも鮮度の概念が無い	抜かない。索引の対象にするかを先に決める

この表で効くのは3行目と4行目です。議事録や報告は古くなっても無効になりません。むしろ過去の経緯を知るために残します。ただし、いつの時点の話かが付いていないと、AIは3年前の決定を現在の方針として引いてきます。積み上がる文書に必要なのは削除ではなく、時点の明記です。

4行目は、そもそも索引に入れるかどうかの判断が先に来ます。契約書や検査の記録を全文読ませると、答えの根拠として引かれたときに扱いが難しくなります。読ませるとしても、要約や台帳の形にして入れ、原本は索引の外に置く。入れない判断も、鮮度の管理の一部です。

棚卸しの周期を3か月・6か月・12か月のどれに置くか

周期の置き方は、実際の製品がどう作られているかを見ると決めやすくなります。マイクロソフトの文書の置き場には、所管者に定期的に内容の確認を求める仕組みがあり、その周期は3か月、6か月、12か月の3つから選ぶ形になっています。細かく刻めるようにはなっていません。選択肢を3つに絞ってあること自体が、運用の知恵です。

対象の選び方も参考になります。その仕組みでは、置き場の作成日が閾値より古く、かつ前回確認した日も同じ閾値より古い場合にだけ、確認の依頼が飛びます。閾値は、実行した日から周期を引いた日です。作ったばかりの場所は猶予で外れ、直近で確認済みの場所は飛ばされます。毎回すべてを見るのではなく、前回からの差だけを見る形にしないと、棚卸しは2周目で止まります。

自社で周期を決めるときの目安は単純です。改訂の頻度より短く置くこと。年に1回改訂される規程を年に1回見直すと、運が悪ければ常に1年近く遅れた状態になります。四半期ごとに動く価格の表を半年周期で見直すのも同じです。見直しの周期は、いちばん早く動く型に合わせるのではなく、型ごとに変えるのが現実的です。

通知して終わりにしない：返事が無かったときの決めごと

周期を置いても、通知に返事が返ってこないのが普通です。ここで止まる会社がとても多いので、先に決めておくべきことを書きます。先ほどと同じ仕組みでは、月に1回の通知を3回送り、それでも反応が無かったときにどう動くかを、設定の段階で選ばせる作りになっています。

選べる動きは3つです。1つ目は何もしない。3回送ったあと3か月は通知を止め、半年経っても反応が無ければ月次の通知を再開します。報告書には未対応として並びます。2つ目は読み取り専用にする。3回の通知に応答が無ければ書き込みが止まります。3つ目は、読み取り専用の期間を3か月、6か月、9か月、12か月から選んで置いたあと、保存階層へ移す。どれを選んでも、3回の通知で区切るところは共通です。

この設計から学べるのは、止める側の決めごとが無いと通知だけが増える、という一点です。自社で回すなら、返事が無かった文書をどう扱うかを先に紙に書いてください。所管が答えないこと自体を、その文書がもう要らないことの信号として扱う、という割り切りが要ります。答えが返ってくるまで待つ運用は、件数が増えた時点で必ず破綻します。

使われていない置き場そのものを畳む

文書を1件ずつ見ていくと終わりません。ある規模を超えたら、置き場ごと畳むほうが速くなります。使われていない置き場を見つける仕組みには、何を活動として数えるかが明確に定義されていて、そこが実務の参考になります。数えるのは、ファイルの閲覧、編集、社内外への共有、同期、ページの閲覧などです。加えて、つながった他のサービス（会話、社内掲示、メール）の動きも合わせて見ます。

面白いのは、数えないものの側です。通知のメールに入っているリンクを開いても、活動としては数えません。しかも、そのメールから開いてから1時間以内の閲覧も数えません。ただし編集は数え、その時点で使われている扱いに戻ります。見に行っただけでは生きているとは見なさない、という線がはっきり引かれています。

自動処理のアクセスも数えません。仕組みの資格情報だけで動く処理は対象外とされ、利用者の資格情報で動く処理も、特定の名乗りが付いているものは除かれると書かれています。巡回や控えの取得のプログラムが毎日触っているだけの場所を、使われていると見なさない設計です。自社の共有フォルダで同じことをやるなら、閲覧の記録をどこで取るのか、機械の動きをどう除くのかを、先に決める必要があります。

索引から外すことと、消すことは違う

「古い版を抜く」と一言で言いますが、実際の手は4つあり、残るものが違います。ここを混ぜたまま議論すると、消したくない人と消したい人が噛み合わなくなります。先に手を並べて、どれを使うかを文書の型ごとに決めてください。

抜き方	原本	権限	AIの答えに出るか	向いている場面
原本を消す	消える	関係しない	出ない	もう誰にも要らないと言い切れるもの
索引から外す	残る	変えない	出ない	開ける人には必要だが、広く見つかると困るもの
保存階層へ移す	残る	保たれる	出ない（利用者も開けない）	使われていないが、捨てるとは決められないもの
読み取り専用にする	残る	書き込みだけ止まる	出る	更新だけを止めて、参照は残したいもの

2行目の「索引から外す」は、権限をいっさい変えずに、組織全体の検索とAIの対象から外す設定として実際に用意されています。開ける人は今までどおり開けるのに、広くは見つからない、という状態が作れます。公開の範囲を絞るために権限を触ると、必要な人まで開けなくなって現場が止まります。権限を触らずに見つかり方だけを変えられる、という選択肢を知っているかどうかで、実務の楽さが変わります。

3行目の保存階層は、内容と権限と付随情報がそのまま保たれ、利用者は開けなくなり、AIの学習にも使われないと説明されています。捨てられない文書の行き先として使えます。ただし開けなくなる以上、戻す手順と、戻せる人を先に決めておかないと、必要になった日に止まります。移す判断と同じ重さで、戻す判断も決めておいてください。

版を入れ替える手順を、1本にまとめる

ここまでの内容を、改訂のたびに踏む手順に落とします。ばらばらの注意事項として配ると守られないので、5段の手順として1本にまとめるのが確実です。改訂を担当する人が、新しい版を置くのと同じ流れで抜くところまで進める形にします。

この手順のうち、現場で飛ばされやすいのは4段目です。巡回の間隔が長い環境では、確認までに1日かかることもあり、待っていられないからです。待てないのであれば、巡回の間隔のほうを短くします。手順を守れない理由が仕組みの側にあるなら、仕組みを直すのが先です。

AIに「最新版かどうか」を判定させない

よく出てくる案が、複数の版をまとめて読ませて、どれが最新かをAIに判断させる、というものです。手間が省けそうに見えますが、勧められません。判定に必要な情報が、そもそも文書の中に無いことが多いからです。道具の賢さの問題ではありません。

実際に足りないのは3つです。版の番号や改訂日が本文のどこにも書かれていない文書が多いこと。書かれていても、改訂履歴が表の中にあって読み取れないことがあること。そして「最新」の意味が型によって違うことです。失効のある文書にとっての最新は期日の内側にあることですが、積み上がる文書にとっての最新はいちばん新しい回の記録であって、古い回が無効になったわけではありません。同じ「最新」という言葉が、文書の型ごとに違うものを指しています。

代わりにやらせることは決まっています。根拠として引いた文書の名前と、その文書に書かれている日付や版を、答えと必ず一緒に出させることです。判定はさせず、根拠を書かせる。そのうえで、人が確認する範囲を先に決めます。料金、契約の条件、安全に関わる手順、社外に出す数字。この4つは、答えをそのまま使わずに原本を開く、と決めておけば、鮮度の事故の大半は表に出る前に止まります。

鮮度が落ちたことに、人が先に気づく仕掛け

期日と周期を置いても、抜けは必ず出ます。問題は、抜けに気づくのが利用者からの申告だけになっていることです。申告してくれるのは、間違いに気づける知識のある人だけで、その人はもともとAIに聞かなくても分かります。いちばん困る人からは、申告が上がってきません。

人の側で見るものは3つで足ります。1つ目は、根拠として引かれた文書の日付の散らばり方です。古い側に偏り始めたら、抜きが追いついていません。2つ目は、同じ問いに対する答えが月をまたいで変わったかどうかです。変わらないまま数か月が過ぎているなら、改訂が索引に届いていない可能性があります。3つ目は、期日を過ぎたまま索引に残っている件数です。この数字は、放っておくと単調に増えます。

大事なのは、指標を増やすことではなく、見る人を決めることです。月に1回、5分で3つの数字を見る人が1人いれば十分に回ります。見る人が決まっていない指標は、作った翌月から誰も見ません。逆に言えば、見る人を決められないなら、指標を作る前に体制の話を先に片づけたほうが早いということです。

• 根拠に引かれた文書の日付が、古い側に偏っていないか
• 同じ問いへの答えが、改訂の月をまたいで変わったか
• 失効の期日を過ぎたまま索引に残っている件数が増えていないか
• この3つを見る人と、見る日が決まっているか

鮮度の問題に見えて、鮮度ではないもの

鮮度の話をしていると、鮮度では説明できない相談が必ず混ざります。切り分けておかないと、抜く作業をいくら続けても直りません。代表が3つあります。

1つ目は、部署によって同じ問いへの答えが違うという相談です。これは古い版の問題ではなく、参照できる範囲が部署で違う、同じ語の指すものが部署で違う、索引の更新のされ方が置き場ごとに違う、という別の原因から来ています。揃える相手が版ではなく用語と権限になるため、打ち手が丸ごと変わります。この話は別の記事で扱います。

2つ目は、権限で見えていないだけの場合です。最新版はきちんと入っているのに、質問した人にその置き場の権限が無く、古い版が置かれた別の場所しか引けていない。3つ目は、そもそも文書が無い場合です。現場の運用が変わったのに、誰も文書を書き換えていない。この場合、AIは残っている一番近い文書を引くしかありません。文書が無いことを、古い文書で埋めさせてはいけません。答えが出てこないほうが、古い答えが出るよりも安全な場面はあります。

ミニ用語解説：この記事に出てきた言葉

社内で話すときに、言葉がずれていると設計の議論になりません。ここまでに出てきた言葉を、実務で使う意味に絞って並べておきます。情報システム部門と業務部門で、同じ意味で使えているかを確かめる用途にも使えます。

この中で誤解が多いのは、論理削除と保持期間の関係です。消したのに残っている、という相談の多くは、この2つの設定が巡回の間隔と噛み合っていないことから来ています。設定の名前ではなく、順番と間隔で理解しておくと、部門をまたいだ会話が通じます。

まとめ

社内文書をAIに読ませる仕事は、入れた時点では半分しか終わっていません。索引を作る仕組みは、元の置き場での削除を自動では追いかけません。マイクロソフトが公開している手引きには、削除を見つける方法は最初の巡回より前に入れておく必要があり、あとから足して作り直しても、それ以前に消された分は残る、とまで書かれています。論理削除の保持期間は巡回の間隔よりずっと長くしておく必要があり、戻した文書は最終更新日時を動かさなければ読み直されません。鮮度を測るのに更新日は使えません。更新日が示すのは誰かが触ったという事実だけだからです。代わりに、失効の期日、所管、置き換え先の3つを文書の側に書きます。そのうえで文書を、失効があるもの、改訂で置き換わるもの、積み上がるもの、一度きりの記録の4つに分け、型ごとに抜き方を変えます。棚卸しの周期は3か月、6か月、12か月のように選択肢を絞り、前回から変わったものだけを見る形にします。月1回の通知を3回送って返事が無かったときにどうするかも、先に決めておきます。抜き方には、原本を消す、索引から外す、保存階層へ移す、読み取り専用にする、の4つがあり、権限を触らずに見つかり方だけを変える手があることを知っているかどうかで、実務の楽さが変わります。そして、最新版かどうかの判定はAIにさせません。判定に必要な情報が文書の中に無いからです。根拠として引いた文書の名前と日付を必ず出させ、料金、契約の条件、安全に関わる手順、社外に出す数字の4つは人が原本を開く、と先に決めておく。まずは、いま読ませている文書のうち、失効の期日が書かれているものが何件あるかを数えるところから始めてみてください。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。