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

B-094-1 調査結果: character-countingブログ記事の現状分析

1. 現在の記事の概要

基本情報

ファイル: src/content/blog/2026-02-14-character-counting-guide.md
タイトル: 「文字数カウントの正しいやり方: 全角・半角・改行の違いと注意点」
slug: character-counting-guide
カテゴリ: guide / シリーズ: tool-guides
タグ: テキスト処理, オンラインツール, 日本語
公開日: 2026-02-15 / 最終更新: 2026-02-20
関連ツール: char-count, byte-counter, fullwidth-converter, kana-converter

構成（H2 x 8セクション、H3 x 3サブセクション）

はじめに -- 文字数カウントが必要な場面の例示、AI免責事項
文字数カウントの基本 -- Unicode/コードポイント/ツール差異の説明、char-countツールへの誘導
全角と半角の違い -- 全角・半角の起源、環境ごとの扱い（Word/Google Docs/X）、fullwidth-converterへの誘導
改行・スペースのカウント方法 -- LF/CR/CRLFの解説、スペースの扱い
バイト数と文字数の違い -- UTF-8/Shift_JIS/UTF-16のバイト数比較、MySQLの例、byte-counterへの誘導
よくある落とし穴 -- 絵文字、結合文字、異体字セレクタ、ゼロ幅文字、kana-converterへの誘導
実務シーン別ガイド (H3 x 3)
- SNS投稿の文字数制限（X/Instagram/LINE）
- SEO・Web制作（title/meta description/H1）
- レポート・論文（原稿用紙換算）
まとめ -- ツール一覧の再掲

文字数

本文文字数（空白除外、Markdown記法除外）: 約3,728字
本文行数: 109行
ツールリンク: 8箇所（char-count x3, byte-counter x1, fullwidth-converter x1, kana-converter x1, まとめで3つ再掲）

2. ターゲットユーザー分析

最も関連するペルソナ: T1「仕事や日常で使えるちょっとした便利ツールが欲しい人」

根拠:

T1のsearch_intentsに「文字数カウント」が直接含まれている
T1は「自分がやりたい作業の内容」は知っているが「プログラミングや文字コードなどの技術的な知識」は知らない
T1は「入力や操作が少なく、すぐ結果が出る簡単なツール」「結果が明確で、理由や注意点が簡潔に示されること」を求めている

副次ターゲット:

T2「Webサイト製作を学びたいエンジニア」 -- SEO・Web制作セクションの内容、バイト数・エンコーディングの技術知識に関心がある可能性

現状の記事とT1のギャップ

T1の特性	現状の記事の対応状況	問題点
技術的知識なし	Unicode/コードポイント/サロゲートペアなど専門用語多用	T1には難解すぎる。用語解説も不十分
すぐ結果が出ることを求める	ツールリンクは8箇所あるが、記事冒頭でのツール誘導が弱い	「はじめに」を読んでからツールまでスクロールが必要
仕様が曖昧で信用できないことを嫌う	環境ごとのカウント方式を一覧で示している点は良い	しかし情報が古い可能性（Xの文字数制限等）の検証が必要
専門知識不要を好む	「よくある落とし穴」セクションが技術者向け	ZWJ、異体字セレクタはT1には不要な深さ

3. ツールの実際の機能一覧

文字数カウント (char-count)

文字数: String.length（UTF-16コードユニット数）
文字数（空白除く）: 空白文字(\s)を除いた文字数
バイト数（UTF-8）: TextEncoderによるUTF-8バイト数
単語数: Intl.Segmenterによる日本語対応の単語分割（フォールバックはスペース区切り）
行数: 改行(\n)で分割した行数
段落数: 空行(\n\s*\n)で分割した段落数

バイト数計算 (byte-counter)

バイト数（UTF-8）: メイン指標として大きく表示
文字数/文字数（空白除く）/行数/単語数: 補助指標
バイト構成の内訳表示: 1バイト文字(ASCII)、2バイト文字、3バイト文字(日本語等)、4バイト文字(絵文字等)の個数

全角半角変換 (fullwidth-converter)

英数字・カタカナの全角/半角相互変換

ひらがな・カタカナ変換 (kana-converter)

ひらがな/カタカナ/半角カナの相互変換

記事との不整合

記事ではchar-countの機能を「文字数・バイト数・行数・単語数をリアルタイムで確認」と記載しているが、実際には「段落数」も表示される（記事に未記載）
記事ではbyte-counterの機能を「UTF-8でのバイト数をリアルタイムで確認」と記載しているが、実際にはバイト構成の内訳（1/2/3/4バイト文字の分類）も表示される（記事に未記載）
char-countのロジックはString.lengthを使用しており、記事で指摘している「サロゲートペアの絵文字が2としてカウントされる」問題がこのツール自体にも該当する。これを記事で正直に伝えたうえで、「一般的な日本語テキストでは問題にならない」と補足すべき

4. 前サイクル(cycle-29)のリライト品質基準

cycle-29の方針

B-093として、最も古い初期ブログ記事3本の「ターゲットユーザーに合わせた全面的な価値向上」を実施
descriptionのみの修正ではなく、記事の内容・構成・書き方その他すべてを抜本的に最適化
「量より質」の原則に従い、1サイクル3本ずつ丁寧に進める

リライト後の品質水準（how-we-built-this-siteを参考）

リライト後の記事には以下の特徴がある:

冒頭で価値を明示: 「この記事で読者が得られるもの」を箇条書きで列挙
連載ナビゲーション: ワークフロー連載（全5回）のナビを記事冒頭に配置
「なぜ」の徹底: 各セクションが「なぜそうしたか」の判断理由を明確に説明
- 例: 「なぜルールは5つだけなのか」「なぜPV最大化がゴールなのか」
具体的な実例: 実際のメモ引用、Mermaid図、コード例などの具体資料
採用しなかった選択肢: 代替案とその不採用理由の記載
適切なクロスリンク: 関連記事・メモアーカイブ・GitHubリポジトリへの誘導
AI免責事項: 冒頭の「はじめに」セクションに明記
文字数: 約3,587字（空白除外）。大幅に増量（元の約2,000字から約3倍）

レビューで重視された観点

ターゲットユーザーの前提知識に合った説明レベル
読者にとっての具体的な価値の明示
descriptionと本文の整合性
ファイル反映の確実性（実装レビューで「ファイル未反映」が2回発覚）

5. リライトに活かすべきポイント

構成面

冒頭にツールへの直接リンクを配置する: T1は「すぐ結果が出ること」を求めている。記事を読まなくてもすぐツールにアクセスできるようにすべき
「この記事で分かること」を冒頭に追加する: cycle-29の品質基準に準拠
連載ナビゲーションを追加する: tool-guidesシリーズの一部として、他の記事への導線を配置
実務シーン別ガイドを記事上部に移動する: T1にとって最も価値が高いのは「自分のシーンでどうすればいいか」の答え。技術解説の前に配置すべき

内容面

技術的深度をT1に合わせて調整する: Unicode/コードポイント/サロゲートペアの解説は大幅に簡略化し、「なぜ結果が異なるのか」を平易に説明する方向へ
「よくある落とし穴」を実務寄りに再構成する: 異体字セレクタやZWJの詳細な技術解説ではなく、「コピペしたら文字数が変わった」等のT1が遭遇しうるシナリオベースに
ツール機能の正確な記述: 段落数カウント、バイト構成内訳など、実際の機能を正確に反映する
SNS文字数制限の情報を最新化・検証する: Xの文字数制限の記述を確認し正確にする
char-countツールの仕様上の注意を正直に伝える: String.lengthベースのカウントであるため絵文字等で差異がある点を明記しつつ、通常用途では問題ないことを補足

品質面

descriptionと本文の整合性を確認する: 現在のdescriptionは比較的良いが、リライト後に齟齬が出ないよう注意
Xの旧Twitter表記の統一: 記事内で「X（旧Twitter）」と表記統一されているか確認
外部リンク・出典の確認: 「X Developer Platformの公式ドキュメントを参照」と記載があるがリンクが無い

注意事項

現状の記事は約3,728字で、cycle-29リライト後の記事（約3,587字）と同等のボリューム。リライトで過度に増量する必要はないが、構成の見直しと内容の最適化が主眼
T1向けの記事として、技術的な正確さよりも「分かりやすさ」と「すぐ使える実用性」を優先すべき
ただし不正確な情報の記載はconstitution Rule 3に反するため、技術的に正確な範囲で平易に表現する