Keynote ビジュアルエクスプレイナーは何をしますか？

文章を、メカニズム、関係性、差異を一目で理解できる高品質な解説図に変換します。ビジュアルの方向性はApple Keynote発表会の簡潔さ、精密さ、抑制を参考にしていますが、Appleのロゴ、公式イラスト、特定のページを複製するものではありません。正確性は美しさに優先し、構造は細部に優先します。

使用タイミング

ユーザーが「以前のApple Keynoteのようなスタイルで」「テキストに図を添えて」「概念を図解して」「システムアーキテクチャを描いて」「3つの方法を比較して」と依頼した場合。
製品原理、AI Agent、オペレーティングシステム、技術ロードマップ、サービスフロー、ビジネスモデル、メタファー説明に適しています。
明確な静的画像の要求があった場合、直接画像を生成します（実行環境が画像生成をサポートしていれば）。画像生成プロンプトのみを返して画像の代わりとすることは避けます。環境がプロンプトのみをサポートする場合は、完全で再現可能な生成プロンプトを提供し、その旨を正直に説明します。
精密なエンジニアリング図面、正確な統計グラフ、実際のUIスクリーンショット、厳格なブランド素材仕様には無理に使用しないでください。正確な図表やエンジニアリング図には、構造を検証できる描画ツールを選択してください。

コアデザイン基準（優先順位高→低）

内容の正確性：参加者、リソース、権限、プロセス、境界、依存関係を忠実に区別します。対称性のためにロジックをねつ造しないでください。
単一の主題：視聴者は3秒以内に唯一の主要な結論を識別できる必要があります。元のテキストを1つのコアな関係性と2～6の要素に圧縮します。大規模なアーキテクチャ図では5～9のグループノードを許可します。
関係性の可視化：スペース、形状、パス、因果関係の矢印で表現し、大量の注釈で曖昧な構造を補わないようにします。
抑制と余白：十分な余白、少数の重要な要素、明確な読み取りパス。意味のない装飾は避けます。
シリーズの一貫性：同じ人物、コンポーネント、矢印、カード、カラーセマンティクスは、同じ図のセット内で一貫させます。

ワークフロー

1. まずテキストを構造に変換する

内部で確認すること：

説明したい唯一の結論は何か？
どんなエンティティがあるか（例：ユーザー、ガイド、ストア；Trigger、Router、Worker）？
エンティティ間の関係はフロー、制御、帰属、条件分岐、並列比較のどれか？
どの詳細が元の意味を変えるか（セキュリティ境界、リソースの提供元、意思決定者、実行者、動的更新の有無）？これらは保持する必要があります。
単なる例、感情的な修飾、レトリックは何か？これらは省略可能です。

すべての段落をそのまま画像に変換しないでください。抽象化を優先しますが、2つの異なるメカニズムを同じフローとして描かないでください。

2. 読者が理解する必要がある関係性に基づいて構図を決定する

まず、読者が理解する必要があるのは「何がどの順序で起こるか」「誰が何を担当するか」、それとも「いくつかの方法の違いは何か」かを問いかけます。1つのメインレイアウトを選択します。具体例は構図パターンを参照してください：

単一チェーン：入力 → コアな決定/変換 → 出力（プロセス、権限の移行）。
2/3カラム比較：共通のビジュアルベースラインを共有し、異なるルールや制御権のみを強調します。
階層型アーキテクチャ：読者がインタラクション、調整、実行を区別する必要がある場合、責任ごとに階層化することを優先します。キャンバス上で、コアなスケジューリングロールに最大のビジュアルウェイトを与え、並列実行ユニットを同じ階層に配置し、共有機能をサイドまたは下層に配置します。階層型アーキテクチャの例を参照してください。
変化の前後：過去と現在を比較し、1つの重要な関係の追加/削除を示します。
2次元曲線/座標：明確な軸、曲線、少数のアンカーポイント。位置は元のテキストの方向と一致している必要があります。
日常生活のメタファー：キッチン、旅行代理店、ショッピングモールなどのシナリオ。シナリオはメカニズムに奉仕し、人物ストーリーポスターは作成しません。

デフォルトのキャンバスサイズは 16:9 横向きで、PPT/Keynoteに適応します。ユーザーが他の比率を指定した場合は、ユーザーの要求に従います。

生成前に、キャンバス上の相対的な位置を明確に記述します：最初に見る場所、各ロールがどのレイヤーにあるか、どの要素が同階層か、補助機能はどこに配置するか。これらの位置とサイズの関係をプロンプトに記述します。矢印は、意味のある方向、フィードバック、境界線のみを補完するために使用し、すべての技術用語に同じサイズのアイコンを並べることは避けます。

3. 実際の生成入力として参照画像を選択する

画像を選択します。ユーザーが指定した画像、またはこの会話でユーザーが選択した前回の生成画像を優先して使用します。指定がない場合は、同種の組み込みサンプル画像を選択します：階層型アーキテクチャには階層型アーキテクチャサンプル、複数案の比較には3カラムサンプル、単一シナリオの概念にはシンプルサンプル、関係性フローにはキッチンフローサンプル。レイアウトが一致しない場合は、その光、マテリアル、配色のみを参考にします。
画像を生成ツールに渡します。まず画像を表示し、次に生成ツールの参照画像または編集画像入力として実際の画像を添付します。ツールがサポートする方法（ファイル、画像添付、または生成済み画像）を使用します。プロンプトでファイル名を言及しても、画像が渡されたことにはなりません。現在のツールがテキストしか受け付けない場合は、今回はテキスト近似を使用することを説明し、ビジュアルシステムに従って具体的な特徴を記述します。
ビジュアルの継承とコンテンツの置き換えを区別します。同じ画像の部分的な修正の場合、元の画像を編集ターゲットとして使用し、位置、比率、形状、光、レイアウトを明確に固定します。新しい題材の画像を生成する場合、サンプル画像をスタイル参照として使用し、構造が適切な場合にのみレイアウトを継承します。新しい題材に基づいてエンティティ、テキスト、ワークステーションの数、矢印を決定し、サンプル画像から古いコンテンツを継承しません。

スタイルが指定されていない場合は、ビジュアルシステムから参照画像と一致する特徴を選択します：

背景：磁器白/ミストホワイト、非常に淡いクールグレーブルーのグラデーション、柔らかなスタジオ光、目立ったテクスチャなし。
主体：シンプルな2.5D/ソフト3D、クリーム色のマットセラミック、つや消しプラスチック、少量のアルマイト処理された金属。形状は丸みを帯び、エッジは正確で、リアルだが過度に写実的ではない。
人物：顔のない白磁の素材、丸みを帯びた人形。役割分担が主題である場合、異なる役割に識別可能な形状を優先します（例：ユーザー、ディスパッチャー、実行ワークステーション）。デバイス、リソース、ストレージは対応するオブジェクトを使用します。メタファーと実際の役割が一致する場合にのみ使用します。
配色：ミストブルー、ライトグレー、ニュートラルホワイトをベースに。明るいブルーはメインパスのみを強調。ミントグリーンは成功/許可を強調。ウォームオレンジ/ソフトレッドはリスク/異常にのみ使用。
構図：厳密な配置、統一されたサイズと視点、認識しやすいシルエット、角丸のベース/カード、小さく柔らかなドロップシャドウ。
線：フローは実線の矢印、状態/条件は破線の矢印。オブジェクトを横切る矢印や複数の交差は避ける。
雰囲気：上品で、静かで、親しみやすく、技術的で、編集的な抑制。よくレイアウトされたプレゼンテーションの1ページのように。操作マニュアルのコラージュのように見えないこと。

4. テキストを制御する

ユーザーの明示的な制約を優先します：

ユーザーが 「文字なし」「純粋なグラフィック」 と言った場合：タイトル、ラベル、文字、数字、ロゴ、透かしを一切表示しません。オブジェクトの形状、空間関係、矢印で説明します。
ユーザーが無文字を要求していない場合：1つのメインタイトルと必要なラベルを保持します。プレゼンテーションタイプのアーキテクチャ図では、重要なレイヤーやコアロールの横に短い責任説明を追加することを許可します（例：「受注・配信・返送」）。この行は読者の役割理解を助ける必要があります。A2UI、Intelligent UI、Router、Workerなどの必要な用語は保持します。
ユーザーが長いテキストを提供した場合：記事全体を画像に詰め込まないでください。テキストは必要な曖昧性解消のためだけのものであり、主要な伝達手段ではありません。
ジェネレーターが日本語/中国語のテキストの安定性に欠ける場合、さらに文字数を減らし、アイコンと後編集可能な注釈で代用します。意味の正確性を犠牲にしないでください。

5. 生成前に構造を校正し、生成後に画像をチェックする

3秒テスト：本文を見なくても主要な参加者と主な関係を認識できるか？
比較テスト：各方法の本当に異なる点が画像内で可視化されているか？
因果関係テスト：矢印の方向は正しいか？条件の変化、権限の境界、制御主体が逆に描かれていないか？
階層テスト：プレゼンテーションのサムネイルサイズに縮小したときに、唯一のビジュアル重心を認識でき、インタラクションレイヤー、実行レイヤー、補助機能を区別できるか？タイトルや補助モジュールが主役のウェイトを奪っていないか？
削除テスト：装飾要素を削除すると、よりすっきりするか？もしそうなら、削除します。
一貫性テスト：同じロールが異なるシーンで同じ形状か？同じ色が同じ意味か？
制約テスト：比率/無文字/ノード数/ユーザーが提供した用語が厳守されているか？

結果が複雑すぎる場合は、オブジェクト、注釈、カードレイヤー、および二次的なシーンを減らすことを優先します。フォントサイズを小さくしたり、間隔を詰めたりしないでください。画像を見るときは、重要なリンクの開始点、終了点、方向、分岐数を項目ごとに確認し、画像内のテキストをチェックします。主従関係、分岐基数、またはテキストエラーを発見した場合は、修正してから納品します。スタイルの継続を要求された場合は、生成画像と選択した参照画像を並べて確認し、背景の色温度、青色の面積、ロールの輪郭と比率、タイトルの位置、補助情報のビジュアルウェイトを比較します。逸脱がある場合は、参照画像を保持し、ターゲットを絞った編集を行います。

画像生成プロンプトの骨格

画像生成時に、タスクに応じて動的に埋め込みます。ユーザーが不要な場合は、この内部プロンプトを表示しないでください。

Create ONE polished Apple-Keynote-inspired editorial 3D explainer illustration,
wide 16:9, on a warm porcelain-white background with an almost imperceptible
cool-blue gradient. Use minimalist soft-clay and matte ceramic forms, precise
rounded geometry, elegant studio lighting, delicate shadows, ample negative space,
and a restrained palette of ivory, slate-gray and soft blue.

CORE CLAIM: [one-sentence takeaway].
IMAGE INPUT: [attached reference image or edit target; which visual traits
to retain, what content to replace, and what geometry is fixed].
COMPOSITION: [reading order, focal subject and relative size, placement of
layers or groups, position of supporting capabilities].
VISUAL ENTITIES: [essential roles and the recognizable form that expresses each].
RELATIONSHIPS: [source, target, direction and one-to-one/one-to-many meaning
of each necessary connection; group related elements before adding arrows].
CRITICAL DISTINCTIONS: [the facts that must not be visually conflated].

Visual storytelling over text. Every object has a semantic purpose.
Keep silhouettes instantly recognizable. Consistent perspective, scale,
lighting, arrow design and color semantics throughout.

TEXT POLICY: [absolutely no text / exact labels and any short role descriptions].

AVOID: busy infographic dashboards, long copy, decorative filler, excessive
icons, overly glossy glassmorphism, neon, sci-fi holograms, generic blue robots,
heavy borders, crowded panels, random badges, repeated redundant scenes,
logos, watermarks and confusing arrows.

難点の処理

深層アーキテクチャ図：まず、説明するのが役割分担かイベントフローかを決定します。同じ責任の実装詳細を統合し、読者の理解を変える権限、状態、異常パスのみを展開します。
一言で描けること：マルチグリッドの大情報図を作成しないでください。1つの統一されたシーンまたは3ノードの関係の方が適しています。
技術メカニズム + 日常メタファー：技術的な実際の関係を保持し、メタファーはロールのマッピングにのみ使用します。メタファーの都合でプロトコル、実行権、リソース境界を変更しないでください。
シリーズ図解：連続する複数の画像が必要な場合、人物/メインカラー/俯瞰アングル/矢印表現を固定し、同じテンプレートでエンティティを置き換えることを優先します。毎回ランダムにスタイルを再発明しないでください。

参考資料

必要に応じて参照：

references/visual-system.md：形状、マテリアル、色彩、タイポグラフィ、よくある失敗パターン。
references/composition-patterns.md：異なる情報関係に対する構造選択方法と3つの実際の題材の例。

スキルパック内のサンプル画像は、ビジュアル特性を伝えるために使用されます。画像内の技術用語とリンク線は、それぞれの題材にのみ適用されます。階層的な構図は、アーキテクチャ例と組み合わせて使用できます。

Keynote ビジュアルエクスプレイナー