結論（忙しい方向け）
- Research-Factory・軌跡分割・段階的RLを組み合わせ、長時間タスクの「粘り」を設計で獲得する
- 小型モデルでもログ設計とチャンク要約で実運用向けの耐性を高められる
- まずは自動ログ収集→チャンク要約で状態継承→カリキュラムで段階的に伸ばす運用を試そう
想定読者: エンジニア
「デモはいい感じなのに、実運用だとエージェントがすぐ迷子になる…」
そんなモヤモヤを抱えているLLMエンジニア向けに、「KLong」という論文をネタにしつつ、“長く考え続けられるAI”の設計パターンをまとめてみました。
この記事を読むと、次のようなことができるようになります。
- 1/10サイズでも長期タスクで粘り強い「KLong」的AIの設計思想がざっくり分かる
- 手元のエージェント（LangChainでも自前実装でもOK）に「長期タスク耐性」を足す具体イメージが持てる
- 「巨大モデル前提の世界線」から、「設計とログで殴る世界線」にメンタルを切り替えられる
GPU貧民勢でも試せる範囲に落としているので、「とりあえずミニKLongごっこ」から始めてみたい人の参考になればうれしいです。
なぜ今“KLong的AI”を押さえてないとキツいのか？【巨大LLM一辺倒からの脱却】
「うちのエージェント、デモでは優秀なんだけど、実運用に乗せると急にポンコツになるんだよね…」
ここ半年くらい、現場のエンジニア仲間からいちばん聞くボヤきがこれです。
よくよく話を聞くと共通しているのが、
- 30分〜1時間くらいのタスクまではいい感じ
- 半日〜1日かかるような“長丁場タスク”になると、途端に迷子になる
というパターン。
実はここに、KLong論文がぶっ刺さる「長時間タスク耐性」というテーマがあります。
あなたのAI、30分を超えたあたりで“記憶喪失”してない？
ふだん触ってるチャットボット系LLMって、だいたいこんな前提で作られています。
- 会話の1ターン〜数十ターンくらいで完結する
- コンテキストはせいぜい数千〜数万トークン
- 「1回の呼び出しでいい感じの答えが返ってくる」世界観
でも、僕らエンジニアが本当に自動化したい仕事って、だいたいこうですよね。
- 新機能の調査 → 仕様詰め → 実装案出し → PoCコードを書く（半日〜数日）
- インシデント調査 → ログ漁り → 暫定対応 → 根本原因分析（数時間〜数日）
- 新技術のキャッチアップ → 社内勉強会資料作り（1日コース）
こういう「長期タスク」を、いまの「一発回答型LLM設計」で殴りにいくとどうなるか。
- プロンプトがどんどん肥大化して、毎回“前回までのあらすじ”を投げ続ける羽目になる
- コンテキスト上限にぶつかり、古いけど大事な情報から順に消えていく
- 途中の判断の良し悪しが、最後の成果物にどう効いたか分からない
結果として、
1時間くらい経つと、本人（エージェント）も何をしてたかよく分からなくなる
という状態になります。
人間の残業でいうと「24時を回った瞬間から作業効率が爆死する」あれです。
「パラメータ増量」では、長期タスク問題はほぼ解決しない
そこで出てくるのが、ここ2年くらいのトレンドだった
「とりあえずデカいモデルをAPIで叩いておけばだいたい良い感じになるでしょ戦略」
なんですが、長期タスク文脈だと、これはあまり効かないんですよね。
ざっくり言うと：
- 巨大LLMは「一発の賢さ」は上がるけど
「10時間の行動全体をどう設計するか」は別問題 - 文脈ウィンドウが伸びても、
「10時間ぶんのログを全部1プロンプトに詰め込める」わけじゃない - モデルが大きいほど、
- 推論コストが高くて
- ステップ数を増やしづらくて
- つまり“長く付き合う”実験がしにくい
つまり、長期タスクでは「モデルサイズ」以外の設計がボトルネックになってきます。
ここにガチで殴り込みにきたのが、KLongが提案する次の3点セットです。
- Research-Factory（長時間タスク用ログを量産する仕組み）
- 軌跡分割（10時間ログを“小分けにしつつつながりを保つ”学習設計）
- 段階的強化学習（短時間タスクから徐々に「粘り」を教え込む）
論文いわく※、
1/10スケールのモデルでも、設計とデータパイプラインを工夫すれば、
“1兆級クラスの巨大モデルより長期タスクで強くなれる” という主張をしているわけですね。
（※論文原典: KLong: 極めて長期的なタスクのための LLM エージェントのトレーニング）
この話を知らないと、どこで損をするのか？
エージェント実装者目線で、「KLong的発想」を知らないと何がキツいかを具体的に書くと：
- GPUとAPI課金で殴るしか選択肢がなくなる
- 「長時間タスクで精度が出ない → もっと強いモデルを使おう」
- の無限ループに入りがち
-
でも会社のカードは有限です…。
-
“長期タスク問題”を、ただの“プロンプト調整不足”だと勘違いする
- 実は設計の問題なのに、
- システムプロンプトを盛る
- 役割を増やす
- ツールを足す
-
みたいな局所対応で消耗し続けることになる
-
エージェントPoCが「デモ動画止まり」で終わる確率が上がる
- 30分のカッコいいデモは作れる
- しかし実務の「半日〜1日タスク」に乗せると破綻
-
現場から「やっぱりAIってまだ早いよね」と言われて冷える、あるあるパターン
-
“属人化している長期業務”にAIを入れる発想が生まれない
- 長期タスクを“学習の単位”として扱えると、
- SREのインシデント対応
- CSの顧客フォロー
- 研究者の文献調査
- といった「ベテランしかできないシリーズ」にも攻め込めるのに、
その入口に気づけないまま終わってしまう。
個人的にはここが一番もったいなくて、
「デカいLLMで一撃必殺」から「小さくても長く付き合えるAI」への発想転換ができるかどうかで、
次の1〜2年のエージェント案件の価値がだいぶ変わる気がしています。
KLongは“巨大モデル不要論”じゃなくて、“設計で戦うための教科書”
誤解してほしくないのは、KLongが言っているのは
- 「巨大モデルはオワコン！これからは小さいモデルの時代だ！」
みたいな極論ではない、ということです。
むしろ、
- 「長期タスクの性能は、“モデルサイズ以外”の軸でまだまだ伸ばせる」
- 「データパイプラインと学習設計をちゃんと作れば、
小さいモデルでも“粘り強いエージェント”は作れる」
という実例を、わりとガチ目のスケールで示した、という位置づけに近い。
なのでこの記事のゴールも、
- 「1兆パラのモデルAPIがないから詰んだ…」から
→ 「設計とログの集め方でまだ戦える余地あるじゃん」
と、メンタルを切り替えてもらうことです。
次のセクション以降では、
- Research-Factory
- 軌跡分割
- 段階的強化学習
この3つがどう噛み合って「10時間耐久で考え続けられるAI」を作っているのかを、
ホワイトボードに描けるレベルまで分解していきます。
KLongの仕組みを“3枚の図”で理解する【長期タスクAIの設計図】
「KLongって名前は分かったけど、結局なにしてるモデルなん？」
という人向けに、一回ざっくり俯瞰図を作っておきます。
細かい数式やパラメータの話に行く前に、
- どうやって練習問題（長期タスク）を集めて
- どうやって10時間ログを“いい感じに小分け”して
- どうやって段階的に「粘り」を教え込んでいるか
を、ホワイトボード3枚ぶんのイメージで押さえます。
図1：Research-Factory ―― “自動インターン”が長期タスクログを量産する
まず1枚目の図は、データ生成パイプラインの全体像です。
雑に ASCII アートにすると、こんな感じの流れを回しています：
[論文検索] → [候補論文セット] → [要約・整理] → [タスク設計] → [エージェント実行] → [評価・スコア] → ログ保存
↑ │
└──────────(フィードバック)─────────┘
論文ではこれを Research-Factory と呼んでいて、イメージ的には
「24時間働き続ける新人研究インターンを大量に雇って、
ひたすら“ちゃんとした調査タスク”のログを集める工場」
みたいなノリです。
やっていることをざっくり分けると：
- 論文探索ステージ
-
既存の論文DBからキーワード検索や引用関係で候補を集める
-
要約・整理ステージ
-
候補論文ごとに要約・貢献・関連研究を抽出して構造化
-
タスク設計ステージ
-
例：
- 「AとBの手法を比較したサーベイを作れ」
- 「この分野の今後の研究課題を列挙しろ」
- 「実験設定を再現するためのTODOを作れ」
-
エージェント実行ステージ
-
KLong候補モデルやベースラインに調査タスクを投げて、10時間クラスで動かし、行動ログを記録
-
評価ステージ
- 出力されたレポートや中間成果を自動・ルールベースで採点し、「この軌跡は良かったか？」を数値化
ポイントは、
- 人間が1つ1つタスクを手作業で設計しているわけじゃない
- 長期タスクに向いた“行動ログ”を自動で量産できる
というところです。
図2：軌跡分割 ―― 10時間ログを“分冊ノート”に分けて学習させる
2枚目の図は、KLongのコアともいえる 軌跡分割（Trajectory Segmentation）。
10時間ぶんの行動ログをそのまま1本のシーケンスとして扱うと、
- メモリも計算も死ぬ
- 「どこが良い判断だったのか」が分かりづらい
- 勾配がノイズまみれで安定しない
ので、
「分冊ノートみたいに小分けにして、でも“つながり”は保つ」
という発想が入ります。
[長期タスク全体の軌跡: T0 ─ T1 ─ T2 ─ ... ─ Tn] （合計10時間）
↓ 軌跡分割（一定ステップ or イベントごと）
[チャンク1] ── [チャンク2] ── [チャンク3] ── ... ── [チャンクK]
(T0〜T50) (T51〜T100) (T101〜T150) ...
│ │ │
├─ サマリS1 ├─ サマリS2 ├─ サマリS3
│ │ │
└─ 状態表現Z1 └─ 状態表現Z2 └─ 状態表現Z3
流れとしては：
- チャンクの切り方を決める
- 時間ベース（例：30分ごと）
- ステップ数ベース（例：LLMコール100回ごと）
-
タスクイベントベース（新しい論文に着手したタイミングなど）
-
各チャンク末尾で「要約＋状態」を作る
- このチャンクで何をやったか
-
現在の仮説・状況
-
次チャンクの入力に、要約＋状態だけを渡す
-
生ログ全部ではなく、圧縮された状態をバトンにする
-
学習時はチャンク単位の短いエピソードとして扱う
RNNのBPTTで長いシーケンスをブツ切りにするのと感覚は近いですが、
- 「タスク的に意味のある区切り」を意識している
- 各チャンクにサマリ＋状態ベクトルを添えて継承している
という点がポイントです。
図3：段階的強化学習 ―― 短時間タスクから「10時間モード」まで育てる
3枚目は 段階的強化学習（Curriculum RL） の図。
AIにいきなり「今日から10時間ぶっ通しでサーベイ書いて」と言うと、だいたい心が折れます。
そこでKLongでは、タスクを段階的に伸ばしていきます。
レベル1：短時間タスク（〜30分相当） - 単一論文の要約 - 1本の論文から研究課題を抜き出す レベル2：中時間タスク（〜数時間） - 2〜3本の論文を比較して整理 - 分野内のトレンドをまとめる レベル3：長時間タスク（〜10時間クラス） - テーマ全体のサーベイレポート - 関連研究マップ＋今後の提案
イメージのグラフ：
タスク難易度 / 時間 ^ | ● レベル3（長期タスク） | ● | ● レベル2（中時間タスク） | ● |● レベル1（短時間タスク） +----------------------------------> 学習ステップ
- レベル1で「とりあえず成功体験」を積ませる
- レベル2・3で少しずつ時間と複雑さを伸ばす
- レベルごとに評価指標や報酬設計も変える
という「ゲームの難易度解放」的な発想です。
枚の図にすると、KLongはこういう“設計思想の塊”
ここまでをまとめると、KLongの設計思想はざっくり：
- Research-Factory
-
長期タスク向けの練習問題と行動ログを自動で量産する「データ工場」
-
軌跡分割
-
10時間ログを小さなチャンクに切りながら、要約＋状態で“記憶のつながり”を維持する仕組み
-
段階的強化学習
- 短時間 → 中時間 → 長時間とカリキュラムを組み、「粘り強く考え続けるクセ」を育てる
この3つさえ押さえておけば、
「KLongって“データ工場 × 分冊ノート × 段階的レベル上げ”で、長期タスクに強いエージェントを育ててるのね」
というイメージはかなり掴めているはずです。
次からは、このうち実装に一番落とし込みやすい「軌跡分割」にフォーカスしていきます。
軌跡分割をエンジニア目線で分解する【コードに落とすとこうなる】
「10時間分のログをそのまま突っ込めば、モデルがなんとかしてくれるでしょ？」
……と一瞬でも思ったあなた。
その発想、GPUと財布が先に死にます。
ここからは、KLongの肝である「軌跡分割（Trajectory Segmentation）」を、
「自分のエージェントコードに組み込むならどう書く？」という視点でバラしていきます。
-1. “10時間分ログをそのまま学習”が事故る3つの理由
長大ログをそのまま流し込むと、だいたいこの3点で詰みます。
理由1：メモリと計算コストがシンプルに死ぬ
- 10時間 × 数秒〜数十秒おきに1ステップ
- 各ステップで観測・行動・ツール結果など
を全部テキストで持っていると、数十万〜数百万トークン級はすぐです。
それを1エピソードとして扱うと、
- VRAMが足りない
- バッチサイズが極小になる
- 1ステップの学習が妙に重い
という、研究としてもしんどい状態になります。
理由2：どのステップが効いたのか分からず、クレジット割り当てが崩壊
10時間タスクの結果（成功／失敗）だけで全ステップに勾配を流そうとすると、
- どこが本当に効いた判断だったのか
- どこはただのノイズだったのか
が分からず、学習が運ゲー化します。
理由3：勾配がノイズまみれで学習が不安定
- 試行錯誤・寄り道・無駄な検索
- などのノイズ行動が長時間分たっぷり混ざる
のに、終端の1スコアだけで評価すると、
ほとんどのステップは「報酬との相関ほぼゼロのノイズ」になってしまいます。
-2. 軌跡分割アルゴリズムをざっくり疑似コードにしてみる
KLong的な分割のノリは、
長軌跡 → 小さなチャンク → チャンク末尾で「サマリ＋状態」生成 → 次チャンクへ渡す
です。
まずは「切るだけ」の関数：
from dataclasses import dataclass
from typing import List, Dict, Any
@dataclass
class Step:
timestamp: float
observation: str # その時点の状況テキスト
action: str # LLMの出力 or 実行したツール
meta: Dict[str, Any] # コストやツール結果など
@dataclass
class Chunk:
steps: List[Step]
summary: str = "" # このチャンクの要約
state_vector: Dict[str, Any] = None # 次チャンクに渡したい“状態”
def segment_trajectory(steps: List[Step], max_steps_per_chunk: int = 50) -> List[Chunk]:
"""長期タスクの軌跡（steps）を、一定ステップ数ごとにチャンクに切る簡易版。"""
chunks: List[Chunk] = []
current_chunk_steps: List[Step] = []
for step in steps:
current_chunk_steps.append(step)
# チャンクを切る条件
if len(current_chunk_steps) >= max_steps_per_chunk:
chunks.append(Chunk(steps=current_chunk_steps))
current_chunk_steps = []
# 余りがあれば最後のチャンクとして追加
if current_chunk_steps:
chunks.append(Chunk(steps=current_chunk_steps))
return chunks
次に、チャンク末尾で「要約＋状態」を作る部分：
def summarize_chunk_with_llm(chunk: Chunk, prev_state: Dict[str, Any] | None) -> Chunk:
"""このチャンク内で何が起きたかを要約し、次チャンク用の“状態”を作る。"""
# 1. ログをテキスト化
log_texts = []
for step in chunk.steps:
log_texts.append(f"[obs] {step.observation}\n[act] {step.action}")
log_block = "\n\n".join(log_texts)
# 2. prev_state も一緒に渡す
system_prompt = """
あなたは長期タスクエージェントのメモリ管理AIです。
与えられたログから、このチャンクで行った重要な決定・発見・保留事項を要約し、
次のチャンクに引き継ぐべき“状態”をJSONで出力してください。
"""
user_prompt = f"""
これまでの状態: {prev_state}
このチャンクのログ:
{log_block}
出力フォーマット:
{{
"summary": "...このチャンクで行ったことの要約...",
"state": {{
"current_hypothesis": "...いま持っている仮説...",
"open_questions": ["...次に解くべき問い..."],
"completed_items": ["...完了したタスク..."]
}}
}}
"""
llm_output = call_llm(system_prompt, user_prompt) # 擬似コード
parsed = json.loads(llm_output)
chunk.summary = parsed["summary"]
chunk.state_vector = parsed["state"]
return chunk
これをチャンク列に適用：
def process_trajectory(steps: List[Step]) -> List[Chunk]:
chunks = segment_trajectory(steps, max_steps_per_chunk=50)
prev_state = None
processed_chunks: List[Chunk] = []
for chunk in chunks:
chunk = summarize_chunk_with_llm(chunk, prev_state)
processed_chunks.append(chunk)
prev_state = chunk.state_vector # 次チャンクへバトンパス
return processed_chunks
この構造は、LangChain や OpenAI Assistants API の
Memory/ スレッド要約
と相性がよく、
- 1チャンク = 1「会話のまとまり」
summary= 要約メモstate_vector= 次プロンプト用の短いJSON状態
として扱えます。
-3. エージェントの“状態の持ち方”3パターン
軌跡分割を自分の案件に持ち込むとき、いちばん悩むのが「状態をどこに持つか？」問題です。
よくある3パターンだけ押さえておきます。
パターンA：会話履歴サマリ型（チャットボット系）
- 直近Nターンだけフル履歴
- それ以前は1本のサマリに圧縮
- プロンプト = サマリ + 直近ログ
向いている例：
- FAQチャットボット
- 社内ヘルプデスクBot
ここに「サマリをJSON化して、次タスク用の状態に寄せる」だけでも、軌跡分割っぽさが出ます。
パターンB：外部メモリDB型（RAGボット系）
- 会話・行動ログをチャンクに分けてベクターストアに保存
- 必要に応じて検索してコンテキストに差し込む
向いている例：
- ナレッジ検索Bot
- 規程・マニュアル検索Bot
KLong的に使うなら、
- 1チャンク = 1タスクのまとまり
state_vectorに「このチャンクで完了したこと」「参照ノートID」を持たせる
と、長期タスクのログもRAGになじみます。
パターンC：チェックポイント＋ログ再生型（リサーチ／運用エージェント）
- ある程度大きな粒度で「途中状態」をチェックポイント保存
- 直近チェックポイント + 差分ログで状態を復元
向いている例：
- 半日〜数日スパンのリサーチエージェント
- スプリントをまたぐ開発支援エージェント
- インシデント対応の振り返り支援
-4. どれを選ぶ？ざっくり指針
- タスク時間が1〜2時間以内
→ まずは A（サマリ型） - 文書量が多く、過去情報を「必要なときだけ」参照したい
→ B（外部メモリDB型） - 半日〜数日単位で「経過」ごと再現したい
→ C（チェックポイント＋ログ再生型）
KLongの軌跡分割は、BとCのハイブリッドに近いです。
-5. LangChain / Assistants で「ミニ軌跡分割」をやるなら
LangChain の場合
- 自前
Memoryや Callback でStepをロギング - Nステップごとにチャンク切り
- チャンク末尾で LLM に
summary＋state_vectorを生成 load_memory_variablesで直近チャンクのsummary/stateをプロンプトに混ぜる
OpenAI Assistants API の場合
thread1本 = 1長期タスク- 一定ステップ／時間ごとに
messages.listでログ取得 - 外側のWorkerでチャンク切り＆要約
- 要約結果を
assistantロールメッセージとして差し込む
やっていることはシンプルで、
- ログをチャンクに分けるルールを決める
- 各チャンク末尾で LLM に“要約＋状態JSON”を吐かせる
- 次チャンクでは、その状態だけを持ち回す
という3ステップです。
Research-Factoryを“日本の現場”に持ってくるとこうなる
「Research-Factory？そんなカッコいい名前の仕組み、うちの会社には無いんだけど？」
いや、名前が付いていないだけで、素材だけならだいたい揃ってます。
KLong論文の Research-Factory は「論文×研究タスク」特化の工場でしたが、
日本の現場に持ってくるときはもっと素朴に、
すでに溜まってる業務ログを、“長期タスクの行動軌跡”としてリサイクルする工場
ぐらいに捉えるとやりやすいです。
-1. 社内に眠る“なんちゃって Research-Factory 素材”を掘り起こす
日本企業だと、高確率でこんなログがあります。
- 問い合わせ対応履歴
Zendesk / Salesforce / 独自システム、メール、チャットのログ - 運用マニュアル＋障害対応記録
Confluence / esa / Qiita:Team、ポストモーテム文書 - 営業活動ログ
SFAの商談履歴、議事録、訪問記録 - チケット管理
Jira / Redmine / Backlog / GitHub Issues
これ、全部「長期タスクの軌跡」に変換できます。
例：
- 1つのインシデント：発生 → 検知 → 暫定対応 → 恒久対策 → 振り返り
- 1つの顧客：初回問い合わせ → PoC → 契約 → トラブル → 継続 or 解約
- 1つの機能開発：企画 → 要件 → 実装 → テスト → リリース → 改修
まずやるべきは、
- 「2〜3時間以上かかるのが普通で、担当者によってやり方がバラバラ」なタスクを1つ選ぶ
- それに紐づくログがどこに散らばっているかを書き出す
ことです。
-2. 行動ログを“状態・行動・報酬”に分解する半自動ワークフロー
素材が見つかったら、次は RLでも扱える形（状態・行動・報酬） にほぐします。
KLongのようにフル自動・大規模は難しくても、
LLMによる自動アノテーション＋人間のスポットチェックなら現場でも回せます。
ステップ1：生ログを“イベント単位”に切る
長いSlackログなどを、「1つの連続した行動」単位に切るイメージです。
LLMプロンプト例（要旨）：
- 「目的＋実際に行った操作」で1イベント
- 敬語はやめて、砕けた日本語で要点だけにする
- JSON配列で
event_id/raw_text/summaryを返す
ここで敬語を剥がして要点にするのが日本語ログでは重要です。
ステップ2：各イベントに“状態”と“行動”のタグを付ける
イベント要約に対して、
- state：その時点の状況
- action：実行した行動
を短文でラベル付けします。
後でベクターストアやstate_vectorに使えます。
ステップ3：成功／失敗／コストから“簡易報酬”を付ける
本格RLではなく、3段階評価くらいのなんちゃって報酬で十分です。
例（インシデント対応）：
- +1：復旧や原因特定、再発防止につながる行動
- 0：状況確認や共有など中立
- -1：明らかに無駄な調査や誤った方向への固執
LLMに reward と reason を出させて、
人間は「明らかにおかしいところだけ直す」くらいの運用でも、それなりに使えます。
-3. スモールスタート向け“ミニ長期タスク”3選
大規模Research-Factoryは無理でも、ミニ長期タスクなら個人・小規模チームでも余裕です。
① 1日1テーマの「技術調査エージェント」
- 午前：検索＆候補記事ピックアップ
- 午後：精読＆比較・メモ
- 夕方：簡易レポート作成
「1テーマ＝1軌跡」として、
- 30〜60分ごとにチャンク
- 各チャンクで「読んだもの・仮説・未解決」を要約
をやると、ミニResearch-Factoryになります。
② 長尺ドキュメント要約＋QAエージェント
- 数十〜数百ページのPDFを相手に、
- 章ごとの要約
- 重要部分の深掘り
- 最終サマリ＋QA
までを「1ドキュメント＝1軌跡」として扱うパターンです。
③ 継続的リファクタ支援エージェント
- 数週間〜数ヶ月にわたるテックデット返済やリファクタを
- 「1テーマ＝1軌跡」
- 「1スプリント＝1チャンク」
として扱い、進捗・残TODO・リスクを状態として持ち回すイメージです。
段階的強化学習：AIに“締切ギリギリまで粘る習慣”を教える
長期タスクでよくあるのが、
「最初の30分は優秀なのに、その後は雑なまとめで締めたがるAI」
問題です。
ここをチューニングするためにKLongが使っているのが、段階的強化学習（カリキュラム学習）です。
-1. いきなりエルデンリングは無理ゲー：カリキュラム学習の基本
AIにいきなり10時間タスクを学習させると、
- 成功例がほぼ出ない
- 報酬ゼロ or マイナスだらけ
- 勾配がまともに流れない
という「ナイトメア難易度スタート」状態になります。
なので、
- 短いタスクでまず成功体験を積ませる
- 少しずつタスク時間と複雑さを伸ばす
- 成功率がゼロ近辺に落ちないように調整する
というレベル上げ式カリキュラムを組みます。
-2. LLMエージェント向け“段階的タスク設計”サンプル
例として「技術リサーチエージェント」を3レベルで設計してみます。
- レベル1：単一URLの要約（10〜15分相当）
- レベル2：2〜3本の記事を比較して違いを整理（1〜2時間）
- レベル3：半日〜1日のリサーチ＋サーベイレポート作成（ガチ本番）
これをJSONで定義して、レベルごとに
time_limit_minutessources_countrequired_sections
などを変えていけばOKです。
報酬設計もレベルごとに変えます（要約の網羅性 → 比較軸の妥当性 → 全体構成と実用性、のように）。
RLまでやらなくても、
- レベル別タスクテンプレを作る
- エージェントに投げて、LLMで自動採点させる
だけで、「どのレベルまで任せられるか」はだいぶ見えてきます。
-3. 報酬設計の“沼ポイント”3つとKLong流のコツ
長期タスクの報酬設計では、この3つが特に罠です。
-
沼1：終端報酬だけ（最後だけ正解ならOK）
→ 途中の探索・丁寧さが評価されず、「早めに結論決めて証拠だけ拾うAI」が生まれがち。 -
沼2：中間報酬が「やったかどうか」だけ
→ 質に関係なく「検索しただけで+0.1」みたいになると、「手数だけ多い中身スカスカAI」になる。 -
沼3：探索へのペナルティ盛りすぎ
→ APIコストを気にするあまり、ちょっとでも不確実な行動を避ける超保守的AIが生まれる。
KLong的に真似したいのは、
- フェーズごとに評価軸を変えながら、中間報酬を細かく置く
- 探索には軽い罰＋「新しい有用情報」を見つけたときだけ強めのボーナスをつける
という「時間×質」での評価です。
日本の現場での“粘るAI”活用アイデア5選【KLong的発想で考える】
ここまで設計の話をしてきたので、「で、現場でどこに効くの？」を5パターンでまとめます。
狙うのは次の5シーンです。
- SRE / 運用
- 研究開発
- コールセンター / CS
- ソフトウェア開発
- 個人の知的生産
-1. SRE/運用：「夜通し付き合ってくれる運用エージェント」
- アラート発火
- 状況確認
- 暫定対応
- 根本原因調査
- 恒久対策
- ポストモーテム
までを1インシデント＝1軌跡として扱います。
- ログ：監視ツールのアラート、Slackオンコールチャンネル、チケット、レポート
- チャンク：
- アラート〜一次対応
- 調査フェーズ
- 暫定対応
- 原因特定
- 恒久対策
- 振り返り
各チャンク末尾で
- 試したことと得られた知見
- まだ不明な点
- 次にやるべき候補
を要約させれば、「夜通し付き合いつつ、筋のいい粘り方をする運用エージェント」に近づきます。
-2. 研究開発：文献調査〜実験設計までを10時間並走させるリサーチAI
- テーマ決め
- 文献検索
- 関連研究整理
- 仮説立案
- 実験案設計
を1研究タスク＝1軌跡として扱うパターンです。
- ログ：論文管理ツール、arXiv / CiNii / J-STAGE検索履歴、日本語論文メモ、Slack議論、実験ドラフト
- チャンク：
- テーマ決め〜キーワード出し
- 文献検索＆スクリーニング
- 重要論文の精読
- 分類・トレンド整理
- 仮説・実験案ドラフト
日本語資料も多い現場では、「専門用語の日本語訳も含めた状態」を持ち回ると、和製Research-Factoryになります。
-3. コールセンター/CS：問い合わせ単位ではなく“顧客との関係”を学習させる
1件の問い合わせごとではなく、顧客ID単位で数ヶ月〜数年のやりとりを1軌跡にします。
- ログ：問い合わせ履歴、CSチケット、営業メモ、アップセル・解約履歴
- チャンク：
- 導入フェーズ
- 初期トラブル
- 安定運用期
- 利用率低下期
- アップセル or 解約前後
要約時のポイント：
- 顧客の不満・期待・感情の変化
- サポート側がとったアクション
- モメたポイントと解決の有無
です。
日本語なら、プロンプトで「敬語をフランクに剥がす」指定をすると、本音が見えやすくなります。
-4. ソフトウェア開発：スプリントをまたいでタスクを追いかける開発エージェント
1つの機能改善が、企画 → 設計 → 実装 → レビュー → テスト → リリース、と数スプリントかけて進む
この流れを1長期タスクとして扱います。
- ログ：Jira/GitHub Issues、コミット・PR・レビューコメント、仕様議事録、テストレポート
- チャンク：
- Issue作成〜要件整理
- 最初の実装スプリント
- レビュー＆リファクタ
- 結合テスト〜リリース
- リリース後フィードバック
状態として
- 進捗
- 未完了TODO
- 設計の前提・前回の議論
を持ち回すと、「スプリントまたいでタスクを追いかけてくれる開発エージェント」の原型になります。
-5. 個人の知的生産：“1日中付き合ってくれる学習コーチAI”
- 午前：インプット（本／動画／講義）
- 午後：演習・アウトプット
- 夜：振り返り＆翌日の計画
を1日＝1軌跡にします。
- ログ：カレンダー、ノート（Notion/Obsidian）、閲覧履歴、GitHub、AIチャット履歴
- チャンク：
- 午前インプット
- 午後アウトプット
- 夜の振り返り
各チャンク末尾で
- 学んだこと
- できるようになったこと／まだ怪しいこと
- 翌日へ引き継ぎたいポイント
をまとめれば、「1日中付き合ってくれる＆翌日も覚えていてくれる学習コーチAI」になります。
KLong×長期タスクAI よくある疑問Q&A【日本語タスク対応も含めて】
ここまで読んで出てきそうなツッコミを、Q&A形式でまとめておきます。
Q1：結局、巨大モデルが正義なんじゃないの？
A：一発の賢さはデカいモデルが強い。でも“10時間付き合う設計”は別軸です。
- 瞬間最大風速（1回の推論の賢さ）は巨大モデルが有利
- ただし、10時間タスクでは
- どんなログを食べさせるか
- どう分冊ノートにするか（軌跡分割）
- どうレベル上げするか（段階的RL）
といった設計のほうが効くフェーズがある、という話です。
KLongは「巨大モデル不要論」ではなく、
「長期タスク性能はモデルサイズ以外の軸でまだ伸ばせる」
「中堅モデル＋設計とログで“粘り”を後付けできる」
という実例だと見るのがちょうどいいと思います。
Q2：軌跡分割って、日本語の業務ログでも普通に使える？
A：発想は言語非依存。日本語特有の“めんどくささ”にはちょっと工夫を。
軌跡分割の「構造」は完全に言語非依存ですが、日本語ログには
- 敬語・社交辞令が多くて本音の行動が埋もれがち
- 文が長くてどこで区切るか微妙
- 社内略語がやたら多い
というクセがあります。
対応のコツは3つ：
- 分割ルールは時間／イベントベース寄りにする
- 要約プロンプトで敬語を剥がしてフランクに要約させる
- 社内略語は最初に用語集JSONを渡しておく
これだけでも、日本語ログでもかなり扱いやすくなります。
Q3：個人開発レベルのGPU or API課金でもチャレンジできる？
A：論文スケール再現は無理。でも“ミニKLongごっこ”なら普通にいけます。
やることをスケールダウンすると：
- タスク時間を1〜2時間程度に縮小（長“め”タスクから）
- ログはLangChainやAssistants API、自前スクリプトで全部JSON／CSV保存
- 報酬学習まではやらず、まずは
- 「good軌跡／bad軌跡」のラベル付け
- LLMで両者のパターン分析
くらいから始める
これなら、GPT-4o mini / Claude Haikuクラス＋月数千円〜1万円の課金でも十分遊べます。
Q4：既存のLangChain / LlamaIndexプロジェクトにどう組み込む？
A：“TrajectoryStore”という1コンポーネントを足すイメージがハマりやすいです。
典型的な構成：
[User] → [Agent] → [Tools] → [Memory] → [LLM]
に対して、次の3コンポーネントを追加します。
- TrajectoryStore
- ステップごとのログを保存
-
Nステップ／イベントごとにチャンク化
-
Summarizer
- チャンク末尾で LLM 要約
-
summary＋state_vectorを生成し Memory / 外部DBへ格納 -
Trainer/Scorer
- 軌跡を後からまとめてスコアリング（最初は人間向けレポートでもOK）
LangChainならCallbackハンドラ、LlamaIndexなら「1チャンク＝1ノード」としてNode/Indexに入れていくイメージです。
関連記事（次に読むなら）
- LLM能力・安全性・ベンチマーク最新論文の読み解き（導入判断の論点整理）
- AIツール乱立時代の“賭けどころ”整理（現場での使い分け）
- Claude Sonnet 4.6の判断ポイント（モデル標準化/運用の考え方）
まとめ：“デカさ頼みじゃないAI”を、自分の手で育ててみよう
ここまで付き合ってくれたので、あなたはもう立派な「粘るAI」オタク候補です。
最後に要点と、明日からの一歩をまとめます。
-1. この記事のポイント5つを30秒で振り返り
- KLongは“1/10サイズでも長期タスクで粘れるコスパ重視AI”の実例
- Research-Factoryは、長時間タスク用行動ログを量産する“データ工場”
- 軌跡分割で、10時間ログを“小分け＋つながった記憶”として学習可能にする
- 段階的強化学習で、短時間タスクから徐々に伸ばしながら“根気”をチューニングする
- 日本の現場でも、運用／研究／CS／開発／個人学習など応用余地はかなり大きい
-2. 明日からできる“ミニKLongごっこ”チェックリスト
- 「2〜3時間以上かかるタスクログ」を1つ見つける
- 時間 or イベントベースで、簡単な軌跡分割ルールを決める
- 各チャンク末尾で、LLMに“要約＋次へ引き継ぎたい状態”をJSONで出させる
- 最初は60〜90分タスクから始めて、徐々に時間とステップ数を増やす
- 良さそうな軌跡と悪そうな軌跡にラベルを付け、“なんちゃって報酬学習”のタネを作る
ここまでできれば、もう「KLong読者」ではなくミニKLongごっこ勢です。
-3. 次回予告：軌跡分割をPythonで雑に組んでみる【実装編】
次のブログでは、今回の話をそのままコードに落としていきます。
- Pythonで書く最小限の軌跡分割スクリプト
- ログ読み込み
- チャンク分割
- LLM要約 →
summary＋stateを保存 - LangChain / OpenAI Assistants APIと組み合わせた
ミニ長期タスクエージェントの実装例 - おまけで、good/bad軌跡のラベル付け＆LLMによるパターン分析
「概念は分かったからコードを見せろ」派の人は、ぜひ次回も覗きにきてもらえると嬉しいです。
巨大モデルの新作を追いかけるのも楽しいですが、
“デカさ頼みじゃないAI”を、自分のログと設計で育てていくのも、かなり中毒性のある遊び方です。
GPU貧民でも戦える余地はまだまだあります。
そのひとつの証拠としてのKLongをネタに、明日からちょっとだけ、エージェントの「粘り」を意識してみてください。
コメント