AIが作るデザインはテンプレート感が出がち？huashu-design 3.0：AIに見せ、試させ、同じ見た目の量産を減らす

花叔（Huashu）が huashu-design 3.0 をリリースしました。これはオープンソースのデザイン Skill であり、Agent が読み込むための一連のデザイン仕様書、参考資料、およびチェック用スクリプトで構成されています。ターミナル上で動作する Agent は、これらの資料を読み込むことで、この体系に沿った Web ページ、PPT、App プロトタイプを作成できるようになります。

インストール後、Skill 機構をサポートする Agent のコマンドラインで一言の要望を入力すると、Agent が自律的に素材を探し、レイアウトを構成し、HTML ファイルを出力します。主に以下の制作形態をカバーしています。

• インタラクティブプロトタイプとランディングページ：単一 HTML ファイルで構成されるインタラクティブな Web プロトタイプ、公式サイト、および App のマルチスクリーン展示ボード；
• 編集可能なスライド：1920×1080 の固定キャンバスを採用した HTML Deck。再編集可能な PPTX プレゼンテーションファイルへのエクスポートに対応；
• モーショングラフィックスとインフォグラフィック：タイムラインベースの CSS/Canvas アニメーション、ビデオ絵コンテ、および実際のオープンデータを組み合わせた縦長インフォグラフィックの可視化；
• 3つの方向性の初稿：新しいビジュアル要件に対し、Agent はデフォルトで異なる3つの方向性のデザイン案を提示し、ユーザーが実物を見比べながら選定した上で詳細な作り込みへと進められます。

適用範囲として、huashu-design はビジュアルプロトタイプの探索や各種素材デザインに適しており、バックエンド連携を伴う本番稼働レベルの Web アプリケーションやシステム開発には適していません。長文ドキュメントを読むのが苦手な場合は、まず作者本人が収録した16分間のハンズオン解説動画を視聴することで、実際の効果と操作手順を直感的に把握できます。

なぜルールを増やすほど、デザインは退屈になるのか

AI を使って Web ページやスライドを日常的に作成しているクリエイターは、ある種の「見えない疲労感」に直面しがちです。単体で生成されたページは整然として美しく見えても、いくつかプロジェクトを続けると、ページの構造や配色がどれも酷似してくるという問題です。

2.0 バージョンでは、「トップデザイナー」「実在リファレンス」「秒数ルーレット」という3つのロジックを用いて各案の違いを引き出そうとしていました。しかし数か月使い続けた後、作者は新たな問題に気づきました。個々のプロジェクトで見ると悪くないのに、並べて比較すると非常によく似ているのです。温かみのあるクラフト紙風の地色、セリフ体の見出し、テラコッタカラーのアクセントという組み合わせが、異なるプロジェクトで何度も繰り返し登場していました。旧バージョンで実施したテスト課題を振り返って検証したところ、5組中3組で3つの方向性の色が被り、同じ外観系統に偏っていました。その根本的な原因は、旧 Skill の中に「温かみのあるクリーム色の地色＋セリフ体＋テラコッタ色」というデフォルトの外観がハードコードされていたことにありました。クラフト紙風の質感やセリフ体自体は優れたものですが、問題は異なる題材のすべてがこの見た目へと引き寄せられてしまう点にありました。

作者はランディングページ、クラウドファンディング用 PPT、インフォグラフィック、App プロトタイプをテスト課題とし、改修前後のデザイン案の順序をシャッフルして壁一面に並べ、自身でブラインドテストを実施しました。その3ラウンドの結果は非常に示唆に富むものでした。

• 第1ラウンド（4問中わずか1勝）：各方向性に「大きなメタファー（比喩）」を持たせることを義務付けました。その結果、多くのページが具象的な小道具へと仕立て上げられてしまいました。クラウドファンディングの PPT が「図書貸出カード」の形になったり、App プロトタイプが丸ごと「地下鉄路線図」に当てはめられたりして、過剰な演出がコア情報を覆い隠してしまいました。
• 第2ラウンド（2問全敗）：「2026年 AI デフォルト外観リスト」といくつかのガードレールを追加し、ネガティブリストによって Agent をありがちな見た目から締め出そうとしました。その結果、Agent は極端に保守的になり、提案されたデザインはすべて無機質な浅い寒色と整然としたグリッドばかりで、ひどく平板で退屈なものになりました。旧バージョンで好評だったダークトーンのカードや温かみのある紙の余白までもが、ルールによって排除されてしまったのです。
• 第3ラウンド（2問全勝）：発想を逆転させ、「禁止事項を増やすのではなく、選択肢を増やす」方針へと改めました。すなわち、Agent に目に見える実在のサンプルや参考作品を先に見せるようにしたのです。これはすべてのルールを撤廃したわけではなく、テンプレート特有の装飾の排除や、フォントサイズ、コントラスト比といった可読性の最低基準は維持しつつ、スタイルの探索においてネガティブリストによる制限を設けないようにしました。

第3ラウンドの「2問全勝」は、作者が少数の課題を対象に個人的に行った選択の結果にすぎず、元の告知文にあった「デザインの審美眼が 100% 向上する」という表現にそのまま置き換えられるものではありません。この改修から学ぶべき価値があるのは、「目に見える選択肢を豊富に提供し、Agent に具体的な参照先を持たせる」というアプローチです。

6つの方向性をまず試作し、3案を選び抜いて深掘りする

3.0 では、新規のビジュアルデザインに対して「3方向ゲート（Three Directions Gate）」の通過をデフォルトで義務付けています。同一プロジェクトで方向性が決定した後のイテレーション、機械的な単純作業、またはユーザーが明示的にスキップを要求した場合は免除されます。このワークフローは単に当てずっぽうで3つの案を作るのではなく、Agent に対して3つの探索ルートからそれぞれ2つずつ、計6つの候補案を構想するよう定めています。マルチ Agent をサポートする環境では並列で作成でき、リソースが限られた軽量なランタイム環境では直列で実行することも可能です。これらの候補に対して初期スクリーニングを行い、構造が明確に差別化された3つのデザインを選定した上で、それぞれのメディアに応じた本番初稿へと仕上げます。

1. 6つの候補はどのように導き出されるか

Agent は以下の3つのアプローチから、それぞれ2つの候補を構想します。

• トップデザイナー（ゼロからの構想）：今回の題材に適したデザイナーやデザインスタジオ（原研哉、田中一光、呂敬人、Irma Boom など）を考察し、代表作の表面的な模倣ではなく、そのレイアウト構成や余白の思考法を取り入れてゼロから設計します。
• 実在リファレンス（同一メディアのベンチマーク）：同一のメディアの中から優れた実在の作品を探します。App を作るなら優れた App（デザインアワード受賞作など）、Web ページなら秀逸な Web サイト、スライドなら質の高い出版物を参照します。組み込みスクリプト ref_board.py を通じてリファレンスのスクリーンショットをボード化し、Agent がグリッド、フォントサイズ比、図版とテキストの関係を視覚的に正確に把握できるようにすることで、テキスト上の印象だけで構成されるのを防ぎます。
• 秒数ルーレット（見本サンプリング）：実行時のシステム秒数の剰余に基づき、該当メディアの分類と、メディアをまたぐ東アジア分類からそれぞれ1つずつスタイルを抽出します（84種類から均等に抽選するわけではありません）。スタイルライブラリは従来の60種類から84種類へと拡張され、Web 20種、PPT 20種、インフォグラフィック 20種、App 12種、および中国・東アジア 12種に明確に区分されています。各スタイルには見本画像が用意されており、Agent は完成形の見本を確認してから構想に着手しなければなりません。ルーレットの狙いは、普段 Agent が思いつきにくいビジュアルの方向性へと誘導することにあります。

2. サムネイルによる初期スクリーニングで試行錯誤のコストを下げる

6つの候補を生成する際、Agent は最初から6組の完全なコードを書くのではなく、まず design-demos/thumbs.html という6分割のサムネイルパネル（各枠約 480×300 ピクセル）を生成します。ここには実際のフォント、配色、レイアウト骨格、見出しが含まれ、インタラクションの細部は省略されます。Agent は画像認識能力を活用してこのサムネイルを精査します。サムネイルの段階で構造が成り立っていないものは、完全版を作っても成立しないため、この段階で案を差し替えることで手戻りのコストを大幅に削減できます。

3. どのようにデザイン案を絞り込むか

6つの候補から3つを選んで完全なデザイン案へと昇格させるため、以下の4つの基準に沿って選定を行います。選出されるデザイン案はルールに基づいて絞り込まれた候補であり、アルゴリズムが必然的にデザインの品質を保証することを意味するわけではありません。また、各ルートから必ず1案ずつ残す必要もありません（例えば、トップデザイナーから2案＋ルーレットから1案という構成も可能です）。

1. 単体で自立しているか：視線の重心が明確で、階層構造が散漫になっていないか。サムネイルの段階で成立していないものは、完全版でも救いようがありません。
2. 3案の骨格が互いに異なっているか：「ガワ替え（スキン変更）」を避けます。ガワ替えとは、グリッドやフォントサイズが完全に同じで色だけを変えることを指します。真の差異とは、レイアウトの骨格、図版とテキストの関係、そして閲覧動線の違いを指します。
3. 直近の台帳履歴を回避しているか：ローカルの履歴記録を読み込み、直近のいくつかのプロジェクトで使用されたばかりの外観やリファレンスを能動的に避けます。
4. メタファー（比喩）が過剰でないか：判断基準は一つだけです——「その演出手法を取り除いたとき、コア情報はより明確になるか、それとも曖昧になるか？」。取り除いた方が明瞭になるものは、過剰な演出（ページ全体を図書カードにしたり、地下鉄路線図に押し込めたりするなど）と判断されます。ページ全体を小道具に見立てたり、強引なメタファーを当てはめたりする手法は、3案の中で最大1案までに留め、コンテンツ上真に必要な場合にのみ使用します。

リファレンスはどのように具体的なデザインになるのか：4つの事例

作者が公開した4つの事例から、これらの手法がレイアウト上にどのように具体化されているかを確認できます。

事例1：葛飾北斎『富嶽三十六景』オンライン特別展（Web）

この文化的な題材に対し、システムが生成した3つの方向性はまったく異なるビジュアルトーンを提示しました。第1案はアムステルダム国立美術館（Rijksmuseum）のような暗い空間の展示ケースを採用し、第2案は田中一光の幾何学的な三角窓を抽出し、第3案は東洋の装丁に見られる「書衣・題簽（題箋）」を取り入れました。

この事例では、実際のコンテンツ構成が具体的なレイアウトの意思決定に直接影響を与えています。

• サンプル内の全46点の絵画素材は、シカゴ美術館とメトロポリタン美術館のオープンアクセスコレクションから取得されています。
• 「プルシアンブルー」を紹介するセクションでは、メトロポリタン美術館の研究成果に沿ってページレイアウトが構成され、濃色での重色印刷と淡色の純粋なプルシアンブルーの対比が示されています。底部には、画面上の色見本がデジタル画像のピクセルから抽出されたものであり、顔料の実測値ではなく参考値である旨が明記されています。
• 作者のデザインチェックレポートにより、2つの案でファーストビューに『神奈川沖浪裏』が重複して選ばれていたことが判明し、ダークトーンの案を『山下白雨』に差し替えることで画面のバリエーションを確保しました。

事例2：「鸣迹（Mingji）」野鳥観察記録アプリ（App プロトタイプ展示ボード）

従来のプロトタイプ展示では、複数のスマートフォンを等間隔で並べることが多く、画面が単調になりがちでした。作者はリファレンスボードにおいて、Apple Design Awards を受賞した「CapWords」を同一メディアのリファレンスとして提示し、その写真ステッカーによる収集の質感を借用しました。

リファレンス作品から取り入れたのは、「写真からステッカーを剥ぎ取る」ようなインタラクションの質感です。

• 野鳥の素材は Wikimedia の実在写真から切り抜かれ、白いフチ付きのステッカーとして1年間の記録手帳へと貼り付けられます。
• 鳴き声の波形は実際の録音データに基づいて演算・生成されており、プロトタイプのインターフェースをより現実の記録シーンに近づけています。

事例3：「今晩何食べる？」家庭料理レシピ（App プロトタイプ）

この課題では、秒数ルーレットによって呂敬人のブックデザインスタイルが選ばれました。

エディトリアルデザインのレイアウト規則がモバイルインターフェースへと移植され、調理に必要な重要情報が際立っています。

• 1品につき1ページ：ページは見開きの料理本のように構成され、構造が明快で手順が一目で分かります。
• 独立したサイドノート欄：ページの小口（端）側に専用のメモ欄を設け、「水気を拭き取ってから焼くと油が跳ねない」「老抽（中国の濃口醤油）は数滴で十分」といった実践的なコツを記載することで、本文の手順とコツのヒントが互いに干渉しないようにしています。
• 朱肉の印章：画面全体の中で、鮮やかな朱赤の印章を「調理開始」のアクションだけに割り当てることで、主要な導線を際立たせ、無駄な色面によるノイズを抑えています。

事例4：『千里江山図』講演プレゼンテーション（Deck）

スライドを制作する際、Agent は「トップデザイナー」のアプローチにおいて、Abbott Miller によるダークトーンの展示空間の設計思想を参照しました。

レイアウトデザインは、長大な絵巻を鑑賞する体験に深く寄り添っています。

• スライドの暗い背景色は、絵画が描かれた絹本の最も深い色から直接抽出されています。
• 表紙の下部には絵巻全体の細長い縮小ナビゲーションバーがデザインされており、全長11.9メートルの絵巻の中でこのページがどの位置に該当するかを枠で示すことで、聴衆が全体感を把握できるようにしています。
• 後続のページは作品の内容に沿って展開され、作品の寸法、「希孟年十八歳」という題跋に見る作者の年齢、豆粒のように微小な人物のディテール、石青・石緑といった鉱物顔料の解説へと進みます。

スクリプトで構造的欠陥を検知し、履歴記録で次回の選択を最適化する

一連のプロセスにおいて、huashu-design は性質の異なる判断基準を明確に分離しています。

• 測定可能な問題はスクリプトで検査：フォントサイズが小さすぎないか、コントラスト比が基準を満たしているか、画像リンクが切れていないかといった物理的事実は、design_lint.py がヘッドレスブラウザを通じて直接測定します。
• 審美的な良し悪しはユーザーが判断：スクリプトはデザインが美しいかどうかを評価する役割は担いません。検査用 Agent が付けた高得点も、ユーザー自身の納得の代わりにはならず、最終的な美の判断は完全にユーザーに委ねられます。
• コンテンツの事実は原文と別途照合：文字やデータの事実関係は、レイアウトやコントラストのチェック用スクリプトでは検出できません。例えばウェッブ宇宙望遠鏡の科学解説課題において、初稿では論文中の「数が約100倍多い」という記述を「100倍明るい」と読み間違えていましたが、最終的に別枠で立ち上げた独立したファクトチェック Agent が原文と照合したことで初めて修正されました。

1. design_lint.py：事実のみを計測し、審美性は評価しない

このスクリプトはブラウザを駆動してページをレンダリングし、テキストとスクリーンショットの情報を抽出して、検証可能な事実のみを検査します。

• 赤信号（納品をブロック、修正必須）：画像のリンク切れ、本文やラベルのフォントサイズが下限を下回っていないか、テキストと背景の相対輝度コントラスト比が基準を満たしているか（通常テキストは 4.5:1、大きな文字は 3:1 以上が必要）、およびブラウザコンソールにエラーが出ていないかを検出します。
• 黄信号（テンプレート特有の装飾をクリーンアップ）：全大文字で字間を極端に広げた小さなラベル、無意味な中黒による羅列（A · B · C）、ボタン末尾の不要な矢印（→）、見出し内の単語に対する孤立した色替え、連番ではないコンテンツに強引に振られた 01/02/03 といったナンバリングを検出します。こうした機械的に生成されがちな装飾は直接削除すべき対象となります。
• 外観フィンガープリントと類似度のアラート：スクリプトはページの地色、フォント、メインパレット、およびレイアウトの骨格ベクトルを抽出して比較を行います。カラーパレット間の平均距離は Oklab 色空間を用いて計算されます。これらの類似度チェックは「ガワ替え」やスタイルの衝突に対するヒントにすぎず、絶対的な審美的判決ではありません。ユーザーのタスク自体がブランドカラーやフォントを指定している場合は骨格のみを比較すればよく、App のマルチスクリーン並列表示のように構造上必然的に骨格が同一になる形態では、レイアウト類似度のアラートを無視することも可能です。広く普及している外観スタイル自体に問題があるわけではなく、似ているからといって劣っているとは限らないため、ヒューリスティックなルールで審美眼の判断を直接代替することはできません。

2. ローカル履歴：新しいプロジェクトでの重複を回避する

新しいセッションにおいて過去のプロジェクトで得られた具体的な好みや外観の履歴を活用するには、それらの情報を保存し、再読み込みできる仕組みが必要です。同じような見た目の繰り返しを防ぐため、3.0 ではローカルディレクトリ ~/.huashu-design/ 内に3種類の記録を保持しています。

1. テイストファイル（experience.md）：ユーザーが口頭で伝えた好みの言葉を一語一句記録し、その適用範囲を明記します。例えば作者が個人の旅行滞在アーカイブを作成した際、何気なく発した「できるだけ漏れがないように」という要望をシステムはファイルに記録しましたが、これは写真アーカイブにのみ適用され、製品インターフェースには波及させない旨が明記されました。
2. 外観台帳（ledger.jsonl）：納品が成功するたびに、その地色の分類、メインパレット、見出しフォント、レイアウト骨格を記録します。次回作業を開始する前にチェックを実行し、直近で頻繁に使用された組み合わせを能動的に回避します。例えば外観台帳によって、直近6件の納品のうち5件でサンセリフ体の見出しが使われていたことが検知された場合、後続のプロジェクトである料理レシピや北斎展の見出しには意図的に明朝体（宋体）が選ばれ、フォントの重複が回避されました。
3. 経験と落とし穴：単一プロジェクトで初めて観察された現象（observed）と、複数回の再現や測定によって検証された結論（verified）を区別して記録します。汎用的かつ検証済みのルールのみが、Skill と共に配布されるナレッジドキュメントへと昇格します。

新しいタスクを開始する前、Agent は関連するテキストをコンテキストに再読み込みすることで選択を調整できます。これによってモデルの重み自体が書き換わるわけではありません。

ユーザーの好みを記録する際、Agent は事前にユーザーへ通知する必要があります。ユーザーが不要と答えた場合は記録しません。これらの記録はローカルマシンに保存され、Skill と共に外部配布されることはありません。Agent が記録を読み込んだ後にローカルモデルで処理するかクラウドモデルで処理するかは、使用している環境に依存します。

利用を開始する手順

初めて使用する場合は、まず一連の PPT 制作に沿って進めるのがおすすめです。Skill のインストールと自己診断を行い、要望を出し、3つの代表ページを確認し、方向性を決定した上で残りのスライドを作成・エクスポートします。以下に、各ラウンドでそのまま Agent に送信できるプロンプトを掲載します。Web、App、アニメーションについてもそれぞれ対応する演習を用意しています。

作者は初期バージョン向けに16分間の実際の操作動画を収録しています。その一部の仕組みは 3.0 で進化していますが（例えば3方向の選定が「直接3案を出力」から「まず6つのサムネイルを作成して3案を厳選」に変更された点など）、核となる対話ロジックやデザイン思想は一貫しています。手を動かす前に、まず作者のデモを視聴してみることをお勧めします。

16分13秒の完全版チュートリアル動画を視聴するほか、手元の作業に合わせて作者が設定した各チャプターへ直接スキップすることも可能です。

• 03:09 スライド（PPT）実践演習
• 06:39 プロフィールページと写真からの配色抽出
• 10:43 iOS ToDo管理 App プロトタイプ
• 12:47 プロダクトプロモーションアニメーションとタイムライン
• 15:46 インストール方法と一般的な環境連携

1. 準備作業：システムターミナルと Agent の対話ウィンドウの区別

作業を始める前に、初心者が最も混同しやすい操作インターフェースの違いを整理しておきます。

• システムターミナル（macOS の Terminal/iTerm、または Windows の PowerShell/CMD）：Node.js の環境確認、インストールやアップデートのコマンドを実行するために使用します。
• Agent 対話ウィンドウ（Claude Code のターミナルセッション、Cursor の Chat サイドバー、Codex など）：Skill を読み込み済みのモデルに対し、具体的なデザインの指示や修正要望を送信するために使用します。

huashu-design 自体は Skill（機能拡張パッケージ）であり、GUI を備えた単体の独立アプリや、独立したクラウド SaaS ではありません。利用可能なモデルと基本的な実行権限を備えた既存の Coding Agent 上で動作することが前提となります。デザインの生成品質やコード記述能力は、ホストとなる Agent が接続しているモデルの推論能力およびマルチモーダル性能に依存します。

まず PC のターミナルで、Node.js と npx 環境が整っているかを確認します。

node --version
npx --version

もしターミナルに「コマンドが見つかりません（command not found）」と表示された場合、実行環境がまだインストールされていません。Node.js の公式サイト nodejs.org から、現在の LTS（長期サポート）バージョンをダウンロードしてインストールしてください。インストール完了後、ターミナルを再度開いて上記2つのコマンドを実行し、確認します。

生成されたファイルがシステム内に散乱するのを防ぐため、今回の演習専用のプロジェクトディレクトリを作成し、そこへ移動することをお勧めします。

mkdir huashu-demo
cd huashu-demo

各ホスト Agent によって Skill のインストールパスは異なります。すべてのホストが同じグローバルディレクトリに設定を書き込むと思い込まないように注意してください。

2. インストール、ディレクトリ構造の確認、セッションの読み込み

システムターミナルで、公式が推奨するインストールコマンドを実行します。

npx skills add alchaincyf/huashu-design

実行後、対話型インストーラーによって検出されたホスト環境（Claude Code、Cursor、Codex など）が一覧表示されます。普段使用している Agent をカーソルで選択し、インストールを確定してください。

インストールディレクトリの完全性の確認

インストールが完了したら、必ずインストールディレクトリのファイル構造を確認してください。huashu-design には膨大な見本画像、スタイルリファレンス、エクスポート用スクリプト、プリセットコンポーネントが含まれており、決して SKILL.md 単一ファイルだけで構成されているわけではありません。Claude Code のデフォルトパス（~/.claude/skills/huashu-design/）を例に挙げると、正常なディレクトリには少なくとも以下の内容が含まれている必要があります。

• SKILL.md：中核となるワークフローと仕様規約の説明；
• references/：Web ページ、スライド、インフォグラフィック、アニメーションなどのモジュールマニュアルおよび組版・フォントガイド；
• assets/：84種類のネイティブスタイル見本、デバイスフレームコンポーネント（ios_frame.jsx など）、効果音ライブラリ；
• scripts/：デザインチェック用スクリプト（design_lint.py）、リファレンスボード生成ツール（ref_board.py）、履歴管理スクリプト；
• demos/：各機能モジュールの基本的なデモ。

もしインストール先を確認して SKILL.md の単一ファイルしか存在しない場合、古いバージョンの skills CLI（≤1.5.15）において単一ファイルしか同期されない問題が README に記載されています。その場合は @latest タグを付けたコマンドで再インストールを試みてください。

# システムターミナルで実行
npx skills@latest add alchaincyf/huashu-design

Agent が正しく読み込んでいるかの確認

すでに開いている古いセッションで質問を投げても、新しい Skill が自動的に反映されるとは限りません。ホスト Agent で新規セッションを立ち上げ、モデルに読み込みと自己診断を促す明確な指示を送信することを推奨します。

タスク指示：
インストール済みの huashu-design SKILL を読み込み、検出されたバージョン番号と現在の Skill のルートディレクトリのパスを報告してください。

Agent がバージョン 3.0.0 を読み込み、references と scripts のパスを正常に特定できた旨を返答すれば、タスクを開始する準備は完了です。

CLI によるインストールが不完全な場合、リポジトリでは Git クローンによる導入方法も提供されています（GitHub へのアクセス環境が必要です）。README に明記されている Claude Code のパスを例にします。

# システムターミナルで実行
git clone https://github.com/alchaincyf/huashu-design.git ~/.claude/skills/huashu-design

対象ディレクトリにすでに同名の旧バージョンフォルダが存在する場合は、安易に上書きせず、事前にバックアップを取るかパスを確認してください。その後の日常的なアップデートは、実際にクローンしたディレクトリで git pull を実行するか、インストールコマンドを再度実行してください。

3. 完全ハンズオン演習：30分間のプレゼンテーション（4ラウンドの対話）

スライド（Deck）は、要件定義、3方向ゲート、内容の具体化、編集可能なエクスポートまでを一気通貫で体験できる代表的なシナリオです。以下の手順は、作者の動画（03:09–06:39）にある事例を参考にしています。プログラミングの知識がないデスクワークの会社員に向けて、Coding Agent と Claude Code の基本的な活用法を解説する30分間の対面セミナー用スライドを作成します。

この演習では制作を4つのラウンドに分け、各ラウンドの結果を確認してから次へ進めることで、最後まで作ってから方向性の不一致に気づくリスクを防ぎます。

第1ラウンド：初期プロンプト（ターゲット層、テーマ、3方向ゲートの制約の明示）

新規作成した演習用ディレクトリで Agent の対話を開き、以下の構造化された初期指示を送信します。※本文のプロンプトは作者のデモの思考手順に沿って整理したものです。読者は日本語または英語のいずれかを選択して Agent に送信できます。

タスク指示：
対面セミナーで使用するスライドを作成したいです。テーマは、非エンジニアのオフィスワーカーに向けて Coding Agent の概要と Claude Code の基本的な使用ロジックを解説することです。全体の所要時間は約30分です。huashu-design の仕様を遵守してください：
1. 聴衆にはプログラミングの基礎知識が一切ありません。Anthropic 公式の公開資料とブランドトーンに基づいて設計し、存在しない機能を捏造しないでください；
2. 「3方向ゲート」を厳格に適用し、まず6つの候補サムネイルを考案した上で、骨格が異なる3つの方向性を推薦してください。各方向性につき、最も代表的な2ページ（表紙とキーとなるコンテンツページ）のみを作成してください；
3. 3つの方向性の代表ページを生成したら、一度処理を止めて私の確認を待ってください。私が承認するまで後続のスライドを一括生成しないでください；
4. 最終成果物には、ブラウザで直接再生可能な HTML Deck、ベクター形式でテキスト検索が可能な PDF、およびプレゼンテーションソフト上でダブルクリックして文字編集が可能な PPTX を含める必要があります。

Task:
I need to create a slide deck for an in-person presentation introducing Coding Agents and the core concepts of Claude Code to non-technical white-collar professionals. The presentation will last about 30 minutes. Please follow the huashu-design workflow:
1. The audience has no programming background. Base the design on official public materials and authentic brand style, without inventing non-existent features;
2. Strictly follow the Three Directions Gate: first generate a 6-candidate thumbnail board, pick 3 structurally distinct directions, and build only 2 representative showcase slides per direction (cover and key content slide);
3. Stop and wait for my visual review once the 3 directions are ready; do not batch-generate the rest of the deck without approval;
4. The final delivery must include a browser-playable HTML Deck, a vector-searchable PDF, and an editable PPTX file with double-clickable text boxes.

このラウンドで得られるべき結果：Agent は design-demos/thumbs.html（6枠のサムネイル一覧）と design-demos/dir-1/、dir-2/、dir-3/ の3つのサブディレクトリを作成し、それぞれ2ページの代表スライドの HTML とスクリーンショットを出力します。同時に、Agent はターゲット層の知識レベルや重点とすべき事例に関する簡潔な質問を提示し、あなたのフィードバックを待ちます。

第2ラウンド：背景情報の補足と方向性の決定（早期のすり合わせ）

この段階では、Agent は駆け出しのデザイナーのように具体的な提案を示しながら前提条件をすり合わせてきます。スクリーンショットを確認して好みのビジュアル構造を選び、提示された質問に回答します。

方向性を確定させるか、要素の組み合わせ（ミックス）を指示します。以下の方向性番号や特徴は記述のサンプルですので、実際に確認・選択した内容に置き換えてください。

タスク指示：
3つの方向性の代表ページのスクリーンショットを確認しました：
1. 全体として Direction 1 のダークトーン展示の骨格とテキストのコントラスト階層を採用しますが、Direction 3 の柔らかなカード強調色を取り入れたいです；
2. 聴衆の最大のペインポイントは日常のオフィス文書処理と情報収集にあります。事例の重心を一般的なオフィスワークの場面に置き、低レイヤーのコマンドライン引数などの解説は省いてください；
3. 私の選択を direction-approved.md に記録して現在のデザインシステムを確定させ、確認用として全8〜10ページのスライド構成案（アウトライン）を出力してください。

Task:
I have reviewed the screenshots of the three directions:
1. I choose Direction 1's dark exhibition layout and typography hierarchy, but blend in Direction 3's softer card accent color;
2. The audience's main pain point is daily office document processing and info gathering; focus the examples on everyday white-collar tasks, skipping low-level CLI parameters;
3. Record my choice into direction-approved.md, lock this design system, and draft a complete 8-10 slide outline for my review.

このラウンドで得られるべき結果：Agent はプロジェクトのルートディレクトリに direction-approved.md を生成し、ユーザーの指示の原文とミックスの決定内容を記録します。その後、表紙、課題提起、製品コンセプト、オフィスでの実戦事例、よくある懸念点、まとめを含むアウトライン一覧を提示します。

第3ラウンド：構成の承認、残りのスライド生成と微調整

構成案に問題がなければ、Agent は単一ページコンポーネントの一括記述を開始します。スライドはデフォルトで「複数ファイル＋概要ウォール」アーキテクチャを採用しているため、各ページは独立した HTML ファイルとして生成される必要があります。

タスク指示：
構成案（アウトライン）に問題ありません。確定したデザインシステムに従い、残りのすべてのスライド単一ページを生成してください。要件：
1. 各ページを slides/slide-*.html として独立して保存し、ページ内部にページ番号をハードコードせず、外枠の概要ウォール側で一括制御してください；
2. 4ページ目の「重要事例の比較」では、同一の事務作業における「手動での段階的処理」と「Agent 協調処理」のステップ比較を分かりやすく示す左右2カラム構造を採用してください。実測記録がない場合は所要時間や効率の数値を勝手に追加しないでください；
3. 可読性の最低基準を厳守してください：本文フォントサイズ ≥24px、注釈ラベル ≥16px とし、全体のレイアウトの一貫性を維持してください。

Task:
The outline looks good. Please generate the remaining slide HTML files according to the locked design system:
1. Save each page independently as slides/slide-*.html. Never hardcode page numbers inside slide content; let the shell overview manage indexing;
2. For Slide 4 (Case Comparison), use a side-by-side card layout comparing manual steps and Agent-assisted steps for the same office task; do not add time or efficiency figures without measured records;
3. Strictly enforce readability thresholds: body text >= 24px, label/annotation >= 16px, maintaining global visual coherence.

このラウンドで得られるべき結果：プロジェクトディレクトリに各単一ページファイルと、一覧表示用の index.html が生成されます。ブラウザで index.html を開き、ページに用意されたページ送りや全体ビューの機能を使ってスライド全体を確認します。また、ページに示されたキーボードの矢印キーによるページ送りを試し、正常に機能することを確認します。

第4ラウンド：エクスポート納品とページごとの検収

HTML の確認が完了したら、Agent に組み込みのエクスポートツールチェーンを呼び出させ、正式な納品ファイルを生成させます。

エクスポートの指示を送信します。

タスク指示：
スライド全体の確認が完了しました。エクスポートとデザインチェックを実行してください：
1. 確認済みの huashu-design インストールルートから PDF エクスポートスクリプトを呼び出し、現在のプロジェクト向けにテキスト検索可能な PDF を生成してください；
2. 現在の HTML 構造に応じて適切な PPTX エクスポートルートを選択してください。ページ全体を1枚のスクリーンショットにするのではなく、テキストが編集可能な状態を目指してください；
3. インストールルートから design_lint.py を呼び出し、フォントサイズ、コントラスト比、画像リンク切れ、コンソールエラーを検査してください。また、各ページのスクリーンショットで文字欠けや要素の重なりがないか別途確認し、PPTX のテキスト照合結果および未合格の項目を報告してください。

Task:
The slides have been verified in browser. Please proceed with export and linting:
1. Call the PDF export script from the confirmed huashu-design installation root for this project;
2. Choose the PPTX export route suited to the current HTML, aiming for editable text rather than a full-page screenshot;
3. Run design_lint.py from the installation root for typography, contrast, broken images and console errors. Separately inspect slide screenshots for clipping and overlap, and report PPTX text comparisons and any failed checks.

このラウンドで得られるべき結果：同名の .pdf と .pptx ファイルが生成されます。リポジトリでは HTML の構造に応じてエクスポートの手法が分かれています。エクスポートの制約に沿って書かれた Deck には export_deck_pptx.mjs が利用でき、既存のビジュアル HTML の場合はブラウザのレンダリング結果からテキストと座標を抽出する pptx_from_rendered.py が使用されることがあります。Agent にどちらのルートを使用したかと、テキストの照合結果を報告させてください。照合をパスした後も、必ず実際のプレゼンテーションソフトで開き、文字編集が可能かどうか、およびレイアウト崩れがないかを自ら確認してください。

4. Webページ、Appプロトタイプ、アニメーション、インフォグラフィックの実践的な違い

共通のワークフロー（3方向ゲートと要件のすり合わせ）はすべてのタスクで有効ですが、異なるメディアを扱う場合、それぞれのモジュールに特有の入力仕様と技術的な境界が存在します。

A. Webページとプロフィールページ（写真からの配色抽出とブランド仕様）

作者のデモ（06:39–10:43）では、プロフィールページを作成する際、既存のテンプレートを当てはめるのではなく、ユーザーが提示した実際の写真やブランド資料から固有のカラーシステムを抽出しています。

• 入力の要件：気に入ったポスター、店舗の実写写真、またはブランドのロゴファイルをプロジェクトディレクトリに配置し（例：assets/sample.jpg）、Agent に対してメインカラーとサブカラーを抽出して brand-spec.md に固定化するよう明示的に指示します。実際のプロフィールや SNS アカウントを提供し、Agent に経歴やメディア掲載実績、名言などを捏造させないでください。
• コピー可能な初期指示（本文のデモに基づき整理）：

  タスク指示：
  プロフィールと実績をまとめたランディングページを作成したいです。提供する参考写真 assets/sample.jpg を読み込み、スクリプトで分析して代表的なカラー値を抽出し、brand-spec.md に書き出してデザイン仕様として固定してください。その後、3方向ゲートに沿って3種類のレイアウト初稿を提示してください。内容は提供されたプロジェクトと SNS リンクを忠実に表示し、提供されていない肩書き等を捏造しないでください。
  

• 追加入力・微調整の指示：

  タスク指示：
  3案の中から Direction 2 を選択します。ファーストビューのメインビジュアルの抽象的なプレースホルダーを、提供した実際の肖像写真 avatar.jpg に差し替えてください。また、モバイル表示（幅375px）でナビゲーションバーと本文のフォントサイズを確認し、本文が 16px 未満にならないようにしてください。
  

Initial prompt:
I want to build a personal profile and portfolio landing page. Please inspect my reference image assets/sample.jpg, extract its dominant and accent color values into brand-spec.md as CSS variables, and follow the Three Directions Gate to present 3 distinct layout concepts. Display my actual projects and links honestly; do not fabricate credentials or quotes.

Follow-up prompt:
I choose Direction 2. Replace the abstract hero placeholder with my actual photo avatar.jpg. Check the navigation and typography on mobile (375px viewport) to ensure body text is >= 16px.

B. モバイル App プロトタイプ（4画面のインタラクションを実際に機能させる）

作者のデモ（10:43–12:47）では、『完訳 7つの習慣』の考え方に基づくタスク管理 App のプロトタイプが紹介されています。

• 操作のポイント：Skill パッケージの assets/ios_frame.jsx デバイスフレームを Agent に再利用させ、コアとなる画面を展示ボードとして構成させることができます。展示ボードは全体を俯瞰するのに便利ですが、ハンズオンでは「タスクの新規作成」「モーダルの開閉」「完了のチェック」「ホームへの復帰」といった主要な操作が実際にクリックして機能するように作り込む必要があります。整った4画面のスクリーンショットが存在するだけでは、これらのフローが実装されていることの証明にはなりません。
• 4画面演習用のコピー可能プロンプト（本演習向けに実際のタスクから整理）：

  タスク指示：
  【本演習課題】時間管理のマトリックス（アイゼンハワーマトリックス）に基づく iOS App の高精度なインタラクティブプロトタイプを作成してください。要件：
  1. assets/ios_frame.jsx が提供する iPhone 15 Pro 標準デバイスフレームを使用し、ダイナミックアイランドやステータスバーを手作業で自作しないでください；
  2. 4つの主要画面を並べて展示ボードの構図を作成してください：①「本日の4象限」ホーム、②「新規タスク作成」モーダル、③「タスク詳細と影響の輪分析」ページ、④「完了アーカイブと週間振り返り」ページ；
  3. クリック操作可能な4画面プロトタイプを提供してください：タブ切り替え、モーダルの開閉、完了チェックに対応し、画面間の明確な「戻る」動線を用意してください；
  4. 画面内のデータには4象限のロジックに合致した質の高いサンプルデータを使用し、これがフロントエンドのインタラクションデモであり、本番のバックエンドデータベースとは連携していないことを明記してください。
  

Task:
[Practice Exercise] Please create a high-fidelity interactive iOS app prototype for Eisenhower Matrix task management:
1. Bind strictly to assets/ios_frame.jsx for the standard iPhone 15 Pro bezel; do not handwrite dynamic islands or status bars;
2. Lay out 4 core screens on a composed presentation board: ① Matrix Dashboard Home, ② New Task Modal, ③ Task Detail & Circle of Influence, ④ Archive & Weekly Review;
3. Make the four-screen prototype clickable, including tab switching, modal toggles and task completion, with clear back-navigation routes;
4. Populate with realistic task data, explicitly marking this as an interactive front-end demo rather than a production backend system.

C. プロモーションおよびコンセプトショートアニメーション（実在アセットの確認とタイムライン）

作者のデモ（12:47）では、ビリビリ（bilibili）が発表した AI 動画ツール「花生（Huasheng）」向けに制作された、15〜20秒・16:9 の横長プロモーションアニメーションが紹介されています。

• 操作のポイント：モーションデザインは、静的なスライドの文字を1行ずつフェードイン（Fade-up）させることではありません。制作前に、Agent はまず WebSearch を通じて製品の存在を確認し、公式ロゴとグラデーションカラーを取得しなければなりません。また、3方向ゲートの段階で、レンダリング済みのキーフレームボードと絵コンテカードを提出し、承認を得てからコードの記述に進む必要があります。
• 環境と性能に関する注意点：MP4/GIF へのエクスポート、BGM やナレーション音声の合成は、ローカルのホスト環境に Node.js、Playwright、および ffmpeg が正しく構成されているかに強く依存します。まずはブラウザ上で HTML アニメーションを確認できますが、不足しているエクスポート用の依存関係は別途整える必要があります。ベースとなる 25fps の動画から派生した 60fps はフレーム複製や補間が使われている場合があり、フレーム単位で seek する真の 60fps ルートも存在します。ファイルが「60fps」と表示されていても、それ単体で動きのディテールがより豊かであることの証明にはなりません。非公式のプロモーション素材には、権利関係の帰属を正しく記載してください。
• コピー可能な初期指示（本文のデモに基づき整理）：

  タスク指示：
  「花生 AI」という動画生成ツール向けに、15〜20秒、16:9 比率の非公式プロダクトプロモーションショートアニメーションを作成したいです：
  1. まず Web 検索を通じて当該製品の公式ロゴ、主要なビジュアルトーン、主な機能を検証してください；
  2. 3方向ゲートの要件に従い、キーフレームの静止画スクリーンショットとカラーパレットを含む方向性ボードを提示し、簡潔な絵コンテを添えて私の選択を仰いでください；
  3. 方向性が決定したら、タイムライン駆動による連続したストーリー展開を構築し、「プロンプト入力からワンクリックでの動画完成」へと至る動的な変化プロセスを際立たせてください。単なるスライドの切り替えにはしないでください；
  4. ラストカットの右下に「Created by Huashu-Design · 非公式ファンメイド」の透かしを正しく残してください。
  

Task:
I want to produce a 15-20 second, 16:9 ratio unofficial motion promo for a video AI tool named "Huasheng AI":
1. First verify the official brand logo, color gradient, and key feature list via WebSearch;
2. Comply with the Three Directions Gate: present motion moodboards with rendered keyframe screenshots and a light storyboard first;
3. Once approved, build a timeline-driven continuous narrative highlighting the "prompt to final video" transformation, avoiding slide-like fade-up cuts;
4. Keep the "Created by Huashu-Design · Unofficial Tribute" watermark at the bottom right of the outro.

D. インフォグラフィックと縦長データビジュアライゼーション（データの真正性とフォントサイズ換算）

データビジュアライゼーションや科学解説のインフォグラフィックにおいて、核心となる原則は「データこそが画面の主役であり、単なるレイアウトの装飾ではない」ということです。

• 入力の要件：確かなデータソースと閲覧環境を提供します（例：モバイル向けの幅 1080px の縦長画像、または記事内に埋め込む横長グラフなど）。数値の関係性に応じて表現形式を決定します（比率関係は面積、経時変化は連続曲線、多次元比較は対比グリッド）。デモで示されている大規模言語モデルのベンチマークスコア等の数値はレイアウトの例示にすぎず、現在の客観的な性能評価を表すものではありません。
• スマートフォン上の最終サイズでフォントサイズを確認する：リポジトリが提示する幅 1080px の縦長キャンバスの基準は、本文 ≥36px、ラベル ≥28px です。しかし、画像全体が幅 390px のスマートフォン画面に縮小されると、それぞれ約 13px と 10px 程度となり、快適に読める保証はありません。エクスポート後は実際の表示幅で確認し、注記が小さすぎる場合はフォントサイズを拡大するか画像を分割するなど、大画面キャンバス上だけの確認で済ませないようにしてください。

5. 部分調整、Tweaks によるパラメータ調整、5次元レビュー

初稿が完成した後、どのように細部を修正し納品物を検証するかが、最終的な作品のクオリティを左右します。

部分的な修正と確定済みスタイルの維持

全体のデザインに満足しており、特定の文言や余白だけを微調整したい場合は、Agent に対して「指定した領域のみを修正し、確定済みのカラー変数、フォント、およびその他のコンポーネントは厳格に維持すること」を明確に伝える必要があります。これを行わないと、Agent が全体のリデザインと誤解し、すでに承認されたレイアウトを書き直してしまう恐れがあります。

Tweaks を用いたリアルタイムなパラメータ調整

Agent に指示して HTML に Tweaks パネルを追加させ、スライダーやセレクトボックスを使ってデザインに影響を与える主要なパラメータ（色、フォントサイズ、密度、レイアウトなど）をインタラクティブに調整できます。どのようなコントロールを用意するかは作品に応じて決定されるため、すべての成果物に一律で4つのスイッチが付くわけではありません。

ページ内の調整ボタンを開き、効果を確認しながら変更します。もし実装に localStorage が使われている場合、設定は現在のブラウザに保存されますが、HTML ソースファイルに自動で書き戻されるわけではないため、別のブラウザに切り替えたり他人にファイルを送信した場合には保持されないことがあります。値が決まったら、次の一文を送信します。

タスク指示：
現在私が選択している色、フォントサイズ、レイアウトを HTML のデフォルト値として固定化し、納品ファイルを再エクスポートしてください。その後、ローカル設定をクリアするか別のブラウザで開き、表示がこのバージョンのままであることを確認してください。これらのパラメータのみを変更し、確定した方向性やその他の内容は維持してください。

5次元エキスパートレビューの利用限界

対話の中で「このデザインに対して5次元レビューを実行して」と入力すると、Agent は組み込みの規範に基づいてページを採点します。

重要な認識：5次元レビュー（デザイン哲学の一貫性、視覚的階層、ディテールへの配慮、機能性、革新性）で出力される 0〜10 点のスコアやレーダーチャートは、本質的にモデルがあらかじめ設定されたルールに沿って生成したヒューリスティックな評価にすぎず、客観的なデザインの審美スコアと見なしてはなりません。その本質的な価値は、具体的な Keep / Fix / Quick Wins の修正リストを出力させ、コントラスト不足や余白の不均衡といった構造的欠陥を発見することにあります。モデルの高評価や提案があなた自身の直感と衝突した場合は、常に自分自身の直感を優先してください。

最終納品のチェックリスト

他者への正式な納品や素材の公開を行う前に、以下の基準に沿って1項目ずつ照合を行ってください。

1. HTML プロトタイプ：デスクトップおよびモバイルのブラウザで実際に開き、すべてのタブ、ボタン、展開レイヤーを実際にクリックし、F12キーで開発者ツールを開いてコンソール（Console）に赤字のエラーが出ていないことを確認する；
2. PDF プレゼンテーションファイル：各ページをチェックし、端のテキストが切れて消失していないか、マウスでテキストを選択してコピーや検索ができるかを確認する；
3. PPTX プレゼンテーション：実際の PowerPoint、WPS Office、または Keynote で開き、各ページのテキストボックスをダブルクリックして、ページ全体が固定された1枚の画像ではなく、文字が自由に編集・改行・修正できることを確認する；
4. 動画とアニメーション：最初から最後まで完全に再生し、映像の冒頭や末尾にちらつく黒画面や白画面がないか、BGM や効果音（SFX）が正常に出力されているかを確認する；
5. レスポンシブな幅：ブラウザの開発者ツールでスマートフォンの幅（375px）に切り替え、横スクロールバーの発生やテキストのオーバーフロー・レイアウト崩れがないかを確認する。

6. よくある問題のトラブルシューティングと修正指示

問題が発生した際は、単に「動かない」と伝えるのではなく、実際のエラーログやスクリーンショットを Agent に送るようにしてください。

デザインチェック用スクリプトで playwright や pillow が見つからない。 スクリプトの実行に使用している Python 環境を Agent に確認させ、同一環境内に不足している依存パッケージやブラウザをインストールさせた上で再実行してください。すぐに環境を補えない場合は、実際のブラウザでのスクリーンショットとクリックによる確認を行い、納品物には「自動デザインチェック未実行」と明記してください（パスしたことにしてはなりません）。

6つの候補サムネイルや3つの代表ページが出力されない。 まずインストールディレクトリが完全であるか、現在のセッションが Skill を読み込んでいるかを確認し、その上で次のように送信してください：「インストール済みの huashu-design 仕様を読み込み、まず6枠の候補サムネイルと異なる3つの方向性の代表ページを提示してください。提示後は一度処理を停止し、私の選択を待ってから後続の作業に進んでください。」モデルが手順を守らなかった場合、単なる指示実行の失敗である可能性もあるため、結果だけでインストールが壊れていると決めつけないようにしてください。

PPTX をダブルクリックしても画像1枚しか選択できない。 次のように送信してください：「現在の HTML が Skill パッケージ内のどの PPTX エクスポートルートに適しているか確認し、確認済みのインストールルートから該当スクリプトを呼び出して実際のテキストボックスを保持してください。テキストの照合結果を報告し、プレゼンテーションソフトで開いて編集可能であることを確認してください。」

HTML を別の場所へ移動すると画像が表示されなくなる。 画像がプロジェクト内の相対パスや一時リンクになっていないかを確認し、次のように指示してください：「納品に必要な素材を一緒にパッケージ化するか、適切な場合は単一の HTML に埋め込んでください。納品ファイルを新しいディレクトリにコピーした上で再度開き、画像やリンクが正常に表示されるか確認してください。」

7. モジュール化の進展、不具合の修正、オープンソースライセンスについて

リリースノートでは、エンジニアリング面での2つの改善についても触れられています。SKILL.md を593行から215行へとスリム化し、メディアごとの説明をサブモジュールへと分割したこと、および PPTX エクスポート時に生のテキストが脱落する不具合（#56）を修正し、エクスポート後のテキスト照合を追加したことです。これらの改修はルールとチェック結果の整理に寄与していますが、毎回の生成やエクスポートの完全な正確性を保証するものではありません。

現在のリポジトリには MIT ライセンス が適用されており、個人利用および商用プロジェクトの双方で利用可能です。ただし、モデルの API 利用料、ホスト Agent、または外部サービスは各サービスの料金体系に従って課金されるほか、制作物に使用されたサードパーティの画像、フォント、ブランド素材については各自でライセンスを確認する必要があります。huashu-design は主にビジュアル案やクリック可能なプロトタイプの制作を支援するものであり、ユーザー認証、データベース、運用保守を伴う本格的なプロダクトには、別途エンジニアリングの実装が必要です。

最初の演習から正式な納品に至るまで、最も大切にすべき習慣は「まず目に見える具体的な提案を確認し、どの案を採用するかを明確に選ぶこと。修正後は再度開き、エクスポート後は目的のソフトウェアで直接確認すること」です。そうして初めて、多様なデザインの選択肢が、実際に業務で役立つ成果物へと結実します。