【ITニュース解説】How AI Is Actually Changing Web Agency Workflows: The Honest Developer's Breakdown

AIがWeb制作の現場にどのような変化をもたらしているのか、その実態について解説する。よく言われるような「AIがあらゆるものを革命的に変える」といった単純な話ではない。AIが開発者の仕事を完全に奪うわけではなく、むしろ開発者の時間の使い方、価値のあるスキルの種類、そしてWeb制作会社がクライアントにサービスを提供する流れ（デリバリーパイプライン）を根本的に再構築している。意図的にAIツールを導入していなくても、プロとしてクライアントの案件に携わっているなら、すでにこれらの変化の影響を受けている可能性が高い。

AIの導入が実際に作業の流れ（ワークフロー）を改善している具体的な場面をいくつか見ていこう。

まず「コンテンツインテリジェンスパイプライン」という領域がある。これは、クライアントから渡される様々な形式のコンテンツ（Word文書、製品仕様書、古いブログ記事など）を、大規模言語モデル（LLM）を使って構造化された、そして検索エンジン最適化（SEO）に配慮した形式の出力へと変換するものである。以前は、開発者がこれらのばらばらなコンテンツを手作業で解析し、CMS（コンテンツ管理システム）に登録できる形に整えていた。しかし今では、AIに適切な指示（プロンプト）を与えることで、これらのコンテンツを直接CMSのコンテンツモデルにマッピングできるJSON形式で出力させることが可能になっている。

具体的には、あるクライアントの膨大なドキュメントをAIに処理させる例が挙げられる。プログラミング言語のLaravelを使ったジョブ（バックグラウンドで実行される処理）の中で、OpenAIのAPIを利用し、GPT-4oのようなLLMに「コンテンツ構造化アシスタントとして、生のテキストから構造化されたページコンテンツを抽出し、有効なJSONのみを返す」というシステムプロンプトと、具体的な抽出指示を含むユーザープロンプトを与える。この指示には、SEO最適化されたタイトル、メタディスクリプション、主要キーワード、そして見出し・段落・リストといった形式のコンテンツブロックの配列をJSONで出力するよう求める。ここで重要なのは、AIからの応答形式を「json_object」と指定することだ。これを指定しないと、AIは自由形式のテキストを返してしまう可能性があり、その結果、後続の処理が頻繁に失敗することになる。このようにして得られたJSONデータを、データベース内のページ情報として更新することで、コンテンツ作成の初期段階における労力を大幅に削減できる。

次に「自動コードレビューをCI（継続的インテグレーション）のステップとして組み込む」という活用法も広がっている。これは、開発者がコード変更を提出するプルリクエスト（PR）のプロセスにAIによるコードレビューを組み込むものだ。人間のレビュー担当者の代わりにAIがレビューするのではなく、シニア開発者の目に触れる前に、AIがまず最初の一歩として明らかな問題（セキュリティ上の脆弱性、N+1クエリ、バリデーションの漏れなど）を検出するフィルターとして機能させる。

GitHub Actionsのような自動化ツールを使い、プルリクエストが作成または更新されるたびにAIコードレビューを自動的に実行する設定が可能だ。変更されたPHPファイルの差分を取得し、その差分をOpenAIのAPIに送信する。この際、費用対効果を考慮して「gpt-4o-mini」のような比較的安価なモデルを使用することが推奨されている。AIには「セキュリティ問題、N+1クエリ、バリデーションの欠落について、簡潔かつ具体的に、本当に問題のある点だけを指摘せよ」という指示を与える。AIのレビュー結果はプルリクエストのコメントとして自動で投稿され、開発者は人間がレビューする前に潜在的な問題に気づき、修正できる。これにより、レビュープロセスの効率が向上し、品質の高いコードをより早く提供できるようになる。

しかし、AIの導入には誰もあまり話さないような問題点も存在する。その一つが「コンテキストウィンドウの負債」である。LLMは本質的にステートレス（状態を持たない）だ。つまり、リクエストごとにAIは前の会話を覚えておらず、毎回まっさらな状態から処理を開始する。これは一見当たり前のことだが、その影響は意外な形で現れる。例えば、AIアドバイザーを伴う多段階のオンボーディングウィザードのように、複数のユーザーインタラクションにまたがるAIアシスト機能を構築する場合、開発者は毎回のリクエストで、それまでの会話履歴を再構築してAIに渡す責任を負う。これは、会話履歴を保存し、AIのトークン制限（一度に処理できる情報の量）を超えないようにインテリジェントに切り詰めたり、どの情報を破棄しても安全かを判断したりする作業を伴う。

具体的なコード例では、ConversationContextManagerというクラスが、会話オブジェクトから最新のメッセージ履歴を取得し、システムプロンプトと合わせてAIに渡すメッセージの配列を構築する様子が示されている。このとき、メッセージの文字数からトークン数を概算し、設定された最大トークン数を超えないように古いメッセージから順に削除する処理が行われる。これは地味なインフラ作業だが、この処理が適切に行われないと、チャットボットは数回のやり取りで会話の流れを見失ってしまうことになる。

もう一つの問題は「クライアント向けコンテンツにおける生成への過度な依存」だ。AIが生成したコンテンツを、ドメイン知識を持つ専門家によるレビューなしにそのまま公開してしまうと、後になってSEO上の問題を引き起こす可能性がある。内容の薄いコンテンツ、画一的な表現、特定の技術分野における事実誤認などがよくある失敗例である。効果的なアプローチとしては、AIはコンテンツの構造化や下書き作成の段階で利用し、その後必ず人間のレビュー工程を挟んでから、制作CMSに反映させるという方法がある。これは完全に自動化されたパイプラインよりも時間はかかるが、検索パフォーマンスにおける品質の差は明確に測定できるレベルで現れる。

では、システムエンジニアとして今後どのようなスキルに時間を投資すべきだろうか。AIを導入したWeb制作会社のワークフローで最も価値が高まる領域は以下の通りである。

まず「構造化出力のためのプロンプトエンジニアリング」だ。これは、AIに意図した通りの形式で情報を出力させるための指示（プロンプト）を設計するスキルである。単に自由形式のテキストを解析するよりも、JSONモードや関数呼び出し、スキーマ強制といった機能を使って、AIに正確な構造のデータを生成させる技術が重要になる。

次に「検索拡張生成（RAG）」の理解だ。これは、クライアント固有の知識ベース（ドキュメント、データベースなど）をAIが参照できるように、情報を適切に分割（チャンク）、数値データに変換（エンベッド）、そして必要に応じて検索・取得する方法を知ることである。これにより、汎用的なLLMの出力をクライアントのビジネス文脈に沿った、より関連性の高いものにできる。

そして「AI呼び出しのための可観測性（Observability）」も重要だ。AI機能がサイレントに性能低下を起こした場合、それを診断するためには、AIへのリクエストの応答時間（レイテンシ）、使用されたトークン数、出力の品質といったメトリクスをログとして記録し、監視する能力が不可欠となる。

最後に「コストモデリング」だ。AIの利用には費用が発生するため、機能一つあたりのトリガーにかかるコストを正確に把握するスキルが必要となる。例えば、1回あたり0.002ドルの機能であれば問題ないが、0.40ドルかかる機能であれば、導入前に予算に関する議論が必要になる。

結論として、Web制作のワークフローにおけるAIは、単純なオン・オフのスイッチではない。それは慎重に計器を取り付けて監視し、調整していくべき対象だ。コンテンツ処理の効率化、コードレビューの補助、クライアント向けの対話型インターフェースなど、AIがもたらすメリットは確かにある。しかし同時に、コンテキストの不適切な管理、予期せぬコストの増大、数ヶ月後に分析でしか表面化しないコンテンツ品質の劣化といった失敗のリスクも現実のものとして存在する。

これらのツールを最大限に活用している開発者たちは、AIを使って全てのコードを書かせているわけではない。彼らは、決定論的なシステム（常に同じ結果を出すシステム）と確率論的なシステム（結果が変動する可能性があるシステム）の境界線を理解し、それに応じて適切なガードレール（安全装置や制約）を構築できる人々だ。

AI機能を開発・リリースする際には、他のインフラストラクチャをリリースするのと全く同じ方法で臨むべきである。つまり、適切なロギング（記録）、障害時のフォールバック（代替手段）、そして「あまりにも簡単に見えるもの」に対する健全な懐疑心を持って取り組むことが成功への鍵となる。