PyCharmで npm start 実行時にIDEがサイレントクラッシュした事例と切り分け

PyCharmで npm start 実行時にIDEがサイレントクラッシュした事例と切り分け

こんにちは!Qualitegプロダクト開発部です!

PyCharmの内蔵npmツールで npm start を実行した瞬間、何のエラーメッセージもなくIDEが消える。

再起動してもう一度試すとまた落ちる。ログを見ても手がかりがない——。

今回はこの「サイレントクラッシュ」に遭遇し、原因の絞り込みから回避策の確立まで至った過程を書き残しておきます。同じ現象で困っている方の参考になれば幸いです。


環境

項目 内容
OS Windows 10/11
PyCharm 2026.1(2023.1.6時代から連綿とUpdateをした状態)
Python 3.11.4(venv使用)
Node.js v25.2.1
プロジェクト Python + Node.js 混合構成

上記のとおり、PyCharmは執筆時点の最新版(2026.1)となります。

確認できたこと・推測していること

まず最初に、この記事で述べる内容の確度を整理しておきたいとおもいます

確認できたこと

  • npmツール内蔵ターミナル経由でのみクラッシュが再現する(外部ターミナルでは再現しない)
  • ConPTYを無効化すると回避できる
  • idea.log、JVMクラッシュダンプともに有力な痕跡がない
  • インストール先のパスに旧バージョン名(PyCharm 2023.1.6)が残っている
  • conpty.dll が旧バージョンのパスからロードされている

推測していること

  • 上書きアップデートに伴うネイティブコンポーネントの不整合が関与している可能性がある
  • conpty.dll 周辺の互換性問題である可能性が高い
  • 大量のコンソール出力時にだけ顕在化するネイティブ層の異常と考えられる

conpty.dll の新旧バージョンの差分比較やクラッシュダンプの詳細解析までは行っていないため、根本原因については状況証拠に基づく推測となりますが、
切り分けの結果としてConPTY周辺が原因である可能性は非常に高いと判断しています。


症状の詳細

PyCharmのnpmツール内蔵ターミナルで npm start を実行すると、数秒以内にPyCharmのウィンドウが消えます。タスクバーからも消え、プロセスも終了しています。再現率はほぼ100%でした。

特徴的だったのは以下の点です。

  • エラーダイアログが一切表示されない
    JetBrains標準のクラッシュ通知も出ません。ウィンドウが文字通り「消える」だけです。
  • idea.logにクラッシュの痕跡がない
    正常に起動・インデックス完了した後、ログがプツッと途切れています。
  • Pythonスクリプトの実行では問題が起きない
    Run ConfigurationからPythonを実行する分には安定しています。
  • コマンドプロンプトから npm start してもPyCharmは落ちない。
    外部ターミナルを使えば問題なく動作します。

最後の点が最も重要な切り分けポイントとなります。


ログに何も残らないサイレントクラッシュの難しさ

通常、PyCharm(IntelliJ系IDE)がクラッシュすると、idea.log にJavaレベルの例外が記録されるか、JVMクラッシュダンプ(java_error_in_pycharm_*.log)がユーザーのホームディレクトリに生成されます。

今回はそのどちらにも有用な情報がありませんでした。これはJava層ではなく、もっと低いレイヤー——ネイティブコード層でプロセスが異常終了している可能性を示唆しています。JVMがクラッシュダンプを書く暇もなく終了させられている状態です。

ログに何も残らないため、「何を変えたら再現しなくなるか」を1つずつ試す切り分けテストが唯一の手段でした。

ログの場所について補足

なお、PyCharmのログと設定は別々のディレクトリに保存されています。ログは %LOCALAPPDATA%AppData\Local)、設定は %APPDATA%AppData\Roaming)です。ネット上では %APPDATA% としか書かれていないことが多く、Roamingを探して「ない!」となるケースがよくあります。

ログ:  %LOCALAPPDATA%\JetBrains\<バージョン>\log\
設定:  %APPDATA%\JetBrains\<バージョン>\

一番手軽なのは Help → Show Log in Explorer です。2025年以降のバージョンでは Help → Diagnostic Tools → Special Files and Folders で全ディレクトリのフルパスが一覧表示できるので、こちらも便利です。


idea.log から読み取れた手がかり

クラッシュの瞬間は記録されていませんでしたが、idea.logからはいくつかの間接的な手がかりが得られました。

インストールパスと設定パスの不一致

Djb.vmOptionsFile=C:\Users\ml\AppData\Roaming\JetBrains\PyCharm2026.1\pycharm64.exe.vmoptions
Djna.boot.library.path=C:\Program Files\JetBrains\PyCharm 2023.1.6/lib/jna/amd64

設定ファイルのパスセレクタは PyCharm2026.1 なのに、インストール先は PyCharm 2023.1.6 のままです。

これは、長年の上書きアップデートによって環境の一貫性が崩れていることがわかります。ネイティブバイナリが想定通りに更新されていない可能性を疑う材料になりました。

ConPTYのロード元

Loaded bundled ConPTY from C:\Program Files\JetBrains\PyCharm 2023.1.6\lib\pty4j\win\x86-64\conpty.dll

npmツール内蔵ターミナルが使用する conpty.dll が旧バージョンのパスからロードされています。PyCharm 2026.1が想定するバージョンと一致しているかどうかは確認できていませんが、パスの不自然さは気になる点です。

node_modules の大量ファイル登録

NodeModulesDirectoryManager - Contributed {
  allCalculationsDuration: 2263 ms,
  allIncludedFileCount: 45078,
  allRootsWorkspaceModel: 42960,
  ...
}

45,078ファイルがインデックス対象として登録されていました。

最初はこれがクラッシュの原因ではないかと疑いましたが、node_modules をExcludedに設定してもクラッシュは解消しませんでした。(実はexcludedにしても、librootにしてるとインデックスしちゃう事象がありますので、excludedの効能が正直理解しきれていない面もあります)パフォーマンスの問題ではありましたが、クラッシュの直接原因ではなかったようです。

JVMメモリ設定の重複

-Xms256m, -Xmx2048m, ..., -Xmx8192m

-Xmx がうっかり2回指定されていました(後者が有効なので動作上は問題なし)。これ自体はクラッシュの原因ではありませんが、設定ファイルの引き継ぎにも一貫性のなさが見え、環境全体に違和感があることを示していました。


切り分けテストと原因の絞り込み

テスト1: 外部ターミナルから npm start を実行する

PyCharmを開いた状態で、外部のコマンドプロンプトから npm start を実行したところ、PyCharmは落ちませんでした。

これにより、問題が npm start 自体ではなく、PyCharmのnpmツール内蔵ターミナルを経由して実行したときだけ起きることが確認できました。

この1つのテストで、疑わしい範囲が一気に狭まりました。

テスト2: ConPTYを無効化する

次は、PyCharmの内部レジストリ設定で terminal.use.conpty.on.windowsfalse に変更し、npmツール内蔵ターミナルから npm start を実行しました。

結果、クラッシュしなくなりました。

この2つの切り分けから、問題がConPTY周辺にあることはほぼ確実と判断しました。


ConPTYの無効化手順

Settings(設定画面)のTerminalセクションにはConPTYのオン・オフ項目がないため、内部レジストリから変更する必要があります。

  1. Help → Find ActionCtrl+Shift+A)を開く
  2. Registry と入力してEnterを押す
  3. レジストリ画面の検索欄に terminal.use.conpty.on.windows と入力する
  4. 該当項目のチェックボックスをオフにする
  5. PyCharmを再起動する

これでターミナルはConPTYではなく旧方式のWinPTYで動作するようになります。カラー出力の品質が若干落ちる場合がありますが、安定性は大幅に向上します。


なぜConPTYで落ちるのか(推測)

ここからは状況証拠に基づく推測です。裏付けとなるクラッシュダンプの解析やDLLのバージョン比較は行っていないため、その前提で読んでいただければと思います。

ConPTY(Windows Pseudo Console)は、Windows 10 バージョン1809で導入された仮想端末APIで、従来のWinPTYに代わりカラー出力やUnicode対応を改善した仕組みです。VS Code、Windows Terminal、JetBrains系IDEの内蔵ターミナルなどで採用されています。

npm start で起動するNode.jsの開発サーバーは、コンパイルログやHMR通知などを大量かつ高速にコンソールへ出力します。ConPTYはこの出力をPyCharmのJavaプロセスに中継する役割を担っています。

今回の環境では、PyCharm 2026.1が PyCharm 2023.1.6 のフォルダにインストールされており、conpty.dll も旧パスからロードされていました。上書きアップデートではすべてのネイティブバイナリが確実に更新される保証がないため、新しいターミナルエンジンと conpty.dll の間で何らかの不整合が生じ、大量出力時にネイティブ層で異常終了に至っている——というのが現時点での仮説です。

idea.logに記録が残らないのも、この仮説と整合的です。クラッシュがJVMの管理外のネイティブコードで発生している場合、JVMのエラーハンドラ自体が呼ばれず、ログを書く余地がないためです。

より確度の高い原因特定を行うのであれば、Windows Event ViewerでのApplication Errorの確認、ProcMonによるDLLロードのトレース、conpty.dll のファイルバージョン比較などが有効な次のステップになると思います。


複合的な条件で発生する問題

今回の問題は、複数の条件が重なって初めて顕在化するタイプのものでした。

条件 結果
上書きアップデート + ConPTY有効 + npm start(大量出力) クラッシュする
上書きアップデート + ConPTY無効 + npm start 問題なし
上書きアップデート + ConPTY有効 + Pythonスクリプト(少量出力) 問題なし
上書きアップデート + 外部ターミナル + npm start 問題なし

どれか1つの条件を外すだけでクラッシュは回避できます。裏を返すと、再現条件の特定が難しく、「環境によって起きたり起きなかったりする」ように見える厄介な問題でもあります。


再発防止のための対策: クリーンインストール

ConPTYの無効化は1つの回避策ですが、そもそもネイティブコンポーネントの不整合が関与しているのであれば、クリーンインストールで解消される可能性が高いと考えています。

結局それかよって感じですが、やっぱりクリーンインストールするのが一番手っ取り早く効果があられるかもしれません。

  1. PyCharmをアンインストールする
  2. C:\Program Files\JetBrains\PyCharm 2023.1.6\ フォルダが残っていれば手動で削除する
  3. PyCharm 2026.1を新規インストールする

設定ファイルは %APPDATA%\JetBrains\PyCharm2026.1\ に保存されており、アンインストールしても消えないため、再インストール後に自動的に引き継がれます。

また、JetBrains Toolbox Appを使ってインストール・アップデートを管理すると、バージョンごとに独立したディレクトリにインストールされるため、今回のようなパスの不整合が起きにくくなります。


教訓

1. サイレントクラッシュには切り分けテストが最も有効

ログに情報がない場合、ログをいくら睨んでも答えは出ません。「何を変えたら再現しなくなるか」を1つずつ試す切り分けが最も効果的です。今回は「内蔵ターミナルか、外部ターミナルか」という1つの切り分けで原因の範囲を大幅に絞り込めました。

2. Updaterによる上書きアップデートには(案外)リスクがある

JetBrains系IDEに限らず、メジャーバージョンをまたぐ上書きアップデートは予期しない問題を引き起こすことがあります。特にネイティブバイナリが関わる場合、古いファイルが残ることで新旧の不整合が生じる可能性があります。メジャーアップデートの際はクリーンインストールを検討すべきです。

3. 「確認できたこと」と「推測していること」を分ける

これは今回きづいた教訓というか、先輩方に指摘されたことですが、トラブルシューティングの記録を残すとき、切り分けで確認した事実と、状況証拠からの推測を明確に分けておくことが大切です。
事実と推測を混ぜてしまうと、後から振り返ったときに「結局何がわかっていて何がわかっていないのか」が曖昧になってしまいます。

4. テレメトリデータも情報源になる

PyCharmが出力するworkspaceModelのメトリクスからは、ファイルインデックスの規模やメモリ使用状況など、idea.logだけではわからない情報が得られます。今回はこのデータから node_modules の大量ファイル登録を把握できました。結果的にクラッシュの直接原因ではありませんでしたが、パフォーマンス改善のための有益な情報でした。


まとめ

  • PyCharmのnpmツール内蔵ターミナルで npm start を実行するとIDEがクラッシュする問題に遭遇しました。
  • idea.logにもJVMクラッシュダンプにも記録が残らないサイレントクラッシュでした。(ただし、再現性が高かったのでわりと切り分けがしやすくてそこは助かりました)
  • 切り分けの結果、ConPTY周辺が原因である可能性が非常に高いと判断しました。
  • 上書きアップデートによるネイティブコンポーネントの不整合が関与していると推測しています(conpty.dll の新旧差分までは未検証)。
  • レジストリで terminal.use.conpty.on.windows を無効化することで回避できます。
  • 再発防止にはPyCharmのクリーンインストールが有力な対策です。

ログに何も残らない問題のデバッグは心が折れそうになりますが、AIの力もかりつつ地道な切り分けが結局は一番の近道だとおもいます。
同じ現象で困っている方の助けになれば嬉しいです。

それでは、次回またお会いしましょう!

Read more

Claude Opus 5.0 完全ガイド モデル仕様とAPI・Claude Code運用ポイント

Claude Opus 5.0 完全ガイド モデル仕様とAPI・Claude Code運用ポイント

こんにちは! 2026年7月24日、AnthropicからClaude Opus 5がリリースされました。 Opus 4.8(5月28日リリース)からわずか2ヶ月での世代交代です。このあたりのスピード感、加速していますね。 さて、当ブログではClaude Opus 4.7 完全ガイド、Claude Opus 4.8 完全ガイドとOpusの世代を追いかけてきましたが、今回のOpus 5は過去2回の「4.x内のアップデート」とは立て付けが根本的に違います。 何が違うのか。まず、Opus 5は「最上位モデル」ではありません。 Anthropicのラインナップには2026年6月9日リリースのClaude Fable 5が最上位として存在し、Opus 5はその下位、Sonnet 5の上位という「中上位」ポジションで投入されました。 Opusという名前が「最上位ティア」を意味した時代は、Fable 5の登場で終わっています。 そのうえでAnthropicはOpus 5を「

By Qualiteg プロダクト開発部
TensorRT 10 × Blackwell 移行ガイド【前編】RTX 50 で推論資産が動かない — 基本と最初の壁

TensorRT 10 × Blackwell 移行ガイド【前編】RTX 50 で推論資産が動かない — 基本と最初の壁

こんにちは! 新しい GPU を手に入れてワクワクしながら既存の推論環境を載せ替えたら、 昨日まで普通に動いていたものが軒並みエラーで止まった そんな経験はないでしょうか。NVIDIA RTX 50 系、NVIDIA RTX PRO 系(Blackwell 世代)への移行では、これがかなりの高確率で起きます。 そして厄介なことに、エラーで止まってくれるのは、まだ親切なほうで、、TensorRT の世界には 「ビルドは通る、実行も通る、速度もちゃんと出る、けれど出力だけが静かに壊れている」 という、いちばん見つけにくい失敗の仕方が存在します。 本記事はその全体像を扱うシリーズの前編です。 対象環境 OS: Ubuntu 24.04 (WLS) GPU: NVIDIA RTX PRO 4000 Blackwell・GeForce RTX 5060 Ti (ともに Compute Capability 12.

By Qualiteg プロダクト開発部
Kimi K3 徹底リサーチ — 2.8兆パラメータ、「史上最大のオープンウェイト」は実現するか

Kimi K3 徹底リサーチ — 2.8兆パラメータ、「史上最大のオープンウェイト」は実現するか

こんにちは! 2026年7月16日、中国・北京の Moonshot AI が新しいフラッグシップモデル Kimi K3 を発表し、APIやWebサービスでの提供を開始しました。 総パラメータ2.8兆という規模、100万トークンのコンテキスト、そして 「史上最大のオープンウェイトモデルになる」 という宣言がAI界隈をにぎわせています。 当ブログでは今年5月の記事「Mythos(ミュトス)レベルのオープンモデルはいつ出るのか」で、オープンモデルがクローズドのフロンティアにいつ追いつくのかを予測しました。 Kimi K3 は、まさにその問いに対する現時点での最新の「回答」のひとつです。 一方で、この記事を書いている7月20日時点では、モデルのウェイトも技術レポートもまだ公開されていません。 ただし、XなどSNSかいわいでは、 「ガードレールが弱めで、Fable5では拒否されるようなプロンプトでも対応してくれる」 「すぐにOpus4.8にフォールバックする Fable5より使い勝手がいい」 といった声が散見されており、 米国産のガードレール強め方針にたいして、ガードレール

By Qualiteg プロダクト開発部
PII 非識別化の本質——「誰か」は偽ってよい、「何が起きたか」は偽ってはならない

PII 非識別化の本質——「誰か」は偽ってよい、「何が起きたか」は偽ってはならない

こんにちは!Qualitegプロダクト開発部です! 本日は、PII( Personally Identifiable Information→個人情報)の非識別化に関する内容を解説いたします。 当社ではこれまで、高精度なPII検出技術やLLM利用時の段階的PIIマスキング、PII検出のテスト設計など、個人情報検出とAIセキュリティに関する技術解説をお届けしてきました。 現在、当社では、PII検出マスキング技術「PII-FIエンジン」と、それを活用したPIIのマスキング・非識別化サービス「PII-FI Scan」「PII-FI API」を開発・提供しています。 本記事では、「PIIを検出したあと、それをどう書き換えるか」の設計原則を、1つの例文を試金石にして、私たちが実際のプロダクトで採用している整理をご紹介します。 先にことわっておきますと、本記事でいう「非識別化(de-identification)」は、文書やログを安全に共有・分析するための技術的な加工(個人を特定できないように加工する処理)のお話です。 個人情報保護法上の「仮名加工情報」「匿名加工情報」に該当することを

By Qualiteg プロダクト開発部, Qualiteg AIセキュリティチーム