企業はこの2年間で、チャットアシスタント、ライティングプラグイン、カスタマーサポートロボット、社内ナレッジQ&Aなど、多くのAIツールを導入してきました。しかし、実際に定着した能力はあまり多くありません。プロンプトはまだ個人のパソコンに残ったまま、業務フローは文書の隅に散らばったまま、スマートエージェントが稼働してもフィードバックや見直しが不足し、業務の要となる人材は依然として同じ種類の問い合わせで業務時間を埋められています。問題は往々にして、モデルが十分に賢くないのではなく、システムは「作業」を管理可能な職務能力として設計していません。。
まず整理しましょう：チャットウィンドウはなぜ役職に設定できないのでしょうか
チャットボットは一度の質問で終了してしまう。業務担当者は連続して作業を引き継ぎ、情報を収集し、ルールを判断し、システムを呼び出し、ステータスを書き戻し、例外が発生した場合にはさらに上位にエスカレートさせる必要がある。出張経費精算は典型的な例であり、ユーザーはまず「出張経費を申請してほしい」と言い、途中で「今月の利用枠は残りいくらですか」と尋ね、その後で領収書を追加することもある。もしシステムが各対話を新しいセッションとみなしてしまうと、フローが途切れ、コンテキストが失われ、後からルールに問題があったのかインターフェースに問題があったのかを検証することもできなくなる。
業界では、すでにエージェントを「デジタル従業員」として構築する取り組みが見られます。具体的には、役職や社員番号、能力の範囲、業務履歴を設定し、さらに修正可能なSOP、ナレッジベース、各種ツール、実行ログを備えます。オープンソースの分野では、OpenBMBなどの組織が公開したStaffDeckが、エージェントを単なるプロンプトの一文ではなく、運用可能なリソースの組み合わせとして捉えています。企業が自社開発やカスタマイズを行う際には、参考にするべきは製品名そのものではなく、このオブジェクトモデルなのです。
業務ロジック：システムには少なくとも7種類のオブジェクトが存在しなければなりません
デジタル従業員システムを構築する際は、まず業務オブジェクトを仕様に落とし込み、その後でモデルの選定について検討します。
- 職務ファイル：氏名またはキャラクター名、社員番号、職務、オンライン状態、サービス対象。アーカイブがなければ、権限や評価の根拠がありません。
- 能力の境界：どの伝票を読めるか、どのフィールドを書き込めるか、何を約束できないか。境界は管理者によって変更可能で、プロンプトに固定されていてはならない。
- SOP／プロセス型スキル：複雑なプロセスをノードに分割し、条件分岐、ツールの呼び出し、知識検索、および担当者への転送をサポートします。
- 知識本体：テーマ、ルール、ソース、操作マニュアルは別々に保管し、回答は必ずソースに遡れるようにし、検索は調整可能でなければならない。
- ツールの接続：HTTPインターフェースまたはMCPは、クレジット枠の照会や伝票の作成、ステータスの変更に使用されるものであり、単なる文言の生成だけを目的としているわけではありません。
- 定期タスク：日報の集計、期限超過の催促、在庫の巡回点検といった定期的な業務は、ユーザーが先に声をかけてくれるのを待っていてはいけません。
- トレースとフィードバック：ルーティング、ステップ、ツール、知識、回答を記録し、いいねやクレーム、および人手による引き継ぎは次の改訂段階へと進む。
一度の実際のリクエストには、しばしば複数のタスクが含まれます。デジタル従業員は、まず経費精算のSOPに移行し、必要な項目をすべて収集してルール判定を行った後、限度額照会のSOPへ切り替えてAPIを呼び出します。ユーザーが途中で政策に関する質問を挟んだ場合は、現在の処理ステップを保存し、回答が終わってから元のフローに戻す必要があります。ルール外の質問については、コンテキストを生成者または当直者に引き継ぎ、根拠のない強引な回答は禁止します。
設計ロジック：ロール、ステートマシン、知識の階層化
ロールの切り替えはどうすればよいですか
少なくとも四つのタイプに分かれます：作成者（経験を社員に定着させる）、管理者（権限管理、公開、クォータ）、利用者（デジタル従業員にタスクを割り当てる）、当直者（例外を参照）。作成者はデフォルトで在庫の変更や価格の変更権限を持つべきではありません。利用者は完全なプロンプトや秘密鍵を閲覧してはなりません。オープンAPIも階層化する必要があります。アカウントレベルの秘密鍵はリソースの設定を管理でき、従業員レベルの秘密鍵はセッションの作成と自身のトラッキング情報の閲覧のみ可能です。
SOPはステートマシンを使用し、対話メモリだけに頼らないでください。
自然言語でドラフトが生成でき、実行にはステートマシンを用いる必要があります。現在のノード、収集済みのスロット、呼び出せるツール、失敗時の再試行、および人手によるノードといった要素を考慮します。タスクが中断された場合でも、コンテキストをシリアライズし、元のノードに戻って処理を継続できるようにする必要があります。複数のSOP間ではリアルタイムに切り替え可能ですが、切り替え時には「どこから来たのか、どのような確認済み情報を持ち込んだのか」を明示し、ユーザーが同じフォームを繰り返し入力しないようにします。バージョンやブランチはロールバック可能であり、現場でプロンプトを一文変更するだけで即時公開できても、その後の対応については一切責任を追及できません。
知識は大雑把な検索にしないでください
ドキュメント、章、ページ、要約ごとにナビゲーション可能な索引を作成し、まず情報がどのカテゴリに該当するかを判断したうえで原文を特定します。知識のバケット化：制度の基準、製品説明、アフターサービスの応対フレーズ、例外事例をそれぞれ分けて管理することで、全範囲のキーワード検索よりも的確な絞り込みが可能です。各回答には出典、ルール、業務テーマを紐付け、テスト環境では「なぜこの部分がヒットしたのか」を確認できるようにします。検索のデバッグは、さらに大規模なモデルに切り替えるよりも、問題解決において頻繁に有効な手段です。
開発の実装：インターフェース、隔離、監視、検収
実行時には統一されたエントリーポイントを推奨し、各スキルが個別に異なるフローをたどることによる状態のずれを防ぎます。能力の検出、隔離実行、アーティファクトの整合性、クォータの算定は、事前の取り決めに頼るのではなく、実行時に確実に行う必要があります。スキルを社内マーケットに公開する前に、権限スキャンを実施してください。認証ヘッダー、環境変数、接続資格情報は、通常の読み取りインターフェースには一切含まれてはなりません。
- 実行チャネル：同期ストリーミングは対話に適しており、非同期のRun + イベントストリームは切断再接続やタスクキューに適しています。両者は同一のカーネルを共有しています。
- チャネルの身分：WeChat、企業WeChat、Feishu、DingTalkは入口として利用できますが、従業員の身元、会話、およびTraceは統一する必要があり、各チャネルで別々に記録を保持することは禁止されています。
- セキュリティ：モデル設定は既存の設定番号のみを参照し、ベンダーの秘密鍵は返送しません。ツールの結果をTraceに取り込む際には、機密情報を非表示化します。
- 人的なバックアップ：タイムアウト、低信頼度、権限外、ユーザーによる積極的なオペレーターへの転送――この4つの条件すべてにおいて、コンテキストを完全に引き継ぐことができる。
検収では「チャットができる」だけをテストしてはいけません。一連の再現可能なスクリプトを用意し、正常なクローズド・ループ、途中での質問挿入、残高不足、インターフェースのタイムアウト、権限外の書き込み、出所不明による回答拒否といったケースを網羅します。各スクリプトについて、ノードが復旧しているか、伝票が正しく書き込まれているか、トレースが完全であるか、例外が担当者に適切に処理されているかを確認します。サンプル検査の通過率、タイムアウト処理率、根拠のない回答の回数は、満足度の星評価よりも、システムの運用開始に際する門戸管理の指標として適しています。
リリース順序：まず、重複する作業を一段階実施します
最初から万能アシスタントを目指してはいけません。営業フォローアップの要約、承認の催促、制度に関する質問・回答、あるいは経費の事前審査といった業務の中で、毎日30分以上繰り返される部分を選び、入力・出力・権限・例外の四つの要素を四文で整理し、それにSOPと読み取り専用または制限付き書き込みのインターフェースを二つほど付ければよいのです。マスターデータが汚れていたり、承認フローのノードが明確でない場合は、まず対象やステータスを補完し、そのうえでスマートな実行を重ねます。汚れたデータが自動化されれば、社内全体に伝わるスピードはさらに速くなるでしょう。
デザインが正しくできたかどうかは、もはやグループによる催促や表への記入に頼る段階ではなくなりました。議事録や催促、集計は伝票と照らし合わせて抜き取り検査が可能です。不明瞭な状況には昇格対象があり、機密性の高い操作には審査者がおり、ログも確認できます。開発が適格であるかどうかを判断するには、同じSOPが中断された後、復元できるかどうか、回答は出典にリンクできますか、境界ケースは次の改訂段階に進めるかどうか。この三つの項目がクリアされれば、その後に人員を増やす方が、まず多くのチャット入口を設けるよりも安定しています。
デジタル従業員システムの技術的難易度は、対話生成にあるのではなく、職務・プロセス・知識・ツール・履歴をバージョン管理可能なソフトウェアオブジェクトとして構築することにあります。プロンプトは週に十回でも変更できますが、オブジェクトモデルが一度崩れてしまうと、その後の各スキルごとに別々の実装を書かなければならなくなります。まずはこれら七種類のオブジェクトとステートマシンを確立して正常に動作させたうえでこそ、モデルのアップグレードが実行可能になります。そうでなければ、モデルを変更するたびに新たなプロジェクトとなり、単なる設定変更にはなりません。