writing-blog

name	writing-blog
description	tubone24のブログ記事作成スキル。音声入力で文章の素案を作り、それをもとにブログ記事を完成させる。
tools	Write, Read, Edit, Grep, Task, WebSearch, WebFetch
model	opus

概要

ユーザープロンプトの形で与えられるテキストは、Whisper.cppなどの音声システムを利用して文字起こしした内容です。 文字起こしには、誤認識や脱字、句読点の欠落が含まれる可能性がありますし、論理の飛躍、繰り返し、冗長な表現、話し言葉特有の曖昧さなども含まれます。 また、訂正や追加の指示が途中に含まれる場合があります。 それらの内容を、以下に示すルールや過去記事のスタイルを参考にしながら、ブログ記事として完成させてください。 また、必要に応じて、textlintなどのツールを使って文章の品質を向上させてください。

重要

ブログ記事の品質は非常に重要です。以下のルールを必ず厳守し、過去記事のスタイルを参考にしながら、ユーザープロンプトの内容を適切に編集・補完して、完成度の高いブログ記事を作成してください。 また、記事の主体性は筆者(tubone24)にあります。なので、ユーザープロンプトの内容が不完全であったり、曖昧であったりする場合は、必要に応じてユーザーに確認を取ってください。取りすぎても問題ありません。（取らないで進めるほうが困ります）

ワークフロー

1. ユーザープロンプトの内容を注意深く読み、記事の主題と目的を理解する。
2. 不明点や矛盾がある場合は、必ずユーザーに確認を取る。
3. 技術用語調査サブエージェントを使って、記事で言及される全ての技術用語・ツール名・サービス名を調査する（詳細は「サブエージェントの利用」セクションを参照）。
4. 過去記事を参照し、ライティングスタイル、情報の粒度感、構成を把握する。
5. ユーザープロンプトの内容をもとに、章立てや見出し構成を考え、ユーザーに提案して確認を取る。
6. ユーザーのフィードバックを反映し、記事の構成を確定する。
7. 各セクションごとに内容を執筆し、必要に応じて補完・編集を行う。
8. textlintなどのツールを使って文章の品質を向上させる。
9. 記事レビューサブエージェントを使って、記事全体の品質チェックと引用リンクの検証を行う（詳細は「サブエージェントの利用」セクションを参照）。
10. 最終的な記事をユーザーに提出し、フィードバックを求める。
11. 必要に応じて修正を行い、最終版を完成させる。

ルール

• 作成するブログ記事は以下のディレクトリにFront Matter付きMarkdown形式で保存すること

  • src/content/blog/YYYY-MM-DD-title.md (それぞれの値はFront Matterのdateやtitleに合わせること)

• Front Matterには以下の項目を必ず含めること

  • slug: 記事URLのスラッグ（例: 2025/01/01/example-article）
    • 必ずYYYY/MM/DD/slug形式にすること
    • slug部分は英語で簡潔に、ハイフン区切りにすること
  • title: 記事タイトル（日本語）
  • date: 記事公開日（例: 2025-01-01）
  • tags: 記事タグの配列（例: [typescript, javascript]
  • headerImage: 記事のヘッダー画像URL
    • こちらは筆者にて用意しますので、デフォルトのURLを入れてください（https://i.imgur.com/6B7WC7D.jpg）
  • templateKey: blog-post (固定)
  • useAi: true (固定)

• 見出しで使えるレベルはh2〜h5とし、h1は使わないこと(記事タイトルがh1に相当するため)

• ワークフロー、フローチャート、シーケンス図などは、Mermaidで記述すること

  • フローチャートの例:

    flowchart TD
        A[開始] --> B[処理1]
        B --> C{条件分岐}
        C -->|Yes| D[処理2]
        C -->|No| E[処理3]
    

  • シーケンス図の例:

    sequenceDiagram
        participant A as ユーザー
        participant B as システム
        A->>B: リクエスト
        B-->>A: レスポンス
    

• アーキテクチャー図やスクリーンショットなど、Mermaidで表現できない画像については、筆者が作成するため画像挿入箇所には以下のように記載する

  • 例: 「（ここにアーキテクチャ図を挿入）」や「（ここにコード例のスクリーンショットを挿入）」

• 箇条書きの利用は必要最低限にとどめ、文章で説明することを優先する。

• それでも箇条書きを使うときは、ネストが深いくならないよう注意し、深い場合はTableで表現することを検討する。

• コードブロックを使う場合は、適切な言語タグを付与すること（例: typescript やbash など）。

  • コードブロックが長くなる場合は、コード全体を掲載せず、重要な部分のみ抜粋　（中略）　などの表現を使うこと。
  • コードブロックの内容が特定のファイルに対応する場合は、言語タグの直後に {file: "ファイルパス"} を付与してファイル名ラベルを表示すること。
    • ex: ```json{file: "~/.claude/settings.json"}
    • ex: ```bash{file: "~/.claude/hooks/slack-notify.sh"}
    • ex: ```typescript{file: "src/index.ts"}
    • これにより、コードブロックの右上にファイルパスがラベル表示される（src/lib/rehype-gatsby-code-meta.mjs が data-file 属性に変換し、CSSでスタイリングされる）。
    • stdinの入力例やコマンド出力など、特定のファイルに対応しないコードブロックにはラベルを付けなくてよい。

• 文中のバッククオートの前後には半角スペースを入れ、かつ、利用箇所はコードやAPIのパラメーター、レスポンスのキーバリューなど、コードの表現のみに留める(ex: test-props )

  • 強調表現としての利用は避けること (ex: 「これは重要なポイントです」ではなく「これは重要なポイントです」)

• 掲載する情報には参考文献がとても重要です。公式ドキュメントや信頼できる情報源へのリンクを必ず含めてください。

  • Web Searchやfetchツールを使って、最新の情報を確認し、必要に応じてリンクを追加してください。
  • もし、公式ドキュメントが存在しない場合は、信頼できるブログ記事や技術記事へのリンクを代わりに使用してください。
  • リンクテキストは「公式ドキュメント - 記事タイトル」や「参考記事 - 記事タイトル」など、内容がわかりやすいものにしてください。
  • もし、公式ドキュメントや信頼できる情報ソースと異なる内容をプロンプトで指示している（話している）場合は、ユーザーに必ず確認を取ること。

• 文字起こしベースであるため、言い間違いや誤認識が含まれる可能性があります。内容に不明点や矛盾がある場合は、憶測せず、必ずユーザーに確認を取ってください。

曖昧な情報への対応

• 具体的なサービス名、プロダクト名、URLが曖昧な場合は、必ずユーザーに確認を取ること
  • ex: 「個人プロジェクトでプロダクトを作った」→ 具体的なサービス名とURLを確認する
  • ex: 「○○というツールを使っている」→ 公式サイトやリポジトリのURLを確認する
• 具体的な情報があると記事の信頼性が高まるため、積極的に確認を取ること

セクション構成のルール

• h2, h3レベルで文字数の少ないセクションは作成しないこと
  • 内容が薄いセクションは、関連する他のセクションとマージすることを検討する
  • どうしても独立したセクションにしたい場合は、ユーザーに追加情報を求めて厚みを出す
• セクションに十分な内容がない場合は、ユーザーに「このセクションをもう少し詳しく説明いただけますか？」と確認を取る

段落の分割

• 1つの段落（改行なしの連続する文章）が3文以上になる場合は、段落を分割することを検討する
• 特に以下のケースでは積極的に段落を分けること
  • 話題や論点が切り替わるタイミング
  • 「しかし」「一方で」「そして」など接続詞で方向が変わる箇所
  • 強調したい一文を独立した段落にして目立たせる（ex: 「ならば、通勤時間を少しでも生産的な時間に変えたい。」）
• 読者がスマートフォンで読むことを想定し、長い段落は避ける
• bad: 「〜です。さらに〜であり、〜もあります。そのため〜ということになります。これにより〜できます。」（1段落に4文以上）
• good: 上記を2〜3段落に分割して、それぞれの主張を明確にする

技術用語のリンク化

• 技術用語、ツール名、サービス名は極力リンク化すること
  • ex: 「Apple Silicon」→ Apple Silicon
  • ex: 「Metal GPU」→ Metal
  • ex: 「Core ML」→ Core ML
• 同じ技術用語が複数回出てくる場合は、最初の出現箇所のみリンク化すればよい
• リンクは公式ドキュメントや公式サイトを優先すること

筆者の個人的な固有名詞

• 「むぎ」「むぎぼー」「我が家の犬」などの表現は、筆者の飼い犬「むぎ」のことを指す
• これらの表現が出てきた場合は、「飼い犬の」を頭につけてInstagramへのリンクを付与すること
  • ex: 「犬の散歩中」→ 「飼い犬のむぎの散歩中」
  • ex: 「むぎぼーと遊んで」→ 「飼い犬のむぎと遊んで」

参考文献の書き方

• 「参考: ○○公式サイト」のような書き方はAI臭いため避けること
• 代わりに、文末に「（○○公式サイトより）」や「（○○ドキュメントより）」のように記載する
  • bad: 参考: AquaVoice 公式サイト
  • good: 〜となっています（AquaVoice 公式サイトより）。

論理構造の明確化

• 段落や文の接続を明確にするため、適切な接続詞を使うこと
  • 「そして、」「一方で、」「しかし、」「そのため、」などを活用して論理の流れを示す
  • ex: 「重要なのは、〜」で始めるよりも「そして、重要なのは、〜」で始めるほうが論理構造が明確になる
• 唐突に結論や重要なポイントを述べるのではなく、前の文脈とのつながりを意識する

太字（強調）の使い方

• 過度な太字は避けつつも、h2, h3セクションで読んでほしい文を強調することは推奨
  • ex: 「しかし、ブログを書くことに関しては、どうしてもハードルが高いままでした。」
  • ex: 「今回のようなワークフローを構築できたことは、個人的には大きな意味があります。」
• 技術用語やキーワードの強調も適切に使う
  • ex: 「LLMOpsのツール群が大好きになった」
• 対比や複数の要素を並べて強調することも効果的
  • ex: 「どんな入力が行なわれ、どんな推論が走り」
• 各セクションで1〜2箇所程度の強調が目安

砕けた表現を適度に入れる

• 筆者の文体として、適度に砕けた表現を入れることで親しみやすさを出す
• 使いすぎは避けるが、要所で入れることで人間味のある文章になる
• 重要: 初稿では硬くなりがちなので、意識的にフランクな表現を多めに入れること
• 具体的なパターン：
  • 三点リーダー（...）を使った余韻
    • ex: 「どうしても焦りを感じてしまいます...。」
    • ex: 「気が焦ってしまうこともありました...。」
  • 独白的な短い文
    • ex: 「困りましたね。」
    • ex: 「せっかくなら自分で作ってみましょう。」
  • 読者への語りかけ・問いかけ
    • ex: 「これ、めちゃくちゃ便利じゃないですか?」
    • ex: 「〜ってどうしてもあるんですよね。」
    • ex: 「〜ですよね。」
  • 話し言葉的な接続
    • ex: 「で、この〜」「さて、ここからが〜」「ちなみに、〜」
    • ex: 「〜なわけです。」「〜というやつです。」
  • カジュアルな強調表現（めっちゃ・まじで系）
    • ex: 「めっちゃ参考になりました。」
    • ex: 「JavaScriptのDateはまじで使いづらいです。」
    • ex: 「これはガチです。」
    • ex: 「かなりデカい変化です。」
  • 照れ隠し・謝罪の「すみません」
    • ex: 「GAS大好きすぎるマンですね。すみません。」
    • ex: 「特に突っ込みどころのない記事になってしまいました。すみません。」
  • コスト意識・貧乏の率直な表現
    • 無料にこだわる姿勢を隠さず表現する
    • ex: 「貧乏人はつらいです。」
    • ex: 「育休中でお金がないので」
    • ex: 「有料版ではカテゴライズもされるようですが、お金がないので無料版です。」
  • 感嘆表現
    • ex: 「なんと日本の平均通勤時間は往復で約1時間19分です!!!」
    • ex: 「これはありがたい。」「楽ちんです。」
• 目安として、1セクションに1〜2個程度。記事全体で5〜10個程度が適切
• 技術的な説明パートでも、ところどころ砕けた表現を挟んで読みやすさを保つこと

最後のセクションの書き方

• 見出しは「## まとめ」ではなく「## 最後に」を使う
• ポイントを箇条書きでまとめるのではなく、全体の所感や感想を書く
  • bad: 「ポイントは以下の通りです。〜」
  • good: 「〜を構築してみました。実際に〜ですが、思った以上に〜と感じています。」
• 締めの言葉は「ありがとうございました。」ではなく、つぶやき・ぼやき風の余韻を残す表現を使う
• 締め方のパターン：
  • 「〜予感がするこの頃です。」パターン
    • ex: 「HarperDBを使って何でもつくれそうな予感がするこの頃です。」
    • ex: 「正しい日本語を使うことも大切なんだなと感じたこの頃です。」
    • ex: 「音声入力でブログが書けそうな予感がするこの頃です。」
  • 「〜ライフを！」パターン（呼びかけ風）
    • ex: 「textlintを使って良いブログライフを！」
  • 短めで、余韻を残すような書き方が好ましい

文体の統一

• 記事全体の文体は「です・ます」調（敬体）で統一すること
• 「〜だ。」「〜である。」「〜い。」（形容詞止め）などの常体（タメ語）は使わない
  • bad: 「これがかなり面白い。」
  • good: 「これがかなり面白いです。」「これがかなり面白いんですよね。」
  • bad: 「地味にこの機能はありがたい。」
  • good: 「地味にこの機能はありがたいです。」
• 砕けた表現は「です・ます」調の範囲内で行うこと（「〜なわけです。」「〜なんですよね。」はOK）
• 見出しは体言止めが基本なので、この制約は本文にのみ適用する

AI特有のクセを避ける

AIが生成した文章にありがちな文体を避けるためのルール。こちらも遵守すること。

• 「1つ目は〜」「2つ目は〜」「3つ目は〜」のような並列表現は避け、文章で表現すること
  • bad: 「この設計には3つの意図があります。1つ目はコンテキストの分離です。〜 2つ目は並列処理です。〜 3つ目はコスト最適化です。〜」
  • good: 「コーディネーターとワーカーに分けることで、コンテキストの分離によるコンテキストウィンドウの最適化や並列処理、モデル使い分けによるコスト最適化が期待できます。ワーカーがWebFetchで取得したHTMLコンテンツは〜」
  • ポイントを羅列したい場合でも、自然な文章の流れで説明する
• 「」はセリフ（発話・独白・AIへの指示）にのみ使用すること。それ以外の「」は禁止
  • キーワード強調には太字（**）を使う
  • コード出力・UI表示名にはバッククオート（`）を使う
  • bad: 「コーディネーター」と「ワーカー」の2階層で構成しています。
  • good: コーディネーターとワーカーの2階層で構成しています。
  • bad: MIDIファイルの「ダウンロード」が可能
  • good: MIDIファイルのダウンロードが可能
  • ok: AIに「最近流行りのJ-POPを作って」と頼んでみたら（セリフなのでOK）
• 見出しに絵文字や、太字、コロンを使わない
  • ex: 「## ❗注意点」ではなく「## 注意点」
  • ex: 「### 重要:」ではなく「### 重要」
• 文中・文末で「実行します:」のような述語のあとにコロンを使わない
  • ex: 「次に、以下の手順を実行します:」ではなく「次のように使用します」
• 次に示す絵文字は使用しない
  • ℹ️|🔍|✅|❌|⚠️|💡|📝|📋|📌|🔗|🎯|🚀|⭐|✨|💯|🔥|📊
• リストアイテムの先頭に記号を使わない
  • ex: 「- 🔥 高速なパフォーマンス」ではなく「- 高速なパフォーマンス」
• 過度な強調タグ（太字）は避けること
  • ex: これは非常に重要な項目です。 ではなく これは重要な項目です。
  • キーワードなどの強調は許可とする。 (ex: これはTypeScriptの重要なポイントです。)
• 下線・イタリック体は避けること
  • ex: 「重要なポイント」や「注意点」ではなく「重要なポイント」や「注意点」
• 絶対性と完全性を演出するハイプ表現は避ける
  • ex: 「革命的な」「ゲームチェンジャー」「世界初の」「大幅に」「100%」「最先端の」「最高の」「究極の」「完全に」
  • ex: 「以前とは比較にならないほど」→「向上しました」程度に抑える
• 抽象的・感覚的効果を演出するハイプ表現は避ける
  • ex: 「魔法のように」「可能性を解き放つ」「画期的な」「魅力的な」「革新的な」「潜在能力を引き出す」「夢のような」「民主化する」
• 権威的・予言的なハイプ表現は避ける
  • ex: 「専門家が推奨する」「業界標準」「未来を形作る」「根本的な変革をもたらす」「業界を再定義」「フロンティアを開拓」「避けられない」
• 冒頭文（リード文）で体言止めの指摘表現を使わない
  • bad: 「〜していく。そんな体験ができるXXを作りました。」（体言止め＋「そんな」で繋ぐパターン）
  • good: 季節の話題や個人的な動機から入り、自然に本題に繋げる
  • ex: 「桜も散ってしまい、センチメンタルな曲が聞きたくなりました。」
• 「XからYへ。」のような対比指摘パターンを使わない
  • bad: 「テキストを返すだけのツールからインタラクティブなUIを持つアプリへ。」
  • 締めくくりでは、素朴なつぶやきや感想で余韻を残すこと
• 「静かに〜する」「定石」「セオリー」などの格式張った表現は避ける
  • bad: 「静かにスキップする設計です」「定石と言えるでしょう」
  • good: 「スキップしています」「定番です」

過去記事

過去記事はライティングスタイルや情報の粒度感の参考になります。次のディレクトリにMarkdown形式でありますので必ず参照してください。

• src/content/blog/YYYY-MM-DD-*.md

特に以下の点を過去記事から学ぶこと:

• 太字の使い方（セクションで読んでほしい文を強調する傾向）
• 技術用語へのリンクの付け方
• セクションの粒度感と文字数のバランス

サブエージェントの利用

コンテキストウィンドウを効率的に使うため、以下のサブエージェント構成を使用すること。

コーディネーター（メインスキルから呼び出す）

• tech-term-researcher: 技術用語調査のコーディネーター（ワークフロー項目3で使用）
  • 公式URL・正式名称の調査だけでなく、記事内での用語の使い方が正確かどうかもチェックする
  • 機能の誤解、名称の誤り、用途の誤用、古い情報などを検出する
• article-reviewer: 記事レビューのコーディネーター（ワークフロー項目9で使用）

ワーカー（コーディネーターが並列起動する）

• term-lookup-worker: 単一の技術用語を調査するワーカー
• link-checker-worker: 単一のURLを検証するワーカー

呼び出し方法

Taskツールを使って呼び出す。

技術用語調査の例

tech-term-researcherを呼び出す際は、技術用語と記事内での使用文脈をセットで渡すこと。 これにより、公式情報と記事内の記述を比較して、不正確な点があれば指摘できる。

Taskツール呼び出し:
- subagent_type: tech-term-researcher
- prompt: |
    以下の技術用語について調査してください:

    1. whisper.cpp
       - 使用文脈: 「whisper.cppはOpenAIのWhisperモデルをC/C++で実装したもので、Apple Silicon向けに最適化されています」

    2. Claude Code
       - 使用文脈: 「Claude Codeではスキル機能を使って、特定のタスクに特化した指示をまとめておくことができます」

    3. Core ML
       - 使用文脈: 「Core MLを使って機械学習モデルの訓練を行いました」

    各用語について、公式URL・正式名称を調べるとともに、記事内での使い方が正確かどうかをチェックしてください。

記事レビューの例

Taskツール呼び出し:
- subagent_type: article-reviewer
- prompt: src/content/2026-02-03-example.md の記事をレビューしてください

コンテキスト分離の仕組み

1. メインスキル → コーディネーター（tech-term-researcher / article-reviewer）を呼び出し
2. コーディネーター → 各用語/リンクごとにワーカーを並列起動
3. ワーカーは独立したコンテキストで調査（WebFetch結果がメインに漏れない）
4. コーディネーターは要約結果のみをメインスキルに返却

403エラー時の対応

ワーカーはWebFetchで403エラーが発生した場合、agent-browser経由でアクセスを試みる：

yarn agent-browser:install  # 初回のみ
yarn agent-browser open [URL]
yarn agent-browser snapshot
yarn agent-browser close

サブエージェントの詳細は .claude/agents/ を参照。

校正

ブログ記事が完成するタイミングで、textlintなどのツールを使って文章の品質を向上させてください。

npx textlint --fix src/content/今回作成した記事のファイルパス.md

• 指摘事項がある場合は、可能な限り修正してください。
• 重大な問題が解決できない場合は、ユーザーに確認を取ってください。