第31章 受注から引継ぎまでを通して実践する

ここまでの章は、必要な場面ごとに使えます。しかし初めて外部支援へ入る人は、成果物をどの順で作り、前の結果を次の判断へどうつなぐか迷います。本章では、架空の二案件を通して追います。数字や期間は例であり、そのまま自分の案件へ当てはめず、判断のつながりを使ってください。

31.1 ケースA：問い合わせ対応AIの新規事業

相談

ある企業から「生成 AI を使った問い合わせ対応サービスを、三か月で事業化したい」と相談を受けました。依頼時点では、顧客、扱う問い合わせ、販売方法、許容できる誤りが決まっていません。

外部支援者は、すぐにチャット画面を作らず、意思決定を次のように置き換えます。

12週間後に、物流会社の配送状況問い合わせを対象として、限定提供へ投資するか、中止または対象変更するかを決める。

受注条件

最初の四週間を顧客課題と実行条件の確認、次の四週間をモックと AI 品質評価、最後の四週間を限定提供計画と予算判断に分けます。

依頼側は顧客候補への紹介、業務担当者の週2時間、匿名化した問い合わせ例、情報管理確認を担います。外部支援者は調査設計、同席、モック、評価設計、体制・予算案を担います。本番システムの完成と売上は、この段階の検収対象にしません。

顧客理解

5社へ最近の問い合わせを聞くと、顧客が欲しいのは自然な雑談ではなく、「荷物番号を間違えず、現在位置と次の行動を短く示すこと」でした。遅延や破損は担当者へ確実に渡す必要があります。

発言を次の価値仮説へ変えます。

配送問い合わせを受ける担当者が、定型的な状況確認を自動で返し、遅延・破損だけを根拠とともに引き継げれば、回答待ち時間と確認作業を減らせる。

AIを使う範囲

荷物番号の形式確認と配送データ取得は固定ルールと API で行います。生成 AI は、取得済み事実を利用者向けの短い説明へ変換する部分だけに使います。返金判断や顧客情報の変更は行わせません。

この分割により、正確であるべき事実を生成 AI に推測させずに済みます。

動くモックと評価

最初のモックは、担当者が裏で配送データを選び、AI が回答候補を作る形にします。30件の架空問い合わせと、利用許可を得て匿名化した20件で評価します。

公開条件は次のように置きます。

• 荷物番号と配送状態の取り違えが0件
• 必要な次の行動を含む回答が95%以上
• 遅延・破損を人へ戻せた割合が100%
• 回答候補の90%が軽微な修正以内
• 1件当たり費用と応答時間が上限内

結果は、通常配送では条件内、住所変更では誤案内が発生しました。したがって「すべての問い合わせ」へ広げず、通常配送の状況確認だけを限定提供します。

体制と予算

最低案は有人運用を残した3社限定、推奨案は運用担当と評価担当を置いた10社限定、加速案は複数業務へ拡大する専任チームとします。各案にモデル利用費、評価データ整備、人による確認、セキュリティ・法務、監視、サポートの費用を入れます。

経営会議では「AI チャットを作れた」ではなく、対象業務、確認できた品質、対象外、次の投資で減らす不確実性を示します。推奨案が条件付き承認され、住所変更は対象外のまま残します。

引継ぎ

社内のプロダクト責任者へ顧客判断、技術責任者へ評価と公開判定、運用責任者へ人への切替と事故対応を移します。外部支援者のアカウントを解除し、評価データ、プロンプト、費用表、既知の失敗を引き渡して終了します。

31.2 ケースB：既存SaaSへの議事録要約機能

相談

既存の会議管理サービスへ、議事録の要約とタスク抽出を追加したいという依頼です。すでに有料顧客、閲覧権限、保存期間、外部連携があります。

意思決定は次のように置きます。

8週間後に、希望した顧客だけへ要約機能を公開できるかを、品質、情報管理、既存業務への影響から判断する。

現在の基準値

実装前に、議事録作成時間、タスクの記載漏れ、問い合わせ、会議当たりのデータ量を測ります。顧客契約を確認すると、一部顧客は外部 AI サービスへのデータ送信を認めていません。

そのため、全顧客へ自動表示せず、管理者が機能を有効化し、対象会議ごとに利用者が実行する設計にします。禁止顧客には機能自体を表示しません。

設計レビュー

設計レビューでは、画面だけでなく次を確認します。

• 会議参加者だけが要約と原文を閲覧できるか
• 削除した議事録が検索やログに残らないか
• タスクの担当者と期限を原文にない内容から補わないか
• AI が不確かな箇所を明示できるか
• 外部サービス停止時も元の議事録を利用できるか
• 利用量急増時の費用上限があるか

評価と段階公開

会議の種類別に評価データを作り、決定事項、担当者、期限、未決事項を採点します。人事評価を含む会議は初期対象から外します。

社内検証では、長い会議で担当者の取り違えが見つかりました。原文中の発言者情報を入力へ追加し、担当者を断定できない場合は空欄にするよう変更します。固定評価を再実行した後、協力企業3社へ機能フラグで公開します。

公開後の判断

議事録整理時間は減りましたが、会議直後の待ち時間が長いという不満が出ました。モデルを速いものへ変える前後で品質と費用を再評価し、短い会議だけ高速モデル、長い会議は処理完了を通知する設計に変えます。

利用率だけでなく、修正率、担当者の誤り、処理時間、1会議当たり費用、問い合わせを毎週確認します。重大な権限違反が起きた場合は全顧客で停止する手順を用意します。

引継ぎ

プロダクトチームへ機能フラグと顧客説明、開発チームへモデル変更時の固定評価、サポートへ既知の限界と問い合わせ手順、情報管理担当へ外部サービスと保存条件を移します。公開後30日のレビューを行い、未解決事項と次回判断日を残します。

31.3 二つのケースに共通する判断の鎖

各成果物を完成品として孤立させません。ヒアリングの証拠が価値仮説を変え、評価結果が提供範囲と予算を変え、公開後の失敗が評価データと設計を変えます。

31.4 最小限の実務セット

小規模案件で全テンプレートを埋める必要はありません。最低限、次の六点を一つの共有場所で管理します。

1. 意思決定、対象・対象外、責任者、期限
2. 顧客・現場の証拠と、それによって変わった仮説
3. AI を使う理由、許容できない失敗、人へ戻す条件
4. 固定評価データと、品質・費用・速度・安全性の結果
5. 現在の提供範囲、監視、停止・復旧手順
6. 次の判断日、所有者、未解決事項

資料を増やすより、古い版を判断に使わないこと、確認済みと仮説を混ぜないこと、所有者を空欄にしないことが重要です。

考えてみる問い

自分が受ける予定の案件を、この章の判断の鎖へ当てはめてください。今どの局面にいて、次の判断に足りない証拠は何か、外部支援者が持ったままにしてはいけない責任は何かを書いてください。

外部から価値を出すとは、代わりにすべてを抱えることではありません。曖昧な相談を判断へ変え、顧客の証拠から小さく作り、AI の品質を測り、既存の仕組みを壊さず、組織が自分で続けられる状態へ移すことです。