著者注: この記事の約90%はAIによって執筆されたものですが、読みやすく自然な文章になるよう私自身が校正・編集を行いました。Jules自身が自分の成果を誇らしげに語る傾向があったのは微笑ましいポイントでした。この最終結果に到達するまでに数多くのプロンプトで誘導する必要がありましたが、最後の微調整は手動で行ったほうがスムーズでした。編集の全履歴は PRのコミット履歴 で確認できます。ちなみに、Julesは「翻訳機能は備えていない」と主張してこの記事のポルトガル語(ブラジル)翻訳を完全に拒絶したのですが、このブログ全体の翻訳は以前のやり取りでJules自身が行ったものでした。どうやらその時は気分が乗らなかったようです。:)
はじめに#
最近、最新のコンテンツをより効果的にハイライトするために、ブログのホームページを更新することにしました。バックエンドエンジニアである私にとって、フロントエンドの細かな実装に深く踏み込むことは普段の業務ではありません。そのため、あまり慣れていない領域ですべての変更を手作業でコーディングする代わりに、AIコーディングアシスタントである 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のアスペクト比を試してみましょう。……まだ少しイメージと違うので、もう少し横長(高さを低く)にしてください。」
ここで、視覚的な要素についてJulesと反復的に作業する難しさと特徴が如実に現れました。
- 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 ... */}のようなコードコメントがそのまま文字としてレンダリングされてしまっていることを指しています」 - 解決: 私が言っていたのが、正しくない形式で書かれた Goテンプレート/HTMLの文字通りのコードコメント(Hugoの正しいコメント記法
{{/* ... */}}ではなく{/*...*/}と書いていたため、テキストとしてレンダリングされていた)だとJulesが理解すると、修正は一瞬でした。テンプレートから問題のテキストを削除して解決しました。 - 感心した点: (誤解があったとはいえ)問題をデバッグしようとするJulesの粘り強さと体系的なアプローチは見事でした。
- 課題と学び: これはAIとの対話における極めて重要な側面を浮き彫りにしました。それは「自然言語の曖昧さ」です。「コメント」という言葉には複数の意味があります。私の最初の指示は十分に厳密ではありませんでした。
イテレーション5:仕上げの微調整#
目に見えていたテンプレートのコメントを解決した後、最後の仕上げを行いました。
「『Featured Post』という見出しタイトルを削除してください。カード幅を50%に変更し、タイトルとサマリーのフォントサイズを大きくしてください。アイキャッチ画像のアスペクト比は16:9にしてください。」
これにより、カード幅、フォントサイズ、画像のアスペクト比の最終調整が行われました。幅のパーセンテージ指定は効果がありませんでしたが、アスペクト比の変更は見事に狙い通りの効果を発揮しました。
ボーナス・イテレーション:Jules がこの記事のドラフトを執筆!#
「完璧です! これ以上のコード変更は必要ありません。では次に、今行った一連のイテレーションを振り返る新しいブログ記事のエントリを作成してください……」
そして完成したのがこの記事です! この記事自体、Julesとのやり取りログと私のガイダンスフィードバックをもとに、Julesの支援を受けてドラフトが執筆されました(まさに今あなたが読んでいるこの内容も含めてです)。
Jules との協調でうまくいった点#
- スキルギャップの解消: バックエンドエンジニアである私にとって、Hugoのテンプレート処理やTailwind CSSなど、普段あまり触れないフロントエンドのタスクに取り組む上で、Julesは非常に心強い味方でした。Julesはフロントエンドに関する私の知識不足を補い、提示された解決策を私自身が誘導し、ブラッシュアップしていくことができました。
- 実装スピード: 要件が明確に理解されている変更であれば、Julesは手作業でタイピングするよりもはるかに速く、コードの修正、ファイルの作成、構造のリファクタリングを行ってくれます。
- 複雑な指示への対応力: 全体として、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アシスタントは極めて強力なツールです。人間の監督や設計意図そのものを完全に代替するわけではありませんが、適切なマインドセットとコミュニケーション戦略を持って臨めば、開発効率を飛躍的に高めてくれる頼もしい相棒になります。




