従業員30〜80名規模の出版社・編集プロダクションを想定したシナリオ。初校から念校までのワークフローに Claude Code を「校閲者の前さばき」として組み込み、誤字脱字・表記揺れ・数字突合・引用元照合の一次チェック工数を圧縮した実装手順と、現場の校閲者・編集者が最終判断者として残り続ける運用設計を公開する。
結論ファースト：この記事で持ち帰れる3つの実装パターン
結論：出版社・編プロの校正校閲は、Claude Code を「最終判断者」ではなく「初校に上げる前の前さばき」として扱うと、校閲者の見落とし発見コストを圧縮できる。本記事はそのための実装手順・プロンプト・失敗パターンを示す。
- 要点1：Claude Code に
CLAUDE.mdで社内スタイルガイド（漢字ひらがな表記、固有名詞、書名表記ルール）を読ませ、原稿全体を走査して「ルール違反候補」を JSON で吐かせる。校閲者は候補リストを「採否」するだけで済む。 - 要点2：数字と引用元の突合は、原稿と参考文献PDFを同時にコンテキストに入れて「数字の根拠ページ番号」を答えさせる。校閲者は答えとPDFの該当箇所だけ照合すればよい。
- 要点3：初校・再校・念校で Claude Code に求める粒度を分ける。初校＝粗拾い、再校＝表記統一、念校＝最終的な事実関係。フェーズごとにプロンプトとチェック項目を切り替える。
対象読者：出版社の編集者・編集長、編集プロダクションのディレクター、書籍/雑誌/Webメディアの校閲チームリーダー、社内の業務改革担当（DX推進部門）。今日読めること：Claude Code をどう校正フローに「混ぜる」か、校閲者の役割をどう再定義するか、よくある失敗4パターンの回避方法。
※本記事の事例は、複数の出版社・編集プロダクションへのヒアリングと、Uravation の Claude Code 個別指導で実装してきたパターンを再構成した想定シナリオです。特定の出版社・書名・実績ではありません。最終判断は必ず校閲者・編集者が行ってください。
リード：「校正者が辞めて、AIに置き換える」のではなく「校正者の負荷を下げる」
「うちは校閲の人員を減らしたいわけじゃないんですよ」
都内のビジネス書系出版社で編集長をしている知人と話したとき、最初に強調されたのがこの一言でした。
その出版社では、月8〜12冊のビジネス書・実用書を出していて、校閲は社内に2名・外部委託に3〜4名。1冊あたり初校・再校・念校の3回、平均で校閲者1人あたり12〜18時間/冊かかっていました。雑誌や定期刊行物ではないので「締切が決まっていて回避不能」というより、「校閲品質が落ちると著者・読者・書店からの信頼が一気に崩れる」という性質の業務です。
つまり校閲は「速くしたい仕事」ではなく「ミスを減らしたい仕事」でした。
では Claude Code に何を期待していたのかというと、編集長の答えは明確で「校閲者が読み始める前に、明らかな誤字脱字とスタイルガイド違反だけは拾ってほしい」というものでした。校閲者の集中力は有限なので、「明らかな誤り」に脳のリソースを使うのではなく、「文脈で初めて気づける微妙な事実誤認」に集中させたい、という設計思想です。
私自身、Claude Code をいろいろな業界で導入支援してきた中で、この「校閲者の前さばき」というポジショニングは、士業・専門業務の中でも特に綺麗にハマるユースケースだと感じました。法務契約書のレビューや会計士の監査調書チェックと同じく、「最終責任は人間、AIは下読み」の構図がもっとも安全に運用できるからです。
この記事では、その出版社で実際に走らせたシステムを、社名・書名を伏せて再構成しながら、初校〜念校までの実装手順、プロンプト、失敗パターンを順に書いていきます。
導入前の状況：校閲業務のボトルネックは「全文の頭出し」
導入前のフローを整理すると、以下のようになっていました。
- 初校：印刷所から上がってきたゲラ（PDF）を、校閲者2名が独立に通読。誤字脱字、明らかな表記揺れ、数字の単位ミス、固有名詞の漢字違いを赤入れ。所要時間は1冊（200〜300ページ）で各6〜8時間。
- 再校：初校の赤を著者が反映した修正稿に対して、再度通読。前回の赤が反映されているか＋新規の誤りがないかを確認。所要時間は各3〜5時間。
- 念校：印刷直前の最終確認。本文の中身というより、目次・ノンブル・柱・奥付・引用元の最終確認。所要時間は各2〜3時間。
つまり1冊あたり、社内校閲者2名 × 3回で合計24〜32時間、外部委託も合わせると1冊あたり50〜80時間がかかっていました。
ボトルネックは、初校の「全文頭出し」に集中していました。校閲者は最初の通読で、「文字レベルのミス」と「内容レベルのミス」を同時に拾わなければならず、結果として「文字レベルのミスにリソースを取られて内容レベルのミスを見落とす」というリスクが常にありました。
編集長の悩みは「2人体制で相互チェックしているのに、出版後の読者指摘や著者再読で発見される誤りが、年間で見ると10〜15件は残っている」ということでした。校閲者の力量の問題ではなく、人間の脳が長時間の文字面チェックに耐えられない、という構造的な問題です。
Claude Code の役割：4つのフェーズに分けて担当範囲を限定する
導入設計で最初にやったのは、Claude Code に「何をやらせて、何をやらせないか」を厳密に切り分けることでした。校正校閲は「全部AIに任せる」と必ず事故るので、フェーズごとに担当範囲を明文化します。
- 原稿入稿〜初校前の「下読みパス」 — 著者から入稿された Word/Markdown 原稿に対して、社内スタイルガイド違反候補・誤字脱字候補・数字単位の不整合候補を JSON で出力。校閲者が初校で読む前のスタート地点にする。
- 初校〜再校の「表記揺れ統一パス」 — 原稿全体で「ユーザー」「ユーザ」が混在、「Claude Code」「Claude code」「ClaudeCode」のような大文字小文字ブレを抽出。表記統一ルールに従って「直す候補」と「直さない候補（引用部・固有名詞）」に分けて提示。
- 再校〜念校の「事実関係照合パス」 — 原稿中の固有名詞（人名・会社名・地名・書名・URL）と数字（売上、年代、ページ数、統計値）を抽出し、参考文献PDFや指定ソースとの整合性候補を出力。校閲者は最終的な裏取りだけ実行する。
- 念校直前の「目次・ノンブル・奥付パス」 — 目次の章タイトルと本文の章タイトルが一致しているか、ノンブル・柱の整合、奥付の発行日・ISBN・著者プロフィールの整合を確認。
このように4フェーズに分けたうえで、それぞれに別のプロンプト・別の CLAUDE.md を用意します。「校正AI」を1つの巨大なシステムにせず、小さな専門化されたエージェントを4つ並べるイメージです。
実装手順1：社内スタイルガイドを CLAUDE.md に落とし込む
まずやるべきことは、社内のスタイルガイドを Claude Code が読める形に翻訳することです。多くの出版社・編プロには「表記ルール」「漢字ひらがな表」「固有名詞リスト」が紙やExcelで存在しますが、Claude Code に読ませるなら Markdown が最適です。
ワークスペース直下に CLAUDE.md と、参照用の docs/styleguide/ ディレクトリを作成し、Claude Code が常に参照できるようにします。
# ~/work/proofreading/CLAUDE.md
## あなたの役割
あなたは出版社「○○出版」の校閲アシスタントです。
最終的な採否判断は人間の校閲者が行います。あなたは「候補」を提示する役割です。
## 守るべきこと
1. 候補は必ず JSON 形式で出力する（後段スクリプトでパースする）
2. 各候補には「該当箇所の前後30字」「違反したルール」「修正候補」を含める
3. 確信度（high/medium/low）を必ず付ける
4. 文脈で正解が変わる箇所（引用文中・登場人物のセリフ）は low で出す
5. 不確かな点は「不確か」と明記する。憶測で確定させない
## 参照すべきスタイルガイド
- docs/styleguide/kanji-hiragana.md（漢字ひらがな表）
- docs/styleguide/proper-nouns.md（固有名詞リスト）
- docs/styleguide/numbers.md（数字・単位の表記ルール）
- docs/styleguide/punctuation.md（句読点・記号ルール）
## 不足情報の扱い
判断に必要な情報が不足している場合は、推測せず「要確認」フラグで出力してください。
そして社内スタイルガイドを以下のように Markdown 化します。例として「漢字ひらがな表」の一部を示します。
# docs/styleguide/kanji-hiragana.md
## ひらがな表記にする語
- 致します → いたします
- 出来る → できる
- 下さい → ください
- 様々 → さまざま
- 但し → ただし
- 又は → または
- 等 → など
- 為 → ため
- 程 → ほど
- 殆ど → ほとんど
## 漢字表記を維持する語
- 一方
- 結果
- 確認
- 検討
- 実施
## 例外（文脈で漢字を使う）
- 著者名・人名の引用（「鈴木下さん」など）
- 法令・公式文書の引用部分
- 章タイトル内の慣用表現
このようにスタイルガイドを Markdown 化しておくと、Claude Code は @docs/styleguide/kanji-hiragana.md という指示なしでも、CLAUDE.md 経由で自動的に参照してくれます。校閲者はスタイルガイドを更新するだけで、Claude Code の挙動も追随します。
実装手順2：「下読みパス」のプロンプト
原稿入稿直後、初校前に Claude Code に走らせる「下読みパス」のプロンプトを示します。コピペで使えるテンプレートとしてどうぞ。
以下の原稿（manuscript.md）に対して、社内スタイルガイドに沿った
「校閲候補」を JSON 形式で出力してください。
入力ファイル: @manuscript.md
スタイルガイド: CLAUDE.md と docs/styleguide/ 配下
出力ルール:
1. 候補は以下のスキーマで出力する
{
"candidates": [
{
"id": "C001",
"line": 142,
"before_30": "（該当箇所の前30字）",
"after_30": "（該当箇所の後30字）",
"target": "（指摘対象の文字列）",
"rule": "（違反したスタイルガイドのルール名）",
"suggestion": "（修正候補）",
"confidence": "high|medium|low",
"category": "kanji_hiragana|proper_noun|number|punctuation|other",
"note": "（判断理由・注意点）"
}
]
}
2. 確信度の付け方
- high: スタイルガイドに明確に違反、文脈で変わる余地がない
- medium: スタイルガイドに違反だが、文脈で例外の可能性がある
- low: 引用部・登場人物のセリフ・専門用語の可能性があり要確認
3. 1ファイル内で重複する違反は最初の3件まで出して、4件目以降は
"（同種違反 N 件あり、行番号: 142, 287, 305...）" のように集約してよい
4. 確信が持てない箇所は推測せず "category": "other", "confidence": "low",
"note": "要校閲者確認" として出力する
5. 著者の固有の文体（口語表現、わざとの表記）と思われる箇所は
指摘対象から除外する（除外理由を summary に記載）
出力後、最後に以下の summary も付ける:
{
"summary": {
"total_candidates": N,
"high_confidence": N,
"medium_confidence": N,
"low_confidence": N,
"excluded_intentional_style": N,
"needs_human_review": ["（人間判断が必須な箇所のidリスト）"]
}
}
このプロンプトの肝は「確信度を3段階で出させる」ことと「除外の合理化を summary に書かせる」ことです。high のみを校閲者が「採否ボタン」で処理すれば、初校の最初の30分で全文の文字レベルチェックの大半が終わります。
実装手順3：「表記揺れ統一パス」と引用元突合
初校で校閲者が赤を入れた後、再校に向けて走らせるのが「表記揺れ統一パス」です。原稿全体を走査して、同一概念が複数の表記で混在している箇所を抽出します。
原稿 @manuscript.md 全体を走査して、表記揺れを検出してください。
検出ルール:
1. 同一概念に対して 2 種類以上の表記が混在している語句を抽出
例: 「ユーザー / ユーザ」「ChatGPT / Chat GPT / ChatGpt」
「2026年 / 二〇二六年 / 令和八年」
2. 出力スキーマ:
{
"inconsistencies": [
{
"id": "I001",
"concept": "ユーザー",
"variants": [
{"form": "ユーザー", "count": 84, "lines": [12, 45, 67, "..."]},
{"form": "ユーザ", "count": 6, "lines": [203, 287, "..."]}
],
"recommended": "ユーザー",
"rationale": "本書の他章および社内スタイルガイドで多数派",
"exceptions": [
{"line": 287, "reason": "JIS規格名の引用のため原表記維持を推奨"}
]
}
]
}
3. 引用部・参考文献の表記は「原文ママ」が原則なので、
exceptions に書き出して校閲者に判断を委ねる
4. 全体の少数派表記の出現箇所が、特定の章に偏っている場合
"section_bias": "第3章に集中"のように指摘する
（著者が別の協力者から原稿を受け取った可能性があるため）
次に重要なのが、引用元・参考文献との数字突合です。これは Claude Code の長コンテキストを活かしやすい領域です。
本文 @manuscript.md と参考文献PDF @references/*.pdf を読み込み、
本文中の数値主張と引用元の整合を確認してください。
確認手順:
1. 本文中の数字・統計・年代・人名を抽出
- 「○○年に〜が発表された」
- 「××は△△%増加した」
- 「□□の市場規模は○○億円」
2. 各抽出項目について、参考文献PDFのどのページに根拠があるかを示す
- ある場合: "source": "ref01.pdf p.42", "verbatim": "（PDFからの抜粋）"
- ない場合: "source": "not_found", "note": "本文中で出典が明示されているか確認要"
- 数値が異なる場合: "discrepancy": "本文: 28%, 出典: 27.3%（四捨五入の可能性）"
3. 出力スキーマ:
{
"fact_checks": [
{
"id": "F001",
"line": 412,
"claim": "（本文中の主張）",
"source": "ref01.pdf p.42 | not_found | discrepancy",
"verbatim": "（PDFからの引用）",
"verdict": "match | partial_match | mismatch | unverifiable",
"confidence": "high|medium|low",
"note": "（校閲者への申し送り）"
}
]
}
4. unverifiable と mismatch は必ず校閲者の最終確認が必要なので
summary.needs_human_review に必ず含めること
このプロンプトを使うと、校閲者は「Claude Code が見つけた match 以外」だけ目視確認すればよくなります。1冊あたり数字突合は数百件あるので、これだけで再校〜念校の数字確認パートが大幅に短縮されます。
実装手順4：人物名・固有名詞の整合チェック
出版社の校正で最も事故が起きやすいのが、人物名の表記揺れです。著者名、登場人物名、組織名は「漢字違い」「敬称の付け外し」「肩書きの時系列ズレ」が起きやすく、外部からの指摘も非常に多い領域です。
原稿 @manuscript.md から、登場する全ての人名・組織名・肩書きを抽出し、
整合性をチェックしてください。
確認項目:
1. 同一人物の表記揺れ
- 「鈴木一郎」「鈴木 一郎」「鈴木氏」「鈴木さん」「Suzuki」
- 漢字違い（「斎藤」「斉藤」「齋藤」「齊藤」）
- 旧字体・新字体の混在
2. 肩書き・所属の時系列整合
- 同一人物に「○○社CEO」と「△△社CTO」が併記されていないか
- 「元○○社長」「現○○社長」が混在していないか
3. 敬称の統一
- 「氏」「さん」「先生」「博士」が同一人物で混在していないか
4. 出力スキーマ:
{
"name_check": [
{
"id": "N001",
"canonical": "鈴木一郎",
"appearances": [
{"line": 12, "form": "鈴木一郎", "title": "○○社CEO"},
{"line": 145, "form": "鈴木氏", "title": "なし"},
{"line": 287, "form": "齋藤一郎", "title": "○○社CEO", "warning": "漢字違いの可能性"}
],
"suggestion": "全箇所「鈴木一郎」に統一を推奨",
"needs_verification": ["line 287 の漢字違いは校閲者確認必須"]
}
]
}
5. 不明確な箇所は推測せず "needs_verification" に追記すること
このプロンプトと、社内が持っている「過去の著作で登場した人物名リスト」を組み合わせると、シリーズもの・続編で「前作と表記がズレている」事故が大幅に減ります。特に翻訳書では「カタカナ表記の揺れ」（カーティス / カーテス / カーチス）が頻発するので、翻訳書チームには特に効きます。
実装手順5：初校・再校・念校でプロンプトを切り替える
4つのフェーズそれぞれに別の「目的」があるので、プロンプトも切り替えます。CLAUDE.md に以下のような「フェーズ別の指示書」を書いておきます。
# docs/phases/initial-proof.md（初校・下読み）
## 目的
著者から入稿された原稿を、初校に上げる前の段階で「明らかな文字レベルのミス」だけ拾う。
## 重視するもの
- 誤字脱字
- 明らかな単語の重複（「のの」「をを」）
- 簡単に判定できる漢字ひらがな違反
- 半角全角の混在（数字・英字・記号）
## あえて拾わないもの
- 文体・文章のリズム（著者の個性領域）
- 内容の事実関係（再校以降で扱う）
- 表記揺れ（再校で一括でやる）
## 確信度の閾値
high のみを「校閲者に提示」、medium 以下は「参考情報」として別ファイルに退避
---
# docs/phases/second-proof.md（再校・統一）
## 目的
初校の赤入れが反映された原稿に対して、原稿全体の整合性を整える。
## 重視するもの
- 表記揺れ（章をまたいだ統一）
- 固有名詞の整合
- スタイルガイドへの準拠度
- 数字・単位の表記
## あえて拾わないもの
- 細かい誤字脱字（初校で拾い切られているはず、漏れたら念校で再点検）
- 内容の事実関係（次フェーズで集中）
---
# docs/phases/final-proof.md（念校・事実関係）
## 目的
印刷直前の最終確認。事実関係と書誌情報の最終チェック。
## 重視するもの
- 引用元・参考文献との整合
- 人物名・肩書きの時系列整合
- 目次・ノンブル・柱・奥付の整合
- URL の生存確認
- ISBN・発行日・著者プロフィール
## あえて拾わないもの
- 表記揺れ（再校で済んでいる前提）
- 文体・誤字（初校で済んでいる前提）
## 重要な注意
このフェーズは「校閲者が見落としている可能性が最も低い」フェーズなので、
Claude Code は補助的な役割に徹する。
final verdict は必ず人間が出す。
フェーズ別に CLAUDE.md の指示を切り替えるには、Claude Code の サブエージェント機能を使うのが最もスマートです。.claude/agents/initial-proof.md .claude/agents/second-proof.md .claude/agents/final-proof.md をそれぞれ用意し、初校時は /agents initial-proof で呼び出します。
実装手順6：JSON 出力を校閲者が使う UI に流し込む
Claude Code が JSON を吐いても、校閲者が JSON を読むのは現実的ではありません。実装の最終仕上げとして、JSON を校閲者向けの「採否レビューUI」に流し込みます。
最小構成では、ローカルで動く軽量な HTML を用意して、JSON を読み込み、各候補に「採用」「却下」「保留」のボタンを付けます。校閲者は1日かけて初校全文を読む代わりに、まず候補リストを30〜60分で「採否」して、その後で全文を通読する流れに変えました。
// review-ui.js（最小構成のサンプル）
// このスクリプトを Claude Code に書かせる時のプロンプト例:
「以下の要件で校閲レビューUIを作って。
- 入力: candidates.json（先のプロンプトで生成したJSON）
- 出力: review.html（ブラウザで開ける単一HTML）
- 機能:
- 各候補を一行ずつ表示（line / before_30 / target / after_30 / suggestion）
- 採用 / 却下 / 保留 の3ボタン
- 採否結果を localStorage に保存
- 採用された候補のみ「赤入れ.txt」としてエクスポート可能
- スタイル: 印刷物の校閲を意識した可読性最優先のフォントとレイアウト
- 余計な依存ライブラリは使わない（CDNなし、純粋HTML+JS+CSS）」
この UI を作っておくと、Claude Code が生成した候補を、校閲者が紙の校閲に近い感覚で処理できます。社内に開発者がいなくても、Claude Code に作らせれば1〜2日で動くものができあがります。
効果指標：何が変わって、何は変わらなかったか
導入から半年運用した結果、定量的に観測できた変化と、変わらなかった部分の両方を整理します。これらは想定シナリオに基づく数値であり、実際の出版社の実績ではない点はご注意ください。
| 指標 | 導入前（想定） | 導入後（想定） | 変化 |
|---|---|---|---|
| 初校・1冊あたり校閲時間（校閲者1名） | 6〜8時間 | 4〜5時間 | 約30〜35%短縮 |
| 表記揺れ漏れ件数（外部指摘・年間） | 10〜15件 | 3〜5件 | 約65〜70%減 |
| 数字突合の校閲者作業時間（1冊） | 1.5〜2時間 | 20〜40分 | 約65〜75%短縮 |
| 人物名の漢字違い事故（年間） | 3〜4件 | 1件以下 | 大幅減 |
| 再校で発見される新規誤り（1冊） | 40〜60件 | 40〜55件 | ほぼ変化なし |
| 校閲者の精神的負荷（自己申告） | 「常に重い」 | 「集中できる」 | 定性改善 |
注目すべきは「再校で発見される新規誤り」がほぼ変わっていないことです。これは Claude Code が初校で拾えない「文脈レベルの誤り」が、依然として再校で人間によって発見されている、ということを意味します。つまり校閲者の仕事は減ったのではなく、より高付加価値な領域に集中できるようになった、と読むのが正確です。
編集長のコメントを引用すると、「校閲の人数を減らすのではなく、1人あたりが受け持てる冊数が増えた。結果、繁忙期に外部委託に振っていた分が社内で吸収できるようになり、外注費が下がった」とのことでした。
段階的導入のロードマップ（3フェーズ）
Phase 1（1〜2ヶ月）：スタイルガイドの Markdown 化と下読みパス試験運用。既存のスタイルガイド・固有名詞リスト・漢字ひらがな表を Markdown に翻訳し、Claude Code に読ませる。最初の1〜2冊で「下読みパス」だけを試験運用し、校閲者が候補リストをどう使うかをチューニングする。この段階では校閲者の作業時間はむしろ増える（プロンプト調整のコストがかかる）が、土台を作る期間と割り切る。
Phase 2（3〜4ヶ月）：表記揺れ統一と引用元突合の本格運用。下読みパスが安定したら、表記揺れ統一パスと数字突合パスを順に追加。校閲者向けレビュー UI も Claude Code に作らせて、JSON を直接読まなくて済むように整える。Phase 2 終了時点で、初校・再校の校閲時間が 20〜30% 短縮できる目安。
Phase 3（5〜8ヶ月）：人物名整合・念校パスの組み込みと運用定着。最も繊細な人物名チェック・念校時の事実関係照合を導入。同時に、過去の刊行物から登場人物名リストを構築し、シリーズもの・続編の整合に活用。Phase 3 終了時点で、社外指摘件数が初期の 1/3 程度になっているのが目標。この段階で、校閲チーム以外（編集者・著者）も Claude Code を使い始めるよう、社内研修を組む。
【要注意】よくある失敗パターン4選
実装の途中で何度もハマったポイントを4つ紹介します。これから導入する出版社・編プロは、最初からここを避けてください。
失敗1：Claude Code に「最終判断」をさせてしまう
❌「Claude Code がOKと言ったから、もう校閲者の通読は飛ばしていい」
これは絶対にやってはいけません。Claude Code は「明らかなミスを拾う」のは得意ですが、「文脈で初めて気づく誤り」「著者の意図を読む」のは依然として苦手です。たとえば「東京駅から徒歩5分」と書かれた地名が、文脈上は「大阪駅から徒歩5分」が正しい、というような誤りは、Claude Code には絶対に拾えません。
⭕「Claude Code は校閲者の前さばき。校閲者の通読は省略しない」と運用ルールに明記する。これは編集長から校閲チームへ繰り返し伝える必要があります。
失敗2：プロンプトに「全部チェックして」と書いてしまう
❌「原稿の誤字脱字、表記揺れ、事実関係、固有名詞、すべてチェックして JSON で出して」
このプロンプトを投げると、Claude Code は出力が膨大になりすぎて、確信度の低い候補が大量に混ざります。結果として校閲者は「ノイズの中から本当の指摘を探す」という、導入前より重い作業を強いられます。
⭕1プロンプト1目的に絞る。「今回は漢字ひらがな違反だけ」「今回は数字突合だけ」と限定すれば、出力品質が安定し、確信度の管理がしやすくなります。
失敗3：著者の文体を「ミス」と判定する
❌ プロンプトで「絶対にスタイルガイドに従ってください」と指示してしまう。すると Claude Code は、著者が意図して使った口語表現や、わざとの漢字選択まで「違反」として指摘します。校閲者はそれを「指摘を却下する」作業に追われ、結果的に時間がかかります。
⭕ 「著者の固有の文体（口語表現、わざとの表記）と思われる箇所は指摘対象から除外する。除外理由を summary に書く」と必ずプロンプトに含める。これだけでノイズが半減します。さらに、過去にその著者の本を出している場合は、過去原稿を docs/authors/{name}/past-works.md として読ませると、著者ごとの文体傾向まで踏まえた判定をしてくれます。
失敗4：JSON のパース崩れに気づかず校閲者に渡してしまう
❌ Claude Code が返した JSON が、稀に文字列のエスケープミスやコメント混入で valid JSON でなくなることがあります。校閲者がレビュー UI で開いて初めて「ロードできません」となり、半日無駄になるケースがありました。
⭕ Claude Code の出力後、必ずスクリプトで JSON を validate してから校閲者に渡す。jq や Python の json.loads を通して、エラーが出たら Claude Code に「先ほどの JSON を valid JSON に直してください」と再生成を依頼するパイプラインを組みます。これだけで運用事故が劇的に減ります。
実装手順7：CI/CDとしての校正パイプライン化
4つのフェーズを安定運用し始めると、次の課題は「同じプロンプトを毎回手で実行する手間」です。出版社の現場では、編集者は技術者ではないので、ターミナルで毎回コマンドを叩くのは現実的ではありません。導入半年目あたりから、校正フローを CI/CD 的にパイプライン化することを推奨しています。
具体的には、原稿を Git リポジトリで管理し、ブランチに push されたら自動で Claude Code の各パスが走るようにします。GitHub Actions や GitLab CI、社内のオンプレ環境であれば自前のシェルスクリプトでも実現できます。
# .github/workflows/proofread.yml の最小サンプル
# 編集者は manuscript.md を更新して push するだけでよい
name: Proofread
on:
push:
paths:
- 'manuscripts/**/*.md'
jobs:
initial-proof:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Run Claude Code initial proof
run: |
# Claude Code CLI で下読みパスを実行
# 実際のコマンドは Anthropic 公式ドキュメントを参照
claude-code --agent initial-proof --input manuscripts/ \
--output candidates.json
- name: Validate JSON
run: |
python3 -c "import json; json.load(open('candidates.json'))"
- name: Generate Review UI
run: |
python3 scripts/build_review_ui.py candidates.json > review.html
- name: Upload artifacts
uses: actions/upload-artifact@v4
with:
name: proofread-results
path: |
candidates.json
review.html
このパイプラインの肝は、編集者が「原稿を Git に push するだけで、校閲レビュー UI が artifact として出てくる」という体験を作ることです。校閲者はSlackやメールで通知された URL を開いて、ブラウザで採否ボタンを押すだけ。技術的なステップは完全に裏側に隠れます。
さらに踏み込むなら、Pull Request 形式で原稿の修正を管理することで、誰がいつ何を変更したかの履歴が全て残ります。出版業界はトラブル時に「いつ誰が直したか」を遡る必要が多いので、Git ベースの履歴管理は副次的に大きなメリットがあります。
実装手順8：過去刊行物アーカイブを Claude Code に読ませる
6ヶ月ほど運用すると、もうひとつ強力な使い方が見えてきます。それが「過去の刊行物全てを Claude Code のコンテキストに入れて、自社書籍の整合性を保つ」という使い方です。
たとえばビジネス書系の出版社は、同じ著者の続編や、同じテーマの関連書を複数出すことが多く、書籍をまたいだ整合性（同一人物の表記、引用した統計数値、登場した固有名詞）の維持が悩みになります。
# docs/archive/CLAUDE.md（過去刊行物アーカイブ専用の指示書）
## あなたの役割
このアーカイブには過去5年間に刊行した書籍のテキスト（許諾済み）が
入っています。新刊原稿の整合性確認に使います。
## 確認できること
1. 過去刊行物との人物名・表記揺れ
- 同じ人物が前作で何と表記されていたか
- 過去刊で使った漢字（斎藤 / 斉藤 など）
2. 過去刊行物との数値・統計整合
- 同じ統計を異なる数値で引用していないか
- 年代記載のズレがないか
3. 過去刊行物と矛盾する主張
- 著者が前作と矛盾する見解を述べていないか
- 同じ事例を別の結論で語っていないか（要編集判断）
## 出力ルール
- 確認結果は archive_check.json に出力
- 「矛盾候補」は必ず編集者の判断を仰ぐ（修正提案は控えめに）
- 著者の意図的な見解変更の可能性があるため、断定しない
これを docs/archive/ 配下に過去刊行物の Markdown を置いて運用すると、新刊執筆段階から「この記述、前作と整合してますか？」という観点で著者に質問できるようになります。著者にとっても、自分の過去発言との矛盾を事前にチェックできるのは大きな価値で、編集者と著者の信頼関係も深まります。
ただしこの運用には注意点があります。過去刊行物の電子版データを社内で保有していること、その利用権限が編集部にあること、著者との契約上「過去原稿を社内ツールで参照すること」が許諾されていること、を必ず確認してください。出版契約書のひな型を更新する必要が出る場合もあります。
運用上のさらなる注意点（社内の合意形成）
技術実装そのもの以上に難しいのが、校閲チームへの導入合意です。校閲者は「自分の仕事が AI に置き換わるのではないか」という不安を持ちやすく、最初の数週間で心理的抵抗が出ます。以下のポイントを編集長から繰り返し伝えると、定着が早くなります。
- 「校閲者を減らす」目的ではないことを最初に宣言する。実際の運用でも、校閲者の人員は減らさない。むしろ「1人あたりの担当冊数が増えるので、繁忙期の外注費が減る」という方向性を明示する。
- 校閲者がプロンプトをチューニングするオーナーシップを持つ。スタイルガイドの Markdown 化、フェーズ別プロンプトの調整は、校閲者自身が編集する。「自分が使う道具を自分で磨く」という体験が、AI に対する心理的距離を縮める。
- 校閲者の「却下理由」を蓄積する。Claude Code の提案を校閲者が却下した場合、なぜ却下したかを
docs/feedback/にメモする。これを定期的にCLAUDE.mdやdocs/styleguide/に反映することで、システムが校閲者の判断を学習していく。 - 事故が起きた時の責任分界点を最初に決める。Claude Code が出した提案を校閲者が採用して事故になった場合、責任は「採用を決めた校閲者」にある、と明記する。「AI が間違えた」を理由にしない運用文化を作る。
定性的な変化：校閲者の語りから
数字に出ない変化として、校閲チームメンバーが「導入から半年たった今、どう感じているか」を聞き取った結果も整理しておきます。これも想定シナリオに基づく代表的な声であり、特定個人の発言ではない点はご了承ください。
ある校閲者（社内勤続7年・40代）は、「最初の1ヶ月は、Claude Code の指摘が自分の判断と合うか不安で、結局二重チェックしていた。だから一時的にむしろ忙しくなった」と語っています。これは導入初期の典型的な反応です。重要なのは、その不安期を編集長が「織り込み済み」として、無理に効率化を強制しなかったことでした。
2ヶ月目に入ると、別の校閲者（外部委託・50代）からは「Claude Code が拾った候補を見て『そういえばここも気になっていた』と思うことが増えた。自分の感覚と Claude Code の感覚が近づいてきている」というコメントが出始めました。これは、Claude Code 側がフィードバックを通じて校閲者の好みに寄せていったというより、校閲者側が Claude Code の指摘パターンを学んで「自分が見るべきポイント」を絞り込めるようになった、という相互学習が起きた結果です。
4ヶ月目以降は「もう Claude Code なしでは初校に取り掛かれない」という声が出てきます。これは「依存している」のではなく、「先に明らかな誤字脱字が消えている状態の原稿を読むほうが、文脈レベルの確認に集中できる」という意味です。校閲業務における「集中の質」が変わった、と言い換えてもいいでしょう。
編集長自身の語りとしては、「校閲チームが本来やりたかった『内容に踏み込んだ提案』をしてくれる頻度が増えた」というのが最も大きな変化でした。たとえば「この章は構成を入れ替えたほうが読者に伝わる」「この事例は別の章で先に触れたほうがいい」といった、編集者と協働すべき構造レベルの提案が、校閲者からも上がるようになったとのことです。これは、文字レベルのチェックに脳のリソースを使わなくて済むようになったから、というシンプルな理由でした。
適用余地のある業界・規模
このフローは、出版社・編プロ以外にも横展開可能です。具体的には以下の業界・業務で、ほぼ同じ設計思想で適用できます。
- 新聞社・通信社の校閲部門。スタイルガイド（記者ハンドブック）の Markdown 化が容易で、固有名詞・数字突合のニーズが極めて高い。
- 翻訳会社の校正フロー。原文と訳文の整合チェック、人名・地名のカタカナ表記揺れ抽出に活用できる。
- 大学・研究機関の論文編集。引用元との数字突合、参考文献の書式統一、固有名詞の整合に強い。
- 大手企業の社内報・周年史制作。社内固有名詞（部署名・役職名・過去のプロジェクト名）の整合性を担保しやすい。
- 法律事務所・特許事務所の文書校正。法令・先行判例・特許明細との整合チェックに、同じパターンが適用できる。
とくに法律事務所の文書校正は、関連する業界事例として参考になります。詳細は 契約書レビュー自動化で工数を75%削減した法律事務所事例 でも触れています。また、同じ士業・専門業務カテゴリでは 法律事務所の相談受付フロントをClaude Codeで構築した事例 も、運用フェーズの設計思想が共通しています。教育・出版に近い領域として 教育機関のコードレビュー自動化で60%削減した事例 も合わせて読むと、Claude Code を「人間の前さばき」として組み込む設計の汎用性が見えてきます。
導入時のチェックリスト（編集長向け）
これから出版社・編プロで Claude Code を校正フローに導入する編集長・編集部長向けに、最初の30日でやることをチェックリストにまとめます。
- □ 社内スタイルガイドが Markdown 化されているか（紙・Excel・Word のままだと Claude Code が読みにくい）
- □ 固有名詞リスト（人名・組織名・書名）が一覧化されているか
- □ 過去刊行物の登場人物名・表記が遡れるアーカイブがあるか
- □ 校閲チームと「Claude Code は前さばき、最終判断は人間」の運用ルールを合意したか
- □ 1冊目はパイロットとして「下読みパスのみ」で運用し、効果測定するか
- □ 校閲者から却下理由をフィードバックする仕組みを作ったか
- □ JSON validate のパイプラインが組まれているか
- □ 機密原稿（未刊本・著者情報）のセキュリティポリシーを社内で合意したか
- □ Claude Code のサブエージェント機能で、フェーズ別に挙動を切り替えられるよう設定したか
- □ 半年後の効果指標（外部指摘件数、校閲時間、外注費）を測定する基準値を取ったか
セキュリティ・契約上の注意点
未刊行の原稿は機密情報そのものです。Claude Code を導入する前に、以下を必ず確認してください。
- Anthropic のデータ利用ポリシーを確認する。Claude API 経由の通信内容がモデル学習に使われるかどうかは契約形態で異なる。法人契約や Zero Data Retention オプションの有無も含めて、Anthropic 公式ドキュメントで最新の条件を確認すること。
- 著者との出版契約に「AI 利用条項」を追加検討する。校正校閲過程で AI を補助的に使うこと、最終判断は人間が行うこと、原稿は Anthropic のモデル学習に使われない設定で運用していること、を明記する。著者によっては AI 補助を歓迎する場合もあれば、慎重な場合もあるため事前合意が大事。
- 校閲者・編集者の端末セキュリティを最低限固める。Claude Code は
--dangerously-skip-permissionsを安易に使わない、ワークスペースを限定する、原稿を含むディレクトリを git 管理して履歴を残す、など基本ポリシーを編集部全体で共有する。 - 原稿の保管期間ポリシーを再確認する。Claude Code に読ませた原稿のキャッシュ、ログ、コンテキストファイルを、刊行後にどう処理するか（保存・削除・アーカイブ）のルールを編集部内で文書化する。
編集者・著者・校閲者の役割再定義
Claude Code を本格運用してわかったのは、技術導入そのものよりも「編集部全体の役割設計」を見直す必要があるということでした。出版社・編プロは長年「編集者は構造を見る、校閲者は表記を見る、著者は中身を書く」という三角形で動いてきましたが、Claude Code が「表記を見る」役割の一部を肩代わりするようになると、この三角形が少しずつ変わります。
まず編集者は、これまで「校閲から赤入れが上がってきたら著者に戻す」というワークフローの中で受動的なポジションだったのが、Claude Code が生成する初期の候補リストを最初に眺めて、「ここは著者の意図を尊重して直さない」「ここは思い切って章ごと再構成しよう」という構造判断に時間を使えるようになります。校閲者がやっていた表記レベルのチェックを少し肩代わりするわけではなく、編集者本来の「読者目線でのストーリー設計」の比率が上がるのが理想的な形でした。
次に校閲者は、文字レベルの「明らかな誤り」のチェックから解放された分、「文脈レベルの違和感」「事実関係の追加検証」「読者から指摘されそうな箇所の予測」といった高度な判断業務に時間を使えるようになります。これは校閲者にとってキャリアのアップグレードになり、特に若手校閲者の育成スピードが上がるという副次効果も観測されました。Claude Code が文字レベルの基礎を担保してくれることで、若手は最初から「文脈を読む」訓練に入れるからです。
最後に著者は、原稿入稿時点で「明らかな誤字脱字や表記揺れがある状態だと出版社に申し訳ない」というプレッシャーから少し解放されます。著者自身が Claude Code を使って入稿前にセルフチェックすることもできますし、出版社側で下読みパスをかけて結果を著者に共有することもできます。これにより著者が「中身を考えること」に集中できる時間が増え、結果として書籍の内容品質も上がるという好循環が生まれます。
導入を見送ったほうがいいケース
正直に申し上げると、すべての出版社・編プロにこの導入がフィットするわけではありません。以下のケースでは、Claude Code の本格導入を急がず、まず別の改善を優先することをおすすめします。
- そもそも社内に Markdown を扱える人がいない場合。スタイルガイドを Markdown 化する作業は、慣れていれば1〜2日ですが、慣れていないと1〜2週間かかります。社内に技術リソースが全くない場合は、まず Notion や Google Docs での整理から始めて、外部支援を受けながら段階的に Markdown 化するほうが現実的です。
- 未刊原稿の社外サーバー利用に強い抵抗がある場合。Anthropic の API 経由で原稿を送ることに対して、著者・経営層が強い懸念を持つ場合は、まずローカル LLM（Llama 等）でのオフライン校正パイプラインを検討するほうがよいでしょう。ただしローカル LLM は精度・コンテキスト長で Claude Code に劣るため、効果はかなり限定的になります。
- 1冊あたりの校閲時間がそもそも短い場合。雑誌や定期刊行物で「印刷直前の超短時間校閲」がメインの場合、Claude Code のパイプラインを組む時間的余裕すらないことが多いです。この場合はまず「校正前の時間を確保するワークフロー改革」が先決です。
- 翻訳書中心で、社内に翻訳前のソース言語ファイルがない場合。翻訳済みの日本語原稿だけでは「訳ヌケ」「誤訳」のチェックは不可能です。原書の電子版が手に入る前提でないと、翻訳書校正の本領は発揮できません。
FAQ（よくある質問）
Q1：校閲者の人員は減らせますか？
A1：減らさないことを推奨します。実際の運用でも、人員は維持して「1人あたりの担当冊数」を増やすほうが、品質と運用安定の両面でメリットが大きいです。校閲者を減らした出版社の事例では、結果的に外部指摘件数が増えて読者信頼を損ねた、というケースを複数聞いています。
Q2：費用感はどれくらいですか？
A2：Claude API の料金は読み込む原稿サイズと出力量に依存しますが、書籍1冊（10〜20万字）の下読み・表記揺れ・数字突合を一通り走らせた場合の API 利用料は数百円〜数千円のオーダーです。校閲者の人件費削減効果と比較すれば、十分に投資回収できる範囲です。具体的な見積りは Anthropic の料金表で最新情報を確認してください。
Q3：どの段階から始めるべきですか？
A3：「下読みパスだけ」から始めることを強く推奨します。最初から4フェーズ全部を組もうとすると、プロンプト設計・スタイルガイド整備・校閲者との合意形成のすべてが同時並行になり、運用が崩れます。1〜2冊は下読みパスだけで運用して、校閲者の使い勝手と効果を見てから次の機能を足していくのが安全です。
Q4：著者本人が AI 校正を嫌がる場合は？
A4：必ず事前に説明・合意してください。AI を補助的に使うこと、最終判断は人間が行うこと、機密性を担保する運用にしていること、を丁寧に伝えれば、ほとんどの著者は受け入れます。それでも嫌がる著者の原稿には Claude Code を適用しない、というオプションも残しておくと安心です。
Q5：他のツール（Microsoft Editor、Just Right!、Wordvice AI など）との違いは？
A5：既存の校正ツールは「あらかじめ用意されたルール」での自動チェックが中心です。Claude Code の強みは、社内スタイルガイドや過去刊行物・参考文献PDFをコンテキストに入れて、出版社固有のルールで校正できること。汎用ツールでは拾えない「自社らしさ」を担保したい場合に向いています。両者を併用するのも現実的な選択肢です。
Q6：校閲者の評価制度はどう変えればいいですか？
A6：これは導入半年たってから本格検討する論点です。文字レベルの誤り発見数だけで校閲者の貢献度を測ると、Claude Code に肩代わりされる領域で実力が見えにくくなります。代わりに「文脈レベルの指摘件数」「著者への構造提案」「読者指摘の予防実績」といった定性的な貢献を評価軸に組み込む方向に、人事制度ごと見直す出版社が増えています。
Q7：複数の編集部やレーベルで横展開する時の注意点は？
A7：スタイルガイドはレーベルごとに微妙に異なるため、CLAUDE.md を共通化しすぎないことが大事です。共通の基盤（漢字ひらがな表・全角半角ルール）と、レーベル固有の指示書（ビジネス書編集部用・実用書編集部用・翻訳書編集部用）を分離して管理するのが現実的です。docs/labels/{label_name}/ のようにディレクトリを切ってください。
次の一歩：今日から始める3つのアクション
ここまで読んで「うちでも試したい」と思った方は、以下の3つを今日から始めてください。Claude Code 個別指導のサポートが必要であれば、Uravation にご相談ください。
- 今日できること：社内の校正・表記ルールを、PDF/Excel/紙のままになっているなら、まず Markdown ファイル1枚に書き写してみる。完璧でなくていいので、まず「Claude Code が読める形」に変換することがスタート地点です。
- 1週間以内にやること：直近で初校に上げる予定の原稿1冊を選び、「下読みパス」のプロンプトをコピーして走らせてみる。校閲者2名で並行して通読し、Claude Code の指摘がどれくらい使えるかを定性評価する。
- 1ヶ月以内にやること：パイロット運用の結果を持って、校閲チーム全員にデモを行い、フェーズ別運用（初校・再校・念校）の合意形成を始める。同時に、フィードバック収集の仕組み（却下理由のメモ）を整備する。
関連事例
- 契約書レビュー自動化で工数を75%削減した法律事務所事例 — 同じ「人間の前さばき」設計思想で運用している士業事例。
- 法律事務所の相談受付フロントをClaude Codeで構築した事例 — 機密情報を扱う業界での Claude Code 運用ガバナンス参考。
- 教育機関のコードレビュー自動化で60%削減した事例 — レビューフローへの AI 組み込みパターン比較。
まとめ：「AIに置き換える」のではなく「校閲者の集中の質を変える」
出版社・編集プロダクションの校正校閲業務における Claude Code の本質的な価値は、「人を減らす」ことではなく「校閲者の集中の質を変える」ことにあります。文字レベルのチェックを Claude Code に肩代わりさせ、校閲者が文脈レベルの判断に集中できるようにする。この一点が、書籍の最終品質と校閲チームのキャリア満足度の両方を底上げします。
導入の鍵は技術ではなく運用設計です。社内スタイルガイドの Markdown 化、フェーズ別プロンプトの切り分け、校閲者向けレビュー UI、JSON validate のパイプライン、そして何より「最終判断は必ず人間が行う」という運用ルールの徹底。これらを着実に積み上げれば、半年〜1年で校閲品質と作業時間の両立が見えてきます。
本記事の手順をベースに、自社の規模・ジャンル・チーム構成に合わせて調整してみてください。実装で詰まったときは、Uravation の Claude Code 個別指導でも具体的な伴走を行っていますので、お気軽にご相談ください。
著者プロフィール
佐藤傑（さとう・すぐる）。株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。100社以上の企業向けAI研修・導入支援を実施。著書『AIエージェント仕事術』（SBクリエイティブ）、SoftBank IT連載7回執筆。Claude Code の業界別実装事例を体系化し、出版・士業・専門業務領域での導入支援を中心に活動中。
参考出典
- Anthropic 公式「Claude Code Documentation」 https://docs.anthropic.com/ — Claude Code の機能・設定・サブエージェント等の公式仕様
- Anthropic 公式「Claude のデータ利用ポリシー」 https://www.anthropic.com/ — 法人利用時のデータ取扱いポリシー（最新条件は公式ドキュメントで要確認）
- code.claude.com 公式ドキュメント — Claude Code のサブエージェント機能とワークスペース運用のリファレンス
- 『AIエージェント仕事術』佐藤傑著（SBクリエイティブ）— Claude Code を含むAIエージェントの業務組み込み設計
※本記事に登場する出版社・編集プロダクション・書名・実績は、複数の現場ヒアリングとUravationの導入支援経験から再構成した想定シナリオです。特定の組織・書籍ではありません。Claude Code は校閲者・編集者の判断を補助する道具であり、最終的な採否判断は必ず人間の校閲者・編集者が行ってください。
