長時間エージェントの文脈は要約より分割で軽くする。AI自動執筆38本の実測から

📖 この記事で分かること

• LangChainとScaleDownが示した文脈管理の3つの手
• 1本の仕事を短い起動に分けた自動執筆の実測
• 圧縮と分割、どちらを先に検討すべきかの判断
• 圧縮を入れる前に用意しておきたい検査

💡 知っておきたい用語

• 文脈(コンテキスト):AIが1回の応答で読む材料の全部。会話の履歴やツールの結果が積もるほど重く、高くなる

最終更新日: 2026年10月15日

▶ 公式ページ

• Building Long-Running Agents with ScaleDown and Deep Agents(LangChain Blog)
• ScaleDown ドキュメント(ScaleDown)

長く走るエージェントの「重さ」をどう減らすか

この記事のポイント

• LangChainが2026年10月13日、ScaleDownの専用モデルで長時間エージェントの文脈を要約・圧縮する連携を公開しました。
• 編集部は10月1日から15日朝まで、記事の自動執筆を毎回まっさらな短い起動で回し、38本を投稿しました。
• 編集部の結論は、圧縮の前に「仕事を分けて、渡すものを決める」が先、です。

AIエージェントに長い仕事を任せている開発者は、積もった履歴やツール結果の整理を、本体のLLMとは別の専用モデルに任せられるようになります。LangChainが10月13日に公開したScaleDownとの連携で、履歴とツール結果が積もって1手ごとに高く・遅くなる問題への答えです。本記事では、その発表を読んだうえで、tech-noisy.com 自身の自動執筆の運用記録と照らし、編集部がどちらの手を先に取るべきだと見ているかを書きます。

LangChainの発表は、エージェントの基盤「Deep Agents」に、ScaleDownのモデルを中間処理(ミドルウェア)として差し込む langchain-scaledown パッケージを紹介するものです。ScaleDownのモデルは制約付きデコーディングモデル(CDM)と呼ばれ、LangChainは「汎用のLLMが任意の文字列を1トークンずつ書くのに対し、CDMは1つの仕事のために訓練され、その仕事が許す答えだけを返す」と説明しています。

差し込み方は3つです。

• 要約(ScaledownSummarizationMiddleware): 履歴が閾値に達したら、古い履歴を短い要約に置き換え、直近のメッセージは残す。コード例では、文脈の8割に達したら発動し、1割を残す設定が示されています
• ツール結果の圧縮(ScaledownToolCompressionMiddleware): エージェントが「何を知りたいか」を問いとして渡し、ツールの結果から必要な部分だけを抜いてからモデルに見せる。EUの注文の返金規定を問いにした例で、長いドキュメントのページを18,402文字から3,110文字へ、ほぼ9割削ったとしています
• 抽出(ScaledownExtractionMiddleware): 最初の呼び出しの前に、ユーザーのメッセージから注文番号やエラー文などの項目を構造化して取り出し、エージェントの状態に保存する

なぜこの話題か

この媒体の記事は、AIの書き手が1日3枠(木曜の14時は視点記事)で下書きを作り、人が承認してから公開しています。長時間エージェントの文脈をどう扱うかは、編集部にとって他人事ではなく、毎日の運用で設計を決めてきた問題です。ScaleDownの発表が「詰めて小さくする」側の答えだとすれば、編集部はここ2週間「そもそも溜めない」側で運用してきました。両方を並べると、読者が自分のエージェントでどちらを先に試すべきかの判断材料になると考え、取り上げます。

運用で見ている景色

編集部の自動執筆は、1回の起動で記事1本だけを書き、終わったら何も覚えずに消える作りです。前回の会話を引き継ぐことはありません。以下は、編集部が自分たちの実行記録(2026年10月1日〜15日朝)から数えた値です。

記憶はAIではなく、サーバに持たせる

書き手が起動すると、最初にサーバから「今日の計画」を受け取ります。中身は、今の枠・読者層・題材の候補・直近に書いた話題の一覧・承認済みの改善指示です。直近の話題は、本文ではなく「主題の短いキー」で渡します。この記事を書いている回の計画では、直近の8本分がキーとして入り、計画データ全体は3,784バイトでした。

同じ題材を二度書いていないか、上限に達していないかといった判断もサーバ側が決まった規則と判定モデルで行い、書き手は結果を受け取るだけです。書き手に「これまでの経緯」を覚えさせないので、履歴が積もる場所がそもそもありません。

1本の仕事を、さらに2回の起動に分ける

10月2日からは、一部の枠で1本の仕事をさらに分けています。

• 調べる回: 使える道具はWeb検索とページ取得だけ。出力は題材候補のJSONだけを受け取る
• 書く回: 道具は持たせない。プログラムが記事の書き方と、調べる回で集めた材料をまとめて渡し、本文だけを書かせる
• 間をつなぐプログラム: 重複の照会、一次ソースの照合、文章の検査、投稿はAIではなくプログラムが行う

それぞれの回には上限時間があり、調べる回は900秒、書く回は600秒です。外部のページを読む回と、文章を書く回で、必要な材料も権限も違うので、混ぜないことにしました。

数字で見るとこうなった

10月1日から15日朝までに、書き手が投稿まで終えた起動は38回でした。

• 1回の起動で全部を行う従来の形: 16回、平均約4.1分、最長約5.9分
• 調べる回と書く回に分けた形: 22回、平均約4.4分、最長約5.7分
• 38回のうち36回は、最初の投稿で通った(残り2回は検査の指摘を直して2回目で通過)

ほかに、題材がすべて既出だった・枠の担当外だったなどで書かずに終えた起動が6回、起動直後に2秒で落ちた失敗が1回ありました。分けた形は、全体の所要時間がほとんど変わらないまま、各回の材料と権限を絞れています。

要約は、数字を言い換えることがある

分けて運用して気づいたのは、間に要約を挟む場所が、数値が崩れる場所でもあることです。この記事の下調べでも使っているページ取得の道具は、ページを小さなモデルで要約してから返します。これはScaleDownの「ツール結果の圧縮」と同じ種類の処理です。そこで編集部のプログラムは、調べる回が拾った引用文が一次ソースの原文に本当に含まれるかを、ページを取り直して照合しています。要約を挟むなら、要約の外で原文と突き合わせる検査も一緒に置く、というのが編集部の設計です。

ScaleDownの数字をどう読むか

ScaleDownの数字は大きいですが、比較の条件を確かめてから使う必要があります。LangChainの記事によると、要約はコストが41分の1で2.7倍速く、圧縮はコストが138分の1で1.8倍速く、精度もどちらも上回ったとしています。比較の相手は、GPT-5.5・GPT-5.4 Mini・GPT-5.4 Nano(2026年10月時点)の平均で、公開データセットで測ったものです。ScaleDown自身は、こうした限られた仕事でフロンティアモデルより200倍速く、467倍安いと説明しています。

つまり、自社のエージェントが扱う文書や、手元で使っているモデルとの比較ではありません。また、ScaleDownのモデルはAPIキーで呼ぶホスト型のAPIで、ツールの結果や履歴はScaleDown側へ送られます。入力は最大100万トークン(2026年10月時点)、新規アカウントには5,000万トークンの無料枠(2026年10月時点)があるとしています。

LangChain自身も使いどころを線引きしており、「コードを書く、返信の下書きを作る、計画を立てるといった自由な生成には、汎用のLLMを残す」と書いています。CDMが向くのは、決まった形の答えを返す整理の仕事です。

編集部の見方

編集部は、長時間エージェントの文脈が重くなったとき、最初に取るべき手は圧縮ではなく「仕事を分けて、段の間で渡すものを決める」ことだと見ています。圧縮は、分けてもなお大きくなる部分、たとえば長いドキュメントやログを読む段に限って入れるのがよい、という立場です。

理由は3つあります。

• 分ければ、溜まる場所が消える: 編集部の書き手は毎回まっさらに起動し、経緯はサーバが短いキーで渡します。今日の計画は3,784バイトで、要約で縮める対象になる履歴がそもそもありません
• 分けても、速さはほとんど落ちなかった: 1回で全部やる形の平均約4.1分に対し、2回に分けた形は約4.4分でした。各回の材料と権限を絞れることに比べれば、差は小さいと判断しています
• 要約は、数字や固有名詞が崩れうる段を新しく作る: 編集部は要約の外で原文との照合を置いています。圧縮を入れるなら、この検査の費用も含めて考える必要があります。LangChainの記事は精度が上回ったとしていますが、その比較は公開データセットでのものです

一方で、ScaleDownの「ツール結果の圧縮」には、編集部としても期待しています。問いを渡して必要な部分だけ抜く形は、長いドキュメントを読む段にそのまま当てはまり、編集部の調べる回が抱えている「ページ全体を読むか、要約に頼るか」の悩みに近いからです。

この見方が変わる条件もあります。1本の仕事が数時間続き、途中の判断の積み重ねそのものが成果になる仕事(長いコーディング作業など)では、編集部のように「毎回まっさら」には分けられません。そうした仕事では、要約で履歴を持ち続けるScaleDown型の手が先に来ます。編集部の仕事は1回6分以内に収まる短い仕事で、この点で読者のエージェントとは条件が違います。また、編集部は1回ごとのトークン数や費用を計測しておらず、分割による費用の差は数字で示せていません。

読者への提案

自分のエージェントの文脈が重いと感じている開発者に、編集部が勧める順番は次の3つです。

1. 1回の実行を「外の文章を読む段」と「決める・書く段」に分けられないかを見る。段の間で渡すものを、JSONなど決まった形で書き出せるなら、履歴を丸ごと持ち越す必要はありません。経緯の記録は、AIではなくデータベースやファイルに持たせられます
2. 圧縮や要約を入れるなら、先に「残ったかどうか」の検査を作る。数値・日付・固有名詞・URLが原文に含まれるかを機械で突き合わせるだけでも、要約による言い換えを拾えます
3. ScaleDownの費用比較は、自分の条件で測り直す。記事の数字は3つのモデルの平均と公開データセットでの比較です。自社の文書と、いま実際に使っているモデルで、要約前後の精度と費用を比べてから判断するのが確実です。社外に出せないデータを扱う場合は、ホスト型APIへ送ってよいかの確認も先に済ませておく必要があります

よくある質問

Q: ScaleDownはLangChain以外でも使えますか?

A: 今回の記事が紹介しているのは、LangChainのDeep Agents向けの langchain-scaledown パッケージです。ほかの基盤との連携は、この記事の範囲では扱われていません。ScaleDownのドキュメントで確認するのが確実です。

Q: 文脈を分割すると、AIは前の判断を忘れてしまいませんか?

A: 忘れます。そのため、編集部では「何を書いたか」「何が上限か」といった次の判断に要る情報だけを、サーバが短いキーや数値で渡しています。忘れてよいことと、渡すべきことを分けるのが分割の設計の中心です。

Q: 要約と圧縮はどう違いますか?

A: LangChainの記事では、要約は古い会話履歴を短くまとめて置き換える処理、圧縮はツールの結果から問いに関係する部分だけを抜き出す処理として、別々のミドルウェアになっています。

まとめ

LangChainとScaleDownは、長時間エージェントの文脈を専用モデルで要約・圧縮する手を示しました。編集部は自動執筆を毎回まっさらな短い起動で回し、38本を投稿するなかで、経緯をサーバに持たせ、仕事を段に分けるだけで文脈が溜まらないことを確かめています。まず分け、分けても大きい段にだけ圧縮を入れ、その外に原文との照合を置く。これが、編集部が勧める順番です。

【用語解説】

• Deep Agents: LangChainが提供する、長い仕事をこなすエージェントを組むための基盤。要約の中間処理や、状態を保存する仕組みを備える
• ミドルウェア: エージェントとモデルの間に差し込み、入出力を加工する部品
• CDM【シーディーエム】: 制約付きデコーディングモデル。1つの仕事のために訓練され、その仕事が許す形の答えだけを返すモデル

引用元:

• [1] Building Long-Running Agents with ScaleDown and Deep Agents(LangChain Blog)

この記事について: AI 支援で執筆、編集部が事実確認・編集しています。誤りや追加情報があれば Contact よりお知らせください。