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

日本語対応 LLMランキング2026 ~ベンチマーク分析レポート~(7月10日版)

日本語対応 LLMランキング2026 ~ベンチマーク分析レポート~(7月10日版)

はじめに 本レポートは、Nejumi Leaderboard 4のベンチマークデータ(2026/7/10版)に基づいて、日本語対応LLMの性能を総合的に分析したものです。 前回は 2026/3/6 版の分析レポート を公開しましたが、 約4か月ぶりとなる今回も、上位勢の顔ぶれが大きく入れ替わる激動の回となりました! (定期的に最新LLMランキングを更新してまいります。当社のX(旧Twitter)をフォローいただくことで更新情報を受け取り可能です) Nejumi Leaderboard 4は、日本語タスクにおけるLLMの性能を多角的に評価する信頼性の高いベンチマークとして知られています。汎用的言語性能(GLP)とアラインメント(ALT)の2軸で構成され、翻訳・要約・推論・コーディングから毒性・バイアス・真実性まで、幅広い観点をカバーしているのが特徴です。 本分析では、商用APIモデルとオープンモデルの両方を対象に、それぞれの特徴や傾向を詳しく見ていきます。まず、今回の3大トピックを先にご紹介します。 * Claude Opus 4.8がリーダーボード史上初の総合スコア0.8

By Qualiteg プロダクト開発部
Claude Fable5 完全ガイド — 公式ドキュメントから読み解くモデル仕様とClaude Code運用ポイント

Claude Fable5 完全ガイド — 公式ドキュメントから読み解くモデル仕様とClaude Code運用ポイント

こんにちは! 2026年6月に登場した Claude Fable 5 は、公開直後の輸出規制による一時停止、グローバル再展開、そしてサブスクリプション枠からの離脱と、わずか1か月でめまぐるしい動きを見せています。 当ブログでもその時々の状況を追ってきました。 まず全体像は ついに一般公開、Claude Mythos 5 / Fable 5 を実務視点で読み解く で、公開直後の停止騒動は 公開から3日で停止──Fable 5/Mythos 5 をめぐる米政府指令が示した、AI の新しい可用性リスク で、料金と今後の見通しは Claude Fable 5 はこれからどうなる? 経緯・コスト・今後の見通し で扱っています。 本記事は、それらを踏まえた「実務で使うための決定版ガイド」です。 とくに 2026年7月12日(日本時間7月13日)を境にサブスクリプション枠から外れ、使用クレジットを有効化しないと使えなくなる (この期限は当初2026年7月7日とされていましたが、のちに5日間延長されて7月12日になりました。

By Qualiteg プロダクト開発部
AI時代のデータ漏洩防止の要諦とテクノロジー:第2回 従来型DLPを超えて、AI-DLPが解決すべき本質的課題

AI時代のデータ漏洩防止の要諦とテクノロジー:第2回 従来型DLPを超えて、AI-DLPが解決すべき本質的課題

こんにちは! 前回の記事では、AI時代のデータ漏洩防止における技術的な基礎として、HTTPSインターセプトの仕組みと限界について詳しく解説しました。プロキシサーバーによるSSL/TLS通信の復号化、中間CA証明書の運用、そして証明書ピンニングという技術的制約まで、企業がWeb通信を監視する際の技術的な現実を明らかにしました。 しかし、これらのプロキシ技術は、実は既存のDLP製品でも広く採用されている一般的な手法です。メール監視、ファイル転送の制御、Webアクセスの監査など、従来型のデータ漏洩防止においても、HTTPSインターセプトは中核的な役割を果たしてきました。 では、なぜAI時代において新たにDLPを考え直す必要があるのでしょうか。 前回にひきつづき、従来型DLPでは対応できないAI固有の課題と、AI-DLPとして新たに考慮すべき要素に焦点を当て、より本質的な議論を展開していきます。 1. AI時代が要求する新たなDLP要件 従来のDLP製品は、クレジットカード番号や社会保障番号といった定型的なパターンの検出において優れた実績を持っています。これらの技術は今後も重要な

By Qualiteg プロダクト開発部, Qualiteg コンサルティング
Claude Fable 5はこれからどうなる? 経緯・コスト・今後の見通しをファクトベースで整理する

Claude Fable 5はこれからどうなる? 経緯・コスト・今後の見通しをファクトベースで整理する

こんにちは! 2026年7月2日(日本時間)、日本からもClaude Fable 5が再び利用できるようになりました。 2026年6月に大きな注目を集めて登場し、わずか3日で米政府の指令により停止、そして7月1日(米国時間)に復活したAnthropicの最上位モデル「Claude Fable 5」。 復活と同時に 「サブスクで使えるのは7月7日まで」 という条件が付いたことで、利用者の間ではコストへの懸念の声も見られます。 本記事では、憶測と事実を切り分けながら、 (1)これまでの経緯、 (2)確定している料金体系、 (3)実際のコスト試算、 (4)今後の見通し、 の4点を整理します。確定情報(ファクト)と筆者の推測は明確に区別して書きます。 ※本記事の日付は、特記のない限りAnthropicの発表に基づく米国時間を基準としています。 なお当ブログでは、Fable 5 / Mythos 5についてリリース直後の技術解説、米政府指令による停止が示した可用性リスクの考察、Fable 5の安全分類器がClaude Code上で実際にどう振る舞ったかの体験記を公開してきました。

By Qualiteg コンサルティング