はじめに

「Claude Desktopを導入したいけど、何からどの順番で学べばいいかわからない」

この記事は、Claude Desktopをゼロから使いこなすまでの全ステップを体系的に整理したロードマップです。セットアップ・GitHub MCP連携・ベストプラクティスまで、関連記事へのナビゲーションも含めて完全解説します。

Claude Desktopとは？30秒でわかる概要

Claude Desktopは、ClaudeをネイティブアプリとしてPC上で動かすデスクトップアプリケーションです。

Web版との最大の違い：MCP（Model Context Protocol）対応

Claude Desktop
    ↓
MCPサーバー接続
    ↓
✅ GitHubリポジトリを直接操作
✅ ローカルファイルの読み書き
✅ Slack・Notionへのアクセス
✅ データベース操作
✅ 9,400種類以上のツール連携（2026年中旬時点）

ローカルMCPによる「外部ツールとの連携」が、Desktop版の最大の強みです。なお、2026年1月よりWeb版（有料プラン）でもリモートMCP（Connectors機能）が利用可能になりました。また、2026年2月10日にはWindows版が正式リリースされ、macOS版と同等の機能が利用可能になっています。

Claude Desktop vs Web版の主要差分

Claude Desktop習得ロードマップ

STEP 1: 基本を理解する（30分）
  → Web版との違い・できることを把握

STEP 2: セットアップ（30〜60分）
  → インストール + GitHub MCP設定

STEP 3: ベストプラクティスを身につける
  → トークン節約・効率的な使い方

STEP 4: 応用（オプション）
  → 他のMCPサーバー追加・高度な活用

STEP 1：Claude Desktopの全体像を把握する

まずClaude Desktopがどんなことができるのか、Web版・Claude Codeとどう違うのかを理解しましょう。

Claude Desktop ベストプラクティス完全ガイド

メリット・デメリット・MCP活用・トークン消費の管理まで、Claude Desktop活用の全てを網羅した記事：

【2026年版】Claude Desktop 効果的な活用ガイド - メリット・デメリット・ベストプラクティス完全版

はじめにClaude Desktopは、Claudeをネイティブアプリとして利用できる強力なツールです。本記事では、Web版との違い、効果的な使い方、トークン消費を最小化するテクニック、そして今後の展望まで、実践的な知見を完全網羅します。(...

caymezon.com

2026.01.24

この記事で分かること：

• MCP統合でできること（GitHub・Slack・DBなど）
• ローカルファイルシステムへのアクセス方法
• トークン消費の仕組みと使用量制限
• トークンを節約する6つのテクニック
• デメリット・注意点の整理
• 今後の展望（Tool Search機能など）

STEP 2：セットアップ（GitHub MCP連携）

Claude Desktopの真価はGitHub MCPとの連携にあります。設定は30分程度で完了します。

Claude Desktop + GitHub MCP 完全セットアップガイド

Node.jsのインストールから、GitHub PATの作成・設定ファイル編集・動作確認まで、初心者でも30分で完了できる手順を画像付きで解説：

【2026年最新版】Claude Desktop + GitHub MCP 完全セットアップガイド - 初心者でも30分で完了

はじめにClaude Desktop + GitHub MCP（Model Context Protocol） を使えば、あなたのGitHubリポジトリ全体をClaudeから直接操作できます。この記事では、完全初心者でも30分でセットアップ...

caymezon.com

2026.01.24

セットアップ完了後にできること：

✅ ファイルサイズ制限なし（プロジェクト機能の4KB制限を回避）
✅ リポジトリ全体にリアルタイムアクセス
✅ ファイルの読み書き・編集
✅ Issue/PR管理
✅ 常に最新版を参照
✅ プライベートリポジトリにもアクセス可能

実際の活用例：

あなた: 「publish.jsの行742-766を確認して」

Claude Desktop:
[GitHub MCPでリポジトリから最新版を取得]
[35KB全文を確認]
「複数スラッグ対応が正しく実装されています...」

Desktop Extensionsによる簡単インストール（2026年新機能）

2026年より、**Desktop Extensions（.mcpbファイル）**による簡単なMCPインストールが利用可能になりました。従来のJSON設定ファイルの手動編集なしに、ブラウザ拡張機能と同じ感覚でMCPサーバーをインストールできます。

インストール方法：
1. 設定 > Extensions から拡張機能を追加
2. または .mcpb ファイルをダブルクリック
→ ターミナル操作・JSON編集不要で即使用可能

GitHub MCPなど主要なサーバーを試す際は、従来のJSON設定に加えてDesktop Extensionsも活用できます。

Cowork（デスクトップエージェント）：2026年新機能

2026年初頭に発表されたCoworkは、Claude Desktopに統合された自律型デスクトップエージェントです。技術的な知識がなくても、フォルダを指定してやりたいことを伝えるだけで、複数ステップのタスクを自律的に実行します。

Coworkの主な用途:
✅ ファイルの整理・分類・名前変更
✅ ドキュメントの要約・データ抽出
✅ 画像からのデータ読み取り
✅ 複数ステップのデスクトップ作業の自動化
✅ 実際のファイルへの読み書き（完成したファイルをフォルダに保存）

Claude Code との使い分け：

セットアップの流れ（概要）

STEP 3：ベストプラクティスでトークンを節約する

Claude Desktopを効率的に使うには、トークン消費の管理が重要です。

重要な前提：トークンはすべて共有

Web版 + Desktop版 + Claude Code
        ↓
   同じ使用量制限（5時間あたり約44,000トークン）

トークン節約の主要テクニック

1. タスクごとに新規会話を開始する

❌ 悪い例: 1つの会話で全作業を継続
  → 会話履歴が膨大化 → 毎回再処理 → トークン消費加速

✅ 良い例: タスクごとに新規会話
  → 会話A: 「記事作成」
  → 会話B: 「コードレビュー」
  → 会話C: 「翻訳作業」

2. 質問をまとめて送る

❌ 3回に分けると: 約25,000トークン消費
✅ 1回にまとめると: 約10,000トークン消費
→ 60%節約

3. 不要なMCPサーバーを無効化する

MCPツール定義のトークン消費:
GitHub MCP単体: 約5,000トークン
4つのMCPサーバー: 約67,000トークン

→ 使わないMCPはコメントアウトして無効化

4. /compact コマンドで会話を圧縮する

/compact 「コード実装部分に焦点を当てて要約」
→ 会話履歴を大幅削減しながら流れを保持

詳しいベストプラクティスはこちら：

【2026年版】Claude Desktop 効果的な活用ガイド - メリット・デメリット・ベストプラクティス完全版

はじめにClaude Desktopは、Claudeをネイティブアプリとして利用できる強力なツールです。本記事では、Web版との違い、効果的な使い方、トークン消費を最小化するテクニック、そして今後の展望まで、実践的な知見を完全網羅します。(...

caymezon.com

2026.01.24

トラブルシューティング：よくある問題と解決法

プロジェクト機能でファイルが文字化けする

Claude Desktopのプロジェクト機能にJavaScriptファイルをアップロードすると、日本語コメントが文字化けする問題があります。

解決策（2通り）：

1. UTF-8 BOM付きで保存する（VSCodeで簡単に対応可能）
2. GitHub MCPを使う（根本的な解決策）

この問題の詳細な原因と解決方法：

【2026年1月】Claudeプロジェクトのファイル文字化け問題と解決法 - UTF-8 BOM付き保存の効果

はじめにClaudeのProプラン以上で利用できる「プロジェクト機能」で、JavaScriptファイルをアップロードすると日本語コメントが文字化けするという問題に遭遇しました。本記事では、この問題の原因究明から解決までの実体験を詳しく解説し...

caymezon.com

2026.01.24

プロジェクトファイルの4KB制限を回避したい

プロジェクト機能のファイル添付には約4KB（約114行）の制限があります。

解決策：GitHub MCP

GitHub MCPを使えばリポジトリ全体にリアルタイムアクセスでき、ファイルサイズ制限を完全に回避できます。

プロジェクトファイル vs GitHub MCP 比較:

| 項目 | プロジェクトファイル | GitHub MCP |
|------|---------------------|------------|
| エンコーディング | BOM必要 | 不要 ✅ |
| ファイルサイズ | 約30KB | 無制限 ✅ |
| 更新 | 手動アップロード | リアルタイム ✅ |
| 複数ファイル | 個別管理 | リポジトリ全体 ✅ |

Claude Desktop vs Web版：どちらを使う？

詳しい使い分けの判断基準はこちら：

【2026年版】Claude Web版 vs Desktop版 完全比較｜GitHub連携の設定（5分・30分）から使い分けまで徹底解説

はじめに「Claude Web版とDesktop版って何が違うの？」Claudeを使い始めた多くのユーザーが最初に抱く疑問です。特にGitHub連携に関しては、Web版とDesktop版で設定方法も機能も大きく異なります。この記事では、初心...

caymezon.com

2026.02.07

簡易判断基準

今後追加予定の活用コンテンツ

Claude Desktopのエコシステムは急速に拡大しており、2026年中旬時点で公式MCPレジストリには9,400本以上のサーバーが登録されています。以下のトピックについても随時記事を追加予定です：

📌 追加予定記事
├─ GitHub以外のMCPサーバー活用（Slack・Notion・DB等）
├─ Desktop Extensions（.mcpb）を使ったワンクリックMCP導入
├─ 複数MCPサーバーの組み合わせ活用術
├─ Claude Desktop × 自作MCPサーバー入門
├─ Cowork（デスクトップエージェント）活用術
└─ 企業向けMCP機能（Okta連携・MFAオーサリゼーション・監査ログ）

まとめ：Claude Desktop習得の最短ルート

今日やること:
1. Claude Desktopをインストール（5分）
   https://claude.ai/download

2. GitHub MCPをセットアップ（30分）
   → caymezon.com/claude-desktop-github-mcp-setup-guide/

3. ベストプラクティスを読む
   → caymezon.com/claude-desktop-best-practices-guide/

Claude Desktopを使いこなすことで、GitHubリポジトリを起点とした強力なAI開発支援環境が整います。特にMCPによる外部ツール連携は、一度体験すると手放せなくなります。

関連記事

• Claude AI全製品の入門ガイド（Web版・Desktop版・Claude Codeの選び方）

【2026年版】Claude AI完全入門ガイド｜Web版・Desktop版・Claude Codeの違いと選び方を徹底解説

はじめに「Claudeを使ってみたいけど、Web版・Desktop版・Claude Codeって何が違うの？」Anthropicが提供するClaude AIには複数の製品があり、初めて触れる方はどれを使えばいいか迷うことが多いです。この記事...

caymezon.com

2026.03.21

• Claude Code完全攻略ロードマップ

【2026年版】Claude Code完全攻略ロードマップ｜セットアップからVSCode活用・コマンド習得まで全記事まとめ

はじめに「Claude Codeに興味があるけど、何から始めればいいかわからない」「Claude Codeを使い始めたけど、もっと使いこなしたい」この記事は、Claude Codeに関するすべての記事を体系的にまとめたロードマップです。初心...

caymezon.com

2026.03.21

参考リンク

• Claude公式ドキュメント
• Model Context Protocol
• Claude Desktop ダウンロード
• GitHub MCP Server
• MCPサーバー一覧

更新履歴

• 2026-03-21: 初版公開
• 2026-04-20: Web版リモートMCP対応・Desktop Extensions（.mcpb）追加・MCPサーバー数を最新化
• 2026-06-20: Windows版正式リリース（2026年2月）の反映・Cowork（デスクトップエージェント）セクション追加・MCPサーバー登録数を最新化・比較表にOS対応列とCowork列を追加

The post 【2026年版】Claude Desktop完全攻略ロードマップ｜MCP設定・GitHub連携・活用術を体系的に学ぶ first appeared on CayTech Lab.

はじめに

「Claude Web版とDesktop版って何が違うの？」

Claudeを使い始めた多くのユーザーが最初に抱く疑問です。特にGitHub連携に関しては、Web版とDesktop版で設定方法も機能も大きく異なります。

この記事では、初心者でも迷わないよう、両方の違いを徹底比較し、Web版（設定5分）・Desktop版（設定30分）それぞれでGitHub連携を使えるようになるまでの詳細手順を完全解説します。

🤔 この記事を読むべき人

✅ Claudeを使い始めたばかり
✅ Web版とDesktop版の違いが分からない
✅ GitHubリポジトリをClaudeで扱いたい
✅ どちらを使うべきか迷っている
✅ 両方の設定方法を知りたい

📊 Web版 vs Desktop版 - 一目で分かる比較表

基本情報

GitHub連携

パフォーマンス

拡張性

🌐 Part 1: Web版のGitHub連携設定（5分で完了）

前提条件

✅ GitHubアカウント（無料でOK）
✅ Claudeアカウント（Free以上）
✅ ブラウザ（Chrome/Edge/Safari/Firefox）

ステップ1: Claude GitHub Appのインストール

1-1. GitHubにアクセス

以下のURLにアクセスします：

https://github.com/apps/claude/installations/select_target

1-2. アカウント選択

• 個人アカウントを選択
• またはOrganizationを選択（管理者権限が必要）

1-3. リポジトリアクセスを設定

推奨設定：

◉ All repositories（全リポジトリ）
  → 最も簡単、新規リポジトリも自動で対象

◯ Only select repositories（特定リポジトリのみ）
  → セキュリティ重視の場合

1-4. インストール実行

「Install & Authorize」をクリック

⚠️ 注意： 個人アカウントのリポジトリが表示されない既知のバグが2026年2月頃に報告されていました。現在は解消されている場合も多いですが、表示されない場合は後述の回避策を参照してください。

ステップ2: Claude.aiでリポジトリを追加

2-1. 新しいチャットを開始

claude.aiにアクセスし、新しいチャットを作成

2-2. リポジトリを追加

1. 左下の「+」ボタンをクリック
2. 「Add from GitHub」を選択
3. リポジトリリストから目的のリポジトリを選択
4. 必要なファイル・フォルダを選択

2-3. 確認

以下のメッセージで動作確認：

選択したリポジトリの構造を教えてください

⚠️ トラブルシューティング（Web版）

問題1: リポジトリが表示されない

原因： Claude GitHub Appが未インストール、または権限不足

解決策：

1. GitHub Settings - Applicationsを開く
2. 「Claude」が表示されているか確認
3. 表示されていない場合、ステップ1からやり直し

問題2: 個人リポジトリが選択できない

原因： 2026年2月頃に報告されていた既知のバグ（現在は多くの環境で解消済み）

回避策：

1. リポジトリURLを直接貼り付け

   https://github.com/your-username/your-repo

2. プロジェクト機能でリポジトリを追加

問題3: ファイルが大きすぎる

原因： プロジェクトファイルは約4KB（114行）が上限

解決策：

• 小さなファイルのみプロジェクトに追加
• 大きなファイルはDesktop版 + GitHub MCPを検討

💻 Part 2: Desktop版のGitHub連携設定（30分で完了）

Desktop版では、MCP（Model Context Protocol） を使ってGitHubと連携します。設定は少し複雑ですが、一度設定すれば非常に強力です。

前提条件

✅ Windows 10/11、macOS、またはLinux
✅ Node.js 16以上
✅ GitHubアカウント
✅ Claude Proプラン以上

ステップ1: Node.jsのインストール（未インストールの場合）

Windows

1. Node.js公式サイトにアクセス
2. LTS版をダウンロード
3. インストーラーを実行（すべてデフォルト設定でOK）

確認

コマンドプロンプト（またはターミナル）で：

node --version

npm --version
# 10.x.x のように表示されればOK

ステップ2: Claude Desktopのインストール

2-1. ダウンロード

Claude公式ダウンロードページから、お使いのOS版をダウンロード

2-2. インストール

• Windows: .exeファイルを実行
• macOS: .dmgファイルをマウント
• Linux: 配布形式に応じてインストール

2-3. ログイン

Claude.aiアカウントでログイン

ステップ3: GitHub Personal Access Token（PAT）の作成

3-1. GitHubでトークン作成

1. GitHub Settings - Tokensにアクセス
2. 「Generate new token」→「Generate new token (classic)」を選択

3-2. トークン設定

3-3. スコープ（権限）を選択

最小限の推奨設定：

✅ repo (Full control of private repositories)
  └─ すべてのサブ項目も自動的に✅になる

✅ read:org (Read org and team membership)
  └─ Organizationのリポジトリにアクセスする場合のみ

より高度な操作を行う場合：

✅ workflow (Update GitHub Action workflows)
✅ user:email (Access user email addresses)

3-4. トークンをコピー

1. 「Generate token」をクリック
2. 表示されたトークン（ghp_xxxxxxxxxxxx）をコピー
3. 必ず安全な場所に保存（パスワードマネージャー推奨）

⚠️ 重要： このトークンは二度と表示されません。紛失した場合は新しいトークンを作成する必要があります。

ステップ4: Claude Desktop設定ファイルの編集

4-1. 設定ファイルの場所

Windows:

%APPDATA%\Claude\claude_desktop_config.json

macOS:

~/Library/Application Support/Claude/claude_desktop_config.json

Linux:

~/.config/Claude/claude_desktop_config.json

4-2. ファイルを開く

Windows:

notepad %APPDATA%\Claude\claude_desktop_config.json

macOS/Linux:

nano ~/Library/Application\ Support/Claude/claude_desktop_config.json

または、VSCodeなどのエディタで開きます。

4-3. 設定内容を記述

ファイルが空の場合、以下をコピー＆ペースト：

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_YOUR_TOKEN_HERE"
      }
    }
  }
}

重要： ghp_YOUR_TOKEN_HERE を、ステップ3でコピーした実際のトークンに置き換えてください。

4-4. 保存

Ctrl + S（Windows）またはCmd + S（macOS）で保存

ステップ5: Claude Desktopを再起動

1. Claude Desktopを完全に終了
   • Windowsの場合：タスクトレイのアイコンを右クリック→「終了」
   • macOSの場合：Cmd + Qで完全終了
2. Claude Desktopを再起動

ステップ6: 動作確認

6-1. 新しいチャットを作成

Claude Desktopで新規チャットを開始

6-2. テスト

以下のメッセージを送信：

私のGitHubリポジトリ一覧を表示してください

または

[リポジトリ名]リポジトリの構造を教えてください

6-3. 成功の確認

✅ 成功のサイン：

• 🔨 ハンマーアイコンが表示される
• GitHubリポジトリ情報が取得される
• ファイル一覧が表示される

❌ 失敗の場合：

• 「Could not connect to MCP server」エラー
• トラブルシューティングへ

⚠️ トラブルシューティング（Desktop版）

問題1: 「Could not connect to MCP server」エラー

原因： Node.jsが正しくインストールされていない、またはPATHが通っていない

解決策：

# Node.jsの確認
node --version
npm --version

# 表示されない場合、Node.jsを再インストール

問題2: ハンマーアイコンが表示されない

原因： 設定ファイルのJSON形式が間違っている

解決策：

1. JSONLintで設定ファイルを検証
2. カンマ、括弧、クォートの位置を確認
3. トークンが正しく貼り付けられているか確認

問題3: トークンが無効

原因： トークンの期限切れ、または権限不足

解決策：

1. GitHubでトークンの状態を確認
2. 必要に応じて新しいトークンを作成
3. repoスコープが✅になっているか確認

🎯 どちらを選ぶべきか？判断基準

Web版がおすすめな人

✅ すぐに使い始めたい
✅ 設定が簡単な方がいい
✅ 複数デバイスで使いたい（PC、タブレット等）
✅ たまにGitHubを参照する程度
✅ チャットごとに特定のリポジトリを見る
✅ リンクでチャットを共有することが多い

具体例：

• ブログ記事のアイデア出し
• たまに自分のリポジトリを確認
• 他の人とチャット履歴を共有

Desktop版がおすすめな人

✅ 開発作業が中心
✅ 複数リポジトリを横断的に扱う
✅ ファイルの読み書き・編集が必要
✅ 長時間の作業セッションが多い
✅ Issue/PR作成など高度な操作が必要
✅ Notion、Slack、DBなど他ツールも連携したい

具体例：

• コードレビュー
• 複数リポジトリの比較分析
• 自動化ワークフロー構築
• 大規模なリファクタリング

実際の使用頻度による判断

料金による違いは？

重要： Web版もDesktop版も料金は同じです。

Web版: Proプラン $20/月 / Max 5xプラン $100/月 / Max 20xプラン $200/月
Desktop版: 同じプランが適用（追加料金なし）

トークン消費も同じ：

• 同じアカウント
• 同じ usage limit（5時間のローリングセッション、実際の上限はAnthropicが非公開）
• Desktop版だからといって消費が増えるわけではない

💡 実践的な使い分け例

パターン1: 両方を併用

多くのユーザーが実践している賢い使い方：

【Web版】
- 簡単な質問・調査
- 外出先での確認
- チームとのチャット共有
- 新しい機能の試用

【Desktop版】
- 本格的な開発作業
- コードレビュー
- 複数リポジトリの横断分析
- 長時間の集中作業

パターン2: プロジェクト別に使い分け

プロジェクトA（小規模ブログ）
→ Web版で十分
  └─ たまに記事のアイデア出し
  └─ リポジトリ構造は単純

プロジェクトB（大規模Webアプリ開発）
→ Desktop版を活用
  └─ 毎日コードレビュー
  └─ 複数リポジトリ（フロント/バック/インフラ）
  └─ GitHub Issue/PR管理

パターン3: 作業内容で使い分け

朝（計画フェーズ）
→ Web版
  └─ 今日のタスク確認
  └─ Issue一覧の閲覧

日中（実装フェーズ）
→ Desktop版
  └─ コード編集
  └─ ファイル操作
  └─ PR作成

夕方（レビューフェーズ）
→ Web版 or Desktop版
  └─ 進捗報告の作成
  └─ チームへの共有

📊 具体的な活用シーン

シーン1: ブログ記事作成（Web版）

1. 新しいチャット開始
2. 「+」ボタン → 「Add from GitHub」
3. ブログリポジトリを選択
4. 過去記事を参照しながら新記事のアイデア出し

あなた: 
「過去のAWS関連記事を参考に、
新しいLambda活用記事のアイデアを3つ提案してください」

Claude:
[過去記事を分析]
[新しい切り口を提案]

シーン2: コードレビュー（Desktop版）

あなた:
「caytech-blog-repoのscripts/publish.jsの
行742-766を確認して、
複数スラッグ対応が正しく実装されているかレビューしてください」

Claude:
[GitHub MCPで最新版を取得]
[35KB全文を確認]
[詳細なレビュー結果を提示]

シーン3: 複数リポジトリの比較（Desktop版）

あなた:
「以下のリポジトリのREADME.mdを比較して、
ドキュメント品質の改善点を提案してください：
- repo-A
- repo-B  
- repo-C」

Claude:
[3つのリポジトリに横断アクセス]
[それぞれのREADME.mdを取得]
[比較分析]
[改善提案]

シーン4: Issue管理（Desktop版）

あなた:
「『publish.js複数スラッグ対応の実装完了』という
Issueをcaytech-blog-repoに作成してください」

Claude:
[GitHub MCPでIssue作成]
[適切なラベルを付与]
[詳細な説明を記載]

🔄 移行を検討するタイミング

Web版 → Desktop版への移行検討

以下の兆候が見られたら、Desktop版への移行を検討しましょう：

❌ Web版の不満点が出てきたら
  └─ ブラウザタブが重くなる
  └─ 毎回リポジトリを追加するのが面倒
  └─ ファイルサイズ制限（4KB）に引っかかる
  └─ 複数リポジトリを比較したい

✅ Desktop版のメリットが明確になったら
  └─ GitHub操作の頻度が週4回以上
  └─ コードレビューが日常業務
  └─ Issue/PR作成を自動化したい

Desktop版 → Web版に戻る場合

Web版で十分だった場合：
  └─ 設定の手間 > 得られる利便性
  └─ GitHub操作が思ったより少ない
  └─ MCPの複雑さに対応できない

🚀 さらに高度な活用

Desktop版をマスターしたら、以下の記事でさらに効率化：

【2026年版】Claude Desktop 効果的な活用ガイド - メリット・デメリット・ベストプラクティス完全版

はじめにClaude Desktopは、Claudeをネイティブアプリとして利用できる強力なツールです。本記事では、Web版との違い、効果的な使い方、トークン消費を最小化するテクニック、そして今後の展望まで、実践的な知見を完全網羅します。(...

caymezon.com

2026.01.24

GitHub MCP設定の詳細なトラブルシューティングはこちら：

【2026年最新版】Claude Desktop + GitHub MCP 完全セットアップガイド - 初心者でも30分で完了

はじめにClaude Desktop + GitHub MCP（Model Context Protocol） を使えば、あなたのGitHubリポジトリ全体をClaudeから直接操作できます。この記事では、完全初心者でも30分でセットアップ...

caymezon.com

2026.01.24

📝 まとめ

Web版の特徴

✅ メリット
  - 設定が簡単（5分）
  - すぐに使える
  - 複数デバイス対応
  - チャット共有が簡単

❌ デメリット
  - 毎回リポジトリを手動追加
  - ファイル閲覧のみ
  - ブラウザ依存のパフォーマンス
  - 拡張性が限定的

Desktop版の特徴

✅ メリット
  - 全リポジトリに横断アクセス
  - ファイルの読み書き・編集可能
  - Issue/PR作成
  - 高いパフォーマンス
  - 100種類以上のツール連携

❌ デメリット
  - 設定が複雑（30分）
  - JSON編集が必要
  - Node.jsのインストール必要
  - 学習コストが高い

最終的な選択基準

【Web版を選ぶべき人】
週1-3回程度のGitHub利用
↓
設定5分、すぐに使える
↓
手動追加でも問題なし

【Desktop版を選ぶべき人】
週4回以上のGitHub利用
↓
設定30分、一度設定すれば快適
↓
自動化で大幅な効率化

どちらか迷ったら？

1. まずWeb版から始める
2. 使用頻度を記録（1-2週間）
3. 週4回以上ならDesktop版を検討
4. 両方を併用するのも◎

今日からできること

【Web版ユーザー】
✅ Claude GitHub Appをインストール（5分）
✅ リポジトリを追加して使ってみる

【Desktop版ユーザー】
✅ Node.jsをインストール（10分）
✅ Claude Desktopをインストール（5分）
✅ GitHub PATを作成（5分）
✅ 設定ファイルを編集（5分）
✅ 動作確認（5分）

💰 料金とトークン消費

共通事項

トークン消費の違い

Web版：

システムプロンプト: 約3,000トークン
プロジェクトファイル: ファイルサイズ次第（最大4KB）
会話履歴: 累積
→ 合計: 通常5,000-15,000トークン/メッセージ

Desktop版：

システムプロンプト: 約3,000トークン
MCPツール定義: 約5,000-80,000トークン（初回）
会話履歴: 累積
→ 合計: 初回10,000-85,000トークン、以降5,000-15,000トークン/メッセージ

重要： Desktop版はMCPツール定義で初回のトークン消費が多いですが、2回目以降はWeb版とほぼ同じです。なお、2026年よりTool Search（Lazy Loading）機能が追加され、使用するMCPツールのみ動的に読み込むことでコンテキスト使用量を最大95%削減できるようになりました。

🔮 今後の展望

2026年Q1-Q2の実績と今後の展望

2026年Q1（実現済み）:
✅ Web版でMax/Team/EnterpriseプランへのリモートMCPベータ提供開始
✅ Desktop版のTool Search（Lazy Loading）機能追加（コンテキスト最大95%削減）
✅ GitHub MCP Serverの公式化・機能強化
✅ Max 5x（$100/月）・Max 20x（$200/月）プランの提供開始
✅ OAuth 2.1対応によるエンタープライズ向けMCP強化

2026年Q3-Q4（予想）:
✅ Web版MCPのProプランへの一般ロールアウト
✅ プロジェクトファイル制限のさらなる緩和
✅ リアルタイムコラボレーション機能

懸念事項

⚠️ usage limitのさらなる制限強化の可能性
⚠️ Pro/Maxプランの価格改定の可能性
⚠️ Claude Code利用時のクォータ不足問題（2026年3月にAnthropicが認識・対応中）

📚 関連記事

より詳しいDesktop版の活用方法：

【2026年版】Claude Desktop 効果的な活用ガイド - メリット・デメリット・ベストプラクティス完全版

はじめにClaude Desktopは、Claudeをネイティブアプリとして利用できる強力なツールです。本記事では、Web版との違い、効果的な使い方、トークン消費を最小化するテクニック、そして今後の展望まで、実践的な知見を完全網羅します。(...

caymezon.com

2026.01.24

GitHub MCP設定の完全ガイド：

【2026年最新版】Claude Desktop + GitHub MCP 完全セットアップガイド - 初心者でも30分で完了

はじめにClaude Desktop + GitHub MCP（Model Context Protocol） を使えば、あなたのGitHubリポジトリ全体をClaudeから直接操作できます。この記事では、完全初心者でも30分でセットアップ...

caymezon.com

2026.01.24

• 【まとめ記事】Claude Desktop完全攻略ロードマップ｜MCP設定・GitHub連携・活用術を体系的に学ぶ

【2026年版】Claude Desktop完全攻略ロードマップ｜MCP設定・GitHub連携・活用術を体系的に学ぶ

はじめに「Claude Desktopを導入したいけど、何からどの順番で学べばいいかわからない」この記事は、Claude Desktopをゼロから使いこなすまでの全ステップを体系的に整理したロードマップです。セットアップ・GitHub MC...

caymezon.com

2026.03.21

• 【入門ガイド】Claude AI完全入門ガイド｜Web版・Desktop版・Claude Codeの違いと選び方

【2026年版】Claude AI完全入門ガイド｜Web版・Desktop版・Claude Codeの違いと選び方を徹底解説

はじめに「Claudeを使ってみたいけど、Web版・Desktop版・Claude Codeって何が違うの？」Anthropicが提供するClaude AIには複数の製品があり、初めて触れる方はどれを使えばいいか迷うことが多いです。この記事...

caymezon.com

2026.03.21

参考リンク

• Claude公式サイト
• Claude Desktop ダウンロード
• Model Context Protocol
• GitHub MCP Server 公式リポジトリ
• Node.js公式サイト
• GitHub Apps - Claude

更新履歴

• 2026-02-08: 初版公開
• 2026-07-18: タイトル・導入文を改善

Happy Coding with Claude! 🚀

The post 【2026年版】Claude Web版 vs Desktop版 完全比較｜GitHub連携の設定（5分・30分）から使い分けまで徹底解説 first appeared on CayTech Lab.

GitHubとは？

GitHubは、Gitリポジトリをクラウド上で管理できるプラットフォームです。2008年にサービス開始し、現在は1億人以上の開発者が利用しています。

Git vs GitHub

Gitがエンジン、GitHubがクラウド基盤と考えるとわかりやすいでしょう。

GitHubでできること

1. ソースコード管理

バージョン管理

git add .
git commit -m "機能追加"
git push origin main

変更履歴を完全に記録し、いつでも過去の状態に戻せます。

ブランチ戦略

main（本番）
  ↓
develop（開発）
  ↓
feature/new-function（機能追加）

複数人での並行開発を安全に実現します。

2. コラボレーション

Pull Request

コードレビューとマージを効率化：

1. ブランチで開発
2. Pull Request作成
3. チームメンバーがレビュー
4. 承認後マージ

Issue管理

タスク、バグ、機能要望を一元管理：

• ラベルで分類
• マイルストーンで進捗管理
• アサインで担当者明確化

3. CI/CD自動化（GitHub Actions）

ワークフロー例：

name: Deploy to Production
on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Build and Test
        run: |
          npm install
          npm test
      - name: Deploy
        run: npm run deploy

できること：

• 自動テスト実行
• 自動ビルド
• 自動デプロイ
• 定期実行タスク

GitHub Actionsの実践例は「【試行錯誤の記録】GitHub ActionsでWordPress自動投稿！403エラーとの戦い」で詳しく解説しています。

4. 静的サイトホスティング（GitHub Pages）

無料でWebサイト公開

gh repo create my-portfolio --public

# index.html作成
echo "
My Portfolio
" > index.html

# プッシュ
git add .
git commit -m "Initial commit"
git push origin main

# GitHub Pagesを有効化
# Settings → Pages → Source: main branch

公開URL： https://username.github.io/my-portfolio/

利用例：

• ポートフォリオサイト
• プロジェクトドキュメント
• ブログ（Jekyll/Hugo）
• ランディングページ

5. プロジェクト管理

Projects機能

カンバンボードでタスク管理：

To Do → In Progress → Done

ガントチャート表示やスプリント管理も可能です。

Discussions

コミュニティフォーラムとして活用：

• Q&A
• アイデア共有
• アナウンス

6. セキュリティ機能

Dependabot

依存パッケージの脆弱性を自動検出：

⚠️ Security Alert
package "lodash" has a vulnerability
→ Pull Request自動作成
→ ワンクリックで更新

Code scanning

コード内のセキュリティ問題を検出：

• SQL injection
• XSS脆弱性
• ハードコードされた認証情報

7. パッケージホスティング

GitHub Packages

コンテナイメージやライブラリを公開：

• Docker images
• npm packages
• Maven artifacts
• NuGet packages

GitHub Copilot：AI開発支援

Copilotとは

GitHub CopilotはOpenAIのCodexをベースにしたAIペアプログラマーです。

できること

1. コード補完

# コメントを書くだけでコード生成
# ユーザー認証機能
def authenticate_user(username, password):
    # ここから自動生成
    user = db.query(User).filter_by(username=username).first()
    if user and check_password_hash(user.password_hash, password):
        return user
    return None

2. テストコード自動生成

// 関数からテストを自動生成
function calculateTotal(items) {
    return items.reduce((sum, item) => sum + item.price, 0);
}

// Copilotがテストを提案
describe('calculateTotal', () => {
    it('should calculate sum correctly', () => {
        const items = [{price: 10}, {price: 20}];
        expect(calculateTotal(items)).toBe(30);
    });
});

3. コメント自動生成

既存コードに対して適切なドキュメントを生成します。

Copilot料金

Copilot CLI

コマンドライン操作もAI支援：

# 自然言語でコマンド生成
?? "kill process on port 3000"

# 提案
lsof -ti:3000 | xargs kill -9

# Gitコマンド支援
git? "create a new branch for feature"

CLIツールの詳細は「GitHub CLI完全ガイド：コマンドラインでGitHub操作を効率化」をご覧ください。

料金体系

無料プラン（Free）

個人開発者向け：

• パブリックリポジトリ：無制限
• プライベートリポジトリ：無制限
• GitHub Actions：2,000分/月
• GitHub Packages：500MB
• Codespaces：120コア時間/月

できること：

• 基本的なGit機能
• Issue/Pull Request
• GitHub Pages
• 基本的なCI/CD

有料プラン

Pro（$4/月）

追加機能：

• GitHub Actions：3,000分/月
• GitHub Packages：2GB
• 高度なコードレビューツール
• Wiki機能強化
• Insights詳細分析

おすすめ：

• 個人プロジェクトを本格運用
• ポートフォリオサイト運営

Team（$4/月/ユーザー）

追加機能：

• チーム管理機能
• Protected branches（ルール設定）
• Code owners
• Draft Pull Requests
• 50,000 Actions分/月

おすすめ：

• 小〜中規模チーム開発
• スタートアップ

Enterprise（$21/月/ユーザー）

追加機能：

• SAML SSO
• 監査ログ
• 高度なセキュリティ
• SLA保証
• プレミアムサポート

おすすめ：

• 大企業
• 高度なセキュリティ要件

学生・教育機関向け

GitHub Education：

• 学生：Pro機能無料
• 教員：Team機能無料
• GitHub Copilot無料

申請方法：

https://education.github.com/
→ 学生証または教員証明書をアップロード
→ 数日で承認

主要機能まとめ

GitHub Actions（CI/CD）

自動化できること：

• テスト実行
• ビルド
• デプロイ
• リリース作成
• Slack通知
• セキュリティスキャン

無料枠：

• パブリックリポジトリ：無制限
• プライベートリポジトリ：2,000分/月

GitHub Pages（静的サイト）

特徴：

• 完全無料
• HTTPS標準対応
• カスタムドメイン設定可能
• Jekyll/Hugo対応

制限：

• 1GB容量
• 月間100GB転送量
• 10ビルド/時間

GitHub Codespaces（クラウドIDE）

特徴：

• ブラウザでVSCode
• 環境構築不要
• リポジトリと連携

無料枠：

• 120コア時間/月
• 15GB/月ストレージ

GitHub Discussions（コミュニティ）

用途：

• Q&A
• アイデア収集
• アナウンス
• ショーケース

個人利用での活用法

1. ポートフォリオ管理

GitHub Pagesでポートフォリオサイト公開
↓
リポジトリで実績コード管理
↓
Contributionsグラフで活動可視化

2. 学習記録

学習プロジェクトをリポジトリ化
↓
README.mdに学習メモ
↓
GitHub Actionsで自動テスト

3. 個人ブログ運営

Jekyll/Hugo + GitHub Pages
↓
Markdown記事執筆
↓
git pushで自動公開

4. スクリプト管理

日常業務の自動化スクリプト
↓
Gistで共有
↓
バージョン管理

チーム開発での活用法

ブランチ戦略

Git Flow：

main（本番）
↓
release（リリース準備）
↓
develop（開発）
↓
feature/xxx（機能開発）

GitHub Flow（シンプル版）：

main（本番）
↓
feature/xxx（機能開発）

ブランチ戦略の詳細は「Git Branch戦略完全ガイド：チーム開発を成功させる実践パターン」をご覧ください。

コードレビュー

Pull Requestベストプラクティス：

• 小さな変更に分割
• 明確なタイトル
• 詳細な説明
• テスト結果添付
• レビュアー指定

セキュリティベストプラクティス

1. 認証情報を含めない

NGパターン：

API_KEY = "abc123xyz"  # ❌ ハードコード

OKパターン：

import os
API_KEY = os.getenv("API_KEY")  # ✅ 環境変数

2. .gitignoreを設定

# 機密情報
.env
config/secrets.yml

# 認証情報
*.pem
*.key

# ビルド成果物
node_modules/
dist/

3. Two-Factor Authentication有効化

Settings → Password and authentication
→ Enable two-factor authentication

4. Personal Access Token管理

Settings → Developer settings → Personal access tokens
→ Fine-grained tokens推奨
→ 必要最小限の権限
→ 有効期限設定

トラブルシューティング

問題1：git pushが403エラー

原因：

• 認証情報が古い
• Personal Access Token期限切れ

解決：

# 認証情報更新
git config --global credential.helper store
git push  # 新しいトークンを入力

問題2：Actions実行が失敗

原因：

• 無料枠超過
• Secretsの設定ミス

解決：

Settings → Secrets and variables → Actions
→ 環境変数を確認

問題3：GitHub Pages公開されない

原因：

• Pagesが有効化されていない
• index.htmlがない

解決：

Settings → Pages
→ Source: main branch
→ ルートディレクトリにindex.html配置

学習ロードマップ

ステップ1：基礎（1週間）

• リポジトリ作成
• コミット、プッシュ
• Pull Request作成

ステップ2：コラボレーション（2週間）

• Issue管理
• ブランチ戦略
• コードレビュー

ステップ3：自動化（1ヶ月）

• GitHub Actions基礎
• CI/CDパイプライン構築
• 自動テスト

ステップ4：高度な機能（2ヶ月）

• GitHub Copilot活用
• セキュリティ強化
• パフォーマンス最適化

まとめ

GitHubは単なるコード管理ツールではなく、開発ワークフロー全体を支える総合プラットフォームです。

できること：

• ソースコード管理（無制限）
• CI/CD自動化（GitHub Actions）
• 静的サイト公開（GitHub Pages）
• AIコーディング支援（Copilot）
• チームコラボレーション
• セキュリティ管理

料金：

• 基本機能は完全無料
• 高度な機能は月$4から
• 学生は無料でPro機能利用可能

おすすめ対象：

• 個人開発者：無料プランで十分
• チーム開発：Teamプラン推奨
• AI活用したい：Copilot Individual追加

GitHubを活用することで、開発効率が劇的に向上します。まずは無料プランから始めて、必要に応じて機能を拡張していきましょう！

関連記事

• GitHub CLI完全ガイド：コマンドラインでGitHub操作を効率化

GitHub CLI完全ガイド：コマンドラインでGitHub操作を効率化

GitHub CLI（ghコマンド）は、GitHubの操作をコマンドラインで完結できる公式ツールです。ブラウザを開かずに、リポジトリ作成からIssue管理、Pull Request作成まで、すべてターミナルで行えます。この記事では、実際の導...

caymezon.com

2026.01.31

• GitHubリポジトリ作成の2つの方法：GUI vs CLI徹底比較

GitHubリポジトリ作成の2つの方法：GUI vs CLI徹底比較

GitHubでリポジトリを作成する方法は大きく分けて2つあります。ブラウザを使ったGUI操作と、GitHub CLIを使ったコマンドライン操作です。この記事では、実際のPythonプロジェクトを例に、両方の方法を詳しく解説します。前提条件G...

caymezon.com

2026.01.31

• Git Branch戦略完全ガイド：チーム開発を成功させる実践パターン

【保存版】Git実務ガイド｜ブランチ戦略から失敗時のリカバリまで完全網羅

はじめにGitは強力なバージョン管理ツールですが、使い方を間違えると大変なことになります。この記事では、実務で使えるブランチ戦略から、よくある失敗とそのリカバリ方法まで、完全網羅します。対象読者：Gitの基本は分かるが、実務での使い方に不安...

caymezon.com

2026.01.12

The post GitHub完全ガイド：できること・料金・Copilot活用まで徹底解説 first appeared on CayTech Lab.

GitHubを始める前に

必要なもの

必須：

• GitHubアカウント（無料）
• Git（バージョン管理システム）
• テキストエディタ（VSCode推奨）

推奨：

• GitHub CLI（コマンドライン操作用）

アカウント作成

1. https://github.com にアクセス
2. Sign upをクリック
3. メールアドレス、パスワード、ユーザー名を入力
4. メール認証
5. 完了！

ユーザー名選びのポイント：

• 変更可能だが、推奨しない
• プロフィールURLになる：github.com/username
• 本名または認知されやすいID

GitHubの基本概念

リポジトリ（Repository）

プロジェクトを管理する単位です。

my-project/           ← リポジトリ
  ├── README.md       ← プロジェクト説明
  ├── index.html      ← ソースコード
  ├── style.css
  └── .gitignore      ← 管理対象外ファイル指定

コミット（Commit）

変更の記録単位です。

コミット1: 「初回作成」
コミット2: 「ログイン機能追加」
コミット3: 「バグ修正」

各コミットには誰が、いつ、何を変更したか記録されます。

ブランチ（Branch）

並行開発のための分岐です。

main（本番コード）
  ↓
develop（開発中）
  ↓
feature/login（ログイン機能開発中）

ブランチの詳しい使い方は「Git Branch戦略完全ガイド：チーム開発を成功させる実践パターン」をご覧ください。

リモートとローカル

ローカルリポジトリ（あなたのPC）
  ↕️ git push / git pull
リモートリポジトリ（GitHub）

ブラウザでの基本操作

リポジトリ作成

手順：

1. GitHubホーム右上の「+」
2. New repository
3. Repository name: my-first-repo
4. Public（公開）またはPrivate（非公開）
5. Add a README file: ✅チェック
6. Create repository

完了！ リポジトリが作成されました。

ファイル追加

Webインターフェースで：

1. Add file → Create new file
2. Name your file: hello.txt
3. 内容を入力
4. Commit new file

ローカルからプッシュ：

echo "Hello, GitHub!" > hello.txt

# Git管理に追加
git add hello.txt

# コミット
git commit -m "Add hello.txt"

# GitHubにプッシュ
git push origin main

Issue作成

バグ報告や機能要望を管理：

1. Issues タブ
2. New issue
3. タイトル: 「ログイン画面のバグ」
4. コメント: 詳細説明
5. ラベル: bug
6. Submit new issue

Pull Request

変更をマージする流れ：

1. ブランチで開発
2. Pull requests → New pull request
3. base: main ← compare: feature/login
4. Create pull request
5. レビュー待ち
6. Merge pull request

GUIとCLIでのリポジトリ作成の違いは「GitHubリポジトリ作成の2つの方法：GUI vs CLI徹底比較」で解説しています。

VSCodeでのGit操作

VSCodeはGitと深く統合されており、GUI操作で効率的に作業できます。

初期設定

Git設定確認：

git config --global user.name "Your Name"
git config --global user.email "your.email@example.com"

VSCode拡張機能インストール：

• GitLens（推奨）
• GitHub Pull Requests

リポジトリをクローン

方法1：コマンドパレット

Ctrl+Shift+P（Macは Cmd+Shift+P）
→ Git: Clone
→ GitHubリポジトリURL入力
→ 保存先選択

方法2：統合ターミナル

git clone https://github.com/username/repo.git

ファイル変更とコミット

手順：

1. ファイルを編集
2. 左サイドバー「ソース管理」アイコン（またはCtrl+Shift+G）
3. 変更ファイルの「+」をクリック（ステージング）
4. メッセージ入力：「ログイン機能追加」
5. ✓（チェック）ボタンでコミット

複数ファイル一括ステージング：

Changes の「+」アイコンですべてステージング

ブランチ操作

ブランチ作成：

1. 左下のブランチ名クリック
2. 「新しいブランチを作成」
3. ブランチ名入力：feature/new-function

ブランチ切り替え：

1. 左下のブランチ名クリック
2. 切り替え先ブランチを選択

マージ：

1. mainブランチに切り替え
2. コマンドパレット → Git: Merge Branch
3. マージ元ブランチ選択

VSCodeでのGit操作の詳細は「VSCodeでGitを使いこなす：初心者から実務まで完全ガイド」をご覧ください。

プッシュとプル

プッシュ（ローカル → GitHub）：

方法1：ソース管理パネルの「...」→ プッシュ
方法2：Ctrl+Shift+P → Git: Push

プル（GitHub → ローカル）：

方法1：ソース管理パネルの「...」→ プル
方法2：Ctrl+Shift+P → Git: Pull

コンフリクト解決

発生条件：

同じファイルの同じ箇所を
別々に編集してマージしようとした場合

VSCodeでの解決：

1. コンフリクトファイルを開く
2. <<<<<<< HEAD と >>>>>>> feature の間に表示
3. 「Current Change」「Incoming Change」「Both」から選択
4. 保存してコミット

CLIでの効率的な操作

コマンドライン操作に慣れると、作業が格段に速くなります。

基本コマンド

リポジトリ作成とプッシュ：

# ローカルで初期化
mkdir my-project
cd my-project
git init

# ファイル作成
echo "# My Project" > README.md

# コミット
git add .
git commit -m "Initial commit"

# GitHubと接続
git remote add origin https://github.com/username/my-project.git
git push -u origin main

クローン：

git clone https://github.com/username/repo.git
cd repo

状態確認：

# 変更ファイル確認
git status

# コミット履歴
git log --oneline

# ブランチ一覧
git branch -a

ブランチ操作

作成と切り替え：

# ブランチ作成
git branch feature/new-function

# 切り替え
git checkout feature/new-function

# 作成と切り替えを同時に
git checkout -b feature/new-function

マージ：

# mainに切り替え
git checkout main

# マージ
git merge feature/new-function

# プッシュ
git push origin main

削除：

# ローカルブランチ削除
git branch -d feature/new-function

# リモートブランチ削除
git push origin --delete feature/new-function

GitHub CLI活用

インストール：

# Windows
winget install GitHub.cli

# Mac
brew install gh

# 認証
gh auth login

便利なコマンド：

# リポジトリ作成
gh repo create my-project --public --source=. --push

# Issue作成
gh issue create --title "バグ修正" --body "詳細"

# Pull Request作成
gh pr create --title "新機能" --body "説明"

# リポジトリ情報表示
gh repo view

# ブラウザで開く
gh browse

GitHub CLIの使い方は「GitHub CLI完全ガイド：コマンドラインでGitHub操作を効率化」で詳しく解説しています。

個人利用での注意点

1. 公開リポジトリの扱い

Public = 全世界に公開

注意すべきこと：

• パスワード、APIキーを含めない
• 個人情報を含めない
• 企業秘密を含めない
• ライセンスを明記

NGパターン：

# ❌ ハードコード
API_KEY = "sk_live_abc123xyz"
PASSWORD = "mypassword123"

OKパターン：

# ✅ 環境変数
import os
API_KEY = os.getenv("API_KEY")
PASSWORD = os.getenv("PASSWORD")

2. .gitignoreの設定

必ず除外すべきファイル：

# 環境変数
.env
.env.local

# 認証情報
*.pem
*.key
config/secrets.yml

# ビルド成果物
node_modules/
dist/
build/

# IDE設定（個人差）
.vscode/
.idea/

# OS生成ファイル
.DS_Store
Thumbs.db

3. コミットメッセージ

良いコミットメッセージ：

# ✅ 明確で具体的
git commit -m "Add user authentication feature"
git commit -m "Fix login button alignment"
git commit -m "Update README with setup instructions"

悪いコミットメッセージ：

# ❌ 曖昧
git commit -m "update"
git commit -m "fix bug"
git commit -m "test"

4. ブランチ管理

個人開発でも推奨：

main        ← 本番コード（常に動作する状態）
develop     ← 開発中（テスト済み）
feature/xxx ← 機能開発（作業中）

NGパターン：

すべてmainで直接開発 ← 壊れたコードがそのまま本番に

5. セキュリティ設定

Two-Factor Authentication有効化：

Settings → Password and authentication
→ Enable two-factor authentication
→ SMS or Authenticator app

Personal Access Token：

Settings → Developer settings → Personal access tokens
→ Generate new token (classic)
→ 必要な権限のみ選択
→ 有効期限設定（推奨：90日）

6. コントリビューションの可視性

プロフィールに表示：

Settings → Public profile
→ Contribution settings
→ Private contributions を含める（オプション）

アクティビティグラフ：

• 緑色の四角：コミット数を可視化
• 就職活動でアピール材料に

7. ライセンス選択

推奨ライセンス：

• MIT License：最も自由（商用利用OK）
• Apache License 2.0：特許保護付き
• GPL v3：オープンソース強制

設定方法：

リポジトリ作成時
→ Add a README file
→ Choose a license
→ MIT License 選択

トラブルシューティング

問題1：git pushが拒否される

エラー：

! [rejected] main -> main (fetch first)

原因：
リモートに新しいコミットが存在

解決：

# リモートの変更を取得してマージ
git pull origin main

# コンフリクトがあれば解決

# 再度プッシュ
git push origin main

問題2：間違えてコミットした

まだプッシュしていない場合：

# 直前のコミットを取り消し（変更は保持）
git reset --soft HEAD~1

# 変更も取り消す
git reset --hard HEAD~1

プッシュ済みの場合：

# 新しいコミットで打ち消し
git revert HEAD
git push origin main

問題3：ファイルを削除したい（履歴からも）

機密情報を間違えてコミット：

# 特定ファイルを履歴から完全削除
git filter-branch --force --index-filter \
  "git rm --cached --ignore-unmatch secrets.txt" \
  --prune-empty --tag-name-filter cat -- --all

# 強制プッシュ
git push origin --force --all

注意： 履歴を変更するため、他の人が使っているリポジトリでは避ける

問題4：VSCodeでGitが認識されない

エラー：

Git not found. Install it or configure it using the 'git.path' setting.

解決：

1. Gitをインストール（https://git-scm.com/）
2. VSCode再起動
3. それでもダメなら settings.json に追加：
{
  "git.path": "C:\\Program Files\\Git\\bin\\git.exe"
}

学習のロードマップ

第1週：基礎

目標：

• リポジトリ作成
• ファイルをコミット
• GitHubにプッシュ

実践：

mkdir learning-git
cd learning-git
git init
echo "Day 1: Started learning Git" > journal.md
git add journal.md
git commit -m "Day 1: First commit"
gh repo create learning-git --public --source=. --push

第2週：ブランチとマージ

目標：

• ブランチ作成
• 変更をコミット
• マージ体験

実践：

git checkout -b feature/add-intro
echo "## Introduction" >> journal.md
git add journal.md
git commit -m "Add introduction section"
git checkout main
git merge feature/add-intro
git push origin main

第3週：コラボレーション

目標：

• Issue作成
• Pull Request作成
• コードレビュー体験

実践：

# Issue作成
gh issue create --title "Add contact page" --body "Need to add contact information"

# 開発
git checkout -b feature/contact-page
# ファイル編集...
git add .
git commit -m "Add contact page"
git push origin feature/contact-page

# Pull Request
gh pr create --title "Add contact page" --body "Closes #1"

第4週：実践プロジェクト

目標：

• ポートフォリオサイト作成
• GitHub Pagesで公開

実践：

gh repo create my-portfolio --public
cd my-portfolio
echo "
My Portfolio
" > index.html
git add .
git commit -m "Initial portfolio site"
git push origin main

# GitHub Pagesを有効化
# Settings → Pages → Source: main branch

まとめ

GitHubは開発者にとって必須のスキルです。

この記事で学んだこと：

• GitHubの基本概念（リポジトリ、コミット、ブランチ）
• ブラウザ、VSCode、CLIでの操作方法
• 個人利用での注意点（セキュリティ、.gitignore）
• トラブルシューティング

次のステップ：

1. まずは個人プロジェクトで練習
2. GitHub Pagesでポートフォリオ公開
3. オープンソースプロジェクトにコントリビュート
4. GitHub Actionsで自動化

最初は難しく感じるかもしれませんが、実際に手を動かしながら学ぶことで、確実に身につきます。まずは小さなプロジェクトから始めてみましょう！

関連記事

• VSCodeでGitを使いこなす：初心者から実務まで完全ガイド

VSCodeでGitを使いこなす完全ガイド｜GUI操作とCLIコマンドを徹底比較

はじめにVSCodeでアプリケーション開発をしている方の多くが、Gitによるバージョン管理を導入しています。しかし、「CLIコマンドならわかるけど、VSCodeのGUI操作がよくわからない」「どのメニューから操作すればいいのか迷う」といった...

caymezon.com

2026.02.02

• GitHub CLI完全ガイド：コマンドラインでGitHub操作を効率化

GitHub CLI完全ガイド：コマンドラインでGitHub操作を効率化

GitHub CLI（ghコマンド）は、GitHubの操作をコマンドラインで完結できる公式ツールです。ブラウザを開かずに、リポジトリ作成からIssue管理、Pull Request作成まで、すべてターミナルで行えます。この記事では、実際の導...

caymezon.com

2026.01.31

• Git Branch戦略完全ガイド：チーム開発を成功させる実践パターン

【保存版】Git実務ガイド｜ブランチ戦略から失敗時のリカバリまで完全網羅

はじめにGitは強力なバージョン管理ツールですが、使い方を間違えると大変なことになります。この記事では、実務で使えるブランチ戦略から、よくある失敗とそのリカバリ方法まで、完全網羅します。対象読者：Gitの基本は分かるが、実務での使い方に不安...

caymezon.com

2026.01.12

The post GitHub初心者ガイド：基本の使い方からVSCode連携・注意点まで実践解説 first appeared on CayTech Lab.

GitHub×AWSで実現できること

自動化の全体像

コード変更（git push）
  ↓
GitHub Actions自動実行
  ↓
ビルド・テスト
  ↓
AWSへ自動デプロイ
  ↓
本番環境更新

メリット：

• 手動デプロイの排除
• ヒューマンエラー削減
• リリース時間短縮
• 一貫性のある環境構築

できることの例

事前準備

必要なもの

GitHub側：

• GitHubアカウント
• リポジトリ（Public/Private）

AWS側：

• AWSアカウント
• IAMユーザー（適切な権限）
• 対象サービス（EC2/S3など）

IAMユーザー作成

手順：

1. AWSコンソール → IAM
2. Users → Add users
3. ユーザー名: github-actions-user
4. Access key - Programmatic access ✅
5. Attach policies directly:
   - AmazonEC2FullAccess（EC2デプロイ用）
   - AmazonS3FullAccess（S3デプロイ用）
6. Create user
7. Access Key ID と Secret Access Key を保存

注意： 本番環境では最小権限の原則に従い、必要な権限のみ付与してください。

GitHub Secretsに認証情報を保存

1. GitHubリポジトリ → Settings
2. Secrets and variables → Actions
3. New repository secret

登録する情報：
- AWS_ACCESS_KEY_ID: （IAMのAccess Key ID）
- AWS_SECRET_ACCESS_KEY: （IAMのSecret Access Key）
- AWS_REGION: ap-northeast-1（東京リージョン）

ハンズオン1：EC2にNode.jsアプリを自動デプロイ

システム構成

GitHub Repository
  ↓ git push
GitHub Actions
  ↓ SSH接続
EC2インスタンス
  ↓ アプリ更新
Webアプリ公開

EC2インスタンスの準備

1. インスタンス起動：

AMI: Amazon Linux 2023
インスタンスタイプ: t2.micro（無料枠）
セキュリティグループ:
  - SSH (22) ← 自分のIP
  - HTTP (80) ← 0.0.0.0/0
  - Custom (3000) ← 0.0.0.0/0（開発用）

2. SSH接続して環境構築：

ssh -i your-key.pem ec2-user@your-ec2-ip

# Node.jsインストール
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.0/install.sh | bash
source ~/.bashrc
nvm install 20
nvm use 20

# アプリディレクトリ作成
mkdir ~/myapp
cd ~/myapp

# pm2インストール（プロセス管理）
npm install -g pm2

3. SSH鍵をGitHub Secretsに登録：

秘密鍵（your-key.pem）の内容をコピー

GitHub Secrets に登録：
- EC2_SSH_KEY: （秘密鍵の内容）
- EC2_HOST: （EC2のパブリックIP）
- EC2_USER: ec2-user

サンプルアプリ作成

package.json：

{
  "name": "github-aws-demo",
  "version": "1.0.0",
  "scripts": {
    "start": "node server.js"
  },
  "dependencies": {
    "express": "^4.18.0"
  }
}

server.js：

const express = require('express');
const app = express();
const PORT = process.env.PORT || 3000;

app.get('/', (req, res) => {
  res.send(`
    
GitHub Actions × AWS EC2
    
自動デプロイ成功！
    
デプロイ時刻: ${new Date().toLocaleString('ja-JP')}
  `);
});

app.get('/health', (req, res) => {
  res.json({ status: 'OK' });
});

app.listen(PORT, () => {
  console.log(`Server running on port ${PORT}`);
});

GitHub Actions設定

.github/workflows/deploy-ec2.yml：

name: Deploy to EC2

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    
    steps:
      - name: Checkout code
        uses: actions/checkout@v3
      
      - name: Deploy to EC2
        env:
          SSH_KEY: ${{ secrets.EC2_SSH_KEY }}
          HOST: ${{ secrets.EC2_HOST }}
          USER: ${{ secrets.EC2_USER }}
        run: |
          # SSH秘密鍵を設定
          echo "$SSH_KEY" > private_key.pem
          chmod 600 private_key.pem
          
          # EC2にファイル転送
          scp -i private_key.pem -o StrictHostKeyChecking=no -r \
            server.js package.json ${USER}@${HOST}:~/myapp/
          
          # EC2でアプリ更新
          ssh -i private_key.pem -o StrictHostKeyChecking=no ${USER}@${HOST} << 'EOF'
            cd ~/myapp
            npm install
            pm2 restart myapp || pm2 start server.js --name myapp
            pm2 save
          EOF
          
          # 秘密鍵削除
          rm -f private_key.pem
      
      - name: Verify deployment
        run: |
          sleep 5
          curl -f http://${{ secrets.EC2_HOST }}:3000/health || exit 1
          echo "Deployment successful!"

デプロイ実行

1. リポジトリにプッシュ：

git add .
git commit -m "Add EC2 auto deploy"
git push origin main

2. GitHub Actionsで確認：

Actions タブ
→ Deploy to EC2 ワークフロー
→ ログ確認
→ ✅ 成功

3. ブラウザでアクセス：

http://your-ec2-ip:3000
→ 「自動デプロイ成功！」表示

完了！ コードを変更してpushするたびに自動デプロイされます。

GitHub Actionsの実践例は「【試行錯誤の記録】GitHub ActionsでWordPress自動投稿！403エラーとの戦い」でも紹介しています。

ハンズオン2：S3で静的サイトを自動公開

システム構成

GitHub Repository（HTML/CSS/JS）
  ↓ git push
GitHub Actions
  ↓ AWS CLI
S3バケット
  ↓ 静的Webホスティング
インターネット公開

S3バケット作成

1. バケット作成：

1. S3コンソール → Create bucket
2. Bucket name: my-github-demo-site（グローバルで一意）
3. Region: ap-northeast-1
4. Block Public Access: すべてOFF（公開用）
5. Create bucket

2. 静的Webホスティング有効化：

バケット → Properties
→ Static website hosting → Enable
→ Index document: index.html
→ Error document: error.html
→ Save changes

3. バケットポリシー設定：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PublicReadGetObject",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-github-demo-site/*"
    }
  ]
}

サンプルサイト作成

index.html：

  
  
  
  


  

    
GitHub Actions × S3
    
静的サイトの自動デプロイ成功！
    

  
  

style.css：

body {
  font-family: Arial, sans-serif;
  display: flex;
  justify-content: center;
  align-items: center;
  min-height: 100vh;
  margin: 0;
  background: linear-gradient(135deg, #667eea 0%, #764ba2 100%);
}

.container {
  background: white;
  padding: 2rem;
  border-radius: 10px;
  box-shadow: 0 10px 30px rgba(0,0,0,0.3);
  text-align: center;
}

h1 {
  color: #333;
  margin-bottom: 1rem;
}

script.js：

document.getElementById('timestamp').textContent = 
  `最終デプロイ: ${new Date().toLocaleString('ja-JP')}`;

GitHub Actions設定

.github/workflows/deploy-s3.yml：

name: Deploy to S3

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    
    steps:
      - name: Checkout code
        uses: actions/checkout@v3
      
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v2
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ${{ secrets.AWS_REGION }}
      
      - name: Sync to S3
        run: |
          aws s3 sync . s3://my-github-demo-site \
            --exclude ".git/*" \
            --exclude ".github/*" \
            --delete
      
      - name: Invalidate CloudFront (optional)
        run: |
          echo "CloudFront未使用の場合はスキップ"
          # aws cloudfront create-invalidation \
          #   --distribution-id YOUR_DISTRIBUTION_ID \
          #   --paths "/*"

デプロイ実行

1. プッシュ：

git add .
git commit -m "Add S3 static site deploy"
git push origin main

2. S3エンドポイントにアクセス：

http://my-github-demo-site.s3-website-ap-northeast-1.amazonaws.com

完了！ HTMLを変更するたびに自動で公開されます。

ハンズオン3：Lambda関数の自動デプロイ

システム構成

GitHub Repository（Lambda関数）
  ↓ git push
GitHub Actions
  ↓ zip & AWS CLI
Lambda関数更新
  ↓ API Gateway
REST API公開

Lambda関数作成

1. AWSコンソールでLambda作成：

Lambda → Create function
Function name: github-demo-function
Runtime: Node.js 20.x
Create function

2. 環境変数設定（オプション）：

Configuration → Environment variables
Key: STAGE
Value: production

サンプル関数

index.js：

exports.handler = async (event) => {
  console.log('Event:', JSON.stringify(event));
  
  const name = event.queryStringParameters?.name || 'World';
  const timestamp = new Date().toISOString();
  
  return {
    statusCode: 200,
    headers: {
      'Content-Type': 'application/json',
      'Access-Control-Allow-Origin': '*'
    },
    body: JSON.stringify({
      message: `Hello, ${name}!`,
      timestamp: timestamp,
      environment: process.env.STAGE || 'development',
      deployedBy: 'GitHub Actions'
    })
  };
};

package.json：

{
  "name": "github-lambda-demo",
  "version": "1.0.0",
  "description": "GitHub Actions Lambda deployment demo"
}

GitHub Actions設定

.github/workflows/deploy-lambda.yml：

name: Deploy to Lambda

on:
  push:
    branches: [main]
    paths:
      - 'lambda/**'

jobs:
  deploy:
    runs-on: ubuntu-latest
    
    steps:
      - name: Checkout code
        uses: actions/checkout@v3
      
      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '20'
      
      - name: Install dependencies
        working-directory: ./lambda
        run: npm install --production
      
      - name: Create deployment package
        working-directory: ./lambda
        run: |
          zip -r function.zip .
      
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v2
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ${{ secrets.AWS_REGION }}
      
      - name: Deploy to Lambda
        working-directory: ./lambda
        run: |
          aws lambda update-function-code \
            --function-name github-demo-function \
            --zip-file fileb://function.zip
      
      - name: Wait for update
        run: |
          aws lambda wait function-updated \
            --function-name github-demo-function
      
      - name: Test Lambda function
        run: |
          aws lambda invoke \
            --function-name github-demo-function \
            --payload '{"queryStringParameters":{"name":"GitHub"}}' \
            response.json
          cat response.json

API Gateway設定（オプション）

REST APIとして公開：

1. API Gateway → Create API
2. REST API → Build
3. Create resource: /hello
4. Create method: GET
5. Integration type: Lambda Function
6. Lambda Function: github-demo-function
7. Deploy API → Stage: prod

エンドポイント：

https://xxxxxxx.execute-api.ap-northeast-1.amazonaws.com/prod/hello?name=World

応用パターン

パターン1：環境別デプロイ

複数環境の管理：

on:
  push:
    branches:
      - main      # 本番環境
      - develop   # 開発環境

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Set environment
        run: |
          if [ "${{ github.ref }}" == "refs/heads/main" ]; then
            echo "ENVIRONMENT=production" >> $GITHUB_ENV
            echo "LAMBDA_FUNCTION=prod-function" >> $GITHUB_ENV
          else
            echo "ENVIRONMENT=development" >> $GITHUB_ENV
            echo "LAMBDA_FUNCTION=dev-function" >> $GITHUB_ENV
          fi
      
      - name: Deploy
        run: |
          aws lambda update-function-code \
            --function-name ${{ env.LAMBDA_FUNCTION }} \
            --zip-file fileb://function.zip

パターン2：ブルーグリーンデプロイ

無停止デプロイ：

- name: Create new version
  run: |
    VERSION=$(aws lambda publish-version \
      --function-name my-function \
      --query 'Version' --output text)
    echo "VERSION=$VERSION" >> $GITHUB_ENV

- name: Update alias
  run: |
    aws lambda update-alias \
      --function-name my-function \
      --name production \
      --function-version ${{ env.VERSION }}

パターン3：ロールバック機能

デプロイ失敗時の自動ロールバック：

- name: Deploy and test
  id: deploy
  run: |
    # デプロイ
    aws lambda update-function-code ...
    
    # ヘルスチェック
    if ! curl -f https://api.example.com/health; then
      exit 1
    fi

- name: Rollback on failure
  if: failure() && steps.deploy.outcome == 'failure'
  run: |
    aws lambda update-function-code \
      --function-name my-function \
      --s3-bucket backup-bucket \
      --s3-key previous-version.zip

トラブルシューティング

問題1：EC2デプロイでSSH接続失敗

エラー：

Permission denied (publickey)

原因：

• SSH鍵の改行コードが正しくない
• 鍵の権限が適切でない

解決：

# 改行コードを明示的に処理
run: |
  echo "$SSH_KEY" | tr -d '\r' > private_key.pem
  chmod 600 private_key.pem

問題2：S3デプロイで403エラー

原因：

• IAMユーザーに権限がない
• バケットポリシーが未設定

解決：

1. IAMユーザーに AmazonS3FullAccess 付与
2. バケットポリシーで PublicReadGetObject 設定
3. ブロックパブリックアクセスを確認

問題3：Lambda関数が更新されない

原因：

• 関数名が間違っている
• zipファイルサイズ超過（50MB制限）

解決：

# 関数名確認
aws lambda list-functions

# zipサイズ確認
ls -lh function.zip

# 大きい場合はS3経由でデプロイ
aws s3 cp function.zip s3://my-bucket/
aws lambda update-function-code \
  --function-name my-function \
  --s3-bucket my-bucket \
  --s3-key function.zip

セキュリティベストプラクティス

1. IAM権限の最小化

NG（フルアクセス）：

{
  "Effect": "Allow",
  "Action": "*",
  "Resource": "*"
}

OK（必要な権限のみ）：

{
  "Effect": "Allow",
  "Action": [
    "s3:PutObject",
    "s3:DeleteObject",
    "lambda:UpdateFunctionCode"
  ],
  "Resource": [
    "arn:aws:s3:::my-bucket/*",
    "arn:aws:lambda:ap-northeast-1:*:function:my-function"
  ]
}

2. Secrets管理

GitHub Secrets以外の選択肢：

• AWS Secrets Manager：より高度な管理
• AWS Systems Manager Parameter Store：無料枠あり

GitHub ActionsでSecrets Manager使用：

- name: Get secrets
  run: |
    SECRET=$(aws secretsmanager get-secret-value \
      --secret-id my-app-secret \
      --query SecretString --output text)
    echo "::add-mask::$SECRET"
    echo "SECRET=$SECRET" >> $GITHUB_ENV

3. 監査ログ

CloudTrailで操作履歴記録：

CloudTrail → Create trail
→ S3バケットに操作ログ保存
→ GitHub Actionsの操作も記録

まとめ

GitHub ActionsとAWSの連携で、強力な自動化基盤を構築できます。

実装したハンズオン：

1. EC2自動デプロイ：Node.jsアプリをSSH経由でデプロイ
2. S3静的サイト：HTML/CSS/JSを自動公開
3. Lambda関数：サーバーレス関数の自動更新

メリット：

• 手動作業の削減
• デプロイミスの防止
• 一貫性のある環境
• リリース時間の短縮

コスト：

• GitHub Actions：パブリックリポジトリは無料
• AWS無料枠：1年間または月次制限内
• 実質コスト：ほぼ無料で始められる

まずは簡単なS3デプロイから始めて、徐々に複雑な構成に挑戦してみましょう！

関連記事

• 【試行錯誤の記録】GitHub ActionsでWordPress自動投稿！403エラーとの戦い

【試行錯誤の記録】GitHub ActionsでWordPress自動投稿！403エラーとの戦い

はじめにVSCodeでMarkdownを書いて、git push するだけでWordPressに自動投稿される――そんな夢のようなシステムを作ろうと、GitHub Actions連携に挑戦しました。しかし、待っていたのは 403 Forbi...

caymezon.com

2026.01.12

• GitHub CLI完全ガイド：コマンドラインでGitHub操作を効率化

GitHub CLI完全ガイド：コマンドラインでGitHub操作を効率化

GitHub CLI（ghコマンド）は、GitHubの操作をコマンドラインで完結できる公式ツールです。ブラウザを開かずに、リポジトリ作成からIssue管理、Pull Request作成まで、すべてターミナルで行えます。この記事では、実際の導...

caymezon.com

2026.01.31

• VSCodeでGitを使いこなす：初心者から実務まで完全ガイド

VSCodeでGitを使いこなす完全ガイド｜GUI操作とCLIコマンドを徹底比較

はじめにVSCodeでアプリケーション開発をしている方の多くが、Gitによるバージョン管理を導入しています。しかし、「CLIコマンドならわかるけど、VSCodeのGUI操作がよくわからない」「どのメニューから操作すればいいのか迷う」といった...

caymezon.com

2026.02.02

The post GitHub×AWS実践ハンズオン：ActionsでEC2自動デプロイから始める連携活用術 first appeared on CayTech Lab.

GitHub CLIとは？

GitHub CLIは、Gitコマンドとは別の、GitHub専用のコマンドラインツールです。

Gitとの違い

つまり、Gitはローカル作業、GitHub CLIはGitHub上の作業を担当します。

インストール手順

Windows

方法1: wingetコマンド（推奨）

winget install GitHub.cli

実行すると以下のような出力が表示されます：

見つかりました GitHub CLI [GitHub.cli] バージョン 2.85.0
ダウンロード中...
インストールが完了しました

方法2: 公式インストーラー

1. https://cli.github.com/ にアクセス
2. 「Download for Windows」をクリック
3. .msiファイルをダウンロードして実行

インストール後の確認

重要: インストール後はコマンドプロンプトを再起動してください。

再起動後、以下のコマンドで確認：

gh --version

以下のように表示されればOKです：

gh version 2.85.0 (2024-XX-XX)

macOS

brew install gh

Linux

Ubuntuの場合：

sudo apt install gh

その他のディストリビューションは公式ドキュメントを参照してください。

認証設定

GitHub CLIを使うには、GitHubアカウントとの認証が必要です。

基本的な認証フロー

gh auth login

対話形式で以下を選択していきます：

1. アカウント選択

? What account do you want to log into?
> GitHub.com
  GitHub Enterprise Server

GitHub.com を選択します。

2. プロトコル選択

? What is your preferred protocol for Git operations?
> HTTPS
  SSH

HTTPS を選択します（一般的な使い方）。

3. 認証方法選択

? How would you like to authenticate GitHub CLI?
> Login with a web browser
  Paste an authentication token

Login with a web browser を選択します（推奨）。

4. ブラウザで認証

! First copy your one-time code: XXXX-XXXX
Press Enter to open github.com in your browser...

1. 表示されたワンタイムコードをコピー
2. Enterキーを押す
3. ブラウザが開くので、GitHubにログイン
4. コードを入力
5. 「Authorize github」をクリック

重要ポイント：

• ワンタイムコードには有効期限がある（通常15分）
• 素早く入力すること
• 手入力ではなくコピー&ペーストを推奨

認証完了の確認

gh auth status

以下のように表示されれば成功：

github.com
  ✓ Logged in to github.com as YOUR_USERNAME
  ✓ Git operations for github.com configured to use https protocol.
  ✓ Token: ghp_************************************

トラブルシューティング

エラー1: 'gh' は認識されていません

原因: インストール後にコマンドプロンプトを再起動していない

解決方法:

1. コマンドプロンプトを閉じる
2. 新しいコマンドプロンプトを開く
3. 再度 gh --version を実行

それでも解決しない場合は、環境変数のPATHに以下を追加：

C:\Program Files\GitHub CLI

エラー2: Uh oh, we couldn't find anything

原因: ワンタイムコードの入力ミスまたは有効期限切れ

解決方法:

1. gh auth login を再実行
2. 新しいワンタイムコードが表示される
3. すぐにコピーしてブラウザに入力
4. 手入力ではなくコピー&ペーストを使用

エラー3: Personal Access Tokenを使いたい場合

ブラウザ認証がうまくいかない場合：

gh auth login

認証方法選択で Paste an authentication token を選択

トークン作成手順：

1. https://github.com/settings/tokens にアクセス
2. 「Generate new token」→「Generate new token (classic)」
3. Note: github-cli-access
4. Expiration: 任意（推奨: 90 days）
5. Select scopes: repo にチェック
6. 「Generate token」をクリック
7. トークンをコピー（画面を離れると二度と見れない）
8. コマンドプロンプトに貼り付け

基本的な使い方

リポジトリ操作

リポジトリ作成

gh repo create my-project --public

# プライベートリポジトリ
gh repo create my-project --private

# 説明付きで作成
gh repo create my-project \
  --public \
  --description "プロジェクトの説明"

# 現在のフォルダをソースにして作成＆プッシュ
gh repo create my-project \
  --public \
  --source=. \
  --push

リポジトリ作成の詳細な手順は「GitHubリポジトリ作成の2つの方法：GUI vs CLI徹底比較」をご覧ください。

リポジトリ設定変更

# 説明文変更
gh repo edit --description "新しい説明文"

# プライベートに変更
gh repo edit --visibility private --accept-visibility-change-consequences

# 公開に変更
gh repo edit --visibility public --accept-visibility-change-consequences

# ホームページURL設定
gh repo edit --homepage "https://example.com"

# Wiki有効化
gh repo edit --enable-wiki

# Issue無効化
gh repo edit --disable-issues

リポジトリ情報表示

# 情報表示
gh repo view

# ブラウザで開く
gh repo view --web

Issue操作

Issue作成

# 対話形式で作成
gh issue create

# タイトルと本文を指定
gh issue create \
  --title "バグ報告" \
  --body "詳細な説明"

# ラベル付きで作成
gh issue create \
  --title "機能追加" \
  --body "詳細" \
  --label "enhancement"

Issue一覧表示

# オープンなIssue一覧
gh issue list

# すべてのIssue
gh issue list --state all

# 自分がアサインされているIssue
gh issue list --assignee @me

Issue表示

# Issue #123を表示
gh issue view 123

# ブラウザで開く
gh issue view 123 --web

Pull Request操作

PR作成

# 対話形式で作成
gh pr create

# タイトルと本文を指定
gh pr create \
  --title "機能追加: ユーザー認証" \
  --body "詳細な説明"

# ブラウザで開いて作成
gh pr create --web

PR一覧表示

# オープンなPR一覧
gh pr list

# 自分のPR
gh pr list --author @me

PR表示とマージ

# PR #456を表示
gh pr view 456

# PR #456をマージ
gh pr merge 456

その他便利なコマンド

現在のリポジトリを確認

gh repo view

ブラウザで開く

# リポジトリをブラウザで開く
gh browse

# 特定のIssueを開く
gh issue view 123 --web

# 特定のPRを開く
gh pr view 456 --web

GitHub Actionsの確認

# Workflow実行履歴
gh run list

# 最新のWorkflow詳細
gh run view

# 特定のWorkflowを表示
gh run view 12345

実践的な活用例

例1: 新規プロジェクトの開始

# プロジェクトフォルダ作成
mkdir my-new-project
cd my-new-project

# README作成
echo "# My New Project" > README.md

# Git初期化
git init
git add .
git commit -m "Initial commit"

# GitHubにリポジトリ作成＆プッシュ
gh repo create my-new-project --public --source=. --push

例2: Issueを作成してブラウザで確認

# Issue作成
gh issue create --title "バグ修正: ログイン失敗" --body "詳細な説明"

# Issue一覧を確認
gh issue list

# 最新のIssueをブラウザで開く
gh issue view 1 --web

例3: 既存リポジトリのクローンとPR作成

# リポジトリをクローン
gh repo clone username/repository

# ブランチ作成
git checkout -b feature-branch

# 変更をコミット
git add .
git commit -m "Add new feature"

# プッシュ
git push origin feature-branch

# PRを作成
gh pr create --title "新機能追加" --body "詳細"

GUIとの比較

作業速度の比較

GUI（ブラウザ）での新規リポジトリ作成:

1. ブラウザを開く（5秒）
2. GitHubにアクセス（5秒）
3. New repositoryをクリック（3秒）
4. フォームに入力（30秒）
5. Create repositoryをクリック（3秒）
6. ターミナルに戻る（3秒）
7. コマンドをコピペ（20秒）
8. プッシュ（10秒）

合計: 約79秒

CLI（gh コマンド）での新規リポジトリ作成:

1. コマンド1行で完了（5秒）

合計: 約5秒

具体的なコマンド例

実際に私が Claudeチャットエクスポートツール を管理するために使ったコマンド：

# リポジトリ作成（GUIなら1分以上かかる作業が5秒で完了）
gh repo create my-python --public --source=. --push

# 公開範囲変更（GUIなら設定画面を開いて変更が必要）
gh repo edit --visibility private --accept-visibility-change-consequences

# 情報確認（ブラウザを開く必要なし）
gh repo view

GitHub CLIを使うメリット

1. 作業効率の大幅向上

• ブラウザとターミナルを行き来する必要がない
• マウス操作が不要
• ショートカットキーで高速操作

2. 認証が楽

• 一度認証すれば以降はパスワード不要
• Personal Access Tokenの管理が不要
• セキュアな認証情報保存

3. スクリプト化・自動化が可能

# 複数リポジトリを一気に作成
for repo in project1 project2 project3; do
  gh repo create $repo --public
done

4. 一貫した操作感

• すべての操作がコマンドラインで統一
• Gitコマンドとシームレスに連携
• VSCodeなどのターミナルからも実行可能

5. リモート作業に最適

• SSHでリモートサーバーに接続している場合でも使える
• ブラウザが不要なため軽量
• スクリプトに組み込んで自動化可能

デメリットと対策

デメリット1: 学習コスト

対策: よく使うコマンドから徐々に覚える

# まずはこの3つから
gh repo create  --public --source=. --push
gh repo view
gh issue create

デメリット2: GUIほど直感的ではない

対策: --helpオプションを活用

gh repo --help
gh issue --help
gh pr --help

デメリット3: 初期セットアップが必要

対策: 一度セットアップすれば永続的に使える

学習ロードマップ

レベル1: 基本操作（1週間）

gh auth login
gh repo create
gh repo view

レベル2: Issue/PR管理（2週間）

gh issue create
gh issue list
gh pr create
gh pr merge

レベル3: 高度な操作（1ヶ月）

gh run list
gh release create
gh gist create

まとめ

GitHub CLIは、GitHubの操作を大幅に効率化できる強力なツールです。

こんな人におすすめ：

• 開発作業の効率を上げたい
• コマンドライン操作に慣れている
• 複数のリポジトリを管理している
• リモート環境で作業することが多い

初めての人へ：
まずは gh repo create と gh repo view から始めてみてください。慣れてくると、他のGitHub操作もCLIで行いたくなるはずです。

GitHubの操作をコマンドラインで完結させることで、開発フローが劇的に改善します。ぜひ試してみてください！

関連記事

• GitHubリポジトリ作成の2つの方法：GUI vs CLI徹底比較

GitHubリポジトリ作成の2つの方法：GUI vs CLI徹底比較

GitHubでリポジトリを作成する方法は大きく分けて2つあります。ブラウザを使ったGUI操作と、GitHub CLIを使ったコマンドライン操作です。この記事では、実際のPythonプロジェクトを例に、両方の方法を詳しく解説します。前提条件G...

caymezon.com

2026.01.31

• Claudeチャットを資産化！エクスポートデータを整形するPythonツール

Claudeチャットを資産化！エクスポートデータを整形するPythonツール

Claudeとの会話履歴は貴重な知的財産です。しかし、エクスポートしたJSONファイルは読みにくく、そのままでは活用しづらいのが現状です。この記事では、ClaudeのエクスポートデータをMarkdown形式に整形し、チャット毎に分割して保存...

caymezon.com

2026.01.31

The post GitHub CLI完全ガイド：コマンドラインでGitHub操作を効率化 first appeared on CayTech Lab.

前提条件

• GitHubアカウントを持っている
• Gitがインストール済み
• ローカルにプロジェクトフォルダがある

今回は以下のような構成のPythonプロジェクトを例にします：

C:\my-local\my-python\
├── claude_chat_exporter/
│   ├── exporter.py
│   ├── README.md
│   └── output/
├── .gitignore
├── README.md
└── requirements.txt

方法1: GUIでリポジトリ作成（ブラウザ）

ステップ1: GitHubでリポジトリを作成

1. https://github.com/new にアクセス
2. 以下を入力：
   • Repository name: my-python
   • Description: 個人用Pythonツール集
   • Public/Private: 任意で選択
3. 重要: 「Add a README file」のチェックは外す
   • ローカルに既にREADME.mdがある場合、競合を防ぐため
4. 「Create repository」をクリック

ステップ2: ローカルリポジトリを初期化

コマンドプロンプトまたはターミナルで：

cd C:\my-local\my-python

# Gitリポジトリを初期化
git init

# すべてのファイルをステージング
git add .

# 初回コミット
git commit -m "Initial commit: Add claude_chat_exporter"

ステップ3: GitHubにプッシュ

GitHubのリポジトリページに表示されるコマンドを実行：

# ブランチ名をmainに変更
git branch -M main

# リモートリポジトリを追加
git remote add origin https://github.com/YOUR_USERNAME/my-python.git

# プッシュ
git push -u origin main

ステップ4: 認証（初回のみ）

プッシュ時に認証が求められます。

Personal Access Token（推奨）

1. GitHub Settings → Developer settings → Personal access tokens → Tokens (classic)
2. 「Generate new token」をクリック
3. Note: my-python-repo
4. Expiration: 任意（推奨: 90 days）
5. Select scopes: repo にチェック
6. 「Generate token」をクリック
7. トークンをコピー（画面を離れると二度と見れない）
8. プッシュ時のパスワード欄にトークンを貼り付け

メリット・デメリット

メリット：

• ビジュアル的で分かりやすい
• 初心者にも扱いやすい
• 設定項目が一目で確認できる

デメリット：

• ブラウザとコマンドラインを行き来する必要がある
• 認証情報を毎回入力する必要がある（トークンを保存しない場合）
• 複数リポジトリを連続で作成する場合は非効率

方法2: GitHub CLIでリポジトリ作成

GitHub CLI（ghコマンド）を使うと、すべてコマンドラインで完結します。

ステップ1: GitHub CLIをインストール

Windowsの場合：

winget install GitHub.cli

インストール後、コマンドプロンプトを再起動してください。

macOS/Linuxの場合は公式ドキュメントを参照してください。

GitHub CLIの詳細なインストール手順やトラブルシューティングは「GitHub CLI完全ガイド：コマンドラインでGitHub操作を効率化」をご覧ください。

ステップ2: GitHub CLIで認証

gh auth login

対話形式で以下を選択：

1. GitHub.com
2. HTTPS
3. Login with a web browser

ワンタイムコードが表示されるので、ブラウザでGitHubにログインして入力します。

重要: コードには有効期限があるため、表示されたらすぐに入力してください。

ステップ3: 一発でリポジトリ作成＆プッシュ

# プロジェクトフォルダに移動
cd C:\my-local\my-python

# Gitリポジトリ初期化（未初期化の場合）
git init
git add .
git commit -m "Initial commit: Add claude_chat_exporter"

# GitHub上にリポジトリを作成し、同時にプッシュ
gh repo create my-python \
  --public \
  --description "個人用Pythonツール集" \
  --source=. \
  --push

これだけで完了です！

オプション詳細

gh repo create <リポジトリ名> [オプション]

メリット・デメリット

メリット：

• すべてコマンドラインで完結
• 認証情報を保存するため、以降の操作がスムーズ
• 複数リポジトリを短時間で作成できる
• スクリプト化・自動化が可能

デメリット：

• 初回のCLIインストールと認証が必要
• コマンドに慣れるまで時間がかかる
• GUIほど直感的ではない

両方法の比較表

どちらを選ぶべきか？

GUIがおすすめな人

• GitやGitHubを始めたばかり
• たまにしかリポジトリを作成しない
• ビジュアル的な操作が好き
• コマンドラインに慣れていない

CLIがおすすめな人

• 頻繁にリポジトリを作成する
• 開発作業をコマンドラインで行っている
• 効率性を重視する
• GitHubの他の操作（Issue、PR作成など）もCLIで行いたい

実際の使い分け

私の場合、以下のように使い分けています：

• 個人の小規模プロジェクト: GitHub CLI（速い）
• チームでの新規プロジェクト: GUI（設定を確認しながら慎重に）
• 学習目的: GUI（プロセスを理解するため）

次のステップ

リポジトリ作成後の日常的な操作については、以下の記事も参考にしてください：

• GitHub CLI完全ガイド：コマンドラインでGitHub操作を効率化

GitHub CLI完全ガイド：コマンドラインでGitHub操作を効率化

GitHub CLI（ghコマンド）は、GitHubの操作をコマンドラインで完結できる公式ツールです。ブラウザを開かずに、リポジトリ作成からIssue管理、Pull Request作成まで、すべてターミナルで行えます。この記事では、実際の導...

caymezon.com

2026.01.31

• Claudeチャットを資産化！エクスポートデータを整形するPythonツール

Claudeチャットを資産化！エクスポートデータを整形するPythonツール

Claudeとの会話履歴は貴重な知的財産です。しかし、エクスポートしたJSONファイルは読みにくく、そのままでは活用しづらいのが現状です。この記事では、ClaudeのエクスポートデータをMarkdown形式に整形し、チャット毎に分割して保存...

caymezon.com

2026.01.31

まとめ

GitHubリポジトリの作成方法を2つ紹介しました：

1. GUIでの作成: 直感的で分かりやすい
2. GitHub CLIでの作成: 効率的で自動化可能

どちらもメリット・デメリットがあるため、自分の作業スタイルに合った方法を選択してください。個人的には、GitHub CLIに慣れると作業効率が大幅に向上するので、ぜひ試してみることをおすすめします。

GitHub CLIを使いこなせば、リポジトリ作成だけでなく、Issue管理やPull Request作成などもコマンドラインで効率的に行えるようになります。

The post GitHubリポジトリ作成の2つの方法：GUI vs CLI徹底比較 first appeared on CayTech Lab.

はじめに

Claude Desktop + GitHub MCP（Model Context Protocol） を使えば、あなたのGitHubリポジトリ全体をClaudeから直接操作できます。

この記事では、完全初心者でも30分でセットアップできるよう、すべての手順を画像付きで詳しく解説します。

2026年6月更新: MCPは2025年12月にAnthropicからLinux Foundation（Agentic AI Foundation）に寄贈され、オープンスタンダードとして管理されるようになりました。GitHub公式のMCPサーバーも大幅に進化しており、本記事では最新の設定方法を解説します。

🎯 このセットアップで得られるもの

セットアップ完了後、以下のことが可能になります：

✅ ファイルサイズ制限なし（プロジェクト機能の4KB制限を回避）
✅ リポジトリ全体にリアルタイムアクセス
✅ ファイルの読み書き・編集
✅ Issue/PR管理
✅ 常に最新版を参照
✅ プライベートリポジトリにもアクセス可能

具体的な活用例

あなた: 「caytech-blog-repoのscripts/publish.jsの行742-766を確認して」

Claude: 
[GitHub MCPでリポジトリから最新版を取得]
[35KB全文を確認]
「複数スラッグ対応が正しく実装されています...」

プロジェクトファイルの4KB制限から完全に解放されます！

詳しい問題背景はこちら：

【2026年1月】Claudeプロジェクトのファイル文字化け問題と解決法 - UTF-8 BOM付き保存の効果

はじめにClaudeのProプラン以上で利用できる「プロジェクト機能」で、JavaScriptファイルをアップロードすると日本語コメントが文字化けするという問題に遭遇しました。本記事では、この問題の原因究明から解決までの実体験を詳しく解説し...

caymezon.com

2026.01.24

📋 事前準備

必要なもの

所要時間

• 初めての方: 約30分
• 経験者: 約10分

🚀 ステップ1: Node.jsインストール

すでにNode.jsがインストールされている方はステップ2へ。

1-1. Node.jsのダウンロード

1. Node.js公式サイトにアクセス
2. 「LTS（推奨版）」 をクリックしてダウンロード

1-2. インストール

1. ダウンロードした.msiファイルを実行
2. すべてデフォルト設定で「Next」をクリック
3. 「Automatically install the necessary tools」に✅チェック
4. インストール完了まで待機

1-3. 確認

コマンドプロンプトを開いて確認：

node --version

npm --version
# 10.x.x のように表示されればOK

📥 ステップ2: Claude Desktopアプリのインストール

2-1. ダウンロード

1. Claude公式サイトにアクセス
2. Windows版をダウンロード

2-2. インストール

1. ダウンロードした.exeファイルを実行
2. インストーラーの指示に従う
3. Claude.aiアカウントでログイン

🔑 ステップ3: GitHub Personal Access Token (PAT) の作成

2026年現在、GitHubのトークンにはClassic PATとFine-grained PATの2種類があります。よりセキュアなFine-grained PATの使用を推奨します。

Fine-grained PAT（推奨）の作成方法

3-1. GitHubにアクセス

1. GitHub Settings - Fine-grained tokensにアクセス
2. 「Generate new token」 をクリック

3-2. トークンの設定

Permissions（権限）：

3-3. トークンをコピー

1. 「Generate token」 をクリック
2. 表示されたトークン（github_pat_xxxxxxxxxxxx）をコピー
3. 必ず安全な場所に保存（二度と表示されません）

Classic PAT（従来の方法）を使う場合

Classic PATを使う場合はGitHub Settings - Tokens (classic)から作成し、以下のスコープにチェックを入れてください：

✅ repo (Full control of private repositories)
✅ workflow (Update GitHub Action workflows)
✅ read:org
✅ user:email

注意: Classic PATはアカウント全体の権限になります。Fine-grained PATの方がリポジトリ単位で権限を絞れるため、セキュリティ上優れています。

⚠️ 重要： このトークンはパスワード同様に重要です。他人に見せたり、公開リポジトリにコミットしないでください。

⚙️ ステップ4: Claude Desktop設定ファイルの編集

2026年現在、設定方法が3つあります。用途に合わせて選んでください。

方法A: GitHub公式MCPサーバー（npx・推奨）

GitHub社が公式メンテナンスするMCPサーバー（github/github-mcp-server）を使う方法です。

4-1. 設定ファイルを開く

エクスプローラーから:

1. Windowsキー + R を押す
2. %APPDATA%\Claude と入力してEnter
3. claude_desktop_config.json を右クリック
4. 「プログラムから開く」→「メモ帳」または「VSCode」

コマンドプロンプトから:

notepad %APPDATA%\Claude\claude_desktop_config.json

4-2. 設定内容を記述

ファイルが空の場合は、以下をそのままコピー＆ペースト：

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "YOUR_TOKEN_HERE"
      }
    }
  }
}

重要： YOUR_TOKEN_HERE を、ステップ3でコピーした実際のトークンに置き換えてください。

方法B: GitHub公式MCPサーバー（Docker版）

Dockerがインストールされている場合、Dockerイメージを使った方法も利用できます。Node.jsなしで動作し、環境を汚染しないメリットがあります。

{
  "mcpServers": {
    "github": {
      "command": "docker",
      "args": [
        "run", "-i", "--rm",
        "-e", "GITHUB_PERSONAL_ACCESS_TOKEN",
        "ghcr.io/github/github-mcp-server"
      ],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "YOUR_TOKEN_HERE"
      }
    }
  }
}

前提: Docker Desktopのインストールと起動が必要です。

方法C: Desktop Extensions（ワンクリック・最も簡単）

2026年から利用可能になった**Desktop Extensions（.dxt形式）**を使えば、JSONの編集なしにワンクリックでインストールできます。

1. Claude Desktop上でExtensionsギャラリーを開く
2. 「GitHub」を検索
3. インストールボタンをクリック
4. GitHub認証を完了

注意: Desktop Extensionsは.dxt（旧）→.mcpb形式（新）に移行中です。どちらも対応しています。

4-3. 設定ファイルの保存（方法A・Bの場合）

Ctrl + S で保存して、ファイルを閉じます。

🔄 ステップ5: Claude Desktopを再起動

1. Claude Desktopを完全に終了
   • ウィンドウを閉じるだけでなく、タスクトレイのアイコンも右クリック→「終了」
2. Claude Desktopを起動

✅ ステップ6: 動作確認

6-1. 新しいチャットを開始

Claude Desktopで新しいチャットを作成します。

6-2. テスト

以下のように質問してみてください：

私のGitHubリポジトリ一覧を表示してください

または

caytech-blog-repoリポジトリの構造を教えてください

6-3. 成功の確認

Claudeが以下のように応答すれば成功です：

• 🔨 ハンマーアイコンが表示される
• GitHubリポジトリ情報が取得される
• ファイル一覧が表示される

🎉 セットアップ完了！

おめでとうございます！これでClaude DesktopからGitHubリポジトリ全体にアクセスできるようになりました。

💡 実際の使い方

📂 ファイルを読む

caytech-blog-repoの「scripts/publish.js」の内容を全て表示してください

→ 35KB全文が表示されます ✅

📝 複数ファイルを確認

以下のファイルを確認して、全体の構造を教えてください：
- scripts/publish.js
- scripts/check-posts.js  
- readme/USAGE.md

🔍 コードレビュー

publish.jsの行742-766の複数スラッグ対応が
正しく実装されているか確認してください

📊 リポジトリ全体の分析

caytech-blog-repoの全体構造を分析して、
改善点を提案してください

📥 Issueを作成

「publish.js複数スラッグ対応の実装完了」という
Issueを作成してください

🔄 最新の変更を確認

caytech-blog-repoの最近のコミット履歴を表示して、
どんな変更があったか教えてください

🛠️ トラブルシューティング

❌ 「Could not connect to MCP server」エラー

原因1: Node.jsが正しくインストールされていない

node --version
npm --version
# 両方が表示されればOK

表示されない場合は、ステップ1に戻ってNode.jsを再インストールしてください。

原因2: トークンが間違っている

• claude_desktop_config.jsonのトークンを再確認
• GitHubで新しいトークンを作成し直す

原因3: 設定ファイルのJSON形式が間違っている

• カンマ、括弧の位置を確認
• JSONLintで検証

❌ ハンマーアイコンが表示されない

1. Claude Desktopを完全に終了
2. タスクマネージャーで「Claude」プロセスが残っていないか確認
3. Claude Desktopを再起動

❌ ファイルが読めない

スコープ不足の可能性

GitHubでトークンの権限を再確認：

• repoスコープが✅チェックされているか
• トークンが有効期限切れになっていないか

💰 料金について

追加料金は一切かかりません。

📊 トークン消費について

重要な事実

claude.ai (Web) + Claude Desktop + Claude Code
        ↓
     同じアカウント
        ↓
   同じusage limit（5時間ごとに約44,000トークン）

GitHub MCPのトークン消費

GitHubリポジトリ全体のサイズは直接的には影響しません

重要なのは：

1. MCPツールの定義：約5,000トークン（常時）
2. 実際に取得したファイル：内容次第

実例

リポジトリサイズ: 数MB
↓
MCPツール定義: 約5,000トークン
publish.js読み込み: 約8,000トークン（35KB）
↓
合計: 約13,000トークン（Proプランの約30%）

🎯 次のステップ

セットアップが完了したら、Claude Desktopを最大限に活用しましょう：

【2026年版】Claude Desktop 効果的な活用ガイド - メリット・デメリット・ベストプラクティス完全版

はじめにClaude Desktopは、Claudeをネイティブアプリとして利用できる強力なツールです。本記事では、Web版との違い、効果的な使い方、トークン消費を最小化するテクニック、そして今後の展望まで、実践的な知見を完全網羅します。(...

caymezon.com

2026.01.24

📚 関連記事

【2026年1月】Claudeプロジェクトのファイル文字化け問題と解決法 - UTF-8 BOM付き保存の効果

はじめにClaudeのProプラン以上で利用できる「プロジェクト機能」で、JavaScriptファイルをアップロードすると日本語コメントが文字化けするという問題に遭遇しました。本記事では、この問題の原因究明から解決までの実体験を詳しく解説し...

caymezon.com

2026.01.24

• 【まとめ記事】Claude Desktop完全攻略ロードマップ｜MCP設定・GitHub連携・活用術を体系的に学ぶ

【2026年版】Claude Desktop完全攻略ロードマップ｜MCP設定・GitHub連携・活用術を体系的に学ぶ

はじめに「Claude Desktopを導入したいけど、何からどの順番で学べばいいかわからない」この記事は、Claude Desktopをゼロから使いこなすまでの全ステップを体系的に整理したロードマップです。セットアップ・GitHub MC...

caymezon.com

2026.03.21

📝 まとめ

セットアップの流れ

1. Node.jsインストール（10分）
   ↓
2. Claude Desktopインストール（5分）
   ↓
3. GitHub PATを作成（5分）
   ↓
4. 設定ファイル編集（5分）
   ↓
5. 再起動＆確認（5分）
   ↓
✅ 完了！

得られたメリット

• ✅ ファイルサイズ制限なし
• ✅ リポジトリ全体にアクセス
• ✅ 常に最新版を参照
• ✅ ファイルの読み書き
• ✅ Issue/PR管理
• ✅ プライベートリポジトリ対応

よくある質問

Q: プロジェクトファイルはまだ使えますか？

A: はい。小さなドキュメントファイル（README.mdなど）にはプロジェクトファイルが便利です。大きなコードファイルはGitHub MCPを使いましょう。

Q: 複数のリポジトリにアクセスできますか？

A: はい。同じGitHubアカウントで管理している全てのリポジトリ（プライベート含む）にアクセスできます。

Q: トークンを更新したい場合は？

A: GitHubで新しいトークンを作成し、claude_desktop_config.jsonのトークンを更新して、Claude Desktopを再起動してください。

Q: Fine-grained PATとClassic PATの違いは？

A: Fine-grained PATは特定のリポジトリと権限に絞った最小権限を付与できます。Classic PATはアカウント全体に権限が及ぶため、セキュリティ的にFine-grained PATの使用を推奨します。Fine-grained PATのトークンはgithub_pat_で始まります。

Q: Desktop Extensionsを使えばJSON設定は不要ですか？

A: はい。Desktop Extensions（.dxt/.mcpb形式）を使えば、JSONファイルの編集なしにワンクリックでインストールできます。ただし、Claude Desktopのバージョンが対応している必要があります。

Q: MCPはAnthropicが管理しているの？

A: 2025年12月に、AnthropicはMCPをLinux Foundation傘下のAgentic AI Foundation（AAIF）に寄贈しました。現在はオープンスタンダードとして、Anthropic・OpenAI・Block等が共同で標準化を進めています。

参考リンク

• Claude公式ドキュメント
• Model Context Protocol 公式サイト
• GitHub MCP Server 公式リポジトリ
• GitHub MCP Server セットアップガイド（GitHub公式）
• Agentic AI Foundation（MCP標準化団体）
• Node.js公式サイト
• Desktop Extensions（DXT）について

更新履歴

• 2026-06-20: Node.js要件をv18以上に更新、Fine-grained PAT推奨を追加、GitHub公式MCPサーバー（npx/Docker）・Desktop Extensions対応を追加、MCPエコシステムの最新動向を追記
• 2026-01-24: 初版公開

The post 【2026年最新版】Claude Desktop + GitHub MCP 完全セットアップガイド - 初心者でも30分で完了 first appeared on CayTech Lab.

はじめに

Gitは強力なバージョン管理ツールですが、使い方を間違えると大変なことになります。

この記事では、実務で使えるブランチ戦略から、よくある失敗とそのリカバリ方法まで、完全網羅します。

対象読者：

• Gitの基本は分かるが、実務での使い方に不安がある方
• ブランチ戦略を学びたい方
• 失敗したときの対処法を知りたい方
• チーム開発でGitを使う予定の方

この記事で分かること：

• main/develop/feature/* の使い分け
• 日常的な操作フロー
• 失敗したときのリカバリ方法
• 便利なコマンド集

ブランチ戦略の基本

なぜブランチを分けるのか

1つのブランチだけだと：

main
  ├─ 機能Aを開発中
  ├─ 機能Bを開発中
  └─ バグ修正中

→ すべてが混ざって混乱

ブランチを分けると：

main（本番）
  ├─ develop（開発）
  │   ├─ feature/機能A
  │   ├─ feature/機能B
  │   └─ fix/バグ修正
  └─ hotfix/緊急修正

それぞれ独立して作業できる！

Git Flow：最も一般的なブランチ戦略

main（本番環境）
  ├─ 常に安定版
  └─ リリース済みのコード

develop（開発環境）
  ├─ 開発中のコード
  └─ すべての作業の起点

feature/*（機能開発）
  ├─ feature/login
  ├─ feature/payment
  └─ 開発完了後、developにマージ

hotfix/*（緊急修正）
  ├─ hotfix/critical-bug
  └─ 本番の緊急バグ修正

各ブランチの役割

mainブランチ

役割：

• 本番環境のコード
• 常に動作する状態
• リリース済みの確定版

ルール：

• ❌ 直接編集しない
• ✅ developまたはhotfixからマージのみ
• ✅ タグでバージョン管理

例：

main
  ├─ v1.0.0
  ├─ v1.1.0
  └─ v2.0.0

developブランチ

役割：

• 開発環境のコード
• すべての機能開発の起点
• 次のリリース候補

ルール：

• ✅ feature/* からマージを受け入れる
• ✅ テスト済みの機能のみマージ
• ✅ mainより先に進んでいる

イメージ：

develop = main + 開発中の機能

feature/* ブランチ

役割：

• 個別の機能開発
• 独立して作業できる
• 開発完了後、developにマージ

命名規則：

feature/ログイン機能
feature/決済機能
feature/ユーザー管理

ライフサイクル：

1. developから作成
2. 機能開発
3. developにマージ
4. ブランチ削除

hotfix/* ブランチ

役割：

• 本番の緊急バグ修正
• mainから直接作成
• mainとdevelopの両方にマージ

使用タイミング：

本番でバグ発見
  ↓ 緊急修正が必要
hotfix/critical-bug を作成
  ↓ 修正
mainにマージ（本番反映）
  ↓ 同時に
developにもマージ（開発環境にも反映）

基本操作

ブランチの作成と切り替え

新しいブランチを作成して切り替え

git checkout develop
git checkout -b feature/new-function

# または
git switch -c feature/new-function

説明：

• -b オプションで作成と切り替えを同時に実行
• switch は新しいGitコマンド（v2.23以降）

既存のブランチに切り替え

# developに切り替え
git checkout develop

# mainに切り替え
git checkout main

ブランチ一覧を確認

# ローカルブランチ一覧
git branch

# 出力例：
  main
* develop  ← *が現在のブランチ
  feature/login

# リモートブランチも含めて表示
git branch -a

# 出力例：
* develop
  main
  remotes/origin/develop
  remotes/origin/main
  remotes/origin/feature/login

コミット

ステージングとコミット

# ファイルをステージング
git add file.txt

# すべてのファイルをステージング
git add .

# コミット
git commit -m "feat: ログイン機能を追加"

コミットメッセージの規約

Conventional Commits:

: 

type:
- feat: 新機能
- fix: バグ修正
- docs: ドキュメント
- style: コードスタイル
- refactor: リファクタリング
- test: テスト
- chore: その他

例：

git commit -m "feat: ユーザー登録機能を追加"
git commit -m "fix: ログインエラーを修正"
git commit -m "docs: READMEを更新"

プッシュ

リモートにプッシュ

# 現在のブランチをリモートにプッシュ
git push origin feature/login

# 初回プッシュ時（追跡ブランチを設定）
git push -u origin feature/login

# 次回以降
git push

-u オプション：

• upstream（追跡ブランチ）を設定
• 次回以降は git push だけでOK

マージ

developにマージ

# developに切り替え
git checkout develop

# featureブランチをマージ
git merge feature/login

# 出力例：
Updating abc1234..def5678
Fast-forward
 login.js | 50 +++++++++++++++++++++++++++++++++++
 1 file changed, 50 insertions(+)

# リモートにプッシュ
git push origin develop

mainにマージ

# mainに切り替え
git checkout main

# developをマージ
git merge develop

# プッシュ
git push origin main

日常的な運用フロー

パターン1：新機能を開発

Step 1：featureブランチを作成

# developから作成
git checkout develop
git pull origin develop  # 最新の状態に更新

# featureブランチ作成
git checkout -b feature/user-profile

Step 2：開発作業

# ファイルを編集
code user-profile.js

# コミット（何度でも）
git add user-profile.js
git commit -m "feat: ユーザープロフィール表示機能"

git add user-profile.css
git commit -m "style: プロフィール画面のスタイル調整"

git add tests/user-profile.test.js
git commit -m "test: ユーザープロフィールのテスト追加"

Step 3：リモートにプッシュ

# 初回
git push -u origin feature/user-profile

# 2回目以降
git push

Step 4：developにマージ

# developに切り替え
git checkout develop

# 最新の状態に更新
git pull origin develop

# featureブランチをマージ
git merge feature/user-profile

# コンフリクトがなければ
git push origin develop

# featureブランチを削除（オプション）
git branch -d feature/user-profile
git push origin --delete feature/user-profile

パターン2：複数の機能を並行開発

# 機能A開発
git checkout develop
git checkout -b feature/function-a
# 開発...
git push origin feature/function-a

# 機能Bも開発したい
git checkout develop  # developに戻る
git checkout -b feature/function-b
# 開発...
git push origin feature/function-b

# 機能Aに戻る
git checkout feature/function-a
# 開発続き...

ポイント：

• 各機能が独立して開発できる
• いつでもブランチを切り替えられる

パターン3：mainへのリリース

# developの作業が完了
git checkout main
git pull origin main

# developをマージ
git merge develop

# タグを付ける
git tag -a v1.0.0 -m "バージョン1.0.0リリース"

# プッシュ
git push origin main
git push origin v1.0.0

よくある失敗とリカバリ

失敗1：mainで誤って作業してしまった

状況

# mainブランチにいることに気づかず作業
git add file.txt
git commit -m "機能追加"

# あっ、mainだった！
git branch
# * main  ← まずい！

リカバリ方法A：まだプッシュしていない場合

# コミットを取り消し（変更は残る）
git reset --soft HEAD~1

# developに切り替え
git checkout develop

# 再度コミット
git add file.txt
git commit -m "機能追加"
git push origin develop

reset --soft：

• コミットだけ取り消し
• ファイルの変更は残る
• ステージング状態も残る

リカバリ方法B：すでにプッシュしてしまった場合

# developに該当のコミットを持っていく
git checkout develop
git cherry-pick コミットハッシュ
git push origin develop

# mainから削除
git checkout main
git revert コミットハッシュ
git push origin main

cherry-pick：

• 特定のコミットだけを別ブランチに適用

revert：

• コミットを打ち消す新しいコミットを作成
• 履歴は残る（安全）

失敗2：developとmainがずれてしまった

状況

main: 最新の状態
develop: 古い状態

→ mainで作業してしまった
→ developに反映されていない

リカバリ方法：mainの変更をdevelopにマージ

# developに切り替え
git checkout develop

# mainの変更を取り込む
git merge main

# 出力例：
Updating abc1234..def5678
Fast-forward
 file.txt | 10 ++++++++++
 1 file changed, 10 insertions(+)

# プッシュ
git push origin develop

これで同期完了！

失敗3：コミットメッセージを間違えた

まだプッシュしていない場合

# 最後のコミットメッセージを修正
git commit --amend -m "正しいメッセージ"

すでにプッシュしてしまった場合

# 修正
git commit --amend -m "正しいメッセージ"

# 強制プッシュ（注意！）
git push -f origin feature/my-branch

⚠️ 注意：

• git push -f は履歴を書き換える
• チーム開発では使わない（他の人の作業が壊れる）
• 自分専用のブランチでのみ使用

失敗4：間違ったファイルをコミットしてしまった

まだプッシュしていない場合

# 最後のコミットを取り消し（変更は残る）
git reset --soft HEAD~1

# 正しいファイルだけをステージング
git add correct-file.txt
git commit -m "メッセージ"

# 間違ったファイルは破棄
git checkout -- wrong-file.txt

すでにプッシュしてしまった場合

# ファイルを削除するコミット
git rm wrong-file.txt
git commit -m "不要なファイルを削除"
git push origin feature/my-branch

失敗5：コンフリクトが発生した

状況

git merge feature/function-a

# 出力：
Auto-merging file.txt
CONFLICT (content): Merge conflict in file.txt
Automatic merge failed; fix conflicts and then commit the result.

解決手順

1. コンフリクトしているファイルを確認：

git status

# 出力：
Unmerged paths:
  both modified:   file.txt

2. ファイルを開いて編集：

<<<<<<< HEAD
現在のブランチの内容
=======
マージしようとしているブランチの内容
>>>>>>> feature/function-a

どちらを採用するか決める：

# 最終的な内容（コンフリクトマーカーを削除）
採用する内容

3. コミット：

git add file.txt
git commit -m "merge: コンフリクトを解決"

便利なコマンド

空コミット

ファイルを変更せずにコミット：

git commit --allow-empty -m "chore: CI/CDをトリガー"

使用例：

• CI/CDを再実行したい
• Git履歴に記録を残したい
• ファイル変更なしでプッシュしたい

特定のコミットを別ブランチに適用

# コミットハッシュを確認
git log --oneline

# 出力例：
abc1234 feat: 機能追加
def5678 fix: バグ修正

# 別ブランチに切り替え
git checkout target-branch

# 特定のコミットを適用
git cherry-pick abc1234

コミット履歴を確認

# 簡易表示
git log --oneline

# グラフ表示
git log --graph --oneline --all

# 出力例：
* abc1234 (HEAD -> develop) feat: 機能追加
* def5678 (origin/develop) fix: バグ修正
* ghi9012 (main) chore: 初期設定

変更内容を確認

# まだステージングしていない変更
git diff

# ステージング済みの変更
git diff --staged

# ブランチ間の差分
git diff develop..main

変更を一時保存

# 変更を一時保存
git stash

# 別のブランチで作業...

# 変更を復元
git stash pop

# stash一覧
git stash list

使用例：

• 作業中に別のブランチに切り替える必要がある
• コミットしたくないが、変更を保存したい

ブランチを削除

# ローカルブランチを削除
git branch -d feature/old-feature

# まだマージしていないブランチを強制削除
git branch -D feature/old-feature

# リモートブランチを削除
git push origin --delete feature/old-feature

GitHub連携

Re-run jobs（GitHub Actions）

GitHub Actions が失敗したときの再実行方法：

方法1：GitHub UIから再実行（推奨）

GitHub → Actions
→ 失敗したWorkflow
→ Re-run jobs
→ Re-run all jobs

メリット：

• コード変更不要
• 設定変更後に使う

方法2：空コミット

git commit --allow-empty -m "chore: GitHub Actions再実行"
git push origin main

メリット：

• Git履歴に記録される
• コマンドラインで完結

Pull Request（PR）

チーム開発での標準フロー：

Step 1：featureブランチで開発

git checkout -b feature/new-function
# 開発...
git push origin feature/new-function

Step 2：GitHub でPRを作成

GitHub → Pull requests
→ New pull request
→ base: develop ← compare: feature/new-function
→ Create pull request

Step 3：レビュー

チームメンバーがレビュー
→ コメント
→ 承認

Step 4：マージ

Merge pull request
→ Confirm merge
→ Delete branch（オプション）

ベストプラクティス

1. 作業前に必ずブランチ確認

# 習慣化する
git branch

または、プロンプトに表示：

# ~/.bashrc に追加
parse_git_branch() {
  git branch 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/(\1)/'
}
export PS1="\[\033[32m\]\w\[\033[33m\]\$(parse_git_branch)\[\033[00m\] $ "

表示例：

~/project (develop) $

2. 小まめにコミット

# 悪い例
git add .
git commit -m "いろいろ修正"

# 良い例
git add login.js
git commit -m "feat: ログイン機能追加"

git add login.css
git commit -m "style: ログイン画面のスタイル調整"

git add tests/login.test.js
git commit -m "test: ログイン機能のテスト追加"

メリット：

• 履歴が分かりやすい
• 問題があったときに特定しやすい
• レビューしやすい

3. 定期的にdevelopを更新

# 作業開始時
git checkout develop
git pull origin develop

# mainの変更も取り込む
git merge origin/main

# featureブランチでも定期的に
git checkout feature/my-feature
git merge develop  # developの最新を取り込む

メリット：

• コンフリクトを早期に発見
• 最新の状態で開発できる

4. 意味のあるコミットメッセージ

# 悪い例
git commit -m "修正"
git commit -m "update"
git commit -m "fix"

# 良い例
git commit -m "feat: ユーザー登録機能を追加"
git commit -m "fix: ログインエラーを修正（#123）"
git commit -m "docs: READMEに環境構築手順を追加"

5. mainとdevelopを保護

GitHub設定：

Settings → Branches
→ Add branch protection rule

main:
  ✅ Require pull request reviews
  ✅ Require status checks to pass
  ❌ Allow force pushes

develop:
  ✅ Require pull request reviews
  ❌ Allow force pushes

これで：

• 誤って直接プッシュできない
• レビューが必須
• 安全性向上

チートシート

ブランチ操作

# ブランチ一覧
git branch

# ブランチ作成
git checkout -b feature/new

# ブランチ切り替え
git checkout develop

# ブランチ削除
git branch -d feature/old

コミット操作

# コミット
git add .
git commit -m "メッセージ"

# コミット修正
git commit --amend -m "修正後のメッセージ"

# コミット取り消し（変更は残る）
git reset --soft HEAD~1

# 空コミット
git commit --allow-empty -m "メッセージ"

リモート操作

# プッシュ
git push origin branch-name

# プル
git pull origin branch-name

# リモートブランチ削除
git push origin --delete branch-name

マージ操作

# マージ
git merge branch-name

# コンフリクト確認
git status

# マージ中止
git merge --abort

確認系

# 状態確認
git status

# 履歴確認
git log --oneline

# 差分確認
git diff

# ブランチ確認
git branch -a

リカバリ系

# 変更を破棄
git checkout -- file.txt

# コミット取り消し
git reset --soft HEAD~1

# コミット打ち消し
git revert コミットハッシュ

# 特定のコミットを適用
git cherry-pick コミットハッシュ

まとめ

ブランチ戦略

main（本番）
  ↓ マージ
develop（開発）
  ↓ マージ
feature/*（機能開発）

ルール：

• mainで直接作業しない
• developですべての開発
• featureで個別機能

基本フロー

1. featureブランチ作成
2. 開発・コミット
3. developにマージ
4. mainにマージ（リリース時）

失敗時の対処

mainで誤って作業
  → developにマージ

コミットミス
  → reset --soft

コンフリクト
  → 手動で解決

覚えておくべきコマンド

git branch  # ブランチ確認
git checkout -b  # ブランチ作成
git merge  # マージ
git reset --soft  # コミット取り消し
git stash  # 一時保存

おわりに

Gitは最初は難しく感じるかもしれません。

でも、基本的な流れを理解して、失敗を恐れずに使っていけば、必ず使いこなせるようになります。

この記事が、あなたのGit習得の助けになれば幸いです。

Happy Coding! 🚀

参考リンク

• Git公式ドキュメント
• Git Flow
• Conventional Commits
• GitHub Docs

最終更新： 2026-01-12

The post 【保存版】Git実務ガイド｜ブランチ戦略から失敗時のリカバリまで完全網羅 first appeared on CayTech Lab.