はじめに
私、絵文字の画風が苦手 なんです（笑）
カラフルなアイコンで感情を表すやり方は、人によってはとても伝わると思うんですが、私の記事だと なんか違う 感じがしてしまいます。
だからブログでは、昔ながらの 顔文字 でノリを足す派です (´▽｀)
ところが Cursor に「カジュアルに」「柔らかく」と頼むと、返ってくるのはだいたい 絵文字 です。
さらに「顔文字多めで」と言うと、今度は 知らない顔文字の洪水 が来る。
しかも Markdown 上では (´・ω・\) が斜体になったり、*ﾟДﾟ)ﾄﾞｷﾄﾞｷ` が太字になったり、プレビューで見ると 別人 になっている……。
怖いですよね。*ﾟДﾟ)ﾄﾞｷﾄﾞｷ
この記事は、「絵文字ではなく顔文字で書きたい」という私の好みを、Qiita 執筆用 Agent Skill（qiita-blog-writing）の 顔文字ホワイトリスト に落とし込んだ話です。
技術的な大発見ではないですが、同じ悩みの人の参考になれば嬉しいです。
想定読者
- 絵文字より顔文字のほうがしっくりくる方
- Cursor に書かせると、勝手に絵文字が混ざる方
- Agent Skills で「文体」と「顔文字の好み」を分けて管理したい方
- Qiita Markdown で
*や_が顔文字を壊す話にうなずける方 - 真面目な手順記事より、失敗談のほうが読みやすい方 (=^･ω･^=)
私の属性
- 30代女性・事務職
- 絵文字はあまり使わない。顔文字でノリを足す派
- このブログは Qiita CLI + GitHub Actions で運用
- 執筆環境の話は Qiita Tech Festa 20記事を目指して整えた Cursor 執筆環境 にまとめ済み
- 顔文字は好き。でも 好き＝なんでも許可 ではない、と最近学びました m(_ _)m
きっかけ：AI は絵文字がデフォルトだった
執筆 Skill を育て始めた頃、私はこう思っていました。
- 文体は
style-guide.mdに書いてあれば AI が寄せてくれるはず - 顔文字は「そのときのノリ」で足してもらえばいいはず
- 多め、くらいなら問題ないはず
……はずだったんです (´・ω・`)
実際に起きたことは、絵文字と顔文字の 二段オチ でした。
| 依頼 | AI の返答の傾向 |
|---|---|
| カジュアルに書いて | 本文に 絵文字 が紛れ込む（私の画風と不一致） |
| 顔文字多めで | 絵文字は減るが、 新作顔文字 が増殖する |
| オチをつけて | 知らない顔文字か、また絵文字が末尾に鎮座する |
つまり AI から見ると、
- 絵文字 ＝ カジュアル表現の定番
- 顔文字 ＝ なんとなく足せる装飾
という理解になっているっぽいんです。
私にとっては真逆で、顔文字こそ定番、絵文字は使いたくない なんですが……。
しかも textlint は 顔文字の見た目も絵文字の有無も検証しません。
「AI 臭」はある程度拾ってくれるのに、表現の好みのズレはスルーされる。
整理すると、
- 文体 → 機械 + 人間でなんとかなる
- 絵文字 → デフォルトで入ってくる
- 顔文字 → 放置すると勝手に増える・化ける
という三層構造になっていたんです。｡｡｡(lll __ __)ﾊﾞﾀｯ
絵文字ではなく顔文字、を Skill に書く
方針は二つに絞りました。
- 絵文字は使わない（画風が合わないので）
- 使っていい顔文字だけをリスト化 し、それ以外はユーザー承認なしで追加しない
置き場所は style-guide.md ではなく、別ファイルの kaomoji-guide.md です。
| ファイル | 管理するもの |
|---|---|
style-guide.md |
文体・読みやすさ・AI 臭の排除 |
kaomoji-guide.md |
顔文字のホワイトリスト・Markdown 対策 |
文体と顔文字は 別管理 にしないと、どちらも中途半端に育ってしまう、という割り切りです。
「カジュアルに」と言ったとき絵文字が出ないようにするのも、結果的にこの分離のおかげです。
いまのホワイトリスト構成（ざっくり）
| カテゴリ | 例 | 用途イメージ |
|---|---|---|
| 基本 |
（笑） (*´▽｀*) (ﾉ´∀｀*)
|
締め・オチ・軽いユーモア |
| お気に入り |
|ω・*) ヾﾉ｡ÒдÓ)ﾉｼ ﾊﾞﾝﾊﾞﾝ!!
|
勢い・ちらっ・ドヤ |
| 猫・かわいい系 |
(=^･ω･^=) ฅ^•ﻌ•^ฅ U・ｪ・U
|
柔らかいトーンのとき |
絵文字の代わりに「かわいさ」を足したいときは、猫系の顔文字を使う、という使い分けです (=^･ｪ･^=)
追記ログもファイル内に残していて、「いつ・何を・なぜ足したか」が後から追えるようにしました。
2026-07-07 のログには、お気に入り 9 種と猫系 7 種を追加した、と書いてあります。
Skill 側のルールもこうです。
顔文字の追加・変更は
kaomoji-guide.mdのホワイトリスト承認後のみ
AI に「絵文字はやめて、好きな顔文字を創作もしないで」と口頭で頼むより、リストを見せる ほうが効きました。
人間の「絵文字は苦手・顔文字はこれ」と「創作意欲」は、リストの外側で止める。((( _( 'ω') ｺｿｺｿ
Markdown で壊れる顔文字たち
ホワイトリストを作っても、もう一段階ありました。
Qiita Markdown と相性の悪い顔文字 です。
絵文字はこの問題が少ない反面、「画風が合わない」。
顔文字は雰囲気は合う反面、** や _ に弱い。
| 文字 | 何が起きるか |
|---|---|
* |
斜体・太字のマーカーになる |
_ |
同上（__ は特に危険） |
` |
インラインコード扱い |
| |
表の区切りと誤認されやすい |
たとえば *ﾟДﾟ)ﾄﾞｷﾄﾞｷ は、先頭の * が Markdown を発狂させます。
素のまま書くと、プレビューでは \ で逃がした \*ﾟДﾟ)ﾄﾞｷﾄﾞｷ じゃないと、別物になります。
｡｡｡(lll __ __)ﾊﾞﾀｯ も __ が太字候補。
倒れてるはずなのに、画面上では 強調されて立ち上がる ことがあるんです。怖い。
なので kaomoji-guide.md には、顔文字ごとにこんなメモを付けています。
- 末尾の
*に注意 -
_多数。プレビュー必須 - 比較的安全
「比較的安全」という表現がまた地味に笑えるポイントなんですが、これは 100% 安全ではない という謙虚さです（笑）
プレビューが最終裁判
顔文字のホワイトリストは、textlint では判定できません。
絵文字が紛れ込んでいないかも、機械では見ません。
最終確認はいつもこれです。
npm run preview:draft -- 0015-qiita-kaomoji-whitelist
npm run preview
npm run cleanup:preview
執筆環境記事でも書いた通り、ブラウザで見るのが一番早い です。
顔文字の崩れも :::note も、プレビューしないと信用できない。
ホワイトリストに載せた顔文字でも、
- エスケープ漏れ
- 行頭の
| - 表の中に紛れ込んだ
などで化けることがあります。
だから推敲チェックリストにも「プレビューで表示崩れがないか」が入っています。
AI に任せきりにしない。でも毎回手打ちもしない。
リスト + プレビュー の二段構え、という落としどころです (_・ω・)_ﾊﾞｧﾝ…
意識していること
-
絵文字は使わない。カジュアルさは顔文字か
（笑）で足す - 記事あたり 3〜5 個 が通常の目安（今回みたいに「顔文字の話」だと意図的に多め、は例外）
- 見出し・表・コードブロックの中には顔文字を入れない
- 新しい顔文字は「かわいいから」ではなく 用途 + Markdown リスク で採用する
- 文体のルールと混ぜない（
style-guide.mdとkaomoji-guide.mdは分離）
あと、個人的な学びとして。
「顔文字多めで」は強力な依頼文だけど、コントロールなしだと多すぎ問題 になる
なので今は、
- 絵文字は出さない（画風の統一）
- ホワイトリストにある顔文字だけ使う
- 多めが欲しいときは 記事テーマとして明示 する（今回みたいに）
- それでもプレビューで顔を合わせる
という運用に寄せています。ヾﾉ｡ÒдÓ)ﾉｼ ﾊﾞﾝﾊﾞﾝ!!
まとめ
- 私は絵文字の画風が苦手で、ブログでは 顔文字でノリを足す 派
- その好みを Skill に書くと、AI のデフォルト（絵文字）とのズレがはっきり見えた
- 対策として
qiita-blog-writingにkaomoji-guide.mdを置き、ホワイトリスト + 用途メモ + エスケープ例 で管理している - 最終判定は
npm run preview。リストに載っていてもプレビューは必須
真面目なインフラ記事ではないですが、「絵文字は嫌・顔文字は好き」と言った側が、ホワイトリスト管理までやる羽目になる、というオチだけは本当です（笑）
同じように顔文字派で Cursor を使っている方が、好みだけ別ファイルに逃がす案を参考にしてもらえたら嬉しいです。
次はちゃんと技術の話も書きます。|ू•ω•)ﾁﾗｯ