SG記事 AI検索・読者理解向け改善ルール

基本方針

SG記事の改善では、AI検索向けの特別な裏技ではなく、読者にとって分かりやすく、試験で使える内容にすることを優先する。

特に、次の観点を重視する。

  • 用語の一般説明だけで終わらせない
  • 試験で選択肢を切る判断軸を示す
  • 混同しやすい類似語との違いを明確にする
  • 既存記事と粒度・見出し・トーンを揃える
  • 不自然なキーワード詰め込みは行わない
  • AI専用ページやキーワード違いだけの量産は行わない

追加ブロックの目的

通常記事では、必要に応じて記事冒頭に次の3ブロックを追加する。

  1. このページで切り分けること（先にここだけ）
  2. SG試験で選択肢を切る判断軸（〇〇編）
  3. 関連記事との役割分担（混同防止）

この3ブロックは、記事本文を読む前に、読者が次のことを把握できるようにするためのもの。

  • このページの主題
  • 似た用語との違い
  • 試験でどの言葉に注目すればよいか
  • 関連記事のうち、どれを読めばよいか

追加位置

追加ブロックは、原則として本文の最初の主要見出し「## まず結論」の直後に配置する。

ただし、既に同等の切り分けブロックがある場合は、重複して追加せず、既存ブロックを短く整える。

3ブロックの扱い

3ブロックは必ずすべて追加するものではない。

  • 混同しやすい用語がある場合：3ブロックすべてを検討する
  • 関連記事が少ない場合：「関連記事との役割分担」は省略してよい
  • 既存本文で判断軸が十分に示されている場合：短い補足にとどめる
  • 記事冒頭が長くなりすぎる場合：判断軸を優先し、関連リンクは省略してよい

追加対象に向いている記事

次のような記事は、追加ブロックの対象にしやすい。

  • 類似語と混同しやすい記事
  • 「AとBの違い」で検索されやすい記事
  • 試験で選択肢の切り分けが重要な記事
  • 関連記事が複数あり、役割分担を明確にしたい記事
  • 既存本文はあるが、冒頭で判断軸が弱い記事

例：

  • 認証・認可・アクセス制御
  • HTTP・HTTPS・SSL/TLS・DNSSEC
  • 電子証明書・電子署名・MAC
  • IDS・IPS・ファイアウォール
  • SOC・CSIRT・JPCERT/CC
  • CRL・OCSP
  • MTBF・MTTR・稼働率
  • リスク回避・低減・移転・保有

追加対象外にするページ

次のページには、原則として追加しない。

  • カテゴリページ
  • 一覧ページ
  • indexページ
  • allページ
  • summary / overview 系のまとめページ
  • すでに比較記事として十分に整理されており、冒頭に追加しても価値が増えないページ
  • 記事冒頭が長くなりすぎるページ
  • 関連記事との違いを無理に作る必要がない単独記事

追加ブロック1：このページで切り分けること（先にここだけ）

目的

記事の冒頭で、読者に「このページで何を理解するか」を示す。

基本形

## このページで切り分けること（先にここだけ）

このページは、**〇〇**を中心に整理します。

- A：〜
- B：〜
- C：〜

> 迷ったら、
> **「〇〇の話か」** を見ます。

書き方ルール

  • 1文目はできるだけ「このページは、〇〇を中心に整理します。」に揃える
  • 箇条書きは原則3項目まで
  • 長くても4項目まで
  • 用語説明は短くする
  • 初心者が読んで分かる言葉を使う
  • できれば「迷ったら〜を見る」の形で判断軸を入れる

追加ブロック2：SG試験で選択肢を切る判断軸（〇〇編）

目的

試験中に、選択肢を切るための判断軸を示す。

基本形

## SG試験で選択肢を切る判断軸（〇〇編）

- 「〜」が出る
  → Aの話

- 「〜」が出る
  → Bの話

- 「〜」と書かれている
  → 誤り。〇〇は〜ではない

書き方ルール

  • 原則3項目まで
  • 多くても4項目まで
  • 「何が出たら、どれを選ぶか」が分かる形にする
  • 正解だけでなく、誤答を切る視点も入れる
  • 「〜は誤り」と書く場合は、理由を短く添える
  • 本文と重複しすぎないようにする

追加ブロック3：関連記事との役割分担（混同防止）

目的

関連する記事同士の重複を防ぎ、読者が目的に合う記事を選べるようにする。

基本形

## 関連記事との役割分担（混同防止）

- 〇〇を中心に確認したい → `/sg/example-a/`
- 〇〇との違いをまとめて見たい → `/sg/example-b/`
- 運用面まで確認したい → `/sg/example-c/`

書き方ルール

  • 原則3リンクまで
  • 多くても4リンクまで
  • 内部リンクは必ず実在確認する
  • 実在しないリンクは追加しない
  • 関連が弱い記事を無理に入れない
  • 「この記事では何を扱うか」「関連記事では何を扱うか」が分かる表現にする

内部リンクの確認ルール

関連記事リンクを追加する場合は、次のいずれかを確認する。

  • 対応する Markdown ファイルが存在する
  • 対応する permalink が存在する
  • 既存記事内で同じリンクが使われている

確認できないリンクは追加しない。 候補として必要な場合は、作業報告に「未追加リンク候補」として記載する。

表現の統一ルール

次の表現を基本形として使う。

このページは、**〇〇**を中心に整理します。

判断軸では、次のような表現を優先する。

迷ったら、**「〇〇の話か」** を見ます。

または、

迷ったら、**「AかBか」** を先に見ます。

文章量の目安

追加ブロック全体は、長くしすぎない。

目安：

  • このページで切り分けること：5〜8行程度
  • SG試験で選択肢を切る判断軸：3項目程度
  • 関連記事との役割分担：3リンク程度

記事冒頭が重くなる場合は、無理に3ブロックすべてを長くしない。

よくある良い例

認証・認可・アクセス制御

- 認証：その人が誰かを確認する
- 認可：認証後に、何を許可するか決める
- アクセス制御：決めた権限どおりに通す／拒否する

判断軸：

迷ったら、**「誰か」を確認する話か、「何ができるか」を決める話か**を見ます。

DNSSEC・HTTPS/TLS

- DNSSEC：DNS応答の正当性・完全性を確認する
- HTTPS/TLS：Web通信の暗号化と相手確認を行う

判断軸：

迷ったら、**名前解決を守る話か、通信中を守る話か**を見ます。

電子証明書・電子署名・MAC

- 電子証明書：公開鍵が誰のものかを証明する
- 電子署名：署名者確認、改ざん検知、否認防止に使う
- MAC：改ざん検知と送信者確認に使うが、否認防止は弱い

判断軸：

迷ったら、**あとで「自分は関係ない」と言えないようにする話か**を見ます。

注意点

  • 既存記事の見出し構成は原則として壊さない
  • front matter は不要に変更しない
  • title / description / permalink / tags / date / last_modified_at を勝手に変更しない
  • 追加ブロックを入れるだけで本文品質が下がらないようにする
  • 同じ説明を複数記事で不自然に繰り返さない
  • 比較記事がすでにある場合は、その記事への導線を優先する
  • 読者にとって不要なリンクは増やさない
  • AI検索対策という理由だけで低品質なページを量産しない

作業報告ルール

このルールに従って記事を改善した場合は、作業後に次を報告する。

  • 変更したファイル
  • 追加したブロック
  • 追加した判断軸
  • 追加した関連記事リンク
  • リンク切れ確認結果
  • 編集しなかった候補と理由

© 2024-2026 stemtazoo. All rights reserved.