こんにちは、白々さじきです。
飲み会の日程調整ツールをCloudflare Workers + Hono +
D1で作るこの検証プロジェクト。今回は開発中の雑談から生まれた「Issue 作成を /issue の一言で済ませる仕組み」を作りました。
なぜ Issue 作成を自動化したかったのか
きっかけはちょっとした出来事でした。
Claude Code とやり取りしている最中に「あ、これ別タスクに切り出したほうがいいな」と気づくことがあります。そのとき「じゃあ Issue 作って」と頼んだところ、こんな返事が来ました。
gh CLI がインストールされていないため、GitHub Issue を直接作成できません。
その瞬間に逆転の発想が生まれます。「gh CLI さえあれば Claude が Issue を作れる」。
もう一つ、Issue の質がバラバラになる問題もありました。手で書くと「背景」を省いたり「完了条件」を忘れたり、Issue によって粒度がバラバラになります。Claude に任せればフォーマットを統一できます。
整理するとこういう課題でした。
- gh CLI が未インストールで Claude が Issue を作れない
- Issue の書き方の粒度が毎回ブレる
- 「別タスクだな」と気づいた瞬間に即切り出せない
gh CLI のセットアップ
Windows なので winget でインストールします。
winget install GitHub.cliインストール後、認証を通します。
gh auth login
GitHub.com → HTTPS → ブラウザで認証、の流れです。成功するとこう表示されます。
✓ Authentication complete.
✓ Configured git protocol
✓ Logged in as sirajirasajikiこれで Claude に「gh issue create してください」と頼める状態になりました。実際にいくつか手動で依頼して Issue を作った後、「毎回頼むのも面倒だな」と思い自動化を検討します。
自動化の方法を3案検討した
案A：メモリに保存する
Claude Code にはセッションをまたいで記憶を保持する「メモリ」機能があります。Issue フォーマットをメモリに書いておく方法です。
却下理由：メモリは忘れる可能性があります。別の情報で上書きされたり、将来のセッションで読み込まれなかったりすると、フォーマットが崩れます。
案B：フックを使う
Claude Code には hooks という設定があり、ツール実行などのイベントに応じてシェルコマンドを実行できます。
却下理由：hooks はシェルコマンドを実行するものです。「この会話の内容を読んで Issue の本文を生成する」という動的な処理には使えません。フォーマットが固定された単純な操作には向きますが、今回はやりたいことと噛み合いません。
案C：カスタムスラッシュコマンドを作る（採用）
Claude Code には .claude/commands/ 配下に Markdown ファイルを置くことで、独自の /コマンド名 を定義できます。ファイルの中身はClaude への指示文です。つまりシェルコマンドではなく Claude のプロンプトとして動作します。
これなら「会話を読んで Issue を推測して、確認後に gh issue create を実行する」という流れが書けます。
カスタムスラッシュコマンド /issue の実装
配置場所によってスコープが変わる
| 配置場所 | スコープ |
|---|---|
~/.claude/commands/issue.md |
すべてのリポジトリで使えるグローバル版 |
.claude/commands/issue.md |
そのプロジェクト限定のプロジェクト版 |
同名コマンドが両方に存在する場合、プロジェクト版が優先されます。エラーにはならず、プロジェクト内ではプロジェクト版が使われ、他リポジトリではグローバル版が使われます。
今回はブログ記事の比較用として両方作り、プロジェクト版に差分を持たせました。
グローバル版（~/.claude/commands/issue.md）
会話の流れからバグ・課題・改善案を読み取り、GitHub Issue の下書きを作成してください。
## 手順
1. 直近の会話を読んで、Issue にすべき内容を特定する
2. 以下のフォーマットで下書きを作成し、ユーザーに提示する
3. ユーザーが確認・承認したら `gh issue create` で作成する
## Issue フォーマット
**タイトル:** （端的に課題を表す一文）
**本文:**
## 背景
（なぜこの課題が生まれたか・どんな問題が起きているか）
## やること
（具体的な対応内容を箇条書き）
## 完了条件
（何ができていれば完了とみなすか）
## 注意事項
- 下書きを提示した後、必ずユーザーの承認を待ってから `gh issue create` を実行すること
- リポジトリは現在の git リポジトリから自動判定する
- タイトル・本文が会話から読み取れない場合はユーザーに質問する実際にこれでやってみるとこんなIssueが作成されます。
プロジェクト版（.claude/commands/issue.md）との差分
グローバル版から2点変えています。
① タスク概要セクションを追加
背景の前に概要を1段はさむことで、Issue を一覧で見たときに内容がすぐ分かります。
② アサインを自分に固定
個人プロジェクトなので常に自分がアサインされます。--assignee sirajirasajiki を毎回指定する手間がなくなります。
実際に使ってみる
会話の途中で /issue と打つだけです。Claude が会話を読んで下書きを生成します。
## タスク概要
この記事のブログ下書きを作成する
## 背景
gh CLI の導入と Claude Code のカスタムスラッシュコマンド機能を使って、
会話の流れから GitHub Issue を自動作成する仕組みを構築した。
この内容をテックブログ記事としてまとめる。
## やること
- 記事の構成を決める
- 下書きを2ファイルセットで作成する
- drafts/weekly/2026-05-03/{記事名}.md
- drafts/weekly/2026-05-03/wordpress/{記事名}-wp.html
## 完了条件
- .md と wordpress/*.html の2ファイルが作成されている
- 読者が同じ手順を再現できる内容になっている
「OK」と返すと gh issue create が実行されます。Issue #11 として作成されました。
おまけ：Issue の編集も gh CLI でできる
gh CLI には gh issue edit というコマンドもあります。今回、Issue #10 にフォルダ命名規則の追記が必要になったとき、ブラウザを開かずそのまま Claude に編集を依頼できました。
gh issue edit 10 --body "新しい本文"--title でタイトル変更、--add-label でラベル追加なども可能です。
gh CLI を入れておくと Issue の作成だけでなく編集・閲覧・クローズまで Claude との会話の中で完結します。
何が解決できたか
- 摩擦がほぼゼロになった：「別タスクだな」と思った瞬間に
/issueを打てば切り出せます。ブラウザを開く必要がありません - フォーマットが自動で統一される：背景・タスク概要・やること・完了条件が毎回揃います
- 会話の流れを中断しない：Issue を作るために別の画面に移る必要がなく、会話の文脈がそのまま使われます
つまずき・教訓
① コマンド追加後は新しいスレッドが必要
.claude/commands/ にファイルを追加しても、すでに開いているスレッドでは /issue が認識されません。Claude Code はスレッドの起動時にコマンドを読み込むためです。
新しいスレッドを開始すれば使えます。ただし新スレッドで以前の会話履歴を呼び出せば、文脈を引き継いだまま /issue を使えます。
教訓：カスタムスラッシュコマンドを追加したら、一度スレッドを開き直す。
② hooks は動的コンテンツの生成に使えない
hooks はシェルコマンドを実行するものです。「会話を読んで Issue の内容を推測する」といった動的な処理はできません。「特定のファイルが保存されたら自動フォーマット」のような静的な操作に向いています。
教訓：hooks は静的な自動化、カスタムスラッシュコマンドは Claude に考えさせたい自動化、と使い分ける。
③ この記事を書かせたら Claude がフォルダを間違えた
記事の下書き作成を依頼したところ、drafts/weekly/2026-05-03/ という新しいフォルダを作ってしまいました。実際には 5/2（金）と 5/3（土）は同じ週なので、drafts/weekly/2026-05-02/ に入れるべきでした。
原因は drafts/weekly/ のフォルダ命名規則が CLAUDE.md に書かれていなかったことです。Claude は「今日の日付でフォルダを作る」という判断をしましたが、このプロジェクトの慣習は「週単位でフォルダを切り、同じ週の記事は同じフォルダに入れる」です。
手動でファイルを移動し、Issue #10（CLAUDE.md へのルール追記）にフォルダ命名規則の追記も含めることにしました。
教訓：ファイルの配置ルールは CLAUDE.md に書かないと Claude が毎回違う判断をする。「暗黙の慣習」はゼロにする。
まとめ
gh CLI のインストールという偶然の気づきから、カスタムスラッシュコマンドによる Issue 自動化まで一気に作りました。
.claude/commands/ に Markdown を置くだけでコマンドが作れるのは想像より手軽でした。「Claude に考えさせてから実行する」処理はスラッシュコマンドとの相性が良く、他にも応用できそうです。
今回の仕組みはグローバルに置いているので、このプロジェクト以外でも使えます。
次にやること
サポートのお願い
下記リンクからお買い物いただけると、ブログ運営のための費用が増え、有料サービスを利用した記事作成が可能になります。ご協力よろしくお願いします！
コメント