/always-on-agent-inputs — 永続エージェントへのコンテキスト供給
あなたは、常時稼働型エージェントが見るもの、聞くもの、知るものを設計しています。アーキテクチャスキルはメモリがどこに存在するかを扱います。このスキルは、メモリに入力されるもの、つまり生の信号、それらがどのように構造化されるか、エージェントがいつ起動するか、そしてコンテキストウィンドウを正直に保つ方法を扱います。
決定ポイント
検索戦略の選択
エージェントタスク種類 → 検索戦略
IF 会話/チャット:
├─ 再帰性優先を使用 (70% 時間的, 30% 意味的)
├─ 予算: 15K 会話履歴 + 4K 最近の想起
└─ アーカイブはユーザーが「あの時…」と尋ねない限りスキップ
IF 問題解決/デバッグ:
├─ 関連性優先を使用 (60% 意味的, 40% 時間的)
├─ 予算: 8K アーカイブ + 4K 想起 + 2K アンビエント
└─ 過去の解決策からのエラーパターンを含める
IF コンテキストスイッチを検出:
├─ 頻度ベースを使用 (ユーザーが最もよく取り組んでいるものは?)
├─ 予算: 6K プロジェクトコンテキスト + 2K 最近 + 4K 目標
└─ アクティブなファイル/人物のエンティティ履歴を取得
IF スケジュールトリガー (朝のブリーフィング):
├─ 構造化アジェンダを使用 (カレンダー + タスク + 更新)
├─ 予算: 4K カレンダー + 4K 未完了タスク + 2K 変更
└─ 会話履歴は不要
IF リアクティブトリガー (CI障害、会議開始):
├─ イベント固有のコンテキストローディングを使用
├─ 予算: 8K イベントコンテキスト + 4K 関連履歴
└─ 関連性がない限り一般会話はスキップ
アンビエントデータフィルタリング
画面/音声観測 → フィルタ判断
IF 同じアプリ + 同じテキストが5分以上:
└─ 破棄 (変更なし、ノイズ)
IF アプリスイッチを検出:
├─ 遷移記録を保持
└─ 新しいアプリコンテンツの関連性をスコアリング
IF 高シグナルキーワードを発見:
├─ アクティブなプロジェクト/目標と照合
├─ IF 一致スコア >0.6 → アーカイブ + 想起に保存
├─ IF 一致スコア 0.3-0.6 → 想起のみに保存
└─ IF 一致スコア <0.3 → 破棄
IF 技術的エラー/例外が表示されている:
├─ 常に保存 (デバッグコンテキスト)
└─ 緊急度レベルをタグ付け
IF カレンダーイベントが言及された:
├─ 常に保存 (時間的アンカー)
└─ 実際のカレンダーと相互参照
トリガー緊急度割り当て
イベント種類 + コンテキスト → 緊急度
IF CI障害:
├─ プロダクションブランチ → アクティブ (ユーザーに通知)
├─ フィーチャーブランチ + ユーザーが現在コーディング中 → パッシブ (次にユーザーが関与したときに言及)
└─ 古いブランチ/PR → サイレント (ログのみ)
IF 会議開始:
├─ <5分 → アクティブ (準備で割り込み)
├─ 5-15分 → バッジ (準備が利用可能であることを表示)
└─ >15分 → サイレント (バックグラウンドで準備)
IF コード変更を検出:
├─ 新しいブランチの最初のコミット → パッシブ (新しい作業を記録)
├─ 以前のエラーを修正するコミット → パッシブ (解決を記録)
└─ 通常のコミット → サイレント (進捗を追跡)
IF Slackでメンションされた:
├─ ダイレクトメッセージ → アクティブ (応答が必要)
├─ チャンネルメンション + 緊急キーワード → アクティブ
└─ チャンネルメンション、通常 → バッジ (都合の良いときに確認)
障害モード
スキーマ肥大化
- 症状: コンテキストウィンドウが常に最大、応答が遅い、フィルタリングにもかかわらずトークンコストが高い
- 根本原因: 観測スキーマが、エージェントが推論に必要なフィールドだけではなく、すべてのフィールドをキャプチャしている
- 検出ルール: 平均コンテキストサイズが50Kトークンを超える、または観測ストレージが1MB/日を超える場合、スキーマ肥大化の可能性
- 修正: 毎月スキーマを監査。30日間決定に影響を与えていないフィールドを削除。生のストレージの代わりに要約を使用。
検索スラッシング
- 症状: エージェントが古い情報を引用、最近のコンテキストを見逃す、または無関係な記憶を繰り返し取得する
- 根本原因: リランキングなしの単一パスベクトル検索、または時間的/意味的重みの調整不良
- 検出ルール: 取得コンテキストの30%以上が応答で使用されない、またはユーザーが最近のイベントについてエージェントを訂正する
- 修正: 2段階検索を実装 (広域検索 + リランク)。異なる時間的/意味的重み比率をA/Bテスト。
トリガースパム
- 症状: ユーザーがエージェント通知を無効にする、中断について不満を言う、またはエージェントが無視される
- 根本原因: 緊急度階層がない、またはアクティブ/割り込みトリガーのしきい値が低すぎる
- 検出ルール: ユーザーがアクティブ通知の50%以上を却下する、またはユーザーエンゲージメント間の平均時間が4時間を超える
- 修正: すべてをデフォルトでサイレントに。アクティブ通知を必要とするものをユーザーが明示的に設定できるようにする。却下率を追跡。
コンテキスト陳腐化
- 症状: エージェントが古い情報に基づいて行動する、ユーザーが焦点/プロジェクトを変更したことに気づかない
- 根本原因: コンテキストに鮮度減衰がない、または検索重みが再帰性を十分に考慮していない
- 検出ルール: エージェントが最近のコンテキストが存在するにもかかわらず7日以上前の情報を参照する、または完了したプロジェクトに言及する
- 修正: 関連性スコアに指数減衰を追加。最近の観測をアーカイブより2-3倍高く重み付け。
アンビエントノイズ flooding
- 症状: 高コスト、応答品質低下、エージェントが無関係な画面コンテキストに言及する
- 根本原因: 生のアンビエントデータがフィルタリングをバイパスする、または関連性ゲートが許容範囲すぎる
- 検出ルール: アンビエント観測が保存された記憶の30%以上を占める、またはトークンコストが$10/日を超える
- 修正: 関連性スコアリングを厳格化。アンビエント観測を5分ウィンドウでバッチ処理。関連性を確認するために2つ以上のシグナルを要求。
実践例
シナリオ: トークン予算制約のある請求バグ調査
ユーザー報告: 「エンタープライズ顧客の請求計算が間違っています。」
ステップ1: コンテキスト予算割り当て (合計40K)
システム + アイデンティティ: 4K トークン (固定)
コアメモリ: 2K トークン (ユーザー設定、アクティブプロジェクト)
決定: 問題解決タスク → 関連性優先検索を使用
割り当て: 8K アーカイブ + 4K 想起 + 2K アンビエント + 15K 会話 + 5K 出力バッファ
ステップ2: 検索戦略の実行
# 請求関連記憶の広域意味検索
archival_candidates = vector_search(
query="billing calculation enterprise customer error bug",
top_k=20,
filters={"project": ["billing", "payments"]}
)
# 真の関連性でリランク (埋め込み類似度だけではない)
reranked = rerank_results(archival_candidates, query, top_k=5)
# 結果: 純粋なベクトル検索では12位だった「3週間前のエンタープライズ割引ロジックバグ」を取得
# 最近の請求作業の時間的検索
recent_work = temporal_search(
time_range="last_7_days",
entity_filters=["billing", "enterprise"],
max_results=3
)
# 結果: ユーザーは昨日、価格階層をデバッグしていた
ステップ3: アンビエントコンテキスト統合
# ユーザーが現在何をしているか確認
screen_summary = get_ambient_summary(last_30_minutes)
# 結果: 「ユーザーはbilling_calculator.pyを開いており、
# calculate_enterprise_discount()関数を見ている」
# 予算チェック: 8K アーカイブ + 4K 最近 + 2K アンビエント = 14K (予算内)
ステップ4: 高速 vs 完全のトレードオフ エージェントには2つの選択肢がある:
- 高速検索 (現在): 14Kコンテキスト、最近のバグパターンに焦点
- 完全コンテキスト: git履歴、関連PR議論を追加 (+8Kトークン、予算超過)
決定: 最初の応答は高速検索を維持。ユーザーがより深い調査を求めた場合、拡張コンテキスト予算でフォローアップをトリガー。
エージェント応答品質:
- 初心者アプローチ: 請求関連コンテキストをすべてダンプし、予算超過、混乱した応答になる
- エキスパートアプローチ: 最も関連性の高い14Kコンテキストを厳選し、ベクトル検索だけでは見逃された3週間前の特定のエンタープライズ割引バグに言及、予算内に収まる
品質ゲート
- コンテキストウィンドウ割り当てが階層 (システム/コア/取得/会話) 間で明示的に予算化されている
- ルーチン的な対話でのリクエストあたりのトークン数平均が40K未満
- アンビエント観測が保存前にフィルタリングパイプラインを通過する
- 検索は2段階プロセス (広域検索 + リランキング) を使用する
- すべてのトリガーが緊急度 (サイレント/バッジ/パッシブ/アクティブ/割り込み) で分類されている
- 観測スキーマにタイムスタンプ、信頼度スコア、ソースが含まれている
- フィルタパイプラインがテストされている: 取得コンテキストの30%未満が応答で未使用
- ユーザーがアクティブ通知の20%未満を却下している (トリガースパムチェック)
- エージェントがアーカイブにデフォルトするのではなく、利用可能な場合に最近の情報 (過去24時間) を参照する
- ストレージ成長率がユーザーあたり100MB/週未満 (効率性チェック)
境界外
/always-on-agent-inputs を使用する場合:
- ユーザー環境からどのデータをキャプチャするか決定する
- トリガーと観測スキーマの構造化
- コンテキストウィンドウ予算管理と検索戦略の選択
- アンビエントデータがエージェントに到達する前のフィルタリング
使用しない場合:
- メモリアーキテクチャ設計 (ベクトルストア、データベース、メモリ階層) →
/always-on-agent-architectureを使用 - アプリケーションとユースケースのアイデア出し →
/always-on-agent-applicationsを使用 - キャプチャされたデータのプライバシーと安全性 →
/always-on-agent-safetyを使用 - 一般的なプロンプトエンジニアリング技術 →
/prompt-engineerを使用 - エージェント推論パターン →
/agentic-patternsを使用