1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Windows miniPC に Claude Code を 3 セッション常駐させ、ノートPCから Remote Control で任せる

1
Last updated at Posted at 2026-11-05

はじめに

会社から配布された miniPC に Claude Code を常駐させ、ノートPC からは指示を出すだけ、という運用を始めました。調査・開発・資料作成といった作業は miniPC 上の Claude Code が進め、手元のノートPC は「依頼・確認・承認」に専念します。

この記事では、その構成と、無人の miniPC に AI を任せるために決めた運用ルールを紹介します。

この記事の内容は 2026年11月時点のものです。Claude Code は更新が速いため、機能や設定方法は公式ドキュメントで最新情報を確認してください。

ノートPCは指示を出すだけ。作業は常駐miniPCで。

なぜ miniPC に分けたのか

ノートPC だけで Claude Code を使っていると、次のような不便がありました。

  • 長い調査や開発を任せている間、ノートPC を閉じられない
  • Docker やコンテナが動いていると、普段使いのアプリが重くなる
  • 会議や移動のたびに作業が止まる

そこで、作業する場所(miniPC)と、人が考えて判断する場所(ノートPC)を分けることにしました。

全体構成:手元は指示だけ、作業は miniPC で

全体構成

  • miniPC の前に人はいない前提です。判断が必要な操作は、Claude Code が理由を添えて質問してきます。
  • 社内 Wiki は MCP 経由で検索・参照しています。
  • 成果物は OneDrive で受け渡します。

つなぎ方:Claude Desktop から Remote Control で常駐セッションへ

役割 使っているもの
ノートPC Claude Desktop アプリ
接続 Remote Control
miniPC Claude Code のセッション ×3(常駐)

手元の Claude Desktop から、miniPC で常駐している Claude Code のセッションに接続するだけです。miniPC 側で SSH サーバーを立てたりポートを開けたりする必要はありません。

セッションは3つ常駐させ、空いているものを選んで使っています。話題が変わったら /clear で履歴を消し、同じセッションを次の作業に使い回します。長い調査を任せている間に、別のセッションで次の依頼を進めることもできます。

組織のプランで Claude を使っている場合、Remote Control を使うには管理者による有効化が必要なことがあります。私たちの環境でも、管理者に組織設定で有効化してもらいました。

常時起動の仕組み

常時起動の仕組み

# 項目 内容
1 サインインで起動 タスク スケジューラで、Windows サインイン時に3つのセッションを起動し、Remote Control にも自動で接続する
2 止まっても自動復帰 セッションが終了しても、30秒後に自動で起動し直す
3 スリープしない 電源設定でスリープを無効にし、いつでも指示を受けられる

実際の仕組みは、起動スクリプト、タスク スケジューラへの登録、Remote Control の自動接続設定の3つでできています。

起動スクリプト(start-claude.ps1)

1番の画面が2番以降の画面を別ウィンドウで起動し、各画面が自分の claude を見張って、終了したら30秒後に起動し直します。

start-claude.ps1
# Claude Code 常駐起動スクリプト(タスクスケジューラからログオン時に実行)
# - claude のセッションを $Count 個常駐させる(1 番が 2 番以降を別画面で起動)
# - 各画面は自分の claude が終了したら 30 秒後に起動し直す(自動復帰)
# - 起動前に Docker のエンジンを確認し、止まっていれば Docker Desktop を起動する
param(
    [int]$Slot = 1,   # この画面の番号(タスクからは指定なし = 1)
    [int]$Count = 3   # 常駐させるセッションの数(1 番だけが見る)
)
$ErrorActionPreference = 'Continue'
$claude    = Join-Path $env:USERPROFILE '.local\bin\claude.exe'
$dockerExe = Join-Path $env:LOCALAPPDATA 'Programs\DockerDesktop\Docker Desktop.exe'
$logDir    = 'C:\claude-worker\logs'
$log       = Join-Path $logDir 'start-claude.log'
New-Item -ItemType Directory -Force $logDir | Out-Null
# ログが 1MB を超えたら切り替える(1 番だけが行う)
if ($Slot -eq 1 -and (Test-Path $log) -and (Get-Item $log).Length -gt 1MB) { Move-Item $log "$log.old" -Force }
Set-Location 'C:\claude-worker'   # claude を起動するフォルダ(CLAUDE.md や .claude\settings.json を置く場所)
$Host.UI.RawUI.WindowTitle = "claude-worker (auto) #$Slot"

function Write-Log($msg) {
    $line = "[$(Get-Date -Format 'yyyy-MM-dd HH:mm:ss')] [#$Slot] $msg"
    Write-Host $line
    # 複数の画面が同じログに書くので、重なったら少し待って再試行する
    for ($i = 0; $i -lt 5; $i++) {
        try { Add-Content -Path $log -Value $line -Encoding utf8 -ErrorAction Stop; return } catch { Start-Sleep -Milliseconds 200 }
    }
}

function Test-DockerEngine {
    docker version --format '{{.Server.Version}}' *> $null
    return ($LASTEXITCODE -eq 0)
}

# Docker が応答しなければ Docker Desktop を起動する。$Wait のときは最大 3 分待つ(失敗しても claude は起動する)
function Ensure-Docker([bool]$Wait) {
    if (-not (Get-Command docker -ErrorAction SilentlyContinue)) { Write-Log "docker コマンドが見つかりません"; return }
    if (Test-DockerEngine) { Write-Log "Docker は応答しています"; return }
    if (-not (Test-Path $dockerExe)) { Write-Log "Docker Desktop が見つかりません: $dockerExe"; return }
    if (-not (Get-Process 'Docker Desktop' -ErrorAction SilentlyContinue)) {
        Write-Log "Docker Desktop を起動します"
        Start-Process $dockerExe
    }
    if (-not $Wait) { return }
    for ($i = 0; $i -lt 36; $i++) {
        Start-Sleep -Seconds 5
        if (Test-DockerEngine) { Write-Log "Docker が起動しました"; return }
    }
    Write-Log "Docker が 3 分以内に起動しませんでした"
}

$first   = ($Slot -eq 1)   # Docker の起動を待つのは 1 番の 1 回目だけ
$spawned = ($Slot -ne 1)
while ($true) {
    if (-not (Test-Path $claude)) { Write-Log "claude.exe が見つかりません: $claude"; break }
    Ensure-Docker -Wait $first
    $first = $false
    if (-not $spawned) {
        # 2 番以降を別の PowerShell 画面で起動する(各画面が自分の claude を見張る)
        $pwsh = (Get-Process -Id $PID).Path
        for ($n = 2; $n -le $Count; $n++) {
            Write-Log "セッション #$n の画面を起動します"
            Start-Process $pwsh -ArgumentList @('-NoProfile', '-NoExit', '-ExecutionPolicy', 'Bypass', '-File', "`"$PSCommandPath`"", '-Slot', $n)
            Start-Sleep -Seconds 5   # Remote Control への接続が重ならないよう少しずらす
        }
        $spawned = $true
    }
    Write-Log "claude を起動します"
    & $claude
    Write-Log "claude が終了しました(終了コード $LASTEXITCODE)。30 秒後に起動し直します"
    Start-Sleep -Seconds 30
}

タスク スケジューラへの登録

設定は次のとおりです。

  • 起動のきっかけ:ログオン時
  • 実行時間:上限なし
  • 二重に起動しない
  • バッテリー駆動中でも起動する

同じ設定にする登録コマンドの例です(PowerShell 7 の pwsh を使う前提です)。

$pwsh = (Get-Command pwsh).Source
$action  = New-ScheduledTaskAction -Execute $pwsh `
  -Argument '-NoProfile -NoExit -ExecutionPolicy Bypass -File "C:\claude-worker\start-claude.ps1"'
$trigger = New-ScheduledTaskTrigger -AtLogOn -User $env:USERNAME
$settings = New-ScheduledTaskSettingsSet -ExecutionTimeLimit 0 -MultipleInstances IgnoreNew `
  -AllowStartIfOnBatteries -DontStopIfGoingOnBatteries
Register-ScheduledTask -TaskName ClaudeWorker-AutoStart -Action $action -Trigger $trigger -Settings $settings

Remote Control の自動接続

claude を起動するフォルダ(ここでは C:\claude-worker)の .claude/settings.json に次のように書くと、起動時に Remote Control へ自動で接続します。

.claude/settings.json
{
  "remoteControlAtStartup": true
}

補足:

  • 起動のきっかけがログオンなので、再起動したあとは Windows へのサインインが必要です。セキュリティを考え、自動サインインはあえて設定していません。スリープも無効にしておきます。
  • 止めたいときは、「claude-worker (auto) #n」の画面を閉じます。
  • Docker の確認を入れたのは、Windows のスタートアップに登録しただけでは Docker Desktop が起動していないことがあったためです。

作業の流れ:AI の成果物は AI がまず検証する

作業の流れ

  1. 依頼:ノートPC から普通の文章で指示
  2. 作業:調査・実装・資料作成
  3. 検証:レビュー役のサブエージェントが並列で指摘
  4. 修正:重大な指摘がなくなるまで修正と再検証を繰り返す(検証は最大3回)
  5. 報告:確認内容を添えて渡す(重大な指摘が残れば人に相談)

レビュー役のサブエージェントは次の4種類を用意し、成果物に応じて2〜3体を選びます。

  • 依頼どおりかの確認
  • 事実の裏取り
  • 日本語の校正
  • コードの正しさ

どの指摘にも根拠を必須にしています。

工夫しているのは、レビュー役には元の依頼文と成果物だけを渡し、作成側の考えは渡さないことです。作成側の説明を読ませると、それに引っ張られて追認しがちになるためです。上限の3回で重大な指摘が残った場合は、確定させずに人に相談します。

ユースケース

ユースケース1(実績):脆弱性の影響調査を全リポジトリ横断で

依頼:公開された〇〇の脆弱性、うちのプロジェクトに影響ある?

  1. Git ホスティングから全プロジェクト(100件超)を取得
  2. 設定ファイルから実行環境とライブラリを抽出
  3. 該当する処理を検索し、一部は実際に動かして確認
  4. 影響を判定し、推奨対応つきの報告書を作成

影響の可能性があるプロジェクトを洗い出し、対応を「至急・早期・計画」の3段階の優先度で整理した報告書が OneDrive に届きました。人が1件ずつ確認すると数日かかる作業です。

本番環境は確認しておらず、リポジトリの記述からの推定です。最終判断は人が行っています。

ユースケース2(想定例):テスト駆動で開発し、レビュー依頼まで作成

依頼:この不具合を直して、MR(マージリクエスト)を出しておいて

※ まだ実施していない想定例です。開発時のルールに沿った流れを示しています。

  1. 作業用ブランチを作成
  2. 不具合を再現するテストを書き、失敗を確認
  3. 開発用コンテナで修正し、テストを合格させる
  4. レビュー役の検証後、MR を作成

ビルドとテストは、プロジェクトごとの開発用コンテナ(devcontainer)の中で行います。Claude Code 自体は miniPC 本体で動かし、コンテナは「テストと動作確認の場」として devcontainer CLI で起動します。VS Code は使っていません。

# 開発用コンテナを起動(<repo> は対象のフォルダ)
devcontainer up --workspace-folder <repo>
# コンテナ内でテストを実行
devcontainer exec --workspace-folder <repo> npm test

この形にすると、miniPC 本体にプロジェクトごとのツールを入れずに済み、人も同じ環境を再現できます。なお、テストのないリポジトリでは、テストの土台を入れるかを作業前に人に確認させています。

ユースケース3(実績):社内ナレッジ整理と資料作成

依頼:社内 Wiki にある GitHub Copilot の使用状況をまとめて

  1. 社内 Wiki から MCP でページを取得
  2. 必要な部分を Markdown に整理
  3. OneDrive の作業フォルダへ保存

Office 資料も作れます。この記事の元になった紹介スライド(PowerPoint)も、miniPC 上の Claude Code が作成しました。既存ファイルは上書きせず、別名で出力するルールにしています。

利用枠の節約:余計なものを読ませない

利用枠の節約

常駐させて長時間働かせると、利用枠(コンテキストとレート上限)の消費が気になります。そこで、AI に余計なものを読ませない工夫をしています。

# 工夫 内容
1 context-mode 大きなコマンド出力は AI の外で処理し、結果だけ受け取る
2 Serena コードは丸ごと読まず、必要なシンボルだけ読む
3 レビュー役のサブエージェント レビューは別の AI に任せ、結論だけ受け取る
4 /clear 話題が変わったら会話の履歴をリセットする

context-mode は Claude Code のプラグインとして導入しています。上の GitHub リポジトリをマーケットプレイスとして追加(/plugin marketplace add mksglu/context-mode)したあと、/plugin install で入れています。

context-mode の統計(ctx_stats)で計測したところ、あるセッションで処理した約1.3MB のうち、AI が読んだのは数十KB。調べた情報の 約98% を読まずに済んでいました。読む量が減るほど同じ利用枠で長く作業でき、会話の自動圧縮も起きにくくなります。

/clear は、話題が変わったら Claude Code の側から提案する運用にしています。context-mode に残した作業内容は、/clear 後も検索で引き継げます。

無人の AI に安心して任せるための運用ルール

# ルール 内容
1 判断が要る操作は質問 miniPC の前に人がいない前提なので、理由を添えて質問させる
2 共有ブランチを直接触らない 作業はブランチで行い、MR で出す。取り込むのは人
3 成果物は検証してから渡す レビュー役の重大な指摘を解消してから渡す
4 ルールは文章で管理 「ルールにして」と言えば CLAUDE.md に追記され、次回以降に反映

ルールを CLAUDE.md に文章で積み上げていくことで、使うほど「任せられる範囲」が広がっていく感覚があります。

使っているもの一覧

区分 使っているもの 用途
AI Claude Code miniPC に常駐して作業する本体
AI サブエージェント 成果物のレビュー(依頼・事実・日本語・コード)
接続 Claude Desktop・Remote Control ノートPC から指示・確認・承認
拡張 context-mode 大きな出力を AI の外で処理
拡張 Serena(MCP) コードを必要な部分だけ読む
拡張 社内 Wiki 連携(MCP) 社内ナレッジの検索・取得
開発 git・ghq・glab リポジトリ管理、ブランチ作業、MR 作成
開発 Docker Desktop・devcontainer CLI 開発用コンテナでビルド・テスト
資料 Python・Node.js・pandoc Office 資料・PDF の作成
資料 OneDrive 成果物の受け渡し
基盤 Scoop・uv コマンドラインツールと Python 環境の管理
基盤 タスク スケジューラ サインイン時の起動

まとめ

  1. 専用マシンで常駐:Claude Desktop からつなぐだけ。3セッションを使い分け、止まっても自動復帰
  2. 調査・開発・資料まで:横断調査と資料作成は実績あり。開発もテスト駆動で進める環境とルールを準備済み
  3. AI が AI をチェック:レビュー役のサブエージェントで確かめてから人に渡す

「AI に任せる時間」と「人が考える時間」を物理的に分けたことで、待ち時間がほぼなくなりました。miniPC が手元にある方は、ぜひ試してみてください。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?