問題点：AIエージェントはあなたの組織を知らない
AIコーディングアシスタントは、私たちのコード記述を革命的に変えました。彼らは関数を生成し、エラーをデバッグし、最適化を数秒で提案します。約束は明確です：AIを共同パイロットとして活用し、10倍の開発者になることです。
しかし現実はこうです：AIエージェントが組織の内部インフラストラクチャと連携する必要が生じた瞬間、魔法は崩れます。
あなたのAIエージェントは次のことを知りません：
- チームが使用するデザインシステム
- CI/CDパイプラインの構成
- ロギング、メトリクス、トレースの内部ライブラリ
- 組織のコーディング標準と規約
- ステージング環境の管理方法
- 存在するサービスとその相互作用
- デプロイ作業と要件
倍率ではなく、足を引っ張る存在になります。ドライバーの代わりに、数分おきに道順を尋ねる乗客になります。
これはフロントエンドの問題ではありません。特定の企業だけの問題でもありません。 AI開発ツールを導入するすべての組織が直面する普遍的な課題です。
根本原因：コンテキストが全てを決める
AIエージェントは非常に強力ですが、彼らが持つコンテキストに依存します。公開ライブラリやフレームワークを扱う場合、AIは豊富な訓練データ、ドキュメント、および例にアクセスできます。しかし、内部ツールや組織基準は彼らにとってブラックボックスです。
従来の解決策は、文書を手動で貼り付けたり、チャットでアーキテクチャを説明したり、AIに試行錯誤をさせたりすることでした。これは単純なタスクには機能しますが、拡張性がありません。10xの生産性を本当に実現するわけではありません。
私たちの解決策：AIエージェントに組織について教える
私たちの組織では、フロントエンドインフラストラクチャに関するこの問題に正面から取り組みました。解決策は3つの主要な要素から成ります：
1. 包括的なドキュメンテーション層
私たちは、以下をカバーする構造化ドキュメントを作成しました：
- アーキテクチャ文書: 複数サービスのポータルアーキテクチャの仕組み、リクエストフロー、システム設計
- 規約: 命名規則、コーディングパターン、ベストプラクティス
- ワークフロー: 翻訳パイプライン、デプロイチェックリスト、貢献ガイドライン
- 視覚的図表: リクエストフロー、ビルドパイプライン、デプロイプロセスを示すMermaid図
これは単なるリポジトリ全体のREADMEファイルの寄せ集めではなく、AIが活用するためにキュレーションされ、相互接続された知識ベースです。
2. リビング・プロジェクトカタログ
私たちは、豊富なメタデータを備えたフロントエンドインフラストラクチャの全プロジェクトのカタログを維持しています：
- プロジェクトタイプ（サービス、ライブラリ、テンプレート）
- 技術スタック
- npmパッケージ名
- 内部依存関係
- ドキュメントリンク
- オーナー情報
これにより、AIエージェントはエコシステムの全体像を把握でき、何があり、どう接続され、追加情報をどこで見つけるかを知ることができます。
3. MCPサーバー：AIとインフラの橋渡し
Model Context Protocol (MCP) サーバーを介して、AIエージェントが外部ツールとデータソースへアクセスする標準的な方法を提供します。
私たちのMCPサーバーは、AIエージェントに以下の専用ツールを提供します：
Discovery Tools:
list_projects: 利用可能なフロントエンドインフラプロジェクトを閲覧get_project_metadata: 依存関係、技術スタック、ドキュメントリンクを含む特定プロジェクトの詳細情報を取得
Documentation Tools:
get_architecture_docs: アーキテクチャ文書、図、規約、ワークフローを取得get_documentation: プロジェクト固有のドキュメントとガイドへアクセス
Source Code Tools:
list_project_files: リポジトリ構造とファイル組織を探索get_project_files: 任意のプロジェクトからソースコードを取得（適切な認証が必要）
Scaffolding Tools:
clone_template: 承認済みテンプレートから新しいサービスをスキャフォールドする手順を取得
すべてはOkta認証を通じて安全に行われ、AIエージェントが開発者が閲覧を許可された情報のみを見ることができます。
実践での仕組み
現実的なシナリオを見てみましょう。
Developer: 「チャート付きのユーザー分析を表示する新しいフロントエンドサービスを作成して」
Without MCP Server:
AI: I'll create a React app with Chart.js... Developer: No, we use our internal design system AI: Which design system? Developer: Our component library AI: How do I import it? Developer: *pastes package name and import examples* AI: How should I structure the service? Developer: *explains our multi-service architecture* AI: How do I deploy it? Developer: *explains deployment pipeline, service registration, manifest files, etc.*With MCP Server:
AI: Let me check your frontend infrastructure... [Calls list_projects to discover available tools] [Calls get_architecture_docs to understand the system] [Calls get_project_metadata to learn about the component library] [Calls clone_template to get the service template] I'll scaffold a new service using your standard template, integrate with your component library, and set up the deployment configuration following your conventions.AIエージェントは必要な情報を自律的に発見し、組織標準に従い、インフラにぴたりと適合する本番運用可能なコードを作成します。
影響
このアプローチにより、組織は以下を実現できます：
- オンボーディング時間の短縮: 新しい開発者はAIエージェントが組織の標準を案内することで、より早く貢献を開始できます
- コード品質の一貫性: AIエージェントが自動的に規約を遵守します
- 本番環境の問題の減少: AIエージェントは開発者が見逃す可能性のあるデプロイ要件を把握します
- 機能開発の高速化: 開発者はコンテキストの説明に費やす時間を減らし、機能構築に集中できます
より大きな視野: すべての組織にこれは必要です
私たちの実装はフロントエンドインフラに特化していますが、パターンは普遍的です。内部ツール、プラットフォーム、標準を持つすべての組織がこの課題に直面します。
Model Context Protocolは、それを解決する標準化された方法を提供します。内部フレームワークを備えたバックエンドサービス、カスタムSDKを備えたモバイルアプリ、独自ツールを備えたインフラストラクチャ、内部プラットフォームを備えたデータパイプラインなど、何を構築する場合でも適用可能です。
組織固有のコンテキストについてAIエージェントに教える方法が必要です。
重要なポイント
- AIエージェントは強力だが、コンテキストには盲点がある: 明示的に組織知識へアクセスさせる必要があります
- ドキュメンテーションだけでは不十分: 情報を機械可読な方法で公開する構造化された方法が必要です
- MCPは私たちに有効でした: Model Context ProtocolはAIエージェントを拡張するための実証済みパターンを提供しました — あなたにも有効かもしれませんし、ニーズに合う別の実装を見つけることもできるでしょう
- セキュリティは重要です: 適切な認証によりAIエージェントがアクセス制御を尊重します
- 小さく始めて、反復する: 最も重大な課題から始め、時間とともに拡大していきます
はじめに
同様の仕組みを自組織向けに作ってみたい場合は、実際の痛点を特定することから始めましょう：
- 実務タスクでテストする: 「新しいサービスを作成する」「このエンドポイントに認証を追加する」「このコンポーネントのモニタリングを設定する」など、組織内の一般的なタスクをAIエージェントに実行させる
- 欠落している知識を特定する: AIが失敗したり誤ったコードを生成する場合、欠けている組織知識は何かをメモする - デプロイプロセスか、内部ライブラリか、コーディング規約か
- まずはコンテキストを手動で追加する: 欠落している情報をチャットに直接提供し、そのコンテキストでAIがタスクを正しく完了できるか検証する
- 2〜3のユースケースを収集する: 異なるシナリオでこのプロセスを繰り返し、AIエージェントに最も必要な知識のパターンを理解する
- そのユースケース向けのツールを構築する: 明確なパターンが見えてきたら、それをプログラム的に提供するMCPツールを作成する — 最も一般的な痛点に対応するツールから始める
- 元のタスクで検証する: ツールが実際にAIエージェントがユースケースのタスクを手動介入なしで解決するのに役立つか試す
このアプローチは、実際の問題を解決するツールを作ることを保証します。使われない可能性のあるインフラを作るのではありません。
AI支援による開発の未来は、よりスマートなモデルだけではなく、それらのモデルに組織を理解させる適切なコンテキストを与えることです。そのギャップを埋めれば、AIエージェントは本当に10xの乗数になるのです。
Model Context Protocolについてもっと知りたいですか？ 仕様と例は modelcontextprotocol.io をご覧ください。
元は debuggr.io で公開されました。
私はソフトウェアエンジニアリング、AI、そして私たちの業界についての悩みを書いています。もしこの話があなたに共鳴したら、より多くの情報を debuggr.io でご覧ください。
