2026年4月22日〜24日に開催された Google Cloud Next '26 へ参加してきました。昨年に引き続きアメリカ・ラスベガスで開催され、弊社からはMA部の平井・林・木野、AI事業戦略部の川田・桜井の5名が参加しました。なお、昨年参加した様子は以下の記事で紹介しています。 techblog.zozo.com 今年はAIエージェントを『実戦』に投入し、いかに賢く、安全に使うのかに焦点を当てたセッションが多い印象でした。本記事では、現地での様子と特に興味深かったセッションをピックアップして紹介します。 また、Recapのオンラインイベント「 Google Cloud Next 2026 Recap in ZOZO 」を2026年5月18日に開催しました。このイベントでは、Google Cloud Next '26について、今回のテックブログで紹介できなかった内容など、より詳細に共有しております。 現地の様子 私たちは会期の前々日にラスベガスの空港に到着したのですが、空港内にはさっそくGoogle Cloud Nextの広告が流れており、イベントに向けた熱意が一気に高まりました。 Google Cloud Nextの広告を見かけたハリー・リード国際空港の様子 昨年に引き続き会場は、ラスベガスのマンダレイ・ベイホテル コンベンションセンター。非常に盛り上がっており、特に各セッションや展示ブースでのデモでは参加者から活発な質問が飛び交っていたのがとても印象的でした。 熱気に包まれる会場内の様子 以降では、現地に参加したメンバーが気になったセッションを紹介します。 セッション紹介 What's new in Cloud Run こんにちは、MA部配信基盤ブロックの木野です。私は通知系（LINE/Mail/アプリ）の開発をしています。 公開資料「 What's new in Cloud Run 」のP.1より引用 このセッションでは、Cloud Runが単なるWebアプリのデプロイ先ではなく、より幅広いワークロードを受ける汎用実行基盤へ広がっていることが紹介されていました。セッション全体のメッセージは、Cloud Runが「on-demand compute for everyone」であるという点に集約されており、Vibe Coded Apps、AI Agents、AI Models、Large Scale Appsという4つの観点から新機能が説明されていました。 冒頭では、AI Studioで生成したマルチプレイヤーゲームをそのままCloud Runに公開するデモが紹介されており、Cloud Runが「作ったものをすぐにクラウドへ出す」ための基盤として強く打ち出されていました。また、Cloud Run公式のFully managed MCP Serverも発表されており、人間が操作する実行基盤というだけでなく、AIエージェントから直接デプロイや管理の対象になる基盤へ寄ってきていることも印象的でした。 GA対応したCloud Run Worker Pools 私が特に興味を持ったのは、Cloud Run worker poolsのGAです。Worker poolsは、HTTPリクエストを受けることが本質ではない常駐workerやpull consumer、runnerのような処理に対して、Cloud Run上のより自然な置き場を与える機能だと感じました。 Cloud RunにはこれまでもServiceやJobがありましたが、Serviceはrequest-driven、Jobはrun-to-completionであり、そのどちらにもきれいに当てはまらない処理を表現しづらい場面がありました。セッションでも、Temporalのworkerのようなlong polling前提の処理がworker poolsに適している例が紹介されていました。 この点は、私たちの配信基盤にもそのままつながります。例えばPub/Subのpull consumerや、ループし続ける常駐worker、定期的に状態を見て後続処理を進めるfinalizerのような処理は、実態としてはHTTPエンドポイントを持つことが本質ではありません。それにもかかわらず、これまではCloud Run Serviceの形に寄せるためにヘルスチェックや待受用のコードを持たせていました。worker poolsが一般提供されたことで、こうした処理をより素直な形で実装でき、配信基盤の見通しや運用性を改善できる可能性があります。 Cloud Run Instancesとbuilt-in dev loop 公開資料「 What's new in Cloud Run 」のP.30より引用 もう1つ興味深かったのが、Cloud Run Instancesとbuilt-in dev loopの流れです。セッションでは「ローカルでクラウドをエミュレートしようと頑張るのではなく、Cloud Run上でそのまま開発する」というメッセージが明確に打ち出されていました。ローカルの変更をCloud Run instanceに同期し、そのままdev scriptをクラウド側で実行することで、pushしてデプロイを待つ前に即時検証できる世界観が示されていました。さらに、SSH supportも合わせて紹介されており、Cloud Runを本番の実行基盤として使うだけでなく、開発や調査の場としても扱う方向性が見えてきたと感じました。 これは、複数サービスをまたぐ検証が多い配信基盤の開発体験にとって特に大きい変化だと思います。現在でもローカルでの統合テストやcontainer_testのような仕組みは有効ですが、実サービス依存に近い確認をしたい場合は、どうしてもdev環境への反映待ちや、共有環境ゆえの状態差分が問題になります。もしbuilt-in dev loopが成熟すれば、各開発者が自分の変更をCloud Run側へすぐに反映し、実サービス依存に近い状態で軽く検証を回せるようになります。さらに、人間が行う確認フローとPR後のE2EやCIの構成も近づけられる可能性があり、複数サービスをまたぐ開発・検証体験を大きく変えるアップデートだと感じました。 加えて、このセッションはCloud Runの新機能を個別に列挙するだけでなく、「Cloud Runはどこまで守備範囲を広げようとしているのか」という観点で見ると、とても示唆が多い内容でした。これまではHTTPサービスをスケールさせるためのプロダクトという見方が中心だったと思いますが、今回の発表では、AIエージェントの実行基盤、長時間動くworkerの置き場、さらにはCloud Run上での開発ループまで含めて整理されていました。配信基盤のように非同期処理、複数サービス連携、運用時の可観測性が重要なシステムにとっては、単なる機能の追加以上に、Cloud Runをどう使うかの前提そのものが変わり始めていると感じています。 セッションを通しての感想 Cloud Runは長らく「HTTPサービスを手軽に動かす場所」という印象が強かったのですが、今回のセッションを通して、AIエージェント、常駐worker、開発ループまで含めたより広い実行基盤へ進化していることがよく分かりました。特に私たちのように、非同期処理や複数サービス連携を多く持つシステムにとっては、今後の設計や検証フローを見直すきっかけになるセッションでした。 What's new in AlloyDB: Scale PostgreSQL for agentic AI and hybrid clouds こんにちは、MA部MAシステム開発ブロックの平井です。私は自社マーケティングシステム「ZMP」の開発をしています。ZMPではユーザー毎に最適化された情報を配信するパーソナライズ配信機能があり、そのデータベースとしてGoogle CloudのAlloyDBを利用しています。そこで、私はAlloyDBに関するセッションを聴講しました。 「What's new in AlloyDB」セッション会場の様子 このセッションでは、AlloyDBのアップデートをエンタープライズ・分析機能の観点、AI関連機能の観点から説明していました。 エンタープライズ・分析機能に関するアップデート Hot Standby 公開資料「 What’s new in AlloyDB: Scale PostgreSQL for agentic AI and hybrid clouds 」のP.8より引用 Hot Standbyは、スタンバイ中のノードがWALを受け続けながらアクティブなインスタンスとして動く機能です。この機能によって、起動時間の短縮とプライマリー昇格の加速によるRTOの改善、メモリーキャッシュの暖気とフェイルオーバー後のパフォーマンス低下の抑制により一貫したパフォーマンスの維持が可能になります。 Read Pool Autoscaling 公開資料「 What’s new in AlloyDB: Scale PostgreSQL for agentic AI and hybrid clouds 」のP.9より引用 Read Pool Autoscalingは、読み取りインスタンスがワークロードに応じて自動でスケーリングする機能です。また、事前に決められたスケジュールでスケーリングすることも可能です。例えばサイバーマンデーやブラックフライデーなどあらかじめ高負荷が予想される場合にとても有効です。私たちのパーソナライズ配信システムでも読み取りインスタンスを利用していて、負荷がスパイクする傾向があるため、Read Pool Autoscalingが一般提供された際は、その効果を速やかに検証したいと考えています。 Transparent Query Forwarding 公開資料「 What’s new in AlloyDB: Scale PostgreSQL for agentic AI and hybrid clouds 」のP.11より引用 Transparent Query Forwardingは、プライマリーノードで受け付けた読み取りクエリを読み取りノードにフォワードする機能です。読み取りノードにクエリをフォワードすることでプライマリーノードの負荷を軽減し、クラスター全体のリソースを有効活用するために設計されました。アプリケーション側で必要だったライブラリを利用したプライマリノードと読み取りノードのコネクションの作成/クエリフォワード設定が不要になります。また、書き込みと読み込みの一貫性を担保しているため、アプリケーション側で古い情報を参照する心配がありません。 LakeHouse Federation for AlloyDB 公開資料「 What’s new in AlloyDB: Scale PostgreSQL for agentic AI and hybrid clouds 」のP.16より引用 Lakehouse Federation for AlloyDBは、AlloyDBからBigQueryやIcebergにあるデータを簡単にクエリできる機能です。AlloyDB上のトランザクションデータとBigQuery上の履歴データ、集計データを結合することで統合的な分析が可能になります。 私たちのパーソナライズ配信システムでは、BigQuery上の集計データをAlloyDBにロードして、配信処理に利用しています。Lakehouse Federation for AlloyDBを経由したBigQueryのクエリ時には、コンピューティングの料金が発生するためリアルタイムでの利用は難しいですが、BigQueryを利用した集計データをAlloyDBにロードする処理をより簡素化が可能です。セッションではAlloyDB上のリアルタイムなデータとLakehouse上の履歴データを利用して、実績を比較する例が紹介されていました。 以下の画像は、AlloyDBとLakehouseがシームレスに連携することで、運用と分析の統合的なプラットフォームとして活用できることを表現した図です。AlloyDBからLakehouseへはDatastream機能が提供されていて、LakehouseからAlloyDBへもReverse ETL機能が提供されています。相互のデータ連携機能が提供される一方で、データ連携せずに統合的なデータアクセスを実現する手法として、Lakehouse Federation for AlloyDBが紹介されていました。 公開資料「 What’s new in AlloyDB: Scale PostgreSQL for agentic AI and hybrid clouds 」のP.15より引用 AI関連機能のアップデート AI関連機能で紹介されていた内容は以下になります。 ベクトル検索の改善 公開資料「 What’s new in AlloyDB: Scale PostgreSQL for agentic AI and hybrid clouds 」のP.30より引用 AlloyDB開発チームはベクトル検索を今後の検索機能における中核と位置付け、パフォーマンス向上に注力してきました。Google researchが開発したScaNNでは数百億のベクトルまで拡張でき、高速なクエリパフォーマンスとインデックス構築を実現しています。また、業界標準のHNSWのパフォーマンス向上にも取り組んでいて、オープンソースのpgvectorと比較して最大4倍高速な検索を実現できるそうです。 ハイブリッド検索 公開資料「 What’s new in AlloyDB: Scale PostgreSQL for agentic AI and hybrid clouds 」のP.31より引用 ハイブリッド検索は完全一致を行うためのキーワード検索とセマンティックな検索を行うためのベクトル検索を統合した高度な検索機能です。この検索により固有名詞や型番などは確実にヒットさせつつ、曖昧な表現を含んだ単語でも関連性の高い結果を取得できます。既存のキーワード検索においても、RUM拡張のサポートによるパフォーマンス改善に加え、BM25アルゴリズムの活用によって検索精度の向上を実現しています。キーワード検索自体の機能改善による、それをベースとしたハイブリット検索の精度とパフォーマンスの向上にも取り組んでいるそうです。 Geminiを利用したAI関数の拡張 公開資料「 What’s new in AlloyDB: Scale PostgreSQL for agentic AI and hybrid clouds 」のP.32より引用 ai.if、ai.rank、ai.generateといった関数を活用することで、LLM（大規模言語モデル）の強力な機能をクエリインタフェース上で直接享受できます。例えば、ai.rank関数では、上記画像にあるような「サントリーニ島での夏休暇用のシャツ」を検索する場合、クエリ結果がGeminiに送信され、Geminiが現実世界の情報を加味して最適にソートした結果を返してくれます。 セッション全体に対する感想 AlloyDBがAIエージェント時代のデータベースとして選択されるために単なるデータ蓄積を超えた様々な新機能を開発していることが印象的でした。システムの可用性と信頼性を担保するためのエンタープライス機能、データ分析の基盤として活用するための分析機能、AIのパワーを活用したAI機能と今回紹介しただけでも様々な領域における機能が紹介されていて、データベースに求められている要件が非常に多岐に渡っていることを感じました。 また、私たちのパーソナライズ配信システムではAlloyDBでのベクトル検索機能を利用できておらず、AlloyDB開発チームがベクトル検索に投資している点からも、利用できるユースケースがないか探してみようと思います。 Generative UI for any agent, anywhere: A2UI, AG-UI, MCP Apps, and more こんにちは、MA部MAシステム開発ブロックの林です。私は自社マーケティングシステム「ZMP」の管理画面をフロントエンド・バックエンドを横断して開発しています。 現在のAIとの対話はテキストベースが主流ですが、テキストだけではユーザー体験として不十分なケースが多くあります。Generative UIとは、AIエージェントがユーザーに合わせたインタフェース（UI）を動的に構成するための手法です。ここでは、Generative UI関連のセッションで紹介された技術と、現地で体験したデモについてレポートします。 公開資料「 Generative UI for any agent, anywhere: A2UI, AG-UI, MCP Apps, and more 」のP.1より引用 MCP Apps まず紹介されたのが、Anthropic社が提唱するModel Context Protocol（MCP）の公式拡張「MCP Apps」です。従来のMCPがテキストやデータを返すのに対し、MCP AppsではエージェントがインタラクティブなUIを返します。UIは会話の中に直接埋め込まれ、ユーザーはチャットの流れから離れることなくアプリを利用できます。ChatGPT・Claude・Geminiなど主要なホストがすでに対応しています。 MCP Appsのスピーカーは、UIの形式を大きく3種類に分類して説明していました。 Predefined UI （事前定義）：決まったフォーマットのUIを返す Declarative UI （宣言的）：コンポーネント構造をJSONで指定してUIを組み立てる Generative UI （生成的）：ゼロからUIをその場で生成する MCP Appsはどの形式にも依存しない（agnostic）設計のため、後述するA2UIやAG-UIとも連携できます。A2UIやAG-UIが生成したUIをMCP Appの中でレンダリングしたり、逆にMCP Apps自体をA2UIやAG-UIでレンダリングしたりするコンポーネントとして扱うことも可能です。 A2UI 次に、Google社が提唱するエージェント駆動型インタフェース向けの「宣言型UIプロトコル」であるA2UIが紹介されました。 A2UIでは、あらかじめコンポーネントのカタログを定義しておき、エージェントはそこから選ぶ形でUIを組み立てます。エージェントが送信するのはJSONによるコンポーネント構造とデータのみで、実際の描画は自前のデザインシステム（ReactやFlutterなど）が行います。A2UI標準のBasic Catalogもデザインシステムとして利用できます。 コンポーネントを自前で管理する構造はセキュリティ上の利点もあります。たとえば「クリックターゲット内に隠しフォームを埋め込むUI生成」といった攻撃も、定義済みコンポーネントのみを使う構成であれば防御できます。 また、トランスポート不問のため、AG-UIやMCPと組み合わせることも可能です。 A2UIはすでにGemini Enterpriseにてプレビューで提供が開始されています。 AG-UI そして、CopilotKit社が提唱する「エージェントとフロントエンドの接続を標準化するプロトコル」として、AG-UIが紹介されました。MCPがツールとの接続、A2Aが他のエージェントとの接続を担うのに対し、AG-UIはユーザー向けフロントエンドとの接続を担う位置づけです。 AG-UIのスピーカーは、Generative UIの手法は制御の度合いによってグラデーションがあると説明していました。 Controlled ：アプリ側が厳密に制御するUI Declarative ：JSONなどで宣言的に構成するUI A2UIはここに位置づけられる Open-ended ：AIが自由に生成するUI MCP Appsはここに含まれる手法の1つ AG-UIはこのグラデーション全体をカバーし、ユースケースに応じて各技術と連携・使い分けができる設計になっています。 AKQA社の事例紹介 本パートでは、ブランド企業がGenerative UIに取り組むべき理由について説明がありました。従来のWebサイトはナビゲーション中心のユーザー体験に最適化されています。しかし現在では、多くのユーザーが事前にChatGPTやGeminiで情報収集してサイトを訪れるため、必要な情報が見つからなければ再びAIに戻ってしまいます。そのため、ユーザーの意図に直接応答できる仕組みの重要性が高まっています。 デモでは、ユーザーの意図を機能的・感情的・社会的という3つの側面に分解するアプローチが紹介されました。たとえば「コンバージョンを落とさずに不正検知を改善したい」といった入力から、ユーザーの緊急度や心理的背景を推定し、それに応じたページを動的に生成します。従来は人手でPDF資料を作成しており1件あたり6時間以上かかっていた作業が、この仕組みによってWeb上では約10秒で完了するようになったと説明されていました。 GenLatte Generative UIが組み込まれたラテアート注文アプリを「GenLatte」ブースにて実際に体験できました。ラテアートのデザインをリテイクする指示を出したところ、AIから私専用の追加質問がいくつか投げられました。質問は単一選択のもの、スライダーで微調整するもの、テキスト入力のものなど複数パターンがありましたが、どれも私のラテアートの内容に応じた質問で、人間が答えやすい形式のUIとして提示されました。生成されたラテは実際に飲むことができ、本当にお店でラテを注文しているようでした。Generative UIの可能性を実感できるブースでした。 公開資料「 Personalize the user experience with generative UI 」のP.19より引用 Generative UIが組み込まれたラテアート注文アプリを体験できる「GenLatte」ブース（左）と生成されたラテ（右） 自社での活用の可能性 今回のセッション・デモを通じて、Generative UIは自社でも応用可能だと感じました。 現在の自社マーケティングシステムは、マーケターがSQLを直接書いてセグメントを作成することを前提に設計されています。しかし、すべてのマーケターがSQLを書けるわけではないこと、「すでにあるSQLを元に年齢で配信を出し分けたい」といった軽微な修正であっても毎回SQLを書く必要があることに対して改善を求める声がありました。 一方で、エンジニア側も対応に十分な工数を割けていない状況です。過去にはUI上で条件を絞り込める機能を開発したこともありましたが、後から追加になった絞り込み条件などマーケターの要望に追従できず、利用されづらい状態になっていました。 こうした課題に対して、AIによるSQL生成とGenerative UIを組み合わせるアプローチが有効だと考えています。具体的には、以下のような流れです。 マーケターが自然言語でセグメントの条件を入力する AIがSQLを生成する 生成されたSQLの実行結果（セグメント数）や、既存SQLとの差分などの情報を、Generative UIで動的に構成されたダッシュボードとしてマーケターに提示する このような仕組みが実現すれば、セグメント作成をマーケター完結で迅速かつ柔軟に行えるようになります。結果として、マーケターの作業工数だけでなく、エンジニアへの問い合わせ・対応コストの削減にもつながると考えています。 What's new in Google Cloud's agent platform こんにちは、AI事業戦略部AIソリューション開発ブロックの桜井です。私は社内の業務・事業へAIをどのように組み込み、継続的に価値を出せる形へ育てていくかに関心を持って開発・検証に取り組んでいます。 公開資料「 What's new in Google Cloud's agent platform 」のP.1より引用 このセッションでは、Google Cloud上でAIエージェントを構築し、本番業務に展開していくためのAgent Platformのアップデートが紹介されました。これまでVertex AIとして提供されてきた機能が「Gemini Enterprise Agent Platform」に統合され、Agent時代における新しいインフラ環境として生まれ変わりました。 セッションの冒頭で印象的だったのは、AIエージェントの位置づけが「チャットで質問に答えるもの」から「現実の業務タスクを実行するもの」へ移りつつある、という整理です。 公開資料「 What's new in Google Cloud's agent platform 」のP.5より引用 これまでのエージェントは、ユーザーがチャットで問いかけ、その場で応答を返すInteractive Chat Agentsが中心でした。一方で、これからはバックグラウンドでデータやシステムを監視し、必要に応じて判断・処理・通知するBackground Processing Agentsや、音声・映像を使って人と自然にやり取りするReal-time Audio/Video streaming Agentsも重要になると紹介されていました。 この考え方は、社内業務にAIを組み込むときにも非常に重要だと感じました。例えば、問い合わせ内容から注文情報や配送状況を確認して一次調査をまとめる、商品説明文の改善候補を商品マスタやレビュー傾向から整理する、BigQuery上の販促結果を定期的に確認して異常値を通知する、といった業務は単発のチャット応答ではなく「一定時間、業務を預ける」タイプのタスクです。 Agent Platform全体は、Build、Scale、Govern、Optimizeという4つの領域で整理されていました。 公開資料「 What's new in Google Cloud's agent platform 」のP.6より引用 Buildでは、ADKやAgent Studio、Agent Garden、MCP、A2Aなどを使ってエージェントを作るための機能が提供されます。Scaleでは、Agent RuntimeやAgent Sandbox、Agent Memory Bank、Agent Sessionsなどを使って、エージェントを本番ワークロードとして動かすための仕組みが用意されています。Governでは、Agent Identity、Agent Gateway、Agent Registry、Agent Policy、Model Armorなどにより、権限や通信、セキュリティポリシーを統制します。Optimizeでは、Agent EvaluationやAgent Observability、Agent Simulationなどを使って、運用中の品質を継続的に確認していきます。 特に興味を持ったのは、Agent Runtimeのアップデートです。 公開資料「 What's new in Google Cloud's agent platform 」のP.13より引用 Runtime enhancementsでは、1秒未満の高速なコールドスタート、数秒でのプロビジョニング、最大7日間のLong-running Operation、双方向ストリーミング、リソースレベルのIAM binding、Python、Java、TypeScript、Goへの対応、プロジェクトあたり3,000エージェントまでのスケールなどが紹介されていました。これにより、エージェントを長時間・多段階の業務を担う実行単位として扱うための基盤が提供されます。 さらに、Agent Runtimeは実行環境だけでなく、セッションやメモリ、サンドボックス、評価、Observabilityとつながる形で説明されていました。社内でエージェントを使う場合、単にモデルへプロンプトを送るだけでは足りません。どのユーザーの依頼で、どのセッションの文脈を持ち、どのデータを参照し、どのツールを呼び出し、どのような結果を返したのかを追える必要があります。商品情報、FAQ、問い合わせ履歴、販売実績などを横断する業務ほど、セッション管理やメモリ、実行ログが重要になります。 Governの領域では、Agent IdentityとAgent Registryの考え方が実運用に直結すると感じました。 公開資料「 What's new in Google Cloud's agent platform 」のP.16より引用 Agent Identityでは、エージェントごとにIDを持たせ、最小権限の考え方で権限を付与し、エージェントの操作を監査できるようにすることが説明されていました。これは、業務システムに接続するエージェントを「誰かの権限を使って動くスクリプト」としないために重要です。商品情報を読むだけのエージェント、売上や在庫を集計するエージェント、問い合わせ対応を支援するエージェント、外部SaaSへチケットを作成するエージェントでは、必要な権限がまったく異なります。 また、組織内のエージェント、MCPサーバー、エンドポイントを管理するための中央システムとしてAgent Registryが紹介されていました。エージェントが部署やチームごとに増えていくと、似たようなエージェントが乱立したり、古いバージョンが使われ続けたり、オーナーがわからなくなったりする可能性があります。AIソリューション開発ブロックとしても、各業務領域の知識を持つチームと一緒にエージェントを育てるためには、どこに何があり、誰が管理し、どのデータやツールにつながっているのかを可視化する仕組みが必要になると感じました。 Agent Gatewayやセキュリティのアップデートも、業務利用にあたって重要なポイントです。Agent Gatewayは、エージェントの通信やツールアクセスに対して、中央でガバナンスとセキュリティポリシーを適用するための仕組みとして紹介されていました。IAM連携、プロトコル解析、ログ、Trace IDなどを通じて、エージェントがどの通信を行い、どの操作を実行したのかを追えるようになります。エージェントの数が増えるほど、個別実装ごとに認可やログを作り込むのではなく、共通の制御点を持つことが重要になると感じました。 運用面では、Agent ObservabilityとEvaluationのライフサイクルが印象的でした。 公開資料「 What's new in Google Cloud's agent platform 」のP.19より引用 通常のWebアプリケーションであれば、HTTPステータスやエラー率、レイテンシを見ることで、ある程度の健全性を把握できます。しかしエージェントの場合、レスポンスが返っていても、根拠が不十分だったり、不適切な判断をしていたりする可能性があります。そのため、トレースやダッシュボード、Multi-Agent topology graph、オンライン・オフライン評価、シミュレーション、継続的な改善までを一連のライフサイクルとして見る必要があります。 このセッションを通じて、AIエージェントを業務で活用するうえで必要なインフラが、Agentに最適化された形で整備されつつあることを強く感じました。これまでも、実務でAIを活用する際はプロンプトだけで完結するわけではなく、実行環境、権限管理、ログ、評価、監査などをどう組み合わせるかを試行錯誤する必要がありました。だからこそ、Runtime、Identity、Gateway、Registry、Observabilityのような機能がプラットフォームとして提供されるのは非常にありがたい流れだと感じます。ZOZOでも業務・事業におけるエージェント活用において、権限とログを整えながら、Background Processing Agentsのように、ユーザーが意識しなくても裏側で業務を支える形での活用も推進していきたいと思います。 Gemini Enterprise appとGoogle Workspaceのアップデート こんにちは、AI・アナリティクス本部 AI事業戦略部 生成AI推進ブロックの川田です。ZOZOでは生成AI活用を推進するチームのマネージャーとして、業務活用とプロダクト活用の両面で企画・推進を担当しています。 今回、Google Cloud Next '26に参加して、生成AIが「質問に答えるもの」から「業務を理解し、タスクを実行するもの」へ進化していることを強く感じました。特に、ビジネス部門の業務効率化に直結しそうなGemini Enterprise appとGoogle Workspaceのアップデートを中心に紹介します。 Google Workspace Blog「 10 more announcements from Google Workspace at Cloud Next ‘26 」のカバー画像より引用 Knowledge Catalog まず印象的だったのが、Gemini Enterprise appとも関係の深いKnowledge Catalogです。Knowledge Catalogは、一言でいうと仕事に関わる情報の集約場所です。 AIエージェントが自律的に動くためには、仕事のこと、会社のこと、プロダクトのことなど、業務に必要な文脈を理解している必要があります。しかし実際の業務情報は、メール、Slack、Googleドライブ、Box、Salesforce、BigQueryなど、さまざまな場所に分散しています。これまでは人間がそれらのツールを行き来しながら、必要な情報を探し、つなぎ合わせていました。 Knowledge Catalogは、外部ソースも含めて100以上のコネクタで情報をつなぎ、ユニバーサルなコンテキストエンジンとして機能します。例えば、エージェントがBigQueryから過去のキャンペーン結果を取得し、スプレッドシートから現在の在庫状況を確認します。そして、Boxにあるデザインガイドラインも参照したうえで、新しい施策案を作るといった使い方が考えられます。 これまでも、AIに社内情報を参照させるためにベクトルデータベースを構築したり、RAGの精度向上に試行錯誤したりする必要がありました。Knowledge Catalogによって、普段使っている業務ツールをコネクタでつなぐだけでセマンティック検索の基盤を活用できるようになると、AIのための準備に使っていた時間を、本来考えるべき業務設計に向けやすくなると感じました。 また、Gemini Enterprise appのDeep Research機能においても、Knowledge Catalogは重要な役割を持ちます。プロンプトだけでは伝えきれない社内の前提や文脈を補完できるため、調査結果の質を高められる可能性があります。 Agent Designer v3 次に、Gemini Enterprise appのアップデートとして、ノーコードでエージェントを作成できるAgent Designer v3が紹介されました。 Agent Designer v3の特徴は、大きく3つあります。1つ目は、自然言語でエージェントやワークフローを作成できることです。2つ目は、実行順序や条件分岐を設定し、柔軟にタスクを実行できることです。3つ目は、MCPサーバーをコネクタとして利用し、企業データを扱えることです。 つまり、企業データを理解したエージェントを、開発者だけでなくビジネス部門のメンバーも視覚的に設計できるようになります。日々の定型業務や複数アプリをまたぐ作業を自動化したい場合や、現場のニーズに合ったAIツールを各部門で作って活用したい場合に、大きな効果が期待できます。 ZOZOでの活用例としては、「商品レビューの自動分析・構造化」ワークフローが考えられます。 1. MCPサーバー経由で、BigQueryに蓄積された新着の商品レビューデータを取得する 2. AIがレビュー内容から「フィット感」「サイズ感」「使用感」などの特徴量を抽出し、ポジティブ・ネガティブの感情を判定してJSON形式で出力する 3-1. ネガティブな感情が強い場合や不良品に関する言及があった場合は、カスタマーサポート部門へGmailやチャットで通知する 3-2. 通常のレビューであれば、構造化したデータをAlloyDBやBigQueryに書き込み、レコメンドやパーソナライズ配信のデータとして蓄積する このように、「自社データの取得」「AIによる分析・構造化」「条件に応じた通知やシステム操作」までを一連の流れとして構築できる点が、Agent Designer v3の大きな魅力だと感じました。 Workspace Intelligence Google Workspace Blog「 Workspace Intelligence の発表 」の本文中で使用されている画像より引用 Google Workspaceのアップデートとしては、Workspace Intelligenceも印象に残りました。Workspace Intelligenceは、Google Workspaceの各アプリとGeminiを連携させ、ユーザーの業務背景や文脈をAIに理解させるための統合的な仕組みです。 イメージとしては、Knowledge CatalogのGoogle Workspace版に近いと感じました。Gmail、Googleドライブ、Google Chatなどに分散している情報を横断的に理解し、ユーザーが今必要としている情報やアクションを提示してくれます。 例えば、Ask Gemini in Chatでは優先タスクのリストアップやファイル検索を支援できます。また、GmailではAI InboxやAI Overviewといった機能が紹介されていました。AI Inboxは、受信トレイの中から今日中に返信すべき承認依頼や、プロジェクトの遅延リスクにつながるメールを判断し、ToDoとして提示してくれます。AI Overviewを使えば、メール、ドキュメント、スライドを横断して「あの件の最新ステータスはどうなっているか」「あの仕様は最終的にどのような落とし所になったか」といった質問にも答えられるようになります。 数日間の出張や休暇から戻ったときに、メールやチャットを何百件も遡って状況を把握するのは、多くの人が経験している負荷だと思います。Workspace Intelligenceによって、その不在期間の文脈を要約できれば、人間はキャッチアップ作業に時間を使うのではなく、最初から判断や意思決定できるようになります。 Sheets Canvas 最後に、Sheets Canvasについても紹介します。これはエージェント的な機能というより、データの理解や業務の進め方を大きく変えそうなアップデートです。 Sheets Canvasは、スプレッドシート上のデータをもとに、ノーコードでミニアプリを構築できる機能です。例えば、KPIダッシュボードやプロジェクト進捗を管理するカンバンボードのようなものを、数クリックで作成できます。作成したCanvasはシートのデータとリアルタイムに同期されるため、シートを更新するとアプリ側も最新の状態になります。また、通常のスプレッドシートと同じように他のユーザーへ共有できます。 スプレッドシートは柔軟で便利な一方、データ量が増えると全体像をつかむのに時間がかかることもあります。Sheets Canvasによって、データを入力・管理する場所と、それを理解・活用するための画面が近づくことで、情報を把握するスピードや意思決定の質を高められると感じました。 まとめ 今回紹介したKnowledge Catalog、Agent Designer v3、Workspace Intelligence、Sheets Canvasに共通しているのは、AIが業務の文脈を理解し、必要な情報を探し、タスクの実行まで支援する方向に進んでいる点です。 AIに参照させたいコンテキストを集約し、そのデータを活用するエージェントを作成できるようになることで、これまで人が担っていた情報探索や整理、定型的な判断の一部を任せやすくなります。また、普段利用しているGoogle Workspaceの各アプリにもAI機能が組み込まれることで、日常業務の中で自然にAIを活用できる場面が増えていくと感じました。 一方で、これらの機能は導入するだけで価値が出るものではなく、どの業務に適用し、どのように運用へ組み込むかが重要です。ZOZOでも、業務活用とプロダクト活用の両面でユースケースを見極めながら、研修や検証を通じて社内での生成AI活用を推進していきたいと思います。 おわりに 今回のGoogle Cloud Next '26では、各サービスのアップデートを個別に知るだけでなく、それらが実際の開発・運用体験をどのように変えていくのかを考える機会になりました。Cloud Run、AlloyDB、Generative UI、Agent Platform、Gemini Enterprise app、Google Workspaceといったテーマはそれぞれ異なりますが、どのセッションも、私たちが日々向き合っているシステム設計、データ活用、業務改善、開発体験に直接つながる内容でした。 また、現地ではセッションに加えて、企業ブースやデモ展示を通じて、発表された技術がどのようなユーザー体験として提供されるのかを具体的に知ることができました。資料や動画だけでは分かりにくい細かな操作感や、参加者の反応、会場全体の熱量を肌で感じられたことも、現地参加ならではの大きな収穫でした。 今回得た知見を、ZOZOのプロダクト開発や社内でのAI活用にも活かしていきたいと思います。Google Cloud Next '26では数多くのセッションが公開されていますので、気になる方はぜひ 公式サイトのSession and Activity library もご覧ください。 最後に、弊社ではカンファレンス参加に伴う渡航費や宿泊費は福利厚生のひとつであるセミナー・カンファレンス参加支援制度によって、カンファレンス参加にかかる費用は全て会社負担です。 ZOZOでは一緒にプロダクトを開発してくれるエンジニアを募集しています。ご興味のある方は下記リンクからぜひご応募ください！ corp.zozo.com

こんにちは！「 SHIFTグループ技術ブログ 」編集部です。 お役立ち記事を発信していますので、ぜひご注目ください！！ 本ブログは、IT技術だけでなくSHIFTグループのあらゆる知見やノウハウを広義の“技術”とし、入社歴や部署の垣根を超えて従業員が公式ブロガーとして記事を執筆しています。

自社のサービス利用率向上やリピート率改善を目指し、新規にアプリ開発を検討する企業が増えています。 しかし、社内にアプリ開発の専門人材がいない場合、プロジェクトを成功させるには外部の専門会社へ外注することが前提となります。 いざ検索してみると、アプリ開発の費用は数十万円から1,000万円規模まで幅広く、相場感がつかみにくかったり、「外注先選定に失敗した」というリスクを恐れて慎重になったりする担当者の方も少なくありません。 単に費用の安さだけで会社を選んでしまうと、要件の認識違いによる手戻り、追加費用の発生、納期遅延、あるいはリリース後の不具合といったトラブルを招く危険があります。 そこで今回はアプリ開発を外注するメリット・デメリットをはじめ、依頼前に自社で決めておくべき準備、失敗しない外注先の比較ポイント、契約時の注意点までを詳しく解説します。 発注側として最低限押さえるべき知識を身につけ、安心してプロジェクトを進められる土台を整えましょう。 import haihaiInquiryFormClient from "https://form-gw.hm-f.jp/js/haihai.inquiry_form.client.js";haihaiInquiryFormClient.create({baseURL: "https://form-gw.hm-f.jp",formUUID: "927d2c4e-f06c-45b1-bd36-0240e55ccf72",}) ▼アプリ開発の基本について知りたい方はこちら▼ アプリ開発とは？種類・流れ・必要スキル・費用感まで初心者向けにわかりやすく解説 アプリ開発は外注すべき？自社開発との違いを理解する アプリ開発の外注とは アプリ開発の外注とは、自社以外の専門会社や開発ベンダー、あるいはフリーランスのエンジニアといった外部のプロフェッショナルに対して、アプリの企画から設計、プログラミング、テスト、ストアへのリリース申請、さらにはリリース後の保守・運用にいたるプロセスの全部、または一部を委託することを指します。 自社の組織内にシステムエンジニアやデザイナー、プロジェクトマネージャーなどの専門人材が一人もいない状態であっても、外部が持つ高度なIT知識やノウハウをそのまま活用してプロジェクトを前進させられる点が大きな特徴です。 発注側のリソース状況や目的に応じて、デザインだけを外注するケースや、要件定義以降の開発工程をすべて一任するケースなど、柔軟な関わり方を選択できます。 外注の主なメリット 外部の専門会社へ開発を委託する最大のメリットは、これまでに膨大なシステムを構築してきた実績や知見をそのまま自社のプロジェクトに還元できる点にあります。 自社で一からエンジニアを採用し、教育し、開発環境を整えるとなれば膨大なコストと時間がかかりますが、外注であればその負担を大幅に抑えながら、開発期間自体を短縮することが可能です。 また外注によって技術的な実務を切り離すことで、社内のコアメンバーはマーケティング施策の立案や資金調達、リリース後の運用設計といった、事業の成果に直結する重要な業務に集中できるようになります。 複数のプラットフォームに対応したアプリや、セキュリティ対策が求められる大規模なアプリなど、自社単独では対応が難しい高度なシステム構築でも、専門知識を駆使して最適かつ高品質な開発を実現し、社内リソースを柔軟に調整しながら進められる点が強みです。 外注のデメリット・注意点 非常に多くのメリットがある一方で、アプリ開発の外注にはいくつかの注意すべきデメリットも存在します。 まず開発の実務をすべて外部の企業に任せることになるため、自社の組織内にアプリ開発に関する具体的な技術やノウハウが蓄積されにくいという点が挙げられます。 また、自社の意図やビジネスの目的を開発側に正確に伝えるためのコミュニケーションコストが想像以上に発生し、意思疎通が不十分だと成果物にズレが生じるリスクもあります。 さらに、初期の開発費用だけでなく、リリース後の機能改修や不具合対応などで長期的に見た場合のコスト負担が膨らんでしまうケースも少なくありません。 特に発注側で要件が曖昧な状態のまま見切り発車で依頼してしまうと、仕様変更による追加費用の発生や、スケジュールの見直しによる納期遅延につながりやすいため注意が必要です。 外注が向いているケース これまでの特徴を踏まえると、自社で初めてアプリ開発のプロジェクトに取り組む場合や、社内にITの専門人材が不足している企業にとっては、外注を選択するのが最も現実的で確実な手段と言えます。 特に、新サービスの開始時期やイベントに合わせてリリース時期が厳密に決まっているプロジェクトでは、開発ラインを迅速に確保できる外注の強みが活きます。 また、ユーザーにとって使いやすいUIやUXのデザイン、強固なセキュリティ、バグのない高い品質を担保したい場合も、一から自社で試行錯誤するより専門家に一任するほうが賢明です。 技術的なシステム構築はプロのベンダーに委ね、事業部門は企画のブラッシュアップや集客、顧客対応の体制構築といった、本来注力すべき運用の内製化にリソースを集中させたいケースにおいて、外注は非常に有効な選択肢となります。 アプリ開発を外注する前に自社で決めておくべきこと アプリ開発の目的を明確にする アプリ開発のプロジェクトを立ち上げる際、まず何のためにアプリを作るのかという根本的な導入目的を定義することが極めて重要です。 新規顧客の獲得、既存顧客のリピート促進、業務効率化、あるいは会員接点の強化など、自社が抱える課題に対してアプリがどのような役割を果たすべきかを具体化する必要があります。 この目的が曖昧な状態のまま開発会社に相談してしまうと、どのような機能やデザインを優先すべきか、予算をどこに集中させるべきかの判断基準が定まりません。 その結果、開発が始まってから迷いが生じて仕様変更や作業の追加が重なり、スケジュールの大幅な遅れや予想外の追加費用が発生して社内への説明責任を果たせなくなるリスクが高まります。 ターゲットユーザーと利用シーンを決める アプリを実際に利用するユーザー像と、それがどのような場面で使われるのかという利用シーンを事前に整理しておくことも欠かせません。 ターゲットが既存のロイヤルカスタマーなのか、これから獲得したい新規顧客なのか、あるいは自社の従業員による社内業務向けなのかによって、アプリに求めるべき方向性は180度変わります。 年齢層やスマートフォンの操作習熟度、利用する時間帯や場所といった具体的なシチュエーションを明確にすることで、必要となる機能の選定はもちろん、直感的に操作できるUIやUXの設計、最適な通知のタイミング、対応すべき端末のスペックなどが自然と導き出されるようになります。 必要な機能を優先順位づけする アプリに搭載したい機能を網羅的に洗い出し、それぞれの重要度に応じて優先順位をつける作業が必要です。 会員登録やログイン、決済、予約、クーポン配信、プッシュ通知、チャット、データ管理画面、外部システム連携など、想定される機能をすべてリストアップします。 その上で、目的達成に絶対欠かせない必須機能、予算に余裕があれば導入したい機能、リリース後のアップデートで対応すべき将来的な機能の3段階に分類します。 初期開発の段階からすべての機能を詰め込もうとすると見積もり金額が高騰し、納期も長期化するため、まずは最小限の機能に絞ってスピーディーに形にすることが成功の鍵となります。 アプリの種類・対応範囲を決める ターゲットユーザーの利用環境に合わせて、どのような技術形態でアプリを構築するかを検討します。 iOSアプリ、Androidアプリ、Webブラウザ上で動くアプリ、両方のOSに対応できるハイブリッドアプリ、あるいはLINEミニアプリといった選択肢の中から、自社の戦略に最適なものを比較して選びます。 また、すでに自社で運用しているWebサービスやECサイト、店舗のPOSシステム、顧客管理システム、既存の会員データベースなど、外部のシステムとデータを連携させる必要があるかどうかもこの段階で確認が必要です。 データの連携範囲やカスタマイズの自由度、リリース後の分析機能の有無は、外注先の選定や費用の見積もりに直結する重要な要素となります。 予算とスケジュールを決める アプリ開発には初期の構築費用だけでなく、月々のサーバー維持費や不具合に対応する保守運用費、OSのアップデートに伴う改修費、各種ストアの維持費など、リリース後にかかるランニングコストも発生するため、これらを見込んだ予算計画を立てておく必要があります。 スケジュールに関しては、目標とするリリース希望日から逆算し、企画、要件定義、設計、開発、テスト、アプリストアの審査といった各工程に必要な期間を現実的な目線で確保することが大切です。 また、アプリ内に掲載するテキストや画像の素材提供、社内の法務確認、稟議承認といった自社側のタスクにかかる日数も事前にスケジュールへ組み込んでおくことで、無駄なやり取りや進行の遅れを防ぐことができます。 アプリ開発の外注先を選ぶ際の比較ポイント 開発実績・専門性があるか 外注先を選ぶ上で、自社が想定している業界やサービス規模、必要とされる機能と類似した開発実績が過去にあるかを必ず確認します。 アプリ開発には、端末の性能を引き出すネイティブアプリ開発のほか、FlutterやReact Nativeといったクロスプラットフォーム開発、あるいはWebアプリなど多様な選択肢があり、自社に必要な技術に対応できる会社かを見極める必要があります。 また、幅広い基幹システム開発の一部としてアプリも扱っている会社と、アプリ開発自体に特化している会社では、ノウハウの深さが異なります。 技術力や専門性の高さはもちろん、アプリ特有のApp StoreやGoogle Playの審査対応、複雑な下請け構造によるトラブル回避、品質管理への取り組みまで含めて総合的に対応できる会社であるかが重要な基準です。 提案力があるか 指示された仕様通りにただプログラムを組むだけでなく、自社の目的を達成するためにプロの視点から積極的な改善提案をしてくれる会社かどうかも比較のポイントです。 機能に過不足はないか、ユーザーにとって不便な点はないかなど、システム構成やUI、UXの観点はもちろん、リリース後の実際の運用やマーケティングにまで踏み込んだ提案をしてくれるベンダーは信頼がおけます。 初回相談や見積もりを依頼した時点で、自社が気付いていない課題を先回りして質問してくれるか、課題整理のサポートに長けているかといった対応姿勢を見ることで、開発パートナーとしての資質を測ることができます。 UI/UX・デザイン力があるか アプリは見た目が綺麗なだけではなく、ユーザーが迷わずに操作できる使いやすさや、目的を達成するためのスムーズな導線設計が施されているかが成果を大きく左右します。 開発力に定評があっても、デザイン力や最新のUIおよびUXトレンドへの理解が不足していれば、ユーザーに継続利用されるアプリには育ちません。 過去のポートフォリオや実績をチェックし、ターゲットとなるユーザー層の心理や行動パターンに配慮したデザイン実績が豊富かを確認します。 自社のブランドイメージを向上させ、ユーザー体験を高めるための論理的なデザイン設計ができる会社かどうかが選定の鍵となります。 コミュニケーション体制が整っているか プロジェクトを円滑に進めるためには、発注側と開発側の認識のズレを防ぐためのコミュニケーション体制が欠かせません。 問い合わせに対する担当者のレスポンススピードや、こちらの要望や背景にある意図を正確に理解してくれる傾聴力があるかを見極めます。 さらに、開発進行中の要望変更や予期せぬ課題に対して柔軟に対応できるよう、定期的なミーティングや進捗報告の仕組み、議事録の共有、課題管理ツールの導入などが徹底されているかも重要です。 仕様書や画面設計書などの資料を介して、常に双方が同じ完成イメージを持って進められる環境が用意されているかを確認します。 セキュリティ・品質管理体制があるか 会員の個人情報や決済情報を取り扱うアプリを開発する場合、データの暗号化や不正アクセスの防止、システムの脆弱性診断といったセキュリティ対策が万全であるかは企業としての死活問題です。 これらに加えて、納品されるアプリの品質を担保するためのテスト体制やレビュー体制が十分に整っているかを質問する必要があります。 開発メンバー以外の客観的な視点で不具合や使いにくさを洗い出す第三者検証を取り入れているか、週次でのリスク管理などトラブルを未然に防ぐ具体的な取り組みが実施されているかなど、品質管理への具体的な施策や体制の有無を確認することが安心な発注に繋がります。 リリース後の保守・運用まで対応できるか アプリは完成して終わりではなく、公開後の継続的なシステム維持や改善が必要となるため、技術面、料金体系、そして運用開始後の対応までを含めて総合的にアフターケアをしてくれる会社かを確認します。 予期せぬバグの修正やスマートフォンのOSアップデートへの追従、サーバーの監視、機能追加、ストアの規約変更に伴う審査対応など、リリース後に必要な保守運用の対応範囲を明確にすることが大切です。 また、契約前にどこまでが無償対応でどこからが有償になるかの保証期間と範囲をクリアにし、長期的かつ安定的なビジネスパートナーとして伴走してくれる会社を選びます。 見積もり・契約時に確認すべきポイント 複数社から見積もりを取り比較する アプリ開発の外注先を決める際は、最初から1社だけに絞り込むのではなく、必ず複数の開発会社に相談して相見積もりを取ることが大切です。 全く同じ要件定義や前提条件を提示した上で見積もりを依頼し、提示された金額、開発の対応範囲、予定される納期、そしてリリース後のサポート範囲を横並びで比較します。 このとき、単純に総額の安さだけで判断するのではなく、提示された提案内容の具体性や、プロジェクト進行における想定リスク、その対策について丁寧に説明してくれているかといった誠実さも見極める重要な基準となります。 見積もりの内訳を確認する 提示された見積もりについては、総額だけでなく詳細な内訳までしっかりと目を通す必要があります。 要件定義、UIやUXの設計、デザイン制作、画面側のフロントエンド開発、サーバー側のバックエンド開発、管理画面の構築、各種テスト、リリース作業、さらには保守運用費など、どの工程にどれだけの費用が割り当てられているかを確認します。 特に、どこまでが初期費用に含まれており、どこからが追加費用になるのかの境界線をクリアにしておくことが欠かせません。 開発の途中で仕様変更や機能の追加が必要になるケースは非常に多いため、どのような条件下で追加費用が発生するのか、その際の費用算出ルールを事前に明確にしておくことで、後々の金銭トラブルを防ぐことができます。 開発手法を確認する プロジェクトがどのような開発手法で進められるのかを把握しておくことも、進行管理上の重要なポイントです。 最初にあらかじめすべての要件と仕様を厳密に固めてから工程通りに作り込むウォーターフォール開発か、あるいは大枠の機能からスタートして段階的にテストと改善を繰り返しながら柔軟に進めるアジャイル開発かによって、開発の進め方は大きく異なります。 初めて外注を経験する場合は、日々の進行方法や、途中で仕様を変更したくなった場合の扱い、誰がどの段階で承認を出すべきかという承認フローについて、開発会社と事前にすり合わせておく必要があります。 契約形態を確認する 外注時の契約形態には、主に請負契約と準委任契約の2種類があり、それぞれの特徴とリスクを理解しておくことが不可欠です。 請負契約は、約束された成果物の完成と納品を前提として対価を支払う形態であり、開発会社側が完成の責任を負います。 一方で準委任契約は、一定の技術や裁量を持って日々の業務を行うこと自体に委託費用を支払う形態であり、必ずしも完成を保証するものではありません。 プロジェクトの性質や要件の決まり具合に応じて適した形態を選ぶ必要があるため、最終的な成果物の定義、お互いの責任範囲、検収の合格条件、支払い条件、そして仕様変更が発生した際の対応方法を契約書に明記しておくことが、社内への説明責任を果たす上でも極めて重要です。 保証期間・アフターサポートを確認する アプリを無事にリリースできたとしても、その後に予期せぬ不具合が発覚することがあります。 そのため、リリース後のバグ修正が一定期間無償で受けられるのか、それとも最初から有償対応になるのかを契約前に突き詰めておく必要があります。 無償の保証期間が何ヶ月間設けられているのか、またスマートフォンのOSアップデートやアプリストアの仕様変更に伴う急な改修への対応が含まれているかどうかも確認が必須です。 リリース後に別途、保守契約を結ぶ場合には、月額の費用に対して具体的にどのようなトラブルまで対応してもらえるのかという対応範囲と、別途修正費用が発生する条件を事前に書面でクリアにしておきます。 機密情報・権利関係を確認する アプリ開発では、自社のビジネスモデルや顧客データに関わる重要な情報を扱うため、契約の初期段階で秘密保持契約（NDA）を確実に締結します。 あわせて、開発されたソースコードやデザインデータ、アプリストアの登録アカウント、ドメイン、サーバー、管理画面の所有権や著作権が最終的に自社に帰属するのかどうかを必ず確認してください。 また、開発会社がシステムの一部に外部の有償サービスやオープンソースのライブラリを利用する場合の利用条件や、開発会社が自社だけで対応せずに外部のパートナー企業へ実務を再委託する可能性があるか、その場合の再委託先の管理体制がどうなっているかまで確認しておくことで、将来的な権利トラブルや情報漏洩のリスクを未然に排除できます。 アプリ開発の外注でよくある失敗と成功させるコツ 失敗例1：要件が曖昧なまま依頼する 「このような雰囲気のアプリを作りたい」という大まかなイメージや思いつきだけで開発会社に依頼してしまうケースです。 発注側の要件が曖昧な状態でプロジェクトがスタートすると、開発の工程が進むにつれて認識のズレが表面化し、仕様の変更や機能の追加が度重なるようになります。 結果として、初期の見積もりから大幅に費用が膨らみ、当初予定していた納期にも間に合わなくなるという事態に陥りかねません。 これを防ぐためには、アプリを開発する目的、想定するターゲット層、絶対に外せない必須機能とその優先順位、そして許容できる予算の上限を事前に自社内で整理して提示することが不可欠です。 失敗例2：費用の安さだけで外注先を決める 提示された見積もり金額の安さだけに惹かれ、コスト最優先で外注先を決定してしまうことも代表的な失敗パターンの一つです。 相場よりも極端に安い見積もりを提示する会社は、必要な開発工程を削っていたり、リリース後の運用・保守体制が不足していたり、品質管理が不十分であったりするリスクを孕んでいます。 最悪の場合、納期遅延やアプリの品質低下につながる恐れがあり、結局は不具合の修正や機能の補填のために追加費用が重なって結果的に高くついてしまいます。 価格の低さだけで安易に判断せず、過去の実績、提案力、品質管理体制、そして長期的な保守体制までを総合的に比較して選定する必要があります。 失敗例3：外注先に丸投げする 技術的な知識がないからといって、発注側が重要な判断を下さず、すべての工程を開発会社任せに丸投げしてしまうケースです。 どれだけ技術力のある開発会社であっても、発注側企業のビジネスモデルや顧客の特性を深く理解しているわけではありません。 コミュニケーションを怠り丸投げを続けていると、自社の事業目的やユーザーの真のニーズが全く反映されていない、形ばかりで誰にも使われないアプリが完成してしまいます。 対策として、発注側でも必ずプロジェクトの責任者を立て、定期的な定例会の実施やマイルストーンごとの確認フローを設け、当事者意識を持って並走することが求められます。 失敗例4：機能を詰め込みすぎる 初期リリースの段階からあれもこれもと多くの機能を詰め込みすぎてしまうのも、プロジェクトを停滞させる要因になります。 最初から多機能なアプリを目指すと、それだけ開発費用が高騰し、リリースまでの期間も長期化する上、システムが複雑化して不具合が発生するリスクも跳ね上がります。 また、選択肢が多すぎるアプリはユーザーにとっても操作が分かりにくく、定着を妨げる原因になりかねません。 まずは、ビジネスの目的を達成するために最も重要な最小限の機能だけでリリースし、ユーザーの反応を見ながら段階的に改善していくプロダクト開発の考え方を取り入れることが成功への近道です。 失敗例5：リリース後の運用を考えていない アプリが無事にストアに公開された後の、具体的な運用イメージを想定していないケースも多く見られます。 リリース後に発生する予期せぬバグへの迅速な対応や、ユーザーからの問い合わせ窓口、利用状況に応じた機能改善、そして認知度を高めるための集客・マーケティング施策が決まっていないと、アプリを作っただけで誰も利用者が増えないという結果に終わってしまいます。 アプリはリリースしてからが本当のスタートであるため、開発に着手する前の企画段階から、保守運用、効果測定、改善サイクル、プロモーションの体制をあらかじめ見込んでおくことが重要です。 成功させるための実践ポイント アプリ開発の外注プロジェクトを成功へ導くためには、自社が何のためにアプリを作り、どの数値を指標（KPI）として追うのか、ターゲットは誰なのかを明確に定義することが大前提となります。 その上で、開発会社との間に定期的なコミュニケーションの場を設け、進捗状況や認識のすり合わせを怠らないようにします。 見積もりの内訳や契約書で定義されている対応範囲を細部まで精査し、万が一の追加費用や仕様変更、納期変更が発生した場合のルールをあらかじめ取り決めておくことも安定した運用の鍵です。 さらに、納品物の品質管理やテストの体制が信頼できるかを確認し、リリース後の保守から改善までを長期的に見据えることが大切です。 開発会社を単なる作業の「発注先」としてではなく、自社の事業を一緒に育てていくための「ビジネスパートナー」として信頼関係を築ける企業を選ぶことが、何よりも強力な成功のポイントとなります。 まとめ アプリ開発の外注を成功させるためには、単に技術力のある開発会社を価格だけで選ぶのではなく、自社の事業目的を深く理解し、リリース後の運用まで見据えて伴走してくれるパートナーを見極めることが重要です。 事前の準備としてアプリの目的やターゲット、必須機能を明確にし、複数社からの見積もり内訳や契約形態（請負・準委任）を細かく確認しておくことで、認識のズレによる追加費用や納期遅延のリスクは最小限に抑えられます。 仕様変更時のルールや、リリース後の保守・運用の対応範囲まで契約前にしっかりとクリアにしておけば、社内稟議でも納得感のある説明が可能になり、プロジェクト責任者としての信頼にもつながるはずです。 アプリはリリースして終わりではなく、そこからユーザーの声を反映して改善を続けることで初めて事業成果が生まれます。 自社に最適な開発会社を慎重に比較検討し、二人三脚で事業を成長させていける理想的なビジネスパートナーを見つけ出してください。 QA業務効率化ならPractiTest テスト管理の効率化 についてお悩みではありませんか？そんなときはテスト資産の一元管理をすることで 工数を20%削減できる 総合テスト管理ツール「 PractiTest 」がおすすめです！ PractiTest (プラクティテスト) に関する お問い合わせ トライアルアカウントお申し込みや、製品デモの依頼、 機能についての問い合わせなどお気軽にお問い合わせください。 お問い合わせ この記事の監修 Dr.T。テストエンジニア。 PractiTestエバンジェリスト。 大学卒業後、外車純正Navi開発のテストエンジニアとしてキャリアをスタート。DTVチューナ開発会社、第三者検証会社等、数々のプロダクトの検証業務に従事。 2017年株式会社モンテカンポへ入社し、マネージメント業務の傍ら、自らもテストエンジニアとしテストコンサルやPractiTestの導入サポートなどを担当している。 記事制作： 川上サトシ （マーケター、合同会社ぎあはーと代表）