AIで生成は速くなったのに仕事が終わらない｜確認・修正を含めて工数を測る方法

「AIで下書きがすぐに作れるようになったのに、承認を得て仕事が終わる時刻は変わらない」と悩んでいませんか。これは、AIの生成時間が短縮されても、人の確認や他者のレビュー待ちを含めた全体の完了時間は別物だからです。

実際の税務業務の事例でも、全体の経過時間と人が直接操作する時間を区別する重要性が指摘されています。また、AIの待機中に別の作業を進めると、本来かかった時間が正確に測りにくくなります（資料作成の実測ではありませんが、開発者実験の報告もあります）。

この記事では、資料作成の工程を「AIの実行」「人の修正」「レビュー待ち」などに分けて記録し、完了が遅れる原因を見つける手順を解説します。記録をもとに「資料の納期を早める」か「自分の実作業を減らす」のどちらを優先し、どう改善すべきかを判断できるようになります。

資料が完成した時点と比較条件を決める
生成・確認・修正を時刻付きで記録する
短くなった工程が承認時刻を動かすか調べる
商品比較資料の一件で区間と待ちを読む
納期と担当者の作業時間から次の改善を選ぶ
よくある質問
AIを組み込む仕事の流れづくりをご支援します

資料が完成した時点と比較条件を決める

AIを使って資料作成がどれくらい効率化されたかを正確に測るには、まず「どの状態をもって資料が完成したとするか」という完了条件と、AI導入前後で比較するための前提条件をそろえる必要があります。AIによる下書きの生成が短時間で終わっても、最終的な承認・完了が早まらない原因を探るためには、この条件定義が測定の第一歩となります。

工数測定で特に注意すべきなのは、AIが文章や図表の案を出力した瞬間を「作業の完了」とみなさないことです。導入前後の作業時間を比較する際は、対象とする具体的な業務を同じにしたうえで、「人間が内容を検査し、必要な修正を加えた後に完成する」という条件をそろえなければならないと実務解説でも指摘されています。

また、「どのような状態になれば終わりなのか」という停止条件も明確にしておく必要があります。取り組む課題の難易度や、完成した資料に求める品質基準に違いがあると、時間比較自体が難しくなってしまうからです（METRによる報告）。AIに作業を任せる仕事では、どのような結果が得られれば要件を満たしたと評価し作業を終了するのかという条件と、作業の複雑さと応答待ち時間との交換条件をあらかじめ整理しておくことが重要とされています（Anthropicによる解説）。

そのため、読者が実際に工数比較を行う際は、次のような手順で条件を定義してください。まず、「競合他社との商品比較資料」や「週次の進捗レポート」など、毎回決まった目的や分量で作成している具体的な資料を対象として選びます。次に、「部門長に提出し、内容の差し戻しがなくなった時点」や「顧客へそのままメールに添付して送れる時点」など、同じ成果物として受け入れるための具体的な完成条件を言語化し、メモに書き出して手元に置きます。

AIを使わない従来の手順とAIを使う場合とで、この「同じ資料を、同じ品質の完成状態に持っていく」という前提を固定することで、初めて意味のある工数の比較が可能になります。成果物に対する評価条件が定まったら、次はその基準に従って実際の作業工程を記録していきます。

生成・確認・修正を時刻付きで記録する

資料の完成条件を揃えたら、実際の作業工程を時刻付きで記録していきます。AIを業務に取り入れた場合、作業開始から終了までの「全体の経過時間」を漫然と測るだけでは、AIの生成が速くなったのに仕事が早く終わらない原因を見つけることはできません。ここで重要なのは、読者が手書きの時刻表やストップウォッチで測るのではなく、AIやシステムに各工程の開始・終了を出させ、自動で記録させる仕組みを利用することです。

AIの実行時間を正確に測るには、AIの仕組みに応じた工夫が必要です。作業の開始時に一度だけ現在時刻を伝えても、AIは自律的な時計を持たないため、終了時刻や経過時間を正確に推測・出力することはできません。そのため、アプリケーション側でAIの実行開始と出力完了の二時点を取得して差分を測定するか、AIモデルの関数呼び出し（Function Calling）を応用し、AI自身に「時計ツール」を使わせる設計が必要です。実行環境側で現在時刻を取得し（datetime.now(timezone.utc)など）、AIに各工程の開始・終了時に時計を呼び出させて記録できます。時計ツールが使えるAIには「工程を始める時と終える時に時計を読み、工程名・時刻・取得元を表へ追記して。人の確認や中断は私が知らせた時だけ記録して」と依頼します。

一方で、「人が事実確認や手直しをする時間」や「上司のレビュー時間」は、AIからは直接観測できません。こうした未観測の時間をAIに勝手に推定させるのは不正確なため、取得元を明確にする必要があります。このとき、編集画面を開いてから提出するまでの全期間を「人の直接作業」と単純に同一視してはいけません。作業中に中断や別業務が入れば、実作業を別に観測する必要があるからです。

なぜこのように取得元を分け、時間を厳密に区別するのでしょうか。税務業務にAIを適用した事例において、全体の経過時間と人が直接操作した時間を区別することの重要性が報告されています。この区別を資料作成の計測にも応用できます。AIの処理待ちが発生すると、人はその隙間にメール返信などの別作業を進めがちです。開発者を対象とした研究でも、AIの処理待ち中に別課題を進めるため、課題ごとの正確な時間報告が難しくなるという測定上の問題が指摘されています。そのため、人の作業は「本人の切り替え通知（開始・終了・中断の入力）」、上司の動きは「提出・承認などのシステムイベント」を起点として区間を確定し、AIの待機時間と切り分ける必要があります。

これらをAIやシステムから出力させると、次のような取得元が明確な区間データが得られます。提出から最終承認までを一つの「レビュー待ち」にまとめず、細分化して記録している点にも注目してください。

10:00〜10:15：プロンプトの入力と構成検討（本人の作業開始入力〜AIへの送信操作で取得）
10:15〜10:25：AIの下書き生成と待ち時間（AIによる時計ツールの呼び出し、またはアプリが自動取得。人は別件を処理）
10:25〜10:45：生成された下書きの事実確認と手直し（本人の編集開始〜提出の通知で取得。中断・別業務があれば除く）
10:45〜13:00：上司への提出とレビュー待ち（提出イベント〜上司のレビュー開始イベントで取得）
13:00〜13:10：上司のレビュー（上司のレビュー開始〜フィードバック返却のシステムイベントで取得）
13:10〜13:20：担当者の修正（本人の修正開始〜修正完了の通知で取得。13:20に上司が最終承認）

このように、どの工程がいつ始まりいつ終わったのかを取得元付きで分離することで、AIによって作業のどこが短くなり、どこに待ち時間や新たなボトルネックが発生しているのかが正確に可視化されるようになります。

短くなった工程が承認時刻を動かすか調べる

前節で各工程の開始時刻と終了時刻を記録しました。次はこの記録を使って、作業を短縮したのになぜ最終的な承認が早まらないのかを分析します。

ここで着目すべきは、工程ごとの「依存関係」です。製造工程の時間調査に関する解説では、全体の完了時間は並行する複数の作業時間を単に足し合わせたものではなく、各作業の開始・終了時刻と、どの作業が終わらないと次へ進めないかという依存関係によって決まると説明されています。短縮した作業が最終的な完了時刻を前倒しできるのは、それが全体の進行を制約している工程であった場合のみです。この製造業における考え方は、AIを使った資料作成の工程管理にも応用できます。

資料作成における依存関係とは、「AIの下書きが終わらなければ人が修正できない」「人の修正が終わらなければ上司がレビューを開始できない」といった作業の順序を指します。仮にAIを使って下書きの生成工程を大幅に短縮できたとしても、その直後に次の工程がすぐに始まらなければ、仕事全体の完了時刻は動きません。たとえば、上司が資料をレビューするタイミングが「定例会議のある夕方」と決まっていたり、忙しくて提出から数時間放置されたりする場合、下書きの提出がどちらも予定のレビュー開始時刻より前なら、最終的な承認時刻は同じになります。

METRの開発者実験では、AIの処理待ちに別の課題を進める例が報告されています。これにより担当者自身の別の仕事は片付くかもしれませんが、対象となっている資料の承認時刻が早まるわけではない点に注意が必要です。

また、AIの出力品質を上げようとして、プロンプトの調整や再生成、人の目による細かな確認を何度も繰り返すことも承認時刻に影響します。AIを含む多段の作業プロセスには品質と遅延のトレードオフがあり、単純に確認や修正の段階を増やせば良い結果になるとは限らないと指摘されています。

ご自身の仕事で承認時刻が動くかどうかを判定するには、時刻付きの記録を振り返り、「AIの作業が短縮された分だけ、次工程（人の修正や上司のレビュー）の開始時刻が前倒しになっているか」を確認してください。もし次の工程の開始予定が特定の日時に縛られていたり、他者の都合で待機時間が発生していたりするならば、生成スピードの向上は完了時刻を動かす直接的な要因にはなりません。まずは作業記録から、どの工程と待ち時間が仕事の進行を制約しているのかを見極めることが重要です。

商品比較資料の一件で区間と待ちを読む

前節までに整理した依存関係の考え方を、商品比較資料を作成する架空の通し例に当てはめて、区間ごとの時間と待ちを検算してみましょう。なお、以下の時刻は計算手順を示すための架空の数字であり、実際の実測値やAIの導入効果を示すものではありません。

先行節で挙げた10:00からの記録を引き継ぎ、レビュー待ちから最終承認に至るまでの時刻を次のように設定します。

10:00〜10:15（15分間）：プロンプトの入力と構成検討（人の実作業）
10:15〜10:25（10分間）：AIの下書き生成（処理待ち）。並行して別件のチャット対応
10:25〜10:45（20分間）：下書きの事実確認と手直し（人の実作業）
10:45〜13:00（135分間）：上司へ提出し、フィードバックを待つ（レビュー待ち）
13:00〜13:10（10分間）：上司が資料のレビューを実施（他者の作業）
13:10〜13:20（10分間）：フィードバックに基づく最終的な修正（人の実作業）
13:20：上司が再確認し、最終承認（完了）

まず、担当者の作業時間と全体の経過時間を分けて計算します。時間管理に関する解説では、同じ一人の作業者が09:00〜10:00と09:30〜10:30にそれぞれ別の作業を行った場合、記録の合計は120分になりますが、時間の重なりを除いた経過時間は90分として計算されます（重複する時間記録の解説）。ここでは区間の重複を除く計算だけを参考にします。

この考え方を10:15〜10:25の区間に当てはめると、AIが資料を生成している10分間と、担当者が別件のチャット対応をしている10分間は並行して進んでいますが、この区間の資料作成にかかる経過時間は10分間のままです。実際、開発者を対象とした研究でも、AIの待機中に別件を進めると課題別の作業時間を正確に報告しにくくなることが指摘されています（METRの開発者実験）。この数値例は商品比較資料の実測ではありません。

次に、この架空例の全体像を見てみます。10:00の着手から13:20の承認まで、資料が完成するまでの全体の経過時間は200分間です。しかし、この商品比較資料に対する担当者自身の直接的な実作業は、最初の15分間、手直しの20分間、そして最終修正の10分間を合わせた合計45分間にすぎません。

ここで重要になるのが、完了を制約している工程の特定です。製造工程の解説では、並行する工程を単純に合算して完成までの経過時間とするのではなく、各工程の開始時刻と終了時刻を確認し、全体の完了を制約している工程を見分けることが求められます（製造工程の解説）。本記事では、この考え方を資料作成の架空例に当てはめています。

この視点で架空例を検算すると、資料の完成時刻を最も強く制約しているのは、10:45から13:00まで発生している「135分間のレビュー待ち」であることがわかります。仮に、高性能なAIを使って10分間の下書き生成や20分間の手直し時間を半減できたとしても、上司のレビュー開始時刻が13:00に固定されている限り、13:20という最終的な承認時刻は前倒しになりません。

このように、商品比較資料の一件を時刻付きの区間に分けて計算することで、AIを使う場合に短縮を検討できる「担当者の実作業時間（45分間）」と、全体の完了時刻を決定づけている「他者への依存や待ち時間（135分間）」の違いをはっきりと読み取ることができます。

納期と担当者の作業時間から次の改善を選ぶ

前節の商品比較資料の架空例では、資料が完成するまでの全体の経過時間200分のうち、担当者の実作業は合計45分間、他者によるレビュー待ちが135分間であることがわかりました。このように実際の工程と時間を切り分けて可視化できたら、次は自分たちが何を解決したいのかという目的に合わせて、改善する対象を選びます。主な着眼点は「全体の完了時刻（納期）を早めたいのか」、それとも「担当者自身の手間（実作業時間）を減らしたいのか」の二つに分かれます。

資料を提出・公開するまでの納期そのものを前倒しにしたい場合、AIによる生成速度をさらに上げるのではなく、仕事の進行を止めている待ち時間や確認工程の見直しが必要です。架空例の135分間にあたるレビュー待ちが制約になっているのであれば、上司との確認タイミングを早める工夫が求められます。また、AIの出力を完璧にしようとして、確認と修正を何度も繰り返すプロセス自体が全体の遅れを招いている可能性もあります。AIを含む多段の作業プロセスでは、品質を追求する一方で遅延や費用が増す場合があり、取り組む課題に応じてまずは単純な方法から始めるべきだと指摘されています。AIによる下書きの品質と、人間が求める最終的な完成条件との間に過剰な差がないか、あるいは不要な確認工程を減らせないかを確かめてください。

一方、資料の完成時刻自体は変わらなくても、担当者が直接手を動かす実作業（架空例の45分間）を減らし、別の業務に充てる余裕を生み出したい場合は、別の見方が必要です。全体の経過時間が近くても、人が直接操作している時間や経路が大きく異なる場合があることが、税務業務におけるAI活用の事例でも報告されています。実作業を削る際は、AIの処理待ち中に発生する「割り込み」にも注意を払う必要があります。AIに作業を任せている間に別件を進めると一見効率的に思えますが、AIの状況が気になって画面を監視するような予測不能な割り込みの負担は、単純な直接操作時間だけでは捉えきれません（前述の税務事例による指摘）。さらに、開発者を対象としたAI利用実験においても、AI待機中の別件作業や取り組む課題の品質差が正確な時間測定を難しくしており、実験で推定されたような作業の加速率をそのまま資料作成の実務へ移せるわけではないことが示されています（METRによる報告）。

AIを使って下書きの生成が速くなったのに仕事が終わらないと感じたときは、まずご自身の作業記録を見直してください。解決したいのは、承認や確認のプロセスを整理して「資料の納期」を早めることなのか、それともAIとの協働方法を見直して「自分自身の実作業や割り込み負担」を減らすことなのか。目的を明確にすることで、次にどの工程の何を変えるべきかという具体的な一手を選ぶことができます。

よくある質問

Q. 作業時間を比較する際、どのような状態を「完成」とすればよいですか？ A. AIが出力した下書きができた瞬間ではなく、必ず「人間が内容を検査し、必要な修正を加えた後の状態」を完成条件としてください。「上司に提出し、差し戻しがなくなった状態」など、AI導入前後で同じ成果物として受け入れられる具体的な条件をあらかじめ決めておくことが重要です。

Q. AIの待ち時間に別の仕事をすれば、資料作成の時間は短縮できたと言えますか？ A. 別件を進めるだけでは、資料作成の経過時間は短くなりません。担当者自身の別の仕事は片付くかもしれませんが、レビュー開始時刻が固定されている例では、資料の完成時刻は同じです。また、待機中に別件を進めると課題ごとの正確な時間が測りにくくなることや、AIの出力状況が気になって画面を監視するような「割り込み」の負担が生じることが研究事例でも指摘されています。

Q. 記録した結果、上司のレビュー待ちが一番長い区間でした。もっと生成が速いAIに変えるべきでしょうか？ A. AIの生成速度を上げるよりも、確認工程を見直す必要があります。全体の完了時刻を制約しているのが「他者のレビュー待ち」である場合、AIの生成時間だけを削っても、レビュー開始時刻が固定なら最終承認は前倒しになりません。資料の納期を早めたい場合は、上司の確認タイミングを早めるなどの工夫を優先して検討してください。

Q. AIの出力を完璧にしようとして修正を繰り返し、かえって時間がかかってしまいます。 A. まずは「どこまで修正すれば終わりなのか」という停止条件を見直してください。AIを含む作業において品質を追求して確認や修正の段階を単純に増やすと、かえって遅れを招く場合があると指摘されています。自分が求める完成条件とAIの下書きの間に過剰な差がないかを確認し、不要な修正工程を減らせないか検討することが大切です。