AIエージェントの新時代を切り拓く：SourcegraphのMCPとClaudeを活用した先進的開発戦略

はじめに：ソフトウェア開発の未来を再定義するAIの波

今日のソフトウェア開発は、かつてないスピードで進化しています。特にAIの進化は、私たちがコードを書き、問題を解決し、アプリケーションを構築する方法そのものを根本から変えようとしています。Sourcegraphは、長年にわたり大規模かつ複雑なコードベースに取り組むプロフェッショナルエンジニアを支援するための開発ツールを提供してきました。私たちの製品は、市場価値トップ10に入るソフトウェア企業のうち7社、米国のトップ10銀行のうち6行を含む、あらゆる業界の無数の企業で利用されています。

今回、私たちはAnthropicの画期的な「Model Context Protocol（MCP）」と、彼らの最先端のLLM（大規模言語モデル）であるClaudeを深く統合することで、AI駆動型ソフトウェア開発の新たな地平を切り開こうとしています。本記事では、この取り組みを通じてSourcegraphが目指す未来、その具体的な機能、ビジネスへの影響、そして将来の展望について、詳細かつ説得力のある形で掘り下げていきます。私たちは、MCPとツール呼び出しLLMの組み合わせが、AIアプリケーションアーキテクチャの新たなパラダイムシフトを導くと確信しています。

第1章：AI開発アーキテクチャの波：Co-pilotからエージェントへ

AIの進化は、ソフトウェアアプリケーションのアーキテクチャにも明確な波をもたらしてきました。私たちはこれまで、大きく分けて3つの時代を経験し、そして今、新たな時代へと突入しようとしています。

第一波：Co-pilot時代（2022年以前）

2022年という「古き良き時代」を振り返ると、当時のAIモデルは、まだチャット形式での対話やツール利用には最適化されていませんでした。それらは基本的に「テキスト補完モデル」であり、与えられた入力に対して次に続くトークンを予測し、テキストを補完する能力に優れていました。

このモデルの能力によって、多くの初期のAIアプリケーション、例えばコード補完ツールやシンプルなコンテンツ生成ツールが構築されました。ユーザーはコードの一部や文章の冒頭を入力し、モデルがその続きを提示するという、比較的単方向のインタラクションが主流でした。この時代のアプリケーションのアーキテクチャは、モデルのテキスト補完という限られた能力によって規定されていたと言えるでしょう。

第二波：RAGチャット時代（ChatGPT以降）

そして、ChatGPTの登場は、AIアプリケーションの様相を一変させました。これにより、「チャット」という新たな対話モダリティが一般化しました。ユーザーはモデルに対して明示的に質問を投げかけ、より複雑なタスクや問い合わせが可能になりました。

この時代において、特にコードベースのAIアプリケーションで重要性が認識されたのが、「RAG（Retrieval Augmented Generation）チャット」というパラダイムです。これは、関連するコードスニペットやドキュメントをモデルのコンテキストウィンドウにコピー＆ペーストし、その情報に基づいて質問に答えることで、モデルの回答の品質と有用性が劇的に向上するというものでした。これにより、AIはより実用的なレベルで開発者の日常業務に組み込まれるようになりました。SourcegraphのAIコーディングアシスタント「Cody」も、このRAGチャット時代における強力な製品の一つでした。しかし、このアプローチには、依然として「関連するコンテキストを手動で探し、コピペする」という人間の介入が必要でした。

第三波：エージェント時代（現在進行形）

そして今、私たちは新たな時代、すなわち「エージェント時代」に突入しています。この波を決定づけているのは、AnthropicのClaude 4のような「ツール呼び出しLLM（Tool-Calling LLM）」と、それを支える「Model Context Protocol（MCP）」の進歩です。

この新しいモデルの能力は、アプリケーションのアーキテクチャに根本的な再考を促しています。もはや人間が手動でコンテキストを提供したり、モデルに指示を出すだけでなく、AI自体が状況を判断し、適切なツールを自律的に選択・実行し、タスクを完了させる能力を持つようになったのです。

Sourcegraphは、このパラダイムシフトの初期段階からAnthropicと密接に連携してきました。AnthropicのDavid氏（現在MCPの共同開発者）から「LSP（Language Server Protocol）のモデルコンテキスト版のようなものに取り組んでいる」と聞いた時、私たちは即座にその潜在能力を確信し、MCPの初期設計パートナーとなりました。この協業を通じて、私たちは「ツール呼び出しモデルとMCPの組み合わせが、AIアプリケーションアーキテクチャの次のパラダイムシフトをリードする」という確固たる信念を持つに至りました。そして、この信念に基づき、私たちは既存のアーキテクチャの前提を問い直し、まったく新しいコーディングエージェントをゼロから構築することを決意したのです。それが、これからご紹介する「AMP」です。

第2章：Sourcegraphが提示する未来：コーディングエージェント「AMP」

AIエージェント時代に対応するため、Sourcegraphは完全に新しいコーディングエージェント「AMP」をゼロから構築しました。AMPは、Anthropicが提供する最先端のツール呼び出しLLMであるClaude 4と、Model Context Protocol (MCP) を深く統合することで、従来のAIアシスタントの枠を超えた、真に自律的な開発体験を提供します。

AMPの真価を理解いただくには、その動作を実際に見ていただくのが一番です。ここでは、先日行われたライブデモの内容を基に、AMPがどのようにMCPとツールを駆使してタスクを遂行するかを具体的に解説します。

AMPが示した驚異のデモ：マルチタスクをこなす自律エージェント

デモでは、AMPが複数の複雑なタスクを同時に、かつ自律的にこなす様子が示されました。これらは全て、人間が詳細な指示を与えることなく、高レベルの目標を与えるだけで実現されました。

1. 自己修正能力とUI検証：AMP自身の背景パネル変更

最初のデモでは、「AMPの背景パネルの色を赤に変更する」というタスクが与えられました。これはAMP自身のコードを変更するという、エージェントにとって非常に挑戦的なタスクです。

課題の理解: まず、AMPは「Linear」と呼ばれる課題管理システムのURLを受け取ります。AMPは、MCPを介して提供されるLinearツールを自律的に呼び出し、そのURLから課題の詳細（背景パネルを赤にするという指示）をフェッチします。これは、モデルが人間からの指示を解釈し、関連する情報源から必要なコンテキストを自ら収集する能力を示しています。
コードの変更と環境操作: 指示を理解したAMPは、自身のコードベース内で背景パネルのスタイルを定義している箇所を特定し、変更を加えます。この変更は、単にコードを書き換えるだけでなく、それが実行環境にどのように反映されるかを確認する必要があります。
視覚的フィードバックと自己検証: ここで重要な役割を果たすのが、Playwright MCPサーバーです。AMPは、Playwrightツールを呼び出して、ブラウザ上で実行されているアプリケーションのスクリーンショットを撮影します。このスクリーンショットをモデルが解析し、「背景パネルが本当に赤に変わったか」を視覚的に検証します。コンポーネントの階層が複雑なUIでは、コード上の変更が意図通りに反映されないことがよくあります。AMPはこのような「見た目」と「実際の挙動」のギャップを、視覚的フィードバックを通じて認識し、必要に応じて修正を試みます。
タスク完了の宣言: 最終的に、AMPはUIの変更が成功したことを確認すると、再びLinearツールを呼び出し、該当する課題を「完了」とマークします。

この一連のプロセスは、AMPが単にコードを生成するだけでなく、外部システムと連携し、実行結果を検証し、フィードバックループを通じて自律的にタスクを完遂できることを示しています。

2. アーキテクチャの自己説明：AMPアーキテクチャの可視化

次に、デモではAMPのCLIを開き、「AMPの主要なアーキテクチャコンポーネントと、MCPがどのように関与しているか教えてください」と質問しました。

テキストによる説明: AMPはまず、自身の内部構造に関する詳細なテキスト説明を生成しました。これにより、各コンポーネントの役割と相互作用、そしてMCPがそれらをどのように結びつけているかが明確にされました。
ビジュアル化の指示と実行: さらに、「これらのコンポーネントがどのように接続し、通信するかを示す図を描いてください」と指示すると、AMPはアーキテクチャダイアグラムを生成しました。この図は、AMPのクライアント、サーバー、MCPインテグレーション、そして様々な外部サービスがどのように連携しているかを視覚的に示し、大規模なコードベースにおけるシステムの理解を大幅に簡素化します。

このデモは、AIエージェントが自己の構造や機能について深く理解し、それを人間が理解しやすい形式で説明できる「内省」の能力を示しています。これは、複雑なシステムを扱うエンジニアリングチームにとって、オンボーディングの簡素化やトラブルシューティングの迅速化に大いに役立つでしょう。

3. 並行作業：3D Flappy BirdのVibe Coding

さらにデモでは、これらの主要タスクが進行中に、並行して「3D Flappy Bird」というミニゲームを開発するというサイドプロジェクトが開始されました。

別タスクの開始: 「3D Flappy Birdに関するLinearの課題を見つけてください」と指示すると、AMPは再びLinearツールを呼び出し、ゲームの仕様が記述された課題をフェッチします。
自律的な開発: AMPは、他のタスクと並行して、ゲームのコードを生成し、PythonのWebサーバーを起動するまでを自律的に行いました。
成果物の確認: デモの最後に、生成されたゲームがブラウザで正常に動作していることが確認されました。

この「Vibe Coding」は、AIエージェントが複数のタスクを効果的に管理し、並行して開発作業を進めることができる可能性を示唆しています。これは、開発者がより創造的な作業に集中し、退屈な反復作業をAIに任せるという、未来のワークフローの一端を垣間見せるものです。

デモから読み取れるMCPとツール呼び出しLLMの力

これらのデモは、MCPとツール呼び出しLLMの組み合わせが、以下のような強力な能力をAIエージェントにもたらすことを明確に示しています。

文脈理解に基づくツール選択: モデルは、人間からの高レベルの指示を解釈し、そのタスクを遂行するために必要なツール（Linear、Playwrightなど）を自律的に識別・呼び出すことができます。
複雑なワークフローのオーケストレーション: 単一のツールを呼び出すだけでなく、複数のツールを論理的に連鎖させ、フィードバックループを組み込むことで、複雑なタスク全体を自動化できます。
外部システムとのシームレスな統合: MCPは、ローカル環境のツールから、LinearのようなサードパーティのSaaS、そしてSourcegraphのコード検索エンジンといった自社サービスまで、あらゆるサービスとAIエージェントを接続する汎用的なインターフェースとして機能します。
自己検証と自己修正能力: エージェントは、ツールの出力や外部からのフィードバック（例：スクリーンショット）を基に、自身の行動を評価し、必要に応じて修正を行うことで、タスクの信頼性を高めます。

AMPは、これらの能力を基盤として、開発者が日々の業務において直面する多様な課題に、より賢く、より自律的に対応する新たなコーディング体験を提供することを目指しています。

第3章：AMPアーキテクチャの深層：MCPが結びつける開発エコシステム

AMPの心臓部には、Model Context Protocol（MCP）が深く組み込まれています。MCPは、AMPの様々なコンポーネント、すなわちAMPクライアント、AMPサーバー、そして外部サービスやローカルツールを結びつける、不可欠な通信プロトコルとして機能します。

MCPの中核的役割：全ての接続を統合

AMPアーキテクチャの中心には、クライアントからのリクエストを処理し、様々なサービスと連携する「サーバーズスレッド」コンポーネントがあります。このサーバーズスレッドは、MCPインテグレーションを通じて、あらゆる種類のサービスと対話します。

ローカルツールとの連携: Playwright（ブラウザ自動化）やPostgres（データベース）といったローカルで動作するツールとは、標準I/OやMCPを介して直接通信します。これにより、AMPはユーザーのローカル開発環境と密接に連携し、テストの実行、データベース操作、UIの検証といった幅広いタスクを実行できます。
外部サービスとの連携:
- Sourcegraph Code Search Engine: Sourcegraphが誇る大規模コードベース検索エンジンは、エージェントが関連コンテキストを効率的に発見するための強力なツールとしてMCPを介して統合されています。
- 課題トラッカー（例：Linear）: 前述のデモのように、Linearのような課題管理システムと連携し、課題の取得、更新、完了マーク付けなどを自動化します。
- 可観測性ツール（例：Sentry）: Sentryのようなエラー監視・パフォーマンス分析ツールと連携することで、エージェントはアプリケーションの実行時情報を取得し、問題を特定・診断する能力を持つことができます。
- その他のサードパーティサービス: CI/CDツール、ドキュメント管理システムなど、あらゆる開発関連サービスがMCPを介して統合可能です。

MCPは、これらの多様なサービスを単一の統一されたプロトコルで接続するための基盤を提供します。これにより、AMPは柔軟かつ拡張性の高いエージェントとして機能し、開発ワークフロー全体をカバーする能力を持つことができるのです。

MCP接続のセキュリティ確保：エンタープライズ対応へのコミットメント

Sourcegraphの顧客の多くは、厳格なセキュリティ要件を持つ大規模な企業です。そのため、MCPの統合におけるセキュリティは、私たちにとって最優先事項でした。

既存の課題とリスク

MCPの初期仕様には認証メカニズムがありませんでしたが、その後、OAuth 2が指定された認証プロトコルとして統合されました。これは大きな前進です。しかし、プロトコルが指定されても、その実装方法によっては依然としてセキュリティリスクが残ります。

現状、多くのMCPサーバーの実装では、ユーザーの機密情報（APIトークンやシークレット）が暗号化されずにローカルマシン上のファイルシステムに保存されるケースが見られます。例えば、リモートMCPサーバーをローカルMCPに変換するnpmプラグインのようなツールが存在しますが、これが内部的にユーザーのシークレットを平文で、かつ無作為なディレクトリに保存してしまうことがあります。このようなアプローチは、セキュリティ上の大きな脆弱性となり、多くの企業顧客にとっては許容できるものではありません。機密情報が暗号化されずに保存されることは、情報漏洩のリスクを高め、企業のセキュリティポリシーに違反する可能性があります。

SourcegraphのセキュアなMCP統合戦略

この問題に対処するため、SourcegraphはAMPのアーキテクチャにセキュアなシークレットストアとプロキシ機能を実装しました。

AMPサーバーによるOAuthハンドシェイクの管理: AMPクライアントは、直接外部サービスとOAuth認証を行うのではなく、AMPサーバーを介して認証プロセスを行います。AMPサーバーがOAuthハンドシェイクを安全に処理し、アクセストークンなどの機密情報を安全に管理します。
MCP接続のプロキシ: AMPサーバーは、クライアントと外部サービス間のMCP接続をプロキシします。これにより、クライアントが直接外部サービスに接続し、機密情報をやり取りする必要がなくなります。
セキュアなシークレットストア: 取得されたOAuthトークンやAPIキーなどのシークレットは、AMPサーバー上のセキュアなストアに保存され、決して暗号化されていない状態でユーザーのローカルマシンに保存されることはありません。これにより、機密情報が不適切に漏洩するリスクを排除します。
ユーザーアイデンティティの転送: AMPサーバーは、ユーザーのアイデンティティ情報を安全な方法で適切な外部サービスに転送します。これにより、外部サービスは認証されたユーザーからのリクエストであることを認識し、適切なアクセス制御を適用できます。

この堅牢なセキュリティアーキテクチャにより、AMPは大規模なエンタープライズ環境においても安心して利用できるAIエージェントとして機能します。開発者は、セキュリティの懸念なく、AIエージェントの強力な機能と外部サービスとのシームレスな統合の恩恵を享受できるのです。

第4章：新しいAIエージェント開発のレシピ：成功のための4つの要素

これまでの経験を通じて、Sourcegraphは成功するAIエージェントアプリケーションを構築するための「レシピ」を発見しました。これは、魔法のようなものではなく、誰でも今日から実践できる実用的なアプローチです。私たちはこのレシピについてブログ記事でも公開しており、この記事を読めば、シンプルなコーディングエージェントを自作することも可能です。

このレシピは、以下の4つの主要な要素で構成されています。

1. 強力なツール利用LLM (Tool Use LLM)

AIエージェントの基盤となるのは、間違いなくその中核となるLLMの能力です。特に「ツール呼び出し」に特化したLLMは不可欠な要素となります。

Claude 4の能力: 私たちはAnthropicの最新モデルであるClaude 4のツール呼び出し能力に非常に興奮しています。AMPのデモで示した全ての機能は、Claude 4によって実行されました。Claude 4は、複雑な指示を理解し、利用可能なツールの中から最適なものを選択し、その実行結果を解釈して次のステップを計画する、高度な推論能力とツール利用能力を兼ね備えています。
本質的な要求: モデルが単にテキストを生成するだけでなく、外部の関数やAPIを呼び出すことを理解し、その呼び出しを適切なタイミングとパラメータで行えることが、真のAIエージェントを実現するための最低条件となります。

2. 豊富なツール提供手段 (Model Context Protocol - MCP)

強力なLLMがあっても、それが利用できるツールがなければその能力は限定的です。MCPは、LLMに多様なツールを効率的かつセキュアに提供するための理想的なソリューションです。

LSPとの類似性: MCPは、プログラミング言語と開発環境を結びつけるLanguage Server Protocol (LSP) のように、LLMと外部サービス・ツールを結びつけます。これにより、モデルはツールの存在、機能、使い方をプロトコルを通じて理解し、適切なコンテキストで呼び出すことができます。
エコシステムの成長: 現在、多種多様なMCPサーバーが登場しており、エージェントが利用できるツールの範囲は急速に拡大しています。
- ローカルツール: Playwright (ブラウザ自動化), Postgres (データベース操作)。
- Web検索: AnthropicのWeb検索APIやBraveのWeb検索など、最新の情報にアクセスするためのツール。
- コンテキスト7: 企業のドキュメントコーパスやナレッジベースから関連情報を引き出すためのMCPサーバー。
- Linear: 課題管理システムとの連携。
- Sentry: エラー監視ツール。特にSentryのMCPサーバーは、ツールの記述品質が高く、モデルがツールを効果的に利用するための良い例とされています。ツールの正確で高品質な説明は、モデルが混乱せずに適切なツールを選択するために不可欠です。

3. 重要なフィードバックループ

AIエージェントが信頼性の高い結果を生み出すためには、自身の行動が成功しているか否かを判断し、必要に応じて軌道修正するメカニズム、すなわち「フィードバックループ」が不可欠です。

Playwrightによる視覚的検証: AMPのUI変更デモでは、Playwright MCPサーバーを使用してスクリーンショットを撮影し、変更が正しく適用されたかを視覚的に検証しました。これは、UI開発における変更が、必ずしもコード上の記述通りに視覚的に反映されるとは限らないという現実的な課題に対応するものです。
その他のフィードバック源:
- 単体テストや統合テストの実行: コード変更後、関連するテストを自動的に実行し、その結果（パス/フェイル）をフィードバックとして利用することで、バグの混入を防ぎます。
- コンパイラの呼び出し: コードのシンタックスエラーや型エラーなどを早期に検出し、修正を促します。
- コードレビューツールとの連携: 生成されたコードをレビューシステムに提出し、自動的なLinterや静的解析の結果をフィードバックとして受け取る。
実践における重要性: フィードバックループを適切に設計することで、エージェントは複雑で曖昧な指示に対しても、高い信頼性でタスクを完了させることができます。これは、単にコードを生成するだけでなく、そのコードが「正しく機能する」ことを保証するために不可欠です。

4. 命令的なUXデザイン (Imperative UX)

エージェント時代の到来は、ユーザーインターフェース（UX）の設計思想にも変化をもたらします。

従来のAIアプリケーションの課題: 以前のAIアプリケーションでは、ユーザーが手動でコンテキストを選択したり、複雑なUIを操作してチャットモデルを特定の状況で呼び出したりする必要がありました。これはしばしば、認知負荷が高く、効率的ではありませんでした。
エージェント時代のシンプルなUX: ツール呼び出しLLMと豊富なツールが利用可能になったことで、UXはより「命令的」なものへと移行します。ユーザーは単に「エージェントにやらせる」と指示を出すだけでよくなります。詳細な手順やツールの選択はエージェントが自律的に行い、ユーザーはフィードバックループを通じて結果を検証・調整します。
例: 「この課題を実装して」「このバグを修正して」「この新機能を追加して」といった高レベルの指示が、エージェントへの入力となります。エージェントは、これらの指示を具体的なタスクに分解し、適切なツールを呼び出し、フィードバックループを通じて問題を解決していきます。
メリット: このアプローチにより、開発者はより高レベルの創造的な作業に集中できるようになり、退屈で反復的な作業はエージェントに任せられるようになります。UXはよりシンプルになり、エージェントの能力を最大限に引き出すことができます。

これらの4つの要素を組み合わせることで、私たちはAIエージェントがソフトウェア開発のあらゆる段階で真の価値を提供できると確信しています。

第5章：賢いツール選定とセキュリティ対策：Toolmaggedonを避ける

MCPを活用したAIエージェント開発は大きな可能性を秘めていますが、その道のりにはいくつかの落とし穴も存在します。特に、ツールの統合とセキュリティは、効果的なエージェントを構築する上で慎重に取り組むべき課題です。

Toolmaggedonの罠：ツール過多によるパフォーマンス低下

MCPの魅力の一つは、非常に多くのツールをエージェントに提供できる点です。しかし、ここに一つの落とし穴があります。私たちが「Toolmaggedon（ツールマゲドン）」と呼ぶ現象です。

問題の発生: MCPサーバーはそれぞれ複数のツールを提供することができ、それらを無計画に「プラグイン」してしまうと、モデルのコンテキストウィンドウが、大量の関連性の低いツール記述で埋め尽くされてしまいます。
LLMへの影響: LLMは、コンテキストウィンドウ内の全ての情報を処理しようとします。関連性の低いツール記述が多すぎると、モデルは：
- 適切なツール選択の困難: 膨大な選択肢の中から最適なツールを見つけるのに苦労し、誤ったツールを呼び出す可能性が高まります。
- 推論能力の低下: ツール記述の解析に多くのコンテキスト容量と計算リソースが割かれ、本来のタスク（コード生成、問題解決など）における推論能力や一般常識的な判断力が低下します。
- コストの増加: コンテキストウィンドウのサイズが大きくなればなるほど、LLMの呼び出しコストも増加します。

このToolmaggedonを避けるためには、ツール選定において戦略的なアプローチが必要です。Sourcegraphでは、エージェントの効率とパフォーマンスを最大化するために、特定のワークフローに不可欠なツールセットに限定して提供しています。

Sourcegraphが考える有用なツールのカテゴリ

私たちは、AIエージェントにとって特に価値の高いツールを以下の3つのカテゴリに分類しています。

関連コンテキストの発見:
- 目的: 大規模なコードベース、ドキュメント、Web上から、現在のタスクに関連する情報を効率的に検索・取得する。
- 例: Sourcegraphのコード検索エンジン、Context 7 (ドキュメント検索), Web検索ツール (Anthropic Web Search API, Brave Web Search)。
- 重要性: モデルが正確で最新の情報に基づいて行動するための基盤となります。
高品質なフィードバックの提供:
- 目的: エージェントが実行したアクションの結果を検証し、学習し、修正するために、客観的で信頼性の高いフィードバックを提供する。
- 例:
  - 単体テスト/統合テストの実行: コード変更後、自動的にテストを実行し、パス/フェイルの結果をフィードバックとして返す。
  - コンパイラの呼び出し: コードの構文エラーや型エラーを検出する。
  - UIのスクリーンショット (Playwright): 視覚的な変更を検証する。
  - コードレビューツールとの連携: Linterや静的解析ツールの結果をフィードバックとして提供する。
- 重要性: エージェントの自己修正能力と信頼性を高め、実用的な品質を保証するために不可欠です。
成功の宣言と状態更新:
- 目的: タスクの完了を明確に示し、関連するシステムの状態を更新することで、ワークフロー全体をシームレスに進行させる。
- 例:
  - 課題管理システムでの完了マーク (Linear): タスクが完了したことを課題として記録し、チームメンバーに通知する。
  - プルリクエストの作成: コード変更が完了したら、レビューのためにプルリクエストを自動的に作成する。
  - ユーザーへの通知: 特定のタスクが完了したことや、フィードバックが必要な場合にユーザーに通知する。
- 重要性: チーム全体の連携を強化し、開発ワークフローのボトルネックを解消します。

これらのカテゴリに沿ってツールを選定し、最適化することで、Toolmaggedonを回避し、エージェントのパフォーマンスを最大限に引き出すことができます。

第6章：エージェントの未来：サブエージェントから動的ツール合成、そしてプログラミングの再定義へ

AIエージェントの旅はまだ始まったばかりです。MCPとツール呼び出しLLMの現在の能力も、その潜在能力のほんの一部に過ぎません。Sourcegraphは、未来のAIエージェントがどのような形になるかについて、いくつかの興味深い考察と投機的な展望を持っています。

サブエージェントの台頭：より高度な自律性と専門化

現在、「ツール」として認識されている機能の多くは、将来的にはそれ自体がより専門化された「サブエージェント」として実装される可能性があります。

AMPのコンテキスト収集機能: AMPがコードベースのコンテキストを収集する方法は、単なる決定論的な検索ツールではありませんでした。それは、低レベルの検索ツールを呼び出し、得られたコンテキストを推論し、クエリを洗練させることで適切なコンテキストを収集する、一種の「ミニエージェント」として機能していました。
専門化されたエージェントの連携: このアプローチは非常に効果的であることが判明しています。将来的には、コード生成を担当するエージェント、テスト実行を担当するエージェント、ドキュメント生成を担当するエージェントなど、特定の役割に特化したサブエージェントが連携して、さらに複雑なタスクを遂行するようになるかもしれません。
メリット: 各サブエージェントが特定のドメインに特化することで、より深い専門知識と効率的な処理が可能になり、全体としてのエージェントの能力と信頼性が向上します。

動的ツール合成とコードインタープリターの復活

ツールの利用方法は、静的なリストから選択する現在のパラダイムから、より動的でプログラム可能なものへと進化するでしょう。

MCPへの出力スキーマ統合: MCPに「出力スキーマ」の概念が統合されたことで、モデルはツールの出力形式を事前に理解し、複数のツールをどのように組み合わせ、連鎖させるかをより高度に計画できるようになりました。
プログラミングとの融合: ツールをまるで関数のように扱い、モデルがこれらの関数を組み合わせて新しいロジックを動的に構築・実行する能力は、本質的にプログラミングに非常に近いです。LLMは、特定の目標を達成するために、利用可能なツールという「関数」を「コード」のように記述し、実行できるようになるでしょう。
コードインタープリターの再評価: 2023年に一度注目を集めた「コードインタープリター」（LLMがコードを生成し、それをサンドボックス環境で実行して結果をフィードバックとして利用する機能）は、ツール呼び出しエージェントの文脈で再び大きな可能性を秘めています。モデルが自身の生成したコード（ツール呼び出しのシーケンスも含む）を実行し、その結果から学習し、反復することで、より複雑な問題解決やデバッグが可能になります。

高レベルプログラミング言語の歴史との類似

ツール呼び出しLLMとAIエージェントの進化は、まるで高レベルプログラミング言語の初期の議論を再現しているかのようです。

過去の議論の再燃: 初期プログラミング言語の時代には、「サブルーチンの適切な抽象化とは何か？」「関数とメッセージパッシングのどちらが良いか？」「並行通信を効果的に管理する方法は？」といった根本的な議論が交わされました。
エージェント時代への適用: 現在、エージェント、サブエージェント、そしてそれらが決定論的なシステムとどのように相互作用するかという議論は、これらの過去の議論と強い類似性を示しています。私たちは、エージェントが互いにどのように通信し、タスクを分担し、共有リソースを管理するかという、新しい「プログラミングパラダイム」を再定義しているのかもしれません。これは、ソフトウェア工学の原理をAIの文脈で再考する、非常にエキサイティングな機会を提供します。

MCPプロトコルの未活用機能：未来への巨大な可能性

MCPプロトコルは、その設計者が非常に先見の明を持っていたことを示すかのように、まだ多くの未活用機能を含んでいます。

現在の利用状況: 現時点でのMCP接続の大部分は、ステートレスなツール呼び出しに限定されており、ストリーミング機能ですら十分に活用されていません。
未活用の可能性:
- ステートフルセッション管理: より長期的な記憶とコンテキストを維持できるエージェントは、より複雑で継続的なプロジェクトに取り組むことができます。
- 双方向通信: MCPサーバーとクライアント間のより複雑な対話により、エージェントはよりインタラクティブな方法で情報を取得し、行動を調整できます。
- サンプリング（MCPサーバーからのLLM推論要求）: MCPサーバーが、何らかの理由でLLMの推論能力を必要とする場合に、クライアント（エージェント）にLLM推論を要求する機能です。これにより、ツール側がよりインテリジェントな振る舞いをすることが可能になります。
未来への示唆: これらの未活用機能が完全に実装され、活用されるようになれば、AIエージェントの能力はさらに飛躍的に向上するでしょう。この先1年は「本当に奇妙な（really weird）」ことが起こる、と私たちは予測しています。それは、今日の私たちが想像もできないような、新しい開発のワークフローやアプリケーションが生まれることを意味します。

結論：AI駆動型ソフトウェア開発の最前線

SourcegraphとAnthropicは、約3年間にわたる緊密なパートナーシップを通じて、AI駆動型ソフトウェア開発の最前線を走り続けてきました。私たちは2023年1月にはClaudeをコーディング目的で利用し始め、その進化の旅を共に歩んできました。

AMPは、このパートナーシップと、MCP、そしてツール呼び出しLLMに対する私たちの深い理解の結晶です。AMPは、単なるAIアシスタントではなく、「ツール呼び出しネイティブ」なコーディングエージェントとしてゼロから構築され、開発者がより複雑な課題に自律的に対処し、より生産的に働くことを可能にします。

KodiとAMPの戦略的差別化

ここで、Sourcegraphの既存のAIコーディングアシスタントである「Cody」と「AMP」の関係性について触れておきましょう。Codyは、RAGチャット時代のモデルの能力を最大限に引き出した、コンテキストアウェアな優れたAIアプリケーションでした。多くの組織や特定のワークフローでは、RAGチャットパラダイムが引き続き大きな価値を提供します。

しかし、LLMの能力がツール呼び出しへと劇的に変化したことで、最適なユーザー体験とアプリケーションアーキテクチャもまた変化しました。だからこそ、私たちはAMPをCodyとは別に、ツール呼び出しとMCPの利点を最大限に活用できるようにゼロから設計したのです。もし、アプリケーション開発者がこの新しいアーキテクチャの波に乗り遅れ、既存の前提に固執するならば、AI開発の次の波から取り残されるリスクがあると考えています。AMPは、この新たな波を捉え、未来のソフトウェア開発のあり方を再定義するための私たちの回答です。

未来への呼びかけ

私たちは、AMPの可能性、そしてMCPエコシステムの成長に非常に興奮しています。もし、あなたがMCPサーバーを開発している、あるいはAIエージェントを使った新しいソフトウェア開発の形を模索しているのであれば、ぜひ私たちにご連絡ください。私たちは、皆さんと共にこのエキサイティングな旅を続け、AIがもたらす新たな可能性を最大限に引き出すことを楽しみにしています。

AIはソフトウェア開発のあり方を根本から変えています。Sourcegraphは、この変革の最前線に立ち、開発者がより創造的で、より効率的で、より満足のいく仕事ができる未来を創造するために尽力していきます。