文章校正AIというと、「文章を直す」「正解を提示する」仕組みを思い浮かべがちだ。
しかし現場で本当に欲しいのは、修正ではなく「見落としに気づくきっかけ」だった。
本記事では、DifyとローカルLLMを使い、文章を直さない校正――
赤ペンだけを返す、極端に役割を絞った文章チェックを試す。
RAGもワークフローも使わない。
AIに判断も責任も持たせない。
それでも、文章の事故は確実に減った。
その理由と実例を、できるだけ淡々と紹介する。
今回作った「文章を直さない赤ペンAI」アプリのイメージキャプチャ
序章｜なぜ、Difyで「文章校正」をやろうとしたのか
文章校正AIを作ろうと思ったわけではない。
少なくとも、「文章をきれいに直すAI」を作りたかったわけではなかった。
現場で本当に困るのは、表現が少し拙いことでも、言い回しが洗練されていないことでもない。
問題になるのは、後から気づくと冷や汗が出るような、あの手のミスだ。
首都の間違い。
固有名詞の誤り。
誤変換に気づかないまま公開されてしまった一文。
どれも、内容を深く理解しなくても防げる。
人間が一度「ん？」と立ち止まれれば、回避できる事故ばかりだ。
それなのに、忙しいときほど文章は流し読みされ、
「たぶん大丈夫だろう」という感覚のまま通ってしまう。
結果として、後から修正が効かない形で外に出る。
ここで必要だったのは、賢い校正AIではなかった。
必要だったのは、人間が二度見するためのきっかけだけだ。
文章を直さなくていい。
正解を提示しなくていい。
判断もしなくていい。
ただ、「ここ、少し怪しくないか？」と印を付けてくれれば、それで十分だった。
この発想に行き着いたとき、
自然と作るものの形は決まった。
AIには赤ペンだけを持たせる。
修正案は出させない。
理由も考えさせない。
単語や短いフレーズ単位で、目に引っかかる箇所だけを示す。
あとは人間が読む。
考える。
決める。
Difyを使ったのは、そのための置き場所として都合が良かったからだ。
重たい仕組みはいらない。
RAGもいらない。
業務フローを作る必要もない。
「文章を貼って、赤ペンをもらう」
それだけの窓口を、軽く置ける場所が欲しかった。
この先で紹介するのは、
校正AIの作り方でも、プロンプトの技巧でもない。
文章を直さない、という選択が、なぜ一番壊れにくかったのか。
その経緯と、実際の挙動を淡々と書いていく。
賢さを競う話ではない。
何も起きない状態を、どうやって作るかの話だ。
第1章｜文章校正で、本当に困るポイント
文章校正というと、多くの人は「誤字脱字を直すこと」を思い浮かべる。
しかし実務で本当に困るのは、そこではない。
多少の言い回しの拙さや、表現の粗さは、後からどうにでもなる。
読み手に多少の違和感を与えたとしても、それだけで致命傷になることは少ない。
問題になるのは、次のようなミスだ。
首都の取り違え。
固有名詞の誤記。
意味が反転してしまう誤変換。
一見それらしく見えて、事実としては通っていない一文。
これらは、文章の巧拙とは関係がない。
内容理解や高度な判断が必要なわけでもない。
人間が一度立ち止まり、注意深く見れば、防げるものばかりだ。
それにもかかわらず、こうしたミスは驚くほど多く外に出てしまう。
理由は単純で、文章が「読まれていない」からだ。
忙しい現場では、文章はどうしても流し読みになる。
一文一文を吟味する余裕はなく、「たぶん大丈夫だろう」という感覚で通っていく。
ここで重要なのは、校正者がいないことではない。
チェックする意志がないことでもない。
注意を向けるきっかけが存在しないことが、最大の問題になる。
文章校正ツールの多くは、「正しく直す」ことに主眼を置いている。
しかし現場で欲しいのは、必ずしもそれではない。
・ここは一度見たほうがいい
・この単語は怪しい
・この表現、少し引っかかる
そうした“違和感の入口”だけが提示されれば、人間は自然と立ち止まる。
逆に言えば、その入口さえあれば、
判断も修正も、最終的な責任も、人間の側に残すことができる。
この章で押さえておきたいのは、ただ一点だけだ。
文章校正で本当に困るのは、
「間違っていること」ではなく、
「間違いに気づかないまま通ってしまうこと」である。
第2章｜AIに「直させる」と、だいたい壊れる
文章校正にAIを使う、という話になると、
多くの場合「どこまで正しく直せるか」が議論の中心になる。
だが実際に試してみると、ここに大きな落とし穴がある。
AIに修正案を出させた瞬間、
文章チェックの性質が一変する。
正解が目に入る。
整った文章が提示される。
理由まで丁寧に説明される。
すると、人間は原文を読まなくなる。
「AIが直してくれたなら大丈夫だろう」
その一瞬の安心感が、最も危険だ。
修正案が正しいかどうかを判断するためには、
本来、原文と照らし合わせて読む必要がある。
だが、現実にはそこまで丁寧な確認は行われない。
結果として起きるのは、次のような事態だ。
・修正の妥当性を誰も検証していない
・文体や意図が、静かに変わっている
・責任の所在が曖昧になる
これは精度の問題ではない。
どんなに賢いAIでも、同じことが起きる。
実際に試してみると、AIは非常にお節介になる。
誤変換だけでなく、言い回しや語調、
時には文全体の構造まで手を入れたがる。
それは「より良い文章」を作るという意味では正しい。
しかし、今回求めているものとは完全に別物だ。
ここでやりたいのは、文章を完成させることではない。
事故を防ぐことだ。
AIが修正を行った文章をそのまま使ってしまえば、
最終的に何がどう変わったのか、
人間自身が把握できなくなる。
その状態で起きるミスは、
もはや「見落とし」ではなく、「委譲による事故」になる。
だからこの段階で、はっきり切り捨てる。
この文章チェックでは、
AIに「直させない」。
正解を言わせない。
修正案を出させない。
理由も深く考えさせない。
やらせる仕事を減らすことで、
初めて人間の確認行為が成立する。
第3章｜やらせる仕事を、極端に限定する
ここまでの整理で、やるべきことはほぼ決まっている。
文章チェックにAIを使うとしても、任せる範囲は最小限でいい。
判断させない。
修正させない。
正解を言わせない。
代わりにやらせるのは、ただ一つ。
人間が立ち止まるための印を付けること。
この役割に絞った瞬間、設計は一気に単純になる。
文全体を評価しなくていい。
文脈を深く理解しなくていい。
文章の良し悪しを考えなくていい。
単語や短いフレーズを見て、
「少し引っかかる」「違和感がある」
その感覚だけを拾えばいい。
例えば、
・誤変換っぽい語
・固有名詞として怪しい綴り
・一般常識とズレていそうな地名や国名
・意味が通らなくなるタイプミス
ここで重要なのは、確信がないなら挙げないという姿勢だ。
「もしかしたら違うかもしれない」
「調べれば正しい可能性もある」
そう感じたものまで拾い始めると、
ツールはすぐにお節介になる。
チェック結果がノイズで埋まる。
だから、役割はさらに削る。
・理由を考えすぎない
・説明しない
・文芸的な表現には触れない
・出力は一度で終える
AIは、赤ペンを持ったまま黙って返す。
それ以上のことはしない。
この設計にすると、
AIの能力を引き出すという発想そのものが不要になる。
必要なのは、
「何をさせないか」を決めることだけだ。
この章で行っているのは、
AIを賢く使う話ではない。
AIを不器用な道具として使うための設計である。
第4章｜今回の構成（Dify × ローカルLLM）
ここまでで整理した設計は、特別な仕組みを必要としない。
むしろ、余計な機能があると壊れやすくなる。
今回使っている構成は、驚くほど単純だ。
・Dify のチャットボット
・ローカルで動かす LLM
・ワークフローなし
・プレプロンプト 1 枚
これだけで成立している。
Difyを選んだ理由は、思想的なものではない。
業務用の「相談窓口」を置く場所として、ちょうど良かっただけだ。
文章を貼り付ける。
返ってくるのは、赤ペンだけ。
それを見て、人間が判断する。
この流れを、無理なく置ける。
RAGを使わなかったのは、意図的だ。
今回の用途では、外部知識を引き当てる必要がない。
むしろ、引いてしまうと話が膨らみすぎる。
文章チェックで欲しいのは、
「知識」ではなく「違和感」だからだ。
ワークフローも使っていない。
IF/ELSE を書くほど、条件は複雑ではない。
条件分岐を書き始めた時点で、
このツールは別物になってしまう。
必要なのは、
貼る → 印が付く → 人間が見る、
この一直線の流れだけだった。
プレプロンプトも 1 枚に収めている。
能力を引き出すためではなく、
やらせないことを並べるためのプロンプトだ。
環境構築や細かい手順については、
ここでは触れない。
この章で伝えたいのは一つだけ。
Difyを使ったから成立したのではない。
余計なことをさせなかったから、Difyで十分だった。
第5章｜実例：校閲サンプルで試す
ここからは、実際の文章を使って挙動を確認する。
使うのは、校閲の練習用として公開されている文章だ。
【校閲の適性チェック！】間違いさがし、全問正解できるかな？
https://www.en-soku.com/interest/23574
実務文に近く、誤りの種類も分かりやすい。
今回の用途には、ちょうど良いサンプルだ。
以下、3例をそのまま流し込み、
「赤ペンだけ」のチェックがどう返ってくるかを見る。
【例1】
取材先は、今回入社される方の配属先であるカフェです。店の中に入ると、コーヒ豆の良い香りが漂ってきました。店長に伺ったところ、豆だけでなく、焙煎、弾き方、淹れ方など、すべてにこわだって一杯のコーヒーを提供しているのだとか。
検出サマリ:
文字数: 136
検出件数: 2
要確認箇所:
#01 「コーヒ豆」
#02 「こわだって」
最後に:
もう一度見直してみてください。
誤変換として分かりやすい箇所が、そのまま拾われている。
一方で、「弾き方」は検出されていない。
これは欠点でもあり、同時に設計どおりの挙動でもある。
専門用語の誤用や、業界知識が必要な判断は、
あらかじめ人間が見る前提で残している。
【例2】
仲間を大切にする社風であり、積極的に車内での交流イベントを行なっています。フットサルや野球などのクラブ活動のほか、BBQやボーリング大会などのイベントも多数開催。普段の業務では関わることのないメンバーとも親しくなれます。こうしたて取り組みが、当社のの強みである組織の一体感に繋がっているのです。
検出サマリ:
文字数: 131
検出件数: 3
要確認箇所:
#01 「車内での交流イベント」
#02 「こうしたて取り組みが」
#03 「当社のの強み」人間が二度見するための一言：ちょっと変な表現やタイプミスがあります。
いずれも、意味を考えるまでもなく
「一度目に引っかかる」タイプの誤りだ。
文章全体の評価はしていない。
だが、これだけ印が付けば、人間は自然と立ち止まる。
【例3】
この販促ツールはこれまでに多くの成功実績があり、お客様から指示されています。導入にあたって、まずはお客様に1日の来店数や単価などをヒアリング。実際に当社の販促ツールを使用した場合、どれどの集客が煮込めるのかをシュミレーションしましょう。
検出サマリ:
文字数: 102
検出件数: 4
要確認箇所:
#01 「お客様から指示されています」
#02 「1日の来店数や単価などをヒアリング」
#03 「どれどの集客が煮込めるのか」
#04 「シュミレーションしましょう」人間が二度見するための一言：確認した方が良い表現があります。
誤変換、誤用、表記ゆれが混ざった典型的な例だ。
ここでも、修正案は出ていない。
正解も示されない。
それでも、
「このまま出すのは危ない」という感覚は十分に伝わる。
これらの例を見ると分かるとおり、
このツールは万能ではない。
すべての誤りを拾うわけでもない。
専門用語の正誤を判断するわけでもない。
だが、致命的な見落としを減らすという目的には、
必要な仕事だけをしている。
第6章｜類似のサービスと比べて
文章校正を目的としたサービスは、すでに数多く存在する。
それらの多くは、今回紹介しているものより、ずっと親切だ。
誤りを指摘する。
正しい表現を提示する。
理由を説明する。
場合によっては、文章全体を整え直す。
それ自体は、決して悪いことではない。
特に、文章を書くことに不慣れな人にとっては、大きな助けになる。
ただし、その親切さには代償がある。
修正案が前面に出るほど、
人間は原文を見なくなる。
どこがどう問題だったのかを考えなくなる。
結果として、
「直された文章」を使ったのか、
「自分が確認した文章」を使ったのか、
境界が曖昧になる。
今回の構成は、その方向を意図的に選ばなかった。
誤りを減らすことよりも、
見落とさないことを優先している。
そのため、指摘は少ない。
説明もない。
時には、お節介に見えることもある。
だが、打ち漏らすよりは、
少しお節介な方が安全な場面は多い。
重要なのは、
このツールが「完成形の文章」を作らない点だ。
判断も修正も、人間の側に残る。
AIは、最後まで脇役のままでいる。
その立ち位置を守る限り、
文章チェックは人間の仕事として成立し続ける。
終章｜Difyが「RAG前提」に見えてしまう理由
Difyの話をすると、特に中小零細の現場では、
「RAGをやるためのもの」という印象を持たれることが多い。
確かに、そういう使い方もできる。
だが、それはDifyの一面にすぎない。
実際の現場で価値が出るのは、
もっと手前の、もっと地味なところだ。
文章を貼る。
赤ペンが返ってくる。
人間が読む。
何も起きなければ、それで終わり。
今回作ったものは、
AIを賢く使った例ではない。
自動化を極めた話でもない。
むしろ逆だ。
AIに判断をさせない。
AIに完成させない。
AIに責任を持たせない。
それでも、事故は確実に減る。
中小零细の現場では、
「すごいことができる」よりも、
「何も起きない」ほうが価値が高い。
派手な成果は残らない。
効率化の数字も出しづらい。
だが、信用が毀損する機会を確実に減らせる。
Difyは、そのための置き場所として十分だった。
RAGを使わなくても、
ワークフローを組まなくても、
相談窓口として成立する。
AIに任せすぎない、という選択。
文章を直さない、という判断。
その積み重ねが、
結果的に一番壊れにくい運用につながった。
ここまで読んで、
「これなら自分の現場でも置けそうだ」と感じたなら、
それがこの構成の正解だ。
AIを使いこなす必要はない。
ただ、赤ペンを一つ、置いておけばいい。
それだけで、
文章の事故は、確実に減る。
補章
使用したSYSTEMプロンプト
今回使用したモデルは、gpt-oss-20b。
あなたは日本語文章の「違和感検出器」です。
校正者・編集者・解説者ではありません。
あなたの仕事は、
文章を読んで「少しでも引っかかる箇所」を拾い出し、
その該当箇所だけを列挙することです。
正誤の判断、修正、言い換え、説明、断定は行ってはいけません。
理由の説明は最小限に留めます。
必ず守ること：
・文章を書き換えない
・正しい内容を提示しない
・結論や助言を書かない
・質問を返さない
・賢そうな説明をしない
・同じ箇所を重複して挙げない
出力は必ずプレーンテキストで、次の形式のみを使います。
Markdown、HTML、記号装飾は禁止です。
出力形式：
検出サマリ:
文字数: N
検出件数: K
要確認箇所:01 「……」
02 「……」
03 「……」
（最大30件まで）
最後に:
人間が二度見するための一言（1行のみ）
追加ルール：
・文体の好み、表現の味わい、文芸的表現は検出対象に含めない。
・地名、国名、首都、著名な施設など、一般常識として固定されている語が含まれる文は、違和感があれば優先的に挙げる。
・確信がなかったら挙げない
・理由を考えすぎない
・違和感がない場合は「特に見当たりません」とだけ書く
・出力は1回で終える
・文全体や文脈ではなく、単語・短文単位で目に引っかかる箇所を優先する。
