コンバーチャルなAIエージェントの内部作動機

OpenClawの内部構造: AgenteのIAの6つのステージ

AgenteのIAの内部構造は、どのように機能するのでしょうか? この記事では、OpenClawの内部構造を解説します。WhatsAppから受信したメッセージから、返信するテキストまでのプロセスを、技術的な詳細で説明します。

TL;DR: 各ターンは6つのステージを通過します: インジェスト、コンテキスト解決、スキル選択、次のアクション決定、実行、メモリの保存。すべてのサイクルは、Cloudflareのエッジで、固定サーバーなしで、<秒で実行されます。

---

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

デモで機能するように見えるが、実際にはプロダクションで機能しないアーキテクチャは、4つの問題を抱えています。

1. 高遅延 — クライアントは8秒間待っていますが、会話は死にます。
2. 非制御の妄想 — アーケードは価格、時間、ポリシーを想像します。
3. コンテキストの喪失 — クライアントは2日後に戻り、しかし、アーケードは「すべてを忘れて」います。
4. コストの制御 — 長い会話は、トークンを大量に消費し、費用が高くなります。

4つはアーキテクチャの選択であり、モデル制限ではありません。OpenClawは、4つの問題を回避するために設計されています。理解するには、ターンのサイクルを観察する必要があります。

---

ターンのサイクル (6ステージ)

クライアントが「土曜日の朝に予約したい」というメッセージを送信したとします。ターンのサイクルは、受信から返信までのプロセスを表します。

ステージ1: インジェスト (エッジワーカー、<ms)

WhatsAppのWebhookからメッセージがCloudflare Workerに送信されます。Workerは、受信したメッセージを処理し、以下の3つのタスクを実行します。

1. 署名の検証 (HMACに対してWebhookの秘密鍵)
2. テナントの識別 (受信した電話番号から)
3. ペイロードの正規化 (音声は文字列に、画像は説明に、位置は座標に)

ステージ1の終了時点で、オブジェクト {tenant_id, conversation_id, user_message} が準備され、次のステージに進みます。

ステージ2: コンテキストの解決 (D1 + KV、~80ms)

アーケードは、3つのコンテキストを取得する必要があります。

1. テナントの情報 (テナントIDから)
2. 会話の履歴 (会話IDから)
3. ユーザーの情報 (ユーザーIDから)

これらのコンテキストを取得するには、D1とKVを使用します。

ステージ3: スキルの選択 (D1 + KV、~80ms)

アーケードは、次のアクションを決定するために、スキルを選択する必要があります。スキルは、D1とKVを使用して選択されます。

ステージ4: 次のアクションの決定 (D1 + KV、~80ms)

アーケードは、次のアクションを決定するために、D1とKVを使用します。

ステージ5: 実行 (D1 + KV、~80ms)

アーケードは、決定したアクションを実行します。実行は、D1とKVを使用して行われます。

ステージ6: メモリの保存 (D1 + KV、~80ms)

アーケードは、メモリに保存します。保存は、D1とKVを使用して行われます。

これらの6つのステージを通過すると、ターンのサイクルが完了し、返信が送信されます。

• 最近の履歴 (最後のN回の重要なターン).
• 長期記憶 (クライアントの設定、購入履歴、メモ).
• エージェントの状態 (パーソナ、有効なスキル、ルール).

すべては D1 (Cloudflareの分散型SQLite) から来ています。D1は従来のPostgres/Mongoを置き換えます — サーバーレスなので、ワーカーからアクセスするのに数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は、Anthropic Claude、OpenAI GPT、Google GeminiなどのフロントラインのLLMに単一の呼び出しを行います (テナントによって構成可能)。呼び出しに渡されるのは:

• システムプロンプト = エージェントのパーソナ + ルール + 有効なスキル。
• 履歴 = ステージ 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)

スキルは モデルで実行されません。代わりに、コードが実行されます。このコードは、スキルを実行するために必要な情報を取得し、スキルを実行するために必要な情報を提供します。

CRITICAL RULES:

• Preserve ALL markdown formatting EXACTLY (headers ##, lists -, bold, italic, links, code blocks, etc.)
• Do NOT translate URLs, code, or HTML tags
• Do NOT add preamble or commentary
• Output ONLY the translated markdown, nothing else

1. 有効なパラメータを検証 (date_range が正しい形式か? tenant のルールに従っているか?).
2. 許可を確認 (このエージェントはこのカレンダーを参照する権限があるか?).
3. APIを呼び出す (この場合はGoogle Calendar API).
4. 結果を構造化して返す してモデルに渡す。

なぜこれが重要か? モデルは結果を生成することはない。カレンダーが [10h, 11h] と返す場合、実際にその時間が返される。スキルが失敗した場合、モデルは失敗したことを知っている。エージェントが「9時には時間がある」という情報を生成するリスクがない。

価格、期限、顧客名などの機密情報を含むケースでは、パイプラインは tool call を強制する。モデルが回答するのではなく、スキルが回答するようにする。 幻覚 の最も一般的なクラスを排除する。

ステージ 6 — 返答と永続化 (~50ms)

スキルの結果を手に入れたモデルは、2 回目の呼び出しを行う — これは、最終的な回答を顧客に渡すために。例えば:

"土曜日に 10 時間と 11 時間がある。どちらが好きなですか?"

並行して、ワーカーは:

1. API経由でメッセージを送信する。
2. ターン全体をD1に保存する (ユーザー + アシスタント + ツールの呼び出し + 処理時間)。
3. 長期記憶を更新する (ターンが新しい事実を生み出した場合) (例: 「顧客は土曜日に好み」)。
4. 観察可能性のイベントを発行する (遅延のメトリック、トークンのコスト、スケールのレート)。

すべては並行して実行される。永続化はメッセージの送信をブロックしない。顧客はD1を待たない。

---

幻覚の防御

生産環境で幻覚を起こすエージェントは、信頼性を失う。OpenClawには4つの防御線がある。

1. 事実のソースを強制する。価格、時間、名前などのデータは 常に スキルから来る。モデルは単独で回答することはない。
2. 機密情報の二重確認。予約は顧客に確認される前に保存され、支払いは顧客に確認される前に解除される。
3. 否定的なルール。各エージェントのパーソナは「X、Y、Zを生成しない」という明確なルールを含む。モデルはこれに従う。
4. 人間へのフォールバック。質問に対してスキルが対応できない場合、エージェントは「チームに確認してみましょう」というメッセージを表示し、チケットを開く。

CRITICAL RULES:

• すべてのマークダウンフォーマットを厳密に保存 (ヘッダー ##, リスト -, 太字, イタリック, リンク, コードブロックなど)
• URL、コード、HTMLタグを翻訳しない
• 導入文やコメントを追加しない
• 翻訳されたマークダウンのみ出力

元のマークダウン: Arquitetura boa é invisível até você olhar a fatura. Dado que cada turno faz 1-2 chamadas de LLM + lookups em D1, o custo típico por conversa completa (10-15 turnos) fica em:

翻訳されたマークダウン: Arquitetura boa は、請求書を確認するまで目に見えない。各ターンは、LLM の 1-2 回の呼び出し + D1 の検索を実行するため、完全な会話 (10-15 ターン) の典型的なコストは次のようになる。