AIエージェントは“忘れる”ことで失敗する

Dev.to / 2026/5/18

💬 オピニオンDeveloper Stack & InfrastructureSignals & Early TrendsIdeas & Deep AnalysisModels & Research

要点

  • AIエージェントは最初の進捗の後、文脈がずれたり要件やアーキテクチャ上の判断が忘れられたりして、長時間の実行で整合性が失われやすく、問題はモデル性能よりもメモリアーキテクチャにあると述べています。
  • エージェントのメモリは、実行を支える長期運用の仕組みとして階層化して扱うべきだという主張で、短期の実行メモリ、長期の永続知識、行動や意思決定に結び付いたイベントベースのメモリを挙げています。
  • 長い対話や自律実行でのドリフトを防ぐため、目的、制約、完了した作業、未解決の障害、実行履歴に継続的に接続し直す内部のリキャップループを導入するとしています。
  • デバッグや長期ワークフローのために、一時的なチャットではなくローカルでの相互作用履歴を完全に参照できることが開発者にとって重要だと述べ、巨大なプロンプトを丸ごと投入するだけに依存しない運用を可能にします。
  • さらに、チーム/役割ベースの委任、文脈共有、作業の引き継ぎ、そして(デフォルトではなく)構成可能なスケジューリングによる目標駆動の自律実行を含む“本物のマルチエージェント統括”の設計も説明しています。

毎日エージェントを使っているなら、すでにそのパターンはご存じでしょう。

最初の20分は魔法みたいに感じます。

そして:

  • コンテキストが徐々にズレていく
  • 要件が忘れられる
  • アーキテクチャの意思決定が消えていく
  • エージェントが同じミスを繰り返す
  • 長時間の実行でゆっくりと一貫性が失われる

問題はもはやモデルの品質ではありません。

問題はメモリアーキテクチャです。

現在の多くのエージェントシステムは、運用メモリではなく、依然として一時的な会話を中心に構築されています。

OnBuzzでは、エージェントを孤立したチャットとしてではなく、システムの中で長時間動作するワーカーのように扱うと何が起こるのかを探ってきました。


メモリは人間のように振る舞う必要がある

すぐに明らかになったことの1つ:

すべてのメモリが同じように振る舞うべきではない。

そこで私たちは、レイヤー構造のメモリシステムを構築しました:

  • アクティブな実行のための短期メモリ
  • 永続的な知識のための長期メモリ
  • アクション、タスク、会話、意思決定に結びついたイベントベースのメモリ

これにより、検索の品質が劇的に変わります。

巨大なコンテキストウィンドウをプロンプトに詰め込むのではなく、必要なときにエージェントが関連する運用コンテキストを取得できます。


リキャップループ(要約・再確認)の重要性が決定的になった

長時間動作するエージェントはドリフトします。

最高のモデルであっても同様です。

そこで、エージェントを次のものへ継続的に再接続する内部のリキャップ機構を実装しました:

  • 元の目的
  • アクティブな制約
  • 完了した作業
  • 未解決のブロッカー
  • 実行履歴

これにより、長い会話や自律実行の間の安定性が大幅に向上します。


ローカルでの完全な相互作用履歴

もう1つ、開発者として強く望んでいたこと:

相互作用履歴にローカルからフルアクセスできること。

一時的なチャットだけではなく。

エージェントは、肥大化したプロンプトに頼るのではなく、運用上のニーズに応じてコンテキストを動的に取得できます。

これにより、デバッグや長時間のワークフローがまったく別物になります。


真のマルチエージェント・オーケストレーション

「複数タブ」ではありません。

実際のオーケストレーション:

  • チーム
  • 役割
  • タスクの委譲
  • コンテキスト共有
  • エージェント間での作業の引き継ぎ

異なるエージェントが担当:

  • アーキテクチャ
  • 実装
  • バリデーション
  • レビュー
  • リサーチ
  • 実行

並行して。


目標駆動の自律実行

エージェントは、実行のたびに一貫性を保ちながら、目的に向けて自律的に動作できます。

ワンショットのプロンプトだけではありません。

スケジューリングと組み合わせることで、エージェントは:

  • 繰り返し実行されるワークフローを作成する
  • 自分自身に対してタスクをスケジュールする
  • 他のエージェントに対してタスクをスケジュールする
  • 時間をまたいで運用上の連続性を維持する

(完全に設定可能。デフォルトでは有効化されていません)


マネージャー・エージェントと動的なエージェント生成

私たちが今まさに探っている、興味深いことの1つ:

他のエージェントを監督するマネージャー・エージェント。

彼らは:

  • 実行を調整する
  • 進捗を監視する
  • 作業を委譲する
  • 目標/タスクに基づいて、実行中に動的に専門エージェントを作成する

また、エージェントが生成してシステムへ動的に取り込める、再利用可能なスキルの実験も行っています。

ワークフローは、チャットを手動で操作するよりも、エンジニアリング・システムを協調させる作業にかなり近い感覚になってきます。


CLI-first + local-first

私たちは、このシステムを開発者にとってネイティブに感じられるものにしたいと考えました。

CLI-first。
Local-first。
フルコントロール。

データはあなたの手元に残ります。


なぜこれが重要なのか

最大の生産性向上は、次のことではありません:
「AIがより速くコードを書く。」

それよりも、運用上の手間を減らすことです。

減るもの:

  • コンテキストを作り直すこと
  • 指示を繰り返すこと
  • ワークフローを手動で調整すること
  • 明らかなことを再チェックすること
  • コンテキスト・クラッシュとの戦い

増えるもの:

  • アーキテクチャを考えること
  • 実行のレバレッジ
  • 並行ワークフロー
  • より速くシステムを出荷すること

最もレバレッジが効く開発者は、たいてい最速でタイピングできる人ではありません。

複雑さを効率よく調整できる人です。

それが、私たちが探ってみたいワークフローの転換点です。

もしこの領域に興味があるなら、エージェントを毎日使って作っている方々からの率直なフィードバックをぜひいただきたいです。

⭐ リポジトリをつける(on the repo)と大いに助かります:
https://github.com/Loxia-ai/onbuzz-community

さらに、フルプラットフォーム向けに懸賞(bounties)とクラウドクレジットを備えたコントリビューター・コアも公開します。