この記事ではAIエージェントを前提に設計するアプリ基盤に特化して解説します。AIエージェント全般の地図は AIエージェントフレームワーク比較2026年版 をご覧ください。
Agent-Nativeとは何か：チャット後付けを終わらせるアプリ基盤
Agent-Native は、Builder.io が公開したオープンソースのアプリケーションフレームワークです。GitHubスター約3,061、TypeScript製、ライセンスはMIT。一言でいえば「AIエージェントを後付けのチャットではなく、一級のユーザー・操作者として組み込んだアプリ（agent-nativeなアプリ）を作るための土台」です。READMEの冒頭は次のように宣言しています。「Agent-Native is an open-source framework for building robust agents that act inside real apps, not just chat next to them」——つまり「アプリの横でチャットするだけのエージェントではなく、アプリの中で実際に動くエージェント」を作るためのものです。
この記事を読むあなたが知りたいのは、おそらく3つに絞られます。①このAgent-Nativeは結局何ができるのか、②何を解決するのか、③既存のどの構成を代替できるのか。先に結論を言うと、①1つの「Action」を定義するだけでUI・エージェント・API・MCP・A2A・CLIのすべてから同じ処理を呼べるようになり、②UIとAIで状態が二重管理されてズレる「チャット後付けアプリ」の構造的な問題を解決し、③固いSaaSツール・UIのない生のAIエージェント・保守の重い社内ツールという既存3択を一本化して代替します。
なぜ今これが必要なのか。ここ数年、多くのWebアプリは「AI対応」をうたって右下にチャットウィジェットを貼り付けてきました。しかしその実体は、人間が使う本体UIの横にLLMを置いただけで、エージェントは本体の機能をAPI経由で間接的に叩く「外部者」にすぎませんでした。結果として、UIで起きた変更とAIが行った変更で状態がズレたり、AIがアプリの一部の操作しかできなかったり、AIに新しい機能をやらせるたびに人間がコードを書き足す必要があったりします。Agent-Nativeはこの構造そのものを作り変えます。「the agent and the UI are equal citizens of one system（エージェントとUIは1つのシステムの対等な市民）」という公式の表現が、この設計思想を端的に表しています。
・何ができる：処理を1回だけ定義すれば、人間がボタンで実行しても、エージェントが会話で実行しても、外部システムがMCP/A2A/HTTPで呼んでも、同じ1本の処理が走る
・何を解決する：UIとAIの状態の二重管理・ズレ、エージェントがアプリの一部しか操作できない問題、AI機能追加のたびに発生する手作業
・何を代替する：チャットを貼り付けただけの「AI対応Webアプリ」の自前実装、UIを別途用意する必要があった生のエージェント基盤
Builder.ioはもともとVisual CMS・ビジュアル開発ツールの会社で、UIとコードの橋渡しを長年やってきた企業です。その知見が「UIとエージェントを対等に扱う」という今回のフレームワークの設計に色濃く出ています。
agent-nativeなアプリとは何か：従来のWebアプリとの決定的な違い
「agent-native」という言葉を正確に理解するのが、このフレームワークを使いこなす出発点です。agent-nativeなアプリとは、AIエージェントを「一級のユーザー／操作者」として最初から設計したアプリを指します。エージェントがチャットの中に閉じ込められた来訪者ではなく、人間ユーザーとまったく同じ権限・同じ操作経路でアプリを動かせる、という意味です。
READMEの「Agents and UIs, Fully Connected」セクションが、この違いを具体的に5点で説明しています。これがagent-nativeなアプリが何を解決するかの核心です。
・Everything syncs（すべてが同期）：データベースは1つ、状態は1つ。UIから変更してもエージェントから変更しても、もう一方に即座に反映される。状態の二重管理が原理的に発生しない
・Real-time multiplayer（リアルタイム共同編集）：人間とエージェントが同じドキュメントを一緒に編集できる。エージェントは一級のピア（対等な参加者）として振る舞う
・Context-aware（文脈を理解）：エージェントはあなたが今見ているものを把握している。テキストを選択して Cmd+I を押し、やってほしいことを伝えるだけでよい
・Agents call agents（エージェントがエージェントを呼ぶ）：任意のアプリから別のエージェントにタグを付ければ、A2A（Agent-to-Agent）でエージェント同士が連携する
・Self-improving（自己改善）：エージェントが機能を追加し、バグを直し、UIを時間をかけて洗練させていける
従来のWebアプリでは、これらを実現しようとすると地獄のような実装になります。UI側の状態管理（React stateなど）、AI側が叩くAPIエンドポイント、両者の整合性をとる同期処理、認証の二重チェック——これらをすべて自前で配線しなければなりません。Agent-Nativeは「データベースは1つ・状態は1つ」というアーキテクチャを前提に置くことで、この配線作業そのものを不要にします。人間がクリックする操作も、エージェントが会話で頼む操作も、内部的にはまったく同じ1本の経路を通る——これがagent-nativeの一番おいしいところです。
ここで重要なのは、agent-nativeは「ノーコードでAIアプリが作れる魔法」ではない、という点です。あくまでTypeScriptでアプリを書くフレームワークであり、エンジニアが対象です。ただし、その上で動くエージェント自身がアプリを改修できるため、運用フェーズでの拡張は人間とエージェントの協業になる、という新しいモデルを提示しています。
具体的なユーザー体験で言い換えると、こうなります。あなたがドキュメントを編集している最中に、気になる段落を選択して Cmd+I を押し、「ここをもっと簡潔に」と頼む。エージェントはあなたが今その段落を見ていること（コンテキスト）を把握しているので、画面の文脈に沿って即座に書き換える。同時に、別のエージェントを @ でタグ付ければ、そのエージェントがA2A経由で呼ばれて、たとえばファクトチェックを並行で走らせる。これらの編集はすべて同じデータベースの同じドキュメントに対して行われるため、人間の編集とエージェントの編集が衝突せずリアルタイムで混ざり合います。「チャットの返信をコピペして本体に貼り戻す」という、現在のAIチャット利用で誰もがやっている退屈な往復作業が、構造的に消えるわけです。
逆に言えば、agent-nativeでないアプリでこの体験を実現しようとすると、フロントの状態管理・WebSocketによるリアルタイム同期・AIのfunction calling・権限の二重チェック・楽観的ロックによる衝突解決……といった重量級の実装を全部自前で書く必要があります。Agent-Nativeはこれらを「1つのシステムの対等な市民」という前提に畳み込むことで、開発者が書くべきコードを劇的に減らします。これが「何を解決するか」の最も実感しやすい部分です。
Actionsの仕組み：1回定義してUI・エージェント・MCPで使い回す
Agent-Nativeの中核プリミティブが Actions です。これがフレームワーク全体で何ができるかを決定づける最重要概念なので、丁寧に見ていきます。READMEのトップに置かれたコードが、Actionの本質を一発で示しています。
// One action powers UI, agent, HTTP, MCP, A2A, and CLI.
export default defineAction({
schema: z.object({
emailId: z.string(),
body: z.string(),
}),
run: async ({ emailId, body }) => {
await db.insert(replies).values({ emailId, body });
},
});
たったこれだけです。defineAction で「入力スキーマ（zod）」と「実際の処理（run）」を1回定義すると、コメントが宣言する通り このAction1つが UI・agent・HTTP・MCP・A2A・CLI のすべてから呼ばれる ようになります。メール返信を作る処理を例にとると、次のように同じ処理が複数の入口から走ります。
・UIから：ユーザーが返信ボタンを押すと、このActionが呼ばれてDBに返信が挿入される
・エージェントから：「このメールに『了解しました』と返信して」と頼むと、エージェントが同じActionをツールとして呼ぶ
・HTTP APIから：外部システムがエンドポイント経由で同じActionを叩ける
・MCPから：Model Context Protocolのツールとして公開され、他のAIクライアントから利用できる
・A2Aから：別のエージェントがエージェント間プロトコルでこのActionを呼べる
・CLIから：ターミナルから直接Actionを実行できる
ここが従来のアーキテクチャと根本的に違うポイントです。普通のWebアプリでは、ボタンのクリックハンドラ、REST APIのコントローラ、AIのfunction calling用ツール定義、CLI用のスクリプト——同じ「メール返信を保存する」処理を、入口の数だけ別々に書いて、それぞれでバリデーションと権限チェックを重複させていました。Agent-Nativeでは、処理は1か所、入口は自動。「Define work once. Use it from UI, agent, API, MCP, A2A, and CLI」というREADMEの一文がそのまま実装思想です。
この「Action中心設計」がもたらす実利は大きく3つあります。第一に、バリデーション（zodスキーマ）とビジネスロジックの重複がゼロになるため、入口ごとに挙動がズレるバグが構造的に消えます。第二に、新しいActionを1つ足すだけで、人間UIにもエージェントにもMCPツールにも同時に機能が増えます。第三に、db.insert(...) のようなデータ更新経路が1本に集約されるので、状態の整合性が保たれます。前のセクションで説明した「状態が1つ」が成立する技術的な裏付けが、このActionの仕組みなのです。
ここで「MCP」「A2A」という言葉に馴染みのない読者のために補足します。MCP（Model Context Protocol） は、AIモデルに外部のツールやデータを安全につなぐための標準プロトコルで、Actionを defineAction で定義すればそのままMCPツールとして公開され、対応する任意のAIクライアントから呼べるようになります。A2A（Agent-to-Agent） は、エージェント同士が直接やり取りするためのプロトコルで、これによりあるアプリのエージェントが別のアプリのエージェントの能力（=Action）を呼び出して連携できます。従来であれば、エージェント向けにツールを公開するにはMCPサーバを別途実装し、エージェント連携にはまた別の仕組みを用意する必要がありました。Agent-Nativeでは、これらがActionを書いた時点で自動的に生える——つまりプロトコル対応のためのボイラープレートを書かなくてよい、というのが効いてきます。
実務上のインパクトをもう一段かみ砕くと、こうなります。たとえばSaaSの管理画面を作っていて「ユーザーを招待する」機能を実装するとします。普通なら、招待ボタンのUIハンドラ、POST /api/invite のAPI、AIアシスタント用のツール定義、運用スクリプト用のCLIコマンドを別々に書きます。Agent-Nativeなら inviteUser というActionを1つ書くだけで、画面のボタンも、エージェントへの「田中さんを招待して」という依頼も、外部システムからのAPI呼び出しも、ターミナルからの一括招待も、すべて同じ検証・同じ権限チェック・同じDB書き込みを通ります。コードベースが小さくなり、テスト対象が1か所に集約され、レビューも楽になる——地味ですが、運用が長くなるほど効いてくる種類の利点です。
エージェントランタイム：チャット・ツール・記憶・ジョブが最初から揃う
agent-nativeなアプリを作るには、Actionsだけでは足りません。エージェントを実際に走らせる「エージェントランタイム」が必要です。Agent-Nativeはこのランタイムを最初から一式同梱している点が、自前でエージェント基盤を組む場合と比べて圧倒的に楽なところです。READMEは「Agent runtime: Chat, tools, skills, memory, jobs, observability, and handoffs ship together」と明言しています。
同梱されるランタイム要素を、それぞれが何を解決するかとあわせて整理します。
・Chat（チャット）：エージェントとの会話インターフェース。会話を一から実装する必要がない
・Tools（ツール）：エージェントが呼べる道具。Actionsがそのままツールになるため、UI機能とエージェント能力が一致する
・Skills（スキル）：エージェントに与える定型的な振る舞い・手順のまとまり
・Memory（記憶）：会話やコンテキストをまたいで情報を保持する仕組み
・Jobs（ジョブ）：バックグラウンドで走る非同期処理。長時間タスクをエージェントに任せられる
・Observability（可観測性）：エージェントが何をしたかを観測・追跡する。本番運用で必須
・Handoffs（引き継ぎ）：エージェント間や、エージェントと人間の間でタスクを受け渡す
・Identity（認証・ID）：誰が操作しているか（人間かエージェントか、どのユーザーか）を扱う
これらが「ship together（一緒に出荷される）」というのが価値の本体です。自前でエージェントアプリを作る場合、チャットUIはこのライブラリ、ツール実行はあのフレームワーク、記憶はベクトルDB、ジョブはキューイングサービス、監視は別のSaaS……と寄せ集めて統合する作業が発生します。Agent-Nativeはこれを1つのランタイムにまとめているため、開発者が持ち込むのは次の4つだけで済みます。
// agent-native の設定イメージ（バックエンド非依存：DB・ホスト・モデルを持ち込む）
import { drizzle } from "drizzle-orm/...";
export default {
// ① 任意のDrizzle対応SQLデータベース（Postgres / SQLite / MySQL など）
db: drizzle(/* あなたの接続設定 */),
// ② Nitro互換のホスティング（デプロイ先）
// ③ 使いたいモデルスタック（任意のLLM）
// ④ アプリ固有のActions / UI / コード
};
READMEの「Backend agnostic: Plug in any Drizzle-supported SQL database and Nitro-compatible host」と「Bring your own database, hosting provider, model stack, and app code」がこの設計を支えています。特定のクラウドやベンダーにロックインされない——これがエージェントランタイムを丸ごと使えることと両立しているのは、運用を考えると見逃せない利点です。データ更新がSQLバックの状態（SQL-backed state）として管理されるため、エージェントの操作も人間の操作も同じデータベースに帰着します。
テンプレート：完成済みのOSS SaaSアプリを丸ごと所有する
Agent-Nativeのもう1つの強烈な特徴が、完成済みのSaaSアプリをテンプレートとして丸ごとクローンできる点です。READMEは「Each one is a complete, 100% free and open-source SaaS app: cloneable, not scaffolded, except you own the code and can customize everything」と説明します。ここで重要なのは「scaffolded（雛形生成）ではなく cloneable（複製）」という区別です。空っぽの骨組みを生成するのではなく、動く完成品を丸ごと手に入れて、そのコードを100%自分のものとして改造できる、という意味です。
READMEで紹介されているテンプレートは次の6つです。いずれもagent-nativeの設計を体現した実用アプリで、それぞれが何ができるかの生きた実例になっています。
・Clips：Loom + Jam のagent-native版。画面録画を自動文字起こし・ブラウザのデバッグログ付きで記録し、リンクを共有。エージェントが文字起こしを読み、タイムスタンプ付きフレームを見て、バグを直してくれる
・Plans：コーディングエージェント向けのビジュアルプランモード。/visual-plan と /visual-recap を導入し、エージェントが実装前に図・ワイヤーフレーム・注釈付きで計画し、変更後に差分を高レベルでレビューできる
・Design：agent-nativeなデザイン試作ツール。インタラクティブなHTMLプロトタイプを生成し、バリアントを比較・調整して結果をエクスポートできる
・Content：MDX向けのオープンソース版Obsidian。ローカルのMarkdown/MDXを編集し、リッチなカスタムブロックを生成、エージェントで下書き・書き換え・公開ができる
・Slides：agent-nativeなGoogle Slides／Pitch。プロンプトやポイント＆クリックでReactベースのプレゼンを生成・編集できる
・Analytics：agent-nativeなAmplitude／Mixpanel。分析データソースに接続し、プロンプトで本物のチャートを作り、再利用可能なダッシュボードを構築できる
しかも create 時に複数テンプレートを選べます。READMEの例では「Mail + Calendar + Forms を選ぶと、3つすべてが配線され、認証を共有した状態で手に入る」とあります。つまり複数の完成アプリを組み合わせて、認証を共有する1つのワークスペースとして起動できるわけです。これが「rented（借り物）」のSaaSではなく「you own the code（コードはあなたのもの）」である意義で、月額課金のSaaSに機能リクエストを送って待つのではなく、自分でコードを直せます。
これらのテンプレートは、単なるデモではなく「agent-nativeの設計が実アプリでどう機能するか」の教材としても優れています。たとえば Clips では、録画した画面の文字起こしとタイムスタンプ付きフレームが状態として保存され、エージェントがそれを読んでバグを修正する——という流れが、まさに「人間が録画する」「エージェントが同じデータを読んで直す」という対等な操作の具体例になっています。Analytics なら、分析データを取り込むActionと、チャートを生成するActionが定義され、人間がダッシュボードをポチポチ作っても、エージェントに「先月のサインアップ推移をグラフにして」と頼んでも、同じActionを通って同じダッシュボードに反映されます。テンプレートを読むことは、自分でゼロから書く前に「Action中心の設計とはこういうことか」を体で理解する最短ルートになります。全テンプレートの一覧は公式の agent-native.com/templates で確認できます。
何を代替できるか：SaaS・生エージェント・社内ツールの「いいとこ取り」
ここまでで Agent-Native が何ができて何を解決するかは見えてきました。最後に、③何を代替できるかを、READMEが用意している比較表「The Best of Both Worlds」に沿って明確にします。Agent-Nativeは「SaaSツール」「生のAIエージェント」「社内ツール」という既存3択のそれぞれの弱点を埋める位置づけで設計されています。
READMEの比較表を、当サイトで読みやすく再構成すると次の通りです。
| 観点 | SaaSツール | 生のAIエージェント | 社内ツール | Agent-Native |
|---|---|---|---|---|
| UI | 綺麗だが固い | なし | 品質はまちまち | フルUI付き・forkして即利用 |
| AI | 後付け | 強力 | 浅い接続 | AI一級・統合済み |
| カスタマイズ | できない | 指示・スキルで | フルだが保守が重い | エージェントがアプリを改修 |
| 所有 | 借り物 | ある程度自分のもの | コードは自分のもの | コードは自分のもの |
この表が示すのは、4つの観点すべてで満点を狙いに行くというAgent-Nativeのポジショニングです。具体的にどれを置き換えられるか、ケース別に整理します。
・SaaSツールを代替：綺麗だが融通の利かない既製SaaSに毎月課金し、欲しい機能を要望して待つ運用から、フルUI付きのテンプレを fork して自分で改造する運用へ
・生のAIエージェントを代替：強力だがUIがなく、運用に乗せるたびに画面・認証・状態管理を自前で用意していた構成を、UI・認証・状態が最初から揃ったランタイムへ
・社内ツールを代替：所有はできるが保守が重く、AIとの接続も浅かった内製ツールを、エージェント自身がバグ修正・機能追加できる「自己改善するアプリ」へ
さらに「アプリを丸ごと作らずに、いま使っているコーディングエージェントを少し強化したい」というニーズにも応えます。READMEはこの軽量な入口を提供しています。
# Claude Code / Cursor / Copilot などに /visual-plan と /visual-recap を1コマンドで追加
npx @agent-native/core@latest skills add visual-plan
これを実行すると、/visual-plan（エージェントがコードを書く前に、図・ワイヤーフレーム・ファイル単位の実装マップ・注釈付きのレビュー可能な計画を開く）と、/visual-recap（変更後にPRやgit diffを生の差分ではなく、共有可能なレビューリンク付きの俯瞰サマリに変える）の2つのスラッシュコマンドが手に入ります。Claude Code・Codex・Cursor・Pi・OpenCode・GitHub Copilot / VS Code など幅広いエージェントに対応しているので、フレームワークの世界観を最小コストで体験できます。
クイックスタート：1コマンドでagent-nativeアプリを起動する
最後に、実際にどう始めるかを見ます。Agent-Nativeはローカルでの立ち上げを1コマンドに集約しています。これがフレームワーク導入の入口で何ができるかを体感する最短ルートです。
READMEのQuick Startはこうです。
# 1コマンドで新規プロジェクトをローカルに作成
npx @agent-native/core@latest create my-app
cd my-app
pnpm install
pnpm dev
create を実行すると、まず「どう始めたいか」を聞かれます。ここが何を解決するかに直結する選択で、目的に応じて3つの開始方法から選べます。
・Full template(s)（フルテンプレート）：完成済みアプリを1つ以上、ワークスペースにクローンする。前述の通り Mail + Calendar + Forms を選べば、認証を共有した3アプリが配線済みで手に入る
・Chat（チャット）：最小限のチャットUIとブラウザシェルが配線済みの単一アプリ。UIを手早く立ち上げる最もシンプルな方法
・Headless（ヘッドレス）：UIシェルを持たない、Action中心の単一アプリ。CLIが最初のActionとエージェントの呼び出し方を案内し、UIは後から足せる
プロンプトを飛ばしてフラグで指定することもできます。
# フラグ指定で対話プロンプトをスキップする例
npx @agent-native/core@latest create my-app --template mail # メールテンプレで作成
npx @agent-native/core@latest create my-app --headless # ヘッドレスで作成
npx @agent-native/core@latest create my-app --standalone # スタンドアロンで作成
注目したいのは Headless の存在です。UIを持たず、Actionとエージェントだけから始められるということは、Agent-Nativeが「UIのおまけとしてのAI」ではなく「Actionとエージェントを核に置いた設計」であることの裏返しです。まずヘッドレスでActionを定義し、CLIやエージェントから動かして固め、必要になったらUIを後付けする——という、従来のWebアプリ開発とは順序が逆の作り方ができます。これこそが「agent-native（エージェントを前提に設計する）」という言葉の実践的な意味です。
なお開発の全体像をフローで捉えると、agent-nativeなアプリ開発は次のように回ります。
開始方法を選択
template / chat / headless"] --> B["Action を defineAction で定義
schema + run を1回だけ書く"] B --> C{"どの入口から
呼ぶ？"} C -->|人間| D["UI から実行
クリック操作"] C -->|エージェント| E["Agent がツールとして実行
会話で依頼"] C -->|外部| F["HTTP / MCP / A2A / CLI"] D --> G["SQL バックの状態を更新
DBは1つ・状態は1つ"] E --> G F --> G G --> H["UI とエージェントへ即同期
Everything syncs"] H --> I["エージェントが機能追加・バグ修正
Self-improving で進化"] I --> B
このループ図が示す通り、Action定義 → 複数入口からの実行 → 単一状態への集約 → 即時同期 → エージェントによる自己改善、という循環がagent-nativeアプリの基本サイクルです。人間とエージェントが同じ輪の中にいるのが、従来のWebアプリ開発との一番の違いです。
まとめ：Agent-Nativeは「AIを前提にしたアプリ」の標準を狙う
Agent-Native（BuilderIO/agent-native）は、AIエージェントを後付けのチャットではなく一級のユーザー・操作者として組み込んだアプリを作るためのOSSフレームワークです。最後に、読者の3つの問いへの答えをもう一度まとめます。
・①結局何ができる：1つのActionを定義するだけで、UI・エージェント・HTTP・MCP・A2A・CLIのすべてから同じ処理を呼べる。チャット・ツール・スキル・記憶・ジョブ・可観測性・引き継ぎを備えたエージェントランタイムが一式同梱され、6種類の完成済みSaaSテンプレを丸ごとクローンして所有できる
・②何を解決する：UIとAIで状態が二重管理されてズレる問題、エージェントがアプリの一部しか操作できない問題、AI機能を足すたびに発生する手作業を、「データベース1つ・状態1つ・入口は自動」という設計で構造的に解消する
・③何を代替する：固いSaaSツール・UIのない生のAIエージェント・保守の重い社内ツールという既存3択を、フルUI付きで即fork可・AI一級統合・エージェントがアプリ自体を改修できる単一の選択肢に置き換える
バックエンド非依存（Drizzle対応SQL＋Nitro互換ホスト＋任意のモデル）で、ライセンスはMIT、コードは100%自分のもの。「AI対応」を右下のチャットで済ませてきた時代から、「エージェントを前提にアプリを設計する」時代への移行を、具体的なプリミティブとして提示しているのがAgent-Nativeです。まずは npx @agent-native/core@latest skills add visual-plan で世界観を試すか、create my-app のヘッドレスでActionから書き始めてみてください。詳細は公式リポジトリと agent-native.com のドキュメントで確認できます。
よくある質問（FAQ）
Q1. Agent-Nativeとは何ですか？ Builder.ioが公開したOSSフレームワークで、AIエージェントを後付けのチャットではなく一級のユーザー・操作者として組み込んだアプリ（agent-nativeなアプリ）を作るための土台です。Actions・エージェントランタイム・SQLバックの状態管理などのプリミティブを提供します。
Q2. Agent-Nativeのライセンスは？ MITライセンスです。テンプレートも100%オープンソースで、生成したコードは自分のものとして自由に改変・商用利用できます。最新の条件は必ずリポジトリで確認してください。
Q3. Agent-Nativeは何を置き換えますか？ READMEの比較表では、固いSaaSツール・UIのない生のAIエージェント・保守が重い社内ツールの3者を置き換える位置づけです。フルUI付きで即forkでき、AIが一級として統合され、エージェント自身がアプリを改修できます。
Q4. 既存のデータベースやホスティングは使えますか？ はい。バックエンド非依存（backend agnostic）が設計方針で、Drizzleが対応する任意のSQLデータベースと、Nitro互換のホストを持ち込めます。モデルスタックやアプリコードも自分のものを使えます。
Q5. アプリを作らずに試す方法はありますか？
あります。npx @agent-native/core@latest skills add visual-plan を実行すると、Claude Code・Cursor・Copilotなどのコーディングエージェントに /visual-plan と /visual-recap のスラッシュコマンドを1コマンドで追加できます。
Q6. Agent-Nativeの始め方は？
npx @agent-native/core@latest create my-app を実行し、フルテンプレート・チャット・ヘッドレスの3つの開始方法から選びます。その後 pnpm install と pnpm dev でローカル起動できます。--template・--headless・--standalone フラグでプロンプトをスキップすることも可能です。
参照ソース
・BuilderIO/agent-native（GitHub公式リポジトリ） — README・コード・ライセンス（MIT）の一次ソース
・Agent-Native 公式サイト・ドキュメント（agent-native.com） — テンプレートギャラリー・Skills Guide・全ドキュメント
