/always-on-agent-applications — 持続性 + メモリが実際にもたらすもの
これは、エピソディックメモリを持つ常時稼働AIエージェントで何を構築するか悩んでいる人を支援するスキルです。「だから何なのか？」に答えるスキルです。アーキテクチャは存在し、入力は流れている。では、ステートレスのチャットボットにはできない、具体的に何ができるのか？
判断ポイント
1. 常時稼働 vs セッションベース 決定木
タスク要件を評価:
├─ タスクにセッションをまたいだ記憶が必要か?
│ └─ いいえ → セッションベースのエージェントを使用（低コスト、シンプル）
│ └─ はい ↓
├─ タスクにプロアクティブな動作が有効か?
│ └─ いいえ → メモリ付きスケジュールエージェントを使用
│ └─ はい ↓
├─ [持続性ROI] > [インフラコスト]?
│ └─ いいえ → セッションベースで開始し、後でアップグレード
│ └─ はい ↓
├─ ドメインは品質の高いメモリを実現できるほど狭いか?
│ └─ いいえ → スコープを絞る（会議のみ、コードのみ）
│ └─ はい → 常時稼働エージェントを構築
ROI計算:
- 持続性ROI = (タスク頻度 × タスクあたりの節約時間 × ユーザーの時給価値)
- インフラコスト = (サーバーコスト + メモリストレージ + 開発時間)
ROI > 3倍のコスト: 常時稼働を構築 ROI 1～3倍のコスト: セッションベースで開始し、まず価値を証明 ROI < 1倍のコスト: 既存ツールを使用
2. アプリケーションカテゴリの選択
ユーザーが「何を作ればいい？」と尋ねる:
├─ 主要ワークフローはコーディングか?
│ └─ はい → 開発者コンパニオンパターン
│ └─ いいえ ↓
├─ 主要なニーズは会議/コミュニケーションのオーバーヘッド削減か?
│ └─ はい → パーソナルチーフオブスタッフパターン
│ └─ いいえ ↓
├─ 主な目標は学習/知識作業か?
│ └─ はい → 学習ジャーナルパターン
│ └─ いいえ ↓
├─ 焦点は健康/習慣トラッキングか?
│ └─ はい → 健康観察者パターン（高い安全性への配慮が必要）
│ └─ いいえ → プロジェクトオーケストレーターまたはアンビエントインテリジェンス
3. スコープ境界の決定
ユーザーがマルチドメインエージェントを提案:
├─ これが初めての永続エージェントか?
│ └─ はい → 単一垂直領域に強制（最もROIの高いものを選択）
│ └─ いいえ ↓
├─ 開発期間が6か月以上あるか?
│ └─ いいえ → 単一垂直領域のみ
│ └─ はい ↓
├─ 各ドメインの成功指標を定義できるか?
│ └─ いいえ → 定義できるまでスコープを縮小
│ └─ はい → ステージングロールアウトでマルチドメインを許可
4. プロアクティブ動作の調整
エージェントの割り込み頻度を設定:
├─ ユーザーの作業スタイルは深い集中ブロックか?
│ └─ はい → 通知をバッチ処理し、集中シグナルを尊重
│ └─ いいえ ↓
├─ ユーザーが明示的に高頻度の支援を要求?
│ └─ はい → 関連性しきい値を設けてリアルタイム割り込みを許可
│ └─ いいえ ↓
├─ デフォルト: 80%リアクティブ、15%パッシブプロアクティブ、5%アクティブプロアクティブ
障害モード
1. 記憶捏造症候群
症状: エージェントが自信満々に、実際には発生していない会話やイベントを参照する 検出ルール: エージェントが特定の引用/日付/事実を主張するが、正確なソースタイムスタンプを提供できない 根本原因: 取得されたコンテキストと生成された応答の間のメモリ境界が不適切 対策: 厳格なメモリ引用要件を実装 – エージェントはすべての主張を特定のメモリエントリとタイムスタンプにリンクする必要がある
2. メモリ汚染カスケード
症状: エージェントのパフォーマンスが時間とともに劣化し、矛盾した情報が応答に現れる 検出ルール: エージェントが7日以内に同じトピックについて、変更を認識せずに矛盾するアドバイスをする 根本原因: 低品質な観測が価値あるシグナルよりも速く蓄積される 対策: メモリ衛生の実装: 関連性スコアリング、自動圧縮、ユーザートリガーによるメモリクリーンアップ
3. コスト増大爆発
症状: 毎月の請求額が価値の比例的な増加なしに30%以上増加する 検出ルール: 有用なインタラクションあたりのコストが30日間でベースラインより50%以上上昇 根本原因: エージェントが低価値の入力（通知、スパム、自動メール）を過剰処理している 対策: 入力フィルタリングパイプライン、メモリアクセス予算、自動スロットリング付きプロアクティブコスト監視
4. スコープクリープ麻痺
症状: エージェントがすべてを処理しようとし、何にも秀でず、ユーザーが2週間で放棄する 検出ルール: エージェントが5つ以上の異なるアプリケーション垂直領域を持ち、それぞれに明確な成功指標がない 根本原因: 集中ツールではなく、「汎用アシスタント」を構築している 対策: 単一垂直領域から開始し、拡張前に卒業基準を要求する
5. プライバシー侵犯ドリフト
症状: エージェントが誤ってコンテキストをまたいで機密情報を共有する 検出ルール: エージェントが誤ったコンテキストで個人/仕事の詳細に言及する（仕事のチャットで個人情報） 根本原因: メモリ境界がユーザーのプライバシー期待と一致していない 対策: コンテキスト分離、明示的なメモリ区分化、定期的なプライバシー監査
実践例
例: 開発者コンパニオンエージェントの構築
シナリオ: ソフトウェアエンジニアがコードレビューとPR説明文の作成を支援するエージェントを希望
ステップ 1 - スコープ定義
- ユーザー: 「より良いコーディングを支援するAIが欲しい」
- 決定木を適用: コーディングワークフロー = 開発者コンパニオンパターン
- スコープを絞る: 「PR説明文の生成のみ」（フルコーディングアシスタントではない）
ステップ 2 - ROI計算
- タスク頻度: 1日3PR × 5日 = 週15PR
- 節約時間: PR説明文あたり5分 = 週75分 = 年間65時間
- ユーザー価値: 時給150ドル × 65時間 = 年間9,750ドル
- インフラコスト: 月額約50ドル = 年間600ドル
- ROI = 16倍 → 常時稼働エージェントを構築
ステップ 3 - メモリ戦略
- コアメモリ: 現在の機能ブランチ、最後の5コミット、コード変更に関する最近の会話
- リコールメモリ: ユーザーが好むPRテンプレート、レビュアーのフィードバックパターン、プロジェクトコーディング標準
- アーカイブ: 過去のPR、チームのコミュニケーションスタイル、プロジェクトの決定と根拠
ステップ 4 - トリガー設計
triggers:
- git_push_to_feature_branch: PR説明文を下書き
- pr_opened: コンテキストで説明文を強化
- code_review_received: 将来のためにフィードバックパターンを記録
ステップ 5 - 品質基準
- PR説明文には実際の根拠が含まれる（一般的な要約ではない）
- エージェントは言及された特定のコミット/ファイルを参照する
- 生成された説明文の80%が2分未満の編集で済む
- PRが複数の懸念事項にまたがる場合、エージェントが正しく識別する
初心者が見逃しがちなこと: 「あらゆるものに対応するAIコーディングアシスタント」を目指すこと エキスパートが見抜くこと: 持続性がステートレスなソリューションよりも明確な優位性を生み出す、単一の高価値ワークフロー（PR説明文）に焦点を当てること
品質基準
すべての条件が満たされたときにアプリケーション設計が完了:
- コストの3倍以上の利益を示す明確なROI計算
- 定義された境界を持つ単一垂直領域のスコープ
- 圧縮戦略によりメモリ増加が抑制されている
- プロアクティブ動作の頻度が設定されている（全インタラクションの20%未満）
- 成功指標が定義され、測定可能である
- ユーザーのプライバシー境界が明示的にマッピングされている
- メモリが蓄積されていなくてもコールドスタート体験が機能する
- ユーザーのメモリ制御のためのキルスイッチが実装されている
- 自動スロットリングしきい値を設定したコスト監視が行われている
- スコープ拡張のための卒業基準が定義されている
使用禁止の境界
このスキルは以下の目的には使用しないでください:
- メモリアーキテクチャの構築 → 代わりに
always-on-agent-architectureを使用 - 入力フィードとトリガーの設計 → 代わりに
always-on-agent-inputsを使用 - 安全性、プライバシー、コストに関する懸念 → 代わりに
always-on-agent-safetyを使用 - 一般的なエージェントパターンとループ → 代わりに
agentic-patternsを使用 - AI安全リスクの評価 → 代わりに
ai-safety-engineerを使用 - 技術インフラの決定 → 代わりに
systems-architectureを使用
ユーザーが以下の質問をした場合は、他のスキルに委譲してください:
- 「エピソディックメモリはどうやって保存するの？」 →
always-on-agent-architecture - 「エージェントは何を監視すべき？」 →
always-on-agent-inputs - 「これは安全/プライベート？」 →
always-on-agent-safety - 「エージェントループはどうやって構築するの？」 →
agentic-patterns