AIの価値を測る前に、その仕事の完了を一行で言えるか

月曜の朝、請求画面を開くことがあります。

先月より増えた利用。 席数。 トークン単価。

数字は見えます。 でも、隣の席の実感と合いません。

「使っているのに速くならない。」 「安いモデルにしたのに、手戻りが増えた。」 「高いモデルにしたのに、説明できない。」

このずれは、性能不足だけではありません。

測る前に、仕事の完了が空だからです。

OpenAIは2026年7月17日、AI投資の測り方を席数やトークン単価から「Useful Intelligence per Dollar」へ移す枠組みを示しました。有用な仕事量、成功タスクの完全コスト、依存可能性、規模を広げたときの価値、という四つの問いです。7月14日前後には投資管理の話題も出ています。

ただ、ここでやりたいのは、その枠組みを社内KPIへ移植することではありません。

先に残すのは、完了の一行です。

席数が見せるもの、見せないもの

席数は、「誰が触れるか」を見せます。 単価は、「一回いくら」を見せます。

どちらも捨てなくていいです。 どちらも、仕事の価値までは見せません。

見せないものは、だいたい現場に落ちています。

途中で捨てた下書き。 人が直した時間。 再試行の回数。 顧客に出せなかった文面。 「一応確認した」だけの会議。

完了が定義されていないと、これらは勘定に入りません。 入らないまま、安い／高いだけが残ります。

安いモデル信仰と、高額モデル信仰は、同じ穴に落ちます。 穴の名前は、完了の決まりがないことです。

「レポートができた」では、まだ完了ではない

完了を「レポートができた」と書くと、また空になります。

できた、は状態ではありません。 誰が、何をもって、使えると判断したか、が抜けます。

現場の言葉にすると、こんな一行です。

「初回提案の下書きが、金額以外を埋めた状態で、営業担当の確認待ちになった。」 「問い合わせ一次回答が、個人情報を含まない形で送信可能な文になった。」 「週次メモが、決定事項と保留事項に分かれ、共有フォルダに置かれた。」

AIが書いたかどうかは、ここでは二の次です。

人が受け取れる状態まで含めることです。

完全コストを測るなら、再試行と人の確認もここに入ります。 入らないなら、それはAIの価値ではなく、生成回数の記録です。

全部測ろうとすると、指標作りが仕事になる

全部の仕事を一度に測ろうとすると、指標作り自体が仕事になります。

週の優先順位としては、一つで足ります。

測る仕事を一つ選ぶ。 完了を一行で書く。 失敗条件を一行で書く。 そのうえで、再試行と人確認の時間をざっくり残す。

失敗条件の例です。

顧客名や金額が混ざる。 参照元が不明な断定が入る。 担当者が「送れない」と判断する。

失敗条件があると、安いモデルで回数だけ稼ぐことが、成果に見えなくなります。

モデルの切り分けそのものは、モデルが三つに分かれた週に、先に決めるのは性能比較ではないに任せます。こちらで残すのは、切替の前に完了を置く、という順序だけです。

「依存できる」は、便利だった、とは違う

枠組みにある依存可能性を、現場語にするとこうです。

同じ仕事を、同じ条件で、何度頼んでも、人が受け取れるか。

一度うまくいっただけの成功は、再現ではありません。 再現がないまま規模を広げると、請求だけが増えます。

広げてよいのは、完了定義がある仕事です。 完了が空の仕事を広げると、迷いも広がります。

実験枠と本番枠の話は、AI予算を増やす前に、実験枠と本番枠の境界を一行で分けるに任せます。測定と予算は別物ですが、入口は同じです。完了があるか。

再現を見るときも、成功例の保存より、失敗条件の固定が先です。

成功例だけ残すと、上手くいった日の条件が神話になります。 失敗条件が残っていると、月曜の担当が変わっても同じ線で切れます。

会議でよく見る、三つの逃げ道

一つ目。指標を先にきれいにする。

スコアカードを移植し、ダッシュボードを整える。 見た目は整います。 完了は空のままです。

二つ目。時間短縮だけを見る。

時間だけで測ると、手戻りが見えなくなります。 短縮は結果の一部であって、仕事の完了そのものではありません。

三つ目。成功事例の数字を借りる。

他社や提供元の数値は、条件が違います。 借りる前に、自社の完了定義が必要です。

逃げ道を閉じるのは、難しい計算ではありません。 一行です。

完了が空のまま、週次会議に入ると

完了が空のまま週次会議に入ると、会話はだいたいこうなります。

「利用率は上がった。」 「でも実感がない。」 「だからモデルを変えよう。」 「いや、プロンプトを変えよう。」 「そもそも全社に広げすぎでは。」

どれも、部分的には正しい可能性があります。 ただ、並べても結論は出ません。

結論を出すには、測る仕事を一つに戻す必要があります。

その仕事の完了は何か。 失敗は何か。 人の確認はどこか。

この三つが無い会議は、ツール会議です。 仕事会議ではありません。

週の優先順位として、ツール会議を減らすなら、完了の一行から始めてください。

完全コストに、入れるものと後回しにするもの

入れるものです。

生成そのものの費用。 再試行の回数と時間。 人の確認時間。 使えなかった出力を捨てる時間。 修正して送り直す時間。

後回しでよいものです。

全社の席数の合計だけ。 モデルのベンチマーク順位。 「便利だった」という感想。 他社事例の削減時間。

後回しのものを先に見ると、会議は長くなります。 入れるものを先に見ると、1業務の話に戻ります。

営業の現場で書くなら、この粒度

抽象のまま残すと、また席数に戻ります。 具体に落とします。

初回メールなら。

完了は、宛先・要件・次の質問が入り、金額と納期以外が埋まった文が、担当者の確認待ちになった状態。 失敗は、相手の社名が違う、約束していない納期が入る、社内メモが混ざる、あたりです。

失注メモの整理なら。

完了は、失注理由が三つ以内に整理され、次に人が決める論点が一行で残った状態。 失敗は、理由が十個並ぶ、誰が読むか不明、次の一手が「頑張る」だけ、です。

週次の社内共有なら。

完了は、決定と保留が分かれ、共有先が一人以上決まって置かれた状態。 失敗は、長文のままフォルダに沈む、読む人が「あとで」と言う、です。

この粒度があると、安いモデルか高いモデルかの話は、仕事ごとに短くなります。

月曜に残すのは、この問いだけ

週の始まりに残す問いは、次の一つで足ります。

この仕事の完了を、一行で言えるか。

言えないなら、ROIの話はまだ早いです。 言えるなら、初めて再試行と人レビューを足せます。

言えたあとにやることも、多くありません。

完了定義を紙かメモに残す。 失敗条件を一行足す。 一週間だけ、再試行と人確認を雑でよいので記録する。

雑でよい、が大事です。 精密な原価計算の前に、決まりのない部分を減らします。

記録の粒度も、粗くて足ります。

再試行は、0回 / 1回 / それ以上。 人確認は、5分未満 / 15分前後 / それ以上。 結果は、使えた / 直して使った / 捨てた。

これだけあれば、「安いのに高い」「高いのに安い」の感覚を、次の週の判断に残せます。 感覚のまま残さないことが、測定の入口です。

AIの価値を測る前に、その仕事の完了を一行で言えるか。

測り方を増やす前に、測る対象を細くしてください。 細い完了定義があるほうが、数字は短く、判断は速くなります。

完了の一行が残ると、請求画面を見る朝も変わります。

「いくら使ったか」の前に、「何が終わったか」が口に出ます。 終わっていない仕事に、席数を足しても、説明は増えません。 終わった仕事に、再試行と人確認を足すと、初めて数字が仕事の話になります。