Monte Carlo Simulation Forecasting Mcp について
MCS-MCPは、Jiraプロジェクトの履歴を交付分析と確率予測に変換し、チームのフローやプロセスの安定性を評価します。実績データによるモンテカルロ予測に加え、バックテスト、診断、インタラクティブなチャートを備えています。
主な機能
- 01モンテカルロによる納期予測
- 02履歴データによるバックテスト
- 03XmR管理図による安定性分析
- 04ワークフロー状態の特定
- 05インタラクティブなチャート表示
- 06過去時点での分析
活用シーン
- 01複数の作業項目の完了時期を予測
- 02予測を過去の実績と照合
- 03ボトルネックや滞留作業を特定
- 04プロセス変更の前後を比較
MCP 対応
このMCPサーバーはJiraボードから作業項目の遷移履歴を読み取り、AIエージェントに予測とデリバリー分析のツールを提供します。READMEによると、タイトル、説明、担当者を破棄し、分析に必要なメタデータのみを保持します。
設定
ローカルサーバーの設定はどのクライアントでも共通です。コピーしてクライアントの MCP 設定ファイルに貼り付けてください。
このサーバーのパッケージやリモートエンドポイントはまだ取得できていません。プロジェクトの README の手順に従ってください。
ツール
ローカルサーバーのツールはマシン上で起動して初めて取得できます。メンテナーはまだツール一覧を提供していません。
詳細
MCS-MCP:Model Context Protocol 向けモンテカルロシミュレーション
MCS-MCP は、Claude などの AI アシスタントを Jira プロジェクトの履歴に接続し、自然言語によるデリバリー分析と確率的予測を可能にする Model Context Protocol(MCP)サーバーです。「この 20 件はいつ完了しますか?」「プロセスの予測可能性は高まっていますか?」「作業項目が滞留しているのはどこですか?」といった質問をすると、推定や勘ではなく、チームの実際の過去の実績に基づいた回答が得られます。
🚀 主な機能
- インタラクティブなチャート描画:すべての分析ツールでインタラクティブなチャートを描画できます。チャートは localhost HTTP 経由で MCP サーバーから直接配信されます。外部依存関係を必要としない、自己完結型の React/Recharts ページです。デフォルトで有効です(
MCS_CHARTS_BUFFER_SIZE=20。無効にするには0を設定してください)。各ツールの応答には、任意のブラウザーで開けるchart_urlが含まれます。 - モンテカルロ予測:「いつ完了しますか?」(期間)や「どれだけ対応できますか?」(スコープ)に答えるため、10,000 回以上のシミュレーションを実行します。推定ではなく、チームの実際の過去のスループットを使用します。
- 予測のバックテスト:過去のデータに予測を照らし合わせて再生し、予測がどの程度正確だったかを実証的に検証します(ウォークフォワード分析)。
- 予測可能性のガードレール:XmR 管理図を使用して「特殊原因」による変動を検出し、サイクルタイム、WIP 集団、デリバリー頻度のプロセス安定性を評価します。
- SLE 遵守状況のトレンド分析:週ごとのサービスレベル期待値(SLE)の達成状況と、違反の深刻度(最大サイクルタイム+違反超過分の P95)を追跡します。デフォルトではローリングウィンドウの P85 SLE を使用します。安定した Vacanti 方式のベースラインに固定するには、
sle_duration_daysを明示的に渡してください。 - ワークフローの意味的な検出:各ワークフローのステータスの目的(作業中、待機キュー、エントリーファネル、終端の退出)を自動的に推定し、事務的なオーバーヘッドではなく、実際のボトルネックを特定します。
- プロセスの歩留まりと作業の放棄:作業がどこで破棄されるのかを正確に特定し、作業の種類とワークフローの段階ごとに分類して、無駄を定量化します。
- 高精度な滞留期間分析:各ステータスの現在の WIP 滞留期間を過去の標準と比較し、「放置された」作業項目を特定します。
- 層別分析:作業項目の種類による層別化を、分析スイート全体で徹底しています。シミュレーション、スループット、サイクルタイム、安定性について、バグとストーリーを分けて分析し、キャパシティの競合(「バグ税」)を明らかにします。
- サンプルパス分析(滞在時間):有限の Little の法則の恒等式 L(T) = Λ(T) · w(T) を計算し、サイクルタイム、WIP 滞留期間、フロー負債を、整合性のある単一の見方にまとめます。フローの不均衡を検出するため、w'(T)(退出数を分母とする滞在時間)と Θ(T)(退出率)も含まれます。滞在時間と通過時間の整合性の差から、稼働中の作業項目がシステムに及ぼす「終端効果」が明らかになります。
- 戦略的な変化の追跡:週次/月次の 3 元管理図を用いた経時的な監査により、長期にわたる体系的な改善やプロセスの変化を検出します。
- 過去の時点の再現:過去の特定の日付を分析の基準点として設定し、その時点でのプロセスの状態を再現できます。ふりかえり、事後分析、またはプロセス変更の前後比較に役立ちます。
- セッション分析ウィンドウ:すべての診断で、単一の
[start, end]範囲を使用します。set_analysis_windowで一度設定すると(例:{end_date, duration_days}または 2 つの明示的な日付)、以降のすべての分析(スループット、サイクルタイム、フロー負債、WIP、歩留まり、滞在時間など)が同じウィンドウを使用します。「1 か月戻る」操作は、10 回ではなく 1 回の呼び出しで済みます。予測ツールはエンジンによって決まる独自のサンプルウィンドウを使用するため、予測精度は診断対象の期間に左右されません。 - 分析ロードマップのガイド:サーバーは、目標(予測、ボトルネック分析、キャパシティ計画)に応じた適切な診断手順を先回りして提案し、AI エージェントが適切な手順を推測する必要がないようにします。
🧱 制限事項と前提条件
- サーバーは Jira のワークフロー関連 REST API を使用しません。実際の課題遷移からワークフローを推測します。これは、ボード上のすべての作業項目タイプで同じワークフローを共有している、つまり正確に言えば、同じ順序で同じステータスを共有しているという前提が成り立つ場合、非常に信頼性の高い方法です。この前提が成り立たない場合、ワークフローの検出結果は予測不可能になり、分析/診断や予測機能が混乱する可能性があります。異なるワークフローをまたいだフローの分析は無意味に思えるため、こうしたケースに今後対応するかどうかはわかりません(間違っていると証明していただけるなら歓迎します)。
- 同じ理由から、サーバーは現在ボードを対象として動作し、JQL を渡すことはできません。簡単な回避策は明らかです。クエリをボードの JQL として使用するボードを作成してください。実行する内容には十分注意してください。
🛡️ データセキュリティと GRC の原則
Atlassian Jira のような作業管理システムには、機密性の高いプロジェクトデータや個人データが含まれていることがよくあります。MCS-MCP は セキュリティ・バイ・デザイン のアプローチで構築されており、次の 2 つの基本的な統制原則に基づいて動作します。
1. 「知る必要がある人だけが知る」原則(データの最小化)
知的財産とプライバシーを保護するため、サーバーが取り込み、保持するデータは厳密に最小限に抑えられています。
- 取り込み、保持するデータ:分析メタデータのみです。高精度なフロー分析に必要な最小限のデータとして、課題キー、課題タイプ、ステータス遷移、タイムスタンプ、および 解決名 を扱います。
- 破棄するデータ:Jira API が包括的な課題オブジェクトを返す場合でも、システムは タイトル、説明、受け入れ条件、担当者 などの機密情報を 直ちに破棄 するよう設計されています。
そのため、サーバーのキャッシュが侵害されたとしても、プロジェクトの機密情報や個人を特定できる情報(PII)が漏えいするような、人が読めるコンテンツは含まれません。さらに、このデータは分析エンジンによって処理されたり、メモリに保存されたりすることがないため、やり取りの際に機密情報が AI エージェントに漏えいする 可能性はありません。
2. 透明性の原則(監査可能性)
私たちは「ブラックボックスを作らない」ことを重視しています。サーバーは初回の取り込み後、主にローカルキャッシュを使用して動作します。
- 人が読めるキャッシュ:永続化されるデータ(イベントログ、ワークフローマッピング)はすべて、データディレクトリ内に標準的な人が読める形式(JSON および JSON-Lines)で保存されます。
- 検証可能なロジック:これらのファイルをいつでも確認または監視して、機密データがサーバーの長期メモリに漏えいしていないことを検証できます。
🛠️ 仕組み(概要)
-
取り込み:サーバーはプロジェクト内のボードから Jira アイテムを取得し、トランジションログからイベントソーシングによる完全な履歴を再構成します。
-
ワークフローのマッピング:Jira のワークフローはそれぞれ異なります。分析を始める前に、サーバーは各ステータスの 目的 を理解する必要があります。サーバーは、4 段階のメタワークフローへのマッピングを提案します。
- 需要:入口となるファネルです。まだ着手が確定していないアイデアやバックログ項目が含まれます。
- 上流:分析と詳細化の段階です。取り上げられているものの、まだデリバリーへの着手が確定していない作業が含まれます。
- 下流:実行中の段階です。コーディング、テスト、レビューが含まれます。ここが「コミットメントゾーン」です。
- 完了:終端状態です。完了、キャンセル、破棄が含まれます。
このマッピングに加え、「完了」の意味(デリバリー済みか、放棄済みか)と、コミットメントポイント(作業が正式に開始されるステータス。サイクルタイムと WIP の定義に使われます)がどこにあるかを自動的に提案し、あなたが確認します。この設定はキャッシュされるため、ボードごとに一度設定すれば十分です。
-
分析期間の設定:診断には、対象となる履歴の範囲、つまり期間が必要です。すべての診断(スループット、サイクルタイム、フローデット、WIP の安定性、歩留まり、滞留時間、ステータスの持続性、プロセスの安定性、作業項目の経過時間(終了時点のスナップショット)、プロセスの進化(終了時点を基準とする長期分析))で共有するセッションごとに 1 つの期間を設定します。期間のデフォルトは今日を終了日とする直近 26 週間です。AI は
set_analysis_windowを呼び出して変更します({end_date, duration_days}または明示的な 2 つの日付)。「1 か月戻す」は 10 回ではなく 1 回の呼び出しで済みます。予測(forecast_monte_carlo、forecast_backtest)は意図的に対象外です。予測精度を高めるため、これらのサンプル期間は診断の対象期間とは独立して、シミュレーションエンジンによって選択されます。 -
診断と予測:データ、各ステータスの 意味 に関する明確な理解、そして選択した期間があれば、デリバリーシステムの健全性、予測可能性、将来のスループットについて、AI に幅広い質問をすることができます。
🏃 はじめに
前提条件
- Atlassian Jira(Data Center または Cloud)へのアクセス
- チャットに使う MCP 対応 AI エージェント(私は Claude Desktop を使っています)
- 自分でビルドする場合は最近のバージョンの Go が必要です。リリースをダウンロードする場合は不要です
インストール
- ソースからビルドする(ソースからのビルドを参照)か、リリースをダウンロードします。
mcs-mcp.exe(またはmcs-mcp)を任意の場所にコピーします(ビルドする場合はdist/を確認してください)。- 一度実行します。データフォルダーにコメント付きの
.envが作成されます。デフォルトでは、お使いのプラットフォームの標準的なユーザーごとの場所(Windows では%AppData%\mcs-mcp、macOS では~/Library/Application Support/mcs-mcp、Linux では~/.config/mcs-mcp)です。設定の参照元を参照してください。すべての設定項目とデフォルト値があらかじめ記入されています。このファイルを編集してください。最低限、Jira インスタンスと認証方法に関する情報が必要です(認証を参照)。編集内容が上書きされることはありません。 - データを別の場所に保存するには、
--data-path /path/to/writable/dirを指定して起動します(またはDATA_PATH環境変数を設定します)。データ(.envを含む)はその場所に保存されます。 - AI エージェントを MCP ツールとして使用するように設定します(エージェントの設定を参照)。通常、変更を反映するにはエージェントを再起動する必要があります。
- チャットします。
- 確認したいプロジェクトとボードを AI エージェントに伝えます。
- ワークフローを検出するようエージェントに指示します。提案内容が実際のプロセスと一致しているか、慎重に確認してください。ティア(Demand、Upstream、Downstream、Finished)、どの解決状況または終了ステータスを delivered と abandoned と見なすか(スループットの計算に影響します)、コミットメントポイント(作業が正式に開始されるステータス。サイクルタイムと WIP の定義に影響します)、そしてもちろんワークフローステータスの順序を確認してください。これらの選択内容はキャッシュされるため、一度確認すれば以降は不要です(
cacheフォルダーを空にしない限り)。 - ツールの目標指向の実行順序を確認するには、診断ロードマップをエージェントに尋ねます(例:「15 件の項目を予測したい」、「何が遅延の原因になっているのか把握したい」)。
- 過去の特定時点におけるシステムを分析したい場合(例:振り返りや事後分析)、必要に応じてエージェントに評価日の設定を依頼します。
認証
サーバーは3種類の認証方法に対応しています。.env ファイル、またはエージェントの env ブロックで設定します。
JIRA_TOKEN_TYPE は自動判定されるため、通常は設定する必要はありません。JIRA_USER_EMAIL が設定されている場合、サーバーは api(Jira Cloud、Basic 認証)を使用し、それ以外の場合は pat(Data Center、Bearer)を使用します。これを上書きする場合にのみ、明示的に設定してください。起動時、サーバーは選択したモード(mode=basic|bearer|cookie|none)をログに記録します。認証に失敗した場合は、まずこの行を確認してください。
該当しない変数は、空欄またはコメントアウトのままにできます。空の値は未設定として扱われます。
オプション A:Jira Datacenter 用パーソナルアクセストークン(PAT)
JIRA_TOKEN=your-personal-access-token
オプション B:Jira Cloud 用 API トークン
JIRA_TOKEN=your-api-token
JIRA_USER_EMAIL=your-jira-account-email
オプション C:セッション Cookie(フォールバック)
どちらも利用できない場合は、アクティブなブラウザーセッションから取得したセッション Cookie を指定します。
JIRA_SESSION_ID=jira-session-ID
JIRA_XSRF_TOKEN=XSRF-token
JIRA_REMEMBERME_COOKIE=Jira-RememberMe-cookie
JIRA_GCILB=optional-google-cloud-load-balancer-cookie-GCILB
JIRA_GCLB=optional-google-cloud-load-balancer-cookie-GCLB
Cookie はトークンが設定されていない場合にのみ参照されます。両方が設定されている場合はトークンが優先され、その旨がサーバーのログに記録されます。
Cookie には、a)期限切れになることがあり、b)Atlassian がこの方法でのセッション Cookie の使用を防ぐ措置を講じる可能性がある点に注意してください。
ソースからのビルド
ソースをダウンロードするか、リポジトリをクローンします。
Windows(PowerShell)の場合:
.\build.ps1 build
Unix/Linux/MacOS(Make)の場合:
未テストですが、動作するはずです。
make build
生成されたバイナリは、サンプルの .env ファイルとともに dist/ フォルダーに配置されます。このサンプルは internal/config/template.go から生成されます。レジストリーを編集する場合は、テストによって同期される conf/.env-example ではなく、こちらを編集してください。
エージェントの設定
Claude や Gemini などの AI エージェント用サーバーとして使用するには、MCP クライアントの設定でコンパイル済みバイナリを指定します。
{
"mcpServers": {
"mcs-mcp": {
"command": "/path/to/mcs-mcp/mcs-mcp.exe",
"args": []
}
}
}
デフォルトでは、サーバーはプラットフォームごとのユーザー領域に cache、logs、.env を保存します(設定の読み込み元を参照)。別の場所に保存するには、--data-path を指定します。
{
"mcpServers": {
"mcs-mcp": {
"command": "/path/to/mcs-mcp/mcs-mcp.exe",
"args": ["--data-path", "/path/to/writable/folder"],
"env": {
"JIRA_URL": "https://your-domain.atlassian.net",
"JIRA_TOKEN": "your-token",
"JIRA_USER_EMAIL": "your-jira-account-email"
}
}
}
}
env ブロック内の設定は .env ファイルより優先されます(設定の読み込み元を参照)。そのため、認証情報はここに設定し、残りの設定はファイルに任せることができます。
設定の読み込み元
設定は、優先度の高い順に次のように解決されます。
- プロセス環境変数 — MCP クライアントが
envブロックで渡す値 - データフォルダー内の
.env— 初回実行時に作成されるファイル。編集するのはこちらです - バイナリと同じ場所にある
.env— 後方互換性のためにサポートされています - 作業ディレクトリ内の
.env— 開発用です - 組み込みのデフォルト値 — 生成される
.envに表示されます
起動時にサーバーは、各設定値の読み込み元(flag、env、dotenv、default、inferred)を記録したログを1行ずつ出力します。これにより、想定と異なる値が設定されていても、推測に頼らず原因を特定できます。シークレットは値ではなく、設定されているかどうかのみがログに記録されます。
データフォルダーだけは例外です。 .env を探す前に場所を把握する必要があるため、--data-path フラグまたは DATA_PATH 環境変数のみから、この順に読み取られます。どちらも設定されていない場合は、プラットフォームごとの標準のユーザー領域(%AppData%\mcs-mcp、~/Library/Application Support/mcs-mcp、~/.config/mcs-mcp)、バイナリのディレクトリ、システムの一時フォルダー、最後に作業ディレクトリの順に使用されます。
.env ファイル内で DATA_PATH を設定しても効果はありません。サーバーは見つけた場合に警告を出します。
0.21以前のバージョンからアップグレードしますか? デフォルトのデータフォルダーが移動しました。以前のバージョンでは、
cache、logs、.envはバイナリと同じ場所に保存されていましたが、現在は上記のユーザー領域がデフォルトです。--data-pathまたはDATA_PATHを設定したことがない場合、サーバーは空のキャッシュで起動し、Jira からデータを再取り込みします。データは削除されません。履歴を引き継ぐには、--data-pathに以前のフォルダーを指定するか、その中身を新しいフォルダーに移動してください。
.env内でDATA_PATHを設定している場合は、--data-pathまたは実際の環境変数に移してください。.env内では、これまで一度も有効になったことがありません。サーバーはこのケースを検出し、ログで明示的に通知します。
オプション設定
以下のオプション変数は、.env ファイルで設定できます。
| 変数 | デフォルト | 説明 |
|---|---|---|
JIRA_TOKEN_TYPE | (推定) | api または pat。未設定の場合は JIRA_USER_EMAIL から推定されます。 |
JIRA_DEPLOYMENT | (検出) | cloud または datacenter。サーバーから検出されます。検出に失敗した場合のみ設定してください。 |
VERBOSE | false | 詳細なデバッグ情報をログファイルに書き込みます。 |
COMMITMENT_POINT_BACKFLOW_RESET_CLOCK | true | コミットメントポイントを越えて後戻りした場合に、サイクルタイムとWIP経過時間の時計をリセットします。 |
JIRA_REQUEST_DELAY_SECONDS | 10 | Jira REST APIへのリクエスト間に適用される遅延時間(秒)。 |
MCS_CHARTS_BUFFER_SIZE | 20 | チャート描画バッファー(0=オフ、1-100=オン)。localhostでHTTPサーバーを起動します。 |
MCS_ENGINE | crude | シミュレーションエンジン:crude、bbak(レジーム対応)、または auto(バックテスト駆動)。 |
MCS_ENGINE_CRUDE | 50 | crudeエンジンの重み(0=無効)。autoモードで同点を解消します。 |
MCS_ENGINE_BBAK | 50 | bbakエンジンの重み(0=無効)。autoモードで同点を解消します。 |
INGESTION_UPDATED_LOOKBACK | 24 | 初回のJiraハイドレーションJQLにおける updated >= 条件の遡及期間(月)。 |
INGESTION_CREATED_LOOKBACK | 36 | created >= 条件の遡及期間(月)。最近更新されていない長期継続アイテムも取得します。 |
INGESTION_MAX_ITEMS | 5000 | 初回ハイドレーションのページ上限。前方への追跡取得(import_history_update)には上限がありません。 |
DATA_PATH は .env で設定しても効果がないため、ここには記載していません。--data-path または環境変数を使用してください。
コマンドラインフラグ
| フラグ | 説明 |
|---|---|
--data-path | cache、logs、.env のベースディレクトリ。DATA_PATH を上書きします。 |
📊 チャート描画
MCS-MCPは、インタラクティブなチャートをサーバー側で描画します。MCS_CHARTS_BUFFER_SIZE に1~100の値を設定すると、サーバーはランダムなlocalhostポート(3000-4000)でHTTPリスナーを起動します。
このリリースでの変更点: チャートはデフォルトで有効になりました(
MCS_CHARTS_BUFFER_SIZE=20)。以前の組み込みデフォルトは0でしたが、同梱の.env-exampleで20が設定されていたため、チャートが有効になっていました。この変数を設定せず、ローカルリスナーも不要な場合は、明示的にMCS_CHARTS_BUFFER_SIZE=0を設定してください。各分析ツールのレスポンスには、contextフィールドにchart_urlが含まれます。このURLをブラウザーで開くと、ツールのデータを使った自己完結型のReact/Rechartsチャートが描画されます。
サーバーは直近N件のツール結果(MRU)をバッファーに保存します。バッファーがいっぱいになると、古い項目は削除されます。チャートはURLにアクセスされたときにオンデマンドで描画されます。
AI エージェントからのチャート URL の表示
サーバーは open_in_browser ツールを公開しており、AI エージェントはこのツールを呼び出して、chart_url をシステムの既定のブラウザーで直接開けます。ブラウザー拡張機能や手動でのコピー&ペーストは不要です。分析ツールの実行後、エージェントはすぐに open_in_browser を呼び出してチャートを表示できます。
何らかの理由でエージェントが open_in_browser を呼び出さない場合でも、ツールの応答から chart_url をコピーして、任意のブラウザーに手動で貼り付ければ表示できます。チャートは完全に自己完結しているため、最初の読み込み以降はアクティブなサーバー接続を必要としません。
以前のバージョンをお使いの方への注意: 以前の Skills ベースのチャート描画機能(
docs/skills/、inject.py)は削除されました。チャートは現在、すべてサーバー側で描画されます。Claude Desktop にmcs-mcp.skillファイルをインストールしている場合は、競合を避けるため、アンインストールするか無効にしてください。
👉 使用上のヒント
- セッションの開始時に、エージェントに診断ロードマップを尋ねてください。目標に沿ったツールの実行順序が提示されるため、次に何を実行するか推測せずに、分析の道筋を明確にできます。
- チームの再編やワークフローの全面的な見直しなど、プロセスに大きな変更があった後は、エージェントにワークフローの検出を強制更新付きで再実行するよう伝え、現在のパターンに基づいてセマンティックマッピングを再評価してください。
- サーバーはすべてのイベント履歴をローカルにキャッシュします。最初の取り込み後は、ほとんどのクエリを完全にオフラインで実行できます。Jira への接続は不要です。
🧪 シミュレーションエンジン
予測では選択可能なシミュレーションエンジンを使用します。エンジンは MCS_ENGINE で設定します。
| 値 | 動作 |
|---|---|
crude(デフォルト) | 経験的なスループットヒストグラムに基づくベースラインのモンテカルロ法です。 |
bbak | レジームを考慮したサンプリングです。最近のプロセスレジームをより重視します。 |
auto | 両方を履歴データでバックテストし、より高い精度を記録した方を使用します。 |
新しい予測手法は追加のエンジン値として提供され、実績が確認されるまではオプトイン方式です。そのため、デフォルトの動作が予告なく変更されることはありません。以前のゲートベースのシステム(MCS_ALLOW_EXPERIMENTAL と set_experimental ツール)は削除されました。以前これを使用していた場合は、代わりに MCS_ENGINE=bbak を使用してください。
エンジンの選択とバックテストの仕組みについては、アーキテクチャ:マルチエンジンフレームワーク のセクション 4.6~4.8 を参照してください。
🎲 オフラインテストとシミュレーション(mockgen)
Jira へのライブ接続がない場合や、機密性の高い企業データを使わずにサーバーの分析機能をテストしたい場合に備えて、MCS-MCP には mockgen という組み込みのモックデータジェネレーターが含まれています。
このツールは標準化されたシミュレーションデータセットを生成します。プロジェクトキーとボード名に MCSTEST を指定して分析できます。MCP-Server は、cache/ ディレクトリにあることを前提とする MCSTEST_0.jsonl および MCSTEST_0_workflow.json ファイルに基づいて動作します。
mockgen の使用方法、データ分布(mild、chaotic、drifted)の設定方法、キャッシュされたシミュレーションの再構築方法について詳しくは、モックデータジェネレーターガイド を確認してください。
⚠️ 確率的性質と免責事項
MCS-MCP は統計ツールです。過去の実績に基づいて確率的な予測を生成しますが、結果を保証するものではありません。
- 確定的な回答ではありません:「10 月 12 日までに完了する確率は 85%」という予測は、それより時間がかかる確率が 15%あることを意味します。
- 入力の品質が結果を左右します:結果は、Jira データの品質と一貫性に完全に依存します。
- 責任の免除:このツールは「現状有姿」で提供されます。著者および貢献者は、ツールの出力に基づくプロジェクトの遅延、金銭的損失、業務上の意思決定について責任を負いません。
📖 ガイド付きインタラクション
MCS-MCP は、AI エージェントが「テクニカルコパイロット」として使用することを想定して設計されています。特定のワークフローに関する詳しいガイダンスは、以下を参照してください。
- プロジェクト憲章:概念的な基盤とアーキテクチャの原則。
- インタラクションのユースケース:PM と AI エージェント向けの詳細なシナリオ(タイミング、対象範囲、ボトルネック、バックテストなど)。
- アーキテクチャの詳細解説:内部の仕組み、ツールディレクトリ、分析パイプライン、データフロー。このサーバーとやり取りする AI エージェント向けの主要なリファレンスです。
- モックデータジェネレーター:
mockgenの使用方法と、MCSTESTの合成サンドボックスの操作方法。
開発と貢献
正直なところ、そこまでは考えていません。
貢献したい場合は、ご連絡ください。このようなツールは多様なプロジェクトで使われることで改善されるため、どんなフィードバックも歓迎します。診断や予測に違和感があれば、お知らせください。
開発に参加する場合は、コーディングエージェントに .agent/rules/preferences.md を読ませてください。特に、このファイルから関連する他のファイルも参照できます。
⚖️ 概念的一貫性
このプロジェクトは、結束性、一貫性、整合性という中核原則に従っています。すべてのツールと分析モデルは、管理上のノイズを排除し、デリバリーのパフォーマンスを統一された信頼できる視点から把握できるよう設計されています。
謝辞
- Redidence Time は Krishna Kumar の成果に基づいており、実装は Sample Path Analysis Toolkit にある同氏のリファレンス実装を大いに参考にし、照合して検証しています。
📜 ライセンス
このプロジェクトは Apache License 2.0 の下でライセンスされています。詳細は LICENSE ファイルと NOTICE ファイルを参照してください。
Copyright © 2026 Bruno Baketarić。
コメント
AI アプリケーションが外部のツールやデータソースに統一的な方法で接続するためのオープンなプロトコルです。クライアントはモデルとの対話を担い、MCP サーバーはツール・リソース・プロンプトテンプレートを提供します。標準メッセージでやり取りするため、1 つのサーバーを複数のクライアントで再利用できます。