【AIエージェントのオブザーバビリティ】エージェント監視 開発者ガイド
Article by: Sergiy Dybskiy 「エージェントのオブザーバビリティのベストプラクティス」を謳うコンテンツのほとんどは、2019年のコンプライアンスチェックリストの「マイクロサービス」という部分を「AI」と貼り替えただけのようなものです。「包括的なロギングを実装する」「評価メトリクスを確立する」「ガバナンスフレームワークを構築する」など、コードは一行も出てこず、エージェントが3ターン目にこっそり間違ったツールを選んでしまったとき、なぜそうなったかを突き止める方法にも一切触れていません。 エージェント監視に必要なものは2つです。すべてのエージェントで何が起きているかを示すダッシュボードと、特定の実行でなぜ問題が起きたかを正確に示すトレース。ほとんどのツールはどちらか一方しか提供しません。両方を持っている場合どうなるか、見ていきましょう。 エージェントのオブザーバビリティとは何か エージェントのオブザーバビリティとは、AIエージェントの動作をエンドツーエンドで可視化することです。どのモデルを呼び出しているか、どのツールを実行しているか、各ステップでどんな意思決定をしているか、そしてその決定が最終的な出力にどう影響しているかを把握できます。 従来のアプリケーション監視はリクエスト、エラー、レイテンシを追跡します。各リクエストが独立したステートレスなHTTPサービスではそれで十分です。 しかしAIエージェントは異なります。単一のエージェント実行には、複数のLLM呼び出し、ツールの実行、サブエージェントへのハンドオフ、マルチターンの推論ループが含まれることがあり、これらすべてが互いに依存し合っています。出力が誤っていた場合、その連鎖のどこかに失敗が潜んでいる可能性があります。ツールからの不正なレスポンス、コンテキストウィンドウのオーバーフロー、モデルによる間違った関数の選択、ハンドオフでのステート消失など、原因はさまざまです。 従来の監視がAIエージェントで機能しない理由 標準的なAPMツールは「POST /api/chat が4.2秒で200を返した」とは教えてくれます。しかし、そのリクエストの中でエージェントが5回LLMを呼び出し、3回目に間違ったツールを選択し、そのツールが古いデータを返し、モデルがそのゴミを律儀に要約したというようなことは教えてくれません。 「とにかく全部ログに残して後で考える」という監視方針であれば、カウントと平均値で埋まったダッシュボードができ上がるだけで、深く掘り下げる手段はありません。間違った答えを返したエージェントは、12回LLMを呼び出し、4つのツールを実行し、サブエージェントにハンドオフしてからゴミを生成していたかもしれません。集計メトリクスはエラーレートが上がったことは教えてくれても、推論のどこでおかしくなったかは教えてくれないのです。 必要なのは、標準的な規約に基づいて設計された構造化トレースです。ダッシュボード、トレース、アラートがすべて同じ言語で話せるようになります。 エージェントオブザーバビリティのOpenTelemetry標準 OpenTelemetryの gen_ai セマンティック規約は、AIエージェントシステムのインストゥルメンテーション標準を定義しています。カスタムロギングの代わりに、すべてのAI操作が一貫した属性セットを持つ構造化スパンを生成します。規約で定義されたコアオペレーションは以下の通りです。 スパンオペレーション 何をキャプチャするか gen_ai.request 単一のLLM呼び出し：モデル、プロンプト、レスポンス、トークン数 gen_ai.invoke_agent エージェント実行のフルライフサイクル：タスクから最終出力まで gen_ai.execute_tool ツール/関数呼び出し：名前、入力、出力、実行時間 これらはスパンツリーとして構成されます。 これはプロプライエタリな仕様ではなく、オープン標準です。この規約に従うオブザーバビリティプラットフォームであれば、どれでもこれらのスパンを取り込むことができます。スパンのopは gen_ai.{operation_name} というパターンに従います。手動インストルメンテーションの場合、gen_ai.request がすべてのLLM呼び出しをカバーします。SDKによる自動インストルメンテーションでは、呼び出されるAPIに応じて gen_ai.chat や gen_ai.embeddings といったより具体的なopが生成されることもあります。これらは非構造化ログではなく構造化スパンであるため、ダッシュボードとトレースビューの両方を活用できます。 AIエージェント監視の主要メトリクス ツールの話に入る前に、本番環境のAIエージェントで追跡すべき指標を整理しておきましょう。 信頼性メトリクス エージェントエラー率 — 失敗またはエラーを返したエージェント実行の割合 ツール失敗率 […]
【OpenTelemetry】既存トレースをSentryに送信
Article by: James W. アプリにOpenTelemetryを組み込むのに何ヶ月も費やしてきたはずです。それを新しい可観測性バックエンドに移行するためにすべてやり直すという選択肢は現実的ではありません。 SentryのOTLPエンドポイントを使えば、その必要はありません。実際のところ、必要なのは環境変数を2つ設定するだけで、既存のトレースがSentryのトレースエクスプローラーに表示されるようになります。 SentryのOTLPサポートは現在オープンベータです。つまり、すぐに利用を開始できますが、いくつかの既知の制限があります（これについては後ほど説明します）。 なぜOTLPなのか：計測はそのままに、送信先だけを変更する OpenTelemetryを使用する最大の利点は、計測がベンダーに依存しないことです。計測コードはOpenTelemetryの標準APIを使用し、OTLP（プロトコル）はそのデータを対応する任意のバックエンドに送信します。つまり、いくつかの設定を変更するだけで、いつでも可観測性バックエンドを切り替えることができます。 次のような場合に特に有効です。 すでにOpenTelemetryエコシステムに大きく投資している場合 計測の柔軟性を維持したい、またはスタックの他の部分ですでにOpenTelemetryを使用している場合 一方で、ゼロから始めてSentryのみを使用する場合は、ネイティブのSentry SDKの方が、すべてのSentry機能（spanイベント、Session Replay、プロファイリングを含む）を完全にサポートしています。OTLPサポートはまだベータであり、いくつかの制限があります。本ガイドの後半で両者を比較します。 前提条件 開始する前に、以下が必要です。 Sentry アカウント（無料プランで問題ありません） Node.js 18以上がインストールされていること Express.jsの基本的な知識 まだSentryプロジェクトを作成していない場合は、ここで作成してください。作成時にはプラットフォームとしてExpressを選択します。DSNの設定手順はスキップして構いません。代わりにOTLPエンドポイントを使用します。 SentryのOTLP認証情報を取得する Sentryはプロジェクトごとに専用のOTLPエンドポイントを提供しています。 取得方法は以下の通りです。 左側のサイドバーでSettingsをクリックします。 SettingsサイドバーのOrganizationセクションでProjectsをクリックします。 一覧から対象のプロジェクトを見つけてクリックし、プロジェクト設定を開きます。 プロジェクト設定のサイドバーで、SDK Setupセクション内のClient Keys（DSN）をクリックします。 OpenTelemetryタブを選択し、ExpandボタンをクリックしてすべてのOTLPエンドポイントの値を表示します。 Sentry UIで「Settings > Client Keys（DSN）> OpenTelemetry」タブを開き、OTLPエンドポイントが表示されている画面 このタブは開いたままにしておいてください。次のステップで以下の値を使用します。 […]
【Next.js】ロギングが難しい理由と解決策
Article by: Kyle Tryon 一般的なNext.jsのデプロイでは、最大で3つの異なるランタイム（Edge、Node.js、ブラウザ）でコードが実行される可能性があります。 サーバーサイドのコードからログをすでに取得しているかもしれませんが、ミドルウェアからサーバーレンダリング、そしてブラウザに至るまでのリクエスト全体を取得していない場合、問題が発生したときに多くのデバッグ情報を見逃していることになります。 要約：一般的なNext.jsのデプロイは、Node、Edge、ブラウザという最大3つの環境で実行されます。ほとんどのJavaScriptのロギングライブラリはNodeを対象としており、Edgeやブラウザに対応しているものははるかに少ないです。LogTapeとSentryはいずれも、ランタイムに依存しないJavaScriptのロギングを提供します。 なぜNext.jsでのロギングは難しいのか 課題 1：多くのロガーはNode.jsを前提としている 多くのロガーはNode.js専用に構築されており、ブラウザやEdgeランタイムでは利用できないAsyncLocalStorageやfsのようなAPIに依存しています。 Next.jsに最適なロガーとしてPino（またはNext-Loggerのようなラッパー）が推奨されることがよくありますが、実際にはどちらもNext.jsにとって良い選択ではありません。 Pino、ひいてはNext-LoggerはNode.js向けに設計されており、ブラウザで動作させるためにポリフィルを使用しています。しかしそのポリフィルにより、Nodeでのパフォーマンス上の利点は失われ、さらにEdge関数やミドルウェア（Edge上で実行される）ではログを取得することができません。 課題 2：クライアントサイドのロギングが欠落する クライアントサイドのログを取得する必要はないと考えがちです。なぜなら「フロントエンドのコード」はすべてサーバーサイドで動作していると思われがちだからです。 デフォルトでは、Next.jsはすべてのページとコンポーネントにServer Componentsを使用します。そのため、デフォルトでは「フロントエンドのコード」から出力されるログは、実際にはサーバーサイドのログとして取得されます。 しかし、インタラクティブなコンポーネントのためにuse clientの境界を追加すると、そのコードはブラウザで実行されるようになります。 「フロントエンドのコード」は、1つのページをレンダリングするために連携して動作するServer ComponentsとClient Componentsの混在であり、それぞれ異なる場所にログを出力します。 この分断を解消し、どこで実行されるかに関わらず、すべてのフロントエンドコードのログを同じ場所に集約する必要があります。 課題 3：トレースと結びついた構造化ロギング ロギングは可観測性の一部にすぎず、それ単体ではローカルでのデバッグ時に最も有用です。本番環境では、数十、数百、あるいは数千のリクエストからログを収集するようになると、関連するログ同士を結び付けて検索・集約する手段が必要になります。 トレーシングはアプリ内の各リクエストに一意のIDを付与し、そのIDを構造化データとしてすべてのログに付加します。これにより、後からそのIDに基づいてログを検索し、同一リクエストに関連するすべてのログを、Sentryのエラーなど他のテレメトリデータとあわせて確認することができます。 Next.jsへのトレーシングの導入自体は実際には簡単ですが、それでも実施すべきステップであり、いくつかの方法が存在します。 ここでは、JavaScriptのロギングライブラリとSentryを組み合わせて、トレースに紐づいたログをNext.jsに計測として組み込みます。別の記事では、OpenTelemetryを使用した別のトレーシング導入方法について解説・比較する予定です。 Next.js用のロガーに求めるべき要件 ロガーは何を満たすべきでしょうか。私は最近、主要なJavaScriptロギングライブラリを比較し、そもそもなぜロギングライブラリを使うべきなのかを整理しました。基本的な考え方はNext.jsでも同様ですが、より具体的に考える必要があります。 ランタイム対応：Node、ブラウザ、そして（Edgeを使用する場合は）Edgeランタイムで動作する必要があります。 トレーシング対応：Next.jsアプリはデフォルトでマルチサービス構成です。トレーシングにより、複数のソースからのログを単一のトレースに紐づけることができます。 本番向け機能：データのマスキングやノイズ削減のためのフィルタリング、コンテキスト管理や子ロガーによる構造化ロギングの強化、および後の検索・集約の容易化。 想像できる通り、機能面では各ライブラリは互いの優れた実践を取り入れ、似通ってきています。 それでもなお注目すべき最大の違いは、ランタイム対応とパフォーマンスです。 Next.jsアプリ全体をカバーできる現実的な選択肢は2つあり、これらは排他的ではありません。 LogTape（Sentryシンクと組み合わせる） Sentry.logger（Sentry Next.js SDKと組み合わせる） LogTape […]
【Next.js】オブザーバビリティのギャップと解消方法
Article by: Sergiy Dybskiy このブログは、最近実施されたライブワークショップに基づいています。YouTubeでフルのライブ配信を視聴できます。 Next.js は多くの機能を当初から提供しています。サーバーサイドレンダリング、ファイルベースルーティング、エッジランタイムなどです。しかし、実際に本番環境で何が起きているのかを明確に把握する手段は提供していません。フレームワークの3つのランタイム構成（クライアント、サーバー、エッジ）により、エラーがあるレイヤーで発生しているように見えても、実際には別のレイヤーに起因していることがあります。また、データベースクエリはORMの抽象化の背後に隠れ、サーバーアクションは有用なエラーメッセージをブラウザに到達する前に飲み込んでしまいます。 本記事では、Next.jsアプリにおけるいくつかの具体的なオブザーバビリティ（可観測性）のギャップ、それらが存在する理由、そしてSentryを用いてそれらをどのように解消するかについて説明します。 要約 Next.js の本番ビルドでは、サーバーアクションからエラーの詳細が削除されます。クライアント側には「サーバーコンポーネントのレンダリング中にエラーが発生しました」とだけ表示され、コンテキストは一切提供されません。Sentryは完全なスタックトレース付きで元のサーバーサイド例外をキャプチャします。 Hydrationエラーは、Reactにおいて最も一般的でありながら最も役に立たないエラーのひとつです。SentryはHTMLの差分ビューを提供し、サーバーとクライアントのレンダリング間でどのDOMノードが不一致だったのかを正確に示します。 ログとメトリクスはトレースのようにサンプリングされません。tracesSampleRateの設定に関係なく、データは100%取得されます。データの欠落を避けたい場合はこれらを使用してください。 サーバーアクションはOpenTelemetryのスパンを生成しないため、トレースに表示させるにはwithServerActionInstrumentationを使用した手動のインストルメンテーションが必要です。 DrizzleのようなORMを通じたデータベースクエリは、デフォルトではトレーシングに表示されません。データベースクライアント（例：TursoのlibSQL）のインテグレーションを追加することで、すべてのクエリをスパンとして可視化できます。 Vercel AI SDKとのインテグレーションによるAIエージェントのモニタリングでは、モデルごとのトークン使用量、コストの内訳、ツールコールのトレースを、Sentryから離れることなく確認できます。 3つのランタイム、3つの設定ファイル Next.js は異なる環境でコードを実行します。Sentryのウィザードを実行することで、セットアップを開始できます。 ウィザードはそれぞれの環境に対して個別の初期化ファイルを作成します。ブラウザ用の instrumentation-client.ts、Node.js 用の sentry.server.config.ts、そしてエッジランタイム用の sentry.edge.config.ts です。 これにより、各ランタイム向けの設定ファイル、グローバルエラーバウンダリ（global-error.tsx）、そして withSentryConfig によってラップされた next.config.ts が生成されます。next.config.ts のラッパーは、可読性のあるスタックトレースのためのソースマップのアップロードを処理し、さらにトンネルルーティングを設定します。これは広告ブロッカーを回避するために、Sentryのデータを自分のサーバー経由で送信する仕組みです。 設定に関していくつか注意点があります。 サンプルレートは重要です。開発環境では tracesSampleRate を 1.0 に設定し、本番環境では 10〜20% に設定します。これを高くしすぎると、クォータを急速に消費します。 sendDefaultPii はリプレイやイベントにユーザーのIPアドレスを付与します。必須ではありませんが、セッションを実際のユーザーと関連付けるのに役立ちます。 エッジの設定は異なる場合があります。ミドルウェアがリクエストの再ルーティングのみを行う場合、ノイズを減らすためにエッジ設定でトレーシングを無効にしても問題ありません。 セットアップに関してもう一点あります。認証後に一度 Sentry.setUser() を呼び出すことで、エラー、ログ、トレース、リプレイ全体にユーザーコンテキストを伝播させることができます。 […]
【SeerがSeerを修正】Seerがバグの場所を示し、障害の修復に役立った方法
Article by: Kush Dubey Seerはバグを受け取り、Sentryが持つあらゆるコンテキストを使って根本原因を特定し、修正案を提案するAIエージェントです。私たちはこれを日常的に使い、Sentryの改善に役立てています。SeerはSentryを修正します。 最近では、Seerは自分自身の修正にも役立っています。つまりSeerがSeerを修正する、ということです。 ある上流の障害が連鎖的な影響を引き起こし、数か月間潜んでいたバグを露呈させました。修正する段階になったとき、Seerは私たちが見るべき場所を正確に指し示しました。 警報が鳴る 2026年2月21日、SeerのAIによるIssueサマリー機能がEUリージョンで停止しました。 SeerのIssue Summary APIエンドポイントへのリクエストの約80〜90%が失敗しており、その結果、すべての新しいSentry Issueにおいて「AI Summary」カードが壊れた状態になっていました。アクショナビリティスコアは表示されず、自動Autofixの実行も行われませんでした。そして40,000件以上のエラーが流入しました。 このような事態を引き起こすような変更は直近で行っていなかったにも関わらず、なぜ今起きたのでしょうか。 原因は上流の問題でした。SeerのAIサマリーはGoogle Cloud Platform（GCP）のVertex APIを通じて、gemini-2.5-flash-lite上で動作しています。GCPは後に、複数のEUリージョンにおけるgemini-2.5-flash-liteの可用性に関するインシデントを公表しました。 しかし、それは本来であれば軽微な性能低下にとどまるはずでした。なぜなら、Vertex AIでスループットを確保しており、その約12%しか使用していなかったからです。 管理可能な上流の可用性問題を完全な障害へと変えてしまったのは、私たち自身のコードでした。失敗するリージョンをスキップするために構築したレイテンシ最適化により、EU内のすべてのGeminiリージョンがブロックリストに登録されてしまい、保証されたキャパシティを持っていたリージョンまでも含まれてしまいました。 SeerがEUでLLMコールをどのようにルーティングするか 前述のとおり、SeerはGCPのVertex AIを通じてgemini-2.5-flash-liteを実行しています。EUデプロイでは、europe-west1にプロビジョンドスループット（PT）を確保しており、これによりVertex AI全体の需要が急増した場合でも、予約されたキャパシティを利用できます。 その他の複数のEUリージョンでは、Standard pay-as-you-go（Standard PayGo）を使用しています。Standard PayGoはベストエフォート型のキャパシティであり、Googleが過去30日間のVertex AIの総利用額に基づいてクォータを設定しますが、需要が急増した場合の保証はありません。 SeerのLLMクライアントは、一時的なブロックリストを伴うリージョンフォールバックを実装しています。短時間のうちに1つのリージョンで6回の対象となる失敗が発生した場合、そのリージョンは一時的にローテーションから除外されます。この機能はレイテンシに敏感なサービスにとって重要です。というのも、429や504のレスポンスは通常2〜4秒かかって返ってくるためです。50〜100回のLLMコールを行うインタラクティブなAutofixセッションでは、これらの遅延が積み重なります。 このシステムには重要な不変条件があります。PTリージョンを決してブロックリストに登録してはいけない、ということです。ここは保証されたキャパシティであり、これをブロックリストに登録することは、負荷を処理するために料金を支払っている唯一のリージョンを放棄し、処理能力を持たないリージョンにすべての負荷を押し付けることを意味します。 この障害によって、これまで潜んでいたバグが明らかになりました。私たちはこの不変条件をUSデプロイでは適用していましたが、EUデプロイには追加し忘れていました。 連鎖 私たちのPTリージョンであるeurope-west1は、Google側でモデルが断続的に利用できなかったため、504 Deadline Exceededエラーを返し始めました。 短時間に6回の失敗が発生するとブロックリストの閾値を超えるため、europe-west1は頻繁にローテーションから除外されるようになりました。 europe-west1がブロックリストに登録されると、すべてのトラフィックがStandard PayGoリージョンへと移動しましたが、それらは全負荷を処理できるようにはプロビジョニングされていませんでした。europe-west4は429 RESOURCE_EXHAUSTEDを返し始めてブロックリストに登録され、続いてeurope-central2も同様になり……という流れになりました。数分以内に、クライアントはEU内のすべてのリージョンを順にブロックリストに登録し、その後のすべてのコールはLlmNoRegionsToRunErrorを返すようになりました。使用可能なリージョンが一つも残っていなかったのです。 GCPのインシデント中であっても、europe-west1へのコールの大半は成功していました。これは、プロビジョンドスループットが負荷を吸収していたためです。しかしブロックリストは成功率に関係なく6回の失敗で発動するため、大半のリクエストを正常に処理していても、たまたま6回の失敗が集中すれば、そのリージョンは除外されてしまいました。 修正はPTリージョンがブロックリストに登録されないようにするallowlistにeurope-west1を追加することでした。これをデプロイしてから数分以内に、失敗率はベースラインに戻りました。 コードの問題 […]
【Sentry SDK】アップグレードが必要な状態かもしれません
Article by: Sergiy Dybskiy Session Replay、Structured Logs（構造化ログ）、AI Monitoring（AIモニタリング）、Automatic OpenTelemetry Tracing（自動 OpenTelemetry トレーシング）、Feature Flag Tracking（フィーチャーフラグトラッキング）。もしこれらをあなたの Sentry ダッシュボードで見かけていないなら、その理由はおそらく SDK のバージョンにあります。 @sentry/react、@sentry/nextjs、@sentry/vue、@sentry/angular、@sentry/sveltekit、あるいはその他の @sentry/* パッケージのいずれを使っていても、これらはすべて同じバージョンで管理されています。v10 はそれらすべてを指しています。 ここで重要なのは、npm のダウンロード数に基づくと、Sentry の JavaScript SDK のインストールの約半分が、いまだに v8 もしくはそれ以前にとどまっているという点です。 データ 主要な @sentry/* パッケージについて、npm のダウンロード統計を取得しました。2026年3月時点での週間インストール数は以下の通りです。 パッケージ 週間合計 v7のまま v7 + v8 合計 @sentry/node 14.9M 4.8M (32%) 7.3M (49%) @sentry/browser 14.5M 3.2M […]
【JavaScriptロギングライブラリの選び方】2026年決定版ガイド
Article by: Kyle Tryon AIがますます多くのコードを書くようになるにつれて、そのコードを適切に監視し、デバッグすることは、開発ワークフローにおいて無視できない重要な要素となっています。幸いなことに、そのための対応に適したツールを導入する時間は、これまで以上に確保しやすくなっています。 本番環境に対応したロギングソリューションの実装は容易であり、アプリケーション全体にわたって、ユーザーや環境を横断した豊富なデバッグ情報を、開発者およびLLMエージェントにもたらします。 なぜロギングライブラリが必要なのか もしデバッグにまだconsole.logを使っているのであれば、なぜロギングライブラリを使う必要があるのか疑問に思うかもしれません。 高パフォーマンスロギングライブラリは非同期で動作するため、ネイティブのconsoleログよりも高いパフォーマンスを発揮します。 構造化された出力文字列ではなく構造化オブジェクトとして出力でき、追加のコンテキストや子ロガーの管理を簡素化します。 トランスポートとシンクコンソール、ファイル、ストリーム、オブザーバビリティプラットフォームなど、1つまたは複数の宛先にログを送信できます。 フィルタリング重大度、カテゴリ、その他の条件でログをフィルタリングし、ノイズを削減できます。アプリケーション外に出る前に機密データをマスキングすることも可能です。 統合Webフレームワーク、ORM、その他のライブラリと統合することで、アプリケーションのすべてのレイヤーにわたり、一貫したAPIでコンテキストやエラーを自動的に記録できます。 トレース連携ログSentryでは、ログがエラーやその他のイベントと自動的にトレースで結び付けられ、デバッグや問題の相関関係の把握が容易になります。 ロギングライブラリの選定 主要な4つのライブラリをひと目で比較できるようにまとめました。 ライブラリ バージョン ランタイム リリース トランスポート／シンク Minified + gzip 依存関係数 ツリーシェイク可能 Pino 10.2.0 Node 2016 ✓ 3.3 KB 11 ❌ Winston 3.17.0 Node 2010 ✓ 38.3 KB 17 ❌ Bunyan 2015年8月1日 Node […]
AI時代における Fair Source Software
Article by: Chad Whitacre, Gavin Zee 最近、AIの存在を感じていますか？ええ、もちろん私たちもです。生成AIはソフトウェアの既存の前提を揺るがしており、それはライセンスにも及びます。そして当然ながら、さまざまな「意見」を生み出しています。 Sentry はソフトウェアライセンスについて長い間、明確な考えを持ってきました。2008年には無ライセンスのサイドプロジェクトとして始まり、その後 BSD、BSL へと移行し、独自ライセンスである FSL を策定しました。 そして直近では2024年、私たちは Fair Source を立ち上げました。これはソース公開型ライセンス（ FSL を含む）の中で「シンプルな非競争条項」と「最終的なオープンソース化」を両立させる、新しい業界ポジションを確立するためのものです。Fair Source の採用は現在拡大しています。 では、AIによって何が起きているのでしょうか。そしてソフトウェアライセンスにはどのような影響があるのでしょうか。特に Fair Source は今でも意図通りに機能しているのでしょうか。また企業にとって安全な選択肢であり続けているのでしょうか。 結論から言えば「はい」なのですが、詳しくご紹介いたします。 新しいAIの転換点 Andrej Karpathy の言葉を借りれば、この変化は「通常の進歩のように徐々に起きたのではなく、まさに昨年12月に起きた」ものです。 2025年の最新世代AIモデル（11月24日の Opus 4.5、12月11日の Codex 5.2）は、初めて「単体のエージェントとして依存可能なレベル」に到達しました。 これにより、VS Code や Cursor のような従来の IDE 内での高度なオートコンプリートではなく、Claude Code や OpenCode のような環境で独立したエージェントとして動作することが可能になりました。 さらに、オープンソースのAIパーソナルアシスタントである OpenClaw が爆発的に普及しました。これは「vibe-coding（コードを読まずに出荷する）」の現実性と、「コードを書く以上のことをエージェントに求める需要」の両方を示しています。 リリースからわずか3ヶ月で、OpenClaw は […]
OTLP を使って OpenTelemetry のログを Sentry に送る方法
Article by: James W. もしすでに OpenTelemetry でアプリを計装しているなら、Sentry を使うためにわざわざ外す必要はありません。環境変数を2つ設定するだけで、Logs を Sentry に送れるようになります。SDK の変更も再計装も不要です。この記事では、サンプルアプリでの設定方法とネイティブ Sentry SDK を使うべきケースについてご紹介します。 なぜネイティブ SDK ではなく OTLP を使うのか OTLP の主な利点は、ログ記録のコードを特定のオブザーバビリティ基盤から切り離したままにできることです。数行の設定を変更するだけで、ログの送信先を切り替えられます。 次のような場合に役立ちます。 すでに OpenTelemetry によるロギングを導入している ログを複数のバックエンドに送りたい ベンダー中立な計装が必要である OpenTelemetry をデフォルトで使用する AI や LLM のフレームワークを扱っている より広い OpenTelemetry のエコシステムを活用したい 一方、ゼロから導入するのであれば、必要なのが Sentry のみの場合は ネイティブの Sentry SDK のほうが適しています。ネイティブ SDK では、Logs からの Issue 作成、Session Replay […]
React Native SDK 8.0.0 が登場
Article by: Antonis Lilis React Native SDK 8.0.0 をリリースしました。 新機能と変更点をご紹介します。 前回のメジャーバージョンからしばらく経ちました。前回のメジャーリリースである 7.0.0 は 2025年9月2日 にリリースされています。マイナーリリース 13回 とパッチリリース 2回 を経て、ついに新しいメジャーバージョン 8.0.0 の登場です。今回のバージョンは、メンテナンスと機能拡張を目的としたメジャーリリースです。 具体的には以下を行いました。 ネイティブ初期化によるアプリ起動時エラーのキャプチャを追加 主要なネイティブ依存関係をアップグレード 最小バージョン要件を引き上げ アップグレードは概ねスムーズなはずですが、環境に応じて移行ガイドをご確認ください。 知っておきたい変更点 バージョン8の変更の多くは2つに大別できます。新機能と依存関係の更新です。 要点は以下のとおりです。 アプリ起動時エラーのキャプチャ Sentry は React Native ブリッジのセットアップ、バンドルのロード、ネイティブモジュールの初期化の最中に発生するクラッシュやエラーを、いまではキャプチャできます。JavaScript 側で Sentry.init() が実行された後だけでなく、その前の段階も対象です。従来のバージョンでは、これを実現するには複雑な設定やネイティブ初期化の手動対応が必要でした。 バージョン8では sentry.options.json 設定ファイルと新しいネイティブ API を使って、ネイティブ層で Sentry を初期化できます。これにより、アプリのライフサイクルの最初から、アプリ起動時のエラーやネイティブクラッシュを SDK がキャプチャできます。詳細は React Native […]