Genieのスコープを計画する
ジョブディスクリプションが明確で焦点が絞られていると、Genieの信頼性が高まります。 明確で焦点が絞られたジョブディスクリプションにより、適切にスコープ設定されたGenieになります。 スコープが広すぎるGenieは、構築され、デモされても、プロダクションで信頼性が低く、保守が難しく、段階的な改善が不可能なため、いつの間にか放棄されます。
このページでは、信頼性を確保するためにGenieのスコープを設定する方法について説明します。
サブドメインを使用してスコープを定義する
ビジネスドメインとは、IT、人事、営業、財務などの広範な機能領域です。 サブドメインとは、そのドメイン内の焦点を絞った区分であり、特定のユーザーペルソナに対して特定のタスクセットを提供します。 サブドメインは、Genieのスコープを設定するための推奨単位です。
次の例は、一般的なビジネスドメインを適切にスコープ設定されたサブドメインに分割する方法を示しています。
HR
- 従業員セルフサービス: 全従業員向けの休暇申請、ポリシーに関する質問、個人データの更新
- 採用調整: 採用担当者向けの面接スケジュール設定、候補者とのコミュニケーション、求人リクエストの追跡
- オンボーディング: 入社後90日以内の従業員向けの新入社員タスク完了、機器リクエスト、システムアクセス
- 福利厚生管理: 福利厚生対象従業員向けの登録、変更、資格に関する質問
IT
- 従業員ヘルプデスク: 全従業員向けのパスワードリセット、アクセスリクエスト、ソフトウェアインストール
- インシデント管理: ITサポートエージェント向けのP1/P2エスカレーション、関係者とのコミュニケーション、解決状況の追跡
- ライセンス管理: IT管理者向けの利用状況監視、最適化の推奨、プロビジョニング
- 変更管理: エンジニア向けの変更リクエスト送信、承認ルーティング、影響評価
Sales
- アカウント調査: アカウントエグゼクティブ向けのアカウント概要、見込み客インテリジェンス、ニュース監視
- パイプライン管理: 営業マネージャー向けの商談更新、更新追跡、フォーキャスト整備
- CPQ: ディールデスクおよびAE向けの見積作成、割引承認、製品構成
- SDRの生産性: SDR向けのリード調査、アウトリーチ文面作成、会議スケジュール設定
特定のユーザーペルソナ向けに設計する
サブドメインでスコープを設定することに加えて、特定のユーザーペルソナ向けにGenieを設計する必要があります。
対応するユーザータイプが多すぎるGenieは、受け取るリクエストの種類が多くなりすぎます。 これには、異なるスキル、異なるナレッジベースコンテンツ、異なる応答スタイルが必要です。 Genieのジョブディスクリプションを作成する前に、次の質問に回答してください。
- 主なユーザーは誰ですか: 具体的なロールまたはペルソナに名前を付けます。 これは、特定のロールで特定のジョブを実行する具体的な人物である必要があります。
- このペルソナが最も頻繁に実行する3～5個のタスクは何ですか: これらのタスクが、ジョブディスクリプションのユースケースカテゴリになります。
- このペルソナはすでに何を知っていますか: Genieの応答スタイルと詳細レベルは、ペルソナの既存の知識を反映する必要があります。
- このペルソナが決して尋ねないことは何ですか: ペルソナの要件の境界を把握することで、スコープ外の内容を定義できます。
ペルソナ定義を作成するには、次の例を使用します。
| ❌非推奨 | ✅推奨 |
|---|---|
Employees | New hires in their first 90 days |
Users | Enterprise account executives managing renewals |
Staff | IT support agents triaging P1 incidents |
焦点を絞ったGenieから始める
焦点を絞ったスコープのGenieから始め、計画的に拡張します。 スコープを狭くすると、Genieが少数のタスクを確実に実行できます。 Genieがプロダクション環境に入り、確実に動作するようになった後で、ユースケースカテゴリ、同じペルソナに対応するスキルを追加し、追加コンテンツでナレッジベースを拡張できます。
適切にスコープ設定されたGenieには、通常、次のものがあります。
- ジョブディスクリプション内の2～3個のユースケースカテゴリ
- 3～5個のスキル
- 焦点を絞った1つのナレッジベース
- 明確に定義された1つのユーザーペルソナ
Genieのスコープを設定する
Genieのスコープを定義する際の参考として、次のガイドラインを使用します。
| ❌非推奨 | ✅推奨 |
|---|---|
| HR Genieのように、全従業員タイプのすべてのHRプロセスを対象として、ビジネスドメイン全体を処理する単一のGenie。 | サブドメインごとに個別のGenieを用意し、各Genieを特定のペルソナとタスクセットを中心に構築する。 たとえば、個人貢献者向けの休暇管理Genieです。 |
| ITポリシー、HRドキュメント、営業プレイブック、財務手順が混在するナレッジベース。 | 関連する結果が取得されるように、1つのサブドメインにスコープ設定された焦点を絞ったナレッジベース。 |
| 複数のドメインにまたがる多数のスキルを持ち、スキル選択に曖昧さを生むGenie。 | LLMが一貫して正しいスキルを選択できるように、単一のドメイン内に3～5個のスキルを用意する。 |
| ドメイン全体の多数のシナリオ、ユースケース、ルーティングルールを対象とするジョブディスクリプション。 | 1つのペルソナ向けに2～3個のユースケースカテゴリに焦点を絞ったジョブディスクリプション。 |
| 既存のGenieに異なるペルソナ向けのユースケースを追加する | 新しいサブドメイン用に新しいGenieを作成し、Agent orchestrationを通じて接続する。 |
ガバナンスの利点
焦点を絞ったGenieは、ガバナンスも容易です。
- アクセス制御が明確になる: ユーザーグループが明確に定義され、アクセス可能なスキルの境界も明確になります。
- 監査証跡の意味がより明確になる: すべてのアクションが特定のサブドメインにマッピングされ、コンプライアンスレビューを効率化します。
- 調査が限定される: 問題が発生した場合、調査のスコープは単一のサブドメインに限定されます。
詳細については、Genie governanceを参照してください。
構築するGenieの数を決定する
サブドメインを設計した後の次のステップは、構築するGenieの数と、それらが相互にどのように関連するかを決定することです。 この決定には、個別に対処する必要がある2つの部分があります。
内部に存在すべきGenieはいくつですか: これは、自動化の構成方法に関するアーキテクチャ上の質問です。 管理するジョブディスクリプション、スキルセット、ナレッジベースの数、およびそれらの相互関係。
ユーザーがやり取りすべきGenieはいくつですか: これは、ユーザーが認識する必要のあるエントリポイントの数、および使用するGenieをユーザーが選択するか、その決定をユーザーの代わりに行うかに関するユーザーエクスペリエンス上の質問です。
これらの質問には通常、個別の回答があります。 ユーザーには表示されない複数の内部Genieと、内部Genieにルーティングする単一のユーザー向けGenieを用意できます。
最初のユースケースに対応するために必要な最小数のGenieから始めます。 ユースケースの拡大に合わせて、Genieとオーケストレーションを追加します。
アーキテクチャフレームワーク
自分の状況に合うアーキテクチャオプションを判断するには、次の質問を使用します。
| 質問 | はい | いいえ |
|---|---|---|
| ユーザーは、自分のリクエストがどのサブドメインに属するかを知っていますか。 | オプション1またはオプション3 | オプション2またはオプション3 |
| ドメイン横断クエリは一般的ですか。 | オプション2またはオプション3 | オプション1 |
| 同じビルダーチームがすべてのGenieを保守していますか。 | 任意のオプション | オプション1 |
| スキルはサブドメイン間で共有されていますか。 | オプション2またはオプション3 | オプション1 |
| これは初めてのGenie構築ですか。 | オプション1 | 任意のオプション |
オプション1: サブドメインごとの複数のユーザー向けGenie
各サブドメインには、独自のチャットインターフェースを持つ独自のGenieがあります。 ユーザーは、必要な内容に基づいてやり取りするGenieを選択します。
ユーザーエクスペリエンス: ユーザーは、自分のニーズに合うGenieを選択します。 たとえば、あるSlackチャンネルのIT Genieと、別のチャンネルのHR Genieです。
内部アーキテクチャ: 各Genieは独立しており、独自のジョブディスクリプション、スキル、ナレッジベースを持ちます。
このオプションを使用する場合:
- サブドメインの境界が明確で、ユーザーに十分理解されている
- ユーザーが、どのニーズにどのGenieを使用すべきかを確実に把握している
- 各Genieを保守するビルダーチームが独立している
- ドメイン横断クエリがまれである
注意点: ユーザーが誤ったGenieに頻繁にアクセスする場合、境界が十分に明確ではありません。 同じスキルが複数のGenieで再構築されている場合は、Genie間でスキルを共有することを検討してください。
オプション2: 内部オーケストレーションを備えた単一のユーザー向けGenie
単一のユーザー向けGenieがすべてのリクエストを受信し、専門化されたサブドメインGenieに内部でルーティングします。 ユーザーは1つのGenieとやり取りし、複数のエージェントが関与していることを認識することはありません。
統合されたユーザーエクスペリエンス: ユーザーは全体ドメイン内のあらゆる内容を1つのGenieに尋ね、Genieがルーティング先を判断します。
内部アーキテクチャ: ユーザー向けGenieはオーケストレーターとして機能します。 サブドメインを特定し、リクエストを直接処理するか、Genieにタスクを割り当てアクションまたはdelegate/handoverパターンを使用して、適切な専門Genieに委任します。
このオプションを使用する場合:
- ユーザーが自分のリクエストがどのサブドメインに属するかを知る必要がない
- ドメイン横断クエリが一般的である
- ビルダーチームがすべてのGenieを保守し、オーケストレーションロジックを調整できる
注意点: オーケストレーションを行うGenieのジョブディスクリプションは、正しくルーティングできるように適切に構成されている必要があります。 この方法で呼び出されるすべてのサブドメインGenieには、Verified user accessまたはBusiness approvalsがサポートされないことを含め、Agent orchestrationの制限が適用されます。
オプション3: ハイブリッド
一部のサブドメインGenieはユーザー向けで直接アクセス可能であり、その他はオーケストレーションを行うGenieを通じてのみアクセスできます。
柔軟なユーザーエクスペリエンス: 必要な専門Genieを把握しているパワーユーザー向け。 それ以外のユーザーはメインGenieを使用します。
内部アーキテクチャ: メインGenieがサブドメインGenie間をOrchestrateします。 各サブドメインGenieには、直接アクセス用の独自のチャットインターフェースもあります。
このオプションを使用する場合:
- 一部のユーザーグループは、専門Genieを直接使用できるだけの知識を持っている
- 一部のユーザーには統合されたエントリポイントが有益である
- ドメイン横断クエリは発生する可能性があるが、やり取りの大半ではない
注意点: 直接利用するエクスペリエンスとOrchestrateされたエクスペリエンスの一貫性を維持するには、規律が必要です。 Genieが直接呼び出された場合とメインGenie経由で呼び出された場合で動作が異なると、ユーザーは気付きます。
アーキテクチャに合わせてワークスペースを整理する
選択するアーキテクチャオプションは、Workatoワークスペースの整理方法に影響します。
オプション1: サブドメインごとに個別のプロジェクトにマッピングします。 各チームは、独自のスキル、ナレッジベース、App Eventsを持つ独自のプロジェクトを保守します。 チームの自律性が重複のコストを上回るため、スキルの重複は許容されます。 チームは、単一のプロジェクトに統合せずに、プロジェクト間でスキルとナレッジベースを共有することもできます。 これにより、重複を減らしながら独立した所有権を維持できます。
オプション2および3: 関連するGenieをまとめて整理し、必要に応じてプロジェクト間でスキルとナレッジベースを共有します。 共通プロジェクトには、複数のチームが依存するData tables、関数、その他の再利用可能なアセットを保持できます。 このアプローチによりスキルの重複が解消され、オーケストレーションが簡素化されますが、ビルダーチーム間の調整が必要です。
Last updated: