🤖
PR作成時のルーティン、全部やってくれる“神後輩”をGitHub Actionsで作った話

s19514tt
2025/03/31に公開
GitHub
GitHub Actions
tech
私たちのチームでは、Notionでタスク管理をして、開発作業はGitHubで行うというスタイルを取っています。

以前は、定例ミーティングのたびに担当者にタスクの進捗を確認し、その内容に応じてNotion側のタスク状態を手動で更新するなど、GitHubとNotionをそれぞれ別々に管理していました。

しかし最近になって、これらのツールを連携させることで大きなメリットが得られることに気づきました。
具体的に連携によって得られた利点は、以下のようなものです：
GitHubでPull Requestを作成すると、Notion側のタスクステータスが自動的に「Review」に切り替わる
PRがマージされると、自動でステータスが「Done」に更新される
タスクの進行状況が常に最新の状態で保たれ、確認漏れやステータス更新の手間がなくなる
このように、GitHubとNotionを連携させることで、手動操作を最小限にしつつ、タスクの状態を正確に保つことができるようになりました。

 課題の背景と自動化の必要性当然ですが、GitHubとNotionを連携しただけで、Pull Request（PR）の状態に応じてNotionのタスクのステータスが自動で切り替わるわけではありません。

この連携システムが正しく機能するためには、GitHub上のPRとNotion上のタスクが明確に紐付けられている必要があります。
Notionでは、GitHub PRとタスクとの連携において「PRのタイトルにタスク番号（例：TASK-123）が含まれていること」がタスクとPRを自動で紐付ける条件になっています。

そのため、PRタイトルに対応するタスク番号を含める必要があるのですが、これを毎回手動で行うのは手間がかかります。
実際の運用では、私自身がPRタイトルにタスク番号をつけ忘れることが頻繁にあり、定例ミーティングのたびに“神後輩”から「またタスク番号忘れてますよ〜」と指摘を受けるのが恒例になっていました。
さらに、PRに付けるべき「feature」や「fix」などのラベルのつけ忘れも起きがちでした。
このように、PR作成時のルーティンが面倒で、作業ミスが多発している状況にありました。

こうした問題を根本的に解決し、GitHubとNotionの連携をより安定して運用するために、GitHub Actionsを使って

PR作成時にタイトルやラベルを自動的に整える仕組み（通称：神後輩システム）を構築しました。

 ブランチ命名規則この自動化を成功させる鍵は、一貫したブランチ命名規則にあります。

私たちは、ブランチ名に以下のようなフォーマットを採用することにしました：
<PRのカテゴリ>/<PRの種類>/<Notionタスク番号>-<説明>
具体例としては、以下のようなブランチ名になります：
frontend/feature/123-add-login-button
backend/fix/789-fix-api-error
この命名規則には、次のような情報が含まれています：
カテゴリ（category）:
例: frontend または backend
どの領域の作業かを示し、対応するラベル（例：frontend や backend）の自動付与に利用されます。
作業種別（type）:
例: feature、fix、release、tmp など
作業内容の種類を表し、適切なラベル付け（例：feature や fix）に使用されます。
Issue番号（issue-number）:
例: 123-456
ハイフン区切りで複数のIssue番号を含むことが可能です。これを元に、PRタイトルに「TASK-123, TASK-456」の形式で自動付与され、Notionとの正確な連携をサポートします。
ブランチの説明（description）:
例: add-login-button や fix-api-error
作業内容を端的に表現し、どのような変更が行われるかを示します。
さらに、VSCodeを利用している場合は、settings.jsonに以下のように記述することで、

ブランチ名がこの命名規則に反している場合にエラーを表示し、誤った命名を事前に防止する仕組みを導入しています。
setting.json
{
  ...
  "git.branchValidationRegex": "^(backend|frontend|ci)/(feature|fix|release|tmp)/[0-9]+-[a-z0-9-]+$",
  ...
}
実際にPRを作成すると、命名規則にあっていない場合のみエラーが出ていることがわかると思います。


命名規則通りではない時


命名規則通りの時
このように、ブランチ名に一貫性を持たせることで、後続の自動化処理が正確に動作し、Notionとの連携も安定して行われるようになります。

 GitHub Actionsによる自動化以下は、PR作成時にタイトルへIssue番号を追加するためのGitHub Actionのコードです。

コード中に詳細なコメントを入れて、各処理の意味を明示しています。
assign-notion-task.yml
name: Assign Issue Number to Pull Request Title
on:
  pull_request:
    types: [opened, reopened]

env:
  GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

jobs:
  release_edit_title:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - name: Edit Pull Request Title
        run: |
          # 1. PRのブランチ名を取得します。
          branch_name=`echo ${{ github.event.pull_request.head.ref }}`

          # 2. ブランチ名が規定の命名規則に合致するかをチェックします。
          if [[ $branch_name =~ ^([a-z]+)\/(feature|fix|release|tmp)\/([0-9]+(-[0-9]+)*)-[^\/]+$ ]]; then
              # 3. 正規表現でキャプチャした番号部分（例: 123-456）をハイフンで分割し、配列に格納します。
              IFS='-' read -ra ADDR <<< "${BASH_REMATCH[3]}"
              issue_numbers=""

              # 4. 配列の各要素をWF-形式に変換し、カンマ区切りで連結します。
              for i in "${ADDR[@]}"; do
                  if [ -z "$issue_numbers" ]; then
                      issue_numbers="WF-$i"
                  else
                      issue_numbers="$issue_numbers, TASK-$i"
                  fi
              done

              # 5. 元のPRタイトルを取得し、Issue番号を先頭に付加した新しいタイトルを作成します。
              title=`echo ${{ github.event.pull_request.title }}`
              gh pr edit ${{ github.event.pull_request.number }} --title "[$issue_numbers] $title"
          fi

 このコードがやっていることこのGitHub Actionは、Pull Requestが作成または再オープンされたときに自動で実行され、以下の流れで動作します。
まず、PRのブランチ名を取得し、正規表現を用いて命名規則に沿っているかを確認します。たとえば、frontend/feature/123-add-login-button の場合、正規表現により「123」という数字の部分が抽出され、これがPRタイトルに必要なIssue番号となります。
次に、抽出された番号が複数ある場合（例：123-456）はハイフンで分割され、個々の番号が配列に格納されます。各番号に対して「TASK-」というプレフィックスを付与し、複数の番号が存在する場合にはカンマで区切り、一つの文字列（例：TASK-123, TASK-456）として整形します。
最後に、元のPRタイトルを取得し、先ほど整形したIssue番号を先頭に追加した新しいタイトルを生成します。gh pr edit コマンドを用いてPull Requestのタイトルを自動で更新することで、手動による記載ミスを防ぎ、Notionとの正確な連携を実現しています。

 ラベルも自動付与できます同様に、ブランチ名からカテゴリ（frontend／backend）や作業種別（feature／fix）を判別し、Pull Requestにラベルを自動で追加するGitHub Actionも用意しています。
assign-labels.yml
name: Add Labels to Pull Request
on:
  pull_request:
    types: [opened, reopened]

env:
  GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

jobs:
  add_labels_to_pr:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - name: Add labels to PR
        run: |
          branch_name=`echo ${{ github.event.pull_request.head.ref }}`

          # カテゴリごとのラベル付与
          if [[ $branch_name =~ ^(backend)\/ ]]; then
              gh pr edit ${{ github.event.pull_request.number }} --add-label backend
          elif [[ $branch_name =~ ^(frontend)\/ ]]; then
              gh pr edit ${{ github.event.pull_request.number }} --add-label frontend
          fi

          # 作業種別ごとのラベル付与
          if [[ $branch_name =~ \/fix\/ ]]; then
              gh pr edit ${{ github.event.pull_request.number }} --add-label fix
          elif [[ $branch_name =~ \/feature\/ ]]; then
              gh pr edit ${{ github.event.pull_request.number }} --add-label feature
          fi

 Notionとの連携もより確実に以上のActionを実行することによりPull Requestのタイトルに TASK-123 のような形式でIssue番号をPRのタイトルに含めてくれるため、Notion側では自動でタスクとひも付けが行われます。
ただし、ただPRとタスク連携するだけでは意味がないため、事前にNotion側で以下のようにGitHubのPRのステータスに合わせてNotionのタスクのステータスを変更する設定を行なってください。
この連携により、以下のようなステータス更新がNotion側で自動的に反映されます：
PR作成 → 「Review」(以下に注意点あり)
Review完了 → 「Approved」
Merge → 「Done」
また、NotionのワークスペースとGitHubの連携方法など、NotionとGitHubの連携についてもっと詳しく確認したい方はこちらのNotionのドキュメントをご覧ください。

 実際にPRを立ててみる実際に命名規則に従ってPRを立ててみましょう。すると以下のようにラベルとタスク名が自動的にPRブランチ名から付与されて、Notionとの連携が完了したこともわかります。

 Notion側の課題とその対応Notion側の仕様としてPRのApproveやMergeといったタイミングでステータスを変更する自動化は以上のやり方でも正常に動作するのですが、

PRが作成（Open）されたタイミングでタスクのステータスをReviewに切り替える処理だけは、

PR作成後にタイトルを変更し、その後にNotionとの連携が行われた場合に限って実行されないという問題があります。
この制限を補うために、私たちはNotion上に別のオートメーションを追加し、GitHubのPR編集時にステータスを手動「Open」で切り替える仕組みも整備しました。

 おわりに今回ご紹介したように、GitHub Actionsを活用することで、Pull Requestに関する細かなルール運用を自動化することができます。

この自動化により、以下のようなメリットが得られます：
PR作成時のタイトルやラベル付けミスが大幅に削減される
Notionとの連携漏れが解消され、タスク管理がスムーズになる
手動での確認や修正作業の工数が削減され、チーム全体の生産性が向上する
さらに、VSCodeのブランチ名バリデーション機能を組み合わせることで、開発の初期段階から命名規則を厳守できる環境を整えることが可能です。

これにより、日常的な運用の手間が軽減され、開発者はより本質的な業務に集中できるようになります。
GitHub Actionsは、ちょっとした工夫で開発フロー全体を大きく改善できる強力なツールです。

今回の事例が、同様の課題を抱える皆さんの参考になれば幸いです。

ぜひ、自身のチームに合わせた自動化の仕組み作りに挑戦してみてください。
ispec inc.Publication
医療領域でソフトウェア開発支援を行うヘルスケアテック企業、ispecです。医療従事者や患者の願いを技術で支えるべく、電子カルテをはじめとしたシステムに向き合い、医療DX事業の開発をリードしています。医療に関わる人が専門性を活かし手を取り合う「ヘルスケアプラットフォーム」を構築し、技術面で協力体制を推進します。
課題の背景と自動化の必要性

ブランチ命名規則

GitHub Actionsによる自動化

このコードがやっていること

ラベルも自動付与できます

Notionとの連携もより確実に

実際にPRを立ててみる

Notion側の課題とその対応

おわりに

Discussion
