著者注： この記事の約90%はAIによって執筆されたものですが、読みやすく自然な文章になるよう私自身が校正・編集を行いました。Jules自身が自分の成果を誇らしげに語る傾向があったのは微笑ましいポイントでした。この最終結果に到達するまでに数多くのプロンプトで誘導する必要がありましたが、最後の微調整は手動で行ったほうがスムーズでした。編集の全履歴はPRのコミット履歴で確認できます。ちなみに、Julesは「翻訳機能は備えていない」と主張してこの記事のポルトガル語（ブラジル）翻訳を完全に拒絶したのですが、このブログ全体の翻訳は以前のやり取りでJules自身が行ったものでした。どうやらその時は気分が乗らなかったようです。:)
はじめに#
最近、最新のコンテンツをより目立たせる（ハイライトする）ために、ブログのホームページをリニューアルすることにしました。バックエンドエンジニアとして、フロントエンドの細かな仕様やマークアップに深く潜り込むのは日常的な業務領域ではありません。そのため、不慣れな領域の変更をすべて手作業でコーディングする代わりに、AIコーディングアシスタントである Jules の力を借りることにしました。
この記事では、Julesとの試行錯誤のプロセスやうまくいった点、（時にはクスッと笑えるような）すれ違い、そしてスキルギャップを埋めながらWeb開発でAIを効果的に活用するための学びを詳しく振り返ります。
実装のゴール：特集記事（Featured Post）セクション#
Julesへの最初のリクエストはシンプルでした。
「メインページのレイアウトを変更して、最新のブログ記事を「最近の投稿」一覧に含めるのではなく、特集（ハイライト）として上部に目立たせて表示してください。「最近の投稿」リストには、その最新記事を除いた過去の記事を表示するようにします。なお、この挙動はブログのトップページ（Home）のみに適用してください。ユーザーが「Blog」メニューをクリックした際には、最新記事も含めすべての投稿が従来どおり新しい順（逆時系列）で表示される必要があります。」
Julesは意図を即座に汲み取り、Hugoのコードベースを探索して該当テンプレートを特定し、必要な修正を加える作業計画を提示してくれました。
試行錯誤のハイライト：良かった点、苦戦した点、そしてAIの挙動#
理想の表示を実現するまでに、いくつかのイテレーション（試行錯誤）を重ねました。
イテレーション1：初期セットアップ — まずは基本の骨組みから#
Julesは、Blowfishテーマのパーシャル（partial template）を的確に特定し、テーマのオーバーライド構造を整えてくれました。「Recent Posts（最近の投稿）」一覧から最新記事を切り離すロジックもスムーズに実装されました。
- うまくいった点： Hugoのコア構造の把握、記事リストの取得、基本的なテンプレートの改修。テーマやプロジェクト内のファイルを迅速に探索・把握するJulesの能力は、ここで大きな時間短縮につながりました。
イテレーション2：Tailwind CSS によるスタイリング — 試行錯誤のダンス#
続いて、タイトル表示、カード幅、アイキャッチ画像のサイズなど、見た目のスタイリングに着手しました。ここではビジュアルを微調整するために、次のようなプロンプトを何度もやり取りすることになりました。
「特集記事のタイトルを『Featured Post』に変更してください。カード幅は画面幅の約80%に調整してください。画像が縦長すぎるので、4:3のアスペクト比を試してみましょう。……まだ少しイメージと違うので、もう少し横長（高さを低く）にしてください。」
ここで、AIを介して視覚的な要素を作り込むイテレーションの難しさが浮き彫りになりました。
Julesのアプローチ： タイトル表示のためにi18nファイルを修正し、Tailwindの様々な幅ユーティリティクラス（例：
md:w-4/5、md:w-2/3、max-w-xl、max-w-2xl）を適用したほか、画像のアスペクト比を保つためにpadding-bottomハックを活用しました。課題と苦労した点： 普段バックエンドを中心に開発している私にとって、AIという仲介者を挟んでTailwindのスタイリングを手探りで進める作業はなかなかの難関でした。Julesが適切だと判断したクラスを当てても、レンダリング結果がこちらの思い描くイメージとすぐに一致するとは限りません。Tailwindのクラスを変更しても一発で目に見える変化が得られなかったり、予期せぬ副作用が出たりすることも多くありました。その結果、「このクラスを試してみて」「いや、もっと幅を狭く／広く／縦を低くして」というやり取りが何巡も続くことになりました。最終的には狙いどおりの見た目に仕上がったものの、もどかしさを感じる場面もありました。非同期なAI支援ワークフローにおいて、コードの変更とリアルタイムな視覚フィードバックが直結していないというギャップを痛感しました。
得られた学び： 指示が意図通りに視覚へ反映されないことがあるため、デザインの細かな微調整はAIとの共同作業の中で最も根気を要する部分です。具体的でわかりやすい言葉でフィードバックを返すことが不可欠ですが、画面を直接指さしたりリアルタイムに自分でピクセル単位の微調整ができない以上、多少のキャッチボールが発生するのは避けられないと割り切ることも大切です。それでもJulesはこちらの修正リクエストに一つひとつ忠実に対応してくれたため、フロントエンドの知識不足を十分に補うことができました。
イテレーション3：カスタムCSS vs Tailwind — ちょっとした寄り道#
カードのサイズをより精密に制御したいと考えた私は、ある段階で次のようなプロンプトを投げました。
「Jules、既存のクラスを組み合わせるのではなく、特集記事カード専用のカスタムスタイルクラスを作成してください。このスタイルでは、コンテナに対して幅・高さを相対的に75%に設定してください……」
Julesの対応： Julesは指示どおりにカスタムCSSルールを定義し、カード用のパーシャルテンプレートを書き換えてそのクラスを適用しました。
結果と学び： Julesは指定通り完璧に実装してくれたものの、Tailwindで統一されているブログ全体のデザイン体系の中で、その部分だけがどこか浮いた印象になってしまいました。カスタムCSSが全体と調和しなかったため、やはりTailwindの流儀に沿って一貫性を保つほうが重要だと判断しました。AIに解決策を提示させるときでも、プロジェクト既存のデザイン言語やフレームワークの規約にしっかり従わせるべきだという良い教訓になりました。Julesにお願いして、再びTailwindベースの実装へとロールバックしてもらいました。
「直前の変更を取り消して、Tailwindスタイルの記述に戻してください。Tailwindのベストプラクティスに沿って同様のスタイルガイドラインを適用してください」
イテレーション4：「コメント」をめぐる大いなるすれ違い！#
人間とAIのコミュニケーションの面白さを最も象徴していたのがこの場面です。私は次のように伝えました。
「特集記事の中にコメントがレンダリングされてしまっています。すべてのコメントを削除するか、非表示にしてください」
- Julesの解釈： Julesは私がブログの「ユーザーコメント欄（UtterancesやGiscusなど）」や、閲覧数・いいね数といったメタデータを指していると勘違いしました。その結果、Julesは閲覧数・いいね数の表示条件を調べて非表示にするコードを書き始めました。
- こちらの意図を再説明： 変更内容を見て、具体的な例を挙げて誤解を解きました。
「違います、閲覧数やいいね数を消してほしいとは言っていません。画面に
{/* Adjusted padding ... */}や{/* Removed prose classes ... */}のようなコードコメントがそのまま文字としてレンダリングされてしまっていることを指しています」 - 解決方法： 私が言っていたのが「テンプレート内のコードコメント」であり、書式ミス（Hugoの正しいコメント構文
{{/* ... */}}ではなく{/* ... */}と書いていたため、プレーンテキストとして画面に出力されていた）だったと理解した瞬間、修正は一瞬でした。該当する不要なコメント文字列をテンプレートからさっと削除してくれました。 - 感心した点： （解釈がズレていたとはいえ）問題を突き止めて修正しようとするJulesの粘り強さと体系的なデバッグ姿勢は見事でした。
- 課題と学び： 自然言語の曖昧さという、AIとの対話における根本的な課題が如実に現れました。「コメント」という単語ひとつ取っても複数の意味が存在します。最初の私の伝え方が具体的でなかったのが原因でした。
イテレーション5：最後の仕上げ#
余計なテンプレートコメントの露出が解消されたところで、最後の微調整を行いました。
「『Featured Post』という見出しタイトルを削除してください。カード幅を50%に変更し、タイトルとサマリーのフォントサイズを大きくしてください。アイキャッチ画像のアスペクト比は16:9にしてください。」
これにより、カード幅、フォントサイズ、画像比率の最終調整が完了しました。パーセンテージによるカード幅の指定はうまく効きませんでしたが、アスペクト比の調整は見事にバッチリ決まりました。
ボーナス・イテレーション：Jules がこの記事のドラフトを執筆！#
「完璧です！ これ以上のコード変更は必要ありません。では次に、今行った一連のイテレーションを振り返る新しいブログ記事の下書きを作成してください……」
こうして生まれたのがまさにこの記事です！ この記事自体、Julesとの作業ログと私のフィードバックをもとに、Jules自身の協力を得てドラフトが書き上げられました（今読まれているこの反省点や学びも含めてです）。
Jules との開発でうまくいった点#
- スキルギャップの補完： バックエンドエンジニアである私にとって、Hugo のテンプレート構造や Tailwind CSS のスタイリングといった普段あまり触れないフロントエンド領域のタスクを進める上で、Jules は心強い味方でした。フロントエンドの専門知識不足を Jules が補い、提示された解決策を私自身がレビューしながら洗練させていくという理想的なコラボレーションができました。
- 実装スピード： 変更要件が明確であれば、ファイルの作成、コードの編集、構造のリファクタリングを手作業でタイピングするより圧倒的に素早く完了させてくれます。
- 複雑な指示の理解力： 複数ステップにわたるリクエストや、やや複雑なレイアウト要件であっても、全体として意図を的確に把握してくれました。
- 論理的なアプローチ： たとえ途中で認識のズレがあっても、Jules のデバッグや探索プロセス自体は極めて論理的でした。
- 柔軟なイテレーション対応： 微調整のリクエストに対しても、こちらのフィードバックを素直に受け入れ、柔軟に反映してくれました。
直面した課題と学び#
- 指示の厳密さと言語の精度： 「コメント」のすれ違いが示すように、言葉の選び方は極めて重要です。人間同士なら文脈で自明な略称や表現であっても、AIにとっては多義的で曖昧に映ることがあります。
- 視覚的フィードバックループと Tailwind： Tailwind によるスタイリングの試行錯誤は最大の難所でした。Jules は画面のレンダリング結果を直接「見る」ことができないため、理想の見た目や、指定したクラスがなぜ思い通りにならないのかを言葉で説明するには根気と詳細な描写が求められます。これはテキストベースの対話でデザインを詰める宿命と言えます。
- 誤解時の軌道修正： Jules がタスクの意図を誤解した場合、そのまま間違った方向へ律儀に突き進んでしまいます。処理の途中で割り込んで中断する手段がないため、現在の一連の処理が完了するのを待ってから修正指示を出す必要がありました。
- 非同期ワークフローと開発テンポ： 作業は基本的に非同期で進行します。指示を出してから Jules の実装が完了するまでに、数分から複雑なタスクでは30分近くかかることもありました。即座にフィードバックが得られる手作業でのコーディングや、リアルタイムのペアプログラミングと比べると、イテレーションのサイクルはどうしてもゆっくりになります。
関連リソース#
Jules についてさらに詳しく知りたい方は、以下の公式リソースを参照してください。
まとめ#
総じて、ブログのホームページ機能の実装を Jules と進めた体験は非常に生産的なものでした。まさに AI をステアリングしながら作り上げる「バイブコーディング（vibe-coding）」そのものを実感できました。成功の鍵は、明確で反復的なコミュニケーション、すれ違いが生じたときの忍耐強さ、そして具体的で実行可能な指示（フィードバック）を与える姿勢にあります。
Tailwind をめぐる試行錯誤や AI 特有の誤解といったもどかしさは、現段階の AI 支援開発におけるリアルな日常と言えます。しかし、非同期処理ゆえの待ち時間があったとしても、コーディングの機械的な作業を任せ、自分の専門外（Tailwind の実装パターンや Hugo のテンプレート構造など）に関する具体的な提案を引き出せたことは、トータルで見て間違いなく大きなプラスでした。この単一機能のためだけにフロントエンドのデザイン原則や Hugo の細かな仕組み、Tailwind CSS の書き方をゼロから自力で勉強するのと比べれば、圧倒的に速く、効率的でした。
Jules のような AI コーディングアシスタントは強力なツールです。人間の監督や設計意図そのものを代替するわけではありませんが、適切なマインドセットとコミュニケーション戦略を持って接すれば、開発効率を飛躍的に高めてくれる頼もしい相棒になります。
