calloc134-style

name	calloc134-style
description	Zenn の Markdown 記事(articles/*.md または books/*/*.md)を、筆者 calloc134 の文体に寄せて書き直すスキル。本論は静かな敬体で短い行を縦に積み、イントロ・アウトロ・余談だけは口語の体温に切り替える「温度差設計」が核。triggers — ユーザが「自分の文体で書き直したい」「calloc134 風に直して」「Zennの記事の言い回しを揃えたい」「この記事の文体を統一したい」「下書きを自分の口調に寄せて」と頼んだとき、または Zenn 記事 (`articles/*.md` / `books/*/*.md`) のリライト・推敲・文体統一を依頼されたとき。Zenn 形式の記事に対する文体調整の依頼であれば、明示的に「calloc134 風」と書かれていなくても積極的に発動してよい。技術書・技術記事の和文リライト作業全般にも使える。

calloc134 文体リライトスキル

このスキルの目的

このスキルは、既存の Zenn Markdown(技術記事・技術書のチャプター)を筆者 calloc134 の文体に寄せて書き直すためのものです。

「書き直す」と言っても、内容(技術的事実・解説の骨子)は変えず、語り口・改行・接続詞・記号・強調・表・比喩の入れ方を筆者の癖に近づける作業です。

スキルを呼び出されたら、まず入力ファイル全体を読み、その上で本ガイドの規則を適用しながら全文を書き直してください。部分的な書き換えではなく、全体のトーンを揃えるのが目的です。

最重要原則 — 「温度差」の設計

筆者の文体の最大の個性は、本論とそれ以外でレジスタ(口調)が切り替わることです。これを取り違えると一気にニセモノになります。

場所	文体	感情記号
本論(各節の解説本体)	整った敬体、断定を一段下げる、感情記号を抑える	基本なし
イントロ(## はじめに ## 概要 # はじめに などの冒頭)	口語混じり、励まし口調、私事 OK	！ ・・・ 〜 OK
アウトロ(## まとめ 末尾、結びの段落)	感謝・続編予告・読者への呼びかけ	！ 〜 OK
余談(## 余談：〇〇 余談ですが、〜)	本論よりやや柔らかいが、本論寄り	抑えめ
自己紹介(冒頭の名乗り)	完全に口語	フル解禁

砕けた表現(！！！ の重ね打ち、・・・ 三点リーダ、〜 波ダッシュ、口語の「わからん」「やったり」など)は、本論には絶対に出さない。 イントロ・アウトロ・自己紹介・モチベ語りに限定します。

本論で ！ を使うと一気にウソっぽくなります。本論の感嘆符は強い違和感だと思ってください。

作業手順

1. 入力 Markdown を最後まで読む。
2. 文書をブロック単位に頭の中で分類する。
   • frontmatter(変更しない、ただし emoji 未設定なら適切なものを提案してよい)
   • イントロ(# はじめに / ## このブックについて / ## 概要 / ## はじめに のいずれか最初の節)
   • 本論(残りの大半)
   • 余談節(## 余談：〜 や本文中の「余談ですが、」)
   • アウトロ(## まとめ 以降、最後の感謝・続編予告まで)
3. ブロックごとにそのレジスタの規則を適用して書き直す。
4. 全体を通して用語表記の統一をかける(後述)。
5. 改行・表・callout・脚注の整形を最後に通す。

書き直したあとは、元の Markdown と置き換えるか、隣に *.calloc.md を作るかを、ユーザの指示がなければ確認してください。デフォルトは「同じファイルを上書き」より「diff を出して見せる」のほうが安全です。

---

本論の文体規則

文の長さ・改行

• 意味の塊ごとにソース上で改行を入れる。1 文を 2〜4 行に折り、Markdownのレンダリングでは結合させる。
• 改行位置の典型:
  • 読点 、 の直後
  • 助詞 は / が / を / で / に / と / から / より の直後
  • 接続詞 しかし つまり また 更に の直後
• 段落内の小休止 = 単純改行 / 段落間 = 1 行空け。
• 箇条書きの 1 項目内でも改行してよい。

例:

入力(1 行で書かれている):

クライアントはリソースオーナーから許可を得て、認可サーバからアクセストークンを取得し、アクセストークンを用いてリソースサーバのリソースにアクセスします。

出力(縦に折る):

クライアントはリソースオーナーから許可を得て、
認可サーバからアクセストークンを取得し、
アクセストークンを用いてリソースサーバのリソースにアクセスします。

文末

本論の文末は柔らかい敬体で統一。

• 断定を一段下げる: 「〜です」「〜となります」「〜と言えます」「〜と考えられます」「〜と思います」
• 読者を巻き込む「ましょう」: 「整理してみましょう」「見ていきましょう」「考えてみましょう」「学んでいきましょう」「理解しておきましょう」
• 節入口の問いかけ: 「では、〇〇はどうなっているのでしょうか？」「ここで、〇〇とはどういうことでしょうか？」 — 疑問形で読者の注意を起こしてから答える
• 柔らかい指示: 「〜してみてください」「〜と良いでしょう」「〜することをおすすめします」

「〜だ」「〜である」の常体は使わない。本論はあくまで敬体。

接続詞・つなぎ語(高頻度語彙)

文頭・段落頭で必ず読点付きで切る形を多用してください。

カテゴリ	語彙
誘導	「では、」「ここで、」「ここでは、」「まず」「まずは」「次に」「最後に」
言い換え	「つまり、」「要するに、」「言い換えると、」「具体的には、」
補足	「なお、」「ちなみに、」「また、」「更に、」
対比	「しかし、」「一方、」「その一方で、」「対して、」
結論導入	「したがって、」「そのため、」「これにより、」
メタ言及	「余談ですが、」「余談として、」「更に余談ですが、」

「では」「つまり」を読点なしで使う形(「ではxxx」「つまりxxx」)は避ける。 必ず「、」で切る。

強調・記号(本論版)

• 太字 **〇〇** を多用する。1 段落に 1〜3 箇所、文ではなく単語・短句を太字で囲う。
  • 例: 「これは セキュリティ向上のために必要なステップ です。」
• 鉤括弧 「〜」 は本論では比喩・新出概念・俗称の引用符として使う。
  • 例: 「鍵」「引換券」「保管庫」「車線(レーン)」
• 感嘆符 ！ は本論では使わない。
• 三点リーダ ・・・ は本論では使わない。
• 波ダッシュ 〜 は本論では使わない(範囲記号としての 〜 は OK、口語の 〜 はダメ)。
• ？ は本論では疑問の ？ に限定。口語の「不明マーク」用途では使わない。
• 括弧の中に英訳・略称・補足を入れる: 認可コード(Authorization Code) クライアント(役割)

比喩・アナロジー

筆者は抽象概念に日常物の比喩を当てる癖が強い。本論にも積極的に挟む。

• 例: 「アクセストークンは、リソースアクセスのための『鍵』です。」
• 例: 「認可コードは、アクセストークンを引き換えるための一時的な『引換券』です。」
• 例: 「alternate は、パラレルワールドの自分と繋がるためのポインタのようなものです。」

導入の型:

• 「〇〇は、〜のための『□□』です。」
• 「〇〇のようなものです。」
• 「〇〇に相当します。」

新出概念の最初の登場時に、鉤括弧で括った日常語の比喩を併記するのが基本パターンです。

用語の表記ルール(全体に通す)

書き終わったあと、または書きながら、以下を機械的に統一してください。

ルール	例
長音記号を落とす	ユーザー → ユーザ / サーバー → サーバ / コンピューター → コンピュータ / メモリー → メモリ
識別子はバッククォート	key / tag / stateNode / redirect_uri
英数字と日本語の間に半角スペース	OAuth 2.0 と OpenID Connect Handle 式トークン React の
カタカナ語の精度を上げる	「認証」と「ID連携」を区別する/「証明書」と「証明トークン」を区別する など、文脈で意味が曖昧になる語は精度の高い方に寄せる

「ユーザー」「サーバー」が混在していたら、長音を落とす側にすべて統一します。

構造の好み

• 対比と分類で進める: 新概念は対の片方として導入する。「OAuth vs OIDC」「Handle式 vs Assertion式」「命令的 vs 宣言的」のような対を活かす。
• 「整理してみましょう」→ 表 のパターン: 文章で説明したあとに、必ず表で再掲する。
• 箇条書きの直後にメタ分類解説: リストの後に「前半 N 個は〇〇、後半 M 個は△△です」のように分類を口頭で添える。
• 箇条書きより 2 列表が好き: プロパティ名 | 説明 のような表を優先する。フラットな bullet を見つけたら、表に昇格できないか検討する。
• mermaid シーケンス図 + ステップ番号付き箇条書きでフローを二重表現する。
• callout :::message / :::message alert で注意喚起・補足を本文から浮かせる。
• 脚注 [^xxx] で仕様書参照(RFC / 仕様 URL)を地の文から切り離す。
• 表が横に長くなったら、セル内に <br> を入れて縦に開く。
• 表の前は必ず「以下のようになります。」「以下の通りです。」「整理してみましょう。」のような橋渡し文を置く。

メタ語り(文書自身への言及)

• 「本書では」「本記事では」「今回は」「今回の解説では」 を節ごとに使う。
• 「以下のように〜」「以下の通りです」「以下のような〜」 で箇条書き・表・図に橋を架ける。
• 「(例: 〇〇)」 で文中例示を挟む。
• 「〇〇していきます」「〇〇していきましょう」 で予告してから本題に入る。
• 節末の「では、次の〇〇に進みましょう」 で章間を接続する。
• 節の入口に**「## 概要」、節の出口に「## まとめ」**を置く構成を好む。

---

イントロ・アウトロの規則(温度を上げる)

本論の規則をいったん緩め、口語の体温を持ち込む場所です。

イントロでやってよいこと

• 名乗り: 「こんにちは！かろっく@calloc134 です。」 — 既存記事でこの名乗りがなければ、ユーザに「入れるか?」を確認する。勝手に挿入はしない。
• 私事・モチベ語り: 「先日、晴れて社会人となりました！」「念願の一人暮らしを始めた」「ロマンがあるからです！！！」のような動機を 1 段落入れる。
• 感嘆符の重ね打ち: ！！！ まで OK。
• 三点リーダ ・・・(中黒3つ): 「わからん・・・」「・・・というのはざっくばらんとしすぎましたが、」 — 一般的な … ではなく ASCII 風の中黒3つ を使う。
• ？ の口語用法: 「触るかもしれない？」「基本的に利用できない？ (不明)」 — 疑問ではなく自信なしのマーク。
• タメ口の混入: 「わからん」「やったり」「モチベが高まり」「テンションがあがりますよね？」
• 読者を巻き込む励まし: 「焦らず、一歩ずつ進んでいきましょう！」「完全に理解した状態へステップアップすることを目指しましょう。」
• 諺・成句: 「千里の道も一歩から。」「餅は餅屋」 — イントロ・アウトロでだけ使う。

イントロの定型構成

多くの記事で次のブロックが順に並んでいます。

1. 名乗り(口語)
2. モチベ語り(口語、！ あり)
3. 「今回は〇〇について書きました」(やや本論寄り)
4. 「このブックで学べること」「対象読者」(箇条書き、敬体)
5. 「今回割愛したもの」(任意、箇条書き)
6. 「参考にする仕様」「参考文献」(リンク列挙)

リライト時、既存のイントロがこの構成から大きく外れていたら、順序を整える提案をユーザに出してよいです。

アウトロでやってよいこと

• 感謝表明: 「ここまで読んでいただきありがとうございました！」
• 続編予告: 「次回の記事もお楽しみに〜」「・・・と思ったのですが、〇〇の話も長くなりそうです・・・」
• 執筆参考への感謝: 「素晴らしい書籍を執筆してくださった〇〇さんに、心より感謝申し上げます。」
• 波ダッシュ 〜 の口語使用 OK: 「お楽しみに〜」

余談節の扱い

• 見出しは ## 余談：〇〇 か、本文中の 「余談ですが、」「余談として、」「更に余談ですが、」 のいずれか。
• 内容は本論より軽くてよいが、感情記号 ！！！ などは入れない。あくまで「本論を一段ゆるめた敬体」止まり。
• 余談を独立節として明示することで、本筋の流れを汚さないのが筆者の好み。

---

やってはいけないこと(アンチパターン)

リライト時に絶対に避けるべきこと:

1. 本論に ！ や ・・・ や 〜 を持ち込む

   • ❌「アクセストークンは『鍵』です！」
   • ❌「・・・このとき、認可コードが発行されます。」
   • ✅「アクセストークンは、リソースアクセスのための『鍵』です。」

2. 本論で常体(だ・である調)を混ぜる

   • ❌「アクセストークンはリソースアクセスのための鍵だ。」
   • ✅「アクセストークンは、リソースアクセスのための『鍵』です。」

3. 接続詞を読点なしで使う

   • ❌「ではアクセストークンの検証手順を見ていきます。」
   • ✅「では、アクセストークンの検証手順を見ていきます。」

4. 太字を「文全体」にかける

   • ❌「アクセストークンは認可サーバが発行するクレデンシャルであり、リソースサーバへのアクセスに利用されます。」
   • ✅「アクセストークンは認可サーバが発行する クレデンシャル であり、リソースサーバへのアクセスに利用されます。」
   • 太字は単語・短句単位で散らすのが筆者の癖。

5. 長音記号を残す

   • ❌「ユーザーがサーバーにアクセスする」
   • ✅「ユーザがサーバにアクセスする」

6. イントロを冷たい説明文だけにする

   • ❌「本記事では PostgreSQL の MVCC について解説する。」
   • ✅「こんにちは！かろっく@calloc134 です。」+ モチベ語り + 「本記事では〜」 のような複数段構成。
   • もちろん、既に書かれているイントロが冷たい場合に勝手に名乗りを足してはいけない。ユーザに確認する。

7. 比喩を削る

   • 既存原稿に「鍵」「保管庫」のような比喩があったら、絶対に削らない。
   • 逆に新規に比喩を足すのは積極的に推奨。

8. 挿絵プレースホルダ ![](/images/...) を削る

   • 画像参照は筆者の文書に必須要素。位置の入れ替えは OK だが、削除はしない。

9. シーケンス図(mermaid)を散文に変換する

   • 図はそのまま残す。図のあとに「ステップ番号付き箇条書きで言い換える」二重表現が好まれる。

10. コミットメッセージ風の語彙(「ブラッシュアップ」「とりあえず」)を本文に持ち込む

    • これは編集メモの語彙であって、本文の語彙ではない。

---

サンプル変換(Before / After)

サンプル 1: 本論の 1 段落

Before (機械的・冷たい):

JWTは3つのパートから構成されている。ヘッダ、ペイロード、署名である。それぞれBase64URLエンコードされてドットで連結される。

After (筆者文体):

JWT は **3 つのパート** から構成されています。
**ヘッダ**、**ペイロード**、**署名** の 3 つです。

それぞれが Base64URL エンコードされ、
ドット `.` で連結されることで JWT の文字列が出来上がります。

つまり、JWT はあくまで「**3 つの情報を連結した文字列**」であると言えます。

何をしたか:

• 常体 → 敬体
• 行を縦に折る
• 単語単位の太字
• 「つまり、」で言い換え
• 「〇〇であると言えます」で柔らかく結ぶ
• 鉤括弧で要点を再強調

サンプル 2: 箇条書き → 表 + メタ分類

Before:

JWTのメリットは以下の通りです。

- ステートレス
- 検証が高速
- 標準化されている
- 言語サポートが豊富

After:

JWT のメリットを整理してみましょう。

| 観点         | 内容                       |
| ------------ | -------------------------- |
| **特性**     | ステートレス               |
| **性能**     | 検証が高速                 |
| **互換性**   | 標準化されている           |
| **エコシステム** | 言語サポートが豊富       |

ここで、前半 2 つは **JWT 自体の特性** に関するメリット、
後半 2 つは **JWT を取り巻くエコシステム** に関するメリットであると言えます。

何をしたか:

• 箇条書きを 2 列表に昇格
• 太字でラベルを散らす
• 「整理してみましょう」で表へ橋渡し
• 表の後にメタ分類解説を口頭で添える

サンプル 3: イントロの温度上げ

Before (素っ気ない):

# はじめに

本記事では、Reactの内部実装について解説する。

After (筆者文体):

# はじめに

こんにちは！かろっく@calloc134 です。

最近、React のレンダリング処理について調べる機会があったのですが、
内部実装まで踏み込んだ解説がまとまっている記事は意外と少ない・・・
と感じました。

そこで今回は、React の内部実装について
**できるだけ図と例を使いながら** 解説していきたいと思います。

この記事を通して、
React の内部構造に対する解像度を上げましょう！

何をしたか:

• 名乗りを追加(※既存原稿に名乗りがなく、かつユーザが OK と言っている場合のみ)
• モチベ語りを 1 段落
• ・・・ を口ごもりマークとして使用
• 「解像度を上げましょう！」の励まし口調(これは筆者の口癖)
• 締めに ！ を解禁

---

出力フォーマットの指針

リライト結果をユーザに見せる際は、次のいずれかをユーザの希望に従って選ぶ:

1. diff 形式: 既存ファイルとの差分を git diff 風に提示。差分が大きい場合に向く。
2. ファイル上書き: 既存の articles/xxx.md をそのまま書き換える。ユーザが「上書きしていい」と明示したときのみ。
3. 隣に新ファイル: articles/xxx.calloc.md のように .calloc.md サフィックスで隣に作成。最初のレビューに最も向く。

デフォルトは 3 → ユーザの確認 → 1 か 2 で最終化 の流れを推奨します。

チェックリスト(リライト後に自分で見直す)

リライトが終わったら、以下を頭の中で(または diff を眺めながら)チェックしてください。

本論

• 本論に ！ ・・・ 〜 が紛れていないか
• 常体(だ・である)が混じっていないか
• 「では」「つまり」「ここで」が読点付きで書かれているか
• 1 文が長すぎないか — 縦に折れる場所はないか
• 太字が「文単位」になっていないか — 単語・短句単位に直す
• 「ユーザー」「サーバー」が残っていないか
• 識別子がバッククォートで囲まれているか
• 英数字と日本語の間にスペースが入っているか
• 新出概念に比喩か 「〜」 が添えられているか
• 箇条書きで表に昇格できそうなものはないか

イントロ

• 名乗りが必要か(既存になければユーザに確認)
• モチベ語りや動機を 1 段落入れたか
• 「対象読者」「このブックで学べること」「今回割愛したもの」のテンプレ節を必要に応じて整えたか
• 励まし口調で締めているか

アウトロ

• 「まとめ」節があるか
• 感謝表明か続編予告があるか
• 参考文献節があるか

全体

• 挿絵プレースホルダ(![](...))が消えていないか
• mermaid 図が消えていないか
• frontmatter(title / emoji / topics / published)が壊れていないか
• 余談節が独立して切り出されているか

---

詳細リファレンス

更に詳細な観察データが必要な場合は、以下を参照してください。

• references/observations.md — 既存記事 (sikkari-oauth-oidc, postgres-internal-mvcc-index, how-react-works-guide, newlife-openwrt-riron, 4a8c1af0eb5aae) から抽出した実例集。本論・イントロ・アウトロそれぞれの実サンプルが章ごとに並んでいる。判断に迷ったらここを見て近い例を探す。
• references/vocabulary.md — 接続詞・文末表現・比喩・専門用語表記の語彙リスト。grep 的に置換候補を探したいときに使う。