mizchi-blog-style

mizchi Blog Style

mizchi 個人ブログ向けの文体評価 skill。記事を書いた後に「mizchi 文体度」と「AI 臭度」を判定させて反復改善する。

一般的な日本語の自然文の規範は natural-writing-ja、AI 指数の測定手法は ai-index にある。 本 skill はその上に乗る声固有の層だけを扱う。

すべての数値は実測。zenn API から 18 本 (2025-06〜2026-09)、コードブロックを除いた 散文 937 文 / 766 段落 / 64,340 文字を計測した。再現手順は ../ai-index/references/calibration.md。

先に結論: マーカーを追うと失敗する

この skill は当初、口語・文末・自分 の出現レートで採点していた。それで書かせた記事が 「っぽい」と言われたので測り直したら、原因がはっきりした。

成分	mizchi 実測	未編集 AI	マーカー最適化した原稿
文 / 段落	1.4	2.5	3.3
一文段落の割合	64%	15%	13%
5 文以上の段落	0%	0%	23%
冒頭段落の文数	1〜2	3	3

マーカーレート (自分 11.1 対実測 11.5、文長 40 字対 43.6) はすべて目標圏に入れたうえで、 段落の形は未編集 AI より遠かった。粒度では AI のほうが正解に近い。

語句は合っていて形が違う文章は、パロディに見える。だから採点は構造から始める。 マーカーは下限チェックにしか使わない (§4)。

1. 構造成分 (これが本体)

python3 ../ai-index/scripts/slopscore.py --lang ja draft.md が全部出す。

1.1 段落 = 1 文

最重要。766 段落の実測分布:

1 文 = 64%   2 文 = 29%   3 文 = 6%   4 文 = 1%   5 文以上 = 0%
平均 1.45 文 / 段落

5 文以上の段落は 18 本でゼロ件。3 文以上でも 7% しかない。

これは Zenn のレンダリング都合ではない。連続する <p> の元行番号を調べたら、 差が 1 (単一改行) のペアは 0% で、全部に空行が入っていた。意図的な改行である。

書くときの操作はこれだけ。文を書いたら空行を入れる。 2 文つなげるのは、 2 文目が 1 文目の言い直しや直接の帰結であるときだけ。

ただし「一文段落だから短い」は完全に間違い。 313 個の一文段落を測ると:

平均 48.8 字   中央値 43   70 字以上が 18%
十分位 [18, 27, 34, 38, 43, 51, 59, 68, 89]

段落全体の平均文長 44.5 字より、一文段落のほうが長い (48.8 字)。 一文で切るからこそ、その一文が限定節を抱え込む。

長い一文は が / ので / のだが / ですが で従属節を中に持つ形になる。実物:

抽象度もちょうど良く、Rust では頻出するライフタイムや低レベルのバイナリ操作が隠蔽されていて
高水準な記述ができるので、システムプログラミングだけではなくアプリケーション層にも最適です。

LSP という視点でみたときに、これらはプロジェクト、ファイル、カーソル位置におけるアクション
という命令セットになっているのだが、実際 AI 向けには非効率なのではという直感を得ている。

まだ自分も Quint を試し始めたところですが、分散システムの「たぶん危ない」を
「この値と順番で壊れる」に変える道具として、かなり手応えがありました。

段落を割るときに、限定節まで別の短文へ割ってはいけない。 これをやると 一文段落の形は合うのに平均文長が 33 字まで落ちて、刻んだ印象だけが残る (この skill の開発中に一度やった)。割るのは段落、束ねるのは節である。

2 文段落 (29%) は「主張 + それを解消する文」の組。2 文目が理由・数値・帰結・ 判断のどれかで 1 文目を discharge している。

そして lint はこれを検出できない。判定の根拠にできるシグナルが、一つも立っていないからだ。
jev は単に速いモデルというわけではありません。意図的に出力を限定することで、その精度と速度を得る最適化を行います。
人生で5度目ぐらいの Markdown Editor 実装をしました。今回が最速です。

✗ 3 文以上の塊 (LLM が既定で出す形)
  洗浄版が 0 件になった。自分の本物の記事 18 本のうち 5 本に勝って残り 13 本と
  同点、という点数を、中身が空っぽのまま取っている。表層シグナルは
  find-and-replace で消える側の性質だけを見ていたことになる。

✓ 一文ずつ
  洗浄版が 0 件になった。

  本物の記事 18 本のうち 5 本に勝って、残り 13 本と同点。中身は空っぽのまま。

  表層シグナルは、find-and-replace で消える側の性質だけを見ていたことになる。

1.2 見出しは名詞ラベル

149 / 178 = 84% が名詞句。 問い 9%、文 7%。中央値 12 文字、41% が 10 文字以下。

✓ ラベル (84%)  作ったもの / 実装手順 / 先行事例の紹介 / 学び・苦労した点 / 今後やりたいこと
✓ 問い (9%)     なぜ作ったか / で、使えるの？ / Jev で何が変わるか
△ 文 (7%)       WPT 通すのがしんどい！ / ノードの再計算は最初から考慮した方がいい

文形の見出しは 7% しかない。論評を見出しに書く (自分のシグナルが 3 つ死んだ) のは 英語圏のテックブログの形で、mizchi 文体ではない。節の中身に名前を付けるだけにする。

文形を使うなら、上の 2 例のようにその節で分かったことそのものを書く。要約ではなく結論。

1.3 コードは 100 文字ごとに戻ってくる

コードブロック間の散文は 中央値 102 文字 / ブロック数 2。平均は 311 文字だが、 分布は下に偏っている。

つまり散文が 2 段落続いたら、次はコード・表・出力例が入る。抽象論が 1,000 文字 続く区間は存在しない。1 記事あたりコードブロック 4.7 個、インラインコード 13.4 個、 リンク 17.3 本。

1.4 節の長さは非対称

節あたり中央値 313 文字、CV 0.57〜0.70、最短 18 文字・最長 1,180 文字。 1 記事の見出し数は中央値 10 (レンジ 1〜22)。

18 文字の節が実在する。「全節を同じ厚みにする」のが AI の形で、mizchi は 書くことがある節だけ長い。

1.5 冒頭は 1〜2 文の「機会」

18 本中 11 本が 1 文、7 本が 2 文。中央値 49 文字。箇条書きは 17/18 でゼロ。

Jev を一晩叩いたので、その感想を書きます。タイトルは超大雑把な要約です。
前々から自作ブラウザを作ってみたかったんですよね。作ります。
人生で5度目ぐらいの Markdown Editor 実装をしました。今回が最速です。
速報気味。jev 同士に五目並べで対戦させて、速度を実測してみました。
(この記事の AI 成分は 5 割ぐらいです)

共通するのは 機会があること。何かをやった、その報告として記事がある。 「一晩叩いた」「人生で5度目」「速報気味」— 書いている理由が最初の一文に入る。

本記事では A、B、C について解説します 型の議題表は 18 本で 0 件。

1.6 締めは前を向く。「おわり」ではない

旧版は「おわり で足りる」と書いていた。実測すると、最終段落の支配的な型は 次の行動 / 読者への誘い / 未完の予告である。

自分は次に、これを使って GitHub 以外で動く CI 環境を作っています。
手元に Unison MCP をすでに実装してある。もうちょっと練ったら後で紹介したい。
というのを作りたく、じつはちょっとだけ試作したんですが、それは後で書きます。
新しいおもちゃなので、こき使っていきたいですね。
と言うわけで皆さんもMoonbitを書いてください。最高の言語です。
皆さんもブラウザを作りましょう。
そこは使いながら覚えてください。
現状、これをメンテナンスすること自体が、たぶん一番大変です。

記事は完結しない。続いている作業を指して終わる。 総括して閉じるのは AI の形。

1.7 文体純度

18 / 18 が単一文体を 80% 以上の純度で保持。14 本は 100%。混在ゼロ。 敬体 14 本 / 常体 4 本。

• 敬体が既定 (14/18)。読者に向けた通常の記事
• 常体は資料・メモ・マニフェスト寄りのとき (cheatsheet 96%、singularity-point 100%、lsmcp 100%、empirical-prompt-tuning 99%)
• 混在が最大の AI 臭。段落ごとに AI に書き直させると必ずここが割れる

ただし AI サンプルも 100% だった。検出には使えない、書き方の規則である。

2. 内容成分

構造が合っていても中身が無ければ意味がないので、natural-writing-ja の判定軸を通す。

その文が更新するのは「状況」か、「文書」か。

段落の移動の実測 (段落に占める割合): 行為報告 14%、判断 10%、限界開示 6%、定義・説明 31%。 汎用例 (例えば、ある会社では〜) は 18 本で 0 件。数値は全部自分の実測に紐づく。

3. mizchi 度の採点 (構造 6 + 内容 4)

軸	配点	0	1	2
文 / 段落	2	3.0 以上	2.0〜3.0	1.2〜2.0
5 文以上の段落	2	10% 超	3〜10%	3% 以下
見出しの形	2	全部文形	混在	名詞ラベル 50% 以上
冒頭	2	議題表・箇条書き	話題はあるが機会がない	1〜2 文で機会
締め	1	総括して閉じる	—	次の行動・誘い・未完の予告
文体純度	1	混在	80〜95%	95% 以上
主観の明示	1	主体なし	と思います のみ	自分は で判断主体
具体性	1	抽象論のみ	コードのみ	実測値・実コマンド
限界開示	1	言及なし	一般的注意	具体的な失敗・妥協

計 13 点を 10 点に換算。構造 9 点 / 内容 4 点 の配分が意図で、 旧版の 5 軸 (全部マーカー) から重心を移している。

4. マーカーは下限チェックだけ

ここから下は目標値ではない。「ゼロだと冷たい技術文書になる」という下限の確認に使う。 上限に寄せる編集は、§先に結論 の失敗を再生産する。

実測レート (万字あたり):

マーカー	実測	使い方
自分	11.5	判断主体として 1 回は出す。ただし所有格 (自分の記事) で数を稼がない
だろう / はず / かも	6.5	裏を取っていない箇所にだけ
だよね / でしょ / わけだ	5.0	—
なんか / まあ / とりあえず	3.7	副詞側の緩み。文末の逡巡に偏らせない
と思う	3.3	文末の 1.2%。主流ではない
自己責任 / 妥協 / 課題 / 微妙	3.3	限界開示
めっちゃ / かなり / わりと	1.6	—
シュッと / サクッと / ざっくり	0.5	64,340 字で 3 回。入れると即パロディ

文末は敬体が主流 (敬体 64% / 常体 15%)。〜と思う 〜だろう 〜はず の合計は 3.3%。

マーカーを数えるときの注意: AI 臭パターンを論じる記事では、引用が自分の使用として カウントされる。この skill の開発中に 3 回同じ罠にかかった。著者の文か引用かを 必ず分けて数える。

5. AI 臭の典型パターン

パターン	AI 例	直し方	実測
段落が 3 文以上の塊	—	空行で割る	5文以上 0%
見出しが論評	「X が 3 つ壊れていた」	名詞ラベルに	文形 7%
総括して閉じる	「以上、〜を解説しました」	次の行動・未完の予告	0 件
冗長な丁寧表現	〜することができます	〜できる	0.78/万字
空虚な当為	〜することが重要です	誰が何をすべきか	0.00
空虚な強調語	素晴らしい / 画期的 / 多岐にわたる	削除、数値で置換	0.00
無意味な両論併記	〜という意見もあれば	自分の立場を明示	0.00
出典なき一般論	一般的に〜とされています	自分は〜と思っている	0.00
進行実況	前章では X について述べました	削除	0.00
一般論の締め	重要なのはバランスです	自分は経験的に〜	0.00
英語直訳のコロン	設定は以下のとおりです：	設定はこれ。	5.4/万字
対称的な見出し階層	全節が 概要/メリット/まとめ	節長を内容に合わせる	節長 CV 0.57
過剰な箇条書き	主張を全部 bullet	主張は文、列挙だけ bullet	段落比 0.42
汎用例	例えば、ある会社では〜	自分の repo / 実コミット	0.00
文体混在	段落ごとに敬体と常体	どちらかに統一	0 本

実測 0.00 の行は 64,340 字で一度も出なかったパターン。1 件でも出たら疑う。

6. 評価ワークフロー

1. ドラフトを書く。この skill を先に読ませない (過剰適応する)
2. 構造を先に測る: python3 ../ai-index/scripts/slopscore.py --lang ja draft.md。 §1 の 5 項目が全部 ok になるまで、subagent を呼ばない。 段落粒度は機械的に直せるので、人間や LLM の判断を使うのが無駄
3. subagent dispatch: 新規 subagent に §3 の採点と状況/文書テストを依頼
4. 差分適用: 合意できるものを修正 (1 iter で 3〜5 箇所)
5. 再評価: 新規 subagent で
6. 収束: 「構造 5 項目 ok かつ mizchi 度 ≥ 8 が連続 2 iter」または 「指摘が本人しか判断できない好みレベル」で停止

8 / 10 で出すのが正解。 文体は人間の判断を残す領域。

subagent dispatch テンプレ

あなたは mizchi (https://zenn.dev/mizchi) の長年の読者です。
記事ドラフトをレビューしてほしい。

## 対象記事
<パス>

## まず読むもの
- <repo>/mizchi-blog-style/SKILL.md (実測付き文体プロファイル)
- <repo>/natural-writing-ja/SKILL.md (状況/文書の判定軸)

## 前提 (再計測不要)
構造は slopscore で計測済み: <文/段落・一文段落%・5文以上%・見出しラベル%・冒頭文数>

## 見てほしいこと
A. 状況/文書テスト: 各段落の冒頭文と独立した短文について
   「状況を更新しているか、文書を更新しているか」を判定。文書側を行番号+引用で全部。
   短く断定調に整形された文を見落とさないこと。
B. 見出し: 名詞ラベルにできる文形見出しを、行番号 + 改善案で。
C. 締め: 最終段落が「次の行動・読者への誘い・未完の予告」になっているか。
   総括で閉じているなら指摘。
D. mizchi 度: SKILL.md §3 の表で採点 (構造 9 / 内容 4)。
E. 個別指摘 最大 5 件 (行番号 + 引用 + 改善案)。

注意: この記事が AI 臭パターン自体を論じている場合、引用として出てくる語句は
該当として数えないこと。著者自身の文として書かれている場合だけ数える。

修正はせず、判定だけをレポートしてください。

落とし穴

• マーカーレートを目標値として追う: この skill が一度やった失敗。§先に結論 の表がその記録。レートは下限チェックにしか使わない
• 構造を subagent に判定させる: 段落粒度・見出し形・冒頭文数は script が出す。LLM に聞くのは token の無駄で、しかも当たらない
• 引用を自分の使用としてカウントする: 開発中 3 回踏んだ
• subagent に「mizchi っぽく書き直して」と任せる: AI が AI 臭を排除しきれない。判定までで止める
• mizchi 度 10/10 を狙う: シュッと は 64,340 字で 3 回。過剰に入れると即パロディ
• 文体を主題にした記事で mizchi 度を収束判定に使う: 採点表そのものが主題だと構造的に有利になり、満点が出ても意味がない
• 日本語 CV を AI 判定の根拠にする: 人間下限 0.36 対 AI 0.32。差 +0.04
• 体言止め・反問の不在を減点する: 18 本中 3 本はどちらもゼロ
• 同じ subagent を使い回す: 毎回新規 dispatch

関連

• natural-writing-ja — 日本語の自然文の一般規範 (状況/文書の判定軸)
• ai-index — 測定手法・slopscore.py・実測ベースライン
• empirical-prompt-tuning — subagent dispatch + 反復改善のメタ skill