site-motion：サイト動態評価とバージョン選択は何をしますか？

ユーザーがウェブサイトを「静的だ」と言うとき、問題は大抵アニメーション不足でも読み込み速度でもなく、すべての操作がページ遷移を伴い、コンテンツがバラバラのブロックに見えることです。まず問題を特定し、それから何を動かすかを決めます。

ユーザーの言語で返答してください。技術用語は原文のままにします。

原則

選定前に本番コードを変更しない：まず診断、提案、プロトタイプを提示し、ユーザーがバージョンを明確に選択した後にのみ実装します。
デフォルトでレイアウトは変更しない：明確な要求がなければ、配色、フォント、レイアウトは変更せず、インタラクションのみを変更します。サイト全体のスタイル変更は別の話です。
モバイルファースト：375pxを基準に判断・検証し、デスクトップは付随的なものとします。
アニメーションはクリック可能でなければ意味がない：静止画では操作感がわかりません。各バージョンは実際に操作できるプロトタイプにします。
アニメーションには目的が必要：すべての動きは、「押したかどうか」「どこから来たのか」「データが更新されたか」など、ユーザーのどの質問に答えているかを説明できなければなりません。答えられないものは削除します。
検索と広告で収益を得ているサイトでは、SEOと収益化がスタントより優先：アニメーションによって、個別のURL、ファーストビューのHTMLコンテンツ、広告の可視性を損なってはいけません。ログイン後の管理画面や社内ツールはこの制限の対象外です。
コンテンツを変更する場合は実際にページ遷移し、同じコンテンツを調整する場合のみその場で：別の記事を見るには新しいページが必要です。新しいURLと広告リクエストをもたらすからです。展開、フィルタリング、ソートはその場で行います。
アニメーションはサイトの制約を超えてはならない：まずプロジェクトの規約と法令遵守の制限を確認します。欠損値のあるフィールドを視覚表現に使ったり、根拠のない情報をアニメーションで示唆したりしません。

フロー

ステップ 1：ユーザーが求める動きの種類を判断する

「動き」には4つの種類があり、解決策は全く異なります。

種類	典型的な発言	実際に行うこと
データの動的更新	コンテンツが自動更新されるべき、リアルタイムが必要	cron、API、ポーリング。主にバックエンドの作業で、更新シグナルを組み合わせる
フィードバック	押しても反応がない、静的すぎる	押下感、状態変化、更新フラッシュ
連続的な動き	ページ遷移がバラバラ、原始的、オブジェクトの集まりのよう	ページトランジション、その場での展開、共有要素、ジェスチャー
ストーリーテリングアニメーション	トップページにインパクトが欲しい、スクロールエフェクト、GSAP	ヒーローアニメーション、スクロールストーリー、ブランドモーメント

明らかにデータの動的更新に該当する場合は、これはアニメーションの問題ではないと説明し、データソリューションに移行します。それ以外の場合は、逆質問をせずにステップ2に進み、実際の観察に基づいて回答します。

ステップ 2：現状を確認する

プロジェクトのソースコードにアクセスできる場合は、このスキルのルートディレクトリから以下を実行します：

python3 scripts/motion_audit.py <プロジェクトディレクトリ>

スクリプトの結果は手がかりであり、決定ではありません。ヒットした項目は一つずつ確認します。

ブラウザを開ける場合は、375pxで主要なパスを一通り確認します：トップページ、詳細ページ、タブの切り替え、リスト項目のクリック、前のページに戻る。実際の感覚を記録します：

どの操作がページ全体のリロードで、どの操作がその場での変化か
ページが一つのまとまりとして見えるか、それともバラバラなブロックの集まりか
データが更新されたとき、ユーザーにそれがわかるか
フィードバックに遅延はないか、アニメーションが逆効果になっていないか（例：ページに入るたびに数字が跳ねる）

ウェブサイトがない場合（新規サイト）、またはプロジェクトが空で実際のページがない場合：企画書を読み、サイトの種類を判断し、ステップ3に進みます。現時点では実際の画面を診断できないことを説明します。

ウェブサイトもコードも見られない場合：ユーザーから提供された情報をもとに進めます。「問題の所在」はすべて推測であることを明記し、「未検証」として不足しているデータをリストします。観察事項を捏造してはいけません。

ステップ 3：サイトの種類に応じて方向性を決める

サイトの種類	重点	避けるべきこと
データ・ツール系サイト（スコア、検索、ダッシュボード）	連続的な動き、更新シグナル、密度	スクロールフェードイン、データを遮るアニメーション
コンテンツ・記事系サイト	軽いフィードバック、読書の中断なし	読書や広告の押し出しを妨げるアニメーション
ブランド・マーケティングページ	一つの洗練されたストーリーテリングの瞬間	あちこちで動かす
App型サービス	ジェスチャー、その場での操作、状態の連続性	見た目だけ変えてインタラクションは変えない
ログイン後の管理画面・社内ツール	フィードバック、状態変化、ページ遷移の削減	繰り返し操作を遅くするアニメーション

ステップ 4：2～3のバージョンを計画する

references/recipes.md を読んでモーションレシピを取得し、references/pitfalls.md を読んでリスクを評価します。

まずナビゲーションゲートを確認します。これにより、どのようなページ遷移方式を提案に含められるかが決まります：

サイトの状況	ナビゲーション方式
現在または今後、広告（AdSenseなど）を表示する予定がある	デフォルトでクロスドキュメント `@view-transition` を使用し、実際のページ遷移を維持。広告と分析の動作は変更しない
自動広告、アンカー広告、インタースティシャル広告が有効、または遷移後の広告動作を検証できない	同一ドキュメントのソフトナビゲーションは推奨しない。記載する場合は、事前に実際にテストする必要があること、およびフォールバックを明記する
広告がない、または広告と分析の動作が検証済み	同一ドキュメントのソフトナビゲーションやフレームワークルーティングを使用可能。ただし、ページ遷移後の分析とログイン状態が正常であることを確認する必要がある

既存サイトでソフトナビゲーションが有効で、広告を掲載予定の場合は、その点を「問題の所在」に記載し、解決済みとして扱わないでください。

バージョン間には実質的な違いが必要で、インタラクションの範囲の違いであり、色の違いではありません。段階はサイトの現状から積み上げ、すでに実装済みの項目は重複してリストしません。デフォルトの段階：

A 軽量フィール版：ナビゲーション構造を変更せず、フィードバックと更新シグナルのみを追加。リスク最小、当日完了可能。
B 連続版：Aに加えて、ページトランジション、共有要素、その場での展開を追加。ナビゲーション方式はゲートに従う。通常は推奨版。
C フルApp感版：Bに加えて、スワイプジェスチャー、その場でのデータ切り替え、リアルタイム通知、またはブランドサイトのストーリーテリングモーメントを追加。最も操作感が強く、コストとリスクが最も高い。

バージョンはステップ3のサイトタイプフィルターを通過する必要があります：記事コンテンツサイトは通常Aか軽量Bで止まります。2つのバージョンにしか実質的な差がない場合は2つだけ提供し、無理に数を揃えないでください。Aがすでに要件をすべて満たしている場合も、その旨を明言します。アニメーション開発コストはサイトの収益に見合ったものでなければなりません。

ステップ 5：クリック可能なプロトタイプを作成する

references/prototype.md に従います。プロトタイプは実際のデータと既存の外観を使用し、1つのファイル内でバージョンを切り替えられるようにし、モバイル幅で実際にクリックしてから提供します。開始点として assets/prototype-template.html を使用できます。

ステップ 6：提案

以下の「出力フォーマット」に従って報告し、ユーザーにバージョンを選択してもらいます。環境に選択ツールがあればそれを使用し、なければ番号付きの選択肢をリストし、推奨版を最初に配置します。ステップ1の「逆質問しない」は診断段階にのみ適用されます。ここでは停止して選択を待ちます。

ステップ 7：実装と検収

ユーザーが選択した後にのみ開始します。references/acceptance.md の順序に従って実装し、検収を完了します。他のエージェントに引き継ぐ場合は、そのファイルの引き継ぎテンプレートを使用します。

出力フォーマット

提案は常に以下の構造で、簡潔かつ具体的にします：

## 動態評価：<サイト名>

**問題の所在**
<2～4項目。それぞれ観察された現象で、ページの位置を添える。「インタラクション不足」のような漠然とした表現は避ける。>

**バージョン比較**
| | A 軽量フィール | B 連続 | C フルApp感 |
|---|---|---|---|
| ユーザーが感じること | | | |
| 主な変更点 | | | |
| 作業量 | ファイル数とおおよその時間 | | |
| SEO・CWVリスク | 低／中／高、理由を一言 | | |
| 広告・分析への影響 | ナビゲーション方式と前提を明記 | | |
| 保守コスト | | | |

**推奨**：<どれを選ぶか、理由を一言。前提があれば前提も記載>

**プロトタイプ**：<リンクまたはパス。試すべき3～5のアクションをリスト>

**レイアウト変更**：<ユーザーの同意が必要な項目。なければ「なし」>

**提案しないこと**：<ユーザーが要求したが、今回行わない項目とその理由。なければ省略>

**変更しないもの**：<レイアウト、配色、URL、SEOの制約など>

**未検証**：<実際にはテストしていない項目。例：広告の実際の動作、実機での操作感>

2つのバージョンしか提供しない場合は、不要な列を削除したテーブルにします。作業量は「4～5ファイルを変更」のような具体的な数字を書き、リスクは「低」とだけ書かずに理由を明確にします。数字が実測か推定かを明記します。ユーザーの要求が条件でブロックされた場合は、どこでブロックされ、どのような条件で再検討できるかを直接説明し、代替案を提示します。推奨版は、ゲートとパフォーマンス条件を基準にし、必ずしもBである必要はありません。

参考ファイル

ファイル	いつ読むか
references/recipes.md	ステップ4、モーションとパラメータを選ぶとき
references/pitfalls.md	ステップ4のリスク評価、ステップ7の実装時
references/prototype.md	ステップ5
references/acceptance.md	ステップ7、引き継ぎテンプレートを含む
assets/prototype-template.html	プロトタイプ作成の開始テンプレート

site-motion：サイト動態評価とバージョン選択