AIエージェントは、別の段階へと移行しつつあります。
もはや回答を生成することに限定されません。Webサイトを閲覧し、ファイルを管理し、コードを書き、情報を扱い、そして複数ステップのワークフローを実行できます。
その追加された機能は、新しいエンジニアリング上の課題を生み出します。
ソフトウェアがあなたの代わりに動けるようになったとき、何が許可されていて何が許可されていないのかをどう管理しますか?中断されたタスクが消えてしまわないように、どう確認しますか?そして、データと計算の裏側でそれを支えるインフラを、どう保護しますか?
それが、@NEAR Protocol からの IronClaw 1.0 を調べる価値がある理由です。
重要な境界は、「決める」と「実行する」の間にあります
IronClaw 1.0は、#NEARAI から作り直されたエージェント用ハーネスです。シンプルなアーキテクチャ上の分離を軸に構築されています。つまり「何をするかを決めるコンポーネント」と「アクションを実行するコンポーネント」が別になっています。
その間にあるのが、ガードと呼ばれる調整(コーディネーション)レイヤです。
すべてのアクションはこの経路を通ります。機微なアクションでは、実行前に明示的な承認が必要になる場合があります。これにより、エージェントの推論と外部システムに影響を与える能力の間に制御ポイントが生まれます。
ガードは、ローンチ後にエージェントの周りに巻き付けられるわけではありません。ガードは実行経路の一部です。
それこそが、「設計による安全性」が現実的になる場所です。あるルールセットは、後から新しいツールが追加されても機能し続けるために、一度定めておくものです。

作業が耐えられなければ、能力だけでは不十分です
実作業を扱うエージェントにも、永続性が必要です。
IronClawは状態を継続的にチェックポイントします。タスクが中断されたり、許可のために一時停止されたり、セッションを再起動する必要が生じても、作業は失われず、止まったところから再開できます。
中断は、タスクを最初から繰り返す理由ではなく、一時停止になります。
同じ原理はチャネル全体にも広がります。CLI、Web、Slack、Telegramは、共有メモリと同じ安全ルールを備えた1つのアシスタントとして機能できます。
組織向けには、#IronClaw がさまざまな隔離モデルをサポートします。マルチテナントのデプロイでは、チームがツールやスキルを共有しつつ、個々のワークスペースはデフォルトで管理者からプライベートに保ちます。必要な場合には監査可能なアクセスが提供されます。シングルテナントのデプロイでは、完全な隔離を提供できます。
AIエージェントについて話すと、こうした詳細は見落とされがちです。ソフトウェアが、実在する組織のデータの周辺で動くことが求められると、重要になってきます。
ベンチマークは、制御がパフォーマンスコストを伴うかどうかを検証します
続いて当然の疑問があります。もう1つの制御ポイントを追加すると、エージェントの能力は下がってしまうのでしょうか?
NEAR AIは、同じdeepseek-v4-flashのベースモデルを用いて、3つのベンチマークでIronClawをテストしました。その選択により、ハーネスが切り分けられます。
PinchBench:スケジューリング、メールの一次仕分け、コーディング、調査、ファイル管理を含む147の実タスクで93.5%。
ClawBench:140以上の実運用Webサイトに対して書き込み重視・マルチステップのタスクをテストし、88.6%。
OfficeQA:米国財務省の官報(Treasury Bulletins)約89,000ページに含まれる、2,600万以上の数値データを含む文書に対する、エンタープライズ向けの文書推論で76.4%。
これらのテストは、さまざまな種類のエージェント業務を明らかにします。オフィス業務のワークフロー、ライブなWebでのやり取り、そして密度の高いドキュメントです。
数値は、IronClawがあらゆるワークフローで勝つことを証明しているわけではありません。示しているのは、より限定的で役に立つ何かです。制御レイヤを追加しても、非常に異なる形態のエージェント実行において首位の結果を妨げなかった、ということです。

NEAR AIとステーキングがどこに当てはまるか
IronClawはそれ自体では浮かびません。より広いNEAR AIのインフラの中に収まっており、そこは民間で検証可能なAIを中心に構築されています。
NEAR AI Cloudは、対象となるワークロードにTrusted Execution Environments(TEE)を含む機密コンピューティングを使います。プライバシーは、「機械を運用する誰かを信頼する」だけではなく、技術的な隔離と検証に基づいて保たれることを意図しています。
率直に言うと、私はこの建築の“より面白い半分”のほうに惹かれています。エージェントが何をするかを制御するだけの話ではなく、そもそもエージェントが動いている環境のプライバシーと検証可能性の話でもあります。
この物語のうち、ステーキングはしばしば利回りに押しつぶされて語られがちです。NEARでは、関連しているものの別々の2つの役割があります。
プロトコルのレベルでは、ステーキングはプルーフ・オブ・ステークを支えています。ユーザーはNEARを検証者に委任し、検証とコンセンサスに参加します。経済的なステークは、ネットワークが安全であり続けるための仕組みの一部です。
NEAR AIは、機密推論や常時稼働のエージェントホスティングといったサービスにもステーキングを使います。このモデルでは、ステークされたNEARが、AIインフラの利用クレジットと結び付けられます。
プロトコルのステーキングはネットワークを守るのに役立ちます。NEAR AIのステーキングはAIインフラと計算資源へのアクセスを提供します。
あわせて見ると、層はきれいに積み重なっています。IronClawはエージェントの振る舞い方を制御し、NEAR AIはそれを動かすためのプライベートな場所を与えます。そして両方の下にあるのが、NEARプロトコルのステーキングです。これがネットワーク全体を正直に保ちます。

NEAR上でのステーキングは、利回りのためだけではありません。この層は、OpenClawが依拠するインフラを支えます。たとえば、NEAR AI Cloud上でのOpenClawのデプロイも含まれます。
私にとって本当の物語は、より賢いエージェントではなく、最終的に、こっそり踏み越えられない境界線を持つようになったことです。
意思決定と実行の間にガードがあるなら、実作業を任せるAIエージェントを信頼できるでしょうか?
