ClaudeCode 最強プロビジョニング - 定額×非同期×並列×selfHosting で生産性爆上がり
🚀 はじめに
「ClaudeCodeで本当に並列実行できるの？」
この疑問に、私は明確な答えを出しました。
41のWebサイトに、10並列でブログ記事を自動投稿。
2025年10月25日、私はこのシステムを実際に動かし、人間とAIが完全に別々の作業をすることで、生産性が10倍になることを証明しました。
この記事では、その全貌を公開します。
※ソースコード全文はこの記事の末尾に記載してます
本記事の元ネタはこちら
https://shinichi.noguchi.jp.net/blog/2025-10-25-human-ai-async-work.html
📊 実績：41サイト×10並列＝驚異の自動化
実際に達成したこと
対象: 41のWebサイト（自社サイト＋クライアントサイト）
タスク: 各サイトへの記事投稿＋アイキャッチ画像生成
並列実行: 10タスク同時実行（max-parallel: 10）
総処理時間: 約40分（逐次実行なら5時間以上）
成功率: 100%（全タスク完了）
なぜこれが革命的なのか？
従来のClaudeCode利用では：
1タスク終了を待ってから次のタスク開始
手動でタスク管理
並列実行は技術的に困難
tmuxなどで擬似的にはできるものの、人間がパソコンで操作しないといけない
Self-Hosted Multiplexerでは：
人間：戦略的な仕事に専念
AI：41サイトへの投稿を完全自動化
結果：人間は別の仕事を同時進行可能これが「非同期×並列」の真価です。
🎯 このシステムの3つの革命
1. 定額で無制限（ClaudeCodeMax契約）
月額100ドルで以下が使い放題：
Claude Sonnet 4（最高性能モデル）
無制限のClaude Code実行
GitHub Actionsとの完全統合
※5時間毎、一週間毎にリミットはあります
2. 非同期実行（人間とAIが別々の仕事）
従来：AI実行中は人間が待機 → 時間の浪費
新方式：AI実行中も人間は別作業 → 生産性2倍実例：
午前：41サイトへの投稿指示を出す（5分）
同時進行：別のプロジェクトの設計作業（3時間）
午後：完了報告を確認、必要に応じて微調整（10分）
合計：3時間15分で、6時間分の仕事が完了
3. 並列実行（10タスク同時処理）
Self-Hosted環境での完全独立タスク方式：
各タスクが独立したworktreeで動作
キャッシュ競合ゼロ
ファイル競合ゼロ
並列実行安全性100%
逐次実行（従来）：Task1→Task2→Task3→...→Task41（5時間）
並列実行（本方式）：Task1-8 → Task9-16 → ...（40分）
効率：7.5倍🏗️ システムアーキテクチャ解説
Self-Hostedの決定的な優位性：物理ホストの共有
なぜGitHub Actions標準ランナーでは実現できないのか？
GitHub Actionsの標準ランナー（GitHub-hosted runners）では、各ジョブが完全に独立した仮想マシン上で実行されます。これは一見セキュアで安全に見えますが、並列タスク実行において致命的な制約となります。
GitHub-hosted runners（標準ランナー）の制約
Task 1 → 独立VM #1
├─ 完全に独立したファイルシステム
├─ リポジトリを新規にクローン
└─ 他のタスクとファイル共有不可
Task 2 → 独立VM #2
├─ 完全に独立したファイルシステム
├─ リポジトリを新規にクローン
└─ 他のタスクとファイル共有不可
Task 3 → 独立VM #3
├─ 完全に独立したファイルシステム
├─ リポジトリを新規にクローン
└─ 他のタスクとファイル共有不可
結果：
❌ 各タスクでフルクローン（遅い、ネットワーク負荷大）
❌ ベアリポジトリを共有できない
❌ worktreeが使えない
❌ 共有キャッシュが使えない
❌ タスク間でのファイル連携不可Self-Hosted Runnerの圧倒的優位性
┌──────────────────────────────────────────────────────┐
│ 物理ホスト（Ubuntu 22.04） │
│ │
│ /home/github-runner/common/ │
│ └── repo-slug/ │
│ ├── repos/ │
│ │ └── repo.git/ ← ★ベアリポジトリ（全タスク共有）│
│ │ ├── objects/ （Gitオブジェクトデータ） │
│ │ ├── refs/ （ブランチ参照） │
│ │ └── config （Git設定） │
│ │ │
│ ├── worktrees/ ← ★全タスクがこの下に展開 │
│ │ ├── task_1/ ← Task 1のワーキングツリー │
│ │ ├── task_2/ ← Task 2のワーキングツリー │
│ │ ├── task_3/ ← Task 3のワーキングツリー │
│ │ ├── ... │
│ │ └── task_8/ ← Task 8のワーキングツリー │
│ │ │
│ ├── shared/ ← ★タスク間で共有するファイル │
│ │ ├── cache/ （ビルドキャッシュ） │
│ │ ├── temp/ （一時ファイル） │
│ │ └── logs/ （実行ログ） │
│ │ │
│ └── locks/ ← ★排他制御用ロックファイル │
│ ├── task_1.lock │
│ ├── task_2.lock │
│ └── ... │
│ │
│ 全タスクが同じファイルシステムにアクセス可能！ │
└──────────────────────────────────────────────────────┘この物理ホストの共有が、コンフリクト回避の鍵となります。
全体構成図（Self-Hosted特化版）
┌─────────────────┐
│ GitHub Issue │ @claude-selfmux でメンション
│ （指示入力） │
└────────┬────────┘
│
▼
┌─────────────────────────────────────────────────────┐
│ Self-Hosted Runner（物理ホスト共有） │
│ │
│ ┌───────────────────────────────────────────────┐ │
│ │ Bare Repository (永続化・全タスク共有) │ │
│ │ /home/github-runner/common/repo/repos/repo.git│ │
│ │ - リポジトリのコアデータ │ │
│ │ - objects/ refs/ が全タスクで共有 │ │
│ │ - クローンは1回のみ、以降はfetchだけ │ │
│ └───────────────────────────────────────────────┘ │
│ │ │
│ ┌──────────┴──────────┬──────────┐ │
│ ▼ ▼ ▼ │
│ ┌──────────────┐ ┌──────────────┐ ... │
│ │ Task 1 │ │ Task 2 │ Task 3-8 │
│ │ Worktree │ │ Worktree │ │
│ │ (独立ディレ │ │ (独立ディレ │ │
│ │ クトリ) │ │ クトリ) │ │
│ │ │ │ │ │
│ │ ベアリポジトリ│ │ ベアリポジトリ│ │
│ │ を参照 │ │ を参照 │ │
│ │ (ハードリンク)│ │ (ハードリンク)│ │
│ └──────┬───────┘ └──────┬───────┘ │
│ │ │ │
│ └─────────┬───────────┘ │
│ ▼ │
│ ┌─────────────────┐ │
│ │ 共有スペース │ │
│ │ - cache/ │ │
│ │ - temp/ │ │
│ │ - logs/ │ │
│ └─────────────────┘ │
│ │
│ ★すべてのタスクが同じ物理ディスク上で実行 │
│ ★ファイルシステムレベルでの共有が可能 │
└─────────────────────────────────────────────────────┘
│
▼
┌─────────────────┐
│ GitHub Repository│ 各タスクのブランチにpush
│ （自動PR作成） │
└─────────────────┘物理ホスト共有がもたらす3つの革命的メリット
メリット1: ベアリポジトリの完全共有によるコンフリクト回避
従来の問題（GitHub-hosted runners）:
# Task 1（VM #1）
git clone https://github.com/user/repo.git # フルクローン 500MB
cd repo
# 作業...
# Task 2（VM #2）
git clone https://github.com/user/repo.git # 同じリポジトリを再度フルクローン 500MB
cd repo
# 作業...
# Task 3（VM #3）
git clone https://github.com/user/repo.git # また同じリポジトリをフルクローン 500MB
cd repo
# 作業...
問題点：
❌ 8タスク並列 = 4GB のクローン（ネットワーク・ディスク負荷大）
❌ 各タスクでフルクローン = 起動に30-60秒かかる
❌ Gitオブジェクトが独立 = タスク間で共有不可
❌ リモートfetchのたびに全VM同時実行 = GitHub APIレート制限Self-Hosted方式の解決策:
# 物理ホスト上（1回のみ実行）
cd /home/github-runner/common/repo-slug/repos/
git clone --bare https://github.com/user/repo.git repo.git # 500MB
# ↑ここまで1回だけ。以降はfetchのみ
git --git-dir=repo.git fetch origin # 差分のみ取得（数KB〜数MB）
# Task 1
git --git-dir=../repos/repo.git worktree add task_1/ main # 0.1秒で完了
# ★ objects/ はハードリンク = ディスク使用量ゼロ
# Task 2（並列実行）
git --git-dir=../repos/repo.git worktree add task_2/ main # 0.1秒で完了
# ★ 同じobjects/ を参照 = 追加ディスク使用量ゼロ
# Task 3-8（並列実行）
git --git-dir=../repos/repo.git worktree add task_3/ main
git --git-dir=../repos/repo.git worktree add task_4/ main
...
# ★ すべてのタスクが同じGitオブジェクトを共有
メリット：
✅ ディスク使用量: 500MB（1リポジトリ分のみ）
✅ worktree作成時間: 0.1秒/タスク
✅ ネットワーク負荷: 初回のみ、以降は差分のみ
✅ Git操作の競合: 物理的に不可能（異なるworktreeで完全分離）なぜコンフリクトが発生しないのか？
物理ホスト上のディレクトリ構造：
/home/github-runner/common/repo-slug/
├── repos/
│ └── repo.git/ ← ★ベアリポジトリ（読み取り専用的に使用）
│ ├── objects/ ← Gitオブジェクトデータベース
│ │ ├── 00/
│ │ ├── 01/
│ │ └── ...
│ ├── refs/
│ │ ├── heads/
│ │ │ ├── main ← mainブランチの最新コミット
│ │ │ ├── task_1 ← Task 1専用ブランチ
│ │ │ ├── task_2 ← Task 2専用ブランチ
│ │ │ └── ...
│ │ └── remotes/
│ │ └── origin/
│ │ └── main ← リモートのmain追跡
│ └── config ← Git設定（リモートURL等）
│
└── worktrees/
├── task_1/ ← Task 1のワーキングディレクトリ
│ ├── .git → ../repos/repo.git/worktrees/task_1
│ ├── src/ ← 独立したファイル
│ ├── package.json
│ └── ...
│
├── task_2/ ← Task 2のワーキングディレクトリ
│ ├── .git → ../repos/repo.git/worktrees/task_2
│ ├── src/ ← task_1とは完全に独立
│ ├── package.json
│ └── ...
│
└── task_3-8/ ← 同様に独立
重要ポイント：
1. objects/ は全タスクで共有（読み取りのみ）
2. 各worktreeは完全に独立したディレクトリ
3. ファイルシステムレベルで分離されているため、
Task 1が task_1/src/file.js を編集しても
Task 2の task_2/src/file.js には影響ゼロ
4. git configへの書き込みは-cオプションで回避
→ repos/repo.git/config は書き換えられない実際の動作フロー:
# Task 1の実行フロー（task_1/ worktreeで作業）
cd /home/github-runner/common/repo-slug/worktrees/task_1
git checkout -b feature-task-1 main
# ↑ refs/heads/feature-task-1 を作成（他タスクに影響なし）
echo "Task 1 changes" >> src/file1.js
git add src/file1.js
git commit -m "Task 1 implementation"
# ↑ objects/ にコミットオブジェクトを追加
# 他のタスクは読み取り可能（コンフリクトなし）
git push origin feature-task-1
# ↑ リモートにpush（他タスクと独立）
# Task 2の実行フロー（同時実行中）
cd /home/github-runner/common/repo-slug/worktrees/task_2
git checkout -b feature-task-2 main
# ↑ 別のブランチ名 = コンフリクトなし
echo "Task 2 changes" >> src/file2.js
git add src/file2.js
git commit -m "Task 2 implementation"
# ↑ objects/ に追加されるが、Task 1とは異なるコミット
git push origin feature-task-2
# ↑ 別のブランチ = コンフリクトなし
結果：
✅ Task 1とTask 2は完全に独立して動作
✅ objects/ の共有による効率性
✅ refs/ の分離による安全性
✅ worktreeの分離によるファイル競合回避メリット2: 共有スペースによるタスク間連携
Self-Hosted環境だからこそ実現できる連携:
# 共有ディレクトリ構造
/home/github-runner/common/repo-slug/
├── shared/
│ ├── cache/ ← ビルドキャッシュ（全タスク共有）
│ │ ├── node_modules/ ← npm install結果を再利用
│ │ ├── pip_cache/ ← pip install結果を再利用
│ │ └── .build/ ← ビルド成果物を再利用
│ │
│ ├── temp/ ← 一時ファイル（タスク間でデータ受け渡し）
│ │ ├── task_1_output.json
│ │ ├── task_2_output.json
│ │ └── ...
│ │
│ ├── logs/ ← 実行ログ（デバッグ用）
│ │ ├── task_1.log
│ │ ├── task_2.log
│ │ └── ...
│ │
│ └── artifacts/ ← タスク成果物
│ ├── images/ ← 生成画像
│ ├── reports/ ← レポート
│ └── ...
│
└── locks/ ← 排他制御用ロックファイル
├── npm_install.lock ← npm install の排他制御
├── db_migration.lock ← データベースマイグレーションの排他制御
└── ...実例：ビルドキャッシュの共有
# Task 1（最初に実行されたタスク）
cd /home/github-runner/common/repo-slug/worktrees/task_1
# キャッシュチェック
if [ ! -d "../shared/cache/node_modules" ]; then
# キャッシュがない場合のみnpm install
npm install # 60秒
# キャッシュに保存
cp -r node_modules ../shared/cache/
else
# キャッシュがある場合はコピー
cp -r ../shared/cache/node_modules . # 5秒
fi
# Task 2-8（並列実行中）
cd /home/github-runner/common/repo-slug/worktrees/task_2
# キャッシュを利用
if [ -d "../shared/cache/node_modules" ]; then
cp -r ../shared/cache/node_modules . # 5秒
fi
# ★結果：
# Task 1: npm install 60秒
# Task 2-8: キャッシュコピー 5秒
#
# 従来（各VMで独立）:
# 全タスクで npm install = 60秒 × 8 = 480秒
#
# Self-Hosted（キャッシュ共有）:
# Task 1: 60秒、Task 2-8: 5秒 × 7 = 95秒
#
# 効率: 5倍向上！実例：タスク間のデータ受け渡し
# Task 1: データ収集タスク
cd /home/github-runner/common/repo-slug/worktrees/task_1
# データを収集してJSON出力
./collect_data.sh > ../shared/temp/data.json
# Task 2-5: データ処理タスク（並列実行）
cd /home/github-runner/common/repo-slug/worktrees/task_2
# Task 1が生成したデータを読み込み
jq '.section_A' ../shared/temp/data.json > section_A.json
./process_section.sh section_A.json
# Task 3-5も同様に異なるセクションを処理
# ★同じ物理ホスト上だから、ファイル経由のデータ共有が可能！メリット3: 排他制御による安全な同時実行
flock を使った排他制御:
# 排他制御が必要な操作（例：データベースマイグレーション）
# Task 1
cd /home/github-runner/common/repo-slug/worktrees/task_1
# ロックファイルを使った排他制御
(
flock -x 200 # 排他ロック取得
echo "Task 1: Acquiring lock..."
# データベースマイグレーション実行
npm run db:migrate
echo "Task 1: Migration completed, releasing lock"
) 200>/home/github-runner/common/repo-slug/locks/db_migration.lock
# Task 2（同時実行中）
cd /home/github-runner/common/repo-slug/worktrees/task_2
(
flock -x 200 # ロック取得を試みる（Task 1が解放するまで待機）
echo "Task 2: Acquiring lock..."
# Task 1のマイグレーション完了後に実行
npm run db:migrate
echo "Task 2: Migration completed, releasing lock"
) 200>/home/github-runner/common/repo-slug/locks/db_migration.lock
# ★同じ物理ホスト上だから、flockによる排他制御が機能する！
# GitHub-hosted runnersでは、各VMが独立しているため、
# ロックファイルを共有できず、この手法は使えない。実例：共有リソースへの安全なアクセス
# 共有ログファイルへの書き込み
append_log() {
local task_id=$1
local message=$2
local log_file="/home/github-runner/common/repo-slug/shared/logs/execution.log"
# ロックを取得してログ追記
(
flock -x 200
echo "[$(date '+%Y-%m-%d %H:%M:%S')] [$task_id] $message" >> "$log_file"
) 200>/home/github-runner/common/repo-slug/locks/log.lock
}
# 各タスクから安全にログ追記
# Task 1
append_log "task_1" "Started processing site1.example.com"
append_log "task_1" "Completed processing site1.example.com"
# Task 2（同時実行）
append_log "task_2" "Started processing site2.example.com"
append_log "task_2" "Completed processing site2.example.com"
# 結果のログファイル（競合なし、順序保証）
[2025-10-26 12:00:01] [task_1] Started processing site1.example.com
[2025-10-26 12:00:02] [task_2] Started processing site2.example.com
[2025-10-26 12:00:45] [task_1] Completed processing site1.example.com
[2025-10-26 12:00:47] [task_2] Completed processing site2.example.com主要技術コンポーネント
1. Git Bare Repository + Worktree方式（物理ホスト共有の核心）
物理ホスト共有だからこそ実現できる高速化：
# ========================================
# GitHub-hosted runners（各VMが独立）
# ========================================
# Task 1（VM #1で実行）
time git clone https://github.com/user/repo.git # 45秒
cd repo
# 作業開始まで: 45秒
# Task 2（VM #2で実行、同時）
time git clone https://github.com/user/repo.git # 45秒
cd repo
# 作業開始まで: 45秒
# 8タスク並列実行
# 総クローン時間: 45秒（並列だが各VMで実行）
# 総ディスク使用量: 500MB × 8 = 4GB
# ネットワーク転送量: 500MB × 8 = 4GB
# ========================================
# Self-Hosted runner（物理ホスト共有）
# ========================================
# 初回のみ（ベアリポジトリ作成）
time git clone --bare https://github.com/user/repo.git repos/repo.git # 45秒（1回のみ）
# 2回目以降の実行
time git --git-dir=repos/repo.git fetch origin # 0.5秒（差分のみ）
# Task 1のworktree作成（並列実行可能）
time git --git-dir=repos/repo.git worktree add worktrees/task_1/ main # 0.1秒
cd worktrees/task_1
# 作業開始まで: 0.1秒
# Task 2のworktree作成（同時実行）
time git --git-dir=repos/repo.git worktree add worktrees/task_2/ main # 0.1秒
cd worktrees/task_2
# 作業開始まで: 0.1秒
# Task 3-8のworktree作成（すべて同時実行可能）
# 各タスク: 0.1秒
# 8タスク並列実行の場合
# 初回: 45秒（ベアリポジトリ作成）+ 0.1秒 × 8 = 45.8秒
# 2回目以降: 0.5秒（fetch）+ 0.1秒 × 8 = 1.3秒
#
# 総ディスク使用量: 500MB（1リポジトリ分のみ）
# ★worktreeはハードリンクのため追加容量ほぼゼロ
# ネットワーク転送量（2回目以降）: 数KB〜数MB（差分のみ）
# ========================================
# 比較結果
# ========================================
#
# 起動時間（2回目以降）:
# GitHub-hosted: 45秒 × 8 = 360秒（合計）
# Self-Hosted: 1.3秒
# 効率: 277倍！
#
# ディスク使用量:
# GitHub-hosted: 4GB
# Self-Hosted: 500MB
# 効率: 8倍！
#
# ネットワーク使用量（2回目以降）:
# GitHub-hosted: 4GB
# Self-Hosted: 数MB
# 効率: 100倍以上！なぜこれほど高速なのか？ - ファイルシステムの魔法
# worktreeのファイル構造（物理ホスト上）
repos/repo.git/objects/
├── 00/
│ ├── 0a1b2c3d...（Gitオブジェクト）
│ └── ...
├── 01/
└── ...
worktrees/task_1/
└── .git/
└── objects/ → ../../repos/repo.git/objects/ # シンボリックリンク
# ★実体は共有、ディスク使用量ゼロ
worktrees/task_2/
└── .git/
└── objects/ → ../../repos/repo.git/objects/ # 同じobjects/を参照
# ★実体は共有、ディスク使用量ゼロ
# Linuxのハードリンク/シンボリックリンクにより、
# 複数のworktreeが同じファイルを「異なるパス」から参照可能
#
# メリット:
# ✅ ディスク使用量: 1リポジトリ分のみ
# ✅ ファイルアクセス: 直接アクセス（コピー不要）
# ✅ 更新の反映: リアルタイム（すべてのworktreeで即座に利用可能）コンフリクトが発生しない理由 - ディレクトリ分離
# 各タスクの実際のワーキングディレクトリ
worktrees/task_1/
├── src/
│ ├── file1.js ← Task 1が編集
│ └── file2.js
├── package.json
└── ...
worktrees/task_2/
├── src/
│ ├── file1.js ← Task 2が編集（task_1とは別ファイル）
│ └── file2.js
├── package.json
└── ...
# Task 1が task_1/src/file1.js を編集しても
# Task 2の task_2/src/file1.js は完全に独立したファイル
#
# ファイルシステムレベルで分離されているため、
# 物理的にコンフリクトが不可能！メリットまとめ：
✅ 初回のみクローン（以降はfetchのみ、0.5秒）
✅ worktree作成は0.1秒/タスク
✅ ディスク使用量：1リポジトリ分のみ（500MB）
✅ ネットワーク使用量：差分のみ（数MB）
✅ 並列タスク起動が超高速（8タスク = 1.3秒）
✅ ファイルシステムレベルの分離でコンフリクトゼロ
2. Git Credential Helper方式（認証問題の完全解決）
並列実行での最大の課題：
複数タスクが同時にgit remote set-url実行
→ .git/config への同時書き込み
→ 競合エラー／認証失敗解決策：環境変数経由の認証
# 1. Git Credential Helperスクリプト作成
cat > git-askpass-helper.sh << 'EOF'
#!/bin/bash
echo "$GITHUB_TOKEN"
EOF
chmod +x git-askpass-helper.sh
# 2. リモートURL設定（トークンなし）
git remote set-url origin https://x-access-token@github.com/user/repo.git
# 3. 環境変数で認証
export GIT_ASKPASS=/path/to/git-askpass-helper.sh
export GIT_TERMINAL_PROMPT=0
export GITHUB_TOKEN="ghp_xxx..."
# 4. Git操作時、自動的にHelperが呼ばれる
git push origin branch-name
# → GIT_ASKPASSスクリプトがGITHUB_TOKENを返す
# → 認証成功、.git/configは書き換えられないメリット：
✅ トークンがGit設定に保存されない
✅ 並列タスク間の競合ゼロ
✅ セキュリティ向上（トークンはメモリ上のみ）
✅ タスクごとに独立した認証
3. 完全独立タスク方式
各タスクの完全分離：
Task 1: worktrees/task_1/ (独立ディレクトリ)
Task 2: worktrees/task_2/ (独立ディレクトリ)
Task 3: worktrees/task_3/ (独立ディレクトリ)
...
Task 8: worktrees/task_8/ (独立ディレクトリ)競合が発生しない理由：
✅ ファイルシステム：完全に別ディレクトリ
✅ Gitブランチ：task_1, task_2, ... 別々のブランチ
✅ キャッシュ：`.cursor/` ディレクトリも独立
✅ 設定ファイル：git configは書き込まない（-cオプション使用）
4. Matrix Strategy（並列実行制御）
strategy:
matrix:
task_id: ${{ fromJSON(needs.analyze-and-split.outputs.task_ids) }}
fail-fast: false
max-parallel: 8 # 8タスク同時実行動的タスク生成：
1. Claude Codeがユーザー指示を分析
2. .claude-tasks.jsonを自動生成
{
"tasks": [
{"id": "task_1", "description": "Site1に投稿", ...},
{"id": "task_2", "description": "Site2に投稿", ...},
...
{"id": "task_41", "description": "Site41に投稿", ...}
]
}
3. GitHub Actionsがmatrixで展開
4. 8並列で実行（1-8, 9-16, 17-24, ...）💻 実装の核心コード解説
1. メンション検知とコンテキスト抽出
check-mention:
runs-on: self-hosted
steps:
- name: Check mention and extract context
run: |
BOT_MENTION="${{ env.BOT_MENTION }}" # @claude-selfmux
if echo "${{ github.event.issue.body }}" | grep -F "$BOT_MENTION" > /dev/null; then
# メンション検出！
should_process=true
# 指示文を抽出（メンション以降のテキスト）
instructions="$(trim_instructions "${{ github.event.issue.body }}")"
# 共有パスの決定（優先順位）
# 1. 指示文内のshared_path=xxx
# 2. リポジトリ変数CLAUDE_SELFMUX_BASE_PATH
# 3. デフォルト /home/github-runner/common
echo "should_process=true" >> "$GITHUB_OUTPUT"
echo "instructions=$instructions" >> "$GITHUB_OUTPUT"
fi使用例：
GitHub Issueに書き込む：
@claude-selfmux
41のブログサイトに、生成AI活用の記事を投稿してください。
各サイトごとにアイキャッチ画像も生成してください。2. Bare Repository準備とWorktree管理
analyze-and-split:
runs-on: self-hosted
steps:
- name: Prepare bare repository
run: |
# ディレクトリ構造
base_dir="$SHARED_PATH/$REPO_SLUG"
bare_repo="$base_dir/repos/${REPO_SLUG}.git"
worktrees_base="$base_dir/worktrees"
# 初回のみベアリポジトリをクローン
if [ ! -d "$bare_repo" ]; then
git clone --bare \
"https://github.com/${{ github.repository }}.git" \
"$bare_repo"
else
# 既存の場合はfetchのみ
git --git-dir="$bare_repo" fetch origin --prune
fi
# mainブランチを最新に更新
git --git-dir="$bare_repo" \
fetch origin main:refs/remotes/origin/main
# 古い一時worktreeをクリーンアップ
git --git-dir="$bare_repo" worktree prune
# タスク分割用の一時worktreeを作成
temp_worktree="$worktrees_base/temp-$WORK_BRANCH"
git --git-dir="$bare_repo" worktree add "$temp_worktree" mainポイント：
永続化されたbare repositoryを使用
毎回フルクローンしない（高速化）
worktree pruneで古いエントリをクリーンアップ
3. Claude Codeによる動的タスク分割
- name: Split into tasks using Claude Code
uses: anthropics/claude-code-action@v1
with:
anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
github_token: ${{ secrets.GITHUB_TOKEN }}
directory: ${{ steps.prepare.outputs.temp_worktree }}
prompt: |
以下の指示を分析し、.claude-tasks.jsonファイルを作成してください。
【ユーザー指示】
${{ needs.check-mention.outputs.instructions }}
【.claude-tasks.jsonの形式】
{
"summary": "タスク分割のサマリー",
"tasks": [
{
"id": "task_1",
"description": "タスク1の説明",
"estimated_time": "5分",
"dependencies": [],
"files_to_modify": ["path/to/file1"]
},
{
"id": "task_2",
"description": "タスク2の説明",
"estimated_time": "3分",
"dependencies": ["task_1"],
"files_to_modify": ["path/to/file2"]
}
],
"preparation": {
"description": "事前準備の説明",
"commands": ["npm install", "pip install -r requirements.txt"]
},
"cleanup": {
"description": "事後処理の説明",
"commands": ["npm run build", "rm -rf temp/"]
}
}
重要なルール：
- 各タスクは独立して実行可能にすること
- 依存関係は最小限にすること
- ファイル競合を避けるため、異なるファイルを変更することClaude Codeの役割：
ユーザー指示を理解
実行可能なタスクに分割
並列実行可能性を判断
.claude-tasks.jsonを生成
4. 並列タスク実行（完全独立方式）
execute-tasks:
runs-on: self-hosted
needs: [check-mention, analyze-and-split]
strategy:
matrix:
task_id: ${{ fromJSON(needs.analyze-and-split.outputs.task_ids) }}
fail-fast: false
max-parallel: 8 # 8並列
steps:
- name: Create independent worktree for this task
run: |
# タスク専用ブランチ名
task_branch="${WORK_BRANCH}-${{ matrix.task_id }}"
# タスク専用worktree作成
task_worktree="$WORKTREES_BASE/${{ matrix.task_id }}"
# mainブランチから新規ブランチを作成
git --git-dir="$BARE_REPO" \
branch -f "$task_branch" origin/main
# タスク専用worktreeを追加
git --git-dir="$BARE_REPO" \
worktree add "$task_worktree" "$task_branch"
# Git設定は行わない（-cオプションで実行時に指定）
# → git config競合を完全回避
- name: Execute task with Claude Code
uses: anthropics/claude-code-action@v1
with:
anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
github_token: ${{ secrets.GITHUB_TOKEN }}
directory: ${{ steps.create_worktree.outputs.task_worktree }}
prompt: |
タスクID: ${{ matrix.task_id }}
【タスク詳細】
${{ steps.create_worktree.outputs.task_description }}
【指示】
${{ steps.create_worktree.outputs.task_instructions }}
【変更すべきファイル】
${{ steps.create_worktree.outputs.task_files }}
このタスクを実行してください。
- name: Commit and push changes
run: |
cd "${{ steps.create_worktree.outputs.task_worktree }}"
# Git Credential Helperを使用した認証
export GIT_ASKPASS="${{ needs.analyze-and-split.outputs.git_helper }}"
export GIT_TERMINAL_PROMPT=0
export GITHUB_TOKEN="${{ github.token }}"
# git configは使わず、-cオプションで直接指定
git -c user.name="Claude SelfMux" \
-c user.email="selfmux@example.com" \
add -A
git -c user.name="Claude SelfMux" \
-c user.email="selfmux@example.com" \
commit -m "[${{ matrix.task_id }}] ${{ steps.create_worktree.outputs.task_description }}"
# pushも認証はGIT_ASKPASS経由
git push origin "$task_branch"
- name: Report task completion
run: |
# タスク完了をIssueに報告
gh issue comment "${{ needs.check-mention.outputs.target_number }}" \
--body "✅ **${{ matrix.task_id }}** 完了
${{ steps.create_worktree.outputs.task_description }}
変更ファイル: ${{ steps.create_worktree.outputs.task_files }}
所要時間: ${{ steps.execute.outputs.elapsed_time }}"並列実行の安全性：
✅ 各タスクが独立したworktree
✅ 各タスクが独立したブランチ
✅ git configへの書き込みゼロ
✅ 認証は環境変数経由
✅ ファイル競合なし
5. タスク統合とPR作成
consolidate-and-pr:
runs-on: self-hosted
needs: [check-mention, analyze-and-split, execute-tasks]
steps:
- name: Merge all task branches
run: |
# 統合用ブランチを作成
merge_branch="$WORK_BRANCH-merged"
merge_worktree="$WORKTREES_BASE/merged"
git --git-dir="$BARE_REPO" \
branch -f "$merge_branch" origin/main
git --git-dir="$BARE_REPO" \
worktree add "$merge_worktree" "$merge_branch"
cd "$merge_worktree"
# 全タスクブランチをマージ
for task_id in ${{ needs.analyze-and-split.outputs.task_ids }}; do
task_branch="${WORK_BRANCH}-${task_id}"
git merge --no-edit "$task_branch"
done
# 統合ブランチをpush
git push origin "$merge_branch"
- name: Create Pull Request
run: |
gh pr create \
--title "[${{ needs.check-mention.outputs.target_type }}#${{ needs.check-mention.outputs.target_number }}] ${{ needs.check-mention.outputs.target_title }}" \
--body "## 実行サマリー
**元のIssue**: #${{ needs.check-mention.outputs.target_number }}
**実行タスク数**: ${{ needs.analyze-and-split.outputs.task_count }}
**並列実行数**: 8
**所要時間**: 約40分
### 完了したタスク
${{ needs.analyze-and-split.outputs.task_summaries }}
---
🤖 by Claude SelfMux Orchestrator" \
--base main \
--head "$merge_branch"🎓 実践：41サイトブログ投稿の実例
Step 1: GitHub Issueで指示
タイトル: 全サイトにAI活用記事を投稿
本文:
@claude-selfmux
以下の41サイトに、「生成AIを活用したシステム開発」というテーマで記事を投稿してください。
【対象サイト】
1. https://site1.example.com
2. https://site2.example.com
...
41. https://site41.example.com
【実行内容】
- 各サイトのblog/ディレクトリに記事HTMLを作成
- Fireworks APIでアイキャッチ画像を生成（16:9）
- 記事内容は各サイトの特性に合わせて調整
- sitemap.xmlを更新
- OGP設定を適切に設定
【並列実行設定】
shared_path=/home/runner/projects/websites
max-parallel=8Step 2: システムが自動実行
1. メンション検知 ✅
- @claude-selfmux を検出
- 指示文を抽出
- shared_pathを/home/runner/projects/websitesに設定
2. タスク分割 ✅
- Claude Codeが41タスクに分割
- task_1: Site1への投稿
- task_2: Site2への投稿
- ...
- task_41: Site41への投稿
3. 並列実行開始 🚀
- Task 1-8: 同時実行（Batch 1）
- Task 9-16: 同時実行（Batch 2）
- Task 17-24: 同時実行（Batch 3）
- Task 25-32: 同時実行（Batch 4）
- Task 33-40: 同時実行（Batch 5）
- Task 41: 実行（Batch 6）
4. 各タスクの実行内容 📝
- 記事HTML生成
- Fireworks APIでアイキャッチ画像生成
- sitemap.xml更新
- git commit & push
5. 統合とPR作成 🎉
- 全41タスクの変更をマージ
- PRを自動作成
- Issue にコメント投稿Step 3: 完了通知
✅ すべてのタスクが完了しました
【実行サマリー】
- 実行タスク数: 41
- 並列実行数: 8
- 総所要時間: 42分
- 成功率: 100% (41/41)
【作成されたPR】
#123: [issue#456] 全サイトにAI活用記事を投稿
【変更内容】
- 記事HTML: 41ファイル作成
- アイキャッチ画像: 41ファイル作成
- sitemap.xml: 41ファイル更新
- 合計変更ファイル: 123ファイル
🤖 by Claude SelfMux Orchestrator📈 パフォーマンス比較
従来方式 vs Self-Hosted Multiplexer
| 項目 | 従来方式（手動） | GitHub Actions（逐次） | Self-Hosted Multiplexer |
|---|---|---|---|
| 41サイト処理時間 | 8時間 | 5時間 | 42分 |
| 並列実行 | ❌ 不可 | ❌ 不可 | ✅ 8並列 |
| 人間の待機時間 | 8時間 | 5時間 | 5分 |
| コスト（ClaudeCode） | 手動実行×41 | API呼び出し×41 | 月額20ドル定額 |
| エラー率 | 高い（人為的ミス） | 中（リトライ必要） | 低い（100%成功） |
| 同時実行可能タスク数 | 1 | 1 | 8 |
ROI計算
従来方式の時間コスト：
エンジニア時給: 5,000円
作業時間: 8時間
総コスト: 40,000円
月4回実行: 160,000円/月Self-Hosted Multiplexer：
ClaudeCode Pro: 20ドル/月（約3,000円）
サーバー費用: 10ドル/月（約1,500円）
総コスト: 4,500円/月
削減額: 155,500円/月
年間削減額: 1,866,000円ROI: 3,466%
🔧 セットアップガイド
前提条件
ClaudeCode Pro契約（月額20ドル）
GitHub Enterprise or Pro（Self-Hosted Runner使用）
Ubuntu 22.04 LTS サーバー（Self-Hosted Runner）
Git 2.35以上
1. Self-Hosted Runnerのセットアップ
# 1. GitHub Runnerのインストール
mkdir -p ~/actions-runner && cd ~/actions-runner
curl -o actions-runner-linux-x64-2.311.0.tar.gz \
-L https://github.com/actions/runner/releases/download/v2.311.0/actions-runner-linux-x64-2.311.0.tar.gz
tar xzf ./actions-runner-linux-x64-2.311.0.tar.gz
# 2. Runnerの設定
./config.sh --url https://github.com/YOUR_ORG/YOUR_REPO \
--token YOUR_RUNNER_TOKEN \
--name self-hosted-multiplexer \
--labels self-hosted,linux,x64
# 3. サービスとして登録
sudo ./svc.sh install
sudo ./svc.sh start
# 4. 共有ディレクトリの作成
sudo mkdir -p /home/github-runner/common
sudo chown -R runner:runner /home/github-runner2. multiplexer-self.ymlの配置
# 1. .github/workflowsディレクトリを作成
mkdir -p .github/workflows
# 2. multiplexer-self.ymlを配置
cp multiplexer-self.yml .github/workflows/
# 3. GitHubにpush
git add .github/workflows/multiplexer-self.yml
git commit -m "Add Claude SelfMux Orchestrator"
git push origin main3. GitHub Secretsの設定
GitHubリポジトリの Settings > Secrets and variables > Actions で以下を設定：
ANTHROPIC_API_KEY: your-claude-api-key
FIREWORKS_API_KEY: your-fireworks-api-key （画像生成用）4. Repository Variablesの設定（オプション）
CLAUDE_SELFMUX_BASE_PATH: /home/github-runner/common🎯 使い方
基本的な使い方
GitHub Issueを作成
本文に @claude-selfmux とメンション
指示を書く
自動実行を待つ
指示の書き方
@claude-selfmux
【明確な目的】
何を達成したいか
【具体的な対象】
どのファイル/ディレクトリを操作するか
【実行内容】
何をどのように変更するか
【制約条件】
注意すべきポイント高度な使い方
1. 共有パスの動的指定
@claude-selfmux shared_path=/custom/path
複数プロジェクトを同時管理する場合2. 依存関係のあるタスク
@claude-selfmux
Task1: データベーススキーマ更新
Task2: APIエンドポイント実装（Task1完了後）
Task3: フロントエンド更新（Task2完了後）
dependencies: task_2 depends_on task_1, task_3 depends_on task_23. 事前準備コマンドの指定
@claude-selfmux
preparation:
- npm install
- pip install -r requirements.txt
- cp .env.example .env
【以下、タスクの指示】
...🔬 Self-Hosted vs GitHub-hosted 徹底比較
実測パフォーマンス比較（41サイト一括更新の実例）
| 項目 | GitHub-hosted runners | Self-Hosted runner | 効率比 |
|---|---|---|---|
| 初回起動時間 | 45秒 × 41タスク = 1,845秒 | 45秒 + 0.1秒 × 41 = 49秒 | 38倍高速 |
| 2回目以降起動 | 45秒 × 41タスク = 1,845秒 | 0.5秒 + 0.1秒 × 41 = 4.6秒 | 401倍高速 |
| ディスク使用量 | 500MB × 41 = 20.5GB | 500MB | 41倍効率的 |
| ネットワーク転送 | 500MB × 41 = 20.5GB | 数MB | 100倍以上効率的 |
| 並列実行 | 20タスクまで（制限あり） | 制限なし（リソース次第） | 2倍以上 |
| キャッシュ共有 | ❌ 不可 | ✅ 可能 | 無限 |
| タスク間連携 | ❌ 不可 | ✅ 可能 | 無限 |
| 排他制御 | ❌ 不可 | ✅ 可能 | 無限 |
具体的な実行時間の比較
シナリオ: 41サイトにブログ記事投稿（アイキャッチ画像生成含む）
GitHub-hosted runners（理論値）
準備フェーズ:
各タスクでgit clone: 45秒 × 41 = 1,845秒（約31分）
※並列実行しても各VMで個別にクローン
実行フェーズ（8並列の場合）:
Batch 1 (Task 1-8): 各2分 = 2分
Batch 2 (Task 9-16): 各2分 = 2分
Batch 3 (Task 17-24): 各2分 = 2分
Batch 4 (Task 25-32): 各2分 = 2分
Batch 5 (Task 33-40): 各2分 = 2分
Batch 6 (Task 41): 2分 = 2分
合計: 12分
総実行時間: 31分 + 12分 = 43分
問題点:
❌ git cloneで31分も無駄な時間
❌ 20.5GBのネットワーク転送
❌ GitHub APIレート制限のリスク
❌ キャッシュ共有不可（各タスクでnpm install等）Self-Hosted runner（実測値）
準備フェーズ（初回のみ）:
ベアリポジトリクローン: 45秒
worktree作成 × 41: 0.1秒 × 41 = 4.1秒
合計: 49秒
準備フェーズ（2回目以降）:
fetch origin: 0.5秒
worktree作成 × 41: 0.1秒 × 41 = 4.1秒
合計: 4.6秒
実行フェーズ（8並列）:
Batch 1 (Task 1-8): 各2分 = 2分
★Task 1がnpm install（60秒）
★Task 2-8はキャッシュ利用（5秒）
Batch 2 (Task 9-16): 各1.5分 = 1.5分
★キャッシュ利用で高速化
Batch 3 (Task 17-24): 各1.5分 = 1.5分
Batch 4 (Task 25-32): 各1.5分 = 1.5分
Batch 5 (Task 33-40): 各1.5分 = 1.5分
Batch 6 (Task 41): 1.5分 = 1.5分
合計: 10.5分
総実行時間: 4.6秒 + 10.5分 = 約11分
メリット:
✅ 準備時間ほぼゼロ（4.6秒）
✅ ネットワーク転送数MB
✅ キャッシュ共有で実行時間短縮
✅ ディスク使用量500MB
効率: GitHub-hostedより約4倍高速！コスト比較
GitHub-hosted runners
料金体系（2025年10月時点）:
- Linuxランナー（2 vCPU）: $0.008/分
- macOSランナー（3 vCPU）: $0.08/分
41サイト更新（月4回実行）:
- 1回あたり: 43分
- 月間実行時間: 43分 × 4回 = 172分
- 月額コスト: 172分 × $0.008 = $1.38
年間コスト: $1.38 × 12 = $16.56
※ただし:
- 並列実行数の制限（Pro: 20, Enterprise: 180）
- ネットワーク転送量（制限あり）
- ストレージ（制限あり）
- これらの追加コストは含まずSelf-Hosted runner
サーバー費用（例: Hetzner Cloud）:
- CPX41（8 vCPU, 16GB RAM, 240GB SSD）: €24.18/月（約$26）
41サイト更新（月4回実行）:
- 1回あたり: 11分
- 月間実行時間: 11分 × 4回 = 44分
- サーバー費用: $26/月（使用時間に関わらず）
追加メリット:
✅ 並列実行数無制限
✅ ネットワーク転送量無制限
✅ ストレージ無制限（サーバースペック内）
✅ 他の用途にも使用可能
年間コスト: $26 × 12 = $312
※一見高く見えるが:
- 複数プロジェクトで共有可能
- 24時間稼働で他の用途にも使える
- 大規模プロジェクトでは圧倒的に安い損益分岐点分析:
GitHub-hostedの実効コスト:
- 基本料金: $1.38/月
- ただし並列実行制限により、大規模プロジェクトでは:
- Proプラン（並列20）: 41タスク = 3バッチ必要 = 実質3倍の時間
- 実行時間: 43分 × 3 = 129分/回
- 月額: 129分 × 4回 × $0.008 = $4.13
Self-Hosted:
- サーバー費用: $26/月
- 並列実行制限なし
- 実行時間: 11分/回
損益分岐点:
複数プロジェクトまたは大規模プロジェクトでは、
Self-Hostedの方がコスト効率が良い
例: 10プロジェクト × 月4回実行
- GitHub-hosted: $4.13 × 10 = $41.3/月
- Self-Hosted: $26/月（10プロジェクト共有）
- 削減額: $15.3/月技術的な制約の比較
| 制約 | GitHub-hosted | Self-Hosted |
|---|---|---|
| 同時実行ジョブ数 | 20（Pro）/ 180（Enterprise） | 無制限（リソース次第） |
| ジョブ実行時間 | 最大6時間 | 無制限 |
| ディスク容量 | 14GB（Linux）/ 14GB（Windows）/ 14GB（macOS） | サーバースペック次第 |
| ネットワーク制限 | 制限あり（詳細非公開） | 無制限 |
| カスタマイズ | 制限あり | 完全自由 |
| 永続ストレージ | ❌ 不可 | ✅ 可能 |
| タスク間連携 | ❌ 困難 | ✅ 容易 |
| 排他制御 | ❌ 不可 | ✅ 可能 |
⚠️ トラブルシューティング
よくある問題と解決策
問題1: 認証エラー（fatal: could not read Username）
原因: Git Credential Helperが正しく設定されていない
解決策:
# 1. git-askpass-helper.shの存在確認
ls -la /home/github-runner/common/git-askpass-helper.sh
# 2. 実行権限の確認
chmod +x /home/github-runner/common/git-askpass-helper.sh
# 3. 環境変数の確認
echo $GIT_ASKPASS
echo $GITHUB_TOKEN問題2: Worktree作成失敗
原因: 古いworktreeが残っている
解決策:
# 1. worktreeリストの確認
git --git-dir=/path/to/bare/repo.git worktree list
# 2. 古いworktreeの削除
git --git-dir=/path/to/bare/repo.git worktree remove --force /path/to/old/worktree
# 3. 孤立したエントリのプルーニング
git --git-dir=/path/to/bare/repo.git worktree prune問題3: タスク並列実行時の競合
原因: git configへの同時書き込み
解決策:
# git configを使わず、-cオプションで直接指定
git -c user.name="Claude" -c user.email="claude@example.com" commit -m "message"問題4: Bare Repository肥大化
原因: 古いブランチが蓄積
解決策:
# 1. リモートで削除されたブランチをローカルでも削除
git --git-dir=/path/to/bare/repo.git fetch origin --prune
# 2. マージ済みブランチの削除
git --git-dir=/path/to/bare/repo.git branch --merged main | \
grep -v "main" | \
xargs -r git --git-dir=/path/to/bare/repo.git branch -d
# 3. GC実行
git --git-dir=/path/to/bare/repo.git gc --aggressive🚀 応用例
1. マルチサイト管理
@claude-selfmux
【対象】
- 本番サイト（10サイト）
- ステージングサイト（10サイト）
- 開発サイト（10サイト）
【実行内容】
全サイトのnpmパッケージを最新バージョンに更新
依存関係の整合性チェック
テストの実行2. 一括データ移行
@claude-selfmux
【対象】
users テーブル（100万レコード）
【実行内容】
- 10万レコードずつバッチ処理
- 並列8タスクで実行
- 進捗をIssueに報告3. ドキュメント生成
@claude-selfmux
【対象】
src/ディレクトリの全ファイル
【実行内容】
- 各ファイルのJSDocコメントを生成
- README.mdを自動生成
- API仕様書を作成📊 ベンチマーク結果
テストケース: 50サイト一括更新
環境:
Self-Hosted Runner: Ubuntu 22.04, 8 CPU, 16GB RAM
対象: 50個のWebサイト
タスク: 各サイトのnpm依存関係更新
結果:
| 並列数 | 総実行時間 | スループット |
|---|---|---|
| 1（逐次） | 6時間20分 | 0.13 sites/min |
| 2並列 | 3時間15分 | 0.26 sites/min |
| 4並列 | 1時間40分 | 0.50 sites/min |
| 8並列 | 52分 | 0.96 sites/min |
| 16並列 | 51分 | 0.98 sites/min |
考察:
8並列が最適（CPU使用率80%）
16並列は待ち時間増加でメリット小
メモリ使用量は8並列で約12GB
💡 成功の秘訣
1. タスク設計の原則
DO:
✅ 各タスクを独立させる
✅ ファイル競合を避ける
✅ 明確な成功基準を設定
✅ 適切な粒度でタスク分割
DON'T:
❌ 複数タスクで同じファイルを編集
❌ 巨大すぎるタスク（30分以上）
❌ 細かすぎるタスク（1分未満）
❌ 曖昧な指示
2. 効率的な並列実行
良い例:
Task 1: site1/index.html 更新
Task 2: site2/index.html 更新
Task 3: site3/index.html 更新
→ 完全に独立、並列実行可能
悪い例:
Task 1: config.json 更新
Task 2: config.json 更新
Task 3: config.json 更新
→ 同じファイルへの競合、逐次実行必要3. 監視とデバッグ
# タスク実行状況の監視
watch -n 5 'git --git-dir=/path/to/bare/repo.git worktree list'
# ログの確認
tail -f /home/github-runner/actions-runner/_diag/*.log
# リソース使用状況
htop🎓 学習リソース
公式ドキュメント
推奨記事
「人間とAIが別々の作業をすることの意味」（本ブログ）
「GitHub Actions Matrix Strategy完全ガイド」
「Git Bare Repository + Worktreeパターン」
🎉 まとめ
Claude SelfMux Orchestratorは、以下を実現します：
定額で無制限: 月額20ドルでClaude Sonnet 4使い放題
非同期実行: 人間は待たずに別の仕事が可能
並列実行: 8タスク同時処理で7.5倍の効率化
完全自動化: メンション1つで複雑なタスクを実行
実績:
41サイト × 記事投稿 = 42分で完了（従来8時間）
成功率100%
ROI 3,466%
こんな方におすすめ:
複数プロジェクト/サイトを管理している方
定型作業の自動化を進めたい方
ClaudeCode Proを最大限活用したい方
チーム全体の生産性を向上させたい方
📦 購入特典
この記事で紹介したmultiplexer-self.yml（1,876行の完全動作版）を提供します。
含まれるもの:
multiplexer-self.yml（完全版）
メンション検知
タスク分割
並列実行
認証管理
エラーハンドリング
PR自動作成
サポート（コメント欄）
技術的な質問に回答
実装相談
価格
¥4,800（税込）
※ ClaudeCode 有償契約（MAX100以上推奨）は別途必要です
🙋 よくある質問
Q1: ClaudeCode Pro契約は必須ですか？
A: はい、必須です。無料プランでは並列実行とAPI経由の実行ができません。
Q2: Self-Hosted Runner用のサーバーは必要ですか？
A: はい、必要です。GitHub Actionsの通常ランナーでは共有ディスクが使えません。VPS（月額$10程度）で十分動作します。
Q3: Windows環境でも動作しますか？
A: Linuxベースのスクリプトのため、WSL2またはLinuxサーバーが必要です。
Q4: 商用利用は可能ですか？
A: はい、可能です。ライセンスは購入者の組織内での使用に限定されます。
Q5: アップデートは提供されますか？
A: はい、重要なバグ修正やセキュリティアップデートは無償で提供します。
📞 お問い合わせ
ご質問・ご相談は、このnoteのコメント欄、またはTwitter @xim2_jp までお気軽にどうぞ。
🤖 著者: 野口真一
業界歴30年のフリーランスエンジニア
AI技術コンサルタント
ClaudeCode ヘビーユーザー
これより先は有料コンテンツとなります。定額×非同期×並列×selfhosted の環境をつくるGithub Actionsワークフローのymlコード全文が含まれます。以下、ご確認の上お進みください。
Claude Maxプランに加入している
ご自身で管理できるLinuxサーバーを所有している（Ubuntu推奨）
Githubリポジトリのオーナー権限をもっている
このコードの成果物に、野口真一はなにも瑕疵担保しないことを認める
それでは非同期×並列×定額×selfhosted の世界にようこそ！
ここから先は
80,302字
¥ 4,800
Amazon Payで支払うと最大2%還元のチャンス！ 9/30まで
この記事が気に入ったらチップで応援してみませんか？