Pipeline Lens

人とAIエージェントが混在した開発で、誰が何を書いたか / どこで詰まったか / 仕様がいつ変わったかを可視化するVS Code拡張です。

📖 この拡張が生まれた背景の物語: STORY.md —「誰も見ていないコード」（同梱されています）

他のツールと何が違うのか

1. いま見ているその行に答えを出します

LinearB・Jellyfish・DX・Swarmia などのエンジニアリング分析基盤は、PRのサイクルタイムやDORA指標といったメタデータで動いていて、diffを見てAIか人間かを区別しません。GitClearのようなコード分析は行レベルを見ますが、ダッシュボードです。

ダッシュボードは構造的に、あなたが読んでいるコードの上に答えを置けません。 この拡張は行にマウスを乗せると出します:

🤖 claude-code — 2026/6/3 15:50
refactor: support stacked coupons (#101)
判定根拠: Co-Authored-By: Claude
─────────────────────────────────
⚠️ この行が書かれた後に仕様が変わっています
- specs/coupon.spec.md — 6/4 に改訂
⚠️ この変更に人間のレビュー記録がありません
この行が書かれた後、このファイルは 2 回変更されています

git blame は「誰がいつ」しか答えません。AIが書いたかは Co-Authored-By: トレーラーにしかなく、blameはそれを見せないからです。

2. 「仕様が先に進んでいるコード」を検出します

git上は何も異常に見えません。テストは通り、PRも開いておらず、変更もない。それでもコードは要件と合っていない — エージェントに実装を任せたときの典型的な失敗です。

仕様が先に進んでいます  specs/notify.spec.md
2026/6/18 に Rin Takahashi が改訂。以下は改訂前のまま:
- src/notify/push.ts — 7 日前（Claude）が最後

仕様の履歴とコードの履歴を突き合わせないと原理的に検出できません。 メタデータ基盤はdiffを読まず、コード分析基盤は要件履歴を持たず、エージェント監視基盤はリポジトリを持たない。この検出には3つのうち2つが同時に必要です。

3. データが外に出ません

gitとローカルのイベントファイルだけで動きます。サーバもアカウントも不要で、リポジトリをSaaSに取り込ませる必要がありません。

セキュリティとプライバシー

ネットワーク通信は1か所だけ。 GitHub連携を使ったときの api.github.com への読み取りアクセスのみです（PR・レビュー・CIの取得）。トークンはVS Codeの認証機構から都度受け取り、保存しません。連携しなければ通信はゼロです。テレメトリはありません
同梱している第三者コードはありません。 実行時依存パッケージゼロで、VSIXの中身はすべてこのリポジトリのMITライセンスのコードです
git はシェルを介さず引数配列で実行します（コマンドインジェクション対策）。イベントデータ由来のコミット参照は16進形式のみ受け付け、パスはリポジトリ内に制限、外部リンクは http/https のみ開きます
信頼されていないワークスペースでは動作しません（Workspace Trust対応を宣言済み）。開いたフォルダで git を実行する拡張なので、これは意図した制限です
書き込むのは対象リポジトリの .pipeline-lens/（自動で .gitignore 済み）だけです

1. インストール

code --install-extension pipeline-lens-0.1.0.vsix

GUIからでも入れられます。VS Codeの拡張機能パネル → 右上の ··· → 「VSIX からのインストール...」 → pipeline-lens-0.1.0.vsix を選択。

インストール後、VS Codeの再読み込みは不要です。

2. 使いかた（すべてクリック操作）

コマンド入力は一切不要です。

ステップ1: gitリポジトリのフォルダを開く

この拡張はgitリポジトリでしか動きません。 普通にVS Codeでリポジトリのフォルダを開いてください。

gitリポジトリでない場合はサイドバーに案内が出て、［フォルダを開く］ と ［このフォルダを git リポジトリにする］ のボタンが表示されます。そこから操作できます。（このAITeamフォルダ自体はまだ git init していないので、ここで試すとこの画面になります。）

ステップ2: アクティビティバーのアイコンをクリック

VS Code左端の縦アイコン列に、横3本線のアイコン（Pipeline Lens）が増えています。それをクリック。

サイドバーに「作業スレッド」が開きます。初回は ［履歴を読み込む］ ボタンが出るので押してください。数百コミットで数秒です。

ステップ3: 一覧から選ぶ

読み込みが終わると、詰まった順にスレッドが並びます。

一番上には、いま何をどうまとめて表示しているかの説明が出ます。ここは読んでください。「課題番号が見つからないので作業セッション単位でまとめました」のように、ツールが何をしたかを必ず申告します。クリックすると設定画面が開きます。

🔴 spec: coupon field on checkout (#101)      詰まり 4 件 · 2日
   ⚠ 仕様が実装開始後に2回変更されました
   ⚠ CI が3回連続で失敗
   ⚠ 3ファイルが3回以上書き直されました
   ⚠ エージェントのツールエラー・権限拒否が2件
   👤 担当: Rin Takahashi、claude-code、github-actions、playwright
   🕐 イベント 21 件 · 2日
🟡 spec: passkey login (#103)                 6時間
⚪ fix: null guard in cart total (#102)        20分

🔴＝詰まった / 🟡＝やや / ⚪＝順調
行をクリックすると、タイムラインが開いてその箇所が光ります
左の > を押すと詰まった理由が展開されます
マウスを乗せるだけでも要約が出ます

常に見える場所

ウィンドウ右下のステータスバーに 3 件が難航 のように出ます。クリックでタイムラインが開きます。 VS Codeを起動した時点で表示されるので、ここが一番手軽な入口です。

2-1. ボタンの位置

やりたいこと	押す場所
タイムラインを開く	ステータスバー右下 or サイドバーの行 or サイドバー上部の 📈
履歴を読み込み直す	サイドバー上部の 🔄 or タイムライン右上の［履歴を読み込み直す］
設定を開く	サイドバー上部の ⚙ or タイムライン右上の［設定］
gitリポジトリにする	サイドバーの案内内のボタン

サイドバー上部のアイコンは、「作業スレッド」のタイトル行にマウスを乗せると出ます。

3. 画面の読み方

上部（サマリー）

Pipeline Lens                  [履歴を読み込み直す] [設定]
┌────────────────────────┬──────────────┬──────┐
│      agent 50%         │  human 50%   │ bot  │   ← コミット数の比率
└────────────────────────┴──────────────┴──────┘
29 イベント · 3 スレッド · エージェント 12 行 / 人間 17 行
● コミット  ◆ 仕様変更  ▲ レビュー  ■ PR  ▮ CI  ✕ エージェントのエラー
● 成功  ● 失敗  ● 保留   ┆ 破線＝実装開始。右側の仕様変更＝後出しの要件変更

紫＝エージェント、青＝人間、灰＝bot。バーにカーソルを乗せると実数が出ます。

本体（スイムレーン）

1つの枠＝1つの作業単位（スレッド） です。まとめ方は2通りあり、枠の左のバッジで区別できます。

バッジ	まとめ方
`#101` のような番号	ブランチ名やコミットから拾った課題番号単位。こちらが本来の姿
`作業セッション`（点線枠）	課題番号が無いので、4時間以上あいたところで区切った1回の作業単位

課題番号を使っていないリポジトリでは全部が「作業セッション」になります。それでも「3月22日の午後に auth.ts を3回書き直した」といった単位までは絞り込めます。区切り時間は設定で変更できます（5章）。

● 101  spec: coupon field on checkout (#101)                   2d
  [仕様が実装開始後に2回変更] [CI 3連続失敗] [3ファイルを3回以上書き直し]

                        ┆ code starts
  claude-code   ────────┆──●────●──────────●──────●────────
  Rin Takahashi ──◆─────┆────────────◆────────▲───────●────
  ci / bots     ────────┆──▮▮──▮────────▮──────────────────
                        ↑
                  この線より右の ◆ ＝ 後出しの要件変更

横軸は時間（そのスレッドの中で正規化。長さは右上の 2d などで確認）
行＝担当者。エージェントは種類ごとに1行、人は1人1行
左端の色つきの丸：赤＝詰まった、黄＝やや、緑＝順調
枠は詰まった順に上から並びます

いちばん重要なのが code starts の破線です。実装が始まった時刻を示していて、**その右側にある ◆（仕様変更）が「後出しの要件変更」**です。ここが厚いスレッドが、いちばん時間を溶かしています。

クリックすると

グリフ（●や◆）をクリックすると右側に詳細が出ます。

項目	意味
担当	誰が（人 / エージェント種別）
判定根拠	なぜAI／人と判定したか（例: `Co-Authored-By: Claude`）
データ元	どのデータソースから来たか
対象	どの画面・ファイルか

「判定根拠」は必ず出ます。AIか人かの判定根拠が追えないと信用できないためです。

その下に 変更ファイルの一覧が出ます。

変更ファイル 2 件
  src/checkout/coupon.ts
  src/checkout/total.ts
  ［現在のファイルを開く］

ファイル名をクリックすると、そのコミット時点の差分（before / after）が開きます。 現在のファイルではなく、その時に何が変わったかが出ます。同じレーンの別の時点をクリックすれば、当然それぞれ別の差分になります。

この変更の差分を見る — 1ファイルなら直接、複数なら選択リストが出ます
現在のファイルを開く — 今のワーキングツリーの状態を見たいとき
GitHub で開く — GitHubのPRページ（GitHub連携時のみ）

3-0. 行ごとの出自表示

エディタのタイトルバーの目のアイコンで切り替えます。

アイコン	状態	押すと
👁️‍🗨️（閉じた目）	オフ	表示される
👁（開いた目）	オン	非表示になる

ステータスバー左側にも常に状態が出ています。

$(eye-closed) 出自 OFF
$(eye) 出自 ON · AI 62% · この行: claude-code

こちらもクリックで切り替わります。オン/オフはウィンドウを閉じても記憶されます。

オンにすると：

AIが書いた行に薄い紫の背景が付きます
人間が一度も編集もレビューもしていない行は赤系になります
スクロールバー（右端）にも印が出るので、ファイル全体のAI密度が一目で分かります
行にマウスを乗せると出自が出ます — どのエージェントが、いつ、どの仕様の下で書いたか。その後に仕様が改訂されていないか。人間のレビューを受けたか。何回書き直されたか
ステータスバー左側に この行: claude-code | このファイル AI 62%

ホバーの最下部の「このコミットの差分を見る」から、その行を書いたコミットの差分に直接飛べます。

取り込み範囲外（historyLimit より古い）のコミットの行は「不明」と表示されます。人間と断定はしません。

3-1. チームレポート（PM・EM・PL・スクラムマスター向け）

タイムライン上部の ［チームレポート］ タブに切り替えると、役割別の指標が出ます。 ［Markdown をコピー］ でレトロや週報にそのまま貼れます（ファイル保存も可）。

各指標には公開されている業界水準（2025-2026）を併記しています。目標値ではなく比較の目安です。

仕様との乖離 — いま直すべきもの

最初に出ます。ここだけは「傾向」ではなく「いま壊れているもの」だからです。

項目	意味
仕様が先に進んでいます	仕様が改訂されたのに、その実装が改訂前のまま更新されていない
誰も見ていない AI コード	エージェントが書き、人間が編集もレビューもせず30日以上経過

実装ファイルの特定は、同じスレッドに登場したコードファイルを使っています。形式的なトレーサビリティリンクが無い以上これが唯一の手がかりで、correlationId（課題番号）が効いてくるのはここです。

品質 — 書いたコードが残っているか

指標	意味
コード書き直し率（AI / 人間）	30日以内に書き直された行の割合。業界では AI導入前 ≈3.3% → 2025年 ≈7.1% と倍増
AI ÷ 人間	この比が 1.5x を超えると、AI分の手戻りが目立つ水準
テストを伴わない変更	テストファイルに一切触れずコードだけ変えたスレッド
人間が一度も触っていないファイル	エージェントのみが書き、人間が編集した記録が無いファイル

最後の2つは「エージェントが done と宣言したが検証されていない」領域を示します。 AI由来の障害は 30〜90日後に表面化するという報告があるため、先に見えている方が安全です。

書き直し率は git の行数統計による近似です。行単位の同一性までは追跡していません（画面にも明記されます）。

レビュー — 誰が負荷を負っているか

指標	意味
レビュー着手までの時間（AI / 人）	PR作成からレビュー開始までの中央値
AI ÷ 人間	AIのPRほど放置されやすい傾向が報告されています（業界 ≈5x）
レビュー負荷の偏り	誰が何件レビューしているか。1人に集中していないか
収束していないPR	2回以上の変更要求を受けてまだマージされていないもの

AI導入組織ではレビュー時間が +91%、PR数が +47%/人 増えています。最後の項目は、AIのPRの一部がレビューに入ると収束せず廃棄され、レビュー工数が回収できない問題に対応します。

フロー — 仕事の流れ方

指標	意味
リードタイム中央値 / 85%タイル	着手から完了まで。両者の差が大きいほど予測が効きません
週あたり完了数	スループット
進行中 / 滞留している作業	動きが止まっているものを日数順に

ベロシティが機能しなくなった代わりに使える、フロー系の指標です。滞留項目はクリックでタイムラインに飛べます。

4. GitHub連携（PR・レビュー・CI）

初回は自動では繋がりません。 これは意図的で、拡張を開いた瞬間に認証ダイアログが出るのを避けているためです。

繋ぐには、タイムライン右上の［履歴を読み込み直す］ か、サイドバー上部の 🔄 を押してください。VS CodeのGitHub認証ダイアログが出るので許可すると、以降はPR・レビュー・CIの結果もタイムラインに乗ります。

トークンの用意は不要です。 VS Codeが既に持っているGitHubセッションをそのまま使います。PATの発行もOAuthアプリの登録も要りません。

一度許可すれば次回以降は自動です。連携したくない場合は設定で pipelineLens.github.enabled をオフにしてください。

5. 設定（ここが肝心）

サイドバー上部の ⚙、またはタイムライン右上の ［設定］ を押すと、この拡張の設定画面が直接開きます。

`pipelineLens.specGlobs` — 仕様書の置き場所

["specs/**/*.md", "docs/specs/**/*.md", "*.spec.md", ".kiro/**/*.md"]

この設定がこのツールの心臓部です。 仕様書をリポジトリ内のファイルとして置いていれば、そのgit履歴がそのまま「思考がどう変わったか」の記録になります。自分のプロジェクトの仕様書の場所に合わせて書き換えてください。

逆に、仕様がNotionやチケットにしか無い場合、この層は空になります。そのときは「なぜ変わったか」は原理的に復元できません。

`pipelineLens.correlationPatterns` — 作業単位のまとめ方

["#(\\d+)", "([A-Z][A-Z0-9]+-\\d+)"]

ブランチ名・コミットメッセージ・PRタイトルからこの正規表現でIDを拾い、同じIDのものを1スレッドにまとめます。デフォルトで #123 と ABC-45（Jira形式）に対応。

チームでやるべきことが1つだけあるとすれば、ブランチ名にissue番号を入れることです。 これが無いと、git・GitHub・エージェントのログが最後まで繋がりません。ツールを変えても解決しない部分です。

`pipelineLens.sessionGapHours` — 作業セッションの区切り

既定 4（時間）。課題番号が無いときに、何時間あいたら「別の作業」とみなすかです。

小さくする（例 1）→ 細かく分かれる
大きくする（例 12）→ 1日単位くらいにまとまる

課題番号を使っているリポジトリでは影響しません。

`pipelineLens.historyLimit`

読み込むコミット数の上限（既定800）。重いリポジトリで遅ければ下げてください。

6. 他のデータソースを流し込む

エージェントのOTelトレース、CIのwebhook、スクリーンショット差分などは、リポジトリ直下の .pipeline-lens/external.jsonl に1行1JSONで追記すれば取り込まれます。

{"ts":"2026-07-02T10:15:00Z","kind":"agent_tool_error","actor":"claude-code","ref":"sess-9f2","correlationId":"101","title":"Edit failed: file changed on disk"}
{"ts":"2026-07-02T10:40:00Z","kind":"visual_change","actor":"playwright","ref":"checkout.png","correlationId":"101","surface":"/checkout","metrics":{"visualDelta":0.31}}
{"ts":"2026-07-02T11:00:00Z","kind":"ci_run","actor":"github-actions","ref":"ci-88","correlationId":"101","title":"e2e","outcome":"failure"}

必須は ts と kind だけです。使える kind：

spec_edit commit pr_open pr_review pr_reopen pr_merge pr_close ci_run agent_session agent_tool_error agent_permission_denied visual_change

outcome は success / failure / pending / neutral。

データソースが変わってもここだけ差し替えれば済みます。 取り込みは source 単位で置き換わるので、gitを読み直しても external が入れたイベントは消えません。

7. 困ったとき

症状	原因と対処
「git リポジトリを開いてください」と出る	gitリポジトリではないフォルダを開いています。サイドバーのボタンから開き直すか、初期化してください
アクティビティバーにアイコンが無い	インストール直後です。VS Codeを再起動するか、左端のアイコン列を右クリック→「Pipeline Lens」にチェック
ステータスバーに何も出ない	まだ読み込んでいないか、gitリポジトリではありません
何も表示されない	コミットが無いか、`historyLimit` の範囲外。サイドバー上部の 🔄 を押してください
◆（仕様変更）が1つも出ない	`pipelineLens.specGlobs` が自分の仕様書の場所と合っていません（⚙ から設定）
PR・レビューが出ない	🔄 を押してGitHub認証を通してください（4章）
全部が「作業セッション」になる	課題番号を使っていないリポジトリです。異常ではありません。細かさは `sessionGapHours` で調整できます（5章）
セッションが細かすぎる／粗すぎる	`sessionGapHours` を上下させてください（5章）
エージェントの commit が「人間」判定になる	コミットに `Co-Authored-By:` トレーラーが付いていません

判定ロジックの優先順位は トレーラー → アカウント名 → メッセージの推測 です。トレーラーが最優先なので、チームで Co-Authored-By: を規約にするのが最も確実です。

8. コマンドパレットから使う場合

GUIだけで完結しますが、Ctrl+Shift+P からも同じ操作ができます。

コマンド	内容
`Pipeline Lens: タイムラインを開く`	タイムラインを開く
`Pipeline Lens: 履歴を読み込み直す`	読み込み直す（GitHub認証もここで）
`Pipeline Lens: 設定を開く`	設定画面を開く

9. 開発者向け

VS Codeを使わずCLIで動かす

npm install && npm run build

node dist/cli.js ingest  --repo <リポジトリのパス>   # 取り込み
node dist/cli.js report  --repo <リポジトリのパス>   # ターミナルに要約
node dist/cli.js preview --repo <リポジトリのパス>   # ブラウザで開けるHTMLを生成

preview は拡張と同じ描画コードを使ったスタンドアロンHTMLを出します。PMなど非エンジニアに見せたいときはこれを渡してください。

デモを動かす

2種類のダミーリポジトリで試せます。

# 課題番号あり。実装開始後に仕様が2回変わるケース入り
bash demo/make-fixture.sh
node dist/cli.js ingest --repo .demo/sample && node dist/cli.js report --repo .demo/sample

# 課題番号なし・数ヶ月の履歴・同一人物が2つのメールアドレスを使用
bash demo/make-noconvention-fixture.sh
node dist/cli.js ingest --repo .demo/noconvention && node dist/cli.js report --repo .demo/noconvention

後者は実際に報告された不具合（全部が1つの塊になる／同一人物が重複する）の再現ケースです。

その他

npm test         # テスト11件
npm run build    # ビルド
npm run watch    # 監視ビルド
npm run package  # VSIX作成

10. 設計

なぜVS Code拡張なのか

決め手は認証です。vscode.authentication でGitHubトークンがOAuthアプリ登録もPAT発行もなしに取れます。単体アプリ版はどう作っても「トークンを用意する」手順が価値の前に挟まります。

代わりに非エンジニアへ共有できないので、コアを vscode 非依存に分離してあります（CLIが vscode を external 指定せずにバンドルできることがその証明）。Web版が必要になったらデプロイ先の追加であって、書き直しにはなりません。

5つの層

層	問い	実装
プロセス	誰がいつ何を	`core/ingest/git.ts`, `github.ts`
帰属	AIか人か	`core/actors.ts`
エージェント実行	何で躓いたか	`core/ingest/external.ts`
意図	仕様がどう変わったか	`core/ingest/specs.ts`
App / UI	画面がどう変わったか	`visual_change` イベント

2つの軸

すべてのイベントは core/types.ts の1つの形に正規化され、2つのキーで結合されます。

correlationId — 因果の軸。これが無いと4つのログはただ並んでいるだけで、UIをどう作っても繋がりません
surface — 空間の軸。画面・コンポーネント・ファイル。「この画面が時系列でどう変わったか」を引くための鍵

詰まりの判定

すべてイベントの実数で、モデルの判断は一切使っていません。数字はクリックで元イベントまで辿れます。エージェントについて「詰まった」と言う以上、根拠が検証可能でなければ信用されないためです。

判定項目：実装開始後の仕様変更 / CI連続失敗 / 変更要求レビュー / PR再オープン / 3回以上書き直されたファイル / エージェントのツールエラー・権限拒否。

内部の score はスレッドの並び替え専用です。評価点ではなく、UIにもそう表示していません。

状態

動作確認済み: git・仕様書の取り込み、external JSONL、詰まり判定、CLI、タイムライン描画、HTMLプレビュー。テスト11件（帰属判定・correlation抽出・glob照合・詰まり計算・jsdomでの描画）。

未検証: GitHub連携（core/ingest/github.ts）は型チェックとビルドは通っていますが、実トークン・実リポジトリでは未実行です。4章の手順で初めて実地に走ります。

Pipeline Lens

rkojima

Pipeline Lens

他のツールと何が違うのか

セキュリティとプライバシー

1. インストール

2. 使いかた（すべてクリック操作）

ステップ1: gitリポジトリのフォルダを開く

ステップ2: アクティビティバーのアイコンをクリック

ステップ3: 一覧から選ぶ

常に見える場所

2-1. ボタンの位置

3. 画面の読み方

上部（サマリー）

本体（スイムレーン）

クリックすると

3-0. 行ごとの出自表示

3-1. チームレポート（PM・EM・PL・スクラムマスター向け）

仕様との乖離 — いま直すべきもの

品質 — 書いたコードが残っているか

レビュー — 誰が負荷を負っているか

フロー — 仕事の流れ方

4. GitHub連携（PR・レビュー・CI）

5. 設定（ここが肝心）

pipelineLens.specGlobs — 仕様書の置き場所

pipelineLens.correlationPatterns — 作業単位のまとめ方

pipelineLens.sessionGapHours — 作業セッションの区切り

pipelineLens.historyLimit

6. 他のデータソースを流し込む

7. 困ったとき

8. コマンドパレットから使う場合

9. 開発者向け

VS Codeを使わずCLIで動かす

デモを動かす

その他

10. 設計

なぜVS Code拡張なのか

5つの層

2つの軸

詰まりの判定

状態

`pipelineLens.specGlobs` — 仕様書の置き場所

`pipelineLens.correlationPatterns` — 作業単位のまとめ方

`pipelineLens.sessionGapHours` — 作業セッションの区切り

`pipelineLens.historyLimit`