コンテキストポータル MCP (ConPort)

（メモリバンクです！）

構造化されたプロジェクト コンテキストを管理するための、データベース バックアップのモデル コンテキスト プロトコル (MCP) サーバー。IDE やその他のインターフェース内の AI アシスタントや開発者ツールで使用されるように設計されています。

Context Portal MCP サーバー (ConPort) とは何ですか?

コンテキストポータル（ConPort）は、プロジェクトのメモリバンクです。意思決定、タスク、アーキテクチャパターンといった重要な情報を構造化された形式で保存することで、AIアシスタントが特定のソフトウェアプロジェクトをより深く理解するのに役立つツールです。AIが簡単にアクセスして活用し、より正確で役立つ回答を提供できる、プロジェクト固有の知識ベースを構築すると考えてください。

機能:

• プロジェクトの決定、進捗、システム設計を追跡します。

• カスタム プロジェクト データ (用語集や仕様など) を保存します。

• AI が関連するプロジェクト情報をすばやく見つけられるようにします (スマート検索のように)。

• AI がプロジェクト コンテキストを使用してより適切な対応を行えるようにします (RAG)。

• 単純なテキスト ファイル ベースのメモリ バンクに比べて、コンテキストの管理、検索、更新がより効率的です。

ConPortは、AIアシスタントが様々なプロジェクトコンテキストを保存、取得、管理するための堅牢で構造化された方法を提供します。プロジェクト固有のナレッジグラフを効果的に構築し、意思決定、進捗、アーキテクチャといったエンティティとそれらの関係性を捉えます。この構造化されたナレッジベースは、セマンティック検索のためのベクトル埋め込みによって強化され、**検索拡張生成（RAG）**の強力なバックエンドとして機能します。これにより、AIアシスタントは正確で最新の情報にアクセスし、よりコンテキストを考慮した正確な応答を提供できるようになります。

ConPortは、より信頼性が高くクエリ可能なデータベースバックエンド（ワークスペースごとにSQLite）を提供することで、従来のファイルベースのコンテキスト管理システムに代わるものです。ConPortは、MCPをサポートする様々なIDEやクライアントインターフェースと互換性のある、汎用的なコンテキストバックエンドとして設計されています。

主な機能は次のとおりです。

• SQLite を使用した構造化コンテキスト ストレージ (ワークスペースごとに 1 つの DB、自動的に作成)。

• Python/FastAPI で構築された MCP サーバー ( context_portal_mcp )。

• 対話用に定義された包括的な MCP ツール スイート (以下の「利用可能な ConPort ツール」を参照)。

• workspace_idによるマルチワークスペースのサポート。

• 主な展開モード: IDE との緊密な統合のための STDIO。

• コンテキスト項目間の明示的な関係を持つ動的なプロジェクト ナレッジ グラフの構築を可能にします。

• 高度な RAG を強化するためのベクター データ ストレージとセマンティック検索機能が含まれています。

• **検索拡張生成 (RAG)**の理想的なバックエンドとして機能し、AI に正確でクエリ可能なプロジェクト メモリを提供します。

• 互換性のある LLM プロバイダーによる迅速なキャッシュのために AI アシスタントが活用できる構造化されたコンテキストを提供します。

前提条件

始める前に、以下がインストールされていることを確認してください。

• **Python:**バージョン 3.8 以上を推奨します。

  • Pythonをダウンロード

  • インストール中に Python がシステムの PATH に追加されていることを確認してください (特に Windows の場合)。

• uv: (強く推奨) 高速なPython環境とパッケージマネージャー。uv uv使用すると、仮想環境の作成と依存関係のインストールが大幅に簡素化されます。

  • uvをインストールする

  • uvを使用しない場合は、標準の Python venvとpipを使用できますが、このプロジェクトではuvが推奨されます。

PyPI 経由のインストール:

MCP サーバーをインストールするディレクトリに仮想環境を作成してアクティブ化します。

uv

環境をアクティブ化します。

Linux/macOS (bash/zsh):

Windows (コマンドプロンプト):

Windows (PowerShell):

(PowerShell で実行ポリシーの問題が発生した場合は、最初にSet-ExecutionPolicy RemoteSigned -Scope CurrentUser実行する必要がある場合があります。)

標準の

MCP サーバー ディレクトリ内:

アクティベーション コマンドは上記のuvと同じです。

PyPi経由でConPortをインストールします。

uv を使用した context-portal-mcp の PyPI インストール コマンドは次のとおりです。

仮想環境内で標準の pip を使用している場合、コマンドは次のようになります。

PyPIインストールの設定

ConPortをPyPI経由でインストールした場合（ pip install context-portal-mcp ）、仮想環境内でPythonインタープリタを使ってConPortサーバーを直接起動できます。この方法は実行ファイルを明示的に指定するため、一般的に信頼性が高いです。

重要:に置き換える必要があります。

Linux/macOSの例:

Windowsの例:

• command : これは、ConPort インストールの.venv内のpython (または Windows の場合はpython.exe ) 実行可能ファイルへの絶対パスである必要があります。

• args : ConPort サーバー モジュールを実行するための引数 ( -m context_portal_mcp.main ) とサーバーの引数 ( --mode stdio --workspace_id "${workspaceFolder}" ) が含まれます。

• ${workspaceFolder} : この IDE 変数は、現在のプロジェクト ワークスペースの絶対パスを自動的に提供するために使用されます。

• --log-file : オプション：サーバーログが書き込まれるファイルへのパス。指定されていない場合、ログはstderr （コンソール）に出力されます。永続的なログ記録やサーバーの動作のデバッグに役立ちます。

• --log-level : オプション：サーバーの最小ログレベルを設定します。有効な選択肢は、 DEBUG 、 INFO 、 WARNING 、 ERROR 、 CRITICALです。デフォルトはINFOです。開発中またはトラブルシューティング時に詳細な出力が必要な場合は、 DEBUGに設定してください。

PyPI経由でインストールした場合、 conport-mcpコマンドは仮想環境のPATHに直接アクセスできます。サーバーを実行するコマンドは次のように簡略化されます。

Gitリポジトリからのインストール

以下の手順では、ConPort の Git リポジトリをクローンし、依存関係をインストールすることで、ConPort をセットアップする方法を説明します。仮想環境の使用が不可欠です。

1. **リポジトリのクローンを作成する:**ターミナルまたはコマンド プロンプトを開き、次のコマンドを実行します。

   git clone https://github.com/GreatScottyMac/context-portal.git cd context-portal

2. 仮想環境を作成してアクティブ化する:

   • uv context-portalディレクトリ内:

     uv venv

     • 環境をアクティブ化します。

       • Linux/macOS (bash/zsh):

         source .venv/bin/activate

       • Windows (コマンドプロンプト):

         .venv\Scripts\activate.bat

       • Windows (PowerShell):

         .venv\Scripts\Activate.ps1

         (PowerShell で実行ポリシーの問題が発生した場合は、最初にSet-ExecutionPolicy RemoteSigned -Scope CurrentUser実行する必要がある場合があります。)

   • 標準の context-portalディレクトリ内:

     python3 -m venv .venv # Or 'python -m venv .venv'

     • アクティベーション コマンドは上記のuvと同じです。

3. **依存関係をインストールします。**仮想環境がアクティブ化されたら、次の操作を実行します。

   • uv

     uv pip install -r requirements.txt

     注:

   • 標準の

     pip install -r requirements.txt

4. **インストールの確認 (オプション):**仮想環境がアクティブ化されていることを確認します。

   • uv

     uv run python src/context_portal_mcp/main.py --help

   • 標準の bash python src/context_portal_mcp/main.py --helpこれにより、ConPort サーバーのコマンドライン ヘルプが出力されます。

推奨構成 (直接 Python 呼び出し):

この設定はcontext-portal仮想環境からPythonインタープリタを直接呼び出します。これは、コマンドがuvであることや、クライアントがサーバープロセスのcwdフィールドをサポートしているかどうかに依存しない信頼性の高い方法です。

重要：

• プレースホルダー パスをcontext-portalリポジトリをクローンして設定した場所に対応する絶対パスに置き換える必要があります。

• --workspace_id引数の"${workspaceFolder}"変数は、現在のプロジェクト ワークスペースの絶対パスに展開される一般的な IDE プレースホルダーです。

Linux/macOSの例:

context-portalリポジトリが/home/youruser/mcp-servers/context-portalにクローンされているとします。

Windowsの例:

context-portalリポジトリがC:\Users\YourUser\MCP-servers\context-portalにクローンされているとします。JSON文字列内のパスには二重のバックスラッシュ\\が使用されていることに注意してください。

• command : これはcontext-portalインストールの.venv内にあるpython (または Windows の場合はpython.exe ) 実行可能ファイルへの絶対パスである必要があります。

• args: これはcontext-portalインストール内のmain.pyスクリプトへの絶対パスである必要があります。

• --workspace_id "${workspaceFolder}" : これは、ConPort に管理するプロジェクトのコンテキストを指示します。 ${workspaceFolder} IDE によって現在のプロジェクトのルート パスに解決される必要があります。

• --log-file : オプション：サーバーログが書き込まれるファイルへのパス。指定されていない場合、ログはstderr （コンソール）に出力されます。永続的なログ記録やサーバーの動作のデバッグに役立ちます。

• --log-level : オプション：サーバーの最小ログレベルを設定します。有効な選択肢は、 DEBUG 、 INFO 、 WARNING 、 ERROR 、 CRITICALです。デフォルトはINFOです。開発中またはトラブルシューティング時に詳細な出力が必要な場合は、 DEBUGに設定してください。

クローンされた Git リポジトリ経由でインストールされた場合、IDE は通常、次のようなコマンドを構築して実行します。

/path/to/your/context-portal/ context-portalリポジトリをクローンした場所の絶対パスです。 "/actual/path/to/your/project_workspace"は、ConPortが管理するコンテキストを持つプロジェクトのルートへの絶対パスです（例：VS Codeでは${workspaceFolder} ）。ConPortはyour_project_workspace/context_portal/context.dbにデータベースを自動的に作成します。

--workspace_id

ConPort サーバーを起動する場合、特に STDIO モード ( --mode stdio ) では、 --workspace_id引数はいくつかの重要な目的を果たします。

1. **初期サーバー コンテキスト:**サーバー プロセスに、最初に関連付けられるプロジェクト ワークスペースへの絶対パスを提供します。

2. 重要な安全性チェック: STDIO モードでは、このパスはサーバーが自身のインストールディレクトリ内にデータベースファイル ( context.db 、 conport_vector_data/ ) を誤って作成するのを防ぐための重要なチェックを実行するために使用されます。これにより、クライアントがワークスペースパスを正しく提供しないという誤った設定から保護されます。

3. **クライアント起動信号:**これは、MCP クライアント (IDE 拡張機能など) がどのプロジェクトを起動しているかをサーバーに通知する標準的な方法です。

重要事項：。ConPortツールは、各呼び出しでworkspace_idパラメータを明示的に指定するように設計されています（例： get_product_context({"workspace_id": "..."}) ）。この設計により、単一のサーバーインスタンスで複数のワークスペースを管理できるようになり、各操作の明確性が確保されます。クライアントIDE/MCPクライアントは、各ツール呼び出しで正しいworkspace_id提供する必要があります。

重要なポイント： ConPort は、ターゲットプロジェクトを識別するために、正確な--workspace_idに大きく依存しています。この引数が${workspaceFolder}などの IDE 変数を使用するか、絶対パスを直接指定することで、プロジェクトワークスペースの絶対パスに正しく解決されることを確認してください。

Pythonバイトコードキャッシュのクリア

ConPort をアップデートまたは再インストールした後、 __pycache__ディレクトリに保存されている古い Python バイトコードファイル ( .pyc ) が原因で、予期しない動作やエラーが発生することがあります。このキャッシュをクリアすると、このような問題を解決できます。

Unix 系システム (Linux、macOS、WSL) のfindコマンドを使用して、これらのファイルとディレクトリを見つけて削除できます。

1. __pycache__

   find . -type d -name "__pycache__" -exec rm -rf {} +

2. .pyc

   find . -type f -name "*.pyc" -delete

これらのコマンドを実行する場所:

これらのコマンドを実行するディレクトリは、ConPort のインストール方法によって異なります。

• **Git リポジトリからインストールした場合:**クローンされたcontext-portalリポジトリのルート ディレクトリから次のコマンドを実行します。

• PyPI 経由でインストールした場合: ConPort がインストールされている Python 環境の site-packages ディレクトリ内 (たとえば、仮想環境のlib/pythonX.Y/site-packages/ルート) からこれらのコマンドを実行します。

• **Docker イメージから実行する場合:**通常、 docker exec <container_id> <command>を使用して、実行中の Docker コンテナー内でこれらのコマンドを実行します。

LLM エージェントでの使用 (カスタム手順)

ConPort と LLM エージェントの連携は、LLM に特定のカスタム指示やシステムプロンプトを提供することで大幅に強化されます。このリポジトリには、さまざまな環境に合わせてカスタマイズされた戦略ファイルが含まれています。

• Roo Codeの場合:

  • roo_code_conport_strategy : Roo Code VS Code 拡張機能内で動作する LLM 向けの詳細な手順が含まれており、コンテキスト管理に ConPort ツールを使用する方法をガイドします。

• CLineの場合:

  • cline_conport_strategy : Cline VS Code 拡張機能内で動作する LLM の詳細な手順が含まれており、コンテキスト管理に ConPort ツールを使用する方法をガイドします。

• ウィンドサーフィンカスケードの場合:

  • cascade_conport_strategy : Windsurf Cascade環境に統合されたLLM向けの具体的なガイダンス。重要：Cascadeでセッションを開始する際は、LLMに以下の内容を明示的に伝える必要があります。

  Initialize according to custom instructions

• 一般/プラットフォームに依存しない用途:

  • generic_conport_strategy : MCP対応LLM向けに、プラットフォームに依存しない命令セットを提供します。ConPortのget_conport_schemaオペレーションを用いて、ConPortツールの正確な名前とそのパラメータを動的に検出することに重点を置き、特定のツール呼び出しの詳細をハードコーディングするのではなく、概念的なインタラクション（意思決定のログ記録や製品コンテキストの更新など）をいつ、なぜ実行するかをLLMに指示します。

これらの戦略ファイルの使用方法:

1. LLM エージェントの環境に関連する戦略ファイルを特定します。

2. そのファイルの内容全体をコピーします。

3. LLMのカスタム指示またはシステムプロンプト領域に貼り付けます。方法はLLMプラットフォーム（IDE拡張機能設定、Web UI、API設定）によって異なります。

これらの手順により、LLM は次の知識を身に付けます。

• ConPort からコンテキストを初期化してロードします。

• 新しい情報（決定、進捗状況など）で ConPort を更新します。

• カスタム データとリレーションシップを管理します。

• workspace_idの重要性を理解してください。セッション開始に関する重要なヒント： LLMエージェントがコンテキストを正しく初期化してロードできるようにするには、特に最初のメッセージでカスタム指示に厳密に従わないインターフェースの場合、「 Initialize according to custom instructions.これにより、エージェントは戦略ファイルで定義されたConPort初期化シーケンスを実行するようになります。

ワークスペースでの ConPort の初期使用

新規または既存のプロジェクトワークスペースでConPortを初めて使用する場合、ConPortデータベース（ context_portal/context.db ）が存在しない場合は、サーバーによって自動的に作成されます。初期のプロジェクトコンテキスト、特に製品コンテキストをブートストラップするには、以下の点を考慮してください。

projectBrief.mdファイルの使用（推奨）

1. **projectBrief.mdを作成します。**プロジェクト ワークスペースのルート ディレクトリに、 projectBrief.mdという名前のファイルを作成します。

2. **コンテンツの追加:**このファイルにプロジェクトの概要を入力します。これには以下のような内容が含まれます。

   • プロジェクトの主な目標または目的。

   • 主な機能またはコンポーネント。

   • 対象となる視聴者またはユーザー。

   • 全体的なアーキテクチャスタイルまたは主要なテクノロジー（わかっている場合）。

   • プロジェクトを定義するその他の基礎情報。

3. **インポートの自動プロンプト:**提供されている ConPort カスタム命令セット ( roo_code_conport_strategyなど) のいずれかを使用する LLM エージェントがワークスペースで初期化されるときは、次の操作を行うように設計されています。

   • projectBrief.mdの存在を確認します。

   • 見つかった場合は、ファイルを読み取り、その内容を ConPort製品コンテキストにインポートするかどうかを尋ねます。

   • 同意すると、コンテンツが ConPort に追加され、プロジェクトの製品コンテキストのベースラインがすぐに提供されます。

手動初期化

projectBrief.mdが見つからない場合、またはインポートしないことを選択した場合:

• LLM エージェントは、通常、カスタム指示に従って、ConPort 製品コンテキストが初期化されていないことを通知します。

• ワークスペース内の他のファイルを一覧表示して関連情報を収集するなど、製品コンテキストを手動で定義するのに役立つ場合があります。

projectBrief.mdまたは手動入力を通じて初期コンテキストを提供することで、ConPort と接続された LLM エージェントは最初からプロジェクトの基礎をより深く理解できるようになります。

利用可能なConPortツール

ConPortサーバーは、MCPを介して以下のツールを公開し、基盤となるプロジェクトナレッジグラフとのインタラクションを可能にします。これには**、ベクターデータストレージを活用したセマンティック検索ツールが含まれます。これらのツールは、AIエージェントによる拡張生成（RAG）に不可欠な検索**機能を促進します。すべてのツールには、対象のプロジェクトワークスペースを指定するためのworkspace_id引数（文字列、必須）が必要です。

• 製品コンテキスト管理:

  • get_product_context : プロジェクトの全体的な目標、機能、アーキテクチャを取得します。

  • update_product_context : 製品コンテキストを更新します。完全なcontent （オブジェクト）または部分的な更新の場合はpatch_content （オブジェクト）を受け入れます（キーを削除するには、パッチの値として__DELETE__を使用します）。

• アクティブコンテキスト管理:

  • get_active_context : 現在の作業フォーカス、最近の変更、および未解決の問題を取得します。

  • update_active_context : アクティブコンテキストを更新します。完全なcontent （オブジェクト）または部分的な更新の場合はpatch_content （オブジェクト）を受け入れます（キーを削除するには、パッチの値として__DELETE__を使用します）。

• 意思決定のログ記録:

  • log_decision : アーキテクチャまたは実装の決定を記録します。

    • 引数: summary (str, req)、 rationale (str, opt)、 implementation_details (str, opt)、 tags (list[str], opt)。

  • get_decisions : ログに記録された決定を取得します。

    • 引数: limit (int, opt)、 tags_filter_include_all (list[str], opt)、 tags_filter_include_any (list[str], opt)。

  • search_decisions_fts : 決定フィールド (概要、根拠、詳細、タグ) 全体のフルテキスト検索。

    • 引数: query_term (str, req)、 limit (int, opt)。

  • delete_decision_by_id : ID によって決定を削除します。

    • 引数: decision_id (int, req)。

• 進捗状況の追跡:

  • log_progress : 進行状況エントリまたはタスクのステータスを記録します。

    • 引数: status (str, req)、 description (str, req)、 parent_id (int, opt)、 linked_item_type (str, opt)、 linked_item_id (str, opt)。

  • get_progress : 進捗エントリを取得します。

    • 引数: status_filter (str, opt)、 parent_id_filter (int, opt)、 limit (int, opt)。

  • update_progress : 既存の進捗エントリを更新します。

    • 引数: progress_id (int, req)、 status (str, opt)、 description (str, opt)、 parent_id (int, opt)。

  • delete_progress_by_id : ID によって進捗エントリを削除します。

    • 引数: progress_id (int, req)。

• システムパターン管理:

  • log_system_pattern : システム/コーディングパターンをログに記録または更新します。

    • 引数: name (str, req)、 description (str, opt)、 tags (list[str], opt)。

  • get_system_patterns : システムパターンを取得します。

    • 引数: tags_filter_include_all (list[str], opt)、 tags_filter_include_any (list[str], opt)。

  • delete_system_pattern_by_id : ID によってシステム パターンを削除します。

    • 引数: pattern_id (int, req)。

• カスタムデータ管理:

  • log_custom_data : カテゴリ内のカスタムキーと値のエントリを保存/更新します。値はJSON形式でシリアル化可能です。

    • 引数: category (str, req)、 key (str, req)、 value (any, req)。

  • get_custom_data : カスタムデータを取得します。

    • 引数: category (str, opt)、 key (str, opt)。

  • delete_custom_data : 特定のカスタム データ エントリを削除します。

    • 引数: category (str, req)、 key (str, req)。

  • search_project_glossary_fts : 「ProjectGlossary」カスタム データ カテゴリ内での全文検索。

    • 引数: query_term (str, req)、 limit (int, opt)。

  • search_custom_data_value_fts : すべてのカスタム データ値、カテゴリ、およびキーにわたるフルテキスト検索。

    • 引数: query_term (str, req)、 category_filter (str, opt)、 limit (int, opt)。

• コンテキストリンク:

  • link_conport_items : 2 つの ConPort アイテム間の関係リンクを作成し、プロジェクト ナレッジ グラフを明示的に構築します。

    • 引数: source_item_type (str, req)、 source_item_id (str, req)、 target_item_type (str, req)、 target_item_id (str, req)、 relationship_type (str, req)、 description (str, opt)。

  • get_linked_items : 特定のアイテムにリンクされたアイテムを取得します。

    • 引数: item_type (str, req)、 item_id (str, req)、 relationship_type_filter (str, opt)、 linked_item_type_filter (str, opt)、 limit (int, opt)。

• 履歴とメタツール:

  • get_item_history : 製品またはアクティブコンテキストのバージョン履歴を取得します。

    • 引数: item_type ("product_context" | "active_context", req)、 version (int, opt)、 before_timestamp (datetime, opt)、 after_timestamp (datetime, opt)、 limit (int, opt)。

  • get_recent_activity_summary : 最近の ConPort アクティビティの概要を提供します。

    • 引数: hours_ago (int, opt)、 since_timestamp (datetime, opt)、 limit_per_type (int, opt、デフォルト: 5)。

  • get_conport_schema : 利用可能な ConPort ツールとその引数のスキーマを取得します。

• インポート/エクスポート:

  • export_conport_to_markdown : ConPort データを markdown ファイルにエクスポートします。

    • 引数: output_path (str、opt、デフォルト: "./conport_export/")。

  • import_markdown_to_conport : Markdown ファイルから ConPort にデータをインポートします。

    • 引数: input_path (str、opt、デフォルト: "./conport_export/")。

• バッチ操作:

  • batch_log_items : 1 回の呼び出しで同じタイプの複数の項目 (決定、進行状況エントリなど) を記録します。

    • 引数: item_type (str, req - 例: "decision"、"progress_entry")、 items (list[dict]、req - アイテム タイプの Pydantic モデル辞書のリスト)。

プロンプトキャッシュ戦略

ConPortは、AIアシスタントが互換性のあるLLMプロバイダー（Google Gemini、Anthropic Claude、OpenAIなど）とのプロンプトキャッシュに活用できる構造化コンテキスト（セマンティック検索用ベクターデータを含む）を提供するために使用できます。プロンプトキャッシュは、プロンプトの頻繁に使用される部分を再利用することで、トークンコストとレイテンシを削減します。

このリポジトリには、LLM アシスタントが ConPort からキャッシュ可能なコンテンツを識別し、さまざまなプロバイダーのプロンプトを構成する方法を定義する詳細な戦略ファイル ( context_portal/prompt_caching_strategy.yml ) が含まれています。

戦略の主な側面は次のとおりです。

• **キャッシュ可能なコンテンツの識別:**製品コンテキスト、詳細なシステム パターン、特定のカスタム データ エントリ (特に、 cache_hint: trueメタデータでフラグが付けられたエントリ) などの大規模で安定したコンテキストを優先します。

• プロバイダー固有の相互作用:

  • **暗黙的なキャッシュ（Gemini、OpenAI）：**プロンプトの先頭にキャッシュ可能なConPortコンテンツを配置することで、プロンプトの構造化を行います。LLMプロバイダが自動的にキャッシュを処理します。

  • **明示的なキャッシュ (Anthropic):**プロンプト ペイロード内のキャッシュ可能な ConPort コンテンツの後にcache_controlブレークポイントを挿入します。

• ユーザーヒント: ConPort のカスタム データにcache_hint: trueなどのメタデータを含めることができ、キャッシュのコンテンツの優先順位付けについて LLM アシスタントに明示的に指示します。

• LLM アシスタント通知: LLM アシスタントは、潜在的なキャッシュのプロンプトを構成するときにユーザーに通知するように指示されます (例: [INFO: Structuring prompt for caching] )。

ConPort を使用してプロジェクトの知識を管理し、LLM アシスタントにこの迅速なキャッシュ戦略を提供することで、AI インタラクションの効率とコスト効率を高めることができます。

さらに読む

ConPort の設計、アーキテクチャ、高度な使用パターンの詳細については、以下を参照してください。

• conport_mcp_deep_dive.md

貢献

ConPort プロジェクトへの貢献に関する詳細は、今後ここに追加される予定です。

ライセンス

このプロジェクトは、Apache-2.0 ライセンスに基づいてライセンスされます。