シリーズ第4回。いよいよ実装の話です。
技術選定が終わって、Nuxt + WordPressという構成が決まりました。ここからは、AIエージェントと一緒にコードを書いていく日々の始まりです。
「AIとペアプロ（ペアプログラミング）って、実際どんな感じなの？」——そのリアルをお伝えします。
Agent Teamsでチーム開発
僕（人間）→ PMエージェント → 実装担当/確認担当——
第2回で設計したこの体制が、実装フェーズで本格的に動き出しました。Agent Teams（複数のAIエージェントをチームとして動かせる機能）をフル活用して、僕がPMに「こういうものを作りたい」と伝えると、PMがタスクを分解して実装担当に振り、できたコードを確認担当がレビューする流れです。
典型的な開発の流れ
ちなみに、最初のひと通りの実装——共通レイアウト、各ページの骨組み、WordPress APIとの連携——はものの数時間で終わりました。一人で全部手作業でやったら、この工程だけで数日はかかるはず。AIチームのスピードは想像以上で、僕が要望を伝えている間に次々とコードが出来上がっていく感覚です。
1回のやりとりの流れは、だいたいこんな感じでした。
- 僕: 「こういうコンポーネント（UI部品）を作りたい。要件はこう」とPMに伝える
- PM: タスクを分解して、実装担当に割り振る
- 実装担当AI: コードを書いてくれる
- 確認担当AI: できたコードをレビューして、問題点をフィードバック
- 僕: PMからの報告とレビュー結果を確認し、「ここを変えて」「この方向で直して」と判断
- 僕: 最後に実際にブラウザで表示を確認して、OKなら次へ進む
一人開発なのに、登場人物が4者いるチーム開発の流れになっているのが分かりますか？ しかも、AIは疲れないし、待たせても怒らない。夜中の2時に「やっぱりここ変えたい」と言っても、嫌な顔一つしません。
フリーランスは作業時間が不規則になりがちなので、正直これはとても助かりました。
AIが得意だった3つのこと
1. 型定義やテンプレート的なコード
TypeScript（型のあるJavaScript）の型定義や、Nuxtの決まった書き方に沿ったコードは、AIの最も得意な領域です。
たとえば、「WordPressのAPIから返ってくるデータの形」と「フロントエンドで使いたいデータの形」は違います。この変換処理を、AIは型定義からデータ変換のロジックまで一気に書いてくれます。
人間がやると地味に時間がかかる作業ですが、AIにとっては朝飯前です。
2. 「これと同じパターンで別のを作って」
「ブログのカードと同じ構造で、実績紹介のカードを作って」という指示が、非常によく効きました。
AIはプロジェクト内の既存コードを理解しているので、デザインの統一感を保ちながら新しい部品を作ってくれるんです。人間だと「前のコードどこだっけ？」と探す時間がかかりますが、AIは一瞬です。
3. ちょっとした便利関数
「HTMLタグを除去する関数」「日付を見やすいフォーマットに変換する関数」「SEO用の構造化データを生成する関数」——こうした小さなユーティリティ（便利ツール）は、「こういう関数が欲しい」と言えばサッと作ってくれます。
AIが苦手だった2つのこと
1. プロジェクト全体の「空気」を読むこと
AIは目の前のタスクは上手くこなしますが、「このサイト全体の中で、このページはどういう位置付けなのか」という大きな文脈の理解は弱いです。
たとえば、実績紹介ページを作るとき、僕は「NDA（秘密保持契約）がある案件をどこまで載せるか」でかなり悩みました。業務実績はぼかして書くしかない、でも個人プロジェクトは詳しく見せたい——この「何を見せて、何を見せないか」の判断は、あくまで人間がするべきコンテンツの意思決定です。
AIは指示どおりにページを組み上げてくれますが、「この情報は出していいのか」「どう表現すればNDAに抵触しないか」まではわかりません。コンテンツの方針を決めるのは、最後まで人間の仕事でした。
2. 「使い心地」の判断
「このボタン、ここにあると押しにくいな」「この動き、ちょっとうっとうしいな」——こういう感覚的な判断はAIにはできません。
コードだけ見ると問題ないけど、実際にブラウザで触ってみると「なんか違う」と感じる。この「なんか違う」をキャッチして言語化するのは、人間だけの仕事です。
AIの出力を「方向修正」した実例
具体的なエピソードを紹介します。
サイト全体のデザインが一通り組み上がったとき、AIはデザインガイドラインに忠実に、各コンポーネントのテキスト色をCSS変数で設定してくれました。見出しは明るめ、本文はやや控えめ、補足テキストはさらに薄く——ルール通りの階層構造です。
コード上は完璧。CSS変数もきれいに整理されていて、設計としては申し分ない。
でも、実際にブラウザで記事を読んでみたら「暗い。読みにくい」と感じたんです。
ダークテーマの背景色に対して、本文テキストのグレー（#6B7280）が沈んでしまっている。長文を読み進めるには、ちょっとつらい。これはCSSの数値を見ているだけでは気づけない、実際に目で見て、読んで、初めて分かる違和感でした。
そこでAIに「本文テキストが暗すぎるから、もっと明るくして。ブログ記事やWorksの説明文など、じっくり読むテキストは全部 –color-text-primary に統一しよう」とフィードバック。結果的に、かなりの数のコンポーネントのテキスト色をまとめて修正することになりました。
ここでの教訓は、AIは設計ルールを正確に守るのが得意。でも「実際に使ったときにどう感じるか」は、人間が確かめないと分からないということです。コードレビューだけでなく、ブラウザで実際に触る・読む・感じるというステップが、AI協働では欠かせません。
計画にない作業が出てきたとき
第1回で紹介した「4フェーズの計画」に沿って進めていましたが、実際にはプロジェクトの途中で計画にはなかった作業がいくつも出てきました。
たとえば——
- WordPressのローカル開発環境構築——LXCコンテナでWordPressを動かす環境をゼロから構築。計画時点では「既存のWP環境を使う」くらいのイメージだったのが、実際にはコンテナ設定・ポートフォワード・オフラインインストールなど、かなりの作業量になった
- UI改善のブラッシュアップ——ひと通り実装が終わった後、「ここの余白が気になる」「このホバーエフェクトを調整したい」といった細かい改善が山ほど出てきた。計画には「実装」とあるだけで、こうした磨き込みのフェーズは想定していなかった
- 別のAIエージェントとの連携——このプロジェクトではClaude Codeだけでなく、別のAIエージェント（Google系）にもUI改善やOGP実装を手伝ってもらった。エージェント間の情報共有のために、共有ディレクトリとドキュメントルールを整備する必要があった
こうした計画外の作業が出てきたとき、PMが都度判断して小規模なチームを編成し、対応してくれたのが大きかったです。UI改善なら「デザイン調査担当＋実装担当＋レビュー担当」の3名チーム、環境構築なら「実装担当＋確認担当」の2名チーム——というように、作業の性質に合わせて柔軟にチームを立ち上げてくれる。
人間がPMをやっていたら、計画外の作業が積み重なるたびに「これもやらなきゃ」と焦りが生まれます。でもPMをAIに任せていると、PMが淡々とタスクを整理して、最適なチームで対処していくので、僕は「これでOK？」と確認するだけ。この安心感は大きいです。
一人開発の味方——AIによるコードレビュー
面白い使い方として、AIが書いたコードをAI自身にレビューさせることもしました。
「このコードをレビューして。セキュリティ（安全性）、パフォーマンス（処理速度）、アクセシビリティ（使いやすさ）の観点で」と依頼すると、問題点を指摘してくれます。
完璧ではないですが、一人開発の「見落とし」を減らす効果は確実にあります。人間って、自分で書いたコードの問題点にはなかなか気づけないものなので、「もう一つの目」があるのは心強い。
まとめ——AIは「24時間対応のチームメイト」
AIとのペアプログラミングで感じたことをまとめます。
- 決まったパターンの実装 → AIに任せるとびっくりするほど速い
- 既存コードの横展開 → AIが一番活きる場面
- 使い心地の判断や方向性 → 人間が握るべき部分
- コードレビュー → AIの客観的な目も活用できる
そして何より実感したのは、開発期間の圧倒的な時短です。企画・設計を含めたプロジェクト全体が、一人で手作業でやった場合の何分の一かの期間で形になりました。単純に「コードを書く速度が速い」だけでなく、PMがタスクを分解して複数のエージェントに並行で割り振るので、人間一人では物理的に不可能な並列作業が実現するんです。
大事なのは、AIを「便利なコード生成ツール」ではなく、「チーム」として機能させること。PMに要望を伝えて、PMがチームを動かし、僕は確認と判断に集中する。この体制があるからこそ、一人開発でもチーム並みの生産性が手に入るんです。
次回は、このプロジェクトで一番試行錯誤した「デザイン・演出」の話。人間の感性とAIの実装力をどう組み合わせたかをお話しします。