会話型AIエージェントの内部アーキテクチャ

会話型AIエージェントの内部動作（OpenClawアーキテクチャ）

会話型AIエージェントはどのように動作するのか、実際にターンごとに見ていきましょう。この記事ではOpenClawのブラックボックスを開きます：顧客のメッセージがWhatsAppに届いた瞬間から、エージェントが返信テキストを書くまでの流れです。技術的な内容になります。プロダクトアーキテクチャの意思決定をする方、ソリューションの購入を検討していて中身を評価したい方、あるいは会話の裏側で何が起きているか知りたい方にとって、読む価値があります。

TL;DR: 各ターンは6つのステージを通過します — 取り込み、コンテキスト解決、スキル選択、次のアクション決定、ガードレール付き実行、メモリ永続化。サイクル全体はCloudflareのエッジで2秒未満で実行され、固定サーバーは不要です。

---

なぜアーキテクチャが重要なのか

デモではうまく動くように見えるが本番環境で壊れる会話エージェントには、通常以下の4つの問題のいずれかがあります：

1. 高レイテンシ — 顧客が応答を8秒待つと、会話は途切れる。
2. 制御されないハルシネーション — エージェントが価格、営業時間、ポリシーを捏造する。
3. コンテキストの喪失 — 顧客が2日後に戻ってきたとき、エージェントがすべてを「忘れている」。
4. 制御不能なコスト — 長い会話のたびにプロンプトが膨れ上がり、トークンに莫大な費用がかかる。

4つともモデルの制限ではなく、アーキテクチャの選択の問題です。OpenClawはこの4つすべてを回避するために構築されました — それを理解する道筋は、1ターンのサイクルを見ることです。

---

1ターンのサイクル（6ステージ）

顧客が "土曜の午前に予約したい" というメッセージを送ったとしましょう。「受信」からエージェントの応答までの間に何が起きるのでしょうか？

ステージ1 — 取り込み（エッジワーカー、<50ms）

WhatsAppからのメッセージは、MetaのWebhookを経由して、地理的に最も近いポイントオブプレゼンス（PoP）にあるCloudflare Workerに直接到達します。ブラジルの場合、これはサンパウロまたはリオを意味し、ネットワークレイテンシは20ms未満です。

ワーカーは3つのことを行います：

1. Webhookの署名を検証します（WABAシークレットに対するHMAC）。
2. 受信者の電話番号でテナントを識別します（to_numberによるマルチテナント）。
3. ペイロードを正規化します — 音声は文字起こしに、画像は説明に、位置情報は{lat,lng}に変換され、テキストはそのまま残ります。

ステージ1の終了時点で、次のステップに進む準備ができた{tenant_id, conversation_id, user_message}オブジェクトが得られます。

ステージ2 — コンテキスト解決（D1 + KV、〜80ms）

エージェントは判断を下す前に3つのコンテキスト要素を必要とします：

• 直近の会話履歴（最新のN件の関連ターン）。
• 顧客の長期記憶（好み、購入履歴、メモ）。
• エージェントの状態（ペルソナ、有効なスキル、ルール）。

すべてD1（CloudflareのSQLite分散型データベース）から取得されます。D1は従来のPostgres/Mongoを置き換えます — 維持すべきデータベースサーバーなし、workerから数msでアクセス可能、tenant_idによるマルチテナント対応。

重要なポイント: 私たちは会話全体をプロンプトに読み込みません。OpenClawのMemory Manager v2（内部ドキュメントに記載）は、現在のターンに関連するターンのみを選択します（直近N件 + 意味的関連性の高いN件）。これにより、100ターン以上の会話でもトークンコストを予測可能に保ちます。

ステージ3 — スキル選択（ポリシーエンジン、約20ms）

各エージェントには利用可能なスキルのセットがあります — 呼び出し可能な関数です。例：consultar_calendario、criar_evento、gerar_link_pagamento、consultar_pedido、chamar_humano。

メッセージ"quero marcar pra sábado de manhã"（土曜の午前に予約したい）が与えられた場合、ポリシーエンジンは以下をフィルタリングします：

• 検出された意図（予約）と互換性のあるスキル。
• この会話フェーズで許可されているスキル（すべてのスキルが常に利用可能なわけではありません）。
• このテナントが有効にしたスキル（カレンダーはテナントが統合した場合のみ表示されます）。

最終的に、モデルに渡されるのはスキルの小さなサブセットです — 50個の候補すべてではなく、ここで意味のある4つだけです。これにより、モデルが誤ったスキルを呼び出す可能性が大幅に減少します。

ステージ4 — 判断（LLM呼び出し、400-1200ms）

ここでモデルが登場します。OpenClawはフロンティアLLM（Anthropic Claude、OpenAI GPT、Google Gemini — テナントごとに設定可能）に対して単一の呼び出しを行います。内容は：

• システムプロンプト = エージェントのペルソナ + ルール + 利用可能なスキル。
• 履歴 = ステージ2で選択されたターン。
• ユーザーメッセージ = 現在のターンのメッセージ。

モデルは2つのうちいずれかを返します：

• 最終応答（クライアントへの直接テキスト）。
• ツール呼び出し（特定のスキルをパラメータ付きで実行するリクエスト）。

"quero marcar pra sábado de manhã"の例では、モデルは通常以下を返します：

{
  "tool": "consultar_calendario",
  "args": { "date_range": "2026-04-19 06:00 to 12:00" }
}

ステージ5 — ガードレール付き実行（可変、約100-500ms）

スキルはモデル内で実行されません。私たちのコード内で実行され、以下を行います：

1. パラメータを検証（date_rangeのフォーマットは正しいか？テナントのルール内か？）。
2. 権限をチェック（このエージェントはこのカレンダーを参照する権限があるか？）。
3. 呼び出しを実行（この場合はGoogle Calendar API）。
4. 構造化された結果をモデルに返す。

なぜこれが重要なのか？それはモデルが結果を捏造することが決してないからです。カレンダーが[10h, 11h]を返せば、次の呼び出しに渡されるのはまさにその情報です。スキルが失敗すれば、モデルは失敗したことを認識します。エージェントが実際には空いていない9時に「空きがある」と「でっち上げる」リスクはゼロです。

機密情報（価格、納期、顧客名）を含むケースでは、パイプラインがtool callを強制します — モデル自身の「知識」から回答させません。これにより、商用エージェントで最も一般的なハルシネーションのクラスを排除できます。

ステージ6 — レスポンスと永続化（約50ms）

スキルの結果を手にしたモデルは、2回目の呼び出しを行います — 今度はクライアントへの最終レスポンスを生成するためです。例：

"土曜日の10時と11時が空いています。どちらがよろしいですか？"

並行して、workerは以下を実行します：

1. WhatsApp APIを通じてメッセージを送信。
2. 完全なターン（user + assistant + tool calls + 所要時間）をD1に永続化。
3. ターンが新しい事実を生成した場合（例：「顧客は土曜日を希望」）、長期メモリを更新。
4. オブザーバビリティイベントを発行（レイテンシメトリクス、トークンコスト、エスカレーション率）。

これらはすべて並列で実行されます。永続化はメッセージ送信をブロックしません — クライアントはD1を待ちません。

---

ハルシネーションに対する防御の所在

本番環境でハルシネーションを起こすエージェントは、すぐに信頼を失います。OpenClawには4つの防御ラインがあります：

1. 信頼できる情報源の強制。 事実データ（価格、時間、名前）は常にスキルから取得され、モデル単独からは決して取得されません。
2. 機密データの二重確認。 予約は永続化前にクライアントに確認されます。支払いはアクセス許可前に確認されます。
3. 明示的なネガティブルール。 各エージェントのペルソナには「X、Y、Zを決して捏造しない」が含まれており、モデルはそれに従います。
4. 人間へのフォールバック。 どのスキルも質問をカバーできない場合、エージェントは"チームに確認させてください"と言ってチケットを作成します — 推測はしません。

過去6ヶ月間に実施した監査（手動でレビューした実際の会話）では、事実に関するハルシネーション率はターンの0.3%未満にとどまりました — そしてほぼすべてのケースは設定ミス（テナントが関連スキルの有効化を忘れた）によるもので、モデルのエラーではありませんでした。

---

会話あたりのコスト

良いアーキテクチャは請求書を見るまで目に見えません。各ターンが1-2回のLLM呼び出し + D1ルックアップを行うことを考えると、完全な会話（10-15ターン）あたりの一般的なコストは以下の通りです：