Onlookレビュー【2026年】料金とコードを直接編集する仕組み・Figmaとの違い

Onlook（オンルック）は、Reactのコードをそのままキャンバスで編集するデザインツールです。開発元は米On Off, Inc.で、公式サイトのフッター表記もこの社名になっています。公式トップの見出しは「The Developer Tool for Visual Engineers」、説明文は「Onlook is a free, local-first editor where designers craft exceptional experiences in code」とあります。無料で、ローカル優先で、コードの中でデザインする、という3つが同時に掲げられています。料金は公式ページでFree（自分でホストすれば無料）とFor Teams（カスタム見積り）の2段だけで、月額の数字は公開されていません。この記事は実際の操作を行わず、公開情報だけを材料にした整理です。編集画面の反応速度、生成されるコードの品質、日本語UIの使い勝手は未検証です。

Onlookとは何か。コードを直接編集するとはどういうことか

Onlookは、Webの画面を「絵」としてではなく「コード」として扱う編集ツールです。公式の説明は「Onlook is a free, local-first editor where designers craft exceptional experiences in code」で、デザイナーがコードの中で体験を作る、という言い方をしています（2026年11月6日確認）。FigmaやCanvaのように画面のデータを編集するのではなく、Next.jsやReactのプロジェクトを開き、ブラウザに表示された画面を直接つかんで動かす。変更はコードに反映され、そのコードがそのまま本番の資産になります。

公式はこの考え方を「The canvas is the app」という一文で表しています。「Every frame is a working page, not a picture of one」と続き、キャンバスの1枚1枚が動くページであって、その写真ではない、と説明しています。この一文がこの製品の性格をほぼ言い切っています。デザインの道具と実装の道具の境目を、キャンバスの側で消しにいっているわけです。

料金の構造も、この思想とつながっています。自分でホストする形は無料で、ホストされたクラウド版はチーム向けの見積り。個人が使う分には費用が発生せず、組織で運用を任せたい場合だけ費用がかかる、という二段構えです。道具そのものを売るのではなく、運用の手間を売っている形だと言えます。

公式トップに「Onlook just crossed 27,000 stars on GitHub!」「27,127 other builders」という表示があります。いずれも公式ページ上の表示で、日付と集計方法は明示されていません。数字をそのまま市場の評価として読むのは避けるべきですが、少なくとも開発者がソースを読みに来る規模の関心を集めている、という材料にはなります。2026年11月に見た限り、Onlookは、商用SaaSとして育つ前の段階にある道具として捉えておくのが実態に近いと考えられます。

Onlookの料金はいくらか。公式に金額がない理由

料金の話は、確認できた事実から書きます。2026年11月6日に公式の料金ページを開くと、並ぶのは「Free」と「For Teams」の2つだけでした。Freeの説明は「Download Onlook and start designing in your code」、For Teamsの説明は「Custom pricing tailored to team's needs」で、チームの要望に合わせた見積りです。月額の数字は公式ページのどこにも書かれていません。そのため、この記事では月額を書かずに、何で金額が決まるかの構造だけを整理します。

この表から分かるのは、金額が3つの財布に分かれることです。1つはツール本体で、セルフホストなら無料、チーム運用なら見積り。2つ目はAIの利用料で、自分が契約しているClaudeやChatGPTのプランに乗ります。3つ目は、成果物を公開する先のホスティング料です。公式のFAQにも「Is there a free version of Onlook? Yes, Onlook can be self-hosted for free on GitHub. For the hosted cloud version, please contact our team or book a demo.」とあり、無料の範囲と見積りの範囲が明示されています。

第三者の比較サイトには「Pro 月25ドル」といった記述が見られますが、公式ページには該当する表記がありませんでした。この記事では、公式で確認できない金額は採用していません。判断の材料にするなら、見積りを依頼して条件を聞き取るのが確実です。表示は地域・支払い周期・為替で変わるため、契約前に公式サイトの料金表を確認してください。

「無料」の範囲はどこまでか

無料で使えるのは、自分でホストする形と、アプリをダウンロードして手元のプロジェクトを開く形です。この範囲では、ツールの利用に対する支払いは発生しません。一方で、AIに指示を出して画面を作り変える機能は、自分が契約しているClaudeまたはChatGPTのプランを通ります。「Onlookが無料」と「AIの利用が無料」は別の話であり、この2つを混ぜて考えると費用の見積もりを誤ります。既にAIの有料プランを持っている人ほど、追加の出費が小さく済む構造です。

ローカル優先とAIの契約流用。設計の狙いはどこにあるか

Onlookの説明で特徴的なのは「local-first」という言葉です。プロジェクトはMacの上に残り、クラウドに預ける必要がありません。これは単なる保存場所の話ではなく、誰のAIを使うかという話につながります。公式は「Bring your AI subscription」「Use the Claude or ChatGPT plan you already have. OpenCode and more are coming soon.」と書き、AIの利用を自前の契約に寄せています。ツール側がAIの利用料を抱え込まないため、本体を無料にできる、という理屈です。

この設計には、実務上の効き目が2つあります。1つは、費用の予測が立てやすいこと。AIの利用量は、自分が契約しているプランの上限の中で管理できます。もう1つは、データの流れが読みやすいこと。どのモデルに何を送っているかが、契約の主体として把握できます。機密性の高い画面を扱うチームにとって、ここは評価の対象になります。

公式の機能一覧には、次のような項目が並びます（2026年11月6日確認）。

• キャンバスがアプリそのもの。編集した結果がそのまま動くページになる
• 常に同期。「Always design in sync」として、本番のコードとずれない設計を掲げる
• 方向の探索。「Spin up variations of an idea right on the canvas, then merge the ones that work」とある。案を出して、良かったものを統合する
• デザインシステムの操作。トークン、コンポーネント、スタイルを視覚的に扱う
• 素材の持ち込み。スクリーンショットやムードボードを、動く画面の隣に置ける
• 見慣れたショートカット。既存の操作感をそのまま使えるとしている
• 対応スタック。Next.js、React、Vite、Storybook、shadcn/uiが並ぶ
• 受け渡し。「share a branch or an artifact」として、ブランチか成果物で渡す

この並びで目を引くのは、対応スタックが明示されていることです。React系のプロジェクトを前提にしており、VueやSvelteの名前は出てきません。短所にはなりますが、導入を決める前に必ず確かめる前提です。Reactで書かれたプロダクトを持つチームなら、導入の判断は早く済みます。逆に、別のフレームワークで書かれたプロダクトは、この道具の土俵の外になります。

公開情報として、対応環境の記載も確認できました。macOS 13以降で動き、ディスクは約1GBを使うという説明です。Windows版やLinux版の記載は、公式トップと料金ページからは見つかりませんでした。社内にWindowsしかない組織では、この段階で選択肢から外れる可能性があります。ここが導入前の最初の確認項目になります（未検証）。

評価できるところ。デザインとコードの往復が消える

• 成果物が最初からコード。絵からコードへ作り直す工程がない
• セルフホストが無料。契約の前に、社内の環境で試せる
• オープンソース。ソースを読めるので、社内の情報管理の審査に出しやすい
• AIの契約を自分で選べる。既にClaudeやChatGPTを契約していれば追加の出費が小さい
• 案を統合する使い方が用意されている。複数の方向を出して、良かった部分を合わせられる
• 既存のショートカットを使える。覚え直しの負担が小さい
• プロジェクトはローカルに残る。クラウドに預けきらない運用ができる

一番の強みは、作り直しの工程がないことです。Figmaで画面を作り、エンジニアがコードに直す流れでは、必ずどこかで数値と部品がずれます。余白が2ピクセル違う、コンポーネントの名前が違う、といった差分が積み上がり、確認のやり取りが発生します。Onlookは、最初からコードを触っているので、このずれが起きる場所がありません。「デザインの正しさ」をコードの上で語れることが、この道具の最大の持ち味だと考えられます。

この効き目は、変更の履歴をどう扱うかにも表れます。公式の料金ページには、For Teamsの機能として「Branching & Version Control」「Create and manage branches for your projects with full version history」が並びます。ブランチを切って試し、良ければ統合する。コードを扱うチームには見慣れた手順です。デザインの道具でこの手順が使えると、試作と本番の区別が作業の流れの中で自然に保てます。レビューの担当者が、どの変更を採用するかを差分の単位で選べることも、この流れの持ち味です。

二つ目は、試すことの安さです。セルフホストが無料で、プロジェクトもローカルに置けます。社内の規程で外部サービスへの送信が難しい組織でも、まず手元で動かして評価できます。ソースが読めることも、審査を通すときの材料になります。「何をしているか分からない道具」ではなく「何をしているか読める道具」として説明できます。

三つ目は、AIの費用の置き方です。ツールの月額にAIの利用料が含まれている形だと、使えば使うほど費用が読めなくなります。自前の契約に寄せる形なら、AIの費用は自分の管理下に置けます。この設計は、費用の上限を先に決めたい組織に向いています。

四つ目は、オープンソースであることの意味です。公式は「Why is Onlook open-source?」というFAQで、開発者がデザインの工程で二級市民扱いされてきた歴史に触れ、デザインと開発の間を橋渡しするためにソースを開いた、と説明しています。理念の話ではありますが、実務では「ツールが提供を止めても、ソースが残る」という安心材料になります。長く使う予定の道具では、ここは軽くありません。

五つ目は、案を統合する使い方です。方向の違う案を出し、良かった部分を合わせる。この作業が機能として用意されているのは、デザインの現場の進め方に合っています。1案を磨き込むより、複数の案から部品を拾うほうが、チームの合意を作りやすい場面があります。

気になるところ。React前提と、見積り頼みの料金

• React系のプロジェクトが前提。VueやSvelteのプロジェクトでは使えない
• 月額が公式に存在しない。チーム利用の費用は見積りを取らないと分からない
• AIの契約が別に必要。ClaudeやChatGPTの有料プランを持っていないと、生成系の機能の費用が上乗せになる
• 対応OSがmacOS中心。WindowsやLinuxの記載は確認できていない
• コードを読める前提の道具で、非エンジニアのデザイナーには敷居が高い
• 第三者の比較サイトの金額は公式と一致しない。外部の情報だけで予算を組むのは危険

一番の引っかかりは、フレームワークの縛りです。Reactのプロジェクトを前提にしているため、社内のプロダクトが別の技術で書かれていると、そのままでは使えません。「デザインとコードの往復をなくす」という売りは、Reactの上でしか成立しません。ここは、道具の評価というより前提条件の話です。導入の検討は、技術スタックの確認から始めるべきだと考えられます。

二つ目は、金額の見えにくさです。公式ページに月額の数字がなく、チーム向けは見積り制です。個人が無料で試す分には問題ありませんが、組織で導入する段になると、費用の当てが立たない期間が生まれます。見積りの依頼から回答までの日数も、スケジュールに効きます。導入の計画を立てるなら、見積りの依頼を最初の工程に置いてください。

三つ目は、AIの契約の前提です。AIの利用料が自前の契約に乗る設計は、費用の予測が立てやすい半面、契約を持っていない人には入口が高い。無料のAIプランでも使えるかどうかは、公式の記載からは読み取れません（未検証）。生成系の機能を当てにして導入を決めるなら、先に手元で試して、どの機能がどの契約で動くのかを確かめる必要があります。

運用の形も、この製品ならではの判断になります。セルフホストを選ぶと、更新の適用とサーバーの面倒を自分たちで見ることになります。クラウド版を選ぶと、その手間は減る代わりに、見積りの金額と契約の条件が発生します。「誰が更新を当てるのか」を決めないまま導入すると、数か月後に古い版を使い続ける状態になりかねません。この役割の割り当ては、道具の比較より先に済ませておきたい項目です。

なお、対応スタックの一覧にStorybookの名前があることも、見逃せません。Storybookは、UIの部品を1つずつ確認するために使われる道具です。ここが対応先に並ぶということは、部品単位での確認を前提にした使い方を想定している、と読めます。画面全体を作り込むより、部品の状態を整える仕事が多いチームほど、相性がいいと考えられます。

どんなチームに向き、どこで止まるか

向くのは、React系のプロダクトを持ち、デザイナーとエンジニアが同じリポジトリで働いているチームです。デザインの意図をコードに落とす工程を短くしたい場面、変更の履歴をブランチで管理したい場面。この2つが日常的に発生する組織なら、相性はいいと考えられます。向かないのは、技術スタックがReact以外のチーム、コードを触らない非エンジニアだけのチーム、そして費用を先に確定させたい予算の厳しい組織です。向き不向きを分けるのは、ツールの使い勝手ではなく、プロダクトのコードがReactで書かれているかどうかです。

FigmaやMagic Patternsとの違いは？比較の軸を3つに絞る

比較の前提として、編集画面の使い勝手や生成品質の優劣は書けません。同じ題材で操作を比べた検証をしていないためです（未検証）。公開情報で並べられるのは、道具の性格の違いまでです。軸は3つに絞れます。編集する対象、AIの持ち方、そして成果物の置き場所です。

Figmaとの違いを一言で書くなら「絵を触るか、コードを触るか」です。Figma AIは、画面の設計図をチームで作る道具として定着しています。誰でも同じ画面を見て話せることが強みで、コードを書かない人が参加しやすい。Onlookは逆で、コードを読めないと会話に入りにくい。どちらが上かではなく、議論の参加者にコードを書く人が何人いるかで選ぶのが正しい。デザインの会議にエンジニアが同席するチームほど、Onlookの強みは大きくなります。

Magic Patternsとの違いは、作業の向きです。Magic Patternsは、案を作って実装に渡すところまでを担います。Onlookは、動いているコードそのものを編集する道具です。前者は「作る前」、後者は「作った後」に強い。既存のプロダクトの改善が中心なら、Onlookのほうが近道になる場面が多いと考えられます。

他の候補も同じ軸で並べられます。LovableやReplitは、指示から動くアプリを作って公開まで進む方向です。Cursorはコードを書く道具で、Onlookと同じ層に置かれますが、触る対象はエディタの中のテキストです。BubbleやSoftr、WeWebは、コードを書かずにアプリを組む方向。Uizardは案を作る方向、Shipixenはテンプレートからサイトを立ち上げる方向です。用途が「速く公開したい」なら生成ツール、「既存のコードを磨きたい」ならOnlookが候補になります。

比較の表で一つ補足しておきます。Onlookは「コードが正」、Figmaは「絵が正」、生成ツールは「指示が正」と、それぞれ何を拠りどころにするかが違います。この違いは、修正のときに表れます。コードが正なら、修正はコードを直すことそのものです。絵が正なら、修正は絵を直してからコードに反映する作業になります。どちらの負担が軽いかは、チームの編成で決まります。

3つの軸で自分のチームを置いてみる

編集する対象、AIの持ち方、成果物の置き場所。この3つに自社の状況を置くと、候補は2つほどに絞れます。迷ったら、直近1か月で「デザインの意図がコードに伝わらず手戻りした」件数を思い出してください。その件数が多いチームほど、コードを直接触る道具の強みは大きくなります。逆に、手戻りがほとんどないなら、無理に道具を替える理由は薄い。手戻りの件数が、この道具を入れるかどうかの一番素直な物差しになります。

導入前に決めること。小さく試す順序

最初に決めるのは、どのプロジェクトで試すかです。本番のリポジトリをいきなり触るのは避け、社内の小さな画面から始めるのが安全です。設定画面や一覧画面のように、部品の使い方が決まっている画面は、評価の結果が読みやすい。逆に、演出の多いランディングページは、コードの編集より画像の扱いが中心になり、評価の軸がぶれます。

試す順序は4段です。React系のプロジェクトを1つ選び、ブランチを切る。セルフホストかダウンロード版で、画面を開いて部品を1つ動かす。変更がコードにどう反映されるかを、差分で確認する。その結果を見て、チーム利用の見積りを依頼するかどうかを決める。先に見るのは画面の見栄えではなく、変更の差分の読みやすさです。ここが読みにくいと、レビューの工程で詰まります。

記録する項目は3つに絞ります。部品を1つ動かすのにかかった時間。コードの差分をレビューできたかどうか。そして、元に戻す操作が分かりやすかったか。この3つが揃えば、テキストを編集する道具との比較も同じ物差しでできます。「操作しやすかった」という感想は、翌週には曖昧になります。差分の読みやすさだけが残ります。

AIの契約の確認も、最初に済ませてください。公式はClaudeとChatGPTのプランを挙げていますが、どのプランでどの機能が動くかは、公開情報からは読み取れません（未検証）。社内で既に契約しているプランを並べ、試す前に担当者へ確認する。この一手間が、試作の途中で止まる事故を減らします。

最初の1か月に揃える3つの記録

初月の目標は、継続の判断材料を3つ集めることです。差分のレビューにかかった時間。手戻りが減った件数。そして、見積りを取った場合の費用の見通し。この3つが揃えば、チーム展開の判断は、印象ではなく記録の話になります。見積りの依頼は、試作の結果が出る前に出しておくと、判断の時期を逃しません。

よくある質問

まとめ

主な参照元：Onlook公式サイト「Onlook — The Developer Tool for Visual Engineers」（2026年11月6日確認。位置づけの説明、キャンバスの考え方、AIの契約の記載、機能の一覧、対応スタック、対応OSとディスク容量、GitHubのスター数表示、利用者の声はここによります）。Onlook公式の料金ページ（2026年11月6日確認。FreeとFor Teamsの2段、For Teamsのカスタム見積り、セルフホストが無料である旨のFAQ、For Teamsの機能一覧はここによります）。月額の数字は公式ページに存在しないため記載していません。編集画面の動作、生成されるコードの品質、AIの無料プランでの利用可否、日本語UIの使い勝手は未検証です。実機検証は未実施です。