チェックリスト：作成ルール、配置、および例

チェックリストとは、読者が未完了または完了としてマークできる、有限の独立したアクションまたは検証ゲートの集合です。そのチェック可能な状態は意味の一部です。必要な項目をすべて完了することで、指定されたタスク、レビュー、または準備状態が完了したことを証明できるはずです。

このレンダリング例は、範囲が限定されており、4つの簡潔なアクション、表示された未チェック状態、および1つの完了条件を持っています。同じ文言を装飾的な箇条書きに変換すると、そのセットが完了可能であるという約束が失われます。

この要素が重要な理由

読者はチェックリストを使用して記憶を外部化します。ドラフト、ブラウザ、デザイン、公開インターフェースを行き来しながらすべての要件を頭に保持する代わりに、一度に1つの条件を検査し、進行状況を記録できます。有限の境界は不確実性を軽減します。読者は何が残っているか、「完了」が何を意味するか、いつ次に進んでも安全かがわかります。

この心理的契約は、「ここにいくつか役立つアイデアがあります」よりも強力です。チェックボックスはコミットメントを促し、最後の未チェック項目は意図的な緊張感を生み出します。したがって、この要素は範囲について正直でなければなりません。リストが必要なゲートを省略したり、「ページを素晴らしくする」などの曖昧な願望を含めると、インターフェースはコンテンツが獲得していない確実性をシグナルすることになります。

機械抽出可能性とは、検索エンジン、AI回答システム、支援技術、出版ツールが、各項目の役割や完了モデルを失うことなく抽出できる能力です。型付けされたチェックリストは、名前付きコレクション、安定した項目境界、初期状態、完了条件を公開します。パーサーは必要なゲートを例や利点から区別でき、AIシステムはチェックリストの主題を保持したまま、1つの自己完結型アクションを引用できます。

コンポーネントを選択する前に、要素作成ルール に従ってください。その優先順位ルールは意味論的です。ブロックの目的が完了または検証である場合、通常の箇条書きで同じ文言を表示できても、チェックリスト要素を使用してください。視覚的な類似性では、状態、検証、アクセシビリティ、アダプタマッピングは維持されません。

使用すべき場合

セットが有限で、各項目が独立して合格または不合格になり、必要な項目を完了することで意味のある状態が確立される場合に、チェックリストを使用します。適切な対象には、公開前レビュー、調達要件、移行準備、インシデント引き継ぎ、ドキュメント完全性、アクセシビリティレビュー、定期的なメンテナンス検査が含まれます。

3つのテストを適用します：

1. 状態テスト： 各項目を明確に未完了または完了としてマークできますか？
2. 範囲テスト： リストには宣言された範囲に必要なすべてのチェックが含まれていますか？
3. 完了テスト： 必要な項目を完了することで、名前付きの結果が証明されますか？

いずれかの答えが「いいえ」の場合、別の要素の方がおそらく正確です。よくある類似要素は以下の通りです：

• 箇条書きリスト は、事実、選択肢、例、または属性をグループ化します。その項目はタスクではなく、セットが完了することはありません。
• ステップリスト は依存関係のある順序をエンコードします。項目4を項目2の前に移動すると失敗する可能性がある場合、チェックボックスよりも番号と復旧ガイダンスが重要です。
• 機能リストは製品が何を持っているかを説明します。「CSVエクスポート対応」は、読者が明示された要件を検証しているのでない限り、チェック項目ではありません。
• ウィッシュリストは境界線や優先度が変わる可能性のある好みを記録します。完了を約束するべきではありません。
• スコアカードは尺度上の次元を評価します。二値のチェック状態では、有用なパフォーマンスの度合いが失われます。
• すべてのクリックにチェックボックスを付けた長い手順は、実行と検証を混同します。手順をステップとして説明し、その後で短い完了チェックリストを追加してください。

すべてのセクションの最後に装飾としてチェックリストを使用しないでください。繰り返しの未チェックボックスは作業を課し、コンテンツが単にオプションのアドバイスを提供している場合でも、読者がまだ完了していないことを示唆します。

配置する場所

配置は、読者が行動または検証できるタイミングに従います。最初にタスク、範囲、必要なコンテキストを紹介し、その後、チェックリストをその管理対象となる判断の直前、または要約する内容の直後に配置します。

• 準備チェックリストは、前提条件の後、不可逆的または高コストなアクションの前に配置します。
• 品質保証チェックリストは、評価対象のドラフト、設定、または手順の後、承認または公開の前に配置します。
• 購入要件チェックリストは、ニーズと制約を説明した後、製品を絞り込む前に配置します。
• 定期点検チェックリストは、メンテナンスセクション内、その頻度と担当者の近くに配置します。
• 専用のチェックリスト記事では、主チェックリストを記事の上部近く、短い範囲説明の後に配置し、難しい項目はその下で説明します。

チェックリストは、範囲が重複する別のチェックリストのすぐ隣に配置してはいけません。統合するか、それぞれに明確な見出しと完了条件を付けてください。どのブロックが手順でどれが検証かを明示せずに、順序付きステップリストの隣に配置しないでください。警告とその結果または必要な対応を分断したり、比較表を中断したり、コールトゥアクション内に配置したりしてはいけません。最後の項目と完了条件の間にプロモーションボタンを決して置かないでください。

構成要素

ラベル付けされた領域は以下の通りです：

1. 範囲見出し： 「公開前リンクチェック」など、正確なオブジェクトと判断を命名します。
2. 説明文： 完了によって何が許可されるか、または何が証明されるかを示します。
3. チェックボックスコントロール： 未完了または完了状態をプログラム的かつ視的に公開します。
4. アクションラベル： 具体的な動詞で始まり、単独でも理解可能です。
5. オプション修飾子： しきい値、場所、担当者、またはエビデンス要件を提供します。
6. 必須インジケーター： 契約が本当に許可する場合にのみ、オプション項目を区別します。
7. 進捗サマリー： インタラクティブバリアントで、完了した項目数と必須項目の合計数を報告します。
8. 完了条件： すべての必須項目が合格したときに確立される結果を述べます。

文言は権威を保持します。チェックアイコン、緑色の行、取り消し線ラベルは状態を強化するかもしれませんが、ネイティブまたはプログラムによるチェック状態を置き換えることはできません。

デザイン例

静的編集チェックリスト

印刷用または参照用チェックリストには、表示された未チェックのコントロールを使用します。読者はコピーまたは印刷できますが、ページは進行状況を保存しません。

インタラクティブ進捗チェックリスト

セッション中に読者が進行状況をマークするメリットがある場合に使用します。フォーカスを移動せずにカウントを通知し、明確なリセットアクションを提供します。

必須項目とオプション項目のあるチェックリスト

オプションのタスクが完了条件に本当に影響しない場合にのみ使用します。オプション項目はテキストでラベル付けし、薄い色だけに依存しないでください。

グループ化されたチェックリスト

合計10項目を超えるチェックの場合は、作業を4〜10項目のグループに分割し、それぞれに別々の見出しと完了条件を付けます。各グループは独立して理解可能です。

印刷状態

印刷出力では、空のマークと完了マークを白黒で保持し、ラベルをコントロールの横に配置し、短いグループがページをまたがらないようにします。

パラメーター

初期の checked 値は、実例、保存済みテンプレート、またはサーバー所有のタスク状態を対象としています。編集用チェックリストは未チェックで開始します。作成者は、より魅力的なスクリーンショットを作成するためだけに項目を事前チェックしてはいけません。interactive=false の場合、persist は none でなければなりません。

構文とコード例

正規のマッピングは、基本契約の優先順位、本文、ネスト項目ルールに従います。親がコレクションの動作を提供し、各項目が1つのラベル、オプションの詳細、状態フィールドを提供します。

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

:::checklist{id="pre-publish-links" interactive=true persist=local}
## Pre-publish link check

Complete every required item before approving the page.

::item
### Open every internal link and confirm the destination exists
::

::item
### Confirm each anchor describes its destination out of context
::

::item{required=false}
### Check campaign parameters on optional promotional links
::

::item
### Verify keyboard focus is visible on every linked control
::

Complete when every required item passes and no exception remains.
:::

Hugoショートコード

{{< checklist id="pre-publish-links" title="Pre-publish link check" interactive="true" persist="local" completion="Complete when every required item passes and no exception remains." >}}
{{< checklist-item >}}Open every internal link and confirm the destination exists.{{< /checklist-item >}}
{{< checklist-item >}}Confirm each anchor describes its destination out of context.{{< /checklist-item >}}
{{< checklist-item required="false" >}}Check campaign parameters on optional promotional links.{{< /checklist-item >}}
{{< checklist-item >}}Verify keyboard focus is visible on every linked control.{{< /checklist-item >}}
{{< /checklist >}}

これは必要なHugoアダプターの形状であり、リポジトリがすでにショートコードを提供しているという主張ではありません。登録されたレンダラーが存在するまでは、無関係なスタイルでコンポーネントを模倣するのではなく、セマンティックHTMLをライブ例として使用してください。

WordPressブロック

<!-- wp:amicited/checklist {"id":"pre-publish-links","title":"Pre-publish link check","interactive":true,"persist":"local","completion":"Complete when every required item passes and no exception remains."} -->
<!-- wp:amicited/checklist-item -->
<p>Open every internal link and confirm the destination exists.</p>
<!-- /wp:amicited/checklist-item -->
<!-- wp:amicited/checklist-item -->
<p>Confirm each anchor describes its destination out of context.</p>
<!-- /wp:amicited/checklist-item -->
<!-- wp:amicited/checklist-item {"required":false} -->
<p>Check campaign parameters on optional promotional links.</p>
<!-- /wp:amicited/checklist-item -->
<!-- wp:amicited/checklist-item -->
<p>Verify keyboard focus is visible on every linked control.</p>
<!-- /wp:amicited/checklist-item -->
<!-- /wp:amicited/checklist -->

すべてのアダプターは、ソース順序、必須状態、表示ラベル、完了条件、およびスクリプティングが利用できない場合の未チェックコンテンツを保持する必要があります。

例

良い例：範囲が限定されたリリースチェック

• リリースバージョンが承認された変更記録と一致することを確認する。
• 文書化されたスモークテストを実行し、その結果を添付する。
• ロールバック担当者がリリース期間中に利用可能であることを確認する。
• デプロイ時間をインシデントタイムラインに記録する。

完了条件： 4つの記録すべてが存在し、指名されたロールバック担当者が期間を了承していること。

これは、各項目が観察可能なアクションで始まり、1つのリリース判断に留まり、二値のエビデンスを持つため機能します。完了行は、完全なセットが何を証明するかを説明しています。

悪い例：願望的なコンテンツリスト

• 読者について考える。
• 記事を魅力的にする。
• SEOを改善する。
• 役立つものを追加する。

これは、どの項目も合格条件を定義しておらず、「役立つもの」によってセットが無限になり、ボックスにチェックを入れても記事の準備ができたことが証明されないため、失敗します。願望を「ブリーフに主要読者を1人挙げる」などの検証可能なゲートに置き換えるか、実行不可能なガイダンスを散文に移してください。

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

一般的なSchema.orgのChecklistタイプはありません。独立したチェックをHowToStepにマッピングしないでください。ただし、ページが実際に順序付き手順を説明しており、表示コンテンツにそれらのステップが含まれている場合は除きます。チェックリストはArticle、TechArticle、Product、またはその他の正当なページタイプ内の表示コンテンツとして残ることができますが、そのチェックボックスが追加のスキーマ適格性を生み出すことはありません。

インタラクティブ状態にはネイティブの<input type="checkbox">コントロールを使用し、ラッピングまたは一致するforとid値を使用して各コントロールを<label>に関連付けます。変更できない静的表示は、有効なコントロールになりすましてはいけません。明示的に非インタラクティブな例には無効化されたチェックボックスを使用するか、フォームコントロールが誤解を招く状況では「未チェック」などのテキスト相当物を持つリストを使用してください。

キーボードユーザーは、すべての有効なチェックボックスにソース順で到達し、Spaceキーで切り替え、永続的なフォーカスインジケーターを確認できる必要があります。チェック後にフォーカスを移動しないでください。進捗メッセージが更新される場合は、「必須項目6件中4件完了」などの簡潔なサマリーをポライトライブリージョンを通じて通知し、リスト全体を再度通知しないでください。

チェック済みと未チェックの状態には、色以上のものが必要です。チェック時にラベルを「完了」に置き換えるのではなく、保持してください。アクションが識別可能でなければならないためです。進捗が永続化される場合は、ストレージの範囲を説明し、「進捗をリセット」を提供してください。有用なコンテンツ、必須インジケーター、完了条件は、JavaScriptが失敗した場合でもサーバーレンダリングHTMLに残らなければなりません。

作成ルール

チェックリストの項目はコンパクトです。なぜなら、読者はコントロール内で主題全体を学ぶのではなく、実行または検証しているからです。ルールを述べる前に、周辺の散文で理由を説明してください。

• 1つのチェックリストは4〜10項目に抑えてください。4項目で有用な有限セットが確立されます。10項目を超えるとスキャンが困難になり、複数のフェーズを示します。
• 各アクションは約80文字、3〜12語に抑えてください。短いラベルはコントロールの横で使用可能であり、隣接する散文なしでも抽出可能です。
• 具体的な命令形動詞で開始してください：「確認」、「開く」、「比較」、「記録」、「テスト」、「添付」、「検証」など。「考慮する」、「覚える」、「考える」などの弱い動詞は避けてください。
• 各項目に1つの合格条件を設定してください。「タイトルとリンクを確認する」は部分的に合格する可能性があるため、2つの項目に分割してください。
• 項目は独立させてください。1つのアクションが次のアクションを解放する場合は、手順をステップに変換し、最終検証にのみチェックリストを使用してください。
• 文法と粒度を並列にしてください。「法的承認を確認する」と「すべてのチャネルでキャンペーンを公開し、1週間監視する」を混在させないでください。
• 完了が直接見えない場合はエビデンスを指定してください：レポートを添付する、タイムスタンプを記録する、承認者の確認を得る。
• オプション項目は明示的にマークし、必須の進捗から除外してください。オプションとは、それらがなくても完了条件が真であることを意味します。
• 文のスタイルと末尾の句読点を一貫して使用してください。項目に修飾子が含まれる場合は、完全な文章が推奨されます。

チェックリスト項目の中に以下を決して入れないでください：

• 複数の順序付きサブステップ、分岐するトラブルシューティングロジック、または2つ目のネストされたチェックリスト。
• 行動前に見なければならない安全警告、法的免責事項、または不可逆的な結果。
• 説明の段落、長い引用、推薦文、スクリーンショット、ビデオ、フォーム、またはプロモーションのコールトゥアクション。
• 主観的なスコア、自由回答形式の願望、根拠のないしきい値、または観察可能なエビデンスのない要件。
• 「こちら」とだけラベル付けされたリンク。項目は周囲の文脈なしで抽出されても成立しなければならないためです。

使用する投稿タイプ

以下の結合は、このページの postTypes フロントマターによって駆動されます。「必須」は投稿タイプのコアタスクが有限の完了モデルに依存することを意味し、「推奨」と「オプション」はページの主題に依存します。

QAチェックリスト

コンテンツと配置

• 見出しが1つの境界のあるオブジェクト、判断、または準備状態を命名している。
• 導入部で必須項目の完了が何を証明するかを説明している。
• 4〜10項目を使用し、より大きな作業は名前付きグループに分割している。
• 各項目を約80文字に抑え、具体的な動詞で開始している。
• 各項目に1つの観察可能な合格条件があり、独立してチェックできる。
• 項目の順序を変更してもタスクが壊れないことを確認する。
• セットは有限であり、宣言された範囲に必要なすべてのゲートを含んでいる。
• オプション項目は視覚的にラベル付けされ、必須の進捗から除外されている。
• ネストされた手順、警告、長い説明、メディア、プロモーションを削除している。

完了条件： コレクションに1つの境界のある目的があり、すべての項目が簡潔で、独立しており、検証可能であること。

レンダリングとアクセシビリティ

• 完了条件が最後の項目の直後に表示されている。
• 有効なコントロールには関連するラベル、キーボード操作、表示可能なフォーカスがある。
• 状態が色、アイコン、取り消し線、または位置だけで伝えられていない。
• インタラクティブな進捗がフォーカスを移動せずに機能し、永続化について説明している。
• ラベルと完了基準がCSSやJavaScriptなしでも利用可能である。
• 構造化データはそれを囲むページに保持し、Checklistスキーマを発明しない。
• 3つのプラットフォームマッピングすべてで同じフィールドと順序を保持する。
• スクリーンショットコメントは指示として保持し、存在しない画像を参照しない。

完了条件： 状態、ラベル、順序、完了の意味が、サポートされているすべてのレンダリングパスで維持されること。

よくある質問

アカデミーテンプレートは、このページの [[faq]] フロントマターにある5つのレビュー済み質問をレンダリングします。これらは、項目数、箇条書きやステップとの区別、保存状態、構造化データをカバーしています。