2026年5月の技術動向：AIの限界とチームのスケーラビリティ

AI won’t speed up software delivery — nothing has

ラブラドールと犬の話から始まるこの記事。ペットを飼うなら「相棒」が欲しい。そこで「AIはスピードだけ」という企業は、チーターを飼おうとしているようなものだ。

私の現場でもAIツールはある。CopilotやClaudeでコードは書きやすくなった。でもデプロイの速度は変わっていない。ボトルネックは別にある。

アジャイルやDevOpsも「スピード」だけを求めて失敗してきた歴史がある。目的はスピードじゃなくて「フィードバック」。ユーザーが嫌がる機能を早く知るためだ。

「フィードバックループ」は、開発した機能をユーザーに届け、その反応を元に修正を繰り返すプロセスを指します。早くリリースしてから修正するのではなく、早く間違いに気づくことが目的です。

インフラエンジニアとして、TerraformやK8sの設定をAIが書いてくれたとしても、承認プロセスが遅ければ意味がない。AIが個人の作業時間を削減しても、組織全体のリリース速度は上がらない。

フィードバックを「メトロノーム」にする考え方は面白い。これに合わせてペースを調整するイメージ。AIをどう使うかは、もう一度見直す必要があるかもしれない。

Arize AI and Google Cloud lay down standardized telemetry mandate to keep enterprise agents in check

ArizeとGoogle Cloudが提唱する「エージェントの標準化された監視」って話。エージェントが複雑になりすぎて、可視性がなくなってきたのが現状だね。

モダンなエンタープライズソフトはコンポーザブルだから、エージェントも自由に動けるようになった。でも、監視データがバラバラだと「西部開拓時代」みたいだ。ArizeのRichard Young氏は「OpenTelemetryやOpenInferenceを使えば、オプション性は保ちつつ可視性は維持できる

これらは、分散トレーシングやメトリクスの収集を標準化するためのオープンなプロトコルです。プロバイダに依存せず、一つの仕組みで複数のシステムのログを統合できるため、エージェントの可視性を確保するのに役立ちます。」と言ってる。

私のワークフローだと、GoやPythonで書いたマイクロサービスはOpenTelemetryでトレースしてる。LLMの部分も含めて同じように管理できるのは嬉しい。Google CloudのGemini Enterprise Agent PlatformとArize AXが連携して、一度インストルメンテーションすれば、どこへでもルーティングできる仕組みになっているらしい。

実際のエージェントは、リクエストの書き換え、検索、ツール呼び出し、リトライ、ハンドオフまでやるから、一つの実行に複雑な手順が含まれる。Ryan Mangan氏の言葉通り、「見えないものは操作できない」。構造化されたトレースがないと、デバッグは推測の域を出ない。

以前、トレース標準がバラバラだった時と同じ流れだね。Noam Levy氏は「OpenTelemetryは必須だけど、スケールでの収集や正規化が難しい問題がある」と指摘してる。各プロバイダ（OpenAIとかAnthropic）のデータをどう統一するか、そこが次の山だ。

Cloudflare Processes 10M+ Daily Insights with New Security Overview Dashboard

Cloudflareがセキュリティダッシュボードの刷新を発表した。「Security Overview」という新機能は、これまで散らばっていたセキュリティのログや警告を一箇所にまとめている。

セキュリティオペレーションで一番の悩みは「何に手をつけるべきか」の判断にある気がする。この新ダッシュボードは「Security Action Items」という概念を導入して、重大度ごとにリスト化してくれるらしい。これまで複数のツールを切り替えて調査していた作業を、ここで優先順位を付け直すだけで済むならかなり効率化できる。

WAFルールやAPIセキュリティの制御が「有効モード」か「ログのみモード」かをリアルタイムで確認できる機能もポイントだ。

WAF（Web Application Firewall）は、Webアプリケーションに対する攻撃を防御するためのファイアウォールの一種です。運用していて地味に嬉しいのは、設定ミスを検知できる点だ。これ、監査の負担を減らすのに役立ちそうだ。

1日に1000万件以上のインサイトを生成しているという。その裏にあるアーキテクチャは、DNS設定やAPIセキュリティなど、特定のドメインに特化した「checkers」というマイクロサービス群だ。スケーラビリティを意識した設計なのかな。

今はドメイン単位の表示だが、アカウント単位で全ドメインのリスクをまとめて見る機能も今後追加される。複数サービスを運用していると、こういう統合ビューは欲しいところだ。実際に運用してみて、この優先順位付けがどれくらい正確かはまだ分からないが、とりあえずは使ってみる価値がありそうだ。

Presentation: The Human Scalability Problem: Why Your Teams Don’t Scale Like Your Code

Charlotte de Jong Schouwenburgさんが LeanIXの事例を挙げていたのが印象的だった。

LeanIXは、企業のITインフラやアプリケーションのライフサイクルを管理するプラットフォームです。12人から500人へと急成長した同社は、技術的なスケーリングは成功したが、意思決定が10倍遅くなったり、チーム間の連携が崩壊したりしたそうだ。

これって、マイクロサービスをKubernetesで構築した時によくある話じゃないか。プロセスやツールは整ったけど、人間同士がつながっていないと、結局は「ダブルワーク」や「不満」が増えるだけだ。

私自身、GoやPythonでサービスを書いていると、インフラはスケールするけど、オーナーシップが分散してコミュニケーションコストが跳ね上がった経験はある。特にリモートワークが増えた今、AIツールでコードは効率化できても、心理的安全性や信頼関係の構築にはまだ手が届かない部分がある。

このままでは、技術力があってもチームとしてのスピードは落ちてしまう。

Podcast: Roq: Leveraging Quarkus to Build Static Sites at the Speed of Go

静的サイトジェネレータのRoqという新プロジェクトを知った。Quarkusの作者が作っていて、JavaとQuarkusの力を借りてMarkdownをHTMLに変えるだけのシンプルな仕組みだ。

Quarkusは、KubernetesネイティブなJavaフレームワークで、起動時間の短縮と低メモリ消費に特化しています。

普段はGoやTypeScriptでマイクロサービスを書く身として、静的サイト生成は別の言語でやることが多い。でも、QuarkusがJVMのネイティブ実行速度を実現してJavaが復権している流れは面白い。

起動も速いし、Quarkusの拡張機能が軽いからか、フットプリントも小さい。マークダウンファイルだけでサイトを生成できるなら、ドキュメントサイトやブログの構築に使えそうだ。

既存のWebアプリを移行するにはコンテンツをMarkdownに落とし込むだけでいいらしい。非エンジニアにも優しいUIを追加する予定とのこと。業務で使えるか試してみたい。

参照記事

今日の傾向

AI監視の標準化、セキュリティダッシュボードの集約、そして人間のスケーラビリティといったトピックから読み取れるのは、技術の複雑化に伴い「可視性」と「運用の効率化」が最優先課題になっていることだ。AIは単なるスピードアップではなく、監視と制御の対象として位置づけ直されつつある。

記録日: 2026-05-05