MCPツールをつないでもLinkedInのコーディングエージェントが迷った理由

LinkedInが作ろうとしているオンコールの同僚

会社の検索、文書、チケットにClaude Codeをすでに向けた人がぶつかる問いは、それでも社内ワークフローではなぜ止まるのかです。AJと呼ばれるLinkedInのソフトウェアエンジニアAjay Prakashは、その停滞の内側から答えます。MCPツールでLinkedIn側の情報は取れていましたが、エージェントは手順のところで迷ったままでした。AI Engineerチャンネルが公開した彼の講演は、その隙間を失敗としてほどいたあと、LinkedInがそれらのツールの上に作った内部システムをたどります。

彼はこの仕事をコンテキストエンジニアリングとして置きます。コーディングエージェントが見られるものと呼べるものを整え、汎用の自動補完ではなくLinkedInの中で動けるようにする、という仕事です。導入はオンコールの一連の流れで、彼はこれを、チームがすでに回している本番の話として出します。

重要なサービスを持つチームのエンジニアが、インシデントをまだつかんでいる途中でエラー急増のアラートを受けます。エンジニアはそのアラートのリンクを、Claude CodeやGitHub Copilotのようなコーディングエージェントに貼ります。人がまだ状況をつかんでいるあいだに、エージェントは会社のデバッグ手順を取り、影響を受けたサービスを特定し、そのサービス用の文脈を読み、ログとメトリクスを引きます。そこから原因と緩和の手順を提案し、確認を待ちます。エンジニアが確認したあとの段は、Prakashがこう説明します。エージェントが緩和の操作をし、詳細とエラーメトリクス、ダッシュボードでインシデント管理システムを更新し、コードをチェックアウトし、原因に向けたプルリクエストを開きます。

彼はこの循環が、手作業なら数時間かかる仕事を数分で片づけると言い、この流れに「作り話ではない」というラベルを貼り、LinkedInのチームはすでにコーディングエージェントを、内部システムとコードを深く知る同僚としてこう使っていると言います。それを可能にするシステムを彼の言葉で言うと、contextual agent playbooks and toolsです。講演の残りは、なぜ作ったか、どう作ったか、何を学んだかです。

• Ajay Prakash、LinkedIn — AI Engineerでの講演（YouTube）

エンジニアに汎用のコーディングエージェントを渡すだけでは足りなかった理由

LinkedInは多くの会社と同じようにエンジニアへコーディングエージェントを配り、Prakashは大企業ではうまく働かなかったと言います。彼の診断は学習データの空白です。モデルはオープンソースのリポジトリで学習されており、LinkedInの成熟した内部コードベース、フレームワーク、システムを持っていませんでした。

その文脈がなければ、彼の話では、エージェントはハルシネーションを起こすか、作業の途中で止まるか、誤った細部を作り上げました。エンジニアは正しいことをさせようと手でプロンプトを書き、その時間がコードを自分で書くより長くなることがしばしばでした。多くのエンジニアは手作業のコーディングに戻りました。

彼がスケッチした、エージェントが覚えるべきスタックは大きく、ほとんど非公開です。LinkedInの新しいエンジニアは、それらのシステムに慣れるだけのために1週間のブートキャンプを受ける、と彼は言います。そのオンボーディングを、エージェントにも同じ組織の文脈が要る理由のたとえに使います。

• 数千のマイクロサービスとアプリを支える1,000を超えるリポジトリ
• それらのサービスの下にある内部フレームワークとライブラリ
• 自前のデータベース、実験とトラッキングの基盤、内部の構成管理システムのような独自インフラ

基準は、どのエージェントでも信頼できる内部コード

彼らが置いた設計の問いは、CursorでもClaude CodeでもGitHub Copilotでも、どのコーディングエージェントがLinkedInの内部を十分に理解し、エンジニアが信頼するコードを出せるかでした。Prakashはその信頼を二つで定義します。コードが正しいこと、そして品質が実際のエンジニアが書いたコードに並ぶことです。

それが、チームが置いたと彼が言う基準です。

最初の突破口は社内のMCPツールだった

Prakashは最初の突破口を2025年初めに置きます。彼は、Anthropicがエージェントを外部ツールにつなぐModel Context Protocol、つまりMCPを出し、それがエージェントツールを作る業界標準へ急速になり、LinkedInは最初のツールが全社のコード検索である内部MCPサーバーを作った、と言います。自動字幕は「MCB」と「Cloud Code」に滑ります。講演が指しているのはAnthropicのMCPプロトコルとClaude Codeです。

LinkedInにはすでに、キーワードと独自フィルタで数千のリポジトリを問い合わせられる精緻なコード検索がありました。そのシステムをMCPで開くと、エージェントは所定のセットアップをLinkedInがどうやるかの社内例を見つけ、その結果から実装できました。Prakashはこれを大きな突破口と呼びます。エンジニアがセットアップの仕方を尋ねれば、エージェントは推測せずにLinkedInのコードを検索できました。

続いて文書、Jira、Slack、データ基盤、フィーチャーフラグをMCPで足しました。彼は、エンジニアがプロダクト要求仕様（PRD）、設計文書、Jiraチケットをコーディングエージェントに入れるにつれて価値が積み重なった、と説明します。

ツールだけでは仕事を終われなかった三つの理由

それらのツールをつないでも、やや複雑なワークフローでは失敗したままでした。ツールがあれば、Prakashの話では、エージェントは基本的な質問に答え、コード例を見つけられました。仕事を端から端まで安定して終えるのは、別の基準でした。

一つ目の失敗は、散らばった現場の知識です。特定の仕事を終えるには、与えられたエラーの直し方、システムの設定の仕方、特定のログのデバッグの仕方を知る必要がありました。その知識は文書、ウィキ、Slackの会話に分かれ、古いか重複していることがしばしばでした。ツールはそこにある資料を取ります。そこから手順を組み立てるのは別の段です。アクセスできるエージェントも、依然として「迷いました」。

二つ目の失敗はコンテキストの過負荷です。ツールの結果が返るたびに、エージェントのコンテキストウィンドウ、つまりそのセッションの作業記憶を使いました。やがてセッションは前の内容を要約するか捨てて圧縮しなければならず、情報が落ちてエージェントは仕事をやり直しました。

三つ目の失敗は、セッションをまたぐ記憶がないことです。エージェントがタスクをつかんでも、次のエンジニアが同じ仕事を頼むと最初からでした。プレイブックはのちに、これをリポジトリ内の指示ファイルとして扱います。

• 特定のエラー、設定、ログについての現場の知識は、文書、ウィキ、Slackに散らばっていた
• ツールの結果がコンテキストウィンドウを埋め、圧縮で情報が落ちた
• 解けたタスクにも持続する記憶がなく、次のセッションは最初からだった

プレイブック：ツールと同じ渡り方をする指示

Prakashは、2025年初めに、MCPがツールと、それを使う指示やプロンプトの両方を渡すようにプレイブックを作った、と言います。各プレイブックは、エージェントが呼び出せる、名前と説明の付いたツールとして現れます。呼ぶと指示と文脈がツール出力として返るので、エージェントは同じ経路で機能と案内を受け取ります。

彼が使う利用の話は、エンジニアがLinkedInでApache AirflowのDAG、つまりタスクの有向非巡回グラフをどう立てるかを尋ねる場面です。エージェントはそのタスクのプレイブックを選び、返った指示を読み、関連するツールを呼んで仕事を終えます。

LinkedInの誰でもプレイブックを書き、リポジトリに入れ、他の人に使わせられます。

書くときの二つの原則と、スキルとの比較

プレイブックが増えると、Prakashは全員に二つの基本原則に従うよう求めた、と言います。第一に、プレイブックは一つの具体的なタスクだけで自己完結し、エージェントが正しいものを選べるようにします。Airflow DAGのプレイブックは、そのDAGの話に留まります。

第二に、大きなプレイブックは、親が参照できる小さなプレイブックに分けます。分けると、彼の話では二つ得られます。小さなプレイブックを複数の親から参照できるので再利用でき、エージェントはその文脈の断片が必要なときだけ小さなプレイブックを読むので、段階的に発見できます。

彼はプレイブックをスキルとも比べます。スキルは、エージェントが必要なときに読めるよう指示をパッケージする業界の型です。Prakashは、プレイブックは同じアイデアであり、LinkedInはスキルが存在する前にプレイブックの仕組みを作り、プレイブックは組織の文脈を捉え、準備をほとんど要さずMCPで渡すほうにより寄せてある、と言います。

プレイブックを古くさないために促している循環

彼が挙げる知識ベースの問題は、古くなることです。指示が時代遅れになります。促しているエージェントの流れは、プレイブックを使い、セッションの終わりに学び、つまり古い、食い違う、欠けている情報を見つけ、リポジトリのプレイブックファイルを直し、プルリクエストを開くことです。

彼はプルリクエストのあとプレイブックが更新されると言います。彼はこれをフライホイールと呼びます。エージェントが会社の指示を使い、同時に更新する、という意味です。

ノートPCのMCP一つ、中央のプレイブック、ローカルのプレイブック

彼が説明する配布は、LinkedInのノートPCに最初から入っているローカルMCPサーバーです。入社してノートPCを受け取れば、サーバーはすでにあります。Prakashは、サーバー、プレイブック、ツールの更新が1時間ごとに届くと言います。

プレイブックは二種類に分かれます。中央のプレイブックは、多くのリポジトリにまたがる横断的な仕事を扱います。ローカルのプレイブックは特定のリポジトリにあり、コーディングエージェントがそこで作業しているときだけ拾われます。中央のカタログを変えずに、リポジトリ固有の知識を増やせます。

一つのMCPサーバーがすべてのプレイブックとツールの前面に立ち、認証、テレメトリ、学習を中央で扱えます。

すべてのツールを並べるのをやめた理由

MCPの表面にプレイブックとツールをすべて載せるやり方は、彼がMCPでよくある問題とみなす規模の限界に当たりました。ツールがおよそ30個か40個を超えると、コンテキストとシステムの性能が落ちました。

彼らが使った間接化は、カタログの前に三つのメタツールを置く形です。エージェントはキーワードとタグで検索し、選んだツールかプレイブックのスキーマを取り、その項目を実行します。LinkedInは各コーディングエージェントに、検索と残りのメタツールを効率よく使うシステム指示をあらかじめ入れます。Prakashは、この設計でツールとプレイブックを数千まで広げられた、と言います。

誰が使い、企業への二つの結論は何か

壇上で見せた成長チャートについて、Prakashはツールとプレイブックの1日の利用者が8,000人を超え、プレイブックは600を超えると挙げます。プロダクトマネジャー、デザイナー、テクニカルプログラムマネジャー（TPM）も、エンジニアとともに職能をまたいでツールを使い、プレイブックを持ってくると彼は言います。公開された動画タイトルは講演を「500 Skills, Zero Fine-Tuning」と包装しています。話された講演には、スキル500という数も、ファインチューニングをしない方針もありません。

彼の一つ目の結論は、MCPサーバーを作る前を含めて品質と信頼性を初日から制約にしたから、このシステムは働いた、というものです。彼はこの原則を、速く動いても劣化しないよう、生産性とともにシステムの品質と信頼性を保つことだと説明します。

二つ目の結論は、MCPの検索とチケットをすでに結んだ実務の開発者への主張です。大企業では、彼の話では、会社がエージェントがその中で動けるインフラも作らなければ、最新のエージェントとモデルは効かないままです。そのインフラとは、プレイブック、ノートPCのMCP、そしてカタログがセッションを埋め尽くさないようにするメタツールです。

• YouTubeで講演を見る