Claude CodeのAlt+V画像貼り付けが遅い理由 — Windowsで約2秒かかる仕組み
WindowsのClaude Codeで、Alt+Vの画像貼り付けに約2秒かかる原因はPowerShell 5.1を2回起動する実装と報告されています。計測値と、待たずに済ませる手段を並べます。
WindowsのClaude Codeで Alt+V を押してから [Image #1] が出るまで約2秒かかるのは、貼り付けのたびにWindows PowerShell 5.1が2回起動するためだと、GitHubのissue #101444で報告されています。画像の処理そのものはほとんど時間を使っていません。時間の大半は、PowerShellの起動と.NET Frameworkの読み込みです。
このissueはバグとして起票され、openのままです。コメントは付いていません。ここでは、報告された計測値、遅さの内訳、似た症状との切り分け、待たずに済ませる手段を順に書きます。
Alt+Vの約2秒は何に使われているのか
報告者の環境はWindows 11、Windows Terminal、PowerShell 7、Claude Code 2.1.296です。クリップボードには544×680の画像を入れて計測しています。
報告された計測値(1台のWindows 11での測定)
PowerShell 5.1の空起動
約155 ms
powershell -NoProfile -Command "exit 0"
画像の有無を調べる処理
約210 ms
checkImageコマンド
画像を保存する処理
約1,860 ms
saveImageコマンド
常駐した1プロセス内で同じ処理
約130 ms
Add-Type + GetImage + Save
数字の読み方は次のとおりです。
- 保存処理の約1,860 msが体感の「約2秒」のほぼ全部を占めます
- 同じ処理を、すでに起動済みのpwshプロセスの中で実行すると約130 msで終わります
- 差の約1.7秒は、画像のエンコードではなく、新しいPowerShellを立ち上げて.NETを読み込む分だと報告者は見ています
これは1台のマシンでの1回の計測です。CPUやディスク、ウイルス対策ソフトの有無で、起動コストは変わります。自分の環境の目安を知りたいなら、PowerShellで次を実行してください。issueと同じ空起動の計測です。
Measure-Command { powershell -NoProfile -Command "exit 0" }TotalMilliseconds が数百ミリ秒を超えるなら、2回の起動が積み上がる分、貼り付けは2秒より遅くなりえます。この計測は貼り付け処理そのものの再現ではなく、PowerShell 5.1の起動コストの目安です。
PowerShell 7を入れている環境では、同じ形で pwsh の空起動も測れます。2つの TotalMilliseconds を並べると、5.1の起動がどれだけ重いかが自分のマシンで分かります。
Measure-Command { pwsh -NoProfile -Command "exit 0" }数値は1回ごとにぶれるので、何度か測って見比べてください。pwshのほうが速くても、Alt+Vが呼ぶのは5.1なので、貼り付けの待ち時間は縮みません。
2回起動する流れ
issueによると、Alt+Vを押すと次の順にPowerShellが呼ばれます。
Alt+V1回で起きること(報告された実装)
- 1
1回目の起動:画像があるか確認
Clipboard::ContainsImage()でクリップボードに画像があるかを調べます。 - 2
2回目の起動:画像を取り出して保存
もう一度
powershellを起動し、Clipboard::GetImage()で取得して.Save(..., Png)でPNGに書き出します。ここが約1.9秒です。 - 3
チップの挿入
保存できたら、入力欄に
[Image #1]が挿入されます。
呼び出されるのはPowerShell 7(pwsh)ではなく、Windowsに標準で入っているWindows PowerShell 5.1です。ターミナルでPowerShell 7を使っていても、この処理には関係しません。issue上の環境がPowerShell 7でも約2秒かかっているのは、そのためです。
報告者が挙げる改善案は2つあります。
OpenClipboardとGetClipboardDataでクリップボードをネイティブに読み、登録済みのPNG形式を取る。ブラウザーやSnipping ToolはPNGのバイト列をそのまま載せるので、再エンコードが要らない。形式が無ければCF_DIBV5やCF_DIBに落とす- 少なくとも起動を1回にする。
GetImage()が$nullを返せば画像が無いと分かるので、最初の確認は省ける
どちらもissue上の提案で、採用が決まったわけではありません。
「遅い」と「失敗する」を切り分ける
Alt+V周りの不具合報告は、症状が似ていても別の問題が混ざっています。次の表で、自分の症状がどれに近いかを確かめてください。
| 症状 | 近い報告 | 状態 |
|---|---|---|
| 貼れるが2秒前後かかる | 近い報告#101444(v2.1.296) | 状態open |
| 貼れるが5秒前後かかる | 近い報告#15625(v2.0.76) | 状態2026-02-14にnot plannedでclose |
| 起動直後やアイドル後の1回目だけ失敗し、すぐ押し直すと通る | 近い報告#78395(v2.1.212) | 状態2026-09-03にnot plannedでclose |
CLAUDE_CODE_USE_POWERSHELL_TOOL=1 のとき失敗する | 近い報告#83350 | 状態2026-10-02にnot plannedでclose |
| WSL2で「No image found in clipboard」と出る | 近い報告別の原因 | 状態WSL2の記事を参照 |
#101444は、#15625が同じ遅延を報告してcloseされていたことにも触れています。#78395と#83350はPowerShell経由のクリップボード処理が絡む点が共通ですが、症状は「遅い」ではなく「失敗する」です。
遅いだけで最終的に貼れているなら、このissueと同じ系統です。1回目だけ失敗するなら遅延の話ではありません。
「遅い」ではなく「失敗する」報告の再現条件
#78395は、ネイティブWindows(Windows Terminal、Git Bash)で、Claude Codeを起動した直後か、長く放置したあとの最初のAlt+Vで「no image found」系のメッセージが出て、何も添付されない報告です。クリップボードをそのままにして2回目を押すと [Image #N] が入ります。その後しばらくは1回目から通り、また長く放置すると同じことが起きます。報告者は、この動きから初期化かタイミングの問題を疑っていますが、仮説と断っています。待ち時間の長さではなく、押した回数で結果が変わるなら、こちらに当たります。
#83350は、環境変数 CLAUDE_CODE_USE_POWERSHELL_TOOL=1 を設定すると、有効な画像がクリップボードにあってもAlt+Vが「no image found」になる報告です。変数を外してClaude Codeを再起動すると貼れるようになります。#78395とは違い、押し直しても通らず、失敗が続きます。テキストの貼り付けは影響を受けません。報告時のバージョンは2.1.220です。
#15625は、v2.0.76のWindows TerminalとWarpで、37.5 KBほどの小さなスクリーンショットでもAlt+Vに約5秒かかった報告です。ドラッグ&ドロップは即時で、テキストの貼り付けにも遅れはありません。画像が小さくても遅いので、#101444と同じく、サイズではなく起動コストを疑う材料になります。
待たずに済ませる方法
公式のドキュメントには、画像を会話に加える方法が3つ載っています。
- Claude Codeのウィンドウへのドラッグ&ドロップ
- クリップボードからの貼り付け(Windowsでは
Alt+V) - 画像のパスを文章で渡す
issueの報告者も、ドラッグ&ドロップは速いと書いています。#15625にも「ドラッグ&ドロップは即時、Alt+Vは約5秒」とあります。保存済みのファイルを使う経路なら、クリップボードを読むPowerShellが要りません。
パスで渡す場合は、次のように頼みます。
Analyze this image: C:\Users\me\Pictures\Screenshots\error.pngスクリーンショットを何枚も貼る作業では、先にフォルダーへ保存しておき、パスをまとめて渡すほうが待ち時間は減ります。貼り付けの待ち時間が気になる場面だけの工夫です。1枚ずつ確認しながら進めるなら、約2秒は許容できる範囲かもしれません。
キーを変えても速くはならない
キーバインドの一覧には chat:imagePaste があり、既定は Ctrl+V(WindowsとWSLでは Alt+V)です。割り当てを別のキーに変えられますが、変わるのは押すキーだけです。内部でPowerShellを呼ぶ処理は同じなので、遅さは変わらない可能性が高いです。ドキュメントには、この点の記載がありません。
changelogに残る関連項目
画像貼り付けに関するchangelogの項目は、遅延とは別の方向の修正です。2.1.232には「貼り付けた画像やクリップボードの画像を、イベントループをブロックせずに読む」という項目があります。2.1.296の報告より前の変更なので、約2秒の待ちはこの修正の後も残っていることになります。非同期に読むようになっても、読む先のPowerShell 5.1の起動が速くなるわけではありません。
WSL向けには、xclipやwl-pasteが画像を読めないときにPowerShellへフォールバックする項目があります。この項目はWSL2での貼り付け失敗を扱うもので、Windowsネイティブの遅延とは別の話です。
修正はいつ入るのか
状況は次の3点です。
- #101444はopenで、Anthropic側のコメントはありません
- 同じ遅延を報告した#15625はnot plannedでcloseされています
- 報告時点のバージョンは2.1.296です。changelogで2.1.296より新しい2.1.310までの項目には、Alt+Vの速度やPowerShell呼び出しの変更に触れたものがありません
直るまで待つか、ドラッグ&ドロップとパス渡しに寄せるかは、貼る頻度しだいです。直ったかどうかは、更新後に先ほどの計測と実際のAlt+Vを比べれば確かめられます。ターミナルの種類を変えても、PowerShellを起動する経路は同じなので、体感はあまり変わらないはずです。
WSL2で動かしていて「No image found in clipboard」と出るなら、遅さとは別の原因です。WSL2の画像貼り付けの記事で切り分けられます。macOSのTerminal.appで貼り付けが途中で止まる場合は、Option+-の中断が関係します。
まとめ
Alt+Vの約2秒は、画像が重いからではありません。貼り付けのたびにWindows PowerShell 5.1を2回立ち上げる設計が原因と報告されています。
貼る回数が多い作業ではドラッグ&ドロップに寄せるのが手堅い選択です。更新のたびにPowerShell 5.1の空起動とAlt+Vの体感を測り直せば、修正が入ったかどうかが分かります。