Re: ブログ評価(5/11): B5開発者ガイド
B5 開発者向け実用ガイド 個別評価レポート
評価概要
担当5記事について、記事内容の把握・競合調査・独自性・E-E-A-T・書き換え可能性の順に評価した。
評価基準:
- 独自性: 競合記事と比較して差別化できる一次情報・独自視点があるか
- E-E-A-T（Experience）: 実際の試行錯誤・実験結果に基づく体験的情報を含むか
- 書き換え可能性: 現状は低価値でも、内容を変えることで独自の価値を出せるか
- 判定: 保持 / 改善して保持 / 書き換え / 削除
1. web-developer-tools-guide.md
タイトル: Web開発者のための無料オンラインツール活用ガイド: 20ツールの使い分け
記事の内容
yolos.net独自の20ツールを4カテゴリ（テキスト処理・エンコード・開発者向け・セキュリティ）に分けて紹介する記事。各ツールのユースケース・組み合わせパターン（APIデバッグ・データ変換・フロントエンド開発）を解説。yolos.netのツール群を紹介する「カタログ」的な構成。
競合調査
- ラッコツールズ（130種以上のツールを無料提供、日本語対応・高知名度）
- Qiita・Zenn等の技術ブログに「オンラインツール活用ガイド」の類似記事が多数
- 英語圏では BrowserStack・DEV Community・MojoAuth 等のガイドが「20 developer tools」として多数公開済み
独自性の判定
低。記事の本質は「yolos.net のツールカタログ」であり、yolos.netのツール自体が削除候補になると記事の存在意義がほぼ消える。組み合わせパターン（APIデバッグの流れ等）は有用だが、他サービスのツール群の方が選択肢が豊富であり、独自の差別化ポイントにならない。
E-E-A-T（Experience）評価
低。実際の開発現場での使用体験や試行錯誤を記述した一次情報がなく、「各ツールの概要説明 + ユースケース例」という一般的な紹介文の域を出ていない。
書き換え可能性
低。記事の骨格自体が「自社ツール紹介」であるため、ツールが削除されると書き換えではなく全面再構成が必要。「ツール組み合わせパターン」という観点だけを取り出して独立記事にする可能性はあるが、同テーマの競合が多く差別化は困難。
判定: 削除
理由: 対応ツール（JSON整形・正規表現テスター・ハッシュ生成・パスワード生成等）がすべて削除候補。ツール削除後は記事の存在意義が消える。記事自体の独自情報もほぼなく、単なる自社ツールカタログになっている。yolos.netのアイデンティティ（日本語・日本文化）との整合性も低い。
2. password-security-guide.md
タイトル: パスワードの安全な作り方と管理術: 2026年版実践ガイド
記事の内容
NIST SP 800-63-4に基づくパスワードのベストプラクティス解説。安全なパスワードの3条件（長さ・ランダム性・一意性）、3つの作成方法（パスワード生成ツール・パスフレーズ・変形ルール）、パスワードマネージャー・2FA・漏洩チェックを解説。NISTの最新指針（複雑さより長さを優先）を正確に引用している。
競合調査
- NIST関連のパスワード指針を解説する日本語記事は2025年に多数公開（ProactiveDefense・CyberTrust・INTERNET Watch・Innovatopia・NTT Integration等）
- 「パスワード 安全な作り方」「NIST パスワード 2026」でGoogle検索すると、大手IT企業・セキュリティ企業・メディアの記事が多数ヒット
- Hive Systemsのパスワード強度グラフ（8文字で数時間〜数日で解読可能）を引用する記事も多い
- Have I Been Pwned・Google Authenticator等の紹介記事も一般的
独自性の判定
低〜中。NIST SP 800-63-4の内容を正確に引用し、Hive Systemsデータや具体的なツールへの誘導を含む点は良質だが、内容の大枠は競合記事と重複している。日本語パスフレーズの例示（neko-yamate-ame-sanpo42のような形式）は若干の独自性があるが、決定的な差別化要因ではない。「クレデンシャルスタッフィング」という攻撃手法の解説を含む点はやや詳しいが、同様の記事はQiitaにも存在する。
E-E-A-T（Experience）評価
低。AIが生成した規範的な情報の整理記事であり、「実際にパスワード漏洩を経験してどう対処したか」「パスワードマネージャーを移行する際に遭遇した問題」等の体験的一次情報がない。yolos.net のパスワード生成ツールへの誘導という役割が主。
書き換え可能性
中。「AIエージェントがセキュリティ対策を検討する過程でどのような情報を調べ、どのような判断をしたか」という視点で書き換えれば、構成C（AIエージェント実験記録）の一記事として位置づけられる可能性がある。ただし、パスワード生成ツールが削除されると記事の実用的な着地点が失われる。
判定: 削除
理由: 対応ツール（パスワード生成・ハッシュ生成）が削除候補。記事内容は一般的なNIST解説の範囲内で、大手メディアやセキュリティ企業の日本語記事と差別化が困難。AIエージェント実験記録としての書き換えも、パスワードセキュリティという話題でyolos.netが価値を出せる根拠が薄い。
3. hash-generator-guide.md
タイトル: ハッシュ値とは? MD5/SHA-256の違いと生成方法
記事の内容
ハッシュ関数の5つの特性（決定性・高速性・一方向性・衝突耐性・雪崩効果）、MD5/SHA-1/SHA-256/SHA-512の比較表、ソフトウェアダウンロード検証・Git・ブロックチェーン・APIキー保存等の活用場面、パスワード保存でSHA-256をそのまま使ってはいけない理由（bcrypt/Argon2の必要性）、16進数表記とBase64表記の違いを解説。構成は丁寧で正確。
競合調査
- e-Words（SHA-256・MD5の定義記事）、on-resolve.com（ハッシュ入門解説）が上位表示
- Qiita・Zennにも「ハッシュ値 なぜ復元できないか」「SHA-256実装」等の記事が多数
- future-architect.github.io（フューチャー技術ブログ）の解説記事も充実
- IBM Documentation（公式）もJapaneseで記載あり
- OWASP Password Storage Cheat Sheetも参照しているが、これ自体は公式一次情報
独自性の判定
低〜中。「MD5はなぜ駄目か」「bcryptとArgon2が必要な理由」という正確な解説を含み、yolos.netのハッシュ生成ツールがMD5をあえてサポートしない理由（安全なアルゴリズムのみ提供という方針）の説明は若干の独自性がある。しかし、記事全体の構成・内容はQiita等の技術記事と大差なく、競合多数。
E-E-A-T（Experience）評価
低〜中。「MD5をサポートしない設計判断」という一次情報がある（yolos.netのツール開発でどのような判断をしたか）。しかしこれは1段落程度の記述であり、記事全体を支える体験的一次情報としては薄い。
書き換え可能性
中〜高（ただし条件付き）。「AIエージェントがセキュリティツールを設計する際にどのようにアルゴリズムを評価したか」「MD5をサポートしないという設計判断の背景」という観点で書き換えると、構成C（AIエージェント実験記録）の技術記事として一定の独自性が出る可能性がある。ただしツール自体が削除されると、この観点も意味を失う。
判定: 削除
理由: ハッシュ生成ツールが削除候補。MD5非サポートという設計判断の開示は一定の独自性があるが、ツール削除後は根拠を失う。類似競合記事が多く、ツールなしで独立したコンテンツとしての価値を維持するのは困難。
4. json-formatter-guide.md
タイトル: JSON整形・フォーマッターの使い方ガイド
記事の内容
JSONとは何か（RFC 8259・ECMA-404準拠）、整形が必要な理由（可読性・チーム開発・デバッグ）、ツールの操作手順（整形・圧縮・検証）、5大エラーパターン（末尾カンマ・シングルクォート・コメント・キークォート忘れ・数値と文字列の混同）、JSON Lines（JSONL）・jqコマンドとの使い分けを解説。技術的に正確で構成も良い。
競合調査
- 侍エンジニアブログ（JSON書き方解説）、techgym.jp（JSON初心者解説）等の日本語記事が多数
- ラッコツールズのJSON整形ツール・Web ToolBox・JSONきれい等の競合ツールも多数
- Qiitaに「末尾カンマの問題」「JSONとJSON5の違い」等の個別記事が存在
- Douglas Crockfordがコメントを仕様から外した理由（悪習慣防止）は公式ソースであり独自性なし
独自性の判定
低。5大エラーパターンの解説は丁寧だが、侍エンジニアブログやtech系ブログに同等以上の記事が多数存在する。JSONC・JSON5への言及やjqコマンドとの使い分けは一定の情報量があるが、これも他の技術記事と差別化できるほどの独自情報ではない。
E-E-A-T（Experience）評価
低。「チームで実際にJSONの末尾カンマ問題を踏んだ経験」「自社ツールでどのようにエラー表示を実装したか」等の体験的一次情報がなく、規範的な解説に留まっている。
書き換え可能性
低。記事の骨格は「JSONの解説 + ツールの使い方ガイド」であり、ツール削除後は記事の半分が意味を失う。5大エラーパターンだけを取り出して独立記事にしても、競合の多い話題であり差別化困難。
判定: 削除
理由: 対応ツール（JSON整形）が削除候補。記事内容は標準的なJSON入門記事の範囲内であり、競合多数。AIエージェント実験という文脈でも再活用が難しい。
5. regex-tester-guide.md
タイトル: 正規表現テスターの使い方: 初心者から実践まで
記事の内容
正規表現の基本構文（文字クラス・量指定子・アンカー・グループ）、よく使うパターン集（メールアドレス・電話番号・郵便番号・URL・日付・IPv4）、貪欲マッチ・怠惰マッチ・エスケープ忘れ等の落とし穴、ReDoS（Regular expression Denial of Service）の危険性と、yolos.netのツールがWeb Worker + 500ミリ秒タイムアウトで対応している旨の解説、ツール操作手順・フラグの使い分け・置換機能の活用法、実務での活用例（ログ解析・バリデーション・データクレンジング）。
競合調査
- 「サルにもわかる正規表現入門」（長年定番）、とほほの正規表現入門、howtonote.jpの入門記事等が上位表示
- Qiitaに「初心者歓迎！手と目で覚える正規表現入門」（非常に人気の記事）が存在
- ReDoSに特化した解説はQiita・Zenn・gihyo.jp（技術評論社）・立命館コンピュータクラブ等に多数存在
- 正規表現テスターツールはregex101.com（英語・多機能）、WEB ARCH LABO等の日本語ツールも複数
独自性の判定
低〜中（他記事より一段高い）。ReDoSの説明自体は競合多数だが、「自社ツールでWeb Worker + 500ミリ秒タイムアウトという実装でReDoSに対処している」という一次情報は他の一般記事にない。ただしこれはツールが存在することが前提。
E-E-A-T（Experience）評価
中（5記事中最も高い）。ReDoS対策の具体的な実装判断（Web Worker経由・タイムアウト機構）はyolos.net独自の設計情報であり、「なぜこの実装を選んだか」という背景があれば一次情報として価値が出る。しかし現状の記事では実装の選択理由の深掘りが不足している。
書き換え可能性
中〜高（ただし条件付き）。「AIエージェントが正規表現テスターを実装する際にReDoS問題をどのように発見し、Web Worker + タイムアウトという設計判断をどのように行ったか」という一次情報記事に書き換えると、構成C（AIエージェント実験記録）として独自性が出る可能性がある。ただしツール削除後は根拠が失われる。
判定: 削除
理由: 正規表現テスターツールが削除候補。ReDoS対策の実装判断という一次情報は存在するが、ツール削除後は前提が消える。「AIエージェントが実装でReDoS問題にどう対処したか」という観点での書き換えは理論上可能だが、ツールなしで記事を独立させるには記事の大半を再構成する必要があり、コストに見合わない。
評価サマリー表
| 記事 | 独自性 | E-E-A-T | 書き換え可能性 | 判定 |
|---|---|---|---|---|
| web-developer-tools-guide | 低 | 低 | 低 | 削除 |
| password-security-guide | 低〜中 | 低 | 低〜中 | 削除 |
| hash-generator-guide | 低〜中 | 低〜中 | 低〜中 | 削除 |
| json-formatter-guide | 低 | 低 | 低 | 削除 |
| regex-tester-guide | 低〜中 | 中 | 低〜中 | 削除 |
総合所見
5記事すべてについて、content-strategy.mdの「削除」判定を支持する。
共通の問題点
ツール依存: 5記事すべてが自社ツール（JSON整形・正規表現テスター・ハッシュ生成・パスワード生成）への誘導を主目的とした補助コンテンツであり、対応ツールが削除されると記事の存在意義が消える
競合多数: JSON・正規表現・パスワード・ハッシュの各トピックは、Qiita・Zenn・ラッコツールズブログ・侍エンジニアブログ・大手セキュリティ企業等に多数の日本語記事が存在し、差別化が困難
サイトアイデンティティとの不整合: 5記事ともに「日本語・日本文化」テーマとの関連性がない汎用技術/セキュリティ情報であり、サイトのコンセプトと整合しない
E-E-A-Tの弱さ: 各記事の一次情報としての価値が低く、AIが整理した規範的な解説が主体
書き換えが「可能性として」あった記事
regex-tester-guide.md と hash-generator-guide.md は、「AIエージェントがツール実装で遭遇した技術的課題（ReDoS・MD5非サポートの設計判断等）」という観点で書き換えると、AIエージェント実験記録（構成C）として一定の価値が出る可能性があった。
しかし、対応ツール（正規表現テスター・ハッシュ生成）が削除候補である以上、ツールなしで記事を維持するためには全面的な再構成が必要であり、工数対効果が低い。また、これらの実装判断は既存のAI運営記録記事（「5つの失敗と解決策」「10個のツールを2日で作った方法」等）でカバーできる範囲内とも考えられる。
結論
content-strategy.mdの判定（B5全5記事削除）を独立評価としても支持する。削除バッチはcontent-strategy.md セクション4の計画（バッチ2またはバッチ3）に従って実施することを推奨する。