既存の仕組みが限界に達したとき、延ばす部分と作り直す部分の境界線を引く

エージェントAIの観測にOTelとOpenSearchが組む、という実験

AWSのエンジニアが7月22日、OpenTelemetryとOpenSearchを使ったエージェントAIのトラブルシューティング実演を行う。ログ・メトリクス・トレースの相関確認から、エージェントのトレースがOTelパイプラインをどう流れるかまでをライブで見せるという。同時にオープンソースの評価フレームワーク「Agent Health」も紹介される。本番前のベンチマークで、エージェントの予測不能な挙動にフラグを立てる仕組みだ。

気になるのは「非決定的なエージェント」が観測の前提をどう変えるか。従来のログ・メトリクス・トレースの3本柱は、決定的なマイクロサービス向きに作られている。入力が同じなら出力も同じ、だから異常はトレースのスパンやメトリクスの閾値で拾えた。エージェントは違う。同じプロンプトでもLLMの応答がブレるし、ツール呼び出しのチェーンも毎回変わる。ボリュームも桁違いだ。記事が指摘する通り、「テスト環境で動いた」がもはや意味をなさない。ここは実感としてわかる。手元のAPI呼び出しが冪等だった時代の観測モデルを、そのままエージェントに持ち込むのは無理がある。

OTelが新しいクラウドネイティブ計装プロジェクトの95%採用を超えたという数字は大きい。事実上のデファクト。この土台の上にエージェント向けのセマンティックコンベンションを乗せようとしているわけで

（セマンティックコンベンションとは、属性名や値の定義を標準化し、異なるツール間でもデータの意味を統一する共通規格のこと）、プロプライエタリなツールにロックインされるより筋がいい。OpenSearch側も今年のロードマップで、AIエージェントの主要な検索インターフェースとRAGスタックの必須層になることを明記している。観測とAIの統合という方向性ははっきりしている。

ではワークフローはどう変わるか。Agent Healthが提供するのは、本番前の構造化ベンチマークだ。エージェントを一定シナリオで走らせ、OTelトレースとOpenSearchの評価データで挙動を検査する。プロンプト変更やツール追加のたびに、このベンチマークを回すことになるだろう。CIに組み込むイメージか。ただし、ベンチマークが通ったエージェントが本番で安定する保証はない。非決定性はテスト環境でも本番でも同じだから、ベンチマーク自体の信頼性をどう担保するかは別の課題として残る。LLMをジャッジとして使う評価手法があるらしいが、実務でどこまで使えるのかは未知数だ。

7月22日の実演で、AWS勢がこの矛盾をどう捌くか。エージェントの観測は「どこまで既存のOTelパイプラインで賄えるか」と「どこにエージェント専用の拡張が必要か」の境界線だ。そこが見えれば、マイクロサービスの観測基盤をエージェントにどこまで延ばせるか判断できる。

PostgreSQLからClickHouseへ：200億エントリのキャッシュを支える再設計

MomenticはAI駆動のソフトウェアテストプラットフォームを提供する企業だ。彼らがキャッシュシステムの再構築に踏み切った直接のきっかけは、データ量の急増だった。キャッシュテーブルが約8万エントリから10億エントリへ膨れ上がったとき、PostgreSQLでは対応できなくなった。高頻度な読み書きが同時に走るワークロードで、リソース消費の増大とロック競合が顕在化したのだ。

移行時点で1日約60万回のキャッシュルックアップを処理していたが、最終的に200億エントリ、1日200万クエリ以上を平均レイテンシ約250msでさばく構成になった。この数字だけ見ると劇的な改善だが、注目すべきは移行の過程で問い合わせパターンそのものも見直している点だ。

ClickHouseを選んだ技術的な理由は、スパース主キーインデックスにある。

（スパースインデックスは、全行ではなく一定間隔のデータのみにインデックスを貼ることで、メモリ消費を抑えつつ高速な範囲検索を可能にする仕組み）PostgreSQLのB-treeインデックスではデータサイズに伴ってクエリコストが増大する。一方ClickHouseは、キー値が既知の場合に探索範囲を少数の「グラニュール」へ絞り込める。Momenticは主キーにテストID、ステップID、バージョン、Gitブランチ、コミットタイムスタンプを組み込んだ。フィーチャーブランチ向けのクエリは9割が1〜2データパーツのみを読む効率的なルックアップになった。ただしメインブランチではほぼ全パーツを走査する外れ値が発生し、メモリとディスクIOがスパイクした。この問題にはマテリアライズドビューでテストIDごとのコミットタイムスタンプを事前計算することで対応した。

もう一つ興味深いのは、クエリパターンの転換だ。PostgreSQLでは3つの独立したクエリを使っていたが、ClickHouseのReplacingMergeTreeと組みて

（ReplacingMergeTreeは、同じ主キーを持つ行が挿入された際に、バックグラウンドで古いデータを新しいデータで置き換えるClickHouse特有のエンジン）、INSERT中心の構成に切り替えた。取得時のSELECT、TTL延長のための再INSERT、テスト実行後の新規INSERTを基本とし、重複排除はClickHouseの非同期処理に任せた。この変更でRedisレイヤーを完全に排除できたという。キャッシュキーのカーディナリティが高まってRedisの価値が低下していた状況で、シンプルな構成に戻せたのは大きいだろう。

移行戦略も現実的だ。PostgreSQLとClickHouseを並行稼働させ、全書き込みを両系統に複製した。本番トラフィックはPostgreSQLから引き続き提供し、ClickHouseにはシャドウクエリを投じて結果をdiffで検証。信頼性が確認できてから徐々にトラフィックを移行し、カットオーバー後もしばらくデュアルライトを維持してロールバック可能な状態を保った。この手順は、データの正確性が求められる場面で参考になるアプローチだ。

RDBMSから列指向データベースへの移行は、単なるストレージの差し替えではない。クエリパターンやデータモデル、周辺のキャッシュ層まで含めて再検討する必要がある。Momenticの事例は、データ量のスケールが既存の構成を押し潰す前に、どこで踏みとどまるかの判断材料を示している。

デスクトップから解放されたClaude Cowork

Anthropicのエージェントツール「Claude Cowork」が、ようやくデスクトップの束縛から解放された。これまでCoworkでタスクを走らせるには、ラップトップを開きっぱなしにする必要があった。スケジュール実行もローカル依存。蓋を閉じれば処理が止まる。それが今回の更新で、すべてのタスク実行がクラウドに移行された。デバイスを閉じても仕事は続く。スマホからでも進捗を確認できる。

なぜこれが重要か。エージェントの実用性は「放置できるか」に直結する。バッチジョブと同じだ。cronがサーバーで走るから信用できるのであって、手元のPCが常時起動している前提なら用途が限られる。Coworkのスケジュールタスクも同じ問題を抱えていた。既存タスクの移行は自動ではない点に注意が必要だが、新規タスクはクラウドで自動実行される。

気になるのはChatとCoworkの統合。Webとデスクトップで同一インターフェースになり、モーダルで切り替える設計になった。「依頼することが会話と同じくらい簡単に」という主張だが、ここには説明の難しさが潜む。Coworkのローンチ時、説明記事が乱立した。チャットとエージェントの違いが、大多数の知識労働者にとって自明ではないからだ。統合によって差異がぼやけるリスクはないだろうか。

興味深いのは利用データ。5月の120万件の匿名セッションのうち、90%以上がソフトウェア開発以外だという。ビジネスオペレーションが3分の1。スプレッドシートの照合、散在する更新情報の統合、オンボーディングチェックリストの作成。コンテンツ作成が16.4%。この二つで半分を占める。開発は8.7%にとどまる。Claude Codeという選択肢がすぐ隣にあることを考えると、この数字は低く見える。それでも知識労働の「仕事の周りの仕事」をエージェントに任せる流れは、確実に広がっている。

月額100ドルのMaxプランでベータ提供が始まった。数週間以内により広いプランにも拡大される見込み。常時起動エージェントを求める層にとって、自前のマシンを動かし続ける手間が消えるのは大きい。

オープンソースのコラボレーションが急増し、メンテナー防衛機能が進んだQ1 2026

GitHubのInnovation Graph最新データによると、Q1 2026の越境コラボレーションが前四半期比で16%増加した。ある経済圏の開発者から別の経済圏の公開リポジトリへ送られたgit pushとpull requestの合計を指すこの指標で、16%という数字は2020年以降で2番目の高さだ。1位はQ2 2020の21%。パンデミックの影響で一斉にPCに向かった時期であり、その異常なブームに次ぐペースで今、世界中の開発者がオープンソースに参加している。

3位はQ1 2023の9%。ある研究ラボが新サイトのバグ報告者にAPIクレジットの懸賞を提供した直後の急増だ。金銭的インセンティブがこれほど効くとは、と興味深い。ただ今回は懸賞があったわけではない。AIコーディングツールの普及でプルリクの絶対数が底上げされている可能性があるし、単にオープンソースの裾野が広がっただけかもしれない。原因は断定できないが、コントリビューションの量が爆発的に増えているのは間違いない。

地域差も面白い。シリアではQ4 2025から開発者コミュニティが急成長している。制裁緩和に伴いGitHubが機能アクセスを拡大したのが直接の契機だ。過去6ヶ月で8,000人以上のシリア人学生にStudent Developer Packが提供された。テクノロジーのアクセシビリティが政策の変化でどう変わるかを示す具体例だ。

だが、コントリビューションの急増は諸刃の剣だ。GitHubもEternal September of Open Sourceと呼び、メンテナーの負担増を認めている。私の業務でも、依存ライブラリのIssueが「+1」コメントで埋め尽くされる光景は日常茶飯事だ。そこでGitHubはメンテナー向けの防衛機能をいくつも追加した。書き込み権限のないユーザーのオープンPR数に上限を設ける機能、IssueやPRの作成をコラボレーターに限定する機能、一時的なインタラクション制限だ。これまでの「誰でもウェルカム」な雰囲気から、適切に管理された受け入れへと、プラットフォームが舵を切り始めたと読める。

レビュー体験の改善も進んだ。PRのdiff表示が新しいファイル変更体験で最大67%高速化され、Issueのナビゲーションも高速化された。ノイズコメントを減らすバナーや、Issueのコメントピン留めも追加されている。コントリビューションの質と量のバランスを取るための機能が、ここ数四半期で一気に揃った印象だ。

CNCFがMeetupからの脱却を果たした、OCG移行の2ヶ月

CNCFがOpen Community Groups（OCG）をローンチして2ヶ月が経った。ocgroups.devで動いている、オープンソースのオンラインミートアッププラットフォームだ。週末プロジェクトじゃない。ローンチまでにほぼ2年かかっている。

なぜ自前を作ったか。既存のオープンソース選択肢を探したが、CNCFのコミュニティが実際に動く方式に合うものがなかった。Meetup.comに頼り続けることもできた。だが、サードパーティのプラットフォームにコミュニティの居場所を預けるリスクは、Cloud Native界隈のプロジェクトがよく知っている問題だ。ベンダーロックインはインフラだけの話じゃない。コミュニティの基盤でも起きる。自前で構築する方が、既存の何かを無理に曲げて使うよりコミュニティに奉仕する。そういう判断だった。

5月2日の週末に移行を実行。既存プラットフォームのスナップショットを取り、コミュニティグループを移した。community.cncf.ioでリダイレクトサービスを動かし、Cloud Native Community Group（CNCG）、Kubernetes Community Day（KCD）、バーチャルイベントそれぞれに振り分ける。最初の数日はDNSまわりのトラブルがあった。おなじみの問題だ。でも週末には解消された。KCDとバーチャルイベントはまだcommunity2.cncf.ioに残っているが、こちらへの移行も進行中らしい。二つのシステムを並走させ続けるつもりはない。

2ヶ月の数字を見る。289グループ、89,202メンバー、6,024イベント、146,182の参加者。ライブの数字はocgroups.dev/statsで確認できる。

次の優先事項が2つ。KCDのようなイベント向けの決済機能。そしてCNCFエコシステムの他の部分との統合。Slackやメーリングリストとの連携だ。自前で作った意義はまさにここにある。サードパーティならAPIの制限や仕様変更に縛られる。自分たちで作れば、自分たちのワークフローに合わせて統合の自由を手に入れる。408のマージされたPR、68以上のクローズドイシュー。コミュニティがすでに動いている。

気になるのは運用の持続可能性だ。プラットフォームを自前で持つということは、機能追加だけでなくインフラの維持、障害対応、セキュリティパッチも自分たちで背負うということだ。CNCFのスケールでこれを回し続けられるか。決済機能が入れば、今度はPCI DSSへの準拠や決済トラブルの対応も発生する。オープンソースだからこそ、コントリビューションが持続するかどうかも鍵になる。でも、少なくとも方向は筋が通っている。コミュニティの基盤をコミュニティ自身の手で持つ。それがCloud Nativeの理念と合致する。

まとめ

5つの話題に共通するのは、既存の前提が限界に達している場面だ。エージェントの非決定性は冪等なマイクロサービス向きの観測モデルと合わない。データ量の急増はPostgreSQLのB-treeインデックスを押し潰す。コントリビューションの爆発はメンテナーの負担を限界まで引き上げる。コミュニティの居場所をサードパーティに預けるリスクも、Cloud Native界隈がよく知る問題として顕在化した。どれも「今までのやり方では追いつかない」局面だ。

では全部作り直しかというと、そう単純ではない。OTelはデファクトの土台を延ばしてエージェント向けのセマンティックコンベンションを乗せる方向だ。PostgreSQLからClickHouseへの移行も、並行稼働で安全に段階的に切り替えている。既存の仕組みをどこまで延ばせるか、どこで作り直すか。この境界線を引く判断が実務上の鍵になる。

境界線は「放置できるか」で測れるのではないか。エージェントは放置できて初めて実用的になる。デスクトップを開きっぱなしにする前提からクラウドへの移行は、まさにそこを解消した。データストアも、スケールに対して放置できる設計かどうかが選択の基準だ。オープンソースの受け入れも、メンテナーが放置できない状態を脱する防衛線を引いている。CNCFが自前基盤を持つのも、サードパーティの都合でコミュニティを放置できないからだ。

境界線を引くタイミングは早めがいい。スケールが構成を押し潰してからの移行は痛い。コントリビューションがノイズで埋め尽くされてから防衛機能を足すのも遅い。前提が揺らぎ始めたら、延ばす部分と作り直す部分の切り分けを早く見極める。ただしAgent Healthのベンチマークが通ったエージェントが本番で安定する保証はないように、作り直した先にも新たな不確実性は生まれる。境界線を引くこと自体が正解ではなく、引いた先で何が残るかを常に見張る必要がある。

参照記事

記録日: 2026-07-08