AI校正を業務に入れる設計。社内文書のルールを人の修正で育てる

AI校正を業務に入れる設計とは、社内文書・記事・提案書の校正を、コードで検査する項目・AIに判断させる項目・人が直す項目の3層に分け、人が直した差分から校正ルールを育てる仕組みのことです。ツールを選ぶのは、この3層を決めた後です。

僕はAIVESTという会社を経営しながら、自分でも手を動かして、AIに文章を書かせる仕組みを設計しています。このブログの記事はAIが書いた原稿が公開前に必ず機械の検査を通り、僕が直した箇所は記録されて、翌日以降のルールになります。

2026年9月時点で「AI 校正」を検索すると、上位はツールのおすすめ・比較・無料一覧と、コピペ用のプロンプト集で埋まっています。この記事はそこに無い「自社の文書で何をコードで止め、何をAIに読ませ、何を人が直すか」と「直した箇所をどう校正ルールに変えるか」を、自社で毎日回している校正の現物で埋めます。

AI校正を業務に入れるとは。AI文章校正ツールを選ぶ前に決める3層

校正の3層の中身

校正とは、文書を公開・提出する前に、表記・用語・数字・禁止語・トーンを自社の基準に揃える作業です。AI文章校正、文章校正AIと呼ばれるツールは、この作業の一部をAIが担うものです。

問題は「一部」がどこかを、ツール側は決めてくれないことです。僕は校正を次の3層に分けています。

• コードで検査する層: 禁止語・表記・数字の出所・内部情報の露出・形式。同じ文書を入れれば毎回同じ結果を返す検査で、AIには判定させない

• AIに判断させる層: 読みやすさ・論旨のつながり・トーン。合否ではなく「指摘」を返させる

• 人が直す層: 検査と指摘が通った後に残る違和感。直した箇所は記録し、ルールに昇格させる

校正のうち、判断が要らない照合はコードへ、判断が要る読みは AIへ、最後の違和感は人へ。この振り分けが決まっていないと、どのツールを入れても「AIが直しすぎる」か「人が全部見直す」のどちらかになります。

順番はツール選びより前

上位の解説記事には、校正ツールを「ルールに従って機械的に直す型」と「生成AIが文脈を読んで直す型」に分ける整理があります。分類として正しいのですが、それはツールの型分けであって、自社のルールを機械にする話ではありません。

ツールの型を選ぶ前に、自社の文書のどの項目が照合で済み、どの項目に判断が要るかを決める。この順番が逆になると、ツールの出力を人が毎回見直す体制に戻ります。

なぜAI校正ツールを比較する前に、自社の校正基準が要るのか

基準がないと「直しすぎ」を止められない

AIに「校正して」と頼むと、AIは頼まれた範囲を全部直します。何を直してはいけないかが決まっていないと、書き手の主張、固有名詞、数字の言い回しまで書き換えられます。

直しすぎを止めるのは、ツールの性能ではなく、自社の基準です。「ここは触るな」を先に書いた文書だけが、AI校正を業務に入れられます。

基準がないとツールの合否を判定できない

無料ツールで足りるか、有料ツールが要るかは、自社の基準を当てて初めて分かります。基準がない状態でツールを比較すると、比較の物差しが「なんとなく良さそう」になります。

Xでも、AIにチェックさせる難しさは「AIに何の観点でチェックさせるべきかを、人間が理解しているか」だという指摘が出ていました（出典節）。観点を先に持つのは、ツールの前です。

何をコードで検査するのか。禁止語・表記・数字の出所・内部露出・形式

判断が要らない項目はAIに判定させない

コードで検査する、とは「同じ文書を入れれば、誰がいつ実行しても同じ結果を返す検査」を作ることです。禁止語が入っているか、タイトルが32字以内か、段落が4文以上あるか。これらは判断ではなく照合です。

照合をAIに頼むと、日によって結果が変わります。「今回は文脈的に問題ないと思います」と言われた瞬間に、基準は基準でなくなります。

検査にAIが「これは大丈夫そうです」と言う余地を残した瞬間、基準は緩みます。禁止語が入っているかどうかは判断ではなく照合なので、僕は照合を全部コード側に寄せています。

自社の公開前の機械ゲート

このブログの全記事は、公開前に機械の検査を通ります。検査の分類は12で、形式の下限（タイトル字数・要約文の字数・本文量・見出し数・FAQか手順の有無・URLの形式）、リンクと画像（内部リンク・画像の枚数と表示確認・許可外リンク）、計測の担保、安全に関わる検査に分かれます。

規約には「基準の緩和禁止」と書いてあります。落ちたら公開できず、人が緩めることもできません。ゲートの設計そのものは、別の記事で作り方まで書いています。

関連記事AI記事作成の品質管理——公開前に自動で守る機械ゲートの作り方AIに記事を書かせたいが品質が心配で任せきれない。その答えは人力チェックの強化ではなく、公開前に自動で合否を判定する機械ゲートです。僕のブログ全記事が通っている検査項目の実物と作り方5ステップを公開します。→

僕の修正から生まれた検査19ブロック

もう1つ、X向けの記事には、僕のフィードバック1件ずつを機械検査に変換した検査があります。2026年9月時点で19ブロック。中身は次のような項目です。

• 全角ダーシの使用、太字の閉じ忘れ、絵文字の混入

• 実態と違う会社規模の自称表現、セキュリティの内側の記述

• 別ツール由来の数字の混入、1段落4文以上の改行密度

• 出典の有無、冒頭25%以内にビジュアルがあるか

• 独立した採点を通していない記事、図解の無い記事は投入できない

どれも最初は僕が口頭で直していた指摘でした。同じ指摘を2回したら、機械が照合できる1文に言い換えて検査に足す。この規約で、口頭の指摘が検査に変わっていきます。

数字の出所と内部露出も校正項目にする

上位の解説記事が扱う校正は、誤字脱字・表記ゆれ・敬語・トーンまでです。僕はそこに「未計測の数字」「内部のファイル名や管理番号」「許可外リンク」を足しています。

社内文書がそのまま外に出る時代に、校正で止めるべきは誤字より数字と内部情報です。この記事自身も、書いてよい数字は照合済みのものだけ、内部のファイル名は書かない、という拘束の下で書かれています。

何をAIに判断させるのか。読みやすさ・論旨・トーンだけ

AIに渡す3つ

コードで照合できない項目だけをAIに渡します。渡すのは次の3つです。

• 読みやすさ: 1文が長すぎないか、段落が壁になっていないか

• 論旨: 主張と根拠がつながっているか、見出しと本文がずれていないか

• トーン: 読者との距離が適切か、敬語に過不足がないか

渡し方は「直して」ではなく「指摘して」です。AIには直す権限ではなく、指摘する権限だけを渡します。

指摘は合否の二値で返させ、根拠の文を逐語で引用させます。指示の書き方はAIに仕事を任せるプロンプトの設計にまとめてあります。

AIに渡さないもの

事実の正誤はAIの校正には渡しません。固有名詞や数字の書き換えも渡しません。AIが自信を持って間違える典型がここに集まるからです。

事実の検証は校正とは別の仕組みで扱っていて、生成AIのハルシネーション対策に書きました。禁止語の判定はコードの仕事、文体の最終判断は人の仕事なので、どちらもAIには渡しません。

誰が直すのか。書き手と検査者を分ける

自分の出力を自分で審査させない

書いたAIに「自分で見直して」と頼むと、甘くなります。書いた本人が自分の原稿を校正しても誤字が残るのと同じです。

僕は書き手と検査役を別の文脈に置いています。検査役は経緯を知らない担当として原稿を受け取り、合否の二値と証拠の逐語引用だけを返します。

既定は却下で、通す理由を証拠付きで出せた項目だけが通ります。この分離の設計はマルチエージェントを業務で使う設計で1本にまとめました。

別系統のAIを併走させる

2026年9月6日から、設計や仕様のレビューは別系統のAIを併走させる規約にしています。自社の規約の該当箇所はこうです。

どちらか一方でもP0（公開を止める重大指摘）を出したら差し戻し。両者の指摘を突合し、両者一致、片方のみ、矛盾を明示して報告する。

片方が通しても、もう片方が止めたら止まる。検査役を1体にすると、その1体の癖が基準になります。

人が直すのは最後の違和感だけ

コードの照合と、AIの指摘を通った後に残った違和感だけを人が直します。全文を見直すのではなく、残ったものだけを見る。人の校正時間が短くなるのは、AIが速いからではなく、人の前に2層あるからです。

人の修正差分から校正ルールを育てる手順

添削の記録の実数

ここが、上位の解説記事に空白か1文しかない部分です。僕は公開版と生成版を文単位で突き合わせ、変更・削除・追加に分けて記録しています。

2026年8月に公開したX向けの記事1本では、生成版127文に対して公開版125文、一致118文（93%）、変更6・削除3・追加1でした。変更の中身は、比喩を読者の利得の言葉に置き換えた、番号を振るためだけの短文を削った、注記の位置を変えた、という種類のものです。

この添削の記録は2026年9月時点で6本あります。記録から蒸留した文体ルールは、僕の修正ログ141件が元になっています（2026年9月7日時点）。

昇格の5段

この手順は、AI運用の事故をチェック項目に変える手順の校正版です。事故ではなく人の修正を燃料にする点だけが違います。事故側の手順はAI運用の再発防止を仕組み化に書きました。

止める基準は緩めない。AI校正が形骸化する3つの兆候

兆候1: 止まったときに基準を下げる

検査で止まると「今回だけ通してほしい」という圧力がかかります。ここで基準を下げると、次からは検査ではなく相談になります。

僕は規約に「基準の緩和禁止」と書いています。緩めるなら、人がルールを改定して日付を残してから緩める。止める基準は、止まった回数ではなく、人が改定した記録だけで変わります。

兆候2: 検査を人が飛ばす

検査を実行するかどうかが人の判断に委ねられていると、忙しい日に飛びます。投入前に必ず実行し、不合格なら投入しない、という順序を手順そのものに固定します。

飛ばせる検査は、存在しない検査と同じです。検査は「やる」ものではなく「通らないと次に進めない」ものとして置きます。

兆候3: AIに文体を覚えさせて、校正ルールを持たない

2026年9月時点で、ChatGPT Workが書き手の文体を学習する機能を発表しています（出典節）。書き手らしさをAIが寄せてくれるのは、AIに判断させる層の精度を上げる話です。

文体を寄せることと、禁止語・数字・内部情報を機械で止めることは別の仕事です。文体学習があっても、コードで止める層と人が直す層は消えません。この機能を自社で計測した実績はないので、使い勝手については書きません。

AI校正のよくある質問

まとめ。3層に分けて、人の修正で育てる

AI校正を業務に入れる設計を、順番どおりに並べます。

1. 校正基準を4項目書き出す。禁止語、表記、数字の出所、人しか変えられない項目

2. 3層に振り分ける。照合はコード、読みはAI、最後の違和感は人

3. 書き手と検査役を分け、別系統のAIを併走させる

4. 公開版と生成版を文単位で突き合わせ、修正差分を記録する

5. 繰り返した修正を検査に昇格させ、人だけが変えられるルールを凍結する

6. 止める基準は緩めない。緩めるなら人が改定して記録する

ツールの比較は、この6つが決まってからで間に合います。自社の文書でどこを機械に止めさせ、どこを人が直すかを一緒に設計したい場合は、お問い合わせからご連絡ください。校正基準づくりの伴走はAI顧問サービスで承っています。

付録。校正基準の雛形と3層の振り分け表

出典

線引きを先に書きます。校正を「コードで検査・AIに判断させる・人が直す」の3層に分ける振り分け、人の修正差分を文単位で記録して検査に昇格させる手順、書き手と検査役の分離と別系統AIの併走、止める基準を緩めない規約は、僕の発明部分です。

本文の実数（機械ゲートの分類12、修正由来の検査19ブロック、生成版127文から公開版125文の添削記録、添削記録6本、修正ログ141件）は、僕の自社運用の記録（公開前の検査の規約、記事の検査、添削の記録、文体ルールの蒸留記録、レビューの規約。いずれも社内記録・2026年9月時点）に基づく一次情報です。借りた部分は次のとおりです。

• 校正ツールを「ルールに従って機械的に直す型」と「生成AIが文脈を読んで直す型」に分ける用語は、koromoの校正ガイド（2026年6月21日公開・リンクは省略・2026年9月8日確認）の整理を借りました。本記事はツールの型分けではなく、自社ルールの機械化に絞りました

• 法人で校正を運用するときの「対象文書・禁止事項・最終承認者」の整理と、AIが一次・人が二次という分担は、Uravationの社内文書校正ガイド（2026年9月5日更新）とAI経営総合研究所の校正ガイド（2025年10月18日公開）の整理を借りました（いずれもリンクは省略・2026年9月8日確認）。本記事は分担の境界と修正差分の昇格手順を足しました

• 校正ルールをAIエージェントの設定ファイルに書く発想は、genai-aiの文章校正AI比較（2026年9月1日更新・リンクは省略・2026年9月8日確認）に整理があります。本記事は「設定に全部書く」のではなく、照合はコードに分ける立場です

• 表記ゆれの分類は、CBT-Solutionsの表記ゆれ解説（2026年3月14日公開・リンクは省略・2026年9月8日確認）を参照しました。本記事は分類より「誰が改定するか」に絞りました

• ツール比較の観点は、アスピックのAI校正ツール紹介（2025年10月22日公開・リンクは省略・2026年9月8日確認）を参照しました。本記事はツール名ごとの優劣を扱っていません

• ChatGPT Workの文体学習機能: @ChatGPT の投稿 https://x.com/ChatGPT/status/2097018264048251309 （2026年9月8日確認）。機能の発表として引用し、自社での実測はありません

• @ai_security_CT の投稿 https://x.com/ai_security_CT/status/2094390236386316721 （2026年9月3日確認）: 本当に難しいのは、AIに何の観点でチェックさせるべきかを人間が理解しているか、という趣旨。観点を先に持つ、という本記事の出発点に用いました

• @suthio_ の投稿 https://x.com/suthio_/status/2091846321909203008 （2026年9月3日確認）: AIに「改善して」と言うとよく分からない結果になる、という趣旨。基準なしに「校正して」と頼む側の限界の需要として用いました