{"meta":{"title":"コンテンツ モデルについて","intro":"コンテンツ モデルでは、公開するコンテンツの構造と種類が記述されています。","product":"GitHub Docs に投稿する","breadcrumbs":[{"href":"/ja/enterprise-cloud@latest/contributing","title":"GitHub Docs に投稿する"},{"href":"/ja/enterprise-cloud@latest/contributing/style-guide-and-content-model","title":"スタイル ガイドと コンテンツモード"},{"href":"/ja/enterprise-cloud@latest/contributing/style-guide-and-content-model/about-the-content-model","title":"コンテンツ モデルについて"}],"documentType":"article"},"body":"# コンテンツ モデルについて\n\nコンテンツ モデルでは、公開するコンテンツの構造と種類が記述されています。\n\nコンテンツ モデルでは、 GitHub Docs内で作成するコンテンツの種類ごとの目的と、記事を作成または更新するときに含める内容について説明します。 コンテンツ モデルを使用して、ユーザーが目標を達成するために必要な情報を一貫して明確かつ包括的に GitHubで伝えます。\n\nすべてのドキュメント セットでこれらの種類を使用して、一貫したユーザー エクスペリエンスを提供します。すべてのコンテンツの種類は、すべての製品または対象ユーザーに適用されます。 コンテンツの種類は時間の経過と共に進化し、新しい種類が追加されます。 モデルに従うコンテンツのみを公開します。\n\n一貫性は、ドキュメントのメンタル モデルを形成し、時間の経過とともに GitHub Docs に戻る際に必要な情報を見つける方法を理解するのに役立ちます。 また、一貫性のあるコンテンツを維持および更新する方が効率的で、初めてのコミットを行うオープンソース共同作成者でも、新しい製品全体を文書化するGitHubスタッフのライターであっても、ドキュメントへの投稿がより簡単かつ迅速になります。\n\n## コンテンツの構造\n\nドキュメントは、サイト上の階層の複数のレベルに編成されています。\n\n* 最上位のドキュメント セット\n  * カテゴリー\n    * 地図のテーマ\n      * 記事\n    * 記事\n  * 記事\n\nコンテンツの整理とは、検索対象を見つけるのに役立つ特定のグループ化を作成することと、ユーザーが移動する必要がある階層のレイヤを制限することのバランスです。 多くのマップ トピックが入れ子になった複雑な階層では、特定の記事を見つけることが難しくなります。 多くのカテゴリまたは記事が同じレベルの幅広い階層では、ユーザーが選択する内容を評価して決定することが難しくなります。\n\n## ホームページのコンテンツ\n\nGitHub Docsホームページ [docs.github.com](/ja/enterprise-cloud@latest) では、ユーザーが検索する最も重要なトピックが強調表示されています。 ホームページのドキュメント セットの数を制限して、ユーザーが情報を見つけることができ、ホームページが過密になって検索が困難にならないようにします。<!-- markdownlint-disable-line search-replace -->\n\nホームページには、すべての最上位ドキュメントセットといくつかのカテゴリが含まれています。 ホームページ上のコンテンツは、 GitHub の概念とプラクティスを中心に整理されています。 たとえば、\"CI/CD と DevOps\" グループには、 GitHub Actions、 GitHub Packages、および GitHub Pagesの最上位のドキュメント セットが含まれています。\n\n### ホームページへのドキュメント セットの追加\n\nホームページの目的は、ユーザーが学習する GitHub 機能または製品に関する情報を見つけるのを支援することです。 ホームページに項目を追加するたびに、他の項目が見つけにくくなるため、ホームページに含まれるドキュメント セットの数を制限します。\n\n新しい最上位ドキュメント セットが作成されると、ホームページにそれが追加されます。\n\nカテゴリが GitHub の製品または機能を使用するための開始点として機能する場合は、ホーム ページに追加できます。\n\n## 最上位のドキュメント セット\n\n最上位のドキュメント セットは、 GitHub 製品、機能、またはコア ワークフローを中心に編成されます。 最上位のドキュメント セットはすべて、 GitHub Docs ホームページに表示されます。 最上位ドキュメント セットを作成するのは、新しいドキュメント セットに含まれるコンテンツが大量で、マップ トピックに分割された複数のカテゴリがあり、そのトピックが製品、機能、またはアカウントの種類にまたがって適用される場合のみです。 コンテンツが既存の最上位ドキュメント セットに収まる場合は、その既存のドキュメント セットに属している可能性があります。\n\n* 最上位レベルのドキュメント セットは、互いにほぼ同じ重要性を持ちます (それぞれが GitHub 製品または主要な機能を中心としています)。\n* 重要な例外がない限り、ほとんどの最上位ドキュメント セットにはランディング ページ レイアウトがあります。 たとえば、「[サイト ポリシー](/ja/site-policy)」ドキュメント セットには、他のドキュメント セットのようなガイドや手順に関する記事がないため、ランディング ページ レイアウトは使用されません。\n* 最上位のドキュメント セットには、カテゴリ、マップ トピック、または記事の組み合わせを含めることができます。\n\n### 最上位ドキュメント セットのタイトル\n\n* 機能または製品ベース。\n* だれかが使用している GitHub の部分について説明します。\n* 例\n  * [組織とチームに関するドキュメント](/ja/enterprise-cloud@latest/organizations)\n  * [GitHub Issues ドキュメント](/ja/enterprise-cloud@latest/issues)\n\n## カテゴリ\n\nカテゴリは、製品のテーマに合わせて最上位ドキュメント セット内の機能または個別のタスク セットを中心に編成されます。 カテゴリの件名は、そのコンテンツを管理でき、大きすぎて使用できなくならない程度に範囲が絞られています。 一部のカテゴリはホームページに表示されます。\n\n* 多くの場合、カテゴリは最初は小さく、製品と共に大きくなります。\n* カテゴリには、より具体的なユーザー体験やタスクに関するコンテンツを分割するためのマップ トピックが含まれる場合があります。\n* 長い手続き型記事を使用して、関連するコンテンツのチャンクをグループ化し、カテゴリ内の記事を合理化した状態に保ちます。\n* カテゴリに 10 件を超える記事がある場合は、コンテンツをマップ トピックまたは追加のカテゴリに分割することを検討してください。\n* カテゴリには、マップ トピックまたは記事の組み合わせを含めることができます。\n\n### カテゴリのタイトル\n\n* タスク ベース (動名詞で始まる)。\n* 機能または製品を使用する全体的な目的または目標を記述します。\n* 将来の製品の機能強化に合わせてスケーリングするのに十分な一般的または大まかなもの。\n* カテゴリ タイトルは 67 文字以下で、[`shortTitle`](https://github.com/github/docs/tree/main/content#shorttitle) が 27 文字未満である必要があります。\n* 例\n  * [GitHub アカウントとプロファイルの使用方法](/ja/enterprise-cloud@latest/account-and-profile/how-tos)\n  * [変更をコミットする](/ja/enterprise-cloud@latest/pull-requests/how-tos/commit-changes)\n\n### カテゴリの紹介\n\nすべてのカテゴリに概要があります。 概要は、1 文の長さで、将来の製品の変更に合わせてスケーリングするのに十分な一般的または大まかなものである必要があります。 カテゴリの構造を大幅に変更する場合は、必要な更新の概要を確認してください。\n\n## マップ トピック\n\nマップ トピックでは、カテゴリのセクションを紹介し、カテゴリのより大きなタスクの一部であるより具体的なワークフローまたは件名に関するカテゴリ内の記事をグループ化します。\n\nマップ トピックには、少なくとも 2 つの記事が含まれています。 マップ トピックに 8 件を超える記事がある場合は、コンテンツをより具体的なマップ トピックに分割することを検討すると便利な場合があります。\n\n一般に、特定のユーザーのニーズを満たす最善の方法でない限り、マップ トピック内にマップ トピックを含めないでください。\n\n### マップ トピックのタイトル\n\n* タスク ベース (動名詞で始まる)。\n* カテゴリのより大きなワークフロー内のより具体的なタスクを記述します。\n* 製品への将来の追加に合わせてスケーリングするのに十分な一般的または大まかなもの。\n* マップ トピックのタイトルは 63 文字以下で、[`shortTitle`](https://github.com/github/docs/tree/main/content#shorttitle) が 30 文字未満である必要があります。\n* 例\n  * [サプライ チェーンのセキュリティ](/ja/enterprise-cloud@latest/code-security/concepts/supply-chain-security)\n  * [Enterprise のユーザを管理する](/ja/enterprise-cloud@latest/admin/managing-accounts-and-repositories/managing-users-in-your-enterprise)\n\n### マップ トピックのイントロ\n\nすべてのマップ トピックに概要があります。 概要は、1 文の長さで、将来の製品の変更に合わせてスケーリングするのに十分な一般的または大まかなものである必要があります。 マップ トピックで記事を追加または削除する場合は、必要な更新の概要を確認してください。\n\n## \\[アーティクル]\n\n記事は、 GitHub Docsのコンテンツの基本単位です。複数のコンテンツ タイプを使用していますが、これらはすべて記事として公開されています。 各コンテンツの種類には独自の目的、形式、構造があります。しかし、記事で一貫したユーザー エクスペリエンスを確実に提供できるように、概要などのすべての記事の種類で標準的な要素を使用します。\n\n## コンテンツの順序\n\nカテゴリ、マップ トピック、記事内で予測どおりにコンテンツを整理します。 最も広い適用性から、最も具体的な、範囲を絞った、または詳細な情報まで、次の順序に従います。\n\n* 概念的コンテンツ\n* 参照コンテンツ\n* 機能または設定を有効にするための手続き型コンテンツ\n* 機能の使用に関する手続き型コンテンツ\n* 機能または設定の管理に関する手続き型コンテンツ\n* 機能または設定の無効化に関する手続き型コンテンツ\n* 破壊的なアクションに関する手続き型コンテンツ (削除など)\n* トラブルシューティング情報\n\n## コンテンツの再利用\n\n再利用可能な変数文字列を使って、手続き型手順や概念的な段落など、同じコンテンツのチャンクを複数の場所で使用します。 一般に、具体的な理由なしに記事の大きなセクションを再利用することはありません。 記事のセクション全体が複数の記事に関連している可能性がある場合は、両方の目的を確認してください。 1 つの長い形式の記事を作成する機会はありますか? 情報に最適で永続的なホームを明確にし、他の記事からリンクするには、コンテンツ モデルを参照してください。"}