7
6

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@nxted_sapporo(NXTED Co., Ltd.)in株式会社NXTED

#185 MCP × draw.io による画面設計書自動生成の実験

7
Posted at

はじめに

先日、こちらの記事を拝見しました。

Playwright MCPとdraw.io MCPで画面仕様書を自動生成する

非常に興味深い内容でしたので、
今回はこちらの記事の画面レイアウト生成部分にフォーカスし、
より自動化の完成度を高めるために検証した内容を紹介したいと思います。

紹介記事内に記載されていた課題点

  • レイアウト図生成の際に項番の座標が安定しない

本記事で試みた内容とその結果

  • 項番の座標を安定させられるか
    • 可能。かなり安定性が向上することが確認できました。
  • Playwright MCPはFigma MCPにも代替可能か
    • 可能。一定粒度でコンポーネント化されていれば、HTMLがあるときと同等の精度で画面設計書を書き起こすことが期待できます。
  • HTMLのDOM構造やFigmaのコンポーネント構造をpngファイル内に埋め込むことで、画面設計書をAIが読み込んだ時の理解度をより上げることは可能か
    • 要検討。draw.io上で再現しなくてはいけない矩形が多すぎるので、構造をすべて埋め込むのは非現実的。ある程度グルーピングする形になります。AIの認識精度向上への寄与度について定量的な評価はできていません。
  • 画面レイアウトを、draw.ioで開ける形式のpngファイルとして出力することで、drawioファイルなしでpngファイルだけで運用することは可能か
    • 可能。出力されたpngファイルをdraw.io上で直接編集できることが確認できました。

環境・前提

  • Model: Claude Opus 4.6

    • 本記事の検証はこちらのモデルを使用しているため、他のLLMでは結果が異なる可能性があります。

  • MCP: Playwright, Figma

  • OS: Windows + WSL

  • AIへのコンテキストとして、参考元記事のURLを渡しました

    • 参考元記事に掲載されているSKILLS設定は別途していません

  • 検証対象画面として、GrafanaのBigQueryデモ画面を使用

    • Playwright MCPでの検証時: 上記ページのURLをそのままAIに渡す
    • Figma MCPでの検証時: 上記ページをFigmaプラグインのhtml.to.designでFigmaに取り込んで使用

全体の手順

今回試した手順の全体像は以下のとおりです。
HTMLからの画面設計書自動生成（Playwright MCP）と、
Figmaからの画面設計書自動生成（Figma MCP）の
2パターンを試しました。

1 座標取得（Playwright MCP / Figma MCP）
   スクリーンショット + 各UI要素の座標を取得

2 画面項目一覧の生成
   突合済み要素をグルーピングし、
   項番・項目名・種別・座標を一覧化

3 PNG生成（draw.io XML直接生成 + CLI export）
   スクリーンショット背景に番号付き矩形を重ねたPNGを出力
   → draw.ioで開けば再編集可能
   → PNGのままMarkdownにも貼れる

Playwright MCPで座標取得

元記事の課題であった
「項番の座標が安定しない」問題に対するアプローチです。


スクリーンショットの画像から座標を推測させるのではなく、
JavaScriptで座標を直接取得させました。

Playwright MCPツールの browser_evaluate で
以下のようなJavaScriptを実行しました。

なお、このスクリプトは
AIがHTML内容から判断して自動で生成したものです。

セレクターの選定基準などは、
プロジェクトによって調整が必要かと思います。

(() => {
  const selectors = [
    'input', 'button', 'a', 'select', 'textarea',
    '[role="button"]', '[role="tab"]', '[role="textbox"]',
    'label', 'h1', 'h2', 'h3', 'h4', 'h5', 'h6',
    '[data-testid]', '.panel-title', '.panel-header'
  ].join(', ');

  return JSON.stringify({
    elements: [...document.querySelectorAll(selectors)]
      .filter(el => {
        const rect = el.getBoundingClientRect();
        return rect.width > 0 && rect.height > 0 && rect.y >= 0;
      })
      .map(el => {
        const rect = el.getBoundingClientRect();
        return {
          tag: el.tagName.toLowerCase(),
          role: el.getAttribute('role') || '',
          aria_label: el.getAttribute('aria-label') || '',
          text: (el.textContent || '').trim().slice(0, 80),
          rect: { x: Math.round(rect.x), y: Math.round(rect.y),
                  width: Math.round(rect.width), height: Math.round(rect.height) }
        };
      })
  });
})()

Figma MCPで座標取得

Figma MCPの get_file で座標を取得しました。

オーバーレイPNG生成

取得した項目とその座標をdraw.io XMLに変換し、
スクリーンショット上に
番号付き矩形を重ねたPNGを生成させます。

元記事ではdraw.io MCPを使ってダイアグラムを生成していますが、
draw.io公式MCP自体からは構造化された図を生成・編集するAPIが提供されていないようで、
headless環境ではGUI URLが返るだけで自動化に不向きでした。

そのため今回はLLMがdraw.io XMLを直接生成し、CLIでPNGにexportする方式を採用しています。

非公式版のdraw.io MCPサーバーには
ダイアグラム作成機能もあるようなのですが、
こちらについては今回試していません。

また、要素ではなくコンポーネント単位での構造情報を残しておくと、
読み取りの際に多少精度があがりやすいかと思い、
グルーピングデータも作成させています。

draw.ioで開けるPNG

draw.io CLIの --embed-diagram オプションを使うと、
PNGのzTXtチャンクにXMLが埋め込まれます。

"/mnt/c/Program Files/draw.io/draw.io.exe" \
  --export --format png --embed-diagram \
  --output output/overlay.png input.drawio

生成されたPNGは3つの用途を1ファイルで兼ねます。

  1. 画像: MarkdownやNotionに貼れる普通のPNG
  2. 項目マッピング: draw.ioで開くとXMLが復元され、全要素がGUI編集可能
  3. 構造データ: zTXtチャンクからXMLを抽出すればAIが読み取れる

.drawioファイルを別途管理する必要がなく、PNGだけで運用できます。

実行結果

以上の一連の流れで、実際に出力された画像がこちらです
※こちらはトリミング後画像のため、
ダウンロードしてもdraw.ioでは開けないですが、
元画像はdraw.ioに対応しています

overlay.png

かなり精度高く項番がつけられていることが分かるかと思います。
上図はPlaywright MCP経由で実行したものですが、
Figma MCPを通したものもほぼ同じ結果となりました。


何もない場所に付いているように見えるラベルは、折り畳み等の小さいボタンがあります。

また、番号がついていない要素は、
座標取得時のセレクタのフィルタで弾かれてしまったものと思われます。
（<li>要素等）

白枠の範囲がずれている箇所も、中の要素がフィルタリングで弾かれているだけに見えます。

お試しだったので色々見にくいですが、項番の見た目や項目フィルタ方法についてはAIに指示すれば自由に変更できます。

まとめ

今回は、Qiita記事をもとに、画面設計書自動生成の改善に取り組みました。
結論として、以下のフローを用いることで、デザインツールの種類に縛られることなく、
自動生成の品質が安定しそうなことがわかりました。

座標を取得できる任意のデザインツール(HTML/Figma/draw.io等)かHTMLで画面レイアウトを作成
 => AIによる読み込み
 => PNG画像（draw.io対応）で出力

AIが読める画面設計書の需要が高まっている今、是非活用していきたいですね。
最後まで読んでいただきありがとうございます。


本記事は、元記事で提示されていた課題意識を起点に検証を進めたものです。
実践的な知見を共有してくださった筆者の方に改めて感謝いたします。

出典/参考

7
6
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
7
6

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?