ステップリスト：手順の書き方

ステップリストは、既知の開始状態から検証可能な結果へ読者を導く順序付けられた手順です。番号には意味があります。ステップ2はステップ1に依存し、順序を変更すると作業の無駄、エラーの発生、または完了の妨げになる可能性があります。各ステップは、どこをクリックするかだけでなく、理由、アクション、成功状態、そして先に進むために必要な回復経路を説明します。

1. 順序が結果を変えることを確認する。 理由： 番号は依存関係を約束するため、誤った順序は読者や機械を誤解させます。 アクション： 2つのアクションを入れ替えてみてください。 成功： 少なくとも1つの入れ替えで結果が変わる、妨げられる、または無効になること。 回復： どのアクションでも問題なく動作する場合は、シーケンスを箇条書きまたはチェックリストに置き換えてください。

2. 観察可能な成功状態を書く。 理由： 読者は次に進む前にアクションが機能したという証拠を必要とします。 アクション： 見える、測定できる、ダウンロードできる、またはテストできるものを指定します。 成功： 下書きを知らない人が合格か不合格かを判断できること。 回復： 成功が判断のみに依存する場合は、具体的な基準または例を追加してください。

3. 失敗時の回復経路を追加する。 理由： 完全な実行を前提とした手順は、最初のエラーで読者を見捨てることになります。 アクション： 最も安全な修正方法、再試行方法、またはエスカレーション方法を明記します。 成功： 読者が推測することなく期待される状態に戻れること。 回復： 安全な回復方法がない場合は、アクションの前に警告し、誰が支援できるかを明示してください。

この実例は意図的に簡潔ですが、それでもステップ契約を満たしています。このページの残りでは、公開システム全体でこの要素を一貫して生成する方法を定義します。

この要素が重要な理由

手順を読むユーザーは、今何をすべきか、なぜそれが重要なのか、うまくいったかどうか、そして現実が想定と異なる場合にどうすべきかを知りたいと考えています。「保存をクリック」では最初の質問にしか答えられず、読者は何を確認すべきか、失敗が何を意味するかを推測するしかありません。

ステップリストは、繰り返しの判断リズムを作り出すことでその不確実性を低減します。命令形のタイトルは「接続」「確認」「公開」などのコマンドで始まります。理由は読者が労力を費やす前に関連性を確立します。アクションは実行に十分な詳細を提供します。成功状態は完了を観察可能にします。回復経路は失敗したアクションが行き止まりになるのを防ぎます。これがステップ契約であり、表示される各ステップは5つの部分すべてを満たさなければなりません。

この規則性は機械抽出可能性も向上させます。つまり、検索エンジン、AIエージェント、変換システムが指示をその役割を失うことなく分離できる能力です。安定した順序、説明的なタイトル、明示的な結果、範囲が限定された回復ガイダンスにより、機械は指示とその検証を区別できます。

番号自体がその意味を生み出すわけではありません。番号はコンテンツがすでに持っている意味を明らかにします。順序が本物の場合、番号はスキャンする読者に依存関係を伝え、構造化データの位置を保持します。順序が人為的な場合、番号は誤った約束を生み出します。

使用するタイミング

読者が順番に手順を実行する必要があり、各完了アクションが次のアクションの開始状態を確立する場合にステップリストを使用します。適切な使用例には、アカウント設定、ソフトウェア設定、繰り返し可能な分析ワークフロー、移行、修復シーケンス、依存関係のある公開プロセスなどが含まれます。

番号が権威的に見えるというだけの理由でステップリストを使用してはいけません。項目がオプション、例、材料、特性の場合は箇条書きを使用します。項目が任意の順序で検証できる独立したゲートの場合はチェックリストを使用します。読者が1つの結果に向かって進むのではなく選択肢を比較している場合は比較表を使用します。明白なアクションが1つか2つだけで、それぞれに独立した検証が必要ない場合は通常のプローズを使用します。

類似ケースが誤用の大部分を占めます：

• 「ランディングページを改善する10の方法」は、項目4が項目3の出力を必要としない限り、リスト記事です。
• 「公開前にタイトル、リンク、画像、作成者を確認する」はチェックリストです。順序が有効性を左右しないからです。
• 「プランを選択し、支払い詳細を入力し、購入を確認する」はステップリストです。各状態が次の状態を解放するからです。
• 「インポートに失敗した場合は、A、B、Cを試す」はトラブルシューティングガイダンスです。診断ブランチを定義された順序で試す必要がある場合にのみステップリストになります。
• 時系列は時間の経過とともに何が起こったかを説明します。読者がそのアクションを実行して記載された結果に到達できる場合を除き、手順ではありません。

意図が不明な場合はスワップテストを実行します。隣接する2つの項目を入れ替えて、手順が正しいままかどうかを確認してください。すべての入れ替えが無害であれば、順序は装飾的であり、この要素は適切ではありません。

配置する場所

ステップリストは、読者が結果を理解し、開始に必要な入力を準備できた後に配置します。その直上に前提条件ブロックを置き、開始状態、権限、ファイルやデータ、ツール、消耗品、時間、取り返しのつかないリスクを明記します。該当しないフィールドは省略し、必須入力をステップ4の中に隠してはいけません。

最終ステップの直下に結果ブロックを配置します。これは完了状態、読者が現在持つべき成果物または状態、および次に取るべき適切なアクションを明記します。これにより、さらなる番号がないことをもって成功と推測させずに手順を終了します。

この要素は、ハウツーページのメイン手順として1回、または長いチュートリアルで明確に名前付けられたフェーズとして複数回出現することがあります。フェーズ見出しは中間結果を説明し、番号はフェーズ間で継続するか、「フェーズ2、ステップ1」などの明示的な識別子を使用する必要があります。黙って1から再開してはいけません。

ステップリストは、異なる目的を持つ別の番号付きリストのすぐ隣に配置してはいけません。見出しまたはトランジションで境界を説明する必要があります。タスクの実行安全性を変える警告の前に開始してはいけません。ステップ間に一般的なコールトゥアクションを配置したり、アクションとその成功状態の間に参照を挿入したり、手順の途中に関連のない比較表を挿入したりしてはいけません。サポート資料は、そのアクションの完了に役立つ場合のみ該当ステップ内に配置し、それ以外の場合は完全なシーケンスの前または後に配置します。

構造

構造には3つのコレクションレベルの領域と5つの繰り返しステップレベルの領域があります：

1. 前提条件： 開始状態、アクセス権限、ツール、消耗品、時間、重要な制約。
2. シーケンスラベル： 手順とその結果を説明する説明的な見出し。
3. ステップ番号： タイトルに入力するのではなく、順序付きリストレンダラーによって生成される意味的な位置。
4. 命令形タイトル： スキャンする人がタスクを予測できる1つのアクション主導のフレーズ。
5. 理由： 今このステップを実行する正当性となる依存関係、リスク、または利点。
6. アクション： 関連する場所、入力、選択肢を含む正確な指示。
7. 成功と回復： 観察可能な完了状態と、その状態が現れない場合の次の安全な対応。
8. 結果： 最終状態と、読者がそれを活用してできること。

凡例はラベルがコンテンツでありアートワークではないため、ページに残します。デザインが変更されても、同じ意味領域がピクセルを編集しなくても識別可能でなければなりません。

デザイン例

デフォルトバリアントはほとんどの編集手順に対応します。コンパクトバリアントはスペースを削減できますが、契約フィールドを削除することはできません。スクリーンショット補助バリアントは、曖昧なインターフェースステップと1つのフォーカスされた画像を組み合わせます。フェーズバリアントは、長い手順を中間結果でグループ化しながら、一貫した全体シーケンスを保持します。

理由や回復経路を削除する「ミニマル」バリアントは許可されません。表現は空白を圧縮することはできても、編集契約を圧縮することはできません。

パラメータ

これらのパラメータは、ソースコンテンツを定義するものであり、オプションの視覚的装飾ではありません。Source列は、値が属性、ネストされたアイテム本文、またはその最初の見出しのいずれから来るかを示します。

通常のステップあたりの長さは、5つの契約フィールド全体で50〜140語です。短いステップは推論や検証を省略する傾向があり、長いステップは通常複数のアクションを隠しています。

構文とコード例

正規の構造は要素作成ルール に従います。親がコレクション設定を保持し、各繰り返しステップはネストされた項目です。以下の例は、マッピングの明確さのために同じ2ステップの断片をエンコードしています。公開可能な手順は通常、少なくとも3つのステップを含むべきです。

ポータブルMarkdownディレクティブ

:::step-list{totalTime="PT15M" variant=default}
## データソースを接続して確認する

前提条件：管理者アクセス権とプロパティ識別子。

::item
### プロパティ接続画面を開く

**理由：** 正しいプロパティから開始することで、データが誤ったアカウントに紐づくのを防ぎます。

**アクション：** 設定を開き、データソースを選択し、前提条件ブロックに表示されたプロパティ識別子を選択します。

**成功：** 選択したプロパティ名が接続サマリーに表示されます。

**回復：** 表示されない場合は、アカウントアクセスを確認し、プロパティリストをリロードしてください。
::
::item
### 接続テストを実行する

**理由：** テストが成功すれば、最初のインポートの前に認証情報と権限が機能することが証明されます。

**アクション：** 接続テストを選択し、ステータス応答を待ちます。

**成功：** インターフェースに現在のタイムスタンプとともに「接続済み」と表示されます。

**回復：** アカウントを再認証します。それでもテストが失敗する場合は、サポート用にエラーコードをコピーしてください。
::

結果：ソースが接続され、最初のインポートの準備ができました。
:::

Hugoショートコードマッピング

{{< step-list totalTime="PT15M" variant="default" >}}
前提条件：管理者アクセス権とプロパティ識別子。
{{< step title="Open the property connection screen" >}}
**理由：** 正しいプロパティから開始することで、データが誤ったアカウントに紐づくのを防ぎます。
**アクション：** 設定を開き、データソースを選択し、プロパティ識別子を選択します。
**成功：** 選択したプロパティが接続サマリーに表示されます。
**回復：** アクセスを確認し、プロパティリストをリロードしてください。
{{< /step >}}
{{< step title="Run the connection test" >}}...{{< /step >}}
結果：ソースが接続され、最初のインポートの準備ができました。
{{< /step-list >}}

この表記はアダプター契約を定義します。作成者は、利用可能な場合はサイトの登録済みレンダラーを使用する必要があります。このページは実例をセマンティックMarkdownとしてレンダリングし、新しいHugoショートコードを導入しません。

WordPressブロックマッピング

<!-- wp:amicited/step-list {"totalTime":"PT15M","variant":"default"} -->
<!-- wp:amicited/step {"title":"Open the property connection screen"} -->
<p><strong>理由：</strong> 正しいプロパティから開始することで、データが誤ったアカウントに紐づくのを防ぎます。</p>
<p><strong>アクション：</strong> 設定を開き、データソースを選択し、プロパティ識別子を選択します。</p>
<p><strong>成功：</strong> 選択したプロパティが接続サマリーに表示されます。</p>
<p><strong>回復：</strong> アクセスを確認し、プロパティリストをリロードしてください。</p>
<!-- /wp:amicited/step -->
<!-- /wp:amicited/step-list -->

プラットフォームの出力は視覚的に異なる場合がありますが、すべてのフィールドとその意味は維持されなければなりません。

例

良例：データ収集前にドメインを確認する

1. 検証レコードを追加する。 理由： レコードはアカウント認証情報を公開せずにドメインの管理権限を証明します。 アクション： 正確なTXT値をドメインのDNS設定にコピーし、ルートホストで保存します。 成功： プロバイダーが余分な引用符なしでDNSリストにレコードを表示します。 回復： 表示されない場合は、ホストフィールドがプロバイダー要求のルート記号を使用しているか確認し、DNS伝播を待ってから再試行してください。
2. プロダクトで所有権を確認する。 理由： 確認により、未検証のプロパティに対して収集が開始されるのを防ぎます。 アクション： 検証画面に戻り、レコードが公開解決可能になったら「確認」を選択します。 成功： ドメインステータスが「確認済み」に変わり、確認時間が表示されます。 回復： 確認が失敗した場合は、TXTレコードを照会し、文字ごとに比較し、DNSエントリを修正してから再試行してください。
3. 最初の収集を開始する。 理由： 確認済みでも未使用のプロパティはベースラインを生成しません。 アクション： 「収集開始」を選択し、プロジェクトが文書化された除外を必要としない限りデフォルトのスコープを維持します。 成功： キューに入れられたジョブが確認済みドメインと現在時刻とともに表示されます。 回復： ジョブが表示されない場合は、1回更新し、重複を作成せずにサポート用にドメイン、時刻、エラーメッセージを記録してください。

これが機能する理由は、順序が現実的で、タイトルが命令形で、チェックポイントが可視的で、失敗時のガイダンスが安全だからです。

悪例：記事を改善する

1. 内部リンクを追加する。
2. 序文を書き直す。
3. スペルを確認する。
4. 例を追加する。

このリストが悪い理由は2つあります。第一に、順序が恣意的です。スペルチェックはリンクの前でも可能で、例は序文の前でも追加できます。チェックリストであるべきです。第二に、各項目が単にアクティビティを挙げているだけです。なぜそれが属するのか、どこまで行うのか、何が成功なのか、確認が失敗した場合にどうするのかを説明していません。動詞を増やしても意味のミスマッチは修正できません。

粒度とネスト

1つのステップは1つの意味のある状態変更を生み出すべきです。1つの中断のないインタラクションを形成し、1つの成功シグナルを共有する場合、複数のクリックがそのステップに属することができます。たとえば、「CSVを選択し、UTF-8を選択し、ファイルをエクスポートする」は、観察可能な結果がダウンロードされたCSVであれば1つのステップです。中間結果に検証が必要な場合、異なる権限が必要な場合、材料となる待機時間がある場合、判断の分岐がある場合、または異なる回復経路が必要な場合は分割します。

文章テストを使用します。タイトルに2つの結果を結合するために「および」が必要な場合は、おそらく2つのステップが含まれています。失敗テストも使用します。前半が成功し後半が失敗する可能性があり、それぞれに異なる回復が必要な場合は分割します。

ネストは1階層、3つの短いサブステップに制限されます。サブステップは厳密に境界づけられたアクションを明確にします。手順の中に手順を作成するものではありません。別個の前提条件、3つ以上のアクション、複数のスクリーンショット、複数の失敗分岐、または他のページが独立して使用できる結果がある場合は、シーケンスを独自のページに昇格させます。そのサブ手順にリンクし、親ステップはいつ実行するかとその結果を確認する方法に焦点を当てます。

ステップごとのスクリーンショットポリシー

スクリーンショットは、言葉だけではコントロールや状態を確実に識別できない場合に価値を発揮します。ラベルが重複している場合、コントロールがメニューに隠れている場合、空間的な位置が重要な場合、インターフェースが馴染みのないアイコンを使用している場合、または成功状態が視覚的に曖昧な場合に使用します。タスク領域にクロップし、方向確認のための十分なコンテキストを保持し、代替テキストと近くのプローズで関連状態を説明します。

インターフェースラベルが一意で成功状態を正確に記述できる場合は、スクリーンショットを省略します。また、明確にラベル付けされた保存ボタンの選択、テキストとして既に表示されているターミナルコマンド、1つの意味のある選択に至るまでに通過するすべての画面など、ルーチンアクションのスクリーンショットも省略します。14の明白なステップに14のスクリーンショットがあると、手順が遅くて脆いスライドショーになり、インターフェース変更のメンテナンスコストが高くなります。

ステップあたりのスクリーンショットは1つまでです。ステップに前、中、後の画像が必要な場合、その粒度はおそらく広すぎます。アセットが存在するまで参照してはいけません。また、重要な指示を画像内だけに配置してはいけません。

スキーママークアップとアクセシビリティ

スキーママークアップ は、表示コンテンツの意味と関係を説明する機械可読コードです。ページが完全な手順を実際に教えている場合、ステップリストはJSON-LD で表現されたSchema.orgのHowToオブジェクトを供給できます。マッピングは直接的です：

マークアップは表示手順を正確に反映しなければなりません。非表示のステップを追加したり、2つの表示ステップを1つのスキーマ項目に結合したり、順序を変更したり、構造化バージョンを短くするために回復ガイダンスを省略したりしてはいけません。ページに番号付きリストが含まれているという理由だけでHowToを適用してはいけません。ページは完了可能なプロセスを説明している必要があります。

アクセシビリティは、ステップごとに1つの<li>を含む<ol>から始まります。番号と順序は支援技術で利用可能でなければなりません。番号を見出しに入力してはいけません。コピーされたテキスト、CSSカウンター、スクリーンリーダー出力が一致しない可能性があるためです。論理的な見出しレベル、安定したフラグメント識別子、説明的なスクリーンショット代替テキスト、色だけに頼らない成功と回復のテキストラベルを使用します。

変更を通知せずにステップ順序を変更するインタラクティブコントロールは避けます。ステップが折りたたまれる場合、コントロールにはアクセシブルな名前と展開状態が必要であり、キーボードフォーカスは予測可能でなければなりません。印刷可能出力とJavaScriptなしの出力は、手順全体を保持する必要があります。

作成ルール

3〜10ステップを書き、各ステップは通常50〜140語とします。各2〜8語のタイトルは命令形の動詞で始め、1つの結果を説明します。読者がスキップ、並べ替え、誤解する可能性のあるアクションの前に理由を説明します。落ち着いた直接的な言葉を使用します。

すべてのステップは5つの契約フィールドを含まなければなりません。ただし、レンダリングデザインは、タイポグラフィがアクセシブルに伝える場合に、かさばるラベルを繰り返す必要はありません。成功状態は観察可能でなければなりません。ステータスが変わる、ファイルが存在する、値が指定された範囲内にある、メールが届く、テストに合格するなどです。「すべて問題なく見える」は観察可能ではありません。回復は安全で、具体的で、適切でなければなりません。再試行と元に戻しを区別し、読者が状態を修復できない場合のエスカレーションを特定します。

関連のない背景情報、プロモーションのコールトゥアクション、お客様の声、2つ目の独立した手順、複数の判断分岐をステップ内に配置してはいけません。背景はリストの上に、プロモーションは結果の下に、実質的な分岐はトラブルシューティングセクションに移動します。失敗する可能性のあるアクションに「単に」「明らかに」「ただ」を使用してはいけません。製品が実際に提供しない画面、ラベル、時間、結果を約束してはいけません。

使用する投稿タイプ

postTypesフロントマターは、カタログと検証用途のためにこれらの関係を記録します。登録されたプレイブック投稿タイプのページのみがリンクを受け取ります。他の行は、ルートを考案せずにサポートされている編集パターンを説明します。

QAチェックリスト

公開前に、以下すべてを確認してください：

• 隣接するステップを入れ替えると、結果が変わる、妨げられる、または無効になること。
• 前提条件が必要なすべての開始状態、権限、ツール、消耗品、リスクを明記していること。
• 手順に3〜10ステップが含まれているか、正当な例外が文書化されていること。
• すべてのステップに命令形タイトル、理由、アクション、観察可能な成功状態、回復経路があること。
• 各ステップが1つの意味のある状態変更を生成し、1階層のネスト内に収まっていること。
• 独自の前提条件または結果を持つサブ手順は分離されていること。
• スクリーンショットはインターフェースまたは状態が曖昧な場合のみに表示され、ステップあたり1つ以下であること。
• 結果ブロックが現在存在するものと読者が次にできることを明記していること。
• 順序付きリストのセマンティクス、見出し順序、フラグメントリンク、代替テキストが色やスクリプトなしで機能すること。
• HowToプロパティ（存在する場合）が表示ステップ、順序、期間、消耗品、ツール、テキスト、画像と正確に一致していること。
• ポータブルMarkdown、Hugo、WordPressのマッピングが同じフィールドと意味を保持していること。
• リンクとメタデータがより広範な公開前QAチェックリスト に合格していること。

FAQ

ステップリストにはいくつのステップを含めるべきですか？ 3〜10を使用します。1つまたは2つのアクションはプローズで記述し、10を超える場合はグループ化または分割します。

番号付きリストが真のステップリストとなる条件は？ 順序が結果に影響を与え、各ステップが5つの部分からなる契約を満たさなければなりません。

すべてのステップにスクリーンショットが必要ですか？ いいえ。言葉だけではインターフェース、場所、状態を確実に識別できない場合にのみ追加します。

ステップにサブステップを含めることはできますか？ はい、1階層のみです。独自の前提条件、結果、または3つ以上のアクションを持つシーケンスは分離します。

いつチェックリストにすべきですか？ 項目を任意の順序で完了できる場合、または独立した検証ゲートである場合です。

ステップリストは、プレゼンテーションだけでなく動作も伴うSEOコンテンツ要素 の1つです。その品質は、読者が失敗から回復し、約束された結果に到達できる場合に証明されます。番号が単にきれいに見えるからではありません。