人間による引き継ぎ

管理者がチャネルで直接発言すると、AIはその1つの会話への返信を停止し、返却されるまで沈黙します——押すボタンも、切り替えるモードもなく、グローバル設定には一切触れません。

なぜ「発言」であって、ボタンではないのか

カスタマーサポートツールにおける人間へのハンドオフには3つのモデルがあります。IntercomはAIを交代可能なアサイン先として扱います（人間がメッセージを1件送信＝制御権の移転）。ManyChatは自動化をミュート可能なトラックとして扱います（人間が入力を始めると30分間自動一時停止）。LINE公式アカウントは会話レベルに「一時的な手動チャット」という逃げ道を用意しています（デフォルト1時間、延長可、早期終了可、グローバル設定に影響しないことを明言）。

3社の共通の結論はこうです：担当者は引き継ぐためにまずボタンを押すべきではない。人が会話に飛び込むのは、たいてい何かが起きたからです。その瞬間に操作が1つ増えることは、忘れる機会が1つ増えることを意味します。DuDuClawも同じ道を選びました——管理者が発言した瞬間、引き継ぎが成立します。

仕組み

トリガー条件（意図的に厳格）

次の2つを同時に満たす人の発言だけが引き継ぎをトリガーします：

そのチャネルアカウントがダッシュボードでアイデンティティ紐付けを完了しており、その紐付けが検証済みであること；
紐付け先のダッシュボードアカウントが有効な管理者またはスーパーバイザーであること。

それ以外の人の発言は一切トリガーしません：一般従業員アカウント、チャネルアカウントを入力しただけで検証を完了していない紐付け、まったく紐付けのない未知のアカウント、別のメッセンジャー上の同じid。

まだ誰もダッシュボードでチャネルアカウントを紐付けていないデプロイメント（たとえばインストール直後の一人会社）では、自動引き継ぎは発生しません。これは意図的です：その状況で身元証明として使えるのは「設定された宛先からメッセージが届いた」ことだけであり、チャネル内ではそれは「あなた自身」を意味します——これを適用すると、オーナーが最初の一言を送った瞬間にAIが永久に沈黙する結果になります。このようなデプロイメントでAIを一時停止したい場合は、セーフワード !STOP を使うか、先にダッシュボードでチャネル紐付けを1件完了してください。

チャネルで /takeover と入力すると、現在どの状況にあるかを直接教えてくれます。

引き継ぎ中に起こること

AIはこの会話に対して完全に沈黙します。 回答せず、「一時停止中です」といった説明も投稿しません——人間が対応している最中に、ボットが自分の状態を報告しに出てくること自体が妨害だからです。

メッセージは引き続き記録されます。 引き継ぎ中のすべての発言（管理者のもの、顧客のもの）は会話ログに書き込まれるため、AIが復帰したときにその間何が起きたかを把握でき、断絶した文脈の上に続けることはありません。

スケジュール済みのアクションも一緒に止まります。 ここが最も見落としやすい部分です：「新しい返信」だけをブロックするのでは不十分で、すでに実行中の作業は終了後に結果をプッシュしてきます——人間が対応を終えた後に、ボットの古いメッセージがぽつぽつと現れるのです（ManyChatユーザーが実際に踏んだ罠）。DuDuClawはこの会話に向かうすべてのディスパッチ経路にチェックを入れています：

経路	引き継ぎ中の動作
チャネルからの受信メッセージ	返信しない（メッセージは会話ログに記録される）
自律タスクのディスパッチ	凍結。ディスパッチも人間へのエスカレーションもしない（呼ぶべき人がすでに現場にいる）
自律タスクの進捗プッシュ	保留し、返却後にまとめて配信
自律タスクの「あなたの判断待ち」カード	保留し、返却後に配信（ボタンは完全に保持）
自律タスクの完了通知（全自動モード）	保留し、返却後にまとめて配信
通常のプロアクティブ通知（周知／要確認レベル）	保留し、返却後にまとめて配信
自動化ルールのサーキットブレーカー通知	保留し、返却後に配信（ボタンは完全に保持）
タスクボードのウェイクアップ	スキップ。返却後は通常どおり再開
プロアクティブなケアメッセージ	破棄（1時間遅れの「2時間連続で作業していますよ」は遅れたメッセージではなく、誤ったメッセージ）
定期ジョブ（cron）の結果	破棄（次回の実行が置き換える。実行記録は残る）
委任レポート（サブ従業員の完了報告）	破棄（結果はキューに残り、ダッシュボードから確認可能）

スキップはすべてgatewayログに記録されるため、「なぜAIが話さなかったのか」は常に調べられます——無音のブラックホールにはなりません。

3種類の通知は意図的にブロックしません：高リスクアクションの承認、インストール申請の承認、チャネル障害アラート。この3つはいずれも「要対応」レベル（緊急かつ重要で、実際にあなたの手を必要とする）であり、いま対応中のこの会話とは無関係です。通知ガバナンスはもともとこのレベルをサイレント時間帯の対象外にしており、理由も同じです：割り込みを1回減らすために「このアクションは不可逆かもしれません。承認しますか？」を握りつぶせば、その代償は現実のリスクです。

引き継ぎは会話レベルであり、アカウントレベルではありません。 同じAI従業員は他のグループや他のDMでは通常どおり返信し、同じグループ内のスレッドはそれぞれ独立しています。唯一意図的に広げた点：あるスレッドを引き継ぐと、親チャネルへのプッシュも一緒にブロックされます——人間が話している最中に割り込むくらいなら、1件余分に沈黙するほうを選びます。

ライフサイクル

アクション	方法
開始	管理者が会話内で発言（デフォルト60分）
延長	`/takeover +30m`（`+30`、`30m`、`45min` も受け付ける）
状態確認	`/takeover` — いま誰が引き継ぎ中か、残り何分か
早期返却	`/takeover end`（`結束` も受け付ける）
自動返却	時間切れでAIが自動的に復帰

管理者が一言発するたびに、タイマーはその時点から60分で再スタートします——対応中の会話が途中で突然AIに奪い返されることはありません。逆に、会話を離れて60分経てば自動的に返却されるため、AIをオンに戻し忘れる人もいません。

Slackの例外：Slackは未登録のスラッシュコマンドをクライアント側で遮断するため、/takeover はこちらに一切届きません。Slackでは /duduclaw takeover、/duduclaw takeover +30m、/duduclaw takeover end を使ってください。他のチャネルではどちらの書き方も使えます。

延長には上限があります：max_duration_minutes（デフォルト12時間、ハード上限も12時間）。「永久一時停止」はこの機能の仕事ではありません——それはAI従業員の無効化で行うことです。

同時に起こる3つのこと

引き継ぎが成立する瞬間は、3つではなく1つのアクションです：

この会話へのAI返信を一時停止する；
作業を引き継ぐ：この会話から生まれた未完了の自律タスクを、あなたが対応中としてマークする（ボード上で「AIが作業中」と表示されなくなる）；
アクティビティフィードに記録する：誰がどの会話を引き継ぎ、あわせて何件の作業を引き継いだか。

3つのうちどれか1つでも欠けるとブラックホールが残ります——最も多いのは一時停止だけしてマークしないケースで、ボード上ではそのタスクがまだAIの作業中に見えるため、次に引き継ぐ人はすでに誰かが対応中であることをまったく知りようがありません。

順序は意図的です：まず一時停止（安全に関わる唯一のステップ。失敗すれば引き継ぎ全体が不成立となり、外部への告知も行われない）、次に作業のマーク、最後にアクティビティフィードへの記録。後者2つの失敗は警告を記録するだけで、すでに有効になった一時停止を取り消すことはありません。

会話に表示されるもの

引き継ぎ時、会話に次の1件が表示されます：

👤 王小明 已接手對話，接下來由真人回覆（約 60 分鐘）。

（「王小明がこの会話を引き継ぎました。ここからは人間が返信します（約60分）。」）

返却時：

🤖 AI 已恢復回應。

（「AIが応答を再開しました。」）

この層は自前で作るしかありません。 完全な身元開示を組み込みで備えるのはIntercomだけです（コンプライアンス駆動）。ManyChatの公式FAQは「自動化が一時停止したことを連絡先に自動通知しない」と明言しており、LINEのアーキテクチャにはこの層自体が存在しません。だからDuDuClawはこの2つのメッセージを自分で送信します。

表示される名前はダッシュボードの表示名から取得します。表示名が未設定の場合は「管理員」（管理者）と表示され、チャネルアカウントのidが露出することは決してありません。

設定

~/.duduclaw/config.toml：

[takeover]
enabled = true            # デフォルトで有効。false にするとこの機能を完全に無効化
duration_minutes = 60     # 1回の引き継ぎの長さ
max_duration_minutes = 720  # 延長の上限（ハード上限12時間）

不正な値（0、負数、天文学的な数値）は機能を壊すのではなく、妥当な範囲にクランプされます——設定ファイルの打ち間違いの代償が「AIが二度と話さない」や「一時停止が1秒で終わる」であってはならないからです。

状態は ~/.duduclaw/takeover_state.json に保存され、書き込まれるのはこのファイルだけです。誰も引き継いでいないとき、このファイルは空（または存在しない）です。グローバル設定、agent.toml、チャネル設定には一切触れません——これはLINEの4点セットの中で最も重要な1条であり、担当者が安心してこの機能を使える理由でもあります。

ダッシュボード

takeover.list RPC（スーパーバイザー以上）は、現在引き継がれている会話の一覧を返します：誰が引き継いでいるか、どのチャネルか、残り何分か、あわせてどの作業を引き継いだか。

読み取り専用で、書き込みはありません。 引き継ぎとは「人がその会話の中にいる」という事実そのものです。これをダッシュボードのボタンにすると、第2の認可モデルが生まれ、実際にはその場にいない会話を「引き継ぐ」ことが可能になってしまいます。引き継ぎたければ、その会話の中で発言してください。

既知の境界

スラッシュコマンドは発言に数えません。 管理者が /status と打っても引き継ぎはトリガーされません——コマンドは操作であって、会話ではありません。
保持者は常に1人だけです。 2人目の管理者が同じ会話で発言すると、引き継ぎはその人に移転します（顧客がいま対話している相手は、最後に発言した人だからです）。
返却通知にはbotトークンが必要です。 トークンを解決できないチャネルには「AIが応答を再開しました」の1件は届きませんが、アクティビティフィードには記録が残ります。
期限切れはバックグラウンドジョブに依存しません。 すべてのチェックポイントが現在時刻と比較するため、スイープタスクが動かなくても時間が来ればAIは回答を再開します。バックグラウンドスキャンの役目は返却通知の送信だけです。