QuiverAIがArrow 2を発表:AIがコードで描くベクター画像、ロゴや線画の全形状を個別編集でき、アニメーションにも対応
Arrow 2が生成するのはラスター画像ではなくSVGコードです。拡大しても劣化せず、すべての線や形状を編集できます。複雑な図面は50%高価なArrow 2 Telosが担当します。新モデルはトークン従量課金に移行しましたが、1枚あたりの平均消費トークン数は非公開のため、コスト試算には事前の実測が不可欠です。
主流の生成AIのほとんどは「ピクセルを描く」ことに終始しています。モデルが出力するのは、無数の色ブロック(画素)が敷き詰められたラスター画像(JPGやPNGなど)です。こうした画像は拡大すると輪郭がぼやけ、画面内の要素もすべて一枚に結合してしまいます。デザイナーが一枚の木の葉を動かしたり、フロントエンドエンジニアがアイコンの線幅を変えたりしようとしても、直接編集することはできません。
QuiverAIが発表した新世代ベクター生成モデル「Arrow 2」および「Arrow 2 Telos」は、これらとは根本的に異なるアプローチを採っています。それは、コードによって構造化されたベクター画像(SVG)を直接生成するという手法です。SVG(Scalable Vector Graphics)は、XMLコードを用いて幾何学図形を記述するフォーマットです。ピクセルを記録するのではなく、点、線、多角形、曲線の数学的な方程式を記録します。そのため、生成されたグラフィックはどれだけ拡大しても劣化せず、図中のすべての形状、線、レイヤーをベクター編集ソフトやコード上で個別に修正できます。
同時にQuiverAIは、対話形式の生成とキャンバス編集を統合した新バージョンのApp、ならびに独立した開発者向けプラットフォームもリリースしました。料金体系も刷新され、従来のArrow 1シリーズのような画像1枚ごとの固定料金ではなく、Arrow 2とTelosはトークン従量課金へと移行しました。
なぜベクター画像はピクセルのトレースだけでは不十分なのか?
伝統的なデザインワークフローにおいて、ラスター画像をベクター画像に変換する際は、グラフィックソフトの自動トレース(Image Trace)機能を使うのが一般的でした。しかしこの自動トレースは、アルゴリズムがピクセルの色境界に沿ってパスを近似配置する仕組みであるため、輪郭にわずかでもノイズがあると、細かく断片化した「アンカーポイント」が大量に生成されてしまいます。
コントロールポイント(ハンドル)とアンカーポイントは、ベクターグラフィックの根幹をなす要素です。アンカーポイントは幾何学パスの屈折位置を決定し、コントロールポイント(ハンドル)は曲線の曲率や向きを決定します。デザインやエンジニアリングの観点では、コントロールポイント(ハンドル)が少なく整然としているほど、線は滑らかでクリーンになります。パス上に不要なポイントが密集しているとファイルサイズが肥大化するだけでなく、輪郭の一部をドラッグして微調整したいときにも、無数のポイントを一つひとつ手作業で処理しなければならなくなります。
ラスター画像
14×14=196個のグリッドの色を記録。拡大するとグリッドごと拡大される
自動トレースによるパス
38 個のアンカーポイント、パスコードは 363 文字
デザイナー式の手法
2 個のアンカーポイント(塗りつぶし)+ 4個のコントロールポイント(白抜き)、パスコードは 43 文字
SVGファイル内における2つのパスの実際のコード:
自動トレース
M17.5 81.1L18.1 74.4L18.2 68.9L17.9 63.4L19.4 57.5L21.6 51.3L25.1 48.2L27.4 42L32.2 39.5L35.9 34.1L41.1 29.6L45.3 26.9L48.2 23.6L53.5 22.9L58.3 20.2L64.8 18L69.9 16L74 15.5L81.1 15.7L85.5 16.2L85.4 21.1L85.3 27.8L82.6 33L81.7 39.1L80.2 42.8L78.5 47.4L74.3 53.8L70.6 57.7L66.9 62.4L65 66.1L61.3 69L56.5 73L51.6 75.4L47.4 79.1L41.2 80.2L34.7 81.7L30.5 83.3L25 81.8Z
デザイナー式の手法(Cは曲線を意味し、後ろに2つのコントロールポイントと終点が続く)
M18 82C14 40 52 14 86 16C84 52 58 86 18 82Z
QuiverAIチームは初期にStarVectorやRLRFといったベクター生成に関する研究を発表しており、そのプロダクト思想は「視覚的表現をプログラミングの問題へと変換する」ことにあります。すなわち、大規模言語モデルに規約に則ったSVGタグとベジェ曲線のパラメータを直接記述させるのです。Arrow 2が重視しているのは、ピクセル単位での見た目の模倣ではなく、簡潔で正確なコードノードによって保守性の高いデザインアセットを構築することです。
Arrow 2 と Telos の違い
今回リリースされた2つのモデルは、位置づけ、コンテキストウィンドウ、価格がそれぞれ異なります。
Arrow 2:品質と速度のバランスを重視した主力モデルです。一般的なアイコン、単体イラスト、フラットなUIアセット、そして日常的なデザイン探求の大部分に適しています。コンテキストウィンドウは131,072トークン、1回あたりの最大出力制限は65,536トークンです。
Arrow 2 Telos:高度に複雑な制作に向けた、ロングコンテキストかつ高精度な上位モデルです。Telosのコンテキストウィンドウは1,050,000トークン(Arrow 2の約8倍)に拡張されており、1回あたりの最大出力は同様に65,536トークンです。
QuiverAIはTelosについて、「Arrowのスピード、テイスト、インフラと、フロンティアモデルの洗練能力や深みを融合させたもの」(combines Arrow's speed, taste and infrastructure with the refinement capabilities and depth of frontier models)と説明しています。ただし、具体的にどこのフロンティアモデルを採用しているのか、どのように統合されているのかについては一切公開されていません。
価格面では、Telosの各トークン単価はArrow 2より一律50%高く設定されています。マルチレイヤー構造の大規模なダイアグラム、極めて緻密な幾何学的製図、長文のデザインガイドラインや複数の複雑な参考画像を入力する必要があるシーンにはTelosが適しています。一方、基礎的なアイコンの大量生産や、生成コストを重視するパイプラインであれば、Arrow 2がより合理的で堅実な選択肢となります。
品質、速度、公式事例
公式発表によると、Arrow 2の品質向上は主に2点あります。コントロールポイント(ハンドル)がより少なく正確になったこと、そして要素間のスペーシング、余白、整列が一段と洗練されたことです。ただし、標準ベンチマークテストのスコアやノード数の統計データといった定量的な指標は一切公開されておらず、ブログやSNSで提示されている事例はいずれも公式が選定したものに限られます。
生成速度に関しても、公式ブログや投稿では定性的に「より高速」と述べられているのみです。プロモーション動画のナレーションに「Arrow 2.0 is five times faster」(Arrow 2.0は5倍高速)という一言が含まれているのみで、Arrow 1.0と比較してなのかArrow 1.1と比較してなのか、どのような測定条件なのかは明らかにされていません。
公式ブログでは4つのカテゴリの事例が紹介されています。
左側の参考ポートレートを入力し、カラーと幾何学的スタイルの一貫性を維持した4つの新しい人物ポートレートをArrow 2が生成
スタイルの継承と複数キャラクターの生成:1枚のイラストを参照画像として入力すると、モデルはそのカラーパレット、明暗の幾何学的ファセット、顔立ちの描画ルールを抽出し、統一されたスタイルのキャラクターポートレートをまとめて生成できます。シリーズもののキャラクターアセットを素早く構築するのに役立ちます。
筋肉の線画イラストにおいて、肩の三角筋などの対象部位を赤く塗りつぶして強調し、周囲の骨格・筋肉はモノクロ線画のまま維持
部分強調のテクニカルイラスト:技術図面や医学イラストにおいて、テキスト指示に応じて特定の幾何学領域を視覚的に強調できます。たとえば、肩の三角筋などの特定筋群を赤く塗りつぶしつつ筋繊維のラインを残し、周囲の解剖構造は白黒の線画のまま保持するといった処理が可能です。
ファッションプロンプトから生成されたジャケット線画。ファスナー、パーツの切り替え、ステッチ構造を明瞭に表現
アパレルおよび工業線画:アパレルの平絵(Technical Flats)には、整ったラインと左右対称の構造が求められます。生成された線画は、襟のバリエーション、ポケットの位置、斜めファスナー、縫製ラインなどを安定して描き出し、デザイナーがパターンメイキングのロジックを直感的に把握できます。
左側の鉛筆手描きマスクスケッチが右側のベクター画像へと変換され、外郭には数十個の主要アンカーポイントのみが配置されている
スケッチのベクター化(Vectorization):紙の手描きスケッチや通常の画像(ラスター画像)をベクターコードに変換します。手描きのマスクスケッチをベクター化した例では、外輪郭のアンカーポイントの大部分が角や曲率の変化点に配置されており、輪郭ノイズによる乱雑なパスの発生が抑えられています。
リリースから24時間経たないうちに、Justine Moore氏がX上に23秒の画面録画を投稿しました。彼女はa16zのパートナーであり、a16zはQuiverAIの830万ドルのシードラウンドを主導しているため、これは投資家による実演デモであり、第三者の独立した検証ではありません。彼女は新モデルを「極めて詳細なSVGの生成に優れている」(remarkably good at generating detailed SVGs)、「描画過程を見るのがとても楽しい」(very fun to watch it draw)と評価し、様々な商品画像をモデルにベクター化させています。動画内では、Miu Miuの公式サイトに掲載されている3,200ドルのショート丈ダウンジャケットの画像をAppに貼り付け、「puffer jacket」とプロンプトを入力し、モデルにArrow 2 Telosを選択しています。キャンバス上のSVGはパーツごとに段階的に描画され、まず袖、次に身頃と裾、最後にキルティングライン、白いパイピング、立ち襟、ファスナー、ポケット、ドローコードが描き足され、最後に元の写真と生成されたSVGが並べて比較されます。
最終的な比較画面を見ると、立ち襟、ラグラン線の白いパイピング、2つのジッパー付きポケット、裾のドローコード、リブ袖口がしっかり再現されています。カラーは元の写真の深いネイビーに比べてやや紫がかって明るく、身頃のキルティング格子はより規則的かつシンプルに整理されています。このように選び抜かれたデモ映像からは、「写真 → 編集可能なベクター画像」のプロセスやディテールの再現度を視覚的に確認できますが、成功率や安定性のデータを担保するものではありません。また、生成にどれだけの時間がかかり、どれほどのコストを消費したのかは動画からは確認できません。
キャンバスワークスペースとマイクロアニメーション機能
新バージョンのAppは、生成と編集を同一のワークスペースに統合しました。欲しいグラフィックを1行のテキストで指示し、チャットの対話で修正を重ね、キャンバス上で精密に調整します。すべての成果物は編集可能なSVGであり、Appの外に書き出して利用できます。
新版App:左側のチャット欄で「雲をすべて削除して(Delete all the clouds)」と送信しようとしており、右側のキャンバス上では1つの雲が個別に選択されている
Appの画面構成は、左側がチャットパネル、右側がSVGキャンバスとなっています。たとえば画面内の雲を取り除きたい場合、キャンバス上でその雲を直接選択して削除することもできますし、チャットで「雲をすべて削除して」(Delete all the clouds)と指示することも可能です。
先述の画面録画では、Appのモデル選択メニューも確認できます。メニューにはArrow 2とArrow 2 Telosの2つのモデルに加え、「Effort」(モデルの思考の深さを指定する設定項目)があり、デモではMediumが選択されていました。Telosにカーソルを合わせると、「複雑なSVGの作成に優れていますが、利用枠の消費が格段に早くなります」(Excels at complex SVG creations and drains usage much faster.)という説明文が表示され、「Usage based」(従量課金)のラベルが付いています。公式ブログや開発者ドキュメントには、Effortにいくつの段階があるのか、段階ごとにどれほど差があるのか、またApp内でTelosがArrow 2に比べて具体的にどれほど多くクレジットを消費するのかについての記載はありません。
Arrow 2はさらに、静止画のSVGにマイクロアニメーションを付加する機能も備えています。この機能には明確な適用範囲があります。
- マイクロアニメーションは既存の形状に適用される動的エフェクトである:モデルが何もないところから動画クリップを生成するのではなく、SVG内に既に存在する形状やグループ(Group)を動かす仕組みです。出力されるのはWebページに直接組み込めるSVGアニメーションです。
- 最適な用途はUIのマイクロインタラクション:ロゴのストローク描画、ローディング状態(Loading State)、コーヒーカップから立ち上る湯気、アイコンのまばたきといったフラットな構造のグラフィックに最適です。
- 今回が初登場ではない:QuiverAIが初期に公開したMCPツールにおいて、既存のSVGにアニメーションを追加する機能はすでに提供されていました。Arrow 2における主な進歩は、この機能を正式に製品化し、新モデルおよびWebエディタへ統合した点にあります。
ブログのアニメーションサンプルでは、4つの小さなグラフィックが同時に再生されています。フクロウのまばたきと揺れ、カップから立ち上る湯気、モノラインから塗りへと展開するモノグラムロゴ、わずかに変化する幾何学パネルのラインなどです。動いているのはいずれも画像内に元からあった要素であり、画面自体のカメラワークや視点移動はありません。
料金体系:画像ごとではなくトークン従量課金へ移行
Arrow 2をプロダクション環境に導入するにあたり、最も把握しておくべきなのは課金モデルです。
従来のArrow 1シリーズは画像1枚ごとの固定料金制でした。Arrow 1.1はSVG生成が1枚あたり0.20ドル、ベクター化が1回あたり0.15ドルで、これらの旧モデルは現在も価格表に掲載されています。
Arrow 2およびTelosには1枚ごとの固定価格はなく、トークン消費量に応じた従量課金となります:
| モデル | 入力トークン単価(100万トークンあたり) | キャッシュ入力単価(100万トークンあたり) | キャッシュ書込単価(100万トークンあたり) | 出力トークン単価(100万トークンあたり) |
|---|---|---|---|---|
| Arrow 2 | $4.00 | $0.40 | $5.00 | $20.00 |
| Arrow 2 Telos | $6.00 | $0.60 | $7.50 | $30.00 |
画像1枚あたり実際いくらかかるのか?
料金ドキュメントには試算例が1つ示されています。1回の呼び出しでキャッシュされていない入力トークンを10,000トークン、出力トークンを2,000トークン消費した場合、Arrow 2では0.08ドル、Telosでは0.12ドルのコストとなります。
ただしこれは計算例にすぎず、画像1枚を生成する平均コストを示すものではありません。QuiverAIはSVG1枚あたりに平均して何トークン消費されるのかを公表していません。
公式の単価から試算してみると、以下のことが分かります:
- 出力のみに注目した場合:Arrow 2の出力単価は100万トークンあたり20ドルであるため、出力がちょうど10,000トークンで0.20ドルとなり、Arrow 1.1でSVGを1枚生成する価格と同額になります。Telosの出力単価は100万トークンあたり30ドルで、約6,700トークンの出力で0.20ドルに達します。
- 公式の試算例(入力10,000トークン + 出力2,000トークン)では、Arrow 2で0.08ドル、Telosで0.12ドルとなり、いずれもArrow 1.1の0.20ドルより安価です。
- 1回のリクエストにおける最大出力上限は65,536トークンです。上限いっぱいに達した場合、出力部分の費用だけでArrow 2は約1.31ドル、Telosは約1.97ドルになります。
- Responses APIを用いて複数ターンのツール呼び出しを行う場合、ターンごとに上記の方法で個別に課金され、最終的な総額は各ターンの合算となります。
- したがって、割高になるか安くなるかは、生成する画像が(推論トークンを含めて)実際に何トークンを必要とするか次第ですが、公式はその数値を明かしていません。実際の消費量は、APIプラットフォームの「Usage & Logs」ページでリクエストごとに確認できます。
公式単価で画像1枚のコストを試算
実測値または推定トークン数を入力すると、同じ使用量でArrow 2とTelosの費用がそれぞれいくらになるか、Arrow 1.1の1枚あたり0.20ドルの固定価格と比較できます。トークン数は任意の想定値、単価は公式料金ページに基づきます。
| モデル | この画像の費用 | Arrow 1.1との比較 |
|---|---|---|
| Arrow 2入力 $4 / 出力 $20(100万トークンあたり) | $0.080 | 60% 安い |
| Arrow 2 Telos入力 $6 / 出力 $30(100万トークンあたり) | $0.120 | 40% 安い |
| Arrow 1.1固定価格、1枚生成 | $0.200 | 基準 |
計算式:(入力 × 入力単価 + 出力 × 出力単価)÷ 1,000,000 × リクエスト回数。キャッシュ入力の割引価格は含みません。複数ターンの呼び出しでは毎回完全な会話履歴を再送信する必要があるため、後続のターンほど入力トークンが増加します。そのため、複数ターンの計算結果は理論上の最小値となります。Arrow 2のコンテキスト上限は131,072トークンで、これを超える入力は収まりません。Telosは1,050,000トークンです。
実際の運用において、予算見積もりに必ず組み込むべき3つのエンジニアリングルールがあります:
- 推論(Reasoning)トークンは出力として課金される:モデルは作画を始める前に推論を行います。この推論トークン(reasoning token)はすべて出力トークンとして計算されます(別途二重に課金されるわけではありません)。ストリーミング出力を有効にすると、この推論プロセスを確認できます。
- 複数ターンのツール呼び出しは都度課金:Agentワークフローにおいて、モデルがツールを介してアセットを繰り返し微調整する場合、発行されるHTTPリクエストごとにトークン費用が独立して決済されます。1枚の最終的な図面を完成させるまでに、複数回分の呼び出しコストが累積する可能性があります。
- デポジット(事前ホールド)の仕組み:トークン従量課金のリクエストでは、リクエストの実行開始前にアカウントの利用可能残高から1ドルが一時的に仮押さえ($1 hold)されます。リクエスト完了後に実際の消費額が差し引かれ、余剰分は解放されます。残高がそのリクエストの支払いに不足している場合、実行前にAPIが402エラーを返すことがあります。
AppのサブスクリプションとAPIチャージは完全に分離
AppとAPIの会計は完全に独立しています:
- AppのサブスクリプションはAPIに流用不可:AppにはGo(月額$8)、Basic(月額$20)、Pro(月額$40)の3つのプランがあり、それぞれ毎週$5、$15、$40のアプリ内クレジットが付与されます。これらのクレジットは毎週月曜日(UTC)にリセットされ、翌週に繰り越すことはできません。App内でのみ使用可能で、APIの呼び出しには利用できません。
- APIは独立した前払い方式:開発者がAPIを呼び出すには、platform.quiver.aiで個別に前払い残高をチャージする必要があります。デフォルトの最低チャージ額は10ドルで、チャージしたクレジットの有効期限は1年間です。
開発者の導入:2つのインターフェースをどう選ぶか
開発者向けに、Arrow 2は2つの呼び出しルートを提供しています。ネイティブの/v1/svgs/*エンドポイントと、Open Responses仕様に準拠した/v1/responsesインターフェースです。
ユースケースが単発の「プロンプトからのSVG生成」や「画像のベクター化」だけであれば、ネイティブのPOST /v1/svgs/generationsを呼び出すのが最もシンプルです。参考画像(Base64または公開URL)の入力に対応しており、stream: trueを有効にすると、サーバーからreasoning(推論)、draft(ドラフトレンダリング)、content(最終的なSVG結果)の3種類のServer-Sent Eventsが順次配信されます。
Arrow 2をAgentのワークフローに組み込み、独自のツールを呼び出させたい場合は、Responsesインターフェースを利用します:
標準SDKとの互換性:Vercel AI SDKの@ai-sdk/open-responses拡張経由での接続をサポートしているほか、OpenAI公式のJS/TS SDKを直接使用することも可能です。その場合、baseURLをhttps://api.quiver.ai/v1に置き換えてclient.responses.createを呼び出すだけで連携できます。
クライアント側ツール呼び出し(Tool Calling):開発者はリクエスト内で、自身のアプリケーションがサポートする関数(ファイルを保存するwrite_fileなど)をArrowに宣言できます。Arrow 2は複数ターンの対話の中で、いつそのツールを呼び出すかを判断し、構造化されたパラメータを返します。
完全なステートレス設計:QuiverAIのResponsesインターフェースは過去の会話履歴をサーバー側に保持せず、リクエスト内で会話を保存するためのパラメータもサポートしていません。複数ターンの微調整や、ツール実行後の生成継続を実現するには、クライアント側がコンテキスト配列の中に完全な会話履歴、ツールの呼び出しパラメータ、実行結果を毎回含めて再送信する必要があります。
プロモーション動画のナレーションでは、「QuiverAIを使って人々が創り出すものを見たことで、私たちのArrowモデルの構築方法は変わりました。生成されたすべてのイラスト、すべてのアイコン、すべての設計図が私たちのモデルの糧となりました」(Watching what people created with QuiverAI changed how we built our model Arrow. Every generated illustration, every icon, every technical drawing helped our model.)と語られていますが、具体的にどのように利用されているのかについての詳細な説明はありません。判明している点としては、APIプラットフォーム上で組織が「Improve QuiverAI」(条件を満たす組織のデータを用いてQuiverAIを改善すること)に同意するかどうかを設定可能で、設定変更は組織のOwnerまたはAdminのみが行えます(ドキュメントにデフォルト値の記載はありません)。また、提供されている資料の中には、Appサブスクリプションユーザー側のデータ利用に関する説明は見当たりません。
モデル選定チェックリスト
-
グラフィックの複雑さと要求精度はどれくらいか? アイコン、ロゴ、フラットなイラストなど要素数が少ないグラフィックを生成する場合、公式ドキュメントでは大半のケースでArrow 2を第一選択とすることを推奨しています。Arrow 2の出力で細部のズレや密集したパスの乱れが見られる場合、あるいは緻密なイラスト、厳密な幾何学性が求められるロゴ、設計図など「速度よりも精度が重要」なグラフィックを扱う場合に、Telos(各単価が50%高価)への切り替えを検討してください。一般的なグラフィックに最初からTelosを使うとコストが無駄になりますし、高精度が求められる複雑なグラフィックで無理にArrow 2を使い続けると、納品要件を満たせない可能性があります。
-
1回のリクエストで送信するコンテキストはどれくらいの長さか? 入力する必要のあるデザイン指示、ブランドガイドライン、参考資料などの合計トークン量を確認してください。Arrow 2のコンテキスト上限である131,072トークンを超える場合は、1,050,000トークンに対応するTelosを選ぶしかありません。上限に収まっている場合、コンテキスト長はTelosを選ぶ理由にはなりません。上限を超えるデータはArrow 2に入り切りませんし、上限を超えていないのにTelosを選べば単価が50%高くなります。
-
事業予算はトークン従量課金の変動コストを許容できるか? まずは実際の業務要件に即した少量のサンプルをAPIプラットフォームで試走させ、「Usage & Logs」ページで画像1枚あたりに実際に消費されるトークン数を確認してください。公式単価に基づく試算では、Arrow 2において画像1枚の出力(推論を含む)が10,000トークンに達すると、出力費用だけで0.20ドルとなり、Arrow 1.1の1枚あたりの固定価格と同等になります(これに入力費用が加算されて総額となります)。出力がこの水準を明確に下回って初めて、Arrow 2はArrow 1.1より安くなります。画像1枚ごとのコストを完全に確定させる必要がある業務であれば、画像単位の固定料金であるArrow 1.1に留まる選択肢もあります。事前の実測を行わずに全面的にArrow 2へ移行すると予算超過を招くリスクがありますが、Arrow 1.1のままでは新モデルが提供するSVGの編集機能やマイクロアニメーション機能を利用できません。
-
単発の固定生成か、それともAgent内で自社ツールを呼び出すのか? 単発の「テキストからのSVG生成」や「画像のベクター化」だけであれば、ネイティブの
/v1/svgs/*インターフェースを使う方がシンプルです。Agentワークフローの中でArrowに独自のツールを呼び出させる必要がある場合にのみ、/v1/responsesインターフェースを採用し、必ずリクエストのターン数に上限を設けてください。シンプルな要件でResponsesインターフェースを使うと、実装や状態管理のオーバーヘッドが増加します。また、Agentのフローでターン数の上限を設定しないと、ツールが呼び出されるたびに個別課金が発生し、総呼び出し費用が高騰するリスクがあります。
