ほとんどのAIアプリケーションの対話は早すぎる段階で止まってしまいます。それらは「アプリが生成された」瞬間で止まります。

これは第一波の中では合理的でした。一年前、プロンプトが実行可能なインターフェースに変わるのを見ていること自体が、すでに全体の注目を集めるものでした。今日、開発者たちは自然言語がソフトウェアを生成できることを理解しています。より難しい問題は、生成されたアプリケーションの後に何が起こるかです。

それは実際のユーザーのために動作するのでしょうか？
それは安全にタスクを実行できるのでしょうか？
それはコストを計測し、価値に応じて請求し、証明書を発行できるのでしょうか？
開発者はそこから収益を得ることができるのでしょうか？
ユーザーは盲目的にランダムなアプリのリストに頼らずにそれを見つけることができるのでしょうか？

X-Agentでは、私たちが繰り返し戻るのはこの境界線です：創造は必要ですが、創造だけではエージェントアプリを本当の製品にすることはできません。欠けている層は、「構築が完了した後」に起こるすべてのことです。

要約

次のプラットフォームレベルの問題は、より多くのAIアプリを生成することではなく、生成されたエージェントアプリを実行可能で配布可能、かつ収益を上げられる製品に変えることです。構築パス（Build Path）と実行パス（Runtime Path）は、異なる2つのシステムとして扱われるべきです。前者はアプリを構築し、後者は実際のユーザーがそれを操作することを可能にします。

エージェントアプリの支払いは、実行自体に結びつくべきです——予算、計測、確認、決済、証明書、そして紛争処理のパスを含みます。エージェントストアと成長は、厳選された配布と実際の使用信号から始まるべきであり、空の市場リストからではありません。

構築パスは製品の半分に過ぎない

構築パスは、現在ほとんどの人が認識している部分です。クリエイター → スタジオ → ハーネス（実行フレームワーク） → サンドボックス → デプロイされたエージェントアプリ。クリエイターは自分が何を望んでいるかを説明し、システムはその意図を解釈し、アプリを生成し、サンドボックスでプレビューし、デプロイに進みます。

これはすでに非常に価値があります。これは、過去に非エンジニアを妨げ、エンジニアの構築作業を遅らせていたものを取り除きました：リポジトリ構造、環境設定、プレビューサイクル、デプロイの詳細、そして最初のアプリケーションのスキャフォールディングの構築。しかし、ここで止まってしまうと、私たちは本質的に「供給をより良く創造する」方法を持っているだけです。より多くの開発者がより多くのアプリを生み出し、より多くのアイデアがデモ段階に進み、より多くのプロトタイプが共有されることは、「製品」という問題には答えていません。生成されたアプリには、依然としてユーザー、タスク、状態、権限、価格設定、信頼、配布が必要です。

これが、私たちが構築パスと実行パスを区別する理由です。

実行時は、アプリが本当に役立つ場所です

実行パスは、アプリのデプロイが完了した後から始まります。ユーザー → エージェントアプリ → エージェント対話 → ツール/状態/ウォレット/支払い → 結果。このパスはエンドユーザーにサービスを提供し、クリエイターには提供しません。デプロイされたエージェントアプリは、単なるAIラベルの付いた静的ページであってはなりません。ユーザーはこのアプリを開き、意図を表現し、詳細を追求し、ワークフローをトリガーし、状態を照会し、ツールを呼び出し、タスクの結果を得ることができるべきです。

この言葉は明白に聞こえますが、実際にそれを構築し始めるまでそう感じることはありません。

構築時のエージェントと実行時のエージェントは、異なる2つの作業です。構築時のエージェントはアプリの作成を支援し、実行時のエージェントはユーザーがアプリを操作するのを支援します。これら2つの役割を同じ冗長なプロンプトに詰め込むと、システムは推論が難しくなり、安全性を保証することが難しくなり、収益を上げることも難しくなります。

実行時は、ユーザーとの独自の「契約」を確立する必要があります。このアプリがどの状態を読み書きできるかを知る必要があります；どのツールが利用可能かを知る必要があります；どの操作が安価で可逆的であるか、どの操作が高価で外部システムに関与するか、またはリスクがあるかを知る必要があります；いつ確認を要求すべきかを知る必要があります；そして監査証跡を残す必要があります。

これが「モデルが答えを出した」と「アプリがタスクを完了した」との違いです。

具体的な例：リード分析は単なるプロンプトではない

シンプルなエージェントアプリの例として、イベントやマーケティングキャンペーン終了後のリード分析があります。プロンプトだけのバージョンは非常に一般的です：ユーザーがリードリストを貼り付け、モデルにそれらをソートさせます。モデルは表を返し、評価や提案されたフォローアップのスクリプトを伴うかもしれません。役に立ちますが、完全ではありません。

実行可能なエージェントアプリは、ワークフローの残りの部分を処理する必要があります：

フォーム、スプレッドシート、CRM、またはイベントシステムからリードをインポートする；
フィールドを標準化し、元のソースを保持する；
モデルを使用して分類し、オプションで強化APIを呼び出してデータを補完する；
どの外部呼び出しが費用を発生させるかをマークする；
メッセージを送信する前やCRMに書き戻す前に確認を要求する；
誰がこの操作を承認したかを記録する；
何が請求され、何が消費され、何が結果として得られたかを示す；
タスクが失敗した場合、返金、再試行、または紛争処理をサポートする。

これが多くのAIアプリが静かに崩壊する場所です。モデルは次に何をすべきかを提案できますが、製品層は権限、実行、コスト、責任を担う必要があります。この製品能力の層が、私たちが言う「実行時（Runtime）」です。

実行には契約が必要です

私たちは「エージェント実行」がモデルに無限の権限を与えることを意味するとは考えていません。より良いモデルは、より収束すべきです：ユーザーの意図 → モデルが提案するソリューション → 実行時の検証 → ツールの実行 → 監査記録。モデルは理解と計画を担当し、実行時は検証と実行を担当します。

実際に意味のある操作に対して、実行時は「実行契約（Execution Contract）」を構築できる必要があります。これは必ずしもインターフェース上で見える文書ではなく、プラットフォームに「次に何が起こるか」を知らせる内部オブジェクトです。

実行契約は次のことに答えるべきです：

支払い者（payer）：誰が支払うのか；
エージェントアプリ（agentapp）：どのアプリが実行されているのか； 開発者（builder）：このアプリは誰が作成したのか； タスク（task）：どのタスクが実行されているのか； 価格設定（pricing）：このタスクはどのように価格が設定されるのか； 予算上限（budgetcap）：許可される最高コストはいくらか；
確認（confirmation）：ユーザーの確認が必要か；
計測（metering）：何を測定すべきか；
決済（settlement）：支払いはどのように決済されるのか；
監査（audit）：実行プロセスはどのように追跡されるのか。

ユーザー体験の面ではシンプルに保つことができます：

「このタスクは最高で0.50ドルかかる可能性がありますが、続行しますか？」

しかし、バックエンドはそんなにシンプルではありません。ユーザーがこのタスクを承認したか、どれだけの予算を予約したか、どのツールを呼び出したか、実際の実行コストはいくらか、タスクは完了したか、どのような証明書を発行すべきかを知る必要があります。この契約がなければ、支払いは単なるチェックアウト画面になります；それがあれば、支払いは実行プロセスの一部になります。

支払いはチェックアウトボタンではない

エージェントアプリにとって、支払いは製品の外側に無理に貼り付けられるべきではありません。エージェントが本当に作業を始める瞬間から、コストと価値は実行時の問題になります。いくつかの操作はモデルのトークンを消費し、いくつかは有料APIを呼び出し、いくつかは計算、ストレージ、検索、データサービスプロバイダー、デプロイインフラストラクチャ、またはサードパーティサービスを使用し、いくつかの操作は直接商業的価値を生み出します。

したがって、支払いの問題は単に「カードを使うか、ウォレットを使うか？」ではありません。

むしろ：

誰がこのタスクを開始したのか？
誰がこの予算を承認したのか？
何のリソースが消費されたのか？
結果は完了したのか？
いくら請求すべきか？
収益はどのように分配されるべきか？
タスクが失敗した場合はどうなるのか？
何が起こったかを証明する記録はあるのか？

これが、私たちがエージェントアプリの支払いを「エージェント商業層（Agent Commerce Layer）」と見なす理由です。実用的な「実行-商業」状態機械はおおよそ次のようになります：見積もり → 認可 → 予約 → 実行 → 計測 → 決済 → 証明書の発行 → 分配 → 返金/紛争処理。

ほとんどのユーザーはこの全体のメカニズムを見る必要はありません。彼らは明確なコストの境界と明確な結果だけを見るべきです。例えば、リード分析型エージェントアプリの典型的な価格戦略は次のようになるかもしれません：

無料枠：最初の10回の実行は無料；
価格単位：タスクごと；
タスク価格：リードのバッチごとに3ドル；
予算上限：各タスクに許可される最高の内部コスト；
外部コストが直接転嫁されるか：はい/いいえ；
確認が必要か：外部メッセージを送信する前やCRMに書き込む前に必要。

（これらの数字は製品モデルの例であり、X-Agentが現在公開している実際の価格ではありません。）

開発者は元のトークンコストを計算する必要はなく、ユーザーもすべての内部計測指標を見る必要はありません——プラットフォームは実行プロセスをユーザーが理解できる価格設定に翻訳するべきです。初期段階では、実用的な出発点はシンプルです：無料枠 + 使用量上限 + タスクSKU。使用量に基づく価格設定は、モデル呼び出し、API呼び出し、検索、ストレージ、計算に適用されます；タスクに基づく価格設定は、リードの分析、ページの生成、アプリのデプロイ、レポートの生成、データセットの要約、または明確に定義されたワークフローの実行など、動作が明確なシナリオに適用されます。

セッションやサブスクリプションに基づく価格設定は、高頻度で使用されるツールに適しています。結果に基づく価格設定は魅力的ですが、後回しにすべきです——ほとんどのエージェントアプリが商業的結果に基づいて請求できるようになる前に、帰属、リスク、信頼、責任の認定、紛争処理メカニズムが十分に強化される必要があります。

抽象的な支払いチャネル、実行契約を保持する

支払いチャネルは製品体験を定義すべきではありません。ユーザーが購入するのはタスクの結果であり、支払い契約そのものではありません。開発者が知りたいのは：

このエージェントアプリはどのように価格設定されるべきか？
誰が支払うのか？
コストはどのように管理されるのか？
開発者の収入はいつ現実のものになるのか？
タスクが失敗した場合はどうなるのか？

彼らは、基盤となるチャネルがクレジットカード、Apple Pay、プラットフォームポイント、請求書、ステーブルコイン、ウォレット、または何らかのエージェント対エージェントの支払い契約であるかを気にする必要はありません。製品のレベルでは、これらの概念はシンプルに保たれるべきです：残高、ポイント、請求書、ウォレット。

そして、基盤では、さまざまな支払いチャネルが共存できます：

主流ユーザー向けのクレジットカードやApple Pay；
一般的な有料タスク向けのプラットフォームポイント；
企業顧客向けの請求書や前払いポイント；
Web3ネイティブユーザー向けのウォレットやステーブルコインチャネル；
エージェント対エージェントシナリオ向けの権限予算と自動決済。

新興インフラの例には、エージェントウォレット（agentic wallet）、x402のような有料呼び出しプロトコル、ステーブルコイン決済、プログラム可能な支払いシステムが含まれます。これらはすべて同じ方向を指しています：ソフトウェアは実行時レベルで機能する支払いチャネルを持つ必要があります。これは、すべてのエージェントアプリが暗号通貨を使用しなければならないという意味ではなく、アプリケーション層は支払いチャネルを抽象化し、その上に実行契約を保持するべきだということです。

異なるユーザーは異なる支払いチャネルを必要としますが、契約自体は一貫しているべきです。

配布もまた、実行時の問題の一部です。

一度作成が容易になると、配布は難しくなります。AIの構築者はアプリの供給量を増やしますが、これはユーザーが適切なアプリを見つけられることを意味するわけではなく、構築者が自らの創造物から利益を得られることを意味するわけでもありません。エージェントアプリのエコシステムには、単なる公開アプリのリスト以上のものが必要です。それは発見メカニズム、信頼メカニズム、ランキングメカニズム、インセンティブメカニズム、使用フィードバックを必要とし、同時に実行時のリスクを理解する必要があります。

一般的なアプリストアは大体次のことを尋ねます：

これはどんなアプリですか？
誰が開発しましたか？
インストールできますか？
評価はどうですか？

しかし、エージェントストアはもっと多くのことを尋ねる必要があります：

このエージェントアプリは何を実行できますか？
どんな権限が必要ですか？
どのツールを呼び出せますか？
使用するのにいくらかかりますか？
どのようなタスクを完了しましたか？
それが本当に役立つことを証明する使用信号はありますか？
支払いまたは証明の履歴はありますか？
この構築者の信用はどうですか？
誰が配布を手伝ったり、コンテンツを選別していますか？

これは製品の方向性であり、すべての構成要素が今日成熟しているわけではありません。私たちの見解は、エージェントストアは空のオープンマーケットを出発点とすべきではなく、「高品質のエージェントアプリに対して選ばれた配布と成長支援を提供する層」から始めるべきだということです。これは、高品質のアプリを選び、初期の露出、運営活動、実際の使用状況の検証、効果的な配布行動への報酬を提供し、同時に低品質または虚偽のアクティブデータをフィルタリングすることを意味します。

成長メカニズムは助けになる可能性がありますが、前提としてそれは実際の使用に結びついている必要があります。推薦報酬、タスク活動、ランキング、エコシステムインセンティブ——これらのメカニズムは、ユーザーを問題を解決できるエージェントアプリに導くときにのみ意味があります。そうでなければ、それらは単にトラフィックを生み出すだけで、信頼をもたらすことはありません。

構築者経済のフライホイール

ビジネスチャンスは、構築、実行時、支払い、配布がつながったときに現れます。

構築者がエージェントアプリを作成する
→ ユーザーがそれを発見し使用する
→ 実行時に実行プロセスを測定する
→ ユーザーが有用なタスクに対して支払う
→ 構築者の収入が可能になる
→ 推薦者またはコンテンツキュレーターが配布を手伝う
→ 実際の使用データがランキングとテンプレートを改善する
→ さらに多くの構築者が参加する

支払いは製品使用に結びつき、配布は実行品質に結びつき、構築者のインセンティブは実行時の測定に結びつきます。このメカニズムを本当に機能させるためには、プラットフォームは最終的に真の帳簿（ledger）を必要とします。意味のある支払い実行があるたびに、次のことを記録できるべきです：

総料金額(grosscharge) モデルコスト(modelcost)
ツールコスト(toolcost) インフラコスト(infracost)
支払い手数料(paymentfee) プラットフォーム料金(platformfee)
構築者収入(builderrevenue) 推薦報酬(referrerreward)
返金額(refundamount) 決済状況(settlementstatus)

この基盤がなければ、収入分配、返金、企業請求、詐欺防止管理、税務申告、送金、監査は非常に脆弱になります。それがあれば、エージェントアプリは真の経済単位となります：構築者はアプリを公開でき、ユーザーは有用なタスクに対して支払うことができ、コンテンツキュレーターは配布を手伝い、プラットフォームは実行品質に基づいてアプリをランキングします。これが「アプリ生成」から「エージェントアプリの商業化」への転換です。

X-Agentの位置はどこにあるか

X-Agentは「エージェントアプリ層」として構築されています。

それは基盤モデルを置き換えるつもりはなく、クラウドサービスプロバイダーを置き換えるつもりもなく、ウォレットインフラを置き換えるつもりもなく、ただのプログラミングエージェントでもありません。私たちが構築している技術スタックは大体次のようになります：

基盤モデル
→ ビルダー / ハーネス（構築者/実行フレームワーク）
→ セキュア実行時 / ツール / ウォレット
→ エージェントアプリ
→ ストア / 配布 / 成長

基盤モデルはインテリジェンスを提供します;
ビルダーと実行フレームワークは意図をアプリに変換します;
セキュア実行時、ツール、ウォレット、支払いシステムは実行の境界を定義します;
エージェントアプリは実際のユーザーを対象とします;
ストア、配布、成長システムは高品質のエージェントアプリがスケールされたユーザー採用を得るのを助けます。

重要なのは、今日のすべてのピースが完成しているわけではなく、エージェントアプリがこの一連の完全なライフサイクルを経る必要があるということです：作成 → デプロイ → 実行 → 測定 → 課金 → 決済 → 配布 → 反復改善。もしプラットフォームが人々にアプリを作成する手助けだけをしているなら、それは「アプリビルダー」という層で競争しているだけです; もしそれがウォレットだけを提供しているなら、それは単なるインフラです; もしそれが成長活動だけを運営しているなら、それは単なる配布ツールです。

そしてエージェントアプリ層は、これら三者をつなげています。

生成されたアプリからエージェントビジネスへ

AIソフトウェアの第一段階は、インテリジェンスに焦点を当てています——質問に答え、推論し、生成し、支援を提供できるモデルです。次の段階は、実行に焦点を当てています——ツールを使用し、状態を管理し、タスクを完了できるエージェントアプリです。さらに次の段階は、経済に焦点を当てています——発見され、価格が付けられ、支払いされ、配布され、実際の使用を通じて改善されるエージェントアプリです。

生成されたアプリは、この変換チェーンの出発点に過ぎず、製品の終点ではありません。AIアプリの未来は、「どれだけ多くのデモを生成できるか」ではなく、「どれだけ多くのエージェントアプリが実際のタスクを実行し、実際のユーザーに届き、実際の経済活動を維持できるか」によって定義されます。

これがまさにX-Agentが構築しているアプリ層の方向性です。

もしあなたがエージェントアプリ、インテリジェントウォレットインフラを構築している、またはAIネイティブソフトウェアの配布チャネルを構築しているなら、X-Agentに注目して、実行時、商業化、配布に関する構築ノートをもっと取得してください。