定義：注意力戦略とは、AI アシスタントがユーザーに割り込みをかけてもよい条件を決定する一連のルールです。Semibot V3 では、この戦略は保守的にデフォルト設定されています。すべてのシグナルは、重複排除、関連性スコアリング、注意予算制限、リスクポリシーチェック、クールダウンタイマー、ユーザーフィードバック加重を通過してから、初めて通知になることができます。設計哲学は「ノイズを作るくらいなら見逃す」です。この哲学は消極的に見えますが、能動的アシスタントの長期間にわたる有用性を考えれば、むしろ積極的な設計選択です。
能動的アシスタントが失敗する理由
能動的アシスタントの失敗モードは、見逃すことがあることではありません。通知が多すぎることです。通知を多く受け取りすぎたユーザーは通知を完全に無効にし、その後はすべてを見逃します。これは単なる仮説ではなく、通知システム全般に観察される実際のパターンです。電子メールの通知を無効にするユーザー、Slack のメンションをミュートするユーザー、スマートフォンのプッシュ通知を全拒否するユーザー。いずれも同じ動機で行動しています。この非対称なコスト構造を次に示します。
- 通知を 1 つ見逃した場合：ユーザーは後でサマリーを確認してリカバリできます。Agent は見逃された情報をサマリーページに保持し続けるため、取りこぼしは発生しても一時的なものです。
- 通知が多すぎる場合：ユーザーはシステムを永久に無効にします。これはリカバリ不能な状態であり、能動的アシスタントとしての価値を完全に失います。
この非対称性は、デフォルトポリシーとしての抑制を支持します。1 つの有用な通知を見逃すコストと、1 つの不要な通知がユーザーに与える不快感は、同じ重みではありません。不要な通知の蓄積がシステム全体の信頼を侵食するのに対し、見逃しはサマリーという安全網で補完できます。
スコアモデル
すべてのシグナルは、ユーザーに届く前にスコアリングされます。このスコアリングは単純なルールベースではなく、複数の信号源からの加重合成です。
score = ruleScore + recencyScore + relationshipScore + urgencyScore + userPreferenceScore - noisePenalty - cooldownPenalty
各コンポーネントは異なる目的を果たします。ルールスコアは構造的シグナル（新しいコンテンツ、ステータス変更、エラー）を捉えます。近接性スコアは新しいシグナルに高い重み付けをします。関係性スコアはシグナルとユーザーのアクティブタスク間の接続を考慮します。たとえば、ユーザーが現在レビューしているコードに関連する変化は、無関係なプロジェクトの変化より高いスコアを受けます。緊急度スコアは時間感度を加えます。期限が近いタスクに関するシグナルは、期限の遠いものより高いスコアを持ちます。ユーザープリファレンススコアは却下パターンから学習した嗜好を反映します。ノイズペナルティはノイズの多いソースからのシグナルのスコアを減少させます。クールダウンペナルティは前の通知の直後に届いたシグナルを抑制します。
スコアリングの設計思想は、単一の指標で判断しないことです。あるシグナルが緊急度の点で高くても、関連性が低ければ総合スコアは下がります。あるソースが過去にノイズの多いシグナルを多く出していた場合、そのソースからの新しいシグナルにもノイズペナルティが適用されます。この多面的な評価により、一見重要に見えるシグナルが実はユーザーにとって低価値であることを検出しやすくなっています。
閾値層
スコアは 3 つの閾値層に分類され、それぞれ異なる振る舞いを引き起こします。
| 層 | 閾値 | 振る舞い |
|---|---|---|
| 提案 | ≥ 0.70 | 提案エリアに表示、プッシュ通知なし。ユーザーが確認したいときにだけ見える形で提示されます。 |
| 通知 | ≥ 0.82 | プッシュ通知、アクティブ時間帯のみ。ユーザーの作業を中断しますが、高い確信度を持つシグナルに限定されます。 |
| 自動下書き | ≥ 0.90 + 低リスク | 確認なしでアクションを準備。ただし外部への書き込み（メッセージ送信、ファイル公開など）は自動実行しません。内部的な準備作業のみが自動で行われます。 |
この 3 層設計により、低スコアのシグナルは静かに蓄積され、中スコアは適度に通知され、高スコアのみが積極的にユーザーの注意を引きます。すべてのシグナルが同じ優先度で扱われるのを防ぐことで、通知疲れを構造的に回避しています。
注意予算とクールダウン
注意予算は、1 日にユーザーに届けられるシグナルの数を制限します。これは中断に対するスロットルであり、作業に対するスロットルではありません。Agent は継続的に作業できますが、継続的に注意を要求することはできません。この区別は重要です。能動的アシスタントの価値は「働き続ける」ことにあるので、作業自体を制限すべきではありません。制限すべきは「ユーザーに知らせる頻度」だけです。
通知の後、クールダウンタイマーが設定可能な期間中に次の通知を防止します。これは、関連するシグナルが連続して届くというよくある失敗モードを防ぎます。たとえば、あるリポジトリで CI が赤くなったとき、テスト失敗、ビルドエラー、デプロイ失敗という複数のシグナルがほぼ同時に発生します。クールダウンがないと、これらが個別に通知され、ユーザーは短時間に大量の通知を受け取ることになります。クールダウンがあることで、最初の通知から一定期間は新しい通知が抑制され、Agent は複数のシグナルをまとめて 1 つの包括的な通知として届けることができます。
却下フィードバック
ユーザーが提案を却下すると、その却下はユーザープリファレンスの重みを調整し、同様のシグナルの将来のスコアが低くなります。これによりフィードバックループが生まれます。Agent は保守的に開始し、ユーザーの却下が「うるさい」の基準を教え、シグナル対ノイズ比が時間とともに改善します。
代替案である「ユーザーに通知設定を手動で構成させる」という方法は、ほとんどのユーザーが閾値を設定しないため、より悪い結果になります。通知設定の画面を開くユーザーは少なく、開いたとしても最適な閾値を知っているユーザーはさらに少ないです。却下ベースの学習は、ユーザーの行動そのものをフィードバックとして使うため、設定画面を触らなくてもユーザーごとの最適な閾値に収束していきます。初期状態は保守的で、ユーザーが「これはいらない」と思ったものを却下するたびに、システムはそのユーザーにとっての「ちょうどいい通知量」を学習していきます。
限界
- スコアリングにはモデルプロバイダが必要です。利用できない場合、ルールベースのスコアリングへのフォールバックは細やかさに欠けます。ルールベースでは関係性スコアやユーザープリファレンススコアのような動的な要素が失われます。
- アクティブ時間帯は大まかな仕組みです。Agent はあなたのカレンダーを知りません。夜間に重要なデプロイが行われている場合でも、アクティブ時間外であれば通知は抑制されます。
- すべてを却下し続けると、Agent は何も表示しなくなります。正しい振る舞いですが、動かなくなったように感じることがあります。この状態からの回復は、特定のシグナルカテゴリを明示的に許可することで可能です。
- 戦略はグローバルであり、タスクごとではありません。現在の設計では、異なるタスクに異なる通知閾値を設定することはできません。プロジェクト A についてはうるさいほど知らせてほしいが、プロジェクト B は静かにしてほしい、というケースには個別のポリシーが必要です。
実装契約：意思決定空間の直交分解
Semibot の注意力戦略で最も重要な工学的決定は、「通知すべきか」と「AI がそれを許されるか」を二つの直交する意思決定タイプに分解したことです。AttentionDecision（skip / inbox_only / notify / auto_draft）は介入の問題だけに答え、CapabilityDecision（allow / ask_approval / deny）は認可の問題だけに答えます。どちらも他方を代替できません。高スコアの外部書き込み操作は、決して自動実行されず、最大でも「通知」に降格されます。これは規則の積み重ねではなく、意思決定空間の分解であり、「ノイズ削減をどれだけ積極的にしても、越権操作は生まれない」という構造的保証を与えます。
すべてのシグナルは六つのゲートを固定順で通過します。重複除去、関連度スコアリング、注意力バジェット、リスクポリシー、クールダウン、ユーザーフィードバック。順序自体が設計属性です。重複除去が最初にあるため、重複シグナルはスコアやバジェットを消費せず、フィードバックが最後にあるため、現在の決定ではなく今後の類似シグナルにのみ影響します。バジェットは四つの次元（日次・ソース別・リスクレベル別・カテゴリ別）のハード上限で、既定では高優先度通知 3 件/日、中優先度提案 10 件/日。超過分は統合・降格・延期されます。バジェットは合計スコアで補償される軟批判ではなくハードゲートです。これは「スコアが目標になると、システムは判断ではなくスコアを最適化する」という Goodhart の警告と同じ防衛思想の製品化です。
フィードバックループは五つの挙動を定義します。承認は類似シグナルの関連度を上げ、却下は下げ、「こうした通知を減らして」はクールダウンを強化、「後で通知」は降格せず延期のみ、ソースの無効化はそのソースを停止——そして各効果は取り消し可能で、設定から確認できなければなりません。通知は三カテゴリ（高価値な提案、承認待ちの実行、接続認証の破損）のホワイトリストに制限され、メール本文や非公開予定の内容を載せることは禁止です。提示される各提案は四つの問いに答えなければなりません。なぜ重要か、なぜ今か、なぜ権限が必要か、どうすれば減らせるか。実装は AttentionPolicyService として提供され、受け入れテストは予算超過・サイレント時間・高リスクの自動実行禁止を明示的にカバーします。
FAQ
「おやすみモード」と同じですか？
いいえ。おやすみモードはすべての通知を一律に抑制します。注意モデルは選択的です。スコアの高いシグナルはアクティブ時間帯でもあなたに届きます。おやすみモードが時間ベースの全拒否であるのに対し、注意モデルは内容ベースの選択的フィルターです。
無効にできますか？
閾値の調整や特定の通知チャネルの無効化は可能です。スコアモデル自体は常にアクティブです。これがないと、すべてのシグナルが届いてしまいます。完全に無効にすることは、能動的アシスタントとしての機能を放棄することを意味します。
どうやって好みを学習しますか？
あなたの却下行動からです。各却下はそのシグナルカテゴリのユーザープリファレンス重みを調整します。明示的な設定変更は不要です。普段の使い方の中で自然に学習が進みます。
秘書もこれを使いますか？
はい。秘書の変化検知デリバリーは同じ注意パイプラインを通過します。閾値に達しない変化は通知をトリガーしません。秘書が検知した変化はスコアリングされ、ユーザーにとって価値の高いものだけが通知されます。
スコアの値は確認できますか？
現時点ではスコアの値を直接確認するユーザー向けインターフェースはありません。提案エリアに表示されるか、通知されるか、表示されないかという形で間接的にスコアの結果を確認できます。
複数のプロジェクトを同時に行っている場合、どう振る舞いますか？
関係性スコアが現在のアクティブタスクとの関連を評価します。ただし、戦略自体はグローバルであるため、プロジェクトごとの個別設定はできません。すべてのプロジェクトからのシグナルが同じ注意予算を共有します。