Astroのシステム開発の発注/外注/依頼/委託方法について

Astroのシステム開発を発注・外注するなら、Astroを採用すること自体ではなく、公開コンテンツを速く届ける部分と、ログイン・検索・予約などの動的機能をどこに分担させるかを先に決めることが重要です。

本記事では、Astroのシステムを外部へ依頼する企業担当者に向けて、発注形態の選び方、RFPと要件整理、契約形態、費用相場、委託先の選定、見積書の比較方法までを順番に解説します。既存WordPressからの移行や、公開後のCMS運用・保守まで含めて、失敗しにくい進め方を確認できます。

▼全体ガイドの記事
・Astroのシステム開発の完全ガイド

Astroのシステムを発注・外注する前に押さえる全体像

Astroは、企業サイト、サービスサイト、オウンドメディア、ドキュメントサイトなど、コンテンツを検索経由で届けるシステムと相性がよいWebフレームワークです。静的に生成したHTMLをCDNから配信し、必要な部分だけにJavaScriptを読み込むIslands Architectureが特徴ですが、CMSやデータベース、認証、監視までをAstroだけで完結させる製品ではありません。

会社情報、商品説明、導入事例、FAQ、ブログ記事など、閲覧者ごとの差が小さいページは、SSG（静的サイト生成）とCDN配信で構成しやすい領域です。一方、会員情報、在庫、予約枠、決済、個別のダッシュボードは、API、認証基盤、データベース、既存の基幹システムなどと連携して実装します。Astro側にReactやVueなどのUI部品を組み込むこともできますが、動的な業務処理がサイトの大半を占める場合は、Next.jsやNuxtなども含めて比較するのが安全です。

発注前に「表示速度を改善したい」「マーケターが記事を更新したい」「WordPressの保守負担を下げたい」「問い合わせや資料請求を増やしたい」など、事業上の目的を言語化します。Astroを指定しても、画像が重い、外部タグが多い、APIの応答が遅い、公開のたびに手作業が発生するといった設計では、期待した成果が出ません。要件と評価指標を先に置き、その達成手段としてAstroを検討すると、委託先の提案も比較しやすくなります。

Astroのシステムに適した発注形態を選ぶ方法

発注形態は、サイトの規模だけでなく、更新頻度、既存データの量、業務機能の複雑さ、社内に技術担当者がいるかで決まります。初期費用を抑えることだけを優先すると、移行や運用の追加費用が後から膨らむため、公開後の総保有コストまで見積もります。

ページ数が少ないコーポレートサイトやキャンペーンページで、独自の会員機能・複雑な検索・大量移行がない場合は、既存テンプレートや制作会社の標準パッケージを使う方法があります。画面と機能の範囲を早く確定できるため、短納期になりやすい一方、管理画面の細かな変更や将来の独自機能には制約が出ます。見積時には、テンプレート費用、デザイン調整、フォーム、解析タグ、公開後の修正回数がどこまで含まれるかを確認します。

記事やお知らせを社内で更新するなら、microCMS、ContentfulなどのヘッドレスCMSとAstroを組み合わせる構成が有力です。CMSは編集画面とコンテンツ管理を担当し、Astroは表示側を担当するため、デザイン変更と記事更新の責任を分けやすくなります。公開前プレビュー、承認フロー、予約公開、Webhookによる自動ビルド、SEOタイトルやディスクリプションの入力欄までRFPに書いておくと、単に「CMS連携」と書くより見積の差が小さくなります。

既存WordPressをヘッドレスCMSとして残し、表側だけAstroへ刷新する方法もあります。編集部門が慣れた管理画面を継続利用できる反面、WordPress本体・プラグイン・API・認証・バックアップを保守し続ける必要があります。完全移行する場合は、記事本文だけでなく、URL、画像、カテゴリ、著者、構造化データ、canonical、301リダイレクト、サイトマップまで対象にします。データが整理されていないサイトでは、移行作業が実装より長くなることもあります。

ログイン、権限管理、商品・顧客・予約データ、外部API、監査ログなどが必要なら、Astroの画面開発だけでなくバックエンドと運用基盤を含めて委託します。公開ページはAstroのSSG、個別表示はSSRやServer Islands、業務処理はAPIとデータベースという分担にすると、静的配信の利点を活かしながら機能を拡張できます。反対に、動的処理が中心なら、Astroを無理に採用する理由があるかを含めて提案を受けます。

Astroのシステム開発を発注・外注する進め方

発注は、いきなり制作会社へデザインを依頼するのではなく、現状把握、要件整理、提案比較、契約、設計・開発、移行、検収、運用開始の順に進めます。特にAstroでは、表示側の実装よりも「何をCMSで管理し、何をAPIから取得し、誰が公開を承認するか」の設計が品質と費用を左右します。

最初に、現行サイトのURL一覧、ページ数、記事数、画像容量、CMSの入力項目、フォーム、外部タグ、アクセス解析、サーバー、ドメイン、リダイレクトを整理します。WordPressからの移行では、公開中のURLを表計算などで一覧化し、移行後URL、ステータス、担当者、確認結果を記録できるようにします。

目的は「Astro化」だけにせず、自然検索からの流入、問い合わせ数、更新のリードタイム、Core Web Vitals、公開作業の工数など、測定可能なKPIへ置き換えます。microCMSのエイチームライフデザインの事例では、記事更新のリードタイムが7日から1日以下になったと紹介されていますが、最終的な移管完了には約14か月かかっています（出典: microCMS導入事例、2026年確認）。短期の制作期間だけでなく、移行後の運用改善まで成果として設計することが大切です。

RFPには、背景と目的、対象ページ、想定ユーザー、必要な機能、管理者の権限、CMSの入力項目、公開フロー、外部連携、移行対象、納期、予算、納品物、保守条件を記載します。機能要件だけではなく、表示速度の測定条件、アクセシビリティ、バックアップ、障害時の復旧目標、セキュリティ、ログ保存期間などの非機能要件も必要です。

例えば「速いサイトにする」ではなく、「代表ページをモバイル回線の実機で測定し、公開前後に同じ条件で比較する」「記事公開から反映までの目標時間を設定する」と書きます。「更新できる」ではなく、「マーケターがタイトル、ディスクリプション、OGP画像、本文、関連記事を承認フロー付きで変更できる」と定義します。受入条件まで書くと、委託先の見積と提案が同じ土俵に乗ります。

委託先を決める前後に、代表的なページを1〜3種類だけ作るPoCを挟むと、CMSの入力体験、画像最適化、検索、フォーム、API連携、デプロイ方法を早く検証できます。特に既存WordPressの記事移行では、本文の表現、表や画像、内部の関連付け、canonical、構造化データが壊れないかをサンプルで確認します。

設計では、サイトマップ、URLルール、コンポーネント、CMSスキーマ、データモデル、API仕様、権限、環境構成、CI/CD、監視を確定します。Astro 6では外部コンテンツをリクエスト時に扱うLive Content Collections、静的・動的ページのCSP設定、フォント最適化のためのFonts APIが提供されています（出典: Astro公式「Astro 6.0」、2026年3月）。ただし、新機能を使うかどうかは、運用者のスキル、ホスティング、長期保守のしやすさを踏まえて判断します。

実装が終わったら、いきなり全公開せず、移行リハーサルを行います。URLのステータスコード、301、画像、内部リンク、title、description、canonical、構造化データ、サイトマップ、フォーム通知、アクセス解析、表示速度を確認し、差分を修正します。検索流入が多いページは、公開直後だけでなくSearch Consoleのインデックス状況も確認します。

リリースは、テスト環境、限定公開、段階的な切り替えなどに分けます。納品時にはソースコードだけでなく、リポジトリの権限、CMSアカウント、環境変数の管理方法、CI/CD、インフラ設定、テスト仕様書、操作手順、障害時の復旧手順を引き渡してもらいます。誰がどの設定を持っているかが不明なまま公開すると、委託先を変更する際に大きな障害になります。

契約形態と責任分界を発注前に決める方法

Astroの開発では、画面を作る工程だけでなく、CMS、ドメイン、クラウド、CI/CD、外部API、セキュリティ、コンテンツ移行、保守が関係します。契約書や仕様書に責任分界を明記しないと、障害や仕様変更のたびに「それは対象外です」という行き違いが起きます。

請負契約は、完成させる成果物と検収を重視する契約形態です。サイト一式、CMS設定、移行スクリプト、テスト結果、ドキュメントなど、何を納品するかを明確にし、検収期間、修正の扱い、瑕疵対応、仕様変更時の追加費用を定めます。ページ数だけで契約すると、CMSの入力項目やリダイレクト、管理画面の権限などが抜けやすいため、機能一覧と受入条件を契約書に紐付けます。

準委任契約や時間精算型の契約は、要件を検証しながら改善する案件や、公開後の継続開発に向きます。発注者と委託先が週次で優先順位を変えられる一方、完成範囲と総額が見えにくくなるため、月ごとの上限工数、担当者、成果報告、未使用工数の扱い、バックログの管理方法を決めます。要件定義だけを準委任で行い、仕様確定後の開発を請負に切り替える方法もあります。

公開後はAstro本体、Node.js、npm依存パッケージ、CMS、ホスティング、WAF、ドメイン、証明書、バックアップ、監視を誰が管理するかを決めます。脆弱性が見つかった際の通知から修正までの時間、障害時の連絡手段、復旧目標、バックアップの保存期間、復旧テストの頻度も契約に含めます。問い合わせフォームや会員情報を扱う場合は、個人情報保護法に沿った安全管理、最小権限、多要素認証、アクセスログ、暗号化、委託先の再委託管理も確認します。

公開Webのセキュリティでは、Astroで静的に出力する部分と、APIや認証側の責任を分けて検査します。IPAが挙げるSQLインジェクション、クロスサイト・スクリプティング、CSRF、認可不備などをテスト項目にし、CSP、TLS、WAF、依存パッケージ更新を運用に組み込みます。アクセシビリティも見た目の追加要望ではなく、キーボード操作、代替テキスト、色のコントラスト、エラー表示を受入条件に含めます。こうした観点は、IPA「安全なウェブサイトの運用管理に向けての20ヶ条」および厚生労働省の障害者差別解消に関する案内でも示されています。出典は各機関の公開資料で、2026年に確認しています。

Astroのシステム開発にかかる費用相場とコストの内訳

Astro自体はオープンソースのため、Astroのライセンス費だけで開発費が決まるわけではありません。費用は要件定義、情報設計、デザイン、フロント実装、CMS、API、移行、テスト、インフラ、保守を合計した金額です。以下はAstro専用の公的統計ではなく、公開料金、一般的なWeb・CMS制作相場、業務システムの相場をもとにした発注前の参考レンジです。最終的には同じRFPで個別見積を取得します。

小規模LPや数ページのサイトは、テンプレート活用、Astroの静的生成、フォーム、基本的なSEO設定を含めて20万〜80万円程度が一つの参考レンジです。要件定義やオリジナルデザインを厚くすると、この範囲を超えることがあります。

10〜20ページ程度の中規模コーポレートサイトは80万〜180万円程度、CMS、フォーム、ブログ、オリジナルデザインまで含めたメディア・採用サイトは150万〜500万円程度が目安です。TamaTは中規模コーポレートサイトを80万〜120万円、大規模コーポレートサイトを120万〜180万円と公開しており、10ページ程度のCMS・フォーム・ブログ、または20ページ以上の認証・複数管理者・カスタム機能を前提にしています。料金の根拠はTamaT「Webサイト制作」の公開情報です。記事執筆時点の2026年に確認しています。

認証、外部API、個別ダッシュボード、監査ログ、既存基幹システムとの連携を含む業務ポータルは300万〜1,500万円超、大量のURLや複数サイトを段階移行する大規模リニューアルは500万〜数千万円、期間は6か月から1年以上になることがあります。ログインやデータ処理の比重が高い案件は、Web制作の単価だけで判断せず、業務システムとして見積もります。

見積書では、要件定義・進行管理、サイト構造とUI設計、デザイン、Astro実装、CMS設定、APIやフォーム、データ移行、SEO設定、品質試験、インフラ構築、公開作業を分けて確認します。「開発一式」とだけ書かれている場合は、何が含まれ、何が別途かを質問します。特に移行では、スクリプト作成、手作業の整形、画像の再配置、件数超過、差分検証が別費用になることがあります。

公開後は、CMS、ホスティング、CDN、監視、バックアップ、WAF、メール配信、画像配信、アクセス解析などの月額費用が発生します。利用量やSLAによって数千円から数十万円まで幅があるため、見積書にサービス名、プラン、想定利用量、超過料金、契約主体を記載してもらいます。

保守費は、一般的な業務システムの目安として初期費用の年15〜20％程度とされることがありますが、Astroサイトでも作業範囲によって大きく変わります（出典: NotebookLMリサーチノート内の業務システム全般Q&A、2026年）。月次の軽微修正だけか、脆弱性対応、障害監視、復旧、改善提案まで含むかを分け、保守契約を初期開発費と同じくらい具体的に確認します。

RFPと要件整理、見積比較で確認するポイント

見積金額だけを横並びにすると、安い会社が本当に安いのか判断できません。同じRFPを渡し、同じ前提条件で、設計の考え方、含まれる作業、体制、リスク、公開後の支援を比較します。Astroの実績数だけでなく、CMS運用や移行、API、セキュリティまで説明できるかが重要です。

RFPには、発注の背景、現状の課題、対象ユーザー、対象デバイス、ページ・URL一覧、コンテンツの種類、CMSの編集者と承認者、必要な機能、外部サービス、既存データの件数、移行方針、デザインの有無、希望公開日、予算上限、社内の確認体制を記載します。曖昧な項目は「提案してほしい」と明示しても構いませんが、その場合は提案範囲と追加費用の条件を分けて示してもらいます。

さらに、Astroの採用理由、SSG・SSR・Server Islandsの想定、Node・Cloudflare・Vercel・AWSなどのホスティング候補、ビルドとデプロイの方式、公開時のキャッシュ更新、ロールバック、バックアップ、脆弱性対応を確認項目にします。Astro公式は複数のデプロイ先とアダプターを案内しているため、特定サービスに固定される前に、移管可能性と運用者の負担を提案に含めます。複数の選択肢を案内していることは、Astro公式ドキュメントでも確認できます。出典は同ドキュメントで、2026年に確認しています。

比較表を作るときは、要件定義の時間、デザイナーとエンジニアの体制、CMSの設計、移行件数、手動移行の有無、テスト範囲、公開支援、ドキュメント、保守を一行ずつ分解します。A社の見積に含まれる移行・テストが、B社では別途になっていることは珍しくありません。工数が多いこと自体が悪いのではなく、なぜ必要かを説明できるかで判断します。

極端に安い提案では、要件定義、コンテンツ整備、SEOの移行、品質試験、公開後の修正、ソースコードの権利、インフラ費が省かれていないか確認します。反対に高い提案でも、不要なフルスクラッチ開発や過剰な機能が含まれている可能性があります。各社に「この金額が上下する条件」「納期が延びる条件」「発注者側が準備するもの」を質問すると、提案の現実性が見えます。

面談では、実績のURLや技術名だけでなく、担当者がどの範囲を自社で行ったのかを確認します。要件定義から参加するのか、実装だけなのか、バックエンドやインフラは別会社なのか、公開後の保守担当は誰なのかを質問します。可能であれば、実装担当者やプロジェクトマネージャーにも同席してもらい、曖昧な要望をどう要件へ変換するかを見ます。

委託先の候補は、Astroを使える会社というだけでなく、CMS、データ移行、API、セキュリティ、バックアップ、障害復旧を同じ体制で説明できる会社です。例えばmicroCMSのUSEN ICT Solutionsの事例では、コーポレートサイトにAstroのSSGを使い、WebhookからGitHub Actionsを経由してオンプレミス環境へCI/CDを実行しています。また、コンテンツとデザインを分けて2フェーズで移行しています（出典: microCMS導入事例、2026年確認）。このように、技術名よりも運用フローを聞くと、自社の発注に合うか判断しやすくなります。

Astroの外注で起きやすい失敗と対策

Astroは軽量なHTMLを出力しやすい一方、採用すれば自動的に速く、安全で、運用しやすくなるわけではありません。発注時に起こりやすい失敗を知り、RFPと契約に対策を入れておきます。

画像、フォント、動画、第三者タグ、過剰なHydration、API待ち、検索処理がボトルネックになると、静的HTMLでも体感速度は悪化します。提案時にLighthouseのスコアだけを約束させるのではなく、代表ページを実機とモバイル回線で測定し、初回表示、画像の読み込み、操作可能になるまでの時間、公開時のビルド時間を基準にします。公開後も同じ計測条件で継続監視します。

ヘッドレスCMSを導入しても、入力項目が分かりにくい、プレビューできない、承認者が設定されていない、公開後に再ビルドが必要、画像の扱いが不明という状態では、運用は内製化できません。実際の編集担当者にPoCを触ってもらい、記事作成、修正、レビュー、予約公開、公開後の差し戻しまで一通り試してもらいます。microCMSの導入事例でも、マーケターがSEOメタ情報や記事の軽微な修正を行えることが成果として紹介されています。

記事数が多いサイトでは、実装よりもコンテンツの整形、画像の確認、URL対応、リダイレクト、検索結果の検証に時間がかかります。発注時点で移行件数と方法を決め、サンプル移行、全件移行、差分確認、公開後の監視まで計画します。USEN ICT Solutionsの事例でも、構造化されていない旧サイトのコンテンツは手作業で移行され、ページ数の多さが負担になったと紹介されています。

また、納品後に担当エンジニアがいなくなると、AstroやNode.jsの更新、依存パッケージの脆弱性対応、CMS障害、デプロイ失敗に対応できません。保守契約を結ばない場合でも、更新手順、復旧手順、連絡先、アカウント、バックアップ、ソースコードの管理権限を引き渡してもらい、社内または別の会社へ引き継げる状態にします。

Astroのシステム発注・外注でよくある質問

ここでは、Astroのシステムを発注するときに多く寄せられる疑問へ、判断の基準を先に回答します。自社のRFPを作る際の確認項目としても活用できます。

Astroの実装実績に加えて、CMS、既存サイトの移行、APIや認証、インフラ、公開後の保守まで説明できる会社へ発注します。実績の数ではなく、担当範囲、開発体制、納品物、障害時の対応、ソースコードと環境の引き渡しを同じRFPで確認し、2〜3社程度から提案を比較すると判断しやすくなります。

小規模LPや数ページなら20万〜80万円程度、中規模コーポレートなら80万〜180万円程度、CMS付きのメディアや採用サイトなら150万〜500万円程度が参考レンジです。認証、API、業務データ、大量移行が入ると300万〜1,500万円超や数千万円になる可能性があるため、ページ数ではなく機能・移行量・保守範囲をそろえて見積を取ります。

必ず改善するとは限りません。AstroでHTMLを軽量にしても、URL変更、301漏れ、titleやcanonicalの欠落、画像の品質低下、内部リンクの断絶、コンテンツの削除があれば検索流入を損なう可能性があります。移行前後のURL対応表、リダイレクト、サイトマップ、構造化データ、実機での速度を検証し、公開後にSearch Consoleとアクセス解析で確認します。

静的ページ中心で、社内にNode.jsやGit、CMS、クラウドの担当者がいれば内製保守は可能です。ただし、Astro本体や依存パッケージの更新、CI/CDの失敗、脆弱性、CMSやドメインの障害、バックアップからの復旧まで担当できる体制が必要です。難しい領域だけを外部保守へ委託し、記事更新や軽微な修正を社内で行う分担も現実的です。

まとめ：Astroのシステム発注は要件・契約・運用を一体で比較します

Astroのシステムを発注・外注するときは、まず公開コンテンツと動的な業務機能を分け、SSG、SSR、API、CMSの役割を整理します。そのうえで、テンプレート、ヘッドレスCMS、既存WordPress活用、スクラッチ開発のどれが自社の目的に合うかを選びます。

RFPには、目的とKPI、現行URLとデータ、CMS運用、必要な機能、非機能要件、移行範囲、納期、予算、成果物、検収条件、保守、セキュリティ、責任分界を記載します。見積は金額だけでなく、要件定義・移行・テスト・公開・引き継ぎが含まれるかを比べ、PoCで編集体験と技術リスクを確かめます。

Astroの知識だけでなく、事業要件を整理し、CMS運用、既存サイト移行、API、セキュリティ、バックアップ、公開後の改善まで設計できる委託先を選びます。発注形態と契約を先に整え、開発会社と同じ前提で話せる資料を用意すれば、費用と納期のブレを抑えながら、速さ・SEO・更新性・保守性を両立しやすくなります。

▼全体ガイドの記事
・Astroのシステム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。