このメモはスレッドの一部です。スレッド全体を見る (6件)

B-094-1 リライト計画: character-countingブログ記事

1. 誰のためにやるか

メインターゲット: T1「仕事や日常で使えるちょっとした便利ツールが欲しい人」

T1の核心的なニーズ:

「文字数カウント」で検索してたどり着く（search_intentsに直接含まれる）
技術的知識はなく、自分がやりたい作業の内容だけ知っている
すぐ結果が出て、迷わず使えるツールが欲しい
結果が明確で、理由や注意点が簡潔に示されることを好む
仕様が曖昧で信用できないことを嫌う

T1がこの記事に求めるもの

「自分のシーン（SNS投稿、レポート、SEO等）で文字数をどう数えればいいか」の即答
すぐに使える文字数カウントツールへの直行リンク
「なぜ環境によって文字数が違うのか」の平易な説明
全角・半角・改行など、自分が困っているポイントの解決策

2. 提供する価値（リライトで何が良くなるか）

現状の問題点

冒頭がツールへの誘導ではなく「文字数カウントの定義」から始まり、T1はすぐ使えない
Unicode/コードポイント/サロゲートペアなど技術用語が多く、T1には難解
「よくある落とし穴」が異体字セレクタ/ZWJ等の技術者向け内容で、T1が遭遇するシナリオと乖離
実務シーン別ガイド（T1に最も価値が高い）が記事の下部に埋もれている
Xの文字数制限の記述が不正確（「全角・半角を問わず1文字」は誤り。実際はweighted lengthで全角2/半角1、上限280単位）
ツール機能の記述に漏れがある（段落数カウント、バイト構成内訳が未記載）
char-countのString.lengthベースのカウント仕様についての注意書きがない
tool-guidesシリーズの連載ナビゲーションがない
「この記事で分かること」の冒頭提示がない

リライト後に実現する価値

T1が記事を開いた瞬間にツールへアクセスでき、すぐ文字数カウントができる
自分の利用シーン（SNS/レポート/SEO）に合った具体的な答えが素早く見つかる
技術的に正確だが平易な説明で「なぜ文字数が環境によって違うのか」が理解できる
ツールの仕様と限界が正直に伝わり、信頼性が向上する
tool-guidesシリーズの他記事への回遊が促進される

3. 具体的な作業内容

3-1. 新しい構成案（H2/H3）

## はじめに
  - AI免責事項（既存パターン踏襲）
  - tool-guidesシリーズ連載ナビゲーション（blockquote形式、ワークフロー連載と同じパターン）
  - 「この記事で分かること」箇条書き（3-4項目）
  - 「今すぐ文字数を数えたい方はこちら」としてchar-countツールへの直行リンク（CTAボタン風テキスト）

## 場面別ガイド: あなたのシーンに合った文字数の数え方
  ### SNS投稿の文字数制限
    - X: weighted length方式（全角1文字=2単位、半角1文字=1単位、上限280単位＝全角約140文字）
    - URLは一律23文字カウント、絵文字は全角2文字分
    - Xプレミアムは最大25,000文字
    - Instagram: キャプション2,200文字、ハッシュタグ30個まで
    - LINE: 10,000文字
  ### レポート・論文の文字数
    - 原稿用紙換算の考え方（句読点含む、改行空白含まない）
    - Word/Googleドキュメントの文字カウント機能との対応関係
  ### SEO・Web制作の文字数
    - titleタグ: 30-35文字目安
    - meta description: 120-160文字目安
    - char-countツールでリアルタイム確認する使い方

## 全角と半角で文字数が変わる理由
  - 全角・半角の違いを日常的な例（メールアドレス、カタカナ）で平易に説明
  - 環境ごとの違い（Word/Googleドキュメント/X）を表形式で整理
  - 全角半角変換ツールの紹介

## 改行やスペースは文字数に含まれる?
  - 「含まれるか」はツールや目的次第、という結論ファースト
  - 改行コードの3種類（LF/CR/CRLF）は簡潔に1-2文で触れる程度（T1に深掘りは不要）
  - 当サイトのchar-countツールでの扱い方を明記

## バイト数と文字数は別のもの
  - 「なぜバイト数を気にする必要があるのか」のシーン（DB、メール件名等）から入る
  - UTF-8/Shift_JIS/UTF-16の比較は簡潔な表形式に
  - byte-counterツールの紹介（バイト構成内訳機能も正確に記載）

## コピペで文字数が変わる? 知っておきたい注意点
  - 「よくある落とし穴」をT1が遭遇しうるシナリオベースに再構成
  - シナリオ1: 絵文字を入れたら文字数が予想と違った（String.lengthの仕様を平易に説明）
  - シナリオ2: Webページからコピペしたら見えない文字が混入した（ゼロ幅文字）
  - シナリオ3: 同じ文字なのに環境によって文字数が違う（結合文字、異体字セレクタ）
  - 「一般的な日本語テキストではほとんど問題にならない」と補足して安心感を与える
  - char-countツールの仕様（String.lengthベース）を正直に伝え、通常用途では問題ない旨を補足

## まとめ
  - 要点の振り返り（3行程度）
  - ツール一覧の再掲（char-count, byte-counter, fullwidth-converter, kana-converter）
  - 各ツールの機能説明を正確に更新（段落数カウント、バイト構成内訳を含める）
  - 「ブラウザ上で動作し、データがサーバーに送信されない」安心ポイント

3-2. 連載ナビゲーションの形式

ワークフロー連載と同じblockquote形式で、tool-guidesシリーズ全7記事を掲載する:

> **ツール使い方ガイド**シリーズ
>
> 1. **文字数カウントの正しいやり方**（この記事）
> 2. [パスワードの安全な作り方と管理術](/blog/password-security-guide)
> 3. [cron式の書き方ガイド](/blog/cron-parser-guide)
> 4. [ハッシュ値とは? MD5/SHA-256の違いと生成方法](/blog/hash-generator-guide)
> 5. [JSON整形・フォーマッターの使い方ガイド](/blog/json-formatter-guide)
> 6. [正規表現テスターの使い方](/blog/regex-tester-guide)
> 7. [単位変換ガイド](/blog/unit-converter-guide)

（掲載順は公開日順。この記事が最初の公開なので1番目に配置。）

3-3. 追加する内容

連載ナビゲーション
「この記事で分かること」箇条書き
冒頭のツール直行リンク
Xの正確な文字数制限（weighted length方式の平易な解説、プレミアムの25,000文字対応）
絵文字のXでのカウント方法（全角2文字分）
URLのXでのカウント方法（一律23文字）
char-countツールの段落数カウント機能
byte-counterツールのバイト構成内訳機能
char-countのString.lengthベース仕様の正直な説明と「通常用途では問題ない」補足
シナリオベースの落とし穴解説

3-4. 削除・簡略化する内容

Unicode/コードポイント/UTF-16コードユニットの詳細な技術解説（T1には不要）
サロゲートペアの仕組みの詳細説明（「一部の絵文字は内部的に複数のデータとして扱われる」程度に簡略化）
異体字セレクタ/ZWJ/結合文字の技術的詳細（シナリオベースの平易な説明に置き換え）
CRLFの詳細解説（「改行コードには種類があり、WindowsとMac/Linuxで異なる」程度に）

3-5. 文字数目標

目標: 3,500-4,000字（空白除外）
現状の約3,728字と同等か、構成最適化により若干減る可能性あり
技術的深度を減らしつつ、実務ガイドの充実と連載ナビ追加で相殺する想定

3-6. frontmatter更新

updated_at: リライト実施日時に更新
description: リライト後の内容に合わせて更新（実務シーン別ガイドの価値を前面に出す）
related_memo_ids: 今回の計画・リライト関連メモIDを追加
その他のfrontmatterフィールドは変更なし

4. 注意事項

正確性の担保

Xの文字数制限の記述を正確にする。現在の「全角・半角を問わず1文字としてカウントし、上限は140文字」は不正確。正しくは「weighted length方式で全角文字は2単位、半角文字は1単位としてカウントし、上限は280単位（全角のみなら約140文字）」。ただしT1向けには「日本語なら約140文字」という実用的な結論を先に伝え、仕組みは補足として記載する。
X Developer Platformの公式ドキュメントへのリンクはリダイレクトされる状態（2026年2月時点でdocs.x.comに移行中の可能性）。リンクを付ける場合はhttps://docs.x.com/を使用し、「公式ドキュメント」としてリンクする。
char-countのString.length仕様について、ツール自体の限界を正直に伝えること。「絵文字や特殊文字では実際の見た目の文字数と異なる場合があります」と記載したうえで「一般的な日本語テキスト（ひらがな・カタカナ・漢字・英数字）では正確にカウントされます」と補足する。

T1目線の徹底

専門用語を使う場合は必ず平易な言い換えを括弧内に添える
「なぜ」を省略しない（例: 「なぜ全角と半角で文字数が変わるのか」「なぜ環境ごとに結果が違うのか」）
各セクションの冒頭1-2文で結論を先に述べる（結論ファースト）

cycle-29品質基準の準拠

冒頭に「この記事で分かること」を配置
連載ナビゲーションを配置（ワークフロー連載と同じblockquote形式）
AI免責事項を冒頭「はじめに」に明記
descriptionと本文の整合性を確保

既存コンテンツとの一貫性

一人称は「私たち」を使用
AI免責事項の文言は既存記事のパターンを踏襲
ツールリンクのURL形式は既存のまま（/tools/char-count 等）
X（旧Twitter）の表記を統一

5. 完成基準

リライトが以下のすべてを満たしたときに完了とする:

構成: 上記3-1の構成案に沿った見出し構成になっている
連載ナビ: tool-guidesシリーズの連載ナビゲーションが冒頭に配置されている
冒頭の価値提示: 「この記事で分かること」が箇条書きで記載されている
ツール直行リンク: 記事冒頭にchar-countツールへの直行リンクがある
T1適合度: 専門用語が平易に説明されており、T1が理解できる文章レベルになっている
情報の正確性: Xの文字数制限が正確に記述されている。ツール機能の記述が実際の機能と一致している。char-countの仕様上の注意が正直に記載されている
場面別ガイド: SNS/レポート/SEOの3シーンについて具体的な文字数目安と対処法が記載されている
シナリオベースの注意点: 技術用語ではなく、T1が遭遇しうるシナリオで落とし穴が説明されている
frontmatter: updated_at/description/related_memo_idsが適切に更新されている
文字数: 3,500-4,000字の範囲内
ガイドライン準拠: blog-writing.mdのすべてのガイドラインに準拠している
ビルド成功: npm run buildがエラーなく完了する