はじめに

NotionでタスクをチェックしてClaude Codeで開発して、GitHubでPR作って、Slackで日報書いて……ってやってたら、気づいたらブラウザのタブが20個開いててもう何がなんだか分からない状態になってました。

「あれ、この作業どこに書いたっけ？Notionだっけ？それともGitHubのIssue？」って毎回探す時間がもったいなくて、かなり疲弊してたんですよね。

そこで、Claude Codeから全部完結できるようにしようと思い立って、GitHubのIssue・ラベル・Projectsを管理できるClaude Codeスキルを作りました。

まだ改良中ですが、ツールを行ったり来たりする回数がかなり減って、けっこう手応えを感じてるので、その話を書いていきます。

なぜGitHub Issues + Claude Codeなのか

NotionとClaude Codeの行き来が煩雑だった

うちのチームでは、Notionで細かいタスクを管理しつつ、開発はClaude Codeでやるっていうフローだったんです。

NotionもClaude Codeから更新はできるんですが、カラムが多かったりページが複雑になってると更新できなかったりして、結局ブラウザを開く羽目になることが多くて。

でもこれがけっこう大変で：

Notionでタスクを確認 → Claude Codeで開発 → またNotionに戻って更新
開発の文脈（どのファイルをいじってたか、どの変更をしたか）がNotionに戻った時に消える
「今どこまでやったっけ？」って毎回思い出すのに時間かかる

これがストレスだったんですよね。

ターミナルから全て完結させたい

Claude Codeで開発してると、ターミナルから離れたくないんですよ。

コードを書いて、テスト実行して、gitコミットして……っていう流れの中で、タスク管理だけ別ツールに飛ぶのが、集中力を削がれる感じがして。

「開発の文脈を保ったままタスク管理したい」っていうのが一番の動機でした。

作ったもの

`/gh`、`/if-vault`、`/daily-report` という3つのClaude Code スキル

GitHubのIssueやProjectsを管理できるスキルと、日報を簡単に書けるスキルを作りました。

`/gh` - 汎用GitHub管理ツール

複数リポジトリ対応で、Issue・ラベル・Projectsの完全CRUD操作ができます。

# Issue一覧
/gh issue list

# ラベル一覧
/gh label list

# Projects一覧
/gh project list

`/if-vault` - main-project専用の簡易版

うちのメインリポジトリ（main-project）専用で、もっとシンプルに使えるようにしたやつです。

# 自分にアサインされたIssue
/if-vault mine

# 優先度別
/if-vault priority:high

# Issue作成
/if-vault create task

`/daily-report` - 日報をターミナルから秒で書く

日報をGitHub Issueのコメントとして記録する専用スキルです。

毎日 GitHub Actions が日報 Issue（タイトル: 日報 YYYY-MM-DD）を自動作成してくれるんですが、それに各メンバーがコメントで作業内容を追加していく形式にしました。

使い方はめちゃくちゃシンプル:

# 対話形式で日報を書く
/daily-report

# 内容を直接指定
/daily-report 今日はプロジェクトの開発を進めた。APIの実装が完了し、テストも通った。

これだけで、今日の日報 Issue に自分のコメントが追加されます。

何がいいって:

ターミナルから一行で完結
Slackやブラウザを開かなくていい
開発の文脈を保ったまま日報が書ける
書いた内容は GitHub Issue に残るので、後から検索もしやすい

「日報どこに書くんだっけ？」「URLどこだっけ？」って毎回探す時間がゼロになりました。

開発終わって、そのまま /daily-report 打って、今日やったこと書いて Enter。これだけ。めちゃくちゃ楽です。

実際に使ってみて

ツールを行ったり来たりが減った

一番の成果はこれです。

Claude Codeで開発してて、「あ、このIssueクローズしなきゃ」って思った時に、ブラウザ開いてGitHub行って……っていう手間がなくなりました。

/if-vault close 29

これだけで完結するのは、想像以上に快適ですね。

実際の表示画面はこんな感じ

/if-vault mine を実行すると、こんな感じで表示されます。

表示内容:

自分にアサインされたIssueが一覧で表示される
各Issueの番号、タイトル、ラベル、更新日が見やすいテーブル形式
優先度・部署・種類・Epicのラベルが色分けされて表示される
優先度：高の Issue (全体) セクションで、チーム全体の緊急タスクも一目で分かる

これの何がいいって:

ブラウザを開かなくても、今やるべきことが一目瞭然
ラベルで優先度や担当部署がすぐ分かる
Claude Codeから直接Issueにアクセスできる

ターミナルから離れずに、すべての情報が手に入るのは本当に楽ですね。

日報を書くハードルが圧倒的に下がった

/daily-report を使い始めてから、日報を書く習慣が完全に定着しました。

以前:

「日報書かなきゃ」→ Slack 開く → 今日の日報 Issue のリンク探す → GitHub 開く → コメント欄に移動 → やっと書ける
この間に Slack の通知見ちゃって、気づいたら 10分経ってる……

今:

コード書き終わった → /daily-report → 今日やったこと書く → Enter
5秒で完了

ターミナルから離れないから、開発の流れが途切れないんですよね。

「今日何やったっけ？」って思い出すのも、さっき書いたコードが目の前にあるから楽だし、そのまま自然に日報が書ける。

しかも、書いた内容は GitHub Issue に残るから、後から「あの時何やったっけ？」って検索するのも簡単です。

チームメンバーの反応:

Slack で /daily-report スキルを共有したら、「これいいね！」ってすぐに使い始めてくれました。

「日報書くのめんどくさい」って言ってたメンバーも、「これなら続けられる」って毎日書いてくれるようになって、チームの透明性が上がりましたね。

週報が自動で作られる快感

金曜日の 15:00 になると、Slack に「週報が自動作成されました！」って通知が来ます。

週報 Issue を開くと、もう完了した Issue も、進行中のタスクも、ブロッカーも、全部まとまってる。

これまで「今週何やったっけ？」って日報を遡ってた時間が、完全にゼロになりました。

あとは手動入力項目（スプリントゴール達成度とか、来週の予定とか）をサクッと入力するだけ。5分で週報完了です。

17:30 のリマインド通知も地味に効いてて、「あ、まだ入力してなかった」って気づけるのがいいですね。

まだ改良中だが手応えを感じている

正直、まだ完璧には程遠いです。

GitHub Projectsの制約とか、やりたいことはまだまだあるんですが、「これ、いい方向に向かってるな」っていう手応えはあります。

完璧を目指さず、少しずつ改善していくっていうスタンスで進めてます。

実装のポイント

ここからは、実装時に工夫したポイントや苦労したところを紹介します。技術詳細に興味がない方は、まとめまでスキップしてOKです。

ラベルシステム

GitHub Issuesをちゃんと運用するために、ラベルを整理しました。

優先度: 高・中・低
部署: 部門A・部門B・部門C
種類: バグ・機能・タスク・ドキュメント
Epic: 業務自動化・インフラ・セキュリティ

これをセットアップスクリプトで自動作成できるようにしてます。

cd ~/.claude/skills/if-vault
./scripts/setup-labels.sh

Issue作成のインタラクティブUI

/if-vault create を実行すると、対話形式でIssueを作成できます。

1. Issueタイプの選択

タスク（作業タスク・TODO・実装作業など）
バグ報告（システムの不具合・エラー・予期しない動作の報告）
機能要望（新機能の提案・既存機能の改善要望）
ドキュメント（マニュアル作成・手順書整備・ドキュメント更新）

矢印キーで選択して、Enterで決定。シンプルで迷わないUIになってます。

2. 部署やラベルの選択

Issueタイプを選んだら、次は部署やラベルを選択します。

複数選択可能（チェックボックス形式）
Tab/矢印キーで移動
Submitで次へ

この対話形式のおかげで、「あれ、このIssueどのラベル付ければいいんだっけ？」って悩む時間がゼロになりました。

チーム配布パッケージとしての設計

チームメンバーに「これ使ってみて」って言えるように、インストールスクリプトも作りました。

cd ~/Documents/main-project/team/github-management-tools
./install.sh

これでスキルファイルが ~/.claude/skills/ にコピーされて、すぐ使えるようになります。

スクラム・日報・週報の一元化

今は基本的にGitHubベースで：

スクラムして
日報書いて
スプリント書いて
週報まとめて

っていう一連の流れをClaude Codeから操作できるように改良中です。

GitHub ActionsでSlackへの自動投稿

日報やスクラムの入力URLを、GitHub Actionsのワークフローで自動的にSlackに投稿するようにしました。

これで「今日の日報どこに書くんだっけ？」っていうのがなくなって、Slackの通知から今まで通り飛び先で入力することもできるし、ターミナルからIssueをリストアップ、更新、削除なども完結できるようになりました。

作業スタイルに合わせて使い分けられるのがいいですね。

週報自動作成システム（実装完了）

日報とスクラムの内容を見て週報を自動作成するシステムを作りました。

なぜ週報を自動化したかったか

毎週金曜日の夕方、「今週何やったっけ？」って日報やIssueを見返して週報を書くのが地味にしんどくて。

しかも、Unit長や上位レイヤーに「チームの状況が見える」週報を書こうとすると、情報を集めるだけで30分くらいかかってたんですよね。

実装した仕組み

GitHub Actionsで完全自動化しました。スケジュールはこんな感じ：

金曜 15:00 → 週報自動作成
  ├─ その週の完了 Issue を自動収集
  ├─ 進行中の主要 Issue を自動収集
  ├─ スクラムからスプリントゴール・ブロッカーを抽出
  ├─ 日報から学び・気づきを抽出
  ├─ 週報 Issue を作成（自動収集データ付き）
  ├─ 入力依頼 Issue を作成（手動入力項目のチェックリスト）
  └─ Slack で通知

金曜 17:30 → リマインド通知
  ├─ 入力完了率を計算（例: 5/8項目完了 = 62%）
  ├─ 未入力のメンバーに Slack でリマインド
  └─ 「あと少し！」「まだX項目未入力」など状況に応じたメッセージ

自動収集される情報

週報 Issue には、こんな情報が自動で入ります：

📊 今週のサマリー: 完了 Issue 9件、進行中 Issue 18件、ブロッカー 1件（テーブル形式）
✅ 今週の成果: クローズした Issue 一覧（担当者・ラベル付き）
🚧 主要な進行中タスク: 優先度高・Epic ラベル付きの Issue
⚠️ ブロッカー: スクラムで「詰まってること」に書かれた内容
💡 学び・気づき: 各日報の「学んだこと / 気づき」を日付・担当者付きで集約

これらは全て gh CLI でデータを取得して、Markdown フォーマットで整形してます。

実装の成果

週報作成の時間が 30分 → 5分 くらいになりました。

情報を探し回る時間がゼロになって、手動入力も必要最小限に絞れたので、かなり楽になりましたね。

まとめ

チームに合った形を探すことの大切さ

今回の取り組みで一番学んだのは、「他のチームの真似よりも、自分たちのベストを探す」っていうことです。

Notionが便利っていう人もいるし、Jiraが最高っていう人もいる。でもうちのチームには、Claude Codeから完結できる方が合ってたんです。

同じようにツールの分散に悩んでる人がいたら、「自分たちのチームに何が必要か」を考えるところから始めるのがいいと思います。

小さく始めて、少しずつ改善する

完璧なシステムを最初から作ろうとすると、絶対に挫折します（経験談）。

まずは「Issue一覧を見れるだけ」から始めて、「あ、これクローズもできたら便利だな」って気づいたら追加して……って感じで、少しずつ育てていくのがいいですね。

今も改良中ですが、そのプロセス自体が楽しいです。

Claude Codeのポテンシャル

Claude Codeのスキル機能、けっこうポテンシャル高いと思います。

GitHub CLI (gh) と組み合わせることで、かなり複雑な操作も自動化できるし、チーム配布も簡単にできる。

もしClaude Codeを使ってて「もっと効率化したいな」って思ってる人がいたら、スキルを作ってみるのをおすすめします。

付録：週報マージシステムの詳細な実装（興味がある方向け）

📝 Note: ここから先は、週報自動化システムのより詳細な技術解説です。
実装の具体的な手法に興味がない方は読み飛ばしてOKです。

週報マージシステムの実装詳細（2026-03-05 完成）

週報システムをさらに進化させて、各メンバーの入力を自動的に1枚の週報にマージする仕組みを実装しました。

なぜマージが必要だったか

最初は「週報 Issue に各自がコメントで書く」方式でしたが、これだと：

Unit長が見る時に、コメント欄をスクロールして全員の入力を確認する必要がある
「誰がまだ入力してないか」が一目で分からない
最終的な週報として体裁が整っていない

という課題がありました。

そこで、個別の入力依頼 Issue で各自が記入 → 3人全員の入力が揃ったら自動的にメイン週報にマージという仕組みを作りました。

実装した3つのワークフロー

1. weekly-report-generator.yml（週報生成）
   トリガー: 毎週金曜17:00 or 手動実行
   処理:
   ├─ 今週の完了 Issue を gh CLI で収集
   ├─ 進行中 Issue を収集
   ├─ メイン週報 Issue を作成（自動生成部分）
   ├─ 3人の入力依頼 Issue を作成
   │  ├─ @member1 用
   │  ├─ @member2 用
   │  └─ @member3 用
   └─ Slack に通知（@it-if メンション + 具体的手順）

2. weekly-report-merger.yml（自動マージ）
   トリガー: Issue コメント投稿時 or Issue クローズ時
   処理:
   ├─ 週報入力依頼 Issue かチェック
   ├─ 3人全員の入力完了を検知
   │  └─ コメント送信 or Issue クローズで「完了」判定
   ├─ 全員完了していたら:
   │  ├─ 各メンバーのコメント内容を収集
   │  ├─ Python で本文を処理してマージ
   │  ├─ メイン週報 Issue を更新
   │  ├─ 入力依頼 Issue を全てクローズ
   │  └─ Slack に完成通知

3. weekly-report-reminder.yml（リマインド）
   トリガー: 毎日10:00
   処理:
   ├─ 未完了の入力依頼 Issue を検索
   ├─ 各メンバーの完了状況を確認
   └─ 未完了者に Slack + Issue コメントでリマインド

「仕組みを忘れても大丈夫」な設計

これが一番こだわったポイントです。

週報システムって、週1回しか使わないんですよね。だから、「やり方忘れた」ってなりがちで。

そこで、メンバーが何も覚えてなくても使えるように設計しました：

1. Issue 本文に具体的な手順を記載

# 👋 週報入力依頼 @member1

## 📝 やること（シンプル！）

1. **下記の項目を記入**
2. **このIssueにコメントで「入力完了」と送信**（または Issue をクローズ）
3. **完了！** 🎉 自動的にメイン週報にマージされます

冒頭に大きく「やること」を書いて、3ステップで完結するようにしました。

2. 各項目に記入例を提示

## ✅ 今週の成果

**あなたが今週完了したタスク・達成したこと**

\`\`\`
例：
- 管理画面を実装
- API認証の脆弱性を修正
- マスターデータCRUDを完成
\`\`\`

記入欄 👇

「何を書けばいいか分からない」をゼロにするために、全項目に記入例を付けました。

3. 完了方法を複数用意

コメントで「入力完了」と送信（推奨）
Issue をクローズ

どちらでも完了扱いになるので、メンバーの好みで選べます。

4. Slack 通知に次のアクションを明記

{
  "text": "@team 週報入力をお願いします！",
  "blocks": [
    {
      "text": "*やること（簡単！）*\n1️⃣ 自分の Issue を開く\n2️⃣ 項目を記入（5分程度）\n3️⃣ コメントで「入力完了」と送信\n\n→ 3人揃ったら自動的に週報が完成します 🎉"
    },
    {
      "text": "*📋 各自の入力 Issue*\n• @member1\n• @member2\n• @member3"
    }
  ]
}

Slack の通知に「何をする」「どこで」「いつまでに」を全部書いて、各自の Issue への直リンクも付けました。

5. 自動リマインド

毎日10:00に未完了者へリマインドが飛ぶので、忘れててもOKです。

実装で苦労したこと: sed vs Python

マージ処理の実装で、かなり試行錯誤しました。

最初の実装: sed でテキスト処理

# 自動生成部分を抽出
sed -n '1,/## 👥 各メンバーの週報入力/p' current_body.txt | sed '$d' > new_body.txt

# 各メンバーの入力を追加
echo "$KAWAMURO_INPUT" >> new_body.txt
# ...

→ 失敗。 絵文字や日本語を含む文字列で sed がエラーを吐く。

2回目: 一時ファイル + sed

gh issue view 43 --json body --jq -r '.body' > current_body.txt
sed -n '1,/## 👥/p' current_body.txt > new_body.txt

→ 失敗。 accepts 1 arg(s), received 2 というエラー。マルチバイト文字の処理が不安定。

最終実装: Python + subprocess

import subprocess
import json
import re

# gh CLI で本文を取得
result = subprocess.run(
    ['gh', 'issue', 'view', '43', '--repo', 'my-org/main-project', '--json', 'body'],
    capture_output=True,
    text=True
)
current_body = json.loads(result.stdout)['body']

# 正規表現で自動生成部分を抽出
match = re.search(r'^(.*?)## 👥 各メンバーの週報入力', current_body, re.DOTALL)
if match:
    auto_generated = match.group(1).rstrip()

# 新しい本文を作成
new_body = f"""{auto_generated}

## 👥 各メンバーの週報入力

{kawamuro}

---

{sekiguchi}

---

{ikuta}

---

✅ **週報完成！** 全メンバーの入力が揃いました
"""

# ファイルに書き出し
with open('/tmp/new_body.txt', 'w', encoding='utf-8') as f:
    f.write(new_body)

# gh コマンドで更新
subprocess.run(
    ['gh', 'issue', 'edit', '43', '--body-file', '/tmp/new_body.txt'],
    check=True
)

→ 成功！ Python なら encoding='utf-8' で確実にマルチバイト文字を扱えます。

学んだこと:

GitHub Actions で日本語・絵文字を扱うなら、sed より Python
subprocess で gh CLI を呼ぶと、エラーハンドリングも楽
一時ファイルは /tmp/ に作るのが安全

動作テスト結果

実装後、すぐに動作テストを実行しました。

# 1. 週報生成ワークフローを手動実行
gh workflow run weekly-report-generator.yml --repo my-org/main-project

# 2. 作成された Issue を確認
gh issue list --repo my-org/main-project --label weekly-report

# 3. 各メンバーの入力依頼 Issue にテストコメントを送信
gh issue comment 44 --body "テスト入力..."
gh issue comment 45 --body "テスト入力..."
gh issue comment 46 --body "テスト入力..."

# 4. マージワークフローが自動実行される
# → 3人全員の入力が揃ったら、自動的にメイン週報にマージ！

結果:

✅ 週報生成: 23秒で完了
✅ 入力依頼 Issue 作成: 3人分作成成功
✅ Slack 通知: 正しく送信
✅ マージワークフロー: 23秒で完了
✅ 自動マージ: 完璧に動作

メイン週報を開くと、自動生成部分（Issue 統計）+ 各メンバーの入力内容がきれいにマージされていました。

実装コスト

ワークフロー3つ: 約300行
運用ガイド: 約400行
実装時間: 約4時間（試行錯誤含む）

でも、毎週30分 × 3人 = 90分/週の時間削減になったので、2週間で元が取れました。