図解とイラスト:仕組みの解説方法
図解を用いて、明確なノード、ラベル付きの関係性、アクセシブルなテキスト代替、ポータブルな構文、機械による意味抽出を備えた仕組みを説明します。
図解は、名前の付いた部品がどのように接続し、何が部品間を移動し、それらの関係性がどのような結果を生み出すかを示します。読者が複数の関係性を同時に把握する必要がある場合に使用し、説明はテキストとしても利用可能にしておきます。
ページが検索可能になる仕組み: ソースページは抽出と正規化を経て、有用なパッセージが回答インデックスに到達します。
- ソースページ はHTML、見出し、画像、構造化フィールドを提供します。
- 抽出と正規化 は、テキスト、階層、エンティティ、関係性を保持しながら、表示上のノイズを除去します。
- 回答インデックス は、後続の質問にマッチング可能な検索可能なパッセージを保存します。
- 最初の矢印はページ表現を処理に運び、2つ目の矢印は正規化された検索可能なパッセージをインデックスに運びます。
図は流れを一目で可視化します。キャプションと番号付きの説明は、画像なしでも同じ意味を伝えます。この2チャンネルの契約が、説明用の図解を装飾的なアートワークと区別します。
この要素が重要な理由
散文は、読者に複数の要素を記憶させてからそれらの関係性を明かすことを強いる場合があります。図解はそのモデルを外部化します。ノードは部品を、コネクターは関係性を、境界は範囲を示します。これは順序だけでは不十分な場合に最も有用です。クローラーがページを取得し、パーサーがコンテンツを抽出し、インデックスがパッセージを保存することを一文で表現できます。図解は障害点、並行経路、フィードバックも示せます。これは正確な表現の必要性を減らすのではなく、再構成の労力を軽減します。
図解は散文よりも速く誤解を招く可能性もあります。ラベルのない矢印は因果関係、転送、順序、関連性を意味する可能性があり、ループは誤って自動フィードバックを暗示するかもしれません。すべての関係性には明示的で防御可能な意味が必要です。
機械抽出可能性とは、ソフトウェアが意味を失わずにコンテンツ単位を分離する能力です。検索システム、翻訳ツール、スクリーンリーダー、AI検索システムは、ピクセルから仕組みを再構築することが期待できません。光学文字認識はラベルを復元できるかもしれませんが、矢印や境界の意味は復元できません。タイトル、キャプション、構造化されたノードとコネクター、可視のテキスト代替により、コンピュータビジョンなしで仕組みを抽出可能にします。
共通の要素作成ルール が優先順位ルールを定めています。見出しや外観ではなく、パッセージが果たす役割によって要素を選択します。このページは、図解固有のフィールド、密度制限、テキスト代替要件、アクセシビリティ動作に関して優先されます。コンテンツの役割が仕組みを視覚的に説明することである場合は、汎用的な画像に即席のキャプションを付けるのではなく、図解要素を使用してください。
使用すべきタイミング
結論が少なくとも2つの関係性を同時に見ることに依存する場合に図解を使用します。強い使用例としては、分岐やフィードバックのあるプロセス、コンポーネントがデータを交換するシステム、以前の状態に戻るライフサイクル、介在因子のある因果連鎖、境界が重要な概念モデルなどがあります。読者は「このプロセスはどこで失敗する可能性があるか?」や「どのコンポーネントが正規化されたレコードを送信するか?」といった具体的な質問に図から答えられるべきです。
まず散文テストを適用してください。仕組みを3〜8文で書きます。相互参照、分岐、ループ、空間的関係がない場合、散文のほうが適切でしょう。正確なテキスト代替を組み立てるのに認知的コストがかかる場合に、図解はそのスペースに値します。
類似例との違いはよくあります:
- 実行可能なアクションにはステップリストを使用してください。矢印は前提条件、成功確認、復旧手順を代替できません。
- 選択肢間の繰り返し属性には比較表を使用してください。ラベルのない2軸の図は基準を隠します。
- 明示的な条件によって選択される経路には決定木を使用してください。一般的なフローは移動を説明しますが、決定を説明しません。
- 実際のインターフェースでコントロールを特定するには注釈付きスクリーンショットを使用してください。再描画はその証拠を失います。
- 量的な尺度が値をエンコードする場合はチャートを使用してください。装飾的な上昇矢印は測定された成長を暗示してはなりません。
- インライン画像は、仕組みではなく、オブジェクト、場所、または結果を描写するために使用してください。
図解を装飾や枠で囲んだ繰り返しとして使用しないでください。仮説的、論争的、条件的、または簡略化された関係性は、画像とテキストの両方で明示してください。
配置する場所
仕組みと質問を導入する段落の後に図解を配置します。その後に可視のテキスト代替、次に解釈、証拠、限界、またはアクションを続けます。
タイトル、画像、キャプション、凡例、テキスト代替は一つの図版領域にまとめてください。画像とその説明を分離するものがあってはなりません。長いテキスト代替はその直後に「テキストで」の下に配置します。
図解は、別の全幅の図解、チャート、動画、画像ギャラリー、密集した表、スクリーンショットのすぐ隣に置いてはいけません。次の密集したビジュアルの前に説明文を挿入してください。表セル、リスト項目、アコーディオン、コールアウト、クリッカブルカード、図版の中に配置しないでください。
手順については、最初のアクションの前に概要を配置し、結合されたステップの間に置かないでください。論証では、仕組みの主張の後、証拠の前に配置します。製品ページでは、機能説明の後、直接的な回答の上(単に技術的に見せるため)には決して配置しません。
構成要素
構成要素は意味を説明するものであり、スタイリングではありません。ボックスシャドウ、イラストスタイル、矢印の太さ、角丸、背景色はレンダラーまたはアートディレクションに属します。
- タイトル: 仕組みまたは質問を3〜10語で命名します。
- スコープ文: 図解に含まれるもの、除外されるもの、簡略化されるものを一文で定義します。
- ノード: 一つのコンポーネント、状態、アクター、入力、または結果を表します。
- ノードラベル: 説明のない省略形ではなく、具体的な名詞句を使用します。
- コネクター: 二つのノード間の宣言された一つの関係性を表します。
- コネクターラベル: 「イベントを送信する」や「パッセージを生成する」などの動詞または転送オブジェクトでその関係性を命名します。
- 方向マーカー: 配置だけに依存せずに、読み取りまたは転送の方向を示します。
- 境界: 所有権、フェーズ、環境、またはスコープを共有する項目をグループ化します。
- 凡例: 意味を変える線のパターン、記号、または色を定義します。
- キャプション: タイトルを繰り返すのではなく、主要な結論を述べます。
- 出典注記: モデルが調査、ポリシー、または独自システムから派生した場合に、証拠または所有者を特定します。
- テキスト代替: 意味を持つすべてのノード、コネクター、方向、条件、境界、例外を読み取り可能な順序で再述します。
デザイン例
すべてのバリエーションには、タイトル、キャプション、テキスト代替、明示的なコネクターの意味が必要です。質問に答える最もシンプルなバリエーションを選択してください。
線形プロセスフロー
仕組みが主に一方向に進む場合は、3〜7段階を使用します。段階間で何が移動するかをラベル付けし、矢印だけに依存しないでください。読者が段階を実行する必要がある場合は、概要を別のステップリストと組み合わせてください。
システムマップ
所有権、インターフェース、またはデータ交換が時間経過よりも重要な場合は、3〜9個のコンポーネントを使用します。境界は環境やチームを特定し、交差する線は再グループ化またはビューの分割の必要性を示します。
因果連鎖
原因、中間の仕組み、結果に対してこれを使用します。条件と不確実性を明示してください。矢印が相関を因果に変えてはなりません。散文と情報源はすべての因果的主張を裏付ける必要があります。
ライフサイクルループ
出力が後続の入力になる場合にのみループを使用してください。段階に番号を付け、再開トリガーを明示してください。装飾的な円は誤って繰り返しを暗示します。
詳細インセット付き概要
コンポーネントに詳細が必要だがシステムコンテキストに依存する場合に、一つのインセットを使用します。そのラベルを繰り返します。複数のインセットは通常、別の図解が必要です。
モバイルでは、線形図を読み順に積み重ねて表示します。システムマップは簡略化された概要と番号付きの関係性になる場合があります。意味を理解するために水平スクロールやズームを必要とさせないでください。
パラメーター
コンテンツモデルは仕組みを保存します。座標、色、フォントサイズ、アイコン選択、コネクターの経路設定、レスポンシブブレークポイントはレンダラーまたはソースアートワークに属します。
| 名前 | 型 | 必須 | 最小/最大 | デフォルト | ソース | |
|---|---|---|---|---|---|---|
title | プレーン文字列 | はい | 3〜10語;最大80文字 | なし | ディレクティブ本文の最初の見出し | |
variant | Enum | いいえ | process、system、causal、lifecycle、または overview-detail | process | 親属性 | |
src | ルート相対アセットパス | レンダリング画像に対してはい | 一つの既存のSVG、WebP、またはPNG | なし | 親属性または承認済みアセットレコード | |
alt | プレーン文字列 | はい | 40〜180文字目標;最大250文字 | なし | 親属性または承認済みアセットメタデータ | |
scope | プレーンテキスト | いいえ | 8〜30語;一文 | なし | タイトル後の最初の段落 | |
nodes | 順序付きコレクション | はい | 3〜9目標;最大12 | なし | 本文内の繰り返しアイテムディレクティブ | |
node.id | 安定した文字列 | はい | 2〜40文字;小文字ケバブケース | なし | アイテム属性 | |
node.label | プレーン文字列 | はい | 1〜6語;最大50文字 | なし | アイテム本文の最初の見出し | |
node.description | プレーンテキスト | はい | 5〜30語 | なし | 見出し後のアイテム本文 | |
connectors | 順序付きコレクション | はい | 2〜12 | なし | 本文内の繰り返し関係性ディレクティブ | |
connector.from | ノードID | はい | いずれかのノードと一致する必要あり | なし | 関係性属性 | |
connector.to | ノードID | はい | いずれかのノードと一致する必要あり | なし | 関係性属性 | |
connector.label | プレーン文字列 | はい | 1〜6語;最大50文字 | なし | 関係性属性 | |
connector.kind | Enum | いいえ | flow、cause、condition、feedback、または association | flow | 関係性属性 | |
caption | プレーン文字列 | はい | 8〜30語;最大200文字 | なし | ネストされたアイテム後の段落 | |
textEquivalent | リッチテキスト | はい | 50〜250語;必要な複雑性がある場合のみそれ以上 | なし | In text という見出しの最終本文セクション | |
source | プレーン文字列またはHTTPS URL | 条件付き | 出典注記1つ;最大200文字 | なし | 親属性または最終出典段落 |
source は、外部調査、標準、規制プロセス、または適応されたモデルに必須です。各ノードとコネクターはテキスト代替に出現する必要があります。散文は繰り返しを組み合わせても構いません。
構文とコード例
3つのマッピングは同じフィールドを保持します。アセットパスの例はプロダクション契約を説明するものです。それらのファイルが存在するまで、ライブ画像参照として出現してはなりません。
ポータブルMarkdownディレクティブ
:::diagram{variant=process src="/cdn-assets/seo-playbook/examples/content-pipeline.svg" alt="Three-stage flow from source pages through extraction and normalization to an answer index"}
## How a page becomes retrievable
The model covers content processing after a page has been fetched.
::item{id=source-pages}
### Source pages
Provide HTML, headings, images, and structured fields.
::
::item{id=extract-normalize}
### Extract and normalize
Preserve useful text, hierarchy, entities, and relationships.
::
::item{id=answer-index}
### Answer index
Stores passages that can be matched to a question.
::
::relationship{from=source-pages to=extract-normalize label="sends page representation" kind=flow}
::relationship{from=extract-normalize to=answer-index label="produces retrievable passages" kind=flow}
Normalized passages reach the answer index only after useful structure is preserved.
### In text
Source pages send their page representation to extraction and normalization. That stage preserves useful text, hierarchy, entities, and relationships, then produces retrievable passages for the answer index.
:::
最初の見出しは title にマッピングされ、次の段落は scope にマッピングされ、アイテムディレクティブはノードを定義し、関係性ディレクティブはコネクターを定義し、その後の段落は caption にマッピングされ、In text セクションは textEquivalent にマッピングされます。
Hugoショートコードマッピング
{{< diagram variant="process" src="/cdn-assets/seo-playbook/examples/content-pipeline.svg" alt="Three-stage flow from source pages through extraction and normalization to an answer index" >}}
## How a page becomes retrievable
{{< diagram-node id="source-pages" label="Source pages" >}}Provides page content.{{< /diagram-node >}}
{{< diagram-node id="extract-normalize" label="Extract and normalize" >}}Preserves useful structure.{{< /diagram-node >}}
{{< diagram-node id="answer-index" label="Answer index" >}}Stores passages.{{< /diagram-node >}}
{{< diagram-relationship from="source-pages" to="extract-normalize" label="sends page representation" kind="flow" >}}
{{< diagram-relationship from="extract-normalize" to="answer-index" label="produces retrievable passages" kind="flow" >}}
### In text
Source pages send content for extraction and normalization, which produces passages for the answer index.
{{< /diagram >}}
名前付きパラメーターのみが使用されます。これはポータブルなアダプター仕様であり、これらのショートコードが現在のテーマに登録されているという主張ではありません。承認されたレンダラーが存在するまで、確立された画像パイプラインを通じて意味論的な figure を公開し、そのテキスト代替を通常のページコンテンツ内に保持してください。
WordPressブロック
<!-- wp:amicited/diagram {"variant":"process","src":"/cdn-assets/seo-playbook/examples/content-pipeline.svg","alt":"Three-stage flow from source pages through extraction and normalization to an answer index"} -->
<figure>
<h2>How a page becomes retrievable</h2>
<img src="/cdn-assets/seo-playbook/examples/content-pipeline.svg"
alt="Three-stage flow from source pages through extraction and normalization to an answer index">
<figcaption>Normalized passages reach the answer index only after useful structure is preserved.</figcaption>
<div class="diagram-text-equivalent">
<h3>In text</h3>
<p>Source pages send content for extraction and normalization, which produces passages for the answer index.</p>
</div>
</figure>
<!-- /wp:amicited/diagram -->
ノードとコネクターをブロック属性として保存します。エクスポートはそれらとテキスト代替を保持する必要があります。フラット化された画像はポータブルなコンテンツではありません。
例
良い例:図と散文が同じ主張をする
良いバージョンは一つの質問に答えます:送信された質問がどのようにして裏付けのある回答になるか。4つの具体的なノードが明確な方向に従います。コネクターラベルはルーティングを検索と構成から区別します。破線のフィードバック経路は凡例でオプションの人間によるレビューとして定義されているため、自動ループを暗示しません。キャプションは結論を述べ、隣接するテキストはすべての段階と転送を命名します。
これにより、視覚的な読者は迅速なモデルを得ると同時に、テキストは同じ仕組みと条件を伝えます。機械は座標から推測することなく、名前付きの関係性を受け取ります。
悪い例:意味の宣言がない説明的な絡まり
悪いバージョンは「AI」を中心に置き、その周りをコンテンツ、データ、ユーザー、信頼、収益、成長といった漠然とした名詞で囲みます。ラベルのない矢印は双方向を指しますが、読者はそれらが因果関係、交換、順序、関連性のいずれを意味するのか判断できません。色は意味があるように見えますが、凡例はありません。成長の矢印はデータなしに改善を暗示します。小さなラベルはモバイルで読めなくなり、主張された仕組みを説明する散文もありません。
これを修正するには、一つの質問を選択し、無関係なノードを削除し、コネクターに名前を付け、原因と関連性を分離し、スコープ、キャプション、テキスト代替、出典を追加します。利点のみが残る場合は、リストを作成してください。
スキーママークアップとアクセシビリティ
図解に専用のSchema.orgタイプや独立したリッチリザルトの対象資格はありません。意味のある図解は、正確なURL、キャプション、寸法、作成者、クレジット、著作権、ライセンスデータを含む Article.image または ImageObject に設定される場合があります。メタデータや関係性ボキャブラリを発明しないでください。ノードとコネクターは可視のコンテンツのままです。
画像とキャプションには <figure> を使用してください。代替テキストは転記するのではなく、仕組みと結論を特定します。40〜180文字を目指し、「〜の図」のような表現は避けてください。例:「ソースページから抽出、正規化を経て回答インデックスに至る3段階のフロー」
可視のテキスト代替には、すべての意味のあるノード、コネクター、条件、フィードバックトリガー、境界、凡例、例外を含めます。ARIA、ホバーテキスト、メタデータ、閉じたアコーディオンに隠さないでください。
色、アイコン、パターン、形状、位置をテキストラベルと組み合わせて使用してください。コントラスト、可視の矢印、テキスト代替と一致する読み順を維持してください。実際のSVGテキストは有用ですが、可視の散文を代替しません。
320 CSSピクセルでは、同じデータから積み重ね、簡略化、またはモバイルビューをレンダリングしてください。ノードを削除したり、コネクターを切り取ったり、読み順を変更したりしないでください。近くのテキストはズームなしですべての本質的な意味を保持する必要があります。
作成ルール
最初にテキストを作成して検証し、それからテキストに含まれる関係性のみを描画してください。これにより、視覚的な仕上げが新しい主張を導入することを防ぎます。
- 図解に一つの質問または仕組みを与えてください。アーキテクチャ、ワークフロー、利点、ロードマップを一つのキャンバスに組み合わせないでください。
- 3〜9個の主要ノードを使用し、最大12個までとします。過負荷のモデルは概要図と詳細図に分割してください。
- ノードには1〜6語の具体的な単語でラベル付けします。ページテキストで初出時に略語を定義し、読者が解釈できない内部チーム名は避けてください。
- 意味を持つすべてのコネクターに、1〜6語の動詞句または転送オブジェクトでラベル付けします。「統合」よりも「イベントを送信する」の方が明確です。
- キャプションは8〜30語に抑え、読者が保持すべき結論または関係性を述べてください。
- スコープ文は一文に抑えてください。省略が解釈を変える可能性がある場合は、除外事項や簡略化を明記してください。
- テキスト代替は、正確さにより多くが必要でない限り、50〜250語に抑えてください。
- 説明的で中立的なトーンを使用してください。システムが行うことと、行う可能性があること、行うべきこと、仮説されていることを区別してください。
- 「〜する可能性がある」「条件付き」「提案された」などの言葉で不確実性を明示し、破線や点線の経路を凡例で定義してください。
- 段落、引用、生のURL、宣伝スローガン、精密な証拠、完全な指示をアートワーク内に決して配置しないでください。選択可能なページテキストに配置してください。
- ラベルのないアイコン、第二の手がかりのない色、宣言された意味のない矢印を決して使用しないでください。
- 証拠と凡例がそのエンコーディングをサポートしない限り、サイズや方向を通じて規模、数量、因果の強さ、確実性、測定された成長を決して暗示しないでください。
- 存在しないアセットパスを公開しないでください。保留中のアートワークは
screenshotsPending = trueのキャプチャコメントとして保持してください。
これを使用する投稿タイプ
postTypes フロントマターが登録された結合です。リストされた各投稿タイプは同じ図解契約を使用しますが、異なる閾値で使用します。
| 投稿タイプ | 要件 | 推奨位置 | 理由 |
|---|---|---|---|
| アルティメットガイド | オプションの概要 | ガイドが複雑なシステムを定義した後、詳細セクションの前 | 広範なガイドは一つの安定したメンタルモデルの恩恵を受けますが、すべてのサブセクションに図解があると視覚的疲労を生みます。 |
| ハウツーガイド | オプションの方向付け | 分岐、依存関係、フィードバックが重要な場合、最初のステップの前 | 図解は全体的な仕組みを説明します。ステップリストは依然としてすべての実行可能な指示と復旧経路を保持します。 |
| フレームワーク記事 | 通常推奨 | フレームワークの定義とスコープの後 | 再利用可能な手法は多くの場合、段階間の関係性に依存しますが、散文は各段階と制限を定義する必要があります。 |
| 独自調査 | オプションの説明モデル | 方法論の後、または仕組みを解釈する必要がある場合の調査結果の前 | 図解はデザインや裏付けのある因果提案を明確にできますが、データ、方法、表明された不確実性を代替できません。 |
| 機能ページ | オプションの仕組みの証明 | 機能と成果が述べられた後 | システムフローは機能の動作を示せますが、機密アーキテクチャを露出させたり、裏付けのない自動化の主張をしたりしてはいけません。 |
QAチェックリスト
- 目的: 一つの仕組みまたはフローが散文だけよりも視覚的に把握しやすいこと。
- テキスト優先: レビューされた説明がアートワークに先行し、裏付けのない関係性は追加されていないこと。
- スコープ: タイトルとスコープが境界、簡略化、除外事項を明確にしていること。
- ノード: 通常3〜9個で、それぞれ具体的かつ必要であること。
- コネクター: それぞれに方向とラベルがあり、スタイルと色に凡例があること。
- 主張: 因果関係、自動化、規模、強さ、確実性、成長は、証拠がそれらを裏付ける場合にのみ示されていること。
- テキスト代替: 可視テキストにすべてのノード、関係性、条件、境界、凡例、例外が含まれていること。
- キャプション: 8〜30語で結論を述べていること。
- アクセシビリティ: 色が唯一の手がかりではなく、コントラスト、矢印、代替テキスト、読み順が機能していること。
- モバイル: 320 CSSピクセルで、ページレベルのスクロールや必須のズームなしで意味が維持されること。
- 配置: 導入コンテキストが図解に先行し、キャプションとテキスト代替が付随し、競合する密集したビジュアルが隣にないこと。
- 出典: 調査、標準、規制プロセス、適応モデルに正確な可視の出典または所有権注記があること。
- 移植性: すべてのマッピングがタイトル、ノード、コネクター、キャプション、テキスト代替を保持していること。
- アセットの安全性: ライブパスが公開される前にファイルが存在し、権利が文書化され、保留中のアートワークは
SCREENSHOTコメントのままであること。 - 優先順位: 目的がこの要素と一致するためブロックが図解として型付けされており、汎用的な画像がたまたま似ていたからではないこと。
FAQ
アカデミーテンプレートは、このページの [[faq]] フロントマターに保存された5つのレビュー済み質問をレンダリングします。これらは図解を使用する閾値、必須のテキスト代替、代替テキストの範囲、構造化データ、ノード制限をカバーしています。
このセクションの他のチュートリアル
実践する準備はできましたか?
無料チェック · 7日間お試し · クレジットカード不要