academic-humanizer レビュー: 論文と NSF/NIH 申請書から AI っぽさだけを削る SKILL.md
Strip AI-writing tells from papers and grant proposals (NSF/NIH), while keeping scholarly voice and tying claims to evidence. A skill for Claude Code, Codex, and MorphMind.
ひと目でわかる
- これは何？
- AI 支援で書いた論文・グラント申請書から汎用的な言い回しを取り除きつつ、著者の声と引用・数値を保つ Claude Code 用スキル。仕組みは SKILL.md 一枚と例集という素朴な構成で、その素朴さが導入判断の分かれ目になる。
- 誰に向いている？
- 著者自身の過去論文や採択済み申請書を数本持っていて、AI で書いた草稿を自分の声に寄せたい研究者に向く。逆に、データや引用そのものを生成・修正したい人、分野固有の用語体系を自分で調整する気がない人には向かない。
- 商用利用できる？
- まず確認が必要です。このリポジトリのライセンスは自動分類の対象外なので、商用利用の前に LICENSE ファイルを読んでください。
- 今もメンテナンスされている？
- されています。最後のコミットは 75 日前です。
- 何の言語で書かれている？
- GitHub はこのリポジトリの主な言語を示していません。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
AI 草稿の「In recent years...」を消すという狭い問題
このプロジェクトが解こうとしている問題は、文章生成の品質ではない。AI に手伝わせて書いた論文やグラント申請書の草稿が、汎用的で冗長になり、著者自身の声から離れてしまうという問題である。README は「In recent years...」という書き出し、膨らんだ言い回し、長すぎる文を具体的な症状として挙げている。
対象読者はかなり限定されている。著者自身の過去の採択論文や採択済み申請書が手元にあり、それを基準に AI 草稿を寄せたい研究者だ。README には「NSF, CAREER, NIH R01」で作ったとあり、想定されているのは NSF や NIH に申請する層である。ブログやマーケティング文書のための humanizer とは目的が違う。README は既存の humanizer について「Run one on a paper or an NSF proposal and it flattens the precision along with everything else」と書いており、学術文の精度が最初に失われることを問題視している。
倫理面の立場も明示されている。このツールは知見を生成せず、データを捏造せず、引用を変えず、AI 利用検出を回避するためにも設計されていない。使っても AI 利用の開示義務は残る、と README は書いている。
6 層のルールと audit→rewrite ループ
仕組みは SKILL.md という一枚の指示ファイルに集約されている。README によれば 6 層で構成される。Layer 1 は汎用の AI っぽさカタログ、Layer 2 は学術文に固有の癖、Layer 3 は学術的な慣行の保存、Layer 4 は主張と根拠の照合、Layer 5 は声と投稿先の調整、Layer 6 は NSF/NIH の申請書モードである。audit→rewrite のループは SKILL.md に定義されている、と README は述べている。
Layer 1 は blader/humanizer のカタログを再利用していると README に明記されている。ゼロから作ったのではなく、ブログ・カジュアル・百科事典向けのパターン除去カタログを学術文向けに拡張した構成だ。
Layer 3 と Layer 4 が実務上の核になる。Layer 3 は根拠に紐づいたヘッジ表現、適切な箇所の受動態、we、定義、記号、そしてすべての引用を保存対象とする。Layer 4 はデータより強い動詞を禁止し、prove を show empirically に置き換え、曖昧な大きさを出典付きの範囲に変える。数値と参照は変更しない、と README は書いている。
Layer 6 は NSF と NIH の提案書の安定した構造を蒸留したものだと説明されている。具体的なページ制限・書式・締切は変動するため、NSF の PAPPG や NIH の Write Your Application といった一次情報を参照するよう README は促している。申請書モードでは、論文なら削るようなビジョンを残し、審査員が採点する最初のページに作業を集中させる。
インストールと実行: クローン先がそのままスキル配置
導入は git clone 一発である。README のコマンドは次のとおり。
git clone https://github.com/AIScientists-Dev/academic-humanizer ~/.claude/skills/academic-humanizer
クローン先がそのまま Claude Code のスキル配置ディレクトリになっている点に注意したい。既に同名ディレクトリがある場合は上書きや衝突が起きうる。
実行はスラッシュコマンドで行う。README の例では /academic-humanizer を呼び、本文を貼るか main.tex を指し、任意で「match my voice from prior_paper.pdf; target venue: ICLR」のように声の参照元と投稿先を指定する。
Claude Code 専用ではない。README は、ただの SKILL.md と例の集まりなので Codex や MorphMind のスキルまたはシステムプロンプトとしても動くと述べている。その場合はエージェントに SKILL.md を指し示す。設定キーや環境変数の類は README には出てこない。カスタマイズは「Fork the repo and adapt them to your own」とあり、自分の過去論文を数本指定し、分野に合うチェックを残して残りを調整する、という運用が想定されている。
保存対象の定義が広いほど、ルールの衝突も増える
Layer 3 が保存対象とするものの一覧は、そのままこのツールの限界でもある。根拠に紐づいたヘッジ表現、適切な箇所の受動態、we、定義、記号、すべての引用を残す、という方針は、分野によっては「適切な箇所の受動態」の判断が分かれる。受動態を多用する分野の慣行と、能動態を好む投稿先の編集方針がぶつかったとき、どちらを優先するかは SKILL.md の記述だけでは決まらない。
Layer 4 の claim↔evidence 照合も同様である。データより強い動詞を禁じ、prove を show empirically に置き換えるという規則は、数学や理論計算機科学のように証明を実際に与える分野では過剰修正になりうる。README 自身が「The rules here reflect one group's voice」と認めており、万能のフィルタではないと明言している。
もうひとつの制約は入力の性質だ。このツールは編集パスであり、下書きが存在することを前提とする。ゼロから本文を組み立てる用途は想定されていない。references セクションで挙げられている koaeraser/ARMS はアイデアから検証済み原稿までの自律パイプラインで、こちらはより広い範囲を扱う補完的なプロジェクトだと README は位置づけている。academic-humanizer はそのうちの編集工程だけを切り出した狭い部品である。
ライセンスは README のバッジと本文が MIT と記載しているが、リポジトリのライセンス識別子は NOASSERTION となっている。実際の LICENSE ファイルの中身を確認するまでは、MIT という表示だけを根拠に再利用条件を判断しないほうがよい。法的助言はここではできない。
blader/humanizer との違いは対象読者と保存対象
比較対象として README が名指ししているのは blader/humanizer である。同じく MIT で、焦点はブログ・カジュアル・百科事典向けのテキストから一般的な AI っぽさを取り除くことにある。academic-humanizer はその Layer 1 カタログを再利用し、学術文向けに拡張した。
違いは抽象的な思想ではなく、保存対象の有無に出る。blader/humanizer は汎用パターンの除去が目的なので、数値や引用を守る層を持たない。academic-humanizer は Layer 3 と Layer 4 を追加し、引用・数値・根拠に紐づいたヘッジを触らないという制約を課している。NSF/NIH 向けの Layer 6 も固有で、最初のページに編集の重みを置くという判断は汎用 humanizer には存在しない。
もう一方の koaeraser/ARMS は方向が逆で、範囲が広い。アイデア出しから検証・改稿までを自律的に回すパイプラインであり、academic-humanizer はその中の編集一回分に相当する。どちらを選ぶかは、原稿のどこで詰まっているかで決まる。構成や検証の設計に困っているなら ARMS 側の関心であり、出来上がった草稿の言い回しと主張の強さを直したいならこのスキルの守備範囲である。
メンテナンスとアップグレードの実際
リリースは取得されておらず、README のバッジには version 0.3.2 とある。バージョン管理は README の表示に依存しており、タグやリリースノートから変更履歴を追う経路は今回の材料からは確認できない。
中身が SKILL.md と例の集まりである以上、アップグレードは git pull で完結する類のものではない。自分でルールを書き換えている場合、上流の変更と自分の編集が同じファイル上で衝突する。README が「Fork the repo and adapt them to your own」と勧めているのは、この衝突を前提とした設計だと言える。フォークして自分の分野向けに調整した時点で、上流の改善を取り込むコストは自分持ちになる。
維持すべき依存はエージェント側の仕様である。Claude Code のスキル配置やスラッシュコマンドの挙動、Codex や MorphMind のシステムプロンプトの扱いが変われば、SKILL.md のままで動き続ける保証はない。Layer 6 が参照する NSF の PAPPG や NIH のページ制限・書式・締切も更新される。README 自身がこれらは一次情報を参照するよう求めているので、申請書モードを使うなら公募要領の確認は別作業として残る。
自分の原稿で試す前に見るべきファイル
導入判断で最初に開くべきは examples/before-after.md である。README によれば、一般的な例、NIH の Specific Aims ページ、採択済み NSF CAREER の summary の 3 種類の before/after が収録されている。自分の分野の文章がこの 3 例のどれに近いかで、Layer 2 と Layer 6 が効くかどうかの見当がつく。
次に SKILL.md の audit→rewrite ループの定義を読む。ここが実際の処理手順であり、6 層のどこで何を判定するかが書かれている。Layer 3 の保存対象リストと Layer 4 の claim↔evidence 照合が、自分の投稿先の慣行と衝突しないかを確認する。衝突する箇所があれば、それはフォークして書き換える対象である。
最後に LICENSE ファイルを直接確認する。README は MIT と表示しているが、リポジトリの識別子は NOASSERTION であり、この不一致は自分で解消しておくべき点だ。
編集部の結論
著者自身の過去論文や採択済み申請書を数本持っていて、AI で書いた草稿を自分の声に寄せたい研究者に向く。逆に、データや引用そのものを生成・修正したい人、分野固有の用語体系を自分で調整する気がない人には向かない。導入前に確認すべきは、リポジトリ直下の SKILL.md に書かれた 6 層のルールのうち、Layer 3 の保存対象リストと Layer 4 の claim↔evidence 照合が自分の分野の慣行と衝突しないかどうか。衝突するなら examples/before-after.md の例を自分の過去原稿に置き換えてフォークする前提で読むべきで、そのまま使うと自分の精度が落ちる箇所が出る。
コミュニティノート