Qt Creator MCP Server のデバッグ機能
（掲載 2026年5月）
まえがき
Qt Creator 20 では MCP Server の機能が拡張され、外部の AI エージェントから Qt Creator の状態を取得したり、ビルドやデバッグなどの操作を実行したりできる範囲が広がっています。今回は、Qt Creator のデバッガーを MCP 経由で操作し、ブレークポイント停止、コールスタック取得、ローカル変数の確認、式評価、ステップ実行ができるかを確認しました。
前回は Qt Creator MCP Server を使い、Qt Creator 上のビルドエラーを AI エージェントから取得して修正する流れを確認しました。今回は一歩進めて、ビルド後のプログラムをデバッガーで実行し、実行時の状態を AI エージェント側から観察できるかを確認します。
Qt Creator 20 の MCP Server
Qt Creator 20 では、MCP Server の設定ページが Preferences > AI > Qt Creator MCP Server に用意されています。MCP サーバーを有効にすると、外部の MCP クライアントから Qt Creator のプロジェクト情報やビルド構成、実行構成などを取得できます。
今回確認した環境では、MCP サーバーのポート番号は自動的に空いているポートを選ぶ設定が標準になっていました。固定したい場合は、従来と同じように 3001 などのポート番号を指定できます。複数の Qt Creator を同時に起動する場合は自動選択が便利ですが、外部ツール側で接続先を固定している場合は設定の確認が必要です。
Qt Creator 20 では、デバッグ関連の 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 経由でプロジェクト情報、ビルド構成、実行構成を確認し、デバッグセッションを開始しました。
デモコードの平均値計算部分は次のような形です。
double averageScore(const std::vector<int> &scores)
{
int total = 0;
for (std::size_t i = 0; i + 1 < scores.size(); ++i) {
total += scores[i];
}
return static_cast<double>(total) / static_cast<double>(scores.size());
}
ループ条件が i + 1 < scores.size() になっているため、scores.size() が 5 の場合には i が 0, 1, 2, 3 のときだけ処理され、i が 4 の最後の要素は処理されません。この加算処理の行にブレークポイントを設定し、Qt Creator のデバッガーで停止させました。
ブレークポイントと実行時状態の確認
ブレークポイントで停止した状態では、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 < scores.size() とする必要があります。
AI が Qt Creator を用いてデバッグする意味がある対象
今回のサンプルは動作検証用の小さな例でしたが、AI が Qt Creator を用いてデバッグする意味が出るのは、ソースコードを読むだけでは実行時の事実が足りない場面です。
たとえば、キットやビルド構成によって挙動が変わる問題、実行構成の作業ディレクトリや環境変数に依存する問題、設定ファイルや前回実行時の状態によって値が変わる問題では、Qt Creator が実際に使っている構成で止めて確認することに意味があります。
Qt アプリケーションでは、シグナル・スロット、タイマー、イベントループ、QML と C++ の境界など、ソースコード上の順序と実際の実行順序が一致しない場面もあります。このような場合は、ブレークポイントで停止し、コールスタックやローカル変数を確認することで、どの経路から呼ばれ、どの値になっていたかを AI エージェントが把握できます。
テスト失敗時の途中状態の確認、クラッシュやアサーションの原因追跡、大きなコードベースで実際に通った呼び出し経路を絞り込む調査も、Qt Creator 経由のデバッグが有効な対象です。
検証時の注意点
検証中には、実用上の注意点もいくつか見つかりました。Qt Creator に古い QML や Python のブレークポイントが残っていると、C++ のデバッグ開始時に警告ダイアログが表示され、デバッグ開始を妨げる場合がありました。この場合は、ブレークポイント一覧を取得し、不要なブレークポイントを削除してから実行すると安定しました。
macOS では /tmp と /private/tmp が同じ場所を指しますが、デバッグ情報上のパスとブレークポイント登録時のパスが文字列として一致しないと、ブレークポイントが登録されていてもヒットしない場合がありました。今回も最初は /private/tmp 側のパスでブレークポイントを登録したため停止せず、デバッグ情報に出ていた /tmp 側のパスで登録し直すことで停止できました。
また、非常に短時間で終了するコンソールプログラムでは、AI エージェントがデバッグ状態を取得する前にプロセスが終了してしまいます。デモでは冒頭に短い待機を入れ、実行中に一時停止したり、ブレークポイントまで進めたりできるようにしました。
まとめ
今回の検証で、Qt Creator 20 の MCP サーバーから、デバッグセッションの起動と停止、実行中プロセスの一時停止と再開、ブレークポイント停止、コールスタック取得、ローカル変数取得、式評価、ステップ実行ができることを確認しました。
前回確認したビルドエラー取得と組み合わせると、AI エージェントが Qt Creator 上のプロジェクトをビルドし、エラーを確認し、必要に応じてデバッガーで実行時状態を見ながら原因を調査する流れが見えてきます。
Qt Creator MCP サーバーは、Qt Creator と外部 AI エージェントをつなぐ機能として、ビルド支援だけでなくデバッグ支援にも広がり始めています。まだキット選択や一部の UI 操作など、人が Qt Creator 側で行う必要のある場面はありますが、Qt を使った開発作業の中で、AI エージェントが実行時の情報を扱えるようになることは、今後の開発支援を考えるうえで重要な前進だと思います。
参考情報