プラカシュ氏によると、LinkedInがAIコーディングエージェントを導入した際、大きな課題になったのが、AIが同社固有の開発環境を知らないことだった。

　プラカシュ氏によると、一般的なAIコーディングエージェントはオープンソースのコードリポジトリなどを学習に利用している。一方、LinkedIn固有のコードベースや社内フレームワーク、独自システムについての知識を持っていない。

　プラカシュ氏は「AIエージェントに正しい処理をさせるため、人間が細かく指示しなければならず、手作業でコードを書くより時間がかかることもあった」と述べる。結果として、AIコーディングを試したものの、従来の手作業に戻るエンジニアもいたという。

　この問題の背景には、LinkedInの開発環境の複雑さがある。同社には1000を超えるコードリポジトリがあり、それらが多数のマイクロサービスやアプリケーションを構成する。独自のデータベースや実験基盤、設定管理システムなども存在する。

　LinkedInに新しく入社したエンジニアは、こうした社内システムを理解するために約1週間の研修を受けるという。

　そこでプラカシュ氏は、AIコーディングエージェントにも「LinkedInの内部システムを理解し、人間のエンジニアと同等の品質で信頼できるコードを作れる状態」を目標として設定したと説明する。

MCPで社内ツールにつないでも解決しなかった

　LinkedInは2025年初頭からMCPを利用した社内向けの仕組みを構築した。最初にAIエージェントが利用できるようにしたのが、社内のコード検索システムだった。これによってAIエージェント自身が多数のリポジトリからコードを検索し、「LinkedInでは同種の処理をどのように実装しているか」を調べられるようになった。

　その後、ドキュメント、Jira、Slack、データ基盤、フィーチャーフラグなどにもAIエージェントの接続対象を広げた。製品の要件文書や設計書、Jiraのタスクなど、複数の社内情報をAIコーディングに利用できるようになった。

　しかしプラカシュ氏は、「ツールへ接続できるだけでは不十分だった」と振り返る。簡単な質問への回答やコード例の検索はできても、ある作業を最初から最後まで安定して実行させることは難しかったからだ。

　その理由の1つが、社内の「暗黙知」だ。例えば、特定のエラーをどう調査するのか、あるシステムをどう設定するのかといった知識は、ドキュメントや社内Wiki、Slack上の会話などに分散している。資料そのものが古かったり、似た内容の文書が複数存在したりするケースもある。

　AIエージェントがそれらの情報にアクセスできても、「どの情報を参照し、どの順番で処理すればよいか」が分からなければ、作業を安定して完了できない。

ツールだけでなく「仕事の進め方」もAIに渡す

　そこでLinkedInが構築したのが「playbook」だ。playbookには、特定の作業を実行するための指示や必要なコンテキストがまとめてある。AIエージェントからは通常のツールのように見え、必要な作業に応じて呼び出せる仕組みだ。

　プラカシュ氏はplaybookの例として、LinkedInでAirflow DAGを作成するケースを挙げた。Airflow DAGとは、ワークフロー管理ツール「Apache Airflow」で、複数の処理を実行する順番や処理同士の依存関係を定義したワークフローのことだ。

　同氏は「AIエージェントはまず、その作業に対応するplaybookを取得する。その指示に従って、必要なツールを呼び出して作業を進める」と述べる。

　つまり、「コード検索」「Jira」「Slack」といった個別ツールへのアクセス権をAIに与えるだけではない。playbookを通じて、「この作業では最初に何を確認し、その後どのツールを使い、どう進めるか」という企業固有の作業手順もAIエージェントに渡す。

　MCPが「何を使えるか」をAIエージェントに提供するとすれば、playbookは「それをどう使って仕事を進めるか」を補う仕組みと捉えることができる。

大きな手順書を丸ごと読ませない

　プラカシュ氏によると、LinkedInはplaybookを作る際、2つの基本原則を設けた。1つは、1つのplaybookに1つの具体的な作業だけを持たせることだ。例えばAirflow DAGの作成用であれば、その作業に必要な情報だけを収める。

　もう1つは、大きなplaybookを複数の小さなplaybookに分割することだ。

　プラカシュ氏は「小さく、自己完結したplaybookに分けることで、複数の作業から再利用できる」と説明する。さらに、AIエージェントは最初から全ての情報を読み込む必要がなくなる。作業の進行に応じ、必要になったplaybookだけを順番に取得できる。

　同氏はこの考え方を「progressive discovery of context」というキーワードで表現している。AIエージェントに企業内の知識を一度に全て与えるのではなく、必要な文脈を段階的に追加する設計を意味している。

AIに情報を与え過ぎても性能は落ちる

　必要な情報を段階的に取得する背景には、AIエージェントの「コンテキスト過多」という問題もある。

　AIエージェントが多数のツールを使えば、それぞれの実行結果がコンテキストを消費する。情報量が増え過ぎると、処理中に情報が圧縮され、一部の情報を失う場合がある。その結果、同じ調査をやり直すことになるという。

　一方プラカシュ氏は、AIエージェントが抱えていたもう1つの課題を挙げる。それは、「AIエージェントには、調べた内容を次回まで保持する永続的な記憶がなかった」という点だ。毎回ゼロから調査するのでは非効率だ。そこでLinkedInは、AIエージェントが毎回必要な手順を探し直さなくても済むよう、業務知識や作業手順をplaybookとして管理し、必要なときに取得できる仕組みを構築した。

AI自身が「古い手順書」を見つける

　企業内の知識をAIエージェントが参照できるようにすると、次に問題になるのが情報の陳腐化だ。そこでLinkedInは、AIエージェントがplaybookを利用した後、内容に古い情報や不足、矛盾がないかを確認する仕組みを設けた。

　具体的には、「AIエージェントには、playbookを使ったセッションの最後に学びを振り返り、古い情報や不足している情報を特定するよう促している」とプラカシュ氏は話す。

　改善できる内容があれば、AIエージェントがplaybookの修正案を作り、PR（プルリクエスト）を作成する。この仕組みによって、AIエージェントが社内ナレッジを使うだけでなく、実際の利用結果を基にそのナレッジを更新する循環を作っている。

ツールが増え過ぎたら、AIに「検索」させる

　playbookやツールを増やしていくと、別の問題が発生する。多数のMCPツールをそのままAIエージェントに提示すると、コンテキストを圧迫し、性能が低下する。プラカシュ氏は、「MCPでは、30～40程度を超えてツールを増やすと、コンテキストやシステムの性能に影響が出る」と説明する。

　そこでLinkedInでは、全てのツールやplaybookを直接AIエージェントに見せるのではなく、「search」など3つのメタツールを用意した。

　AIエージェントはまずキーワードやタグを使い、必要なツールやplaybookを検索する。候補が見つかれば、そのツールの詳細な仕様を取得し、必要なものだけを実行する。この設計によって、AIエージェントは多数のツールやplaybookを利用できるようになったという。

障害対応では原因分析からPR作成まで

　プラカシュ氏によると、LinkedInではAIエージェントの仕組みを障害対応にも利用している。例えばサービスのエラー増加を知らせるアラートが発生した場合、AIエージェントは社内のデバッグ手順を取得し、対象となるサービスを特定する。

　その後、必要なログやメトリクスを取得して原因を分析し、対処方法を整理する。人間が確認すれば、対処作業も実行する。

　さらに、インシデント管理システムへ情報を記録し、根本原因を修正するためのPRまで作成するという。プラカシュ氏によると、「手作業なら数時間かかる可能性がある一連の処理を、数分で進められる」という。

「最新AIを配るだけ」では企業内で機能しない

　LinkedInの事例で注目したいのは、AIモデルそのものだけを改善するのではなく、「AIが企業内で仕事をするための基盤」を整備している点だ。

　プラカシュ氏は「大企業では、最新のツールやモデルをエンジニアに提供するだけでは十分ではない」と述べる。

　企業固有の環境では、AIエージェントが社内システム、知識、作業手順を適切に利用できるインフラが必要だからだ。

　同氏は、LinkedInの取り組みで当初から重視したのは、生産性だけではなく「品質と信頼性」だったと振り返る。

　社内でAIエージェントを導入する情報システム部門担当者やAI開発の担当者にとっても、検討すべきなのは「どのAIモデルを採用するか」だけではない。「自社の暗黙知をどう整理するか」「どの情報を、どのタイミングでAIに与えるか」「古くなった知識をどう更新するか」といったコンテキスト設計が、AIエージェントを実務で使えるものにする上で重要な論点になる。

本稿は、AI Engineerが2026年9月9日に公開した500 Skills, Zero Fine-Tuning: LinkedIn's Playbook for AI Agents — Ajay Prakash, LinkedInを基に作成しました。