@NEAR Protocol のアプローチで興味深いのは、AIエージェントを、単により多くのツールを備えたチャットボットではなく、インフラとして扱っている点です。
多くのエージェントシステムでは、推論、実行、機密情報、インターネットアクセスが、いまだに同じループを通っています。デモではそれが印象的に見えるかもしれませんが、実際の仕事は別の話です。エージェントがアクセスできるツールが増えるほど、何かがうまくいかなくなる可能性も増えます。
IronClaw 1.0は別のアプローチを取っています。
エージェントが意思決定を行い、guard と呼ばれる別の調整レイヤーが、その決定をどのように実行するかを制御します。後から追加された新しい機能も含め、すべてのアクションはそのレイヤーを通過します。
ベンチマーク結果が興味深いのは、基盤となるモデルが同じままだった点です：deepseek-v4-flash。
• PinchBench：147の実世界タスクで93.5%
• ClawBench：140以上の本番Webサイトで88.6%
• OfficeQA：米国財務省の文書を数十年単位で推論するテストで76.4%
同じベースモデル。異なるランタイム。IronClawのほうがより良い結果です。
でも個人的には、その数字よりもアーキテクチャのほうが重要だと思っています。
IronClawは、いくつかの実用的なセーフガード（保護策）を中心に構築されています：
設計上より安全：機密性の高い操作には明示的な承認が必要になる場合があります。一方で、シークレットは必要に応じて発行され、その後スクラブ（消去）できます。
永続的な状態：継続的なチェックポイントにより、エージェントは中断後に進捗を失うのではなく、停止したところから再開できます。
オムニチャネル・メモリ：CLI、Web、Slack、Telegramで、同じルールと文脈を保ちながら1つのアシスタントとして動作できます。
チーム分離：組織はツールを共有できますが、プライベートなワークスペースを自動的に公開することにはなりません。
そして、NEAR AIとステーキング全体のより大きな話があります。
NEAR AIは分散型AIのための基盤を構築しており、機密推論、計算、そしてAIエージェントといった領域に焦点を当てています。その文脈において、ステーキングは単に利回りを得るためだけのものではありません。これらのシステムが依存する分散型インフラを支え、保護することにも役立ちます。
ユーザーはNEARをステークし、機密推論およびIronClawホスティングのための繰り返し利用できる計算クレジットを受け取れます。一方で元本は引き出し可能です。
AIエージェントが単なる会話を超えて、Webサイト、ツール、データ、そして機密性の高いシステムとやり取りし始めるほど、この点はますます重要になります。OpenClawのような今後の展開は、そうしたより広い方向性の一部です。
私の主な気づきはシンプルです：
AIエージェントには、より良いモデルだけでなく、それらのモデルの周りにあるより良い仕組みが必要です。
セキュリティがポリシードキュメントにしか存在しない場合、後回しになりやすくなります。
IronClawでは、セキュリティをランタイムそのものの一部に組み込むという発想です。
そして正直に言うと、NEARのAIアプローチで私が最も興味深いのは、その部分です。
必要なら、XとLinkedInでIronClaw 1.0のより深い内訳と、NEAR AIのステーキングについても共有しました。
X: https://x.com/sheishelen914/status/2096210978027303108
LinkedIn:
https://www.linkedin.com/pulse/ironclaw-10-near-staking-why-agent-architecture-now-matters-essien-6xfse?utm_source=share&utm_medium=member_android&utm_campaign=share_via