> ## Documentation Index > Fetch the complete documentation index at: https://docs.intention.xyz/llms.txt > Use this file to discover all available pages before exploring further. # エージェント > 参加者が人でないとき、アーキテクチャの各層は何をしなければならないのか——プロトコルの外にある runtime、エージェント負荷下の受け入れ、トランザクションとしての認可、そしてリプレイ可能な環境。ここで見据えている方向は、**一人の人間が複数のエージェントに代表され、それぞれがその人の意図の一部を担って動く**という形です。人＋道具でもなければ、固定スクリプトを回すボットでもありません。ひとつのアカウントに責任を負う、市場に対する複数のカウンターパーティです。参加者が変われば、市場のミクロ構造も一緒に変わります。一件あたりのサイズは下がり、メッセージレートは上がり、取り消しと約定の比率は今よりさらに開き、そして人間のフローにはない相関がフローに現れます——同じシグナルを読むエージェントは、同じ瞬間に同じ結論に達します。これは機能をひとつ足して片づく話ではありません。アーキテクチャを一層ずつ通り、各層が何を違うようにしなければならないかを問うことでしか片づきません。このページはその一巡です。順に辿り、各層が実際にどこまで来ているかを書きます。

1 · アプリケーション層

2 · ネットワーク層

3 · 実行層

4 · ステート層

runtime はプロトコルの外にあるそして特権を持ちません——低いレイテンシも、早いデータも、第三者が届かないインターフェースもありません

送信者が agent のときの受け入れ取り消しの遅れは発注の遅れより悪く、公平性はメッセージごとではなく直近の履歴で追われます

認可はトランザクションであるブロック高を持ち、閉じた命令セットの中にあります。そして取り消せば、その agent の未約定注文が同じブロックで消えます

リプレイ可能で、ブロック単位に版が付いた環境point-in-time は規律ではなく構造によるもの

アーキテクチャ概要と同じ四層です。違うのは問いだけ——参加者が人でないとき、各層は何をしなければならないのか。

| 層 | 変わるもの | 状態 | | ------------ | ------------------------------------- | --------------------- | | **アプリケーション** | runtime——リサーチと執行——はプロトコルの外にあり、特権を持たない | コミット済み | | **ネットワーク** | バースト的で相関し、取り消しの多いフロー下での受け入れ | 提供済み、未決の問いが二つ | | **実行** | 認可が条件を伴うトランザクションになる | 全か無かの形で提供済み、条件はコミット済み | | **ステート** | チェーンそのものが、エージェントが評価される環境である | 提供済み |

1 · アプリケーション層 —— runtime は外にあり、外になければならない

エージェント runtime はリサーチと執行のフレームワークです。見立てを作り、それを実行可能なものに変え、取引の場に差し出します。フロントエンドや API クライアントと同じ階層、つまりアプリケーション層で動き、**プロトコルの一部ではありません**。この配置は設計上の好みである前に物理的な制約です。モデルは秒で推論し、市場はミリ秒で動きます。モデルを呼ばなければならないものは、注文が実際に通る経路の上に置けません。つまり**プロトコルにはモデルが一切ありません**。これは欠落ではなく、決済経路上のモデルが、ここの他のすべてが乗っている唯一の性質を壊してしまうからです。実行経路はどのノードでも同じバイト列を出さなければならず、推論はそれをしません。そこで runtime は外にいます。すると誠実な問いは、プロトコルがそれに何を負っているか、になります。五つあり、いずれも提供済みではなくコミット済みです。 | | エージェントに与えるもの | | ------------------- | ------------------------------------------- | | **プリトレード・シミュレーション** | 提出する前に、コミット済みの状態に対して注文が何をするかを評価する | | **冪等な提出** | 結果が曖昧な提出を、二重のエクスポージャーを負うことなく再送できる | | **名前のある終端状態** | 結果が不明のまま終わることがない。すべての動作は名前のある状態で終わる | | **定義された再開** | 再起動したエージェントが、どこまで進んでいて次に何をすべきかを知っている | | **帰属付きのレシート** | そのエージェントが何をし、誰の権限のもとで、いくらかかったか——プロトコルの出力として | 状態は[次に来るもの](/ja/protocol/roadmap/whats-next)を参照してください。 runtime は特権的な経路を一切持ちません。より低いレイテンシも、より早いデータも、第三者の runtime が届かないインターフェースもありません。これは前提にせず明記すべきことです。このアーキテクチャが他所で述べている主張は「トレーダーとクリアリングハウスのあいだには何も立たない」であり、専用レーンを持つ自社ツールは、まさにその「何か」だからです。

2 · ネットワーク層 —— 送信者がエージェントのときの受け入れ

mempool は、何を保持する価値があるか、ある送信者のどれが次か、どのピアがそれを知るか、需要が容量を超えたとき何を落とすかを決めます。エージェントのフローはこの四つすべてに負荷をかけますが、それを吸収する性質のうち二つは、エージェント以前の理由ですでに備わっています。 **遅れた取り消しは、遅れた注文より悪い。** [mempool](/ja/protocol/architecture/mempool)は設計上、注文と取り消しのトラフィックを非対称なものとして扱います。エージェントは取り消しと約定の比率が人間より高いため、その非対称性をより極端にしますが、問題の形そのものは、この層がもともとその周りに作られたものです。 **公平性はメッセージ単位ではなく、直近の履歴で追われる。** mempool は、最近どの送信者とどの種類のトラフィックが容量を消費したかのローリングな記録を保ち、それに応じて次に何を出すかを整えます。**相関するバーストで効いてくるのはここです**：四十のエージェントが同じシグナルで取り消すのは、平均負荷の四十倍が均等に広がることではなく、一本のスパイクです。メッセージ単位の制限はそれを取り逃がします。最近誰がうるさかったかの記憶は取り逃がしません。 **コンセンサスはスループットとともに大きくならない。** トランザクションはバッチとしてバリデータに届き、提案が参照できるようになる前に可用性が証明されるため、ブロック提案は本体ではなくダイジェストを運びます。メッセージレートを一桁上げるエージェント群がいても、コンセンサスのメッセージサイズは一切上がりません。ブロックが消すのは**ブロック内**のレースです。同じブロックの二つのトランザクションには、どのノードも同一に計算する優先順位があります。**その保証はブロック境界から始まります。** ブロックに入るまでは依然としてレースであり、送信者単位の公平性によって形を与えられてはいても、消えてはいません。mempool の受け入れは、ブロックへの取り込みではありません。この層では二つの問いが開いており、どちらも人間の量ではなくエージェントの量で初めて実際の問題になります。 **取り消しはいくらであるべきか。** 実行層ではすでに取り消しが先に来ます——流動性を取りうるものより前のフェーズで走ります。ネットワーク層での同じ問いは未決です。安価で優先される取り消しこそが「気配を守れる」ことの源であり、同時に mempool を溢れさせる最も安い方法でもあります。取り消しが発注とは別の容量勘定を持つべきかどうかは、決まっていません。 **冪等性はどの層のものか。** 応答を得られなかったエージェントは再送します。冪等な提出は実行層でコミット済みであり、本当に重要な帰結——二重のエクスポージャーがないこと——を片づけます。しかしネットワーク層の版は片づきません。mempool が再送を同じ意図として認識すべきか、両方を運んで実行層に重複排除させるべきか。リトライの嵐のもとで、この二つは違う挙動になります。意図的にリストに入れていないものが一つあります。エージェント専用の受け入れレーンです。優先アクセスはあらゆる中央集権型の場が最後には売るものであり、「トレーダーとクリアリングハウスのあいだには何も立たない」という主張と正面から矛盾します。エージェントのフローも同じ扉を通ります。

3 · 実行層 —— 認可はトランザクションである

ここがアカウントモデルの変わる層であり、その変化のすべてはひとつの事実から出ています。 **アカウントをエージェントに渡すことは、オンチェーンのトランザクションです。** フォームの送信でも、設定ページから発行される API キーでも、運営者のデータベースの一行でもありません。トランザクションです——ブロックの中にあり、高さを持ち、それを付与したアカウントが署名しています。したがって第三者は誰にも尋ねることなく、それを見つけ、読み、確かめられます。そこから三つの帰結が出ます。どれも API キーにはできないことです。 **それは閉じた命令セットの中にある。** エージェント認可は[カーネル](/ja/protocol/architecture/kernel)の列挙された操作のひとつです。汎用チェーンはこれを表現できません——その呼び出しの意味は不透明なバイトコードになります。中央集権型の場は、あなたが検査できないソフトウェアの中でそれを強制します。ここでは権限とその境界が**命令そのもの**であり、だから境界は約束ではなく検査できるものです。 **エージェントが何をしてよいかは運べるが、何をしてはいけないかは運べない。** 認可は、そのエージェントが何を持てるか、いくらまで失えるか、どの市場に触れてよいか、証拠金モードを変えてよいかを述べられます。**「出金」とは述べられません。** これは既定でオフにしてある設定ではなく、書くべき項目そのものが存在しないということです。アカウントを操作するエージェントには、そこから資金を動かす表現可能な経路がありません。 **それを取り消せば、そのエージェントの未約定注文も消える。** 取り消しもまたトランザクションであり、[順序付け](/ja/trading/tx-sequencing)が「取り消しは流動性を取りうるものより前に走る」と定めているブロックに着地します。したがってエージェントが板に残した注文は、その権限と同じブロックで消えます。取り消しがデータベース書き込みである場では、キーは効かなくなり、未約定注文は未定義の状態に置かれます。ここでは停止は証明可能で、それが起きた高さを誰でも見つけられます。

付与ブロック N のトランザクション範囲を運びます。その agent が何を持てるか、いくら失えるか、何を取引できるか。出金は運べません——その項目自体が存在しません

実行すべての動作が権限の出所を明示する提出した agent だけでなく、付与したアカウントに帰属します

取り消しブロック M のトランザクションその agent の未約定注文は同じブロックで、流動性を取りうるものが走る前に取り消されます

三つのいずれも、誰かに知らせてもらう必要のあるデータベース書き込みではありません。どれも、誰でも高さで見つけられるトランザクションです。

今日、付与は全か無かで、有効期限が付いています。上に挙げたより豊かな条件——何を持てるか、いくら失えるか、次に何をしてよいか——は提供済みではなくコミット済みです（[次に来るもの](/ja/protocol/roadmap/whats-next)を参照）。**すでに成立しているのは、後から付け足せない部分です**：権限は、運営者が持つ権限の記録ではなく、プロトコルのオブジェクトである、ということです。

場がすでに runtime のために担っているもの

普通の場でユーザーを守らなければならない取引 runtime は、結局自前の特権カーネルを作ることになります。自分で維持し照合するポジション台帳、自分で走らせて場も同じ計算をしていることを願うプリトレードのリスクチェック、自分で書いて改竄されていないことを証明できない監査ログ。**この三つはいずれも、帳簿を見せない場に対する冗長性です。** ここではその三つがプロトコルの性質です。台帳を書くのは[クリアリングハウス](/ja/protocol/architecture/clearinghouse)だけです。リスクステージはマッチングの前、同じブロックの中で走ります。監査ログはチェーンそのものであり、あらゆる状態変化がそれを引き起こしたトランザクションを伴います。runtime に残るのは四つめ——冪等なオーダーゲートウェイ——であり、それは信頼の問題ではなくインターフェースの問題です。

マッチング：ブロックがすでにバッチである

エージェントのフローは板に届くものの頻度を上げ、サイズを下げます。これはバッチオークションを論じるときに最もよく持ち出されるミクロ構造そのものです——離散的な区間、まとめて清算、1 マイクロ秒早く着いても優位はない。その性質はここで**すでに成立**しており、バッチオークションを足したからではありません。ブロック内の時間はローカルな時計ではなくコンセンサスがコミットした位置なので、**ブロック内にサブミリ秒の優位は存在しません**。そして取り消しは攻撃的な注文より先に走るため、古い気配は引くことができ、取り消しと並んで到着した注文に食われることはありません。ブロックは、まとめて清算される離散区間です。それは市場設計の後付けではなく、コミット済みの順序を実行することの**帰結**として現れました。それ以上のことが妥当かどうか——そして連続的な価格・時間優先と頻繁なバッチオークションは、バッチがバッチ内の時間優先を意図的に取り除く以上、**足し算ではなく二者択一**です——は、構築中ではなく検討中です。

4 · ステート層 —— チェーンが環境である

エージェントの良し悪しは、何に対して評価されたかで決まり、失敗の大半はまさにその評価で起きます。シミュレータでは儲かって本番で失敗する戦略は、たいてい新しい市場に出会ったのではなく、場ではないシミュレータに出会っただけです。 [ステート層](/ja/protocol/architecture/state/model)は、この隔たりを規律ではなく**構造**で取り除きます。状態はブロック単位で版が付き、あらゆる変化はそれを引き起こしたトランザクションに帰属するので、ブロックをリプレイすることは環境のモデルではなく**環境そのもの**をリプレイすることになります——そのエージェントを実際に実行するのと同じ状態機械の上で、ネットワークがコミットした入力に対して。これが[自分で検証する](/ja/developers/verify)の五番目のチェックであり、ここでのバックテストが取引所の履歴 API に対するバックテストとは**別種のもの**である理由です。より微妙な性質は、これが**構造による point-in-time** だということです。取引所 API から組み立てたデータセットが point-in-time であるのは、組み立てた人が注意深かった場合だけで、先読みは誰も気づかない隙間から漏れ込みます——後から埋め戻されたフィールド、履歴に適用された修正、改訂された参照価格。ここではその問いが生じません。あるブロックの状態はそのブロックで真であったものであり、状態はそれ以外の形を取ったことがないからです。

難しくなること

エージェント向けに作るということは、良くなることの一覧だけではありません。 **決定性は両刃です。** エージェントは提出前に自分の注文が何をするか予測できます。同じ入力がどのノードでも同じ結果を出すからです。**他人のエージェントも、あなたの注文について同じことができます。** 再現可能性は、あなたの計画可能性と予測されやすさを同時に高め、後者は無料ではありません。 **エージェントの流動性は相関した流動性です。** 人間のマーケットメイカーは気づく時点が違うので、引く時点も違います。同じ公開状態を読むエージェントは一緒に同じ結論に達します。エージェントに支えられた板は平常時には厚く、肝心な日にはより速く薄くなりえます——これはプロトコルの吸収層が備える市場構造リスクであって、取り除けるリスクではありません。 **オラクルが読む場では、エージェントも取引しています。** 認証は価格をそれを消費したブロックに結び付けますが、原市場を操作不能にはしません。相関したシグナルで動くエージェント群は、原市場が一緒に動きうるもう一つの経路です。[オラクルが保証すること・しないこと](/ja/protocol/architecture/oracle)を参照してください。 **エージェントの自己評価は証拠ではありません。** 取引のフィードバックはコードのそれと違い、ノイズが多く非定常です——コンパイラは間違っていると教えますが、儲かった一週間は正しかったと教えてはくれません。エージェント向けに場が作るものは何であれ、エージェント自身の成績の申告を測定ではなく**敵対的な入力**として扱わなければなりません。[自分で検証する](/ja/developers/verify)のチェックが、報告できることではなく再計算できることを軸に組まれている理由のひとつがこれです。

次に読む

四つの段階と、変わらなければならないのがアカウントである理由。エージェントの評価を主張以外の何かにするチェック。検証できるものを検証したあとに残るもの。エージェント runtime と認可条件の状態。