シリーズ第6回。今回のテーマは「品質管理・テスト・デプロイ（公開）」です。
一人開発あるあるなんですが、品質管理って後回しにしがちですよね。テストを書くのは面倒だし、自動公開の仕組みを作るのも地味に手間がかかる。
でも、AI協働だと、この「面倒だけど大事な部分」を効率よくカバーできるんです。
Agent Teamsで「実装」と「確認」を常にペアに
コードレビュー（書いたコードを別の目でチェックすること）は、プロの開発現場では当たり前の工程です。でも、一人開発だとこれができない。自分で書いたコードを自分でチェックしても、見落としは減りません。
これまでの記事でも紹介してきたAgent Teamsの体制——僕（人間）→ PMエージェント → 実装担当/確認担当——が、品質管理の面でも大きく効いてきます。
実装担当と確認担当が常にペアになっているので、コードが書かれた時点で自動的にレビューが入る仕組みです。
流れとしてはこんな感じ——
- 実装担当のエージェントがコードを書く
- PMが確認担当に「レビューお願い」とタスクを振る
- 確認担当が安全性・処理速度・使いやすさの観点でチェック
- 問題があればPM経由で実装担当にフィードバック → 修正
- PMが結果をまとめて僕に報告
一人開発なのに、「書く人」と「チェックする人」が別という、プロの開発現場と同じ体制が作れるわけです。
実際に確認担当が見つけた問題の例——
- 入力値のチェックが甘い箇所（悪意あるデータが入る可能性）
- HTMLを直接埋め込んでいる部分のセキュリティリスク
- 画像に代替テキスト（目が見えない方向けの説明文）が設定されていないケース
- 型定義があいまいなまま残っている箇所
100%完璧なレビューではないですが、「書いた本人（エージェント）とは別の視点でチェックが入る」というのが大事なポイント。一人では気づけなかった問題を拾ってくれるのは間違いありません。
キャッシュの問題——AIと一緒にデバッグ
サイト運用で実際にハマった問題を一つ紹介します。
ブログ記事を新しく追加したのに、一覧ページに表示されない。あれ？と思ってWordPress側を確認すると、記事はちゃんと存在している。
原因は、第3回で設計したキャッシュ（データの一時保存）でした。サーバーが古いデータを保存したまま使い続けていて、新しい記事が反映されていなかったんです。
この問題をAIに「こういう状況なんだけど、原因は何だと思う？」と相談したら、「キャッシュが残っている可能性が高い」「キャッシュの保存場所はここ」「削除コマンドはこう」と、すぐに的確な回答が返ってきました。
一人で悩んだら数時間かかったかもしれない問題が、AIとの会話で10分かからず解決。こういう場面では本当に助かります。
GitHub Actionsで自動デプロイ——フロントもバックも
デプロイ（サイトの公開・更新）は、GitHub Actions（コードの変更をきっかけに自動で処理を実行する仕組み）を使って自動化しています。
このサイトはフロントエンド（Nuxt）とバックエンド（WordPress）が分かれた構成なので、デプロイも2本立てです。
フロントエンド（Nuxt → VPS）
フロントエンド側のコードを変更してmainブランチに送ると、自動で——
- Nuxtアプリをビルド（動く形に組み立てる）
- SSH経由でVPS（自分のサーバー）にファイルを転送
- サーバー上でアプリを再起動
——という流れが走ります。
バックエンド（WordPressテーマ → レンタルサーバー）
バックエンド側（WordPressのカスタムテーマ）を変更した場合は、別のワークフローが動きます。こちらはFTP経由でレンタルサーバーにテーマファイルを転送する仕組みです。
ポイントは、変更のあったファイルに応じて必要なワークフローだけが自動で実行されること。フロントエンドだけ変えたのにバックエンドもデプロイされる、ということがありません。GitHub Actionsのpathsフィルタを使って、関連するディレクトリが変更されたときだけ実行するよう設定しています。
これらのワークフローの初期版は、AIに書いてもらいました。「Nuxtをビルドして、VPSにデプロイするGitHub Actionsを書いて」「WordPressテーマをFTPでデプロイするワークフローも」と依頼すると、それぞれほぼ動くものが出てきます。
ただし、セキュリティに関わる部分は自分で確認しました。SSH鍵（サーバー接続用の暗号鍵）やFTPの認証情報、秘密情報の扱いは、AIの提案をそのまま使うのではなく、一つ一つ自分で理解した上で設定しています。
テスト——計画以上の結果が出た
テストフェーズでは、PMがテスト専門の4名チーム——「ビルド検証担当」「コード品質チェック担当」「ユニットテスト担当」「コンポーネントテスト担当」——を編成しました。これも第2回で紹介した「フェーズの内容に応じてチーム編成を変える」パターンです。
結果は——
- ユーティリティ、Composable、サーバーAPI、コンポーネントの全テストがパス
- TypeScript型チェック: テストチームが型エラーを洗い出して修正し、エラー0件に
- ESLintの指摘も全件解消
- ビルド: 成功
当初の計画ではテストの目標数値までは決めていなかったので、ここまでしっかりした結果が出たのは想定以上でした。テスト専門のチームを組んだことで、「テストも書かなきゃ」というプレッシャーから解放され、テスト自体の質も上がったと感じています。
「人間が気をつける」ではなく「仕組みで防ぐ」
品質管理で一番大事だと思っているのは、「人間が毎回注意する」のではなく「仕組みとして防ぐ」ことです。
人間の注意力には限界があります。「気をつけよう」と思っていても、忙しいときは忘れる。だから、仕組みに落とし込む。
このプロジェクトでAIと一緒に作った「仕組み」の例——
- TypeScript厳格モード: 型のミスはコードを書いた時点で検出される
- ESLint（コード品質チェックツール）: コードの書き方を自動で統一
- 構造化データの自動生成: SEO用のデータをプログラムで生成して、手書きミスを防止
- OGP画像の自動生成: SNSでシェアされたときの画像を、記事タイトルから自動で作成
こうした仕組みは、最初に作るのに手間がかかります。でも、AIがあればその初期コストが大幅に下がる。
これ、実はAI協働の「隠れた大きなメリット」だと思っています。今まで「やったほうがいいけど、手間がかかるから後回し」にしていたことを、AIの力で「じゃあやろう」に変えられるんです。
本番運用でもAIと一緒に
サイトを公開した後も、AI協働は続いています。
- バグの修正: エラーの内容をAIに見せて、原因を一緒に特定
- 見た目の微調整: 「ここの余白が気になる」→ AIにCSS修正を依頼
- 新しい記事の追加: WordPress投稿 → キャッシュクリア → 表示確認
特に「すぐ直したいバグ」があるとき、サッとAIに相談して修正案をもらえるのは、フリーランスの一人運用で大きな安心感になります。
まとめ——一人でも「チーム体制」を作れる
品質管理のポイントをまとめます。
- コードレビュー: Agent Teamsの実装/確認ペアで、書いた時点で自動的にチェックが入る
- 問題解決: 状況をAIに説明すれば、一人で悩む時間が激減
- 自動化: AIが骨組みを作って、人間がセキュリティを確認・調整
- 仕組み化: AIのおかげで初期構築コストが下がり、後回しにしがちなことも実現できる
一人開発でも、Agent Teamsで「人間 → PM → 実装/確認」の体制を組めば、品質管理の仕組みが自然と回る。これはAI時代ならではの大きな恩恵です。
次回はいよいよ最終回。このプロジェクト全体を振り返りつつ、「AI時代のエンジニアってどうなっていくの？」というテーマでお話しします。