GitHub Issueを起票したら、あとはClaude Codeが勝手に調べて実装してPRまで作ってくれたら――。毎回ターミナルを開いてセッションを立ち上げ、同じような指示を打ち込むたびに、そう思ったことはないでしょうか。
「Slackで指示したらリモートでSkillが動いてくれたら楽なのに」
「Issueにラベルを付けるだけで調査が始まってほしい」
そんな要望、ありませんか？
- Issue起票→自動処理を実現する4つの手段とその向き不向き
- 実際に動いている「ラベルを付けるとAIが無人でリサーチしPRを作る」仕組みの中身
- 個人開発者が現実的に選べる組み合わせはどれか
そもそも何を実現したいのか
「Issue起票→自動処理」と「Slackから遠隔実行」は、似ているようで狙いが少し違います。前者は人が起票したタスクを、人が張り付いていなくても処理してほしいという無人実行への要望で、後者はターミナルを開けない場所からでもClaude Codeに指示を出したいという遠隔操作への要望です。
筆者は個人でこのwrite-blogリポジトリを運営していて、記事の執筆・投稿・内部リンク管理などをClaude Code用のカスタムSkill（`.claude/skills/`配下に置く独自の手順書）でこなしています。Skillが増えるほど、「これは自分がセッションを開かなくても、Issueが起票された時点で自動的に走らせたい」という場面が目につくようになりました。実際に手を動かして4つを試すと、動くか動かないかより先に、そもそもどのプランで足止めを食うかで選択肢が絞られていきました。
比較の軸は3つです。①どんなきっかけ（トリガー）で起動するか、②どのプランで使えるか、③リポジトリの.claude/skills/に実際にアクセスできるか。3つ目が地味に重要で、Skillベースで運用している人ほど「動くには動くが、Skillの中身までは読めない」という落とし穴にはまりがちです。
選択肢1: GitHub Actions（claude-code-action）
公式が提供しているanthropics/claude-code-actionを使い、GitHub Actionsのワークフロー内でClaude Codeを動かす方法です。リポジトリをチェックアウトした状態で実行されるので、.claude/skills/もリポジトリ内の他ファイルと同じように普通に読めます。プランを問わずAPIキー課金で使えるため、個人開発者でも今日から試せる選択肢です。
- Issue/PRコメントの
@claudeメンションで起動できる - プランを問わずAPIキー課金だけで始められる
- リポジトリをそのままチェックアウトするので既存のSkillが無改修で動く
基本形：@claudeメンションに応答する
最小構成は、Issueやプルリクエストのコメントで@claudeとメンションしたときだけ起動するワークフローです。ターミナルで/install-github-appを実行すればGitHub Appの導入とワークフローファイルの用意まで案内してくれるので、セットアップ自体は数分で終わります。筆者のリポジトリにも、Issueコメント・PRレビューコメント・Issue本文への@claudeメンションで起動する基本形のワークフローを置いています。
応用：ラベル起動でSkillを無人実行しPRまで作る
実際に運用していてこの基本形の一歩先まで踏み込んだのが、write-blogのナレッジ管理の場面です。ナレッジ管理用の別リポジトリ（knowledge-wiki、Obsidian Vault）に対する調査を、wiki-research-bridgeというSkillで行っています。ただ、調査した内容を毎回自分の手でナレッジ化するのを忘れがちで、「リサーチしたのに結局wikiに追加されないまま放置される」ことが何度かありました。そこで、Issueにwiki-researchというラベルを付けるだけで、この調査からナレッジ化までを無人で最後までやり切ってくれるワークフローを作りました。
ポイントは、1つのワークフロー内で2つの別リポジトリを同時にチェックアウトしていることです。write-blog（このリポジトリ自体）とknowledge-wiki（ナレッジベース）をどちらもワークフロー内のディレクトリにcloneし、Skill側にはknowledge-wikiのパスを環境変数で渡します。こうすると、Skillからすれば「ローカルに2つのリポジトリが並んでいて、自分のマシンで実行しているのと同じ」状態になり、Skillの中身を一切書き換えずにCI環境でも動かせます。
つまずいた点：別プライベートリポジトリの認証
実際に組んでみて一番苦労したのは、この「もう1つの別プライベートリポジトリをチェックアウトする」部分の認証でした。ワークフローが動いているのはwrite-blogのGitHub Actions上なので、標準のGITHUB_TOKENではknowledge-wiki（別のプライベートリポジトリ）にはアクセスできません。knowledge-wiki用に個人アクセストークンを発行し、write-blog側のリポジトリシークレットとして登録した上で、そのトークンをactions/checkoutのチェックアウトステップと、後段でPRを作成するghコマンドの両方に渡す必要がありました。1つのワークフローで複数リポジトリを横断する構成は、単一リポジトリ内で完結する@claudeメンション対応よりも一段階、権限設計を意識する必要があります。
安全策：無人実行はmain直コミットにしない
もう1つ最初の設計段階で決めたのが、「無人実行の結果を、いきなりknowledge-wikiのmainブランチへ直接コミットさせない」というルールです。人が張り付いていない状態でAIに書き込ませる以上、ナレッジベースの品質を落とすような追記が紛れ込んでも、動いている最中には誰も気づけません。そこで、ワークフロー内では必ず新しいブランチを切ってコミットし、プルリクエストを作成するところまでで止め、最後に元のIssueへPRのリンクをコメントする設計にしました。実際に運用してみて、この点で特にトラブルは起きておらず、想定通りに動いています。人の目を通す一手間を挟むだけで、無人実行の安心感がかなり変わります。
あたまIssueにラベルを1つ付けるだけで、リサーチからPR作成、元Issueへの報告まで一気に終わっている。最初にこの一連の流れが動いたときは、正直「ここまでやってくれるのか」と少し感動しました。
選択肢2: Routines——個人開発者でも手が届くスケジュール実行
Routinesは、cronのようなスケジュールやWebhookをきっかけにClaude Codeを起動できる公式機能です（claude.ai/code/routines、またはCLIの/scheduleから作成）。GitHub Actionsのようにワークフローファイルを自分で書く必要がなく、実行環境もAnthropic側が用意してくれるため、サーバーやランナーの管理が要りません。実行対象のリポジトリをcloneする設定さえしておけば、.claude/skills/も普通に読み込めます。
大きいのは、Pro・Maxプランでも使える点です（Team・Enterpriseも対応、1日あたりの実行回数に上限あり）。「毎晩、公開済み記事の内部リンクが不足していないか棚卸ししてほしい」「週次でSNS運用の進捗を確認してほしい」といった定期実行のニーズには、GitHub Actionsを自分で組むよりRoutinesの方が手早く始められます。GitHub Issueをきっかけにした即時対応が要らないなら、まずここから試すのが現実的です。
選択肢3: Claude in Slack（Claude Tag）——個人には現状ハードルが高い
「Slackで@Claudeとメンションすれば、チャンネルの中でそのままClaude Codeに指示が出せる」というのがClaude Tag（Claude in Slack）です。チャンネルタグ付け・DM・AIアシスタントパネルの3つの経路で使えて、体験としては非常に魅力的です。
ただし、Claude TagはTeam・Enterpriseプラン限定のベータ機能で、しかもTeamプランは最低10有料席から、という制約があります。個人開発者やごく小規模な運営では、そもそもプランの土俵に乗れません。
- Team/Enterpriseプラン限定のベータ機能
- Teamプランは最低10有料席から
- 個人・数名規模の運営では現状プランの土俵に乗れない
write-blogは筆者一人で運営しているため、この時点でClaude Tagは選択肢から外れます。正直に書くと、実際にはまだ触っておらず、公式ドキュメントベースの調査止まりです。チームで複数人が運営していて、すでにTeam/Enterpriseプランに10席以上乗っているなら検討価値がありますが、個人・小規模運営の現実解ではない、というのが今のところの結論です。
選択肢4: Agent SDK自前実装——自由だが工数がかかる
Claude Agent SDKを使えば、GitHub Actionsの枠組みにもRoutinesの制約にも縛られず、自分の好きなトリガー（独自のWebhookエンドポイント、社内ツールとの連携など）からClaude Codeのエージェントループを起動できます。実はclaude-code-action自体もこのAgent SDKの上に構築されており、ローカルでできることは基本的にそのままパイプラインの中でも再現できます。
一方で、実行環境（サーバー・コンテナ）の用意、認証情報の管理、Skillファイルへのパス解決などをすべて自分で設計・実装する必要があり、工数は4つの中で最も大きくなります。GitHub ActionsでもRoutinesでも表現できない独自のフロー（例えば社内チャットツールや自社サービスの管理画面からの起動）が必要になったときに検討する、最後の選択肢と位置づけるのが現実的です。
結局どれを選べばいいか
迷ったら、次の順番で検討するのがおすすめです。
| やりたいこと | おすすめ | 理由 |
|---|---|---|
| Issue起票やPRコメントをきっかけに動かしたい | GitHub Actions（claude-code-action） | プラン不問・リポジトリの.claude/skills/がそのまま読める |
| 時間・曜日ベースで定期実行したい | Routines | Pro/Maxでも使え、ワークフローYAMLの管理が不要 |
| Slackから会話的に指示したい | Claude Tag | Team/Enterprise・10席以上の組織向け（個人には非現実的） |
| 既存3つで表現できない独自フローがある | Agent SDK自前実装 | 自由度は最大だが実装・運用の工数も最大 |
個人・小規模でSkillベースの手順書を既に持っているなら、まずGitHub Actionsで@claudeメンション対応を組み、慣れたら「特定のラベルで無人実行する」応用パターンに広げるのが無理のない順序です。定期実行が要る場面が出てきた時点でRoutinesを足せば、無人実行の入口（Issue起票／スケジュール）を両方押さえられます。
まとめ
Claude CodeでGitHub Issueを自動処理する方法は、GitHub Actions（claude-code-action）・Routines・Claude in Slack（Claude Tag）・Agent SDK自前実装の4つに整理できます。個人開発者にとって現実的な起点はGitHub Actionsで、リポジトリをチェックアウトするだけで.claude/skills/に置いた既存のSkillをそのまま無人実行できる点が大きな強みです。write-blogでの実運用でも、ラベル1つで調査からPR作成まで一気通貫にできる仕組みが、実際に手間を減らしてくれています。Slack連携（Claude Tag）は魅力的ですが、Team/Enterprise・10席以上という制約があるため、個人・小規模運営はまずGitHub ActionsとRoutinesの組み合わせから試すのが現実的です。
あたま自分のリポジトリでSkillを運用しているなら、まず`@claude`メンション対応から試してみてください。動き出す感覚がつかめたら、ラベル起動の無人実行にも自然と手が伸びるはずです。
関連記事
コメント