im-not-ai (Humanize KR) レビュー：韓国語AI文体をスパン単位で削るClaudeスキル

誰のための道具か：韓国語の翻訳調を名指しで消す

このスキルが解こうとしている問題は、韓国語のAI生成文に特有の「AIっぽさ」が英語由来の翻訳調から発生するという前提にある。READMEは英語圏のhumanizer（QuillBot・Hix・Undetectable AI）を名指しし、それらは韓国語が弱いと述べる。根拠として挙げられるのは「AI 기술을 통해 효율을 높일 수 있다」を「AI로 효율을 높인다」に、「이에 있어서 중요한 점은」を「여기서 중요한 건」に、「~에 의해 생성된」を「~가 만든」に置き換えるという具体例だ。つまり対象読者は、英語の文章を韓国語に訳したような下書き、あるいは韓国語で書かせたが英語の構文が残った下書きを、公開前に文体だけ直したい人である。内容の修正やファクトチェックを担う道具ではない。READMEの4大原則の第一項が「意味不変」で、事実・主張・数値・固有名詞・直接引用は100%原文を保持すると明記されている。編集者ではなく、校正者に近い位置づけだ。

route_hintが決める3経路：コール数を削るという設計判断

アーキテクチャの中心は、入力の状態が処理経路を決めるという考え方にある。shim の prepare_monolith_input.py が入力テキストを KatFish と post-editese 指標で事前に定量採点し、そのスコアから route_hint（light / standard / heavy）を決定論的に算出する。light は1コールで診断と finalize を省き、語彙的なAIっぽさがほぼゼロの文章なら「すでに良い」と早期終了する。standard は診断1コールと狙い撃ちの書き換え1コールの計2コールで、1万字級でもチャンク分割せず単一コールで処理する。heavy は3コール以上で、診断、書き換え、finalize の順に進み、shim が2つ以上のチャンクを作った場合に限って並列化する。READMEはこの削減がモデル交換ではなくコール数削減から来ると明言し、モデル選択は利用者の裁量だとしている。READMEが示す計測では、1万字の文章を7コールに分割すると610Kトークン、単一コールなら134Kで4.5倍の差が出たという。チャンクごとにルールブックと診断を再ロードする費用が節減分を食い潰すためだと説明されている。この数字はREADMEの記載であり、こちらで再現したものではない。

分類体系の粒度：AからJまでの70サブパターン

検出対象は10の大分類と70のサブパターン、加えて検証待ちの hold 1件で構成される。分類はAが翻訳調、Bが英語引用と用語の過多、Cが構造的なAIパターン、DがAI特有の慣用句、Eがリズムの均一性、Fが修飾と重複、Gがヘッジの濫用、Hが接続詞の多用、Iが形式名詞の過多、Jが視覚装飾の濫用という並びだ。具体的な項目名までREADMEに載っているものもあり、A-16は「그/그녀」の強迫的な使用、A-18は関係節の左方向修飾、A-19は「~에서의/~에로의」のような二重助詞、C-11は連結語尾の後の読点、E-7は聞き手への敬語法の一貫性の損失を指す。深刻度は3段階で、S1は一度出ただけでAIと確信できる決定的なもの、S2は1〜2回までは許容し3回以上の反復で除去対象、S3は他のパターンと重なったときだけ問題になる弱いものと定義される。この深刻度設計は、単純な禁止リストではなく出現頻度のしきい値で判断する点で、過剰な書き換えを抑える方向に働く。分類体系そのものは korean-ai-tell-taxonomist という別コマンドのエージェントがSSOTとして管理し、新規パターンの審査と昇格を担う。

変更率ゲートという安全装置と、その限界

すべての経路に共通で verify_change_rate.py が走り、変更率を決定論的なコード判定として exit code で返す。READMEの4大原則は変更率30%超で警告、50%超で強制停止と明記する。書き換えの強度をモデルの判断に委ねず、スクリプトの判定に落としている点は評価できる。ただしこのゲートが守るのは変更の量であって、変更の質ではない。意味不変の原則は「検出されたspanにのみ外科的に修正を加える」という前提に依存しており、検出そのものが誤っていれば、変更率が低くても意味は動く。READMEは探索的な検証として対照コーパスによる実証を v2.3.0 のリリース名に掲げているが、その検証がどのジャンルの文章をどれだけの量で扱ったのかは、与えられた資料からは確認できない。もう一つの限界は言語の非対称性だ。このスキルは韓国語のAIっぽさを韓国語のパターンとして定義するため、日本語や中国語の文章に同じルールブックを当てても、A分類の翻訳調項目は表面的な類似でしか反応しない。多言語の文体校正を一つのツールで済ませたい場合、これは正しい選択ではない。

導入コマンドと、ツールごとに変わる実行経路

インストールは4つのCLIを対象とする。GitHub Copilot CLI では copilot plugin marketplace add epoko77-ai/im-not-ai の後に copilot plugin install humanize-korean@im-not-ai を実行し、copilot plugin list で確認する。更新は copilot plugin update humanize-korean@im-not-ai、削除は copilot plugin uninstall humanize-korean@im-not-ai だ。READMEは 1.0.79-5 では copilot plugin install epoko77-ai/im-not-ai というリポジトリ直接指定も動くが、CLIが非推奨の警告を出すため新規導入には勧めないと注記している。Claude Code では /plugin marketplace add epoko77-ai/im-not-ai と /plugin install humanize-korean@im-not-ai を実行し、新しいセッションで /humanize-korean を呼ぶ。クローンしてから ./install.sh を使う経路もあり、インストール済みの claude と codex を自動検出してグローバルシンボリックリンクを張る。片方だけなら --claude-only か --codex-only、削除は ./uninstall.sh、更新は ./update.sh で、--check を付けると検出だけを行う。ここで見落としやすいのは経路の差だ。Copilot・Codex・Gemini は単一呼び出し経路のみを提供し、standard の2コールや heavy の3コール以上、診断と finalize を含む多コール経路は Claude Code 専用だとREADMEは明記する。つまり同じスキルを入れても、ツールによって品質段階が変わる。

v2.1でのエージェント退役が示すもの

現在の実行エージェントは4つに整理されている。humanize-monolith は全経路共通で、検出・書き換え・自己検証を一括処理し、ツール呼び出しは3回で上限を切る。humanize-diagnostician は standard と heavy で文章全体の支配的パターンを3〜6個診断し、taxonomy IDと処方を返す。humanize-finalizer は heavy 専用で、原文と直接照合して意味保持の15項目と自然さを判定し局所補正する。korean-ai-tell-taxonomist は別コマンドとして分類体系を管理する。旧 strict 5人パイプラインの ai-tell-detector、korean-style-rewriter、content-fidelity-auditor、naturalness-reviewer と、ウェブ拡張設計用の humanize-web-architect は v2.1 で退役した。役割を分割した多段構成から、単一コールを優先する構成へ移したことになる。agents/ ディレクトリにはリリース回専用の開発ツール5つが残っているが、READMEはこれらを書き換え実行とは無関係と明示している。リポジトリを眺めたときにエージェント数だけを見て処理の複雑さを推測すると、実態を読み違える。

代替手段との違い：汎用humanizerか、パターン台帳か

比較対象としてREADME自身が挙げるのは QuillBot、Hix、Undetectable AI のような英語圏のhumanizerだ。違いはapproachにある。汎用humanizerはモデルに「自然に書き直せ」と指示し、出力の自然さをモデルの判断に委ねる。im-not-ai は検出パターンを taxonomy として台帳化し、各パターンにIDと深刻度を与え、検出されたspanにだけ修正を当てる。この差は、なぜその文が直されたのかを説明できるかどうかに現れる。編集者が「A-16の強迫的な代名詞使用だから」と根拠を追える一方、汎用ツールの出力は差分を見ても理由が残らない。代償は網羅性の方向にある。台帳に載っていない新しい言い回しは、どれだけ不自然でも検出されない。70サブパターンという数は、韓国語のAI文体をかなり細かく分解した結果だが、同時にこのリストの外側は守備範囲外だという宣言でもある。hold 1件という記載は、分類体系が固定ではなく審査中の項目を抱えた状態で運用されていることを示す。

ライセンスと更新の実際

ライセンスはMITで、リポジトリはアーカイブされておらず、最終プッシュは2026年9月6日、直近のリリースは v2.3.2（プラグインスキルの位置修正）、その前が v2.3.1（パス解決・ランタイム境界・契約整合）、v2.3.0（効率化と対照コーパスによる実証検証）という並びだ。パッチリリースがパス解決やプラグイン配置の修正に充てられている点は、マルチツール対応のインストール経路が今も調整されていることをうかがわせる。更新の運用は導入経路で分かれる。マーケットプレイス経由なら /plugin update、クローン経由なら ./update.sh が新バージョンを検出して git pull と再インストールを行い、--check は検出のみで終わる。MITライセンスなので改変と再配布は許容されるが、分類体系のSSOTである ai-tell-taxonomy.md や rewriting-playbook.md をフォークして自組織のルールブックに差し替える場合、上流の更新をそのまま取り込めなくなる。この点は法務判断ではなく運用判断であり、フォークするか追従するかを先に決めておく必要がある。なお、ここに書いた内容はライセンス解釈の助言ではない。

編集部の結論

韓国語の記事やレポートをAIで下書きし、公開前に文体だけ整えたい書き手には向いている。英語圏のhumanizerを韓国語に流用しても直らない翻訳調を、パターンIDで名指しして潰せる点が実務上の差になる。逆に、事実確認や構成の組み直しを期待する使い方には向かない。READMEが掲げる4大原則のうち意味不変はスパン単位の修正に依存するため、数値・固有名詞・直接引用を含む文書では、変更率ゲートの exit code と final.md の差分を必ず自分で照合したい。導入前に確認すべきは3点。自分のツールが3経路のうちどれを実行できるか（Copilot・Codex・Geminiは単一コール経路のみ）、heavy経路の15,000字超というしきい値が自分の原稿長に当てはまるか、そして taxonomy の A-16 や A-18 のような細かい項目が自分のジャンルの文章で誤検出を起こさないか。

公式情報源

1. epoko77-ai/im-not-ai on GitHub
2. License: MIT
3. Project website
4. README
5. Releases