https://tech.enechange.co.jp/entry/2026/02/18/161032

こんにちは、VPoTの岩本 (iwamot) です。

ENECHANGE発のOSSであるCollmboでは、GitHub Actionsワークフローや品質チェック機能をもりもりと活用しています。正直「やりすぎ」なくらいです。

ただ、これは意図的なものです。他のOSSやプロダクトのリポジトリではどこまでやれば充分なのか、議論の叩き台にしてもらうのが真の狙いです。

この記事では、Collmboで利用しているワークフローや品質チェック機能をご紹介します。

1. 開発プロセス

DCO (Developer Certificate of Origin)

Collmboでは、コミットにDCO (Developer Certificate of Origin、開発者起源証明書) への署名を必須としています。git commit -s で署名する方法が一般的です。

DCOは、提出するコードがライセンス的に問題ないこと、また、プロジェクトによる公開・配布に同意することを、コントリビューターに宣言してもらう仕組みです。CLA (Contributor License Agreement) と比べ、関係者の負担が少ない特長があります。

署名がなされているかどうかのチェックには、DCO GitHub Appを利用しています。

ただし、署名を忘れた場合でも、署名付きコミットを追加すれば遡及的に適用できるよう、下記内容の .github/dco.yml を配置しています。

allowRemediationCommits:
  individual: true

CI: pip-licenses, ruff, ty, pytest, hadolint, actionlint, ghalint, zizmor, pinact

mainブランチへのpush時と、pull requestの作成時に、以下のようなCIを実行しています。

コマンド	目的
`pip-licenses`	Pythonライブラリのライセンスチェック
`ruff check`	Pythonコードのlint
`ruff format --check`	Pythonコードの整形
`ty check`	Pythonコードの型チェック
`pytest --cov`	Pythonコードのテスト
`hadolint Dockerfile`	Dockerfileのlint
`actionlint`	GitHub Actionsワークフローのlint
`ghalint run`	GitHub Actionsワークフローのlint
`zizmor .github/workflows/`	GitHub Actionsワークフローのlint
`pinact run --check`	GitHub ActionsワークフローのSHAピン留め

pip-licensesでは、コピーレフト系ライセンス（GPL、AGPLなど）のパッケージがCollmboに混入しないようチェックしています。混入すると、プロジェクト全体にコピーレフト条件が及び、MITライセンスでの配布が続けられなくなってしまうからです。

また、特に「やりすぎ」感があるのが、3つのツールで実施している「GitHub Actionsワークフローのlint」です。ただし下記の記事にあるとおり、各ツールは得意分野が異なるため、現状では併用するのがよいと思っています。

zenn.dev

2. リリース

リリースノートの作成

新しいバージョンタグを公開する際には、まずGitHub上でリリースノートを作るところから始めています。

.github/release.yml で以下の内容を定義しており、dependencies タグの付いたpull request（ライブラリ更新）が下方にまとまるよう工夫しています。それ以外のpull request（機能変更）を目立たせたい意図です。

changelog:
  categories:
    - title: 🏕 Features
      labels:
        - '*'
      exclude:
        labels:
          - dependencies
    - title: 👒 Dependencies
      labels:
        - dependencies

下図は実際のリリースノートの例です。

Dockerイメージのビルド、公開

新しいバージョンタグを公開すると、自動的にDockerイメージがビルドされ、GitHubのコンテナレジストリにpushされます。

ワークフローは以下の3つのジョブで構成しています。すべて説明すると長くなってしまうので、ここでは概要のみ記します。

build: amd64とarm64による並列ビルド
merge: マニフェストリストの作成、コンテナレジストリへのpush
sign: イメージへの署名、SBOMの生成

3つめの「イメージへの署名、SBOMの生成」については、次のセキュリティの項で補足します。

3. セキュリティ、品質

イメージへの署名、SBOMの生成

前項のとおり、sign ジョブで、Dockerイメージに署名するとともに、SBOM (Software Bill of Materials) を生成しています。イメージがどこで作られたのか、また、どんなパッケージが含まれるのかを保証する意図です。

署名には、Cosignというツールを利用しています。GitHub ActionsのOIDCトークンに対して発行される短命の証明書が署名に使われるため、秘密鍵の管理が不要なメリットがあります。

- name: Install cosign
  uses: sigstore/cosign-installer@...

- name: Sign the image
  env:
    DIGEST: ${{ needs.merge.outputs.digest }}
  run: |
    cosign sign --yes "${REGISTRY_IMAGE}@${DIGEST}"

また、SBOMは anchore/sbom-action で生成し、イメージのアテステーション（証明情報）としてCosignで添付しています。SBOM保存用のストレージを別に用意する必要がないので便利です。

- name: Generate SBOM
  uses: anchore/sbom-action@...
  with:
    image: ${{ env.REGISTRY_IMAGE }}@${{ needs.merge.outputs.digest }}
    format: spdx-json
    output-file: sbom.spdx.json
    upload-release-assets: false

- name: Attest SBOM
  env:
    DIGEST: ${{ needs.merge.outputs.digest }}
  run: |
    cosign attest --yes --predicate sbom.spdx.json --type spdxjson "${REGISTRY_IMAGE}@${DIGEST}"

イメージの脆弱性スキャン：Trivy

mainブランチへのpush時および日次のタイミングで、Dockerイメージをビルドし、Trivyによる脆弱性スキャンを実行しています。

日次でも実行しているのは、コードに変更がなくても、イメージに含まれるパッケージに新たな脆弱性が見つかる可能性があるからです。

スキャン結果はSARIF形式で出力し、GitHubのSecurityタブにアップロードしています。タブ上で脆弱性の一覧が確認できて便利です。

- name: Build Docker image
  run: |
    docker build -t trivy-scan:${{ github.sha }} .

- name: Run Trivy vulnerability scanner
  uses: aquasecurity/trivy-action@...
  with:
    image-ref: trivy-scan:${{ github.sha }}
    format: 'sarif'
    output: 'trivy-results.sarif'
    scanners: 'vuln'
    version: 'v0.68.2'

- name: Upload Trivy scan results to GitHub Security tab
  uses: github/codeql-action/upload-sarif@...
  if: always()
  with:
    sarif_file: 'trivy-results.sarif'

依存関係の脆弱性チェック：dependency-review-action

pull requestの作成時に dependency-review-action で依存関係の変更をスキャンし、追加・更新されるパッケージに既知の脆弱性がないかチェックしています。

- name: 'Dependency Review'
  uses: actions/dependency-review-action@...
  with:
    comment-summary-in-pr: always
    license-check: false
    show-openssf-scorecard: false

ライセンスチェックを無効化したり、OpenSSFスコアカードを非表示にしたりしているのは、現状のCollmboが依存しているパッケージの場合、サポートが不十分な印象があるためです。ライセンスチェックは「CI」の項で触れたpip-licensesで代替させています。

サポートが不十分な例：bedrock-agentcoreがUnknown扱いになっている

コードの品質チェック：GitHub Code Quality

まだパブリックプレビュー段階にあるGitHub Code Qualityも、試しに有効化しています。コードの信頼性、保守性などの品質をチェックできるツールです。

リポジトリの設定で有効にするだけなので簡単に始められますが、まだまだ発展途上な印象です。特にAIによる分析結果を見ると、AIが最新情報を知らないことによる誤検知が多く感じます。今後の改善に期待します。

4. 依存関係管理

自動更新：Renovate

依存関係の自動更新にはRenovateを使っています。

すでに広く使われているので、こだわっているポイントのみ記します。

Renovateサーバーではなく renovatebot/github-action を利用
- クラウドホスト版を試したが、レート制限に引っかかりやすかった
マイナーバージョンまでの変更は自動マージ
- 承認は下記のようなワークフローで実現している

if: github.event.pull_request.user.login == 'enechange-renovate[bot]'
steps:
  - uses: actions/github-script@...
    with:
      script: |
        await github.rest.pulls.createReview({
          owner: context.repo.owner,
          repo: context.repo.repo,
          pull_number: context.issue.number,
          event: 'APPROVE',
          body: 'Auto approved automated PR'
        })

まとめ

以上、Collmboで活用しているワークフローや品質チェック機能についてご紹介しました。

Collmboだけを考えれば「やりすぎ」かもしれませんが、利用例があることで議論しやすくなる場面も多いのではないかと思います。

みなさんの関係しているリポジトリでも、どこまでやれば充分なのか考えてみていただければ幸いです。