第5章 運用と改善

学習目標

• 業務のリスクに合わせてチェックリストを作り、誤りの重大度に応じて全件チェックとサンプルチェックを選ぶ。
• 品質・効率・定着・限界の4つの運用指標を定義し、指標ごとに分母と収集方法を決める。
• 失敗事例を発生段階ごとに分類し、再現と回帰テストを経て指示と資料を直す。
• 指示・資料・接続・モデル・製品の変化を、1つの変更管理手順で扱う。
• ベースラインと総運用コストで導入効果を測り、手作業への切り替えと運用終了の計画を立てる。

はじめに

あるチームが、顧客への返信の下書きを作るアシスタントを導入して3か月たちました。チーム長は四半期報告書に「月間利用回数が3倍に増加」と書きました。ところが、同じ期間に相談員たちの退勤時刻は変わりませんでした。調べると、相談員はアシスタントの下書きをほとんど書き直していました。利用回数が増えたのは、気に入る下書きが出るまで何度も再生成していたからです。数字はよく見えても、仕事は減っていませんでした。さらに悪いこともありました。2か月前に変わった送料無料の基準がアシスタントの資料に反映されていませんでしたが、相談員はどのみち下書きを書き直していたため、誰も気づかなかったのです。測らないものは改善できず、誤った測り方は見当違いの改善を招きます。

自動化は、展開した日が始まりです。資料は古くなり、業務も製品も変わります。この章では、結果をどうチェックするか、何を測れば実態が見えるか、失敗をどう改善につなげるか、変更時に何を守るか、そして効果をどう証明するかを扱います。最後に、自動化が止まったり、目的を失ったりしたときに、業務を継続する方法も扱います。第1章の設計書に書いた成功基準と、第2章のテスト質問セットを、この章で再び使います。

重要な概念

チェックリスト：リスクに応じて選ぶ項目

人が結果を確認するとき、何を見るかを決めていなければ、チェックは「単なる流し見」になってしまいます。だからといって、すべての業務に同じ長いリストを使うと、肝心な項目が埋もれます。チェックリストは、業務のリスクに合わせてカテゴリを選んで作ります。

第1章の段階表に書いた完了条件が、チェックリストの出発点です。また、チェックリストは固定された文書ではありません。チェック担当者が繰り返し直す部分が出てきたら、それが次に加える項目であり、次の改善対象です。

誤りの重大度と全件・サンプルチェック

すべての誤りが同じ重みを持つわけではありません。読点の誤りと、間違った顧客へのメール送信を同じ点数で数えると、指標が実際のリスクを示せません。誤りを等級に分けます。

等級により、チェック方法も変えます。重大な誤りが起こり得る段階では、全件チェック（すべての案件を確認）を維持します。軽微な誤りしか起こらない段階は、サンプルチェック（一部を無作為に選んで確認）に切り替え、人の時間を節約します。サンプルチェックで重要以上の誤りが基準を超えて出たら、全件チェックに戻します。この切り替え条件は、事前に決めておく必要があります。

チェック担当者同士の判断をそろえる

担当者が2人以上いると、同じ結果でも判定が分かれます。ある人は「修正が必要」、別の人は「合格」とするなら、品質指標が担当者によって大きく変わります。判断をそろえる手順は次のとおりです。

1. 同じ成果物10〜20件を、担当者がお互いの判定を見ずに、それぞれ判定します。
2. 判定が分かれた案件を集め、理由を話し合います。
3. 合意した基準を、「合格・修正・保留」の短い例とともにチェックリストに書きます。
4. 四半期ごとと、担当者が替わるたびに、この手順を繰り返します。

判定が分かれ続ける項目は、基準があいまいだというサインです。その項目をさらに具体的に分けるか、判断ではなく確認できる事実に置き換えます。

4つの運用指標

1つの指標だけを見ると判断を誤ります。ユーザーが増えても品質が落ちれば問題で、品質がよくても誰も使わなければ効果はありません。限界の指標が急にゼロに近づくことも、よい兆候とは限りません。引き継ぐべき仕事を引き継いでいない可能性があります。製品が指標を提供することもあります。Gemini Notebookでは、ノートブックを4人以上と共有し、直近7日間に会話があると、日別のユーザー数と質問数が表示されます。こうした指標は定着を示すだけで、品質は示しません。

指標の定義と分母

同じ「承認率」でも、チームによって計算が違えば比較できません。指標ごとに定義書を書きます。

[指標定義書]
指標名：修正なしで承認された割合
計算式：（修正なしで承認された下書きの数）÷（人が確認を終えた下書きの数）× 100
含めるもの：期間内に確認が終わった下書き
除外するもの：確認待ちの下書き、テスト用に作った下書き
部分修正：事実・条件・約束を直したら「修正」、誤字・脱字・空白だけを直したら「表記修正」として別に数える
収集方法：承認画面の記録を週1回ダウンロード
責任者：運用担当

分母が重要です。同じ期間に下書きを100件作り、60件だけを確認し、そのうち45件が修正なしで承認された場合、分母を生成件数にすれば45%、確認件数にすれば75%です。未確認の40件は品質がわからないため、品質指標の分母は確認件数にし、確認率を別に報告します。部分的な成功（一部だけ正しい結果）や保留をどう数えるかも、事前に決める必要があります。

採点方法を選ぶ

結果の評価方法は大きく3つあります。Anthropicは、評価方法を選ぶとき、最も迅速で信頼性が高く、拡張性の高い方法を選ぶよう勧めています。

AIに採点を任せる場合は、具体的な採点基準表（ルーブリック）を渡し、「正しい／誤り」や1〜5点など、決まった答えを出させ、人の採点結果と比較して信頼できるかを先に確認します。1つの業務でも基準が複数あるなら、基準ごとに異なる採点方法を使います。また、評価用テストケースは実際の業務の発生分布に近づけ、例外事例を除外してはいけません。

失敗を発生段階ごとに分類する

失敗を見つけると、すぐに指示を直したくなりますが、すべての失敗が指示の問題ではありません。どの段階で失敗したのかを先に見分けます。

モデルの交換は、この表のどの欄でも最初の対策にはなりません。資料が古いままモデルを替えても、新しいモデルは同じ古い資料で答えます。会話履歴を削除しても、アシスタントが誤りを「忘れる」わけではありません。アシスタントの動作を決めるのは、指示、資料、接続です。OpenAIも、ツールを増やす前に指示を整え、例を追加したほうが、問題を早く直せる場合が多いと説明しています。

1件の失敗を改善実験に変える

目立った失敗1件だけを応急的に直しても、似た失敗が別の形で再び現れます。失敗を改善実験に変える手順は、次のとおりです。

1. 再現します。 同じ入力で同じ失敗が起きるかを確認し、その時の指示・資料・設定の状態を記録します。
2. 仮説を立てます。 発生段階の表を使い、原因を1つ選びます。
3. 1つだけ変えます。 複数の箇所を一度に変えると、何が効いたのかわかりません。
4. 回帰テストをします。 失敗事例と既存のテスト質問セットを一緒に実行し、修正が以前は正しかった回答を壊していないか確認します。ソフトウェアのテストでは、このように以前は正しかったものが再び誤る現象を回帰といいます。
5. 失敗事例をテストセットに追加します。 次の変更時にも、この事例で確認します。

変更管理

自動化の結果を変えるのは指示だけではありません。5種類の変化があります。

変更は、同じ手順で扱います。

1. 変更する対象と理由を書き、影響を受けるユーザーと業務を把握します。
2. 固定のテストセットで、変更前後を比較します。
3. 一部のユーザーに先に適用して指標を見ます（段階的な適用）。
4. 全体に適用し、以前の状態へ戻れるように保管します。
5. 何がなぜ変わったかを、ユーザーに短く知らせます。

OpenAIは、GPTの編集画面でバージョン履歴を見て、以前の版を復元できると案内しています。製品にバージョン機能がなければ、指示の原文を日付ごとの文書として別途保管してください。自分たちで変えていない変化（モデル、製品、接続の提供者）には、通知を確認し、テストセットを再実行して対応します。

導入効果の測定

導入効果は、ベースラインとの比較で証明します。ベースラインは、導入前に同じ方法で測った値です。また、コストには契約料や従量料金だけでなく、人の時間をすべて含める必要があります。

純削減時間（月）=（導入前の1件の時間 − 導入後の1件の全体時間）× 月の処理件数
                − 月の維持時間（資料更新、指示修正、テストセット管理、教育）
導入後の1件の全体時間 = 生成・入力時間 + 確認・修正時間 + やり直し時間

たとえば、導入前は1件15分、導入後は生成2分と確認・修正6分、月300件、月の維持時間が8時間なら、純削減時間は（15−8）×300 = 2,100分（35時間）から8時間を引いた27時間です。これにツールの費用も併せて報告します。品質が同じ水準かも確認が必要です。時間が減っても誤りが増えたなら、削減ではなく、費用を別の場所へ移しただけです。

ユーザーへの導入と支援体制

ツールを展開しても、ユーザーがいつの間にか元の方法へ戻ることはよくあります。理由はたいていツールの外にあります。

1. 初回利用の案内：どの業務にまず使えばよいか、具体例を3つ示します。
2. 信頼してよい範囲：どこまではそのまま使え、どこからは必ず確認すべきかを伝えます。
3. 報告窓口：誤った回答を見たときに、10秒以内に知らせられる窓口を作ります。
4. 隠れた手作業を探す：使わない人、途中でやめた人に聞き取りをします。結果を他のプログラムに移して修正する作業など、指標に表れない手作業が理由であることが多いです。

事故対応、手作業への切り替え、運用終了

自動化が止まったり、誤動作したりした場合の計画は、平常時に立てておきます。

Anthropicも、スケジュールされたタスクは毎回結果を確認し、使わないものは停止または削除するよう勧めています。使われないのに動き続ける自動化は、費用がかかり、古い権限を保持し続けます。

さらに深く

比較の落とし穴

導入効果を示す最も簡単な方法は「導入前3か月と導入後3か月」の比較です。しかし、その間に業務量、難しさ、担当者、季節が変わっていれば、その差が自動化によるものかはわかりません。

同時の比較でも、2つの集団が処理した業務の構成が違うと、結論がずれます。比較時には、業務の種類別に見る習慣をつけてください。全体の平均が改善していても、難度の高い案件では悪化していることがあります。

よく見える数字を疑う

数値が良好に見えるときに、確認すべき問いがあります。

1. 分母は何か。 利用回数は再生成するほど増えます。案件の数なのか、実行の回数なのかを見ます。
2. 誰の声か。 満足度調査には、使い続けている人だけが答えがちです。やめた人の理由が抜けています。
3. 観測件数は十分か。 週20件の結果で「誤り0%」とは言いにくいものです。
4. 何が減ったか。 生成時間だけが減り、確認・やり直しの時間が増えているかもしれません。
5. 難しい事例はどこに行ったか。 人に引き継いだ割合が急減したら、引き継ぐべき仕事を無理に処理していないかを見ます。

運用終了も設計の一部

すべての自動化を永久に動かす必要はありません。業務がなくなった、よりよい方法ができた、純削減の効果が維持コストを下回った場合は、終了が正しい決定です。終了時には、何をなぜ終えたか、指示とテストセットの最終版、接続と共有を解除したことの確認、人が再び引き受けた手順を残します。この記録があれば、後で同じ試みをするとき、最初から学び直さずに済みます。

実務の場面

ヨウル文化財団：資料の構造が変わった後

地域の文化財団「ヨウル文化財団」の広報チームは、毎週木曜午後、翌週の文化イベント案内の下書きを、スケジュールされたタスクで作っています。タスクは、イベント担当部署が管理する予定のスプレッドシートを読み、イベントごとに案内文を書き、チームドライブに保存します。広報チームのイムさんが下書きを確認し、ウェブサイトと広報紙に掲載します。

ある木曜、イムさんは下書き14件のうち9件で、会場が空欄になっていることに気づきました。確認段階で見つかったため、外に出たものはありませんでした。イムさんはまず翌週のタスクを一時停止し、今週の案内は先週までの方法で手作業で書きました。手作業への切り替え手順を事前に書いていたため、半日で済みました。

原因を調べる際、イムさんは最初から指示を疑いませんでした。先週と比較し、変わったものを5つの欄で確認しました。指示は同じで、接続も正常、提供者のモデル・製品の変更通知もありませんでした。変更管理の表では変わったのは「資料」、失敗の発生段階の表では、タスクに入る入力形式が変わった「入力」段階の失敗でした。イベント担当部署がスプレッドシートを改修し、「会場」列を「会場（建物）」と「会場（部屋番号）」の2列に分けたため、タスクは以前の列名を見つけられなくなっていました。

あるメンバーは、指示に「会場を必ず書く」を太字で加えようと提案しました。イムさんは採用しませんでした。入力に会場情報がないのに強調文を加えると、タスクが存在しない会場を捏造したり、似たイベントの会場と混同して出力したりするおそれがあったからです。代わりに3つを変えました。指示に新しい列構成を反映し、会場欄が空なら案内文の一番上に「会場の確認が必要」と表示させました。テストセットには、会場が空欄のイベントと、部屋番号だけがあるイベントを追加しました。そして、担当部署と「スプレッドシートの列を変える際は広報チームへ事前に知らせる」と取り決め、資料管理台帳の変更連絡欄に書きました。

再開条件は、回帰テストの合格とチーム長の確認でした。既存のテストセット20件と新しい事例4件がすべて期待どおりになってから、タスクを再び有効にしました。イムさんの変更記録には、こう残りました。「指示は同じだった。変わったのは資料の構造だった。」

草の葉生協：使わない人たちの理由

消費生活協同組合「草の葉生協」の顧客センターは、4か月前に組合員からの問い合わせへの返信下書きアシスタントを導入しました。運用担当のナムグンさんは、四半期点検の準備で4つの指標を集めました。定着の段階から問題がありました。相談員15人のうち、毎週継続して使うのは6人でした。その6人の修正なしの承認率は70%で、悪くありませんでした。

ナムグンさんは、使っていない9人に1人ずつ会いました。理由は品質ではありませんでした。アシスタントの下書きには段落ごとに見出しとリスト記号が付いていましたが、相談システムの返信欄に貼り付けると記号が崩れました。相談員は下書きから記号を消し、行を整え直すのに1件2〜3分を要し、最初から自分で書いたほうがよいと感じていました。この時間はどの指標にも表れていませんでした。効率の指標が「下書きの生成時間」だけを測っていたからです。

ナムグンさんは2つを直しました。指示の形式の項目を「相談システムの返信欄にそのまま貼り付けられる普通の文章で書く。見出しやリスト記号は使わない」に変え、同じテストセットで形式だけが変わったかを確認しました。効率指標の定義も変えました。今後の1件あたりの処理時間は、問い合わせを開いた時点から返信を送信した時点までとします。

品質指標も見直しました。それまでは担当者2人が各自で判定していましたが、同じ下書き15件を別々に判定すると、5件で判断が分かれました。2人は判定が分かれた案件で基準をそろえ、「合格・修正・保留」の例をチェックリストに添えました。

2か月後、毎週使う相談員は13人になり、問い合わせ1件を処理する全体時間は、導入前の11分から7分に減りました。ナムグンさんの報告書には、利用回数ではなく4つの指標を並べ、最後に指標の定義が変わったことと、その理由を記しました。

間違えやすいポイント

1. 「強調の文を追加すれば直る」 「絶対に間違えるな」と指示したり太字で強調したりしても、根本原因は解消されません。失敗した段階を見分け、それに合わせて直します。
2. 「モデルを替えればすべて解決する」 古い資料、変わった入力、あいまいな指示は、どのモデルでも同じ誤りを生みます。
3. 「失敗した会話を消せば、再び間違えない」 会話履歴を削除しても、アシスタントは再学習されません。失敗事例はむしろテスト用の資料です。
4. 「利用量が増えたので成功だ」 利用回数は再生成でも増えます。品質・効率・定着・限界を一緒に見ます。
5. 「自分たちで何も変えていないので、結果も同じだ」 資料、接続、モデル、製品は、知らないうちに変わり得ます。通知を確認し、テストセットを定期的に実行します。
6. 「修正版をすぐに全体へ展開する」 テストセットでの比較と一部への適用を飛ばすと、新しい誤りを全員が経験することになります。
7. 「生成時間が減った分だけ削減できた」 確認・修正・やり直し・維持の時間を差し引いてこそ、純削減時間です。

ひと目でわかるまとめ

• チェックリストは業務のリスクに合わせてカテゴリを選び、完了条件を出発点に、失敗事例で増やします。
• 誤りは軽微・重要・重大に分け、重大な誤りが起こり得る段階は全件チェック、それ以外はサンプルチェックにします。切り替え条件は事前に決めます。
• 担当者が2人以上なら、同じ案件を別々に判定し、基準をそろえます。
• 運用指標は品質・効率・定着・限界の4つを一緒に見ます。各指標で計算式、分母、含めるもの・除外するもの、収集方法を定義します。
• 採点は、正確な値はルール、あいまいな判断は人、トーン・形式は信頼性をテストしたAIで行います。
• 失敗は、入力・資料・検索・生成・権限・接続・チェック・受け渡しのどこで起きたかを先に見分けます。モデルの交換は最初の対策ではありません。
• 改善は、再現 → 仮説 → 1つだけ変更 → 回帰テスト → テストセットへ追加、の順です。
• 変更管理では、指示・資料・接続・モデル・製品の5つを一緒に扱います。
• 純削減時間 = 減った1件の全体時間 × 件数 − 維持時間です。品質が保たれたかも併せて見ます。
• 停止のサイン、手作業への切り替え、再開条件、運用終了の基準は、平常時に決めます。

公式ドキュメントで確認する

• Anthropic — Define success criteria and build evaluations：成功基準の条件、評価設計の原則、コード・人・AIの採点の長所と短所を読みます。
• Anthropic — Building effective agents：性能を測りながら繰り返し改善し、結果が明確に改善する場合だけ複雑さを増やす原則を確かめます。
• OpenAI — Creating and editing GPTs：プレビューでのテスト、バージョン履歴と復元、カスタムGPTの終了日程を読みます。
• Google — Create a notebook in Gemini Notebook：ノートブックの利用分析の指標と条件を確かめます。
• Google — About the transition from Gems to skills：製品の切り替え日程と移行方法を確かめます。
• Anthropic — Use Claude Cowork safely：タスクの結果確認と、未使用タスクの整理の推奨を読みます。

セルフチェック

5-1. すべての業務に同じ長いチェックリストを使うと生じる問題を説明してください。また、社内の週次会議録を要約する業務について、この章の表から必須のチェックカテゴリと、省いてもよいカテゴリを1つずつ選んでください。

5-2. 誤りを軽微・重要・重大に分けるとき、それぞれの例を1つずつ挙げ、サンプルチェックから全件チェックに戻す条件を1つ提案してください。

5-3. チェック担当者2人の判定がよく分かれます。基準をそろえる手順を3段階で書き、それでも判定が分かれ続ける項目はどう直すべきかを説明してください。

5-4. ある週に下書きを200件作り、人が120件を確認し、そのうち90件が修正なしで承認されました。分母が生成件数の場合と確認件数の場合の割合をそれぞれ求め、報告ではどちらを品質指標にし、何を併記すべきかを書いてください。

5-5. 次の3つの失敗を、発生段階に分類してください。㋐ コネクタの認証期限が切れ、昨日届いたメールを取得できなかった ㋑ 正しい根拠文書は見つけたが、例外条項を落として回答した ㋒ 申請書の様式が変わり、申請者の連絡先欄を読み取れなかった。

5-6. 架空の数値で月の純削減時間を計算してください。月500件、導入前は1件10分、導入後は生成1分と確認・修正4分、月の維持時間は10時間です。計算過程を示し、この数字だけで成功と言う前に確認すべきことを1つ書いてください。

5-7. 自動化を止めて、人が仕事を引き継ぐ場合に備え、平常時に決めることを3つ書き、そのうち1つが欠けるとどのような混乱が起きるかを説明してください。

実習課題