@Newton Protocolが最初に目を引いたのは、取引自動化戦略のためのセキュアなロールアップとして説明されていて、開発者が自分のエージェントを公開できるマーケットプレイスだとされたからです。野心的に聞こえましたが、同時に警戒もしました。自動化を主な魅力として掲げながら、その自動化がミスを起こしたときに何が起きるのかを適切に扱っていない暗号プロジェクトを私はたくさん見てきました。

私を引き込んだ問いはシンプルでした。私がソフトウェアに取引や資産の移動を任せるとして、それが意図した以上のことをしてしまわないようにするにはどうすればいいのでしょうか？

最初、Newtonは主にトレーディングボットや自動ポートフォリオ戦略のためのものだと期待していました。現在のWebサイト、ドキュメント、ホワイトペーパー、トークン情報、そして公開リポジトリを読んだ後、このプロジェクトがより広い発想へと進んだことを理解しました。Newtonは今、自身をオンチェーン・ファイナンスのための認可レイヤーだと説明しています。

この変化は最初、私を混乱させました。というのも、私が最初に始めたプロジェクト説明と完全に同じではないからです。以前の資料は、検証可能なエージェント、セキュアな実行環境、ゼロ知識の権限、そして開発者向けのマーケットプレイスについてもっと話していました。現在の資料は、オンチェーン取引が実行される前にチェックされるプログラマブルなポリシーに焦点を当てています。考えれば考えるほど、この方向性にはより筋が通っているように思えてきました。

ブロックチェーンは、取引に有効な署名があるか、ウォレットに十分な資金があるかを検証できます。しかし自動的に知ることができないのは、取引が支出上限に違反していないか、怪しいアドレスを使っていないか、企業のポリシーを破っていないか、あるいは自動化された戦略に与えられた指示に反していないかといった点です。

これらの判断は通常、Webサイト、プライベートサーバ、または管理者によって処理されます。問題は、Webサイトは回避できてしまうことです。人はスマートコントラクトと直接やり取りでき、別のアプリケーションはまったく異なるルートを使う可能性があります。

Newtonは、ポリシーチェックを実際の取引により近い場所へ置こうとしています。保護されたアクションが実行される前に、コントラクトが「特定の条件が満たされたか」を尋ねます。これらの条件を検証できないなら、資金が動く前に取引は拒否されるべきです。

私にとって最もわかりやすい比較はカード決済でした。カードネットワークは、すべての支払い要求を即座に決済しません。まず、口座ステータス、利用可能な限度額、不正の兆候、加盟店情報などを確認します。Newtonは、オンチェーン取引に対するこの認可ステップのプログラマブル版を作ろうとしています。

プロセスはポリシーから始まります。開発者や組織が、特定のアクションが許可される前に何が真でなければならないかを定義します。Newtonは、Open Policy Agentエコシステムに関連するポリシー言語であるRegoを使って、これらのルールを表現します。基本的なポリシーなら、ウォレットが1日あたり固定額以上を使えないようにできます。より詳細なポリシーでは、自動化された戦略が承認済みの資産だけを売買し、選択したプロトコルを使い、スリッページ上限を下回り、市場価格が許容範囲から外れたら停止する、といったことを許可できます。

取引が要求されると、Newtonのオペレーターネットワークがポリシーを評価します。そのチェックは、オンチェーンの情報だけでなく、市場価格、ウォレットのリスクシグナル、本人性ステータス、準備金（proof-of-reserve）データ、管轄に関する制限など、承認済みの外部情報も使えます。

条件が満たされていれば、ネットワークはスマートコントラクトが検証できる結果を生成します。条件が満たされなければ、保護されたアクションは進行しません。

Newtonの開発者ドキュメントでは、それを「EigenLayer上にアクティブに検証されたサービスとして構築された分散型ポリシーエンジン」と説明しています。2026年2月のホワイトペーパーでは、このシステムを、ステーブルコイン、トークン化された資産、機関投資家向けDeFi、国境を越える支払い、そして自律型エージェントを含む商取引といった領域のための認可レイヤーとして提示しています。

自動取引は、こうしたものが必要になる理由を説明する、今でも有用な例です。たとえば、ポートフォリオのリバランスを行う自動化された戦略を作りたいとします。ETH、USDC、WBTCは取引させたいかもしれませんが、それ以外は不要です。分散型取引所を2つまで使うことを許可し、あるスリッページ上限を超える取引は拒否し、1日の損失上限に達したら取引を停止する、といったことが考えられます。

戦略に通常のウォレットアクセスを与えると、必要以上の権限を持たせることになり得ます。Newtonのポリシーなら、その周囲により狭い境界線を作れます。戦略がリバランスのタイミングを決め、ポリシーが、提案された各取引が実際に許可されるかどうかを決めることになります。

それは、Newtonが悪い戦略を利益の出る戦略に変えられるという意味ではありません。トレーディングロジックが貧弱なら、ポリシーを完全に守っても結果は改善しません。Newtonが主に関心を持っているのは、その戦略が指示の範囲内に留まっていたかどうかです。

この違いは役に立つと思いました。検証によって、ルールが守られたことは示せます。しかし、そもそもそのルールが妥当だったことまでは証明できません。

同じモデルは、オンチェーンのヴォルトにも適用できます。キュレーターには、預け入れた資産を異なる貸付市場の間で移動することが許可されるかもしれません。しかし、預け手は、リスクの枠組みに従うというキュレーターの約束だけに全面的に頼る必要はないはずです。ポリシーは、許可される市場を制限したり、エクスポージャーに上限を設けたり、最低流動性を要求したり、オラクルの価格があまりに急に動いた場合にはアクションをブロックしたりできます。DAOのトレジャリーも、もう一つの現実的な例です。トレジャリーは、承認済みの受取人への通常の支払いを許可しつつ、異常に大きい振込にはより厳しい条件を適用できます。ガバナンス投票が通ったとしても、最終的な取引は引き続きアクティブなポリシーを満たす必要があります。

Newtonは、ステーブルコインやトークン化された現実世界の資産についても議論しています。そのようなケースでは、ポリシーが本人性の要件、譲渡の制限、制裁情報、取引の上限、あるいは管轄に関するルールをチェックできます。

なぜ機関がこれを有用だと感じるかは理解できます。Webサイトにだけ置かれたコンプライアンスルールは弱いです。誰かがそのWebサイトを回避できてしまうからです。保護されたあらゆる操作の前に、そのコントラクトでチェックされるルールのほうが、はるかに回避が難しくなります。

同時に、このNewtonの部分は不快な問いも引き起こします。ポリシーエンジンは、常識的なセキュリティ上限を強制するために使えますが、オフチェーンの本人性やリスク情報に基づいて取引を制限するためにも使え得ます。規制された資産ならそれが必要だと考える人もいるでしょう。公開ブロックチェーンのオープンさから離れていくことだと捉える人もいます。

Newtonはポリシーを強制する仕組みを提供しますが、その仕組みが「特定のポリシーが公正かどうか」を判断するわけではありません。私の調査は、利用可能なドキュメント、ホワイトペーパー資料、トークン発表、現在のWebサイト、そして公開されているGitHubリポジトリに基づいていました。私はNewtonを通じて資金のあるウォレットを接続したり、本番用のポリシーをデプロイしたり、バリデータを運用したり、実際のトレーディング戦略を動かしたりはしませんでした。

それによって、経験について私が正直に言えることには限界があります。システムがどのように機能するはずなのかを調べることはできますが、実際の取引コスト、速度、信頼性、そして統合の容易さは、ライブ実装をテストしない限り確認できません。

[デモを実際に使った、ウォレットを接続した、NEWTをステークした、ポリシーをデプロイした、または開発例を試した場合は、ここに詳細を追加してください。]

私が一つ気づいたことは、Newtonの古い資料と新しい資料の違いです。

プロジェクトの2025年の情報では、信頼された実行環境とゼロ知識証明を使った検証可能なオンチェーン自動化について説明されていました。また、開発者がモデルやエージェントを列挙し、オペレーターがそれを提供できる「Newton Model Registry」についても触れられていました。

プロジェクトの現在のバージョンは、認可、コンプライアンス、ヴォルトのセキュリティ、ステーブルコイン、トークン化された資産について、以前よりはるかに多く語っています。エージェントのマーケットプレイスは、メインのWebサイトではもうそれほど目立っていません。これらの考え方は、まだ一つに組み合わせられる可能性があります。認可レイヤーは、将来的に自動化されたエージェントや、開発者が作った戦略のセキュリティ基盤として機能し得ます。とはいえ、Newtonは私が望むほど明確にそのつながりを説明していません。

私は、このプロジェクトが焦点を広げたのか、方向性を変えたのか、それとも単に見せ方を変えただけなのかが気になりました。何が変わり、なぜそうなったのかがわかる明確なタイムラインがあれば、プロジェクトの理解がずっと容易になるでしょう。

NEWTの役割についても、さらに詳しく見る価値があります。Foundationの公式なトークン発表によると、NEWTの総供給量は10億トークンで固定されています。初期の流通供給は2億1500万に設定されており、総数の21.5%に相当します。

発表された配分では、コミュニティ関連のカテゴリに60%、内部カテゴリに40%が割り当てられていました。内部部分には、コアコントリビューター、初期の支援者、Magic Labsへの配分が含まれており、それぞれ別個のロックアップおよびベスティング条件が設定されていました。

NEWTには当初、ネットワークのセキュリティのためのステーキング、プロトコル手数料の支払い、モデルレジストリへの参加、そして最終的にはガバナンスに関与する、という4つの想定される機能が与えられていました。

私がはっきり判断できなかったのは、その有用性のどれくらいが今日アクティブで、また新しい「認可」重視の設計にどう収まっているのか、という点です。もしNewtonが今、主にポリシーネットワークであるなら、どのポリシー操作にNEWTが必要なのか、ステーキングがポリシー評価をどう守るのか、誰がネットワークを運用できるのか、そしてモデルレジストリがアクティブな優先事項として残っているのかを知りたいです。トークンはシステム内で重要な位置を占めるかもしれませんが、現在および計画されている用途は、より明確に切り分けられるべきです。そうでなければ、読者は発表された機能と、すでに稼働しているものを簡単に混同してしまいます。

Newtonで私が最も気に入ったのは、アクションが起きようとしている瞬間に条件をチェックすることに重点を置いている点でした。

セキュリティ監査は、コントラクトが意図どおりに動くかを調べられますが、将来のあらゆる市場状況、データの障害、取引の異常な連なりを予測することはできません。ランタイムのポリシーは、いまの条件下で、その操作が安全で許可されているかどうかを問いかけることで、もう一つの層を追加します。

これは監査に代わるものではありません。問題の別の部分に対処しています。

私も、アプリケーションのメインコントラクトとポリシーロジックが分離されている点が気に入りました。リスク上限やビジネス要件は時間とともに変わります。可能なあらゆるルールをコアコントラクト内に恒久的に埋め込んでしまうと、更新が難しくなります。別のポリシーレイヤーがあれば、アプリ全体を作り直さずに、いくつかの条件を変更できるかもしれません。

ただし、この柔軟性にはそれなりのリスクもあります。もし1人の管理者が、制限的なポリシーをこっそりと許容的なポリシーに置き換えられるなら、分散型の評価はあまり保護になりません。ポリシーを更新できるのは誰なのか、更新には遅延があるのか、ユーザーにはどう通知されるのか、そして古いバージョンは公開レビュー用に残るのか——そうした点を知りたいです。

外部データも、私が何度も立ち戻ってしまう別の制限です。Newtonは、ポリシーが正しく評価されたことは証明できるかもしれませんが、評価に使われた情報が正確だったことは保証しません。データ提供者がウォレットを誤ってフラグ付けすれば、ポリシーは正当な取引を拒否するかもしれません。価格フィードが遅延したり操作されたりしていれば、正しく評価されたポリシーでも誤った結果が出る可能性があります。暗号学的検証は、どのような判断が行われたかは証明できますが、信頼できない情報を信頼できるものにすることはできません。

可用性も重要です。Newtonのオペレーターが応答できない場合、保護されたコントラクトはどうなるのでしょうか。すべての取引を拒否するほうが安全かもしれませんが、正当な活動まで凍結してしまう可能性があります。ポリシーチェックなしで取引を続行できるようにすると、セキュリティモデル全体が弱くなります。

プロジェクトは、オペレーターの停止、緊急事態、データ提供者の障害、そして争われたポリシー結果をどのように扱うのかを、明確に説明すべきです。

また、コストや応答時間についての情報ももっと見たいです。あらゆるセンシティブなアクションに認可チェックを追加すると、追加の作業が発生します。それは大規模なヴォルト送金なら許容できるかもしれませんが、頻繁で低額な取引では高くついたり遅くなったりする可能性があります。

ここで役立つのは実際の利用データです。アクティブなポリシーの数、独立したオペレーター数、保護されたコントラクト、認可リクエスト、拒否された取引、平均応答時間、平均コストが分かれば、提携発表だけを見るよりもはるかに多くのことが分かるでしょう。プロジェクトに時間を費やした後、Newtonに対する私の理解は変わりました。最初は、主に自動取引エージェントのためのプラットフォームだと思っていました。今では、エージェント、アプリケーション、キュレーター、そして組織が行動してよい境界を定義し、強制する試みなのだと見ています。

それは、私が最初に期待していたよりも面白い課題です。

主な問題は、自動化されたエージェントが判断を下せるかどうかだけではありません。そのエージェントが、現在の状況のもとでその判断を実行してよいのかどうかです。

Newtonの答えは、要求と最終取引の間にプログラマブルなポリシーを配置することです。そのアプローチのロジックは気に入っていますが、実運用の条件下でどのように機能するのか、もう少し根拠が必要です。

プロジェクトは、オペレーターネットワークが本当に独立していること、ポリシーが安全にガバナンスされ得ること、外部データを本当に信頼できること、そして認可チェックが日常的な利用に十分手頃なコストであることを示す必要があります。また、元々のエージェントのマーケットプレイスやロールアップ構想が、現在構築しているプロダクトとどう関係しているのかを説明する必要もあります。

私はNewtonを完成した解決策だとみなす準備ができていません。私が見つけたのは、現実で、しかもますます難しくなる問いに取り組む進行中のプロジェクトです。ソフトウェアがオンチェーンの価値を制御できるようにしたとき、その限界を誰が定め、どうやってその限界を強制できるのか。

@NewtonProtocol #Newt $NEWT #newton #newtonprotocol