モックアップは方向性を示せますが、製品仕様にはなりません

本文の実装やプロジェクトの状況は、原文が記録した 2026 年 10 月 2 日時点のスタジオ改修を指しています。現在の委託範囲はグラフィックデザイン、UI/UX、フロントエンド開発で、確認した範囲に応じて見積もります。詳しくはサービスページをご覧ください。

一枚のモックアップがあれば、ページの雰囲気、情報の階層、おおよその読む順序をすぐに共有できます。スタジオ改修の参考画像も、その役割を果たしました。ホーム、モバイル版ホーム、ノート一覧、記事ページ、製品紹介、協業の方向性について、考えられる構成をまず画面として並べたものです。

ただし、画像に見えている見出し、日付、カード、製品画面、サービス項目が、そのまま実在するコンテンツや機能になるわけではありません。これらは AI が生成した方向性を検討するための案であり、寸法を測るための設計稿でも、製品のスクリーンショットでも、正式な記事でも、機能の証明でもありません。私の判断は、モックアップは視覚的な方向性をそろえるために使い、コンテンツのデータ、製品機能、操作時の振る舞いに関する実装契約の代わりにしないというものです。

モックアップが先に答えるのは「画面をどう見せるか」です

モックアップは、次のような視覚上の問題を検討するのに向いています。

• 最初の画面に入るのはどの部分で、その先を読む入口はどこに置くか。
• 見出し、説明、ボタン、カード、画像のうち、どれに最初に目を向けてもらうか。
• デスクトップでは横に並べられる内容を、モバイルでは縦に読む形に変えるか。
• ノート、製品、協業、自己紹介が、それぞれ別のコンテンツ領域として見えるか。
• ページ全体でどのような雰囲気を保ち、どこに余白を設けるか。

こうした情報には価値があります。実装する側が、最初からすべての CSS の数値を固定せずに、「この方向で進めるか」を話し合えるからです。

一方、モックアップだけでは、次の問いには答えられません。

• 画像にある記事のタイトルは実在するのか、その日付は公開してよいのか。
• ボタンはどの URL に移動するのか、それとも見た目上の配置にすぎないのか。
• 製品画面に見える項目は実装済みなのか、サービス項目は実際に提供できるのか。
• その画面画像は実製品のスクリーンショットなのか、静的なイメージなのか、構図を伝えるだけのものなのか。
• キーボード操作、JavaScript の無効化、狭い画面、文字の拡大、読み込み失敗の際に、ページはどう振る舞うのか。

この二つの問いを混ぜると、画像がいつの間にか製品の判断を代行します。日付があるように見えるだけで公開済みと扱われ、機能があるように見えるだけで完成済みと扱われ、問い合わせフォームに見えるだけで実際に送信できると思われてしまいます。

一枚の画像には四種類の情報が混ざっています

モックアップを見るとき、私は細部をすべてコードに写すのではなく、見えている内容をまず四つの層に分けます。

画像に見える情報	検討に使えること	実装までに必要なもの
セクションと配置	ページの階層、読む順序、デスクトップとモバイルでのグループ分け	実際の DOM 順序、RWD のルール、そのセクションが実在するかどうか
サンプルの文言	文章の長さ、見出しの階層、カードの密度	正式な文言、出典、言語版、公開状態
画面イメージ	視覚的な焦点、製品とサイトの見せ方の比率	実際の素材、またはイメージであることの明示、alt、寸法、エラー状態
機能を示唆する表現	必要になりそうな入口や操作	ルート、要素のセマンティクス、データの取得元、状態、キーボード操作と JavaScript なしでの振る舞い

たとえば、ノート一覧のモックアップには、完成しているように見えるカードや分類ラベルをいくつも置けます。カードにトピックのタグ、要約、記事への入口が必要かを話し合う助けにはなりますが、その記事がすでに書かれている証拠にはなりません。枠を埋めるために架空の記事を追加する理由にもなりません。

製品モックアップにあるダッシュボード画面も同様です。製品のセクションに大きめの視覚的な焦点が必要だとは伝えられますが、いくつかのアカウント項目から完全なデータモデルを導くことはできません。イメージにある小さなアイコンを、一つ残らず約束済みの機能として扱うこともできません。

視覚的な方向性を実装契約に置き換えます

より確実なのは、残したい画面要素ごとに「製品の中で何を担うのか」を確認することです。

視覚要素	記録時点のページでの実装上の問い	確認できる根拠
ホームのノートカード	どの記事を読み、どう並べ、記事がない場合はどう表示するか	HomePage.astro は getPublishedNotes(lang) から最大三件を取得し、公開可能な記事がなければ空の状態を表示します
ノート一覧と分類	分類は実在するコンテンツ契約なのか、クリック後はどこへ移動するか	NotesPage.astro は公開可能な記事から一覧を作り、分類、featured、ページ分割、記事リンクは当時のデータとルートによって決まります
記事の目次	本文と同期しているか、モバイルではどう読むか	ArticleLayout.astro は実際にレンダリングされた heading から目次を作り、モバイルには Drawer と JavaScript なしで使う fallback もあります
製品画面	実際の screenshot なのか、コードで作ったイメージなのか、まだ取得していない素材なのか	ZeniDashboardPreview はコンポーネントが出力する静的な画面プレビューです。構図は伝えられますが、特定の実データの状態を証明するものではありません
協業の方向性を示す行	公開できる協業範囲はどこまでで、どこからが探索段階か	servicesCopy は協業の方向性と相談の出発点を示し、AI 導入コンサルティングは今後の方向性であることも明記しています
モバイルでの横並びセクション	狭くなった際の順序、折り返し、はみ出し、操作方法はどうなるか	共通の主要 DOM、内容が収まることを基準にした RWD ルール、実際の狭い画面とキーボードでの確認です

この変換を挟むと、「画像どおりに組む」作業は「各セクションの責任を先に確認する」作業になります。正式なデータになる要素もあれば、CSS や局所的なスクリプトの振る舞いになる要素もあります。生成画像が見た目を完成させるためだけに補った細部なら、そのまま削除したほうがよい場合もあります。

画面イメージは製品のスクリーンショットではありません

今回の改修には、「画面」という一つの呼び方で混同されやすいものが、少なくとも三種類ありました。

方向性を検討するための案です

方向性を検討する案は、全体の雰囲気、セクションの比率、情報の階層を話し合うためのものです。文字、アイコン、日付、画像、機能が最終版と同じになることは保証しません。改修仕様でも参考画像を AI が生成した方向性の案と明記しており、モデルが独自に追加した細部は実装要件になりません。

コードで生成する画面イメージです

サイトは Astro コンポーネントと CSS で静的な画面イメージを作れます。そのため、一枚の生成画像に依存する必要はありません。たとえば、記録時点の協業ページにある ServicePreview.astro は、方向性ごとに簡略化したパネル、文字を表す線、カードを生成し、「画面イメージ」と表示していました。この領域自体は装飾用の aria-hidden プレビューであり、操作できるサービスシステムではありません。

ホームと製品ページで使う ZeniDashboardPreview も、コードで組み立てた展示用の画面です。製品領域の視覚的な比率や内容の方向性を説明する助けにはなりますが、実際のアカウントのある時点を撮った screenshot と説明するべきではありません。

実際のスクリーンショットです

実際のスクリーンショットは、実在するページや製品の状態から取得し、公開してよい内容を別途確認する必要があります。少なくとも、どのバージョン、ルート、状態を撮ったのか、画像内のデータが匿名化されているのかを説明できるべきです。静的なイメージでしかないなら「画面イメージ」と明示し、screenshot という言葉で実際にはない信頼性を与えないようにします。

この区別は、画像の実装上の扱いにも関わります。公開する実画像には適切な alt、寸法、lazy loading、読み込み失敗時の状態が必要です。純粋に装飾用のイメージは、支援技術に操作可能なデータの集まりだと誤認させないようにします。

食い違うときは、画像の雰囲気より実際の契約を優先します

当時の改修仕様では、最新の明確なフィードバックをコンテンツと振る舞いの契約より優先し、その契約を確認済みの元画像と文言より優先し、モックアップの雰囲気は最後に置いていました。これは視覚表現の否定ではありません。議論を経ないまま、一枚の画像に決定権を与えないためです。

原文が記録した実装には、具体例がいくつかあります。

• 画像の枚数に合わせてノートカードを複製しません。 ホームはその言語で公開できる記事だけを読み、記事がなければ空の状態を表示します。一覧ページの featured、通常の一覧、ページ分割も、実際の記事からのみ作ります。モックアップのサンプルカードは、このデータ条件の代わりにはなりません。
• 見た目を完成させるために分類を増やしません。 画像には複数の分類 chip を描けますが、当時のコンテンツ schema とデータが対応していたのは確認済みの分類だけです。十分なコンテンツとルートの振る舞いがないまま分類を増やすのは、装飾を製品機能と取り違えることになります。
• 製品プレビューをそのまま機能一覧にはしません。 当時の製品ページには日序の位置付け、状態、説明、整理済みの二つの方向性がありました。モックアップ内の細かな画面要素から、製品範囲を直接広げることはできません。
• 協業の方向性を、そのまま成熟したサービスとは扱いません。 協業ページには、インターフェースとコンテンツの設計、サイトと Web システム、AI 活用の探索という三つの方向性があります。ただし、文言には「AI 導入コンサルティングは今後の方向性」という制約も残されています。サービスの行が視覚的に存在していても、すべてに固定プランや保証された提供手順があるとは限りません。
• 記事の目次を画像から手で写しません。 目次は本文の実際の heading から生成し、関連記事も正式な記事から選ぶべきです。モックアップに描かれた目次の文字やカードは、レイアウトの例にすぎません。

画像とコード、またはコンテンツのルールが一致しないときは、コードを無理に画像へ近づけるのではありません。その違いは未完成なのか、まだ決まっていないのか、それとも画像が最初から方向性の案でしかなかったのかを確認します。答えによって、その後の対応も変わります。

着手前にモックアップの確認カードを埋めます

すべての参考画像をピクセル単位の検収表にする必要はありません。ただし、実装する各セクションには、少なくとも次の六つの答えを残しておけます。

• 視覚的な意図：このセクションで、読者に最初に何を見てもらいたいですか。
• 実装契約：ページ内で担うのは、コンテンツ、ナビゲーション、操作、装飾のどれですか。
• 実際の情報源：文字、画像、状態、リンクはどこから来ますか。
• 不足時の表示：記事、画像、翻訳、製品データがないとき、どう表示しますか。
• 対象外：画像のどの細部は、約束しない、公開しない、または今は実装しませんか。
• 検証の根拠：HTML、データ、キーボード、狭い画面、目視のうち、何を使ってどの点を確認しますか。

以下には、繁体字中国語の元の確認カードをそのまま残しています。

視覺意圖：這個區塊想讓讀者先看到什麼？
實作契約：它在頁面裡負責內容、導航、操作還是裝飾？
真實來源：文字、圖片、狀態與連結從哪裡來？
缺少時：沒有文章、圖片、翻譯或產品資料時要怎麼呈現？
不包含：圖中哪些細節不承諾、不公開或暫時不做？
驗證證據：要用 HTML、資料、鍵盤、窄螢幕或人工視覺確認哪一件事？

このカードは、一般的な要件整理とまったく同じではありません。サンプルの文言を正式なコンテンツと扱う、画面イメージを screenshot と扱う、画面上のサービス名を製品の約束と扱う、といったモックアップ特有の誤解を対象にしています。先にそれぞれの位置付けを分けることで、何を実装する価値があり、何は議論の段階に留めればよいかが分かります。

この方法で確認できることと、できないことを分けます

ここで記録した Astro の実装と文書からは、いくつかの具体的な判断ができます。ホーム、ノート一覧、記事、製品、協業の各ページには実際のコンポーネントとコンテンツの情報源があります。正式なノートは公開対象を取得する処理を通じて公開ページに入り、製品と協業の画面プレビューはコードで生成でき、記事の目次は実際の heading と結び付けられます。

ただし、これらを根拠に次のような結論は出せません。

• モックアップがすでに正確に計測された設計稿であること。
• 正式なページが画像とピクセル単位で一致していること。
• 画像に登場するすべての製品機能、サービス範囲、記事、日付が実在すること。
• 当時の RWD、読みやすさ、アニメーションのテンポ、視覚的な雰囲気が、すべての端末で目視検収を通過していること。
• このページ群が検索、アクセス、協業、事業上の成果をすでに生んでいること。

技術的な確認では、出力、データ、振る舞いの一部を検証できます。最終的な視覚の方向性と公開内容は、それでも決定権を持つ人の確認が必要です。モックアップの役割は、みんなの判断を先回りして済ませることではなく、判断が必要な箇所を早い段階で見えるようにすることです。

この記録の範囲です

本文は、スタジオ改修の参考画像と、当時の Astro ページとの差異についての判断を整理したものです。視覚的な方向性、実装契約、画面イメージ、実際のスクリーンショット、架空のコンテンツの境界に焦点を当てています。視覚デザイン全体の解説ではなく、未計測の RWD、ユーザー調査、製品機能、サービスの成果を確認済みの事実として記述したものでもありません。