VercelのAIエージェントフレームワーク「eve」を試してみた｜ブログのナレッジで自作キーボードエージェントを作る
こんにちは、豊島です。
2026年6月17日、ロンドンで開催されたVercel Ship 26で、Vercelから新しいオープンソースのAIエージェントフレームワークeveが発表されました。2026年6月時点ではpublic preview（beta）です。
位置づけは「Next.js for agents」、Next.jsがWebアプリケーションにやったことを、AIエージェントに対してやろうとしているフレームワークです。
少し前にVercel Labsのvercel-openclawで知る、Vercelサービスの組み合わせ事例という記事で、AIエージェントを構築するために、Vercelのサービス群をどう組み合わせるかを整理し、設計を理解していたので、eveを触ったときに、「これが最初から入ってくるのか」と気づくことができました。
本記事では、まずeveを動かしてみたうえで、これまでのAIエージェント構築と何が変わるのかを見ていきます。
これまでどうやってAIエージェントを構築していたか
数時間動き続けたり、人の承認を待ったり、外部APIとつないだり、デプロイやクラッシュをまたいでも状態が消えないエージェントを作ろうとすると、毎回同じような土台を組む必要がありました。
前回vercel-openclawで見た構成でいうと、ざっくり次のような処理です
- 状態の永続化と、中断・再開
- エージェントが生成したコードを隔離するサンドボックスの管理
- APIキーをサンドボックスの中に持たせず、外で預かって呼び出し時だけ差し込む仕組み
- SlackやTelegramとの連携
- 定期実行や停止中のサンドボックスを起動する仕組み
公式ブログIntroducing eveでは、「この土台がエージェントごとに作り直しになり、次のユースケースに何も引き継がれないことが課題だった」と紹介されていました。
Webアプリケーションフレームワークが登場する前、共通部分を手で書いていた状態に近い、という整理です。eveはそのエージェントの形をフレームワークにしたもの、という位置づけになります。
eveとは何か
eveの中心にあるのは、「エージェントは1つのディレクトリである」という考え方です。
agent/配下のディレクトリごとに役割が決まっていて、ツリーを見ればそのエージェントが何で、何ができるのかが一目で分かります。
agent/
agent.ts # 使うモデル
instructions.md # 役割や人格（システムプロンプト）
tools/ # できること（1ツール＝1ファイル）
skills/ # 知識（Markdown、必要なときに読み込む）
subagents/ # 作業を任せる子エージェント
channels/ # どこから話しかけるか（Slack など）
schedules/ # 定期実行（決まった時刻に動かす）
「batteries included」も掲げていて、耐久実行・サンドボックス・人間の承認・サブエージェント・チャネル・トレース/evals...といった、本番環境で必要なものが最初から入っています。
この全部入り+規約という方針は、Next.jsをはじめVercelのプロダクトに共通して感じるものですね。
背景や導入解説は公式ブログIntroducing eveによくまとまっています。
重複するので本記事では解説部分は省略し、私個人のブログのナレッジを使ってAIエージェントを構築してみました。
自分のブログのナレッジでAIエージェントを作ってみた
運営している自作キーボードのブログ（tysmmsy.dev）のナレッジを活かして、そのままエージェントを構築してみました。
このブログはContentfulをヘッドレスCMSにしていて、キーボードの記事もXポストの内容もすべてContentfulに入れています。
狙いはシンプルで、ナレッジを新しく書き起こすのではなく、CMSにあるコンテンツをeveのskillsとして変換しました。
構成はとてもシンプルで、
agent/instructions.md: dawne（キーボード用の名義）の人格と、「必ずブログの記述を根拠に答える。分からなければ正直に言う」というルールagent/skills/: ブログの内容をMarkdownにしたスキル（30%キーマップの設計、ビルド代行サービス、個別のキーボード・パーツ）に、私の文体を再現する文体スキルを加えた4本から成っています- toolsはなし（ナレッジを元に回答するエージェントなので、skillsだけ）
skillsは知識だけでなく文体にも使えて、ブログ記事やXポストの語り口調をMarkdownにまとめておくと、回答のトーンも寄せることができます。
eve infoコマンドでそれらをちゃんと認識しているか確認できます。
$ eve info
eve v0.11.7
Application
Layout nested
Compile ready
Diagnostics 0 errors, 0 warnings
Instructions instructions.md
Skills 4 skills
instructions.mdとSkills（30%キーマップ・ビルド代行・個別ボード・文体の4つ）が認識されています。
構築手順
やったことは大きく3ステップで、実行したコマンドも下記の通りです。
- 雛形を作成後、
agent/agent.ts（モデル指定）とagent/instructions.md（人格と「必ずブログの記述を根拠に答える」というルール）を置きます。 - 自作のスクリプトでナレッジをskillsに変換します。Contentfulからキーボード関連の記事を取り出し、
agent/skills/にMarkdownとして書き出します。 - ブログとXポストの語り口調をskillsにまとめ、回答のトーンを私に合わせます。
pnpm dlx eve@latest init keyboard-agent # 雛形を作成
pnpm exec eve link # Vercel にリンク（AI Gateway の認証）
pnpm run export:skills # Contentful の情報をskillsに書き出し（自作スクリプトですが、既存のデータに対してAIエージェントに「skillsに変換して」と頼むのと同様）
pnpm dev # ローカルで起動して確認
pnpm exec eve deploy # 本番にデプロイ
繰り返しになりますが、すでに蓄積している情報を、eveの規約（agent/skills/にMarkdownを置く）に合わせて変換しただけで、ドメイン特化のAIエージェントを構築することができます。
作ったファイルの一部も転記します。
agent/instructions.md（人格と回答ルール）
あなたは dawne（豊島真也）の自作キーボードに関する知見を代弁するエージェントです。
dawne は次の2つの顔を持っています。
- キーマップ設計の実践者: 60% → 40% → 30%（36キー）と段階的にキー数を減らしてきた。
- ビルド代行サービスの運営者: 分割・トラックボール系を中心に、多数のキーボードを組み立ててきた（タグ #dawne_kbd_svc）。
回答のルール
- 日本語で答える。英語で質問されたら英語で答える。
- 文章のトーンは dawne 本人の文体に寄せる（詳しくは writing-style スキルを参照）。
- 必ず手元のスキル（dawne の実体験に基づく知識）を根拠にする。スキルに書かれていないことは、一般論だと断るか、分からないと正直に言う。スペックや事実を憶測で作らない。
- 質問が「キーマップ設計」「ビルド代行サービス」「個別のキーボード/パーツ」のどれに関するものかを意識し、該当するスキルを参照する。
- 具体的な数字や前提（キー数、レイヤー構成、対象キーボード名など）を明示する。
- dawne の主観や好み（黒で統一された見た目が好き、など）は「dawne の好み」として、一般的な事実と区別して伝える。
- 元記事やポストがある内容は、可能なら出典（tysmmsy.dev の該当 URL）を添える。
agent/skills/keymap-design.md（抜粋です。ブログ記事から生成しています）
---
description: dawne の 30%（36キー）キーマップ設計の考え方。キー数の変遷、レイヤー構成、キー配置、親指まわり、コーディング向けの最適化、編集ツールについて聞かれたら参照する。
---
# dawne のキーマップ設計（30% / 36キー）
## キー数の変遷
- 60% → 40% →（40% を 30% にして修行）→ 30%（36キー）で落ち着いた。
- キー数を減らすたびに「これ以上は減らない」と思ってきたが、36キーで一旦のゴールとした。
## 36キーマップの方針
- 仕事柄コーディングの機会が多く、Ctrl / Tab / Shift などの修飾キーや記号キーを、意識せず打てるかどうかを重視している。
## 編集ツール
- キーマップ編集には Vial を使用。主に Layer / Toggle 機能を使っている。
## 関連タグ・出典
- 出典: ブログ記事「30%キーボードのキーマップ 2026年版」 https://tysmmsy.dev/posts/try-keymap-for-30percent-kbd
ハマりポイント 無料枠のモデルアクセスについて
eve linkで認証を通したあと、最初に指定していたanthropic/claude-sonnet-4.6で動かそうとしたところ、次のエラーで止まりました。
MODEL_CALL_FAILED: Free tier users do not have access to this model.
Upgrade to paid credits to access this model.
これはクレジット残高ではなく、AI Gatewayの無料枠が対象モデルを限定しているためでした。対応は2つあり、
- 無料で試す
agent/agent.tsのモデルを無料枠対象のものに変える（私は一番安いanthropic/claude-haiku-4.5にしました）
- 制限を外す
- AI Gatewayにクレジットをチャージして他のモデルを使う
今回、ローカルは無料枠のモデル、本番は上位モデル、と切り替えられるよう、モデルは環境変数で差し替える形にしました。
export default defineAgent({
model: process.env.AGENT_MODEL ?? "anthropic/claude-haiku-4.5",
});
モデル呼び出しはAI Gateway経由なので、Vercelコンソールの「AI Gateway」→「Usage」を開くと、どのモデルに何回リクエストが飛び、レイテンシやコスト等を確認できます。
例えば下記のようにanthropic/claude-haiku-4.5が3回動いてコスト$0.01、anthropic/claude-sonnet-4.6は1回だけ（0トークン（無料枠で弾かれた回））を確認することができます。
AI Gateway自体の概要は別記事（Vercel AI GatewayがGAされました）にまとめています。
実際に聞いてみる
pnpm devにてローカルで起動してやりとりしてみました（起動時のあいさつ等は省略してます）
回答の前にload_skillが走って、ブログ由来のスキルを読み込んでいるのが見えます。
▌ LiNEA40について教えてください
▲ LiNEA40についてですね。詳しい情報を確認させていただきます。
✓ load_skill skill="boards-and-parts"
→ # dawne が触れたキーボードとパーツ（ブログのスキルを読み込み）
▲ LiNEA40についてお答えします。
LiNEA40 は dawne が組み立て代行で依頼が多いボードで、実際に何台も組んでいます。
評価としては、黒デザインにシルバーのボール＆ベアリングの相性が良い、とのこと
（dawne の「黒で統一された見た目が好き」という好みと合致）。トラックボール
搭載のコンパクトな 40% ボードです。
より詳しい仕様（キー数の配置、PCB構成、対応スイッチなど）は、各キットの
頒布元の情報をご確認いただくのが確実です。
読み込んだskillsを根拠に答えつつ、skillsにない細部は「頒布元で確認を」と正直に断っています。ブログという自分のナレッジが、そのままエージェントの土台になっているのが分かります。
デプロイする
デプロイしなくても上記のようにローカルで動作確認できます。
TUIで会話できるだけでなく、エージェントは同じHTTPルートをローカルでも返すので、curl http://localhost:3000/eve/v1/healthやセッション作成（POST /eve/v1/session）をそのまま叩くことができます。
eve deployは中身としてはvercel deploy --prod（本番デプロイ）で、未リンクなら先にプロジェクトのリンクとAI Gateway連携（環境変数の取得）もやってくれます。
デプロイができたら、次は実際に叩いて確かめるのですが、その前に、認証に触れておきます。
eveはエージェント呼び出しルート（POST /eve/v1/sessionなど）をデフォルトで保護するので、叩くにはまず認証を通す必要があります。
設定はagent/channels/eve.tsで行います。ローカルのeve devはlocalDev()で素通ししつつ、本番はvercelOidc()（CLI・サービス間の認証）や、共有のユーザー名/パスワードで通すhttpBasic()などに切り替えます。eve init直後はplaceholderAuth()が入っていますが、これは本番リクエストを401で弾くだけの仮の設定なので、公開前に本物の認証へ差し替えます。
例）
import { eveChannel } from "eve/channels/eve";
import { localDev, placeholderAuth, vercelOidc } from "eve/channels/auth";
export default eveChannel({
auth: [
localDev(), // localhost の eve dev は素通し
vercelOidc(), // 本番は Vercel OIDC で認証（CLI / サービス間）
placeholderAuth(), // 未設定の状態。本番リクエストは 401。公開前に差し替える
],
});
本番（Vercel）で疎通確認する
eve deployコマンドで本番にデプロイした後は
/eve/v1/healthPOST /eve/v1/session（セッション作成）GET /eve/v1/session/<id>/stream（ストリーム取得）
の順で確認します。
呼び出しルートは保護されるので、今回は確認用に、チャネル認証のplaceholderAuth()をhttpBasic()（共有のユーザー名/パスワード。値は環境変数）に差し替えて叩きました。認証なしのリクエストは401、正しい資格情報を付けると通ります。
# 本番にデプロイ（ドキュメントの正規フロー。内部で vercel deploy --prod）
eve deploy
# → Production: https://{xxxxx}.vercel.app (READY)
# 死活確認（health は常に公開）
curl https://{xxxxx}.vercel.app/eve/v1/health
# → {"ok":true,"status":"ready", ...}
# セッション作成（httpBasic の資格情報つき。認証なしは 401）
curl -X POST https://{xxxxx}.vercel.app/eve/v1/session \
-u "$EVE_BASIC_USER:$EVE_BASIC_PASSWORD" \
-H 'content-type: application/json' \
-d '{"message":"30%キーボードのキーマップで意識していることを教えて"}'
# → HTTP 202 / x-eve-session-id: wrun_...
# セッションのストリームを取得
curl -u "$EVE_BASIC_USER:$EVE_BASIC_PASSWORD" \
https://{xxxxx}.vercel.app/eve/v1/session/<session-id>/stream
返ってきたイベントストリームを整形すると、こういう流れでした。本番環境でも、load_skillでブログのスキルを読み込んでから、それを根拠に回答しているのが分かります。
> 30%キーボードのキーマップで意識していることを教えて
session.started model=anthropic/claude-haiku-4.5
assistant キーマップ設計スキルを参照して、dawne が30%キーボードで意識していることをお答えします。
tool-call load_skill skill="keymap-design"
tool-result # dawne のキーマップ設計（30% / 36キー） …（スキルを読み込み）
assistant 30%キーボードのキーマップで意識していることをお答えします。
主な考え方
最優先は「修飾キーと記号が無意識に打てるか」。仕事でコーディングが多く、
Ctrl / Tab / Shift や記号キーを意識せず打てることを重視。
レイヤー設計の学び
40%以降、各レイヤーに役割を持たせ、記号を左右対称でグルーピング。
土台になっている配置
初自作の 7sPro 以来、親指スペース/エンター、Lの横にハイフン、数字の置き方。
今では変えられない基盤。
使用ツール
キーマップ編集は Vial、主に Layer / Toggle 機能。
詳しくはこのブログ記事に: https://tysmmsy.dev/posts/try-keymap-for-30percent-kbd
turn.completed
これまでのAIエージェント構築と何が変わったか
ここでいう「これまで」とは、eveのようなフレームワークがない前提で、AIエージェント構築に必要な部分をVercelの各機能から自分で組み上げるやり方です。
前回の記事で整理したvercel-openclawはVercelの各サービスの組み合わせを実装で見ることのできる題材でした。
そこで見えた「自前で用意する部分」が、eveだとどう変わって、何がメリットになるかを整理します。
| 必要なもの | これまで（手組み） | eveだと | メリット |
|---|---|---|---|
| 状態の永続化、中断/再開 | WorkflowとRedis（Upstash等）を自前で用意 | セッションが標準で状態を保つ | 永続化の作り込みが不要 |
| コード実行の隔離 | Sandbox SDKを直接叩いて管理 | エージェントごとにサンドボックスが立ち上がる | 隔離環境のライフサイクル管理が不要 |
| モデルキーの管理 | transformで認証を外から注入 | AI Gateway＋OIDCで解決 | プロバイダーキーの管理が不要 |
| 外部サービスの認証情報 | サービスごとに個別管理 | Vercel Connectで短命トークンを払い出す | 長期キーを自分で抱えなくて済む。モデルに認証情報が渡らない |
| 人間の承認（Human in the loop） | 承認の中断・再開も自前で実装 | needsApprovalで承認待ちにできる |
承認待ちの中断・再開が組み込み（待っている間はリソースを使わない）承認のやり取り自体はチャネル側 |
| チャネル連携（Slack等） | webhook、署名、トークンを個別実装 | 1チャネル＝1ファイル | webhookや署名などの定型実装が不要 |
| 定期実行 | Cronやwakeの自前設計 | schedules/にファイルを配置 |
スケジューラとwakeの設計が不要 |
| 観測・トレース | 自前でログ整形 | Agent Runs / OpenTelemetryの連携可能 | 各実行が自動でトレースになる（自前のログ整形が不要） |
| テスト | 手動でログ確認 | evalsで採点 | テストをCIのゲートにできる |
vercel-openclawでは、APIキーをサンドボックスの外で預かり、呼び出し時だけ差し込む仕組みを自前で組み、その都度「漏れていないか」を確かめていました。
eveではここがAI Gateway + OIDCと、Vercel Connect（用途ごとにスコープを絞った短命トークンを払い出すしくみで、2026年6月時点でpublic beta）に置き換わり、モデルに認証情報が渡りません。
他のフレームワークと比べると
LangGraphやMastra、AI SDKなどエージェントを構築する選択肢は多いですが、その多くはエージェントのロジックを組むライブラリで、本番で動かす土台（永続実行・隔離実行・デプロイ・監視）は別に用意する形が多いと思います。
このあたりをVercelサービスで一気通貫で管理できることがeveのメリットだと思います。
触ってみた所感と、気をつけるところ
気をつけるところとしては、2026年6月時点ではbetaであり、GAまでにAPIや挙動が変わる可能性があると明記されています。検証や記事化の際はバージョンを固定し、changelogを追っておくと安心です。
そして、フレームワークで補助できない部分が「そのエージェントが実際に何をするのか」です。
標準化されたぶん、勝負どころはtoolsとskills、つまりエージェント固有のドメイン知識と振る舞いの設計に寄っていきます。
今回、その勝負どころを自作キーボードブログのナレッジで実際に試しました。skillsを差し替えるだけで、汎用のデモが自分の専門領域に答えるエージェントに変わります。
ここからは主観ですが、AIエージェントが広がるほど、土台を組む部分は平準化されていきます。みんなが同じ土台に立つなら、最後に差がつくのは、領域をどれだけ深く理解し、言語化できているかだと思います。
今回スキル化できたのも、キーボードの知見をブログに書き溜めてきたからでした。
さいごに
betaではありますが、AIエージェント基盤を手さぐりで作っていた人ほど、その差分をはっきり感じることができると思います。
Next.jsがWebアプリケーション構築の手法として広まっていったように、eveもAIエージェント構築の前提になっていくのか、そう思わせてくれる手応えがありました。
