Claude Code でWeb制作の案件管理を自動化した話 — GitHub × Google Chat 連携を1日で構築 | GH Media
URLがコピーされました

Claude Code でWeb制作の案件管理を自動化した話 — GitHub × Google Chat 連携を1日で構築

TECH
# AI# Claude Code# GitHub# プロジェクト管理# Google Chat
URLがコピーされました
Claude Code でWeb制作の案件管理を自動化した話 — GitHub × Google Chat 連携を1日で構築

はじめに

エンジニア歴10年。現在はグリームハブ合同会社でテクニカルマネージャーをしている鈴木です。

弊社では複数のWeb制作案件を並行して受託しています。ありがたいことに案件数は増えているのですが、ずっと頭を悩ませていたのが プロジェクト管理のコストと運用 でした。

ツール遍歴 — Notion → Google Workspace → GitHub

最初は Notion や JIRA を使って管理していました。機能的には申し分ないのですが、案件が増えるにつれて ツールコストが無視できなくなってきた。少人数のWeb制作チームにとって、管理ツールだけで月数万円の固定費は重い。

そこで目を付けたのが Google Workspace です。弊社では Google Workspace を事業運営の基盤として使っており、メール・カレンダー・ドライブ・Chat すべてがここに集約されています。この すでに課金しているプラットフォーム に案件管理も乗せられないか？　と考えました。

実際にスプレッドシートでタスク管理表を作り、AppSheet で簡易的なダッシュボードも構築してみました。しかし、正直 しっくりこなかった。スプレッドシートはデータの入力・更新が手作業になりがちで、AppSheet は柔軟性はあるもののプロジェクト管理に特化した UI ではない。結局「管理のための管理」から抜け出せませんでした。

本当の課題 — 業務委託メンバーの横断管理

ツール選定以上に深刻だったのが、業務委託メンバーの案件横断的な管理 です。

弊社ではデザイナーやコーダーに業務委託で入っていただくことが多いのですが、複数案件にまたがって稼働しているメンバーが「今どの案件のどのタスクを持っていて、何が着手中なのか」を一覧で把握する手段がありませんでした。結果として、気づかないうちにオーバーワークをさせてしまうこともありました。

要するに、ツールにコストをかけても、かけなくても、メンバーの稼働状況を正しく把握できていない — これが最大の課題でした。

解決策 — GitHub Projects × Google Chat × Claude Code

最終的にたどり着いたのが GitHub Projects です。GitHub 自体は開発で使っており追加コストゼロ。Projects v2 のボード機能は Notion や JIRA に引けを取らず、Organization Project を使えば 全案件の Issue を1つの画面で横断管理 できる。そして日常のコミュニケーションは Google Chat にそのまま残す。

この「GitHub Projects × Google Chat」の連携基盤を、Claude Code を使って1日で構築 しました。本記事ではその全体像と、実際にどう作ったかを共有します。

何を作ったのか — システム全体像

構築したのは GitHub Projects × Google Chat を連携する案件管理システム です。

ポイントは、案件ごとにリポジトリと Issue を分けつつ、GitHub Organization Project で全案件の Issue を1つの画面に集約 していること。これにより「Aさんは案件Xのデザインと案件Yのコーディングを抱えていて、どちらも着手中」といった状況が一目で分かるようになりました。

GitHub Organization Project（全案件を横断して一覧表示）
    │
    ├── 案件A リポジトリ ─── Issues ──┐
    ├── 案件B リポジトリ ─── Issues ──┼── 自動追加（GitHub Actions）
    └── 案件C リポジトリ ─── Issues ──┘

Google Chat（クライアントとのやりとり）
    │
    ├── Chat Bot（GAS）
    │     /create → GitHub Issue 作成
    │     /close  → Issue クローズ
    │     /status → 進捗一覧表示
    │
    ├── 自動通知（GitHub Actions）
    │     Issue 作成・完了時に Chat へ通知
    │
    └── Bot 投稿
          WBS 展開・日報生成の結果を Chat に投稿

主要な機能は以下の6つです。

  1. Organization Project による一元管理 — 全案件の Issue が1つのボードに集約。担当者×案件の横断ビューで稼働状況を把握
  2. 案件セットアップの自動化 — 案件名を伝えるだけで、リポジトリ・ラベル・Projects・通知ワークフローを一括作成。Issue は自動で Org Project に追加される
  3. Chat Bot — Google Chat 上で /create デザインカンプ作成 @伊藤 と打てば GitHub Issue が作られる
  4. 自動通知 — Issue の作成・完了時に Google Chat へリアルタイム通知
  5. WBS 展開 — Markdown の WBS を GitHub Issues に一括変換（15タスクを1コマンドで Issue 化）
  6. 日報生成 — GitHub Issues の当日変更を自動集計してレポート生成

Claude Code の「エージェント」とは

Claude Code には、特定の業務に特化した カスタムエージェント を定義できる機能があります。.claude/agents/ にマークダウンファイルを置くだけで、そのタスク専用の AI アシスタントが使えるようになります。

今回は3つのエージェントを定義しました。

.claude/agents/
├── project-setup.md     # 案件セットアップ
├── report-generator.md  # 日報生成
└── space-migrator.md    # 既存スペース移行

たとえば案件セットアップエージェントの定義はこれだけです。

---
name: project-setup
description: 新規案件のセットアップを実行するエージェント
tools:
  - Bash
  - Read
  - Write
---

# 案件セットアップエージェント

新規Web制作案件の GitHub 環境を構築する。

## 実行手順

1. 案件名を受け取る
2. `agents/setup/create_project.py` を実行し、以下を自動化:
   - GitHub リポジトリ作成
   - 標準ラベル作成
   - GitHub Projects (v2) 作成
   - `config/space_project_map.json` に対応情報を追加
3. 結果を報告する

これで、Claude Code に「案件名『ThemeX コーポレートサイト』でセットアップして」と伝えるだけで、GitHub の環境構築が完了します。手作業でやると10〜15分かかる作業が、数秒です。

しかも、新しく作った案件リポジトリの Issue は GitHub Actions によって自動的に Organization Project に追加 されます。案件ごとに個別設定する必要はなく、Claude Code がセットアップ時にワークフローも含めて全部やってくれます。

実装の進め方 — 8ステップを1日で

このシステムは、事前に書いた設計書を Claude Code に渡し、8つのステップ に分けて段階的に実装しました。

Step内容主な成果物
1環境整備ディレクトリ構成、pyproject.toml、CLAUDE.md
2GitHub API 実装REST + GraphQL クライアント
3Google Chat API 実装Service Account 認証クライアント
4Chat Bot（GAS）/create, /close, /status コマンド
5自動通知GitHub Actions → Chat Webhook
6日報生成Issues 集計 → Markdown レポート
7既存スペース移行Chat スペース → GitHub 環境の紐付け
8WBS 展開Markdown WBS → Issues 一括変換

実際のコミット履歴がこちらです。

592220e fix: Chat 通知を curl 方式に変更
7456d4f feat: WBS 展開スクリプト実装（Step 8）
92040c2 feat: 既存スペース移行スクリプト実装（Step 7）
b2d92ae feat: Chat API クライアント・GAS Bot・通知連携・日報生成を実装（Step 3〜6）
6ef13ec feat: 初期構築（環境整備 + GitHub API クライアント実装）

各ステップで「dry-run → 動作確認 → 承認 → 本実行」のサイクルを回しました。Claude Code が勝手に本番環境を触ることがないよう、CLAUDE.md に安全ルール を明記しています。

## 安全ルール

- `.env` と `credentials/` を絶対にコミットしない
- 破壊的 API 操作（リポジトリ削除等）は実装しない
- 本番デプロイ・費用が発生する API・公開投稿は人間の承認を必須とする

技術的なポイント

GitHub REST API + GraphQL の使い分け

GitHub Projects v2 の操作には GraphQL API が必須 です。Issue やリポジトリは REST API で操作できますが、Projects v2 のボード管理（アイテム追加、ステータス更新）は GraphQL でしか実現できません。

今回は1つのクライアントクラスに両方を統合しました。

class GitHubClient:
    """GitHub API クライアント"""

    # REST API — Issue・リポジトリ操作
    def _rest(self, method: str, path: str, *, json: dict | None = None):
        url = f"{REST_BASE}{path}"
        resp = requests.request(method, url, headers=self.headers, json=json, timeout=30)
        resp.raise_for_status()
        return resp.json()

    # GraphQL API — Projects v2 操作
    def _graphql(self, query: str, variables: dict | None = None):
        resp = requests.post(GRAPHQL_URL, headers=self.headers, json={"query": query, "variables": variables}, timeout=30)
        data = resp.json()
        if "errors" in data:
            raise RuntimeError(f"GraphQL エラー: {data['errors']}")
        return data["data"]

Projects v2 への Issue 追加は、こんな GraphQL mutation で実現しています。

def add_item_to_project(self, project_id: str, content_id: str) -> dict:
    mutation = """
    mutation($projectId: ID!, $contentId: ID!) {
        addProjectV2ItemById(input: { projectId: $projectId, contentId: $contentId }) {
            item { id }
        }
    }
    """
    data = self._graphql(mutation, {"projectId": project_id, "contentId": content_id})
    return data["addProjectV2ItemById"]["item"]

なお、GraphQL API を使うには Personal Access Token に project スコープの追加が必要です。最初はスコープ不足で INSUFFICIENT_SCOPES エラーが出ましたが、Claude Code がエラーメッセージを読み取り、スコープ追加のコマンド（gh auth refresh -s project）を提案してくれました。

Google Chat API の2つの認証モード

Google Chat API には ユーザー委任モード と App モード の2種類があります。

class ChatClient:
    def _get_user_service(self):
        """ユーザー委任モード（管理ユーザーとしてスペース一覧・メッセージ取得）"""
        creds = service_account.Credentials.from_service_account_file(
            str(self._sa_file), scopes=CHAT_SCOPES
        )
        creds = creds.with_subject(self._delegated_user)  # ← ユーザーに成り代わる
        return build("chat", "v1", credentials=creds)

    def _get_app_service(self):
        """App モード（Bot 自身としてメッセージ投稿）"""
        creds = service_account.Credentials.from_service_account_file(
            str(self._sa_file), scopes=CHAT_SCOPES
        )
        # with_subject なし → Bot として動作
        return build("chat", "v1", credentials=creds)

with_subject() の有無だけで切り替わるシンプルな設計ですが、これを知らずにハマるケースは多いと思います。スペースの一覧取得やメッセージの読み取りにはユーザー権限が必要で、Bot としての投稿には App 権限が必要 — この使い分けがポイントです。

WBS → GitHub Issues の一括変換

Web制作では、WBS（作業分解構成図）をもとにタスクを管理するのが一般的です。今回はこんな Markdown フォーマットの WBS を書くだけで、GitHub Issues に一括変換できるようにしました。

## フェーズ1: デザイン

### トップページ
- [ ] ワイヤーフレーム作成 @伊藤 #期限2026-03-10
- [ ] デザインカンプ作成 @伊藤 #期限2026-03-15
- [ ] デザインレビュー・修正 @鈴木

### 下層ページ
- [ ] サービスページ デザイン @伊藤
- [ ] 会社概要ページ デザイン @伊藤

## フェーズ2: コーディング
...

パーサーの設計はシンプルです。

@dataclass
class WbsTask:
    title: str           # タスク名
    milestone: str = ""  # ## → マイルストーン
    section: str = ""    # ### → 工程
    assignees: list[str] = field(default_factory=list)  # @名前
    due_date: str = ""   # #期限YYYY-MM-DD
  • ## 見出し → マイルストーン（フェーズ）
  • ### 見出し → 工程（Issue 本文に記載）
  • - [ ] → Issue（タスク）
  • @名前 → 担当者ラベル
  • #期限YYYY-MM-DD → 期限

このフォーマットなら非エンジニアのディレクターでも書けますし、普通のチェックリストとしても読めます。実際にテスト用の WBS（15タスク）を実行したところ、全 Issue が Projects に追加され、Chat にも通知が飛びました。

Claude Code と開発して気づいたこと

エラーを自分で解決する「エージェント力」

Claude Code の強みは、単にコードを書くだけでなく、実行して、エラーを読んで、自分で修正する サイクルを回せることです。

今回の開発中にも、GitHub API のスコープ不足、GAS のデプロイ設定漏れ、空リポジトリへの API 呼び出し失敗など、様々なエラーが発生しました。そのほとんどを Claude Code がエラーメッセージから原因を特定し、修正案を提示 → 実行してくれました。

たとえば、新規作成したリポジトリにワークフローファイルを追加する際、リポジトリの初期化が完了する前に API を叩いて 404 エラーが出ました。Claude Code はこれを受けて、リトライロジックを自主的に追加してくれました。

CLAUDE.md が「チームのルールブック」になる

CLAUDE.md に書いたルール（安全ルール、コーディング規約、ディレクトリ構造）は、Claude Code にとっての行動指針になります。これは人間のチームメンバーに対するオンボーディング資料と同じ役割を果たします。

面白いのは、Claude Code と一緒に開発を進める中で CLAUDE.md 自体も進化していくことです。新しいモジュールを追加するたびに構造の記述を更新し、安全ルールも実際の運用で気づいた点を追記していく。コードと一緒にルールも育っていく 感覚があります。

dry-run パターンの重要性

外部 API を叩くスクリプトでは、必ず dry-run モードを実装 しました。Claude Code に「まず dry-run で確認して」と指示すると、実際に API を叩かずに処理内容だけを表示してくれます。

# dry-run（Issue は作成しない）
uv run python agents/setup/expand_wbs.py --repo my-project --wbs wbs.md

# 実行（承認後）
uv run python agents/setup/expand_wbs.py --repo my-project --wbs wbs.md --execute

AI に外部リソースを操作させる場合、この「確認してから実行」のフローは必須だと感じました。

まとめ

Notion → スプレッドシート → AppSheet と試行錯誤してきたプロジェクト管理ですが、最終的に GitHub Projects × Google Chat × Claude Code という組み合わせに落ち着きました。

振り返ると、これまでのツール選定で見落としていたのは「ツールの機能」ではなく 「運用の自動化」 でした。どんなに優秀なツールでも、セットアップが手作業で、データの入力が手作業で、集計が手作業なら、結局「管理のための管理」から逃れられない。

Claude Code は「コードを書く AI」ではなく、「開発プロセスを一緒に設計・構築するパートナー」 です。設計書を渡してから実働するシステムが動くまで1日で到達しました。GitHub API の REST / GraphQL の使い分け、Google Chat API の認証設計、GAS Bot の実装、GitHub Actions の通知連携 — これらを横断的に扱う開発を、1人 + Claude Code で完走できたのは大きな収穫です。

そして個人的に一番インパクトが大きかったのは、Organization Project による案件横断の一元管理 です。全案件の Issue が1つの画面に集約されることで、業務委託メンバーが「どの案件のどのタスクを持っていて、何が着手中なのか」を一目で把握できるようになりました。これまで見えなかった稼働状況が可視化されたことで、無意識のオーバーワークを防げるようになったのは、管理者として本当に大きい変化です。

しかもこの仕組み、案件が増えるたびに Claude Code にセットアップを任せるだけで、ワークフローの設定も含めて全自動で整います。案件が10件、20件と増えても管理コストが増えない。これがスケールする仕組みの力だと実感しています。

コスト面でも、Notion や JIRA の月額課金がなくなり、すでに使っている GitHub と Google Workspace だけで完結する。少人数のWeb制作チームにとって、追加コストゼロで本格的なプロジェクト管理基盤が手に入った のは大きなメリットです。

特にWeb制作の受託チームのような 少人数で複数案件を回す現場 では、こうした管理業務の自動化が直接的に生産性に効きます。「管理のための管理」をなくし、クリエイティブな作業に集中できる環境を作ること。それが今回の自動化の本質的な価値だと思っています。

本記事のコード例は実際のプロジェクトをもとにしていますが、案件名・クライアント名等は変更しています。

AI を活用した業務効率化に取り組んでいます

グリームハブ合同会社では、本記事で紹介したような AI を活用した開発プロセスの最適化 をはじめ、 AI ツール導入支援、開発ワークフローの設計など、幅広くお手伝いしています。

お気軽にご相談ください。

お問い合わせはこちら → グリームハブ合同会社 お問い合わせ

URLがコピーされました

グリームハブ合同会社は、変化の激しい時代において、アイデアを形にし、人がもっと自由に、もっと創造的に生きられる世界を目指しています。

記事を書いた人
鈴木 翔
鈴木 翔

技術の可能性に魅了され、学生時代からプログラミングとデジタルアートの分野に深い関心を持つ

関連記事