記事AI設計原則 / 公開物 / principle
第2章 AI導入は効率化とは限らない
要件をAIで文章化した後、理解・説明・合意形成が不足して手戻りになった経験から、業務全体の効率を考えます。レビューしやすさ、確認コスト、総工数と経過時間を区別した評価、改善後の業務の流れを扱います。
2026年8月更新履歴
手戻りした実務経験をもとに、レビューしやすさ・理解・説明・合意と、工数・経過時間を区別したAI導入評価を整理した
読む目的: AI導入・責任・評価 / 自然言語サービス・RAG・ナレッジ
このBookの目次(全5章)
目次
現在位置:第2章・全5章
AI導入によって、業務全体は本当に効率化したのでしょうか。評価の対象は、AIが生成する工程だけでなく、確認・説明・合意を経て成果物が使える状態になるまでです。
AIが速くても、仕事が速いとは限らない
文章やコードを短時間で生成できても、後工程で確認や差し戻しが増えれば、仕事全体が速く終わるとは限りません。生成時間を短くすることと、業務を完了するまでの時間を短くすることは別です。
実際に手戻りした経験
要件定義した内容をAIに整理してもらい、Markdown形式の成果物としてまとめ、社内の設計レビューへ持ち込んだことがありました。文章化自体は速く進み、当時は「要件を整理する → AIでMarkdown化する → 完成」と考えていました。
しかし、その形式ではレビュー側が内容を理解しにくく、私自身も設計意図や論点を十分に説明できませんでした。有効な合意形成につながらず、やり直しが発生しました。
不足していたのは、整理された内容を自分で理解する工程と、相手が判断できる成果物へ整える工程です。読み手に理解を求めるだけでなく、判断しやすい形へ変換する責任が作成側にもありました。
AIを使わなければ防げた、と断定できる経験ではありません。問題は、生成された文章を、そのまま業務上の完成品として扱ったことにありました。
中間成果物と最終成果物を分ける
Markdownは、AIとの情報交換や要件の構造化、中間成果物として有用です。ただし、AIが扱いやすい形式、自分が理解しやすい形式、他人がレビューして判断しやすい形式は、一致するとは限りません。
文章で列挙した要件が正しくても、既存システムとの関係や変更前後の差分を追いにくければ、追加の説明が必要です。次工程で必要なのは全文を読むことなのか、構造を確認することなのか、選択肢を比較することなのかを考え、用途に合う表現を選びます。
成果物の品質には、レビューしやすさも含まれる
内容の正しさだけでなく、読み手が理解でき、確認対象、判断の根拠、確定事項と未確定事項が分かり、必要な比較ができることも品質条件です。
この失敗以降、文章だけで終わらせず、必要に応じてシステム構成図、処理フロー、変更前後の比較、比較表、入出力関係、責任分界へ変換するようになりました。図表化は、他者への説明と自分自身の理解確認の両方に使えます。関係や差分を表す過程で、曖昧な部分にも気付けます。
図を増やせば完成するわけでもありません。比較が必要なら表、流れを確認するならフロー、と次工程の判断に合う表現を選びます。
総工数と完了までの経過時間を見る
同じ品質・完成条件の仕事について、導入前後を比較します。AIの生成だけを、従来の仕事全体と比べません。
| 評価対象 | 確認すること |
|---|---|
| 総工数 | AI処理と、人間による確認、修正、形式変換、説明、手戻り、合意形成、必要時の復旧に掛かる作業量 |
| 完了までの経過時間 | レビュー・承認待ちや並行工程を含む、開始から利用・合意までの時間 |
| 品質 | 欠落、不整合、誤り、次工程でのレビューしやすさ |
| 運用 | 更新、監視、例外対応を続けるための負担 |
確認とレビューが同じ作業なら、二重に数えません。AIによって減った工程と増えた工程を分けて記録します。複数人の作業時間を合計した工数と、待ち時間や並行作業を含む経過時間は、同じ値にはなりません。
生成だけを見ると改善に見える仮例
次は説明用の仮例であり、今回の経験の実測値ではありません。同じ完成条件の仕事を従来方式では60分で終えられたとして、AI導入後に以下の工程時間が順に掛かる場合を考えます。
| 工程 | 仮の時間 |
|---|---|
| AI生成 | 10分 |
| 内容確認 | 20分 |
| 修正 | 20分 |
| 説明準備 | 20分 |
| 差し戻し対応 | 30分 |
| 工程時間の合計 | 100分 |
この仮例では、並行作業も待ち時間もないため、経過時間も100分になります。生成が10分でも、後工程が増えれば仕事は早く終わりません。この数字から実際の削減率やROIを主張することはできません。
人間によるレビューにもコストがある
確認は品質と安全性のために必要ですが、無料の工程ではありません。大量のAI出力をすべて最初から精査するなら、最初から人間が作業した方が速い場合もあります。
必要な承認を省くことが解決にはなりません。根拠や差分を添える、確認しやすい形式にする、生成範囲を小さくするなど、責任を持ってレビューできる仕事へAIの役割を縮めます。
誰が承認し、どの条件でAIを止め、人へ判断を戻すかは、AI出力の責任境界とHITLの設計対象です。その確認工程を含めても価値があるかを評価し、委任範囲へ戻します。範囲の選び方はAI適用可否と委任レベルの設計で整理しています。
自分の言葉で説明できることを確かめる
現在は、レビューへ進む前に、自分の言葉で次の点を説明できるかを確認しています。
- なぜこの要件が必要か
- なぜこの構造なのか
- 既存仕様へどう影響するか
- 何が未確定か
- どこにリスクがあるか
AIが理解したように見える文章を生成することと、自分が理解していることは別です。説明できない部分は根拠を確認し、必要なら関係者へ問いを戻します。言い回しを整えるだけで、理解を代替しません。
失敗後に変えた業務の流れ
生成を完了条件にせず、次の流れで考えるようになりました。
- 要件を整理する
- AIで構造化する
- 自分で内容を確認し、理解する
- 必要に応じて図表化し、他人がレビューできる形へ変換する
- 自分の言葉で説明できるか確認する
- レビュー・審議で論点を確認し、合意する
AI導入は、一工程へのツール追加ではなく、AIを含む業務の開始から完了までを設計し直すことです。再設計しても必ず効率化するとは限らないため、導入後の結果を評価し、必要なら既存の方法へ戻すことも選びます。
次の第3章 AIに聞くことと、AIに仕事を任せることは違うでは、仕事に必要な情報をAIが利用できる条件を考えます。