mcpField
C
cw-ai-check

cw-ai-check

github.com/everyincクリエイティブ・メディア377218 回インストール6 週間前に更新
リポジトリ

cw-ai-check について

cw-ai-checkは、生成文に見られる特徴を見つけて整えるライティングスキルです。編集者や、意味と文体を保ちたい書き手向けに、表現より先に出典、確実性、論の構造を確認します。

主な機能

  1. 01出典と事実の範囲を確認
  2. 02論の過剰な収束を検出
  3. 03定型的な構成や表現を発見
  4. 04書き手の意味と文体を維持
  5. 05文章の修正または診断のみ

活用シーン

  1. 01モデルが起草・改稿した文章を確認
  2. 02生成文の特徴を原稿から取り除く
  3. 03書き換えずに問題点と修正案を得る

インストール

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

$npx skills add https://github.com/everyinc/compound-writing --skill cw-ai-check

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

同梱ファイルreferences/ai_tells_lexicon.csvreferences/structural-overcompletion.md

詳細

AI チェック

目的

文章を生成されたように感じさせる言語的、構造的、認識論的なパターンを特定し、書き手の意味、声、ユーモア、そして有用な奇妙さを損なわずに取り除きます。

生成された文章は、語彙よりも先に過剰な補完によってそれとわかることがよくあります。元の文章で裏付けられていない因果関係、対称性、感情的な意味、結論を補ってしまうのです。AI らしさを防ぐ第一の手段として、書き手が実際に知っていることへの忠実さを大切にしてください。

全文または原文に基づくスキャンを行う場合は、まず references/structural-overcompletion.md を読んでください。次に、語彙や文のパターンの残存要素を確認するため、references/ai_tells_lexicon.csv を読んでください。この語彙リストはパターン集として扱い、機械的な禁止リストとして扱わないでください。

動作

サイレントな適用

Draft または Line Edit に組み込む場合:

  • 生成または修正された文章をスキャンします。
  • 明らかな AI らしさを、作業内容を語らずに修正します。
  • 意味、出典、現在の文体のコンテキストを保ちます。
  • ユーザーには、そのまま使える文章だけを提示します。
手動での修正

ユーザーから AI らしさの除去や修正を求められた場合:

  1. まず修正済みの文章を提示します。
  2. 続けて、文書内の順序に沿った簡潔な修正記録を提示します。
  3. 求められない限り、カテゴリ、深刻度ラベル、信頼度スコアは省略します。

ユーザーが診断のみを明示的に求めた場合は、書き換えないでください。問題箇所を引用し、修正案を添えた順序付きチェックリストを返します。

スキャンの順序

以下の順序で確認します。単語のブラックリストから始めないでください。

  1. 出典との整合性: 原文で裏付けられていない詳細、動機、場面、原因、結果を削除するか、指摘します。
  2. 認識論的な忠実さ: 書き手が実際に抱いている確信の度合いを取り戻し、観察と解釈を区別します。
  3. 因果関係と論旨の完結: 文章を洗練させるために解消された矛盾や未知の点を、再び未解決の状態に戻します。
  4. 論旨に関する自己解説: 証拠を評価する、構成を予告する、主張の位置づけを示す、引用を提示する前に解釈する文を削ります。
  5. 構成と声の演出: 押しつけられた対称性、フレームワークへの過度な準拠、持続的な比喩、過剰に盛り込まれた決まり文句を見つけます。
  6. 読者と調査への姿勢: 根拠のない一般化や、権威を飾りとして使う表現を防ぎます。
  7. 語彙および文の残存要素: 以下のカテゴリと語彙リストを適用します。

完成済みの文章しかない場合は、原文との食い違いを作り出さないでください。出典に関する懸念は、質問または条件付きの指摘として表現します。例外は自己解説の確認です。これは原文がなくても必要であり、完成済みの文章に対して最大限の確信をもって適用します。

検出カテゴリ

0. 構造の過剰補完

以下のいずれかに当てはまる場合は、references/structural-overcompletion.md を読んでください。

  • 文章がモデルによって作成または大幅に修正された。
  • 比較対象となるメモ、書き起こし、調査資料、または以前の人間による草稿がある。
  • 既成の AI らしい語彙を避けているのに、まだ生成されたように感じられる(§11「論旨に関する自己解説」に特有の条件です)。
  • ユーザーが、文章が人間らしく聞こえるか、書きすぎではないか、洗練されすぎていないか、自分らしくないかを尋ねている。
  • AI の残存要素をすべてスキャンするよう求められている。

裏付けのない接続要素、強められた確信、整いすぎた因果関係の説明、ひとつの分類体系に無理やり当てはめられた例、不自然な密度で盛り込まれた声の演出、つながりを保つために延長された比喩、根拠なく読者に割り当てられた体験、そして書き手が実際にたどり着いたところ以上に決着をつける結びを指摘します。

修正: 原文の範囲に立ち戻ります。観察と解釈を分け、矛盾を残し、素材に沿って構成し、目立つ声の演出を適度に抑え、裏付けのある最も強い帰結または未解決の問いで締めくくります。

1. 汎用的な導入と書き出し

文脈のない書き出しには、次のようなものがあります。

  • 「今日の目まぐるしく変化する世界では」
  • 「[X]をめぐる絶えず変化する状況の中で」
  • 「[X]がある世界/時代では」
  • 「[X]の台頭に伴い」
  • 「[トレンド]が[X]し続ける中で」
  • 「[X]の領域では」
  • 「[X]を掘り下げてみましょう/分解してみましょう」
  • 「本質的に、[X]は[Y]です」
  • 「[X]に注目することが重要です/注目に値します」
  • 「一緒に[X]してみましょう」

修正方法: 具体的な事実、日付、場面、行動、または固有名詞から始めます。

2. AIらしさがにじむ語彙と不要な形式ばった表現

大げさな表現、曖昧な称賛、平易な言葉の代わりに使われる格調高い言葉には、次のようなものがあります。

  • delve、比喩的な意味での tapestry、reimagined、nuanced、multifaceted
  • leverage、utilize、harness、unlock、unleash、empower
  • pivotal、crucial、vital、significant、noteworthy、transformative
  • robust、seamless、comprehensive、meticulous、bespoke
  • foster、underscore、illuminate、endeavor、embark
  • elevate、amplify、optimize、spearhead、revolutionize
  • plethora、myriad、commence、facilitate、optimal、prior to、whilst、amongst

修正方法: 平易な動詞と具体的な名詞を使います。正確な専門用語がリストに含まれているというだけで、別の言葉に置き換えてはいけません。

3. 企業用語やMBA風の抽象表現

平易な主張を分かりにくくするビジネス用語には、次のようなものがあります。

  • problem space、solution space、value proposition
  • go-to-market motion、north star metric、operating cadence
  • [X]について考えるためのフレームワーク、[X]に関するメンタルモデル
  • pain points、actionable insights、key takeaways、move the needle
  • low-hanging fruit、circle back、touch base、strategic alignment
  • stakeholders、deliverables、digital transformation、paradigm shift

修正方法: 実際の問題、行動、人、決定、指標、または結果を具体的に述べます。

4. お決まりの定型表現と中身のない強調

次のような、汎用的な枠組みとして使われる表現には注意してください。

  • 「[X]について言えば」
  • 「実のところ、[X]です」
  • 「これまでになく今、[X]」
  • 「[X]として登場しました」
  • 「重要な節目となります」
  • 「[X]を証明するものです」
  • 「結局のところ」
  • 「一つだけはっきりしていることがあります」
  • 「今後は」
  • 「要するに」

修正方法: 前置きを削り、具体的な主張を述べます。

5. 中身のない類推や比喩表現

比喩が意味を加えず、文章を飾るだけの場合は注意してください。次の基準で判断します。

  • 削除テスト: 比較を取り除いても意味が変わりません。
  • 対応関係テスト: 二つの事柄に共通する仕組み、関係、または構造が、文章中で説明されていません。
  • 入れ替えテスト: 比喩の題材を別のものに差し替えても、意味がほとんど変わりません。
  • 言い換えテスト: 比喩の一文が、前後の文字どおりの文を繰り返しているだけです。
  • 効果テスト: 比喩によって、結果、推論、重要性、実感のある理解が加わっていません。
  • 再登場テスト: 文学的なつながりを保つために比喩が続いていますが、読者の思考を助けなくなっています。

また、「〜のタペストリー」「宝の山」「諸刃の剣」「氷山の一角」「未知の海域」「希望の光」「岐路に立つ」「成功への青写真」「交響曲/モザイク」のように使い古された比喩にも注意してください。

修正方法: 飾りを削り、文字どおりの主張を述べます。または、正確な対応関係と、それによって読者が理解しやすくなる点を示し、比喩に意味を持たせます。

保護する表現: 仕組みを明確にし、抽象的な内容を理解しやすくし、独自の推論を生み、重要性を際立たせ、または書き手ならではの視点を伝える、新鮮で具体的な比喩表現は残してください。比喩をすべてAIらしさの兆候と見なしてはいけません。

6. 埋め草、曖昧な表現、根拠のない熱意、いつまでも続く両論併記

次の表現に注意してください。

  • 強調として使われる「just」と、埋め草として使われる「actually」
  • 反射的に重ねられる不確実性を示す表現:might、could、perhaps、generally、arguably、potentially、somewhat、often
  • 「一般的に言えば」「そう主張することもできます」「ある程度は」「場合によります」
  • 「提供された情報に基づくと」
  • 「もちろんです!」「確かに!」「いい質問ですね!」「喜んでお手伝いします」
  • 「どちらの側にも妥当な主張があります」「メリットとデメリットがあります」「合理的な人でも意見が分かれることがあります」

修正方法: 中身のない婉曲表現や熱意を削除します。根拠をもって主張できる最も強い内容を述べ、実際の不確実性は正確に示します。

7. 形式的なつなぎ言葉と曖昧な権威付け

学術的なつなぎ言葉や、根拠を示さない主張の多用に注意してください。

  • moreover、furthermore、additionally、consequently、thus、hence、therefore
  • accordingly、notably、significantly、essentially、indeed、subsequently
  • not only...but also、whether...or
  • 「研究によると」「専門家の見解では」「調査結果は示しています」「最近の報道によると」

修正方法: 自然なつなぎ言葉を使うか、文の構成を見直します。証拠の出典を日付や数値とともに明記し、リンクするか、裏付けのない主張を削除します。

8. 相関表現と否定による対比

繰り返しや定型的な対比に注意してください。

  • 「XではなくY」
  • 「Xだけでなく、Yも」
  • 「Xだからではなく、Yだから」
  • 「大切なのはXではありません。Yです。」

修正方法: 肯定形で直接述べるか、簡潔に対比します。能動態で最も効果的な文になる場合に限り、単独の構文として残します。

9. 定型的な構成と大げさな演出

次の表現や構成に注意してください。

  • 「Xはない。Yもない。あるのはZだけ。」
  • 断定文を3つ並べる、または冗長な3項目の文
  • 緊迫感を演出する、繰り返しの断片文
  • 三つ並べる表現の過剰な使用
  • 対称的すぎるリスト、箇条書き、段落の長さ
  • 文章全体で文の長さが均一
  • 「主語+動詞+目的語、現在分詞+詳細」という構文の繰り返し
  • 最後に「and」を付けずに列挙を続ける
  • ありふれた発見を大げさに見せる劇的な種明かし
  • 何が変わったのかを述べない、曖昧な変化の説明

修正方法: 重複をまとめ、文のリズムに変化をつけ、接続詞を補い、大げさな演出を具体的な出来事、発見、または変化に置き換えます。

10. 格言めいた等式とAIらしい気の利いた表現

証明の代わりに、対称的で切り取りやすい言い回しを使っていないか注意してください。

  • 「YのないXは、ただのZ」
  • 「Xとは、Z向けのY」
  • 「Xを得るものは、Yを得る」
  • 「最良のXとは、[動詞]しないX」
  • 論文のように見せかけたツイートのような表現

修正方法: その主張を裏付ける具体例や証拠を示すか、主張を直接述べるか、削除します。

11. 定型的な締めくくり

次の表現に注意してください。

  • 「結論として」「要約すると」「まとめると」
  • 「全体として」「最終的には」
  • 記事の内容を繰り返すだけの結論
  • 「一つだけ明らかなことがあります」のような一般的な締めくくり

修正方法: 最も重要な示唆、具体的な次のステップ、または未解決の具体的な問いで締めくくります。

12. 論旨についての自己解説

修辞的な足場作りとも呼ばれます。論旨を展開する代わりに、文章が自らの論旨を説明しています。平易な言葉、短い文、語彙リストにはない表現です。そのため、ここに挙げたほかのどのカテゴリにも当てはまらず、見過ごされがちです。詳しくは references/structural-overcompletion.md §11 を参照してください。

次の4つのサブタイプに分類します。

  • 証拠の自己評価:「私たちが見つけた中で最も明快なもの」「良い点は測定可能なことです」「私を納得させた成果物」「ベンチマークはそれほど魅力的ではありません」
  • 構成の道案内:「読み解きのもう半分」「それから地図があります」「冗長さは表面にすぎません」「X がこれに境界を設けています」
  • 認識論的なラベル付け:「未解決の問いは」「2つの点は暫定的なままです」「ある結果が全体像を複雑にしています」
  • 引用の性格付け:「Mike が最も的確に述べています」「その不満は全員に共通していました」

次の2つのテストのうち、どちらか一方に当てはまれば十分です。

  • 削除テスト。 その表現を削除します。論旨が成り立ち、読者への案内だけが失われるなら、それは足場作りです。
  • 指示対象テスト。 対象ではなく文章そのものを指す名詞に印を付けます:読み解き、セクション、全体像、事例、証拠、要点、境界。

修正: 削除するか、解説をそれが説明していた内容に置き換えます。不確実性は、それを制限する事実として示します。転換は一語で表します。引用には、発言者とその人の役割を添えます。

保護: 両面のある所見を比較評価する表現は、世界についての主張であり、多くの場合必要です。「Mike の施工チェックによってホテルの選択が変わる可能性があります。HTML ページでは変わりません」は残します。「施工チェックのほうがより強い所見です」は削除します。公開時の引き継ぎに関する慣例はそのまま残します。

文脈に関するガードレール

該当する表現がすべて問題とは限りません。変更する前に、意図と分野を確認してください。

  • 一貫性と過剰な補完を混同しないでください。構成が素材を超えている、または素材を歪めている場合にのみ、その構成を指摘します。
  • 評価と自己解説を混同しないでください。所見を比較して判断するのは主張ですが、その判断を説明するのは足場作りです。
  • 文章を人間らしく見せるために、誤り、繰り返し、乱雑さを残さないでください。
  • 定型的な文章への対抗策として、奇をてらった具体性を作り出さないでください。具体性は原文に基づく必要があります。
  • 時間を表す「just」と、訂正を表す「actually」は残してください。
  • 根拠のある不確実性は残し、反射的または曖昧な婉曲表現だけを取り除いてください。
  • 正確な標準的な分野用語は残してください。
  • そのジャンルで本当に必要な形式的なつなぎ表現は残してください。
  • 意図的な皮肉や引用は残してください。
  • 意味を伝える類推や比喩は残してください。
  • 原文の確実性の度合いを保ち、慎重な主張を、その証拠以上に強めないでください。

出力形式

クリーンアップ
## Cleaned Copy

[Rewritten text]

---

## What Changed

1. Line/paragraph [N]: "[original]" -> "[revision]"
   Why: [brief explanation]

Summary: [X] AI tells removed. Primary patterns: [short list].
診断のみ
## Sequential Editing Checklist

□ Line/paragraph [N]: "[quoted problem]"
  -> [suggested fix]

ユーザー拡張

確認済みの反復的な癖を、維持管理されている語彙リストまたは基準となる文体の文脈に反映するには、/cw-save または明示的なフロー内のリクエストを使用してください。インストール済みのキャッシュを正本として編集しないでください。

コメント