Git履歴を技量スコアにせず、検算できるCLIを作った

git履歴から、後で検算できる事実だけを取り出すOSS Grift CLI v0.5.6 を公開しました。

作った背景にある、GitHubの活動量、経験年数、人月への違和感はnoteへ分けています。

この記事では思想についてではなく、技術的観点の次の5点に絞ります。

• 5分で動かす方法
• 何を観測するのか
• その数値から何が言えて、何が言えないのか
• 73 / 274 をどう検算するのか
• 技量スコアにしないために、何を出さないのか

まず動かす

Python 3.11以上とgitが入っていれば、対象リポジトリで次の3行です。

pipx install grift-cli
cd ./my-repo
grift report

grift report は現在のHEADを分析し、次の2ファイルを作ります。

.grift/report.json
.grift/report.md

• report.json: 機械処理と検算に使う正本
• report.md: 人が読むための表示

もう一度確かめるときは、同じリポジトリで次を実行します。

grift verify

レポートに記録された条件で再計算し、一致すれば VERIFIED、違えば MISMATCH、再計算できなければ CANNOT_VERIFY を返します。

Grift CLIとは

Cor.株式会社では、受託開発の現場に散らばる顧客の要望を、要件、参考見積もり、作業パケットへ構造化するGriftというプロダクトを作っています。

Griftでは、AIに見積金額を丸投げしません。

過去実績や相場を材料にして、「なぜこの金額になるのか」を人間が確認できる形にします。

その中で作ってきた、git履歴から確認可能な事実を取り出す部分を、単独で試せるOSSとして切り出したのがGrift CLIです。

資料はこちら

方法論の名前は TEP（Technical Evidence Pipeline）、コマンド名は grift です。

最初に、出さないものを決めた

Grift CLIは、エンジニアの技量を一つの数字にするツールではありません。

出さないもの	理由
技量の総合点	異なる観測を一つへ丸めると、前提と文脈が消える
シニア／ジュニア等のランク	リポジトリの目的、担当範囲、開発段階をgitだけでは判断できない
採用の合否	判断は人間が行い、CLIは確認できる材料だけを渡す
AI利用の検出・減点	AIを使ったかどうかを罰する機能ではない
観測できなかった値のゼロ埋め	not_observed や unresolved として、分からない理由を残す

「数値が高いほど優秀、低いほど劣る」という読み方もしません。

何を数えたのか。

分子と分母は何件か。

誰の仕事として数えたのか。

どのscope、定義版、SHAで分析したのか。

そこまで戻れることを優先しています。

個人とリポジトリ全体を混ぜない

分析範囲は2種類あります。

• --scope tenant: .tep/identity.toml で本人に帰属すると確認できた変更を見る。本人が自分の経験を説明するためのscope
• --scope repo: botを除くリポジトリ全体の人間の変更を見る。開発プロセスと参照分布のためのscope

個人の値を、リポジトリ全体の分布へそのまま載せません。

母集団が違うからです。

identityやupstreamを確定できない変更も、勝手に本人の実績へ入れず、unresolved などとして残します。

実際に何を観測するのか

v0.5.6で扱う主な観測は次の通りです。

観測	数えているもの	そこから読めること	それだけでは言えないこと
origin / 帰属	本人固有、上流継承、merge/sync、vendor生成物、bot、未解決など11分類のコミット件数	どの変更を観測対象へ入れたか	コードの良し悪し
activity	本人に帰属したコミット数、活動日数、活動日あたりの平均・中央値、直近13週の活動日数	変更が何日に分散したか	労働時間、生産性
core activity period	本人に帰属したコミットの80%以上を含む最短の連続月区間	活動がどの時期に集中したか	在籍期間、経験年数
test co-change	本番コードを変えたコミットのうち、同じコミットでテストも変えた件数と比率	変更とテストコードが一緒に動いた頻度	テストの成否・質、コード品質
path retouch	本番コードの同じパスへ21日以内に再接触したコミット件数と比率	同じ場所へ短期間で戻った頻度	手戻り、不具合の件数
corrective rework	21日以内の再接触のうち、件名がfix、hotfix、bug、revert等に一致した件数と比率	件名上、修正として記録された近接再変更	バグ率、技量。件名規約にも左右される
revert rate	対象コミットのうち、revertとして検出した件数と比率	取り消しとして記録された変更の頻度	失敗率
survival（任意）	現在の行をblameし、行の経過日数に時定数180日の指数減衰重みを付けた平均	現在残る行の相対的な新旧	180日後に残った割合、コード品質
context profile	参加者数、最大参加者の比率、活動日密度、merge比率、言語・test・docs・releaseなど	数字が出たリポジトリの規模・活動・共同作業の文脈	個人の能力、チームの優劣

観測を「帰属」「証拠」「観測」「文脈」に分け、総合点にはしません。

0.2664 ではなく、73 / 274 と読む

公開OSS pallets/click を使ったtenant scopeのゴールデン例では、test co-changeが次のように出ます。

test co-change: 0.2664 ratio（73 of 274）

この値が記録しているのは、次の事実です。

本人に帰属した本番コード変更274件のうち、73件では同じコミットでテストも変更されていた

テストだけの変更やdocsだけの変更は、274件の分母へ入れません。

そして、73 / 274 から次のことは言えません。

• テストが通った
• テストの質が高い
• コードの品質が高い
• 本人が優秀である

一方で、質問は具体的になります。

• この期間は、どんな変更を担当していたのか
• テストが同じコミットで動かなかった201件には、どんな事情があったのか
• 担当範囲やリポジトリの段階を踏まえると、この値をどう読むべきか

小数だけではなく、分子、分母、定義、文脈へ戻れることが重要です。

同じSHAを再計算できる

レポートには、次を残します。

• 方法論名
• ツール版
• 定義版
• 分析scope
• 分析したコミットSHA
• 指標の分子と分母

同じリポジトリとレポートがあれば、受け取った側も再計算できます。

grift verify

既存のJSONを、再分析せずMarkdownへ表示し直したい場合だけ、入力ファイルを明示します。

grift report .grift/report.json --out ./rendered-report.md

引数なしの grift report は常に現在のHEADを再分析します。

「最新を測ったつもりなのに、古いJSONを表示していた」という状態を避けるためです。

117リポジトリで、分けられなかった結果も残した

test co-changeは、117リポジトリのコーパスで判別力を確認しました。

117件すべてを一つの比較へ使ったわけではなく、比較ごとの母数は別です。

• 検証文化のあるOSS群とテンプレート由来群: 18件対18件、Cliff's δ=0.9198、登録済み判定は separated
• 同じOSS群と、テストを持つAI活用リポジトリ群: 18件対21件、δ=0.291、fail_tier2

二つ目を分けられなかった理由は、この結果だけでは分かりません。

結果を見てから基準を下げず、効かなかった結果も残しています。

ローカルで動き、勝手に送らない

分析は手元のリポジトリで完結します。

• LLMを使わない
• テレメトリを持たない
• 分析結果を自動送信しない
• grift contribute も公開用payloadをローカルに作り、全文を表示するだけ

提出する場合は、本人が内容を確認し、自分でPull Requestを作ります。

利用規範では、数値だけの足切り、同意のない第三者プロファイリング、組織内の監視や個人比較をTEP非準拠としています。

v0.5.5で、普段使う操作を2語に揃えた

v0.5.4では、引数なしの grift report が古い report.json を拾わず、常に現在のHEADを再分析するようにしました。

v0.5.5では、普段使う操作を次の2語に揃え、既定出力を .grift/ に統一しました。

grift analyze
grift report
grift verify
grift contribute

grift report の裸実行と grift verify の裸実行は、公開wheelを新しいリポジトリへ入れて実測済みです。

自分のリポジトリで確かめてほしい

pipx install grift-cli
cd ./my-repo
grift report
grift verify

出てきた数字が、自分の経験と合っているか。

大事な文脈を落としていないか。

数字だけを見ると誤解されそうなところはないか。

違和感があれば、数値とリポジトリの文脈をIssuesへください。

• GitHub: https://github.com/Cor-Incorporated/grift-cli
• PyPI 0.5.6: https://pypi.org/project/grift-cli/0.5.6/
• Issues: https://github.com/Cor-Incorporated/grift-cli/issues

参照資料

• 作った背景を書いたnote「AI時代のプロジェクトをどう評価するのか」
• Grift: https://cor-jp.com/works/grift/
• README（v0.5.6）: https://github.com/Cor-Incorporated/grift-cli/blob/v0.5.6/README.md
• report-v1の定義: https://github.com/Cor-Incorporated/grift-cli/blob/v0.5.6/docs/report-schema.md
• 利用規範: https://github.com/Cor-Incorporated/grift-cli/blob/v0.5.6/docs/norms.md
• 判別力の記録: https://github.com/Cor-Incorporated/grift-cli/blob/v0.5.6/corpus/DISCRIMINANT-v2026.11.md