検証に合格した。全社に一斉に出してよいか
PoC で Go 判断が出ました。ここで「全物件・全担当者に一斉展開」とやるのが、最後の落とし穴です。Deployment & Scale は、検証済みの AIエージェントを本番に出し、段階的に広げ、組織に根づかせるステップで、3つの段階を経ます。
パイロット：まず小さく本番で動かす
パイロット導入は、全社一斉ではなく、限定した部門・チーム・業務で本番稼働させることです。Step4 のサンドボックスとの最大の違いは、実データと実際の利用者を対象に、本番環境で運用する点です。
なぜサンドボックスの合格だけでは足りないのか。理由は3つあります。
- 実環境でしか見つからない品質の問題がある。 テストデータでは問題なくても、実際の依頼には誤字、方言、写真の向きの違い、複数の設備をまとめて書いた長文など、想定外が含まれます。
- AI 本体だけでなく、運用の仕組みも検証する必要がある。 AI が判定できないケースを誰に引き継ぐのか、誤った判定で業者を手配してしまったらどう対応するのか。運用の手順は実際に回してみないと機能するか分かりません。
- 小さな成功実績が、次の展開を進める根拠になる。 いきなり全社展開より、限定範囲で成果を示した方が経営層と現場の理解を得やすい。これは Discovery のクイックウィンの考え方とつながります。
修繕依頼の例なら、1つの営業所の担当者2名で、3週間、実際に届いた依頼を AI が処理する本番運用を行います。確認する観点は、実データでも精度が維持されるか、運用の流れ（担当者がどう確認し、業者にどう手配し、入居者にどう連絡するか）が無理なく回るか、定量的な成果（初回連絡までの時間が2日から2時間、1件あたりの処理が 15 分から 4 分、など）が実際に出るか、です。
ロールアウトとスケーリング：広げ方は2種類
パイロットが成功したら広げます。広げ方には2種類あり、試験で区別が問われます。
- ロールアウト: 同じ機能を、より多くの人に届ける。 機能は変わらない。例: 1営業所の担当者2名 → 全5営業所の管理担当者へ。
- スケーリング: 処理能力や適用範囲を拡張する。 対象業務の拡大や新機能の追加を含む。例: 設備故障に加えて、鍵の紛失や共用部の不具合への対応を追加する（判定基準を新たに設計する必要がある）。業者への手配を、候補の提示から空き日程の自動調整まで広げる（カレンダー連携という新機能）。
段階的に進める意味は、リスクを管理できる範囲に収めることです。全社一斉で問題が起きれば影響は全社に及びますが、段階的なら各段階で問題を見つけて直してから次に進めます。各段階の進行判断基準は事前に決めておきます。たとえば「読み取り精度 85% 以上を3週間維持」「公平性テスト合格」「担当者の満足度 70% 以上」の3条件をすべて満たしたら次の段階へ、というルールです。
AI-SECI モデル：人と AI の間で知識が回る
第3章の SECI モデルは、人と人の間で知識が暗黙知と形式知を行き来しながら増える循環でした。AI-SECI モデルは、この循環の中心に AIエージェントを置いたものです。人と AI の間で知識が回ります。
| 段階 | 修繕依頼の受付での姿 |
|---|---|
| 共同化 | ベテラン担当者が AI の判定を日々確認するうちに「築年数の古い物件の『水の出が悪い』は、AI が通常と判定するが、配管の劣化が多いので早めに見た方がよい」という勘を蓄積する |
| 表出化 | その勘が「築 30 年以上の物件の水量低下は、3日以内に格上げする」というフィードバックとして言葉になる |
| 連結化 | フィードバックがルールとして既存のプロンプトに統合される。設備故障だけでなく、共用部の点検依頼の判定にも横展開される |
| 内面化 | 改善された AI の判定を日々見る新人担当者が、「古い物件の水回りはこう見る」という判断力を自然に身につける |
このサイクルが回り続けると、AI の精度と人の判断力が同時に上がり、組織の知的資産が厚くなります。試験では「人の暗黙知が AI へのフィードバックとして形式知化され、改善された AI を通じて人が新たな暗黙知を得る」一連の流れの名前として AI-SECI モデルが問われ、「人と人の間」の SECI モデルやフィードバックループと区別させます。
KPI モニタリング：処理件数は成果ではない
稼働後に追う指標は、第5章のアウトプット指標とアウトカム指標の区別がそのまま使われます。
「AI が1日に 60 件の依頼を処理している」はアウトプット指標（活動量）です。件数が多くても、判定の精度が低ければ担当者の修正が増えて、かえって工数が膨らみます。追うべきはアウトカム指標（価値）です。初回連絡までの時間がどれだけ短くなったか、担当者間の判定一致率がどう変わったか、そしてAI が「通常」と判定した依頼が、後日「緊急だった」と判明していないか（二次被害や苦情につながっていないか）。
3つ目は修繕依頼固有の本質的な指標です。処理を速くしても、見逃しで水漏れが階下に広がっていれば導入の意味がありません。この指標は数か月かけて追う必要があるので、短期のアウトカム指標と長期のアウトカム指標を分けて設計します。公平性テストの定期的な合格確認も、稼働後のモニタリングに含めます。
試験で問われる観点
- ベテランが AI の癖を発見し、言葉にしてプロンプトに反映し、改善された AI を見た新人が判断力を得る一連のプロセスは AI-SECI モデル（SECI モデルやフィードバックループとの区別）。
- 成果を測る指標として最も適切なもの（初回連絡までの時間の短縮と、判定の見逃しによる二次被害の有無）。処理件数、利用回数、プロンプト改善回数はアウトプット指標。
- パイロット（実データ・実ユーザー・本番環境）とサンドボックス（テストデータ・隔離環境）の違い。
- ロールアウト（同じ機能を多くの人へ）とスケーリング（機能・範囲の拡張）の区別。
- 段階ごとの進行判断基準を事前に決め、満たしたら次へ進む。