定義: 継続委任はユーザーと AI アシスタント間の契約である:一度仕事を伝えると、AI はフォローし続ける——変化がないかチェックし、要約をまとめ、結果を一箇所に集める——そして入力が必要なときや承認が必要なときだけ連絡してくる。これにより 2 つの不満な代替手段が不要になる:手動で硬直的な cron スケジュールを設定することと、チャットで同じ質問を繰り返し聞くことだ。前者は柔軟性がなく、後者は手間がかかる。秘書モデルはこの両方の問題を一度に解決する。ユーザーは最初に何をしたいかを伝えるだけで、あとは秘書が主体的隱私權を持って仕事を進め、重要な変化があったときだけ連絡してくる。
なぜチャットボットは継続タスクを落とすのか
チャットボットはセッションに束縛されている。セッションが終わると、コンテキストは履歴に残るがアクティブなタスクは残らない。リマインダーは設定できるが、何が変わったかを理解せずに指定時刻に発火するだけだ。結果はスレッドに散らばり、時系列でまとまることがない。週次プロジェクト要約が必要なら、毎回自分から覚えているか、別ツールで固定スケジュールを組むしかない。いずれにしても、追跡すべき変化を見逃すリスクがある。
問題はチャットボットが回答下手だということではない。継続的なタスクには異なる契約が必要だということだ——見守り続け、必要なときだけ割り込み、結果を予測可能な場所に集める。既存のチャットボットは「一問一答」に最適化されており、継続的な見守りという異なるパラダイムには対応していない。このギャップこそが秘書モデルの出発点だ。
秘書契約
Semibot の秘書は継続委任を 5 つの設計コミットメントで実装する。各コミットメントはユーザーと秘書間の信頼を構築するためのものだ。これらは独立した機能ではなく、相互に補完し合う仕組みだ。例えば変更認識型の配信は結果収集と組み合わせることで効果を発揮し、同一セッションの連続性は平言語の委仕を実用的にする。
- 平言語での委仕。 「トークンリーセラー市場を監視して、動きがあれば読みを送って」で有効な指示だ。cron 構文は不要だ。リズムを指定すれば秘書は従い、指定しなければデフォルトを提案して伝えてくれる。自然言語で仕事の内容とリズムを伝えるだけで、技術的な設定知識は一切必要ない。
- 変更認識型の配信。 秘書は単にタイマーで動くわけではない。現在の状態を最後に配信した結果と比較する。動きがなければ静かにしている(スケジュール通り配信を依頼しない限り)。これがリマインダーとの決定的な違いだ。変化がないのに報告するのは無駄な割り込みであり、秘書はこれを構造的に避ける。
- 結果の収集。 すべての結果は秘書ページに集約され、セッション・成果物・タスクへのリンクが付く。先週の金曜日にエージェントが作ったものをチャット履歴から探す必要はない。時系列で整理されたフィードとして、過去の成果物にいつでもアクセスできる。
- 必要なときだけ割り込む。 情報不足や承認要求のときだけ ping が来る。中間ステップのたびには来ない。これにより、ユーザーの集中が守られ、割り込みには確実に意味があることが保証される。
- 同一セッションの連続性。 追加要件は同じセッションに入る。秘書はフォローアップごとに新しい会話を作らず、コンテキストを維持する。これにより、同じ作業に関する文脈が途切れず、繰り返しの説明が不要になる。
変革理論
秘書モデルはユーザーと AI の関係を「聞いて受け取る」から「委任してレビューする」に変える。これは従来のチャットボットとの関係とは根本的に異なるパラダイムだ。従来のチャットボットでは、ユーザーが能動的に問いかけを行い、その都度回答を受け取る。秘書モデルでは、ユーザーは一度だけ指示を出し、その後は秘書が主体的に動き、結果だけを届ける。この変化は 3 つの実効果をもたらす:
- 認知負荷のシフト。 何をいつチェックするか覚えておく必要がなくなる。秘書が見張りを担う。ユーザーは判断とレビューに集中でき、監視の負担から解放される。
- 仕事が蓄積する。 チャット履歴に消えていく一問一答ではなく、結果が構造化フィードに集まる。時間が経つとフィードは作業ログになり、チームの知識ベースとして機能する。
- 割り込みがシグナルになる。 秘書はデフォルトで静かなので、ping が来たら何か意味がある——「入力が必要です」か「これが変わったので見てください」だ。通知のノイズ対シグナル比が自然と改善する。
継続委任と他のモデルの比較
既存の手段と秘書モデルを並べると、それぞれの強みと弱みが明確になる。チャットは柔軟だが文脈が持続せず、cron は自動化できるが変化を理解しない。秘書はこの両方の良いところを組み合わせ、さらに構造化された結果の収集を加える。
| 観点 | チャット | cron / リマインダー | 秘書 |
|---|---|---|---|
| 作業の理解 | セッション単位 | なし | あり(ワークスペースコンテキストから) |
| 変化検知 | なし | なし | あり(前回配信と比較) |
| 結果の収集 | チャットに散在 | — | セッションリンク付き秘書ページ |
| cron 構文の必要性 | 不要 | 必要 | 不要(平言語) |
| 承認 | — | — | 既存ゲートと統合 |
秘書がやらないこと
- 承認やフォルダ許可を迂回しない。秘書は Semibot の残りと同じセキュリティモデルを使い、特別な権限を持たない。
- すべての履歴を巨大なチャットに投げ込まない。フォローアップは正しいセッションに束縛されたまま、文脈が散らばらない。
- 設定が欠けているときに見張っているふりをしない。モデルもコネクタもフォルダ許可もなければ、正直に伝える。嘘の安心感は最悪の設計だ。
- 深い創造的作業を代替しない。秘書は監視と要約を担い、深い調査や創造的な執筆は集中セッションの仕事だ。秘書は「何が変わったか」を伝え、判断はユーザーに委ねる。
限界
秘書モデルは強力だが万能ではない。以下の制約を理解した上で活用することが重要だ。これらは現時点での設計上の制約であり、今後の開発で改善される可能性があるが、現時点でユーザーが知っておくべき事項だ:
- スコアリングと生成にモデルプロバイダが必要。それなしでは秘書は有効な仕事ができない。モデルの品質が秘書の出力品質を直接決める。低品質のモデルでは、変化の検知精度や要約の質が低下する。
- 変化検知はテキスト比較であり、意味的理解ではない。微妙な意味の変化や文脈のシフトは見逃されることがある。例えば数字は同じだが意味が変わったケースや、表現のニュアンスが変化したケースは検出しにくい。将来的にはより高度な意味比較が導入される可能性がある。
- 秘書モデルはまだ進化中だ。配信リズム、結果のプレゼンテーション、履歴管理は活発に開発されている領域だ。ユーザーのフィードバックがモデルの改善に直接つながる。現在の使い勝手に不満があれば、それは将来改善される可能性が高い。フィードバックは積極的に行うことが推奨される。
- リアルタイム監視(秒以下)が必要なタスクには、秘書のポーリングモデルは遅すぎる。人間のタイムスケールのチェック(毎時、毎日、毎週)向けに設計されている。株価の秒単位監視のような用途には向かないが、日次や週次の市場動向チェック、週次レポートの自動生成、定期的なステータス確認のような人間のタイムスケールで十分なタスクには最適だ。
実装の選択:スケジューラを作らない自律
秘書の実装で最も注目すべきは「作らない」という決定です。専用のタスクテーブル、スケジューラ、ツールゲートウェイ、承認ステートマシンを新設しません。委任は既存の定期タスクサービスとランタイムを再利用した、配信ポリシーを持つ定期タスクです。scheduled は合意された周期で配信し(必要な「今回の変化なし」を含む)、on_change は関連する変化があったときだけ配信します。自然言語での委任に「毎日」「毎週」という語は不要です。「気にかけておいて」「変化があったら教えて」も継続委任です。周期を解釈できなかった場合、静かに推測するのではなく、毎日の既定値へフォールバックし、それを明示します。
静寂の原則は判定可能な規則として書かれています。重要な変化がなければ変化通知を送らない。合意された配信は定時に報告する。資料が利用不能な場合は「変化なし」とみなさない。この三つは、沈黙で正常性を装うことを防ぎます。変化の判定は「最後に配信された結果」を比較背景とし、それは配信情報であってタスク完了のゲートではありません。
介入側の情報構造は三つの領域に収斂します。結果ストリーム(見る価値のあるもの)、進行中(AI が何をしているか)、あなたの対応が必要(どの段階で必要か)。「あなたの対応が必要」は要約するのは二種類の要求だけです。承認要求と必須情報の補足要求。通常の結果、監視アラート、失敗、検証ギャップは保留義務を生まず、パネルの開閉は承認でも回答でもありません。委任の変更(「毎週にして」「短めに」「あれを一時停止」)は新しいタスクを作らず同じタスク定義を更新し、再開すれば元の要件と履歴を引き継ぎます。効果の指標も明示的です。最初の有用な結果までの時間、配信の採用率、二週間の継続委任の維持率、人間の修正時間。ページビューは成功の基準ではありません。
FAQ
継続委任と秘書モデルについてよく寄せられる質問とその回答をまとめる:
cron 式を書く必要があるか?
いいえ。平言語で有効だ。「毎朝 9 時にチェックして」のような自然な指示で十分だ。リズムを指定しなければ、デフォルトが提案されて表示される。cron 構文を知らなくても、秘書は意図を理解して適切なスケジュールを選ぶ。技術的な知識は一切不要で、普通の日本語で仕事の内容と頻度を伝えるだけで始まる。
スペシャリストとは何が違うのか?
スペシャリストは仕事をどうやるかを記憶する静的な設定だ。秘書は継続的な見張りを担い、時間をかけて結果を届ける動的なプロセスだ。秘書タスクは実際の作業にスペシャリストを使うことがある。つまり秘書は「いつ見るか」を担い、スペシャリストは「どうやるか」を担う。
秘書タスクを一時停止できるか?
はい。タスクは一時停止・再開できる。保留中のアイテムは処理するか却下するまで残る。一時停止中も過去の結果はアーカイブされず、いつでも参照できる。
結果はどこに行くのか?
秘書ページに集約され、セッション・成果物・タスクへのリンクが付く。時系列で整理されたフィード形式で、過去のどの結果にも遡ってアクセスできる。結果は蓄積されるため、数週間前に行われた調査の結果も簡単に見つけられる。秘書ページはあなた自身の作業ログとして機能し、何がいつ行われたかの全体像を把握するのに役立つ。
秘書には追加料金がかかるか?
別のサブスクリプションはない。モデル呼び出しは既存のクォータまたは自前のプロバイダを消費する。秘書のチェック回数が増えればモデル利用量も増えるが、変化がないときは静かにしているため、無駄な呼び出しは少ない。実際には、毎回手動で同じ質問をするより秘書を使った方が、変化がないときはスキップされる分だけモデル利用量が少なくなるケースも多い。秘書はあなたの代わりに状況を判断し、本当に必要なときだけモデルを使う。
