GitHubの活用事例(弁護士ドットコム株式会社)
弁護士ドットコム株式会社 / 櫛部勇気
メンバー / SRE / 従業員規模: 501名〜1,000名 / エンジニア組織: 101名〜300名
| 利用プラン | ツールの利用規模 | ツールの利用開始時期 |
|---|---|---|
GitHub Enterprise | 101名〜300名 | 2024年10月 |
| 利用プラン | GitHub Enterprise |
|---|---|
| ツールの利用規模 | 101名〜300名 |
| ツールの利用開始時期 | 2024年10月 |
導入の背景・解決したかった問題
導入背景
当社では、長らく GitLab Self-Managed を開発基盤として利用してきました。開発組織やリポジトリ数の増加に伴い、インフラ運用、アップデート、脆弱性対応などの負荷が大きくなっており、最終的に GitHub Enterprise Cloud への移行を実施しました。
移行の詳細は当社の Creators Blog の記事「800リポジトリを1年半で GitLab Self-Managed から GitHub Enterprise Cloud へ移行した話」でも紹介しており、本記事では移行後の GitHub 活用、特に サプライチェーン攻撃への対策も意識したセキュリティ運用 を中心に紹介します。
ツール導入前の課題
主な課題は、GitLab Self-Managed の運用負荷が高く属人化しやすいことと、CI/CD・権限設定・セキュリティ設定がリポジトリごとに分散し、横断的に把握・統一しづらいこと でした。
- GitLab 本体やインフラの継続的な運用負荷
- CI/CD や権限設定の標準化
- GitHub 上でシークレット混入を検知・防止できる状態の整備
- 脆弱性検知における有効化状況や運用のばらつき
どのような状態を目指していたか
開発チームが日常的に利用する基盤を GitHub に集約し、SRE や Platform Engineering を含む横断チームが全体方針と標準化を支援できる状態を目指しました。
リポジトリ管理や CI/CD だけでなく、Secret scanning、Dependabot Alerts などのセキュリティ機能も同じ基盤で扱い、設定状況を Organization 単位で見える化したいと考えていました。
比較検討したサービス
- GitLab Self-Managed
- GitLab SaaS
比較した軸
- インフラ運用の負荷を下げられるか
- CI/CD の標準化を進めやすいか
- セキュリティ機能を開発フローに組み込みやすいか
- SRE や Platform Engineering を含む横断チームが支援しやすいか
選定理由
GitLab SaaS も、Self-Managed の運用負荷を下げられる有力な選択肢でした。既存の GitLab 利用体験を大きく変えずに移行できる点は、GitLab SaaS の大きな利点でした。 一方で、今回の移行では既存運用の延長ではなく、CI/CD、権限設定、セキュリティ運用を含めて開発基盤全体を見直すことを重視しました。
GitHub Enterprise Cloud は、単にリポジトリをホストする場所としてではなく、開発基盤全体を標準化する中心にしやすい と判断しました。開発者の日常的な開発フロー、セキュリティ検知・対応、横断チームによる標準化支援を同じ基盤上で進めやすい点を評価しています。
また、当社では Copilot 関連機能への関心も高まっていました。GitHub の AI 戦略や開発者支援の方向性に期待があったことに加え、検討時に担当営業やエンジニアへ相談しながら移行・運用面の具体的なイメージを持てたことも、GitHub Enterprise Cloud を選定する後押しになりました。また、開発者側にも GitHub を中心とした開発体験への関心があり、移行後の定着や改善を進めやすいと考えました。
導入の成果
改善したかった課題はどれくらい解決されたか
GitLab Self-Managed の運用負荷については、GitHub Enterprise Cloud への移行により、自社で GitLab のインフラや本体アップデートを継続運用する負担を大きく下げることができました。
GitLab Self-Managed では、アップデート対応のたびに事前調査や手順作成、レビュー、作業実施が必要で、月あたり10時間前後の定常的なメンテナンス工数 が発生していました。移行後は、この工数を GitHub 運用の標準化やセキュリティ施策に振り向けやすくなりました。
移行プロジェクト全体では、63チーム、293名の開発者、802リポジトリを対象に、1年半かけて段階的に移行しました。
どのような成果が得られたか
GitHub を起点に、リポジトリ管理、CI/CD、権限設定、セキュリティ設定を同じ基盤上で扱いやすくなりました。
特に大きかった成果は以下です。
- GitLab Self-Managed のインフラ運用や本体アップデートの負担を下げられた
- 802リポジトリを段階的に GitHub Enterprise Cloud へ移行できた
- GitHub を中心に CI/CD や権限設定を見直すきっかけになった
- Security coverage を起点に、リポジトリごとのセキュリティ設定を棚卸しできるようになった
導入時の苦労・悩み
GitLab から GitHub への移行は、リポジトリを移すだけでは完了しませんでした。GitLab CI やその変数、Issue、Merge Request などを GitHub 側でどう扱うかを整理する必要がありました。
各リポジトリの実態は開発チームごとに異なるため、SRE や Platform Engineering を含む横断チームが共通方針を整備し、各開発チームが確認と修正を行う形で進めました。
移行後も、リポジトリごとのセキュリティ設定にばらつきが残るため、継続的な棚卸しと是正の運用が必要でした。
導入に向けた社内への説明
上長・チームへの説明
GitHub Enterprise Cloud への移行は、単なるツール変更ではなく、開発基盤の運用負荷を下げ、CI/CD やセキュリティ運用を標準化する取り組みとして説明しました。各開発チームには、担当リポジトリの確認や、CI/CD・Secrets / Variables 周りの見直しを依頼しました。
活用方法
サプライチェーン攻撃への対策を意識し、セキュリティ運用を中心に Security coverage を起点とした棚卸しと是正の運用 を進めています。Security coverage 機能で、Organization 配下のリポジトリごとにセキュリティ機能の有効化状況を確認しています。
現在は、以下の有効化状況を確認し、未対応のリポジトリは担当チームと対応方針を調整しています。
- Dependabot Alerts
- Dependabot Security Updates
- Code scanning
- Secret scanning
- Push protection
Dependabot Alerts については、横断チームで状況を可視化しつつ、各リポジトリの事情を踏まえてリポジトリオーナーと対応方針を確認しています。重要度の高いアラートや長期間残っているアラートについては、横断チーム側でも状況を把握し、必要に応じてフォローできる運用を整えていきたいと考えています。
また、依存関係更新についても以下を確認し、標準設定として揃えるものとチーム判断に残すものを切り分けています。
- Dependabot や Renovate の利用状況
- Dependabot cooldown の設定状況
- Renovate minimumReleaseAge 相当の設定状況
棚卸しした結果をもとに、リポジトリごとの状況に応じたフォローを進めています。
サプライチェーン攻撃を踏まえた見直し
GitHub Actions で利用するセキュリティツール自体が、サプライチェーン攻撃の対象になる事例もあります。2026年3月の Trivy 関連のサプライチェーン事案では、aquasecurity/trivy-action や aquasecurity/setup-trivy の侵害、悪性 Trivy バイナリの公開が確認されました。
当社でも社内のセキュリティ連携を起点に、GitHub リポジトリを横断して Trivy の利用状況を確認し、GitHub Actions の SHA pinning に関する検証を進めました。一方で、この対応を通じて、GitHub Actions を commit SHA で pin していても、Action 内部で実行時に取得されるバイナリやスクリプトまでは SHA pinning だけでは保証できない、という課題も見えてきました。
このため、Action の参照方法だけでなく、実行されるツール、取得されるバイナリ、Actions log / Audit log で確認できる範囲を含めて、CI/CD 全体の信頼境界を見直す必要があると考えています。
よく使う機能
Secret scanning と Push protection は、シークレット混入を早い段階で検知・防止するために利用しています。Dependabot Alerts は依存関係の脆弱性検知に利用しています。
今後は reusable workflow を活用し、複数リポジトリに共通するセキュリティチェックを集約していくことも検討しています。
ツールの良い点
開発者が日常的に利用する Pull Request や Actions と、セキュリティ検知・対応を同じ基盤で扱えることです。
Organization 単位で設定状況を確認できるため、全体の棚卸しや未対応リポジトリへのフォローを進めやすい点を評価しています。
ツールの課題点
GitHub のセキュリティ機能は便利ですが、有効化すればすぐに運用が完成するわけではありません。
実際に当社でも Secret scanning alerts や Dependabot Alerts で検知が発生しており、検知後の対応フローや優先度付けを含めた運用整備が課題として見えています。Dependabot や Code Security は、開発チームのレビュー負荷や CI の安定性も踏まえて運用する必要があります。
ツールを検討されている方へ
GitHub Enterprise Cloud は、リポジトリ管理だけでなく、CI/CD とセキュリティ運用を同じ基盤で整えたい組織 にとって有力な選択肢だと思います。
大規模に導入する場合は、移行そのものよりも、移行後にどのような標準運用を作るかが重要です。誰が棚卸しし、どの範囲を強制し、どこをチーム判断にするのかを決めておくと進めやすいと考えています。
今後の展望
以下に取り組む予定です。
- Code Security / Dependabot の運用整理
- 依存関係更新における cooldown や minimumReleaseAge 相当の設定標準化
- セキュリティチェック用 reusable workflow の整備
- Org Ruleset と組み合わせたセキュリティチェック適用方針の整理
Code Security は、重要度の高いリポジトリから検知内容や運用負荷を確認し、段階的に導入を進める方針です。 reusable workflow と Org Ruleset については、開発体験を損なわない形でセキュリティ上必要なチェックをどの範囲に適用するか、開発チームとも調整しながら検討していきます。
弁護士ドットコム株式会社 / 櫛部勇気
メンバー / SRE / 従業員規模: 501名〜1,000名 / エンジニア組織: 101名〜300名
よく見られているレビュー
弁護士ドットコム株式会社 / 櫛部勇気
メンバー / SRE / 従業員規模: 501名〜1,000名 / エンジニア組織: 101名〜300名


