CMSにAI自動化の機能を増やしたら、タイムアウトと戦うことになった

前回の記事からCMS管理画面の機能を中心に、思いつくものを片っ端から形にしてきました。元々WebメディアやSNSを運用していた経験があり、記事の作成・管理・SEOの面でWordPressにあったら便利だと思っていた機能を、実際にメディアを運用しながら次々に追加。X、noteの運用で欲しかった機能も合わせて実装しています。

作った機能

ざっと挙げるとこれだけあります。

• タイトル入り記事サムネイルの自動生成：タイトルから画像を生成し、AIZOMEのロゴと文字を焼き込むようにしています。以前はOpenAIの画像生成API(GPT Image)で画像生成だけを行なっていましたが、タイトルもサムネイルに含めたかったので、画像生成の後、タイトルを焼き込むようにしています。タイトルの改行については改善点はありますが、意味のある部分での区切りを持たせる仕組みも加えています。

• X投稿・note記事の下書き生成機能：自社メディアの展開だけでは流入が限られるため、SNSも同時展開しています。Xの自動投稿機能はありましたが、Xの記事機能やnoteのようなブログ向けの投稿も記事本文から生成できるようにしています。

• 用語集：このメディアは経営者向けであり、開発者向けではありません。そのため、専門的な用語で躓くことがないように用語の説明を記事内からすぐに見られるようにしました。また、用語集自体もSEOの意味もあります。用語集は検索・50音インデックス、トップページの注目用語ランキングまで合わせて作成しました。

• スケジュール管理：一連のリリースで私が最も力を入れたのはここです。メディア運用で面倒なのがスケジュール管理です。複数のライターがいるようなメディアでは、かなりのリソースが記事の作成・公開管理に割かれています。管理画面上で、いつ公開予定の記事があり、現在どのような状態か、完パケしているのか、などステータス管理できるようになっています。XやnoteといったSNSの投稿管理も合わせておこなうことができ、どの記事は投稿済みか否か、すぐに確認できるようになっています。

• PageSpeed Insights対応：機能ではないですが、SEOを意識してPageSpeed Insightsのスコアを上げにいきました。サムネイル圧縮とフォント自己ホスト化で、モバイルのPerformanceスコアが58から96〜99まで上がりました。

PageSpeed対応を除けば、これらの機能は基本的にAI駆動です。機能が増えるほどAIへの依頼も増え、依頼が増えるほど、ある問題に何度も引っかかることになりました。

機能を増やすたびに、タイムアウトと戦った

前回の記事にあったようにホスティング先としてAWS AmplifyAWS AmplifyAWS Amplifyは、Webやモバイルアプリの開発・公開をコード量少なく実現できるAmazonのクラウドサービス群。認証やデータベース、ホスティングなどの機能をまとめて提供し、専門知識が浅くてもアプリを短期間で立ち上げられる。経営視点では、外注コストや開発期間を抑えて自社サービスやDXの試作を素早く始められる点が価値となる。詳しく見る →を採用しましたが、Amplify Hostingの約30秒のプロキシタイムアウトは、前回の記事の時点でも把握していた制約でした。ただ、機能が増えるにつれて、この壁に当たる頻度は明らかに上がっていきました。

ニュースの自動収集ではRSS取得自体が固まってしまい、ハードタイムアウトを追加しました。AI下書き生成がタイムアウトする不具合には、応急的な復元手段で対応。用語集のAI生成は2段階、さらに3段階に分割し、モデルも切り替えて生成時間を縮めました。タイトルから画像を作るサムネイル生成は1回のリクエストに収まらなくなり、2段階に分割。それでもタイムアウトすることがあるため、裏側で処理が完了しているかを自動確認するポーリングまで追加しました。

しかし、同じ理由の修正が何度も出てくるのは、根本原因が一つだからです。機能を追加するたびに「これも30秒に収まるか」を考え、収まらなければ分割するかポーリングで誤魔化す。本当に動いているのかもわからないUXに、さすがに限界を感じ始めていました。

限界を迎えた機能「URLからの記事下書き生成」

止めを刺したのは、一次情報のURLを入力すると、その情報や周辺情報を踏まえてAIが記事下書きを生成する機能でした。

一次情報を読み込んでから書くぶん、単純なキーワード生成より時間がかかります。追加した直後、「URL入力時のAI下書き生成が応答を受け取れない」という不具合が発生しました。分割やポーリングでその場をしのぐことはできても、機能を追加するたびに同じパターンの対症療法を書くのは、もう限界を迎えていました。

AmplifyからVercelへ移行した

VercelVercel(バーセル)Vercelは、Webサイトやアプリを簡単に公開・運用できるクラウド開発プラットフォーム。コードを更新すると自動で配信環境に反映され、インフラ管理の負担を減らせる。近年はAIアプリ開発向けの機能も拡充しており、少人数でも高速にサービスを立ち上げられる点が経営面で注目される。詳しく見る →は最初のホスティング選定でも候補に挙がっていましたが、無料プランが非商用限定だったため外していました。有料にはなりますが、Proプランを使うとこの制約も問題になりません。加えて、Vercelは最大実行時間を800秒まで設定できます。30秒でのタイムアウトという壁そのものが、根本からなくなります。

AWSを選んだのはコストではなく拡張性のためでした。ところが実際に運用して足かせになったのは、その拡張性ではなく、日常的に使う機能を安定して動かせるかどうか。選定の時点では見えていなかった部分です。

検証してから切り替えた

いきなり本番を切り替えるのではなく、別のVercelプロジェクトを作ってプレビュー環境で先に検証しました。見たかったのは、直前まで詰まっていたURLからの記事下書き生成が最後まで完了するかどうか。そして、他の機能もすべて問題なく動くかどうか。どちらも問題なしとわかったところで、mainにマージしてDNSを切り替えました。詰まっていた機能が動くようになった瞬間、移行の判断が正しかったと実感できました。

メディアの運用という面では、だいぶストレスのない状態になってきました。今後は、AI経営を広げていけるようなコンテンツの拡充や、経営者がAI動向を追いやすくなるニュース記事の充実に取り組んでいきます。