9月19日、InfoQが「Context Engineering at LinkedIn: How We Built an Organizational Context Layer for AI Agents with MCP」と題した記事を公開した。この記事では、LinkedInがMCP（Model Context Protocol）を活用して大規模コードベース向けの「コンテキストエンジニアリング層」を構築し、AIエージェントを実用レベルで活用できるようにした取り組みについて詳しく紹介されている。
最初に押さえるべき成果：600超のワークフロー、数時間の作業が数分に
この取り組みの結果として、現在LinkedInでは600以上のワークフローと数千のツールが稼働している。オンコール中のエンジニアがレイテンシスパイクのアラートURLをエージェントに渡すと、原因特定から修正PRの作成まで数時間かかる作業が数分で完了する。こうした成果を可能にした仕組みが、本記事で紹介する「Playbook（手続き的記憶）」とMCPを組み合わせたコンテキストエンジニアリング層だ。
問題の本質：巨大なコードベースとコンテキストの欠如
LinkedInのソフトウェアエンジニア、Ajay Prakash氏が語る課題は、多くの企業が直面しているものだ。
LinkedInのスタックは数千のリポジトリ、数千のマイクロサービスから成り、すべての層に内製フレームワークが存在する。カスタムデータベース、独自のトラッキング・実験システム、観測基盤、設定管理—これらはLinkedInのスケールに特化して作られている。新入社員でも1週間以上のブートキャンプを経て初めてシステムを理解し始め、実際に生産性を発揮できるまで数週間かかる。
GitHub CopilotなどのAIコーディングエージェントを全エンジニアに解放したとき、「バイブコーディング（vibe coding＝LLMと対話しながら直感的にコードを書き進めるスタイル）」はうまく機能しなかった。LLMはオープンソースコードで学習されているため、LinkedInの内部コードの文脈を知らない。エンジニアたちはエージェントを正しい方向へ誘導するために絶えずプロンプトを書き直すことになり、「エージェントの子守」という本末転倒な状況が生まれた。
MCPで外部ツールを接続し、コードサーチを武器に
転機はAnthropicがModel Context Protocol（MCP）をオープンソース化したことだ。MCPはエージェントとツールをつなぐオープン標準として急速に普及し、主要なコーディングエージェントがこれを採用した。
LinkedInがまず接続したのは、社内のコード検索システムだ。1,000以上のリポジトリを横断し、キーワードやRegex、ファイルタイプ・言語などのフィルタで検索できる既存の仕組みをMCPでラップした。これによりエージェントは事前学習データに頼らず、「LinkedInのコードが実際にどう書かれているか」をリアルタイムで参照できるようになった。
「LangChainの使い方を見せて」のような曖昧な自然言語クエリでも、エージェントは検索クエリを繰り返し変えながら関連コードを探し当てられる。
その後、ドキュメント・Wiki検索、フィーチャーフラグ、タスク管理、データプラットフォームへのアクセスも順次追加した。それでも複雑なタスクになると動かないという壁にぶつかった。
残った3つのギャップ
部族知識（Tribal Knowledge）の問題：依存関係のインストール方法、コンパイルやテストコマンドの書き方といった暗黙知は、ドキュメントにも存在せずベテランエンジニアの頭の中にしかない。ツールを増やしても「干し草の山から針を探す」状態は解消されなかった。
コンテキスト過負荷：ツールの呼び出しが増えるほどLLMのコンテキストウィンドウが埋まり、最終的に強制的なサマリー（コンパクション）が発生する。情報が失われたエージェントは同じツール呼び出しをやり直し、奇妙なループに陥る。
長期記憶の欠如：あるタスクをこなすのに必要なコンテキストを一度見つけても、次回は最初からやり直し。トークンも時間も無駄になる。
解決策：「Playbook」による手続き的記憶
Prakash氏が提案したのが手続き的記憶（Procedural Memory）の概念だ。タイトルでいう「組織の記憶」はまさにこれを指しており、エージェントが毎回ゼロから暗黙知を探し直すのではなく、組織として蓄積した手順知識をエージェントに直接渡せる仕組みを意味する。
実装上の参照点として、AnthropicがAgent Skillsとしてオープンソース化した考え方がある。Agent SkillsはLLMに再利用可能なスキル定義を与えるという方向性で共通しているが、LinkedInでは独自の要件（内製フレームワークの多さ・MCP経由での配布・誰でもチェックインできる中央リポジトリ運用）に合わせて「Playbook」として独自実装している。Agent Skillsと思想は近いものの、あくまでLinkedIn固有のアーキテクチャに最適化された別実装だ。
PlaybookはMCP経由で提供される。構成は名前・説明・手順（Instructions）の3要素で、エージェントは通常のツール呼び出しと同じ感覚でPlaybookを起動できる。
例として挙げられているのがAirflow Playbookだ。「Airflowパイプラインをセットアップして」とエンジニアが依頼すると、エージェントはMCP経由でAirflow Playbookを呼び出し、必要な手順・内部知識をすべて受け取ってからタスクを実行する。
誰でもPlaybookを作成して中央リポジトリにチェックインできる設計になっており、知識の共有インフラとして機能している。
実際の成果：600超のワークフロー
冒頭で触れたデモシナリオをもう少し詳しく見ておこう。オンコール中のエンジニアがレイテンシスパイクのアラートURLをエージェントに渡すと：
- デバッグ手順のPlaybookを取得
- 問題サービスのログ・メトリクス・最近のデプロイを取得
- 原因がダウンストリームサービスの不具合と特定
- 障害を引き起こしたPRを特定
- インシデント管理システムを更新し、修正PRまで作成
数時間かかる作業が数分で完了する。現在LinkedInでは600以上のワークフローと数千のツールがPlaybook・MCPを通じて稼働している。
詳細はContext Engineering at LinkedIn: How We Built an Organizational Context Layer for AI Agents with MCPを参照していただきたい。
