モデル・コンテキスト・プロトコル(MCP)についてはもう耳にしたことがあるでしょう。生成AIのハイプトレーン🚂は全速力で進んでおり、MCPは事前学習モデルの隙間を埋め、複雑な問題を解決するための追加ツールとリソース(文字通り)を提供する、パズル🧩の欠けていたピースだと言われています。これは単なる誇大宣伝なのか、それともMCPは本物なのでしょうか?
私はMCPを2週間かけて調査しました — 生成AIの世界では約8年分に相当するので、この時点でもう専門家と言えるでしょう😉。冗談はさておき、MCPは間違いなく素晴らしいものだと感じています。Amazon Interactive Video Service(Amazon IVS)のデベロッパーアドボケイトとして、私は多くの時間をAmazon IVSのドキュメントに触れ、開発者がアプリケーションにライブストリーミングを実装する方法を学ぶためのデモを構築しています。MCPサーバーとクライアントを作成し(そしてRAGナレッジベースを組み込むことで)、Amazon IVSリソースに関するドメイン固有の知識を持ち、短時間で「すぐに使える」精度の高いプロトタイプを生成し説明できるソリューションを構築しました。
MCPの導入前
AWS Lambda、EC2、S3、EKSと比較すると、Amazon IVSはよりニッチなサービスです。誰もがコンピューティングとストレージを必要としますが、ライブストリーミングのユースケースを持つ人は全員ではありません。つまり、LLM(この場合はClaude 3.7 Sonnet)にプロトタイプやサンプル実装の生成を依頼すると、かなり近いものが得られますが、完璧ではありません。そして私の経験では、これは方向性をまったく得られないよりもしばしば悩ましいことです。LLMの出力をデバッグするよりも、ドキュメントを参照して何かを学ぶために必要な手順を進める方が良いと思います。
これを説明するために、以下のプロンプトをClaude 3.7(Amazon Bedrock経由)に送信した結果を見てみましょう:
help me create an html file to broadcast to an amazon ivs low-latency channel using the latest version of the amazon ivs web broadcast sdk
(最新バージョンのAmazon IVS Web Broadcast SDKを使用して、Amazon IVSの低遅延チャンネルにブロードキャストするHTMLファイルの作成を手伝ってください)
単純なプロトタイプなので、重要なことではないのだが、Claudeが作成したファイルをローカルでブラウザで実行したときの様子を見てみましょう:
では、本当に重要な部分、つまりコードそのものを見てみよう。 Claudeは最善を尽くしましたが、Amazon IVSの専門家ではないため、そのファイルはすぐに動作するものではありませんでした。 プロンプトの全出力はこちらです。 出力全体をここに貼り付けることはしませんが、いくつかの問題点を強調しておきます。
⚠️ 深刻に古いバージョンのSDKをインポートした。 当たり前ですが、Claudeは学習データに制限があります。 ここでは、このブログ投稿時点での最新バージョン「1.22.0」と比較してかなり古い「1.4.0」を使用することを提案しています。
⚠️ これは、遅すぎるまで気づかない、隠れた問題です。
if (!IVSBroadcastClient.isSupported) {
updateStatus("Browser is not supported for IVS broadcasting", true);
}
このコードは「動作」しますが、正常には動作しません。 エラーは投げないが、常にtrue
を返す。 なぜか?isSupported
はプロパティではなく関数だからです。そのため、JavaScriptはライブラリに関数が存在するという理由で、true
に強制変換します。修正方法は簡単で、関数として呼び出すだけです: IVSBroadcastClient.isSupported()
.
⚠️ startCameraButton
リスナーは、IVSBroadcastClient
のインスタンスを正しく作成しますが、その後、全く存在しない関数を呼び出します:
const devices = await client.getDevices();
正しいアプローチは、ユーザーのブラウザ上のカメラとマイクを一覧表示するためにnavigator.mediaDevices.enumerateDevices()
を使用することです。しかし、devices
変数を何にも使用していないため、それはあまり重要ではありません。代わりに、cameraStream
をビデオ — そしてオーディオ🤨 — 入力デバイスとしてアタッチします。
// ビデオデバイスを追加
await client.addVideoInputDevice(cameraStream, 'camera', { index: 0 });
// オーディオデバイスを追加
await client.addAudioInputDevice(cameraStream, 'microphone');
まだ続けられますが、ポイントは伝わったと思います。Claudeはこの問題を適切に解決するために必要なデータを持っていません。しかし、MCPサーバーを通じてClaudeにより多くのツールと機能、そして私たちのAmazon IVSリソースに関する洞察を与えることで、それらのツールを使用して実際のチャネルとステージに直接洞察を持つドメインエキスパートになることができます。
MCPの導入後
次の記事では、この解決策の背後にある実際のコードをお見せします。 とりあえず、私のカスタムMCPクライアントを使って、上記のと同じ問題を解決し、その結果をチェックしてみましょう。 以下が私のプロンプトです。 クライアントがこのレベルの具体性に対応できることを知っているからです。
lets create an html file to broadcast to an amazon ivs low-latency channel using the latest version amazon ivs web broadcast sdk. check the documentation for low-latency streaming with the web broadcast sdk and use my existing channel called demo-channel. to retrieve the channel's stream key from the application, create a function that uses this endpoint: https://[redacted]. use tools at your disposal to find the ingest endpoint for this channel. save the file to /path/to/ivs-web-broadcast-demo.html
(最新バージョンのAmazon IVS Web Broadcast SDKを使用して、Amazon IVSの低遅延チャンネルにブロードキャストするHTMLファイルを作成しましょう。低遅延ストリーミング用のWeb Broadcast SDKのドキュメントを確認し、既存の「demo-channel」というチャンネルを使用してください。アプリケーションからチャンネルのストリームキーを取得するために、このエンドポイントを使用する関数を作成してください:https://[削除済み]。このチャンネルのingestエンドポイントを見つけるために、利用可能なツールを使用してください。ファイルを/path/to/ivs-web-broadcast-demo.htmlに保存してください)
あまり重要ではありませんが、前回の試みと比較してこの例が視覚的にどれだけ良く見えるかに注目してください。
最も重要なことは、すぐに使えるということだ。 私のプロンプトからの出力はこちらから確認できます。 ご覧のとおり、Claude はカスタムMCPサーバーを利用することで、ナレッジベースを検索して最新のドキュメントを取得し、動作するプロトタイプを生成することができました。 また、MCP サーバーは私の IVS チャンネル情報を取得し、渡しているため、Claude は必要な ingestEndpoint
を適切に取得し、それをコードに含めることで時間と労力を節約することもできました。
まとめ
この記事で取り上げた以外にもMCPには多くのことがありますが、このプロトコルに取り組んでみて、LLMに最もドメイン固有の問題でさえもより高い成功率で解決できるツールを与える可能性があることは明らかです。 次回は、私が作成したAmazon IVS MCPサーバーについて詳しく見ていきます。