AIに作ってもらった成果物のレビューが、いちばん疲れる

「AI疲れ」って、たぶん人によって中身が違う

最近「AI疲れ」という言葉をよく見かけます。ただ、中身を聞いてみると人によってバラバラです。キャッチアップが追いつかない疲れ、ツールが増えすぎた疲れ、レビュー依頼が増えた疲れ。

私の場合、疲れの正体はもっと具体的でした。AIが作った成果物のレビューです。

そしてしばらく考えて、その理由は「AIが間違えるから」ではないことに気づきました。間違いを探す足場が消えたからです。この記事はその話です。

昔は「どこで間違えたか」がわかった

AIを使う前、私はモノを作るときにExcelで作業シートを作っていました。前提条件を並べたシート、計算過程のシート、それらを踏まえた最終成果物。

手間はかかります。でも一つ大きな利点がありました。最終成果物がおかしいとき、どこで思考を間違えたかを遡れるんです。前提が間違っていたのか、途中の変換で落としたのか、シートを見れば切り分けられました。

AIに頼むと、成果物だけが降ってくる

AIに頼むと、確かに速い。ただし出てくるのは完成品だけです。

「思考過程は見えるじゃないか」と言われそうですが、あれは独り言であって、成果物との対応関係が取れていません。「なるほどこう考えたのか」とは読めても、「この判断がここの出力に効いている」までは追えない。

結果、レビューでは完成品を頭から読み下して、自分の中で作業シートを再構築することになります。作ってもらったはずなのに、検算のために自分で作り直している。

抽象論のままだと伝わらないので、同じお題を3つのやり方でやってみます。

同じお題を、3つのやり方でやってみる

お題

• エンジニア単価：60万円/月
• 1人月 = 20営業日
• 実稼働率 80%（会議やレビューなどの間接工数を除く）
• 工数：設計10人日、実装30人日、テスト20人日

正解は 60人日 ÷ (20日 × 0.8) = 3.75人月 で 225万円。ここで「稼働率が消える」という、よくある間違いを起こしてみます。

実際の業務ではもっと工程も変数も多く、単価も工程ごとに違います。この規模なら私も間違えません。
ここで見たいのは金額の正しさではなく、間違いが起きたときに、どこを見れば見つかるかという仕組みの違いだけなので、極端に簡単にしています。

ケース1：昔のExcel

作業シートはこうなります。

シート	内容
前提	単価60万 / 20営業日 / 稼働率0.8
工数	設計10・実装30・テスト20
見積	=工数合計/20*60 → 180万円

金額がおかしいと気づいたとき、見るのは見積シートの数式1つです。/20 の後ろに *0.8 がない。前提シートには稼働率0.8がちゃんと書いてある。

つまり「前提は正しくて、参照が漏れている」と即座に切り分けられます。 探す場所は数式バーの1行だけです。

ケース2：普通にAIに頼む

こう頼みます。

単価60万/月、1人月20営業日、実稼働率80%、
工数は設計10人日・実装30人日・テスト20人日。
見積を作ってください。

出てくるのはこれです。

工程	工数(人日)	金額
設計	10	30万円
実装	30	90万円
テスト	20	60万円
合計	60	180万円

各行は破綻していません。日額3万円（60万÷20日）で計算すれば、どの行も正しい。思考の独り言にも「月額単価から日額を算出します」と書いてあって、これも間違ってはいない。

でも225万円になりません。

問題はここです。表のどこにも「稼働率を考慮しなかった」という痕跡がありません。
こちらは確かに80%と伝えたのに、成果物の上では最初から存在しなかったように見えます。

なので、やることは自分で前提を洗い出して、成果物と一行ずつ突き合わせる作業になります。それはもう、自分で作業シートを作っているのと同じでした。

ケース3：今の頼み方

同じお題を、二段階に分けます。まず計算させません。

（同じ条件）
まず、この見積で使う前提条件だけを表にしてください。
計算はまだしないでください。
私が指定していない前提を補った場合、
または指定した条件を使わなかった場合は、その旨も書いてください。

出てくるのはこれです。

前提項目	値	出所
月額単価	60万円	指定
月あたり営業日	20日	指定
日額単価	3万円	単価÷営業日で算出
工数合計	60人日	指定

稼働率の行がありません。

金額を1円も検算しないまま、この時点で間違いが確定します。
消えた前提を完成品から探すのは大変ですが、最初に並べさせておけば「ない」ことは一目でわかります。

ここで稼働率0.8を足させてから見積を作らせると225万円が出ますし、前提表を通した後の成果物は、前提表と突き合わせるだけでレビューが終わります。

3つを並べるとこうなります

	前提はどこにあるか	間違いに気づく場所	レビューの労力
ケース1（Excel）	前提シート	数式1行	小
ケース2（普通に依頼）	どこにもない	全行を自分で再計算	大
ケース3（今の頼み方）	前提テーブル	表の1行の欠落	小

やっていることは、Excelの前提シートをAIに書かせているだけです。成果物を良くする工夫ではなく、レビューする自分のための足場を先に作らせている、という整理になりました。

同じ発想でやっている、他の3つ

Plan mode を使う

Claude Code なら Plan mode で計画を先に確認できます。ケース3と同じで、判断が成果物に溶ける前に見るという話です。完成したコードのレビューは重いですが、「何をどの順で作るか」のレビューは軽い。同じ間違いを捕まえるなら軽い側で捕まえたい。

CLAUDE.md に書いておく

毎回口頭で指示していると、指示を忘れた回だけレビューが重くなります。前提を明示する・省略した条件があれば書く、といったルールをCLAUDE.mdに置いて、ケース3をデフォルトにしました。

一度に頼む量を、レビューできる量に合わせる

前提を見える化しても、量が多ければ結局読み切れません。作れる速度ではなく、自分が検算できる速度が上限だと割り切りました。速さを一部返上した形です。

正直なところ

「それはプロンプトが下手なだけでは」と言われそうですし、実際その要素はあると思います。

それに、これで疲れがゼロになったわけでもありません。レビューの手間を前工程に移しただけ、という見方もできます。

そして白状すると、こういう頼み方を毎回考えること自体が、そこそこ疲れます。
前提を出させるべきお題なのか、そのまま頼んでいいお題なのか、その判断を都度やっているわけで、
疲れの総量が減ったかと言われると自信がありません。

それでも、どこを見れば間違いが見つかるかが分かっている疲れと、全部読まないと分からない疲れでは、私にとってはだいぶ違いました。

みなさんはどうしていますか

同じような疲れを感じている方、どう対処しているか教えてもらえると嬉しいです。特に「前提を先に出させる」以外のアプローチを取っている方や、そもそもレビューの考え方から変えた方の話が聞きたいです。