Rosarium

AI設計原則 / 公開物 / principle

第2章 AI導入は効率化とは限らない

要件をAIで文章化した後、理解・説明・合意形成が不足して手戻りになった経験から、業務全体の効率を考えます。レビューしやすさ、確認コスト、総工数と経過時間を区別した評価、改善後の業務の流れを扱います。

公開:最終更新:

更新履歴

  1. 改訂

    手戻りした実務経験をもとに、レビューしやすさ・理解・説明・合意と、工数・経過時間を区別したAI導入評価を整理した

  2. 公開

システム設計 / 生成ai / aiエージェント / hitl / aiガバナンス

読む目的: AI導入・責任・評価 / 自然言語サービス・RAG・ナレッジ

このBookの目次(全5章)
  1. 全体構成
  2. 第1章 AIに仕事を任せても、責任は消えない
  3. 第2章 AI導入は効率化とは限らない
  4. 第3章 AIに聞くことと、AIに仕事を任せることは違う
  5. 第4章 AIに任せない条件を、先に決める
  6. 第5章 AI時代、人間には「判断する力」が求められる
目次
  1. AIが速くても、仕事が速いとは限らない
  2. 実際に手戻りした経験
  3. 中間成果物と最終成果物を分ける
  4. 成果物の品質には、レビューしやすさも含まれる
  5. 総工数と完了までの経過時間を見る
  6. 生成だけを見ると改善に見える仮例
  7. 人間によるレビューにもコストがある
  8. 自分の言葉で説明できることを確かめる
  9. 失敗後に変えた業務の流れ

現在位置:第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が理解したように見える文章を生成することと、自分が理解していることは別です。説明できない部分は根拠を確認し、必要なら関係者へ問いを戻します。言い回しを整えるだけで、理解を代替しません。

失敗後に変えた業務の流れ

生成を完了条件にせず、次の流れで考えるようになりました。

  1. 要件を整理する
  2. AIで構造化する
  3. 自分で内容を確認し、理解する
  4. 必要に応じて図表化し、他人がレビューできる形へ変換する
  5. 自分の言葉で説明できるか確認する
  6. レビュー・審議で論点を確認し、合意する

AI導入は、一工程へのツール追加ではなく、AIを含む業務の開始から完了までを設計し直すことです。再設計しても必ず効率化するとは限らないため、導入後の結果を評価し、必要なら既存の方法へ戻すことも選びます。

次の第3章 AIに聞くことと、AIに仕事を任せることは違うでは、仕事に必要な情報をAIが利用できる条件を考えます。