ハイブリッドAIエージェントが求める「速度」と「制御」の両立

LLMを活用したAIエージェントの実装において、技術責任者が直面する最も厄介なトレードオフは「レイテンシー」と「制御」の両立である。ユーザーがプロンプトを入力してから応答が返ってくるまでの体感時間は、LLM推論の計算時間とネットワーク往復時間（RTT）の合計で決まる。特に対話型エージェントでは、この応答時間が1秒単位で体感品質が大きく変わるため、推論処理をどこで実行するかが設計の核心となる。

一方、制御の観点では、機密データへのアクセス権限管理、監査ログの保全、ビジネスロジックのバージョン管理、コンプライアンス要件の対応など、既存のAWS基盤やオンプレミス環境で確立されたガバナンスを維持する必要がある。すべての推論処理をエッジに移行すればレイテンシーは最小化されるが、データが外部ネットワークを通過するリスクと、既存のアクセス制御基盤との整合性を失う問題が生じる。

このジレンマを解くアプローチとして、処理の性質に応じて実行環境を分ける「ホットパス/コールドパス」の設計パターンが有効である。ホットパスとは、ユーザーとの直接対話に関わる低レイテンシー処理（応答生成、エンティティ抽出、要約など）をエッジに近い環境で実行する層であり、コールドパスとは、機密データや複雑なビジネスロジックを既存基盤で処理する層である。

Cloudflare Workers AIは、グローバルに分散したエッジロケーションでLLM推論を実行できるサーバーレス環境を提供する。この特性により、ユーザーの地理的位置に近いロケーションで推論が行われ、RTTを大幅に短縮できる可能性がある。一方で、Workers AIは状態を持たない（stateless）ため、長期記憶やトランザクション管理は別途の基盤に委譲する設計が必要になる。本記事では、この2つの層をどう連携させるかという具体的なアーキテクチャパターンを、実在するエッジネイティブなエージェント実装の構造を参考にしながら解説する。

Talorysから学ぶ：エッジネイティブなエージェントの構造

ホットパス/コールドパスの設計パターンを理解するために、まずエッジネイティブなエージェントの具体的な実装構造を見てみよう。Talorysは、チャット・メモリ・タスク管理を備えたオープンソースの個人用AIアシスタントであり、Cloudflareアカウント内で完全に動作する設計となっている。このプロジェクトは、エッジ環境でAIエージェントを構築する際の最小構成と設計思想を学ぶ上で有用な参照例である。

Talorysのアーキテクチャは3層から構成される。フロントエンドはCloudflare Pagesで配信され、バックエンドのビジネスロジックはPrivate Workerが担う。データ永続化層にはDurable Objectsが採用されており、その内部でSQLiteが使用されている。AI推論にはWorkers AIの@cf/zai-org/glm-4.7-flashモデルが利用される。この構成により、フロントエンドから推論エンジンまでが同一のCloudflareプラットフォーム内に収まり、外部への依存が最小限に抑えられている。

特に設計上の注目点は、データ層の単一化である。会話履歴、メモリ、タスク、ノート、プロジェクト、設定といったすべてのデータが、ユーザーのCloudflareアカウント内の単一のSQLite-backed Durable Objectに保存される。Durable ObjectsはCloudflareが提供するグローバルに分散した状態管理プリミティブであり、同一のオブジェクトへの並行リクエストが単一インスタンスにシリアル化されることで、データ競合を回避する。SQLiteとの組み合わせにより、複雑なSQLクエリやトランザクションがエッジロケーション内で実行可能になる。

デプロイはnpx create-talorys@latestの1コマンドで完了し、Cloudflareの無料プランで動作する。この低コストな検証環境は、PoC段階でエッジ推論のレイテンシー特性を体感する上で実用的である。ただし、Talorysは単一ユーザー向けに設計されており、サインアップやアカウント作成は不要で、インストール時に設定された所有者パスワードのみでアクセスする方式である。この制約は後述するマルチテナント環境への適用時に考慮する必要がある。

flowchart TD
    A["ユーザー"] --> B["Cloudflare Pages"]
    B --> C["Private Worker"]
    C --> D["Workers AI"]
    C --> E["Durable Objects"]
    E --> F["SQLite"]

このデータフローから読み取れるのは、エッジネイティブなエージェントでは「状態の所在」が設計の核心になるということである。Durable Objectsが状態を保持することで、Workers AIのstatelessな推論結果と整合性のある対話を実現している。この構造をそのまま企業環境に適用するのではなく、どの層をホットパスに置き、どの層をコールドパスに残すかを判断する材料として活用する。

ホットパス設計：Workers AIの低レイテンシー推論環境

ホットパスに委譲する処理の要件は明確である。第一に「速さ」、すなわちユーザーが体感する応答時間を最小化すること。第二に「スケーラビリティ」、すなわち同時接続数が増加しても応答品質を維持できること。第三に「コスト効率」、すなわち常時リソースを確保するのではなく、リクエスト発生時にのみ計算資源を消費すること。Workers AIのサーバーレス推論環境は、この3要件を同時に満たす選択肢の一つである。

Workers AIで利用可能なモデルは、用途に応じて選択できる。Talorysでは@cf/zai-org/glm-4.7-flashという軽量かつ高速なモデルが採用されている。このモデルは、対話の文脈理解や簡易的な情報抽出に十分であり、エッジロケーションでの推論により、ユーザーからのリクエスト到着から推論完了までの時間を短縮できる可能性がある。モデルの選択は「推論品質」と「推論速度」のトレードオフであり、ホットパスでは後者を優先するのが一般的である。より高精度な推論が必要な場合はコールドパス側で処理する設計にする。

レイテンシーの観点では、Workers AIの推論はCloudflareのエッジネットワーク内で完結するため、従来の「クライアント → 専用推論サーバ（リージョン単位）→ クライアント」の往復に比べ、物理的な距離要因が大幅に縮小される。ただし、モデルサイズやバッチ処理の有無によって推論時間は変動するため、プロダクション環境では実際のP95レイテンシーを計測し、SLAとの整合性を確認する必要がある。

運用上の重要な制約として、Workers AIの無料枠（Neuron割り当て）が存在する。この割り当てを使い切ると、Talorysのケースではチャット機能が停止するが、タスク管理やメモ機能は継続して使用可能である。この挙動は、ホットパスのコスト特性を理解する上で示唆的である。LLM推論は計算資源の消費が他の処理と桁違いに大きく、無料枠の上限に到達しやすい。プロダクション利用を想定する場合は、Workers AIの課金プランの料金体系を確認し、月間の推論呼び出し回数とNeuron消費量の推定を行うことが不可欠である。PoC段階では無料枠で十分検証できるが、本番移行時のコスト見積もりは設計初期段階で行うべきである。

コールドパス設計：既存AWS基盤との連携とデータ管理

ホットパスが「速さ」を担うのに対し、コールドパスは「制御」と「データ保護」の役割を担う。機密情報を含むビジネスロジック、規制対象のデータ処理、長期記憶に基づく複雑な推論は、既存のAWS基盤（EC2、EKS、Lambda）またはオンプレミス環境に留めるのが基本方針である。

この設計判断の根拠は、データ主権とコンプライアンス要件にある。金融・医療・製造業などでは、特定リージョンへのデータ保管が法的に義務付けられている場合があり、グローバルなエッジネットワーク上でデータを展開するWorkers AIに委譲するわけにはいかない。コールドパスに留めることで、既存のIAMポリシー、VPC内のネットワーク分離、監査ログの仕組みをそのまま活用できる。新規にセキュリティ基盤を構築する必要がないため、導入コストとリスクが大幅に抑えられる。

データ同期の方針として、ホットパスで生成された中間結果（エンティティ抽出の結果、要約テキスト、分類ラベルなど）はコールドパスのAPIに非同期で転送し永続化する。逆に、コールドパスの長期メモリやビジネスルールは、ホットパスが必要なタイミングで引き出す形にする。この非同期設計により、ホットパスの応答時間をコールドパスの可用性に依存させない。コールドパスがメンテナンス中でも、ホットパスはキャッシュされたコンテキストで最低限の応答を継続できる。

Talorysの設計思想には、この点で参考になる要素がある。Talorysはテレメトリやトラッキングコードを一切含んでおらず、開発者へデータを一切送信しない構造になっている。企業内でAIエージェントを運用する場合、サードパーティへのデータ漏洩リスクが最小限であることは、セキュリティ審査を通過するための重要な要件となる。

バックアップとデータ移行の観点では、Talorysは「talorys-backup.json」という形式で会話、メモリ、タスク、ノート、プロジェクト、設定をエクスポートする。ただし、セッション情報や認証情報は含まれないため、このファイルを単体で移行しても認証状態は復元できない。ハイブリッド構成では、エッジ側の状態とコールドパス側の状態を別々にバックアップし、両者の整合性を保つための同期メカニズムを別途設計する必要がある。

項目ホットパス（Cloudflare）コールドパス（AWS/オンプレ）
役割低レイテンシー推論、初期処理複雑なロジック、データ永続化
データフローユーザー入力の即時応答中間結果の非同期転送、長期記憶
コスト特性無料枠でPoC可能、推論量に応じて課金既存インフラの固定コスト中心
データ保護転送中暗号化、PIIマスキングIAM、VPC分離、監査ログ

状態管理のトレードオフ：Durable Objects vs RDS

Talorysが採用するDurable Objects（SQLiteバックエンド）は、単一ユーザー向けに設計されている。サインアップやアカウント作成は不要で、インストール時に設定した所有者パスワードのみでアクセスする。この設計は、データの一貫性と低レイテンシーを最優先しており、スケーラビリティよりもシンプルさを重視している。

このアプローチが有効な場面は明確である。個人用アシスタントや、少数のユーザーに対して高頻度で状態を読み書きするケースでは、単一のDurable ObjectにSQLiteを置けば、ネットワーク往復なしにトランザクションが完結する。RDSへの接続プールの管理や、ネットワークレイテンシーの考慮が不要になるため、実装の複雑さが大きく下がる。また、Durable Objectsは同一ユーザーのリクエストを単一インスタンスにルーティングするため、ロックの競合が発生しにくい。

一方、以下のような要件がある場合は、状態管理をコールドパス側に移行すべきである。マルチテナント環境でユーザーごとにデータ分離が必要な場合、複数テーブルにまたがる複雑なトランザクションが必要な場合、既存のRDSやDynamoDBに業務データが既に存在し参照統合が必要な場合である。これらの要件をDurable Objectsで満たそうとすると、単一インスタンスのストレージ上限や処理能力の制約にすぐさまぶつかる。

ハイブリッド構成における設計原則は、「エッジ側の状態はキャッシュ的に扱う」である。具体的には、ホットパスのDurable Objectsに保持するデータは「セッション一時保存」または「頻繁に参照するキャッシュ」として位置づけ、真のソース・オブ・トゥルースをAWS側（RDSやDynamoDB）に置く。エッジ側のデータが失われた場合でも、コールドパスから再構築できることが設計上の不変条件になる。

この選択のメリットは、Cloudflareの無料枠や低コスト枠を有効活用しつつ、既存インフラへの投資を活かせる点にある。Durable Objectsのストレージには上限があるため、大規模なデータセットをエッジに置こうとするとすぐに制約にぶつかる。ソース・オブ・トゥルースをAWSに置くことで、エッジ側のストレージ制限を「キャッシュサイズの問題」に矮小化でき、コスト管理が直感的になる。

実装パターン：Hot/Coldパス間のコンテキスト同期

ホットパスとコールドパスの連携で最も重要なのは、コンテキストの境界を明確に定義することである。ユーザー入力がホットパスに到達した時点で、Workers AIで初期処理（エンティティ抽出、意図分類、要約生成など）を実行する。この段階で必要なコンテキストが十分に揃っている場合は、ホットパス内で完結させる。逆に、ユーザーの過去の業務履歴に基づく個別判断、規制対象データの参照、複数システムにまたがるトランザクションの検証などは、コールドパスへの参照が必要になる場合がある。

通信のオーバーヘッドを抑えるため、ペイロードの設計が重要になる。gRPCを使うことで、プロトコルバッファのコンパクトなバイナリ形式を活用できる。JSONでも構わないが、送信するフィールドを最小限に絞り、不要なネスト構造を避ける。特に、コールドパスから返すデータは「ホットパスの処理に必要な最小限のコンテキスト」に限定し、生データ全体を転送しない設計にするとよい。これにより、ネットワーク帯域とパース処理の両面でコストを抑えられる可能性がある。

エラーハンドリングの設計では、コールドパスの応答遅延や障害時にどう振る舞うかが重要になる。推奨されるアプローチの一つとして、タイムアウト（例：2〜3秒）を設定し、期限を超えた場合はフォールバック処理に切り替えることが考えられる。フォールバックとしては、ホットパス内で実行可能なローカルルールベースの判定や、より軽量なモデルによる簡易推論が挙げられる。完全な精度は得られなくても、ユーザーに対して応答を返すことで体験の断絶を避けることができる。フォールバック発生時は、監査ログに記録し、後からコールドパス側で補完処理を行う設計も検討できる。

sequenceDiagram
    participant U as ユーザー
    participant HP as ホットパス(Workers)
    participant WAI as Workers AI
    participant CP as コールドパス(AWS)
    U->>HP: リクエスト
    HP->>WAI: 初期処理(抽出・分類)
    WAI-->>HP: 中間結果
    alt コンテキスト不足
        HP->>CP: 追加情報取得
        CP-->>HP: 詳細データ
    end
    HP->>WAI: 最終推論
    WAI-->>HP: 応答テキスト
    HP-->>U: レスポンス

セキュリティとプライバシー：エッジ環境の特性を理解する

エッジ環境でAIエージェントを動かす際、最も重視すべきは「どこにどのデータが残るか」という点である。Talorysはテレメトリ・分析・トラッキング・広告コードを一切含まず、開発者へデータを送信しない設計となっているとされる。この構造は、機密性の高い個人情報を扱う場合でも心理的抵抗を下げ、企業内のセキュリティレビューを通りやすくする一因になる可能性がある。

Hot PathとCold Pathの境界でのデータ管理

しかし、ハイブリッド構成では事情が異なる。ユーザーの入力データがHot Path（Cloudflareエッジ）で処理され、必要に応じてCold Path（AWS）へ渡されるため、両者の境界を跨ぐ転送が発生する。この転送経路でデータが平文で流れると、エッジノードの物理的所在がグローバルに分散している特性上、データの管轄地域が想定と異なる可能性が生じる。GDPRや個人情報保護法への対応を考慮する場合は、どのデータがどのパスで処理されるかを事前にマッピングし、機密データをHot Pathに渡さない設計判断が必要になる場合がある。

具体的な対策として、Hot Path側でPII（個人識別情報）のフィルタリングやマスキングを行うレイヤーを設けるのが有効だ。例えば、ユーザー入力がWorkers AIに到達する前に、名前やメールアドレスなどのパターンを正規表現で検出し、仮名置換する処理をWorker内で行う。これにより、推論エンジンに渡されるプロンプトから識別可能な情報が除去され、エッジノード上で残るログにも機密データが含まれなくなる可能性がある。

認証方式の段階的導入

Talorysは単一ユーザー向けに設計されており、サインアップやアカウント作成は不要で、インストール時に設定された所有者パスワードのみでアクセスする方式を採用しているとされる。この簡易な認証は、個人のPoCや社内検証環境では十分である。ただし、本番環境で複数ユーザーが利用する場合は、エッジ側のアクセス制御としてAPIキーやJWTの検証をWorker内で実装し、Cold Path側ではOAuth 2.0やSAMLなどの標準プロトコルで本格的なアイデンティティ管理を行う二層構成が望ましい。エッジ側は「第一関門」として不正アクセスを遮断し、Cold Path側で権限の粒度を制御する役割分担となる。

運用と拡張：無料枠からプロダクションへの移行

Cloudflare Workers AIの無料枠（Neuron割り当て）は、PoCや個人利用段階でコストゼロで検証を進める上で有用である。ただし、Neuron割り当てを使い切るとチャット功能是停止する一方、タスク管理やメモなどの他の機能は継続して使用可能であるとされる。この特性を踏まえると、無料枠段階で「推論が止まってもシステム全体が停止しない」フォールバック設計を最初から組み込むことで、課金プランへの移行判断を急かされずに済む可能性がある。

監視と容量計画

本番環境への移行時に確認すべき運用指標は、主に以下の3点である。第一に、Workers AIのレートリミットとNeuron消費量。推論モデルのサイズやバッチ処理の有無によって消費量が大きく変わるため、ピーク時の消費を計測し、課金プランの割当が十分かを算出する必要がある。第二に、Durable Objectsのストレージ使用量。SQLiteベースのDurable Objectsにはストレージ上限が設定されており、会話履歴やメモリが蓄積されるにつれて上限に接近する。第三に、Hot PathとCold Path間のAPI呼び出し回数と応答時間。境界を跨ぐ通信が増えるとレイテンシーが悪化する可能性があるため、この数値の推移をダッシュボードで常時監視する。

ストレージ上限に接近した際の拡張戦略として、Durable Objects上のデータを定期的にCold Path側のRDSやDynamoDBへエクスポートし、エッジ側は「直近N日分のセッションキャッシュ」として扱う方式が現実的である。これにより、エッジ側のストレージを一定量に抑えつつ、履歴の完全な保持はAWS側で担保できる可能性がある。

バックアップ戦略の二層構成

Talorysのバックアップ機能は、会話・メモリ・タスク・ノート・プロジェクト・設定を含む「talorys-backup.json」形式でエクスポート可能であるとされるが、セッション情報や認証情報は含まれないとされている。この形式はデータの論理的なスナップショットとしては有効だが、認証状態の復元には別途対応が必要である。本番環境では、このエッジ側のバックアップに加え、Cold Path側のデータレイク（S3やRedshiftなど）へ定期的な同期を行う二層構成を採用すると、エッジ側の障害とCold Path側の障害の双方に耐性を持つ可能性がある。

設計判断のまとめ：なぜハイブリッドなのか

AIエージェント基盤の技術選定において、「どこに何を置くか」の境界設計がシステム全体の品質を左右する。完全なクラウド依存構成は、推論コストがトラフィックに比例して増加し、ベンダーロックインのリスクも高まる可能性がある。一方、完全なオンプレミス構成は、初期投資の大きさやスケーラビリティの限界という課題を抱える。どちらか一方に偏ると、コストとパフォーマンスのトレードオフで不利な位置に立たされやすい。

ハイブリッド設計が有効な理由

Cloudflare Workers AIをHot Pathに組み込むハイブリッド設計は、この両方の課題を同時に緩和する可能性がある。エッジ側では、推論の単位コストが低く、グローバルに分散したノードからユーザーに近接して応答できるため、レイテンシーとコストの両面で有利である場合がある。一方、複雑なトランザクション処理や機密データへのアクセス制御は、既存のAWS基盤（IAM、KMS、VPC構成など）が既に提供している制御機構をそのまま活用できる。つまり、新規に構築するコストはHot PathのWorkerとWorkers AIの呼び出しに集中し、既存投資を活かせる範囲を最大限に保てる可能性がある。

境界を定義する判断基準

Hot PathとCold Pathの境界をどこに引くかは、以下の3軸で評価するのが実用的である。第一に、データの機密性。機密データを含む処理はCold Pathに固定する。第二に、レイテンシー要件。ユーザーが応答を待っている処理（入力補完、即時応答など）はHot Pathに置く。第三に、既存インフラの投資。既に運用しているRDSやLambdaの処理をHot Pathに移動するメリットが薄い場合は、Cold Pathに残す。この3軸を各機能ごとに評価し、境界を文書化することで、チーム内での設計判断の基準が揃い、後の機能追加時の判断コストも下がる可能性がある。

まとめ：次世代AIエージェント基盤への第一歩

本記事では、Cloudflare Workers AIをHot Pathとして活用し、既存のAWS基盤とCold Pathとして組み合わせるハイブリッドAIエージェントの設計パターンを、Talorysのアーキテクチャを参照系として解説してきた。

Talorysが示すエッジネイティブな構造——Cloudflare Pagesによるフロントエンド、Private Workerによるバックエンド、Durable Objects（SQLite）による状態管理——は、単一の個人用アシスタントとして完結しているが、その設計思想は企業規模のシステムにも適用可能である。特に、単一のDurable Objectに状態を集中させる一貫性優先の設計と、無料枠での段階的な検証が可能である点は、既存のAWS基盤を前提とするチームがエッジ推論を導入する際の足がかりになる可能性がある。

Hot Pathによる低レイテンシーなユーザー体験と、Cold Pathによる堅牢なデータ管理・コスト制御の両立は、単なる技術的な最適化にとどまらない。レイテンシーがユーザーの継続利用を左右するAIエージェントでは、この両立がビジネスの成否に影響を与える可能性がある。技術責任者としては、自社のデータ機密性・レイテンシー要件・既存インフラの投資状況を総合的に評価し、Hot PathとCold Pathの境界を明確に定義することから、次の一手を始められるだろう。

関連記事

参考

本記事は海外の技術トレンド「Talorys – A self-hosted personal AI agent on Cloudflare's free tier」（Hacker News）で話題のテーマをもとに、両儀システムソリューションズが独自に解説したものです。

記事一覧に戻る