前回は、AIエージェントとの役割分担について書きました。
今回は、このプロジェクトの技術選定——「どんな技術を使ってサイトを作るか」を決めたプロセスをお話しします。
技術選定って、正解がないんです。だからこそ、AIの力が活きる場面と、人間が判断すべき場面がはっきり分かれる、面白いフェーズでした。
まずは要件の整理から
技術を選ぶ前に、「このサイトに何が必要か」を整理しました。
- ポートフォリオ（実績紹介）＋技術ブログ＋お問い合わせページ
- SEO（検索エンジン対策）に強いこと
- コンテンツはCMS（管理画面）から更新したい
- ダークテーマ、かっこいいアニメーション演出
- 一人で運用・メンテナンスできること
この要件をAIに伝えて、「これに合うフレームワーク（サイトの土台となる技術）とCMS（コンテンツ管理システム）の選択肢を、メリット・デメリット付きで出して」とお願いしました。
AIが出してくれた選択肢
フレームワーク側の候補として、Nuxt、Next.js、Astro、SvelteKit。CMS側の候補として、WordPress（ヘッドレス）、microCMS、Contentful、Notion APIなどが挙がりました。
それぞれのメリット・デメリットを比較表にまとめてくれて、とても分かりやすかったです。
ここまでは「AIの仕事」。選択肢を素早く、網羅的に出してくれるのは、AIの大きな強みです。
そしてここからが「人間の仕事」——どれを選ぶか、の判断です。
Nuxtを選んだ3つの理由
比較検討の結果、Nuxt（Vue.jsベースのフレームワーク）を選びました。
理由1: 今一番興味がある分野だから
正直に言うと、Nuxtに「精通している」とは言えません。業務でVue.js / Nuxtの案件に携わってはいますが、JavaScriptを書くこと自体は得意でも、フレームワークとしてのNuxtを隅々まで知り尽くしているわけではないんです。
でも、だからこそ選びました。今一番深掘りしたい技術だったから。
ポートフォリオサイトは、自分が「いま関心を持っていて、本気で取り組んでいる技術」で作るのが一番誠実だと思ったんです。「完璧にできるもの」より「全力で向き合っているもの」のほうが、伝わるものがある気がして。
理由2: サーバー機能が優秀
Nuxtには「Nitro」というサーバー機能が組み込まれています。これを使うと、WordPressから取ってきたデータを整理してからフロントに渡す、という処理がとても簡単に書けます。
イメージとしては、レストランの厨房（WordPress）と客席（ブラウザ）の間に、料理を盛り付けるスタッフ（Nitro）がいる感じ。このスタッフのおかげで、お客さんには綺麗に盛り付けられた料理が出てきます。
理由3: 表示速度とSEOの両立
SSR（サーバーサイドレンダリング、つまりサーバー側でHTMLを生成してから送る方式）とキャッシュ（一度作ったデータを再利用する仕組み）の組み合わせで、表示速度とSEOの両方をカバーできます。
ちなみに、Next.js（React系のフレームワーク）も有力候補でした。でも、Vue.jsのエコシステムを深掘りしていきたいという自分の方向性と、ポートフォリオとしてのメッセージ性を考えて、Nuxtに決めました。
こういう「自分のキャリアの方向性」を踏まえた判断は、AIには難しい部分です。技術的な比較はAIに任せて、最終判断は人間がする。この組み合わせがうまく機能しました。
CMSの選定——過去の経験が決め手になった話
CMSの選定では、AIとの議論も参考にしつつ、最終的には自分の過去の経験が決め手になりました。
候補としてはmicroCMSやContentfulなど、最近のクラウド型ヘッドレスCMSも検討しました。APIがシンプルで使いやすいのは魅力です。
ただ、僕には一つ引っかかるポイントがありました。
実は過去に、WordPressをヘッドレスCMSとして使い、Nuxtと連携するWebサイト制作の案件を数件担当した経験があるんです。WordPress自体の実務経験はそこまで多くなく、どちらかと言えばモック作成の案件のほうが多いのですが、このヘッドレスWordPress × Nuxtという構成には手応えを感じていました。
REST APIでコンテンツを取得して、Nuxtのサーバー機能で整形してフロントに渡す——この流れは実案件で何度か経験していて、設計の勘所が分かっています。
AIにCMSの比較を依頼したときも、WordPressヘッドレスの提案は出てきました。でも今回は、AIの提案に乗ったというより、自分の実体験に基づいて「これなら確実にやれる」と判断したのが正直なところです。
ここがAI協働の面白いところで、AIは技術的なメリット・デメリットを客観的に出してくれますが、「過去に自分がどういう経験をして、何に手応えを感じたか」は人間にしか分からない。最終的な判断基準が自分の中にあることが、技術選定では大事だと感じました。
キャッシュ戦略——AIとの技術的な深掘り
技術スタックが決まった後、「サイトの表示速度をどう確保するか」というキャッシュ戦略をAIと一緒に考えました。
キャッシュというのは、ざっくり言うと「一度取ってきたデータをしばらく保存しておいて、次回からはそれを使い回す」仕組みです。毎回WordPressにデータを取りに行くと時間がかかるので、保存しておいたデータを使って表示を高速化します。
このプロジェクトでは3段階のキャッシュを設計しました。
- Nuxtサーバーのキャッシュ: API応答を一定時間保存
- WordPress側のキャッシュ: WP内部でデータを保存
- Webサーバーのキャッシュ: 画像やCSSファイルを高速配信
初期案はAIが出してくれて、僕が「キャッシュの有効期限はどれくらい？」「記事を更新したらすぐ反映される？」と質問して詰めていきました。
こういう技術的な深掘り（「もし○○だったらどうなる？」を掘り下げること）は、AIが本当に得意です。「この設計の弱点は？」と聞けば、ちゃんと答えてくれる。一人で考えるより、議論の質が上がった実感がありました。
ホスティング環境——フロントとバックを分ける
技術スタックとキャッシュ戦略が決まったところで、「じゃあどこで動かすか」というホスティング環境も決めました。
このサイトはフロントエンド（Nuxt）とバックエンド（WordPress）が分かれたヘッドレス構成なので、サーバーも2台に分かれています。
- フロントエンド（Nuxt）: VPS（自分で管理するサーバー）で動作。NuxtのSSR（サーバーサイドレンダリング）を活かすにはNode.jsが動く環境が必要なので、自由度の高いVPSを選びました
- バックエンド（WordPress）: レンタルサーバーで動作。WordPressを動かすだけなら、PHPとデータベースが使えるレンタルサーバーで十分。管理の手間も少ないです
フロントエンドからはWordPressのREST API（データを取得するための窓口）を叩いてコンテンツを取得する形です。2台のサーバーがAPIで繋がっている、というイメージですね。
この構成もAIと相談して決めましたが、最終的には「自分が運用しやすいかどうか」が決め手でした。VPSは設定の自由度が高い反面、管理は自分でやる必要がある。でもNuxtを動かすにはそれが必要。一方、WordPress側はレンタルサーバーに任せて管理コストを下げる。この使い分けが、一人運用では大事だと思います。
AIの提案を鵜呑みにしないためのポイント
ただし、AIの提案をすべて信じるのは危険です。僕が心がけていたことを共有します。
- 「意図伝わるかな？」と確認する——AIに指示を出した後、こちらの意図が正しく伝わっているか確認する。AIは「分かりました」と答えても、実は違う解釈をしていることがある。提案を受け取る前に、まず認識が合っているかを擦り合わせる
- 「なぜそれがいいの？」と必ず聞く——理由がちゃんと説明できるか確認する
- デメリットもセットで聞く——良いことしか言わないAIの出力は要注意
- 自分の実務経験と照らし合わせる——机上の最適解と、現場の最適解は違うことがある
- 運用のことを考える——技術的に面白くても、一人で面倒を見られるか？
特に最初の「認識合わせ」は大事です。AIの提案を鵜呑みにしない、というと「出力をチェックする」ことばかり意識しがちですが、そもそも入力の段階で認識がズレていたら、どんなに出力をチェックしても的外れなままです。「こういう方向で考えているんだけど、認識合わせをしよう」と一声かけるだけで、AIとのやりとりの精度がぐっと上がります。
AIは「技術的に最も優れた選択」を提案する傾向がありますが、実際のプロジェクトでは技術以外の要素もたくさんあります。チーム体制、予算、運用の手間、キャリアの方向性……。それらを総合して判断するのは、人間にしかできません。
まとめ——「AIに調べてもらって、人間が決める」
技術選定において、AIは「選択肢と比較情報を素早く出してくれるリサーチャー」として、とても頼りになりました。
一方で、最終的に「これでいこう」と決めるのは人間の仕事。自分のスキル、プロジェクトの特性、将来の運用——これらを総合して判断する。
この「意思決定のプロセスを可視化できること」自体が、エンジニアとしての信頼につながると考えています。「なぜその技術を選んだのか」を説明できるエンジニアは、クライアントにとっても安心感がありますよね。
次回はいよいよ実装の話。AIエージェントとのペアプログラミングの現場をお見せします。