顧客オンボーディング自動化

顧客オンボーディング自動化では、合意した顧客要件を、担当と依存関係を持つ繰り返し使える設定チェックリストに整理します。承認済みの作業ライブラリから始め、提供された要件と照合し、誰かがチェックリストに従って作業する前に不足情報をレビューします。

以下の例では、人が承認するオンボーディング計画を準備します。出力は担当を割り当てたチェックリストです。アカウントの作成・設定、予約日程の調整、歓迎メッセージの配信は、ここでは扱いません。

執筆：Ai Flowi · 公開日：2026-10-11

設定例（記録されたテストではありません）
カタログに記載されていますが、Ai Flowi による本番テストは行われていません

1. 合意済みの範囲と依頼された範囲を分ける

受け入れた作業範囲、顧客が提供した要件、現在の設定状況を集めます。顧客が依頼した連携は、責任を持つチームが対象範囲に含まれると確認するまでは、依頼として計画に入れます。下書きが誤って作業を約束しないよう、出力でもこの違いを保持してください。

作業識別子、適用条件、必須入力、先行作業、責任を持つ役割、完了の証拠を含む作業ライブラリを作ります。役割と実名の担当者は分けてください。モデルは承認済みの役割を選べますが、担当者はチームリーダーが決めるべきです。期限は、誰かが受け入れて初めて約束になります。

2. 利用許可のある入力とアクセスを準備する

ワークスペースと承認済みのオンボーディング作業ライブラリを準備します。モデル認証情報リファレンスに従い、ご自身のプロバイダーアカウントとAPIキーを設定してください。作業選択の呼び出しには、プロバイダーの料金がかかります。最初の下書き用に、利用許可のある要件情報一式を Chat Input に貼り付けます。作業範囲のバージョンと出典識別子を含め、認証情報や非公開のアクセスリンクは除いてください。

ライブラリが Knowledge Base にある場合は、下書き前に取得した作業識別子を承認済みのライブラリと比較します。選択した knowledge_base と返された出典を確認してください。検索で必須作業が漏れる可能性があるため、出典の関連性だけでは、オンボーディングのチェックリストがすべての必須活動を網羅しているとは確認できません。

チェックリストの受け入れと、認証情報の準備状況は分けます。保存先へのアクセスが未解決でも、チームは作業順序を承認できます。顧客の設定作業を完了とせず、公開・保存への引き継ぎに対して、アクセスの不足を記録してください。

3. 要件と作業を対応付けた情報一式を作る

承認済みの製品と顧客要件に関連する作業を検索するよう、Knowledge Base の search_query を設定し、出典参照のために include_metadata を有効にします。作業ライブラリに適した top_k を意図的に設定し、漏れた項目を確認してください。承認済みライブラリの共通必須作業は別途含め、必須要件の有無が検索結果によって決まらないようにします。

取得した作業記録をオンボーディング情報一式へ整形するには、Parser の項目リファレンスを使います。

架空の設定依頼で、承認済みの作業に顧客提供のリソース識別子が必要で、アクセスのレビューに依存しているとします。要件情報一式には識別子がありますが、完了したアクセスレビューはありません。依存関係を保ったまま設定作業を含め、アクセスの証拠待ちでブロック中と記録します。まだ開始できないという理由で除かないでください。検索で設定作業だけが返され、その前提作業がない場合は、順序を下書きする前にライブラリで前提作業を探します。これにより、検索の不完全さと顧客情報の不足を区別できます。

最初の提案では、レビュアーがその情報一式を顧客要件とまとめ、統合したテキストを Chat Input に貼り付けられます。この明示的な引き継ぎにより、対応するポートだけで複数の文書を統合したり、意図した順序を保持したりできるという主張を避けます。

4. 選択を制限したオンボーディングのチェックリストを生成する

Chat Input の message ポートから、チェックリスト抽出用の Structured Output の input_value へ要件情報一式を渡します。model 入力には Language Model の model_output を接続します。作業識別子、要件参照、提案する責任役割、先行作業の識別子、不足入力、完了の証拠、レビュー状況を含む output_schema を定義してください。

system_prompt では、提供されたライブラリからだけ作業を選ぶよう設定します。顧客が必要な詳細を提供していない場合は、不足入力の記録を必須とします。依存関係を保持し、一致する承認済み作業がない要件を明示するようモデルに指示してください。不足を埋めるために、作業、システム権限、完了日を捏造してはいけません。

顧客オンボーディングのチェックリストの自動化では、着手可能な作業とブロック中の作業を分ける必要があります。先行作業がリストにあるだけでは、完了したことを意味しません。完了の証拠を確認するまで依存する作業をブロック中に保ち、顧客情報待ちの作業と社内の範囲判断待ちの作業を区別します。

5. 担当と依存関係の順序をレビューする

チェックリスト候補のJSONを input_value に指定し、Chat Output で確認します。作業識別子をライブラリと比較し、承認済みの要件ごとに作業か不足の記録があるかを確認し、依存関係の循環を探します。責任を持つチームメンバーが、その網羅性をレビューした後で担当者を割り当て、目標日を受け入れます。

レビュー済みのチェックリストと未解決の問いを一緒に保持します。作業が不明なアクセス権限に依存している場合、完全に見えるリストでも誤解を招く可能性があります。文書を作っただけで作業を完了にしないでください。完了には、作業ライブラリで定めた証拠が必要です。

AIによる顧客オンボーディングのチャットボットは、追加確認した要件を収集できますが、その回答にもこのチェックリストのレビューが必要です。ここでの Chat Input による受付と Chat Output による表示は、Playground 内で動作します。顧客向けチャネルへの展開には、この構成とは別に範囲を定めた作業が必要です。

6. 承認済みの文書を別に準備する

共通の文書準備と失敗時の手順を使います。このチェックリストでは、承認済みの作業ID、受け入れた担当割り当て、依存関係、未提供の入力を initial_text に対応付け、受け入れた作業範囲のバージョンを title で識別します。

リンク先のフォームから文書を作る手順は、CR+LF から LF への変換後、検証済みのフォーム項目と文書作成について42/42に合格と報告しています。この結果には、作業の検索、依存関係の選択、オンボーディングの承認は含まれません。

適用されない作業と、範囲の判断が未解決で除外された作業を区別します。例えば、顧客要件に未承認のサービスオプションが含まれている場合があります。その要件を範囲に関する問いとして保持し、オプションが受け入れられた場合に適用される承認済みの作業を特定します。その条件付き作業を約束として割り当てないでください。レビュー後に範囲が変わった場合は、自由記述の作業を追加するのではなく、影響する適用条件と依存関係を見直します。選択の根拠は引き続き承認済みのライブラリとし、改訂した範囲によってチェックリストの変更理由を示します。