コンサルティング
Google Cloud
システム開発
データ分析
セキュリティ
生成AI
Google Cloud認定トレーニング
こんにちは。クラウドエースの田中です。 分析基盤にデータは蓄積できているものの、ダッシュボードの表示が遅い。ログ検索に時間がかかる。顧客向け分析画面のフィルタを変更するたびに待たされる。 データ量やクエリ数が増えると、こうした応答速度の問題が表面化します。特にマーケティング分析、オブザーバビリティ、顧客向けダッシュボード、AIアプリケーションでは、大量のログやイベントを継続的に処理しながら、必要な情報をすぐに返す性能が求められます。 そこで選択肢となるのが、オープンソースのカラム型OLAPデータベース「ClickHouse」です。 本記事では、ClickHouseの特徴と高速に分析できる仕組み、代表的なユースケース、既存のDWHとの使い分け、導入時の注意点を解説します。 [toc] ClickHouseとは ClickHouseとは、大量データに対する分析クエリを高速に処理するために設計された、オープンソースのカラム型OLAPデータベースです。 特に、Webの行動イベントやアプリケーションログ、インフラログ、IoTデータなど、継続的に追加される大量データの集計・検索を得意としています。 SQLでクエリできるため、既存の分析ツールやBIツールと組み合わせることもできます。 参考:AIのためのデータプラットフォーム - ClickHouse カラム型ストレージで必要なデータだけを読み出す 一般的な業務システムでは、1件の注文や1人の顧客情報など、行単位でデータを読み書きする処理が中心です。 一方、分析では「直近30日間のクリック数を媒体別に集計する」といったように、大量の行から一部の列を読み出す処理が多くなります。 ClickHouseはデータを列単位で保持するカラム型ストレージを採用しています。クエリに必要な列だけを読み出せるため、大量データを対象とする集計処理で読み取り量を抑えられます。 ログ・イベント・時系列データに向いている ClickHouseの代表的な対象は、継続的に追加される次のようなデータです。 Web行動イベント 広告クリック、インプレッション、コンバージョン アプリケーションログ セキュリティログ インフラログ トレースデータ IoT・センサーデータ AIアプリケーションの実行ログ これらはデータ量が増えやすく、「特定期間のデータを絞り込む」「属性別に集計する」といった処理が繰り返されます。ClickHouseはこうしたクエリを高速に処理する用途で使われています。 ClickHouseが大量データを高速に分析できる仕組み ClickHouseの性能を支えているのは、カラム型ストレージだけではありません。 MergeTree系のテーブルエンジン、ORDER BYによるデータの並び順、データ圧縮、Materialized Viewなどを組み合わせ、クエリ時に読み込むデータ量と計算量を抑えています。 MergeTreeとORDER BYで読み取り範囲を絞る ClickHouseで広く使われるMergeTree系のテーブルエンジンでは、ORDER BYに指定したキーに沿ってデータがディスク上に並びます。 たとえば顧客向け分析サービスで、 「tenant_id = A、直近7日間」 という条件を頻繁に使うのであれば、tenant_idや日時を考慮してORDER BYを設計します。検索条件とデータの並び方が合っていれば、クエリ時に確認するデータ範囲を減らせます。 参考:MergeTree テーブルエンジン Materialized Viewで繰り返し計算を減らす ダッシュボードでは、同じ指標が何度も参照されます。 たとえば、 時間帯別のアクセス数 媒体別の広告効果 ステータスコード別のエラー率 顧客別の利用量 といった指標です。 毎回すべての生データから計算する代わりに、Materialized Viewなどを使って集計結果を保持すれば、ダッシュボード表示時の計算量を減らせます。 参考:materialized view を利用する 圧縮とTTLで大量データを管理する ログやイベントはデータ量が大きくなるため、分析性能だけでなく保存方法も課題になります。 ClickHouseでは、カラム型ストレージによる圧縮に加えて有効期限(TTL)を設定できます。 たとえば、 「詳細ログは30日間保存し、それ以前は削除する」 「古いデータは別のストレージへ移動する」 といったライフサイクルをデータに設定できます。 参考:有効期限 (TTL)でデータを管理する テーブル設計は性能を左右する ClickHouseの性能は、ORDER BYなどのテーブル設計と実際のクエリによって変わります。 たとえば、ORDER BYと検索条件が合っていない場合や、長期間のデータを毎回読み込む場合は、読み取り量が増えます。 導入時には、頻繁に実行するクエリをもとにORDER BYや集計方法を設計します。 DWHとClickHouseをどう使い分けるか ClickHouseはBigQuery、Snowflake、Databricks、Amazon Redshiftなどと比較されることがあります。ClickHouse自体をDWHとして利用することもできます。一方で、既存のDWHをすべてClickHouseへ置き換える必要はありません。 同じ分析用途でも、求められる応答時間や同時実行数によって適した構成は変わります。全社データの統合や部門横断分析をBigQueryなどのDWHで行いながら、低レイテンシや高頻度アクセスが求められる処理をClickHouseに担当させる構成もあります。 たとえば、Google Cloudを中心とした構成では、次のように役割を分けられますどちらを使うかは、製品カテゴリではなく、データ量やクエリ特性、同時実行数、求める応答時間などから判断します。 観点 DWH中心で処理しやすい領域 ClickHouseを組み合わせやすい領域 主な要件 データ統合、ガバナンス、部門横断分析 低レイテンシ、高頻度アクセス、高い同時実行性 代表的な利用 経営分析、標準BI、アドホック分析 顧客向け分析、ログ検索、オブザーバビリティ、分析API クエリ特性 複雑な横断分析や探索的なSQL 大量データを対象とした高速な集計・絞り込み 応答速度 秒〜数十秒でも成立する分析 サブ秒〜数秒など短い応答時間が重要な処理 利用者 社内アナリスト・BIユーザー中心 エンドユーザーやアプリケーションからの高頻度アクセス これは製品の明確な境界ではありません。ClickHouseをDWHとして利用することも、BigQueryなどを顧客向け分析に利用することもできます。重要なのは製品カテゴリで分けるのではなく、実際のワークロードに応じて使い分けることです。 ClickHouseの主な活用例 ClickHouseの特徴が活きる代表的なユースケースを見ていきます。 マーケティング分析 広告クリック、インプレッション、Web行動イベント、購買データなどを継続的に取り込み、媒体別やキャンペーン別に集計できます。 たとえば、 媒体別の広告効果 キャンペーン別のクリック率・コンバージョン率 LP別の流入・離脱 時間帯別のアクセス状況 顧客向けレポート などです。 当日のデータを見ながら施策を調整する運用では、データ量だけでなく、集計結果が返るまでの時間も業務のスピードに影響します。 ログ解析・オブザーバビリティ アプリケーションログ、セキュリティログ、インフラログ、トレースなども代表的なユースケースです。 障害調査では、 エラー率の時系列変化 ステータスコード別の傾向 特定ユーザーやテナントのログ 障害発生前後のイベント などを大量のログから絞り込みます。 ClickHouseはこうしたオブザーバビリティデータの保存・分析エンジンとして利用できます。また、ClickHouseではオブザーバビリティ向けの「ClickStack」も提供されています。ClickStackはClickHouseを基盤として、ログ、メトリクス、トレースなどの観測データを扱うためのオープンソースのオブザーバビリティスタックです。 ClickHouseを既存の監視ツールと組み合わせる構成に加え、ClickStackを使ってオブザーバビリティ環境を構築する選択肢もあります。 ※ClickStackの提供機能や構成については、公式ドキュメントの最新情報をご確認ください。 顧客向け分析・埋め込み分析 SaaSやWebサービスの管理画面に分析機能を組み込む用途でもClickHouseが使われています。 たとえば、 SaaSの利用状況ダッシュボード 広告管理画面のキャンペーンレポート EC管理画面の売上推移 セキュリティサービスのイベント検索 などです。 こうした画面では、多数のユーザーが同時にアクセスし、日付やカテゴリ、ステータスなどのフィルタを何度も変更します。分析処理がそのままプロダクトのユーザー体験になるため、クエリの応答時間が重要な指標になります。 一方、顧客データを扱う場合は、tenant_idによるデータ分離だけでは不十分です。認可、クエリ制限、監査ログなども含めてアプリケーション全体で設計します。 AIログ分析・AIオブザーバビリティ 生成AIやAIエージェントでは、通常のアプリケーションログに加えて、次のようなデータが発生します。 プロンプト レスポンス 利用モデル トークン利用量 レイテンシ ツール呼び出し 評価スコア ユーザー別利用状況 これらを蓄積すると、モデル別のレイテンシ比較、トークンコストの分析、エラー調査、品質評価などに利用できます。 AIログにはプロンプトやレスポンスなど機密情報が含まれる場合もあるため、PIIマスキング、アクセス制御、保持期間、監査ログについてもあわせて検討します。 参考: Langfuseとは - ClickHouse Docs Langfuse Cloud、 日本で動きます。 ClickHouseを導入する際の注意点 ClickHouseには得意なワークロードがある一方、一般的なOLTPデータベースやDWHと同じ使い方をすると、その特徴を活かせない場合があります。 頻繁な行単位更新を行うシステムとは役割が異なる ClickHouseには更新・削除の仕組みがありますが、注文処理、在庫更新、決済処理など、1行ずつ頻繁にデータを書き換える業務処理を主用途とするデータベースではありません。 こうした処理にはOLTP向けデータベースを使い、分析対象となるイベントをClickHouseへ送る構成が基本となります。 繰り返し実行される集計は事前集計を検討する ダッシュボードや顧客向け画面では、同じような集計や絞り込みが繰り返し実行されます。 すべてのリクエストで生データから集計するのではなく、Materialized Viewや集計済みテーブルを使い、あらかじめ必要な単位で集計しておく方法があります。 実際に頻繁に実行されるクエリをもとに、事前集計する指標や粒度を決めます。 JOIN中心の分析ではデータモデルを検討する ClickHouseでもJOINは利用できます。 ただし、短い応答時間が求められるクエリで多数のテーブルを毎回JOINする場合は、非正規化やDictionary、Materialized View、集計済みテーブルなどを使い、クエリ時の処理を減らす設計も検討します。 認可やガバナンスはシステム全体で考える 顧客向け分析やAIログを扱う場合は、データベースの性能だけでは要件を満たせません。 テナント分離 認可 PIIマスキング 監査ログ データ保持期間 クエリ制限 などをアプリケーションや周辺サービスも含めて設計します。 自然言語BI・AIとClickHouse 自然言語BIでは、ユーザーの質問からAIがSQLを生成し、分析基盤に問い合わせて結果を返します。 たとえばユーザーが、 「先週と比べてコンバージョン率が下がったキャンペーンを教えて」 と質問すると、AIがSQLを生成し、分析基盤から結果を取得して回答します。 この仕組みでは、SQL生成だけが速くても十分ではありません。分析クエリの実行に数十秒かかれば、会話のテンポが崩れます。 大量データに対する集計を高速に処理できるClickHouseは、この実行部分を担う選択肢になります。 一方、AIにSQLを自由生成させると、必要以上に長い期間の検索や不要なJOIN、tenant条件の欠落などが発生する可能性があります。 そのため実運用では、 利用可能なテーブル・カラムの制限 セマンティックレイヤー SQL生成時のガードレール 最大検索期間 集計済みテーブルへの誘導 クエリ監視・制限 などを組み合わせます。 実装方法としては、LibreChatのような対話型UIからMCPを介してClickHouseへ接続する構成や、エージェントによる分析フローなども考えられます。 参考: リアルタイムデータ上のAIのためのオープンプラットフォーム - ClickHouse LibreChatでClickHouse MCPサーバーを使用する 導入前にPoCで確認すべき項目 ClickHouseの性能は、データ構造や実際に発行されるクエリによって変わります。 そのため、製品ベンチマークの数値だけではなく、自社のデータと代表的なクエリを使ったPoCで判断します。 確認項目の例は次のとおりです。 代表的なクエリのp50、p95、p99レイテンシ 複数ユーザーによる同時実行時の性能 データ取り込みから検索可能になるまでの時間 tenant・期間など主要な検索条件での性能 JOINを含むクエリの性能 Materialized View導入前後の性能差 データ保持期間ごとのストレージ使用量・コスト 既存DWHとのデータ連携方法 権限制御・監査ログ・クエリ制限 監視・バックアップ・障害対応 単純に「ClickHouseは速いか」を測るのではなく、実際のデータ量、クエリ、同時実行数を再現し、求める応答時間を満たせるかを確認することがPoCの目的です。 まとめ ClickHouseは、大量のログやイベントに対する集計・検索を高速に処理するカラム型OLAPデータベースです。既存DWHを一律に置き換えるのではなく、顧客向け画面やログ検索など、応答速度が求められる処理を担わせる構成も考えられます。 導入を検討する場合は、高速化したいクエリ、データ量、同時実行数、目標とする応答時間を整理し、実データを使ったPoCで性能とコストを確認します。 クラウドエースでは、Google CloudやBigQueryを活用したデータ基盤の構築に加え、ClickHouseを組み合わせた分析基盤の設計・導入も支援しています。 ClickHouseの導入・運用支援をクラウドエースが支援します 大量のデータを高速分析できるClickHouseの導入や活用なら、クラウドエースにご相談ください。要件整理から検証、構築、運用定着まで一気通貫で支援します。 ClickHouse導入・運用支援について詳しく見る ClickHouseについて相談する 田中 悠路
2026.09.09
こんにちは、クラウドエースのマーケティング部の石島です。 クラウドエースではエンジニア部門に限らず、各部門でAIを活用した業務改善や開発に取り組んでいます。今回ご紹介するのは、私が所属するマーケティング部で進めたSFAツールの開発です。 本記事ではその実践をもとに、非エンジニアである私がAI駆動開発をどのように進めたのかをご紹介します。 [toc] なぜアプリを作る必要があったのか アプリづくりの出発点は、マーケティングの観点から見たい数字を、すぐに確認できないという課題でした。 社内にはSFAツールが導入されていますが、中心となっているのは営業視点の情報です。マーケティングとして把握したい数字とは切り口が異なるため、必要な情報を確認するには、複数の管理基盤を手動で見比べて拾い上げる必要がありました。 その作業には毎回30〜40分ほどかかり、確認できる人も限られていました。そのため、必要な数字をすぐに確認できないだけでなく、情報の把握が特定のメンバーに依存し、チームで状況を共有しづらい状態になっていたのです。 データそのものは存在していても、必要なときにすぐ確認できなければ、現場では十分に活用できません。そこで、まずは私たちが必要な数字をすぐ確認できるシンプルなSFAツールを自分たちで作ってみることに。 GAS ✖️ Google AI Studioで進めるAI駆動開発 今回使用したのは、Google AI StudioとGASです。 Google AI Studioは、Googleの生成AIモデルを使い、自然言語で画面や動きのたたき台を素早く形にできるツールです。今回は主にUIのプロトタイピングに活用しました。 一方、GASはGoogle Workspaceと連携した業務アプリを開発でき、Webアプリとしてそのまま公開できます。 この2つを選んだ理由は、非エンジニアでも開発から公開まで進めやすいという特徴があったからです。Google AI Studioは追加の環境構築なしで試すことができ、GASも普段使っているGoogle Workspaceの環境から利用できます。Google Cloudの権限管理の範囲で動くため、社内展開しやすい点も今回の用途に合っていました。 こうした環境によって、「まず形にして、触りながら考える」という進め方がしやすくなりました。 もちろん、AI駆動開発はAIにすべてを任せることではありません。では、実際にAIをどのように活用し、どこを人が判断したのか。ここから具体的な開発の流れを振り返ります。 ▼合わせて読みたい AI駆動開発とは?メリット・注意点・クラウドエース流の実践5ステップなど徹底解説 AI駆動開発の実際の流れ 実際にどのように開発を進めたのかをご紹介します。UIのたたき台づくり、実装時の構成、AIと人の役割分担の3つに分けて振り返ります。 自然言語でUIのたたき台を作成 上記画像は、Google AI Studioで作成したUIのたたき台です。 自然言語で「こういう画面が欲しい」「こういう動きにしたい」と伝え、生成された画面を実際に触りながら修正していく進め方です。ゼロからコードを書くのではなく、頭の中にある「欲しいもの」を言語化し、画面の構成や必要な要素を詰めていきました。 小規模チーム向けの構成で実装 データはBigQueryとスプレッドシートを組み合わせて扱い、GASでWebアプリとして展開しました。 以下の画像は実際に開発したSFAツールのサマリー画面です。まず全体像をつかめるようにし、必要な確認にすぐ入れる構成にしました。 最初から大規模なシステムを目指すのではなく、現在のチーム規模で運用でき、必要に応じて自分たちで直せる構成を選びました。 AIが進めたことと、人が判断したこと 実際に開発を進める中で、AIが得意なことと、人が判断すべきことが、あらためて見えてきました。 観点 AIの役割 人の役割 画面づくり たたき台を素早く出し、修正を繰り返す 何を見せると現場が使いやすいかを決める 機能の具体化 曖昧な要望を動く形へ寄せる 本当に必要な機能かを見極める データの扱い 扱いやすい構成の検討を助ける どの数字を採用するか、定義を揃える 運用の現実性 改善案を出す チーム規模や運用負荷に合うかを判断する AIによって「作って試す」までの距離は大きく縮まりました。一方で、その結果を見て何を採用するか、現場で使えるものになっているかを判断するのは人の役割であることを体感しました。 AI駆動開発で速くなったこと、速くならなかったこと 実際に取り組んでみると、AIによって大きく速くなった工程がある一方で、従来と同じように時間をかける必要がある工程もありました。 UIは速く形になった AIによって、「どの情報をどう見せるか」という方向性を早い段階で判断できました。 従来であれば、要件をある程度固めてから開発に渡す流れが一般的だったと思います。しかし、画面は実際に触ってみないとわからないことも少なくありません。 今回は先に触れるものを作れたことで、「この情報はいらない」「ここはもっと目立たせたい」といった判断がしやすくなりました。 画面の完成度は後から上げられますが、方向性がずれたまま作り込むと手戻りは大きくなります。完成品を想像しながら議論するのではなく、たたき台を見ながら判断できたため、方向性がずれることなく、UI開発のスピード向上につながりました。 時間がかかったのはデータ整理と要件定義だった 一方、他の業務と並行しながら進めたこともあり、ツール全体が形になるまでには約1か月かかりました。 特に時間を使ったのは、既存の社内データの見方を揃え、必要な項目を洗い出し、どの数字をどう扱うかを確認する工程です。 たとえば「先月のご支援開始件数」のような一見単純な数字であっても、期間の切り方や参照元がそろっていなければ、現場で使える指標にはなりません。 AIは実装を助けてくれますが、「何を、どの粒度で、どのデータを見て測るのか」という業務上の定義まで自動的に決めてくれるわけではありません。 今回の開発では、むしろこの工程に時間を使いました。作るスピードが上がったからこそ、その前提となるデータや要件を整理する重要性がよりはっきり見えたとも感じています。 このAI駆動開発の事例から見えたこと 部内専用のSFAツールを開発したことで、これまで毎回30〜40分かかっていた確認作業は約5分程度まで短くなり、特定のメンバーに聞かなくても状況を把握できるようになりました。 また、今回の取り組みを通じてAI駆動開発の価値も強く体感しました。 個人的に大きかったのが、「自分でも作れる」という感覚が生まれたことです。 一度、自分の課題を自分で形にする経験ができると、次の改善や別のツールを作ることへのハードルも下がります。実際、今回作ったツールも完成して終わりではなく、いまも少しずつ機能を足しながら育てています。 今回の実践から見えたポイントは、次の3つです。 現場の課題を素早く形にし、試行錯誤の速度を高められること 要件定義やデータの意味づけ、最終的な判断は人が担う必要があること 最初から大きく作り込まず、現場に合った規模から始めることで改善を続けやすくなること 今回ご紹介したのは、クラウドエースにおけるAI駆動開発の一例です。 こうした取り組みはエンジニア部門だけのものではありません。部門ごとに扱う業務や課題は異なっていても、現場の課題を起点にAIを使ってまず形にしてみるというアプローチは、さまざまな業務で応用できるはずです。 本記事が、現場でAI駆動開発に取り組もうとする方にとって、最初の一歩を考えるきっかけになれば幸いです。
2026.08.28
2026年7月30日、31日の2日間にわたり、東京ビッグサイトでGoogle Cloud Next Tokyo '26が開催されました。イベント全体を通して非常に多くの方にご来場いただきました。昨年の熱気を凌ぐほどの盛況であり、多くの企業がGoogleのテクノロジーを活用して成果を上げるなか、その実践知をキャッチアップしようとする輪が広がり、強固なエコシステムが確立されてきたことがうかがえます。 Google Cloudや生成AI、AIエージェント、Google Workspaceなどの最新動向が集まるこのイベントに、クラウドエース株式会社はスポンサー区分の最上位にあたるダイヤモンドスポンサーとして協賛しました。本記事ではGoogle Cloud Next Tokyo '26全体の概要に触れつつ、クラウドエースが会場でどのような発信を行ったのかをお伝えします。 AIをキーにしたメッセージで来場者を迎える会場前の巨大看板 Google Cloud Next Tokyo '26で発表されたこと Google Cloud Next Tokyo '26では、Gemini EnterpriseやGemini Enterprise Agent Platform、AI Threat DefenseといったAI・Google Cloud領域の発表にくわえ、Google Workspace、Workspace Intelligence、Sheets canvas、Google Meetなど、生産性向上にダイレクトにつながるアップデートも数多く紹介されました。 発表内容の詳細については以下の速報記事で詳しくご紹介していますので、気になる方はぜひご覧ください。 AI・Google Cloud関連 【速報まとめ】Google Cloud Next Tokyo ’26基調講演Day 1|クラウドエース株式会社 【速報まとめ】Google Cloud Next Tokyo ’26基調講演Day 2|クラウドエース株式会社 Google Workspace関連 【速報】Google Cloud Next Tokyo ’26基調講演まとめDay 1|吉積情報株式会社 【速報】Google Cloud Next Tokyo ’26基調講演まとめDay 2|吉積情報株式会社 クラウドエースのブースについて クラウドエースはAIの活用を個人の業務から組織全体の変革へと広げるため、「AI駆動開発」「AXコンサルティング」という2つの切り口から、組織変革に活用できるソリューションや考え方、自社での取り組みをブースにてご紹介しました。 AI駆動開発の領域では、私たち自身がAIによる変革を体現した脱SaaS・CRM置き換えの社内事例や、GAS × AI Studioを活用した業務アプリ開発、バイブコーディング体験、Floyo AI、ClickHouseなどを通じて、AIを活用した開発の進め方や実装イメージをご紹介しました。 AXコンサルティングの領域ではAX指数診断をはじめ、AIを個人利用で終わらせず、組織の業務や意思決定の中にどう組み込んでいくかを解説しました。 クラウドエースのブース。ミニセミナー、デモンストレーション、1to1の会話が同時に可能なデザイン 48本のミニセミナーを実施 ブースでは各日11:30から17:30までの時間帯に、1セッション約10分のミニセミナーを実施しました。2日間で実施したセッション数は計48本! 来場者の皆さまが関心のあるソリューションやプロダクトの概要を短時間で把握できる内容としました。 ミニセミナーの内容は以下の通りです。 Glean:社内情報を探すから、仕事を進めるへ。Gleanではじめる全社Work AI Gemini Enterprise:社内データをつなぎ、AIエージェントで業務を動かす Wiz:アラートの山で終わらない。Wizで始める“対処できる”クラウドセキュリティ AISec:AI時代のセキュリティ――止めるためではなく、業務に入れるための統制設計 ClickHouse:AIエージェント時代のリーディングデータベースの活用法 AI駆動開発:クラウドエース流AI駆動開発の実践 Floyo:プロンプトから、制作フローへ。Floyoが変えるAIクリエイティブの現場 Lightning:SFAは「借りる」から「作る」へ。〜AI駆動開発で営業基盤を内製するという選択〜 GAS × AI Studio:非エンジニアが業務ツールを作成した実践例 Antigravity:Antigravity 2.0の構成とエンタープライズ対応 AXコンサルティング:「私だけのAI」から「会社を動かすAI」へ 各ミニセミナーで使用していた資料はこちらからダウンロードできます。 Google Cloud Next Tokyo 26 クラウドエース ミニセミナー資料まとめ GleanやGemini Enterprise、Wiz、ClickHouse、Floyo、Antigravity 2.0といったプロダクトをはじめ、AI時代のセキュリティ論、AI駆動開発の実践、クラウドエースがAI駆動開発で内製したSFAツールLightning、非エンジニアによる業務ツール開発事例、そしてAIを組織に定着させるためのAXコンサルティングまで、幅広い内容を取り上げました。 ミニセミナーでは、エンジニアやコンサルタントなどそれぞれの領域で実務を担うメンバーが登壇しました おかげさまでミニセミナーは盛況で、たくさんの方にご聴講いただきました スポンサーセッションにAXコンサルタントの杉山が登壇 7月31日には、クラウドエースのAXコンサルタントである杉山がスポンサーセッションに登壇しました。セッションタイトルは「【超実践】AIエージェントが個人利用止まりの“症状”に効くAXの処方箋」です。 盛況だったスポンサーセッションの登壇資料。AI活用を個人レベルから組織レベル(AX)へと引き上げるための具体的な「処方箋」を提示しました このセッションでは、生成AIやAIエージェントの活用が個人利用で止まる状態を、 ・「何に使うか」が定まらないユースケースの壁 ・「誰が推進するか」が決まらない推進体制の壁 ・「どう定着させるか」が描けない定着の壁 という3つの課題に整理しました。 さらに、AIを既存業務に追加するのではなく、AIが担う工程を組み込んで業務プロセスを再設計する考え方や、成果を「業務時間の削減」「品質改善」「意思決定の速度」「業務への組み込み度」という4つの指標で測る方法について解説しました。 理想論だけではなく、現実的な進め方や評価の考え方まで踏み込んで紹介した点が、このセッションの大きな特徴です。おかげさまで事前申し込み枠は満員となり、当日は待機列ができるほどの盛況となりました。ご参加いただいた皆様、誠にありがとうございました。 本セッションの資料はこちらからダウンロードできます。 【超実践】AIエージェントが個人利用止まりの“症状”に効くAXの処方箋 スポンサーセッションにて、多数の企業AX支援を通じて得た実践的なノウハウや評価の考え方を解説するAXコンサルタントの杉山 パブリックセクター向けスペシャルセッションにも出展 会議棟で開催された「公共機関・ヘルスケア・教育向けスペシャルセッション」でも、ブースを出展しました。公共機関や自治体、医療・教育分野のIT推進担当者に向けて、Google Cloudの活用や、クラウドエースの支援内容についてお伝えしました。 また、クラウドエースの中川が日本大学の情報イノベーションセンター教学情報担当(CDO) 教学DX戦略委員会委員長の中村先生とともにライトニングトーク(LT)に登壇し、学生の異分野協働によるバイブコーディング・ハッカソンの取り組みをご紹介。教育現場における生成AI活用と実践的なクラウド人材育成について発信する機会となりました。 クラウドエースの中川が日本大学の中村先生と登壇したLT「異分野協働によるバイブコーディング・ハッカソン」のタイトルスライド 当日はたくさんの方にご参加いただきました Ask the Expertとラーニングブースでも交流 会場内のAsk the Expertとラーニングブースでは、Google CloudやAIに関する技術的な疑問、導入・活用方法、学習の進め方などについて、来場者の皆さんからのご相談に社員が対応しました。これからもクラウドエースは、Google Cloudのプロフェッショナルとして最新技術の活用を幅広くご支援していきます。 ブースに立つクラウドエースのスペシャリスト。こちらはエモーショナルカタリストのラリオス川口 ブースに立つクラウドエースのスペシャリスト。こちらはGoogle Cloud Partner Top Engineerを5年連続受賞した阿部 AI変革の最前線で、たくさんの方と未来のビジネスを描いた2日間 Google Cloud Next Tokyo '26では、Google CloudとAIの進化を体感できるだけでなく、来場者の皆さまと直接お話しできる貴重な機会にもなりました。クラウドエースとしても、ブース出展、ミニセミナー、スポンサーセッション、そしてAsk the Expertやラーニングブースでの交流を通じて、多面的にクラウドエースの価値をお伝えできた2日間だったと感じています。 クラウドエースは、Google Cloud黎明期から培った知見と経験をもとに、数多くのお客様のクラウド活用を支援してまいりました。現在も「Service」「Co-sell」両部門で最上位の「Diamondパートナー」に認定されています。私たちはこれからもGoogle Cloudとともに、お客様のビジネスの成長と変革に貢献し続けます。
2026.08.27
2026.08.31
2026.08.17
2026.07.31
2026.07.30
2026.06.23
2026.05.29
2026.05.28
2026.05.27
2026.05.22
2026.05.20
2026.04.30