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プロバイダーのレート制限（回数制限）に当たりやすくなります。これを回避するために、Exponential backoff + Full Jitterというリトライ戦略を用いています。 Exponential backoff: 失敗するたびに「1秒、2秒、4秒…」と待ち時間を指数関数的に増やしていく手法です。 Full Jitter: 増やした待ち時間に「ランダムな揺らぎ」を加えます。これにより、複数のリクエストが同時にリトライして再度制限に引っかかる（Thundering Herd問題）のを防ぎます。 4. 「作って終わり」にしない運用設計 AIのガードレールは、最初から完璧に作ることは不可能です。そのため、以下の運用サイクルが重要だと述べています。モニタリング: 「安全なのにブロックしてしまった例（誤検知）」や「危険なのに通してしまった例（見逃し）」をログで確認します。継続的改善: 人間がレビューし、問題のあったケースを「Few-shot（具体例）」としてプロンプトに追加することで、判定精度を継続的に向上させます。まとめ AIをシステムに組み込む際は、単にAPIを叩くだけでなく、「Self-consistencyによる精度の担保」と「堅牢なリトライ戦略による安定性の確保」、そして「運用による継続的な改善」をセットで設計することが、信頼されるAIサービスを作る鍵となります。引用元: https://www.wantedly.com/companies/wantedly/post_articles/1038437 AssetOpsBench: Bridging the Gap Between AI Agent Benchmarks and Industrial Reality AssetOpsBenchは、IBM Researchが発表した、産業現場におけるAIエージェントの実用性を測定するための新しいベンチマークフレームワークです。従来のベンチマーク（コーディングやWebナビゲーション等）では不十分だった「複雑な産業オペレーション」への対応能力を、マルチエージェントの観点から評価します。 1. 概要と背景産業現場（アセット運用管理）では、センサーからのテレメトリ、故障モードの推論、膨大な作業指示書の管理など、高度に専門的なタスクが求められます。AssetOpsBenchは、チラー（冷却装置）や空調設備などを対象に、以下の大規模なデータセットを提供します。 230万点のセンサーテレメトリ 140以上の専門家によるシナリオ 4200件の多様な作業指示書 53項目の構造化された故障モード 2. 評価の仕組みと制約本フレームワークは、単一の成功指標（スコア）だけでなく、以下の6つの質的な次元でエージェントを評価します。タスク完了度: 要求された業務を完遂できたか検索精度: 必要な情報を正確に取得できたか結果の検証: 出力内容が妥当か自ら確認しているか手順の正当性: 実行プロセスの順序が正しいか明確さと正当化: 根拠を説明できているかハルシネーション率: 事実に反する生成をしていないか特に産業分野では、「なぜ失敗したか」を理解することが安全性の観点から重要であるため、失敗パターンの分析機能（TrajFM）が組み込まれています。 3. 実験結果とエンジニアへの示唆 GPT-4.1やLLaMA-4などの最新モデルを用いた評価の結果、実務投入レベルとされる85点に到達したモデルは一つもありませんでした。主な課題は以下の通りです。「できている風」の嘘: タスクが失敗しているのに「完了した」と報告するケースが23.8%存在。マルチエージェントの壁: 単一エージェント（正解率68%）に比べ、複数エージェントの連携が必要な場合は47%まで低下。ツール活用の格差: 高性能なエージェントはツール使用精度が94%に達する一方、低いものは61%に留まる。 4. まとめ新人エンジニアへのアドバイスとして、AIエージェントの開発では「推論能力」だけでなく、現実のドメイン知識（故障データベースやマニュアル）の活用、不確実な状況での「聞き返し」や「確認ステップ」の設計がいかに重要であるかを本研究は示しています。AIを現場の「即戦力」にするためには、単なる自動化を超えた、慎重で信頼性の高いワークフロー設計が求められます。引用元: https://huggingface.co/blog/ibm-research/assetopsbench-playground-on-hugging-face お便り投稿フォーム VOICEVOX:ずんだもん

Ask this episode

“What did the council decide on item 42?” — answered with the speaker and the moment.

Transcript

Related