リリースごとにドキュメントを自動更新する方法

2026年11月3日更新

リリースごとにドキュメントを自動更新するには、リリース自体（公開されたGitHubリリース、GitLabのリリースイベント、Bitbucketのタグ、または公開変更履歴への新規エントリ）からドキュメント作成ジョブを開始します。このジョブはリリースノートを読み取り、影響を受けるヘルプページや動画を特定し、変更案を作成して担当者に承認を求めます。顧客向けドキュメントの場合、このレビュー工程がドキュメント自動化の安全性を保つ鍵となります。

本ガイドでは、まず任意のツール（GitHub Actions、GitLab、Bitbucket、変更履歴ページ）を使用したパイプラインを解説し、続いてCleveraのAutopilotが動画付きヘルプセンターで同様のループを実行する方法を紹介します。

継続的ドキュメント（Continuous Documentation）とは？#

この用語を広めたSwimmは、継続的ドキュメントを「時折まとめて行う作業ではなく、開発ワークフローの一部として段階的にドキュメントを作成・更新すること」と定義しています。この考え方に基づいたツールの多くは、現在「自己更新型ドキュメント」として販売されており、コミットやプルリクエストを監視してコードの隣にある開発者向けドキュメントを更新します。

顧客向けヘルプセンターには、異なるトリガーが必要です。読者はコミットではなくリリースを目にするからです。以下の表は、そのトレードオフを示しています。

自動化を導入する理由はスピードです。DORAの2021年DevOps状況調査では、エリートチームは低パフォーマンスチームより973倍頻繁にデプロイしていることが判明しました。すべてのデプロイが読者の目に触れるわけではありませんが、チームは人間が手作業で記事を再確認できる以上の頻度でリリースを行っています。同調査では、高品質なドキュメントを持つチームは、セキュリティのベストプラクティスを実装する可能性が3.8倍高いことも分かっており、ドキュメントは決して二の次ではありません。また、古いドキュメントは一般的です。GitHubの2017年オープンソース調査では、回答者の93%が不完全または古いドキュメントに遭遇した経験があり、60%の貢献者がドキュメントへの貢献をほとんど、あるいは全く行わないと回答しています。

ステップ1：ドキュメント作成ジョブが利用できるリリースノートを書く#

自動化によるドキュメント更新の精度は、リリースノートの記述内容に左右されます。以下の2つの慣習が役立ちます。

• 変更をタイプ別にグループ化する。 Keep a Changelogでは、Added（追加）、Changed（変更）、Deprecated（非推奨）、Removed（削除）、Fixed（修正）、Security（セキュリティ）を使用します。「Added」は通常、新しい記事や動画を意味し、「Changed」や「Removed」は既存のコンテンツが古くなったことを意味します。
• ユーザーに見えるものと見えないものを分ける。 GitHubの自動生成リリースノートは、マージされたプルリクエストを.github/release.ymlのラベルで分類し、特定のラベルを完全に除外することも可能です。

# .github/release.yml
changelog:
  exclude:
    labels: [internal, chore]
  categories:
    - title: New
      labels: [feature]
    - title: Changed in the app
      labels: [ui-change]
    - title: Fixes
      labels: [bug]
    - title: Other changes
      labels: ["*"]

「ui-change」ラベルを追加するのが最も有効です。これにより、ドキュメント作成ジョブはどの項目が記事を修正対象とするかを判断できます。プルリクエストのタイトルにも画面名を記載してください（例：「請求設定：リマインダーを『自動化』へ移動」）。そうすることで、その画面を表示しているページと変更を照合できます。

ステップ2：リリース時にドキュメントを自動更新する：ジョブを開始する#

主要なGitホストはすべて、出荷時にジョブを開始できます。これを利用して、GitHubリリースやGitLab、Bitbucketの同等機能からドキュメント更新を生成します。詳細はそれぞれ異なります。

GitHubにおける最小限のワークフローは以下の通りです。

# .github/workflows/docs-on-release.yml
name: Docs on release
on:
  release:
    types: [published]
permissions:
  contents: read
jobs:
  draft-docs:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
        with:
          persist-credentials: false
      - name: Draft docs updates for this release
        env:
          TAG: ${{ github.event.release.tag_name }}
          NOTES: ${{ github.event.release.body }}
        run: ./scripts/draft-docs-updates.sh

createdではなくpublishedを使用してください。GitHubのイベントリファレンスにある通り、createdはドラフトリリースでは発火せず、publishedは安定版リリースとプレリリースの両方をカバーするためです。リリースノートはユーザー入力であるため、シェルコマンドに直接渡さず、上記のように環境変数経由で渡してください。また、release-pleaseやsemantic-releaseのようなツールがデフォルトトークンでリリースを作成する場合、それらがトリガーするイベントはドキュメントワークフローを開始しません。代わりにGitHub Appトークンやパーソナルアクセストークンをそのツールに付与してください。

GitLabやBitbucketでは、タグに対して実行されるジョブがこれに相当します。

# .gitlab-ci.yml
draft-docs:
  rules:
    - if: $CI_COMMIT_TAG
  script:
    - ./scripts/draft-docs-updates.sh "$CI_COMMIT_TAG"

# bitbucket-pipelines.yml
pipelines:
  tags:
    'v*':
      - step:
          script:
            - ./scripts/draft-docs-updates.sh "$BITBUCKET_TAG"

ステップ3：各リリースが影響を与えるページと動画を特定する#

これは多くのガイドで省略されていますが、自動化が役立つかどうかを決定づける重要なステップです。リリースノートに「リマインダーを『請求』から『自動化』へ移動」とある場合、ジョブはそれを「これら3つの記事と2つの動画が現在不正確である」と変換しなければなりません。

最もシンプルなものから強力なものまで、3つの手法があります。

1. 名前が変更されたラベルを検索する。 リリースノートから引用されたUI文字列をすべて抽出し、記事や動画スクリプト内で古い表現を検索します。
2. 画面インベントリを維持する。 各記事や動画に表示されている画面をタグ付けし、プルリクエストのタイトルにある画面名と照合します。ドキュメントを最新に保つ方法のガイドには、インベントリのテンプレートがあります。
3. モデルに各候補ページを全文読み込ませる。 言語モデルにリリースノートと各候補ページの全文（またはトランスクリプト）を渡し、「正しいままか」「テキスト修正が必要か」「新しいスクリーンショットや動画が必要か」という判定を求めます。ページ全体を読み込ませることが重要です。なぜなら、壊れているステップはリリースノートに記載されている箇所とは限らないからです。

その判定のためのプロンプトは簡潔で構いません。

You check help articles against a software release.
Release notes: {release_notes}
Article ({url}): {article_text}

Answer in JSON: {"verdict": "still_right" | "text_fix" | "new_screenshots_or_footage",
"reason": "<one sentence quoting the release item>",
"changed_steps": [<step numbers>]}
Only use facts from the release notes. If unsure, answer "text_fix" and say why.

ステップ4：更新案を作成する#

テキストの場合、案の作成は簡単です。モデルがリリースノート、現在の記事、スタイルルールを受け取り、改訂版を返します。記事のIDとURLを保持することで、重複を作成せずに既存ページを更新し、最後に変更されたリリースを記録します。ヘルプセンター記事の書き方のルールは、優れたスタイルプロンプトになります。

スクリーンショットや動画はより困難です。モデルは見たことのない画面のスクリーンショットを作成できません。UIテストスイートで新しい画像をキャプチャするか、変更されたフローを再録画するか、担当者に再録画を依頼するフラグを立てる必要があります。計画内の各項目に「テキスト修正」「新しいスクリーンショット」「再録画」のいずれかをマークします。変更されたフローを録画したら、録画をドキュメントに変換することで、新しいステップとスクリーンショットを一度に取得できます。

ステップ5：ドラフトと読者の間に担当者を介在させる#

プルリクエストの説明は多くの人によって書かれ、顧客の視点でレビューされることはありません。これらやリリースノートは信頼できない入力として扱い、モデルが従うべき指示が含まれている可能性があると考え、すべてのドラフトをレビューに回してください。

• 承認者： ヘルプセンターコンテンツならサポートまたはドキュメントのリード、APIリファレンスならエンジニア。
• 優れたレビューのポイント： 影響を受ける各ページの修正前後の差分、原因となったリリース項目、そしてレビュー担当者がスキップされた箇所を信頼できるようにするための明確な「変更なし」リスト。
• 自動公開するもの： 最初は顧客向けのものを含めないこと。いくつかのリリースで問題がないことが確認できたら、誤字修正のような低リスク項目についてはルールを緩和できます。

どのセットアップがチームに最適か？#

チームがすでにClaude Codeを使用している場合は、MCP経由でリリース後のドキュメント更新を依頼することも可能です。その手順については、リリースごとにClaude Codeでドキュメントを更新する方法で解説しています。

Clevera Autopilotでリリース時にドキュメントを自動更新する方法#

Cleveraは、画面録画からナレーション付きのハウツー動画、ステップバイステップのヘルプ記事、そしてホスト型ヘルプセンターのページを74言語で生成するAIプラットフォームです。Proプランおよびカスタムプランで利用可能なAutopilot機能は、上記のステップ2から5をCleveraヘルプセンター向けに自動実行します。

• トリガー。 「製品リリース時にヘルプセンターを最新に保つ」レシピは、リポジトリの「リリース」や「マージされた変更」、あるいは毎日または毎週読み込まれる「変更履歴ページ」を監視します。GitHubは読み取り専用アプリを通じて接続し、GitLab (gitlab.com) やBitbucket Cloudも利用可能な環境で同様に接続します。Cleveraは約1時間に1回リポジトリを確認し、リリースノート、タグ、プルリクエストのタイトルや説明を読み取ります（コード自体は読み取りません）。
• 照合。 実行のたびに、ヘルプセンター内の最大40件の動画や記事をチェックし、影響を受ける各項目を完全に読み取ります。
• ドラフト作成。 各項目に対して「変更なし」「テキスト修正（修正前後の比較を表示）」「新しい手順で再録画」のいずれかの判定を下します。再録画には「アプリの使用」が必要です。アプリのアドレスと、必要に応じてサインイン情報（テストアカウントが最適です）を提供します。新しい動画は同じリンク先で古い動画を置き換えるため、LiveSyncの編集と同様に、埋め込みやヘルプセンターのページではリンクを変更することなく最新の動画が表示されます。
• レビュー。 すべての実行はユーザーの確認を待ちます。不要な項目を選択解除して「実行」をクリックするか、「変更を依頼」をクリックして新しい計画を作成します。計画は7日間で期限切れとなり、次回の実行ですべての変更が反映されます。

監視と計画作成は無料です。計画の各行には必要なクレジットが表示され、通常の実行には10〜150クレジットを消費します。ヘルプセンターがない場合でも、「製品変更時に動画を更新する」機能で同様のループを利用できます。また、「新機能ごとに動画を録画する」機能では、リリース内容に基づいた新しいハウツー動画を提案します（手動での作成方法はリリースノート動画の作り方を参照してください）。

Cleveraが適さないケース：コードからのAPIリファレンス生成や、CHANGELOG.mdの作成には対応していません。その場合は、AI変更履歴ジェネレーターの比較をご覧いただくか、他のプラットフォームでAIエージェントにドキュメントを編集させたい場合はドキュメント用MCPサーバーをご検討ください。

無料で開始して、まずはヘルプセンターと動画を構築してください。AutopilotはProプランに含まれています。セットアップ手順はヘルプ記事AutopilotにGitHubやその他のリポジトリを接続するを参照してください。

FAQ#

リリース時にドキュメントを自動更新できますか？#

検知とドラフト作成は自動化可能です。リリースをトリガーとしてジョブが開始され、影響を受けるページを特定して修正案を作成します。ただし、リリースノートにはユーザーが取るべき行動が常に明記されているとは限らないため、顧客向けのドキュメントについては、公開の判断は人間が行うべきです。

ドキュメントはコミットごと、それともリリースごとに更新すべきですか？#

ヘルプセンターの場合は、リリースごとが最適です。コミットやプルリクエストは頻繁に変更され、機能フラグの背後に隠れていることも多いため、ユーザーが実際に変更を体験するのはリリース時だからです。コードと密接に関連する開発者向けドキュメントは、プルリクエストに従って更新しても良いでしょう。

リリース公開時にGitHub Actionsをトリガーするにはどうすればよいですか？#

on: releaseとtypes: [published]を使用してください。リリースがデフォルトのGITHUB_TOKENを使用して別のワークフローによって作成された場合、ワークフローは開始されません。リリースツールにはGitHub Appトークンまたはパーソナルアクセストークンを使用してください。

GitHubでリリースを公開していない場合はどうすればよいですか？#

利用可能なシグナルを使用してください。GitLabのリリースイベント、Bitbucketのタグパイプライン、あるいは公開されている変更履歴ページやRSSフィードを読み取るスケジュールジョブなどが有効です。CleveraのAutopilotは、まさにこのケースに対応しており、変更履歴ページを毎日または毎週監視できます。

スクリーンショットや動画も自動更新できますか？#

スクリーンショットは、ビルドごとのUIテストでキャプチャ可能です。動画については、変更されたフローを再録画する必要があります。AIレコーダーは保存された手順を新しいUIに対して再実行でき、Autopilotはアプリのアドレス（および必要に応じてサインイン情報）を提供することで、Clevera動画に対してこれを実行します。承認前に新しい録画内容を確認してください。