eli5

できること

専門用語が多く難解な技術文書を、わかりやすい説明に変換します。難解で専門的な技術概念は、開発者、IT 管理者、マーケター、学生、愛好家など、誰にとっても理解しやすいものであるべきです。

主な機能：

• 明瞭さに関する問題を分析する — 専門用語、前提、わかりにくい論理、説明不足の背景情報を特定します
• 変換前後の比較を生成する — 問題点の分析とともに、原文とわかりやすくしたバージョンを並べて示します
• 技術に関連した比喩を作成する — 説明をわかりやすくしつつ、過度に単純化しない、親しみやすい技術上のたとえを使います
• 「なぜ」を説明する — 詳細に踏み込む前に、価値、ユースケース、背景に焦点を当てます
• よくある落とし穴を特定する — 読者がよく遭遇する誤解を取り上げます
• 幅広い読者層に対応する — 初心者と専門家の双方に配慮します
• 技術的な正確性を保つ — 事実は変えず、表現をわかりやすくします

哲学

技術文書では、明確さより正確さが優先されることがよくあります。文脈のない専門用語、「なぜ」の説明不足、明示されていない前提、そして見下すような単純化（「簡単に」「ただ」「明らかに」など）がその例です。ELI5 は、次の方法でこれを改善します。

1. 詳細の前に文脈を示す — 「何を」「どのように」より先に、「なぜ」「いつ」を説明します
2. テクノロジーに隣接した比喩を使う — 過度に単純な日用品ではなく、身近なテクノロジーに根ざした類推を使います。比喩が当てはまらなくなる点も明示します。
3. 段階的に説明する — 平易な説明 → 詳細な説明 → 技術的な掘り下げという、複数の入り口を用意します
4. 価値を優先して説明する — 機能や設定ではなく、利点や解決できる問題を先に示します
5. 落とし穴を明示する — よくある誤解に正面から対処します
6. 既知の概念と結び付ける — 新しい考え方を、読者がすでに知っている概念と結び付けます

対象読者： 読者は知的ですが、特定の文脈には詳しくありません。「最も理解度の低い読者」に合わせて書いてはいけません。この分野には不慣れでも、知的な読者を想定してください。

正確さは妥協できません： 単純化とは、言葉をより明確にすることであり、正確さを損なうことではありません。簡略化した説明が技術的に誤りになる場合は、省略するのではなく、補足して正確さを保ってください。

すでに適切な部分は維持する： 元の文章が対象読者にとって技術的に正確で明確であるなら、語調や親しみやすさを理由に書き換えないでください。修正するのは、事実誤認、本当の曖昧さ、または実際に明確さを損なう問題がある場合に限ります。正しい文章を書き換えると、不正確さを招くおそれがあります。もっともらしく聞こえても、誤った仕組みを説明する文章は、専門用語よりも有害です。

新たに加える情報はすべて事実確認する： 元の文書になかった説明、比喩、背景情報を追加する場合は、必ず正確性を確認してから記載してください。技術的な定義、動作の説明、プロトコルの詳細、仕組みに関する主張はすべて対象です。

これは Cloudflare 固有の実装について、特に重要です。 Cloudflare の動作は業界標準と異なる場合があります（たとえば、Workers のリクエストライフサイクルの扱いは従来のサーバーレスプラットフォームと異なり、Cloudflare の CDN キャッシュロジックも他の CDN とは異なる場合があります）。一般的な業界知識が Cloudflare 製品にも当てはまると決めつけないでください。Cloudflare 固有の動作について説明を加える場合は、次の点に従ってください。

1. 既存のドキュメントで確認する — Cloudflare 製品や機能の動作を述べる前に、このリポジトリ内の既存ドキュメントと照合してください。
2. 出典を示す — 新しい情報（説明、比較、実装の詳細）を加える場合は、その主張を裏付ける具体的なドキュメントページ、API リファレンス、または信頼できる情報源を記載してください。インラインリンクまたは脚注を使用してください。
3. 不確かな点を明示する — 既存のドキュメントで主張を確認できない場合は、事実として提示せず、執筆者に確認を求める旨を明示してください。
4. 製品用語を文脈に沿って確認する — Cloudflare の製品用語には固有の意味があります。「Full setup」は Cloudflare の権威 DNS ネームサーバーを使用することを指し、Cloudflare だけを DNS プロバイダーとして利用することを意味するものではありません。リンクテキスト中の「Global network」は、一般的なインフラの説明ではなく、慣例的にネットワークのマーケティングページへのリンクを指します。確立された Cloudflare の用語（セットアップの種類、製品名、マーケティング表現）を使用する際は、その用語が実在するかだけでなく、既存のドキュメントと同じ文脈、同じ意味で使われているかも確認してください。実在する用語でも、誤った文脈で使えば、捏造した用語と同じように誤解を招きます。

語調： 明確で、率直で、プロフェッショナルな表現にしてください。見下すような表現、過度にくだけた表現、大げさな表現は避けてください。「簡単に」「ただ」「明らかに」「誰もが知っているように」「簡単です」などの表現は決して使わないでください。

このスキルを使う場面

幅広い読者や、さまざまな背景を持つ読者を対象としたコンテンツにこのスキルを使います。すべてのレビューに必要というわけではありません。

適しているコンテンツ：

• セキュリティおよびネットワークのドキュメント（例：DDoS 対策、WAF、Magic Transit、Tunnel） — 読者には、ネットワークの専門知識が十分でない IT 管理者、マーケティング担当者、意思決定者が含まれることが多いためです。
• 入門ページや概要ページ — 読者がまだ分野の背景知識を身につけていない、最初に目にするコンテンツです。
• 開発者以外を対象とする概念ページ — ソフトウェアエンジニア以外の読者に向けて、「何を」「なぜ」を説明するページです。
• 複数の製品にまたがるドキュメント（Zero Trust、SASE） — 複数の分野にまたがり、さまざまな読者を対象とします。

次のコンテンツでは使用を避けるか、優先度を下げてください：

• 開発者向けの API および SDK リファレンス（例：Workers、D1、R2、Durable Objects、KV） — 対象読者は、プログラミングの概念、データベース用語、API の慣例を理解していることが前提の開発者です。
• 開発者向けのコード中心のチュートリアル — 読者は自ら選んで読み、必要な前提知識もすでに備えています。
• 技術者のみを対象とした設定リファレンス — パラメーターの表、CLI リファレンス、スキーマのドキュメントなど、専門用語そのものがコンテンツを構成しているものです。

それ以外は、状況に応じて判断してください。「このページを読む一般的な読者は、すでにこれらの用語を知っているだろうか？」と考えてください。知っているなら、このスキルの効果はあまりありません。一方、次の点に当てはまる場合は、このスキルが大きく役立つ可能性があります。

• コンテンツが前提知識を求めすぎている
• 専門用語や略語の説明がない
• ドキュメントが「なぜ」を説明せずに「どのように」へ進んでしまう
• 読者が、いつ、どこで使えばよいのか理解に苦労している
• コンテンツのどこが分かりにくいのか、フィードバックがほしい

動作の仕組み

ワークフロー

1. ファイルパスを受け取る

/eli5 path/to/documentation.md

対応形式：.md、.mdx

2. コンテンツを読み取り、解析する

ファイルを読み取り、セクションを検出して構成を分析し、コンテンツの種類を特定します。

コンテンツの種類： 概要、概念、手順、リファレンス、チュートリアル

検出の手がかり：

• 概要： タイトルに製品名が含まれる、機能の一覧、利点の説明、「こんな用途に最適」などのセクション
• 概念： 「〜とは」「仕組み」「概念の説明」「重要である理由」
• 手順： 番号付きの手順、「前提条件」、見出しに含まれる動作を表す語、検証セクション
• リファレンス： 表、パラメーターの一覧、技術仕様、データ型
• チュートリアル： 「作成するもの」、段階的なコード例、「所要時間」

検出後、コンテンツの種類を確認します。種類によって適切な方針は異なります。

種類	方針
概要	問題 → 解決策 → 利点
概念	たとえ話 → 平易な説明 → 技術的な詳細
手順	背景 → 複数の経路（ダッシュボード + API）
リファレンス	2 段階の説明を用いたユースケース別の構成
チュートリアル	コードの説明を加えながら段階的に複雑さを高める

3. 拡充の制約を適用する

拡充する前に、次の制限を適用します。目標とする拡充量は 1.5～2 倍で、5～10 倍にはしません。既存の内容を置き換えるのではなく、背景情報を補って拡充します。

ドキュメントごとの追加量の上限：

• 問題や価値の説明： 本文中に 2～4 文（独立したセクションにはしない）
• ユースケースの例： 主要な概念ごとに 1～2 件、各 5～15 行
• 「なぜ」の補足： 機能を紹介するときに 1～2 文
• 専門用語の定義： 初出時に簡潔な説明を添える
• トラブルシューティング： 重要な問題を 1～2 件のみ
• テスト： 検証コマンドは最大 3～5 個

維持するもの： 既存のコンテンツ、構成、図、コード例、コンポーネントの使用方法、手順の流れをすべて維持します。

追加しないもの： 独立した概念の事前説明セクション、図への注釈、概念ごとの複数の例、包括的なテストやトラブルシューティングのセクション、ベストプラクティスのセクション、新しいダッシュボード/API の経路。

ダッシュボードと API の経路の検出： 経路が 1 つしかない場合は、提案の中でその点に触れ、執筆者に確認を促します。不足している経路は作成しません。

4. 簡潔にするセクションを確認する

次の選択肢を提示し、回答を待ちます：

• すべてのセクション — ドキュメント全体を処理します
• 特定のセクション — 行番号付きで検出されたセクションから選択します
• 最も複雑なセクションを自動検出 — 専門用語の密度と前提の頻度に基づいて優先順位を付けます
• カスタム範囲 — 行番号またはセクション名を指定します

5. 選択したセクションを分析する

各セクションについて、次の点を特定します。

• 専門用語 — 説明のない用語、定義されていない頭字語、複数の意味を持つ用語
• 前提 — 明示されていない前提条件、説明なしで言及されている概念、省略された基礎的な手順
• 不明瞭な論理 — 話の流れの問題、つながりの欠如、密度の高い段落、不明瞭な階層構造
• 文脈の不足 — 「なぜ」の説明がない、ユースケースがない、「いつ使うか」の説明がない

6. 用語を抽出する

用語集での定義や相互リンクが必要となる可能性のある用語を、重複を除いて一覧にまとめます。

• 未定義の技術用語 — 説明なしで使われている特定分野の用語
• 頭字語 — 初出時に正式名称が展開されていない頭字語
• 製品名／機能名 — ドキュメントへのリンクがない、特定の製品、サービス、機能への言及
• リンクがあると役立つ概念 — 別の場所に専用のドキュメントページがあるにもかかわらず、リンクされていない用語

各用語について、用語、出現箇所（行番号）、文脈内で定義されているかどうか、推奨する対応（用語集のツールチップを追加、相互リンクを追加、またはインライン定義を追加）を報告します。

GlossaryTooltip 品質ゲート： 用語に対して GlossaryTooltip を提案する前に、実際の用語集の定義（src/content/glossary/ 内）を必ず確認します。以下の基準で評価します。

• 定義は正確ですか？ 用語集の項目が曖昧、古い、または技術的に不正確な場合は、リンクするのではなく、改善が必要な項目として指摘します。質の悪いツールチップは、ツールチップがないよりも悪い結果になります。
• 定義は周囲の文と重複していませんか？ ツールチップが、適用先の文章とほぼ同じ内容を繰り返す場合は追加しません。新たな理解につながらず、見た目が煩雑になるためです。
• 定義だけで意味が通じますか？ 読者はツールチップを単独で読みます。用語集の項目が別の文脈でしか意味をなさない場合や、独自の専門用語を使っている場合は、リンクせずに指摘します。

用語集の項目がこれらの基準のいずれかを満たさない場合は、「用語集の項目の確認を依頼 — [reason]」を対応として用語インデックスに記載し、「用語集のツールチップを追加」とは記載しません。

用語インデックスは必ず出力に含めます。対応が必要な用語がない場合は、その旨を明記します。

7. 比較を作成する

以下を含む比較を作成します。

• 元の内容をそのまま保持
• 特定した問題を具体例とともに提示
• 簡略版に以下を含める：平易な言葉での要約、基礎から順を追った明確な説明、重要な理由、使う場面、技術分野に隣接する比喩、よくある落とし穴、関連概念

8. 報告する

改善内容の要約、元の文章がわかりにくかった理由、用語インデックス全体を報告します。

その後、直ちにステップ 9（敵対的レビュー）に進みます。レビューが完了するまで、次の手順についてユーザーに尋ねないでください。

9. 敵対的レビュー

ステップ 8 の報告を提示した後、次の手順についてユーザーに尋ねる前に、必ず新しいサブエージェント（Task ツール、subagent_type: "general"）を起動して敵対的レビューを実施します。現在のセッションでレビューを続けないでください。推論や ELI5 スキルの指示を知らない別のエージェントに出力を先入観なく評価させ、確証バイアスを排除することが目的です。この手順を省略しないでください。

サブエージェントに次のプロンプトを渡します（角括弧内の値を置き換えてください）。

---

敵対的レビュープロンプト開始

あなたは懐疑的なレビュアーです。あなたが最優先するのは、提案された変更に含まれるすべての事実に関する主張が正確で、引用可能な情報源によって裏付けられていることを検証することです。証明されるまでは、主張には根拠がないものとみなしてください。

あなたの役割は、文体の確認や書式設定ではありません。誤字や口調の問題ではなく、出典のない断定、誤解を招く含意、誤った仕組みを見つけてください。 元のファイル： [original file path] 変更案： [full ELI5 output — the simplified/enhanced content]

両方のファイルを注意深く読んでください。確認するのは変更案のみです。元のファイルは、すでに記載されていた内容と新たに加わった内容を区別するための基準です。

主張に該当するもの

変更案に含まれる、読者が妥当性を疑問に思う可能性のある記述です。

• 技術的な動作（「Workers は最大 128 MB のメモリをサポートします」）
• 比較（「代替手段の X より高速です」）
• 数値、上限、デフォルト値、クォータ
• 製品、プロトコル、規格の仕組みに関する記述
• 仕組みを簡略化した説明（簡略化の過程で追加された「どのように動作するか」の説明）
• 類推や比喩（対応関係についての主張。「X は Y のように動作する」という場合、対応する動作が実際の X の動作と一致している必要があります）
• 新たに加わった背景情報（元の内容になかった「理由」「どのような場合に使うか」「どのような問題を解決するか」といった説明）
• Cloudflare 製品の動作に関する主張

意見、ドキュメント内で定義された用語、手順（「Save を選択します」など）は主張に該当しません。

ELI5 で特に注意すべき点

ドキュメントを簡略化した際に、リスクが最も高い項目です。優先して確認してください。

1. 仕組みを簡略化した説明 — 元の内容になかった、仕組みを説明する記述が追加されていないかを確認します。最もリスクが高い項目です。もっともらしく聞こえても、誤った仕組みを説明する記述は、元の専門用語よりも有害です。このリポジトリ内の参照ドキュメントで、実際の仕組みを確認してください。

2. ニュアンスを誤解させる表現 — 完全な誤りではなくても、重要なニュアンスが省かれ、誤った理解につながる記述です。例：「Cloudflare は、AI クローラーにコンテンツへアクセスしないよう指示する robots.txt ファイルを生成します」という表現は誤解を招きます。robots.txt はパスごとに許可または禁止を指定する仕組みであり、一律にブロックするものではありません。この文では、クローラーがどこにアクセスできるか、またはできないかを指定する点が抜けています。簡略化によって重要な区別が失われていないかを確認し、該当する場合は指摘してください。

3. 新たな主張 — 簡略化の過程で追加された、説明、背景情報、位置づけなどです。新しい情報にはすべて出典が必要です。元の文書に「ゾーンはリゾルバーポリシーと組み合わせる」とだけ書かれていて、簡略版に「送信元 IP、ユーザー ID、ドメインに基づいて」と追加されている場合は、これらの条件がすべて実際にサポートされているか確認してください。

4. Cloudflare 固有の動作 — Cloudflare 製品にも業界標準の動作が当てはまると決めつけないでください。Cloudflare の実装は、一般的な方法と異なることがよくあります（例：従来のサーバーレスとは異なる Workers のリクエストライフサイクル、他の CDN とは異なる Cloudflare CDN のキャッシュロジック、一般的なヘルスチェックパターンとは異なる Cloudflare Tunnel のヘルスチェック動作）。Cloudflare 固有の主張はすべて、このリポジトリ内の src/content/docs/ にある実際のドキュメントで確認してください。

5. カテゴリ全体への過度な一般化 — 簡略版に「すべてのレコード」「IP アドレス」（単数形）、「すべてのリクエスト」といった表現がある場合、実際に例外なく当てはまるか確認してください。DNS レコードの種類（A、AAAA、CNAME、MX、TXT、NS）によって、プロキシのルールは異なります。Cloudflare は単一の IP アドレスではなく、複数のエニーキャスト IP アドレスを返します。プロトコルの動作、プランごとの機能、設定のデフォルト値は、レコードの種類、プラン、製品ティアによって異なることがよくあります。「すべて」「各」「任意」といった量化表現や、「the」のように単数を暗示する冠詞が正確か確認してください。A レコードについて正しい記述が、MX レコードには当てはまらない場合があります。また、Enterprise で利用できる機能が Free では利用できない場合もあります。

レビュープロセス

1. 抽出 — 提案された変更に含まれるすべての主張をリストアップします。元の文書からそのまま引き継がれた主張も含めてください。元の文書が誤っていれば、その簡略化も誤りを継承します。
2. 出典 — 各主張について、このリポジトリ内のドキュメント（src/content/docs/）を検索し、利用可能な最も強力な引用を見つけます：
   • このリポジトリ内の既存のドキュメントページ（推奨 — ファイルパスを使用）
   • 公開されている Cloudflare のブログ記事、変更履歴、またはアナウンス
   • RFC またはプロトコル仕様（Cloudflare 以外の主張の場合）
   • 主張が元のファイルにそのまま存在していた場合は、「元の文書に存在 — [ファイルパス]:[行番号]」として引用します
3. ニュアンスの評価 — 出典のある各主張について、提案された変更の文言が、出典の内容を正確に表しているか確認します。主張は出典があっても、限定条件を省略したり、条件を平坦化したり、出典が支持するよりも広い適用可能性を示唆したりしている場合は、誤解を招く可能性があります。
4. フラグ付け — 問題に重要度を付けます：
   • critical — 主張がページの目的の中心であり、誤っているか不正確な場合、読者を誤解させる可能性があります。
   • high — 主張は目立つが主要なポイントではない。不正確さは信頼を損ないます。
   • medium — 主張は周辺的だが、検証可能です。
   • low — 主張は軽微であるか、広く受け入れられている常識です。
5. 報告 — 調査結果をこの形式で提示します：

#	主張（正確なテキスト）	出典	ステータス
1	"Workers KV supports keys up to 512 bytes"	src/content/docs/kv/api/write-key-value-pairs.mdx	✅ sourced
2	"Latency is under 50 ms globally"	—	❌ unsourced (high)
3	"instructs crawlers to stay away from your content"	src/content/docs/bots/robots-txt.mdx — source says per-path allow/disallow, not blanket block	⚠️ misleading (critical)
4	"zones pair with resolver policies"	present in original — path/to/file.mdx:34	✅ sourced (original)

ルール

• コンテンツを修正または書き換えないでください。報告のみです。
• すべての問題には、曖昧な要約ではなく、主張の正確なテキストを含めてください。
• 出典が存在するが、主張が出典を誤って表現しているかニュアンスを失っている場合は、⚠️ misleading としてフラグを立て、出典の関連部分を引用してください。
• 十分な出典のある主張を認めてください — 表は失敗したものだけでなく、合格したものも示すべきです。
• このリポジトリまたは権威ある参照資料で出典が見つからない場合は、❌ unsourced としてフラグを立て、検索した内容を述べてください。

敵対的レビュープロンプトの終了

---

サブエージェントが調査結果を返したら、完全な主張テーブルをユーザーに提示します。❌ unsourced または ⚠️ misleading の調査結果がある場合は、それらを個別にリストアップし、推奨されるアクション（主張の削除、出典の追加、文言の調整）を提示します。

次に尋ねます：次に何をしますか？

1. フラグ付けされた問題を修正 — レビューで特定された出典のない主張や誤解を招く主張に対処します
2. 追加の改善を提案
3. 変更を含む PR を作成
4. 特定のセクションを改善
5. 元のファイルに変更を適用
6. 参考として保持

判断基準

用語を簡略化すべきですか？

• 置き換える、または説明する場合：分野固有の専門用語である、ほとんどの読者が知らない、同じように正確なより簡単な用語がある
• そのまま使い、定義する場合：業界標準の用語として読者が知っておくべきである、より簡単で正確な用語がない、その用語が頻繁に登場する

内容を追加すべきですか？

• 追加する場合：「なぜ」が抜けている、ユースケースがない、よくある誤解に触れていない
• 追加しない場合：元の説明ですでに明確である、追加しても価値がなく水増しになる、読者が文脈から推測できる

結果や影響を明記すべきですか？

• 対象読者が、述べられた原因から結果を推測できる場合は、明記しません。たとえば、ネットワーク分野の読者向けであれば、「ヘルスチェックをブロックする」に「つまり、Cloudflare がトンネルを正常でないと判断する可能性がある」という説明を加える必要はありません。分野に関する知識を信頼してください。
• 結果が自明でない、直感に反する、または対象読者が原因と結果を結び付けるための分野知識を本当に持ち合わせていない場合にのみ、明記します。

GlossaryTooltip を追加すべきですか？

• 用語集の定義が正確で、文中ですでに述べられている内容に情報を付け加え、追加の文脈なしで成立する場合は、追加します。
• 用語集の定義が曖昧、技術的に不正確、または周囲の文とほぼ同じ場合は、追加しません。代わりに、用語集の項目にレビューが必要であることを示します。
• 同じ段落内ですでに用語が明確に定義されている場合は、追加しません。

用語に類義語や別名を追加すべきですか？

• いいえ。 インラインでの定義は1つで十分です。定義によって動作を説明できている場合、「X とも呼ばれる」といった別名を重ねて記載しないでください。別名を列挙するのではなく、用語が何をするかで定義してください。

内容を削除すべきですか？

• めったにありません。 本当に冗長、または本題から外れている場合に限ります。注意事項、正確性に関する限定表現、セキュリティ上の警告は決して削除しないでください。

品質チェックリスト

最終確認の前に、以下を確認してください。

• 技術的な正確性が保たれている
• 専門用語を特定し、説明している
• 前提が明示されている
• 「なぜ」が「何を」「どのように」より先に説明されている
• ユースケースが現実的である
• 比喩に明確な1対1の対応関係があり、その限界も示されている
• 見下すような表現がない
• 拡張版が元の1.5～2倍の長さである（5～10倍ではない）
• 元の構成が保たれている（再構成していない）
• 概念ごとの例は最大1～2個である
• 図はそのままにしている
• すでに正しい文章はそのままにしている（語調を変えるために書き換えていない）
• 対象読者が推測できる結果の連鎖を記載していない
• 動作に基づく定義がある場合、類義語の説明を追加していない
• 修辞的な疑問文がない（例は例として記載している）
• 太字の書式が Cloudflare のスタイルガイドに従っている（クリック可能な UI 要素にのみ太字を使用し、説明文の散発的な強調には使用していない）
• すべての簡略化で、正しい仕組みを説明している
• 文体が既存のドキュメントの語調に合っている
• 敵対的レビューを完了している

避けるべきアンチパターン

改善に思えても、一貫してドキュメントの質を低下させるパターンがあります。AI が生成した編集内容に対する人間のレビューを通じて、これらが特定されました。

1. 「親しみやすさ」のために正確な文章を書き換える

元の文が事実として正確で、構成にも問題がない場合は、より温かみのある表現や簡単な表現に書き換えないでください。書き換えによって、機械的な誤りが生じるリスクがあります。具体的な問題（誤った事実、曖昧な指示対象、未定義の用語、論理の破綻）がある文だけを修正してください。

2. 読者が推測できる結果の連鎖を付け加える

読者が因果関係をすでに理解している場合、「X が起きると Y が起き、それによって Z が生じます」といった説明を詳しく書かないでください。たとえば、ネットワークエンジニアに対して、ヘルスチェックがブロックされるとトンネルが正常でない状態になると説明するのは、言うまでもないことです。「このページの読者なら、この結果をすでに理解しているだろうか？」と考えてください。そうであれば、省略してください。

3. 同義語の注釈（「X とも呼ばれます」）を付け加える

同じ文の中で概念がすでにその動作によって定義されている場合、「『デフォルト拒否』とも呼ばれます」などの別名を付け加えないでください。定義は一度で十分です。同義語を重ねても理解は深まらず、文章が冗長になります。

4. ドキュメントで修辞疑問文を使う

例のリストを、「VPN、NTP、またはデータベースサービスを実行していますか？」のような質問に変えないでください。例は例として示してください。ドキュメントは会話ではありません。

5. 相互に補完する機能を、互いに排他的であるかのように示す

両方の機能を一緒に使う場合に、一方がもう一方に取って代わるかのような印象を与える「ルールを一から記述する代わりに」などの表現を加えないでください。2 つの機能が互いを補完する場合は、対比するのではなく、相互参照してください。

6. もっともらしい単純化によって、実際とは異なる仕組みを説明する

システムの仕組みを簡略化する場合は、その説明が実際の仕組みを正しく表しているか確認してください。たとえば、「カスタムルールでマネージドルールのアクションを変更できます」という説明は、実際にはカスタムルールが評価順序によって優先されるのであれば、誤りです。もっともらしく聞こえても、仕組みを誤って説明する方が、元の専門用語を使うよりも悪い結果になります。

7. 読者がすでに理解している精度を、過剰に説明する

Wireshark 構文のフィルター式を書く読者に対して、== が「等しい」を意味すると説明しないでください。インラインの定義が必要なレベルは、想定上の初心者ではなく、そのページの実際の読者に合わせてください。

8. 形式的なドキュメントでカジュアルな表現を使う

Cloudflare のドキュメントでは、「let you」はカジュアルすぎます。「allow you to」を使うか、操作を直接記述してください。会話的な理想ではなく、既存のドキュメントの文体に合わせてください。

9. 関連していても異なる概念を、1 つの文で混同する

説明を簡潔にする際に、別々の概念を、それらが同じもの、または一方が他方を必要とするかのように、1 つの文にまとめないでください。たとえば、「CNAME フラット化はチェーンを解決して Cloudflare のエニーキャスト IP を返します」という表現は、CNAME フラット化（DNS 解決の動作）とプロキシ（トラフィックルーティングの判断）を混同しています。プロキシをオフにして CNAME フラット化を使うこともでき、その場合は Cloudflare の IP は返されません。同様に、「完全なセットアップとは、Cloudflare だけを DNS プロバイダーとして使うことです」という表現は、セットアップの種類（Cloudflare の権威ネームサーバーを使うこと）と排他性（他のプロバイダーが存在しないこと）を混同しています。それぞれの概念は、よく併用される場合でも、個別に説明してください。2 つの機能が相互に作用する場合は、まず別々に説明し、その後で関係性を説明してください。

例外的なケース

• 非常に長いドキュメント（1000 行超）： 優先するセクションを尋ね、分割して処理することを提案してください
• すでに明確な内容： 明確であることを伝え、軽微な改善だけを提案してください
• 高度に専門的な内容： 何よりも正確性を維持し、段階的に情報を示してください
• コード中心のドキュメント： コードが何を実現し、なぜそのような構成になっているのかを平易な言葉で説明してください
• 複数の読者層： 「開発者向け：」／「技術に詳しくない読者向け：」など、ラベル付きのセクションを使ってください

出力形式

以下のテンプレートに従って出力してください。すべてのセクションが必須です。

# ELI5 Simplified: [Original Doc Name]

**Original:** `[file path]`
**Sections simplified:** [count/list]

---

## Simplification Overview

**What was confusing:**
- [Issue pattern 1]
- [Issue pattern 2]

**Approach taken:**
- [Strategy 1]
- [Strategy 2]

---

## Section: [Original Heading]

### Original Content
[Exact text from source, preserved]

### Issues Identified
**Jargon:** [terms and why problematic]
**Assumptions:** [unstated prerequisites]
**Unclear Logic:** [structural issues]

### Simplified Version
**In Plain Language:** [One-sentence distillation]
**What It Is:** [2-3 paragraphs building from basics]
**Why It Matters:** [Benefits and value]
**When You'd Use This:** [Use cases with context]
**Think of It Like:** [Tech-adjacent metaphor]
**Where this metaphor breaks down:** [Limitations]
**Common Pitfalls:** [Misunderstanding → Correction]
**Related Concepts:** [Connections to familiar ideas]

---

[Repeat for each section]

---

## Terminology Index

| Term | Line | Defined? | Suggested Action |
| ---- | ---- | -------- | ---------------- |
| [term] | [line number] | Yes/No | Add glossary tooltip / Add cross-link to [page] / Add inline definition |

---

## Summary & Recommendations

**Key improvements made:** [list]
**Patterns noticed:** [meta-analysis]

## Suggestions for Enhancement

Line-numbered recommendations for further improvements:

| Line(s) | Current Approach | Suggested Enhancement | Why | Priority |
| ------- | ---------------- | --------------------- | --- | -------- |
| [lines] | [what exists] | [what to change] | [why it improves accessibility] | High/Medium/Low |

参考資料

• コンテンツタイプの判定基準： references/content-type-guide.md
• 変更前／変更後のパターンテンプレート： references/pattern-library.md
• 完全な例： EXAMPLES_REFERENCE.md