社内の業務手順書が実態と合っているかを点検して、改訂が要るものを洗い出す

処理の起点を決める

毎週の決まった時刻を起点にします。n8n の Schedule Trigger は、Unix の cron に相当する動きをするノードで、秒・分・時・日・週・月の間隔、またはcron式でワークフローを実行できます。週次の実行はこの範囲に収まります。

月100本を週25本ずつに分けて処理します。一度に全1,200本を処理しないでください。 AIの呼び出しが集中し、結果の確認も追いつきません。

もう1つの起点として、正本の側が更新されたときに関連する手順書を再点検する形が考えられます。システムの画面一覧が更新されたら、その画面名を含む手順書だけを点検する、という動きです。これが入ると、年1巡を待たずに食い違いを見つけられます。 ただし最初は週次の定期実行だけで始めてください。

入力データを集める

データの取得方法を決める

手順書： SharePoint の文書ライブラリから取得します。Word、PDF、スライドが混在します。スライド形式の手順書が、実は一番厄介です。 画面のキャプチャに文字が埋め込まれていて、本文としては抽出できません。画像内の文字も読む必要があるかは、自社の手順書の実態を見て決めてください。

正本の索引： 4種類の正本をベクトルストアに取り込みます。規程集と様式一覧はテキストなのでそのまま入ります。画面一覧は、情報システム部が持っていないことがあります。 その場合、システムの画面名の一覧を作ることから始める必要があります。

組織図： 現行の部署名だけでなく、過去の部署名と変更日の対応表を持ってください。「営業推進部」が「営業企画部」になったと分かれば、食い違いの理由まで示せます。

AIへ渡す前に整形する

1. 本文の抽出 … Word・PDF・スライドから本文を取り出します。表の中の文字も落とさないようにします
2. 手順のステップ分解 … 番号付きの手順を1ステップずつに分けます。どのステップが古いかまで特定できると、改訂する側の負担が大きく減ります
3. 画像の扱いの判定 … 画面のキャプチャが多い手順書は、本文だけでは点検できません。「画像中心」の印を付け、別枠で人が見る対象にします
4. 点検対象外の除外 … 廃止済みの手順書、他社から受領した文書、テンプレートを除きます

AIに処理させる

2つの工程に分けます。

参照先の抜き出し（1回目）：

食い違いの判定（2回目）：

「重さの判定」を必ず入れてください。 部署名が「営業推進部」から「営業企画部」に変わっただけなら、手順は実行できます。一方、画面の項目が消えていれば、そこで手順が止まります。この2つを同じ扱いにすると、リストが指摘であふれて誰も見なくなります。

指示内容を固定する

参照先の抜き出しは次のようになります。

あなたは社内文書の管理を支援する担当者です。
下の業務手順書から、この手順書が「現在もそうなっている」と前提にしている
参照先を抜き出してください。

【厳守事項】
- 手順書に実際に書かれている表記のまま抜き出してください。
  正式名称に直したり、略称を展開したりしないでください。
- 手順書に書かれていない参照先を推測で足さないでください。
- どのステップ（番号）に出てきたかを必ず併記してください。
- 一般的な用語（「パソコン」「メール」など）は抜き出さないでください。
  社内固有の名称だけを対象にします。
- 判断に迷うものは uncertain に入れ、その理由を書いてください。

【業務手順書】
{procedure_document}

食い違いの判定は次のようになります。

下の「参照先」が、現在の正本に存在するかを判定してください。

【厳守事項】
- 判定は、下の「正本の検索結果」に書かれている内容のみを根拠にしてください。
  検索結果に情報がない場合は status を unknown にしてください。
  **知識から補わないでください。**
- status は次から選んでください。
  ok ... 現在も同じ名称・同じ版で存在する
  renamed ... 存在するが名称が変わっている
  version_changed ... 様式の版が変わっている
  not_found ... 現在の正本に存在しない
  unknown ... 検索結果から判断できない
- severity は次から選んでください。
  high ... その記述のままでは手順が実行できない
  medium ... 実行はできるが、読み手が迷う
  low ... 表記の違いのみ
- 改訂後の文案を書かないでください。指摘と根拠までが役割です。

【参照先】
{references}

【正本の検索結果】
{retrieved_sources}

「知識から補わない」の1行が要です。 これを書かないと、AIは「就業規則第32条は一般に◯◯を定めています」といった一般論を答えます。自社の規程がどうなっているかは、検索結果にしか書かれていません。

出力形式を固定する

{
  "document_id": "",
  "document_title": "",
  "owner_department": "",
  "last_updated": "",
  "findings": [
    {
      "step_no": "",
      "reference_type": "screen | form | regulation | department | system",
      "as_written": "",
      "status": "ok | renamed | version_changed | not_found | unknown",
      "current_value": "",
      "changed_on": "",
      "severity": "high | medium | low",
      "evidence": ""
    }
  ],
  "high_count": 0,
  "medium_count": 0,
  "unknown_count": 0,
  "image_heavy": false,
  "recommend_revision": true
}

evidence には、正本の検索結果のどの部分を根拠にしたかを入れます。これがないと、文書管理担当は指摘を検証できません。根拠のない指摘は、改訂依頼を受けた部署に反論されて終わります。

unknown_count が多い手順書は、指摘が正しいのではなく、正本の索引が足りていない可能性を示します。この数を全体で見ることで、索引の整備状況が測れます。

システムへ連携する

点検リストは Microsoft Lists に1文書1行で作ります。列は次のとおりです。

改訂依頼は、管理部署の担当者へチャットで通知します。通知には、指摘の内容と根拠を含めてください。 「あなたの部署の手順書を改訂してください」だけの通知は動きません。「ステップ4の『受注入力』画面は、2026年3月に『受注登録』へ変更されています」まで書いて、初めて着手されます。

期限を過ぎた依頼は、週次で再通知します。再通知の宛先に管理部署の上長を含めるかは、運用として決めてください。

人が確認する

改訂を依頼するかどうかは、全件、文書管理担当が決めます。自動で依頼を出しません。

理由は2つあります。1つは、食い違いの中に「あえてそう書いている」ものが混ざるためです。旧システムを一部の拠点だけが使い続けている、といった事情があります。もう1つは、誤った指摘を自動で送ると、次から誰も通知を読まなくなるためです。

確認を速くするための設計が効きます。

• high_count の多い順にリストを並べる
• severity が high の指摘を、根拠と並べて表示する
• 前回の点検で同じ指摘をした文書に印を付ける（放置されている証拠）
• image_heavy が true の文書を別タブに分ける
• unknown ばかりの文書は、索引の不足として別枠に出す

例外に対処する

記録を残す

この業務のログは、文書管理の状況を説明する材料になります。

• 点検日ごとの findings（指摘の内容と根拠）
• 文書管理担当の判断（依頼／様子見／対象外）と、その理由
• 改訂依頼の送信日、期限、改訂の完了日
• 再点検の結果（食い違いが解消したか）
• 正本の索引の更新日

「様子見」とした理由を残すことが特に重要です。 翌年の点検で同じ指摘が出たとき、前回なぜ見送ったかが分からないと、同じ検討を繰り返します。