📑
LLMをの評価基準はどう決めるかについて

2025/09/01に公開
Claude-codeでコーディングをして、プロジェクトから外れた構成をした内容に関して、現状可能な範囲で改善する範囲とリファクタリングの範囲の内容を変更差を記録しました。
3つのパタンを記録しています。

(無料で試したため、参考にはできないと思います。)
これで気になるのは、評価値としてどのように基準化していくのか、という点です。

命名規則やコーディングの内容に関して、調整が必要な点が他にある前提はさておき、変更する内容に対してオペレーションするには差があります。

これはLLMを扱う以上前提ですが、ルールの設定やLLM、エディタ、CILの違いなど、実際にカテゴライズや使うパタンとしてのカスタマイズも異なります。
質問しながら徐々に作られていくことが、ベースだと考えていますが

最小単位のプロセス以下だと考えます。
[ABlock] -----

1,LLMへのメッセージ

2,LLMからのレスポンスと評価

3,実装

4,1に戻る
このサイクルに対して、

前提のプロジェクトの情報

githubやgitlabなどの変更パタン

開発者の情報構造のオペレーションに対する特徴量の把握があり、

会話とオペレーションの継続でチャット形式で改善されていく、というプロセスだと考えます。
対象のリポジトリは以下です。

https://github.com/mindface/betaTasker
1.0.98 (Claude Code)

https://github.com/mindface/betaTasker/tree/claude-code-ref
Identifier github.copilot Version| 1.364.0 Last Updated 2025-08-29, 04:03:57 Size| 64.11MB

Agent GPT-4.1

https://github.com/mindface/betaTasker/tree/copilot
Version: 1.5.7 (Universal) VSCode Version: 1.99.3 Electron: 34.5.8 Chromium: 132.0.6834.210 Node.js: 20.19.1 V8: 13.2.152.41-electron.0 OS: Darwin arm64 22.6.0

https://github.com/mindface/betaTasker/tree/re-cursor

(Agentのコーディングではありません。)
コードの命名規則やファイルの場所を評価して、類似点から新規でコーディングすることなど、実際に活用しようとする時に、ルール付けすると結果として、どう解釈するかという点でこの1つのオペレーションに対する実行の単位を記録した内容になります。
1単位を連続して、確認しABlockとして各LLMのパタンに対する改善した結果の回数aと時間tによって

計測されます。
ABloclkx回数a|時間t => Result

Resultに対して、結果に関して出力内容を補正した箇所数とその時間
評価の形成に関して、LLMの各モデルのパタンや検証総数から感覚的に評価することがベースかもしれません。

ABloclkの1回の概念が1レスポンスか、コードの確認までか、など、指標が分かれそうですが、どちらかというと計測の概念の定義をどうするか、という話の方が課題にも見えそうです。
全体を確認した上で、対象の箇所の変更するためのオペレーションを定義される効果を検証することができるかどうかも考える必要もありそうです。

今回はエージェントでしたが、MCPサーバーの場合の効果の計測を会話上で計測するための指標をするプロセスも難しそうです。
どこかの企業は、すでに開発者のオペレーションや確認の数値の記録を相対的にデータとして使い、それをDWHのダッシュボードを側だけ使うことやBIツールで指標にしているかもしれません。
ということで以下を質問してみました。
数理モデルとして公開してる情報はありますか。
1. LLMオペレーションと開発サイクル（ABlockサイクル）の評価指標化について

ご提示の「ABlock」（LLMへのメッセージ → 応答と評価 → 実装 → 再開）サイクルを評価するためには、以下のような多層的指標（メトリクス）を用意すると実用的です。

A. LLM出力の品質評価（機能的視点）
Answer Correctness（正確性）
Relevance／Contextual Relevancy（関連性）
Hallucination（幻覚率）、Bias（偏り）などの品質指標

Task Completion（タスク完遂率）
これらは、LLMの生成内容そのものを評価するメトリクスで、例えば G-Eval、DAG、LLM-as-a-judge（他のLLMを用いた評価）などの手法が挙げられます。
Confident AI
PromptLayer
arXiv

B. システム性能・運用パフォーマンス

Latency（応答速度）
Error Rate（エラー率）
Throughput（処理能力）

ビジネス視点ではコスト面（トークン使用量等）も含まれる場合があります（AiseraのCLASSicフレームワーク参照）。
galileo.ai
Aisera: Best Agentic AI For Enterprise

C. 開発プロセスの生産性指標（開発者視点）
SPACEフレームワーク
Satisfaction（満足度）
Performance（パフォーマンス）
Activity（活動量）
Collaboration（協働）
Efficiency（効率）

DORAメトリクス（DevOps Research and Assessment）でよく知られた指標：
Lead Time（変更のリードタイム）
Deployment Frequency（リリース頻度）
Change Failure Rate（変更失敗率）

MTTR（平均復旧時間）
これらはLLM導入による開発サイクルの変化を測るのに有効です。
ウィキペディア
+1
Medium

2. 指標の収集と可視化 → DWH／BIツールとの連携

既に企業の多くは、LLMや開発プロセスに伴うメトリクスをDWHやBIツールで収集・可視化し、以下のように活用しています：

時間・回数ごとの傾向分析：
LLM応答品質が時間とともに改善しているか、ABlockサイクル回数 a や時間 t と連動させて見る。

多次元評価：
LLM品質指標 × 運用指標（latencyなど） × 開発生産性指標をクロス集計。

Alert・ダッシュボードによるリアルタイム監視（LLMOps）：
異常な品質低下や応答遅延があればアラート通知する体制。
PromptLayer
Datadog

評価プロセスの表ログ：
どのPrompts／モデル／改善案がどのように成果につながったかを追跡。

3. 数理モデル的な公開例：最新論文も参考に
A. Code Quality Score（CQS）

LLM生成コードの品質を定量化し、実際の開発現場で導入された例。コード品質の自動評価＋開発者フィードバック収集による改善循環を構築。
arXiv

B. LLM-as-a-Judge による評価精度の検証

LLM自身を評価者として用いた評価スコアが、人間の評価と高い相関を示すという研究成果。
arXiv

4. ご提案：あなたの ABLOCK モデル向け指標体系の設計例
| カテゴリ       | 推奨指標例                                          |
| ---------- | ---------------------------------------------------- |
| LLM品質評価 | 正確性、タスク完遂率、 hallucination、LLM-as-judge スコア |
| システム性能     | 応答速度、エラー率、リクエストスループット、コスト        |
| 開発プロセス効率   | ABlock回数 a、ABlockにかかる時間 t、Lead Time（DORA）、満足度（SPACE） |
| 定量・定性の混合評価 | Qualitativeコメント（開発者インサイト）＋定量スコアの併走  |

このような混合型アプローチを DWH／BI に統合し、定期的なレビューやカイゼン会議に活用すると効果的です。

結びに

現実世界に近い「ABlockサイクル」においては、LLM品質評価 × 運用指標 × 開発効率、さらには定性情報を統合した体系的計測が鍵になります。

参考例として CQSシステム や LLM-as-a-Judge の研究は、非常に有用な実装ヒントになります。
arXiv
+1

SPACE や DORA フレーム、LLMOps フレームワークも過去の実績として有効に活用可能です。

ご希望があれば、具体的なダッシュボード設計や Prompts のフォーマット提案、BI可視化の例などもご用意できますので、お気軽にお知らせください
最終的に以下の質問してレスポンスがありました。
ちなみにこれを企業で実装しているところはありますか。
ANZ銀行：GitHub Copilotと生産性評価

ANZ銀行では、GitHub Copilotの導入により、生産性とコード品質が大幅に向上したという実証的な研究を行っています。約1,000名のエンジニアによるテスト結果として生産性と満足度の向上が確認されました。ただし、具体的な「実行回数と時間を組み合わせたモデル」は示されていません。

arXiv
そのほかもレスポンスがありましたが、回答を保証するものではありませんでした。

以上です。

これは、オペレーションとして使ったのですが、言語情報としての指示と内容を明確するとそこから、連続した形式を保持しているためのか、以下のブランチの形式になっています。
コードに対する状況的な参考を持して、その抽出量を保持できる確率よりも、言語として様々なパタンを保持していることで成立する文脈を与えることで成立させることが効果があることになります。
これは内容を保証するものではないので、実装と検証をするための参考程度に解釈していただけると幸いです。
Discussion
