Qt Creator 20 MCP サーバーのデバッグ機能
（掲載 2026年7月13日）
Qt Creator 20 で拡張された MCP サーバーのデバッグ機能を、外部の AI エージェントから操作して検証しました。
前回 は Qt Creator MCP サーバーを使い、QtCreator 上のビルドエラーを取得して修正する流れを確認しました。
今回は一歩進めて、Qt Creator のデバッガーを MCP 経由で起動し、ブレークポイントで停止し、コールスタックやローカル変数、式評価の結果を AI エージェント側から参照できるかを確認しました。
Qt Creator 20 では、MCP サーバーの設定ページが Preferences > AI > QtCreator MCP Server に用意され、MCP 関連のツールも拡張されています。ポート番号が 3001 ではなく、自動的に空いているポートが選ばれるのがデフォルトになっているので、注意が必要です。ポート番号を 3001 に設定すれば、今まで通りのポートで接続できますが、複数の Qt Creator を同時に起動している場合などは、空いているポートを自動的に選ぶ設定のほうが便利だと思います。
今回の検証では、Qt Creator 20.0.0 を起動し、MCP サーバーを有効にした状態で、CMake ベースの小さな C++ プロジェクトをデバッグ対象にしました。対象プログラムには、平均値を計算する関数に意図的な境界条件のバグを入れています。
デモ用コードでは、80, 90, 100, 70, 60 という 5 つの点数の平均を計算します。本来の平均は 80.0 ですが、ループ条件を誤って最後の要素を処理しないようにしていたため、実行結果は 68.0 になりました。今回のサンプルは小さく、バグも単純なため、AI がソースコードを直接読んでも見つけられる内容です。そのため、このサンプルは「AI が Qt Creator を使わないと見つけられないバグ」を示すものではありません。主目的は、Qt Creator のデバッグ状態を MCP 経由で取得し、ブレークポイント停止、変数確認、式評価、ステップ実行といったデバッガー操作を AI エージェントから行えるかを確認する動作検証です。
実際の操作では、まず Qt Creator 側でプロジェクトを開き、キットを選択して CMake の構成を完了しました。その後、AI エージェントから MCP 経由でプロジェクト情報、ビルド構成、実行構成を確認し、デバッグセッションを開始しました。さらに C++ の加算処理の行にブレークポイントを設定し、そこでプログラムを停止させました。
ブレークポイントで停止した状態では、MCP 経由で現在位置を取得できました。停止位置は averageScore() 関数内で、Qt Creator のデバッガーが停止している行、関数名、ファイル名を AI エージェント側から確認できました。また、コールスタックを取得すると、averageScore() が main() から呼ばれていることも分かりました。
ローカル変数としては、ループ変数 i、点数を保持する scores、合計値 total が取得でき、最初の停止時点では i が 0、total が 0 であることを確認できました。
さらに、式評価も MCP 経由で実行できました。scores.size() を評価すると 5、scores[i] を評価すると 80、scores[4] を評価すると 60 が返りました。ここでステップオーバーを実行すると、total が 0 から 80 に変化することも確認できました。これにより、加算処理そのものは動作している一方で、最後の要素である scores[4] がループで処理されていないことを実行時の値から追跡できました。
原因は、ループ条件が i + 1 < scores.size() になっていたことです。
scores.size() が 5 の場合、この条件では i が 0, 1, 2, 3 のときだけ処理が行われ、i が 4 の最後の要素は処理されません。正しくは i < scores.size() とする必要があります。この例では静的に読んでも分かるバグですが、MCP 経由でブレークポイント停止、変数確認、式評価、ステップ実行を組み合わせることで、通常のデバッグ作業と同じ流れを AI エージェントから実行できることを確認できました。
AI が Qt Creator を用いてデバッグする意味があるのは、ソースコードを読むだけでは実行時の事実が足りない対象です。たとえば、キットやビルド構成によって挙動が変わる問題、実行構成の作業ディレクトリや環境変数に依存する問題、設定ファイルや前回実行時の状態によって値が変わる問題などでは、実際に Qt Creator が使っている構成で止めて確認することに意味があります。
Qt アプリケーションでは、シグナル・スロット、タイマー、イベントループ、QML と C++ の境界など、ソースコード上の順序と実際の実行順序が一致しない場面もあります。このような場合は、ブレークポイントで停止し、コールスタックやローカル変数を確認することで、どの経路から呼ばれ、どの値になっていたかを AI エージェントが把握できます。テスト失敗時の途中状態の確認、クラッシュやアサーションの原因追跡、大きなコードベースで実際に通った呼び出し経路を絞り込む調査も、Qt Creator 経由のデバッグが有効な対象です。
このような場面では、AI エージェントが単にソースコードを読むだけでなく、Qt Creator が実際に使っているキット、ビルドディレクトリ、実行構成、ブレークポイント、コールスタック、ローカル変数を確認できることに意味があります。人が Qt Creator 上で行っているデバッグ操作の一部を、AI エージェントが外部から実行し、観察結果をもとに原因を絞り込めるためです。
今回の検証で、Qt Creator 20 の MCP サーバーから、デバッグセッションの起動と停止、実行中プロセスの一時停止と再開、ブレークポイント停止、コールスタック取得、ローカル変数取得、式評価、ステップ実行ができることを確認しました。
前回確認したビルドエラー取得と組み合わせると、AI エージェントが Qt Creator 上のプロジェクトをビルドし、エラーを確認し、必要に応じてデバッガーで実行時状態を見ながら原因を調査する流れが見えてきます。
Qt Creator MCP サーバーは、Qt Creator と外部 AI エージェントをつなぐ機能として、ビルド支援だけでなくデバッグ支援にも広がり始めています。まだキット選択や一部の UI 操作など、人が Qt Creator 側で行う必要のある場面はありますが、Qt を使った開発作業の中で、AI エージェントが実行時の情報を扱えるようになることは、今後の開発支援を考えるうえで重要な前進だと思います。
Qt Creator 20 Beta released
MCPクライアントを使う