デザイナーが実案件の途中からClaude Codeを使ってみた話📖
要件定義書がまだ整っていない案件で、画面を先に作りながら仕様を固めていくためにClaude Codeを使い始めました。この記事では、何をClaude Codeに渡し、何を任せて何を任せなかったかをまとめます。
要件定義書がない状態で画面制作が同時に走り出した
2026年3月に入社し、Claude Codeを使い始めたのは同年5月末からです（執筆時点で使用歴約2ヶ月）。アサインされたのは、関係するアクターの種類が多い基幹業務システムのリニューアル案件でした。普段の所属とは別の体制で動くプロジェクトへの参加だったため、Figma・GitHub・Claude Codeのアカウント権限まわりに制約があり、MCP連携はおろか閲覧すら制限されている資料もある状態でのスタートでした。
この案件では、要件定義がまだ固まりきっていない段階で画面制作を並行して進めることがすでに決まっていました。デザインはFigmaで納品し、画面・フロー・詳細仕様の合意もFigma上で行う前提です。見積もられていた画面数は当初300程度、現在はスコープが調整され200程度まで絞られていますが、それでも従来のやり方ではデザインが工程のボトルネックになるのは目に見えていました。プロンプトだけで完成形をコントロールするタイプのツールでは対応しきれないと判断し、Claude Codeのアカウントが使えるようになったタイミングで、まずは個人的に試験導入する形で使い始めました。
このシステムは、エンドユーザー・契約先企業の担当者・業務管理者・システム管理者・外部委託のサポート窓口など関係するアクターの種類が多く、アクターごとに端末も操作もまったく異なります。画面を作る前にこの構造を横断して読み解いておかないと、後工程で仕様の矛盾に振り回されることになると考え、着手前にアクターごとの役割を整理するところから始めました。
Claude Codeに渡したもの: コンテキスト→ルール→タスクの順で安定させる
タスクをいきなり投げても画面は生成されますが、根拠のないまま「なんとなくいい感じ」に作られてしまいます。そこでタスクを渡す前に、案件の背景（コンテキスト）と守ってほしいルール（レギュレーション）を先に渡す順序を徹底しました。デザイナーの仕事に置き換えると、コンテキストは案件の背景、ルールはレギュレーション、タスクは作業依頼にあたります。
要件定義書はまだ存在せず、材料は顧客要求のPDF・Miroのフロー図・画面一覧のスプレッドシートに散らばっていました。しかもそのままではClaude Codeから読める形式ではなかったため、どう変換すれば正確に読み取れるかを相談しながら、次のようなドキュメント構成に整理していきました。
CLAUDE.md：発注書にあたるファイル。誰向けの説明か、仕様の出典の優先順位、どこで作業を止めるべきかを定義- アクター別の
CLAUDE.md：ルールをアクター単位の階層に分割 docs/：顧客作成のPDF（要求定義、53本）、Miroのフロー図（32本）、画面一覧（2,000行超のCSV）などをMarkdown化して集約figma-links.md：既存のFigmaデザインシステムのうち、コンポーネント単位のURLをアクター別にリスト化Design-guide.md/spacing-rules.md：表示フォーマットや余白のルールをMarkdown化
CLAUDE.mdには、まず「自分はデザイナーであり、実装の詳細までは判断できない」という役割の宣言を置きました。そのうえで、要求と業務フロー図の内容が食い違った場合にどちらを優先するかという出典の優先順位を明記しています。この優先順位を書いておくと、資料同士が食い違ったときにClaude Codeが独断で折衷案を作らず、確認を挟むようになりました。
権限の都合でMiroのMCP連携は使えず、フロー図の矢印やメモはテキストとして読み取れなかったため、画像をいったんMarkdownに変換してから読み込ませています（この制約は直近で改善されたとの情報もあり、実際に矢印やメモを正確に読み取れるかどうかは今後あらためて検証する予定です）。
Figmaとの連携では、デザインシステム全体のURLをまとめて渡すのではなく、Button・Input・Table・Modalといったコンポーネント単位でURLをリスト化し、アクターごとのディレクトリに分けて渡しました。単位を細かくしたことで「ここのButtonを使って」という指示が正確に伝わるようになっています。
要求整理から顧客レビューまでの回し方
実際の業務フローは次の順で回しました。
- 顧客要求と、開発チームが顧客と一緒に作った業務フロー図から画面を起こす
- 開発側のレビューを通し、最新の要件定義の状況とすり合わせる
- 顧客レビューで画面を使いながら仕様の詳細を詰める
- そこで決まった内容を開発にフィードバックする
画面は提案したい業務フローを可視化したものなので、早く出せるほど後工程の詳細設計が楽になります。仕様の抜けや追加で決めるべき項目も、画面という具体物があるほうが早く見つかります。画面が納品物であると同時に、要件定義を進めるための道具にもなったという点は、この案件でのAI活用の一番の手応えでした。
任せたこと・任せなかったこと
Claude Codeにはドキュメントを読み込んで調べる作業、実装方法の調査、フォルダ構成の検討などをほぼ任せました。本開発を担うわけではないため、実装手法そのものには踏み込んでいません。
一方で、渡せるものをすべて渡したうえで、情報の強弱・見せ方・文言・フローの前後関係・不足の補い方といったUXの判断だけは手元に残しました。生成物をそのまま確定させず、おかしいと感じた箇所はそのつど指摘する運用です。これは仕上がりへのこだわりというより、あとで作り直しになる手戻りを避けるための判断でした。AIは顧客の性格や言葉の行間、言語化されていない隠れたニーズまでは読み取りにくく、ドキュメント通りの成果物は作れても、ドキュメントに書かれていないことまでは補ってくれません。
生成物への向き合い方は、AIの提案を頭から信用しないと決めているわけではありません。CLAUDE.mdに禁止事項をルールとして明文化したうえで、生成物には都度目を通してフィードバックを重ねる運用にしています。おかしな挙動が出るたびにルールを一つ追加していくことで、精度を継続的に上げていきました。
AI導入によって浮いた時間は、UXの仮説やアクターごとの隠れたニーズについてClaude Codeと議論する時間に充てました。議論用のセッションは案件の実装を進めるセッションとは別に立ち上げ、セッションごとに名前をつけてテーマを分けて整理しています。話題を混在させないことで、後から読み返したときに議論の経緯を追いやすくなりました。
隠れたニーズをどう見つけたか
隠れたニーズの具体例として挙がったのが、ログインフローにおける認証方式の不整合でした。パスキーでログインするアクターにもかかわらず、利用している認証サービスの仕様上パスワードの登録自体は必須になってしまうケースがあり、要求定義の時点ではこの矛盾に気づいていませんでした。
パスキーでログインする以上パスワードでのログインはブロックされる仕様なのに、登録画面ではパスワードの設定が求められる。ユーザーからすると、何が起きているのか分からないまま操作を進めることになります。この不整合は、画面を実際に作って可視化してはじめて発見できたもので、会議で言葉のうえだけで合意していたときには見えていませんでした。今回はパスワード登録自体をなくす対応は認証基盤の仕様上実現できませんでしたが、次善策として説明文を添えたダイアログを表示する案を開発チームと検討しました。要望や会議の議事録だけでは出てこない不整合を拾えるかどうかは、画面という具体物に落として初めて試せるという点を、あらためて実感した場面です。
おまけとして、Claude Codeへの指示に、返答を元気いっぱいのトーンにするという設定を一つ加えています。仕事の合間に眺めていると、やる気が乗らない日でもつられて元気が出てくるので、地味におすすめの工夫です。
まとめ
この案件でわかったのは、ドキュメントを渡せばドキュメントの通りに作ってくれる一方、ドキュメントに書かれていないことは補ってくれないという点でした。体験を考慮した導線設計、アクターごとの言語化されていない隠れたニーズ、顧客の言葉の行間、業務フロー自体の改善提案は、いずれも人間が担うべき領域として残りました。
今回は要件定義より前に画面を作るという順序でしたが、結果として画面そのものが仕様を決める道具になりました。AIが短時間でUIを出せるようになったからこそ、何を作るべきかを判断する人の役割は、より早い段階から必要になっていくと感じています。
こうした「コンテキスト→ルール→タスク」の順序でAIに情報を渡す考え方は、AIDD デザインのアプローチにも通じるものです。AIDDデザインを導入した案件では、開発工数を約50%短縮した事例も出ています。デザイン工程でのAI活用に迷っている方は、社内で継続的に運用ノウハウを積み上げています。お気軽にご相談ください。