【要約】自分のトーン規約を渡して、Ollama に Zenn 下書きを点検させる [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
執筆者が技術記事を執筆する際、文体のトーンが意図せず緩んでしまう課題がある。媒体の規定に沿った「淡々とした工程誌」としての品質を維持するため、以下の問題に直面している。
- ・「〜してみた」や感嘆符の混入など、無意識な表現の揺らぎ。
- ・textlint等の既存ツールでは、煽り感や押し付けがましさといった曖昧なニュアンスの検出が困難。
- ・未公開の下書きを外部APIに送信することによる、情報漏洩のリスク。
// Approach
執筆者が自身のトーン規約をプロンプトに反映させ、Ollamaでローカルに動作する点検スクリプトを構築した。以下の手法を用いて、精度と利便性を両立させている。
- ・Python標準ライブラリのみを使用し、依存関係を最小限に抑えた実装。
- ・Markdownを段落単位に分割し、コードブロックやHTMLコメントを適切に処理。
- ・OllamaのJSONモードとtemperature 0を活用し、構造化された指摘結果を取得。
- ・プロンプトの改善により、曖昧な回答を禁止し、具体的な書き換え案を強制。
// Result
LLMを「品質保証」ではなく「見落としを検出する外部の目」として活用する現実的な運用像が示された。試行の結果、以下の知見が得られている。
- ・小型モデル（gemma3:4b）は誤検出が多く、文体が官僚化しやすい。
- ・中型モデル（gemma3:12b）は誤検出は減るが、規約への反応が鈍くなる非対称性が確認された。
- ・最終的な修正判断は人間が行う必要があり、textlintとの併用が最も効果的である。
Senior Engineer Insight
> ローカルLLMによる校正は、機密保持の観点から極めて実用的である。しかし、モデルサイズによる「過剰検出」と「見逃し」のトレードオフは無視できない。自動修正に頼らず、あくまで「指摘候補の提示」に留める設計思想は、開発体験と品質のバランスにおいて極めて妥当である。実戦投入時は、textlintで定型句を、LLMでニュアンスを、というハイブリッド構成が最適解となる。