UI/UXの評価であるヒューリスティック評価は、画面ごとに評価軸を当てはめてコメントを書き出す地道な作業で、ディレクターやデザイナー1人の負担になりがちです。じつは、評価結果をAIに作らせ、Figmaへのコメント投稿やNotionのチケット化まで仕組み化すれば、この作業は大きく省力化できます。ただし、API連携には独特のつまずきポイントがあり、手順を誤ると評価結果が反映されないこともあります。GOROでも、評価の手順をスキルにして運用する中で、いくつかのエラーに当たりました。評価作業の負担を減らしたいなら、まず仕組みの全体像とつまずきどころを押さえておきましょう。ここでは、Figma連携の具体的な手順と注意点を解説します。
ヒューリスティック評価とAI自動化の基本的な考え方
ヒューリスティック評価は、AIに任せられる作業とそうでない作業が分かれています。画面をチェックする判断には人の経験値が必要ですが、評価後のコメント記入やチケット化は仕組み化しやすい領域です。この境目を理解することが、自動化を検討する最初の一歩になります。
ヒューリスティック評価とは何か
ヒューリスティック評価とは、画面の設計上の問題を見つける手法です。評価者は、使いやすさの原則（ヒューリスティック）に照らして画面を判断します（How to Conduct a Heuristic Evaluation（Nielsen Norman Group））。よく使われるのは、Jakob Nielsenがまとめた10の原則です。「システムの状態を見えるようにする」「一貫性と標準」「エラーの防止」などが並び、具体的な規則ではなく大まかな経験則であることから「ヒューリスティック」と呼ばれています（10 Usability Heuristics for User Interface Design（Nielsen Norman Group））。
評価そのものは、デザイナーや担当者が画面を見て判断する作業です。Nielsen Norman Groupは、どれほど経験のある人でも1人では問題を見落とすため、3〜5人がそれぞれ独立して評価するよう勧めています。専門知識と経験が必要で、本来は時間をかけるべき工程です。
なぜAIによる自動化が注目されるのか
評価後の作業に目を向けると、状況が変わります。見つけた問題を一つずつ文章にまとめ、Figmaのコメントに書き込み、さらにNotionなどのタスク管理ツールにチケットとして転記します。この一連の作業は、判断ではなく転記と入力の繰り返しになりやすいものです。
案件数が増えるほど、この転記作業は積み重なります。評価軸は10項目前後あることが多く、1画面につき複数の指摘が出る場合もあります。結果として、以下のような負担が発生しやすくなります。
| 作業内容 | 負担になりやすい理由 |
|---|---|
| コメントの文章化 | 指摘内容を毎回ゼロから言語化する |
| Figmaへの転記 | アートボードごとに手作業で貼り付ける |
| Notionへのチケット化 | コメントとチケットの情報を二重入力する |
| 担当者間の表記ゆれ | 深刻度や指摘の書き方が人によって揺れる |
こうした転記作業は属人化しやすく、担当者が変わるたびにやり方がばらつきます。評価の質を高める時間を削ってまで、この単純作業に時間を割く状況が生まれます。
ここにAI活用の余地があります。画面の点検結果をもとに文章を生成し、Figmaのコメント投稿やNotionのチケット作成まで一連で処理できれば、担当者は評価の判断に集中できます。次のH2では、AIが実際にどこまでを任せられるのか、できることとできないことを分けて見ていきます。
なお、こうした定型作業をAIに仕組み化させる考え方自体は、Claude Codeの「スキル」とは？非エンジニアが定型業務を仕組み化する選び方で詳しく扱っています。
AIにヒューリスティック評価を任せてできること・できないこと
評価と転記を分けて考えると述べましたが、実際の境目はもう少し細かいものです。社内で運用しているスキルの設計を見ると、AIに任せる範囲と人が確認すべき範囲がはっきり決められています。
AIが得意な評価作業
決まった評価軸に沿って画面を点検し、結果を定型フォーマットに落とし込む作業はAIの得意領域です。社内のスキルでは、スクリーンショットをH1〜H10の10軸で評価し、画面名・違反軸・問題・深刻度・改善案という項目を毎回同じ形式で出力します。
深刻度は0〜4の5段階で統一されており、担当者によって表記がぶれる心配がありません。この0〜4の幅は、Nielsenが示した深刻度の尺度（0＝問題ではない、4＝リリース前に必ず直す）と同じです（Severity Ratings for Usability Problems（Nielsen Norman Group））。評価が終わった後は、Figmaのアートボードを探してコメントを投稿し、そのコメントのURLをNotionのチケットに記録するところまで一気通貫で進められます。
コードを読み取って現状のユーザー体験を可視化するスキルでも、考え方は同じです。ページやルート定義のディレクトリを機械的に調べ、タッチポイントを並べていく作業は人手より速く進みます。
| AIが処理しやすい作業 | 具体例 |
|---|---|
| 定型評価軸でのチェック | H1〜H10に沿った画面点検と深刻度の付与 |
| フォーマットへの変換 | 画面名・違反軸・問題・改善案の定型出力 |
| 転記・投稿作業 | Figmaコメント投稿、Notionチケット化 |
| コードからの事実抽出 | ページ構成やルーティングの機械的な読み取り |
人の判断・確認が必要な部分
一方で、AIが答えを持たない場面も明確に決められています。コードからユーザー体験を可視化するスキルには、推測による捏造は厳禁という条件が付いています。コードを根拠に、ユーザー体験の実態（As-Is）を逆算・可視化する設計のため、確認できないファイルパスは特定不可、評価できない箇所は情報不足のため評価不可と扱う決まりがあります。
この姿勢は、AIが根拠のない答えを作らないための仕組みでもあります。言い換えると、根拠が見つからない部分の最終判断は人に戻ってきます。改善策についても、改善策は実装レベルで具体的に記述する（「UXを改善する」のような抽象表現は禁止）という条件があり、出てきた改善案が本当に自社の実装で成立するかは、担当者が確認する必要があります。
加えて、トークンの発行や管理のような操作も人が担う範囲です。発行したトークンをメンバー間で共有せず、各自で発行するという運用ルールも、セキュリティ面で人の判断が欠かせないことを示しています。
前述のとおり、原典は複数人での評価を勧めています。AIの評価も1人分の視点として扱い、人の確認と組み合わせるのが安全です。評価軸に沿ったチェックと転記はAIに渡し、根拠が曖昧な判断とセキュリティに関わる操作は人が握る——この線引きを押さえておくと、自動化の設計で迷いにくくなります。似た切り分けの考え方はClaude Codeはデザイナーの仕事をどう変える？非エンジニアでもできる活用法でも扱っています。
評価結果をFigmaとNotionに自動反映する仕組み
前述のとおり、評価軸でのチェックと転記作業はAIに任せやすい領域です。社内で運用しているスキルは、この2つの作業を5つのステップでつなぎ、評価からチケット化までを一度に進める設計になっています。
ステップに入る前に、3つの準備が必要です。1つ目はスクリーンショットのファイル名と、Figmaのアートボード名を完全に一致させることです。先頭2桁の連番をそろえ、スペースは入れません。2つ目はFigmaの個人トークンの発行で、読み取りとコメント書き込みの2つのスコープを選びます。3つ目はFigmaのURLからファイルキーを確認しておくことです。
準備が整ったら、最初のステップとしてトークンをターミナル上でファイルに保存します。「⚠️ トークンはチャットに貼り付けない。ターミナルのみで扱う。」という決まりがあり、チャット画面に書き込んで進める方法は取れません。発行したトークンはメンバー間で共有せず、各自で発行する運用になっています。
評価軸H1〜H10で画面を評価する
トークンの準備が終わると、スクリーンショットの評価に進みます。評価軸はH1からH10までの10項目で、画面名・違反軸・問題・深刻度・改善案という5つの項目を、画面ごとに同じ形式で出力します。
深刻度は0から4までの5段階で統一されており、担当者が変わっても評価の重みづけがぶれません。この段階はまだFigmaやNotionと切り離されていて、スクリーンショットとテキストのやり取りだけで完結します。
Figma APIでアートボードにコメントを投稿する
評価結果ができたら、Figma側の操作に移ります。まずFigma APIでアートボード一覧を取得し、それぞれのnode_idを確認します。node_idは、コメントを貼り付ける場所を指定するための番号にあたります。
次に、評価結果とnode_idを画面ごとに照合し、該当するアートボードへコメントを投稿します。このとき、1つのコメントには1つの問題だけを書き込む決まりになっています。複数の指摘を1コメントにまとめないことで、後から見返したときにどの指摘が解決済みかを追いやすくなります。
NotionにチケットとしてコメントURLを残す
最後のステップは、投稿したFigmaコメントのURLをNotionのチケットに記録する作業です。コメントそのものをNotionに書き写すのではなく、URLをチケットの参照先として残す形を取っています。
この方法なら、Notion側のチケットを開けばFigmaの該当コメントへすぐ移動できます。コメントの文面を二重に管理する必要がなくなり、Figma側で返信や解決済みの操作をしても、Notion側の記録とずれにくくなります。Notionとの連携でつまずきやすい点は、Claude CodeとNotionの連携方法とは？できること・制限と実際につまずいた点を解説でも扱っています。
この5つのステップを通すと、事前準備3つと合わせて一連の流れが完成します。評価からチケット化までが1本につながることで、担当者は画面を見て判断する作業に時間を使いやすくなります。次のH2では、この流れを実際に組むときにつまずきやすいポイントを見ていきます。
自動化を構築する際につまずきやすいポイントと対処法
5つのステップは一度組んでしまえば流れますが、実際に構築する過程ではいくつかの壁にぶつかります。ここでは社内で起きた具体的なつまずきと、その対処を見ていきます。
ネストが深いフレームが取得できない
Figma APIでアートボード一覧を取得する際、最初に指定したパラメータでは一部のフレームが結果に含まれませんでした。原因はネストの深さにありました。
実録GOROの作業記録
depth指定で取得漏れが起きた
「重要：
?depth=5を指定する（depth=3ではネストが深いフレームが取得できない）」出典：GOROの社内の作業記録
Figmaのデザインファイルは、グループの中にグループが入っている構造になりやすいものです。階層が浅い指定のままでは、奥にあるアートボードのnode_idが取得対象から漏れます。評価結果とnode_idを照合する段階で該当するアートボードが見つからず、コメントを投稿できない状態になります。
対処は深さの指定を広げることです。取得範囲を広くしておけば、ネストの深いフレームも一覧に含まれます。この設定は構築の初期段階で決めておき、案件ごとに調整し直さない方が運用が安定します。
Figmaコメントはプレーンテキストのみ
評価結果の文章をそのままコメントに投稿すると、見た目が崩れる問題も起きました。原因はFigmaコメントAPIの仕様にあります。
実録GOROの作業記録
マークダウン記法がそのまま表示される
「⚠️ FigmaコメントAPIはプレーンテキストのみ。
*text*などのマークダウン記法は使用しない（*がそのまま表示される）。」出典：GOROの社内の作業記録
評価結果を強調しようとアスタリスクで太字表記にすると、Figma上ではアスタリスクの記号が文字としてそのまま残ります。改行や箇条書きの記法も同様に、意図した見た目になりません。
評価結果をコメント文に変換する段階で、装飾を使わない書式に統一しておく必要があります。画面名・違反軸・問題・深刻度・改善案という項目を、記号で強調せず、改行と文章だけで区切る形にすると表示が崩れません。
トークンの扱い方
構築の初期段階に発行したFigmaの個人トークンも、運用を続けるうちに扱い方で判断に迷う場面が出てきます。
実録GOROの作業記録
トークンはチャットに貼り付けない
「⚠️ トークンはチャットに貼り付けない。ターミナルのみで扱う。」
出典：GOROの社内の作業記録
トークンはFigmaへの読み取りとコメント書き込みの権限を持つ文字列で、外部に漏れると他人がその権限でAPIを操作できてしまいます。チャット画面に貼り付けて進めたくなる場面もありますが、やり取りの履歴に残ってしまう点が問題になります。
対処として、トークンはターミナル上でファイルに保存し、チャットの入力欄には書き込まない運用に統一しています。加えて、よくあるエラーとしてInvalid token・Invalid scopeが記録に残っており、トークン発行時に選ぶスコープを読み取りとコメント書き込みの2つに正しく設定できていないと、この種のエラーで止まります。「コメントが見えない（見ているページが違う）」という現象も記録されており、投稿先のアートボードとFigma上で開いているページが一致しているかを確認すると解決することが多いです。
これらのつまずきは、いずれも一度対処を仕組みに組み込んでしまえば再発しない性質のものです。構築を始める段階でこの3点を押さえておくと、途中で止まる回数を減らせます。次のH2では、実際に導入する際に押さえておきたいセキュリティ面の注意点と、始め方の手順を見ていきます。
非エンジニアが導入する際の注意点とはじめ方
評価の自動化をFigmaと連携させる以上、権限の管理は欠かせません。最後に、導入前に整理しておきたい注意点と、実際に手を動かし始める進め方をまとめます。
トークン管理などセキュリティ面の注意
前述のとおり、Figmaの個人トークンはチャット画面に貼らず、各自で発行して使う運用が決まっています。この原則は、コードを書けない担当者がチームで仕組みを使う場面でも変わりません。
複数人で同じ仕組みを使う場合、押さえておきたい点を整理します。
- 担当者ごとにトークンを分けて発行する（誰の操作か後から追える状態にする）
- トークンの保存場所をチームで統一し、個人のメモ帳やメッセージアプリに残さない
- 担当者の異動・退職のタイミングで、該当のトークンを無効化する運用を決めておく
- Figmaのスコープは必要な範囲（読み取り・コメント投稿）だけに絞って発行する
エンジニアが社内にいないチームほど、こうしたルールは曖昧になりやすいものです。誰がいつトークンを発行したかを記録する一覧表を作るだけでも、管理の抜け漏れは減らせます。スコープの種類や権限範囲の最新情報は、都度Figmaの公式ヘルプで確認する姿勢も必要です。
自分たちの業務に合わせて仕組み化するステップ
仕組みを一から設計し直す必要はありません。手元の業務のどこが転記作業になっているかを洗い出すところから始めると、導入の輪郭がつかみやすくなります。
- 評価からチケット化までの作業を書き出し、判断の工程と転記の工程を分ける
- 転記の工程だけを対象に、入出力のフォーマットを固定する（評価軸・深刻度の段階・コメントの書式など）
- Figmaのアートボード名やファイルの命名規則を、仕組みが読み取りやすい形にそろえる
- 小さな案件1件だけで一通り試し、コメント投稿とチケット化が狙いどおりに動くか確かめる
- うまく動いた範囲から対象の案件を広げ、運用ルールをチームの手順書に残す
この進め方のポイントは、最初から全ての案件に広げないことにあります。フォーマットを固定する工程でつまずくと、後続のコメント投稿とチケット化も崩れやすくなります。1件で動作を確かめてから対象を広げれば、修正が必要な箇所も小さく保てます。
コードを書く工程は仕組みの内部に隠れていて、担当者が直接触るのはプロンプトの入力と、FigmaやNotionの画面だけになります。評価の判断に時間を使いたいという動機に立ち返り、まず手元の転記作業を1つ選んで、フォーマットを固定するところから着手するのが現実的な進め方です。
この記事と合わせて読みたい
- Claude Codeの「スキル」とは？非エンジニアでもできる作り方と活用事例を解説 — この記事で紹介した評価の手順化は「スキル」という仕組みを使っているため、スキルの基本的な作り方や選び方をより詳しく知りたくなる
- Claude CodeとNotionの連携方法とは？できること・制限と実際につまずいた点を解説 — 評価結果をNotionにチケット化する際の連携方法やできること・制限についてさらに詳しく知りたくなる
- Claude Codeはデザイナーの仕事をどう変える？非エンジニアでもできる活用法 — ヒューリスティック評価以外にも、デザイナーの日常業務がAIでどう変わるのか、具体的な活用法を広く知りたくなる
Claude Codeの社内導入を検討している方へ
GOROは、デザイナー・マーケ担当・ディレクターなど非エンジニアの部署を対象にしたClaude Code法人研修を提供しています。事前ヒアリングで業務の内容を伺い、研修の内容を設計します。研修の当日に、受講者が実際の成果物を作り切る形式です。
