Skip to content

非公式本サイトは非公式の日本語ドキュメントであり、Cloudflare 公式サイトではありません。最新情報はdevelopers.cloudflare.comをご確認ください。

貢献

最終更新 Markdown で表示Agent セットアップ

Cloudflare Docs ↗ はオープンソースで、GitHub の cloudflare-docs リポジトリ ↗ でホストされています。つまり、Cloudflare 組織の一員でない人も含め、誰でも貢献できます。ドキュメントの品質を保ち、最新に保つ提案を歓迎します。

ドキュメントに貢献するには、GitHub アカウントを作成 ↗ し（まだない場合）、ログインします。そのあと、次の 3 つの方法があります。

  • GitHub issue: 一般的な提案をすばやく送ります。
  • クイック編集（編集ボタン）: すばやく pull request を作成します。Web ブラウザーで 1 ページだけ編集し、変更のプレビューが不要なときに適しています。
  • フル開発: pull request を作成します。複数ページを編集し、変更をプレビューしたいときに適しています。Codespaces ↗ で Web ブラウザーから行うことも、Visual Studio Code ↗ でローカルマシンから行うこともできます。

文法とスタイルの指針として Cloudflare Style Guide を使うほか、ボタン、タブ、折りたたみセクションなどの追加フォーマットには コンポーネント を確認することを推奨します。

GitHub issue を作成する

GitHub issue を作成します。

  1. GitHub にログイン ↗ し、cloudflare-docs リポジトリ ↗ を開きます。
  2. Issues を選び、続けて New issue を選びます。
  3. issue の種類を選び、フォームに記入して Create を選びます。

GitHub issue の作成について、さらに学ぶ ↗

クイック編集

編集ボタンを使い、すばやく pull request を作成します。

  1. GitHub にログイン ↗ します。
  2. Cloudflare Docs ↗ で編集したいページを開きます。

  3. Edit または Edit page

    Cloudflare Docs のすべてのページ（このページも含む）には、右サイドバーに Edit ボタンがあり、ページ最下部に Edit page ボタンがあります。 編集アイコン
    ページの Markdown が開きます。
  4. 編集し、Commit changes を選びます。
  5. フォームで、Commit message を、変更した製品を括弧に入れた短い説明に更新します。例: 「[Images] Fixed broken link.」
  6. Extended description に、何をなぜ変えたかの詳細を書きます。詳しいほどよいです。
  7. Propose changes > Create pull request > もう一度 Create pull request を選びます。

フル開発

フル開発ワークフロー ↗ で編集し、pull request を作成します。

  1. GitHub にログイン ↗ し、cloudflare-docs リポジトリをフォーク ↗ します。

  2. Web ブラウザーで編集する場合（Codespaces ↗）は、ステップ 3 へ進みます。


    ローカルマシンで編集する場合（Visual Studio Code ↗）: * （必須）Node.js ↗ をインストールします（バージョン 24 以降）。 * （推奨、任意）パッケージ管理を簡単にするため Volta ↗ をインストールします。 * （必須）フォークをローカルマシンにクローンします。 ↗

  3. フォーク（またはクローン）からブランチを作成します。

  4. 編集します。

  5. 依存関係をインストールし、ローカル開発サーバーを起動して、編集内容をプレビューします。

    pnpm install
pnpm run dev

    ターミナルにリンク（例: https://localhost:1111/）が表示され、そこで変更をプレビューできます。編集するとプレビューは自動更新されます。

  6. 変更をコミットします。

  7. コミットをブランチへプッシュし、フォークへ戻します。

  8. GitHub に戻り、コミットした変更から pull request を作成します。説明フォームに、変更した製品を括弧に入れた短い説明を追加します。例: 「[Images] Fixed broken link.」

issue または PR を作成したあと

issue または PR を作成すると、Cloudflare 組織のメンバーが提案をレビューします。次のように進みます。

  • Cloudflare 組織のメンバーが、技術またはコンテンツのレビューやフィードバックのために、ほかの人をタグ付けすることがあります。
  • 提案に追加情報が必要な場合、Cloudflare 組織のメンバーがフォローアップや確認の質問をコメントすることがあります。more-information-needed タグを付けると、14 日以内に応答がない場合、issue または pull request は自動で閉じます。
  • 変更が承認された場合:
    • GitHub issue では、Cloudflare メンバーがリクエストに対応する新しい pull request を作成し、リンクすることがあります。PR をマージすると、issue も閉じます。
    • GitHub PR では、Cloudflare メンバーが PR をマージします。
  • 提案が承認されない場合、Cloudflare メンバーが理由を返信し、issue または PR を閉じます。

オープンソースのエコシステムへの貢献と、Cloudflare コミュニティへの参加に感謝します。

コンテンツレビュー

GitHub ↗ で作業しています（そしてそれを歓迎しています）が、完璧なツールではありません。

受信作業のトリアージ、レビューの効率化、コミュニケーションの自動化を助けるため、いくつかの使いやすい改善を追加しました。

作業のトリアージ

ライターが作業をトリアージできるように（バックエンドのレポートにも役立つように）、いくつかのラベルと issue / pull request の割り当てを自動化しています。

Pull request

pull request では、特定の GitHub action ↗ でラベルを追加し、codeowners を割り当てます。

  • 製品のラベル付け ↗: トップレベルの製品フォルダーにラベルを付けます。ライターが受信 pull request を流し見し、自分に関係するものを見つけやすくします。
  • サイズのラベル付け ↗: pull request のサイズにラベルを付けます。差分の相対的な大きさを把握しやすくします。完璧な尺度ではありませんが、変更行数で pull request のサイズを見積もります。
  • codeowners の割り当て ↗: CODEOWNERS ↗ ファイルを使い、変更ファイルに基づいて人を pull request に自動割り当てします。この割り当てにより、ライターはスキャンとフィルターで、自分に関係する pull request を見つけやすくなります。

Issue

issue でも、同様の GitHub action ↗ でラベルを追加し、codeowners を割り当てます。

スクリプト ↗ が issue を扱うのは、通常、リポジトリ内のファイルではなくサイトへのリンクが含まれるためです。issue の説明欄から関連リンクを取り出し、それでライターを割り当て（ここでも CODEOWNERS に基づく）、製品ラベルを追加します。

レビューの効率化

レビューを効率化するため、よくあるレビュアーの課題を解く自動化をいくつか使っています。

何か壊れますか？

すべてのコミットで必須チェックが 1 つ走ります。CI ↗ です。

このチェックは次を確認します。

誰の承認が必要ですか？

承認についての質問はよくあります。特に、複数の製品領域（またはコンポーネント）にまたがる pull request です。

開いている pull request では、Cloudflare Docs Bot が Review coverage ↗ コメントを投稿します。まだ CODEOWNERS の承認が必要な領域、その領域の連絡先候補、すでにカバー済みの領域の要約を示します。コメントに表示される所有領域の正確なパターンと所有者を見るには、CODEOWNERS mappings セクションを展開します。Bot は、下書き、クローズ済み、スパム / オフトピックの pull request をスキップします。

何が変わりましたか？

GitHub action ↗ を使い、pull request のすべてのコミットにプレビュービルドを公開します（そのリンクを pull request にコメント ↗ します）。これにより、レビュアーは GitHub 上の変更済み Markdown だけでなく、レンダリング後のサイトとコンテンツの見た目を正確に確認できます。

現在、その機能をネイティブに提供する Workers Builds への移行を進めています。

フィードバックに基づき、レビュアーがプレビュービルド内のリンクを見つけやすいよう、前後のリンク表も追加しました。

前後の表

ほかに確認することはありますか？

確認が難しいことの 1 つは、pull request がコンテンツのファイルパスをリネームまたは削除するときの、潜在的なリダイレクトです。

レビュアーがこれらのパスを特定し、確認しやすくするコメントを投稿する 専用の action ↗ があります。

GitHub Actions のリダイレクトコメント

コミュニケーションの自動化

コミュニケーションは、主に no-response ↗ GitHub Action で自動化しています。

オープンソースであるため、誰からの issue と pull request も受け付けます。その多くは自明であるか、フォローアップに十分なコンテキストがあります。

一方、コンテキストが足りないものは負担になりがちです（特に、私たちの 忙しいリポジトリ ↗ では）。ライターは詳細を尋ね、あとで確認し、場合によっては再度尋ね、また確認する必要があります。

この精神的な負荷を減らすため、質問したあとに more-information-needed ラベルを付けます。このラベルは、著者が応答するための 14 日のタイマー ↗ を開始します。応答があればラベルは外れ、会話を続けられます。応答がなければ、issue は 理由を説明するコメント ↗ 付きで自動的に閉じます。

応答なしのコメント

このワークフローは、チームの必要と、貢献者への健全な敬意のバランスを取ることを意図しています。

古い issue

一定期間活動がない pull request や issue を閉じる stale ワークフロー ↗ は、意図的に使いません。

私たちの見解では、このワークフローは解決する以上の摩擦と不満を生みます。1 年残っているからといって、まだ関係ないとは限りません。

AI で Cloudflare ドキュメントに貢献する

cloudflare-docs リポジトリには AGENTS.md ↗ ファイルがあります。AI コーディングエージェントがリポジトリの構造、ツール、規約を理解し、ドキュメント貢献時に正しくビルドできる変更を行えるようにします。

AGENTS.md ↗ は、コーディングエージェントを案内するためのシンプルなオープン形式です。

リポジトリには、次の AI ツール向けの設定が最初から含まれます。

エージェントスキル、コマンド、エージェント定義はすべて .agents/ にあり、各ツールが期待する場所へ自動でシンボリックリンクされます。

役に立ちましたか？