ポートフォリオに作品カードだけでなくノートも必要になる理由

作品カードとノートは同じサイトに置けますが、同じ種類の根拠を示すものではありません。

カードは「これは何か、どこで見られるか」を読者にすばやく伝えるのに向いています。ノートは「なぜこう作ったのか、途中で何を選び何を見送ったのか、どの結果を実際に検証したのか」に答えるのに向いています。説明をすべてカードに詰めると、作品一覧を拾い読みしにくくなります。一方、カードだけでは、重要な判断の多くを読者が推測するしかありません。

基本的な判断は、作品カードは成果を見つけてもらうために、ノートは方法と限界を理解してもらうためにあるということです。長さだけが違う同じページではなく、公に示す根拠について異なる役割を担っています。

作品カードはまず「見つける」を支えます

原稿で記録した実装では、作品ページのカードには、作品名、日付、画像、技術タグ、展示ページやプロジェクトページへのリンクという、比較的決まった情報があります。これらの項目は、すばやく比較して選ぶのに向いています。読者は、すべての作品を開かなくても、続けて見るかどうかを判断できます。

カードを根拠に判断できることは、通常、限られています。

• その作品が、サイトの作品一覧に含まれています。
• 名前、画像、基本的な分類があります。
• 読者が、実際の展示や公開プロジェクトのリンクへ移動できます。
• ページの日付やタグは、記録したデータに明示されている情報です。

これだけでも役立ちますが、アーキテクチャ、要件、失敗時の経路、その後の保守を自動的に説明するものではありません。画像は結果を見せられますが、画面の背後にある判断の根拠にはなりません。

ノートは「どう形になったか」を扱います

ノートの役割は異なります。一見単純な結果を、読者がたどれる問いに分けられます。

• 当時、何の問題を解決する必要があったのでしょうか。
• どの要件を残し、どの要件を実装しなかったのでしょうか。
• なぜ、そのデータモデル、ルート、操作方法を選んだのでしょうか。
• ツールとテストは、実際に何を確認したのでしょうか。
• まだ測定していないことや、人による主観的な確認が必要なことは何でしょうか。

このために、すべての作品について完全なケーススタディを書く必要はありません。ある判断が、ほかのページ、コンテンツの工程、開発作業にも持ち帰れる意味を持つなら、独立したノートにできます。逆に、素材が画像一枚と外部リンク一つだけなら、カードで十分かもしれません。

ここで記録している公開ノートは、サイトの再構築、コンテンツの公開、多言語ルーティング、検証、AI との協働を扱っています。作品カードの説明を長くしただけではなく、開発過程のうち、公開できて確かめられる方法を整理したものです。

カードとノートでは根拠として示せる範囲が違います

同じ作品が作品ページとノートの両方に登場することはありますが、二つの入口は互いの代わりにはなりません。

入口	根拠として示すのに向いていること	そこから直接結論づけてはいけないこと
作品カード	作品の存在、基本的な名前、画像、外部への入口です	アーキテクチャの品質、利用者の成果、開発過程の全体です
公開ノート	記録された判断、限界、実装、検証の範囲です	ビジネス上の成果、すべての端末で問題がないこと、すべての読者が理解したことです
実際の展示ページ	記録した状態で、そのリンクを開けることです	内部のデータモデルや、展示していないエラー処理です
コードやテスト結果	確認した範囲内で、対象の条件が成立していることです	テストしていない端末、デプロイ、利用状況です

サイトにノートを加えても、「作品が存在する」が「作品は必ず成功している」に変わるわけではありません。読み取れる根拠が増えることで、読者は結論の出どころと、その結論が及ばない範囲を把握できます。

作品カードを小さな記事にしないようにします

カードごとに背景、判断、技術的な詳細、限界、長い結果一覧を詰めると、一覧は本来の役割を失います。読者は作品をすばやく比較できなくなり、モバイルでは同じ階層の文章が大量に並んで、画面が長くなります。

より安定した役割分担は、次のようなものです。

• カードには、作品を識別するために最低限必要な情報を残します。
• 背景全体が必要な場合は、実際の展示ページ、プロジェクトページ、公開ノートへリンクします。
• ノートは主要な問いを一つ扱い、作品情報をすべてもう一度コピーしません。
• 素材が足りない作品を、無理に完全なケーススタディにしません。

内容を細かく分ければ分けるほどよい、という話ではありません。各入口でどれくらい読む必要があるかを、読者にわかるようにするためです。カードは閲覧するため、ノートは理解するために使います。互いに案内し合い、同じ内容を取り合わないようにします。

ノートで作品の成果を作り足すこともできません

ノートはカードより長く書けますが、根拠のない説明まで増やせるわけではありません。手元にあるのが実装コード、画面、ビルドの確認だけなら、説明できるのもその内容です。利用者調査がなければ、読者の好みを補えません。アクセス数や協業に関するデータがなければ、ビジネス上の成果を付け加えることもできません。

同様に、作品カードの日付、タグ、リンクを、ノートで別の物語に組み替えるべきではありません。作品名は何か、リンクは存在するか、機能は実際にマウントされているかは、実際のデータと使用箇所に戻って確認する必要があります。

公開ノートの価値は、結果を大きく語ることではなく、判断の範囲をより明確に書くことにあります。

作品からノートを一本書く価値があるのはどんなときでしょうか

まず、いくつかの問いを確認できます。

1. この作品には、作者以外の人にも役立つ判断があるでしょうか。
2. その判断を、実装、データ、出力の検証で裏づけられるでしょうか。
3. 作品カードだけでは、読者が重要な取捨選択を見落とすでしょうか。
4. プロジェクト全体をもう一度書くのではなく、主要な問い一つに答える記事にできるでしょうか。
5. どの内容を公開でき、どの内容が私的なデータや未確認の範囲に残るのでしょうか。

すべて否定なら、まずカードだけを残せば十分です。Notes に記事があるように見せるために、作品ごとに新しい根拠のない記事を作る必要はありません。

肯定できるなら、その記事は作品カードに依存せずに成立することもできます。読者が読み終えた後に持ち帰るべきなのは、プロジェクト名だけではなく、判断の方法です。

このサイトでは二つの入口を併設しています

ここで記録した構成では、作品ページからウェブサイトやシステムの作品、コンテンツやビジュアルの作品、独立して表示する AIGC のキャラクタービジュアルを確認できます。Notes では、アーキテクチャ、コンテンツエンジニアリング、インターフェース、AI との協働に関する公開記録を読めます。この二つの入口は、同じデータを説明しているわけではありません。一方は「何を作ったか」に、もう一方は「どう判断し、どう届けたか」に重点があります。

この役割分担には、限界も残しています。すべてのノートが一つの作品に対応する必要はなく、すべての作品にノートが必要なわけでもありません。内容が成立するかどうかは、サイトにまだ埋められるカードがあるかではなく、明確な読者の問いに答えられるかで判断します。

作品カードは成果を見つけるために、公開ノートは成果が形になる過程を理解するためにあります。それぞれが根拠の範囲を守れば、一種類のページですべての問いに答えられるように見せかける必要はありません。

この記録の範囲

この記事は、原稿で記録した作品ページのカードデータ、外部への入口、Notes のコンテンツモデル、既存ページの契約をもとに整理しています。作品を見せることと方法を記録することの役割を分け、作品の画面、ビルドの成功、記事の内容を、利用者の反応、検索上の成果、ビジネス上の結果、完全なケーススタディの根拠へ広げてはいません。