FigmaはAI時代に消えるのか──設計・実装・議論の境界線が溶けた先【2026年版】

1. 結論：Figmaは消えない。ただし「静的な画面を渡すだけの工程」は消えていく

2026年、生成AIに画面のイメージを伝えるだけで、ブラウザー上で動く試作品が数分で生まれるようになった。ボタンは実際に押せる。架空の利用者データを表示できる。修正したければ、変更内容を自然言語で伝えればよい。

この状況で、わざわざデザインツールを開き、静的な画面を描き、別の担当者がそれを見ながら実装する工程に、どれほどの意味が残っているのか。

この疑問の中心にあるのがFigmaである。

Figmaは、ウェブサービスやアプリの画面設計において事実上の標準になった。一方、AIエージェントは設計図を省略して、いきなり動くものを作り始めた。設計ツールの王者は時代遅れになるのか。それとも、AI時代だからこそ重要な役割を手に入れるのか。

その答えは、デザインを何と考えるかによって変わる。画面をきれいに描く作業だと考えれば、確かに多くの工程は不要になる。しかし、複数の人間が目的をすり合わせ、判断理由を共有し、製品全体の一貫性を保つ仕事だと考えると、見える景色はまったく違ってくる。

2. Figmaが標準になった本当の理由：描画機能ではなく共有空間

ブラウザーと共同編集が、ファイル受け渡しを終わらせた

Figmaの共同創業者であるディラン・フィールドとエヴァン・ウォレスは、ブラウン大学でウェブ上のデザインツールに取り組んだ。彼らが目指したのは、従来のデスクトップソフトをブラウザーに置き換えるだけの製品ではなかった。

従来のデザイン業務では、担当者が手元のパソコンでファイルを作り、更新版を関係者へ送付していた。修正のたびに最新版が増え、誰の手元にあるファイルが正しいのか分からなくなる。開発者は完成画像を見て余白や色を推測し、企画担当者は専用ソフトがなければ中身を確認できない。

Figmaは、この分断をブラウザーと共同編集によって解消した。画面を共有すれば、デザイナー、開発者、企画担当者、顧客が同じ内容を同時に確認できる。ファイルを送る必要がなく、変更はその場で全員に反映される。

創業者による初期の製品説明でも、共有資産と複数人による同時編集が、2016年に向けた重要な開発項目として掲げられていた。最初から競争相手は描画ソフトだけではなく、ファイル受け渡しそのものだった。

その成果は利用調査にも表れている。UX Toolsの調査では、インターフェース設計でFigmaが82.3％を占め、企業の個人実務担当者に限ると利用率は93.1％に達した。^[1]

ただし、この数字は調査回答者における利用状況であり、世界市場の売上シェアを厳密に示す数値ではない。それでも、多くの現場でFigmaを前提に仕事が組み立てられている事実は十分に読み取れる。

画面、部品、変数、議論を同じ場所に集める

Figmaの用途は、完成画面を描くことに限られない。

構想段階では、画面の大まかな配置を示すワイヤーフレームを作る。次に、配色、文字、余白、アイコンを決め、実際の画面に近い視覚設計へ進める。複数の画面をつなげれば、操作の流れを確認する試作品になる。

さらに、ボタン、入力欄、警告表示などを共通部品として登録すれば、別の担当者が同じ部品を再利用できる。色、余白、角の丸み、文字サイズを共通変数として管理すれば、ブランド全体の見た目を統一しやすくなる。

この仕組みがデザインシステムである。単なる見本集ではなく、製品全体の見た目と振る舞いを揃えるための運用基盤だ。

例えば、人事システムに申請画面、承認画面、通知画面、管理画面があるとする。それぞれの担当者が自由にボタンを作れば、同じ確定操作なのに色や位置が画面ごとに異なる。共通部品を使えば、利用者は画面が変わっても同じ感覚で操作できる。

Figmaには、議論のためのFigJam、開発者向けのDev Mode、プレゼンテーション用のFigma Slides、ウェブ公開用のFigma Sites、試作品生成用のFigma Makeなどもある。2025年第2四半期の決算では、顧客の80％超が2種類以上の製品を使い、約3分の2が3種類以上を使っていた。^[7]

Figmaが浸透した理由は、描画機能が優秀だったからだけではない。製品を作る人たちが、同じ場所に集まるようになったからである。

リモートワークで価値を持つ「消えないホワイトボード」

オフィスに全員が集まっていた時代は、ホワイトボードの前で画面遷移を書き、付箋を貼りながら議論できた。リモートワークが広がると、その場は自然には存在しなくなった。

FigJamは、この空白を埋めるオンラインホワイトボードである。利用者の行動を整理し、画面の流れを描き、付箋を並べ、会議中に全員で加筆できる。投票、タイマー、カーソルに表示される簡易チャットなども利用できる。

有料プランでは音声会話にも対応している。別の会議ツールを立ち上げなくても、同じ画面を見ながらその場で話せる。操作中のカーソルや、誰がどこを見ているかも共有できる。

Figmaの公式説明によれば、1つのファイルには最大500人まで共同参加でき、それを超える参加者は静的な表示に切り替わる。通常の設計会議には十分以上の規模である。

重要なのは、会議が終わっても議論の痕跡が残ることである。なぜこの画面を採用したのか。なぜ別案を捨てたのか。どの部署が懸念を示したのか。完成したコードだけでは分からない判断の過程を、共有空間に残せる。

ただし、音声で会話できることと、会話内容が自動的に永続保存されることは別である。判断理由を後から参照したいなら、コメントや議事録として明示的に残す必要がある。

ここでFigmaが提供している価値は、図を描く機能ではなく、意思決定の場所である。AIが図を代わりに描けるようになっても、人間同士の合意形成まで自動的に不要になるわけではない。

3. 静的な設計図が揺らぐ理由：AIは翻訳工程を飛び越える

一方で、従来型の設計工程には明らかな弱点がある。

静的な画面では、入力時の反応、通信中の表示、エラー処理、画面幅の変化、キーボード操作、実際の動きが分かりにくい。高精細に描いた画面でも、動かなければ使用感は確定しない。

さらに、設計と実装の間には翻訳作業が存在する。デザイナーが作った部品を、開発者がReactなどの実装へ変換する。その過程で余白がずれたり、既存の共通部品が無視されたり、画面上では成立していた配置が実機で崩れたりする。

生成AIは、この翻訳工程を飛び越え始めた。文章で目的を伝えれば、HTML、CSS、JavaScriptを組み合わせた動く試作品を生成できる。架空の顧客情報や注文履歴を表示し、実際にボタンを操作しながら改善できる。

個人開発、小規模な業務ツール、短期間で方向性を確認する試作では、この方法が合理的な場合が多い。先にFigmaで画面を描き、それを別のAIに実装させるより、最初からコードとして作るほうが手戻りを減らせる。

特に、実装する本人が判断者でもある場合、設計図の受け渡しは発生しない。開発者、デザイナー、発注者が同一人物なら、中間成果物の価値は大きく下がる。

消え始めているのは、デザインそのものではない。静的な画面を作り、それを実装担当者へ一方向に渡す固定的な工程である。

動くアプリとMarkdownの仕様書だけで十分な場面

コードを中心に設計を進める方法では、試作品そのものを検討材料にする。

開発用サーバーを立ち上げ、画面に静的なデータを読み込ませる。顧客名、売上、申請状態、通知件数などを架空のデータで再現すれば、本物のサービスに近い操作感を得られる。

仕様は、プロジェクト内のMarkdownファイルに記録する。対象ユーザー、画面ごとの目的、操作条件、エラー時の挙動、権限の違い、受け入れ条件を文章で整理する。AIエージェントは、その文書と既存コードの両方を読みながら実装を進められる。

この方法には明確な利点がある。コードと仕様書が同じリポジトリーに置かれるため、変更履歴をまとめて管理できる。画面を修正したら、その変更に対応する仕様も更新できる。完成した試作品は、そのまま本実装の土台にもなる。

小規模な社内管理画面や個人向けサービスなら、Markdownの仕様書、静的データ、動く試作品、画面単位のコメントがあれば、専用のデザインツールを使わずに十分な成果を出せる。

ただし、Markdownは一覧性に限界がある。画面が30個あり、それぞれに初期状態、読み込み中、入力エラー、権限不足、通信失敗が存在すると、文章だけで全体像を理解することは難しい。

加えて、開発環境を扱えない営業担当者や経営層にとって、コードとローカルサーバーは参加しやすい作業空間ではない。技術的に最短の方法が、組織全体にとって最短とは限らない。

画面は仕様の一部であって、仕様の全部ではない

Figmaの画面は、見た目の仕様を伝えるには優れている。どこにボタンがあり、どの順序で入力し、どの色を使うかを視覚的に共有できる。

しかし、画面があることと、仕様が確定していることは同じではない。

例えば、承認ボタンが表示されていても、そのボタンを誰が押せるのかは画面だけでは分からない。代理承認は可能か。締め切り後はどうなるか。承認者が退職した場合は誰に引き継ぐか。二重送信は防止されるか。監査履歴は何年間残すか。

こうした業務上の条件は、画面の配置だけでは表現しきれない。権限、状態遷移、例外処理、監査、セキュリティ、性能要件は、文章やテストとして明文化する必要がある。

反対に、Markdownだけでも十分とは限らない。文章で正確に書かれていても、画面全体の視線誘導や操作負荷は、実際の見た目を確認しなければ判断しづらい。

現実的には、仕様の正本を1つの形式に押し込めるより、情報の性質に応じて置き場所を分けるほうがよい。

業務ルールと受け入れ条件は文章に残す。実際の振る舞いはコードとテストで示す。視覚的な比較や合意形成はキャンバスで共有する。重要なのは、それぞれが矛盾せず、相互に参照できることである。

4. Figma自身が境界を壊す：Code Layers、Agent、MCP

Figmaは、この変化を見落としていない。

2025年にはFigma Makeを投入し、自然言語から動く試作品を作れるようにした。同年にはFigma Sites、Figma Draw、Figma Buzzも発表し、画面設計だけに依存しない製品群を整えた。

2026年6月の年次イベントConfigでは、さらに大きな方針転換を示した。中心になったのがCode Layersである。

Code Layersは、Figmaのキャンバス上に、実際のコードで動く画面を配置する仕組みである。静的なデザインを動く試作品へ変換し、複数案を横に並べ、関係者が同じ場所で比較できる。

設計画面からコードへ移し、必要に応じて再び編集可能なデザインへ戻す。既存のコードベースを取り込んだり、GitHubのリポジトリーを複製したりして、実際の部品を前提に試作する機能も案内されている。

2026年8月23日時点でCode Layersはクローズドベータ版であり、全利用者に一般提供されている機能ではない。一方、Figma AgentはProfessional、Organization、Enterpriseの対象利用者向けにオープンベータとして展開されている。^[2][3]

Figmaは、静的な設計図を守ろうとしているのではない。動くコードをキャンバスに持ち込み、設計と実装を同じ共有空間に統合しようとしている。

従来は、設計図か実物かという二者択一だった。新しい構想では、実物をチームで比較しながら設計する。設計ツールと実装ツールの境界そのものが薄くなっている。

Figma Agentは、編集可能なデザイン構造を扱う

2026年のFigmaには、キャンバス上で直接作業する独自のAIエージェントが搭載されている。

指示を与えると、新しい画面案を生成し、既存のレイアウトを調整し、複数の方向性を並べて比較できる。大量のレイヤー名を整理したり、共通部品を適用したり、既存のデザインルールに合わせて修正したりする作業も支援する。

単にきれいな画像を生成する仕組みとは異なり、デザインデータの構造、部品、変数、既存ライブラリーを理解しながら、編集可能な形で結果を作ることが目標である。

2026年6月以降の更新では、組織独自の作業手順をスキルとして登録できるようになった。例えば、自社の配色規則、承認画面の必須項目、アクセシビリティ上の確認事項をまとめ、繰り返し適用できる。ウェブ検索、MCPコネクター、PDFや表計算を含む添付も利用できる。^[3]

外部のウェブ情報を調べたり、画像、文章、コード、PDF、表計算ファイルを参考資料として添付したりする機能も追加された。組織の外にある情報を取り込みながら、社内のデザインルールに沿った案を生成する方向へ進んでいる。

Figmaの発表によれば、2026年7月末の時点で、年間契約額が1万ドルを超える有料顧客の50％以上が、このエージェントを毎週利用していた。^[6]

ただし、エージェントの利用条件には注意が必要である。2026年8月時点では主にProfessional、Organization、Enterpriseの有料プランが対象で、ベータ期間中はエージェント自体の処理にAIクレジットを消費しない。正式提供後は通常のクレジット体系が適用される予定である。

MCPとCode Connectが、設計の文脈をコードへ渡す

AIエージェントに画面を実装させる際、完成画像だけを渡す方法には限界がある。

画像から見た目を再現できても、そのボタンが既存の共通部品なのか、色がブランド指定の変数なのか、入力欄に特別な検証処理があるのかは分からない。結果として、見た目だけ似ている別物が増えていく。

そこで使われるのがMCPである。AIエージェントが外部のツールやデータに接続し、必要な情報を構造化された形で受け取るための仕組みだ。

FigmaのMCPサーバーを利用すると、画面内の部品、配置、変数、色、余白などを、AIエージェントが読み取れる。Cursor、Claude Code、Codex、GitHub Copilotなどが、画像だけでは得られない設計情報を参照できる。

さらにCode Connectを使えば、Figma上の部品と、実際のリポジトリーに存在する部品を対応付けられる。デザインに表示された確定ボタンが、既存コードのどのコンポーネントに対応するかまで伝えられる。

Figmaが2026年8月5日に公開した自社評価では、Code Connectを併用した場合、作業時間の中央値が19.6％短縮し、トークン消費の中央値は29.5％減少した。コード品質も4段階評価で1段階改善したという。^[4]

これは同社自身による検証であり、すべての環境で同じ改善が起きることを保証する数字ではない。それでも、画面の画像だけを渡すより、既存部品との対応関係まで共有したほうが効率的だという点は、技術的にも自然である。

AIに必要なのは、見た目の再現だけではない。何を再利用し、何を作り直さず、どの規則を守るべきかという文脈である。

コードが正本なら、Figmaを通すほど遅くなることもある

ただし、MCPを使えるからといって、常にFigmaを中心に置くべきだとは限らない。

すでに本番コードに共通部品が整備され、Storybookで各部品の表示例と仕様が管理されているなら、AIエージェントが直接それらを参照するほうが合理的なこともある。

Storybookは、実際のコードで作られた画面部品を独立して確認するための仕組みである。2026年3月には、React向けのMCP連携が公式に紹介された。AIエージェントが既存部品の情報、利用例、仕様書を読み取り、部品を再利用し、テストを実行して不具合を修正できる。

この環境では、Figmaで描いたボタンをコードへ変換するより、すでに存在するボタンをそのまま使うほうが正確である。現実のコードが最も信頼できる情報源になる。

公式フォーラムや利用者コミュニティでも、AIからFigmaへ移し、さらに別のAIでコード化する二段階処理に疑問を持つ声がある。最終成果物がアプリである以上、最初からアプリを作ればよいという意見には十分な合理性がある。

一方で、完成画面の候補を横に並べ、営業担当者、デザイナー、開発者が同時に比較したい場合は、コードだけの環境では参加しにくい。どちらが優れているかは、処理速度だけでなく、誰が判断に参加するかによって決まる。

5. AI時代に価値が上がる設計、下がる作業

設計には、価値が下がりやすい部分と、逆に重要性が増す部分がある。

価値が下がりやすいのは、既存画面の単純な模写、よくある管理画面の量産、部品の位置を細かく手作業で調整するだけの仕事である。AIはこうした反復作業を短時間で処理できる。

反対に、重要性が上がるのは、何を作るべきかを判断する仕事である。

同じ申請画面でも、誰が使うかによって最適な構成は変わる。経理担当者なら一度に多くの情報を確認したい。現場の従業員なら迷わず申請できることが重要になる。承認者なら、確認すべき差分が目立つ必要がある。

AIは複数案を大量に生成できる。しかし、利用者の事情、組織内の権限、過去の失敗、ブランドの方針、法令上の制約を踏まえて、何を採用するかは別の問題である。

Figmaが2026年に公開したAI調査は、過去3年間の延べ8,403件の回答と639件の聞き取りを基に、日本を含む10市場を対象としている。回答者の90％は、AI登場後もデザインの重要性は少なくとも以前と同程度だと答えた。開発者の65％は、デザインが以前より重要になったと回答している。^[5]

同じ調査では、開発に参加するデザイナーの割合が前年の21％から41％へ増えた。デザイン業務に関わる開発者も44％から60％へ増えている。

ただし、これはFigmaによる調査であり、同社の利用者層や設問設計の影響を受ける可能性がある。だからといって意味がないわけではない。少なくとも、設計担当者と実装担当者の境界が急速に薄くなっていることを示す材料として読むべきである。

48％成長とGAAP赤字が同時に示す現実

Figmaが消えつつある企業なのかを判断するには、印象だけでなく業績を見る必要がある。

2026年8月5日に公表された第2四半期決算によれば、売上高は3億7,010万ドルで、前年同期比48％増加した。成長率は3四半期連続で加速している。^[6]

年間契約額が1万ドルを超える顧客は1万5,964社で、前年から34％増えた。10万ドルを超える大口顧客も1,635社に増え、伸び率は46％だった。

既存顧客が契約をどの程度拡大したかを示す売上継続率は136％である。単純化すれば、既存顧客からの売上が、解約や縮小を差し引いた後でも前年の1.36倍になったことを意味する。

年間契約額が1万ドルを超える顧客の80％以上が、AIクレジットを毎週利用していた。AIはFigmaの外から顧客を奪う存在であると同時に、Figma内部で新しい利用と課金を生み出している。

ただし、楽観だけでは不十分である。同じ四半期の会計上の営業損失は1億1,730万ドル、純損失は1億1,220万ドルだった。株式報酬などを調整した営業利益は3,610万ドルだが、会計上は赤字である。

売上の成長と事業の安定性は同じではない。AI計算費用、研究開発費、販売費用が増えれば、利用者が増えても利益が圧迫される。2026年通期の売上見通しは14億6,300万ドルから14億6,700万ドルだが、その成長を持続可能な利益につなげられるかは別問題である。

料金とAIクレジットが新しい摩擦になる

2026年8月23日時点の公式料金では、Professionalプランの年間契約換算で、Fullシートが月額16ドル、Devシートが12ドル、Collabシートが3ドルである。^[8]

OrganizationプランのFullシートは月額55ドル、Enterpriseプランでは90ドルとなる。上位プランでは、組織全体の管理、認証、デザインシステム統制などが強化される。

AIクレジットの配分は、ProfessionalのFullシートで月3,000、Organizationで3,500、Enterpriseで4,250である。Dev、Collab、Viewの各シートや無料プランには、原則として月500クレジットが付与される。^[9]

無料プランには1日150クレジットという上限もある。そのため、月間の残高が残っていても、その日の利用を打ち切られる場合がある。

公式フォーラムには、数回の指示でクレジットが急速に減ったという投稿や、AIが自分で作った不具合を直すたびに追加費用が発生するという不満が寄せられている。

ただし、こうした投稿は個別の体験談であり、利用者全体の平均的な満足度を示す統計ではない。Figma側は、処理の複雑さ、読み込む資料の量、利用モデルによって消費量が変動すると説明している。

問題は、金額だけではない。AIの失敗が増えるほど利用者の負担が増える仕組みでは、利用者と提供企業の利害が完全には一致しない。

特に大企業では、デザイン担当者、開発者、企画担当者のシート料金に加え、AIクレジット、追加契約、管理機能が積み重なる。1人で使う場合には小さな差でも、数百人規模では導入判断を左右する。

現場が評価するのは、派手さではなく地味な摩擦の解消

現場の反応は一枚岩ではない。

利用者コミュニティでは、AIエージェントと独自のスキルを組み合わせ、既存のデザインシステムとの接続作業の約6割を任せられるようになったという報告がある。大量の部品適用や不足チェックでは、明確な効果が見え始めている。

一方、2026年の大型発表に対しては、派手な演出や画像効果よりも、表組み、余白制御、部品設定、デザイントークンの改善を優先してほしいという意見も見られた。

コードを扱えること自体は魅力的でも、生成物が本番品質に達しないなら、結局は開発者が作り直すことになる。機能が増えるほど、操作が複雑になり、本来の用途が見えにくくなるという懸念もある。

Figmaが新しいPhotoshopのように、あらゆる機能を抱え込む巨大ソフトになりつつあるという指摘もある。歴史的には、機能過多になった製品の周辺から、特定の課題だけを上手に解く新興企業が登場してきた。

逆に、AIで直接コードを書くだけでは、どの製品も似たような見た目になり、ブランドらしさや使い勝手が失われるという反論もある。

これらは定量調査ではないが、競争の焦点をよく表している。Figmaの評価は、AI機能があるかどうかではなく、それが日常の地味な課題をどれだけ解決するかで決まる。

6. 競争相手も隣の領域へ：Stitch、Canva、Miro、Atlassian、Notion、Adobe

Google Stitchは設計工程を正面から短縮する

Figmaの強力な競争相手の1つが、Google LabsのStitchである。

Googleは2026年5月、文章、音声、既存コードやデザインファイルから画面を生成し、生成途中から方向を変えられるStitch Agentを発表した。^[10]画面に向かって話しかければ、別の配色を試したり、複数のメニュー案を作ったり、設計上の問題点を指摘させたりできる。

静的な画面から操作可能な試作品を生成する機能もある。画面遷移をつなげ、利用者の行動に応じた次の画面を生成し、体験全体を短時間で確認できる。

さらにStitchはMCPサーバーを提供し、外部の開発環境やAIエージェントと連携する。Google AI StudioやAntigravityなどの開発ツールへ設計情報を渡すことも想定されている。

これは、Figmaの設計図を経由しなくても、構想から試作、実装へ進める流れである。特に新規プロジェクトでは、既存のFigma資産が少ないため、乗り換えの障壁も低い。

ただし、企業が長年蓄積してきた共通部品、承認フロー、過去の議論、ブランド規則まで自動的に置き換えられるわけではない。新しい生成能力と、既存の組織資産のどちらが重要かによって競争条件は変わる。

Canvaはデザインの民主化からアプリ制作へ進む

Canvaも、AIによって不要になると考えられやすい製品である。ポスターや資料を文章から生成できるなら、テンプレート中心のデザインツールは役割を失うように見える。

しかし、実際の動きは逆方向である。

Canvaは2025年末時点で月間利用者2億6,000万人を公表し、2026年のCanva AI 2.0発表では「2億5,000万人超」と説明している。^[11][12]デザイン素材の作成に加え、資料、ウェブサイト、動画、ブランド管理へ用途を広げてきた。

2026年にはCanva Code 2.0を公開し、自然言語からレスポンシブなウェブアプリや対話型コンテンツを作り、HTMLも取り込んで編集できる方向へ進んだ。^[12]

Canva自身も社内でAI活用を進めている。2026年の取り組みでは、5,300人の従業員を対象にAI活用へ集中的に取り組み、AIへの自信を高く評価する従業員の割合が72％から89％へ上昇したと公表した。^[13]

Canvaの戦略は、デザインツールを守ることではない。専門知識がなくても、見た目、文章、動画、動くコンテンツまで作れる入口になることである。

ただし、利用者数が多いことと、専門的な業務システム設計に強いことは同じではない。Figmaの企業向け設計基盤とCanvaの広範な制作基盤は重なる部分もあるが、完全な代替関係ではない。

MiroはホワイトボードをAIの共同作業空間へ変える

Miroも、オンラインホワイトボードがAIに置き換えられると疑われやすい製品である。

文章を入力すればAIが図を作れるなら、付箋を手で並べる必要は減る。議事録を要約し、工程表を自動生成できるなら、ホワイトボードを開く時間そのものが不要に見える。

Miroは2026年5月、Sidekicksを、質問に答える補助機能から、計画を立てて成果物を作るエージェントへ発展させる方針を発表した。発表には提供前の機能も含まれる。^[14]

利用者が目的を説明すると、エージェントが必要な条件を確認し、作業手順を提案する。その後、資料、図、工程表、付箋、管理ボードをキャンバス上に生成する。Slack、GitHub、Jira、Confluenceなどの情報も取り込む構想である。

ただし、発表時点では提供開始前の機能も含まれていた。紹介された構想のすべてが、2026年8月時点で全利用者に利用可能という意味ではない。

Miroが維持しようとしている価値は、付箋を貼ることではない。複数人が同じ文脈を共有し、その場で方向性を決める空間である。

AIが図を作るほど、人間が図の内容について議論する場所の価値が高まる可能性がある。その一方で、議論が少なく、担当者が1人だけの仕事では、専用のホワイトボードを使う理由は弱くなる。

JiraとConfluenceは、人間向け画面からAIの記録基盤へ変わる

課題管理のJiraや、社内文書を管理するConfluenceにも似た疑問が向けられている。

AIエージェントに仕事を任せられるなら、課題票を人間が細かく書く必要はあるのか。議事録からAIが作業を抽出し、コードまで修正するなら、管理画面を開く理由は減るのではないか。

Atlassianは、この変化に対し、AIエージェントのRovoや、組織内の作業履歴を関連付けるTeamwork Graphを中心に据えている。

2026年8月に公表された決算によれば、同社の四半期売上は約18億ドルで前年同期比28％増、クラウド売上は約12億ドルで31％増加した。^[15]

外部エージェントがAtlassianの情報へ接続するMCPサーバーと関連する操作基盤は、月間利用者が100万人を超え、1四半期で2倍以上になった。同社は2026年3月時点で、Rovoが月間500万人を超えたとも公表している。^[15]

この動きは、Jiraを人間が操作し続けるという意味ではない。AIエージェントが課題を作り、進捗を更新し、過去の議論を参照するようになれば、画面を直接開く回数は減るかもしれない。

それでも、担当者、期限、承認状況、障害履歴を管理する仕組みまで消えるとは限らない。人間向けの操作画面から、AIと人間が共有する記録基盤へ役割が変わる可能性が高い。

Notionは文書置き場からAIの記憶へ変わる

Notionも同じ変化に直面している。

AIが質問に答え、会議を要約し、仕様書を自動生成できるなら、文書管理ツールの画面を毎日開く必要は減る。Markdownファイルをリポジトリーに置くだけで十分だと考える開発チームもある。

しかし、Notionは蓄積された文書を、AIエージェントの行動基盤として利用しようとしている。

同社はCustom Agentsを導入し、社内の文書、データベース、会話、業務手順を参照しながら、繰り返し発生する作業を自動化できるようにした。

2026年2月の公開時点でNotion社内では2,800のエージェントが稼働し、早期利用者は2万1,000件超を作っていた。5月には、顧客が作成したCustom Agentsが累計100万件を超えたと同社が公表している。^[16][17]

同時に、権限管理の難しさも明らかになった。初期の仕組みでは、エージェントにSlackへの広い書き込み権限を与えた結果、意図しない投稿が全社向けのチャンネルに送信された事例があったという。

そのため、特定の会話への返信だけを許可する権限設計などが追加された。

この問題はFigmaにも共通する。AIが設計や仕様へアクセスできるだけでは不十分であり、どの情報を見せ、誰の承認で何を変更できるかまで管理しなければならない。

文書ツールの将来を決めるのは、文章を表示する画面の使いやすさだけではない。組織の知識、権限、変更履歴を、AIが安全に利用できる形で保てるかどうかである。

Adobeは巨大企業でも安泰ではない

Adobeは、AI時代に最も大きな課題を抱える企業の1つである。

画像の切り抜き、背景変更、資料作成といった作業は、生成AIによって簡単になった。高度な編集ソフトを学ばなくても、文章だけで一定の結果が得られるようになれば、従来型の有料契約は見直される。

それでも、2026年6月の決算では、四半期売上が66億2,000万ドルに達した。AIを中心とする年間継続売上は前年の3倍を超え、5億ドルを上回った。^[18]

AdobeはFireflyなどの生成AIを既存製品へ組み込み、画像、動画、広告制作を横断する体制へ移行している。強みは、企業の制作工程、ブランド管理、既存資産に深く入り込んでいることである。

一方で、軽い用途の利用者が安価なAI製品へ移る可能性は残る。数回しか使わない画像加工のために高額な契約を続ける理由は弱くなるからだ。

Figmaとの関係も象徴的である。Adobeは2022年に約200億ドルでFigmaを買収する計画を発表したが、2023年に合意を解消した。^[19]Figmaはその後、2025年7月31日にニューヨーク証券取引所へ上場した。^[20]

大企業が新興企業を取り込むはずだった構図は、両者がAI時代の制作基盤を争う構図へ変化している。

7. 本当に消えるのはツールではなく、工程の境界線

ここまでの動きを並べると、共通する現象が見えてくる。

FigmaはコードとAIを取り込む。Google Stitchは設計から実装へ直接進む。Canvaはウェブアプリを生成する。Miroはホワイトボード上でAIに作業させる。Atlassianは課題管理をエージェントの行動基盤へ変える。Notionは文書をAIの記憶として使う。

つまり、それぞれが隣の領域へ広がっている。

画面設計ツール、ホワイトボード、文書管理、課題管理、開発環境という分類は、人間が手作業で工程を分けていた時代の区分である。AIが情報を横断できるようになると、製品の境界は曖昧になる。

しかし、境界が消えることと、基盤が消えることは同じではない。

組織には、誰が決めたか、何を変更したか、どの情報を使えるか、どの案が採用されたかという記録が必要である。AIが仕事を速く進めるほど、その記録が不正確な場合の影響も大きくなる。

反対に、単に別の画面で同じ情報を手入力し直すだけの道具は厳しくなる。情報が孤立し、AIが読み取れず、承認や履歴にも関与しない製品は、中間工程として省略されやすい。

生き残る条件は、きれいな画面を持つことではない。組織の文脈を保持し、人間とAIの双方から利用され、実際の成果物と接続できることである。

Figmaが必要なチーム、不要になりやすいチーム

Figmaの必要性は、組織の規模や作業の性質によって変わる。

個人開発、試験的なサービス、単発の管理画面では、Markdownの仕様書、静的データ、AIが生成する動く試作品だけで十分な場合がある。判断者と実装者が同じなら、デザインツールを挟まないほうが速いことも多い。

少人数でも、既存のReact部品やStorybookが十分に整っているなら、コードを直接編集しながら設計を詰める方法が有力である。画面部品の正本がコード側にある以上、別の設計図を維持する必要は小さい。

一方、多数の画面を抱え、複数の部署が関わり、長期運用される製品では事情が異なる。営業、企画、顧客、法務、デザイナー、開発者が同じ画面を見ながら判断する必要がある。共通部品、ブランド基準、画面間の整合性、変更の影響範囲も管理しなければならない。

そのような環境では、Figmaの価値は静的な設計図ではなく、共有された視覚的な意思決定基盤にある。

ただし、Figmaを導入すれば自動的に設計品質が上がるわけではない。画面だけ増え、仕様が古くなり、コードとの差分が放置されるなら、管理対象が1つ増えるだけである。

必要なのは、設計、コード、業務仕様、議論の履歴をどう接続するかという設計そのものである。

8. AI時代の設計ツールに必要な3条件

これからの設計ツールには、少なくとも3つの条件が求められる。

第一に、静的な絵ではなく、動く成果物と接続できることである。実際のコード、共通部品、試験データ、操作結果を扱えなければ、現実の製品との差は広がる。

第二に、人間が判断した理由を残せることである。AIは別案を大量に生成できるが、なぜ特定の案を採用したのかは、組織の知識として管理しなければならない。

第三に、AIが安全に利用できることである。設計情報、業務仕様、個人情報、機密資料へアクセスする以上、権限、承認、監査、変更履歴の管理が不可欠になる。

Figmaがこの3条件を満たし続けるなら、単なるデザインツールとしてではなく、製品開発の共有基盤として残る可能性が高い。

反対に、生成した画面が本番コードとつながらず、利用料が増え、機能ばかり複雑になれば、Google Stitch、コード中心の開発環境、Storybook、より小さな専門ツールに利用者を奪われる余地は十分にある。

Figmaが消えるかどうかは、AIがデザインできるかどうかだけでは決まらない。組織が、何を作るかをどう決め、その決定をどこに残すかによって決まる。

ぽちょ研究所の視点から見れば、AI時代に消えていくのは、設計という仕事ではない。設計、実装、議論を別々の箱へ閉じ込めていた古い工程である。残るのは、それらを人間とAIが一緒に扱える場所だ。

注記: 本稿は2026年8月23日時点の公開情報に基づく。ベータ提供範囲、料金、AIクレジット、各社の数値は変更される可能性がある。企業導入では、最新の公式情報と自社の権限・監査要件を確認してほしい。

参考文献・出典

1. [1]UX Tools, Interface Design Trends. 「market share」は調査回答者の主要ツール構成を示し、世界売上シェアではない。 ↩
2. [2]Figma, “Config 2026 recap”, 2026年6月24日。 ↩
3. [3]Figma Help Center, “What’s new from Config 2026”, 2026年8月23日確認。 ↩
4. [4]Figma, “Better code, fewer tokens: The benefits of Code Connect in MCP”, 2026年8月5日。同社の評価であり、全環境への一般化はできない。 ↩
5. [5]Figma, “Figma’s 2026 AI Report”, 2026年6月24日。同社調査である点に注意が必要。 ↩
6. [6]Figma Investor Relations, Q2 2026 Financial Results, 2026年8月5日。 ↩
7. [7]Figma Investor Relations, Q2 2025 Financial Results, 2025年9月3日。 ↩
8. [8]Figma, Plans & Pricing, 2026年8月23日確認。 ↩
9. [9]Figma Help Center, Manage AI credits, 2026年8月23日確認。 ↩
10. [10]Google, “New ways to design in real time with Stitch”, 2026年5月19日。 ↩
11. [11]Canva, “A transformative year for Canva: 2025 in review”. ↩
12. [12]Canva, “Introducing Canva AI 2.0”, 2026年。 ↩
13. [13]Canva, “Inside our second AI Discovery Week”, 2026年。 ↩
14. [14]Miro, “What’s New: What we announced in May 2026”, 2026年5月27日。 ↩
15. [15]Atlassian, Q4 FY26 shareholder letter, 2026年8月6日。 ↩
16. [16]Notion, Notion 3.3: Custom Agents, 2026年2月24日。 ↩
17. [17]Notion, “Introducing Notion’s Developer Platform”, 2026年5月13日。 ↩
18. [18]Adobe, Q2 FY2026 Earnings Release, 2026年6月11日。 ↩
19. [19]Adobe, “Adobe and Figma Mutually Agree to Terminate Merger Agreement”, 2023年12月18日。買収計画の対価は2022年の発表資料を参照。 ↩
20. [20]Figma Investor Relations, “Figma Announces Pricing of Initial Public Offering”, 2025年7月30日。 ↩