ノーコード開発でも、AIエージェント連携と品質担保の両立が課題になりつつあります。2026年6月2日、FlutterFlowは公式Xアカウントで「FlutterFlow 7.0 shipping today」と告知し、MCP対応やTest Pilot AI QA、Supabase Edge Functions連携などを含む大型アップデートを展開しました。
この記事では、公式告知とドキュメントに基づき、7.0で何が変わるのか、開発速度と品質のどちらがどう改善されるのかを整理します。
この記事でわかること
- FlutterFlow 7.0の公式告知内容と、2つの開発テーマ（build faster / build better）
- MCP対応の仕組みと、Claude Code・Cursorなど既存エージェントとの連携方法
- Test Pilot AI QAの位置づけと、従来のAutomated Testsとの違い
- Supabase Edge Functions連携と、バックエンド実装の進め方
- Test Mode強化・AI Agents・プロジェクト整理など、その他の変更点
FlutterFlow 7.0が目指す2つの軸
https://x.com/flutterflow/status/2061869332783878177
FlutterFlow公式の告知では、7.0は「開発者が最も気にする2つのこと」にフォーカスすると説明されています。
build faster（より速く作る）
- MCP support（MCP対応）
- Test Pilot AI QA
build better（より良く作る）
- Supabase Edge Functions連携
- Test Mode upgrades（Test Modeの強化）
- Smarter AI Agents（AIエージェントの強化）
- Project organization（プロジェクト整理機能）
あわせて「250M+ users running on apps built with FlutterFlow」とも記載され、FlutterFlowで構築されたアプリの利用者規模の大きさが強調されています。この数字はFlutterFlow公式の発表に基づくもので、第三者による独立検証ではありません。規模感の指標として読むのが妥当です。
7.0は2026年6月2日時点で提供開始（shipping today）とされており、詳細なリリースノートはFlutterFlow Changelogでも随時更新されます。現時点のChangelogには、5月8日の「FlutterFlow MCP」や5月18日の「GenUI & Page/Component Gen Updates」など、7.0に含まれる機能の一部が先行して記載されています。
MCP対応でエージェントとビジュアル開発が一体化
https://docs.flutterflow.io/flutterflow-cli/build
MCP（Model Context Protocol）は、AIアプリケーションと外部ツールを接続するためのオープン標準です。FlutterFlowはこの標準を採用し、Claude Code、Gemini CLI、Codex、Cursor、GitHub Copilotなど、MCP対応のコーディングエージェントからFlutterFlowプロジェクトを直接読み書きできるようにしました。
従来、FlutterFlowでAIを使う場合は「エージェント側で生成 → 結果を手動でビルダーに反映」という二画面作業が発生しやすく、ウィジェット構成やデータソースが複雑になるほど摩擦が増えます。FlutterFlowチームのコミュニティ告知でも、この点が「最も要望の多かった機能」として挙げられています（FlutterFlow MCP Is Here）。
MCP対応後の流れは次のとおりです。
flutterflow ai initでワークスペースを作成する- エージェントがMCPサーバー経由でFlutterFlowのクラウド上のプロジェクトAPIを呼び出す
- ページ、コンポーネント、テーマ、アクション、APIエンドポイントなどをエージェントが直接変更する
- 結果をビジュアルビルダーで確認・微調整する
公式ドキュメントでは、エージェントが変更できる範囲としてページ・コンポーネント・アプリ状態・テーマ・ナビゲーション・アクション・APIエンドポイントなどが明示されています。一方、Firebaseプロジェクトの新規作成やApp Store申請、シークレット管理など、FlutterFlowプロジェクト外の作業は対象外です。
CLIの導入は dart pub global activate flutterflow_cli で行い、APIトークンはアカウント設定から取得します。flutterflow ai mcpコマンドでMCPサーバーを各エージェントに登録でき、BYOA（Bring Your Own Agent）として好みのエージェントを選べます。プラン比較表では、Basicプラン以上で「MCP Server (Experimental)」が利用可能とされています。
ビジュアル作業が得意な場面はこれまでどおりビルダーが速く、繰り返しの構造変更や大規模リファクタリングはエージェントに任せる、という住み分けが現実的です。
Test Pilot AI QAが品質面に足すもの
7.0の「build faster」に含まれるもう一つの柱が、Test Pilot AI QAです。公式告知では名称と位置づけのみが示されており、2026年6月初旬時点では専用のドキュメントページは公開されていません。
FlutterFlowには、すでに「Automated Tests」という自動テスト機能があります。これはウィジェット操作（タップ、テキスト入力など）と結果検証（Expect Result）をステップとして定義し、内部ではFlutterのintegration testingフレームワーク向けコードを生成する仕組みです。ただし公式ドキュメントでは「FlutterFlow上でテストを実行する機能はまだサポートしていない」と明記され、コードをダウンロードしてローカルまたはFirebase Test Labで実行する必要があります。
Test Pilot AI QAは、この既存のAutomated Testsを置き換えるのではなく、AIを活用したQA（品質保証）の新レイヤーとして位置づけられています。名称から、テスト設計やカバレッジ拡張をAIが支援する方向性と読めますが、具体的なUIやプラン制限は公式の追加情報が出るまで、告知文の範囲で理解するのが安全です。
開発チームにとっての意味は明確です。ノーコードで作るほど、手動の画面確認だけではリグレッションを拾い切れません。7.0は「作る速度（MCP）」と「壊れにくさ（Test Pilot）」を同時に押し上げる構成であり、小規模チームでもエンタープライズ寄りの開発サイクルに近づける意図がうかがえます。
Supabase Edge Functionsをアプリ内から扱いやすく
Supabase Edge Functionsは、Deno上で動くTypeScriptのサーバーレス関数で、デプロイ後は https://[PROJECT_ID].supabase.co/functions/v1/[関数名] からHTTPで呼び出せます。決済、外部API連携、秘匿キーを使う処理など、クライアントに載せたくないロジックの定置場として使われます。
FlutterFlowは以前からSupabase連携（データベース、認証）に対応しており、Edge Functions自体もAPI Callとして接続する方法はコミュニティで共有されていました。7.0では、このEdge Functions連携が「build better」の中核として前面に出ており、バックエンドロジックをFlutterFlowの開発フローに組み込みやすくする改善と考えられます。
Supabase公式のデプロイ手順では、supabase functions deployで関数をグローバルに配信し、クライアントからはPublishable Keyを使って呼び出す流れが標準です。FlutterFlow側では、Action FlowからAPI Callを発火させる形が基本になります。Stripe決済やOpenAI Assistant APIをEdge Function経由で呼ぶチュートリアルもコミュニティに存在し、実運用のパターンは確立しつつあります。
ローコードでUIを組みながら、サーバー側はTypeScriptで型安全に書く。この分業は、FlutterアプリをFlutterFlowで作りつつ、バックエンドだけSupabaseに寄せたいチームに特に相性が良いです。
Test Mode・AI Agents・プロジェクト整理の強化
7.0告知の「build better」には、次の3点も含まれます。
Test Mode upgrades
Test Modeは、Web版アプリをホットリロード付きで試すモードです。既存ドキュメントではセッション時間が30分とされ、カメラなど一部機能は使えない制約も記載されています。7.0では「upgrades」とだけ示されており、時間制限の緩和や実機テスト対応など、具体的な変更内容は公式の追記待ちです。Local Run（デスクトップアプリから実機へホットリロード）との使い分けは引き続き重要です。
Smarter AI Agents
FlutterFlowはアプリ内AIエージェント（OpenAI、Anthropic、Googleなど）の構築機能も持ちます。Changelogの5月18日付エントリでは、GenUI（コンポーネントとアクションブロックを定義し、AIが動的UIを組み立てる仕組み）や、AI Page/Component Generatorの品質向上が紹介されています。7.0の「Smarter AI Agents」は、この系譜の強化と読むのが自然です。
Project organization
大規模化したプロジェクトでは、ページやコンポーネントのフォルダ分け、Librariesによるモジュール共有、命名規則の統一が保守性を左右します。FlutterFlowの生成コードも、UIで作ったネストフォルダがそのままエクスポート先のディレクトリ構造に反映されます。7.0での「Project organization」は、こうした整理機能の強化として期待できます。
7.0を試すときの進め方
まずは既存プロジェクトでMCPワークスペースを切るのが手早いです。flutterflow ai initでプロジェクトIDを紐づけ、普段使っているエージェントを起動して「プロフィール画面を追加」「プライマリカラーを変更」など、小さな変更から動作を確認してください。ビジュアルビルダーと同時編集する場合は、楽観的ロックにより競合時にエージェントのプッシュが拒否される点に注意が必要です。
Supabaseを使っている場合は、既存のEdge FunctionをFlutterFlowのAPI Callに接続し、7.0の連携改善がどこまで効くかを検証するのがよいでしょう。Test Pilot AI QAについては、公式ドキュメントやChangelogに詳細が載り次第、Automated Testsとの併用方針を決めるのが現実的です。
FlutterFlow 7.0は、250Mユーザ規模の実績を背景に、AIエージェント統合とバックエンド・QAの両面を同時に押し上げるリリースです。ノーコード/ローコードでFlutterアプリを作るチームにとって、単なるUIビルダーの更新ではなく、開発パイプライン全体の再設計に近い一手と言えます。