🤖 AIエージェントは、自分自身が動くための「実行基盤」を自分で作って改善できるのでしょうか。 タイトル: HarnessDev: Can LLMs Create and Evolve Their Own Agent Harness? URL: ❓ そもそも「ハーネス」とは何ですか 💡 実行ループ・ツール利用・コンテキスト管理・失敗からの復旧・検証など、エージェントを動かす実行基盤のことです。これまでの評価はハーネスを固定してモデル性能だけを測ってきましたが、実際はハーネスの設計品質も実力を大きく左右します。 ❓ LLMは最小限の材料からハーネスを作れますか 💡 わざと弱いシードハーネスから構築させたところ、最高スコアのOpus 4.8でも67.8点にとどまり、人間が作った参照実装（86.2点）には及びませんでした。特にリサーチ・検索領域でのギャップが最も大きかったです。 ❓ 自分でハーネスを改善（進化）させることはできますか 💡 5つのモデルすべてが可視フィードバック上では改善しましたが、隠されたタスクでの改善幅は大幅に縮小。バージョン切り替えの64回中、ノイズを超える明確な改善は2回だけでした。 ❓ 別の実行者モデルに載せ替えても性能は保たれますか 💡 保たれないケースが目立ちました。Opusが作ったハーネスは実行者をGeminiに固定した途端、SWE-Proスコアが69.3から33.0に急落。ハーネスは特定モデルの前提を埋め込んでしまうため、移植性には注意が必要です。 #AIエージェント# #LLM#

単一文書のQ&Aから、数千文書を横断する分析へ——10万社が使うBoxが、Deep Agentsで「AIネイティブ」に生まれ変わった事例です📦 タイトル: Building Box AI: How an Enterprise Content Platform Went AI-Native with Deep Agents URL: 📦 概要 コンテンツ管理プラットフォームBoxが、Deep Agentsを採用して高度な複数文書分析を実現した事例です。親の「Global Agent」がリクエストの意図を分類し、必要に応じて子エージェントをツールとして動的に生成する階層型システムを構築しました。 ❓ 解決する課題 当初のBox AIは単一文書のQ&Aや知識ハブが中心でした。 ・しかし顧客は、数千文書を横断した調査の統合や、契約書をリスクフレームに照らした分析を求めました ・こうした多段階・分野横断のタスクは、従来のRAGベース検索では扱いきれませんでした 💡 方法論と提案手法 ・親のGlobal Agentが意図を分類し、単純なものは自分で、複雑なものは子エージェントを動的に生成して処理します ・全エージェントが共通ツール（BM25・ベクトル検索・構造化Q&A・ファイル操作）にアクセスできます ・子エージェントは隔離コンテキストで動き、ミドルウェア経由で結果を報告します ・ミドルウェアが本番の要：引用生成、プロンプトキャッシング、17万トークン超で自動要約するコンテキスト管理 ・Deep Agents採用の理由は、モデル非依存（OpenAI/Anthropic/Google）と反復速度です 📊 実験結果 / 実績 ・新エージェントの投入が、数ヶ月から数週間に短縮 ・再帰的な親子システムは、当初の専門エージェント構成より4倍速く出荷 ・単純なクエリは子生成をバイパスし、不要なレイテンシを排除 #AIエージェント# #エンタープライズAI#

🔁 キャビネットを34回調べ続けて50ステップで力尽きたエージェントが、同じタスクを17ステップで解けるようになりました。 タイトル: Beyond Memory: Harnessing Long-Horizon Agents with Explicit Belief States URL: 履歴を保持したり圧縮したりするのではなく、「今の世界はこうなっている」という信念を明示的に持ち続けることで長時間タスクを安定させる、学習不要の推論時フレームワークPoSの提案です。 注目ポイントは3つあります。 🗂 信念を構造として持つ 世界状態をEntity・State・Relationの構造で表し、各状態には出所と確信度、可能なら裏づけの証拠まで添えます。環境を網羅的にモデル化せず、行動の実行可能性や目標の充足に効く記録だけを残すのがポイントです。あわせて「まだ知るべきこと」と「まだ達成すべきこと」をギャップとして明示します。 🐞 毎ステップ、信念を検証する Belief Sentinelという検証器が、更新された信念に矛盾がないか、観測やこれまでの証拠と食い違っていないかを毎回チェックし、確定前に修正させます。電子レンジが開と閉の両方で記録されると、マグを入れる前に開けるべきか判断できなくなる、という類の破綻を防ぐ役割です。 🚨 空回りを検知して脱出する 進捗が出ないまま行動し続ける状態をBelief Trappingと呼び、未解決ギャップの残存率・進捗のない遷移の割合・同じ状態の再訪頻度の3指標で検知します。そのうえで挙動パターン（静止・循環・漂流）と詰まっているギャップの種別に分けて診断し、両方に合わせた復旧制約をかけます。 4ベンチマーク・3バックボーンすべてで最高性能を記録し、RCA-100では最強ベースラインを相対37.89%上回りました。総トークンは5倍に増えますが、タスクエージェント自身の消費は20.9%減っています。 #AIエージェント# #コンテキスト管理#

# AIエージェントをソフトウェアに組み込むプラクティス # コンテキスト予算配分 🎯 「全部入れれば精度が上がる」は幻想です。コンテキストウィンドウは有限の予算として管理しましょう。 スロットごとに配分比率を決め、信号密度を最大化するパターンです。 🔥 解決する課題 RAGやメモリを使うエージェントでは、検索結果・会話履歴・システム指示・長期メモリが同じコンテキストウィンドウを奪い合います。情報を詰め込むほどコストは増え、会話が長くなるとシステム指示の割合が縮んで振る舞いが劣化します。さらに"Lost in the Middle"問題により、窓の中盤に置かれた重要な情報が実質的に無視されてしまいます。 💡 提案パターン コンテキストウィンドウをシステム指示・検索結果・会話履歴・メモリなどのスロットに分け、各スロットに最大占有率と優先度を設定します。システム指示は圧縮対象外の固定枠（10〜20%）として先に確保し、検索結果はリランク後にtop-k件に絞り、履歴は窓使用率が閾値を超えたら要約圧縮します。配置順序はLost in the Middle対策として、最重要情報を先頭に、直近入力を末尾に置きます。cost_sensitivityが高い環境ほどtop-kを絞り、圧縮閾値を下げ、履歴を短く保ちます。 ✅ 選定条件 使うとき： - RAGやメモリを使い、投入候補がモデル窓サイズの50%を超えうる - コスト感度が中以上で、投入トークンの増加がコストや推論時間に影響する - 複数ターンの会話で履歴が蓄積し、他の情報のスペースを圧迫する 使わないとき： - 投入情報がシステム指示＋単発入力のみで窓の30%未満に収まる場合 - ロングコンテキストモデルを使い投入量が窓の20%未満、かつコスト感度が低い場合 ⚠️ 落とし穴 - システム指示を圧縮対象にしてはいけません。ツール定義や安全指示が削られると振る舞いが壊れます - リランクなしのtop-kは信号密度が低いです。ベクトル検索上位20件からクロスエンコーダで3〜8件に絞りましょう - 要約圧縮は非可逆です。重要な決定事項や固有名詞が落ちるリスクがあるため、キーワード抽出を併用してください 🔧 実装方針 - コンテキストウィンドウをスロット（system/user/retrieval/history/memory）に分割し、各スロットに最大占有率・優先度・圧縮可否を定義した構造体で管理します - システム指示は圧縮対象外の最高優先度として先に確保し、残りの予算を他スロットに優先度降順で配分します - 検索結果はベクトル検索の上位候補をクロスエンコーダでリランクしてから予算内に収め、信号密度を最大化します - 履歴スロットが予算を超過した場合は要約圧縮を適用し、圧縮前にキーワード抽出して重要情報の欠落を防ぎます #AIエージェント# #ソフトウェアアーキテクチャ#

# AIエージェントをソフトウェアに組み込むプラクティス # コンテキスト予算配分 🎯 「全部入れれば精度が上がる」は幻想です。コンテキストウィンドウは有限の予算として管理しましょう。 スロットごとに配分比率を決め、信号密度を最大化するパターンです。 🔥 解決する課題 RAGやメモリを使うエージェントでは、検索結果・会話履歴・システム指示・長期メモリが同じコンテキストウィンドウを奪い合います。情報を詰め込むほどコストは増え、会話が長くなるとシステム指示の割合が縮んで振る舞いが劣化します。さらに"Lost in the Middle"問題により、窓の中盤に置かれた重要な情報が実質的に無視されてしまいます。 💡 提案パターン コンテキストウィンドウをシステム指示・検索結果・会話履歴・メモリなどのスロットに分け、各スロットに最大占有率と優先度を設定します。システム指示は圧縮対象外の固定枠（10〜20%）として先に確保し、検索結果はリランク後にtop-k件に絞り、履歴は窓使用率が閾値を超えたら要約圧縮します。配置順序はLost in the Middle対策として、最重要情報を先頭に、直近入力を末尾に置きます。cost_sensitivityが高い環境ほどtop-kを絞り、圧縮閾値を下げ、履歴を短く保ちます。 ✅ 選定条件 使うとき： - RAGやメモリを使い、投入候補がモデル窓サイズの50%を超えうる - コスト感度が中以上で、投入トークンの増加がコストや推論時間に影響する - 複数ターンの会話で履歴が蓄積し、他の情報のスペースを圧迫する 使わないとき： - 投入情報がシステム指示＋単発入力のみで窓の30%未満に収まる場合 - ロングコンテキストモデルを使い投入量が窓の20%未満、かつコスト感度が低い場合 ⚠️ 落とし穴 - システム指示を圧縮対象にしてはいけません。ツール定義や安全指示が削られると振る舞いが壊れます - リランクなしのtop-kは信号密度が低いです。ベクトル検索上位20件からクロスエンコーダで3〜8件に絞りましょう - 要約圧縮は非可逆です。重要な決定事項や固有名詞が落ちるリスクがあるため、キーワード抽出を併用してください 🔧 実装方針 - コンテキストウィンドウをスロット（system/user/retrieval/history/memory）に分割し、各スロットに最大占有率・優先度・圧縮可否を定義した構造体で管理します - システム指示は圧縮対象外の最高優先度として先に確保し、残りの予算を他スロットに優先度降順で配分します - 検索結果はベクトル検索の上位候補をクロスエンコーダでリランクしてから予算内に収め、信号密度を最大化します - 履歴スロットが予算を超過した場合は要約圧縮を適用し、圧縮前にキーワード抽出して重要情報の欠落を防ぎます #AIエージェント# #ソフトウェアアーキテクチャ#

# Claude Agent SDKの便利で実践的な使い方 🔍 数百〜数千のツールを効率的に管理し、必要なツールだけオンデマンドでロードできます。 ツール検索は、大量のツールをコンテキストに事前ロードする代わりに、必要なツールだけを実行時に検索・ロードする機能です。 📌 タイトル：多くのツールにスケーリングするツール検索 🔗 URL： 🧩 概要 `ENABLE_TOOL_SEARCH=auto` でツール定義がコンテキストを圧迫する場合に自動的にツール検索を有効化します。50ツールで10〜20Kトークン消費、30〜50ツール超で選択精度が低下する問題を解決します。 🛠 使い方 ```bash export ENABLE_TOOL_SEARCH=auto:5 # コンテキストの5%超で有効化 ``` 🏗 実践的な使い方 ・エンタープライズ MCP サーバー（数百ツール）接続時に、必要なツールだけオンデマンド検索してコンテキスト圧迫を防ぎます。 ・`auto:5` で「ツール定義がコンテキストの5%超ならツール検索を有効化」と自動判定。小規模（10ツール未満）なら `false` で事前ロードの方が高速です。 ・ツール説明に「キーワード、チャネル、日付範囲で Slack メッセージを検索」のような具体的キーワードを入れ、検索ヒット率を向上させます。 💡 ユースケース 🏢 大規模 MCP サーバーのツール管理 💰 トークンコストの最適化 🎯 ツール選択精度の維持 ⚠️ 注意点 Claude Sonnet 4 / Opus 4 以降が必要です（Haiku 非対応）。カタログ上限1万ツール、検索ごとに3〜5ツール返却。Vertex AI とサードパーティ `ANTHROPIC_BASE_URL` ではデフォルト無効です。 #ClaudeAgentSDK# #AI#

# Claude Agent SDKの便利で実践的な使い方 📏 長時間のエージェント実行でコンテキストが溢れる心配はありません。自動圧縮が履歴を賢く管理します。 コンテキストウィンドウと自動圧縮は、長時間実行エージェントで古い履歴を自動要約し、コンテキスト上限を超えずに動作を継続させる仕組みです。 📌 タイトル：コンテキストウィンドウ 🔗 URL： 🧩 概要 エージェントが長時間動作し続けると、ツール呼び出し履歴でコンテキストが膨張します。SDK はコンテキスト上限接近時に古い履歴を自動要約（圧縮）し、重要な情報を維持しながら動作を継続します。`PreCompact` フックで圧縮前に完全トランスクリプトをアーカイブすることも可能です。 🛠 使い方 自動圧縮はデフォルトで有��です。`compact_boundary` メッセージを監視して圧縮タイミングをログに記録できます。`PreCompact` フックで圧縮前のアーカイブ処理を追加できます。 🏗 実践的な使い方 ・圧縮で失われたくない恒久的ルール（タスク目標、変更したファイルパス、テスト結果、決定理由）は CLAUDE.md に書くことで、毎リクエスト再注入されます。 ・`PreCompact` フックで圧縮前の完全トランスクリプトを外部ストレージにアーカイブし、監査ログとして保持します。 ・長尺のリファクタリングタスクで、数十回のツール呼び出し履歴が自動的に要約され、最新のコンテキストに集中して作業を継続できます。 💡 ユースケース 📝 長時間のリファクタリング・デバッグタスク 🗄 監査ログ用の完全トランスクリプト保存 🎯 CLAUDE.md による恒久ルールの維持 ⚠️ 注意点 圧縮により古い履歴の詳細は失われます。絶対に保持したい情報は初期プロンプトではなく CLAUDE.md に記述することで、圧縮の影響を受けません。 #ClaudeAgentSDK# #AI#

TL;DR: 長期エージェントの3大問題（誤差蓄積・コンテキスト腐敗・状態消失）を、Manager-Execute-Audit（MEA）ループで構造的に解決。WeaveBenchで51.8%→80.7%を達成しました。 LongHorizon-Harness: Advancing Long-Horizon Agents for Real-World Tasks ポイント 🔧 Manager: 実行軌跡の外でタスク状態を明示管理。ゴール・受け入れ基準・制約を含む「サブタスクコントラクト」を生成する ⚡ Executor: 過去の軌跡を持ち込まない、バジェット有界の新鮮コンテキストで各サブタスクを実行する 🔍 Auditor: 実行後に読み取り専用で独立検査。完了・整合性・状態更新を3分類でレポートし、ラウンド間の永続メモリとして機能する 🖥️ GUI/CLIハイブリッド: Managerがタスクに応じてインターフェースを選択。AgentAdapterでClaude Code・Codex CLI等を差し替え可能 📊 WeaveBench: PassRate 51.8%→80.7%、Design+60pp・Spatial/3D+50ppの大幅改善 🤖 OSWorld 2.0: Qwen 3.7-Plusで2.8%→8.3%（3倍）、Claude Opus 4.7で20.6%→35.3% 💻 Terminal-Bench: 69.7%→77.2%、かつトークン消費24%減（オーバーヘッドなし） 💡 Manager cost: 総トークンのたった2〜8%。Auditorが19〜38%でほとんどの追加コストを担う 「エージェント能力はモデル単体でなく、モデル＋ハーネス全体の性質」——この視点が長期エージェント設計の出発点になると思います。 #AIAgents# #LLM#

# Codexの機能と実践的な使い方 🔌 Codex を「コードしか触れないエージェント」から「課題管理・DB・デザインツールまで直接操作できる相棒」へ。その鍵が MCP(Model Context Protocol)接続です。 🏷️ タイトル: 外部ツール接続(MCP) 🔗 URL: 📘 概要 MCP は Codex を外部のツールやコンテキストにつなぐ標準プロトコルです。MCP サーバーを登録すると、Codex がそのツールを直接呼び出して読み書きできます。設定は CLI と IDE 拡張で共有され、クライアントを切り替えても同じ構成で動きます。 ⚙️ 機能の説明 ・最も手軽な追加方法は CLI です。`codex mcp add <名前> -- <起動コマンド>` の形で登録し、TUI 内では `/mcp` で稼働中のサーバーを確認できます。 ・トランスポートは2種類あります。ローカルプロセスを起動する STDIO サーバー（`command` / `args` / `env` / `cwd` を指定）と、URL でアクセスする Streamable HTTP サーバー（`url` / `bearer_token_env_var` / `http_headers` を指定）です。 ・認証は環境変数経由の Bearer トークン、または OAuth に対応します。OAuth 対応サーバーは `codex mcp login <名前>` でログインします。 ・ツール単位の制御も可能で、`enabled_tools` / `disabled_tools` で許可・拒否リストを、`default_tools_approval_mode`(`auto`/`prompt`/`approve`)で承認方式を指定できます。 ・`startup_timeout_sec`(既定10秒)や `tool_timeout_sec`(既定60秒)、`required`(起動失敗時に Codex 自体を失敗させる)などの調整項目もあります。 🛠️ 実践的な使い方 ・例えば最新の開発ドキュメントを引ける Context7 を入れるなら `codex mcp add context7 -- npx -y @/upstash/context7-mcp` の1行です。 ・細かく制御したいときは `~/.codex/config.toml`（信頼済みプロジェクトなら `.codex/config.toml`）の `[mcp_servers.<名前>]` セクションに `url` と `bearer_token_env_var`、必要なら `http_headers` を書きます。 💡 ユースケース 課題管理ツールから仕様を読み取り、DB のスキーマを参照しながら実装し、Figma のデザインを取り込んで UI を作る、といった一連の流れを Codex 1つに任せられます。社内 API を MCP サーバー化すれば、独自業務ロジックも Codex から直接叩けます。 ⚠️ 注意点 ・外部ツールに読み書き権限を渡すことになるため、`disabled_tools` や承認モードで権限を絞るのが安全です。 ・トークンは設定ファイルに直書きせず、`bearer_token_env_var` で環境変数から読む形にしましょう。 ・プラグイン提供の MCP サーバーは起動コマンドをユーザーが指定するのではなく、`plugins..mcp_servers.` 配下で有効状態とツールポリシーを制御します。 #OpenAICodex# #MCP#