2026-05-24の技術動向：エージェント、コンプライアンス、そしてデータレイクハウスの進化

OpenClaw passed 300,000 GitHub stars. Then Google launched Spark.

OpenClawがGitHubで30万スターを超えたって話を聞いた。4ヶ月でReactを超える勢いだ。このプロジェクトは「自分のMac miniで動かす」ことを売りにしている。電力も7Wしか食わないし、棚に置いておけばいい。一方でGoogleのSparkは、Google Cloud上の仮想マシンで動く24時間体制のエージェントだ。

私みたいなバックエンドエンジニアだと、まず「どこで動くか」を気にする。OpenClawなら自前のハードウェアで動かせるし、認証情報も自分の手元にある。でも、ちゃんと動かすにはTailscaleの設定や、機密キーのローテーションとか、手間がかかる。

でもGoogleのSparkは、すでにGmailやドキュメントの中にいて、設定なしで動く。これは強力だ。Dropboxが自前のNASに勝ったのと同じ理屈で、管理コストをかけたくない人には魅力的だろう。

でも、ここが一番気になるところだ。ファイルをGoogleに置くのとは違う。Sparkは私のメールやカレンダー、関係性まで読んで、勝手にメールを書いたりするんだ。その「アクセス権」をGoogleに握らせるのか。これは単なるデータ保存じゃなくて、私の生活そのものをGoogleに委ねることになる。

個人エージェントの市場は、管理型とセルフホスト型で分かれそうだ。私は今のところ、OpenClawのような「自分のハードウェアで動くもの」に興味がある。でも、本当に便利になりたいなら、Googleのクラウドに頼るしかないのかもしれない。

Anthropic’s $300M Stainless deal lands hardest on OpenAI and Google

Anthropicが$300MでSDK生成系のStainlessを買収した。面白い。

OpenAPI specからTypeScriptやPythonのSDKを吐き出すツールで

OpenAPI Specification（旧Swagger）は、REST APIの仕様を記述する標準フォーマットであり、これに基づいてSDKやドキュメントを自動生成するための共通言語として機能する。、OpenAIやGoogle、Cloudflareも使ってた。これが今、Anthropicの所有物になったことで、ホストサービスが終了する。つまり、OpenAIやGoogleは自前でSDK作るか、移行するしかない。

エンジニアとして、APIのラッパーが変わるたびにライブラリを書き直すのは地味に面倒だ。Stainlessが提供していた「共有の工場」がなくなったことで、競合他社は開発体験の維持にコストを払うことになる。

これでAnthropicが開発体験を完全にコントロールできるようになったわけだ。ライブラリの互換性がどうなるか、気になるところだ。

How MCP and synthetic data are reshaping compliance in the agentic era

AIエージェントが開発プロセスのあちこちでデータに触れるようになった。私の業務でもCopilotやClaudeは欠かせないけど、これが「意図せず」機密データにアクセスするリスクを増やしているのは確かだ。

従来のガバナンス（手動レビューや定期的な監査）だと、AIが一時間に何千ものリクエストを投げてきたら追いつけない。特に開発やテスト環境に本番データが流れ込む非生産環境のリスクは、Kubernetesで環境を複製している私には痛いところだ。コード生成が増えれば増えるほど、テストデータの管理が命題になる。

記事で紹介されていたMCP（Model Context Protocol）や合成データを使えば

MCPは、AIモデルが外部データソース（データベース、ファイルシステムなど）に安全かつ標準化された方法でアクセスするためのプロトコル仕様である。、データアクセスを自動制御できそうだ。MCPは自然言語でデータインフラにアクセスできる標準インターフェースとして機能し、複数のシステムにログインする手間を省く。これにより、ガバナンスを「ボトルネック」ではなく「サービス」として提供できる。

DevOpsのベストプラクティスが重要になるのは間違いない。これからは、KubernetesやTerraformでインフラを管理しつつ、AIが自律的に動ける安全なデータフローを構築するのがエンジニアの仕事になるのかもしれない。

Google Cloud Introduces Cross-Engine Iceberg Support in BigQuery

アパッチIceberg SummitでGoogle Cloudが発表した「Cross-Engine Iceberg Support」について、読んだ。

BigQueryがApache IcebergのサーバーレスRESTカタログをプレビューで提供するという話だ。これにより、SparkやTrinoといった別のエンジンと同じIcebergテーブルをBigQuery上で作成・更新・クエリできるようになる。データをコピーする必要がないのは、ストレージコストと運用負荷の観点でかなり魅力的だ。

最近のデータアーキテクチャは「レイクハウス」にシフトしつつある。Apache Icebergはその中核になりつつあるし、Netflixが作った技術がここまで業界標準になるなんて驚きだ。ただ、実際にIcebergを導入していると、メタデータ管理やCompaction（圧縮）などで手間がかかることを感じる。「隠れた税金」って言われても仕方ない部分だよね。

自分のワークフローだと、バッチ処理はSparkで回しつつ、分析はBigQueryを使うことが多い。以前は、SparkでETLしてIceberg REST Catalogに書き込んでいたら、BigQueryからは直接書き込めなかったし、BigQueryのストレージ管理機能も使えない。これがつらい。

今回のアップデートで、BigQueryのインフラがIcebergテーブルをネイティブにサポートするようになったことで、メタデータ管理やトランザクション、CDC（変更データレプリケーション）をBigQuery側で管理できるようになる。SparkでETLしたデータをBigQueryでそのまま分析できるし、逆にBigQueryからIcebergカタログに書き込むこともできる。この制約がなくなるのは、開発体験がかなり良くなる。

さらに、AWSやAzure、Databricks、Snowflakeといった他のクラウドやプラットフォームともIcebergを通じてやり取りできるようになる。ObjectRefsで構造化データとCloud Storageの非構造化データを混ぜられるのも、AIワークフローとの連携を考えると重要だ。

ただ、実装はまだプレビュー段階だし、完全にマネージドな運用になるかは検証が必要だ。でも、Openなフォーマットでデータを持ちつつ、運用の大部分をGoogleに任せられるなら、かなり魅力的な選択肢になる。自分のプロジェクトでも、まずはこの機能を使って、SparkとBigQueryの間の壁を少しでも低くしてみたい。

What Anthropic and OpenAI launched in 72 hours has Wall Street paying attention

72時間でこうも動くとは驚きだ。AnthropicとOpenAIが、金融業界向けのサービス部門を立ち上げ、連携を発表した件。

モデルの性能競争から「デプロイのギャップ」にシフトしていると感じる。記事によると、これらの大手が「Forward Deployed Engineer（常駐型エンジニア）」を送り込み、現場のワークフローを再構築する流れだ。私の周りの現場でも、LLMはあるものの「どう業務に組み込むか」で悩むチームは多い。その「つなぎ」の仕事が、今後はもっと本格化しそうだ。

特に金融業界に注目したのは興味深い。PwCとOpenAIの話だと、CFOオフィスの業務をAIエージェント化し、契約処理を5倍に高速化したとか。人間の監視は残すものの、業務効率化は明確だ。Anthropicも金融用のテンプレートを公開し、Opus 4.7がベンチマークで勝っている。

これは私のワークフローにも関係してくる。これまではKubernetesやCI/CDのインフラ構築がメインだったが、AIエージェントの実装と運用が次のフェーズになるのかもしれない。エンジニアが顧客先に常駐して業務を設計する時代が、もうすぐ来るのかもしれない。

参照記事

記録日: 2026-05-24

今日の傾向

今日の動向は、個人向けAIエージェントの選択肢の拡大、開発体験を握るSDK市場の変動、そしてデータレイクハウスの標準化（Iceberg）の進展に集約されているようだ。エンジニアはAIの自律性とガバナンスのバランス、そしてデータの非構造化と構造化の融合を考える必要がある。