古くなった資料が自分で申告する仕組み

資料が古くなるコストは、作るコストより大きい

社内で使う資料は、作った日がいちばん正確で、そこから毎日少しずつ実態からずれていく。料金表、業務マニュアル、研修スライド、営業提案の標準テンプレート。どれも作った時点では正しかったのに、半年後には値上げ前の単価が残り、廃止したはずの手順が載ったままになり、退職した担当者の名前が連絡先欄に残っている。

厄介なのは、古くなったことに誰も気づかないまま使われ続ける点だ。機械なら壊れれば止まるので分かる。資料は壊れない。古いまま、それらしい顔をして会議に出てくる。10人規模のマーケティング会社で、去年作った提案テンプレートをそのまま客先に出してしまい、すでに提供をやめたオプションの説明が入っていた、という事故はどこの会社でも起きている。事故が表に出るのは、たいてい相手に指摘されたときだ。

さらに、更新にかかるコストは作成にかかるコストより高くつくことが多い。新しく作るときは最初から書くと腹をくくれるが、更新は「どこが変わったのかを探す」ところから始まる。全ページを読み直し、元になった情報と突き合わせ、直すべき箇所を特定する。この探す工程に時間の大半が消える。資料運用の本当のボトルネックは、書き直す作業ではなく、どこを書き直すべきか分からない状態そのものにある。

そしてこの問題は、生成AIで資料を作るようになってから、むしろ深刻になった。作るのが速くなったぶん、資料の本数が増えたからだ。10本なら人力で棚卸しできるが、100本になると誰も全部は見ない。見ないまま、全部が少しずつ古くなっていく。

自分の古さを申告する資料、という発想

海外の技術者向け掲示板に、SlideOpsという小さな仕組みが公開された。作ったのはGlukicovという開発者で、GitHub上で誰でも中身を確認できる。彼が困っていたのは、まさにいま書いた問題だった。

彼はAIに自分のプログラムを読ませて、その解説スライドを作らせていた。最初はうまくいく。ところが数週間経つとプログラムのほうが更新され、スライドの内容が実態とずれる。直そうとすると、AIにもう一度プログラム全体を読ませることになる。時間もかかるし、AIの利用料金もかかる。しかも、直す必要があるのは20枚のうち3枚だけかもしれないのに、毎回20枚ぶんのコストを払うことになる。

そこで彼が取った手は、スライドそのものに出どころを持たせることだった。スライドの各ページが、自分はこのファイルの何行目から何行目を根拠に書かれた、という情報を抱えている。しかもその範囲の中身をハッシュ（文章や数字を短い固定長の文字列に変換した、内容の指紋のようなもの）にして一緒に持っている。指紋が一致していれば根拠は無傷、一致しなければ根拠が変わったと分かる。

これで、資料は自分が古くなったことを自分で申告できるようになる。人間が全ページを読み直して探す必要がない。資料に出どころを持たせるだけで、確認作業が読解から照合に変わる。 読解は人間かAIにしかできないが、照合は機械がただの作業として一瞬でこなす。

チェックにAIを使わない、という設計判断

この仕組みでいちばん学ぶところが多いのは、確認作業にAIを一切使っていない点だ。作者はチェック処理をPythonの標準機能だけで書いている。外部のAIを呼ばない。インターネットにもつながらない。だから速いし、料金もかからないし、社外に情報が出ない。

しかもこの確認は、単に「違う」と言うだけで終わらない。位置がずれただけなのか、中身そのものが変わったのかを区別する。上のほうに新しい処理が足されて、根拠にしていた箇所が10行下にずれただけなら、書いてある内容は今も正しい。位置情報を更新すれば済む。一方で、その箇所の中身が書き換わっていたら、スライドに書いた説明そのものが間違っている可能性がある。この場合は人間かAIが読んで直す必要がある。

この区別が効くのは、対応の重さがまったく違うからだ。前者は機械が勝手に直せる。後者だけが人間の判断を要する。もし両方をまとめて「変わりました」としか言わなかったら、結局すべてを読み直すことになり、何も解決しない。

そしてAIの出番は最後だけになる。確認の段階で、どのページの、どの根拠が、どう変わったかまで絞り込まれている。だからAIには全体を読ませる必要がなく、直すべき箇所だけを渡せばいい。安い作業と高い作業を分けて、高い作業の範囲をできるだけ小さくする。これがAIを業務に組み込むときの、いちばん効くコストの下げ方だ。

AIを使うと決めた瞬間に、何でもAIに投げたくなる。だが実際には、AIを使わなくていい部分を先に切り出したほうが、全体としては速く安くなる。

非エンジニアの仕事に、そのまま置き換わる話

ここまではプログラムとスライドの話だが、構造は非エンジニアの資料とまったく同じだ。

あなたの手元にある資料の多くは、何かの写しである。就業規則の説明スライドは、就業規則という正本の写し。顧客向けの料金表は、社内の価格マスタの写し。研修テキストは、業務手順書の写し。カスタマーサポートのトークスクリプトは、返品ポリシーの写し。写しである以上、正本が変われば写しも変わらなければならない。

ところが実務では、正本と写しの関係がどこにも書かれていない。就業規則を改定した総務担当は、それを説明した資料が社内に何本あるのか把握していない。価格を改定した営業企画は、その単価を引用している提案書が何本あるのか知らない。だから改定は反映されず、写しだけが取り残される。

SlideOpsが持ち込んだのは、写しの側に「私はこれの写しです」と書かせるという発想だ。技術的には行番号とハッシュだが、文書の世界ではそこまで厳密でなくていい。元のファイル名、参照した見出しや条番号、確認した日付。この3つが書いてあるだけで、確認作業は劇的に軽くなる。就業規則を改定したとき、第12条を参照している資料だけを探せばいい。

資料は作品ではなく、正本から出力された結果物として扱う。この一点を変えるだけで、更新は棚卸しから差分対応に変わる。

資料の価値は書きぶりではなく、どの正本から出力されたかを追跡できることで決まる。 見た目が整っている古い資料より、素っ気なくても出どころが明記されている資料のほうが、組織にとってはるかに安全だ。

業種別に見る、どこで効くのか

従業員40名の製造業、総務担当の場合

就業規則を改定したとする。改定作業そのものは社労士と進めるので迷わない。問題はその後だ。新入社員向けのオリエン資料、パート向けの勤怠説明シート、管理職向けの評価運用マニュアル、イントラに貼ってある休暇申請の手順ページ。これらすべてに就業規則の内容が引き写されている。しかもそれぞれ別の担当者が別の時期に作っている。改定のたびに全部を開いて読み直すのは現実的でないので、たいてい放置され、パート向けシートだけ2年前の有給付与ルールのまま残る。ここで各資料の冒頭に「出典：就業規則 第4章 第18条から第22条／確認日 2026年3月10日」と書いておけば、改定した条文の番号で検索するだけで、直すべき資料が10秒で並ぶ。読み直す必要はない。実際に直すのは、その中の該当ページだけだ。

15人規模の会計事務所、顧問先対応の担当者の場合

制度改正の説明資料は、会計事務所にとって商品そのものに近い。インボイスや電子帳簿保存の要件が変わるたび、顧問先向けの説明スライドや案内文を更新する。ところが顧問先ごとにカスタマイズしたバージョンが枝分かれしていて、どの版がどの通達を根拠にしているかが分からなくなる。結果、古い要件のまま説明してしまい、後から訂正の連絡を入れる羽目になる。信用に直結する事故だ。ここでも各資料に「出典：国税庁 一問一答 問15／取得日 2026年5月」と根拠と取得日を書いておけば、その一問一答が改訂されたときに、影響する資料と顧問先が一覧で出る。訂正連絡も、影響のある先だけに絞って出せる。全社に一斉送信して不安を煽らずに済む。

30名規模のEC運営会社、カスタマーサポート責任者の場合

返品・交換ポリシーを変更したとき、直すべきものが驚くほど多い。サイト上のガイドページ、チャットボットの回答文、オペレーター用のトークスクリプト、よくある質問集、外部モールの店舗ページ、注文完了メールの文面。しかも作った時期も担当者もバラバラで、AIに作らせた派生版まである。1か所でも古いまま残ると、顧客ごとに違う案内をすることになり、クレームの温床になる。ここで各文面の管理表に「出典：返品ポリシー v3.2／該当：未開封品の返送期限／確認日」を持たせておけば、ポリシーを更新した瞬間に、更新が必要な文面の一覧が出る。オペレーターにも、いま自分が見ているスクリプトがいつ時点のものかが分かる。出どころを書くという一手間は、書くときのコストではなく、変わったときの捜索コストを買い取る投資だ。

今日から使える、5つの手順

技術的な仕組みを導入しなくても、考え方だけなら今日から入れられる。順番はこうなる。

第一に、正本を1つに決める。同じ内容のファイルが複数の場所にあるなら、どれが正なのかを宣言する。ここが決まっていないと、そもそも何の写しなのかを書けない。よくあるのは、共有ドライブとローカルとチャットの添付に3つの版があって、誰も正が分からない状態だ。ここを片づけるのが最初の仕事になる。

第二に、資料の1ページ目か各セクションの末尾に、出典・該当箇所・確認日を書く。凝った様式はいらない。「出典：価格マスタ 2026年度版／該当：Bプラン月額／確認日 2026年9月1日」の1行で十分だ。

第三に、正本を更新したときに写しを洗い出す担当と手順を決める。改定した人が洗い出すのがいちばん確実だ。改定の起案書に「影響資料の一覧」という欄を1つ足すだけでも運用は回る。

第四に、洗い出した資料のうち、該当ページだけを直す。ここでAIを使う。全文を渡さず、変更前後の正本と、直すページだけを渡すのがコツだ。

第五に、直したら確認日を更新する。ここを飛ばすと、次の改定でまた全部を疑うことになる。

AIに手伝わせる場合、最初の一手はこう頼むと早い。

（コピーして使えるプロンプト:）

以下の2つを渡します。
【正本の変更点】変更前と変更後のテキスト
【対象資料】いま使っている説明資料の本文

やってほしいこと:
1. 対象資料の中で、正本の変更によって事実と食い違う箇所だけを列挙する
2. 各箇所について、単なる表現の差か、内容が誤りになったかを区別する
3. 内容が誤りになった箇所のみ、修正案を提示する
4. 変更の影響を受けない箇所は書き換えない

推測で補わず、渡したテキストに書かれていることだけを根拠にしてください。

この頼み方の要点は、直さなくていい箇所には触るなと明示することだ。指示しないとAIは資料全体を親切に整えようとして、変えなくていい部分まで書き換える。そうなると、どこが本当の変更点なのかが分からなくなり、確認の手間が増える。変えない箇所を明示的に守らせることが、AIに資料を直させるときの最重要ポイントになる。

注意点と、よくある3つの誤解

1つめの誤解は、これを入れれば資料が自動で最新になる、というものだ。そうはならない。この仕組みがやるのは、古くなったと教えることまでだ。直すのは人かAIで、そこには相応の時間と判断が要る。むしろ導入直後は、これまで見えていなかった古い資料が大量に可視化されて、仕事が増えたように感じる。それが正常な反応で、これまで見ないふりをしていた負債が表に出ただけだ。最初の棚卸しさえ越えれば、その後は差分だけの対応になる。

2つめは、出典を書けば内容が正しくなる、という誤解だ。出典が保証するのは、正本と写しが一致していることだけで、正本そのものの正しさは別問題になる。価格マスタの入力が間違っていれば、それを正しく引き写した提案書も間違う。だから出典を書く運用と、正本の品質を保つ運用は両方いる。むしろ出典を集中させると、正本の間違いが一気に全社に波及するので、正本の管理は今までより厳しくする必要がある。

3つめは、すべての資料に適用すべきだという思い込みだ。これは違う。一度きりの会議用メモや、その場で使い捨てる打ち合わせ資料に出典を書くのは、手間のわりに見返りがない。効くのは、繰り返し使われて、正本があって、間違うと外に迷惑がかかる資料に限られる。契約関連、料金、法令や制度の説明、安全手順。この4種類から始めれば十分だ。

もう1つ、実務上の注意を挙げておく。正本の置き場所とアクセス権を先に整理することだ。出典を書くということは、参照先を明示するということで、その参照先を見られない人が資料を持つと、確認できないまま使うことになる。人事や財務の正本には見せられない範囲があるので、資料側には「総務が管理する正本の第4章に基づく」といった書き方に留め、実物を追える人を明示しておくのが安全だ。

資料をメンテナンスするのではなく、出力する側に回る

SlideOps自体はプログラムを扱う小さな道具で、Claude Codeの拡張として動くほか、ほかのAI開発ツールでも同じ手順書として使える。使う人を選ぶ道具ではある。だが、そこにある考え方は道具を選ばない。

資料を手作りの作品として抱えている限り、更新は永遠に人間の記憶力と気配りの問題であり続ける。誰かが覚えていて、誰かが気づいて、誰かが直す。その誰かが辞めた瞬間に、資料は静かに腐りはじめる。一方、資料を正本からの出力物として扱えば、更新は仕組みの問題になる。正本が変わったら、写しの一覧が出て、該当箇所だけが直る。担当者が変わっても回る。

AIで資料を作るのが当たり前になったいま、差がつくのは作る速さではない。作ったものを何本抱えられるか、つまり保つ力のほうだ。これから効いてくるのは、たくさん作れる会社ではなく、作ったものが古くなったことに気づける会社になる。 出典を1行書く。それだけで、あなたの資料は自分の状態を申告しはじめる。

自社のどの資料からこの整理を始めるべきか、正本をどう決めるべきか。この判断は業種と体制によって変わります。Claude Worksでは、手元の資料と業務フローを見ながら整理の順番を一緒に決める無料30分相談を受け付けています。まずは今いちばん更新が滞っている資料を1本持ってきてください。