ウェブサイトコンセプトアーキテクト
個人サイト、ポートフォリオ、ランディングページ向けのコード以前のコンセプト設計。このスキルが生み出すのは方向性であり、マークアップではありません。成果物は、ユーザーが選択するための小規模で明確なコンセプトドキュメント群であり、選ばれたものはui-ux-architectに実装のために渡されます。
使用するタイミング
ユーザーが新しいウェブサイトを始めようとしており、コードを書く前にそれが何であるかを決めたい場合。動作中のサイトのリデザインには使用しません（ただし「ゼロから考え直す」という要件がある場合は除く）。コンポーネントレベルのUI決定にも使用しません — これらはui-ux-architectの担当です。
1. 動作原則 — 一気にやらず、対話形式で進める
6つのステージを対話形式で、一度に一つずつ実行します。各ステージの後、メニューを表示し、一時停止し、ユーザーの選択を待ってから次に進みます。複数のステージを一度の質問にまとめないでください。ユーザーが情報を自発的に提供した場合でも、ステージをスキップしないでください — 提供された内容をプリセットのデフォルトとして表示し、確認を取ってください。
ウォークスルーのポイントは、ユーザーが後回しにしがちな決定を強制することにあります。ステージをスキップすると、後であいまいなコンセプトドキュメントができあがります。
2. 6つのステージ
| # | ステージ | 目的 | 出力 |
|---|---|---|---|
| 1 | 目的 | サイトは何のためか？ | アーキタイプリストから1～2つ選択 |
| 2 | 対象読者 | 誰が読むのか？ | 1～2つ選択、トーンと濃度を決定 |
| 3 | コンテンツ一覧 | サイトには何が載るのか？ | チェックされたセクションメニュー |
| 4 | トーンとパーソナリティ | どのような雰囲気か？ | 厳選リストから2～3の形容詞 |
| 5 | ビジュアル方向性 | どのように見えるか？ | 1つのアーキタイプ（順位付き提案、全リスト表示） |
| 6 | 統合 | コンセプトドキュメント | 2～3の明確なコンセプト案 + ASCIIワイヤーフレーム |
3. ステージ1 — 目的
以下のアーキタイプを提示します。ユーザーは1～2つ選択します（組み合わせ可能、例：ポートフォリオ + ライティングハブ）：
- ポートフォリオ / ショーケース — 作品が中心であり、プロジェクトが情報アーキテクチャの核となる。
- ライティングハブ — エッセイ / ブログ / ノートが中心であり、それ以外はナビゲーション。
- プロフェッショナル名刺 — シングルページまたはそれに近いもの。採用担当者 / クライアントが訪れ、知り、連絡を取る。
- デジタルガーデン — 常にリンクされたエバーグリーンノート。構造はネットワークであり、時系列ではない。
- プロジェクトランチャー — 特定のプロダクトまたはプロジェクトが主役であり、「私について」は脚注。
- 実験的遊び場 — サイト自体がクリエイティブな作品であり、慣習は敵。
ユーザーが互換性のない2つのアーキタイプ（例：実験的遊び場 + プロフェッショナル名刺）を選択した場合、その旨を指摘し、どちらがトップページで優先されるかを尋ねます — 選ばれなかったものはサブセクションとなります。
4. ステージ2 — 対象読者
選択内容は、ものごとに必要な説明の量と適切な語り口を決定します。
- 採用担当者 / クライアント — 素早くスキャンでき、経歴が第一、専門用語は少なく、連絡先が明確。
- 仲間の開発者 / 同業者 — 共通の語彙を前提とし、密度の高さを許容し、コードサンプルが効果的。
- 友人 / コミュニティ — 非公式、性格が前面に出て、内輪ネタもOK。
- 未来の自分 / アーカイブ — 自分の過去を検索するために構築され、密度が洗練よりも優先される。
- オープンウェブ — 一般的な訪問者、自己説明が必要、SEOが重要。
複数の対象読者がいるのは普通です。3つ以上選択された場合、トップページはどれに最適化されるかを尋ねます — 残りはサブページで対応します。
5. ステージ3 — コンテンツ一覧
このメニューを提示します。ユーザーは必要なものをチェックし、カスタム項目を追加することもできます。
標準セクション：
- プロフィール / 自己紹介
- ナウページ（現在注力していること）
- プロジェクト一覧
- 個別プロジェクトのケーススタディ
- エッセイ / ブログ / 文章
- ノート / デジタルガーデン / ウィキ
- 読書リスト / 本棚
- 使用ツールページ（ツール、ハードウェア、セットアップ）
- 履歴書 / CV（またはPDFリンク）
- 連絡先（メール、ソーシャル、フォーム）
- ニュースレター登録
- RSS / Atomフィード
- 変更ログ（サイトまたは生活の更新）
- フォトギャラリー
- トーク / ポッドキャスト / メディア出演
- ゲストブック / ウェブリング（レトロウェブ風）
選択された各セクションについて、フォローアップの質問を1つ行います：これはすでに存在しますか？ コンテンツがないセクションは、コンセプトドキュメントで[deferred]（保留）とマークされ、ユーザーが空のページを公開しないようにします。
6. ステージ4 — トーンとパーソナリティ
2～3の形容詞を選択します。これらはステージ5のビジュアル提案とステージ6のコピーの語り口の基盤となります。
対になる選択肢として提示することで、トレードオフを強制します：
- ミニマル ↔ 情報量が多い
- 遊び心がある ↔ 真面目
- 温かみがある ↔ 無機質
- 生々しい ↔ 洗練されている
- 親密 ↔ 公的
- 実験的 ↔ 従来的
- 速い / スキャンしやすい ↔ 思索的 / 長編向け
- 自信がある ↔ 自虐的
ミニマル + 遊び心がある + 温かみがあるを選んだユーザーには、情報量が多い + 真面目 + 無機質を選んだユーザーとはまったく異なる提案が行われます。選択内容はそのまま記録され、コンセプトドキュメントに設計要件として記載されます。
7. ステージ5 — ビジュアル方向性
8つのアーキタイプ。ステージ1～4に基づいて適合度が高い順に3つをランク付けしますが、ユーザーが上書きできるように全リストを表示します。
| アーキタイプ | 雰囲気 | ステージ1～4でこう言っている場合に適合... | 参考サイト |
|---|---|---|---|
| ターミナル / CLI | 等幅フォント、簡素、コマンドライン風 | 開発者読者、ミニマル、生々しい、アーカイブ | sive.rs、wiki.nikiv.dev、ratfactor.com |
| エディトリアル / スイススタイル | 強いタイポグラフィ、グリッド、たっぷりの余白 | 洗練されている、真面目、プロフェッショナル名刺 | rauno.me、paco.me、linear.app |
| ブルータリズム | 生のHTML、デフォルトスタイル、装飾なし | 実験的、生々しい、親密、開発者読者 | brutalist-web.design、motherfuckingwebsite.com |
| Zine / マキシマリスト | コラージュ、複数のフォント、重ねられたテクスチャ | 遊び心がある、実験的、コミュニティ読者 | cassie.codes、lynnandtonic.com |
| ミニマリストポートフォリオ | シングルカラム、大きな画像、たっぷりの余白 | ポートフォリオ、洗練されている、採用担当者 / クライアント | 多くのデザイナーポートフォリオ |
| ノート / ガーデン | ウィキ風、密な相互リンク、エバーグリーン | デジタルガーデン、アーカイブ読者、情報量が多い | gwern.net、andymatuschak.org |
| マガジン / ストーリー | 長いスクロールのナラティブ、アートディレクション、ヒーロー画像 | プロジェクトランチャー、思索的、オープンウェブ | pitchfork.comのロングリード、the Vergeの特集 |
| データベース / インデックス | フィルタリング可能なテーブル、ほぼUI | 情報量が多い、アーカイブ、多数の作品 | are.naのプロフィール、Derek Siversの/nowディレクトリ |
選択ごとに一文の理由を付けてランキングを表示します（例：「ターミナル/CLIが適合する理由：開発者読者 + ミニマル + 生々しい」と選択したため）。ユーザーが1つを選択します。ランキングを上書きした場合、その理由を尋ねて記録します（上書きは、それまで表面化していなかった制約を明らかにすることが多いため）。
8. ステージ6 — 統合
1つではなく、2～3の明確に異なるコンセプト案を生成します。ユーザーが既に決めている場合でも、代替案は何をトレードオフしているかを明らかにします。
コンセプトドキュメントの形式
各案について、以下のセクションを含むMarkdownドキュメントを作成します：
# コンセプト：<名称>
## 一行ピッチ
<15語以内でサイトを説明>
## 概要
- 目的：<ステージ1の選択>
- 対象読者：<ステージ2の選択、優先順位順>
- トーン：<ステージ4の形容詞>
- ビジュアルアーキタイプ：<ステージ5の選択>
## 情報アーキテクチャ
<ページ/セクションのツリー、最大2階層>
## トップページ戦略
<トップページが何をするか、2～3文で：第一印象、主要アクション、訪問者が知った上で去ること>
## サンプルコピーの語り口
<選ばれた語り口での2～3文 — 「プロフィール」セクションの冒頭、またはトップページのタグラインとサブヘッド>
## このコンセプトで犠牲にするもの
<他のコンセプトと比較して優先度が下がるものの正直なリスト — すべてのコンセプトは何かをトレードオフする>
## ASCIIトップページワイヤーフレーム
<§9を参照>
3つの案は、見た目のバリエーションではなく、現実の軸で異なる必要があります：
- コンセプトA = ユーザーの選択から明らかに読み取れるもの
- コンセプトB = 主要読者にさらに最適化する（多くの場合、よりミニマル）
- コンセプトC = 意図的な挑戦 — 実験のダイヤルをもう一段階回したらどうなるか
3つのうち2つがほぼ同一になった場合、1つを削除し、その理由を説明します。
9. ASCIIトップページワイヤーフレーム
コンセプトごとに1つ。80桁幅に収め、領域を[角括弧]でラベル付けします。ボックス描画または単純なダッシュで階層を示します。
ターミナル/CLIポートフォリオの例：
+------------------------------------------------------------------------------+
| ~ example.dev [now] [writing] [/] |
+------------------------------------------------------------------------------+
| |
| jane doe |
| backend developer · tooling · open-source CLIs |
| |
| > currently building a small build-cache tool in Go |
| |
| --- recent ---------------------------------------------------------- |
| 2026-05-18 shipped: cachetool v0.3 |
| 2026-05-02 essay: why I keep my tools in one repo |
| 2026-04-21 project: build-cache internals |
| |
| --- projects -------------------------------------------------------- |
| cachetool incremental build cache [→] |
| notes short write-ups on tooling [→] |
| |
+------------------------------------------------------------------------------+
| email · github · rss |
+------------------------------------------------------------------------------+
ワイヤーフレームはプロポーションと階層に関するものであり、ピクセル単位のレイアウトではありません。色、フォント、アイコンはASCII以外使用しません。セクションに説明が必要な場合は、ワイヤーフレームの下に1行のメモを追加します。
10. アンチパターン
- 「ユーザーが既に言ったから」という理由でステージをスキップする。 ユーザーの入力をデフォルトとして表示し確認を取ります。想定しないでください。価値の半分は、ユーザーが言わなかったことに目を向けさせることにあります。
- 2～3ではなく1つのコンセプトドキュメントにする。 代替案こそが、ユーザーが何を選んでいるのかを理解する手段です。単一コンセプトの出力は失敗です。
- トーンが確定する前にビジュアルアーキタイプを決める。 ステージの順序が重要です — ビジュアルは目的/読者/トーンの下流であり、並列ではありません。
[deferred]セクションにコンテンツを埋める。 ユーザーがエッセイを書いていないなら、トピックリストを発明しないでください — コンセプトドキュメントは構造にコミットし、コンテンツにはコミットしません。- 実装の詳細を含むワイヤーフレーム。 「ここでshadcn Cardを使う」は禁止 — それはui-ux-architectの仕事です。ワイヤーフレームは何がどこに行くかを示します。
- 一般的な提案。 「クリーンでモダンなポートフォリオ」はコンセプトではありません。すべてのコンセプトドキュメントは、あらゆる軸で具体的な選択にコミットする必要があります。
11. 引き継ぎ
ユーザーが2～3のコンセプトから1つを選択したら、そのコンセプトドキュメントが以下のための要件となります：
- ui-ux-architect — トークン、コンポーネント、アクセシビリティ、4つの必須状態向け。
- 組み込みの
frontend-designスキル — 実運用グレードでコードを書く場合向け。
コンセプトドキュメントはプロジェクトリポジトリに保存され（例：docs/concept.md）、設計根拠として残ります。
12. スキル間の連携
- ui-ux-architect — 実装レベルの標準。このスキルが要件を提供します。
- demo-presentation-architect — 同様のインタラクティブなウォークスルー構造ですが、ドメインが異なります。
- demo-script-architect — ナラティブの原則（読者第一、段階的な開示）はトップページのコピーにも適用されます。