生成AIを仕事に入れて分かった、最初に売上をKPIにしない方がいい理由

生成AIを仕事に入れた直後は、本当に効果があるのか判断しづらく感じました。

CodexやClaude CodeのようなAI開発ツールを使うと、コードや文章のたたき台はすぐ出ます。しかし、その時点では売上も問い合わせも増えていません。むしろ、出力の確認や指示のやり直しが増えることもあります。

うにラボでブログ運営とWeb開発を続ける中で、最初に起きた変化は売上ではなく、作業を始めやすくなり、修正を繰り返しやすくなり、同じ依頼を再利用できるようになることでした。

先に結論

生成AI活用の最初のKPIは、売上よりも次の3つを見ています。

1. 作業時間
2. 着手率
3. 再利用率

売上を見ないという意味ではありません。AIを使う運用がまだ固まっていない時期に、売上だけで継続可否を決めないということです。

実際にAIを使っている作業

うにラボでは、AIを単発の質問相手ではなく、ブログ運営と開発の作業工程に入れています。

• ブログ記事の構成、下書き、既存記事の修正
• Next.jsやPythonのコード作成
• Gitの差分確認とコードレビュー
• 公式情報や既存データの整理
• Search Consoleを見たあとの改善候補の整理
• 変更対象、確認項目、開発タスクの整理

ただし、AIの出力をそのまま公開したり、そのまま本番へ反映したりはしていません。

記事なら一次情報を確認し、コードなら型チェック、ビルド、差分、公開画面を確認します。AIに任せているのは、主にたたき台と整理です。最終判断は人間側に残しています。

最初に表れたのは売上ではなく、作業の変化だった

生成AIを入れて先に変わったのは、次のような部分でした。

• 白紙から書き始める代わりに、下書きを直すところから始められる
• 修正案を複数出し、比較して選べる
• 変更後に、関連ファイルや確認項目を洗い出せる
• 一度使えた指示を、同じ種類の作業でもう一度使える

実際、サイト改善では、記事を書く作業だけでなく、コード修正、Gitの差分確認、ビルド、本番確認までがひと続きです。

AIが下書きを速く作っても、確認で問題が見つかれば修正が必要です。それでも、修正点を伝えてもう一度出力させられるため、修正サイクルを回しやすくなることには早い段階で価値がありました。

売上を最初のKPIにしなかった理由

ブログ記事を修正した日と、検索表示や問い合わせが変わる日は同じではありません。

実際に、Search Consoleの数値をもとに料金ページのタイトル、H1、導線を修正したときも、改善直後には成果を断定しませんでした。Search Consoleで表示1,077回・クリック2回・CTR 0.2%だったページを改善した記事では、修正前の実測値と変更内容までを記録し、改善後の成果はデータがたまるまで書かない形にしています。

このように、売上や検索流入は結果が出るまで時間がかかり、AI以外の要因も混ざります。

一方、作業時間、着手率、再利用率は、その作業を行った時点で確認できます。初期の運用改善を判断するには、こちらの方が近い指標でした。

KPI 1：作業時間

作業時間は、AIへ依頼してからではなく、人間の確認と修正が終わるまでで測る必要があります。

AIが数秒で文章を出しても、事実確認に時間がかかれば時短とは言えません。

実際、AIを活用していた記事に「1,100円で6か月延長できる」という確認できない制度が混ざったときは、公式FAQを102件保存して確認し、該当箇所だけでなくページ構成ごと修正しました。詳しい経緯は、AIの誤情報を一次情報102件で確認した記事にまとめています。

この作業を「AIの出力時間」だけで測れば速く見えます。しかし、実務で測るべきなのは、確認と手戻りを含む完了時間です。

KPI 2：着手率

小規模な事業では、重要でも緊急ではない作業が後回しになりやすくなります。

たとえば、既存記事の見直し、Search Consoleの数字から改善候補を出す作業、開発手順の整理です。どれも必要ですが、白紙から始めると重い作業です。

AIで最初の整理を作れると、人間は「何を書くか」ではなく、「この事実を使ってよいか」「この変更を採用するか」から始められます。

そのため、件数を増やしたかだけではなく、後回しにしていた作業を実際に開始し、確認まで終えられたかを見ます。

KPI 3：再利用率

一度だけ便利だった使い方より、同じ種類の仕事でもう一度使った指示の方が、運用上は価値があります。

うにラボの開発では、変更のたびに確認する項目を手順として残しています。

• 変更対象を限定する
• Gitの差分を見る
• 型チェックとビルドを行う
• pushで何が起きるか確認する
• 本番反映後は公開画面を見る

また、GitHubでレビューするだけの変更とAmplifyへデプロイする変更を分けるため、feature・dev・mainの役割も整理しました。AmplifyとGitの運用を変えた記事で書いたように、再利用できるのはプロンプトの文章だけではありません。確認手順や、どこまでAIへ任せるかという境界も再利用できます。

同じ型を次の作業でも使えた回数が増えているなら、AIが単発の試用から実務の一部へ変わり始めています。

数字がない部分は、効果があったことにしない

現時点で、AI導入前後の作業時間、着手件数、再利用回数を同じ条件で比較した数値は確認できていません。

そのため、「作業時間が半分になった」「生産性が何倍になった」とは書けません。

確認できているのは、AIを使った記事で誤情報が見つかり、公式FAQ102件まで戻って修正したこと、Search Consoleの実測から修正対象を決めたこと、GitとAmplifyの運用を変更したことです。

KPIを置くなら、これから同じ作業単位で記録し、比較できる状態を作る必要があります。

まとめ

生成AIを仕事に入れて最初に見るべきなのは、売上がすぐ増えたかではありません。

• 確認と手戻りを含む作業時間がどう変わったか
• 後回しだった作業に着手できたか
• 指示や確認手順を別の作業でも再利用できたか

この3つを先に見ます。

売上や問い合わせは、その運用が回った先で確認する指標です。最初から売上だけを追うより、AIを使う作業の型ができているかを確かめる方が、継続するか、使い方を変えるかを判断しやすくなりました。