Azure x AWS x Google Cloud コミュニティ本音トーク！の参加記録
Azure x AWS x Google Cloud コミュニティ本音トーク！に参加させていただいていました。講演者の方、運営の方ありがとうございました。普段はAWSしか触っていないので別のクラウドの話を聞けて面白かったです。
超10000行プロジェクトをバイブコーディングで立ち上げる方法
角田俊さん
バイブコーディングはまだまだエンジニア界隈でも使われていないそう。バイブコーディング否定派の意見としては修正が多く、結局自分で開発した方が早いとか、大規模開発だと技術的負債が溜まってしまうなど。
バイブコードでは次のことの対策が必要
ハルシネーション対策
- 修正方法だけ提案。修正はさせない。
- フォールバックを禁止する
- 会話履歴のこまめなリセット
- gitで戻せるようにしておく
指示の具体化
- 回答の範囲を狭める(具体的な回答をさせる)
- ライブラリやフレームワークを指定する
- 指示は機能ごとに作っていく
プロジェクト構造は抽象的にする
- ディレクトリ構成をAIに伝わるように整理
- 関数やクラスなどの抽象化
昔、Q Developerを使った時に指示の具体化や、gitによるチェックポイントの有効性は自分も感じていた。プロジェクト構成については考えてことがなかったのでvibe codingする際は実行してみたい。
「Kiroってどうなの？」リアルな使い勝手と最新の料金ガイド
ヤマダ（北野）さん
Kiroとは仕様駆動開発の新しいIDE。従来とはちがい、仕様を作るところから開発を行う。仕様書があるため、コミュニケーションコストの低減やレビュー品質をあげることができる。設計書を作って仕様駆動開発なのでエンジニアというよりはプロジェクトマネージャーに近いとのこと。
既存プロジェクトでもKiroにさせることができる。既存のものから仕様書を作成できる。Kiroがあることで容易にオンボーディングができるようになる。従来はメンバーのリソースを使いながらプロジェクトに入っていくことが多かった。
KiroにはAgent Hooksがあり、これを用いればドキュメントの更新などの雑務を自動で行う(if-then)ように設定できる。Kiroを使ってみた不安としては開発した実感がないことや、スキルを忘れてしまいそうな不安があった。これの解消策としては開発以外に価値を求めることや、Kiroを使わないことで対策が可能。
オンボーディングに使うという視点はなかった。Agent Hooksで雑務をお願いすることは楽そうなのでぜひ試してみたい。
Cloud RunでのリモートMCPサーバー構築と、それらを支えるIaCのお話
太田有人さん
Cloud RunではFastMCP, Uvicorn,...などを利用。Pythonで作られているそうなので自分も真似できるかもしれない。これをコンテナにしてCloud Runでホスト。 認証は将来的にOAuthの導入を検討。インフラ部分はTerreformとTerragruntでDRYな構成にしているらしい。 MCPサーバーをホストしたことはなかったのでまた試してみたい。
DataOps Night #8 ～スケーラブルでAI-Readyなデータ基盤の最前線～ の参加記録
DataOps Night #8 ～スケーラブルでAI-Readyなデータ基盤の最前線～ というイベントに参加させていただいていました。AI-Readyというところで先進的な取り組みと、それを支える裏の泥臭い取り組みを同時に知ることができて勉強になりました。講演者のかた、運営のみなさま、ありがとうございました。
LLMによるデータ構造化の精度管理
株式会社ナウキャスト 隅田 敦さん
非構造データのETLの中にもLLMというのは正規化や情報抽出など今後入ってくる。確かにユーザーインタビューやアンケートなどで活用していけそう。例に挙げられていたものは物件情報のメール(非構造データ)から構造化された状態で物件情報を抽出するようなワークフロー。
LLMを用いたETLのベンチマークが必要になってくる。本番運用だと継続かつ高頻度に行わないといけないし、データのシフトへの変更に対応することも重要。これはMLプロジェクトでよく出てくる話な気がする。(が、対応できている企業はどれぐらいあるだろうか)
精度はユースケースに応じて(ドメインを理解して)定義することが必要。例えば物件情報のうち賃料や面積などの優先度が高いものが完全一致することを正解とする。この定義のもとで適合率と再現率が計算できる。
精度の計測はCLIツールによって自動化されている。これがCIのところで動いているのだろうか？時間の都合で発表されなかったベンチマークにはいっていない未知のデータが来た場合の処理も興味があるのでどこかで聞いてみたい。
OCRのような、どうしても誤りが含まれるものをETLに組み込む際のデータ品質の管理方法が気になっていたが誤りがあること前提にアプリケーション側で誤りに気づきやすい仕組みであったりユーザーが修正できるような管理画面があるとのこと。
Terragruntを用いたスケーラブルなSnowflakeインフラ管理
シンプルフォーム株式会社 山岸 裕樹さん
TerraformはHashiCorpが脱しているIaCのためのツール。Snowflakeもサポートしている。現職ではAWSに閉じているので必要性を感じていないが、勉強しておいたほうがよいかも。モジュール化という機能により、環境をまたいでもリソース本体のコードはDRYになるが一方でメタ情報がDRYにならない。cdk.context.jsonがないみたいな理解であっているのかな？
TerragruntはTerraformのラッパーでを用いればメタ情報も含めてDRYになるらしい。tfstateが細かく分割できる反面、事前のディレクトリの設計が重要。これは結構大変な気もする。
Snowflakeの場合はオブジェクトレベルでディレクトリを切ることで、認知負荷が少ない形で開発できるらしい。
GA technologiesでのAI-Readyの取り組み
株式会社GA technologies 酒井 悠斗さん
デジタルマーケティングに数十億かけており、広告の最適化などを行っているらしい。とてもやりがいがありそう。確かにRENOSYの広告はよく見る。AI-Readyのワードは元からあったが、LLM活用の文脈で再注目されるようになった。AI-Readyとは戦略、インフラ、データ、人文化、ガバナンスの5つに分けれる。
購入まではWeb問い合わせから電話面談、オンライン面談、契約手続きがあり人がかかわる部分が多くAI活用の余地があった。そのなかで面談のデータを活用したいが課題があった。
まずはそもそもデータなかった。面談の会話内容はZoomの中にありそのままでは活用できない状態にありデータを連携するところから始めた。
他にリアルタイム性がもとめられるケースも出てきた。バッチ処理のワークフローと併存する形でZoomの面談データをWebhookで処理するワークフローも追加した。ワークフローのタイミングが異なるとZoomの面談記録だけ先にあって顧客のデータがCRMから取れてないみたいな不整合なケースはなかったのだろうか？
SFAのデータとZoomのデータが紐づけられなかった。ある程度ロジックでカバーしたうえでSFAも面談データ作成時にZoomのMTGも作成するようにした。周囲を巻き込んで改善していくのは重要ですよね...
データの品質が足りない。文字起こしの制度も完ぺきではなく、固有名詞の誤認識が多かった。こちらは用語集などを用いたLLMでのプロンプトの改修で管理できるようにした。glossaryで求める制度が出たというのは結構すごいのでは。コツとかがあれば聞いてみたい
LLMアプリの民主化。Difyを用いてデータ以外のメンバーも触れるようにした。LLMアプリもDify側でコントロールすることで管理。Difyの認証まわりをどう管理しているのかが気になった。
Apache Iceberg Meetup Japan #3 の参加記録
Apache Iceberg Meetup Japan #3 に参加させていただいていました。icebergだけを対象とした会は初めてで、どの講演も興味深く聞かせていただきました。講演者の方、運営の方、スポンサーの方にお礼申し上げます。
https://iceberg.connpass.com/event/364492/
Iceberg, Trinoでのログ基盤構築とパフォーマンス最適化
上條 忠久さん さくらインターネット株式会社
社内ではもともと監視基盤が個別に構築運用されていた。Trinoとicebergで開発を開始した。システムログの保管場所として開発しており、2025年にパブリックサービスとして開発の完了予定だそう
ログ基盤としてはotlp/httpでの書き込みをサポートしており独自webuiはログの検索する際に便利そう。
icebergとはストレージフォーマットでデータレイク構築などに用いられる。高い信頼性と費用対効果の高いストレージを持つ。またマージ戦略などによるパフォーマンス最適化や柔軟なスキーマ変更も可能。
icebergの内部としてはカタログはdbに保存しており、それ以外はS3などに保存される。普段はAWS Glue Data Catalogを使っているので意識することはないが、自前で組む場合は何かしらのDBを持つ必要がある。資料にあったメタデータで何を管理しているかというスライドがとてもわかりやすかった。
icebergでは書き込みが増え続けるとどうしてもメタデータやスナップショットが肥大化する。そのため定期的なメンテナンスが必要。
具体的には小さいファイルをまとめるマージ、スナップショットや孤立ファイルの削除、古いメタデータの削除がある。スライドで紹介されたコマンドは初見だったがAthenaではVacuumに相当するものだろうか？メタデータの削除はAthenaにはまだなさそう？
そのためログ基盤では定期的にメンテナンスコマンドを発行して、またメンテナンス状態をモニタリングしている。このあたりを管理するのは大変なので自動化してくれるのは嬉しい。S3Tablesとかも、このあたりの機能を備えているのかな？
s3互換のオブジェクトストレージを作る大変さが質疑応答で伺い知れました。
大規模Snowflake＋αのIcebergの活用
松原 侑哉さん 株式会社NTTドコモ
オンプレ、Redshift、BigQuery、snowflake +databidricsと基盤を移行しているらしい。データの量が大きいだけに短いスパンで移行しているのはすごい。
中央集権型からデータメッシュに移行しており、データオーナーが責任を持ちデータを管理する。snowflakeではinternal market placeというのでデータ共有が簡単にできるらしい？
snowflakeの通常テーブルとicebergではクエリ性能の劣化はあまりみられなかったそう。snowflakeがわからないけど通常テーブルというのがそんなに性能が良いのだろうか？
一方でストレージに関しては通常テーブルより最大30%ほど効率が良い。これはテーブルの多くがfloatな一方、通常テーブルではdoubleであったことからしい。なのでテーブルの構造に強く影響されそう？
エンタープライズな金で殴ることができない規模のデータ処理の話が聞けて興味深かったです。
Kafkaを利用したIcebergへのデータストリーミング
清水 亮夫さん Confluent Japan合同会社
Kafkaを使ったicebergへのデータ取り込みの話。
Kafka Connectというものがあり、これを用いることでローコードでデータの取り込みが実現できるそう。複数のデータシンクへの配信やデータに対するマスクもパイプラインの中で行えるので使う上で困らなさそう。
連続的な書き込みをどうするのかが気になったが、もちろん全てのワーカーで書き込んでいくわけではなくで5分間隔でまとめてコミットしているらしい。確かにそれなら解決できそう。
docker composeするだけで試せる環境もあるらしいので今度試してみたい。小ネタで挙げられていたtabular版であったupsertが無くなっているのが実務では結構困るかもしれない。Insert onlyな環境だととてもよく使えそう。
AIセミナー「n8n＆Dify 徹底活用」AIワークフロー自動生成やナレッジ運用を徹底解説！【大阪】 の参加記録
AIセミナー「n8n＆Dify 徹底活用」AIワークフロー自動生成やナレッジ運用を徹底解説！【大阪】に参加させていただいていました。グランフロントの高層階に綺麗なオフィスがあり圧巻！
VPSでDifyとかが動かせるらしい。1800円/月とかで動かせるので確かにEC2とか立てるより安いかも
https://xserver.connpass.com/event/368862/
Difyを使用した社内ナレッジ回答アシスタントにおいて、ナレッジ更新を自動化する方法
taskforce株式会社 谷口 輔久さん
組織でDifyを使える状態にする。実務上の困難はアプリ共有とナレッジの更新。共有は組織専用のアプリポータルを運用、ナレッジはデータソース更新をトリガーに自動で作成で対応。
ユーザーごとに見えるアプリを切り替える。アプリポータルで精度を追跡したり利用状況を可視化できる。ダッシュボードにしてみることも出来る。
ソースの変更イベントを検知してキャプチャして差分更新する。これによってソース側の変更をナレッジに更新することが可能。
基本的な機能であればAPIが充実しているため、自分たちでもできそう。ただDifyだけの機能で組織に導入していくことは結構大変か。
MCP時代のn8n活用 ― ワークフロー自動生成と外部制御
株式会社RAYVEN 鈴山 佳宏さん
n8nは外部ツールとのワークフローを自動化するプラットフォーム。検索のトレンド的にはDifyよりn8nの方が上のよう？テンプレートがあるので、既存のものを流用可能。StepFunctionsみたいなもの？VPSのようなところでホスティングする必要はある。
外部からAPIでワークフローが呼び出せないのはちょっとエンジニア的には辛いかもしれない。
n8nにMCPを使うことが可能。なのでAIに自然言語で依頼することでワークフローが作成できる。外部から呼び出すのがこんなんだったのをMCPサーバー化することで可能になるとか？
Difyもn8nも認証、認可まわりが大変そう。Localで動かすか、オンプレで動かすか...
【エムスリー／バンダイナムコネクサス／東京ガス／リクルート】TECH PLAY Data Conference 2025 事業の意思決定を支えるデータマネジメント の参加記録
【エムスリー／バンダイナムコネクサス／東京ガス／リクルート】TECH PLAY Data Conference 2025 事業の意思決定を支えるデータマネジメント の参加記録 に参加させていただいていました。
用事により後半だけ聴講させていただいていました
データメッシュ×データマネジメントで加速する東京ガスのデータ・AI民主化 ― 実践事例と次世代データ基盤への挑戦 ―
東京ガス株式会社 笹谷 俊徳さん
全社的なデータ基盤はすでに存在しておりデータ活用していくべきという流れはあった。一方で中央集権型のためアジリティやガバナンスに課題が出てきた。 そこでモダンなAIやプラットフォームをもちいた新たなデータ基盤へと移行を検討した。いわゆる一般的な中央集権からデータメッシュへと移行した。 データメッシュの事例を聞けるのはとても貴重。
データメッシュ、つまり中央集権から個別ドメインに最適な形でデータ基盤を整備する。個々のドメインでデータを管理し、他からはデータカタログを通じて各ドメインのデータを参照する。 一方でデータプロダクトのインターフェイスや認証、認可は共通化しておく。
文書やパワポもいった非構造データも生成AI活用の発展にともないデータマネジメントの対象とする。ユーザーはAIエージェントを通じたデータメッシュ上に整備されたデータにアクセス
データ基盤をタレントマネジメントに利用されているとのこと。採用とかでは聞いたことはあるが社内の人事に関しての利用のケースは初めて聞いた。社員のキャリアについてAIがチャット形式でアドバイスしてくれたり、生成AIや数理最適化による異動のレコメンドを行う。人事のようなセンシティブかつKDDで進みやすい事柄をデータドリブンに行えることがすごい。
顧客DNAとよばれる顧客基盤も構築している。データの組み合わせによって顧客の属性や価値観にあわせた提案やマーケティングをおこなう。
データメッシュやデータマネジメントの体制も拡大しているが、人材や育成には苦労したことのこと。確かにデータメッシュの経験者はかなり少なさそう。
モダンなデータマネジメントの体制でかなり先進的な取り組みの話が聞けて面白かったです。
経営の意思決定を加速する「事業KPIダッシュボード」構築の全貌
株式会社リクルート 白子 佳孝さん
これまでは各事業が独自で報告しているため、横断的に把握できないという問題があった。
経営と事業の認識を統一する。具体的にはマーケットプレイスビジネスモデルにそって売り上げと予約と両方からの分解に全事業をそろえる。また指標の定義をそろえて、認識ずれがないようにする
KPIツリーを使った指標の構造化する。売り上げとアクションのつながり全体像を見せることで単なるKPIの報告でなくなる。KPIツリー、全体の構造をみれるダッシュボードはとても良いと思った。自分も真似していきたい。
利用される仕組みづくりとしてダッシュボードをもとに議論する場を作る。報告から議論が行われるようにする。
報告だけ、見るだけにせずにモニタリングのダッシュボードを活用していく方法がしれて興味深かった。意思決定層にデータを届けられるような仕組みを作っていかなければと強く感じた。
JAWS-UG CDK支部#22 大阪でもCDKしたいねん 参加記録(感想)
大阪で珍しく？CDKのイベントが開催されていたので、参加させていただいていました。運営のかた、講演者のかたありがとうございました。
https://jawsug-cdk.connpass.com/event/365121/
惚れてまうやろ - CDKを初めて使った感想
こばさん
CDKとはAWS純正のIaCツール。新しく生えるCloudOPSの資格試験にCDKが入るのは知らなかった。 CDKの良さとして一般的な言語(TypeScript, Python, ...)がつかえる。そのためIDEの機能をうまく使えたり、AIによる支援も受けやすい。
またIaCなので構成変更が簡単。タイトなスケジュールであったり要件の変更などに対応しやすい。
インフラだけでなくLambdaなどアプリのコードも含めてデプロイが簡単にできる。
なにより使っていて楽しいというのは一番良いところ。
まずはマネコンでちゃちゃっと作ってから、それをCDKにしてみよか。
ヤマダさん
ラーメンタイマー(SFn)の作成されていたらしい。
SFnはasl.jsonという形のファイルで記載でき、これを用いればVSCode上SFnを編集ができる。 そのためローカルでSFnをかけるため、いちいちマネコンを設定しなくて良いのが嬉しい。
マネコンでつくったものを移植しているが、なぜかAppSynkのところでつまっているとのこと。
CDK CLIで使ってたあの機能、CDK Toolkit Libraryではどうやるの？
SUZUKI Masakiさん
CDK Toolkit Libraryは知らなかった。cliで実行していた処理をプログラムから実行できる可能なライブラリ。
cdk は --profileでプロファイルを指定できていた。ただcdk toolkit libraryでは指定できないらしい。sdkConfigに設定することで設定が可能。
cdkでは一部センシティブな処理をユーザーに確認をとっていた。toolkit libraryは確認がないらしく、これはちょっと困るかもしれない。確認処理はioHostで設定が出来る。デフォルトだとスタックの削除が確認なく行えてしまうため、設定を変更しておくのがおすすめとのこと。
ないもんは作ればええねん ~ CDKエコシステムへの貢献とL2 Constructの新規開発 ~
よ〜んさん
lightsailはL2コンストラクタがない。ないから作るというバイタリティがすごい。 公式がRFCプロセスという壁があるとのこと。一方でOpen Constructs Libraryはコントリビュートを歓迎してくれているらしい。公式のCDK以外にもエコシステムがあることは知らなかった。
宇宙最速!? CDK Refactorをがっつり語る会
CDK Refactor(Preview版)という機能がつい最近でた。外部からみた振る舞いを変えずに、内部構造を意図した形に再構成できる。例えばStack AでつくったDynamoDBをStack Bに移せるらしい。これは一部のケースですごく助かりそう。 あとからリファクタできるイメージがなかったので、試してみたい。L1からL2への書き換えとかでも使えるかも？
エスマットさん開催のデータ基盤勉強会の参加記録(感想)
エスマットさんが開催されているデータ基盤勉強会に参加させていただきました。
時系列データ×生成AIで示唆を届ける ─ 在庫AIエージェント開発・運用の裏側
野島 大誠さん
プロダクト開発は不確実性が高い。生成AIを使うプロダクトはより不確実性が高くなる。
初めは基盤は作らじに何ができるか、価値が出せるかを小さいサイクルを回しながら開発する。ユースケースから基盤構築のとりかかれるのは良いと思いました。
生成AIをつかうプロダクトを定量的に評価して改善していくのは難し(やりがいがあり)そう。
個人からはじめる生成AI de データエンジニアリング
瀬田 拓海さん
個人、開発で使えるデータエンジニアリングでつかえる方法の紹介。
EvidenceをBIツールとして採用している例は初めて見たかもしれない。
MCPサーバーはsnowflake(自作), dbt, aws(cdk, knowledge)を使用しているとのこと。readの権限だけ渡しているらしい。awsのものは自分でも導入していけそう。
AI-Readyなデータ基盤には一足先にいけなくてHuman-Readyなデータ基盤の延長線上にあるのではないか
生成AIは社内のデータ活用をどのように変えた/変えるか？
大木 基至さん
活用領域のデータにまつわる課題 - 分析の企画設計、データのディスカバリー、データマート開発 、自然言語による分析、事業計画の理解、モニタリングとアクション
分析の企画、設計
- 業界や分析、社内の商品や業務プロセスに詳しいAIパートナーがある(作った)らしい？
データマート開発
- 開発手順をドキュメント化している。それを参照してAIが開発する。これはドキュメントの整備も含めて自社でもやっていきたい。
データディスカバリー
- 目的ごとに個別に詳しいAIを用意して呼び出す
事業計画の理解
- ドキュメントが重要。事業計画を支える数字の裏のロジックや理由について理解できる
今後、エンジニアはAIを使いこなしていく能力が重要になってくる。ドキュメントをAI-Readyな資産として整備していくのが重要だと再認識しました。
