Claudeで作業標準書の改訂差分を現場向けの変更点周知にする

作業標準書を改訂したあと、現場に「どこが変わったのか」を伝える文書づくりは地味に時間を取ります。新旧のPDFを横に並べて目で追い、変更点を拾い、どの工程と誰に関係するかを書き起こす作業です。

この前半、つまり新旧の突き合わせと変更点の一覧化は、Claudeに新旧のPDFを渡して任せられます。後半の周知文は、毎回の書き方がぶれないよう、型をSkillに持たせると安定します。

新旧PDFを渡して、変更点を表にさせる

まず、旧版と新版のPDFを同じ会話に添付します。指示は「差分を出して」だけにせず、出力の列を先に決めておきます。

添付は作業標準書の旧版(Rev.3)と新版(Rev.4)です。
差分を次の列の表にしてください。
- 該当箇所(章・ページ)
- 旧の記載 / 新の記載(原文に近い形で)
- 変更の種類(追加 / 削除 / 数値変更 / 手順の順序変更 / 表現のみ)
- 影響しそうな工程
- 再教育が要りそうな作業者(職種・資格で)
 
表現の整理だけで意味が変わらない箇所は、末尾にまとめてください。
読み取れなかった箇所は推測せず「要確認」と書いてください。

ここでの工夫は3つです。

• 「変更の種類」を選択式にして、数値や順序の変更を表現の揺れと区別させる
• 「原文に近い形で」と指定し、Claudeの言い換えを現場に出さない
• 読み取れない箇所は「要確認」に逃がし、埋め推測を避ける

出力は次のような形になります。以下は書式の例示で、実際の作業標準書の内容ではありません。

影響工程と再教育の欄は、候補として扱う

表のうち、「該当箇所」「旧の記載」「新の記載」は文書に書いてあることの抜き出しです。一方、「影響工程」と「再教育が要る作業者」は、文書に書かれていないことをClaudeが読み取って補った欄です。

作業標準書に工程名や必要資格が書かれていれば、そこから引けます。書かれていなければ、Claudeは一般的な推測に寄ります。この2列は「候補」として出させ、確定は製造や品質の担当者が行います。

確定に必要な材料は、プロンプトの側から渡せます。たとえば次のように、社内の呼び方を添えます。

工程名は次の一覧を使ってください:
受入検査 / 加工 / 組立 / 最終検査 / 出荷
再教育の対象は、次の区分から選んでください:
新人 / 一般作業者 / 検査員 / 保全担当 / 班長

選択肢を渡すだけで、現場で通じない言い方が表に混ざりにくくなります。

PDFの大きさと形式に注意する

作業標準書は図や写真が多く、ページ数も膨らみがちです。Claudeの開発者向けPDF対応(API)には次の上限があります。

新旧を同じリクエストに載せると、2冊分の合計が上限に数えられます。版ごとのページ数が多い作業標準書は、この点を先に見積もっておくと安心です。

claude.aiでファイルを渡す場合は、アップロードもダウンロードも1ファイル30MBが上限です。上の表はAPIの数字で、claude.aiの会話に当てはまる値ではありません。

また、図表の多い密なPDFは、ページ上限に届く前にコンテキストを使い切ることがあります。その場合は、章ごとに分けて渡します。大きなPDFは、ページ上限より手前でリクエストが失敗することもあり、これはFiles APIを使っても同じです。各ページは画像としても処理されるため、埋め込み画像を縮小して容量を落とす手も効きます。公式の最適化の項には、PDFをテキストより前に置く、読みやすいフォントを使う、ページを正しい向きに回す、プロンプトでPDFビューアーのページ番号を使う、といった工夫も挙がっています。

パスワード付きのPDFは扱えない条件になっています。社内で保護をかけているファイルは、解除した版を用意する必要があります。

周知文の型をSkillに持たせる

変更点の表ができても、現場に配るのは表そのものではありません。班長朝礼で読み上げる短い文面や、掲示用の1枚が必要です。この文面の型を毎回プロンプトに書くより、Skillにしておくと、誰が実行しても同じ型で出てきます。

Skillは、skill.md を含むフォルダです。ファイル先頭のYAMLに name(64字以内)と description(200字以内)を書きます。description はClaudeが「いつ使うか」を判断する材料なので、使う場面を具体的に書きます。

---
name: 作業標準書改訂の周知文
description: 作業標準書の新旧差分から、現場向けの変更点周知文を作る。改訂、Rev、変更点周知の依頼で使う。
---
 
## 出力の構成
1. 件名(文書名・版・施行日)
2. 変更点を3点以内(現場で動作が変わるものを優先)
3. 影響する工程と、再教育が必要な作業者
4. 施行日と、不明点の問い合わせ先
5. 要確認事項(読み取れなかった箇所)
 
## 書き方
- 一文は短く、作業者が声に出して読める長さにする
- 旧と新は「これまで:○○ / これから:○○」の対で書く
- 数値は単位まで原文のまま書く
- 表現のみの変更は周知文に入れない
- 施行日・担当者名が差分から分からないときは空欄にして「要確認」とする

構成を番号で固定し、書き方の規則を短く並べるのがコツです。description が曖昧だと、Claudeが使うべき場面でSkillを呼ばないことがあります。公式のトラブルシューティングにも、説明欄に使う場面が明確に書かれているかの確認が挙がっています。

Skillを取り込む手順は次のとおりです。

この機能にはコード実行が有効になっている必要があります。Teamプランでは既定で有効なので、Ownerは組織設定のPlugins & skillsにあるPolicyタブで、有効のままかを確かめる程度で足ります。Enterpriseでは、同じタブでコード実行とSkillsの両方が有効かをOwnerが確かめます。個人プランは、Settings > Capabilitiesでコード実行とファイル作成が有効になっていれば足ります。

改訂のたびに回す流れ

Skillができたあとは、改訂ごとに次の順で回します。

1. 新旧のPDFを添付し、差分の表を出させる
2. 工程名と再教育区分の選択肢を添えて、「候補」の2列を埋めさせる
3. 品質または製造の担当者が表を確認し、2列を確定する
4. 確定した表を渡して、Skillの型で周知文を作らせる
5. 班長が現場向けの言い回しを直し、承認者が決裁して配布する

配布後の実施記録まで仕組みにする場合は、ClaudeとProcess Streetの連携でSOPの実行管理を扱っています。

3番を挟むことで、Claudeの推測が確定情報として現場に出ることを防げます。

法改正の差分を発注書の点検に使う進め方は、取適法の変更点を発注書チェックに落とす手順でも扱っています。新旧を比べて項目別に整理するという骨格は、作業標準書でも同じです。

同じ型を職場全体で使うには

自分用のSkillが動いたら、品質管理の同僚にも使ってもらいたくなります。Team・Enterpriseでは、作ったSkillを特定の人やグループに共有できます。共有されたSkillは閲覧のみで、受け取った側は有効化して使えますが、中身は編集できません。作者が更新すると、受け取った側は次の利用時に更新版を受け取ります。

全社の標準にしたい場合は、組織への公開(Publish to org)を使います。組織が審査を必須にしていれば、Ownerなどの審査者が確認してから公開されます。組織全体に配る設定の流れは、Skillsを組織全員に配布するOrganization settingsの手順にまとめています。

なお、共有されたSkillを有効にする前には、同梱ファイルの中身を確かめます。公式も、信頼できる提供元のSkillだけを入れるよう注意しています。スクリプトを同梱する場合は特に、何を実行するかを読んでから有効にします。

よくあるつまずき

差分の数が合わない: 表の中にレイアウト変更だけの行が混ざる、逆に小さな数値変更が漏れる、といったことが起こります。数値を含む行は、新旧の原文と突き合わせてから確定します。

図の中の変更が拾われない: PDFは各ページが画像としても処理されますが、図中の細かい文字や寸法線は読み違えることがあります。図が差し替わった箇所は、表に頼らず担当者が目で確かめます。

新旧の取り違え: 添付の順序やファイル名が紛らわしいと、旧版と新版が逆になった表が出ます。プロンプトで「旧はRev.3、新はRev.4」と版番号を明示し、表の見出しにも版番号を入れさせます。

Skillが呼ばれない: トグルがオフ、description が曖昧、のどちらかが多い原因です。「作業標準書改訂の周知文のSkillを使って」と依頼で名指しして試すと切り分けられます。

アップロードで弾かれる: ZIPのサイズ超過、フォルダ名とSkill名の不一致、skill.md の欠落、名前や説明の不正な文字が代表的な原因です。

Skillの項目が見当たらない: Customize > Skillsが出ない場合は、コード実行が無効になっている可能性があります。Team・Enterpriseでは、Skillの作成をOwnerが止めていることもあります。

まとめ

作業標準書の周知は、突き合わせと一覧化をClaudeに、確定と承認を人に分けるのが現実的です。新旧PDFから出る差分表は下書きで、工程と再教育の欄は担当者が確かめて初めて現場に出せます。

周知文の型を一度Skillにしておけば、改訂のたびにプロンプトを書き直す手間が減り、班ごとの文面のばらつきも抑えられます。最初の1回は、過去に改訂済みの旧版と新版で試し、実際に配った周知文と見比べると、型の直しどころが見えます。