Lomo Agent：創作型・継続協働型 Agent のアーキテクチャ設計とエンジニアリング実践

製品ショートムービーを 1 本作るには、要件のすり合わせ、参考素材の整理、絵コンテ、画像生成、動画生成、そして何度もの修正を経ることがよくあります。その中には数秒で終わる作業もあれば、数分待たなければならない作業もあります。モデルに判断を任せてよいものもあれば、必ずユーザーの確認が必要なものもあります。そして第 1 版ができあがっても、仕事はまだまだ終わりません。

AI の時代が到来してから、技術記事を書くことはめっきり減りました。その分の時間は、さまざまな実用シーンでの AI の探索に充ててきました。

AI 時代の最大の受益者はプロダクトマネージャー（PM）だと考える人は少なくありません。アイデアと実装との距離が大きく縮まったからです。しかし私は、AI がエンジニアにもたらす力のほうが、より深いものかもしれないと考えています。AI は技術的な実装が創造性に課していた制約を少しずつ取り払い、エンジニアがコードやエンジニアリングの細部から一歩引いて、プロダクト、アーキテクチャ、さらにはヒューマン・コンピュータ・インタラクションの本質を見つめ直す機会を与えてくれています。

これまで私たちは、機械に指示を正しく実行させる方法を考えることに多くの時間を費やしてきました。今ようやく、より面白い問いに力を注げるようになりました。それは、機械に人の意図を本当に理解させ、より自然なかたちで人と協働させるにはどうすればよいかという問いです。

先日、私たちは Lomote AI で Lomo Agent をリリースしました。この機会に、構想から実装に至るまでの考え方、アーキテクチャ設計、エンジニアリング実践についてお話ししたいと思います。

本記事では、タスクの組み立て方、メッセージルーティング、Durable Execution（永続実行）、非同期タスク、コンテキストエンジニアリング、長期記憶、自律的な推進、共有の創作ワークスペースを取り上げます。すでに実装済みの設計もあれば、まだ探索・検証中のものもあります。また、DeepSeek、Manus、Claude Code といった優れたプロダクトや技術的な取り組みにも触れながら、複数の選択肢の間で私が何を考え、どう取捨選択したのかを共有します。

Lomote AI と Lomo Agent

Lomote AI は、私たちが開発しているオールインワンの AI 創作プラットフォームです。面白いことに、このプロジェクトで私はプロダクトマネージャー（PM）の役割を多く担いつつ、基盤アーキテクチャの設計・構築にも携わってきました。おかげで、プロダクトと技術の両方の視点から、AI 創作ツールがどのような形と体験を備えるべきかを改めて考える機会を得ました。

現在、Lomote AI は画像・動画・3D の生成モデルや高画質化モデルを数多く統合し、アセットライブラリ、ムードボード、そして Flows ビジュアルワークフロー などの機能を提供しています。クリエイターが統一されたワークスペースの中で素材を管理し、モデルを組み合わせ、創作フローを組み立てられるようにすることで、AI 創作を断片的なモデル呼び出しから、一貫したまとまりのある創作体験へと進化させたいと考えています。

これらの機能によって、AI 創作ツールがバラバラに散らばっているという問題はかなりの部分が解消されました。しかし使い込むにつれて、ツールの統合は第一歩にすぎず、それらを本当に連携させてユーザーの生産性を解き放つにはどうすればよいか、という問いのほうがより探求する価値があると気づくようになりました。

従来の AI 創作フローでは、ユーザーは依然として自分で手順を計画し、モデルを選び、素材を整理し、異なるタスクの間でコンテキストや中間成果物を何度も受け渡す必要があります。創作フローが複雑になるほど、ユーザーは各工程の調整に多大な労力を割かざるを得なくなります。

Lomo Agent は、まさにこうした背景から生まれました。AI を単なる創作ツールから、意図を理解し、タスクを計画し、継続的に協働できるエージェントへと少しずつ進化させたい。ユーザーは目標を伝えるだけで、Agent がプラットフォーム上の既存モデルやツールを呼び出して創作フローを組み立て、実行中もユーザーのフィードバックに応じて調整を続けていく。そんな体験を目指しています。

こうした体験を実現するには、従来の単発のツール呼び出しでは明らかに不十分です。タスクをどう組み立てるのか、コンテキストをどう管理するのか、非同期実行をどう調整するのか、そしてユーザーが離れた後も Agent がどうやって作業を進め続けるのか。これらすべてが、私たちが解決すべきアーキテクチャ上の課題となりました。

クリックで拡大

クリックで拡大

何度も修正が入る創作タスクから考える

ある月曜日、ユーザーが「レトロ調のブランドポスターを何枚か作って」と頼んだとします。Agent は要件を整理し、参考画像の生成を始めます。その途中で、ユーザーが別の依頼を差し込みます。「ついでに昨日の猫の画像を 5 秒の動画にしておいて」。そして水曜日、ユーザーはまた話を持ち出します。「この前のポスター、もう少し暖かい色味にして、文字の位置も調整して」。

人と人との日常的な協働ではごく当たり前のやりとりです。しかし Agent にとっては、その裏で複数タスクの並行管理、非同期生成、コンテキストの関連付け、過去の素材の検索が絡んできます。タスクが進むにつれ、キャンセル、リトライ、予算管理、ユーザーの好みの変化、マルチデバイスでの協働といった問題にも直面します。

1 か月ほど前から、私はある問いについて考え始めました。Agent はなぜセッション（Session）中心でなければならないのか？

既存の Agent プロダクトの多くは、いまだにチャットボットのインタラクションパラダイムを踏襲しており、ユーザーは自分でセッションを作成し、探し、管理しなければなりません。ヘビーユーザーほどセッションはどんどん溜まっていき、本来 AI が担うべきコンテキスト管理の仕事が、逆にユーザーの負担になってしまっています。

一方、現実の生活で人はわざわざ「セッション」なるものを管理したりはしません。いつでも話題を切り替えられますし、数日後に以前の件の続きを自然に話すこともできます。理想的なエージェントも、こうした能力を備えるべきなのかもしれません。

そこで Lomo Agent では、ユーザー側のセッションという概念を薄め、タスクの識別、コンテキストの分離、過去の文脈との関連付けをシステムに任せることにしました。もちろん、これはアーキテクチャ設計全体の一部にすぎません。継続的な創作を本当に支えるには、実行の復旧、非同期スケジューリング、長期記憶、予算の承認、共有成果物の管理といった一連のエンジニアリング課題を解決する必要があります。

デモを作っていた頃、ちょうど DeepSeek チームの Super-agent に関するアーキテクチャ構想を読みました。とても興味深いことに、タスクの組み立てやコンテキスト管理において、私たちと似た問題にぶつかっていたのです。DeepSeek チームの記事「Super-agent 設計の探求：より自律的な Agent システムへ」における Router / Worker の役割分担や、その後のメッセージルーティングの設計からは多くのヒントを得ており、Lomo Agent の全体アーキテクチャをさらに洗練させる助けにもなりました。

ここからは実際の設計と実装に沿って、いくつかの課題について私が考えたことと、その取捨選択についてお話しします。

1. タスクの組み立て：ユーザーのリクエストから継続的に進められるタスクへ

先ほどの例に戻りましょう。ユーザーは数分のうちに複数の話題を切り替えることもあれば、数日空けてからあるタスクを再び持ち出すこともあります。Agent にとってメッセージを受け取るのは始まりにすぎません。より重要なのは、そのメッセージがどの目標に属するのかを理解し、それまでの進捗や関連素材をどうやって見つけ出すかです。

ここにはアーキテクチャ上のトレードオフがあります。すべてのタスクが 1 つのコンテキストを共有すると、異なる目標の情報が互いに干渉しやすく、モデルのコンテキストウィンドウもあっという間に膨れ上がります。逆にセッション単位で完全に分離してしまうと、異なるタスク間にある過去の文脈とのつながりが断ち切られてしまいます。

そこで Lomo Agent では、インタラクションの入口、実行コンテキスト、長期記憶を、比較的独立した 3 つの層に分けました。

ユーザーは統一された入口で自然に意図を伝えるだけでよく、タスクの帰属はシステムが判断し、継続的に進める必要のある作業には独立したタスクを作成します。各タスクは独自のコンテキスト、実行状態、成果物への参照を持ち、必要に応じて、制御された検索・共有の仕組みを通じて他のタスクの情報を取得できます。

この設計にあたっては、既存プロダクトのさまざまな取り組みも参考にしました。

たとえば ChatGPT は、セッションをまたぐ記憶によって会話間の情報の連続性を高めています。Claude は Projects などの仕組みによって、ユーザーが特定のプロジェクトを軸に知識とコンテキストを整理できるようにしています。どちらの設計にも長所があります。明示的なセッションやプロジェクトの境界は理解・管理・共有がしやすく、ユーザーがコンテキストの範囲をより直接的にコントロールできます。

しかし、長期にわたって頻繁にタスクを切り替える創作シーンでは、ユーザーは依然としてコンテキストの整理を一部担わなければなりません。セッションをまたぐ記憶は Agent がユーザーの好みや履歴を把握する助けにはなりますが、実行中のタスクとその進捗を完全に表現することはできません。

そこで Lomo Agent は、タスクを組み立てる仕事のより多くをシステムに任せ、ユーザーが日々のセッション管理からできるだけ解放されるようにしました。もちろん、自動識別にはタスクの帰属を誤るリスクもあります。そのため、明示的なタスクの入口と誤りを訂正する仕組みを残し、目標が明確な場合は決定論的ルーティングを優先して、不要なモデル判断を減らしています。

flowchart TD
    U["ユーザー"] --> E["統一されたインタラクション入口"]
    E --> R["タスク識別とルーティング"]
    R --> A["タスク A：ブランドポスター"]
    R --> B["タスク B：動画制作"]
    R --> C["簡単なリクエスト：メインスレッドで直接処理"]
    A <--> M["長期記憶"]
    B <--> M
    C <--> M
    A --> S["共有素材と成果物"]
    B --> S

図 1：Lomo Agent のタスク組み立てモデル

2. システム概要：調整層、実行層、共有ワークスペース

タスクの組み立て方が決まったら、次はそれらのタスクを実際にどう動かすかを考えます。

継続的に協働できる Agent は、ユーザーの新しいリクエストへの対応、既存タスクの推進、外部の生成結果の待機、作品に対するユーザーの修正への応答を同時にこなす必要があります。これらをすべて 1 つの Agent に任せると、コンテキストはすぐに膨れ上がり、タスク同士も干渉しやすくなります。逆にリクエストごとに独立した Agent を作れば、余計な調整コストが生じます。

こうした考えから、私は Lomo Agent に Main / Task の 2 層構造を設計し、実行層には永続化されたランタイムを導入しました。これにより、各タスクが独立して進みながら、共有ワークスペースを通じて創作成果物にアクセスし、修正できるようになっています。

2.1 全体アーキテクチャ

システム全体は、主に 4 つの部分に分けられます。

• Main（メインスレッド）：ユーザーが継続的にやりとりする入口です。新しいリクエストの理解、既存タスクとの関連付け、簡単な質問への対応、そして各タスクの実行とフィードバックの調整を担います。

• Task（タスク）：具体的な創作目標を担う独立した実行空間です。各タスクは、自身のブリーフ（タスク指示書）、コンテキスト、実行計画、メッセージの受信箱、実行状態を管理します。

• Agent Runtime（ランタイム）：モデル推論、ツール呼び出し、非同期待機、状態の永続化、実行の復旧を管理し、各ステップで予算・権限・停止条件をチェックします。

• Shared Workspace（共有ワークスペース）：画像、動画、3D、ドキュメント、素材セット、Flows ワークフローなどの創作成果物を保存し、ユーザーや各タスクが権限の範囲内で共同でアクセス・修正できるようにします。

役割分担としては、Main が主に Router の役割を担い、Task の内部では Worker が具体的なタスクを進めます。Router と Worker は論理的な実行上の役割であり、異なる基盤モデルを使うことを前提とはしていません。

flowchart TB
    U["ユーザー：自然言語 / カード操作 / ワークスペースでの編集"] --> UI["統一された協働インターフェース"]
    UI --> GW["アクセス層：サイト内 API / オープン API / リアルタイムイベント"]
    GW --> CMD["指示とメッセージの受け付け"]

    subgraph CORE["Agent Core"]
      ROUTER["Main / Router：理解と調整"]
      ROUTING["目標の帰属判定と決定論的ルーティング"]
      W1["Task A / Worker：シリーズポスター"]
      W2["Task B / Worker：ショート動画"]
      CTX["コンテキストの編成 / 圧縮 / オンデマンドのツール"]
      RT["Durable Execution エンジン"]
      GUARD["承認 / 予算 / 自律度"]
    end

    CMD --> ROUTING
    ROUTING --> ROUTER
    ROUTING --> W1
    ROUTING --> W2
    ROUTER --> RT
    W1 --> RT
    W2 --> RT
    RT --> CTX
    RT --> GUARD
    RT --> TOOLS["創作ツール：画像 / 動画 / 音声 / 3D / キャンバス / 素材"]
    RT <--> DB[("永続化データベース：実行の事実と状態")]
    RT <--> M["長期記憶：ユーザープロファイル / 事実 / エピソード要約"]
    TOOLS --> ASSET["共有成果物とワークスペース"]
    ASSET --> UI
    DB --> EVENTS["キュー / イベント発行 / リアルタイムプッシュ"]
    EVENTS --> UI

図 2：Lomo Agent の全体レイヤーアーキテクチャ

このアーキテクチャの重要な特徴の 1 つは、タスクの実行と創作成果物がそれぞれ独立したライフサイクルを持つことです。

たとえばユーザーがメインスレッドでポスター制作を依頼すると、システムはそのための独立したタスクを作成します。以降の参考画像、生成記録、修正履歴はそのタスクが管理し、最終的な成果物は共有ワークスペースに保存されます。ユーザーが別のタスクに切り替えても、ポスターのタスクは生成結果を待ち続けることができ、必要になれば実行を再開できます。

メインスレッドが管理するのはタスクの概要と現在の状態だけで、モデル呼び出しやツール実行の全過程を長く保持しておく必要はありません。これにより、使用期間が長くなるにつれてメインスレッドのコンテキストが際限なく膨らむのを防げます。

DeepSeek Super-agent から得たヒント

設計の過程では、DeepSeek チームの Super-agent のアーキテクチャ構想から多くのヒントを得ました。

Super-agent も調整と実行を分離する考え方を採っており、Router / Worker によって異なる目標を組み立て、Ticket / Executor などの仕組みでタスクの帰属を管理しています。この設計は、長期間動き続け、新しい指示を繰り返し受け取る必要のある Agent に特に適しています。

ただし、DeepSeek が公開している研究プロトタイプは主にコードリポジトリを対象としています。リポジトリのタスクは通常、作業範囲、ファイルの変更、成果物が比較的はっきりしていますが、AI 創作のタスクの境界ははるかに曖昧です。

たとえば、1 回の簡単な画像生成なら数十秒で済むかもしれませんが、その後ユーザーが何度か修正を重ねるうちに、長期的な創作プロジェクトへと少しずつ発展していくこともあります。しかも、同じ素材が複数のタスクから参照・修正されることもあります。

そこで私たちは、Router / Worker の基本的な分担は残しつつ、創作シーン向けに軽量タスク、共有成果物の同一性（アイデンティティ）、非同期待機といった設計を追加しました。

このやり方は、タスクの帰属判定、共有オブジェクトの権限、タスク間の状態同期といった新たな複雑さももたらします。これらについては後の章で個別に掘り下げます。

2.2 すべてのリクエストに独立した Worker が必要なわけではない

マルチエージェントのアーキテクチャは、ある落とし穴にはまりがちです。タスクを分割できるのだから、何でもできるだけ独立した Agent に任せてしまおう、というものです。

しかし、独立した実行空間にはそれ自体にコストがあります。Worker を 1 つ作るたびに、追加のコンテキスト、実行状態、メッセージのルーティング関係を管理する必要があり、モデル呼び出しや調整のオーバーヘッドも増える可能性があります。

Lomo Agent の創作シーンを例にとると、次のようになります。

ユーザーが「この動画モデルはどの解像度に対応している？」と尋ねたなら、Main がそのまま対応できます。

ユーザーが「茶トラ猫の画像を 1 枚生成して」と頼んだなら、1 回の生成タスクで済むかもしれません。

一方、「スタイルの統一されたブランドポスターを一式作って」となると、計画、素材管理、複数回の生成、その後の修正が絡むため、独立したタスクを作成するほうが適しています。

そこで私たちは、実行タスクをさらに 軽量タスク（Lightweight Task） と 正式タスク（Persistent Task） に分けました。

軽量タスクは主に 1 回きりの生成、実行状態、結果カードを担うもので、ユーザーのタスク一覧に長く居座る必要はありません。ユーザーが生成結果を軸に修正を続けたり、タスクが少しずつ複雑な創作目標へと発展したりした場合には、システムがそれを正式タスクに昇格させ、その後の協働に必要なコンテキストと実行記録を残します。

正式タスクは比較的完全なライフサイクルを持ち、メッセージを継続的に受け取り、計画を実行し、外部タスクを待ち、日をまたいで、あるいはさらに長い時間が経ってから作業を再開できます。

この区分は、脱セッション化の設計を補うものでもあります。ユーザーがセッションを管理する負担を減らしたい以上、それを結局、頻繁に整理しなければならない別のタスク一覧に置き換えるだけで終わらせたくはありません。

2.3 1 回の協働はどう流れるのか

先ほどのブランドポスターと猫の動画の例に戻りましょう。

ユーザーはまず Main でポスター制作を依頼します。Router はこれが継続的に進める必要のある目標だと判断し、対応するタスクを作成して、その後の計画と生成を Worker に任せます。

ポスター制作の途中で、ユーザーは以前の猫の画像から動画を作るよう頼みます。システムはこれを別の独立した作業だと識別し、新しい実行空間を作ります。2 つのタスクはそれぞれコンテキストを管理し、各自の状態に応じて独立して進められます。

ポスター案の確認が必要になると、Agent はタスクカードを通じてユーザーに候補案を提示します。ユーザーがカード上で直接選択すれば、メッセージは明確なタスクの身元情報にもとづいて対応する Worker に送り返されるため、意味判断をやり直す必要はありません。

数日後、ユーザーがメインスレッドで「この前のポスター、もう少し暖かい色味に」と言うと、Router はタスクのインデックスと過去の情報を組み合わせて、この新しい指示を元のポスタータスクに関連付けます。

sequenceDiagram
    participant U as ユーザー
    participant R as Main / Router
    participant A as Task A（ポスター）
    participant B as Task B（動画）
    U->>R: ブランドのシリーズポスターを一式作って
    R->>A: タスクとブリーフを作成
    R-->>U: メインスレッドにタスクカードを表示
    U->>R: ついでに昨日の猫を動画にして
    R->>B: 別のタスクを作成
    Note over A,B: 独立したコンテキストで並行して進行
    A-->>U: ポスター案の確認待ち
    U->>A: カード上で案 B を選択
    B-->>U: 動画の生成が完了
    U->>R: この前のポスター、もう少し暖かい色味に
    R->>A: 追加の依頼を既存タスクに戻す

図 3：Main / Task による複数タスク協働のシーケンス図

ここで注目すべき設計上の細部があります。メッセージの帰属とメッセージの実行は、別々のフェーズであるという点です。

Router はメッセージを対応するタスクに割り当てられますが、Worker がすぐに処理するとは限りません。たとえば動画の生成を待っている最中かもしれませんし、ユーザー確認のポイントで一時停止しているかもしれません。新しいメッセージはまず永続化された受信箱に入り、その後ランタイムが現在の状態に応じて消費のタイミングを決めます。

つまり、タスクの組み立ては第一歩にすぎないということです。タスクの数が増えるにつれて、ユーザーの後続の意図をどう正確に識別するか、誤ルーティングをどう防ぐか、実行中に割り込んでくる新しいメッセージをどう扱うかが、アーキテクチャ全体にとって重要な課題になっていきます。

3. メッセージルーティング：すべてのメッセージを正しい実行単位へ

統一されたインタラクションの入口によって、ユーザーは自然にタスクを切り替えられるようになりました。しかしその一方で、もともとユーザーが担っていた仕事をシステムが引き受けることにもなりました。それは、新しいメッセージを 1 つひとつ、誰が処理すべきかを判断することです。

たとえば、ユーザーが画像を 1 枚生成した直後に、突然「さっきのを青にして」と言ったとします。

この「さっきの」は、直前に生成した画像を指しているのかもしれませんし、以前のあるポスタータスクの素材を指しているのかもしれません。

帰属の判断がずれると、軽ければ重複したタスクが作られる程度で済みますが、重ければ Agent が間違った作品を修正してしまいます。

つまり、メッセージルーティングの正確さはシステム全体の信頼性に直結します。私たちはすべてのメッセージについてモデルに帰属を推測し直させるのではなく、比較的シンプルな原則を採りました。明確な関係から特定できるものはプログラムで直接処理し、明確な帰属がない場合に限ってモデルに意味判断を任せるというものです。

3.1 決定論的ルーティングとセマンティックルーティング

Lomo Agent のメッセージ受け付けは、大きく 3 つの段階に分かれます。

第 1 層：目標が明確な場合の直接ルーティング。

ユーザーがあるタスクのパネルで返信したとき、タスクカード上の操作ボタンをクリックしたとき、あるいは明確に紐づいた作品に対して修正を依頼したとき、システムはメッセージがどの目標に属するかをすでに知っているので、Task ID やオブジェクトの関連付けにもとづいて直接配送できます。

このような場合にわざわざモデルを呼び出して帰属を判断させると、かえってレイテンシと誤判定のリスクが増えるだけです。

第 2 層：Router による意味判断。

メインスレッドから送られてきた、明確な目標の帰属がないメッセージについては、Router が現在のリクエスト、最近のやりとり、既存タスクのインデックスを組み合わせて判断する必要があります。

考えられる結果は次のとおりです。

• Main が直接処理する簡単なリクエスト。

• 1 回の生成で済む軽量タスク。

• 既存のいずれかのタスクに関連付けられる後続の指示。

• 正式タスクの作成が必要な新しい目標。

• 帰属に明らかな曖昧さがあり、ユーザーにさらに確認する必要があるもの。

ここには見落としがちな点がもう 1 つあります。Router はすべてのタスクの完全な履歴を読み込む必要はない、ということです。通常はタスクの目標、要約、最新の状態、関連オブジェクトへの参照を渡すだけで十分で、候補となる目標を特定した後に、必要に応じて具体的な情報を読み込みます。

こうすることで、タスクの数が増えるにつれてルーティングそのものが膨張し続ける別のコンテキストになってしまうのを防げます。

現在は、最近アクティブだったいくつかのタスクについて、目標、要約、状態などのインデックス情報を優先的に渡しています。ユーザーがもっと前の作業を持ち出した場合は、キーワードと要約ベクトルの類似度で検索し、関連する少数の候補を Router に渡して判断させます。こうすることで、タスクの数が増えても主に影響を受けるのは検索の範囲であり、推論のたびに持ち込まなければならないコンテキストの長さではなくなります。

もう 1 つ起こりやすい誤りは、ユーザーが本来続けたかった作業を新しい目標と取り違えてしまうことです。そこで、正式タスクを作成する前に、システムは直近の進行中タスク 50 件との類似度チェックも行います。重複の可能性がある目標が見つかれば、もっとも似ている候補をいくつかモデルに渡し、既存のタスクを引き続き使うべきか、新規作成を確定すべきかを判断させます。このチェックで重複作成の一部は防げますが、意味上の曖昧さをすべて解消できるわけではありません。根拠が不十分な場合は、やはりユーザーに明確に選んでもらう必要があります。

第 3 層：実行前の帰属と状態のチェック。

メッセージの宛先が決まった後も、システムはそのタスクが有効か、現在の操作を受け付けられる状態か、関連オブジェクトがまだアクセス可能な状態にあるかをチェックする必要があります。

たとえば、ユーザーがすでにアーカイブされたタスクを参照したり、削除済みの素材を修正しようとしたりすることがあります。Router が正しい意味上の帰属を示したからといって、その後の操作が必ず実行できるとは限りません。

flowchart TD
    M["ユーザーのメッセージまたはインタラクションイベントを受信"] --> A{"明確なタスクの身元情報を持っているか？"}
    A -->|はい| V["既存の宛先とアクセス権限をチェック"]
    A -->|いいえ| B{"明確なオブジェクトの関連付けがあるか？"}
    B -->|はい| V
    B -->|いいえ| R["Router による意味判断"]

    R --> Q["簡単なリクエスト：Main が直接処理"]
    R --> L["単発の生成：軽量タスクを作成"]
    R --> E["既存の目標：既存タスクに関連付け"]
    R --> N["独立した目標：正式タスクの作成を準備"]
    R --> C["曖昧さあり：ユーザーに確認を求める"]
    N --> S{"進行中タスクの重複チェックに該当するか？"}
    S -->|はい| H["類似候補を提示しモデルが判断"]
    H -->|既存タスクに関連付け| E
    H -->|新規作成を確定| CREATE["正式タスクを作成"]
    S -->|いいえ| CREATE
    CREATE --> NV["新しいタスクと操作権限を検証"]
    L --> NV
    NV --> I["実行状態を作成し入力を配送"]

    E --> V
    V --> D{"既存の宛先の状態は有効か？"}
    D -->|はい| T["対応するタスクの Inbox に書き込む"]
    D -->|いいえ| F["ユーザーに知らせるか宛先を選び直す"]
    C --> U["ユーザーの返信後に再判断"]
    U --> R

図 4：Lomo Agent のメッセージルーティングの流れ。

3.2 メッセージが届いても、すぐに実行されるとは限らない

メッセージルーティングには、見落とされがちな細部がもう 1 つあります。メッセージがある Worker に割り当てられることと、Worker が実際にそのメッセージの処理を始めることは、別のタイミングで起こりうるという点です。

たとえば、Agent が動画生成を実行している最中に、ユーザーが突然「背景を室内に変えて」と付け加えたとします。

このとき、動画生成のリクエストはすでに上流のサービスに送信されていて、すぐには変更できないかもしれません。システムはまずこの新しい指示を保存しておき、Worker が適切な実行の区切りに達してから、現在の進捗と照らし合わせて次の操作を判断する必要があります。

そのため、私たちはタスクごとに永続化された**メッセージ受信箱（Inbox）**を管理しています。Router はメッセージを正しい受信箱に届けることに責任を持ち、ランタイムはいつ読み込むか、どのようにコンテキストに統合するか、既存の計画を調整する必要があるかを判断します。

ここでは、さらにいくつかのケースを区別する必要があります。

• まだ Worker に消費されていないメッセージは、条件を満たせば取り消したり差し替えたりできる。

• すでにモデルの推論に入ったメッセージは、現在の実行の区切りを待つ必要がある。

• すでに送信済みの外部生成リクエストは、現時点では直接取り消すことができない。新しい指示は Worker が適切な実行の区切りに達するのを待ち、タスクの進捗に応じて再生成するか、新しい制約を後続のステップに適用するかを判断する必要がある。

この分離は、後述する中断からの復旧、非同期タスク、ユーザーによる随時の介入の土台にもなっています。

3.3 コラボレーションツールに学ぶメッセージ帰属の設計

インタラクション設計では、Slack や Feishu（飛書）といったコラボレーションツールのメッセージの整理方法も参考にしました。

Thread（スレッド返信）を例にとると、ユーザーが特定のスレッドに返信した時点で、システムはそのメッセージがどの議論に属するかを当然知っているため、チャット全体を分析し直して帰属を判断する必要はありません。このような明示的な関連付けの利点は、安定していて予測可能であり、しかも追加の意味識別コストがほとんどかからないことです。

ただし、Lomo Agent が向き合うインタラクションのシーンはもっと柔軟です。ユーザーはタスクカード上で直接返信することもあれば、メインスレッドに戻って数日前のある作業を何気なく持ち出すこともあります。

そこで私たちは 2 つの方式を残しました。明確なタスク操作には構造化された身元情報によるルーティングをそのまま使い、メインスレッドでの自然言語については、Router が過去のタスクと照らし合わせて関連付けます。

このハイブリッド戦略によってモデルがルーティングに関わる回数は減らせますが、曖昧さを完全になくすことはできません。たとえば、ユーザーが 2 セットのポスターを同時に制作していながら「この前のやつを直して」としか言わなかった場合、システムには宛先を判断するだけの根拠がないかもしれません。そうしたときは、もっとも関連がありそうに見えるタスクを勝手に選ぶよりも、こちらから尋ねるほうが通常は確実です。

タスクの数が増えていく中で、再現率、ルーティングの正確さ、インタラクションのコストの間でどうバランスを取るかは、実際の利用状況を見ながら継続的に最適化していく必要があります。

とはいえ、帰属の判断がチェーン全体の最後の関門というわけではありません。タスクが 1 つ余計に作られても、たいていは後から統合したり閉じたりできます。しかし、メッセージが誤って作品の修正、素材の削除、有料の生成に結びつけられてしまえば、その代償ははるかに大きくなりかねません。そこで私たちは、メッセージルーティングと実際の実行の承認とを分けています。前者は作業をどのタスクに任せるべきかを判断し、後者は権限と費用の境界を引き続き独立してチェックします。

たとえば、素材の削除や記憶を忘れさせるといった元に戻せない操作は、毎回ユーザーの確認が必要です。有料の生成ではまず見積もりを提示し、確認不要の金額枠、1 日あたりの確認不要の上限、あるいは承認済みの計画予算を超える場合に、ユーザーに確認を求めます。オープン API 経由で行われる有料操作も 1 件ずつ確認します。Router が正しいタスクを判断できたとしても、それによってユーザーが承認した範囲を超える実行権を得られるわけではありません。

メッセージが正しいタスクに届いた後も、実行は数分から数日に及ぶことがあり、プロセスの再起動、ネットワークのタイムアウト、ユーザーによるキャンセルに見舞われる可能性があります。確実な復旧を担うのが Durable Execution の仕組みです。

4. Durable Execution：中断からの復旧、リトライ、並行性制御

メッセージがタスクに正しくルーティングされたら、次に解決すべきは実行プロセスの信頼性です。

通常の Chat Completion なら、1 回のリクエストはたいてい数秒から数十秒で完了します。しかし創作 Agent のワークフローははるかに複雑です。1 本の動画制作には、複数回のモデル推論、数十回のツール呼び出し、そして数分かかる外部生成タスクがいくつも絡むことがあります。実行中に、ユーザーがいつ要件を変更したり、自らタスクを停止したりしてもおかしくありません。

よくある障害シナリオを考えてみましょう。Agent が動画生成サービスにリクエストを送信し、上流では実際にタスクの作成に成功しているのに、サービスのプロセスがちょうどレスポンスを受け取る前に再起動してしまったケースです。

復旧後はどう処理すべきでしょうか。そのままリトライすれば、重複して生成し、二重に課金してしまうかもしれません。リクエストが成功したとみなせば、実際には作成されていないタスクを永遠に待ち続けることになるかもしれません。

こうした問題から、Agent の実行プロセスには、モデルのコンテキストやサービスのプロセスから独立した永続的な状態が必要だと気づきました。

そこで私は、Lomo Agent に Durable Execution（永続実行） の仕組みを導入しました。データベースには重要な実行状態、モデルの意思決定、ツール呼び出しの結果を記録し、タスクキューが実行のスケジューリングと復旧を担い、リアルタイムイベントで進捗をユーザーにフィードバックします。実行プロセスが中断しても、システムは保存済みの事実にもとづいて次に何をすべきかを判断できます。

設計にあたっては、Temporal の Durable Execution の考え方を参考にしました。Temporal はワークフロー履歴、タスクのスケジューリング、リトライの仕組みによって、業務プロセスが単一プロセスのライフサイクルを超えて継続できるようにしています。その利点は、複雑で長時間動き続けるワークフローで特に際立ちます。

ただし、汎用ワークフローエンジンには、それなりのモデリングコストと運用コストもかかります。Lomo Agent の実行プロセスでは、モデル推論、動的なツール呼び出し、創作の状態、ユーザーとのインタラクションも管理する必要があるため、私たちは Agent 自身のデータ構造を軸に、実行台帳とイベントスケジューリングの仕組みを実装しました。ここで取り入れたのは Durable Execution のエンジニアリング思想であり、Temporal のソリューションをそのまま使っているわけではありません。

4.1 まず意思決定を永続化し、それからツール呼び出しを実行する

従来の Agent Loop は、たいてい次のようなシンプルな流れに従います。

コンテキストを読み込む → モデル推論 → ツールを呼び出す → 結果を取得する → 推論を続ける。

短いタスクであれば、この実装は比較的素直です。しかし実行プロセスが複数のプロセス、外部サービス、課金システムにまたがるようになると、どのステップで中断しても状態の不整合を引き起こしかねません。

私たちは実行プロセスを一連の Step に分割しました。各 Step には、1 回のモデル推論と、モデルが提案したひとまとまりのツール呼び出しを含めることができます。

ツールを実行する前に、ランタイムはまずモデルの意思決定の結果と、これから実行する呼び出しを永続化します。ツール呼び出しにはそれぞれ安定した業務上の識別子があり、実行台帳にその状態、入力、結果が記録されます。

こうしておけば、Worker が復旧したときに、どの操作が完了済みか、どれがリトライ可能か、どれは先に外部の状態を突き合わせる必要があるかを台帳から判断でき、同じラウンドのツール判断を生成するためにモデルを呼び出し直す必要がありません。

flowchart TD
    S["Inbox と現在の実行状態を読み込む"] --> L["モデル推論で返信とツール呼び出しの意図を生成"]
    L --> P["モデルの結果と実行予定の呼び出しをアトミックにコミット"]
    P --> X{"呼び出しに永続化済みの結果があるか？"}
    X -->|はい| REUSE["既存の結果を再利用"]
    X -->|いいえ| K{"以前に実行済みの可能性があるか？"}
    K -->|いいえ| EXEC["ツール呼び出しを送信"]
    K -->|はい| I{"冪等なリトライに対応しているか？"}
    I -->|はい| EXEC
    I -->|いいえ| UNKNOWN["結果不明としてマークしモデルに返す"]
    EXEC --> SAVE["ツールの結果と業務状態を永続化"]
    REUSE --> NEXT["次の呼び出しまたは Step へ"]
    SAVE --> NEXT
    UNKNOWN --> CHECK["まず現在の状態を照会し、リトライの要否を判断"]
    CHECK --> NEXT

図 5：Agent の Durable Execution の流れ。

ここで重要になる概念が 冪等性（Idempotency） です。

ユーザーが動画の生成を承認した後、システムがネットワークのタイムアウトによって同じリクエストを重複して送信したとします。理想的には、2 回の送信は同じ 1 件の生成注文に対応すべきで、同じ動画が 2 本できてはいけませんし、ましてや二重に課金されてはなりません。

冪等キーに対応した下流サービスであれば、安定した呼び出し識別子を使って重複を排除できます。プラットフォーム内部の注文や課金のフローについても、呼び出し ID、注文 ID、一意制約によって、重複したリクエストが新たな業務上の効果を生まないようにできます。

しかし、上流の生成 API が冪等キーにも対応しておらず、リクエストの結果を照会することもできない場合、ネットワークのタイムアウト後にシステムはタスクが作成されたかどうかを実際には確認できません。

このとき、Durable Execution が何もないところから Exactly-once（厳密に 1 回の実行）を保証してくれるわけではありません。

ここではさらに 2 つのケースを区別する必要があります。冪等にできない一部のツールについては、実行台帳に started が記録されたまま結果が得られない場合、ランタイムはそのまま再実行せず、outcome_unknown マーク付きの結果をモデルに渡して、まず現在の状態を確認してから次の動作を決めさせます。冪等に対応した呼び出しであれば、元の呼び出し識別子を使ってリプレイできます。

もう 1 層の不確実性は、生成サービスと上流 API との間で生じます。ここではより保守的な方針を採っています。送信結果が不明な場合はその送信を失敗と判定し、上流へ自動で再度リクエストを送ることはしません。どちらも「結果不明」と呼ばれますが、一方は Agent のツール呼び出しの復旧を扱うもので、もう一方は実際に課金される生成タスクの重複作成を防ぐためのものです。

Temporal も Activity のリトライで同じ問題に直面しています。ワークフローエンジンは実行を確実にスケジューリングしリトライできますが、外部 API の副作用には、やはり業務側の冪等性の仕組みが組み合わさる必要があります。

有料の生成サービスにとって、この境界は特に重要です。実行の失敗は復旧できても、二重課金は自動的に埋め合わせられるとは限らないからです。

4.2 Worker の引き継ぎと Fencing Token

Durable Execution によってプロセス中断後の復旧の問題は解決できますが、もっと気づきにくいケースもあります。元の Worker が実は終了していないかもしれない、というものです。

たとえば、Worker A が実行中にネットワークの瞬断で一時的に連絡が取れなくなったとします。システムはタイムアウトを検知し、Worker B がタスクを引き継いで実行を続けます。数秒後、Worker A が接続を回復し、先ほど完了した自分の結果をコミットしようとします。

このとき、システムには自分が実行権を持っていると考える Worker が 2 つ同時に存在しうることになります。何も制限しなければ、古い Worker が新しい状態を上書きしたり、すでに停止したタスクを再び実行フローに戻したりしかねません。

そこで私たちは、Fencing Token（フェンシングトークン） に似た実行世代の仕組みを採用しました。

タスクが新しい実行者に引き継がれるたびに、ランタイムはそのタスクの実行世代を引き上げます。Worker は状態の変更をコミットする際、自分が保持している世代を必ず添えて検証しなければなりません。

データベース上の現在の世代がすでに更新されていれば、古い Worker のコミットは拒否されます。

この仕組みは、新しい実行者に作業の引き継ぎを認めると同時に、古い実行者から内部状態を変更し続ける資格を取り上げるもの、と考えることができます。

ユーザーが自らタスクを停止した場合も、実行状態と実行世代のチェックを通じて、古い Worker が復帰後に処理を進めるのを防ぐ必要があります。

ただし、Fencing Token が守るのはシステム自身の状態の一貫性です。古い Worker がすでに外部プラットフォームに動画生成リクエストを送信していた場合、内部の実行権が無効になっても、リモート側の操作が自動的に取り消されるわけではありません。

そのため、ユーザーがタスクを停止した後も、先に送信した外部生成が動き続けることがあります。生成サービスはタスクの結果を引き続き追跡して対応する費用の精算を完了させますが、遅れて届いた完了イベントが停止済みのタスクを再び起こすことはなく、すでにキャンセルされた実行状態を変えることもありません。

4.3 実行中に届いたユーザーの新しいメッセージをどう扱うか

ユーザーによるリアルタイムの介入からも、また別の種類の問題が生じます。

Agent がモデルを呼び出して、ポスター一式を生成しようとしているとします。そこへユーザーから「背景は白じゃなくて、濃い青にして」と届きました。

このメッセージはモデルの推論が終わる前にサーバーに届いているかもしれませんが、現在のモデルリクエストは実際にはそれを読み込んでいません。

システムがメッセージの作成時刻だけで履歴をつなぎ合わせると、状態の食い違いが起こりえます。見かけ上はユーザーが要件を変更した後にモデルが判断を下したように見えるのに、実際にはモデルはその新しい指示をまったく知らない、という状態です。

この問題を解決するために、私たちはメッセージの受信とメッセージの消費を分けて扱うことにしました。

新しいメッセージは、まず対応するタスクの永続化された Inbox に入ります。Worker は次の安全な実行の区切りでこれらの入力を読み込み、現在のタスクの状態とあわせてモデルのコンテキストに組み込みます。

システムは、メッセージの送信時刻だけで前後関係を判断するのではなく、そのメッセージがどの Step で実際に消費されたかを記録します。

これにより、ユーザーの指示が届いた段階、モデルが理解した段階、関連する操作が実行された段階を明確に区別できます。

もちろん、生成リクエストがすでに上流に送信されていれば、後から届いた修正によって生成中の内容が自動的に変わることはありません。現在のバージョンではこうしたリクエストを取り消すこともできず、Worker にできるのは、次の安全な実行の区切りで再生成するかどうかを判断するか、新しい制約を後続のステップに適用することだけです。ユーザーがすでにタスクを停止していれば、古い生成がその後完了しても、タスクの実行が再開されることはありません。

ユーザーにとっても、インターフェースがこの状態を正確に伝える必要があります。「メッセージを受け取った」ことが「現在の生成が新しい要件に合わせて調整された」と誤解されないようにするためです。

動画、音声、3D のような時間のかかる生成タスクでは、Worker はさらに、外部の結果を待つ間は実行リソースを解放し、イベントが届いたら正確に再開する必要があります。

4.4 実行台帳とスケジューリングの一貫性の境界

ここまで、モデルの意思決定の永続化と、実行世代によってタスクの引き継ぎ後に古い Worker が状態を変更し続けるのを防ぐ方法について述べてきました。しかし実際の運用では、見落とされがちな問題がもう 1 つあります。データベースには実行待ちの作業がすでに記録されているのに、Worker を起こすためのキューメッセージが失われた場合、タスクはどう復旧すればよいのか？

Lomo Agent では、ターン（Turn）とツール呼び出しの台帳によって実行状態を管理しています。ターンには実行状態、実行世代、リース、チェックポイント（Checkpoint）を記録し、ツール呼び出しは「ターン + ステップ番号 + 呼び出し番号」を安定した識別子とします。モデルが応答を返すと、ランタイムは意思決定の結果、実行予定の呼び出し、消費済みの Inbox メッセージを同じトランザクションの中で保存します。ツールの実行前には started を記録し、完了後には結果を done 状態とあわせて保存します。こうしておけば、復旧時には既存の記録にもとづいて結果を再利用したり安全にリトライしたりでき、それまでに何が起きたかをモデルに推測し直させる必要がありません。安全にリトライできない呼び出しについては、結果不明の状態を保持し、後続の意思決定に委ねます。

タスクのスケジューリングでは、ターンのエンキューにトランザクショナル Outbox を導入せず、データベースを実行の事実の情報源とし、キューは主に Worker を起こす役割を担うようにしました。ターンをコミットした後にスケジューリングメッセージを送り、エンキューに失敗した場合は、バックグラウンドのウォッチドッグがデータベースの状態からタスクを再発見します。現在、ウォッチドッグは 10 秒ごとにチェックを行い、主にリースの期限切れ、長時間のキュー待ち、そして未処理のメッセージがあるのにアクティブなターンがないタスクに注目しています。キューのジョブはターン ID と実行世代で識別し、同じ世代の重複エンキューを減らしています。重複したスケジューリングが起きても、ランタイムは実行状態と世代の検証によって期限切れの書き込みを防ぎます。つまり私たちは、限定的な復旧の遅延を受け入れる代わりに、よりシンプルなスケジューリングの仕組みを得ているということです。UI へのイベントプッシュと外部生成タスクには、それぞれ独自の確実な配送と補償の仕組みを残しています。

もう 1 つのリスクは、新旧の Worker の並行実行から生じます。Fencing Token は古い Worker が内部状態を上書きするのを阻止できますが、すでに送信された外部リクエストを取り消すことはできません。そこで私たちは、有料生成の冪等キーを「ターン + ステップ番号 + 呼び出し番号」に固定し、実行世代は含めないようにしました。新旧の Worker が同じ呼び出しを重複して送信しても、プラットフォームの生成層は「ワークスペース + 冪等キー」の一意制約によって同じ 1 件の注文に関連付け、内部の課金も重複排除します。これでプラットフォーム内部の重複注文と重複課金は抑えられますが、外部の上流がもともと Exactly-once を保証しているという意味ではありません。一方、モデルの意思決定がまだ永続化されていない段階で障害が起きると、そのステップの推論がやり直しになる可能性があります。現在はメディア生成が中心のコスト構造であることを考え、この比較的限られた推論の重複コストは受け入れることにしました。

さらに厄介なのは、上流への送信結果がはっきりしないケースです。リクエストのタイムアウトは、送信に失敗したことを意味する場合もあれば、上流ではタスクが作成されたのにレスポンスが返ってこなかったことを意味する場合もあります。重複生成を避けるため、現在の生成サービスはこうしたリクエストを自動で再送信しません。上流のタスク ID を取得できたら、中断後もポーリングを続けられるよう、すぐに永続化します。ただし、ID を取得してから保存するまでの間にちょうどプロセスがクラッシュした場合、現時点ではそのタスクを逆引きで照会する手段がありません。システムにできるのは、タイムアウト後にルールに従って返金を処理し、すでに発生した可能性のある上流の費用をプラットフォームが負担することだけです。

これらの設計ですべての障害の窓をなくせるわけではありませんが、状況ごとの処理の境界ははっきりさせています。完了を確認できたものはそのまま再利用し、安全にリトライできるものは実行を続け、確認できないものはやみくもに再送信しない。 継続的に動く Agent にとって信頼性とは、どのステップも失敗しないことではなく、中断が起きた後も、システムが既存の事実にもとづいて制御された復旧の判断を下せることなのです。

5. 非同期生成：タスクのライフサイクルとイベント駆動の起動

これまで紹介してきた Durable Execution は、主に Agent が動作中にどう状態を記録し、障害を処理し、実行を復旧するかという問題を解決するものでした。しかし AI 創作のシーンには、避けて通れない特徴がもう 1 つあります。大量のツール呼び出しが、それ自体非同期であるということです。

たとえば、画像生成は数秒で済むかもしれませんが、動画や 3D のタスクは数分、あるいはそれ以上かかることもあります。タスクを送信しても、上流のサービスは通常タスク ID を返すだけで、実際の生成結果はポーリングかコールバックによって取得する必要があります。

Worker に外部タスクの完了をずっと待たせると、実行リソースを占有するだけでなく、モデル推論と、制御できない外部生成の所要時間とが結びついてしまいます。

そこで私たちは、Agent の実行ライフサイクルと外部生成タスクのライフサイクルを分けて管理することにしました。

5.1 送信、待機、そして実行の再開

Worker が生成ツールを呼び出すと、ツールはまず対応するサービスにリクエストを送信し、生成ジョブの識別子を返します。続いてランタイムが、生成ジョブと現在のタスクとの関連付けを保存します。これにはジョブ ID、待機状態、その後の実行に必要な情報が含まれます。

送信が終われば、Worker は現在の実行をサスペンドできます。モデルを呼び出し続ける必要も、長時間動き続ける推論リクエストを維持する必要もありません。

待機中、生成サービスの進捗の変化は業務イベントとして直接フロントエンドにプッシュでき、タスクカードに現在の状態が表示されます。

ジョブが完了したら、ランタイムは後続のステップが生成結果に依存しているかどうかにもとづいて、Worker を再び起こすかどうかを判断します。

sequenceDiagram
    participant W as Task Worker
    participant G as 生成サービス
    participant S as 永続化ランタイム
    participant UI as タスクカード

    W->>G: 生成リクエストを送信（安定した業務識別子付き）
    G-->>W: ジョブ ID を返す
    W->>S: ジョブとの関連付けと待機状態を保存
    Note over W,S: 以上は正常な経路。送信後に保存できなかった異常は 4.4 を参照
    S-->>UI: 生成中に更新

    Note over W: Worker はサスペンドし実行リソースを解放

    G-->>S: 生成の進捗イベント
    S-->>UI: 進捗を更新（モデル推論は不要）

    G-->>S: 生成完了イベント
    S->>S: ジョブの状態を更新し成果物を保存
    S-->>UI: 生成結果を表示

    alt 後続のステップが生成結果に依存する
        S->>W: 実行再開イベントを配送
        W->>W: 最新の状態を読み込み実行を続ける
    else 現時点では推論を続ける必要がない
        Note over UI: 結果とタスクの状態のみ更新
    end

図 6：非同期生成タスクの実行の流れ（正常な経路）。

この設計による直接的な効果は、リソース利用率の改善です。動画の生成を待つ数分の間、システムは永続化された状態と必要なイベント処理を維持するだけでよく、Agent の推論リソースを占有し続ける必要はありません。

同時に、生成の進捗とユーザーインターフェースも独立して更新できます。ユーザーは Worker がモデルを再び呼び出すのを待たずに、タスクの状態をリアルタイムで確認できます。

5.2 非同期イベントも確実に処理する必要がある

生成タスクをイベント駆動に変えたら、今度はイベントそのものの信頼性も考えなければなりません。

たとえば、上流のサービスがネットワークの問題で完了通知を重複して送ってくることもあれば、あるコールバックが失敗した後すぐにはリトライできないこともあります。複数の生成タスクが同時に動いている場合、進捗イベントが順不同で届くこともあります。

そのため、イベント処理を単純に「コールバックを受け取ったら実行を続ける」と捉えるわけにはいきません。

永続化されたジョブの状態を拠り所として生成タスクの状態を更新し、重複したイベントによって書き込み、課金、Worker の起動が重複しないようにする必要があります。

順不同で届く可能性のあるイベントについては、古い進捗が最終結果を上書きしないようにすることも必要です。たとえば、ジョブがすでに完了した後に、遅れて届いた「生成中」の通知を受け取っても、状態を巻き戻してはいけません。

さらに、外部からのコールバックが常に信頼できるとは限りません。長時間結果が届かないジョブについては、ジョブ ID と上流の照会 API を使って状態を突き合わせ、必要に応じて補償ポーリングでタスクの進捗を回復させることができます。

ここは前述の Durable Execution と互いに補い合う関係にあります。ランタイムは信頼できる実行状態を維持する責任を持ち、非同期タスクの仕組みは外部生成の過程で起きた変化を、復旧可能な業務イベントに変換する責任を持ちます。

5.3 どんなときに Worker を起こすべきか？

モデル呼び出しのコストに直結する問題がもう 1 つあります。生成タスクが完了するたびに、毎回モデルを呼び出し直す必要があるのか？

答えは、そのタスクの後に Agent の判断を要する作業がまだ残っているかどうかによります。

たとえば、ユーザーが「猫の画像を 1 枚生成して」と頼んだだけなら、生成が完了したら結果をそのまま表示すれば十分です。わざわざ Worker を起こして、生成済みの画像をモデルにもう一度説明させる必要はありません。

しかし、ユーザーが「スタイルの統一されたブランドポスターを一式作って」と頼んだ場合、現在の生成結果は後続のステップの入力になる可能性があります。Agent は既存の成果物を確認し、実行チェックリストを読み込み、現在の目標に照らして、次に生成を続けるのか、ユーザーの確認を待つのかを判断する必要があります。

そこで私たちは、生成完了イベントと、Agent が自動で続行するかどうかの判断とを分けて扱うことにしました。

生成サービスは結果の報告に責任を持ち、ランタイムはタスクの計画、待機関係、承認、現在の実行状態にもとづいて Worker を再開させる必要があるかを判断します。

これにより、大量の進捗イベントをそのままモデルに処理させることも避けられます。数分続く動画タスクでは上流で多くの状態変化が起きることがありますが、その大半はフロントエンドを更新するだけでよく、新たな推論を走らせるほどの価値はありません。

このイベント駆動の設計は、汎用ワークフローエンジンやタスクキューにおける非同期待機の仕組みに近いものです。Lomo Agent では、それを創作の目標、実行チェックリスト、ユーザーのレビューフローとどう組み合わせるかに、さらに重点を置いています。

たとえば、ある動画カットの生成が完了したとき、後続でほかのカットも制作する必要があり、かつユーザーが続行をすでに承認していれば、ランタイムは対応するタスクを再開できます。一方、現在のフェーズでユーザーのレビューが必要なら、確認待ちの状態にとどまるべきです。

生成の完了が意味するのは、あるツール呼び出しが終わったということだけです。創作タスク全体を続けるべきかどうかは、計画、予算、承認と照らし合わせて判断する必要があります。

ここから、後で扱う自律的な推進の仕組みにつながっていきます。Agent があるフェーズを終えたとき、あるいはこのラウンドの推論を終えようとしているときに、タスクが本当に完了したのか、実行を続けるべきなのかを、システムはどう判断するのか、という問題です。

6. コンテキストエンジニアリング：限られたウィンドウの中で有効な状態を保つ

Agent が長時間・多段階の創作タスクを扱うようになるにつれ、コンテキスト管理は実行の品質とコストを左右する重要な要素になっていきます。

数日にわたる創作タスクには、数百件のメッセージ、数十回のツール呼び出し、そして大量の画像、動画、ワークフローの状態が蓄積されていきます。モデルのコンテキストウィンドウがいくら大きくなっても、これらすべてを毎回の推論に詰め込むのは現実的ではありません。

長いコンテキストは Token のコストと推論のレイテンシを押し上げますし、過去の情報が多すぎると、現在の目標に対するモデルの判断を妨げることもあります。特にユーザーが何度も要件を変更した場合、すでに無効になった初期の制約がコンテキストに混ざったままだと、後続の生成に影響を与えやすくなります。

そのため私たちは、コンテキスト管理を独立したエンジニアリングの課題として扱っています。推論の各ステップで、十分かつ関連性があり、なおかつまだ有効な情報をモデルにどう渡すか、という課題です。

6.1 コンテキストの階層化と Prompt Cache

Lomo Agent は、モデルのコンテキストをいくつかの層に分けて組み立てています。比較的安定したシステムプレフィックス、圧縮済みの履歴、最近のやりとり、そして現在の実行ステップに必要な動的な状態です。

flowchart LR
    A["安定したプレフィックス：システムルール / コアツール / ユーザープロファイルのスナップショット"] --> B["区間ごとの履歴要約"]
    B --> C["最近のメッセージと重要なツール結果"]
    C --> D["動的な末尾：ブリーフ / チェックリスト / 予算 / オブジェクトの変更"]
    D --> E["このステップの入力とオンデマンドの呼び出し"]

図 7：Lomo Agent のコンテキストの組み立て方。

ここには、実際の推論コストと密接に関わる要素があります。Prompt Caching（プロンプトキャッシュ） です。以下でいう Prompt Cache は、モデル提供事業者が API レイヤーで提供するプロンプトキャッシュ機能を指します。その具体的な実装や再利用できる範囲は事業者ごとに決まります。

この機能をサポートするモデルサービスは、そのキャッシュルールを満たすプロンプトのプレフィックスを再利用し、重複処理のコストを減らせます。そのため私たちは、システムルール、コアツール、比較的安定したユーザープロファイル情報をできるだけコンテキストの前方に置き、ステップごとに変わりうるタスクの状態は後方に置くようにしています。

変化の激しい情報をプレフィックスの先頭に差し込んでしまうと、その後ろにある本来は安定した内容まで、キャッシュをうまく再利用できなくなるおそれがあります。

ただし、Prompt Cache の実際のヒット率は、モデルの提供元、リクエストのルーティング、キャッシュ戦略にも左右されます。コンテキストのレイアウトはキャッシュ再利用の条件を整えることしかできず、最終的な効果は実際の呼び出しデータで検証する必要があります。

また、プレフィックスが安定しているからといって、ユーザープロファイルを長期間更新しなくてよいわけではありません。ユーザーが好みを変えたり、ある情報を忘れるよう求めたりした場合には、関連するプロファイルのスナップショットを速やかに無効化し、キャッシュの再利用によって古い情報が推論に使われ続けないようにする必要があります。

6.2 ツールのオンデマンド読み込み：機能が多いほどコンテキストは高くつく

Lomote AI は多様な創作モデルとツールを統合しており、画像生成、動画生成、3D、素材管理、ドキュメント編集、Flows ワークフローなど、さまざまな領域にまたがっています。

すべてのツールの名前、パラメータ、使い方の説明を毎回のモデルリクエストに入れると、Token の消費が増えるだけでなく、似たようなツールが大量に並ぶ中でモデルが選択を誤るおそれもあります。

そこで私たちはツールを 2 種類に分けました。常に見えている必要があるコアツールと、機能領域ごとに動的に読み込むツールです。

たとえば、Agent が絵コンテを計画している段階ではドキュメントと素材関連のツールだけで足りるかもしれず、動画制作の段階に入ってから動画生成とワークフローの機能を読み込みます。

使われなくなったツール領域については、コンテキスト圧縮の区切りで詳細な定義を取り除き、無関係な情報が後続の推論に影響するのを減らせます。

この設計にも代償があります。ツールの集合が変わると、モデルのコンテキストの構造もそれに伴って変わり、Prompt Cache のヒット率に影響することがあります。また、履歴にすでに現れているツール呼び出しが、現在見えているツール定義と完全には一致しないこともあります。

この点について、Manus の Context Engineering の実践 は、考える価値のある対照的な例を示してくれました。

Manus はツール定義を安定させておくことを重視し、現在使えるアクションを制約することでツール選択の複雑さを下げています。こうすることで、ツール定義の変化によるプレフィックスの無効化を減らしやすくなり、過去のツール呼び出しと現在のコンテキストとの一貫性も保ちやすくなります。ここで扱っているのは安定したコンテキストがキャッシュの再利用に与える影響であり、API レイヤーの Prompt Caching とモデル推論内部の KV Cache の仕組みを同一視しているわけではありません。

Lomo Agent が領域ごとの読み込みを選んだのは、主に創作プラットフォームのツールの種類やパラメータ構造が比較的膨大で、すべてのツール定義を常に保持しておくとコンテキストのオーバーヘッドが大きくなりかねないと考えたからです。

2 つの戦略にはそれぞれ適した条件があります。ツールの集合を安定させればキャッシュと振る舞いの一貫性に有利で、動的な読み込みは無関係なツールによる Token コストや選択の混乱を減らせる可能性があります。

私たちの方式については、ツールの切り替え頻度、キャッシュのヒット率、ツール呼び出しの正確さ、推論コスト全体を合わせて、実際の効果を継続的に評価していく必要があります。なお、ツールがモデルのコンテキストに現れるかどうかは、モデルがいま何を選べるかに影響するだけです。実際のツール実行権限は引き続きサーバー側で制御しており、Prompt 内でツールが見えるかどうかをセキュリティ境界として頼ることはできません。

6.3 履歴の圧縮：要約に加えて、読み返せる能力を残す

長期間の実行では、履歴メッセージとツールの結果が増え続けます。大きめのコンテキストウィンドウを使っていても、適切なタイミングで圧縮する必要があります。

よくあるやり方は、モデルにそれまでの履歴を繰り返し要約させ、最新の要約を使って会話を続けるというものです。しかしこの方法には問題があります。圧縮を繰り返すうちに要約から細部が少しずつ失われ、さらにはモデル自身の推測が過去の事実として固定されてしまうことさえあるのです。

そこで私たちは区間ごとに要約する方針を採り、古い履歴は区間単位で圧縮しつつ、最近のやりとりは内容をそのまま残しています。

新たに作られた要約は、できるだけ既存の要約の列に追記するようにし、毎回履歴全体を書き直すことは避けています。

素材一覧、ワークフローのノード情報、複雑な生成結果のような大きなツール出力については、現在のコンテキストには必要な要約だけを残し、完全な内容は外部ストレージに置くことができます。

Agent が後で特定のパラメータや過去の細部を確認する必要が出てきたら、検索やページング読み込みによって関連情報を取り戻します。

これは、Manus が提唱する、ファイルシステムを外部のコンテキストの置き場として使う考え方と通じるところがあります。モデルはすべての情報を常に抱えている必要はありませんが、必要なときに信頼できる元の根拠を改めて見つけ出せなければなりません。

ここには注意すべき違いがもう 1 つあります。要約は現在の推論におけるコンテキストの負担を減らすためのものであり、過去の事実の唯一の情報源になるべきではありません。 特にユーザーがある情報を訂正した場合や、ある過去の制約がすでに無効になった場合には、システムが関連する出所を特定でき、古い要約がその後の実行に影響し続けないようにする必要があります。

6.4 現在のタスクを常にモデルの視野に入れておく

コンテキストの圧縮で履歴が長すぎる問題は解決できますが、同じくらい重要な問題がもう 1 つあります。実行の途中で、Agent は自分がどんな目標に取り組んでいるのかをまだはっきり把握しているでしょうか。

長時間動くタスクでは、何ラウンドものツール呼び出しを経るうちに、モデルが当初の目標から少しずつずれていくことがあります。たとえば、ユーザーはブランドポスター一式の完成を求めているのに、Agent が 1 枚の参考画像の調整を繰り返すことに労力の大半を費やし、全体の納品をおろそかにしてしまう、といった具合です。

そのため私たちは、Worker の動的なコンテキストに、現在のブリーフ、実行チェックリスト、重要な制約、待機状態、関連する作品の最新の変更を継続的に提供しています。

これらの状態は永続化ランタイムから取得したものであり、モデルがそれまでのチャット内容をまとめた要約だけに頼っているわけではありません。

たとえば、次のようなものです。

• ブリーフには、ユーザーが最終的に承認したビジュアルの方向性を記録する

• 実行チェックリストには、どのステップが完了し、どれがまだ残っているかを記録する

• ワークスペースの状態は、ある素材がユーザーによって差し替えられたかどうか、現在のドキュメントがどのバージョンかをモデルに伝える。

ユーザーが Flows ワークフローや共有ドキュメントを直接変更した場合にも、次のラウンドの実行でオブジェクトの変更通知を受け取り、必要に応じて最新の内容を読み込めます。

こうしておけば、履歴の一部がすでに圧縮されていても、Agent は信頼できるタスクの状態にもとづいて作業を続けられます。

この点では、Manus が ToDo リストを繰り返し提示することでモデルの目標への注意を保っている点からも多くのヒントを得ました。Lomo Agent はさらに、こうしたリストをランタイムの状態と結びつけ、モデルにコンテキストを提供するだけでなく、その後の自動続行や停止の判断にも使えるようにしています。この部分は、自律的な推進の章で詳しく紹介します。

6.5 コンテキストエンジニアリングにおける実際の取捨選択

まとめると、Lomo Agent のコンテキストエンジニアリングは主に 3 つの目標を軸にしています。

• 無関係な情報を減らす

• 推論コストを抑える

• 現在の判断の拠り所となる情報がまだ有効であることを保証する

しかし、これらの目標は常に一致するわけではありません。

より積極的に圧縮すれば Token の消費は減らせますが、重要な細部を取りこぼすおそれがあります。ツールを動的に読み込めばツール選択の幅は絞れますが、キャッシュのヒットに影響しかねません。安定したユーザープロファイルを長く保持すれば連続性は高まりますが、好みの変化や記憶の取り消しにも対処しなければなりません。

そのため、1 つの固定的な戦略だけでコンテキスト管理のあらゆる問題を解決するのは困難です。タスクの状態、記憶の仕組み、ツールの権限、実際のモデルの振る舞いと合わせて、一緒に調整していく必要があります。

Lomo Agent で私たちがより重視しているのは、必要なときにモデルが正しい情報を見つけ出し、現在有効なタスクの状態にもとづいて作業を進められるかどうかです。そして協働が複数のタスク、複数の日付、さらには数か月にまたがるようになると、タスク内部のコンテキスト管理だけではまだ足りません。ユーザーが長い時間をかけて形づくってきた好み、過去のプロジェクト、かつて下した判断は、別の仕組みで整理し、検索できるようにする必要があります。

7. Memory エンジニアリング：出所、バージョン、取り消し可能性

前の章では、限られたコンテキストウィンドウの中で情報をどう組み立てるかを取り上げました。しかし長期的に協働する Agent には、さらに根の深い問題があります。ある会話がすでに現在のコンテキストから外れ、関連するタスクもとっくに終わっているとき、システムは何を覚えておくべきか？

Lomo Agent の創作シーンでは、ユーザーは数か月にわたってプラットフォームを使い続け、比較的安定したビジュアルの好み、よく使う創作フロー、ブランドの規定を少しずつ形づくっていきます。こうした情報を、毎回ユーザーに説明し直してもらうべきではありません。

その一方で、ユーザーの好みは変わることもあります。あるプロジェクトで採用した一時的なスタイルが、その後のすべての創作に当てはまるとは限りませんし、かつて有効だったブランド規定が、一度のリニューアルで完全に無効になることもあります。

そこで私たちは、長期記憶がタスクや時間をまたいで連続性を提供しつつ、事実の出所と有効範囲も保持できるようにしたいと考えました。

7.1 履歴メッセージから長期記憶へ

長期記憶がまず解決すべきなのは、情報の選別です。

たとえば、ユーザーが「普段は彩度の低い配色が好き」と言えば、長く保存しておく価値のある好みかもしれません。しかし「今回はまず彩度の高い赤を試してみて」と言った場合は、今の作品に限った要望である可能性のほうが高いでしょう。

どちらも色に関する発言ですが、適用範囲が異なります。システムがユーザーのメッセージをすべてそのままベクトルデータベースに書き込み、意味検索で呼び戻すようにすると、長期的な好み、一時的な要望、すでに無効になった過去の情報が簡単に混ざってしまいます。

そこで私たちは、Lomo Agent の記憶をいくつかの層に分けました。

これらの層は互いにある程度関連していますが、担う役割は異なります。

元のメッセージは追跡可能な証拠です。システムはそこから候補となる記憶を抽出し、出所、時刻、適用範囲、既存の記録にもとづいて、保存・補足・更新が必要かどうかを判断します。

エピソード要約は、ひとまとまりの協働で何が起きたかに重きを置きます。たとえば、ユーザーが先週ブランドポスターを一式制作し、最終的に暖色系の案を選び、その後の動画制作はいったん見送ると決めた、といった情報です。これらすべてが長期的なプロファイルに入る価値があるとは限りませんが、ユーザーが次にそのプロジェクトを持ち出したときに役立つかもしれません。

ユーザープロファイルには、より抑制が求められます。比較的安定した少量の情報だけを保持すべきで、使用期間が長くなるにつれて膨らみ続けるもう 1 つの会話履歴になってしまうのは避けなければなりません。

実際に呼び出す際には、システムが現在のタスクの目標と権限にもとづいてモデルに渡す記憶を選ぶので、毎ラウンド完全な履歴を読み込む必要はありません。

ここにはもう 1 つ重要な原則があります。記憶は、ユーザーが明確に表明した事実と、モデル自身の推測とを区別しなければならないというものです。

たとえば、ユーザーがサイバーパンクの画像を何枚か続けて生成したことから、Agent がその人は長期的にサイバーパンク風を好むと推測したとします。これは候補としての判断にはなりえますが、ユーザーが明確に表明した好みとそのまま同一視することはできません。

同様に、Web ページの内容、ツールが返した結果、Agent 自身が生成した要約も、信頼できる根拠がないまま、ユーザー個人に関する事実として包み直されるべきではありません。

7.2 既存の記憶アーキテクチャから得たヒント

長期記憶の設計にあたっては、いくつかの異なる技術的アプローチを参考にしました。

OpenClaw の記憶の実践では、確認・保守しやすい保存方法と、記憶と元のコンテキストとの関係が重視されています。透明性が比較的高く、何が保存されているかをユーザーや開発者が確認しやすいのが利点です。ただ、記憶の規模が増え続けると、検索、保守、競合の処理にはやはり追加の仕組みが必要になります。

Mem0 は、会話から価値のある情報をどう抽出し、その後のやりとりで検索によって関連する記憶をどう取り戻すかに重きを置いています。このやり方は長時間・話題横断で使われるエージェントに向いていますが、記憶の質は抽出の正確さと呼び出し戦略に大きく依存します。一時的な指示を長期的な好みと誤判定してしまうと、その後の検索がかえって誤りを増幅し続けることにもなりかねません。

Zep / Graphiti は、また別の考え方を示しています。記憶の中でエンティティ間の関係と時間情報を明示的に管理するというものです。これは移り変わっていく事実を扱ううえで特に価値があります。たとえば、あるブランドが以前は青をメインカラーにしていて、後に緑に変えた場合、2 つの記録は必ずしも矛盾しているわけではなく、それぞれ異なる有効期間に対応しているのかもしれません。

ただし、時間的な関係やナレッジグラフは、エンティティの正規化、関係の更新、競合の処理、検索コストなど、保守の複雑さも高めます。

Lomo Agent の創作シーンに照らして、私たちが特に重視しているのは次の 3 つです。

1. ユーザーの好みに信頼できる出所があるか

2. 過去の事実がまだ有効か

3. ユーザーが情報を訂正・取り消したとき、関連する記憶も連動して更新できるか

そのため、一般的な階層型の保存と意味検索に加えて、記憶ごとに出所、バージョン、派生関係も管理しています。

7.3 「忘れる」ことはなぜ「覚える」ことより難しいのか

長期記憶には、見落とされがちな問題がもう 1 つあります。ユーザーがある内容を忘れるよう明確に求めたとき、システムはどう対処すべきでしょうか。

ユーザーが最初に「うちのブランドのメインカラーは青です」と言ったとします。

その後、「青にオフホワイトを合わせると、全体がもっと柔らかい印象になります」と付け加えました。

記憶の仕組みは、この 2 つの発言を 1 つの新しいブランドの好みにまとめるかもしれません。

「このブランドは青とオフホワイトの組み合わせを好み、全体のビジュアルは柔らかいスタイルを志向している」

その後ユーザーが、最初の青に関する設定を忘れるよう求めた場合、1 つ目のアトミック記憶を削除するだけでは明らかに不十分です。統合後のバージョンにも関連する情報が残っているからです。

システムが動き続けるうちに、この情報はエピソード要約やユーザープロファイルに入り込み、さらにはほかの派生した記憶にまで統合されている可能性があります。

そこで私たちは、記憶ごとに出所と派生関係を管理し、ある記憶がどの過去の証拠や旧バージョンから派生してきたのかを記述できるようにしています。

flowchart TD
    U["ユーザーが忘れてほしい内容を指定"] --> A["関連する証拠から記憶としての利用資格を取り消す"]
    A --> B["影響を受ける記憶のバージョンを特定"]
    B --> C["派生関係をたどって後続のバージョンを探す"]
    C --> D["影響を受けた内容を無効化し、まだ有効な証拠を確認"]
    D --> E["残った有効な証拠から再抽出"]
    E --> F["アトミック記憶・要約・ユーザープロファイルを更新"]
    F --> G["関連する検索インデックスとコンテキストキャッシュを無効化"]

図 8：記憶の取り消しの流れ。

実際の実装では、バージョンチェーンによって記憶の変遷を管理しています。先ほどのブランドのメインカラーの例でいえば、最初の青に関する発言は有効なバージョン v1 となり、元の証拠（ORIGIN）に関連付けられます。ユーザーがオフホワイトとの組み合わせを付け加えると、システムは新しいバージョン v2 を作り、元のバージョンを SUPERSEDED としてマークすると同時に、追加された修正の証拠（REFINE）を記録します。その後、既存の結論を確認するだけであれば CONFIRM として記録でき、記憶を新たに生成し直す必要はありません。

ユーザーが最初の青の設定を忘れるよう求めると、システムは対応する証拠の利用資格を取り消し、バージョンの関係をたどって影響を受ける記憶を特定します。その証拠に依存しているバージョンは削除されて内容が消去され、残った有効な証拠から改めて抽出されます。確認の役割しか果たしていない証拠は関連付けを解除するだけでよく、それとは独立して成り立っている記憶には影響しません。

この取り消しの処理は、ユーザープロファイルとエピソード要約にも波及します。関連するプロファイルの項目が無効になると、システムはプロファイルのバージョンを更新し、以降の推論で古いスナップショットが使われないようにします。影響を受けた要約は作り直す必要があります。同時に、対応する検索用ベクトルを削除し、削除済みの内容が再び抽出されるのを抑止することで、古い情報がコンテキストに再び入り込むリスクを下げています。

注意したいのは、すでに送信済みのモデルリクエストは即座に取り消せないという点です。そのため、返答やツールの結果がどのメッセージと記憶にもとづいていたのかも追跡し、以降の推論では影響を受けた派生コンテンツを除外して、忘れたはずの情報が Agent 自身の過去の出力を通じて再び持ち込まれないようにしています。

ここで述べている「忘れる」は、主に長期記憶とそこから派生したコンテキストの利用資格を対象としたものであり、元のチャット記録、生成した素材、取引データをすべて削除することとは異なります。後者は別のデータライフサイクルとプライバシー管理の問題であり、独立して扱う必要があります。

7.4 記憶の信頼性とフォールバック戦略

出所の追跡とバージョン管理によって記憶の仕組みの制御性は高められますが、モデルの理解の誤りを完全になくせるわけではありません。

たとえば、1 つの会話に複数の候補となる事実が含まれていて、そのうち 1 つは保存の条件を満たしているのに、もう 1 つはモデルが誤解した一時的な指示にすぎない、ということがあります。抽出結果をひとまとめにして分割できない 1 つの塊として扱うと、1 件の異常がほかの有効な記憶にまで影響しかねません。

そのため、候補となる記憶は 1 件ずつ検証・処理し、出所が裏付けにならない、内容が競合する、出力形式が異常である、といった異なるケースを区別する必要があります。

記憶サービスに障害が起きたときも、通常の創作タスクが完全に止まってしまうべきではありません。

たとえば、呼び出しがタイムアウトしたら記憶の補足を一時的にスキップすればよいですし、バックグラウンドでの抽出に失敗したら後から再処理すればよく、1 件の候補の形式が異常だからといって、ほかの有効な記録まで一緒に失う必要はありません。

このフォールバック戦略によって、Agent は場合によっては過去の好みをすべて使えないこともありますが、それでも現在のブリーフと既存の実行状態にもとづいて作業を続けられます。

問題のある記憶の結果がタスク全体に影響するよりは、通常の実行経路を保ち、記憶が復旧した後で関連する背景情報を改めて提供するほうを選んでいます。

長期記憶の価値は、最終的には実際の協働を通じて検証していく必要があります。呼び出しの正確さだけでなく、記憶が古くなっていないか、出所を説明できるか、ユーザーが訂正や取り消しを終えた後も古い情報がその後の判断に影響していないか、といった点も気にかけています。

クリックで拡大

記憶とタスクのコンテキストが少しずつ整ってきたことで、Agent は時間をまたいだ背景情報を得られるようになりました。しかし、ユーザーが過去に何をしたかを知っていることは、現在のタスクを続けるべきかどうかを判断できることを意味しません。

複数の創作ステップを含むタスクには、さらに明確な実行計画、停止条件、ユーザーによる承認の境界が必要です。これが、次の章の自律的な推進の仕組みで解決すべき問題です。

8. 自律的な推進：計画、停止条件、ユーザーによる承認

ここまでのいくつかの仕組みによって、Agent は長期的なタスクを管理し、中断した実行を復旧し、必要に応じて過去の情報を取り戻せるようになりました。しかし、継続的に進める必要のある創作目標には、まだ解決していない問題があります。Agent は、自分が作業を続けるべきかどうかをどう判断するのか？

たとえば、ユーザーがブランドのショートムービーの制作を依頼したとします。Agent は台本と絵コンテを仕上げた後、まとめを出して現在のラウンドを終えるかもしれません。このときモデルは間違ったことをしたわけではなく、現在のフェーズの作業を確かに完了しています。しかし、ユーザーが最終的に望んでいる完成映像までは、まだ長い道のりがあります。

初期のデモやシナリオリハーサルでは、実際にこうした状況に遭遇しました。ユーザーが何度も「続けて」と送らないと、Agent が次のフェーズに進まなかったのです。

一方で、単純にモデルに「すべてのタスクが終わるまで止まらないで」と求めると、別の問題が起きやすくなります。Agent がすでに失敗した操作を何度も試したり、不要な素材を生成し続けたり、ユーザーの確認がないまま創作の範囲を勝手に広げたりしかねないのです。そのため、タスクの目標と実行の進捗を 1 回ごとのモデルの返答から独立させ、自動で進める範囲の境界をランタイムが制御する必要があります。

8.1 計画を継続的に管理できる実行チェックリストに変える

私たちは、1 つの創作目標が計画から納品に至るまでの主なステップを記録するために、Execution Checklist（構造化された実行チェックリスト） を導入しました。

モデルがチャットの中で生成する普通の TodoList とは異なり、実行チェックリストはシステムが永続化して管理する構造化された状態です。各ステップには、実行状態、成果物、完了の証拠、必要なユーザー確認の要件を関連付けられます。

たとえば、ブランドのショートムービーを制作する場合は、次のように組み立てられます。

ユーザーが実行案を承認すると、チェックリストがその後の推進の拠り所になります。Worker は現在のステップにもとづいて計画とツール呼び出しを行い、ランタイムは各ラウンドの実行が終わるたびに進捗を確認できます。

注意したいのは、実行チェックリストが変更不可能な固定の計画ではないという点です。

創作の過程は頻繁に変わります。たとえば、ユーザーがカットの生成段階でキャラクターの設定を変えると決めた場合、既存のステップや一部の成果物を調整し直す必要が出てくるかもしれません。このときシステムは、ユーザーの新しい指示に応じて計画を更新し、ステップと成果物との関連付けを維持する必要があります。

実行チェックリストが解決するのは、目標と進捗の継続性です。コンテキストの圧縮、非同期の待機、プロセスの復旧の後でも、Agent が現在のタスクの実行位置を見つけられるようにします。

8.2 モデルが出力を止めた後、タスクは続けるべきか？

計画を永続化したら、さらに具体的な問いに答える必要があります。モデルが現在のラウンドを終えたとき、ランタイムはどう処理すべきか、という問いです。

この部分の仕組みを設計するにあたっては、Codex Goals と Claude Code Hooks の考え方を参考にしました。

Codex Goals は目標と継続的な実行状態を結びつけ、Agent がまだ完了していない目標に向かって作業を進め続けられるようにしています。Claude Code の Stop hook は、モデルが停止しようとしたときに追加のチェックを実行し、その結果にもとづいて今回の停止を阻止するかどうかを決められるようにしています。

この 2 つの設計から私が得たヒントは、モデルが 1 回の返答を終えたからといって、必ずしもタスク全体が完了したわけではない、ということです。ランタイムには、独立した目標の状態と停止チェックの仕組みが必要です。

ただし、コーディング Agent と創作 Agent とでは、完了の基準に明らかな違いがあります。

コードのタスクでは、テストが通る、ビルドが成功する、想定したファイルの修正が終わる、といったことが、通常は比較的明確な実行の証拠になります。創作のタスクには、統一された客観的な基準がほとんどありません。動画が無事に生成できたからといって、キャラクターの一貫性、カットのテンポ、全体のビジュアルがユーザーの期待どおりだとは言えません。

そこで私たちは、フローの進捗と作品の検収を分けて扱うことにしました。

前者は実行チェックリスト、ツール呼び出しの記録、成果物の状態にもとづいて判断できます。後者はマルチモーダルな理解、具体的なタスクの要件、そして必要に応じた人によるレビューを組み合わせて判断する必要があります。

ランタイムは各ラウンドの実行が終わるたびに、現在のタスクにまだ進めるべきステップがあるか、外部の待機があるか、ユーザーの確認が必要か、実行の上限にすでに達しているかを確認します。

flowchart TD
    E["現在の実行ラウンドが終了"] --> A{"実行チェックリストは完了したか？"}
    A -->|はい| END["実行を終了し結果の表示または検収へ"]
    A -->|いいえ| B{"タスクが一時停止・ブロック中または上限超過か？"}
    B -->|はい| STOP["自動推進を止めて理由を記録"]
    B -->|いいえ| C{"外部イベントを待機中か？"}
    C -->|はい| WAIT["サスペンドして対応するイベントを待つ"]
    C -->|いいえ| D{"人によるチェックポイントに達したか？"}
    D -->|はい| GATE["確認または選択のカードを表示"]
    D -->|いいえ| F{"実質的な進捗があるか？"}
    F -->|いいえ| LIMIT["自動続行を止めて空回りを防ぐ"]
    F -->|はい| NEXT["次のラウンドの Worker 実行をスケジュール"]
    NEXT --> E

図 9：ランタイムは、モデルが出力を終えたかどうかだけに頼るのではなく、永続化されたタスクの状態にもとづいて実行を続けるかどうかを判断する。

ここで特に注目すべきなのが、実質的な進捗（Meaningful Progress） です。

たとえば、使える創作成果物が新たに増えた、チェックリストのあるステップが完了した、新しい生成ジョブの送信に成功した、といったことは、いずれも実行の進捗を測る目安になります。

しかし、Agent が計画の説明を何度も書き直しているだけだったり、ステップの状態を「未着手」から「進行中」に切り替え続けているだけで、新たな有効な結果を生み出していなかったりする場合は、際限なく続行させるべきではありません。

私たちは進捗のチェックと実行の上限によって、こうした空回りによる推論コストをできるだけ抑えています。

もちろん、この判断にも限界があります。新しい素材が生成されたことは、システムが操作を実行したことの証明にはなっても、素材の品質が基準を満たしていることの直接の証明にはなりません。より完全なマルチモーダルの品質検収は、今後も継続的に探っていくべき方向です。

8.3 Human-in-the-Loop：重要な判断にユーザーを関わらせる

創作の過程で、ユーザーは繰り返しの作業を Agent に任せつつ、重要な創作の方向性については自分でコントロールしたいと考えることがよくあります。

たとえば、ブランドのビジュアルの方向性、キャラクターの設定、絵コンテの案、最終的なカットの選択は、主観的な要素が強いのが普通です。Agent がこうした節目で自ら判断して生成を続けてしまうと、後で無駄なコストが大量に発生しかねません。

そこで私たちは Human-in-the-Loop Checkpoint（人によるチェックポイント） を導入し、ユーザーの関与が必要なフェーズでは自動推進を一時停止するようにしました。

チェックポイントに達すると、Agent は構造化されたカードで現在の案、候補となる結果、推奨する操作を提示できます。ユーザーが「確認して続ける」か「案を調整する」かを直接選ぶと、システムはその明確な操作結果にもとづいてタスクの状態を更新します。

クリックで拡大

この種のインタラクションでは、Claude Code などのプロダクトにおける権限確認の方式も参考にしました。明らかな副作用を伴う操作については、システムが実行内容を事前にユーザーに伝え、続行するかどうかをユーザーが決める、というものです。

ただし創作のシーンでは、人によるチェックは権限だけでなく、美的感覚や創作の方向性にも関わります。ユーザーが Agent に動画の生成をすでに許可していても、カットの設計が終わった段階で自分で案を選びたいと考えることもあります。そのため、チェックポイントは独立した実行状態として保存する必要があり、モデルが返答の中で「確認を待っています」と述べることだけに頼るわけにはいきません。

開発中のリハーサルでも、実際に同様の問題に遭遇しました。Agent はユーザーの確認が必要なフェーズにすでに入っていたのに、「続行してよいか確認してください」と一言返しただけで、直接操作できる確認カードを出さなかったため、ユーザーは改めて「続けて」と入力しなければなりませんでした。

そこで、ランタイムにフォールバックの仕組みを追加しました。タスクがチェックポイントで止まっているのにモデルが対応する質問を出していない場合は、システムが確認カードを自動で補います。また、ユーザーの承認後に実行される生成については、実行チェックリストにまだ完了していないステップがあれば、生成の終了後にタスクを自動で起こします。これにより、確認待ちと実行の再開はモデルのインタラクションの振る舞いに全面的に依存するのではなく、ランタイムがタスクの状態にもとづいて調整するようになりました。

もちろん、チェックがあるからといって、すべてのステップにユーザーの介入が必要なわけではありません。元に戻せない操作や承認の範囲を超える操作については、システムは常に明確な確認を求めます。一方、繰り返しの多い低リスクなステップは承認の範囲内で連続して進められるようにし、確認が多すぎて創作の流れが途切れるのを避けています。

8.4 自律度、予算、承認の境界

AI 創作プラットフォームでは、Agent は異なるモデルベンダーが提供するテキスト、画像、動画、音声、3D などの生成機能を呼び出すことができ、こうした操作には往々にして実際の費用が伴います。そのため、自律度と予算管理は分けて設計する必要があります。

ユーザーが Agent に自動実行を許可したからといって、有料モデルを無制限に呼び出すことに同意したわけではありません。同様に、ユーザーがある予算を承認したからといって、すべての操作でレビューを省略してよいわけでもありません。

ランタイムでは、次の 3 つの軸を別々に管理しています。

たとえば、ユーザーが 3 本の動画の制作を承認し、予算の範囲内で Agent が自動で仕上げることを許可したとします。

実行中に、キャラクターの参考画像を追加で作る必要があると分かった場合、Agent はその操作が元の計画と予算に含まれるかどうかを判断できます。実行範囲を広げたり費用を増やしたりする必要があるなら、改めてユーザーに確認を求めるべきです。

ここには重要なセキュリティ境界があります。モデルが提案した計画も、モデルが「承認されている」と主張することも、それ自体が本物のユーザーの承認になることはありません。

システムは、インターフェース上でのユーザーの明確な操作と、サーバー側に保存された承認状態にもとづいて判断すべきです。

ツールごとに、実際の副作用に応じて異なる制御戦略を採る必要もあります。

• 読み取り専用の照会は、通常リスクが低い

• ドキュメントへの書き込みでは、バージョンと権限を扱う必要がある

• 有料の生成では、予算をチェックする必要がある

• 素材の削除や記憶の取り消しのような元に戻せない操作には、より厳格な確認の仕組みを適用すべきである

コーディング Agent と比べて、創作プラットフォームの Agent には特有の制約もあります。多くの外部生成操作は、いったん送信すると費用がすでに発生している可能性があり、ユーザーがその後タスクを止めても、完全には取り消せないことがあるのです。そのため、予算と承認のチェックは実際に副作用が生じる前に行う必要があり、前述の Durable Execution の仕組みとも組み合わせなければなりません。

これまでの実践から見ると、自律実行の難しさもやはり、いつ止まるべきかの判断にあります。残高不足、ユーザーによる一時停止、外部ジョブの待機、必要な人によるレビュー、あるいは連続して実行しても有効な進捗が得られない場合には、ランタイムが現在の状態を保持し、条件が満たされるのを待ってから再開する必要があります。

これはつまり、自律度は高ければ高いほどよいわけではない、ということでもあります。創作タスクによってリスク、コスト、検証のしやすさには明らかな差があります。Agent はユーザーが承認した範囲内で不要な介入をできるだけ減らしつつ、重要な節目ではユーザーのコントロールを残しておくべきです。

より長期的には、マルチモーダルな品質評価によって、キャラクターの一貫性、カットのつながり、ビジュアルの出来栄えをシステムがより正確に判断できるようにしたいとも考えています。自動検収の能力が少しずつ整っていけば、もともと人の確認が必要だった工程の一部も、Agent に自律的に任せられるようになるはずです。

もちろん、継続的な協働には、タスクの実行とは別の問題もあります。ユーザーは会話を通さず、ワークスペースで作品を直接変更するかもしれません。Agent とユーザーが同じドキュメントやワークフローを同時に編集しているとき、システムは状態の一貫性をどう保てばよいのでしょうか。

そのためには、タスクの実行とは別に、人と Agent が作品に共同でアクセスし編集できる状態を共有ワークスペースが維持する必要があります。

9. Shared Workspace：ユーザーと Agent が同じ作品を編集する

ここまでに取り上げた仕組みは、主に Agent がタスクを理解し、コンテキストを維持し、作業を継続的に進める方法についてのものでした。しかし実際の創作の過程では、ユーザーと Agent の協働はチャットウィンドウの中だけで起きるわけではありません。

たとえば、Agent が絵コンテにもとづいて動画を生成している最中に、ユーザーが右側のワークスペースで、あるカットのプロンプトを直接調整したり、参考素材を差し替えたり、Flows ワークフローのモデルノードを変更したりすることがあります。

こうした操作は会話を経ていませんが、作品を確実に変えています。Agent がそれまでのコンテキストのまま実行を続ければ、古いパラメータを使ってしまったり、ユーザーがたった今行った変更を上書きしてしまったりしかねません。

そこで Lomo Agent では、創作成果物を会話やタスクのコンテキストから独立した永続オブジェクトとして扱い、Shared Workspace（共有ワークスペース） を通じて人と Agent の協働を組み立てています。

9.1 作品に独立したライフサイクルを持たせる

従来の会話型 Agent では、生成結果はたいてい特定のチャットメッセージにぶら下がっています。ユーザーは閲覧したりダウンロードしたり、続けて質問したりできますが、会話が長くなるにつれて、作品の管理やその後の修正はセッションの構造に少しずつ縛られていきます。

一方、Lomo の創作フローには、画像、動画、3D アセット、絵コンテのドキュメント、素材セット、そして Flows ビジュアルワークフローなど、長期的に管理する必要のあるオブジェクトが大量に含まれます。

これらのオブジェクトには、安定した同一性（アイデンティティ）、バージョン、アクセス権限が必要であり、ユーザーが直接編集できると同時に、異なるタスクの間で参照できなければなりません。

そこで私たちは、会話のコンテキストと創作成果物を別々に管理しています。

• 会話とタスクのコンテキストは、ユーザーの意図、実行の過程、そして Agent が現時点で把握している情報を管理します。

• 共有ワークスペースは、継続的に編集・納品する必要のある作品そのものを保存します。オブジェクトの同一性、内容、バージョン、関連する参照もここに含まれます。

たとえば、ユーザーがまず Main でブランドのショートムービーの絵コンテについて話し合い、その後は動画制作のタスクがそれを引き継いで進めるとします。2 つの実行空間は、権限が許す範囲で同じ絵コンテのドキュメントを参照でき、それぞれがコピーを作る必要はありません。

同様に、ある動画生成タスクが終わった後も、その成果物は新しいワークフローから参照できます。元の Worker が動き続けているかどうかには依存しません。

この設計によって、作品は 1 回の会話や 1 つのタスクのライフサイクルを超えて存在できるようになり、その後の素材の再利用や複数タスクでの協働の土台にもなっています。

9.2 ワークスペースでの変化を Agent に気づかせる

共有オブジェクトによって作品をどう保存するかという問題は解決しましたが、もう 1 つ解決すべき問題があります。作品が変更されたことを、Agent はどうやって知るのでしょうか。

Agent がある絵コンテのドキュメントを読み込み、その中のカットの説明にもとづいて生成を続けようとしているとします。ちょうどそのとき、ユーザーがワークスペースで 2 つ目のカットの内容を直接書き換えました。

システムがチャットメッセージしか記録していなければ、Agent は次のラウンドの推論でこの変更を知ることができません。

そこで私たちは、共有オブジェクトごとにバージョン情報を管理し、関連するタスクが前回そのオブジェクトを読み込んだり変更したりしたときに見ていたバージョンを記録しています。

ドキュメント、素材、ワークフローが変化すると、システムは関連するタスクに対して永続化された変更通知を残せます。たとえば次のようなものです。

絵コンテのドキュメントが v3 から v4 に更新され、2 つ目のカットの説明が変わりました。実行を続ける前に最新バージョンを読み込んでください。

ここで私たちは、ワークスペースで編集が行われるたびに即座に Agent の推論を走らせる方式は選びませんでした。

理由はシンプルです。ユーザーがワークフローを調整するときには、ノードを続けてドラッグしたり、パラメータを変えたり、素材を差し替えたりすることがあります。変化のたびに Worker を起こしていたら、無意味なモデル呼び出しが大量に発生するだけでなく、ユーザーがまだ編集を終えていないうちに Agent が何度も割り込んでくることにもなりかねません。

そのため、変更通知は主に、Agent が次に実行するときに自分の情報が古くなっていることに気づくためのものです。関連するタスクを本当に進める必要がある場合にだけ、ランタイムが現在の状態にもとづいて実行を再開するかどうかを判断します。

Flows のようなビジュアルワークフローについても、Agent が毎ラウンドの推論でノードの全データを読み込む必要はありません。システムはまず簡潔な変更情報を渡し、モデルが実際に関連ノードを扱う必要が出てきた時点で、必要に応じて最新の内容を取得します。

この扱い方は、前述のコンテキストエンジニアリングともつながっています。ワークスペースは作品の完全な状態を保存し、コンテキストは現在の判断に必要な情報だけを提供する、という関係です。

9.3 バージョン競合と楽観的並行性制御

変化に気づけるだけでは、並行して行われる変更の安全性は保証できません。

もう少し具体的なシナリオを考えてみましょう。

Agent が絵コンテのドキュメント v3 を読み込み、3 つ目のカットを調整しようとしています。同じころ、ユーザーが同じドキュメントを直接編集し、v4 として保存しました。

その後 Agent が v3 にもとづいて作った変更をそのままコミットすると、ユーザーが v4 でたった今仕上げた内容を上書きしてしまうおそれがあります。

そこで私たちは Optimistic Concurrency Control（楽観的並行性制御） を採用しています。

Agent はオブジェクトを読み込むときに現在のバージョンを取得し、変更をコミットするときには、その前提としたバージョン情報を添える必要があります。サーバー側は書き込みの前に、オブジェクトがまだ想定どおりのバージョンにあるかを確認します。

バージョンが一致していれば変更はそのままコミットできます。オブジェクトがすでに更新されていれば、システムは新しい内容を上書きするおそれのある操作を拒否し、Agent に最新の状態を読み込み直すよう求めます。

ただし、創作オブジェクトの種類によって、バージョン競合を判断する粒度は異なります。

ドキュメントの場合、全体を書き直すときは前提としたバージョンを添える必要があります。ユーザーがすでにドキュメントを変更していれば、システムは上書きを拒否します。部分的な変更は、正確かつ一意なテキスト断片で位置を特定し、想定したすべての置換が成立した場合にのみコミットします。

Flows ワークフローについては、より細かい粒度の競合チェックを採用しています。ユーザーがあるカットのノードを調整している最中に、Agent が別のノードを同時に変更することもあります。ワークフローに少しでも変化があればコミットを拒否するようにすると、頻繁な自動保存のせいで双方が並行して編集するのは難しくなります。そこでシステムは主に、Agent が変更しようとしているノードに変化があったかどうかを確認します。同じノードがユーザーによってすでに変更されていれば Agent に読み込み直しを求め、変化がほかのノードで起きているなら、競合しない変更を最新のワークフローに適用することを認め、関連する変化を Agent に知らせます。

これは同じ内容に対する双方の異なる変更を自動でマージするものではありません。適切なバージョンの粒度によって、互いに競合しない編集はできるだけ独立して完了させつつ、古い状態で新しい内容を上書きすることは防ぐ、というものです。

sequenceDiagram
    participant A as Agent
    participant O as 共有作品
    participant U as ユーザー

    A->>O: 絵コンテのドキュメント v3 を読み込む
    U->>O: 絵コンテを修正し v4 として保存
    O-->>A: バージョン変更通知を記録
    Note over O,A: 変更通知は次の実行時に読み込まれるのを待つ

    A->>O: v3 にもとづいて変更をコミット
    O-->>A: バージョン競合のため上書きを拒否
    A->>O: v4 を読み込み直す
    A->>A: 最新の内容に合わせて変更案を調整
    A->>O: v4 にもとづいて再コミット

図 10：共有作品のバージョン管理。

ここでは、さらに 2 つの仕組みが連携しています。変更通知は Agent が作品の更新にいち早く気づけるようにし、バージョンの検証はコミット時の最後の守りとなります。通知が遅れたとしても、Agent が期限切れの状態でユーザーの変更をそのまま上書きすることはできません。

もちろん、楽観的並行性制御が解決するのは状態の一貫性であり、創作意図の食い違いではありません。たとえば、ユーザーはカットに寒色系のトーンを使いたいのに、Agent は元の計画どおり暖色系を使い続けているとします。バージョン競合が起きていなくても、最終的にどちらの案を採用するかは、最新のユーザーの意図とタスクの制約を合わせて判断する必要があります。

9.4 Artifacts と Canvas から共有の創作空間へ

インタラクション設計では、Claude Artifacts や ChatGPT Canvas といったプロダクトの考え方を参考にしました。

これらのプロダクトは、生成されたコンテンツを普通のチャットメッセージから切り離し、ユーザーが会話の横でドキュメントやコードを直接閲覧・編集できるようにしています。修正の細部を自然言語で何度も説明するコストを減らすためです。

このインタラクションの方式は、Lomo Agent にとって大いに参考になりました。クリエイターは多くの場合、すべての操作を Agent に説明し直すよりも、ノードを 1 つ直接ドラッグしたり、絵コンテの一部を書き換えたり、画像を 1 枚差し替えたりしたいと考えるものです。

ただし、Lomo Agent の共有ワークスペースは、一般的なドキュメント編集とは異なるシーンにも対応する必要があります。

まず、創作オブジェクトの種類がより複雑です。テキストだけでなく、画像、動画、3D アセット、そしてノード間の依存関係を持つ Flows ワークフローも含まれます。さらに、同じ作品が複数のタスクから参照され、非同期の生成ジョブとユーザーによる直接の変更が同時に存在することもあります。システムが管理すべきなのは作品の内容だけでなく、バージョン、関連するタスク、そして実行の過程で作品の状態をどう把握しているかまで含まれます。

そこで私たちは、編集可能なワークスペースと Agent の実行状態とを結びつけ、ユーザーが作品を直接操作できるようにすると同時に、Worker がその後の実行時に有効なオブジェクトの状態を取得し直せるようにしています。

クリックで拡大

これまでの実践から見ると、共有ワークスペースがもたらした重要な変化の 1 つは、ユーザーが自然言語と直接編集という 2 つの方法で同じ創作プロセスに関われるようになったことです。ただしその分、状態の同期や並行性制御についてシステムが負う責任も増えました。特に 1 つの素材が複数のタスクに同時に影響する場合、オブジェクト間の依存関係をどう管理するか、上流が変更された後にどの下流の成果物を再生成する必要があるかは、私たちが引き続き探っている方向です。

10. 創作機能のオーケストレーション：モデル呼び出しから完全な作品の納品へ

Lomote AI のような創作プラットフォームでは、Agent が向き合うのはツールをどう選び、どう呼び出すかだけではありません。異なる創作機能の間の関係も理解する必要があります。

画像を 1 枚生成するのは比較的簡単ですが、完全なショートムービーを 1 本作るには、台本、絵コンテ、キャラクター設定、背景の参考、カットの生成、ポストプロダクションなど、多くの工程が絡んできます。フェーズごとに異なるモデルを使う可能性があり、前のフェーズの結果は後続の制作に直接影響します。さらに重要なのは、個々の生成タスクが成功したからといって、創作フロー全体が無事に完了するとは限らないことです。

たとえば、Agent がある制作案を立てたとします。まずキャラクターと背景を生成し、次に人物を切り抜き、最後に指定した動画の画面に合成する、というものです。プラットフォームが現時点で対応する切り抜きや動画合成の機能を備えていなければ、前段の素材がどれほどうまく生成できていても、案全体として最終的な作品にはなりません。

そのため、Agent には計画の段階で、プラットフォームが実際に備えている機能と、ツールや成果物どうしの依存関係を理解させる必要があります。

10.1 Agent に創作フローと機能の限界を理解させる

Lomote AI はすでに画像・動画・3D の生成モデルや高画質化モデルを数多く統合しており、素材管理や Flows ビジュアルワークフローも提供しています。

これらのツールにはそれぞれ得意なシーンがあり、モデルによって入力条件、生成品質、コスト、出力形式も異なります。

Agent にとってツールを選ぶということは、現在の創作目標、手元にある素材、後続の制作要件を総合的に考えることを意味します。

たとえば、決まったキャラクターが登場するショートムービーを制作する場合、Agent はキャラクターの参考をどう作るか、どのモデルが参考画像の入力に対応しているか、カットをまたいでビジュアルの一貫性をどう保つか、生成結果を後続の制作フローに回せるか、といったことを考える必要があります。ユーザーの最終目標だけを見てそのままモデルを呼び出すと、見栄えはよくても最終作品には使えない中間素材が大量にできてしまいがちです。

そこで私たちは、創作のノウハウとツールの機能上の制約を、必要に応じて読み込めるガイドとしてまとめました。キャラクターの一貫性、絵コンテの計画、参考素材の使い方、ワークフローのオーケストレーション、そしてプラットフォームが現在対応している制作機能などです。これらのガイドは関連するタスクで Agent に提供され、実行可能な創作ステップを計画する助けになります。すべての領域知識をシステム Prompt に常に入れておく必要はありません。

この部分の設計は、前述の Context Engineering とも補い合っています。Agent は現在の制作フェーズに応じて必要なツールと創作の知識を取得し、実際の機能と照らし合わせて計画と実行を行います。

もちろん、モデルがツールの説明を理解することに頼るやり方には限界もあります。モデルは、もっともらしく見えても実際には実現できない制作案を出してくることがあります。そのため、重要なツールの機能、入出力の制約、実行条件については、やはりシステムが明確な検証の根拠を提供する必要があります。

10.2 ViMax に見るマルチエージェントの動画制作

創作機能のオーケストレーションを探る中で、ViMax をはじめとする動画生成向けのマルチエージェントシステムにも注目しました。

ViMax は、台本、キャラクター、絵コンテ、カットの生成、動画の組み立てを 1 つの制作フローの中にまとめ、異なる役割や実行フェーズの協働によって、動画制作における相互に関連したタスクを処理しています。

この考え方は大いに参考になります。動画制作はもともと段階的なものであり、工程ごとに気にかけるべき点も異なります。台本の計画ではストーリーの構造が重視され、キャラクターデザインではビジュアルの一貫性に注意を払う必要があり、カットの生成では具体的なモデルの入力条件と生成結果を考慮しなければなりません。

専門化された実行の分担によって、各フェーズが比較的明確な責務を軸に動けるようになり、複雑な制作フローを組み立てやすくなります。

とはいえ、この種のアーキテクチャにも見極めるべき点があります。マルチエージェントの協働はコンテキストの受け渡し、状態の同期、調整のコストを増やしますし、あらかじめ定義した制作パイプラインが、ユーザーの移り変わる創作ニーズをカバーしきれるとは限りません。

Lomo Agent が向き合うシーンは、よりオープンです。ユーザーはポスターを 1 枚作りたいだけかもしれませんし、既存の素材から動画を生成したいのかもしれませんし、ある Flows ワークフローの修正を Agent に直接頼みたいのかもしれません。あらゆる創作ニーズに固定のマルチエージェントパイプラインを持ち込むと、かえって不要な実行階層を増やすことになりかねません。

そのため現段階では、統一されたタスク実行の仕組みに、オンデマンドで読み込む創作ガイドとツールの機能を組み合わせ、Worker が具体的な目標に応じて制作ステップを組み立てる方式を採っています。長期的に管理する必要のある複雑な創作タスクについては、より明確な専門分担とタスク間の依存管理を段階的に探っていきます。この取捨選択は、前述の Main / Task の設計とも一貫しています。独立した実行空間が実際の利益をもたらす場合にのみ、追加の調整階層を設ける価値がある、という考え方です。

10.3 制作依存グラフ：直線的な実行から依存管理へ

現在、構造化された実行チェックリストによって Agent は創作の進捗を管理できるようになっていますが、相互に関連する素材や生成ステップが大量に絡むタスクでは、直線的なリスト構造にはまだ一定の限界があります。

たとえば、1 本のショートムービーに複数のカットがあり、それらが同じキャラクター設定を共有しながら、異なる背景と生成モデルを使うことがあります。

独立して生成できるカットもあれば、上流の参考素材が出来上がるのを待たなければならないカットもあります。ユーザーが途中でキャラクターの見た目を変えた場合、関連するカットは再生成が必要になるかもしれませんが、まったく無関係な背景には影響すべきではありません。

こうした関係は、Production DAG（制作の有向非巡回グラフ） で表現するほうが適しています。

flowchart LR
    BR["創作の要件"] --> SCRIPT["台本 / 絵コンテ"]

    SCRIPT --> CHAR["キャラクター設定"]
    SCRIPT --> SCENE["背景設定"]

    CHAR --> SHOT1["カット 1"]
    CHAR --> SHOT2["カット 2"]

    SCENE --> SHOT1
    SCENE --> SHOT2

    SHOT1 --> REVIEW["検収と組み立て"]
    SHOT2 --> REVIEW

    REVIEW --> FINAL["最終納品"]

図 11：構想中の制作依存グラフ。

この構造では、各ノードが 1 つの制作ステップまたは中間成果物を表し、ノード間の接続がその依存関係を表します。

これらの関係をさらに構造化すれば、システムはいくつかの機能を実現できる可能性があります。

• 依存関係にもとづくスケジューリング：必要な上流の素材が揃ってから、対応する下流のステップを実行する。

• 並列生成：直接の依存関係がないカットは、リソースと予算が許す範囲で並列に実行できる。

• 変更の伝播：キャラクターや背景の設定が変わったとき、影響を受けうる下流の結果を特定し、手当たり次第に再生成することを避ける。

• 差分制作：まだ有効な素材や生成結果をできるだけ再利用し、重複した呼び出しや不要な制作コストを減らす。

ただし、依存グラフは追加のエンジニアリング上の複雑さももたらします。特に創作タスクにおける依存関係は完全に確定しているとは限らず、ある上流の素材が変わったとき、下流の結果を必ず再生成すべきかどうかは、変更の範囲と具体的な制作要件を合わせて判断する必要があります。

さらに、依存関係が正しくても、生成結果が視覚的に期待どおりになることは保証できません。キャラクターの一貫性、カットのつながり、全体のテンポには、やはり独立した品質評価の仕組みが必要です。

そのため、Production DAG は現時点では、私たちが探っている発展の方向という位置づけです。現段階では、Lomote AI に既存のモデルとツールの機能の範囲内で、Agent が実行可能な創作フローを完了でき、中間成果物のコストと有効性をコントロールできることを優先しています。

タスク間の依存、自動検収、マルチモーダルな理解の能力が少しずつ整っていけば、将来的にはこれらの仕組みを組み合わせ、Agent がステップごとに創作タスクを実行する段階から、制作フロー全体を管理する段階へと進める可能性もあります。そして、こうした設計が本当に有効かどうかを判断するには、1 回のスムーズなデモだけではまったく足りません。複雑な創作タスクでは、ツールの失敗、ユーザーによる変更、状態の復旧、重複した生成といった事態も起こるからです。

これらの設計が有効かどうかは、障害からの復旧と、エンドツーエンドの協働リハーサルを通じて検証する必要があります。

11. エンジニアリング面の検証：障害からの復旧からエンドツーエンドの協働まで

Agent システムには、とても興味深い特徴があります。個々のモジュールが正常に動いていても、協働のプロセス全体が信頼できるとは限らない、という点です。

たとえば、メッセージは対応するタスクに正しくルーティングされ、ツール呼び出しも成功して返ってきたのに、Agent が生成完了後に実行を続けるのを忘れてしまうことがあります。あるいは、各ステップはすべて想定どおりなのに、最終的に重複したドキュメントが何部もできてしまい、ユーザーにはどれが最新版なのか分からなくなる、ということもあります。

こうした問題は、従来の単体テストや数ラウンドの簡単な会話ではなかなか見つかりません。

そこで Lomo Agent の開発では、各モジュールの正しさを検証するだけでなく、実際の利用に近いシーンで Agent にフロー全体を通して実行させ、各仕組みを組み合わせたときの実際の振る舞いを観察するようにしました。

11.1 ランタイムの信頼性の検証

Durable Execution、メッセージ受信箱、非同期生成、ユーザーによる承認といった仕組みでは、多くの問題が特定の状態遷移の過程でしか現れません。

たとえば、次のようなケースです。

• 動画生成のリクエストはすでに送信済みだが、結果を保存する前に Worker が再起動する

• 古い Worker が連絡不能になって新しいプロセスに引き継がれた後、実行を再開する

• ユーザーが停止をクリックしたちょうどそのときに、生成完了イベントが届く

こうした状況は通常のデモではめったに起きませんが、実行状態、ユーザーの作品、さらには実際の費用にまで直接影響しかねません。そこで私たちは開発段階で、フォールトインジェクションテストによって、こうした異常な状況におけるシステムの処理能力を重点的に検証しました。

具体的には、次の重要な実行の境界をテストでカバーしています。

安定して再現できるモデルの出力については、固定の結果をリプレイし、ランタイムの状態遷移を重点的に検証できます。外部の生成サービスについては、タイムアウト、重複したコールバック、順不同のイベントを模擬することで、毎回本物の有料モデルに頼らずに済みます。このテストで重視しているのは、システムの振る舞いの決定性です。モデル自体にある程度のランダム性があっても、タスクの状態、実行権限、課金の制約には、明確で検証可能なルールがあるべきです。

代表的なテストの 1 つは、ツールの実行中に Worker が突然「フリーズ」する状況を模擬するものです。テストではモデルに固定の出力を使わせ、まず照会ツールを 1 つ呼び出すと判断させます。1 つ目の Worker はモデルの意思決定を保存し、ツール呼び出しを started として記録した後、意図的にハングさせられます。そのリースが期限切れになると 2 つ目の Worker が引き継ぎ、実行世代が 2 に上がって checkpoint から再開します。このステップのモデルの意思決定はすでに保存されているので、推論をやり直す必要はなく、同じ冪等キーでツール呼び出しを完了します。最後に 1 つ目の Worker を復帰させ、遅れて届いた結果をコミットさせてみます。

テストの結果は想定どおりでした。ターンは最終的に completed になり、実行世代は 2 でした。モデルの呼び出しは 1 回だけで、ツールの結果も 1 件しかなく、古い Worker による状態の書き込みは拒否されました。ほかにも統合テストで、キューメッセージが失われた後の再配送、承認後の生成タスクの冪等な復旧、キャンセル済みのターンによる新規タスク作成の阻止、費用の承認の制限、記憶の取り消しといったケースをカバーしています。

11.2 エンドツーエンドの協働リハーサル

ランタイムのテストでは、システムが異常な状態を正しく扱えるかどうかは検証できても、Agent の実際の協働体験を完全に反映することはできません。

たとえば、Agent が絵コンテの計画を無事に終えたのに、次のフェーズでそのまま止まってしまい、ユーザーが改めて「続けて」と入力するまで動画の生成を始めない、ということがあります。プログラムの実行という観点ではこれは障害とは言えないかもしれませんが、ユーザーにとっては明らかに自然な流れではありません。

そこで私は、シナリオリハーサルという手法を取り入れてみました。

隔離された環境で、本物のテキストモデルを使い、模擬の生成サービスと、あらかじめ振る舞いを設定した模擬ユーザーを組み合わせて、Agent に比較的まとまった創作フローを最後までこなしてもらいます。

リハーサルのシナリオは、シリーズポスター、ショートムービーの制作、Flows ワークフローの修正、3D の創作、複数タスクの切り替え、過去のタスクの再開、そして記憶の訂正と忘却といったケースをカバーしています。これらのシナリオには、連続するモデルとツールの呼び出しだけでなく、ユーザーによる確認、非同期の待機、タスクをまたいだコンテキストの関連付けも含まれます。

たとえばショートムービー制作のシナリオでは、模擬ユーザーがまず創作の目標を伝え、Agent は絵コンテを組み立て、素材を用意し、生成リクエストを送信する必要があります。実行の途中で、ユーザーは案を調整したり、カットを選んだり、急に別のタスクを差し込んだりします。私たちが観察したいのは、あるステップが成功するかどうかだけではなく、こうした変化の後でも Agent が元の目標に沿って作業を進め続けられるかどうかです。

私が重点的に観察しているのは次の点です。

• Agent が正しい節目で一時停止したり、作業を続けたりしているか

• ユーザーが「続けて」を何度も送らないとタスクが進まない、ということはないか

• 不要な確認や重複した生成が起きていないか

• 新しいメッセージを既存のタスクに正しく関連付けられるか

• ユーザーが作品を変更した後、Agent が最新の状態を取得できているか

• 同じ作品が意図せず複数のコピーに分かれていないか

• 記憶を訂正・取り消した後も、古い情報がその後の協働に影響していないか

本物のメディア生成サービスを直接呼び出すのに比べて、模擬環境ならテストのコストを抑えられますし、特定のシナリオを繰り返し作り出して、モジュールをまたいだやりとりで起こりうる問題を観察するのも簡単です。

ただし、このやり方にもはっきりした限界があります。模擬の生成結果では実際の作品のビジュアル品質は検証できませんし、あらかじめ決めた戦略で動く模擬ユーザーでは、実際の創作における複雑な振る舞いを完全には反映できません。そのため、これらのリハーサルは主にタスクの組み立て、実行状態、協働フローの連続性を確認するためのものであり、実際のユーザーのタスクの成功率をそのまま表すものではありません。最終的な作品の品質と実際の使用体験は、やはり本物の生成結果とユーザーのフィードバックを組み合わせてさらに評価する必要があります。

11.3 1 回の協働の質をどう測るか

こうしたリハーサルを重ねるうちに、モデルの回答が滑らかかどうか、ツール呼び出しが成功したかどうかだけでは、長期間動き続ける Agent を十分に評価するのは難しいと気づくようになりました。

ユーザーがより気にかけているのは、おそらく次のような問題です。

• 何回説明し直さなければならないのか？

• Agent はすでに決まった要件を覚えているか？

• 数日後に、以前の作業の続きを自然に始められるか？

• 自分が作品を変更したとき、Agent は何が起きたのかを把握しているか？

そのため私は、従来の実行の正しさに加えて、タスクの連続性、ユーザーが介入するコスト、繰り返しの操作、成果物の一貫性といった観点にも注目するようになりました。

実際のリハーサルでは、モジュールを個別にテストしているだけでは見つけにくい問題もいくつか明らかになりました。

たとえば、英語のシリーズポスターを制作する過程で、Main はユーザーの要望を正しく理解してタスクを作成したのに、Worker がその後の計画で中国語に切り替わってしまいました。問題はタスクのルーティングではなく、タスクがメインスレッドで整理された目標の記述しか受け取っておらず、ユーザーの元の表現に含まれる言語の情報が欠けていたことにありました。その後、ユーザーの言語の受け渡し方を見直し、タスクが実際のユーザー入力にもとづいて返答の言語を維持できるようにして、モデルがタスクの記述から推測することに全面的に頼らないようにしました。

もう 1 つの問題は、人によるチェックと非同期生成のつなぎ目で起きました。Agent がユーザーの確認が必要なフェーズまで進んだのに、操作できる確認カードを出さなかったり、ユーザーが生成を承認した後、外部のタスクは正常に完了したのにタスクが先に進まなかったりしたのです。こうしたケースに対して、ランタイムに確認カードのフォールバックと生成完了後の自動再開の仕組みを追加し、モデルのインタラクションの振る舞いへの依存を減らしました。

これらの問題は、単独で見ればどれも明らかな実行障害として現れるとは限りませんが、ユーザーが感じる協働の連続性には直接影響します。そしてこの経験から、私はよりはっきりと確信するようになりました。意図の理解とステップの計画はモデルが担い、待機、承認、実行の再開といった重要な状態は、ランタイムが決定的に保証する必要があるということです。

もちろん、これらの観点だけで Agent の知能の水準を示せるわけではありません。創作プラットフォームでは、フローの完了と作品の品質は、やはり別々に評価する必要があります。Agent が計画どおりにすべてのカットを生成できたとしても、最終的な動画がビジュアルのスタイル、キャラクターの一貫性、ストーリーのテンポの面でユーザーの期待に届くとは限りません。より信頼できるマルチモーダルな検収は、今後も磨いていきたい能力です。

これまでの実践から見ると、エンドツーエンドのリハーサルは、比較的コントロールしやすい検証手段を私たちにもたらしてくれました。モジュールをまたいだ協働の問題を見つける助けになるだけでなく、アーキテクチャ設計のいくつかの原則が、完全な実行フローの中で実際に試される機会にもなりました。モデルの能力を単に高めることと同じように、そうした能力を長期的な協働の中で安定してつなぎ合わせる方法にも、継続して力を注ぐ価値があります。

12. まだ解決していない問題と今後の探索

Lomo Agent はすでに、複数タスクの組み立て、Durable Execution、コンテキスト管理、共有ワークスペースといった基本的な能力を備えています。しかし、私が理想とする創作エージェントには、まだまだ探るべき問題がたくさん残っています。

まずはタスク間の協働です。

現在の Router / Worker の構造では、複数のタスクがそれぞれ独立して進み、必要に応じて共有成果物にアクセスできます。しかし、さらに Worker どうしが自ら助けを求めたり、タスクを委任したり、共有予算について調整したりできるようにするなら、権限、状態の同期、並行時の一貫性といった、より複雑な問題を解決しなければなりません。

マルチエージェントの協働は魅力的に見えますが、Agent を増やせば自然と効率が上がるわけではありません。追加の調整コストやコンテキストの受け渡しが、専門分担による利益を打ち消してしまうこともあります。まずは実際のニーズの中から分割する価値のある作業を見つけ、それから協働の範囲を少しずつ広げていきたいと考えています。

次に、創作フローの依存管理です。

前述の Production DAG は、私が特に注目している方向です。複数のカット、キャラクター、背景を含む複雑な制作タスクでは、明示的な依存関係があることで、並列実行、差分更新、結果の再利用を支えやすくなります。

ただし、創作タスクにおける依存関係は常に確定しているわけではありません。ユーザーがキャラクターの設定を 1 つ変えたとき、どのカットを必ず再生成すべきで、どのカットはそのまま使えるのかは、多くの場合、実際の内容と照らし合わせて判断する必要があります。

非同期生成の信頼性にも、まだ改善の余地があります。

現在、上流に送信済みの生成タスクをシステムから能動的にキャンセルすることはまだできません。また、タスクが作成されたのに上流のタスク ID を保存する前に障害が起きた場合、逆引きで照会して関連付けを復旧する手段もありません。

こうしたケースには対応する状態処理と費用のフォールバックの仕組みがすでにありますが、それでも不要な生成コストが発生する可能性があります。今後は上流サービスのキャンセルやタスク照会の機能を少しずつ取り入れ、実行の中断やユーザーによる急な要件変更を、システムがより正確に扱えるようにしたいと考えています。

マルチモーダルな品質検収も、同じく難しい課題です。

現時点では、ツールが成功を返したこと、チェックリストのステップが完了したことは、システムが対応する操作を終えたことの証明にしかなりません。本当の作品の品質には、ビジュアルの一貫性、動きのつながり、音と映像の同期、そしてユーザーの主観的な美意識といった要素も関わってきます。

マルチモーダルモデルの発展に合わせて、こうした評価能力を少しずつ実行フローに取り入れ、いつ調整が必要なのか、いつ再生成する価値があるのか、いつ判断をユーザーに委ねるべきなのかを、Agent がより正確に判断できるようにしたいと考えています。

また、長期記憶の正確さ、タスクルーティングの信頼性、そして自発的なフォローアップの境界も、継続的に検証していく必要があります。

出所の追跡とバージョン管理によって記憶の制御性は高められますが、モデルによる抽出の誤りや、過去の情報の誤った呼び出しを完全に防ぐことはできません。同様に、現在のルーティングの仕組みはタスクのインデックス、履歴の検索、類似タスクの重複チェックを組み合わせて誤判定を減らしていますが、長期間にわたって大量に蓄積されたタスクについては、タスクの関連付けの正確さと、ユーザーが自分で訂正しなければならない頻度を、実際の利用データでさらに測っていく必要があります。

自発的なフォローアップについては、あるタスクにまだ後続の作業があることをシステムが知っていても、ユーザーがいま声をかけられたいと思っているかどうかまでは分からないかもしれません。将来の Agent にはもっと自発的に動いてほしいと考えていますが、その自発性は、ユーザーの承認、タスクの価値、そして実際の利用習慣の上に成り立つものでなければなりません。

これらの問題すべてに、短期間で成熟した解決策が見つかるとは限りません。Lomo Agent がより多くの実際の創作シーンで使われるようになるにつれて、既存のアーキテクチャを繰り返し見直し、どの設計が本当に有効で、どれを調整すべきかを検証していきます。

おわりに

Lomo Agent の最初の構想からリリースまでを振り返ると、Agent の発展によって、ソフトウェアアーキテクチャがとても興味深い新しい問題に向き合うようになっていると、ますます感じます。

これまでソフトウェアを設計するときは、まず明確な機能、フロー、インタラクションの境界を定義し、ユーザーにはそのルールに従って操作してもらうのが普通でした。しかし AI が意図を理解し、ツールを呼び出し、自律的に判断する能力を備えはじめたことで、もともとユーザーが担っていた組み立てや調整の仕事の多くも、少しずつシステムに任せられるようになってきています。

ただ、モデルの能力の向上はその一部にすぎません。

長期的に協働できる Agent には、自分がいま何に取り組んでいるのか、すでに何をしたのか、どの情報がまだ有効なのか、どんなときに続けるべきで、どんなときに止まるべきなのかを知っていることが求められます。現実のシステムで起きる中断、並行処理、費用、権限に対処する必要があり、ユーザーがいつでも気が変わってよいことも許容しなければなりません。

今回の Lomo Agent のアーキテクチャ設計は、まさにこうした問題を軸に進めた 1 つの実践です。その考え方の多くは DeepSeek、Manus、Claude Code、Temporal といった優れたプロダクトやエンジニアリングの実践から得たもので、私自身の創作シーンの中で少しずつ手探りで見つけてきたものもあります。

現在の実装はまだ初期の探索段階にあり、理想の形まではまだ長い道のりがあります。多くの設計も、引き続き実際のユーザーによる検証を受ける必要があります。

それでも私は、モデルの能力が前進し続けるにつれて、ソフトウェアと人とのインタラクションのあり方には、まだ大きな可能性が広がっていると常に感じています。

いつの日か、私たちはソフトウェアの使い方を学ぶ必要がなくなり、ただ何を成し遂げたいかを伝えるだけでよくなるのかもしれません。

それこそが、Lomo Agent が少しずつ近づいていきたいと願っている方向です。

もしあなたも Agent を開発しているなら、アーキテクチャ設計やエンジニアリング実践での経験や課題について、ぜひ意見を交わしましょう。

もしあなたがクリエイターなら、実際の創作のニーズを携えて、ぜひ Lomo Agent を試してみてください。

Lomo Agent を試す： lomo agent

クリックで拡大

クリックで拡大

参考資料とさらに読む

以下のリンクは主にアーキテクチャ上のヒントや研究の背景を示すためのものであり、各プロジェクトがあらゆる機能において Lomo Agent と同じ実装や設計目標を持っていることを意味するものではありません。

1. DeepSeek Super-agent Prototype

2. Temporal — Design Patterns

3. OpenAI — Using Goals in Codex

4. Anthropic — Effective Harnesses for Long-Running Agents

5. Claude Code — Hooks

6. Anthropic — How We Built Our Multi-Agent Research System

7. Manus — Context Engineering for AI Agents

8. Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory

9. Zep / Graphiti: A Temporal Knowledge Graph Architecture

10. LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory

11. OpenClaw — Memory Architecture

12. ViMax — Multi-Agent Video Generation

注：本文では「既存の仕組み」と「今後の発展の方向」をできるかぎり区別して記しています。外部サービスの冪等性の保証、「忘れる」がカバーするデータの範囲、モデルのキャッシュの挙動、自動検収の効果については、いずれも実際の能力が具体的な実装と依存する条件に左右されます。