AIエージェントのIssueを工数ではなくトークン消費で見積もるのサムネイル（1ページ目）

AIエージェントのIssueを工数ではなくトークン消費で見積もるのサムネイル（2ページ目）

AIエージェントのIssueを工数ではなくトークン消費で見積もるのサムネイル（3ページ目）

AIエージェントのIssueを工数ではなくトークン消費で見積もるのサムネイル（4ページ目）

AIエージェントのIssueを工数ではなくトークン消費で見積もるのサムネイル（5ページ目）

AIエージェントのIssueを工数ではなくトークン消費で見積もるのサムネイル（6ページ目）

AIエージェントのIssueを工数ではなくトークン消費で見積もるのサムネイル（7ページ目）

AIエージェントのIssueを工数ではなくトークン消費で見積もる

Google Translate: 日本語英語

yubele

フォロワー 0人

最終更新: 2026/10/19

読む時間: 01:51

埋め込み用コード

通報

埋め込み用コード

通報

最終更新: 2026/10/19

読む時間: 01:51

課題: 工数で見積もると、AIチームのコストが読めない

スライド内容

複数のコーディングエージェントへIssueを割り当てるとき、規模を人間の工数で見積もっていた
「1項目あたり実装・テスト・確認で8往復」のような、人間の実装時間の前提がそのまま基準に入っていた
見積もりが実績と桁でずれ、分割するかどうかの判断も当たらなくなる
欲しいのは工数予測ではなく「このIssueをそのまま1エージェントに任せるか、分割するか」を着手前に決める基準

詳細説明

もともとはスクラムのストーリーポイントをそのまま持ち込んでいました。ただ、人間の実装時間を前提にした刻みだと、エージェントに任せたときの実績と桁でずれます。見積もりの目的も工数予測ではなく、1つのIssueをそのまま1エージェントに任せるか分割するかを着手前に決めることなので、基準そのものを作り直す必要がありました。

測った事実: コストはturn数×コンテキスト長で決まる

スライド内容

Claude Codeのセッション記録283件（2026-09-15〜2026-10-09）を集計した
課金対象トークンを入力換算で揃えた値を「実効トークン」と呼ぶ
内訳はキャッシュ読出 80.6% / 出力 9.5% / キャッシュ書込 9.9% / 素の入力 ≒0%
アシスタントturn数と実効トークンの相関（log-log）は 0.971、傾き 1.07
1 turnあたりの実効トークンは中央値 21.4k（p25 18.1k / p90 32.2k）

傾き1.07の読み方

わずかな超線形。長いセッションは1 turnあたりも高くつく。コンテキストが伸び続けるため。

詳細説明

そこで実際に測りました。Claude Codeのセッション記録283件、2026年9月15日から10月9日ぶんです。課金対象のトークンを入力換算で揃えた値を実効トークンと呼んでいます。内訳で目を引くのはキャッシュ読出が8割を占めることで、素の入力はほぼゼロです。そしてturn数との相関が0.971。つまりコストはおおむねturn数とその時点のコンテキスト長の積で決まります。

傾きがちょうど1ではなく1.07だったのもポイントです。わずかですが超線形で、長いセッションは1turnあたりの単価自体も上がります。コンテキストが伸び続けるからです。この性質があるので、見積もりは小さい側ではなく大きい側に寄せることにしています。

実効トークンの定義はコードに置いた

スライド内容

export function effectiveTokens(usage) {
  const [input, creation, read, output] = values;
  return input + 1.25 * creation + 0.1 * read + 5 * output;
}

係数はprompt cacheと出力の単価比
支配項はキャッシュ読出。一度読んだファイルは以降の全turnに乗り続ける

詳細説明

実効トークンの定義は文章ではなくコードに置いて、集計CLIから使っています。係数はprompt cacheと出力の単価比です。キャッシュ書込が1.25、読出が0.1、出力が5。支配項は読出で、一度読んだファイルはそのあとの全turnに乗り続けます。だから何を読ませるかの設計がそのままコストになります。

行数では見積もらない

スライド内容

+4657行のIssueは大半が生成済みCSVで、判断も依存もなかった
+26/-2行のIssueはskillの運用ルール設計を含み、往復が多かった
変更行数とトークン消費は相関しない

詳細説明

よくある誤解として、変更行数で規模を測る方法があります。実例として、4657行追加のIssueは大半が生成済みのCSVで、判断も依存もありませんでした。逆に26行追加2行削除のIssueは運用ルールの設計を含んでいて往復が多かった。行数とトークン消費は相関しません。

ポイントは1/2/3/5/8/13/21の7段階だけ

スライド内容

SP	想定turn数	実効トークン目安	性質
1	〜10	〜0.2M	1ファイル数行、判断なし
2	〜20	〜0.4M	小さな変更＋テスト
3	〜40	〜0.8M	数ファイル。方針は確定
5	〜90	〜1.9M	設計判断を1つ含む（標準サイズ）
8	〜160	〜3.4M	複数レイヤー、または調査が独立して必要
13	〜350	〜7M	不確実性が高い、または複数リポジトリ
21	350超	7M超	見積もれていない状態の表明

実測のturn数分布（p10 21 / p25 49 / p50 89 / p75 158 / p90 349）はこの刻みとほぼ一致した。

詳細説明

刻みは1、2、3、5、8、13、21の7段階だけにして、中間値や範囲指定は使いません。各段に想定turn数と実効トークンの目安を置いています。5が標準サイズで、実測セッションの中央値にあたります。実測のturn数分布を並べると、p50が89、p75が158、p90が349で、この刻みとほぼ一致しました。

決め方: 完了条件の数×3に係数を掛ける

スライド内容

検証可能な完了条件の数 N を数える。曖昧な条件は数えない（数えられないなら21）
基準turn数は N × 3
触るファイルが事前に特定できていない → ×2、変更対象が2リポジトリ以上 → ×2
外部仕様の確認 / 実環境での確認 / 大きい生成物を読む → それぞれ ×1.5
小さい側に落ちたら大きい方のSPを選ぶ

詳細説明

決め方は、まず検証可能な完了条件の数を数えます。曖昧で数えられないなら、それは見積もれていない状態なので21です。次に基準turn数を出して、不確実性の係数を掛けます。ファイルが特定できていないと2倍、2リポジトリ以上で2倍。外部仕様の確認や実環境での確認、大きい生成物を読む場合はそれぞれ1.5倍です。

最初に置いた N×8 は外れていた

スライド内容

当初の基準turn数は N × 8。1項目あたり8往復を見込んでいた
8往復は人間の実装時間の前提だった。方針と触るファイルが確定している項目は1〜3往復で終わる
N × 3 に直し、不確実性は係数側（ファイル未特定 ×2 など）で表すことにした
係数表に割引は足さない。下げたいなら進め方を変える

詳細説明

最初に置いた式は完了条件の数の8倍でした。1項目あたり実装・テスト・確認で8往復という見込みです。これが外れていました。8往復は人間の実装時間の前提で、方針と触るファイルが確定している項目なら1から3往復で終わります。3倍に直して、不確実性は係数側で表すことにしました。係数表に割引は足しません。下げたいなら進め方を変えるという整理です。

一番の発見: 分割には1本あたり10〜20 turnの固定費がある

スライド内容

Issueを1本切るごとに、設計の再記述とリポジトリ・関連コードの再読込が乗る
つまり「大きいから分割する」は必ずしも安くならない
分割案を比べるときは、分割後の各turn数に固定費を足した合計と、1本で続ける場合を比べる
判断基準を人間工数から「文脈が既にセッションに載っているか」へ置き換えた
8〜13でも文脈が載っているなら続ける方を既定にし、載っていない場合に分割を前提にする

詳細説明

一番効いた発見がこれです。Issueを1本切るごとに、設計の再記述とリポジトリや関連コードの再読込で10から20turnが乗ります。つまり大きいから分割するというのは必ずしも安くなりません。分割案を比べるときは、分割後の各turn数に固定費を足した合計と、1本で続ける場合を比べる必要があります。判断基準自体を、人間工数から文脈が既にセッションに載っているかどうかへ置き換えました。

分割ルールは3回ひっくり返った

スライド内容

初版: 人間の操作（認証・権限・マージ）に依存する作業は、SPにかかわらず別Issueへ切り出す
2版: 承認で進められるなら切り出さない。SP 2以下を切り出すと固定費が作業本体と同等以上になって純損
3版: 切り出す前に、その作業が必要かを確かめる
3版の契機は、認証が要るからと切り出したIssueが、そもそも不要でnot plannedになった実例
切り出してから不要と分かるのが一番高い。固定費と起票の往復が丸ごと無駄になる

詳細説明

この固定費が分かったことで、分割ルールを3回書き換えています。初版は、人間の承認が必要な作業はSPにかかわらず切り出すというものでした。2版で、承認で進められるなら切り出さないに変えました。SP2以下を切り出すと固定費が作業本体と同等以上になって純損だからです。3版では、切り出す前にその作業が必要かを確かめるを足しました。契機は、認証が要るからと切り出したIssueが、そもそも不要だと分かってnot plannedで閉じた実例です。切り出してから不要と分かるのが一番高くつきます。

SPは進め方を変えれば下がる

スライド内容

調査と実装をIssueごと分ける → 調査で膨らんだコンテキストを実装側へ持ち込まない
探索をsubagentに出す → ファイル全文が親のコンテキストに残らない。キャッシュ読出80%への直接の対策
読むファイルと範囲をIssueに書く → 「ファイル未特定 ×2」を外す
完了条件を検証可能な形で書く → 確認の往復が減る
SP 8以上はセッションの区切りを意図的に置く

詳細説明

SPはこのまま進めたときのコストなので、進め方を変えれば下がります。調査と実装をIssueごと分ければ、調査で膨らんだコンテキストを実装側へ持ち込みません。探索をsubagentに出せば、ファイル全文が親のコンテキストに残りません。これはキャッシュ読出8割への直接の対策です。読むファイルと範囲をIssueに書けば、ファイル未特定の2倍を外せます。

見積もりと実績を突き合わせる仕組み

スライド内容

台帳（start / switch / stop）とセッション記録を突き合わせ、Issue単位にturn数と実効トークンを集計するCLIを足した
集計結果はGitHub ProjectのEffective Tokensフィールド（百万単位）へ反映する
改訂直後の3件は、改訂後の基準（9 / 15 / 30 turn）と実測（10前後 / 20前後 / 30前後）で桁が合った
母数3件なので、基準そのものの妥当性はまだ主張できない

詳細説明

基準を作ったら実績と突き合わせる必要があります。どのIssueを作業していたかの台帳とセッション記録を突き合わせて、Issue単位にturn数と実効トークンを集計するCLIを足しました。結果はGitHub Projectのフィールドへ百万単位で入ります。改訂直後の3件は、改訂後の基準と実測で桁が合いました。ただ母数3件なので、基準そのものが妥当だとはまだ言えません。