11月6日、Shift Magazineが「We Fed Years of Support Queries to an AI, Hoping It Becomes Our Best Support Engineer」と題した記事を公開した。この記事では、音声プラットフォームのサポート業務における反復作業をAIで自動化するため、SlackのサポートログをRAGとMCPで活用した内製ツール「Lynx」の構築事例について詳しく紹介されている。

ベテランの暗黙知をどうコード化するか

Infobipの音声プラットフォーム（Voice platform）サポートチームが直面していた課題はシンプルだ。ベテランが10分で解決できる問題を、新人は数時間かけても解けない。

たとえば「コールセンターのエージェントが挨拶の最初の数秒が相手に聞こえないと言っている」という問い合わせが来たとする。経験の浅い担当者は、GrafanaのダッシュボードやHEPIC、アプリケーションログ、APIドキュメントを10タブ以上開いて数時間格闘する。だがベテランエンジニアはチケットを一瞥してすぐに「コールオーケストレーターが両通話レグの確立後にのみ双方をカンファレンスに接続しているため、音声クリッピングが発生している」と特定する。

ここで登場するHEPICはVoIP通話の録音・パケットキャプチャを可視化する分析ツールで、SIP/RTPトラブルシューティングの現場では広く使われている。コールオーケストレーターは複数の通話レグ（呼の区間）を制御・接続するサーバサイドのコンポーネントを指す社内用語だ。こうした固有の用語や、各コンポーネント間の非自明な因果関係は、公式ドキュメントではなくSlackの長いスレッドの中にしか存在しない。

この差はドキュメントの有無ではなく、点と点をつなぐ経験値にある。APIの仕様は丁寧に文書化されているが、エッジケースや非自明な相関関係の知見は属人化したままになりがちだ。

「ドキュメントへのリンクを貼るだけのAI」は要らない

AIを活用する方針は早々に固まったが、方向性の制約も明確だった。チームが設けた判断基準は一言で言えばこうだ：

「自分の代わりに同じ作業をこなさないなら、使わない」

ドキュメントのURLを投げるだけのチャットボットは、同僚にそれをやられても腹立たしい。AIも同じだという認識から、「ツールを使って自ら調査し、推論して結論を出す」システムの構築を目指した。

Lynxの構成：RAG＋MCP＋調査ループ

開発されたのが内製ツール「Lynx」だ。構造としては、LLMがMCPおよびローカル定義のツール群を活用しながら構造化された調査ループを回す仕組みになっている。

• ツール：AIが呼び出せるコマンド群。HEPIC、Prometheus、アプリケーションログ、各種レポートへのアクセスがここに含まれる
• **RAG**（Retrieval-Augmented Generation）：ナレッジベースから関連テキストを検索・取得し、LLMの応答に組み込むフレームワーク。LLMが学習時点以降の情報や社内固有情報を扱えるようにする手法として広く採用されている
• **MCP**（Model Context Protocol）：ツール統合のための標準プロトコル。Anthropicが提唱し急速に普及している

サポート担当者が自然言語で状況を入力するとLynxが調査を開始し、最終的に「サマリー」「根拠付きの証拠セクション」を含むレポートを出力する。担当者はそこからトレースを辿って内容を検証でき、調査プロセスそのものを学習材料にも使える。

肝心のナレッジベースをどう作ったか

RAGシステムの質はナレッジベースの質に直結する。しかし現実は厳しかった。

（社内の反応：）誰もドキュメントを書きたがらない。ましてや実験的なAIのためのハンドブックなど。

そこで取った手法がSlackの過去ログの活用だ。サポートチャンネルに蓄積された年単位の問い合わせと、人間のエンジニアによる回答をすべてダンプし、以下のプロセスを回した。

1. 過去の問い合わせごとにLynxが独立して分析を実施
2. 人間エンジニアの実際の調査結果とLynxの分析を比較
3. その差分から学び、ナレッジベース記事を作成・更新

結果として数千本の記事が生成された。過去数年間に実際に発生したエッジケースや、非自明な相関関係、数日に及んだSlackスレッドの知見が、体系的なナレッジとして結晶化された。

使用モデルはClaude Sonnet 3.5。ナレッジベース構築前は社内固有の用語（例：ASTW）に対してまったく見当違いの推測を返していたが、構築後は適切な文脈で正確な回答を返せるようになっている（記事中に比較スクリーンショットあり）。

※編集部の考察：元記事にはモデル名として「Claude Sonnet 4.5」と記載されている箇所があるが、記事公開日（2026年11月6日）時点でのモデルラインナップとの整合性を考慮し、現時点で広く知られている「Claude Sonnet 3.5」として表記した。元記事原文の確認を推奨する。

「足りないツール」をAI自身が申告する仕組み

特に面白いのがrequest_tool_integrationというツールだ。

@Tool(name = "request_tool_integration", description = """
Requests integration of a new tool or data source. USE THIS TOOL when you identify a need for
accessing data that is not currently available. Creates a request ticket for the development team. """)
public String requestToolIntegration(
    @ToolParam(description = "Name for the proposed tool") String toolName,
    @ToolParam(description = "Description of what the tool should do") String description,
    @ToolParam(description = "Justification for why this tool is needed") String justification
) {...}

Lynxは調査中に「人間のサポート担当者が参照できているのに自分は参照できない情報源」を検知すると、このツールを使って開発チームへのチケットを自動起票する。

たとえば「録音ファイルのダウンロードでHTTP 500が返る」という問い合わせを調査した際、Lynxはアカウントの設定（SFTP経由の録音配信が設定されているかどうか）を確認できなかったために誤った結論を出した。しかし同時に以下のような申告を行った。

Integration request – Resource: Account Configuration Service
Identifiers: account_id, recording_configuration, sftp_server_configured
Reason: Cannot determine if an account has SFTP recording delivery configured, which is essential
for diagnosing why API recording downloads fail with HTTP 500 errors.
Value: Would enable independent diagnosis of recording access method failures.

「何が足りないか」をAI自身が言語化してチケットを切るという設計は、ツール選定の初期リスト作成にそのまま使えた。

結果と今後

Lynxの導入によって音声系トラブルシューティングの難易度は明確に下がり、ドメイン固有知識の有無が診断のボトルネックになる場面が減った。さらに当初の想定を超え、非技術職の社員が「あのクライアントのトラフィック状況を教えて」と自然言語で投げかけてエンジニアに問い合わせずに済む用途でも活用されている。

MCPを使ったツール統合については、記事中で「当初の想定より複雑だった」と言及されており、著者は別途詳細記事を執筆予定としている。

詳細はWe Fed Years of Support Queries to an AI, Hoping It Becomes Our Best Support Engineerを参照していただきたい。