Windows で Claude Code、どこで詰まるか

Claude Code を Windows 11 の業務端末で、毎朝の自動実行として本番運用しています。2026年8月16日から動かしていて、日本語環境で実際に詰まった箇所がはっきりしました。

先に結論です。動きます。ただし放っておくと壊れます。 日本語環境の Windows では、出力が文字化けし、外部CLIが見つからず、長いプロンプトがシェルで壊れます。どれも「たまに」ではなく、当メディアではPythonファイル58本のうち41本（71%）で文字コードの明示的な指定が必要でした。

この記事は、その4か所を再現条件と対策コードつきで書いたものです。うまくいった話ではありません。 3つは今日（2026年9月2日）実際に踏んだ失敗で、そのうち1つは自作のガードが自分の正常な処理を誤って止めたものです。

Claude Code とは（Windows で何が変わるか）

ターミナルで動く、Anthropic 公式のコーディング用エージェントです。ブラウザ版の Claude との違いは1点で、あなたのマシンでファイルを読み書きし、コマンドを実行します。

この「あなたのマシンで動く」がそのまま Windows 固有の問題になります。

ブラウザ版で困らなかった人が Claude Code で詰まるのは、OS の差が初めて表に出てくるからです。 日本語版 Windows は文字コードが CP932 なので、ここが最初に効きます。

Windows で使えるのか

使えます。 当メディアは Windows 11 上で毎朝の自動実行を本番運用しています。WSL は必須ではありません。

ただし「動く」と「放っておいても壊れない」は別です。この記事はその差を埋めるためのものです。

料金（Windows でも同じ）

OS によって金額は変わりません。 ただし前提として、Free プランでは Claude Code が使えません。

（2026-09-30 公式ページ再取得。金額は税抜で、消費税は別途かかります。ブラウザで開くと税込で出ることがあり、2026-09-30 に当メディアの環境で開いた画面では、10%を足した $22・$110・$27.50 が「Prices include 10% JCT」の注記つきで出ました。金額の下が「Prices include 10% JCT」なら税込、「表示価格には該当する税金は含まれていません」なら税抜です。前版の表はこの税込表示の金額でした。値上げではありません）

試すだけでも Pro 以上が必要なので、環境構築の前に契約を済ませてください。プランの選び方はClaude Codeの料金にまとめています。

まず動くところまで（インストールと起動確認）

詰まる話の前に、動くところまでを短く書きます。ここで詰まる人は少ないので、先に通してください。

1. Node.js を入れる（公式インストーラでよい）。node -v でバージョンが出れば通っています
2. Claude Code を入れる — npm install -g @anthropic-ai/claude-code
3. 起動する — 作業したいフォルダで claude
4. ログインする — 初回起動時にブラウザが開くので、Claude のアカウントで認証します

claude -v でバージョンが出て、claude で対話が始まれば、インストールは終わりです。 Free プランでは Claude Code が使えないため、Pro 以上の契約が必要です （料金はClaude Codeの料金）。

ここまでは Windows でも素直に通ります。 問題はこの後、日本語環境で自動実行に載せた時に出ます。

詰まる4か所

順に書きます。1と3を先に潰さないと、あとの検証が全部あてにならなくなります。

罠1 文字コード（既定のCP932でAPIの日本語が壊れる）

日本語版 Windows のコンソールは既定が CP932 です。APIから返ってきた日本語をそのまま標準出力へ書くと壊れます。実際に、Google Sheets API から取得した日本語のシート名が読めない状態で返ってきました。

環境変数だけでは足りません。呼び出し元が環境変数を引き継がない経路があります。 当メディアはタスクスケジューラから .cmd を起動し、その中でPythonを呼ぶ構成なので、両方に入れています。

import sys

for s in (sys.stdout, sys.stderr):
    if s.encoding and s.encoding.lower() != "utf-8":
        s.reconfigure(encoding="utf-8")

これを58本のうち41本に入れています。新しくスクリプトを足すたびに必要なので、テンプレート化しておくのが現実的です。

外部プロセスを呼ぶときは、環境変数も明示的に渡します。

import os, subprocess, sys

r = subprocess.run(
    [sys.executable, "child.py"],
    capture_output=True, text=True,
    encoding="utf-8", errors="replace",
    env={**os.environ, "PYTHONIOENCODING": "utf-8"},
)

errors="replace" を付けているのは、壊れた1文字で処理全体を落とさないためです。ログ用途なら潰れた文字が残るほうが、例外で止まるより追いやすくなります。

書き込み側も別に必要

読み書きは別の問題です。Pythonでテキストを書くとき、Windowsでは既定で改行が CRLF に変換されます。CSVやSVGを書くと余分な改行が入ります。当メディアでは14本のファイルで指定しています。

import io

io.open(path, "w", encoding="utf-8", newline="").write(text)

罠2 シェルを通すと、CLIも指示も壊れる

シェルを経由する時点で2種類の壊れ方をします。CLIそのものが見つからないのと、渡した文字列が届かないのです。両方とも今日踏みました。

CLIがPATHから解決されない

今日実際に踏みました。Git Bash から codex を名前で呼んだところ command not found で落ちました。PATH に載っていても、Git Bash 側のシェルからは解決されないことがあります。

対策はフルパスで持つことです。

from pathlib import Path

CODEX = Path(r"C:\Users\takum\bin\codex.cmd")

if not CODEX.exists():
    raise SystemExit(f"[ERROR] CLI がありません: {CODEX}")

.cmd や .bat のラッパーは、シェルによって解決の仕方が変わります。「自分の端末では通る」で書くと、タスクスケジューラから起動した時に落ちます。 当メディアが .cmd ラッパーを5本持っているのは、この差を1箇所に閉じ込めるためです。

長い日本語プロンプトが届かない

これも今日踏みました。しかも壊れたことに気づきにくいという点で、4つのうち一番厄介です。

外部の生成CLIへ、日本語で20行ほどの指示をコマンド引数として渡しました。エラーは出ませんでした。返ってきたのは、指示と全く関係のない画像でした。禁止したはずの表現がそのまま入っており、指定した文字も1つも描かれていませんでした。

原因は、長い引数がシェルを通る途中で壊れて、指示がほとんど届いていなかったことです。モデルが指示を無視したのではなく、指示が到達していませんでした。

対策は標準入力から渡すことです。

import subprocess, tempfile
from pathlib import Path

with tempfile.NamedTemporaryFile("w", suffix=".txt", delete=False,
                                 encoding="utf-8") as f:
    f.write(prompt)
    pf = Path(f.name)
try:
    with pf.open("r", encoding="utf-8") as fh:
        r = subprocess.run([str(CLI), "exec", "-"], stdin=fh,
                           capture_output=True, text=True,
                           encoding="utf-8", errors="replace", timeout=420)
finally:
    pf.unlink(missing_ok=True)

この失敗の見つけ方が本題です。 エラーが出ないので、出力を目で見るまで気づけません。当メディアは生成物を毎回目視で確認する手順を入れていて、今回もそれで気づきました。「エラーが出ていないから通っている」と扱わないでください。

罠3 ファイルロックのAPIがOS依存

複数のジョブが同じリポジトリを触るなら排他制御が要ります。Windowsでは msvcrt を使います。当メディアは3箇所で使っています。

import msvcrt

msvcrt.locking(handle.fileno(), msvcrt.LK_NBLCK, 1)   # 取れなければ即例外

Linux や macOS へ移すときは fcntl へ置き換えが必要です。

import fcntl

fcntl.flock(handle.fileno(), fcntl.LOCK_EX | fcntl.LOCK_NB)

ここがWSL移行の判断材料になります。 ロック実装を書き換える前提なら、移行は「環境を変える」ではなく「コードを直す」作業になります。

自分のガードが自分を止めた

今日もう1つ踏みました。当メディアには、誤ってサーバーへアップロードするのを止めるガードを入れています。このガードは、実行しようとしているPythonスクリプトの中身まで読んで判定します。

そのガードが、図解を生成するだけの正常な処理をブロックしました。

原因は相対パスです。python cron/foo.py のように相対パスで呼ぶと、ガード側が自分の作業ディレクトリを基準に解決しようとして、ファイルを読めません。読めなかったときは安全側に倒す設計なので、ブロックされました。

対策は呼び出し側をフルパスにすることでした。Windowsに限った話ではありませんが、作業ディレクトリがシェルごとに変わる環境では起きやすくなります。 安全側に倒す設計そのものは正しいので、ガードを緩めるのではなく呼び出し方を直しました。

CLAUDE.md に書いておく Windows 固有のこと

プロジェクト直下に置くと毎回読まれる設定ファイルです。/init で雛形が作れます。

Windows で運用するなら、ここに書いておくと同じ失敗を繰り返さなくなります。 当メディアが実際に書いている内容を出します。

【この環境の前提】
- Windows 11 / 日本語環境（コンソールの既定は CP932）
- Python スクリプトは必ず標準出力を UTF-8 に切り替える
- ファイル書き込みは newline="" を付ける（CRLF の二重変換を防ぐ）
- 外部 CLI はフルパスで呼ぶ（PATH に載っていても解決されないことがある）
- 長い日本語の指示は引数で渡さない。標準入力から渡す

【使うスクリプト】
| やること | コマンド |
|---|---|
| 画面を撮る | python scripts/page_screenshot.py <URL> |
| 公開する | python cron/safe_publish.py --deploy |

上4行を書いておくだけで、新しいスクリプトを作るたびに指摘する手間が消えます。

書いても守られないものは hook にする

設定ファイルは読まれますが、長くすると他の指示が薄まります。 当メディアの実測では、「破ったら止まる」仕組みに寄せたほうが確実でした。

hook の実装例はClaude Code の hooks でガードレールを作るにあります。

置き場所

Windows 固有の前提は「自分だけの好み」ではありません。 同じ環境で作業する人が他にもいるなら、リポジトリ側に置いてください。

定期実行に載せるとき（タスクスケジューラ）

手元で動いたあと、自動実行に載せた瞬間に壊れます。 当メディアはここで一番時間を使いました。

手元で動いて自動実行で落ちる3つの理由

1つ目が最も多いです。 タスクスケジューラは対話シェルとは別の環境で起動するため、手元の設定が効きません。

.cmd ラッパーを1枚挟んで、そこに全部書くのが確実でした。

@echo off
chcp 65001 > nul
set PYTHONIOENCODING=utf-8
set PYTHONUTF8=1
cd /d C:\path\to\project
C:\path\to\python.exe cron\daily_job.py >> logs\daily.log 2>&1

chcp 65001 はコンソールのコードページを UTF-8 に切り替えるコマンドです。 これと PYTHONIOENCODING の両方を入れているのは、片方だけでは抜ける経路があったためです。

バッチファイル自体の文字コード

.cmd / .bat は ASCII + CRLF で保存してください。 日本語コメントを入れて UTF-8 で保存すると、実行時に文字化けして構文エラーになります。

当メディアはバッチには日本語を一切書かないことにしました。説明が必要なら、隣に .md を置きます。

ログを必ずファイルへ出す

... >> logs\daily.log 2>&1

自動実行は画面を見られないので、これが無いと原因が分かりません。 2>&1 を付けてエラー出力もまとめてください。当メディアは最初これを忘れて、落ちた理由を推測で探していました。

相対パスで踏んだ実例

自作のガードスクリプトが、相対パスで渡された .py を解決できずに正常な処理を誤ってブロックしたことがありました。手元では動いていたので、原因の切り分けに時間がかかりました。

「自分の端末では通る」で書くと、自動実行で落ちます。 絶対パスに寄せるほうが、書くときは面倒でも後が楽です。

この環境で実際に使っている数（30日間の実測）

「Windows で本当に運用できるのか」への答えを、数字で出します。当メディアは Windows 11 上のターミナルだけで運用しています。

操作の6割超がシェル実行です。 つまり Windows で運用するというのは、「日本語環境の cmd / Git Bash に毎日5,000回コマンドを投げる」ということです。文字コードとパスの問題が効いてくる理由がここにあります。

Windows 固有の対処が必要だったファイル数

7割のファイルで文字コードの指定が要りました。 これは「たまに起きる」ではなく、新しくスクリプトを足すたびに必要という意味です。テンプレート化しておかないと、必ず忘れます。

macOS・Linux との違い（移す前に）

移行を検討する前に、何が違うのかを整理します。

移行コストの実体は、この表の左列に合わせて書いたコードの量です。 当メディアの場合は msvcrt 3箇所と .cmd 5本、合計8箇所でした。

「Windows と WSL のどちらが優れているか」ではなく、「上の項目に当てはまる箇所が自分のコードに何箇所あるか」で決めてください。 数えれば、移すかどうかは自動的に決まります。

詰まったときの調べ方（症状別）

原因の切り分け順を書きます。上から順に潰すと早いです。

3行目が一番見つけにくいです。 エラーが出ないため、モデルの問題に見えます。指示を短くして再現しなくなったら、届いていなかったと判断できます。

再現確認のコツ

「同じことをもう一度頼む」では切り分けになりません。 生成AIなので毎回同じ結果になりません。

4行目を忘れると、直したはずのものが直っていないように見えます。 文脈が長いと、前の指示を引きずるためです。

この記事の数字の出どころ

出せない数字は出しません。 当メディアが持っていないのは次です。

この記事は「Windows でも運用できる」を示すものであって、「Windows が優れている」を示すものではありません。 上の表に当てはまる箇所を自分のコードで数えて判断してください。

Windowsのままでよいか、WSLに移すか

次の3つのいずれかに当てはまるなら、Windowsのままのほうが安く済みます。

• ファイルロックにOS固有のAPIを使っている
• .cmd や .bat のラッパーからジョブを起動している
• Windows側のGUIアプリや、ドライブ同期フォルダのファイルを触る

当メディアは3つすべてに当てはまるのでWindowsのままです。逆に、どれにも当てはまらず、扱うのがコードとAPIだけなら、WSLのほうが躓きは少なくなります。

移行の判断は「WindowsとWSLのどちらが優れているか」ではなく、上の3つに当てはまる箇所が自分のコードに何箇所あるかで決めてください。当メディアの場合は msvcrt 3箇所と .cmd 5本、合計8箇所でした。この数が判断材料になります。

環境が通ったあと何から覚えるかは、Claude Code の使い方に31日間の実測から書いています。

---

訂正履歴

• 2026-09-30：料金の表を税抜の金額（Pro $20・Max $100 から・Team スタンダード $25）へ直しました。前版の $22・$110・$27.50 は、公式ページをブラウザで開いたときに出ることがある税込表示（10%込み）の金額で、値上げではありません。同日に公式ページを再取得し、静的に取得した本文が税抜、当メディアの環境で開いたブラウザの表示が税込であることを確認しています