AI Agentのデプロイは始まりにすぎません。

数週間たつと、よくある展開が起きます。起動が遅くなる。あるスケジュールタスクがいつの間にか壊れている。記憶ファイルが太りすぎて、毎回の起動で大量のTokenを使う。「AIをメンテナンスする時間」が、AIによって節約できた時間にじわじわ近づいてきます。

以下はAI Agentシステムを運用して得た実戦経験です。どれも実際に踏んだ落とし穴から残った方法です。

一、起動コストは最も見落とされやすいTokenのブラックホール

新しい会話を始めるたびに、システムは設定ファイル、記憶index、人格定義を読み込みます。これらのファイルサイズが、話し始める前にどれだけTokenを使うかを直接決めます。

起動コストを一通り棚卸しすると、よく気まずい事実に気づきます。ある履歴ファイル1つだけで、起動コストの半分以上を食っている。

AI Agent起動コスト分析図

この種のファイルは、もともとsession間で進捗を引き継ぐために作られたものが多いです。大量の履歴が溜まります。システムが進化した後、その役割は別の仕組みに置き換えられたのに、起動フローから外すことを誰も覚えていません。

やること：起動時に読み込む各ファイルを定期的に棚卸しする。 自分に聞きます。このファイルが最後に本当に使われたのはいつか。答えが「思い出せない」なら、起動時に読む必要はたぶんありません。

使える原則：

  • 起動時に読むのは少数の中核ファイルだけ（人格、identity narrative、現在状態など）
  • それ以外はすべて「必要時読み込み」にし、関連トピックが出た時だけ読む
  • 起動コストは半分以上削れることが多い

二、記憶システム：正典は一つ、二重帳簿にしない

AI Agentには複数の記憶ソースがありがちです。システム内蔵のauto-memory、自作の知識ベース、さまざまなfeedback記録。時間がたつと、同じことが二か所に記録され、しかもバージョンが一致しません。

よくある問題は、内蔵記憶と自作知識ベースが別々に動いていることです。行動修正記録は一か所、プロジェクト知識は別の場所。新しいsessionで古いバージョンを読むことがあります。

解決策：一つの正典（Canonical）位置へ統一する。

memory/
  feedback/    ← 行為矯正（曾經糾正過 AI 的做法）
  user/        ← 個人偏好和背景
  topics/      ← 穩定的知識主題
  YYYY-MM-DD.md ← 每日紀錄
  archive/     ← 自動歸檔的歷史紀錄

システム内蔵記憶は、正典位置を指す超薄いredirectにします。どの入口から入っても、常に同じデータを読むようにします。

より詳しい記憶分層の考え方は、AIアシスタントの記憶はどう設計すべきか と AI Agent記憶システムガイド を参照してください。

三、自動メンテナンスの階層設計

人間が毎日AIシステムの健康状態を手で確認するのは無理です。ただ、全部自動化に任せるのも怖い。安定しやすい方法は、頻度と判断力の必要度で分層することです。

層頻度実行者役割
監視毎時軽量モデル純粋な機械チェック：システムは生きているか？スケジュールは正常か？
日次清掃毎日中位モデルファイル整理 + 記憶アーカイブ + スケジュール健診
週次レビュー毎週強いモデル知識ベース整理 + プロジェクト状態更新 + 自動Gitバックアップ
月次総点検毎月強いモデルcache清掃 + 長期トレンド + 非activeプロジェクト確認

重要な原則：

  • 軽い仕事には軽いモデル：毎時の健康チェックに最強AIは不要です。安いモデルで機械的ルーティングをすれば十分です。
  • 判断力が必要な仕事には強いモデル：記憶アーカイブは「このファイルはまだ役に立つか？」を判断する必要があり、単なるif-elseでは解けません。
  • 複雑な委任チェーンを避ける：「モデルAが起動 → モデルBを呼ぶ → モデルBが実行」のようなチェーンは切れやすいです。直接実行できるなら直接実行します。

AI Agent自動メンテナンス階層アーキテクチャ

四、スケジュールタスクの静かな失敗

健診で最もよく出る重大問題は、複数のスケジュールタスクが何日も壊れていたのに、何の警報もなかったことです。

原因は、タスク実行時にtimeoutしたのに、システムが静かにerrorを記録しただけで誰にも通知しなかったことです。タスクは「動いている」ように見えますが、実際には毎日失敗しています。

修復後、日次清掃スクリプトにスケジュール健診を追加できます。

# 掃描所有排程任務，找出有連續錯誤的
python3 -c "
import json
jobs = json.load(open('cron/jobs.json'))
for j in jobs['jobs']:
    if j.get('enabled') and j['state'].get('consecutiveErrors', 0) > 0:
        print(f'{j[\"name\"]}: {j[\"state\"][\"consecutiveErrors\"]} errors')
"

毎日未明に自動スキャンし、壊れたスケジュールがあれば報告します。人間が偶然見つけることに頼りません。

五、「保存」思考の罠

最後に一つ、考え方の転換です。

最初は「保存」機構を作りたくなります。各会話の終わりに、AIがState Freeze（状態凍結）を書き、「何をしたか、何が残っているか、次の一手」を記録する。さらにckpt（checkpoint）コマンドで手動保存もできる、という仕組みです。

しばらく使うと、この仕組みは実は余分だとわかります。

AIが作業中に状態ファイルを継続更新しているなら、その状態ファイル自体が常に最新です。追加の「保存」動作はいりません。Google DocsでCtrl+Sを押さないのと同じです。もともとリアルタイム保存だからです。

新しい方法：状態ファイルはliveである。 AIは作業中に能動的に更新し、triggerを待ちません。ユーザーはいつ画面を閉じても進捗を失いません。

まとめ：AI運用の中核原則

  1. 起動時ロードを定期的に棚卸しする：毎月一度、「どのファイルを起動時にまだ読む必要があるか」を聞く
  2. 正典を一つにする：すべての記憶を一か所へ統一し、内蔵記憶はredirectにする
  3. 自動化を分層する：機械的な仕事は安いモデル、判断が必要な仕事は強いモデル
  4. スケジュール健康を監視する：失敗したスケジュールを自動スキャンし、人間の偶然発見に頼らない
  5. live状態で保存を置き換える：「保存」機構を作らず、状態を常に最新に保つ

AI Agentの本当の価値は、デプロイした日ではなく、安定して動く100日目です。

関連記事

小企鵝の経験

一番痛いのは本当に記憶です。記憶をうまく扱い、agentに忘れさせないのは難しいです。実戦でのコツは中核ファイルをきれいに整理すること。ファイルが簡潔なほど、agentは各bootで本当に重要なことを覚えやすくなります。OpenClaw上のmulti-agent構成（Opus / Sonnet / ChatGPT）も似た論理で動いています。起動tokenを守り、記憶分層を守ることで、システム全体の安定性が上がります。

よくある質問

Q: AI Agentシステムには定期メンテナンスが必要ですか？

必要です。どんなソフトウェアシステムと同じように、AI Agentの記憶ファイル、cacheデータ、スケジュールタスクは時間とともに蓄積します。メンテナンスしないと、起動が遅くなり、Tokenコストが上がり、スケジュールタスクが静かに失敗します。少なくとも週1回の確認をおすすめします。

Q: AI AgentのToken消費を下げるには？

最大の節約は起動時ロードの削減です。各session開始時にどのファイルを読み込んでいるか確認し、不要になったものを外し、大きなファイルは必要時読み込みへ移します。実務では、古い履歴ファイルを1つ外すだけで起動コストが半分以上減ることもあります。

Q: AI Agentの記憶システムは長期利用に向けてどう設計すべきですか？

鍵は分層です。熱い記憶（現在のtodo）は起動時に必ず読む小さなファイルへ、温かい記憶（最近の出来事）は必要時に読む日次メモへ、冷たい記憶（履歴）は自動アーカイブへ置きます。定期清掃スクリプトと組み合わせ、activeな記憶が無限に膨らまないようにします。

— Penchan