Generated by All in One SEO v4.9.10, this is an llms.txt file, used by LLMs to index the site.

# Ichizoku

Transform Your Company With AI

## Sitemaps

- [XML Sitemap](https://ichizoku.io/sitemap.xml): Contains all public & indexable URLs for this website.

## Posts

- [「AI-PAX 2026 大阪」出展のお知らせ](https://ichizoku.io/ai-pax-2026-osaka-ichizoku/) - Ichizoku株式会社（本社：東京都港区、代表取締役社長：Jay Revels）は、2026年10月29日（木）30日（金）にグランフロント大阪で開催される「AI-PAX 2026 大阪［第1回 AIの実践的な活用展］」に出展します。 Ichizokuは、企業を限定的なAI活用から、構造化されたデジタルインテリジェンスとエージェント型ワークフォースの導入へと導く、デジタルインテリジェンス企業です。 AIエージェントの設計・デバッグ・導入支援から、導入後のパフォーマンスを継続的に把握・改善するオブザーバビリティ、社内でAIを活用・運用していくための人材育成と内製化まで、一貫して支援します。 Ichizokuのブースでは、次のような課題についてご相談いただけます。 生成AIを導入したものの、実証実験や限定的な利用にとどまっている 自社の業務に適したAIエージェントを設計・導入したい AIエージェントの精度や品質、導入後のパフォーマンスに不安がある 複数のAIエージェントが連携するエージェント型ワークフォースを構築したい AI活用を一部の担当者に依存させず、組織全体に定着させたい AIを活用・運用できる人材を育成し、将来的な内製化につなげたい 事前予約制で、具体的な課題をご相談いただけます AI-PAXは、来場者が関心のある出展企業のブースを事前に予約し、着席して相談できます。Ichizokuのブースでも、皆さまが現在抱えている課題やAI活用の状況を伺いながら、落ち着いた環境で具体的なご相談をお受けします。 AI導入を検討されている方、AIを事業価値へとつなげたい方は、ぜひ事前にIchizokuのブースをご予約ください。 開催概要 ※イベントへの参加申込後、来場ガイドブックから別途ブースの訪問予約が必要です。 お問い合わせ先Ichizoku株式会社広報担当:竹内 美稀 (Miki Takeuchi)メール: miki.takeuchi@ichizoku.io
- [Tokenmaxxing はROIを生んでいるのか？AIデプロイ計画にオープンソースモデル戦略が欠かせない理由](https://ichizoku.io/open-source-ai-model-strategy-token-cost-roi/) - By Jay Revels, Ichizoku株式会社 CEO 本記事は、エンタープライズAIのトークンコスト急騰の実態とジェボンズのパラドックス的構造を分析し、オープンソースモデル戦略とハイブリッドアーキテクチャによってAI投資のROIを守る方法を解説します。 重要なポイント 運用費の比重が人件費からトークンコストへとシフトする中、レベルごとに異なる組織のボトルネック フロンティアモデルの価格低下にもかかわらず、使用量の拡大・複雑性の増大・プレミアムモデルへのデフォルト集中により、総支出は高水準のまま モデルの適正化・オープンソースモデルの活用・タスクあたりのコスト計測によるトークン経済の能動的マネジメントが勝者の条件 OpenAI・Anthropicの最先端パワーの活用と、長期利益率を守る堅牢なセルフホスト型オープンソースフレームワークの同時構築 現在のエンタープライズ市場には、適切な管理を伴わないAI実験の失敗によって生じた数多くの投資損失が散在しています。オープンソースモデル戦略が、なぜ長期的な収益性と競争優位を実現するうえで不可欠なのかを理解するためには、まず経営幹部を踏みとどまらせている「思い込み」を検証する必要があります。 最大の思い込み：トークン価格はゼロに向かう クローズドソースAPIへの依存戦略（OpenAIやAnthropicの利用）を正当化する際に最もよく聞かれるのが、「トークン価格は下がり続ける」という主張です。ハイパースケーラー間の競争やハードウェア性能の向上によって、トークン価格は今後も下がり続けるため、OpenAI・Google・AnthropicのAI能力を利用する方が、オープンソースモデルを自社環境でホスティングし、チューニング・運用するよりも安価になるという理論です。 しかし、この考え方はジェボンズのパラドックスを見落としています。ある資源が安価になり効率が向上すると、その資源の利用量は減るどころか、むしろ総消費量が大幅に増加するという現象です。 コストは本当に下がるのでしょうか。モデルの価格は世代ごとに約10分の1のペースで下落しているため、期待は理解できます。しかし実際に、タスクあたりのコストはほとんど変わっておらず、その背景には、価格低下を相殺する3つの力が働いています。 第一に、企業は常に最新のフロンティアモデルへ移行するという現実です。新しいClaudeやGPTがリリースされれば、最新モデルに移行し、「旧モデルで十分だからコストを抑えよう」とは考えません。旧世代モデルの価格は下がっても、最新モデルはいつでも高額となります。（下記参照） 第二に、クエリあたりのトークン消費量の増大です。エージェントはツール呼び出しのオーケストレーション、エラー修正、コンテキストの読み込みなど、複雑なマルチステップ業務を担うようになっています。高度なモデルほど、より難しい問題に対して多くのトークンを消費します。 第三に、利用範囲そのものが拡大します。チームがエージェントの有効性を実感すると、次々と新たな業務へ適用し始めます。 各パフォーマンス層のコストは下がっても、ユーザーはより高性能なフロンティアモデルへと移行するため、全体の支出水準はほぼ横ばいで推移するでしょう。 現実を直視する2026年：予算が数ヶ月で消える これは理論上のリスクではありません。市場全体のエンタープライズ導入事例から得られた財務データは、サードパーティAPIへの過度な依存が、企業の予算管理モデルそのものを破綻させ得ることを示しています。 Uberは、2026年のAI予算全額を4月までに使い果たしました。わずか4ヶ月で数十億ドルの資本を消費したことになります。 Microsoftは、社内で導入していたClaude Code開発者ライセンスの大半をキャンセルせざるを得ませんでした。ツールの利用によって発生したコンピュートコストが、それによって生産性向上を図るはずだったエンジニアの人件費を上回ったためです。 Zillowは、2026年第1四半期だけでAIトークンに100万ドル超を費やしました。このペースが続くと、年間利益の最大20%をトークンインフラに費やす計算になります。 OpenRouterのテレメトリによると、週次のトークン処理量は2026年半ばまでの15ヶ月間で0.4兆から27兆へと急増しており、68倍という驚異的な増加を記録しています。 エンタープライズソフトウェアはこれまで、ユーザー数に応じた予測可能なシート課金モデルによって運用されてきました。一方、生成AIは利用量に応じてコストが加速度的に膨らむ非線形のトークン課金モデルで動きます。モデルの重みを保有せず、基盤インフラをコントロールできない限り、コストリスクは際限なく拡大します。 根本的な病：エージェントループにおけるTokenmaxxingと利用ガバナンスの欠如 こうした予算超過の根本にあるのが、Tokenmaxxing（トークンマックス）と呼ばれる組織的な悪習です。これは、ガバナンスやインテリジェントなルーティングロジックを持たない企業システムが、あらゆるタスクに対して最も高性能かつ高価なフロンティア推論モデルを無条件に使い続けることで生じます。 基本的なチャットボットから高度なエージェントAIへ移行すると、トークン消費は単発のプロンプト処理から、複雑な反復推論ループへとシフトします。マルチターンの業務フローを実行するエージェントは、次のような処理を繰り返します。 1. 巨大なシステムプロンプトを読み込む 2. 多数の外部ツールやスキーマ定義（MCPサーバーなど）を取り込む 3. ツール呼び出し、自己評価、エラー修正の再帰ループを実行する その結果、1回のリクエストで消費されるトークン量は、数百トークンから15万トークン規模へと容易に膨れ上がります。フロンティアAPIを通常料金で利用し続けることは、増え続ける変動コストを、そのままサプライヤーの利益に注ぎ込んでいるようなものです。 オープンソースは粗利率改善の突破口 AIネイティブソフトウェアを取り巻く経済環境は厳しいものがあります。従来のSaaS企業が75〜85%の高い粗利率を維持している一方で、AIネイティブアプリケーションの平均粗利率は52%にとどまり、推論コストが売上高の約23％を占めています。 この「トークン税」から逃れる現実的な手段が、オープンソースモデル戦略の構築です。実際に、先進的な技術組織はどのように収益性を確保しているのでしょうか。 プライベートインフラへの転換：企業がレンタル型のSaaS APIへの依存から脱却し、Llamaエコシステム、Mistral、Moonshot AIといったオープンソースモデルを自社環境で運用するようになると、収益構造そのものが変化し、コスト構造は変動費中心のモデルから、予測可能な固定資産中心のモデルへと移行。 成功事例：Cursorは外部APIへの全面的な依存から脱却し、Moonshot AIのKimiをベースにファインチューニングしたモデルを活用することで、大企業向けビジネスにおいて構造的な粗利率の黒字化を実現。 高度に最適化されたタスク特化型オープンソースモデルをプライベートクラウド上で運用することで、実行に伴う限界コストは限りなくゼロに近づきます。その結果、開発チームはコストのテレメトリダッシュボードを常に気にすることなく、大規模なコンテキストウィンドウ、マルチエージェントフレームワーク、高強度な推論ループの構築に集中できるようになります。 プレミアムモデルの強みとスケール時の課題 まず明確にしておきたいのは、独自のフロンティアモデルはソフトウェアエンジニアリングの傑作だということです。高度な戦略的推論、越境コンプライアンスのマッピング、オープンエンドな創造的統合といった複雑で曖昧なタスクにおいては、OpenAI・Claude・Geminiが持つ最高水準の認知能力は欠かせません。 しかし、基本的なデータ抽出やテキスト要約、ルーティング処理にまで数十億ドル規模のフロンティアモデルを使うのは、フェラーリで食料品を配達するようなものであり、資本の無駄遣いにほかなりません。 企業での利用が小規模な試験導入から数千規模の自動化業務フローへと拡大すると、API依存型のアーキテクチャには次のような構造的な課題が生じます。 1. 際限なく膨らむ変動コスト 運営利益率が、サードパーティの利用量に応じた価格体系に完全に左右されるようになる。 2.
- [FDEサービスを提供するAIベンダーの選び方](https://ichizoku.io/fde-vendor-selection-ai-architecture/) - By Jay Revels, Ichizoku株式会社 CEO 本記事は、Forward Deployed Engineer（FDE）サービスを提供するAIベンダーを選定する際に、SaaSプロダクト型とレガシーコンサルティング型それぞれに潜む構造的な落とし穴と、粗利率を守るソブリンなAIアーキテクチャの選び方を解説します。 重要なポイント SaaSベンダーFDEのプラットフォームバイアス： FDEがセールスチームの一員として機能し、業務データが自社エコシステムに囲い込まれる構造的リスク。 レガシーSIに潜むトークンマックスの罠： コスト管理の設計原則を持たないFDEがすべての問い合わせを最上位モデルに送り続け、粗利率を複利的に圧迫する。 知能・モデルウェイトの所有権： ベンダー切り替え時にカスタマーロジックを引き継げるかが、長期的な事業自律性を左右する最重要評価軸。 粗利を守るベンダー評価の4軸： モデル所有者・トークンマックス防止策・データ不整合対応・モデル非依存性を全ベンダーに確認する。 大手エンタープライズIT企業のセールストークが、いま一斉に変わっています。Salesforceのような大手ソフトウェア企業も、大手グローバルITコンサルティングファームも、口を揃えてこう言います。 「私たちはソフトウェアやスライドを売るだけではありません。Forward Deployed Engineer（FDE）を直接お客様のオフィスに派遣し、自律型カスタマーエージェントを現場で構築します。」 背景にあるのは、ソフトウェアそのものの変化です。私たちは今、決定論的システム（ソフトウェアの振る舞いが明示的にコーディングされるシステム）から、確率論的システム（ソフトウェアの振る舞いがコンテキストと確率によって決まるシステム）への移行期にあります。確率論的AIモデルは、実運用データという泥の中でしかチューニングできません。そのため、エンジニアを最前線に送り込むことは、もはや余裕があればやることではなく、不可欠なこととなっています。 しかしこうした選択肢を評価する企業側にとって、「Forward Deployed Engineer」という言葉は実態を覆い隠すマーケティング用語と化しています。数百万ドル規模のアーキテクチャ上の落とし穴を避けるためには、FDEという肩書きだけを見るのではなく、誰が、どのようなインセンティブのもとで彼らを派遣しているのかを見極める必要があります。 2つの道：SaaSロックインか、SIの底なし沼か カスタマーエージェントインフラに関するベンダーの提案を評価する際、企業は構造的な問題を抱えた2つのビジネスモデルのいずれかを選ぶことになります。 1. プロダクト／SaaS大手（Salesforce、Oracle、Exawizardsなど） これは理論上のリスクではありません。市場全体のエンタープライズ導入事例から得られた財務データは、サードパーティAPIへの過度な依存が、企業の予算管理モデルそのものを破綻させ得ることを示しています。 提案内容：「車輪の再発明は不要です。私たちのプラットフォームエコシステムを導入すれば、プロダクトFDEがすぐに使えるエージェントを設定し、カスタマーサポートを稼働させます。」 隠れた罠：プラットフォームバイアスとマージンの取り込みプロダクト企業のFDEは、実質的にはセールスチームの一員と言えます。彼らの最大の目的は、企業のデータと業務プロセスを自社の独自エコシステムへ取り込むことです。そのため、あらゆるワークフロー上の課題に対して、新たなモジュールの追加や高収益な従量課金サービスの利用拡大によって解決策を提示する傾向があります。 結果：企業は基盤となる知能やモデルウェイトを所有できません。仮に3年後に別のプラットフォームへ移行しようとしても、そこで蓄積・最適化されたカスタマーロジックを引き継ぐことはできません。結果として、企業は完全にベンダーへ縛られることになります。 2. レガシーコンサルティングファーム／グローバルSI 提案内容：「硬直的なSaaSの制約を受け入れる必要はありません。私たちのFDEチームが最先端のAPIを活用し、エージェント基盤をゼロから独自に構築します。」 隠れた罠：工数課金モデルとTokenmaxxing（トークンマックス）コンサルティングファームの収益源は、プロジェクト工数と継続的な保守運用にあります。そのため、コスト管理を組み込んだアーキテクチャの設計原則を持たない場合、FDEは「トークンマックス」に陥りがちです。つまり、1件当たりの採算やコスト効率を十分に考慮することなく、顧客からのあらゆる問い合わせをOpenAIやClaudeといった最上位の推論モデルへ機械的に送ってしまうのです。 結果：機能するシステムは構築できます。しかし、その代償として増え続けるトークンコストが粗利率を圧迫します。企業はパブリッククラウド事業者へ、複利的に膨らみ続ける負担を払い続けることになり、さらにシステムの挙動の変化や性能低下が生じた際には、その修正をコンサルティングファームに依存し続けることになります。 ベンダー評価マトリクス：必ず確認すべき4つの質問 ベンダー選定の場でFDEに関する誇大な売り文句を見抜くには、すべてのベンダーに次の4つの質問を必ず投げかけるべきです。 Ichizokuの差別化：粗利率にこだわるコンテキストエンジニア この比較が示す通り、Ichizokuはまったく異なる種類のエンジニアリング支援モデルを採用しています。私たちは、FDEをソフトウェアライセンスの利用を最大化するために派遣することも、工数課金を積み上げるために長期間常駐させることもありません。 私たちのエンジニアが現場に入る目的は一つです。モデルに依存しない視点から、お客様の粗利を守るためのソブリンかつアンチフラジャイルなAIアーキテクチャを構築することです。 優れたカスタマーエージェントの実現には、OpenAIやAnthropicに代表される最先端モデルの高度な推論能力が不可欠であり、複雑なエッジケースではそれらのモデルを積極的に活用すべきです。しかし日常的な業務にまで同じモデルを使い続け、予算を圧迫することは避けるべきです。 Ichizokuのエンジニアは、お客様のインフラ上にハイブリッド型の階層的ルーティングアーキテクチャを直接構築します。日常的な業務は高度に最適化された固定コスト型のプライベートなオープンソース基盤で処理し、フロンティアモデルの高度な能力は本当に必要な場面でのみ活用される仕組みを実現します。 重要なのは、プラットフォーム都合に縛られたFDEモデルに惑わされるのではなく、長期的な自律性と事業の収益性をともに重視するエンジニアリングパートナーを選ぶことです。 次のベンダー契約を締結する前に、ぜひIchizokuのアーキテクチャ監査をご活用ください。 【FAQ】よくある質問 1. FDEを「プロダクト型ベンダー」から調達する場合の最大のリスクは何ですか？ 業務データと知識が自社の独自エコシステムに取り込まれ、将来的なプラットフォーム移行時にカスタマーロジックを引き継げなくなります。結果としてベンダーへの完全な依存状態が生じます。 2. トークンマックスとはどのような状態ですか？ コスト管理を設計原則に持たないFDEが、すべての問い合わせを最上位の推論モデルに送り続ける状態です。増え続けるトークンコストが粗利率を圧迫し続けます。 3.
- [リアライズ・イノベーションズ、Ichizokuが共同でAI移行を加速するFDEトレーニングカリキュラムの提供を開始](https://ichizoku.io/ai-training-curriculum-realize-innovations-ichizoku/) - Ichizoku株式会社（本社：東京都港区、代表取締役社長：Jay Revels、以下「同社」）と、リアライズ・イノベーションズ株式会社（本社：東京都港区、代表取締役社長：酒谷 正人、以下「リアライズ」）は、このたび共同開発したFDE（Forward Deployed Engineer※1、以下FDE）育成カリキュラムの提供を開始したことを発表しました。本プログラムは、ソフトウェアエンジニアが企業において投資対効果（ROI）を創出するAIシステムを構築・導入するために必要なスキルを習得できるよう設計された集中育成プログラムです。 FDEという職種は、米国のAI企業である Palantir Technologies ※2によって広く知られるようになり、現在では Anthropic ※3や OpenAI ※4といった基盤モデル企業でも高く求められている人材像です。 AI以前の時代に確立された従来のソフトウェア開発手法の多くは、確率的に動作するAIシステムの特性とは必ずしも適合しません。同社と リアライズは、企業がこのギャップを埋めるための支援を目的として、本プログラムを共同で提供します。 背景と課題 AIの価値は生成（Generation）から実行（Execution）へと移行し、市場は生成AIの時代から、自律的に判断し行動するエージェンティック AI（Agentic AI）※5の時代へと進化しています。今日の企業が求めているのは、単にコンテンツを生成するAIではありません。自律的に意思決定を行い、具体的な成果を生み出すAIエージェントです。この変化が加速する中で、新たな競争優位性として注目されているのがエージェンティックヴァリュー（Agentic Value）※6です。一方で、多くの企業は、エージェンティック AIの可能性を認識しているにもかかわらず、AIエグゼキューションギャップ（AI Execution Gap）※7に直面しています。これは、AIのプロトタイプを作成できても、組織全体で利用できる本番システムへと移行できない状態を指します。このギャップを埋めるためには、単にAIツールを導入したり、基盤モデル利用のためのトークンコストを増やしたりするだけでは不十分です。企業には、AIエージェントのワークフローを設計・構築できる専門人材と組織基盤が求められています。 しかしながら、依然として以下のような課題が存在します。 多くのSIerや企業内エンジニアリング組織には、AI以前の時代の決定論的なソフトウェア開発を専門としてきたエンジニアが多く、確率的なAIシステムの構築に必要なスキルが不足している。 日本国内でFDEとしての実務経験を持つ人材は極めて少なく、そのような人材は大手基盤モデル企業や海外コンサルティングファームから高額報酬で採用される可能性が高い。 そのため、多くの企業やSIerは、AIエージェントシステムの導入・運用を加速するために、既存人材のスキル転換（リスキリング）を進める必要に迫られている。 その結果、日本企業にとっては、AIネイティブな人材育成と組織変革が、今後の競争力を左右する重要な経営課題となっています。 FDE育成カリキュラムについて これらの課題に対し、同社とリアライズは既存社員および今後採用する人材を、AIネイティブなエージェンティックチームへと進化させるための包括的な育成カリキュラムを提供しています。本プログラムは、FDEとして求められる中核的な能力の習得を目的としています。 FDEは従来のソフトウェアエンジニアとは異なり、主に以下の3つの特徴を持ちます。 1. 分離された実行ではなく、最前線での高い自律性 FDEは、複雑かつ不確実性の高い顧客環境の中で直接業務を遂行します。与えられた要件を実装するだけではなく、自ら課題を特定し、意思決定を行いながら、AI導入における最後の重要な工程である「ラストマイル」を担います。 2. 決定論的ロジックではなく、確率論的なAIオーケストレーション FDEは非決定論的なAIシステムを扱うための訓練を受けています。AIエージェントは従来のソフトウェアのように静的なロジックを順番に実行するのではなく、確率空間の中で最適な判断を行いながら動作します。FDEには、このようなAIシステムを設計・運用する能力が求められます。 3. 機能開発ではなく、価値創出を目的としたシステム設計 FDEの評価指標は、コードの開発速度や機能数ではありません。業務変革や事業成果といった組織全体へのインパクトが重視されます。そのため、FDEには技術だけでなく、ビジネス価値を創出するためのシステム設計能力が求められます。 FDEカリキュラムで育成する主要スキル 1. 高い自律性 クライアント環境において自律的にビジネス課題を解決し、自ら推進役となってプロジェクトを前進させるとともに、変化する要件へ迅速かつ柔軟に対応できるエンジニアを育成します。 2. プラットフォームへの深い習熟 ファインチューニング、Assistants API、ステート管理、オーケストレーションフレームワーク、エージェントアーキテクチャなど、最先端のAIモデルを支える技術スタックやフレームワークに関する高度な専門知識を習得します。 3. ドメイン知識とAIをつなぐ能力 従来の業務プロセスや決定論的ワークフローを、確率論的なエージェンティックワークフローへと変換する能力を養います。受講者は、業界・業務知識を、安全かつテスト可能でスケーラブルなAIエージェントフローへ迅速に落とし込み、本番環境で運用できるスキルを習得します。 エージェンティック組織変革・人材育成プログラム 1. 人材の特定 既存社員の中からエージェンティック・マインドセットを持つ人材を特定するための独自の技術的・行動的評価フレームワークを提供します。また、新規採用候補者に対しても技術評価および行動評価を実施し、高いポテンシャルを持つ人材を見極めます。
- [AIエグゼキューションギャップ ー チャットライセンスからデジタル従業員へ](https://ichizoku.io/ai-execution-gap-chat-to-digital-employee/) - By Jay Revels, Ichizoku株式会社 CEO 本記事は、日本企業のAI活用率とAIエージェントによる業務自動化率の間に存在する「AIエグゼキューションギャップ」の実態と、1990年代のIT化失敗との構造的な共通点、そしてチャットUIから自律型のAIエージェントワークフォースへ転換するための3層アーキテクチャを解説します。 重要なポイント 88.8%と2.4%の乖離：AI活用率は9割近いが、業務自動化を確立した企業はわずか2.4%という統計的ギャップ 1990年代との構造的類似：PC導入時と同様、業務フローを変えずに技術だけ刷新する過ちが繰り返されている AIサイコシスによる縮小：本番環境での破綻を経て、AIの役割が受動的チャットボットへ後退する心理的サイクル 3層ワークフロー転換：決定論的コード・エージェンティックAI・HITLを組み合わせ、人間ミドルウェアを排除する自律型実行へ 企業の現場リーダーは今、難しい立場に置かれています。 経営幹部と取締役会は、ベンダーの華やかなデモを見て「AI導入」を求め、エンタープライズ企業はここ数年で数百万件規模の生成AIライセンスを積極的に採用しています。導入率は高く、ユーザーアカウントはアクティブで、数字の上では申し分ない結果を出し、IT部門はAIの民主化に成功したと胸を張ることができます。 しかし、そこに日本のAI活用に関する実証データが突きつけられます。 KiteRaが2026年6月に実施した包括的な企業調査によると、エンタープライズ企業の管理・バックオフィス部門担当者の88.8％が、日常業務で生成AIまたはAIエージェントを積極的に活用しています。一見すると、業務変革はほぼ達成されたように見えます。 しかし、実態を詳しく見ると、その裏には大きな運用上のギャップが存在します。同調査によると、「AIエージェントによる自動化」を日常業務の主要な実行手段として確立している企業は、わずか2.4％しかありません。 （出典：KiteRa調査、2026年6月発表) 88.8％のカジュアルなAI活用率に対し、AIエージェントによる業務自動化はわずか2.4％。この巨大な統計的乖離こそが、AIエグゼキューションギャップを決定的に示す数字です。 この数字は残酷な現実を突きつけています。莫大な投資が行われてきたにもかかわらず、エンタープライズAIの導入は本質的な成果につながっていません。システム全体の生産性向上を実現するどころか、コンピューティング史上最大級の技術革新を高価な文章作成ツールへと矮小化してしまっているのです。 その理由を理解するには、一過性のAIブームに目を奪われるのではなく、企業が現代のナレッジワークの仕組みをどのように設計してきたのかを見直す必要があります。 歴史は繰り返す：1990年代の再来 この失敗は新しい現象ではありません。1990年代のパソコンブームと、まったく同じ失敗の繰り返しです。パソコンと企業内イントラネットがエンタープライズに初めて普及したとき、企業は全従業員のデスクにPCを配備するために巨額の投資を行いました。経営層はタイプライターをワープロに置き換えるだけで、生産性が飛躍的に向上すると考えていたのです。 しかし、結果はどうだったでしょうか。ホワイトカラーの生産性は、その後10年間、ほとんど変わりませんでした。 根本的な原因は、業務フローの再設計を拒み続けたことにあります。時代遅れの紙ベースの稟議プロセスを残したまま、その上に最先端のハードウェアを導入しただけでした。従業員はデジタルで文書を作成し、それを印刷して、中間管理職の判子をもらうためにオフィスを歩き回っていました。技術は変わっても、手続きはアナログのままだったのです。 そして現在、企業の経営層はまったく同じ過ちを繰り返しています。業務モデルを見直さないまま、従業員にChatGPT EnterpriseやMicrosoft Copilotのライセンスを配布することは、紙と判子の業務手続きを現代風に焼き直しているにすぎません。 現代のホワイトカラーは、かつて紙をオフィス中に運んでいた代わりに、ブラウザを開いてプロンプトを入力し、LLM（大規模言語モデル）がテキストを生成するのを待ち、そのアウトプットをレガシーなERPやCRM、Excelスプレッドシートへ手作業でコピー＆ペーストしているのです。 KiteRaの調査は、この構造的な問題を裏付けています。企業におけるタスク実行の53.3％は、依然として人手による作業と、断片化されたハイブリッドSaaSプロセスの組み合わせに大きく依存しています。人間は炭素製の統合ミドルウェアとして、分断されたAIインターフェースと硬直した基幹業務システムの間で、データの受け渡しを強いられているのです。技術は進歩しても、業務フローそのものは、いまだ自動化されていません。 根本原因：なぜナレッジワークAIはコーディングAIが成功した領域で失敗するのか この2.4%のギャップを埋めるには、ある技術的パラドックスに答えなければなりません。なぜ自律型AIエージェントは、AIコーディングエージェントを通じてソフトウェアエンジニアリングを大きく変革した一方で、エンタープライズのナレッジワーク全般では成果を上げられていないのでしょうか。 答えは、両者の業務環境における構造的な違いにあります。ソフトウェアエンジニアリングには、エンタープライズのワークフローには存在しない強力なガードレールが備わっているのです。 エンタープライズのナレッジワークには決定論的な検証ループが欠けているため、標準的な生成AIツールを導入すると、Box CEOのAaron Levie氏が「AIサイコシス」と呼ぶ状態に組織は陥ります。 これは、エンタープライズAIプロジェクトがたどる心理的ライフサイクルです。 1. サンドボックスでの成功体験 エンジニアや経営幹部が週末に簡単なプロトタイプを構築します。LLMは難なく文書を生成し、テスト用データセットを整理します。制作者は大きな期待を抱き、やがて一人の従業員が部門全体を運営できるようになると確信します。 2. 本番環境での破綻 プロトタイプが本番環境に投入されます。しかし現実には、ハルシネーション、基盤モデルのアップデートによる推論プロファイルの予期しない変化、未処理のエッジケース、厳密なコンプライアンス要件などに直面し、システムは破綻します。 3. 縮小 確率的システムを維持するために必要なエンジニアリング負荷に直面した経営陣は引き下がり、安全策を優先します。そしてAIの役割を「人間がプロンプトを入力するだけの安全で受動的なチャットボット」へと縮小してしまいます。 AIを人間の入力待ちのチャットボットへと格下げした瞬間、構造的なROIは消滅します。KiteRaの調査は、まさにこの停滞状態を示しています。53.9％の従業員はAIを「時々」しか利用していません。AIはビジネスのエンジンではなく、補助的なツールとして扱われているのです。 脱却への道：チャットからFDEアーキテクチャへの転換 ※FDE（Forward Deployed Engineer） AIエグゼキューションギャップを解消するには、「SaaS＋チャットUI」モデルを完全に捨て去る必要があります。真の変革はソフトウェアを購入することでは生まれません。人間のミドルウェアを排除する自動化されたワークフォースを設計することで初めて実現します。 これがAIトランスフォーメーションブループリントの中核となる考え方です。デジタルモダナイゼーションを超え、AIエージェントワークフォースが中核となる企業へと進化することです。 AIエージェントとは、従業員がプロンプトを考えるのを待つチャットボットではありません。既存の企業システムの上で直接稼働するよう設計された、高度に統合された自律型エージェントです。 業務ロジックを以下3つのレイヤーに整理し、それぞれを自律的に実行します。 1.
- [DXの先へ ― 真のAIトランスフォーメーション設計図](https://ichizoku.io/beyond-dx-ai-transformation-blueprint/) - By Jay Revels, Ichizoku株式会社 CEO 本記事は、DX（デジタルトランスフォーメーション）がなぜ真の変革をもたらせなかったのかを振り返りつつ、AIエージェントを軸に企業をゼロから再構築する「AIトランスフォーメーション」の設計図をIchizokuの実践知をもとに解説します。 重要なポイント DXの限界ソフトウェアを導入するだけでは業務の仕組みは変わらない。ツールを変えても、プロセスを変えなければ生産性は向上しない SIer依存からの脱却3年・数十億円規模のカスタム開発に頼らず、既存インフラ上にAIエージェントを構築することで、ゼロ・ディスラプションでの変革が可能 業務再設計の3分類すべてを自動化するのではなく「決定論的コード／エージェンティックAI／人間の意思決定」の3つに業務を分類し、AIが最も価値を発揮する領域に集中する Human-in-the-Loop設計初日からHITLアーキテクチャを組み込み、シャドーモードで精度を高めながら段階的に自律性を向上。導入1ヶ月以内に12〜15%の自律性向上を実現 労働力不足が加速する今、紙の書類、FAX、Excelへの依存から脱却し、業務効率化をさらに推進することはかつてないほど重要な課題となっています。現場では中間管理職の粘り強さと努力によって業務が支えられていますが、人材だけに頼り続けることには限界があります。 その答えとして注目されてきたのが「デジタルトランスフォーメーション（DX）」でしたが、DXとは結局、デジタル化による自動化に過ぎませんでした。今、それを大きく超える機会が到来しています。エージェンティックAIを軸に企業組織をゼロから再構築することで、これまでにない成長力と競争優位性を手に入れることができます。 Ichizokuは業務の進め方そのものを再定義することで、業務効率を最大化するAIトランスフォーメーションを設計・実行します。ここのブログを読み終える頃には、組織の無駄を省き、SIer依存から脱却し、中核事業を止めることなく自律型AIエージェントを導入して収益に直結する成果を生み出す方法が、具体的にイメージできるはずです。現状維持から脱却し、AIネイティブ企業への転換に本気で取り組みたい方は、ぜひ読み進めてください。Ichizokuは現在、急速に拡大中です。AIで日本のビジネスの未来を切り拓きたいエンジニア、エンタープライズアーキテクト、トランスフォーメーションリーダーを東京で募集しています。 デジタル化の幻想：テクノロジーの購入はトランスフォーメーションではない ソフトウェアを購入するだけでは、真の変革は生まれません。 「失われた数十年」は、私たちに残酷な真実を突きつけました。真の生産性向上は、ツールのアップグレードからは生まれない。業務の仕組みそのものを根本から変えない限り、何も変わらないのです。しかし、未だにこの現実から目を背けている経営層は少なくありません。 1990年代のパソコンとイントラネットの普及を思い出してください。当時、多くの企業がデスクトップパソコンの購入、ネットワークの整備、社内メールの導入に何億円もを投じました。 しかし結果はどうだったでしょうか。 ホワイトカラーの生産性は、ほとんど変わりませんでした。理由は単純です。経営層はタイプライターをワープロに置き換えたにもかかわらず、従来と全く同じ紙ベースの稟議プロセスを維持し続けたためです。業務フローを変えるのではなく、デジタルデータをわざわざ印刷し、承認をもらうために中間管理職の各デスクに向かい判子をもらうという、大昔に設計された業務プロセスの上に、最新のハードウェアを乗せただけだったのです。仕組みが変わらない限り、何も変わりません。 真の変革が起きたのは、コンピューターが単なる高速なタイプライターではなく、情報をリアルタイムで自由にやり取りできるツールだと気づいた時でした。価値はハードウェアにあったのではなく、紙の回覧という物理的な業務フローを完全に廃止し、場所や時間に縛られないデジタルファーストのワークフローへ移行したことにありました。 今、多くの経営層はAIでも全く同じ過ちを繰り返しています。何千ものMicrosoft CopilotやChatGPTのエンタープライズライセンスを購入して従業員に配布し、劇的な生産性の向上を期待しています。かつてメールをわざわざ印刷して判子をもらうだけで何も変わらなかったように、チャット画面にプロンプトを入力してメモを10%速く書くだけでは、AI時代の競争に取り残されてしまいます。真のトランスフォーメーションとは、旧来の業務の仕組みを根本から作り直し、自律型エージェントがエンドツーエンドで実行できる形にパイプライン全体を再構築することです。 SI依存の罠から脱却する 日本のイノベーションを阻む最大の要因は、巨大なカスタムソフトウェア開発を外部のSIer（システムインテグレーター）に任せ続けてきたことです。こうしたプロジェクトは完成まで3年、費用は何十億円にも上り、リリースする頃にはすでに時代遅れになってしまいます。 エージェンティックAIは、この構造を根本から変えます。レガシーERPを書き直す必要も、欧米のSaaSプラットフォームへ移行する必要もありません。 Ichizokuでは、SIerに頼ることなく以下を実現します。 ゼロ・ディスラプション統合既存のインフラ上に自律型AIエージェントを構築します。人間のオペレーターが操作するのと同じように、既存のソフトウェアを操作します。 暗黙知の抽出調達から買掛金管理まで、中核となる業務現場にFDE（Forward Deployed Engineer）チームを常駐させます。ベテランスタッフが持つ、文書化されていない業務ルール（暗黙知）を抽出し、エージェントが確実に実行できる明確なルールとコンテキスト層へと変換します。 ベンダー依存からの脱却ベンダーに依存しない仕組みを構築します。現場の責任者が、コードを一行も書かずに業務ルールを変更できる運用フレームワークを構築します。 業務再設計：注力すべき領域を選ぶ まず、大前提をお伝えします。すべての業務フローにAIエージェントを導入すべきではありません。過度な自動化は、収拾のつかない複雑性を生み出します。 Ichizokuの業務再設計では、企業の業務フローを以下の3つに分類することから始めます。 AIエージェント導入に適した業務フロー 4つの条件 IchizokuではROIの高い業務フローを特定するために、以下4つの条件を確認します。 1. 計測可能な業務上の非効率長いサイクルタイム、高いエラー率、仕入先への支払い遅延など、問題を明確に数値化できる業務フロー2. 高い処理量月に何百、何千回と繰り返される業務フロー3. パターンに基づく意思決定毎回同じ形ではないが、AIが過去のデータから学習できる明確なパターンに従っている業務4. システムの断片化メール、PDF、旧来のグリーンスクリーン端末、Excelの間でデータをコピー&ペーストするために何時間も費やしているプロセス 継続的な進化を前提とした設計 IchizokuのAIトランスフォーメーションは、一度導入して終わりのソフトウェア展開ではありません。初日からすべてのエージェンティックシステムにHITL（Human-in-the-Loop）アーキテクチャを組み込みます。 初期の「シャドーモード」フェーズでは、人間のオペレーターがエージェントの動作を確認・承認・修正します。すべての修正は高精度なフィードバックデータとして記録され、エージェントは本番環境で継続的に精度を高めていきます。 Ichizokuの実績では、エージェントの自律性は導入から1ヶ月以内に12〜15%向上し、効率化の成果は着実に収益へと反映されていきます。成果はすぐに出るものではありませんが、財務的な検証は数週間以内に確認できます。 企業の未来を守る Ichizokuが活用するすべての方法論、アーキテクチャ基準、業務プレイブックは、Google、Adobe、McKinseyなどの一流企業出身のエグゼクティブとエンジニアによって構築されています。表面的な「DXツール」への無駄な投資をやめ、AIネイティブな企業への転換を目指すなら、ぜひIchizokuにご相談ください。 現在、来四半期に向けた新規案件を受け付けています。まずは業務アセスメントのご相談からでも構いませんので、アドバイザリーチームまでお気軽にお問い合わせください。 【FAQ】よくある質問 1. DXとAIトランスフォーメーションは何が違うのですか？ DXはデジタル化による自動化に留まりますが、AIトランスフォーメーションは業務の仕組みそのものをAIエージェントを軸にゼロから再構築することです。ツールを変えるのではなく、プロセスを根本から作り直します。 2.
- [AIエグゼキューションギャップを埋める ― 日本企業向けForward Deployed Engineering宣言](https://ichizoku.io/ai-execution-gap-fde-japan/) - By Jay Revels, Ichizoku株式会社 CEO 本記事は、日本企業に存在するAIエグゼキューションギャップを踏まえ、Ichizokuが実践するFDE（Forward Deployed Engineer）モデルを解説します。 重要なポイント コモディティ化したAIの知性：採用するモデルが競争優位をもたらす時代の終わり。残る優位性は「どこで・どう実装するか」の実行力のみ 旧来のSIでは対応できないAIエグゼキューションギャップをFDEが埋める：確率的なAIエージェントには静的なSIは対応不可。FDEが現場に常駐し、業務診断から本番デプロイまでを一貫して実行 3つの自動化マトリックスで最適領域を特定：業務を「エージェントプロトコル・決定論的プロトコル・ヒューマン・コアプロトコル」に分類し、AIが最も価値を発揮する領域に注力 Evalsで経営層の信頼を獲得：感覚的評価を数学的検証に置き換え、エラー最大60%削減・RAG応答精度40%以上向上を実現 未だ生成AIを試験的な取り組みとして扱っていたり、導入を旧来のシステムインテグレーター（SI）に任せきりになっているようであれば、組織的に資本を無駄にしていることに他なりません。 希少で独占的な資産だった「AIの知性」は、今や急速にコモディティ化するインフラとなり、テクノロジーのパラダイムは根本から変わりました。OpenAI、Anthropic、Googleによる超高性能モデルのリリースは、アルゴリズム推論の基盤を民主化したため、採用するLLMの選択が持続可能な競争優位をもたらすことは、もはやありません。 残された唯一の競争優位性は、コモディティ化したAIの知性を自社の業務にどこで・どのように組み込むか、その判断と実行力にあります。しかし日本企業には、巨大なAIエグゼキューションギャップが存在します。旧来のSIは、確率的システムを構築するために必要なアジリティと深いAI専門知識を持ち合わせていません。根本的に静的で決定論的なコードベースのために設計された組織です。一方、企業内部のエンジニアリングチームには、不安定なデモ環境を実際の業務で使える自律型ワークフォースへと発展させる専門的なアーキテクチャ経験が不足しています。 このギャップを埋めるべく、業界では各社が高額報酬で争奪する新たなエンジニア像として、FDEが誕生しました。Palantirから生まれた概念で、AnthropicやOpenAIが積極的に採用を進めるFDEは、Applied AI時代の最前線を担う、精鋭エンジニアです。 Ichizokuでも自社の運営モデルとして、FDEフレームワークが定着しています。提案資料を納品して終わりにするのでも、5年間保守契約を締結するのでもなく、FDEチームが常駐した上で、実際に自律型AIエージェントによるワークフォースを設計・構築します。また最終的に社内チームが自ら運用・維持できるよう、スキルアップも同時に行います。 以下にIchizokuがFDE運用モデルを活用し、コモディティ化したAIの知性を企業の持続的なROIへと転換するための決定版プレイブックをご紹介します。 ブラックボックスSIの幻想 vs Applied AIの現実 日本における旧来のテクノロジーコンサルティングは、根本的に破綻した前提の上に成り立っています。「外部ベンダーが500ページの仕様書を書き、社外の開発センターに閉じこもり、1年後に動くシステムを納品する。」このようなやり方はもう通用しません。 AIエージェントは確率的な生き物です。乱雑な企業データ、動的なツール環境、予測不可能な人間のインプットと常に相互に作用しながら動いています。信頼性の高いエージェントワークフォースを構築するには、未知のレガシーコードに真っ先に飛び込み、本番品質のオーケストレーションレイヤーをその場で書き上げ、技術的なパフォーマンスを経営陣が理解できる財務指標へと変換できるエリートエンジニアが必要です。 だからこそ、私たちIchizokuのようなApplied AI企業が存在するのです。旧来のSIにありがちな煩雑な承認プロセスを排除し、実証済みの3段階のフレームワーク「診断・評価・デプロイ」を現場で直接実行します。 フェーズ1：徹底的な業務診断と自動化マトリックス 業務フローへの深い理解なしに動作するAIエージェントは、問題を解決するどころか、新たな問題を生み出すリスクになります。IchizokuのFDEはまず、クライアントの各業務部門に直接常駐することから始めます。営業オペレーション、購買部門、財務部門など、各チームに数週間寄り添い、社員が実際にどのように情報を処理しているか、そのデータの流れを丁寧にマッピングします。 表面的なエグゼクティブサマリーは信用しません。すべての業務タスクを、以下3つの自動化マトリックスをもとに評価します。 1. エージェントプロトコル（AIエージェントを導入すべき業務） 業務がロジックルールで規定されているものの、入力情報が高度に断片化・非構造化され（複数形式のPDF、仕入先メール、非構造化の顧客問い合わせなど）、複数ステップの外部ツール実行が必要な業務が該当します。IchizokuのAIエージェントワークフォースが最も力を発揮する領域です。 2. 決定論的プロトコル（標準コードを導入すべき業務） 調達から買掛金管理まで、中核となる業務現場にFDEチームを常駐させます。ベテランスタッフが持つ、文書化されていない業務ルール（暗黙知）を抽出し、エージェントが確実に実行できる明確なルールとコンテキスト層へと変換します。 3. ヒューマン・コア・プロトコル（人材を活かすべき業務） 繊細なパターン認識、深い現場知識、高度な倫理的・ビジネス的判断が求められるタスクは、人間が担う業務です。この領域でのエージェントは、意思決定を補助する役割に限定されます。 ROIフィルター：低頻度のタスクは除外します。月に5回しか発生しない社内プロセスを自動化しても、意味がありません。FDEが注力するのは、プロセスの遅延を40%以上削減することで収益に直結する、高頻度・高ボリュームの業務ボトルネックのみです。 フェーズ2：エンタープライズレベルのEvals（AI評価）で不信感を払拭する 企業向けAI施策がパイロット段階で失敗に終わる最大の理由は、経営層の信頼を失うことです。生成AIのデモが財務数値で、一度でもハルシネーションを起こしたり、プレゼン中にコンテキストが漏れたりするだけで、保守的な経営層はプロジェクトを即座に打ち切ります。 Ichizoku Fix というIchizoku独自のアプローチを通じて、IchizokuのFDEは「なんとなく良さそう」という感覚的な評価を数学的・実証的な検証に置き換えます。データ環境に合わせたオーダーメイドのEvalsフレームワークを構築します。 推論トレース評価 AIエージェントの最終的なアウトプットだけを評価するのではありません。エージェントの内部思考プロセスをステップバイステップで追跡し、ツール呼び出し、ベクターデータベースへのクエリ、中間的な推論ループを検証します。正確なアウトプットに辿り着いていても、そのプロセスに問題があれば、本番環境に入る前にEvalsが検出します。 ゴールデンデータセットの構築 貴社のドメイン専門家と協力し、「ゴールデンアンサー」と呼ばれる、完璧な実行を体現する高精度なテスト用データセットを作成します。エージェントのプロトタイプをこのデータセットに対して継続的にテストし続けます。 Ichizokuは、堅牢なガードレール、入力バリデーション、ステップ制限を設計・実装することで、一般的なエンタープライズ実装と比較して、エラーを最大60%削減し、RAGの応答精度を40%以上向上させています。本番環境へのスケールアップ前に、システムが確実に機能することを証明する確固たる定量指標を経営陣に提示します。 フェーズ3：本番デプロイと完全オブザーバビリティ AIエージェントのデプロイは、ローンチして終わりではありません。そこからが、継続的な最適化サイクルの始まりです。本番環境では、性能劣化、モデルドリフト、データパイプラインの障害、APIトークンコストの暴走といった問題が次々と起こります。 IchizokuのFDEはリスクの高い大規模なデータベース移行を必要とせず、エージェントを既存のエンタープライズデータレイヤーにシームレスに組み込みます。自動リトライロジック、指数バックオフ、厳格なJSON構造化出力の強制など、堅牢な実行環境を構築します。 さらに、IchizokuはSentryおよびArizeの日本における最高位の公式パートナーであり、デジタルワークフォースに世界最高水準のオブザーバビリティの導入が可能です。
- [コーディングAIは成功し、ナレッジワークAIが失敗する理由 ― ギャップを埋める方法とは](https://ichizoku.io/coding-ai-success-knowledge-work-ai-gap/) - By Jay Revels, Ichizoku株式会社 CEO 本記事は、AIコーディングエージェントが成功する一方でナレッジワークAIが失敗しやすい構造的な理由と、IchizokuのFDEによってAIエグゼキューションギャップを埋める方法を解説します。 重要なポイント コーディングとナレッジワークの環境差：入力が断片化・非構造化され、非技術系担当者が多いナレッジワークでは、エージェントの安定稼働が困難 SIer依存の罠：静的設計を前提とするSIerは確率的なAIエージェントに対応できず、固定仕様書ベースのアプローチは不適合 AIサイコシス期の落とし穴：週末プロトタイプの成功体験が過剰な期待を生み、本番環境での複雑さに直面し幻想が崩壊 Evalsによる精度の実証的検証：推論トレース評価とゴールデンデータセットを活用し、エラー最大60%削減・RAG精度40%以上向上を本番前に実証 何千ものMicrosoft CopilotやChatGPTのエンタープライズライセンスを購入し、従業員に配布し、劇的な生産性向上を期待する。このようなAI戦略だとしたら、企業資本を無駄にしているのと同じです。 1990年代にも、同じような失敗がありました。パソコンとイントラネットが日本企業に普及し始めた頃、経営層はハードウェアの購入やネットワークの整備に何億円もを投じました。しかし生産性はほとんど変わりませんでした。 理由は単純です。組織が従来と全く同じ紙ベースの稟議プロセスを維持し続けたためです。デジタルデータをわざわざ印刷し、承認をもらうために中間管理職の各デスクに向かい、判子を押す。大昔に設計された業務プロセスはそのままに、単に最先端のテクノロジーを導入しただけだったのです。もし今も、従業員がチャット画面の前に座り、プロンプトを手入力してメモを10%速く書くだけなら、全く同じ失敗を繰り返すことになります。真のトランスフォーメーションとは、旧来の業務の仕組みを根本から作り直し、自律型エージェントがエンドツーエンドで実行できる形にパイプライン全体を再構築することです。 しかしこの戦略を実行するには、BoxのCEOアーロン・レビーが「AIサイコシス期（AIに対して過剰な期待を抱く時期） 」と呼ぶ段階を乗り越える必要があります。すべての経営者やエンジニアが経験する心理的な変遷です。週末にプロトタイプを作り、LLMが文章を生成したりコードを書いたりするのを見て、「これは人類史上最大の技術革命だ」と確信します。そして、1人の従業員がやがて数十億円規模の事業部門を丸ごと動かせるようになると考え始めます。 しかし、実際の現場に出た瞬間、その幻想は崩れ去るのです。 確率的なシステムを維持するには、膨大なエンジニアリングの監視が必要です。ハルシネーションによるエラーの修正だけで何時間も費やし、基盤モデルがアップデートされれば、推論プロファイルの変化が既存のアーキテクチャ全体を壊すこともあります。さらにセキュリティプロトコル、コンプライアンスの制約、レガシーなデータ構造も大きな障壁となります。実際の企業環境では、週末に作ったサンドボックスのプロジェクトなど全く使えないのです。 なぜAIコーディングエージェントは驚異的な効果を発揮するのに、企業のナレッジワークに適用したAIエージェントは失敗することが多いのでしょうか。実は自律型エージェントワークフォースをスケールさせるには、ある技術的なパラドックスに向き合う必要があります。 現実の比較：コーディング vs 一般的なナレッジワーク なぜAIは特定の領域でしか普及しないのか。 その答えは、業務環境そのものの構造的な違いにあります。アーロン・レビーは、ソフトウェア開発の自動化が急速に進む一方で、一般的なナレッジワークが依然として停滞している理由を明確に整理しています。 コーディング環境では、エージェントは明確なルールと即時のフィードバックループの中で動作し、問題が起きれば熟練したエンジニアがすぐに修正できます。一方、一般的なナレッジワークでは、乱雑なデータ、レガシーなソフトウェア、予測不可能な人間のインプットが混在する環境にエージェントが放り込まれることになります。 デジタル化の幻想とSIer依存の罠 AIがナレッジワークでうまく機能しないという現実は、日本企業にとって特に重大な問題です。深刻な労働力不足に直面しながら、手作業での引き継ぎ、FAX、複雑なExcelデータに頼り続けている企業が少なくないためです。 これまで、経営層は外部のSIer（システムインテグレーター）に頼ってきましたが、AI導入においてこの選択は慎重に考える必要があります。従来のSIerは、静的で決定論的なソフトウェアを設計するために作られた組織です。500ページの仕様書を書き、社外の開発センターに閉じこもり、何十億円もかけて1年後に納品されるシステムは、リリースする頃にはすでに時代遅れになってしまいます。 AIエージェントは確率的な生き物であるため、このやり方はもう通用しません。何年もかけて作られた固定の仕様書で、AIエージェントを管理することはできません。信頼性の高いデジタルワークフォースを構築するには、レガシーシステムに深く入り込み、リアルタイムでオーケストレーションレイヤーを構築し、アルゴリズムのパフォーマンスを収益に直結させられるエリートエンジニアが必要です。 Ichizokuフレームワーク：ナレッジワークAIエージェントの構築 このAIエグゼキューションギャップを埋めるために、IchizokuはFDE（Forward Deployed Engineer）フレームワークを確立し、従来のSIへの依存を回避します。FDEとは、Palantirなどのシリコンバレーの先進企業から生まれた概念で、企業の業務現場に直接常駐するエリートエンジニアを指します。IchizokuのFDEチームの使命は、AIエージェントの構築と既存の業務フローの理解に特化した運用モデルを実装することです。複雑でアドホックな企業環境を、AIエージェントが効率的に機能できる形へと変えていきます。 これを実現するために、実証済みの3フェーズの運用モデルを採用しています。 フェーズ1：徹底的な業務調査と自動化マトリックス FDEは表面的なエグゼクティブサマリーには頼りません。購買部門、営業オペレーション、財務部門などに直接常駐し、情報がどのように処理されているか、丁寧にマッピングします。ベテランスタッフが持つ暗黙知を抽出し、AIエージェントが活用できる形に変換します。すべての業務タスクを厳密な自動化判断マトリックスで評価することで、トークンの無駄遣いやシステムの肥大化を防ぎます。 1. エージェントプロトコル（AIエージェントを導入すべき業務） ロジックルールで規定されているものの、断片化・非構造化された入力（仕入先メールと複数形式のPDFの照合など）が多く、複数システムにまたがる業務に適用します。 2. 決定論的プロトコル（標準コードを導入すべき業務） 入力情報もビジネスルールも完全に予測可能であれば、LLMの活用は資本の無駄遣いです。より速く、安く、100%信頼できる標準的なソフトウェア統合を構築します。 3. ヒューマン・コア・プロトコル（人材を活かすべき業務） 深いビジネス的判断、現場の文脈、高度な交渉が必要なタスクは人間が担当し、エージェントは意思決定の補助に限定します。 低頻度のタスクは除外します。月に数回しか発生しないプロセスの自動化は意味がありません。Ichizokuが注力するのは、プロセスの遅延を40%以上削減することで収益に直結する、高頻度・高ボリュームの業務ボトルネックのみです。 フェーズ2：エンタープライズレベルのEvals（AI評価）で不信感を払拭する 企業向けAI施策がパイロット段階で失敗に終わる最大の理由は、経営層の信頼を失うことです。生成AIのデモが財務数値でハルシネーションを起こしたり、プレゼン中にコンテキストが漏れたりするだけで、保守的な経営層はプロジェクトを即座に打ち切ります。 「Ichizoku Fix」というIchizoku独自のアプローチを通じて、IchizokuのFDEは「なんとなく良さそう」という感覚的な評価を数学的・実証的な検証に置き換えます。 推論トレース評価 AIエージェントの最終的なアウトプットだけを評価するのではありません。中間的な推論ループ、ベクターデータベースへのクエリ、ツール呼び出しをステップバイステップで検証します。正確なアウトプットに辿り着いていても、そのプロセスに問題があれば、本番環境に入る前にEvalsが検出します。 ゴールデンデータセットの構築 貴社のドメイン専門家と協力し、ゴールデンアンサーと呼ばれる複雑なベンチマークデータセットを作成します。このゴールデンアンサーに対してプロトタイプを継続的にテストし、厳格なガードレールを構築します。標準的な実装と比較してエラーを最大60%削減し、RAGの精度を40%以上向上させます。
- [ダイニーが進めるフルスタックオブザーバビリティの強化とSentryの価値](https://ichizoku.io/case-studies-sentry-dinii/) - 要約 ダイニーではSentry（エラーモニタリング／トレーシング／セッションリプレイ）とClaude Code＋Sentry MCPを活用中 トレーシングとAI連携により、不具合調査の効率化とユーザー影響度の素早い判断を実現 Ichizokuの伴走支援により、トレーシングなど高度機能の活用が進み、運用レベルが向上 飲食業界のDXを推進するダイニーの取り組み 株式会社ダイ二ーは、日本の飲食業界のデジタルトランスフォーメーションを牽引するSaaS企業です。多くの導入実績のある同社のサービスは、約11000店舗（ダイニー全サービス） が飲食店が利用し、のべ2,500万ユーザー以上の方が利用しています。また、店舗の現場業務と顧客データ、デジタルマーケティングをシームレスに連携させ、独自の価値を提供しています。 サービス紹介サイト：https://dinii.jp/ 同社の長期的なビジョンは、飲食店のデジタル化にとどまらず、運営を自動運転のように円滑にするシステム開発を目指しています。そのため、社内でのAI活用への積極的な投資や「外食AIサミット 」の開催によって飲食店経営の新たなスタンダードを共創することを目的に、業界内の対話の促進、AIを利用した機能構築などに取り組んでいます。ダイニーにとって重要なのは、積極的なイノベーションだけでなく、Sentryを活用した強固なフルスタック可観測性の確保と、中核となるプラットフォームが顧客との契約を確実に果たすことにあります。 TypeScript統一とモノレポで支える開発基盤 ダイニーでは全プロダクトの開発言語をTypeScriptに統一し、モノレポ構成で一元管理しています。バックエンドはNestJS、フロントエンドはReactおよびNext.js、モバイルはReact Nativeと、全領域で技術スタックを揃えることで、開発効率と保守性の向上を図っています。さらに、これらすべての領域にSentryのSDKを組み込み、横断的な監視基盤を整備しています。 組織面では、以前は単一チームで全プロダクトを扱っていましたが、事業拡大に伴い領域別のチームに分割されています。一方で、横断的に技術基盤を担うプラットフォームチームが存在します。 「私はプラットフォームチームの一員として、複数プロダクトの品質やアーキテクチャを見ています。特にフロントエンド領域ではコードオーナーとしてレビュー責任を担い、全体の品質担保に関与しています。」（プラットフォームチーム 畑田氏） 人間の勘に依存していたコードレビューと調査 Sentryのトレーシング機能を本格的に活用する以前は、フロントエンドとバックエンドのイベントの関連性を経験や勘に頼って判断していました。ある程度は機能するものの、暗黙知に依存した運用になりやすく、特に複雑な不具合の調査では精度や再現性に課題がありました。 また、AIを活用した分析を行う際にも、イベント同士の明確な紐付けがないことで誤認識が発生する可能性がありました。人であれば経験則で補える部分もありますが、AIにとっては構造化されていない情報は扱いづらく、結果として分析の精度にばらつきが生じていました。 こうした状況の中で、トレーシングによる明示的な関連付けが求められていました。 「人間の感覚でなんとなく紐付けていた部分は多かったと思います。ただ、それが必ずしも正しいとは限らないという不安は常にありました。」（畑田氏） また、Sentryの活用において、近年大きく変わったポイントの一つが、Claude CodeとMCPを組み合わせた調査フローです。従来は、SentryのUI上でイベントを一つひとつ確認しながら、必要な情報を手動で探していく必要がありました。ログやトレースを横断的に見ながら原因の手がかりを探す作業は、一定の時間と労力を要するものでした。 現在では、Sentry MCPをClaude Codeから利用することで、こうした調査プロセスが大きく変わっています。必要な情報の取得や関連イベントの分析を自動的に進めることができるため、人間がUIを操作し続ける必要がなくなり、調査の初動が大幅に効率化されました。 「以前はUIを操作しながらイベントを見ていましたが、今は待っていれば必要な情報が揃うようになりました。」（畑田氏） 既存導入からの再評価で見えたSentryの価値 畑田氏が入社した時点でSentry自体はすでに導入されていましたが、当初は基本的なエラーモニタリングが中心で、高度な機能は活用されていませんでした。そのため、Sentryの本来の価値を十分に引き出せている状態ではなかったと振り返ります。 その後、トレーシング機能を有効化したことで、イベント間の関係性が明確になり、従来は見えなかった因果関係が可視化されるようになりました。その結果として、これまで見落とされていた関連性や、複雑な問題の構造が把握しやすくなっています。 トレーシングの導入にあたっては、すでにSDKが組み込まれていたこともあり、大きな障壁はありませんでした。基本的には設定を有効化するだけで利用でき、導入コストは非常に低かったと感じています。 一方で、サンプリングレートの設定については、イベント数やリクエスト頻度をもとにAIと壁打ちしながら決定しました。コストとデータ量のバランスを見ながら最適化するプロセスはありましたが、それ以外に大きな課題はなく、スムーズに運用へ移行できたとのことです。 「導入というよりは、単にフラグをオンにしただけという感覚でした。それくらいシンプルに、スムーズに進みました。」（畑田氏） トレーシング導入後、社内から大きな混乱や課題の声は特に上がっておらず、各メンバーがAIと組み合わせながら自然に活用できています。実際に詰まったというフィードバックがないこと自体が、スムーズに使われている証拠だと感じているとのこと。 トレーシングとリプレイで実現した判断コストの削減 現在は、エラーモニタリングに加えてトレーシングやセッションリプレイを活用しています。特に、バックエンドのエラー発生時にユーザー影響を即座に判断できる点が大きな価値となっています。 例えば、エラー発生時にトレースから紐づくセッションリプレイを確認することで、ユーザーが問題なく操作できているかを即座に把握できます。その結果、調査や対応の優先度を迅速に判断でき、調査コストを削減できています。 また、プラットフォームチームでは定期的にSentryのダッシュボードを確認する運用を行っており、継続的な品質改善にもつながっています。全体として、特別なトレーニングなしでも自然に使われており、チームへの浸透度の高さがうかがえます。 「私個人の利用頻度は高いです。エラー調査時に、トレースとセッションリプレイを組み合わせており、ユーザー影響の有無が迅速に判断できています。ユーザー影響がないと判断できた時点で深掘りをやめられるので、調査の無駄がかなり減りました。」（畑田氏） 分析基盤との連携とプロアクティブな改善への期待 今後の期待としては、イベントデータをより高度に活用できる分析基盤との連携を挙げています。現在はBigQueryなどで他のプロダクトデータと組み合わせた分析を行っているため、Sentryのデータも同様に統合的に扱える仕組みがあると有用だとのことです。 Sentryが単なるエラーモニタリングにとどまらず、蓄積されたイベントやコードベースをもとに、潜在的な問題を自動検出し、改善提案やプルリクエスト生成まで行うような仕組みにも期待しているとのこと。 「定常的な変更がない領域でも異常を検知し、能動的に改善を促してくれると、今後の開発体験を大きく変えると感じています。」（畑田氏） Ichizokuの伴走支援が後押しした活用の深化 最後に、IchizokuのSentry導入支援に関する評価を伺いました。 ダイニーではIchizokuのサポートによって、Sentry活用が単なるツール導入にとどまらず、段階的に深化していきました。もともとは基本的な機能の利用にとどまっていたものの、トレーシングの有効化など、実際に価値のある機能を適切なタイミングで提案・支援を受けられたことで、運用の幅が広がっています。 「サポートがなければ、トレーシングも活用しきれずに何となく使い続けていたと思います。」と畑田氏は振り返ります。ツール単体ではなく、活用の仕方を含めて支援を受けられたことが、現在の運用レベルにつながっていると実感してくれています。 ありがとうございました！
- [お知らせ｜招待制モーニングセッション開催のお知らせ](https://ichizoku.io/morning-session-ai-strategy/) - 2026年5月21日（木）に、招待制モーニングセッションを開催いたします。 本セッションでは、パロアルトを拠点とするベンチャーキャピタル Evolution VC の大橋晶氏をお迎えし、シリコンバレーの最新動向を踏まえながら、日本企業に求められるAI戦略の次の一手を考えます。少人数・クローズドな場で、経営層やAI推進リーダーの皆さまと、実践的な対話の機会を創出します。詳細・お申し込みは、以下のページをご覧ください。 ■ お申し込み 詳細・お申し込みは以下よりご確認ください。https://promotion.ichizoku.io/ja/morning-session ■ Ichizokuについて Ichizoku株式会社は生成AIの導入戦略立案から実装・定着までを支援するテクノロジーソリューション企業です。 お問い合わせ先Ichizoku株式会社広報担当:竹内 美稀 (Miki Takeuchi)メール: miki.takeuchi@ichizoku.io
- [Ichizoku、NexTech Week 2026 出展のお知らせ](https://ichizoku.io/nextechweek-2026-ichizoku/) - 東京ビッグサイトでのAI・人工知能EXPOに出展 生成AIの導入戦略立案から実装・定着までを支援するテクノロジーソリューション企業のIchizoku株式会社（本社：東京都）は、2026年4月15日から17日まで東京ビッグサイトで開催される「NexTech Week 2026」に出展することをお知らせいたします。 出展概要 会期 ：2026年4月15日（水）～17日（金） 各日10:00-17:00会場 ：東京ビッグサイト（西展示棟）出展場所：AI・人工知能EXPO（小間番号：14-1）Ichizoku展示会詳細参加費 ：無料 展示内容 当社ブースでは、4回のセッションを予定しております。社内AIエージェント開発の実例をもとに、セキュリティや実装における具体的な課題と、その対応に必要な視点をわかりやすくご紹介します。加えて、RAGをはじめとするエンタープライズ検索AIの最新動向を踏まえ、今後のAI活用に求められる設計・実装のポイントをお伝えします。来場者の皆さまに実践的な知見をお持ち帰りいただける内容を予定しています。なお、セッションは当社の Head of Client Solutions and AI Innovationのフランシスコ・ソアレス（Francisco Soares）がブース内にて担当します。 お問い合わせ先Ichizoku株式会社広報担当:竹内 美稀 (Miki Takeuchi)メール: miki.takeuchi@ichizoku.io
- [AIエージェント カンファレンス 2025 Fall Online 登壇内容が ビジネス＋IT にて記事掲載](https://ichizoku.io/news-ai-agent-conference-2025-businessit-ichizoku/) - 生成AI活用の本質に迫る「コンテキストウィンドウの管理」について紹介 AIエージェントのデバッグとテスト領域をリードするテクノロジーソリューション企業、Ichizoku株式会社（本社：東京都港区）は、SBクリエイティブ株式会社が運営するIT・ビジネスメディア ビジネス＋IT において、当社クライアントソリューション＆AIイノベーション担当責任者 フランシスコ・ソアレスの講演内容が記事として掲載されたことをお知らせいたします。 本記事は、2025年10月24日（金）に開催された 「AIエージェント カンファレンス 2025 Fall Online」 における登壇内容をもとに構成されたものです。 掲載記事 ビジネス＋IT「AIエージェントの自律性と信頼性を両立させるために必要な開発・運用の考え方」https://www.sbbit.jp/article/sp/175407※本記事はペイド記事として掲載されています。 カンファレンス登壇概要 イベント名：AIエージェント カンファレンス 2025 Fall Online主催：SBクリエイティブ株式会社開催日：2025年10月24日（金） 登壇者 フランシスコ・ソアレス（クライアントソリューション＆AIイノベーション担当責任者） 講演内容 AIエージェントの「自律」と「信頼」を両立し、成長を加速させる成功への実現戦略 「AIエージェント元年」において、自律的に動くシステムをいかに安心して本番運用に乗せるかが最大の課題です。本講演では、エージェントの自動生成と継続的改善のサイクルと、その非予測的な振る舞いを精密に捉え、是正する高度な監視メカニズムを統合した新しい開発・運用モデルを提案し、未来のシステムを支える高信頼なアーキテクチャの設計思想を解説しています。 お問い合わせ先Ichizoku株式会社担当:竹内 美稀 (Miki Takeuchi)メール: miki.takeuchi@ichizoku.io
- [ムック本掲載のお知らせ](https://ichizoku.io/news20250707/) - #日経ムック『AIで加速する エマージングテクノロジー』にIchizokuが登場（提供企画） Ichizokuは、KPMGコンサルティングが監修し日経BPが発行する注目のムック本 日経ムック『AIで加速する エマージングテクノロジー』 に、提供企画として登場します。 本誌は、生成AIをはじめとする革新的テクノロジーが、ビジネス・社会・人材育成にどのような変革をもたらすのかを多角的に特集。国内外の最先端企業の事例や、専門家による知見が凝縮された、未来を見据えるための保存版です。 Ichizokuは「生成AIを核としたIchizokuのデジタルインテリジェンスとは」というテーマで登場。以下の3名が、それぞれの視点からデジタルインテリジェンスのオンボーディングの重要性について語っています。 ・ジェイ・レヴェルズ（CEO兼創業者）・野村 肇（営業責任者）・フランシスコ・ソアレス（クライアントソリューション & AIイノベーション担当責任者）生成AIを軸に企業の未来戦略を描こうとするすべての組織にとって、必読の一冊です。ぜひお手にとってご覧ください。書籍情報タイトル：日経ムック『AIで加速する エマージングテクノロジー』発行日：2024年6月26日著者名：KPMGコンサルティング監修発行元：日本経済新聞出版詳細：https://bookplus.nikkei.com/atcl/catalog/25/05/14/02023/Ichizokuについて：https://ichizoku.io/japan/お問い合わせ先Ichizoku株式会社担当:竹内 美稀 (Miki Takeuchi)メール: miki.takeuchi@ichizoku.io
- [『ZDNET Japan』にて寄稿連載が開始](https://ichizoku.io/news20250817/) - 生成AI活用の本質に迫る「コンテキストエンジニアリング」を解説
- [『ZDNET Japan』にて寄稿連載の第２回記事が掲載されました](https://ichizoku.io/news20250829/) - 生成AI活用の本質に迫る「コンテキストエンジニアリング」のケーススタディーを紹介 ZDNET Japanにて弊社CEO兼創業者のジェイ・レヴェルズによる寄稿連載の第２回の記事が掲載されました。生成AI活用の現場で問われている「コンテキストエンジニアリング」について、実際の事例や知見を交えながら解説している本連載の第2回では、ソフトウェア開発のライフサイクルから「Sentry」と「Cursor」のケーススタディーを紹介しています。 記事はこちらからご覧いただけます。コンテキストエンジニアリングが変えるソフトウェア開発--「Sentry」と「Cursor」のケーススタディー第１回の記事成功するAIエージェント展開のための新たなスキル--コンテキストエンジニアリングとは今後も連載を通じて、最新の知見や実践的なアプローチをお届けしてまいります。お問い合わせ先Ichizoku株式会社担当:竹内 美稀 (Miki Takeuchi)メール: miki.takeuchi@ichizoku.io
- [『ZDNET Japan』にて寄稿連載の第3回記事が掲載されました](https://ichizoku.io/news20250930/) - 生成AI活用の本質に迫る「コンテキストウィンドウの管理」について紹介 ZDNET Japanにて弊社CEO兼創業者のジェイ・レヴェルズによる寄稿連載の第3回の記事が掲載されました。生成AI活用の現場で問われている「コンテキストエンジニアリング」について、実際の事例や知見を交えながら解説している本連載の第3回ではAIエージェント設計で誤解されがちなテーマの一つである「コンテキストウィンドウの管理」に焦点を当てています。 記事はこちらからご覧いただけます。AIエージェントの能力を最大化するコンテキストウィンドウ設計法とは第１回の記事成功するAIエージェント展開のための新たなスキル--コンテキストエンジニアリングとは第２回の記事コンテキストエンジニアリングが変えるソフトウェア開発--「Sentry」と「Cursor」のケーススタディー今後も連載などを通じて、最新の知見や実践的なアプローチをお届けしてまいります。お問い合わせ先Ichizoku株式会社担当:竹内 美稀 (Miki Takeuchi)メール: miki.takeuchi@ichizoku.io
- [AIエージェント カンファレンス 2025 Fall Online登壇のお知らせ](https://ichizoku.io/news20251016/) - 弊社クライアントソリューション & AIイノベーション担当責任者であるフランシスコ・ソアレスが登壇。 AIエージェントのデバッグとテスト領域をリードするテクノロジーソリューション企業、Ichizoku株式会社（本社：東京都港区）は、2025年10月24日（金）にSBクリエイティブ株式会社が主催するオンラインイベント「AIエージェント カンファレンス 2025 Fall Online」にて、当社クライアントソリューション＆AIイノベーション責任者のフランシスコ・ソアレスが登壇することをお知らせいたします。 概要 日 時：2025年10月24日(金) 13:00～18:55弊社講演時間：2025年10月24日(金) 17:05～17:35URL：https://www.sbbit.jp/eventinfo/85969 講演内容 AIエージェントの「自律」と「信頼」を両立し、成長を加速させる成功への実現戦略「AIエージェント元年」において、自律的に動くシステムをいかに安心して本番運用に乗せるかが最大の課題です。本講演では、エージェントの自動生成と継続的改善のサイクルと、その非予測的な振る舞いを精密に捉え、是正する高度な監視メカニズムを統合した新しい開発・運用モデルを提案します。未来のシステムを支える高信頼なアーキテクチャの設計思想を解説します。お問い合わせ先Ichizoku株式会社担当:竹内 美稀 (Miki Takeuchi)メール: miki.takeuchi@ichizoku.io
- [【The AI Conference 2025】GraphRAGの優位性ナレッジグラフが切り拓くエンタープライズAIエージェントの未来](https://ichizoku.io/why-vector-only-rag-falls-short/) - By Francisco Soares, Head of Client Solutions & AI Innovation, Ichizoku株式会社 本記事は Neo4j Nyah Macklin 氏の講演をもとに、GraphRAGが従来型RAGの限界（関係性欠落／説明可能性不足／データ範囲の制約）を越え、信頼できるエンタープライズAIを実現する要点を日本企業向けに簡潔に整理します。 重要なポイント 従来RAGの限界ベクトル検索のみでは関係性を見落とし、説明可能性が乏しく、構造化データの活用が不十分 GraphRAGの中核価値ナレッジグラフで「つながり」を直接活用し、高精度／説明可能／広いデータカバレッジ／ガバナンス強化を実現 実証に裏付け回答品質3倍向上（DataTalks.World, 2023）、解決時間28.6%短縮（LinkedIn事例）、Q&A精度向上（Microsoft CTOオフィス研究） 実務への波及複数ソース横断推論・説明可能性・ハルシネーション抑制を満たし、実験から実用への移行を後押し 2025年9月にシリコンバレーで開催されたThe AI Conference 2025に参加した際のレポート「Silicon Valley Trip Report #03 The AI Conference 2025 シリコンバレーから学ぶ日本への示唆 - 業界を牽引するリーダーたちが語る、世界の AI潮流と日本企業の次の一手 -」から抜粋しお届けします。フルバージョンはこちらからダウンロード頂けます。 生成AIの進化はめざましいものがありますが、多くの日本企業が直面している課題は「AIがどこまで信頼できるのか」という点です。従来のRAG（Retrieval-Augmented Generation）システムは、文書検索やQ&Aに効果を発揮しますが、複雑な業務データをまたぐ推論には限界があります。 私はサンフランシスコで開催された The AI Conference に参加し、Neo4jのシニアAIデベロッパーアドボケイト、Nyah Macklin（ナイア・マクリン）氏 による講演 「The GraphRAG Advantage: Providing Enterprise-Grade Knowledge to
- [【The AI Conference 2025】エージェント時代のAI　日本企業が直面する課題とベストプラクティス](https://ichizoku.io/pitfalls-best-practices-for-ai-adoption-in-enterprises/) - By Francisco Soares, Head of Client Solutions & AI Innovation, Ichizoku株式会社 本記事は Google Cloud の Dr. Ali Arsanjani 氏講演をもとに、「エージェント時代（Agentic Era）」の到来と日本企業が直面するセキュリティ／ガバナンス／コスト／統合の壁、そして導入のベストプラクティスを簡潔に整理します。 重要なポイント エージェント時代の到来AIエージェントは実験ツールではなく企業基盤へ。PoCから本番での運用課題が顕在化。 エージェントの本質ゴール受領→観察→計画・実行（人/他エージェントと協調）。Google CloudはGemini 2.5／ADK／Agent Engine／Agenspace／A2A／AP2で支援。 落とし穴の典型統合の難しさ／セキュリティリスク／コスト増／可観測性不足が障害に。 導入の勘所小さく始める、モジュール型、ガバナンス最優先、A2Aによる協調、AP2での取引を見据える。日本企業は責任ある運用が鍵。 2025年9月にシリコンバレーで開催されたThe AI Conference 2025に参加した際のレポート「Silicon Valley Trip Report #03 The AI Conference 2025 シリコンバレーから学ぶ日本への示唆 - 業界を牽引するリーダーたちが語る、世界の AI潮流と日本企業の次の一手 -」から抜粋しお届けします。フルバージョンはこちらからダウンロード頂けます。 エージェント時代はすでに始まっている サンフランシスコで開催された The AI Conference で、Google CloudのApplied AI Engineering ディレクターであるDr. Ali
- [【The AI Conference 2025】音声AIでゲームを安全に　Riot Gamesに学ぶボイスチャットモデレーションの未来](https://ichizoku.io/the-hidden-challenge-of-online-voice-communication/) - By Francisco Soares, Head of Client Solutions & AI Innovation, Ichizoku株式会社 本記事は、Riot Games Daniyal Manlar 氏の講演をもとに、音声LLMでボイスチャットを安全化する実装要点を日本企業向けに簡潔に整理します。音声特徴の直接分類／課題と克服サイクル／大規模運用スタック／日本企業への示唆に焦点を当てます。 重要なポイント 文字起こしを介さない直接分類Whisperの音声特徴を直接解析し、不適切発言を分類。精度・多言語対応・速度・コストの同時最適化を達成 課題に対する反復サイクルデータ不足／ラベル不一致／ポリシーの限界／低遅延・低コスト要件に、Foundation Models＋再ラベリング＋再学習で継続改善 スケールする本番基盤NVIDIA Triton、GPUマルチテナント、CI/CD＋Canaryで、日々数百万件規模の音声イベントを安定処理 日本企業への適用余地ゲーム以外でもコールセンターや金融等の音声コミュニケーションで有効。ポリシー更新とガバナンスを中核に据える 2025年9月にシリコンバレーで開催されたThe AI Conference 2025に参加した際のレポート「Silicon Valley Trip Report #03 The AI Conference 2025 シリコンバレーから学ぶ日本への示唆 - 業界を牽引するリーダーたちが語る、世界の AI潮流と日本企業の次の一手 -」から抜粋しお届けします。フルバージョンはこちらからダウンロード頂けます。 オンライン体験の「見えないリスク」 オンラインゲームにおけるボイスチャットは、チームプレイの醍醐味である一方、誹謗中傷や不適切な発言が飛び交う場にもなり得ます。数百万人規模のプレイヤーが同時に声でやり取りをする中で、それを安全に管理することは容易ではありません。 この課題に挑んでいるのがRiot Gamesです。サンフランシスコで開催された The AI Conference にて、同社のソフトウェアエンジニア Daniyal Manlar（ダニヤール・マンラー）氏 は「Voice Chat Moderation at Scale: Building
- [【The AI Conference 2025】エージェント変革　企業におけるAIエージェント成熟度　4段階ロードマップ](https://ichizoku.io/navigating-the-four-stages-of-ai-agent-maturity/) - By Jay Revels CEO, Ichizoku株式会社 本記事は、Rubrik の Jackie Ho 氏講演「Agentic Transformation」をもとに、AIエージェント成熟度モデル（4段階）と日本企業への示唆を簡潔に整理します。実験 → 制度化 → 拡大 → 自律の道筋と、各段階での課題・成功ポイントを要約します。 重要なポイント 競争力の源泉へAIエージェントは実験段階を超え、企業の競争力を左右。予測では2028年に企業アプリの1/3がエージェント活用、意思決定の15%が自律化。 4段階の道筋実験→制度化→拡大→自律の順に成熟。初期は専門知識不足・標準化欠如・ガバナンス不在が壁。 鍵はガバナンスと可視性制度化・拡大期では権限設計、ポリシー、ログ/監査が要。最小権限とブラックボックス解消が拡大の前提。 日本企業への要点PoC早期本番化／厳格ガバナンス／“社員同等”の監視・評価／段階的導入で、ビジネス指標に直結させる。 2025年9月にシリコンバレーで開催されたThe AI Conference 2025に参加した際のレポート「Silicon Valley Trip Report #03 The AI Conference 2025 シリコンバレーから学ぶ日本への示唆 - 業界を牽引するリーダーたちが語る、世界の AI潮流と日本企業の次の一手 -」から抜粋しお届けします。フルバージョンはこちらからダウンロード頂けます。 AIエージェントは、今や単なる実験的な技術ではなく、企業の競争力を左右する存在になりつつあります。Gartnerの予測によれば、2028年までに企業アプリケーションの3分の1がエージェントを活用し、全ビジネス上の意思決定の15%が自律的に行われるようになるといいます。 サンフランシスコで開催されたThe AI Conferenceにて、RubrikのAIプロダクトリードJackie Ho（ジャッキー・ホー）氏が「Agentic Transformation: Navigating the 4 Stages of AI Agent Maturity」という講演を行いました。その中で紹介されたのが、企業がAIエージェント導入を進める際に直面する課題と、その克服方法を示す「AIエージェント成熟度モデル」です。 Ichizokuとして参加した私自身も、日本の大企業がAI活用を進める上で直面する現実と重なる点が非常に多いと感じました。ここでは、その4つの段階を日本企業が活用できるヒントとともにご紹介します。 第1段階：実験期（Experimentation） 最初のステップは、小さなチームが安全な範囲でエージェントを試す段階です。たとえば、非クリティカルなデータに限定した読み取り専用としての利用などです。
- [【The AI Conference 2025】SDLCからADLCへ　エンタープライズAIエージェント導入で成功する方法](https://ichizoku.io/how-enterprises-can-succeed-with-ai-agents/) - By Jay Revels CEO, Ichizoku株式会社 本記事は、Writer社 Sam Julien 氏の講演をもとに、SDLCでは捉えきれないエージェント型AIに対し、ADLC（Agent Development Lifecycle）で成果を出す要点を日本企業向けに簡潔に整理します。成果志向・適応性・非決定論を前提に、評価とガバナンスまで含めた実装指針を解説します。 重要なポイント SDLCの限界を前提化エージェントは成果志向・適応的・非決定論的。従来の決定論依存の枠組みでは運用できない。 ADLCへの転換開発・監視・拡張を通し、成果志向／適応性／継続監視を中核に据える。 3つの問いで設計何を作る、誰が作る、どう作るを明確化（自律性のスペクトラム、役割分担、行動設計と評価・ガバナンス）。 日本企業の要点KPI定義、役割受容、評価とガバナンスの優先、PoC止まりからの脱却で本番成果に直結。 2025年9月にシリコンバレーで開催されたThe AI Conference 2025に参加した際のレポート「Silicon Valley Trip Report #03 The AI Conference 2025 シリコンバレーから学ぶ日本への示唆 - 業界を牽引するリーダーたちが語る、世界の AI潮流と日本企業の次の一手 -」から抜粋しお届けします。フルバージョンはこちらからダウンロード頂けます。 旧来のモデルを超えて サンフランシスコで開催されたThe AI Conferenceで、Writer社のDeveloper Relationsディレクター Sam Julien（サム・ジュリアン）氏の講演 「Understanding the Agent Development Lifecycle in the Enterprise」 を聴講しました。最初に強く印象に残ったのは、従来のソフトウェア開発ライフサイクル（SDLC）は、エージェント型AIの負荷に耐えられなくなっているというメッセージでした。 これまでのエンタープライズ開発は、入力に対して予測可能な出力を返す「決定論的」な仕組みを前提としてきました。しかし、AIエージェントは成果志向・適応的・非決定論的であり、従来のフレームワークでは対応できません。日本企業が2025年以降、AIを本格的に活用するためには、この発想の転換が不可欠です。 ADLCとは何か Julien氏が提唱したのが Agent Development Lifecycle（ADLC） です。これは、AIエージェントを開発・監視・拡張するために必要な新しい方法論です。
- [【The AI Conference 2025】2025年AIコーディングエージェントがもたらすソフトウェア開発の未来](https://ichizoku.io/how-ai-coding-agents-are-changing-the-future-of-software-development/) - By Jay Revels CEO, Ichizoku株式会社 本記事は、Together AI の Dan Fu 氏講演をもとに、2025年がAIコーディングエージェント実用化の転換点である理由と、日本企業が「どう活用するか」の実装指針を簡潔に整理します。GPUカーネル最適化／運用の作法／生産性インパクトに焦点を当てます。 重要なポイント 転換点の到来2025年は品質と実用性が飛躍。課題は「導入の是非」ではなく活用設計。 GPUカーネルの要高速・低コスト化の鍵だが人材希少。エージェント活用で開発を加速。 運用の作法が成果を左右小分割のタスク設計／伴走型フィードバック／環境整備／過不足ない関与が効果を最大化。 生産性の実証数週間→数日〜数時間へ短縮し、事例では手書きアセンブリを上回る性能も。人は設計・問題解決に集中。 2025年9月にシリコンバレーで開催されたThe AI Conference 2025に参加した際のレポート「Silicon Valley Trip Report #03 The AI Conference 2025 シリコンバレーから学ぶ日本への示唆 - 業界を牽引するリーダーたちが語る、世界の AI潮流と日本企業の次の一手 -」から抜粋しお届けします。フルバージョンはこちらからダウンロード頂けます。 2025年 AIソフトウェア開発が迎える転換点 サンフランシスコで開催された The AI Conference にて、Together AIのVP of KernelsであるDan Fu（ダン・フー）氏の講演を聴講しました。メッセージは明快で、「2025年はAIコーディングエージェントの品質と実用性が飛躍的に高まる転換点である」という内容でした。 特に日本企業が直面するエンジニア不足や生産性向上の課題を考えると、AIコーディングエージェントの導入は「導入するなら」ではなく「どう活用するか」が問われています。 GPUカーネルとは？なぜ重要なのか Fu氏のチームはGPUカーネルの開発に取り組んでいます。GPUカーネルとは、行列計算やアテンション機構、正規化といった AIモデルの基礎的な演算をGPU上で効率的に実行する低レベルプログラムのことです。 簡単に言えば、優れたGPUカーネルはAIモデルの学習や推論を高速かつ低コストで実現するカギとなります。しかしカーネル開発の専門スキルは非常に希少で、人材不足が大きな課題です。そこでTogether AIはAIコーディングエージェントを用いてこのプロセスを加速できるかを検証しました。 AIコーディングエージェント活用の実践知 講演で特に印象的だったのは、「AIコーディングエージェントをどのように管理すれば最大の成果が得られるか」という具体的な知見でした。Fu氏はこれを 「新人エンジニアを育成するのに似ている」 と表現しました。 1. タスクを小さく分割する
- [【The AI Conference 2025】なぜAIは企業で失敗するのか — 成功のために組織DNAを再配線する](https://ichizoku.io/why-ai-is-failing-in-enterprises/) - By Jay Revels CEO, Ichizoku株式会社 本記事は、The AI Conference 2025 の Dr. Garth Andrus 講演内容をもとに、「技術は正しいのにAIが失敗する」根本原因＝組織DNAの不一致を日本企業向けに簡潔に整理します。意思決定・業務設計・リーダーシップ・文化をプレAIからAI対応へ再配線する指針を解説します。 重要なポイント 失敗の主因は技術ではなく組織AIを旧来モデルに組み込むと崩壊、荷車にジェットエンジンの比喩が示す通り。 日本のブラインドスポット安定・管理・予測可能性を重視する慣行が、意思決定の遅延・静的職務・リスク回避・協働抵抗を招く。 プレAI→AI対応への再配線構造・ワークフロー・学習・ガバナンスを分散、適応、継続学習、アジャイルへ転換し、AIも意思決定に参加。 今こそ行動競争の本質は最高モデルではなく活かせる組織DNA。再設計できなければ、競合に大きく引き離される。 2025年9月にシリコンバレーで開催されたThe AI Conference 2025に参加した際のレポート「Silicon Valley Trip Report #03 The AI Conference 2025 シリコンバレーから学ぶ日本への示唆 - 業界を牽引するリーダーたちが語る、世界の AI潮流と日本企業の次の一手 -」から抜粋しお届けします。フルバージョンはこちらからダウンロード頂けます。 テクノロジーは正しくても、失敗するのはなぜか サンフランシスコで開催された The AI Conference 2025 で、印象的なシーンがありました。Anderson Consultingのグローバルリーダーである Dr. Garth Andrus（ガース・アンドラス）博士は、こう問いかけました。 「馬に引かれた古い荷車に、強力なジェットエンジンを取り付けたらどうなるでしょう。」 エンジンを始動した瞬間の結果は？荷車は制御不能に揺れ、木材は裂け、車輪は外れ、最終的に荷車はバラバラに崩壊してしまう。 博士が示したのは、AIを旧来型の組織モデルに組み込む危険性でした。失敗の原因はAIそのものではなく、AIを受け入れる「組織の側」にあります。実際に、70〜80%の企業AIプロジェクトは期待した成果を出せていないのです。その理由は、技術の欠陥ではなく、意思決定・業務設計・リーダーシップ・文化が依然として、プレAI時代のままだからです。 日本企業に潜む「組織的ブラインドスポット」 日本企業もAI投資を加速していますが、同じ壁にぶつかっています。その理由は、多くの組織が、安定性・管理・予測可能性を重視した旧来型モデルのままだからです。 硬直的なヒエラルキーが意思決定を遅らせる 静的な職務定義がAIによるワークフロー変化についていけない リーダーシップの思考がリスク回避を優先し、実験的な適応を阻む 文化的規範が「人とAIの協働」に抵抗する
- [【The AI Conference 2025】生成AI CXの自動化に欠けていたもの — 信頼できるナレッジ基盤構築方法](https://ichizoku.io/building-a-trusted-knowledge-infrastructure/) - By 野村 肇 Head of Sales, Ichizoku株式会社 本記事は、eGain の Arvind Gopal 氏による 「The Missing Link in AI CX Automation: A Trusted Knowledge Infrastructure」 をもとに、AI CX が失敗する真因と信頼できるナレッジ基盤”の構築要点を日本企業向けに簡潔に整理します。 重要なポイント 失敗の真因はナレッジ分断誤答・不一致の主因はサイロ化と古い情報の増幅。 解はSSOT中心の信頼基盤Single Source of Truthで正確性・一貫性・説明責任を担保。 統合→キュレーション→配信→改善高価値20%の優先統合、メタデータ整備、マルチチャネル配信、継続的フィードバック。 ROIが明確最大75%のサービスコスト削減、動的ガイダンス定着、説明可能性で信頼強化。 2025年9月にシリコンバレーで開催されたThe AI Conference 2025に参加した際のレポート「Silicon Valley Trip Report #03 The AI Conference 2025 シリコンバレーから学ぶ日本への示唆 - 業界を牽引するリーダーたちが語る、世界の AI潮流と日本企業の次の一手 -」から抜粋しお届けします。フルバージョンはこちらからダウンロード頂けます。 AI CXが失敗する本当の理由 サンフランシスコで開催されたThe AI Conferenceにて、eGain
- [【The AI Conference 2025】信頼できる生成AIカスタマーサポート構築方法 − Cleanlab「Reliability by Design」アプローチ](https://ichizoku.io/building-trustworthy-genai-customer-support-systems/) - By 野村 肇 Head of Sales, Ichizoku株式会社 本記事は、Cleanlab の Curtis Northcutt 氏講演をもとに、「Reliability by Design」で生成AIカスタマーサポートの信頼性を設計段階から担保する要点を日本企業向けに簡潔に整理します。スピード偏重の落とし穴／決定論的ガードレール／段階的拡張／リアルタイム評価の勘所を解説します。 重要なポイント 「速さ」だけでは信頼は守れないNYCやAir Canadaの事例が示す通り、信頼性を設計に組み込まない限り事故は起きる。 Reliability by DesignLLM × 決定論的ガードレール（正規表現ブロック、固定応答、ルールベース・ルーティング）で不確実×不確実を避ける。 段階的に積み上げるまずは返金額算定／ポリシー引用など高信頼タスクから開始し、信頼性を維持したまま機能拡張。 常時モニタリングリアルタイム評価とConfident Learning（不確実性推定）で誤回答を事前に遮断し、必要時は人間確認へ。 2025年9月にシリコンバレーで開催されたThe AI Conference 2025に参加した際のレポート「Silicon Valley Trip Report #03 The AI Conference 2025 シリコンバレーから学ぶ日本への示唆 - 業界を牽引するリーダーたちが語る、世界の AI潮流と日本企業の次の一手 -」から抜粋しお届けします。フルバージョンはこちらからダウンロード頂けます。 「速さ」だけでは顧客の信頼は守れない セッションの前、廊下では「次の失敗事例になりたくないね」と冗談交じりの声が飛び交っていました。登壇したのは Cleanlab CEO & Co-Founder Curtis Northcutt（カーティス・ノースカット）氏。 彼が紹介したのは、NYCのMyCityチャットボットが違法行為を助言した事例や、Air CanadaのAIサポートが存在しない返金ポリシーを捏造し、実際に損失を出した事例。別の企業ではログイン規則を「創作」したAIが解約の波を引き起こしました。 これらは例外ではなく、信頼性を設計に組み込まない限り必ず起こる問題なのです。 なぜモデルが進化しても信頼性に欠けるのか 講演で特に印象に残ったポイントは次の3点です。 ハルシネーションは依然として発生
- [【The AI Conference 2025】Uberの生成AI活用から学ぶ顧客体験変革](https://ichizoku.io/the-ai-conference-2025-transforming-ubers-customer-experience-with-generative-ai/) - By 野村 肇 Head of Sales, Ichizoku株式会社 本記事は、「Transforming Uber’s Customer Experience with Generative AI」をもとに、超大規模マーケットプレイスで、CX（カスタマーエクスペリエンス）を変革する生成AIの実装要点を日本企業向けに簡潔に整理します。ビジネスKPI連動・二段構えのAIソリューション・意思決定エージェント化・測定の文化に焦点を当てます。 重要なポイント AIは事業の中核解決時間・CSAT・品質・P&Lに全AIプロジェクトを紐づけ、専用予算と学習サイクルで本番適用を継続。 Nova × ScoutでCXを高速化月1,500万会話/約90%精度、70–80%自動解決、人は高付加価値案件へ集中。 支援から意思決定へ進化Lumen（ルール・ポリシーエンジン）とPhoenix（アダプティブ・オートノミー）で自律的判断に段階移行。 測定が信頼を生む人→AI、AI→人、AI→AIの三層評価で4,000万件/月の会話ログを監査し、プライバシー・安全性を担保。 2025年9月にシリコンバレーで開催されたThe AI Conference 2025に参加した際のレポート「Silicon Valley Trip Report #03 The AI Conference 2025 シリコンバレーから学ぶ日本への示唆 - 業界を牽引するリーダーたちが語る、世界の AI潮流と日本企業の次の一手 -」から抜粋しお届けします。フルバージョンはこちらからダウンロード頂けます。 「Transforming Uber’s Customer Experience with Generative AI」 このセッションタイトルを目にした瞬間から、私は惹き込まれました。世界70カ国、15,000都市、月間10億件を超えるトリップ、1億8千万人以上のアクティブユーザー。これがUberのスケールです。その背後では、ライダーとドライバー、注文者と配達員、レストランや店舗といった複雑なマーケットプレイスが絡み合い、毎月200億件のメッセージと4,000万件の会話が発生しています。 この規模で、どのようにして効率性・パーソナライズ・信頼を同時に実現するのか。答えは、生成AIを活用した次世代エージェントでした。 ビジネス成果に直結するAI Uberのアプローチで最も印象的だったのは、AIを“nice to have（あると良いもの）”ではなく、ビジネスの中核に据えていることです。 すべてのAIプロジェクトは、以下の成果に紐づけられます。 解決時間の短縮 顧客満足度（CSAT）の向上 品質改善 P&Lへのインパクト
- [【The AI Conference 2025】実験からエンタープライズへ　AIエージェントの現実](https://ichizoku.io/the-ai-conference-2025-from-experiment-to-enterprise-what-it-really-takes-to-deploy-ai-agents/) - By Jay Revels, CEO Ichizoku株式会社 本記事は、AI Conference 2025 の「AI Agents in Production」セッションをもとに、AIエージェントを研究段階から本番運用へ移行する要点を日本企業向けに簡潔に整理します。システム設計・オープンソース活用・運用指標の観点から、実装の勘所を解説します。 重要なポイント モデル選定から設計重視へエージェントはモデル単体でなくシステム全体設計が要。 OSS × カスタマイズが鍵コスト・品質・機動性で優位化し、本番移行を加速。 運用の規律が成果を左右決定性・レイテンシ・コンプライアンスへの対処が中核。 測るべきを測る最初/最後のトークン時間とばらつきを継続計測し、UXを担保。 2025年9月にシリコンバレーで開催されたThe AI Conference 2025に参加した際のレポート「Silicon Valley Trip Report #03 The AI Conference 2025 シリコンバレーから学ぶ日本への示唆 - 業界を牽引するリーダーたちが語る、世界の AI潮流と日本企業の次の一手 -」から抜粋しお届けします。フルバージョンはこちらからダウンロード頂けます。 AI Conference 2025で開催されたセッション 「AI Agents in Production: Systems Design, Tuning, and Deployment」 に参加した際、会場はすでに熱気に包まれていました。そこに集まった誰もが抱いていた問いはひとつ。 「AIエージェントを研究段階から実際の本番環境にどう展開するのか。」 登壇したのは、Fireworks AIのHead of AI Developer Relations、Aishwarya
- [【The AI Conference 2025】なぜ企業にはAIガーディアンエージェントが必要なのか](https://ichizoku.io/the-ai-conference-2025-why-enterprises-need-ai-content-guardian-agents/) - By Jay Revels, CEO Ichizoku株式会社 本記事は、The AI Conference 2025 における Matt Blumberg 氏（Markup.ai）の講演をもとに、AIガーディアンエージェントで「スケール可能な信頼」を実現する要点を、日本企業向けに簡潔に整理します。生成AIで作成は容易になった一方、ガバナンス・一貫性・規制順守がボトルネックとなる現実と、その解決指針を解説します。 重要なポイント 作成は容易・運用が難しい生成AIは正否・ブランド適合・規制準拠を自律判断できず、信頼性の運用がボトルネックに。 分断×スケールの壁人手監視は不可能。複数モデル利用やシャドーAIで品質管理の一貫性が崩れやすい。 解決の中核はAIでAIを監視コンテンツ・ガーディアンエージェントにより、ワークフロー、スコアリング、既存環境統合、HITLを標準化。 日本企業への示唆グローバル準拠を満たしつつ、信頼／おもてなしの価値を損なわずにスピードと創造性を維持するための実装指針。 2025年9月にシリコンバレーで開催されたThe AI Conference 2025に参加した際のレポート「Silicon Valley Trip Report #03 The AI Conference 2025 シリコンバレーから学ぶ日本への示唆 - 業界を牽引するリーダーたちが語る、世界の AI潮流と日本企業の次の一手 -」から抜粋しお届けします。フルバージョンはこちらからダウンロード頂けます。 生成AI時代における「スケール可能な信頼」 毎年、数百万ものドキュメント、マーケティング資料、チャットボット応答を公開する企業において、生成AIはコンテンツ作成を容易にしました。 一見すると大きな前進に思えます。しかし、2025年サンフランシスコで開催された The AI Conference 2025 にて、Markup.ai CEO、Matt Blumberg（マット・ブルムバーグ）氏のセッション 「Trust at Scale: Why Enterprises Need AI Content Guardian Agents」 を聴き、課題は「作成」ではなく「信頼できる形での運用」にあることが明らかになりました。
- [【The AI Conference 2025】小売業におけるAI Amazon、Wayfair、Walmartが描く未来のショッピング](https://ichizoku.io/svtrr03-the-ai-conference-2025-ai-in-retail-how-amazon-wayfair-and-walmart-are-redefining-the-future-of-shopping/) - By Jay Revels, CEO Ichizoku株式会社 本記事は、Amazon・Wayfair・Walmartの事例をもとに、小売におけるハイパーパーソナライゼーション、リアルタイム対応、会話型AI、発見型UXの実装と成果を解説します。「即時性 × 膨大なデータ」を前提に、2025年以降の小売が直面する意思決定・顧客体験・運用最適化の論点を日本市場向けに整理します。 重要なポイント 即時性×膨大データ小売はクリック・棚スキャン・在庫移動などの行動データを数分以内に施策へ反映し、需要・価格・在庫・推奨を同一ループで最適化する領域である。 ハイパーパーソナライゼーション地域・天気・ライフスタイル・価値観を統合し、従来の「おすすめ」を超える文脈理解型の個別最適化を実現する。 発見型UX（Wayfair「Muse」）AI提案とユーザー編集を組み合わせ、発見→欲求喚起→購入を短縮するインタラクティブな購買体験。 日本の小売リーダーへのメッセージハイプを追わず、まずは一つの意思決定をAIに任せることで、おもてなし×改善の拡張を現実装に落とし込む。 2025年9月にシリコンバレーで開催されたThe AI Conference 2025に参加した際のレポート「Silicon Valley Trip Report #03 The AI Conference 2025 シリコンバレーから学ぶ日本への示唆 - 業界を牽引するリーダーたちが語る、世界の AI潮流と日本企業の次の一手 -」から抜粋しお届けします。フルバージョンはこちらからダウンロード頂けます。 未来のショッピングはすでに始まっている 想像してみてください。渋谷で雨の午後にお店へ入ると、デジタルサイネージに表示されるのは一般的な広告ではなく、あなたのスタイルに合った傘や防水スニーカー。オンラインでは、エコ素材の軽量ジャケットが表示されます。なぜなら、あなたが環境に配慮したブランドを好み、東京の秋に厚手のコートが必要ないことをAIが理解しているためです。 これは2030年の未来像ではなく、今まさに実現されつつある小売業におけるAI活用の姿です。 2025年サンフランシスコで開催された The AI Conference 2025 にて、私は小売業界のリーダーたちによるパネルディスカッションに参加しました。モデレーターを務めたのは、アクセンチュア先端AIセンター マネージングディレクターであるWinnie Cheng（ウィニー・チェン）氏。そして登壇したのは、世界最大級の小売企業でAI戦略を牽引する3名のキーパーソンです。 Rajesh Sura（ラジェッシュ・スラ）氏Amazon US データエンジニアリング＆アナリティクス部門 責任者 Harish Krishna（ハリシュ・クリシュナ）氏Wayfair LLC プリンシパル エンジニアリングリード Bhanu Prakash Reddy Rella（バーヌ・プラカシュ・レディ・レラ）氏Walmart Labs
- [【生成AIエージェント】あらゆる業界で従業員の生産性を再構築](https://ichizoku.io/how-ai-is-reimagining-employee-productivity-across-industries/) - By Manish Prabhune, AI Solutions Advisor Ichizoku株式会社 重要なポイント 生成AIは業務生産性を劇的に高める 単純作業から高付加価値業務へのシフト あらゆる業界・部門にインパクト 将来を見据えた戦略的活用が鍵 はじめに 今、企業のリーダーは、人工知能によって従業員の生産性に深い変化が起きていることを目の当たりにしています。もはや単なる誇張ではなく、AI、特に生成AIは、日々の業務において測定可能な効率性向上をもたらしています。 Google Cloud が実施した世界の経営幹部を対象とした最新調査では、70％が生成AIの導入により従業員の生産性が向上したと回答しています。さらに注目すべきは、そのうち39％のリーダーが、生成AIソリューションを導入後、いくつかの分野で生産性が少なくとも2倍になったと答えている点です。 こうした成果は、AI投資に対するROI（投資利益率）において、新時代が到来したことを示しています。定型業務は自動化され、洞察はより迅速に得られるようになり、従業員はより付加価値の高い業務に集中できるようになっています。 この記事では、銀行の窓口から工場の現場まで、AIがいかに生産性を再構築しているのか、そして企業の意思決定者にとって、それが戦略的にどのような意味を持つのかについて探ります。 生成AIによる生産性ブーム：数字で見る実態 生成AIは、知識労働と業務効率における力強い推進力として急速に定着しました。Google の「ROI of AI 2025」レポートでは、経営幹部たちが技術系・非技術系の両分野での大きな成果を強調しています。 IT部門では、AIを活用したコードアシスタントやトラブルシューティングエージェントがワークフローを効率化し、ITスタッフの生産性を70％向上させています。 同様に注目すべきは、その恩恵はIT以外の部門のビジネスユーザーにも広がっており、非ITプロセスにおいても生産性が60％向上している点です。実際には、AIはマーケティング担当者のコンテンツ作成の支援、人事チームによる履歴書の分析、アナリストのレポート生成など、ソフトウェア開発者だけでなく、幅広い業務をサポートしています。 さらに、こうした改善の規模は驚くべきものであり、単なる漸進的な向上ではなく、多くの場合、従業員一人あたりの成果が倍増しています。 Google の調査によると、一部の企業では生成AIによって成果が2倍になったと報告されており、外部の研究もその可能性を裏付けています。たとえば、ある分析では、生成AIを活用したカスタマーサポート担当者が約14％多くの問い合わせに対応し、AIコーディングアシスタントを利用するプログラマーは、同じ時間で126％多くのコードを生成したとされています。 このようなスループットの飛躍的向上は、企業にとって大きな価値創出に直結します。つまり、AIは職場における新たな生産性のブームをもたらしており、数十年分の効率向上を短期間に圧縮して実現しているのです。企業の意思決定者にとって、これらの数値は強力な論拠となります。AIを受け入れることは、もはやリスクの高いギャンブルではなく、労働力の生産性を飛躍的に高めるための実証済みの戦略なのです。 マインドシフト：単純作業から高付加価値業務へ ​​AIが企業にもたらす主要な戦略的利点の一つは、単調で繰り返しの多い業務を引き受け、従業員がより複雑な仕事に集中できるように支援する能力にあります。生成AIはコンテンツ生成や情報検索に優れており、これまで知識労働者の時間を何時間も奪っていたタスクを効率的に処理することが可能です。 重要なのは、こうしたAIによる強化が、すべての部門に及んでいるという点です。AIを使ってコードを書いたりトラブルシューティングをしたりするのは、ITスタッフだけではありません。マーケティングチームはAIでキャンペーン文案を作成し、法務チームは判例文書の要約、営業チームは提案書の作成や見込み顧客の調査にAIを利用しています。 Google の調査でも、このような幅広い導入が確認されています。経営幹部たちは、ソフトウェア開発から調査、財務、人事、カスタマーサービスに至るまで、各分野で生産性が向上したと報告しています。AIは普遍的な協働者として機能し、雑務を引き受けることで、従業員が創造性や批判的思考、人間関係の構築に集中できる環境を実現しています。その結果、従業員は本当に人間の判断を必要とする高付加価値な業務により多くの時間を費やし、AIは裏方で雑務を処理するという体制が確立されるのです。 ■ヘルスケア ヘルスケア分野では、AIが臨床医の事務的負担を軽減し、患者と過ごす時間を増やすことに貢献しています。たとえば、東南アジアのある病院向けテクノロジープロバイダーは、OpenAI の生成モデルと音声認識を活用したAIスクライブツールを導入し、医師と患者の診察内容を自動で文字起こし・要約できるようにしました。このソリューション「AIScribe」により、医師が医療文書作成に費やす時間は50％削減され、記録の質も向上し、さらに臨床医の燃え尽き症候群が70％減少しました。同様に、WellSky のようなヘルスケアソフトウェア企業も、生成AIを臨床評価フォームの自動入力や患者データのインサイト提示に統合しています。ケア移行時のデータ入力や分析を自動化することで、WellSky のAIツールは医療提供者がより迅速かつ適切な判断を下し、患者ケアにより多くの注意を向けられるようにしています。これらの事例は、AIが医療スタッフのデジタルアシスタントとして機能し（書類作業や情報検索を担うことで）、ケアの質を損なうことなく処理能力を向上させていることを示しています。 ■金融サービス 銀行や金融機関は、AIを活用してナレッジワークや顧客サービスを飛躍的に強化しています。際立った例として挙げられるのが、モルガン・スタンレーが導入した生成AIアシスタント「AI @ Morgan Stanley Debrief」です。このツールは、年間100万件以上の顧客通話を自動で記録し、会話内容を文字起こし・要約し、さらにフォローアップメールを作成するなど、アドバイザーの業務フローに統合されています。その効果は劇的で、アドバイザーは会議ごとのメモ作成や文書化に約30分を節約でき、その時間を顧客への助言に再投資できます。数万件の会議を考慮すると、同社は1万5,000人のファイナンシャルアドバイザーに対して年間約50万時間の労働を削減できると見積もっています。さらに、このAIが生成する一貫性のある構造化されたメモは、ビジネスにより良いインサイトをもたらし、情報の取りこぼしを防ぎます。あるアドバイザーは「これは完全にゲームチェンジャーだ」と述べ、顧客会議中にメモ取りに追われることなく意思決定に集中できるようになったと語っています。モルガン・スタンレーにとどまらず、ゴールドマン・サックスのような他の金融大手も、生成AIを使ったコード生成や複雑な文書作成の自動化に取り組んでおり、IT業務の迅速化や手作業によるエラー削減を実現しています。これらの事例は、AIが情報処理の重労働を担うことで、高度な専門知識を持つ金融プロフェッショナルの生産性を大幅に引き上げていることを示しています。 ■小売業 小売業界では、AIが現場の従業員を支援し、業務を効率化しています。代表的な事例として、Victoria’s Secret が導入した生成AIエージェントの実証実験があります。店舗スタッフはチャット形式のAIアシスタントを活用し、製品在庫の確認、サイズやスタイリングの提案、顧客からの質問への回答を即座に行うことができます。これまで時間のかかる検索やバックルームへの問い合わせが必要だった作業が瞬時に行えるようになり、従業員はより迅速かつ正確に顧客対応ができるようになりました。これにより、生産性と顧客体験の両方が向上しています。さらにVictoria’s Secret は、店舗スタッフのオンボーディングや研修の一部を生成AIで自動化し、人事部門向けの職務記述書のドラフトを生成するなど、管理者が内部業務に費やす時間を削減する取り組みも進めています。小売大手 Wayfair も異なる視点を示しています。同社のCTOフィオナ・タンは、AIは小売業務のあらゆるワークフローに応用できると述べており、マーケティングコンテンツのパーソナライズからサプライチェーンの最適化まで幅広く活用されています。そして「どのビジネスにもAIが実質的な価値をもたらすワークフローが存在する」と強調し、測定可能な成果につながるプロセスを加速させています。スピードと一貫性が重要な小売現場（在庫確認、商品情報、顧客対応など）では、AIアシスタントがリアルタイムのコーチ兼リファレンスツールとして従業員を支援し、遅延なくより多くの業務をこなせるようにしています。
- [AIエージェントの評価手法『評価駆動開発』とは？](https://ichizoku.io/ai-evaluation-driven-development/) - AIエージェント開発に不可欠な評価駆動開発（EDD）を、基本概念から評価軸設計（関連性・正確性・安全性）、導入手順、実践例まで詳説。推論・ルーティング・行動を測定し、可観測性とCI/CDで継続的に最適化、ビジネス指標に直結。現場で使える実務ガイド。
- [AIエージェントの本格導入による企業・チームKPI達成方](https://ichizoku.io/how-to-drive-strong-adoption-of-ai-agents-into-the-workforce-and-achieve-company-and-team-kpis/) - By Jay Revels, Ichizoku株式会社 CEO 重要なポイント 生産性、イノベーション、一貫性の向上を図るために、特に中堅層の従業員を中心に、デジタルインテリジェンス（DI）を業務の中核プロセスに統合する 孤立したAIツールの使用は避け、DIを業務やオペレーションに直接統合することで、持続的な成果を生み出す 従業員の役割を再定義し、AIエージェントの監督およびそのオーケストレーション（調整）を含める 体系的なトレーニングと経営陣との連携を通じて、AIエージェントへの信頼を確立する 経営層200名への質問 「今後2年間において、生成AIが貴社のビジネス戦略に果たす役割を最も適切に表すものはどれですか？」 I. なぜDIを人的リソースに統合すべきなのか 多くの組織は、AIを既存の業務プロセスの上に位置する自動化レイヤーとして捉えています。しかし、このようなアプローチは人間の働き方を無視しており、スケーラビリティに乏しく、広く展開されることはほとんどありません。DIの統合が成功するのは、人間の従業員と知的エージェントが統合された業務フロー内で協働する場合です。Salesforceが実施した最近の調査によると、人事部門の責任者の86％が、デジタル人材を既存の労働力に統合することが、自身の主要な職務の一つになると考えています。さらに、人事責任者の多くは、AIエージェントの導入率が今後2年間で327％、すなわち現在の15％から2027年には64％にまで増加すると予測しています。そして、AIエージェントが労働力に完全に導入されれば、生産性が30％向上し、人件費が19％削減されると見込まれています。 「デジタル労働は、経済、キャリア、スキルなど、多くの機会を切り開いています。未来は、この変化を受け入れ、迅速に変革する人々のものになるでしょう。」と、Salesforce 社長兼チーフ・ピープル・オフィサーである Nathalie Scardino（ナタリー・スカルディーノ）氏は述べています。 II. DIの人的リソースへの不完全な統合による影響 チャットボットやアシスタントなどの簡易的なツールは、以下の理由により失敗に陥りやすい傾向があります。 チームの業務フローから切り離されている 業務ごとの役割に即したタスクとの統合の欠如 実質的な行動変容を促進できない デジタルインテリジェンスが構造的に統合されず、適切なオンボーディングも行われなければ、AIエージェントは十分に活用されずに終わります。その結果、信頼は構築されず、人間とAIの協働は停滞します。従業員は、AIは一過性の流行に過ぎず、実質的な投資対効果（ROI）が見込めないと早計に判断するおそれがあります。このような認識が職場全体に浸透すると、企業はAIの全社的な導入において出遅れ、競争力を失う可能性があります。 III. 従業員によるAIエージェントの導入を加速させるためのリーダー・マネージャー向け実践ガイド 1. 位置付け AIエージェントを、従業員が責任を持つスタッフとして位置付けます。これにより、従業員はAIを業務効率化のツールとして、主体的に活用する機会を得ることができます。また、AIを「自分を置き換える新技術」ではなく、「新たな学習体験」として受け入れやすくなります。 ＜なぜ効果があるのか＞ 多くの従業員は、AIを使用していることを上司に隠しています。自分が代替可能だと思われることを恐れているためです。この新たな位置付けでは、従業員が自らのコントロールと責任を持てる「新しい学習体験」という前向きな関わり方を提示し、その恐れに正面から向き合います。 2. 透明性のあるガイドラインとガバナンスフレームワークの構築 従業員の意見を取り入れながら、明確で簡潔なポリシーフレームワークを共同で策定します。ここでは、エージェントに「できること」と「できないこと」を明確に定義します。例：レポートの下書きは作成出来るが、人間の承認無しに提出することはできない。 ＜なぜ効果があるのか＞ 信頼には予測可能性と安全性が不可欠です。こうした境界線をあらかじめ設定することで、AIが安全かつ人間の監督下で動作しているという安心感と、従業員自身が持つコントロール感覚を確保できます。 3.「説明可能性」はAIエージェント設計の一部にする 本番環境に導入されるすべてのエージェントには、「処理の根拠を示す」機能を備える必要があります。ユーザーは、エージェントがなぜ特定の提案や行動を取ったのかを容易に確認できるようにします。これは「監査可能な推論」と呼ばれます。 ＜なぜ効果があるのか＞ エージェントの論理を可視化することで、予測不能なブラックボックスではなく、合理的に判断するツールであることを示せます。 4. 「社内エージェント構築プログラム」を立ち上げる ローコードまたはノーコードのプラットフォームを提供し、従業員が自分の業務に合わせた小規模なタスク専用エージェントを構築できるようにします。または、ユーザーと密接に連携し、要件定義やプロトタイプ開発を迅速に行う小規模なITチームを編成します。 ＜なぜ効果があるのか＞ 従業員に所有感を与え、技術の受け手ではなく、能動的な創り手に変えることができます。従業員は自らの業務知識をもとにAIを教育し、それによって自身の価値が高まり、貴重な組織知の蓄積にもつながります。 5. AI活用のチャンピオンを称える AIを上手に活用している従業員を称賛し、社内の推進役やメンターとして位置付けます。 ＜なぜ効果があるのか＞ こうした従業員はすでに学習段階を乗り越え、AIの価値を実感しています。そのため、同僚に対してAI活用の利点を自分の言葉で説得力をもって伝えることができます。 6. 人間のフィードバックによる強化学習を実演する 従業員がAIエージェントにタスクを教える様子を、強化学習を用いたライブワークショップで実演します。従業員がエージェントの出力や精度にどのように積極的に影響を与えるかを示します。
- [【エージェント型ワークフォース】先進企業はいかにして生成AIを中核能力として拡張しているのか](https://ichizoku.io/the-agentic-workforce-how-leading-companies-scale-ai-as-a-core-operating-system/) - By Jay Revels, Ichizoku株式会社 CEO 重要なポイント エージェント型ワークフォースは、分散したAIツールを統合された知的オペレーティングシステムに置き換える AIエージェントを大規模に導入した企業は、意思決定の質、実行速度、コスト効率を向上させる ビジネスリーダーは、部分的な自動化から脱却し、システム全体でのエージェント統合に投資する必要がある エージェント型の成熟度は、支援型エージェントから完全自律型のマルチエージェントシステムへと発展する エージェント型ワークフォースの最大の価値は、企業全体の変革とイノベーションの加速によって実現される はじめに：自動化から運用インテリジェンスへ 多くの企業は、反復作業を自動化するためにAIを活用しています。しかし、この限定的なアプローチでは、わずかな効率改善は得られるものの、事業変革には至りません。デジタルインテリジェンス（DI）オンボーディングは、ディープラーニングモデルを人員、データ、プロセス、インフラ全体に統合する企業規模の取り組みです。これにより、AIの役割を再定義します。 この取り組みによって、企業はエージェント型ワークフォース、すなわちデジタル同僚として業務システム内で計画・実行・統合を行うAIエージェントを構築できるようになります。DIオンボーディングは、AIを単なる技術ツールから、コアとなる労働力能力を展開可能にする存在へと引き上げます。 エージェント型ワークフォースを採用した企業は、実行速度の向上、応答性の強化、そして測定可能な価値の創出を実現します。一方で、導入を遅らせる経営者は、知的システムが牽引する経済において後れを取るリスクを負うことになります。 エージェント型ワークフォースとは エージェント型ワークフォースとは、業務機能を管理するために設計されたAI搭載エージェントのシステムです。これらのエージェントは、単純な自動化とは異なり、知的なタスクを実行し、変化する状況に適応し、企業全体の環境に統合されます。 エージェント型システムの主な能力 ​​計画と推論エージェントは複雑なタスクを構造化された計画に分解します。依存関係を評価し、リスクを予測し、特定の目標に向けて手順を実行します。 自律的な行動エージェントは、設定された目標とリアルタイムのコンテキストに基づいて独立して行動します。組織はリスク管理のための監督基準を設定しつつ、自律性を拡大します。 システム統合エージェントは企業システム内で動作します。CRM、ERP、データベース、APIに接続し、実稼働環境で実際のビジネスタスクを実行します。 記憶とコンテキスト保持エージェントは、やり取りを通じて状態を保持する記憶を持ちます。これにより、複数のステップからなるプロセスを完了し、過去のコンテキストに基づいて出力をパーソナライズできます。 4種類の企業向けAIエージェント AIエージェントの成熟度は、次の4つの分類に沿って進化します。 この進化は生産性向上からエンドツーエンドのプロセス自動化と動的オーケストレーションへの転換を示します。 エージェント型ワークフォースの測定可能な効果 エージェント型システムを大規模に導入した組織は、明確な業務改善の効果を報告しています。 取引コストを15〜35％削減 プロセス速度を最大40％向上 市場対応力を3倍に向上 収益化サイクルを60％短縮 これらの改善は、意思決定の迅速化、引き継ぎ回数の削減、リアルタイムでの適応によってもたらされています （Stanford AI Index 2024）。 ユースケース：小売業サプライチェーンにおけるエージェント型ワークフォース 世界をリードする小売企業は、サプライチェーンの強靭性と顧客エンゲージメントを向上させるため、マルチエージェントシステムを導入しています。エージェントは、顧客転換、在庫管理、顧客満足度の向上といったさまざまな役割を担います。 この導入により、欠品率が20％減少、コンバージョン率が30％向上し、顧客満足度スコアが15％上昇しました。世界的な小売戦略は、市場の複雑さに対応するため、マルチエージェントシステムの活用にますます注力しています。小売業者は、このようなシステムを導入することで、市場の先端を行き、変化する消費者ニーズに応えています。 エージェント型ワークフォースによる価値創出の4つの戦略ゾーン エージェント型ワークフォースは、明確に区分されたゾーンごとに価値を創出します。組織は、導入規模を拡大するにつれて、これらのゾーンを段階的に進んでいきます。 1. パフォーマンスゾーン 収益最大化：現在の市場における内部最適化に焦点を当て、収益を最大化します。組織は、既に参入している市場で生産性を高め、収益を最大化します。着手すべき時期は「今」です。 2. 生産性ゾーン 生産性最大化： 組織構造の再編、コスト削減、効率向上、資産稼働率の改善を行います。着手すべき時期は「今」です。 3. トランスフォーメーションゾーン 成長戦略： 組織の運営方法を再設計し、新製品の市場投入に向けた新たなオペレーションを実施します。この成長戦略の実行期間は今後9〜18か月です。 4. インキュベーションゾーン イノベーション戦略：
- [【デジタルインテリジェンス】CEO戦略における第5の企業資源](https://ichizoku.io/digital-intelligence-the-fifth-enterprise-resource-for-a-ceos-strategy/) - By Jay Revels, Ichizoku株式会社 CEO 重要なポイント デジタルインテリジェンスは、深層学習モデルと連携型エージェントを活用し、意思決定・行動・戦略遂行を支援する企業全体の能力であり、一過性の技術トレンドではない デジタルインテリジェンスは、単なるトレンドではなく、企業の機能や価値創出のあり方を再定義する、新たな戦略的リソースである デジタルインテリジェンスは、人材・プロセス・テクノロジー・データに続く「第5の企業資源」として、価値を増幅させる役割を果たす デジタルインテリジェンスの導入により、企業は静的な業務運用から、判断をインテリジェンスシステムやAIエージェントに委ねる動的な体制へと移行できる デジタルインテリジェンスを早期に導入した企業は、生産性・意思決定・イノベーションの各面において、複利的な恩恵を享受している 経営層200名への質問 「今後2年間において、生成AIが貴社のビジネス戦略に果たす役割を最も適切に表すものはどれですか？」 デジタルインテリジェンス（DI）とは？ 多くの経営者は、いまだに人工知能（AI）をツールや自動化プロジェクトの集合体として捉えています。このような狭い見方では、戦略的なインパクトやビジネス価値を持たない、断片的なパイロットプログラムが生まれがちです。それに対して、DIは深層学習モデルを企業全体に統合し、意思決定・タスクの遂行・自己改善を行うインテリジェントシステムを構築することを指します。 DIを導入することで、企業は判断力をインテリジェントシステムに委ねることが可能になります。これは、デジタルインテリジェンスの時代に入ったからこそ実現できるものであり、真の経済的ブレークスルーと言えるでしょう。 ガートナーは、DIを「組織がデータを意味のあるインサイトとアクションへと変換する能力」と定義しています。これは、単なる自動化をはるかに超える概念です。DIは、個別のユースケースにとどまるものではなく、継続的な使用と全社的な統合によって効果を高めていく、動的で複利的な能力として機能します。 以下の図は、従来の戦略マップを示したものです。企業のリソースがどのように連携し、社内、顧客、そして最終的には財務面での価値を創出するかを可視化しています。最終的な成果として目指すのは、企業価値の向上です。デジタルインテリジェンスは、これら4つの既存のリソース（人材・プロセス・テクノロジー・データ）を増幅し、新たな能力やビジネスモデルの構築、生産性の向上を可能にします。 DIは企業の4つの従来型リソースをどのように変革するのか 1. 人材 単純労働から拡張知能へ DIは、AIコパイロット、アシスタント、自律型エージェントをワークフローに統合することで、労働生産性を向上させます。マイクロソフトの2023年「ワークトレンドインデックス」によると、従業員の70％が「AIによって反復作業が自動化され、燃え尽き症候群の軽減に役立っている」と回答しています（Microsoft, 2023）。 AIの導入により、従業員はイノベーションや意思決定など、より付加価値の高い業務に集中できるようになります。また、パーソナライズされたAI支援により、実務を通じた学習やスキル向上も促進されます。人間と知的エージェントの協働関係を再設計することで、人間がより大きな影響力を発揮できる新たな可能性が生まれます。 【事例紹介】PwC 「AIアカデミー」PwCは社内に「AIアカデミー」を設立し、7万5,000人以上の社員を対象に、プロンプト設計、データリテラシー、AIツールの活用に関する研修を実施しました（PwC AI Academy, 2024）。 【引用】「AIの導入は一瞬で起きるものではありません。人々を慌てさせるのではなく、どうすれば時代に取り残されずにすむかを伝えるべきです。」— Tim Ryan, PwC米国会長 2. プロセス 硬直した手順から適応型ワークフローへ DIを既存の業務プロセスに統合することで、生産性の向上、コストの削減、収益の増加といった大きなリターンが得られます。AIエージェントは、固定化された業務手順を、リアルタイムで反応する柔軟かつデータ駆動型のプロセスへと進化させます。知的エージェントはリアルタイムの入力を継続的に監視し、それに応じて業務判断を動的に調整することで、人間の管理を超える俊敏性と効率性を実現します。 【事例紹介】UPS AIエージェント「ORION」UPSは自社の効率性を支えるAIエージェント「ORION」を導入しました。ORIONは物流における最も複雑な課題の一つである「リアルタイムでの配達ルート最適化」を解決するために開発されたものです。従来の静的なルート最適化システムとは異なり、ORIONは真のAIエージェントとして、過去のデータとリアルタイムデータに基づき、自律的に判断を下します。ORIONは以下のような変化し続ける複数の変数に対応しながら、意思決定を支援します。 荷物量：年末商戦などの季節的な急増がさらなるオペレーション上の課題を引き起こす 交通状況：突然の事故や渋滞が発生した場合には、即座にルートを変更する必要がある 天候：嵐や雪などの異常気象が配達スケジュールに大きな影響を与えることがある 3. テクノロジー コスト部門から予測型インフラへ これまで支援機能として位置づけられてきたエンタープライズITは、DIによって、戦略的な差別化要素へと進化しています。Google Cloudによると、IT運用にAI（AIOps）を活用している組織では、問題の検出と解決が40％高速化されていると報告されています。DIを導入することで、システムは障害を事前に予測し、自己修正する能力を持つようになり、稼働時間と信頼性の向上が期待されます。 【事例紹介】PayPal「予測型AIインフラ」PayPalはAIを活用してインフラ全体で不正取引を事前に検出・防止し、数億人のユーザーを保護しながら、より迅速かつ安全なデジタル決済を実現しています（PayPal AI, 2024）。PayPalの知的エージェントは、以下のような主要な処理を実行することで、詐欺を防止し、顧客を守っています。 顧客の行動をリアルタイムで評価 膨大なデータを活用し分析 変化する詐欺パターンに柔軟に適応 詐欺師による新たな攻撃パターンを発見するためにフィルターやルールを最適化 【引用】「AIによって、私のチームの1つはすでに生産性が30％向上しています。あらゆる業界、フロントオフィスでもバックオフィスでも、30〜40％の生産性向上が見込まれます。」― Dan Schulman,
- [【生成AI デジタルインテリジェンスオンボーディング】スケーラブルなAI導入成功のためのCEO向けロードマップ](https://ichizoku.io/digital-intelligence-onboarding-the-ceo-roadmapto-scalable-ai-success/) - By Jay Revels, Ichizoku株式会社 CEO 重要なポイント デジタルインテリジェンスオンボーディングは企業資源にデジタルインテリジェンスを組み込むための全社的な戦略である AIエージェントを一時的なツールではなく、人材・プロセス・データ・インフラを横断する企業機能として統合 データ、人材、インフラ、ガバナンスの整合性に基づくエージェント導入を推進 デジタルインテリジェンスオンボーディングによる競争優位性と新たな価値創出の実現 I. デジタルインテリジェンスオンボーディングとは？ 企業が新入社員を採用する際、オンボーディングはその後の成功の基盤となります。オンボーディング期間中には、新入社員に明確な目標や適切なツールへのアクセス、その役割に応じたトレーニングが提供されます。さらに、継続的なフィードバックが成長と改善を促します。 オンボーディングには数週間から数か月を要する場合もありますが、十分に時間をかけて実施されたオンボーディングは、より大きな効果をもたらします。逆に不十分なオンボーディングでは成長が停滞し、潜在能力を十分に発揮できません。 デジタルインテリジェンスの成功にも、オンボーディングの習得は不可欠です。AIエージェントも同様に、オンボーディングを必要とします。業務に必要なデータによるトレーニング、人間との業務フローへの統合、明確な役割とタスクの割り当て、必要なシステムへのアクセス、さらに継続的なガバナンスとモニタリングによって、安全かつ継続的に進化する仕組みが求められます。 人間と同じように、エージェントを深くワークフローに統合し、オンボーディングを適切に行った組織は、より大きな価値（グラフ中の紫の部分）を引き出し、競合に対して優位に立つことができます。 人間と同様に、AIエージェントを深く業務フローに統合し、適切なオンボーディングを実施した組織はより大きな価値（下記グレイ箇所）を引き出し、競合に対して優位に立つことができます。 「競争の舞台は、ますます激化しようとしています。あらゆる業務においてAIやデータを活用してイノベーションを進めない企業は、不利な立場に置かれるでしょう。」— Paul Daugherty, アクセンチュア テクノロジー＆イノベーション最高責任者 II. 軽量AIがスケールアップに失敗する理由 人工知能、特に生成AIには、多くの課題を解決する可能性があります。しかし、その可能性を実現するには、ライセンスを購入するだけでは不十分です。 問題の本質はテクノロジーに対する誤解にあります。多くの企業は、AIが即座に問題を解決してくれる存在だと考えて導入しています。しかし、あらゆる先進的なツールと同様に、AIについても「何ができるのか」「何が得意なのか」「それを効果的に機能させるには何が必要なのか」といった繊細な理解が欠かせません。多くのプロジェクトが失敗に終わるのは、こうした基本的な問いを検討せず、AIによる持続的かつ測定可能な貢献のための導入方法を十分に考慮していないためです。 これは人材育成におけるオンボーディングの重要性とも共通しています。企業でも新入社員のオンボーディングが不十分であることにより、定着率の低下や生産性の低下といった悪影響が生じています。一方で、社員の育成と生産性の向上に真剣に取り組む企業は、徹底したオンボーディングを提供しています。これと同様に、AIの導入に真剣に取り組む企業も、単にツールを購入するだけでなく、AIエージェントによる持続的な価値創出のために、しっかりとしたオンボーディングプロセスを構築する必要があるのです。 不十分なオンボーディングが招く失敗要因 コアシステムとの統合がなされていない 人間とAIのタスク分担が明確でない 設計不備や人間の監督不足により、エージェントの応答が不正確 マッキンゼーによる「2025年AIワークプレースレポート」によれば、AI成熟度に達している企業はわずか1％にとどまっており、今後はデジタルインテリジェンスを全社的に導入する企業が中心となって拡大していくと予測されています。 III. 効果的なDIオンボーディングの4つの柱とは？ たとえば、新たに営業担当者やソフトウェア開発者を雇い、「さあ始めてください」とだけ伝えたと想像してみてください。いきなり質問を投げかけたり、タスクを割り当てたりする状況です。新入社員は知識やスキルを持っているかもしれませんが、会社で成功するために不可欠なコンテキスト（背景情報）を欠いている状態にあります。 会社の従業員が成果を出すためには、会社やチームの目標、技術やデータのエコシステム、現在進行中のプロジェクトの状況、会社のガイドラインや文化的背景、さらにはチームメンバーの役割や目標など、さまざまな情報を理解する必要があります。こうした理解があってこそ、生産性と成果を最大化することが可能になります。 人間が自身の知識やスキルを組織やチームの目的に沿って適応させるのと同様に、AIエージェントも企業の業務ニーズに応じて出力をパーソナライズし、カスタマイズするためのコンテキストを必要とします。 Google、OpenAI、Anthropicが提供するディープラーニングモデルは、極めて高い知性と知識を備え、幅広い分野に精通しています。しかし、これらはあくまでゼネラリストであり、特定の企業やその市場における業務プロセスに精通しているわけではありません。こうしたモデルや、それに基づいて構築されたAIエージェントは、適切なオンボーディングを受けなければ、企業固有の現状や文脈を理解することはできないのです。 AIエージェントに適切なコンテキストを提供するにはどうすればよいのでしょうか？適切なオンボーディングに必要な要素とは？ 1. 企業データの統合 エージェントが賢明な判断を下し、人間のパートナーからの質問に対してより正確に応答するためには、CRM、ERP、HRIS、クラウドシステムなどにまたがる構造化・非構造化データへリアルタイムにアクセスできる必要があります。また、役割に適したデータにアクセスし、タスクを正確に実行するために、適切な権限を与える必要があります。 エージェントが賢明な判断を下し、人間のパートナーからの質問に対してより正確に応答するためには、CRM、ERP、HRIS、クラウドシステムなどを横断する構造化データおよび非構造化データにリアルタイムでアクセス可能であることが求められます。 また、それぞれの役割に応じたデータにアクセスし、タスクを正確に実行するためには、適切な権限を付与することも欠かせません。 2. 人間の労働力との連携 人間はAIエージェントと単に並んで働くだけでなく、それらを適切に管理する必要があります。AIエージェントは人間が現在担っている業務プロセスや業務フローに統合されなければなりません。 また、エージェントが担当するタスクと人間が担当するタスクを、明確に定義することが求められます。人間側はエージェントの管理責任を負い、その実行結果が正確であった場合も、そうでなかった場合も、モデルに対してフィードバックを提供する責任があります。 こうした体制を整えることで、AIエージェントの導入におけるパフォーマンス改善のための強固な基盤が構築されます。 3. AIエージェントの運用 AIエージェントは、企業の目標や人間のKPIと整合するように設計・構築される必要があります。エージェントをデジタルの同僚として位置づけ、タスクを割り当て、パフォーマンスを追跡し、フィードバックに基づいて調整を行い、業務を正確に実行するために必要なデータやシステムへのアクセス権を付与します。 ベンダーから提供されるAIエージェントは、企業の独自ニーズにどの程度適合し、どの程度カスタマイズ可能であるかを基準に評価すべきです。一方、ゼロから開発されるAIエージェントについては、技術要件とビジネス目標の双方を踏まえて設計されなければなりません。 4. 責任あるガバナンス
- [LLMアプリケーションとそのユーザーにとって、どの程度のハルシネーションが許容されますか？ ](https://ichizoku.io/what-level-of-hallucinations-are-acceptable-for-my-llm-application-and-its-users/) - Jay Revels（ジェイ・レヴェルス）とFrancisco Soares（フランシスコ・ソアレス）共著 LLMアプリケーションのプロダクトマネージャーや、LLMアプリケーションに資金を提供するビジネスリーダーは、社内ユーザーや顧客にアプリケーションを使用させることに躊躇することがあります。。なぜなら、LLMアプリケーションのハルシネーションがあまりにも頻繁に、予測不可能に発生するからです。。開発者がアプリケーションのハルシネーションを許容できるレベルまで減らしたと思った矢先、データセット、プロンプト、検索エージェントに小さな変更を加えただけで、LLMは再び望ましくないレベルのハルシネーションを見せ始めることがあります。私たちは以前、ハルシネーションを抑えるテクニックについて、以下の記事「Re-Rankingの力：RAGシステムを強化する」や「RAGの精度向上：チャンクサイズ、クエリ変換、チャンク方法のカスタマイズ」などを書きました。 さらに、LLMアプリケーション開発者は、アプリケーションに適切な目標ハルシネーション率の設定方法について、慎重に検討を重ねているところです。目標とするハルシネーション発生率が達成された場合、どのようなメリットがあるのか、達成されなかった場合、どのようなリスクがあるのかを知りたがっています。LLMアプリケーションプロジェクトの予算を確保し、その成功を確実に測定するための指標は何か、という重要な問いも出ています。 このブログ記事では、以下のことを解説します。 AHR（許容ハルシネーション率）の定義 適切な目標AHRの決定プロセス AHRを活用したプロジェクト予算獲得の戦略 AHRの継続的なモニタリングと報告手法の習得 ハルシネーションの許容率とは ハルシネーションとは、LLMが、事実に基づかない情報を生成する現象のことです。これには捏造された事実、誤った解釈、完全にでっち上げられた情報などが含まれます。大規模言語モデル（LLM）アプリケーションLLMアプリケーションにおける許容ハルシネーション率（AHR）とは、ユーザーが許容できる、ハルシネーションを含む生成された回答の割合を指します。ユーザーがハルシネーションを修正する時間が、LLMアプリケーションの生産性向上メリットを超えない場合、ユーザーはその割合のハルシネーションを許容します。 ハルシネーション発生率がAHRを超えるとどうなるか。生じるリスクとは？ ハルシネーション発生率がAHRを超えると、アプリケーションの採用率はすぐに低下します。 アプリケーション開発者やプロダクトマネージャーは、幻覚率が少し上昇したからといって、採用率が同じように少し下がると考えるべきではありません。 実際、ハルシネーション発生率が2～5％上昇すると、すぐに採用率がゼロになる可能性は十分に有り得ます。今日のほとんどのLLMアプリケーションは、これまで人間が行っていたワークフローやタスクを置き換えるものであることを忘れてはなりません。 したがって、LLMアプリケーションのユーザーは、LLMアウトプットの品質に大きな期待を寄せているのです。彼らは、アプリケーションの出力と、これまで手作業で行っていた作業の結果を比較します。もしアプリケーションがAHRを維持できなければ、彼らはすぐに手作業に戻すでしょう。もし導入がゼロになれば、導入が再開されるまで、アプリケーションの予測された生産性、時間の節約、または収益の利益は失われます。AHRを維持できないことによるその他のリスクには、次のようなものがあります。 ユーザーの信頼性と体験： ユーザーは、正確かつ信頼できる情報を求めてAI主導のアプリケーションに頼る。ハルシネーション発生率が高いと、信頼が損なわれ、将来的にユーザーが新しいアプリケーションの採用をためらう可能性がある。 運用の非効率性： AIシステムからの出力に一貫性がなかったり不正確であったりすると、情報を検証・修正するための追加リソースの必要性など、運用上のオーバーヘッドが増大する可能性がある。AHRの設定：許容可能なハルシネーション率を決めるには、以下のことが必要です。 法的・倫理的リスク： アプリケーションによっては、特に医療、金融、法律などの分野において、ハルシネーションが深刻な法的・倫理的影響を及ぼす可能性がある。 継続的改善の阻害： 展開プロセスの一環としてハルシネーション発生率を管理しないと、アプリケーションのROIの継続的な改善が阻害される可能性がある。 ハルシネーション発生率がAHRを下回るとどうなるか。 ハルシネーション発生率を許容範囲以下に抑えることができれば、アプリケーションのROIは向上する可能性があります。例えば、LLMアプリケーションが外部顧客向けの電子メールのドラフトを書くものとしましょう。ハルシネーションが少なければ、人間がハルシネーションの確認と修正に費やす時間は減少します。 つまり、ハルシネーション率が改善されるにつれて生産性が向上し、組織のROIが大きくなる可能性があるということです。 他のユースケースでは、ROI向上の機会がより限定されるかもしれません。例えば、LLMアプリケーションが作成した電子メールの下書きが、人間によるレビューなしで直接外部顧客に送信されることを想定しているとします。このユースケースでは、アプリケーションをリリースするためには、非常に低いAHRが必要になります。従って、AHRを多少改善したところで、ROIの大幅な改善は見込めないでしょう。どのようなユースケースであれ、AHRは、アプリケーションライフサイクルの中での要件の変化により、変動する可能性があります。開発者とプロダクトマネージャは、AHRの継続的なモニタリング、維持、最適化が成功とROI確保の鍵だと認識すべきです。 AHRの設定方法 許容ハルシネーション率の設定ハルシネーションをゼロにすることは不可能です。ほとんどのユースケースでは、ユーザーが有用な情報を得ることの妨げにならない限り、ある程度のハルシネーションは許容されます。ハルシネーションの影響は、それぞれのユースケースで考慮しなればなりません。例えば、クリエイティブやエンターテイメント分野においては、ハルシネーションが体験を向上させるかもしれません。ただし、医療、金融、法律相談などの分野では、ハルシネーションによる誤りが重大なリスクをもたらす可能性があります。 許容できるハルシネーション率は、アプリケーションのユースケースやーザーに大きく依存します。それは以下のような要因に影響されます。 アプリケーションの目的： クリエイティブ もしくはファクトのコンテンツ生成 正確性の重要性： 法律文書 / カジュアルな会話ボット ユーザーの期待値： プロフェッショナルな使用 / 個人的な使用 規制： コンプライアンスと法的影響 AHRの設定：許容可能なハルシネーション率を決めるには、以下のことが必要です。 ユースケースの深い理解： 開発者とプロダクトマネージャーは、ユースケースとLLMアプリケーションが自動化するワークフローを深く理解しなければならない。 ワークフローのどの部分が幻覚の影響を最も受けやすいか、また他の部分はより許容しやすいかを特定する。 ユーザーからのフィードバックとテスト： 幻覚の影響についてユーザーから洞察を集め、どの幻覚が許容され、どの幻覚が許容されないかについて意見を得る。 領域固有の基準： 業界特有の基準や慣行を考慮する。 反復的改善： 使いやすさを維持しながら、ハルシネーションを最小限に抑えるために、モデルと検索技術を継続的に改良する。
- [NexTech Week 2025 出展のお知らせ](https://ichizoku.io/news20250414/) - 東京ビッグサイトでのAI・人工知能EXPOに出展 AIエージェントのデバッグとテストをリードするテクノロジーソリューション企業のIchizoku株式会社（本社：東京都港区）は、2025年4月15日から17日まで東京ビッグサイトで開催される「NexTech Week 2025」に出展することをお知らせいたします。 出展概要 会 期 ：2025年4月15日（火）～17日（木） 各日10:00-17:00会 場 ：東京ビッグサイト（東展示棟）出展場所：AI・人工知能EXPO（小間番号：18-67）参 加 費 ：無料Ichizokuの詳細 : NexTech Week 2025展示会URL：https://www.nextech-week.jp/hub/ja-jp.html#/ 展示内容 AIエージェント導入・監視サービス、生成AIエンジニアによる業務委託型プロジェクト支援についての内容をご確認いただけます。また2025年3月、世界的なAI教育者 Andrew Ng氏 とDeepLearning.aiが主催する、AI開発者向けのカンファレンス AI Dev 25 が開催され、世界中から400人以上の優れたAI開発者がシリコンバレーに集まりました。そのカンファレンスのレポートを、弊社のHead of Client SolutionsのFrancisco Soares（フランシスコ・ソアレス）が弊社ブース内にて発表する予定です。 Ichizokuのブースでは、AI分野の最前線に立つ技術を体験し、今後のビジネスにどう活かすかのヒントを得ることができます。ぜひお越しください。お問い合わせ先Ichizoku株式会社担当:竹内 美稀 (Miki Takeuchi)メール: miki.takeuchi@ichizoku.io
- [【Arize AI + MongoDB】エージェントシステムの評価とメモリを活用した、堅牢なシステムを構築する方法](https://ichizoku.io/arize-ai-mongodb-leveraging-agent-evaluation-and-memory-to-build-robust-agentic-systems/) - 進化を続ける人工知能の世界では、エージェントシステムの品質が日々高度に成長し続けています。 エージェントシステムとは、システムの環境中のフィードバックから意思決定を行い、学習することができる自律型のシステムのことを指します。与えられた状況から自ら意思決定し処理を実行するソフトウェアのイメージを持っていただければ大丈夫です。 このエージェントシステムの成長と同時に、検索拡張世代（RAG）アプリケーションがより複雑になるにつれ、これらのシステムの重要な構成要素は「メモリ」になりました。 AIエージェントは、効率的に実行し、新しい状況に適応し、情報に基づいた意思決定を行うために、メモリに依存しています。 しかし、これらのシステムへの単一のリクエストは、ボンネットの下で何百もの呼び出しを生成する可能性があり、アプリケーションを構築し維持するAIエンジニアリングチームにとって、問題をデバッグし、それらがどのように出力に至るかを解析していくことは困難です。 より多くの企業がLLMアプリケーションを採用し、堅牢なエージェントシステムと統合し始める中、チームがアプリケーションのパフォーマンスを評価・分析し、かんたんに改善できることが必要不可欠です。 そこで「Arize AI」と「MongoDB」の組み合わせをご紹介します。 この2つは、AIエンジニアが自信を持ってLLMアプリケーションを開発し、展開できるよう支援します。 大規模言語モデル（LLM）が進歩し続ける中、効率的でスケーラブルなメモリシステムが必要になります。特にAIエージェントのメモリを管理する上で、ベクターデータベースはこの文脈において非常に重要です。 MongoDBは、完全なドキュメント型データストアと、統合された全文検索とベクトル検索機能をサポートする堅牢なクエリAPIを提供しています。この高性能なクエリAPIによって、これらのシステムを実装するための強力な基盤を構築することが可能になります。 高速かつスケーラブルな検索 RAGベースのシステムを扱うAIエンジニアにとって、MongoDBとArize AIの組み合わせは、生成AIのシステムを構築・維持するための強力なツールキットとして役立ちます。 MongoDBの「ベクトル検索」機能は、RAGアプリケーションが依存する関連ベクトルを、迅速でスケーラブルに検索します。 この機能は、リアルタイムでのメモリ呼び出しに不可欠です。 データ量が増大してもエージェントが効果的に実行することを可能にしてくれます。 Arize AIのプラットフォームは、エンジニアが入力から最終出力まで、AIシステムを通るデータの流れをトレースできる包括的な観測可能性ツールを提供します。 このトレース機能は、各コンポーネントが最終結果に与える影響を理解することが効果的なデバッグと、最適化に不可欠であるRAGのような複雑な多層アーキテクチャにおいて特に能力を発揮する機能です。 コンテクスチュアル（文脈的）メモリ管理と、インタラクティブ（対話的）なRAG戦略について ドキュメントベースのアーキテクチャと、ベクトル検索機能を組み合わせて活用することで、MongoDBの柔軟なスキーマはエージェントがコンテキストメモリを効率的に管理することを可能にします。 ベクトルと関連するコンテキストを含む複雑なドキュメントを保存することで、MongoDBはエージェントが相互作用の微妙な理解を維持し、一貫性とコンテキストを確実に認識できるようにします。 また、MongoDBのスキーマの柔軟性は、短期記憶と長期記憶の区別をサポートし、エージェントが記憶リソースを効率的に管理することを可能にします。これはまさしく人間と同じような脳の働きをしています。 一方、Arizeではコード生成、Q&Aの精度向上、埋め込みクラスタの要約など、タスクで事前にテストされたLLM評価ライブラリを提供しています。 LLM as a judgeのアプローチを活用し、LLMの評価者はアプリケーションからの出力を関連性・毒性（透明性・信頼性・ 安全性に欠けること）などに基づいて採点します。 LLMが生成する説明文では、出力が特定の方法で採点された理由を詳しく説明し、LLMアプリケーションがその出力に至った経緯や、複雑なシステムのパフォーマンスを向上させる潜在的な方法を理解するための目からウロコのメカニズムを提供します。 インタラクティブなRAGアプローチを採用することで、オンライン上にあるDBやAPIなどで外部ソースから、リアルタイムにアクセスして処理することができます。 これによって、常に変化するデータへのアクセスを必要とするアプリケーションに適した、最新かつ適切な回答を提供することができるようになります！ MongoDB Atlasを搭載したインタラクティブRAGは、大規模言語モデルの関数呼び出しAPIを使用して、チームがリアルタイムでRAG戦略を動的に調整することを可能にします。 Arizeの説明付き検索評価を活用すると、開発者はLLMが幻覚（ハルシネーション）を起こしたことをすぐに検知でき、呼び出しで使用された検索の正確なチャンク（データの集まり）を確認することができます。 これによって、LLMの誤りの原因を迅速に受け取ることができます。 トレースによるシステムの可視化について ArizeのLLMトレース機能は、LLMを使用したシステムの各コールを可視化します。 LLMアプリケーション開発とトラブルシューティングを容易にするために必要不可欠な機能です。 これは、オーケストレーションやエージェントフレームワークを実装するシステムにとっては特に重要です。これらの抽象化されたシステムでは、プログラムによるトレースなしではデバッグがほぼ不可能です。 それは、膨大な数の分散システムコールが隠蔽される可能性があるためです。 Arize Tracingはシステム全体を可視化します。 エージェントとレトリバーのパフォーマンスを評価 LLMの評価は、LLMアプリケーションを開発するチームにとって、パフォーマンスを理解するのにとても役立ちます。 Evalsは、正確性、幻覚（ハルシネーション）率、関連性、待ち時間、ツール呼び出しなど、複数の観点でアプリケーションを測定可能です。 これにより、チームはあらゆる段階でアプリケーションのパフォーマンスを評価することができます。 Arizeは、次のような評価フレームワークを構築しました。 研究に裏打ちされた事前テスト済みの評価者： Arizeの評価者は、干し草の山から針を探すようなLLMプロバイダーの最新の能力に対して徹底的にテストされています。 マルチレベルのカスタム評価： Arizeは、説明付きの数種類の評価を提供し、ユーザーはプロンプトテンプレートを使って、独自の基準に沿った評価基準をカスタマイズすることができます。 スピード重視の設計： Arizeの評価は、並列呼び出し、バッチ処理、レート制限により、大量のデータを処理できるように設計されています。
- [RAGの精度向上：チャンクサイズ、クエリ変換、チャンク方法のカスタマイズ](https://ichizoku.io/how-to-improve-rag-accuracy-in-llm/) - RAG（Retrieval Augmented Generation）は、大規模言語モデル（LLM）の能力を最大限に引き出す強力な手法として注目されています。 RAGは、LLMが外部の知識ベースを参照することで、より正確かつ詳細な応答を生成することを可能にします。しかし、RAGの精度を最大限に引き出すためには、いくつかの重要な要素を最適化する必要があります。 RAG（Retrieval Augmented Generation）の回答精度が低くなる原因としては、主に以下の要素が考えられます。 1. 検索（Retrieval）の精度: 関連性の低い文書の取得: クエリに対して適切な文書が検索されないと、生成される回答の精度も低下します。これは、検索インデックスの品質や検索アルゴリズムの性能に依存します。 重要な文書の欠落: 回答に必要な情報を含む文書が検索結果に含まれない場合、RAGは不完全な情報に基づいて回答を生成することになり、精度が低下します。 2. 生成（Generation）の精度: 言語モデルの能力: 使用する言語モデルの性能が低い場合、文脈を理解できなかったり、不自然な文章を生成したりする可能性があります。 不十分な学習データ: 言語モデルが学習したデータが少ない、または偏りがある場合、特定の分野やトピックに関する回答精度が低くなることがあります。 文脈の理解不足: RAGが検索された文書の文脈を正しく理解できない場合、誤った情報を回答に含めたり、質問の意図と異なる回答を生成したりすることがあります。 3. その他: 検索と生成の連携不足: 検索された文書と生成モデルの連携がうまく取れていない場合、回答の精度に悪影響を及ぼす可能性があります。 質問の曖昧性: 質問があいまいな場合、RAGが質問の意図を正しく解釈できず、適切な回答を生成できないことがあります。 情報の鮮度: 検索された文書の情報が古く、最新の情報が反映されていない場合、RAGは誤った回答を生成する可能性があります。 これらの原因は複合的に作用することもあり、RAGの回答精度低下の原因を特定し、改善するためには、それぞれの要素を注意深く分析し、適切な対策を講じることが重要です。 本記事では、RAGの精度向上に焦点を当て、チャンクサイズ、クエリ変換、そして具体的なチャンク方法のカスタマイズについて詳しく解説します。 これらの要素を最適化することで、RAGシステムのパフォーマンスを大幅に向上させることができるでしょう。 チャンクサイズの最適化 RAGシステムにおいて、チャンクサイズは非常に重要な要素です。チャンクサイズとは、知識ベースを分割する際の単位となるサイズを指します。 チャンクサイズが適切でないと、RAGシステムは適切な情報を検索できず、不正確な応答を生成してしまう可能性があります。 一般的に、チャンクサイズが小さすぎると、各チャンクに含まれる情報が少なくなり、関連性の高い情報を見つけることが困難になります。一方、チャンクサイズが大きすぎると、各チャンクに含まれる情報が多くなりすぎて、ノイズが増え、検索効率が低下する可能性があります。 最適なチャンクサイズは、知識ベースの内容やLLMの特性によって異なります。 具体的な最適化方法としては、以下のようなアプローチが考えられます。 試行錯誤による調整: さまざまなチャンクサイズを試してみて、RAGシステムのパフォーマンスを評価し、最適な値を見つける。 統計的な分析: 知識ベースの文の長さや単語の分布などを分析し、適切なチャンクサイズを決定する。 LLMの特性を考慮: LLMのコンテキストウィンドウのサイズや最大入力長などを考慮して、適切なチャンクサイズを設定する。 チャンクの種類と方法 チャンクにはさまざまな種類があり、それぞれに特徴があります。最適な方法を選択するには、知識ベースの内容とLLMの特性を考慮する必要があります。 固定サイズチャンク: テキストを等しいサイズのチャンクに分割します。知識ベースの内容が均一な場合に有効です。 文章分割: テキストを文章ごとに分割します。知識ベースの内容が文章で構成されている場合に有効です。 再帰チャンク: テキストを再帰的に分割します。知識ベースの内容が複雑な階層構造を持っている場合に有効です。 特殊チャンク: 特定のタスクに合わせたチャンク方法です。 セマンティックチャンク:
- [Re-Rankingの力：RAGシステムを強化する](https://ichizoku.io/the-power-of-re-ranking-enhancing-rag-systems/) - はじめに RAG（Retriever-Augmented Generation）システムにおけるRe-Ranking技術について掘り下げ、その技術が情報の関連性と正確性をいかに向上させるかを解説します。実装戦略の詳細な手順も紹介します。 Re-RankingでRAGのパフォーマンスを向上させる データセットのサイズと複雑さが増すにつれて、複雑なクエリに対して適切な回答を返すために関連情報を選別することが重要になります。この目的のために、Re-Rankingと呼ばれる技術群があります。これにより、テキスト内の重要なチャンクを理解し、文書を並べ替え、最も関連性の高いものを優先順位付けして返すことができます。 Re-Rankingには主に2つのアプローチがあります： Re-Rankingモデルを埋め込みモデルの代替技術として使用する。クエリとコンテキストを入力として受け取り、埋め込みの代わりに類似度スコアを返します。 LLM（大規模言語モデル）を使用して文書内の意味情報を効率的にキャプチャする。 これらのRe-Rankingアプローチを適用する前に、基準となるRAGシステムが第2のクエリに対して返すトップ3のチャンクを評価してみましょう： retriever = index.as_retriever(similarity_top_k=3) query = "Compare the families of Emma Stone and Ryan Gosling" nodes = retriever.retrieve(query) for node in nodes: print('----------------------------------------------------') display_source_node(node, source_length = 500) これはRe-Ranking前の出力です。各チャンクにはノードIDと類似度スコアがあります。 Node ID: 9b3817fe-3a3f-4417-83d2-2e2996c8b467 Similarity: 0.8415899563985404 Text: Emily Jean "Emma" Stone (born November 6, 1988) is an American actress and
- [マルチモーダルRAGアプリケーションの評価とトレース](https://ichizoku.io/automating-prompt-engineering-with-dspy/) - スピーカー Arize AIソリューション・アーキテクト Hakan Tekgul 概要 本プレゼンテーションでは、Hakan Tekgul氏が、マルチモーダルRAG（Retrieval-Augmented Generation）アプリケーションをデモ版から完全に機能する製品モデルへと移行する際の複雑さを取り上げています。このディスカッションでは、robustで信頼性の高いAIシステムの開発における厳密な評価と反復実験の重要性を強調します。 主要なポイント デモから本番環境への移行における課題: AIアプリケーションをデモ版から本番環境に移行させることは、特にテキスト、音声、画像を統合したマルチモーダルアプリケーションにとって重要な課題です。デモ版は可能性を示すかもしれませんが、本番環境への移行には、初期段階では明らかにならないパフォーマンス、安定性、スケーラビリティの問題に対処する必要があります。アプリケーションが実環境で確実に機能するようにするには、入念な計画と広範なテストが必要です。 小さな変更がアプリケーションのパフォーマンスに与える影響: ジェネレーティブAIアプリケーションのモデル、プロンプト、アーキテクチャのわずかな調整でも、下流に大きな影響を及ぼす可能性があります。このような変更は、パフォーマンス、ユーザーエクスペリエンス、顧客満足度、異なるユースケース間でのアウトプットの一貫性に影響を与える可能性があります。このことから、アプリケーションにプラスの影響を与えるような変更を実施する際には、慎重な評価と監視が必要であることがわかります。 評価駆動開発（EDD): Tekgul氏は、ソフトウェア工学におけるテスト駆動開発（TDD）にインスパイアされた方法論である評価駆動開発（EDD）のコンセプトを紹介します。EDDでは、開発者はデータセットを作成し、AIシステムの変更を評価するための実験を実行する。このアプローチは、変更の影響を定量化することを可能にし、開発者がシステムを反復的に改善するのに役立ちます。開発プロセスの中核部分として評価に焦点を当てることで、EDDはあらゆる変更がパフォーマンスの測定可能な改善につながることを保証します。 評価の判断材料としてのLLMの利用: 大規模言語モデル（LLM）は、コンテンツを生成するだけでなく、AIシステムの出力を評価するためにも利用できます。この役割において、LLMはシステムの出力を、関連性、正しさ、一貫性などの一連の基準に照らして比較していきます。このアプローチにより、より客観的でスケーラブルな評価プロセスが可能になり、LLMは、特に複雑なマルチモーダルアプリケーションにおいて、出力の品質を評価する「裁判官」のような役割を果たします。 マルチモーダルアプリケーションの評価: マルチモーダルアプリケーションの評価には、テキスト、音声、画像といった各モダリティに対する個別の評価だけでなく、すべてのコンポーネントが調和して動作することを確認するための複合的な評価も必要です。この包括的な評価戦略は、各モダリティがアプリケーションの全体的なパフォーマンスに効果的に貢献し、よりまとまりのある機能的なシステムを実現するために不可欠です。 反復実験の重要性: AIアプリケーションの開発と改良は、反復実験に大きく依存しています。複数の実験を行い、さまざまなモデル、プロンプト、検索戦略を比較することで、開発者は最も効果的な構成を特定することが可能です。この試行錯誤のプロセスは、アプリケーションの改良に役立ち、さまざまな条件やユースケースのもとで最適に動作することを保証します。 PhoenixによるEDDの実践的実装: Tekgul氏は、オープンソースツールであるPhoenixを使用した評価駆動開発の実践的なアプリケーションについて説明しました。Phoenixは、データセットの作成、実験の実行、経時的な変化の追跡を容易にします。EDDを実装するための実用的なフレームワークを提供することで、Phoenixは開発者が体系的かつ透過的にAIアプリケーションを改善できるよう支援します。このツールは、マルチモーダルアプリケーションの複雑性を管理する上で特に有用であり、本番環境でデプロイされる前に、すべての変更が厳密に評価されることを保証します。 LLM Recovery Labの見解 2024年の最も重要なトレンドの一つは、マルチモーダルモデルの急速な進化と採用です。私たちは、2022年半ばにリリースされたMidjourneyによって、テキストベースの生成モデルが主流になる初期段階を目撃しました。 その後、同年末のChatGPTの爆発的なインパクトが続いていました。2024年までには、テキストだけでなく、画像、音声、動画データを処理し理解することができる多数のモデルを含むように、状況は拡大しています。このマルチモーダリティへのシフトは、AI能力の大きな飛躍を意味し、より統合的で多用途なアプリケーションの新たな可能性を開きます。 マルチモーダルRAGアプリケーションへの進展は、特に開発と評価の分野において、多くの課題と機会をもたらします。これらのシステムは複雑であるため、作成と評価の両方に微妙なアプローチが必要です。開発の観点からは、パフォーマンス、安定性、スケーラビリティを維持しながら、多様なデータタイプをシームレスに統合できるアーキテクチャを設計することが不可欠です。各モダリティは、データ表現、処理、モデルの相互運用性という点でユニークな課題をもたらすため、この統合は自明ではありません。 評価の観点からは、このようなマルチモーダルシステムに適応するためには、各モダリティを個別に、また協調して考慮する洗練されたアプローチが要求されます。テキスト、画像、音声、映像の評価は単独で行うことはできず、システム全体のパフォーマンスに対するそれらの複合的な影響を綿密に評価する必要があるのです。このため、マルチモーダルなインタラクションの複雑さに特化した新しいメトリクスと方法論の開発が必要となります。例えば、画像が生成されたテキストを正しく補完することや、オーディオファイルがビジュアルコンテンツと整合することは、システムの一貫性と有効性にとって重要です。 プレゼンテーションで紹介された評価駆動開発（EDD）のコンセプトは、この文脈に特に関連しています。EDDは、ソフトウェア工学におけるテスト駆動開発（TDD）と類似していますが、AI開発の反復的で実験的な性質に合わせています。評価を開発ライフサイクルに深く組み込むことで、EDDは各反復と調整が厳密なデータ主導の評価に裏打ちされることを保証しています。Phoenixのようなツールは、開発者にデータセットの作成、実験の実行、長期的なパフォーマンスの追跡を行うための構造化されたフレームワークを提供し、このアプローチの運用に役立ちます。 さらに、評価者として大規模言語モデル（LLM）を使用することで、評価プロセスに新しい次元が導入されます。LLMは客観的な判定者として機能し、関連性、正確性、一貫性などの事前に定義された基準に対して出力を体系的に比較することができます。このアプローチは、従来の評価手法がデータの多様性と量に対応するのに苦労するような、マルチモーダルアプリケーションの複雑さにも対応できます。このようにLLMを活用することで、評価の客観性が高まるだけでなく、異なるモダリティ間でよりきめ細かく一貫性のある評価が可能です。 今後の展望として、反復実験の重要性はいくら強調してもしすぎることはありません。マルチモーダルRAGアプリケーションを改良するプロセスは、本質的に実験的であり、様々なモデル、プロンプト、検索ストラテジーを継続的にテストする必要があります。この反復的なアプローチは、実世界の複雑なユースケースに対応できる最も効果的な構成を明らかにするために極めて重要です。管理されたデータ駆動型の方法でこれらのシステムを適応させ、最適化する能力は、概念実証から本番へと移行する際の成功の鍵となるでしょう。
- [PromptLayerはどのようにLLM評価戦略を適応させるか](https://ichizoku.io/building-ai-knowledge-assistants-with-llamaindex/) - スピーカー PromptLayer 創業者 Jared Zoneraich 概要 本発表では、大規模言語モデル（LLM）の評価手法の適応と改良のためにPromptLayer社が採用した戦略に焦点を当てました。講演者のJared Zoneraich氏は、評価エンジニアリングの反復的な性質、評価におけるカスタマイズの重要性、プロンプトエンジニアリングにおけるドメインの専門知識の必要性について議論しました。 主要なポイント 評価エンジニアリングは反復的である: 評価エンジニアリングは、静的で1回限りのプロセスではなく、継続的で反復的なサイクルです。AIシステムのパフォーマンスと精度を向上させるためには、プロンプト、評価指標、データセットを継続的に改良する必要がある。AIモデルが進化するにつれて、そのアウトプットを評価するための手法も進化し、システムが長期にわたって望ましい基準を満たすようにしなければなりません。 評価のカスタマイズ: 一般的な評価データセットは、金融やヘルスケアなどの高度に専門化された分野など、特定のユースケースに適用した場合、不足することがよくあります。評価指標とデータセットを特定のアプリケーションコンテキストに合わせて調整することは、正確な評価のために極めて重要です。カスタマイズすることで、特定の分野特有の課題や要件を評価に反映させることができ、より信頼性の高い適切な結果を得ることができます。 専門家とのプロンプト： 効果的なプロンプトエンジニアリングには、何が正しい出力かを深く理解している分野の専門家からのインプットが必要です。これは、アウトプットの正確さとニュアンスが最も重要な、法律AIのような分野では特に重要です。専門家の知識がなければ、AIの回答が本当に正しいかどうかを評価することは難しく、効果的なプロンプトエンジニアリングには専門家の関与が不可欠となる。 システム構成要素の全体像： AIシステムの構築プロセスは、プロンプトテンプレート、評価フレームワーク、データセットなど、すべての構成要素を相互に関連する要素として考え、全体的に捉える必要がある。システムの全体的なバランスと有効性を維持するためには、あるコンポーネントを変更すると、他のコンポーネントの調整が必要になることが多い。このように相互に関連したアプローチは、より堅牢で適応性の高いAIシステムの構築に役立つ。 手作業によるデータのコンパイル: 自動化が進んだとはいえ、多くの先進的なチームは、ログやトレースからリグレッションデータセットを手作業でコンパイルしています。この手作業によるアプローチは、AIモデルの正確な評価と改良に必要な特定のデータを取得するために必要です。これは、AIの開発と評価のプロセスにおける人間の関与の継続的な重要性を強調しています。 回帰テストとバックテスト: 回帰テストとバックテストは、AIモデルの信頼性を確保するために不可欠な手法です。リグレッションテストは特定のエラーケースの特定と対処に重点を置き、バックテストは過去のデータを使用して、新しいアップデートがリグレッションを引き起こさないことを確認します。これらの手法を組み合わせることで、AIのアウトプットの品質と一貫性を長期にわたって維持するための強固なフレームワークが提供されています。 シングルタスク用のプロンプト: プロンプトのルーティングとして知られる、特定のタスクを実行するプロンプトの設計は、AIシステムのテストとメンテナンスを簡素化します。1つのプロンプトで複数のタスクを処理するのではなく、単一タスクのプロンプトに集中することで、開発者はシステムのパフォーマンスをより簡単に管理および最適化できます。このアプローチは複雑さを軽減し、AIの応答の信頼性を高めます。 継続的インテグレーションの課題: AIシステムは、継続的インテグレーション（CI）にとってユニークな課題を提示します。正しい出力が明確に定義されている従来のソフトウェアとは異なり、AIシステムはより曖昧な状況をナビゲートしなければなりません。このような課題にもかかわらず、CIと自動テストは、AIシステムの信頼性の高いデプロイメントを保証するために不可欠であり、これらのプロセスはAI開発に不可欠な部分となっています。 リアルタイムのフィードバックと反復: 企業は、AIモデルを反復的に改良するために、リアルタイムのユーザーフィードバックに依存するようになってきています。このアプローチにより、新たなエッジケースを継続的に特定し、モデルのレスポンスを改善することができます。リアルタイムフィードバックを開発サイクルに組み込むことで、企業は変化する状況にモデルを迅速に適応させ、多様で進化するタスクの処理に効果的であり続けるようにすることができます。 LLM Recovery Labの見解: 「評価エンジニアリング」は、LLMベースのアプリケーションの領域において重要な注目に値する重要な概念です。評価は、単にビジネス主導の指標ではなく、開発ライフサイクルの基本的な構成要素として扱われるべきものです。このような技術的な視点は、LLM アプリケーションがビジネス目標を満たすだけでなく、高水準の正確性、信頼性、およびパフォーマンスを維持するために不可欠です。 LLMの導入初期には、一般的なチャットボットのインタラクションの質を測るために、主観的な評価、いわゆる「バイブスチェック」に頼ることが多くありました。しかし、LLMアプリケーションが金融、ヘルスケア、法律分野など、より専門的で複雑なドメインに対応するように進化するにつれ、この初歩的なアプローチでは不十分になってきています。厳密でドメインに特化した評価メトリクスの必要性が最も重要になります。これらのメトリクスは、各ドメインのニュアンスや特定の要件を捉えるように注意深く設計されなければならず、LLMの出力がもっともらしいだけでなく、正確で文脈に適したものであることを保証しなければなりません。 本発表で重要なことは、評価エンジニアリングの反復的な性質です。ソフトウェアのテストフレームワークが、新機能やバグフィックスに適応するために継続的な改良を必要とするように、LLMの評価フレームワークも、モデルそのものとともに進化していかなければなりません。これには、プロンプトを改良し、評価データセットを更新し、モデルの機能やアプリケーションドメインの特定の要件の変化に対応するためにメトリクスを調整する継続的なプロセスが含まれています。 さらに、プロンプトエンジニアリングと評価プロセスへの専門家の参加は、過大評価となりません。高度に専門化された分野では、専門家の参加により、プロンプトと評価基準がその分野の複雑さと微妙さを正確に反映したものとなります。このような協力体制は、正確さが譲れない環境で効果的なパフォーマンスを発揮するLLMを生み出すために不可欠なのです。 2023年はLLMベースのアプリケーションの黎明期であり、あらゆる大企業が「AI搭載」ソリューションの構築に挑戦し、この新技術に予算を開放しました。しかし、2024年には、同じような企業が、AIへの投資に対するユースケースとリターンをよりよく理解することに重点を移しています。2025年を展望すると、評価の重要性はさらに高まると予想されます。堅牢な評価システムに反映されるビジネス指標が明確に定義されてこそ、AIアプリケーションはその潜在能力を最大限に発揮し、真の価値を提供することができます。厳密な評価エンジニアリングは、AIソリューションが効果的であるだけでなく、戦略的なビジネス目標に沿ったものであることを保証し、最終的にこの分野におけるイノベーションの次の波を推進する鍵となるでしょう。
- [OSS LLMを効率的にファインチューニングし、サービスを提供する方法](https://ichizoku.io/how-to-efficiently-fine-tune-and-serve-oss-llms/) - スピーカー Predibase社 機械学習エンジニア Arnav Garg氏 概要 本発表で、Arnav Garg氏はオープンソースの言語モデル（LLM）のファインチューニング提供に関数するテクニックと利点を探ります。特に特定のタスク用にカスタマイズされた場合、GPT-3.5やGPT-4のようなクローズドなモデルの性能を上回ることがよくあることが強調されています。 主要なポイント オープンソースLLMのファインチューニング: Garg氏は、オープンソースの言語モデルをファインチューニングすることで、GPT-3.5やGPT-4のようなクローズドなモデルと比較して、特にこれらのモデルが特定のタスク用にカスタマイズされている場合に、優れたパフォーマンスを発揮できることを強調しています。特定のドメインやアプリケーションのニュアンスに合わせてモデルをファインチューニングすることで、より正確で適切な出力を得ることができるため、オープンソースのLLMは開発者にとって強力なツールとなります。 ファインチューニングの費用対効果: オープンソースのLLMをファインチューニングする大きな利点の一つは、費用対効果です。ゼロからモデルを開発したり、高価なクローズドモデルに依存したりするのとは異なり、ファインチューニングに必要な計算リソースは大幅に少なくて済みます。そのため、大規模な言語モデルを一からトレーニングする際に一般的にかかる高いコストを負担することなく、強力なAIモデルを導入したいと考えている組織にとって魅力的な選択肢となります。 LoRAによるパラメータの効率化: Garg氏は、LoRA（Low-Rank Adaptation）テクニックを導入しており、モデルのパラメータのわずか0.1%〜1%を使用してファインチューニングを行うことができます。この手法は計算効率が高いだけでなく、コスト効率も高いです。LoRAは、パラメータの最小限のサブセットに焦点を当てることで、迅速かつ効率的なファインチューニングを可能にし、リソースが限られている小規模な組織でも利用できるようにします。 QLoRAによる低コスト展開: Garg氏は、QLoRAがモデルの重みを圧縮する技術であることを強調し、ファインチューニングと低コストのハードウェアへの展開を可能にしています。これにより、パフォーマンスレベルを維持しながら運用費用を大幅に削減できます。QLoRAを使用すれば、組織は高価なインフラを必要とせずに高性能なLLMを導入できるため、コスト重視のプロジェクトにとって有効なな選択肢となります。 Loraxフレームワーク:「Loraxフレームワーク」は、ファインチューニングされた数百のモデルを単一のGPUで提供するためのソリューションです。このフレームワークは、モデルのウェイトを動的にロードおよびアンロードすることでリソースの使用を最適化し、メモリを効率的に管理してコストを削減します。Loraxは、限られたハードウェア上で、それぞれが特定のタスク用にファインチューニングされた複数のモデルをスケーラブルに展開し、効率を高めてオーバーヘッドを削減します。 LLMの継続的学習: Garg氏は、LLMにおける継続的な学習の重要性を強調し、それを人間の従業員が時間とともに学習し適応していく方法に例えています。継続的な学習により、モデルは新しいタスクやデータ分布の変化に適応し、適切で正確な状態を保つことができます。この能力は、動的な環境において言語モデルの長期的なパフォーマンスを維持するために極めて重要です。 動的文脈内学習: Garg氏のプレゼンテーションでは、言語モデルのパフォーマンスを向上させるために、訓練事例を動的に収集し、利用することの利点について説明します。対象となる特定のタスクに関連する例を使用することで、モデルはエッジケースや特殊なタスクをより効果的に処理することができます。このアプローチは、正確で文脈に適した応答を生成するモデルの能力を向上させます。 学習データ（具体例）による影響: ファインチューニングや文脈内学習で使用される具体例の質は、モデルのパフォーマンスに影響する重要な要素となります。明示的な補正を提供する高品質で関連性のあるデータが最も有益であり、より良いモデル出力につながります。モデルに投入される学習データが最高品質であることを保証することは、パフォーマンスを最適化する上で極めて重要です。 オープンソースへのアクセス: Garg氏は、ファインチューニングツールやデプロイメントフレームワークが、オープンソースプロジェクトとしてアクセスしやすくなっていることを強調して締めくくりました。この傾向は参入障壁を低くし、企業や個人が大規模なリソースを必要とせずに高度な言語モデルを活用できるようにします。このようなツールが利用可能になることで、強力なAIテクノロジーへのアクセスが民主化され、さまざまな業界にわたってより広範なイノベーションが可能になります。 LLMRecovery Labの見解 2024年はオープンソースモデルにとって極めて重要な年であり、クローズドソリューションの強力な競争相手となりました。マイクロソフトのPhi、MetaのLlama、GoogleのGemini、そしてMistralの最新作のような一流企業のモデルによって、オープンソースのエコシステムは大きく成長しました。今日、Hugging Faceの830k以上のモデルのほぼ半分がTransformerベースであり、このフレームワークの広範な採用と開発が強調されています。 このオープンソースLLMへの転換は、GPUやその他の重要なハードウェアのコストが低下し、組織が特定のニーズに合わせてモデルをファインチューニングすることがますます現実的になっていることが主な要因となっています。企業がよりカスタマイズされた効率的なAIソリューションを求める中、大規模で汎用的なLLMから、特定のタスクに秀でるように細かく調整された小型言語モデル（SLM）への移行が顕著になっているのです。 これらのモデルは、オープンソースの他のモデルと並んで、適切なカスタマイズを行うことで、オープンソースのLLMが、ドメイン固有のアプリケーションにおいて、GPT-3.5やGPT-4のような最先端のクローズドモデルを凌駕できることを示しています。このようなカスタマイズされたアプローチは、医療、金融、法律分野など、精度と関連性が重要な分野では特に価値があります。 この傾向を促進する最も重要な進歩のひとつが、Low-Rank Adaptation（LoRA）のような効率的な再学習手法(Parameter-Efficient Fine-Tuning:PEFT）手法です。このアプローチは、モデルのパフォーマンスを向上させるための非常に効率的でコスト効率の高いソリューションを提供します。この手法は、リソースが限られている組織にとって特に有益であり、そのような取り組みに通常伴う経済的負担なしに高度なLLMを導入することができます。 2023年と2024年は、特定のユースケースに合わせたオープンソースモデルをファインチューニングし、提供するための舞台を整えました。この傾向が続くと、特定のドメインに正確に最適化された、コスト効率が高く高性能なAIソリューションのニーズによって、SLMの採用が増加するだろう。 2025年を見据えた場合、SLMへの移行傾向はさらに加速すると予想される。計算コストの低下、ファインチューニング技術の高度化、そしてMistral、Microsoft、Meta、Googleのようなリーダー企業のモデルの登場が相まって、より広範な採用が推進されるだろう。汎用のLLMからドメインに特化したSLMへのシフトは、単なるコスト削減戦略ではなく、AIアプリケーションにおいてより高い精度、効率性、スケーラビリティを実現するための重要なステップである。 継続的な学習と動的なコンテキスト内学習は、これらのモデルの関連性と性能を長期にわたって維持する上でも重要な役割を果たす。新しいタスクや進化するデータ分布に継続的に適応することで、これらのモデルは動的な環境の要求に対応できるようになる。ファインチューニングと文脈内学習において質の高い事例を重視することは、モデルの出力を最適化し、長期的な実行可能性と有効性を確保する鍵となる。
- [LlamaIndexによるAI知識アシスタントの構築](https://ichizoku.io/how-promptlayer-adapts-llm-evaluation-strategies/) - スピーカー ジェリー・リュー、ラマインデックス創業者 概要 Jerry Liu氏はLlamaIndexを使用したAI知識アシスタントの構築について掘り下げ、これらのシステムのパフォーマンスと信頼性を高めるための様々な高度なテクニックと方法論を推奨しています。 データ品質重視 Liu氏は、AIシステムにおける高品質なデータ処理と検索の重要性を強調しています。 大規模言語モデル（LLM）を扱う際の大きな関心事は、AIが誤った情報や誤解を招く情報を生成するハルシネーションを最小限に抑えることです。これに対処するためにLiu氏は、特に画像、表、図を含む複雑な文書に対する高度な構文解析技術の重要性を強調しています。 さらに、誤った出力のリスクを低減するためには、モデルに入力されるデータが正確で構造化されていなければなりません。 マルチモーダルアプリケーションとマルチモーダル埋め込み AIアプリケーションの進化に伴い、テキスト、画像、音声など様々な種類のデータを取り込むマルチモーダル化が進み、高度な索引付けと検索戦略の必要性が高まっています。Liu氏は、画像やその他の非テキストデータにテキスト記述を使用し、システムが多様なデータタイプを効果的に管理・検索できるようにすることの重要性について論じています。このマルチモーダルなアプローチにより、AIは幅広い入力に対応できるようになり、さまざまな文脈でより汎用的で効果的なものとなります。 詳細な計測と観測可能性 Liu氏は、AIシステムにおける詳細な計測と観測可能性の重要性を強調します。llamaTraceのようなツールは、エージェントの実行プロセスの各ステップを詳細にモニタリングし、評価することができます。このレベルのトレースは、デバッグとパフォーマンスの最適化に不可欠であり、開発者にシステムをファインチューニングし、効率的に動作させるために必要な知見を提供します。 エージェント型RAGシステム Liu氏は、基本的なRAG（Retrieval-Augmented Generation）システムに追加される洗練されたレイヤーである「エージェント型RAG」のコンセプトを紹介します。この拡張機能には、クエリ計画、ツールの使用、メモリ統合などのコンポーネントが含まれます。これらのエージェントのような機能を組み込むことによって、RAGシステムはより信頼性が高くなり、より複雑なタスクを処理できるようになります。これらの要素を追加することで、基本的なRAGシステムは、高度な意思決定プロセスが可能な、よりダイナミックで堅牢なツールへと変化していきます。 マルチエージェントシステム 最後にLiu氏は、複雑なタスクを達成するために複数の専門エージェントが協力するマルチエージェントシステムへの関心が高まっていることについて意見を述べました。このアプローチは、特にタスクが多様で専門的な知識を必要とするダイナミックな環境において、並列処理とより効率的なタスク管理を可能にします。複数のエージェントの長所を活用することで、これらのシステムはより複雑な課題に取り組むことができ、高度なAIアプリケーションにおいてますます価値が高まっています。 LLMRecovery Labの見解 LlamaIndexを使ったAI知識アシスタントの構築に関するLiu氏の議論は、LLMベースのシステムの進化するアーキテクチャを包括的に示しています。これらのシステムは、単純なAPIラッパーから洗練されたマルチエージェントフレームワークへと急速に進歩しています。 2023年はChatGPT APIラッパーの台頭が目立ちましたが、2024年はますます複雑化するタスクを処理するためにモジュラーアーキテクチャを活用するLLMベースのエージェントの出現が見られます。これらのエージェントは、AIシステム設計の大きな転換を意味しています。単一のコンテキスト内ですべてのタスクに対処しようとするモノリシックなモデルに依存する代わりに、LLMベースのエージェントはモジュール化された分散アーキテクチャを利用します。 各コンポーネント（エージェント）は、データの解析、検索、意思決定など、特定の機能に特化することで、より効率的なリソース配分と的を絞った最適化を可能にします。 この分野での重要な発展は、これらのエージェント間の相互作用を管理する調整（オーケストレーション）フレームワークの進歩です。AutoGPT、GPT Researcher、および同様のツールなど、この領域における初期の探求は、現在我々が目にするものの基礎を築きました。 これらの初期の取り組みにより、マルチエージェントシステムの可能性が実証されましたが、高いトークンコストの管理や、動的環境における信頼性の高いパフォーマンスの確保など、重要な課題も浮き彫りになりました。現在のコーディネーションフレームワークの世代は、これらの初期の教訓を基に、複数のエージェント間の複雑な相互作用を効果的に管理できる、より堅牢でスケーラブルなシステムの構築を目指しているのです。 LangGraphとllama-agentsは、LLMベースのエージェントをオーケストレーションする革新的なアプローチで躍進している新参者です。一方、Autogenは既存の主要プレイヤーとして、エージェント制御のための手法を改良し続けています。これらのフレームワークは、複雑なエージェント間通信と同期を管理し、遅延とトークンのオーバーヘッドを最小限に抑えながら、異なるエージェント間でデータがスムーズかつ効率的に流れることを保証するために非常に重要です。 RAG（Retrieval-AugmentedGeneration）の領域では、エージェント型RAGシステムの導入により、クエリ計画、ツールの使用、メモリ統合などの高度な機能を統合することで、さらに洗練されたレイヤーが追加されます。この進化により、よりダイナミックでコンテキストを意識した応答が可能になり、AI出力の精度と信頼性が向上します。 Liu氏が提唱するように、階層的な索引付けもここで重要な役割を果たし、特に異種かつマルチモーダルなデータソースを扱う場合、よりニュアンスのある正確な検索処理を可能にします。しかし、これらの進歩は、特にオーケストレーションレイヤーを最適化し、レイテンシーと運用コストを削減するという技術的課題をもたらします。 マルチエージェントシステムは本質的にリソース集約的であり、効率的な通信プロトコルは必要不可欠です。LangGraph、llama-agents、Autogenなどのオーケストレーションフレームワークは、これらの課題に取り組む最前線にあり、高いパフォーマンスを維持しながらエージェント間の複雑なやりとりを管理する技術を開発しています。 2024年の残りから2025年にかけて、いくつかの分野で大きな進展が期待されています。第一に、エージェント間のトークン効率の良い通信プロトコルのさらなる改良は、レイテンシーとコストを削減する上で極めて重要です。第二に、階層的でマルチモーダルなインデックス戦略の改善により、スケーラビリティと適応性が強化され、より広範なタスクをより高い精度で処理できるようになります。 最後に、これらの制御フレームワークが成熟するにつれて、生産環境におけるマルチエージェントシステムのよりシームレスで信頼性の高い統合が実現し、複雑な実用的なアプリケーションの新たな可能性が開かれることになるでしょう。
- [DSPyによるプロンプトエンジニアリングの自動化](https://ichizoku.io/evaluating-and-tracing-a-multi-modal-rag-application/) - スピーカー: Cyrus Nouroozi, Zenbase AI共同創業者兼CEO 概要 本発表では、Cyrus Nouroozi氏が、DSPyを用いた自動プロンプトエンジニアリング（APE）の可能性を探求し、その効率性、AIセキュリティにおける役割、評価指標の進化に焦点を当てます。APEがいかにプロンプト最適化プロセスを効率化し、AI開発における強力なツールとなるかが強調されています。 主要なポイント 自動プロンプトエンジニアリング（APE）は人間のプロンプトエンジニアを凌駕するAPEと人間のプロンプトエンジニアを比較した研究では、20時間の取り組み後、APEは40％優れたパフォーマンスを示しました。この大幅な改善は、プロンプトの最適化における自動化システムの効率性と有効性を強調するものであり、APEがより少ない手作業でAIモデルの品質とパフォーマンスを大幅に向上できることを示唆しています。 試行錯誤を減らすAPEの役割APEは、最適なプロンプトを効率的に探索できるため、手動によるプロンプトエンジニアリングに伴う従来の試行錯誤プロセスの必要性を低減します。この機能により、時間とリソースを大幅に節約できるため、開発者はAIモデルの他の側面の改良に集中することができます。プロンプト検索プロセスの自動化により、開発サイクルが加速し、全体的な生産性の向上が見込めます。 評価指標の動的進化Nouroozi氏は、「優れた」プロンプトの定義は時間とともに進化するため、評価指標を動的に調整する必要があると主張しています。プロジェクトが進行するにつれ、プロンプトの評価に使用された初期の評価基準は古くなり、最適なパフォーマンスを確保するために継続的な再評価が必要となります。 この進化は、継続的な最適化と、新しいタスクや課題に適応するAIモデルの妥当性を維持するために極めて重要です。 レッドチームとセキュリティにおけるAPEAPEはレッドチーム活動、特に言語モデルのハッキングやジェイルブレイク（脱獄）において効果的であることが証明されています。最適化された形態では、APEはこれらのセキュリティ関連タスクで6％の性能向上を示しました。これは、APEが従来の手法よりも効果的に脆弱性を特定・緩和することで、AIモデルのセキュリティを強化できる可能性を示しています。 APE開発の初期段階Nouroozi氏は、自動プロンプトエンジニアリングはまだ初期段階にあり、過去6〜12カ月で大きなトラクションを得たに過ぎないと主張しています。このことは、この分野には革新と発展の余地がかなりあることを示唆しており、将来の進歩によってAPEシステムの効率と能力がさらに向上するでしょう。 LLM Recovery Labの見解 2020年の論文 「Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks 」で紹介されて以来、Retrieval-Augmented Generation（RAG）の進化は、絶え間ない革新と最適化によって特徴づけられてきました。当初は、ChatGPT、Claude、Llamaなど、特定のアプリケーションに合わせた最適な言語モデルを選択することに重点が置かれていました。 この分野が成熟するにつれ、注目はRAGシステムの情報検索コンポーネントを強化する方向にシフトしていきます。これは、より優れた埋め込みモデルの開発、Okapi BM25のような従来のアルゴリズムとセマンティック検索を組み合わせたハイブリッド検索アプローチ、検索精度を向上させるカスタム類似度メトリクスの実装につながりました。 また、2022年にはChain of Thought（CoT）、2023年にはEverything of Thoughts（XoT）が導入されるなど、プロンプトエンジニアリングも年々大きな進歩を遂げています。 これらの技術は、プロンプトの構築と最適化の方法を改善する上で重要な役割を果たしています。しかし、このような進歩にもかかわらず、RAGシステム内のプロンプトを体系的に改善するには、顕著なギャップがありました。 そこで、自動プロンプトエンジニアリング（APE）が極めて重要な役割を果たすのです。 APEは、RAGシステムにおける最も永続的な課題の一つであるハルシネーションの減少に取り組む上で、画期的な進歩をもたらす可能性があります。モデルのファインチューニング、再トレーニング、再展開を必要とする他の最適化戦略とは異なり、APEはそのような必要なしにプロンプトを最適化することで、費用対効果の高いソリューションを提供します。 最も効果的なプロンプトを自動化し、インテリジェントに検索するAPEの能力は、より正確で信頼性の高いRAGシステムを実現するためのミッシングリンクとなり得えます。APEは、従来のプロンプトエンジニアリングに関連する試行錯誤のプロセスを最小限に抑えることで、時間とリソースを節約するだけでなく、開発サイクルの全体的な効率も向上させることが可能です。この自動化は、迅速な反復と展開が重要な環境において、特に有用であることが証明されるでしょう。 さらに、プレゼンテーションで強調された評価指標の動的な進化は、AIモデルの有用性と効果を維持するために極めて重要です。プロジェクトが進化するにつれて、プロンプトを評価する基準も進化しなければなりません。APEの適応性により、これらの評価基準を時間と共に調整することで、タスクがより複雑になったり、完全に変更されたりしても、AIモデルが最適化され、意図したタスクに沿った状態を維持することができます。 APEの可能性はプロンプトの最適化だけにとどまらず、AIのセキュリティにも大きな影響を与える可能性があります。特に脆弱性を特定し、ジェイルブレーキング（脱獄）のような潜在的な攻撃を軽減するレッドチーミングへの応用は、AIシステムの保護におけるAPEの有用性を実証しています。APEはセキュリティ関連のタスクで6％の性能向上を示しており、AIモデルのセキュリティ強化におけるAPEの役割は、これらのシステムがより機密性が高く、利害関係の大きい環境で展開されるにつれて、ますます重要になる可能性があります。 APEはまだ開発の初期段階にあり、ここ6〜12ヶ月の間に大きな進歩があったことを考えると、さらなる革新の余地が大いにあります。技術が成熟するにつれて、APEシステムの効率と能力はさらに向上すると予想されています。これにより、特にRAGシステムにおいて、APEがAI開発プロセスの標準ツールとして広く採用される可能性が高まっています。 将来的には、自動プロンプトエンジニアリングは、LLMベースのアプリケーションを開発する開発者のツールキットに不可欠な要素になる準備が整っています。2025年に近づくにつれ、大規模なモデルの再トレーニングや再展開を必要とせずにプロンプトを最適化できるAPEの能力は、AIの精度と信頼性を高めるための費用対効果の高いソリューションとして位置づけられるでしょう。APEは、特にハルシネーションを減らし、RAGシステムの全体的なパフォーマンスを向上させるという役割において、この分野に大きなインパクトを与えるものと期待しています。
- [AI時代の知的財産権、トレンドと対象法など](https://ichizoku.io/ai-for-ip-compliance/) - 生成AIは、現代の技術の中でも特に大きな影響を与えるものですが、その可能性と共に責任も大きくなり採用に悩んでる企業も多い。この技術をうまく活用し、社会に良い影響を与えるためには、しっかりとリスクを管理することが大切です。この記事では、生成AIのリスクを減らすための効果的な方法について、セキュリティや法的問題、そして倫理的な側面に焦点を当ててお話ししたいと思います。 歴史から学べることも多いです。過去の技術革新も、当初はリスクが伴っていましたが、私たちはその中で安全策を講じ、改善してきました。例えば、自動車が初めて登場したとき、シートベルトや信号、速度制限などはなく、事故が多発しました。でも、時間とともに社会は対応し、交通ルールや安全基準が整い、今では多くの人が安心して車を使えるようになりました。同じように、生成AIにも今後必要な対策を講じることで、安全に利用できる未来が築けると思います。さて、生成AI関連リスクをまず整理しておきましょう こちらは、生成AIコンテンツに関連する法的リスクを処理するためのシンプルなワークフローで、以下の4つのステップに基づいて構成されています：Prevent防止、Detect検出、Check測定、Approve承認。 1. PREVENT防止 (クリーンデータを使用したトレーニング) トレーニング用に、確認済みで法的に準拠した、ライセンスを取得したデータセットからデータを収集・調達します。 著作権で保護された情報、機密情報、または個人識別情報（PII）がトレーニングデータに含まれないよう、厳密なデータ審査プロセスを実施します。 データセットを定期的に監査し、法的および倫理的基準に準拠していることを確認します。例えば、OpenAIやAdobeは、生成AI技術を用いる際に、どのようにして著作権を保護し、著作権侵害を防ぐかに焦点を当てています。特にAdobeは「Content Authenticity Initiative（CAI）」を通じて、デジタルコンテンツのオリジン（出所）を保証する取り組みを推進しています 2. DETECT検出 (コンテンツの分解) AIを活用したツールを使用して、生成されたコンテンツを分析し、著作権に関する問題やプライバシー侵害などの法的問題を検出します。 AI生成の出力をテキスト、画像、コードなどの小さな要素に分解し、盗用や保護されたデータの意図しない使用を確認します。 高い類似度スコアや問題のある要素を持つコンテンツをレビュー対象としてフラグ付けします。 3. CHECK測定 (許容レベルを用いた定量化) コンテンツ生成における類似度の割合、知的財産権の問題、プライバシーの遵守など、法的リスクの許容閾値を定義します。 設定された閾値への近接度を計算することで、潜在的なリスクを定量化します（例：許容される類似度スコア）。 コンテンツが許容レベルに近づいた場合や超えた場合に、それを識別するリスクレポートを生成します。AdobeのCAIやTruepicのようなツールは、デジタルコンテンツのメタデータを分析し、編集履歴や出所を明示することで、コンテンツの真正性を担保することを目指しています。 4. APPROVE承認 (人間による介入とレビュー) フラグが付けられたコンテンツに対して、法務チームや専門家がリスクを評価するための人間によるレビュー手順を実装します。 法的および倫理的な境界内に収まるように、必要に応じてコンテンツを調整または修正し、モデルの再トレーニングも含めます。 法的違反が確認された場合、コンテンツの削除や修正のための明確な手続きを確立します。AdobeのCAIやTruepicのようなツールは、デジタルコンテンツのメタデータを分析し、編集履歴や出所を明示することで、コンテンツの真正性を担保することができます。 このワークフローは、自動化された検出と各重要なステップでの人間による監視を統合することで、生成AIコンテンツ作成における法的リスクを積極的に管理することができるでしょう。もう少しTinEyeとTruepicを確認しましょう。TinEye と Truepic の両方は、デジタルコンテンツの真正性と独自性を確認するためのツールを提供しており、特に著作権侵害、真正性、および誤情報に対する懸念が高まっている生成AIの文脈で役立ちます。これらのツールがAI生成コンテンツの確認にどのように役立つかは以下の通りです： TinEye: 画像の逆検索: TinEye は、ユーザーが画像をアップロードし、その画像や類似の画像をウェブ上で検索することを可能にします。これにより、AI生成コンテンツが既存の画像から派生しているかどうかを特定し、生成AIモデルが許可なく著作権で保護された素材を使用している場合を見つけるのに役立ちます。 画像の使用状況追跡: TinEye は、ユーザーが自分のコンテンツがインターネット上でどのように使用されているかを見るのを助けます。これにより、生成AIモデルがユーザーの画像を不正に利用していないか確認することができます。クリエイターは、不正使用を監視することで知的財産を保護できます。 派生作品の発見: 生成AIが元の画像をわずかに変更した場合、TinEye のマッチング技術は、その変更されたバージョンを見つけるのに役立ち、AIが元の画像に基づいて派生作品を作成したかどうかを追跡するのが容易になります。 Truepic: 真正性の確認: Truepic は、写真やビデオが元々提示された通りに撮影されたことを確認することに特化しています。AI生成コンテンツの場合、Truepic の技術は画像が操作されたり完全に生成されたものであるかを確認し、リアルと作成されたコンテンツを区別するのに役立ちます。 メタデータの認証: Truepic は、画像を撮影した時間、場所、およびデバイスなどのメタデータを安全に検証します。これは視覚メディアの信頼性を確立する際に重要です。生成AIは、現実的なフェイクを作成するためにそのようなメタデータを削除または操作することがよくあるためです。 ブロックチェーン統合: Truepic はブロックチェーン技術を使用して、画像やビデオが撮影された後、その整合性が保たれるようにします。これにより、AI がメディアに無許可の変更を加えることを防ぎ、コンテンツがそのライフサイクル全体で信頼できるものとして保たれることを保証します。
- [「RAGとは？生成AIの基本とハルシネーションの解説」初心者でもわかる！](https://ichizoku.io/retrieval-augmented-generation-utadahikaru/) - AI分野では、RAG、ハルシネーションといった用語が頻繁に登場します。しかし、これらの概念は一体何を意味しているのでしょうか？ そして、なぜ重要なのでしょうか？ここでは、AIに関するこれらの最も興味深く、時には難解な側面について、わかりやすく解説していきます。 いきなりRAGなんてやめましょう。まずは少しAIの話しします AIが必要な理由は、私たちの生活を便利にしたり、問題を解決したりするためです。たとえば、AIは大量の情報を瞬時に処理して、私たちが知りたいことに答えを出すことができます。しかし、時にはAIが正しくない情報を作り出してしまう「ハルシネーション」という現象があります。これは、AIが情報を持っていないときに、適当な答えを出そうとして間違えることです。つまり、AIが「作り話」をする、もしくは「推測」することです。 ちょっとした面白い例でRAGを理解しましょう 2000年代初頭の宇多田ヒカルの「Can You Keep A Secret?」のミュージックビデオを覚えていますか？未来的な世界観の中で、ロボットが宇多田に恋をし、彼は彼女との日常的なやり取りで使われた物を通してさまざまな記憶を思い出していきます。その物たちはロボットにとって記憶を呼び起こす手掛かりとなり、関係をさらに視覚化する助けとなっています。これはRetrieval-Augmented Generation (RAG)のメタファーとも言えます。簡単に言えば、RAGはAIにおいて、サポートとなるデータや記憶のような情報を呼び出すことで、応答の内容を豊かにし、文脈に沿ったものにする技術です。この場面では、車が記憶の手掛かりとして機能し、ロボットが宇多田との過去をシミュレーションできるようにしています。RAGの目的である「生成AIと検索サポートメカニズムの統合によるより正確に人間らしい応答」を反映していると言えるでしょう。 そもそもハルシネーションが起こる理由を整理しましょう ハルシネーションの原因をまとめると以下のとおり 訓練データの不足: AIは大量のデータから学習しますが、十分な関連情報がない場合、知らない質問に対して間違ったり、意味のない答えを生成したりすることがあります。 言語の複雑さ: 言語は複雑で、文脈によって意味が変わることがあります。AIが回答を生成しようとするとき、文脈やニュアンスを誤解して、もっともらしいけれど正しくない答えを出すことがあります。 過剰一般化: AIは、見たことのあるデータから一般的なパターンを学びますが、異なる文脈に対してそのパターンを適用してしまうことがあります。例えば、特定のタイプのテキストから学んだことを、別の質問に誤って使ってしまうことがあります。 ではRAGを登場させよう： RAG（情報検索強化生成）は、AIがより正確な答えを出せるようにする方法です。これは、AIが「信頼できる情報源」から情報を取り出すことを意味します。たとえば、AIが自分だけでは答えを見つけられないとき、RAGを使うことで、別のデータベースや知識の集まりにアクセスして、必要な情報を探し出して答えを提供することができます。 RAGの重要性 RAGはAIの信頼性を向上させ、誤回答を減らすのに役立ちます。特に、カスタマーサービスや検索エンジンなど、正確な情報が求められる場面で大いに役立ちます。 以下は、RAG（情報検索強化生成）がAIの結果を改善する方法の簡単な例です： チャットボットの例: お客さんがチャットボットに特定の製品についての情報を尋ねると、AIはその製品についての詳しい知識を持っていないかもしれません。しかし、RAGを使うことで、チャットボットは最新の製品情報や仕様が入ったデータベースにアクセスできます。これにより、チャットボットは正確で関連性のある回答を提供でき、お客さんの満足度や信頼を高めることができます。チャットボットがPDFのような知識データベースと連携すると、詳しくて整理された情報にアクセスできるようになります。たとえば、ユーザーが技術的な製品について質問すると、チャットボットはPDFに保存された製品マニュアルや研究論文、ユーザーガイドから関連する部分を取り出すことができます。これにより、チャットボットは正確で適切な答えを提供できるようになります。RAGを活用することで、チャットボットはこれらのPDFから特定のデータを取り出すだけでなく、複雑な情報をまとめることもできます。これにより、ユーザーが理解しやすくなります。たとえば、「最新モデルの安全機能は何ですか？」と誰かが尋ねた場合、チャットボットは製品マニュアルのPDFから関連する詳細を抽出し、包括的で正確な回答を提供できます。 画像生成の例: ユーザーが「空飛ぶ車がある未来の都市」といった説明をもとに画像を生成するAIを想像してください。AIが自分の訓練データだけに頼ると、正しい画像を作るのが難しくなるかもしれません。RAGを使うことで、AIは未来の都市や空飛ぶ車に関連する既存の画像や概念、スタイルを取り出すことができます。この取り出した情報と自分の生成能力を組み合わせることで、より魅力的で正確な画像を作ることができます。以下はStyle ReferenceというRAG、ある画像を参考にしてバリエーションを生成するプロセスが一例になります。RAGは思いどおりの生成・デザインコントロールでも使えると言えるでしょう RAGのUse Case RAGの応用は、医療、カスタマーサービス、教育など、さまざまな分野に広がっています。例えば、医療分野では、RAGが広範な医療データベースから得られたエビデンスに基づく推奨を提供することで、医療従事者を支援することができます。 詳細なユースケースの一つは、臨床意思決定支援システム（CDSS）であり、RAGは医療従事者が患者を診断し治療する際に支援します。例えば、医師が特定の病状や治療計画についての質問を入力すると、RAGモデルは関連する医療文献、ガイドライン、および患者データを検索できます。この機能により、AIは患者の独自の状況に応じたエビデンスに基づく推奨を提示することができます。Nature Medicineに発表された研究では、CDSSにRAGを統合することで、ケアの現場でリアルタイムのデータ駆動のインサイトを提供し、診断精度と治療結果の向上につながることが示されています。 さらに、RAGはテレメディスンサービスを強化することができ、チャットボットがパーソナライズされた健康情報を提供することを可能にします。例えば、患者が症状を説明すると、RAGを搭載したチャットボットは関連する医療記事やガイドラインを取得し、ユーザーにカスタマイズされた情報や次のステップを提示します。これにより、患者のエンゲージメントが向上するだけでなく、ケースのトリアージもより効果的に行えるようになります。 まとめると RAGの重要性は過小評価できません。これはAIシステムへの信頼を築くための重要なステップを示しており、AIが一貫した応答を生成するだけでなく、検証された情報に基づくことを確実にします。ハルシネーションの発生を減少させることで、RAGは人間と機械の間のより信頼できるインタラクションを促進し、将来的により高度なAIアプリケーションへの道を開きます。 結論として、AIが私たちの日常生活にますます深く統合されていく中で、Retrieval-Augmented GenerationのようなアプローチはAI開発の進展、精度の向上、ユーザーの信頼の確立において重要です。RAGを受け入れることは選択肢ではなく、人工知能の未来を形作るための必要不可欠な要素です。
- [生成AIの活用事例 – Lemonadeが保険業界でAIを駆使する方法](https://ichizoku.io/lemonade-ai-insurtech-insurance/) - 数年前、アメリカに「Lemonade」という名前の保険会社があることを知って驚きました。この名前の由来は、「伝統的な保険モデルに代わる、若い世代や価値志向の消費者に合った、爽やかで現代的な選択肢を創出するというブランド哲学を体現している」ようです。 Lemonadeの創業者たちは、AIが人間より効率的かつ正確に保険サービスを提供できると信じて、この会社を立ち上げました。2023年6月には、AIチャットボット「AI Jim」が、わずか2秒で保険のクレーム処理を完了させるという驚きの成果を達成しました。この会社の変革の旅について学んでいますが、それがいかに現実的で、顧客にとって意味のある価値を提供しているかに感銘を受けました。 AIの保険業界における未来 マッキンゼーによれば、AIが保険業界に与える影響は「壊滅的（seismic）」であり、保険の流通、引受け、決済だけでなく、保険会社自体のビジネスモデルも大きく変わると予測しています。具体的には、保険会社のモデルは「検出と修復」から「予測と防止」へと移行するとのことです。 マッキンゼーは、2030年の保険業界を予測し、AIがリアルタイムでリスクに基づいて保険料を調整し、自動運転車のドライバーに最も安全なルートを提案するシーンを描いています。また、生命保険も「生きた分だけ支払う」形で自動的に調整され、顧客は追加料金を即座に支払うことになります。さらに、駐車場の看板に車をぶつけた場合、車両が自動的に損傷を評価し、クレーム処理の指示をアシスタントが行うという未来が予測されています。2021年の予測時点では「視界の先」にあると言われたこの未来も、AI技術の進展により、現在ではますます現実味を帯びてきています。 さて、Lemonadeの革新的な取り組みを紹介します Lemonadeは、AIと機械学習を使用して2023年に世界記録を打ち立て、2秒で保険クレームを処理しました。AIチャットボット「AI Jim」は、クレームを評価し、ポリシー条件を確認し、数十の詐欺防止アルゴリズムを使用した後、支払い指示を顧客の銀行に直接送信しました。この革新的なInsureTech企業は、AIチャットボットとクラウドを組み合わせ、「ヒューマン・イン・ザ・ループ（HITL）」として顧客を巻き込み、保険会社と顧客間の不信感を排除しました。 クレームを提出する際、Lemonadeの顧客はチャットボットに何が起きたのかを伝えるだけで、カスタマーサービスセンターのオペレーターとの電話待ちや、部門間の転送、フォーム記入をする必要はありません。Lemonadeのクレームの約30%は、AIが詐欺防止アルゴリズムを実行した後、即座に支払われます。その他のクレームは、人間のエージェントにエスカレートされます。 AIが詐欺防止アルゴリズム Lemonadeの内部ワークフローマネージャーAI「Cooper」は、顧客サービス部門と保険請求部門のデータを統合し、不正の可能性を特定する能力を備えています。 ある顧客が、アパート外の車内から盗まれたスキューバギアが補償されるかを問い合わせた際、「補償される」との回答を受けました。その後、その顧客は保険に加入し、2週間後にスキューバギアの盗難請求を行いました。この請求は、顧客サービス部門のデータを基にAI「Cooper」が不正の可能性を指摘しました。 従来型の企業では、部門間のデータが分断されているため、このようなつながりは見逃される可能性がありますが、LemonadeのAI「Cooper」は、部門間のデータを統合して不正を検出することが可能です。 企業が顧客の全体像を把握するには、加入手続き、ポリシーの変更、苦情、過去の請求など、すべての顧客とのインタラクションを追跡し、それらのデータを統合する必要があります。これほど膨大なデータを人間が処理するのは困難ですが、AIはデータ量が増えるほど賢くなり、個々の顧客をより深く理解してサービスを改善すると同時に、不正の可能性をより正確に評価することができます。 AI Jimをだまそうとするな Lemonadeの完全デジタル保険請求プロセスは、非常にユニークで笑える不正のケースを見破ることに成功しました。2017年、ある男性がカメラと他の電子機器の盗難について保険請求を行い、Lemonadeは信頼と顧客満足を重視して、すぐに677ドルを支払いました。しかし、後にこの請求が不正であったことが判明しました。 同年後半、同じ男性が別のアカウント、偽名、偽のメールアドレスと電話番号を使い、カメラ盗難で5,000ドルの請求を行いました。この際、彼はカツラをかぶり口紅をつけていましたが、AI「ジム」がこの請求を拒否し、該当ユーザーをフラグしました。 それでも諦めず、同じ男性はさらに別の偽アカウントで3度目の請求を行い、今回はピンクのドレスを着用していました。AI「ジム」がこのケースをLemonadeの特別調査チームに報告し、その後、当局に引き渡されました。このエピソードはForbes誌にも取り上げられました。The Sixth Sense: Lemonade's 2019 Product In Review このようなケースは、従来の保険会社でも人間のエージェントによって見つけられる可能性がありますが、AI「ジム」のように迅速かつ効率的に解決することは難しいでしょう。AIを活用した完全デジタルの保険請求プロセスは、時間とコストを節約し、人間よりも効率的に不正を見抜くことが可能です。 機械学習を活用して保険のDNAを変革する Lemonadeは、顧客リスクの引受と保険請求の処理に機械学習（ML）を活用し、保険を「便利さのために購入するもの」へと変革しています。AIの活用は、保険業務におけるプロセスを大幅に改善します。これには、引受精度の向上による保険料価格の正確性の向上、迅速でペーパーレスなプロセスによる顧客体験の向上、不正の削減による請求コストの削減が含まれます。 保険契約を発行する際、Lemonadeはビッグデータを活用してリスクを予測し、損失を定量化します。これにより、顧客をリスクグループに分類し、関連性の高い保険料を提示します。この「均一な被保険者グループ」は、類似のリスク行動を共有する顧客から成り、AIアルゴリズムによって広範な顧客データが収集され、損失率（保険会社が支払った請求額と得た保険料の比率）をモニターすることで構成されます。データが蓄積されるほど、再帰的なリスクパターンが浮かび上がり、より正確な評価が可能になります。 LemonadeのCEOダニエル・シュライバーは、「我々は最初からAIのために作られていた」と語っています。LemonadeはフルスタックのAI駆動型企業であり、そのプロセスは高度に自動化されています。シュライバーは次のように言っています「もし会社をAIが深い情報にアクセスできるように設計していなければ、私たちがビジネスを構築してきたような深い洞察を得るのは難しいでしょう。」 Lemonadeは、AI駆動の引受業務とリスク管理ポリシーが時間とともにますます正確で、より利益を上げることを期待しています。すべてのクレームの98%は、すでにアプリ内のAI Jimから始まり、40%のクレームは「人間の介入なしで」処理されるとシュライバーは言います。 参考用 まとめ これはLemonadeがAIを活用して実現しようとしていることのほんの一部に過ぎません。要点は、顧客とのインタラクションやデータを複数のチャネルにわたって理解し、それに基づいてAIファーストのシステムを構築することです。そして、アンダーライティングからクレームに至るまで、デジタルの完全なジャーニーを提供し、摩擦のない体験を実現することを目指しています。
- [自動車業界編：エージェントAIによるUVeyeの自動車トラブルシューティング革命](https://ichizoku.io/agentic-ai-uveye-toyota/) - 2024年、エージェンティックAIシステムが最も注目されるバズワードとなり、受動的なAIツールから、自律的に目標を達成するエージェントへの進化が加速しています。従来のAIモデルとは異なり、これらのシステムは計画を立て、適応し、主体的に行動する能力を持ち、カスタマーサポートからソフトウェア開発まで幅広い業界で活用が進んでいます。その中で、自動車業界でもエージェントAI（Agent AI）が革新をもたらしています。これにより、車両診断、メンテナンスのスケジューリング、カスタマーサポートのプロセスが大幅に効率化され、顧客満足度の向上につながります。この記事を通じてUVeyeという会社ののAI駆動型車両検査：エージェントAIの実用例に関しまして情報を整理させていただきます そもそも自動車業界におけるエージェントAIの活用 エージェントAIは、自動車業界において以下のような用途で活用されています。 自動診断: AIエージェントが車両データを分析し、人間の介入なしに問題を検出 予測メンテナンス: AIが故障の兆候を予測し、事前に対策を実施 顧客対応: AIチャットボットが顧客の問い合わせ対応や、メンテナンス予約を自動化 これにより、業務の効率化、コスト削減、顧客体験の向上が実現されます。 UVeyeのAI駆動型車両検査：エージェントAIの実用例 UVeyeは、AIと高解像度カメラを活用した自動車検査システムを提供しています。車両がスキャナーの上を通過するだけで、車両下部、外装、タイヤなどを高精度に3Dスキャンし、錆やオイル漏れ、部品の欠損などの異常を瞬時に検出します。この技術により、検査プロセスの迅速化と効率化が可能となり、検査結果の信頼性も向上します。また、これらの検査は数秒で完了し、人手を介さず自動化されています。 さらに、UVeyeは車両全体を一度に検査するシステムの開発も進めており、サービスや中古車部門での活用が期待されています。UVeyeは、AIを活用した高度な車両検査システムを開発し、従来のメンテナンスおよび検査プロセスを変革しています。 UVEyeの概要をもう少し整理してみる 自動車両検査: 車両はUVeyeのドライブスルー型検査システムを通過 高解像度センサーとAIアルゴリズムが、機械的な不具合、外装の損傷、タイヤの摩耗、車両の下部の異常を自動的に検出 リアルタイム分析: AIエージェントが収集データを即座に分析 過去の車両データベースと照合し、異常を特定 シームレスな統合: UVeyeのシステムはディーラー管理ソフトウェアと統合可能 自動的にメンテナンス予約をスケジュールし、顧客とリアルタイムでコミュニケーションを実施 Agentワークフローの流れも以下のとおりだそうです 1️⃣ 車両到着 → 顧客がディーラーやサービスセンターに到着2️⃣ 自動スキャン → UVeyeのAI搭載システムが車両の外装、車体下部、タイヤをスキャン3️⃣ データ処理 → AIがスキャン画像を解析し、損傷や摩耗、異常を検出4️⃣ 瞬時にレポート生成 → 診断結果を含むデジタルレポートを作成5️⃣ 顧客＆サービスアドバイザー確認 → 顧客とサービス担当者が結果を確認6️⃣ メンテナンス提案 → システムが必要な修理や整備を提案7️⃣ 対応実施 → 顧客が承認し、必要なサービスを実施8️⃣ 車両引き渡し → サービス完了後、車両を顧客に返却 三つのAgent、Helios/Artemis/Atlasの統合ソリューション Helios（ヘリオス） Heliosは、UVeyeの車両下部検査システムで、車両の構造的な損傷、オイル漏れ、不正改造、密輸物の隠し場所などを検出するために設計されています。高解像度カメラとAI駆動の分析技術を活用し、車両のアンダーボディを数秒でスキャンし、微細な異常まで特定します。このシステムは、セキュリティチェック、国境検問、自動車整備センター などで広く活用され、安全性と運用効率を向上させます。 Artemis（アルテミス）
- [AIエージェントの性能を下げてしまう9つの落とし穴](https://ichizoku.io/mistakes-ai-agents-performance/) - これからお伝えする問題は、もしかすると身近に感じるかもしれません。 数ヶ月前、私たちはあるスタートアップと協力して、カスタマーサポート業務を支援するAIエージェントを開発していました。このエージェントの役割は、スタッフのスケジュール調整と、顧客からのサポートリクエストの管理でした。しかし、技術チームはエージェントの精度やレスポンス速度を改善しようと、何時間もデバッグに費やしたものの、思うような成果が得られませんでした。顧客を満足させるレベルに到達できず、開発工数とOpenAIの利用料だけを消費し続け、改善を願うばかりの状態。 こうした状況は、決して珍しいことではありません。AIエージェントを導入しようとする多くの企業が直面する問題です。 Ichizokuのエンジニアリングチームは、さまざまな規模・複雑さのAIプロジェクトに取り組んできました。その過程の中で、AIエージェントのデバッグ時に陥りがちな落とし穴を学びました。本記事では、AIエージェントのパフォーマンスと精度を向上させる際に企業が犯しがちなミスを紹介します。加えて、実際のプロジェクトで得た知見や、すぐに実践できる戦略、他業種のチームと協力する中で培った教訓もお伝えします。 AIエージェントの開発を始めたばかりの方も、すでに運用していて最適化を目指している方も、この記事を読むことで時間・費用・ストレスの削減につながるはずです。 それでは、AIエージェントのパフォーマンス最適化でよくある課題を見ていきましょう。以下の通りです。 LLMを効果的な「判定者」として適切に整合させていない テスト時の統計的厳密性に欠けている 実験コストが膨らみ過ぎている モデルのサイズとタスクの複雑さが合っていない ファインチューニング時にAPIレート制限に達してしまう GPUの構築にこだわり過ぎて、迅速な実験のためのインフラが整っていない 新しいモデルやインフラへの移行の難しさを過小評価している プロンプトエンジニアリングの体系的アプローチを欠いている モデル出力の統合・集約が適切に行われていない 1. LLMを効果的な「判定者」として適切に整合させていない 問題LLMを評価者として使用する場合、その評価基準が人間（使用者）の評価基準と合致していないと、意図していない結果や、信頼性の低い評価を招く可能性があります。モデル内部の「判定者」が、人間が正確だと思う、または価値があると考える基準を反映していない場合、誤った結果を最適だと判定する危険性があります。これによって、見た目には80%や90%の精度でうまくいっているように見えるシステムが、実際の現場では、ほとんどがランダムな回答で稼働していることに気づくことになります。 解決策評価プロンプトが、人間のフィードバックと厳密にテストされていることを確認しましょう。LLMが「良い」と判断するものは、人間の評価基準と密接に合致させておくべきです。このプロセスでは、評価基準を洗練させたり、モデルの判断を検証するために人間が介入する仕組みを組み込む必要があるかもしれません。LLMの評価能力を合致させることは、見落としてはならない基礎的なステップです。 2. テスト時の統計的厳密性に欠けている 問題一度きりの実験結果を決定的なものと判断してしまうと、誤った結論を導き出すリスクがあります。結果が良く見えても、それが統計的な偶然や単なる誤差である可能性があるためです。検証を怠ると、データのノイズを本物のパターンと誤認し、不適切な最適化を行ってしまう恐れがあります。その結果、プロジェクトの予算確保やMVP（最小限の実用的製品）の検証のために、貴重な時間とリソースを浪費してしまう可能性が生まれてしまいます。 解決策実験は一度きりでなく複数回行い、結果をしっかりと検証しましょう。ブートストラップや有意性検定といった統計的手法を活用し、得られた改善が偶然ではなく本当に意味のあるものかを確認することが重要です。このような厳密なアプローチを取ることで、ランダムな変動による誤った判断を防ぐことができます。しかし、こうした統計的な厳密さは、ソフトウェアエンジニアがAIエンジニアリングに移行する際に見落とされがちなポイントでもあります。しっかりとした検証を行う習慣を身につけることで、より信頼性の高い成果を得ることが可能となるでしょう。 3. 実験コストが膨らみ過ぎている 問題実験を続けているうちに、コストが想定以上に膨らんでしまうことがあります。実験結果を適切に保存したり、生産性の低い方法を排除したりする仕組みがないと、無駄な処理が増え、予算を使い果たしてしまう恐れがあります。例えば、APIの使用制限（レートリミット）に頻繁に引っかかったり、冗長なテストを繰り返したりすると、貴重な時間とコストを浪費することになります。こうした管理不足が続くと、実験を継続することが難しくなり、プロジェクト全体の進行が大きく遅れる可能性も出てきます。 解決策実験コストを最適化し、効率的に進めるための対策を取りましょう。 キャッシュの実装中間結果を保存できるツール（例：Pythonのディスクキャッシュなど）を使い、不要なAPI呼び出しを減らしましょう。 小さく始めるいきなり大規模なデータで試すのではなく、まずは小さなデータセットを使用してテストしましょう。いきなりフルスケールで実験を行うと、無駄なリソースを消費するだけでなく、エラーが発生した場合の影響も大きくなります。 最新ツールを使用するほとんどの評価フレームワークには、キャッシュや並列処理の仕組みが組み込まれています。もしそういった機能がない場合は、それは非効率なワークフローになっている可能性が高いため、より適したツールを検討しましょう。 4. モデルのサイズとタスクの複雑さが合っていない 問題モデルのサイズとタスクの難易度が適切に釣り合っていないと、期待するパフォーマンスが得られないことがあります。例えば、小さなデータセットに対して過度に大きなモデルを使用すると、データに過剰適合（オーバーフィッティング）し、汎用性のない不安定な結果を生み出す可能性があります。逆に、非常に複雑なタスクに対して小さなモデルを使うと、情報を十分に学習できず、精度の低い結果しか得られないことがあります。こうしたミスマッチは、リソースの無駄遣いにつながるだけでなく、AIの活用そのものが失敗する原因にも繋がります。 解決策データの量やタスクの複雑さに見合ったモデルを選択しましょう。 小規模なデータセットの場合大き過ぎるモデルは避け、適切なサイズのモデルを使用することをおすすめします。適切なサイズのモデルを選べば、少ないデータでも学習を効率的に進められ、過剰適合のリスクも減らすことができます。 タスクが複雑な場合小さなモデルでは処理しきれないため、より大きなモデルを活用し、データの深い部分まで学習できるようにします。 例えば、データが極端に少ない場合（20～40程度）は、プロンプトエンジニアリングやキャッシュなどの代替手段を検討し、少ないリソースでより良い結果を得られる場合があります。推測や仮定を避け、最適なアプローチを決定するために明確な評価基準を設定することが重要です。 5. ファインチューニング時にAPIレート制限に達してしまう 問題OpenAIのファインチューニングAPI（または同様のサービス）を使用していると、APIレート制限にすぐに達してしまい、作業が滞ることがあります。このため、反復的なサイクルが中断され、実験が遅くなることがあります。迅速な試行錯誤は、結果を最適化するために不可欠です。解決策ファインチューニングの進め方を工夫し、APIレート制限の影響を最小限に抑える方法を採りましょう。 バッチで更新小さな変更を逐一ファインチューニングするのではなく、変更をまとめて行うことで、実験の効率を向上させる。 実行の最適化実験を事前に計画し、最も影響力のある変更を優先して実施する。 割当領域の増加を検討レート制限が継続的に作業を妨げる場合、プロバイダーと交渉してAPI利用の割当領域を増加させてもらうか、柔軟な制限を設けた代替APIを検討する。 6. GPUの構築にこだわり過ぎて、迅速な実験のためのインフラが整っていない 問題GPUの構築にばかり注力しすぎると、実験のスピードや反復性が低下してしまいます。多くのチームがハードウェアの最適化にこだわるあまり、スムーズな試行錯誤を支えるインフラやプロセスの整備を後回しにしがちです。その結果、実験の効率が悪くなり、AIエージェントの改善が遅れてしまいます。 解決策実験を頻繁に行える環境を整え、最初からスケールに対応できるインフラを構築しましょう。 バージョン管理を徹底するプロンプト、データセット、コードの変更を追跡し、一貫性を保つ。 自動ログ記録を導入する実験結果を自動的に記録・集計し、重要な情報を見逃さないようにする。 標準化されたプロセスを確立する実験の実施からレビューまでのワークフローを統一し、比較・分析をしやすくする。 初期段階で適切なツールとプロセスに投資することで、素早い反復・最適化が可能になります。 7. 新しいモデルやインフラへの移行の難しさを過小評価している 問題AI技術は急速に進化しており、多くのオープンソースの選択肢が提供される中で、AIエンジニアはコスト管理やパフォーマンス向上のためにさまざまな選択肢を検討できます。しかし、すべてのユースケースに最適なモデルが1つだけとは限りません。たとえば、OpenAIの独自モデルからLLaMAのようなオープンソースのモデルに移行することは簡単ではなく、移行後には大きな変化が起こる可能性があります。プロンプト、評価フレームワーク、データパイプラインなど、さまざまな部分に大きな調整が必要になり、APIの小さな違いでも大きな問題を引き起こすことがあります。 解決策インフラを柔軟かつ移植性を考慮して設計しましょう。
- [【必見】世界で活躍するAIエージェントを構築する方法](https://ichizoku.io/【必見】世界で活躍するaiエージェントを構築する/) - 進化を続ける人工知能の世界では、エージェントシステムの品質が日々高度に成長し続けています。 エージェントシステムとは、システムの環境中のフィードバックから意思決定を行い、学習することができる自律型のシステムのことを指します。与えられた状況から自ら意思決定し処理を実行するソフトウェアのイメージを持っていただければ大丈夫です。 このエージェントシステムの成長と同時に、検索拡張世代（RAG）アプリケーションがより複雑になるにつれ、これらのシステムの重要な構成要素は「メモリ」になりました。 AIエージェントは、効率的に実行し、新しい状況に適応し、情報に基づいた意思決定を行うために、メモリに依存しています。 しかし、これらのシステムへの単一のリクエストは、ボンネットの下で何百もの呼び出しを生成する可能性があり、アプリケーションを構築し維持するAIエンジニアリングチームにとって、問題をデバッグし、それらがどのように出力に至るかを解析していくことは困難です。 より多くの企業がLLMアプリケーションを採用し、堅牢なエージェントシステムと統合し始める中、チームがアプリケーションのパフォーマンスを評価・分析し、かんたんに改善できることが必要不可欠です。 そこで「Arize AI」と「MongoDB」の組み合わせをご紹介します。 この2つは、AIエンジニアが自信を持ってLLMアプリケーションを開発し、展開できるよう支援します。 大規模言語モデル（LLM）が進歩し続ける中、効率的でスケーラブルなメモリシステムが必要になります。特にAIエージェントのメモリを管理する上で、ベクターデータベースはこの文脈において非常に重要です。 MongoDBは、完全なドキュメント型データストアと、統合された全文検索とベクトル検索機能をサポートする堅牢なクエリAPIを提供しています。この高性能なクエリAPIによって、これらのシステムを実装するための強力な基盤を構築することが可能になります。 AIエージェントを構築し、本番環境でスムーズに稼働させ続けることが難しいことだと感じていませんか？ 特にLLM（大規模言語モデル）を扱う場合、まだ未開拓の領域であり、多くの人が試行錯誤を通じて解決策を模索しています。本番環境でリリースした後でも、システムが不具合を起こしたり、予期しない動作をしたりすることがあります。 そのたびに不具合の原因を調査し、改修を重ね、再び挑戦する必要があります。開発と本番環境の境界線があいまいに感じられ、行ったり来たりを繰り返すことも少なくありません。 そんなときに頼りになるのが「Arize」というツールです。このツールキットは機能が非常に充実している反面、どの機能をいつ活用すればいいのか迷います。 私たち自身もAIを構築する際に多くの苦労を経験してきたため、この複雑さを乗り越えるお手伝いをしたいと思っています。 今回は、ArizeとPhoenixを活用してAIアシスタント「Copilot」を開発・改良・改善していく方法を分かりやすく解説していきます。成功を支える重要な機能やワークフローについて、順を追ってご紹介します。 AIエージェントのテストと反復改善 新しいスキルの開発や機能のテスト・反復改善において、私たちの頼りになるツールがPhoenixです。 Phoenixのトレース機能は、開発中に非常に貴重な洞察を与えてくれます。 新しいスキルを構築する際には、まず基本的なスケルトンとして機能するプロトタイプ（概念実証）から始めます。その後、テストと反復改善へ進みます。 私たちは、Copilotのコンポーネントを直接ノートブックに統合したテストフレームワークを構築しました。 これによりテストクエリを実行することが容易になり、トレースをPhoenixですぐに確認できるようになります。 この仕組みを使い、以下の3つを確認します。 ・データ関数がArizeから正しいデータを取得しているか ・ルーターが適切に関数を呼び出しているか ・関数が正しい引数を受け取っているか また、応答が期待通りかどうかも同時にチェックします。要するに、Phoenixのトレースは、何がうまく機能していて何が問題かを理解するのに役立ち、迅速かつ自信を持って反復改善を進めることを可能にします。 私たちにとって、Phoenixのトレースは開発で最も頻繁に使うツールの一つです。 この有能な機能が本番環境で稼働し始めたら、Arizeが主なツールとなります。 特にトレース機能は、ユーザーがCopilotとどのようにやり取りしているか、それが期待通りに動作しているかを確認するため、日常的に使用しています。 ここで重要になるのがデータの『フィルタリング』です。例えば、ユーザーのメールアドレスでフィルタリングして、内部利用と顧客とのやり取りを区別することがよくあります。その後、アプリケーションが実行したステップを確認し、それらが期待通りであることを確かめるためにトレースを精査します。 以前、トレーシングエンドポイントへの変更が原因で、いくつかの生成スキルに不良が生じ、大規模な不具合が発生したことがありました。 この問題を特定するために、トレースページでエラートレースをフィルタリングしました。それらを確認したところ、問題点が明確になり、迅速に解決することができました。 しかし、今後同じような状況を避けるために、エラーが5回以上発生した場合に通知を送るエラーモニターを設定しました。 これにより、さらに迅速に問題を発見・修正できるようになりました。また、ジャイルブレイク試行のような潜在的な問題を検出するために、評価ラベルも監視しています。 ダッシュボードとモニタリング 私たちの日々のワークフローの中で、もう一つの重要なことがあります。 それは、Arizeのダッシュボードをチェックして、使用パターンや利用状況をモニタリングすることです。 具体的には、Copilotのリクエスト数、平均クエリコスト、トークン数といった高レベルの指標を追跡します。これらの指標は、トラフィックやコストを把握するのに役立ちます。また、エラーレートもダッシュボード上で綿密に監視している重要な指標の一つです。 ダッシュボードで特に有用な洞察を得られる部分の一つが、スキルやユーザーごとのリクエスト数を追跡する機能です。このデータを視覚化することで、どのユーザーが最も活発に利用しているかを把握しやすくなり、フィードバックを集める際にも役立ちます。 また、どのスキルが最も注目を集めているかも一目瞭然です。初期段階では、このデータを活用して開発の投資先を特定し、最も効果的なスキルにリソースを集中させることができました。 エージェントのパフォーマンス評価 本番環境でのCopilotのパフォーマンスを把握するために、新しいデータに対して自動評価を実行するオンラインジョブを設定しています。 最初は、Phoenixの評価ライブラリを使ったシンプルなQA正確性評価から始め、Copilotがユーザーのクエリに正しく回答しているかを確認しました。 これにより、トレースをフィルタリングして詳細に分析し、パフォーマンスを時間をかけて改善することができました。また、注釈ツールを使用して評価結果をレビューし、不正確な評価を将来の改良に向けてマークすることも可能となります。 すべてのスキルが一般的なQA正確性評価に適合するわけではないため、その後、スキルごとに特化した評価を構築し、追加の評価レイヤーを導入しました。評価セットを精緻化することで、より包括的なモニタリングを実現しています。 データセットと実験の活用 日々のトレースレビューは、ユーザーの行動に関する仮説を立て、直感を養うのに役立ちます。このプロセスで特に便利なのがデータセット機能です。トレースをレビューする際、問題のあるトレースやバグのある動作、理想的でない結果など、パターンをよく見つけ、それらをデータセットに保存して後のテストに活用します。 例えば、サポートされていないユーザーのクエリをデータセットに集めることで、Copilotに欠けている機能を特定する手助けになります。データセットは様々な用途で用いられ、テスト用の例を集めるためにも、実験を行う開発ワークフローの中で活用するためにも使用されます。 実験は、モデルの更新やA/Bテストなど、変更をテストする際のメジャーな方法です。データセットと実験を組み合わせることで、アプリケーションの変更を体系的にテストできます。アプリケーションの一部を再現するタスクを定義し、成功を測定するために評価者を使用します。 問題解決や改善の検証において、実験は変更の影響を測定し、物事が順調に進んでいることを確認するための構造化された方法を提供してくれます。 実験によるモデル切り替えの処理 5月にOpenAIがGPT-4-oをリリースした際、私たちはその性能、速度、セキュリティの向上を活かすことを楽しみにしていました。しかし、モデルを切り替えることがもたらす影響を予想していませんでした。 生成AIが持つ多くのスキルが失敗し始め、いくつかは奇妙な反応を示し、指示を無視し始め、さらには完全に動作しなくなりました。
- [AIロードマップの道を切り拓く：Ichizokuと共に未来を築こう](https://ichizoku.io/ai-roadmaps-ichizoku-consulting/) - ２０１９年の面白いニュースを覚えていますでしょうか？「変なホテル」、多くのスタッフがロボットであることを売りにしていたが、色んなトラブルもあったニュース。宿泊施設で導入された「ちゅーりー」という名前の仮想アシスタントロボットが、予期せぬ問題を引き起こし、最終的に全客室から撤去されることとなった。この騒動の発端は、宿泊客からの苦情だった。ある宿泊客は、就寝中に「ちゅーりー」に何度も起こされたと不満を述べた。原因は、客のいびきに反応したロボットが「申し訳ありませんが、聞き取れません。ご要望をもう一度おっしゃってください」と繰り返し話しかけたためだった。さらに、別の宿泊客はTripAdvisorのレビュー欄に、「ちゅーりー」が宿泊客同士の会話に勝手に割り込んでくるという不満を投稿した。 その出来事から６年。テクノロジーの世界でまた最も注目を集めたな2文字、「A」と「I」。飛躍的な技術の進展・成長でAIを受け入れずにテクノロジーの未来を生き抜くことはできないと、誰もが知っている2025年に至った次第です。多くの企業・組織もその波に乗ってこの数年でChatGPTを導入し、独自のチャットボットを作成しましたが、これはAIの可能性のほんの一部に過ぎません。次の10年で差別化を図るには、包括的なAIロードマップの開発が不可欠です。このロードマップは、顧客向けアプリケーションだけでなく、内部プロセス、意思決定フレームワーク、戦略的計画も含むべきです。データインフラ、人材開発、倫理的考慮事項、部門横断的な統合など、重要な領域に取り組む必要があります。企業全体でAI採用に戦略的にアプローチすることで、組織は単純なチャットボットをはるかに超える変革の可能性を解き放ち、イノベーション、効率性、競争優位性を推進できるのです。 包括的なAIロードマップとIchizokuにできること 包括的なAIロードマップ、言うのが簡単で作るのが写真がない数千ピースのパズルに向き合うような、気の遠くなるような作業に感じるかもしれません。幸いなことに、AIロードマップを作成することはロケット科学ではありません。しっかりと計画を立てることで、AIへの好奇心を具体的で測定可能なビジネス価値へと変えることができます。 基本から始めよう: なぜAIロードマップが必要なのか 真実を言うと、AIは最先端のアルゴリズムを導入したり、最新ツールを購入したりするだけのものではありません。戦略、企業文化、そして業務プロセスを整え、スケールで価値を生み出すことが重要なのです。ロードマップがなければ、多くの企業は結果を出せない中途半端な実験に終わってしまいます。 AIロードマップをGPSのようなものだと考えてください。それは次のことを教えてくれます： どこから始めればいいのか？ 次にどこへ進むべきなのか？ 途中での間違った方向や行き止まりをどう避けるか まずは作成、その後の運用されたAIロードマップは、AIを単なるツールとしてではなく、組織のあらゆるレベルで真のデジタルトランスフォーメーションを促進する触媒として活用し、その変革力を最大限に引き出せるようにビジネスを位置付けます。 Ichizokuのアプローチ IchizokuがITコンサルティング、デジタルトランスフォーメーション、エンタープライズ戦略の最前線で経験を積んだチームであり、企業の技術的成長を可能にし、加速させる支援を行っています。IchizokuがAIを困難なパズルから実行可能なロードマップに変える方法はハイレベルでまとめる以下の通りです： 文化的な整合性を確保する – AIを効果的に活用するために、人材、プロセス、ワークフローを準備します。 現在の状況から始める – 現在の能力、目標、課題、ギャップを評価します。 AIが測定可能な価値を提供できる重要な領域を定義する – 派手な機能を追加するのではなく、ビジネス課題を解決することに焦点を当てます。 AI戦略を既存のエコシステムに統合する – 進行中のデジタル化イニシアチブを中断させるのではなく、強化することを目指します。 具体的にAIロードマップの６つの主要なワークストリームを詳しく見ていき、それぞれにおいてIchizokuがどのように重要な役割を果たせるかを解説します。 ① AI戦略：北極星を定義する 全体像から始めるのが我々のアプローチです。組織はAIを使って何を達成したいと考えていますか？業務の効率化、顧客体験の向上、あるいは全く新しい収益源の開拓を目指していますか？AI戦略は、全体的なビジネス戦略と一致しているべきです。 これは一度きりの作業ではありません。あなたの戦略は、ビジネスの成長とAIの取り組みから学びながら進化します。これをあなたの北極星として捉え、すべての意思決定を導くものと考えましょう。 Ichizokuが提供できる支援：Ichizokuは豊富な業界経験を活かし、AI戦略に適した北極星の指標を定義するためのコンサルティングとガイドを提供できます。あなたのビジネス目標に共鳴する実行可能なシナリオとベストプラクティスを提案し、AIの取り組みが実用的であり、広範な目標と一致するようにサポートします。 ② AIの価値：ROIを見せて AIは、その提供する価値が大きいほど有効です。特定の課題や機会に対応するいくつかのインパクトの大きいユースケースから始めましょう。パイロットを実施し、成功を測定し、アプローチを改善します。 時間が経つにつれて、焦点を短期的な成果から、長期的な価値を継続的に提供するAI製品のポートフォリオ構築へと移行します。「単発プロジェクト」から持続可能なAIエコシステムへの移行こそが、真の成果を生む場所です。 Ichizokuが提供できる支援：戦略的なテクノロジーパートナーとして、インパクトの大きいユースケースを特定し、AIの価値を組織内で検証するための小規模なPOC（概念実証）の実施を支援します。私たちはエンドツーエンドのサポートを提供し、AIの取り組みが効果的にスケールするようにサポートします。これにより、大規模な内部チームを構築することなく、アジャイルに成果を達成できます。 ③ AI組織：Actionチームを作る AIはある部門で進めるミッションではありません。組織全体で適切なスキル、リソース、そして協力が必要です。まず、どのような専門知識が必要かを特定しましょう。それらの能力を社内で構築しますか、それとも外部パートナーに頼りますか？ 実践コミュニティを確立し、全員を調整します。AIの取り組みが拡大するにつれて、役割、責任、プロセスが明確なより正式な運営モデルへと進化させることができます。 Ichizokuが提供できる支援：IchizokuはAIスキルの人材サービスを提供し、トップクラスのAI人材と専門知識にアクセスできるようにします。社内チームをゼロから構築する手間を省き、AIの取り組みでのインパクトのある成果と成功を確実にします。必要に応じてリソースをスケールできる柔軟性を提供し、AIの旅をスムーズでコスト効果の高いものにします。 ④ AIエンジニアリング：堅実な基盤を作る 揺れる地盤の上に高層ビルを建てることはできません。同じことがAIにも当てはまります。まずはサンドボックス環境を設定して実験し、再利用可能なアーキテクチャ特定がベースライン。スケールを拡大する際は、ModelOps、AIの可観測性、プラットフォームエンジニアリングなどの実践に焦点を当て、AIの取り組みが堅牢でスケーラブルであることを確保します。 Ichizokuが提供できる支援：Ichizokuでは、ビジネスのニーズに合わせたカスタマイズされたソリューションを設計します。私たちの目標は、最適な効率と効果を提供し、AIの基盤が強固でスケーラブル、そして将来に対応できるものとなるよう支援することです。 ⑤ AIデータ：ゴミを入れればゴミが出る AIは、与えられたデータが良いものであるかどうかによって、その効果が決まります。組織のデータ準備状況を評価し、AIのユースケースに対応できるようデータの準備プロセスを実施しましょう。進行するにつれて、データの可観測性や高度な分析能力に投資し、データが信頼性があり、実行可能であることを確保します。 Ichizokuが提供できる支援：Ichizokuのアプローチとしてテストデータ生成からすべてのデータ課題に対応するよう設計されています。高度な分析とRAGサービスを提供します。ハルシネーションの測定できるようにArizeというプラットフォームでリアルタイムでAIシステムの監視・評価を可能にします。 ⑥ AIの人材と文化：変化は難しい 正直に言いましょう—AIは人々の働き方を変革します。従業員は新しいスキルを学ぶ必要があり、いくつかの役割はシフトし、組織文化も適応しなければなりません。まずは、タレントギャップを特定し、それに対処するための計画を立てましょう。変革管理戦略を実施して移行をスムーズにし、AIが従業員に与える影響を継続的に評価します。 Ichizokuが提供できる支援：要相談 まとめ
- [金融業界で生成ＡＩの活用事例：HITL Human In The Loopの重要性](https://ichizoku.io/金融業界で生成ａｉの活用事例：hitl-human-in-the-loopの重要性/) - 生成ＡＩの台頭により、金融業界でも大きな変革が進行しています。特に、2023年3月に発表されたモルガン・スタンレーの内部向けバーチャルアシスタントは、業界で注目を集めました。このアシスタントは、同社の財務アドバイザーが迅速に顧客対応できるよう、約10万件のリサーチレポートや文書データベースから必要な情報を提供するツールです。2023年9月に本格稼働し、金融機関におけるAI活用の新たな可能性を示しました。 銀行業界におけるチャットボットと生成ＡＩの進化 2023年半ばに米国消費者金融保護局（CFPB）が発表した調査によると、米国の主要商業銀行10行すべてがチャットボットを導入済みであり、2024年までに37％の顧客がチャットボットを利用したとされています。しかし、従来のルールベースのボットには技術的な限界があり、時間の無駄や誤情報の提供などの苦情が相次ぎました。それでも、人間の対応と比較して年間80億ドルのコスト削減が見込まれています。 新たに登場した生成ＡＩを活用したチャットボットは、こうした課題を解決しつつあります。例えば、ある欧州の銀行では、ルールベースのチャットボットを生成ＡＩに置き換えることで、顧客の質問に対する回答精度が20％向上。さらなる改善で倍増を目指しています。 内部ツールとしての生成ＡＩ モルガン・スタンレーでは、「Morgan Stanley Assistant」が金融アドバイザーとサポートスタッフ向けに提供され、膨大な情報への迅速なアクセスを可能にしました。ユーザーは、キーワード検索ではなく、人間と話すようなフルセンテンスで質問を投げかけることが求められます。このツールは顧客とのやり取りを効率化し、アドバイザーの業務効率を高めています。同社はさらに、ミーティング要約やフォローアップメールの作成を支援する「Debrief」と呼ばれるツールの試験運用も進めています。 ゴールドマン・サックスもスタート！ ゴールドマン・サックスでも、社内エンジニア向けに自然言語を使ってコードを書いたり、ドキュメントを生成するツールを開発中です。同社は現在、12以上の生成ＡＩプロジェクトを進行中で、規制の厳しい金融サービス分野における「慎重なアプローチ」を採っています。 HITL（Human in the Loop） 同社は、2023年11月時点で12以上のAIプロジェクトに取り組んでおり、その中で最も進展しているものには、自然言語コマンドを使用してコードを生成するツールやドキュメントを作成するツールが含まれます。これらの取り組みは主に社内向けであり、顧客向けにはまだ公開されていません。ゴールドマン・サックスの応用イノベーション部門の共同責任者であるジョージ・リー氏は、金融業界の規制環境を考慮し、慎重かつ意図的に進めていると述べています。また、これらのプロジェクトでは、AIシステムに人間が関与する「ヒューマン・イン・ザ・ループ (HITL)」モデルを採用し、リスク管理や必要に応じた介入を行っています。このような取り組みは、金融サービスの質を高め、業務プロセスを効率化するための重要な一歩となっています。 「ヒューマン・イン・ザ・ループ (HITL)」は、ゴールドマン・サックスの生成AIプロジェクトにおける重要な要素となっています。このアプローチでは、AIが生成した結果を人間が監視し、必要に応じて介入することで、高精度かつ信頼性の高い成果を確保します。例えば、自然言語処理を用いたツールがコードや文書を生成する際、人間の専門家が最終的な確認と修正を行うことで、誤りやリスクを最小限に抑えることができます。特に金融業界では、規制要件や顧客情報の取り扱いに高い慎重さが求められるため、このような二重のチェック体制が不可欠です。HITLは、AIの効率性と人間の判断力を組み合わせることで、安全性を維持しながらイノベーションを推進する効果的な方法といえます。 ゴールドマン・サックスの生成AIプロジェクトにおける「ヒューマン・イン・ザ・ループ (HITL)」の活用例として、自然言語処理を用いたコード生成ツールが挙げられます。このツールでは、開発者が英語のコマンドを入力すると、AIがコードを生成しますが、その後、人間のエンジニアが結果を検証し、必要な修正を加えます。また、ドキュメント作成ツールでも同様に、AIが初期案を生成し、人間がレビューと編集を行うプロセスを取り入れています。このHITLモデルにより、AIが提供する効率性を活かしながら、金融業界に特有の高い精度や規制遵守の要件を満たすことが可能となっています。この取り組みは、リスク管理とAIの能力活用の両立を目指す最前線の事例と言えるでしょう。 参考URL：Goldman Sachs on GenAI Deployment. 顧客対応と生成ＡＩの未来 銀行業界が顧客向けの生成ＡＩを導入する際にはリスクが伴いますが、ガードレールを設けることで成功を収めている事例もあります。例えば、ING銀行とマッキンゼーの共同プロジェクトでは、AIを活用したチャットボットを迅速に構築・導入し、顧客体験を向上させました。導入からわずか7週間で、従来のソリューションよりも20％多くの顧客が待ち時間を短縮し、即時対応を受けられるようになりました。 最後 Human-in-the-Loop (HITL)は、特に金融や医療などの高リスクな業界において、今後も重要な要素であり続けると考えられます。生成AIは進化し続けていますが、HITLは重要な意思決定において人間の判断が必要となる場面、特に倫理的な配慮や複雑な問題解決、規制遵守に関わる場面で欠かせません。特に金融業界では、AIモデルに対して人間の監視が必要であり、リスクを軽減し、変化する規制に適応するための重要な役割を果たします。AIはルーチン作業においては人的介入を減らす可能性もありますが、感情的な配慮やニュアンスを必要とする領域では、HITLが依然として必要であり、信頼と責任を維持するために重要な役割を担うでしょう。 生成ＡＩは、効率と顧客体験の向上という点で、銀行や金融業界に大きな変革をもたらしています。各企業がその可能性をどう活用するのか、今後の動向に注目です。 以下は、銀行業界における生成AIの採用について詳細を記載した参考リンクです。 金融安定理事会 (FSB) レポート銀行業務におけるAI統合について解説しており、リスクモデリング、顧客エンゲージメント、コンプライアンス監視などのユースケースを強調。イノベーションと規制遵守のバランスの重要性も述べられています。金融安定理事会 - 銀行業界におけるGenerative AI オリバーワイマン インサイトGenerative AIが銀行業界に与える変革の可能性について議論しており、顧客サービスの向上、バックオフィス業務の自動化、コンプライアンスの監視システムなどにAIツールを活用する事例を紹介しています。オリバーワイマン - 銀行におけるGenerative AIの採用方法 マッキンゼー 分析Generative AIの活用により、オペレーションコストの削減や効率化が可能となり、顧客オンボーディング、不正検出、個別化された金融アドバイスの提供が実現すると解説しています。マッキンゼー - 銀行のAI活用 世界経済フォーラム (WEF)AIを活用した銀行業務の最新動向について取り上げ、AIチャットボットや予測型金融インサイトツールの事例を紹介。倫理的AI実践の重要性にも触れています。世界経済フォーラム - 銀行におけるAI
- [LLMのトレース： トレースの自動収集からLLMアプリのトラブルシューティングまで](https://ichizoku.io/llm-tracing-from-automatically-collecting-traces-to-troubleshooting-your-llm-app/) - 大規模な言語モデルの使用が増えるにつれ、そのパフォーマンスを理解し最適化するためのツールの必要性も高まっています。観測可能なフレームワークを使用せずにLLMを使用したアプリケーションをデプロイすることは、ブレーキなしで車を運転するようなものです。 トレースは、LLMアプリケーションの内部で何が起こっているのかをよりよく見るための効果的な方法を開発者に提供する、強力な観測可能性テクニックです。 プロンプトとレスポンスのペアのもつれの中で、開発者はしばしばシステムの可視性が低いために効果的な反復を行う能力を失います。トレーシングはこの問題を解決します。 この投稿では、LLMアプリケーションの文脈におけるトレースの効果を探ります。トレーシングがどのように機能するのか、どのようなユースケースで有用なのかを明らかにし、あなたのLLMプロジェクトにトレーシングを導入するプロセスをガイドします。 さあ、トレースの世界へ飛び込みましょう！ トレースの仕組み トレーシングは、リクエストがシステムの複数のステップやコンポーネントを通過する際の経路を記録します。例えば、ユーザーがLLMアプリケーションとやりとりするとき、トレースはリクエストの実行の詳細なタイムラインを提供するために、ドキュメント検索、埋め込み生成、言語モデル呼び出し、レスポンス生成のような操作のシーケンスをキャプチャすることができます。 トレーシングの背後にある重要なコンポーネントには、インスツルメンテーション、エクスポーター、OLTPがあります。 計装 アプリケーションから解析用のトレースを出すには、インスツルメンテーションが必要です。これは、アプリケーションにトレースコードを追加して手動で行うこともできますし、プラグインやインストルメントを使用して自動的に行うこともできます。Arize Phoenixは、アプリケーションに簡単に統合できるインスツルメンテーションツールのセットを提供し、手動でインスツルメンテーションを行うことなく、スパン（作業または操作の単位）を自動的に収集します。 エキスポーター エクスポーターは、インスツルメンテーションによって作成されたスパンを収集し、処理と可視化のためにコレクターに送信する役割を果たします。Phoenixを使用する場合、エクスポートプロセスは、シームレスにトレースデータをPhoenixコレクタに送信する、ボンネットの下で処理されます。 OpenTelemetryプロトコル（OTLP） OTLPは、アプリケーションからPhoenixコレクタへのトレース転送に使用されるプロトコルです。Phoenixは現在、OTLP over HTTPをサポートしており、統合を簡素化し、広く採用されているOpenTelemetryエコシステムとの互換性を確保しています。 トレースによってアプリケーションの実行状況を包括的に把握できるため、開発者はパフォーマンス、運用、デバッグに関するさまざまな課題を、他の方法では不可能な規模で特定し、対処することができます。収集されたトレース・データは、アノテーションの使用によってさらに強化することができ、LLMアプリケーションの反復的な改善を推進するために、ユーザー・フィードバックとAIが生成した評価の両方を取り込むことができます。 トレースの実装例 この例では、RAGパイプラインを構築し、Phoenix Evalsで評価していきます。 検索拡張世代（RAG）とは？ LLMは膨大な量のデータに基づいてトレーニングされますが、その中には貴社固有のデータ（企業のナレッジベースや文書など）は含まれていません。Retrieval-Augmented Generation (RAG)は、生成プロセス中にコンテキストとしてお客様のデータを動的に取り込むことで、この問題に対処します。 これは、LLMの学習データを変更することによってではなく、モデルがお客様のデータにリアルタイムでアクセスし、利用することによって行われ、よりカスタマイズされた、コンテキストに関連した応答を提供します。 RAGでは、データがロードされ、クエリ用に準備されます。このプロセスは『インデックス作成』と呼ばれます。ユーザーのクエリはこのインデックスに作用し、データを最も関連性の高いコンテキストにフィルタリングします。このコンテキストとクエリは、プロンプトとともにLLMに送られ、LLMが応答を返します。 RAGは、チャットボットやエージェントのようなアプリケーションを構築するために重要なコンポーネントです。 RAGパイプラインの構築 RAGとは何かを理解したところで、パイプラインを構築してみましょう。RAGにはLlamaIndexを使い、評価にはPhoenix Evalsを使います。 Phoenix Tracingを使用して、RAGパイプラインの評価に必要なすべてのデータを取得します。これを有効にするには、Phoenixアプリケーションを起動し、LlamaIndexを計測するだけです。 ローカルターミナルで以下のコマンドを使用してPhoenixを起動します。 Phoenixを初めて使う場合は、ターミナルで以下のコマンドを実行する必要があるかもしれません。 クラウドホスティングのPhoenixインスタンスを使用したい場合は、以下の手順を参照してください。 ノートブックに戻って、Phoenixのローカルインスタンスに接続します。 このチュートリアルでは、合成データの作成と評価にOpenAIを使用します。 ポール・グラハムのエッセイを使ってRAGパイプラインを構築してみましょう。 これでQueryEngineを構築し、クエリーを開始することができます。 .response_vector.responseを使用すると、クエリから得られるレスポンスを確認できます。 デフォルトでは、LlamaIndexは2つの類似したノードまたはチャンクを取得します。これを変更するには以下のように行います。 最後に、検索された各ノードのテキストをチェックしてみよう。 RAGパイプラインの評価に必要なすべてのデータを取得するために、Phoenixトレースを使用していることを忘れないでください。トレースは phoenix アプリケーションで見ることができます。 Phoenixセッションからスパンを直接引き出すことで、トレースにアクセスできます。 トレースはクエリーエンジンによって取得されたドキュメントをキャプチャしていることに注意してください！ RAGパイプラインがインスツルメンテーションされ、トレースがPhoenixにエクスポートされると、収集されたデータをPhoenixのユーザーインターフェイスで表示および調査できるようになります。Phoenixアプリケーションには、トレースを可視化、クエリ、分析するための豊富なツールセットが用意されており、LLMアプリケーションのパフォーマンスと動作に関する深い洞察を得ることができます。 LLMトレーシングは何ができるのか？ トレースを実装することで、以下のことが可能になります。 個々の操作のレイテンシを調べることにより、パフォーマンスのボトルネックを特定する。 LLMコールのトークン使用状況を把握し、コストと効率を最適化する。 レート制限の問題など、実行時の例外を検出して調査します。 Retrieverによって検索されたドキュメントを、そのスコアや順序を含めて検査する。
- [モバイル向けセッション・リプレイを発表 - オープンβ開始](https://ichizoku.io/announcing-session-replay-for-mobile-in-open-beta/) - iOS、Android、React Native用のSession Replayがオープンβになりました。 もしあなたがSession Replayをすでに知っているなら、素晴らしいことです。 リンクをクリックし、あなたのSDKをアップデートすれば、あなたのユーザーが怒りを引き起こすような問題を経験している場所をビデオのように再現してくれるようになります。 もし私が何を言っているのか分からないなら、なおさらです。お話をしましょう。 クラッシュ、悪ふざけ、一般的な無反応は、⭐1つのレビューにつながり、人々はアンインストールし、成長ハックを売り込むPMにつながり、誰もそれを望んでいません。このような悪ふざけを先回りするにはどうすればいいのでしょうか？ 昨年、私たちは、Webアプリのユーザーセッションの完全匿名化されたビデオのような複製をキャプチャする機能 - Webベースのアプリケーションのためのセッションリプレイ - を発表しました。現在、40,000を超えるチームが、チェックアウトの不具合、ページの読み込みの遅さ、予期せぬクラッシュなど、あらゆるデバッグにこの機能を使用しています。 何が問題なのかを実際に見ることで、デバッグがより簡単になるとは誰が考えたでしょうか😉 モバイル開発者（GitHubで400以上のアップヴォートを提供し、500以上のアーリーアダプターのサインアップに貢献した）もこの機能を望んでいます。 だから、私たちはここにいます。モバイル向けセッション・リプレイは現在オープンベータ版で、アーリーアダプターは無料で使用できます。 コードとUXのギャップを埋める モバイル向けセッションリプレイは、アプリ上のユーザーセッションを視覚的に再現することで、モバイルアプリケーションの可視性を拡大します。これにより、いつ、どこで、どのようにエラーがアプリに影響を及ぼしているかを、自分で再現したり顧客と会話したりすることなく理解することができます。リプレイを使用すると、タップやピンチによるズームなどのジェスチャーがリプレイビューに含まれるため、ユーザーとのインタラクションをより深く理解し、アプリのどこで問題が発生しているかを特定することができます。リプレイには、デバイスタグ、ネットワークリクエストの詳細、スローされた例外などのデバッグコンテキストも含まれています。 当社の全製品と同様に、セッションリプレイはSentryワークフローに統合されています。Issue Detailsでスタックトレースを検査しながら関連するリプレイを見たり、User Feedbackでバグレポートを提出したユーザからのリプレイを見たりすることができます。また、サンプリング設定を構成して、エラーが発生したときのみリプレイをキャプチャし、データのインジェストを減らすことができます。また、UIへの影響やユーザーの反応（アプリを閉じたかどうかなど）によって、問題の深刻度を評価することもできます。 モバイルエラーの根本原因を確認する モバイル用のSentryのセッションリプレイを使用すると、ユーザーがエラーに遭遇したときにサンプリングセッションを優先するオプションがあります。 これは、クラッシュが発生したときに、その特定のエラーに遭遇した実際のユーザーからの関連するリプレイが、問題の詳細ページで関連するSentryの問題に便利にリンクされていることを意味します。エラーの発生前、発生中、発生後に、OSのバージョンや名前などの有用なコンテキストとともに何が起こったかを見ることで、エラーがどのように発生し、ユーザーにどれほどの影響を与えたかを素早く特定することができます。さらに、エラー時のサンプリングにより、必要なデータを待つ時間や、イベントクォータを監視する不安も軽減されます。 ゲーミフィケーションを使用し、UXに重点を置き、素晴らしいイラストやアニメーションがある、派手なライフスタイル・アプリを開発しているとしましょう。アプリケーション・パフォーマンス・モニタリング（APM）製品は、サードパーティのライブラリでクラッシュが発生していることを警告します。この問題を調査し解決するためにセッションリプレイを使用する方法を説明します。 エラーを特定する： エラー追跡システムで、あなたはエラーメッセージ "NullPointerException in run_animation() "で繰り返し起こるクラッシュを分析します。スタック・トレースは、あなたが使っているサードパーティのアニメーション・ライブラリを指していますが、あなたはその意味を理解していません。 関連するセッションのリプレイを探す： リプレイをフィルタリングして、この特定のクラッシュに関連するものだけを表示します。 リプレイを見る： リプレイの1つを選択すると、達成を祝う画面から始まり、達成ポイントが与えられます。かなり長いです）リワードアニメーションが再生される間に、ユーザーは「次へ」ボタンをタップし、アプリがクラッシュします。 コンソールログを調べる： コンソールログの中で、アニメーションライブラリから「onAnimationCancelled」コールバックが呼び出されていることに気づきます。 このコールバックを実装しそこねていたことに気づきます。対策として、アニメーションの時間も短くします。アップデートをデプロイした後、アプリをアップデートするにつれてクラッシュの数が減少していることを監視します。 この例では、Session Replayにより、クラッシュに至ったユーザーアクションを正確に可視化し、エラーの根本原因としてアニメーションライブラリのコールバックの欠落を特定し、この問題を解決するために的を絞った修正を実装することができます。セッション リプレイがなければ、イベントの正確なシーケンスを理解し、このクラッシュの原因を特定することははるかに困難であったでしょう。 アプリのペインポイントの特定 誤解を招くラベル、リンク切れ、パーミッションの問題 - ユーザーが例外を発生させない問題にぶつかることがありますが、それでもユーザー体験に影響を与えます。セッションリプレイは、ユーザーがどこで立ち往生したり、アプリから脱落したりするかを確認することで、アプリ内でこれらのペインポイントが発生する場所を特定するのに役立ちます。 例えば、モバイル e コマースアプリを開発していて、チェックアウト中にアプリが反応しなくなるという悪いレビューが増えているとします。この問題を調査し解決するためにセッションリプレイをどのように利用できるかを説明しましょう。 アプリのパフォーマンスに問題があると思われます。しかし、パフォーマンスKPIはまだ良好で、APM製品はチェックアウト画面で問題を示しません。 関連するセッション・リプレイを見つける：リプレイをフィルタリングして、チェックアウト画面に関連するリプレイのみを表示し、継続時間の長いリプレイにも注目します。 リプレイを見る：リプレイの1つを選択し、ユーザーのアクションを観察します。ユーザーがチェックアウトページの「次へ」ボタンをタップし、サーバーへのAPIコールが開始されるのを確認します。 ネットワークリクエストを確認する： ネットワーク・タブを調べると、APIコールが正常かつ適切な時間で終了していることがわかります。これで、これが根本的な原因ではないことがわかりました。 パンくずを調べる：アプリのUI状態管理でごく最近の状態変更があり、APIコールが返された後に状態が衝突してUIが更新されないことに気づきます。この時点で、ユーザーは激怒してクリックし、最終的にアプリを終了します。 修正と検証：UI状態管理のバグを処理するための修正を実装します。アップデートをデプロイした後、後続のセッションリプレイを監視して、ユーザーがチェックアウトプロセス中に進めるようになったことを確認します。
- [Reactでフェッチ・ウォーターフォールを特定する方法](https://ichizoku.io/how-to-identify-fetch-waterfalls-in-react/) - フェッチ・ウォーターフォールは、複数のフェッチ・リクエストが並列ではなく、逐次的に呼び出されるシナリオです。これは深刻なパフォーマンス低下につながります。 以下にその様子を示します。 この場合、2番目と3番目のリクエストは並行してフェッチされ、ページロードとデータ表示が4.053秒改善されます。フェッチウォーターフォールによるパフォーマンスへの悪影響は、スタッキングでも発生します。つまり、リクエストが多ければ多いほど、パフォーマンスへの影響は悪化します。 この記事では、トレースを使用してReactアプリケーションのフェッチウォーターフォールを特定する方法を見ていきます。 トレース入門 トレースとは、あるプロセスやフローを定義する操作やコマンドの論理的なグループを記述するスパンの階層からなるデバッグ・データ・セットをキャプチャするために、コードを「インスツルメンテーション」するプロセスのことです。ページのロードを例にとってみましょう。 ページロードを操作の流れとして記述しようとすると、（おおよそ）次のようになるはずです。 ブラウザがサーバーにページをリクエストする サーバーはHTMLで応答し、ブラウザはそれを解析する パース中に、ブラウザはリンクされたJSファイルに出くわす。JSファイルにはReactとページコードが含まれているので、ブラウザはそれを実行する。 ブラウザは、ページコードの指示に従ってコンポーネントのフェッチとレンダリングを行う。 さらに、ブラウザーは画像、ファビコン、CSSファイルなどのリソースをリクエストする。 これらの処理はすべて特定の順序で行われますが、その時間はデバイスの処理能力やインターネット接続の速度などの要因によって異なります。 この記事のトップにあるスクリーンショットは、APIにHTTPリクエストを送信する3つのhttp.clientスパンを示しています。それぞれ、特定の開始時刻、特定の終了時刻、そして雑多なデータが添付されています。上のスクリーンショットのトレース・ビューを見ると、3つのHTTPリクエストが次々と実行されていることがよくわかります。 プロジェクトの設定 まず、ReactプロジェクトにSentryをセットアップする必要があります。始めるには、Sentry React SDKをインストールする必要があります。 この時点で、すでにサインアップしているはずです。新しいReactプロジェクトを作成しましょう。 Create Project」ボタンを押すと、React SDKのインストール方法と初期化方法が表示されます。初期化設定は以下のようにします。 Sentry SDKの最も優れた点は、コードベースの大部分を自動的に計測してくれることです。フェッチのような既知の操作を自動的にスパンでラップし、Sentryインスタンスに送信するので、すぐにデータの検査を開始できます。 これで、アプリをデプロイして、ユーザーがアプリを使用している間に測定された実際のパフォーマンスデータを得ることができます。データが得られれば、フェッチウォーターフォールのようなパフォーマンスの問題を特定するための調査を始めることができます。 Reactでフェッチ・ウォーターフォールを識別するには？ フェッチ・ウォーターフォールの症状には、著しく遅いページロードが含まれるため、不審に遅いページロードを警戒する必要があります。 Performanceページを使用すると、疑わしい遅いページロードを簡単にピックアップして検査することができます。以下は、私たちのアプリのインデックスページのPerformanceページのスクリーンショットで、ユーザーが私たちのページを訪問している間にキャプチャされたトランザクションを示しています。 どのスパンが不審に遅いか、はっきりとわかります。そのうちの1つをクリックすると、トレース・ビュー画面が表示され、すべてのスパンを見ることができます。http.clientのスパンを拡大してよく見ると、ウォーターフォールが見えます。 この場合、3番目のリクエストグループは、どの結果にも依存しないので、2番目のリクエストの終了を待つ必要はありません。つまり、フェッチウォーターフォールを分解すると、2秒の改善を見ていることになります。 フェッチ・ウォーターフォールを修正するには、その原因を調べる必要があります。フェッチ・ウォーターフォールはサーバーに原因があることもあります。フェッチ・ウォーターフォールのよくあるケースの修正方法についてもっと知りたい方は、「Reactにおけるフェッチ・ウォーターフォール」の記事をご覧ください。 これを見ると、トレースを使って他のタイプの問題も解決できると思うかもしれません。そして、それは正しいでしょう！トレースは本当に一般的なデバッグ手法で、Web Vitalの不具合、ネットワークの遅延、サーバーレスアプリケーションのコールドスタート、キャッシュの欠落やキャッシュ機構の問題、その他様々な問題やバグを特定し、デバッグし、修正するのに役立ちます。トレースは、"トレース "をたどって、いつ何が起こったか、どれくらいの時間がかかったかを調べるようなデバッグや修正に使うことができます。 結論 つまり、トレースはフェッチ・ウォーターフォールの特定に役立つということです。 簡単に復習しましょう。 トレースとはデバッグテクニックの一つで、ページロードのような操作の流れを視覚化しやすくするために、デバッグデータをキャプチャすることです。 トレースとは、互いに関連し、開始時刻と終了時刻を持ち、任意のデータが付加されたスパンのコレクションです。 アプリケーションでトレースのキャプチャを始めるために、私たちはSentryのReact SDKをインストールし、アプリのトップで初期化し、変更を単純にデプロイしました。SDKは自動的にアプリをインスツルメンテーションするので、トレースデータをすぐに見ることができました。 キャプチャされたトレースをすべてリストアップし、その継続時間に基づいて、どのトレースが不審に遅いかを確認できました。 遅いページロードを検査すると、最適化するとページロードを秒単位で改善できるフェッチウォーターフォールが見つかりました。 この記事が、トレースとは何か、どのように始めるべきかを理解する助けになれば幸いです。それでは、よいトレースを！ IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。またご導入についての相談はこちらのフォームからお気軽にお問い合わせください。
- [オープンソースLLMアプリケーションの管理と監視について](https://ichizoku.io/managing-and-monitoring-your-open-source-llm-applications/) - 現在、LLMが大流行しており、GPT-4のようなクローズドソースのモデルのAPIは、AIの力を活用することをかつてないほど容易にしています。 しかし、多くの規制産業にとって、これらのクローズドなソースモデルは選択肢とはなりません。幸いなことに、Llama 3、Mistral、Falconのようなオープンソースの代替モデルが多数あり、これらの業界もLLMの流行に乗ることができます。 これらのオープンソースのモデルは、クローズドソースのモデルと同様に強力であり、カスタマイズが容易であるという利点もあります。 オープンソースのモデルは実行可能な選択肢ではありますが、デプロイメント、サービス提供、監視を自分で行う必要があります。 もしあなたがAI分野の初心者なら、これは大変な作業に思えるかもしれませんが、心配ご無用です。 この記事では、UbiOpsとArizeを活用してLLMアプリケーションを簡単にデプロイ、管理、監視する方法をご紹介します。 今回は、Llama-3-8b-instructを例に説明します。 このモデルをUbiOpsでクラウドにデプロイし、モデルが使われるたびに、プロンプトとレスポンスのエンベッディングをメタデータと共にArizeに記録します。 こうすることで、Kubernetesや仮想マシンに煩わされることなく、スケーラブルな方法でllama-3-8b-instructをデプロイして提供できるだけでなく、LLMのパフォーマンスを注意深く見守ることができるようになります。 UbiOpsとは？ UbiOpsは強力なAIサービングとオーケストレーションのプラットフォームで、クラウドの知識がなくても、チームがAIとMLのワークロードを、信頼性が高くセキュアなマイクロサービスとして迅速にデプロイできるように支援します。 UbiOpsを使えば、クラウド、ハイブリッド、オンプレムなど、どのような環境でもAIモデルを大規模にデプロイできます。 Arizeとは？ Arizeは、AIの可観測性とLLM評価プラットフォームです。 Arizeを使用すると、LLMアプリケーションを監視、トレース、評価、反復することができます。 Arizeを使うことで、あなたのAIシステムを自信を持って本番稼動させることができます。 なぜllama-3-8b-instructを使うのか？ Llama 3はMeta社が開発したLlamaシリーズの最新モデルです。 コンパクトな80億パラメータバージョンと、より大きな700億パラメータバージョンの2つのサイズがあります。 どちらのモデルにも、ベースバージョンとインストラクターバージョンがあります。 Llama3のインストラクターバージョンは何が特別なのか？ インストラクション・バージョンは、インストラクション・チューニングが施されていることを意味します。 インストラクション・チューニングとは、単にプロンプトをこなすだけのベースモデルとは対照的に、質問に対して会話形式で応答するようにベースモデルを訓練するプロセスです。したがって、Llama3を微調整するのでなければ、インストラクションバージョンを使用することをお勧めします。 Meta社が発表した評価結果によると、Llama3 8Bは同サイズのMistral 7BやGemma 7Bを上回っています。 以下はその結果の表です。 オープンソースのLLMをインフラに導入する まず、プレーン版のllama-3-8b-instructをUbiOpsにデプロイしましょう。 そのためには、UbiOpsにLLMを提供できるデプロイメントを作成する必要があります。 デプロイメントはUbiOps内のオブジェクトで、データを処理するPythonコードを提供します。 デプロイメントを作成するには、実行したいコードをUbiOpsに提供し、デプロイメントが必要とするハードウェアの種類などのデプロイメント設定を指定する必要があります。 作成後、UbiOpsはコードをコンテナ化し、自動スケーリングAPIエンドポイントを生成します。 プロンプトとsystem_promptを入力として受け取り、レスポンスを返す新しいデプロイメントを作成してみましょう。 プロンプトはユーザーがLLMに送るプロンプトで、system_promptはモデルがどのように振る舞うべきかの指示です。 デプロイコードの作成 デプロイメントが作成されたので、私たちのコードでデプロイメント・バージョンを作成できます。 UbiOpsがいつ何を実行するかを理解するために、コードでは2つの関数を定義する必要があります。 Deploymentの初期化時に実行する必要があるものを指定する__init__関数、そして、新しいデータ（つまり新しいプロンプト）がモデルに送られたときに何が必要かを指定するrequest関数です。 以下に、Llama 3をUbiOpsにデプロイするためのデプロイメントコードを示します。 このコードを実行するには、requirements.txtで依存関係を指定する必要があります。 デプロイメント・バージョンを作成する コードの準備ができたので、デプロイ・バージョンを作成していきます。 このバージョンは、十分に高速に実行するためにGPUが必要です。私たちはNVIDIA Ada Lovelace L4を使っています。Llama 3 8B-Instructデプロイメントパッケージをアップロードします。環境設定で、"Select code environment
- [Arize AI、Microsoft Azure AIモデルカタログにLLM評価と観測可能性をもたらす](https://ichizoku.io/arize-ai-brings-llm-evaluation-observability-to-microsoft-azure-ai-model-catalog/) - 生成AIが現代の企業を再構築しています。最近の調査によると、開発者の半数以上（61％）が、今後1年以内に、あるいは「できるだけ早く」、LLMアプリケーションを本番環境に導入する予定だと答えています。しかし、生成AIを使ったアプリケーションを本番環境に導入し、そのまま使い続けるには課題が残っているのが現状です。 今週のMicrosoft Buildで、Arize AIは、AIエンジニアがLLMアプリケーションの信頼性の高い開発を加速させるために、Microsoft Azureとの深いパートナーシップ結んだことを公開しました。 Microsoft Azure Model-as-a-Service Fortune 500に名を連ねる航空会社、金融サービス企業、小売業者、テクノロジー企業などの多くが、堅牢なMLとLLMの観測可能性のためにArizeとともにAzureを利用しています。これらのユーザーにとって、Azure AIモデルカタログは素晴らしい出発点となります。Azure Open AI Service、Meta、Mistral、Cohereなど、Azure AIがキュレーションした人気のオープンソースモデルが掲載されており、Hugging Faceとのパートナーシップを活用して、推論用の数千ものOSSモデルを提供しています。重要なのは、Azure AIモデルカタログが、Models- as-a-Service (MaaS)を通じて、複数の従量課金型推論APIを提供していることです。AzureがインフラとGPUを管理し、ユーザーがLlama 3、Mistral Large、Cohere Command R/R+、Embedモデルなどの厳選されたモデル群に、LLM用のトークンに基づく課金制の従量課金APIを介してアクセスすることで、ユーザーはGPUをプロビジョニングすることなくホスト型の微調整を行うことが可能になります。そして、プロンプトフロー、LlamaIndex、ArizeなどのLLMOpsツールとシームレスに統合し、最終的に本番環境への移行を早めることができます。これらの生成AIの開発プラットフォームで利用可能なMaaSにより、開発者はEnterpriseグレードの従量課金APIを活用しながら、生成AIアプリを構築するために好みのツールを使い続けることができます。これらのAPIは、Azureのデータ、プライバシー、セキュリティのコミットメントの対象であり、Microsoftがあなたの許可なくデータを第三者に共有しないことを保証しています。プロンプトやレスポンスの内容などは、Azure上のModels as a Serviceを組織で使用することで、生成されるデータを含めお客様のデータはプライベートに保たれ、第三者に開示されることはありません。 ArizeとAzure Model As a Serviceの統合 Arizeは、Arize LLM評価および観測可能性プラットフォームにAzure AI Model as a Serviceを統合しました。Llama 3やMistral Largeのような使いやすいホストモデルの厳選されたセットへのアクセスをサービスとして提供することで、Azureは生成的AIアプリケーションの構築をこれまで以上に迅速化します。LLM評価、トレーシング、観測性のための主要なプラットフォームを提供するArize AIとのシームレスな統合により、Azure AI Studioを使用するAIエンジニアや開発者は、洗練されたLLMシステムのエンタープライズグレードのデプロイメントを確実に行うことができます。 LLM評価と観測可能性の必要性 利用可能なモデルの豊富さと性能のばらつきを考えると、専門的なタスクやユースケースに対する客観的な評価と、LLMアプリが本番稼動した後の問題の検出とトラブルシューティングのための観測可能性が最も重要になります。これは、適切なモデルを選択し、検索拡張世代（RAG）、Copilot、エージェントなどのユースケースでアプリケーションを動作させることがいかに複雑であるかを考えると、『言うは易く行うは難し』です。 LLMベースのアプリケーションの問題点 RAGの展開には、個人の顧客データをLLMの生成モデルに接続するために連携する必要のある複雑な技術セットが含まれます。この技術が実世界に展開される際に発生する問題は、チームにとってトラブルシューティングが困難な場合があります。不正確な検索、機密データ上の幻覚（ハルシネーション）、不完全な回答の原因となる不完全なコンテキストチャンク、回答するコンテキストデータがない質問などが挙げられます。このような複雑なAIシステムには、観測と分析のための世界クラスのソリューションが必要です。このような取り組みがエグゼクティブ・スイートで高い可視性を持つことと相まって、エラーやミスが雪だるま式に増えてPR問題に発展する余地はほとんどありません。つまり、LLMの観測可能性の必要性は、アプリケーションやサービスにLLMを導入するチームにとって必須なのです。 ArizeのAI観測可能プラットフォーム Arize AIがLLM評価と新しいスタックにわたる、観測可能性を提供 Arize AIはAzure AI Studioとの連携を深め、チームがLLMアプリを客観的に評価し、出力から逆算してLLMスタック全体のどこに問題が生じているのかを正確に突き止められるよう支援します。 LLM評価については、Arize社のオープンソースライブラリであるPhoenixが、コード生成、文脈関連性、幻覚（ハルシネーション）、Q&Aの正しさ、要約、毒性などの様々なタスクに対して、シンプル、高速、正確なLLMベースの評価を提供します。すべての評価テンプレートは、LLM
- [RAGの評価について](https://ichizoku.io/rag-evaluation/) - 検索とレスポンス・メトリクスによるLLMと検索補強世代のトラブルシューティング 図1：LLM RAGアプリケーションの根本原因ワークフロー 検索タスクのために大規模言語モデル（LLM）を使って実験している場合、LLMが生成した応答に関連するコンテキスト情報を追加する技術として、検索拡張生成（RAG）に遭遇するでしょう。 LLMをプライベートデータに接続することで、RAGはコンテキストウィンドウに関連データを送り込み、より良い適切な回答を可能にします。 RAGは、複雑なクエリへの応答、知識集約的なタスク、AIモデルの応答の精度と関連性の強化に非常に有効であることが示されています。 しかしながら、RAGから得られるこれらの利点は、LLMシステムの一般的な障害ポイント、つまり応答と検索評価メトリクスを継続的にモニタリングしている場合にのみ享受することができます。 この記事では、不十分な検索とレスポンスのメトリクスを解消するための最適なワークフローについて説明します。 検索段階と回答のトラブルシューティング RAGが最も機能するのは、必要な情報が容易に入手できる場合であることを忘れてはなりません。 関連文書が入手可能かどうかは、RAGシステムの評価を2つの重要な側面に集中させます。 検索評価： 検索された文書の正確さと関連性を評価する。 応答評価： コンテキストが提供されたとき、システムが生成したレスポンスの適切性を測定する。 図2：LLMアプリケーションにおける検索評価と応答評価 レスポンス評価指標（表1） 検索評価指標（表2） RAG評価： ワークフローのトラブルシューティング フロー図に基づき、LLMのパフォーマンス低下をトラブルシューティングするために考えられる3つのシナリオを確認してみましょう。 シナリオ1：良好なレスポンス、良好な検索 このシナリオでは、LLMアプリケーションのすべてが期待通りに動作しており、良好な検索結果とともに良好な応答が得られています。 レスポンスの評価は 「正しく」、「Hit = True 」であることがわかります。 「Hit」はバイナリ指標です。 「True 」は関連文書が検索されたことを意味し、「False 」は関連文書が検索されなかったことを意味しています。 Hitの集計統計はHit率（関連するコンテキストを持つクエリのパーセンテージ）であることにご注意ください。 私たちの応答評価では、「正しさ」は表1に見られるように、入力（クエリ）、出力（応答）、およびコンテキストの組み合わせで単純に行うことができる評価指標です。 LLMはOpenAIの関数呼び出しのようなツールでラベル、スコア、説明を生成するために使用することもできるので、これらの評価基準のいくつかは、ユーザがラベル付けした正解データ（教師データ）を必要としません。 これらの評価は、数値、カテゴリー（バイナリおよびマルチクラス）、マルチアウトプット（複数のスコアまたはラベル）のフォーマットで行うことができ、カテゴリーバイナリが最も一般的に使用されます。数値は一般的に使用されません。 シナリオ2：悪いレスポンス、悪い検索 このシナリオでは、レスポンスが正しくなく、関連するコンテンツが取得できていないことがわかります。 クエリに基づくと、クエリに対する解決策がないため、コンテンツが受信されていないことがわかりますね。 LLMはどのような文書を供給されても、将来を予測することはできません。 しかし、LLMは答えを幻覚（ハルシネーション）で見るよりも良い回答を生成することができます。 ここで、LLMのプロンプトテンプレートに「関連するコンテンツが提供されず、決定的な解決策が見つからない場合は、次のように回答してください」という行を追加するだけで、回答を生成しているプロンプトを実験することができるでしょう。 関連する内容が提供されず、決定的な解決策が見つからない場合は、答えは不明であると回答してください。 場合によっては、答えは存在しないというのが正しい答えとなることがあります。 シナリオ3：悪いレスポンス、混合検索メトリクス この3つ目のシナリオでは、検索メトリクスが混在した誤った回答が見られます（関連文書は検索されたが、LLMは情報が多すぎたために誤った回答を生成したというケースです）。 LLM RAGシステムを評価するには、適切なコンテキストを取得し、適切な答えを生成する必要があります。 通常、開発者はユーザークエリを埋め込み、それを使って関連するチャンクをベクターデータベースから検索します（図3参照）。 検索性能は、返されたチャンクがクエリと意味的に類似しているかどうかだけでなく、それらのチャンクがクエリに対する正しい応答を生成するのに十分な関連情報を提供しているかどうかにかかっています。 前回のシナリオと同様に、プロンプトテンプレートを編集するか、応答を生成するために使用するLLMを変更してみることができます。 関連するコンテンツはドキュメント検索プロセスで取得されますが、LLMでは表示されないため、これは迅速な解決策となります。 以下は、プロンプトの変数、LLMパラメータ、プロンプトテンプレートを繰り返し変更した後、プロンプトテンプレートを変更して正しい応答を生成した例です。 パフォーマンス・メトリクスが混在している悪い応答のトラブルシューティングを行う場合、どの検索メトリクスがパフォーマンス不足であるかを把握する必要があります。 これを行う最も簡単な方法は、しきい値とモニターを実装することです。特定のパフォーマンス不足のメトリクスがアラートされたら、特定のワークフローで解決できます。nDCGは上位にランクされたドキュメントの効果を測定するために使用され、関連するドキュメントの位置を考慮します。
- [Retrieval-Augmented Generation (RAG)で生成部分を正しく理解するための研究主導型手法](https://ichizoku.io/research-driven-techniques-for-getting-the-generation-part-right-in-retrieval-augmented-generation/) - RAGシステムの新しい評価手法が毎日のように発表されていますが、そのほとんどがフレームワークの検索段階に焦点を当てています。Arizeは、テストの詳細な分析を含む、検索段階に関するいくつかの記事を発表しました。 しかし、生成の側面、つまりモデルが検索された情報をどのように合成し、表現するかという点において、より重要ではないにしても、同等の重要性を持つかもしれません。 私たちが実運用で目にする多くのユースケースは、単にコンテキストから回答を返すだけでなく、より複雑なレスポンスに合成する必要があります。 数値データを物語的な分析に変換するのか、抽象的な概念を具体的な例に変換するのか、あるいは異種の情報の断片を統合するのかにかかわらず、生成プロセスは、RAGシステムの機能にとっては必要不可欠です。 私たちはGPT-4、Claude 2.1、Claude 3.0 Opusの生成機能を評価し、比較するためにいくつかの実験を行いました。 この記事では、私たちの研究方法と結果、そしてその過程で遭遇したモデルのニュアンスについて詳しく解説していきます。 研究で得たもの 最初の結果では、Claude がGPT-4を上回りました。しかし、その後のテストでは、戦略的なプロンプトエンジニアリングにより、GPT-4がより幅広い評価で優れたパフォーマンスを示したことが明らかになりました。RAGシステムでは、固有のモデル動作とプロンプトエンジニアリングが非常に重要であるといえます。 プロンプトに 「Please explain yourself then answer the question（説明してから質問に答えてください）」と加えるだけで、GPT-4のパフォーマンスは大幅に（2倍以上）改善します。LLMが答えを話し出すと、アイデアを展開するのに役立つことは明らかです。モデルが説明することで、埋め込み/注意空間において正しい答えを再強化している可能性があります。 RAGシステムの成功には、検索と同じかそれ以上に、生成ステップが重要です。 RAGの段階と生成が重要な理由 RAGシステムにおける最近の研究の多くが検索段階に向けられていることは、膨大な知識ベースから関連する情報を探し出し、抽出することの重要性を考えれば理解できます。 しかし、これらのシステムの全体的なパフォーマンスとユーザビリティにおいて同様に重要な役割を果たす、生成段階の重要性を見落としてはなりません。 検索段階は、最も適切な情報を特定し、検索する役割を担っています。ここで生のデータを受け取り、意味のある、文脈上適切な回答に変換するのは生成段階です。生成段階は、検索された情報を合成し、ギャップを埋め、ユーザーのクエリに関連する、理解しやすい方法で提示する役割があります。 多くのアプリケーションにおけるRAGシステムの価値は、特定の事実や情報の一部を見つける能力だけでなく、より広い枠組みの中でその情報を統合し、文脈化する能力にあります。生成段階では、RAGシステムが単純な検索を超え、詳細な説明を提供したり、複数の情報源に基づいた洞察を提供したり、複雑な問題に対する創造的な解決策を生成したりするなど、真にインテリジェントで適応性のある応答を提供することを可能にします。 テストその1：日付のマッピング 最初のテストでは、ランダムに取得した2つの数字から日付文字列を生成しました。モデルには次のようなタスクを課しました。 1つ目の乱数取得 下一桁を分離して1ずつ増やす 結果から日付文字列の月を生成する 2つ目の乱数取得 2つ目の乱数から、日付文字列の曜日を生成する 例えば、乱数4827143と17は4月17日を表します。 これらの数字は、さまざまな長さのコンテクスト内のさまざまな深さに配置されました。モデルたちは当初、このタスクにかなり苦労していました。 どちらのモデルも素晴らしいパフォーマンスを見せましたが、Claude 2.1 は最初のテストで GPT-4 を大きく上回り、成功率はほぼ4倍になりました。 これは Claude の冗長な性質（詳細で説明的な回答をする性質）が、GPT-4の最初の簡潔な回答と比較して、より正確な結果をもたらし、明確な優位性を与えたようです。 この予想外の結果に促されて、私たちは実験に新しい変数を導入しました。 GPT-4に「自分自身を説明してから質問に答えよ」と指示し、Claudeの自然な出力に似た『より冗長な回答』を促しました。この些細な調整の影響は大きかったです。 GPT-4のパフォーマンスは劇的に向上し、その後のテストでは完璧な結果を残したのです。Claudeの結果もまた、わずかですが向上しました。 この実験は、言語モデルの生成タスクへの取り組み方の違いを浮き彫りにしただけでなく、プロンプトエンジニアリングがその性能に与える潜在的な影響も示しています。 Claudeの長所と思われた冗長性は、GPT-4で再現可能な戦略であることが判明し、モデルが推論を処理し提示する方法が、生成タスクにおける精度に大きく影響することを示唆しています。 全体として、プロンプトに「自分自身を説明する」という一見とても小さなことかと思いますが、すべての実験においてモデルのパフォーマンスを向上させる役割を果たしました。 検索生成タスクのさらなるテスト さらに4つのテストを実施し、検索された情報を合成し、さまざまな形式に変換するモデルの能力を評価しました。これらのテストには以下が含まれます。 文字列の連結： テキストの断片を組み合わせて首尾一貫した文字列を形成し、モデルの基本的なテキスト操作スキルをテストする。 お金の書式設定： 通貨として数値をフォーマットし、四捨五入し、パーセンテージの変化を計算し、モデルの精度と数値データを扱う能力を評価する。
- [LLMエバリュエーションとベンチマークでRAGを評価する方法](https://ichizoku.io/evaluate-rag-with-llm-evals-and-benchmarks/) - 先日、Arize AI主催のワークショップ「RAG Time」に参加しました。 そこでは『LLM Evals と BenchmarkingでRAGを評価する』というタイトルのワークショップに参加しました。 アンバー・ロバーツ氏（Arize AIの機械学習グロースリード）とミキョー・キング氏（Arize AIのオープンソース責任者）が主催したこの講演は、重要な研究分野についての貴重な洞察を提供してくれました。 LlamaIndexを使用したRAGパイプラインの構築からPhoenixを活用した応答評価までをカバーするコードアロングエクササイズとともに、主な学びと収穫をご紹介します。 検索拡張生成（RAG）とは何か？ RAG (Retrieval-Augmented Generation)は、元の学習データソースを超えた権威ある知識ベースを活用することで、言語モデルの出力を強化します。 これにより、モデルは生成プロセス中に外部情報を参照して応答を改良します。 下図は、RAGがどのように機能するかを示しています。 RAGは、特定のドメインや組織内部の知識リポジトリに対応するために、LLMの既存の堅牢な機能を強化します。 RAGは、LLMの出力を強化し、その関連性、正確性、およびさまざまなシナリオでの有用性を確保するためのコスト効率の高い方法を提供します。 RAGの長所には、独自のデータを活用することでLLMアプリケーションのパフォーマンスを向上させ、継続的な進歩の恩恵を受けて結果を改善することが挙げられます。 一方短所としては、RAGワークフローのトラブルシューティングに時間がかかる可能性があることと、システムが適切に監視されない場合に複数の障害が発生するリスクがあることが挙げられます。 RAG構築における重要なステップ RAGには5つの重要な段階があり、これらは大規模なRAG構築の一部となります。 Loading この段階では、テキストファイル、PDF、Webサイト、DB、APIなどの多様なソースからデータを収集し、パイプラインに統合します。 Indexing ベクトル埋め込み、数値データ表現、文脈情報検索の精度を向上させるためのメタデータ戦略の活用によって、LLMに堅牢なデータ構造を構築します。 Storing インデックスの再作成を防ぎ、効率的なデータ検索を実現するためには、最初のインデックス作成後にインデックスとそのメタデータを保存することが重要です。 Querying サブクエリ、マルチステップクエリ、ハイブリッドアプローチなど、様々なクエリ手法を活用し、LLMとデータ構造を選択したインデックス戦略に統合します。 Evaluation 代替案や修正案に対するアプローチの有効性を測定し、レスポンスの正確さとスピードに関する客観的な指標を提供するため、どのパイプラインにおいても極めて重要です。 LlamaIndexを使用してRAGパイプラインを構築する方法 RAGの仕組みと段階は理解できましたか？ それでは実際に、LlamaIndexを使ってRAGパイプラインを構築し、大規模な言語モデルの評価にPhoenix Evalsを使ってみましょう。 OpenAIのキーをお持ちの方は、こちらのGoogle Colabをチェックして、このデモを使ってみてください。 ライブラリのインストール インストールされたライブラリをインポートする nest_asyncioモジュールは、すでに実行されている非同期ループの中に非同期関数を入れ子にすることができます。Jupyterノートブックは本質的に非同期ループで動作するため、これは必要です。nest_asyncioを適用することで、競合することなく、既存のループ内で追加の非同期関数を実行できます。 Phoenixアプリケーションの起動 この実装を通して、Phoenixトレースを使用してRAGパイプラインの評価に必要なすべてのデータを取得します。これを有効にするには、Phoenixアプリケーションを起動し、LlamaIndexを計測するだけです。 これは自分のインスタンスでサーバを実行しブラウザ上でLlamaIndexのset_global_handler("arize_phoenix")を使ってArize Phoenixにすべての情報を設定しています。 OpenAIは、合成データの作成や評価に使用する予定です。 インデックスのダウンロード、ロード、構築 ポール・グラハムのエッセイを使ってRAGパイプラインを構築して見ましょう。 LlamaIndexを使ってエッセイを解析し、chunk_sizeが512のドキュメントのチャンクを作り、それを埋め込みます。 次に、クエリを実行できるように、ローカルファイルをVectorStoreIndexとして保存します。 QueryEngineを構築し、クエリーを開始する クエリーから得られるレスポンスをチェックし、それが私たちが探しているユースケースに合わせたものであることに気づくことができます。 『著者は短編小説を書き、プログラミングに取り組み、特に9年生の時にはIBM 1401コンピューターを使っていました。』
- [RagasとPhoenixによるRAGパイプラインの評価と分析手法について](https://ichizoku.io/evaluating-and-analyzing-your-rag-pipeline-with-ragas-and-phoenix/) - この記事は、Arize AIの創業エンジニア兼オープンソース責任者であるMikyo Kingと、Arize AIのAIエンジニアであるXander Songの共著です。 通常、RAGパイプラインのベースラインを構築することは難しくありません。 しかし、それを本番環境に適したものに強化し、回答の質を確保することは、ほとんどの場合難しいです。 RAGのための適切なツールやパラメータを選択することは、豊富なオプションがある場合、それ自体が困難な場合があります。 今回は、品質を確保しながらRAGを構築し、正しい選択が行えるようになるための強固なワークフローをご紹介します。 この記事では、以下のようなオープンソースのライブラリを組み合わせてRAGを評価、視覚化、分析する方法について説明します。 ・合成テストデータの生成と評価のためのRagas Arize AIのPhoenix（トレース、可視化、クラスター分析用） RAGパイプライン構築のためのLlamaIndex この記事では、RAGパイプラインを構築するために、プロンプト・エンジニアリングに関するarXiv論文のデータを使用します。 ℹ️ この記事では、OpenAIのAPIキーが必要となるので準備してください。 依存関係のインストールとライブラリのインポート 以下を実行して、Git LFSをインストールしてください。 Pythonの依存関係をインストールしてインポートします。 OpenAI API キーを設定する OpenAI API キーが環境変数に設定されていない場合は、設定します。 合成テスト・データセットの作成 評価のためのテストデータセットの作成は、現実的ではない、長く、退屈で、高価なプロセスである可能性があります。 これは、高品質のデータ・ポイントを合成的に生成し、開発者が検証することで解決できます。これにより、テスト・データの収集にかかる時間と労力を90%削減することができます。 以下を実行すると、arXivからPDF形式のプロンプト・エンジニアリング論文のデータセットをダウンロードし、LlamaIndexを使ってこれらの文書を読むことができます。 理想的なテストデータセットは、本番中に観測されたものと同様の分布から、高品質で多様な性質を持つデータポイントを含むべきです。Ragasはユニークな進化ベースの合成データ生成パラダイムを使用し、最高品質の問題を生成します。 RagasはデフォルトでOpenAIのモデルを使用していますが、お好きなモデルを自由に使用することができます。Ragasを使って100点のデータを生成してみましょう。 質問タイプの分布は、必要に応じて自由に変更してください。テストデータセットの準備ができたので、次にLlamaIndexを使用して簡単なRAGパイプラインを構築しましょう。 LlamaIndexでRAGアプリケーションを構築する LlamaIndexは、RAGアプリケーションを構築するための使いやすく柔軟なフレームワークです。 今回は簡単に構築するため、デフォルトのLLM（gpt-3.5-turbo）とエンベッディングモデル（openai-ada-2）を使用して進めていきます。 Phoenixをバックグラウンドで起動し、OpenInferenceのスパンとトレースがPhoenixに送信され、Phoenixによって収集されるように、LlamaIndexアプリケーションをインスツルメンテーションします。OpenInferenceはOpenTelemetryの上に構築されたオープンスタンダードで、LLMアプリケーションの実行をキャプチャして保存します。これは、LLMの実行や、ベクターストアからの検索、検索エンジンやAPIなどの外部ツールの使用など、周囲のアプリケーションコンテキストを理解するために使用されるテレメトリーデータのカテゴリとして設計されています。 クエリーエンジンを構築します。 Phoenixをチェックすると、コーパスデータがインデックスされた時からの埋め込みスパンが表示されるはずです。 後でノートブックで可視化するために、これらの埋め込みデータをデータフレームにエクスポートして保存します。 Phoenixを再起動して、蓄積された痕跡を消去します。 LLM申請書の評価 RagasはRAGパイプラインをコンポーネント単位とエンドツーエンドの両方で評価するために使用できるメトリクスの包括的なリストを提供します。 Ragasを使用するために、まず生成された質問と回答、取得されたコンテキスト、およびグランドトゥルースの答え（与えられた質問に対する実際に期待される答え）からなる評価データセットを形成します。 Phoenixをチェックして、LlamaIndexアプリケーションのトレースを表示しましょう。 1つは後で可視化する埋め込みデータ、もう1つはRagasを使って評価する予定のトレースとスパンをエクスポートしたものです。 RagasはLangChainを使ってLLMアプリケーションのデータを評価します。LangChainをOpenInferenceで計測して、LLMアプリケーションを評価するときに何が起こっているのか見てみよう。 LLMの軌跡を評価し、評価スコアをデータフレーム形式で表示します。 評価をPhoenixに連携すると、スパン上の注釈として表示されます。 Phoenixをチェックアウトすると、Ragasの評価がアプリケーションスパンの注釈として表示されます。 エンベッディングの可視化と分析 エンベッディングは、検索された文書やユーザークエリの意味をエンコードします。 エンベッディングはRAGシステムにとって不可欠な要素であるだけでなく、LLMアプリケーションのパフォーマンスを理解し、デバッグするために非常に有用です。 Phoenixは、RAGアプリケーションから高次元の埋め込みデータを取り出し、その次元を減らし意味を持つデータ群にクラスタ化します。その後、アプリケーションのパフォーマンスを視覚的に検査し、問題のあるクラスタを表面化するために、任意のメトリック（例えば、Ragas-computed
- [LLM RAG（検索拡張生成）のロードマップについて](https://ichizoku.io/the-llm-retrieval-augmented-generation-rag-roadmap/) - アンバー・ロバーツ 機械学習エンジニア | 一月, 2024 検索と取得のユースケースを最大限に活用するために必要なステップを理解する 特定のビジネスニーズに合わせてカスタマイズされたチャットボットを作成するには、独自のナレッジベースを活用する必要があります。 検索拡張生成（RAG）を使用すると、チャットボットは独自のドキュメントから情報を組み込むことによって、その理解を強化することができます。 大規模言語モデル（LLM）によって生成されたコンテンツは、外部ソースから取得された関連資料を追加することによって、強化または増強されます。RAGの主な強みはそのデータ検索方法であり、LLMにコンテンツ生成プロセスを大幅に豊かにする追加コンテキストを提供します。 RAGロードマップは、データ検索から回答生成まで、RAGを支える複雑なプロセスの明確な道筋を示しています。 今回は、これらのステップを詳しくご紹介し、RAGのオンラインとオフラインのモードの違いを検証していきます。 RAGロードマップの旅は、技術的な側面に焦点を当てるだけでなく、検索および検索結果を評価する最も効果的な方法を示します。 LLM RAGを使う前に知っておくべきこと どのようなロードマップでもそうですが、まず自分がどこへ向かっているのか、そしてどのようにそこへ向かっていくのかを知る必要があります。 RAGを使っているのであれば、以下ようなことを覚えておくと役に立ちます。 コストとリスクを削減しようとし、パフォーマンスを最適化しようとしている。 独自のデータを使用している。使用しているLLMアプリケーションが応答を生成するために安全なデータを必要としない場合、LLMに直接プロンプトを表示し、追加のツールやエージェントを使用して応答を適切なものに保つことができる。 プロンプトエンジニアリングの初心者である。LLMから最適な出力を得るために、プロンプトテンプレートとプロンプトエンジニアリングを試す。ただし、プロンプトはユーザーのクエリに追加のコンテキストを追加するものではない。 LLMの微調整 LLMに明示的な例を提供することで、特定のタスクをよりうまくこなせるようにモデルを微調整する。ファインチューニングは、プロンプトエンジニアリングによるパフォーマンス改善やRAGによる関連コンテンツの追加を実験した後に行うのがベター。これは反復のスピードとコストに起因しており、検索インデックスを最新の状態に保つことは、LLMを継続的に微調整し再トレーニングするよりも効率的である。 RAGシステムを構築している場合、検索された関連知識がクエリ応答における事実性を高め、モデルのハルシネーションを減らすことを期待して、LLMアプリケーションシステムに最近の新しい知識を追加していることになります。 LLM RAGの主な構成要素とは？ RAG（検索拡張生成）は、生成AIの強みと検索エンジンの機能を融合させた複雑なシステムのことです。 RAGを完全に理解するためには、その主要なコンポーネントを分解し、それらがシームレスなAIエクスペリエンスを生み出すためにどのように機能するのかを知ることが必要不可欠です。 RAGの主要な構成要素をいくつかご紹介します。 検索エンジン これはRAGプロセスの最初のステップです。膨大な情報のDBから、入力されたクエリに対応する関連データを検索します。このエンジンは高度なアルゴリズムを使用して、検索されたデータが最も関連性が高く、最新のものであることを保証します。 オーグメンテーション・エンジン 関連データが検索されると、オーグメンテーション・エンジンの出番です。検索されたデータを入力クエリと統合し、コンテキストを強化し、回答を生成するためのより多くの情報を提供します。 ジェネレーション・エンジン ここで実際のレスポンスが生成されます。増強された入力を使用して、生成エンジン（通常は高度な言語モデル）は、首尾一貫した、文脈に関連したレスポンスを作成します。このレスポンスは、モデルの既存の知識に基づくだけでなく、検索エンジンによってソースされた外部データによって強化されます。 RAGロードマップ LLM RAGシステムが、入手可能な最新かつ関連性の高い情報に基づいて正確な回答を提供することを保証するにはどうすればよいでしょう？ RAGのプロセスは一連のステップとみなすことができ、それぞれが最終的なアウトプットに貢献します。 以下は、ステップ・バイ・ステップのRAGロードマップです。 正確性と妥当性を確保するため、RAGには6つの段階があり、それは順次より大規模なRAGの一部となります。 データのインデックス化 RAGが情報を検索する前に、データはインデックスに集約され、整理されなければなりません。このインデックスは検索エンジンの参照点として機能します。 入力クエリー処理 ユーザーの入力はシステムによって処理・理解され、検索エンジンの検索クエリの基礎となります。 検索とランキング 検索エンジンはインデックスされたデータを検索し、入力クエリとの関連性の観点から結果をランク付けします。 迅速な補強 最も関連性の高い情報を元のクエリと組み合わせます。この拡張されたプロンプトは、応答生成のための豊富なソースとして機能します。 レスポンス生成 最後に、生成エンジンはこの拡張されたプロンプトを使用して、情報に基づいた文脈に正確なレスポンスを作成します。 評価 どのようなパイプラインでも重要なステップは、他のストラテジーとの相対的な効果や、変更を加えたときの効果をチェックすることです。評価では、応答の正確さ、忠実さ、スピードについて客観的な尺度を提供します。 これらのステップに従うことで、RAGシステムは正確なだけでなく、利用可能な最新の関連情報を反映した回答を提供することができます。このプロセスは、オンラインとオフラインの両方のモードに適応可能であり、それぞれに独自の用途と利点があります。 RAG（検索拡張生成）の応用例 RAGの実用的なアプリケーションを理解するために応用例を挙げましょう。 プライベートな知識ベースを照会するように設計されたチャットボットにRAGが採用されている、というシナリオです。
- [LLM評価の実行、ベンチマークに必要なものについて解説](https://ichizoku.io/llm-evaluation-everything-you-need-to-run-benchmark-llm-evals/) - この記事は、機械学習エンジニアの Ilya Reznik による共著です。 なぜLLMの評価が必要なのか？ 大規模言語モデル（LLM）は、開発者やビジネスリーダーにとって、消費者に新しい価値を生み出すための素晴らしいツールです。 個人的な推薦をしたり、構造化データと非構造化データとの間で翻訳をしたり、大量の情報を要約したり、その他多くのことができます。 そんなLLMを利用したアプリケーションが増えれば増えるほど、性能を測定することの重要性も増していきます。 LLMによる評価が必要なのは、ユーザーからのフィードバックやその他の「真実の情報源」が極めて限られており、存在しないことが多いためです。 幸いなことに、LLMの力を使って評価を自動化することができます。 この記事では、これをどのように設定し、信頼できるものにするかを掘り下げていきます。 LLM評価の核心は、AIがAIを評価することである。 回りくどく聞こえるかもしれませんが、私たち人間は常に人間の知性に人間の知性を評価してもらってきました（例えば、就職面接や大学の期末試験など）。 そして今、AIは他のAIに対しても同じことができるようになったのです。 ここでのプロセスは、LLMが他のシステムを評価するために使用できる合成的な真実を生成することです。 なぜ人間のフィードバックを直接使わないのか？ それは決して十分ではないからです。 1パーセントでも人間のフィードバックからインプットとアウトプットの組み合わせを得ることは大変重要です。 たいていのチームはそれすらできません。しかし、このプロセスを真に有益なものにするためには、LLMのサブコールのすべてに評価を行うことが重要です。 その方法を探ってみましょう。 LLMモデル評価とLLMシステム評価の比較 「LLMエバリュエーション」という言葉を聞いたことがあるかもしれません。LLMエバリュエーションという言葉はいろいろな使われ方をしており、どれもよく似ているように聞こえますが、実はまったく異なります。 LLMモデル評価（エバリュエーション）とは？ LLMモデルのエバリュエーションは、基礎となるモデルの全体的なパフォーマンスに焦点を当てています。 オリジナルの顧客向けLLMを立ち上げた企業は、さまざまなタスクにわたってその有効性を定量化する方法を必要としていました。 今回は、2つの異なるオープンソースの基礎モデルを評価しています。 2つのモデル間で同じデータセットをテストし、hellaswagやmmluのようなメトリクスがどのように積み重なるかを注視しています。 LLMモデルの評価指標 LLMのモデル評価を行う人気のあるライブラリのひとつに、OpenAI Evalライブラリがあります。HellaSwag（LLMがどの程度文章を完成できるかを評価する）、TruthfulQA（モデルの応答の真実性を測定する）、MMLU（LLMがどの程度マルチタスクができるかを測定する）のような多くのメトリクスがあります。また、オープンソースのLLMがどれだけ優れているかを評価するリーダーボードも用意されています。 ハギング・フェイス OpenLLM リーダーボード LLMシステム評価（エバリュエーション）とは？ ここまで、LLMモデル評価について述べてきました。これに対して、LLMシステム評価とは、システム内でコントロールできるコンポーネントを完全に評価することです。 これらのコンポーネントの中で最も重要なものは、プロンプト（またはプロンプトテンプレート）とコンテキストです。 LLMシステム評価では、入力がいかに適切に出力を決定できるかを評価します。 たとえばLLMを一定に保ち、プロンプトテンプレートを変更することで比較評価します。プロンプトはシステムのより動的な部分であるため、この評価はプロジェクトの生涯を通じて大きな意味を持ちます。 例えば、LLMはチャットボットの応答の有用性や丁寧さを評価することができ、同じ評価を行うことで、本番環境でのパフォーマンスの経時変化に関する情報を得ることができるのです。 このケースでは、2つの異なるプロンプトテンプレートを1つの基礎モデルで評価しています。2つのテンプレートで同じデータセットをテストし、精度やリコールなどのメトリクスがどのように積み重なるかを見ています。 LLMシステム評価とLLMモデル評価の役割による使い分け LLM評価を利用するペルソナには違いがあります。 ひとつはモデル開発者、あるいはLLMのコア部分の微調整を行うエンジニアです。もうひとつはユーザー向けのシステムを構築する実務家です。 LLMモデル開発者はごく少数で、OpenAI、Anthropic、Google、Metaなどで働くようなエンジニアたちです。 モデル開発者は、LLMモデルの検証に気を配ります。彼らの仕事は、様々なユースケースに対応するモデルを提供することだからです。 MLの実務家にとっても、タスクはモデル評価から始まります。 LLMシステムを開発する最初のステップの1つはモデルを選ぶことです（GPT 3.5 や GPT 4、Palmなど）。 しかし、このグループのLLMモデル評価は、多くの場合一度きりのステップです。 一旦、ユースケースにおいてどのモデルがベストなのかが決まれば、アプリケーションのライフサイクルの残りの大部分はLLMシステム評価によって定義されます。 このように、ML実務者はLLMモデル検証とLLMシステム検証の両方に関心を持ちますが、おそらく後者に多くの時間を費やします。 LLMシステムの評価指標はユースケースによって異なる
- [LLMOps（大規模言語モデル運用）開発者ガイド： LLMの運用](https://ichizoku.io/intorudction-to-llm-ops/) - ハカン・テクグル（MLソリューション・エンジニア）｜2023年5月21日号掲載 効果的な大規模言語モデル運用の3つの鍵 このブログの共著者はAparna Dhinakaranです。 本番環境における機械学習モデルの運用と効果的なモニタリング（MLOps）は、ここ数年新たなトピックとなっています。 本番環境でモデルが静かに故障し始めた場合、問題を理解し、タイムリーにモデルのトラブルシューティングを行うために、適切なセットアップを行うことが重要です。 GPT-4が従来の様々なモデル・タスクの代替として使用される機会は日々増加しています。 現在、多くのチームがモデルとみなしているものも、将来的にはプロンプトとレスポンスのペアになるかもしれません。 チームが大規模な言語モデルを本番環境に導入する際にも、パフォーマンスやタスクの測定に関する課題は依然として存在します。 したがって、LLMOpsは大規模な言語モデルをスケールし、効果的に本番環境にデプロイするために不可欠です。 LLMOpsとは何か？ 大規模言語モデル運用（LLMOps）は、プロンプトエンジニアリング、LLMエージェントのデプロイ、LLMの観測性など、いくつかのテクニックを組み合わせて、言語モデルを特定のコンテキストに最適化し、ユーザーに期待通りの出力を提供できるようにするための分野のことです。 この記事では、それぞれのテクニックを詳しく取り上げ、プロダクトでLLMを維持するためのベストプラクティスについて解説していきます。 プロンプトエンジニアリング プロンプトとレスポンスという概念は、大規模な言語モデルの導入後に普及し始めました。プロンプトとはユーザが言語モデルに提供する特定のタスクのことで、レスポンスとはタスクを達成するための言語モデルの出力のことです。 例えば、ユーザが最近の診断の医療レポートを提供し、ChatGPTにドキュメントの要約を依頼するとします。 この場合、医療文書と要約するアクションがプロンプトであり、要約自体がレスポンスを意味します。 プロンプトエンジニアリングとは、簡単に言えば、ChatGPTのようなAIソフトウェアと会話し、情報を受け取る能力のことです。 プロンプトエンジニアリングが上手であればあるほど、LLMに対する特定のタスクを完了させるために必要な指示が的確になります。 注意深く作られたプロンプトは、モデルが望ましいアウトプットを生成するように導くことができますが、一方、プロンプトの作りが悪いと、無関係な、あるいは無意味な結果をもたらす可能性があります。 プロンプト・エンジニアリングの一般的なアプローチとは？ プロンプトエンジニアリングの一般的なアプローチには、数発のプロンプト、インストラクターベースのプロンプト、思考の連鎖プロンプト、自動プロンプト生成などがあります。それぞれについて掘り下げてみましょう。 Few-Shotプロンプティング Few-Shotプロンプティングは、プロンプトエンジニアリングのテクニックで、ユーザが大規模な言語モデルが実行すべきタスクのいくつかの例とタスクの説明を提供する。これは、タスクの具体例がある場合に使用すると非常に便利なテクニックです。 Instructor-Basedプロンプティング Instructor-Basedプロンプティングは、LLMに特定の人物になりきってタスクを実行するよう指示するものです。 例えば、特定のトピックについてブログを書こうとしている場合、プロンプトの例としては、「あなた(LLM)はこのトピックに関する専門家として…」で始めることです。こうすることで、反応が最適化されます。 思考連鎖プロンプティング / CoTプロンプティング 思考連鎖プロンプティング（CoTプロンプティング）は、適切なレスポンスを得るために小さなタスクを段階的な順序で実行するよう指示する手法です。複雑なタスクを達成するために使用されます。CoTプロンプトをインストラクターベースのプロンプトや数発プロンプトと組み合わせることで、最良の結果を得ることができます。 プロンプトの自動生成 最後に、大規模な言語モデルを活用して、特定のタスクに対するプロンプトを生成することもできます。ユーザーは、達成したいタスクを数行記述するだけで、言語モデルにさまざまな選択肢を提示させることができます。その後、ユーザーは最適なプロンプトを検索し、最も興味のあるプロンプトを選択することができます。 なぜプロンプト・テンプレートが重要なのか？ プロンプトエンジニアリング以外に、プロンプトテンプレートを使用することは、タスク固有のLLMを本番環境に導入する上で非常に重要です。プロンプトテンプレートは、ユーザーのプロンプトの直前に置かれるプリアンブルテキストとして定義できます。プロンプトテンプレートを使用することで、LLM開発者はユーザーが提供するプロンプトのシンプルさに関係なく、出力形式と品質を標準化することができます。 プロンプトテンプレートは、プロンプトを生成するためのスケーラブルで再現可能な方法を作成し、言語モデルへの指示、数ショットの例、または実行するアクションの異なるチェーンを含めることができます。具体的な例を見てみましょう。 プロンプト・テンプレート 上の例は、再現可能なアウトプットのための言語モデルを準備するために、少数ショットと命令ベースの言語を使用するプロンプトです。このテンプレートを使って、異なる製品セットに固有の名前を生成できるLLMアプリケーションを展開することができます。ユーザーがしなければならないのは、製品の種類を入力することだけです！ プロンプトはどのように管理されるのか？ プロンプトエンジニアリングとプロンプトテンプレートのほかに、本番環境でのプロンプト管理を考慮することも重要です。LLMアプリケーション内では、さまざまなプロンプトテンプレートやユーザー入力が継続的に実行される可能性があり、プロンプトを保存し、そのワークフローを制御することは非常に重要です。したがって、アプリケーション開発中に本番用プロンプトを入れ替えたり、プロンプトを反復したりする機能を考慮する必要があります。たとえば、ユーザーからのフィードバックに基づいて、さまざまなプロンプトテンプレートを使用してA/Bテストを実施し、各プロンプトのパフォーマンスをリアルタイムで追跡することができます。 LLMエージェントとは何ですか？ プロンプトを効果的に管理することとは別に、特定のコンテキストやタスクに合わせた特定のLLMアプリケーションを開発することは、困難な取り組みであることがわかります。 これには通常、関連データを収集し、それを処理するためにさまざまな方法を利用し、LLMを微調整して、ビジネスコンテキスト内で最適な応答を提供できるようにすることが含まれます。 幸いなことに、プロセスを合理化し、アプリケーションをより効率的に拡張できるツールがいくつかあります。 LLM開発者の間で最も人気のあるツールの1つは、LLMエージェントです。このツールは、論理的な順序で関連するプロンプトと回答のシーケンスを作成することにより、ユーザが迅速に回答を生成できるように支援します。 LLMエージェントは、LLMを活用し、ユーザーの最初のプロンプトに基づいて、どのアクションを取るべきかを決定します。LLMエージェントは、ウェブサイトの検索やデータベースからの情報抽出などのタスクを実行するように設計されたさまざまなツールを利用し、ユーザーに包括的で詳細な回答を提供します。 基本的にエージェントはLLMとプロンプトテンプレートを組み合わせて、最終的にユーザーに回答を提供する一連のプロンプトと回答のペアを作成します。 エージェントは、様々なソースからコンテキストに特化したデータを引き出し、適切なプロンプトテンプレートを利用することで、ユーザーにとって最も価値のある情報を探し出す、エキスパートのブレンドとして機能することができます。LLMエージェントの最も顕著な例の一つがLangChainであり、一般的に検索拡張生成の概念を採用しています。このアプローチでは、ユーザのクエリに答える最も関連性の高い情報を特定するために、ドキュメントの一部を使用します。LLMエージェントのアーキテクチャ図を以下に示します。 製品ドキュメンテーションチャットボットのためのLLMエージェントアーキテクチャの例 LLMの可観測性とは？ 前述したように、多くの機械学習チームが達成しようとしていることは、将来的にはプロンプトやエージェントの連鎖で達成されるかもしれません。そのため、従来の機械学習の可観測性と同様に、LLMの可観測性は、LLMアプリケーションを大規模にデプロイするために必要不可欠です。 LLMの可観測性は、すべてのプロンプトテンプレート、プロンプト、および応答がリアルタイムで監視されていることを確認するためのツールであり、プロンプトエンジニアは、否定的なフィードバックの根本原因を容易に見つけ、理解し、プロンプトを改善することができます。 LLM観測システムが収集するデータとは？ 上の図は、LLMの可観測性が基礎モデルの世界でどのように見えるかを示しています。システムへ出入りするインターフェースは、プロンプトとレスポンスのペアの文字列です。入力と出力は、可観測システムによって収集される、以下のようなデータで構成されています。 プロンプトとレスポンス
- [Fraud Detection Model Performance Monitoring](https://ichizoku.io/fraud-detection-model-performance-monitoring/) - Return to Videos
- [Fraud Detection Model - Troubleshooting Drift](https://ichizoku.io/fraud-detection-model-troubleshooting-drift/) - Return to Videos
- [Troubleshoot Embeddings with Arize](https://ichizoku.io/troubleshoot-embeddings-with-arize/) - Return to Videos
- [Set Up Monitors (Alerts) - Quickly Become Aware of Model Issues with Arize](https://ichizoku.io/set-up-monitors-alerts-quickly-become-aware-of-model-issues-with-arize/) - Return to Videos
- [Find the Root Casue of ML Model Degradation](https://ichizoku.io/find-the-root-casue-of-ml-model-degradation/) - Return to Videos
- [Optimize LLM Model Performance with Arize](https://ichizoku.io/optimize-llm-model-performance-with-arize/) - Return to Videos
- [LLM Model Debugging with Arize](https://ichizoku.io/llm-model-debugging-with-arize/) - Return to Videos
- [Troubleshoot LLM Application with Phoenix Code](https://ichizoku.io/troubleshoot-llm-application-with-phoenix-code/) - Return to Videos
- [Why ML & LLM Observability?](https://ichizoku.io/why-ml-llm-observability/) - Return to Videos
- [企業幹部が今、LLMOpsツールに注力すべき理由](https://ichizoku.io/why-enterprise-executives-should-be-hip-to-llm-ops-tools-japanese/) - アリゼ、MLセールスエンジニア、カム・ヤング 顧客サービスの品質向上から、創薬の迅速化まで、生成AIは急速に業界の常識を変化させ続けています。 最近の調査によると、企業のエンジニアリングチームの61.7%が、1年以内に大規模言語モデルのアプリケーションを導入している・導入する予定であり、4月の8.3%に比べ、10分の1以上（14.7%）がすでに実稼働しています。 導入のスピードが速いことを考えると、初期のギャップによる苦痛は避けられません。 LLMを早期に導入した企業の半数近く（43％）が、評価、幻覚、不必要な抽象化といった問題を導入の課題として挙げています。大企業がこのような課題を克服して成果を上げ、組織のリスクを最小限に抑えるにはどうすればよいのでしょうか。 ここでは、LLMの導入に成功している企業が、この課題を克服するために採用している3つのカギを紹介します。 変化する状況への不可知論的アプローチ エンジニアリングチームが、1つの基盤モデル（例：OpenAIのGPT-4）やオーケストレーション・フレームワーク（例：LangChain）にしか接続できないインフラを構築するのに1ヶ月という期間を費やしてしまうことを仮定します。 そうしたら、すぐに自分たちの仕事、あるいはビジネス戦略全体が時代遅れになってしまうリスクが生じてしまいます。 企業のLLM可観測性とスタックが不可知論的であり、主要な基礎モデルとツールに簡単に接続できることを保証することで、切り替えコストと摩擦を最小限に抑えることができます。 LLM科学実験の運用化 ファウンデーションモデルプロバイダーが独自のエバリュエーション（事実上、宿題の採点）を提供するこの分野では、独立したLLM評価を開発または活用することが重要です。 ArizeのLLM評価ツールやその他のツールは、LLMを客観的にナビゲートすることができます。この客観性は、データサイエンティストと機械学習プラットフォームエンジニアのチームと相まって、組織がLLMユースケースのために何百もの科学実験を迅速に自動化し、運用するための強固な基盤を提供し、生産における信頼性と企業全体におけるAIの責任ある使用を保証することができます。 ROIと生産性向上の定量化 モデルの複雑さと新規性を考慮すると、生成AIの実装は困難で時間がかかる可能性があります。 収益に影響を与えるLLMアプリのパフォーマンスの問題を検出するためのシステムを確実に存在させること（根本的な原因を積極的かつ自動的に浮上させるための関連ワークフローを含む）は特に重要です。ここで、オープンソースやその他のツールは、UMAP、スパン、トレース、プロンプト・プレイグラウンドなどのようなインタラクティブでガイド付きのワークフローを通じて、混乱を最小限に抑えるのに役立ちます。 結論 生成AIが進化を続ける中、LLMアプリを確実かつ責任を持ってデプロイする義務と、現代特有の競争圧力を考慮したスピード感とのバランスを取るのは難しいかもしれません。 今回ご紹介した、大規模言語モデルの運用（LLMOps）の展望をナビゲートするための3つの鍵が、あなたの役に立つことを願っています！
- [Why Enterprise Executives Should Be Hip To LLMOps Tools Heading Into the New Year](https://ichizoku.io/why-enterprise-executives-should-be-hip-to-llm-ops-tools-english/) - Ichizoku is on a mission to help Japanese companies adopt AI more quickly and with greater success. That is why we partnered with Arize AI, the leader in LLM and ML observability. In this blog by Cam Young, an ML Sales Engineer at Arize, Cam dives into why embracing these technologies is more than a
- [LLMの観測可能性とは？](https://ichizoku.io/what-is-llm-observability-japanese/) - アパルナ・ディナカラン、共同創設者兼最高製品責任者 LLMが持つ5つの特徴と能力について 2022年11月、ChatGPTがデビューし、多くの人が大規模言語モデル（LLM）の能力を初めて目にしたとき、技術業界は永遠に変わった。 その時以来、誰もがその一部を欲しがっている。例えば エクスペディアがLLMベースの旅行プランナーを開発中 Notionはインラインコンテンツ生成を提供 StripeはChatGPTを使って詐欺を管理し、コンバージョンを増やそうとしている。 DuolingoとKhan AcademyはLLMを使って学習を強化しようとしている。 マイクロソフト、メタ、グーグルのような大企業が自社の製品にLLMを使用していることは言うまでもない。アマゾンは現在、販売者が説明文を自動生成できるようにする競争に参入している。 これらの製品は様々な成熟段階にあるが、機械学習システムのデモと実際の製品との間に隔たりがあることは明らかだ。機械学習を製品化することは常に難題であったが、LLMによってその難題はさらに難しくなった。 LLMの典型的な使用例とは？ LLMアプリケーションに共通するユースケースは数多くある。ここではその一部を紹介し、それぞれの詳細については今後の記事で取り上げる。 チャットボット ChatGPTは当初、チャットボットを通じて大衆にLLMを紹介したので、このユースケースは非常に一般的です。ユーザーが質問し、システムが情報を検索してプロンプトを充実させ、LLMが応答を生成する。 構造化データ抽出 構造化データ抽出のユースケースでは、LLMは非構造化入力をスキーマとともに受け取り、情報の構造化表現を出力する。これは、より大規模なソフトウェア・システムのコンテキストで有用であることが多い。 要約 自然言語処理（NLP）は長い間、優れた要約の解決策を模索してきた。従来の抽出的、抽象的要約技術の多くは、現在ではLLMに取って代わられている。 その他の使用例 これらに加え、コード生成、ウェブスクレイピング、タグ付けとラベリングなど、より専門的なユースケースも多い。 LLMは、Q&Aアシスタントやチャット・ツー・ペイなど、より複雑なユースケースにも採用されている。これらは、高次の目的を達成するステップ（スパン）で構成される。スパンは、他のLLMユースケース、伝統的な機械学習システム、または非MLのソフトウェア定義ツール（電卓のような）とすることができる。 これらのワークフローは便利だが、複数のシステム上で適切なオーケストレーションを必要とするため、非常に複雑でもある。これらのワークフローは多くのコードを必要としないが、その簡潔さを単純さと混同してはならない。たとえ数行でも、エラーの可能性のある非常に長い計算の連鎖を引き起こす可能性がある（挿入図参照）。 この複雑さが、今日のLLMプロジェクトが「ツイッター・デモ」から顧客の使用に至るまでに経験する困難につながっている。 LLMにはどのような問題があるのか？ よくある問題をいくつか挙げてみよう。 幻覚： トレーニングにおけるモデルの目的は、次の数文字を予測することである。回答の正確さはむしろ副次的なものである。そのため、幻覚、つまり事実に基づかないでっち上げの回答はよくあることであり、予測不可能である。あなたはLLMを近道として使っているが、もしそのLLMに書いてあることをすべてダブルチェックしなければならないとしたら、それほど役に立たないかもしれない。しかし、確認しなければ、本当に困ったことになるかもしれない。 電話の多発： 幻覚の問題を解決することさえ、より大きな問題を引き起こす可能性がある。例えば、前述の問題を回避する一つの方法として、LLMに自身の結果を分析するよう求める「リフレクション」がある。このテクニックは強力だが、ただでさえ複雑なシステムをさらに複雑にしてしまう。1回の呼び出しではなく、呼び出しの連鎖が発生するのだ。これはどのスパンでも同じなので、上で話した複雑なユースケースの場合、複数のスパンの中に複数のコールが存在することになる。 独自データ： 独自データをミックスに加えると、事態はさらに面白くなる。複雑な質問に答えるために必要なデータの多くが、プロプライエタリなものであるという現実がある。LLMのアクセス制御システムは、従来のソフトウェアほど堅牢ではない。プロプライエタリな情報が誤って回答に入ってしまう可能性があるのだ。 応答の質： 回答の質は、他の理由でも最適でないことがよくある。例えば、口調がおかしいとか、詳細が不適切であるなどです。ほとんど構造化されていない回答の質をコントロールするのは非常に困難です。 コスト 次に、部屋の中の象がある：コスト。スパン、リフレクション、LLMへの電話などをすべて合わせると、かなりの金額になる。 第三者モデル： サードパーティプロバイダーを通じてアクセスされるLLMは、時間とともに変化する可能性がある。APIが変更されたり、新しいモデルが追加されたり、新しいセーフガードが導入されたりする可能性があり、これらすべてがモデルの振る舞いを変える原因となる。 限られた競争優位性： より大きな問題は、LLMの訓練と維持が難しいことだろう。したがって、あなたのLLMモデルは競合他社と同じであり、本当に差別化できるのは、迅速なエンジニアリングと独自データへの接続である。それらをうまく使っていることを確認したいものです。 これらは難しい問題だが、幸いなことに、すべてに取り組むための第一歩は同じである。 LLMの観測可能性とは？ LLMの可観測性とは、LLMベースのソフトウェアシステムのすべてのレイヤー（アプリケーション、プロンプト、レスポンス）を完全に可視化することである。 LLM観測可能性とML観測可能性の比較 大規模な言語モデルはMLに新しく参入したものだが、旧来のMLシステムと多くの共通点があるため、観測可能性はどちらの場合でも同様に作用する。 MLの可観測性と同様に、埋め込みは非構造化データを理解するのに非常に有用であり、過去に説明したような埋め込み技術はLLMではさらに重要である。 モデルの性能を理解し、それを経時的に追跡することは、相変わらず重要である。データ・ドリフトとモデル・ドリフトを理解することは、セクション3で取り上げた理由から重要である。 データ収集（プロンプト／回答の履歴）は、ドリフトを理解し、モデルを微調整する上で、LLMでも依然として非常に重要である。 しかし、いくつかの重要な違いもある： LLMの導入モデルは従来のMLとは大きく異なる。LLMの導入モデルは、より伝統的なMLとは大きく異なります。ほとんどの場合、LLMにサードパーティーのプロバイダーを使用している可能性が高いため、モデルの内部を見ることはできません。 評価は、ランキングではなく生成の評価であるため、根本的に異なる。そのため、まったく新しいツールセットが必要になり、そのうちのいくつかは、そもそもLLMによってのみ可能になる。 ベクトルストアを使用している場合（そしてほとんどの検索ケースはそうである）、最適な検索を妨げ、その結果、あまり理想的でないプロンプトを生み出すかもしれないユニークな課題がある。 LlamaIndexやLangChainのようなエージェント型ワークフローやオーケストレーションフレームワークは、異なる観測可能性アプローチを必要とする独自の課題を提示している。 大規模言語モデル観測可能性の5つの柱の紹介 LLMの観測可能性の5つの柱を重要な順に理解しよう。それぞれが独自の研究や作品に値するが、ここでは簡単に要約する。
- [What is LLM Observability?](https://ichizoku.io/what-is-llm-observability-english/) - Ichizoku is on a mission to help Japan companies adopt AI faster and with greater success. An extremely important, but often overlooked, practice is LLM Observability. This is why we partnered with Arize AI. Many companies are racing to deploy LLMs, but few have a good answer to the question, "How do you know if
- [Elementor #3767](https://ichizoku.io/elementor-3767/) - Ichizokuとハシゴ・テクノロジーズのCEOであるハリニと私は、グローバルなエンジニアリング・チームの受け入れと管理能力を構築することの価値について、しばしば顧客と議論しています。日本のテクノロジー・リーダーたちは、エンジニアの人材やパートナーをグローバルに求めるようになってきています。この記事では、グローバルエンジニアを積極的に構築しないことで被る可能性のあるマイナス面について説明します。私たちはAI世代に突入しています。 エンジニアリング・チームには新しいスキルが求められます。企業は、採用をローカル市場だけに限定し続けることはできません。潜在的な落とし穴を理解することで、日本のテクノロジー・リーダーは、グローバルなエンジニアリング人材を採用することの緊急性と必要性をより理解することができます。以下は、グローバルエンジニアを積極的に採用しないことによる弊害についてです。 イノベーションの機会を逃すグローバルなエンジニアチームを構築することで、貴重なイノベーションの機会を提供します。 これは、テクノロジーとイノベーションが非常に速く動くからです。チーム内で遅れをとらず、イノベーションを起こすためには、考え方や経験の多様性が重要です。これがないと、企業は従来の思考パターンから抜け出せなくなる可能性があります。画期的な製品やサービスには、既成概念にとらわれない発想が必要です。グローバルなリソースが日本のローカルチームにもたらす創造性とユニークな視点を企業が受け入れることで、イノベーションは成功するのです。 世界市場への参入が難しくなるグローバルなエンジニアリング能力がなければ、日本企業がグローバル市場に参入することは困難でしょう。人材をグローバルに考えることは、日本のテクノロジー企業にとって、言語能力、文化的認識、グローバル市場に対するインサイトを高めることを意味します。これがなければ、企業は海外の顧客のニーズを効果的に伝え、理解することに苦労するかもしれません。その結果、異なる地域に合わせた製品やサービスを提供することが難しくなります。その結果、ビジネスチャンスを逃し、市場シェアを低下させることになりかねません。 スキルのギャップに対応できない日本企業は、新興分野の熟練技術者の不足に直面しています。生成AIもまた、日本で不足するスキルのひとつとなるでしょう。グローバルなエンジニアリングチームを構築する機会を逃すと、日本企業が採用できる人材の幅が小さくなってしまいます。世界的にテクノロジーが急速に進化する中、新しい専門知識を持つエンジニアが不足していると、企業は遅れをとる危険性があります。テクノロジーリーダーには、人工知能、ビッグデータ、クラウドコンピューティングなどの分野のスキルが必要です。グローバルなエンジニアで構成される多様なチームを構築することで、企業はスキルのギャップを埋め、新しい技術の進歩に対応することができるのです。 人材獲得競争で遅れをとる世界的に消費者やユーザーを抱え、ますますグローバル化する市場において、競争力を維持するためには、優秀な人材を獲得し、維持する能力が重要です。グローバルなエンジニアチームを構築している日本企業は、現地の日本人エンジニアを採用する際に、より高い競争力を発揮することができます。グローバルに人材を探す競合他社は、より幅広い人材、多様な視点、グローバル市場のインサイトにアクセスすることができます。グローバルなエンジニアチームを持たない企業は、採用時に新しいエンジニア候補に自信を持てません。 エンジニアチームに他の外国人と仕事をする機会を与えることは、優秀な人材を採用し、現在の人材を維持するための素晴らしい方法です。 スケールアップの難しさとレジリエンス（回復力）グローバルなエンジニアチームがあることで、企業にスケーラビリティとレジリエンスを提供します。さまざまな地域の人材を活用することで、企業は事業を迅速に拡大し、市場の変化に適応してリスクを軽減することができます。グローバルチームを構築しない場合、市場の需要や変動に効果的に対応する能力が制限される可能性があります。 まとめグローバルなエンジニアチームを構築できる日本のテクノロジー企業には、多くの利点があります。グローバルな環境で成功するためには、日本企業がグローバルエンジニアチームを取り入れることの緊急性を認識することが不可欠です。グローバルな人材や希少なスキルへのアクセス、文化の多様性、コミュニケーション能力の向上、市場の拡大、イノベーション、拡張性、雇用やビジネスモデルの回復力など、さまざまなメリットがあります。 今こそ行動すべき時です。企業は、グローバルエンジニアチームを構築することで、将来の成功を実現するだけでなく、リスクを回避することができます。Ichizokuは、日本のテクノロジー企業とともに、高いパフォーマンスを発揮するエンジニアリングチームを構築しています。 グローバルな人材市場へのアクセス方法については、こちらをご覧ください。

## Pages

- [Home](https://ichizoku.io/) - Ichizoku helps enterprises design, deploy, and scale reliable AI agents — bridging the AI Execution Gap from prototype to production. Tokyo-based generative AI solutions.
- [Sentry Technology](https://ichizoku.io/sentry-technology/) - Sentry is the world's leading developer-first observability platform. As Japan's only official Sentry partner, Ichizoku supports your team from implementation to ongoing operations.
- [Sentry Technology - JA](https://ichizoku.io/japan/sentry-technology/) - Sentryは世界をリードするオブザーバビリティプラットフォームです。IchizokuはSentryの国内唯一の公式パートナーとして、導入から運用まで一貫してサポートします。
- [Japan](https://ichizoku.io/japan/) - エンタープライズ向け生成AIエージェントの設計・実装・本番運用を支援。AI実行のギャップを解消し、業務効率とROIの最大化を実現します。
- [AIエージェント開発](https://ichizoku.io/japan/ai-agent-development/) - アイデアのプロトタイプから本番レベルのAIエージェントまで。Ichizokuは精度・安全性・ROIを重視した生成AIエージェントの設計・開発・スケールを支援します。
- [AI Agent Development](https://ichizoku.io/ai-agent-development/) - From prototype to production, Ichizoku helps Japanese enterprises design, develop, and scale reliable generative AI agents — with accuracy, security, and measurable results built in.
- [成功事例](https://ichizoku.io/case-studies-ja/) - Ichizokuが支援した企業の成功事例。AIソリューションの活用を通じて実現した成果をご紹介しています。
- [Case Studies](https://ichizoku.io/case-studies/) - "Explore real-world case studies from companies Ichizoku has supported — see the results Japanese enterprises have achieved through AI solutions.
- [デジタルインテリジェンスで切り拓く未来](https://ichizoku.io/japan/leading-in-the-era-of-digital-intelligence/) - デジタルインテリジェンス時代をリードするためのIchizokuレポート。エージェンティックワークフォースの構築方法と12ヶ月ロードマップを解説しています。
- [Leading in the Era of Digital Intelligence](https://ichizoku.io/leading-in-the-era-of-digital-intelligence/) - Explore Ichizoku's report on leading in the era of Digital Intelligence — learn how to build an agentic workforce with a practical 12-month roadmap.
- [FDEトレーニング](https://ichizoku.io/japan/fde-training/) - ソフトウェア開発者をAIネイティブな Forward Deployed Engineer へ AIネイティブ時代において、従来型のソフトウェア開発スキルだけでは十分ではありません。確率的な振る舞いを持つAIシステムを設計・運用し、ビジネス成果につなげるための実践力が求められています。自社のソフトウェア開発者をビジネス価値を生み出すAIシステムの構築・デプロイができるFDE（Forward Deployed Engineer）に進化させます。 AIエージェントプロジェクトを開始する 無料コンサルティングを予約する 急拡大する需要 AI時代の最注目職種 Forward Deployed Engineer FDEの求人数は2025年に800%以上増加 Forward Deployed Engineerの台頭 AIネイティブ時代の新たなキャリアパス Forward Deployed Engineerはクライアントのニーズに寄り添いながら、AIの進歩を確実にする役割 FDEモデルが急速に普及 AIの統合・導入を加速させるため、エンジニアリング人材をクライアント先のチームに直接組み込む形態であるFDEモデルが、企業の間で急速に広まっている。 AIスタートアップの新たな秘密兵器 Forward Deployed Engineer AI企業はクライアントと協働し、AIツールを現実のユースケースに対応させるためにFDEを起用している。 Forward Deployed Engineerとは？ AIシステムの構築・デプロイ・オーナーシップを一元的に担う役割。ソフトウェア・プラットフォーム・ソリューションを横断し、AIをデモで終わらせず、実際に機能させるために存在します。 成功する FDEエンゲージメントサイクル 1 ビジネスワークフローの理解 ビジネスが実際にどのように動いているかを深く理解することから始める 2 正しい問題を定義 AIで解決すべきワークフローを特定する 3 AIシステムの設計 AIが担うこと、人間が担うこと、使用するデータ、成功指標を決定する 4 既存の制約に合わせた構築 既存データ・システム・セキュリティ・インフラに適合したソリューションを開発する 5 本番環境へのテストとデプロイ 実際のユーザーが利用する本番環境で動くAIをリリースする 6 成果のモニタリングと精度向上 AIエージェントのパフォーマンス、ハルシネーションを改善し、ユーザー定着率を高める エンジニアをFDEへ
- [ニュース](https://ichizoku.io/japan/news/) - Ichizokuの最新ニュース。イベント登壇、メディア掲載、展示会出展などのお知らせをまとめています。
- [AIブログ](https://ichizoku.io/japan/ai-blog/) - IchizokuのAIブログ。生成AIエージェントの最新トレンド、導入事例、技術解説など、エンタープライズAI活用に役立つ情報をお届けします。
- [AI トレーニング](https://ichizoku.io/japan/ai-training/) - IchizokuのAIトレーニングコース。RAG・生成AI・AIエージェント構築・LLM評価・セキュリティ・LLM運用など、エンタープライズ向け実践コースを提供しています。
- [Sentry](https://ichizoku.io/case-studies/sentry/) - Explore how companies have improved observability and accelerated debugging with Sentry — supported by Ichizoku, Japan's only official Sentry partner.
- [Sentry](https://ichizoku.io/case-studies-ja/sentry/) - Ichizokuの支援のもと、Sentryを活用してオブザーバビリティを強化し、不具合対応を加速した事例をご紹介します。
- [Technology Stack](https://ichizoku.io/technology-stack/) - Ichizoku's AI technology stack — featuring tools across observability, agent frameworks, models, and more for building reliable enterprise AI agents.
- [Recorded Webinar](https://ichizoku.io/resources/recorded-webinar/) - Access Ichizoku's resources on AI agents, observability, and enterprise AI.
- [AI Training](https://ichizoku.io/resources/ai-training/) - Practical AI training courses from Ichizoku — covering RAG, GenAI, AI agent development, LLM evaluations, security, and LLM Ops for enterprise teams.
- [AI Blog](https://ichizoku.io/resources/ai-blog/) - Ichizoku's AI blog — the latest insights on generative AI agents, enterprise use cases, and technical guides to help you build and scale reliable AI.
- [Resources](https://ichizoku.io/resources/) - Explore Ichizoku's resources — AI blog, Sentry blog, training courses, recorded webinars, and reports on generative AI agents.
- [Privacy Policy - JA](https://ichizoku.io/privacy-policy-ja/) - Ichizoku株式会社のプライバシーポリシーです。個人情報の取得・利用・管理方法について説明しています。
- [News](https://ichizoku.io/news/) - The latest news from Ichizoku — including conference appearances, media features, and company updates.
- [Recorded Webinar](https://ichizoku.io/japan/resources/recorded-webinar-2/) - Access Ichizoku's resources on AI agents, observability, and enterprise AI.
- [リソース](https://ichizoku.io/japan/resources/) - Ichizokuのリソースページです。AIブログ、Sentryブログ、トレーニング、レポートなどをまとめています。
- [テクノロジースタック](https://ichizoku.io/japan/technology-stack/) - Ichizokuが活用するAIテクノロジースタック。オブザーバビリティ、エージェントフレームワーク、モデルなどの様々なツールを採用しています。
- [ダウンロードコンテンツ](https://ichizoku.io/japan/recorded-webinar/) - IchizokuのAIエージェントやオブザーバビリティに関するリソースをまとめています。
- [Company Overview - JA](https://ichizoku.io/company-overview-ja/) - Ichizoku株式会社の会社概要。2023年創業、東京を拠点とする生成AIソリューション企業です。
- [Company Overview](https://ichizoku.io/company-overview/) - Official company profile of Ichizoku Co., Ltd. — a Tokyo-based generative AI solutions company founded in 2023.
- [会社概要](https://ichizoku.io/japan/company/) - Ichizokuは東京を拠点とする生成AIソリューション企業です。プロトタイプから本番運用まで、信頼性の高いAIエージェントの設計・導入・スケールを支援します。
- [Company](https://ichizoku.io/company/) - Ichizoku is a Tokyo-based generative AI solutions company helping enterprises design, deploy, and scale reliable AI agents — bridging the AI Execution Gap from prototype to production.
- [Arize](https://ichizoku.io/arize/) - Struggling with underperforming LLMs? Arize AI helps you monitor, troubleshoot & boost model performance in real-time—trusted by top AI teams.
- [Contact Us](https://ichizoku.io/contact-us/)
- [Arize AI](https://ichizoku.io/category/arize-ai/) - Discover the latest news, insights, and updates on Arize AI. Stay informed about AI monitoring, model performance, and observability.
- [Sentry](https://ichizoku.io/sentry/) - Ichizokuは日本唯一のSentry公認販売業者です。日本語のドキュメント、動画、サポート窓口で日本のお客様のSentry活用を支援します。 コードを正しく動かして、ユーザーをハッピーに 壊れたコード、クラッシュ、壊れたAPIコールに対処できるデベロッパーファーストで作られた唯一のアプリケーション監視プラットフォームで、手がかりではなく答えを導き出しましょう。350万人以上の開発者と8,500以上のチーム・会社がSentryを利用し、実際に意味がある事項を確かめ、緊急の問題を迅速に解決し、コードについて継続的に学習しています。 お問い合わせ 資料ダウンロード 追跡すべき問題を把握するあらゆるプラットフォームを監視し バグを逃さない 問題を数分で解決する十分な背景情報により、チーム間での 修正の行き来の必要を排除 改善のための洞察を学習するプロジェクト、チーム、組織を通じた トレンドや例外を明らかにする 資料ダウンロード Sentryを使う世界のトップチーム ユーザーやログからは手がかりが得られれば良い方 Sentryは答えを提供します 問題を視覚的にリプレイする Webアプリケーションの操作を視覚的にリプレイし、DOMイベント、コンソールログ、ネットワークコールなどの背景情報を得て、エラーや遅延の問題の根本原因をより速く突き止めましょう 遅さを素早く検知する ダウンタイムになる前にパフォーマンスの問題を迅速に特定しましょう。エンドツーエンドの分散トレース全体を表示し、パフォーマンスの低いAPIコールを正確に判定し、関連するエラーを浮かび上がらせます イベントの軌跡を探りあてる Breadcrumbsは、エラーに至ったイベントの軌跡を表示し、アプリケーション開発を少しでも楽にしてくれます バージョンによる真の変化を見逃さない JavaScriptでもPHPでも、その他のどれでも、リリースを見てどのエラーが対処され、どのエラーが初めて登場したかが一目で分かります イベントの軌跡を探りあてる ソフトウェア開発サイクルは、曖昧さに満ちていることがあります。「イシューオーナー」により、開発者の手元にコントロールを戻し、壊れたコードの素早い修正を可能にします クエリを自在にカスタム リアルタイムアプリケーション監視とは、データをリアルタイムに見ることです。SentryのクエリビルダであるDiscoverを使用して、組織全体の生のイベントデータを照会しましょう データを視覚化 ダッシュボードにより、アプリケーションの監視を視覚的に実行しましょう 開発者向け日本語ドキュメント ダッシュボードにより、アプリケーションの監視を視覚的に実行しましょう ドキュメントへアクセス Sentry ブログ by Ichizoku エラーモニタリングとDevOpsについての世界のベストプラクティスを発信中 「AI-PAX 2026 大阪」出展のお知らせ 08/17/2026 この記事を読む FDEサービスを提供するAIベンダーの選び方 07/08/2026 この記事を読む Tokenmaxxing はROIを生んでいるのか？AIデプロイ計画にオープンソースモデル戦略が欠かせない理由 07/01/2026 この記事を読む さらに読む Sentryは、ソフトウェアチームがより良いソフトウェアをより速く構築できるよう支援します その効果をご自身でお確かめください エンタープライズアプリケーションモニタリング エンタープライズのためのSentry 部門を跨いだ可視化
- [Category](https://ichizoku.io/category/) - Category HomeCategory 「AI-PAX 2026 大阪」出展のお知らせ Ichizoku株式会社（本社：東京都港区、代表取締役社長：Jay Revels）は、2026年10月29日（木）30日（金）にグランフロント大阪で開催される「AI-PAX 2026 大阪［第1回 AIの実践的な活用展］」に出展します。 Ichizok ... Read More FDEサービスを提供するAIベンダーの選び方 By Jay Revels, Ichizoku株式会社 CEO 本記事は、Forward Deployed Engineer（FDE）サービスを提供するAIベンダーを選定する際に、SaaSプロダクト型とレガシーコンサルティング型それぞれに潜む構造的な落 ... Read More Tokenmaxxing はROIを生んでいるのか？AIデプロイ計画にオープンソースモデル戦略が欠かせない理由 By Jay Revels, Ichizoku株式会社 CEO 本記事は、エンタープライズAIのトークンコスト急騰の実態とジェボンズのパラドックス的構造を分析し、オープンソースモデル戦略とハイブリッドアーキテクチャによってAI投資のROIを守る方法を解 ... Read More リアライズ・イノベーションズ、Ichizokuが共同でAI移行を加速するFDEトレーニングカリキュラムの提供を開始 Ichizoku株式会社（本社：東京都港区、代表取締役社長：Jay Revels、以下「同社」）と、リアライズ・イノベーションズ株式会社（本社：東京都港区、代表取締役社長：酒谷 正人、以下「リアライズ」）は、このたび共同開発したFDE（Forward ... Read More AIエグゼキューションギャップ ー チャットライセンスからデジタル従業員へ By Jay Revels, Ichizoku株式会社 CEO 本記事は、日本企業のAI活用率とAIエージェントによる業務自動化率の間に存在する「AIエグゼキューションギャップ」の実態と、1990年代のIT化失敗との構造的な共通点、そしてチャットUIか ... Read
- [Assets](https://ichizoku.io/assets/) - Add Your Heading Text Here Add Your Heading Text Here Add Your Heading Text Here Add Your Heading Text Here Add Your Heading Text Here Add Your Heading Text Here Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo. Read more Set a consultation
- [Home cut](https://ichizoku.io/home-cut/) - Generative AI Agents Have Bugs. We Fix Them. Leading Technology Solutions Company for debugging and testing AI agents. Set a consultation
- [Sample Page](https://ichizoku.io/sample-page/) - This is an example page. It's different from a blog post because it will stay in one place and will show up in your site navigation (in most themes). Most people start with an About page that introduces them to potential site visitors. It might say something like this: Hi there! I'm a bike messenger

## Members

- [Hajime Nomura](https://ichizoku.io/company/hajime-nomura/) - Started his career at NTT Communications, where he led sales teams and played a key role in driving digital transformation for large enterprises. Over the past 15 years, he has held leadership positions—including Sales Director and Country Manager—at global tech companies such as Marin Software, Sprinklr, IDH Media, and OpenClassrooms. Passionate about helping organizations adopt
- [Manish Prabhune](https://ichizoku.io/company/manish-prabune/) - Manish is a strategic technology leader with over 25 years of experience in Japan's digital transformation landscape. As a part of Adobe's Digital Strategy Group in Tokyo, Manish champions AI-driven solutions and advises CXO-level executives on leveraging artificial intelligence to solve complex enterprise challenges. His extensive experience includes 11 years directing global accounts such as
- [Francisco Soares](https://ichizoku.io/company/francisco-soares/) - Francisco earned a Master's degree from the Nara Institute of Science and Technology where he studied Natural Language Processing. He gained experience at companies such as CyberAgent, Cookpad, Google, and Unity, achieving results in technical strategy and custom solution development.At Retail AI, Francisco led the design to release of IoT solutions for physical stores, managing
- [Masataka Shida](https://ichizoku.io/company/masataka-shida/) - Masataka Shida is a software development professional with nearly 10 years of experience in building mobile apps, web applications, and IoT systems from scratch to production. He has worked at both web-based and robotics startups, contributing to a wide range of projects for both consumer and enterprise clients. In recent years, he has served as
- [Jay Revels](https://ichizoku.io/company/jay-revels/) - Jay began his career in Silicon Valley working at Informatica and has built a 20+ year technology and leadership career. The last 10+ years of executive leadership have been in Japan building high performing revenue and technology teams with companies such as Adobe Japan and Marin Software. Jay co-founded Ichizoku to help Japanese Enterprises build
- [Naru](https://ichizoku.io/company/naru/) - Naru is a startup-focused entrepreneur and full-stack Ruby developer with eight years of engineering experience. He specializes in independently building SaaS products that solve real-world problems.His recent work includes ideee , a platform that helps people bring their ideas to life by connecting them with engineers, and Brighty, a digital transformation tool tailored for professional
- [Mani Agrawal](https://ichizoku.io/company/mani-agrawal/) - Mani has a distinguished academic background where he earned a Ph.D. in operations research from North Carolina State University, a M.S. in Engineering from Vanderbilt University, and a Bachelor of Technology from the Indian Institute of Technology. Mani first began his research of Neural Networks during his doctorial studies at North Carolina State University. He

## Members JA

- [Hajime Nomura](https://ichizoku.io/japan/company/hajime-nomura/) - NTTコミュニケーションズにてキャリアをスタート。営業チームをリードし、大手企業のデジタル化を支援した実績を数多く持つ。約15年間にわたり、Marin Software、Sprinklr 、IDH Media、OpenClassromsなど、欧米を拠点とするテクノロジー企業で営業部長やカントリーマネージャーを歴任。重要なビジネス課題を解決するための次世代テクノロジー導入に情熱を注いでおり、大手企業やAIエージェント提供企業を中心にコンサルティングを行なっている。
- [Manish Prabhune](https://ichizoku.io/japan/company/manish-prabune/) - 1998年に来日、製薬・自動車・リテール業界のデジタルマーケティング・ITプログラムにおいて25年の経験を持つ。主に大型のグローバルPJを担当。企業のDX（デジタルトランスフォーメンション）のアドバイザーを務める。『インド式計算』シリーズを始めとする数々の本を執筆したほか、ゲームソフト「インド式計算ドリルDS」の開発に携わった。現在Ichizokuのソートリーダーシップかつアドバイザーとしてサポートしている。
- [Francisco Soares](https://ichizoku.io/japan/company/francisco-soares/) - 奈良先端科学技術大学院大学で自然言語処理を専攻し、修士号を取得。CyberAgent、クックパッド、Google、Unityなどの企業で経験を積み、技術戦略やカスタムソリューション開発で成果を上げる。Retail AIでは、40名以上のチームを指揮し、リアル店舗向けIoTソリューションの設計からリリースまでを担当。当時 400万人以上の月間ユーザーを獲得。同社のソリューションに機械学習を設計、実装を実現。AIに対する強い情熱から、AI技術の専門トレーニングを提供する Furious Green LLCを設立し、大手企業にAIトレーニングを提供。
- [Naru](https://ichizoku.io/japan/company/naru/) - NaruについてNaruは、スタートアップに特化した起業家であり、8年の経験を持つフルスタックのRubyエンジニアです。 一人でSaaSプロダクトを立ち上げる力を強みとし、課題解決型のプロダクト開発に取り組んでいます。 主なプロダクトとして、アイデアとエンジニアをつなぐプラットフォーム「ideee」、コーチ向けのDXツール「Brighty」などがあります。 ユーザー視点を大切にしたテクノロジーで、人やスタートアップの成長を支援し続けています。
- [Masataka Shida](https://ichizoku.io/japan/company/masataka-shida/) - Web系やロボティクス系のスタートアップで、モバイルアプリやWebアプリ、IoTシステムの立ち上げから運用までを一貫して担当。約10年にわたり、個人向けアプリや法人向けソリューションの開発を通じて、幅広い業界の課題解決に取り組む。近年はSREとして、サービスの信頼性向上やクラウドインフラの設計・運用にも携りながら、個人でもアプリの企画・開発・運用を行っている。現場の課題に深く向き合い、技術とビジネスの両面から価値あるソリューションを実装していくことを得意とするソフトウェア開発のプロフェッショナル。
- [Jay Revels](https://ichizoku.io/japan/company/jay-revels/) - シリコンバレーのInformaticaでキャリアをスタートし、20年以上にわたりテクノロジーと組織経営の両面で実績を築く。日本では 10年以上、Adobe Japan や Marin Software などで高い技術力と収益化を実現するチームを牽引し、エグゼクティブリーダーとして活躍。日本企業の発展と業績拡大を支えるAIエージェントの構築を目指し、Ichizoku 株式会社を共同設立。
- [Mani Agrawal](https://ichizoku.io/japan/company/mani-agrawal/) - ノースカロライナ州立大学でオペレーションズ・リサーチの博士号、ヴァンダービルト大学で工学修士号、インド工科大学で技術学士号を取得。ノースカロライナ州立大学で博士課程に在籍中、ニューラルネットワークの研究に着手。その後、cognizant のビジネスコンサルティング部門をヨーロッパで設立、統括。業務効率やサプライチェーンのボトルネックに悩むグローバル企業をサポートし、米国のマニュジスティックス（現Blue Yonder）ではチーフサイエンティスト、マッキンゼー シカゴオフィスではエキスパートコンサルタントとして活躍。その他の実績としては、フォーチュン10社に名を連ねるエネルギー関連企業の事業部門を世界規模で再建、日本の大手自動車メーカー向けにサプライチェーンシステムを設計し、カスタムカーの3週間納期実現に成功。またアメリカ、中国、ヨーロッパの一流グローバル大学にて、大規模システムの最適化などをテーマに講義も行うなど、幅広い実績を持つ。現在はグローバル産業における現実世界の課題を解決するアルゴリズムの開発に情熱を注いでいる。

## Sentry

- [ログを構造化する方法](https://ichizoku.io/sentry/structure-a-log/) - Article by: Kyle Tryon（読了時間：10分） あなたはロギングのレベルを一段引き上げ、クエリや集計ができるようにし、本番環境のデバッグに使える、より価値の高い構造化ログを送れるようにしたとします。さて……では、実際にそれをどう書けばいいのでしょうか。 何をログに残すべきかについては、すでに取り上げましたし、これまでに何度か触れてきたので、ここではふれません。 要約：コードの実行に合わせて、デバッグに役立つコンテキストを集め、意味のある節目で wide-event ログを出力しましょう。成功パスと失敗パスのどちらでも、必ず最終的な結果イベントを出力する。 本記事で取り上げるのは、それらのログを実際にどのように書くかについて、次のような問いに答えていきます。 ログは実際、どのような形であるべきか。 クエリやフィルタリングに役立つものにするにはどうすればよいか。 自分が書くログが、デバッグや、何が起きたのかの把握に役立つとどうすれば分かるのか。 ログを構造化されたものにするのは、単にメッセージを任意の JSON オブジェクトと組み合わせることではありません。そうではなく、ログを実際のアプリケーションデータのように扱います。大きな傾向を把握し、個別のインシデントをデバッグするために、検索・フィルタリング・集計できる必要があるデータとして扱うのです。それらのログを実際にどう書くと選ぶかが、デバッグや何が起きたのかの把握にとってのログの有用性を大きく左右します。 以下は（Sentry の Logs ユーザーと関わり、ロギングからより多くを引き出す手助けをしている立場からの）構造化ログの書き方の一例についての、かなり主観の強いガイドです。 構造化ログの形 どの規約を採用するかそのものよりもそれが予測可能で、一貫して適用されているかどうかのほうが重要です。いったんパターンを定めてそれを守り続ければ、システム内のどのイベントも、そのログメッセージと属性をもとに見つけ出し、理解できるようになるはずです。 私が自分のプロジェクトで使っている規約は次のようなものです。 上の例で気づくいくつかのパターンを、以下で詳しく説明していきます。 イベント名は、domain.action という予測可能なパターンを使う。 使っているプログラミング言語やフレームワークに関係なく、各セグメントは snake_case にする。サービス全体で1つの命名規則にそろえておくと、後々のクエリが格段に楽になる。 属性オブジェクトは、ネストされたオブジェクトではなく、ドット記法を使ってフラットにする。 可視化やグループ化のために、succeeded、failed、retried、canceled、completed といった低カーディナリティの値を持つ、予測可能な result 属性を用意する。 想定内の、あるいは回復可能な失敗には、warning のログレベルを使う。 属性には、プリミティブ値か、プリミティブ値の配列のみを含めるべきである。浅いものも含め、オブジェクトやオブジェクトの配列は入れない。 ESLint でログのパターンを強制する 私は個人的な ESLint プラグインを使っていて、自分の TypeScript プロジェクト全体でこれらのパターンを一貫して守れるようにしています。これは Sentry 公式のプラグインではありません。あくまで私の主観的なガイドラインであり、特定のロギングライブラリに依存しない形で、ログの形をゆるやかに強制する方法です。たとえば zod のスキーマ検証のようなところまでは踏み込みません。 私のパターンに沿って進めたい場合は、以下のプロンプトを使って、私のルールをあなたのプロジェクトにインストール・設定してください。少し違うやり方をしたい場合は、あなた自身のパターンを強制するために、あなたの言語向けの ESLint
- [Sentry + OTLP で .NET の MongoDB クエリをトレースする](https://ichizoku.io/sentry/mongodb-query-tracing-dotnet-sentry/) - Article by: James Crosswell（読了時間：6分） あなたの .NET アプリが MongoDB とやり取りしているなら、遭遇しうるパフォーマンスの問題を効果的にデバッグできるようDB のパフォーマンスを計測できるようにしたいと、まず間違いなく考えるはずです。 そのためには、どのデータベースコマンドが実行されていたのか、どれくらいの時間がかかったのか、そしてそれが一度きりの小さな異常なのか、それともより大きなパターンの一部なのかを知る必要があります。理想を言えば、そのトレースから、関連するエラーやリプレイへと、手作業でつなぎ合わせることなく移動できるようにもしたいところです。 この記事では、まさにそれを実現する方法を次のものを使って紹介します。 MongoDB に組み込まれた OpenTelemetry インストルメンテーション .NET SDK での Sentry の OTLP 取り込みサポート エンドツーエンドの流れを示す、小さなサンプルアプリ 一通り終える頃には MongoDB のスパンとクエリデータを Sentry 上で確認し、次のように掘り下げられるようになります。 なぜこのアプローチなのか Sentry ユーザーのために MongoDB のインストルメンテーションを実現する方法は基本的に2つ考えられます。 1つは、独自の ActivityListener とカスタムのマッピングロジックを備えた専用の Sentry.MongoDB インテグレーションを構築して保守する方法です。これでも機能はしますが、その一方で保守すべきカスタムコードが増え、テレメトリモデル間の変換が増え、説明すべき特殊なインテグレーションがもう1つ増える、ということでもあります。 私たちが選んだのはもう1つの方法である OpenTelemetry を活用し、OTLP 経由で Sentry にスパンを送る方法です。MongoDB はすでに OpenTelemetry 互換の Activity データを出力しており、Sentry も今では OTLP
- [エージェントはあなたが見ているものを理解すべき](https://ichizoku.io/sentry/seer-agent-page-context/) - Article by: Mihir Mavalankar（読了時間：6分） Sentry の Seer Agent を使うと、Sentry 内のデータについてどんな質問でも投げかけ、そのデータを深く掘り下げ、Issue をより速く修正できます。 特に面白い機能の1つが、Sentry で今まさに見ている内容について直接質問できるものです。たとえば「このレイテンシの急上昇は何が原因？」や「このエラーの顧客別・リージョン別の内訳は？」といった質問です。こうした質問に答えるには、エージェントはその瞬間にあなたが Sentry の中で見ているものを、同じように見て理解しなければなりません。そのコンテキストを正しく捉えることは、実は非常に大きな意味を持ちます。答えの質だけでなく、コスト、会話の長さ、そして最終的にエージェントがあなたに代わって行える作業の幅にも関わってくるからです。 シンプルなアプローチ ─ ASCIIスナップショット 少し前まで、Seer は現在のページを理解するために、DOM 要素をスクレイピングして、いわばテキストで描画したスクリーンショットのようなものを取得していました。画面に見えているすべてを、1文字ずつの ASCII グリッドとして捉えるのです。粗い方法ですが、機能はします。人がピクセル化された画像に目を凝らして、おおよその形を認識できるのと同じように、エージェントもそのグリッドを見て、ページに何があるかを推測できます。 しかしこのアプローチには、互いに重なり合う3つの問題があります。 トークンコスト：ASCII グリッドは大きなものです。1つのダッシュボードや Issue フィードのページで、平均して数千トークンを消費することがあり、一部のページでは p95 の計測値が 50k トークン以上に達しました。どの会話にも少なくとも1つはページのスナップショットが含まれ、ユーザーがチャットの途中でビューを切り替えれば、その数はさらに増えます。このコストはエージェントにとって実際に有用な量ではなく、画面に表示されている量に比例して増えていきます。 コンテキストの劣化（context rot）：私たちは主に Claude Sonnet やそれに類するモデルを使っています。能力とコストのバランスが良いためです。これらのモデルはデフォルトで 200k トークンのコンテキスト長を持ち、それをシステムプロンプト、ページのコンテキスト、会話履歴、ツール呼び出しの結果で共有します。それが埋まっていくにつれて、モデルの性能は低下します。前のほうのやり取りが押し出され、エージェントは何を尋ねられたのかを見失い、応答の一貫性が失われていきます。 より豊かなインタラクションへの道がない： ASCII グリッドは何が見えているかは説明できますが、何が可能かは表現できません。「'Edit' をクリックすればこのウィジェットを変更できる」といったヒントを付与する構造もなければ、どの要素が操作可能かを示す方法もなく、エージェントがあなたに代わってページを直接操作するような将来のエージェント的アクションの土台もありません。 以前はこのような見た目でした。（注：データはダミーのプレースホルダーに差し替えていますが、雰囲気は伝わるはずです。すべてが一度に詰め込まれた大きな壁のようなものでした。） 新しいアプローチ ─ 自らを説明するページ ASCII のスクリーンショットに代えて、私たちは各ページがエージェントに対して実質的に自らを説明できる、構造化されたコンテキストシステムへと移行しました。核心となる変化は、何をエージェントに見せるかを誰が決めるのかという点にあります。各 UI コンポーネントは自分が何であり、どんな状態にあり、エージェントに伝える価値のあることは何かを把握していて、その情報を直接提供します。
- [いつ、何をログに残すべきか？](https://ichizoku.io/sentry/apple-update-breaks-app/) - Article by: Ben Coe（読了時間：8分） 本記事は、Sergiy による投稿「【エラー・トレース・ログ・メトリクス】いつ何を使うか」の続編です。 Sentry のようなモダンなオブザーバビリティプラットフォームは、開発者に多くの選択肢を与えてくれます。発生した問題に対して、トレース、プロファイル、メトリクス、ログのどれを使うべきでしょうか。 この記事から1つだけ持ち帰ってもらえるとしたら、迷ったら、まずは狙いを定めたログ行をいくつか追加することから始める ということです。 ログはアプリケーションに追加するのが簡単で、ソフトウェアが本番環境でどのように動いているかについての実際の情報を集め始める、手早い方法でもあります。新しい機能を書くときには、デプロイなしでデバッグできる程度に十分なログを追加するようにしています。ログは一時的なインストルメンテーションであってかまいません。問題を調査するときや機能を検証するときに追加し、役に立たなくなったら削除すればよいのです。 ここからは、アプリケーションをデバッグしやすく、また理解しやすくするために、ログを活用するためのベストプラクティスをいくつか紹介します。 ログに残すことを検討する良い対象 アプリケーションが行う重要な実行時の判断 ユーザーによって、目にするフローが異なることはよくあります。予期しない挙動をデバッグするときには、あるリクエストがどのように処理されたのかを決定づけた、さまざまな判断のすべてを知りたくなります。 例をいくつか挙げます。 あるユーザーにはページの実験的なバージョンを表示する feature flag が有効になっている。 モバイルユーザーは別の体験へとリダイレクトされる。 有料ユーザーと無料ユーザーとで提供される機能が異なる。 アプリケーションが複数のコードパスから選択を行うときには、なぜその判断がなされたのか、そしてその結果どのような挙動になったのかの両方をログに残すことを検討しましょう。 こうしたログがあると、2人のユーザーがアプリケーションを異なる形で体験した理由を理解しやすくなり、特定のコホートだけに影響するバグを再現しやすくなります。 機能やアルゴリズムが期待どおりに動作しているか 機能が複数のステップを実行する場合、ログが役立ちます。途中の結果を記録しておくことで、処理がどこで、なぜ破綻しているのかを把握できます。 実際の例を挙げましょう。私のサイト allaboard.dev では、ユーザーが外部サービスからクライミングのログブックをインポートできます。インポート処理の結果をログに残すことで、元データが正しくパースされていることを確認でき、どこで失敗しているか（そもそも失敗しているか）を特定できます。 監査・アクセスイベント（作成・更新・削除・アクセス・権限） 監査ログは、「これを変更したのは誰か」「それはいつ起きたのか」「そのアクションは想定されたものだったか」といった問いに答える助けになります。 この種のログは、サポート案件の根本原因を突き止めるのに大いに役立ちます。 たとえば、あるユーザーから「うちのチームの週次ダッシュボードが、いったいどこに消えたんだ？」という問い合わせが来たとします。アプリケーションが変更を伴う操作（作成・削除・更新）をログに残しているおかげで、数日前に同じチームの別のメンバーが誤ってそのダッシュボードを削除していたことが分かります。あなたはダッシュボードを復元し、何が起きたのかをユーザーに正確に伝え、そしてアプリケーションが勝手に何かを削除しているわけではないという安心感を得られます。 アクセスや権限をログに残すことは、HIPAA のような一部の標準では要件になっていることもあります。 注: 監査ログは、コンプライアンス要件を満たすための一部分にすぎません。Sentry が提供するプライバシーとセキュリティの制御については、Sentry and Your Data をご覧ください。複雑なコンプライアンスやプライバシーの要件がある場合は、ぜひご相談ください。 エラーや失敗の周辺コンテキスト 例外については、ログ行を追加するよりも、Sentry の Capture Error 機能を使う方がよい場合が多くあります。そうすることで、Issue Grouping、トリアージのワークフロー、Autofix、その他 Issue に焦点を当てた機能の恩恵を受けられます。
- [Apple のアップデートによる不具合 ─ ユーザーより先に気づくための仕組み](https://ichizoku.io/sentry/apple-update-breaks-app-2/) - Article by: Dan Mindru , Oleh Stasula（読了時間：9分） 本記事はフロントエンド開発者兼デザイナーであり、Morning Maker Show の共同ホストも務める Dan Mindru によるゲスト投稿です。Dan は現在、PageUI、Clobbr、CronTool をはじめとする複数のアプリケーションを開発しています。 リリースのたびに、綱渡りをしているようなものです。アプリは軽量で安定していなければならず、高いパフォーマンスも維持しなければなりません。その一方で、いつ予告なく変更されるか分からないAPIにも依存しています。160万ダウンロードを超えた今、私たちには品質を維持する責任があります。小さなチームでありながら、App Storeで4.7という評価を保ち続けられていることを誇りに思っています。では、それをどう実現しているのでしょうか。 答えはシンプルです。Sentryを使って築いたセーフティネットです。 本記事では、ユーザーが気付く前にクラッシュを修正する方法から、ビルドの問題を早期に検出する方法、さらにスタックトレースだけでは分からないユーザーの状況を把握する方法まで、私たちがSentryをどのように活用しているのかをご紹介します。 前提を整理する 今回取り上げるアプリは Usage という、iPhone・iPad・Mac で動作するシステムアクティビティモニターです。デバイスがCPU・メモリ・ネットワーク・ディスク・バッテリー・グラフィックスといったリソースをどのように使っているかを追跡します。これに加えて豊富な履歴データが得られることから、自分のデバイスを細かく把握したいパワーユーザーに人気があります。 これには、いくつもの難しさがあります。 Usageの役割はデバイスの動作を監視しながら、自らがその負荷にならないことです。この一見単純な要件が、少し変わったエンジニアリング上の制約を生みます。機能を追加するたび、依存関係を増やすたび、タイマーを1つスケジュールするたびに、その処理はユーザーに提供したい価値そのものとリソースを奪い合うことになります。自分自身のチャートに表示されてしまうシステムモニターなど、誰も望みません。 しかも、それはまだ序章にすぎません。足場そのものも安定していないのです。必要なデータの一部は、Appleが公開された代替手段を提供していないため、ドキュメント化されていないAPIに頼らざるを得ません。つまり、OSのアップデートによってデータ構造が予告なく変わり、どのデバイスでも、どのタイミングでも動作しなくなる可能性があります。非推奨になるという通知が届くわけでもありません。そのため、常に注意を払い続ける必要があります。 さらに、Usageは単一のプロセスではありません。メインアプリ、メニューバーアプリ、バックグラウンドサービス、そしてウィジェットが協調して動作する構成になっています。それぞれが独自のライフサイクルを持ち、障害もそれぞれ異なる形で発生します。そこで、各コンポーネントを個別のSentryプロジェクトとして構成し、それらを1つのワークスペースにまとめています。こうすることで、クラッシュやエラーは発生したプロセスに正確にひも付けられたまま、システム全体の健全性を一か所で把握できます。 こうした環境で、アプリ全体を軽快かつ高いパフォーマンスのまま維持するのは簡単ではありません。そのため私たちは、Sentryが提供するさまざまなツールを活用しています。 Crash Monitoring — あらゆる機能の土台となる基盤です。 Error Monitoring — OSアップデートによって依存しているデータ構造が変わることで起きるような、静かな失敗を検出します。 Size Analysis — ビルドごとの差分を追跡し、問題のあるリリースを見逃さないようにします。 Metrics — 最適化の取り組みが実際に成果を上げているかを測定し、検証します。 User Feedback — ユーザーがアプリ内から直接フィードバックを送れる窓口です。 それぞれをどのように使っているか、順に見ていきましょう。 Crash Monitoring
- [eval に下せない判断のために、エージェントのトレースを読む](https://ichizoku.io/sentry/spot-checking-ai-agents/) - Article by: Sergiy Dybskiy（読了時間：7分） ユニットテストを書くことにわくわくしていた（あるいは、キャリアの段階や勤め先によっては憂鬱だった）頃を覚えているでしょうか。あるいは、ユーザーが遭遇するユースケースをすべて網羅していると確信していた E2E テストや統合テストで、細部に汗を流していた頃を。 最近では、多くの UI が 1 つの入力フィールドと、UI と同じ価値を届けると約束するエージェントへと、少しずつ置き換わりつつあります。しかも「Jarvis」のようなエレガントさと駄洒落っぽさをまとって。 私たちは SOUL.md を練り、MEMORY.md を練り、システムプロンプトを練ります。ユーザーが実際にエージェントとやり取りする方法とは違うと分かっているプロンプトで eval を組み立て、それでも分かっているふりをします。しきい値を設定し、確信度スコアが満足のいく値で返ってくれば、承認してデプロイする。これで仕事は完了ですよね？ いえ、そうとも限りません。 Sentry は今週 AI Engineer World's Fair に参加しており、私は参加者が自分の予定を組み立てられるよう、エージェント付きの小さなスケジュールビルダーを作ることにしました。（スピーカー、トーク、トラックのデータ、さらには embedding まで提供してくれた Swyx に感謝します。） ある程度スケールさせたかったのですが、AI SDK と Vercel の AI Gateway のおかげで、匿名の訪問者にはオープンウェイトで非常に安価なモデルを、サインアップしたユーザーにはより強力な SOTA 級のモデルを使うようエージェントを設定するのは、かなり簡単でした。 ツール呼び出しと優れたシステムプロンプトがあれば、小さくても賢いモデルがハルシネーションを起こすはずがない、ですよね？？ 「有名な登壇者は？」 このアシスタントにはルーターがあり、各質問を読んで「info」パスと「search」パスのどちらかに振り分けます。 私の登壇者に関する質問は info パスへ送られました。このパスが持つデータツールは getTracks ただ 1
- [シグナル：自己修復するソフトウェアの鍵](https://ichizoku.io/sentry/self-healing-software/) - Article by: Milin Desai（読了時間：7分） いま、この業界の歴史上かつてないほど大量のコードが書かれています。1 年分のソフトウェアが 1 か月で生み出されるようになり、しかもその大半はもう人間が書いたものではありません。GitHub COO の Kyle Daigle は先日、こう述べています。 2025年のコミット数は10億件でした。現在は週2億7,500万件のペースで増えており、このまま線形成長が続くとすれば、今年は140億件に達する計算です（もっとも、線形成長のままにとどまるとは考えにくいですが）。 Anthropic、Cursor、OpenAI のコーディングエージェントは、スタックトレースを読み、絡み合ったコードを追い、人間が該当ファイルを見つけるより速く実際に機能する修正を書き上げます。この「速さ」こそ、いま誰もが語っている物語です。しかし、それ以上に重要なのは、コードがリリースされた後に何が起きるかです。 コードの量が増え、リリースが速くなるほど、実際のユーザーのもとへ届く不具合も増えていきます。そして、壊れたソフトウェアは技術的な問題であるだけでなく、ビジネス上の成果を左右する問題でもあります。顧客は離れ、解約し、その理由を周囲に語ります。Sentryは20万の組織にわたり、年間594兆件のイベントを処理しています。これこそが、自己修復を支える、他では得られないコンテキストです。つまり、ソフトウェアが実際に壊れた、その瞬間の記録です。ソフトウェアが現実世界と出会うことで生まれる、生のシグナルなのです。 だからこそ、いまソフトウェアは、これまで越えたことのない一線を越えつつあります。本番環境で、自らを修復し始めているのです。エラーを検知して人間のトリアージへ回すだけでも、修正案を提示して作業を人間に委ねるだけでもありません。自ら壊れていることに気づき、その理由を理解し、修正を書きます。もちろん、すべてが自動化されているわけでも、完全に実現しているわけでもありません。単純で原因の明らかな障害は自動的に解消される一方で、アーキテクチャ上の判断や複雑なインシデントは、依然としてエンジニアが担います。そして、その境界線は毎月動いています。この業界の歴史を通じて、信頼性は人間が担うものでした。それがいま、ソフトウェア自身の性質へと変わりつつあります。 業界はこれを自己修復するソフトウェア（self-healing software）と呼びます。もはや仮説ではありません。Sentry 社内でも、私たちが協働するチームの間でも、本番環境での実践は日ごとに現実味を増しています。これは、その意味を理解しているチームとそうでないチームとをはっきりと分ける転換点です。 何が必要か ここに到達するには 3 つの要素が必要でした。買うもの、自分で作るもの、そしてもう 1 つは自ら勝ち取らなければならないもの。実はすべてがこの 3 つ目に懸かっています。 Agent（エージェント） — モデルは急速に優秀になり、いまや基本的に「買う」ものになりました。ただしそれ単体では十分ではありません。速く何かを成し遂げることは、それが正しく、あるいは最善のやり方で成されたことを意味しないからです。モデルが正解にたどり着くのは、適切なコンテキストを与えられたときだけです。そして、エージェントの足を引っ張っているのがモデル自身であることは、めったにありません。 Harness（ハーネス） — 診断された修正をマージまで運ぶための配管であり、エディタ、CI、Slack、そして開発者自身のエージェントといった、開発者がすでにいる場所に届けるための仕組みです。これを構築するのは本物のエンジニアリングです。最も難しいのは修正を書くことではなく、それを検証することです。コードがコンパイルを通りテストが通ったことではなく、ユーザーが実際に踏んだ障害が消えたことを確かめなければなりません。そして、指し示すべき「真実」がなければ、そのどれもが機能しません。 Signal（シグナル） — ソフトウェアが自らを修復するには、まず自分が壊れていることを知らなければなりません。理論の上ではなく、現実世界で、です。あらゆるテストを通過したコードが、一晩で更新されたブラウザでは崩れ、広告ブロッカーがあなたのドメインを遮断した環境では動かず、一度もテストしていない端末で失敗する。その破綻はコードの中にはありません。あなたのリポジトリを見つめるだけのモデルには、それを見つけることはできません。そこには存在しないからです。それは、あなたが作ったものと、ユーザーが実際に体験しているものとの間にあります。エージェントは直感ではなく、シグナルに基づいて動きます。適切なコンテキストがなければ、推測に頼るしかありません。修正を試し、失敗し、また試す。本来なら避けられたはずの試行に、時間と費用を費やしてしまいます。一方、十分なシグナルがあれば、エージェントは賭けをやめ、何が、誰に対して、どのリリースから壊れたのかという実際の診断に基づいて行動します。 本当に希少なのはシグナルです。知性は買うことができ、ハーネスは作れます。しかしシグナルだけは、現実世界で本当にソフトウェアが壊れた、その瞬間からしか得られません。それこそがモデルを有用にし、ハーネスを現実に即したものにします。そしてこれこそ、Sentryが10年以上かけて築いてきたものです。 実際にどう動いているのか これは予測ではありません。ご存じの 3 社が、すでにこのループを回しています。 Cursor は、いまや多くのエンジニアが一日中開きっぱなしにしている AIエディタを作っています。それだけ多くのプロセスと、それだけ長いセッションをまたいでデスクトップクライアントを安定させるのは難しく、壊れるときは本番環境で壊れます。そこで Cursor のクライアントインフラチームは、Sentry のクラッシュデータの上に日次の自動化を構築しました。Sentry からシグナルを取り出してエージェントに渡し、どの機能が壊れたのか、そしてスタックトレースが本当に修正可能な根本原因を指しているのか、それともたまたま近くで動いていただけのコードなのかを問います。エージェントの確信度が十分に高ければ、第2のエージェントを呼び出して修正案を作成させます。自動マージは一切ありません。すべての PR
- [【SeerがSeerを修正】Seerがバグの場所を示し、障害の修復に役立った方法](https://ichizoku.io/sentry/seer-fixes-seer-debugging-agent/) - 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を追加することでした。これをデプロイしてから数分以内に、失敗率はベースラインに戻りました。 コードの問題
- [【Skimmer】タブ追加ゼロでリリースを65%高速化](https://ichizoku.io/sentry/customers-skimmer/) - Skimmer はプールサービス業界をリードする業務・物流管理プラットフォームです。スケジューリングやルーティングから請求までを通して現場チームの動きを支え、ソフトウェアが仕事の妨げにならないようにします。 舞台裏では、分散された .NET アーキテクチャが毎週木曜日のリリースを支えています。Web は React、モバイルは .NET MAUI、さらにデプロイ可能な 24 以上のマイクロサービスで構成されています。約24名のスリムで実践的なエンジニアチームで、前年比 40〜50% の成長を続ける Skimmer にとって、見逃されたバグや修正の遅れは致命的です。特に非同期でキュー中心のフローではなおさらでした。 彼らが必要としていたのは「何が起きた？」をクリックひとつで「なぜ起きたのか」「どこで起きたのか」へと変えられるツールでした。 Skimmer が向き合っているのは、ユーザーが「動かなかった」などと書き込む現実の現場です。しかも処理の多くは、キューやバックグラウンドワーカーを介した非同期ジョブとして実行されます。そのため障害の原因は、エラーが表面化した場所やタイミングとは別のサービス、別の時点に存在することがあります。 「サーバーのシグナルは一箇所、ログは別の場所、クライアント／モバイルのクラッシュはさらに別のところ。エラーを投げない問題は何時間もパターン探しに化けることがありました。」— Gary Osteen（品質・オペレーション担当ディレクター） 調子の良い日なら、彼らはエラーの位置を三角測量のように絞り込めました。けれど普段はサポートチケットの会社IDを手がかりに、ログ、バックエンドのメトリクス、クライアントのクラッシュレポートをつなぎ合わせる作業に追われていました。しかも報告者が本当にそのエラーに遭遇した本人であるという前提に賭けるしかありませんでした。 一方で事業は加速度的に成長していました（前年比 40〜50%）。しかしチーム規模はそれに合わせて倍増していません。リーダー陣は現場主義を保ちつつ、「何を変えるべきか」は明確に把握していました。必要だったのはダッシュボードを増やすことではなく、調査の起点を一本化できる開発者が実際に使う場所にある、情報の参照先を一本化できる「唯一の参照元」でした。 課題起点のコンテキスト vs 複雑なセットアップと限られた MAUI 対応 Skimmer はいわゆる定番の APM ツール群を Sentry と比較しました。各ツールを .NET Framework と .NET（Core）のバックエンド両方に加え、Web の React、モバイルの .NET MAUI にも組み込みました。 従来型APMツールで起きたこと 基本を超えるとインストゥルメンテーションが破綻した「シンプルな例を超えた途端、セットアップが面倒になりました。.NET Framework 4.8 と .NET（Core）でドキュメントの整合性が取れていない上、MAUI 対応は限定的、あるいはロードマップにも載っていませんでした。」
- [【Size Analysis（Early Access）】モバイルアプリサイズを可視化・最適化](https://ichizoku.io/sentry/monitor-reduce-mobile-app-size-analysis-early-access/) - Article by: Max Topolsky, Nico Hinderling これは「man.jpg」です。 なぜか、トヨタの iOS アプリにはこのファイルが含まれており、そのサイズは無視できない 14.6MB でした。都合よく、発覚から数か月後に man.jpg は削除されましたが。 本記事は、man.jpg をアプリに含めるべきだったかどうか、あるいは man.jpg をどれだけ小さくできたか（MB）について論じるものではありません。本記事の主題は、今日から Sentry の Size Analysis を使えば、すべての開発者がアプリサイズの問題を簡単に検出し、修正できるということ（さらに、人気のオープンソースアプリのサイズを 30% 削減する方法 😉）です。 Size Analysis（現在 Early Access）紹介 Size Analysis は、モバイルアプリのサイズを監視し、削減するための機能です。 Sentry が Emerge Tools を買収したことを覚えている方もいるかもしれません。Size Analysis は Emerge の最初の製品であり、Spotify、Square、Tinder などのチームがアプリをできる限り軽量化してリリースするために活用していました。 そして今、Sentry アカウントを持っているすべての開発者が、同じツールを利用できるようになりました。 Size Analysis 使い方 Size Analysis
- [LLM パフォーマンスのコア KPI（と追跡方法）](https://ichizoku.io/sentry/core-kpis-llm-performance-how-to-track-metrics/) - Article by: Sergiy Dybskiy 本ブログの内容 「良い」LLM KPIとは？ 抑えるべき LLM パフォーマンスの中核指標10選 Sentry の AI オブザーバビリティを始める 他にも追跡しておくべき LLM メトリクス 次のステップ LLM を制御下に置くために 数か月前、トロントのオープンデータポータル向けに MCP サーバーを構築し、エージェントがユーザーの質問に関連するデータセットを取得できるようにしました。最初のバージョンを急いで作り、コードをざっと確認したところ、問題なさそうに見えたので、Claude に「トロント市における交通関連のデータソースにはどんなものがありますか？」と尋ねました。 ツール呼び出しは動作し、関連する結果も得られました。ところが、すぐにエラーが出ました。 「会話が長すぎます。新しい会話を開始してください。」質問を一度しただけだったのに。 原因は、最初の呼び出しで API から返された巨大な JSON ペイロードでした。それがコンテキストウィンドウを埋め尽くしてしまったのです。見ればすぐに解決できる簡単な問題でした。 しかし、モニタリングがない AI アプリには他にも様々な落とし穴があります。ツールのタイムアウトが黙って発生する、トークン使用量が急増する無限ループ、遅い検索、JSON フォーマットを壊すモデルのダウングレード、あるいは単純な500エラーなどです。 こうした場面があるからこそ、私は重要な問題をすぐに表面化させるために監視しているいくつかの主要な指標をまとめています。 「良い」LLM KPIとは？ Rahul が言うように、「プロンプトを入力してレスポンスが返ってくる。それはオブザーバビリティではありません。ただの“雰囲気”です。」 良いKPIとは生のカウンター値ではなく、プロダクトの成果に結びついた方向性のシグナルです。特にAIエージェントのパフォーマンス指標において重要です。 3つの視点で考えてみましょう。 信頼性：正しく動作しているか コスト効率：妥当な範囲でコストを抑えられているか ユーザー体験：速くてレスポンシブに感じられるか 以下のメトリクスはこれらの視点に直接対応しており、あなたも経験したことがあるであろう実際の障害とも結びついています。例えば、ループによるトークンスパイク、不安定なベクターデータベースがレスポンスを遅くする問題、あるいは静かに行われたモデル変更で出力品質が大幅に低下するケースなどです。 また、これらは「LLM 評価指標（LLM evaluation metrics）」「LLM
- [【Sentry Flutter SDK 9.0】Logs・Session Reply・Feature Flags などをご紹介](https://ichizoku.io/sentry/introducing-sentrys-flutter-sdk-9-0/) - Article by: Gino Buenaflor, Steve Zegalia (本記事は2025/6/16に公開された記事です） 「Null check operator used on a null value（null 値に対して null チェック演算子が使われました）」とだけ書かれたエラーレポートを手がかりに Flutter アプリをデバッグしたことがあるなら、すでにご存じのとおり、コンテキストがすべてです。ですが、ネイティブコードや Dart、非同期スタックトレース、プラットフォームチャネルを同時に扱っていると、そのコンテキストを得るのは簡単ではありません。 そこで Flutter SDK v9 では、何が起きているのかをより可視化し、改善に役立つインサイトを得られる機能を導入しました。 新機能は次のとおりです。 モバイル向け Session Replay の一般提供（GA）対応：クラッシュ前にユーザーが何を見て（何を操作して）いたかを再現して確認できます。 Feature Flags（フィーチャーフラグ）対応：バグ発生時にどのフラグが有効だったかを把握できます。 Logs（現在 Open Beta）対応：ログをクラッシュやパフォーマンス問題と相関付けて確認できます。 ネイティブ JS エラー対応（Flutter Web）：JS 連携（interop）を利用する Flutter Web アプリの可視性が向上します。 Release Health（Flutter Web）対応：リリースの普及状況、安定性、クラッシュフリーセッションについてより深いインサイトを得られます。 Traces と Errors の連携強化：アプリケーションコード内の特定の span と問題を相関付けて分析できます。
- [【View Renderer V2】iOS Session Replay パフォーマンスを向上](https://ichizoku.io/sentry/boosting-session-replay-performance-on-ios-with-view-renderer-v2/) - Article by: Phil Niedertscheider モバイル向け Session Replay を一般提供（GA）にした後、採用は急速に進み、より多くのフィードバックが私たちのもとに届くようになりました。 あまり良くない話ですが、Apple SDK のユーザーから、古い iOS デバイスでの Session Replay のパフォーマンスオーバーヘッドにより、アプリが使い物にならなくなったという報告がありました。 そこで私たちは原因を突き止めるための旅に出て、ベンチマークで 4〜5 倍良いパフォーマンスを得られる解決策を見つけました。モバイルの Session Replay の内部で何が起きているのかを理解するために、技術的な詳細に入る前に、まずモバイルの画面録画がどのように動作するのかを見ていきましょう。 フレームレートをひと言で言うと 画面録画とは、フレームと呼ばれる高速で表示される多数の画像から成る動画です。人間の目は 1 秒あたり約 60 フレーム（フレームレート）を処理でき、これはヘルツ（1 Hz = 1 秒あたり 1 単位）で測定され、動いている映像の錯覚を生み出します。フレームレートは用途によって異なり、映画では 24 Hz、ゲーミング向けの PC ディスプレイでは 144 Hz まであります。 より高いフレームレートはより滑らかな動画を生みますが、重大なトレードオフを伴います。 同じ動画の長さでも、ストレージとネットワーク帯域の消費が増える 1 秒あたりに処理すべきフレームが増え、性能を維持するにはより強力なハードウェアが必要になる フレームレートを最小まで下げると、録画はストップモーション動画のように見えます。このスタイルのとても良い例は、この YouTube 動画で見ることができます。フレームは単に連続した写真にすぎませんが、それでも動いている写真のように感じられる、つまり動画です。 これは本質的に、私たちがモバイルの Session
- [【Sentry MCP ＆ Cursor】デバッグをもっとスマートに](https://ichizoku.io/sentry/smarter-debugging-sentry-mcp-cursor/) - Article by: Cody De Arkland 本番の障害を Cursor でデバッグしていますか？ おそらくワークフローはこうです。Alt-Tab で Sentry に切り替え、エラーの詳細をコピーし、IDE に戻って Cursor に貼り付ける。コンテクストスイッチを 3 回もした頃にはフローは途切れ、実際の本番環境やコードベースを理解しているとは言えない… 一般的な提案を眺めることになります。 Cursor と LLM は良いコードを書けますが、本番のエラー、ユーザーの操作フロー、影響指標、デプロイ履歴、さらにはアーキテクチャのことも知りません。そのコンテクストがあるかどうかで、「パターンマッチングと一般的なエラーハンドリングを提案します」と「この API エンドポイントは、隣接するサービスの 1 つにデプロイされた昨日のコミット以降、ユーザーの 47% で失敗しています」という差が生まれます。 Sentry MCP Server を使えば、Cursor は Sentry が持つ、本番（および開発）アプリケーションのパフォーマンス周辺のコンテクストに直接アクセスできます。エラーメッセージやログをコピー＆ペーストしたり、分散トレーシングの構成やスタックトレースをチャットで説明しようとしたりする必要はありません。MCP は実際の問題を調査し、その影響を理解し、実際の本番コンテクストにもとづいて修正案を提案できます。 ただし、アプリケーションのアーキテクチャの複数領域にまたがるような複雑でシステム全体に及ぶ問題に直面したとき、「AI Debugger」として本領を発揮するのは Sentry の Seer です。Cursor 単体でもピンポイントな修正は得意ですが、MCP Server と併用する場合でも、問い合わせたアプリ性能の各要素を手作業で引き出して自分でつなぎ合わせる必要があります。しかも、MCP の結果が一貫しないこともあります。MCP はまだ完璧には程遠いのです。Seer はプロジェクト全体を横断して、自動的にパターンを見つけ、Sentry のコンテクストに対して深い調査を行い、根本原因の特定と実際に使える解決策の構築に取り組みます。 幸い、私たちは Sentry MCP
- [AIシステムを本番で監視するために本当に必要なこと](https://ichizoku.io/sentry/what-you-actually-need-to-monitor-ai-systems-in-production/) - Article by: Rahul Chhabria 最新の AI エージェントをプロダクトに組み込み、リリースして、あとは寝るだけ。ところが起きてみると、空文字を返していたり、昨日より 5 秒も遅くなっていたり、あるいは「完璧な JSON」の体裁で堂々と嘘を出していたりしています。 当然、ログを確認します。 プロンプトはある。レスポンスもある。……でも、肝心の手がかりが何もない。 驚きますよね。プロンプト入力とレスポンス出力だけでは、オブザーバビリティとは言えません。あれは雰囲気です。 「LLM のオブザーバビリティ」は今かなり話題です。ただ、実態は「要らないチャート」と「そのうち見なくなるダッシュボード」が増えるだけ、というケースも少なくありません。もしあなたが実際に、チャットボットや社内エージェント、検索・取得アプリなど、LLM を組み込んだプロダクトを作って運用しているなら必要なのは観測です。しかも、肝心なところに差し掛かった瞬間に途切れるような観測ではなく、原因まで辿れる観測です。 何を追うべきか。いつ追うべきか。なぜそれが重要なのか。中身のない補完にうっかり 5,000 ドル払う前に、順番に整理していきましょう。 ステージ 1：本番前 （別名：「プロンプト墓場」） 今、プロトタイプを作っている段階だとします。ノートブック、ベクターストア、OpenAI API キー、そして夢もある。必要なのはダッシュボードではなく、壊れたプロンプトを必死に救い出すためのログです。 何をログに残すべきか この段階でデバッグしているのは、ユーザーというより自分自身です。なので、以下をログに残しましょう。 プロンプト全文とレスポンス全文 モデル名、temperature、function schema のバージョン トークン使用量とレイテンシ プロンプトのバージョンを特定できる情報（何でもいいので） プロンプトのバージョン管理に気の利いた仕組みは要りません。コミットハッシュで十分です。付箋でもいい。とにかく、何が変わったのか忘れる前に書き留めておきましょう。 当面はこれで済むツール類 JSON ファイル Postgres のテーブル 構造化ログを使った Sentry Traceloop（そういうのが好きなら） ここでの唯一の目的は「変な挙動」を再現できるようにすることです。何かが爆発しても、5 分以内に説明できるなら勝ちです。 ステージ 2：本番（Production） （いまや「誰か別の人」の問題）
- [堅牢な時系列モニタリング　Matrix Profile と Prophet を用いた異常検知](https://ichizoku.io/sentry/time-series-monitoring-anomaly-detection-matrix-profile-prophet/) - Article by: Ram Senthamarai, Aayush Seth 異常検知は鏡だらけの家で探偵をしているようなものです。何かがおかしいのは分かるけれど、見えているのが本当の問題なのか、それとも奇妙な反射にすぎないのか、いつも確信が持てません。 本番環境のシステムを監視するのは、絶えず形を変える干し草の山の中から動き回る針を探すように感じることがよくあります。Sentry では、お客様が従来のしきい値ベースや割合ベースのアラートを超えられるようにすることを目標にし、システム内の微妙で複雑な異常をほぼリアルタイムで検知できるよう支援することを目指しました。 本記事では、当社の AI/ML チームが Matrix Profile と Meta の Prophet を用いて、時系列の異常検知システムを開発した方法を詳しく説明します。直面した課題を取り上げ、このハイブリッドなアプローチによって、より信頼性が高く、よりインテリジェントなアラートを構築できた理由を解説します。 問題：ノイズの多いメトリクス、微妙な障害 システムメトリクスは本質的にノイズが多いものです。しかし、適切なタイミングで適切な異常を特定できるかどうかで、結果は大きく変わります。たとえば、素早い修正で済むのか、重大インシデントに発展するのか。とはいえ、自動の時系列異常検知（Time Series Anomaly Detection。以下 TSAD）は簡単な問題ではありません。 コンテクストがすべて：データのスパイクは異常かもしれませんし、週末セール、プロダクトローンチ、システムメンテナンスの影響にすぎない場合もあります。コンテクストがなければ、その違いは判別しにくくなります。 「正常」は常に変動する：パターンは時間とともに変化します。季節性、トレンド、そして突然のレジームシフト（状態の急変）によって、今日の「正常」が明日の「異常」になり得ます。 ノイズとシグナルのせめぎ合い：システムメトリクスのデータはノイズが多くなることがあります。特に大規模環境では、誤検知を連発せずに真の異常だけを検知するのは簡単ではありません。 万能解はない：各メトリクスの振る舞いは異なります。CPU 使用率、ユーザー登録数、取引量など、それぞれ特性が異なるため、状況に応じたアプローチが必要です。 ラベル付きデータがない：教師あり学習は、正解（グラウンドトゥルース）がない場合、難しくなります。多くの場合、何が異常だったのかは、実際に何かが壊れてから初めて分かります。 Sentry のスケール：何十万ものメトリクスを監視する Sentry のようなオブザーバビリティプラットフォームの規模で、この問題を解くことを想像してみてください。 要するに、自動 TSAD には、コンテクストを理解し、適応的で、精度が高く、しかもスケールすることが同時に求められます。 解決策：ハイブリッドアプローチ ARIMA、SARIMA、TimeGPT、Moirai、AutoFormer、ChatTS などさまざまなモデルで広範に実験した結果、私たちは Matrix Profile と Prophet を組み合わせたハイブリッド手法に落ち着きました。これらのモデルを組み合わせることで、時系列データにおける異常をより広い視野と、よりニュアンスのある形で理解できるようになります。 Matrix Profile：形状ベースの異常検知
- [【Sentry Seer】法務審査をクリアする方法　Seer をレビューする法務チーム向けガイド](https://ichizoku.io/sentry/how-sentrys-seer-ai-agent-passes-legal-review-a-guide-for-legal-teams/) - Article by: Virginia Badenhope （本記事は法律の専門家が法律の専門家のために書いたものですが、法務担当者がいないまま Seer の利用を検討している方にとっても、安心材料になるはずです） 自社の法務部門が私たちと同じような状況にあるのであれば、事業側から「もっと多くの AI ツールを使いたい」というリクエストが次々と押し寄せてきているのではないでしょうか。開発チームは Cursor のようなコーディングエージェントを使いたがり、セキュリティチームは AI を活用した調査を導入し、セールスやマーケティングは通話内容のインサイトや競合調査に AI を活用しようとしています。私たちは各チームが試し、購入しようとしているツールに大きな変化が起きていることを目の当たりにしてきました。 サービスの主な機能自体は AI を前提としていない場合でも、いまやほとんどすべてのサービスが何らかの AI 機能を備えています。 ビジネス側も AI の利用には一定のリスクが伴うことは理解していますが、それでも「使わなければ取り残されてしまう」という強いプレッシャーを感じています。あなた自身も同じプレッシャーを感じつつ、自社のデータや知的財産はもちろん、顧客から預かっているデータや知的財産を守るという使命も負っています。 Sentry が Issue Scan や Issue Fix を含む自社の AI／ML 機能を支えるために開発してきた AI エージェントである Seer について法務レビューを依頼されているのであれば、本記事の目的は、Sentry の法務チームである私たちがサードパーティ製の AI ツールを評価する際に用いている基準を、Seer も同じように満たしていることを示すことにあります。 もし Seer の評価を依頼されたとしたら、私たちは承認します。理由は次のとおりです。 では、法務は実際のところ何を気にしているのか？ 私たちおよび顧客データと知的財産を保護しつつ、ビジネスの変化するニーズを引き続き支えていくために、Sentry では AI ツールの利用について次の要件に合意しています。
- [AIにもっとデバッグをうまくさせるには？重要なのは「コンテキスト」](https://ichizoku.io/sentry/want-ai-to-be-better-at-debugging-its-all-about-context/) - Article by: Milin Desai AI を活用したコード生成ツールによって、これまでになく大量のコードが次々とリリースされています。いまは開発者にとっての黄金時代と言っていいでしょう。 しかし、ひとつ重要な事実があります。ソフトウェアは依然として本番環境で壊れてしまいます。Microsoft が最近行った調査によると、AI モデルはソフトウェアのデバッグを苦手としていることがわかりました。その理由は、多くのコード生成ツールで、優れた開発者なら誰もが頼りにしているたった1つのもの、「コンテキスト」が欠けているからです。 何かをデバッグしようとするなら、コンテキストが必要です。AI ツールがあっても、この前提は変わりません。AI は学習データを超えて、実際のエラーやトレースデータ、ブレッドクラム、スタックトレース、コードベース全体、コミット履歴などにアクセスできる必要があります。 AI があるかどうかにかかわらず、デバッグにはコンテキストが欠かせないのです。 AI 時代のデバッグに不可欠なのはコンテキスト Sentry はこの10年あまりの間に、13万以上の組織がソフトウェアの不具合をすばやくデバッグできるよう支援してきました。Sentry 独自のコンテキストを提供することで、エンジニアリングチームが本番環境でのデバッグを従来の 10 倍の速さで行うことができるようにしています。 何かが壊れたとき、開発者は次のようなことを知る必要があります。 問題はいつ発生し始めたのか。 壊れる直前に「何が変わった」のか。 影響を受けているのは 1 人のユーザーか、それとも多数なのか。 どのプラットフォーム／デバイス／リリースに影響しているのか。 問題の起点はどこか。自分のコードなのか、それとも依存している外部要因なのか。 Sentry はこれらの問いに答えるだけでなく、次の情報もあわせて提示します。 どの関数やコード片が失敗しているのかを正確に把握するためのスタックトレース エラーの前後で、アプリケーションがエンドツーエンドでどう振る舞っているかを確認するためのトレースとログ フロントエンドでデバッグしている問題に、バックエンドエラーが関係しているかどうかを確認できるようなトレースでつながった関連 Issue 例外の前後でどのようなアクションが行われたかを把握するための Sentry のブレッドクラム 各関数がどのようなパフォーマンス特性を示しているかをよりよく理解するためのプロファイリングデータ こうしたコンテキストのすべてが、長年にわたって Sentry を開発者にとって非常に有用な存在にしてきました。そしてこれは、障害が発生したときに本当に問題を修正するために、他の AI ツールにも必要でありながら、まだ備わっていないまさにそのコンテキストでもあるのです。 Seer：Sentry の
- [そのままで動くLaravel　パフォーマンスモニタリングも同様](https://ichizoku.io/sentry/laravel-just-works-now-your-performance-monitoring-does-too/) - Article by: Will McMullen Laravel アプリを初めて立ち上げたときのことを覚えていますか？ルーティング、認証、ORM、キューがすべてスムーズにつながり、ほとんど手間がかからなくなったはずです。これこそ、Laravel が「最初から生産的に感じられる」理由のひとつです。 しかし、アプリの動作が遅くなり始めたとき、Eloquent クエリが重くなる、ジョブがいつまでも終わらない、キャッシュミスが増えていく。その原因を見つけるのは簡単ではありません。Laravel には多くのツールが備わっていますが、それらをつなぎ合わせて全体像を把握するのは、これまで開発者の手に委ねられていました。 Sentry の新機能「Laravel Insights」を使えば、アプリ内部で何が起きているのかを、より明確に把握できます。エラー、遅いジョブ、データベースクエリ、キャッシュの利用状況、ルートごとのパフォーマンスなどを可視化し、既に追跡している課題と関連づけて表示します。さらに、それらがユーザー体験に実際どのような影響を与えているのかも確認できます。 すべてがつながっています。特定のルートから発生した遅いジョブをたどり、その原因となったクエリを特定し、キャッシュが改善に寄与したのか、それとも逆効果だったのかまで把握できるのです。 Laravel を先回りして最適化 これは新しい製品でも、新しいタブでもありません。Laravel アプリで基本的な Sentry のインストルメンテーション（エラーおよびトレーシング）が設定されていれば、Insights → Backend の中で Laravel プロジェクトを開くだけで次の情報を確認できます。 Recommended Issues：本番環境で新たに発生した、または深刻化している課題を表示 Requests & Duration：リリースごとの負荷の変化やアプリのパフォーマンスを追跡し、リグレッションが発生していないか確認 Jobs：バックエンドジョブの実行時間や失敗率の傾向を監視し、SendWelcomeEmail::dispatch($user); が常に時間通りに動作しているか確認 Queries：コストの高いデータベース呼び出しを特定し、トランザクションを最適化 Caches：キャッシュミスが多発している箇所を特定し、無効化の問題を修正 Routes：リクエスト数、ユーザー数、総処理時間、pXX 指標ごとにソートし、早期にパフォーマンス低下を検知 一人で開発している場合でも、スタートアップのスケールアップ段階にあっても、これらのインサイトによりアプリの挙動を簡単に把握でき、ユーザーが気づく前に問題を修正できるようになります。 さらに深く掘り下げ、アラートを作成 たとえばキャッシュミスの急増、データベース時間を食い尽くす暴走クエリ、異常に滞留しているキューなど、もし何かおかしな兆候を見つけたら、クリックひとつで詳細を掘り下げることができます。 Laravel Insights の各ウィジェットには 「Open in Explore」（Exploreで開く）ボタンがあり、ドロップダウンをクリックすると Sentry のクエリビルダーに直接移動できます。そこで次のようなことが可能です。 特定のサービス、ルート、ユーザー、または環境に絞り込んでクエリをカスタマイズ ブラウザの種類、ユーザーアカウントの状態、リクエスト元など、Sentry に送信している任意のタグ（デフォルト・カスタム問わず）でグループ化
- [【Emerge Tools】Sentryの一部に](https://ichizoku.io/sentry/emerge-tools-is-now-a-part-of-sentry/) - Article by: David Cramer 本日（2025/5/6）、Emerge Tools が Sentry に加わることを発表できることを大変嬉しく思います。 Emerge は、世界の主要ブランドから信頼される最高水準のモバイル向けツールを開発しています。同社チームのたゆまぬ 努力 によってモバイル ビルドを改善してきた取り組みを、皆さんもどこかで目にしたことがあるかもしれません。Sentry では以前からその姿勢を高く評価してきました。 そして実際に Emerge の共同創業者である Josh と Noah に初めて会ったとき、私たちは同じ世界観を共有していることを感じ、すぐに意気投合しました。 モバイル分野は、私たちの業界において常に複雑な存在でした。重要であることは誰もが認める一方で、しばしば軽視されてきた領域でもあります。これまでモバイル特化型のツールが数多く登場してきましたが、モバイルを二の次とする大手ベンダーに取って代わられることも少なくありませんでした。 Sentry では、モバイルアプリケーションをビジネスの重要な延長線上にあるものと捉えています。それは新しい顧客と最初に接する接点の一つであり、テクノロジースタックの他の要素と同等の注目と投資を受けるべき領域です。 市場のリーダーたちはこの重要性を理解していますが、多くの企業はいまだ追随段階にあります。OpenAI は、ChatGPT の体験が iPhone、Android、またはウェブ上のどこであっても快適な体験を提供することが、いかに重要かを深く理解しています。Spotify も同様に、顧客が持つあらゆるデバイス上で自社を存在させる必要があります。DoorDash や Tinder が今のクオリティを維持していなければ、Z 世代の生活はどうなっていたでしょうか。優れたモバイル体験は、私たちが毎日頼りにしているブランドにとって不可欠なものです。 現在の Sentry は、ユニバーサルかつ最高水準のクラッシュレポートおよびアプリケーションモニタリングで広く知られています。そこに Emerge Tools が加わることで、モバイルチームに次のような新たな機能を提供していきます。 アプリをより小さく軽くし、インストール率の向上とユーザー満足度の向上を実現 不要なコードを削除し、バグを減らすとともに、Sentry のコストについて CFO と議論する時間を削減 社内配布を効率的に管理し、残されたバグを顧客ではなく自社チームで発見 ビジュアルリグレッションテストを活用し、サインアップボタンが消えるような問題に再び悩まされることを防止 これはほんの始まりにすぎません。Emerge の専門知識と既存プロダクトが加わることで、皆さんがすでに愛用している機能をさらに強化し、本番監視の枠を超えたサポートを拡張していきます。 私たちはバグを捕まえることを仕事としていますが、本音を言えば、それを未然に防ぎたいのです。 今回の発表および今後の展開については、Emerge
- [【Flask × React】実装するチェックアウトフローの監視とデバッグ](https://ichizoku.io/sentry/monitoring-and-debugging-a-checkout-flow-in-flask-and-react/) - Article by: Will McMullen チェックアウトフローが壊れると、顧客は「最先端」のJSメタフレームワークが廃れるよりも早く離れていきます。幸い、Sentry を使えば、顧客のチェックアウトのようなクリティカルパスにオブザーバビリティを設定するのは簡単です。ここでは、私たちがどのようにインスツルメントし、監視し、大きな問題を最小限の労力で修正したのかを順を追って紹介します。 チェックアウトフローのインスツルメント まず、ユーザーがチェックアウトプロセスとどのようにやり取りしているかを正確に追跡したいと考えました。Sentry の Distributed Tracing を使って監視ダッシュボードを設定するのは簡単でした。フロントエンドとバックエンドのアプリケーション（今回の場合は app.py と App.tsx のトップレベルファイル）でトレーシングを有効化し、/api/ エンドポイントを tracePropagationTargets に追加して Distributed Tracing をセットアップするだけで完了です。 これで、Flask と React の両方にわたって、パフォーマンスメトリクス、エラー、トレーシングデータを取得できるようになりました。 ユーザージャーニーの監視 Sentry にデータが集まるようになると、eコマースストアフロントで最も重要な要素であるチェックアウトフローを監視するためのダッシュボードを立ち上げるのは非常に簡単でした。 ここに到達するために、私たちはいくつかの主要な属性で Span データ を拡張しました。これらは Sentry で Span Metrics として可視化・監視できます。誰かが Cart.jsx コンポーネントを使うたびに、Sentry SDK でのインスツルメンテーションによって「カートに追加されたアイテム数」をそのアクティブな Span に付与し、その数を追跡できるようにしました。 実際のところ、次のような形になります。 まず、Sentry.startSpan() でスパンを作成し、次に checkoutspan.setAttribute を使って items_at_checkout を属性として追加します。ここにデバッグやパターン分析のために顧客データなど他の有用な情報を付与することも簡単にできますが、ここではシンプルに留めることにしました。
- [【Sentry Japan】HonoConf 2025 & Vue Fes Japan 2025 参加レポート ー サーバーサイド・フロントエンド両コミュニティで見えた開発者のリアル](https://ichizoku.io/sentry/sentry-japan-sponsorship-honoconf-vuefes-2025-report-the-reality-of-developers-as-seen-from-both-the-server-side-and-front-end-communities/) - Article by: Naru (Sentry Japan / Ichizoku 株式会社) Sentry Japanは2025年10月、2つの重要な技術カンファレンスにスポンサー参加しました。10月18日に開催されたHonoConf 2025ではGoldスポンサーとして、そして10月25日のVue Fes Japan 2025ではBronzeスポンサーとして、日本のWeb開発コミュニティとの接点を深める機会となりました。 1週間で2つのカンファレンス、合計90名の新フォロワー獲得、そしてサーバーサイドとフロントエンド、両方の開発者から得られた貴重なフィードバック。今回の参加を通じて見えてきた、日本のWeb開発市場の実態をレポートします。 🚀 HonoConf 2025: 急成長する軽量Webフレームワークのコミュニティ イベント概要開催日: 2025年10月18日会場: オンライン・オフライン ハイブリッド開催スポンサーレベル: Gold Sponsor HonoConf 2025は、エッジコンピューティング時代に注目を集める軽量Webフレームワーク「Hono」の第2回カンファレンスでした。Cloudflare Workers、Deno、Bunなど、様々なランタイムで動作するHonoは、モダンなサーバーサイド開発の新潮流として急速に支持を拡大しています。 📊 アンケート結果: サーバーサイドエンジニアのエラートラッキング事情 Goldスポンサーとして、私たちは67名の参加者から詳細なフィードバックを得ることができました。 参加者プロフィール:アンケート回答者: 67名サーバーサイドエンジニア: 51名（76%） Sentry使用経験あり: 40名（60%） この数字が示すように、HonoConfはサーバーサイドエンジニアが圧倒的多数を占めるイベントでした。エッジコンピューティングとサーバーレスアーキテクチャへの関心の高さが、参加者層にも反映されています。 エラートラッキング・監視ツール使用状況 Sentry: 55%CloudWatch: 46%その他のツール サーバーサイド開発者の間では、Sentryの普及率が55%と、モバイル開発市場（DroidKaigiでの23%）と比較して倍以上の高い認知度を示しました。これは、バックエンド開発においてSentryが既に標準的な選択肢として認識されていることを物語っています。 最も重視される機能 リアルタイム検知・アラート:
- [【第2回 Sentry 日本語記事投稿キャンペーン】豪華景品多数！参加者全員にプレゼント🎁](https://ichizoku.io/sentry/japanese-sentry-post-campaign-2/) - ＼第2回「Sentry日本語記事投稿キャンペーン」／ ご好評頂いたキャンペーンの再開催が決定！ 今回は参加者全員にプレゼント贈呈が決定！ ＼ご参加お待ちしております／ ⭐️ Sentry に関する記事を書いて豪華景品を当てよう⭐️ キャンペーンのポイント 先着30名様限定！参加者全員に必ず当たる！ SHURE MV7+（高音質マイク）やShokz OpenComm2（大人気の骨伝導イヤホン）など、豪華景品を用意！ さらに、必ずもらえる参加賞はAmazonギフト券 1,000円〜10,000円 をランダムでプレゼント！ Sentryを使ったことがある方はもちろん、使ったことがない方にもチャンス！「Sentryをもっと便利に使うためのTipsや導入事例、活用方法を共有しましょう！」という企画！抽選でのプレゼントだけでなく、参加者全員プレゼントもあるのでぜひ気軽にご参加ください🚀 こんな人におすすめ Sentry を使い始められたばかりの方 既にご活用されていて、知見やアイデアをお持ちの方 Sentryを使っているが、新機能やカスタマイズ方法をキャッチアップしたい方 豪華景品ラインナップ ⭐️ カスタマイズが上手で賞 2名様 ⭐️ SHURE MV7+ ポッドキャストマイクロホン 新しいMV7+ポッドキャストマイクロホンは、カスタマイズ可能なLEDタッチパネルとさらに優れたDSP機能を搭載し、より高音質なオーディオでの配信が可能になります。 shure.com/ja-JP/products/microphones/mv7 ⭐️ 苦労したで賞 5名様 ⭐️ Anker MagGo Wireless Charging Station 折りたたみ式で軽量コンパクトな設計 旅行などの外出時の持ち運びにも便利です。 さらに、お好きな角度で充電しながらスマホ操作が可能です。 ankerjapan.com/products/b2557 Shokz OpenComm2 2025
- [分散システムのトラブルシューティングにトレース参照機能を備えた Sentry AI デバッガー](https://ichizoku.io/sentry/sentry-ai-debugger-autofix-superpower-traces/) - Article by: Rohan Agarwal デバッグは、すべての開発者にとって常に付きまとう課題であり、たとえAIがコードを書くようになったとしても、その負担が増す可能性さえあります。Sentry のようなツールは、長年にわたりエンジニアが問題を追跡し、デバッグを行う際に支援してきましたが、新たなAIツールを活用することで、こうしたプロセスをさらに迅速かつ容易にできる点が魅力です。 もちろん、Sentry から例外のスタックトレースをコピーして ChatGPT に貼り付けることも可能です。しかし、もし本当に賢いものが欲しいとしたら、どうでしょうか。AI が最善の仕事をするために、より多くのコンテキストを持ち、分散システムを深く理解し、本番環境でそれらをデバッグする能力を備えたものがあればどうでしょうか。 本記事では、私たちがどのようにして、トレーシングの力を活用して、Sentry の本番レベルの AI デバッグアシスタント「Seer」を構築したのかを説明します。 AI によるデバッグの欠点はどこにあるのか？ Seer とその Autofix 機能は、Sentry のIssues 詳細とコードベースとの緊密な統合を活用することで、問題の根本原因を突き止め、修正するための優れたツールとなっています。Autofix は開発者と協働しながら、問題の根本をより深く理解し、効果的な解決策を計画し、さらにはそれを修正するプルリクエストの下書きまで作成します。さらに、リグレッションを防ぐための単体テストも含まれます。これまでのところ、その裏側では主に Sentry のスタックトレースやパンくずリスト、そしてコードベース検索に依存して知見を得ていました。実際、Autofix はすでに数多くの開発者を助けており、さまざまなアプリケーションのバグを修正してきました。 Autofix 自身のバグさえもです。 しかし時には、Autofix が的を外してしまうこともありました。たとえば、フロントエンドから報告された「500 Internal Server Error」に対して Autofix を実行しても、バックエンドでの問題を特定することはできません。あるいは、2つのマイクロサービス間で認証の問題が発生した場合、Seer には実際に何が起きているのか把握できませんでした。さらに、複雑なアプリケーション全般においては、エラーの発生源となっているモジュールがどのように、なぜ利用されているのかについて、ほとんど理解できていませんでした。 ここで登場するのがトレースです。トレースを使うことで、Seer はマルチサービスシステム全体のフロー（フロントエンドとバックエンドといった複数階層を持つソリューションや、さまざまなマイクロサービスを利用するものを含む）、関連するエラー、エラー発生前後に実行された正確な処理（さらにプロファイリングを有効にすれば正確な関数呼び出しまで）を明確に把握できます。これにより Seer は、プロジェクトやリポジトリをまたいだ問題を非常に速く分析し、現実世界でエンジニアが直面する最も複雑な問題の一部を自律的にデバッグできるようになります。それに比べて、チャットボットにコピー＆ペーストするだけでは表面をなぞるに過ぎません。 トレースとは何か？どう活用できるのか？ すでに内容をご理解いただいている場合は、このセクションをスキップしていただいて構いません。そうでない場合は、ここで簡単にご説明します。 トレースとは、アプリケーションおよびその関連サービスを通じてリクエストがどのように流れるかを記録し、データの移動経路や潜在的な問題の発生箇所を可視化する仕組みです。トランザクションやリクエストに関与するイベントのシーケンスを追跡することで、分散システムにおけるパフォーマンスのボトルネック、エラー、依存関係などを特定するのに役立ちます。 トレース内の各ステップは「スパン」と呼ばれ、データベースクエリ、API呼び出し、関数の実行などの作業単位を表します。これらのスパンを組み合わせることで、初期リクエストから最終レスポンスまでの全トランザクションの経路を、包括的に視覚化することができます。トレースは複雑なマイクロサービスアーキテクチャのデバッグおよび最適化において、特に高い価値を発揮します。 Sentry を使えば、トレースを簡単に始められます。アプリに Sentry SDK を追加すると、多くの部分が自動的にインスツルメントされ、後からカスタムのスパンや属性を任意でインスツルメントすることもできます。たとえば Python
- [【Sentry Japan】DroidKaigi初スポンサー参加で見えたモバイル開発市場の実態](https://ichizoku.io/sentry/sentry-japan-first-sponsorship-droidkaigi-realities-of-the-mobile-development-market/) - Article by: Naru (Sentry Japan / Ichizoku 株式会社) Sentry Japan はこれまで様々な技術イベントにスポンサーとして参加してきましたが、2025年9月、ついに DroidKaigi 初スポンサーとして出展を果たしました。Android エコシステムの中核を担う開発者コミュニティとの初接触となった今回、372名もの参加者から得られたデータは、私たちにとって極めて価値ある洞察をもたらしました。 🎰 ガチャポン体験でコミュニティを盛り上げる 今回のブース戦略の中核は、ガチャポン×コミュニティ体験の組み合わせでした。アメリカ本社から取り寄せた限定スワッグ（特にパンケーキステッカーと Sentry キャップ）を用意し、その場で抽選結果がわかるゲーミフィケーション要素を導入することで、DroidKaigi というコミュニティイベントをより盛り上げることを目指しました。 この取り組みが成功し、通常のアンケートブースの3倍にあたる372名という多くの方にご参加いただくことができました。しかし、真の価値は参加者数ではなく、その過程で明らかになった Android 開発者のエラートラッキング事情にありました。 📊 Firebase Crashlytics の普及背景：「とりあえず無料だから」の実態 使用状況の数字とその背景 アンケート結果では、Firebase Crashlytics の高い普及率が確認されました。 エラートラッキング・監視ツール使用状況： Firebase Crashlytics: 285票（76%） Sentry: 86票（23%） その他ツール: 残り1% しかし、参加者との会話で見えてきたのは、Crashlytics の選択理由が必ずしも機能面での優位性ではないということでした。多くの開発者から「無料でとりあえず入れている」という声を聞くことができ、Android 開発における初期導入ツールとしての位置づけが強いことがわかりました。 Sentry の認知度：70%が未認知という現実 Sentryの認知度について調査した結果： Sentryを知らない + 使用経験なし:
- [ダウンタイムの一般的な原因とウェブサイト監視のメリット](https://ichizoku.io/sentry/common-downtime-causes-and-how-website-monitoring-can-help/) - Article by: Lewis D. 本ブログの内容 どの Sentry 機能が使用されているのか ウェブサイト監視による過負荷の検出 アップタイム監視による不良デプロイの検知 アップタイム監視による依存関係問題の検知 なぜアップタイム監視だけではセキュリティ脆弱性を検知できないのか ユーザーに指摘される前にダウンタイムのアラートを受け取る ダウンタイムは、最も都合の悪い瞬間に発生します。例えば、「クイックデプロイ」の直後や、思い切って5分間離れた時などです。トラフィックの急増によってエンドポイントの一つが集中的にダウンし、他のエンドポイントもダウンしてしまうかもしれません。あるいは、自信を持って本番環境に直送した「小さな変更」が原因かもしれません。 どちらの場合も、ユーザーはサイトにアクセスできず、現在は本番環境でライブデバッグを行っています。 この記事では、基本的なウェブサイト監視によって、ステータスページの更新、Slack の通知、ツイートなどの前に、より早く問題を発見できる方法を解説します。シンプルな Node.js Express アプリを用いて、監視によってパターンやボトルネックが明らかになり、ひょっとするとコーヒーを飲み終える時間を稼ぐことができる方法をご紹介します。 本題に入る前に少し余談ですが、物事をシンプルにし、完全に理論的な話にならないようにするために、基本的な Node.js Express アプリを立ち上げ、完全なエンタープライズ監視スタックにすることなく、実用的な監視機能だけに接続しました。 私が設定した内容は次のとおりです。 Sentry トレーシングなので、何かが壊れたときにアラートが届きます。 ソース マップは Sentry Wizard 経由でアップロードされます。縮小されたスタック トレースは最悪だからです。 アプリを軽量ホスティングサービスに投入 Sentry にアップタイム監視アラートを作成しました。これは、パブリックエンドポイントにpingを送信し、応答が停止した場合にアラートを出します。トレーシングとは別に動作するため、アプリがエラーを投げていなくても、全く応答していない状態を検知します。 どの Sentry 機能が使用されているのか この記事で紹介する Sentry のすべての機能とその役割を簡単にまとめたマップを以下に示します。 特徴 監視対象 以下に使用されている箇所 アップタイム監視 パブリックURLまたはエンドポイントにアクセスできるかどうか エンドポイントによってサイト全体がクラッシュしたときに、最初のアラートが出され、その後、別の分離されたエンドポイントルートに対してアラートが出されます。 エラー監視 処理されない例外とログに記録されたエラー 不適切なデプロイ後に発生した パッケージ欠如によるスタックトレース
- [アプリケーションのパフォーマンスを関数呼び出しレベルまでデバッグ ― 継続的プロファイリングとUIプロファイリングの導入](https://ichizoku.io/sentry/debug-app-performance-down-to-the-function-call-with-continuous-profiling/) - Article by: Will McMullen 本番環境で何かの動作が遅くなった場合、古い習慣に陥りやすいものです。ログをいくつか追加し、メトリクスを送信し、ローカルで問題の再現を試みます。意欲があれば perf や py-spy に手を伸ばすかもしれません。トレースは役立ちますが、特にスタックの深い部分では、「なぜ遅いのか」を説明するには不十分なことがあります。 つまり、開発者がアプリケーションの挙動を、直感に頼って推測せざるを得ない場面が生じます。たとえば、プロパティドリルによってレンダリングが肥大化していたり、状態変更によって不要な再レンダリングが発生していたり、あるいはサードパーティ製のライブラリが静かに 500 個のイベントリスナーを起動していたりするかもしれません。 こうしたときにこそ、プロファイリングが役に立ちます。プロファイリングは症状を指摘するだけでなく、CPUを消費している関数呼び出しやファイル、行番号を正確に表示します。 本日、私たちは Continuous プロファイリング と UI プロファイリング の2つの強力なプロファイラーをリリースします。実行時の動作を関数レベルで可視化し、ボトルネックを迅速に特定して解決するための機能を提供します。 バックエンドのボトルネックを特定して解決する Continuous プロファイリング 開発マシンでは問題なく動作していました。ステージングテストも問題なし。しかし、本番環境で実際の負荷がかかると、その重要な API エンドポイントが突然遅くなったり、バックグラウンドワーカーが予期せず大量のメモリを消費したりすることがあります。ログは正常に見え、トレースによってサービスがアクセスされたことも確認できているのに、内部のボトルネックが特定できない…。そのようなとき、開発者は再現が困難な問題や、隠れた非効率性を推測するしかありません。 継続的プロファイリングは、このような状況において、バックエンドの実行状況を常時可視化を提供します。長時間実行されるワークロード、リアルタイム API、「ローカルでは問題なかった」と片付けられがちなコードパスの解析に最適です。 特に、以下のような場合に役立ちます。 CPU ホットスポット：あるエンドポイントが突然 CPU 使用率が3倍に急増し、原因が分からない場合、プロファイリングは機能レベルのボトルネックを直接特定できます。 バッチジョブ：何時間も静かに実行される（時にはクラウド請求を倍増させる）あの夜間処理。いまでは、それが どこで時間を費やしているのかを正確に確認できる ようになりました。 ML パイプライン：あるモデルパイプラインで発生していたレイテンシのスパイクを、プロファイリング を使ってわずか 10 分ほどで、10 秒短縮しました。調べてみると、パイプラインの一部が「想定以上の処理」をしていたのです。詳細はこちらをご覧ください。 アナリティクス：あなたの「インサイトエンジン」が、実際には数百万行を回すだけのループにすぎないこともあります。プロファイリングは、ログやメトリクスでは見えない非効率を、プロダクション環境に影響が出る前に発見する手助けをします。 バックエンドサービスのパフォーマンスは、ブラックボックスのままである必要はありません。Continuous プロファイリング を使えば、インフラコストの最適化、API レスポンスの遅延削減、スループットの向上が可能になり、Slack が通知であふれる前に非効率を簡単に見つけられます。 現在、Node.jsとPythonを標準でサポートしています。
- [AIアシスタントに対する考え方を変えたSentryのAI](https://ichizoku.io/sentry/how-sentrys-ai-autofix-changed-my-mind-about-ai-agents/) - Article by: Dan Mindru ブロックチェーン、IoT、ビッグデータ… テクノロジー業界で長く働いていると、こうしたバズワードが時折現れては話題をさらい、やがて輝きを失っていく光景を何度も見ます。多くの流行が生まれては消えるのを経験してきた私は、つい懐疑的になってしまいます。 今回も、「今度は何を売り込もうとしているのか」と考えてしまいました。これを「愚痴っぽい」と言う人もいれば、「エンタープライズ・アーキテクト的だ」と言う人もいます。だから、AIアシスタントを最初は単なるバズワードだと思っていたことを、どうかお許しください。所詮は、きれいな箱に入った5つの API 呼び出しにすぎないと思っていたのです。 ところが、私は大きく間違っていました。 AIアシスタントとは 平たく言えば、AIアシスタントは販売管理から会議のスケジュール調整、コピーライティングまでを、少ない手間で短時間にこなす有能なチームメイトのような存在です。複数のプロンプト、API 呼び出し、認証、ユーザー入力を組み合わせて構築され、必要に応じてワークフローを自動的に計画できます。 万能でも低価格でもありませんが、すでに私たちの働き方を変えつつあります。さらに、AI の総コストが下がりつつある現状を踏まえると、AI 機能を実装する際の主流の選択肢になる可能性があります。 詳しく知りたい方は、AI エージェントに関する記事もご覧ください。ご自身のアプリでの活用方法を解説しています。 すべてが始まったバグ 私は「技術的に進んでいない」と感じていたため、しばらくの間、AIアシスタントを軽視していました。それは「ただの AI」に、ほんの少し装飾を加えた程度のものだと思っていたのです。しかし、インディーハッキングでの経験から学んだのは、製品を作るうえで重要なのは先進的な技術そのものではなく、解決できる問題だということです。 AIアシスタントは間違いなく強力なツールです。ただし、大きな力には大きな責任が伴います。すべての問題を解決できるわけではなく、最速の手段とも限りません。それでも、確かに有用な使用例があります。 私が信じていなかった理由のひとつは、そうした使用例を実際に見たことがなかったからなのですが、ある日、お気に入りのモニタリングプラットフォームで見つけた機能が、私の視野を大きく広げることになったのです。 その機能とは、Sentry の AI Autofix（現在はベータ版ですが、まもなく一般公開されるでしょう）です。すべては、ほとんどの良い話がそうであるように、一通のメールから始まりました。私のように「バグなんて書かない」という方でも、これはきっと驚かれると思います。 誤検出に違いないと考え、「Sentry で表示」をクリックして事態を確かめました。 そして… このあと何が起こったのか、きっと信じられないでしょう…。 私が初めて感動した AIアシスタントAI Autofix 問題を開いた瞬間、自分の能力を過大評価していた可能性がすぐに明らかになりました。 「これは、例外が規則を証明するケースに違いない」と、自分に言い聞かせます。 しかし、問題ビューの右上隅にあるソリューションハブが目に入りました。原因はどう見ても間違っていて、私は思いました。 「なるほど、Sentry も AI ブームに乗ってきたか。今日は大きく失望させられるかもしれないな」と。 ……冗談はさておき、最初は単なる一発のプロンプトに見えました。ですが、私の興味を強く引いたのは「Open Autofix」ボタンです。Sentry はこの問題に対して豊富なコンテキストを保持しています。コードベース、ソースマップ、例外の詳細、さらには多数の匿名ユーザープロパティまで。人間にとって Sentry が有用であるのと同じ理由で、AI にとっても有用になり得ます。 そして、そのボタンを押した瞬間、この機能は単なるギミックではないと確信しました。 初期分析と自己修正
- [Vercel マーケットプレイスに新カテゴリー追加・Sentry 対応開始](https://ichizoku.io/sentry/sentry-now-in-the-vercel-marketplace/) - Article by: Cody De Arkland 来年にかけて、これまでの10年間よりも多くの人々がアプリケーションを構築・出荷するようになるでしょう。あらゆる経験レベルの開発者によって「ローンチ」されるアプリケーションが増えるにつれ、「何が壊れたのか」「なぜ壊れたのか」、そしてそれを修正するための明確な道筋を理解することが、ますます重要になります。 こうした背景から、Sentry は Vercel の新たな Observability Marketplace カテゴリーにおいて、最初のプラットフォームとしてローンチされました。 Sentry は、ソフトウェアを構築するすべての人が、メトリックの行をたどってデバッグを強いられたり、特別なダッシュボードビューを手作業で作成して問題の原因を探ったりすることなく、安心してソフトウェアを出荷できるようにしたいと考えています。 Sentry を開発が生まれる現場へ ソフトウェアの開発速度が加速する中で、コードが壊れることは避けられません。そこで、Vercel を通じて Sentry を簡単に利用できるようにすることで、開発者は壊れたコードを迅速に修正するための最短ルートを手に入れることができます。 私たちは、開発者が最も利用するエコシステムへの継続的な投資を通じて、最良の開発者体験を提供することに注力しています。これにより、開発チームはソフトウェアの出荷において最も重要な部分に集中できるようになります。 この開発者体験の大部分は、Next.js のような主要なプラットフォームにおいて、可能な限り摩擦のない体験を提供できているかどうかにかかっています。 開発者は、1 行のコマンドを実行するだけで Next.js 上で Sentry を導入できます。これにより、クライアント・サーバー・エッジにわたる設定が自動的に行われ、コードのソースマップが生成され、エラー境界も実装されます。 Next.js アプリケーションでは、初回の設定コマンドを実行するだけで、エラーモニタリング、リプレイ、トレーシングが自動的に構成されるようになっています。これにより、アプリケーションの遅延や複雑なハイドレーションエラー、RSCに関する問題まで、あらゆる不具合を開発チームが迅速にデバッグできるようになります。 しかし、これで終わりではありません！ 現在、Next.js に特化した新しいインサイトダッシュボードの開発に取り組んでいます。これは、Next.js を利用する開発者に対し、フレームワーク特有の視点からの環境モニタリング機能を提供することを目的としています。 フレームワーク固有のインサイトページは、特定のフレームワークに投資した開発者に、監視プラットフォームから最も価値を得ている情報に密接に一致するインサイトを提供するように設計されています。 私たちは、従来型の監視ツールについて、非常に多くの冗談を言ってきました。というのも、それらはしばしばユーザーを複雑なダッシュボードに縛りつけ、過剰に複雑なデータの解釈を強いるからです。そのため、一見すると Next.js 専用のダッシュボードは、かえって過去に戻るように感じられるかもしれません。 ですが、ぜひ私たちの意図を聞いてください。開発者や運用チームが、Sentry の各機能からより多くのコンテキストを得られることに、私たちは強い関心を持っています。 Next.js アプリケーションは、フロントエンドとバックエンド、RSC、SSRといった技術のユニークな組み合わせを特徴としています。これらの特性に最適化されたビューを構築することで、開発者や運用チームがアプリケーション全体の状況をより深く理解し、適切な判断を下すための助けとなります。 Vercel マーケットプレイスでの Sentry Native 統合 本日（April 8,
- [【PHP】パフォーマンスを改善する方法](https://ichizoku.io/sentry/how-to-improve-performance-in-php/) - Article by: Richard C. 本ブログの内容 前提条件 プロファイリングとは？ SPX を使った PHP プロファイリング トレーシングとは？ OpenTelemetry を使った PHP のトレーシング フロントエンドを含む分散トレーシング オンラインサービスを使ったプロファイリングとトレーシング クリーンアップ PHP のパフォーマンスを改善するヒント 次のステップ PHP アプリは一見シンプルに見えますが、何かが遅くなり始めると状況は一変します。ページの読み込みに数秒余計にかかったり、原因がはっきりしないままサーバーコストが増加していたりしませんか？そんなときに役立つのがパフォーマンスモニタリングです。 このガイドでは、PHP アプリケーションのパフォーマンスを監視・改善する方法を解説します。プロファイリングやトレーシングを使ってコードのボトルネックを特定し、アプリを最適化する方法を学びましょう。Docker を使っている場合でも、すでにローカルに PHP をインストールしている場合でも、例に沿って進めることができます。 このガイドの内容は PHP 8 に対応しており、将来的な変更の程度によってはそれ以上のバージョンにも適用可能です。 前提条件 本ガイドに含まれるすべてのコード例は、Docker を使って任意のホスト OS 上で実行できます。Docker をお持ちでない場合は、こちらからダウンロードしてください。 すでに PHP がインストールされている場合、Docker は不要です。 次のセクションでは、プロファイリングとトレーシングを使って処理が遅いコード部分を特定する方法を紹介します。最後には、サイトのパフォーマンスを改善するためのベストプラクティスのチェックリストも掲載しています。 プロファイリングとは？ アプリケーションのプロファイリングとは、パフォーマンスデータを記録し、改善の余地があるコードを特定するために分析することです。パフォーマンス指標には、アプリがユーザーのために機能を実行するのにかかる時間、実行中に使用される CPU、メモリ、ディスク、ネットワーク帯域などが含まれます。これらすべての指標の値が低いほど、ユーザー体験が向上し、サーバーコストの削減にもつながります。 記録された結果を分析することで、意図よりも高い値の指標を特定し、その原因となっているコード行を見つけます。
- [【Sentry トレーシング】Next.js [Object] not found エラーを調査](https://ichizoku.io/sentry/investigating-an-object-not-found-error-in-next-js-with-tracing-in-sentry/) - Article by: David Y. 本ブログの内容 サンプルアプリケーションのセットアップ エラーの再現 エラーの調査 エラーの修正 Next.js アプリケーションでエラーを特定するための Sentry トレーシング設定 Sentry トレーシングで可能なその他の機能 ローカル開発中は、ブレークポイントや console.log があなたの正気を保ってくれるかもしれませんが、本番環境の問題はまったく別の話です。本番環境では、エラーが複数のマイクロサービスに分散していたり、難読化されたコードに隠れていたりします。それらを追跡するのは至難の業です。 そこで活躍するのが Sentry のトレースとスパンです。フルスタックかつ分散された環境において、ネットワークリクエスト、API 呼び出し、DB 取得などすべてを簡単に可視化できます。 Sentry の分散トレーシングは、Next.js アプリを通過する各ネットワークリクエスト、API 呼び出し、データベースクエリを明確かつ実用的に可視化します。推測に頼ることなく、パフォーマンスのボトルネックや複雑な障害が発生している箇所を正確にマッピングできます。 分散トレーシングにより、例えばデータベースのレコード欠落や想定外のペイロードを返すエンドポイントなど、エラーの根本原因をすばやく特定し、エラーがユーザー体験全体にどう影響するかを正確に把握できます。さらに優れているのは、他人のコードをあさったり、リポジトリの権限を待ったりすることなく、本番トラフィックをデバッグできる点です。 Sentry が新たなエラーを検知した瞬間や、インサイトに予期しないスパイクが表示されたとき、特定のトレース ID に絞り込み、各リクエストを特定し、コールスタックが崩れ始めた正確な場所を突き止めることが可能なのです。 分散トレーシングなら、以下のような状況でも簡単にデバッグできます。 ソースコードへの読み書き権限がない場合 デバッグ用のコードを追加でデプロイできない場合 エラーメッセージがあいまいで不明瞭な場合 複数のマイクロサービスが原因の特定を難しくしている場合 本ガイドでは、ソースコードを見ることなく本番環境の問題を効果的にデバッグするために、Sentry のトレーシング機能を活用する方法をご紹介します。 手元でセットアップして進められる、サンプルのコース管理アプリを用意しました。 サンプルアプリケーションのセットアップ このコース管理アプリケーションは、TypeScript で記述されており、React フレームワークである Next.js を採用しています。型安全性の確保には tRPC を、データの永続化には PostgreSQL
- [【Python】エラーと例外処理の実践的なヒント](https://ichizoku.io/sentry/practical-tips-on-handling-errors-and-exceptions-in-python/) - Article by: Abdul D 本ブログの内容 Python におけるエラーと例外 − その違いとは Python におけるエラー Pythonにおける例外 なぜ Python において例外・エラー処理が重要なのか Sentry は Python アプリのエラー監視にどのように役立つのか Python のコードで、原因か分からないエラーメッセージに遭遇したことはありませんか？ それはあなただけではありません。経験豊富な開発者でさえ例外に直面するため、効果的に対処する方法を理解することが重要です。 基本的な構文エラーはコードエディタやデバッグツールによって早期に検出できますが、より複雑な問題は実行時に発生することが多く、体系的な例外処理のアプローチが求められます。 経験の有無にかかわらず、すべての Python 開発者が例外処理を習得することで恩恵を受けられます。本ガイドでは、エラーと例外の違いを理解し、一般的な例外の種類を確認したうえで、Python アプリケーションにおける適切な対処方法を学びます。 また、Sentry を使ってリアルタイムで例外を監視・追跡する方法についても解説し、アプリケーションのパフォーマンスと安定性に関する詳細なインサイトを得る手段を紹介します。 https://player.vimeo.com/video/1069262421?h=64399662d1 Sentry トレーシング Python におけるエラーと例外 − その違いとは 完璧なコードを書くことは非現実的な期待であり、すべての開発者はコーディングミスによる予期しない動作に直面するものです。これらの問題は一般的にエラーと例外の2つに分類されます。 エラーはプログラムの実行を完全に妨げる根本的なコーディングミスです。エラーは通常コンパイル時に検出され、修正されるまでコードは実行されません。 例外はエラーの一種であり、プログラムの実行中（ランタイム）に予期しない状況、例えばゼロ除算のような場合に発生します。 result = 10 / 0 # Raises ZeroDivisionError エラーとは異なり、例外はコード内で捕捉して処理することができます。 エラー処理 vs
- [JavaScript にも Debug ID が必要](https://ichizoku.io/sentry/javascript-needs-debug-ids/) - Article by: Abhijeet Prasad 数か月前、Sentry は Debug ID 用の新しい NPM 組織（名前空間）を作成し、その配下に複数のパッケージを公開しました。https://www.npmjs.com/org/debugids これは、JavaScript Debug ID がエコシステム全体で正式に認知されるための大きな一歩です。同時に、Sentry がオープンスタンダードを牽引し、合意形成に取り組む成熟度を示しています。 ----------------------------------------------------------------------------------- 💡 要点まとめ Debug ID は JavaScript ファイルとそのソースマップを結びつける決定論的かつグローバルに一意な値です。 Sentry は Debug ID を Sentry 独自の機能にとどまらず、JavaScript エコシステム全体で広く利用される概念にしようとしています。 Debug ID をソースマップ仕様に追加するため、tc39 に公式提案を提出し、ブラウザ API も含めた標準化を推進しています。 誰でもツールやアプリに Debug ID 機能を追加できるよう、各種プラグイン・ツール・ポリフィルを公開済みです。また、バンドラーやソースマップツールへの対応を JavaScript コミュニティと協力して進めています。 詳しく知りたい方は、ぜひ読み進めてください。 Debug ID とは何か 現代のウェブサイト開発者は、JavaScript
- [【ダッシュボードのアップデート】クリック数削減、操作性向上、ウィジェット作成の高速化](https://ichizoku.io/sentry/dashboard-updates-less-clicks-more-control-faster-widget-building/) - Article by: Alexandra Cota 本番環境のメトリクスを確認していると、突然ダッシュボードにエラーのスパイクが表示されます。このとき最初に考えるのは「この状況を調べるために新しいビューをどのように作ろう」ではなく、「どうすればすぐに原因を突き止められるのか」でしょう。実際、先月私たちのエンジニアリングチームの一つがAPIのレスポンスタイムに異常なパターンを発見した際にも、まさに同じ状況が起こりました。彼らはゼロからアドホッククエリを実行するのではなく、以前のインシデント後に作成していたカスタムダッシュボードを活用しました。 エラーとトレースデータの傾向を関連付けることで、彼らはすぐに原因を特定しました。それはインデックスの欠落による非効率なクエリ実行でした。迅速に修正を加えた結果、レスポンスタイムはすぐに正常に戻り、何時間も手作業で調査する必要はありませんでした。 ダッシュボードは単なる静的なレポートではありません。チームが異常を素早く検知し、シグナル同士の関連性を見つけ、問題の根本原因に素早くたどり着くための動的なツールです。 過去数か月の間に、ダッシュボードの構築、管理、操作を改善するためのさまざまなアップデートを行いました。ウィジェットビルダーの刷新から、ダッシュボードの整理・保護方法の新機能まで、設定にかける時間を減らし、本当に重要なことに集中できるようになりました。 より直感的なウィジェット作成 ウィジェットはダッシュボードの基本要素であり、私たちはウィジェットビルダーを刷新し、ウィジェットの作成・編集をより簡単かつ直感的にし、ワークフローとの統合性も高めました。 サイドパネルデザイン：ページ遷移せずにウィジェットの作成・編集が可能です。 ライブプレビュー：設定を調整すると即座に反映され、余計なスクロールや固定ヘッダーの操作は不要です。 シンプルなレイアウト：視覚的な煩雑さを抑え、必要なステップが一目で分かり、クエリを素早く作成できます。 ウィジェットライブラリの改善：ビルダーのスペースを圧迫することなく、ゼロからウィジェットを作るか、プリセットから始めるかを選択可能です。 ダッシュボードを意図した通りに維持する リリース当日、チームはクリティカルリリースダッシュボードを注視し、問題が拡大する前に検知しようとしています。エラー、レイテンシ、スループット。必要な情報はすべてそろっているはずです。 しかし、状況が悪化し始めたとき、失敗率のチャートが消えていたり、フィルターが変更されていたり、レイテンシのウィジェットがp95ではなくp50を表示していることに気づきます。 実は、誰かがダッシュボードを編集していたのです。その結果、問題を素早く把握するどころか、表示を元に戻すために右往左往し、貴重なインシデント対応の時間を無駄にしてしまいます。 ダッシュボードは、他チームによる意図しない変更が加えられることなく、自分たちが最も重視するインサイトを正しく反映すべきです。今回の更新により、誰がダッシュボードを編集できるかを制御できるようになりました。 これにより、クリティカルリリース用のダッシュボードをロックしたり、自分のチームだけに編集権限を付与したりすることが可能です。新たに追加された「編集アクセス」セレクターにより、適切な制御が可能になり、明確な権限の線引きがチーム間の円滑なコラボレーションを実現します。 お気に入り登録とダッシュボード整理 チェックアウトフロー、認証フロー、主要APIエンドポイントなど、ダッシュボードの数が増えていくと、目的のダッシュボードを素早く見つけることが重要になります。そこで、ダッシュボードのお気に入り機能を導入しました。重要なダッシュボードをリストの上部にピン留めすることができます。 ダッシュボード詳細ページまたはダッシュボード一覧ページで⭐アイコンをクリックするだけで、よく使うダッシュボードがいつでもすぐアクセスできるようになります。 さらに、テーブルビューも追加し、ダッシュボードの整理・管理をよりコンパクトに行えるようにしました。以下の2つのビューを切り替えられます。 グリッドビュー：カード形式のビジュアルレイアウト テーブルビュー：コンパクトな表形式 始め方 Sentry のダッシュボードを使えば、単なる監視にとどまらず、すぐに問題解決へとつなげることができます。トランザクションの失敗が急増しているのを見つけた際、どのデータベースクエリが遅延を引き起こしているのか、どの例外がコード内で発生しているのかを即座に掘り下げることができます。ハイレベルなメトリクスと実装の詳細が直接つながっているため、頻繁に画面を切り替えることなく、問題の特定・診断・修正が可能になります。 これらの改善は、モニタリングとデバッグをよりシンプルにするという私たちの継続的な取り組みの一環です。そしてこれは始まりにすぎません。今後数か月間でさらに多くの改善が予定されています。 この機能は Business プランと Enterprise プランのすべてのユーザーが利用できます。ぜひダッシュボードで自分だけの画面を作ってみてください。 まだ Sentry のアカウントをお持ちでない方もご安心ください。無料トライアルやデモリクエストですぐに始められます。 Original Page: Dashboard updates: Fewer
- [異常検知アラートがオープンベータで利用可能に　より賢いモニタリング・誤検知を削減](https://ichizoku.io/sentry/anomaly-alerts-open-beta-smarter-monitoring-fewer-false-alarms/) - Article by: Rachel Wang, Aayush Seth 数週間前、私たちはアーリーアダプター向けに異常検知アラートを導入しました。そして本日（2025/3/25）、異常検知アラートが正式にオープンベータとなり、Trial、Business、Enterpriseプランの全Sentryユーザーが利用可能になったことをお知らせします。 異常検知アラートとは？ Sentryでは、特定のメトリクスが予想された閾値から逸脱した際に通知されるメトリクスベースのアラートを設定できます。例えば、エラー率が一定の閾値を超えたときや、主要なアプリケーションパフォーマンス指標が特定の範囲を外れたときにアラートを作成できます。 強力ではありますが、メトリクスのアラート閾値を手動で設定するのは複雑な作業になりがちで、しばしばノイズの多いアラートや、最悪の場合は問題の見逃しにつながることもあります。従来、Sentryでメトリクスアラートを設定するには、適切なバランスを見つけるためにかなりの推測と試行錯誤が必要であり、さらにデータについての深い理解も求められていました。 アラート詳細ページでユーザーのクエリによって定義されたカスタムメトリクスアラートで発生した異常アラートの例です。チャート上では赤色で表示され、アルゴリズムが異常な挙動を検知するとアラートが発報されます。 異常検知アラートは、予想されるパターンを自動的に学習することで、この複雑さを解消し、ユーザーは設定や推測なしでアラートを作成できます。静的な閾値を手動で定義する代わりに、異常検知アラートは過去のデータを利用して予測される傾向を判断します。これにより、誤検知が減り、アプリケーション監視時のシグナルとノイズの比率が改善されます。 さらに、静的な閾値は状況の変化によってすぐに古くなったり無意味になったりしますが、異常検知アラートは時間とともに動的に調整され、昼夜や平日・週末といった季節性や、持続的な成長といった長期トレンドも考慮します。これによりビジネスやアプリケーションが変化しても、アラートは常に適切な状態が保たれます。 仕組み 異常検知アラートは、Matrix Profiling と Prophet Forecasting という2つのアルゴリズムの組み合わせを活用しています。 Matrix Profiling：最新のデータポイントが過去のパターンと比べてどれほど「意外」かを検出します。現在と過去のデータ系列間のユークリッド距離に基づいて異常を評価します。 Prophet Forecasting：季節性や長期的なパターンを考慮しながら期待されるトレンドのモデルを構築し、データポイントが予測範囲から外れたときに逸脱として検出します。 ハイブリッド検知： 両方のアルゴリズムが異常を検知した場合、または片方が高い確信度で異常を検知した場合に、システムは異常アラートを発報します。この組み合わせたアプローチにより、誤検知（偽陽性）と見逃し（偽陰性）の両方を最小限に抑えます。 今すぐ試してみよう 異常検知アラートは現在、Trial、Business、Enterpriseプランのすべてのユーザーにオープンベータ版として提供されています。 始めるには、左側のナビゲーションバーの Alerts タブに移動し、Create Alert をクリックしてください。次にメトリクスを選択し、検知方法として Anomaly を選び、必要に応じて感度を調整すれば、あとは Sentry が処理してくれます。異常検知アラートの設定方法については、ドキュメントに詳しい情報があります。 異常検知アラートのパブリックベータ版公開は、私たちのチームにとって大きな節目であり、今後もこの機能の安定化に取り組んでいきます。皆さんのフィードバックもぜひお聞かせください。ぜひ試して、ご意見をお寄せください！ Original Page: Anomaly Alerts Now in Open Beta: Smarter
- [【AIエージェント】ハイプか現実か？](https://ichizoku.io/sentry/ai-agents-hype-or-reality/) - Article by: Dan Mindru 数年前はブロックチェーンが話題の中心でした。その前はIoT、その前はビッグデータ、さらにその前はクラウドでした。それぞれの時代が一種のパラダイムシフトをもたらし、大規模な投資と約束が生まれました。成功したものもあれば、そうでないものもありましたが、いずれもテクノロジーの進化を促進したといえます。 現在、私たちは2022年頃にOpenAIから始まったAIの誇大広告サイクルを全面的に受け入れています。しかし、今回はこれまでとは異なる感覚があります。マーケティングが優れているからではありません（「OpenAI」の「Open」と「AI」について議論の余地はあります）が、前例のない速度で実際のアプリケーションが次々と登場しているからです。これは未来の約束ではなく、「今」起きている現象です。そして、その進展は非常に速いのです。では、どのくらい速いのか。その速さは、2025年の現在、誰もが次のビッグトレンドである「AIエージェント」に飛びついていることからもよくわかります。 OpenAIは「Operator」を発表しました。これは自分のブラウザを使ってユーザーのためにタスクを実行できるAIエージェントです。中には2024年の時点で一足先にAIエージェントをリリースした企業（Chatbaseなど）もあります。 しかし、そもそもAIエージェントとは何でしょうか？ 初めて聞く方にもわかるように説明しましょう。14歳の子どもにも説明できると言いたいところですが、正直なところ、最近では私たちより彼らの方がAIエージェントについて詳しいかもしれません。 では、始めましょう！ AIエージェントとは？ 想像してみてください。 あなたの会社で極秘のエンタープライズアップグレードが導入されたとします。ITチケットも不要、ダウンタイムもなし、マニュアルもいりません。目に見えない裏方チームが、カスタマーサポートの対応、コードの記述、ドキュメントの翻訳、マーケティングコピーの作成など、あらゆる作業を同時にこなします。しかも月額200ドル、24時間365日稼働し、「至急」案件も数分で「完了」へ。ミーティングもオンボーディングも不要。まるでワークフローに誰も予想しなかったターボボタンを追加したようなものです。それがAIエージェントであり、どのように見ても魅力的です。 では、仕組みはどうなっているのでしょうか？ AIエージェントは、大規模言語モデル（LLM）を強化するためのシステムであり、タスクの計画、サードパーティサービスとの統合、プロンプトの連鎖による回答の洗練を行います。 LLMとは？LLM（大規模言語モデル）は、大量のテキストデータで学習されたディープラーニングモデルで、人間のような言語を理解し生成します。文章の次に来る単語を予測し、質問への回答、コンテンツの執筆、言語の翻訳、アイデア出しなどを、学習データ内のパターン認識を通じて実行します。 簡単に言えば、比較的シンプルなプロンプトを受け取り、それを複数のプロンプトとAPIコールの組み合わせに変換できます。もちろん、単一のプロンプト実行よりはコストが高くなります（この点については後述します）。話を複雑にしすぎずに言えば、AIエージェントのワークフローは「彼ら」が従うフローに基づいて大きく2つのカテゴリーに分かれます。 処方型ワークフロー 探索型ワークフロー これらについて詳しく見ていきましょう。 処方型ワークフロー 単一のレスポンスで完結 シンプルに言えば、AIエージェントは「通常の」プロンプトを連結したものです。魔法のようなものではありませんが、実用的な実装が可能になります。 例えば、AIエージェントのシンプルな実装は、好みのAIモデルに対して複数回のLLMコールを行うforループであり、その前後にサードパーティAPIコール（あるいはインテグレーション）を組み合わせる形です。 一部のAPIコールは他のサードパーティAPIへのアクセスでもあり、ユーザーの「ゲート」（入力待ち状態）によって制御される場合もあります。 これは、リアルタイムデータや他のシステムに隔離されたデータへアクセスするなど、LLMの本質的な制限を克服するのに特に有効です。 例えば、AIエージェントが従業員の休暇申請を処理するケースでは、内部APIを介して分離された人事データベースにアクセスし、残りの有給休暇を確認し、条件を満たせば自動承認する、という流れです。 他の例としては以下のようなものがあります。 カスタマーサポートFAQエージェントクエリの意図を特定するために4つのプロンプトを連鎖させ、内部ナレッジベースから関連情報を取得し、ユーザーにわかりやすい形で返します。 コンテンツ作成ワークフローブログ記事作成のために3つのプロンプトを連鎖し、アウトラインの生成、各セクションへの展開、最終稿のスタイル調整までを行います。 ミーティングスケジューラーAPIコール、プロンプト、再度APIコールを連鎖し、個人のカレンダーを確認し、最適な時間にミーティングを提案・予約し、Slackチャンネルへ通知します。 処方型ワークフローでは、タスクを小さなマイクロタスクに分割し、並列処理したうえで最終的に1つのレスポンスにまとめることもできます。このアプローチは非常に高性能かつ柔軟性があります。 さらに、各マイクロタスクがそれぞれ独自にAPIコールを行い、リアルタイムデータや隔離されたデータを取得することも可能です。 つまり、これらのワークフローは、私たちがよく知っていて好むLLMの特性（文脈理解、タスク非依存の多用途性、柔軟な推論、人間らしい対話など）を活かしつつ、それ単体では難しい、あるいは不可能な機能を補完しています。 処方型ワークフローの利点はコストが予測しやすい点です。単一のLLMコールよりは高くなりますが、APIの使用量やタスクの複雑さが一定ならコストは安定します。 しかし、統合数を増やすと難易度や非効率が増すこともあります。APIコールがすべて必要とは限らず、場合によっては動的なユーザー入力が求められることもあります。 では、もしエージェント自身がこれを判断できたらどうなるでしょう？ 探索型ワークフロー：適応的かつ動的 ここまで読んでこう思ったかもしれません。 「AIエージェントって、トレンチコートを着たLLMコール3回分の塊じゃない？」 しかし、実は時には冬用ジャケット、金融用ベスト、さらにはダサいクリスマスセーターにもなり得ると言ったらどうでしょう？実際、すべてのAIエージェントが同じように作られているわけではありません。多くのエージェントはプロンプトの連鎖に基づいていますが、それだけでなく計画、推論、反復、自己指向的なワークフローの遂行も可能です。 探索型ワークフローは動的で適応性があります。処方型ワークフローで可能なすべての経路をたどることができますが、あらかじめ定義されているわけではなく、APIやインテグレーション、人間からのフィードバックに基づいて自ら計画・実行・適応します。根本的には、プロンプト技法、ループ処理、APIコールの集合体です。そこにユーザー入力を少し加えることで、数年前には構築不可能だったようなシステムが実現できます。 このようなワークフローは、より汎用的になり、ツールやAPIコールの数に関わらずスケールし、何千もの個別かつ動的なワークフローを構築できる可能性があります。これも拡張手法の一つですが、より多くの工夫が加わっています。 動的な計画立案：エージェントが中央レジストリから使用するツールを自分で決定します。 ツール統合：OpenAPI仕様のようなコンテキストを利用して、CRMシステムや各種APIと統合します。 セキュアアクセス：OAuthのようなプロトコルを使い、エージェントが安全にプライベートデータへアクセスします。 反復的推論：結果を評価し、成功または失敗の基準に達するまで計画を調整します。 フィードバックループ：強化学習や人間のフィードバックを通じてパフォーマンスを改善します。 例えば、クラウドストレージやメールを横断検索するよう指示されたAIエージェントを考えてみましょう。このエージェントは、必要に応じてDropboxやGmailのAPIを呼び出し、実行ステップを動的に計画し、タスクが完了するまで結果に基づいて繰り返し処理を行います。実際のアプリは単純な入力インターフェースであり、ユーザーは「Dropboxを検索」といった特定のサービスを指定したり、「メールとカレンダー全体を検索」といった一般的な指示を出したりします。
- [【React Native】ログ出力ガイド](https://ichizoku.io/sentry/a-guide-to-logging-in-react-native/) - Article by: Matthew C. コンソールによる基本的なログ出力は、アプリのデバッグや理解を始める上で良い出発点です。より大規模で複雑なアプリでは、追加情報の記録やログの永続化が有効になります。 このガイドでは、React Native においてログを作成・表示する方法、カスタムログをファイルに保存する方法を学びます。 JavaScript のログを中心に扱いますが、Sentry の React Native SDK を使用し、従来のログを超えたエラー・例外の自動報告やそれに至るイベントの可視化方法についても紹介します。 コンソールメソッドとログレベル React Native では、Web ブラウザと同じコンソールメソッドが使用できます。 ほとんどのコンソールメソッドには、重大度（Severity）のレベルが割り当てられています。以下の 4 段階があり、軽いものから重いものの順に、それぞれの用途を示しています。 Verbose（冗長）：デバッグ用のログメッセージ。 Info（情報）：コードが期待通りに動作しているときのログ（例：ユーザーが支払いを完了した時）。 Warning（警告）：問題につながる可能性のあるイベントのログ。 Error（エラー）：実際のエラーのログ。 以下の表はよく使われるコンソールメソッドと、それぞれに割り当てられたログレベルを示したものです。 console.debug メソッドは、console.log や console.info と同様に動作しますが、ログレベルが異なります。console.trace メソッドは、スタックトレース（関数の呼び出し履歴）をコンソールに出力するために使用されます。 console.time と console.timeEnd メソッドを組み合わせて使用することで、処理にかかる時間を測定できます。 オブジェクトのログ出力 本番環境のアプリケーションでは、文字列よりもオブジェクトをログに出力した方が良い場合があります。 構造化されたログ出力（Structured Logging）により、JSON としてパース可能なログファイルが作成されます。これにより、監査ツールでログをデータベースのように検索できます。可能であれば、あらかじめログプロパティのセットを定義しておくと、ログの整理や検索がしやすくなり、エラー追跡や分析がよりスムーズになります。 コンソールログの表示方法 React Native の開発サーバーを起動すると、Metro
- [PlayStation・Xbox・Switch・PC・モバイル　どのプラットフォームでもSentry がバグの修正をサポート](https://ichizoku.io/sentry/playstation-xbox-switch-pc-or-mobile-wherever-youve-got-bugs-to-crush-sentry/) - Article by: Sasha Blumenfeld ボス戦でのフリーズでも、マルチプレイ中の突然の切断でも、クラッシュは没入感を壊し、プレイヤーを怒らせてしまいます。しかも各プラットフォームごとに異なるエラー報告システムがある中で、これらの問題をデバッグするのは非常に困難です。 Riot Games、Epic Games、Unity を含む 1,500 社以上のゲーム企業が Sentry を使用して自社プロダクトを監視しており、当社はゲームエンジンおよびコンソールとの統合サポートを継続的に拡充しています。Unreal Engine、Unity、Godot、社内エンジンのいずれで開発していたとしても、PlayStation、Xbox、Nintendo Switch 向けに出荷していても、Sentry は本番環境におけるクラッシュ、エラー、パフォーマンス問題を分散したログを探し回ったり、プラットフォーム固有のツールを切り替えたりすることなく追跡できます。 https://player.vimeo.com/video/1066828073?h=bec67c0497 Sentry を使えば、すべてのプラットフォームで発生したネイティブクラッシュや例外を一箇所に集約できるため、こうした問題を簡素化できます。読みにくいメモリアドレス（長い 16 進数の数字列）と格闘する代わりに、Sentry はシンボル化されたスタックトレースを提供し、どの関数のどのコード行がクラッシュを引き起こしたのかを正確に示してくれます。 以下のような充実したコンテクスト情報を得ることができます。 読みやすいスタックトレースやパンくずリストにより、クラッシュ直前のプレイヤーの操作、エンジンイベント、システム動作を記録。何が壊れたかだけでなく「何が起きたのか」を把握できます。 ビルド番号やOSバージョンの追跡により、クラッシュが特定のアップデートに関連しているのか、古いシステムを使用しているプレイヤーのみに影響しているのかを判断できます。 クラッシュ時のスクリーンショットを記録し、ゲームが停止する直前のプレイヤーの視点を把握できます。 クロスプラットフォームでの可視化により、コンソールの問題を認証の障害となる前に解決できます（パブリッシャーに「なぜリリースできなかったのか」と説明することは、誰にとっても望ましくありません）。 開発用キットでは正常に動作していたにも関わらず、市販のハードウェア上で突然クラッシュが起き始めた… という場合でも、Sentry なら、原因（たとえば物理エンジン内のヌルポインタ例外）を正確に突き止め、プレイヤーの怒りが爆発する前に修正することができます。 Nintendo Switch 向けゲームで Sentry を使用するには、Nintendo のサーバーを設定してクラッシュ情報を Sentry に自動で転送するようにします。まずは Nintendo の CRPORTAL から始めてください。 Xbox 向けには、Microsoft の GDKX Middleware 認証ページで Sentry を見つけて、そこから導入を開始できます。 そして最後に、PlayStation 向けには Tools
- [【Mobile Vitals】ユーザーがアンインストールする前にモバイルアプリの動作遅延を修正](https://ichizoku.io/sentry/fix-slow-mobile-apps-before-your-users-uninstall-with-mobile-vitals/) - Article by: Will McMullen, Markus Hintersteiner モバイル開発者なら、この苦労をよく知っているはずです。小さなリグレッションが本番環境では大きな問題につながることがあります。しかも、それを修正するのは簡単なパッチを即座に反映すれば済むというものではありません。Webアプリと違って、モバイルアプリの修正にはアプリストアの審査を通す必要があり、場合によってはクライアントとのミーティングに参加し、再現が難しい問題のデバッグに取り組むこともあります。 ★1レビューが届く前に、こうした問題を検知することが極めて重要です。幸いなことに、Sentry がこの作業をこれまでになく簡単にしてくれました。 Mobile Vitals ― インサイト機能に新たに追加されたこのツールは、アプリの起動や画面の読み込み、描画が遅い箇所をハイライト表示することで、フリーズやラグによる操作不良を、ユーザーが怒ってアプリを終了してしまう前に迅速に対処できます。React Native、Flutter、Android、iOS ― どのプラットフォームで開発していても活用できます。では、何ができるのか見ていきましょう。 （ちなみに「Mobile Vitals」については数年前にも取り上げています。この新ツールの仕組みに興味がある方は、こちらの記事もあわせて読むと面白いと思います。） Mobile Vitals は何を計測しているのか？ 1：アプリ起動のパフォーマンス インスタグラムでレシピを延々と見ていたら、突然カロリー計算アプリの良さそうな広告が表示されました。試しにダウンロードしてみたものの、なぜか初回の起動に20秒、2回目以降でも10秒かかる。さて、あなたはどうしますか？ オレオを食べながら、遅い起動に耐えるか、それとも体重計に戻るか… Sentry はユーザーがイライラしてアプリをアンインストールする「無駄なカロリー消費」を防ぐために、アプリ起動のパフォーマンスを計測します。ここで注目しているのは、コールドスタートとウォームスタートの2つの指標です。 コールドスタート第一印象は取り返しがつきません。Sentry はコールドスタートを個別に計測することで、最新のパッチが第一印象を台無しにしないかどうかを確認できます。 ウォームスタート iOS や Android のメモリ管理は複雑で、アプリをバックグラウンドで「ウォーム」に保ちながら、一部のタスクを停止することがあります。最近使用したアプリ一覧から再び起動するときには、アプリがすぐに立ち上がることが求められます。 重要なのは、上位の指標だけではありません。ウォームスタートにおいて、Sentry は iOS および Android アプリに対して非常に細かく自動で計測を行います。たとえば iOS では、実行前処理、UIKit、フレームレンダリングなど、さまざまなネイティブ処理を個別に確認でき、アプリの読み込みを遅らせているボトルネックを特定・修正できます。 各画面をクリックすると、その画面に至るまでの最新のアプリ読み込み状況が一覧で表示され、さらに詳細に掘り下げて、どの処理がボトルネックになっているかを確認できます。 2：画面読み込みのパフォーマンス コメントページを開くたびに毎回5秒かかるようでは、誰もコメントを残しません。話はそれだけシンプルです。 Sentry は各画面の読み込みについて TTID と TTFD を計測することで、UX の重さを軽減するのに役立ちます。 TTID（Time to Initial
- [React.js パフォーマンスガイド](https://ichizoku.io/sentry/react-js-performance-guide/) - Article by: Armin Ulrich 最もパフォーマンスが高い JavaScript フレームワークはどれでしょう？React、Vue、Svelte、Angular…？この問いに答えようとするとき、私たちはしばしばリアクティビティ、バンドルサイズ、メモリ使用量などのベンチマークの比較に迷い込んでしまいます。 もちろん、パフォーマンスの高いアプリを作るために最適なフレームワークを選びたいものです。しかし、React アプリに限らず、Web アプリ全般におけるパフォーマンス最適化のベストプラクティスに従わなければ、フレームワークの性能だけではアプリの恩恵は得られません。 では、どこから始めればよいのでしょう？パフォーマンスに影響するのは何でしょうか？ このガイドでは、Reactにおけるパフォーマンス最適化の基本を解説し、この分野をさらに深く学ぶためのツールやリソースを紹介します。 なぜパフォーマンスに投資すべきか パフォーマンス向上 = ユーザー体験の向上 遅いアプリに時間を割く人はいません。人々は素早く物事を済ませたいのです。あなたのアプリはそのための道具です。パフォーマンスはアプリとブランドへの信頼を築き、良好な体験を提供する助けになります。 パフォーマンス向上 = コンバージョン率と継続率の向上 優れたユーザー体験は、コンバージョン率と継続率（＝どれだけ多くの人が登録し、使い続けるか）を高めます。つまり、パフォーマンスはアプリの成功に直接貢献します。 パフォーマンス向上 = SEOの向上 検索エンジンはパフォーマンスの高いページを上位に表示し、ユーザーエンゲージメントも評価対象とします。ユーザーが必要な情報を効率よく見つけられて長く滞在するなら、それがSEOパフォーマンスにも良い影響を与えます。 パフォーマンス向上 = スケーラビリティの向上とコスト削減 パフォーマンスのベストプラクティスに則ったコードベースは、システムが複雑化しても保守や拡張がしやすく、インフラコストも少なくすみます。 React によくあるパフォーマンス問題 8選とその解決方法 パフォーマンスについて話すとき、通常はアプリの読み込み時間や応答性を測る指標を指します。 読み込み時間とは、アプリが必要とするコードやアセットをすべて読み込むのにかかる時間のことです。これには、FCP（First Contentful Paint）、LCP（Largest Contentful Paint）、TTI（Time to Interactive）などの指標が用いられます。 応答性または実行時パフォーマンスは、スムーズな（再）レンダリングに関わるすべての処理を指します。ここではReactコードそのもののパフォーマンスが大きな要因になります。応答性を測るための重要な指標にはINP（Interaction to Next Paint）があります。さらに、プロファイリングやモニタリングツールを使ってトランザクションの実行時間を測定したり、フレームレート、CPUやメモリの使用量を確認したりすることも可能です。 アプリの読み込みと操作感をどちらも高速に保つには、これら両方のパフォーマンス指標を考慮する必要があります。それでは、よくある問題とReact特有の、あるいはReactに限らない解決策を見ていきましょう！ 1. バンドルサイズが大きい アプリが大きければ大きいほど、読み込みに時間がかかります。これは当然のように聞こえますが、実際にはパフォーマンスを大きく改善できるポイントのひとつです。目標は常に、可能な限り少ないコード（およびその他のアセット）をブラウザに送ることです。 バンドラの使用と最適化Webpack
- [【Breakpoint まとめ】稼働監視・ロボット・豊富なフィーチャーフラグ](https://ichizoku.io/sentry/breakpoint-recap-uptime-monitoring-robots-and-feature-flags-galore/) - Article by: Sasha Blumenfeld バグは丁寧に現れることはなく、チェックアウト機能をクラッシュさせ、認証を破壊し、APIの応答速度を極端に低下させます。しかも多くの場合、CEOから進捗状況を尋ねられる直前に発生します…。さらに、エラー通知ボックスが「TypeError: cannot read property of undefined」の亜種で埋め尽くされると、真に重要な問題を見極めることが困難になります。 https://youtu.be/YHJDfpHUmaQ?si=clnu7dCnsneqMkWG そのため、デバッグにおける推測作業を排除するためのアップデートを展開しました。調査に費やす時間を短縮し、開発に集中できるようにすることが目的です。ユーザーに影響が及ぶ前にダウンタイムの通知を受け取り、サイト上で関連する問題やユーザーからのフィードバックを直接確認できます。また、AIによるアラートのグルーピング機能により重複を整理し、AI支援による修正により、問題の迅速な解決が可能になります。 アプリ障害、上司より先に気づけていますか？ プロダクション障害はそれだけで問題ですが、それを CEO の Slack メッセージで知るのは最悪です。 現在一般提供中の Uptime Monitoring を使えば、SNS で炎上したり、全社ミーティングで取り上げられたりする前に、障害を検知することができます。 最短60秒間隔で実行されるグローバルチェックにより、障害発生の瞬間を即座に把握できます。 以下のことが可能です。 重要なフローの監視たとえば、購入処理が突然止まったかどうかを検出するためのチェックアウトページやユーザーがログインできなくなっているかを確認するログインエンドポイントなどです。 カスタム条件の設定たとえば、ダウンタイムが60秒を超えた場合にのみ通知を受け取るように設定可能です。 普段使用しているツールでの通知Slack、PagerDuty、Teams、または Webhook 経由です。 たとえば、チェックアウトページが突然タイムアウトし始めたとしましょう。顧客からの苦情を待つ代わりに、即座にアラートが届きます。障害ログを確認すると、サードパーティの決済サービスの応答が遅いことが分かります。Sentry のエラーやトレースと照合することで、その遅延がどこで発生しているのか（APIの障害か、ネットワークの問題か、自分たちのコード内の何かか）を正確に特定でき、売上の損失が積み重なる前に修正できます。 私たちはこれまでに 40,000件のダウンタイムを検知しており、それらが大量のサポートチケットに発展する前に、チームが問題を特定できるよう支援してきました。 モニターは1つ無料でご利用頂けます。追加はモニター1つあたり月額1ドルです。HTTPメソッド、ヘッダー、ボディパラメータなど、リクエストの詳細を完全にコントロールし、特定のURLに対するカスタムアラートを作成できます。ぜひ試してください。詳細はブログでもご覧頂けます。 重複したエラーを掘り返すのはやめましょう エラー受信箱が多数の通知で溢れていても、それが本当に10件の異なる問題なのでしょうか。それとも同じ問題の50通りのバリエーションでしょうか。現在受信しているアラートが、実は過去に対応済みのエラーの再通知である可能性もあります。 このように終わりのないアラートの中で混乱するのではなく、Issue Grouping を活用することで、関連するエラーを自動的にグループ化し、イズを削減できます。その結果、本当に修正すべき課題に集中することが可能になります。 例えばアプリケーションの複数箇所で API が、500 Internal Server Error を返している場合でも、Issue Grouping（AI
- [アプリがダウン？今すぐ復旧！Sentry アップタイムモニタリングをご紹介](https://ichizoku.io/sentry/uptime-monitoring-now-ga/) - Article by: Sasha Blumenfeld, Gabriel Lopes https://youtu.be/Wf7-UHhPlE4?si=fGf3FjCTgXs7EkDM Sentry もダウンタイムとは無縁ではありません。実は私たちはかつて、誤ったマイグレーションによって自社のアプリケーションを停止させてしまったことがあります。重要なデータベーステーブルにフィールドを追加しようとしたところ、そのマイグレーションがテーブル全体をロックしてしまったのです。このテーブルは Sentry の動作に不可欠だったため、アプリ全体が停止してしまいました。ウェブサイトは読み込めず、データの取り込みも止まり… すべてが完全に止まってしまいました… 私たちはすぐに問題のクエリを特定して停止させましたが、もし主要なページにアップタイムモニタリングを設定していれば、もっと早く異常に気づけたかもしれません。これこそが、Uptime Monitoring を開発した理由です。 開発者が障害の原因を突き止めようと右往左往しているその1秒ごとに、ユーザーはページをリロードし、苛立ち、あるいは離れていきます。にもかかわらず、通常の対応プロセス（あるツールでアラートを受け取り、別のツールでログを調べ、何が起きたかを手作業でつなぎ合わせる）は遅くて苦痛を伴います。 私たちはトラブルシューティングの断片化が復旧を遅らせることを身をもって体験しました。だからこそ、障害が発生した瞬間に検知し、その修正に必要なコンテキストまで一か所で得られる仕組みを作ったのです。 Sentry の Uptime Monitoring は、単に「何かが落ちた」と通知するだけではありません。バグのあるコード、失敗したAPI、またはまったく別の原因かどうかを特定し、根本原因へと導きます。 Sentry Uptime Monitoringは、すべてのユーザーにご利用いただけるようになりました。すべてのプランに1つの無料モニターが含まれています。ユーザーが気づく前に、あなた自身でダウンタイムを検知しましょう。 Sentry の Uptime Monitoring Sentryはサイトの稼働状況を監視し、ダウンタイムが検出された際に通知します。 設定されたURLに対して60秒ごとに HTTP リクエストでヘルスチェックを行い、Web サービスを能動的に監視します。タイムアウト、DNS 解決エラー、不正なレスポンスなど、問題が検出されれば即座に通知されます。 9月末のベータリリース以降、すでに約10万件のアクティブなアップタイムアラートが作成されました。さらに、皆さまからの要望が多かった機能も多数追加し、より使いやすくなっています。 チェック履歴「すべてが崩れる前にサイトが正常に動いていた証拠があれば…」と思ったことはありませんか？今ならあります。チェック履歴を使えば、過去のアップタイムチェックを確認したり、パフォーマンストレンドを追跡したり、ダウンタイムと他の問題との関連を見つけ出すことができます。詳しくはこちら アップタイム問題詳細画面のUXを改善インシデント調査時により多くの情報が得られるよう、問題詳細ページを全面的に刷新しました。これにより、チェック履歴のタイムライン表示、すべてのアップタイムチェックのクイックビュー、関連リクエストのトレースビューにアクセスできるようになっています。 分散トレーシング対応アップタイムチェックが失敗したとき、探偵のように手がかりを追いかけたくはありませんよね。バックエンドサービスがSentry SDK でインスツルメントされていれば、リクエストのトレースをアップタイムチェックに自動的に関連付けます。そのため、必要なスパンや問題にすぐにジャンプでき、手作業で情報をつなぎ合わせる必要はありません。 地理的に分散されたチェック午前3時の誤検知ほど、気分を台無しにするものはありません。ダウンタイムの見逃しと不要なアラートの両方を減らすため、現在は複数のロケーションからアップタイムチェックを実施しています。異なる地域で3回連続してチェックが失敗した場合にのみ、ダウンタイムとして認識される仕組みです。そのため、本当に対応が必要なときだけ、アラートが届きます。 モニター設定の追加オプションすべてのサービスが同じではないように、モニタリングのニーズも一様ではありません。今では、各スタックに最適な形で、チェック間隔やタイムアウトの設定をカスタマイズできるようになりました。 よくあるダウンタイムの原因 — Uptime Monitoring がどう役立つか 壊れたコードのプッシュ 一見無害に思えた変更をプッシュした結果、システム全体が危機的状況に陥ったという経験を、誰しも一度はお持ちではないでしょうか。あるチームでは、非同期ジョブ内の単純な型エラーが原因で、購入処理用の配信システムがクラッシュし、あわや大惨事という事態になりました。1つのジョブだけが失敗するはずが、クラッシュによってキュー全体がブロックされ、以降のすべてのジョブが実行されなくなったのです。 そしておなじみの JavaScript の典型的なミスといえば、1ページを更新したつもりが、サイト全体を壊してしまうことです。ある開発者はそれを痛い形で学びました。テストではすべて問題なく見えていたにもかかわらず、ほんの小さな見落としが大きな混乱を引き起こしたのです。そのコードは、特定の要素が常に存在すると仮定し、すべてのページで実行されていました。nullチェックがなかったため、該当の要素が存在しないページは即座にクラッシュが発生しました。
- [【PHP】デバッグとログの方法](https://ichizoku.io/sentry/how-to-debug-and-log-in-php/) - Article by: Richard C. このガイドでは、PHP におけるエラーの仕組みと、それらをログ関数や Sentry を使って効率的にデバッグする方法を説明します。 このガイドの情報は PHP 8 に対して正確であり、将来の PHP バージョンの変更内容によっては、それ以降のバージョンにも適用できる可能性があります。 PHP のデバッグとロギングの前提条件 このガイドのすべてのコード例は、ホスト OS を問わず Docker 上で実行できます。Docker をお持ちでない場合は、こちらからダウンロードしてください。 すでに PHP がインストールされている場合、Docker は必須ではありません。ただし、Docker 上でコードを実行すると、以下のような利点があります。 Docker サンドボックス内で実行される悪意あるコードから、マシンを保護できます。 チーム内のすべてのプログラマーが、同じ IDE プラグインと PHP バージョンを使った共通の環境で作業できます。 物理マシンを再設定することなく、開発環境を本番サーバーと簡単に一致させることができます。 PHP の例外とエラー まずは、PHP における例外の仕組みを見ていきましょう。 エラーとはPHP 本体またはその拡張機能内で発生する内部的な問題です。例外とはPHP 開発者（つまりあなた）が書いた外部の PHP コードで投げたり捕捉したりできるオブジェクトの一種です。エラーと例外はどちらも Throwable オブジェクトです。 PHP が生成するすべてのエラーには型が含まれます。以下の PHP エラーの種類の一覧を見てください。それぞれの型の動作と、その原因となる状況について簡単に説明されています。 エラーには主に
- [Transformer ベースのテキスト埋め込みモデルで Sentry アラートを 40% 削減 ー ノイズを突破](https://ichizoku.io/sentry/how-sentry-decreased-issue-noise-with-ai/) - Article by: Tillman Elser, Josh Ferge Sentry は Issue Grouping（イシューグルーピング） を使用して、同一のエラーを集約し、重複するイシューの作成やアラートの送信を防止しています。 しかしこれまでにユーザーから最も多く寄せられていた不満の一つは、既存のアルゴリズムでは一部のケースで類似エラーが十分にまとめられず、Sentry が別々のイシューやアラートを生成してしまうことでした。これにより、開発者にとって不要な混乱、あるいは少なくとも煩わしさが生じていたのです。 この課題に対応するため、私たちは過去最大規模のイシューグルーピングアルゴリズムの改良を行いました。新しいAI搭載のアプローチでは、Transformer ベースのテキスト埋め込みモデルを使用し、新規イシューの生成数を40%削減しつつ、エンドツーエンドの処理レイテンシーを100ミリ秒未満に維持しています。 本記事では、このAIを活用したイシューグルーピングの開発・テスト・デプロイのプロセスについてご紹介します。 なぜ重複イシューが発生するのか Sentryの主要な価値は、ログを延々と読むことなく、必要な情報に素早くアクセスできる点にあります。新たな問題が発生すると、イシューフィード、メール、メッセージングプラットフォームなどを通じて開発者に通知されます。この一連のプロセスの鍵を握るのが、グルーピングアルゴリズムです。 経験豊富な開発者であれば、2つのスタックトレースを比較し、それらが同一の問題かどうかを判断するのはそれほど難しくありません。しかし、この判断プロセスを堅牢なヒューリスティック（経験則）として実装するのは容易ではありません。 たとえば、Reactアプリケーションでは、同じ「Invalid prop」エラーが異なるスタックフレームの順序で出現することがあります。あるときは validateProp(Select.js:42) に続いて Anonymous Component(App.js:123) が現れたり、逆の順番になったりすることもあります。同様に、Python では一見同じ KeyError が、コードのリファクタリングによりわずかに異なる行番号（たとえば line 145 と line 147）で発生することもあります。 さらに、非同期処理（async） はより一層複雑になります。たとえば Python の async 関数内で ValueError が発生した場合、それが asyncio/tasks.py を経由するか asyncio/runners.py を経由するかで、同じエラーが異なる実行パスを通って表面化することがあります。 私たちのグルーピングアルゴリズムは、これらのバリエーションを同一の根本原因として扱いつつ、明確に異なるエラーは正しく区別できなければなりません。しかも、Sentry は高速かつ効率的である必要があります。イベントの取り込み速度の低下や処理コストの増大は許容されません。 従来のグルーピング手法の問題点 従来のグルーピングアルゴリズムは、段階的に広いマッチング戦略を適用しながら、各エラーに対してユニークなフィンガープリント（指紋）を生成することで動作します。最も精度の高い手法であるスタックトレースの分析から始まり、アルゴリズムは各フレームを検査します。その際、アプリケーションコードとサードパーティライブラリを慎重に区別し、さらにプラットフォーム固有のルールに従って正規化を行います。 たとえば、Python のトレースバックと、難読化された JavaScript
- [Sentry のゲームエンジン対応でスムーズなプレイ体験を実現](https://ichizoku.io/sentry/maintain-smooth-game-play-with-sentrys-game-engine-support/) - Article by: Bruno Garcia Sentry はすでにご利用中のツールと直接統合され、Unity、Unreal Engine、Godot においてリアルタイムのクラッシュおよびパフォーマンスインサイトを提供します。 Unity：Sentry の Unity SDK により、C# のエラー、ネイティブクラッシュ、複数プラットフォームにまたがるパフォーマンスのボトルネックを検出できます。自動エラートラッキング、スクリーンショットの添付、オフラインキャッシュ機能によりデバッグが簡単になり、プレイヤーのデバイスがオフラインであっても重要なクラッシュデータを失うことはありません。（ドキュメント） Unreal Engine：PC、モバイル、コンソール向けに開発を行っている場合でも、Sentry の Unreal Engine SDK はエンジンレベルでクラッシュやエラーをキャプチャします。Unreal の組み込みクラッシュレポーターと統合されており、すべてのコンソールでシームレスに動作します。（GitHub） Godot：Godot を使用した開発においては、Sentry は専用の SDK を現在開発中です。これにより、作業フローを中断することなく、エラーの検出とパフォーマンスの向上が可能になります。（GitHub） ご使用のエンジンが何であっても、Sentry はプレイヤーに影響が及ぶ前に問題を特定し、修正する手助けをします。 プラットフォームをまたぐデバッグで足を引っ張られるべきではありません ゲームが PC、モバイル、コンソールなどさまざまな環境で動作する一方で、異なるプラットフォームにわたるクラッシュの追跡は非常に困難です。たとえば、Android では発生する問題が iOS では正常に動作することもあり、PlayStation 上でのクラッシュが開発マシンでは再現できない場合もあります。Sentry はあらゆるの荷プラットフォームにおけるエラーとパフォーマンスを一元的に監視することで、このような混乱を整理します。 すべてのプラットフォームを一元管理するダッシュボードWindows、macOS、Linux、Android、iOS、PlayStation、Xbox、Switch におけるクラッシュやパフォーマンスの問題を一か所で確認できます。散らばったログを探し回ったり、プレイヤーからの報告を待つ必要はありません。 すべてのエラーに完全なコンテキスト何が起きたのかを推測で済ませるのは終わりにしましょう。Sentry はスタックトレース、パンくずリスト、デバイス情報、さらに Unity や Unreal Engine のゲームにおけるスクリーンショットまでも提供し、クラッシュ発生直前の状況を正確に把握できるようにします。 より速く修正し、より賢くデプロイどのクラッシュが最も多くのプレイヤーに影響しているかを把握し、優先順位を付けて対応できます。また、リリースの健全性を追跡することで、問題の早期発見・対応が可能です。 ゲームのモニタリングとデバッグを始めましょう Unity や Unreal Engine
- [Trace Explorer でスパンからメトリクス、グループ、アラートを取得する方法](https://ichizoku.io/sentry/find-and-fix-performance-bottlenecks-with-sentrys-trace-explorer/) - Article by: Will McMullen どこかで、わずかに引っかかるアプリを開発した経験は、誰しも一度はあるでしょう。あるいは、どうしてもうまく最適化できないクエリに悩まされたことがあるかもしれません。Chrome の DevTools にあるネットワークウォーターフォールでは、その裏側で実際に何が起きているのかを完全に把握することは困難ですし、OTelによるトレーシング（正直に言えば、Sentryでのトレーシングも）も、やはり難解でした。 しかし本日から状況が変わります。私たちはトレーシングデータのための全く新しい Explore ビューをリリースしました。これにより、スパンデータを分類、絞り込み、並べ替えることで、パターンや具体的なトレース事例をこれまで以上に容易に見つけ出すことができます。 また、デフォルトまたはカスタムのスパン属性を使って、pXX（パーセンタイル）などのスパンベースのメトリクスを作成し、それをもとにアラートやカスタムダッシュボードウィジェットを構成することも可能となりました。 さらに、スパンをタイムスタンプ順に並べ替えることが、ついに可能になりました。ただし、これだけではありません。さっそく詳細を見ていきましょう。 ※この機能は Sentry のアーリーアダブタープログラムに参加しているすべてのセルフサーブ（自己登録）ユーザーに提供されています。まだ参加していない場合は、Sentry の設定画面から有効にしてください！ Sentry の Trace Explorer における新機能 アプリケーションがますます複雑化する中で、わずかなパフォーマンスの低下でも深刻なユーザー影響を引き起こす可能性が高まっています（最終的にユーザーの離脱という深刻な事態につながることもあります）。遅延の原因を簡単に特定できず、それを特定のサービス、エンドポイント、API、あるいはデータベース呼び出しに関連付ける手段がなければ、生のトレースデータを注意深く確認する（最悪の場合はログを手作業で確認する）必要があり、複数のツールに分断された断片的なデータを手動で追いかけることになります。 このような課題を解決するのが、新しい Trace Explorer です。スパンデータの活用方法が大幅に刷新され、以下の機能が追加されました。 スパンベースのメトリクススパン属性を集計し、p95(measurements.lcp) のようなメトリクスとして扱うことができます。これにより、パフォーマンスにおける境界ケースの検出や、大量の API ペイロードの追跡、さらにはアラートやダッシュボードの設定が可能となり、アプリケーションのシグナルを常に把握できるようになります。 クエリ可能なカスタム属性token_usage、region、cart_value など、アプリケーションに関連するカスタム属性をクエリおよび測定することが可能です。これにより、共通パターンを特定し、ユーザーにとって最も重要な体験に焦点を当てたアラートやダッシュボードを設計できます。 アクションにつながる Trace Explorerスタック全体にわたるトレースデータを迅速にフィルタリングおよびグループ化し、クエリを保存・共有することができます。「なぜチェックアウトページの読み込みが遅いのか？」といった問いに即座に対応できるだけでなく、どのユーザーが影響を受けているかもすばやく把握できます。 これらの機能は、パフォーマンスモニタリング・アラート・ダッシュボードの高度なセットアップを素早く構築できるように設計されており、トレースデータの価値を最大限に引き出すことができます。しかも、最小限のコストと構成で実現可能です。 技術的に見ても非常にスマートな仕組みですが、実用面においてはさらに高い効果を発揮します。ベータ版で多数の企業と連携を行う中で、以下のような代表的なユースケースが明らかになりました。 CDN画像のパフォーマンス分析image_url や cdn_provider のような属性を付加し、プロバイダー別に画像の遅延を並べ替えて分析できます。事前のメトリクス変換や処理は不要であり、クエリ実行時に動的に処理できます。 AI消費量の追跡APIコール数、トークン使用量、モデル名などを測定可能です。スパイクが発生した際には、対象のトランザクション、ユーザー、環境、リポジトリを正確に特定できます。 ECサイトにおけるチェックアウト追跡cart_value や payment_method といった属性を用いてチェックアウトフロー全体を追跡できます。これにより、高額な取引でパフォーマンスが遅延しているケースを特定し、即座にトリアージすることが可能です。 新しい Trace Explorer でスパンメトリクスを設定・活用する 1：重要な箇所にコードを計測挿入する（インストゥルメントする） Sentry
- [Javaにおけるロギングとデバッグのガイド](https://ichizoku.io/sentry/a-guide-to-logging-and-debugging-in-java/) - Article by: Abdul D なぜロギングとデバッグが重要なのか？ プログラムの開発中、プログラムの実行フローを追跡し、コード内の問題を特定するために、単純な println() ステートメントを使っているかもしれません。しかしプロジェクトが大きくなり、複雑になるにつれて、プリント文はすぐに散らかってしまいます。プログラムの実行を追跡するためのより良い方法はロギングです。ロギングはアプリケーションの動作を一貫して整理された方法で追跡する手段を提供し、問題を体系的に特定し、解決できるようにします。 このガイドでは、Java でのロギングの設定方法、基本的なデバッグツールを効果的に使用する方法、そして安定した保守可能なアプリケーションを作成するためのベストプラクティスについて探ります。 また、Sentry が Java アプリケーションでエラーを監視し管理する手助けをどのようにするかについても見ていきます。基本と合わせて、高度なテクニックを理解することで、Javaプロジェクト内の問題に自信を持って取り組むための準備が整います。 Java でロギングを設定する方法 もしかするとコードのロギングとデバッグのために System.out.println() を使用したことがあるかもしれません。 次のように出力されます。 Debugging: Starting the programDebugging: Result is 8 このようなコンソールロギングは、小規模なプロジェクトや簡単なテストには役立つことがありますが、いくつかの制限があります。保存されていないコンソールログはプログラムが停止すると消えてしまい、何が起こったのかの履歴を保持することが難しくなります。また、ログメッセージを重要度別に分類することができず、出力結果で重要な問題を見逃しやすくなります。 Javaでの基本的なロギングは、組み込みの java.util.logging パッケージを使用することで実現できます。この組み込みフレームワークを使用すると、アプリケーション内で情報メッセージ、警告、エラーなど、さまざまなイベントを簡単に記録して出力できます。 java.util.logging を使用すると、各メッセージの重要度を示すためにログレベルを指定できます。 SEVERE：アプリケーションが正しく動作しない可能性のある重大なエラーを示します。 WARNING：注意が必要な潜在的な問題を示します。 INFO：アプリケーションの実行進行状況に関する一般的な情報を提供します。 CONFIG：設定関連のメッセージを示します。 FINE, FINER, FINEST：デバッグ目的で詳細な情報を提供します。 これらのログレベルは次の構文を使って使用できます。logger.("") ロギングを有効にするには、module-info.java ファイルに以下を追加する必要があるかもしれません。 requires java.logging; 以下はロガーを設定し、異なるレベルでメッセージをログに記録する方法です。 以下が出力されます。 ロギング例の出力 ログメッセージがタイムスタンプで記録され、ログステートメントが呼ばれたクラス名とメソッド名が含まれている点に注目してください。この情報は、複雑なアプリケーションでバグを追跡する際に非常に貴重です。 Javaでのログレベルの設定 上記の例では、INFO、WARNING、SEVEREメッセージのみがログに記録され、CONFIG と FINE メッセージは記録されていないことに気付くかと思います。 これはデフォルトのログレベルが
- [Sentry と Pinia との組み合わせで、Vue と Nuxt のエラートラッキングを強化する方法](https://ichizoku.io/sentry/sentrys-pinia-integration-for-vue-and-nuxt-error-tracking/) - Article by: Steven Eubank 本番環境で問題をデバッグする際に大切なのは、その瞬間のコンテキストです。 Sentry はすでにスタックトレースやパンくずリスト、ユーザー情報などの豊富なエラーデータを提供していますが、エラーが発生した時点でアプリケーションがどんな状態だったのかまでが分かれば、再現手順や修正方法が迅速に得られ、リリースに大きく役立ちます。 Sentry の Pinia 統合は、まさにそれを実現してくれる機能です。エラーが発生した時点で Pinia の状態を自動的にキャプチャするため、Vue または Nuxt アプリケーションでどんな問題が発生したのか詳細まで把握できます。 それでは、Vue および Nuxt アプリケーションで実際に導入する手順を確認していきましょう。 Sentryでショッピングカートの不具合も素早くデバッグ Pinia のパイナップルロゴ🍍にインスパイアされた「Pineapple Paradise」というオンラインストアを例に挙げてご紹介します。 この Vue アプリでは、Pinia を使ってショッピングカートの状態を管理しています。 オンラインストアが期待通りに動作する方法を模倣していて、ユーザーは商品を閲覧し、ショッピングカートに追加します。アプリの状態管理は全て Pinia が担っています。 以下はショッピングカートの状態を管理するコードのシンプルな例です。 Vue アプリに Sentry と Pinia の統合を追加する Sentry のPinia統合をセットアップするのは、他のフレームワークと同様にとても簡単です。 main.js ファイルで、Sentry Vue SDK をインポートし、必要なオプションで init メソッドを呼び出し、次に pinia.use(createSentryPiniaPlugin()) を呼び出すように追加すれば完了です。 以下はその例です。 アプリの状態から不具合のコンテキストを見つける 例えば今、ユーザーが好きなパイナップル関連の商品でチェックアウトしようとした瞬間、サイトがクラッシュして購入を諦めてしまったとします。 このとき関連するすべてのコンテキストと共にエラーイベントが Sentry に自動送信され、次のような情報が記録されます。
- [モバイル向けセッションリプレイが一般公開！ユーザー体験を簡単に改善する方法を徹底解説](https://ichizoku.io/sentry/session-replay-for-mobile-is-now-generally-available-see-what-your-users-see/) - Article by: Jasmin Kassas, Sarah Guthals モバイル向けセッションリプレイがついに一般公開されました。 セッションリプレイの偉大さについて大袈裟に語ることもできますが、今回は趣向を変えて、A…I…があなたのために一句詠みます。 画面が固まる 開発者はため息 リプレイ明かす犯人は…… .addListener 忘れていた 俳句になっているかどうかはさておき、要するに Sentry はユーザーの操作を動画のように再現できるため、どのデバイスで問題が発生しているのか、他の端末を使って再現確認しなくても、不具合の箇所や体験が途切れているポイントをすぐに確認できます。 今どき iPhone 12 Mini が家に転がっている人なんてそうそういませんよね？少なくとも、私たちの手元にはありません。あなたのところはいかがですか？ さて、本題に移ります。もし実際の問題をセッションリプレイでどのようにデバッグできるのか知りたい方は、この先をご覧ください。そうでない場合は、iOS、Android、Flutter、React Nativeのセットアップ方法をまとめたドキュメントをぜひご覧ください。 セッションリプレイでどう解決するのか 奇妙なバグの通知を受け取り、クラッシュダンプを見てもなぜユーザーがその状態に至ったのかわからなかった… 開発者であればそんな経験はよくあるでしょう。 その度に状態を把握するためランダムなログを無闇に差し込み、それを再リリースしてユーザーにアップデートを強制するも的が外れてまたやり直し… そんなことを繰り返していませんか？ しかしセッションリプレイならそんな手間を省くことができます。エラーや操作の流れも含めて確認することができるため、ユーザーがエラーに至るまでに何をしていたのかが正確に確認できます。 ここからは、過去6ヶ月間のベータ期間に Sentry のお客様が実際に体験された事例をご紹介していきます。 モバイルアプリの状態を正確に把握する モバイルアプリは実にさまざまな形式があり、その多くは複雑なUIフローや状態を保持しています。セッションリプレイを使用することで、アプリがどのような状態なのかを正確に把握することができ、問題の原因になっているUIフローを見つけることができます。 以下の画像のように、バックエンドのエラーも含めて全体像を掴むのにとても役立ちました。 セッションリプレイがなければ、問題が起きた時の再現手順を特定するのに不要な手間がかかります。これは複雑な条件（手順や状態）をデバッグする際に特に役立ちます。 バックエンドのエンドポイントエラーにも対応 ユーザーがどのような操作をしていたか分からない状態で、サーバーのエラーをデバッグするのは本当に骨が折れます。 しかしセッションリプレイを使えば、エンドポイントに到達するまでのユーザー操作をそのまま見ることができます。またタイムラインビューを使うことでサーバーエラーが発生した正確なタイミングに一瞬でジャンプすることもできます。 とあるお客様の事例を挙げると、アプリがフォアグラウンドに戻った際にプロフィールを更新しようとして、400エラーが発生していたことがありました。 原因はその時点でユーザーがログアウトしていたからでした。修正はシンプルで、今では AppState イベントを監視しユーザーがログアウト状態ならすぐにログイン画面へリダイレクトするように修正しています。 モバイル特有の問題も見逃さない セッションリプレイのパンくずリストを使えば、ユーザーの操作履歴とともにデバイスに関する重要な情報も取得できます。どの瞬間に、どのような操作や理由によって問題が起きたのかを正確に特定します。 例えば「コードに問題はなかったのに、ネットワークが突然切れてオフラインになったこと」が原因だった（調査する開発者にとっては、これほど最悪なケースはありません）としても、セッションリプレイを見れば一目瞭然です。 このパンくずリストは、従来のログでは見えない部分に光を当ててくれる貴重な手掛かりになります。 モバイル向けセッションリプレイ導入手順 セッションリプレイをアプリに組み込むためのステップは以下の通りです。
- [【Sentry Profiling】Autofix の遅延問題をどのように解消したのか徹底解説](https://ichizoku.io/sentry/how-profiling-helped-fix-slowness-in-sentrys-ai-autofix/) - Article by: Rohan Agarwal プロファイリングと聞くと「インフラコストをスケールに応じて最適化するためのわずかな節約に役立つもの」という誤解を抱いている方が多くいらっしゃいます。いわゆる「ミリ秒単位での削減が全て」というアプローチだと思っていないでしょうか。 しかし実際はそうではありません。私たちは自社のプロファイリングツールを使用し、ユーザーインタラクションを各セッションにおいて数十秒単位の時間短縮を可能にしました。数学がお好きな方のために補足すると、それは「重要なミリ秒」どころか、4桁も大きく異なる数値でした。 この記事では、私たちがどのような課題に直面し、何を発見し、どのようにして解決に至ったのか解説します。そしてプロファイリングが単なるミリ秒の削減にとどまらず、なぜパフォーマンスや顧客体験の向上に欠かせない存在なのかについてもご紹介します。 処理速度は、開発者にとってもユーザーにとっても重要 私たち Sentry 開発チームは、デバッグワークフローの改善に一貫して取り組んできました。 その中で「生成AIを活用するなら、 Autofix というツールを作るのが最適だ」と考えました。Autofix は問題の詳細とコードベースを密接に統合させ、課題の文脈を理解した上で解決策を導き出すツールです。完全に独立して動くのではなく、開発者と一緒に作業しながら根本原因を特定し、正確なコード修正を提案するという少しユニークなアプローチを取っています。 Autofix の本来の目的は「デバッグを速くすること」でしたが、実際に使用してみるとどうにも遅いと感じていました。特にコールドスタート時は鈍く、通常よりも10〜20秒以上も余計に時間を要し、こうした遅延は私たち開発チームだけでなく、初期導入されたお客様にも影響を及ぼしていました。 このままでは Autofix を世に出しても中途半端なものになってしまうのではないかという危機感が高まっていました。何としてもローンチまでにパフォーマンス課題を解決しなければなりません。とはいえ、AI駆動のワークフローをデバッグするのは困難です。 問題はサードパーティのLLMプロバイダーからの遅延応答が原因なのだろうか。だとすると、設計そのものを変更しなければなりません。それともタスクキュー（Celery）が非力なインフラでボトルネックになっているのか… 仮説を確かめるには大掛かりな調査が必要となり、もし仮説通りだったとしても、その対応にはアーキテクチャ全体を見直すような大規模改修につながります。いずれにしても大変です。 そこでふと考えました。 「もしかすると、私たちがすでに持っている可視化データの中にヒントがあるのでは……？」 そこで登場したのが Sentry Profiling です。早期導入ユーザーの実際のデバイスから実行データを分析することで、思いがけない2つのボトルネック、「冗長なリポジトリ初期化」と「インサイト生成中の不要なスレッド待機」を明らかになりました。これらに対し、キャッシュの導入とスレッドの最適化を行ったことで、実行時間は数十秒短縮され、Autofix は大きく向上しました。しかも、アーキテクチャには一切変更を加えていません。 プロファイルとは？どのように活用すればいい？ もしすでにご存知であれば、ここは読み飛ばしていただいて構いません。念のため、初めての方に向けて簡単に説明します。 プロファイリングとは、関数の呼び出しや実行時間、リソース使用状況などの情報を本番環境でリアルタイムでキャプチャし、実際のユーザー体験に影響しているCPUやブラウザレベルのパフォーマンス課題を特定するための手法です。 CPUプロファイリングはCPUサイクルがどこで使われているか追跡し、非効率な関数や不要なループ、重たいブロック処理などを見つける際に役立ちます。またブラウザプロファイリングは、主にフロントエンドに焦点を当て、ページの読み込みやレンダリングの遅延、長時間実行されているレンダリングタスクなどの情報を取得することが可能です。最後にモバイルプロファイリングは、ネイティブおよびハイブリッドアプリの画面表示などのパフォーマンスを分析します。 これらのデータは全て「フレームグラフ」として視覚的に表示され、時間経過とともに変化するコールスタックの様子を確認できます。最初は少し慣れが必要になるかもしれませんが、以下のように読み取ることができます。 X軸（時間）：コード実行のタイムラインを示します。各ブロックの幅は、関数呼び出しの時間の長さを示します。 Y軸（コールスタックの深さ）：関数呼び出しの階層を示し、コードレベルでの関数間の親子関係を示します。 カラーコード：Sentry ではアプリケーションコード、システムコード、シンボル名、パッケージなどに色分けがされており、それぞれを直感的に識別できます。 さらにプロファイルは分散トレースと組み合わせて表示することもできるため、ブラウザ、クライアントCPU、ネットワーク呼び出しの流れをひと目で把握できるようになります。Sentry では個別のプロファイル（単一トランザクションのプロファイル）、集約されたプロファイル（平均的な処理の傾向）、差分プロファイル（コードの変更前後の比較）といった形式でパフォーマンス問題を素早く特定できます。 プロファイリングを有効にするには、アプリケーションの起動時にSDKをできるだけ早く初期化し、profiles_sample_rate オプションを 1.0 に設定することでサンプリングされたトランザクションをキャプチャできます。 例えば、Pythonアプリでは次のように設定します。 問題1：コールドスタートに時間がかかる 問題 Autofix の目的は、アプリケーション内のバグについてできるだけ早く開発者にインサイトを提供することです。しかしルートコード分析を行ったり、コード修正を提案したりするたびに数秒もの明確なスタートアップの遅延が発生し、その後も長時間の処理が続いていました。 これでは最先端のAIエージェントとしては動作が重く、時代遅れに感じられてしまいます。この状況が改善されなければ、開発者はワークフローへの不満を抱き、Autofix が低く評価されてしまう恐れがありました。
- [【Visual Studio App Centerが廃止】次に Sentry を勧める理由を解説](https://ichizoku.io/sentry/visual-studio-app-center-retirement-why-sentry-is-your-next-step/) - Article by: Sarah Guthals Visual Studio App Center が廃止されることは以前から知っていました。正式な廃止日が2025年3月31日と発表され、いよいよカレンダーを見ると2025年。そろそろ App Center の代替案を選定し、他のツールへの移行準備を本格的に進めるべき時期が迫りました。 *なお、Microsoft は App Center Analytics & Diagnostics 機能に限り、製品サポートを2026年6月30日まで延長する予定です。ただし App Center の他の機能については 2025年3月31日で提供が終了します。移行には綿密な計画と手間がかかりますので、早めに対応を進めることをおすすめします。 この記事ではスムーズな移行に役立つガイドをお届けします。他の参考リソースへのリンクも盛り込んでいますので、ぜひご活用ください。 Visual Studio App Center からの移行方法 Visual Studio App Center にはモバイル開発者がよく利用していた5つの主要な機能がありました。それはクラウドベースのビルド、デバイステスト、配布、コードプッシュ、そして分析＆診断です。 これらの機能にはそれぞれ推奨される代替ツールがありますが、チームにとってどのツールが最適かを慎重に見極めることが重要です。機能の違いはもちろん、ツールの互換性、API や拡張性、さらにはユーザーエクスペリエンス（UX）も移行のしやすさを大きく左右します。 以下では、App Center の各機能ごとに推奨される代替ツールをご紹介します。 クラウドベースのビルド：App Center では、iOS や Android アプリをクラウド上でビルドいる機能が提供されていました。 代替として、Ionic をおすすめします。Ionicは、Cordova や Capacitor、React Native といったフレームワークで開発されたアプリを複雑な手順を踏むことなく、iOS および
- [SentryのRollback、Hack Week発のプロジェクトが本番稼働へ](https://ichizoku.io/sentry/taking-sentrys-rollback-from-hack-week-project-to-production/) - Article by: Malachi Willey ❗❗もしあなたが Sentry を使っていて、今が2024年なら、今すぐ読むのを止めて、まずは rollback.sentry.io にアクセスしてみてください。自分専用のRollbackが手に入ります！ ほんの数週間前、私たちは Sentry Rollback という機能をリリースしました。 これは Sentry で初めてとなる「年次レビュー体験」です。 イメージとしては、Spotify Wrapped（Spotifyが毎年行っているユーザーの音楽の好みをハイライトする機能） の開発者版のようなもので、Sentry を通して過ごした1年を振り返ることができる独自の機能です。 見た目はスタイリッシュで、ちょっと（というか、かなり）皮肉も効いています。あなたの成果をしっかり称えながら、ついでに失敗も軽くあざ笑います。成功というのは、失敗の上に成り立ちますからね。 Rollback の起源は少しユニークです。最初は社内向けに「何か面白くて笑えるものを作ろう」という軽い気持ちからスタートしました。しかしそれが、気が付けば本格的なプロジェクトに成長していました。今回は、その歩みをご紹介していきます。 クエリ結果が得られないことに何度も悩まされたのではないでしょうか。私たち自身もその例外に何度も頭を抱えた結果、ついに修正することに踏み切りました。 始まり：Rollback のアイデア誕生 毎年、Sentryでは社内ハックウィークを開催しています。これは Sentry 社員全員が普段の業務から離れ、自分の「作りたいもの」に自由に取り組む1週間です。ルールは「何を作ってもOK」ただ一つ。「こんなものがあったらいいのに」と思ったら、それを作るだけです。 多くのハックウィークのプロジェクトは、その週が終わると役目を終えますが、中には社内で使い続けられるものもあります。そして時々、本番環境に飛び込すプロジェクトが生まれることがあります。Sentry Rollback はその一つでした。 チーム編成から始まった Rollback ほとんどのハックウィークのプロジェクトは、エンジニア同士が数人集まってチームを組んで進めます。同じチーム内で完結することも少なくありません。 しかし、Rollback は違いました。エンジニアリング、プロダクト、マーケティング、デザイン、さらにはセールスコピーまで、社内全体から人が集まり、Sentry 全体で取り組む「全社プロジェクト」となったのです。 多様な視点が加わったことで、Rollback はごく初期の段階から「まるで本物のSentryの製品（TM）」のような完成度を見せはじめました。なぜなら、必要な要素がしっかり揃っていたからです。 出荷とクラッシュ、そして再スタート… Rollback Rollback を他の年次レビューと差別化するため、まず取り組んだのは名前を決めることでした。私たちはあまり堅い印象になりすぎないようにしているので、ちょうどいいユーモアのある名前が必要だと考えました。 利用者ターゲットの99%がエンジニアのため、開発者の心に響く名前でなければなりません。Sentry Replay、Sentry Shipped、Sentry Wreckedなどのアイデアが出ましたが、最終的に「Rollback」に決定しました。 「Rollback」という名前は、まるで過去に戻って1年分のバグを再体験するようなイメージを呼び起こします。開発者がひと目見て、直感的に理解できるネーミングです。 今年、あなたも一度は“ロールバック”したのではないでしょうか？私たちはもちろんしましたよ！ MVPを最速で作ることから始める ハックウィークの限られた数日間で、Rollback のような体験を作るのは簡単なことではありません。 プロジェクトはチームを跨いで関わる部分も多いため、綿密な進行管理が必要でした。プロダクトマネージャーは、優先順位を理路整然と決め、初期のデザインやワイヤーフレームといった障害になりそうな要素を排除していきました。その結果、対象スコープも最小限になりました。 ハックウィーク版では、Sentry の従業員のために動作することだけに焦点を当てました。複雑なインフラ構成は避け、データベースも使わず、パフォーマンス最適化に悩む必要性もなくしました。ひたすらコンセプトの実証だけに集中し、クスッと笑える動作を目指しました。 ハックウィークの優勝者
- [Sentryを活用したクエリのレート制限のデバッグ方法について](https://ichizoku.io/sentry/debugging-query-rate-limiting-in-sentry/) - Article by: Rachel Chen Snubaは、Sentryを本番環境で動作させるための中核となるイベントデータの保存およびクエリサービスです。 これまで内部でレート制限を行っていたため、その挙動が見えづらく、サポート対応に時間がかかるケースがありました。Snubaのコードに精通していない限り、こうした詳細にはなかなか気づけません。 しかし、実際に顧客からの問い合わせを整理していく中でよく見かける問題が1つありました。それが「RateLimitExceeded」です。 クエリ結果が得られないことに何度も悩まされたのではないでしょうか。私たち自身もその例外に何度も頭を抱えた結果、ついに修正することに踏み切りました。 SentryがRateLimitExceededの問題を抱えていた理由 Sentry では、社内で運用している複数の ClickHouse クラスタを利用しています。 これらは、UI や API のデータ提供を担っています。また、ClickHouse リソースをどのように割り当てるかを決定するために「ClickHouse 容量管理システム」の中で割り当てポリシーのコレクションを用意しています。 Snuba にクエリが送信されると、容量管理システムがこれらのポリシーを適用し、クエリを受け入れるか、拒否されるか、あるいはスロットル（処理の一時的な遅延）するかを判断します。 Sentryが全体のレート制限をどのように改善したか まずレート制限の仕組みをより明確に把握するため、Sentry のエンジニアたちがクエリ状況を確認できる「Snubaカスタマーダッシュボード」をインフラツール内に構築しました。 そしてこの取り組みによって、エラー関連のクエリが 96.628% の成功率であることがわかりました。 しかし、単に成功率を知っているだけでは、根本的な解決にはなりません。Datadog のようなインフラ監視ツールは非常に有用ですが、デバッグには向いていないためです。 そこで「私たちはそもそもデバッグツールを作っているのだから（それが Sentry です 😃）、この情報をSentry上で見られるようにしよう」と考え、実際にそうしました。 ステップ1: 開発者ワークフローの改善 まず Sentry に新機能を追加する前に、必要な情報が揃っていることを確認しました。 最初に Snuba カスタマーダッシュボードを使って全体の概要（何が起きているのか）を把握し、次に Sentry のトレースビューページでレート制限されたクエリの詳細（なぜ起きたかとどのように起きたか）に掘り下げます。 以下は、api.project-events リファラーから、拒否されたクエリを含むすべてのトレースを取得する例です。 ステップ2: クエリが拒否される前に「警告ゾーン」で知らせる
- [アプリを高速化し、インフラコストを削減！サーバーサイドキャッシュの活用術](https://ichizoku.io/sentry/using-server-side-caching-to-speed-up-your-applications-save-on-infra-costs/) - Article by: Will McMullen もし100ミリ秒未満の応答時間に驚いたことがあるなら、その背後には「キャッシュ」がある可能性が高いでしょう。 キャッシュは、システムのパフォーマンスを支える縁の下の力持ちです。よく使用されるデータを保存しておくことで、データベースやAPIへのアクセスを減らし、アプリの応答速度をミリ秒単位で短縮します。 今回はキャッシュがどのように機能するのか分解し、代表的な活用事例をご紹介していきます。 キャッシュとは？ キャッシュは、データの通り道に置かれる短期的な記憶装置のようなものです。よくアクセスされる情報を、時間のかかるデータベースや外部APIから毎回取り出すのではなく、すぐ使えるように一時的に保存しておきます。 動作の流れはとてもシンプルです。 最初のアクセス（キャッシュミス） まずアプリは指定されたキーに対応するデータがキャッシュにあるかをチェックします。なければ、アプリは時間やコストのかかる処理（たとえばデータベースクエリ）を実行し、その結果をキャッシュに保存してからユーザーに返します。 2回目以降のアクセス（キャッシュヒット） 次回、同じデータが必要になった場合は、データベースを介さずキャッシュから直接取得します。このルートは非常に高速で、ユーザー体験が一気に向上します。 キャッシュはスピード感のあるUXを実現したり、インフラの負荷を軽減したりするうえでとても頼れる存在です。理論上、どのようなデータもキャッシュできますが、特によく使われるのは以下のようなものが挙げられます。 コストの高いクエリの結果 「ユーザーXのカート情報」や「特集商品」のように、何度も同じ結果が返されるデータ 計算されたメトリクスや分析結果 毎回計算し直す必要がなく、元データが更新された時だけ再計算すれば良いデータ 静的アセット 画像やフォント、CSSなど、普段は変更されないものの頻繁に使用されるデータ それではキャッシュを設定して、実際にパフォーマンスのメリットを確認してみましょう。 PythonでシンプルなRedisキャッシュを設定する 「キャッシュと言えば Redis」と呼ばれるほど、世界中の開発者に使われている信頼性の高いオープンソースのツールです。 私が気に入っている説明は Simon Willison のワークショップで耳にした『Redis は素晴らしい小さなサーバー』というひと言です。Redis はインメモリで動く Key-Value 形式でデータを保持します。 またデータベースやキャッシュ、メッセージブローカーとしても使用されています。とにかく高速で効率的なことが特徴で、リアルタイムに動作することが求められるアプリケーションにピッタリです。 今回はこの Redis を使って、データベース呼び出しをキャッシュかすることに焦点を絞ります。Redis の導入で、たとえ開発用のノートPCでも 1秒あたり数十万件の処理をミリ秒単位で処理できるようになります。 メモリ上に保存するため高速ですし、キャッシュだけでなく永続性や原子性のあるストレージとしても活用できます。主要な SQL や NoSQL の負荷を軽くし、全体のパフォーマンス改善にもつながるというわけです。 Redis を導入するためにデータベースを移行したり設定を大きく変えたりする必要はありません。Pythonを使って PostgreSQL のキャッシュ層として
- [【VSCode + Sentry】Pythonのデバッグを快適にする方法](https://ichizoku.io/sentry/debugging-python-with-vs-code-and-sentry/) - Article by: David Y. Sentry は開発者がバグのあるコードを迅速かつ効果的に修正できるよう支援しています。この記事では、VSCode と Sentry Python SDK を活用し、Python コードをデバッグするための中級から上級レベルのテクニックを幅広く紹介します。 Python デバッグの例 デバッグを行うには、まずバグのあるコードが必要です。 そこで今回は短い Python スクリプトを用意しました。このスクリプトは、外部の JSON ファイルからユーザーデータを取得し、内部のデータ構造に格納するといったものです。 こうしたコードは、メールニュースレター管理ツールにユーザーアカウントをインポートする際にも利用されることがあります。 このコードは、小規模で完璧にフォーマットされた users.json を使用した単純なテストケースで正常に動作します。しかし、管理されたテスト環境を離れると例外が発生する可能性が出てきます。考えられる失敗パターンは以下のとおりです。 users.json が存在しない users.json に無効な JSON が含まれている 一部のユーザーに必要なフィールドが欠落している 一部のフィールドのデータ方が想定と異なる 以下のセクションでは、さまざまなデバッグ環境を使用し、これらのケースを調査していきます。 実際に試しながら進める場合は、上記のコードをコピーしてシステム上の空のディレクトリに users.py というファイル名で保存してください（users.json は後ほど作成します）。 VSCode で Python をデバッグする方法 VSCode は、Python を含むさまざまなプログラミング言語で使用できるグラフィカルなデバッグインターフェースを提供しています。 まだ VSCode をインストールしていない場合は、こちらでインストールファイルと手順を確認できます。 以下では、VSCode のデバッグ機能をセットアップし、Python スクリプトをデバッグする方法
- [Next.jsのデバッグ手法はどうしたらいい？開発から本番公開までの実践的ヒントを解説](https://ichizoku.io/sentry/next-js-debugging-tips-and-techniques-from-dev-to-prod/) - Article by: Matt Henderson, Sarah Guthals デバッグ… それはすべての開発者にとって必要不可欠なスキルです。Next.js を使って動的で高性能なアプリケーションを構築する際、Chrome DevTools や console.log() だけでは対応しきれない場面もあります。またアプリケーションが成長していくにつれて、より効果的で体系的なデバッグ手法が求められるようになります。 今回の記事では Next.js のデバッグワークショップで紹介した実践的なヒントを交えながら、開発段階から本番環境まで役立つデバッグ手法をご紹介します。 今回は Next.js に特化した内容ですが、React アプリのデバッグについてもこちらで紹介しています。ぜひご一読ください。 効果的な Next.js のデバッグツールとテクニック デバッグはエディタでコードを書きながらローカル環境でテストしている段階から始まります。 まずはそこから解説していきます。そして最終的には、本番環境にデプロイされた後、開発チームではなく実際のユーザーがバグを発見するような場面でのデバッグ方法まで理解できるようになるはずです。 1. React Developer Tools を活用する Next.js は React を基盤としたフレームワークであり、幸いなことに React Developer Tools を使えば、コンポーネントの階層や props、state を直感的に確認できます。React DevTools を活用すると、以下のようなことが可能になります。 ・コンポーネントツリーを視覚的に把握できるため、動的ルーティングやサーバサイドレンダリング（SSR）を使用しても階層構造を理解しやすくなる ・リアルタイムで state や props を解析、編集を行える ・再レンダリングのトラッキングが可能になる ・React Suspenseの遅延読み込みの挙動を可視化できる
- [GitHub Actionsを使った Sentry Unreal Engine SDKの構築](https://ichizoku.io/sentry/building-the-sentry-unreal-engine-sdk-with-github-actions/) - Article by: Ivan Tustanivskyi ゲーム開発者にとって、シームレスなプレイヤー体験を提供することは非常に重要です。しかし、予期しないクラッシュやパフォーマンスの問題がゲームの評判を損ない、プレイヤーのエンゲージメントを妨げることがあります。 この問題に対処するためには、複数のプラットフォームで積極的なエラーモニタリングが必要です。 幸い、SentryはUnreal Engine専用に設計された強力なSDKを提供しており、開発者がデバッグとパフォーマンスの維持を効果的に行えるよう支援します。 しかし、Unreal Engine用のSDKを構築するのは容易ではありませんでした。設計時には、Unreal Engineの独特なアプリケーション構造やゲーム開発者が直面する課題を考慮しました。しかし、Sentryを真に効果的にするためには、開発中のエディタモードと製品版のゲームをさまざまなプラットフォームで動作させるために、エンジンとシームレスに統合する方法を見つける必要がありました。 本記事では、ゲーム開発者向けのデバッグソリューションを構築する際の課題と機会について解説します。以下のような方々にとって有益な内容となっているはずです。 Unreal Engine用のSDKを開発したい方 カスタムエンジンのプラグインにサードパーティライブラリを統合したい方 反復的なタスクを自動化し、開発ワークフローを効率化したい方 次世代の対策ゲームを支えるプラットフォームの構築方法に関心がある方 また、SentryのUnreal Engine SDKがサポートする以下のプラットフォーム向けのビルドとテストについても紹介します。 Android iOS macOS (x64 / arm64) Linux (x64 / arm64) Windows (x64) 注意: 本記事ではSentryのUnreal Engine SDKのすべての機能を説明していますが、フル活用するにはGitHubのリリースページからSDKをインストールする必要があります。Epic GamesのFab（旧Marketplace）で提供されているバージョンには一部制限があります。詳細については公式ドキュメントをご覧ください。 SentryのUnreal Engine SDKのアーキテクチャ設計 SentryのUnreal Engine用SDKは、ゲーム内クラッシュをキャプチャするためのクロスプラットフォームソリューションです。 複数のSentryネイティブSDKの上に構築された抽象化レイヤーとして機能し、統一されたC++/Blueprints APIを提供します。これにより、プラットフォーム固有の低レベルな実装に煩わされることなく、Unrealプラグインの設定に集中できます。 Sentry Unreal SDKには、ゲームビルド完了時にデバッグ情報ファイルを自動アップロードするSentry CLIも含まれています。 これらのデバッグファイルには、オリジナルの関数名、行番号、ファイルパス、スタックトレース、コールフレーム情報（CFI）などが含まれ、Sentryはこれらの情報を利用して、問題解決のための有益な洞察を提供します。 さらに、Unreal SDKはUnreal専用に構築されているため、SDKを導入するとAPIを呼び出し、エディタ内の自動インストゥルメンテーション機能を利用できます。
- [インデックス不足でDBが遅い… Sentryで問題を見つけ修正する方法とは？](https://ichizoku.io/sentry/missing-indexes-are-slowing-down-your-database-heres-how-to-find-and-fix/) - Article by: Will McMullen 遅いデータベースクエリは、開発者にもユーザーにも悪影響を及ぼします。 リソースを浪費し、テストの遅延を引き起こし、動作が重くなることによってユーザーは不満を抱きます。しかし、多くの場合、驚くほど意外な解決策があります。それがインデックスです。 ここでは、インデックスの仕組みと、その活用タイミングについて解説します。 スキーマの種類を問わず役立つ内容です。 すでにインデックスの基本と使い方を理解していて、遅いクエリの監視やデバッグ方法を知りたい場合は実践例をご覧ください。 インデックスとは？ インデックスとは何かご存じですか？ 簡単にいえば、データベースの「GPS」のようなものです。 インデックスがないと、データベースは全ての行（レコード）を1つずつチェックしながら探し回らなければなりません。そうするとまるで迷子の観光客のように、目的地へ辿り着くまでに時間がかかってしまいます。 しかし、インデックスがあれば無駄な回り道をすることなく、一直線でユーザーの目的地（ここでいう処理）へ辿り着くことができます。 インデックスを技術的に解説すると、カラムの値を行にマッピングする小さなデータ構造のことを指しており、検索を高速化する役割を果たしています。 例を見てみましょう。 ユーザーテーブルやコレクションからメールアドレスを検索する場合、SQLデータベースではメールカラムに対するインデックスを次のように作成できます。 MongoDBやその他のNoSQLのドキュメント型データベースも、同様の方法でインデックスを活用します。例えば以下のコードのように、MongoDBではusersコレクションのemailフィールドを検索する際にインデックスを利用できます。 インデックスは決して魔法のように万能ではありません。アルゴリズムの観点では、まるで魔法のように感じられることがあります（バイナリ検索木やハッシュマップを思い浮かべてください）。 クエリがインデックス付きのフィールドを含む場合、データベースはテーブル内全ての探索を回避し、インデックスを使って効率的にデータを探します。これにより、クエリ速度が大幅に改善するのです。 インデックスは万能ではないことを理解し、適切に使わなければ逆効果になることもあります。 以下がその例の一部です。 ・書き込みの遅延 データを追加・更新するたびにインデックスも更新されるため、書き込み処理が遅くなる ・ストレージの増加 インデックスを保持するための追加のストレージが必要 ・パフォーマンスの低下 インデックスを増やしすぎると、データベースの最適化ツールが適切なインデックスを選びにくくなり、かえって処理が遅くなる それでは次に、インデックスを適用すべきケースを具体的に見ていきましょう。 SQLとNoSQLにおけるインデックスの使いどき すべてのカラムやフィールドに、インデックスを付ければよいわけではありません。 データベースへの負荷を抑えながら最適なパフォーマンスを得るには、インデックスの効果が最も大きい箇所に焦点を当てることが重要です。 どこにインデックスを適用すべきか、この後の内容を踏まえて検討してみましょう。 SQLで一般的なインデックス 主キー(Primary Key) 各テーブルには、一意の識別子となる主キー（例：id）があります。ほとんどのデータベースでは、主キーに対して自動的にインデックスが作成されるため、最も高速にデータを検索できます。 外部キー(Foreign Key) テーブル同士を関連付けるキー（例：注文テーブルと顧客テーブルを結びつける customer_id など）のことです。 これらのフィールドにインデックスを設定すると、JOIN処理のパフォーマンスが大幅に向上します。 フィルター付きカラム WHERE・ORDER BY・GROUP BY などのフィルター条件に頻繁に使うカラムは、インデックスを設定することで検索速度を向上できます。例えば、次のSQLクエリをご覧ください。SELECT * FROM products WHERE category
- [セッションリプレイ機能で、デバッグをさらに正確かつ迅速にする方法](https://ichizoku.io/sentry/debug-faster-smarter-session-replay/) - Article by: Sarah Guthals 開発者なら誰しも、デバッグに時間がかかることを痛感した経験があるでしょう。 なかなか再現できないバグを追いかけたり、あいまいなユーザー報告を頼りに問題を特定しようとしたりすると、シンプルな修正のはずが何時間もの作業になってしまうこともありますよね。 ログやメトリクス、トレースを活用すれば原因の特定に役立ちますが、それだけではユーザーへの影響を正確に把握するのは難しいものです。 そこで役立つのがセッションリプレイです。 ユーザーセッションをビデオのように再生できるこのツールを使えば、デバッグ効率が飛躍的に向上します。ユーザーからの報告を待つ必要も、あいまいな再現手順に振り回されることも、すべての環境を完璧に再現する必要もありません。 セッションリプレイを使えば、「どこで」「何が起こったのか」を正確に把握することが可能です。 この記事では、Sentryのセッションリプレイの仕組みと、それがどのようにデバッグの効率化、ユーザーとのやり取りの削減、さらにはアプリケーションのパフォーマンス向上に役立つのかを詳しく解説します。 セッションリプレイとは？ もし、ユーザーがアプリを操作する様子をリアルタイムで映像として確認できたらどうでしょうか？ クラッシュやパフォーマンスの問題が発生するまでの流れを、正確にたどることができたらどうでしょうか？ セッションリプレイは、まさにそのための機能です。 ユーザーのクリック、スクロール、入力操作などを記録し、それをネットワークアクティビティやコンソールログ、エラーの詳細、さらにはCore Web Vitalsとあわせて表示します。 これにより、問題発生までの流れを可視化し、トラブルシューティングの際の「推測」をなくすことができます。 従来のデバッグ手法であるスタックトレースやログは、バグの再現や原因の特定に必要な情報をすべて提供できるとは限りません。特に、問題の発生状況が不明確な場合、それだけでは十分なコンテキストを得るのが難しいこともあります。 セッションリプレイを活用すれば、ユーザーがどのような操作を行い、それに対してアプリがどのように反応したのかを視覚的に確認できます。そのため推測に頼ることなく、より素早く正確に問題の原因を特定できます。 なぜセッションリプレイを活用すべきなのか セッションリプレイの利点は、開発者のワークフローやチームの体制、ユーザーの特性、アプリケーションの種類によって多少異なります。 しかし、デバッグの効率化やユーザー体験の向上といった点で、どんな開発環境にも共通して有益なメリットがいくつかあります。 デバッグ効率を飛躍的に向上させる エラーレポートを受け取った際、詳細を確認するために何度もユーザーとやり取りをした経験はありませんか？ 問題の説明を詳しく聞いたり、スクリーンショットを依頼したり、ネットワークログを取得してもらったりするのは、開発者・ユーザー双方にとって大きな負担となります。 セッションリプレイを使えば、こうした手間を省くことができます。 ユーザーが問題を報告する前の段階から、エラーが発生するまでの操作をビデオのように正確に再現できるため、原因を素早く特定し、スムーズに修正作業に取り掛かることが可能なのです。 さらに詳しく セッションリプレイを活用して、ユーザーの追加情報なしで問題を解決する Next.jsのデバッグでAPIの読み込み時間を短縮し、より快適なユーザー体験を提供 再現が難しい複雑なバグにも対応可能 バグの再現は、特に発生頻度が低いものほど厄介な存在です。 フロントエンドとバックエンドの複雑な連携によって発生する問題は、一つひとつの要因を切り分けて特定するのに数時間かけてしまうことも珍しくありません。 Sentryのセッションリプレイを活用すれば、これらの問題が発生した瞬間をリアルタイムで自動記録できます。どのUI操作がバックエンドのエラーやAPIリクエストの失敗につながったのかを正確に把握できるため、無駄な試行錯誤を減らし、迅速に修正へとつなげられます。 さらに詳しく セッションリプレイの機能強化: バックエンドエラーの導入 エンドツーエンドの可視化を実現 Sentryのトレース機能と組み合わせることで、セッションリプレイはフロントエンドのクリックからバックエンドのAPIコールまで、処理の流れを可視化します。 例えば、APIのレスポンスが遅くてユーザー体験に影響を与えている場合、セッションリプレイを使えば、ユーザーがその影響を受けた正確なタイミングを特定できます。 さらに、Sentryのネットワークトレースを活用すれば、サーバーの応答遅延や設定ミスによるエンドポイントの問題などを素早く特定でき、迅速な対応が可能になります。 さらに詳しく 開発者向けセッションリプレイ: より速いトラブルシューティングへの近道 ユーザー体験の向上をサポート バグを素早く修正するだけでなく、問題が広がる前に先手を打つことも重要です。 セッションリプレイを活用すると、ユーザーがどのようにアプリを操作しているのかを把握でき、特定の操作で行き詰まったり、パフォーマンスの問題に直面したりしている箇所を可視化することが可能です。 こうした問題を事前に修正することで、ユーザー体験を向上させ、アプリの継続利用につなげることができます。 さらに詳しく セッションリプレイを使って複雑なスタックトレースをデバッグする
- [手遅れになる前に！不安定なテストを見つけて対策する方法](https://ichizoku.io/sentry/blog-catching-flaky-tests/) - Article by: Artem Zakharchenko この記事は、JavaScript用のAPIモックライブラリ「MSWJS」の作成者であるArtem Zakharchenkoによるゲスト投稿です。彼はEpicWebや自身のブログでも、テストに関する記事を執筆しています。 テストの不安定さ（フレーク性）は大きな課題です。 検出して修正するには膨大な時間がかかるだけでなく、テストの最も重要な価値である「信頼性」を損なう原因にもなります。信頼できないテストは、存在する意味がありません。そのメンテナンスに費やす時間も、結果的には無駄となってしまい、本来なら開発に充てられたはずの貴重な時間までも奪ってしまいます。 私はこれまでに、フレークテストへの対処法をご紹介してきましたが、今回はその根本原因である「不安定なテスト（フレークテスト）をいかに見つけるか」についてお話ししていきます。 フレークテストの根本原因 テストを重ねる中で学んだことの一つに、「テストの不安定さはシステムのあらゆる層に潜んでいる」ということです。テストの書き方、セットアップの方法、使用しているツール、さらにはそれらを実行するハードウェアに至るまで、どの部分にも問題の種は潜んでいます。 エンドツーエンド（以降、E2Eと表記）テストが特に不安定だと言われるのは、決して偶然ではありません。システムの端から端まで、多くの要素が絡み合うため、どこで問題が発生してもおかしくありません。それに加えて、E2Eテストはメンテナンスコストが高く、チームの誰もが対処をためらうような厄介な存在になることも多くあります。 さらに厄介なのは、フレークテストの「たまに失敗する」という性質が、問題の深刻さを見落としやすくすることです。複数の層が関わっていると、「たまたまどこかで問題が起きただけ」と片付けてしまいがちです。「再実行」ボタンを押してテストが通れば、それで良しとしてしまうことも少なくありません。 残念ながら、ほとんどのチームは初期のフレークテストをこうして放置します。 一度無視し、二度無視し、気づけばCIの結果に一喜一憂しながら、テストが緑になるまで再実行を繰り返す。そんな状況に陥ってしまうのです。 〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜 E2Eテスト自体を諦めてしまったチームと話したことがあります。最終的に、テストスイートの信頼性が失われてしまったことが原因でした。 しかし、本来の自動テストはそうあるべきではありません。 フレークテストに対処する方法 大規模なチームでは、特にフレークテストの問題が見過ごされることがあります。 そもそも、自分がそのテストの不安定さに直面していないかもしれませんし、何度も再実行する必要がない場合もあります。影響を受けているチームメンバーも、「仕方がないもの」と受け入れてしまうことが少なくありません。 しかし、そんなテストのフレーク性は最終的にチーム全体の生産性を低下させます。 重要なプルリクエストが、ただテストが通るまで再実行を繰り返す「リトライゲーム」のせいで滞ってしまうのは、非常に厄介です。 私自身も、そうした状況に何度も直面してきました。 だからこそ、私はビルドを常に安定させ、フレーク性を見つけ次第、徹底的に排除することに注力しています。 そのためにも、フレークテストを検出し、追跡できるツールを活用するのは非常に有効です。 最近、CodecovがTest Analyticsを発表したので、早速試してみることにしました。最も一般的なフレークテストの原因を意図的に再現し、それをどのように検出・修正できるのかを検証するのが、一番の近道だからです。 フレークテストの検出を検証する ここでは、Vitestのブラウザモードを使用して、シンプルなブラウザ内テストを実施します。 今回テストするのは、ユーザーの投稿リストをレンダリングするコンポーネントです。 かなりシンプルな内容ですが、鋭い方なら既に問題に気づいているかもしれません。 しかし、もし私がそれに気づかなかったとしたら、どうでしょうか？ 私はこのテストを書き、実行し、成功を確認し、変更を承認しました。 そして今、このテストはチーム全員のメインブランチで実行される状態になっています。 ここで、テスト分析を導入してフレークテストを追跡すると、どのような影響があるのかを見てみましょう。 CodecovのTest Analyticsを導入する Test Analyticsは Codecov の一部として提供されており、フレークテストの検出機能も備えています。 公開リポジトリに対しては無料で利用でき、プライベートリポジトリでは Pro またはEnterprise プランが必要です。 プロジェクトへの統合はわずか3ステップで完了します。 https://about.codecov.io/codecov-free-trial/
- [【締切終了】Sentry 日本語記事投稿プレゼントキャンペーン](https://ichizoku.io/sentry/japanese-sentry-post-campaign/) - ☆キャンペーン期間延長☆ 引き続きご応募お待ちしております！ ＼Sentry日本語記事投稿キャンペーン延長決定／ 今日から今月末（3/31）まで期間を延長決定！ 前回も最大31名に賞品が当たる予定でした。。 けど投稿者が下回ったので。。。 ＼全員に賞品を配りました🤡／ Sentryを日頃使っていてもいなくても大丈夫 引き続き240ドル分のクーポンをお配り致します🚀… pic.twitter.com/OoIQ80Wdsb — Sentry Japan (@SentryJapan) March 17, 2025 キャンペーンのポイント 最大31名に豪華景品が当たるチャンス！ Mac miniやVRヘッドセットなど、当選後にお好きなプレゼントを選択可能！ 先着100名の方には特典をご用意！ 参加者全員にSentryクーポンをプレゼント！ 「Sentryを使ったことがある方はもちろん、使ったことがない方にもチャンス」Sentryをもっと便利に使うためのTipsや導入事例、活用方法を共有しましょう！」という企画！抽選でのプレゼントもあるのでぜひ気軽にご参加ください！ こんな人におすすめ 既にご活用されていて、知見やアイデアをお持ちの方 Sentry を使い始められたばかりの方 Sentryに興味があり、これから使っていきたいとお考えの方（無料で使えるプランもご提供しています） 豪華景品ラインナップ 最大31名様にプレゼント！ 当選された方は、当選した賞からお好きなプレゼントが選べます！ ⭐️ Sentry賞 1名様 ⭐️ Mac Mini Mac miniが、さらに小さくなって登場。M4チップまたはM4 Proチップを搭載。Apple Intelligenceのために設計。ポートを背面に、そして前面にも用意。初めてのカーボンニュートラルなMacです。 apple.com/jp/mac-mini/ ⭐️ 最も助けられたで賞 1名様 ⭐️
- [【必読】APIコールの時間を削減する方法！5秒以上から100ミリ秒未満に改善できる…？](https://ichizoku.io/sentry/how-i-reduced-an-api-call-from-greater-than-5-seconds-to-under-100ms/) - 私のプロフェッショナルなキャリアで触れたデータベースは、100％がSQLデータベースだったため、私のデータベースに対する考え方（この言葉遊びを楽しんでください！）は常にリレーショナルモデルが基本でした。 しかし、2020年に小さなサイドプロジェクト（Twitchのストリームにインタラクティブ性を提供するBot）を立ち上げた際、当時のデータ保存要件にはリレーショナルモデルは必要なく、NoSQLソリューションであるMongoDBを選びました。 4年後の2024年、この小さなサイドプロジェクトは予想以上に大きく成長し、テキストベースのゲーム「Pantherworld」へと進化しました。この進化について興味がある方は、どのように小さなTwitchボットからゲームに成長したかを解説した私の2024年のカンファレンス講演「Entertainment as Code」をYouTubeでチェックしてください。 Pantherworldは2024年4月から、私のTwitchチャットインターフェースを通じて、24時間、週7日、数百人にプレイされています。ゲーム内のイベントは、私のストリームで発生するイベントに基づいています。例えば、新しいフォロワーを獲得すると、ランダムなワールドアイテムがランダムなゾーンに出現します。プレイヤーの目標は、Twitchチャットでテキストコマンドを使って世界を移動し、アイテムを収集してインベントリを埋めることです。アイテムには希少なものもあります。 プレイヤーがゲームの進行状況を追跡できるようにするため、私はフロントエンドのコンパニオンアプリを作成しました。このアプリは、NoSQLデータベースからAPIを介してゲームデータを取得します。ゲームが多くのプレイヤーを惹きつけるにつれて、明らかにスケーラビリティ（拡張性）の問題があるAPI呼び出しが一つありました。 それは、リーダーボードデータを取得するエンドポイントでした。このエンドポイントは非常に遅く、その原因が分からなかったため、フロントエンドでスケルトンローダーを追加しました（単に空白画面を表示するのではなく）。遅さを隠そうとしましたが、実際に見るのはとても辛かったです。 重要なのは、私のデータベースに対する思考モデルが常にリレーショナルなものであったことを繰り返し強調することです。 そのため、私は自分がNoSQLをうまく使えていないのだろうと思っていましたが、どこで間違えているのかは分かりませんでした。さらに、このアプリは4年にわたる開発の中で大きく進化し、そのデータモデルの要件がリレーショナルモデルを必要とするようになりました。最初の直感的な反応としては、全体をリファクタリングしてSQLデータベースを使うようにしようと思いました。しかし、4年も経ったレガシーアプリをリファクタリングし、数十万のNoSQLドキュメントをSQLに移行するのは現実的ではありませんでした。 そこで、コードの最適化方法を理解するためにトレースを利用することに決めました。 トレーシング(Tracing)とは何か？ トレーシングは、アプリ内で発生するすべてのイベント（関数呼び出し、データベースクエリ、ネットワークリクエスト、ブラウザイベントなど）をキャプチャする技術で、アプリがどのように動作しているかを理解し、パフォーマンス向上のための改善点やバグ修正ができる箇所を特定するのに役立ちます。 Sentryでは、個別のイベントはスパンとして名前付けされ、これらは各スパンと一緒に送信されるHTTPヘッダーを通じてトレースビューで接続されます。また、これらのイベントをアプリやサービスの全スタックに渡ってキャプチャすることができ、これを分散トレーシングと呼びます。 MongoDBデータベースクエリのトレーシングサポートを追加する方法 MongoDBデータベースクエリのトレーシングは、Sentryの最新のJavaScriptおよびPython SDKで標準でサポートされています。追加の設定は不要です。 私のバックエンドAPIはExpressアプリなので、最新のSentry Node SDKを使用しています。Sentry SDKの初期化コードは別のファイルにまとめることが推奨されています。私の例では、そのファイルをinstrument.tsと呼んでいます。 以下に、最も関連性のあるオプションを示した簡略化されたSDK設定を示します。 tracesSampleRate オプションは、Sentry SDKにトレーシングを有効にするよう指示します。このオプションは0から1の間の値を取り、アプリがSentryに送信するトレースの割合を設定します。アプリのユーザー数やSentryアカウントのプランに基づいて、この値を調整することをお勧めします。 Distributed Tracing（フロントエンドアプリからバックエンドアプリへのトレース）を有効にするには、tracesSampleRateを設定するだけでなく、フロントエンドのSentry SDK設定にbrowserTracingIntegrationを追加する必要があります。ただし、Next.jsやNuxtなどのフルスタックフロントエンドフレームワークは、デフォルトでbrowserTracingIntegrationを追加するため、このルールは適用されません。 バックエンドでは、SentryがMongoDBを含むアプリケーション内のすべてのモジュールを自動的に計測できるように、他のモジュールを要求する前に instrument.js ファイルをインポートすることを確認してください。 私が実際にアプリケーションで使用しているエントリーポイントファイル app.ts の先頭部分でのインポート例をご紹介します。以下の通りです。 MongoDBのクエリをExpressアプリでトレースする設定が完了したので、次にリーダーボードのコードがなぜここまで遅かったのかを調査してみましょう。 なぜ単一のAPI呼び出しが5秒以上かかっていたのか コードの最適化を行う前のトレースのスナップショットがこちらです。 API呼び出しの所要時間が強調表示されています。/world/leaderboard APIへのHTTP GETリクエストは、およそ4秒〜8秒かかっていました。 単一のAPI呼び出しに対する（ズームアウトされた）トレースビューでは、一連のリクエストウォーターフォールと重複したデータベースクエリが表示されています。これは改善が必要です。 API呼び出しを短縮する方法を探る前に、フロントエンドアプリから/ world / leaderboard に対する呼び出しが行われるときに何が起こるのかを見てみましょう。 リーダーボードAPI呼び出しは、プレイヤーの配列を返します。 各Player（プレイヤー）オブジェクトには、username（ユーザー名）、items count（アイテム数）、wealth_index番号（wealth_indexは、すべてのインベントリアイテムの合計で、そのアイテムのレアリティで掛け算された値）が含まれます。 こちらが元のコードで、少し簡略化されています。コードは以下のことを行います。 Itemsコレクションをクエリして、ユーザーに割り当てられたすべてのアイテムを取得し、アイテムをuserIdでグループ化し、そのアイテムのカウントを返します。 各プレイヤーについて、getAllItemsForPlayer()を呼び出します（これによりItems コレクションが再度クエリされます）。 各プレイヤーについて、Playerコレクションをクエリします（このクエリの目的は、アイテムデータと一緒に保存したくなかったuserDisplayNameを取得するためだけです。SQLのジョインがあれば便利でした）。 各Playerオブジェクトを構築し、計算し、配列に追加し、その配列をソートして返します。
- [【Unity開発】Sentry SDKを使用してパフォーマンスインサイトを有効にする方法](https://ichizoku.io/sentry/enabling-out-of-the-box-performance-insights-in-unity-games-with-sentry/) - Sentry Unity SDKは、クラッシュの早期発見に効果的です。 以下をサポートしています。 IL2CPPのC# 例外での行番号サポート（リリースモードでも対応） Windows、macOS、Linux、Android、iOSでのネイティブクラッシュのキャプチャ C#を介して設定されたコンテキストは、ミニダンプを含むあらゆる種類のイベントに表示され、ゲームをエディターでビルドするときにデバッグシンボルが自動的にアップロードされる 私たちは、最良の『クラッシュ報告ソリューション』を提供していると確信しています。次に、ゲームのパフォーマンスに関する即座のインサイトを提供することを目標に掲げ、改良を進めていきました。 その中で、最初の問題に直面しました。 それは、Unityゲームの自動インストルメンテーションはどのようなものになるのか？という質問です。 SentryのパフォーマンスUXをUnityに適応する Sentryはスパンツリーの可視化を提供しており、モバイルおよびWebのインストルメンテーションは画面レンダリングに基づいています。 これらの概念をUnityに適用すれば良いと考えました。 その結果、最初のインストルメンテーションをゲームのスタートアッププロセスとシーンの読み込みに絞り込みました。 すべてのゲームは必ず何らかの基点から始まり、どんなに大きなゲームでも小さなゲームでも、シーンを読み込む必要があります。 いまの段階では、ゲーム全体のインサイトを提供することは難しいですが、パッケージをインストールした直後にSentryが提供できるものをすべての開発者に示すことが可能です。 理想的なシナリオは、ユーザーからほとんど設定なしで即座に動作するものです。以下のスクリーンショットがそのプレビュー画面です。こちらが、Unity SDKの自動インストルメンテーションが提供する内容です。コードは一行も書かずに、すべてのUnityゲームで利用することが可能となります。 さらに興味深いのは、これをどのように構築したか、そしてそれがゲーム開発のパフォーマンスサポートの未来にとって何を意味するかです。だからこそ、私たちはとてもワクワクしています。そして、開発者であるあなたもきっと興奮するトピックとなっているはずです。 【Unity向け Sentry SDK】マルチプラットフォームツール Unityゲームは基本的にすべてのプラットフォームで動作します。 それをサポートするために、Sentry SDK for Unityは『SDKのためのSDK』になりました。ターゲットプラットフォームにネイティブなSDKとP/Invoke（FFI）を通じて統合され提供されます。 iOSで動作するのか？ もちろん。問題ありません。 Apple向けSentry SDKを含めてサポートします。また同様に、AndroidやネイティブのLinux、Windowsでも対応しています。 結局のところ、これがネイティブクラッシュキャプチャのサポートを実現した方法なのです。これらのSDKが共通して持っている特徴は、Unity SDKを支えるだけでなく、すべて自動インストルメンテーションを提供している点です。 しかし残念ながら、これは限られた利用範囲にとどまります。 Unityの成功の鍵となる要素はそのプラットフォームの抽象化です。 開発者はプラットフォーム固有の問題を気にすることなく、Unityの内部に集中できるメリットがあります。Unityゲームは通常、非常に薄いランチャー内に組み込まれているため、ナビゲーションイベントやUIアクティビティのような基盤となるプラットフォームの概念は、一般的に開発者には馴染みがありません。インストルメンテーションが、真に役立ち実行可能であるためには、SDKはUnity内で直接動作する必要があります。 【Unityライフサイクル】インストルメンテーションのための重要なポイントを見つける ゲームは非常に高速なループで動作しており、通常は1秒間に30回から60回の更新を行いますが、上限はありません。 すべてのティックを測定するためにスパンを作成することは現実的ではありません。 私たちは、キャプチャしたい論理的な操作のセットなど、いくつかの主要なアクションに注目する必要がありました。 トランザクションとスパンを定義する課題 Sentryには、何かがどれくらいの時間を要するかを測定するための2つの概念があります。それは「トランザクション」と「スパン」です。 トランザクションは、ページの読み込みや非同期タスクのような、活動やサービスの単一のインスタンスのことをいいます。 スパンは、トランザクション内でネストされた個別の測定値のことです。 概念的には、私たち開発者は、測定したい特定のアクションに対して、巨大なストップウォッチを使って開始と終了の場所を見つけようとしています。 そして、そのアクション内で小さなストップウォッチでキャプチャできるサブタスクを探しています。 しかし、トランザクションはゲームのフレームワーク内でどのように適合するのでしょうか？ ゲームエンジンにすでに組み込まれているサービスのインスタンスが、どのようにトランザクションとして表現されるのでしょうか？ Unityはそのすべての機能にもかかわらず、あらゆる種類のゲームを作成するための真っ白なキャンバスです。 つまり、一般的なライフサイクルを除けば、SDKがスパンを開始および終了するためにフックできる固定されたポイントはあまり多くありません。ボタンのクリックなど、ワンタイムのイベントはたくさんありますが、SDKはボタンクリックの背後で何が起こっているかにどうフックするのでしょうか？ SDKは、スパンを終了するタイミングをどう判断するのでしょうか？ スタートアップとシーンの読み込みのタイミングを測定する
- [React Nativeの新しいデバッグ手法](https://ichizoku.io/sentry/the-new-way-of-react-native-debugging/) - これはSimon Grimmによるゲスト投稿で、SimonはGalaxies.devの創設者です。Galaxies.devでは、Simonが開発者にReact Nativeを学ぶための迅速なコースと個別サポートを提供しています。是非ご覧ください。 従来、React Nativeアプリのデバッグは、面倒な作業として開発者を悩ませてきました。開発者にとって一般的にデバッグがReact Nativeの最大の課題と考えており、これが開発時間のかなりの部分を占めていることはよく知られています。 しかし、良いニュースがあります！ この課題は、改善されつつあるということです。 React Nativeのデバッグ環境は、ここ数年で大きく変わりました。Expo はデバッグを大幅に簡単にする新しいプラグインのセットに取り組んでおり、Flipper は非推奨となり、React Nativeチームは古いツールよりも大幅に改善された新しいDevToolsに取り組んでいます。 新しいReact Native DevToolsは素晴らしいですが、それでもまだ課題がいくつか残っています。 このチュートリアルでは、React Nativeアプリのデバッグに利用できるさまざまなツールを探り、それらをどのように組み合わせて包括的なデバッグ戦略を作成するか見ていきます。 JavaScriptからネイティブコードまで全てをカバーし、アプリで何が起こっているのかを正確に把握し、すべてのエラーを追跡できるようにします。 新しいReact Native DevToolsの良い点 新しいReact Native DevToolsの特徴は、Web開発の体験に合わせていることです。 DevToolsは、（Expoプロジェクトの場合）次のコマンドを実行し、ターミナルで「j」を押すことで開くことができます。 これにより、少し馴染みのあるビューが表示されます。 主な機能は以下の通りです。 Logs: アプリからのログを表示し、フィルタリングする。 Source & Breakpoints: JavaScriptコードをデバッグする。 Components Explorer: コンポーネントの階層を可視化し、propsやstateを検査する。 さらに、Expoのネットワークタブを使用してネットワークリクエストを検査することもできます（現在はunstable(不安定)とマークされていますが、最終的にはDevToolsのコア機能となる予定です）。 React Nativeチームの努力のおかげで、新しいDevToolsは旧バージョンより大幅に改善され、非常に安定していると感じられます — しばらくしてから再接続できる機能も含まれています。 さらに、コンポーネントツリーを直接デバッグできる機能により、別のツールを使う必要がなくなり、ほとんどのReact開発者はこのようなビューに馴染みがあるはずです。 しかし、これらすべては始まりに過ぎません。チームはすでに次の機能を計画しています。 Performance panel：進行中（来年を目標にしています）。 Network panel：進行中（来年を目標にしています）。 Third party Chrome extensions（サードパーティ製のChrome拡張機能）：初期探索中。Expoと協力中（予定時期未定）。 しかし、まだいくつかのギャップがあり、最初はためらっていたものの、Reactotronは今でも重要であることに気づきました。
- [【Sentry活用法】TTFB (Time to First Byte) を削減する方法](https://ichizoku.io/sentry/how-to-reduce-ttfb/) - TTFB (Time to First Byte) とは、クライアントのHTTPリクエストからサーバーが最初のバイトを返すまでの時間を測定するための指標です。 TTFBが低いほど、サーバーの応答が速く、ページの読み込み時間が短縮されていることを表します。近年のWeb開発業界では、Webサイトをサーバー側でレンダリングする潮流が強まっています。 この方法はSEOに有利で、性能の低いデバイスでも快適にWebページを表示させるためユーザ体験を損なうことがありません。 しかし、このアプローチでは TTFB を犠牲にすることになります。 ページをビルド時に静的にプリレンダリングするのではなく、リクエスト時にサーバーで動的にレンダリングするため、ブラウザはサーバーからの応答を待つ時間が長くなります。その結果、TTFBが高くなり、TTFBが高いと他のWebバイタル指標も悪化します。 この記事では、TTFBが高くなる原因を特定し、それを改善する方法について探っていきます。 TTFBの測定方法 ここでは、サーバーサイドでレンダリングされたNext.jsアプリケーションを使用していると仮定します。 一部のページの読み込みが他のページよりも明らかに遅いことが分かったら、Chrome DevToolsを使用してどこで遅延が発生しているのか確認します。 残念ながら、ブラウザがサーバーからの応答を待つのに2秒以上かかったことはわかるものの、DevToolsではページ読み込みのタイムライン内で何がそれほど時間を要したのかを正確に測れません。 そのため、WebPageTestでテストを実行することを検討し始めるかもしれません。 問題があることは間違いない、ということはわかりますが、その原因は依然として不明なままです。 これらのツールは、ブラウザが見て感じることしか提示してくれません。 サーバーでの遅延が高いTTFBを引き起こしているため、ページを読み込む際にサーバーで何が起こっているのかを確認するには、別の種類のツールが必要です。それがトレース（Tracing） です。 トレース（Tracing）とは何か？ トレースは、パフォーマンスの問題をデバッグする際によく使用されるツールで、競合状態（race condition）などの複雑で奇妙なバグを見つけるのにも役立ちます。トレースは「スパン（span）」と呼ばれる最小の作業単位を作成します。 これらのスパンは互いにリンクされており、開始時間と終了時間を持ち、すべてが同じ「トレース」に属します。 測定したい関数やコードブロックを囲む形でこれらのスパンを作成します。また、使用するライブラリによっては、スパンが自動的に作成される場合もあります。この記事では、Sentry を使用します。 SentryはNext.jsと直接統合し、高いTTFBをデバッグするために必要なスパンのほとんどを自動的に作成してくれます。 トレースは「分散型」にすることも可能です。つまり、クライアント側でトレースを開始し、そのままシームレスにサーバー側のトレースを続行できます。これにより、クライアントとサーバーの両方で何が起こっているのかを1つのタイムラインで把握することが可能になります。 Sentryでは、このトレースとすべてのスパンを「フレームグラフ（Flame Graph）」と呼ばれる形式で視覚化します。 トレースに関する詳しい内容については「分散トレース：アプリケーションのデバッグとモニタリングのための強力な仕組み」で解説していますので、こちらをご覧ください！ Next.jsでSentryを使用してトレースを設定する Next.jsでSentryのトレースを設定するには、Sentryをインストールして構成するだけです。指示に従って設定を完了し、アプリケーションを実行すると、ページ読み込みのパフォーマンスデータがSentryに送信されるようになります。 このスクリーンショットから、ブラウザとサーバーの両方で何が起こったかを明確なタイムラインで確認できます。 getServerSideProps 関数が約500msかかっていることがわかります。この遅延の原因は、Cloudinaryへのリクエストであり、リソースが存在することを確認してからページをレンダリングするためのものです。 これを最適化できるでしょうか？ もちろん可能です。例えば、キャッシュを使用するか、リソースの存在を確認する別の（しかもさらに高速な！）方法を見つけることができます。 もし getServerSideProps 関数だけが原因であれば、最適化はこれで完了です！ しかし、今回はそれだけではありません。 getServerSideProps 関数が実行される前に、遅延の大部分が発生していることにお気づきでしょうか。 getServerSideProps 関数の前に、いったい何が実行されているのでしょうか？ 正解は『ミドルウェア』です！ ミドルウェアは自動で計測されないため、以下に示すコードを書いて計測を行う必要があります。 カスタム計測 こちらがミドルウェアの計測を行うための関数です。 まず認証を確認し、その後リクエストがフォトページ用かどうかを確認します。もしそうであれば、画像が存在するかどうかをチェックする関数を呼び出します（聞き覚えがありませんか？）。 次に、ロケールが正しく設定されているかを確認し、リクエストに追加のデータとタグを補完し、next()
- [【Sentry】Reactのデバッグを簡単にする方法](https://ichizoku.io/sentry/sentry-cant-fix-react-hydration-errors-but-it-can-really-help-you-debug-them/) - 初期UIがサーバーでレンダリングされたものと一致しないため、ハイドレーションに失敗したら、とても陰鬱な気持ちになると思います。 Next.jsやReactベースのメタフレームワークを使ってサーバーレンダリングされたページを構築しているなら、ハイドレーションエラーが起きると最悪な気持ちになり、デバッグが困難であることはご存じでしょう。 Reactにおけるハイドレーションとは、サーバー上でHTMLとしてレンダリングされたReactアプリケーションが、ブラウザ上でインタラクティブになるときに発生するプロセスのことです。 ハイドレーションエラーは、クライアント上でReactによってレンダリングされたマークアップが、最初にサーバーからレンダリングされたHTMLと一致しない場合や、サーバーから無効なHTMLが送信され、Reactがそれを修正できなかった場合に発生します。 日付やローカライズなどであれば、避けられないケースとなることも有り得ます。Reactのコードでは、このような不可避な差異に対するエラーを抑制することができますが、ほとんどのハイドレーションエラーは、アプリに何らかのバグがあることを示しています。 この記事では、ハイドレーションエラーの修正方法ではなく、Sentryを使用したハイドレーションエラーをデバッグする方法について説明します。 開発中にハイドレーションエラーが発生すると、選択したJavaScriptフレームワークは通常、エラーを引き起こしたコードに関するいくつかの詳細とともに、大きなエラーメッセージを表示します。 しかし、ハイドレーションエラーは通常、本番環境では表示されませんし、原因も曖昧な状態になりがちです。 一般的なユーザーは、おそらくエラーレポートとともに有用なスクリーンショットを提供することはできないでしょう。 また、ブラウザの開発者ツールなどでエラーを探そうと思うことは皆無に近いでしょう。 さらに言えば、Sentryが自動的に作成するエラー問題も、解決にはあまり役に立たないでしょう。 『セッションリプレイ』を使って原因追及！ もしあなたがSentryのセッションリプレイ機能を用いることで、ユーザーがハイドレーションエラーを起こしたときにユーザーセッションの再現を取得する設定なら、Sentryは特定のハイドレーションエラーのイシューを自動的に作成します（しかも無料です！） Sentryが自動的に特定のハイドレーションエラー問題を作成します。 すべての同じエラーをグループ化します。 エラー発生時に存在したサーバーレンダリングと、クライアントレンダリングの両方のマークアップをキャプチャします。 ビジュアルモードと、プレーンHTMLモードの両方で差分を表示します。 注意点として、SentryのJavaScript SDK、バージョン7.87.0以上を使用していることと、セッションリプレイを有効にしていることを確認してください。 グループ化されたハイドレーションエラーが、Sentryでどのように見えるかご紹介します。 Hydration Error（ハイドレーションエラー）という名前なので、課題リストビューで簡単に見つけることができます。 表示するイベント（推奨、最新、最古）を選択し、イベント間を移動してコンテキスト情報を比較できます。 サーバーとクライアントの間でスライドする差分を表示します（差分ビューアを開くと、ビジュアル差分とHTML差分を並べて表示することもできます）。 『ハイドレーションエラーの解決』をクリックすると、ハイドレーションエラーの解決に関するヘルプが表示されます。 ハイドレーションエラーのデバッグ 標準的なハイドレーションエラーの内容は、サーバーでレンダリングされたHTMLがクライアントでレンダリングされたHTMLと一致しなかったと述べていることが多いです。 そのため、差分ビューアーはこれらの違いを見つけるのにとても役立ちます。 Before「ビューはサーバーでレンダリングされたもの」で、 After「ビューはReactがクライアントでレンダリングしたもの」です。 もしかすると、こちらの例でお気づきかもしれません。 それは「変更前」と「変更後」が見た目がほとんど同じに見えるということです。 HTMLの差分を調べると、サーバーでは空白のページがレンダリングされ、クライアントではHTMLがレンダリングされている、というケースがあります。 しかしこれは正しくない状態です。ブラウザのネットワークタブで確認したところ、HTMLは間違いなくサーバーでレンダリングされています。 ハイドレーションエラーの原因となっているコードの本当の問題は、サーバー側でレンダリングされたHTMLと、クライアント・レンダリングされたHTMLが一致していないことではなく、自身が作成したHTMLが無効で（がの中に含まれている）、Reactがエラーを投げたことです。これが『ハイドレーションエラーが最悪な理由』です。 ではなぜdiff（ファイル差分）によると、サーバー上にHTMLがレンダリングされていないように見えるのでしょうか？ Reactが無効なHTMLのために無意味なハイドレーションエラーを投げたことを考えると、Sentryは問題が何であるかについて最善の努力を尽くして推測するしかありません。 通常、あるイベントに意味のないdiffがある場合、別のイベントの方が役に立つかもしれません。 要するに、Reactがハイドレーションエラーを投げたときは、修正が必要な問題があるということです。 そして、Reactは本番環境で問題を修正するために必要な詳細を教えてくれないので、Sentryはハイドレーションエラーの差分ツールの空白を可能な限り埋めることで、問題をよりよくデバッグできるようにしてくれます。 ハイドレーションエラーの問題や差分を作成すると、Sentryの利用金額は増える…? すでにセッションリプレイを使用している場合、自動的にグループ化されたハイドレーションエラー課題を『無料』でご利用いただけます。 Sentryのハイドレーションエラー問題は、リプレイとその関連データから生成されるため、エラークォーターにも影響しません。さらに、ハイドレーションエラーのアラートもデフォルトで表示されます。 セッションリプレイを使っているなら、Sentry に送信される前に、デフォルトですべてのテキストコンテンツを「 * 」でマスクし、クライアント上のすべてのメディア要素をブロックすることに気づいたかもしれません。 この記事では、Session Replay SDK がどのように設定されているかによって、ハイドレーションエラーの画像に示されている例は、「 * 」ではなくテキストを表示しています。
- [【Sentry】Android開発のデバッグを効率化する方法](https://ichizoku.io/sentry/how-to-improve-your-android-debugging-process/) - Androidアプリのデバッグには、クラッシュ、ANR、一貫性のないログなど、独特な課題が豊富にあります。 しかし、問題を素早く特定して解決し、より良いパフォーマンスとユーザー体験を実現する簡単な方法がいくつかあります。 今回は、Android のデバッグを効率化する基本的なツールとテクニックを紹介し、ANR について説明します！ Androidデバッグにおける「3つ」の基本 Android StudioのLogcat Logcatはリアルタイムにログを出力し、手動でエラーを見つけるのに役立ちます。このツールでは、以下のようなカスタムタグを使用することで特定の問題を切り分けることが簡単にできます。 Logcatで 「MyAppTag 」でフィルタリングすると、無関係なログを選別することなく、NullPointerExceptionのような特定の問題に焦点を当てることができます。 Android Studioのブレークポイント ブレークポイントは、実行時の動作を検査するために不可欠です。コードの重要な行にブレークポイントを設定します。 ブレークポイントがトリガーされると、Android Studioは実行を一時停止し、変数（結果）を検査したり、コードの実行をステップ実行してロジックの展開を確認したりすることができます。 この方法は、フロー制御や計算の微妙なバグをキャッチするために非常に有効です！ ブレークポイントがトリガーされると、Android Studioは実行を一時停止し、変数（結果）を検査したり、コードの実行をステップ実行してロジックの展開を確認したりすることができます。 この方法は、フロー制御や計算の微妙なバグをキャッチするために非常に有効です！ Sentry によるリアルタイムのエラー追跡 ローカルでの開発デバッグや手動ログだけに頼るのではなく、Sentry は本番環境でのエラー追跡を自動化します。例えば、APIリクエストが失敗した場合を追跡する場合、以下のように記述します。 Sentryはエラーをキャプチャし、スタックトレース、ブレッドクラム（エラーに至るまでのイベント）、環境の詳細を含む詳細なレポートを生成します。このコンテキストは、アプリが稼動した後に問題を診断し解決するために非常に貴重です。Sentryはまた、スタックトレースやパンくずのような追加コンテキストでLogcatログからエラーレポートをキャプチャし、強化することによって、Logcatと統合することができます。 さて、基本をカバーしたところで、Androidアプリケーションで非常に頻繁かつ一般的な問題であるANRに取り組む方法など、Androidをデバッグするための他の戦略について、さらに深く掘り下げてみましょう。 AndroidでANRを検出する ANR（Application Not Responding）は、アプリのメインスレッドが長時間ブロックされ、システムがエラーダイアログを表示することで発生します。 最も一般的なものは、Input Dispatching Timeoutで、ユーザーが操作した後アプリのメインスレッドが5秒以上応答しない場合に発生します。これはユーザー体験に大きく悪影響を与え、Google Playストアでアプリのダウングレードにつながる可能性があります。 AndroidでANRを検出する方法はいくつかあり、それぞれに長所と短所があります。トレードオフの関係性にあります。以下で確認していきましょう。 ウォッチドッグスレッド： メインスレッドに定期的にタスクを送信します。スレッドが設定した時間（通常は5秒）以内に応答しなかった場合、ANRが発生したと見なされます。この方法はリアルタイムで検出できますが、ユーザーとの対話がない場合は誤検出してしまうリスクがあります。 ネイティブシグナルハンドラ： ネイティブレベルでシグナルハンドラをインストールすることで、システムによって発生したANRをリッスンすることができます。この方法はネイティブのシグナルを捕捉できますが、バックグラウンドのANRをカバーできず、提供されるスレッド情報も限られてしまいます。 アプリケーション終了情報API（Android 11以上）： この新しいAndroid APIは、完全なスタックトレース、スレッド情報、デッドロック検出など、ANRの最も正確な検出を提供します。フォアグラウンドANRとバックグラウンドANRを区別しますが、Android 11以上でのみ利用可能です。 ANRの検出方法はまだ半分に過ぎません。 AndroidのANRのデバッグについて、Sentryを使用して説明しましょう。 SentryによるANRのデバッグ ANR が発生すると、Sentry は自動的に発生時のアプリの状態、デバイスのパフォーマンス（メモリやバッテリー容量など）、および完全なスレッドダンプを含む重要な詳細を瞬時にキャプチャします。 実際のシナリオを挙げて、確認していきましょう。 スレッドロッキングの問題でアプリが「Input Dispatching Timeout」を出力したとします。Sentryを使えば、ブロックを引き起こしている正確なスレッドを示す詳細なレポートを受け取ることができます。同期化の問題なのか、何か他のものがメインスレッドをロックしているのかを突き止めることができます。 パフォーマンスプロファイリングを使ってANRを解決する
- [Sentryを使って React のデバッグを改善する方法](https://ichizoku.io/sentry/how-to-improve-your-react-debugging-process/) - このガイドは、一般的なバグやパフォーマンスの問題を特定し、解決する方法を解説していきます。 クライアントサイドのReactのデバッグを扱いますが、サーバーサイドレンダリングを使用するReactアプリを持っている場合は、Node.jsのデバッグガイドやオンデマンドのワークショップの記事でその方法がわかります。ぜひそちらもご覧ください。 以下のセクションでは、次のことを解説していきます。 Chrome DevTools、VS Code、およびReact Developer Toolsを使用したReactデバッグの基礎 最小限のバグと最大限のパフォーマンスを実現するReactアプリを作成する方法 一般的なReactのエラーやパフォーマンス課題を特定する方法、それらの課題を改善する方法 SentryがどのようにしてReactのバグやパフォーマンス課題を本番環境で記録しているか、その問題が発生した際に自ら察知するための方法 Reactデバッグの基礎 Chrome 開発者ツール を使用した React のデバッグ すべての主要なブラウザ開発ツールには、JavaScriptデバッガが含まれています。 ブラウザからF12キーを押すことで、Chrome 開発者ツールのコンソールにアクセスできます。開発者ツールの「Sources」パネルが開き、3つのセクションが表示されます。次の通りです。 ページ コードエディタ デバッガ 「ページ」セクションでは、ページが要求したすべてのファイルのファイルツリーが表示されます。React コンポーネントのファイルを選択すると、そのコードが「コードエディタ」に表示されます。 「デバッガ」には、JavaScript コードを精査するためのツールが表示されます。 「コードエディタ」で行番号をクリックするとブレークポイントを設置することができます。行番号を右クリックし、ポップアップメニューから適切な項目を選択することで、条件付きブレークポイントやログポイントを追加することができます。 イベントリスナーブレークポイントは、「デバッガ」セクションで追加できます。 イベントリスナーブレークポイントとは、さまざまな状況でアプリをデバッグするためにDevToolsで利用可能な多くのブレークポイントの中の一つです。 ちなみに、Chrome for Developersの「Pause your code with breakpoints」で、さまざまなタイプのブレークポイントについて学ぶことができるので、こちらの記事も読んでいただくと、理解をさらに深めることができます。 さて、コード実行がブレークポイントで一時停止すると、「デバッガ」セクションの「スコープ」タブで、一時停止時点でのローカル変数とグローバル変数の値を確認することができます。 スコープ内にある値は、DevToolsウィンドウの左下にある「コンソール」パネルで参照することができます。コンソールパネルが表示されない場合は、Escキーを押してみることを試してください。 また、「デバッガ」の上部にあるボタンを使用して、コードを一つずつステップ実行し、変数の値がどのように変化するかを確認することができます。これは問題のデバッグに役立ちます。 「BasicCounter」コンポーネントの「Increment」ボタンをクリックした時の状態を下の画像で示します。 stateValue変数が増加しない場合がありますが、これはインクリメント関数内でcount状態の値に設定されているにもかかわらず、予期しない動作かもしれません。 コードをステップ実行することで、「Increment」ボタンがクリックされたときにstateValue変数がゼロのままである理由がわかります。 stateValueは、コンポーネントが再レンダリングされるたびに「0」に設定されます。count状態が増加するため「Increment」ボタンがクリックされるとコンポーネントが再レンダリングされるという仕組みです。 ブで、Chrome 開発者ツールを使用したJavaScriptのデバッグについてさらに学ぶことができます。 ただ、Reactのデバッグ作業をブラウザの開発者ツールだけで補おうとしても限界があります。 開発者ツールのデバッガを使用してReactコンポーネントの状態値を更新することは可能ですが、推奨されません。 Reactのpropsとstateは不変であり、直接変更すべきではありません。 代わりに、React Developer Toolsを使用して状態値やpropsを変更してください。それでは、次にReact Developer Toolsの使用方法について説明します。 React
- [【必読】Webページを読み込む前に高速化する方法](https://ichizoku.io/sentry/how-to-make-your-web-page-faster-before-it-even-loads/) - 私たちは通常、ブラウザ上に表示されるものを見始めた時や、コンテンツを消費したりページと対話したりできるようになった時に、何が起こるかを測定するという文脈で、Webパフォーマンスについて話します。開発者として、フロントエンド開発者として、Webパフォーマンスは大変重要だからです。例えば、以下のCore Web Vitalsは『私たちが見ることができるもの』、『使用することができるもの』、『経験することができるもの』についての議論を導くものです。 First Contentful Paint（FCP）：ユーザーが最初にページを開いてから、コンテンツの一部がレンダリングされるまでの時間のこと Largest Contentful Paint（LCP）：ページのロードタイムラインにおいて、ページのメインコンテンツがロードされるまでの時間のこと Interaction to Next Paint（INP）：Webページがユーザーの入力にどれだけ速く反応するかを測定する しかし、Webページの最初のバイト(Byte: データのごく小さい単位)がブラウザに受信される前に起こるイベントについてはどうでしょうか？ そのようなイベントを測定し、最適化することで、Webページやアプリケーションの読み込みをさらに速くすることは可能でしょうか？ Sentryトレースビューを使い、TTFB前のイベントがどのように可視化されるのか Sentryのトレースビューを確認すると、browserウィンドウで何かがレンダリングされる前に起こるイベントがキャプチャされ、[browser]のスパンとしてラベル付けされていることがわかります。キャッシュ、DNS、接続、TLS/SSL、リクエスト、レスポンスの6つのスパンが時系列で登録されています。レスポンス以前のすべてのイベントは、Webページ/リソースへのリクエストからレスポンスの最初のバイトが到着し始めるまでの時間を計測するTTFB（Time to First Byte）に先行します。 Sentryがブラウザで初期化されていないにも関わらず、これらのイベントがどのようにしてSentryが捕らえているのか不思議に思うかもしれません。その答えは、Performance API（Webアプリケーションのパフォーマンスを測定するために使用されるウェブ標準のグループ）にあります。より具体的にいうと、Navigation Timing APIにあります。 本当に素晴らしい点は、ブラウザでパフォーマンス API に直接アクセスできることです。パフォーマンス・エントリーのほとんどは、どのWebページに対しても記録されており、それらを取得するためのセットアップや余分なコードは必要ありません。 開発ツールのコンソールを開き、window.performanceと入力して試してみてください。以下のようなものが表示されます。 ※解析しやすいように、関連するタイムスタンプを手作業でグループ化し、順番に並べています。 それでは、Sentryはどのようにしてブラウザのスパンを読み取っているのでしょうか？パフォーマンスAPIが、URLがブラウザでリクエストされた瞬間からタイムスタンプでこれらのメトリクスを記録する結果、Sentry JavaScript SDKは、初期化後にこれらにアクセスし、Webページがロードされる前に、時系列的に起こったイベントの完全なリストを埋め戻し、トレースビューで可視化できるように、関連する完全なトレースにスパンとして送信することができます。 Webページが読み込まれる前に起きていること window.performanceは、Webページのコンテンツがブラウザに表示されるまでに起こるさまざまなイベントへのウィンドウを提供します。 これはPerformanceオブジェクトを返し、そのオブジェクトは上記のコード例にあるtimingpropertyを含んでいます。これはコードを書かずにページ読み込み時にブラウザによって記録されたイベントを検査する素早い方法ですが、Performance.timingプロパティは現在では非推奨となっており、PerformanceNavigationTiming APIに取って代わりました（これまでのところ、わずかな変更のみです）。 Navigation Timing Level 2仕様のこの図は、ブラウザでナビゲーション要求が行われた瞬間から、現在のドキュメントのロードイベントが完了するまでPerformanceNavigationTimingイベントが記録される順序を示しています。すべてのイベントが各ページのロードで利用できるわけではありませんが、順序は上記のwindow.performanceを使用して観察したものと一致しています！ それでは次に、関連する各イベントメトリックを調べてみましょう。 一体、ボンネットの下で何が起こっているのか、そして、トレースビューのブラウザスパンを入力するために、特定のタイムスタンプから Sentry によってどのように計算されるのかを見てみます。そして、この新しい知識を得ることで、TTFBの前にWebパフォーマンスを最適化できるかもしれません。 ブラウザキャッシュ リソースがHTTP GETを使用してフェッチされる場合（例えば、Webページへの標準的なリクエスト）、ブラウザは最初にHTTPキャッシュをチェックします。fetchStartは、ブラウザがキャッシュのチェックを開始する直前の時刻を返します。Sentry Trace Viewのキャッシュスパンは、fetchStartタイムスタンプとdomainLookupStartタイムスタンプの間の時間として計算されます。 トレースビューのキャッシュスパンのゼロでない値は、ブラウザがブラウザキャッシュからリソースを取得するのにかかった時間を表します。キャッシュスパンが長い場合、遅いブラウザや古いブラウザを使用しているか、ブラウザのキャッシュを頻繁にクリアしないユーザである可能性が高いといえます。 ブラウザDNS 次のスパンは、DNS（ドメインネームシステム）のルックアップ時間（ドメイン名をIPアドレスに変換したり、IPアドレスをドメイン名に変換すること）を報告しています。ユーザーがURLをリクエストすると、DNSはデータベース内のドメインを「検索」し、IPアドレスに変換するために問い合わせを行います。これを完了するのにかかった合計時間は、domainLookupEndタイムスタンプ値からdomainLookupStartタイムスタンプ値を引くことで計算されます。 ブラウザ接続 次に、ブラウザがWebサーバに接続するまでの時間を測定します。これは「コネクション・ネゴシエーション」と呼ばれ、connectStart（ブラウザがWebサーバーへの接続を開始するとき）とconnectEnd（Webサーバーへの接続が確立されたとき）の2つのイベント間の時間として測定されます。
- [モバイル向けセッションリプレイを発表 - オープンβ開始](https://ichizoku.io/sentry/announcing-session-replay-for-mobile-in-open-beta-2/) - iOS、Android、React Native用のSession Replayがオープンβになりました。 もしあなたがSession Replayをすでに知っているなら、素晴らしいことです。 リンクをクリックし、あなたのSDKをアップデートすれば、あなたのユーザーが怒りを引き起こすような問題を経験している場所をビデオのように再現してくれるようになります。 もし私が何を言っているのか分からないなら、なおさらです。お話をしましょう。 クラッシュ、悪ふざけ、一般的な無反応は、⭐1つのレビューにつながり、人々はアンインストールし、成長ハックを売り込むPMにつながり、誰もそれを望んでいません。このような悪ふざけを先回りするにはどうすればいいのでしょうか？ 昨年、私たちは、Webアプリのユーザーセッションの完全匿名化されたビデオのような複製をキャプチャする機能 - Webベースのアプリケーションのためのセッションリプレイ - を発表しました。現在、40,000を超えるチームが、チェックアウトの不具合、ページの読み込みの遅さ、予期せぬクラッシュなど、あらゆるデバッグにこの機能を使用しています。 何が問題なのかを実際に見ることで、デバッグがより簡単になるとは誰が考えたでしょうか???? モバイル開発者（GitHubで400以上のアップヴォートを提供し、500以上のアーリーアダプターのサインアップに貢献した）もこの機能を望んでいます。 だから、私たちはここにいます。モバイル向けセッション・リプレイは現在オープンベータ版で、アーリーアダプターは無料で使用できます。 コードとUXのギャップを埋める モバイル向けセッションリプレイは、アプリ上のユーザーセッションを視覚的に再現することで、モバイルアプリケーションの可視性を拡大します。これにより、いつ、どこで、どのようにエラーがアプリに影響を及ぼしているかを、自分で再現したり顧客と会話したりすることなく理解することができます。リプレイを使用すると、タップやピンチによるズームなどのジェスチャーがリプレイビューに含まれるため、ユーザーとのインタラクションをより深く理解し、アプリのどこで問題が発生しているかを特定することができます。リプレイには、デバイスタグ、ネットワークリクエストの詳細、スローされた例外などのデバッグコンテキストも含まれています。 当社の全製品と同様に、セッションリプレイはSentryワークフローに統合されています。Issue Detailsでスタックトレースを検査しながら関連するリプレイを見たり、User Feedbackでバグレポートを提出したユーザからのリプレイを見たりすることができます。また、サンプリング設定を構成して、エラーが発生したときのみリプレイをキャプチャし、データのインジェストを減らすことができます。また、UIへの影響やユーザーの反応（アプリを閉じたかどうかなど）によって、問題の深刻度を評価することもできます。 モバイルエラーの根本原因を確認する モバイル用のSentryのセッションリプレイを使用すると、ユーザーがエラーに遭遇したときにサンプリングセッションを優先するオプションがあります。 これは、クラッシュが発生したときに、その特定のエラーに遭遇した実際のユーザーからの関連するリプレイが、問題の詳細ページで関連するSentryの問題に便利にリンクされていることを意味します。エラーの発生前、発生中、発生後に、OSのバージョンや名前などの有用なコンテキストとともに何が起こったかを見ることで、エラーがどのように発生し、ユーザーにどれほどの影響を与えたかを素早く特定することができます。さらに、エラー時のサンプリングにより、必要なデータを待つ時間や、イベントクォータを監視する不安も軽減されます。 ゲーミフィケーションを使用し、UXに重点を置き、素晴らしいイラストやアニメーションがある、派手なライフスタイル・アプリを開発しているとしましょう。アプリケーション・パフォーマンス・モニタリング（APM）製品は、サードパーティのライブラリでクラッシュが発生していることを警告します。この問題を調査し解決するためにセッションリプレイを使用する方法を説明します。 エラーを特定する： エラー追跡システムで、あなたはエラーメッセージ "NullPointerException in run_animation() "で繰り返し起こるクラッシュを分析します。スタック・トレースは、あなたが使っているサードパーティのアニメーション・ライブラリを指していますが、あなたはその意味を理解していません。 関連するセッションのリプレイを探す： リプレイをフィルタリングして、この特定のクラッシュに関連するものだけを表示します。 リプレイを見る： リプレイの1つを選択すると、達成を祝う画面から始まり、達成ポイントが与えられます。かなり長いです）リワードアニメーションが再生される間に、ユーザーは「次へ」ボタンをタップし、アプリがクラッシュします。 コンソールログを調べる： コンソールログの中で、アニメーションライブラリから「onAnimationCancelled」コールバックが呼び出されていることに気づきます。 このコールバックを実装しそこねていたことに気づきます。対策として、アニメーションの時間も短くします。アップデートをデプロイした後、アプリをアップデートするにつれてクラッシュの数が減少していることを監視します。 この例では、Session Replayにより、クラッシュに至ったユーザーアクションを正確に可視化し、エラーの根本原因としてアニメーションライブラリのコールバックの欠落を特定し、この問題を解決するために的を絞った修正を実装することができます。セッション リプレイがなければ、イベントの正確なシーケンスを理解し、このクラッシュの原因を特定することははるかに困難であったでしょう。 アプリのペインポイントの特定 誤解を招くラベル、リンク切れ、パーミッションの問題 - ユーザーが例外を発生させない問題にぶつかることがありますが、それでもユーザー体験に影響を与えます。セッションリプレイは、ユーザーがどこで立ち往生したり、アプリから脱落したりするかを確認することで、アプリ内でこれらのペインポイントが発生する場所を特定するのに役立ちます。 例えば、モバイル e コマースアプリを開発していて、チェックアウト中にアプリが反応しなくなるという悪いレビューが増えているとします。この問題を調査し解決するためにセッションリプレイをどのように利用できるかを説明しましょう。 アプリのパフォーマンスに問題があると思われます。しかし、パフォーマンスKPIはまだ良好で、APM製品はチェックアウト画面で問題を示しません。 関連するセッション・リプレイを見つける：リプレイをフィルタリングして、チェックアウト画面に関連するリプレイのみを表示し、継続時間の長いリプレイにも注目します。 リプレイを見る：リプレイの1つを選択し、ユーザーのアクションを観察します。ユーザーがチェックアウトページの「次へ」ボタンをタップし、サーバーへのAPIコールが開始されるのを確認します。 ネットワークリクエストを確認する： ネットワーク・タブを調べると、APIコールが正常かつ適切な時間で終了していることがわかります。これで、これが根本的な原因ではないことがわかりました。 パンくずを調べる：アプリのUI状態管理でごく最近の状態変更があり、APIコールが返された後に状態が衝突してUIが更新されないことに気づきます。この時点で、ユーザーは激怒してクリックし、最終的にアプリを終了します。 修正と検証：UI状態管理のバグを処理するための修正を実装します。アップデートをデプロイした後、後続のセッションリプレイを監視して、ユーザーがチェックアウトプロセス中に進めるようになったことを確認します。
- [Reactでフェッチウォーターフォールを特定する方法](https://ichizoku.io/sentry/how-to-identify-fetch-waterfalls-in-react-2/) - フェッチウォーターフォールは、複数のフェッチリクエストが並列ではなく、逐次的に呼び出されるシナリオです。これは深刻なパフォーマンス低下につながります。 以下にその様子を示します。 この場合、2番目と3番目のリクエストは並行してフェッチされ、ページロードとデータ表示が4.053秒改善されます。フェッチウォーターフォールによるパフォーマンスへの悪影響は、スタッキングでも発生します。つまり、リクエストが多ければ多いほど、パフォーマンスへの影響は悪化します。 この記事では、トレースを使用してReactアプリケーションのフェッチウォーターフォールを特定する方法を見ていきます。 トレース入門 トレースとは、あるプロセスやフローを定義する操作やコマンドの論理的なグループを記述するスパンの階層からなるデバッグ・データ・セットをキャプチャするために、コードを「インスツルメンテーション」するプロセスのことです。ページのロードを例にとってみましょう。 ページロードを操作の流れとして記述しようとすると、（おおよそ）次のようになるはずです。 ブラウザがサーバーにページをリクエストする サーバーはHTMLで応答し、ブラウザはそれを解析する パース中に、ブラウザはリンクされたJSファイルに出くわす。JSファイルにはReactとページコードが含まれているので、ブラウザはそれを実行する。 ブラウザは、ページコードの指示に従ってコンポーネントのフェッチとレンダリングを行う。 さらに、ブラウザーは画像、ファビコン、CSSファイルなどのリソースをリクエストする。 これらの処理はすべて特定の順序で行われますが、その時間はデバイスの処理能力やインターネット接続の速度などの要因によって異なります。 この記事のトップにあるスクリーンショットは、APIにHTTPリクエストを送信する3つのhttp.clientスパンを示しています。それぞれ、特定の開始時刻、特定の終了時刻、そして雑多なデータが添付されています。上のスクリーンショットのトレース・ビューを見ると、3つのHTTPリクエストが次々と実行されていることがよくわかります。 プロジェクトの設定 まず、ReactプロジェクトにSentryをセットアップする必要があります。始めるには、Sentry React SDKをインストールする必要があります。 この時点で、すでにサインアップしているはずです。新しいReactプロジェクトを作成しましょう。 Create Project」ボタンを押すと、React SDKのインストール方法と初期化方法が表示されます。初期化設定は以下のようにします。 Sentry SDKの最も優れた点は、コードベースの大部分を自動的に計測してくれることです。フェッチのような既知の操作を自動的にスパンでラップし、Sentryインスタンスに送信するので、すぐにデータの検査を開始できます。 これで、アプリをデプロイして、ユーザーがアプリを使用している間に測定された実際のパフォーマンスデータを得ることができます。データが得られれば、フェッチウォーターフォールのようなパフォーマンスの問題を特定するための調査を始めることができます。 Reactでフェッチウォーターフォールを識別するには？ フェッチウォーターフォールの症状には、著しく遅いページロードが含まれるため、不審に遅いページロードを警戒する必要があります。 Performanceページを使用すると、疑わしい遅いページロードを簡単にピックアップして検査することができます。以下は、私たちのアプリのインデックスページのPerformanceページのスクリーンショットで、ユーザーが私たちのページを訪問している間にキャプチャされたトランザクションを示しています。 どのスパンが不審に遅いか、はっきりとわかります。そのうちの1つをクリックすると、トレース・ビュー画面が表示され、すべてのスパンを見ることができます。http.clientのスパンを拡大してよく見ると、ウォーターフォールが見えます。 この場合、3番目のリクエストグループは、どの結果にも依存しないので、2番目のリクエストの終了を待つ必要はありません。つまり、フェッチウォーターフォールを分解すると、2秒の改善を見ていることになります。 フェッチウォーターフォールを修正するには、その原因を調べる必要があります。フェッチウォーターフォールはサーバーに原因があることもあります。フェッチ・ウォーターフォールのよくあるケースの修正方法についてもっと知りたい方は、「Reactにおけるフェッチウォーターフォール」の記事をご覧ください。 これを見ると、トレースを使って他のタイプの問題も解決できると思うかもしれません。そして、それは正しいでしょう！トレースは本当に一般的なデバッグ手法で、Web Vitalの不具合、ネットワークの遅延、サーバーレスアプリケーションのコールドスタート、キャッシュの欠落やキャッシュ機構の問題、その他様々な問題やバグを特定し、デバッグし、修正するのに役立ちます。トレースは、"トレース "をたどって、いつ何が起こったか、どれくらいの時間がかかったかを調べるようなデバッグや修正に使うことができます。 結論 つまり、トレースはフェッチウォーターフォールの特定に役立つということです。 簡単に復習しましょう。 トレースとはデバッグテクニックの一つで、ページロードのような操作の流れを視覚化しやすくするために、デバッグデータをキャプチャすることです。 トレースとは、互いに関連し、開始時刻と終了時刻を持ち、任意のデータが付加されたスパンのコレクションです。 アプリケーションでトレースのキャプチャを始めるために、私たちはSentryのReact SDKをインストールし、アプリのトップで初期化し、変更を単純にデプロイしました。SDKは自動的にアプリをインスツルメンテーションするので、トレースデータをすぐに見ることができました。 キャプチャされたトレースをすべてリストアップし、その継続時間に基づいて、どのトレースが不審に遅いかを確認できました。 遅いページロードを検査すると、最適化するとページロードを秒単位で改善できるフェッチウォーターフォールが見つかりました。 この記事が、トレースとは何か、どのように始めるべきかを理解する助けになれば幸いです。それでは、よいトレースを！ IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。またご導入についての相談はこちらのフォームからお気軽にお問い合わせください。
- [Trace Viewを使用してAPIコールを22.3秒短縮した方法](https://ichizoku.io/sentry/how-i-cut-22-3-seconds-off-an-api-call-using-trace-view/) - Dan Mindruはフロントエンド開発者兼デザイナーで、モーニング・メーカー・ショーの共同司会者でもあります。 現在、PageUI、Clobbr、CronToolなどのアプリケーションを開発しています。 開発者として、遅いAPIほどイライラさせられるものはありません。 コードが動くことは分かっていても、それがもう良いユーザー体験にならないことは分かっているはずです。 私にもそのようなことがあり、2週間ほど見て見ぬふりをしていました。 しかししばらくすると、いくつかの問題は個人的なものになります。 問題は、どこから手をつければいいのか見当もつかなかったことです。 Sentryの新しいトレース・ビューを発見するまでは。 もちろん、トレースこそ、パフォーマンス低下の根本原因を突き止めるために必要なものです。では、このトレース・ビューのトリックひとつで、APIコールのロード時間を22.3秒短縮した方法をお教えしましょう。 この投稿で詳細を説明し、トレースを使って自分のAPIコールのボトルネックを見つける方法を紹介します。うまくいけば、あなた自身のレスポンスタイムを数秒短縮できるかもしれません。さあ、始めましょう！ トレースビューとは？ ほとんどの人は、Sentryのエラー監視機能を知っています。しかし、それだけではありません。実際、Sentryはパフォーマンスのボトルネックを見つけるのにも役立ちます！ Sentryのセットアップがいかに簡単かは前にも述べました。その後、Sentryはパフォーマンス・メトリクスも収集してくれます。 トレース・ビューはその重要な一部で、トランザクションとスパンを滝のように可視化します。ご想像の通り、これはアプリケーションのパフォーマンスに影響を与える遅延、関連するエラー、ボトルネックの特定に役立ちます。 次に、私のユースケースでこれをどのようにセットアップしたかをお見せしましょう。 面白いことに、Sentryは自社のパフォーマンス測定機能を活用したことで、年間16万ドルを節約しました！ ファイルI/Oのトレースビューの設定 私がデバッグしているエンドポイントは、普通のボトルネックではありません。長いHTTPコール、ファイルI/O、サードパーティ・コール（AI生成）、そして最後にDBクエリーがいくつかあります。 問題のエンドポイントはShipixenというアプリのもので、コードベース全体、リポジトリ、コンテンツを生成し、Vercelにデプロイまでしてくれます。 見ての通り、通常のCRUDエンドポイントではありません。 このような状況は、影響を測定することなく毎月毎月機能を増やし続けるエンドポイントによく見られます。 最終的なエンドポイントのボスと呼んでもいいでしょう。 目の前の問題を理解する ただひとつわかっていたのは、このリクエストのすべてのステップが必要だということでした。バックグラウンド処理にしたり、キューに分けたり、他のアーキテクチャを応用することも考えたが、実際のところは以下の通りです。 ユーザーが利益を得るのは、すべてのタスクが完了してから。 ユーザーは王様／女王様であり、私のアーキテクチャなど気にも留めない。 私は行動を共にし、リクエストを完了するのにかかる時間を半分にするよう努力する必要がある。 これが、44.94秒という短い処理時間の理由です。 あるいは、平均的なシナリオでこのリクエストを完了するのにかかった時間です。 さっそくデバッグシューズを履いて、トレースビューを開いてみました。驚いた！ SentryはネットワークI/Oの検出はうまくやりましたが、それ以外はすべてブラックボックスでした。 そしてそれは理にかなっています。 実行中の様々なファイルI/Oをすべてトレースする必要があることを、どうやって知ることができるでしょうか？ 54秒かかったという事実は無視して、目の前の問題に集中しましょう。どのタスクに一番時間がかかるのか、さらに重要なのは、どの順番でタスクが完了するのかがわからなかったのです。 カスタム計装の設定 幸運なことにSentryはカスタムインスツルメンテーションを行うメソッドを公開しているので、ファイルシステム上であれ、https上であれ、その中間であれ、あらゆる操作を追跡することができます。 スパンを作成する関数呼び出しで、問題の操作をラップする必要があります。スパンとは、基本的に時間の計測値であり、「起こること」です。"thing "と呼ぶのは少し抽象的なので、スパンと呼ぶことにしました。 お使いの言語やフレームワークにもよりますが、以下のようになります。 そして、メソッドをスパンで囲み始めると、いつの間にかトレース・ビューワーはこのようになっていました。 ボトルネックを特定する方法を探ってみましょう。 ボトルネックの特定 この見方をよく見てみましょう。一般的に、これらは最も注意すべき問題です。 ロング・ラン・スパン ペイロードを減らすことができるか？ 複数の並列タスクに分割できるか？ バックグラウンドで実行できるか？ より高速で効率的な新しいAPIはないか？ 互いに待機するウォーターフォール型スパン（並列化可能） 互いに待機しなければならない非効率的なスパンオーダー スパン間の依存関係 最初のバイトまでの時間が遅い / ネットワーク依存のコールドスタート
- [JavaScript v8 SDKにおけるOpenTelemetryとNodeサポートの改善](https://ichizoku.io/sentry/improved-opentelemetry-and-node-support-in-javascript-v8-sdk/) - Sentry Launch Weekで初めて発表したように、私たちはJavaScript SDKのメジャーリリースに向けて取り組んできました。 このアップデートにより、Sentry JavaScript SDKをさらに簡単に使い始めることができます。このリリースは、自動instrumentationを提供するフレームワークとライブラリの数を広げます。しかし、Sentryのセットアップをカスタマイズしたい場合、OpenTelemetry (OTel)の拡張サポートにより、必要なcustom configurationを85行のコードから10行以下に減らしました。 OpenTelemetryによるトレース OpenTelemetry はスタンダードな機能とメンテナンス機能を提供してくれますが、それらのツールと収集されたデータを使って、あなたに洞察を提供するのは私たちの役目です。 例えば、Sentry の新しいトレース・ビューは、v8 の改良された Node.js サポートの恩恵も受ける最新の機能改良の一つに過ぎません。 私たちのNode SDKにOTelを組み込むことで、以前のバージョンよりも詳細なスパンデータを収集します。 Next.jsとPrisma 4で構築されたSentry独自のChangelogに記録されたスパンの詳細をご覧ください。 より多くのNodeフレームワークとライブラリの自動インストルメンテーション 特にOTelのNode SDKは、Sentryの以前のNode SDKよりも多くのNodeフレームワークを自動パフォーマンス計測のためにサポートしています。Node SDKの一部をOTelに置き換えることで、SentryがデフォルトでサポートするNode.jsフレームワークとライブラリのサポートを拡大しました。 これは、あなたのNodeプロジェクトに以下のフレームワークやライブラリがある場合、Sentry Node SDKが自動的にそれらを検出し、設定することを意味します。 Express（改善） Connect（改善） Nest.js（新規） Koa（改善） Fastify（新規） Hapi（新規） ライブラリ pg (Postgres) pg-native (Postgres) mongodb (Mongo) mongoose (Mongo) mysql2 (MySQL) mysql (MySQL) graphql (GraphQL) apollo-server-core (Apollo) @nestjs/graphql (Apollo) Prisma
- [2024年にGoogle Lighthouseのスコアをハックする方法](https://ichizoku.io/sentry/how-to-hack-your-google-lighthouse-scores-in-2024/) - Google Lighthouseは、開発者の間でWebページのパフォーマンスをゲーム化し、促進する最も効果的な方法の1つです。Lighthouseを使えば、全体的なパフォーマンス、アクセシビリティ、SEO、Googleが考える「ベストプラクティス」に基づいてWebページを評価することができます。 これらのテストは、フロントエンドフレームワークのすぐに使えるパフォーマンスを評価したり、熱心なリファクタリングによってパフォーマンスが改善されたことを喜んだりするのに使うかもしれません。そして、Lighthouseの満点のスクリーンショットをソーシャルメディアで共有するのが好きなのはご存じでしょう。紙吹雪のお祝いにふさわしい栄誉です。 Lighthouseが私たちのような開発者にパフォーマンスについて語らせるという事実だけでも勝利です。しかし、パーティーの片棒を担ぐようなことはしたくないですが、実際のところ、Webパフォーマンスはこれよりもはるかに微妙なものです。 この記事では、Google Lighthouseがどのようにパフォーマンス・スコアを算出しているかを検証し、この情報を使って、私たちに有利になるようにスコアを「ハック」してみます。Lighthouseをどこまで 「騙す 」ことができるか、そして自分たちにふさわしいスコアよりも良いスコアを出すことができるか、楽しみながらやってみましょう。 その前に、データについて話しましょう。 現場データは重要である ローカル・パフォーマンス・テストは、Webサイトのパフォーマンスが正しい方向に傾いているかどうかを理解するための素晴らしい方法ですが、現実の全体像を描くことはできません。WWW（ワールドワイドウェブ）は西部の荒野であり、人々がWebサイトにアクセスするために使用しているさまざまなデバイスの種類、インターネット接続速度、画面サイズ、ブラウザ、およびブラウザのバージョン（これらすべてがページパフォーマンスとユーザー体験に影響を与える可能性があります）を、私たちはほぼ確実に見失っています。 Sentryのようなアプリケーションパフォーマンス監視ツールによって、実際にWebサイトを使用している人々のデバイスから収集されたフィールドデータ（しかも大量に）は、制御された条件下でハイスペックなスーパーパワー開発マシンを使用して、1サンプルサイズから収集されたラボデータよりもはるかに正確なWebサイトパフォーマンスのレポートを提供します。フィリップ・ウォルトンは2021年、HTTPアーカイブのデータに基づき、「Lighthouseで100点を獲得したページのほぼ半数が、推奨されるCore Web Vitalsのしきい値を満たしていなかった」と報告しています。 パフォーマンスとは、単一のCore Web Vitals指標やLighthouseのパフォーマンススコア以上のものです。私たちが話しているのは、扱う生データの種類をはるかに超えるものです。 Webパフォーマンスは数字以上のもの Webパフォーマンスについて話すとき、スピードが最初に話題に上ることがよくあります。これは測定する上で最悪なことではありませんが、スピードはおそらくビジネスのKPIや売上目標に大きく影響されることを念頭に置かなければなりません。 Googleが2018年に発表したレポートによると、ページの読み込み時間が3秒以上になると、直帰する確率が32％増加し、10秒になると123％に跳ね上がるといいます。 つまり、より多くの売上につなげるには、直帰率を減らす必要があるという結論になります。そして、直帰率を減らすには、ページの読み込みを速くしなければなりません。 しかし、「読み込みを速くする」とはどういうことなのでしょうか？ ある時点で、Webページの読み込みをこれ以上速くすることは物理的に不可能になります。人間やそれをつなぐサーバーは世界中に散らばっており、現代のインターネット・インフラは一度に多くのバイト数しか配信できないのです。 要するに、ページの読み込みは一瞬ではないということです。スピードとは何か？Googleのいう、ページ読み込みイベントとは。 単一の指標では完全には捉えられない体験のことです。ユーザーが「速い」と感じるかどうかには、読み込み体験の間に複数の瞬間があり、1つの瞬間だけに注目すると、残りの時間に起こる悪い体験を見逃してしまうかもしれません。 ここでのキーワードは『体験』です。本当のWebパフォーマンスとは、数字やスピードよりも、ユーザーとしてページロードやページの使いやすさをどのように体験するかということなのです。そしてこれは、Google Lighthouseがどのようにパフォーマンススコアを計算するかという議論にうまくつながっていく。(あなたが思っているよりも、純粋なスピードは重要ではありません）。 Google Lighthouseのパフォーマンススコアはどのように計算されますか？ (CLS)）と、ページ読み込みのタイムライン全体を通して観察可能なその他のスピード関連メトリクス（Speed Index (SI)、Total Blocking Time (TBT)）に基づくスコアを加重平均して算出されます。 このように、メトリクスは総合スコアで重み付けされます。 各スコアに割り当てられた重み付けは、Googleが優れたユーザー体験のさまざまな構成要素にどのような優先順位をつけているかを教えてくれます。 1. Webページはユーザーの入力に反応しなければならない この指標は、FCP（First Contentful Paint）後の合計時間を調べ、メインスレッドがユーザー入力への迅速な応答を妨げるほど長くブロックされている可能性がある場所を示すのに役立ちます。メイン スレッドで JavaScript タスクが 50 ミリ秒以上実行されると、メイン スレッドは「ブロックされた」と見なされます。TBTを最小化することで、Webページが物理的なユーザー入力（例：キーの押下、マウスのクリックなど）に確実に反応するようになります。 2.Webページは、予期せぬ視覚的な変化を伴うことなく、有用なコンテンツを読み込むべきである Lighthouseのメトリクスで次に重みがあるのは、Largest Contentful Paint（LCP）とCumulative Layout Shift（CLS）です。LCPは、ページのロードタイムラインの中で、ページのメインコンテンツがロードされた可能性が高い時点を示すもので、そのため有用です。 メインコンテンツがロードされた可能性が高い時点で、ユーザーがページを使用でき、予期しないビジュアルシフト（CLS）の影響を受けないように、ビジュアルの安定性も維持したいものです。良いLCPスコアは2.5秒未満です（私たちはWebサイトを可能な限り高速化しようとしていることが多いので、これは想像以上に高いスコアです）。
- [バックエンドが原因で遅くなったWebページのデバッグ手法について](https://ichizoku.io/sentry/debugging-slow-pages-caused-by-slow-backends/) - 開発者として、誰かがあなたのWebサイトの読み込みが遅いと言ったとき、あなたはどんな反応をすべきでしょうか？ 「ユーザーに任せている」と言わない限り、あなたはすでに正しい道を歩んでいます。ユーザーの苦痛を和らげることを選択したのですから、読み込みの遅さやパフォーマンスの問題を特定し、修正するプロセスをご案内します。 実際、パフォーマンスの問題をどのように解決するかはさまざまですが、開発者としては、解決への最短経路を常に求めています。 小規模から中規模の静的サイトであれば、ブラウザの開発ツールに組み込まれているLighthouseスコアで十分でしょう。個々のページのCore Web Vitalsが表示され、通常、Webサイトのパフォーマンスを改善するために必要な変更を行うのに十分な情報が得られます。とはいえ、Lighthouseのスコアだけを目標にすべきではありません。 Webサイトが成長したり、静的でなくなったりすると、パフォーマンスの問題をデバッグするために、より詳細な洞察が必要になります。 この投稿では、私が開発したサイトを紹介します。このサイトは静的Webサイトとは程遠く、各ルートは人気リズムゲームのゲーム内スコアに基づいて、ユーザーにカスタムされたポケモンのようなカードを動的にレンダリングします。 そのような動的な性質をもつため、すべてのブラウザとユーザーが使用する可能性のある・すべてのネットワークで・すべてのルートをテストすることは不可能です。 その代わりに、実際のユーザーによる実際のセッションのパフォーマンスをモニターして、いつ問題が発生し、どのように解決できるかを知る必要があります。 問題の発見 モニタリングツールがなければ、ドッグフーディング（アプリを自分で使用すること）、またはユーザーレポートという2つの方法のいずれかでパフォーマンスの問題に遭遇する可能性が高いです。 ドッグフーディングは重要ですが、インターネット接続が良好なハイエンドのデバイス1台でしかアプリを使用していない可能性が高く、それがユーザーの間で一般的かどうかを検討する必要があります。ユーザーレポートは非常に有用ですが、正直なところ、明らかなレポートチャネルを持っていない場合、それらはほとんどありません（そして、その場合でも、役に立たないか、または再現するのが難しい場合があります）。 常にログを読み、リクエストのタイミングを計っていない限り、どこで間違ったのか、なぜ間違ったのかを正確に突き止めることは難しいのです。 Sentryのユーザーフィードバックとセッションリプレイ Sentryでは、あなたのサイトに常に存在するユーザーフィードバックウィジェットにオプトインすることができます。 このウィジェットは、ユーザーが見つけたバグを直接Sentryのダッシュボードに報告することができ、スクリーンショットを追加するオプションもあるので、即座に実用的な洞察を得ることができます。 さらに、Sentryは、このフィードバックを「セッションリプレイイベント」と連動させ、ユーザーがボタンをクリックしたり、サイト内を移動するたびに、追加の有用な詳細を含むパンくずなど、ユーザーのWebサイトとのインタラクションの完全な再現を見ることができます。 最近、Sentryのウィジェットを介してユーザーがフィードバックを送信し、ロードに時間がかかる理由を尋ねたとき、私はWebサイトのページロードが遅いことに気づきました。セッションのリプレイをチェックすると、明らかに読み込みが非常に遅かったのですが、フィードバックとセッションのリプレイで提供された情報でも、大きな画像や過剰なJavaScriptのような明らかな問題や迅速な解決策を見つけることができませんでした。この問題については、Sentryのトレースビューをもう少し深く掘り下げる必要がありました。 トレースの使用 Sentryのトレース機能は、フロントエンドからバックエンド、そしてサービス間のトランザクションをリンクし、ソフトウェアの接続されたビューを提供することで、コードのパフォーマンスを追跡するために使用されるツールです。 トレースビューは、各トランザクションにかかる時間から、より具体的な問題のデバッグを助けるためにユーザが使用したデバイスやブラウザまで、あらゆる情報を提供します。トレースビューは、ユーザーフィードバックや問題によってトリガーされたリプレイにも添付され、ユーザーがページをロードしたとき、ボタンをクリックしたとき、サイト内を移動したときなど、舞台裏で起こったすべてのことを簡単に調べることができます。 セッションリプレイイベントのトレースを参照した後（パフォーマンスタブを少し調べると同時に）、私のサイトの（かなりひどい）スローダウンはナビゲーション中のロード関数にあることがわかりました。それはいいことですが、私は15分以上前にコードを書いたのです。幸運なことに、Sentryはリクエストまでの詳細をすぐに提供してくれました。 修正 リピート・リクエスト 私が犯した最初のミスは、それを書くときに明らかであったはずなのですが、不必要に同じリクエストを何度も繰り返し、一度に一つのものだけを取り出すことでした。ユーザー」オブジェクトを構築する際に、大きなJSONデータの塊から特定のプロパティを取り出す必要があったのですが、1回の関数呼び出しで必要なプロパティを返すのではなく、同じ関数を8回繰り返し呼び出して配列を作成し、その都度1つのプロパティしか取得しませんでした。 Sentryのトレースビューで、私はすぐに問題を特定することができました。 青い 「自動グループ化された 」スパン（2秒近くかかりました🤮）が最初に目に留まり、それを拡大して各スパンが同じリクエストエンドポイントを持っているのを見ると、私のコードで何が修正されるべきかは明白でした。 リクエストウォーターフォール さてさて、滑稽なほど酷いコードはこのくらいにして、解決策があまり明確でない問題に移りましょう。上の画像では、「自動グループ化された 」リクエストの先にも、ページロードの終わりまで小さな階段があるのがお分かりいただけるでしょう。これはリクエストウォーターフォールと呼ばれるもので、リクエスト（この場合は外部APIへのリクエスト）を直列に行い、前のリクエストを終えてから次のリクエストを開始することで発生するものです。 このウォーターフォールはできるだけ避けたいものですが、リクエストを連続して行う必要がある状況もあります（一般的には、ある呼び出しのリクエストが前の呼び出しの結果に依存している場合）。 1回の呼び出しで楽曲IDのリストを取得しているのですが、より具体的な情報を取得するには、特定のIDごとに個別のリクエストを行う必要があります。私が最初に考えたのは、1回のリクエストですべての情報を集めることはできないので、1つずつ呼び出す必要があり、現在持っているパフォーマンスはそのままになってしまうということでした。幸いなことに、この問題を抱えたのは私が初めてではなく、リクエストのウォーターフォールを回避する2つの解決策を見つけました。 直列運転と並列運転 ロード時間のパフォーマンスを最適化する場合、リクエストを直列に実行しないことが最も重要ですが、常に可能というわけではありません。直列に実行する必要があるときと、そうでないときを見分けることが重要です。 なぜなら、可能な限りリクエストを並行して実行する必要があるからです。 直列実行の反対は並列実行で、その名の通り、すべてのリクエストが同時に実行され、最も遅いリクエストが終了するたびにグループとして解決されます。JavaScriptでは、コード上の違いはごくわずかですが、実行時に実際に起こることは大きく異なります。 上記のように、リクエストを直列に呼び出すコードから並列に呼び出すコードに変更した後、最終的に恐ろしいウォーターフォールを取り除くことができ、Sentryでこれを確認することができます。両方のロード関数のトレースを比較すると、かつては階段状だったものが、今では崖のようになっており、最も遅いリクエストが終了するとすぐにページがロードされることがわかります。リクエストの処理方法を変更した後、P75（75％のユーザーにとっての平均ページ読み込み速度）を6.5秒からわずか2.3秒まで下げることができました。 一歩前進 SvelteKit（またはReactではこのようなもの）のpromiseストリーミングを使えば、このパフォーマンスの大幅な向上をさらに一歩進めることが可能になります。 サーバーのロード関数からクライアントにpromiseをストリーミングすることで、すべてのリクエストが終了する前にページをレンダリングできるようになります。これには累積レイアウトシフト（Cumulative Layout Shift）の可能性に対処する複雑さが加わりますが、ページのロード速度を劇的に改善する機会があり、ユーザーにとって最も重要なデータをより迅速に利用できるようになります。 パフォーマンスには価値がある この記事の冒頭で、最も早く解決する道は常に取るべき道であると述べました。 パフォーマンスの問題は、「バグ 」ではないという点でユニークであり、Webサイトのエラーやクラッシュを引き起こしていないため、多くの開発者が見過ごしてしまうことがあります。しかし、一貫して速い読み込み速度は、10,000セッションに1回起こるエッジケースエラーよりも、ユーザーにとって同じように、いやそれ以上に重要です。Sentryを使用することで、このような抽象的な問題の発見と解決が非常に簡単になります。 パフォーマンス問題のデバッグの詳細 Sentryのトレースがパフォーマンス問題のデバッグにどのように役立つのか、もっと知りたいですか？ 悪いLCPスコアをバックエンドの問題にトレースするSalmaのブログ記事をチェックするか、以下のワークショップの全容をぜひご覧ください。 IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。またご導入についての相談はこちらのフォームからお気軽にお問い合わせください。
- [『Requests』機能によるサードパーティAPIのデバッグ手法](https://ichizoku.io/sentry/debug-third-party-apis-with-reuests/) - インターネットは基本的に、たくさんのWebサイトが互いに通信し合っているだけの仕組みです。 あなたがあるサービスに対して呼びかけ（リクエスト）をかけると、そのサービスからあなたに返答（レスポンス）が返ってきて、そのサービスがダウンしてあなたの午後が台無しになる、というものです。 Insightsの最新機能である『Requests』は、発信されたHTTPリクエストの動作を確認、理解、追跡、改善するための機能です。 一般的なサードパーティのAPIや自社サービスの呼び出しであろうと、Requestsビューはすべての情報を一箇所に集めるのに役立ち、問題が発生したときにトラブルシューティングするための接続されたデバッグワークフローを提供します。 お客様の問題、私たちの解決策 InsightsのRequestsは、他のサービスを呼び出す頻度や、それらのリクエストにかかる時間、3xx、4xx、5xxエラーコードの急増など、その他の興味深い情報を確認するのに最適です。 学術的な興味はそれで十分ですが、ここではRequests機能が解決に役立つ現実の一般的な問題をいくつか紹介していきます。 皆のためか、私だけのためか？ サードパーティのサービスが停止しているのか、それとも自分のサービスが停止しているのか、それをすぐに知るにはどうすればいいのでしょうか？ Requestsを使えば、非常に簡単にできます。人気のあるサードパーティサービスでは、「Status 」リンクからサービスの稼働時間ページにアクセスできます。エラーの応答率を公式の稼働時間と照らし合わせ、エラーが発生しているのがあなただけかどうかを確認してください。 P.S. 人気のあるステータスページのリストはオープンソースです。 助けて！レート制限されています！ リクエストが殺到して、サービスが処理を止めることがあります。 409が多発し、サービスの利用を減らす方法を考えなければなりません。 Requestsを使えば、これはかつてないほど簡単になります！ ドメインをクリックし、トランザクションあたりのスループットをチェックして、コードのどこでそのサービスを最も頻繁に呼び出しているかを確認します。 機能は壊れているが、私の機能ではない アプリケーションがサードパーティのAPIを呼び出している場合、統合がうまくいっていないというバグ報告を受けることがあります。Requestsを使えば、これを追跡するのは簡単です。統合のドメインをクリックし、エラーレスポンスのサンプルを見つけ、関連するトレースを見て問題を見つけることができます。 リクエストを始める Requestsはビジネスプランとエンタープライズプランに含まれています。 始めるには、ドキュメントをチェックするか、今すぐSentryアカウントでお試しください。 また、Sentryを初めてご利用になる場合は、今すぐ無料でお試しいただくか、デモをリクエストしてください。 ぜひGitHub、Twitter、Discordでご意見をお聞かせください。 IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。またご導入についての相談はこちらのフォームからお気軽にお問い合わせください。
- [Laravelとの提携に興奮する理由](https://ichizoku.io/sentry/sentry-strengthens-partnership-with-laravel-php/) - Laravelの友人がSentryとの新しいパートナーシップを発表しました。簡単に説明すると、新規または既存の Forge/Vapor サイトに数クリックでエラー監視とトレース機能を追加できるということです。この新しい統合は、PHP 開発者が可能な限り簡単にプロジェクトの実際の遠隔測定を収集できるように設計されています。 PHPアプリケーションのビルド、デプロイ、管理、デバッグ ForgeとVaporのUIを通して、Sentryを初めて使う開発者は、組織やSentryプロジェクトを作成することができます。ForgeはLaravelのサーバー管理とデプロイサービスであり、Vaporは60万以上のPHPアプリケーションを提供するサーバーレスデプロイプラットフォームです。Laravelのビデオで、実際の動作をご覧ください。 この統合により、PHP 開発者はアプリケーションのビルド、デプロイ、管理、デバッグをより効率的かつ確実に行えるようになります。この統合を通じてPHPのエコシステムをサポートし続けるため、今後も多くの改善が行われることを期待しています。 拡大するLaravelユーザーをサポート Laravelは、10年以上にわたってアプリケーション開発の中核を担ってきました。PHPフレームワークの中で最も人気があり、急成長しているフレームワークの1つで、そのクリーンで表現力豊かな構文とモダンなコーディング原則により、書きやすく読みやすくなっています。大企業や新興企業の開発者は、Laravelを使用してアプリケーションを迅速に構築し、デプロイしています。少なくとも毎年1つのメジャーリリースと、数週間ごとの反復リリースがあり、Laravelのイノベーションは衰えていません。例えば、Laravel 11では以下のようなリリースが行われています。Reverb (ファーストパーティのWebSocketサーバー)グレースフル暗号化キー・ローテーション秒単位のレート制限合理化されたアプリケーション構造 Sentryには、100以上のSDK、フレームワーク、ライブラリがあり、開発者が使用するツールに精通しています。Sentryの中で、Laravelは3番目に人気のあるバックエンドSDKで、毎年増え続けています。 まだ始まったばかり PHP開発者の間でのLaravelの持続的な人気は、驚異的としか言いようがありません。Laravelが長年愛されているのは、その技術のパワーとPHPコミュニティ内で築かれた信頼があってこそだと物語っています。Sentryは、LaravelとPHPコミュニティにコミットし、皆様を念頭に置いて構築し続けています。新しいForgeとVaporの統合により、私たちはLaravelアプリの管理、デプロイ、デバッグのための新しいスタンダードを築き上げます。詳しい使い方はドキュメントをご覧ください。
- [観察せず、デバッグしよう。](https://ichizoku.io/sentry/debugging-full-stack-distrubuted-systems-sentrys-spans-first-tracing-workflow/) - 「観測可能性」という言葉は奇妙なものです。 複雑な分散システムやマイクロサービスを監視するための洗練されたアプローチを説明する方法として、私たちはその価値を理解しています。 しかし、この用語は本質的に受動的なものです（正直に言いましょう、ちょっと負荷の高いマーケティング用語です）。 単に「観察」するだけでは、問題解決にはつながりません。 特に、アクションにつながらないデータが大量にある場合はなおさらです。 私たちは、開発者が行動を起こし、バグやエラー、その他の問題を解決するのを助けるためにSentryを構築しました。 そして、この哲学は、新しいスパン・ファーストのトレースとメトリクス・エクスペリエンスという、観測可能性ツールの構築のアプローチにも受け継がれています。 両者とも現在オープン・ベータ版となっており、皆様からのフィードバックをお待ちしています。 新しいスパン・ファーストのトレース体験 分散システム（マイクロサービスを含む）のデバッグは、複雑で相互接続された環境全体の問題を診断する必要があるため、大変困難です。 例えば、eコマースアプリでユーザーが注文時に遅延が発生した場合、根本的な原因を突き止めるために複数のサービス（潜在的にはユーザーサービス、注文サービス、決済サービス、在庫サービス）をチェックする必要があり、デバッグプロセスが複雑で時間がかかります。 フルスタックアプリケーションのデバッグは、問題がアプリケーションのフロントエンドまたはバックエンドのいずれかに起因する可能性がある場合、同様の課題を提示する可能性があります。 トレーシングは、問題を引き起こしている特定のオペレーションを特定するために、システムやサービスを横断して、ユーザーとの対話からリクエストの完全なエンドツーエンドのパスを追跡するので強力です。 トレースは、すべての開発者のデバッグツールキットの一部であるべきです。 トレースをよりアクセスしやすく、効果的にするために、私たちは新しい、スパンベースのトレースモデルを構築しました。 以前は単純化するために、トランザクションベースのモデルでトレースを構築していました。 （ちなみに、トランザクションは複数のスパンで構成されます。例えば、HTTPリクエストに応答するウェブサーバーや、関数の単一の呼び出しがスパンになります。トレースについて詳しくはこちらをご覧ください） しかし、トランザクションベースのモデルでは、データベースクエリやネットワークリクエストのような重要な情報を照会することは困難でした。 スパンが主要なトレース単位である新しいモデルでは、クリティカルなデータを照会し、根本原因を簡単に掘り下げることができます。 トレースエクスプローラを使用した、既知の問題調査 特定のスパン属性を使用して特定のトレースを検索することで、問題をプロアクティブに特定できるようになりました。 例えば、ユーザーがページの読み込みが遅いと訴えたり、パートナーAPIが停止を報告した場合、ユーザーEメール、APIエンドポイント、またはルートでクエリし、適切なコンテキストでトレースを見つけ、問題を迅速に解決することができます。 ユーザーからチェックアウト・エクスペリエンスが遅いと報告されたとします。 ユーザー ID やスパンの説明のようなカスタムタグや既定のタグを含む、カーディナリティの高いデータを使用してスパンを検索することで、特定のトレースを見つけることができます。 フルコンテキストでより速くデバッグする トレースエクスプローラーから、クエリされたトレースまたは特定のスパンをクリックして、再設計されたトレースビューに直接移動することができます。 ウォーターフォール・ビューは、フロントエンドからバックエンドまで、またサービス全体にわたるアプリケーション・リクエストの完全な可視性を提供します。 特定のスパンにドリルインすると、カスタムタグ、プロファイル、リプレイなど、効率的なデバッグのための適切なコンテキストと詳細なデータが得られます。 メトリクスはトレースビューでも利用でき、デバッグに役立つコンテキスト情報の追加ソースを提供します。 さぁ、はじめてみましょう！ Sentryアカウントをお持ちであれば、トレースを始めるのは簡単です。 私たちのドキュメントの指示に従ってスパンの送信を開始するだけです。 ぜひご利用ください！ IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。またご導入についての相談はこちらのフォームからお気軽にお問い合わせください。
- [Fortune 500,000社のための今後の展望。あと80％です...](https://ichizoku.io/sentry/building-for-the-fortune-500000-80-to-go/) - デイビッド・クレイマーがサイドプロジェクトに最初のコミットを行ったのは16年前のことでした。 彼とクリス・ジェニングスがこのサイドプロジェクトを単純な問題を解決するために存在する会社に変えたのは12年前のことです。 それ以来、我々は多くの人が考える 「観測可能性 」とは少し異なる道を歩んできました。Sentryは、ログを収集して監視ボックスをチェックすることを望むプラットフォームでも会社でもありません。 12年経った今でも私たちは、開発者のためのデバッグの簡素化という1つの重要な問題に注力しています。 しかし、より重要なことは、開発者コミュニティからのサポートなしにはできないことです。 私たちは現在10万以上の組織をサポートしており、昨年のARRは1億ドルを突破しました。 素晴らしいことですが、なぜ気にする必要があるのでしょうか？ どちらも恣意的な数字に過ぎません。しかし、これらのマイルストーンは、単に自分たちを褒め称えるための口実ではないのです。 さてこの話は一旦横に置いておき、代わりに皆さんとSentryの次の展開に焦点を当ててまいります。 （それでも足りない場合は、私たちのコミュニティでお祝いする楽しい方法がありますが、その前にどうかお付き合いください） Sentryのチーム 2019年、デイビッド・クレイマーはCEOからCTOに移行する際、Sentryを率いるために私を雇いました。ここまでは順調でした。 本日、クレイマーと私は、次期CTOとしてセントリーに入社するデイヴ・ローゼンタールを迎え入れます。 クレイマーは、新設された最高製品責任者の役割に移行します。デイヴは、世界で最も革新的な企業のいくつかで、新興企業の創業者と技術リーダーの経験があります。彼は今月初旬に入社し、私たちは彼をチームに迎えることに興奮しています。 一方、CPOへの正式な肩書き変更については、クレーマーからのコメントをお読みください。(私が「公式」と言ったのは、多くの点で、彼は常にSentryのCPOだったからです）。 Sentryのプロダクト そして、クレイマーのオープンソースのサイドプロジェクトとして始まったSentryは、10万以上の組織と数百万人の開発者が自信を持って出荷できる会社に成長しました。当初から、そして現在もSentryは「発見」と「解決」という2つの成果を重視しています。 私たちは、開発者が問題を知るだけでなく、ワークフローの中で問題を解決する方法をリアルタイムで示すことを可能にします。これが、Sentryが100,000以上の組織で信頼されている理由であり、この哲学を倍加することが、次の100,000以上の組織にサービスを提供するために成長する方法なのです。 Sentryバージョンの理想的な開発者アシスタントは、あなたの指先で利用可能なすべての関連するコンテキストであなたの問題をデバッグするのに役立ちます。私たちは、あなたのワークフローで最も重要な問題、あなたが働く場所（PRコメントを考えてください）、そしてソフトウェアの問題を素早く修正するのに役立つ信号の最も鋭い接続されたビューを提供することに対応し続けます。 ですから、問題に行き着いたものの、ビデオのような問題の再現が必要な場合、あるいはスパンウォーターフォールを調査する必要がある場合、Sentryのデータストリームを使えば、どんな種類の問題でも簡単にデバッグすることができます。 多くの企業は、ボトムアップ戦略（製品主導の成長、あるいはPLGと呼ばれることもある）で成功を収め、規模が大きくなると、スイッチを入れて企業バイヤーに売り込み（そして企業バイヤーのために構築し）始めるのが一般的です。 しかし、Sentryは違います。PLGはとにかく、ソート・リーダーシップの訓練なのです。もしあなたが、販売戦略に関係なく、市場に出せる最高の製品を作っていないのであれば、なぜビジネスをしているのでしょうか？私たちは、想像上の 「ペルソナ 」を満たすために製品に機能を追加したりはしません。Sentryは開発者用ツールなのです。Sentryは、Fortune 500社だけでなく、Fortune 500,000社向けにも開発しています。そして私たちは、オープンソースにおける持続可能性の危機を解決するために私たちの役割を果たしながら、オープンに構築し続けます。 ワークフローが変わっても問題は解決しない Gitが登場するずっと前の話です。 当時のエンジニアは、パンチカードを使ってソフトウェアをリリースしていました。 バグを修正するために「パッチ」（文字通りのパッチ。開発者がソフトウェアを構築する方法は今も変わり続けています。私たちが（購入者ではなく）実践者に焦点を当て続けるということは、Sentryが彼らが自信を持って出荷できるように支援するということです。あなたのペアプログラミングのパートナーがCopilotであろうと、Codyであろうと、Devinであろうと、Augmentであろうと）バグを軽減する必要があることに変わりはありません。 簡単に言えば、私たちはまだ作り終えていません。どのように進化しようとも、現代の開発者のワークフローにマッチする革新的なソリューションを出荷し続けます。 ささやかな感謝のしるし 当社のクラウド・サービスで10万を超える組織をサポートしていることは光栄なことであり、当然のことではありません。 私たちは、ユーザーの一人ひとりにコミットしています。私たちが、これまで歩んできた道のりの一部であったすべてのユーザーに感謝する最善の方法は、彼らのために構築し続け、彼らの進化するワークフローのありふれた細部にまでこだわり続けることです。 そして2番目に良い方法は？無料のお菓子です！今年の残りの期間中、私たちはコミュニティに10万ドルのSentryグッズをプレゼントします。詳細はこちらをご覧ください。 未来の詳細がどのようなものになるかはまだわかりませんが、私たちはこれまで以上に、道を切り開く開発者の役割に自信を持っています。私たちの周りの世界を定義するソフトウェアを出荷する彼らのために、彼らとともに構築することは、私たちの特権です。 IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。またご導入についての相談はこちらのフォームからお気軽にお問い合わせください。
- [Sentryのメトリクスで、16万ドル節約した方法](https://ichizoku.io/sentry/sentry-on-sentry-how-metrics-saved-us-160k/) - 私をご存知の方は知っているでしょうが、私はいつも高速に動作するコードかどうか気にしています。 最近、簡単なクエリーを実行したところ、1つのタスクに年間16万ドル近く費やしていることが判明しました。 幸運なことに、私たちは3月にメトリクス・ベータを立ち上げました。 ここ1ヶ月ほど10人のSentryエンジニアは、カスタム・データ・ポイントを追跡するためにMetricsを活用し、この無駄なインジェスト・コストにつながる問題を突き止めるために、多くの機能にわたって協力しました。 解決すべき重要な問題の特定 save_event_transaction 私はSentryのSearch and Ingestチームにいます。 同僚のJernej Strasnerと私は、Sentryのインジェストパイプラインを最適化できるかどうかを調べたいと思いました。最近のクエリで、save_event_transaction タスクに週に6,000ドル近く費やしていることがわかりました。 パフォーマンスとメトリクスが、どのように問題特定に役立ったか これはMetricsの完璧なユースケースだと思いました。 このタスクの計算時間を可視化するためにMetricsをセットアップしたところ、save_event_transaction タスクに過去7日間で1.37週間の計算を費やしたことがわかりました。 save_event_transationタスクから始めるべきだということがわかったので、このオーバーヘッドを減らす方法を特定するために、発見の旅に出ました。 トレース・ビューは、どの関数が最大の違反者であるかのヒントを与えてくれました。下のスクリーンショットでわかるように、この特定のトレースでは 8.00s秒のうち7.37s秒がset_subkeysに費やされていることが分かります。 set_subkeys 関数はmemcachedを通してキャッシュを設定し、私たちのインフラストラクチャで重要な役割を果たしている。 この時点で、 set_subkeysの実際の影響を突き止めたいと思いました。 そこで、Metricsを使用して、抽出されたトランザクションとスパンのメトリクスをプロットし、save_event_transaction. に関連してset_subkeysが費やす時間の割合を得ました。実際には、インジェストされたトランザクションごとに、最小で27％、最大で81％をキャッシュの設定に費やしていることになります。 要約すると、トランザクションの処理時間の平均51％をキャッシュの設定に費やしているということです。 財務用語で言えば、私たちはキャッシュの設定に1週間あたりおよそ3060ドル（年間16万ドル）を費やしていることになります。 セーブイベントからSentryを保存する save_event_transaction:によって引き起こされる時間（とお金）のコストを削減するのに役立つ、Metricsの助けを借りて特定した主な方法は4つありました。 キャッシュを設定するタイミングを慎重にする。 memcacheサーバー間のトラフィックのバランス配分を改善する。 サードパーティツールのバックグラウンドスレッドを有効にする。 Twemproxyから代替へ移行する。 これらの変更により、Sentryのコードベース全体のパフォーマンスが向上し、全体的なコスト削減につながりました。 インパクトのある変更は一行で可能 慎重に検討した結果、トランザクションごとにキャッシュを設定し、別の書き込み操作を必要とする代わりに、最初の読み取り操作の際にキャッシュを設定すればよいことにしました。この変更はGitHubでご覧いただけます。 このマイナーチェンジを行った直後から、平均で300msから100ms以下に短縮されたのがお分かりいただけると思います。 そしてこの変更は、他のceleryタスクにも大きな影響を与えました。 トラフィック配分を改善するためにオペレーション・チームを巻き込む オペレーションの2人の同僚、Anton OvchinnikovとAlex TarasovもSentryのmemcachedサーバーの前にあるロードバランサー、twemproxyのKubernetes設定に問題があることを発見しました。彼らはtwemproxy-saveサービスをclusterIP Noneから通常のclusterIPに切り替えて、memcacheサーバ間のトラフィックを適切にバランスよく分散させる実験を行いました。 その結果、ユーザースペースに費やされるCPU時間の割合が大幅に減少し、接続がより均等に分散されたため、CPU使用率が安定しました。 実験の結果、sentry.tasks.store.save_eventのp95が大幅に減少しました。 C また、sentry.tasks.store.save_eventの時間が10ms（～13%）短縮しました。 さらに、sentry.tasks.store.save_event_transaction p95も減少しました。 サードパーティツールからのブロック解除 メトリクスを詳細に分析した結果、インフラ監視ツールのSDKがstatsdプロキシに逐次的なリクエストを送信し、ブロックしていたため、Sentryのホットパスで高い実行回数が発生していることがわかりました。 私たちはクライアントを更新し、メインのスレッドをブロックしないように別のスレッドでメトリクスを送信するバックグラウンドスレッド機能を有効にしました。 一部のプロファイルでは、インフラ・モニタリング・ツールがプロキシにイベントを送信するのに非常に時間がかかり、トランザクション全体の30%を占めていました。 この変更により、sentry.tasks.store.save_event_transaction.が11ms改善されました。 Twemproxy
- [【Sentry】TTFB(Time to First Byte)を減らし、ユーザ体験を改善する手法について](https://ichizoku.io/sentry/how-i-fixed-my-brutal-ttb-performance-monitoring/) - 最近、私はただひとつの指標、TTFB（Time to First Byte）を改善することに集中することで、すべてのホームページのCore Web Vitalsを改善しました。 データを取得する方法に2つの小さな変更を加えるだけで、p75のTTFBを3.46秒から704msに短縮することができました！ （「p75」と「TTFB」については後述します） この記事では、私がどのように問題を発見し、それを解決するために何をしたのか。 そして、その過程で下した重要な決断について説明します。 Sentryパフォーマンス・モニタリングの使用 新しいサイトを立ち上げるとき、新機能を開発するとき、サイトが本当に遅いと気づいたときがありました。 2021年から22年にかけて、私はパフォーマンスを改善するためにWebサイトを一から作り直しました。 しかし時間が経つにつれ、私はサイトのさまざまな部分に実験的な技術をたくさん追加し、パフォーマンスが再び、恥ずかしくなるほど悪くなってしまいました。 ここ数ヶ月の間、Webサイトをロードしているときに私自身がこのことに気づいていましたが、Sentryパフォーマンス・モニタリングをサイトに追加したときに初めて全体像を見ることができました。 Sentryのようなパフォーマンス監視ツールを使用することの素晴らしい点は、OS、ブラウザ、モバイルデバイス、インターネット接続、その他ユーザーエクスペリエンスに影響を与える多くの要因すべてにわたって、Webサイトの実際のユーザーデータを表示してくれることです。 以前は、Google Lighthouseのようなツールを開発中やWebサイト構築中に使用して、新しいビルドごとにパフォーマンスを分析していました。実際のユーザーデータの方がはるかに価値があります。 Here’s what the performance looked like on my homepage before any modifications from February 14-21 2024. 2024年2月14日から21日まで、修正前の私のホームページのパフォーマンスはこんな感じでした。 最も緊急に改善すべきと目立ったのは、TTFB（Time to First Byte）でした。 TTFBとは、ブラウザがサーバーにリクエストをしてから、最初の1バイトのレスポンスを受け取るまでの時間を指します。 理論的には、TTFBが低ければ低いほど、ブラウザはより早くページの描画を開始することができ、ユーザーはより早くブラウザで何かを見ることができます。 結果的に、離脱する可能性が低くなります！ ここに表示されているTTFBの値は、75パーセンタイル（p75）のもので、3.46秒が全ホームページビューの75%に見られた最悪のスコアであることを意味します。 これはまた、25％のユーザーがページの読み込みに3.46秒以上待たされたことを意味します。 この悪いスコアは、レスポンスが送り返される前にサーバーで行われている処理が多すぎることを示していました。 ひとつはニュースレター・プロバイダからデータを取得して最新の購読者数を取得するもので、もうひとつはTwitch APIからデータを取得して最新のストリーム動画や現在進行中のライブ・ストリームの最新のサムネイルを表示するものです。 どちらの関数も、最初のHTTPレスポンスをメモリに取り込み、サードパーティのAPIからデータを取得し、それに応じてHTMLを書き換えます。 このアーキテクチャの目的は、静的に生成されたホームページに動的なデータを表示するために、メインのJavaScriptスレッドをブロックする可能性のあるクライアント側のデータ・フェッチを最小限に抑えることでした（スケルトン・ローダーは嫌いです）。 これは 「ユーザーに最新のものを見せる 」という観点では素晴らしいものでした。 しかし、HTTPリクエストが事実上重複してしまうため、ブラウザに何かを表示するのにかかる時間が2倍になってしまうことが問題でした。 そして静的な地域にある2つの別々のサードパーティ・サービスが、世界のどこからでも（エッジから）呼び出されることによるAPIの待ち時間の変化も加わり、ちょっとした混乱に陥り始めます。 正確なニュースレター購読者数は、私以外の誰が求めているのでしょうか？
- [Supabase データベースとエッジ機能の監視](https://ichizoku.io/sentry/monitor-supabase-databases-and-edge-functions/) - クラウドサービスが登場し始めた頃、多くの開発者は、オンデマンドでWebアプリケーションをデプロイするために、あらゆる種類のインフラをスピンアップして拡張できることに驚嘆しました。 しかし、大手のクラウドサービスプロバイダーは利用が複雑で、スケールアウトには費用がかかり、デフォルトのモニタリングソリューションはあまり洞察に富んでいないのが実情です。 その上、我々開発者は、物事が簡潔であることを望んでいます。 SupabaseとSentryはデプロイとモニタリングを簡素化します。 SupabaseはデータベースとEdge Functionのデプロイを容易にし、Sentryとの新しい統合はローカルと外部でのコードの監視を簡単にします。 新しいSupabaseとSentryの統合により、Supabaseを通してデプロイしたコードを数行のコードで簡単に監視できるようになりました。そのため、新しいWebサービスが爆発的に普及した場合、Sentryは認証されたEdge FunctionsとDBの呼び出しが監視されていることを確認し、手に負えない問題が発生した場合に警告を発します。 機器データベースの統合 SupabaseはJavaScriptクライアント @supabase/supabase-js を提供し、アプリケーションがプラットフォーム上で動作する Postgres データベースとやり取りできるようにします。 Supabaseチームのサポートにより、Sentryとの統合が可能になり、SupabaseのJavaScript SDKを利用してSentryでパフォーマンスモニタリング、ブレッドクラム、エラーのトレースを収集できるようになりました。 セットアップ コピーして、貼り付けて、さあ始めましょう。 以下のスニペットは、Sentry SDKとSupabaseクライアントをインストールして初期化し、前述のすべての洞察を収集するために必要なすべてを記しています。 エラーとトレースがSentryに確実に取り込まれるようにアプリケーションをセットアップするための詳細については、@supabase/sentry-js-integration documentationとrepoを参照してください。 Supabaseクライアントでは、ログインやユーザー管理機能の構築、大容量ファイルの管理、Deno Edgeファンクションの呼び出しも可能です。 Sentryは、あなたのコードがエッジ上で実行されているときでも、同様に監視されていることを確認するのに役立ちます。 エッジ機能サポート 2023年11月のローンチ・ウィークでは、できるだけ多くのプラットフォームで、できるだけ多くのデベロッパーにサポートを提供するために、私たちがどのように取り組んでいるかについてお話ししました。 特筆すべきは、これにはDenoも含まれているということだ。 Denoは、流行に敏感な開発者の間だけでなく、Supabaseのようなプラットフォームの成長によっても人気が高まっています。 Supabaseは、エッジ機能のランタイムとしてDenoを使用しています。Sentryは、当社のDeno SDKを通じてこれをサポートしています。 Denoは、Edgeランタイム上でコードを実行する機能を提供しますが、Sentryは、コードを確実に監視し、エラーやパフォーマンス課題が発生した場合にアラートを出すことができます。設定の詳細はこちらをご覧ください。 ピースをつなぐ Supabaseは、週末の片手間で構築でき、世界中に拡張できることを約束します。 Sentryとの統合により、エラーや遅いDBクエリがいつ、どのような理由で発生したかを確実に知ることができます。Sentryを初めて使う方はアカウントを作成することができます。 また、この統合に追加してほしい機能などがあれば、GitHubでもお問い合わせを受け付けています。ぜひご連絡ください。 IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。またご導入についての相談はこちらのフォームからお気軽にお問い合わせください。
- [SentryとOpenTelemetryによるAspire Insightsの本番稼動対応](https://ichizoku.io/sentry/aspire-insights-in-production-with-sentry-and-opentelemetry/) - Aspire 101 .NET8のリリースに伴い、Microsoftは分散アプリケーションの作り方を大きく変える.NET Aspireと呼ばれる新しいフレームワークをリリースしました。 Aspireは、.NETでの分散アプリケーションの構成とデプロイを簡単にします。 詳細については、Aspireのドキュメントを参照してください。 Aspireを使用してアプリケーションをビルドすると、以下のような利点があります。 OpenTelemetryのログ、メトリクス、トレース ヘルスチェック サービスディスカバリー .NETでのオーケストレーション（KubernetesやDockerの設定ファイルに潜る必要なし） その他多数 Aspireには、"リソース"（Aspireでは分散システムの様々なコンポーネントを "リソース "と呼ぶ）から生成されるテレメトリを簡単にナビゲートできるダッシュボードが付属しています。 これらすべてが、かなりクールな開発者体験をもたらします。 そして、我々は、OpenTelemetry データを Sentry と簡単に共有することができます。Sentry は、テレメトリーデータから得られる全ての洞察に加えて、Sentry が提供する全てのクールなもの（クラッシュレポート、ソースマップ、.NET でビルドされていない分散アプリケーションコンポーネントを計測する機能など）を提供してくれます。 また、Sentryを使えば、開発現場でも生産現場でも、このインストルメンテーションを利用することができます（現在、Aspireのダッシュボードは開発者のみの体験となっています）。 では、どのように配線するのか見てみましょう！ 注：以下のすべてのソースコードはGitHubで入手可能です。 基本的なAspireソリューションの作成 Aspire を使い始めるための良いチュートリアルがいくつかあるので、ここでは詳しく説明しません。 まず、ツールのセットアップが完了したら、コマンドラインから新しい aspire ソリューションを作成します。 これは、最小 API (ApiService)、Blazor フロントエンド (Web)、Aspire ソリューションのバックボーンとなる 2 つのプロジェクト (AppHost と ServiceDefaults) から構成される aspire-starter テンプレートを使用して、新しい Aspire ソリューションを作成します。 ServiceDefaults には、ソリューション内のすべてのプロジェクトに共通する設定を配線するためのさまざまな拡張メソッドが含まれています。 AppHostはすべてのオーケストレーションに使用され、開発マシン上ですべてをパワーアップしたいときに実行するアプリケーションです。 便利なダッシュボードも含まれています。 ダッシュボードには、分散アプリケーションの各「リソース」に対応するURLへの便利なリンクに加え、それぞれのログ、トレース、メトリクスが表示されます。 Sentry でそれを見ることができたら、素晴らしいと思いませんか？
- [デバッグの問題を軽減する5つの改善点](https://ichizoku.io/sentry/five-improvements-to-make-debugging-less-terrible/) - 昨年Sentryでは、セッションリプレイやクーロンモニタリングのような新しい製品をリリースしました。 しかし、新しい製品を作るだけでなく、ソフトウェアの問題をより速くデバッグするために、コアプラットフォームを改善する方法を常に探しています。 Sentryのローンチウィーク中にご覧いただけたと思いますが、私たちは以下の問題に対処する5つのQoL改善をリリースしました。 修正ファイルに未解決の問題がないことを確認するには？ コードが本番環境で動作しない場合、どうすればよいか？ コンテキストの切り替えを減らすには？ フロントエンドの問題をサーバーサイドのエラーにすばやく突き止めるには？ これが最新情報です。 修正ファイルに未解決の問題がないことを確認するには？ GitHubでレビューコメントを発行する GitHub でプルリクエストを開くと、Sentry はあなたが変更しようとしているコードに起因する既存の未処理の問題をコメントするようになりました。 つまり、PR の一部として変更されたファイルに未解決のエラーやパフォーマンスの問題がある場合、提案した変更のリスクをよりよく理解したり、少し修正する時間を取ることができるようになるということです。 詳しくはドキュメントやGitHubのディスカッションをご覧ください。 コードが本番環境で動作しない場合、どうすればよいのか？ CI/CDツールやプラクティスがこれだけ進歩しているにもかかわらず、CD Foundationが調査した企業のうち、デプロイを毎日行っているのはわずか30%に過ぎないというのは唖然とします。 開発者がより頻繁に本番環境にプッシュしない最大の理由の1つは、自分たちのソフトウェアが本番環境で実際に動作するかどうかわからないということのようです。 Release Healthの最新アップデートにより、デプロイメントが本番稼動した瞬間に、ソフトウェアが本番稼動しているかどうか、リリースの健全性を文字通りお伝えすることができます。 不良リリース検出 リリースが健全でない場合は、リリースページとリリースの詳細ページに表示されるため、リリースに関わったすべてのチームメンバーが何が問題だったのかを確認し、調査することができます。 リリースの健全性を判断するために、エラーやクラッシュ率などに基づいて、独自のしきい値を設定することもできます。 また、CI/CDパイプラインで私たちの新しいAPIをポーリングすることで、リリースの閾値のステータスを取得することができます(Sentry が不正なリリースを検出したときに、すぐに通知と Webhook を起動する機能を公開予定です)。 コンテキストの切り替えを減らすには？ Slackとの統合強化 私たちがより早く重要なリリースにたどり着こうとしているのは、不良リリースの検出だけではありません。 Slackとの統合により、コードベース内の新しい重要な問題に対してアラートを受け取ることができます。このアラートにはより多くのコンテキストが追加され、バグに関する適切な情報を適切なタイミングで、適切な場所で取得できるようになりました。 更新されたSlack通知では、問題の詳細が表示され、Slackクライアント内で一般的なアクションにアクセスできます。以下のこれらでわかります。 イベント数とユーザー数 推奨される担当者 そして、以下で出来るようになります。 ノートとルールブックのURLを追加する issueのアーカイブ方法の設定 課題セレクタで検索（課題を割り当てるチームメンバーを検索できます） Slackから直接、課題の割り当て、解決、アーカイブを行うことができ、より多くのデータを得ることができます。 問題の詳細にリプレイを埋め込む 問題の詳細をスクロールすると、ページにリプレイが埋め込まれるようになりました。セッションリプレイ機能は、映像でユーザーセッションの再現を提供します。 これによって不具合の再現を支援し、ユーザーが問題を経験する前後に何が起こったかを確認することができます。問題の詳細ページを離れることなく、より迅速にデバッグすることが可能になります。 フロントエンドの問題をサーバーサイドのエラーに素早く突き止めるには？ 問題の詳細におけるトレースナビゲータの改善 各問題詳細ページのトレースナビゲータを更新し、トレースで特定のエラーが検出された場所や、このエラーに関連する可能性のある他の問題を簡単に視覚化できるようにしました。 これにより、キーボードの上で顔を丸めることなく、「バックエンドのエラーがフロントエンドに問題を引き起こしているのか」という漠然とした質問に明確に答えることができます。 トレースの改善やパフォーマンス監視の主なアップデートの詳細については、ローンチウィーク2日目に発表した内容をご覧ください。 まとめ 私たちは、あなたが本番を壊すことが少なくなるよう、最善を尽くしています。 新しいパフォーマンス機能から、AI対応のコードレビューやAutofixの導入、そして上記のプラットフォームのアップデートまで、デバッグの酷さを軽減するために前進し続けています。 Sentryの最新情報を入手するには、Change logをチェックしてください。 また、GitHub、Twitter、Discordでもお問い合わせいただけます。
- [【Break Production Less】Codecovのプレリリース・フォーカスの紹介](https://ichizoku.io/sentry/break-production-less-introducing-codecovs-pre-release-focus/) - テストプラクティスとツールの改善を支援しようとするソリューションは、世の中にたくさんあります。 しかし私たちは、高品質なソフトウェアは、テストがいかにうまく行われているかに限らないと考えています。 そのため、私たちはコードカバレッジの枠を超え、バンドル分析、テスト分析、AIを活用したコードレビューを備えた初のプレリリースプラットフォームの基盤を構築しています。 JavaScriptバンドル分析 バンドルサイズが重要なのは、アプリケーションのパフォーマンス、帯域幅の使用量、ロード時間に直接影響するからです。 バンドルが大きいとロード時間が長くなり、パフォーマンスが低下し、ユーザーエクスペリエンスが低下します。私たちは、開発者がこのような課題に立ち向かえるよう、JavaScript バンドル解析を展開しています。 私たちのBundle Analysisは、Rollup、Vite、Webpackと連携し、エンドユーザーに影響を与える前に問題を診断するのに役立ちます。 今すぐ Bundle Analysis を試して、GitHub issue で感想を聞かせてください。 バンドル解析はすべてのCodecovユーザーが無料で利用でき、ほとんど設定なしで動作します。 テスト分析 欠陥のあるテストや、CIの実行に時間がかかるテストは、デプロイ失敗のリスクを高め、新機能を迅速にデリバリー（リリース）することを難しくします。 そこで、テストの実行時間や失敗率のデータを提供し、不安定なテストを特定する Test Analytics を紹介します。 テストの失敗に関する洞察を GitHub 内で直接提供することで、コードの行をスクロールすることなく、テストに欠陥がある箇所や失敗している箇所を確認することができます。これによって、問題の発見と対処がより速くできるようになります。😏 Codecov PR Commentでテストの失敗情報を取得するには、テスト結果をJUnit XMLファイルとして生成し、そのファイルをCodecovにアップロードするだけです。 Test Analyticsを使い始めるには、こちらのドキュメントをご覧ください。 テスト失敗レポートは現在稼働中ですが、私たちはテスト管理プロセスを改善し、コードレビューのサイクルをスピードアップするために、Flaky Test Detectionを積極的に開発しています。 テストの失敗や欠陥のあるテストについてどう思いますか？ GitHub issue でご意見をお聞かせください。 AIによるコードレビュー機能 コードレビューで最悪なのは、自分のPRを誰かにレビューしてもらうことです。 ああ、他のチームの誰かにあなたの変更をレビューしてもらう必要があるなら、幸運を祈ります。 もしあなたがPRを開いた瞬間に、誰かもしくは何かがレビューしてくれたらいいと思いませんか？ Codecovの新しいAIコードレビュー機能は、まさにそれを可能にします。 明らかなミスを特定し、開発者がコード変更のより複雑で重要な側面にコードレビューを集中できるようにする、物知りな友人のようなものだと考えてください。 これは、レビューの迅速化、承認の迅速化、顧客への機能提供の迅速化、そして「最新の変更をレビューしてもらえますか」というメッセージの減少を意味します。 まとめ Sentryはおそらく本番環境であなたのコードを監視していると思いますが、デプロイする前にはギャップがあります。 そこで、SentryのCodecovチームは、コードカバレッジだけでなく、リリース前のすべてにフォーカスを移すことで、そのギャップを埋めようとしています。 これはほんの始まりに過ぎません。私たちが境界を押し広げ、一度に1行のコードでソフトウェア開発の未来を形作り続けるように、私たちに加わってください。 いつものように、あなたのご意見をお聞かせください。 また、Codecovを初めてお使いになる方は、今すぐ無料でお試しいただくか、デモ利用のお申し込みをください。 IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。またご導入についての相談はこちらのフォームからお気軽にお問い合わせください。
- [【必見】Sentry Performance でユーザ体験を改善する方法](https://ichizoku.io/sentry/inp-tracing-and-mobile-app-starts-move-faster-and-solve-real-user-pain-with-sentry-performance/) - 本日、3つの新しいSentry Performance機能により、ユーザーに影響を与える問題の発見と解決がさらに簡単になりました。 INP（Interaction to Next Paint）が新たなCore Web Vitalになった 改善されたトレース体験 モバイル開発者がコールドスタートとウォームスタートでアクションを起こすための新しいワークフロー Core Web Vital に INP のサポート追加 Googleは3月12日、First Input Delay（FID）に代わる新しいCore Web VitalであるInteraction to Next Paint（INP）を発表しました。 FIDは最初のユーザーインタラクションの応答遅延を測定するのに対し、INPはページ上のすべてのインタラクションのパフォーマンスを測定するため、INPはページ全体の応答性をより正確に測定することができます。 ユーザーがページとインタラクションするとき、アクションが完了したこと、または何かが進行中であることを示す視覚的なフィードバックを表示することが重要です。 例えば、ショッピングカートに商品を追加する場合、カートのカウントはほぼ即座に更新され、商品が追加されたことを示すべきです。 ページが反応せず、視覚的なフィードバックがない場合、ユーザーはページが壊れていると思うかもしれません。 SentryがINPをサポートし、ページがすべてのユーザーインタラクションにどのように反応するかをモニターできるようになったのはそのためです。 SentryのWeb Vitalsのホームページには、INP、LCP、CLSのような指標を考慮したパフォーマンススコアが表示されます。 トレースでは、INPスコアから開始し、トレース内のスパンを使って、関連するエレメントとインタラクションのタイプを素早く特定することができます。また、Sentryのプロファイリングを使用している場合は、そのインタラクションに応答している間にブラウザがどのコードでブロックされたかを見つけることで、根本原因を診断することもできます。 このINPの新しいサポートにより、迅速な対応を講じることができ、問題に関連する可能性のあるすべてのトレースを検査したりする手間を省くことができます。 根本原因を追跡して、低い INP スコアを調査します。 もちろん、この同じ論理ワークフローで他のウェブ・バイタル（LCP、CLSなど）もモニタリングできるため、ユーザーに影響を与えるパフォーマンス問題の根本原因を迅速に突き止めることができます。 フロントエンドからバックエンドまで、エンドユーザーのパフォーマンスをデバッグする ページの読み込みが遅いなど、ひどいUX（ユーザーエクスペリエンス）は、非効率的なSQLクエリ、キャッシュ（またはその欠如）、その他のバックエンドのパフォーマンスの問題などに起因することがよくあります。 そのため、アプリケーションスタック全体の異なるサービスで発生した問題を結び付けることが、ユーザー向けのパフォーマンス問題をデバッグするために必要になります。 パフォーマンスのボトルネックを引き起こしているサービスまで、ユーザー側の問題を簡単に追跡できるようにするため、Sentryのトレースエクスペリエンスを簡素化しました。 当社の更新されたトレースビューは、マルチサービスアプリケーションの統一されたビューを提供し、コンテキストを失うことなく、スタック全体の重要な問題を簡単に特定できるようにします。 Sentryのトレースビューは、フロントエンドとバックエンドのサービスを統合的に表示します。 例えば、LCP（Largest Contentful Paint）のスコアが落ちたとしましょう。 Sentryを使うことで、トレースビューでスコアの悪いページロードの調査を開始し、APIリクエストのバックエンドの操作に焦点を当てることができます。 トレースビューでは、遅いデータベースクエリやフレームドロップのような関連するパフォーマンスの問題も表示されるので、実際のユーザーに影響を与える問題を即座に修正するために何をすべきか（または誰のせいにすべきかᘏ）を正確に知ることができます。 Sentryの新しいトレースビューでは、パフォーマンスの問題を引き起こしているAPIリクエストについて、バックエンドの操作に集中することができます。 【モバイルパフォーマンス】コールドスタートとウォームスタートからコード行数まで モバイル開発者にとって、本番環境でパフォーマンスの問題を発見し、それを修正するのは時間の浪費につながります。 特に、アプリの起動が遅いという苦情があったときにデバッグしようとすると大変です。これを解決するために、私たちは、コールドスタートとウォームスタートの根本的な原因を、原因となっているコードまで検出して追跡できるように、まったく新しいワークフローを構築しました。 簡単に復習すると、コールドスタートとは、アプリがまだ実行されていない状態で起動することです。 ウォームスタートとは、アプリがバックグラウンドからフォアグラウンドになることです。 例を見てみましょう。
- [【Beta版公開中】Metricsで重要指標を測定し、問題を迅速に解決する方法](https://ichizoku.io/sentry/measure-what-matters-and-fix-issues-fast-with-metrics-now-in-beta/) - 4年前、私たちは開発者を第一優先したパフォーマンス監視で大きな一歩を踏み出しました。 それ以来、数千ものソフトウェアチームが当社の最新APMソリューションを採用しています。 しかし、パフォーマンスについてチェックすべき項目が多くある一方で、開発チーム内で別々のツールで管理しているところもあり、監視が分断されてしまっているケースもあります。 エラーの根本原因や、パフォーマンスの問題を結びつけるのは、不必要に難しくさせます。SentryのMetricsは現在ベータ版で公開されています。 最初の立ち上げの週に予告したように、Metricsはまだ開発途中でした。 今回、ベータ版がリリースされ、無料で使用できるようになりました（ローンチウィークのアナウンスはこちら）。 これは単なるツールではなく、あなたにとって最も重要なデータポイントを長期にわたって追跡するための新しいパートナーとなるでしょう。 Metricsを使えば、製品・サービス・コードが常に意図したとおりに動作していることを確認しながら、相関するトレースで問題を特定し、解決することができます。 チームは、処理時間・チェックアウトのコンバージョン率・ユーザーのサインアップなどのカスタムメトリクスを監視して視覚化したり、トランザクションの継続時間などの既成のメトリクスを探索したりすることが可能になります。 また、問題を発見した場合、問題の原因を解決するために相関トレースを使用することができます（もちろん、このような機能はありません）。 メトリクスでクリティカルパスを監視 あなたがショッピングカートとチェックアウトの機能を持つ製品やサービスに取り組んでいるとします。 その処理フローは、あなたの会社の収益に直結しています。ですから、巨大なeコマースチェーンや、ユーザーがクレジットカード情報を入力しなければ続行できないSentry'sのようなSaaSビジネスを思い浮かべてください。 ユーザーがハッピーパスを通して成功できるようにすることは、貴社の成功にとって非常に重要です。このパスに遅延が生じると、収益が失われ、おそらく（間違いなく）多くの顧客が離脱することになります。 以下の例では、チェックアウトのレートを注視し、ユーザーがホームページから配送先住所の追加、チェックアウトへとスムーズに移動できるようにします。 仮想のチェックアウトフローのGIFをご覧いただくとわかるように、訪問者は3つのステップを完了する必要があります。 ホームページでスワッグをリクエストし、住所を入力し、注文を送信します。 Sentryの新しいメトリクスを使用すると、カスタムメトリクスを作成して、チェックアウトプロセスを完了したユーザー数をカウントし、視覚化することができます。 チェックアウトフローの3つのステップを追跡するためにカスタムメトリクスを作成し、何人のユーザーがホームページでスワッグをリクエストし、住所を入力、そして注文を送信したかどうかを可視化できるようになりました。 Metricsのおかげで、チェックアウトのコンバージョン率が安定していることが可視化することが出来るようになりました。 メトリクスが合わないとアラートを受け取る また、アラートを作成して、重大な変更があった場合にSlack、Discord、Teams、Emailで通知を受け取ることもできます。チェックアウトフローですべてがうまくいっていることを確認するために、チェックアウト率が20%下がったら発動する閾値アラートを設定しました。 アラートが表示される場合は、以下の画像のように表示されます。 コンバージョン率が下がったのでしょう。 結果をチェックすると、それを確認することができます。 訪問者が購入者に転換していないようです。 カスタムメトリクスによると、注文を正常に送信するユーザーが明らかに減少している。 一般的な製品の旅はここで終わりです。 しかし、Sentryの場合はまだ始まりに過ぎません。 【メトリクスとトレース】デバッグの強化 問題を特定できたので、当然の次のステップは解決策を見つけ出すことです。 問題がどこにあるのか直感的に分かるかもしれませんし、特定のAPIに問題があるかどうかを確認するために、レスポンスタイムのような他のメトリクスを引き出すかもしれません。 それで十分な場合もありますが、それ以上に厄介な場合もあります。 そんな時こそ、1つのツールでアプリケーションに関する様々な種類のデータにアクセスできるのが本当に便利です。 Metricsは、アプリケーションの幅広いデータを見るのに適しています。 一方、トレースは、フロントエンドからバックエンドまで、アプリケーションの深部を見るのに役立ち、根本原因を見つけるための豊富なトラブルシューティングデータを提供します。 あなたが注目しているメトリクスと相関のあるトレースイベントを表示することで、2つのシグナルを簡単に結びつけることができます。 イベント・サンプル・テーブルから、特定のトレース・ビューにドリルダウンすることができます。 ウォーターフォールを見ると、このトレースに非常に時間がかかっていることがわかります。サードパーティのフルフィルメントAPIが原因です。 これで、問題を解決し、ショップを復旧させるために何をすべきかがはっきりしました。 数えるだけじゃない『分布・ゲージ・セット』 上記の例では、カウント（"インクリメント "できるものをトラッキング）の例を示していますが、以下のようなさまざまなメトリックタイプを作成することができます。 分布： 最大値、最小値、平均値のように、時間にわたって集計できる値のリストを追跡します（たとえば、ページのロード時間）。プロセスの開始時間やキューの健全性やターンアラウンドタイムのように、アプリケーションの健全性を明らかにするようなことをレポートするために分布を使用することができます。 例えば、Sentryでは、イベントマネージャがイベントを保存するのにかかる時間の分布を測定するために、Dogfood Metricsを使用しています。そして、通常95パーセンタイルを監視し、イベント・インジェスト・パイプラインに影響を与える可能性のあるリグレッションをチェックします。 以下のように、青い点はこのメトリクスで収集されたサンプルです。 サンプルテーブルを使用して単一のサンプルを選択するか、直接ドットをクリックしてトレースの詳細を表示することができます。 ゲージ： 増減する値を追跡します（例えば、使用可能なディスク容量や使用メモリなど）。 セット： count_unique（ユニーク・ユーザー数など）のように、時間の経過とともに集計される値のセットを追跡します。 さあ、始めましょう！ Metricsを追加する以前の場合は、SentryのPerformance機能を使えば、すべての典型的なパフォーマンス・メトリクスを測定することは可能でした。
- [【Autofix】AIを使ってプログラムを簡単にデバッグ＆修正する方法](https://ichizoku.io/sentry/ai-powered-autofix-debugs-fixes-your-code-in-minutes/) - Sentryはアプリケーションのコードベースの内部構造について多くのことを知っています。 そこで私たちは、この豊富なデータセットを使って、デバッグをさらに高速化するにはどうすればいいかを考えました。 多くのジェネレーティブAI（GenAI）ツール（GitHub Copilotなど）は、開発環境における開発者の生産性を向上させますが、Sentryのような本番環境でのエラー修正を支援するコンテキストデータを持つものはほとんどありません。 私たちの新しい『AI対応Autofix機能』は、エラーが発生したときにユーザーが何をしているかを理解し、エラーを分析し、修正を生成し、さらにあなたのレビューのためにプルリクエストを開きます。 これは、オンデマンドで支援する準備ができているジュニア開発者を持つようなものです。 Autofixは本番環境でのエラーのデバッグを支援するためのものですが、もし開発中にそのような支援が必要だと感じたら、Codecovの新しいAIコードレビューをお試しください。 AIを搭載したAutofixの仕組み Autofixはエージェントベースのアーキテクチャを使用し、Sentryの問題を評価し修正するプロセスを管理可能な作業単位に分割します。 まず初めに、問題発見エージェントで、問題の予備評価を行い、コード変更で修正可能かどうかを判断します。 次に、プランニングエージェントが、エラーメッセージとお客様のコードベースから関連するコンテキスト情報を使用して、根本的な問題を解決するための実行プランを構築します。 このプランは、修正と付随する単体テストの生成を担当するAutofixの実行エージェントに渡されます。 最後に、PRを生成する前に、すべての変更を最終的にレビューします。 このプロセスは、反復的で透明性があるように設計されています。 システムは、積極的にコンテキストとフィードバックを求めながら進み、各ステップの結果は、開発者にとってなじみのあるCIライクなインターフェイスで表示されることも特徴的です。 IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。またご導入についての相談はこちらのフォームからお気軽にお問い合わせください。
- [INPとは何か？](https://ichizoku.io/sentry/what-is-inp-and-why-you-should-care/) - 2024年3月12日、Googleは新しいCore Web Vital指標である Interaction to Next Paint (INP) を開始することを発表しました。INPは、FID（First Input Delay）に代わるもので、Googleによるサイトのパフォーマンス評価の方法を変え、最終的に検索エンジンの検索結果に影響を与えます。 TL;DR：3月12日以降にあなたのサイトが悪影響を受けないよう、今日からINPに最適化する必要があります。 INPへ変更した経緯 FID（First Input Delay）は、Webページがユーザーの最初のアクションに対してどれだけ速く反応するかを測定するために設計されました。一般的に良いとされるFIDスコアは、100ms以下とされています。 しかしChromeの使用データによると「ユーザーのページ滞在時間の90%は読み込み後に費やされる」ため、FIDではユーザー体験のすべてを把握することはできません。 そこで INPは、最初のインタラクションだけでなくページ上のユーザージャーニー全体にわたってクリック、タップ、キーの押下を観察するように設計することで、ページの全体的な知覚応答性を測定することが可能になっています。 最終的なINPの値は、ユーザーがアクションを実行してから視覚的なフィードバックを受け取るまでに観測された最長時間として計算されます。 ユーザーインタラクションの例としては、製品をカートに追加するボタンのクリック、展開可能なアコーディオンのクリック、折りたたまれたナビゲーションメニューのタップ、入力フィールドへの入力などがあります。 INPは、特定のアクションが実行された後、視覚的フィードバックが表示されるまでの時間（つまり、次のペイント-ここでペイントとは、ブラウザがスクリーンにピクセルを追加するプロセスのことです）に焦点を当て、インタラクションの最終的な効果（ネットワークリクエストやUIの更新など）は除外します。 開発ツールにおけるINPの調査 Chrome、Brave、Edge、ArcなどのChromiumベースのブラウザを使用して、INP測定値に寄与するアクションとイベントを調査する方法を見てみましょう。 INPが計測する以下のユーザーインタラクションのいずれかを受け付けるウェブページを選択します（スクロールやポインタの移動などは計測されない） マウスでのクリック タッチスクリーンを使ってデバイスをタップする 物理キーボードまたはオンスクリーンキーボードのキーを押す 今回は、Sentry Docsのホームページで "web vitals "を検索したときに何が起こるかを調査することにしました。 開発ツールパネルを開き、「パフォーマンス」タブをクリックします。 Webサイトのターゲット層にもよりますが、古いマシンや低速のインターネット上でのユーザー体験を分析するために、CPUやネットワーク速度を調整することはしばしば有用です。 より遅いCPUやネットワークをシミュレートしたい場合は、それに応じてオプションを設定してください。 記録ボタンをクリックし、ページ上でいくつかのインタラクションを実行します。 録画を停止し、プロファイルがロードされるのを待ちます。 すると、色分けされたブロックとラベルの付いたレーンの形で、多くのデータが表示されます。 INPの要因を分析する際に最も重要なレーンは、"Interactions"(ページ上で実行されたユーザーインタラクション)と "Main"(ブラウザのメインスレッド)です。 文脈上、メインスレッドは "ブラウザがユーザーイベントとペイントを処理する場所 "です。デフォルトでは、ブラウザはメインスレッドを使用して、ページ上のすべてのJavaScriptの実行、ページのレイアウト、あらゆる変更の再計算、メモリの確保と解放（ガベージコレクション）を行います。 つまり、長時間実行されるJavaScript関数がメインスレッドをブロックする可能性があり、レスポンスの悪いページや悪いユーザーエクスペリエンスにつながります。GoogleはINPメトリックを導入することで、開発者にこれを解決するよう促しています。 記録されたパフォーマンスプロファイルを見ると、メインスレッドのブロックが赤くハイライトされていることがあります。タスクにカーソルを合わせると、実行にかかった時間が表示され、そのタスクブロックの下には、そのタスクを構成する個別のイベントや関数呼び出しがすべて表示されます。 マウスやトラックパッドでズームイン/ズームアウトしたり、ウィンドウの右側にあるスクロールバーを使ってスタックを上下にスクロールすることができます。 レーンの下にあるサマリー・タブは、各タスクでどれだけの時間が異なるプロセスに割り当てられたかを示しています。 これはタスクによって異なりますが、通常は「スクリプティング」（つまりJavaScriptの処理）と「ローディング」に最も長い時間がかかっていることが明確になります。 では、メインスレッドのアクティビティと、インタラクションレーンを確認してみましょう。 この例では、Sentry Docsホームページの検索入力に "web vitals "と入力した状態です。
- [【Sentry】モバイルアプリのパフォーマンス改善方法](https://ichizoku.io/sentry/improving-mobile-performance-from-slow-screens-to-app-start-time/) - 何千ものモバイル開発者チームと協力してきた経験に基づいて、Sentryではモバイルモニタリングの成熟曲線を開発しました。 私たちは、チームが安定性を達成し、クラッシュの消火と修正がなくなると、ワークフローの合理化にシフトし、最終的にはモバイルアプリのパフォーマンスの最適化に集中するようになるという仮説を立てました。 先日のワークショップで、私たちはモバイル開発者たちに、D彼らがカーブのどこに位置するかを尋ねました。 するとその結果は驚くべきものでした。 ほとんどの開発者（41％）は「安定性の確保」の段階にいました。 また、4分の1近く（24％）が現在パフォーマンスを最適化しています。 集中力とリソースは必要ですが、パフォーマンスの改善はモバイルアプリの成功に不可欠です。開発者が成熟度カーブを上れるよう、当社はモバイル・パフォーマンスの問題を検出して修正する方法を改善しています。これらの改善は、4つの重要な要素に分けることができます。 TTID / TTFDを使って遅い画面を最適化する アプリの起動が遅い根本原因を特定する アプリケーションの応答性を向上 モバイル・サービス・ビューで主要メトリクスを確認 TTID / TTFDを使って遅い画面を最適化する モバイル画面のロード時間、特にTTID（Time to Initial Display）とTTFD（Time to First Display）に焦点を当てたトラブルシューティングのワークフローを開発しました。 TTIDは、ユーザーにアプリがロード中であることを知らせる最初のフレームを表示するのにかかる時間です。 TTFDは意味のあるコンテンツが画面に表示され、アプリが完全にインタラクティブになるまでの時間です。ニュース記事をスクロールしたり、おしゃれな洋服を買ったりするのに、数秒待たされるのは誰だって嫌ですよね。 TTIDとTTFDのどちらかが遅いと、ユーザーはすぐに離脱してしまいます。 TTIDとTTFDは、プロダクションでの遅いメトリクスに寄与する作業を強調します。Sentry の Screen Loads を使用すると、トラフィックが最も多いユーザー画面を確認し、リリース間で TTID と TTFD を比較できます。 これにより、新しいリリースで導入された潜在的なパフォーマンスのボトルネックが強調されるため、速度低下の原因となっているコード変更、依存関係、または資産を調査することができます。以下のスクリーンショットのように表示されます。 また、単一画面の画面ロード・サマリー・メトリクスを見たり、モバイル・デバイス・クラスでフィルタリングして、リリース全体の平均TTID / TTFDを見ることもできます。 サマリー・グラフの下には、最も時間のかかるスパンが表示されます。これらについては、データのフィルタリングも可能です。 これにより、どの操作が TTID または TTFD の遅さの原因となっているかを知るために必要なコンテキストが得られます。以下のスクリーンショットをご覧ください。 Screen Loadsは現在、すべてのAndroidおよびiOSユーザーに提供されています。 アプリの起動が遅い根本原因を特定する 当社の新しいモバイルパフォーマンスアップデートは、アプリの起動が遅い根本原因の特定にも役立ちます。 モバイルアプリの起動シーケンスとは、アプリの起動からTTIDまでのステップを指します。迅速なアプリの起動は、ユーザーに好印象を与え、高い満足度、継続率、コンバージョン率を確保するために非常に重要です。 コールドスタート（アプリが初めて起動されるとき）であれ、ウォームスタート（アプリがバックグラウンドからフォアグラウンドに移動するとき）であれ、アプリの起動時間はAppleやGoogle Playストアでのアプリのランク付けや発見にも影響します。 Sentryでは、SentryのパフォーマンスナビゲーションバーでApp Startを使用して、最近リリースされたアプリバージョンのパフォーマンスを監視できるようになりました。 下の例のように、あるリリースと次のリリースのコールド（またはウォーム）スタート時間を比較し、両方のリリースのイベント
- [正しい指標を選ぶ： パーセンタイルと平均値のガイド](https://ichizoku.io/sentry/choosing-the-right-metric-a-guide-to-percentiles-and-averages/) - アプリのパフォーマンス監視で迷ったら必見。平均値とパーセンタイルの違いと使い分けを解説し、最適な指標選定をサポートします。
- [パフォーマンス監視機能によってアプリの安定性を向上させ、エンジニアの負担を軽減した理由](https://ichizoku.io/sentry/how-actionable-performance-insights-improved-developer-confidence-and-app-stability/) - オランダに本社を置くVisma社のYukiは、中小企業や会計事務所に使いやすい自動化された会計・税務サービスを提供しています。 顧客は財務書類をYukiに送り、Yukiのソフトウェアが自動的に書類を処理し、財務報告や税務申告を行うというものです。 多くの税務・会計ソフトウェアプラットフォームと同様に、Yukiは四半期ごとに約2週間の激務を経験します。 閑散期には機能が長期間使用されないため、バグやパフォーマンスの問題はエンジニアがその場でQAを行い、本番環境で監視していても、気づかれることはありませんでした。 スローダウンは使用量のピーク時にのみ現れ、ただでさえストレスの多い時期にユーザーのフラストレーションを引き起こし、開発者はすべての問題を優先度0（p0）として扱う必要がありました。 チームは迅速に問題を解決していましたが、会社の成長に伴い、自前のロギングおよびモニタリングツールだけでは対応できなくなりました。 エンジニアたちは、パフォーマンス課題を可視化できず、原因の特定が困難となり、反応も鈍かったのです。 影響を受けたユーザー数を確認できないため、最初に修正すべき優先順位を決める方法がありませんでした。 その代わり、エンジニアがコードを見て、それがどのくらいの影響を持つモジュールなのか推測し、問題がクリティカルかどうかを判断することに頼っていました。 「私たちのプラットフォームが成長するにつれ、速度低下に関する顧客からの苦情が増えました。しかし、これらの速度低下を解決するために、エンジニアはローカル環境で問題を再現することができないため、顧客チケットと電子メールの間を往復しなければならず、解決まで期日を要し、フラストレーションも蓄積していきました。」 チームは、顧客が書き込む前にエラーやパフォーマンスの問題を自動的に特定し、トリアージを支援し、解決するソリューションを探し始めました。 課題 エラーの影響に関するグループ化、アラート、メトリクスがない エンジニアにコンテキストがなく、トラブルシューティングが困難で時間がかかる パフォーマンスの問題は表示されるが、根本的な原因を特定するのは難しい ユーザーへの影響を可視化できない 従来のAPMベンダーよりもSentryが適していた Yukiは、いくつかの他のアプリケーションパフォーマンス監視（APM）ツールを比較検討しました。 しかし最終的にエラー追跡とパフォーマンス監視のためにSentryを選択しました。その決め手は、開発者エクスペリエンスの向上、SlackとAzure DevOpsとの連携、および.NETの強力なサポート体制です。 他のソリューションとは異なり、Sentryはカスタマイズをあまり必要としなかったため、エラーや速度低下、エンジニアが気にするメトリクスをすぐに監視することができました。 「私たちが評価した他のツールは圧倒的で、ハイレベルな指標しか示してくれませんでした。データだけで行動を起こすのは難しいのです。しかしSentryはセットアップが簡単なだけでなく、UXもわかりやすい。不必要な情報は適切にカットし、例外や遅いクエリなど、修正すべき点を正確に示してくれます。」 さらにYukiは、ユーザーへの影響やエラーの発生時期などのデータにアクセスすることで、重大性に基づいて問題に優先順位を付け、ログを探し回ったり、顧客と電子メールでやり取りしたりすることなく、それらの問題に対処することができるようになりました。 「問題が発生した場合、正確なバージョン、リリース、完全なURLがわかります。この情報を得ることで、開発者のエクスペリエンスは一変し、何が問題なのか、どこで問題が発生したのかを突き止めるのが非常に簡単になりました。」 すぐに使える.NET SDKサポート カスタムSlackアラート DBクエリと外部API統合のパフォーマンスを監視する機能 ダッシュボードとクエリの活用による迅速な改善 YukiはDB中心のアプリケーションで、より分散されたアーキテクチャに移行する計画があります。 これを念頭に、Yukiは分散サービス全体をトレースし、DBクエリと外部APIに関するパフォーマンス・インサイトを提供するソリューションを必要としていました。 「私たちは多くのサードパーティのAPIに依存し、複雑なクエリを書いています。1つのクエリが遅いと、アプリケーションのさまざまな領域に影響を及ぼす可能性があります」とJeroen氏は説明する。 パフォーマンス・クエリ・モジュールを使用することで、Yukiは、トップ・リグレッション・クエリと、それらがどのAPIエンドポイントから発生しているかを確認することができます。以前は、スローダウンが起きていることを特定するだけでなく、スローランニングしているクエリを見つけるためにエンドポイントごとに時間をかけて確認する必要がありました。 特に、クエリのロード時間が大幅に増加したクエリを検出したケースです。 Arjan氏は、パフォーマンス監視を使って、画像処理に関連する.NETライブラリ内で最近行われた変更までさかのぼりました。 リクエストの URL をすべて見ることができたため、問題を絞り込み、例外をスローする画像フォーマットを特定することができました。 「私たちは、特定の画像タイプのレンダリングに問題があることを知っていました。Sentryは、すべてのメタデータを含む完全なクエリー文字列を提供してくれたので、どの画像タイプが影響を受けているかを正確に突き止めることができました」とArjanは解説します。 以前であれば、問題のクエリは請求書のロードに使用されるコンポーネントを含む多くの異なるコンポーネントと相互作用していたため、Arjan氏のチームは修正パッチの適用を急いでいたことでしょう。しかし、Sentryでその影響を確認できたため、ホットフィックスをプッシュするためにすべてを停止する必要がない、孤立した問題であることがわかりました。 「2週間のリリースサイクルの間にパッチを当てる必要はありませんでした。Sentryのおかげで血圧が下がり、エンジニアが時間を集中させるべき優先順位を効果的に決めることができます。」 もう一つの例は、UIの新バージョンを作成しているときに、TPMメトリクスを使って多用されているエンドポイントを特定したときのことです。 調査の結果、そのエンドポイントは10秒ごとにタイマーを使ってデータベースからステータスをフェッチしていることがわかりました。 彼らはクエリを最適化して書き換え、ラウンドトリップを減らし、古いデータにはキャッシュを適用することができ、スピードが大幅に向上しました。 Slackでクリティカルな接続問題を検出する Yukiは会計を自動化しているため、成功の尺度の1つはアプリで費やされた時間です。このため、開発チームは、ユーザーに影響を与える問題をすべて取り除き、サイト・パフォーマンスを最適化することで、ユーザーが可能な限り速く出入りできるようにしています。 SQLサーバーのDB接続に失敗したことを知らせるアラートをSlackに設定しました。 以前は、Yukiはこのような問題について、サポートチームや顧客からの電話で聞くだけでした。パフォーマンスの問題があった場合、彼らの唯一の手段は、潜在的な問題がないかインフラを検査することだったのです。 「私たちのシステムは大きすぎて、どこが遅いのか、あるいはサーバーの接続数が多すぎて新しい接続を受け付けられないのかを知ることはできません。私たちのインフラ監視ツールはAPIエンドポイントを教えてくれますが、問題がどこにあるのかを突き止めるには十分ではありません。」 適切なロギングがなければ、システムの負荷や使用状況について把握することは困難です。Sentryをインストゥルメント化して以来、Yukiは顧客ベースの5%以上がアクセスできない2つのDB接続エラーを検出し、修正しました。 一旦警告が出されると、彼らはSentryで1分あたりのトランザクション（TPM）の指標を見ながら応答時間を追跡し、顧客が書き込みを始める前に問題を修正し、全員が請求書と税務情報にアクセスできるようにしました。 「私たちはサポートよりも早く、アラートとそれを解決するためのコンテキストを得たので、すぐにシステムをリブートしました。」 2日から2時間の短縮。コントロールの回復、問題の解決、不安の軽減 Sentryを導入して以来、Yukiのエンジニアリングチームは、より透明性の高いワークフローを実現し、開発者が自分のコードのパフォーマンスを管理できるようになりました。 「Sentryはリリースをプッシュするたびに不安を取り除いてくれます。以前はコントロールできませんでした。Sentryを使えば、問題を見つけるだけでなく、より深く掘り下げて解決するためのデータが得られるのです。」
- [Cron監視の拡張](https://ichizoku.io/sentry/scaling-cron-monitoring/) - この1年間、我々はCronを構築してきました。 小さなプロトタイプから始まったこの機能は、Sentryのエラー、パフォーマンス、信頼性モニタリングツールの本格的な機能へと生まれ変わりました。 この機能自体はまだベータ版ではありますが、すでに1日あたり700万以上のチェックインを受け付けています。 このような規模が大きくなった機能なので、信頼性を保証する方法について慎重な決断が必要でした。 早期実施 Sentryの新しいCron監視機能とは、スケジュールされたジョブ（例：古典的なcronjobs、celery beatタスク、Sidekiq、Laravel Scheduled Tasks、あるいはsystemdタイマー）が通常通り動作しているか、あるいは実行に失敗したシナリオを検証し、アラートを出す方法のことです。 これは、スケジュールされたタスクが "check-in "イベントを介して私たちに通知することで機能します。 Missed：予定時刻にチェックインしなかった場合、「チェックイン漏れ」となる Timed-Out：進行中のチェックインが完了しなかった場合、「タイムアウト」となる Error：status=errorのチェックインを送信すると、明示的にエラーとしてマークされる 最初のプロトタイプでは、チェックインの取り込みはDjangoアプリケーションに組み込まれたいくつかのAPIエンドポイントによって処理されていました。 物事をシンプルに保つために、チェックインは単に Postgres テーブルのエントリとして記録されます。 チェックイン漏れを検出するために、1分間に1回、celery beatタスクを実行して、予定時刻にチェックインがなかったモニターを探すだけです。タイムアウトの検出も同様です。 しかし、この最初のプロトタイプをアーリーアクセスユーザーに提供できるようにしたのは、今年に入ってからでした。 アルファ版の機能であっても、私たちはすぐに勢いを取り戻し、信頼性とスケーリングについて考える時が来たということです。 インジェスト・インフラストラクチャー 私たちが最初に解決しようとした問題は、チェックインの取り込みでした。 私たちのSDKが使用するAPIエンドポイントは、可用性が高く分散されています（私たちの分散取り込みインフラであるRelayを使用しています）。 しかし、私たちのフロントエンドを駆動し、プロトタイプのエンドポイントが実装されたSentry製品のAPIは、このような保証がありません。 Relayが可用性を向上させるだけでなく、Relay経由でチェックインを実装するもう一つの大きな利点は、私たちのSDK群全体でCronチェックインを作成するためのサポートを迅速に実装できることです。 これはRelayが統一された「エンベロープシリアライゼーションスキーマ」を使用しており、SDKが任意のイベント（もちろん最も一般的なのはエラーとトランザクションです）をRelayのポイント・オブ・プレゼンスに簡単に渡すことができるためです。 Cronのチェックイン・インジェストをRelayに移行するのは当然のことでしたが、プロトタイプのインフラを大きく変更する必要がありました。 この改良された世界では、Relay は SDK からのチェックインイベントを受け付けます。これは従来の curl スタイルでのチェックイン用の API エンドポイントも提供します。 これらのチェックインは検証され、正規化され、Kafkaトピックに入れられます。 これにより、処理できるチェックインの量をスケールアップするためのノブをすぐに回すことができます。以下のようなイメージです。 このアーキテクチャにより、ユーザーのチェックインを失うことなく、コンシューマーの問題を確実に回復することができます。Kafkaは問題のあるシナリオでもチェックインのバックログを維持することができ、負荷の要求に応じてコンシューマーの数を微調整することができます。 チェックイン漏れを確実に検知 Cronのインジェストインフラストラクチャの可用性が改善されたので、私たちはチェックイン漏れ検出の信頼性に注目しました。 Sentryは通常、プラットフォームに送られたデータを処理します。 未チェックインの検出は、我々のインフラにとって斬新な領域です。 1分間に1回のCelery beatタスクを使ってチェックインを検出するというプロトタイプのアプローチには、2つの大きな問題があることがすぐにわかりました。 Celery beatスケジューラのデプロイ中に、タスクがスキップされる短い期間があります。 これは、1分間に1回のチェックイン・プロデューサ・タスクが、特定の1分間実行されないことがあることを意味します。 このシナリオでは、すべてのユーザに自分のモニタのチェックインミスが通知されません。 Kafkaメッセージのバックログシナリオで、1分以上バックログしている場合、成功したチェックインが単にバックログにあるだけで、まだ処理されていないスケジュールされた時間のチェックインミスが発生する可能性があります。 これらはどちらも問題があるだけでなく、エンドユーザーを混乱させます。 私たちの目標は、モニターが停止したことを確実に伝えることなので、ミスしたチェックインを正しく検出することが重要です。 では、チェックイン漏れをチェックするタスクが、1）毎日毎時毎分、無期限に実行され、2）チェックインが壁掛け時計の時間より遅れても影響を受けないようにするにはどうすればいいのでしょうか？
- [Node.jsのLoaderパフォーマンスを向上させる](https://ichizoku.io/sentry/improving-node-js-loader-performance/) - Node.jsは2種類のモジュールをサポートしています。 EcmaScriptモジュールとCommonJSモジュールです。 ESモジュールはJavaScriptにおけるモジュールの公式な標準であり、すべてのモダンブラウザでサポートされています。 CommonJSモジュールは、Node.jsがデフォルトで使用するモジュールです。これらはブラウザによってサポートされておらず、公式の標準でもありません。しかし、現在でも広く使われています。 Node.jsはどのようにエントリーポイントをロードするのか？ どのローダーを使うかを区別するために、Node.jsはいくつかの要因に依存することを理解しておきましょう。 最も重要なのはファイルの拡張子です。 ファイル拡張子が .mjs の場合、Node.js は ES モジュールローダを使用します。 ファイル拡張子が.cjsの場合、Node.jsはCommonJSモジュール・ローダーを使用します。 ファイル拡張子が .js の場合、 package.json ファイルに "type": "commonjs" があれば（または単に "type "フィールドがない場合）、Node.js は CommonJS モジュールローダを使用します。 package.jsonファイルに "type": "module"があれば、Node.jsはESモジュールローダを使用します。 この決定はlib/internal/modules/run_main.jsファイルで行われます。 以下にコードの簡略版を記載します。 readPackageScope は、package.json ファイルを見つけるまで、ディレクトリツリーを上方向に走査します。 この投稿で最適化する前は、readPackageScopeはpackage.jsonファイルを見つけるまで内部バージョンのfs.readFileSyncを呼び出します。 この同期呼び出しはファイルシステム操作を行い、Node.js C++レイヤーと通信します。 この操作には、データのシリアライズ/デシリアライズのコストがかかるため、返す値/タイプによってパフォーマンスのボトルネックがあります。 そのため、readPackageScope内でreadPackage（別名fs.readFileSync）を呼び出すことはできるだけ避けたいです。 Node.jsはどのようにpackage.jsonを解析するの？ デフォルトでは、readPackageは内部バージョンfs.readFileSyncを呼び出してpackage.jsonファイルを読み込みます。 この同期呼び出しは、Node.js C++レイヤから文字列を返し、後でV8のJSON.parse()メソッドを使用して解析されます。 このJSONの妥当性に応じて、Node.jsは残りのローダーの実行に必要なオブジェクトをチェックした後作成します。 これらのフィールドは、pkg.name、pkg.main、pkg.exports、pkg.imports、pkg.typeです。JSONの構文に誤りがある場合、Node.jsはエラーを投げて処理を終了します。 この関数の出力は、同じパスに対して readPackageScope を再度呼び出さないように、後で内部 Map にキャッシュされます。このキャッシュは、プロセスの寿命が尽きるまで保存されます。 package.jsonフィールドとリーダーの使用法 最適化の前に、Node.jsがこれらのフィールドをどのように使用しているかを見てみましょう。 Node.jsコードベースでpackage.jsonフィールドをパースして再利用する一般的なユースケースは以下の通りです。 pkg.exportsとpkg.importsは、入力に応じて異なるモジュールを解決するために使われます
- [Reactにおけるメモ化の不具合を修正する](https://ichizoku.io/sentry/fixing-memoization-breaking-re-renders-in-react/) - Reactのメモ化を使用することで、ウェブアプリケーションを小さなコンポーネントに分割し、再利用しやすくすることができます。 コンポーネントの更新が必要な場合、Reactは再レンダリングを契機に、動的なデータやアニメーションなどを表示する方法です。 しかし、再レンダリングが必要ないコンポーネントを再レンダリングするとなると、アプリケーションのパフォーマンスに悪い影響を与えます。 以下の状況を想像してみてください。 親コンポーネントが、コールバック関数を子コンポーネントにpropsを通じて渡す場面です。 そして、子コンポーネントはメモ化されているにも関わらず、親コンポーネントが再レンダリングされるたびに子コンポーネントを再レンダリングしてしまう。 この問題を調査し、その修正方法を学んでいきましょう。 問題点 親コンポーネントは、コールバック関数を子コンポーネントにpropsを介して渡します。 子コンポーネントはメモ化されていますが、Reactは親コンポーネントが再レンダリングされるたびにそれを再レンダリングします。 何かが原因で、メモ化の特性を失わせています。 以下は親コンポーネントと子コンポーネントのコードスニペットです。 このコードを試したい場合は、こちらのCodeSandboxリンクをご覧ください。 _Numberコンポーネントには、再レンダリングごとに発生する重い操作が含まれています。 これが問題であることを特定するために、私たちはReact SDKに付属するSentryのwithProfilerメソッドを使用して、関心のあるすべてのコンポーネントをラップします。 これにより、その特定のコンポーネントのui.react.mountおよびui.react.updateイベントがキャプチャされます。アプリをリロードし、「増加」ボタンを数回クリックすると、Sentryパフォーマンスダッシュボードで以下のように表示されます。 トランザクションのうち50％がUI操作に費やされたことがわかります。 こちらについて詳細に調べる必要がありそうです。 しかし、なぜでしょうか？ 私たちは_NumberコンポーネントをReactのmemo()でラップしました。 なぜそれが再レンダリングされ続けるのでしょうか？ Reactと再レンダリングに関して知っていることを考えると、Reactはコンポーネントを再レンダリングするとき、それらの状態またはプロパティのいずれかが変更されたときです。 _Numberコンポーネントを見てみると、状態変数が定義されていないことがわかりますが、propsからsetMessageコールバックを受け入れています。 問題は「増加」ボタンをクリックしたときに発生します。 _Numberコンポーネントには全く関係ありませんが、それによりClosureRerenderコンポーネントが再レンダリングされ、それが_Numberコンポーネントに渡されるonClickメソッドを再作成します。 _Numberコンポーネントはメモ化されていますが、親が再レンダリングされるたびにsetMessageプロパティに異なる値を受け取り、これによりメモ化をバイパスし、再レンダリングします。 onClickメソッドは変更されないにもかかわらず、その参照が変わります。 自分で確認したい場合は、このページでコンソールを開いて、次のように一行ずつ入力してみてください。 最後のx===yコマンドはfalseを出力します。 それにもかかわらず、両方のオブジェクトは同じ値（'Lazar'）を持つ同じ名前のプロパティを持っています。 JavaScriptは、非プリミティブ型を扱う際に変数の値として参照を保持し、手動で両方のオブジェクトを作成したため、xとyは異なる参照を持ち、したがってx===yはfalseになります。 Reactでも同様です。ClosureRerenderが再レンダリングされるとき、onClickメソッドが再作成されるため、実質的に新しい参照が渡されます。 古いsetMessageプロパティは新しいものの値と一致しないため、Reactは_Numberコンポーネントを再レンダリングします。 では、これを修正するにはどうすればよいのでしょうか？ 解決策 解決策としては、`useCallback`フックを使用する必要があります。 `useCallback`フックは、コールバックに対する`useMemo`や`memo()`がコンポーネントに対するものであるようなものです。 依存関係の配列に変更がない限り、コールバックの再作成を防ぎます。 新しい`onClick`メソッドは次のように記述します。 このメソッドを`useCallback`フックでラップし、`props.setMessage`を依存関係の配列に配置します。 それが変更されない限り、再レンダリングの間に`onClick`は同じ参照値を保持し続けます。 もはや「増加」ボタンをクリックしても_Numberコンポーネントの再レンダリングがトリガーされません。そして、それをSentryで検証できます。 ずっと良くなりました。 不必要なui.react.updateイベントもなく、長時間実行されるUIブロッキングタスクもありません。 結論 `useMemo`フックや`memo()`メソッドは、常にコンポーネントが不必要に再レンダリングされるのを防ぎません。 今回の記事のようにメモ化を壊してしまう場面があり、それによってパフォーマンスが損なわれることがあります。 これは、`useCallback`フックを使用しないコールバックメソッドを渡す場合だけでなく、`setMessage={(number) => props.setMessage(number)}`のようにコールバックをインラインで定義する場合にも発生する可能性があります。 慣習的にコードを書いていると思うので「それが何を引き起こすか」にまでは、あまり注意を払っていないかもしれません。 今回のように、これらの状況をアプリ全体で修正したことを検証し、Reactアプリのパフォーマンスを監視し始めるために、アプリにSentryを導入してみてください。 開始は無料で、インストールも簡単です。 SentryがReactアプリに対して何ができるかをもっと詳しく知りたい場合は、Sentry
- [Reactの「フェッチウォーターフォール」について](https://ichizoku.io/sentry/fetch-waterfall-in-react/) - 早速ですが、以下のような問題に遭遇したことはありますか？ または、これはどうですか？ これはおそらく見たことがあるでしょう。 ちなみに、上記で挙げたものはすべて同じです。 1つ目の画像はSentryのイベント詳細ページ、2つ目はChromeのネットワークタブ、そして3つ目は、それを引き起こす原因となるコードスニペットです。 もし上の質問に「はい」と答えた方は、今回の記事が大いに役立つと思います。 そうでない場合でも、将来の自分のためにぜひ読んでみてください。 これは「フェッチウォーターフォール」と呼ばれ、Reactにおける一般的なデータフェッチ問題です。 これはデータをフェッチし、「ローディング」状態を表示してから子コンポーネントをレンダリングする（そして同様のことをするなど）コンポーネントの階層を作成するときに発生します。 ざっくりいうと、Webページを表示するために必要なデータをサーバから取得する際に起こる問題であるということです。 各コンポーネントのデータが親のものに依存する場合には問題ありませんが、常にそうとは限りません。 各フェッチが少なくとも1秒かかる場合、ページのロードに3秒以上かかることになります。現代のデジタルネイティブにとって、3秒のロード時間はとても長く感じますよね。 しかし、並行してフェッチすれば1秒で得られるデータを、3秒以上も待たせる理由は一体何なのでしょうか？ この問題のCodeSandboxがこちらですので、ご自身の目でご確認ください。 良いパフォーマンスを維持するため、3つの方法をご紹介します。 そして、各ソリューションを使用したい場面を探っていきましょう。 対処法① Suspenseを使用する Suspenseは、フェッチウォーターフォールを避けるための有効な手段の1つです。これは、コンポーネントツリー全体のフェッチを並行してトリガーするため、データがずっと速くフェッチされます。しかしこの方法は本番環境に適していません。 Reactのドキュメントでは、Suspense対応データソースのみがSuspenseコンポーネントを起動し、それらはRelayやNext.jsといったフレームワーク、またはlazyでの遅延ロードコンポーネント、あるいはuseでの約束値の読み取りであると説明しています。 遅延ロードとuseフックも必ずしも良い対応策だとはいえません。 遅延ロードコンポーネントは、フェッチウォーターフォールを確実に排除することはありません。それは同じように振る舞い、Suspenseからの「ローディング」フォールバックが唯一の利点です。 useフックはReactのcanaryバージョンでのみ利用可能なため、まだ安定版としてリリースされていません。 ですので、Next.jsやRelayを使用していない限り、Suspenseを対処法として使うことはお勧めしません。 しかし、本当に使いたい場合は、このCodeSandboxの例を確認してください。本番環境に適したものが出れば、良いパフォーマンスを維持し、フェッチウォーターフォールを避ける素晴らしい方法になり得ます。 対処法② サーバー上でデータをフェッチする Next.jsを使用する場合は、サーバーコンポーネントを使用します。 そうすれば、クライアントはデータとともにHTMLを受信し、データ要求をする必要がなくなります。 リクエストがない……つまりフェッチウォーターフォールがない！ということになります。 では、このようにサーバーサイドでデータをフェッチするのでしょうか？ サーバーは、クライアントに処理結果を返す前に、一連のデータをすべてフェッチするのを待つことになります。 これは並列実行の問題であって、レンダリングの問題ではありません。 サーバーでデータをフェッチするだけでは解決することができません。 上の画像を見ると、確かに滝のように見えますね。 古典的なSSR（または "loading "コンポーネントのないServer Components）では、TTFBはデータをフェッチする時間よりも遅くなっています。 そして、TTFBの値が大きくなったので、他のすべてのウェブバイタルも大きくなっています。 Next.jsでもローディングコンポーネントを提供することでTTFBを修正できますが、それでもウォーターフォールは落ち続けます。 もうひとつ考慮すべきことは、SSR/Server Componentsを使用する場合でも、ブラウザ上でレンダリングするということです。 クライアントは、サーバーから受け取ったDOMを表示し、ユーザーのインタラクションに反応できるようにしなければなりません。 つまり、サーバーで生成した静的なWebページに、クライアント側のスクリプトが操作可能にする必要があります。 2台のコンピュータ（ブラウザとサーバー）がレンダリングタスクを実行します。 サーバーは各リクエストに対してより多くのタスクを実行します。 ブラウザは（SSRのとき）ユーザーにはまだ空白のページを表示しており、レスポンスが返ってきたときにもまだレンダリングを行っています。 サーバーでのフェッチは悪いアイデアではありません。 しかしその方法を使う場合は「トレードオフ」であることを踏まえて検討する必要があります。もし問題がないのであれば、このように並列にデータをフェッチするようにしてください。 3つのfetchメソッドは、他のAPIリクエストやデータベース呼び出しなど、どんなものでも構いませんが、Promiseを返さなければなりません。Promise.allはすべての入力プロミスを並行して起動し、入力プロミスの最後が解決されたときに解決される新しいプロミスを返します。 フェッチ・ウォーターフォールを避けるためにデータ・フェッチを持ち上げる フェッチ・ウォーターフォールの問題を解決するもう1つの方法は、データ・フェッチをコンポーネント階層の上位レベルに引き上げることです。 コンポーネント・レベルでデータをフェッチする代わりに、コンポーネント・ツリーの最上位レベル（データをフェッチし始める最初のコンポーネント）でデータをフェッチし、それをコンポーネント・ツリーに渡すことができます。 この場合でも、並行してデータをフェッチすることは重要なので、必ずそのようにしてください。
- [Flutter開発で知っておくべきヒントとツールについて](https://ichizoku.io/sentry/flutter-debugging-top-tips-and-tools-you-need-to-know/) - 現代のアプリケーションは、複雑なサービスの集合体です。 故障する可能性や、期待どおりに動作しない可能性を持つサービスが、相互に連携し合って構成されています。 Flutterとその開発言語であるDartは、イベント駆動型、並行処理、そしてパフォーマンスの高いアプリケーション開発のために設計されています。 それらを使用する開発者にとって、適切なデバッグツールを使いことなすことは必要不可欠です。 デフォルトのFlutterツールには、他言語よりも優れたデバッグとプロファイリングのツールスイートが含まれており、多くの開発者をサポートしています。この堅牢な基盤によって、人気のあるIDE向けのプラグインや外部モニタリングプロバイダが、Flutterアプリケーションに対する深い洞察を得ることができます。 この記事では、いくつかのオプションを紹介し、それらがFlutterのデバッグとプロファイリングにどのように役立つかを説明します。 Flutterデバッグの例 Flutterデバッグに必要なトップツールとヒントを網羅するために、例を交えながらお伝えしていきます。 この情報収集の目的は、複数のタスク、課題、およびToDoのソースを統合し、それらをソートおよびフィルタリング可能なリストで一緒に表示するアプリケーションを作成することです。 では、TrelloとGitHubの課題からアイテムを取得し、リストで表示するアプリケーションを例として挙げて進めていきます。 このアプリケーションは2つのAPIからデータを取得し、JSONレスポンスを解析し、データ構造を統合し、それらをスクロール可能なリストで表示する必要があります。 このアプリケーションの進捗状況はGitHubで確認できます。 ログ記録のオプション 一般的な開発者であれば「console.log()」といったログを出力するコードを書く所から解析を始めるでしょう。 これが最適な方法ではないことはわかっていますが、簡易なデバッグであればこれで充分です。 FlutterとDartには、これを行うための3つの方法があります。 print()、stdoutそしてstderrを使用してメッセージをコンソールに記録できます。 詳細な情報を受け取るためにdart:developerのlog()関数を使用できます。 log()関数を使用すると、タイムスタンプ、エラーレベル、スタックトレースなどの複数のオプションパラメータが追加された状態で出力されます。 Flutterでフラグをデバッグする方法は FlutterはUIに焦点を当てたアプローチを取り、アプリケーションインターフェースはしばしば数十のカスケードウィジェットから構成されるため、アプリケーションのUIに対する視覚的なフィードバックはとても重要です。 Flutterにはクラスに追加できるいくつかのデバッグフラグがあります。ただし、FlutterのDevToolsにはこれらのフラグを複製（および改善）する機能があるため、それらを使用する目的がない限り、出来るだけ使用しない方が良いでしょう。 Flutterのドキュメントには、これらのフラグの概要が記載されており、レンダリングパッケージのプロパティリストには完全なリファレンスがあります。 DevToolsパッケージ Flutterの最も強力な機能の1つは、DevToolsパッケージです。これはデバッグやパフォーマンス分析機能を提供するツール集です。Android Studio、IntelliJ、またはVS Codeのプラグインと組み合わせて使用するのが最適ですが、ブラウザ内またはコマンドラインからも使用できます。 組み込みツールとして、多彩な機能を提供しており、以下が含まれます。 UIのレイアウトと状態を検査 UIパフォーマンスの問題を診断 CPUプロファイリング（プロファイルモードのみ） ネットワークプロファイリング（プロファイルモードのみ） ソースレベルのデバッグ トレースをサポートするタイムラインビュー メモリの問題をデバッグ 実行中のアプリに関する一般的なログと診断情報を表示 コードとアプリのサイズを分析 アプリケーションをデバッグモードまたはプロファイルモードで実行すると、DevToolsは自動的に開始し、エディター内で表示されるか、コマンドラインから実行した場合はブラウザで表示されます。DevToolsはデフォルトで多くの情報を表示しますが、エディタープラグインを使用してブレークポイントを設定することで、その機能を最大限に活用することができます。 DevToolsを使用して、ブラウザからUSBケーブルで接続した物理デバイスまで、どこからでも実行中のFlutterアプリケーションをデバッグすることができます。 Flutterアプリケーションをデバッグするためのエディタープラグインには Android Studio、IntelliJ、およびVS Codeのプラグインは、DevToolsをIDEにバンドルしており、アプリケーションが実行中でも上記でリストに挙げた機能をリアルタイムで活用できます。 ブレークポイントを設定すると、DevToolsはアプリケーションをブレークポイントで一時停止し、アプリケーションが宣言する変数を含む現在のアプリケーションの状態を表示します。その後、DevToolsのUIを使用してアプリケーションの状態を検査し、実行を続行できます。 Sentry Flutterプラグイン Flutterはアプリケーションを構築する際に包括的なデバッグツールを提供しています。 本番環境でのエラー追跡とモニタリングが重要であり、Sentryはそのサポートを提供しています。 これには手動で追加された例外のキャッチングや、本番環境のパフォーマンス監視が含まれ、Sentryはこれらに加え、メタデータやスクリーンショットなどの情報を提供します。 実際の問題をデバッグする これらの様々なツールは、アプリケーションのデバッグをどのようにサポートするのでしょうか？ 以下は、私が遭遇したエラーの具体例と、それらを解決するのに役立ったツールの一部をご紹介します。 もちろん、他にも多くのエラーに悩まされましたがそれらのほとんどは人為的なものでした 😅 開発にはVisual
- [2024年、AIエンジニアになるために知っておくべきこと、できること。](https://ichizoku.io/sentry/how-to-transition-to-an-ai-engineer-in-2024/) - 2024年、AIエンジニアになるために知っておくべきこと、できること。 AI開発の分野は、音声認識、画像認識、ビジネスプロセス管理、医療診断などAIの能力によって、タスクに革命をもたらし急成長しています。高度なコード生成ツールを導入することで、ソフトウェア開発に変革をもたらしています。この業界全体の変化は、日本のみならず世界中のソフトウェアエンジニアにとって重要な岐路となります。ソフトウェアエンジニアは今、厳しい現実に直面しています。恐らく今後、あなたが現在報酬を得ているスキルの一部は、AIによって100％自動化されるでしょう。そんなAIに劣らない技術を維持するためには、エンジニアはAI技術と多くのアプリケーションを受け入れられるようにスキルセットを変えなければなりません。しかし、重要なのはこの転換を「どのように行うか」ということです。何を理解しなければならないのか？AIを使った開発を熟達するためにエンジニアはどのようなステップを踏むべきなのか？多くのエンジニアは、業界と必要なスキルを理解する時間を取ろうとしません。この記事では、必要なスキル、求人の種類、AIエンジニアとして成功するための重要なステップについて解説していきます。 AIエンジニアは実際に何をするのか？ AIエンジニアへの転職を成功させるためには、エンジニアはまずAIエンジニアが実際に何をするのかを深く理解する必要があります。AIエンジニアは、機械学習やディープラーニングのニューラルネットワークを用いたAIモデルの開発を担当しています。ニューラルネットワークがどのようなものなのかについては割愛します。 AIエンジニアの責務AIエンジニアは、AIをより広範な組織の枠組みに統合する上で極めて重要な役割を果たします。その責務は以下の通りです。 機械学習モデルをAPI（Application Programming Interface）に変換し、様々なアプリケーションへの統合と活用を可能にする。 AIモデルを一から構築し、プロダクトマネージャーや利害関係者を含むさまざまな組織部門にその利点を説明する。 データの取り込みと変換のためのインフラを構築し、効率的なデータの取り扱いと処理を保証する。 データサイエンスチームが使用するインフラを自動化し、効率性と生産性を高める。 統計分析を実施し、組織の意思決定のために結果を洗練させる。 AI開発と製品展開のインフラを確立し、維持する。 AI統合を成功させるためには、様々な組織チームとの連携が不可欠であるため、チームワークに優れていること。 AIエンジニアになるために必要なスキルAIエンジニアを目指すプロフェッショナルたちは、この分野で求められるスキルについて知っておく必要があります。その中には以下のようなものがあります。 テクニカルスキル プログラミング・スキル AIエンジニアになるために必要なスキルの第一はプログラミングです。 AIに精通するためには、Python、R、Java、C++などのプログラミング言語を習得し、モデルを構築・実装することが極めて重要です。 線形代数、確率、統計 隠れマルコフモデル、ナイーブ・ベイズ、ガウス混合モデル、線形判別分析など、さまざまなAIモデルを理解し実装するには、線形代数、確率、統計の詳細な知識が必要となります。 Sparkとビッグデータ技術 AIエンジニアは、テラバイトやペタバイト単位のストリーミングや、リアルタイムの本番レベルの大量データを扱うことが多いです。このようなデータを扱う場合、エンジニアはSparkやその他のビッグデータ技術について知っておく必要がある。Apache Sparkの他にも、Hadoop、Cassandra、MongoDBなどのビッグデータ技術を使用することが求められます。 アルゴリズムとフレームワーク 線形回帰、KNN、Naive Bayes、Support Vector Machineなどの機械学習アルゴリズムの仕組みを理解すれば、機械学習モデルを簡単に実装できます。 さらに、非構造化データでAIモデルを構築するには、深層学習アルゴリズム（畳み込みニューラルネットワーク、リカレント・ニューラル・ネットワーク、生成敵対ネットワークなど）を理解し、フレームワークを使って実装する必要があります。 人工知能で使われるフレームワークには、PyTorch、Theano、TensorFlow、Caffeなどがあります。 人間力 成功するエンジニアと苦戦するエンジニアの違いは、ソフトスキルに根ざしていることが多いです。 AIエンジニアは主に技術的な仕事ですが、他者と効果的にコミュニケーションをとり、問題に対処し、時間を効果的に整理し、他者と協力して仕事をする能力は、プロジェクトが問題なく完了し、納品されるかどうかを決定する重要な要素でもあります。 AIを効果的に導入するには、社内の複数の部門が効果的に協力する必要があります。MLパイプラインやAIを活用したアプリケーションを効果的に構築、デプロイ、維持するためには、データエンジニア、データサイエンティスト、ドメインエキスパート、ソフトウェアエンジニアなどが協力し合う必要があります。 異なるチーム間で効果的な協力者となるためには、以下のようなスキルを身につけることが重要です。 コミュニケーション・スキル 人工知能エンジニアが話をしなければならない相手は、幅広い能力レベルの異なるメンバーたちです。 例えば、あなたの会社のなかで新しい人工知能モデルを作成し、社内の各部門に提供するよう依頼されたとしましょう。 複雑な考えやコンセプトを多くの人に伝えたいのであれば、文章や会話のコミュニケーション能力を磨いた方がよいでしょう。 問題解決能力 データサイエンティストやソフトウェアエンジニアとして成功するには、創造的な思考力と問題解決能力が求められます。人工知能はリアルタイムで発生する問題に対処しようとするため、クリティカルかつクリエイティブな問題解決スキルを身につける必要があります。 ドメインの専門知識 機械学習分野のエンジニアは、企業の要求とこれらのソリューションがエンドユーザーのために解決しようとしているビジネス上・技術上の問題の両方を認識しなければなりません。 その分野の専門知識がなければ、プログラムの作成やAIソリューションの最適化は困難になります。関連分野の専門知識の欠如は、不正確な提案、不完全な作業、評価の難しいモデルにつながる可能性が出てきます。AIの知識だけでなくその専門領域の知識も必要となります。 時間管理 人工知能分野のエンジニアは、複数の利害関係者のニーズと、調査、プロジェクトの編成と計画、ソフトウェアの作成、徹底的なテストの必要性とのバランスを取らなければなりません。チームの生産的なメンバーになるためには、時間を効果的に管理する能力が不可欠です。 チームワーク AIやITコミュニティのメンバーは、互いに協力し合うことが多くあります。 チームの中でうまく生産的に活動する能力は、持っておくべき貴重なスキルです。 少人数でも多人数でも、複雑な目標を達成するために協力することが求められます。 他の人の意見を考慮し、明確で簡潔なコミュニケーションを通じて自分の意見を述べることは、チームの一員として成功するのに役立ちます。 ビジネスインテリジェンス ビジネス・インテリジェンス（BI）は、AIイニシアチブを導入し、その効果を評価する上で強力なツールであり、持っておくべきスキルです。
- [すべての開発者のためのパフォーマンス監視 ウェブ・バイタルと機能回帰の問題](https://ichizoku.io/sentry/performance-monitoring-for-every-developer-web-vitals-function-regression-issues/) - パフォーマンス・モニタリング・ツールから適切な洞察結果を出すのは、フラストレーションが溜まるものです。一般的なモニタリングツールを使用すると、必要以上のデータが返されてしまい、そのデータを実際のソースコードで確認するまでに大変な手間がかかります。 Sentryが提供するパフォーマンス・モニタリングは、集中すべき課題をピンポイントで検出することで不要なデータを除外し、原因のコード行番号を的確かつ素早く表示します。その結果、より少ないノイズ、より実用的な結果として得ることができます。 本日、Web/モバイル/バックエンドの開発者がアプリのパフォーマンス問題を発見し、解決するための2つの新機能「Web Vitals」と「機能回帰問題」を発表します。 Web Vitals は、パフォーマンススコアから遅いコードまで確認可能 Web Vitalsは、ページの品質を測定するために、読み込み速度、インタラクティブ性、視覚的安定性のような指標として有効なもののみに統一しています。これらの指標を使用して、Web Vitalsメトリクスの加重平均を使用して計算された100点満点の正規化スコアであるSentry Performance Scoreを開発しました。 Sentryのパフォーマンス・スコアは、Google の Lighthouse のパフォーマンス・スコアと似ていますが、1つだけ重要な違いがあります。 それは、Lighthouseは管理されたラボ環境からデータを収集するのに対し、Sentryは実際のユーザー体験からデータを収集します。 私たちは、ラボ環境でしか関連性のないコンポーネントを除外しながら、Lighthouseにできるだけ近いスコアになるようにモデルを作成しました。 Web Vitals が最大の改善機会を特定する 全体的なパフォーマンス・スコアを向上させるには、パフォーマンスの改善が必要な個々の主要ページを特定することから始める必要があります。 これを簡素化し、すぐに本題に入るために、1つのページが全体のパフォーマンス・スコアに与える影響を示す「機会（Opportunity）」ごとにページをランク付けします。 それでは実際にSentry独自の課題の詳細ページをお見せします。この例では、Webアプリで最もアクセス機会の多いページを表示しています。これは当社の製品で最もよくアクセスされるページであるため、このページのパフォーマンスを向上させることは、Sentryの使用体験全体を大幅に改善することになります。 問題のあるページを特定したら、ユーザー体験が悪かったイベントを探します。 以下に、実際のユーザーが問題の詳細ページを読み込んでいることを示すイベントを表示します。 上のスクリーンショットでは、パフォーマンス・スコアが100点満点中9点（悪い）となったユーザーが表示されていますが、これは主に10秒以上のLargest Contentful Paint（LCP）が原因です。 このような最悪のケースは、ローカル開発中や理想的な条件下（ユーザーが高速ネットワーク接続やハイスペックなデバイスを使用している場合など）では明らかにならないパフォーマンスの問題を浮き彫りにしています。 これらのイベントの中には、『▶️（リプレイ）』ボタンがあることにお気づきでしょう。利用可能な場合は、そのページでのユーザーの実際の体験をビデオのように再現して見ることができます。アプリのパフォーマンスを最適化する場合、これらのリプレイは、ユーザーが劣悪な体験をしている場所を解析するのに役立ちます。 スパンウォーターフォールは、最も価値のあるオペレーションを強調します。 LCPが遅くなった原因を調べるには、イベントの「トランザクション」ボタンをクリックすると、ページ・ロード中に発生した操作の詳細な内訳が表示されます。これらの操作を「スパン」と呼びます。 最も関連性の高いスパンは、赤いLCPマーカーの前に発生するスパンで、これらのスパンはLCPブロックの可能性があるためです。LCPマーカーの後に発生するスパンは、ページ全体のパフォーマンスには影響を与えますが、最初のページロードには影響を与えません。 明らかにパフォーマンスのボトルネックになっているように見える最初のスパンは、app.page.bundle-loadスパンで、JavaScriptバンドルのロードにかかる時間を測定します。この場合、バンドルのロードだけでほぼ6秒、つまりLCPの総所要時間の約60％を要しています。 JavaScriptバンドルのロード時間は、主にそのサイズに依存します。バンドルのサイズを小さくすれば、ページ読み込み時間は大幅に改善されます。 しかし、バンドルの読み込み時間を50%短縮しても、LCPは12秒から7秒にしか短縮されません。 次の明確な改善箇所は、このui.long-task.app-initスパンに1秒近くかかっていることです。長いタスクのスパンは、ブラウザがJavaScriptコードを実行し、UIスレッドをブロックしている50ミリ秒以上の操作を表します。 これは純粋なJavaScriptの操作なので、さらに深く掘り下げて何が起こっているのか調べてみましょう。 ブラウザのプロファイリングは、ソースコードの原因となっている行を表示 従来までは、処理が長いタスクの原因となっているコードを特定することは困難でした。その理由は、プロファイラにアクセスできる開発環境で問題を再現する必要があったためです。 Sentryでは、これを解決するために本番環境（Chromiumベースのブラウザ）でブラウザJavaScriptプロファイルを収集するための新しいサポートを開始しました。これにより、実際のユーザーの問題をデバッグし、ユーザーベース全体で幅広いサンプルプロファイルを収集することができます。 以下の例では、ページ読み込みイベントに関連するプロファイルを開き、1秒ほどのタスクスパンの間に実行されたコードを見ることができます。 EChartsReactCore.prototype.componentDidMount関数の実行時間は558ミリ秒であり、これは長いタスクスパンの半分以上です。この関数は、オープンソースのEChartsビジュアライゼーション・ライブラリが提供するチャートをレンダリングするReactコンポーネントにリンクされています。これはまさに、Issues Detailsのページロード時間を短縮したい場合に注目すべき箇所のようです。 ここまでの流れを要約していきます。 まずパフォーマンス・スコアが低いページを特定します。 次に JavaScript バンドル・サイズを縮小して、特定の React コンポーネントを最適化することで、問題の詳細ページのパフォーマンスを大幅に改善できると判断しました。機会（Opportunity）スコアが高いページを見つけ、ページ読み込みイベントを分解し、プロファイルを使用して JavaScript パフォーマンスを深く掘り下げることで、製品の全体的なユーザー体験を向上させることができます。 Web
- [ソースマップのアップロードエラーを修正する方法](https://ichizoku.io/sentry/how-to-fix-source-map-upload-errors/) - すべての変数と関数名を含むソースコードが含まれていないスタック・トレースは、開発者が問題の根本原因を分析することを困難にさせます。 Sentry には、根本原因分析において開発者を支援する重要な機能があります。 Sentry では、ソースマップをアップロードすることができます。 これにより、元のソースコードにマップバックすることができ、コード内の問題の原因をより簡単に理解することができます。しかし、Sentyにソースマップをアップロードすることは困難です。 このガイドでは、ソースマップのアップロードを試みたもののエラーが表示されてしまう場合の対処方法をご説明します。 最も一般的なアップロードの問題を解決するために、再確認すべき事項やベストプラクティスについて詳しくご紹介します。 まだソースマップをアップロードしていない場合は、以下の1行のコードからプロセスを開始しましょう。 npx @sentry/wizard@latest -i sourcemaps Sentryのソースマップの使い方 スタックトレースにオリジナルのソースコードを表示するには、Sentry はイベントペイロード内のスタックトレースを、そのリリースまたはビルド用にアップロードされたソースマップと照合する必要があります。 そのために、Sentry は「Debug IDs」と「release + abs_path」に基づく2つの照合方法を提供します。上記のコマンドでウィザードを実行すると、どの方法があなたのアプリに有効かを判断するのに役立ちます。 ウィザードを実行してアップロードした後、どの方法を使用しているかを確認することができます。 設定 > プロジェクト > [プロジェクト名] > ソースマップページから、アップロードしたファイルにアクセスすることで確認できます。バンドルを開き、ファイル名の下に Debug ID があるか確認します。 デバッグIDが表示されていれば、現在デバッグIDが設定されているということになります。 デバッグIDが表示されない場合は、リリース+abs_pathマッチングに設定されているということになります。 Sentryでは、より簡単にセットアップするために、Debug IDの使用を推奨しています。 release + abs_pathマッチングを使用している場合でも心配ありません。このアップロードプロセスのデバッグ方法についてもご説明します。 デバッグIDアップロードエラーの修正 デバッグIDは、ソースマップをアップロードするための推奨される方法です。これは release + abs_path アプローチの欠点を無くしたものです。Debug IDのサポートを追加することで、リリースを作成する必要がなくなります。Sentry はパス（信頼性に欠ける可能性がある）に依存するのではなく、Debug ID で圧縮されたソースとソースマップのペアを一意に識別しバインドします。これにより、Sentry はパスを確認することなく、最小化されたソースと対応するソース マップを識別することができます。 以下は、デバッグIDを使用したソースマップ・アップロード・エラーをデバッグするためのトラブルシューティング・チェックリストです。 1. SDKバージョンをアップグレードする： SDKがデバッグIDを使用できることを確認してください。issueの詳細ページの下部に、イベントが送信されたSDKが表示されます。
- [Sentry パフォーマンス - 関数回帰の問題：  Pythonのプロファイリングの例](https://ichizoku.io/sentry/sentry-performance-function-regression-issues-profiling-for-python-example/) - 先日、アプリケーション全体で最も遅く、リグレッション（リリース後、パフォーマンスが低下）している関数を表示する機能を開始しました。 今回、新しいタイプのパフォーマンス・イシューで、関数レベルのリグレッションをデバッグできるようになりました。関数のリグレッション問題は、アプリケーションの関数がリグレッションしたときに通知されますが、単にリグレッションを検出するだけではありません。 関数リグレッションの問題は、Sentry Profilingをサポートしているプラットフォームであれば検出することができます。以下では、Pythonプロジェクトのバックエンドを例に説明していきます。 上のスクリーンショットは、Sentryのライブランニングサーバーコードのスローダウンを特定した、実際のFunction Regression Issueです。Redisに保存された顧客のレート制限をチェックする関数の持続時間が50%近くも後退したために発生しました。 上のグラフは関数の持続時間の経時変化を示し、下のグラフは呼び出し回数（スループット）を示しています。スループットもスローダウン期間中に増加していることがわかります。これは、負荷の増加がこの回帰の原因の1つである可能性を示唆しています。 上のスクリーンショットでは、同じ問題によって、どのAPIエンドポイントがリグレッションの影響を受け、どれだけパフォーマンスが後退したかといった他の重要な情報を見ることができます。このデータから、レート制限関数が多くのエンドポイントで広く使用され、呼び出された結果、バックエンド全体のパフォーマンスが大幅に低下したことがわかります。 回帰問題からプロファイルを確認して根本原因を見つける リグレッションした関数の問題では、リグレッションの前後にキャプチャされたプロファイルを簡単に確認できます。これらのプロファイルを比較することで、リグレッションの原因となった実行時の動作の変化を（コードレベルで）明らかにし、最も重要なコンテキストを提供します。 ここで実際に、リグレッションが発生する前にキャプチャされたプロファイル・イベントの例を見てみましょう。リグレッションが発生した関数は、サードパーティのredisモジュール内の2つの関数を呼び出していることに気づきました。 ConnectionPool.get_connectionとConnectionPool.releaseです。 これをリグレッション後に収集したプロファイルと比較したところ、これら2つの関数のうちの1つであるConnectionPool.get_connectionに以前よりも大幅に時間がかかっていることがわかります。 プロファイルの各関数フレームは、関数が定義された場所と実行された行番号のソース・コンテキストを提供します。この場合、redisモジュールでこのソースの場所を開くと、次の行（以下の画像参照）であることがわかりました。 この行はロックの取得を試みており、この行を実行したときの壁時間の大幅な増加は、複数のプロセスまたはスレッドが同時にロックを取得しようとしていることを示唆しています。このロックの競合がコード・レベルでのリグレッションの原因であることがわかります。 このロック競合の問題は、先にスループット・グラフで見たこと、つまりスループットが増加すると競合が起こりやすくなることとも一致しています。追加の調査を通じて、この関数のスループットの増加は、リグレッションの頃に始まったRedis接続数の増加に対応していることがわかりました。 今回の例を通じて、リグレッションした関数の問題が、プロファイリングデータを使ってリグレッションを引き起こしているコードに直接リンクするのに役立つことを説明しました。 今回の例はバックエンドのユースケースに焦点を当てていますが、この機能はSentry Profilingをサポートするどのプラットフォームでも機能します。 ファンクション・リグレッションの問題は、アーリー・アダプターの皆様には本日よりご利用いただけます。 結論 人々が使いたいと思うような差別化された製品を構築するためには、高性能なバーが不可欠です。ウェブ・バイタルとファンクション・レグレッション・イシューにより、すべての開発者がコードに接続することでパフォーマンスの問題を解決できる方法を提供していきます。 IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。またご導入についての相談はこちらのフォームからお気軽にお問い合わせください。
- [JavaScriptプロジェクトのノイズを減らす](https://ichizoku.io/sentry/making-your-javascript-projects-less-noisy/) - あなたがJavaScriptのエラー監視にSentryを使用している場合、よくある課題にお気づきかもしれません。それはSentryが挙げるすべての問題に目を通し、無視してもよい帝優先度のエラーと、修正が必要な高優先度のエラーを分類する作業のことです。 JavaScriptのブラウザ・プロジェクトでエラーを捕捉するのはとても手間がかかります。それは、単一の環境だけではないからです。一般的に数多くの主要ブラウザ、JavaScriptエンジン、オペレーティングシステム、そしてブラウザ拡張のエコシステムが存在します。そのため、関連するエラーを効果的に捕捉するのは難しいのです。 Sentryは、このようなノイズをできるだけ減らすために、多くの機能を迅速に実行します。しかし、いくつかのステップを追加するだけで、簡単にエラーに優先順位をつけることができるので、重要なことに集中することができます。そのため、開発者はすぐに修正する必要があるものだけに集中することができます。 ソースマップとタグリリースのアップロード ソースマップは、コードを最小化しないことで、本番環境のスタックトレースデバッグを容易にします。また、ソースマップはSentryがエラーを個々のissueにグループ化することを容易にします。これは、イベントがより小さく、より管理しやすいissueの集合にバケットされ、issueストリームのノイズが少なくなることを意味します。 ソースマップのアップロードを設定する最も簡単な方法は、Sentry Wizardを使用することです。以下のコマンドを実行するだけで必要なSentryパッケージをインストールし、ソースマップを生成してアップロードするようにビルドツール/CIを設定することができます。 ここでは、ソース・マップ・ドキュメントをサポートするためのドキュメントをいくつか紹介します。 ソース・マップは、ノイズを減らすのに役立つだけでなく、モニタリングとデバッグのワークフローを改善する上で、最もインパクトのある改善となる可能性を秘めています。 ソースマップをアップロードしたら、リリースバージョンをSentry SDKに渡すようにしてください。以下のようになるはずです。 本番ビルドのために、本番稼働中に環境変数経由で渡すことで対応してもよいでしょう。 元のエラー原因を渡す try...catchステートメントを使うと、同じエラーを再スローする代わりに新しいエラーをスローすることがあります。元のエラーのコンテキストを保持し、新しいエラーに原因を追加することができます。これは、Chrome 93、Safari 15、Firefox 91以降のブラウザでサポートされています。 リンクされたエラーは、SDKでデフォルトサポートされており、エラースタックはグループ化され、元のメッセージと共に表示されます。元のエラーを原因として渡すと、スタックトレースにコンテキストが追加され、デバッグ時に役立ちます。 実行不可能なエラーを無視する Sentryではあらゆる種類の興味深いエラーを見てきました。ページに直接注入されたカスタムJavaScript、ブラウザの拡張機能、無駄なエラーを投げるベンダーのコードからエラーを出力します。あなたのアプリケーションでも、これらのエラーのいくつかを見たことがあるかもしれません。 一般的に、エラーはあなたのコードからではないので、これを修正することはできません。 ノイズの原因になっている場合は、ignoreErrorsを使用してSDKで無視することができます。 Sentryの開発者は、実際に私たち自身の環境でいくつかのエラーを黙殺してきました。 TypeError: can't access dead object というエラーは、ブラウザ拡張機能が削除された DOM 要素にアクセスしたときに Firefox がスローするエラーです。これらのエラーは、ブラウザ拡張機能を作成していない場合、通常は対処できません。 'Node' で 'removeChild' の実行に失敗しました： 削除するノードはこのノードの子ではありません。これは、Chromeなどのブラウザでtranslate機能が有効になっていて、Reactがコンポーネントを更新しようとしたときにReactがスローするエラーです。このエラーは、文字列リテラルをスパンでラップすることで修正できますが、大規模なアプリケーションでは、これを強制するのは困難な場合が多いです。Sentryアプリは、ユーザー設定で有効にできる翻訳機能も提供しています。 これらのエラーは、ignoreErrorsを宣言することで、報告される前にクライアント上で直接フィルタリングすることができます。 プロジェクトの受信フィルタを有効にする プロジェクトレベルのフィルタは、Sentry JavaScript SDKのignoreErrorsと同様に、issueストリームにissueが表示されないようにすることができます。設定 → プロジェクト → プロジェクト設定 → 受信フィルタ で有効にできます。アプリケーションのコードに起因しないブラウザのエラーによって引き起こされる可能性が高いエラーを抑制するために、ブラウザの拡張機能によって引き起こされることが分かっているエラーをフィルタリングする、およびローカルホストから来るイベントをフィルタリングするをオンにすることをお勧めします。 インバウンドフィルタページで独自のルールを作成し、カスタムエラーメッセージをフィルタリングすることもできます。例えば - *ResizeObserver loop limit
- [エスカレーションする問題で、トレンドの問題をより早く見つける](https://ichizoku.io/sentry/find-trending-problems-faster-with-escalating-issues/) - どのissueを優先し、最初に解決すべきか判断することは、開発者が共通して直面する問題です。 この問題に対処するため、Sentry は、エスカレーション、進行中およびアーカイブの課題ステータスのような新機能をリリースしました。 さらに、優先度ソートを更新し、最も重要な課題をより簡単かつ迅速に特定できるようになりました。開発者が最も重要な課題を特定するのに役立つ機能を以下で紹介していきます。 新しい問題状態の導入 Sentryは、新しい問題から始まり、進行中の既知の問題、解決またはアーカイブされた問題まで、問題のライフステージに関するより多くのコンテキストを提供するようになりました。修正された問題がいつクローズするか、進行中の問題やアーカイブされた問題がいつ劣化するかを簡単に発見できるように、RegressedとEscalatingという2つの新しいタブが追加されました。 以前は "Regressressed "というステータスがありましたが、それはユーザーが以前に問題を解決（つまり修正）し、その問題が引き続きイベントを受信している場合にのみ表示されるものでした。しかしこのロジックでは、悪化しつつあり、優先されるべきissueが考慮されていませんでした。 このロジックにより、無視のアクションとステータスをアーカイブに置き換えることにしました。 以前は、「無視」機能は開発者が行える正確なアクションではありませんでした。問題を見えなくする最も簡単な方法でした。 しかし、問題が悪化し始めた場合には役に立ちませんでした。 というのも、いつ無視されなくなるかのしきい値を手動で定義しなければならなかったからです。現在では、アーカイブによってissueはアーカイブ・タブに移動し、issueがエスカレートして悪化し始めると、issueはエスカレーションに移動します。issueが以前にアーカイブされたか、一度も対処されなかったかにかかわらず、issueが通常よりも著しく多くのイベントを受信した場合に、新しいエスカレーションissueステータスが割り当てられます。 また、その他の要因も考慮されます。これにより、issueフィードを整理しやすくなり、優先度の高いissueをより早く特定することができます。課題のエスカレーションはアルゴリズムに基づいて行われるため、どの課題に焦点を当てるべきかを手動で判断する必要はありません。 ベータテストでは、アルゴリズムによってエスカレーションされた課題は、解決される可能性が3倍高いことがわかりました。 また、エスカレーションのしきい値を手動で設定した場合と比較して、これらの課題が再度アーカイブされる可能性も低くなりました。 ソートと検索の改善 早急な対応が必要な問題を特定するために使用できるもう1つのツールが、課題ストリームの優先順位ソートオプションです。最近、優先順位ソート機能がアップグレードされ、年齢、全体的なイベント量、最近のイベント量に基づいて課題が順番に表示されるようになりました。例えば、イベント件数の多い新しい課題は、イベント件数の少ない進行中の課題よりも優先順位が高くなります。どのような課題を上位に表示すべきか、ご意見があればGitHub のディスカッションスレッドに投稿してください。 また、重要な問題をより簡単に見つけるという精神に基づき、問題検索バーに人気フィルターを導入しました。 問題への迅速な対応 注意が必要な問題を素早く見つけることは、Sentryにおける良いユーザー体験の核心であると言えます。上記の改善は、Sentryにログインするたびに、「ホットフィックスに値する」問題を簡単に見つけられるようにするためのほんの始まりにすぎません。 IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。またご導入についての相談はこちらのフォームからお気軽にお問い合わせください。
- [Node.jsのプロファイリングでコードレベルのボトルネックを解決する](https://ichizoku.io/sentry/profiling-for-node-js/) - プロファイリングは、最も重要なツールです。 プロファイリングを利用することで、本番環境で実行中のプログラム情報を詳しく見ることができます。 パフォーマンスのボトルネックは、ローカルで再現するのが非常に困難であったり、不可能であったりすることがよくあります。そのため、この機能はとても重要であるといえます。 再現が困難である理由は、外部制約や本番環境特有の負荷が理由にあります。 Sentryでは、iOSとAndroidのプロファイリングのサポートをリリースした後、他のプラットフォームもサポートするように取り組んできました。そのうちの一つがNode.jsです。Node.jsのプロファイリングは、現在ベータ版です。 Node.jsのプロファイリングのセットアップ Node.jsのプロファイリングを設定するには、@sentry/profiling-node パッケージをインストールする必要があります。次に、パッケージをインポートします。その後、プロファイルに必要なサンプリングレートを設定します。 プロファイリングは、当社のSentryパフォーマンス上で動作します。 そのため、Sentryパフォーマンスもセットアップする必要があります。 これらのセットアップが完了すると、Sentry.startTransactionとtransaction.finishの間のすべてのコードが自動的にプロファイリングされるようになります。 プロファイリングは実際に何をしているのでしょうか？ 本パッケージは、内蔵のV8プロファイラを使用しており、サンプリング周波数が最大100ヘルツでスタックサンプルを取得します。プロファイル結果のスタックサンプルはSentryダッシュボードにアップロードされます。 すると、そのサンプルをフレームチャートの形で可視化することができます。フレイムチャートでは、プロファイラが収集したスタックサンプルを時系列で確認することができます。 これにより、プログラムがどの関数呼び出しに最も多く時間がかかっているのか確認することができます。 自分たちのコードをプロファイリングしてわかったこと まず、Chartcuterie（Slackで共有されるチャートリンクのサムネイル画像を生成するサービス）を実行するExpressサーバーにプロファイリングを導入し、フロントエンドのテストスイート全体と、社内のSlackボットにも導入しました。 コードのプロファイリングを成功させるために、まず、すべてのサービスでSentryの パフォーマンスサービスがインストールされていることを確認します。 Sentryはサービス全体のレイテンシー問題を追跡するので、プロファイルとトランザクションを簡単に関連付けることができます。これにより、リクエストが遅くなっている原因を特定することができます。 パフォーマンスのダッシュボードは、アプリケーションがどのように動作しているかを確認するのに役立ちました。プロファイリングを導入する前と後では、p75の時間を正確に追跡することができました。 パフォーマンスの原因を探る-ネタバレ：テストコードとは限らない Sentryのフロントエンドのコードは、約400のテストファイルにまたがる4000のテストから構成されています。 CI環境からいくつかのプロファイルを確認した後、いくつかのテストでloadFixtures関数呼び出しの内部にかなりの時間がかけられているこることがわかりました。loadFixturesの呼び出しは setup.tsスクリプトの一部で行われます。 これは、テストの実行前に実行され、テストが実行できる環境を準備します。 フレームチャートを見ると、テストのセットアップコードがテスト時間の大部分を占めていることがわかります。そのため、テストセットアップが何を行っているのかを確認することにしました。 擬似的なコードでは、loadFixturesは次のように動作しています。 このコードには何の問題もありません。むしろ、このコードによって、require/import文を書かなくても、テストの内部で一部のコードをスタブ化することができるようになりました。しかし、これはメリットだけではありません。 stubsDir内にあるすべてのコードを（たとえテストで実際に必要とされないものであっても）ロードしてしまいます。 この問題は、Jestがrequire.cacheを採用しないことが原因となり、さらに深刻なものになります。 さらに、setupFilesAfterEnvで定義されたスクリプトが1ファイルにつき一回実行されるということも、問題の原因です。 この問題を解決するために、JavaScriptのプロキシを活用し、require文を遅延ロードさせるようにしました。これにより、パフォーマンスに影響を与えることなく、問題を解決できました。 また、具体的な修正内容はこちらでご覧いただけます。 スローテストを探す Sentryのフロントエンドテストの中には、実行にかなり時間がかかるものがあります（時には数分を超えることもあります）。 その理由はテストによって異なりますが、あるテストは、大きな依存関係グラフを持つ複雑なコンポーネントをテストしているためであったり、すべてのコードを初めてトランスパイル（あるプログラミング言語から、他のプログラミング言語に変換すること）すると、動作に時間がかかったりします。 また、レンダリングに時間がかかるコンポーネントをテストしている場合も同じように動作が遅くなります。 さらに言えば、私たちのテストはデフォルトのGitHub Ubuntuランナー上で実行しています。これはローカル開発で使っているM1チップのmacOS環境とはかなり異なる環境です。 あるコードの実行が遅い理由として、さまざまなことが考えられます。 しかし、プロファイリングがなければ、原因を正確に把握することは難しいでしょう。そのため、実際の本番環境から収集したプロファイルを持つことが非常に重要なのです。 そこで、いくつかのプロファイルがウォーターフォールパターンを示していることに着目しました。 上のフレームグラフでは、keyboardImplementationの呼び出しがウォーターフォール型になっており、テスト実行全体のおよそ7回呼び出されていることがわかります。 これは、テスト時間の大部分を占めています。 また、新しいチームメンバーが招待されたときに、ユーザーに表示されるモーダルをテストしていました。 長文のメールを送信する際に、 userEvent.typeを繰り返し使用していました。そのため、コンポーネント全体の再レンダリングが発生していました。 レンダリングを最適化するためにコンポーネント自体を書き直すことはすぐに対応できることではないため、現実的ではありません。しかし、おそらくそれが最良の解決策だったのでしょう。 私たちは、userEvent.pasteを使用して、ユーザーがメールアドレスを入力することをシミュレートすることで、負荷を軽減することを選びました。これにより、文字列の各文字に対してイベントを発生させることなく、テストの速度を向上させることができました。 当社のサービス以外の問題を発見する Chartcuterieサービスは、Slackのリンクが共有されるたびに、サムネイルを生成します。 これにより、ダッシュボードを開かなくても、Slackですぐにチャートを確認することができます。しばらくの間、このサービスはメモリリークに悩まされており、その都度、再起動させる必要がありました。 最終的に、メモリリークの原因はプロファイリングを活用する前に特定することができ、修正されました。 メモリリークの根本的な原因を調査するのは難しく、簡単な修正作業ではありませんでした。
- [Androidの例外を処理し、アプリケーションのクラッシュを回避する方法](https://ichizoku.io/sentry/how-to-handle-android-exceptions-and-avoid-application-crashes/) - まず、2つのことについて説明します。 例外とは、プログラムの実行中に発生し、本来のプログラムの動作を中断させるものです。そして、例外処理とは、例外に対応するための処理のことです。 Androidでは、例外を処理しないとアプリケーションがクラッシュし、恐ろしい「App keeps stopping」ダイアログが表示されることになります。 クラッシュし続けるアプリを使う人はいないですよね。ですので、例外処理を行うことは非常に重要なことであるといえます。 この記事では、例外を処理するいくつかの方法と、「処理されない例外」を処理する方法を紹介します。 また、これらの例外をキャッチする方法も紹介します。今回の記事における例については、Kotlinで解説します。 例外の階層構造 すべての例外は、Throwableのサブクラスです。ドキュメントによると… ''Throwableクラスは、Java言語におけるすべてのエラーと例外のスーパークラスです。このクラス（またはそのサブクラスの1つ）のインスタンスであるオブジェクトのみが、Java仮想マシンによってスローされるか、Javaのthrow文によってスローすることができます。" 例外の種類 Javaでは、例外は主に大きく2つに分けられます。チェックされた例外と、チェックされていない例外の2種類です。 チェックされた例外： コンパイル時にチェックされる例外です。例外を投げるメソッドを呼び出す場合は、呼び出し側として例外を処理するか、throws句で宣言する必要があります。 チェックされる例外の例： IOException、NoSuchMethodException、ClassNotFoundException チェックされていない例外： コンパイル時にチェックされない例外のことです。 チェックされていない例外の例： NullPointerException, ArithmeticException, ArrayIndexOutOfBoundsException。 興味深いのは、Kotlinにはチェックされた例外がないということです。次のコードをご覧ください。 このメソッドを呼び出したら、どうなると思いますか？「実行時例外が発生する」と思ったあなたは正しいです。 別のコードを考えてみましょう。 doSomethingメソッドを呼び出すと、ClassCastExceptionが発生します。 これらのスニペットを実行したい場合は、ここで実行することができます。 とあるシナリオ（処理のパターン）を定義するために、内蔵の例外クラスでは不十分な場合があります。このような場合、独自の例外を作成することも可能です。 例外処理のさまざまなやりかた 例外について理解したところで、例外をどのように扱えばよいかを見ていきましょう。まずは、例外を投げる小さなコードの一部を考えてみましょう。 このメソッドを呼び出して例外を処理しないと、アプリケーションがクラッシュし、「App keeps stopping」ダイアログが表示されることになります。 この例外を処理する最も簡単な方法は、メソッド呼び出しをtryブロックで囲んで、例外をキャッチすることです。必要であれば、finallyブロックで処理を追加することもできます。 例外をキャッチするだけで、finallyブロックで実行する追加処理がない場合、KotlinはrunCatching関数を提供します。 これらのスニペットを実行したい場合は、ここで実行することができます。 例外を伝播させる あるメソッドがさまざまな例外を投げる場合、そのうちの一部だけを受け取り、他の例外は上位に伝搬させるというパターンが考えられます。 次のようなコードを考えてみましょう。 try/catch文を使うと、次のようなことができます。 runCatchingを使うと、以下のようなことができます。 ここで重要なことは、例外を伝播させるため、より上位で例外を処理する必要があるということです。 これらのスニペットを実行したい場合は、ここで実行することができます。 Androidの例外処理 上記のテクニックを使って例外を処理するサンプルアプリケーションを考えてみましょう。 このアプリには1つの画面があり、2つのボタンがあります。それらがクリックされると何らかの処理が行われるようになっています。 最初のボタンは必要な例外処理をしており、2番目のボタンをクリックするとアプリがクラッシュします。 コードは非常にシンプルです。 実際のところ、どんなに最善を尽くしてもすべての例外を処理することは非常に困難です。もしかしたら、内部ライブラリの例外が発生するかもしれませんし、稀に処理されない「エッジケースシナリオ」があるかもしれません。 では、アプリケーションがクラッシュする頻度を最小限にするためには、どうすればよいのでしょうか。 Thread.UncaughtExceptionHandlerインターフェイスを使用することで、デフォルトの例外ハンドラにフォールバックすることが可能です。 しかし、デバッグアプリでこれを行うことは決してお勧めしません。なぜなら、クラッシュが発生したらすぐにフィードバックが欲しいからです。 これで、2つ目のボタンをクリックしても、例外を明示的に処理していないにもかかわらず、アプリがクラッシュすることはなくなりました。 これまで、さまざまな例外処理の方法と、デフォルトの例外処理されていない時の例外ハンドラを提供する方法について見てきました。では、さらに一歩進んで、これらの例外を監視する方法を見てみましょう。
- [FastCo.が選ぶ2022年最も革新的な企業の一つで、プラットフォームの安定性を最優先する](https://ichizoku.io/sentry/prioritizing-platform-stability-and-ux/) - フィットネス業界では、ずいぶん前に「スマート」な機器をビジネスモデルに取り入れていました。 最近では、ユーザー体験の高さで差別化をはかり、競い合っています。 安定性と品質は、プロダクトの成功に不可欠です。 これはトナール社の開発者たちにとっての最重要課題でした。 「ユーザー数は多いのですが、バグを報告するユーザーは比較的少ないです。私たちは非常に安定した製品を持っており、目標はそれを維持することです。- トナール社、モバイルソフトウェアエンジニアリングシニアマネージャー、マックス・ラピデス氏」 トナール社は、ニューヨークマガジンのベストスマートホームトレーニングソリューション2022年にランクインしています。 また、メンズヘルスでも、ベストコネクテッドケーブルマシン2022にランクインしています。 トナール社は、スマートホームトレーナーの業界水準を定めており、その標準を維持するために、開発者たちは製品がユーザーの期待に応えられるように、今までとは違うアプローチをとっています。 彼らは、製品の問題を減らすだけでなく、完全に無くすことに注力しています。 「エラーやクラッシュを減らそうという意識は持っていません。なぜなら、私たちは、システムがクラッシュすることを想定しておらず、システムはクラッシュしないと想定しています。」 バグのないUXを実現するワークフロー 当たり前ですが、システムエラーはどのシステムにも存在します。しかし、そのエラーがユーザーに影響を与えることを防がなければなりません。 そのためには、パフォーマンスモニタリングと自動エラーレポートを開発作業に取り込む必要があります。 マックスのチームは、Debug Symbolを使用して、エラーログをデバッグの段階で活用することでこれを実現しました。 そして、スタックトレースからSentryが提供する追加のデータコンテキストを使用しています。 例えば、このスタックトレースだけでは、必要なコンテキストデータがあまり得られないため、デバッグには使えません。 しかし、マックスのチームがデバッグ用のシンボルをSentryにアップロードすると、シンボル化されたスタックトレースができてしまいます。 「Sentryがなければ、これらのデバッグ用シンボルファイルを収集する必要があります。Sentryは、App Store Connectや CIシステムからのアップロードから自動的に収集します。これにより、不明瞭で難解なデータを人間が読めるものに変換することができるようになります。」 トナール社がスムーズなUXを維持するもう一つの方法は、Sentryにパンくずリストを設定することです。 これにより、問題を調査している開発者たちは、エラーにつながったユーザーのアクションを時系列で確認することができます。また、問題を再現し、迅速に解決するために必要なすべてのコンテキストも確認することができます。 「これらのユーザーイベントは、デバッグに役立つアプリ内のユーザーのアクションの流れを表していることに気づきました。そこで、現在ではこれらのユーザーイベントもパンくずリストとしてSentryに送信しています。 これにより、Sentryを起動したまま、問題が発生する前のユーザーの行動を正確に把握できるようになりました。」 例えば、新機能のエッジケースのテストでQAエンジニアが、UIの問題を見つけることがあります。 Sentryは、ユーザーがエラーに至るまでに行ったHTTPリクエストや、ユーザーが行ったナビゲーションなど、その問題に関するリアルタイムのデータを表示してくれます。 また、Sentryは担当チーム、Flutterのバージョン、ビルド番号などの詳細なコンテキストデータも提供してくれます。 これにより、対処可能なバグレポートを提出することが簡単になります。 バグレポートには、問題を再現し、最終的に解決する方法について、十分な情報が詳細に含まれています。 コードを "即断即決で "修正することなどありえない トナール社は、2019年から続いている2週間のスプリントとデプロイの徹底した周期に従っています。しかも、そのペースは2019年から変わっていないそうです。 規則的で予測できるリリースは、安定して高性能なユーザー体験を提供するための高い基準をチームに課すことになります。しかし、モバイルでは、その場でコードを修正することは、あまり現実的ではありません。 「AndroidとiOSの両プラットフォームに対応したアプリを再構築する必要があります。そして、24時間から48時間かけてレビューを行い、Google PlayとApp Storeの両方にリリースすることができます。その後、ユーザーの端末で自動的にアップデートされるのを待ちます。重要な機能を追加する場合は、さらに3日ほどかかることもあります」 そのため、マックスのチームはデプロイ前の約一週間、QAでビルドを確認し、リリース用のダッシュボードで監視するようにしています。 リリースは個々のビルド番号で標準化されており、QAを通過すると、チームは最新のビルド番号を「ゴールドマスター」と宣言します。 これで本番リリースの準備が整います。 「Sentryで重大な問題が確認された場合、通常48時間以内に修正することが可能です。しかし、目標はこうした問題が本番環境で発生しないことです。」 トナールのチームは、プラットフォームの安定性、復旧力、ユーザー体験に重点を置いています。マックスのチームは、開発能力とSentryのカスタムソリューションを組み合わせているため、以下のようなことができるようになります。 詳細なコンテキストデータを含むエラーを積極的に監視します。 プラットフォームの安定性とUXに直接影響を与えるエラーを簡単に優先順位付けすることができます。 品質を犠牲にすることなく、きっちりとリリーススケジュールを維持します。 アプリ内のユーザー行動を分析し、解決までの時間を短縮します。 ユーザーに高いパフォーマンスのUXを提供することで、他社よりも優位になります。 「Sentryは、私たちがプラットフォームの安定性を維持するのに役立ちます。 Sentryは、ユーザーたちに直接影響を与えるようなコードをリリースするのを防いでくれます。私たちにとって良い日とは、クラッシュがないときです...それが毎日ならいいですが」 Sentryは、アプリケーションコードの健全性を監視するために不可欠です。エラートラッキングからパフォーマンスモニタリングまで、開発者は、フロントエンドからバックエンドまで、アプリケーションをより明確に把握し、より迅速に解決し、継続的に学習することができます。
- [Pythonのプロファイリングでコードレベルでボトルネックを解決](https://ichizoku.io/sentry/profiling-for-python/) - プロファイリングは、最も重要なツールです。 プロファイリングを利用することで、本番環境で実行中のプログラム情報を詳しく見ることができます。 パフォーマンスのボトルネックは、ローカルで再現するのが非常に困難であったり、不可能であったりすることがよくあります。そのため、この機能はとても重要なのです。 再現が困難である理由は、外部制約や本番環境特有の負荷が理由にあります。 Pythonは、最も人気のあるプログラミング言語の一つです。 SentryもPythonをメインに開発しています。Pythonのプロファイリングは現在ベータ版です。しかし、sentry-sdk==1.11.0を利用することでWSGIアプリケーションで利用可能になります。 これにより、実運用でのアプリケーションのパフォーマンスについて、コードレベルで把握することができます。 Pythonのプロファイリングを始めるには、SDK上でprofiles_sample_rateを設定するだけです。 SDKは100ヘルツのサンプリング周波数でサンプルを取得する別スレッドを実行します。 プロファイルが終了すると、サンプルはSentryに送られ、プロファイルがフレームチャートとして可視化されます。 フレームチャートは、エンドポイントや遅いトレースにおいて、頻繁に実行されるコードを素早く見つけ、リソース消費（例：CPU）を最適化することができます。 SentryプロファイリングでSentryを改善する 長い間、Sentry上でPythonプロファイラの内部バージョンを実行することで、Sentryを最適化することができました。 日付時刻と連携 多くの人は、時系列で確認できることほど嬉しいことはありません。そのため、Sentryの様々なところで時系列グラフを用意しています。しかし、時系列グラフの生成には時間がかかります。 処理が重い箇所を調査したら、 discover.discover - timeseries.transform_results が原因である可能性があることがわかりました。 さらに調査を進めると、この関数が本当に原因であることがわかりました。 たまに数百ミリ秒の遅さになることがあり、これはデータ取得のクエリよりも遅いです！ 実はクエリよりも後処理の方が遅いんです！ コードを見ると、単純な変換をしているだけでした。そのため、根本的な原因はすぐには分かりませんでした。しかし、プロファイルを見ると、リクエストの大半が、ゼロフィル（データが全て0埋めになっている状態のこと）内で日付のパース処理だということがわかりました。 ゼロフィル内の日付時間のパース処理でした！ これを知った時は驚きました。 検証するために、いくつかの簡単なベンチマークを行ました。また、日付と時刻の文字列をパースするいくつかの方法を比較してみました。 それは衝撃的事実でした。なぜなら、dateutil.parser.parseからdatetime.datetime.fromisoformatに変更することで、数百倍速くなる可能性があるからです！ datetime.datetime.fromisoformatは完全なISO 8601通りのパース関数ではありません（とりあえずはPython 3.11までは）。しかし、我々はdatetime.datetime.isoformatに満足していました。なぜなら、この一行を変更するだけで、最悪な状況が大幅に改善されるからです。 Django：プリフェッチするかしないか プリフェッチはDjangoでよく採用されるテクニックです。 これは、関連するオブジェクトにアクセスする時に、大量にデータベースクエリが発生するのを防いでくれます。 オブジェクトごとに1つのクエリを作る代わりに、プリフェッチすることによって、関連するすべてのオブジェクトを一度に取得する一つのクエリを作ることができます。 Sentryの様々な場所でこの技術を採用しています。しかし、ユーザーのエンドポイントが非常に遅いことに気づきました。大きな影響を与えずに、関連するオブジェクトにプリフェッチを使用するようにしました。 いくつかのトランザクションを見ると、興味深いことがわかりました。 それは監視できていない期間があったのです。さらに最も興味深いのは、それがいくつかのデータベーススパンに散らばっていたことです。 また、コードを調べてみると、これらのデータベーススパンは以下のクエリに対応していることがわかりました。 最初のクエリはOrganizationMemberに対するもので、それに続く3つのクエリはprefetch_related内で指定された3つのルックアップに対するものです。 プロファイルを調べると、prefetch_related_objectsがありました。これはDjangoの内部呼び出しで、リクエストの大部分を占めています。 OrganizationMemberとTeamの間の多対多の関係、そしてTeamとProjectの間の多対多のリレーションクエリをしていたことがわかりました。 prefetch_relatedを使ったクエリは高速でしたが、Djangoは結合処理を実行していました。つまり、一部のチームとプロジェクトを取得しただけですが、 DjangoはすべてのOrganizationMember、Team、Projectを繰り返し、関連するオブジェクトを属性として設定していました。 この知識をもとに、クエリの書き換えに取り掛かりました。 Pythonでこの結合処理を実行したくはなかったのです。prefetch_relatedを削除し、関連するオブジェクトを手動でフェッチし、レスポンスを丁寧に構築することで、これを達成することができました。これにより、p95は50%近く減少しました！ プロファイリングはパフォーマンスを補完する プロファイリングは、Sentryパフォーマンスを完璧に補完します。 パフォーマンスが問題を大まかに把握することができますが、プロファイリングは正確なプログラムのコード行番号まで把握することができるので、簡単に問題を解決することができます。 コードのプロファイリングをできるようにするために、まずすべてのサービスをSentryのパフォーマンス製品で接続するようにしました。 Sentryは、サービス全体のレイテンシー問題を把握することができます。 これにより、プロファイルとトランザクションを簡単に関連づけることができ、遅いリクエストの根本原因を特定することができます。 パフォーマンスのダッシュボードは、アプリケーションがどのように動作しているかのを把握するのにも役立ちました。プロファイリングを導入する前と導入した後を比較すると、P75の時間やスループットなどを簡単に把握することができました。 早速いまからプロファイリングを始めてみましょう。 最初に「パフォーマンスを計測する」を確認してください（わずか5行のコードで可能です）。
- [Pythonのテストを数百の環境で高速に実行する方法](https://ichizoku.io/sentry/how-we-run-our-python-tests-in-hundreds-of-environments-really-fast/) - 長文を読む気分ではない方は、ここからDjangoCon 2022で行われた講演（英語）を見ることができます。 Sentryの信念のひとつに「すべての開発者のために」というものがあります。 すべての開発者をサポートしたいと思っています。しかし、すべての開発者が最新の技術や広く採用されている技術スタックを使っているわけではありません。そのため、古いバージョンのライブラリやフレームワークもサポートするように心がけて取り組んでいます。 当社のSentry SDK for Pythonでは、次のことをサポートしています。 約20種類のWebフレームワーク Python2.7を引き続きサポートします（！） Python 3.5から3.11まで対応しています 古いバージョンのフレームワークをサポートしています。(例：8年前のDjango 1.8をサポートしています） SDKが正しく動作することを確認するために、テストスイートには約450の自動テストが用意されており、SDKに変更を加わるたびに実行されます。 7つのPythonのバージョンと約20のフレームワークをサポートしているため、それぞれのフレームワークのバージョンが2～9になると、テストを実行する環境は400を超えます。 テスト用スタック テストスイートはpytestを使用して実行されます。 テスト実行前に、Flake8とblackを使ってソースコードのリントとフォーマットを行い、mypyを使って型チェックを行っています。 Toxは、さまざまな環境でテストスイートを実行するためのツールです。 ローカルマシンの異なる環境でテストスイートを実行するために、古き良きmakeを使用しています。そして最後に、GitHub ActionsをCIとして使用し、すべてのプルリクエストに対してすべての環境でテストスイートを実行できるようにしています。 スローテスト 私たちのテストセットアップは何年も前に作成され、時間の経過とともに多くのテストが追加されました。 しかし、テストセットアップ自体をリファクタリングする時間がありませんでした。そのため、テストスイートを実行するのに約40分も時間がかかっていました。 このようなテストスイートは、苦痛でしかありません。 SDKの新しいバージョンをリリースする際には、リリースごとにテストスイートを実行するため、テストが完了するのに最大で1時間もかかることもありました。 これは由々しき事態です。そこで私たちは、テストスイートの改善に取り組みました。 テストスイートを高速化する すべてのテストをリファクタリングすることなく、より速くテストを実行する方法について、いくつか考えました。どのようなことをしたのかをご紹介します。 フレームワークごとにテストスイートを分割 テスト実行にかかる時間を大幅に短縮 開発者の生産性を向上 考えた結果、テストそのものではなく、テストの実行方法を変えようという結論に至りました。 まず、テストスイートを改善するのに着目したのは次のことです。それはいままでそれぞれのプルリクエストで、すべての環境でテストスイートを実行するGiHub Actionsランナー1つでToxを起動し、1つずつ実行していました。 これは、テストを実行する上で最も遅い方法であり、1回の実行に38〜42分はかかります。 アイデア1：toxでテストスイートを並列に実行する Toxのコマンドラインには、--parallel autoオプションがあり、利用可能なCPUコアの数だけテストスイートを並列実行することができます。 これにより、すでにテストの実行時間は劇的に改善されました。 今まで40分かかっていたテストが、25分程度になったのです。しかし、これではまだ「速い」とは言えません。 GitHub ActionsのランナーはCPUコアを2つしか持っておらず、使用できるCPUコア数には限界がありました。 アイデア2：GitHub Actionsを使ったテストスイートの並列実行 GitHub ActionsのランナーのCPUを増やすことはできませんが、GitHub Actionsのランナーを増やすことは可能です（大きなマシンを購入しない場合）。 そこで、テストを実行するすべての環境に対してGithub Actionsの設定yamlファイルを作成するスクリプトを作成しました。 アイデアとしては、このようなものでした。 しかし、GitHub Actionsの同時実行できるワークフローにも制限があることがわかりました。 私たちはGitHub
- [コードカバレッジインサイト - スタックトレースで確認できるようになりました](https://ichizoku.io/sentry/code-coverage-insights-now-in-your-stack-trace-announcing-our-codecov/) - その理由 コードカバレッジとは、テスト手法の一つで、どのコードがテストされているかを知らせるもので、パーセントで表示されます。 コードカバレッジは、コードの総行数のうち、全体の何割がテストされているのかを把握することができます。 また、テストを書くことはとても大変です。しかし、コード変更があると、せっかく書いたテストコードも変更内容をテストできているかがわかりません。 このストレスから、共同創業者のイーライ氏と私は、テスト駆動開発で解決したいと思うようになりました。 私たちは、（まだ）存在していないものを作ることが好きです。 また、ほとんどの開発者はエラーが発生するコードのテスト状況を見たいだろうと思っていました。 しかし、SentryがCodecovを買収したとき、次のような反応が最も多かったです。 それは私たちもとても感じていました。 Codecovを使ってコードレビューしても、デプロイ後の作業にはあまり役立ちませんでした。 長い間、ユーザー／顧客向けの製品に携わる開発者は、"OK、でも次の問題は何？"ということに向き合ってきました。 その問題は、おおよそ次のように表現されます。 アプリでエラー・不具合内容を受け取る エラー周辺のデータを開く（アプリケーションのパフォーマンス監視と例外処理） "よし、でも次はどうする？" 別画面で自分のIDEを開く 2つの画面を見渡し、コードのメンタルモデル（価値観やイメージのこと）を構築する。 そのコードにテストがあるのなら、根本的な原因を修正する方法を考える。 必要であれば、今後同様のエラーが発生するのを防ぐために、基となるソースコードを変更し、テストを記述・編集する。 さらに一歩踏み込むと… もしエラーが発生するコードがテストされていない場合、次のステップは、このケースを中心にテストを書くことかもしれません。 または もしエラーが発生するコードがテストされていた場合、次のステップとして、問題のテストとコードのロジックとの関連性を調査します。例えば、テストケースに見落としがないかを確認します。 SentryのスタックトレースにCodecovを導入することは、本番前とデプロイ後のデータ連携を実現する最初の取り組みです。 これにより、問題が発生した際のデバッグやパッチ適用がより迅速かつ容易になります。 何を？ ひとことで言うとCodecovのSentry連携を使えば、Sentry Issueのスタックトレースでエラーの原因となる未テストのコードを直接確認することができます。 この機能を使うことで、さまざまなユーザー操作を考えたり、コードを手動で分析したりする必要はもうなくなります。 SentryにCodecovを導入すれば、テストするべき優先箇所を正確に把握できるので、時間を無駄にすることなく、信頼性の高いコードを維持することができます。 テストカバレッジを改善するために、数ヶ月に一度「カバレッジ週間」を設けて、コードのテストを改善していました。しかし、SentryとCodecovの連携により、コードを分析し、テストカバレッジが必要な箇所を考えることはなくなりました。さらに、Sentryが取り組むべき箇所を正確に教えてくれるので、テストカバレッジの構築に費やしていた時間を約50%ほど削減できました。 - アレックス・ナサネイル（技術担当ディレクター）＠vectare.co.jp Codecovの使用方法 前提条件： Sentryの場合 SentryのGitHubインテグレーションをインストールし、Codecovにテストカバレッジデータがあれば、使い始められます。 また、GitHubインテグレーションにCode Mappingsをセットアップする必要もあります。これはテストカバレッジを表示するためのソースコードファイルを把握するのに必要です。 GitHubを使われていない方は、GitLabとBitbucketは対応中ですので、しばらくお待ちください。 Codecovの場合 Codecovにサインアップするだけです。一度アカウントを取得すれば、テストされていないコードが本番環境でエラーを引き起こしている箇所をワンクリックで確認できます。 コードカバレッジは初めてですか？ 大丈夫です。詳しくはこちらをご覧ください。 SentryとCodecov - スタックトレースでコードカバレッジを即座に確認できるようになります。 最も簡単な方法 - 全く何もする必要はありません。両方のサービスでセットアップされたときに、自動連携を有効にする日次ジョブを実行します。 簡単な方法 - すぐにでも始めたい場合は、設定ページに移動し、「コードカバレッジインサイトの有効化」をオンにしてください。
- [Sentryのプロファイリング： コードレベルでパフォーマンスのボトルネックを特定し排除する](https://ichizoku.io/sentry/profiling-from-sentry/) - ユーザーからロードが遅いと言われたため、ログやトレース、メトリクスを通して分析をしました。 さらに、アプリケーションのパフォーマンスの原因を特定するために、利用可能なデータはすべて分析しました。 しかし、それでもボトルネックの原因を突き止めることはできませんでした。 もしかしたら、監視が十分じゃなかったのかもしれません。 あるいは、本番環境と大きく異なる環境でテストしているだけかもしれません。 いずれにせよ、根本的な原因を突き止めるのに、精神的負荷と時間がかかります。 このようなパフォーマンスの悩みを解決するために、プロファイリング機能を構築しました。 現在、Python、Node.js、iOS、Android、PHPでは、最新の料金プランで利用可能です。 プロファイリングは、パフォーマンスの問題を引き起こしているプログラムの行番号までピンポイントで特定するため、Sentryのパフォーマンスを向上させます。 プロファイリングは、関数の実行時にその実行時間に関する本番環境のデータを収集します。 そして、その結果を集計して、あらゆる環境におけるアプリケーションのパフォーマンスを把握することが可能になります。 実行時間を推測したり、パフォーマンステストを書いたりする代わりに、アプリケーション内で非常に多く実行されるコードを確認し、パフォーマンスのボトルネックを素早く特定することができます。 さらに、プロファイリングは手作業による計測にかかる時間を短縮するため、導入後すぐにパフォーマンスを計測することができます。 プロファイリングによってパフォーマンスチューニング作業がどれくらい楽になり、ボトルネックをどのように修正するのかをご紹介します。 また、SDKのサポートに関する最新情報についてもご紹介します。 こちらは、動作の遅い関数からアプリケーションフレームやコールツリーまで掘り下げて、問題の原因となっているプログラムの行番号を特定するデモ画面です。 プロファイリングを始める準備はできていますか？詳しくは価格ページをご覧ください。 トランザクションからプロファイルまで掘り下げる Sentryパフォーマンスでは、トランザクションと期間ごとに、個々のサービスとそのサービスのパフォーマンスを表すトレースを収集することができます。 トランザクションを監視して、速度低下の原因となっている期間を特定するのに役立ちますが、多くのタスクで長時間実行される箇所の原因を特定するのは難しい場合があります。 長期間を小さく分割して計測するのではなく、プロファイリングを使用することで必要なコンテキストを提供することができます。 プロファイリングデータがあると、最も頻繁に発生するコールスタックが表示され、最適化すべきコードを教えてくれます。 以下の例では、特定のコールスタックが収集したサンプルの84.3%に、アプリ内関数の最上位がBigTableKVStorage.get_manyで、GCPのビッグテーブルクエリを実行していることがわかります。 詳細を見ると、その関数が定義されている正確なファイルと行番号がわかります。 さらにデバッグが難しいシナリオとして『一部のデータが抜けているケース』が挙げられます。 観測できていない箇所を推測する代わりに、プロファイリングはその時間帯に実行されるコードを教えてくれます。 これによって、コードのどこを修正する必要があるかがわかるだけでなく、このプレビューによって、新しく監視する箇所を追加しなくても根本的な原因を見つけることができます。 この例では、観測できていなかった474msまでの間が、Redisクラスタへの接続をしていたことがわかります。 さらに、フレームチャートビューアでは、すべてのスレッドのデータを含むプロファイル全体を表示します。 トランザクションデータはプロファイリングデータとインラインで表示されるため、その時間に関連する機能をシームレスに関連付けることができます。 フレームチャートの操作方法と解釈方法についての案内を作成しました。 開発者のヴィトール・カリクストはプロファイルを利用して、Azos Segurosの顧客保険金の分割払いサービスのパフォーマンスを向上させています。 ヴィトールは、フレームチャートを使用して、パフォーマンスの問題に関連するプロファイルを掘り下げ、リクエストが遅くなっている原因の関数コールを特定し、迅速に対応しました。 これにより、リクエストの実行時間が大幅に改善されました。 フレームチャートを使って、顧客決済サービス内で最も遅いデータベースリクエストを見つけることができました。 プロファイリングを使用することで、リクエストの実行時間を1000msから300msに短縮することができました。- アゾス・セグロス社 Vytor Calixto氏 プロファイリングで改善されるパフォーマンス問題 プロファイリングは、トランザクションデータをグループ化して、共通のパフォーマンス問題を検出するなど、パフォーマンス機能を補うものです。 プロファイリングデータが問題をコードレベルで可視化することによって、検出できることが増えます。 プロファイリング・データを活用する最初の新しい課題タイプは、iOSとAndroidでサポートされるJSON Decoding on Main ThreadとImage Decoding on Main Threadの2つです。 例えば、画像のデコード処理（ファイルの解凍などのこと）をメインスレッドから別スレッドに移動させることで、メインスレッド時間を150ミリ秒程度短縮できたことがわかります。 さらに、UIジャンクの発生やスクロール性能の低下を防ぐこともできます。
- [Sentryでもっと早くトリアージし、安らかな睡眠を](https://ichizoku.io/sentry/sleep-more-triage-faster-with-sentry/) - 開発者にとって、トリアージする月の1週間は、しばしば憂鬱でした。 トリアージとは、バグが報告されるたびに、手作業でログを分析し、関係するスタックトレースがあることを期待し、そして記憶を頼りに適切なチームへ連絡することでした。 トリアージをする開発者は、バグを適切なチームに連絡する必要があります。また、バグを調査するのに必要な情報を併せて報告する必要があります。 十分な情報がない場合、開発者はプロダクトを作成するよりも多くの時間をデバッグに費やすことになります。 現在、Sentryは400万人以上の開発者のトリアージとコンテキスト収集作業を最適化してくれます。しかし私たちは、さらに課題解決までの時間と課題解決率を向上するように努めています。 課題解決率および解決までの時間の改善 課題のトリアージは、4つのフェーズに分けることができます。 検知 通知 アサインメント 解決 ユーザーからのフィードバックやインタビューに基づく、通知やアサインメントの改善は、より良い結果をもたらすと考えました。 具体的な改善点として、以下の2点に着目しました。 サジェストでアサインメントの改善 関係ない通知によるノイズ低減 アサインメントの改善とアラートノイズの低減 簡単に課題を特定し、適切なチームや開発者にアサインすることができるようになります。 各課題について、担当者はSentry組織内のメンバーまたはチーム内で、最も詳しい情報を持っています。 Sentryは、3つのシグナルに基づいて、課題をサジェストします。 サスペクト（疑わしい）コミット - Sentryは、問題が起きたコードを最近変更した開発者を特定します。 所有権ルール - Sentryは、イシューのタグやコードなどに基づいて、適切にSentryチーム/メンバーを見つけるためのルールを評価します。 コードオーナー - SentryはGitHub/GitLabのCODEOWNERSファイルを解析し、コードに基づいて、イシューに適切なSentryチーム/メンバーを設定してくれます。 お客様からのフィードバックを目にして、ユーザーが確実かつ迅速に課題をアサイン、解決するのに役立っていることを知りました。 そして、より多くのユーザーがサジェストアサインを利用できるように、ここ数ヶ月で様々な機能を追加しました。 Git Blameを使ったサスペクトコミットについて サスペクトコミットは、Sentryでは問題の原因となっているファイルを最後に変更した人を表示するだけでした。 しかし、Git Blame API連携することで、Sentryは特定のコード行を変更した人、および問題の原因となったコードのプルリクエストを特定することができるようになりました。 また、イシューを自動的にコミット作成者にアサインすることができるようになりました。 この機能は、GitHubまたはGitLab連携を利用すれば、誰でも利用できます。 組織でこの機能を有効にする詳しい方法は、以下をお読みください。 コードマッピングを自動で設定 怪しいコミットを見つけるために、Sentryはエラーの原因となるファイルとリポジトリ内のソースコードファイルを結びつける必要があります。 しかし、これを正しく設定するのはなかなか難しく、ユーザーがこの設定を怠っていることに気づきました。 そのため、SentryのGitHub連携を利用するユーザーのために、この設定を自動化するようにしました。 Sentryは、Python、JavaScript、Node、Rubyなどのプラットフォームのソースコードと、エラーの原因となるコードを自動的にマッピングしてくれます。 この自動化されたセットアップにより、Sentryはさらに多くの怪しいコミットを見つけてくれるようになります。 不要なSentry通知を減らす Sentryでは、新しいプロジェクトを作成すると、デフォルトのイシューアラートルールが作成されます。 しかし、このルールはアサインできる人がいないイシューに対して、同じプロジェクトで作業しているチームメンバーに対して、通知を行う可能性があることに気づきました。 このアラートルールを使うことで、そのプロジェクトの全メンバーに迷惑をかけることなく、チームに通知できるように変更しました。 より良い結果を出すために ここでは、ユーザーがどのように問題解決をするか、その過程を紹介します。 Sentryはイシュー担当候補者がいる場合、アラートルールに従って、適切な開発者、チーム、Slackチャンネルに通知することができます。 これにより、開発者に不要な通知を減らし、チームにとって重要なイシューに集中してもらうことができます。 この利点は、イシューの担当候補者が増えれば増えるほど大きくなります。 さらに、Sentryがデフォルトのイシューアラートルールを変更したことで、問題を迅速にトリアージする能力を維持しながら、全体で不要な通知を33%削減することができました。
- [Sentryの新しい予算配分とスパイク保護で安心して複数のプロジェクトを管理](https://ichizoku.io/sentry/multiple-projects-on-sentry-new-spend-allocation-spike-protection/) - 本日、新しいSpend Allocation（予算配分）機能とSpike Protection（スパイク保護）のアップデートを発表します。 これにより、Sentryユーザーは、プロジェクトがどのようにイベントを消費するかをよりコントロールできるようになります。 私たちは、お客様がプロジェクトにSentryを簡単に追加できるように製品を開発してきました。 しかし、コミュニティからは、ノイズの多いイベントデータを扱うプロジェクトで、イベント枠を消費しすぎないようにするための方法がもっと欲しいという声を聞き続けていました。 そこで私たちは、Spend Allocation（予算配分）を構築し、Spike Protection（スパイク保護）を更新しました。 これにより、Sentryを大規模に利用する皆様は、イベント消費のレベルが異なる複数のプロジェクトやチームを簡単に管理できるようになりました。 なぜか プランによっては、毎月Sentryに送信できるイベント数に上限が設定されています。 その数を超えると、Sentryはあなたのイベントを削除し始めます。 この場合、アプリケーションの状態を把握することができなくなります。 インバウンドフィルタ、メトリックアラート、レートリミットなど、イベント消費を管理するためのツールを用意していますが、さらにコントロールを容易にしたいと考えました。 これにより、プロジェクトでイベントが大量に発生するような予期せぬ事態が発生しても、ペナルティを受けることがないようにできます。 Spend Allocation（予算配分）とSpike Protection（スパイク保護）の向上 予算配分は、予約エラー、トランザクション、添付ファイルに対して、プロジェクトごとに最小限のイベントの閾値を設定することができます。 この設定はリアルタイムで行うことができ、すべてのプロジェクトに公平な割り当てを行うことができます。 また、スパイク保護のアップデートは、その名の通り、イベント量の予期せぬ異常な急増からお客様を保護します。 Spike Protection（スパイク保護） - 何が変わったか 予約した容量を使いながら、月内に十分な視認性を確保できるようにしたい。 しかし、インシデントは起こります。 Sentryに送信されるイベントが急増することがあります。 このような場合、数時間または数分で月間クォータを使用することができます。 ユーザーからのフィードバックに基づき、イベントスパイクからお客様を保護するための従来のアプローチには、主に2つの問題があることが判明しました。 「調整」が早すぎる。 数時間以上続く正しく認識されたスパイクを「非スパイク」と誤判定することがあった。 スパイクの閾値が単純に高すぎる場合がある。 その結果、スパイクが捕捉されないことがある。 これらの要因により、スパイク保護機能の有効性が損なわれていました。そこで、スパイク保護の機能を以下のように改善し、ユーザーの保護を強化することにしました。 スパイクはプロジェクトごとに検出されるため、よりきめ細かい制御と可視化が可能です。 スパイクがトランザクションと添付ファイルを検出するようになりました。 アルゴリズムが更新され、イベントスパイクの検出がより正確になりました。 Stats（統計）ページで、プロジェクトごとのスパイク防止閾値を確認できるようになりました。 また、「スパイク保護のアップデートにより、イベント数上限を超えずに管理することができた」というお客様からの声もいただいています。 「スパイク保護は、データ移行の失敗から私たちを救ってくれました。一晩中、そして朝のピーク時まで、1つのスパイクが原因で、1日のイベント量が6000%増加しました。Sentryは、数時間以内にすべてのクォータを使い果たすことから私たちを救ってくれました。」-Vectare社テクノロジーディレクター、Alex Nathanail氏 フィードバックを共有し、改善の詳細を得るには、GitHubのディスカッションに参加してください。 3つのステップで、アカウントのスパイク保護をオンにします。 Organization（組織）の設定に移動する 左のナビバーにある「Spike Protection」をクリック プロジェクトのすべて（または一部）に対してSpike Protectionを有効にするかどうかを選択します。 なぜ、プロジェクトでスパイク保護を有効にしなければならないのか、という疑問があるかもしれません。 スパイクに関係なく、すべてのデータを確認したいお客様もいらっしゃいます。例えば、開発・テスト段階であれば、すべてのイベントを見ることができれば便利です。 Spend
- [SentryのUnity SDKの始め方 - その1](https://ichizoku.io/sentry/how-to-get-started-with-sentrys-unity-sdk-part-1/) - ユーザー体験とパフォーマンスは、どんなゲームでも最も重要な2つの指標です。どのようなプラットフォームでも、可能な限り最適な状態で動作するようにする必要があります。 理想を言えば、プレイヤーから「動かない」「壊れている」と怒られるのは避けたいところです。また、ゲーム内で発生した問題が、その関連情報とともに通知されることが求められます。 そこで、Sentryの出番です。 Sentryは、開発者がアプリケーションを監視して、重大なエラーやパフォーマンスの問題について把握するのに役立ちます。さらに、ゲーム内のエラーを追跡する重要なコンテキスト情報を提供するため、迅速に修正することができ、プレイヤーに満足してもらいやすくなります。 また、Unityと統合したSDKを提供することで、開発者がゲームを監視することを容易にしてくれます。 このシリーズでは、SentryのUnity SDKをセットアップして、ゲームのエラーやパフォーマンスの問題を監視する方法について説明します。 入門編 前提条件 はじめに、以下のものがインストールされていることを確認してください。 Unity Hub Unity Package Manager - Unity Hubをインストールした場合、Unity Package Managerもインストールされているはずです。 Sentryのアカウントを作成する すでにSentryのアカウントをお持ちの場合は、このステップをスキップすることができます。お持ちでない場合は、Sentryに移動し、無料のアカウントを作成してください。 アカウント作成後、このような画面が表示されます。 「Install Sentry」をクリックして進むと、新しい画面に遷移します。そこで、監視するプラットフォームとしてUnityを選択します。 最後に、「Create Project」をクリックして、Sentryプロジェクトを作成します。 Sentry SDKの設定 Sentry SDKは、Unityエディタ内で直接インストール、設定することができます。 Sentry SDKのインストール ここでは、Unity Package Manager経由でSDKをインストールすることをお勧めします。 プラスアイコンをクリックすると、パッケージマネージャがパッケージを取得するためのGitHubリポジトリURLを指定するオプションが表示されます。 https://github.com/getsentry/unity.git#0.27.0 インストールが完了すると、以下のようなアウトプットが表示されるはずです。 いくつかのバグをトリガーに、ゲームをクラッシュさせるデモシーンを含むサンプルがあり、オプションでインポートすることができます。 そして、SDKがイベントの送信先と関連するプロジェクトを知るためには、SentryプロジェクトのDSN（データソース名）を追加する必要があります。これは、[ツール] -> [Sentry]に移動して設定することができます。 [Sentry]をクリックすると、以下のようなセットアッププロンプトが表示されるはずです。 「Start Wizard」をクリックし、ウィザードを初期化します。すると、Sentryは自動的にブラウザタブを立ち上げ、既存のプロジェクトをエディタにインポートします。 もしプロジェクトが1つしかない場合、設定ウィザードは終了します。複数ある場合、Unityのゲームと関連づけるプロジェクトを選ぶプロンプトが表示されます。 最後に、同梱のサンプルを使用するか、次のようなスニペットで独自の例外を投げることで、Sentryが期待通りに動作しているかを確認することができます。 上図は、スニペットで発生した例外のエラーイベントを示しています。 SDKはこれを自動的にキャッチアップし、Sentryに送信し、issueとしてリストアップしてくれます。 最新リリースでの新機能 エラーのキャプチャーは、Sentryの多くの機能の1つに過ぎません。Sentryの最新版では、Unityのエラー診断と修正に役立つ多くのユーティリティが追加されました。 iOS、WebGLなどでもUnityをサポートするようになり、開発者はデスクトップアプリケーションの監視サポートも可能になりました。しかし、Sentryはそれだけにとどまりません。次のような機能も追加されました。 すべての対応プラットフォームに対応したシンボルの自動アップロード 以前は、画面のフリーズを検出する方法がありませんでしたが、メインスレッドが5秒以上フリーズした場合に、自動的にイベントを作成するようになりました。
- [アプリケーションのパフォーマンスを機能的に操作する方法](https://ichizoku.io/sentry/treat-performance-like-a-feature/) - 私は開発者として、そのアプリケーションがどのように動作すべきか、非常に強い関心を抱いています。 高速に動いた結果、何かを壊すことには興味がありません。正直、世界を変えることにも興味はありません。 快適で人間工学に基づいたソフトウェアを作ることに興味があります。そして、その対価としてお金を貰いたいという思いが強くあります。 私の会社「Buttondown」は、そんな思いから生まれました。Buttondownは、メールやニュースレターを送信するためのツールです。 市場にはこの手のツールはたくさんあります。しかし、Buttondownの強みは「ミニマリスト」であるということです。開発者にとって快適な体験を提供しています。 それはプログラムへのアクセス、アクセシビリティ、そしてパフォーマンスを優先しているためです。 しかし、アプリケーションの性能は時間とともに劣化する 開発者たちはみんな「高パフォーマンスを意識して開発しなければならない！」と考えています。 その意志は常に正しいです。一方で、簡単なことではないことも知っています。 新機能の立ち上げ時には、可能な限り慎重にリリースします。 APIルートごとのデータベース呼び出し回数や負荷テストなど、厳しいテストを実施しています。 誰かが非常に遅いエンドポイントについてバグレポートを提出した場合（あるいは、タイムアウトに関する例外が発生した場合）、私はできるだけ早く対応します。 これは簡単で、テストも可能です。 しかし、性能は時間の経過とともに、ゆっくりと、静かに低下していきます。 余分なループが一つ、最適化されていないデータベースを一回呼び出す……。 それが積み重なっていくように、目に見える小さな問題が積み重なっていくのです。 解約した顧客からメールを受け取って初めて、そのことに気づきます。 彼らは口を揃えて「UX（ユーザ体験）がよくない 」と言います。 クラッシュしないので「問題ない」ように思っていましたが、アプリは知らぬ間に悪化していました。 パフォーマンスを抽象的なものから実用的なものへと変化させる 私は長い間Sentryを、他のユーザーの皆さんと同様エラー処理と問題報告のために使っていました。 軽量なインターフェースと迅速なインストールプロセスにより、私は簡単に問題を処理し、優先順位をつけ、解決することができました。 私は、電子メールの受信箱と同じように、ソフトウェアの問題をクリーンな状態に保っています。 正直、パフォーマンス・モニタリングに注力しているときの私は、半信半疑でした。 たくさんのデータやダッシュボードが送られてきて、それを毎朝監視して見なければいけないからです。 非常に時間がかかる作業な上、結局人が見て判断しなければならないため、億劫に感じました。 しかしその疑念は、Sentryの提供する「パフォーマンスのためのクリアで簡素なアクション層」を理解した途端に消え去りました。 Sentryは、パフォーマンスに関する情報を分かりやすい内容で通知してくれます。 これまでは、分かりにくい折れ線グラフではないにしろ、答えを与える代わりに疑問を増やすだけのものが多かったのです。 代わりに、Sentryは明確で解決可能な問題を提示してくれました。 例えば、SentryはN+1エラー通知をしてくれるので、オンボーディングが重要なルートを高速化することができました。このようなことをPythonの2行で表現しました。 そして、Sentryはこの遅いDB操作にアラートしてくれました。 Sentryは、送信メールのレンダリングと送信を倍の速度で行う方法を教えてくれました。 Sentryは、プログラムのどこでどのトランザクションがパフォーマンスの問題を引き起こしているのかを正確に教えてくれました。 そのため、問題の根本原因を見つけるために、多くのダッシュボードやレポートの分析に時間を費やす必要はありませんでした。 Sentryを使ったおかげで、無駄な作業が減り、アプリのパフォーマンスに注力することができるようになります。 Sentryでは、コードエラーを処理するのと同じように、パフォーマンスの問題を処理することができるので大変便利でした。 開発者にとってパフォーマンスが重要な理由 多くの開発者たちは、アプリケーションのパフォーマンスを「あったらいいな」程度の機能として扱っています。 開発計画や製品ロードマップを作成しているとき、アプリのパフォーマンスについて十分に考えていない開発者がいるのです。これはよくわかります。 お客様の多くは、ページの読み込み時間の遅さやその他のパフォーマンスの問題を受け入れてくれると考えていることが多いからです。 一方で、新機能を搭載しなければ、お客様は不満を募らせるだろうと考えています。 ですから、パフォーマンスよりも新機能を優先することはよくあることです。 しかし、ユーザーや顧客は性能を気にしており、意外とすぐその変化に気がつきます。 しかし、実際にどう説明したらいいのかわからないこともあります。 Buttondownを使い始めてから数カ月後のあるお客様と電話をしたことがあります。 お客様：よく分からないんだけど、[加入者向け管理画面] が操作しやすくなったんですよね。いずれにせよ、UX（ユーザー体験）を向上させたのは素晴らしいです！ とはいえ、UXは1ピクセルも変わっていませんでした。 変わったのは、スピードとパフォーマンスです。Sentryのおかげで、5秒のフィードバックループを1秒に短縮することができました。Sentryを使えば、それは本当に簡単なことでした。 一部製品、一部プロセス： アプリケーションのパフォーマンスに関する考え方のオススメ パフォーマンス問題の優先順位付けと、改善を厳密に行うことに関心のあるエンジニアにお勧めのプロセスがあります。 これは、私がAmazonやStripeでエンジニアをしていたときに実際に効果が合った方法です。
- [アプリ開発時のReact Nativeのデバッグとエラートラッキングについて](https://ichizoku.io/sentry/react-native-debugging-and-error-tracking-during-app-development/) - 優れたソフトウェア開発者は、コードをデバッグする方法を知っています。 実際、ほとんどのソフトウェア開発者は新しいコードを書くことよりも、既存のコードをデバッグすることがほとんどです。ネイティブアプリの開発に関しては、開発中のデバッグとエラーの追跡は手間のかかる面倒な作業として有名です。 そこで今回は、React Nativeアプリケーションをデバッグし、実際にエラーを追跡する方法をご紹介していきます。 また、React Native Debuggerというツールを使ったエラー追跡についても触れていきたいと思います。 React Nativeにおけるデバッグの攻略法 開発中のコードを効率的にデバッグするためのデバッグ手法を知っておくと便利です。場合によっては、専用のデバッグツールを使用する方が効率的かもしれません。 まず、React Nativeアプリでコードをデバッグするために使用できる一般的なテクニックをご紹介します。 今回の記事を通して使用する、新しいExpoベースのReact Nativeプロジェクトを作成しました。次のコマンドを実行すると作成できます。 ここでは、簡単なReact Nativeのコードを紹介します。 これはボタンをレンダリングして関数を起動し、コンソールに文字列を表示する簡単なアプリケーションです。 デバッグ用端末を使う 新しいExpoプロジェクトを起動したり、React Nativeアプリを実行したりすると、開発モード中に操作した全てのログがターミナルに表示されます。 これは、expo startコマンドを実行する別のターミナルでも、IDEに統合されたターミナルでもかまいません。 例えば、VS Codeを使用した場合、ターミナルにはアプリで行ったすべてのログが表示されます。 これは、ローカルでアプリケーションを実行する方法と似ています。 ReactやReact Nativeなどのフレームワークを使ったクライアントサイドの開発では、このターミナルでクライアントサイドのログを取得し、開発モードのアプリのデバッグに利用でき、どんな操作をしたときにどんなエラーが起きたのか手軽に確認できます。 さて、それではわざと構文エラーを起こしてみましょう。 上記のセクションのレイアウト定義において、最後にセミコロンを追加してみます。するとターミナルには、このようなエラーが表示されます。 何のファイルで、どんなエラーが、どこの行で起きたのか……エラーメッセージとともに表示されていますね。 Expoターミナルは、すべてのログが最初に表示される場所です。 そのため、アプリをデバッグしているときはいつでも、そのターミナルを最初に見ることができます。 エキスポデバッガー Expo を React Native で使用する場合、ビルトイン（備え付け）のデバッガーを入手することができます。 このデバッガーは、エラーメッセージを表示し、エラーが表示されたコードの部分を明示し、コード内のエラー部分をマークしてくれます。 React Nativeプロジェクトを物理デバイスで実行している場合、アプリのコードを実行しているExpoアプリでエラーがどのように表示されるかは次のとおりです。 エラーを確認し、コードを簡単にデバッグすることができますが、この場合、スタックトレースはあまり役に立ちません。なぜなら、エミュレータでExpoを使っているのであれば、ログの方が綺麗に整形されているためです。 スタックトレースはありませんが、こちらの方が簡潔で必要な情報だけが表示されていますね。これで混乱を減らし、より早くエラーにたどり着くことができます。 ブラウザで見るReact開発ツール 先ほどはネイティブアプリでした。 続いては、Web上でフロントエンドアプリケーションをデバッグしてみましょう。 ブラウザを開くだけで、コンソールのログやエラー、レンダリングされたUI要素、関連するスタックトレースなど、あらゆるものが表示されます。 ありがたいことに、React NativeやExpoベースのプロジェクトでも同じことができます。React Developer Tools Chrome拡張をインストールするか、次のコマンドを使用してシステムにグローバルインストールするだけで導入可能です。 Expoアプリの端末で、「w」を押せばWeb上でアプリが開きます。 エラー情報が表示され、Webアプリと同じようにデバッグすることができます。 これは、先ほどデバッグターミナルで見たのと同じエラーで、Expoアプリとエミュレーター上でも同じですね。
- [コマンド1つでSentryをインストールする方法](https://ichizoku.io/sentry/install-sentry-with-a-single-command/) - 今回は、Sentryのインストールと初期設定を簡単に行う方法を共有いたします。 Next.jsを使用し、ターミナル（コマンドプロンプト）でコマンドを1つ実行するだけで、新しいSentryアカウントの設定や新しいSentry Next.jsプロジェクトの作成ができるようになります。 始めるのはとても簡単です。 sentry.io/signupにアクセスしてアカウントを作成したり、アプリ内からプロジェクトを作成したりすることももちろん可能です。 しかし現在は、面倒なクリック作業なども省略し、自分のリポジトリに移動してこのコマンドを実行するだけで必要な設定は完了します。 スクリプトが起動すると、ブラウザのタブを開いてサインアップフォームを表示します。 必要な情報を入力してターミナル（コマンドプロンプト）に戻ると、インストールが完了した旨の文言が表示されます。 この新しい方法では、next.config.jsファイルにSentry固有の要件が自動的に追加され、例外や遅延の問題の追跡を開始するために必要なファイルが作成されます。その内容を確認したい場合は『git status』を実行してご確認ください。 Sentryが無事導入できているか確認する場合は、ローカルでエラーをトリガーするか、変更をデプロイして例外や遅いトランザクションを実際に実行する必要があります。 それもSentry for Next.jsで、たった1つのコマンド（npx @sentry/wizard -s -i nextjs）で完了します。詳しくは、GitHub、Twitter、またはDiscordでご意見をお聞かせください。 Sentryは、アプリケーションコードの健全性を監視するために不可欠です。 エラートラッキングからパフォーマンスモニタリングまで、開発者はフロントエンドからバックエンドまで、アプリケーションをより明確に把握し、より迅速に解決し、継続的に学習することができます。 Sentryは、350万人以上の開発者と世界中の85,000以上の組織に愛され、Disney、Peloton、Cloudflare、Eventbrite、Slack、Supercell、Rockstar Gamesといった世界的有名企業の多くにコードレベルの監視機能を提供しています。 毎月、世界中で人気のサービスやアプリケーションから、数十億件の例外を処理し続けています。 IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。またご導入についての相談はこちらのフォームからお気軽にお問い合わせください。
- [Next.jsのよくあるエラーとその解決方法](https://ichizoku.io/sentry/common-errors-in-next-js-and-how-to-resolve-them/) - バグは、ソフトウェア開発において最も厄介なものの1つです。ほとんどの場合、すぐに解決することができますが、中には修正に数時間から数日かかるような恐ろしいバグもあります。 Next.jsは、現在の世界で最も人気のあるWeb開発フレームワークの1つですが、バグから逃れることはできません。 そこで、この記事では、さまざまなプラットフォームの開発者から報告された、最も一般的なNext.jsのエラーをいくつか紹介します。 なぜこのようなバグが発生するのか、そしてどのように解決するのかについて説明します。 ドキュメント/ウィンドウオブジェクトエラー Next.jsでよくあるエラーのひとつに、「document/windowが定義されていない」というエラーがあります。なぜ起こるのでしょうか？このエラーは、通常、インストールされたパッケージが、ページコンポーネントの中でブラウザのウィンドウオブジェクトに直接アクセスしようとしたときに発生します。 例えば、Next.jsアプリケーションにindex.jsのサンプルページがあり、以下のようにブラウザのlocalStorageにアクセスしようとすると、「document/windowが定義されていない」というエラーが発生します。 解決方法 このエラーを解決するにはいくつも方法があります。 ひとつは、ブラウザのウィンドウオブジェクトを必要とするコードブロックを実行するためにreactのuseEffect()フックを使用し、ページコンポーネントがマウントされているときにのみコードを実行するようにすることです。 もうひとつの方法は、ブラウザのウィンドウを必要とするコードを独立したコンポーネントに変換し、Next.jsの動的インポート機能を使ってページコンポーネントにインポートすることです。 Nextの動的インポートは、必要に応じてコンポーネントを遅延ロードまたは動的にロードするために使用される機能です。 さらに、ssrオプションを追加することで、使用時にサーバーレンダリングの有効・無効を設定することができます。※ちなみに「ssr」は、サーバーサイドレンダリングの意味があります。 ssrの値をfalseに設定するだけで、ブラウザのウィンドウやドキュメントに依存するコンポーネントや外部パッケージを読み込むことができるようになります。 下図のようにすることで、ページ内で動的に読み込むようになります。 ミドルウェアエラー ミドルウェアは、リクエストの完了前にコードが実行され、受信したリクエストに基づいて、ユーザーに送信するレスポンスを書き換え、リダイレクトしたり、ヘッダーを追加したりすることができます。 次の例は、Next.jsでミドルウェアを扱うときに遭遇する可能性のあるエラーの1つです。 Next.jsをカスタムサーバーで使用しており、設定でサーバーホストのURLを明示的に指定していない場合に発生するエラーです。 また、Nxのようなモノレポビルドシステムを使用している場合、このようなツールがバックグランドでカスタムサーバーを作成するため、このエラーが発生します。 ※「モノレポ」とは、複数のプロジェクトやアプリケーションのソースコード を一元管理することです。 解決方法 このエラーは、サーバー設定ファイルでホスト名を指定することで簡単に修正することができます。 Nxを使用している場合は、プロジェクト設定ファイル（project.js）のserveオプションを修正することで対応できます。つまり、プロジェクト設定ファイル（project.js）を次のように修正します。 ミドルウェアがトリガーされない まれにミドルウェアのコードが全くトリガーされない場合がありますが、それはミドルウェアのファイルが正しく配置されていない可能性があります。 解決方法 Next.jsの古いバージョンでは、ミドルウェアのファイルは/pagesディレクトリに_middleware.jsとして作成していました。 しかし、Next.jsの最新版では、このファイルをルートフォルダ、つまり/pagesディレクトリと同じ階層にmiddleware.jsとして保存する必要があります。 そのため、ファイル構造は次のようになります。 API/スラッグエラー Next.jsには、データ取得のためのAPIとしてgetStaticPathsとgetServerSidePropsがありますが、これらの使い方を誤るとエラーが発生することがあります。 そのうちのgetStaticProps APIでのエラーは、以下の通りです。 このエラーは、next.jsのSSG（Static Site Generation）機能を使ってサーバーサイドで動的ページをレンダリングしているときに、ページのコンポーネントにgetStaticPaths関数が定義されていない場合に発生します。 動的経路を使用するサーバーサイドレンダリング（SSR）または静的生成（SSG）ページを構築するためには、getStaticPaths関数を追加する必要があります。 解決方法 例えば、/pageName/[slug]がブログ記事に関する情報を表示するページとした場合、getStaticPaths関数でデータベースから利用可能なすべてのブログ記事のスラッグのリストを取得し、[slug]パラメータの値としてそれらを戻り値として返す必要があります。 また、Next.jsのデータ取得APIは、すべてページコンポーネントの内部でのみ使用でき、通常のコンポーネントの外部では動作しないことも特筆すべき点です。 モジュールエラー また、Next.jsでよくあるエラーは、次のような「モジュールが見つかりませんでした。'moduleName'を解決できない」というエラーです。 このエラーは、Next.jsではアクセスできないモジュールをインポートしているときに発生します。 例えば、fsモジュールのように、クライアント側で利用できないモジュールを、あなたやサードパーティのパッケージがアクセスしようすると発生します。 解決方法 このエラーを解決するには、Node.jsまたはサーバー関連のコードをすべてNext.jsのデータ取得API（getServerSideProps、getStaticPaths、getStaticProps）の内部に置くようにしてください。 Node.jsモジュールに明示的にアクセスしようとしているのではなく、インポートしたパッケージが原因でエラーが発生した場合は、Next.jsの設定ファイル（next.config.js）に、次のようにwebpackのエントリを追加する必要があります。 このコードでは、optionsオブジェクトのisServerプロパティをチェックして、現在のビルドがサーバーサイド用かクライアントサイド用かを判断しています。 ビルドがサーバーサイド用でない場合（つまりisServerがfalseの場合）、fsモジュールはwebpack設定のresolveセクションでフォールバックリストに追加されます。 これは、webpackがfsモジュールのimportに遭遇したとき、importを解決しようとせず、fsモジュールがアプリケーションにバンドルされないことを意味します。 もし、Node.jsのモジュールを使っていないのに「モジュールが見つかりません」というエラーが発生する場合は、モジュールが正しくインストールされ、インポートされていることを確認してください。 または、ファイル名やモジュール名が間違っている可能性もあるため、そちらについても確認するようにしましょう。 クロスオリジンエラー（Next
- [フルスタックの可視化で遅さの根本原因を探る](https://ichizoku.io/sentry/full-stack-visibility-to-find-the-root-cause-of-slow/) - ユーザーにとって素晴らしいアプリは、処理パフォーマンスが高いです。 しかし、ページロードに10秒かかるアプリは決して良いとはいえません。ユーザーは安定しかつ高速なアプリケーションを望んでます。Sentryは、コードのどこに異常があるのか通知します。 それだけでなく何が遅いのか、どう修正すればいいのかを詳細に出力します。 パフォーマンスモニタリングを最大限に活用 パフォーマンスモニタリングでは、複雑なケースが多々あります。 その理由のひとつは、開発者のエコシステムが複雑であるということです。私たち開発者は、一つのプロジェクトでアプリケーション全体を構築することはありません。 つまり、あるプロジェクトでの速度低下が、別のプロジェクトでのパフォーマンスのボトルネックになる可能性があるというわけです。 私たちのプロジェクトのエコシステムが複雑になると、スタック全体を監視する必要が生じます。 そこでSentryを使うと、速度低下を修正する方法についてのヒントを得ることができます。また、Sentryを使えば、原因となっているコードを特定することもできます。 例えば、フロントエンドのリクエストからバックエンドの遅いAPIコールまでのトレースを追うことが非常に簡単になります。 サービス間チャッター 一般的に、フロントエンド（クライアント）側はバックエンド側と通信します。 バックエンドは、DBサーバーやサードパーティサービスと連携します。 Eコマース会社を例に考えてみましょう。このストアのフロントエンドは、Webサイトとモバイルアプリを保持しています。どちらもAPI Gatewayを介して、情報をインベントリーサービスにルーティングします。そして、最終的に決済サービスに情報を転送します。 クライアント（フロントエンド）から始まり、決済サービスまでのトレース内の各トランザクションは、連鎖的に影響を与える可能性のある呼び出しの連なりと言えます。 しかし、すべてのサービスやプロジェクトにテレメトリー（処理の監視データ、計測データのこと）がなければ、開発チームはエンドツーエンドのトレースを完全に可視化することはできません。 以下のケースを考えてみましょう。 例えば、Webのメトリクスが良好であるとします。Web開発チームは満足しています。 しかし、インベントリーサービスやチェックアウトフローの処理に長い時間がかかっている可能性が出てきました。 このとき、何が問題なのか、どこに原因があるのか特定できず、チーム内で混乱が生じるリスクが発生します。 原因を特定するには、各サービスがどのように通信しているかを理解する必要があります。 あるサービスが他のサービスの応答を待っていると仮定します。 であれば、アプリケーションのパフォーマンスはもちろん低下します。 すると、ユーザーはページロードに長い時間待たされることになります。 …このように、Sentryを使用するとフロントエンドとバックエンドを横断的に分析することが可能になります。あるプロジェクトの操作が、別のプロジェクトの操作をどのように遅くしているかを見ることができます。 プロジェクト横断的な視認性 さて、それらの機能はどのように動作するのでしょうか。 SentryのSDKは、お客様のコードの変更を監視し、スループット、Apdex、User Misery、トランザクション期間などのメトリクスを測定します。 複数のシステムに渡って、エラーの影響度合いを表示することができます。 また、Sentryはトランザクションとスパンからなる分散トレーシングを取得します。 これらのトランザクションとスパンは、個々のサービスと、それらのサービス内の個々のオペレーションを測定します。 トランザクションは、ある操作をサポートするために呼び出されるサービスの単一のインスタンスを表します。 測定・追跡したい（例：ページロード、ページナビゲーション、APIコール、非同期タスク）個々のオペレーションはスパンと呼ばれます。パフォーマンスの悪いスパンは、レイテンシーに影響を与える可能性があります。 その結果、UX（ユーザーエクスペリエンス）が低下したり、スループットに問題が生じたりする可能性があります。 これはアクセスがピーク時に達した時、サイトに悪影響を及ぼすリスクがあります。 Sentryの分散トレース機能により、あるプロジェクトの遅いスパンが、他のプロジェクトのトランザクションをどのように妨げているかを確認することができます。 分散トレースでは、コードのどこで、何が遅いかを教えてくれます。 また確認に手間のかかるサードパーティの依存関係も特定することができます。 分散トレースは、Trace ViewとTrace Navigatorのバックボーンとなっています。 トレースビューとトレースナビゲータは、プロジェクト間でスパンがどのように相互作用しているかを示すミニマップを出力します。 遅いものを見つける さて、先ほどのEコマースの例に話を戻します。 フロントエンドはReactで構築され、バックエンドはPythonのFlaskフレームワークを使うことがわかりました。 ある日、商品ページの読み込みが遅いことに気づきます。 SentryのPerformanceタブに行くと、/productsページのp50が7秒以上になっていることがわかります（一目でわかります！）。 ページの読み込み時間が遅いのは、実際に開発中のReactプロジェクトにあります。 しかし、その原因は一体どこにあるのでしょうか？ それでは、実際に探してみましょう。 1. Transaction Summary
- [Sentryでクラウドサービスに関するコンテキストを増やす方法](https://ichizoku.io/sentry/get-more-context-about-your-cloud-services-with-sentry/) - Sentryを使用してSentryを構築している、とあるSentry社員がいました。 彼は、ある課題に関する特定のサービスが、当社のクラウド環境のどこでホストされているかを知りたいと考えていました。 これをきっかけにSentryでは、Python SDKに新しいクラウドデータ収集機能を作成し、Sentry社員だけでなく誰でも利用できるようにしました。 この機能の目的は、クラウドでホストされているサービスから問題が発生したときに、そのサービスに関する特定の情報を調べることで、根本原因を突き止め、より速く修正し、製品版のリリースを可能にすることです。 Python SDKは、AWS EC2およびGCP GCEのリージョンとホスティング環境に関する基本情報を取得するようになりました。 これによって、クラウドホスティングの設定に関連する問題や複雑さを迅速に特定することができるようになり、作業時間を大幅に減らすことができます。 この新しいコンテキストは、クラウド技術のベテランであろうと、未経験者であろうと、クラウドに分散されたサービスについて十分な情報に基づいた意思決定をするために必要な情報を提供します。 ぜひ実際に使っていただき、GitHubのディスカッションで感想を聞かせてください。 どのようにこれをリリースしたのか、舞台裏をご紹介しましょう。 私たちは、OpenTelemetry SDKsからインスピレーションを得ました。OTelは、テレメトリーデータとSDKを含むツールのなかで、誰でも使える標準的なものとして有名です。 やはり、意見や感想をもらうことは私たちSentry開発者としても学びになります。私たちのOTelの開発業務についてもっと知りたい方は、最近のブログ記事をご覧ください。 または、ぜひここでご意見をください！ IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。またご導入についての相談はこちらのフォームからお気軽にお問い合わせください。
- [プロファイリング入門101：なぜプロファイリングなのか？](https://ichizoku.io/sentry/why-profiling/) - プロファイリングについて、3回に分けてご紹介する「プロファイリング入門」。今回は第2回目です！ 第1回目「プロファイリングとは何か？」はこちらからご覧ください。 第1部： プロファイリングとは何か？ 第2部：なぜプロファイリングを使うのか？（当記事） 第3部：プロファイリングツールとその使い方（近日公開予定） アプリ開発の成功には、素晴らしいパフォーマンスが重要であることはご存じかと思います。 パフォーマンスを改善するためのツールはたくさんあります。 最新のプロファイリングツールを使ってプロファイリングを行うことは、アプリのパフォーマンスを理解するために最も簡単で効果的な方法の一つといえます。 プロファイリングツールは、1970年代から開発者が遅いコードを修正するのに役立ってきました。 最近のプロファイリングツールは、より洗練され、より使いやすくなっています。そして、サービス終了までのあいだ継続的に稼働させることができます。 例えば、遅いコードの経路を示す有用な可視化データを自動的に作成する機能があります。また、他のパフォーマンスツールとの統合や連携も可能です。 シリーズの第1回目と同様に、この記事のほとんどの例は、フロントエンドとバックエンドの開発に関するものです。 しかし実際には、プロファイリングツールはほとんどのコードに適応し、パフォーマンス向上に役立てることができます。 なぜプロダクションでプロファイルするのか？ PythonのcProfileやGoのpprofのように、多くの言語にはプロファイリングツールが組み込まれています。 これらのツールはとても便利で、何十年も前から使われています。 しかし、使い続けていると次第に使いにくい場面も出てくるのは事実です。そんな時は、追加の可視化ツールを必要とします。 これらのツールは、あなたのローカル環境上で動作することだけを想定しています。 ローカルプロファイリングは限定的 内蔵のプロファイラを使えば、コードの特定の部分について詳細なベンチマークを取得することができます。それにより課題のある箇所を見つけるのに役立ちます。 しかし、大規模なシステムでパフォーマンスの問題を発見するためには、最適の策ではありません。 ローカルプロファイラを使用すると、多くのオーバーヘッドがコードに追加されます。（一般的には200%以上追加されます） プロファイリングを使うということは、コードの性能を気にしているはずです。 それにも関わらず、コードを2倍以上遅くしているのは矛盾します。 そして、すべてのプロファイラで、追加されるパフォーマンスオーバーヘッドの量は、関数呼び出しの間で一定ではありません。 つまり、プロファイリングで得られるCPU処理時間は、正確ではない結果となります。これでは正確に解析できないため、プロファイリングを実行する意味がありません。 一般的に、ローカルでのプロファイリングだけでは、ユーザー体験を明確に把握することはできません。 本番環境での速度低下の原因を、ローカル環境で再現するのは非常に困難であるためです。 ご存知のように、開発マシンでのパフォーマンスは、コードが本番稼働しているときと常に同じとは限りません。 したがって、開発環境のローカルプロファイリングで問題を発見し、実際に修正するのは非常に困難であるということがわかります。 プロダクションにおける最新のプロファイリング 最終的には、本番環境でパフォーマンスを測定することが、システムのパフォーマンスを正確に把握する唯一の方法となります。 幸いなことに、ローカルのプロファイリングツールが作られて以来、プロファイリング技術は大きく進化してきました。 最新のサンプリングプロファイラは、現在、本番環境で実行できるほど進化しています。（決定論的プロファイラとサンプリングプロファイラの比較は第1回目で詳しく説明しています） それは、パフォーマンスのオーバーヘッドを抑えて実行できるようになったためです。 また、コードのパフォーマンスの詳細な情報を可視化して提供してくれます。 それはローカル環境上のプロファイリングと遜色ない、有用で十分な解析結果を出力してくれます。 例えば、Sentryのプロファイリングツールは、10%以下のオーバーヘッドを目標として実行しています。 さらに、最新のプロファイリングツールは、すべてのユーザーセッションのデータを取得するように設計されています。 つまり、コードが本番環境でどのように動作しているかを包括的に把握することができるのです。 プロファイリングはと比較してどうなのでしょうか？ 他のツールを使って、本番環境からパフォーマンスデータを取得している方もいらっしゃると思います。 『なぜプロファイリングをセットアップする必要があるのか』という疑問もあるでしょう。パフォーマンスを監視する方法を変更するのは、決して簡単な作業ではありません。 しかし幸いなことに、プロファイリングはパフォーマンスを測定するための他の戦略とともに機能します。 また、設定もそれほど難しくなく、得られるメリットも大きいです。 最も大きなメリットは、プロファイリングデータが関数またはコードレベルの粒度を提供することです。これにより、開発者はパフォーマンスの問題を発見し、修正することが非常に簡単になります。 システムメトリクス ページロード時間、CPU使用率など、その他の事前設定されたメトリクスは、本番環境で稼働しているアプリのパフォーマンスを把握するために使用されます。 また、効果的でオーバーヘッドの少ない方法を提供し続けます。 メトリクスは、パフォーマンスの問題があることを知らせるには最適ですが、その原因まで突き止めることはできません。 メトリクスは非常に低いオーバーヘッドで動作するので、使わない理由はありません。しかし、最近のツールと比較すると、その有用性は限定的となります。 ロギング ロギングは、パフォーマンスを含め、さまざまな方法でシステムの健全性を把握するのに便利です。 しかし、ロギングからパフォーマンスデータを取得するには、多くの手間がかかります。
- [PythonとNode.jsのプロファイリングβ版](https://ichizoku.io/sentry/profiling-beta-for-python-and-node-js/) - 数ヶ月前、PythonとNode.js SDKのユーザー向けにプロファイリングのアルファ版がリリースされましたが、本日、PythonとNode.js向けのプロファイリングをベータ版に移行しました。 プロファイリングはベータ版の間、無料で使用できます。正式リリースが近づいたら、また更新情報をお届けします。 プロファイリングは、コードのパフォーマンスボトルネックを発見するのに役立つ重要なツールです。 Sentryのプロファイラでは、実行速度の遅いクエリのコードのファイル/行番号まで正確に把握することができます。 特定の関数の実行に時間がかかっている理由を即座に把握し、コード内の関数を最適化することでアプリケーションのパフォーマンスを向上させることができます。 最新のリリースでは、プロファイリング製品にいくつかの改良を加えています。 Pythonのアップデート Geventのサポート：SentryプロファイリングがPythonのgeventをサポートするようになりました。geventライブラリ（Gunicorn WSGI HTTPサーバとよくペアになっている）を使用しているすべてのユーザーに影響があり、以前はデータを取得できなかったgeventコルーチン（リクエスト処理コード）内で実行されているコードを確認できるようになりました。 WSGIリクエストだけでなく、すべてのトランザクションのプロファイリングをサポート：以前は、SentryはWSGIリクエストのみをプロファイルすることができました。現在では、すべてのトランザクション（手動で開始したものも含む）がプロファイルされ、この動作はプロファイルをサポートする他のSDKとの一貫性を担保します。 これらの機能アップデートはいずれも追加設定を必要とせず、SDKをアップデートすればすぐに動作し、プロファイリングのインサイトを確認することができます。 Node.jsのアップデート Node.js 18および19のサポート：SentryプロファイリングがNode.jsの最新バージョン（v18とv19）に対応しました。 Google Cloud Runに対応：Google Cloud Run環境にデプロイした際に、Node.jsプロファイラがセグメンテーションしてしまうバグを修正しました。これで、Google Cloud Runにデプロイした際に、本番環境で正常にプロファイリングできるようになります。 このパッケージは、コンパイル済みのバイナリとともに提供されるため、ソースからのビルドはあまり必要ありません。 製品の機能改善 SDKのサポート強化に加え、いくつかの新しいプロファイリング機能のアップデートにより、ユーザー体験（UX）を向上させました。Sentryプロファイリングでは、ユーザーは以下のことができるようになりました。 フレイムチャートの関数からGitHubのコードへのリンク ソースマッピングが設定されている場合、フレイムチャートの関数フレームを右クリックすると、GitHubのその関数のコードに遷移します。これにより、長時間実行される関数のソースコードに直接移動できるため、パフォーマンス問題の修正プログラムを素早く書くことができ、トラブルシューティングの時間を短縮することができます。 これは、ソースコード管理が設定されているNode.jsとPythonのプロジェクトで機能します。 トランザクションの処理時間をフレイムチャート上で可視化する トランザクションが関連付けられたすべてのプロファイルは、トランザクションからの期間をフレームチャート上に直接出力します。これにより、トランザクションとプロファイルを行き来することなく、特定の処理で実行されたコードを1つの統一された画面で簡単に把握することができます。 期間から対応するプロファイルに移動する Sentryのトレースを有効にしている場合、トランザクションイベントの詳細ページに移動し、ウォーターフォールビューから期間を選択し、「View Profile」ボタンをクリックすると、その期間に発生するプロファイルの部分に移動することができます。これにより、パフォーマンス問題を抽象的な上層〜詳細な下層にまで目的に合った粒度で分析することができます。 結論 Sentryのプロファイリング機能を繰り返し強化する中で、初期の多くのお客様から、Sentryパフォーマンスとプロファイリングは、パフォーマンスワークフローにおいて、しばしばうまく組み合わせて利用できるという話を聞きます。 Sentryパフォーマンスは、お客様がサービス全体をトレースし、動作の遅いデータベースクエリや外部呼び出しを特定することを可能にします。例えば、プロファイリングのお客様の一人は次のように述べています。 Sentryパフォーマンスで最も遅いAPIコールを確認することは非常に有用です。私たちはパフォーマンスの最適化を行い、p50とp95の劇的な改善を確認しました。" - Aunty Grace（オーストラリアのヘルスケア企業）の開発者、シェーン・ホルコム氏 プロファイリングはトレースを補完するもので、CPU消費を抑えるためにコードのどの部分を最適化する必要があるかについて、ファイルや行レベルで詳細に知らせてくれます。パフォーマンスとプロファイリングを併用することで、プロファイルとトランザクションを関連付け、遅いリクエストの根本的原因を特定し、迅速に修正することができます。 数回のクリックでプロファイリングを始められます。まず、パフォーマンスの計測が完了していることを確認してください（わずか5行のコードで完了します）。 P.S. プロファイラを聞いたことがない、プロファイリングとロギングやトレースとの比較を知りたい、あるいは単に興味があるという方は、プロファイリングとは何か、なぜ運用中のアプリケーションをプロファイリングする必要があるのかを説明するブログシリーズ「Profiling 101」をご覧ください。 Pythonのプロファイリングの例やNodeのプロファイリングの例については、こちらをご覧ください。また、GitHub、Discord、またはメール（profiling@sentry.io）にて、ご意見・ご感想をお待ちしています。 Sentryは、アプリケーションコードの健全性を監視するために不可欠です。エラートラッキングからパフォーマンスモニタリングまで、開発者は、フロントエンドからバックエンドまで、アプリケーションをより明確に把握し、より迅速に解決し、継続的に学習することができます。Sentryは、世界中の350万人以上の開発者と85,000以上の組織に愛され、Disney、Peloton、Cloudflare、Eventbrite、Slack、Supercell、Rockstar Gamesといった世界で最も有名な企業の多くにコードレベルの観測機能を提供しています。 毎月、世界中で人気のサービスやアプリケーションから、数十億件の例外を処理し続けています。 IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。またご導入についての相談はこちらのフォームからお気軽にお問い合わせください。
- [Jetpack Composeのはじめかた](https://ichizoku.io/sentry/jetpack-compose/) - 先日、宣言型UIへの移行方法に関する記事を書きました。 Androidアプリ開発も、「Jetpack Compose」で最近のトレンドである宣言的実装に加わりつつあります。 Androidスマホで動作するアプリを、ネイティブAndroidアプリと呼びます。 これを制作する際に、もっと効率化しようと生み出されたのが「Jetpack Compose」です。 Googleによって制作されたこの新しい宣言型UIツールキットが、急速に普及しています。 実際、昨年の「Android Dev Summit」で発表されたように、Androidアプリで人気上位1,000のアプリのうち、160が既にJetpack Composeを使用しています。 従来のXML Viewとは対照的に、Jetpack Composeでは、UIがどのように見え、どのように振る舞うべきかを記述する「Composable Function」を使用して、UIを構築できることが特徴です。 Jetpack Composeを使用する主な利点は、より簡潔で理解しやすいUIコードを書くことができることです。 これは、保守性の向上と開発期間の短縮につながります。 Jetpack Composeを使用する主なデメリットは、まだ生まれて間もない新しいライブラリであるため、使用できるエコシステム（OSバージョン）が限られていることです。 つまり、従来のXML Viewによる開発で使えていたライブラリやツール、リソースの数が、Jetpack Composeだと比較的少ないということです。 それでも、Jetpack Composeを学ぶことは、大きな意味を持ち、挑戦に値すると私たちは信じています。 ここでは、あなたが始めるにあたり、私たちが役に立つと思ったいくつかのヒントを紹介します。 Jetpack Composeの使用開始方法 Jetpack Composeで作業するための推奨IDEは、Android Studioです。 Android Studioをダウンロードしインストールすると、新しいプロジェクトを作成するオプションが表示されます。 新しいJetpack Composeアプリケーションを作成するには、空のComposeアクティビティ（Material v2を使用）、または空のComposeアクティビティ（Material3）（昨年の時点でバージョン1.0であるMaterial v3を使用）のいずれかを選択する必要があります。 このスクリーンショットの右上に、両方のオプションが表示されています。 これは、最も手軽にJetpack Composeを始める方法であるといえます。少し試したいという場合におすすめです。 既存のAndroidアプリケーションにJetpack Composeを有効にしたい場合は、次のように修正を行いましょう。 1. アプリのbuild.gradleファイルに、以下のビルド設定を追加します。 2. Compose BOM（部品表）とComposeの依存関係のサブセットを依存関係に追加します。 Jetpack ComposeのUIはどのように構築されているのでしょうか？ Jetpack Composeでは、ビュー（レイアウト要素）の階層を定義するためにComposablesを使用しています。 そして追加されたComposablesに視覚的な外観や動作の変更を適用するためにmodifierを使用します。 コンポーザブルファンクション Composable関数（または単にComposableといいます）は、「@Composable」でアノテーションするだけで、Composable関数の中に入れ子構造でUIを定義することができます。 UIを定義するために、Composableの階層を返す普通のKotlin関数でもあります。
- [コードマッピングとその重要性とは？](https://ichizoku.io/sentry/code-mappings-and-why-they-matter/) - コードマッピングは、エラーとリポジトリ内のソースコードを結びつけるものです。エラーは、リポジトリのツリー構造とは異なる経路を持つことがあります。 エラーまでの正確なパスを決定するためには、コードマッピングが必要不可欠です。 このコードマッピングは、エラーまでのパスとリポジトリURLとの組み合わせによって成立します。 Sentryは、コードマッピングを使用して、課題の詳細ページでコンテキストと役立つデータを発行します。 例えば、以下のようなものです。 スタックトレース連動 Issue Detailsページから直接リポジトリ内のソースコードに移動することができます 課題所有権とコード所有者 パスルールを定義するか、リポジトリにあるコードの所有者ファイルを使用することで、課題（Issue）をチームに割り当てることができます。 疑わしいコミット エラーが発生した際、どのプログラムのどの行で起きたのか、また誰が触ったかを分析することができます。 変更を加えた人を担当者としてアサインし、問題を解決することができます。 これらの機能によって、実装中に起きたエラーなどの解決にかかる時間を短縮することができます。また、エラー原因のコードの所有者（修正者）を迅速に特定することができます。 これまでは、コードマッピングを設定するためのプロセスが複雑であることが課題視されてきました。そして、使いこなすことが難しいという課題を多くの開発者は以前から抱えてきました。そんな課題を解消するため、私たちは、そのプロセスを簡略化しました。 また、コードマッピングを自動化する機能も新たに追加しました。コードマッピングの自動化に成功したプロセスについては、これからご説明します。また、どのように役立つのか、そして今後のリリース計画についてもぜひご覧ください。 現在、自動コードマッピングは、GitHubインテグレーションをインストールしているお客様（Teamプラン以上）にのみ提供されています。 また、限られた言語でのみ利用可能です。 技術的な課題 スタックトレースに対してコードマッピングを自動生成する機能を、私たちは数日で開発しました。しかし、『大規模プロジェクトで実行させる』という機能が最も大きな課題として私たちを悩ませました。 Sentryは、数万を超える組織やプロジェクトにご利用いただいています。そして、彼らが書いた多くのコードが格納される数多くのリポジトリを保有しています。私たちは、1時間に何十万通りにも及ぶさまざまなイシュー（フィードバックやバグ）を受け取ります。 受け取ったイシューごとに処理を実行しなければなりませんが、この実行にかかるコストは高くつきます。ですので、より経済的でスケーラブル（拡張性がある）設計が必要になりました。 GitHubが設定した利用制限を守らなければならないため、GitHubのAPIをどのように使うかについて検討を積み重ねました。コードマッピングの導出は、GitHubのAPIを使用する唯一の機能ではありません。 そのため、キャッシュを効率的かつ適切に使う必要がありました。これは、他のSentryの機能（GitHubからコミットを取得するなど）の動作に影響を与えるため、とても重要な検討事項です。 GitHubのAPIを利用したコードマッピングの導出 スタックトレースに記載されているファイルを検索するためには、以下の2つの情報が必要です。 ソースコードが存在するリポジトリ ファイルパスと一致させるために必要な変換工程 例えば、このスタックトレースフレーム sentry/shared_integrations/client/base.pyは、Github の以下のソースファイルに接続しているとします。src/sentry/shared_integrations/client/base.py ソースコードがどこにあるのかを判断するためには、顧客の組織内のすべてのファイルとすべてのリポジトリのリストが必要です。リポジトリごとにファイルのツリーを作成するには、GitHub のふたつの API を使います。それは『組織リポジトリの一覧取得』APIと『ツリーの取得』API です。 1つ目の『組織リポジトリの一覧取得』APIは、その組織に関連するすべてのリポジトリをフェッチします。 次にこれを使用して、各リポジトリのツリーをフェッチします。 2つ目の『ツリーの取得』API は、与えられたリポジトリのすべてのディレクトリとファイルを表すリポジトリツリーを返します。このAPIは 1回の呼び出しで、あるリポジトリのすべてのファイルにアクセスできるため、非常に便利です。 レスポンスからツリー情報を抜き出し、ソースコードファイルでないものはすべて破棄します。エラーを発生させる可能性のあるファイルのみに絞り込むためです。 すべてのリポジトリのツリーを入手したら、スタックトレースがあるプロジェクトの課題を選んで処理します。すべてのリポジトリの中で一致するファイルを見つけるために、すべてのフレームファイルのパスを探します。 その際、リポジトリ内の任意の深さで正確なパスを検索します（例えば、src/foo/bar.py と project/src/foo/bar.py は sentry/foo/bar.py にマッチする、など）。 ここで、Githubの検索APIを使うこともできたのですが『1時間に25リクエストまで』というAPI利用制限がありました。
- [SentryファミリーにCodecovが参画：コードカバレッジとアプリケーション監視の融合](https://ichizoku.io/sentry/bringing-codecov-into-the-sentry-family-where-code-coverage-meets-application-monitoring/) - 本日、CodecovはSentryファミリーに加わりました。Codecovは、2014年にコードカバレッジレポートツールとして始まり、それ以来Codecovはテスト分析分野のマーケットリーダーとして成長してきました。Codecovは、20以上のテストフレームワークでカバレッジを実用的なものにします。これまで100万人以上のソフトウェア開発者たちのテスト、カバレッジ、コードの信頼性に対するアプローチを改善するのに役立っています。 テスト分析がアプリケーションの監視とどう関係するのでしょうか。それを理解するためには、まず、コードが適切にテストされないとどうなるかに着目する必要があります。コードを正しくテストせず（あるいは全くテストせず）、モニタリングに失敗したときに何が起こるのかに注目しなければなりません。ソフトウェアの停止が起こり、アプリケーションのパフォーマンスの問題が発生します。そしてそれは、顧客にとって劣悪な体験を生み出すことになるのです。 ソフトウェアの停止は、問題の分析から始まります。実際に何が問題を引き起こしているのでしょうか？パフォーマンスの問題やその他のシグナルをつなぎ合わせて、根本原因を診断します。これがSentryの存在理由です。Sentryは、開発者の生産性を向上させるために存在します。私たちは、問題をできるだけ早く特定することに注力します。 そして、開発者たちがその問題を素早く解決するための正しい情報とツールを手に入れることができるようにします。多くの開発者はこれをMTTR（平均復旧時間）と呼んでいます。Sentryは、問題が発生したときに開発者がそれを認識するのを助け、根本原因を示し、開発者らが臨めば問題をすぐに解決できるようにします。ソフトウェアチームがインシデント管理ではなく、本来の研究開発に割く時間を最大化できるよう、私たちは支援します。 ソフトウェア開発ライフサイクルにおけるリリース前の段階において、ソフトウェアテストは高品質のコードを確実に開発するために最も重要です。Codecovは、より健全で高品質なコードを出荷することが、リスクの低減、より良いユーザー体験、そして開発者の生産性の向上につながると考えています。 開発者の生産性を向上させるためのCodecovのアプローチは、コードが出荷される前のコードカバレッジと自動テストに重点を置いています。Sentryと同様、Codecovは常に開発者がコードの問題を認識するのを助け、望めばそれを解決できるように選択肢を与えることに重点を置いてきました。Codecovがソフトウェア開発ライフサイクルのプリリリース側に焦点を当てているとしても、SentryとCodecovの使命は同じです。両社とも、世界最高の開発者ツールを作り、開発者ファーストの考え方にこだわり続けたいと考えています。 SentryがCodecovと話を始めたとき、何万もの組織と協力してきたその道程について聞きました。つまり、それまでのコードカバレッジの概念は多くの開発者が使う便利な指標でありながらその指標の本来の意味については、ほとんど合意が得られていませんでした。 100％のカバレッジが目標なのでしょうか？完全にカバーされたコードベースが、なぜまだ壊れることがあるのでしょうか？100%がゴールでない場合、どの程度のテストが必要でしょうか？「ハッカーニュース コードカバレッジ」で検索して議論を読んでみてください。 これらの議論は、答えが必要な質問が何かを明らかにしています。開発者はどのようにコードをテストするでしょうか？そのテストはどの程度弾力性がありますか？なぜコードベースの特定の部分をテストするのでしょうか？顧客やユーザーに対するリスクは？コードのコミットごとにすべてのテストを実行する必要があるのでしょうか？これらの質問は、Codecovが豊富な機能と今後のロードマップを確立するためのインスピレーションとなり、そして今後はSentryに統合されます。 Sentryのミッションは常に、ダッシュボードやツールの提供だけでなく、背景情報や洞察を通じて、開発者が高品質のコードを出荷できるようにすることです。Codecovチームは、この私たちのただ一つの焦点を共有しています。Codecovは、開発サイクルの早い段階で、アプリケーションのコード品質について、より包括的な洞察を開発者に提供します。 Codecovは、Sentryと同様に、開発者の既存のソフトウェア開発のワークフロー内で動作します。Codecovは、プラットフォーム、言語、CI/CDツールに関係なく、コードの品質に関するフィードバック、洞察、およびオーナーシップを提供します。今回の買収により、Sentryの顧客は、デプロイ前とデプロイ後の両方で、コード品質に関する洞察と保護から利益を得ることができます。 Sentryは、アプリケーションコードの健全性を監視するために不可欠なツールです。エラー追跡からパフォーマンス監視まで、開発者は、フロントエンドからバックエンドまで、アプリケーションをより明確に把握し、より迅速に解決し、継続的に学習することができます。 Sentryは、世界中の350万人以上の開発者と85,000以上の組織に愛され、Disney、Peloton、Cloudflare、Eventbrite、Slack、Supercell、Rockstar Gamesといった世界で最も有名な企業の多くにコードレベルの観察機能を提供しています。 毎月、インターネット上で最も人気のある製品から数十億の例外処理を実行しています。 IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。またご導入についての相談はこちらのフォームからお気軽にお問い合わせください。
- [プロファイリング入門101：プロファイリングとは何か？](https://ichizoku.io/sentry/profiling-101-what-is-profiling/) - アプリケーションの性能は重要です。パフォーマンスの高いアプリケーションは、優れたユーザーエクスペリエンスを保証し、大切な顧客を維持します。開発者は、パフォーマンス目標を達成するための適切なツールを使う必要があります。顧客から不満が出る前に、適切なツールを用意していなければならないのです。 良好なパフォーマンスを確保するための開発者のツールボックスの中で最も優れたツールの一つがプロファイリングです。本番のコードがどこで遅くなるかを正確に予測するのは非常に困難です。プロファイリングツールを使えば、コードの中で遅くなっている行を正確に示すことができます。また、特定の最適化を行い、テストすることも可能です。 この三回シリーズでは、プロファイリングとは何か、なぜ本番環境でコードをプロファイリングする必要があるのか、プロファイリングのための人気のツールを紹介します。 第1部 プロファイリングとは？プロファイリングとは何か？（この記事です！） 第2部：なぜプロファイリングなのか？ 第3部：プロファイリングツールとその使い方（近日公開予定） プロファイリングとは何か？ プロファイリングツールは何十年も前からありますす。 新しいものではありません。プロファイリングとは、プログラムのリソース使用状況のスナップショットを取得する方法です。これをプロファイルと呼びます。そして、そのスナップショットをコードベースに結びつけます。これで、コードの各行ごとのリソースの使用状況を把握することができます。 プロファイリングは動的解析の一種です。コードを実行しながら測定します。プロファイリングによって、ローカルでも本番でも、コードがどのように実行されているかを正確に把握することができます。コードがデータベースや他のサービスとどのように相互作用しているかを確認することができます。 プロファイリングは分散トレーシングとどう違うのか？ まず、プロファイリングとトレーシングの違いについて説明します。 トレーシングは、パフォーマンスを監視するために一般的に使用されるまた別のツールです。トレーシングは、リクエストの流れやタイミングを、システムを通過する際に追跡します。これは、そのシステムのパフォーマンスを理解し、ボトルネックを特定するのに役立ちます。トレースは、プログラムの実行中に発生したイベントのログです。分散型トレーシングでは、バックエンドとフロントエンドを横断して追跡するなど、分散型システムでトレースを作成します。 フロントエンドからバックエンドへのリクエストをトレーシングすることで、どのサービスが関与し、どれくらいの時間がかかっているかを把握することができます。多くの場合、外部サービスやデータベースがアプリケーションの遅延を引き起こす最大の原因となっています。 トレーシングは、これらの遅延を特定し測定するのに適しています。 しかし、外部からの呼び出しではなく、内部的な問題でアプリケーションが遅くなっている場合、トレーシングは問題がどこにあるのかを正確には示せないことがあります。トレースから得られる情報は、コードに手動で実装したスパンと同程度の粒度しかないのです。一方、CPUプロファイラでは、関数や行レベルの詳細な情報を得ることができます。すべての関数を計測しなくても、コードのどこが遅いかを知ることができるのです。 プロファイラの種類 プロファイリングは非常に幅広い意味で用いられる言葉です。 プロファイラは様々な方法で実装することができます。例えば、プロファイラが収集するデータには、CPU、GPU、メモリ、I/O、ネットワーキングなどの使用状況が含まれます。 最近のプロファイリングツールのほとんどはCPUプロファイラで、CPU上で実行されるコードの性能を測定します。 この連載では、CPUプロファイラに焦点を当てます。 注意する点として、この記事で使用する例のほとんどは、フロントエンドとバックエンドの開発に関するものです。しかしながら、プロファイリングはあらゆるタイプのコードのパフォーマンスを理解するのに役立てられます。 継続的プロファイリング、アドホックプロファイリング、およびトランザクションベースのプロファイリング プロファイリングには、継続的に行う方法（常に行う方法）、アドホックに行う方法（Chrome DevToolsなどのツールを使ってサイトのプロファイルを手動で収集する方法）、またはその中間があります。 アドホックプロファイリング アドホックプロファイリングは、ウェブアプリケーションのプロファイルを取得する最も簡単な方法です。でも、ほとんどのアドホックプロファイリングツールは、機能が制限されています。 非常に人気のあるアドホックプロファイリングツールの一つは、Chrome DevToolsのパフォーマンスパネルです。これは、ボタンを押すことで、あらゆるウェブサイトの基本的なCPUプロファイルを記録することができます。アドホックプロファイリングツールは、ウェブサイトのパフォーマンスを素早く把握するのに便利ですが、プロファイルに収集されるデータは完全ではありません。 Chrome DevToolsのプロファイルは、主にウェブサイトのフロントエンドのパフォーマンスを素早く把握するのに便利です。しかし、バックエンドのデータを正確に把握することはできません。さらに、プロファイルはあなたのマシンに固有のものであり、他のユーザーたちが体験している挙動を正確に反映しているとは限りません。 最後に、これらのプロファイルの収集を自動化する簡単な方法もありません。パフォーマンスデータを見るには、毎回手動でプロファイルを作成する必要があります。 各プロファイルがユーザーエクスペリエンスを正確に表しているかどうかは定かではないのです。 継続的プロファイリング 継続的プロファイリングは、包括的なプロファイルデータの定石です。継続的プロファイリングは、長時間実行されるプロファイルです。このプロファイルは、アプリケーションの実行時間全体、またはユーザーセッション全体にわたって自動的に収集されます。 アドホックプロファイリングとは対照的に、連続的プロファイリングは、すべてのユーザーセッションで自動的に実行されます。これにより、いつでも実際のユーザーエクスペリエンスを明確に把握することができます。 これを実現するために、ウォールタイム（通話が完了するまでにかかる現実世界の時間）のような計算されたメトリクスを使用することができます。 継続的プロファイリングには、デメリットもあります。継続的プロファイリングは時間を長く擁することもあり、そのため必要な情報を見つけるのが難しくなることがあります。大量のデータ処理を要する場合もあります。 トランザクションベースのプロファイリング トランザクションベースのプロファイリングは、アプリ内でトランザクションが発生している間にプロファイルを自動的に収集するプロファイリング手法です。 トランザクションはトレーシングから生じた概念です。トランザクションとは、アプリケーション内部で呼び出されるサービスの単一インスタンスのことです。 例えば、ページロード、ナビゲーション、非同期タスクなどです。これらのトランザクションの集合が1つのトレースを構成します。 トランザクションベースのプロファイリングでは、自動プロファイリングの利点を享受でき、複数のユーザーのマシンで実際に起きていることを把握することが可能となります。しかし、継続的プロファイリングほど多くのデータを収集することはできません。トランザクションベースのプロファイリングでは、プロファイルが自動的に収集されるのは、トランザクションが発生している間だけです。 これにより、トランザクションと一対一でプロファイルを収集することが可能になります（例えば、トランザクションをキャプチャする毎にプロファイルもキャプチャされます）。また、トランザクションに対してプロファイルの収集をアンダーサンプリングすることも可能です。つまり、各プロファイルはトランザクションに関連付けられますが、すべてのトランザクションがプロファイルを持つわけではありません。 プロファイルの収集はトランザクションよりも多くのリソースを使用するため、アンダーサンプリングによってプロファイリングツールが引き起こすアプリケーションのパフォーマンス悪化を防止できます。 さらに、プロファイルをトランザクションにリンクさせることで、トランザクションとプロファイルからパフォーマンスデータを探索し理解するためのわかりやすいメンタルモデルを得られます。 アドホックプロファイリング、継続的プロファイリング、トランザクションベースプロファイリングの違いをまとめた表がこちらです。 アドホックプロファイリング 継続的プロファイリング トランザクションベースの プロファイリング プロファイルの作られ方 手動 自動
- [コードとUXの間のギャップを埋める、SentryのSession Replayとは？](https://ichizoku.io/sentry/introducing-session-replay-from-sentry-bridge-the-gap-between-code-and-ux/) - あの厄介なバグがありますよね？ローカルでは再現できないアレです。 何度環境を再現しようとしても、再現できません。パンくずリストを調べ、スタックトレースを読み、サポートチケットをつなぎ合わせて、バグが本物であることを確認しなければなりません。 しかし、もう原因をより迅速に突き止めるためにキーボードを走らせ頭を悩ませる必要はありません。SentryはSession Replayをリリースしました。この機能は現在すべてのウェブベースのプラットフォームでご利用いただけます。 Session Replayは、ウェブアプリケーション上のユーザーセッションを動画のように再現します。エラーやパフォーマンスの問題に至るまでユーザーが経験したことを正確に確認でき、再現が困難な問題をより迅速にトリアージして解決するのに役立ちます。 Session Replayを始める準備はできましたか? リプレイの基本割り当てはすべての Sentryプランに含まれておりすぐにご利用可能です。追加のリプレイは10,000リプレイにつき月額29ドルからご購入いただけます。詳細については、料金ページをご覧ください。 パンくずリストとスタックトレースの先へ Sentryのエラー追跡では、例外データを記録し、パンくずリスト、スタックトレース、コードの改行など、開発者たちが問題をトラブルシューティングできるように背景情報を表示しますが、それでも理解や再現が困難なタイプの問題もあります。 Session Replayでユーザーが辿った行程を視覚化できるため、コードと実際のユーザーエクスペリエンスの間のギャップを埋めて、問題がUIでどのように現れるかを理解できます。また、DOM イベント、ネットワークデータ、コンソールログ、パンくずリストなどの追加のデバッグ用背景情報を Replay機能に追加したため、最も苛立たしいバグやパフォーマンスの問題のトラブルシューティングに必要なものがすべて揃っています。 意味のあるデータを記録 世の中にあるほとんどのセッションリプレイ製品は、製品を使うユーザーセッションの何%かをランダムを記録します。これは、ユーザー分析や製品ファネルの理解が目的の場合は理にかなっていますが、主にソフトウェアの問題のデバッグを行う場合にはあまり意味がありません。 この方法では、再現したい複雑な問題に対応するリプレイに到達するまでに、1,000回のランダムなセッションを記録する必要が生じる場合があります。これは時間と費用の両方がかかります。 SentryのSession Replayは仕組みが異なります。一般的な方法でサンプリングをするオプションも提供していますが、ユーザーがエラーに遭遇したときのセッションを優先的にサンプリングするオプションも提供しています。これにより、トリッキーなバグが発生した場合に、そのバグに対応するリプレイが手配でき、この方法では、再現したい複雑な問題に対応するリプレイに到達するまでに、1,000回のランダムなセッションを記録する必要が生じる場合があります。 問題に便利に紐付けられています。必要なデータの取得に必要なつ時間が減り、イベントクォータを監視する不安が軽減されます。サンプリングとカスタマイズの詳細については、ドキュメントをご覧ください。 SentryのSession Replayを使用すると、エラーに対応するリプレイに集中でき、問題を迅速に確認し、リプレイを閲覧して15分で解決できます。以前は、同じ問題を解決するのに一日はかかっていたかも知れません。- Resistbot社 ソフトウェアエンジニア プライバシーを第一に考えたアプローチ セッションリプレイ系の製品には難しい問題があります。記録された HTML内のユーザーの秘密情報を誤って明らかにすることなく、貴重なデバッグコンテキストを提供するというバランスを取らなければなりません。情報を隠しすぎると、ユーザーがそのトリッキーなバグを引き起こした正確な方法を解読するのが難しくなります。情報を隠さなすぎると、機密データがユーザーのブラウザから流出する危険があります。 SentryのSession Replayは、コンテンツをデフォルトで安全でないものとして扱うことで、ユーザのプライバシーに有利になるような調整を行っています。すぐに使用できるすべてのHTML テキスト、画像コンテンツ、およびユーザーによる入力内容がユーザーのブラウザからサーバへ送信される前にマスクし、代わりに、リプレイに必要な既知の安全な HTMLコンテンツ (静的ナビゲーションやヘッダーリンクなど) をオプトインするように開発者に依頼します ）。この方法ではより多くのコンテンツがマスクされることにより、記録内容の忠実度がわずかに低下します。 しかし、ほぼ確実に、既知の安全なコンテンツのみがユーザーのブラウザから送信されます。 追加の防御策としてSession Replayは、個人情報スクラビングやIPリダクションなど、Sentryの他の製品と同じプロジェクトレベルのプライバシー設定を適用します。これにより、データが保存される前にエッジ取り込みサービスで機密コンテンツが削除されます。デフォルトで強力なプライバシー保護を導入することで、ユーザーの信頼を維持しながらデバッグエクスペリエンスを向上させることができます。 ヘルスケア企業として、個人情報や個人健康情報/PHIを適切に扱うことは、私たちや従業員にとって非常に重要です。Sentryは、この機密データがSession Replayで簡単に秘匿できるように調整してくれました。- Peppy、スタッフエンジニア デイブ・クリッドランド氏 問題の再現と解決をより迅速に。Replayがいかにエラーのトラブルシューティングに役立つか 実際に、Session Replayが開発者たちをどう支援するかを詳しく見るために、トラブルシューティングが困難なエラークラスの一つであるハイドレーションエラーを見てみましょう。 このクラスの問題は、Next.jsなどのハイブリッドレンダリングフレームワークに共通に見られ、サーバーが生成した HTMLがクライアント側のJavaScript が期待するものと一致しない場合に発生します。これにより、UIでコンテンツの不一致が発生し、本来不要なコンテンツの再フェッチと再レンダリングを引き起こします。 lablab.ai のLaszloがNext.jsプロジェクトでハイドレーションエラーに遭遇したとき、サーバーが生成したHTMLとクライアントのHTMLとが一致しない要素がページに何百もあったため、最初はデバッグが困難でした。またこの問題がユーザーにどう影響するかを理解するのは困難でした。そこでSession Replay の出番です。Laszloは、Replayを 一回見ただけで、コンソールログとリプレイのパンくずリストにハイドレーションエラーが表示され、ユーザーに対し誤って重複した画像が表示されていることに気付きました。 Session
- [Sentryでパフォーマンス監視をより実用的にする方法とは？](https://ichizoku.io/sentry/making-performance-monitoring-more-actionable-with-sentry/) - コードがどのように機能するかは、主観的な議題ではありません。少なくとも、これからは違います。過去数か月で、Sentryは何が遅いのか、どこを修正すればいいのかを正確に教えてくれるようになりました。具体的には、コード内のN+1データベースクエリです。 N+1の問題解決は皆経験がありますが、パフォーマンスの問題には様々な種類があります。今や、課題フィード、Slackのアラート、電子メール通知で、より多くのPerformance Issuesに気づくでしょう。 ダッシュボードや指標に目を通す時間を節約するために、Sentry はエラーと例外のワークフローをパフォーマンス監視にもたらします。Sentryは、コード内で一般的なパフォーマンス問題を自動的に検出してグループ化し、アプリケーションの速度低下やレイテンシー問題の原因となる具体的な問題点に対処できるようにします。 フロントエンド、バックエンド、モバイルのパフォーマンスに関する新たな問題の通知を受け取り、対策を講じることができるようになりました。 フロントエンド N+1 APIコール 非圧縮アセット 大きなレンダリングブロックアセット バックエンド 連続データベースクエリ N+1 データベースクエリ 遅いデータベースクエリ モバイル メインスレッドでのファイル入出力 Performance Issuesを始める。issue.category:performanceでフィルターをかけるだけで、すべてのパフォーマンスの問題が表示されます。また、パフォーマンス問題の各タイプの詳細については、こちらをご覧ください。 フロントエンドのパフォーマンスに関する問題 フロントエンドデベロッパーとして、ウェブの健全性に目を配り、顧客からのフィードバックに耳を傾けることは、ユーザーにとって高品質な体験を維持するために不可欠です。パフォーマンスの問題を放置しておくと、ページの読み込みが遅くなったり、スクロールが乱れたり、その他のUXの問題を引き起こし、ユーザーが失望してウェブサイトからの離脱に繋がります。 他のAPMツールでは、通常開発者達は、問題があまりにも深刻でサイトがダウンする場合を別とすれば、ダッシュボードを閲覧してログ、トレース、および指標の間を行き来しながらこれらの問題を手動で探し当てる必要があります。 Tilled のようなSentryの顧客にとって、Sentryのパフォーマンス監視サービスが提供する実用的な背景情報は、開発者チームの時間を節約するための鍵となっています。Sentry Performanceをセットアップしてトランザクションの送信を開始するや否や、TillのSRE リードである ブッチ・メイヒューにとって、パフォーマンスの問題が自動的に認識され、遅いページの読み込みや、遅いAPIエンドポイント応答の原因を特定するのに必要な、さまざまなデータソースを掘り下げる労力が軽減されました。 Sentryを専任とするエンジニアは週に1人です。パフォーマンスの問題に直面する中でも私たちのユーザーが慣れ親しんでいる高レベルのアプリケーションパフォーマンスを維持するには、背景情報がなければ、より多くのエンジニアリングリソースを割く必要があったでしょう。— ブッチ・メイヒュー（Tilled） Sentryは、すべてのフロントエンドWeb SDKについて、以下のフロントエンドのパフォーマンス問題を自動検出するようになったので、それらをあなたが手動で探す必要はありません。 N+1 APIコール バッチ処理される可能性のある、よく似た繰り返しAPIコールを検出します。 N+1 APIコールは、UIコードが同じ種類のリソースに対して多くの同時リクエストを行う場合によく起こります。例えば、アイテム内のすべてのリストが自身をレンダリングするためにAPIコールを行う場合などです。 クライアントとサーバーの両方にとって余分なリクエスト各々が負荷となるため、これらのリクエストをバッチ処理して一括APIコールを行うことは、アプリのパフォーマンスを向上させるために重要です。N+1APIコール問題はよく起こります。特に、コンポーネントが隔離された状況で作業が行われ、インテグレーションテストが行われていない場合、リストでレンダリングされていることに気づかずに、データ読み込みロジックをコンポーネントに追加してしまいがちです。 非圧縮アセット CSSやJavascript ファイルなどのフロントエンドテキストアセットの圧縮漏れに繋がるサーバーまたはインフラストラクチャ構成の問題を検出します。 ブラウザページをロードするためにダウンロードする必要がある大きなファイル (500キロバイト以上) の転送にかなりの時間がかかる場合 (500ミリ秒以上)、または転送中に圧縮されない場合、それは素材ファイルを提供しているサーバーまたはCDN（コンテンツデリバリーネットワーク）の設定ミスを示していることがあります。 圧縮されていない素材を最適化することで、特に接続速度の遅いユーザー（モバイルなど）に対して、ページの読み込み速度を向上させることができます。 大型レンダリングブロックアセット ダウンロードに時間がかかり、最初のページレンダリングを阻む大きなリソーススパン、および巨大なネットワークペイロードを検出します。 大きなレンダリングブロックアセットは、ウェブページのレンダリングを続行する前に完全にダウンロードして処理する必要があるJavaScriptファイルまたはCSSです。サイズが大きいため、ページのレンダリングとパフォーマンスがブロックされます。これにより、コンテンツがすべて適切に読み込まれる前に、ユーザーに対して空白または不完全な画面が表示されます。Javascript に新しい依存関係を追加したり、webpackの設定を変更したりすると、誤ってレンダリングブロックアセットが大きくなる可能性があります。 Sentryは、リクエストのFirst Contentful Paint（FCP）とFirst Input Delay（FID）によって測定される、ページのレンダリングとインタラクティブ性に影響を与える長いリソーススパンを警告するようになりました。これらのサイトの健全性は、ページロードがうまくいっているかどうかを示し、ウェブページのユーザー保持率を追跡するのに役立ちます。大規模なレンダリングブロックのアセット問題は、アセットURLでグループ化され、キャッシュバストやアセット分割のさまざまな方法に対応します。
- [【モバイル開発】未来は宣言型にある](https://ichizoku.io/sentry/mobile-the-future-is-declarative/) - モバイル開発のエコシステムは常に非常に多様であると言えます。（デスクトップ）ウェブ開発のエコシステムよりも多様だと言えるでしょう。日々、ウェブ開発者向けのフレームワークやツールは増えているようですが、その多くはJavaScriptの上に構築されています。 その多くは、互いに似たようなパターンを実装しています。一方、モバイルのエコシステムには、コアとなる複数の言語セットがあり、そのためモバイル向けのツールやフレームワークの違いを識別するのは非常に簡単です。 モバイルのネイティブプラットフォームの代表格といえば、ネイティブのAndroidとiOSの2つがあります。 どちらも最近興味深いイノベーションがありました。近年Jetpack ComposeとSwiftUIの導入がありました。 ネイティブアプリの開発は、React NativeやFlutterアプリの開発と非常によく似ています。React NativeもFlutterも、最初から宣言型アプローチをとっています。 AndroidとiOSも現在、宣言型のアプローチを採用しています。 モバイル開発の未来は、宣言型であると言えるでしょう。 ちょっとした歴史 React NativeやFlutterは常に宣言型のアプローチをとってきましたが、AndroidとiOSは当初はそうではありませんでした AndroidはViewを活用していました（今もそうですが）。ViewはXMLファイルです。 Button、TextView、LinearLayoutなどのウィジェットを使ってユーザーインターフェイスを定義します。開発者はこれらのウィジェットにIDを割り当てます。これらのIDは、Javaファイルの中でウィジェットを参照するために使用されます。 ファイルでは、機能と動作を開発します。以下は、Viewファイルの例です： このようにウィジェットのリファレンスを作成することになります。 iOSには、Auto Layout、UIAppearance、Objective-Cの@property宣言、KVCコレクション演算子、Combineといった宣言型の機能がありました。 しかし、それでもある程度の命令型のコードを書く必要がありました。 例えば、iOSにはStoryboardsがありました（今もあります）。Storyboardsは、私たちがUIを構築するために使うグラフィカルなツールですが、実際にはXMLファイルです。しかし、開発者はXMLのコード自体にはほとんど触れません。ここでは、StoryboardsでUI要素を追加し、参照とアクションを作成する方法を紹介します。 宣言型に移行する 記憶を呼び覚ますと、命令型アプローチとは、目的のUIを実現するまでのステップバイステップの指示を出すことです。宣言的アプローチとは、最終的なUIがどのような状態になるかを記述することです。 Androidの新しいJetpack ComposeはKotlinで書かれています。 これはマークアップ言語であるXMLとは対照的なプログラミング言語です。 先ほどのXML Viewの例は、Jetpack Composeではこのようになります。 ご覧のように、このアプローチでUIを構築すると、必要なコードはかなり少なくなります。プログラミング言語を使えば、ウィジェットへの参照を作成し、そのウィジェットにロジックを取り付ける代わりに、変数とコールバックを直接使用することができます。値に変化があれば再構成（リレンダリング）が行われるため、UIは常に最新の状態に保たれます。 iOSのSwiftUIはほとんど同じで、Jetpack Composeの代わりにSwiftで構築されています。先ほどのStoryboardの例は、SwiftUIではこのようになります。 ここでもコード量がぐっと減ります。ここはプログラミング言語なので、Buttonのラベルを直接定義することができます。 参照を作成することなく、onClickコールバックを提供することができます。 命令型UIKitで作業しているときに、問題が見つかりました。ViewをView階層に追加する前に、Viewの制約を有効にする必要があります。 subview.leadingAnchor.constraint(...)の行とview.addSubview(view)の行を入れ替えるとエラーにならずに動作します。最初にこのエラーに遭遇したとき、何が起こっているのか理解するのに時間がかかりました。 理解しやすくなるまで、さらに何度かこのエラーを発生させてみました。しかし、新しい宣言的アプローチでは、この問題に遭遇することはないでしょう。 AndroidとiOSにおけるこの宣言型へのシフトは、より良い開発者体験とより速い開発への大きな一歩となります。プログラミング言語を使ってUIを宣言型で定義することで、AndroidやiOSの開発者が抱える多くの苦悩を解決することができます。 ここでは、宣言型アプローチの利点を紹介します。 テーマ設定が簡単になり、より動的になります。 ステートマネジメントは自然に感じられ、新しい宣言的アプローチにおいて重要な役割を果たします。 コンポジションアプローチでは、要素をネストすることでUIを構成することができます ダイナミックレイアウトや条件付きレンダリングが簡単にできるようになりました。 なぜでしょうか？それは制御構造や分岐ロジックを持つプログラミング言語を使ってUIを構築しているからです XMLを介するよりもSwift/Kotlinのコードを介した方がgrepがしやすくなります。 プログラミング言語の他の部分に適用されるのと同じツールを使って、より体系的にコードを再構築することができます。 PRのコード差の方がわかりやすくなります。 UI要素は、マークアップ言語とは対照的に、実際のデータ構造（関数、クラス、構造体）で構築されています。 そのため、Viewのユニットテストも行うことができます。 もちろん、気にかけるべき欠点は常にいくつか存在します。 SwiftUIとJetpack Composeはまだ生まれて数年しか経っていません。 ドキュメントの不足、コミュニティの小ささ、いくつかのパフォーマンスの問題（例えばAndroidの遅延カラム）などの欠点があり、また以前のフレームワークからのすべてのコンポーネントがサポートされているわけではありません。 より複雑なUIを構築しようとすると、制限があります。SwiftUIとJetpack Composeの両方は、まだ進化し、改善されています。
- [【APM】実用的、手頃、そして実際の開発者のために作られた新しいアプリケーションパフォーマンス管理ツール](https://ichizoku.io/sentry/the-new-apm-actionable-affordable-and-actually-built-for-developers/) - 今ある可観測性の製品群 - 特に従来のアプリケーションパフォーマンス管理（APM）製品は、現代的な開発者たちの期待に応えられていません。これらのレガシーなツールは、運用チームとインフラ チームがインフラストラクチャとサービスを稼働させ続けるために作られたものです。しかし、実際にコードを書く人々を助け、レイテンシーの問題を見つけて修正する段になると、これらのツールにはしばしば莫大な価格がかかるため、開発者たちは問題を探し回り続ける必要があり、開発の遅延を招きます。問題を見つけたら、ログ、各種指標およびトレースの間を行ったり来たりして、コードのどこに問題があるのかを突き止める必要があります。 自社アプリケーションのパフォーマンスを理解するために、APMツールが博士号を備えている必要はありません。 Sentryのアプリケーションモニタリングへの新しいアプローチは、実用的で手頃な価格であることに重点を置いており、実際の開発者向けに構築されています。 動作の遅いクエリであれ、タイムアウトして売上下落を招くリスクのある潜在的な支払いエンドポイントであれ、Sentry は複雑さを取り除き、分析を行い、すぐに対処できる最も重要なパフォーマンスの問題を明らかにします。 あらゆる規模で手頃な価格を実現 従来の APM ツールのほとんどは「すべてを取り込む」アプローチに重点を置いているため、ストレージコストが高騰、環境にノイズが増加し、ほとんどの開発者たちが分析する必要のない膨大な量のテレメトリデータを発生させます。一つのツールに数千万円（またはそれ以上）を投資する場合、面倒な作業はすべてツールが行うべきです。御社が自らデータを詳細に調べて潜在的な問題やその根本原因を見つける必要はありません。 私たちは異なるアプローチを取り、市場で最も手頃なAPMソリューションを構築しました。私たちは、ノイズを取り除き、パフォーマンスデータから最大限の価値を引き出すと同時に、その節約分を直接お客様に還元しています。その結果、現在Sentryの大容量ユーザーの月次トランザクションコストは20％以上減少しています。 まとめると、大量のデータがある場合、すべてを保存する意味はありません。全てを保存してしまうと、重複やノイズが発生し、コストがかかります。しかし、全てのデータがあることで、アプリケーション パフォーマンスの最も正確な視点を提供できることも私たちは知っています。プラットフォームを手頃な価格に提供するための新しいアプローチにより、御社が送信するデータが増えるほど、アプリケーションパフォーマンスのサンプルにおいて代表性を確保するために必要なデータ保存量が減少し、イベント毎のお支払い金額は少なくなります。 裏側では、長期保存や検索に必要なイベントがどれかを最適化しており、御社が利用規模を拡大すればするほど、その節約の効果が表れます。さらに重要な点として、Sentryは異常値についてはデータを捨てることなく捕捉し続け、最新リリース、重要なトランザクション、開発環境など、お客様が設定した優先順位に基づいて最も気になる問題を特定し、さらなる分析やトラブルシューティングに必要なデータにいつでもアクセスできるようにします。 この技術がSentryの現在および将来の製品にどのような影響を与えるか、まだ表面しか触れていませんので、詳しく確認したい方はこちらでディスカッション頂けます。 これらの新しい価格テーブルを利用するには、サブスクリプション設定ページに移動してプランを更新するか、sales@sentry.ioに連絡してください。 パフォーマンス監視をより使いやすく ご利用の技術スタックに関係なくパフォーマンスデータに基づいた行動が取れるようにするために、よくあるパフォーマンスの問題を自動検出して通知する唯一のソリューションである Sentry が、より多くのフロントエンド、バックエンド、およびモバイルパフォーマンスの問題を検出できるようになりました。おなじみのエラーワークフローと同じように、ダッシュボードの情報を解読したりスパンツリーを調べたりする必要なく、画面上のフィードで実際に直接アラートを受けて問題を修正することが可能です。 おそらく、素材の圧縮が漏れたためかページの読み込み速度が低下、または、持続時間が 1000 ミリ秒を超えるSQLクエリを記述したために、ユーザーがロード中の回転アニメーションを延々と見続ける - このような新しいパフォーマンスの問題、レンダリングをブロックする大きな素材、遅いデータベースクエリ、およびメインスレッドのファイル I/O - これらの問題はイシューフィードに自動的に表示されるようになり、トリアージ、割り当て、そして問題を解決することで、顧客に影響を与えたり、アプリケーションをダウンさせるのを防ぐことが可能となりました。 今、私たちはSentryなしでは生きられません。 パフォーマンストランザクション内でイベントの詳細を確かめ、HTTPリクエストでデータベースで実際に何が起こったかを確認できます。これまでのようにパフォーマンスの問題に関するアラートを受け取り、そこからさまざまなログをつなぎ合わせて解決を試みるために時間を費やす必要はもうなく、このお陰で開発者の生産性が約 50% 向上し、開発者の時間を節約できます。 ブッチ・メイヒュー - Tilled社SREリード Sentryの新しいPerformance Issues機能について、詳しくはこちらのブログ投稿をご覧ください。または既に Sentry Performance をご利用の場合は、ログインして issue.category:performanceでフィルター処理し、パフォーマンスの問題をすべて確認してください。 Performance Issuesでは、折りたたまれたスパン ツリーを提供して、問題がコード内のどこにあるかを特定するのに役立ちますが、問題を修正するためにさらに背景情報が必要な場合もあります。SentryのSession Replayを使用すると、ユーザーセッションをビデオのように再現し、ユーザーがパフォーマンスの問題に遭遇するまでに何を経験したかを正確に確認できるため、通常は再現が困難なレイテンシーの問題をトリアージして解決し、数日から数分に短縮できます。 例えば、リプレイのパンくずリスト内で、特定のページナビゲーション、ページの読み込み、およびユーザーが経験したLargest Contentful Paint (LCP) を把握できるため、例えば、チェックアウトフローで読み込みが遅い画像があり、その読み込みを待つためにユーザーがどれだけ苦痛だったかをすぐに確認することができます。 Session Replayを使えば、ページの乱れを視覚的に確認でき、どのコンポーネントが影響を受けたかをピンポイントで特定できるので、手作業でのデバッグにかかる時間を短縮することができます。 -Laszlo
- [OpenTelemetry対応開始のご案内：  オブザーバビリティ（可観測性）データの有効利用](https://ichizoku.io/sentry/opentelemetry-support/) - Sentryは、2008年にサイドプロジェクトから成長していたオープンソース企業です。 現在では、350万人以上の開発者たちに利用されるアプリケーションパフォーマンス監視（APM）プラットフォームへと拡大しています。Sentryは、オープンソースと開発者たちのコミュニティにコミットしています。 また私たちは、コミュニティに対してオープンで透明であることにコミットしています。 Sentryは、ソフトウェアを構築するために、パブリックアプローチをとっています。 OpenTelemetry（またはOTel）の対応とインテグレーションは、Sentryにとって非常に自然なパートナーシップです。 何千もの企業がOpenTelemetryを使用して、サービス全体のデータを取得しています。 生ログ、トレース、メトリクスをキャプチャすることで、ソフトウェアのパフォーマンスを改善するための最初のステップが始まります。 OpenTelemetryを使用している開発者は、Sentryの最新のAPMを使用できるようになりました。 SentryのAPMツールは、開発者たちを第一に考慮して作られています。 私たちは、すべてのオブザーバビリティ（可観測性）データを実用化します。SentryとOpenTelemetryを使用する開発者たちは、パフォーマンス問題の根本原因をより迅速に特定し、解決することができるようになります。 Sentryは、Golang、Node.js、Python、Ruby、Javaをサポートしており、近日中に.NETがそこに加わります。 これにより開発者たちは、SentryのパワーとOpenTelemetryが設定されたアプリケーションからのパフォーマンスデータを組み合わせることができます。また開発者たちは、問題の原因となっているコードや関数の行を突き止めることができるようにます。 多くの無駄なデータを分析したり、ツール間を行き来したりする必要はもうありません。 Sentryは、利用者がより速く修正にたどり着くために必要な答えを見つけることを可能にします。 OpenTelemetryとSentryの連携を開始する Sentryは開発者優先のツールであり、簡単な導入プロセスを提供することで、開発者が複雑な設定に時間を費やすことなくコード作成に集中できるよう設計されています。 OpenTelemetryのインテグレーションは、設定も簡単です。 ソフトウェアに数行のコードを追加するだけで、すぐにSentryでテレメトリーデータを見ることができるようになります。 一度設定すれば、自動的に読み込みの遅いページのトレースが開始されます。 問題の原因となっているAPIコールやKafkaキューまで、簡単に確認することができます。他にも関連するエラーがあれば、Sentryはそれらも表示し、発生している可能性のある他のエラーと結びつけます。 Sentryは、問題を迅速に解決するために必要なすべてのデータ背景情報を提供します。それはまるで、ソフトウェアにGPSを搭載しているようなものです。Sentryは問題の原因を直接指摘してくれます。 SentryとOpenTelemetryを使い始めるのは、早くて簡単でした。私たちがSentryを選んだ理由は、どこでなぜ遅延が発生しているのかを理解できるからです。 迅速に修正し、ユーザーからのクレームを防ぐことができます。 Dominik Sandjaja シニアソフトウェアエンジニア @bex technologies GmbH Open TelemetryとSentryを使用して、ソフトウェアをより速く修正 顧客が注文をするためにチェックアウトページにたどり着きました💰。すべてがうまくいったように見えます。でも、errors.errorString（別名：無効な製品ID）が原因でサイレントクラッシュが発生し、支払いのフローが壊れてしまいました。顧客は注文を完了できず、怒りのソーシャルメディア投稿💸を書き始めます。 Sentryは、これを解決するのに役立つことができます*。Sentryはそのエラーを捕捉し、OTelのトレースデータと組み合わせます。Sentryは警告を発し、コードのどこに問題があるのかを正確に示します。 自動グループ化を用い、Sentryのフィード画面に個々の課題が表示されます。Sentryは、すべてのユニークなインスタンスをグループ化します。また、OTelからのトレースとスパンを同様に使用することもできます。Sentryは、エラーと問題を引き起こした関連する分散サービスを結びつけます。 問題が特定されたら、SentryのGithubとの強固なインテグレーションを活用し、その分散システムのコードをどのチームやエンジニアが所有しているかを見つけることができます。そして、そのチームをSentryから直接担当に割り当てることができます。 担当者らは、誰とも会話する必要もなく、修正作業を開始し、本番環境にリリースすることができます🪄。 Sentryは、アプリケーションコードの健全性を監視するための不可欠なツールです。エラー追跡からパフォーマンス監視まで、開発者たちは、フロントエンドからバックエンドまで、アプリケーションをより明確に理解し、より迅速に問題を解決し、継続的に学習することができます。Sentryは、世界中の350万人以上の開発者と85,000以上の組織に愛され、Disney、Peloton、Cloudflare、Eventbrite、Slack、Supercell、Rockstar Gamesといった世界で最も有名な企業の多くにコードレベルの監視機能を提供しています。 毎月Sentryは、インターネット上で最も人気のある製品から数十億の例外処理を行ってしています。 IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。またご導入についての相談はこちらのフォームからお気軽にお問い合わせください。
- [【Next.js / Supabase オブザーバビリティ設計】バイブコーディングから本番運用へ](https://ichizoku.io/sentry/nextjs-supabase-observability/) - Article by: Sergiy Dybskiy ここ数年で、ソフトウェアの作り方は大きく変化しました。一方で変わっていないのは、そのソフトウェアが最終的に「実際の人間」に届くという事実です。あなたや私、そして私の母のような人たちです。 そして、そうしたユーザーが必然的に何かしらの不具合に遭遇したとき、アプリケーションの開発者であるあなたは、何が壊れたのか、どこで壊れたのか、そしてそれをできるだけ早くどう修正するのかを理解するための適切なツールとコンテキスト、そして認識を備えている必要があります。 私たちは日々、「自己修復するソフトウェア」に少しずつ近づいています。Next.jsアプリケーションを構築し、バックエンドサービスとしてSupabaseを利用している場合、以下で説明するツールは、より高品質なソフトウェアを生み出すことと、すり抜けてしまった問題を最小限の影響で修正するという、自己完結的なループに一歩近づく助けになります。 要約 Supabaseはクエリパフォーマンスのインサイト、行レベルセキュリティ（RLS）のアドバイザリ、Edge Functionのログを標準で提供しているが、フルスタックを横断したトレースはできない Sentryはそのギャップを埋める：Next.jsのフロントエンドからSupabase Edge Functions、Postgresまでをまたぐ分散トレースを一箇所に集約できる SupabaseからSentryへログをドレインすることで、エラー・トレース・インフラログの単一の信頼できる情報源を作れる SentryはN+1クエリ、遅いスパン、パフォーマンス劣化を手動設定なしで自動検出する SentryのAIデバッガー「Seer」は新しい問題に対して原因を自動で推定し、修正をコーディングエージェントに引き渡すことができる エージェントが生み出すスタック問題 AI支援開発には特有の失敗モードがあります。エージェントは動作するコードを生成できますが、そこにオブザーバビリティが組み込まれていないことが多いという点です。その結果、Next.jsアプリがSupabaseと通信する方法が3種類（直接Postgres接続、Supabase JS SDK、そしてDrizzle、エージェントが戦略を切り替え続けたため）混在することもあり得ます。さらにDeno上で動くEdge Functionが加わり、実行時に何が起きているのかを統一的に把握できない状態に陥ります。 もう一つの失敗モードはより見えにくいものです。エージェントはインデックスを忘れることがあります。ローカル環境ではデータが40行程度しかないため問題にならず、N+1クエリを書いてしまうこともあります。しかし本番にデプロイし、データベースが400行に増えると、検索クエリが突然10秒かかるようになります。Sentryはこれを自動的に検出できますが、それは最初から正しく計装されている場合に限られます。 この計装を正しく行うには、SupabaseとSentryがどのように組み合わさるかを理解する必要があります。 Supabaseの組み込みオブザーバビリティとその限界 Supabaseには堅牢な組み込みオブザーバビリティがあります。ダッシュボードのQuery Performanceパネルでは、どのクエリが最も頻繁に実行されているか、どれが最も時間を消費しているかを確認できます。パフォーマンス問題が発生した際に最初に見るべき場所です。 またAdvisorsは、RLSポリシーの不足などのセキュリティ問題を検出し、重要度に応じて優先順位付けします。Index Advisorは不足しているインデックスを指摘し、それらが本番インシデントになる前に可視化します。 Logsセクションでは、Supabaseのすべてのサブシステムから構造化ログを取得できます。対象にはEdge Functions、Postgres REST API（PostgREST）、コネクションプーラー、ストレージ、cronジョブなどが含まれます。これらのログはダッシュボード上でSQLを使って直接クエリすることも可能です。 これは確かに非常に有用です。ただし、Supabaseの内部で観測できる範囲に限定されるという制約があります。つまり、Supabaseの外側で起きていることまでは見えません。例えば、遅いPostgresクエリがNext.jsフロントエンドのどのユーザーアクションによって発生したのか、あるいはEdge FunctionのタイムアウトがAPIレイヤー全体にどのようなエラーの連鎖を引き起こしたのか、といった因果関係は把握できません。こうした情報を得るには、フルスタックを横断した分散トレーシングが必要になります。 SupabaseログをSentryに接続する SupabaseのデータをSentryに取り込む最も簡単な方法は、log drainを使うことです。Supabaseダッシュボードの「Logs > Drain」で送信先を追加し、SentryのDSNを貼り付けると、そのSupabaseプロジェクトのすべてのログが対応するSentryプロジェクトへ流れ込むようになります。 この仕組みについて、いくつか重要な点があります。 現時点では「全量送信（all-or-nothing）」であり、Supabase側でログレベルによるフィルタリングはできません。 ログがSentryに入った後は、Log Explorer上で severity:warn や severity:error のようにフィルタリングできます。 log drainはNext.jsアプリやEdge
- [【Application Metrics】Unreal Engine のゲームパフォーマンスを監視する](https://ichizoku.io/sentry/unreal-engine-performance-metrics/) - Article by: Ivan Tustanivskyi あなたのUnrealゲームはエラーゼロの状態でリリースできたとしても、それだけで優れた体験になるとは限りません。戦闘中のスタッター、大型ボス戦での急激なフレームレート低下、マルチプレイヤーでのラバーバンディング。これらはいずれもクラッシュとしては現れず、Sentry にも表示されません。そのため、実際にプレイヤーが現場で何を体験しているのかを把握する手段がありませんでした。少なくとも、これまでは。 Unreal Engine には、ゲームパフォーマンスを測定し、実行時統計を収集するためのツールがすでに豊富に用意されています。しかし、そのデータはすべて開発者のマシン内に留まったままでした。 Unreal SDK の新しい自動パフォーマンスメトリクス機能は、このギャップを埋めます。FPS、フレーム時間、ネットワーク状態、そのほか一般的なゲームテレメトリを直接 Sentry に送信することで、どこでパフォーマンスが低下しているのか、どのハードウェアで発生しているのか、どのプレイヤーに影響しているのかについて、チームが実用的なインサイトを得られるようになります。Release & Health と組み合わせれば、各リリースが時間経過とともにパフォーマンスへ与える影響も追跡できます。 本題に入る前に、一点だけ触れておきます。すべてのゲーム開発者は、これまでに一度はプロファイラを使ったことがあるでしょう。自動パフォーマンスメトリクスはそれとは異なるものですが、関連するツールです。両者は同じ問題を異なるレイヤーから扱います。メトリクスは「どこでゲームが遅くなっているか」を見つけ、プロファイリングは「なぜ遅くなっているのか」を説明します。 Sentry が現在追跡するもの 現在、Unreal SDK は、全体的なパフォーマンスへ影響するいくつかの主要領域について、メトリクスを自動インストルメントします。対象には、フレーム時間、ネットワーク、ゲーム固有の統計などが含まれます。 フレーム時間 ゲームが快適に感じられるかどうかを最も直接的に示す指標です。フレーム時間は、「各フレームの処理にエンジンがどれだけ時間を使ったか」を示します。また、スレッドごとに分解することで、どのサブシステムがボトルネックになっているかを確認できます。 平均FPS 総フレーム時間 ゲームスレッド処理時間 レンダースレッド処理時間 GPUフレーム時間 ゲームスレッド、レンダリングスレッド、GPUの処理時間を比較することは、CPUがボトルネックになっているのかGPUがボトルネックになっているのか、そしてどのチーム（ゲームプレイ、レンダリング、コンテンツ）が修正を担当すべきかを判断する古典的な方法です。 FPSメトリクスの例（GPU別にグループ化） ネットワークインサイト マルチプレイヤーのパフォーマンスは、接続品質によって成否が決まります。しかし、クラッシュレポートだけではその状態を把握できません。これらのメトリクスによって、パケットロス、レイテンシ、帯域不足が、気づかれないまま体験品質を低下させていないかを確認できます。 送受信帯域幅 パケットスループットとパケットロス クライアントの ping と jitter アクティブ接続数 サーバービルドではさらに、ロードシェディング分析のために、クライアントごとの平均 ping、クライアントごとの帯域幅、飽和状態の接続数も取得できます（ネットワークメトリクスの完全な一覧を参照）。 これらのメトリクスは、マルチプレイヤーセッションがアクティブな間のみ存在します。ネットワーク機能を持たないシングルプレイヤーゲームでは、ここにデータは送信されません。また、一部の値はクライアント専用（ping、jitter）、あるいはサーバー専用（アクティブクライアント数、接続飽和）です。 Pingメトリクスの例
- [JavaScript のオブザーバビリティを修正する：ライブラリ単位での改善](https://ichizoku.io/sentry/fixing-javascript-observability/) - Article by: Abdelrahman Awad ここ数週間、私たちはクロスエコシステムでの取り組みとして、現在すべての JavaScript APM ツールを支えている「モンキーパッチング」をランタイムに組み込まれた仕組みに置き換える作業を進めてきました。ここでは、その背景と仕組み、そして現状について説明します。 この内容はサーバーサイド JavaScript（Node.js、Bun、Deno、Cloudflare Workers）のみに適用されます。ブラウザには diagnostics_channel が存在せず、またそれをポリフィルするために必要な非同期コンテキスト伝播の仕組みも備わっていません。 モンキーパッチングはスケールしない 私のチームメイトである Sigrid は、なぜモンキーパッチングが破綻しつつあるのか、そして TracingChannel がそれをどう解決するのかについて詳しく解説しています。 要点をまとめると、JavaScript のすべての APM ツール（Sentry を含む）は、実行時に require() や import をフックし、import-in-the-middle（IITM）や require-in-the-middle（RITM）を使ってライブラリをインストルメントしています。しかしこの仕組みは ECMAScript Modules（ESM）で壊れやすく、Node 以外のランタイムでは動作せず、バンドラとも衝突し、さらに制御できない内部実装に依存する構造になっています。また SDK は対象ライブラリより先に読み込まれていなければならず、そうでない場合は計測が静かに失敗します。 これは Sentry 固有の問題ではありません。JavaScript のインストルメンテーションを提供するすべての APM ベンダーが、同じ不安定さを抱えています。エコシステム全体が行き詰まっている状態です。 多くのライブラリメンテナーはオブザーバビリティを前提にしていません。何を公開すべきかも分からず、OpenTelemetry のような仕組みを導入することは標準化というより実装負担になります。これまで APM 側がパッチで吸収してきたため、ライブラリ側が対応する必要がありませんでした。 しかし、より良い方法があります。 TracingChannel：パッチ不要のオブザーバビリティ 2025年後半、私たちは Nitro、h3、そして unjs エコシステムの開発者である Pooya Parsa
- [【React Native SDK】Expo アプリのデバッグが簡単に](https://ichizoku.io/sentry/debugging-expo-react-native-sdk/) - Article by: Aleksandr Pantiukhov Expo アプリからのイベントは、React Native アプリ全体のイベント量の約 75% を占めています。この数値を受けて、Expo アプリのデバッグとパフォーマンスのワークフローを改善するために、Sentry React Native SDK への投資を行うことは自然な判断でした。 このアップデートにより、以下が可能になります。 OTA アップデートのチャンネルやバージョンでイシューをフィルタリングし、特定のアップデートに起因する問題かどうかを即座に絞り込む 緊急リリースに対するアラートを受け取り、ユーザーから報告される前に OTA パイプラインの障害を検知 EAS Build の健全性を Sentry 上で追跡できるため、ビルドログを辿ることなく問題の発生箇所を特定 ナビゲーションパフォーマンス全体を可視化し、プリフェッチのタイミングやアセット読み込みまで含めて確認 自動 OTA 更新コンテキストの付与 Expo Updates を使った OTA 配信では、適切なコンテキストがないと問題の原因が見えづらくなります。どの update channel だったのか、どの runtime version だったのか、埋め込みバンドルだったのか、それともダウンロードされた更新だったのか、といった情報です。 今回のアップデートでは、すべての Sentry イベントに ota_updates コンテキストが自動で付与されます。追加設定は不要です。update ID、channel、runtime version、起動時間、埋め込みアセットの使用有無などが取得できます。これらは Expo プロジェクトで標準で収集されます。 さらに、すべてのイベントには検索可能なタグ（expo.updates.channel、expo.updates.runtime_version、expo.updates.update_id）も付与されるため、特定のチャンネルやアップデートに絞ったフィルタリングを簡単に行えます。
- [【Application Metrics】シグナルを追跡し、スパイクを把握し、トレースへジャンプする](https://ichizoku.io/sentry/introducing-application-metrics/) - Article by: Ben Coe 要約：Application Metrics をリリースしました。これは、アプリケーション内の重要なシグナルを追跡するための新しい仕組みです。コンテキスト付きでユーザーの状況を把握し、問題がエラー化する前に検知できるようになります。 数週間前、私たちは Session Replay に関するバグに遭遇しました。1,000 を超える動画セグメントが読み込まれると、一部ブラウザで Replay が失敗していたのです。しかし、それがどの程度発生しているのか、誰に影響しているのかが分かりませんでした。さらに、この障害は必ずしもエラーを生成するわけではなかったため、影響を受けたユーザーを特定して再現する手段もありませんでした。 以前であれば、span やログを使って調査していたでしょう。しかしそれでは扱いづらい面があります。span はサンプリングされることが多く、外れ値を見逃す可能性があります。ログは構造化が弱く、時間とともに内容が変化しやすいものです。どちらも調査用途には向いていますが、既知の振る舞いを継続的に追跡するには、メトリクスのほうが適しています。 そこで私たちは、Sentry SDK 内で user 属性と provider 属性付きのメトリクスを設定し、1,000 セグメントを超えるセッションをフィルタリングしました。その結果、数分で再現ケースを特定できました。 これこそが、Application Metrics の役割です。追跡したいシグナルを記録し、あとで必要になるかもしれないコンテキストを紐付けておくこと。何か問題が起きたときには、必要なデータがすでにそこに揃っています。 事前集計されたカウンターではなく、完全なイベント インフラストラクチャテレメトリの追跡向けに設計されたメトリクスツールは、多くの場合、データを集計します。その過程で、ユーザー、IP アドレス、リージョンといった情報は削ぎ落とされます。残るのは単なるカウンターです。 Sentry の Application Metrics は、user のような高カーディナリティ属性を含む完全なイベントを保存します。そのため、「アプリケーション全体でチェックアウト体験が遅かったか」だけではなく、「東海岸のユーザーに対してチェックアウト体験が遅かったか」や、「特定ユーザーのスケジュールジョブがキューの滞留を引き起こしていたか」といった問いにも答えられます。 同じ SDK、コード1行で利用可能 最近の Sentry SDK を使っていれば、メトリクス機能はすでに有効化されています。新しい依存関係やサイドカーは不要です。必要なのはコードを1行追加するだけです。 主に使うことになるメトリクス型は、次の3つです。 Counter — 何かが発生するたびに数値を加算します。payment.declined、search.zero_results、email.failed のようなものです。アラート対象にしたい発生率や合計値の追跡に向いています。 Distribution — 何かが発生するたびに値を記録し、その分布を分析します。そのジョブはどれくらい時間がかかったか？
- [【Stripe Projects】2つのコマンドで Sentry が利用可能に](https://ichizoku.io/sentry/sentry-stripe-projects/) - Article by: Burak Yiğit Kaya 2つのコマンドだけで、エラーモニタリング、パフォーマンストレーシング、セッションリプレイを備えた完全に構成済みの Sentry プロジェクトをゼロから立ち上げることができます。 サインアップフォームも、メール認証のステップも、ダッシュボードを行き来して DSN をコピーして .env に貼り付ける作業もありません。アカウントは作成され、プロジェクトはプロビジョニングされ、5つの環境変数が作業ディレクトリに生成されて、そのまま SDK が読み取れる状態になります。 そしてコーディングエージェントを使っている場合でも同じです。ただしその場合、コマンドを入力する必要すらありません。「エラーモニタリングを追加して」と伝えるだけです。 仕組み Sentry は Stripe Projects のプロバイダーとして追加されました。Stripe Projects は、開発者（および AI エージェント）がターミナルから直接インフラサービスを発見・プロビジョニング・管理できる CLI ワークフローです。アプリが実行時に依存するサービスのためのパッケージマネージャのようなものだと考えると分かりやすいかと思います。 全カタログはこちらです。 デプロイ可能なサービスは2つ（Sentry プロジェクトと Seer AI）、プランは3種類。すべて CLI から管理できます。課金は既存の Stripe の支払い方法を通じて行われるため、Sentry 側で別途請求設定を行う必要はありません。 「エージェントに指示するだけ」という部分 stripe projects init を実行すると、プロジェクト内にエージェントスキルのファイルがスキャフォールドされます。 これらは、Claude Code や Cursor などのコーディングエージェントに Stripe Projects
- [サイトからCookieをなくして2年：私たちはどこにたどり着いたのか](https://ichizoku.io/sentry/two-years-without-cookies-on-the-site/) - Article by: Matt Henderson 2024年1月、私は sentry.io からすべての広告 Cookie とユーザートラッキングを削除したことについて書きました。当時、その決定から8か月が経っていましたが、何が壊れ、何が予想外だったのかを、まだ検証している最中でした。その記事は大きな反響を呼びました。おそらく、これまで私たちが公開した記事の中でも最も多く読まれたものの一つです。理由は単純で、Web 上でプロダクトを作ったり運営したりしている誰もが、同じ Cookie 廃止の流れを見つめながら、「もし本当に誰かが思い切って全部やめたら、実際どうなるのか？」を気にしていたからだと思います。 それから、もう2年以上が経ちました。私たちは Cookie を戻していません（そもそも戻すつもりもありませんでした）。そして、その結果として、成長予算の使い方はかなり大きく変わりました。最初から壮大な戦略を立てていたわけではありません。ですが、Cookie をなくしたことで、「どこにお金を使うべきか」「その投資に何を期待するのか」を考え直さざるを得なくなったのです。現在、私たちの成長予算のおよそ70%は認知向上に使われています。実際には、たとえば次のような取り組みです。 私たちは Golden State Warriors、Golden State Valkyries、そして Chase Center と複数年契約を結びました。 Syntax.fm は、自社でコーポレートポッドキャストを立ち上げる代わりに、2023年に Sentry の一部となりました。 毎年、ビルボード広告や OOH（屋外広告）にもかなりの予算を使っています。 ポッドキャスト、Reddit、YouTube、サードパーティニュースレター、インフルエンサーは、私たちにとって非常に大きなチャネルです。 この2年間で Open Source Pledge を通じて、オープンソースメンテナーに75万ドルを寄付しました。（それ以前にも継続して支援しています。） コアとなるビジネスモデルや、その他すべての施策も含めると、こうした投資は確実に成果を上げています。新規のアクティブユーザー数は指数関数的に成長しています。 こうしたタイプの投資は、開発者向けに製品を販売している企業としてはかなり珍しいものです。ただ、私たちも最初から大きな施策を打っていたわけではなく、もっと小さなところから始めました。ここまでで、私が学んだことを紹介します。 ソフトウェアの見つけられ方が変わっている もしプロダクトを作っているなら、すでに感じているかもしれません。人々がツールを見つけ、評価する方法は、いま大きく変わりつつあります。 以前は、かなり予測しやすい導線がありました。誰かが Google で問題を検索し、いくつかの検索結果をクリックし、比較記事を読み、トライアルに登録する。コンテンツを書き、広告を出し、SEO を行い、その流れの中で見つけてもらえれば、プロダクトは成長できました。 ですが、その流れは以前ほど信頼できるものではなくなっています。Google からのリファラルトラフィックは減少し、ゼロクリック検索は増加しています。Semrush の 2025年のデータによると、現在では Google 検索のおよそ60%が、どの
- [エージェントがエージェントをオーケストレーションする時、誰が監視するのか？](https://ichizoku.io/sentry/scaling-observability-for-multi-agent-ai-systems/) - Article by: Paul Jaffre かつて、あなたが監視していたのはサービスでした。 その後、サービス内部で動く AI 呼び出しを監視するようになりました。 そして今では、AI エージェント自身がタスクを完了するために別の AI エージェントを立ち上げるようになっています。これまでの監視に対する感覚は、もはや通用しなくなりつつあります。 これは仮定の話ではありません。エージェント型アーキテクチャは、すでに本番環境で動いています。コーディングエージェントが検索エージェントを呼び出し、オーケストレーターが検索、計画、実行のための専門サブエージェントを生成しています。チームは、それらをどう監視するかを理解するよりも早いスピードで、こうしたシステムを出荷しています。 問題はエージェントが失敗することではありません。問題なのは、失敗した時にどのエージェントが原因だったのか、あるいはそもそも技術的に「失敗」と呼べるものが起きていたのかすら分からないことです。 従来のトレーシングはこの世界のために作られていない 従来のスタックでは、リクエストをデバッグするとは、エントリーポイントからデータベースまで、1本の流れを追跡することを意味していました。1つのサービス、1人の責任者、1か所の調査対象です。 しかしマルチエージェントシステムでは、1回のユーザー操作によって、プランナーエージェント、3つのツール呼び出しエージェント、検証エージェント、書き込みエージェントが動作するかもしれません。つまり5つのアクターが関与し、それぞれ異なるモデル、異なるプロンプト、そして大きく異なるレイテンシ要件を持っている可能性があります。 しかも、エラーは必ずしも例外として表面化しません。サブエージェントによる不適切な出力は、エラーを投げることなく、単に問題の連鎖を始めるだけかもしれません。その破損したコンテキストは、後続のチェーンへと伝播していきます。オーケストレーターは成功したと思っている。しかしユーザーはおかしな結果を見る。そしてログを開いても、明らかに壊れているものは何も見つからないのです。 これが実際にどのようなものかを見たいなら、実際のマルチエージェントデバッグセッションを分解した事例を見るとよいでしょう。2段階上流で発生した静かなツール障害が、1つのエラーも発生させないまま最終出力を破壊していく様子が示されています。「ログを読めば分かる」という感覚が、このレベルの複雑さでは通用しなくなる理由をよく表しています。この世界では、小さなズレが積み重なり、やがて雪崩のように広がっていくのです。 この投稿では、チーム横断かつエンタープライズレベルの信頼性が求められる大規模運用環境において、その複雑さがどのように現れるのかに焦点を当てます。 可視性の問題はスケールとともに増幅していく 1つのエージェントなら把握できます。2つでも管理可能でしょう。しかし、5つのエージェントが条件分岐しながら互いを呼び出し、コンテキストを共有している状態になると、それはもはやまったく別の種類の問題になります。 あなたがデバッグしているのは、もはやコード実行ではありません。分散した意思決定グラフ全体にわたる、創発的な振る舞いです。かつてマイクロサービスによって、「スタックのどこかが遅い」という言葉が、トレースなしでは意味を持たなくなったように、マルチエージェントシステムでは、適切なインストルメンテーションなしに「AI が何かおかしなことをした」と言われても、ほとんど対処不能になります。 多くのチームは、それを痛みを伴って学びます。たとえば、原因不明のユーザー離脱率の急増かもしれません。あるいは、チェーンの3段階下流で、LLM が静かに誤ったデータを返しているケースかもしれません。ある日突然、トークンコストが3倍になっていることもあるでしょう。しかし、単一コンポーネントとして閾値を超えていないため、アラートは何も発火しません。 分散トレーシングは、マイクロサービスにおいて、まさにこの問題を解決してきました。今問われているのは、あなたの AI パイプラインが、その次の世代の問題に対応できるようインストルメントされているかどうかです。 実際に役立つマルチエージェント監視とは マルチエージェントシステムの可視化は、新しい製品カテゴリの話ではありません。重要なのは、適切な粒度で、適切な基本要素を適用することです。Sentry の AI オブザーバビリティ機能は、分散トレーシングと同じ基盤の上に構築されています。そのため、複雑さが増しても、基本的な考え方は変わりません。実際には、次のようなものが必要になります。 エージェント間ハンドオフをまたぐトレース継続性 トレース ID は、エージェント呼び出しごとにリセットされるのではなく、タスク全体を通して引き継がれる必要があります。必要なのは、誰が何を、どの順番で、どの入力と出力を伴って呼び出したのかを示す完全なツリー構造です。すべてのスパンが同じ親を持つフラットな一覧では、チェーン途中のどのエージェントが不正な状態を生み出したのかを理解するには不十分です。 エージェント単位でのスパン属性付け レイテンシ、トークン使用量、モデルバージョン、プロンプトハッシュ、出力シグナルなどは、トップレベル呼び出しへまとめるのではなく、各エージェント単位で把握できる必要があります。「オーケストレーターが 4.2 秒かかった」という情報だけでは、ほとんど意味がありません。しかし、「低信頼度の結果を返した検索サブエージェントを 3.8 秒待っていた」と分かれば、調査箇所は明確になります。このレベルの属性付けは、モデルバージョン、トークン数、プロンプト識別子などのメタデータを、インストルメンテーション時に各スパンへ付与することで実現できます。 障害モードの区別 エージェントのタイムアウト、不正なツール出力、コンテキストウィンドウのオーバーフロー、モデル拒否、技術的には正常な応答の下流で発生するハルシネーション。これらはすべて異なる問題であり、必要な対処法もまったく異なります。それらをすべて「AI エラー」と一括りにするのは、すべての 500
- [【モンキーパッチはもう不要】Tracing Channels による、より優れたオブザーバビリティ](https://ichizoku.io/sentry/observability-with-tracing-channels/) - Article by: Sigrid Huemer ほとんどすべての本番アプリケーションは、さまざまなツールやライブラリを利用しています。たとえば、データベースやキャッシュと通信するためのライブラリ、あるいは Nest.js や Nitro のようなフレームワークです。本番環境で何が起きているのかを把握するために、アプリケーション開発者は Sentry のような APM（Application Performance Monitoring）ツールを利用します。 しかし、そこには本質的な問題があります。APM ツールが必要とするパフォーマンスデータは、多くの場合、ライブラリ自身からネイティブに提供されていません。そのデータ取得は、Sentry や OpenTelemetry のような APM ツール側へ委ねられており、それらが代わりにライブラリの重要な機能へインストルメンテーションを行っています。 インストルメンテーションとは？ アプリケーションを観測可能にするための最も基本的な要件は、その各コンポーネントや利用ライブラリをインストルメントできることです。インストルメンテーションとは、プログラム内部の動作を監視・分析し、診断データを生成するためのコードを追加するプロセスを指します。Sentry SDK や OpenTelemetry のインストルメンテーションは、まさにこの処理を内部で行っています。 たとえば、一般的な HTTP クライアントライブラリを考えてみましょう。アプリケーション開発者は、リクエストの開始と完了のタイミング、さらに URL、ステータスコード、ヘッダーといったメタデータを知りたいと考えます。 現在、ライブラリごとにこの対応方法は統一されていません。emitter.on('request', ...) のような独自フックを提供するものもあれば、リクエストを横取りするためのベンダー固有ミドルウェアを提供するものもあります。こうした場合、Sentry や OpenTelemetry は、オブザーバビリティデータを送信するプラグインを実装できます。 これは機能しますが、その負担はライブラリやフレームワーク側（たとえば Nuxt）にかかります。つまり、インストルメンテーション用 API を意識的に設計し、どこでそれを公開するべきかを判断しなければなりません。フックやインターセプタによって、適切な場所へオブザーバビリティコードを差し込める一方で、APM のメンテナーは、その API が将来にわたって安定して維持されることをライブラリ作者に依存しています。 さらに、共通規約も存在しません。ライブラリごとにフックの形もメタデータも異なるため、APM メンテナーはライブラリごとに大きく異なるプラグインを実装・保守し続ける必要があります。 サーバーサイド JavaScript はどのようにインストルメントされているのか JavaScript における従来のインストルメンテーション手法は「モンキーパッチ」です。これは、ライブラリのコードを実行時に書き換え、本来の処理に加えてオブザーバビリティデータも送信するようにする方法です。この手法が可能なのは、モジュールが変更可能で同期ロードされる CommonJS（CJS）環境に限られます。
- [【マルチエージェントAI - デバッグ】障害がエージェント間の「隙間」で発生するとき](https://ichizoku.io/sentry/debugging-multi-agent-ai-when-the-failure-is-in-the-space-between-agents/) - Article by: Sergiy Dybskiy 私は最近、マルチエージェント型のリサーチシステムを構築していました。アイデア自体はシンプルです。「PythonバックエンドをRustへ書き換えるべきか？」のような議論の分かれる技術トピックを与えると、3つのエージェントがそれぞれ役割を担います。Advocate は賛成側を主張し、Skeptic は反対側を主張し、Synthesizer は両者のブリーフを先入観なしに読み込んで、バランスの取れた分析を生成します。各エージェントはそれぞれ異なるモデル、異なるツール、異なるシステムプロンプトを持っています。 テストではうまく動いていました。しかし、そのうち Synthesizer が片側に強く寄った分析を繰り返し生成していることに気づきました。間違っているわけではないのですが、明らかに偏っていたのです。たしかに Sentry のモノレポをRustへ書き換えるのは悪いアイデアかもしれませんが、本来なら賛成になるべきだと明確に分かっているケースでも反対寄りの結論になっていました。 最終的に原因をたどると、Skeptic 側の web_search ツールに行き着きました。Advocate はクエリごとに3〜4件のしっかりしたデータポイントを返していました。一方 Skeptic は、データとうまく一致しない別の検索語を使っており、結果として汎用的な検索結果を1件返しているだけでした。そのため、Advocate のブリーフには引用付きの十分な根拠がありましたが、Skeptic のブリーフは……雰囲気だけになっていました。 Synthesizer は、合理的な読み手なら当然するであろう判断をしただけです。より根拠が揃った側の主張を、より重く扱ったのです。 問題は、ある1つのエージェント内のツール呼び出しにありました。そしてその問題が、2段階後にまったく別のエージェントへ渡される入力品質を静かに劣化させていたのです。私がそれを発見できたのは、トレースをクリックしながら各ステップのツール出力を順番に読み進めたからでした。 マルチエージェントのオブザーバビリティとは？ マルチエージェントのオブザーバビリティとは、複数のAIエージェントがどのように協調し、作業を引き継ぎ合い、互いの意思決定へ影響を与えているかを可視化することです。 おそらく、単一エージェントのオブザーバビリティについてはすでにご存じでしょう。1本の推論チェーンがあり、いくつかのツール呼び出しがあり、最終的なレスポンスが返る、というものです。マルチエージェント版では、1つのエージェントの出力が別のエージェントの入力になる、相互接続された推論チェーンのグラフ全体を追跡します。このグラフのどこか1か所で失敗が起きると、その後段すべてを静かに壊してしまう可能性があります。 もし、いくつかのツールを持つ単一エージェントを動かしているだけなら、通常のエージェントオブザーバビリティで十分です。しかし、エージェント同士が他のエージェントを呼び出したり、サブタスクを委譲したり、並列実行した結果を後から統合したりし始めた瞬間、必要になる可視性のレベルは別物になります。 なぜ単一エージェント向け監視では不十分なのか 既存のエージェント監視では、「Skeptic が3.1秒で実行され、2,400トークン消費した」ということは分かります。しかし、それだけでは、Skeptic の web_search が弱い検索結果しか返していなかったこと、その結果生成されたブリーフが Advocate に比べて薄かったこと、そして Synthesizer が片方の入力品質の低さによって偏った分析を生成したことまでは分かりません。 これが破綻する理由は、主に3つあります。 まず、責任の所在が分散していることです。最終出力が間違っていたとしても、単一のエージェントだけを責めることはできません。Advocate はツールから得た情報を元に合理的な主張を組み立てていましたし、Synthesizer も受け取った情報を合理的に統合していました。問題は両者の相互作用の中にあり、単一エージェントのログだけを見ても発見できません。 次に、最悪の失敗ほど一見正常に見えることです。従来のソフトウェアでは、問題が起きればエラーが投げられます。しかしマルチエージェントAIでは、あるエージェントが「もっともらしいが薄い結果」を返し、次のエージェントがそれを疑わず取り込み、最終出力が返る頃には、弱いデータが何段階もの推論を経て自信満々に要約されています。生の入力同士を比較しない限り、その問題には気づけません。 さらに、すべての経路をテストできないという問題があります。5つのツールを持つ単一エージェントであれば、各ステップで取り得る行動は5通りです。しかし、5つのツールを持つ3つのエージェントが並列実行され、後で結果を統合する場合、可能な実行経路の数は膨大になります。すべての組み合わせを事前テストすることはできないため、本番環境で実際に何が起きているかを観測する必要があります。 多くの「マルチエージェント」は実際には単一エージェント 先へ進む前に、正直に言っておきたいことがあります。私は最初、この実験環境でマルチエージェント型のスタートアップアイデア検証システムを作りました。しかし途中で気づきました。これは偽物のマルチエージェントだったのです。 「Market
- [【Android tombstone】ネイティブクラッシュ解析の大幅改善](https://ichizoku.io/sentry/native-crash-postmortems-via-android-tombstones/) - Article by: Mischan Toosarani-Hausberger , Roman Zavarnitsyn （了読時間：13分） Androidにおけるネイティブクラッシュは、これまで本来あるべきよりもデバッグが難しいものでした。 Androidには独自のクラッシュレポーター（debuggerd）があり、クラッシュしたスレッド、実行中の他のすべてのスレッド、レジスタ状態、メモリマップを tombstone と呼ばれるファイルに記録します。tombstone は長年Androidの一部であり、実際にはAndroid最初期のコミットの頃から、形を変えつつ存在してきました。 問題は、Androidの歴史の大半において、アプリ内部から tombstone をプログラム的に読み取ることができなかったことです。そのため、SDKベースのネイティブクラッシュレポート機能（私たちのものを含む）は、プラットフォーム側ですでに存在している仕組みを独自に再実装せざるを得ませんでした。その代償として、バイナリサイズの増加、不完全なJavaフレームのシンボリケーション、さらに変化し続けるAOSPに追従するために維持しなければならないC++フォークが発生していました。 Android 11（SDK level 30）では ApplicationExitInfo が導入されました。さらに Android 12（SDK level 31）では、ApplicationExitInfo.REASON_CRASH_NATIVE に対する trace input stream へのアクセスが追加されました。 SentryのAndroid SDKは、バージョン8.30.0以降、Android 12以上を実行しているすべてのデバイスでこのストリームを読み取り、ネイティブクラッシュイベントとして送信します。これにより、ネイティブコードを使用するAndroidアプリのクラッシュレポートは大幅に改善されました。基本的なクラッシュ通知だけが必要なチームにも、詳細なデバッグ情報が必要なチームにも有効です。 ここからは、以前はどのように動作していたのか、既存のNDK統合を壊さずにこれをSDKへ組み込むために何が必要だったのか、そしてこれによってどのような改善がもたらされたのかを見ていきます。 tombstoneサポート以前：変化し続けるターゲットを追い続けるフォーク tombstoneサポート以前、Android SDKでは Native SDK（sentry-native）がネイティブエラーレポートの主要な仕組みとして使用されていました。AndroidはLinuxベースであるため、SDKのかなりの部分を再利用できました。しかし再利用できない部分については、2019年からAndroid固有コードの統合作業が始まりました。 特に、libunwindstack（現在も debuggerd、そして tombstone のスタックトレース生成に使用されているAOSPのプラットフォームアンワインダ）を統合したことは、Sentry Android SDKでネイティブクラッシュをサポートする上で重要な転機となりました。なぜかというと、Native Development Kit（NDK）には汎用的なスタックウォーカーが存在しなかったからです（今でも存在しません）。 libunwindstack はNDKの一部ではなく、Android Open Source Project（AOSP）のプラットフォームコードの一部であるため、通常の方法ではアプリ開発者から直接利用できません。Sentryは、NDKでビルドできるようプラットフォームコードへパッチを当てたリポジトリをフォークし、その後も上流のパッチ版に変更がないまま、そのフォークを維持してきました。 これにより、非常に複雑なAndroid
- [すべてをサンプリングせず、AIトレースを100%取得する](https://ichizoku.io/sentry/sample-ai-traces-at-100-percent-without-sampling-everything/) - Article by: Sergiy Dybskiy 少し前、エージェントたちが「あなたは完全に正しいです！」と言っていた頃、私はwebvitals.comを作っていました。URLを入力すると、Next.jsのAPIルートへのAPIリクエストが開始され、いくつかのツールを持つエージェントが呼び出されてそれをスキャンし、あなたの……そう、想像どおり……Web Vitalsを改善するためのAI生成の提案を提供します。今もこれを気にする必要はあるのでしょうか？ 開発環境ではtraceSampleRateを100%に設定していましたが、本番環境ではそれを10%まで下げていました。なぜなら……まあ、それが私たちのインストルメンテーションで推奨されているからですが。 Kyleは「【Sentry サンプリング戦略】すべてを見ようとすると結局なにも見えなくなる」と説明する優れたブログ記事を書いています。しかし、AIは非決定的です。そしてツールコールのエラーをデバッグしていたとき、そのサンプリング戦略のせいで、Vercel AI SDKから出力される非常に重要なスパンを見逃していることに気づきました。 7回のツールコールを伴うエージェントの実行は、部分的にサンプリングされることはありません。スパンツリー全体を取得するか、完全に失うかのどちらかです。これがヘッドベースサンプリングの仕組みです。 私は幻を追いかけていたわけです。 エージェントの実行はスパンツリーであり、サンプリングは全取得かゼロかのどちらか 一般的なエージェントの実行は、Sentryのトレースビューでは次のように表示されます。 1回の実行で11個のスパンがあり、サンプリングの判断はルートで一度だけ行われます。それは POST /api/chat のHTTPトランザクションです。すべての子スパンはその判断を引き継ぎ、ルートが破棄されれば、9個すべてのスパンが消えます。 これはHTTPリクエストのサンプリングとは本質的に異なります。GET /api/users を1つ捨てたとしても、次のリクエストはほぼ同じなので大きな問題にはなりません。 エージェントの実行は同一ではありません。それぞれが異なる判断を行い、異なるツールを呼び出し、異なるデータを処理します。67回目の実行でハルシネーションを起こしたエージェントが、420回目では完全に正常に動作するかもしれません。もしサンプルレートによって67回目が捨てられていたら、何が問題だったのかを知ることはできません。 ヘッドベースサンプリングが実際にどのように動作するのか（そしてここでなぜ重要なのか） SentryのJavaScriptおよびPython SDKはいずれもヘッドベースサンプリングを使用しています。判断はトレースの開始時、まだ子スパンが存在しない段階で行われます。 JavaScript SDKでは、SentrySampler.shouldSample() がこの点を明確に示しています。 ルートでないスパンには決定権はありません。ルートスパンが破棄された場合、gen_ai.request や gen_ai.execute_tool を含むすべての子スパンについて tracesSampler が呼び出されることはありません。子スパンは親の運命を引き継ぎます。 Pythonでも同じロジックは Transaction._set_initial_sampling_decision() にあります。traces_sampler コールバックには sampling_context の辞書が渡され、その中には transaction_context（op と name を含む）と parent_sampled が含まれます。これはルートトランザクションに対してのみ実行されます。 つまり、ヘッドベースサンプリングでは、親トランザクションとは別に
- [【AIエージェントのオブザーバビリティ】エージェント監視 開発者ガイド](https://ichizoku.io/sentry/ai-agent-observability-developers-guide-to-agent-monitoring/) - 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に送信](https://ichizoku.io/sentry/send-your-existing-opentelemetry-traces/) - 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】ロギングが難しい理由と解決策](https://ichizoku.io/sentry/logging-in-next-js-is-hard-but-it-doesnt-have-to-be/) - 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】オブザーバビリティのギャップと解消方法](https://ichizoku.io/sentry/next-js-observability-gaps-how-to-close-them/) - 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() を呼び出すことで、エラー、ログ、トレース、リプレイ全体にユーザーコンテキストを伝播させることができます。
- [【Sentry SDK】アップグレードが必要な状態かもしれません](https://ichizoku.io/sentry/overdue-for-a-sentry-sdk-upgrade/) - 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
- [AI時代における Fair Source Software](https://ichizoku.io/sentry/fair-source-software-in-the-ai-age/) - 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 は
- [【JavaScriptロギングライブラリの選び方】2026年決定版ガイド](https://ichizoku.io/sentry/javascript-logging-library-definitive-guide/) - 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
- [OTLP を使って OpenTelemetry のログを Sentry に送る方法](https://ichizoku.io/sentry/structured-logging-opentelemetry/) - 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 が登場](https://ichizoku.io/sentry/react-native-sdk-8-is-here/) - 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
- [ランダムなチャンクから本当のコードへ：SentryでNext.jsのソースマップをつなぐ](https://ichizoku.io/sentry/setting-up-next-js-source-maps-sentry/) - Article by: Sergiy Dybskiy, Anton Bjorkman Next.js アプリをリリースするとき、あなたが書いた React や TypeScript は、ユーザーが実際にダウンロードするものではありません。Next.js はパフォーマンスには優れている一方でデバッグには最悪な形で、コードをコンパイルし、ミニファイし、分割し、チャンクへとシャッフルします。 この記事では、そのパイプラインがどのように動くのか、ソースマップと Debug ID がそれらをどのように元のコードへ結び付けるのか、そして Sentry が読みにくいスタックトレースではなく、実際のファイル名と行番号を表示するように設定する方法を解説します。 コードに実際に何が起きるのか 一般的な Next.js アプリでは、React＋TypeScript のソースはビルドパイプラインを通り、JavaScript、HTML、CSS へコンパイルされます。その出力はミニファイされ、ユーザーが必要なものだけをダウンロードできるようにチャンクへ分割されます。 これらはページの読み込みには良いことです。しかしエラーが起きたとき、スタックトレースが app/page.tsx ではなく static/chunks/12345-something.js を指すようになると、あなたにとってはあまり良いことではありません。 あなたのコードは見覚えのあるものから、まったく見覚えのないものへと変わります。そこで登場するのがソースマップです。コンパイルされた各バンドルチャンクには、2つの重要なメタデータがあります。Debug ID と対応するソースマップを指す sourceMappingURL です。 Sentry はアップロードされたミニファイ済みファイル上の Debug ID を使って、アップロードされたソースマップ上の一致する Debug ID を見つけます。このペアがそろうと、Sentry はスタックトレースをデミニファイし、元のファイル、行、列へマッピングし直して、バンドラーが生成したコードではなく、あなたが実際に書いたコードを表示できます。 開発ツールではきれいなスタックトレースが出るのにSentry ではチャンクになる理由 開発時はブラウザ上では問題なく見えます。dev でアプリを動かし、サンプルのエラーを投げると、ブラウザの開発者ツールは実際のファイル名とソースを含む、読みやすいスタックトレースを表示します。 これは next
- [AIによるキャッシング戦略と計測](https://ichizoku.io/sentry/ai-driven-caching-strategies-instrumentation/) - Article by: Lazar Nikolov, Ben Coe 最低限の製品（MVP）と本番対応のアプリを分けるものは、磨き込み、最終調整、そしてパレートの法則でいう「最後の20%」の作業です。ほとんどのバグ、エッジケース、パフォーマンス問題は、リリース後に実ユーザーがあなたのアプリケーションを使い込むようになって初めて表面化します。これを読んでいるということは、おそらく作業の80%地点にいて、残りに取り組む準備ができているはずです。 本記事では、アプリケーションのキャッシングを扱います。テールレイテンシの削減、データベースの保護、トラフィックのスパイクへの対処にキャッシュをどう使うか、さらに本番環境で稼働し始めてからそれをどのように監視するかを解説します。 本記事は、MVP を本番環境に持ち込む際に生じる共通の課題を扱うシリーズの一部です。 本番環境で大規模データセットをページネーションする：OFFSETの限界とカーソルの利点 AIによるキャッシング戦略と計測（本記事） キャッシングのメンタルモデルを構築する 適切なキャッシングはパフォーマンス、スケーラビリティ、コスト効率を何倍にも高めます。正しく行えば、ミリ秒未満の応答を実現し、オリジンサーバーを潰すことなくトラフィックの急増を吸収できます。一方、誤ったキャッシング（過度なキャッシング、不適切な無効化、誤った戦略）は、微妙なバグや古いデータ、デバッグが難しく、しかも多くのユーザーに影響が及んだ後になってようやく表面化する劣化したユーザー体験（UX）を生みます。 キャッシングの機会を探す前に、何をキャッシュすべきで、何をキャッシュすべきでないのかについてのメンタルモデルが必要です。 以下のチェックリストをご覧ください。 ✅ 大半が当てはまるならキャッシュを検討 高コスト：CPUが遅い、入出力（I/O）が遅い、DBが重い、大規模な結合／集計、外部API 高頻度：呼び出し回数が多い（1分あたりのリクエスト数（RPM）が高い）、またはホットパス上にある（ページ読み込み、コアAPI） 再利用可能：同じ入力が繰り返される（キーのカーディナリティが低い） ある程度安定：データが毎秒変わらない（または多少の古さを許容できる） スパイク負荷：突発的なトラフィックで、キャッシュがアクセス集中（サンダリングハード）を吸収できる テールが痛い：P95/P99が悪く、キャッシュミスが遅いリクエストと相関している 古いデータを返しても安全：ユーザー影響が小さい、または stale-while-revalidate（SWR）を使える 無効化が簡単：TTL（time to live）が機能する、または更新に明確なトリガーがある ペイロードが小さめ：メモリコストが妥当で、シリアライズが安い ❌ 次のいずれかに当てはまるならキャッシュしない（または慎重に） キーのカーディナリティが高い：ユーザーごと／ページごと／フィルターごとに爆発する → ほとんどがキャッシュミスになる（ページネーションは特殊ケース。後述の注記を参照） 変化が激しい：正確性のために鮮度が必須 個別対応／権限制御がある：キーのミスでデータ漏えいが起きやすい 無効化が難しい：明確なTTLがない、更新が予測できない すでに速い：5msの短縮は複雑さに見合わない キャッシュスタンピードのリスク：再計算コストが高い＋有効期限が同期される（ロック／ジッターが必要） ページネーションされたエンドポイントをキャッシュする際には特別なルールがあります。まずは1ページ目と一般的なフィルターをキャッシュしてください。1ページ目と少数の一般的なフィルターは通常ホットで再利用されるため、キャッシュの効果が大きくなります。一方、ページ番号が増えるほどキーのカーディナリティが爆発し、再利用は急落します。そのため、深いページは自然にキャッシュミスになりますが、それで問題ありません。全ページで均一なヒット率を達成することではなく、バックエンドの保護と入口（エントリーポイント）でのテールレイテンシ削減を最適化対象にしてください。 本番環境でキャッシング機会を見つける 何をキャッシュすべきかが分かったら、次に考えるべきは「キャッシュが実際に効く場所はどこか」です。本番環境のシステムでは、良いキャッシュ候補はたいてい「痛み」として現れ、通常は3つの形を取ります。 バックエンドでの問題（ここから始めましょう） バックエンドとフルスタックのシステム において、これが最も手を打ちやすいシグナルです。
- [SentryがXcodeBuildMCPを買収](https://ichizoku.io/sentry/https-blog-sentry-io-sentry-acquires-xcodebuildmcp/) - Article by: Cameron Cooke, Josh Cohenzadeh 本日（2026年2月11日）、Sentry が XcodeBuildMCP を買収したことを発表いたします。XcodeBuildMCP はオープンソースの MCP サーバーで、AI エージェントにネイティブのiOS／macOS アプリをビルド、テスト、デバッグする機能を提供します。 XcodeBuildMCP はエージェント型の Apple プラットフォーム開発における定番ツールとなっており、GitHub のスター数は4,000を超え、活発なコミュニティがあります。ビルド、実行、デバッグ、操作、検証という開発ループ全体を解放し、ユーザーが好みのエージェント型開発環境にとどまったまま作業できるようにします。 この買収の一環として、XcodeBuildMCP の作者兼メンテナーである Cameron Cooke も Sentry のチームに加わり、Sentry のモバイル向けツール群、そして新しいエージェント型開発の環境を継続的に改善していく取り組みを支えてくれます。 なぜ Sentry に適しているのか Sentry はソフトウェアの信頼性を高め、開発者がアイデアから本番環境へ最短で到達できるようにすることに注力しています。モバイルチームにとって、この道のりは依然として困難であり、そのため私たちは2025年に Emerge Tools を買収しました。 Apple プラットフォーム向けのツールはエージェント的なワークフローへの採用が再び遅れており、開発者たちはますます重厚な IDE よりも Cursor や Claude Code、Codex CLI のようなツールで作業を行うようになっています。 XcodeBuildMCP はそのギャップを埋めるのに役立ちます。開発者が持つ現実世界での能力をエージェントにも与えることで、自律的に反復し、人間に都度コントロールを戻すのではなく、変更を検証できるようになります。 XcodeBuildMCP で可能になること 主な機能は以下のとおりです。
- [【Size Analysis】Sentryで提供開始](https://ichizoku.io/sentry/size-analysis-generally-available/) - Article by: Max Topolsky, Steve Zegalia Sentry は 2025年5月に Emerge Tools を買収しました。これにより開発チームに最適なモバイルツールを提供する準備が整いました。そして主力製品の1つである Size Analysis を正式にすべての Sentry ユーザーに提供を開始しました。これで、アプリサイズをもう心配する必要はありません。 CI パイプラインでの自動監視 アプリサイズが増えていく最も一般的なパターンは、少しずつ積み重なっていくことです。小さな変更が時間とともに蓄積し、気づけばモバイル通信でのダウンロード上限を超えているという警告が出るようになります。そうした小さな変更は、加えた時点であれば簡単に最適化できますが、1年後に対処しようとすると、途端に難しい作業になります。 Size Analysis は CI ワークフローに統合できるため、アプリサイズの状態を継続的に把握できます。すべてのビルドをアップロードして差分比較できます。サイズに変化があったときは、単に変わったことがわかるだけでなく、なぜ変わったのか、さらにサイズを小さくするために実施できる推奨修正があるかどうかまで確認できます。 よくあるシナリオを見てみましょう。SDK を追加する場合です。 ここに、Kingfisher を追加した際のステータスチェックがあります。Size Analysis を使うと、すぐに次のことがわかります。 この PR により、ダウンロードサイズは約500 kB、インストールサイズは約1.5 MB増加しています。 この PR が失敗したのは、「Install Size の差分が 1 MB を超える場合はチェックを失敗させる」という事前設定済みのしきい値があったためです。 「Comparison Page」を確認すれば、差分が想定どおりであることを確かめたうえで、PR を承認できます。このページでは全体のサイズ変化だけでなく、サイズが変化したすべてのファイルを表形式とビジュアルの両方で確認できます。 この場合、これは意図した差分であることが明らかなので、ステータスチェックを承認し、PRをマージできます 🎉。 次のシナリオを見てみましょう。新しいヒーローイメージを追加する場合です。 全体のサイズ差分は今回も確認できますが、今回は2つの Insights
- [【Sentry サンプリング戦略】すべてを見ようとすると結局なにも見えなくなる](https://ichizoku.io/sentry/sampling-strategy-sentry/) - Article by: Kyle Tryon 要約：一律のサンプリングレートは無駄や非効率につながることがあります。独自のサンプリングロジックを用いて、ノイズを減らしつつ100%のシグナルをキャプチャし、アプリケーションの監視方法を細かく調整しましょう。 高トラフィックの本番環境では、テレメトリはユーザー体験への最も直接的なリンクです。Sentry に送られるすべての Span、Trace、Log、Replay は、本番環境で実際に何が起きているのかを高い精度で可視化してくれます。 しかしその可視性から最大限の価値を引き出すには、シグナルとノイズをどう切り分けるかを理解しておく必要があります。安定したレガシールートにおける通常の「ページ読み込み」を、チェックアウトフローや新機能リリースのような重要な体験と同じ強度で扱っていては、収集するデータを最適化できているとは言えません。 スケールしても持ちこたえ、クォータも圧迫しないオブザーバビリティ戦略を構築するには「一律サンプリング」を超えていく必要があります。重要な箇所や変化の速い箇所では高解像度のデータを優先し、安定しているシステムでは設定を最適化する必要があります。 すべてを100%サンプリングすればいいのでは？ 可能です！ アプリが小規模だったり、まだ新しかったりするなら、それが実際に正しい方針である場合もあります。しかしスケールしていくにつれ、「すべてを100%」はたいてい現実的な選択肢ではなくなります。 理由はいくつかあります。 シグナル対ノイズ（Signal-to-Noise）: テレメトリデータはひと目で何が起きたかわかるときに、より役立ちます。チェックアウト中にユーザーが問題を経験した100件を見つけるために、100万件の「ユーザーがボタンをクリックした」span を解析しなければならないのは、あなたにとっても、クエリにとっても、そして私たちと同じ情報を利用する可能性のあるLLMにとっても、効率的ではありません。 ネットワーク負荷（The Network Footprint）: SDKは高度に最適化されていますが、あらゆる操作、あらゆる関数呼び出しは、積み重なると負荷になります。必要なものだけをサンプリングすることで、価値ある情報を収集しながら、高いパフォーマンスを維持できます。 基本の調整項目：静的サンプルレート Sentry を初期化する際には、送信するデータ量を調整するための主要なオプションが4つあります。まず最初のステップはそれぞれがどう連動するのかを理解することです。 sampleRate：エラー向けです。何かが壊れたら、毎回必ず把握したいので、私たちはほぼ常にこれを 1.0 のままにしています。 tracesSampleRate：トラフィックの一断面を取得します。パフォーマンスデータの量を管理するための主要な調整レバーです。 replaysSessionSampleRate：セッション開始時点から、セッション全体を記録します。高精細（high-fidelity）なので、通常は「平均的な」ユーザーがどうナビゲートしているかを見るには、ごく小さい割合で十分です。 replaysOnErrorSampleRate：バッファです。エラーが発生した場合にのみリプレイを送信し、エラーに至るまでの 60秒間 のアクティビティを記録します。 精密な制御：tracesSampler Trace は私たちが持つ指標の中でも特に重要である可能性が高く、パフォーマンス監視、エラー監視、そしてすべてのデータを相互に結びつける役割を担っています。本番環境では、トレースの100％をサンプルすることがほとんどの場合推奨されます。しかし、特にトラフィックが非常に多いアプリケーションでは、戦略的にトレースするのであれば、すべての Trace を収集する必要はありません。 一律の割合を指定する代わりに、Sentry では tracesSampleRate に tracesSampler 関数を渡せます。これにより、リクエストのコンテキストに基づいて、リアルタイムに判断を下せるようになります。
- [【Next.js SDKがTurbopackに対応】少ないコードで高速ビルド、テレメトリーはそのまま](https://ichizoku.io/sentry/turbopack-support-next-js-sdk/) - Article by: Sergiy Dybskiy 要約：Next.jsでTurbopackがデフォルトとなったため、バンドラーに依存しないようにSDKを再構築しました。その結果、コード量の削減、ビルドの高速化、そしてこれまでどおりのテレメトリーを実現しました。このブログでは、その過程を説明します。 何年もかけてツールを構築してきたのに、支えていたものが突然非推奨になり、アプローチ全体を見直さなければならなくなる。そんな経験はありますか？ そして念のためですが、これは Ralph Wiggum の話ではありません。私たちのコミュニティで合意してその名前で続けることにした、再帰エージェントプラクティスについての話でもありません。 これは、Next.js が Turbopack を展開し、Webpack を非推奨にしたこと（Next.js v16 からは Turbopack がデフォルトになっています）、SDK におけるテレメトリアプローチを見直したことについてです。 以前の状況 以前は next build を実行すると、Webpack ローダーがすべてのページ、API ルート、ミドルウェア、サーバーコンポーネントを横取りしていました。 このローダーは次のことを行っていました。 ファイルを解析し、タイプを判定する Rollup を使用し、 Sentry ラッパーテンプレートとバンドルする 元のコードを計装済みのバージョンに置き換える これはうまくいきました。しかし、それには6種類のラッパーテンプレート、360行の Webpack ローダー、約1,667行の計測コードを維持する必要がありました。Next.js の新機能が追加されるたびに、サーバーコンポーネントやルートハンドラー、App Routerといったものに対して新しいテンプレートを書く必要があり、Webpackの内部が最後に確認したときから変更されていないことを祈るしかありませんでした。 私たちは、すべてのファイルに「Sentryでラップされたドッペルゲンガー」が存在する並行世界を構築していました。こういったアーキテクチャはうまく機能する時には良いのですが、うまくいかなくなると、どの層が壊れたのかを追うのは至難です。 現在の取り組み Next.js には、組み込みの OpenTelemetry 計装機能があります。これにより、すべてのリクエスト、ミドルウェアの実行、レンダー処理ごとにルート情報つきの スパン を出力します。コードをラップする代わりに、それを受け取るようにしています。 上のスニペットは「きれいなバージョン」です。実際には、標準の
- [【Log Drains 提供開始】プラットフォームログを直接Sentryへ](https://ichizoku.io/sentry/log-drains-now-available/) - Article by: Allison Rogers, Paul Jaffre Sentry は Log Drains に対応しました。これにより、アプリケーションコードの変更や手動でのプロジェクトキー検索をすることなく、簡単にログを Sentry へ転送できます。すでに別の場所にログがある場合でも、コード変更なしで、Sentry上でエラーやトレースと並べて確認できるようになりました。 すぐに試したい方は、クイックスタートガイド をご確認ください。 ログを1か所に集約し、Issue のコンテキストと関連付ける 2025年9月に Sentry で Logs を一般提供した際の目的は、ログ、トレース、エラー、リプレイを単一のプラットフォームで確認できるようにすることでした。そしてフィードバックで特に多かったのは、「適切なログが適切な Issue にデフォルトで紐づいていてほしい」という点でした。 「Sentry をアプリに統合したところ、急に「もうひとつ目が増えた」ように感じています。私たちは Logs にも活用していて、デバッグが大幅に楽になりました。Sentry がエラーを報告すると、関連するログがその場ですぐに確認できます。もうひとつ大きな利点は、各ログエントリにユーザー情報が自動でタグ付けされることです。そのため手作業で付ける必要がありません。」 Log Drains を使用することで、プラットフォームのログ（およびトレース）が自動的に Sentry に流れ込み、アプリケーションコード外のプラットフォームレベルのイベントにも「もうひとつの目」が届くようになります。 「例を見せてほしい」と思った方は DevEx チームが Sentry で Vercel ログについて説明する動画をご覧ください。 アプリケーションのエラーやトレースと一緒にプラットフォームのログを一箇所に集約することで、チームはビルド、デプロイ、エッジランタイム、データベース、認証レイヤーにわたるシステムの動作を全体的に把握できます。追加のエージェントを実行したり、アプリケーションコードに触れたりする必要はありません。 ダッシュボードを行き来したり、ログの保持期限が短いせいで大切な情報を失ったりすることなく、エンジニアは Sentry上でエンドツーエンドに問題を調査できます。 今すぐ始める：すべてのプランで5GBのログが含まれています（追加分は1GB$0.50）。 チームはどのように Log
- [Next.js は最初からリクエストをトレースしている ー OpenTelemetry でエクスポートする方法](https://ichizoku.io/sentry/nextjs-export-traces-opentelemetry/) - Article by: Kyle Tryon （読了時間：7分） トレースは情報の宝庫であり、あなた自身、あるいは AI が遅いページを見つけて修正する助けになります。 Next.js は標準で トレーシング をサポートしています。受信リクエスト、fetch() 呼び出し、ミドルウェア、サーバーサイドレンダリングはすべて配線済みで、OpenTelemetry 互換のバックエンドにトレースを送信する準備が整っています。 ただし落とし穴があります。エクスポーターを設定しない限り、それらのトレースを目にすることはありません。 数行のコードと @vercel/otel ライブラリの助けを借りれば、アプリケーションは OpenTelemetry データを受け付けるあらゆるプラットフォーム（Sentry を含む）にトレースをエクスポートできます。（また OTLP と Sentry SDK のどちらを選ぶべきか迷っている方のために、その点についても解説します。） なぜ Next.js のトレースが重要なのか Next.js アプリのページが遅いとき、難しいのはリクエストのどの部分が原因なのかを突き止めることです。原因はミドルウェアかもしれませんし、サーバーサイドレンダリング、API ルート、データベースクエリ、上流への fetch() 呼び出し、あるいは自分で書いたカスタム関数かもしれません。 リクエストが実際にどう実行されたかのトレースがなければ、症状から逆算して作業を進めることになります。ローカルで再現し、ログを追加し、ボトルネックになりそうな箇所を推測し、本番環境が自分のマシンと同じ挙動をすることを願う、という具合です。 トレーシングを使えば、各 API 呼び出し、ページロード、データベースクエリなどが、実行タイムライン上の スパン として記録されます。トレースは 1 つのリクエストから生まれたすべてのスパンをウォーターフォールとしてまとめるため、どこで時間が費やされたかを正確に確認できます。 このトレースでは、最上位の GET /api/auth/[...nextauth] スパンが受信リクエストを表しています。その下に、Next.js がリクエストの各ステップごとに追加のスパンを作成します。ページコンポーネントの解決、API ルートの実行、レスポンスの開始といった具合です。この完全な階層構造があれば、そのリクエスト中にどこで時間が費やされたかを正確に把握できます。 Node ランタイム では、このタイムラインを独自のカスタムスパンで拡充し、各トレースにアプリ固有のコンテキストを追加していくことになります（具体例は後ほど紹介します）。 Edge ランタイム
- [【Seer】開発の全工程でAIデバッグ](https://ichizoku.io/sentry/seer-debug-with-ai-at-every-stage-of-development/) - Article by: Indragie Karunaratne Seer という AI デバッグエージェントを立ち上げた際、ある中核的な信念に基づいて構築しました。現実のソフトウェアにおける複雑な障害モードを理解するには、本番環境のコンテキストが不可欠だという信念です。Seer は Sentry が収集する詳細なテレメトリー（エラー、スパン、ログ、メトリクスなど）を利用して、的確にバグの根本原因を特定し、修正します。このテレメトリーはトレースで紐付いているため、Seer は問題に関連するすべてのデータを決定的にたどることができ、曖昧な時間範囲検索に頼る必要がありません。 コーディングエージェントはソースコードを読むことで見つけられるバグもありますが、実行時の挙動を観察してはじめて、信頼性をもって特定できるバグもあります。分散システムでは、障害がネットワークの境界を越えて広がることがよくあります。健全でないサービスがタイムアウトや他の場所での連鎖的な障害を引き起こすことがあり、負荷がかかったときにのみ発生する問題も存在します。パフォーマンス特性を理解する場合も同様です。例えば、p95のレイテンシスパイクは、ロックの競合や接続プールの飽和、またはコードからは明らかでない他の根本原因に起因している可能性があります。実行時のコンテキストは、Seerがこうした現実世界の問題を正確に診断して解決するために必要な証拠を提供します。 本番環境でのバグ修正は常に重要なユースケースですが、最良のバグとは、そもそもリリースされないバグです。 今日は、ローカル開発やコードレビューの段階でもデバッグできるように Seer の機能をシフトレフトで拡張し、あわせて無制限利用を可能にする新しい定額料金も導入します。 ローカル開発中にデバッグを行う バグは導入された瞬間に修正するのが最も簡単です。Sentry MCP サーバー は、強力なデバッグフィードバックループを通じて、ローカルのコーディングエージェントを接続します。これにより、コードレビューや本番環境ではなく、開発中に問題を発見し解決することができます。ローカルでバグを再現すると、テレメトリがアプリケーションから Sentry に送られ、エージェントはコンテキストのための生のイベントにアクセスしたり、Seer を呼び出して完全な根本原因分析を実行することができます。コーディングエージェントは、コードがローカル環境を離れる前にパッチを生成するために必要なすべての情報を得ることができます。 本物の欠陥を発見するコードレビュー それでも、ローカル環境ですべてを捕まえられるわけではありません。すり抜けたバグに対しては、コードレビューのタイミングで Seer が介入し、プルリクエストに含まれる問題をマージ前に特定します。Seer が重視するのは、本番環境を壊しかねない実害のあるバグを見つけることです。信号の弱い提案やスタイルに関する些細な指摘には注力しません。レビューの段階でこうした欠陥を見つけ出すことで、インシデントは減り、リリースは速くなり、本番環境でのデバッグに費やす時間も短くなります。 すでに Seer をお使いの場合は、GitHub連携をインストールし、Seerの設定で GitHub リポジトリを接続して、コードレビュー機能をセットアップしてください。 本番環境での根本原因分析を自動化する これらの安全策を講じていても、いくつかのバグは本番環境に到達します。その際、Seer は最も対処しやすい問題を特定し、実行時のテレメトリを自動的に利用して、裏で根本原因を特定します。Seer がある問題を対処可能であると高く確信した場合、さらに踏み込んでバグを修正するコード変更を生成したり、Cursor などのコーディングエージェントに委任して、代わりに修正を実行させることもできます。 未知を調査 Sentry がすでに問題を特定している場合、Seer の自動根本原因分析は効果的に機能します。しかし、時には Sentry がフラグを立てたバグが原因ではない問題もあります。たとえば、顧客から「何かおかしい」という報告があったり、ダッシュボード上でメトリクスが望ましくない方向へ推移していたりすることがあります。こうした構造化されていない調査に対して、私たちは新しい実験的機能を開発しています。それは、Sentry
- [Sentryでマイクロサービスと分散システムを監視](https://ichizoku.io/sentry/monitoring-microservices-distributed-systems-with-sentry/) - Article by: Richard C. 5つのサービス、キュー、そして自分が所有していないデータベースに触れるリクエストをデバッグしようとしたことがあるなら、分散システムの監視がなぜ難しいのかはすでにご存じでしょう。 ログはそれぞれ別の場所に存在し、リクエストはフローの途中で見失われ、そして本番環境で何かが壊れると、断片から何が起きたのかを再構成することになります。 マイクロサービスは設計上これをさらに悪化させます。1つのリクエストが、小さく独立してデプロイされる複数のサービスへと広がり、しばしば非同期にやり取りします。そして、リクエストが自分が管理しているサービスを離れた瞬間に、可視性は通常、急激に落ち込みます。 このガイドでは、Sentry のトレーシングとロギングを使ってリクエストをエンドツーエンドで追跡し、本番環境では通常あまりに時間がかかりすぎる次の疑問に答えられるようにする方法を紹介します。 このリクエストは実際にどこへ行ったのか どのサービスが遅延させたのか、あるいは失敗したのか ログを手作業でつなぎ合わせずに、それをどうやって確認すればよいのか 前提条件 マイクロサービスの経験は不要です。この記事を理解するうえで、Web サービスを書いた経験があると役立ちます。 チュートリアルに沿って進めるには以下が必要です。 Docker：サンプルアプリの実行に Docker を使用します。Docker を使うことで、プログラミング言語の各種バージョンをインストールしなくても、どのOSでもアプリが動くことが保証されます。また、個人ファイルから安全に隔離されたセキュアなサンドボックス内で実行できます。 Sentry アカウント：サンプルアプリケーションを Sentry のプロジェクトのいずれかに接続したい場合、Sentry アカウントが必要です。 また少しわかりやすくするために、実行が必要な操作には ▶️ を付けています。 サンプルケーススタディ この例は意図的にシンプルにしていますが、実際のシステムはもう少し複雑です。 ただし失敗の起こり方は同じです。リクエストは複数の先へ広がり、処理は非同期に進み、何かが壊れると元のコンテキストはたいてい失われています。 では簡単な例を使って、マイクロサービス設計がどのように、そしてなぜ機能するのかを確認しましょう。たとえば、ユーザーが「作る必要のある商品」を注文できるウェブサイトがあるとします。商品は物理的な3Dプリントの物体から、デジタルの納税証明書まで、何でもあり得ます。 現時点ではプロセス全体を処理し、すべてのデータを1つのデータベースに保存するモノリシックな Web サーバーがるとします。 設計は次のとおりです。 ウェブサイト、注文管理、そして商品の製造（工場側）をそれぞれ別のチームが担当しており、各チームはシステム全体を壊さずに、自分たちのコードやデータベースのテーブルに対する改善を独立してデプロイしたいと考えています。 そこで単一のサービスとデータベースを3つの独立したサービス（web、order、factory）に分割することにしました。 システムは次のようになります。 各サービスは他のサービスのアドレス（URL）を把握しています。たとえば order サービスが factory サービスに商品の製造開始を依頼したい場合、order サービスは HTTP の POST
- [正常に見えるダッシュボードに潜む危険信号](https://ichizoku.io/sentry/green-dashboards-red-flags/) - Article by: Milin Desai 最近、ある企業の開発責任者（会社名は出せないのですが）からこんなふうに言われました。 「あなたのおかげで、本当にユーザーに影響を与える問題を見つけて解決できました。次は、それが標準的な SLO やシステム指標よりも重要だということを CTO に納得してもらう必要があります。」 CTOがシステムと基本的な稼働時間を測定するのは間違いではありません。ただ、それは基準線にすぎません。だれもがあらゆるものを監視しようとしていますが、ユーザーに関係することについては何も見えていないのです。 従来型モニタリングの罠 稼働率は素晴らしい。レイテンシはSLOの範囲内。エラーバジェットも問題ない。ダッシュボードは緑一色。 それでも、ユーザーはまだ失敗しています。システムが落ちているからではありません。システム自体は問題ないのです。けれども「ユーザーがボタンをクリックする」から「ユーザーが欲しかった結果を得る」までのどこかで、何かが壊れました。静かに。 アラートは出ない。しきい値も超えない。ただ、ユーザーが諦めて離脱しただけです。 コードは壊れます。そこが問題の核心ではありません。問題は、それが3週間後に発覚することです。大口の顧客が苛立って離脱しそうになり、営業チームがエスカレーションして初めて分かるのです。 マネーモーメント どのプロダクトにも「マネーモーメント」がいくつかあります。ユーザーが成功できるか、あるいは収益を失うかを左右する、プロダクト内の特に重要なポイントです。「APIは落ちていないか」でも「ページは読み込めたか」でもありません。ユーザーが本当にやりに来た「その行為」のことです。 最近聞いた例をいくつか挙げます。 ある小売企業はブラックフライデーを完璧な稼働時間で乗り切りましたが…コンバージョン率が12%も下がってしまいました。マネーモーメントである「購入手続きの完了」が、特定のブラウザ拡張機能を使っているユーザーで機能していませんでした。サーバーエラーはなし、アラートもなし。3週間分の売上を失いました。修正にかかったのは1時間ですが、問題に気づくまでには非常に長い時間がかかりました。 ある決済企業はすべてのSLOを満たしていましたが…顧客から「ランダムに失敗する」という苦情がありました。マネーモーメントである「送金が実際に完了し、確認まで終わること」が、国際送金では断続的に失敗していたのです。原因はタイムアウトのエッジケースで、ダッシュボードには平均値しか表示されていませんでした。影響を受けていたのはユーザーでした。修正は6行のコードで済む内容でしたが、何か月分ものノイズの下に埋もれていました。 あるB2Bプラットフォームはどの指標でも健全に見えていましたが…ところが、マネーモーメントである「新規顧客が“なるほど”と実感する瞬間」が、特定の設定を持つエンタープライズアカウントで壊れていました。監視より先に営業がそれを見つけました。ダッシュボードはどれもシステムが「稼働中」だと言っていましたが、プロダクトは壊れていたのです。 毎回、同じパターンです。 測っている対象が間違っています 違いはこうです。 多くのチームが測っていること すべてのサービスは動いているか 指標はしきい値の範囲内か システムは健全か 本当に重要なこと ユーザーは目的を達成できたか できていないなら、どのコードが壊れたのか どれだけ早く直せるか 前者は横方向です。あらゆるものを監視して、何かを拾えることに期待する。 後者は縦方向です。マネーモーメントをエンドツーエンドで追う。壊れたらすぐに分かる。リリースまでたどる。修正する。 両方を行うこともできます。もしダッシュボードが緑でもユーザーが失敗しているのであれば、何が欠けているかがわかります。 実践するべきこと 複雑ではありません。 マネーモーメントに名前を付けましょう50もの異なるフローではなく、プロダクトが機能するかどうかを左右する3〜5つのポイントを特定してください。ユーザーにとって重要で、彼らが目的を達成できるかどうかを左右する瞬間です。ユーザーが成功する瞬間、離脱する瞬間はどこでしょうか。 セグメント別に監視しましょう平均ではなく、顧客ティア別、地域別、デバイス別、リリース別です。最大の顧客を混乱させるバグは、集約されたメトリクスには現れません。 リリースと結びつけましょうマネーモーメントが失敗した場合、最初にすべき質問は「何が変わったか」です。数分で答えられないようであれば、目を閉じたまま飛んでいるようなものです。 アラートまでの時間ではなく、修正までの時間を測りましょう誰もダッシュボードがどれだけ早く真っ赤になったかには関心がありません。壊れたコードをどれだけ早く発見し、修正をリリースできたかが重要です。
- [【Duolingo】アラート疲れを減らしてデバッグを12倍高速化](https://ichizoku.io/sentry/customers-duolingo/) - Duolingo は世界をリードする語学学習アプリであり、毎月何百万人もの学習者に、魅力的なレッスン体験を提供しています。ミッションはシンプルです。世界最高の教育をつくり、誰もが利用できるようにすること。 舞台裏では 200以上のマイクロサービスと、1日に複数回のデプロイを伴う高速なリリースサイクルがこれらの体験を支えています。これほど複雑なシステムを運用する以上、Duolingo は見逃されたバグや遅い問題解決がプラットフォームや「学習者第一」のミッションを損なわないようにする必要がありました。 暫定対応、分断されたデバッグ、生産性のボトルネック Sentry 導入前、Duolingo は同社のスケールに対応できるよう設計されていない従来型のエラー監視ツールに依存していました。その結果、煩雑なデバッグワークフローとUIがエンジニアの不満を招き、生産性を制限していました。 遅いデバッグ： 情報の検索は1回のクエリでも最大30分かかることがありました。さらに同時にクエリできるのは1人のエンジニアだけで、チーム全体に強いボトルネックが生まれていました。 ノイズ過多： 有効なフィルタリングやグルーピングがなく、無関係なデータが大量に流れ込み、重要な問題に集中することが難しくなっていました。 検索機能の制約： 短期的なスパイクのような細かなエラートレンドは、特定がほぼ不可能でした。エンジニアは手作業に頼ったり、勘に頼って原因を探したりすることがよくありました。 使いにくさと属人化： UIが扱いづらく、利用は経験豊富な少数のエンジニアに限られていました。その結果、「パワーユーザー」への依存が生まれ、他のメンバーは貢献に必要なツールやコンテキストを得られない状態でした。 コンテキストと可視性の不足： 取得できるメタデータが最小限で、エラーと根本原因の相関も弱かったため、開発者は複数の情報源からコンテキストを寄せ集める必要がありました。こうしたコンテキストの切り替えが解決までの時間を延ばし、生産性を下げていました。 さらに悪いことに、この従来ツールでは課題をすべて解決できず、ワークフローに重要な穴が残っていました。チームは暫定対応を素早く出せてはいましたが、それは場当たり的な対症療法になりがちで、根本原因は未解決のまま残り、同じ問題が後から何度も再発することがありました。 「単純なデバッグですらマラソンのように感じました。ツールが分かりにくく、デバッグできるのはパワーユーザーだけで、他の人は簡単に理解できなかったのです。全員にとってデバッグを効率化するためのツールがありませんでした。」と、Duolingo の Staff Site Reliability Engineer である David Amin 氏は言います。「単に時間を無駄にしていたという話ではありません。すべてのエンジニアが、素早く問題を解決できるという自信と能力を持つためのツールがなかったのです。」 システムとチームの複雑さが増すにつれ、Duolingo は、よりスケーラブルで開発者にやさしいエラー監視とデバッグのアプローチを求めるようになりました。 Duolingo が Sentry を選んだ理由：実装の簡単さ＆インサイトまでの時間の短縮 選択肢を評価した結果、Duolingo は最小限のセットアップで最大の課題に対処できることから Sentry を選びました。分かりやすい導入と開発者中心の設計により、チームは採用しやすく、すぐに効果を得られました。 200以上のマイクロサービスを2週間未満で移行： Sentry のAPI、Terraform 対応、分かりやすい設定により、200以上のマイクロサービスをわずか2週間で移行できました。 解決までの時間を12倍高速化： リアルタイムクエリ、直感的なダッシュボード、深いコンテキストにより、エンジニアはノイズを素早く絞り込み、トレンドを可視化し、問題箇所を特定できました。すべてを1つのツール内で完結できます。以前は原因の特定がほぼ不可能で、何時間、場合によっては何日もかかっていました。いまは数分の話です。 ノイズ削減： 組み込みのグルーピング、フィルタリング、Spike Protection、オーナーシップルールにより、ノイズを取り除き、重要な問題だけを検知して適切なチームへルーティングします。これによりアラート疲れが軽減され、重要なエラーに集中できます。さらに明確さを得たことで
- [【Anthropic】600人以上のエンジニア＆1つのツール。Anthropic の Sentry ストーリー](https://ichizoku.io/sentry/customers-anthropic/) - 世界でも Anthropic が日々取り組んでいる課題ほど技術的に複雑な挑戦に取り組むチームはそう多くありません。 AIとAI安全性研究の最前線で働くAnthropic の日々の業務には、想像を絶する規模のデータセット、大規模な分散ジョブ、そして高度に専門化されたハードウェアが関わっています。同社のエンジニアは GPU メモリの制約から最下層レベルでの計算最適化まで、あらゆる課題に取り組みながら、ほんの少し前までは考えられなかった種類のコードを継続的にリリースしています。 システムの複雑さが増すにつれて、問題が発生した際の修正も一層複雑になります。 Anthropic の既存のインフラストラクチャーモニタリングツールが追いつかない状況になったとき、彼らはSentryを導入して、より迅速に問題を見つけて修正することにしました。バグやクラッシュを早く取り除くことができれば、本当に重要な研究に注力する時間が増えます。 「Sentry は Sonnet の開発を進める上で重要な役割を果たしました。」と、Anthropic のシステムリードを務める Nova DasSarma が、同社の最も先進的なAIモデルの1つに言及しながら語っています。 課題：圧倒的なログ量 AI研究では、時間は単なるコストではなく「前進」そのものです。業界の最前線で取り組むなら、バグの特定と修正に何日もかけている余裕はありません。 「1つのノード障害が、数百、あるいは数千台のサーバーに影響することがあります… Sentry 導入前は（多くはハードウェア故障が原因で）クラッシュループに陥ることがよくありましたが、不良ハードウェアを排除するためのノードレベルのテレメトリがありませんでした。」ー Nova（システムリード） インフラが拡大するに伴い、問題も増加しました。 既存のモニタリングツールが処理しきれない圧倒的なログ量 ノードレベルのハードウェア問題の可視性がない 分散システム間でエラーを関連付けるのが難しい エラーが発生したときに最初に誰が知るべきか、エラーの所有権を追跡する能力が限られている トレーニングしていたモデルが大規模化するにつれて、これらの問題は深刻化しました。数千の GPU が同時に稼働する中で、デバッグに費やす1分1秒がリソースの浪費と研究の停滞につながります。 「私たちは、デバッグに数日かかる障害にぶつかっていました。何千台ものサーバーが関わる中で、それをSentryで“数時間”に短縮できたことは、大規模トレーニングジョブを効率よく回し続けるうえで決定的でした」ー Nova（システムリード） 小規模なジョブでは問題なかった既存のセットアップは、この規模には適していませんでした。 「以前のツールは厳しいスロットル制限があり、生成されるログの量が多すぎて処理しきれませんでした。」ー Nova（システムリード） 彼らが求めていたのは、このスケールに対応でき、失敗を手作業でつなぎ合わせなくてもよいリアルタイムのデバッグソリューションでした。 解決策：スケールした状態での即時可視化 Anthropic の機械学習インフラは、小さな障害がすぐに大きな混乱へと発展する規模で動いています。Claude 1 のトレーニング時点でも、既存のインフラ監視は追いつけなくなっていました。 「これは、それまでで最大のジョブでした。以前はほとんどのジョブが数ノードで完結していました。でも大規模モデルを学習させると、1つのノード障害が数千台のサーバーに影響します。」ー Nova（システムリード） 以前の会社で Sentry を使ったことのあるメンバーもいました。そのため、GPU クラスターで連鎖的障害が起き、デバッグがほぼ不可能になったとき、Sentry
- [【GRIN】Sentryで3ツールを1つに。デバッグを20倍高速化](https://ichizoku.io/sentry/customers-grin/) - Grin は、ブランドがクリエイターと本物の関係を築けるよう支援する、急成長中のインフルエンサーマーケティングプラットフォームです。事業が拡大するにつれて、エンジニアリングチームはある課題に直面しました。オブザーバビリティのスタックが分断され、摩擦が生まれ、開発スピードが落ちていたのです。 ツールが多すぎて、シグナルが足りない Sentry 導入前、Grin はスタック全体をカバーするために、3つのオブザーバビリティツールを組み合わせて使っていました。この構成でパフォーマンスとエラーの監視はできていましたが、明確さよりも混乱が増える状態になっていました。 「当時はインフラ用ツール、APM ツール、それからクラッシュレポート用ツールがありました」と、Grin の シニアエンジニアリングマネージャーの Jorge は話します。「使い方によっては重複するツールが3つあるようなものです。集約したかったですし、ツールの力を最大限に引き出して使いたかったんです。」 既存のエラートラッキングツールはノイズが多く、パフォーマンス問題はさらに厄介でした。 「フラストレーションが溜まりました。たとえば、遅いデータベースクエリがエンドユーザー体験にどう影響しているか。のような基本的なパフォーマンスの疑問に答えるだけでも、ログ、メトリクス、トレースを手作業でつなぎ合わせる必要がありました。」 5分で元が取れた理由 Sentry を置き換え候補として、社内でデモをしていた Grin のメンバーが数名いました。そのデモの最中に偶然が起きます。デモ用に擬似エラーを仕込んでいたわけではなく、実際のバグが現れ、それをその場で追跡して解決できたのです。 Sentry により、特にそのページを頻繁に使うユーザーの読み込みが異常に遅いことが分かりました。パワーユーザーでは読み込みに 50 秒以上かかり、場合によってはまったく表示されないこともありました。 Session Replay と Tracing を組み合わせることで、チームは実際のユーザーセッションを確認し、どの瞬間に、どこで遅くなっているのかを正確に特定できました。しかも5分以内に問題が見つかったのです。 「ページをリロードして、リプレイを見て、リクエストを見て、それからトレースを確認するだけでした。」と Jorge は振り返ります。「たった5分で問題が何かが分かりました。」 修正はシンプルでした。ページの一部を非同期で読み込むようにしたことで、読み込み時間は 50秒から10秒未満 に短縮されました。80% の改善です。 「Sentry に Session Replay と Tracing があることを知りませんでした。」と Jorge は認めます。「会話はすぐに、切り替えるべきか。から、どれだけ速く進められるか。へ変わりました。」 Jorge の見積もりでは本来なら丸1週間のデバッグが必要だったものが、1回のミーティングで解決しました。 「Sentry のデモをしただけで元が取れました。」 オーバーヘッドのないオブザーバビリティ：Grin が Sentry を選んだ理由
- [【Flo】毎日50回デプロイしても品質が落ちない理由](https://ichizoku.io/sentry/customers-flo/) - 要約世界をリードする女性向けヘルスケアアプリを手がける Flo Health は、Sentry を活用して「素早くリリースし、さらに素早く修正」しています。モバイルとバックエンドを横断するフルスタックの可視化により、Flo は問題が本番に到達する前に検知し、パフォーマンスをリアルタイムで追跡し、世界中の数百万人のユーザーのエンゲージメントを維持しています。しかも、1日50回以上のデプロイというペースを落とすことなく実現しています。 結果 主要トランザクションの重要リクエストにおける処理速度を 50% 向上 数百万人のユーザー規模で 99.9%+ のクラッシュフリー率を維持 自信を持ったモバイルロールアウトと迅速なロールバック戦略を可能に 品質や可視性を犠牲にせず、バックエンドを 約50回/日 デプロイする運用を支援 「アプリが遅ければ、ユーザーは待ってくれません。すぐに離脱します。Sentry を使ってパフォーマンスをデバッグし、監視することは、ユーザーをアプリ内に留め、利用を継続してもらううえで、私たちの成功を支える重要な要因です。」ー Vaidas Zlotkus（エンジニアリング・ディレクター） バックエンドのデプロイからエッジのレイテンシまで：1億人超のユーザーに対する「応答性」をデバッグする Flo は世界で最も広く利用されている女性向けヘルスケアアプリで、AI によるインサイトと医療専門家によるレビュー済みコンテンツを複数言語で提供しています。インフラはバックエンド主導の UI を支え、数万本に及ぶコンテンツ記事を提供し、バックエンド更新を高頻度で配信しています。 その回数は 1日最大50回 にもなります。この規模でアプリの速度と安定性を確保することは、単なる技術目標ではなく、事業上の必須要件です。 世界中にユーザーがいる Flo は、地域やデバイスを問わず、応答性・データ保護・信頼性に関して高い基準を満たす必要があります。そのためには問題を検知し、強固なプライバシー保護とデータ最小化の保護策を適用し、チームがそれに対して迅速に行動できるようにする、堅牢なオブザーバビリティツールが求められます。 Sentry はそのためのフルスタック可視性を提供します。 Flo が Sentry を使って高速で安定したアプリを提供する方法 1. プロアクティブなリリース監視とクラッシュ管理 Flo のエンジニアはモバイルのロールアウトにおける「最初の防衛線」として Sentry を活用しています。段階的デプロイとバージョンごとに異なるユーザーの採用率がある中で、リグレッションを早期に検知すること、つまり深刻化する前に止めることが重要です。 「モバイルで 5% ロールアウトを行うとき、Sentry を確認するのはリリースチェックリストの一部です。この方法で重大な問題を捕捉し、ユーザーベースに影響する前に悪いリリースを止められました。」—
- [本番環境で大規模データセットをページネーションする：OFFSETの限界とカーソルの利点](https://ichizoku.io/sentry/paginating-large-datasets-in-production-why-offset-fails-and-cursors-win/) - Article by: Lazar Nikolov 、Ben Coe MVP（Minimum Viable Product）と本番環境に耐えるアプリアプリを分ける要素は、仕上げ、最終調整、そしてパレートの法則で言うところの「最後の20%」の作業です。多くのバグやエッジケース、パフォーマンス問題は、リリース後にユーザーの殺到でアプリケーションに大きな負荷がかかったときに表面化します。この記事を読んでいるあなたは、おそらく80%地点にいて、残りを片付ける準備ができているはずです。 この記事では、大規模データセットをスケール環境でページネーションする際に、どこで問題が起こり得るのか、そしてデータベースのインデックスが結果をどう左右するのかを見ていきます。 本番の洗礼（ローンチ後の現実） テスト中はすべて順調でしたが、しばらくするとページの読み込みに時間がかかるようになりました。 このような状況に備えて、Sentry をローンチ前にセットアップしておくことをおすすめします。カスタムのインストゥルメンテーションを何もしなくても、データベースクエリが遅くなったときに Sentry が知らせてくれます。 スクリーンショットには、Sentry での Slow DB Query の問題が表示されています。Drizzle ORM と node-postgres を使用したおかげで、Sentry は自動的にすべてのデータベースクエリを計測してくれました。このテレメトリデータによって、Sentry は遅いデータベースクエリを検出して表示できます。 少しスクロールすると、リクエスト情報が表示されます。 ここから分かることは次のとおりです。 クエリは GET /admin/tickets リクエスト内で実行されています。 OFFSET を含むため、オフセットベースのページネーションです。 実行されたのは 321 ページです。 実行時間は3.85秒でした。 Seer はインデックス不足の可能性が高いと推測しています。 では、実際にインデックスが不足しているのか確認しましょう。 Seer の言った通りでした！大規模なデータセット、データベースインデックスの不足、そしてオフセットベースのページネーションの組み合わせがこの問題を増幅させています。 データベースにインデックスがなく、かつページネーションがオフセットベースのため、今回のように321ページのような高いページ番号に移動すると、データベースは 321 × page_size 行
- [【React Native】Sentry にログを送る](https://ichizoku.io/sentry/logging-react-native-with-sentry/) - Article by: Lewis D. Logs は、開発チームが問題を調査するときに最初に確認することが多い場所です。しかし、Logs は後回しで追加されることが多く、開発者は「ログを出しすぎる／出さなさすぎる」のバランスに悩みがちです。 経験豊富な開発者なら、調査を頼まれて 200MB のプレーンテキストのログファイルを渡された経験を覚えているかもしれません。3 時間と 4 本の Python スクリプトを費やした末に、問題が別のコンポーネントにあると分かる、というようなことです。 これまで、ロギングを簡単にするための多くの標準やライブラリが作られてきましたし、React Native にはロギング関数も豊富にあります。私たちの React Native ロギング入門ガイドは良い出発点です。ただ、さらに一段レベルを上げたいなら、このガイドで Sentry のロギング機能を使う方法を紹介します。これにより、ログが有用になり、必要な情報をすぐに取り出せるようになります。 Sentry に Logs を取り込む このガイドでは、シンプルな React Native（Expo）アプリを使って、Sentry のさまざまなロギング機能の例を示します。 このアプリは、フィールドに基本的なバリデーションがある問い合わせフォームです。手元で同じように試したい場合は、デモリポジトリ内にこのアプリがあります。 デモの React Native アプリのインターフェース 既存の React Native アプリケーションがある場合やこれから作る予定がある場合でも、このガイドでは、Sentry を使ったロギングを最大限に活用するために必要な手順を説明します。 セットアップ Sentry の機能を使い始めるには、まずプロジェクトに Sentry を導入する必要があります。最初に Sentry で新しいプロジェクトを作成し、プラットフォームとして React
- [【Logs と Next.js】壊れたものがすべてエラーとは限らない](https://ichizoku.io/sentry/not-everything-that-breaks-is-an-error-a-logs-and-next-js-story/) - Article by: Sergiy Dybskiy スタックトレースは便利ですが、教えてくれるのは「何が壊れたか」だけで、「なぜ壊れたのか」を教えてくれることはほとんどありません。例外が発生すると、物事が崩れた瞬間のスナップショットは得られますが、そこに至るまでのコンテキストは消えてしまいます。 そこで Logs の出番です。適切な場所に Logs があることで、何時間も悩む羽目になるか、5 分で直せるかの分かれ道になります。最近私が遭遇した実際のバグを例に、その意味をご説明します。 ボットから AI 搭載の Next.js エンドポイントを守る 私は WebVitals という、AI を活用した Next.js アプリケーションを開発していました。ドメインを入力すると、パフォーマンスデータを取得するために一連のツール呼び出しを実行し、その結果を AI エージェントが解析して、Web Vitals を改善するための実行可能な提案を返します。 フロントエンドでは会話のやり取りを扱うために、AI SDK の useChat フックを使っています。 /api/chat エンドポイントは標準的な Next.js の API ルートなので、誰でもどこからでもアクセスでき、各リクエストにはコストがかかります（OpenAI は無料ではありません）。そのため、ボットや悪意ある攻撃者がリクエストを大量に投げて請求額を跳ね上げようとするのを防ぐ仕組みが必要でした。 Vercel にはそのための良い解決策があります。 checkBotId 関数によるボット対策です。受信したリクエストを見て、ボットからのものかどうかを判定します。シンプルで効果的で、ユーザーに横断歩道を選ばせる CAPTCHA も不要です。 Firefox と Safari にだけ影響する本番バグ ローカル開発ではすべて完璧に動いていました。本番にデプロイして、Chrome でテストしても問題なし。ところが、Firefox
- [【Unity SDK 4.0.0】ゲーム機対応、ログ、ユーザーフィードバックなど](https://ichizoku.io/sentry/introducing-gaming-console-support-logs-user-feedback-unity/) - Article by: Stefan Jandl Sentry の Unity 向け SDK 4.0.0 をリリースしました。 これはこれまでで最大のアップデートです。このメジャーリリースでは、ゲーム機への包括的な対応、構造化ログ、ユーザーフィードバック機能、そしてあらゆるプラットフォームでより良いゲームを作るための重要な改善が追加されています。新機能は以下のとおりです。 ゲーム機対応 Unity 向け Sentry SDK は、Xbox と PlayStation をネイティブにサポートするようになりました。 これにより、Sentry のエラートラッキングの全機能がゲーム機にも提供されます。SDK は scope をネイティブ層へ自動的に同期するため、ゲームがゲーム機上でクラッシュした場合でも、取得された issue には C# の適切な行番号を含む完全なスタックトレースが付与されます。 さらに Sentry は、カスタムコンテキスト、タグ、breadcrumbs も提供します。こうした全プラットフォームで統一された体験により、問題がどこで発生したかに関わらず、トリアージと修正が容易になります。 構造化ログ 構造化ログが、Unity 向け Sentry SDK で本番利用可能になりました。つまり、ログ出力がゲーム内のエラー、クラッシュ、パフォーマンス問題に直接つながるようになります。 SDK は設定に応じてデバッグログの出力を自動的に取り込み、Sentry 上で閲覧・検索できる構造化ログエントリを作成します。プレイヤーがシーン読み込み中にクラッシュしたり、ロード画面で止まってしまったりした場合でも、問題に至るまでのログの流れをすべて追えるため、再現が難しい問題の診断が大幅に容易になります。 User Feedback（ユーザーフィードバック） User Feedback のサポートが、Unity 向け
- [【LogTape & Sentry】トレースに紐づく構造化ログ](https://ichizoku.io/sentry/trace-connected-structured-logging-with-logtape-and-sentry/) - Article by: Kyle Tryon アプリケーションがちょっとした個人開発から、多くのユーザーに使われる複雑な分散システムへと成長していくにつれて、従来の console.log に頼ったデバッグ手法では通用しなくなります。本当に観測可能なシステムを構築するには単なるテキストログから、構造化されクエリ可能で、トレースに紐づくイベントへと移行していく必要があります。 要点：ログ戦略の転換 多くの人はログをパンくずのように扱い、各行が実行されたことを確認したり、デバッグのために出力結果を記録したりします。ところが本番環境では、そのパンくずはすぐにノイズの山になります。必要なのは処理の過程を逐一ログに残すやり方から、マイルストーンをログに残すやり方へ切り替えることです。 ノイズを取り除く：ノイズを生み、クエリや相関が難しい「薄い」ログから離れましょう。 高カーディナリティを受け入れる： タスクの進行に伴って積み上がる「厚い」コンテキストをログに詰め込みましょう。ユーザーID、注文ID、カート情報などを含め、任意のイベントについて必要なデータをクエリできるようにします。 点をつなぐ： Sentry を使ってログをトレースに紐づけたままにし、各ログをそれを引き起こした特定のリクエストへ紐づけます。 ログの洪水：なぜ本番環境では console.log が通用しないのか ログが集中管理されなくなり、時系列で追えなくなった瞬間に console.log は破綻します。複数のユーザーとサービスが同時に動く本番環境では、ログはすぐにさまざまなイベントが入り混じったストリームになってしまい、特定の1リクエストについて何が起きたのかを復元する明確な手がかりがなくなります。 関連するログ同士をつなぐ共通のトレースと、フィルタ可能で有用なデータがなければ、こうしたログは本番環境では実質的に役に立たなくなります。 LogTape と Sentry で本番品質のロギングを実装 Sentry はトレースに紐づくロギングを提供します。トレースを使えば、1つのリクエストに関する全体のコンテキスト（そのリクエストに紐づくログも含む）を確認できます。これにより特定の issue やリクエストに関連するトレースとログを簡単にクエリできるようになります。 さらに Sentry Logs には、属性や構造化データをもとにログを検索できる強力なクエリエンジンがあります。そこから検索結果に基づいてアラートやダッシュボードを作成することも可能です。 LogTape はあらゆる JavaScript ランタイム向けの軽量なロギングライブラリです。LogTape のようなロギングライブラリを使うと、コードに計測を組み込み、自動でリッチな構造化ログを出力できるようになります。また「log sink」を使って、それらのログを Sentry に送信できます。 構造化ログとは、単なる文字列ではなく、定義されたプロパティを持つ構造化オブジェクトとしてログを扱う形式です。 これにより本番環境でのデバッグにおいて、ログから必要なデータを見つけて可視化するための強力なクエリやフィルターを作成できます。 LogTape の構造化ログマニュアルからの例 クイックスタート：Next.js
- [2025年もオープンソースのメンテナーに75万ドルを支援](https://ichizoku.io/sentry/another-year-another-750-000-to-open-source-maintainers/) - Article by: Chad Whitacre 2025年も Sentry は日頃から頼りにしているオープンソースのメンテナーに、まとまった金額を拠出しました。これで5年連続（2024、2023、2022、2021）になりました。 これは私たちが Open Source Pledge を立ち上げて以来、最初のレポートです。 この Pledge は、コミュニティの独立したメンテナーに対する敬意を共有する企業を集めるものです。Pledge メンバーは立ち上げ以来、合計で 450 万ドルをオープンソースのメンテナーおよび財団に支払ってきました。もう言い訳はできません。企業がメンテナーに支払う時代は現実です。あなたもこの流れに参加してください。:-) いつもどおり、私たちの主要な配分（37.5 万ドル）の詳細は thanks.dev（TD）で確認できます。 これが一番簡単な方法です。thanks.dev にあなたの会社を登録して、依存しているプロジェクトのメンテナーに支払いましょう。Pledge の最低基準（開発者 1 人あたり年間 2,000 ドル）を満たし、さらにブログで発信してくれれば、私たちはあなたの会社をそのリストに追加します。参加する企業が増えるほど、参加する企業はさらに増え、オープンソースのエコシステムはより強く、よりレジリエントになります。 私たちは引き続き Open Source Collective / Ecosyste.ms Funds（7.5 万ドル）や GitHub Sponsors（5 万ドル）とも取り組んでいます。 thanks.dev と同様に、Ecosyste.ms Funds も複数のプロジェクトをまとめて支援しやすくしてくれますが、特定のエコシステムで私たちが実際に使っている依存関係を見て、どのプロジェクトを使っているかを判定する仕組みはありません。ただし、彼らの全体データは非常に優れているため、私たちは依存しているエコシステム全体に広く支援が行き渡るよう、10% を彼ら経由で拠出しています。 残念ながら、Microsoft はこの 1 年で Sponsors を事実上停止しました。Universe でも Sponsors 関連の発表はなく、AI
- [本番データを活用してバグを予測するコードレビューシステムの構築](https://ichizoku.io/sentry/building-a-code-review-system-that-uses-prod-data-to-predict-bugs/) - Article by: Giovanni Guidini, Kush Dubey, Suejung Shin この投稿では、Sentry の AI Code Review が実際にどのように動作するのかを、より詳しく見ていきます。 Seer（Sentry の AI デバッガー）の一部として、Sentry のコンテキストを使用し、バグを正確に予測します。自動またはオンデマンドで実行され、出荷前に問題点を指摘し、修正案を提案します。 AI ツールはノイズが多くなり得ることを私たちは理解しています。そのためこのシステムは、誤検知や役に立たないスタイル上の指摘で埋め尽くすのではなく、実際の変更内容に含まれる本物のバグを見つけることに焦点を当てています。AI とアプリの Sentry データ（実行状況や、これまでどこで壊れてきたか）を組み合わせることで、将来新しいバグを出荷してしまうことを避けられるようにします。 高レベルアーキテクチャ このコードレビューシステムは、コード分析と Sentry データの両方を用いてバグを検出し、PR に対して提案を提示します。 以下は AI Code Review のアーキテクチャの概要です。 バグ予測パイプライン できる限り高い精度でバグを予測するために、仮説と検証に基づくマルチステップのパイプラインを採用しています。 フィルタリング：このステップでは PR の情報を収集し、PR 内のファイルを、最もエラーが発生しやすいものへ絞り込みます。特に大規模な PR では重要です。 予測：肝となる部分です。ここでは複数のエージェントを実行し、バグの仮説を作成して検証します。 パッケージングと出荷：提案を集約し、フィルタリングと解析を行ってコメントに整形したうえで、PR に送信します。 このあと、パイプラインが実際に動いている様子を示す例として、getsentry/sentry リポジトリのトレースをいくつか見ていきます。 フィルタリング 変更が少ない
- [【Cocoa SDK 9.0.0】リリース！](https://ichizoku.io/sentry/cocoa-sdk-9-0-0-has-landed/) - Article by: Philipp Hofmann Cocoa SDK 9.0.0 をリリースしました。新機能と変更点をご紹介いたします。 前回のメジャーバージョンアップから、ずいぶんと時間が経ちました。前回のメジャーリリースであるバージョン 8.0.0 が公開されたのは、2023年1月16日のことです。その後、57回のマイナーアップデートと47回のバグ修正リリースを経て、ついに新しいメジャーバージョン 9.0.0 をお届けする時が来ました。 なぜ今なのか 私たちの最小サポート OS バージョンはかなり古くなっており、その結果、一部のユーザーが望まないほど多くの Xcode の警告を目にするようになっていました。「互換性は絶対（Compatibility is King）」を少し重視しすぎていたようです。だからこそ、メジャーアップデートを実施し、サポートする最小 OS バージョンを引き上げるのに最適なタイミングだと判断しました。 今回はどのようなリリースなのか バージョン 9 は「メンテナンス系メジャー」リリースです。 具体的には以下の通りです。 最小 OS バージョンの引き上げ いくつかの機能をデフォルトで有効化 多くの細かい API の問題を整理 アップグレードは簡単に行えるはずです。…そう言ってハマるのがお約束ですが。 知っておくべき変更点 バージョン 9 における変更点のほとんどは、「プラットフォーム要件」「デフォルトで有効になった機能」「以前から予定していたクリーンアップ」の 3 つに分類されます。 主要なポイントは以下の通りです。 サポート対象の最小 OS バージョンを更新
- [.NET アプリで AI エージェントをより効果的にモニタリングする方法](https://ichizoku.io/sentry/agent-monitoring-net-apps/) - Article by: Alex Sohn 今年の初めにエージェントモニタリングをリリースし、ユーザーがアプリケーション内での LLM の利用状況やツール呼び出しを計測できるようにしました。ただし当時、エージェントモニタリングに対応していたのは Python と JavaScript のみでした。そこで私たちは、.NET 向けのエージェントモニタリング SDK、具体的には Microsoft.Extensions.AI.Abstractions 向けの開発に取り組んできました。 Sentry.Extensions.AIのご紹介 Sentry.Extensions.AI は、Microsoft.Extensions.AI.Abstractions に基づく .NET の LLM パッケージ用のインストゥルメンテーションレイヤーです。このレイヤーを使用することで、以下の LLM 使用状況を計測できます。 LLM呼び出し 入力・出力 トークン数 モデル名 ツール呼び出しの入出力 LLM 呼び出しに関連する Issue 総コスト これらすべてを Sentry でスパンやイベントとして確認できるため、AI の挙動を他のアプリケーション部分、例えば HTTP リクエスト、バックグラウンドジョブ、データベースクエリなどと関連付けることが可能です。 Microsoft.Extensions.AI.Abstractions とは AI.Abstractions パッケージは、多くの他のライブラリにとっての低レベルな契約レイヤーです。これは .NET における生成 AI 用のインターフェースやデータモデルを含んでおり、他のライブラリによって実装されることを目的としています。依存関係が最小限に抑えられているため、ライブラリエコシステムの基盤として使用できます。 Microsoft.Extensions.AIとは混同しないでください。Microsoft.Extensions.AIには ChatClientBuilder
- [【Seer】Honra がSeer AI Code Review でレビュー時間を75%削減した方法](https://ichizoku.io/sentry/how-honra-cut-their-review-time/) - 5人の開発チームが冗長なレビューをやめ、的確で即時のフィードバックに置き換えることで、より速くバグの少ないリリースを実現 Honra はプエルトリコに拠点を置くスリムな B2B ソフトウェアコンサルティング企業で、クライアントのカスタムプロダクトやインフラ構築を支援しています。 TypeScript・Python・Go を扱う 5人のチームで構成されており、エンジニア一人ひとりが平均以上のインパクトを出すことが求められ、1分1秒が重要になります。この少人数チームが顧客により大きな価値を届けられるようにするため、社長の Marc Maceira Zayas 氏は、高い品質基準を維持したままコードをより速く出荷できる方法を必要としていました。 本記事では、Seer がどのようにして、わずか 1週間で 15,000ドル分のエンジニアリング工数をチームに節約したのかをご紹介します。 課題：レビューが遅く、フローが途切れてしまう Seer を使う前の Honra のコードレビューは、遅くて手作業中心のプロセスでした。Marc さんのチームは、手動テストと PR を一行ずつ読み込むレビューを組み合わせて運用しており、しばらくのあいだはうまく機能していたものの、やがて限界が見えてきました。 「たいていの場合、問題は細部に潜んでいます」と Marc さんは話します。「本来であればもっと早い段階で拾うべき小さなバグを見落としてしまうことがありました。そして、メンバー全員がリリースの責任を負っているので、レビューが長引くということは、新しいコードが出荷されないということなんです。」 そこでまず別の AI コードレビューツールを導入し、レビューの自動化に取り組みました。当初は確かに役立っていましたが、次第に足かせになっていきました。AI が生成するフィードバックは PR 1件あたり 20〜50 分もかかり、本来であれば 3行のコメントで済む内容が、2パラグラフにもわたる長い講釈として返ってくることも少なくありませんでした。 本当に重要な問題を浮き彫りにする代わりに、そのツールは実装の細部について主観的な解説を長々と始めてしまう傾向があり、その結果として生じていたのは、コンテキスト過多による疲労感と混乱です。 「本当は自分の解決策が正しいのに、間違っているのではないかと不安にさせられることもありました。冗長になりすぎて、遅すぎて、ツールとしての役割から外れてしまっていたんです。」 解決策：即時で、すぐ行動につなげられるフィードバック Honra が Seer の AI Code Review を試し始めたとき、その違いにすぐに気づきました。 「最初に動かしたときは、思わず笑ってしまいました」と Marc 氏は話します。「PR
- [【新機能】Web Vitals Performance Issue](https://ichizoku.io/sentry/meet-web-vitals-performance-issues/) - Article by: Ben Coe 新しい種類の Performance Issue として、Web Vitals Performance Issues を導入しました。Web Vitals の指標が、パフォーマンスに関する当社の「meh」または「poor」のしきい値に下がった場合、アプリケーション内の改善余地が最も大きいページを対象に、これらの課題が作成されます。 これらの課題は Seer Issue Fix を念頭に置いて構築しました。私たちの目的は、Vitals スコアの低下を通知するだけではありません。スコアを改善するために取れる具体的な手順を提示し、可能な場合は問題の修正まで支援することです。 Web Vitalsとは？なぜ気にする必要があるのか Web Vitals は、サイトのユーザー体験がパフォーマンスの基準値と比べてどの程度かを把握するための標準指標です。Vitals の良いスコアを持つウェブサイトが必ずしも素晴らしいユーザー体験を保証するわけではありませんが、Vitals の評価が悪いウェブサイトはほとんどの場合、ユーザー体験も悪いと言えます。 とはいえ、たとえユーザー体験の向上にはそこまで関心がないとしても、Web Vitals は Google の検索ランキングや Shopify でのリスティングにも影響します。要するに、ビジネスの成果に直結します 🤑。 中でも、最も重視すべき 3 つの Core Web Vitals は次のとおりです。 Largest Contentful Paint (LCP)：ページ内で最も大きな要素が表示されるまでにどれくらい時間がかかるのかを測定します。読み込み速度の指標。 Interaction to Next Paint (INP)：ページ要素を操作したとき、次のフレームが表示されるまでにかかる時間を測定します。インタラクティビティの指標。 Cumulative
- [【AI 機能アップデート】全 Sentry ユーザー対象](https://ichizoku.io/sentry/sentry-just-got-an-upgrade-and-its-all-free/) - Article by: Lindsay Piper 今回のアップデートでは、また新たなチャットボットを提供するのではなく、チームの時間が浪費されがちな Sentry の箇所に AI を直接組み込み、すでにお持ちのデータを即座に活用できるコンテキストへと変換できるようにしました。 そして本日、すべての Sentry ユーザーが利用できるようになりました。 Trace Explorer で自然言語クエリを使って質問するだけ Trace Explorer は自然な言葉で書かれた質問をそのまま受け取り、実際のクエリに変換できるようになりました。演算子やフィールド名を覚えておく必要はなく、知りたい内容をそのまま言葉で説明するだけで構いません。 たとえば「うちの DB の p90 レイテンシはどのくらい？」のような質問を入力すると、その裏側で必要なクエリが自動生成され、関連する span を特定し、レイテンシの分布を表示してくれます。 構文を書く必要は一切ありません。クエリを組み立てる手間は大幅に減る一方で、これまでと同じ深さのトレースデータにアクセスできます。 Issue の原因にまず「あたり」をつける 新しい Issue に遭遇したとき、最初の疑問はたいてい「どこから手を付ければいいのか？」ではないでしょうか。 各 Issue に表示される Initial guess は、Issue のコンテキストを自動的に解析し、何が問題になっていそうかを初期的に推定します。これにより、ソースコードや追加の Sentry テレメトリを参照して根本原因をより正確に特定する Seer による詳細な分析に進む前の、出発点を提供してくれます。 Session Replay Summaries でインサイトに素早くたどり着く エラーが発生した瞬間にジャンプできること自体は便利ですが、ユーザーがそこに至るまでの経路を理解するには、依然として時間がかかります。長いセッションでは、多数のインタラクションやネットワークコール、UI
- [100ms未満のEC体験　Speculation Rules APIによる瞬時ロード](https://ichizoku.io/sentry/less-than-100ms-e-commerce-instant-loads-with-speculation-rules-api/) - Article by: Lazar Nikolov Eコマースでは、スピードが収益に直結することは、皆さんご存じだと思います。私も知っていますし、皆さんも知っているでしょう。Amazonも、eBayも、Shopifyも、誰もが認識している事実です。この記事では、製品詳細ページやカートページ、チェックアウトページといった重要なページのパフォーマンスをどのように向上させることができるかをご紹介します。Speculation Rules API（SRA）を活用して、これらのページをプリレンダリング/プリフェッチし、さらにNext.jsのような特定のフレームワークが提供する独自のプリフェッチ機構についても説明します。 Speculation Rules API SRAは、現在 Chromiumブラウザでのみ利用可能な実験的な機能で、ウェブサイト側から「ユーザーが次にどのページを訪れる可能性があるか」をブラウザにヒントとして伝えることができます。ブラウザはそのヒントをもとに、あらかじめページをプリロードまたはプリレンダリングし始めます。これにより、そのページへの遷移がほぼ瞬時に感じられるようになります。 プリレンダリングルール（prerender rules）は、ブラウザに対して対象ページを「見えないタブ」の中で完全にダウンロードし、レンダリングし、読み込むよう指示します。これにはすべてのサブリソースの読み込み、すべての JavaScript の実行、さらに JavaScript から開始されるデータフェッチも含まれます。プリレンダリング済みページへの遷移は即座に完了します。文字通り、ブラウザが「すでに完全に読み込み済みのタブに切り替える」だけの動きになります。 プリフェッチルール（prefetch rules）は、ブラウザに対してページのドキュメント本体だけをダウンロードさせます。バックグラウンドでページをレンダリングしたり、JavaScript を実行したり、サブリソースを読み込んだりはしません。ナビゲーション時のメインドキュメントの HTTP リクエストをスキップするだけで、その後のレンダリングやリソースの読み込みは通常どおり必要になります。それでもパフォーマンスは大きく改善されますが、プリレンダリングルールに比べると処理はかなり軽量です。 これらのルールは、ページ内に 要素を追加し、その中で JSON 形式で定義します。 上記の speculation rules によって、そのページ内に存在する /products/* にマッチするすべての URL が積極的にプリフェッチされ、さらに /cart ページも 同様に処理されます。これらのルールをどのように追加するかは問いません。 の末尾にハードコードしてもよいですし、JavaScript でランタイムに動的生成してもかまいません。これらのルールには「締め切り」はなく、ブラウザは DOM 内でルールを見つけた瞬間にプリフェッチやプリレンダリングを開始します。 どれだけ積極的に先読みするかや、さまざまな種類のマッチャーやセレクタ、その他の注意点についてもオプションが用意されていますが、この記事では取り上げませんので、詳しくは必ずMDN の Speculation rules APIのドキュメントを確認してください。
- [【Seer】自動根本原因分析で N+1 クエリ問題を解消](https://ichizoku.io/sentry/fix-n-plus-one-database-issues-with-sentry-seer/) - Article by: Sergiy Dybskiy Shopify で働いていたとき、ブラックフライデーとサイバーマンデーはまさに私たちにとってのスーパーボウルでした。マーチャントの皆さんが1年の中で重要な時期に予期せぬトラブルに遭遇しないよう、数週間も前からコードフリーズに入っていました。それでも、ときには直前になってアップデートをリリースしなければならないこともあります。 たとえば、こんな場面です。 ブラックフライデー前夜の午後 11 時 47 分。50 点以上の商品を割引価格で掲載した新しい /sale ページをデプロイしたばかりです。マーケティングチームはこれから 50 万人の購読者にメールを送ろうとしています。サンプルデータでのテストはすべて問題ありませんでした。 そして午前 0 時 13 分、最初の Sentry アラートが届きます。 問題 /sale エンドポイントの平均レスポンスタイムが 1 リクエストあたり 4 秒以上かかっています。ユーザーはタイムアウトを経験しており、今すぐこの問題を修正する必要があります。 Sentry が問題を検知する Sentry を開いてみると、すでに原因が特定されています。N+1 クエリです。Sentry はトランザクションスパンを自動的に解析し、/api/sale エンドポイントがリクエストごとに 150 回以上の連続したデータベースクエリを発行していることを突き止めました。 Issue の詳細を見ると、典型的なパターンが現れています。 まず最初に全商品を取得するクエリが 1 回実行され、その後に各商品のセール価格、メタデータ、カテゴリ情報を取得するクエリが何度も繰り返し実行されています。典型的な N+1 です。
- [Seer が Cursor Agents を起動してバグを自動修正できるようになりました！](https://ichizoku.io/sentry/seer-can-now-trigger-cursor-agents-to-fix-your-bugs/) - Article by: Jenn Mueng 先日、Cursor Cloud Agent との連携機能をリリースしました。これにより、Seer がバグを見つけたときに、その問題に関して Sentry が持っているコンテキスト一式を添えて Cursor に渡し、修正コードを書いて PR を作成させることができるようになりました。 完全自動＆検証済みのコード修正 これからは、実際に稼働しているコードベース環境の中で、コーディングエージェントを自律的に動かすことができます。しかも、すべてバックグラウンドで実行されます。 Seer が問題を検知し、根本原因を分析すると、その結果と問題のコンテキストを Cursor Cloud Agent に送信できます。 エージェント側では次の情報を受け取ります。 Issue のコンテキスト一式：スタックトレース、ブレッドクラム、ユーザーインパクトなど Seer の Root Cause Analysis：実際に何が壊れているのかに関する詳細な分析結果 あなたの稼働中コードベース：Cursor Cloud Agent は実際のコードベース全体にアクセスでき、コードの実行も可能 あとは、あなたがコーヒーを取りに行っている間に、エージェントが自律的に作業を進めてくれます。戻ってくる頃には、あなたのリポジトリにはエージェントが作成した PR がすでに用意されています。 使い方は 2 通り 手動トリガー 任意の Issue の「Seer Root Cause Analysis」カードから、Find
- [うまく機能していたメトリクス製品をあえて終了させてゼロから作り直した理由](https://ichizoku.io/sentry/the-metrics-product-we-built-worked-but-we-killed-it-and-started-over-anyway/) - Article by: David Rosenthal 2年前、Sentry は「紙の上では」完璧に見えるメトリクス製品を作りました。ところが、自分たちでドッグフーディングしてみると、それが本当にお客様の求めているものではないことに気づいたのです。ローンチ予定の 2 週間前、私たちはそのプロダクト全体をお蔵入りにしました。 ここでは、その過程で得た学び、なぜ従来型の時系列メトリクスがモダンなアプリケーションのデバッグでは破綻してしまうのか、そして私たちがそのシステムをどのようにゼロから作り直したのかをお話しします。 最初のメトリクス製品がイマイチだった理由 2年以上前、Sentry では開発者向けのメトリクス製品をつくろうと動き始めました（私が Sentry に入社する前のことです）。その結果、ほとんどのオブザーバビリティプラットフォームが通ってきた道、メトリクスを事前に集計し、時系列データとして保存するというアプローチを選ぶことになりました。この方法であれば、エンドポイントのレイテンシやリクエスト数といった指標を効率よく、かつ高速に追跡できるはずでした。 そして実際、私たちのチームは成功しました。個々のメトリクスを追うだけなら、高速で低コストに動いていたのです。 しかし Sentry には、社内で自分たちのプロダクトを徹底的に使い込む「ドッグフーディング」の文化があります。この仕組みを実際の現場で使い始めたとき、すぐに問題点が見えてきました。それは、同じ設計思想のメトリクス製品が必ずぶつかる古典的な課題、いわゆる Cartesian product problem（デカルト積問題） でした。 ご存じない方のために説明すると、従来型のメトリクスでは新しい属性を 1 つ足すたびに、その属性の値ごとに新しい時系列データを保存しなければなりません。たとえば "server" 属性にサーバー名を入れるなら、サーバー名ごとに別々の時系列が必要になります。さらに複数の属性で分解したければ、それらの値のすべての組み合わせに対して時系列を持たなければなりません。これはすべて「事前集計」をする以上、あらかじめ「どんな問いを立てるのか」を決めておく必要があるという根本的な制約から生じています。 もちろん、これは常に大問題になるわけではありません。30台のサーバーのメモリ使用量を追跡するとか、その 16 コアそれぞれの CPU 使用率を見る、といった用途だけなら、従来のやり方でも十分に機能します。 しかし Sentry のゴールは、「コードが壊れたときに、開発者がデバッグして修正するためのリッチなコンテキストを提供すること」です。そのために、開発者は状況を理解しやすくするための属性やコンテキストをできるだけたくさん付けたくなります。ところが、コンテキストを増やせば増やすほどコストが爆発していくとなると、開発者は「本当は取りたいコンテキスト」を諦めざるを得ません。 社内でこのプロダクトを使っていたエンジニアたちは、常に「欲しいコンテキスト」と「払えるコスト」のあいだで板挟みになっていました……。これは、明らかに良くない状態でした。 カーディナリティという女王様 例を見てみましょう。 仮に、個々のタイムシリーズを保存するコストが 1 本あたり月 $0.01 だとします（業界的にもだいたいこのオーダー感です）。そして、ある特定のエンドポイントのレイテンシを追跡していて、そのエンドポイントは 1 日あたり 10 万回呼ばれているとしましょう。ここまではよくある状況です。 ここに、開発者 A がやってきて、「どのサーバー（8
- [【Sentry Godot SDK】Logs・User Feedback など新機能追加](https://ichizoku.io/sentry/introducing-logs-user-feedback-godot-sdk/) - Article by: Serhii Snitsaruk 最初の安定版リリースを経て、Sentry Godot SDK が Windows / Linux / macOS / iOS / Android をサポートし、一般利用いただける状態になったことをお知らせし致します。1年前、いくつかのプロトタイプから本格開発をスタートし、ついにここまでたどり着きました。実績のある Sentry プラットフォーム SDK 群の上に構築されており、Godot プロジェクトに簡単に追加できる GDExtension アドオンとして提供されています。 はじめて Sentry を知る方のために説明すると、Sentry はゲームの開発中・QA 中・リリース後を通じて「健全性」を管理するためのアプリケーションモニタリングツールです。クラッシュや実行時エラー、ログ、さらにはプレイヤーからのフィードバックまで自動的に追跡できるため、バグ追いに費やす時間を減らし、そのぶん「おもしろい体験」を作ることに集中できます。 このあと、Godot SDK に含まれる主な機能をご紹介していきます。 クラッシュとエラー Sentry はエラーやクラッシュのレポートを収集し、それらを「Issue」としてダッシュボード上に自動でグルーピングします。これにより、どの問題から優先的に修正すべきかを判断しやすくなります。 Godot Engine のランタイムエラーやスクリプトエラーを自動で捕捉し、詳細なスタックトレースを表示します。必要に応じてローカル変数やメンバー変数の情報、さらに可能な場合はその前後のスクリプトソースコード行まで確認することができます。 C++ レイヤーで発生したクラッシュについては、Sentry が minidump を収集・送信できます。これにより、ゲームがいつ、Godot のソースコードのどこでクラッシュしたのかを把握できます。この情報をもとにクラッシュの原因を理解したり、スタックトレース（または minidump ファイル）を Godot の開発者と共有したり、自分たちで問題を修正したりすることが可能になります。
- [【webvitals.com 登場】サイトを遅くしている原因を見つけよう！](https://ichizoku.io/sentry/introducing-webvitals-com/) - Article by: Anton Bjorkman, Sergiy Dybskiy 開発者が求めているのは、「ツールを実行して、数字を見つめて、落ち込むだけ」のウェブサイトではありません。なので、私たちは、まったく違うものを作りました。 WebVitals は、サイトの分析・最適化・高速化を、ひとつの場所でまとめて行えるサービスです。スタックトレースや遅いクエリに日々向き合っているメンバーが作ったこのツールは、パフォーマンス指標と、実際にユーザー体験を遅くしている原因とのつながりを浮かび上がらせます。 この 1 つの場所で、次のことができます。 実際のユーザーがあなたのサイトをどう体験しているかを把握する 最大の遅延要因をすぐに見つけ出す 専門用語や勘に頼ることなく、「次に何をすべきか」がはっきり分かる webvitals.com の仕組み ドメインを入力して「Go」を押せば、あとは WebVitals にお任せです。 裏側では、WebVitals が Vercel AI SDK を使って、いくつかのツールコールを実行します。 1つは Google の PageSpeed API：過去28日間の実ユーザーのパフォーマンスデータ、いわゆる CrUX データを取得します。 もう1つは Cloudflare の URL Scanner：サイトで使われている技術スタックを検出します。 これらの結果を組み合わせて分析し、本当に重要なポイントだけが浮かび上がるようにしています。 何がうまくいっていて、どこに改善余地があるのかが一目でわかります。各レポートでは、CrUX データを踏まえながら、指標を改善するための具体的でコンテキストのある次のステップを提示します。 なお、CrUX データは「実ユーザーの実際の利用データに基づく各指標の 75 パーセンタイル値」です。 Core Web Vitals レポート
- [【Sentry】デザインを一新しました！](https://ichizoku.io/sentry/sentry-has-a-bold-new-look/) - Article by: Jesse Box お気づきかもしれませんが、Sentry の見た目が大きくアップデートされました。 これまで、プロダクトの見た目は「いかにもエンタープライズ向け」という無難なデザインだった一方で、ブランドはずっと大胆で型破りでした。そのちぐはぐさは、もう終わりです！今日からは、皆さんが Sentry に期待するあの「ノリ」とプロダクトのデザインがきちんと噛み合うようになりました。より鮮やかで、より手触り感があって、より一層「Sentry らしい」見た目になっています。 ようこそ、S.C.R.A.P.S. 時代へ。これは Sentry の新しいデザイン言語で、正式名称は 「Standardized Collection of Reusable Assets & Patterns for Sentry（Sentry のための再利用可能なアセット＆パターンの標準コレクション）」 です。Sentry ならではの、ちょっと風変わりでクセになる魅力を、そのままプロダクトの中に流し込むためのデザイン体系なのです。 はじまりはこんなところから Sentry のプロダクトは、この数年で機能面では大きく成長してきましたが、見た目のほうは小さな改善の積み重ねにとどまっていました。「壊れていないものは直すな（Don’t fix what isn’t broken）」という考え方も、いつまでも通用するわけではありません。デザインは静かに古びていき、いったん世の中の期待値が変わってしまうと、かつては新鮮だったものも途端に古くさく感じられてしまいます。 一方で、ブランドのほうはどんどん先へ進んでいました。イラストはいい意味でどんどん「ヘン」になり、トーンはますます大胆に。それに対してプロダクトは、ずっと控えめなまま。両者の距離は少しずつ開いていきました。アプリはブランドの「少しトーンを落とした反響」であることが多いとはいえ、私たちの場合、そのギャップはもはや見過ごせないほど大きくなっていたのです。プロダクトが、もはや「Sentry らしく」感じられなくなっていました。 直近のマーケティングキャンペーンは「Make it make sense.」でした。 Sentry が初期に成功できた理由は、ほんの少しだけ他と違うことをしていたからです。誰も気にしないような部分にまで手をかけ、誰とも同じような「しゃべり方」をしないと決めていました。その最初のタグラインである「Sh*t Happens. Be on top of it.（トラブルは起きるもの。主導権はこちらが握る。）」が、その姿勢を物語っています。正直で人間味があって、ソフトウェアのカオスを前にしてもユーモアを忘れないトーンです。 その声は今も私たちを形づくっていますが、状況は変わりました。いまや「磨き上げられていること」は前提条件で、どのアプリも見た目はちゃんとしている。だから Sentry のデザインを刷新しようと決めたとき、私たちが目指したのは、よりツヤツヤした UI ではなく、「もう一度、自分たちらしさを取り戻すこと」でした。
- [10x チームの夜明け](https://ichizoku.io/sentry/the-dawn-of-the-10x-team/) - Article by: Milin Desai 以前の記事では、人間であれ AI 搭載ツールであれ、デバッグはコンテキストに依存しているという話を書きました。コンテキストがなければ、どれだけ高性能なシステムでも「どのコードが壊れているか」までは教えてくれても、「なぜ壊れたのか」までは教えてくれません。 いまや AI は、開発者が頼りにしているのと同じレベルのコンテキスト（スタックトレース、トレース、ログ、コミット、コード）にアクセスできるようになりました。その結果、ソフトウェアの構築と運用のあり方が変わりつつあります。私たちは、単なるモニタリングの時代から「推論」の時代へと移行しつつあるのです。 「10x デベロッパー（10倍の成果を出す開発者）」という概念は、今でも議論の的です。本当にそんな人はいるのか？ 採用に力を注ぐだけの人数が存在するのか、それともユニコーン探しに過ぎないのか？ そして AI は、私たちの多くをその理想像に近づけることができるのでしょうか。 しかし、これらは本質的なポイントではありません。私たちの前にあるチャンスは、単発の「超人的な個人貢献者」を解き放つことではなく、AI の力で「10x チーム」を実現することにあります。 情報の「ふるい分け」から、共有される推論へ 何十年もの間、デバッグは「起きてから対応する」もの（リアクティブ）でした。何かが壊れると、1人のエンジニアが（後ろで足をトントンしながら待っている人に急かされつつ）ログやトレース、ダッシュボードに飛び込み、干し草の山から一本の針を探すように原因を追いかけていました。モニタリングツールは「何が起きたか」を教えてくれますし、それは当時も今も有用ですが、「なぜ起きたのか」を判断するのは常に人間の役割でした。 時間とともに、モニタリングツールも進化してきました（正直に言うと（少し自慢すると）、その進化には私たちも大きく関わっています）。いま開発者が求めているのは、生のエラーデータだけではなく、「どこで・いつ問題が発生し、誰に影響し、その原因となったコードの行はどこか」といったコンテキストに富んだインサイトです。「何かがおかしい」から、「ここがまさにおかしい」とスポットライトを当てて指し示せるようになったことが、デバッグにおける最初の大きな転換でした。データに意味を与え、壊れたコードを素早く修正するためのツールを開発者に提供したのです。 AI はこの転換をさらに大きく前進させています。Sentry の Seer のようなエージェントは、「何が起きたのか」を構成するあらゆる情報を取り込み、それをコードベースや最近の変更と突き合わせて、根拠のある形で根本原因分析を行います。つまり、「何が起きたのか」を踏まえて推論し、その原因（＝なぜそうなったのか）を自然言語で説明できるのです。しかも、それをインタラクティブに行うこともできます。 こうして、デバッグのプロセスそのものが変わります。これまでは、1人か2人の担当者がベストな仮説を立て、それをチケットなどを通じて組織全体へ共有する、という流れでした。いまはそれが「チームスポーツ」になりつつあります。チーム全員が、同じコンテキスト、同じ推論過程、同じ解決への道筋を共有できるようになっているのです。 人手による「情報のふるい分け」から AI による推論支援へと移行することは、単に個々の開発者を速くするだけではありません。「なぜそうなったのか」という答えをチーム全員で共有できるようにすることで、チーム全体を速くします。「10x エンジニア」のことばかり心配する必要はありません。これは「10x チーム」をつくるための、最初の、そして一見するとごくささやかな一歩なのです。 コンテキストは力を増幅する どのエンジニアリングチームも、コンテキストの断片化やデータ不足がもたらす影響を経験しているはずです。ひとつの大規模チームの中ですら、メンバー間の認識のずれは非常に大きくなり得ます。使っているツールも違えば、追いかけているダッシュボードも違い、DM でのサイド会話の内容も異なる。その結果、本番環境で何が起きているのかについて、メンバーごとにまったく異なるメンタルモデルが形成されてしまいます。 ひとつのコンテキストを共有できれば、フィードバックループは短くなり、重複した作業は減り、時間の経過とともに学習効果が蓄積されていきます。本番環境の問題のデバッグは、孤立した作業からチームで取り組むリズムへと変わり、各イテレーションのたびに、人と機械から成るシステム全体が少しずつ賢くなっていきます。 いまやコンピュータも同じように機能しています。Seer は Sentry
- [【Sentry Logs】ダイナミックサンプリング問題をデバッグ](https://ichizoku.io/sentry/using-sentry-logs-to-debug-a-dynamic-sampling-issue/) - Article by: Simon Hellmayr この四半期、Sentry のチームの一部は不具合の修正に注力し、正確には 800 件を超える問題を解決しました。その中には、社内の Sentry プロジェクトでトランザクションのスパイク（急増）を引き起こしていた複雑な不具合も含まれていましたが、Sentry Logs を用いて調査し、根本原因を追跡して問題を解決しました。 問題：断続的なスパイクと 100% のサンプル率 最初の症状は明確でした。特定の時間帯の始まりに、社内のプロジェクトが大量のスパンであふれ、プロジェクトの「abuse layer（異常負荷防止層）」が Sentry プロジェクトから膨大なデータをランダムに破棄していました。ただし、すべての時間帯で発生するわけではなく、数日間連続で発生しないこともありました 調査の結果、ダイナミックサンプリング設定が「すべてをサンプリングする」ルールに上書きされていることがすぐに判明しました。つまり、{"type": "sampleRate", "value": 1.0} という設定です。 この設定の目的は、どのプロジェクトやトランザクションをどの割合で保存するかを指定することです。そして、その値が 1.0 の場合、すべてをサンプリングすることを意味します。Sentry の目標サンプリング率は 2% であるため、突如として 50 倍のトラフィックを受け取る事態は冗談では済みません。 しかし、なぜこのようなことが起きていたのでしょうか？ 最初の仮説は、ルール生成ロジックがフォールバックケース（代替処理）に入ってしまっているというものでした。これを確認するためには、より多くの可視性が必要でした。まず最初のステップとして、問題の設定状況を把握するために、コードに詳細なログ出力を追加し、動作を記録するようにしました。 調査に Logs を活用する まずは設定の JSON をそのままログに出力しましたが、この設定は非常に大きくなることがあり、GCP Logs が受け付けるサイズを超える場合があると分かりました。一方で Sentry Logs は JSON を自動的に切り詰め、重要な情報を直接得られるようにしてくれました。 ログのペイロードを縮小し、意味の明確化も図って迅速に改善した結果、必要なデータを取得できるようになりました。次に問題が再発した際には、すぐにSentry
- [「ミニ」じゃなかったミニダンプ！SteamOSで見逃されていたクラッシュを発見](https://ichizoku.io/sentry/not-so-mini-dumps-how-we-found-missing-crashes-on-steamos/) - Article by: Amir Mujacic 私たちは Sentry のゲームエンジンとネイティブ SDK のアップデートをリリースしましたが、Windows でビルドしたゲームを Linux 上で Wine / Proton 互換レイヤーを使って意図的にテストしている場合を除いて、おそらくほとんどの開発者はこれまで気づいていなかったと思います。それこそが狙いです。 ゲームエンジン SDK の改善に取り組んでいる最中、謎の問題を調査する中で得た知見は、Wine やその他の互換レイヤーを介して Linux 上で動作するあらゆる Windows アプリケーションにも当てはまります。そしてそこに至るまでの経緯自体が語る価値のあるストーリーだったのです。 謎：なぜクラッシュレポートが届かないのか きっかけは、あるゲームスタジオからのサポートチケットでした。 「Sentry は Windows ではうまく動いているのですが、Steam Deck のクラッシュでは何も届きません。」 おかしい… 私たちはテスト用ゲームを SteamOS 上で動かしましたが、Linux ビルドをテストすれば、問題なく動作します。次のステップは、多くのゲームと同じように互換レイヤーを介して、SteamOS 上でテスト用ゲームを動かすことでした。非致命のエラーはきちんと拾える。ログも例外もパフォーマンスデータも一通り見えます。ところが実際のクラッシュだけは、反応ゼロ…。 最初の直感：アップロードパイプラインを確認しました。ネットワークの問題？認証？いいえ。非クラッシュイベントに関してはすべて正常に見えました。 そこで Steam Deck のテストデバイス上のローカルストレージを確認しました。 すると 15 個のクラッシュダンプがありました… それぞれが 500MB 超えで、デモゲームなのに、ヒープメモリがダンプされていない状態としては異常な大きさです。 参考までに言えば、同じゲームの通常の Windows クラッシュダンプは 50〜80KB 程度です。何かが壊滅的におかしかったのです。
- [【AI Code Review】バグを3万件削減、50%高速化](https://ichizoku.io/sentry/ai-code-review-30k-bugs-lighter-50-faster/) - Article by: Lindsay Piper 先月、私たちは AI Code Review をリリースしました。これは、バグを自動で検出し、パフォーマンス問題を見つけ、PR をより速く出荷できるようにする開発者向けツールです。 リリースから30日、アップデートは次のとおりです。 自社コードでの AI Code Review の検証 これまでに、AI Code Review は3万件以上のバグを検出しました。そのうちいくつかは、Sentry のスタッフエンジニアである Ryan Brooks のサイドプロジェクト（持久系アスリート向けにトレーニング計画を作成・維持するアプリ）にも含まれていました。Strava のパフォーマンスに基づいてワークアウトを調整する、いわば「適応型のバーチャルコーチ」です。 AI Code Review はスケジューリングのロジックバグを検出しました。 「私のアプリの一部では、レース日から逆算してトレーニングの“フェーズ”を生成します。このアルゴリズムにいくつか手を入れたところ、Sentry が、2つのフェーズが潜在的に重なり得るという、起こり得ないはずのバグを正しく検出してくれました。PR のコメントをそのまま Claude Code に貼り付けたら、バグは修正されました。」 ユーザーに確実に影響していたはずのミスもありました。 「オンボーディングのフローに、3週間未満先のレースを追加できないようにするロジックを加えました。率直に言って、来週末にマラソンは走らないでしょうからね。ですが、レースの編集にも同じ React コンポーネントを使っており、Sentry がすでに予定されているレースの編集をブロックしてしまうバグを見つけてくれました。これは大きな指摘でした。」 コピペできるプロンプトで、コメントをより高速に パフォーマンスを50%改善 レビューにかかる時間が誰にとっても長すぎたため、レビューパイプラインを作り直し、平均レイテンシをおよそ50%削減しました。 実施内容は次のとおりです。 推論量が少なくてよいタスクについては、出力の一貫性を保つようプロンプトを調整しつつ、より高性能な（高速な）モデルへ切り替えました。 すべてのステップに「思考の上限（thinking budget）」を設け、仮説検証ステップには最大反復回数を設定して、考えすぎ（overthinking）を防ぎました。 評価（eval）とスポットチェックを実施し、パフォーマンス改善がレビュー品質に悪影響を与えていないことを確認しました。 要するに、レビューはこれまでより速くスリムになり、私たちはそのバランスの調整を継続しています。
- [【Unreal Engine】ゲームコンソールでクラッシュレポート提供開始　トレース連携ログに対応](https://ichizoku.io/sentry/unreal-engine-crash-reporting-now-available-on-gaming-consoles/) - Article by: Ivan Tustanivskyi, Steve Zegalia Sentry Unreal SDK の最初のメジャーリリース（現在 v1.2.0。インタラクティブなサンドボックスでも試用可能）に合わせて、クロスプラットフォームの Unreal 開発者を支援するため、プラットフォーム対応範囲、ユーザーフィードバックを用いたデバッグ、パフォーマンス監視の各面で重要な改善を行いました。 主な更新点は次のとおりです。 ゲームコンソール対応 Sentry Unreal SDK は、Unreal の platform extensions を用いてコンソール（Xbox、PlayStation 5、Nintendo Switch）をサポートするようになりました。これにより、開発機とリテール機を問わず、致命的・非致命的イベントの完全なコンテキスト（ネイティブクラッシュのフルサポートを含む）を 1 か所で取得できます。ゲームコンソール対応の詳細をあわせてご覧ください。 これまでの Unreal SDK のアーキテクチャでは、新しいプラットフォームを追加する作業が複雑でエラーが起きやすいものでした。今回の再設計により、（プラグインのように機能する）platform extensions を採用する基盤が整い、コンソール固有コードをモジュール式に統合できるようになりました。これにより、プラットフォーム API へのハードコード参照や SDK コア全体への大規模な変更を避けつつ、開発を簡素化し、NDA により保護された低レベルの実装詳細を適切にカプセル化できます。 構造化ログ Unreal SDK でも構造化ログが利用可能になりました。ゲーム内のエラーやクラッシュ、パフォーマンス問題に対して、ログ出力を取得し、関連付けることができます。つまり、プレイヤーがロード画面でスタックした場合や、アセットのストリーミング直後にクラッシュが発生した場合でも、障害に至るまでの正確なログの軌跡を把握でき、Issue ビューや Trace ビューから直接確認できます。 公開
- [段階的にブラウザのトレーシングを改善](https://ichizoku.io/sentry/improving-browser-tracing-step-by-step/) - Article by: Lukas Stracke ブラウザのトレーシングは、うまく機能しているあいだは「存在を感じさせないもの」です。しかし、一度それがうまく動かなくなると、たちまち強烈な存在感を放ちます。トレーシングが正しく機能していれば、実環境におけるアプリケーションの挙動を明確に把握でき、具体的で行動につながるインサイトが得られます。一方で、トレーシングがうまく機能していない場合、そこにあるのはノイズだらけのデータ、欠落したトレース、そして何も語ってくれないスパン。つまり、何の手がかりも得られない状況です。私たちはここ数か月、この問題に少しずつ取り組み、着実に改善を重ねてきました。 ここでは、Sentry の JavaScript SDK に施した改善を順に見ていき、ブラウザトレーシングを「より正確にする」だけでなく、「より有用にする」ための取り組みをご紹介します。ページロードスパンを明示的に制御できるようにすることから、リダイレクトのより賢い取り扱い、リソーススパンにおけるより深いタイミングデータの追加まで。これらの更新は、推測を減らし、本当に重要なものを前面に出すことに主眼を置いています。 ページロードスパンを明示的に終了する 提供開始：10.13.0 私たちの SDK では、規定でページロードやナビゲーションのスパンは「アイドルスパン」として開始されます。このアイドルスパンは、子スパン（例：fetch リクエストのスパン）が継続的に開始・終了されるかぎりアクティブな状態を維持し、一定時間アクティビティが途絶えると自動的に終了します。 なぜこの方式なのでしょうか。それは、「ページが完全に読み込まれた」と言える普遍的な指標が存在しないからです。 初回レスポンスの受信後でしょうか。すべてのスクリプトやリソースのロード完了後でしょうか。それともアプリケーションのハイドレーションやブートストラップ完了後でしょうか。 たしかに、ブラウザには domContentLoaded や readyStateChange のようなシグナルも存在しますが、初期の体感的なページロードに関わる処理がその後に続くケースも少なくありません。現実として、フレームワークや Web アプリの多様性、そして一般的な JavaScript のカオスを踏まえると、この問いに万能な答えはありません。 私たちのアイドル化とデバウンスの仕組みは、ユーザーの 95% にとって十分に機能しており、概ねページロードの所要時間に納得いただけています。しかし一部のユーザーからは、「ページの読み込み完了をアプリケーション側から Sentry に明示的に通知したい」という要望も寄せられていました。そこで用意したのが、Sentry.reportPageLoaded() です。 enableReportPageLoaded: true と Sentry.reportPageLoaded() を併用すると、アイドル機構の大部分が取り除かれ、代わりにユーザーが完全に制御できるようになります。 コールバック外でのアクティブなスパン 提供開始：10.15.0 バージョン 8 で NodeJS SDK に OpenTelemetry を導入した際、私たちは旧来のトランザクション中心の API を新しい
- [【バイブコーディング】トレーサビリティでフィードバックループを閉じる](https://ichizoku.io/sentry/vibe-coding-closing-the-feedback-loop-with-traceability/) - Article by: Kyle Tryon ここ数か月で私は本気で「ヴァイブ・コーディング」を受け入れはじめ、メインのコードエディタとしては Cursor を、エージェントの LLM としては Claude Sonnet 4 を使っています。開発者にとっていまは刺激的な時代です。私たちは、生産性を100倍にしてくれるかもしれない何かを試しつつ、これらのツールを実装するための新しいワークフローや戦略を切り拓いているのです。 しかし、十分に大きなコードベースで LLM を使った本格的な開発をしたことがある人なら誰でも知っているとおり、それは「怯えた猫の群れをまとめようとするようなもの」です。 コードベースが複雑化・分散化するほど、管理すべきコンテキストは増え、ファイル固有のルールも増え、エージェントから高品質な出力を得ることが全般的に難しくなります。皮肉なことに、私たちがコードをきちんと整理すればするほど、LLM はそれを見つけるためのコンテキスト管理タスクをより多くこなさなければならなくなります。 PR のレビューやテスト生成といった AI ツール一式があっても、AI 生成コードを出荷するのは不安が残ります。ヴァイブ・コーディングで作った機能が本番を落とさないと、どうして言い切れるでしょうか。そもそも本当に動くのか、どうやって確かめればよいのでしょう。ビルドを通すためだけに、エージェントが巨大なコード片をコメントアウトしてしまうのを目にしたことさえあります。 エージェント主導のコードサイクルには盲点があります。しかし、それは修正可能です。 LLMの盲点：実行時の可視性 プロンプトを微調整したり、docstring を追加したり、エージェントのルールを洗練させたりしても、核心的な問題は解決しません。LLM は、自分が生成したコードが実際に走ったときに何が起きるのかを「見る」ことができないのです。暗闇の中で手探りでダーツを投げ、修正を重ねても照準を合わせ直せない。しかも、生成コードに現れたエラーは、LLM がその問題を見ないまま反復するほど増殖していきます。 現状のコンテキスト管理は、プロンプトにどのファイルを含めるかの管理に大きく依存しています。MCP（Model Context Protocol）は一歩先に進み、複数のデータソース間でコンテキスト情報をやり取りできるようにしてくれます。 いま Cursor や Claude Code のようなツールを、MCP 連携が限定的な形で使っているなら、あなたのコンテキストはおそらくアプリのソースコードと、多少のドキュメント、それにコピペした何かくらいに留まっているはずです。 コードを実行し、そのログを問題解決のために手動で LLM に食べさせたことがあるかもしれません。目指すべきはここにフィードバックループを組み込むことです。すなわち、コードを生成し、その実行からテレメトリ（計測情報）を収集し、その結果を LLM に知らせることで、ガイダンス付きで解法の反復を進められるようにするのです。 このフィードバックループをどう閉じるかを理解するために、まずトレースとは何か、そしてそれが欠けている「実行時の可視性」をどう提供できるのかを見ていきます。MCP サーバーを使えば、この重要なコンテキストを LLM エージェントに追加し、可視性のギャップを埋めることができます。
- [【Session Replay】自分自身がデジタル上のシークレット・ショッパーになる](https://ichizoku.io/sentry/session-replay-becoming-your-own-digital-secret-shopper/) - Article by: Kyle Tryon 本ブログの内容 リアルな顧客インサイトのために Session Replay を有効化する チェックアウト離脱とカート放棄の原因を診断する Session Replay を使って放棄カートを Sentry で確認する 自分のショップを次のステップへ 小売店が長年にわたってショッピング体験の測定と改善のために頼ってきた秘密兵器… それが「シークレット・ショッパー」です。 彼らは一般の客を装い、顧客体験を評価します。たとえば見つけにくい商品の特定、接客品質の評価、チェックアウトプロセスのスムーズさなど、摩擦が生じる箇所を見つけ出します。彼らが収集するデータは、偏りのない実践的なフィードバックの代理として機能し、店舗運営者はそれを基に顧客体験を改善し、コンバージョン率を高め、平均注文額を増やします。 しかし、eコマースでは小規模なサンプルや代理顧客に頼る必要はありません。Session Replay （セッションリプレイ）のようなツールを使えば、実際の購買者の行動を大規模に分析できるのです。さらに、ユーザーのセッションを「再生」して、彼らが実際に見たものをクリックごとに正確に確認することもできます。 リアルな顧客インサイトのために Session Replay を有効化する Session Replay は、ユーザー体験をまるで動画のように再現し、その時に発生したログ、エラー、トレースなどの関連情報をすべて紐づけて記録します。これにより、ユーザーが実際にどのような体験をしているのかを、当時のコンソールログなどと突き合わせながら確認することができます。 これは、ユーザー自身に報告を依頼せずに問題を診断できる非常に優れた方法です。詳細な説明やスクリーンショット、動画を求める代わりに、実際に何が起きたのかをそのまま見ることができるのです。 しかも、これは単なるエラーデバッグツールにとどまりません。「どこで迷い、どこで操作フローが途切れ、デザイン上の選択が体験にどう影響しているか」といったユーザーの行動パターンを可視化することもできます。 導入をするには、まず自分のオンラインストアのフロントエンドフレームワークに対応する正しい SDK を選び、Replays 機能を有効化した状態で Sentry を追加します。もし Shopify の Hydrogen を使ってアプリを開発している場合は、React Router SDK を利用することができます。 以下は、ご自身のアプリに簡単に組み込めるシンプルな React のセットアップ例となります。 エラー発生時や通常のセッションなど、状況に応じて Session Replay のキャプチャ率（録画割合）を個別に設定
- [【Sentry AIコードレビュー】現在ベータ版：本番環境での問題発生を減少](https://ichizoku.io/sentry/sentry-ai-code-review-now-in-beta-break-production-less/) - Article by: Lindsay Piper これは防げたはずです。 これも防ぐべきでした。 これも同じです。 私たちは皆、PR（プルリクエスト）でタグ付けされるのが嫌いです。時間を取られ、必ず何かを見落とした時には責められ、そして「自分ならこうは書かなかった」という感覚が常につきまといます。LLM（大規模言語モデル）は、これをもっと簡単にしてくれると約束しました。私たちの代わりにやってくれると。しかし、ご覧のとおり、まだその段階には至っていません。 しかし、これこそが Sentry の本業です。私たちはバグを捕まえます、本番環境で。では、その専門性をコードレビューの段階に持ち込んだらどうでしょうか？天才的だと思いませんか？ そこで私たちは、AI コードレビューに新しい機能を追加しました。プルリクエストを開く際に、Sentry の Issue を取り込み、実際にバグを予測するのです。もちろん、すべてのエラーを防げるわけではありません。あなたが書いた（あるいはプロンプトで生成した）コード以外にも考慮すべき要因があまりに多すぎるからです。しかし、この機能を使えば、本番環境を停止させるような回避可能なミスを出荷してしまうことを防ぐことはできます。 Sentry のコンテキストをプルリクエストに持ち込む AI ツールにおいては、コンテキストこそがすべてです。これは、Seer がベータ期間中に開発者たちの累計2年以上の時間を節約できた理由でもあります。私たちの AI コードレビューも同じアプローチを取りますが、それを出荷（デプロイ）前に行います。具体的には、あなたが触れたコードに対して Sentry のコンテキストや、そのコードに関する過去のシグナルを活用します。対象となるのは、関数の残りの部分、リポジトリ内で呼び出される関数、そして依存するクラスやオブジェクトです。 この「ライブのコードコンテキスト」と「現実世界での Issue 履歴」を組み合わせることで、フィードバックは曖昧な警告や一般的なリンティングの助言ではなく、具体的で実行可能なものになります。 最も重要なエラーを予測し、防ぐ 自動化された PR レビューは、たとえリポジトリ全体のコンテキストを持っていても、しばしば実際の問題をスタイル上の細かい指摘やベストプラクティスに埋もれさせてしまいます。その結果、開発者は「consider inlining」や「prefer async/await」といった注意の洪水の中から UnboundExecutionError を探し出さざるを得なくなるのです。 しかし、Sentry のコードレビューはそうではありません。PR がレビュー可能（ready for review）とマークされたときに実行され、実際に本番環境を壊すものだけにフォーカスします。 したがって、もしあなたが次のような変更を含む PR を開いた場合、以下のようになります。 インポート文の後に空行を追加したほうがよい、といったコメントは表示されません。 Sentry が返すのは、次のように 具体的で実際に役立つデバッグコメント です。 これがどのように動作するかは、次のとおりです。
- [Sentry ハックウィークの舞台裏　壊すための口実](https://ichizoku.io/sentry/inside-sentrys-hackweek-an-excuse-to-break-things/) - Article by: Hector Dearman, Nico Hinderling, Nelson Osacky Sentry ハックウィーク（社内開発週間）では、多くの「Sentaurs（Sentryのメンバー）」が、今後何年にもわたって価値をもたらす Sentry サービスの有用な拡張機能の構築にこの機会を活用しました。 しかし、私たちは違いました。 私たちは、混乱を引き起こし、クラッシュを誘発し、バグをあぶり出す機会として、初めて参加する Sentry ハックウィーク を利用しました。もっともらしさを最大化するために、プロジェクトの説明は「SaaS アプリケーション向けの LLM 主導型 Web ファジング」とし、愛称は「Gremlins（グレムリン）🧌」と名づけました。 Gremlins は、予測不能なユーザー操作を実行することでバグを発見するよう設計された、AI 駆動のファジングエージェントです。従来型のファジングが苦戦するのは、現代のアプリケーションがフロントエンド、バックエンド、データベース、補助的なサービスなど複数のコンポーネントにまたがっているためです。入力は単一のデータバッファではなく、ユーザー操作のシーケンスになっています。 Gremlins はこれを、Web エージェントを通じて意図的に混沌を作り出し、Sentry の SDK を活用してエラーを検出し、プロファイリング／トレーシングデータを収集し、セッションリプレイを取得して、何が明らかになったかを確認することで解決します。 グレムリンが見つけられるものは、実際のユーザーも同様に遭遇し得ます。 Gremlin ワークフロー 大まかには、Gremlins はシンプルな手順に従います。 ユーザーが対象サイトを設定し、必要に応じてエージェント設定を追加する エージェント（群）をサイトに放つ Gremlins があぶり出したエラーを Sentry が捕捉する 設定は軽量で、ユーザーは次の項目を指定できます。 対象サイト 任意のテスト指示（例：「設定ページを壊してみて」） 認証情報 Gremlins の数 など
- [エラーメッセージを（偶然）営業マシンに変えてしまった](https://ichizoku.io/sentry/turned-error-messages-into-sales-machine-by-accident/) - Article by: Dan Mindru Dan Mindru はフロントエンド開発者／デザイナーであり、Morning Maker Show の共同ホストでもあります。現在、PageUI、Clobbr、CronTool など複数のアプリケーションを開発中です。 毎日のように多くの AI スタートアップが生まれているのは、実に驚くべきことだと感じています。私たちソフトウェアエンジニアの多くは、自らのソフトウェアが実際に何をしているのかを知りたがります。計画を立て、レビューを行い、自動テストを実施して、想定どおりに動作しているかを検証します。さらに念のため、手動テストも一巡行います。ただし、AIは例外です。何か月も何か月もテストを重ねた末、私は落ち着かない状況に置かれることになりました。私のプロダクトは概ね正常に動作していたものの、タスクの遂行に完全に失敗することがあったのです。実際、約90％の確率では正しく動作しました。しかし、成功率を0％から80％に到達するまでに1か月、80％から90％、あでは 3か月、そして90％から100％にするには、少なくとも12か月はかかりそうに思えました。現在のスピード感では、「AIの時間」における12か月は、通常の時間でいうところのほぼ1世紀に相当します。ですから、毎日のように新たなスタートアップが登場する理由がすぐに理解できたのです。結局のところ、皆すぐにローンチするのです 🤷‍♂️その後、私たちは12,000人のユーザーを獲得しました。ここから、それがどのように私に有利に働いたのかを説明していきます。あわせて、最大の問題が何だったのかについてもお話ししますが、おそらく想像もつかないはずです。 どのように始まったのか 私はウェブサイト制作を変革するスタートアップを立ち上げたいと考えました。PageAI は、シンプルな説明文から本番運用レベルの Web サイトを、計画・デザイン・コーディングまで行うことができるビルダーです。聞こえは非常に壮大ですが、エラーもそれに匹敵するほど壮大でした。予想どおり、うまくいかないこと（実際に起きたこと）も数多くありました。どのように壊れるか、すべてを把握していたわけではありませんが、少なくとも AI の出力を完全には信用できないことは分かっていました。これはセキュリティだけでなく、デザインやコード品質の観点からも同様です。そのため、失敗を受け入れた上で、適切に対処できるようにする必要がありました。ここで直面したのが、古典的な「鶏が先か卵が先か」の問題です。多くの人に使ってもらわない限り、どのような失敗が起こるかは明らかになりません。一方で、自分たちだけでそれを洗い出そうとすれば、資金が尽き、時代遅れのプロダクトをリリースする危険があります（ちなみに PageAI は自己資金で運営していたため、QA のスケールにも厳しい制限がありました）。そこで、他の多くのスタートアップと同様に、私たちもローンチすることにしました。 とはいえ、私もそこまで奇抜ではありません。ローンチ前に、AI のエラーを囲い込み、可能な限り緩和しようとしました。私たちが実際に行ったことは以下のとおりです。 自前のパーサーを実装し、生成されたコードを解析したうえで「再構築」し、怪しい／危険な出力をすべてスキップ 出力を保護するために、プロンプト、チェック、エージェントフローを強化 クラッシュを防ぐために、フロントエンドで追加の処理とサンドボックス化を実装 ローンチはあらゆる指標でうまくいき、最初の1週間で2,000人のユーザーを獲得しました。 ところが、その後は静まり返っていました。誰からもクレームがないのです。何かがおかしい… 少なくとも10人に1人は問題に直面すると思っていたのに。これが最初の問題でした。 ❌ 問題1：どれほど深刻かが見えていなかった エラーが発生していることは把握できていましたが、ユーザーがわざわざその問題を報告してくれることはほとんどありませんでした。試してみてエラーが出たら、黙って競合サービスに移ってしまう。良くない状況です。 ✅ 解決策1：簡単に評価できる仕組みを追加 そこで、投稿ボタンのすぐ横に評価ウィジェットを追加しました。手間も少なく、ユーザーの目にもすぐ留まるため、多くの人が気軽に反応してくれるようになりました。 PageAIのトップバーに評価ウィジェットを追加 レビューが少しずつ届き始めました。予想どおり、1つ星評価も少なくありませんでした。 とはいえ、ほとんど誰もこちらに直接連絡はしてきませんでした。 ❌ 問題2：フィードバックを送るのが面倒 評価ボタンを押すだけならしてくれますが、その先、わざわざお問い合わせページに移動して、メールを送る人はほとんどいませんでした。問題の解決にく関わろうとはせず、また別の競合サービスに移ってしまう、という流れになってしまいました。
- [ベータ期間中に Sentry のユーザーフィードバックウィジェットを使って Logs を形作った方法](https://ichizoku.io/sentry/how-sentrys-user-feedback-widget-helped-shape-logs/) - Article by: Jasmin Kassas Sentry では、私たちは公開の場で開発を行い、迅速に対応しています。しかし、スピードを重視することで、最初の試みで全てがうまくいくとは限りません。そこで役立つのがフィードバックです。フィードバックはうまくいっている点を検証し、不足している部分を特定し、エラートラッキングだけでは把握できない問題を明らかにする助けになります。 数か月前に Logs のベータ版をリリースしたとき（ちなみに先週 GA になったのでぜひご覧ください）、私たちはエラーやパフォーマンス監視だけでは明らかにならないもの（壊れているのに気付かれないもの、静かに失敗しているもの、あるいは単にユーザーを混乱させているもの）を見つける方法が欲しいと考えていました。そこで、Sentry のユーザーフィードバックウィジェットをプロダクトにそのまま組み込みました。 つまり、開発者がつまずいたとき、そのフィードバックにはリリースバージョン、環境、URL、さらには実際に起こったことのセッションリプレイといった、私たちに必要なすべてのコンテキストが付随していました。 その結果、Logs はより速く進化し、信頼性が高まり、開発者（私たち自身を含む）が実際に使いたいと思えるものへと変わりました。 フィードバックを機能と修正に変える ユーザーフィードバックウィジェットは単なる意見収集の箱ではなく、Logs ベータ期間中に私たちが実際に出荷したものを形作りました。 明確な例のひとつが 自動リフレッシュ機能 です。開発者から「ログストリームを自動的に更新してほしい」という要望が繰り返し寄せられていました。私たちもそれが重要であることは認識していましたが、優先順位を上げるには至っていませんでした。しかし、タグ付きのフィードバック提出が積み重なっていくうちに（製品固有のフィードバックを素早く確認するには、URL タグでフィルタリングしています）、その継続的なシグナルが優先度を押し上げました。そして、4週間でフィードバックから機能へと進化し、現在では稼働中の自動リフレッシュ機能をリリースするに至りました。 また、アラート機能に対する強い要望も寄せられました。これを受けて、ログベースのアラートをサポートし、認証エラーや設定の欠落といった重要なログが現れたときにユーザーへ通知できるようにしました。 しかし、このウィジェットは製品リクエストのためだけのものではありません。最も重要なのは、エラートラッキングだけではすぐに明らかにならなかった重大な SDK の問題を表面化させてくれた点です。それによって、私たちは次のような問題を特定し、解決することができました。 Python SDK のバグ：ログ属性を正しく収集していなかった。Python 標準ライブラリのロガーとのログ統合を最初に実装したとき、生成されたログメッセージに名前付きパラメータを付与していませんでした。この API がそのようにも利用され得ることを、ユーザーから指摘を受けるまで気付いていませんでした。 JavaScript SDK の問題：特定のオブジェクトのシリアライズが原因で、ログメッセージが正しくレンダリングされないことがありました。これは、JavaScript SDK でコンソール計測を通じて生成されたログを作成する際に、文字列を連結する方法に起因していました。修正自体は単純でしたが、[Object Object] が紛れ込んでしまうのは簡単だということを思い出させるものでした。 JavaScript SDK のより深刻なバグ：環境とリリースの属性がログに正しく付与されない問題がありました。原因は単純で、これらの属性をログに付与する際に正しいフォーマットを使用していなかったことです。しかし、私たちのプロダクトはリリース値や環境値をトップレベルのフィルタやデータの関連付けに依存しているため、ユーザーにとって多くの問題を引き起こしました。 フィードバック提出には、環境、組織ID、プロジェクト名、URL といった技術的なコンテキストが含まれていたため、私たちはサポート対象プラットフォーム全体に修正を出荷し、Logs をより信頼性の高いものにすることができました。その結果、Logs はフロントエンドの体験においても、基盤となる SDK インフラにおいても、開発者が期待する通りに動作するようになりました。
- [【Issue グルーピングの改善】より賢く、より速く、誤判定は半分に](https://ichizoku.io/sentry/enhancing-issue-grouping/) - Article by: Kush Dubey , Yuval Mandelboum（読了時間：9分） Sentry の役割は、アプリケーションで問題が発生した際に、それを開発者へ知らせることです。そのために、個々のエラーを Issue としてグループ化しています。まず、フィンガープリントを使ってエラー構造を字句レベルで照合し、一致しない場合は AI モデルが補完します。AI モデルは新しいエラーのスタックトレースを既存の Issue と比較し、意味的に類似していると判断した場合は同じ Issue として統合します。このたびモデルをアップグレードしたことで、重複 Issue の発生を20％多く防ぐとともに、誤った Issue 統合を半減させました。 AI による Issue グルーピングはデフォルトで有効になっており、すべての Sentry ユーザーに適用されています。 グルーピングが難しい理由 AI グルーピングの v1 については、「Transformer ベースのテキスト埋め込みモデルで Sentry アラートを 40% 削減 ー ノイズを突破」で解説しています。 優れたグルーピングアルゴリズムは、アンダーグルーピングとオーバーグルーピングの両方を最小化します。アンダーグルーピングを抑えるとは、同じ根本原因の問題に対して Sentry が新しい Issue を次々と生成しないことを意味します。オーバーグルーピングを抑えるとは、アプリが経験している新しいカテゴリのエラーを Sentry が必ず通知することを意味します。このバランスをうまく取るのは難しく、主観的な判断も伴います。 オーバーグルーピングはより深刻な失敗モードと言えます。Sentry がエラーを誤って Issue に統合してしまうと、本来別のワークフローで対処すべき問題が隠されてしまいます。そのエラーは優先度も根本原因も修正方法も異なる可能性があります。 いかに判断を誤りやすいかを示す実例として、Sentry のリポジトリにあるスタックトレースがほぼ同一でありながら、根本原因が異なる 2
- [【Laravel】デバッグとログ記録](https://ichizoku.io/sentry/laravel-debugging-logging-guide/) - Article by: Kyle Tryon 本ブログの内容 サンプルプロジェクトのセットアップ Monolog を使った Laravel のログ記録 Laravel をデバッグするために使うべきツール Laravel アプリのパフォーマンス問題をトラブルシュートし修正する 本番環境で Sentry を使って Laravel をデバッグ・ロギングする Laravel をよりスマートにデバッグする ロジックエラー、失敗した HTTP リクエスト、気付かれずに消えるバックグラウンドジョブ。ソフトウェアはあらゆる「楽しい」形で壊れます。強靭なシステムと脆いシステムの違いは、エラーを完全に回避できるかどうかではありません。何が問題だったのかを、いかに素早く、明確に把握し、修正できるかにかかっています。 Laravel はしっかりとした基盤を提供します。構造化ログ、リアルタイムでの内部観察、そして組み込みのパフォーマンス監視。開発やステージング環境では、dd()、Log::debug()、Monolog、Telescope、Debugbar、Xdebug といったツールを使って、内部を覗き込むことができます。しかし、本番環境はまったく別物です。 本番環境でフロントエンドとバックエンド両方のエラー、遅延、そして再現が難しいエッジケースにわたる完全な可視性を確保するために、Sentry は Laravel アプリに統合され、必要な時に必要なコンテキストを、異なるサービスを横断して提供します。 このガイドでは、いくつかの Laravel デバッグツールについて説明します。それぞれが何をするのか、どのような場面で使うべきか、そしてログを掘り返したり環境ごとに何が悪かったのかを推測したりせずに、適切なインサイトを得る方法を解説します。 前提条件 すでにお使いのコンピュータに Laravel 12 がインストールされている場合は、それを使用できます。 ただし、このガイドでは別のアプローチを取り、Docker コンテナ内でサンプルを実行します。Docker を使うことで、この記事内のコードはあらゆるオペレーティングシステム上で実行でき、セキュアなサンドボックス内で個人ファイルから安全に分離され、特定のバージョンの Laravel、Node、PHP をインストールする必要もありません。 また、このガイドでは Git がインストールされていることを前提としていますが、必要であればサンプルリポジトリを手動でダウンロードして解凍することもできます。 サンプルプロジェクトのセットアップ Laravel
- [ゲームコンソール向けクラッシュレポートが正式リリース](https://ichizoku.io/sentry/error-monitoring-and-crash-reporting-for-gaming-consoles/) - Article by: Bruno Garcia TL;DR：主要なゲームコンソール向けのエラーモニタリングとクラッシュレポートが、正式に利用可能になりました（加えて、Unreal Engine SDK v1.1 もリリース）。これ以上の説明が不要でしたら、以下はスキップして、『リリースに含まれるものは？』のセクションにジャンプしてください。 10年以上前、ある顧客が自分のPlayStation 3のゲームに Sentry をハックして組み込みました。そこから時を経て、Sentry はいまでは Web、モバイル、デスクトップを横断して数千ものゲーム開発者をサポートしています。 欠けていたピースはなんでしょうか。 それはコンソールです。開発者からの要望を受けて、私たちはそれを実現しました。今年初めにベータとして提供を開始した後、主要なすべてのプラットフォームでコンソールサポートが正式リリースとなり、開発者が優れたゲーム体験を構築・提供するための新たな道を切り拓きました。これでスタジオは、クラッシュダンプに溺れることなく、構築・ローンチ・成長に必要なツールを手に入れることができます。 さらに、Unreal SDK、Unity SDK、カスタムエンジン向けの Sentry Native SDK とも緊密に統合され、すでに大規模な本番環境で稼働しています。 〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜 「Sentry のクラッシュレポート機能は、私たちが VALORANT を Xbox Series や PS5 コンソールでローンチするうえで不可欠でした。Riot 規模で対象とするすべてのプラットフォームをサポートするカスタムクラッシュ収集ソリューションを構築するのは、非常に複雑になっていたでしょう。Sentry はその問題を解決してくれたため、私たちはプレイヤーにより良いゲームを届けることに専念できるのです。」— Daniele Giannetti, Riot Games Inc. リリースに含まれるものは？ このリリースにより、開発機や市販デバイスを問わず、致命的・非致命的イベント（完全なネイティブクラッシュ対応を含む）の全コンテキストを一元的に取得できるようになります。 もはやクラッシュダンプを手動で取得したり、リキャップサーバーを立てたり、プラットフォームごとに複数のクラッシュレポートツールを使い分けたりする必要はありません。 リリースに含まれるもの 可読性の高いスタックトレース：問題が何で、どこで発生したのかをすぐに特定できる 組み込みのシンボルサーバー：デバッグファイルを直接 Sentry にアップロード可能 カスタムシンボルサーバー対応：単一かつ統一されたフォーマットを含む、多様なシンボルサーバーレイアウトをサポート タグとデバイスコンテキスト：コンソールモデル、ビルド番号、リージョン、デバイスの状態などを取得し、特定の地域、リリース、ハードウェアで問題が発生しているかどうかを把握可能 クラッシュ時のスクリーンショット：問題が起きる直前にプレイヤーが何を見ていたかを正確に確認できる
- [【SvelteKit】オブザーバビリティが10倍強化 ー その全貌を解説！](https://ichizoku.io/sentry/sveltekit-observability-just-got-10x-better/) - Article by: Lukas Stracke Svelte チームは先日、 SvelteKit の完全なオブザーバビリティとトレーシングのサポートを追加したことを発表しました！ これは SvelteKit と Sentry のユーザーにとって朗報です。なぜなら、Sentryはすでにこの新機能と互換性があるからです。 さらに、このニュースは JavaScript エコシステム全体にとっても大きな意味を持ちます。SvelteKit は、ESM ベースのメタフレームワークとして初めて、インストゥルメンテーションとトレーシングを標準でサポートしたのです。 ここからは、なぜこれが重要な一歩なのか、そしてSvelteKitがどのようにして他のESMフレームワークのお手本となったのかを見ていきましょう。 何が起こったのか SvelteKit バージョン2.31.0 以降では、サーバーサイドインストルメンテーションと SvelteKit が生成するスパンを有効化できるようになり、サーバーサイドのトレースを大幅に強化できるようになりました。これは、SvelteKit アプリケーションにオブザーバビリティを追加したい人にとって大変朗報です。 理由は以下のとおりです。 まず、SvelteKit では instrumentation.server.js という専用ファイルを用いたテレメトリのインストゥルメンテーションがサポートされました。このファイルはサーバーサイドのインストゥルメンテーションを初期化します。ビルドの最終成果物に組み込まれ、OpenTelemetry のような自動インストゥルメンテーションが、サーバーサイドリクエスト処理の全体を確実に捕捉できるタイミングで評価されるようになっています。 さらに Svelte チームはそこで止まりませんでした。SvelteKit はリクエストハンドラー、load 関数、フォームアクション、さらにはリモート関数に対しても専用のスパンを発行するようになりました。これにより、アプリケーションのリクエストライフサイクルのどの部分が最も時間を消費しているのか、あるいはアプリケーション内の異なるパフォーマンス特性を理解することが、はるかに容易になりました。 そして極めつけに、Sentry の SvelteKit SDK はバージョン 10.8.0 以降で、この SvelteKit の公式インストゥルメンテーションとトレーシング機能に完全対応しています！ SvelteKit のオブザーバビリティを Sentry で使う方法
- [Sentry Logs 一般提供開始（ログはログ…でもついに実用化）](https://ichizoku.io/sentry/logs-generally-available/) - Article by: Dhrumil Parekh 本ブログの内容 何も壊れていないように見えても、裏で起きていることがわかる ジョブの実行（あるいは失敗）をリアルタイムで監視 UI のリグレッションが雪だるま式に膨らむ前に検知 これまでの反響は？ Logs の始め方 私たちが Sentry に Logs 機能を構築し始めたとき、目標は一つでした。それは、単なる大量のテキストストレージではなく、実際のデバッグに役立つものにすることです。そのために、初日から「トレースと接続」させることにしました。 これにより、アプリケーション内で発生するアクションやパフォーマンスとログを密接に結びつけ、開発者がエラーやパフォーマンス、レイテンシの問題を調査するまさにその場所で活用できるようにしたのです。 現在、Logs はベータ版を終了し、すべてのユーザーに一般公開されました。さらに嬉しいことに、ベータ期間中に皆さんから要望のあった数多くの機能を追加しています。 ライブテーリング（Live Tailing）：ログをリアルタイムにストリーミングし、修正の確認、長時間実行されるジョブの監視、または問題が発生した瞬間の特定に利用できます。 アラート（Alerts）：特定のログパターン（例: 繰り返される payment_status=declined）に基づいてトリガーし、ユーザーが報告する前に失敗を把握できます。 ダッシュボード（Dashboards）：ログの傾向を時系列で可視化します。たとえば Safari でのエラーレートの上昇や、新しい機能フラグに関連する突然のスパイクを確認できます。 チェックアウトの失敗、不安定なジョブ、ページロードの遅延。どんなデバッグであっても、Logs は重要なコンテキストを提供します。そして、それらの Logs が他のテレメトリー（トレース、エラー、リプレイ）と結びつけば、根本原因をより早く突き止めることができます。タブの切り替えも、タイムスタンプの計算も不要。ただ答えがあるだけです。 ここからは、Logs がどのようにして面倒な問題のデバッグを簡単にするのか、その実例をご紹介します。あるいは、今すぐドキュメントを参照してログ送信を始めて頂いても構いません。 何も壊れていないように見えても、裏で起きていることがわかる トレースと接続されたログは、見過ごされがちなサイレントな失敗を見つける フロントエンドは checkout.request を送信し、バックエンドは 200 を返し、問題は記録されません。例外も投げられません。 しかし、ユーザーは注文確認を受け取っていないと報告してきます。 Sentry でトレースを開くと、checkout.request のスパンは正常に見えますし、処理は成功しています。しかし、本来その後に続くはずの非同期処理 order.processed のスパンがありません。 checkout.request のスパンをクリックすると、そのスパンにスコープされたログが表示されます。
- [【Sentry＆エッジデプロイメント】レイテンシの測定と改善方法](https://ichizoku.io/sentry/how-to-measure-fix-latency-edge-deployments/) - Article by: Kyle Tryon 本ブログの内容 レイテンシの特定 なぜエッジコンピューティングが重要なのか エッジで計算するには？ TL;DR Google の研究者たちが 2017 年に行った調査によると、次のような結果が得られました。 ページの読み込み時間が 1 秒から 3 秒になると、ユーザーが離脱する確率は 32% 増加する。 これは8年以上も前の話です。そして正直なところ、それからユーザーの忍耐力が増したとは考えにくいでしょう。 Web Vitals とは、Google が定義した一連のパフォーマンス指標で、ユーザー体験を測定するためのものです。たとえば次のような要素に着目しています。 LCP（Largest Contentful Paint）：主要コンテンツが読み込まれるまでの時間 INP（Interaction to Next Paint）：ページが入力に反応するまでの速さ CLS（Cumulative Layout Shift）：アプリの視覚的な安定性（＝コンテンツが予期せずずれ動くかどうか） わずか 1 秒の遅延でさえ売上の減少や登録機会の損失につながる可能性があるため、あらゆる観点からレイテンシ（遅延）を調査することが重要です。 どれだけ最適化されたアプリケーションであっても、プルリクエスト（PR）だけでは解決できないボトルネックが少なくとも1つは存在します。それが「距離（distance）」です。 レイテンシの特定 見えないものは、直すことができません。 たとえば、あなたのサービスがアメリカ国内の単一サーバー上で稼働している場合、アジアやヨーロッパといったより遠方にいるユーザーは、単純にリクエストの移動距離が長くなるため、読み込み速度が遅くなるのは自然なことです。 ここでは、Sentry を使って地域ごとのレイテンシの影響を測定・可視化するための基本的なセットアップ手順を紹介します。 テスト環境の構築 今回は、フロントエンドアプリとバックエンド API
- [【React Native】パフォーマンス改善戦略：最新の手法とツール](https://ichizoku.io/sentry/react-native-performance-strategies-tools/) - Article by: Simon Grimm 本記事は、Galaxies.dev の創業者である Simon Grimm によるゲスト投稿です。Galaxies.dev は、ハンズオン形式のコース、専門家のガイダンス、そして個別サポートを通じて、開発者が React Native を習得できるよう支援するプラットフォームです。 React Native のパフォーマンスは、これまで以上に重要になっています。 新しいアーキテクチャが安定版となり、アプリが電光石火のネイティブ体験と競い合う中で、ユーザーは1秒未満の読み込み時間と滑らかな60fpsの操作感を期待しています。遅いアプリはユーザーを苛立たせるだけではなく、最終的な利益にも直結します。実際、100msの遅延でもコンバージョン率が7%低下し得ることを示す調査があります。 そこで、朗報です！ 新しいアーキテクチャを備えた React Native 0.80 以降に、Expo Router や Reanimated 4 といった最新ツール、そして Sentry による包括的なモニタリングを組み合わせることで、開発者は高パフォーマンスなアプリを作るための強力な手段を手にできます。ただし、大きな力には、それに見合う技術が必要です。 本ガイドでは、起動時の最初の印象という重要な局面から、高負荷時でも滑らかなアニメーションを維持する方法まで、React Native アプリのパフォーマンスをあらゆる面で最適化するための実証済みの戦略を解説します。 本記事で扱う内容は次のとおりです。 操作可能になるまでの時間（TTI）の短縮する React の最適化 60フレーム/秒（FPS）を達成する リスト表示のパフォーマンスを改善する 丁寧な状態管理 各トピックには、今日から実装できる実際のコード例と実践的なツール選定のおすすめを含めています。 さらに、Sentry が提供するシグナル（指標）を見ながら、アプリ内で何が起きているのか、そしてどう直せばよいのかを理解する方法も掘り下げます。 React Native アプリを、パフォーマンスの強力なアプリへと変えていきましょう。 1. 操作可能になるまでの時間（TTI）を短縮する TTI はアプリ起動後に「使える状態」になるまでの速さを測る指標です。アプリアイコンをタップしてから、ラグや処理中スピナーで待たされることなく、ユーザーが実際に
- [【MCPサーバー構築後】Sentryでクライアント・ツール・リクエストを追跡](https://ichizoku.io/sentry/introducing-mcp-server-monitoring/) - Article by: Sasha Blumenfeld, Miguel Betegón 本日（2025/8/14）より、MCP SDK 実装に計測コードを1行入れるだけで、サーバーサイド JavaScript SDK ベースの MCP サーバーの多くを計測できるようになりました。 これを導入すれば、MCP 実装全体にわたって、プロトコルの利用状況、クライアントの利用状況、トラフィック、ツールの利用状況、パフォーマンスといった詳細を確認できるようになります。 2025年の初めに私たち自身の MCP（Model Context Protocol）サーバーを公開した際の目的はシンプルでした。AI エージェントが Sentry のコンテキストを使って、ユーザーのアプリケーション上の問題をリアルタイムにデバッグできるようにすることです。 共同創業者の David Cramer も、有名な辛口コメントをシェアしているように、標準が頻繁に変わる新技術を前提に開発するのは簡単ではありません。 ここ数か月の間に、MCP が Streamable HTTP に標準化され、OAuth サポートが改善され、新しい仕様（spec）が導入されるなど、（控えめに言っても）多くの「調整」が行われていくのを見てきました。 ユーザーが簡単に導入できること、そしてユーザーベースが直面する複雑なユースケースをサポートすることを念頭に、MCP サーバーを「最先端」で構築してきました。リモートホストされるステートフルな MCP サーバー、OAuth のサポート、Seer や自然言語検索といった機能の追加など、最先端の要素に踏み込むことには、モニタリングとオブザーバビリティの面で固有の課題が伴いました。 それに加えて、Sentry の規模もあり、MCP サーバーの利用は非常に速いペースで増加しました。数千のユーザーが利用し、月間 5,000 万リクエスト（そして増加中）に達しています。 Sentry MCP サーバーを構築する中で、MCP サーバー監視におけるギャップがどこにあるのかを把握し始めました。エラーの詳細や MCP 内で現れる厄介なエッジケースの詳細を捉えるのは容易ではありません。ツール呼び出しにおけるパフォーマンス問題は診断が難しく、さらにツール呼び出しの特定の入力・出力に関する課題も、MCP の監視という観点では現時点で未成熟な領域です。
- [よくある Unity エラーと対処法](https://ichizoku.io/sentry/common-unity-errors-how-to-fix-them/) - Article by: Abuld D. Unity では、開発中に思いがけない挙動に出会うことがあります。ホットリロード直後のプレイモードのフリーズ、突然広がるピンク一色のマテリアル、あるいは「transform はずっと null でしたよ」と丁寧に思い出させてくるスタックトレースなど。そんな瞬間にスプリントの残りが崩されないように、本記事では実行時によくある厄介者を4つに絞り、それぞれをどう再現し、どう見分け、どう直すかを具体的に紹介します。 扱う内容は次のとおりです。 NullReferenceException: Object reference not set to an instance（オブジェクト参照がインスタンスに設定されていません） IndexOutOfRangeException: Array index problems（配列／リストのインデックスが範囲外です） MissingComponentException: Component not found（必要なコンポーネントが見つかりません） MissingReferenceException: Destroyed object access（破棄済みオブジェクトへの参照にアクセスしています） 具体性を担保するために、まっさらな HDRP サンプルプロジェクト上で各エラーをすべて作り直し、余計なものを省いた SentryCube スクリプトを組み込んで、問題（と修正）がリアルタイムでどう起きるかを確認できるようにしました。コードをそのままコピーしても良いですし、コンソールに出ている内容に一致するスニペットだけ流し読みしても良いですし、解決策セクションに飛んでも構いません。とにかく、より早く開発に戻れるやり方で進めてください。 1. Unity で NullReferenceException（Object reference not set to an instance）を修正する方法 このエラーはスクリプトが null の参照を使おうとしたときに発生します。ゲームのコンソールやログファイルでは、通常次のような表示になります。 UnassignedReferenceException: The
- [エージェントは「見えていないもの」は修正できない](https://ichizoku.io/sentry/agents-need-production-context/) - Article by: Sergiy Dybskiy （了読時間：5分） エージェントはバグ修正がどんどん得意になっています。ヘッドレスブラウザ、サンドボックス、シミュレーターといった仕組みのおかげで、自分の作業をテストする能力も向上しています。 しかし、本番環境に出荷した瞬間に混入してくるさまざまなブラウザ、言語、拡張機能、通信速度、その他の変数が絡み合って初めて現れるバグはどうでしょうか。あるいは、想定外の操作をする「人間ならではの行動」によって発生するバグは。 自己修復ソフトウェアのボトルネックは、エージェントの知能ではありません。エージェントが「実際に何が壊れたのか」をまったく把握できていないことです。エージェントはソースコードだけを手がかりにデバッグしており、これはREADMEを流し読みしてサーバー障害を診断しようとするのと同じくらい効果がありません。足りないのは、本番コンテキスト、つまりスタックトレース、リクエストのペイロード、実行環境、そして障害に至るまでの一連の出来事です。 エージェントには、本番環境で何が壊れているかを伝え、かつ「なぜ壊れたのか」を理解するために必要なコンテキストを渡す、何らかの仕組みが必要です。 私たちは、そのコンテキストを人間にも、そして人間と同様にますます重要な存在となっているエージェントにも提供するために、Sentry MCP と Sentry CLI を構築しました。今日からでも、「Sentryアラートがエージェントをトリガーし、エージェントが人間と同じ証拠を使って問題を調査し、修正を含むドラフトPRがブラウザを開く前にリポジトリに届く」というシステムを構築できます。 なぜ自動マージではなくドラフトPRなのか 現実的に何が可能かについて、正直に述べます。人間の関与なしに、自らパッチを検出・修正・テスト・デプロイ・監視まで完結させるシステムを今、構築すべきではありません。それは非常に刺激的なインシデントレビューを生むことになります。 有用なのはもっと控えめなものです。本番エラーが発生したら、エージェントが実際のSentryコンテキストを使って調査し、リグレッションテスト付きの小さな修正を書き、ドラフトPRを開く、というものです。人間が必ず確認するステップが残ります。 完全な自律化ではありませんが、意義のある変化です。多くのバグはキューの中で、トリアージされ、優先度付けされ、アサインされ、待機したまま、新機能に押しつぶされています。Seer は2分以内に根本原因を診断し、根本原因分析からPRのオープンまでを含む Autofix の完全な実行は、約6分で完了します。 たとえ最後のマージを人間が行うとしても、エラー発生から6分で修正PRが届く体制は、平均修復時間に確かなインパクトをもたらします。 エージェントに本番コンテキストを渡す2つの方法 Sentry MCP は、Model Context Protocolをサポートするエージェント（Claude Code、Cursor、Codex、Windsurf、VS Code with Copilot）に適した選択肢です。エージェントがホスト型サーバーに接続し、OAuthで認証すると、Issues、イベント、トレース、Seer分析への構造化されたアクセスが得られます。ローカルインストールは不要です。 ワンライナーに対応していないクライアントの場合は、設定を手動で追加してください。 Sentry CLI は、スクリプトによるワークフロー、CIパイプライン、あるいはjqにパイプしたり別のプロセスに渡したりするための構造化された出力が必要な自動化処理に適した選択肢です。 実際の動作例は次のとおりです。 CHECKOUT-P1 がトップに表示されています。チェックアウトサービスでのタイムアウトで、1.8kのイベントと86%の修正可能性スコアを持っています。詳細を確認してみましょう。
- [Sentry にプロダクト分析はもう揃っている](https://ichizoku.io/sentry/product-analytics-you-already-have/) - Article by: Rahul Chhabria 必要なものは、すでに手元にそろっています。 Sentry を使っているなら、トレース、構造化ログ、そして新たにアプリケーションメトリクスもあるはずです。多くのチームはデバッグ目的にしか使っていませんが、実はそのデータで、別チームが管理し、別のデータモデルを持ち、別の費用がかかる専用アナリティクスツールに投げていたプロダクトの大半の問いに答えられます（すべてではありません。ギャップについては後ほど正直にお伝えします）。 この記事は、プロダクトアナリティクスツールの存在意義を問うものではありません。開発者がプロダクトインサイトの宝の山の上に座りながら、その問いを他の誰かに外注してきたという事実についての記事です。そうしなくていいのです。 これが今、5年前より重要な意味を持つ理由があります。「プロダクトマネージャー」と「ソフトウェアエンジニア」の境界が曖昧になりつつあるからです。アップタイムやレイテンシだけでなく、採用率・リテンション・ユーザー行動まで考えることが、エンジニアにも求められるようになっています。プロダクトエンジニア（最近はもはや「エンジニア」と同義になりつつありますが）であれば、デバッグに使っているツールで、プロダクトに関する問いの答えを得ることができます。そういう使い方をしてこなかっただけで。 プロダクトの問いはすべて、手元のテレメトリにマッピングできる 「今週、オンボーディングを完了したユーザーは何人いるか？」 これはカウンターメトリクスです：metrics.count("onboarding.completed", 1)。プランの種類、国、流入元など、すでに設定している属性でスライスできます。 「地域別のチェックアウトレイテンシの p95 はどれくらいか？」 これはスパンのディストリビューションです。トレースにはすでにタイミング情報があります。あとはクエリするだけです。 「火曜日にサインアップが落ちたのはなぜか？」 これは構造化ログです。サインアップサービスは signup.failed を reason: email_validation_error や deploy_sha: a3f9b2c といった情報と一緒にログに記録しています。そのログはすでに、リクエスト全体のライフサイクルを示すトレース、エラーが発生したスパン、それを引き起こしたリリースと紐づいています。トレースからワンクリックで Issue に移動でき、Issue からコミットと原因となったコードの行へたどり着けます。 PM がアナリティクスツールに投げているのと同じ質問です。違いは、自分のテレメトリから答えるとき、その答えにはコンテキストが伴う点です。アナリティクスツールは「何が起きているか」を教えてくれます。テレメトリは「何が起きているか」「なぜ起きているか」、そして「責任のあるコードへの直接の道筋」までセットで教えてくれます。 あるクライアントから最近、こんな話を伺いました。アナリティクスツールが問題を知らせてくれるのは被害が出た後ばかりで、先手を打ちたいと。そのクライアントが辿り着いた答えは、すでに収集しているテレメトリにアラートとモニターを設定することでした。ビジネス上重要なメトリクスが下降傾向を示し始めたとき、週次のダッシュボードレビューで気づくより前にアラートが発動します。そしてそのアラートは完全なトレースと繋がったスパンやメトリクスに紐づいているため、別ツールへのコンテキストスイッチなしに、最初からコンテキストを持った状態で調査を始められます。収集するデータを変えたわけではなく、それをどう監視するかを変えたのです。 実際どのようなものか 新しいエクスポート機能のユーザー採用状況を把握したい、パフォーマンスを確認したい、有料ユーザーと無料ユーザーの挙動の違いも見たい、というケースを考えてみましょう。 アナリティクスツールへのインストルメントチケットを作成する必要はありません。スパン、構造化ログ、アプリケーションメトリクスという3つの基本要素がすでに手元にあります。 リクエストレベルのコンテキストにはスパン。 スパンはリクエストがシステムをどう流れ、各処理にどれだけ時間がかかっているかを示します。エクスポート API ハンドラーにはすでにスパンがあります。そこにビジネスレベルの属性（プランでスライスできる export.user_tier など）を追加しましょう。 採用状況、パフォーマンス、エラーを一か所でクエリしてみましょう。 すでにストーリーが見えてきます。xlsx エクスポートは csv の 3〜4 倍遅く、無料プランの xlsx は
- [ダッシュボードをエージェントで作成・編集する新しい方法](https://ichizoku.io/sentry/dashboard-updates/) - Article by: Ben Coe , Steve Zegalia AIエージェントが当たり前になった世界では、チームが重要な KPI を追跡するためにビジュアライゼーションを手作業でじっくり組み上げていく、従来型のダッシュボードワークフローは終わりを迎えつつあります。 数年前、エージェントがあらゆる場面で利用されるようになる前、私たちは開発者が重要なユーザー体験を監視しやすくしようと取り組んでいました。その成果として Insights ページを導入しました。これは事前に設定されたダッシュボードで、Web Vitals や Mobile Vitals といった一般的な健全性シグナルをあらゆる Sentry ユーザーがすぐに活用できるようにしたものです。 考え方は正しかったものの、問題がありました。多くの企業が共通のシグナルを持つ一方、各組織はそれぞれ固有の事情を抱えています。意味のあるカスタマイズができなければ、ほとんどのチームは結局、手作業でダッシュボードを構築する作業を延々とこなす羽目になっていました。そこで私たちは改善を続けました。 オンデマンドでカスタマイズ可能なダッシュボードをついに現実のものにしたのは、大規模言語モデルです。ビジュアライゼーションは、人間にとってもエージェントにとっても、最も情報密度の高いコミュニケーション手段のひとつであり続けていますが、変わったのはそのビューを作成するコストです。 ウィジェットをひとつひとつ組み合わせてダッシュボードを作る代わりに、エージェントに指示して Sentry 上で直接ダッシュボードを作成・編集したり、Sentry CLI で他のモデルと連携して目的に合わせたダッシュボードを生成したりできるようになりました。 Insights ページはSentry Built Dashboards になりました。クローンし、エージェントにプロジェクト向けのカスタマイズを依頼できます。ダッシュボードは数秒で作成でき、プロジェクトや調査の期間中使い続け、必要がなくなれば廃棄することができます。 新機能まとめ エージェントによるダッシュボード作成・編集（ベータ版）： AI 機能が有効化されているすべての組織で、エージェントを活用したチャット体験を通じて Sentry でダッシュボードを作成・編集できるようになりました。 Insights が Sentry Dashboards に： Insights ページをクローンし、編集可能な Sentry Dashboards に置き換えました。特定のユースケースに合わせてカスタマイズできます。 Sentry CLI によるダッシュボード作成・編集： 新しい Sentry CLI を使って、ターミナルから
- [【Sentry & OpenTelemetry】併用する方法](https://ichizoku.io/sentry/sentry-opentelemetry-work-together/) - Article by: Lazar Nikolov 要約：バックエンドがすでにOpenTelemetryを使っているなら、環境変数をいくつか変更するだけでトレースとログをSentryへ送信できます。SDKの置き換えも、インストルメンテーションの書き直しも不要です。OTLPエクスポーターの送信先をSentryのエンドポイントに向け、フロントエンドにはブラウザコンテキスト用のSentry SDKを追加するだけで、クリックからバックエンドのスパンまで1本につながったトレースが手に入ります。 バックエンドはすでに OpenTelemetry でインストルメントしている。サービスはスパンを出力している。チームは OTel の API に慣れている。すでに Collector を運用しているかもしれない。そこで Sentry を評価し始めると、当然こんな疑問が生まれます。 OpenTelemetry の構成を Sentry SDK に置き換える必要があるのだろうか。 答えはノーです。 現実的な答えとしては、OpenTelemetry がすでに機能しているところはそのまま使い続け、より多くのアプリケーションコンテキストが得られる箇所に Sentry SDK を追加し、OpenTelemetry Protocol（OTLP）イベントを Sentry に送信する。Webアプリであれば、フロントエンドにはブラウザトレーシング、エラー、ログ、Session Replay、ソースマップのために Sentry SDK を使い、バックエンドの既存サービスインストルメンテーションには OpenTelemetry をそのまま使う、というケースが多いです。 スコープの補足：OTLPはトレース、ログ、メトリクスを扱えます。現時点では、SentryのOTLPインジェストはログとトレースをサポートしており、メトリクスはサポートしていません。将来的にサポートを追加することを検討しています。 重要なのは、よく混同されがちな2つの判断を分けて考えることです。 フロントエンドとバックエンドでトレースをどのようにつなげるか。 バックエンドのOTLPイベントをどのようにSentryへエクスポートするか。 この2つを分けて考えると、アーキテクチャがずっとシンプルに整理できます。 Sentry vs OpenTelemetry は問い方が間違っている 最初の判断はトレースの連結です。ユーザーがReactアプリのボタンをクリックし、そのクリックがバックエンドへのリクエストをトリガーする場合、フロントエンドとバックエンドは同じ分散トレースコンテキストで合意する必要があります。この例では、Sentry フロントエンド SDK
- [CMSを削除してビルド時間を1/3に短縮した話](https://ichizoku.io/sentry/cut-build-times-delete-cms/) - Article by: Eli Lennox（了読時間：11分） Sentryでは、ものが壊れないことに執念を燃やし、それこそが私たちの存在意義だと考えています。しかしかつて、自社のマーケティングサイトがその信念を揺るがしてしまう時期がありました。 sentry.io 上で皆さんが目にするもの（マーケティングサイト、ブログ、オープンソースのマイクロサイトなど）の多くは、従来のヘッドレスCMSを基盤とした古いGatsbyサイト群で動いていました。理論上は機能していましたが、実際には壊れやすいプラグインの寄せ集め、制限の多いスキーマ、そして肝心な出荷タイミングに限って失敗する外部API依存に振り回されていました。 そこで私たちは、まともなエンジニアリングチームなら当然そうするように、それをすっぱり捨てて、Astro、Markdown、AI駆動の自動化で置き換えました。 問題：「ヘッドレス」という頭痛の種 旧スタックは、不必要に複雑な代物になりつつありました。 ビルドのボトルネック：Gatsbyの統合データレイヤーは便利でしたが、コンテンツが増えるにつれてビルド時間は1回あたり約14分に膨らんでいました。1日平均95回のビルドを行っていたため、毎日約22時間分のビルド時間を消費していました。 CMSのコスト：約2,500ページのコンテンツを1つのCMSインスタンスで管理していました。ページスキーマとコンポーネントスキーマが並立しており、条件付きフィールドが使えなかったため、スキーマの上限に達しないよう条件付きフィールドのプラグインを別途購入する羽目になりました。月額サブスクリプションに加えて年間サブスクリプションのコストも重なり、それでもスケーラビリティは限られたままでした。 外部依存の脆さ：すべてのビルドがGatsbyプラグイン経由で外部のCMSとマーケティングオートメーションシステムのAPIに依存していました。リビルド開始前の最後の1か月で、CMSのGatsbyプラグインが1日に3〜5回失敗し（サポートチケットを提出しても解決策はなし）、マーケティングオートメーションAPIもレート制限で1日に複数回失敗していました（詳しくは後述）。 解決策：Astroと「ただのファイル」の力 フレームワークをAstroに移行しました。モダンなWeb向けに設計されており、デフォルトで高速、そして驚くほど柔軟性が高いことを選定理由としました。 Viteによる高速化：Viteへの移行により、ローカル開発と本番ビルドがようやく2026年らしい速度になりました。ビルド時間は約14分から4分未満に短縮され、1日あたり約15.8時間分のビルド時間を節約できています。 フレームワーク非依存：Astroは目的に最適なツールを使う自由を与えてくれます。コンポーネントにReactが適していればReactを使い、シンプルな静的コンテンツであればHTML/CSSで済みます。 Vercelに重い処理を任せる：画像処理をVercelにオフロードすることで、ビルドプロセスを遅らせることなくアセットを最適化できています。 しかし最大の変化はフレームワークではなく、コンテンツの管理方法でした。ヘッドレスCMSのUIをMarkdownとFrontmatterに置き換えたのです。 AIネイティブなコンテンツ管理（SaaSの肥大化なし） CMSプロバイダーの「AIアドオン」にお金を払う代わりに、Claude Skillsとの直接連携を自前で構築しました。 今ではサイトを更新する際、肥大化したダッシュボードにログインする必要はありません。スキルを使ったワークフローで作業します。 1. ユーザーをガイドしながら、MarkdownファイルとFrontmatterを正確に更新するプロセスを進めます。 2. ライブプレビューを生成します。 3. レビュー用のPull Requestの下書きを作成します。 CMS統合AIを使わず、なぜカスタム構築にしたのか。 依存ゼロ：コンテンツはリポジトリに置かれます。APIの障害がなければビルドの失敗もありません。 スキーマの制限なし：Frontmatterで構造を自分たちで定義します。新しいフィールドやスキーマタイプが必要になれば、追加するだけです。サブスクリプションの制限も、プランの縛りもありません。 「Sentryらしい」やり方：深い技術志向を持つデベロッパーファーストの企業として、コンテンツをコードとして管理することは自然な選択です。バージョン管理され、ピアレビューされ、レンダリングするコンポーネントのすぐそばに置かれます。 実施プロセス マーケティングサイトとブログ合わせて約2,500ページのサイトを移行するのは、大規模なプロジェクトです。チームは2.5人の開発者で、期間は2か月でした。 チームが小さく、サイトの規模が大きかったため、コーディングの多くをClaude Codeに頼りました。開発者たちは計画立案、スコープ定義、要件整理に時間の大半を費やし、コードのレビュー、変更の指示、アウトプットの調整を行いました。 スコープ定義 このプロジェクトでは、次の2つの理由からスコープ定義が比較的容易でした。 これらのWebサイトにはモノレポを使用しているため、ボットがビルド・移行対象の全体像を把握できていた。
- [【エラー・トレース・ログ・メトリクス】いつ何を使うか](https://ichizoku.io/sentry/errors-traces-logs-metrics-when-to-reach-for-what/) - Article by: Sergiy Dybskiy （読了時間：12分） コードをインストルメントするとき、「ログを使うべきか、トレースか、メトリクスか」という問いに何度もぶつかります。コーディングエージェントも同じ壁にぶつかっているのを目にします。答えは明白なように思えますが、実はそうでもありません。エラー・トレース・ログ・メトリクス は、アプリの大半を支える4種類のテレメトリです。 4つはいずれも同じ道具箱に入ったツールであり、役割も重なる部分が多いため、正直なところ答えは開発者の口癖である「場合によります」です。ログに記録するはずのコンテキストをスパンの属性として持たせることもできますし、メトリクスを出力する代わりにログイベントをカウントすることもできます。また、duration を追加してスパンと見なすこともできます。 [スパイダーマンのミームを入れようとしたのですが、法務部門から著作権侵害になると言われたので削除しました。] ただし、「できる」と「すべき」は別の話です。各シグナルは異なる問いに答えるために存在しており、届いた後のワークフローもそれぞれ異なります。しっかりとした指針がなければ、慣れ親しんだものや既にあるものに手を伸ばしてしまい、他の種類のシグナルが本来何のためにあるかを見落としてしまいます。 この記事は、自分自身とエージェントのために書きたかった指針です。スキルだけ欲しい方は末尾まで読み飛ばしてください。 Sentry では、エラー・トレース・ログ・メトリクスのすべてがひとつの SDK から取得でき、すべてのプランに含まれています。エラーと Sentry Tracing は長年使われてきた機能ですが（それぞれ 2012年 と 2020年 から）、構造化ログは昨年追加され、Application Metrics は今年5月にラインナップが完成しました。Sentry をしばらく使っているなら、エラーとトレースはすでに送信されているはずです。ログとメトリクスは、テレメトリの全体像を完成させるための、残りの道具です。 エラー・トレース・ログ・メトリクス：それぞれが答える問い エラー：「何が壊れたのか」 スタックトレースと例外の種類が、Issue としてグルーピングされ、重複排除・アサイン・解決まで追跡されます。コードが例外を投げたなら、それはエラーです。 トレース：「リクエストは想定どおりに送信されたのか」 トレースは、タイミング付きのスパンのウォーターフォールです。リクエストがサービスを横断して、どのように送信されたかを追跡し、時間の使われ方を把握するためのものです。遅くなったDBクエリ、タイムアウトしたAPI呼び出し、200msのはずが8秒かかったLLMのツール呼び出しなどが見えてきます。 メトリクス：「時系列でどう推移しているのか」 Counter・Gauge・Distribution として保持され、任意の属性でスライスでき、集計値から背後にあるサンプル（およびトレース）まで掘り下げられます。「今週のチェックアウト件数は12,000件」という数字だけでなく、米国から8,400件・EUから2,600件・その他から1,000件という内訳も、直近のデプロイ前後で数値がどのように推移したかも把握できます。メトリクスは現在だけでなく過去のシグナルでもあるため、ダッシュボードやアラートとの相性が抜群です。（ただし Sentry ではほぼすべてのシグナルにアラートを設定できます。） ログ：「コードのこの箇所で何が起きていたのか」 コードのある瞬間のシステム状態を構造化イベントとして記録したものです。設定値・フィーチャーフラグ・関数の入出力・ユーザーIDなどが含まれます。ログは関数の意思決定ツリーをたどる手掛かりです。コードが分岐する地点に残すマーカーであり、後から人間やエージェントがその判断の流れを追えるようにします。エラーとトレースが「何が壊れたか」「どこに時間がかかったか」を教えてくれた後、「なぜ」を補うのがログです。 実例（に近いもの） React フロントエンドと Python API を持つストアフロントを運営しているとします。サポートからチケットが転送されてくるようになりました。アカウントページの商品レコメンドが、ログイン済みの一部ユーザーに対して汎用的な内容（パーソナライズされたおすすめではなくベストセラー）を表示しているというのです。どうも様子が変です。 何かクラッシュしていないか？ 最初に確認するのは Issues です。React アプリに例外はなく、リクエストも失敗しておらず、/recommendations/{user_id}
- [自分の環境では動くのに… AIでバグ再現を自動化する方法](https://ichizoku.io/sentry/ai-bug-reproduction/) - Article by: Neel Shah（読了時間：4分） Sentry の SDK チームは、幅広い言語とフレームワークのエコシステムにわたって SDK を開発・サポートしています。公開パッケージの正確な一覧はリリースレジストリをご覧ください。現在、エコシステム全体で 159 のパッケージを公開しています。あなたが使っているものも、Sentry がサポートしているものかもしれません。 これらの SDK はすべてオープンソースであり、それぞれ独自の GitHub リポジトリ（JavaScript 版はこちら）として日々メンテナンスしています。そしてどのオープンソースプロジェクトとも同様に、大量のバグ報告や Issue が寄せられます。 この記事では、再現フローをスムーズにしてトリアージの時間と疲労を軽減するために活用してきた Claude スキルについてお話しします。 バグのトリアージフロー null チェックの漏れ、条件分岐の見落とし、その他の小さなミスなど、修正が簡単なバグもあります。 しかし、そうではないバグも多く存在します。理由はさまざまです。 環境を整えるだけでも面倒な「ボイラープレート」 難解なコードパス レガシーバージョン 誰も想定しなかったエッジケースの組み合わせ データ競合などの並行処理の問題 異なる契約を持つフォーク済みライブラリ ボイラープレート 特に SDK のバグでは、ボイラープレートコードが多いことが大きな負担です。 最近の例を見てみましょう。このバグを再現するには、以下のセットアップが必要です。 正しいバージョンの Python venv 正しいバージョンの Django ボイラープレートアプリ 正しいバージョンの Sentry SDK HTTPS プロキシ限定の問題を再現・確認できる
- [【Sentry Snapshots ベータ公開】スナップショットテストでビジュアルリグレッションを検出](https://ichizoku.io/sentry/snapshots-available-beta/) - Article by: Max Topolsky（読了時間：6分） 要約 — Sentry Snapshots がベータ公開されました。（英語記事公開日2026/6/11）CI でスクリーンショットの差分を検出し、意図しないビジュアルの変更を検知、フロントエンドを持つあらゆるプラットフォームに対応。まずはSnapshots のドキュメントから始めてください。 Sentry Snapshotsは、コミットのたびにスクリーンショットを比較し、表示内容に変更があった場合はPRをブロックして、その変更が意図したものかどうかを確認できます。ユーザーが実際に目にし、操作するのはコードではなくアプリケーションです。Snapshotsは、そのユーザー体験を手軽に検証するための仕組みです。 コードの変更はかつてないほど簡単になりましたが、同時に、スピードのために品質を犠牲にする可能性も高くなっています。現代のコードベースには、正しさを担保するためのガードレールが必要です。Snapshots でめざしているのは、コードへのチェック機能と、ワークフローを改善するためのリソースを提供することです。 スナップショットテストとは スナップショットテストの基本的な流れはシンプルです。 コードを変更する アプリケーションのスクリーンショットを生成する そのスクリーンショットをベースラインと比較する 変更箇所を表示する Sentry Snapshots では、スクリーンショットをアップロードすると差分を比較し、差分があれば PR にコメントします。 その後 UI に移動して、具体的にどのような変更があるかを確認できます。 このシンプルなワークフローにより、ビジュアルのカバレッジという新しい軸が加わり、異なるテーマ・言語・ビューポートでアプリケーションが期待通りに表示されているかをテストできます。スナップショットテストは、意図した以上の変更が行われていないかを検証します。 Sentry Snapshots とエージェントの連携 従来からビジュアル変更に対するガードレールとして利用されてきたスナップショットテストは、AIエージェントによる開発でも特に有効です。たとえ雑なプロンプトでエージェントが変更を加えたとしても、スナップショットテストを実行し、変更が検出されればPRをブロックできます。 しかし Snapshots はエージェントが「活用する」アーティファクトにもなり得ます。最近、Snapshots 自体のビジュアル変更を行う際に Snapshots を活用した流れをご紹介します。 課題 複数のユーザーから「Snapshot Toolbar」に関して似たようなフィードバックが寄せられていました。 最初に表示される赤い「差分マスク」の意味が分からない マスクを非表示にしたいが方法が分からない（実際には可能） 差分ビューを切り替えたいが、操作方法が見つからない 要するに、既存機能の見つけにくさが課題でした。
- [【Seer エージェント】答えはすでに Sentry の中に。あとは尋ねるだけ](https://ichizoku.io/sentry/introducing-seer-agent/) - Article by: Rahul Chhabria 要約：Seerエージェントをリリースします。これは、Sentry があなたのアプリについて把握しているあらゆる情報をもとに、質問して答えを得られる機能です。本日より、すべてのユーザー向けにベータ提供を開始します。Sentry 上で Cmd + / を押すか、Slack でメンションするだけで、さまざまな問題の解決に活用できます。どれほど便利か、ぜひ続きを読んでみてください。 これは、あるエンジニアにとって、ひどい夜になっていてもおかしくなかったのに、結果的には……そこまで悪くならなかった、という話です。 数週間前の土曜日、私たちの AI デバッガー Seer が障害を起こし始めました。 右側にある大きくて恐ろしいスパイクに注目してください。 エラーは、LLM 呼び出しに関する一般的な失敗メッセージで、根本原因を示すような情報は何もありませんでした。その週末は、チームの大半がオンコール予定ではなく、たまたま AI 部門責任者の Indragie がオンラインでした。彼はエンジニアたちを呼び出し始めました。 他のメンバーがオンラインになるのを待つ間、彼はここ数か月間、社内でテストしていたツールを開きました。それが Seerエージェントです。Indragie は、現在見えている状況を Seerエージェントに伝え、「何が起きているのか調べてほしい」と依頼しました。すると、数秒で結果が返ってきました。モデル呼び出しは、特定モデルに対して、特定リージョンでレート制限を受けていました。しかも、こちら側ではトラフィックを処理するための十分なスループットを確保していたにもかかわらずです。 最終的にこのレート制限は、プロバイダー側の上流インフラ障害による症状だったことが、インシデント後に確認されました。しかし、その時点ですでに Seerエージェントは、「どのリージョン」「どのモデル」に問題が集中しているかを正確に示しており、問題がプロバイダー側にあることは明らかでした。それ以外の部分は、すべて正常でした。 これは本来であれば、誰かがダッシュボードを開き、リージョンごとにフィルタし、トラフィックとエラー率を突き合わせ、その傾向に気づき、「なぜ特定リージョンだけで問題が起きているのか」を逆算していく、そんな流れで進むタイプの調査です。Indragie は非常に優秀ですが、日々コードベースに直接関わっているわけではありません。彼はマネジメント側です ;) なので、そこへたどり着くまでには少なくとも30分はかかっていたと思います。正直に言えば、もっと長かったでしょう。 オンコール担当のエンジニアがチャンネルに参加する前には、すでに根本原因まで特定できていました。 それこそが、Seerエージェントの役割です。「Twitter で大騒ぎになるレベルの大規模障害」から、「何か遅いけれど理由が分からない」といった問題まで、アプリケーション内で起きているあらゆる問題を調査するためのツールです。 本日（2026/4/28）、Seerエージェントをオープンベータとして、すべてのユーザー向けに提供開始します。 問題は必ずしも Issue とは限らない Seer の当初のコンセプトはシンプルでした。Sentry が Issue を検知すると、Seer がスタックトレース、トレースデータ、ログ、リプレイ、コミット履歴、コードを読み取り、「何が問題なのか」を説明する、というものです。これがうまく機能するのは、調査の出発点が明確だからです。つまり、「Issue」が存在し、必要なデータもすでにそこへ紐づいています。 ですが、実際のデバッグは、必ずしもエラーから始まるわけではありません。 ときには、Indragie のケースのように始まります。Issue 自体は存在しているものの、エラーメッセージはあまり役に立たず、本当の問題はスタックトレースでは届かない上流側にある、というケースです。
- [【Sentry】Perforce 連携　正式リリース](https://ichizoku.io/sentry/perforce-integration-ga/) - Article by: Amir Mujacic 要約 Sentry が Perforce P4 とネイティブ連携するようになりました。これにより、Perforce を利用するチームでも、スタックトレースのリンク、suspect commit の特定、オンデマンドのソースコンテキスト表示、P4 Code Review との連携を利用できます。integration の導入はこちらから始められます。 Perforce と Sentry の連携 ゲーム開発、VFX、あるいは大容量のバイナリアセットを扱う業界で働いているなら、あなたのコードベースは Perforce P4 上にある可能性が高いでしょう。Perforce P4 は、世界でも最大級のゲームやクリエイティブプロジェクトを支えるバージョン管理システムです。そして、これまで Sentry が正式サポートしていなかった最後の主要 SCM のひとつでもありました。 本日（2026年4月29日）、その状況が変わります。Sentry + Perforce P4 integration が、すべての Sentry organization 向けに正式リリースされました。 利用できる機能 この integration により、P4 サーバーを Sentry と直接接続できるようになり、Git ベースのチームが長年利用してきた、ソースコード連携型のデバッグワークフローを利用できます。 スタックトレースリンク

## Webinars

- [Silicon Valley Trip Report #03 - The AI Conference 2025 シリコンバレーから学ぶ日本への示唆](https://ichizoku.io/resources/webinar/silicon-valley-trip-report-03-the-ai-conference-2025-lessons-for-japan-from-silicon-valley/)
- [Silicon Valley Trip Report #02 - AI Dev 25 AIエージェントメモリ](https://ichizoku.io/resources/webinar/silicon-valley-trip-report-02-ai-dev-25-ai-agent-memory/)
- [Silicon Valley Trip Report #01 - Arize Observe 2024 シリコンバレーのAIエコシステム](https://ichizoku.io/resources/webinar/silicon-valley-trip-report-01-arize-observe-2024-silicon-valleys-ai-ecosystem/)

## Categories

- [Uncategorized](https://ichizoku.io/category/ai-blog/uncategorized/)
- [News](https://ichizoku.io/category/news/)
- [Retrieval Augmented Generation](https://ichizoku.io/category/ai-blog/retrieval-augmented-generation/)
- [Banking](https://ichizoku.io/category/ai-blog/banking/)
- [HITL (Human In The Loop)](https://ichizoku.io/category/ai-blog/hitl-human-in-the-loop/)
- [AI Blog](https://ichizoku.io/category/ai-blog/)
- [Automotive](https://ichizoku.io/category/ai-blog/automotive/)
- [Arize AI](https://ichizoku.io/category/arize-ai/)
- [Sentry Blog](https://ichizoku.io/category/sentry-blog/)
- [Sub1](https://ichizoku.io/category/arize-ai/sub1/)
- [Digital Intelligence Onboarding](https://ichizoku.io/category/ai-blog/digital-intelligence-onboarding/)
- [Silicon Valley Trip Report](https://ichizoku.io/category/ai-blog/silicon-valley-trip-report/)
- [Case Study](https://ichizoku.io/category/case-study/)
- [Sentry](https://ichizoku.io/category/case-study/sentry-case-study/)

## Tags

- [LLM](https://ichizoku.io/tag/llm/)
- [RAG](https://ichizoku.io/tag/rag/)
- [Retrieval Augmented Generation](https://ichizoku.io/tag/retrieval-augmented-generation/)
- [クエリ変換](https://ichizoku.io/tag/クエリ変換/)
- [チャンクサイズ](https://ichizoku.io/tag/チャンクサイズ/)
- [チャンク方法](https://ichizoku.io/tag/チャンク方法/)
- [大規模言語モデル](https://ichizoku.io/tag/大規模言語モデル/)
- [言語モデル](https://ichizoku.io/tag/言語モデル/)
- [Banking](https://ichizoku.io/tag/banking/)
- [Goldman](https://ichizoku.io/tag/goldman/)
- [HITL](https://ichizoku.io/tag/hitl/)
- [Insurance](https://ichizoku.io/tag/insurance/)
- [Agentic AI](https://ichizoku.io/tag/agentic-ai/)
- [UVEye](https://ichizoku.io/tag/uveye/)
- [評価駆動開発](https://ichizoku.io/tag/評価駆動開発/)
- [APM](https://ichizoku.io/tag/apm/)
- [モバイル開発](https://ichizoku.io/tag/モバイル開発/)
- [sentry](https://ichizoku.io/tag/sentry/)
- [プレゼントキャペーン](https://ichizoku.io/tag/プレゼントキャペーン/)
- [日本語記事](https://ichizoku.io/tag/日本語記事/)
- [セッションリプレイ](https://ichizoku.io/tag/セッションリプレイ/)
- [Vue](https://ichizoku.io/tag/vue/)
- [Pinia](https://ichizoku.io/tag/pinia/)
- [Nuxt](https://ichizoku.io/tag/nuxt/)
- [Java](https://ichizoku.io/tag/java/)
- [ロギング](https://ichizoku.io/tag/ロギング/)
- [デバッグ](https://ichizoku.io/tag/デバッグ/)
- [Eclipse](https://ichizoku.io/tag/eclipse/)
- [Sentry Java SDK](https://ichizoku.io/tag/sentry-java-sdk/)
- [日経ムック](https://ichizoku.io/tag/日経ムック/)
- [エマージングテクノロジー](https://ichizoku.io/tag/エマージングテクノロジー/)
- [AI](https://ichizoku.io/tag/ai/)
- [生成AI](https://ichizoku.io/tag/生成ai/)
- [コンテキストエンジニアリング](https://ichizoku.io/tag/コンテキストエンジニアリング/)
- [コンテキストウィンドウ](https://ichizoku.io/tag/コンテキストウィンドウ/)
- [Cursor](https://ichizoku.io/tag/cursor/)
- [The AI Conference 2025](https://ichizoku.io/tag/the-ai-conference-2025/)
- [シリコンバレー](https://ichizoku.io/tag/シリコンバレー/)
- [未来の小売業](https://ichizoku.io/tag/未来の小売業/)
- [ハイパーパーソナライゼーション](https://ichizoku.io/tag/ハイパーパーソナライゼーション/)
- [リアルタイム対応](https://ichizoku.io/tag/リアルタイム対応/)
- [会話型AI](https://ichizoku.io/tag/会話型ai/)
- [相互運用性](https://ichizoku.io/tag/相互運用性/)
- [民主化](https://ichizoku.io/tag/民主化/)
- [AIエージェント](https://ichizoku.io/tag/aiエージェント/)
- [Case Studies](https://ichizoku.io/tag/case-studies/)
- [Dinii](https://ichizoku.io/tag/dinii/)
- [AIトランスフォーメーション](https://ichizoku.io/tag/aiトランスフォーメーション/)
- [フォワードデプロイドエンジニアリング](https://ichizoku.io/tag/フォワードデプロイドエンジニアリング/)
- [FDE](https://ichizoku.io/tag/fde/)
- [ナレッジワークAI](https://ichizoku.io/tag/ナレッジワークai/)
- [AIエグゼキューションギャップ](https://ichizoku.io/tag/aiエグゼキューションギャップ/)
- [FDEトレーニングカリキュラム](https://ichizoku.io/tag/fdeトレーニングカリキュラム/)
- [Tokenmaxxing](https://ichizoku.io/tag/tokenmaxxing/)
- [Ichizoku インテリジェントルーターレイヤー](https://ichizoku.io/tag/ichizoku-インテリジェントルーターレイヤー/)
- [Forward Deployed Engineer](https://ichizoku.io/tag/forward-deployed-engineer/)
- [AI-PAX 2026 大阪](https://ichizoku.io/tag/ai-pax-2026-大阪/)

## Sentry Categories

- [Sentry 機能 / Sentry Features](https://ichizoku.io/sentry-category/features/)
- [Sentry 活用・連携 / Sentry Use Cases & Integrations](https://ichizoku.io/sentry-category/use-cases-integrations/)
- [AI 関連 / AI related](https://ichizoku.io/sentry-category/ai-related/)
- [パフォーマンス・監視全般 / Performance Monitoring & Optimization](https://ichizoku.io/sentry-category/performance-monitoring-optimization/)
- [成功事例 / Case Studies](https://ichizoku.io/sentry-category/case-studies/)
- [SDK・プラットフォーム・ライブラリ / SDKs, Platforms & Libraries](https://ichizoku.io/sentry-category/sdks-platforms-libraries/)
- [Sentryでデバッグするヒント / Sentry Debugging Tips](https://ichizoku.io/sentry-category/debugging-tips/)