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

一文の依頼で、調査から資料作成まで。AIエージェント「Bestllam」のデモ動画を公開しました

一文の依頼で、調査から資料作成まで。AIエージェント「Bestllam」のデモ動画を公開しました

こんにちは! 本日は当社の統合AIプラットフォーム "Bestllam®" の AIエージェント機能のデモをご紹介いたします! 「指示は出せても、AIが本当に仕事を仕上げてくれるのか」 生成AIを業務に取り入れる企業が増えています。 しかし現場からは、こんな本音も聞こえてきます。 「使い方を覚えるより、自分でやったほうが早い」 「指示を細かく出し直しているうちに、結局時間がかかる」 「便利なのは分かるが、機密情報を入力していいのか不安」 AIを"個人の便利ツール"の域から、"部門の成果"へと引き上げる。 これが当社の法人向け統合AIプラットフォーム Bestllam(ベストラム) が掲げるテーマです。 今回、そのAIエージェント機能を実際の操作画面とともに紹介する動画を公開しました。 たった一文の依頼が、7枚のレポートになるまで 動画のデモはシンプルです。エージェントに、こう入力します。 「先月の売上を年代別に分析し、資料にまとめてください」 これだけです。すると、エージェントはまず自分でTODOリストを組み立て、何をどの順番で進めるかという段取りを示します

By Qualiteg ビジネス開発本部 | マーケティング部
NCCL error: unhandled cuda error が出たら ─ WSL2 + マルチGPU + vLLM で詰まった話

NCCL error: unhandled cuda error が出たら ─ WSL2 + マルチGPU + vLLM で詰まった話

こんにちは! Qualitegプロダクト開発部です! 今日は、Windows + WSL2 のマシンに RTX 4090 を2枚挿して、大規模なオープンモデルを vLLM で動かそうとしたら、NCCL の初期化で見事に詰まった話を書きます。 世の中に断片的にしか情報がなく、抜けるまでにかなり粘ったので、同じ構成で消耗している方の時間を少しでも節約できれば嬉しいです。 経緯 今回の目的は、次々と登場する最新のオープンモデル(オープンウェイトのLLM)を、手元で評価することでした。 オープンモデルは数週間単位で新しいものが出てきます。ベンチマークの数字だけでなく、自分たちのユースケースに対して実際にどう振る舞うのか——出力の質、速度、量子化したときの劣化具合、エージェント的なタスクの得手不得手——を、手を動かして確かめています 今回の環境は Windows + WSL2(Ubuntu) に RTX 4090 を2枚(各24GB)挿したマシンです。 nvidia-smi 上の CUDA Version は 12.8。 動かすのは大規模オープンモデルを

By Qualiteg プロダクト開発部
Claude Codeで「The model's tool call could not be parsed」が頻発する問題の原因分析と対策

Claude Codeで「The model's tool call could not be parsed」が頻発する問題の原因分析と対策

こんにちは!Qualitegプロダクト開発部です。 Claude Code(CLI)を使った開発中に、次のようなエラーが繰り返し表示されて作業が止まる現象に遭遇しました。 ● The model's tool call could not be parsed (retry also failed). リトライしても直らず、/clear で会話をリセットしても、しばらく作業を続けるとまた同じエラーが出るという状況です。本記事では、実際のセッションログ(jsonl)を解析して特定した原因と、その対策について共有します。 結論から書くと、これは利用者側の設定ミスやコンテキスト枯渇が原因ではなく、 Opus 4.7(1Mコンテキスト)+ extended thinking の組み合わせで発生する、モデル応答側のストリーミングバグ でした。 現象 エラーが発生した環境は以下のとおりです。 * Claude Code 2.1.148 * モデル: Opus 4.

By Qualiteg プロダクト開発部
Mythos(ミュトス)レベルのオープンモデルはいつ出るのか

Mythos(ミュトス)レベルのオープンモデルはいつ出るのか

こんにちは! 本日は、ここ最近のAI業界で一番ざわついている話題、「Claude Mythos(ミュトス)」とその周辺について書きます。 発表から1ヶ月半が経って、ホワイトハウスの反対、日本のメガバンクの動き、AISIの追加評価、Anthropicの方針転換と、状況がかなり動いてきました。ここで一度、「で、結局オープンソースで同じものが使えるようになるのはいつなの?」という素朴な問いに、数字で答えてみます。 2026年4月7日、AnthropicはClaude Mythos Previewを発表しました。 サイバーセキュリティ能力で人類トップ層に到達したとされる、フロンティアモデルです。 Anthropicは"gated research preview"として、Project Glasswingのローンチパートナー(AWS、Apple、Cisco、CrowdStrike、Google、JPMorganChase、Microsoft、NVIDIAなど)に加え、重要ソフトウェアインフラを担う40超の追加組織に限定して提供しており、一般公開はしていません(Anthropic公式)

By Qualiteg 研究部, Qualiteg コンサルティング