flutterflow【2026年版】課題・拡張性・コミュニティの採用判断

はじめに

「アプリ開発を始めてみたいけれど、どのツールを使えばいいのか分からない」「FlutterFlowという名前は聞くけれど、業務で本当に使えるのか判断できない」と感じている方は多いです。ノーコードツールは画面が作りやすいぶん、導入後に見えてくる課題を事前に想像しにくいという特徴があります。

FlutterFlowは、Googleが開発したFlutterをベースに、画面・ロジック・データ連携を視覚的に組み立てられる開発環境です。flutterflowを採用するかどうかは、画面の作りやすさではなく、公開後の運用まで耐えられるかで判断することが大切です。 MVPを短期間で作るだけなら始めやすい一方で、顧客情報や決済を扱うアプリでは、料金プラン、拡張の方法、ストア公開の手順、困ったときの情報源まで含めて検討する必要があります。

この記事では、2026年9月時点の公式情報をもとに、FlutterFlowの課題と対策、パフォーマンス改善、カスタムコードによる拡張、App StoreとGoogle Playへの公開、今後の方向性、コミュニティの活用方法を順番に解説します。最後に、自社で進めてよい範囲と、専門家に相談したほうがよい範囲の分かれ目も整理します。導入前の社内説明や、見積もり依頼前の確認資料としてもお使いください。

FlutterFlowのデメリットを徹底検証：導入前に知っておきたい注意点

FlutterFlowはノーコードでアプリ開発を進められる強力なツールですが、導入前に知っておくべき注意点もあります。ここでは、開発スピードの限界、料金体系、オフライン環境での制約、WebアプリのSEOと引き継ぎという4つの観点から、FlutterFlowのデメリットを検証します。

課題の多くは、ツールそのものの限界というより、要件と運用体制が合っていないときに表に出ます。教材一覧や予約フォームのようなMVPは進めやすい一方で、顧客別の権限、課金、個人情報、CRM連携を含むアプリでは、画面を作る前にデータ構造と責任範囲を決めておかないと、本番化の段階で手戻りが起きます。

課題	起きやすい場面	対策
要件が曖昧	MVPから本番化する時	データ・権限・公開先を先に定義する
保守者不在	カスタムコード追加後	命名規則とレビュー体制を作る
プラン不足	GitHub連携や共同編集が必要になった時	見積もり前に必要な機能とプランを照合する
ツール不適合	業務フローが複雑な社内システム	Bubbleやスクラッチ開発も比較する

開発スピードの限界？FlutterFlowの弱点と対策

FlutterFlowは、従来のコーディングに比べて画面づくりを大幅に速くできます。ただし、複雑な業務ロジックや高度なカスタマイズが必要になると、その恩恵は小さくなります。何重にも重なる条件分岐や細かな例外処理を画面上の設定だけで表現すると、かえって見通しが悪くなるためです。

対策としては、まず複雑なロジックをDartで書けるカスタムコードで補う方法があります。次に、外部APIとの連携を活用する方法です。決済や地図、通知などは専用サービスのAPIを呼び出したほうが、FlutterFlow単体で作り込むより確実に動きます。

もっとも効果が大きいのは、設計段階での計画です。開発前にアプリの要件を洗い出し、FlutterFlowの標準機能で対応できる範囲と、カスタムコードが必要な範囲を明確にしておくと、途中で作り直す事態を減らせます。標準機能で作れる部分を先に固めることが、結果的に開発スピードを保つ近道になります。

料金体系の落とし穴：無料プランから有料プランへの移行で注意すべきこと

FlutterFlowには無料プランがありますが、本格的な開発や公開には有料プランへの移行が前提になります。上位プランほどチーム開発や運用の機能が増えるため、金額だけで選ぶと予定外のアップグレードが発生しがちです。

2026年9月24日時点のFlutterFlow公式Pricingで確認した主な内容は次のとおりです。

プラン	月払い時の料金（米ドル）	主な機能と上限
Free	$0	プロジェクト2件まで、API Endpoints 2件まで、AI Generation 5回（累計）
Basic	$39/月	プロジェクト無制限、Code Download、APK Download、カスタムドメイン、ワンクリックのストア公開、AI Generation 50回/月
Growth	1席目$80/月、2席目$55/月	GitHub連携、2名のリアルタイム共同編集、ブランチ2本、VS Code Extension、AI Generation 200回/月
Business	1席目$150/月、2〜5席目$85/月	最大5名の共同編集、ブランチ5本、Automated Testing最大3件、Figma Frame Import、CLI Access、AI Generation 500回/月
Enterprise	個別見積り	要件に応じた個別構成

料金は公式ページの月払い表示で、年払いに切り替えると割引されます。税の扱いや最新の金額は契約前に公式ページで確認してください。

注意したい点は3つあります。1つ目は、プランごとの機能制限を把握することです。たとえばソースコードを手元に残すCode DownloadはBasic以上、GitHub連携やVS Code ExtensionはGrowth以上、CLIはBusinessで提供されています。保守を外部に任せる予定があるなら、コードを取り出せるかどうかは見落とせない条件です。

2つ目は、利用量に応じて上限が効く項目を確認することです。無料プランではAPIのエンドポイントが2件までに制限され、AIによる生成回数もプランごとに上限があります。共同編集の人数を増やすとシートごとに料金が加算されるため、チームの人数が増えたときの総額も見積もっておきましょう。

3つ目は、長期利用を見据えたプラン選択です。自動スナップショットのバックアップは、Freeが1時間前まで、Basicが1日前まで、Growthが3日前まで、Businessが7日前までと差があります。プランは月額の安さではなく、開発体制と復旧できる範囲を決める条件として選ぶことが重要です。 無料プランで何を検証できるかはFlutterFlow無料プランの解説記事で詳しく整理しています。

オフライン環境での利用は可能？FlutterFlowの制約

FlutterFlowの開発環境はクラウドベースのため、オフライン環境での開発は制限されます。エディタへのアクセス、コードの生成、ビルドやデプロイといった作業にはインターネット接続が必要です。出張先や通信が不安定な現場で作業する予定がある場合は、この点を前提にスケジュールを組んでおく必要があります。

一方、完成したアプリ側は、設計しだいでオフライン対応ができます。公式のSQLite連携を有効にすると、モバイルアプリの端末内にデータを保存し、通信がない状態でも閲覧や入力ができます。ただし公式ドキュメントにあるとおり、SQLiteはWebアプリでは使えません。オンラインに戻ったときにサーバー側のデータと同期する処理は、どのデータを優先するかを含めて自分で設計する必要があります。

オフライン対応が必須のアプリでは、要件定義の段階で「どの画面をオフラインで使うか」「同期がぶつかったときどちらを正とするか」を決めておきましょう。具体的な実装手順はFlutterFlowでのオフライン対応の実装方法で解説しています。

WebアプリのSEOと生成コードの引き継ぎ

FlutterFlowはWebアプリも出力できますが、検索エンジンからの集客を狙うページには向きません。Flutter公式のWeb FAQでも、アプリ本体はFlutterで作り、ランディングページやマーケティング用のコンテンツ、ヘルプページは検索向けに最適化したHTMLで分けて作る構成を勧めています。集客用のサイトと、ログイン後に使うアプリは別々に考えるのが現実的です。

もう1つの注意点は、生成されたコードの引き継ぎです。Code Downloadでソースコードを取り出すことはできますが、FlutterFlowが生成したコードをエンジニアがそのまま読み解いて保守するには慣れが必要です。将来的にフルコード開発へ移行する可能性があるなら、GitHub連携で履歴を残し、カスタムコードの命名規則をそろえておくと、移行時の負担を減らせます。

FlutterFlowで作るアプリのパフォーマンス改善：高速化の秘訣

FlutterFlowで作ったアプリも、画面数やデータ量が増えるにつれて動作の重さが気になることがあります。ここでは、アプリを高速化するための考え方を、ボトルネックの特定、画像の最適化、アニメーションの扱いの3つに分けて解説します。

パフォーマンスボトルネックの特定と解消

パフォーマンス改善の第一歩は、どこが遅いのかを特定することです。FlutterFlowではTest ModeやLocal Runで実機に近い動作を確認でき、Debug Panelで変数やアクションの状態を追えます。コードをダウンロードできるプランであれば、Flutter標準のDevToolsで描画の負荷を詳しく調べることもできます。

原因が分かったら、それを取り除きます。よくあるのは、画面に表示されていないウィジェットまで読み込んでいるケース、画面側で重い計算をしているケース、データベースから必要以上のデータを取得しているケースです。重い計算はCloud Functionsなどのバックエンドへ移し、取得するデータは画面に必要な項目と件数に絞ります。

一覧画面では、公式のInfinite Scrollを使うと効果的です。FirestoreやSupabase、ページング対応のAPIから取得したデータを、スクロールに合わせて少しずつ読み込めます。既定では1ページあたり25件を読み込む設定になっており、件数の多い一覧でも初期表示を軽く保てます。

画像の最適化：アプリを高速化するためのテクニック

画像はアプリの見た目を良くするために欠かせませんが、パフォーマンスに大きく影響する要素でもあります。高解像度の画像をそのまま使うと、起動や画面の切り替えが遅くなり、通信量も増えます。次のテクニックで画像を最適化しましょう。

テクニック	詳細
画像サイズの最適化	表示するサイズに合わせてリサイズしてからアップロードする
画像形式の選択	写真はJPEG、ロゴやアイコンはPNG、圧縮率を重視するならWebPを使う
画像の圧縮	圧縮ツールでファイルサイズを小さくし、表示速度を上げる
分割読み込み	一覧はInfinite Scrollで、表示される分だけ読み込む
配信サービスの利用	Firebase StorageやCDN、画像変換サービスから配信する

Firebaseに保存した画像を最適化する方法として、公式コミュニティにはTwicPicsを使うチュートリアルも公開されています。サムネイルと詳細表示で画像サイズを切り替えられ、ユーザーが画像を投稿するアプリで特に効果を発揮します。

アニメーションとトランジション：滑らかなUIを実現するために

アニメーションや画面遷移の演出は、アプリを魅力的に見せる重要な要素です。しかし、過度なアニメーションや複雑なトランジションは、処理負荷を高めて動作を重くする原因になります。演出はシンプルな種類を選び、再生時間を短めに設定しましょう。遷移のタイミングが操作の流れに合っているかも、実機で確かめることが大切です。

Webアプリについては、公式のWeb Publishing設定に「Use Wasm (Beta)」があり、FlutterのWebAssembly向けレンダラーでビルドできます。表示速度の改善が期待できる一方で、2026年9月時点ではBeta扱いで、Test Modeでは使えないと明記されています。本番で使う前に、主要なブラウザで動作を確認してから切り替えましょう。

FlutterFlow拡張性：カスタムコードで機能を拡張する方法

FlutterFlowはノーコードツールでありながら、カスタムコードを書くことで標準機能では実現できない機能を実装できます。カスタムコードは自由度を上げる一方で、テストと保守の責任も増やすため、追加する範囲を決めてから使うことが大切です。

カスタムウィジェットの作成：FlutterFlowの可能性を広げる

公式のCustom Codeドキュメントでは、カスタムコードを次の5種類に分けて説明しています。

種類	できること
Custom Functions	ウィジェットやアクションのプロパティに使うDartの関数を定義する
Custom Actions	アクションフローの中で呼び出す処理を定義する（非同期処理が中心）
Code Files	独自のクラスや列挙型、ロジックをまとめて管理する
Custom Widgets	独自のFlutterウィジェットを作り、コンポーネントと同じように配置する
Configuration Files	AndroidやiOSのネイティブ設定ファイルを編集する

このうちCustom Widgetsを使うと、標準のウィジェットにはない独自のUIを作れます。たとえば特殊なグラフ表示や、業務に合わせた入力フォームなど、オリジナルの部品を開発してアプリに組み込めます。pub.devで公開されているパッケージを依存関係として追加することもできるため、Flutterの資産をそのまま活かせるのが強みです。

API連携：外部サービスとの連携でアプリをパワーアップ

FlutterFlowは、REST APIを通じて外部サービスと連携できます。地図、天気、決済、AIなどの機能を自社で作り込まずに利用できるため、開発コストを抑えながら機能を充実させられます。Growth以上のプランではSwagger/OpenAPIの定義を取り込めるため、APIの数が多い場合も設定の手間を減らせます。

連携先サービス	活用例
Google Maps Platform	アプリ内に地図を表示し、店舗や訪問先をマーキングする
OpenWeatherMap API	現在の天気や予報を表示する
Stripe	アプリ内で決済やサブスクリプションを扱う
自社の基幹システムAPI	在庫や顧客情報を読み込み、現場のスマホから更新する

API連携では、APIキーの管理と、相手のサービスが仕様を変えたときの追随が課題になります。キーを画面側に直接書き込まず、バックエンドを経由させる設計にしておくと、安全性と保守性の両方を保てます。

データベース連携：Firebase以外のデータベースとの連携

FlutterFlowは以前からFirebaseとの連携が強みでしたが、現在はSupabaseとの公式連携も用意されています。OAuthまたはAPIキーで接続し、Get Schemaを押すとテーブル構造がFlutterFlowに同期されます。公式ドキュメントでは、公開前にRow Level Security（RLS）を有効にし、アプリに合ったアクセスポリシーを設定するよう注意書きがあります。

既存のMySQLや社内のデータベースを使いたい場合は、バックエンドにAPIを用意し、FlutterFlowからはAPI連携として呼び出す形が基本です。これなら既存のデータをそのまま活かせます。

LibrariesとVS Code Extensionでチーム開発を広げる

複数のアプリで同じ部品を使う場合は、公式のLibrariesが役立ちます。コンポーネント、データ型、API呼び出し、カスタムコードなどをライブラリとして公開し、別のプロジェクトから読み込めます。ライブラリの公開にはブランチ機能が必要で、Growth以上のプランが対象です。

カスタムコードの量が増えてきたら、VS Code Extensionも検討しましょう。Growth以上のプランで使え、Custom Actions、Custom Widgets、Custom Functionsと、pubspec.yamlの依存関係を使い慣れたエディタで編集できます。

FlutterFlowで作ったアプリをストア公開する方法：審査通過のポイント

FlutterFlowで開発したアプリを公開するには、App StoreとGoogle Playの審査を通過する必要があります。FlutterFlowのワンクリック公開はBasic以上のプランで使えますが、審査そのものはAppleとGoogleが行うため、各ストアの基準を理解しておくことが公開をスムーズに進める鍵になります。

iOS App Store：審査基準と対策

AppleのApp Storeは、使いやすさ、安全性、コンテンツの品質について厳しい基準を設けています。審査に通るためには、次の点に注意が必要です。

審査項目	対策
機能の完全性と安定性	クラッシュや未完成の画面がない状態で提出する。複数の端末とOSで動作確認する
ユーザーインターフェース	Appleのデザインガイドラインに沿った、直感的に使える画面にする
コンテンツ	不適切な表現や権利侵害がない、正確な情報を載せる
プライバシー	収集するデータと利用目的をアプリ内とストア上で明示する
メタデータ	アプリ名、説明文、スクリーンショットを実際の内容と一致させる

FlutterFlowからApp Storeへ公開するには、Apple Developer Programへの加入が前提です。公式のApp Store公開手順では、App Store ConnectでApp Managerロールを付けたAPIキーを発行し、FlutterFlowに登録する流れが説明されています。ロールの付け忘れやIssuer IDとKey IDの取り違えは、よくある失敗原因です。

Google Play Store：審査基準と対策

Google Playも、アプリの品質と安全性を重視しています。App Storeとは観点が少し異なりますが、次の点を押さえて審査に臨みましょう。

審査項目	対策
機能とパフォーマンス	起動時間、応答性、バッテリー消費を確認し、快適に動く状態で出す
セキュリティ	ユーザーデータを安全に扱い、脆弱性のあるパッケージを使わない
コンテンツポリシー	暴力的な表現や違法行為を助長する内容を含めない
データの取り扱い	収集するデータ、利用目的、共有先をデータセーフティ欄とポリシーで説明する
広告	広告を入れる場合は、操作を妨げない表示にする

以前は「APKファイルを作ってGoogle Play Consoleから公開する」と説明されることがありましたが、現在の公式のGoogle Play公開手順ではAAB形式を使います。初回だけはFlutterFlowからダウンロードしたAABファイルを、Google Play Consoleの内部テストトラックへ手動でアップロードする必要があります。サービスアカウントのJSONを登録しておけば、2回目以降はFlutterFlowから配信できます。

プライバシーポリシー：作成時の注意点

App StoreとGoogle Playのどちらでも、プライバシーポリシーは審査の重要な要素です。アプリがどのような個人情報を集め、どのように使うのかを、分かりやすい言葉で説明する必要があります。個人情報を集める際にはユーザーから明確な同意を得て、ユーザーが自分のデータを確認したり削除したりできる手段も用意しましょう。

アカウント作成機能のあるアプリでは、アプリ内からアカウントを削除できる導線が求められる点にも注意が必要です。収集したデータを安全に保護する措置を取り、アプリの機能を変えたときはポリシーもあわせて更新します。内容に不安がある場合は、弁護士などの専門家に確認することをおすすめします。

FlutterFlowの未来：今後のアップデートと可能性

FlutterFlowは継続的に機能を追加しており、アプリ開発の選択肢として存在感を高めています。ここでは、公式ロードマップの読み方、AIとの連携、ノーコード開発全体の中での位置づけという3つの視点から、FlutterFlowの今後を展望します。

FlutterFlow Roadmap：最新情報と今後の展望

公式サイトにはRoadmapというページがありますが、2026年9月時点の内容は、今後のリリース予定を並べた一覧ではありません。アプリを構成する要素を3つの層に分け、それぞれでどの機能を使うかを示した学習ガイドです。

層	主な要素	採用時に見るポイント
UI Layer	ウィジェット、画面遷移、レスポンシブ対応	画面数、操作導線、端末ごとの表示
Logic Layer	状態管理、条件付きアクション、ルーティング	条件分岐、通知、権限の複雑さ
Data Layer	認証、データベース、API連携	Firebase、Supabase、既存DBとの接続

自社の要件がどの層に集中しているかを見ると、FlutterFlowが向いているかを判断しやすくなります。画面中心のMVPなら短期間で検証できますが、ロジック層やデータ層に複雑な要件が集まる場合は、設計の負荷が上がります。新機能の情報は、公式ブログや公式コミュニティで随時公開されているため、定期的に確認しておくと開発に役立ちます。

AIとの連携：より高度なアプリ開発へ

FlutterFlowはAIとの連携にも力を入れています。公式の料金表には、テキストの指示から画面や部品を作るAI Generationの利用回数がプランごとに設定されており、アプリにAIエージェントを組み込むAI Agentsの項目もあります。Growth以上ではAI Agentsの数が無制限です。

AIを活用すると、画面のたたき台作りや、定型的な部品の作成にかかる時間を短縮できます。またGrowth以上のプランには自動テストの機能もあり、変更のたびに主要な操作を確認する作業の一部を任せられます。ただし、AIが作った画面やロジックが要件を満たしているかを確かめるのは人の役割です。

ノーコード開発の進化：FlutterFlowが牽引する未来

FlutterFlowは、ノーコードとフルコードの中間にある開発環境として、今後も重要な役割を担うと考えられます。プログラミングの知識がなくても画面を作れ、必要になればDartのコードで拡張できるため、非エンジニアとエンジニアが同じプロジェクトで協力しやすいのが特徴です。

一方で、すべてのアプリにFlutterFlowが最適というわけではありません。FlutterFlowはモバイルアプリや利用者向けのMVPに強みがありますが、承認フローが多い社内システムや、複雑な管理画面が中心のWebアプリでは、Bubbleのほうが作りやすく保守しやすい場合もあります。ツールの進化を追うことと同じくらい、作りたいものに合った道具を選ぶことが大切です。

FlutterFlowコミュニティに参加しよう：情報交換とスキルアップの場

FlutterFlowを使いこなすうえで、コミュニティは心強い情報源になります。ここでは、公式の場、国内外のオンラインコミュニティ、学習の機会の3つに分けて紹介します。

公式フォーラム：最新情報をキャッチアップ

公式のFlutterFlow Communityは、もっとも信頼できる情報源です。ユーザー同士の質問や議論が活発に行われているほか、公式ドキュメント、学習コンテンツのFlutterFlow University、Help Center、不具合を報告するReport an Issueへの導線もまとまっています。

エラーが出たときは、まずここで同じ症状の投稿を検索すると解決の近道になります。ただし、事業の要件やセキュリティの判断は、自社側で責任を持って決める必要があります。

公式の場	主な内容
FlutterFlow Community	Q&A、機能リクエスト、ユーザー同士の議論
Documentation	機能ごとの設定手順と仕様
FlutterFlow University	基礎から応用までの学習コンテンツ
Help Center / Report an Issue	アカウントの問い合わせ、不具合の報告

オンラインコミュニティ：仲間と繋がり、知識を共有

公式以外にも、ユーザーが運営するオンラインコミュニティがあります。国内では、日本語でFlutterFlowの情報を交換できるFlutterFlowカフェが知られており、質問対応やイベントの開催も行われています。

海外のSNSや掲示板にも、FlutterFlowの話題を扱うグループがあります。これらは公式が運営しているわけではないため、得た情報は公式ドキュメントで裏を取ってから使いましょう。

コミュニティの種類	特徴	主な内容
FlutterFlowカフェ	日本語で情報交換ができる国内コミュニティ	Q&A、イベント情報、ノウハウ共有
海外のSNS・掲示板	世界中のユーザーの事例に触れられる（非公式）	Q&A、成果物の共有、ニュース

イベントとワークショップ：スキルアップの機会

体系的に学びたい場合は、公式のFlutterFlow Universityから始めるのがおすすめです。基礎から順番に学べるため、独学で抜けやすい設定や考え方を補えます。

コミュニティ主催の勉強会やオンラインセミナーでは、他の参加者の作り方や失敗談に触れられます。告知は各コミュニティで行われるので、定期的にチェックしておきましょう。

学習の場	特徴	主な内容
FlutterFlow University	公式の学習コンテンツ	基礎から応用まで体系的に学べる
コミュニティイベント	各コミュニティが主催	特定のテーマに絞った内容が多い
オンラインセミナー	場所を選ばず参加できる	最新機能や事例の紹介が多い

自社で進める範囲と相談すべき範囲

自社で進めやすいのは、画面案の作成、プロトタイプ、簡単なログイン、フォーム、一覧表示といった範囲です。社内で操作に慣れた担当者がいれば、無料プランや下位プランで十分に検証できます。学習用のアプリを題材にした進め方はFlutterFlow学習支援アプリ開発ガイドでも整理しています。

一方で、課金、個人情報、複数の権限、外部API、既存データベースとの連携が入る場合は、早めに専門家へ相談したほうが安全です。これらは画面を作り始めてから変えると影響範囲が大きく、作り直しの原因になりやすいためです。

ノーコード総合研究所では、FlutterFlowで進めるべきか、Bubbleで業務システムとして作るべきか、スクラッチ開発を組み合わせるべきかを比較したうえで提案しています。支援の際は、最初に利用者、必要な機能、連携先、公開方法を整理し、標準機能で作れる部分と、カスタムコードやバックエンドが必要な部分を切り分けます。MVPをどこまでFlutterFlowで作り、どこから別の構成にするかの判断はFlutterFlowでのMVP開発ガイドでも解説しています。

まとめ

FlutterFlowは、2026年9月時点でも、アプリ開発を短期間で検証しやすい有力な開発環境です。画面、ロジック、データ連携を視覚的に組み立てられ、カスタムコード、Supabase連携、Libraries、VS Code Extensionを使えば、標準機能の外側まで拡張できます。App StoreとGoogle Playへの公開もFlutterFlowから進められ、公式コミュニティや国内のコミュニティで情報を集めることもできます。

一方で、採用前には課題を正直に見ておく必要があります。複雑なロジックはカスタムコードに頼ることになり、チーム開発やコードの取り出しには上位プランが必要です。オフライン対応はモバイルに限られ、WebアプリはSEOが必要なページに向きません。これらを知らずに進めると、公開直前にプランの変更や作り直しが発生します。

判断に迷う場合は、最初からツールを決め打ちしないことが大切です。まずは標準機能で小さく検証し、課金や個人情報、既存システム連携が絡む部分だけを専門家と切り分ける進め方が現実的です。 FlutterFlowでMVPを作る、Bubbleで業務システムとして仕上げる、スクラッチ開発を組み合わせるなど、目的によって最適な構成は変わります。ノーコード総合研究所では、要件の整理から技術選定、料金プランの選び方、公開後の保守体制まで一緒に検討できます。作りたいアプリの利用者と必要な機能を書き出すところから、お気軽にご相談ください。

費用の目安：生成AI×ノーコードで進む業務システム開発｜費用・期間・失敗回避の型を公開

関連する事例・活用例：【完全保存版】新規事業×SNS活用の成功戦略｜ゼロから始める実践ノウハウと事例紹介

群別サービス：受託開発