AIの出力をCRMやストレージへ渡すときは、「連携できるか」だけでなく、どの情報を、どの権限で、どの形式にして渡すかを決めます。ここが曖昧だと、接続できても業務の記録として使えません。
受け渡す項目を対応表にする
| 元の情報 | 渡す項目 | 変換・確認 |
|---|---|---|
| 問い合わせ番号 | 外部ID | 重複判定に使う |
| 自由記述の相談内容 | 要約欄 | 事実と未確認を分ける |
| 面談の希望時期 | 希望時期欄 | 確定日と混同しない |
| 連絡先 | 所定の連絡先欄 | 必要な処理にだけ渡す |
出力先の必須項目、文字数、日付形式、選択肢を確認します。値がないときは、空欄、保留、入力エラーのどれとして扱うかも決めておきます。
読み取りと書き込みの権限を分ける
認証情報はコードや作業メモへ直接貼らず、利用環境で承認された方法で管理します。連携に必要な範囲だけを許可し、読み取りの試行に削除権限まで付けないようにします。
連携先の公式資料では、認証方法、回数制限、データ容量、エラー、仕様変更の案内を確認します。必要なAPIが利用できるプランと、想定処理件数に応じた従量費も見積もります。この記事は特定製品の設定手順ではなく、実装前の要件整理です。
試験環境で「保存した結果」を見る
架空データで、通常入力、欠損、重複、権限不足、接続失敗を試します。AIの画面に成功と出るだけでは十分ではありません。連携先の実際の記録を読み戻し、入力と照合します。
運用票には、接続の所有者、設定の保管場所、障害時の連絡先、停止方法、費用の確認担当を記します。仕様変更時は、代表的な入力で再試験し、必要なら書き込みを止められるようにします。
空欄を、削除命令へ変えないための対応表
APIの仕様によって、省略した項目、空文字、nullの扱いは異なります。「情報がなかった」というAIの出力を、そのまま既存データの消去に使わないようにします。次はCRMへ確認結果を渡す架空の設計例です。
| 入力の状態 | 業務上の意味 | 実装前に決めること |
|---|---|---|
| 次回日程の記載なし | 新しい日程は不明 | 既存値を維持するか、確認待ち欄へ分ける |
| 削除を明示した依頼 | 既存値の変更を求めている | 実行権限と承認した対象を確認 |
| 日付だけあり時刻なし | 日時としては不足 | 勝手に午前0時や特定の時差を補わない |
| 選択肢にない分類名 | 保存形式に適合しない | 許可した対応表で変換するか保留 |
項目対応を決めたら、保存先から読み戻して値を照合します。利用するAPIの仕様書と契約プランを確認し、変更時は同じ入力例で再試験してください。特定のエラーコードだけを根拠に、書き込みが一切行われていないと断定しないことも必要です。
対象のツール名と受け渡したい項目を持って、AI連携の要件を相談してください。対象・数量・除外範囲が決まると、実装の見積条件もそろえやすくなります。