GitHub Actions：リリースごとにフリップブックを自動生成する

ドキュメント、リリースノート、製品カタログがPDFとしてリポジトリに置かれているなら、手作業でフリップブックを公開する理由はありません。GitHub ActionsとFlipLink CLIを使えば、リリースを切るたびにPDFをビルドし、公開フリップブックに変換して、その公開URLをリリースに直接投稿できます—ダッシュボードに一切触れることなく。

これはCI/CDでのフリップブック公開のGitHubネイティブ版です。別のランナー（GitLab CI、CircleCI、cronボックスなど）を使っている場合でも、手順はそのまま当てはまります—変わるのはYAMLの形だけです。

作るもの

公開されたリリースをトリガーに動き、次のことを行うワークフローです。

1. リポジトリをチェックアウトし、公開したいPDFをビルド（または特定）します。
2. FlipLink CLIをインストールします。
3. リポジトリのシークレットに保存したAPIキーで認証しながら、そのPDFからフリップブックを作成して公開します。
4. JSON出力から公開フリップブックのURLを取得します。
5. そのURLをリリースに自動でコメントし、チームがすぐにリンクを受け取れるようにします。

これはまさに教科書どおりの自動化です。イベントが発火し、スクリプトが走り、成果物が出荷される、という流れです。

ステップ1 — APIキーをリポジトリのシークレットとして保存する

APIキーをワークフローファイルに直接貼り付けてはいけません。ワークフローファイルはリポジトリ内に置かれます—読み取り権限を持つ人（そしてすべてのフォーク）から見えてしまいます。代わりに暗号化されたシークレットを使いましょう。

1. https://go.fliplink.meにサインインし、Subscriptionページを開いてAPIキーをコピーします。
2. GitHubのリポジトリで、Settings → Secrets and variables → Actionsに移動します。
3. New repository secretをクリックします。
4. 名前をFLIPLINK_API_KEYとし、キーを値として貼り付けます。
5. Add secretをクリックします。

ワークフローはsecrets.FLIPLINK_API_KEY経由でこれを読み取り、FLIPLINK_API_KEY環境変数としてCLIに渡します。CLIはこの環境変数を自動でチェックするため、CI内でconfig set-keyの手順は不要です。

ステップ2 — ワークフローファイル

.github/workflows/publish-flipbook.ymlを作成します。

name: Publish flipbook on release

on:
  release:
    types: [published]

permissions:
  contents: write   # needed to edit the release notes in the last step

jobs:
  flipbook:
    runs-on: ubuntu-latest
    steps:
      - name: Check out repository
        uses: actions/checkout@v4

      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 20

      # Replace this with however you produce the PDF.
      # If the PDF is committed in the repo, you can delete this step.
      - name: Build the PDF
        run: |
          mkdir -p dist
          # e.g. your doc tooling outputs dist/release-notes.pdf
          ls -lh dist/release-notes.pdf

      - name: Install FlipLink CLI
        run: npm install -g fliplink-cli

      - name: Create and publish flipbook
        id: flipbook
        env:
          FLIPLINK_API_KEY: ${{ secrets.FLIPLINK_API_KEY }}
        run: |
          ID=$(fliplink flipbook create ./dist/release-notes.pdf \
            --title "Release ${{ github.event.release.tag_name }}" \
            --name "release-${{ github.event.release.tag_name }}" \
            --json | jq -r '.ID')

          fliplink flipbook publish "$ID"

          URL=$(fliplink flipbook share-link "$ID" --json | jq -r '.URL')

          echo "id=$ID" >> "$GITHUB_OUTPUT"
          echo "url=$URL" >> "$GITHUB_OUTPUT"
          echo "Published flipbook: $URL"

      - name: Comment the URL on the release
        uses: actions/github-script@v7
        with:
          script: |
            const url = "${{ steps.flipbook.outputs.url }}";
            const release = context.payload.release;
            await github.rest.repos.updateRelease({
              owner: context.repo.owner,
              repo: context.repo.repo,
              release_id: release.id,
              body: `${release.body || ""}\n\nFlipbook published: ${url}`
            });

作成ステップについていくつか補足します。

• fliplink flipbook create ./path.pdfはPDFをアップロードし、新しいフリップブックを返します。--jsonを付けると生のレスポンスが得られ、jq -r '.ID'でIDを取り出せます。
• fliplink flipbook publish "$ID"でそれを公開します。（フリップブックを作成しただけでは公開されません—公開は別の、明示的なステップです。）
• fliplink flipbook share-link "$ID"は公開ビューアのURLを返し、同じようにjqで取得します。
• idとurlを$GITHUB_OUTPUTに書き出すことで、後続のステップからsteps.flipbook.outputs.urlとして参照できます。

ここで使っているのは、ドキュメント化されたCLIコマンドと--jsonフラグだけです。CLIがラップしていない操作が必要なら、fliplink apiという抜け道に降りていけます—全機能についてはCLIドキュメントを、すべてのエンドポイントについてはAPIリファレンスをご覧ください。

🚀

FlipLinkを無料で試す

PDFを数秒で変換。登録もクレジットカードも不要 — アップロードするだけです。

Drop your PDF here or click to browse

最大40MB

$39 からの有料プランなら、上限が 150 MB に広がります。

ステップ3 — URLをリリースにコメントする

URLを目に触れさせるいちばんすっきりした方法は、リリース自体にコメントすることです。上のactions/github-scriptステップがそれを行います。GitHub CLI（ghはGitHubホストランナーにプリインストール済み）のほうが好みなら、この一行でも同じことができます。

      - name: Comment via gh
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
          gh release view "${{ github.event.release.tag_name }}" \
            --json body --jq '.body' > old-body.txt
          printf '\n\nFlipbook: %s\n' "${{ steps.flipbook.outputs.url }}" >> old-body.txt
          gh release edit "${{ github.event.release.tag_name }}" \
            --notes-file old-body.txt

これはフリップブックのリンクをリリースノートに追記するので、みんなが変更履歴を読むまさにその場所にリンクが表示されます。チームの習慣に合うほうを選んでください—どちらも同じsteps.flipbook.outputs.urlからURLを読み取ります。

キャッシュとパフォーマンスのメモ

このワークフローを高速かつ予測どおりに保つためのポイントをいくつか挙げます。

• npmをキャッシュする。 リポジトリにロックファイルがあるならsetup-nodeステップにcache: npmを追加しましょう—繰り返し実行する際に、CLIやPDFツールのインストールが速くなります。
• レート制限に注意する。 FlipLink APIはキーごとに毎分300リクエストまで許可しています。1回のリリースで公開するフリップブックは1つなので上限には程遠いですが—1つのジョブで多数のPDFに展開する場合は、呼び出しの間隔を空けてください。
• 失敗時に分岐する。 CLIは成功時に0、リクエスト／HTTPエラー時に1、アプリケーションエラー時に2を終了コードとして返します。runブロック内の各コマンドは失敗し得るため、何か問題があればステップははっきりと失敗します—これはCIでまさに望ましい挙動です。
• トリガーを絞り込む。 types: [published]は、実際にリリースを公開したときに一度だけワークフローが走ることを意味します—下書きや公開前の編集では走りません。これにより、うっかり重複したフリップブックを作ってしまうのを防げます。

まとめ

ワークフローファイル1つとリポジトリのシークレット1つで、リリースのたびに公開フリップブックが出荷され、そのリンクがチームに投稿されるようになりました—手作業はゼロです。ここからフォルダ全体を一括変換したり、jqでより手の込んだパイプラインをスクリプト化したり、ロジックをAIエージェントに移したりできます。どのパターンも、同じCLIの上に積み重なっています。

関連記事

• FlipLink CLIをはじめる
• CI/CDパイプラインでフリップブック公開を自動化する
• CLIドキュメント
• FlipLink APIリファレンス
• 自動化とは？（用語集）