Module 4: 運用編 - リファレンス資料
Claude CodeとGitHubを活用した業務運用のための参考資料集です。 必要なときに辞書的に参照してください。
1. GitHub用語集
GitHubで頻出する用語を、身近なたとえと合わせて解説します。
| # | 用語 | 英語表記 | 意味 | 身近なたとえ |
|---|---|---|---|---|
| 1 | リポジトリ | Repository | プロジェクトのファイルや変更履歴をまとめて保管する場所 | プロジェクト専用のフォルダ |
| 2 | ブランチ | Branch | メインの作業に影響を与えず、別の作業を進めるための分岐 | 下書き用のコピー |
| 3 | コミット | Commit | ファイルの変更を記録すること | 「保存」ボタンを押すこと |
| 4 | プッシュ | Push | 手元の変更をGitHub上にアップロードすること | ファイルをクラウドに同期すること |
| 5 | プル | Pull | GitHub上の最新状態を手元にダウンロードすること | クラウドから最新版を取得すること |
| 6 | Issue | Issue | タスク、バグ報告、要望などを記録するチケット | 付箋に書いたToDoメモ |
| 7 | Pull Request (PR) | Pull Request | 変更内容を確認・承認してもらうための依頼 | 「この内容を確認してください」という回覧板 |
| 8 | マージ | Merge | ブランチの変更をメインに統合すること | 下書きを清書に反映すること |
| 9 | mainブランチ | main branch | リポジトリの正式な本流となるブランチ | 清書版のフォルダ |
| 10 | レビュー | Review | PRの内容を確認し、承認やコメントをすること | 上司に書類を確認してもらうこと |
| 11 | クローン | Clone | リポジトリを手元のPCにダウンロードすること | クラウドのフォルダを丸ごとPCにコピーすること |
| 12 | フォーク | Fork | 他人のリポジトリを自分のアカウントにコピーすること | 他人の資料を自分用にコピーすること |
| 13 | コンフリクト | Merge Conflict | 同じ箇所を別々に変更した結果、自動統合できない状態 | 2人が同じ欄を違う内容で埋めてしまった状態 |
| 14 | ラベル | Label | IssueやPRにつけるカテゴリタグ | ファイルに貼る色付きシール |
| 15 | README | README | リポジトリの説明書となるファイル | プロジェクトの表紙・目次 |
| 16 | CLAUDE.md | CLAUDE.md | Claude Codeへの指示や設定を書くファイル | AIアシスタントへの業務マニュアル |
2. GitHubの基本操作チートシート（Web UIベース）
すべてブラウザ上のGitHub Web UIで操作できます。コマンド入力は不要です。
リポジトリの操作
| やりたいこと | 操作手順 |
|---|---|
| リポジトリを作成する | 右上「+」→「New repository」→ 情報入力 →「Create repository」 |
| ファイルを新規作成する | リポジトリページ →「Add file」→「Create new file」→ 内容入力 →「Commit changes」 |
| ファイルをアップロードする | リポジトリページ →「Add file」→「Upload files」→ ドラッグ&ドロップ →「Commit changes」 |
| ファイルを編集する | ファイルをクリック → 鉛筆アイコン → 編集 →「Commit changes」 |
| ファイルを削除する | ファイルをクリック →「…」メニュー →「Delete file」→「Commit changes」 |
| フォルダを作成する | 「Create new file」→ ファイル名に フォルダ名/ファイル名 と入力（スラッシュで区切る） |
Issueの操作
| やりたいこと | 操作手順 |
|---|---|
| Issueを作成する | 「Issues」タブ →「New issue」→ タイトル・本文入力 →「Submit new issue」 |
| ラベルを付ける | Issue画面の右側「Labels」→ 該当ラベルを選択 |
| 担当者を設定する | Issue画面の右側「Assignees」→ ユーザーを選択 |
| Issueを閉じる | Issue画面下部の「Close issue」 |
| コメントを追加する | Issue画面下部のテキスト欄に入力 →「Comment」 |
| Issueを検索する | 「Issues」タブの検索バーにキーワードを入力 |
Pull Requestの操作
| やりたいこと | 操作手順 |
|---|---|
| PRの一覧を見る | 「Pull requests」タブをクリック |
| PRの変更内容を見る | PR画面の「Files changed」タブ |
| 行にコメントを付ける | 「Files changed」→ 行番号左の「+」→ コメント入力 →「Start a review」 |
| レビューを送信する | 「Finish your review」→ Approve / Request changes / Comment →「Submit review」 |
| PRをマージする | 「Merge pull request」→「Confirm merge」 |
| ブランチを削除する | マージ後に表示される「Delete branch」をクリック |
設定の操作
| やりたいこと | 操作手順 |
|---|---|
| 公開範囲を確認する | 「Settings」→「General」→ 下部「Danger Zone」→「Change visibility」 |
| ラベルを管理する | 「Issues」→「Labels」→「New label」 |
| Issueテンプレートを作る | 「Settings」→「General」→ Features内「Set up templates」 |
| コラボレーターを確認する | 「Settings」→「Collaborators」 |
| ブランチ保護を設定する | 「Settings」→「Branches」→「Add branch protection rule」 |
3. CLAUDE.mdテンプレート集
業務の種類に応じたCLAUDE.mdのテンプレートです。自分の業務に合わせてカスタマイズしてください。
テンプレート1: リサーチ業務向け
# CLAUDE.md - リサーチプロジェクト
## プロジェクト概要
市場調査・競合分析・技術調査などのリサーチ業務を管理するプロジェクトです。
## 作業ルール
- 成果物はすべて日本語で作成すること
- ファイル形式はMarkdown (.md) を基本とする
- 調査結果には必ず情報源（URL、書籍名など）を明記すること
- 調査日を成果物の冒頭に記載すること
- 事実と推測・考察を明確に区別すること
## フォルダ構成
- `/market-research/` - 市場調査
- `/competitor-analysis/` - 競合分析
- `/tech-research/` - 技術調査
## 成果物のフォーマット
各レポートには以下を含めること:
1. 調査目的
2. 調査方法・範囲
3. 調査結果（表やリストを活用）
4. 考察・提言
5. 参考文献リスト
## 注意事項
- 機密情報や個人情報を含めないこと
- 著作権に配慮し、長文の引用は避けること
- 古い情報には注意し、調査時点を明記することテンプレート2: ドキュメント作成業務向け
# CLAUDE.md - ドキュメント作成プロジェクト
## プロジェクト概要
社内向けマニュアル、ガイドライン、提案書などの文書を作成・管理するプロジェクトです。
## 作業ルール
- すべての文書は日本語で作成すること
- ファイル形式はMarkdown (.md) を基本とする
- 対象読者のレベルに合わせた表現を使うこと
- 専門用語には初出時に説明を付けること
- 文書には作成日と最終更新日を記載すること
## フォルダ構成
- `/manuals/` - マニュアル・手順書
- `/guidelines/` - ガイドライン・ポリシー
- `/proposals/` - 提案書・企画書
- `/meeting-notes/` - 議事録
## 文書スタイルガイド
- 見出しは `##` から始める（`#` はタイトルのみ）
- 箇条書きは `-` を使用する
- 番号付きリストは手順の説明に使用する
- 重要な注意事項は `> **注意**: ...` の形式で記載する
- 表は3列以上の比較・一覧に使用する
## 注意事項
- 社外秘情報のレベルを意識すること
- 個人名を記載する場合は本人の了承を得ること
- バージョン管理はGitHubの履歴に委ねる（ファイル名にバージョン番号を付けない）テンプレート3: データ分析業務向け
# CLAUDE.md - データ分析プロジェクト
## プロジェクト概要
各種データの分析・可視化・レポート作成を管理するプロジェクトです。
## 作業ルール
- 分析レポートは日本語で作成すること
- データファイルと分析レポートは別フォルダに分けること
- 分析の前提条件・仮定を必ず明記すること
- 数値は適切な単位と桁数で表記すること
- グラフや表にはタイトルと説明を付けること
## フォルダ構成
- `/data/` - 元データ（CSVなど）
- `/reports/` - 分析レポート
- `/dashboards/` - 定期レポート・ダッシュボード
## レポートのフォーマット
各レポートには以下を含めること:
1. 分析目的
2. 使用データの概要（期間、件数、出典）
3. 分析手法
4. 分析結果（表・グラフを含む）
5. 考察・示唆
6. 推奨アクション
## 注意事項
- 個人を特定できるデータは匿名化すること
- 大容量データファイルはリポジトリに含めないこと（.gitignoreに追加）
- サンプルデータと本番データを明確に区別することテンプレート4: プロジェクト管理向け
# CLAUDE.md - プロジェクト管理
## プロジェクト概要
チームのプロジェクト管理に関する資料やテンプレートを管理するプロジェクトです。
## 作業ルール
- すべての資料は日本語で作成すること
- ステータス管理にはIssueのラベルを使用すること
- 週次で進捗レポートを作成すること
- 議事録は会議後24時間以内に作成すること
## フォルダ構成
- `/plans/` - 計画書・スケジュール
- `/reports/` - 進捗レポート・週報
- `/meeting-notes/` - 議事録
- `/retrospectives/` - 振り返り
## ラベル運用ルール
- `優先度:高` `優先度:中` `優先度:低` で優先度を管理
- `リサーチ` `資料作成` `データ分析` でタスク種別を管理
- `レビュー待ち` `修正中` `完了` で進捗を管理
## 注意事項
- 人事情報や評価に関する内容は含めないこと
- クライアント名は必要に応じてコードネームを使うことテンプレート5: 学習・ナレッジ管理向け
# CLAUDE.md - ナレッジベース
## プロジェクト概要
業務で得た知見やノウハウを蓄積・共有するためのナレッジベースです。
## 作業ルール
- すべての記事は日本語で作成すること
- 1トピック1ファイルを原則とする
- 引用や参考資料はリンクを明記すること
- 定期的に古い記事の見直しを行うこと
## フォルダ構成
- `/how-to/` - 手順書・ハウツー記事
- `/tips/` - 小技・コツ
- `/glossary/` - 用語解説
- `/case-studies/` - 事例紹介
- `/faq/` - よくある質問と回答
## 記事のフォーマット
各記事の冒頭に以下の情報を記載すること:
- 作成日
- 最終更新日
- カテゴリ（上記フォルダ構成に対応）
本文の構成:
1. 概要（3行以内で要約）
2. 本文（詳細な内容）
3. 関連記事へのリンク（あれば）
## 注意事項
- 社外秘の技術情報は公開リポジトリに含めないこと
- スクリーンショットに機密情報が映り込まないよう注意すること4. セキュリティチェックリスト
リポジトリを安全に運用するための10項目のチェックリストです。定期的に確認しましょう。
リポジトリ作成時（初回のみ）
| # | チェック項目 | 確認方法 | 対処 |
|---|---|---|---|
| 1 | リポジトリの公開範囲がPrivateになっているか | Settings → General → Danger Zone | Publicの場合はPrivateに変更 |
| 2 | .gitignore が設定されているか | リポジトリのルートにファイルがあるか確認 | なければ作成する（演習5参照） |
| 3 | 不要なコラボレーターにアクセス権を付与していないか | Settings → Collaborators | 不要なメンバーはRemoveする |
ファイル追加・編集のたびに確認
| # | チェック項目 | 確認方法 | 対処 |
|---|---|---|---|
| 4 | パスワードやAPIキーがファイルに含まれていないか | ファイル内を目視確認 | 削除し、該当するキー等を直ちに変更 |
| 5 | 個人情報（氏名・電話番号・メールアドレス等）が含まれていないか | ファイル内を目視確認 | 匿名化するか削除 |
| 6 | 社内システムのURL・IPアドレスが含まれていないか | ファイル内を目視確認 | 削除またはダミーに置換 |
| 7 | データベース接続情報が含まれていないか | ファイル内を目視確認 | 削除し、接続情報を変更 |
定期チェック（月1回推奨）
| # | チェック項目 | 確認方法 | 対処 |
|---|---|---|---|
| 8 | コラボレーター一覧に不要なメンバーがいないか | Settings → Collaborators | 退職者・異動者のアクセスを削除 |
| 9 | 公開範囲が意図せず変更されていないか | Settings → General → Danger Zone | Publicになっていたら直ちにPrivateに戻す |
| 10 | 過去のコミット履歴に機密情報が含まれていないか | コミット履歴を確認 | 発見した場合は該当するキー等を直ちに変更 |
機密情報を誤ってコミットしてしまった場合
重要: 一度GitHubにアップロードされた情報は、ファイルを削除しても過去のコミット履歴に残る可能性があります。
緊急対応手順:
- 該当するパスワード・APIキーを直ちに無効化・変更する（これが最優先）
- ファイルから機密情報を削除して新しいコミットを作成する
.gitignoreに該当ファイルのパターンを追加して再発を防ぐ- 必要に応じてリポジトリの管理者やセキュリティ担当者に報告する
5. Issue/PRテンプレートのサンプル
Issueテンプレート: 汎用タスク依頼
GitHubの .github/ISSUE_TEMPLATE/ フォルダにMarkdownファイルとして配置すると、Issue作成時にテンプレートとして選択できるようになります。
---
name: タスク依頼
about: Claude Codeへの作業依頼テンプレート
title: ''
labels: ''
assignees: ''
---
## タスクの概要
<!-- 何をしてほしいかを1〜2文で記載してください -->
## 詳細な要件
<!-- 成果物に含めるべき内容を箇条書きで記載してください -->
- [ ]
- [ ]
- [ ]
## 成果物
- **ファイル形式**: Markdown
- **保存先**: `/フォルダ名/`
- **ファイル名**: `ファイル名.md`
## 背景・補足情報
<!-- タスクの背景や参考情報があれば記載してください -->
## 完了条件
<!-- どうなれば完了とみなすかを記載してください -->
- [ ]
- [ ]Issueテンプレート: 不具合・修正依頼
---
name: 不具合・修正依頼
about: 成果物の誤りや改善点を報告するテンプレート
title: '[修正] '
labels: 'バグ'
assignees: ''
---
## 問題の概要
<!-- どのファイルにどのような問題があるかを記載してください -->
## 該当ファイル
- ファイルパス: <!-- 例: /research/market-report.md -->
## 問題の詳細
<!-- 具体的にどこが間違っているか、何を改善すべきかを記載してください -->
## 期待する状態
<!-- 正しくはどうあるべきかを記載してください -->
## 優先度
- [ ] 高（業務に支障がある）
- [ ] 中（修正が望ましい）
- [ ] 低（時間があるときに対応）Issueテンプレート: リサーチ依頼
---
name: リサーチ依頼
about: 情報収集・調査をClaude Codeに依頼するテンプレート
labels: 'リサーチ'
assignees: ''
---
## 調査テーマ
<!-- 何について調査してほしいかを記載してください -->
## 背景・目的
<!-- なぜこの調査が必要なのかを記載してください -->
## 調査の範囲
<!-- どこまで調べてほしいかを記載してください -->
## 成果物の要件
- 形式: Markdown
- 保存先: `/research/`
- ファイル名: <!-- 例: market-trends-2026.md -->
- 分量の目安: <!-- 例: 2000〜3000字 -->
## 対象読者
<!-- 誰が読むか、知識レベルは -->
## 期限
<!-- いつまでに必要か -->PRテンプレート
リポジトリの .github/pull_request_template.md に配置すると、PR作成時に自動で本文に挿入されます。
## 概要
<!-- このPRで何を行ったかを簡潔に記載してください -->
## 関連Issue
<!-- 関連するIssue番号を記載してください -->
Closes #
## 変更内容
<!-- 追加・変更したファイルと内容を箇条書きで記載してください -->
-
## 確認してほしいポイント
<!-- レビュアーに特に見てほしい箇所があれば記載してください -->
-
## チェックリスト
- [ ] CLAUDE.mdのルールに従っている
- [ ] 機密情報が含まれていない
- [ ] 日本語の表記が統一されている
- [ ] ファイルが指定のフォルダに配置されている6. よくある質問 FAQ
Q1: リポジトリのPublicとPrivateの違いは何ですか？
A: Publicリポジトリはインターネット上の誰でも閲覧できます。Privateリポジトリは自分と、明示的にアクセス権を付与した人だけが閲覧できます。業務で使用する場合は、基本的に Private を選択してください。
Q2: CLAUDE.mdはなぜ必要なのですか？
A: CLAUDE.mdはClaude Codeに対する「業務マニュアル」のような役割を持ちます。作業ルール、フォルダ構成、注意事項などを記載しておくと、Claude Codeがそのルールに従って作業してくれます。毎回細かい指示を出さなくても一貫した成果物が得られるため、作業効率と品質の両方が向上します。
Q3: IssueとPull Requestの違いがわかりません。
A: 簡単に言うと、Issueは「やるべきこと」を記録するメモ、Pull Request（PR）は「やったこと」を確認してもらう仕組みです。
| Issue | Pull Request | |
|---|---|---|
| 役割 | タスクの定義・依頼 | 成果物の確認・承認 |
| タイミング | 作業の前に作成 | 作業の後に作成 |
| たとえ | 仕事の依頼書 | 完成した書類の回覧板 |
一般的な流れ: Issue作成 → 作業実施 → PR作成 → レビュー → マージ → Issue自動クローズ
Q4: ブランチとは何ですか？なぜ必要なのですか？
A: ブランチは「作業用の分岐」です。mainブランチ（本流）を直接変更せず、別の場所で作業してから統合する仕組みです。Claude Codeが作業する際に自動的にブランチを作成してくれるので、普段は意識する必要はありません。PRをマージすることで、ブランチの内容がmainブランチに取り込まれます。
Q5: PRをマージした後にミスに気づきました。元に戻せますか？
A: はい、可能です。マージ済みのPRを開くと「Revert」ボタンが表示されます。これをクリックすると、マージ前の状態に戻すための新しいPRが自動作成されます。GitHubは変更履歴をすべて保持しているため、過去のどの時点にも戻ることができます。
Q6: 機密情報を誤ってコミットしてしまいました。どうすればよいですか？
A: 最優先で行うこと: 該当するパスワードやAPIキーを直ちに変更・無効化してください。ファイルから削除するだけでは、過去のコミット履歴に情報が残ります。パスワード等を変更した上で、ファイルからも機密情報を削除し、.gitignore に追加して再発を防ぎましょう。不安な場合はセキュリティ担当者に相談してください。
Q7: Claude Codeに作業を依頼する際、Issueの番号を毎回指定する必要がありますか？
A: 必須ではありませんが、指定することを強く推奨します。Issue番号を指定すると、Claude CodeがIssueの内容（タイトル、説明、要件など）を正確に読み取って作業してくれます。「Issue #3 の内容に取り組んでください」のように伝えるのが最も確実です。
Q8: 一度に複数のIssueをClaude Codeに依頼できますか？
A: 技術的には可能ですが、1つずつ依頼する方が成果物の品質が安定します。1つのIssueの作業が完了してPRを作成した後に、次のIssueに取りかかるのがお勧めの進め方です。こうすることで、各成果物を個別にレビューでき、問題の切り分けもしやすくなります。
Q9: GitHubの無料プランでどこまでできますか？
A: GitHubの無料プラン（Free）でも、本教材で紹介している機能はすべて利用できます。
| 機能 | 無料プランでの利用 |
|---|---|
| Privateリポジトリの作成 | 無制限 |
| Issue管理 | 利用可能 |
| Pull Request | 利用可能 |
| プロジェクトボード | 利用可能 |
| コラボレーター追加 | 利用可能 |
| GitHub Actions（自動化） | 月2,000分まで無料 |
個人や小規模チームでの利用には十分な内容です。
Q10: リポジトリが増えてきた場合、どう整理すればよいですか？
A: 以下の4つの方法で整理できます。
- 命名規則を統一する:
部署名-プロジェクト名のような規則を決める（例:sales-market-research,hr-onboarding-docs） - Descriptionを必ず書く: リポジトリの説明欄に用途を簡潔に記載する
- 不要なリポジトリはアーカイブする: Settings →「Archive this repository」で読み取り専用にできる。削除ではなく、履歴を残したまま整理できる
- トピック（タグ）を付ける: リポジトリのトップページで「Add topics」からタグを追加すると、検索や分類がしやすくなる