Description

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つの質的な次元でエージェントを評価します。

1. タスク完了度: 要求された業務を完遂できたか
2. 検索精度: 必要な情報を正確に取得できたか
3. 結果の検証: 出力内容が妥当か自ら確認しているか
4. 手順の正当性: 実行プロセスの順序が正しいか
5. 明確さと正当化: 根拠を説明できているか
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:ずんだもん