MCPが話題沸騰中：Miro、Atlassianなどのビルダーから学ぶ教訓

以下は会話の編集済み書き起こしです。引用は明確さのために軽く要約されています。 

APIは以前から存在しています。MCPはAPIでは実現できなかった何を可能にするのでしょうか？

Gunjan： 以前は、各ツールのAPIを理解し、すでに限られた開発リソースを使ってさまざまな統合を構築する必要がありました。そして要件が一つ変わると——たとえば、何かを読むだけでなく書き込む必要が生じた場合——修正を加えて6週間待つというサイクルを繰り返していました。それは遅く、コストのかかるサイクルでした。

MCPでは、プロバイダー自身がサーバーを提供しており、あなたはただ意図を表現するだけです。構築のスピードは非常に急速に加速します。特定のアクションへの呼び出しを定義することから離れ、代わりに何が欲しいかを記述するようになります。そこで、エージェントのオーケストレーション——実際にエージェントに作業を割り当てること——が可能になります。それなしでは、まったく不可能でした。

Kosta： APIはツールを接続しますが、それでも誰かが操作して全体を把握する必要があります。MCPはエージェントがツール全体のコンテキストを読み取り、個人では到底及ばないスケールでその中で行動することを可能にします。

MCPで実際に何を構築しましたか？それは何をするものですか？

Michelle： 私はPendo MCPと組織の残りのデータを接続するトリアージを構築しました。これは毎朝の目覚まし代わりです。誰かと話す前に何を知っておくべきか？セッションリプレイを見る前に、どれが最も重要か？昨日何が起きたか？

カスタマーサクセスマネージャーを中心に設定したグループに基づいて、特定の人々が何をしたかを教えてくれます。標準的なアクティビティ、注意すべき潜在的な問題、データのスパイク、確認すべきさまざまな数値、祝うべき成果などをフラグで示します。また、CSMに連絡する前にどのセッションを見るべきかも尋ねられます。たとえば、コンテンツの集中的なレビューセッション、多数のレイジクリックやデッドクリック、重大なフラストレーションイベント、ブリーフ作成ワークフローにおけるパワーユーザーなどが表示されます。これはエージェントで構築され、毎日のスケジュールで実行される、プロダクトディレクターの朝のブリーフです。

Kosta： 顧客ディスカバリーコールのトランスクリプトをClaudeに入力し、Miroボード上に直接PRDを生成しました。そこからユーザーフローをマッピングし、参照スクリーンショットを追加し、ノートをキャプチャしました——すべて一つの共有スペースで。チームが合意した後、ボードのURLをClaude Codeに入力しました。MCPはコンテキストを理解し、合意した内容を反映した動作するプロトタイプを生成しました。同日中にステークホルダーに見せ、顧客と検証しました。1年前、このようなスピードは不可能でした。今では、誰でも顧客の課題から合意された解決策へ、数時間で到達できます。

Gunjan： PMとして多くのことを同時にこなしており、最も重要な仕事の一つは顧客が何を求めているかを把握することです：何が好きで、何が嫌いか、製品をどのように使っているか、最近の営業会話で何が起きているか。その調査にはかつて何時間もかかっていました。私はRovoでエージェントを構築しました。営業ツール、Google Docs、カレンダー、GitHub、Jiraチケット、Confluenceページ、ミーティングノート、ホットスポットリードへのアクセスを与えました。今後の会議の準備を手伝ってもらうよう依頼すると、それらすべてのツールを使って数分で包括的なレポートを作成します。かつて何時間もかかっていたことが今では数分で済み、会議室に入る際の自信が格段に増しました。

最初のMCPサーバーを構築したとき、何を間違えましたか？

Francois： 私たちは大きな間違いを犯しました。ツールを非常に低レベルのプリミティブとして公開してしまったのです。私たちが言っていたのは、質問があればこのエンドポイントを呼び出して質問を渡してください、質問を言い換えたければこのエンドポイントを使ってください、ということでした。問題は、LLMに権限を与えすぎていたことです。そのため、モデルがどのツールをいつ使うかを決めることになり、実際には、それらは 使わない 傾向があります。賢いシステムであれば、「自分で解決できる」と判断するでしょう。

たとえば、「上位10件の顧客を見せて」と尋ねた場合、それは非常に曖昧です。LLMは独自の定義を見つけ出し、Spotterを呼び出して回答を得ようとします。同じ質問を2回すると、異なる回答が返ってくることもあります。「上位」の定義を、銀行データセットで最も関連性が高いと思われるもの（普通預金口座の場合もあれば、クレジット口座の場合もある）に基づいて決めてしまうという意味で、ハルシネーションが起きていました。 

現在は、インテリジェンスをすべて内包したツールを提供しています。Claudeに独自のインテリジェンスを持ち込ませることはしません。私たちは自社のデータを把握しており、モデルよりも多くのコンテキストを持っているからです。セマンティックレイヤーを通じてコントロールしているため、質問するたびに、私たちが持つすべてのコンテキストに基づいた同じ回答が得られます。

Michelle： まさにそれが、私がインストラクションレイヤーにすべてのSQLクエリを使った理由です。これらが定義です。私たちのデータにおける「上位」とはこういう意味です。クエリを実行する人は、どの言葉を使えばいいか、フィールド名が何かを必ずしも知っているわけではないので、社内データにはそのレベルの説明が必要でした。

最初に何を公開するかをどのように決めましたか？また、何を 公開しない かはどのように決めていますか？

Kosta： 一律の答えはありません。Miroでは、検証済みのユースケースから始め、注力したい内容を戦略的に絞り込みました。MCPサーバーを構築した際、最も積極的に採用したのはエンジニアたちでした。そのため、エンジニアリングのワークフロー、特にエージェントが何千行ものコードを書いており、その動作を把握して方向を調整することが非常に難しいという問題を中心に構築しました。チームの意図をコード生成に渡す方法に注力したことで、早い段階で範囲を広げすぎることを防ぎ、エージェントとGTMのナラティブの両方が混乱するのを避けられました。

Michelle： 私たちは単一のエージェントから始め、そこから拡張していきました。また、最も簡単で信頼性の高いものから始めました。「エンドツーエンドで対応します」と言う前に、ユーザーがツールを信頼してくれることを確認したかったのです。すべてのタスクを自動的に処理できると言う前に、ユーザーが引き続き主導権を持ち、ガードレールが整っている状態にしたかった。それが、ゆっくりと成長してきたプロセスです。

Francois： インテリジェンスをどこで活用したいかを真剣に考える必要があります。LLMに委任したいですか？場合によっては、それが最適です。しかし私たちの場合、データが非常に機密性が高いため、逆の設計をしなければなりませんでした。これはMCP自体をはるかに超えた話です。本質的には、エージェント的な側面を組み込むことです。

何を公開しないかについては、セマンティックレイヤーに立ち返ります。そこで、公開したいテーブルや、誰が何をする権限を持つかを指定します。旧来の世界では、ダッシュボードがガードレールでした。アナリストがどのビジュアライゼーションをダッシュボードに載せるかをコントロールしていました。ダッシュボードがなくなり、人々がデータに直接話しかけたいと思うようになった今、セマンティックレイヤーが新たなコントロールポイントになります。

チームに実際に働き方を変えてもらうにはどうしましたか？

Kosta： 結局のところ、二つのことに集約されます。一つは権限委任です。これは私だけの判断ではありません。会社のリーダーシップが重要だと決断する必要があります。Miroでは、特に市場の動きが非常に速い中で、導入を加速させたいという認識が広く共有されています。しかし、権限委任だけでは十分ではありません。そのため、イネーブルメントにも多大な投資をしています。AIプロダクトギルド、互いに学び合えるSlackチャンネル、ライブセッションなどを設けています。リーダーとして、私たちも自らその行動を示す必要があります。私はプロトタイプをバイブコーディングして、直属の部下たちと議論します。彼らは刺激を受けます。そして多くの場合、彼らの方が私を刺激してくれます。彼らは現場の最前線にいます。本当に素晴らしいものを作り上げています。

Gunjan: 私たちは本当にこれらのツールに機会を与える必要があります。何をしてほしいかを説明し、それが実現できると信じることです。今日のモデルは完全には実現できないかもしれませんが、明日のモデルは必ずそこに到達するでしょう。だから、完璧を目指さずに試みるという信念の跳躍が目標でした。そして、何度も戻って試し続けなければなりません。今日のClaude Codeは本当に優れています。明日は別の何かがより優れているかもしれません。六ヶ月ごとに戻ってこれらのツールを試してみてください。以前はできなかったことが解放されているかもしれないのですから。

MCPツールにとっての成功とはどのようなものですか？北極星となる指標は何ですか？

Gunjan: 近い将来、ユーザーとAIユーザーを区別することをやめるようになると思います。主にワークフローの問題です。いくつのワークフローを動かしているか、そしてそれらがどのように加速しているか。月に100チケットをこなし、5回のスクラムを開催するチームが、エージェントが毎日100件のPRを書いているなら、何が起きているかを管理・制御するために毎日スクラムを行いたいと思うでしょう。KPIは、エクスペリエンスのフロントエンドがどこにあるかに関わらず、システム内でオーケストレーションされたワークフローの数になります。

Kosta: 私たちは他の製品と同様に見ています。MCP導入において、利用者数とその利用量の両面で非線形な成長を見ています。しかし、私たちはワークフローを本当に理解しようとしています。人々はそれを何のために使っているのか？成功しているのか？それらのワークフローのために再び使用しているのか？特にコードの可視化などにおいて、今では本当に定着しています。MCPだけでなく、人々がMiro全体をどのように使っているかも引き続き見ています。両方です。

ユーザーがUIを一度も開かずに製品から価値を得ているとしたら、それはビジネスにとって何を意味しますか？

Kosta: 私はこれを逆から考えます。エージェントが作業を行っているなら、チームはそれらを理解し、方向付けるためにどこへ行くのでしょうか？ほとんどのAIツールはブラックボックスです。私たちは、それらのエージェントをどこで整合させるか、どのように正しいことをしているか確認するかについて、多くを考えています。私たちにとって、それは脅威ではなく機会です。Miroはチームコラボレーションのために作られました。それは変わりません。チームが少し大きくなっただけです。

Gunjan: あなたの堀は、あなたが構築するものです。他の誰かがあなたの製品を守るよりも速く再構築できるなら、そうです、再考してください。しかし、自分の堀を強化して「これが人々が私たちの製品を使う理由であり、これが彼らにとって最良の結果だ」と言えるなら、本当に集中できます。顧客中心であることは、顧客にあなたと共にいてもらうよう求める権利を与えてくれます。あなたが提供しているものに満足していれば、彼らはそうするでしょう。

Francois: 分析ツールとしての私たちにとって、ユーザーエクスペリエンスは非常に重要です。ドリルダウンし、可視化し、変更を加えられる必要があります。MCPアプリの良い点は、もはや選択する必要がないことです。パワーユーザーは引き続き製品を深く使いこなせます。ビジネスユーザーは一つの質問をして、エージェントの中に直接チャートを表示させることができます。それは共存であり、競争ではありません。

プロダクトマネジメントの役割は実際にどのように進化していますか？

Michelle： Jiraのストーリーを書くのをやめたいと思っています——実際、今はAIが多くを書いてくれています。でも、やはり頭脳は必要です。改善されること：手戻りが減り、バグが減る。なぜなら、コンテキストが保持され、前回見落としたことを次回は見落とさなくなるからです。スパイクにかける時間も短くなっています。APIドキュメントを読んで、何かが実現可能かどうかを調べるのにどれだけ時間を費やしていたでしょうか？今では5分以内にその答えが得られます。もうスパイクは不要になるかもしれません。

Kosta： エージェントが実行や細かい作業をより多く担うようになっています。しかし、本当のPMの技術（問題の定義、合意形成、コミュニケーション）はこれまで以上に重要です。エージェントが勝手に動き回って何を作るかを決めてほしくはありません。誰もそんな世界は望んでいません。だからこそ、プロダクト担当者はより積極的に関与し、技術についてより深く考える必要があります：問題の定義、コンテキストの整理。役割は実行から、より高いレバレッジを持つ活動へとシフトしています。

Gunjan： 以前は人々を制限していたガードレール——「コードが書けない」「構文が理解できない」——はなくなりました。だから、新しい時代では問題の特定が非常に重要です。点と点をつなぐことも大きなポイントです。AIはあなたの代わりに点をつないでくれません。どの問題を解決すべきか、どんな問題が存在するかを見極める必要があります。そして、センスは非常に身につけにくいスキルであり、それは変わっていません。どんな技術が来ては去っても関係ありません。体験やプロダクトにおいて「良いもの」とは何かを理解するために時間を使うこと、それは今でも非常に重要です。

Pendo MCPを始める準備はできていますか？ プロンプトライブラリ, と 無料でセットアップしましょう。