Coco MCP
未テストの箇所を可視化
AI コーディングエージェントは、どのエンジニアよりも速くテストを生成できます。しかし問題は、テストスイートが既にどこをカバーしているかをエージェントが把握していないことです。Coco MCP Server は、あらゆる AI エージェントを、計測済みビルドから得られる実行時のカバレッジデータに接続します。エージェントは、どのステートメント・分岐・条件が実行されたかを照会し、実行されていない部分に対してテストを作成し、その結果を検証します。
テストは十分か。それとも、抜けが見えていないだけか。
AI によってテストが書かれる速度は変わりましたが、そのテストが実際に何をカバーしているかを把握できるかどうかは変わっていません。そのギャップは、リリース時、監査時、あるいはインシデント発生後に表面化します。
リリースまでのコストを削減
カバレッジ目標の最後の詰めは、地道な繰り返し作業です。それが計測・自動化されれば、シニアエンジニアはその時間を、コードを書くことではなく、レビューに使えるようになります。
リリース判断を、憶測ではなく事実に
実際のテスト実行から得られたカバレッジの数値と、正確に特定された未カバー箇所があれば、リリース判断の場での「憶測」を「根拠」に置き換えられます。
変更ごとのリグレッションにかかる時間を短縮
ある変更がどのテストに影響するかを正確に把握できれば、コミットごとに数千件ではなく数十件のテストを再実行するだけで済みます。
MCP は、AI エージェントがツールと対話する手段
Coco MCP サーバーは、エージェントがカバレッジデータと対話する手段
エージェントはコードベースのすべての行を読めても、テスト実行時にどの部分が実際に実行されたかは分かりません。
それを記録できるのは、Coco で計測されたビルドだけです。
MCP の役割
Model Context Protocol（MCP）は、AI コーディングエージェントを外部のツールやデータソースに接続するための標準インターフェースです。VS Code 上の GitHub Copilot や Claude Code などのエージェントは、MCP ホストとして動作します。サーバーはエージェントが呼び出せるツールを公開し、いつ呼び出すか、何を問い合わせるか、その結果をどう扱うかはエージェントが判断します。
これがない場合、カバレッジの数値を AI エージェントに提示するのは手作業です。レポートを出力し、結果をコピーし、チャットに貼り付け、読み間違いがないことを願うしかありません。その結果エージェントは、その場限りのスナップショットをもとに作業することになり、新しいテストを書いた後で自分自身の結果を確認する手段もありません。
Coco MCP サーバーが加える価値
Coco MCP サーバーは、その手作業を完全に不要にします。エージェントはカバレッジデータを直接要求し、必要な情報だけを受け取ります。まずデータの有無を素早く確認し、次に概要レベルのサマリーを取得し、確認すべき場所が分かった時点で未テストコードの正確な位置を取得します。新しいテストを作成・実行した後は、自らの成果を検証し、カバレッジが実際に改善したかどうかを自動的に確認します。
その裏側では、cmreport と cmcsexeimport をエージェントが直接呼び出せるツールとしてラップし、変更ごとに更新された .csexe レポートを再インポートして再照会する仕組みになっています。
実際のエージェントセッションで確認した、
Coco Parser サンプルでの計測結果
Coco parser サンプル – 実際のエージェントセッション – 2つの自然言語プロンプトによるコードカバレッジデモ
プロンプトは2つ。
ツール呼び出しは8回。
手作業のレポートはゼロ。
自然言語プロンプト：カバレッジを分析し、parser.cpp を改善する
レポート作成とインポートの各ステップを自動化する MCP ツール呼び出し
新しいテストが必要な、ファイルとターゲットの正確な位置として特定された未実行ステートメント
グローバル決定カバレッジ：改善前 vs 改善後
すべてのインストールに含まれる Coco parser サンプルによる結果です。実際の数値は環境により異なります。 エージェントセッションの全体像を見る
エージェントが、未テスト箇所を推測する
ソースコードとテストファイルを読み取り、カバーされている範囲を推測します。特定された未カバー箇所の中には実際には存在しないものもあれば、逆に見逃されているものもあります。実行時データがなければ、両者を区別する方法はありません。
すでに実行されている部分に、
テストが書かれてしまう
実行時データがなければ、エージェントは見えていないカバレッジを重複して作成してしまうことがあります。実際の未カバー箇所は、レビューや監査で発見されるまで残り続けます。
エージェントが、計測済みビルドから
未実行のコード項目を照会する
Coco の計測済みビルドは、テスト実行によってコードのどの部分が実行されたかを記録します。MCP Server はこのデータを、照会可能なツールとして公開します。エージェントは未テストのソースコードの正確な位置を取得し、それに対応するテストを作成します。その後、プロジェクトを再ビルドしてテストを再実行し、分析用の新しいカバレッジデータを取得します。
エージェントは、その時点の判断に本当に必要なデータだけを照会します。
未加工のレポートを読み込む必要も、
無駄なコンテキストを消費することもありません。
| ツール | 範囲 | 詳細 |
|---|---|---|
check_coverage_summary |
データベース | カバレッジデータはインポート済みか？ Yes / No |
get_coverage_overview |
プロジェクト / ファイル / 関数 | 全体のカバレッジ率、ファイル単位の内訳、任意でサイクロマティック複雑度を含む関数単位の内訳。エージェントは、次にどのファイルを調査すべきか優先順位をつけられます |
get_file_coverage_detail |
ファイル / 行 | 未実行・デッドコード・実行済みといったステータス別の、正確なファイル：ターゲット位置。任意で、各ポイントを実行したテストへのマッピングも可能です。 |
MCP ホストの互換性
すでに使っているエージェントで、
そのまま動作する
Coco MCP サーバー は stdio 経由で通信し、MCP 標準に準拠しています。準拠したホストであれば、ワークフローのプロンプトを変更することなく接続できます。
カバレッジが計測から得られると、何が変わるのか
エンジニアの時間が、作成からレビューへとシフトする
エージェントは .csmes データベースから未実行の計測ポイントを照会し、正確なファイル：行の位置にテストを作成し、その結果を再検証します。エンジニアが行うのは、成果物の作成ではなくレビューです。
すべてのパーセントポイントに .csexe の裏付けがある
カバレッジは、計測済みテスト実行によって構築された .csmes データベースを cmreport が読み取ることで得られます。未テストのコードはファイルと行で特定されるため、その数値はそのままリリース判断や安全性の根拠になります。
エージェントが書いたテストも、TÜV 認証の証跡に組み込まれる
エージェントがテストを書き、Coco がそれを計測します。実行データは、安全性の根拠としてすでに引用されているものと同じ .csmes データベースに記録されます。SGS TÜV Saar により ASIL D まで認証済みで、新たなツール認証は不要です。
パッチをカバーするテストだけを再実行する
analyze_patch_coverage_from_diff は、git diff の出力を受け取り、変更された行を実行するテストとその現在の合否状態を返します。再実行するのはそれだけです。再実行するのはそれだけです。4,000件すべてではありません。
C、C++、C#、Python、Tcl、QML をひとつの計測済みビルドで
多くのエンタープライズ製品は、サービス、UI レイヤー、組み込みコンポーネントにまたがって複数の言語を組み合わせています。Coco はそのすべてを計測し、結果をひとつの .csmes データベースにまとめます。別々のツールチェーンも、別々のレポートも、数値の手動突き合わせも不要です。
Coco は、ISO 26262 における ASIL D までの安全関連ソフトウェアについて、SGS TÜV Saar の独立認証を取得済みです。エージェントがカバレッジを向上させても、それは監査担当者にとってすでに馴染みのあるツールの中で行われることになります。
自社の標準に Coco をマッピングする
Coco がコンパイラをラップします。ビルドの他の部分は何も変わりません。
Coco をご存じない方へ。Coco は、C、C++、C#、QML、Python、Tcl に対応したコードカバレッジツールです。ビルドを計測し、テストが実際に何を実行したかを正確に記録します。ソースコード、テストスイート、CI パイプラインへの変更は一切必要ありません。
監査担当者がすでに信頼する
カバレッジデータを Coco が生成する
自動車
ISO 26262 · ASIL A - D
ISO 26262 は、ASIL レベルごとにカバレッジ要件を定めています。ASIL A・B にはステートメントカバレッジとブランチカバレッジ、C・D には MC/DC が求められます。実行環境によって到達可能な分岐が変わるため、これらはデスクトップ上のシミュレーションではなく、実機のターゲットハードウェアから取得する必要があります。
Coco は本番バイナリを計測し、ECU 上または SIL ベンチ上で決定条件データと MC/DC データを直接収集し、安全性の根拠として必要なエビデンスを生成します。認定キットは DO-330 に準拠したツール認定をサポートするため、その根拠づくりをゼロから行う必要はありません。
鉄道
EN 50128 · EN 50716 · SIL 3 - 4
EN 50128 は、SIL 3・4 において構造カバレッジを求めており、最低限としてブランチカバレッジと条件カバレッジ、最もクリティカルなコンポーネントには MC/DC が必要です。鉄道用ソフトウェアは RTOS ベースの組み込みターゲット上で動作し、ネットワーク接続やディスプレイ出力、正常終了の仕組みを持たないことも少なくありません。
Coco は、dump-on-event 方式を用いてこれらのターゲットから直接カバレッジを収集し、組み込み環境とデスクトップ環境それぞれのテスト結果を、ひとつの .csmes データベースにマージします。アプリケーション本体やテスト基盤に変更を加える必要はありません。EN 50128 の後継規格である EN 50716 にも対応しています。
産業オートメーション
IEC 61508 · SIL 1 - 4
IEC 61508 は、SIL 2 以上のソフトウェア要素に対してカバレッジに基づく検証を義務付けています。産業用安全システムは、単一の言語や単一のテスト種別で完結することはほとんどありません。C 言語で書かれた PLC ロジック、C++ や QML の HMI、C# の安全レイヤーがあり、それぞれデスクトップでの単体テスト、コントローラー上での機能テスト、そして実機での手動検証によって検証されます。
Coco は、あらゆるテスト種別からのカバレッジをひとつの .csmes データベースに蓄積し、CI で実行された結果だけでなく、テストキャンペーン全体を反映した、監査可能なひとつのカバレッジ数値を機能安全マネージャーに提供します。認定キットも利用可能です。
医療
IEC 62304 · Class C
IEC 62304 の Class C ソフトウェアには、構造カバレッジを含む文書化された検証戦略が求められます。認証機関が確認したいのは、カバレッジ率だけでなく、どのコードがどのテストによって実行されたかという点です。
Coco は、.csmes データベースから直接、テストごと、計測ポイントごとのレポートを生成します。これは、AI エージェントが未カバー箇所を解消する際に照会するのと同じデータベースです。C、C++、C#、QML が混在する製品も、ひとつの計測済みビルドでカバーできます。IEC 62304 および ISO 14971 に基づくツール認定を支援する認定キットも含まれています。
航空宇宙・防衛
DO-178C · DAL A · DO-330
DO-178C の Table A-7 は、ソースコードレベルおよびオブジェクトコードレベルでの構造カバレッジ分析を求めています。DAL A では MC/DC が必須です。カバレッジは、静的解析ツールからではなく、対象プロセッサ上で実行される実際の実行可能ファイル、または承認された同等環境での動的テストから取得する必要があります。
Coco はバイナリを計測し、実行環境から直接 MC/DC データを収集します。委託先のテストハウスを利用するプログラムでも、計測済みバイナリを共有し、cmmerge を使って結果を一元的にマージできます。ソースコードがプログラムオフィスの外に出ることはありません。DO-330 に準拠したツール認定のエビデンスも提供しています。
チュートリアル
AI コードアシスタントを使って単体テストを生成し、カバレッジを最大化する方法
本記事では、GitHub Copilot + Coco Code Coverageを使ってテストカバレッジを65% から 78%まで向上させる方法と、この手法を他のフレームワークや業界、安全性が重視される分野にも応用する方法をご紹介します。
ブログ
テストする関数を間違えている——バグが本番に出る前に知っておくべきこと
カバレッジ率が高いからといって、正しいコードをテストできているとは限りません。チームは自然と、指標を上げやすいシンプルな関数のテストに偏りがちで、その一方で複雑でリスクの高いロジックはテストされないまま残ってしまいます。