[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"/api/social-links:{}":3,"/api/blogs/ai-web-dev-06-quality-and-deploy:{}":9},{"links":4},[5],{"platform":6,"url":7,"icon":8},"note","https://note.com/morinoupa2020","simple-icons:note",{"post":10,"relatedPosts":40,"prevPost":114,"nextPost":117},{"id":11,"slug":12,"title":13,"date":14,"excerpt":15,"content":16,"thumbnail":17,"categories":18,"tags":23,"difficulty":36,"tldr":37,"readingTime":38,"relatedTech":39},245,"ai-web-dev-06-quality-and-deploy","【AI×Web制作 #6】AIと品質を守る — レビュー・テスト・デプロイ","2026-02-25T15:00:00","一人開発でもAIをチームメイトにすれば品質管理体制が作れる。コードレビュー、キャッシュ戦略、自動デプロイのリアルな協働プロセスを紹介。","\u003Cp>シリーズ第6回。今回のテーマは\u003Cstrong>「品質管理・テスト・デプロイ（公開）」\u003C/strong>です。\u003C/p>\n\u003Cp>一人開発あるあるなんですが、品質管理って後回しにしがちですよね。テストを書くのは面倒だし、自動公開の仕組みを作るのも地味に手間がかかる。\u003C/p>\n\u003Cp>でも、AI協働だと、この\u003Cstrong>「面倒だけど大事な部分」を効率よくカバーできる\u003C/strong>んです。\u003C/p>\n\u003Ch2>Agent Teamsで「実装」と「確認」を常にペアに\u003C/h2>\n\u003Cp>コードレビュー（書いたコードを別の目でチェックすること）は、プロの開発現場では当たり前の工程です。でも、一人開発だとこれができない。自分で書いたコードを自分でチェックしても、見落としは減りません。\u003C/p>\n\u003Cp>これまでの記事でも紹介してきた\u003Cstrong>Agent Teams\u003C/strong>の体制——僕（人間）→ PMエージェント → 実装担当/確認担当——が、品質管理の面でも大きく効いてきます。\u003C/p>\n\u003Cp>実装担当と確認担当が常にペアになっているので、コードが書かれた時点で自動的にレビューが入る仕組みです。\u003C/p>\n\u003Cp>流れとしてはこんな感じ——\u003C/p>\n\u003Col>\n\u003Cli>実装担当のエージェントがコードを書く\u003C/li>\n\u003Cli>PMが確認担当に「レビューお願い」とタスクを振る\u003C/li>\n\u003Cli>確認担当が安全性・処理速度・使いやすさの観点でチェック\u003C/li>\n\u003Cli>問題があればPM経由で実装担当にフィードバック → 修正\u003C/li>\n\u003Cli>PMが結果をまとめて僕に報告\u003C/li>\n\u003C/ol>\n\u003Cp>一人開発なのに、\u003Cstrong>「書く人」と「チェックする人」が別\u003C/strong>という、プロの開発現場と同じ体制が作れるわけです。\u003C/p>\n\u003Cp>実際に確認担当が見つけた問題の例——\u003C/p>\n\u003Cul>\n\u003Cli>入力値のチェックが甘い箇所（悪意あるデータが入る可能性）\u003C/li>\n\u003Cli>HTMLを直接埋め込んでいる部分のセキュリティリスク\u003C/li>\n\u003Cli>画像に代替テキスト（目が見えない方向けの説明文）が設定されていないケース\u003C/li>\n\u003Cli>型定義があいまいなまま残っている箇所\u003C/li>\n\u003C/ul>\n\u003Cp>100%完璧なレビューではないですが、\u003Cstrong>「書いた本人（エージェント）とは別の視点でチェックが入る」\u003C/strong>というのが大事なポイント。一人では気づけなかった問題を拾ってくれるのは間違いありません。\u003C/p>\n\u003Ch2>キャッシュの問題——AIと一緒にデバッグ\u003C/h2>\n\u003Cp>サイト運用で実際にハマった問題を一つ紹介します。\u003C/p>\n\u003Cp>ブログ記事を新しく追加したのに、\u003Cstrong>一覧ページに表示されない\u003C/strong>。あれ？と思ってWordPress側を確認すると、記事はちゃんと存在している。\u003C/p>\n\u003Cp>原因は、第3回で設計した\u003Cstrong>キャッシュ（データの一時保存）\u003C/strong>でした。サーバーが古いデータを保存したまま使い続けていて、新しい記事が反映されていなかったんです。\u003C/p>\n\u003Cp>この問題をAIに「こういう状況なんだけど、原因は何だと思う？」と相談したら、「キャッシュが残っている可能性が高い」「キャッシュの保存場所はここ」「削除コマンドはこう」と、すぐに的確な回答が返ってきました。\u003C/p>\n\u003Cp>一人で悩んだら数時間かかったかもしれない問題が、\u003Cstrong>AIとの会話で10分かからず解決\u003C/strong>。こういう場面では本当に助かります。\u003C/p>\n\u003Ch2>GitHub Actionsで自動デプロイ——フロントもバックも\u003C/h2>\n\u003Cp>デプロイ（サイトの公開・更新）は、GitHub Actions（コードの変更をきっかけに自動で処理を実行する仕組み）を使って自動化しています。\u003C/p>\n\u003Cp>このサイトはフロントエンド（Nuxt）とバックエンド（WordPress）が分かれた構成なので、\u003Cstrong>デプロイも2本立て\u003C/strong>です。\u003C/p>\n\u003Ch3>フロントエンド（Nuxt → VPS）\u003C/h3>\n\u003Cp>フロントエンド側のコードを変更してmainブランチに送ると、自動で——\u003C/p>\n\u003Col>\n\u003Cli>Nuxtアプリをビルド（動く形に組み立てる）\u003C/li>\n\u003Cli>SSH経由でVPS（自分のサーバー）にファイルを転送\u003C/li>\n\u003Cli>サーバー上でアプリを再起動\u003C/li>\n\u003C/ol>\n\u003Cp>——という流れが走ります。\u003C/p>\n\u003Ch3>バックエンド（WordPressテーマ → レンタルサーバー）\u003C/h3>\n\u003Cp>バックエンド側（WordPressのカスタムテーマ）を変更した場合は、別のワークフローが動きます。こちらはFTP経由でレンタルサーバーにテーマファイルを転送する仕組みです。\u003C/p>\n\u003Cp>ポイントは、\u003Cstrong>変更のあったファイルに応じて必要なワークフローだけが自動で実行される\u003C/strong>こと。フロントエンドだけ変えたのにバックエンドもデプロイされる、ということがありません。GitHub Actionsの\u003Ccode>paths\u003C/code>フィルタを使って、関連するディレクトリが変更されたときだけ実行するよう設定しています。\u003C/p>\n\u003Cp>これらのワークフローの初期版は、AIに書いてもらいました。「Nuxtをビルドして、VPSにデプロイするGitHub Actionsを書いて」「WordPressテーマをFTPでデプロイするワークフローも」と依頼すると、それぞれほぼ動くものが出てきます。\u003C/p>\n\u003Cp>ただし、\u003Cstrong>セキュリティに関わる部分は自分で確認\u003C/strong>しました。SSH鍵（サーバー接続用の暗号鍵）やFTPの認証情報、秘密情報の扱いは、AIの提案をそのまま使うのではなく、一つ一つ自分で理解した上で設定しています。\u003C/p>\n\u003Ch2>テスト——計画以上の結果が出た\u003C/h2>\n\u003Cp>テストフェーズでは、PMがテスト専門の4名チーム——「ビルド検証担当」「コード品質チェック担当」「ユニットテスト担当」「コンポーネントテスト担当」——を編成しました。これも第2回で紹介した\u003Cstrong>「フェーズの内容に応じてチーム編成を変える」\u003C/strong>パターンです。\u003C/p>\n\u003Cp>結果は——\u003C/p>\n\u003Cul>\n\u003Cli>ユーティリティ、Composable、サーバーAPI、コンポーネントの\u003Cstrong>全テストがパス\u003C/strong>\u003C/li>\n\u003Cli>TypeScript型チェック: テストチームが型エラーを洗い出して修正し、\u003Cstrong>エラー0件\u003C/strong>に\u003C/li>\n\u003Cli>ESLintの指摘も\u003Cstrong>全件解消\u003C/strong>\u003C/li>\n\u003Cli>ビルド: 成功\u003C/li>\n\u003C/ul>\n\u003Cp>当初の計画ではテストの目標数値までは決めていなかったので、ここまでしっかりした結果が出たのは想定以上でした。\u003Cstrong>テスト専門のチームを組んだことで、「テストも書かなきゃ」というプレッシャーから解放され、テスト自体の質も上がった\u003C/strong>と感じています。\u003C/p>\n\u003Ch2>「人間が気をつける」ではなく「仕組みで防ぐ」\u003C/h2>\n\u003Cp>品質管理で一番大事だと思っているのは、\u003Cstrong>「人間が毎回注意する」のではなく「仕組みとして防ぐ」\u003C/strong>ことです。\u003C/p>\n\u003Cp>人間の注意力には限界があります。「気をつけよう」と思っていても、忙しいときは忘れる。だから、仕組みに落とし込む。\u003C/p>\n\u003Cp>このプロジェクトでAIと一緒に作った「仕組み」の例——\u003C/p>\n\u003Cul>\n\u003Cli>\u003Cstrong>TypeScript厳格モード\u003C/strong>: 型のミスはコードを書いた時点で検出される\u003C/li>\n\u003Cli>\u003Cstrong>ESLint（コード品質チェックツール）\u003C/strong>: コードの書き方を自動で統一\u003C/li>\n\u003Cli>\u003Cstrong>構造化データの自動生成\u003C/strong>: SEO用のデータをプログラムで生成して、手書きミスを防止\u003C/li>\n\u003Cli>\u003Cstrong>OGP画像の自動生成\u003C/strong>: SNSでシェアされたときの画像を、記事タイトルから自動で作成\u003C/li>\n\u003C/ul>\n\u003Cp>こうした仕組みは、最初に作るのに手間がかかります。でも、\u003Cstrong>AIがあればその初期コストが大幅に下がる\u003C/strong>。\u003C/p>\n\u003Cp>これ、実はAI協働の「隠れた大きなメリット」だと思っています。今まで「やったほうがいいけど、手間がかかるから後回し」にしていたことを、AIの力で「じゃあやろう」に変えられるんです。\u003C/p>\n\u003Ch2>本番運用でもAIと一緒に\u003C/h2>\n\u003Cp>サイトを公開した後も、AI協働は続いています。\u003C/p>\n\u003Cul>\n\u003Cli>\u003Cstrong>バグの修正\u003C/strong>: エラーの内容をAIに見せて、原因を一緒に特定\u003C/li>\n\u003Cli>\u003Cstrong>見た目の微調整\u003C/strong>: 「ここの余白が気になる」→ AIにCSS修正を依頼\u003C/li>\n\u003Cli>\u003Cstrong>新しい記事の追加\u003C/strong>: WordPress投稿 → キャッシュクリア → 表示確認\u003C/li>\n\u003C/ul>\n\u003Cp>特に「すぐ直したいバグ」があるとき、サッとAIに相談して修正案をもらえるのは、\u003Cstrong>フリーランスの一人運用で大きな安心感\u003C/strong>になります。\u003C/p>\n\u003Ch2>まとめ——一人でも「チーム体制」を作れる\u003C/h2>\n\u003Cp>品質管理のポイントをまとめます。\u003C/p>\n\u003Cul>\n\u003Cli>\u003Cstrong>コードレビュー\u003C/strong>: Agent Teamsの実装/確認ペアで、書いた時点で自動的にチェックが入る\u003C/li>\n\u003Cli>\u003Cstrong>問題解決\u003C/strong>: 状況をAIに説明すれば、一人で悩む時間が激減\u003C/li>\n\u003Cli>\u003Cstrong>自動化\u003C/strong>: AIが骨組みを作って、人間がセキュリティを確認・調整\u003C/li>\n\u003Cli>\u003Cstrong>仕組み化\u003C/strong>: AIのおかげで初期構築コストが下がり、後回しにしがちなことも実現できる\u003C/li>\n\u003C/ul>\n\u003Cp>\u003Cstrong>一人開発でも、Agent Teamsで「人間 → PM → 実装/確認」の体制を組めば、品質管理の仕組みが自然と回る。\u003C/strong>これはAI時代ならではの大きな恩恵です。\u003C/p>\n\u003Cp>次回はいよいよ最終回。このプロジェクト全体を振り返りつつ、「AI時代のエンジニアってどうなっていくの？」というテーマでお話しします。\u003C/p>\n","",[19],{"id":20,"name":21,"slug":22},44,"技術深掘り","deep-dive",[24,28,32],{"id":25,"name":26,"slug":27},78,"AI協働","ai-collaboration",{"id":29,"name":30,"slug":31},20,"Nuxt","nuxt",{"id":33,"name":34,"slug":35},39,"パフォーマンス","performance","intermediate","品質は「気をつける」ではなく「仕組みで防ぐ」。AIで構築コストが下がった分、後回しにしがちな自動化も実現できる。","7",[],[41,70,95],{"id":42,"slug":43,"title":44,"date":45,"excerpt":46,"thumbnail":17,"categories":47,"tags":49,"difficulty":67,"tldr":68,"readingTime":69},254,"ai-markup-horizontal-expansion","AIエージェントが一番確実に活躍できるフロントエンドの仕事 — マークアップの横展開","2026-03-25T19:01:28","AIにコードを書かせる場面は増えてきました。ただ、「結局どこに使うのが一番効くの？」という問いに対して、まだ手探りの方も多いんじゃないかと思います。 自分はフリーランスのフロントエンドエンジニアとして、日常的にAIエージ […]",[48],{"id":20,"name":21,"slug":22},[50,51,55,59,63],{"id":25,"name":26,"slug":27},{"id":52,"name":53,"slug":54},81,"Claude Code","claude-code",{"id":56,"name":57,"slug":58},84,"フロントエンド","%e3%83%95%e3%83%ad%e3%83%b3%e3%83%88%e3%82%a8%e3%83%b3%e3%83%89",{"id":60,"name":61,"slug":62},85,"マークアップ","%e3%83%9e%e3%83%bc%e3%82%af%e3%82%a2%e3%83%83%e3%83%97",{"id":64,"name":65,"slug":66},86,"実務","%e5%ae%9f%e5%8b%99","beginner","フロントエンドの実務でAIエージェントが最も確実に力を発揮するのはマークアップの横展開。レイアウトパターンごとに数ページ人間が作り、残りをAIに任せると圧倒的に速い。完璧ではないが、単純作業の負担を大幅に減らせる。","6",{"id":71,"slug":72,"title":73,"date":74,"excerpt":75,"thumbnail":17,"categories":76,"tags":78,"difficulty":36,"tldr":93,"readingTime":94},252,"wordpress%e3%83%90%e3%83%83%e3%82%af%e3%82%a8%e3%83%b3%e3%83%89%e3%82%92ai%e3%81%ab%e5%85%a8%e4%bb%bb%e3%81%9b%e3%81%97%e3%81%a6%e3%81%bf%e3%81%9f-%e6%84%9f%e6%80%a7%e3%81%8c%e8%a6%81","WordPressバックエンドをAIに全任せしてみた — 感性が要らない領域こそAI向きなのか検証する","2026-03-15T02:38:53","WordPressのバックエンド——カスタム投稿タイプの定義、REST APIの設計、管理画面のカスタマイズ。こうした作業は、仕様が明確でパターン化しやすい。 前回までの連載で「デザインやアニメーションなど、人間の感性に […]",[77],{"id":20,"name":21,"slug":22},[79,80,81,85,89],{"id":25,"name":26,"slug":27},{"id":52,"name":53,"slug":54},{"id":82,"name":83,"slug":84},82,"PHP","php",{"id":86,"name":87,"slug":88},83,"REST API","rest-api",{"id":90,"name":91,"slug":92},31,"WordPress","wordpress","ポートフォリオサイトのWordPressバックエンド（テーマ・REST API・管理画面）をAIに全任せで実装。定型的なバックエンド作業はAIの得意領域だが、実際に使い始めると「キー名の不一致」「運用を想定していない設計」など、細かい修正が必要になる場面があった。","8",{"id":96,"slug":97,"title":98,"date":99,"excerpt":100,"thumbnail":17,"categories":101,"tags":103,"difficulty":36,"tldr":113,"readingTime":38},112,"free-spam-protection-turnstile-honeypot","お問い合わせフォームのスパム対策を無料で実装する — Cloudflare Turnstile × ハニーポットの2層防御","2026-02-28T02:12:59","お問い合わせフォームのスパム対策、後回しにしていませんか？Cloudflare Turnstileとハニーポットを組み合わせた2層防御を完全無料で実装する方法を、本番環境でのハマりポイントも含めて解説します。",[102],{"id":20,"name":21,"slug":22},[104,105,109],{"id":29,"name":30,"slug":31},{"id":106,"name":107,"slug":108},26,"TypeScript","typescript",{"id":110,"name":111,"slug":112},80,"セキュリティ","security","Cloudflare Turnstile（無料）とハニーポットの2層防御でお問い合わせフォームのスパム対策を実装。本番環境ではNitroが.envを読まない問題やPM2の環境変数反映に注意が必要。",{"slug":115,"title":116,"thumbnail":17},"ai-web-dev-05-design-and-animation","【AI×Web制作 #5】人間の感性 × AIの実装力 — デザイン・演出編",{"slug":118,"title":119,"thumbnail":17},"ai-web-dev-07-future-engineer","【AI×Web制作 #7】AI時代のエンジニア像 — これからの開発スタイル"]