HumanifyMe

HumanifyMe

AI の文章をあなたらしく。 · humanifyme.com

ブラウザーで試す → インストールもキーも不要です。自分が書いたメッセージをいくつかと、AI の下書きを貼り付けるだけで、あなたらしい文体に書き直した下書きが得られます。

HumanifyMe は、特定の一人の書き方を学習し、AI エージェントの出力を誰かが読む前に、その人らしい文体に書き直します。一度インストールすれば、お使いのマシン上のすべてのエージェント（Claude Code、Cowork、Cursor）が同じ文体で書き直します。目指すのは「もっと上手に書く」ことではありません。「AI っぽい文章をやめる」ことです。

ローカルで動作します。ネットワークに送信されるのは、選択した LLM プロバイダーに送る、機密情報を除去した下書きだけです。

クイックスタート

まず、セキュリティに配慮した初回セットアップを実行してください。プライバシーの境界について説明し、入力中のプロバイダーキーを非表示にして、プロバイダーを検証します。さらに、文章サンプルを3つ収集してプロフィールを作成し、最初の書き直しを提案します。

npx -y [email protected] setup

インストールする前に動作を確認しますか？セットアップと書き直しの流れを試せるライブデモは、humanifyme.com にあります。

プロバイダーキーを AI チャットに貼り付けたり、コマンドラインフラグとして渡したりしないでください。次に、同梱のマーケットプレイスからプラグインをインストールします。リポジトリのクローンもビルドも不要です。

claude plugin marketplace add JoshMcQ/HumanifyMe   # register the marketplace
claude plugin install humanifyme@humanifyme        # installs 3 skills + the MCP server

あとは、どの下書きにも /humanifyme:humanify を使うか、エージェントがメール、PR、メッセージの下書きを作成した後に、同梱のスキルから実行させます。CLI とインストール済みのすべてのエージェントは、~/.humanifyme/ に保存されたプロフィールを共有します。後からサンプルを追加したり、プロフィールを再作成したりするには、/humanifyme:build-voice-profile を使ってください。

試してみましたか？ 書き直しを評価する：2つのドロップダウンで評価できます。このフィードバックが、文体のマッチングを最も改善します。

セッション中にインストールした場合は、/reload-plugins を実行してください。別のエージェント（Cursor、Continue、Cline、Windsurf、Zed、ChatGPT desktop）や CLI を使っていますか？インストールを参照してください。

プロフィールを設定する前に下書きを調べたいですか？アナライザーはローカルで動作し、決定論的で、API キーも不要です。

echo "At its core, this robust approach paves the way." | npx -y humanifyme analyze

公開されているAI 文章の特徴を示す90項目のチェックリストと照合した正確な語句や句読点を報告します。これは編集を支援するツールであり、AI 検出器ではありません。主観的な特徴は、人間が確認できるようにそのまま表示し、偽の確率に変換することはありません。

開発の背景

日々、コミット、PR の説明、Slack の投稿、メールの下書きなど、文章作成を AI に任せる人が増えています。そして、どのエージェントが生成しても、洗練され、バランスが取れた、どこか企業的な、ひと目でわかる文体になります。受け取る側も、それを見抜くようになりました。よくある対処法（Grammarly、Wordtune、「AI ヒューマナイザー」）は、文章をありきたりなプロフェッショナルな文体に寄せるもので、目指すところとは正反対です。

Few-shot プロンプトだけでは、この差を埋められません。2025 年に実施された大規模な研究では、最先端モデルと数百人の実際の執筆者を対象に、数万件の生成を行い、プロンプトに少数のサンプルを入れてモデルに「私のように書いて」と頼む方法では、カジュアルな文体に限界があることが示されました（Wang et al., 2025）。HumanifyMe は、その限界を超えるために、長いプロンプトではなく、継続的に利用できる検索可能なあなた自身の文章コーパスと、「言い換えてから文体を合わせる」書き換え方式を採用しています。

MCP とプラグインの違い。 MCP（Model Context Protocol）は HumanifyMe が使用するプロトコルなので、MCP 対応のエージェントならどれでも humanify_text ツールを呼び出せます。プラグインはパッケージ形式です（Claude Code と Cowork で使用）。MCP サーバーとスキルがひとつのインストール可能な単位にまとめられています。プラグインをインストールするか、MCP サーバーを直接登録できます。

仕組み

エージェントはひとつのツール、humanify_text を呼び出します。それ以外はすべてお使いのマシン上で実行されます。

flowchart LR
    Agent["AI agent (Claude Code / Cowork / Cursor)"] -->|"calls humanify_text"| Tool["humanify_text (MCP tool)"]
    Tool --> Engine["rewrite engine"]
    Engine --> Redact["redaction"]
    Engine --> Memory["voice memory (retrieval)"]
    Engine --> Provider["LLM provider"]
    Engine --> Verify["deterministic verify gate"]
    Redact -. "masked draft only" .-> Provider
    Memory --> DB[("local store: ~/.humanifyme/data.db")]
    DB --> S["samples"]
    DB --> P["profile"]
    DB --> E["embeddings"]

書き換えには**「言い換えてから文体を合わせる」**方式を採用しています。元の文体を取り除き、学習済みのあなたの文体に近づけて再生成した後、プロンプトでは回避できない決定論的なチェックを実行します。この設計を支える要素は次の 3 つです。

• 決定論的な検証 — 品質を支える強み。 多くの「私の文体で書き換える」ツールは、プロンプトだけで済ませて、うまくいくことを期待します。生成のたびに、src/engine/verify.ts が、秘匿化された下書きに対して 5 つの機械的なチェックを実行します。モデルがあなたの回避語リストから新たに追加した単語、欠落した数値（日付、価格、バージョン）、壊れた URL、消えた秘匿化プレースホルダー、学習済みの大文字・小文字の使い方を確認します。初回の試行で問題が見つかると、再試行の指示に反映されます。再試行後も残る問題は、ユーザーに「送信前に確認してください」というメモとして提示されます。出力がブロックされることはありません。
• 編集可能な文体フィンガープリント。 あなたの文体は、判読可能なラベル付き JSON オブジェクトとして表現されます。文の長さ、フォーマルさ、率直さ、句読点の使い方、避ける単語、実際に使っている挨拶や結びの言葉などを含み、不透明なベクトルではありません。各要素は、カジュアル、プロフェッショナル、メール、苛立ちなど、コンテキストごとに調整でき、書き換え時にディープマージされます。内容を確認して修正できます。
• 自分の文章を使った検索。 過去のメッセージの埋め込みはローカルに保存され、書き換え時に Few-shot の例として取得されます。構造化されたフィンガープリントは、文体の仕様およびコールドスタート時のフォールバックとして使われます。~/.humanifyme/data.db に保存されるひとつの永続的な文体メモリを、マシン上のすべてのエージェントとプロジェクトで共有します。デフォルトの埋め込みモデルはオフラインで動作し、依存関係も不要です。MiniLM と Ollama は、オプトインで使えるローカル限定の拡張機能です。

詳しくは、アーキテクチャと書き換えパイプライン · 文体メモリと検索 · データモデルをご覧ください。

インストール

プラグインとして（まずはこちら）

HumanifyMe は humanifyme.plugin/ にプラグインとしてまとめられています。内容は、.claude-plugin/plugin.json マニフェスト、MCP サーバーを登録する .mcp.json、3 つのスキル（humanify、build-voice-profile、humanify-pr）です。リポジトリのルートには、マーケットプレイスカタログ .claude-plugin/marketplace.json があります。2 行のインストール手順はクイックスタートをご覧ください。

同梱の .mcp.json は、公開済みの npm パッケージから npx -y --package [email protected] humanifyme-mcp を使ってサーバーを起動します。既知のビルドに固定されているため、新しいマシンでも何もチェックアウトせずにプラグインを使用できます。他のエージェント向けのコピー＆ペースト可能なセットアップは、docs/install/にあります。

コマンドライン

npm から実行すると、プライバシー、プロバイダー、3 つのサンプル、プロファイルの作成、最初の書き換えまで、1 つのコマンドで順に設定できます。API キーの入力は非表示になり、中断した場合は最後に完了した手順からセットアップを再開します。

npx -y humanifyme setup
npx -y humanifyme rewrite draft.txt

チェックアウトからコントリビュートするには、Node 22.5 以降が必要です。

npm ci
npm run build
node dist/humanifyme.mjs setup

MCP の直接登録

エージェントがプラグイン形式を使用しない場合は、サーバーを直接登録してください。

claude mcp add humanifyme -- node /path/to/repo/dist/humanifyme-mcp.mjs

サーバーは、1 つのレジストリで 16 個の humanify_* ツールを公開します。中心となる humanify_text に加え、フィードバックとメトリクス、サンプルの追加／一覧表示／削除、プロファイルの取得／作成／更新／削除、プロバイダーの設定、キーのテスト、監査ログの一覧表示、すべてのデータの消去、2 つのインポーターを利用できます。同じエンジンは、MCP を介さずに humanifyme CLI からも実行できます。

実際に機能するのでしょうか？

4 つの文体による評価です。異なる文体を持つ 4 人のライター（カジュアルな小文字、フォーマルな文頭大文字、簡潔で技術的、温かく熱意のある表現）が、汎用的な AI の下書きをそれぞれ 5 つ用意し、検索あり／なしで書き換えました。書き換えペアは 20 組です。手法の全容、生の数値、再現手順については docs/proof/README.md をご覧ください。実行日は 2026-06-24 です。

帰属（証明ではなく、妥当性の確認です）。 文体計測器を使って、検索結果に基づいて書き換えた文章が 4 人のライターのうち誰に最も近いかを判定すると、20 件中 17 件（85%）が元のライターに一致しました。ただし、私たち自身も懐疑的です。ライター間の違いは主に文体で、計測器は大まかな表層的特徴を 8 つ使うだけであり、誤判定はすべて小文字を使う 2 人のライターの間で起きています。これは仕組みが何らかの処理を行っていることを示しますが、誰かの個人特有の文体を再現した証拠ではありません。

今回の実行では、4 人中 3 人について、検索によって書き換え文が実際のライターに近づきました（距離が小さいほど近い）。検索によって悪化したライター B も報告しています。指標にはばらつきがあるため、損失を勝利に丸めることはしません。

ライター	距離（オン）	距離（オフ）	検索による改善
A（カジュアル／小文字）	2.35	3.38	はい、明確に改善
B（フォーマル／文頭大文字）	3.22	2.32	いいえ、今回は悪化
C（簡潔／技術的）	2.92	3.09	はい、わずかに改善
D（温かく／熱意のある表現）	2.47	2.69	はい、わずかに改善

主張していないこと： LLM が別の LLM を評価することが証明になるということ（実施しましたが、弱い代替指標です）、検索がすべてのライターに有効だということ、MVP がすでに文体に特化した検索を行うということ、またはマスキングの再現率がプライバシーを保証するということです。誠実な検証方法は人間による評価です。証明ドキュメントでは、すべての制約を詳しく説明しています。

プライバシー

HumanifyMe はローカルファーストで、送信前にデータをマスキングします。プライバシーの保証は再現率ではなく、アーキテクチャによるものです。エンジンはお使いのマシン上で動作し、プライバシーに関わる重要なコード（src/privacy/、src/network/、src/engine/verify.ts）は Apache-2.0 ライセンスで公開されているため、何が外部に送信されるかを正確に確認できます。

• ローカルファースト。 すべての状態は ~/.humanifyme/ 以下に保存され、変更できるのは HUMANIFYME_HOME を設定した場合のみです。元のサンプルがこのディレクトリの外に出ることはありません。
• キーは OS の資格情報ストアに保存されます。 クラウド API キーは、Windows 資格情報マネージャー、macOS キーチェーン、または Linux Secret Service に保存されます。キーチェーンを利用できない場合、HumanifyMe は安全側に停止し、平文の設定ファイルへの保存に切り替えることはありません。
• 送信前にマスキング。 redact() は単一のネットワーク呼び出しを行う前に、メールアドレス、電話番号、米国の住所、Luhn アルゴリズムで検証したカード番号、API キー、AWS アクセスキー ID、JWT を番号付きプレースホルダーに置き換え、restore() はその後に元に戻します。取得した例も送信時に再度マスキングします。保存時のマスキングを信頼することはありません。設計上、ベストエフォートであり、その旨を明記しています。
• 送信先の許可リストと静的スキャン。 src/network/outbound-scan.test.ts では、fetch() を呼び出せるのは src/providers と src/network のみであること、またハードコードされたすべてのホストが4件の許可リストに含まれることを検証します。
• メタデータのみのテレメトリ。 監査ログとオプトインのフィードバックで記録するのは、件数、レイテンシ、バイト数のみです。コンテンツは記録しません。匿名共有はデフォルトでオフになっており、24時間に1回までに制限されています。

src/privacy/redact.test.ts のゴールデンフィクスチャでは、レダクションによって埋め込まれた7種類すべての秘密情報がマスキングされ、20件の一般的な段落で誤検出はありません。処理は決定論的です。完全な手法は specs/privacy-security-spec.md に記載されています。ここに書かれたルールは、コントリビューターが破ってはならない唯一のルールセットです。

検出回避ツールではありません

HumanifyMe は AI 検出器を欺く手助けはしません。仕様にもそのように明記しています。この方針には研究上の根拠があります。検出は脆弱であり、検出器の信頼性には理論上の限界があり、再帰的な言い換えはほとんどの検出器を無効化します（Sadasivan et al., 2024）。また、分類器を欺くことに成功するツールがあっても、出力があなたらしく聞こえるかどうかは証明できません。AI らしさを示す表現の密度は、目標ではなく最低限の健全性を確認するためだけに追跡します。

参考にした研究

すべての設計上の選択は先行研究に対応しており、それぞれの解説では、科学的知見がどこまでで、私たちの見解がどこから始まるかを明示しています：先行研究の調査 · 最新技術のレビュー · 評価設計。特に、決定論的な検証ゲートは、特定の失敗モードに対する設計上の賭けであり、公開済みの結果によって検証されたものではありません。リンク付きの参考文献一覧は以下に記載しています。

作った理由

AI に自分の代わりにメッセージを書いてもらいたかったのですが、どうしてもうまくいきませんでした。文章を書き上げて、言い回しを少し整えるだけにしてほしいと頼んでも、まったく別の、自分らしくない口調のメッセージが返ってくるのです。そこで、プロンプトを工夫して回避しようとしたことが、このプロジェクトにつながりました。

コードの大半は、私が作成してレビューした仕様と受け入れ基準に基づき、Anthropic のエージェント型コーディングツールである Claude Code を使って書かれました。プラグインファーストの配布、すべてをローカルに保つこと、検証ゲート、評価方法など、製品とアーキテクチャに関する判断は私自身が行っています。

リポジトリの構成

/README.md                       <- you are here
/src/                            <- the MCP server + CLI (TypeScript)
/humanifyme.plugin/              <- plugin bundle: manifest, MCP registration, skills
/prompts/                        <- LLM prompt templates for the rewrite engine
/evals/                          <- ablation runner, scorers, results
/docs/                           <- research, proof, architecture, install, data model

コントリビューション

メンテナーを募集しています。まず CONTRIBUTING.md を読み、次に src/engine/rewrite.ts、src/engine/verify.ts、src/privacy/ を読んでください。この3つが手法の中核です。破ってはならないルールは specs/privacy-security-spec.md に記載されています。動作を変更する場合は、src/network/outbound-scan.test.ts と src/engine/verify.test.ts が引き続きすべて成功する必要があります。初めての方におすすめの課題には good first issue ラベルが付いています。

HumanifyMe によってロボットのような文章になるのを防げたなら、GitHub で ⭐ を付けて、ぜひ広めてください。スターとコントリビューターが、このようなオープンソースプロジェクトを見つけてもらう力になります。

ライセンス

Apache License 2.0 です。LICENSE と NOTICE をご覧ください。リポジトリ全体がオープンソースで、書き換えエンジン、プロンプト、プライバシー上重要なモジュールも含まれています。そのため、どのデータがマシンの外部に送信されるか、されないかを誰でも正確に検証できます。「HumanifyMe」は Joshua McQueary の商標です。このライセンスは商標権を付与するものではありません。

参考文献 — 設計の基盤となった研究（各タイトルは、リンク先が有効であることを確認済みの正式公開版にリンクしています）

プロジェクトの先行研究調査をもとにしています。

1. Stamatatos。A Survey of Modern Authorship Attribution Methods。JASIST、2009年。
2. Koppel、Schler、Argamon。Computational Methods in Authorship Attribution。JASIST、2009年。
3. Abbasi、Chen。Writeprints。ACM TOIS、2008年。
4. Patel ほか。LISA: Learning Interpretable Style Embeddings。Findings of EMNLP、2023年。
5. Stamatatos、Bevendorff ほか。PAN 2023 Cross-Discourse Authorship Verification Overview。CLEF 2023 Working Notes（CEUR-WS）。
6. Salemi、Zamani。RAG vs PEFT for Privacy-Preserving Personalization。ICTIR（ACM SIGIR）、2025年。
7. Li ほか。Teach LLMs to Personalize、2023年。
8. Neelakanteswara ほか。RAGs to Style。ACL の Personalize、2024年。
9. Wegmann、Schraagen、Nguyen。Same Author or Just Same Topic? ACL の RepL4NLP、2022年。
10. Wang ほか。Can Authorship Representation Learning Capture Stylistic Features? TACL、2023年。
11. Krishna、Wieting、Iyyer。STRAP。EMNLP、2020年。
12. Patel、Andrews、Callison-Burch。STYLL、2022年。
13. Wang ほか。Catch Me If You Can? Not Yet。Findings of EMNLP、2025年。
14. Sadasivan ほか。Can AI-Generated Text Be Reliably Detected? TMLR、2024年。
15. Rivera-Soto ほか。Few-Shot Detection of Machine-Generated Text Using Style Representations。ICLR、2024年。
16. Jangra ほか。Evaluating Style-Personalized Text Generation、2025年。
17. Jin ほか。A Survey of Deep Learning for Text Style Transfer。Computational Linguistics（MIT Press）、2022年。