エンジニア1万人規模の組織で、チームごとに別々のAIエージェントを作り始めたら何が起きるか。LinkedInの答えは「100種類の脆い実装」だ。同じオーケストレーション、ツール接続、コンテキスト管理を何度も繰り返すコストは、プラットフォームチームが吸収すべき課題として整理されている。
この記事では、LinkedInがAIを「新しい実行モデル」として位置づけ、MCP（Model Context Protocol）とマルチエージェント基盤で開発・運用・分析をどう支えているかを解説します。
この記事でわかること
- AIを実行モデルとして適用する3つの領域と、プラットフォーム化が必要な理由
- オーケストレーション・ツール・コンテキスト・メモリの4層アーキテクチャ
- コーディング、障害観測、UIテスト、分析など実運用のエージェント事例
- CAPT（Contextual Agent Playbooks and Tools）がもたらした定量的な効果
AIを「実行モデル」として捉え直す
LinkedInは会員13億人、デプロイ可能ユニット約7,000、ピーク時QPS約320万、Kafkaメッセージ1日45兆件、リポジトリ1万超、年間PR100万件超という規模を抱える（InfoQ発表）。従来のCLI、セルフサービスUI、ドキュメント検索は、認知ループの途中で人間が手を動かす必要があり、自動化の限界があった。
Distinguished EngineerのKarthik Ramgopal氏とPrincipal EngineerのPrince Valluri氏は、AIをコード生成の補助ではなく「実行モデル」として位置づける。人間は意図（Intent）を構造化して渡し、システムが計画（Plan）→実行（Execution）→検証（Validation）→成果物（Output）を担う。PRのようなレビュー可能なアーティファクトに、全ステップのトレースが付く。
適用領域は3つに絞られている。作業が反復可能で、調整コストが高く、結果を検証しやすい場面だけだ。
- 開発：定型コーディング、マイグレーション、テスト生成
- 運用：デプロイ準備、信頼性管理、インシデント対応でのコンテキスト収集
- 情報取得：セマンティックなコード検索、分析クエリの組み立て、複数システムにまたがるトラブルシュート
プラットフォーム4層で「100個の実装」を防ぐ
チーム単位でエージェントを作ると、オーケストレーション、ツール、コンテキスト、安全性をそれぞれ再実装する。LinkedInはこれをプラットフォーム責務として4層に分けた。
オーケストレーション層
開発者がチャットやAPIで構造化スペックを送ると、オーケストレーターがサンドボックスを起動する。エージェントはコード変更、テスト実行、修正を非同期で進め、ツール呼び出しはすべてスコープ制限・権限チェック・監査ログ付きだ。テストのフレークやビルド失敗はリトライとバックオフで処理し、エージェントはタスクに集中できる。
ライブラリのバージョンアップを全影響リポジトリに適用するケースでは、依存グラフから対象を特定し、リポジトリごとにサンドボックスを起動。計画→変更→ビルド→テスト→PR作成の流れが1件でも100件でも同じ手順で走る。
ツール層とMCP
MCP（Model Context Protocol）はAnthropicが提唱する、AIエージェントとツールを接続するオープン標準だ。LinkedInがMCPを選んだ理由は2つある。異なるモデルを動かすエージェントが同じツールセットを共有できるモデル独立性。ツールを単なる関数ではなく、権限・リトライ・スキーマ検証・可観測性フックを内包する「ケイパビリティ」として扱える点だ。
内部ツールの例は、セマンティックコード検索と依存分析、ログ・メトリクス・アラート・インシデントへのアクセス、PR履歴・オーナーシップ・システム構成の参照だ。エージェントはAPIを直接叩かず、承認済みツール経由でのみ外部システムに触れる。
このツール基盤の具体実装がCAPT（Contextual Agent Playbooks and Tools）だ。LinkedInのエンジニアリングブログによると、CAPTはMCP上に構築され、社内システムとサードパーティサービスへのアクセスに加え、複数ステップのワークフローをPlaybookとして公開する（LinkedIn Engineering Blog）。
ツールが数百に増えた際、CAPTはメタツール方式を採用した。get_tools_for_tags、get_tool_info、exec_toolの3関数で、タグ（実験、ログ、メトリクス、デプロイなど）に基づきLLMがツールを発見・実行する。エージェントに全ツールのスキーマを毎回渡す必要がなくなり、コンテキスト肥大と精度低下を抑えている。
コンテキスト層
モデルを強化しても改善が頭打ちになるのは、エージェントが「知らないことを知らない」からだ。LinkedInは失敗の多くが推論能力不足ではなく、欠落・陳腐化・不完全な事実に起因すると指摘する。
コンテキストは段階的に絞り込む。タスクに関係するリポジトリとサービスにスコープを限定し、計画段階では依存グラフとオーナーシップ情報、実行段階では具体的なコード断片を渡す。過去のPRからセマンティック理解を構築し、Gradle 9へのアップグレードのようなマイグレーションで他リポジトリの先例を参照できる。
メモリ層
LLMはステートレスなので、各呼び出しに文脈を再注入する必要がある。LinkedInは3種類のメモリを使い分ける。
- ワーキングメモリ：タスク中のメッセージ履歴と中間推論（タスク終了で消える）
- 長期メモリ：検証済みの教訓（手続き的・エピソード的知識）
- 集合メモリ：全エージェント・全チームで共有する慣習とベストプラクティス
実行後、レビュー承認やテスト失敗パターンなど「記憶に値する」情報を抽出し、次回の計画に反映する。
サンドボックスと人間の役割
エージェントのサンドボックス内では、ファイル読み書き、依存クエリ、ビルド・検証、PRブランチへのプッシュが許可される。一方、本番・ステージングへのデプロイ、mainブランチへのマージ、不可逆なシステムコール、無制限のインターネットアクセスは禁止だ。
人間は各ステップを監視するのではなく、成果物をレビューする。マージやデプロイの承認は常に人間が担い、承認・却下のフィードバックがシステムの学習データになる。エージェントは継続実行し、権限が必要な地点で一時停止する設計だ。
実運用の5つのエージェント
理論を超え、LinkedInが実際に稼働させているエージェントには次のようなものがある。
GitHub Copilotの拡張：20年以上の組織固有の文脈をCopilot単体では扱えない。ローカル・リモートのMCPサーバーでLinkedIn固有のコンテキストを注入し、コード検索ツール経由で社内のLLM呼び出しパターンを生成例として渡す。各プラットフォームチームが自チーム用MCPを立ち上げる分散モデルだ。
バックグラウンドコーディングエージェント：構造化スペックを非同期実行し、隔離サンドボックスで変更。監査トレース付きのPRを出力する。再利用可能なプロンプトテンプレートで反復タスクを標準化している。
Observeエージェント（ニアライン）：アラート発火をトリガーに起動し、複数システムの情報を単一画面に集約。過去のインシデントや類似障害をツールとメモリから引き、オンコールの初動調査を圧縮する。
UI QAエージェント（バッチ）：サーバー駆動UI（Server-Driven UI）では、iOS・Android・Webでサーバー側のコンポーネント変更がクライアント表示に反映される。UIの内部実装が動的に変わるため、従来の統合テストでは追従できない。自然言語で機能仕様（「コメント投稿後にフィードに表示される」など）を記述し、定期バッチで回帰を検出する。
分析エージェント（オンライン）：テキストとチャートを出力するマルチモーダルなチャットボット。エンジニアだけでなくPMやビジネスオペレーションも利用し、新しいデータソースを追加すれば対応範囲が広がる。
マルチエージェント連携の例
インシデント調査エージェントは単体では動かない。裏側でInsightsエージェントが状況を把握し、Codingエージェントが修正を作成、Evaluatorエージェントが妥当性を確認する。ユーザーから見えるのは調査エージェントのファサードだけだ。
CAPTが示した定量的効果
InfoQの講演がアーキテクチャの骨格を示す一方、CAPTはその実装と効果を数値で裏付けている。ローンチから6か月後の時点で、1,000名超のエンジニアが利用し、500超のPlaybookが社内で作成された。顧客問い合わせの初動トリアージ時間は約70%短縮、データ分析ワークフローは約3倍速く、SparkジョブやML学習のデバッグ時間は半数以上削減されたケースがある（LinkedIn Engineering Blog）。
LinkedInが強調する教訓は「知性より文脈」だ。特殊なモデルではなく、正しいツール・システム・Playbookに主流モデルを接地させることで効果が出る。MCPのようなオープン標準を選び、既存ツール（GitHub Copilotなど）を拡張する「買う・拡張する」戦略が、自前構築より速い進化を可能にしている。
モデル選定と信頼の確立
推論が不要ならAIを使わず、コードかルールで処理する。推論が必要でも、まず商用クラウドモデルのAPIから始め、RAGやキャッシュで対応し、それでも足りなければファインチューニング、最後の手段としてプリトレーニングに進むピラミッドを推奨する。
信頼は「雰囲気」ではなくEvalで築く。ゴールデンデータセット、客観的シグナル、LLM-as-a-Judgeによる主観評価、回帰検出を組み合わせ、エージェントの推論チェーンとツール呼び出しをすべて記録する。Prince Valluri氏は1万名超のエンジニアの生産性向上を担うTech Leadとして、標準化された実行環境と堅牢なコンテキストエンジニアリングの実装を提言している（QCon AI 2025）。
大規模エンジニアリング組織がAIを本番ワークフローに組み込むなら、個別チームの実験を止めるのではなく、オーケストレーション・ツール・コンテキスト・評価を共通化するプラットフォーム投資が分岐点になる。LinkedInの事例は、その設計判断と実装パターンの参照点として機能する。