私立ずんだもん女学園放送部 podcast 20260123
内容紹介
Mackerel MCPサーバーを活用してAIでISUCONを解いてみよう——問題発見から改善まで全部AIで！、Human-in-the-Loop な AI エージェントを支えるガードレール設計 Wantedly Engineer Blog、AssetOpsBench: Bridging the Gap Between AI Agent Benchmarks and Industrial Reality
出演者
youtube版(スライド付き)
関連リンク
本記事は、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
ビジネス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は、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:ずんだもん