explain

解説ドキュメントの規則

用語の扱い

• ドキュメントの冒頭に、| 用語 | 説明 | 形式の表で用語リストを記載します。本文で使用する専門用語はすべて、初出時にこのリストで定義します。
• 用語リストの項目では、その用語が何であるかを1〜2文で定義します。機能や動作に関する詳細は用語リストではなく、本文に記載します。
• 業界標準の製品名やインフラストラクチャの構成要素など、広く知られている固有名詞もここで定義します。読者がそれらを知らないものとして扱います。
• 複合語を定義するときは、構成する単語も定義します。複合語が3つの単語で構成される場合は、それぞれの単語に独立した項目を設けます。読者が互いの意味を推測できると期待してはいけません。

図の規則

• 図にはMermaidを使用します。ASCIIアートは使用しません。
• すべてのノードラベルは、用語リストに記載されている用語にします。図の中に新しい用語を導入しないでください。
• Mermaidのノード内に<br/>を入れないでください。多くのレンダラーではHTMLタグがそのまま表示されます。改行が必要な場合は、/で区切るか、1行に収まるようにテキストを短くします。
• ノードが4つ以上ある図や、ラベルが長い図には、graph TD（上から下）を使用します。graph LR（左から右）では、ラベルの長い図が読みにくい横長の列になります。

説明の粒度

• 曖昧な表現で詳細をごまかさないでください。主語、目的語、動詞を明確にします。
• 「AはBを使ってXを行う」のような表現では、Aが何であり、Xを行うためになぜAが必要なのかを明示します。
• 「受け取る」や「渡す」のような曖昧な動詞は避けてください。状態を実現するために誰が何をするのかを具体的に記述します（例：「アドレスを受け取る」→「プラットフォームがアドレスを自動的に割り当てる」）。
• 手順間のつながりを読者に推測させないでください。各手順が次の手順につながる因果関係を明示します。
• まず仕組みの一般形を説明し、その後、「Xの場合は、…」のように、具体的な名前の付いた事例に結び付けます。説明全体を単一の固有名詞の例に基づいて構成しないでください。

構成

1. 用語リスト
2. 背景（この仕組みが必要な理由、または解決する課題）
3. 仕組み（動作の説明。図を含む）
4. 具体的な手順（コマンド、手順、または実例）
5. 現状（継続中のシステムの現在の状況）