-
Notifications
You must be signed in to change notification settings - Fork 0
research notes
v0.5.0の一括拡充で参照した資料と、採否の考察を記録します。 以後の拡充もこのノートに追記し、「なぜ入れたか・なぜ入れなかったか」を残します。
- textlint-rule-preset-ai-writing のno-ai-hype-expressions (MIT)。絶対性・抽象性・予言的の3分類25表現
- AIっぽい文章表現大全 (note)。 記号・リズム・導入・スタンス・語彙・比喩の6分類
- 日本語記事を書いたAIを見分ける方法 (Qiita)。 頻出語彙と構成の癖
- 実際の対話・レビューでの指摘 (核・緑・章番号参照など)
- AI出力に過剰出現し、かつ情報が欠けている表現であること
- 共起条件で誤検出を絞れること。絞れないものはmanualか不採用
- 正当な用法がある語は、負例 (deny_examples) とnegativeコーパスで保護できること
比喩: 北極星 最後のピース 最強の武器 化学反応 彩る 切り拓く 時代が到来
潤滑油 成長のエンジン 成功のレシピ スパイス。
誇張: 魔法のよう 究極の 完璧なソリューション 驚異的な 異次元の に違いありません
間違いなし 可能性を解き放つ 再定義 未来を変える 根本的に変革。
空虚な抽象: 価値を提供 寄り添う 想いをカタチに 実現に貢献 珠玉の 民主化。
構文: それだけではありません ご存知でしょうか 想像してみてください の世界へようこそ
紐解く 一概には言えません メリットもあればデメリットも 解説していきます。
翻訳調: 興味深いことに することを可能にします 重要な役割を果たします 言うまでもなく。
締め: ぜひお試しください してみてはいかがでしょうか 最後までお読みいただき〜
注目を集めています。
| 表現 | 不採用の理由 |
|---|---|
大幅に 最高の 最先端の 次世代の
|
人間の報道・広報が通常使用。頻度だけではAI固有と言えない |
世界初の |
事実であれば書くべき情報。真偽の問題であり文体の問題ではない |
奇跡的な 不可避
|
報道の通常語彙 (奇跡的に助かった、衝突は不可避) |
銀の弾丸 車輪の再発明 ボトルネック 技術的負債
|
エンジニアリングの定着した術語 |
見える化 解像度が上がる
|
人間のビジネス文書で広く定着。AI判別力が低い |
一方で 〜と考えられます 結論から言うと
|
学術・技術文書の標準的な言い回し |
追い風 事業の柱 一枚岩 氷山の一角 試金石
|
日本語として定着した比喩。新聞が常用する |
| 語尾の単調さ・接続詞の多用・文章温度 | 語の検出では判定できない。文体全体の問題としてmanual圏 |
第一に/第二に の小論文構成 |
構成自体は正当。過剰かどうかは文脈判断で、機械化しない |
判別の軸は「人間の熟練した書き手が使うか」です。使うなら、それは日本語の資産であって クリシェではありません。頻度ではなく所属で判定します。
formatting/jp-en-space (和欧間スペース) は、人間のスタイルガイドでも採否が分かれる
組版規範です。本辞書では利用者の明示指示 (機械生成の書式の癖として全面禁止) に従い
errorで収録しました。一方、和欧間スペースを一貫して採っている既存の文書資産に
CIごと適用すると全件がerrorになるため、辞書のseverityを下げるのではなく、
プロジェクト設定 (.deadclicherc.json の disable / overrides) で無効化・降格
できる層を用意しています。判定の正しさと、導入先の組版方針は別の問題として扱います。
- broken-emphasisは行単位で対を数えるため、段落内で行をまたぐ太字 (openerとcloserが 別の行) を崩れと誤判定します。実データ (wiki) で1件発生し、内容側を平文化して解消 しました。段落単位の対応はコストに見合うか未判断です
- Bash経由のフック検査は「コマンド文字列に現れ、直近120秒に更新されたファイル」という 近似です。パスを変数に入れて書くコマンドは検出できません
- の一括適用で、用語集や対応表として機能していた 「- 用語: 説明」形式が平文化され、定義と説明の境界が「:」だけになる箇所が出た。 この形式は箇条書きではなく表にすると意図が保てる (ルールのaskに追記済み)
- 決定論的な はコードフェンス内を書き換えない (回帰テストで固定)。一方、 ルールの一括置換を自前スクリプトで行う場合はフェンス除外を自分で持つ必要がある
Wikiへの一括適用134箇所のうち133箇所が書式の修正 (和欧間スペース・太字リスト・ 絵文字・記号参照・行末コロン) で、文章としての改善は生まれなかった、という評価を受けて 該当コミットは差し戻された。ここから確認できることは次の2点である。
- 検出ゼロは品質の証明ではない。辞書にある表現の有無しか見ておらず、無意味な文でも 検出ゼロになる。UIとCLIの文言を「既知のパターンは見つかりませんでした」に改め、 判定範囲を明示した
- 検出ゼロを運用目標にすると、労力が書式の均しへ向かい、文章の改善から遠ざかる。 warn/errorであっても、適用後に可読性が下がる変更は行わず理由を報告する運用が要る (用語集として機能していた太字リストの平文化が実例)
このツールの適性は、AI特有の言い回しが混ざった文の発見と、書き手がそれを直すかどうかを 判断する材料の提示までである。文章の質そのものは書き手が担う。
逐次の指摘に頼ると、気づいた表現しか辞書に入りません。AI生成文と人間の文章の n-gram頻度を比べ、AI側に過剰出現する表現を候補として出す道具を置きました。
npm run mine -- --ai <AI生成文のパス> --human <人間の文章のパス> --top 50
- 文字n-gram (既定3〜8字) を数え、100万あたりの出現率の比で並べます
- 区切り記号と英数字を跨ぐ候補は数えません。語のまとまりにならないためです
- 窓をずらしただけの重なりは1件にまとめます (分岐がある箇所ではつなぎません)
- 辞書が既に検出する候補は既定で隠します (
--include-knownで出ます) - 長すぎる一致 (既定20字超) はコーパス内の重複文とみなして落とします
コーパス自体はこのリポジトリに置きません。出典の権利と、業務文書が混ざる危険が あるためです。手元のコーパスを指定して使います。
出力はそのまま辞書に入れません。上の「採用の基準」で人が判断します。LLMは候補の why / ask / 例文の下書きにだけ使い、検出には使いません。
- 候補を見つけたら、まずこのノートに採否と理由を書く
- 採用する場合は該当カテゴリのrules/*.ymlに1エントリ追加し、正当な用法があれば deny_examplesとnegativeコーパスに負例を足す
- 機械的な候補採掘は
npm run mineで行う (上の節)