youtube版(スライド付き) 関連リンク Mackerel MCPサーバーを活用してAIでISUCONを解いてみよう——問題発見から改善まで全部AIで! 本記事は、Webアプリケーションのパフォーマンス改善を競う「ISUCON」を題材に、MackerelのAPM(Application Performance Management)機能と、新たに提供開始された「Mackerel MCPサーバー」を活用して、AIが自律的に問題を解決できるかを検証したレポートです。 「推測するな、計測せよ」をAIで実践 パフォーマンス改善の鉄則は、当てずっぽうでコードを直すのではなく、まず「どこが遅いのか」を正確に把握することです。今回の検証では、Mackerelを通じて以下のデータを収集し、AI(Claude Code等)がMackerel MCPサーバー経由でこれらのデータにアクセスできる環境を構築しました。 インフラ情報: CPUやメモリの使用率(ホストメトリック)アプリ情報: どのエンドポイントやDBクエリが遅いか(OpenTelemetryによるトレース) 特に、コードを書き換えずに計装できる「OBI(OpenTelemetry eBPF Instrumentation)」の活用についても触れられており、既存のシステムに手を加えにくい現場でも役立つTipsが紹介されています。 AIが自律的にスコアを27倍に向上 AIに対して「スコアの最大化」を目標とし、「Mackerel MCPサーバーなどのツール活用」と「改善プロセスの記録」を指示した結果、驚くべき成果が得られました。 結果: 初期状態の1,810点から、最終的には50,280点までスコアが上昇。改善の内容: AIは「特定のAPIレスポンスが遅いこと」と「その処理中にDBロックを保持していること」を特定。外部APIリクエストをトランザクション外に移動させるという、熟練エンジニアのような的確な判断を下しました。 新人エンジニアへのメッセージ この事例の重要なポイントは、AIにただ「直して」と頼むのではなく、「判断材料となる正確なデータ(観測性)」を与えた点にあります。Mackerelのような監視ツールでシステムを可視化することは、人間がデバッグしやすくなるだけでなく、AIを強力なパートナーとして活用するための必須条件になりつつあります。 ISUCONの過去問とMackerelの無料枠を活用すれば、誰でもこの「AIによる自律改善」を体験できます。最新のAI技術と「計測」の重要性を学ぶ第一歩として、非常に示唆に富む内容となっています。 引用元: https://mackerel.io/ja/blog/entry/tech/ai-isucon Human-in-the-Loop な AI エージェントを支えるガードレール設計 Wantedly Engineer Blog ビジネスSNS「Wantedly」が提供する、スカウト業務を自動化する「AIエージェントモード」を題材に、AIの安全性を担保する「ガードレール設計」の実践的な手法を解説した記事です。新人エンジニアの方でも理解しやすいよう、AIを実務に組み込む際の「信頼性の高め方」と「エラー対策」に焦点を当てて要約します。 1. なぜ「ガードレール」が必要なのか AIエージェントがユーザーの指示に従って動作する際、その出力が不適切だったり、安全性を欠いたりしてはいけません。そこで、AIの出力をチェックする「ガードレール層」を設けます。 一般的なサービス(AWSのマネージドサービス等)や単純なNGワード設定だけでは、採用業務特有の「文脈に沿った細かいニュアンス」を判定しきれません。そのため、Wantedlyでは「ドメイン知識をプロンプトとして与えた、ガードレール専用のLLM」を用意する設計を採用しました。 2. 回答の揺らぎを抑える「Self-consistency」 LLMは確率的に動作するため、同じ質問でも回答が毎回異なる「揺らぎ」が発生します。この不安定さを解消するために採用されたのがSelf-consistency(自己整合性)という手法です。 仕組み: 1回だけの判定で決めつけず、同じ指示に対して複数回(例:5回)推論を行います。判定方法: 各回の結果をスコアリングし、その「平均値」が一定の閾値を超えた場合にのみ「不適切(Unsafe)」と判断します。 これによって、1回の偶然の誤判定に左右されない、安定したガードレールが実現できます。 3. レート制限を回避する「リトライ戦略」 Self-consistencyで複数回のAPIコールを行うと、APIプロバイダーのレート制限(回数制限)に当たりやすくなります。これを回避するために、...
続きを読む
一部表示