Figma MakeにClaude Opus 4.6が追加された背景と実験モデル設定の位置づけ

Figma MakeにClaude Opus 4.6が追加された背景と実験モデル設定の位置づけ

Figma Makeは2025年5月のConfig 2025で初披露されたAIプロトタイピング機能で、自然言語のプロンプトからインタラクティブなUIやコードを自動生成できます。同機能を支えるAIモデルとして、当初からAnthropicのClaudeシリーズが採用されてきましたが、2026年2月にはClaude Opus 4.6が新たに選択可能となり、実験モデル設定を通じてすぐに試せる環境が整いました。ここでは、Figma MakeとClaude Opus 4.6の統合がどのような経緯で実現し、ユーザーにとって何が変わったのかを整理します。

2025年5月のConfig発表から2026年2月のOpus 4.6搭載までの主要アップデート経緯

Figma Makeが最初に公開されたのは2025年5月のFigma Config 2025で、当時はClaude 3.7 Sonnetをデフォルトモデルとして採用していました。その後、2025年7月25日に日本を含む全世界で一般提供が開始され、スタータープラン（無料）でも限定的に利用できる体制が整っています。2025年11月にはコネクタ連携機能が追加され、外部ツールのPRDやチケットをFigma Makeに取り込んで実データ反映型のプロトタイプを作れるようになりました。そして2026年2月5日にAnthropicがClaude Opus 4.6を正式発表すると同時に、FigmaはMakeの実験モデル設定にOpus 4.6を追加しています。このように約9か月の期間で、Figma MakeはAIモデルの世代交代を含む複数回の大型アップデートを経てきました。モデルが進化するたびにFigma Make自体の出力品質も向上するという好循環が生まれており、Figmaの製品戦略としてもAI基盤の継続的な強化が最重要課題に位置づけられていることがわかります。

Figma MakeがClaude一本に統一された技術パートナーシップの判断基準

Figma MakeがAIモデルとしてClaudeを一貫して採用している背景には、コード生成品質・デザイン意図の忠実な再現・処理速度のバランスが高い水準で両立されている点があります。FigmaのChief Design OfficerであるLoredana Crisan氏は、Opus 4.6について「複雑なインタラクティブアプリやプロトタイプを幅広いクリエイティブレンジで生成できる」と評価しており、設計意図を初回のプロンプトでコードに落とし込める一貫性が採用の決め手になったことが読み取れます。また、Figma側ではAIモデルの改善がそのまま製品品質の向上につながるという方針を掲げており、特定のモデルプロバイダーと深く連携することでモデル更新のたびにユーザー体験を底上げできる構造を重視しています。複数プロバイダーを併用する場合に生じる出力品質のばらつきや、プロンプト設計の使い分けコストを回避できる点も、実務的に大きなメリットといえるでしょう。

実験モデル設定で最新AIを即時利用できる仕組みと通常モードとの切替条件

Figma Makeには「実験モデル設定（experimental models setting）」が用意されており、これを有効にすると最新リリースされたClaudeモデルをいち早く利用できるようになります。通常モードではFigma側が安定性を検証済みのモデル（従来のSonnet系列）が自動選択されますが、実験モデル設定をオンにするとOpus 4.6のような新しいモデルに切り替えることが可能です。この設定はFigma Makeのファイル画面から操作でき、フルシート権限を持つユーザーが対象となります。実験モデルは安定版と比較して処理時間が長くなるケースや、まれに予期しない出力が生成されるケースがある反面、コード生成精度やインタラクション品質の面では明確な向上が期待できます。チームでの運用では、安定版と実験版を併用しながら重要度の高いプロトタイプにだけOpus 4.6を使う段階的な導入が現実的な選択肢となるでしょう。

Opus 4.6の1Mトークンコンテキストがプロトタイプ生成にもたらす実務上の変化

Claude Opus 4.6はOpus系列としては初めて100万トークンのコンテキストウィンドウを搭載しました。これは約75万語・3,000ページ分に相当し、大規模なデザインシステムや複数画面のアプリケーション仕様を一度のプロンプトに含めても、モデルが文脈を見失わずにコード生成を継続できることを意味します。従来のモデルでは、長大な仕様書を渡すとコンテキスト上限に到達してCompact（要約・圧縮）が走り、途中で前提条件が欠落して再現度が大幅に低下するという問題がありました。Opus 4.6であればプロジェクト全体のスタイルガイド、コンポーネント仕様、画面遷移フローを一括でインプットできるため、画面間の一貫性を維持したプロトタイプ生成が格段に安定します。複数画面をまたいだ状態管理やナビゲーションロジックの整合性が求められるSaaS系プロダクトのPoC制作などでは、この大容量コンテキストが顕著な効果を発揮するでしょう。

デザイナー・PM・エンジニア全員がコードを書かず参加できる役割変化の実態

Figma MakeにOpus 4.6が搭載されたことで、プロダクト開発における従来の役割分担が大きく変化しつつあります。従来のワークフローでは、デザイナーが静的なモックアップを作成し、エンジニアがそれをコードに起こすという直列的なプロセスが一般的でした。しかしFigma Makeでは、テキストプロンプトから直接React＋TypeScriptベースの動くプロトタイプが生成されるため、プロダクトマネージャーが自らアイデアをプロトタイプ化して仮説検証に進めたり、エンジニアがデザインの方向性をコード付きで提案したりすることが可能になっています。Figma社自身も「エンジニアがデザインし、PMがプロトタイプを作り、デザイナーがソフトウェアを出荷する」という役割のクロスオーバーが起きていると説明しており、Opus 4.6の高精度なコード生成がこの流れをさらに加速させています。非エンジニアでも手戻りの少ない機能プロトタイプを短時間で作れるようになったことは、組織全体の意思決定スピードに直結する変化です。

従来のSonnetモデルと比較したOpus 4.6のコード生成精度と対応範囲の違い

Figma MakeではこれまでClaude Sonnet系列がデフォルトモデルとして使われてきましたが、Opus 4.6の追加により出力品質に大きな差が生まれています。どのような場面でOpus 4.6が真価を発揮し、逆にSonnetで十分な場面はどこなのか、ベンチマーク数値と実務経験の両面から整理します。

Sonnet 3.5からOpus 4.6へ移行した場合のベンチマーク数値比較と実用差

Claude Opus 4.6は、経済的に価値の高いナレッジワークタスクを評価するGDPval-AAにおいて、前世代のOpus 4.5を190 Eloポイント上回り、業界次点のGPT-5.2を約144 Eloポイント凌駕しています。エージェント型コーディング評価であるTerminal-Bench 2.0では全モデル中最高スコアの65.4%を達成し、コンピュータ操作タスクのOSWorldでも72.7%とトップの成績です。一方、Figma Makeの従来モデルだったSonnet 3.5は、基本的なUI生成やシンプルなインタラクションでは十分な精度を出していたものの、複数画面をまたいだ状態管理や条件分岐の多いロジックではプロンプトの追加指示を繰り返す必要がありました。Opus 4.6はこうした多段階の推論を必要とするタスクで特に強みを発揮するため、Figma Makeで生成するプロトタイプの複雑度が上がるほど実用差が顕著に表れます。単純なランディングページの生成ではどちらのモデルでも大きな差は出にくい一方、業務アプリケーションレベルのプロトタイプではOpus 4.6への移行メリットが明確です。

複雑なインタラクション生成でOpus 4.6が初回成功率を高められる3つの理由

Opus 4.6がFigma Makeにおける初回プロンプトの成功率を高めている要因は主に3つあります。第一に、計画性の向上です。Opus 4.6はタスクに取りかかる前により深く思考し、推論を慎重に再検討する傾向があるため、複数のインタラクションパターンを含むプロンプトでもロジックの整合性を維持したコードを出力できます。第二に、長時間のエージェント型タスクへの耐性です。従来のモデルでは大規模な生成タスクの途中でコンテキストが劣化し、後半の画面で品質が落ちる問題がありましたが、Opus 4.6はセッション全体を通じて安定した品質を保つ設計になっています。第三に、自己修正能力の向上です。Opus 4.6はコードレビューやデバッグのスキルが強化されており、生成したコードの不整合を自ら検出して修正できるため、ユーザーが細かなバグ修正を都度指示する手間が軽減されます。これら3つの要素が重なることで、1回のプロンプトで意図通りの動作をするプロトタイプが得られる確率が大幅に向上しています。

レスポンシブ対応やアニメーション処理でSonnetでは失敗しやすかったパターン

Figma Makeの従来のSonnetモデルでは、レスポンシブデザインの実装において、コンテナの最大幅・最小幅の設定が不十分なまま出力されるケースが散見されました。たとえばモバイル表示時にカラムが折り返されず画面からはみ出す、特定のブレイクポイントでフォントサイズの切替が反映されないといった問題です。また、CSSアニメーションやスクロール連動エフェクトの実装では、keyframeの定義が中途半端だったり、transition-durationの指定が省略されたりすることがありました。Opus 4.6では、FlexboxやCSS Gridといったモダンレイアウトシステムの使い分けがより正確になり、メディアクエリの設計精度も向上しています。アニメーションについても、scroll-behaviorの指定やHTML5のdialog要素を活用したモーダル表示など、パフォーマンスを意識したコード選択が自動的に行われます。デザインのプレビュー画面がモバイル・タブレット・PCの3サイズで確認できるFigma Makeの特性と組み合わせることで、出力直後にレスポンシブ挙動を即検証できるワークフローが成り立ちます。

大規模デザインシステムの読み取り精度がモデル選択で変わる判断ポイント

企業規模のデザインシステムをFigma Makeに取り込んでプロトタイプを生成する場合、モデルの読み取り精度が出力品質に直結します。デザインシステムには色・タイポグラフィ・余白のトークン、コンポーネントのバリエーション、インタラクションガイドラインなど膨大な情報が含まれていますが、コンテキストウィンドウが小さいモデルではこれらの情報を網羅的に保持できず、出力に抜け漏れが生じます。Opus 4.6の100万トークンコンテキストであれば、デザインシステム全体の仕様を一度に読み込むことが可能で、カラーバリアブルの値、フォントスケールの対応関係、スペーシングの規則をすべて反映したコードが生成されます。実務的な判断基準としては、コンポーネント数が50個を超えるデザインシステムを扱う場合や、ブランドガイドラインに厳密な準拠が求められるプロジェクトでは、Opus 4.6の選択が推奨されるでしょう。一方で、3〜5画面程度の小規模プロトタイプであればSonnet系列でも十分な精度が得られるケースが多いため、プロジェクトの規模に応じた使い分けが重要になります。

Opus 4.6とSonnet 4.5をFigma Make内で使い分ける実務シナリオ別の選定基準

Figma Makeで利用可能なモデルを適切に使い分けるには、タスクの複雑度・処理速度・クレジット消費のバランスを考慮する必要があります。Opus 4.6は高精度な反面、Sonnet 4.5と比較して処理時間が長く、消費クレジットも多い傾向があるためです。具体的には、PoCや投資家向けデモなど高品質が求められるプロトタイプにはOpus 4.6を割り当て、社内ブレスト用のラフプロトタイプやA/Bテスト用の複数パターン生成にはSonnet 4.5を使うという分け方が効率的です。また、既存のFigmaデザインをそのまま動かす変換作業（1→1）は比較的定型的なため、Sonnet 4.5でも高い成功率が見込める一方、ゼロからアプリ全体を生成する作業（0→1）では推論力の高いOpus 4.6が適しています。チームで運用する場合は、どのモデルをどのタスクタイプに使うかの選定ルールを事前に策定しておくと、クレジットの無駄遣いを防ぎつつ品質の一貫性を担保できるでしょう。

Figma MakeでClaude Opus 4.6を有効化するための設定手順と前提条件

Opus 4.6をFigma Makeで利用するには、プランとシートの条件確認、実験モデル設定の有効化、デザインファイルの事前整備といった複数のステップを正しく踏む必要があります。ここでは、個人利用からチーム導入まで対応できる具体的な手順を解説します。

実験モデル設定をオンにする操作手順とフルシート権限の確認方法

Figma MakeでOpus 4.6を使うには、まず自身のアカウントがフルシート権限を持っていることを確認する必要があります。フルシートかどうかは、Figmaのファイルブラウザ左サイドバーの表示内容で判別できます。「すべてのプロジェクト」が表示されていればスターターまたはプロフェッショナルプラン、「すべてのチーム」が表示されていればビジネスまたはエンタープライズプランです。フルシートの確認後、Figma Makeの新規ファイルを作成し、設定メニュー内にある実験モデル設定（experimental models）のトグルをオンに切り替えます。この操作により、AIチャットのプロンプト入力時にモデルドロップダウンからClaude Opus 4.6を選択できるようになります。なお、Dev・コラボ・閲覧シートのユーザーはドラフトでの限定利用となるため、実験モデル設定の一部が制限される点に注意してください。設定変更は即時反映されるため、再ログインやキャッシュクリアは不要です。

Business・Enterpriseプランで管理者がAI機能を組織全体に適用する際の5ステップ

ビジネスおよびエンタープライズプランでは、AI機能自体を組織単位でオン・オフ制御できるため、管理者が事前に有効化しておく必要があります。手順は以下の5段階です。まず管理者アカウントでFigmaにログインし、左サイドバーの「管理者」セクションから設定画面にアクセスします。次に、AI機能のトグルが「有効」になっていることを確認し、無効の場合はオンに切り替えます。続いて、Figma Makeの公開機能の制御トグル（Webサイトとアプリの公開をオン・オフにする設定）を組織のセキュリティポリシーに合わせて調整します。その後、チームメンバーのシートタイプを確認し、Figma Makeのフル機能を使うメンバーにはフルシートが割り当てられていることを確認してください。最後に、AIクレジットダッシュボードで組織全体のクレジット配分を確認し、2026年3月18日以降のクレジット上限適用に備えた運用計画を策定します。これら5ステップを事前に済ませておくことで、メンバーがOpus 4.6を即座に利用できる環境が整います。

Starterプラン（無料）ユーザーがOpus 4.6を試す場合のクレジット上限と制約

スタータープランでもFigma Makeは利用できますが、いくつかの制約があります。月間のAIクレジット上限は500クレジットで、さらに1日あたり150クレジットという日次上限も設けられています。Opus 4.6はSonnet系列よりリクエストあたりのクレジット消費が大きい傾向にあるため、0からのアプリ画面生成（100クレジット以上の消費が一般的）を行うと、数回の試行でクレジットを使い切る可能性があります。また、スタータープランでは共有可能なFigma Makeファイルが3つまでに制限されており、Webへの公開もFigmaコミュニティ経由に限定されます。これらの制約を踏まえると、スタータープランでのOpus 4.6利用は「お試し」の域を出ないため、継続的な業務利用を前提とするならプロフェッショナルプラン以上へのアップグレードを早期に検討すべきです。まずはスタータープランでOpus 4.6のコード品質を数回のプロンプトで確認し、費用対効果に納得してから有料プランに移行するという段階的な導入が合理的でしょう。

既存のFigma Designフレームを取り込む際にオートレイアウト整備が必要な理由

Figma Makeに既存のデザインフレームを取り込んで動くプロトタイプに変換する場合、入力データの品質が出力品質を大きく左右します。特にオートレイアウトの設定が不十分なフレームを渡すと、AIがレイアウトの意図を正しく解釈できず、コンテナの幅が画面をはみ出したり、要素の並び順が崩れたりする問題が発生します。Opus 4.6は文脈理解力が高いとはいえ、デザインデータ自体にレイアウトの意図が構造的に記述されていなければ、推測に頼った出力にならざるを得ません。具体的には、フレームに適切な制約（Constraints）を設定し、オートレイアウトで最大幅・最小幅・パディングを明示しておくことが推奨されます。さらに、レイヤー名をレイヤーの内容や目的を反映した名前に変更しておくと、AIがコンポーネントの役割を理解しやすくなります。FigmaにはAIによるレイヤー名自動変更機能やClean Documentプラグインが用意されているので、これらを活用してフレームを整理してからMakeに送るのが効率的です。

設定後にモデルが切り替わらない場合の3つの原因と確認すべきチェック項目

実験モデル設定をオンにしたにもかかわらずOpus 4.6が選択肢に表示されない場合、主に3つの原因が考えられます。第一の原因は、組織の管理者がAI機能をオフに設定しているケースです。ビジネスプランおよびエンタープライズプランでは管理者がチームまたは組織全体のAI機能を一括制御できるため、個人の設定だけではモデルが有効化されません。この場合は管理者に確認を依頼してください。第二の原因は、シートタイプの不一致です。Figma Makeのフル機能はフルシートのみで利用可能であり、Dev・コラボ・閲覧シートでは実験モデル設定が制限される場合があります。管理者設定画面で自身のシートタイプを確認してください。第三の原因は、地域やアカウントの段階的ロールアウトによるタイムラグです。新機能は全ユーザーに同時展開されるわけではないため、一時的にモデルが表示されないことがあります。数日待っても解決しない場合は、Figmaサポートへの問い合わせが有効です。

Opus 4.6搭載Figma Makeで高品質プロトタイプを生成するプロンプト設計の実務指針

Opus 4.6の性能を最大限に引き出すには、モデルに渡すプロンプトの設計品質が決定的に重要です。漠然とした指示では高機能モデルでも意図通りの出力は得られません。ここでは、初回プロンプトの構成から反復的な改善フローまで、実務で使えるプロンプト設計手法を具体的に示します。

画面一覧・デザインテイスト・ペルソナを含む初回プロンプトの構成要素と記述例

Figma Makeで高品質な出力を得るための初回プロンプトには、5つの構成要素を盛り込むことが効果的です。第一に「作りたいものの概要」として、アプリの種類・主要機能・目的を明記します。第二に「必要な画面一覧」として、ホーム画面・検索画面・詳細画面など具体的な画面名を列挙します。第三に「デザインテイスト」として、モダン・ミニマル・ニューモーフィズムなどのスタイルキーワードやメインカラーのカラーコードを指定します。第四に「ターゲットユーザーのペルソナ」として、年代・リテラシー・利用シーンなどの情報を添えます。第五に「技術的な制約」として、レスポンシブ対応やアクセシビリティ要件を明示します。たとえば「30代のビジネスパーソン向けのタスク管理アプリ。ホーム画面・タスク一覧・詳細画面の3画面構成。メインカラー#3B82F6のモダンデザインで、モバイルファーストのレスポンシブ対応」のように、具体性の高いプロンプトを初回から渡すことで、Opus 4.6の推論能力を無駄なく活かせます。

guidelines.mdファイルでブランド仕様を事前定義するとトーン統一率が上がる仕組み

Figma Makeにはコードエディタ上で利用できるguidelines.mdファイルが用意されており、ここにブランドガイドラインやコーディング規約を記述しておくと、AIがプロンプト処理時に参照してくれます。たとえば、カラーパレットの定義（プライマリ:#1E40AF、セカンダリ:#F59E0B）、フォントファミリー（Noto Sans JP）、ボタンの角丸サイズ（8px）、余白の基本単位（8pxグリッド）などを明記しておくことで、毎回のプロンプトにこれらの仕様を書く手間が省け、複数回の生成でも一貫したビジュアルが維持されます。Opus 4.6は長いコンテキストを正確に保持できるため、guidelines.mdに詳細な仕様を記述しても情報の欠落が起きにくい点が強みです。チームで運用する場合は、guidelines.mdの内容をデザインシステムのドキュメントと連動させて管理することで、Figma Make上で生成されるすべてのプロトタイプがブランド基準を満たす体制を構築できます。

フォローアップ指示で部分修正する際に全体レイアウトが崩れる失敗の回避策

Figma Makeで生成したプロトタイプの一部を修正しようとフォローアップのプロンプトを送ったところ、修正箇所以外のレイアウトまで変わってしまったという失敗は、多くのユーザーが経験する問題です。この現象を防ぐには、まずFigma Makeのターゲット選択機能（矢印ボタン）を活用し、修正対象のコンポーネントを明示的に選択してからプロンプトを入力する方法が有効です。「ヘッダーのナビゲーションを3項目から5項目に増やして、他の部分は一切変更しないでください」のように、変更範囲と非変更範囲を両方明記する指示も効果的でしょう。それでも全体に影響が出てしまう場合は、Figma Makeの履歴機能で修正前の状態に戻し、プロンプトの粒度を細かくして再試行します。また、調整箇所が多すぎる場合は新しいFigma Makeファイルを作成してゼロからやり直し、初回のプロンプトに前回の学びを盛り込んだ網羅的な指示を書くほうが効率的なケースもあります。

コードエディタ併用で「プロンプト→手動微調整」を繰り返す反復ワークフロー

Figma Makeにはプレビュー画面とコードエディタの2つのタブが用意されており、生成されたReact＋TypeScriptのソースコードを直接編集できます。この機能を活用した効率的なワークフローは、まずプロンプトでプロトタイプの大枠を生成し、次にコードエディタで細かなスタイル調整やロジックの修正を行い、さらに必要に応じてプロンプトで追加機能を依頼するという反復サイクルです。たとえば、プロンプトで「ダッシュボード画面を生成」した後、コードエディタ上でパディングの値を4pxから8pxに変更し、その上でプロンプトに「グラフコンポーネントを追加して」と指示するといった流れになります。この方法の利点は、プロンプトだけでは伝えにくい微細な数値調整をコードレベルで即座に反映できる点と、コード修正の結果をプレビューでリアルタイム確認できる点です。Opus 4.6は生成するコードの可読性が高いため、TypeScriptに慣れたエンジニアであればコードエディタでの直接修正も容易に行えるでしょう。

0→1生成と既存デザイン変換（1→1）でプロンプト構造を切り替える判断基準

Figma Makeには、ゼロからプロンプトで新規生成する「0→1」と、既存のFigma Designフレームを取り込んでインタラクティブ化する「1→1」の2つの利用パターンがあります。0→1ではアプリの全体像をテキストで詳細に記述する必要があるため、前述の5構成要素を含む長めのプロンプトが有効です。一方、1→1ではすでにデザインの視覚情報がインプットとして存在するため、プロンプトはインタラクションの定義に集中します。「このデザインをインタラクティブなプロトタイプに変換して。ボタンクリックで画面遷移し、フォームには入力バリデーションを追加して」のように、動きの仕様だけを簡潔に伝える構造です。判断基準としては、参照できる既存デザインがあり品質も十分であれば1→1を選び、コンセプト段階でまだ形がない場合は0→1を選びます。なお、1→1の場合はフレームのオートレイアウト整備が出力品質を大きく左右するため、前述のデザインデータ整備を必ず先に行ってからMakeに送ることが重要です。

AIクレジット消費量とプラン別コストから見るOpus 4.6運用の費用対効果

2026年3月18日以降、Figma AIの全機能にクレジット上限が正式適用されるため、Opus 4.6をFigma Makeで運用する際のコスト管理が重要になります。ここでは、実測ベースの消費データとプラン別の料金構造を基に、費用対効果の具体的な判断材料を提示します。

シンプル実装20〜26・実用実装100〜150クレジットの消費実測値と変動要因

Figma Makeでは、リクエストの複雑さや使用モデルに応じてクレジット消費量が変動します。実際の検証データによると、シンプルなUI（たとえばボタンとテキストだけの単一画面）の生成では20〜26クレジット程度の消費にとどまりますが、複数のインタラクションや状態管理を含む実用的なアプリ画面では100〜150クレジット前後を消費するのが一般的です。さらに複雑な生成（多画面のSaaS型ダッシュボードなど）では200〜300クレジットに達することもあります。変動要因としては、プロンプトの文字数、参照するデザインフレームの複雑度、フォローアップの回数が大きく影響します。Opus 4.6はSonnet系列より推論にリソースを多く使う設計であるため、同じタスクでもやや多めにクレジットを消費する可能性がある点を見込んでおくべきです。クレジット消費量はFigma Make画面上で確認できるようになっているため、初めて使うタスクタイプでは消費量を記録して自チームの平均値を把握しておくことをおすすめします。

Professional月3,000・Business月3,500クレジットで月間何件の生成が可能か

プランごとの月間クレジット数と1回あたりの平均消費量から、月間の生成可能件数を算出できます。平均消費量を110クレジット/回と仮定した場合、プロフェッショナルプラン（月3,000クレジット）では約27回、ビジネスプラン（月3,500クレジット）では約32回、エンタープライズプラン（月4,250クレジット）では約39回の生成が可能です。ただしこの数値はFigma Make単体での消費を前提としており、背景削除（1〜5クレジット）、画像生成（5〜25クレジット）、AIテキスト調整などFigma全体のAI機能でもクレジットが消費される点に注意が必要です。Opus 4.6を積極的に使う場合は、平均消費量がSonnet利用時より10〜30%程度多くなる可能性があるため、月間25回前後を目安に見込むのが安全でしょう。1人のデザイナーが週に5〜7回のプロトタイプ生成を行うワークスタイルであれば、プロフェッショナルプランの範囲内で運用可能です。

2026年3月18日のクレジット上限適用後にフルシートユーザーが受ける影響

2026年3月18日までは、有料プランのフルシートユーザーはAIクレジットを実質無制限で使えていましたが、この日を境にプラン別の月間上限が正式に適用されます。プロフェッショナルプランで月3,000クレジット、ビジネスプランで月3,500クレジット、エンタープライズプランで月4,250クレジットが上限となり、繰り越しはできません。これまで回数を気にせずにOpus 4.6を含むAI機能を使い倒していたチームにとっては、利用スタイルの見直しが必要になるでしょう。特にFigma Makeを主要な業務ツールとして日常的に使っているチームでは、月の後半にクレジットが枯渇するリスクが高まります。対策としては、タスクの優先度に応じてモデルを使い分ける（重要度の低いタスクにはSonnetを使う）、プロンプトの精度を上げて試行回数を減らす、2026年3月11日から提供開始される追加クレジットサブスクリプションを事前に検討するといった方法が挙げられます。

追加クレジットサブスクリプション（月$120〜$240）と従量課金の損益分岐点

2026年3月11日以降、管理者はAIクレジットサブスクリプションを通じて追加のクレジットプールを購入できるようになります。料金体系は、5,000クレジットで月$120（単発購入$150）、7,500クレジットで月$180（単発$225）、10,000クレジットで月$240（単発$300）という3つのティアが用意される予定です。サブスクリプションのクレジットは組織の共有プールとして運用され、フルシートの付与クレジットを使い切った承認ユーザーが利用できます。さらに2026年第2四半期には従量課金オプションも登場予定で、使った分だけの請求方式も選択可能になります。損益分岐点を検討する際は、チーム全体の月間クレジット消費量を計測したうえで、基本プランの付与分で足りるか、サブスクリプションの最小ティア（5,000クレジット）で補えるか、従量課金のほうが安くなるかを比較してください。月間消費量のばらつきが大きいチームは従量課金、安定的に高消費のチームはサブスクリプションが向いています。

外部エージェンシー委託費用（$8,000〜$25,000）との比較で見る内製化の経済性

プロフェッショナルなWebサイトやアプリのプロトタイプをエージェンシーに委託した場合、一般的な費用は$8,000〜$25,000で、制作期間は4〜8週間です。複雑なECサイト構築では$20,000〜$60,000以上に達するケースもあります。一方、Figma MakeにOpus 4.6を組み合わせた内製化の場合、プロフェッショナルプラン（月額$15/ユーザー）の範囲内で月27回程度の生成が可能であり、1回あたりのコストは約$0.55（約80円）です。API経由でClaude Opus 4.6を直接利用する場合でも、入力100万トークンあたり$5、出力100万トークンあたり$25という料金設定のため、1回のプロトタイプ生成にかかるAPI費用はごく少額に抑えられます。もちろん、Figma Makeの出力はそのまま本番プロダクトに使えるレベルではなく、PoCや初期検証のフェーズに適した品質です。しかし「アイデアの検証に数週間と数百万円をかける」従来のフローから「数分と数十円で動くプロトタイプを確認する」フローへの転換は、特にスタートアップや新規事業開発において大きなコスト優位性をもたらします。

Supabase連携やFigma Sitesを活用したOpus 4.6プロトタイプの公開・拡張フロー

Figma Makeで生成したプロトタイプは、プレビュー確認にとどまらず、Supabase連携による動的Webアプリ化やFigma Sitesでのノーコード公開まで展開できます。Opus 4.6の高品質コード生成を活かして、検証から公開までを一気通貫で進めるフローを解説します。

Supabase接続で認証・データ保存・シークレット管理を追加する設定手順

Figma MakeはSupabaseとの公式連携に対応しており、接続することでユーザー認証、データベースへの保存、APIキーなどのシークレット管理機能をプロトタイプに追加できます。設定手順は、まずSupabaseのアカウントを作成してプロジェクトを新規作成し、プロジェクトURL・anon key・service role keyを取得します。次に、Figma Makeの設定画面からSupabase接続を選択し、取得したURLとキーを入力して認証を完了させます。接続後は、プロンプトで「ユーザーログイン機能を追加して」「タスクデータをSupabaseに保存して」のように指示するだけで、認証フローやCRUD操作のコードが自動生成されます。Opus 4.6の高い推論力により、認証後のリダイレクト処理やエラーハンドリングも含めた完成度の高いコードが初回から得られるケースが増えています。これにより、単なる見た目のプロトタイプではなく、実際にデータの読み書きができる「動くプロトタイプ」を短時間で構築できます。

Figma Sitesでレスポンシブ対応Webページとしてノーコード公開する具体的工程

Figma MakeとFigma Sitesを組み合わせることで、生成したプロトタイプをレスポンシブ対応のWebページとして直接公開できます。工程としては、まずFigma Makeでプロトタイプを生成・調整し、プレビュー画面で最終確認を行います。次に、Figma SitesのWebサイト公開機能を使って、作成したコンテンツを独自URLまたはFigmaドメインで公開します。公開設定ではカスタムドメインの接続やパスワード保護なども可能です。なお、Figma Sites自体はFigma Designで作成したフレームをWebページに変換する機能であるため、Figma Makeの出力をFigma Sitesに直接連携するには、Figma Makeのプレビューから「デザインをコピー」機能でフレームをFigma Designに取り込み、Figma Sites上で最終調整を行うという流れになります。ノーコードで公開まで完結できるため、エンジニアのリソースを確保できない初期検証フェーズや、社内向けのツール公開には特に有効な選択肢です。

コネクタ連携でPRDやチケットを取り込み実データ反映型プロトタイプを作る実務例

2025年11月に追加されたコネクタ連携機能を使えば、外部ツールからPRD（プロダクト要求仕様書）やプロジェクトチケットをFigma Makeに直接取り込むことができます。たとえばJiraやLinearのチケット情報を接続し、要件定義の内容をAIに参照させながらプロトタイプを生成するといった使い方が可能です。実務的な活用例としては、プロダクトマネージャーがPRDを作成した後、そのドキュメントをFigma Makeに接続し、「このPRDの要件に基づいてダッシュボード画面を生成して」とプロンプトを入力するフローがあります。Opus 4.6は大量のテキスト情報を正確に読み取る能力が高いため、PRDに記載された機能要件・画面遷移フロー・ビジネスルールをコードレベルで反映したプロトタイプが得られます。さらに、Figma Makeから接続しているドキュメントを更新したりタスクを作成したりすることも可能で、プロトタイプの検証結果を即座にプロジェクト管理ツールにフィードバックする双方向の運用ができます。

公開後のSEO設定・OGP対応・アクセス解析連携における現時点の制約と代替手段

Figma Makeで生成したプロトタイプをWebに公開する場合、現時点ではSEO設定（メタディスクリプション、canonical URL、構造化データ）、OGP（Open Graph Protocol）対応、Googleアナリティクスなどのアクセス解析ツールとの連携に制約があります。Figma Sitesは2025年5月の発表時点でベータ版として提供されており、本格的なWebサイト運用に必要なこれらの機能は順次追加予定とされていますが、現時点では完全にはサポートされていません。代替手段としては、Figma Makeで生成したコードをエクスポートし、Next.jsやGatsby.jsなどのフレームワーク上に移植したうえでSEO設定やアクセス解析を追加する方法が考えられます。また、ランディングページや期間限定のキャンペーンページなどSEO要件が低いコンテンツであれば、Figma Sitesでの公開でも実用上の問題は少ないでしょう。プロトタイプとしての検証が目的であれば、SEO対応よりもユーザビリティテストの実施に注力し、本番実装の段階で改めてSEO最適化を行う段階的なアプローチが合理的です。

StarterプランとフルシートでWeb公開方法が異なる権限差を事前に把握する重要性

Figma Makeで作成したプロトタイプの公開方法は、利用しているプランとシートタイプによって大きく異なります。スタータープラン（無料）のユーザーは、Figmaコミュニティを通じてのみWebに公開が可能です。つまり、公開されたプロトタイプはFigmaコミュニティ上で誰でも閲覧できる状態になるため、社内限定の検証用途や未公開プロダクトのプロトタイプには不向きです。一方、有料プランのフルシートユーザーは、コミュニティに公開せずに直接Webに公開できるため、特定の関係者だけにURLを共有するクローズドな検証が可能です。さらにビジネスプランの管理者は、組織全体でWebサイトとアプリの公開をオン・オフに制御するトグルを使えます。この権限差を事前に把握しておかないと、クライアント向けのデモを作ったのに公開方法が限られていて共有できないといったトラブルが起きかねません。プロジェクト開始前に、プロトタイプの共有先・公開範囲を確認し、必要なプラン・シートを確保しておくことが重要です。

チーム導入時にOpus 4.6モデルを安定運用するための設計ルールと注意点

Figma MakeとOpus 4.6をチームで本格運用するには、セキュリティ・コスト管理・データ整備・ファイル運用の各側面でルールを事前に整備する必要があります。ここでは、運用開始後によく発生する問題とその予防策を具体的に解説します。

プロンプトに機密データを含めないための社内ガイドライン策定ポイント5項目

Figma Makeのプロンプトにはテキスト情報やデザインデータが含まれるため、機密情報の取り扱いルールを明確にしておく必要があります。策定すべきポイントは5つです。第一に、個人情報（氏名・メールアドレス・電話番号など）をプロンプトに直接入力しない旨を明文化します。第二に、社内秘の設計仕様や未公開プロダクトの詳細スペックをそのままAIに送信しない運用ルールを設けます。第三に、機密度の高いデータが必要な場合はダミーデータに置き換えたサンプルでプロンプトを作成する手順を標準化します。第四に、FigmaのSOC2準拠などのセキュリティ基盤を踏まえつつも、プロンプト内容についてはユーザー自身が責任を持つという責任分界点をチーム内で共有します。第五に、プロンプト内容の定期的なレビュー体制を構築し、ガイドライン違反が発生していないかを確認するプロセスを組み込みます。これらのルールを導入前に策定しておくことで、AI活用に伴う情報漏洩リスクを最小限に抑えられます。

クレジット消費ダッシュボードで管理者がチーム全体の使用状況を把握する方法

有料プランの管理者は、Figmaの管理ダッシュボードからチームまたは組織全体のAIクレジット使用状況を確認できます。ダッシュボードへのアクセス方法は、ファイルブラウザの左サイドバーで「管理者」をクリックし、AIクレジットの使用状況セクションに移動するだけです。ここでは、ユーザーごとのクレジット消費量、残クレジット数、消費推移のグラフなどが表示されます。個々のユーザーも、左上メニュー内の「AI balance」から自身の残クレジット量を確認可能です。2026年3月18日のクレジット上限正式適用後は、月の中旬でクレジットを使い切るメンバーが出る可能性があるため、管理者が週次でダッシュボードを確認し、消費ペースが速すぎるメンバーには早めにアラートを出す運用が推奨されます。また、追加クレジットサブスクリプションの購入判断にも、ダッシュボードの消費データが重要な根拠となります。

デザインファイルのレイヤー名・制約・オートレイアウトを標準化する命名規則例

Figma Makeに取り込むデザインファイルの品質を安定させるには、チーム全体で命名規則とレイアウト設定の基準を統一することが不可欠です。レイヤー名については、「Header/Navigation」「Card/ProductItem」「Button/Primary/Large」のように、コンポーネントの種類・バリエーション・サイズを階層的に表現するBEM風の命名規則が効果的です。AIはレイヤー名からコンポーネントの役割を推測するため、「Frame 234」のようなデフォルト名のままでは適切なコードが生成されにくくなります。オートレイアウトの設定基準としては、すべてのコンテナフレームにmin-width/max-widthを設定すること、パディングは8pxグリッドの倍数に揃えること、要素間のgapは4px単位で統一することなどが推奨されます。FigmaのAIレイヤー名自動変更機能やClean Documentプラグインを活用すれば、既存ファイルの一括整理も効率的に行えます。この標準化をチームの共有ドキュメントとして明文化し、新規ファイル作成時のチェックリストに組み込むことで、Makeへの取り込み品質を安定させられます。

Opus 4.6の出力をFigma Designに戻せない制約を前提としたファイル管理フロー

現時点の仕様では、Figma Makeで生成したプロトタイプをFigma Designのデザインデータとしてそのまま戻すことはできません。両者の技術基盤が根本的に異なるためです。Figma Designはベクターベースのデザインデータを扱うのに対し、Figma MakeはReact＋TypeScriptベースの動的コードを生成しており、この変換は一方通行となっています。ただし、Figma Makeのプレビュー画面から「デザインをコピー」ボタンを押すと、編集可能なレイヤーとしてクリップボードにコピーされ、Figma Designのファイルにペーストすることは可能です。この制約を前提にしたファイル管理フローとしては、オリジナルのデザインファイルはFigma Design上で管理し続け、Figma Makeのファイルは「検証用」として別フォルダに格納するという二系統管理が実務的に有効です。最終的な本番デザインへの反映は、Figma Makeでの検証結果を参考にデザイナーがFigma Design上で手動更新する運用が現実的でしょう。

複数メンバーが同時編集するマルチプレイヤー利用時のバージョン競合防止策

Figma Makeのファイルはマルチプレイヤー機能を備えており、複数のユーザーが同時に入力中・閲覧中であることを確認できます。ただし、現時点ではFigma Makeにコメント機能は実装されておらず、複数人が同時にプロンプトを送信した場合の動作も安定しているとは限りません。バージョン競合を防ぐための実務的な対策としては、まず作業時間を分けてタイムシェア方式で利用する方法があります。Slackやカレンダーでファイルの利用時間を予約し、同時編集を避ける運用です。次に、用途別にFigma Makeファイルを分割し、「ホーム画面検証用」「ダッシュボード検証用」のように担当者ごとにファイルを分ける方法も効果的です。さらに、Figma Makeの履歴機能を活用し、各メンバーが作業前後に履歴ポイントを確認する習慣をつけることで、意図しない変更があった場合にロールバックできる体制を整えます。チーム規模が5名を超える場合は、これらの運用ルールを文書化して全員に共有することが安定運用の前提条件となるでしょう。