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

Linodeのシステム発注は、現状整理、要件とRFP、契約・開発、運用設計の順に進めると、業務に合う構成と責任分担を整えられます。

Linodeは業務パッケージではないため、業務アプリは別途組み合わせて発注します。見積より前に、現状業務と成功条件を整理しておくと抜け漏れを抑えられます。

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

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

Linodeのシステムの位置づけ

Linodeは業務パッケージではなく、Linuxを中心にサーバー、ストレージ、ネットワーク、データベースなどを組み合わせて使うIaaSです。

2022年の買収後は、Akamai Cloudのコンピューティングサービスとして案内される場面が増えました。

一方で、検索者には「Linode」の名称も広く残っています。発注書や提案書には「Linode（現Akamai Cloud）」と記載すると、認識のずれを抑えられます。

基盤を発注する範囲と業務システムの違い

販売管理や顧客管理、在庫管理、申請ワークフローは、Linodeを契約した時点ではまだ含まれていません。

業務に必要な機能は、画面やAPI、データベースを中心に組み合わせて発注します。

認証や帳票、外部連携のほか、サーバー構築と監視も、同じ発注範囲に含めます。インフラ会社に業務要件まで求めたり、アプリ会社に24時間監視を当然のように含めたりすると、責任範囲が食い違いやすくなります。

• サーバー：Linode Compute Instance上に置くWeb・APIサーバー
• データベース：Managed Database、PostgreSQL、MySQLなどの中からの選択
• ストレージと通信：Object Storage、Block Storage、NodeBalancer、Cloud Firewallの組合せ
• 運用機能：DNS、バックアップ、監視も構成に含めます。

小規模な検証環境では、1台に複数の役割を載せられます。

本番では、アプリとデータベースを分け、障害時にどこまで復旧できるかを設計します。

Linodeに向いている業務と向いていない業務

Linode上の開発は、自社の業務の流れに合わせて作り込む場合に合っています。

• 独自業務：社内ポータル、顧客・案件管理、予約・申請のWebシステム
• 外部サービス：外部公開API、ECのバックエンド、既存基幹システムの周辺機能も対象になります。
• 既存資産：Linux、Docker、Node.js、Python、PHP、PostgreSQLを活用できます。

会計や人事、給与など法改正への対応が多い業務は、SaaSやパッケージのほうが合理的な場合があります。

既製品で足りない部分だけを、Linode上の連携基盤で補う方法もあります。

Kubernetesや複数リージョンの採用そのものが目的になると、運用負荷が増え、現場に定着しないこともあります。

利用者数や負荷、停止を許容できる時間に合わせて、段階的に選びます。

発注形態の選び方

発注者は、業務をどれだけ変えるか、自社にIT運用人材がいるか、納期と予算をどこまで固定するかで、発注形態を決めます。

最初から全面的なスクラッチ開発に決めず、SaaS・パッケージ、Linode上の個別開発、既存クラウドとの組み合わせを同じ要件で比べます。そうすると、過剰な開発を避けられます。

SaaS・パッケージを中心に不足分を開発する形

会計や人事のような標準化しやすい業務はSaaS・パッケージに任せ、足りない部分をLinodeで補う形が取れます。

• 標準化しやすい業務：会計や人事のような業務は、SaaS・パッケージを使うと初期開発と法改正対応の負担を抑えられます。
• データ連携：Linodeには、SaaSと社内データをつなぐAPIやCSV・EDI連携を置く構成が考えられます。
• 追加の画面：独自の申請画面や社内ポータルを、Linode上に載せる形もあります。
• 確定事項：標準機能と個別開発の境界、データの正本、障害時に連絡する会社は、書面に残します。

Linode上の個別開発を選ぶ場合

Linode上で業務アプリを作り込む場合は、向いている場面と、開発後に発生する担当を確認します。

• 選ぶ場面：独自ルールや外部公開サービスが競争力に直結する場合です。
• 権限と承認：利用者別の権限や複雑な承認が必要なときも候補になります。
• 利点：仮想マシンの料金は予測しやすく、APIやTerraformを使って環境を再現しやすい点です。
• OS更新と脆弱性対応：その担当者を、別途決めておきます。
• 障害時の体制：復元、監視、障害対応の担当を、事前に決めておく必要があります。

既存クラウドとのマルチクラウド構成

既存クラウドのマネージドサービスは残し、ネットワーク転送量が大きい配信サーバーやバッチだけをAkamai Cloudへ移す構成もあります。

すべての機能をLinodeへ移すとは限りません。

Akamaiは2025年11月、アイレットとの契約で、主要クラウドとの併用の設計・構築・運用を示しました（出典：Akamai「Akamai、アイレットとパートナー契約を締結」、2025年）。

併用時は、費用や可用性の効果と、運用の複雑さを比べて判断します。

• 運用負荷：監視、認証、通信、バックアップ、障害連絡の仕組みが複雑になります。
• 配置と復旧：データの配置、一次対応会社、別クラウドへ戻す手順の取り決め
• 費用対効果：構成を増やす効果が、費用を上回るかを確認します。

Linodeのシステム発注の進め方

会社探しや見積より先に、現状業務と成功条件を整理します。そのうえで3段階で進めると、抜け漏れを抑えられます。

発注者は、決めることと委託先に提案してもらうことを分けておくと、価格だけでなく提案の質も比べられます。

企画と現状整理で発注の前提をそろえる

発注前に、達成したい成果と現行業務、移行するデータの前提をそろえておきます。

• 業務成果：入力時間の半減、月次締めの3営業日短縮、顧客情報の二重入力の解消などの目標
• 現行業務：Excel、紙、メール、電話、既存システム、手作業CSVの洗い出し
• 業務の流れ：情報の作成者、承認者、部署間の受け渡し時点を確認します。
• 移行データ：表記揺れや重複、不要な過去データ、保存期間、削除条件を社内で決めます。

移行対象を一覧にしておかないと、旧Excelとの件数差や、どちらが正しいデータかの判断で問題が起きやすくなります。

RFPによる提案範囲と比較条件

会社ごとに前提が違うと見積を比べられないため、複数社へ共通条件を記したRFPを渡します。

RFPには、業務の中身から発注の条件、インフラや運用の前提まで書いておきます。

• 業務条件：目的、対象業務、利用者数、画面・帳票数、権限を記します。
• 発注条件：外部連携、移行、納期、予算上限、保守時間帯をそろえます。
• 未確定事項：確定できない点は断定せず、前提と不確かな点、提案してほしい代替案に分けて示します。
• インフラ要件：東京または大阪リージョンの希望、同時利用者数、ピーク時の処理量、許容応答時間を含めます。
• 運用・構成：RTO・RPO、バックアップ世代、ログ保持期間、個人情報、開発・検証・本番の環境分離を明記します。

候補会社には、Linode単体、既存クラウド併用、SaaS中心の3案を比べてもらいます。そうすると、技術を目的化しにくくなります。

設計・開発・受入れの段階

契約後は、要件定義から受入れまでを段階的に進めます。全機能を一度に作るとは限りません。

1. 要件定義、基本設計、詳細設計を行います。
2. 開発、結合テスト、総合テストを進めます。
3. 移行リハーサル、受入テストを経てリリースします。

申請、案件、顧客台帳などをMVPとして先に試し、利用者の反応を見てから次の機能を決めます。

画面が動くかだけでなく、担当者と承認者が顧客登録・見積・受注・請求を処理できるかも確認します。

権限のない担当者に機密項目が表示されないことや、バックアップから指定時間内に復元できることも、合否条件に加えます。

受入基準がないまま検収日を迎えると、修正の依頼が追加開発なのか不具合なのか判断しにくくなります。

RFPと要件整理で決めること

RFPでは、業務課題と比較条件を伝え、実装方法は必要以上に固定しないようにします。Compute Instanceの台数やDB方式まで決めてしまうと、より安全な代替案を逃すことがあります。

利用者と業務シナリオで書く業務要件

利用者の役割と業務シナリオが分かると、画面や権限の関係を設計しやすくなります。通知や履歴、帳票も、その流れに沿って設計できます。

• 業務シナリオ：営業担当の顧客登録、上長の値引き承認、経理の請求データ出力などの流れ
• 希望の具体化：「便利」「リアルタイム」を対象者、頻度、期限、指標に置き換えます。
• Excel移行：列名、入力規則、必須項目、過去データの扱いを決めます。
• 移行条件：重複顧客の統合、過去取引の参照方法、旧システムの停止時期を決めます。

移行リハーサルでは、件数や金額、日付を照合します。文字コードや添付ファイルも照合の対象にし、現場の確認責任者を決めておきます。

数値と責任分界で書く非機能要件

性能、復旧、セキュリティの基準と担当を明確にし、保守費やSLAを比べます。

• 性能・稼働：同時利用者数、ピーク時のリクエスト数、応答時間、稼働時間、許容停止時間を定めます。
• 復旧目標：RTO・RPO、バックアップ世代、ログ保存を決めます。
• 対応水準：4時間以内の復旧、直近24時間の復元、平日9時から18時の1時間以内の一次回答などを条件にできます。
• 責任分界：OS・DB・アプリ・料金・監視・窓口ごとの担当を分けます。

Cloud FirewallやVPC、SSH鍵、TLSといった対策を使っても、すべての問題を防げるわけではありません。二要素認証やNodeBalancer、バックアップを併用する場合も、同じ考え方が当てはまります。

アプリの脆弱性や過剰な権限は、基盤の仕組みでは自動で解決しません。誤操作やデータ削除については、運用で備える必要があります。

責任の分担は、担当を一覧にして提案書と契約書に添付します。

個人情報とデータ所在地の契約条件

個人情報の扱いでは、東京リージョンを選ぶだけで法令対応は完了せず、契約条件まで含めて整える必要があります。

個人情報保護委員会のQ7-53では、クラウド利用が第三者提供や委託に当たるかが説明されています。保存データに個人データが含まれるかだけでなく、事業者が個人データを取り扱うかで判断するとされています。

出典は、個人情報保護委員会「個人情報の保護に関する法律についてのガイドラインに関するQ&A」です。

発注時に確認しておきたいのは、データ管理と契約条件です。

• 管理状況：データ種別、保存場所、管理者権限、再委託、ログ、暗号化を確認します。
• 契約終了時：削除証明、バックアップ先、返却方法の取り決め
• 海外委託：外国第三者提供、委託先の監督、再委託先へのアクセス範囲を、法務・情報システム部門と確かめます。

請負と準委任の使い分け

成果物と納期を固定できる工程と、探りながら進める工程を分けて考えます。未確定の要件をすべて請負にすると追加費用が生じやすく、逆に準委任だけでは範囲が見えにくくなります。

成果物と検収条件を固定できる工程の請負契約

請負は、合意した成果物を完成させ、発注者が検収する工程に向いています。

納品一覧には、設計書や画面、API、DBを入れます。テスト仕様やソース、マニュアル、移行結果も加えます。

受入期間や修正、瑕疵対応の扱いは、契約前に確認します。ライセンスとソース利用権も確かめます。

要件整理や継続改善の準委任契約

準委任は、要件定義や技術調査、アジャイル開発、運用改善に使われます。初期整理や月次保守では、作業と稼働時間、会議を決めます。

報告の方法や責任者、時間外対応も定めておきます。成果物や作業記録も合意しておくと、準委任でも品質を管理しやすくなります。

要件定義は準委任、開発は請負など工程を分けた契約

工程ごとに、契約と引継ぎ条件を組み合わせます。

• 契約の組合せ：要件定義・PoCは準委任、仕様確定後のMVP開発は請負にできます。
• 継続運用：リリース後の監視や改善を準委任にする方法があります。
• 工程間の引継ぎ：要件書、画面一覧、データ定義、非機能要件、課題の受け渡し
• 契約条件：支払、変更、検収、知財、秘密保持、賠償、解約時の引継ぎを確認します。

Linodeのシステム発注の費用相場

費用は、クラウド利用料と開発費を分けて見積もり、外部サービス費と保守費もそれぞれ別に扱います。金額は比較用の概算で、要件や契約条件によって変わります。

公式料金と追加サービスを分けたクラウド利用料

2026年8月に確認したAkamai Cloudのアジア太平洋向け料金ページでは、共有CPUのLinode 4GBが月5米ドル、8GBが月10米ドルです。

出典はAkamai Cloud「Asia Pacific Cloud Computing Costs and Pricing」（2026年8月確認）です。

共有CPUのLinode 16GBは月20米ドルです。1米ドル=150円で単純換算すると、4GB、8GB、16GBは月750円、1,500円、3,000円です。

VMの料金だけでなく、追加サービスを含めた構成全体の概算を確認します。

• 変動要因：為替、リージョン、改定、税、追加サービスで請求額が変わります。
• 基盤の追加費用：Managed Database、Block/Object Storage、バックアップ、NodeBalancer、監視です。
• 外部サービス費：外部メールやWAF、ドメイン、決済サービスの費用が加わります。

初期試算の目安は、開発・検証用の1台構成で月数千円から2万円程度です。本番のアプリ・DB・バックアップ・監視を含む小規模構成は、月1万から5万円程度です。

冗長化や複数拠点を含む構成は、月5万から20万円以上になる可能性があります。ただし、いずれも公式見積ではなく、公式掲載料金を組み合わせた概算です。

機能範囲とデータ移行量による開発費

開発費と期間の幅は、利用規模と機能範囲で大きく変わります。

小規模の場合は、基本認証、登録・検索、CSV出力程度を想定しています。

複数部門向けでは、外部会計・決済・基幹連携を含めて想定します。監査ログや冗長化、受入テストも含みます。

• 小規模：利用者50人未満の簡易CRM・申請は150万から500万円、1から3か月です。
• MVP：顧客・案件・受発注・在庫は500万から1,200万円、3から6か月程度です。
• 複数部門：販売管理、予約、業務ポータルに外部連携などを加える場合、1,200万から3,000万円、6から10か月程度です。
• 基幹系：高可用性、複数拠点、大量データ、個人情報や決済情報を扱う場合、3,000万円から1億円以上、9か月から2年程度になることがあります。

MVPの範囲には、権限や検索、帳票が入ります。API、初回データ移行、操作研修も範囲に含まれます。

段階移行や災害復旧訓練、24時間運用は、基幹系の計画に含めて考えます。

これらは要件別に見た一般的な業務システムの幅で、Linode公式の開発価格ではありません。

開発費とクラウド費用を分けた保守費

保守には、問い合わせ対応や障害調査、OS・ミドルウェアの更新が入ります。脆弱性対応やバックアップ確認、監視、定例報告、軽微な改修も含まれます。

見積では、費用の目安と変動する条件を分けて確認します。

• 費用目安：開発費の年15から20%程度が一般的な目安です。
• 変動条件：24時間監視、休日対応、SLA、診断、データ修正、追加開発で変わります。
• 見積の分け方：月額保守、クラウド・外部サービス実費、従量課金の区分

開発費が1,000万円なら、年150万から200万円程度が目安です。ただし、これは目安で、確定した価格ではありません。

クラウド料金は、開発会社が立て替えるか、自社で直接契約するかを決めておきます。

自社で直接契約する場合は、請求権限や管理者の退職時、契約終了時の引継ぎ手順も設計しておくと、ベンダーロックインを抑えやすくなります。

委託先選定と見積比較のポイント

委託先は、工程をまたいだ一貫性で評価します。要件定義や移行、非機能要件、受入れ、運用の流れがつながっているかを見ます。

役割を踏まえ、1社に任せるか、開発と運用で分担するか、発注者が統括するかで体制を決めます。

似た業務と運用による実績確認

技術名だけでは分からない業務理解や運用経験は、実績と担当範囲から確かめます。

• 類似経験：業務、利用者数、移行、障害対応、稼働後の改善について尋ねます。
• 業務理解：名寄せ、締め処理、予約のピーク負荷などの難所を確かめます。
• 実績資料：画面例、体制図、テスト計画、運用報告書のサンプルの確認
• 専門性：業務アプリ、セキュリティ、Linux・OSS・API、移行、Kubernetesを見ます。
• 担当範囲：パートナー企業が業務アプリ開発を行うとは限らないため、開発、インフラ、セキュリティ、MSP、監視の範囲を提案書で示してもらいます。

前提・工数・除外項目による見積比較

見積額の差が作業範囲によるものかは、条件を照合すると分かります。

• 内訳：工程別金額、役割、工数、単価、日程、検収、保守開始を比べます。
• 除外条件：移行別途、クラウド実費、追加要望、本番障害対象外などを確認します。
• 評価軸：3社なら価格、理解、体制、技術、安全性、移行、運用、契約に配点します。
• 条件の統一：価格だけで比べると、移行や保守を含まない提案が有利に見えることがあります。質問表で回答をそろえ、修正版を受け取ります。

納品物と契約終了後の引継ぎ

委託先を変える際に移行が滞らないよう、納品物と終了条件を定めておきます。環境だけを納品されると、別会社へ移すときに再構築費が発生しやすくなります。

• 納品物：ソース、設計書・構成図、Terraform、CI/CD、テスト結果、マニュアル、障害履歴、アカウント一覧の所有者を確認します。
• アカウント：クラウド名義を、発注者と委託先のどちらにするかを決めます。
• 契約終了：データ形式、バックアップ、秘密情報削除、DNS・証明書移管、障害引継ぎ、移行支援単価の取り決め

契約期間や解約条件も確認したうえで、3年程度の開発・クラウド・保守・移行費を合計したTCOで比べます。

本番運用と移行の確認事項

運用設計では、監視や通知、一次対応、エスカレーションを押さえます。バックアップやパッチ適用、脆弱性対応、復元テストも、設計に組み込みます。

自社で運用するか、MSPに委託するか、24時間対応が必要かも、発注前に決めます。

バックアップと復元テスト

世代数や保存先だけでなく、担当者と手順、復旧できる時点を検証します。

DBや画像、添付ファイルも復旧対象です。環境変数や暗号鍵、DNS、証明書、デプロイ設定まで、復旧対象に含めます。

テストの結果は記録し、RTO・RPOを満たせなければ、構成や契約を見直します。

データ移行と切替のリハーサル

小規模なサンプルで成功しても、本番量や文字コードで失敗する場合があります。そのため、切替の条件と確認方法を決めて、本番相当のデータで事前に確かめます。

• 切替条件：停止時間、差分取込、件数照合、アカウント、権限、添付、連携、戻し条件を決めます。
• リハーサル：本番相当のデータでの試行と、業務部門による数字と画面の確認

IRIAMの事例では、既存の配信管理を維持したまま、約2か月で移行したと紹介されています。

同事例では、エグレス費をほぼゼロにし、配信サーバー費を従来の3分の1から10分の1以下にしました（出典：Akamai「IRIAM Akamai Cloud」、2025年公開）。

これは大量配信という特性と構成によって得られた成果です。自社のデータ量で効果を検証します。

クラウド基盤のサポートとアプリ保守の分担

クラウド基盤の支援と、業務仕様やコード、データを直すアプリ保守は、別の領域です。

運用では、窓口と担当、利用者支援の受け持ちを決めておきます。

• 障害切り分け：クラウド、OS・DB、アプリ、利用操作ごとの担当
• 問い合わせ窓口：二次連絡時間、ログ共有、緊急変更の承認者を契約に含めます。
• 発注者の役割：業務、情報システム、セキュリティ、データ移行の責任者の配置
• 利用定着：操作研修、マニュアル、問い合わせ分類、改善会議の計画

現場が使い続け、データが正しく蓄積されていることを、成功条件にします。

よくある質問（FAQ）

料金や開発会社、セキュリティ、運用体制について、発注前に出やすい疑問を取り上げます。

Linodeは本当に他のクラウドより安いですか？

インスタンス料と転送料を含めると安くなる場合もありますが、最安とは限りません。VM単価だけで判断せず、DBやバックアップ、監視、保守まで含めたTCOで比べます。障害対応や移行、外部サービスの費用も、同じ土台で比べます。

大量のアウトバウンド通信がある場合は、IRIAM事例のような効果も考えられます。ただし、自社の通信量と構成をもとに試算します。

LinodeとAWSやAzureはどのように使い分けますか？

比べる際は、標準機能や認証・分析基盤、運用経験を見ます。通信量やリージョン、必要な支援も比べます。

既存クラウドを残したまま、転送量の大きい処理だけをAkamai Cloudに置く方法もあります。障害切り分けと、契約終了時の移行の難しさも評価します。

LinuxやLinodeの知識がなくても外注できますか？

外注は可能ですが、業務要件と運用上の責任は発注者が決める必要があります。Linuxの構築経験だけでなく、要件定義やデータ移行、セキュリティに対応できる会社を選びます。監視や復元テスト、利用者研修まで担えるかも確かめます。

専門人材がいない場合は、開発とMSPをまとめて任せるか、窓口の統合をRFPで求めます。

個人情報をLinodeに保存しても問題ありませんか？

保存場所だけで判断せず、取扱者や委託、第三者提供の関係を確認します。再委託や権限の範囲も見ておきます。

契約には、利用目的や対策、ログ、事故報告を記載します。削除や返却、監査、外国事業者の関与も盛り込みます。

法務や個人情報担当者とデータフローを確認してから、本番データを移します。

見積金額を超える追加費用を防ぐにはどうしますか？

前提や対象外、変更、検収を書面にします。移行や外部サービス、従量課金、保守範囲も、書面にそろえます。

請負と準委任は工程ごとに分け、未確定の要件は調査やPoCの上限額を決めてから進めます。

同じRFPと質問回答を共有し、修正見積の前提をそろえます。

まとめ

発注では料金だけでなく、業務と要件、データ、運用まで含めた構成で選ぶ必要があります。SaaS・パッケージ、Linode上の個別開発、既存クラウド併用は、業務ごとに分けて考えます。

発注前に押さえる要点

発注前に決める条件は、RFP、費用、契約の観点で整理します。

• 業務条件：目的、業務シナリオ、利用者、権限、外部連携、データ移行を記載します。
• 非機能要件：RTO・RPO、リージョン、セキュリティ、保守、納品物、終了時の引継ぎを記載します。
• 費用比較：開発・クラウド・保守・移行費を分けて、3年程度のTCOと責任分界で比べます。
• 契約：工程ごとに契約形態を選び、受入れと変更管理の条件を定めます。

最初の一歩は現行業務とデータの棚卸し

発注の準備は、現状把握から委託先の比較へと段階的に進めます。

1. Excel、紙、メール、既存システム、手作業CSVを集めて、業務とデータ項目を整理します。
2. 達成成果と発注者の作業を決め、複数社へ同じ条件で相談します。
3. Linode（現Akamai Cloud）だけでなく、整理から開発、移行、運用まで担える委託先を選びます。

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

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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