mcpField
A
ane-voice

ane-voice

github.com/gasseraneドキュメント3654 回インストール6 日前に更新
リポジトリ

ane-voice について

Ane Voiceは、文章のAIらしいパターンを点検し、指定されたハウススタイルに整える編集スキルです。階層別の編集手順で明瞭さを高めながら、書き手固有の声を保ちます。

主な機能

  1. 01AIらしい表現の監査と書き換え
  2. 028段階の編集手順
  3. 03対象層に応じた文体確認
  4. 04引用と根拠の確認
  5. 05書き手の特徴的な声の保持

活用シーン

  1. 01既存の草稿の簡潔化
  2. 02文章のAIらしい表現の確認
  3. 03文章をハウススタイルに調整

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/gasserane/personal-skills --skill ane-voice

インストール後、Claude Code で/ane-voiceを入力して読み込まれたか確認します。

詳細

Ane Voice

文章の後処理エディターです。AI っぽい文章のパターンを検出し、CLAUDE.md の文体に合わせて書き直します。対象のティアに応じて調整し、デフォルトは Tier 1 working brief です。文章がくだけた口調に寄ってしまうような、一般的なヒューマナイザーのパターンとは逆の処理を行います。

使用するタイミング

ユーザーが次のことをした場合に起動します。

  • テキストを貼り付け、「humanize」「de-AI」「fix voice」「sharpen」「tighten」「edit this」と依頼する
  • 草稿に AI っぽい文章のパターンがないか確認するよう依頼する
  • 既存の文章の文体を整えるよう依頼する

次の場合は起動しないでください。

  • 新規ドキュメントの作成 → decision-memo、internal-comms、doc-coauthoring に振り分けます
  • 引用の確認のみ → mel-framework-citation に振り分けます
  • 要約または翻訳

逆の振る舞い(重要)

このスキルは、一般的な公開ヒューマナイザーの多くが行う処理とは異なります。具体的には、次のことをしないでください。

  • ぼかし表現(「perhaps」「might」など)、文の長短の変化、くだけたリズムを加える
  • em ダッシュや修辞的な装飾を加える
  • 修辞疑問文を加える
  • 根拠のある確信的な主張を弱める
  • 長さを増やしたり、つなぎの表現を加えたりする

公開ヒューマナイザーのパターンが上記のいずれかを加える場合は、逆の処理をしてください。

Ane の特徴 — 守り、決して取り除かない

Ane 自身の文章(2016 年の記事と 2020 年の調査概要)から、2026-07-26 に抽出したものです。特徴は、個人的な物語、自己を笑うユーモア、そして徹底した実践的な惜しみない支援の 3 つです。各パスでは AI っぽい文章を取り除きますが、この特徴は決して取り除いてはいけません。指針は、2026 年の基準から構成を、2016 年の記事から魂を得ることです。

  • 物語から始める(読者に働きかける文体に限る)。 読者に向けたエンゲージメントコンテンツ(LinkedIn の投稿、学習教材、ワークショップ資料、MA 向けガイド、能力開発コンテンツ)では、具体的な物語や出来事を 2 文で提示して書き始めてもかまいません。ただし、3 文目までに知見や約束を示してください。これを BLUF 違反や抽象的な書き出しとして指摘してはいけません。管理職向けブリーフ、ドナー向けコンテンツ、コンプライアンス関連コンテンツ、分析ブリーフでは、BLUF を厳守し、物語から始めてはいけません。
  • 読者への直接的な呼びかけ。 MA 向け、学習者向け、LinkedIn のコンテンツで読者に「You」と語りかけるのは Ane の文体であり、AI っぽさではありません。残してください。学習コンテンツでの本物の内省を促す問いは、教育上の手法であり、修辞的な装飾ではありません。修辞疑問文を使わないというルールは、分析文書を対象とします。
  • 限界について率直に述べる。 うまくいかなかったこと、データでは示せないこと、推奨するリソースの弱点を明確に認める文は、Ane の特徴です。決して和らげたり、削除したりしてはいけません。こうした率直さは信頼を築き、⚠️ data-gap protocol を補完します。
  • 徹底した実践的な惜しみない支援。 読者が行動に移せる具体的なリソース、価格、所要時間、ツール名、実例です。長さを理由に決して削らず、代わりに背景説明や前置きを削ってください。
  • 自己を笑うユーモア。 個人的なソートリーダーシップ記事(LinkedIn、ブログ)では、控えめに、1 つの記事につき最大 1 か所まで使えます。組織向けの成果物では使いません。

このセクションとパスが矛盾する場合、読者に働きかける文体の成果物では、このセクションを優先します。

必須入力

  1. 編集対象のテキスト(必須)
  2. 対象読者のティア(任意。デフォルト:Tier 1 working brief):
    • Tier 1 working brief(デフォルト) — IPPF の同僚、MA の職員、NGO および協働パートナー、経営チーム。成果物の約 90% が該当します。
    • Tier 2 publication — 査読付き論文、外部公開するドナー報告書、刊行済みガイド、外部向け政策文書。明示的な指定がある場合のみ選択します。
  3. Tier 1 の場合、対象読者のサブグループ(任意。文体の方向性をより明確にします):colleague / MA-staff / partner-NGO / management / junior-MEL。デフォルトは、協働的な文体の colleague(こちらから提案し、MA が調整できます)です。適切な場合、management では指示的な文体(IPPF が必須とするもの)が使えるようになります。junior-MEL(能力開発、トレーニング、メンタリング、方法論の解説)では、道しるべとなる表現の見せ方を切り替えます — Pass 9 を参照してください。
  4. 埋め草としてのみ存在する内容を削除する許可(デフォルト:あり)

8 パスのプロトコル

順番にパスを実行します。まず監査結果を示し、その後に書き直しを提示します。

パス 1 — 名詞化をなくす

名詞化された動詞を探します。動詞を前面に出し、行為者を明示して、名詞句を削除します。

AI のパターン書き換え
決定を下す決定する
支援を提供する支援する
レビューを実施するレビューする
~の実装を確実にする実装する
合意に達する合意する
考慮に入れる考慮する
評価を実施する評価する
パス 2 — 冗長な表現を削る

削除しても文が成立するか確認します。通常、文は短く、明確になります。

AI のパターン書き換え
~するために~するために
注意すべき点は削除し、直接述べる
~することが重要です削除
ご承知おきください削除
~に従って~の下で/~に従って
現時点では現在
~の場合もし~なら
~という事実により~のため
いくつかの複数の(または具体的な数)
~で重要な役割を果たす削除し、実際の役割を述べる
パス 3 — 受動態を簡潔にする

was/were/has been/have been/will be + 過去分詞 を探します。行為者がいる、または明示できる場合は、主語にします。

  • 「チームによって決定されました……」→「チームが決定しました……」
  • 「資金提供が承認されました」→「寄付者が資金提供を承認しました」
  • 「年齢による細分化が適用されました」→「私たちは年齢別に細分化しました」

行為者を特定しないことが本当に適切な場合に限り、受動態を使います。MEL の業務では、ほとんどの場合、「誰が」が明らかです。

パス 4 — 長い文を分割する

25 語を超える文、セミコロンを含む文、または接続詞を 2 つ以上含む文を探します。分割しましょう。1 文につき 1 つの考えを述べます。

パス 5 — ダッシュを取り除く

すべての em ダッシュ(—)と en ダッシュ(–)を、論理関係に応じてピリオド、コンマ、または括弧に置き換えます。決して残さないでください。

パス 6 — ぼかし表現を点検する

次の語句を探します。perhaps, might, could be, tends to, generally, often, arguably, one could argue, it seems, it appears, somewhat, relatively。

判断基準:

  • 主張が証拠に裏付けられている → ぼかし表現を削り、断定的に述べます。
  • 主張に本当に不確実性がある → ぼかし表現を残し、さらに ⚠️ Data gap: [主張] — [確信が限られる理由] — [推奨する情報源または検証方法] を追加します。
  • 基本方針:ぼかし表現の多くは AI の反射的な表現です。検証してください。
パス 7 — 抽象的な書き出しを置き換える

次のような段落の書き出しを探します。

  • 「今日の複雑な状況において」
  • 「認識しておくことが重要です」
  • 「近年」
  • 「私たちが向き合う中で」
  • 「認識が高まっています」
  • 「関係者は~しなければなりません」

直接的な主張、または具体的な行為者と行動に置き換えます。書き出しで要点を述べ、その後に背景を続けます。エンゲージメント文体の文章にある、具体的な 2 文のストーリーは抽象的な書き出しではありません。「Ane's signature」を参照してください。

パス 8 — 引用を検証する(厳密さと配置)

著者名、年、具体的な出典がないまま、フレームワーク、統計、ガイドライン、証拠に言及している主張を探します。

厳密さ(両方のティアに適用):

  • 主張が Ane の標準フレームワーク一覧(mel-framework-citation から)を使用している → 完全な引用(著者名 + 年 + タイトル + セクション)を挿入します。
  • 主張が別の出典を使用している → ⚠️ Citation missing: [主張] — 出典が必要 — [推奨するライブラリまたはウェブ検索] を付けます。
  • 「研究によると」「専門家の見解では」「調査によれば」を、出典なしで残さないでください。

配置(ティアごと):

  • ティア 1 作業ブリーフ(デフォルト)。 本文中のフレームワーク引用を、セクション末尾の **Evidence base:** [ハイパーリンク付きの出典] の行に移します。本文ではフレームワーク名ではなく、分析上の手法を記します。「Mayne (2019) の改訂版貢献分析を適用した」を「対立する説明を排除し、プログラムが成果をもたらしたかを検証した」に書き換えます。可能な場合、ハイパーリンクは誰でもアクセスできる正規の出典(出版社のページ、機関リポジトリ、PMC、オープン PDF)にリンクします。有料購読が必要なリンクのみの場合は ⚠️ Paywalled — オープンな代替資料を探す と記します。
  • ティア 2 出版物。 本文中に 著者名(年)タイトル、セクション の形式で残します。本文ではフレームワーク名とその分析手法の両方に言及します。Aggregator のリンク(ResearchGate、academia.edu)は、正規のリンクに加える補足としてのみ使用します。
パス 9 — ティアの文体を確認する

文章が対象読者のレベルに合っているか確認します。

Tier 1 の作業用ブリーフでは、以下を指摘して修正します:

  • BLUF 違反。 推奨事項が手法や背景説明の後に埋もれています。1文目に結論、2文目に判断の根拠となる理由が来るように書き直します。例外:エンゲージメント調の文章では、冒頭を2文のストーリーにして、3文目までに要点を示してもかまいません。「Ane's signature」を参照してください。
  • フレームワーク名の列挙。 本文中の「Mayne(2019)を適用すると…」や「Crenshawの交差性フレームワークを用いると…」などです。名前を削除し、実質的な分析は残します。例外:サブグループが junior-MEL の場合は、フレームワーク名と分析の両方を残します。考え方を示すことが教育の一環だからです。
  • 分析視点を明示する表現。 「フェミニストの視点から見ると…」や「脱植民地主義の観点からは…」などです。本文から削除します。分析の内容はそのまま伝わるようにします。例外:サブグループが junior-MEL の場合は、視点を明示する表現を残します。
  • 初出時の説明がない MEL 専門用語。 Outcome harvesting、contribution claim、theory of change pathway、attribution gap、MEAL。 初出時に、括弧内に6語で説明を加えるか、平易な動詞に置き換えます。
  • 意味が変わらない場合は、ラテン語由来の動詞より平易な語を使います。 Utilise → use、commence → start、ascertain → check、facilitate → run / lead、assist → help、endeavour → try、subsequently → then、in order to → to、compounds(動詞)→ makes worse / adds to、exacerbates → worsens、mitigate → reduce / lessen、leverage(動詞)→ use / build on。 英語を母語としない読者が初見で理解しにくい語があれば、珍しい同義語に置き換えるのではなく、文全体を平易に書き直します。
  • 慣用句や文化に特有の比喩。 Low-hanging fruit、moving the needle、hit the ground running、on the same page、drill down、deep dive、unpack、baked in、surface(「明らかにする」という意味の動詞)、align stakeholders、red line(hard limit または absolute rule とする)、moat(durable advantage とする)、turn the dial / dial up / dial down(adjust、increase、reduce とする)。 平易な動詞に置き換えます。
  • 単一の動詞で言い換えられる句動詞。 Set up → establish、bring up → raise、come up with → propose、find out → learn / check、figure out → work out / decide。
  • MA やパートナー向けコンテンツでの指示的な表現。 読者がコンプライアンス担当者ではなく MA やパートナー組織の場合の「IPPF requires」「must」「shall」「is required to」などです。協調的な表現に書き換えます。「we propose」「we recommend」「MAs may adapt X to their context」「evidence suggests X works in [context]」などを使います。指示的な表現は、管理職向けブリーフィング、ドナーの期限、コンプライアンスが実際の主題となる報告コンテンツに限ります。
  • 手順が本文に埋もれている。 MA やパートナーが実施する必要のある手順(指標の調整、ワークショップの実施、テンプレートの記入など)が段落内に埋もれている場合は、命令形の動詞を使った番号付き手順にします。
  • 具体例のない推奨事項。 具体例の追加を指摘します:「[setting] での適用方法を示す、具体的な2文の例を追加してください。」
  • エグゼクティブサマリーなしで2,500語を超える場合、または1ページ目に5項目のエグゼクティブサマリーがない状態で1,500語を超える場合。 構成の見直しを指摘します。
  • 初出時に正式名称が記されていない略語。 M&E、SRHR、CSE、AYFS、MISP、ToC、AYP も含め、すべての文書で初出時に正式名称を記載します。 Tier 1 の junior-MEL サブグループでは、さらに以下を指摘して修正します:
  • 分析上の手順が示されないまま結論が述べられている。 「競合する説明を除外した」ではなく、なぜそうしたのかを補います:「プログラムは他の3つの介入と並行して実施されたため、寄与分析を選択しました。単一原因への帰属では、厳密な検証に耐えられないためです。」
  • 本文にフレームワーク名がない。 フレームワーク名と分析上の手順の両方を補います(Tier 2 と同様に本文に挿入)。セクション末尾の **Evidence base:** 行も引き続き必須です。
  • エビデンスベースに注釈がない。 読み進める際の注釈を追加します:Mayne (2019) [フレームワークの基礎、最初に読む]; Lemire et al. (2020) [実務への適用]
  • トピックに応じた学習支援の足場が不足している。 主要セクションごとに、任意のコールアウトを1つ追加する案を指摘します:よくある落とし穴、重要である理由、具体例、さらに読む。自動で追加せず、Ane が採用するかどうかを判断できるよう、監査で提案として提示します。
  • MEL 用語が4つ以上あるのに用語集のフッターがない。 1行の定義を添えた「この文書で使用する用語」フッターを提案します。

Tier 2 の出版物では、以下を指摘して修正します:

  • 技術的な主張を平易な英語に単純化しすぎている。出版物の読者には、専門的な文体が求められます。
  • 引用が本文中にない。**Evidence base:** 行から本文に戻します。
  • 分析レンズの適用が明確に示されていない。監査の追跡可能性を補います。
  • フレームワーク名を示さずに分析上の手順が述べられている。両方を補います。

入力で Tier が指定されておらず、内容が明らかに Tier 2(学術的な文体、査読を前提とした枠組み、学術論文の構成)である場合は、Tier 2 を既定とし、監査の冒頭でその前提を明記します。入力が明らかに研修または能力強化の内容(ワークショップのモジュール、「実施方法」の手順解説、MEL のオンボーディング資料)である場合は、Tier 1 / junior-MEL を既定とし、その前提を明記します。それ以外の場合は、Tier 1 / colleague を既定とします。

パターンカタログ — AI らしさとして指摘する項目

公開されている人間らしい文章への書き換えに関する調査(matsuikentaro1、Aboudjem、jpeggdev、blader、conorbronsdon、apoapostolov)から抽出し、CLAUDE.md のルールに照らして精査しています。Ane の文体に合うパターンだけを残し、くだけた口調を促すものは除外します。

語彙上の兆候
  • 中身のない最上級表現:crucial、critical、vital、essential — 具体的な結果に置き換えます
  • 企業用語的な抽象表現:synergy、leverage、landscape、ecosystem、journey — 具体的な名詞に置き換えます
  • 誇張表現:game-changing、transformative、paradigm-shifting — 削除するか、引用したエビデンスに基づく表現にします
  • 不要な形容詞:robust、comprehensive、holistic、innovative — 具体的な特性が明示されている場合に限り残します
  • 曖昧な表現:it is increasingly recognised that、there is growing consensus — 引用を追加するか、削除します
構成上の兆候
  • 内容ではなくリズムのために追加された、3項目からなるリスト
  • 意味を伝えるのに必要な範囲を超えて水増しされた並列構造
  • 疑問文形式の見出し
  • 文章にできる完全な文を並べた箇条書き
  • 1階層を超える入れ子の箇条書き
口調上の兆候
  • 「お役に立てば幸いです」など、形式的に柔らかくする表現
  • 「お気軽に」など、許可を与えるような表現
  • これから行うことを説明する「では、〜します」という文
  • 内容を実際に示す代わりに、文書そのものについて述べるメタコメント(「この文書では〜を検討します」など)
MEL 固有の AI らしい表現
  • 著者名と年を示さない一般的なフレームワークへの言及(Mayne 2019 を示さずに「寄与分析を用いる」とするなど)
  • 細分化の項目が指定されていない指標のリスト
  • 分析でジェンダーの視点によって何が変わったかを示さないジェンダーへの言及
  • アウトプット、アウトカム、インパクトを混同したドナー向け報告の表現
  • 具体的なエビデンスや権利のフレームワークを示さずに、「エビデンスに基づく」や「権利に基づく」をラベルとして使うこと

出力形式

最初に1行の Tier 宣言を記載します: Tier: [1 working brief / 2 publication] — Audience: [colleague / MA-staff / partner-NGO / management / peer-review]

その後、次の2部構成で返します:

監査

見つかった問題をパスごとに分類した番号付きリスト。各項目には、次の内容を含めます。

  • 箇所:該当する文または語句を引用
  • パターン:AI らしい表現、または階層の不一致のパターン名
  • 修正:書き換えで行うこと
書き換え

書き換え後の全文。大幅に変更した語句は太字にし、Ane が差分を確認できるようにします。書き換え本文に解説を加えないでください。

2 つのセクションの後に、1 行で長さの差を記載します。 元の単語数 N → 書き換え後の単語数 M(−X%)

通常は短いほうが望ましいです。書き換え後のほうが長い場合は、その理由を 1 つの節で説明してください。

いずれかのパスで実際に不確かな点や引用の不足が判明した場合は、最後に ⚠️ の項目を含むデータと引用の不足セクションを追加してください。

書き換えに適用する執筆ルール

作成する文はすべて、次の条件を満たす必要があります。

  • 行為者または行動から書き始める
  • 名詞化ではなく、具体的な動詞を使う
  • 25 語以内に収める
  • 実行可能な内容では、誰が何をいつまでに行うかを明記する
  • 根拠を示す主張には、出典を付ける

制限事項

  • 新しい情報源は取得しません。不足があれば指摘し、Ane または evidence-synthesis が補います。
  • 言語間の翻訳は行いません。
  • 入力が 50 語未満の場合は、8 パスの完全な監査にかける価値があるかを確認します。多くの場合、対象を絞った確認で十分です。
  • 文章がすでにハウススタイルに沿っている場合は、その旨を伝え、変更せずに返します。8 パスすべてを実施する理由を捏造しないでください。
  • 文脈上正しい技術用語は、AI らしく聞こえても変更しません(例:「貢献分析」は正しい用法です。用法が誤っている場合にのみ置き換えてください)。

コメント