ContextForge 有用性の評価：LLMコードレビュー精度で測る

1. 考え方

「このツールを使うことで、LLMのコードレビュー精度が上がるか」を見れば、ContextForgeの有用性が測れる。

つまり、ツールの有用性 ≈ ContextForgeあり vs なしでの、LLMコードレビュー品質の差として定義する。

条件A（ContextForgeあり）	条件B（ContextForgeなし／通常）
ContextForgeで生成したアーティファクト（ZIP/レポート）をLLMに渡し、その上でコードレビューを依頼する	同じリポジトリを、IDEやそのままのファイルリストなど「通常の渡し方」でLLMに渡し、コードレビューを依頼する

で比較する。

GPT-5-Codexの発表で使われたような指標を流用できる：

指標	意味	望ましい方向
不正確な指摘割合	レビュー指摘のうち、誤り・的外れだった割合	ContextForgeありの方が低いと有用
重要なコメント割合	指摘のうち「影響が大きい」と判定された割合	ContextForgeありの方が高いと有用

このほか、必要に応じて以下も検討できる：

対象リポジトリ／PR
レビュー対象のコード（できれば複数サンプル）。
正解ラベル（Ground Truth）
各指摘について「正しい／誤り」「重要／軽微」を人手で付与。
→ 不正確な指摘割合・重要コメント割合を計算するために必要。
同一条件での2通りの実行
- ContextForgeでアーティファクトを生成 → それを渡してレビュー（条件A）
- 通常の渡し方でレビュー（条件B）
結果の集計
条件A・Bそれぞれについて、上記指標を計算し比較する。

厳密な「コードレビュー精度」（不正確な指摘割合・重要コメント割合など）を個人が計測するのは現実的ではない。

理由の例：

つまり、「13.7%→4.4%」のような数値は、個人ユーザーが自分で出すものではない。

数値で出さなくても、個人は次のようなやり方で「ContextForgeが役に立っているか」を感覚的・相対的に確かめられる。

やり方	内容
比べてみる	同じコードで「ContextForgeで作ったアーティファクトを渡したとき」と「いつもの渡し方のとき」でレビューを依頼し、どちらの指摘が自分にとって役に立ったかを比べる。
ノイズで判断	「明らかに違う指摘」や「何度も出る無意味な指摘」が、アーティファクトを渡したときの方が減った気がするかを見る。
採用した指摘で判断	レビュー結果のうち実際に直す／取り入れた指摘が、アーティファクトありのときの方が多かったか、質が高かったかを振り返る。
再現性で判断	同じZIPを何度か渡して聞き直したとき、同じ前提で話が進む感覚があるか（「前回と食い違う指摘」が減るか）を見る。

これらは主観的だが、「個人が自分の作業で有用性を確かめる」には十分な目安になる。
公式の「精度○%」のような指標は、コミュニティやPro側がベンチマークで出す想定で、個人は上記のような体感ベースの判断でよい。

評価設計の提案であり、現時点でContextForge本体に評価スクリプトやベンチマークは含まれていない。
厳密な精度の数値は、コミュニティやPro版がベンチマークで出す想定。個人は「比べてみる」「ノイズが減ったか」「採用した指摘の質」など、体感ベースで有用性を判断すればよい。
実際に測定する場合は、別リポジトリや eval/ のようなディレクトリで、正解データ・実行手順・集計スクリプトを用意する形が現実的。

問い	答え
ContextForgeの有用性は何で測る？	「ContextForgeを使うとLLMのコードレビュー精度が上がるか」で測れる（設計上の指標）。
個人が数値で測れる？	厳密な割合（不正確な指摘○%）は個人には難しい。正解ラベル・複数サンプル・集計が必要で、ベンチマーク運用向け。
個人はどう判断する？	比べてみる（アーティファクトあり vs なしでどちらが役に立ったか）、ノイズが減ったか、実際に採用した指摘の質など、体感・相対比較で十分。

この「レビュー精度の変化を見る」という観点を、公式の有用性指標として明示しておくことで、ユーザーやステークホルダーに「何を持って価値があるか」を伝えやすくなる。一方で、個人ユーザーは数値計測ではなく、体感ベースの判断でよいことを明記しておく。