なぜドキュメントが重要なのか
- 最新のAPIとパラメータ
- ベストプラクティス
- 組織の規約・慣習
- ドメインの用語
モデルの知識カットオフ
- 直近のライブラリ更新が反映されていない
- 新しいフレームワークやツールを知らない場合がある
- カットオフ以降のAPI変更を把握していない
- 学習以降にベストプラクティスが変わっている可能性がある
どのツールを使うべき?
メンタルモデル
Tool | メンタルモデル |
---|---|
@Docs | 公式ドキュメントを参照・閲覧するイメージ |
@Web | インターネットで解決策を検索するイメージ |
MCP | 自社(内部)ドキュメントにアクセスするイメージ |
公開ドキュメント
@Docs の使い方
@Docs
は、人気のツールやフレームワークの公式ドキュメントに Cursor をつなぐ機能。最新かつ信頼できる情報が必要なときに使ってね:
- API リファレンス: 関数シグネチャ、パラメータ、戻り値の型
- はじめ方ガイド: セットアップ、設定、基本的な使い方
- ベストプラクティス: 公式が推奨するパターン
- フレームワーク別のデバッグ: 公式のトラブルシューティングガイド
@
@Docs Next.js How do I set up dynamic routing with catch-all routes?
∞
Agent⌘I
Auto
@Web の使い方
@Web
は、最新の情報、ブログ記事、コミュニティでの議論をインターネット上からリアルタイム検索する。こんなときに使おう:
- 最新のチュートリアル: コミュニティ発のコンテンツやサンプル
- 比較: 異なるアプローチを比較した記事
- 最新アップデート: 直近の更新やアナウンス
- 複数の視点: 問題に対する別々のアプローチ
@
@Web latest performance optimizations for React 19
∞
Agent⌘I
Auto
社内ドキュメント
- 内部API: カスタムサービスやマイクロサービス
- 社内標準: コーディング規約、アーキテクチャパターン
- プロプライエタリシステム: カスタムツール、データベース、ワークフロー
- ドメイン知識: ビジネスロジック、コンプライアンス要件
MCP で社内ドキュメントにアクセスする
- モデルは社内の慣習を推測できない
- カスタムサービスの API ドキュメントは公開されていない
- ビジネスロジックやドメイン知識は組織固有
- コンプライアンスやセキュリティ要件は会社ごとに異なる
よく使われる MCP 連携
Integration | Access | Examples |
---|---|---|
Confluence | 会社の Confluence スペース | アーキテクチャドキュメント、社内サービスの API 仕様、コーディング標準とガイドライン、プロセス文書 |
Google Drive | 共有ドキュメントとフォルダ | 仕様書、会議メモと意思決定記録、設計ドキュメントと要件、チームのナレッジベース |
Notion | ワークスペースのデータベースとページ | プロジェクトドキュメント、チーム Wiki、ナレッジベース、プロダクト要件、技術仕様 |
Custom | 社内システムとデータベース | プロプライエタリな API、レガシーなドキュメントシステム、カスタムナレッジベース、特化ツールやワークフロー |
カスタムソリューション
- 社内ウェブサイトやポータルをスクレイピングする
- プロプライエタリなデータベースに接続する
- カスタムドキュメントシステムにアクセスする
- 社内 Wiki やナレッジベースから取得する
カスタム MCP サーバーを構築したら、Cursor がドキュメントを更新できるようにツールを公開することもできる
ドキュメントを最新に保つ
既存コードから
@
この Express ルーターの API ドキュメントを生成して。すべてのエンドポイント、パラメーター、レスポンス形式を含めて
∞
Agent⌘I
Auto
チャットセッションから
複雑な問題を解決したあと:
@
認証のセットアップについての会話を、チームのwiki向けのステップバイステップガイドに要約して
∞
Agent⌘I
Auto
まとめ
- ドキュメントをコンテキストに使うと、Cursor の精度と最新性が上がる
- 公式ドキュメントには
@Docs
、コミュニティ由来の知識には@Web
を使う - MCP は Cursor と社内システムをつなぐブリッジになる
- 知識を最新に保つために、コードや会話からドキュメントを生成する
- より網羅的に理解するには、外部と内部のドキュメントソースを組み合わせる