はじめに — 通常とは逆の開発フロー
Webツールの開発フローといえば、まずブラウザで動くUIを作り、その裏側にAPIを実装する——というのが一般的な順序です。フォームを設計し、バリデーションを組み、APIを呼び出して結果を表示する。UI起点の開発フローは多くの開発者にとって自然な発想でしょう。
しかしZERONOVA LABでは、ここ数週間の開発を通じて、まったく逆のパターンが定着していました。
API先行・Web UI後追い。先にAPI routeを作り、それをMCP Serverでラップし、最後にブラウザ向けのWeb UIを載せる。この順序が「たまたまそうなった」のではなく、品質とスピードの両面で合理的だったという話です。
MCP Server開発の全体像は「MCP Server開発記 — 82ツールのWeb検査を16コマンドに凝縮した設計判断」で書きました。本記事では、そこから派生した開発パターンの発見に焦点を当てます。
きっかけ — ギャップ分析で見えた「APIはあるのにUIがない」問題
発見のきっかけは、MCP ServerのTier 1ツールとWeb UIページの対応関係を精査したことでした。
ZERONOVA LABのコンセプトは「無料ツールとして公開 → MCP Serverで AIエージェントにも提供」。ブラウザで人間が使えるツールと、AIエージェントがMCPプロトコルで使えるツールを、同じAPI routeの上に載せる二面構造です。
ギャップ分析の結果、2つのツールにズレが見つかりました。security-headers-checkerとsite-config-checkerです。どちらもAPI routeは存在し、MCP ServerのTier 1ツールとして動作している。しかしブラウザ向けのWeb UIページが未実装でした。
開発日記にはこう書きました。
MCP Server（
zeronova-lab-mcp）の Tier 1 ツール 8 つと Web API ルートの対応を確認。security-headers-checkerとsite-config-checkerの API route は存在するが Web UI ページが未実装であることを特定
API routeだけあってWeb UIがないのは、ZERONOVA LABのコンセプトに反します。ユーザーがブラウザで体験し、その価値を実感してからMCP Server経由で自動化する——この導線が成り立たない。Phase 19.8として、Web UI追加を優先度P0に設定しました。
API仕様が「すでに固まっている」という利点
ここで気づいたのは、Web UI実装の異常なスムーズさでした。
通常、新しいツールを一から作る場合、APIの入出力設計から始めます。「何をリクエストパラメータにするか」「レスポンスのJSON構造をどうするか」「エラーハンドリングはどう返すか」。APIの仕様が曖昧なまま進むと、フロントエンド側で「APIの返り値が変わった」「このフィールドが必要だった」といった手戻りが頻発します。
しかし今回は違いました。API routeはMCP Server開発の過程ですでに実装・テスト済みです。リクエストパラメータは確定し、レスポンスのJSON構造も型定義があり、エラーハンドリングも実装されている。SSRF対策もredirect: manualとホップ毎検証で堅牢化済み。
Web UI側がやるべきことは明確でした。
- URLの入力フォームを作る
- API routeを呼び出す
- 返ってきたJSONを見やすく表示する
API仕様の設計や試行錯誤が不要なため、フロントエンドの実装に集中できます。この体験は、典型的な「UI first → API later」の開発フローとは対照的でした。
Phase 19.8 — セキュリティヘッダーとサイト設定の2ツール
セキュリティヘッダーチェッカー
最初に取りかかったのはセキュリティヘッダーチェッカーです。HTTP セキュリティヘッダー6項目（X-Content-Type-Options、X-Frame-Options、Content-Security-Policy、Strict-Transport-Security、Referrer-Policy、Permissions-Policy）を検査し、100点満点でスコアリングします。
APIのレスポンスには各ヘッダーの存在有無と値がすでに含まれていたので、Web UI側はスコアの可視化に集中できました。ページ速度チェッカーで使っていたSVGリングのパターンを踏襲し、スコアに応じた色分け表示を実装。検査結果は重要度順（fail → warn → pass）にソートし、アセスメントバナーでスコア帯別のメッセージを表示しました。
サイト設定チェッカー
次はサイト設定チェッカー。ドメインのrobots.txtとsitemap.xmlを検証するツールです。
統合カード UI（robots.txt + sitemap を 1 枚に集約、アセスメントバナー付き）。robots.txt 内容の折りたたみ表示。未設定ファイルがあれば関連ツール（robots.txt ジェネレーター・サイトマップ XML ジェネレーター）へのリンクを表示
最初は robots.txt と sitemap.xml を別々のカードに分ける案もありましたが、ユーザーにとって「サイト設定の全体像」を一画面で把握できることが重要と判断し、1枚の統合カードにまとめました。未設定のファイルがあれば、ZERONOVA LABのrobots.txtジェネレーターやサイトマップXMLジェネレーターへの導線を表示する設計です。
ガイドライン準拠チェックで見つかった問題
2ツールの実装後、docs/tools-dev-guidelines.mdのセキュリティチェックリストで準拠確認を行いました。「SEO監査の手動チェック項目をゼロにした話」で紹介した5段階レビュープロセスの一環です。
ここで2つの問題が見つかりました。
1つ目は、site-config-checkerのrobots.txtフェッチ方法です。response.text()でレスポンス全体をメモリに展開していましたが、悪意のあるサーバーが巨大なrobots.txtを返すとメモリ枯渇攻撃が可能です。ガイドラインの教訓に従い、ReadableStreamに変更して512KBのサイズ制限を追加しました。
2つ目は、security-headers-checkerのレスポンスボディです。セキュリティヘッダーの検査にはHTTPヘッダーだけが必要で、HTMLボディは不要です。しかしGETリクエストではボディも受信してしまいます。response.body?.cancel()で明示的にキャンセルし、リソースを解放する処理を追加しました。
過去の開発で体系化した教訓が、新しいツール開発で実際に問題を防いでくれた瞬間でした。
Phase 19.9 — 4ツール一括開発で見えたパターンの確かさ
Phase 19.8の成功を受けて、Phase 19.9では4ツールを一括で開発しました。MCP Server Phase 3.5で計画していたSEO検査ツールのWeb UI実装です。
- キャッシュヘッダーチェッカー: Cache-Control、ETag、Last-Modifiedなど7項目を解析し、ブラウザ/CDNキャッシュ状態をスコアリング
- 構造化データチェッカー: JSON-LD構造化データを抽出し、18スキーマタイプ別に必須/推奨プロパティを検証
- リダイレクトチェッカー: リダイレクトチェーンを最大10ホップまで追跡、ループ検知やHTTPS→HTTPダウングレード検知
- 画像最適化チェッカー: ページ内のimg要素を解析し、フォーマット・サイズ・lazy loading・srcset・width/height属性をスコアリング
4ツールすべてで、API routeの仕様はMCP Server開発の段階で確定済みでした。Phase 19.8と同じパターンです。Claude Codeにはフロントエンド実装を依頼し、APIのインターフェースに合わせたUIコンポーネントの構築に集中してもらいました。
5段階レビューで発見した4つのバグ
4ツールを実装した後、5段階レビュー（実装 → バグ修正 → UXレビュー → SEOレビュー → ガイドライン準拠チェック）を実施しました。
バグ修正段階で4件の不具合が見つかりました。schema-checkerのJSONパースエラー（不正なJSON-LDブロックをスキップする処理が抜けていた）、@graph配列の展開処理漏れ、redirect-checkerのフローチャート表示の分岐ミス、image-checkerの空src属性のスキップ処理漏れ。いずれも実データでテストして初めて発見されるタイプのバグです。
ガイドライン準拠チェックでは、redirect-checkerのタイムアウト設定が引っかかりました。
redirect-checker のタイムアウト 15s → 10s に修正（ガイドライン準拠）
初期実装では15秒に設定していましたが、ガイドラインでは外部URLフェッチのタイムアウト上限を10秒と定めています。redirect-checkerはリダイレクトチェーンを追跡すること自体が目的なので例外にしたい気持ちもありましたが、ガイドラインの一貫性を優先して10秒に修正しました。ルールを設けた以上、例外を許すとルールが形骸化します。
PM-AI対話 — APIファーストが自然に生まれた経緯
ZeronovaZeronovaこの対話は、Phase 19.8と19.9の開発を終えた時点で自然に行き着いた結論でした。
意図してAPIファーストを選んだわけではありません。MCP Serverの開発ニーズが先にあり、そのためにAPI routeを実装し、後から「同じAPIにWeb UIも載せられるよね」と気づいた。実践から発見したパターンです。
パターンの構造 — 4ステップの開発フロー
振り返ると、このパターンは以下の4ステップで構成されています。
ステップ1: MCP Server開発のニーズからAPI route作成。外部URLを検査するツール（OGPチェック、リンク切れチェック、セキュリティヘッダーチェックなど）のAPI routeを実装します。この段階でリクエストパラメータ、レスポンスJSON構造、エラーハンドリング、SSRF対策、Cache-Controlヘッダー、レート制限がすべて確定します。
ステップ2: MCP ServerがAPI routeをTier 1ツールとしてラップ。MCP SDKでツールとして登録し、AIエージェントから呼び出せるようにします。199件のテストスイートでAPIの動作が検証されます。
ステップ3: Web UIページを追加。仕様が確定済みのAPIに対して、ブラウザ向けのフォームと結果表示UIを実装します。API設計の試行錯誤は不要なので、UXの改善に集中できます。
ステップ4: 5段階レビューで品質を担保。実装 → バグ修正 → UXレビュー → SEOレビュー → ガイドライン準拠チェック。Phase 19.9ではこのプロセスで4件のフロントエンドバグと1件のガイドライン違反（タイムアウト値）を発見しました。
注目すべきは、ステップ3以降で発見されたバグがすべてフロントエンド側だった点です。API route自体のバグはゼロ。MCP Server開発の過程でAPIの品質がすでに担保されていたからです。
典型的なフローとの比較 — 何が逆転しているのか
典型的なWebツール開発は「UI起点」です。
- ユーザーが使うフォームを設計する
- フォームの入出力に合わせてAPIを設計する
- APIを実装する
- UIとAPIを結合する
このフローでは、UIの要件変更がAPIの設計変更を引き起こします。「この情報も表示したい」→「APIのレスポンスにフィールドを追加」→「バリデーションも変更」。UIとAPIが同時に変動するため、安定するまでに時間がかかります。
APIファーストのフローは逆です。
- MCP Serverの要件からAPIを設計・実装する
- テストスイートでAPIの品質を検証する
- 確定済みのAPIに対してUIを実装する
APIの仕様がステップ2の時点で「凍結」されているため、UIの実装中にAPIが変わることがありません。UIの設計変更はUI側だけで完結します。
ただし、これはすべてのケースで有効なパターンではありません。ZERONOVA LABの場合、MCP Serverという「APIの最初の顧客」が存在したことが前提条件です。APIの最初の顧客がAIエージェントであり、2番目の顧客がブラウザのWeb UIだった。この順序が成り立つ文脈があったからこそ、パターンとして機能しました。
88ツールの到達点と学び
Phase 19.9の完了で、ZERONOVA LABの無料ツールは88個に到達しました。うちSEO検査系ツールは12個。すべてブラウザで使えると同時に、MCP Server経由でAIエージェントからも利用可能です。
この開発を通じて得た学びを3つにまとめます。
1. 「APIの最初の顧客」がAIエージェントである場合、APIの品質が自然に高まる。AIエージェントはUIの曖昧さを許容しません。リクエストパラメータ、レスポンス構造、エラーハンドリング——すべてが型で定義され、テストで検証されます。その厳密さが、後から追加するWeb UIの開発を加速しました。
2. ガイドラインの体系化が「後追い開発」の品質を支える。Phase 19.8でrobots.txtフェッチのメモリ枯渇リスクを発見し、Phase 19.9でタイムアウト値のガイドライン違反を検出しました。どちらも過去の開発で教訓としてドキュメント化していたからこそ、新規ツール開発で同じ問題を再発させずに済みました。
3. バッチ開発 + 一括レビューが効率的。Phase 19.9では4ツールをまとめて実装し、5段階レビューを一括で実施しました。1ツールずつレビューするよりも、複数ツールをまたいだパターンの見落とし（共通のバグ、ガイドライン違反）が発見しやすくなります。
まとめ — 実践から発見するパターン
APIファースト開発は、最初から計画したものではありません。MCP Serverの開発ニーズがあり、APIを先に作る必然性があり、後からWeb UIを載せたら想像以上にスムーズだった。この実体験から「これはパターンとして使える」と気づきました。
PM（プロダクトマネージャー）として面白いのは、「誰が最初の顧客か」で開発の順序が変わるという点です。人間が最初の顧客ならUI起点、AIエージェントが最初の顧客ならAPI起点。2026年のWeb開発では、AIエージェントが「最初の顧客」になるケースが増えていくのではないかと考えています。
ZERONOVA LABでは今後も、「無料ツールとして公開 → MCP Serverで AIエージェントにも提供」の二面構造を続けていきます。APIファーストのパターンが、その両立を支える設計原則として機能し続けるかどうか。引き続き実験していきます。
Zeronova（ゼロノバ）
Product Manager / AI-Native Builder
Web/IT業界19年以上・20以上のWebサービスを担当したPdM。東証プライム上場企業の子会社代表として事業経営を経験。現在はAIを駆使して企画から実装まで完結させる個人開発を実践中。