Cambioのホームページのチャット入力欄は、オープンエンドなLLMではありません。ちょうど5つのカテゴリのリクエストを認識します。この記事はそのツアーです——各カテゴリが何をするのか、どう言い回せばいいのか、そして内部で何が起きているのか。
cambio.oneの上部にあるチャット入力欄は、オープンエンドな言語モデルではありません。カスタマーサポートのウィジェットでもありません。ウォレットエージェントでもありません。それは、親しみやすい会話の表層を備えた構造化インテントパーサーであり、ちょうど5つのカテゴリのリクエストを理解します。この記事では、実際の入力例とともにその5つすべてを順に見ていきます——何が機能し、何が機能しないのか、そしてエンターを押したとき内部で何が起きているのかが分かるように。
Cambioにおける「AIスワップ」の意味を扱った基本記事をまだ読んでいない場合は、そちらを先にお読みください。この記事は、AIがパーサーと説明役であり、見積もりを取得するのはモデルではなく決定論的なコードだということを、すでにご存じである前提で書いています。
5つのカテゴリを一目で
各カテゴリはバックエンドの異なる解析ファミリーに対応し、異なる見積もりツールへルーティングされます。コンポーザーはメッセージの言い回しからどのカテゴリを意図しているか自動検出しますが、入力を始める前にチップをクリックしてカテゴリを固定することもできます——曖昧さを取り除きたいときに便利です。
- Swap——直接実行、送りたい金額（amount-in）
- Execute——逆方向、受け取りたい金額（amount-out）
- Suggest——複数選択肢の探索（「Xを持っているが、どうすべき？」）
- Compare——ネットワーク間または取引所間の比較
- Help——定型の教育的な回答（見積もりは生成されない）
1. Swap——最もよく使われる経路
Swapは、ほとんどの人が求めているものです。ある資産を特定の金額だけ持っていて、特定の別の資産が欲しい。コンポーザーはあなたのメッセージから5つのフィールドを解析します。送付元通貨、送付元ネットワーク、受取通貨、受取ネットワーク、そしてamount-inです。
パーサーが認識する言い回しの例：
- 「Swap 0.3 BNB to USDT on BSC」
- 「Convert 100 USDT on Tron to USDC on Solana」
- 「0.0025 BTC for ETH」
- 「Exchange 50 USDT BEP20 to ETH」
ネットワークが不足していたり曖昧だったりすると、パーサーが尋ねます。「USDT」だけではBSC、Ethereum、Tron、Solanaのいずれにもあり得ます——なので、コンポーザーは黙って推測せずに「USDTはどのネットワークですか？」と確認します。これは意図的な設計判断です。黙って推測することは、インスタント取引所でユーザーが資金を失う最もありふれた原因だからです。
内部では、Swapはひとつの見積もりリクエストに対応します。(from, fromNetwork, to, toNetwork, amountIn) が与えられると、選択された実行ルートがあなたの正確な金額を見積もり、ネットワーク手数料が明記され、他の取引所の日付付きの参考値が添えられます。AIがルートや価格を選ぶことはありません。
2. Execute——送付額ではなく受取額が分かっているとき
ExecuteはSwapの逆です。相手側でどれだけ受け取りたいかが分かっている——典型的には、特定の請求書を支払う、特定の勘定を清算する、目標残高まで補充する、といった場合です。コンポーザーはamount-outの言い回しを受け付け、その逆を解きます。その金額を受け取るには、送付元側をどれだけ送る必要があるか、です。
言い回しの例：
- 「Swap enough ETH to get 500 USDT after fees」
- 「How much BNB do I need to send to receive 200 USDT on BSC?」
- 「I need exactly 1 ETH — what does that cost in BTC?」
Executeも内部では同じ経路で、向きが逆になるだけです。Cambioは、ネットワーク手数料を差し引いたうえで、指定された受取額になる送金額を算出します。解析されるのは同じいつつのフィールドで、違いはどちら側が条件になるかだけです。
細かいながら重要な点として、Executeはルートの上限・下限を受取側ではなく送金側に適用します。必要な送金額がその時点でルートの受け付ける範囲外であれば、入金アドレスが作られる前にコンポーザーがそう伝え、対応できる最大の金額を示します。
3. Suggest——複数選択肢の探索
Suggestは、まだ決めていない段階のためのものです。自分が何を持っているかはわかっていても、何が欲しいかはまだ決めていない。コンポーザーは、ポートフォリオに関する自由形式の質問を受け取り、選択肢の短いリストを平易な説明付きで返します（強引な推奨ではありません）。
言い回しの例：
- 「$500分のBNBがあります。手数料の低い方法でステーブルコインにするには？」
- 「ETHをEthereumから手数料の低いチェーンに移すには？」
- 「I have leftover SOL — what can I do with it?」
Suggestには、ほかのカテゴリーにない特徴があります。いくつかの候補スワップの価格を出し、短いリスト——通常はみっつの選択肢——を返します。各選択肢は仮定の話ではなく、価格まで算出された見積もりです。ユーザーがどれかを選ぶと、それが通常のSwapになります。
これは最も会話らしく感じられるカテゴリーです。AIは違いを平易な言葉で説明し——どのネットワークの手数料が低いか、最終的にどのステーブルコインを持つことになるか——数値は見積もりカードに任せます。選択のロジックは引き続き決定論的です。AIはそれを言葉で伝えるだけです。
4. Compare——ネットワーク間または取引所間
Compareは、Cambioの見積もりが他の取引所と比べてどうかを示します。実行したいのではなく、表を読みたいだけのときもあるでしょう。コンポーザーは比較の形をした質問を認識し、ルートを確定させずに比較だけを返します。
言い回しの例：
- 「Compare USDT prices across all networks」
- 「1 ETHに対するCambioの見積もりは、他の取引所と比べてどうですか？」
- 「0.5 BNBをUSDTにすると、他の取引所ではいくらになりますか？」
Compareで Cambioの見積もりの横に並ぶ行は、すべての見積もりに表示されるのと同じ日付付きの参考値です。他の取引所自身のウェブサイトを確認した結果とそれぞれの確認時刻、または日付付きのEst.行です。Compareは「スワップの準備完了」という枠を外し、表だけを表示します。決めたら、同じコンポーザーのスレッドから、ペアを入力し直さずにSwapへ切り替えられます。
5. Help —唯一、取引を行わないカテゴリー
Helpは例外です。見積もりを生成しない唯一のカテゴリーです。代わりに、Cambioの仕組みに関して認識済みの少数の質問に対して、あらかじめ用意された解説を返します。
言い回しの例：
- 「ネットワーク手数料はどのように表示されますか？」
- 「ペアの上限・下限はいくらですか？」
- 「スワップにはどれくらい時間がかかる?」
- 「対応しているチェーンは?」
ここでの回答は、毎回その場で生成されるわけではありません。あらかじめ書かれ、レビューされ、固定の文字列として保存されています。同じ質問をすれば、どのユーザーにも同じ文章が表示されます。これは意図的な設計です。上限、手数料、対応チェーンといった質問に対して、モデルが即興で回答を作ることは望んでいません。即興の回答こそ、ポリシーに関する主張がぶれていく原因そのものだからです。これらの回答は、FAQページにも詳しい形で掲載されています。
それ以外のすべては?
あなたのメッセージが5つのカテゴリーのいずれにも一致しない場合、コンポーザーはその旨を伝えます。勝手にカテゴリーをでっち上げることはありません。「とりあえずやってみて様子を見よう」と黙ってフォールバックすることもありません。代わりに、「swap、execute、suggest、compare、helpのいずれかならお手伝いできます。言い換えていただけますか?」といった短いメッセージを返し、チップを展開する選択肢を提示します。
メッセージが認識されない最も多い原因は、ネットワークの指定漏れです。「Swap 100 USDT to BTC」はきれいに解析できますが、USDTは4つのネットワークにまたがって曖昧です。コンポーザーが尋ね、ユーザーが明確にし、取引が進みます。
2番目に多い原因は、対応していないペアです。Cambioは25ネットワークにまたがる118トークンを見積もりますが、どの実行ルートも対応していないペアは拒否されます。私たちはすぐにお伝えします。フローの途中で不意打ちになることはありません。
なぜ「何でも思いつくもの」ではなく、ちょうど5つなのか
スコープを限定していることは、機能のひとつです。「何でも聞いて」と謳う自然言語インターフェースの多くは、2つの点で失敗します。エッジケースで過剰な約束をしてしまうこと(ポリシーのない質問をモデルに解釈させると、予測できない回答が生まれます)、そして何が有効なリクエストで何がそうでないのかを、ユーザーが確信できなくなることです。ユーザーはプロンプトで言葉を濁し始めます。信頼の境界線がぼやけていくのです。
5つのカテゴリーは、それぞれに決定論的なポリシーを書き、すべての解析パスをテストし、何が起こるかを正確にお伝えできるくらい、十分に小さな面です。同時に、人々が実際にコンポーザーを使う用途を網羅できるくらい、十分に大きくもあります。これら5つのいずれにも当てはまらない、現実のスワップのユースケースは、まだ見つかっていません。
もし将来そうしたものが見つかり、そのリクエストのパターンが独自の一級解析ファミリーに値するほど一般的であれば、6つ目のカテゴリーを追加し、ポリシーを書き、それを文書化します。パーサーのスコープを黙って広げることはしません。
試してみよう
これらすべてを腹に落とす一番早い方法は、上記の例文のいずれかを、ホームページのコンポーザーに打ち込んでみることです。コンポーザーは、識別したカテゴリーをあなたに伝え、その結果の見積もりカードが、決定論的ルーターがあなたの意図に対して何をしたのかを、正確に見せてくれます。
このシリーズの次の記事では、すべての見積もりの横にある参考値について説明します。それがどこから来るのか、なぜライブではなく日付付きなのか、そしてなぜ元の行データを公開しているのか。
