サプライチェーンとロジスティクス

Waze、Memorystore で 1 秒あたり 100 万件以上のリアルタイム読み取りでトラフィックの流れを維持

Fri, 21 Nov 2025 03:00:00 +0000

※この投稿は米国時間 2025 年 11 月 15 日に、Google Cloud blog に投稿されたものの抄訳です。

編集者注: Google の親会社である Alphabet の一部門である Waze は、コアとなるナビゲーション機能を強化するために、膨大な量の動的なリアルタイムのユーザーセッションデータを活用しています。しかし、世界中の同時ユーザーをサポートするためにデータをスケーリングするには、新しいアプローチが必要でした。同社のチームは、次によって裏打ちされたセッションサーバーを構築しました：Memorystore for Redis Cluster は、99.99% の可用性を備えたフルマネージドサービスで、部分的な更新をサポートし、1 秒あたり 100 万件を超える MGET コマンドを約 1 ミリ秒のレイテンシで処理するという Waze のユースケースに合わせて簡単にスケーリングできます。このアーキテクチャは、Waze のバックエンドの継続的なモダナイゼーションの基盤となります。

リアルタイムデータが Waze アプリのエクスペリエンスを支えています。Google のターンバイターン方式のナビゲーション、事故によるルート変更、ドライバーへのアラートは、ミリ秒単位の精度に依存しています。しかし、数百万の同時セッションでシームレスなエクスペリエンスを維持するには、ユーザーセッションデータの膨大なストリームを管理するように構築された、堅牢で実戦に耐えるインフラストラクチャが必要です。これには、アクティブなナビゲーションルート、ユーザーの位置情報、ドライバーのレポートなどが含まれ、これらは数秒で表示され、変化する可能性があります。

一方舞台裏では、ユーザーセッションという頻繁に更新される大規模で複雑なオブジェクトがあり、非常に大量の読み取り / 書き込みオペレーションに寄与しています。セッションデータはかつて、モノリシックサービスにロックされ、単一のバックエンドインスタンスに緊密に結合されていました。そのため、スケーリングが難しく、他のマイクロサービスがリアルタイムのセッション状態にアクセスできませんでした。これをモダナイズするには、これらのセッションをリアルタイムで、またグローバル規模で処理できる、低レイテンシの共有ソリューションが必要でした。Memorystore for Redis Cluster でそれが可能になりました。

aside_block: <ListValue: [StructValue([('title', 'Google Cloud データベースでよりスマートに構築'), ('body', <wagtail.rich_text.RichText object at 0x7fd142882c40>), ('btn_text', ''), ('href', ''), ('image', None)])]>

適切なルートの選択

Google では、マイクロサービスベースのバックエンドへの移行を計画するにあたり、Redis Enterprise Cloud、セルフマネージドの Redis クラスタ、Memorystore デプロイによる既存の Memcached の継続使用など、さまざまな選択肢を評価しました。従来のセットアップでは、Memcached はモノリシックなリアルタイム（RT）サーバーの背後にセッションデータを保存していましたが、求めていたレプリケーション、高度なデータ型、部分更新機能がありませんでした。Redis には必要な機能が備わっていることはわかっていましたが、自社で管理したり、サードパーティプロバイダを通じて管理したりすると、運用上のオーバーヘッドが増加します。

Memorystore for Redis Cluster は、両方の利点を兼ね備えています。Google Cloud のフルマネージドサービスである Cloud Spanner は、Waze のリアルタイムの需要を満たすパフォーマンス、スケーラビリティ、レジリエンスを備えています。これで 99.99% の SLA と、水平スケーリングのためのクラスタ化されたアーキテクチャが得られます。データベースの決定後、二重書き込みアプローチを使用して、Memcached から Memorystore for Redis への慎重な移行を計画しました。データパリティが確認されるまで、両方のシステムが並行して更新されました。その後、ダウンタイムなしで Redis に切り替えました。

Waze の新しいデータエンジン

そこから、Memorystore for Redis Cluster のラッパーとして、アクティブなユーザーセッションの新しいコマンドセンターである集中型セッションサーバーを構築しました。このサービスは、すべてのアクティブなユーザーセッションの信頼できる唯一の情報源となり、セッションデータとモノリシックな RT サーバー間の緊密な結合に代わるものとなりました。セッションサーバーはシンプルな gRPC API を公開するため、移行中の RT を含め、任意のバックエンドマイクロサービスがセッション状態を直接読み書きできます。これにより、クライアントアフィニティが不要になり、すべてのセッショントラフィックを単一のサービス経由でルーティングする必要がなくなり、プラットフォーム全体でセッションデータにアクセスできるようになりました。

Google は、レジリエンスとスケーラビリティを考慮してシステムをゼロから設計しました。Redis のクラスタリングとシャーディングにより、単一の競合ポイントが排除され、需要の増加に応じて水平方向にスケーリングできます。組み込みのレプリケーションと自動フェイルオーバーにより、セッションをオンラインに保つように設計されています。ノードの交換により、短期間だけ障害発生率とレイテンシが一時的に増加する可能性がありますが、セッションはオンライン状態を維持するように設計されているため、ナビゲーションエクスペリエンスはすぐに安定します。また、モバイルクライアントから任意のバックエンドサービスへの直接 gRPC 呼び出しをサポートすることで、より柔軟な設計パターンを使用しながら、リアルタイムパスから貴重なミリ秒を削減できます。

少ないピットストップで高速動作

Memcached の 99.9% の SLA から Memorystore for Redis Cluster の 99.99% に移行することで、サービスの可用性と復元性が向上します。負荷テストでは、新しいアーキテクチャが本番環境のトラフィック全体を維持できることが証明されました。1 秒あたり最大 100 万件の MGET コマンドのバーストを、1 ミリ秒未満の安定したサービスレイテンシで快適に処理できます。

Memorystore for Redis は部分的な更新をサポートしているため、レコード全体を書き換えるのではなく、セッションオブジェクト内の個々のフィールドを変更できます。これにより、ネットワークトラフィックが削減され、書き込みパフォーマンスが向上し、システム全体の効率が向上します。これは、セッションのサイズが数メガバイトにまで拡大する可能性がある場合に特に重要です。こうした効率化により、エンジニアリングチームはアプリケーションレベルのパフォーマンスと新機能の開発に注力する時間を増やすことができます。

Memorystore for Redis Cluster のセッションデータは、構成の評価からドライバーへのリアルタイム更新のトリガーまで、Waze のコア機能に不可欠なものとなっています。現在の需要に対応し、将来の需要にも対応できるように構築されています。

今後の展望

Waze の最も重要なパスの一つで Memorystore for Redis Cluster を実証したことで、プラットフォーム全体で他の高スループットキャッシュシナリオでも使用できるという自信が生まれました。一元化されたセッションサーバーとクラスタ化された Redis アーキテクチャは、現在ではバックエンドの標準的な構成要素となっており、ゼロから始めることなく新しいサービスに適用できます。

最初のクリティカルパスが完了したため、次の主な焦点は、残りのすべてのレガシーセッション管理を RT サーバーから移行することです。この結果、最終的にはすべてのマイクロサービスがセッションデータを更新するために独立してアクセスできるようになります。今後については、Memorystore for Redis Cluster をスケーリングして将来のユーザー増加に対応し、費用とパフォーマンスの両面で微調整することにも注力しています。

詳細

Waze の事例は、大規模なリアルタイムワークロード向けに 99.99% の可用性を備えたフルマネージドサービスである Memorystore for Redis Cluster のパワーと柔軟性を示しています。

Memorystore の機能の詳細をご確認のうえ、ぜひ無料で利用を開始ください。
Memorystore for Redis Cluster のプロダクトドキュメントをご覧ください。

-Waze BE インフラデベロッパー、Eden Levin 氏

-Waze SRE、Yuval Kamran 氏

牛肉はどこに？サンパウロの農業供給局はその答えを Cloud SQL for SQL Server で得ることが可能に

Wed, 26 Feb 2025 01:01:00 +0000

※この投稿は米国時間 2025 年 2 月 15 日に、Google Cloud blog に投稿されたものの抄訳です。

サンパウロと聞くと、多くの人はビジネスや文化を思い浮かべるでしょう。牛肉や鶏肉を思い浮かべることはまれです。しかし、サンパウロ州は南半球最大の都市を擁するだけでなく、世界第 2 位の農産物輸出国であるブラジルにおいて食肉生産量が 2 番目に多い州でもあります。サンパウロ州農業供給局（SAA-SP）は、ブラジル経済にとってのアグリビジネスの重要性を踏まえ、同州ひいては国全体のアグリビジネスの発展に重要な役割を果たしています。

SAA-SP は、食料、繊維、バイオエネルギーのサステナブルな生産を推進するというミッションの下、複数の地域の地方生産者にサポート（技術支援、調査、農業防衛、市場への流通などのサポート）を提供しています。さらに、全住民の食料安全保障の確保、農作物の品質のモニタリング、栄養指導活動の推進も担っています。

世界の食料システムが進化し、ますます複雑になる中、組織の関心は、食料安全保障とサステナビリティに関する目標の達成を後押しするテクノロジーに向けられています。SAA-SP に関して言えば、増大する機密データを安全に管理し、重要なシステムを 24 時間 365 日利用できるようにする必要があります。こうしたシステムには、Rural Environmental Registry（あらゆる地方資産の登記が義務付けられている電子登記簿）、GEDAVE（家畜と農作物をモニタリングするための管理システム）などがあります。

システムがいかに複雑かを説明するために、例を挙げましょう。家禽生産の管理は GEDAVE でコントロールされており、ヒナは生後 24 時間以内に 1 羽ずつ新しい場所に移す必要があります。食品の安全性を確保するには、このプロセス全体を厳格に文書化しなければなりません。

老朽化した IT インフラストラクチャを刷新するだけでなく、安全で信頼できる食糧供給源を求める人々が世界中で増え続けているという問題にも目を向けるのであれば、今こそ最も重要なシステムの一部をモダナイズすべきだと SAA-SP は考えました。

aside_block: <ListValue: [StructValue([('title', 'Google Cloud データベースを試用するための 300 ドル分の無料クレジット'), ('body', <wagtail.rich_text.RichText object at 0x7fd142c159a0>), ('btn_text', '無料で構築を始める'), ('href', 'http://console.cloud.google.com/freetrial?redirectPath=/products?#databases'), ('image', None)])]>

増大する負荷:

私たちのチームは、SAA-SP の情報技術コーディネーション組織の一部であるシステム管理部門において、SAA-SP にとって非常に重要なシステムである GEDAVE の運用を担当しています。GEDAVE は、サンパウロ州全体の家畜と農作物の健康状態を管理、モニタリングする役割を担っています。

GEDAVE では、家畜の移動、農作物の生産、農薬の使用、ワクチン接種、病害虫駆除といったサンパウロの農業に関するさまざまな情報を記録、管理しています。また、農作物の取引に不可欠な動物輸送ガイド（GTA）や原産地植物検疫証明書（CFO）などの書類の発行も GEDAVE で支援しています。

GEDAVE のバックエンドは Java で開発され、SQL Server データベースに接続されています。このデータベースには、地方の生産者に関する機密情報（生産データ、管理戦略、財務情報など）が含まれています。これまでこのデータベースはオンプレミスでホストされていたため、次のような問題が立て続けに発生していました。

データベースを最新の状態に維持することが困難: オンプレミス環境でパッチとセキュリティアップデートを適用する作業には時間と計画が必要なため、一定期間システムが利用できない状態になり、SAA-SP のサービスに頼る生産者に直接的な影響を及ぼしていました。
定期的なバックアップの実行プロセスが複雑: 確実なバックアップを定期的に行ってデータセキュリティを確保することは、オンプレミス環境では複雑で手間のかかるプロセスでした。
高可用性の確保が困難: オンプレミスデータベースの高可用性を維持するには、冗長で複雑なインフラストラクチャに投資しなければならず、管理のコストと複雑さが増大していました。

さらに SAA-SP は、生産者が市場の需要に応え、輸出に向けた品質管理や内部での生産のモニタリングといった複雑な問題に対処できるように、これらのシステムを 24 時間 365 日利用できるようにする必要がありました。

データセキュリティも重要でした。なぜなら、家畜群の種類、ワクチン接種戦略、害虫駆除などの情報は機密性が高く、厳格に保護する必要があるからです。

イノベーションの種をまく:

SAA-SP はこうした課題に対処するため、データインフラストラクチャをモダナイズすることにしました。そこで選択したのが、Google Cloud です。Google Cloud Platform の優れたパフォーマンスなら、アプリケーションの可用性と効率を確保できると考えたのです。また、その管理のしやすさによってデータベース管理が簡素化され、IT チームが他の優先業務に専念できるようになることも期待しました。

このモダナイゼーションの第一歩として、SAA-SP は SQL Server データベースを Google Cloud 上の Cloud SQL for SQL Server に移行しました。Cloud SQL for SQL Server を選んだ最大の決め手は、簡単に高可用性（HA）を実現できることです。複雑な構成を行わなくても、数回クリックするだけで、データベースの自動レプリケーションと自動フェイルオーバーを構成できました。これによって障害発生時にサービスの継続性を維持し、SLA に準拠できるようになりました。Cloud SQL for SQL Server への移行に関しても、SAA-SP の業務への影響を最小限に抑えながら、迅速かつ簡単に行うことができました。

この戦略的変更は数々のメリットをもたらし、Java アプリケーションをよりスケーラブルで安全な最新のデータベース環境に接続できるようになったのです。

成功を摘み取る:

アップデートの簡素化: Cloud SQL for SQL Server では簡単にパッチとアップデートを適用できるため、ダウンタイムを最低限に留め、最新バージョンのソフトウェアでシステムを常に保護された状態に保つことができます。
自動バックアップ: このサービスには自動のマネージドバックアップ機能が備わっているため、データセキュリティを確保し、障害発生時にはデータを復旧できます。
高可用性を簡単に実現: Cloud SQL for SQL Server によって高可用性の構成が簡素化されたため、IT チームの労力を軽減し、サービスの SLA に準拠できるようになりました。
セキュリティの強化: Cloud SQL for SQL Server では保存データと転送中データが暗号化されるため、不正アクセスから SAA-SP の機密情報を保護できます。
オンデマンドのスケーラビリティ: 需要に応じて Cloud SQL for SQL Server リソースを調整できるため、ピーク時でも Java アプリケーションの最適なパフォーマンスを確保できます。
イノベーションに注力: SAA-SP の IT チームは、データインフラストラクチャの管理を気にすることなく、Java アプリケーションの新機能の開発といった戦略的プロジェクトに注力できるようになりました。
IT コストの削減: Cloud SQL for SQL Server に移行したことで、オンプレミスデータベースを維持するためのハードウェアとソフトウェアに投資する必要がなくなったため、運用コストを削減できました。

Cloud SQL for SQL Server で農業におけるイノベーションの未来を耕す:

Cloud SQL for SQL Server への移行という戦略的な決定により、SAA-SP はオンプレミスのデータマネジメントで発生していた課題を克服し、重要なシステムの可用性、セキュリティ、スケーラビリティを確保できました。このプロジェクトの成功を決定づけた要因は、高可用性を簡単に実現できたこと、そして移行が容易であったことです。

しかし、それ以上に重要なことは、Cloud SQL によって SAA-SP にイノベーションがもたらされたことです。生成 AI の統合への扉が開かれ、より積極的で効率的な分析と意思決定が可能になりました。たとえば、SAA-SP では Looker で Gemini を活用して、Cloud SQL でホストされているリアルタイムのデータ分析情報を経営幹部に提供し、データドリブンな意思決定を促進しています。

さらに SAA-SP は、Gemini を活用したデータベースを使ってお客様を支援しており、お客様が AI を活用してデータベースのパフォーマンスとメンテナンスを強化できるようにしています。

SAA-SP では、引き続きインフラストラクチャとサービスのモダナイゼーションを進めるために以下を実施する予定です。

マイクロサービスへの移行: システムの柔軟性、スケーラビリティ、容量を拡大するため、マイクロサービスをベースとした更新バージョンのアプリケーションをリリースします。
生成 AI を活用したデータ分析: 生成 AI を活用して予測分析を実行し、Cloud SQL for SQL Server データからリアルタイムの分析情報を取得できるようにして、農業セクターにおける戦略的な意思決定を支援します。
Gemini を活用したデータ マネジメント: Gemini を活用してデータの管理と分析を容易にし、関連情報を抽出して、複雑なデータを簡単に利用できるようにします。

SAA-SP は分析の進歩を取り入れながらインテリジェントな運用管理に移行したことで、農業セクターにおけるテクノロジーとイノベーションの基準としての地位を確固たるものとしました。こうして、サンパウロ全体のアグリビジネスの発展を推進し、さらに世界中のアグリビジネスの道標としての役割を果たしています。

使ってみる:

Cloud SQL for SQL Server によってどのようにアプリケーションのパフォーマンスを強化し、可用性を維持できるのかをご確認ください。
Ford や Visual Research などの他の企業が Cloud SQL for SQL Server を使ってどのようにワークロードをモダナイズし、優れたパフォーマンスとコスト削減を実現しているのかをご覧ください。
Cloud SQL を活用してみたいとお考えの方は、今すぐ無料トライアルをお試しください。

-サンパウロ州農業供給局システム管理担当ディレクター、Michel Martins da Silva 氏
-サンパウロ州農業供給局ユーザーサポートおよびサービス部門ディレクター、Roseani Moraes Pereira 氏

Prewave が Google Cloud の AI を使用して世界中の多層サプライチェーンの安全性を確保している方法

Wed, 15 May 2024 01:10:00 +0000

※この投稿は米国時間 2024 年 4 月 26 日に、Google Cloud blog に投稿されたものの抄訳です。

多くの企業は、環境や社会への影響に責任を持つことが長期的な成功の鍵であることを知っています。しかし、ほとんどの企業が直接サプライヤーしか認識していない状況で、どのようにすれば十分な情報に基づいた意思決定を行うことができるのでしょうか。Prewave は、企業によるサプライチェーン全体の復元力、透明性、サステナビリティの向上を支援するという使命を掲げています。

当社のエンドツーエンドプラットフォームはサプライチェーンの幅広いリスクのモニタリングと予測を行いますが、その成功の原動力となっているのは AI です。お客様に大規模なサポートを提供しているため、AI がなければ、膨大な量のデータを処理し、公開されている情報から有益な分析情報を抽出することはほぼ不可能です。そのため、この需要に継続的に対処するには、信頼性、安全性、スケーラビリティに優れた強固なテクノロジー基盤が必要です。2019 年の創業以来、Prewave がサプライチェーンリスクインテリジェンスプラットフォームを Google Cloud 上で構築してきたのはそのためです。

当時の Prewave は、まだ規模が小さく、ハードウェアやインフラストラクチャを保持する余裕がありませんでしたが、信頼性、可用性、セキュリティの面で傑出している Google Cloud のマネージドサービスによって、製品開発と当社の使命に集中することができました。また、サステナビリティに対する共通の懸念も、導入の決断に影響しました。当社は、これほどの低カーボンフットプリントを達成しているデータセンターと連携していることに誇りを感じています。

数千社のサプライヤーを追跡

Prewave のエンドツーエンドプラットフォームは、お客様の 2 つの重要課題を解決します。1 つ目は、説明リスクを特定し、適切な軽減策を講じることで、サプライチェーンの復元力を高めることです。2 つ目は、強制労働や環境問題などの ESG リスクを検出し、解決することで、サプライチェーンのサステナビリティを高めることです。

そのための基盤となるのが、当社のリスクモニタリング機能です。この機能では、共同創業者の Lisa が 2012 年に博士論文研究の中で開発した AI が使用されています。この機能を使用して 120 以上の言語で公開されている情報をスキャンし、お客様にとってのリスクイベントの初期兆候でありうる分析情報を検出しています。これらのリスクイベントには、労働不安、事故、火災や、サプライチェーンの混乱を招く可能性があるその他 140 種類のリスクが含まれています。ここで得られた分析情報に基づき、お客様はインシデントレビューの提出からオンサイト監査の手配まで、さまざまなリスク軽減アクションを当社のプラットフォーム上で行うことができます。

また、Prewave はこの情報を利用して、直接サプライヤーと下層サプライヤーから原材料の供給業者に至るまで、お客様のサプライチェーンをマッピングします。現在、このレベルの粒度と透明性を確保することが、欧州コーポレートサステナビリティデューデリジェンス指令（CSDDD）などの新しい規制の要件となっていますが、お客様がこの要件を支援なしで満たすことは困難な場合があります。多くのお客様が数百、数千のサプライヤーを抱えるなか、当社のプラットフォームは各サプライヤーの把握に役立つだけでなく、必要に応じて特にリスクの高いサプライヤーを注視することもできます。

Prewave のプラットフォームは、サプライヤー側の労力を可能な限り軽減します。サプライヤーは、Tier-N モニタリング機能で潜在的リスクが示された場合にのみ対処する必要があり、その場合も当社が問題の解決と業務水準の向上を支援します。また、このレベルの可視性を達成することで、サプライヤーは業務パートナーとして認定してもらうために多数の質問に手動で回答しなくて済むようになります。

これらすべてを可能にするため、当社のエンジニアリングチームは、SaaS をサポートする Google Kubernetes Engine（GKE）などのスケーラブルなテクノロジーに大きく依存しています。最近 Standard から Autopilot に切り替えたことで時間効率が大幅に向上しました。また、ノードプールが適切に配置されていることや、利用可能なすべての CPU パワーが適切に使用されていることを確認する必要がなくなったため、リソースを最大 30% 節約できるようになりました。実行したデプロイに対してのみ料金を支払えば済むため、費用も削減できました。

当社は、最高のツールを導入することが、お客様だけでなく社内チームにも最高のエクスペリエンスを提供する鍵になると信じているため、Cloud Build と Artifact Registry を使用してアーティファクトをテスト、構築、デプロイし、GKE にも使用する Docker コンテナを管理しています。一方、Cloud Armor は、サービス拒否攻撃やウェブ攻撃から当社を守るファイアウォールとして機能しています。

スケーラビリティは当社の目的達成に重要な要素であるため、アプリケーション開発チームとデータサイエンスチームは Cloud SQL をデータベースとして使用しています。これはフルマネージドサービスであり、要求に応じたサーバーの管理に気を取られることがないため、製品開発に集中できます。また、データサイエンスチームは独自モデルの開発と保守に AI を導入するために Compute Engine を使用しており、これらのシステムは Prewave の日常業務の中核を担っています。

多層サプライチェーンの改善を進めるより多くの企業を支援

2020 年に 3 社だった Prewave のお客様は現在では 170 社を超え、社員は 10 人から 160 人に増加しました。収益は 100 倍まで増加し、重要なマイルストーンを達成しました。また、プラットフォームで多くの新機能をリリースしてきたため、会社の拡大とともに製品の拡張も必要になりましたが、Google Cloud ではこれが問題になりませんでした。新たな実装で必要とされたリソースを拡張しただけで、適切なタイミングで可視性を高め、新規顧客を獲得できるようになりました。当社の基盤は安定性とスケーラビリティに優れているため、事業の拡大は円滑に進みました。

Prewave は、米国などの新しい市場に進出する前に、2023 年に始まった欧州への拡大計画を進めています。この計画は順調に進んでおり、Google Cloud との連携は、その信頼性とセキュリティを確実に信用している初期段階のお客様の信頼獲得に役立っています。当社は、世界中のより多くの企業が多層サプライチェーン全体で透明性、復元力、サステナビリティ、法令遵守を達成できるよう支援するなかで、Google Cloud との連携が今後も大きな利益をもたらしてくれると信じています。

-Prewave、ネットワーク責任者 Daniel Höfer 氏
-Prewave、VP アドバイザリー Jonas Artmeier 氏

Ninja Van: クラウドコンテナプラットフォームでコアアプリケーションに柔軟性、安定性、スケーラビリティを提供

Wed, 01 May 2024 02:00:00 +0000

※この投稿は米国時間 2024 年 4 月 23 日に、Google Cloud blog に投稿されたものの抄訳です。

Ninja Van のビジネスにとって、安定したスケーラブルな環境でアプリケーションを実行できることは不可欠です。当社は、テクノロジーを活用して東南アジア全域で速達サービスを展開する、急成長中の物流企業です。過去 12 か月間に、200 万近くの企業と提携して 1 日あたり約 200 万個の小包をお客様に配達しており、配達に携わる作業員や従業員は 40,000 人を超えています。

当社は Google Cloud を以前から利用しており、今後も Google Cloud と緊密に連携して、サプライチェーン管理やラストワンマイル宅配サービスなど、新しいサービスや新市場へと事業を拡大していきます。

安全かつ安定したコンテナプラットフォームの導入

当社は、コアビジネスを可能にするアプリケーションとマイクロサービスアーキテクチャを実行するために、安全かつ安定したコンテナプラットフォームをデプロイすることを選択しました。当社はコンテナ化をいち早く取り入れており、最初はカスタムスケジューラであるフリートを使用して CoreOS でコンテナワークロードを実行していました。オープンソースコミュニティの活動を観察していると、Kubernetes が勢いを増し続け、ますます人気が高まっていることがはっきりと見て取れました。当社は、独自の Kubernetes クラスタと API サーバーを実行することにし、その後、コントロールプレーンとワーカーノードの両方で構成された、多数の Compute Engine 仮想マシンをデプロイしました。

Kubernetes について詳しく調べているうちに、当社が行っていた多くのことが、Kubernetes のコア機能にすでに組み込まれていることがわかりました。サービスディスカバリはその一例です。この機能を利用すれば、アプリケーションとマイクロサービスは、コンテナがワーカーノードのどこにデプロイされているかを知らなくても、相互に通信できます。独自のディスカバリシステムを維持し続けても、まったく無駄であろうと判断しました。そこで、従来のシステムの使用をやめ、この Kubernetes コア機能を採用することにしました。

また、Kubernetes に取り組むオープンソースコミュニティに参加して貢献する機会も、とても有意義なものとなりました。Kubernetes はオープン標準ベースであるため、当社の技術スタックをニーズに合わせて自由かつ柔軟に適応させることができました。

しかし、初期段階では、セルフマネージド Kubernetes のアップグレードは困難だったため、フルマネージド Kubernetes サービスに移行することにしました。このサービスの特に大きなメリットは、Google Kubernetes Engine（GKE）ユーザーインターフェースや Google Cloud コマンドラインツールから Kubernetes を簡単にアップグレードできることです。適切なリリースチャンネルを指定するだけで自動アップグレードを有効にすることもできます。

複数の GKE クラスタの運用を簡素化

オープンソーステクノロジーをベースにした技術スタックにより、複数の GKE クラスタの運用を簡素化することができました。モニタリングとロギングの運用については、技術スタックを単一の管理 GKE クラスタ上にコロケーションする一元化されたアーキテクチャに移行しました。ロギングには Elasticsearch、Fluentbit、Kibana を使用し、モニタリングには Thanos、Prometheus、Grafana を使用しています。当初はロギングとモニタリングを個々のクラスタに分散していましたが、管理者がそれぞれのクラスタにアクセスする必要があるため、運用が非効率になっていました。また、Kibana インスタンスと Grafana インスタンスの間で同じチャートを重複して保持することにもなりました。

CI / CD については、デベロッパーツールセットのホスティングとパイプラインの実行用に、専用の DevOps GKE クラスタを実行しています。当社は、JIRA、Confluence、Bitbucket、Bamboo などの Atlassian サービススイートを採用しています。これらのアプリケーションは、同じ DevOps GKE クラスタでホストされます。

当社の CI / CD を一元化していますが、カスタムステップを入れることができるので、チームにある程度の自主性を与えています。チームが新しいバージョンのコードを実装すると、CI パイプラインがテストとビルドプロセスを実施します。これにより、バックエンドサービス用のコンテナイメージアーティファクトと、フロントエンドウェブサイト用の圧縮アーティファクトが生成されます。パイプラインは通常、開発環境とテスト環境でコードを実装してテストし、その後サンドボックスと本番環境にデプロイするようにパラメータ化されています。アプリケーションチームは、要件に応じて、完全に自動化されたパイプラインにするか、本番環境へのデプロイに手動での承認が必要な半自動化されたパイプラインにするかを柔軟に選択できます。

自動スケーリングは実行時にも機能します。リクエスト数が増えると、より多くのコンテナにスケールアップする必要がありますが、リクエスト数が減ると自動的に縮小されます。指標に基づいた自動スケーリングをサポートするために、当社では技術スタックに KEDA を統合しています。

シームレスな開発エクスペリエンスを提供

当社の開発チームは、ある意味でお客様でもあり同僚でもあります。当社は、アプリケーションサービスとインフラストラクチャのテスト、デプロイ、管理、運用を自動化することで、開発者にスムーズなエクスペリエンスを提供することを目指しています。こうすることで、開発者は任されたアプリケーションの構築に集中して取り組みことができます。

これを実現するために、当社は DevOps パイプラインを使用して、インフラストラクチャのプロビジョニング、ソフトウェアのテスト、リリースサイクルを自動化し、簡素化しています。チームは、本番環境をミラーリングする最新の環境ビルドに、本番環境以外のサンプルデータをプリロードして、GKE クラスタをセルフサービスでスピンアップすることもできます。これにより、最新の修正とリリースをテストするための現実的な環境が得られます。

ビルドをデプロイする段階では、Bamboo CI / CD コンソールにアクセスして進行状況を追跡できます。

コード品質は当社の開発プロセスにとって非常に重要です。社内の優れたエンジニアリング部門が、オープンソースコードの検査ツールである SonarQube を使用して、CI / CD の一部からコード品質をモニタリングしています。当社では、単体テストのカバレッジ割合に関して厳格な要件を設定しており、単体テストや統合テストに合格しないものを環境内に入れることを許可していません。

リリースについては、ブラックフライデーやサイバーマンデーなどのコードフリーズ期間を除き、ほぼ 1 日 1 回行っています。コードフリーズ期間には、需要のピーク時に緊急でデプロイする必要があるバグ修正や機能のみをリリースしています。GKE のリリーススケジュールは変更していませんが、並列環境で同時ビルドを実施できるようになり、200 のマイクロサービスアーキテクチャ全体でリリースを効果的に管理できるようになりました。

Google Cloud と GKE の選択の鍵となるレイテンシ

他のクラウドプロバイダから Google Cloud と GKE に移行した際に、Google Cloud データセンター間のレイテンシが極めて低いうえに、信頼性、スケーラビリティが高く、競争力のある価格設定であることから、Google Cloud が正しい選択であったという確信を得ることができました。多くの人がウェブサイトを利用する状況においては、低レイテンシであれば迅速な応答時間でカスタマーエクスペリエンスを向上できます。

さらに、Google Cloud ではアップグレードプロセスが自動化されており、それらのアップグレードまたは変更によっていずれかの API が機能しなくなる可能性がある場合には事前に通知されるため、複数の GKE クラスタのパッチ適用やアップグレードが容易になります。

また、Google Cloud と GKE は当社のビジネスにさまざまな技術的な機会をもたらし、簡素化もそこに含まれています。当社のサービスの多くは永続ストレージを使用しており、GKE によって、Container Storage Interface（CSI）ドライバを通じて、簡単に永続ストレージを自動的にデプロイして管理できます。CSI ドライバにより、ネイティブのボリュームスナップショットが有効になり、Kubernetes CronJob と連携して、TiDB、MySQL、Elasticsearch、Kafka などのサービスを実行しているディスクの自動バックアップを簡単に作成できます。開発面では、Skaffold の検討も行っています。これにより、開発チームが内部開発ループのサイクルを改善し、ローカルの実行インスタンスが Kubernetes クラスタ内にデプロイされているかのように、より効率的に開発できる可能性が広がります。

まとめると、管理のしやすい GKE のおかげで、当社はビジネスが成長し続けているにもかかわらず、200 のマイクロサービスアーキテクチャをわずか 10 人のエンジニアと 15 のクラスタで管理できています。

ご自身でお試しになりたい方は、実践的なチュートリアルをご覧ください。このチュートリアルでは、GKE で継続的デリバリーパイプラインを設定し、変更を自動的に再ビルド、再テストして、サンプルアプリケーションに再デプロイします。

ー Ninja Van、シニア スタッフ ソフトウェア エンジニア Ivan Kenneth Wang 氏

ー Google Cloud、カスタマー エンジニア Woh Shon Phoon

サプライチェーン組織がデータと AI を活用して効率化と最適化を推進する方法

Tue, 12 Sep 2023 02:00:00 +0000

※この投稿は米国時間 2023 年 9 月 1 日に、Google Cloud blog に投稿されたものの抄訳です。

データと AI によってあらゆる業界の変革が進んでいますが、これは多くの業界を支えるサプライチェーンにも当てはまります。近年、サプライチェーンの存在感と影響力は、企業にとっても消費者にとっても大きくなっています。同時に、地政学的課題と財政的課題のバランスをとりながら、サステナビリティへの期待に応えなければならないため、効率的でサステナブルなサプライチェーンの運用がこれまで以上に難しいものになっています。Google Cloud では、データと AI を通じてサプライチェーンのお客様に優れた成果をもたらしてきました。その成果によりお客様は、サプライチェーンの詳細な把握、改善すべき領域の特定、サステナビリティ目標の達成、より多くの情報に基づいた意思決定が可能になっています。

現在 Google では、Data and AI Cloud for Supply Chain を通じて、多くのお客様に専門知識を提供しています。Google は、パートナーやお客様と連携してさまざまな業界について理解を深めています。一方お客様は、Google のテクノロジーとバリューアクセラレータを活用してデータドリブンなサプライチェーンを構築することで、非常に大きな価値を得ています。Data and AI Cloud for Supply Chain には、次のようなメリットがあります。

優れたカスタマーエクスペリエンス: データと AI を活用してサプライチェーンを詳細に把握し、効率性とレジリエンスを高めることで実現できます。製品が必要とされるタイミングや、最も効率的な製品の配送方法を正確に予測可能です。
費用と温室効果ガス排出量の削減: 可視性の向上により、ボトルネック、非効率な箇所、リスクが特定されるため、組織はリソースの解放、可能な分野での自動化、効率化を実現できます。この効果は、費用の削減だけでなく、顧客満足度や従業員満足度の向上によっても明らかになっています。
AI を活用したユースケースのデプロイを加速するプラットフォーム: 最新の生成 AI テクノロジーを企業間検索に活用する準備を整えましょう。たとえば、簡単な質問をするだけで、サプライチェーンの末端に至るまでの分析情報を取得できます。また、リアルタイムの在庫状況に基づいて顧客にパーソナライズされたエクスペリエンスを提供することも可能です。

お客様に価値を提供

革新的な企業は、長年にわたって Google のデータクラウドと AI クラウドを使用し、驚くべき成果を上げてきました。

Coop は、Google のデータと AI テクノロジーを使用して予測することで食品廃棄物を削減しました。その結果、自社で構築した専用ソリューションよりもパフォーマンスが 43% 向上しています。
Renault は、サプライチェーンの可視性向上、在庫費用の削減、在庫部品の耐用年数の把握と費用の削減、物流のより効率的な管理により、顧客満足度を向上させています。

Google の Data and AI Cloud for Supply Chain 機能

Google の Data and AI Cloud for Supply Chain には、企業のサプライチェーンの最適化を支援するさまざまなソリューションとバリューアクセラレータが含まれています。主なソリューションとバリューアクセラレータには次のようなものがあります。

AI によって最適化されたプランニングと予測: Google Cloud のプロダクトと Google のパートナーは、ML を使用して計画プロセス、予測プロセス、店頭在庫状況を最適化できる機能を備えています。これにより企業は、無駄の削減、カスタマーサービスの向上、利益の増加を実現できます。
ベンダーのパフォーマンスの可視化: このソリューションを利用すれば、企業がベンダーのパフォーマンスをトラッキングできます。トラッキングした情報に基づいて、納期遅延や品質不良などの起こりうる問題を検出し、対処できます。
企業間のデータ共有: サプライチェーン全体でパートナー、ベンダー、顧客と簡単にデータを共有できるため、コラボレーションが促進され、調整しやすくなります。また、より多くの情報に基づいた意思決定が可能になります。これは、Google プロバイダの幅広いエコシステムが提供するさまざまなデータソースに接続するとともに、取引パートナーと安全にデータを共有することで実現できていることです。
高度なパートナーエコシステム: Google はサプライチェーンとサステナビリティに関して、さまざまな独立系ソフトウェアベンダー（ISV）と提携しています。Kinaxis、Dematic、Atlas AI、ESG Book、NGIS、Project44、Geotab などの ISV が Google Cloud のデータおよび AI 機能と連携して、お客様の重要なワークフローをサポートします。組織は、Google Cloud の最新の Industry Value Networks を活用することで、開発の取り組みをさらに加速できます。Industry Value Networks では、厳選されたパートナーによってアクセラレータや再利用可能な IP / アセットが提供されているため、業界全体で価値の高いユースケースに対応できます。

サプライチェーンの機会を拡大して加速

Google の Data and AI Cloud for Supply Chain は、ソリューション、バリューアクセラレータ、パートナー製品を統合した強力なスイートです。あらゆる規模の企業がデータと AI を活用してサプライチェーンを最適化できるよう支援します。詳しくは、Google Cloud Next のセッションをご覧いただくか、こちらからお問い合わせください。

- グループプロダクトマネージャー、Lucas Thelosen

Coop、Google の AI とデータクラウドを使った予測で食品廃棄を削減

Tue, 28 Mar 2023 09:10:00 +0000

※この投稿は米国時間 2023 年 3 月 17 日に、Google Cloud blog に投稿されたものの抄訳です。

Coop には 160 年近くにもわたる長い歴史がありますが、最新の運営手法を支える ML チームの歴史はまだ始まったばかりです。Coop の ML チームは、ML による予測を活用してビジネス上の意思決定を支援するという明確なミッションを持って 2018 年に発足しました。これには、サプライチェーンの季節性や予想される顧客ニーズに基づいた需要計画などが含まれています。最終的な目標は、現在のデータの分析情報だけでなく今後発生しうる事象の分析情報も得ることで、ビジネス運営を最適化して、顧客満足度の維持、費用削減、サステナビリティ目標の達成を実現することです（詳細は後述します）。

Coop の初期の予測環境は、1 台のオンプレミスのワークステーションで、PyTorch や TensorFlow といったオープンソースフレームワークを活用したものでした。多数の CPU や GPU に対応するためにモデルの微調整やスケーリングを行う作業は煩雑でした。つまり、そのインフラストラクチャでは、アイデアを実現していくことが困難でした。

こうした課題を解決し、生み出した成果をローカルマシン以外でも活用していくにはどうすればよいかを考えたとき、Coop は、すでに進んでいた Google Cloud への広範な移行を活かし、長く利用し続けられるソリューションを探すことにしました。

イノベーションの新しい基礎を築く

Google Cloud チームとの 2 日間のワークショップで、Coop は膨大なデータパイプラインと SAP システムのデータを BigQuery に取り込むことから始めました。同時に、Coop の ML チームは、新たに取り込まれた情報の物理的な累積キューを実装し、情報を種類別に分類しました。チームは、インフラストラクチャと新しいインスタンスの設定について心配する必要がなくなったことに安堵しました。

次に、Coop チームは、データサイエンスワークフローをさらに発展させるために Vertex AI Workbench を採用しました。利用の開始は非常に簡単でした。目標は、予測モデルをトレーニングして、正確な数値に基づいて生鮮食品の在庫を最適化できるよう Coop の配送センターをサポートすることでした。

高い精度をすばやく実現して顧客ニーズを満たす

概念実証（POC）フェーズの間、Coop の ML チームは AutoML を活用した Vertex AI Forecast モデルに対して 2 つのカスタムモデルを比較し、最終的には Vertex AI Forecast モデル（単一の Extreme Gradient Boosting モデルと PyTorch の Temporal Fusion Transformer）を Vertex AI 上で運用化することになりました。比較では、カスタムの仮想マシン（VM）上で手動でモデルをトレーニングするよりも Vertex AI Forecast を使用する方が高速で正確であることが立証されました。

POC のテストセットでは、WAPE（加重平均パーセント誤差）が 14.5 となりました。これは、社内のカスタム VM でトレーニングしたモデルと比べて、Vertex AI Forecast によるパフォーマンスが 43% 優れていたことを示しています。

POC といくつかの社内テストがうまくいき、現在 Coop は小規模の試験運用環境を構築しています（1 つの配送センターの本番環境に配置）。最終的に Coop ML チームは、ここから予測に関する分析情報を SAP に戻し、SAP で輸入業者や販売業者への注文といった処理を行います。今後数か月で、この本番環境での小規模試験運用が成功して適切な評価を得たら、スイス全土の配信センターに範囲を広げて本番環境での本格的な運用を開始できるようになります。次のアーキテクチャ図は、2 つの段階に含まれるステップの概要を示しています。展望は、予測と予測後の最適化を含め、Google のデータと AI サービスを活用して、近い将来にスイス国内の Coop の配送センターすべてをサポートすることです。

Google Cloud の活用により、社内チームでトレーニングしたカスタムモデルと比較して予測精度が 43% 高まったことは、Coop のサプライチェーンに大きな影響を与える可能性があります。この POC を試験運用環境そして本番環境に移行することで、Coop ML チームは、予測モデルをさらに改善し、食品廃棄の削減といった会社のより広範な目標を効果的にサポートしていきたいと考えています。

食品廃棄を削減してサステナビリティを促進する

Coop は、サステナビリティを事業活動の重要な要素であると考えています。廃棄ゼロの会社になるという目的を持って、サステナビリティ戦略を会社のすべての部門で推進しています。これは、オーガニック商品、動物に優しい商品、フェアトレード商品の販売業者の選択から、サプライチェーン内のエネルギー、二酸化炭素排出量、廃棄物、水の使用量の削減までさまざまな面に及びます。

これらの目標の達成は、つまるところ、最適な管理の問題になります。これは、「ベイジアンフレームワーク」として知られています。Coop は配送の規模を決定するために、分位点の推論を行う必要があります。たとえば、特定の日に 35～40 個のトマトを販売することが予測されるか、あるいは信頼区間は 20～400 個であるかといったことです。より具体的かつ正確な数値で不確実性を低減することによって、Coop は配送センターに正確なユニット数を注文できるようになり、顧客は常に必要な商品を見つけられるようになります。同時に、過剰注文を防止して、食品廃棄の削減につなげることができます。

会社全体でさらに高いレベルの達成を目指す

POC で社内モデルと Vertex AI Forecast モデルの比較を終えた Coop は、今後数か月以内に 1 つの配送センターで本番環境を試験的にリリースし、おそらくその後スイス国内のすべての配送センターに展開する予定です。このプロセスで特に有意義だったのが、プロジェクトをサポートしている ML チームが、Google Kubernetes Engine と BigQuery、および Vertex AI といったさまざまな Google Cloud ツールを使用して独自の ML プラットフォームを構築できることに気づいたことです。ML チームは、事前トレーニング済みの Vertex AI モデルを使用できるようになっただけでなく、データサイエンスワークフローの自動化と作成を短期間で行えるようになったため、常にインフラストラクチャチームに頼る必要がなくなりました。

次に、Coop の ML チームは、BigQuery を Vertex AI の前段階として使用することを目指しています。これが実現すれば、データストリーム処理全体の流れが効率化され、Vertex AI の任意の部分に必要に応じてデータを提供できるようになります。「2 つのツールがシームレスに連携するので、この組み合わせを予測のユースケースで試すのが楽しみです。別の新しいユースケースに利用することもできるかもしれません。また、TensorFlow モデルに大きく依存している Coop 内の他のデータサイエンス部門に、自然言語処理ベースのさまざまな種類のソリューションを導入する可能性についても検討しています」と、Coop の AI / ML アナリティクス責任者 Martin Mendelin 氏は語ります。

「Google Cloud 上で当社独自の ML プラットフォームを構築してカスタマイズすることによって、他のチームの模範となるような標準を形成しています。安定した信頼性の高い環境と、オープンソースのプログラムを利用できる柔軟性によって、チームの力を存分に発揮できるようになるはずです」と、Mendelin 氏は続けます。「Google チームは、その専門知識と顧客第一主義をもって予想をはるかに超えた働きを見せ、目標の実現に向けて力を貸してくれました。これが弊社の事業にとって素晴らしい差別化要因となることを確信しています。」

- Coop、データサイエンティスト Nicolo Lardelli 氏

- Google Cloud、ML スペシャリスト Anant Nawalgaria

ライフサイエンスサプライチェーンでデータと AI の力を活用する

Mon, 19 Dec 2022 00:00:00 +0000

※この投稿は米国時間 2022 年 12 月 14 日に、Google Cloud blog に投稿されたものの抄訳です。

グローバルなライフサイエンスのサプライチェーンには、非常に長くかつ複雑で、多くの流動的要素が絡み合っています。一つの小さな混乱により深刻な遅れが生じ、患者に治療薬を届ける能力に影響が出てしまう可能性もあります。

サプライチェーンの破壊要因

ここ数年、医療機関は内的および外的要因の両方によるさまざまな障害に直面し、結果として、サプライネットワークは医薬品や医療機器を必要な場所に時間通りに届けることができない状況に陥っています。障害には次のようなものがあります。

労働力や物資の不足
材料費の高騰
原材料の制限
地政学的な事象
異常気象

では、制御できないサプライチェーンの破壊要因を、どのように克服すればいいのでしょうか。

インテリジェントな医療サプライチェーン

すでに多くの組織がデータドリブンなサプライチェーンを導入しているものの、今なお課題は解消されていません。これには、静的でサイロ化された異なる機能のサプライチェーンアプリケーションの使用、上流から下流の業務まで主要な取引先との限られたデータ交換、関連する外部データを有効活用できない、などが挙げられます。

Google Cloud は、有意義で効果的な変化をもたらす鍵となるのは、可視性、柔軟性、イノベーションを実現するデータドリブンなサプライチェーンであると考えています。

Google Cloud のソリューションは、予測できない事態に備え、皆様のデータの価値を高めることができます。AI 主導の分析情報を活用することで、物流ネットワークを強化し、ワークフローとサプライチェーンを最適化して、高い信頼性とインテリジェンス、サステナビリティを実現します。Google Cloud が取り組むビジネス上の課題には、次のようなものがあります。

Vertex AI Forecast を使用した需要の予測
事前構築された ML モデルを使用した品質と予測メンテナンスの目視検査
Cloud Fleet Routing API による集配業務の自動化と最適化
Supply Chain Twin によるリアルタイムかつ包括的な在庫の可視化

物流ネットワークをリアルタイムで把握して、不測の事態に備えるようにしましょう。AI と分析の力を活用し、サプライチェーンを強化する実用的な分析情報を得る方法について詳しくは、こちらをご覧ください。

- Google Cloud、ライフサイエンスキーアカウント担当ディレクター Geri Studebaker
- Google Cloud、サプライチェーンおよびロジスティクス業界ソリューション担当ディレクター Paula Natoli

嘉穂無線ホールディングス株式会社が Google Cloud を使った需要予測で小売業の課題に挑む

Mon, 05 Dec 2022 01:00:00 +0000

編集者注: Google Cloud を利用する企業のリーダーの皆様にお話を伺い、想いを語っていただく Google Cloud Leader’s Story。連載 2回目となる本記事では、福岡県に本拠を構え、ホームセンターの運営等の事業を展開する、嘉穂無線ホールディングスの代表取締役を務める柳瀬隆志氏にお話を伺いました。

嘉穂無線ホールディングス（以下、嘉穂無線 HD ）は、「常に変わる社会の中で、新しく生まれる続ける社会課題を解決する役割を担うこと」を自社の存在意義と捉え、九州地方を中心に中核事業であるホームセンター「グッデイ」を運営する株式会社グッデイ、学習工作キット「エレキット」の製造及び販売を担う株式会社イーケイジャパン、データ活用やクラウドサービス活用推進などの IT 事業を営む株式会社カホエンタープライズといったグループ事業を展開しています。

今回はグループの代表取締役を務め、また DX の旗手としても広くその名を知られている柳瀬隆志氏に、 Google Cloud のテクノロジーを活用して小売業の課題を解決する取り組みや、Google Cloud への期待についてお話を伺いました。

利用しているサービス：Google Kubernetes Engine, Google App Engine, Cloud Functions, Cloud Scheduler, Cloud Run, Cloud SQL, Cloud Memorystore, Cloud Firestore, BigQuery, Cloud Composer, Cloud Pub/Sub, Cloud AutoML, Cloud Dialogflow, Cloud Speech API

利用しているソリューション：

サプライチェーンとロジスティクスソリューション

実際に手を動かすことが DX 進展の鍵

地方の小売業として DX を積極的に推進する嘉穂無線 HD。グループの代表取締役を務める柳瀬氏が、DX を扱う様々なイベントで講演を行う中で痛感するのは、DX を推進したい経営者自身が深く最新のITやクラウドの知識をもつべきだという事だといいます。

総合商社でキャリアをスタートした柳瀬氏は、食材の輸入業務に関わっていました。当時はメールや FAX が情報のやり取りの中心であり、大量の手入力を必要とする非常に非効率な業務であったといいます。そのような非効率な業務を、簡易的なデータ管理システムを構築して効率化した経験は、その後の仕事の進め方にとても大きな影響があったそうです。

家業であるグッデイに入社時、メールアドレスもウェブサイトもないという自社の状況に驚いたそうですが、2015年から自社システムのクラウド化に着手。現在はシステム関連の会議には必ず出席し、積極的に議論に参加。また、技術書の新刊は欠かさずチェックするなど、経営者でありながら新しい技術の吸収を怠りません。自らの IT への関わりを、柳瀬氏は次のように表現します。「ITだけでなく、人がする業務も含めた、広い意味でのシステムを作る役割。色々な人やモノを組み合わせて実際の仕事の現場で役に立つ仕組みを作ることが、自分の仕事だと思っている。」

このような柳瀬氏のもと、社内には社員が自主的に IT に触れる土壌が育っています。社内では自社のユースケースを題材にしたデータ分析業務に関する勉強会が開催されており、IT エンジニアの指導の下、バイヤーのような非エンジニアが SQL を学び、業務に必要なデータを自分で抽出する取り組みを始めています。また、COBOL で組まれた古い基幹系システムを、社員を中心に Web 化するなど、システムの内製化も積極的に進めています。

「DX 人材の育成とは特殊なスキルを身につける人を育成するという事ではなく、実際の業務に役立てられるデジタルスキルを教え、実践出来るようにすることだと考えています。SQL のように、実際に自分たちが関心有るデータを扱うことで、データとはどのようなもので、どう活用すればよいのか、といった知見が自然と身に付いていくものだと思います。」と柳瀬氏は話します。

また、「学んだことは、手を動かして試さなければ定着しません。それにはすぐ試すことが出来るクラウドが最適です。 SQL を例にとると、我々には BigQuery がすぐ使える環境にある、ということが大きい。ですが、多くの企業では社員が簡単にクラウドに触れることが出来ず、座学で理論を教えて DX 人材を育成しようとするが、それでは思うように育成が進みません。」 DX が思うように進まないジレンマを柳瀬氏はこのように分析します。

これからの小売業に求められる変革

「国内の人口が減少していく以上、今後の小売業は従来のプライベートブランド戦略や、大量仕入れによる購買コストの削減など、安く大量に売るアプローチでは成り立たなくなります。お客様が本当に求めるものを理解して、それに対して応えようと考えることが重要です。」と柳瀬氏は語ります。

お客様を理解し、お客様の求めるものに応えるために、実店舗を展開する小売業が迫られる変革について、柳瀬氏は次のように語ります。「EC サイトが出来ていることは、実店舗でも同じように出来なければいけません。実店舗がなくなってしまうことは無いと思いますが、両者の利便性に差が有ってはいけないと思っています。」

そして、実店舗に EC サイト同等の利便性を持たせる要はIT であり、実現には IT に関する知識が必要不可欠であるとして、小売業の変革とデジタル技術を持った人材の育成の必要性を強く訴えています。

AutoML Tables を活用した季節商品需要予測の取り組み

嘉穂無線 HD では、BigQuery に全店舗の売上データが集約されており、それを AutoML Tables で学習させることで、季節商品の需要予測を実現しています。この仕組を取り入れた経緯や、得られた効果について柳瀬氏に伺いました。

「Google のカンファレンスで米国の活用事例を聞いたことが始めたきっかけです。自社が持つデータと気温のデータを組み合わせると、季節商品の需要予測が出来るのかな、と思い立ち、自社で持つ過去 5 年分の販売データと気温のデータを使って AutoML Tables のチュートリアルに従ってモデルをトレーニングしてみました。やってみたら、思っていたよりも非常に簡単だ、という印象を受けました。」

一方、季節商品の需要を予測するには将来の気温の予測値が必要で、その予測値自体が正確であるという保証がありません。そのため、「機械学習を使って細かい数字を100％当てにいく」というアプローチは成功しない、というのが試行錯誤を繰り返した末に柳瀬氏が行き着いた結論です。

「気温の予測モデルは大きく分けて平年並み、平年より暑い、平年より寒い、の3パターンに設定しています。季節商品の売上を予測するとき、これまでバイヤーは”今年は昨年より暑いからこの商品の売上は前年比30％上がる”といったことを言うわけですが、この数字には根拠がありません。平年との気温差の値や商品毎に売上の前年比は変わります。」と、バイヤーの経験と勘に頼った需要予測の限界を柳瀬氏はこう説明します。

”いつ売れるか”を正確に予測することは難しいが、”今シーズンどれくらい売れるか”を予測することは十分可能と結論づけ、AutoML Tables が算出した予測値を上限値として仕入れを行うことで、仕入れの意思決定業務の改善を実現しました。「この予測を取り入れたことで、在庫回転率はそれまでの約 1.4 倍に改善しました。」と、柳瀬氏は機械学習による需要予測がグッデイにもたらした効果について明かしました。

一方、「実現には技術的な知識と最新の情報に対するアンテナが不可欠であり、経営者が自社のデータの扱い方や分析方法を正しく理解していなければ、自社に最適な方法を見つけることは難しいと思います。」と、経営者が IT に対する関心を持ち、データを理解することの重要性を柳瀬氏は強調します。

Google Cloud にこれから求めるもの

もともと一人のコンシューマーとして Google のプロダクトには親近感を持っていたという柳瀬氏。Google Cloud と出会ったきっかけは 2015 年頃に開催された Google のイベントでした。

「イベントでは BigQuery などのテクノロジーが紹介されていたものの、小売業でどのように使うのか、当時全くイメージ出来ませんでした。また、既に一般提供されていた Google App Engine についても、”尖ったサービスなのは分かるが、これは何に使うものなんだろう？でも、きっとものすごく便利なテクノロジーに違いない”、と思っていました。」と当時の印象を柳瀬氏は笑いを交えながら振り返ります。

これまで Google Cloud の尖ったプロダクトにわくわくしてきた柳瀬氏、これから Google に望むことは「クラウドはまだまだ普及途上。様々なユーザーにとって使いやすいプロダクトにブラッシュアップしていく動きも予想しますが、これからもワクワクするような尖った技術と尖ったプロダクトを世に送り出してほしいと思います。」と締めくくりました。

嘉穂無線ホールディングス株式会社

1950年2月設立。創業者・柳瀬網夫氏が飯塚市の自宅にラジオパーツ・アマチュア無線専門の小売店を開設し創業した嘉穂無線株式会社が起源。ホームセンターを運営する株式会社グッデイをはじめ、学習工作キット「エレキット」を手掛ける株式会社イーケイジャパン、データ活用サービス事業を提供する株式会社カホエンタープライズと行った、各事業会社を統括運営するホールディングスカンパニー。

インタビュイー

嘉穂無線ホールディングス株式会社代表取締役社長柳瀬隆志

インフレに打ち勝つ: ホリデーシーズンを迎える小売業者のための 5 つのヒント

Mon, 28 Nov 2022 05:00:00 +0000

※この投稿は米国時間 2022 年 11 月 19 日に、Google Cloud blog に投稿されたものの抄訳です。

予算の問題やインフレショックが原因で消費者の行動は著しく変化し、2020 年のパンデミック以来目まぐるしく方向転換しています。これまでは十分な商品が手に入らない状況でしたが、現在は適切な商品が適切な価格で提供されていません。小売業者はホリデーシーズンに向けて態勢を整え、ますますコスト意識の高まる消費者に対してスムーズな商品検索とデジタルショッピング体験、適切な在庫、パーソナライズを通じて価値を提供できるよう準備する必要があります。

この記事では、最近の eMarketer ウェブキャストから収集した「小売業者がインフレの影響にうまく立ち向かうにはどうすればよいか」についてのいくつかの見解と、Amy Eschliman（Google Cloud、小売ソリューション戦略および業界エンゲージメント担当マネージングディレクター）、Alexis Hoopes 氏（Mattel Inc.、バイスプレジデント兼 e コマースおよび消費者直販（DTC）責任者）、Elissa Quinby 氏（Quantum Metric、リテールインサイト責任者）といった専門家による実用的なアドバイスをご紹介します。それでは、小売業者が検討すべき 5 つの重要なポイントを見ていきましょう。

1. 早めのホリデーショッピング計画に備える。予算に限りがある買い物客は、かつてないほど早くからショッピングの計画を立てています。Google のパートナーである Quantum Metric の最新の小売ベンチマーク調査によると、米国消費者の 40%、英国消費者の 30% が、すでにホリデーシーズンの買い物を始めています1。Mattel の Alexis 氏は次のように語ります。「私たちはこれまで、お客様のために早くから機敏に行動し、お客様が買い物しようとしたときに商品を提供できるよう準備しておくことを学んできました。」昨今の物価の上昇について、彼女は次のように付け加えました。「お客様は事前計画や調査を今まで以上に念入りに行い、価格の高い商品を購入する際は商品詳細ページを何度も確認してから買い物かごに入れるようになっています。」

Quantum Metric の同じ調査では、平均注文金額は 2022 年 1 月から 7 月の間に増加し（前年同時期よりも多い1）、買い物頻度は減っていたこともわかりました。物価が上昇していることから、買い物客の 37% は、費用を予算内に抑えるために事前に計画を立てて商品を一度に購入しています1。Amy は次のように述べています。「つまり、お客様にショッピングカートを放棄させないためには、お客様が求めているものを至極簡単に見つけられるようにする必要があります。」

Google 品質の検索とレコメンデーションの機能を実装して、買い物客が適切な商品を簡単に見つけられるようにすれば、カートの放棄を減らし、コンバージョンを増加させることができます。

2. 在庫切れの問題に対処する。パンデミック中に表面化したサプライチェーンの問題の多くは解消されましたが、在庫は依然として小売業における難題です。Google / Ipsos の調査によると、2021 年のホリデーシーズン中に消費者が受けた「在庫切れ」のメッセージは、パンデミック前と比較して 253% 増加しました²。Elissa 氏はさらに、米国と英国の消費者の大多数が月に数回の在庫切れに遭遇したと指摘しています。しかし、これは流動的な状況であり、消費者の需要がたとえばブランド品からノーブランド品やホワイトラベル商品に急速に変化すると、小売業者は在庫の肥大化に直面します。「今後 6 か月ほどは、消費者の需要を満たす適正な在庫を持つことに特に注意を払わなければなりません」と彼女は助言しています。

未だかつて、エンドツーエンドの可視性とサプライチェーン全体でリアルタイムに行動する力がこれほどまで喫緊に必要とされたことはありません。Google Cloud とそのパートナーは、エンドツーエンドの可視性、分析、アラート主導のイベント管理を可能にするソリューションや、調達、フルフィルメント、配達のようなプロセスを合理化する AI ソリューション / 自動化を通じて、サプライチェーンの主要な問題に正面から取り組んでいます。

3. 価値を導入する: 商品の品質と体験を伝える。価格の上昇は多くの買い物客にとって最も重要な要素ではありますが、消費者による購入の判断基準は価格のみにあると考えるのはよくある誤解です。Alexis 氏は次のように述べています。「e コマースにおいて、私たちは価格、商品、サービス、体験について話し合います。価格はお客様にとって柱の一つにすぎません。Mattel では、商品と体験に完全に的を絞っています。なぜこれが特別なのでしょうか？新たな方法でお客様と直接つながるにはどうすればよいでしょうか？大切なのは、「あっ」という驚きの瞬間を作り出し、より深く結び付くことです。「お客様に対する価値」という意味では、それがその商品の購入を促進する強みになります。

Elissa 氏は、消費者は買い物に際して多くの比較検討を行いますが、それは実際には、高品質な商品にせよ、高品質な体験にせよ、価値を比較しているのだとも指摘しています。BigQuery で構築された Quantum Metric の継続的製品設計ソリューションは、モバイルアプリケーションやウェブアプリケーションなどの複数のデジタルタッチポイントからデータを取り込んで顧客シグナルを製品ライフサイクルのあらゆる段階に結び付け、それを基にお客様が実際に求めている商品や体験を提供します。

4. どのチャネルでも一貫した体験を提供する。今日の消費者は、チャネル横断的なショッピング体験を要求しています。「チャネル体験は、オンラインや店舗だけにとどまらず、今やいたるところに広がっています。」Amy はこのように説明します。「私たちはこれを「ユビキタスデジタルショッピング」と呼んでいます。」Elissa 氏は、消費者の 75% が買い物のほとんどをデジタルで行っていると付け加えました。ただし、モバイルはデジタルトラフィックの 67% を占めるものの、売り上げに対する割合は 49% にすぎません¹。「最近のデバイス別のトラフィックとコンバージョン率の傾向を見ると、ビッグセール期間に最も多くのトラフィックを生み出すのはモバイルになると予想されます」と彼女は語ります。「人々は商品を見つけ、それを記憶しておく手段を求めており、おそらくプレースホルダやリマインダーとして商品をカートに追加することさえあります。しかし、最終的な購入はデスクトップで行うのを好んでいます。したがって、一貫した体験を提供することは小売業者にとってきわめて重要であり、ブラックフライデーやサイバーマンデーのような大規模なセール期間では特にその重要性が増します。」Elissa 氏はまた、商品やサイト設計に関するテストを早期に終わらせること、顧客体験を組織全体で総体的に把握すること、作業に優先順位を付けて円滑に進めることも助言しています。

現代の消費者が期待しているのは、時と場所を選ばず、店舗にいるか、ウェブサイトを閲覧しているか、アプリの使用中か、あるいはソーシャルメディア広告を見ているかを問わず、自分のニーズに最も適合した商品を購入できること、そして、小売業者のコマースサイトに最初にどのように入ったか、またはコマースサイトからどのように出たかにかかわらず、一貫した良好な体験が得られることです。Google の 2022 年度版小売マーケティングガイドには、オンライン販売やアプリ内販売の売り上げを伸ばす方法についての有益な情報やヒントが掲載されています。

5. タッチポイントをパーソナライズしてロイヤリティを高める。顧客ベースとの関係を築き、お客様に商品の価値を理解してもらうことは不可欠です。Alexis 氏が指摘したキーポイントは、ホリデーシーズンが拡大する中でメッセージの鮮度を保ち、お客様が再びショップに訪れたときに新しいメッセージを提供するということです。「お客様のエンゲージメントを高めるためには、お客様が探しているものを適切なときに見つけられるようにする必要があります。」彼女はこう語ります。「お客様は綿密に計画を立て、早い段階でウィッシュリストを作成してから、最後の最後にできるだけ安い価格で商品を購入しようとします。これらを中心に置くことが大切です。」

Alexis 氏は、今日の消費者は閲覧した商品やカートに入れた商品に関するデータポイントを豊富に提供するという点も指摘しています。「e コマースの優れているところは、小売業者がこれらすべてのデータポイントを利用して個々のお客様向けにカスタマイズされた直接的なメッセージを作成できることです。」彼女はこのように説明します。

Amy は、商品発見とパーソナライズによるコンバージョンに常に焦点を合わせ、顧客データに基づいて分析やアクションを実行することを推奨しています。「企業の最大の資産はデータです。データを可能な限り多様な方法で利用し、それを社内全体で活かすことがきわめて重要になります。」彼女はこのように語ります。「自社データを活用し、マーケティングキャンペーンからサプライチェーンの効率化に至るまで、あらゆることを活発化します。自社のデジタルプロパティを訪れるすべてのお客様が、できるだけ簡単に商品を見つけられるようにします。レコメンデーションに特に注意を払い、パーソナライズを駆使してお客様のショッピング体験を独自色のある充実したものにしてください。」

これらの目標を達成するには、最新のクラウドデータウェアハウスを導入し、顧客データプラットフォームを稼働させる必要があります。Google Cloud の高度なデータ能力とパートナーエコシステムが、さらにパーソナライズされたマーケティング、ショッピング体験、カスタマーサービスの基盤となる顧客データプラットフォームをどのように実現できるかをお確かめください。

この記事は要点を簡単にまとめたものです。さらに詳しくお知りになりたい場合は、オンデマンドウェブセミナー「小売業者がインフレの影響に立ち向かうための 5 つの方法」に登録のうえご覧ください。

^{1. Quantum Metric の小売ベンチマーク、「Adjusting for Inflation」。このレポートは、2022 年 1 月～7 月の閲覧行動の集計結果と、米国および英国の 3,400 人の消費者を対象としたアンケート調査に基づいています。}

^{2. Google / Ipsos、Holiday Shopping Study、2021 年 10 月～2022 年 1 月、オンラインアンケート、米国、n=7,253（過去 2 日間にホリデーシーズンの買い物をした 18 歳以上のアメリカ人）}

- Google Cloud、セールス、リテール、および CPG 戦略 ISV ポートフォリオ担当ディレクター Vikas Jain

- Quantum Metric 社 CEO Mario Ciabarra 氏

Google Cloud ML を活用した風向き予測によりルフトハンザドイツ航空で定時運航の便数が増加

Thu, 06 Oct 2022 01:00:00 +0000

※この投稿は米国時間 2022 年 9 月 29 日に、Google Cloud blog に投稿されたものの抄訳です。

空港の運営は、風の強さと方向に大きな影響を受けます。ルフトハンザグループも例外ではありません。特に厄介なのが、BISE と呼ばれる、スイス高原を北東から南西に横切って吹く冷たく乾燥した風です。この風は、フライトスケジュールに深刻な影響を及ぼすことがあります。たとえば、航空機が滑走路を変更せざるを得なくなり、結果として航空便の遅延や欠航が連鎖的に発生することがあります。特にチューリッヒ空港では、BISE の影響で発着便数が最大 30% 減少することもあるため、航空便の遅延と欠航が一層深刻で、このことはルフトハンザドイツ航空にとって巨額の収益減（および乗客の不満）の原因となっています。

このような風を事前に予測できれば、ネットワーク運用管理チームは、滑走路と時間枠をまたいで最適なフライトスケジュールを組み、スケジュールの混乱を最小限に抑えることができます。とはいえ、風の速度と強さをモデル化し、予測するのは非常に困難です。そこでルフトハンザドイツ航空は、Google Cloud に協力を求めました。

機械学習（ML）を活用すれば、空港と航空会社は、このような運航の妨げとなる気象現象をより的確に予測し、管理できるようになります。このブログ記事では、ルフトハンザドイツ航空が Google Cloud とともに Vertex AI Forecast サービスを使用して行ったテストをご紹介します。このテストでは、ヒューリスティックに基づく社内システムと比較して 40% 以上高い精度で BISE の発生時間を予測することができました。しかも、この大幅な改善は数日以内に達成されました。この規模と精度の ML プロジェクトには数か月を要することが多いにもかかわらずです。

ルフトハンザグループのデジタル運用最適化担当シニアディレクターの Christian Most 氏は、「Googleは AI と機械学習の分野で感心するほど高度なテクノロジーと技量を持っているため、Google の専門家と協力して当社の技術と Google の専門知識を組み合わせれば、最高の成果を得られると確信していました」と述べています。

データセットの収集と準備

今回のルフトハンザと Google Cloud のプロジェクトの目標は、深層学習に基づく機械学習の手法を活用してチューリッヒのクローテン空港の BISE を予測してから、その予測がヒューリスティックに基づく社内ソリューションを上回るか確認し、本番環境における深層学習の手法の使いやすさと実用性を測定することでした。

深層学習に基づく手法には大規模なデータセットが必要なため、本プロジェクトでは、過去 5 年間にスイス国内の複数の気象台で収集された多数の気象センサー測定値からなるデータセット「Meteoswiss シミュレーションデータ」を利用しています。このデータセットを使用することで、風向、風速、気圧、気温、湿度などの要素を 10 分刻みで測定したデータと、高度などの気象観測所の位置に関する情報を合わせて取得できました。BISE の予測に有用であると仮定したこれらの要素には、貴重な指標が含まれていることが判明しました。これについては後述します。

次に、収集されたデータに対して Vertex AI Workbench を使用した大規模なクリーニングと特徴量エンジニアリング処理を実行し、トレーニング用の最終データセットを準備しました。クリーニング段階では、欠損値が多すぎる特徴（行）やエントロピーの統計的テストに不合格となった特徴（行）を削除する処理が実行されました。風向は円形（0～360 度）の特徴であるため、この列（特徴）は、対応するサインとコサインの埋め込み値という 2 つの特徴に置き換えられました。次に、すべての気象台のデータを 10 分間隔で整理したうえで、10 分間隔で配置した各列に関連する特徴とセンサー測定値をすべて格納するという方法でデータセットを平坦化しました。

ターゲット変数である BISE は変数として直接利用できないため、「滑走路周りの追い風速度」という BISE の代理変数を考案しました。これは、あるしきい値を超えると、滑走路沿いに BISE が存在することを示すものです。

Google Cloud での風の予測

これでデータセットの準備が整ったわけですが、ルフトハンザと Google Cloud は、Google の AutoML を搭載した予測サービス「Vertex AI Forecast」のテストと調整を決定する前に、複数の選択肢を評価しました。こうすることで最適な結果を得られると考えたためです。Vertex Forecast では、必要な特徴量エンジニアリング、ニューラルアーキテクチャ探索、ハイパーパラメータチューニングが可能です。このサービスは Google Cloud によって完全自動方式で管理されており、Kaggle の M5 Forecasting Competition では上位 2.5% のスコアを獲得しています。最高性能のディープラーニングモデルを作成、デプロイ、メンテナンスする際の手作業を減らしたいと考えていたルフトハンザドイツ航空は、こうした利点のある Vertex Forecast を、きわめて優れた選択肢であると判断しました。

元データファイルがクラウドストレージから読み込まれ、Vertex AI Workbench 上で前処理が行われました。次に、Vertex AI Pipelines 上でトレーニングパイプラインが開始され、以下の手順が順次実行されました。

.csv データファイルが、Cloud Storage から Vertex AI が管理するデータセットに読み込まれました。
このデータセットを使用して Vertex AI の予測トレーニングジョブが開始され、Vertex AI Model Registry にもモデルとして登録されました。
完了後、モデルがテストセットで評価され、モデルの予測、およびテストセットの入力特徴とグラウンドトゥルースが BigQuery のユーザー定義テーブルに格納されました。また、サービスとモデルのダッシュボードでは、複数のテスト指標を利用することができました。

特に大きな課題として、BISE 発生時の測定値の間隔が非常に長く、測定値の数が非常に少なかったため、データセットのバランスが悪いということがありました。これに対処するため、BISE が発生したインスタンスと、これらと時間的に近いインスタンスが、サンプル数の逆平方根（ISNS）、有効サンプル数（ENS）、ガウス再重み付けなどの方法で算出した重みを使用して重み付けされました。各方法の計算式を以下に示します。これらの重みはデータセット内に別の列として提供され、以後、このサービスで「重み」列として繰り返し使用されました。

ISNS

ENS

加重ガウス

結果と次のステップ

図 1. 2 時間における再現率

図 2. 2 時間における F1 スコア

上図において、X 軸は予測期間を、Y 軸はそれぞれの指標（再現率 / F1 スコア）を表しています。複数回のテストを経て、Vertex AI Forecast は、ベースラインとしたルフトハンザドイツ航空のヒューリスティックに基づくシステムを上回る高い再現率と精度 t（赤い棒）を達成していることが判明しました。また、予測期間が未来に向けて延長されるにつれ、精度の差が徐々に拡大していました。2 時間の予測期間におけるスコアを見ると、Google のカスタム構成 Vertex AI Forecast モデルは、ヒューリスティックに基づく社内システムと比較して 40%、ランダム推測ベースラインと比較して 1,700% の改善を達成していました。他のテストでは、6 時間の予測期間で Vertex AI Forecast の精度の優位性がさらに高まることが確認されました。数時間前に BISE を予測できれば航空便の遅延を防ぐうえで非常に有用であるため、これはルフトハンザドイツ航空にとって素晴らしいソリューションとなりました。

スイス国際航空のプロダクトオーナーである Oliver Rueegg 氏は、「Vertex AI Forecasting によって、BISE の正確な長期予測をできるだけでなく、予測モデルのトレーニングとデプロイをこれまでよりはるかに簡単かつ迅速に行えるようになったことは、非常にうれしいことです。お客様や関係者に最高のサービスを提供するためのイノベーションを加速できるのですから。」と述べています。

ルフトハンザドイツ航空は、このソリューションをクローテンの運用管理センターでネットワーク管理者が使用している Operations Decision Support Suite に統合して本番環境に導入する計画を立案しています。また、Google の専門家と緊密に連携して、Vertex AI Forecast と Google の他の AI/ML サービスの両方を自社のユースケースに合った形で統合することも検討しています。

- Google 機械学習シニアスペシャリストエンジニア Anant Nawalgaria

Cloud Run と Firestore を活用したモビリティダッシュボードの構築

Tue, 12 Jul 2022 00:00:00 +0000

※この投稿は米国時間 2022 年 6 月 22 日に、Google Cloud blog に投稿されたものの抄訳です。

膨大な量のデータを理解する鍵は可視化にあります。今日では、BigQuery や Looker により、ペタバイト規模のデータを分析し、洗練された方法で分析情報を抽出することが可能となっています。しかし、毎秒アクティブに変化するデータをモニタリングするにはどうしたら良いでしょうか？この投稿では、Cloud Run と Firestore を活用したリアルタイムダッシュボードの構築方法について説明します。

モビリティダッシュボード

リアルタイムな更新が必要なビジネスユースケースは数多く存在します。例として、小売店での在庫のモニタリング、セキュリティカメラ、ライドシェアなどの MaaS（Mobility as a Service）アプリケーションなどが挙げられます。MaaS ビジネスの分野では、車両の位置を把握することがビジネスの意思決定を行ううえで非常に役立ちます。この投稿では、地図上で車両をリアルタイムにモニタリングできるモビリティダッシュボードを構築していきます。

アーキテクチャ

クライアントサイドで設定を行うことなく、ウェブブラウザからこのダッシュボードにアクセスできる必要があります。Cloud Run が適している理由は、URL を生成でき、何百万人ものユーザーに対応できるスケーラビリティも当然備えているためです。まず、地理空間データをプロットできるアプリと、地理空間データの更新をブロードキャストできるデータベースを実装する必要があります。今回使用する機能とアーキテクチャは次のとおりです。

Cloud Run - ウェブアプリ（ダッシュボード）のホスティング
（streamlit - データを可視化してウェブアプリを構築するライブラリ）
（pydeck - 地理空間データをプロットするライブラリ）
Firestore - データの同期を維持するフルマネージドデータベース

以下の図は、このシステムの簡易的なアーキテクチャを示したものです。本番環境では、データの取り込みと変換パイプラインも実装しなければならない場合があります。

最終形態に進む前に、以下の手順を実行して各コンポーネントを理解しておきましょう。

ステップ 1: Cloud Run と streamlit でデータ可視化ウェブアプリを構築する

streamlit は、フロントエンド（HTML や JS など）の知識がなくても見栄えのよいデータ可視化アプリを作成できる OSS ウェブアプリフレームワークです。データ分析で pandas の DataFrame を使い慣れている場合、実装にそれほど時間はかからないでしょう。たとえば、次の数行のコードで DataFrame を簡単に可視化できます。

code_block: <ListValue: [StructValue([('code', "import streamlit as st\r\nchart_data = pd.DataFrame(\r\n np.random.randn(20, 3),\r\n columns=['a', 'b', 'c'])\r\nst.line_chart(chart_data)"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fd1433af640>)])]>

ウェブアプリ上のグラフ（ソース）

このアプリは Cloud Run 上で簡単に実行できます。streamlit を requirements.txt に追加して、一般的な python のウェブアプリイメージから Dockerfile を作成するだけです。Docker に慣れていない場合は、buildpacks を使用してこのジョブを実行できます。Dockerfile を作成する代わりに、次の 1 行のみで Procfile を作成できます。

code_block: <ListValue: [StructValue([('code', 'web: streamlit run app.py --server.port $PORT --server.enableCORS=false'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fd1433af8e0>)])]>

以上をまとめると、最低限必要なファイルは次のとおりです。

code_block: <ListValue: [StructValue([('code', '.\r\n|-- app.py\r\n|-- Procfile\r\n|-- requirements.txt'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fd1433af850>)])]>

デプロイも簡単です。以下のたった 1 つのコマンドで、このアプリを Cloud Run にデプロイできます。

code_block: <ListValue: [StructValue([('code', '$ gcloud run deploy mydashboard --source .'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fd1433afa90>)])]>

このコマンドは、buildpacks と Cloud Build を使用してイメージを構築および作成するため、ローカルシステムにビルド環境を構築する必要はありません。デプロイが完了したら、生成された URL（例: https://xxx-[…].run.app）からウェブアプリにアクセスできます。この URL をウェブブラウザにコピーして貼り付けると、最初のダッシュボードウェブアプリが表示されます。

ステップ 2: Firestore データベース内の変更を受信するコールバック関数を追加する

ステップ 1 では、データを固定した条件で可視化したり、streamlit 上の UI 関数でインタラクティブに可視化したりできます。ステップ 2 では、このデータが自動で更新されるようにします。

Firestore はスケーラブルな NoSQL データベースであり、リアルタイムリスナーを通じてクライアントアプリ間のデータの同期を維持します。Android と iOS で使用でき、主要なプログラミング言語で SDK も用意されています。Python で streamlit を使用するため、Python クライアントを使用します。

この投稿では、Firestore の詳しい使用方法については省きますが、特定の「コレクション」が変更になった場合に呼び出されるコールバック関数は簡単に実装できます。[参照]

code_block: <ListValue: [StructValue([('code', "from google.cloud import firestore_v1\r\ndb = firestore_v1.Client()\r\ncollection_ref = db.collection(u'users')\r\ndef on_snapshot(collection_snapshot, changes, read_time):\r\n for doc in collection_snapshot.documents:\r\n print(u'{} => {}'.format(doc.id, doc.to_dict()))\r\n# このコレクションを監視する\r\ncollection_watch = collection_ref.on_snapshot(on_snapshot)"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fd1433aff70>)])]>

このコードでは、users コレクションが変更された場合に on_snapshot コールバック関数が呼び出されます。ドキュメントの変更も監視できます。

Firestore はフルマネージドデータベースであるため、事前にサービスをプロビジョニングしておく必要はありません。「モード」とロケーションを選択するだけで使用できます。リアルタイム同期機能を使用する場合は、「ネイティブモード」と、最も近いロケーションまたは希望するロケーションを選択します。

streamlit と Firestore の併用

ここでは、streamlit で Firestore を実装します。on_snapshot コールバック関数を追加して、Firestore から送信された最新データでグラフを更新します。なお、streamlit でコールバック関数を使用する際、on_snapshot 関数はサブスレッドで実行しますが、streamlit での UI 操作はメインスレッドで実行する必要があるので注意してください。そのため、スレッド間のデータを同期するのにキューを使用します。コードは次のようになります。

code_block: <ListValue: [StructValue([('code', 'from queue import Queue\r\nq = Queue()\r\ndef on_snapshot(collection_snapshot, changes, read_time):\r\n for doc in collection_snapshot.documents:\r\n q.put(doc.to_dict()) # データをキューに入れる\r\n# 以下はメインスレッドで実行される\r\nsnap = st.empty() # プレースホルダ\r\nwhile True:\r\n # q.get() はブロッキング関数なので、タイムアウトの追加を推奨します\r\n doc = q.get() # キューからの読み取り\r\n snap.write(doc) # UI を変更する'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fd1433afd30>)])]>

このアプリをデプロイし、参照するコレクションに何か記述すると、ウェブアプリ上でデータが更新されたことを確認できます。

ステップ 3: streamlit で地理空間データをプロットする

Cloud Run でウェブアプリをホストする方法がわかったので、次に Firestore でデータを更新する方法を説明します。まず、streamlit で地理空間データをプロットする方法が必要です。streamlit で緯度と経度を含む地理空間データをプロットする方法はいくつかありますが、ここでは pydeck_plot() を使用します。この関数は、地理空間可視化ライブラリ deck.gl のラッパーです。

例として、プロットするデータを緯度と経度で提供し、レイヤを追加してそのデータを可視化します。

code_block: <ListValue: [StructValue([('code', 'import streamlit as st\r\nimport pydeck as pdk\r\nimport pandas as pd\r\nimport numpy as np\r\ndf = pd.DataFrame(\r\n np.random.randn(1000, 2) / [50, 50] + [37.76, -122.4],\r\n columns=[\'lat\', \'lon\'])\r\nst.pydeck_chart(pdk.Deck(\r\n map_provider="carto",\r\n map_style=\'road\',\r\n initial_view_state=pdk.ViewState(\r\n latitude=37.76,\r\n longitude=-122.4,\r\n zoom=11,\r\n pitch=50,\r\n ),\r\n layers=[\r\n pdk.Layer(\r\n \'HexagonLayer\',\r\n data=df,\r\n get_position=\'[lon, lat]\',\r\n radius=200,\r\n elevation_scale=4,\r\n elevation_range=[0, 1000],\r\n pickable=True,\r\n extruded=True,\r\n ),\r\n pdk.Layer(\r\n \'ScatterplotLayer\',\r\n data=df,\r\n get_position=\'[lon, lat]\',\r\n get_color=\'[200, 30, 0, 160]\',\r\n get_radius=200,\r\n ),\r\n ],\r\n ))'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fd1433af610>)])]>

pydeck_plot を使用したプロット（出典）

pydeck がサポートしている地図プラットフォームはいくつかありますが、ここでは CARTO を使用します。CARTO と deck.gl を使用した例の詳細については、こちらのブログ記事をご覧ください。

Step 4: モビリティデータをプロットする

完成まであと残りわずかです。このステップでは車両の位置をプロットします。pydeck でデータをプロットする方法はいくつかありますが、モビリティデータをプロットする場合には TripsLayer が適しているでしょう。

Google Maps JavaScript API を使用したデモ（出典）

TripsLayer を使用すると、位置情報を時系列で可視化できます。つまり、特定のタイムスタンプを選択すると、直近の期間 n を含む時間内の位置情報をもとに線が描かれます。時間を順に変更することで、データをアニメーションとして表示させることもできます。

最終形態では、IconLayer も追加して最新の位置を特定します。このレイヤは静的な位置をプロットする必要がある場合にも役に立ちます。Google マップの「ピン」のように機能してくれます。

では、このプロットを Firestore とどのように併用するかを説明します。車両ごとにドキュメントを作成し、各車両の最新の緯度、経度、タイムスタンプのみを保存しましょう。なお、位置情報の履歴まで保存する場合は、BigQuery を使用する必要があります。今回はリアルタイムで更新される最新の位置さえわかれば良いので、履歴は保存しません。

Firestore はスケーラブルかつ有用なデータベースですが、NoSQL です。NoSQL には向き不向きがありますので注意してください。

Firestore コンソール内の位置情報

ステップ 5: 実行する

ついに最終ステップまで到達しました。できることなら実際に車に乗り込んでデータを記録したいところです。

今回はデモ用のダミーデータを Firestore に取り込みます。クライアントライブラリを使用することで、簡単にデータを書き込むことができます。

code_block: <ListValue: [StructValue([('code', "db = firestore.Client()\r\ncol_ref = db.collection('connected')\r\ncol_ref.document(str(vehicle_ind)).set({\r\n 'lonlat': [-74, 40.72],\r\n 'timestamp': 0\r\n})"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fd1433af9a0>)])]>

ダミーデータを書き込み、Cloud Run でホストされているウェブページを開くと、新しいデータが届いて地図が更新されていることがわかります。

Firestore による streamlit 上でのデータ同期

ダミーデータを使用してタイムスタンプを操作したため、位置情報の更新が実際の時間よりもかなり速くなっていることにご注意ください。実際のデータと更新サイクルを使用することですぐに修正できます。

ご自身のデータでお試しください

この投稿では、Cloud Run と Firestore を活用して、リアルタイムで更新されるダッシュボードの構築方法について説明しました。この他にも、Google Cloud プロダクトを活用したユースケースが見つかりましたらぜひお知らせください。

その他の自動車業界向けソリューションはこちらからご確認ください。
まだ Google Cloud を使用していないお客様は、こちらからお試しください。
ソースコードは、GitHub で確認してください。

- 自動車業界担当カスタマーエンジニア Hayato Yoshikawa

SAP IBP と Google Cloud でサプライチェーンの混乱に対処する方法

Mon, 13 Jun 2022 01:00:00 +0000

※この投稿は米国時間 2022 年 6 月 7 日に、Google Cloud blog に投稿されたものの抄訳です。

ほとんどの需要計画担当者にとって、同時に複数の混乱に対処することが日課になっているのではないでしょうか。需要予測を効果的に行うためには、それぞれに異なり、時に競合する以下のような要素を考慮しながら、予測不能な事態を予測する能力が必要です。

労働力や資材の不足
世界的な健康危機
海外の規制の変化
前例のない天候不順
サステナビリティへの取り組み強化
インフレの進行

イノベーターは、AI やデータ分析の高度な機能を組み込むことで需要予測の精度を向上させ、需要計画もスピードアップしたいと考えています。サプライチェーンの経営者数十人を対象に McKinsey が調査を実施したところ、90% が今後 5 年以内にプランニング用の IT の見直しを行う予定で、80% がプランニングに AI や機械学習を活用する予定、もしくはすでに活用していることがわかりました。

Google Cloud は SAP と提携して、このような課題やサプライチェーンの混乱にお客様が対処できるよう、上流の需要計画プロセスから支援し、統合されたエンジニアリングソリューションを通じて予測の精度とスピードを向上させることに重点的に取り組んでいます。この提携により、SAP IBP for Supply Chain と Google Cloud サービスを組み合わせて使用する需要計画担当者は、増え続けるサードパーティのコンテキストデータのリポジトリにアクセスして予測を行うだけでなく、ワークフローを合理化し予測精度を向上させる AI を活用した手法も利用できるようになります。では、これらの機能について詳しく見ていきましょう。

SAP ソフトウェアからのデータを Google 独自のデータシグナルで統合

需要の予測や計画を行う場合、高品質で関連性の高いコンテキストデータを多く使用するほど成果が向上します。これは、製品販売の影響要因を理解して傾向を把握し、混乱への対処や市場機会の活用をより適切なタイミングで正確に行えるようになるためです。

Google Cloud と SAP の提携拡大により、SAP® Integrated Business Planning for Supply Chain（SAP IBP for Supply Chain）を使用するお客様は、Google Cloud が提供する一般公開データセットや商用データセットを自社の SAP IBP のインスタンスに取り込み、SAP IBP の需要計画モデルで使用できるようになりました。そのため、需要計画担当者は、SAP IBP で通常扱う販売履歴、プロモーション、関係者の情報、顧客データに加え、Google Cloud から広告のパフォーマンス、オンライン検索、消費トレンド、地域の健康に関するデータなど多くのデータシグナルを取り入れて、需要シナリオに取り組むことができます。

より多くのデータによって、より確実で正確なプランニングが可能になるため、Google はデータプロバイダのエコシステムを構築し、Google Cloud で利用可能なデータセットの数を増やし続けています。現在のプロバイダの一部には、米国国勢調査局、米国海洋大気庁、Google Earth などが挙げられますが、企業がリスクを特定および軽減し、回復力のあるサプライチェーンを構築できるよう、Crux、Climate Engine、Craft、Dun & Bradstreet との提携も進めています。

より正確な予測を推進するための第一歩となるのが、追加の外部要因データによる需要計画の補強です。たとえば、地域で開催されるイベントや、商品の売上に影響を与える天候パターンを把握することで、十分な供給ができるようになり、それらの変化に迅速に対応できます。その結果、全体的な計画をより正確に立てることができ、リソースの浪費や在庫切れを削減できます。計画担当者は、拡張されたデータに基づいて、販売、価格、調達、生産、在庫、物流、マーケティング、広告などに関し、より正確できめ細かい日々の予測を使って対応できます。

Google AI でより正確な予測を取得

SAP IBP で利用できる広範なアルゴリズムをさらに拡張したバージョン 2205 のリリースを使用すると、SAP IBP のお客様は、予測プロセスの一環として、Vertex AI（Google Cloud の AI as a Platform サービス）上に構築された Google Cloud のサプライチェーン予測エンジンに SAP IBP 内からアクセスできるようになります。

需要予測に AI を活用したエンジンを使用することのメリットは、予測精度を大幅に向上できる点にあります。今日のほとんどの需要予測は、手作業で設定されたルールベースのモデルによって行われていますが、AI を活用したモデルはより高度で、作業に応じて需要予測の精度を上げていきます。

合理化されたワークフローにより、最短経路でデータから価値を創出

Vertex AI は、需要計画のために関連するコンテキストデータセットを含めることができ、さらにその結果を SAP IBP で表示して、計画担当者がワークフローを構築する際に取り入れることができます。

より正確な予測に加え、計画担当者は潜在的なシナリオを構築する際に、より迅速かつ効率的に作業できます。これはつまり、現在よりも多くのシミュレーションを行い、幅広い混乱をモデル化できることを意味します。SAP IBP のお客様は、手間のかかる作業を行う必要はありません。SAP IBP のデータを Google と共有し、プロセスワークフロー機能を使用して、組み合わせたデータを使用する自動化ワークフローを設定するだけで済みます。Google がデータを利用可能にするため、計画担当者は Vertex AI でワークフローを設定する際にそのデータを利用できます。

Google Supply Chain Twin と SAP IBP のユーザーは、IBP の豊富なプランニングデータを SAP の追加データや他の Google データソースと組み合わせて、サプライチェーンの可視性を向上させることができます。Google Supply Chain Twin は、販売履歴、お客様のオープン注文、過去や今後のプロモーション、価格や競合他社に関するインサイト、消費者履歴シグナル、外部データシグナル、Google データに基づいて、お客様のサプライチェーンをリアルタイムでデジタル表示します。

SAP IBP で Google データシグナルを活用し、より正確な予測を実現

これらの新機能の使用は難しいものではありません。また、より正確な短期的予測を行うことができ、SAP IBP と Google Cloud への投資からより多くの利益を得ることができます。6 月 6～8 日にフロリダ州オーランドで開催される Gartner Supply Chain Symposium に参加される場合は、ぜひ Google のブースにお立ち寄りください。または、今すぐ SAP IBP をご活用ください。

- SAP 戦略およびアーキテクチャ担当パートナーマネージャー Dinesh Vandayar

もう「ノーマル」はない？データと AI を活用したサプライチェーンの構築で備えは万全

Fri, 10 Jun 2022 02:00:00 +0000

※この投稿は米国時間 2022 年 6 月 1 日に、Google Cloud blog に投稿されたものの抄訳です。

この 2 年間の激変やイノベーションを経て、私たちが向かっているのがニューノーマルな時代ではなく、もはやノーマルが存在しない時代だとしたらどうでしょう？

Google Cloud のサプライチェーン兼物流担当マネージングディレクター Hans Thalbauer は、最近の Supply Chain & Logistics Spotlight で「サプライチェーンのプロフェッショナルは日々解決しなければならない非常に大きな課題をいくつも抱えている」と指摘しました。こうした課題の例として、Thalbauer はパンデミックによる変化、消費者需要、労働力不足、気候危機、地政学的不安定、エネルギー不足などを取り上げています。

Thielbauer は次のように投げかけます。「重要なのは、これが単に短期的な問題ではなく、長期的でシステム的な問題だと Google が考えていることです。そこには大きな疑問点があります。世界の貿易はどう変わっていくのでしょうか？本当に何か新しいものに変わっているのでしょうか？世界の貿易はこれまでどおりに機能するのでしょうか？」

まさに今、ホワイトハウスの専門家でさえ同じ疑問を抱いています。Supply Chain & Logistics Spotlight と日を同じくして、大統領経済諮問委員会の年次報告書が発表されましたが、そこでは一つの章すべてがサプライチェーンに割かれていました。その章では、かつて曖昧かつ観念的で目に見えなかったサプライチェーンが「食卓の会話に登場した」と記述されています。それには十分な理由があります。「アウトソーシングやオフショアリング、レジリエンスへの不十分な投資のせいで、多くのサプライチェーンは複雑で脆弱になっている」と、経済学者たちは説明します。また、ロジスティクスの未来を懸念しているのは同委員会だけではありません。

グローバル化かローカル化か、自動化が進むか仲介業者が排除されるか、アジャイルになるか脆弱になるかなど、ロジスティクスの未来がどのような結果になるにしても、最も可能性が高いのは、テクノロジーへの依存が高まるということです。特に、あらゆる混乱や中断に対処できるデータへの依存が進む可能性があります。

The Home Depot、Paack、Seara Foods などのこの分野のリーダーは、エンドツーエンドでのデータ接続、情報へのアクセスと共有のためのプラットフォームの機能、問題が発生したとき、あるいは発生する前に問題を軽減する予測分析の重要性など、いくつかの主要分野で機会を見い出しています。

「可視性、柔軟性、革新性を生み出すことが必要です。企業は往々にして、自社の注文、予測、在庫にばかり目を向け、それ以外の部分を目に入れようとしません。私たちは、公的情報、交通、天候、気候、金融リスクなどを取り込み、それを企業データと結び付ける必要があります。コミュニティデータを活用して、全階層のビジネスパートナーとのコラボレーションを実現する必要があるのです」と Thalbauer は話します。

エンドツーエンドのデータ

企業はこれまで、工場から倉庫、店舗、そして今では玄関先まで、それぞれの間に存在するすべてのポイントの可視化を模索してきました。データ量が増え、それに伴って機能も増加し、すべてのポイントを見通す難しさも、必要性も増しています。それが今の状況を複雑にしているのです。これは人間では管理できない規模なので、データだけでなく、分析や AI の重要性が一層高まっています。

The Home Depot は、このような相互依存性の増大、特に競合しつつも補完関係にある顧客層へのサービスの提供に、いち早く対応してきました。

パンデミックでは、思いがけない機会も到来しました。住宅価格の高騰、可処分所得の増加、DIY 愛好家による（自宅待機中の）自宅での作業などが相まって、木材、小屋を改装したオフィス、ガレージドアまで、あらゆるものが売れ続けました。商品棚を空にしてしまうと、顧客の怒りを買うことになります。

The Home Depot の IT サプライチェーン担当バイスプレジデント Chris Smith 氏は、この状況下で、同社が相手にしていたのは住宅所有者や大家だけではなく、請負業者や大規模デベロッパーもますます重要な存在になっていた、と説明します。いずれもが、異なる商品を、異なる規模かつ異なる方法で買い付けたいと要求し、この要求はパンデミックの間、拡大する一方でした。

グローバル化かローカル化か、自動化が進むか仲介業者が排除されるか、アジャイルになるか脆弱になるかなど、ロジスティクスの未来がどのような結果になるにしても、最も可能性が高いのは、テクノロジーへの依存が高まるということです

「当社には、まさにオムニチャネルアルゴリズムと呼んでいるものがあります」と話すのは The Home Depot の IT サプライチェーン担当バイスプレジデント、Chris Smith 氏です。「このアルゴリズムは、お客様の好みを、当社が把握する生産能力、品揃え、在庫の可用性と結び付けます。それらすべてをまとめ、どうすればお客様の期待に応え、サプライチェーンを最も効率的に活用できるのかを考えます。そうすることで、どこから処理するのか、どこに在庫があるのか、お客様との約束を守りつつ、当社にとって最も経済的な方法でそれを行うにはどうすれば良いかがわかります」。

Paack は、英国、スペイン、フランス、ポルトガル、イタリアでラストワンマイルの配達サービスを提供するスタートアップ企業で、同様にフルフィルメントの既存の枠を超えようとしています。同社はドライバー、お客様、センサー、天候などの豊富なデータを組み合わせ、確実な配達を実現することに重点を置いています。これまでのところ、特別なスケジュール管理ツールを使用して顧客が荷物を確実に受け取れるようにすることで、その成功率は 98% に近づいています。

Paack は、Google Maps Platform のラストワンマイルフリートソリューションを使用して、ドライバーと顧客をリアルタイムで管理しています。

Paack チーフプロダクト兼テクノロジーオフィサーの Olivier Colinet 氏は次のように話します。「ドライバーのルートと計画されたルートのどちらがより効果的か、地元にもっと良いルートがあったらドライバーは経路を変えることができるか、お客様から在宅状況を通知してもらえるかなど、収集できる情報の精度が高く、すべての人にとって優れたエクスペリエンスを構築することが可能になりました。当社では新米ドライバーにも生産性の高いドライバーになってもらいたいと考えていますが、情報の精度という最初のステップがこれを可能にしてくれます」。

プラットフォームの力

Paack の成功は、顧客と従業員のための優れたプラットフォームを構築すること、Google マップのような既存のプラットフォームを利用して自社のプラットフォームを強化することの素晴らしさを示しています。

地球の反対側では、世界最大の食肉供給会社が、自分たちのプラットフォームを提供することで何千人もの牧場主や農家を支援しようとしています。Seara はブラジルを拠点とする豚肉、鶏肉、卵のサプライヤーで、世界に事業を展開する JBS コングロマリット傘下にあります。同社は 2021 年 7 月、SuperAgroTech プラットフォームを立ち上げました。

このプログラムは何年も前から開発されていたものの、世界の食糧供給にこれ以上ないほど重要なタイミングでリリースされることとなりました。このとき食品業界は、すでにパンデミックによる供給不足と操業停止に対処中でしたが、そこにウクライナでの戦争の影響までもが及んでいる状況でした。

Seara のイノベーション兼戦略担当ディレクター Thiago Acconcia 氏は次のように説明します。「全般的に、サプライチェーン全体が影響を受け、事業は新しい労働条件に適応しなければなりませんでした。農場や現場でも状況は同じでした。このデジタルオンラインプラットフォームの構築は、農場に自律性を与えます。データ入力とデジタル通信の手段を提供することで世話役としての役割を果たすのです」。つまり、農家と Seara との間に、これまでにはないつながりが生まれたのです。

この技術は、リリース時点で 9,000 以上の農場に導入されました。さまざまな IoT センサー、モニタリングデバイス、農家、オペレーター、Seara によるデータ入力を通じて、チームは多くの結果を追跡しています。これには収穫量、家畜の健康、利益、さらには消費者にとってますます重要な要素となってきている環境や社会的影響などが含まれます。

最終的な目標は、農場のデジタル管理の割合を 100% にすることです。

「現在では、どこでも、どんな生産者でも数秒で有効化できます」と Acconcia 氏は言います。SuperAgroTech を使用することで、プラットフォームは「国の最南端にあっても中心部にあっても構いません。生産者との関係を強化し、また、これまでにないレベルで各生産者に合わせた対応を実現します」。

このようなプラットフォームでは、これまで提供されることのなかったレベルの可視性と接続性を利用できるようになり、データを収集、分析して、分析情報をプラットフォーム上で再び実行に移すという好循環が生み出されます。予測不可能な世界では、このような統合が不可欠になりつつあります。

積み上げられたコンテナ

予測分析

統合されたデータと堅牢なプラットフォームによって企業のデジタル戦略が進化する現在、絶好の機会の一つとなるのが予測分析とその周辺です。

未来を見通すというのは（少なくとも今のところは）SF の世界だけの話ですが、AI、クラウド、さらには量子コンピューティングによって、トレンドの解明、接続の確立、機会と損失の両方の予測を行うための堅牢な方法が提供されつつあります。

The Home Depot は、消費者データと AI を使用してデジタルストアを迅速に適応させ、エクスペリエンスを改善するとともに、サプライチェーンの問題を円滑化する方法を検討してきました。同社の Chris Smith 氏は、たとえば、在庫のない家電や工具を提示すると、すぐに他の場所や販売商品を提示してくれるといった便利な代替手段を挙げています。

「機械学習をさまざまな方法で適用することで、サプライチェーンにおける在庫の移動のサポートや、お客様をサポートするための生産能力の把握など、より良い、迅速な意思決定を行うことができます。自動化に関しては、配送センターから予測システムや補充システム全体で、今後も最適な判断を下すために最適化、自動化できるところはないか、引き続き探していきます」と Smith 氏。

Paack の場合、予測は交通量や嵐、さらにはリピーターがいるかどうかの可能性という形で、自ずと明らかになるでしょう。

Seara の場合は、データと分析の役割は、ビジネスだけでなく、世界の持続そのものに不可欠です。気候、サプライチェーン、世界的な紛争、移民などの問題が食糧供給を制約し続けるなか、問題を予測することが作物を救えるかどうかの分かれ道となる可能性があります。

Acconcia 氏は次のように話します。「私たちは、リアルタイムの問題を通知するだけでなく、近い将来と遠い将来に何が起こるかを予測することも目的として、AI ツールによる高度な分析の作成を開始しました。私たちは世界中の食糧を扱います。SuperAgroTech は、世界に食糧を供給し、これらの最大の課題を克服する役割を担っているのです」。

- 業界編集者 Matt A.V. Chaban