【ITニュース解説】The same AI build went from 30 minutes to 4 — here's what we changed in our MCP server

ウェブサイトを自動で構築するAIの進化は目覚ましく、その裏側では開発者が試行錯誤を続けている。あるシステムでは、AIがウェブサイトを構築する時間が、当初の30分からわずか4分にまで大幅に短縮された事例があった。これは、単なるAIへの指示の改善だけでなく、システムの根幹に関わる部分を見直した結果生まれた成果である。

このシステムは、AIモデル（例えばClaudeのようなもの）に完成したHTMLページを与えると、それを元に、ヘッドライン、リンク、画像など、サイトの各要素が個別に編集可能な「コンポーネント駆動型」のウェブサイトを自動生成するというものだった。このようなAIによる自動構築は非常に便利だが、開発チームが実際にその構築にかかる時間を計測してみると、予期せぬ問題が明らかになった。

最初の段階では、サイトの構築に約30分かかっていた。そこで、AIへの指示（プロンプト）を見直し、無駄な手順を削減することで、構築時間を14分にまで短縮することに成功した。これは一見大きな進歩に見えたが、その14分の内訳を詳しく分析すると、驚くべき事実が判明した。サイトの実際の構築、つまり15個のコンポーネント、レイアウト、ページをまとめて構成する作業自体にかかる時間はわずか3分40秒だったのだ。残りの10分間は、たった5枚の画像を処理するために費やされていた。これら5枚の画像の合計サイズはわずか14キロバイトという非常に小さいものだったにもかかわらず、サイト全体の構築時間の約3倍もの時間を要していたのである。これは単に遅いステップというだけでなく、システムの設計そのものに根本的な欠陥があることを示していた。AIへの指示をどれだけ工夫しても、この問題は解決できなかった。

なぜこれほどまでに画像の処理が遅かったのか。ネットワークの速度やストレージの性能が原因だと考えるのが普通だが、実はどちらも違った。原因はAIモデルそのものにあったのだ。AIがツールを使ってファイルをアップロードする際、画像データは「Base64」という形式のテキストに変換されてやり取りされていた。Base64は、画像のようなバイナリデータを、コンピュータが扱える文字の羅列に変換する方式である。このBase64形式のテキストを、AIモデルが「トークン」と呼ばれる単位で一つずつ生成（タイピングアウト）していたのだ。例えば、5キロバイトの小さな画像でも、約7000文字ものBase64テキストになり、AIがこれを一つずつ慎重に生成するのに膨大な時間がかかっていたのである。ウェブサイトを管理するCMS自体が遅いのではなく、AIが画像データを文字として一生懸命「綴っている」ことがアップロードの遅延につながっていた。

さらに、このBase64によるデータ転送は、デバッグが難しい脆弱性も抱えていた。テスト中に、転送されたBase64の文字が途中で一部欠損し、ファイルが破損するエラーが発生したのだ。これは、通信の問題としてすぐに検出されるのではなく、もっと後の段階で「ファイル破損エラー」として現れるため、根本原因の特定を困難にしていた。

もう一つの問題は、API（アプリケーション・プログラミング・インターフェース、異なるソフトウェアが互いに通信するための仕組み）の応答が過剰に「おしゃべり」だったことだ。書き込み操作を行うたびに、保存したレコード全体の詳細が応答として返されていた。例えば、11個の要素を持つページを保存すると、各要素の完全なコンポーネント定義（テンプレート、CSS、JavaScript、フォームの構成など）が、その要素の数だけ繰り返して返送されていた。これは、約55キロバイトものJSONデータが無駄に送り返されていることを意味した。呼び出し元が送ったばかりのデータを、APIがそのまま返すというのは、AIが自分自身に話しかけているようなもので、構築プロセス全体で見ると、AIへの指示よりも、この無駄な通信にかかるトークンコスト（AIの処理費用）がはるかに大きくなっていた。

これらの問題を解決するために、システムはプロトコルレベルで2つの変更を行った。

1. 画像のインライン取り込み: 画像をBase64テキストとしてAIに処理させるのをやめ、代わりに画像ファイルのURLを要素データに直接含めるように変更した。例えば、"image": { "sourceUrl": "https://example.com/studio.jpg" }のように指定する。これにより、サーバーがそのURLから画像を直接取得し、保存して、実際のファイルIDをコンテンツに置き換える。この一連の作業は、ページを保存するのと同じ一度の処理で完結するため、Base64への変換も、個別のアップロード手順も不要になった。画像データはAIモデルを一切介さずに処理されるため、AIが画像を「タイピング」する時間は完全にゼロになったのである。

2. API応答の簡素化: 書き込みを行うAPIツールに、オプションでverbose: falseという設定を追加した。この設定を有効にすると、APIは書き込みが成功した際に、{"id": 53}のような最小限の情報のみを返すようになる。ページやレイアウトを保存する場合でも、呼び出し元が自身では判断できない要素IDのマッピング情報だけを返し、それ以外の冗長なコンポーネント定義は返さなくなった。これにより、数キロバイトにも及んでいたAPI応答が、わずかなデータ量で済むようになった。既存のシステムが影響を受けないよう、この設定はデフォルトではtrue（以前と同じ詳細な応答）になっている。

これらの変更によって、システムの性能は劇的に改善された。同じページ、同じコンポーネント、同じ5枚の画像を構築するのにかかる時間は、当初の約30分、プロンプト改善後の約14分から、わずか4分0秒にまで短縮された。画像処理にかかっていた約10分間のフェーズは完全に消滅し、ページ保存の一部として統合された。また、AIが処理するトークン数は約22万5000から約4万へと激減し、約85%のコスト削減につながった。ツールの呼び出し回数も減少し、結果として、サイト構築の費用は約6倍も安くなった。

この事例から得られる重要な教訓は、AIツールを開発する者にとって非常に価値がある。AIへの指示（プロンプト）をどれだけ丁寧に整えても、その改善には限界がある。最終的に残るパフォーマンスのボトルネックやコストの大部分は、AIの指示そのものよりも、APIの設計やデータのやり取りの「形」（プロトコルレベル）に起因することがほとんどだという点だ。今回の改善は、無駄なステップを高速化するのではなく、画像処理という一つのフェーズそのものを削除することで達成された。これにより、「空のページを作成 → 5枚のファイルをアップロード → 全てを書き戻す」という一連のプロセスが、画像URLを含んだまま一回の保存で完了できるようになったのだ。

今回の変更は、AIを使ってウェブサイトを構築するユーザーにも大きなメリットをもたらした。まず、AIの実行コストが大幅に削減された。標準的なページ構築でのトークン使用量が約85%も減少したため、ウェブサイトやテンプレート、テストスイートなどを頻繁に構築する場合でも、費用を気にせず、より多くの実験や日常的な運用が可能になった。また、コンテンツが破損するリスクも軽減された。以前の画像ワークフローでは、一度保存したコンテンツに対して画像を紐付けるための二度目の書き込みが必要だったが、これは誤ってページのテキストを消去してしまうような「サイレントな失敗」を引き起こす可能性があった。画像のインライン取り込みにより、この二度目の書き込みが不要になったため、このようなリスクが根本的に排除された。さらに、この新機能は既存の様々なシステムと連携しやすい。インライン取り込みで指定するsourceUrlには、クライアントが既に持っているメディアライブラリのURL、CDN（コンテンツ配信ネットワーク）上のURL、AIが生成した画像のURL、あるいはNeletoサーバー内に既に存在するファイルのURLなど、サーバーがアクセスできるあらゆるURLを使用できる。

ただし、いくつかの注意点もある。画像のインライン取り込みを利用するには、サーバーがそのURLにアクセスできる必要がある。もし画像が個人のPCにしかない場合は、まずどこかインターネット上にホスティングする必要がある。Base64形式でのアップロード経路はまだ存在し、数キロバイト程度の小さなファイルであれば問題なく利用できるが、大容量のファイルでは性能が低下する。また、テスト中に、Neletoサーバーの既存APIで、ファイルURLをそのまま要求するとエラーになるという問題が発見された。これは現在修正中だが、一時的な回避策として、画像サイズ調整などのオプション指定をURLに追加する必要がある。

そして、今回の件で画像とは直接関係ないが、重要な教訓が一つある。それは、データの内容を変更するような「行動レベルの変更」は、AIエージェントに即座に反映されるのに対し、APIのデータ形式（スキーマ）を変更するような場合は、クライアント側が再度接続し直さないと反映されないという点である。システムを開発する際には、このような変更の反映タイミングを考慮して計画を立てる必要がある。

今回の改善はすでに実施されており、Neletoサーバーに接続しているユーザーは、すぐにこの新しい機能を利用できる。画像URLを直接要素データに記述するだけで、これまで時間を要していた画像のアップロードフェーズが完全に無くなるのを体験できる。これは、AIを活用したネイティブなシステム開発において、効率的でコストのかからないワークフローを実現するための重要な一歩となるだろう。