Agentforceローンチチェックリスト：T-90日から本番化まで

カウントダウンが「いつかやるリスト」に勝る理由

Agentforceのローンチが遅れる原因は、たいてい同じです。データクリーンアップを、期限付きの手順ではなく1つの巨大なタスクとして扱ってしまうことです。本番日から逆算すれば、正しい順序が自然と決まります——直す前に測り、検証する前に直し、ローンチする前に検証する。以下のチェックは、4フェーズのレディネス・プレイブックと、その土台である6つのデータ品質ディメンションに沿っています。

T-90日 · スコープとベースライン

測っていないものは直せません。クリーンアップの前に、エージェントが何を読むのか、そのデータが今どのスコアなのかを把握しましょう。

• Agentforceのエージェントが読み取るすべてのオブジェクトとフィールドを洗い出す——検索処理が参照しうるDescription、Notes、Commentsフィールドも含めて。
• 対象オブジェクトに対し、6つのデータ品質メトリクス——完全性率・適合率・有効性率・適時性率・重複率・PII露出率——のベースラインスキャンを実行する。
• ベースラインスコアを記録する。以降のすべての判断と本番化承認は、この数値を基準に測られます。
• PIIホットスポットに印を付ける。担当者が顧客メッセージを貼り付ける大量入力のフリーテキスト項目こそ、SSNやカード番号の隠れ場所です。
• ローンチ前にPIIの数値を承認するコンプライアンス責任者を指名する。

T-60日 · 是正

検出結果は、着手しやすい順ではなくリスクの高い順に処理します。最優先はPII——規制上のインシデントに発展しうる唯一のカテゴリーです。

• エージェントが読み取るテキスト項目から、SSNとクレジットカードの検出をすべて解消する。
• エージェントが依存する主要フィールドの空欄を埋める——Descriptionが空では、あいまいな回答しか返せません。
• 選択リストと参照項目の値を標準化し、「US」「USA」「United States」が3つの別々の事実になるのを止める。
• 構造化フィールド（メールアドレス、電話番号、ID）の不正な形式を修正する——エージェントはそれをそのまま引用します。
• エージェントが読むオブジェクトの重複をマージし、1人の顧客の履歴を1つにまとめる。
• 自信満々の時代遅れな回答の燃料となる、陳腐化したレコードを更新またはアーカイブする。

T-30日 · 検証

同じスキャンを再実行し、ベースラインと比較します。承認の根拠は、口約束ではなくエビデンスであるべきです。

• ベースラインと同じオブジェクト・フィールドに対して、スキャン一式を再実行する。
• エージェントが読むすべてのオブジェクトで、ローンチしきい値（下表）を満たしていることを確認する。
• PII露出率の数値を根拠に、書面でコンプライアンス承認を取得する。
• 是正前後のスコアを文書化する——組織がローンチ可能な状態だったことの証明になります。

ローンチ週とその後

ユーザーがレコードを入力し続ける限り、データ品質は劣化します。レディネスはマイルストーンではなく、回し続けるリズムです。

• ローンチ週に、大量入力のテキスト項目へ最終のPIIスキャンを実行する。
• 大規模なインポートやデータ移行は、本番化後まで凍結する。
• 定期スキャンをスケジュールする——PIIは週次、完全性と一貫性は月次、6メトリクスの全項目スキャンは四半期ごと。
• 初期のエージェント会話をレビューし、あいまい・矛盾・時代遅れな回答を洗い出す——その一つひとつが、直し方のわかっているデータ問題を指し示しています。

本番化しきい値の一覧

検証フェーズの合格基準です。各数値の詳しい根拠は、Salesforceデータ品質ベンチマークのページで解説しています。

チェックリストの半分が不合格だったら？

それがごく普通のスタート地点です。初回スキャンでは、誰も予想していなかった問題がほぼ必ず見つかります。T-90で不合格だらけになること——それこそが、カウントダウンをローンチ週ではなくT-90から始める理由です。まずPIIの検出、次に完全性と一貫性へと優先的に取り組み、対応の区切りごとにスキャンを再実行してください。本番日まで90日を切っている場合は、ベースラインを省くのではなくフェーズを圧縮しましょう。測定なしのローンチだけは、すぐにはリカバリーできない失敗パターンです。