なぜ今ポートフォリオを作ったのか
2026/3/29
なぜ作ったのか
2026年、AI を使えば高品質なポートフォリオは数時間で量産できるし、実際にそういうサイトは増えていると思います。だからこそ逆に、「この人は AI に丸投げしただけでは?」と見透かされるリスクも確実に上がっており、出来上がったものだけでは差がつかなくなってきています。
採用側が今欲しがっているのは、最終成果物の見た目ではなく、「この人は AI に何を指示して、どう判断して、最終的にこう着地させたのか」 という意思決定の軌跡だと感じます。
作れるハードルが下がった以上、差別化は「思考の跡」になる。問題発見 → 仮説 → 試行錯誤 → 決断の理由。これが見えるかどうかで、同じクオリティのアウトプットでも伝わるものがまったく違うと思っています。
このポートフォリオは、その「思考の跡」を残す場所として作りました。コードそのものが技術力のデモンストレーションであり、ブログは判断の記録であり、スライドは深掘りの証拠。完成品を並べるショーケースではなく、考えた過程を見せるドキュメントにしたいと考えています。
以下、このポートフォリオ自体をどう設計・構築したかの判断記録です。
なぜ TanStack Start を選んだか
Next.js ではなく TanStack Start を選んだ理由は、大きく4つあります。
型安全ルーティング
TanStack Router のタイプセーフなルーティングが最大の決め手でした。ルートパラメータ、サーチパラメータ、ローダーの戻り値がすべて TypeScript に推論される。Zod スキーマでサーチパラメータをバリデーションすれば、ランタイムの型安全もついてくる。存在しないルートへの <Link> はコンパイル時にエラーになるので、ブログ記事のスラッグ管理でリンク切れを防げます。
Next.js の useSearchParams() が型なしの URLSearchParams を返すのに対して、TanStack Router はルート定義から型が流れてくる。この差は一度味わうとやめられません。
Vite ベースの開発体験
TanStack Start は Vite ベースなので、開発サーバーのコールドスタートが 150-300ms、HMR が 10-50ms。ポートフォリオのようにデザインを何度も微調整するプロジェクトでは、この速度差が効いてきます。
2026年3月に Vite 8 がリリースされ、Rolldown がデフォルトバンドラーになりました。esbuild + Rollup の二重構成が Rolldown に一本化され、プロダクションビルドは Rollup 比で 10-30 倍高速。実際に Linear は 46s → 6s、Ramp は 57% のビルド時間削減を報告しています。さらに @vitejs/plugin-react v6 では Babel が Oxc に置き換わり、Rust ツールチェーンへの移行がほぼ完了しています。
TanStack Start はこの恩恵をそのまま受けられる。Next.js の Turbopack も高速ですが、プラグイン API は 2026 Q2 時点でまだ未出荷で、500 以上あるVite プラグインエコシステムの柔軟性は得られません。
シンプルなメンタルモデル
TanStack Start のアプローチは「普通の React を書いて、必要な場所にサーバー最適化を足す」。Next.js App Router の「Server Components がデフォルト、インタラクティビティはオプトイン」とは逆の発想です。
createServerFn は明示的な RPC エンドポイントで、何がサーバーで実行されるかがコード上で一目瞭然。HTTP メソッドも GET / POST / PUT と細かく指定できる。Next.js の 'use server' ディレクティブの暗黙的な境界管理と比べて、デバッグ時に迷いません。
ポートフォリオのコードがそのまま技術力のデモンストレーションになるので、「マジック」の少ないフレームワークの方が都合がいい。
デプロイの自由
Cloudflare Workers、Netlify、Vercel、Node.js サーバー、Bun、Deno、AWS Lambda — TanStack Start はプラットフォーム非依存です。特定のインフラに縛られず、このサイトも Vercel にデプロイしていますが、いつでも乗り換えられる安心感があります。
技術スタック
- Framework: TanStack Start + TanStack Router
- Styling: Tailwind CSS v4(
@theme inlineでテーマ定義) - UI コンポーネント: Base UI(Tooltip, Collapsible など headless で使用)
- コンテンツ管理: Content Collections(ブログ、Experience、AI Projects を Markdown で管理)
- フォント: iA Writer(本文)、iA Writer Mono(コード)、Lora(見出し・セリフ)
- アニメーション: Motion(ロゴのストローク描画)、CSS
@keyframes(背景エフェクト)
コンテンツ管理
ブログ記事、職務経歴、AI プロジェクトはすべて Content Collections で Markdown 管理しています。frontmatter にメタデータを書き、renderMarkdown で HTML に変換。型安全なので typo があるとビルド時にエラーで気づけます。
これから — 捨てた選択肢の記録を増やす
このポートフォリオ自体が、自分が普段やっている「コンポーネント設計 × AI」の実験場でもある。Generative UI の考え方を取り入れたコンポーネント体系の試行、LLM との連携など、学んだことをこのブログに書いていく。
特に意識したいのは、「なぜこの選択肢を捨てたのか」「AI の提案をどこで却下したか」「ユーザーテストで予想外だった点をどう修正したか」といった、捨てた選択肢込みの意思決定ストーリーを残すこと。最終的なコードだけでは見えない判断の軌跡こそ、このブログの価値だと考えている。