abekoh-writing

abekohの公開記事7本(Zenn技術記事・個人ブログ・会社ブログ)から抽出した文体の癖をまとめたスキル。 新規執筆でも既存文章の書き直しでも、このスキルのルールに従って「abekohらしい」文章を出力する。

このスキルの数値(段落の文数、頻度など)は実記事の集計に基づく。「それっぽく」ではなく、実測された癖の再現を目指すこと。

まず語尾モードを選ぶ

abekohの記事には語尾の異なる2つのモードがある。

• 丁寧モード(です・ます): 技術解説記事向け。Zenn・会社ブログなど、読者に何かを紹介・解説する記事
• カジュアルモード(常体+体言止め): 参加記・振り返り・日記など、個人ブログの記録系の文章

依頼内容や文脈からどちらか明らかでなければ、AskUserQuestionで必ずユーザーに選ばせること。勝手に決めない。 「技術解説だから丁寧だろう」と推測できる場合でも、迷いが少しでもあれば確認するほうが安全。

モードが決まったら、書き始める前に対応するリファレンスを読む:

• 丁寧モード → references/mode-polite.md
• カジュアルモード → references/mode-casual.md

各リファレンスには語尾ルールの詳細と、実記事からの「お手本」抜粋が入っている。抜粋の声色を掴んでから書くこと。

記事の構成

セクションの枠組み

• 本文はh2始まり。h1は使わない(タイトルはfrontmatterや別枠)。h4はほぼ使わない
• 冒頭は「## はじめに」。本題前に「## 前提」(対象範囲・免責を箇条書きで)を置くことがある
• 締めは「## まとめ」と「## おわりに」を使い分ける:
  • 「## まとめ」= 内容の要約。箇条書き中心。まとめだけで記事の結論がわかるように
  • 「## おわりに」= 所感・反省・今後の展望。感情を率直に書く
  • 両方置く場合は まとめ→おわりに の順
• 末尾に「## 参考」(リンクの箇条書き)を置くことがある。参加記なら「## 謝辞」も

「はじめに」の書き方

個人的な文脈・モチベーションから入る。一般論から始めない。

ここ1年くらいRDBに向き合う機会が多く、その内部実装を手を動かしながら身を持って理解してみたいというモチベーションから始めてみました。

我が家には数年前に組んだ「GeForce RTX 3080搭載のゲーミングPC」があるわけですが、最近はPCゲームをそこまでやらず、それなりのGPUあるのにもったいないなという状態です。

その後「本記事では〜を紹介します」「そのログです」と記事の範囲を一言で示す。

見出しの命名

• h2は短い名詞・名詞句: 「成果物」「進め方」「実験方法」「実装例」「他の選択肢との比較」。英語もたまに(「Overview」「Tips」)
• 「## Tips」「## プラクティス集」「## 実験」のような列挙親セクションを作り、h3で個々の項目に割るパターンが頻出
• h3の命名は3パターン:
  • コンポーネント名・技術名そのまま: 「Listener」「PostgreSQL プロトコル」
  • 動作を表す文(体言止め・終止形): 「レイヤーキャッシュを導入」「CQRSを採用する」
  • 疑問形で問いを立てて話を進める: 「マルチステージビルドは不要?」「Dockerfileも不要?」
• 見出しにです・ます調は使わない

段落は短く(最重要の癖のひとつ)

実測で、地の文の84%が1〜2文の段落(1文41%、2文43%)。中央値は約80字/段落。

• 1段落は1〜2文が基本、3文が上限
• 4文以上になりそうなら、段落を割るか箇条書きに落とす
• 長い理屈も短い段落を重ねてテンポよく進める。「問いかけの段落」→「答えの段落」と割るのも常套手段:

外部パッケージ変更のシナリオは(中略)頷けますが、それ以外のシナリオはなぜ遅くなったのでしょう？

答えは、キャッシュの保存・準備に時間を要してしまったためです。

箇条書きの多用

長い地の文で説明せず、列挙できるものはすぐ箇条書きに落とす。使いどころ:

• 機能一覧・仕様・前提条件(「## 前提」はほぼ必ず箇条書き)
• 参考リンク集(リンクを2件以上並べるときは箇条書き)
• 選択肢・比較の列挙(メリット・注意点の対比)
• 設定・作業のまとめ(「やったことまとめるとざっくり↓」→箇条書き)
• 「## まとめ」セクション自体を箇条書きだけで構成することもある

書き方のルール:

• ネストを活用し、項目の下に一段下げて補足・注釈をぶら下げる
• 手順・フローは番号付きリスト(ネストあり)
• 箇条書き内は常体・体言止めで簡潔に(です・ます調の記事でも箇条書き内は常体)

カギカッコ「」の使い方(abekohらしさの核)

「」を多用する(多い記事では26回/300行)。3つの用法がある。

1. 概念・用語のマーキング: キーワードの初出や強調。「テスト・ダブル」「古典学派」「ステートレスな関数」
2. 心の声・脳内セリフの直接引用(最も特徴的): 開発者の内心や想定される発話をセリフとして地の文に埋め込む。しばしば「…」「!」入り
   • 「どこに処理内容置いていたっけ…」と迷います。
   • 「読み取り処理がなんだか冗長になるな…」という感覚がある場合は
   • 「とにかくモデルに振る舞わせよう！」と頑張るのではなく
3. 方針・スタンスのセリフ化: 主張を話し言葉にして括る
   • 「基本操作はステートレスに、ただモデルの状態くらいはモデルに教えてほしいな」というスタンスでいければよい

説明が固くなってきたら、読者や自分の心の声を「」で挟むのがabekoh流。

インラインコード``の使い分け

``で囲むもの:

• コマンド・SQL文: psql, go get, terraform apply, LISTEN, EXPLAIN
• 識別子・型・変数・引数名: User, roomClientMap, id
• 関数・メソッドは () 付き: Service.UpdateUserName()
• 設定キー・オプション・値: cache-from, mode=max, --bare, linux/amd64
• リポジトリパス形式のアクション名: actions/cache, docker/build-push-action
• テーブル名・カラム名・DB型: table_catalog, jsonb

``で囲まないもの:

• ツール名・製品名は地の文では裸かリンク: Docker, GitHub Actions, PostgreSQL, moq, Terraform
• ライブラリの初出は [jackc/pgx](URL) 形式のリンクにすることが多い

表現の癖

• 「〜してみる」「〜してみました」のtry表現を多用。タイトルにも使う(「繋いでみる」「考える」「試してみます」)。実験・挑戦の記録という姿勢が文体の芯
• 断定を避ける緩和表現: 「〜と思います」「〜かもしれません」「〜な気がします」「〜な印象でした」
• 主観を明示するときは「〜と筆者は考えます」(丁寧モードの解説記事)
• 謙遜・自己ツッコミを入れる: 「自作、といっても大部分は移植です」「ほぼ写経になりました」「力業で対応しています」
• カジュアルな挿入で人間味を出す: 「ラッキーでした」「捗りました」「壮観です」、成功報告に「🎉」、三点リーダ「…」、波ダッシュ「いいな〜と思い」
• くだけた副詞: 「ざっくり」「もろもろ」「とりあえず」「いい感じに」
• 一人称: 丁寧モードの解説記事では「筆者」、個人ブログでは省略か「自分」

引用・参照のスタイル

• 書籍からの引用は > ブロック+出典明記: 『書名』p.XX 章タイトル
• 参考リンクは本文に自然に差し込む: 「こちらの記事もご参照ください」「先人のログを参考にさせていただきました」「詳細は〜でキャッチアップ」
• 主張には根拠を添える: 実測値の表、実際のコマンド出力、書籍の引用。実測・実例ドリブンが基本姿勢
• 比較は表にする。要点は太字で強調

書き直し(リライト)の場合

既存の文章をabekoh風に書き直すときの手順:

1. モードを決める(上記の通り、不明ならユーザーに確認)
2. 元の文章の情報・主張はすべて保持する。勝手に内容を足したり削ったりしない
3. 構成をabekoh流に組み替える: 「はじめに」で個人的文脈→本文→「まとめ/おわりに」
4. 長い段落を1〜2文に割る。列挙的な説明は箇条書きへ
5. 語尾をモードに合わせ、try表現・緩和表現・「」の心の声を織り込む
6. 元の文章に個人的な文脈(なぜやったか、どう感じたか)が欠けている場合は、ユーザーに軽く確認するか、TODOコメントとして残す。捏造しない

やってはいけないこと

• AIっぽい網羅的・教科書的な説明(「〜には以下の3つのメリットがあります。第一に…」)
• 4文以上のもったりした段落
• 過度に丁寧なビジネス文書調(「〜でございます」「〜いたしますと幸いです」)
• 感情ゼロの無機質な報告。abekohの記事は失敗・驚き・喜びが必ずどこかに入る
• 絵文字の乱用。「🎉」は成功報告の決め所に1〜2回まで