PMOがClaudeとpmo.runのMCPサーバーでタスクを自動化する方法
pmo.runのMCPサーバーは、PERT、EVM、TCO、モンテカルロ分析という4つのPMIツールをClaudeに提供します。使い方を実践的に解説。
ステータスレポートの隠れたコストでは、プログラム内のコミュニケーション負荷が共有認知によって解決可能であることを論じました。さらに、認知をコード化して再利用可能にする解決策を示しました。
本稿はその実践編です。pmo.runは、Claudeから呼び出せる4つの古典的なPMIツール — PERT、EVM、TCO、モンテカルロ分析 — を備えたMCPサーバー（MVP版）をリリースしました。現時点ではソースコードからインストール可能で、PyPI経由の正式リリースはロードマップに含まれます。
以下の実践例では、ベンダーの教科書どおりの「14日」という見積もりが、ベンダー側からは見えない摩擦を加味するとプログラム上は「28日」のコミットに変わることを示します。
pmo.runのMCPサーバーで何ができるのか?
LLMから呼び出せるよう調整した4つのPMI手法を、MCP stdio プロトコルに対応するクライアント(Claude Desktop、Claude Code、その他)から利用できます。
| ツール | 手法 | 用途 |
|---|---|---|
estimate_task_duration | PERT(3点見積もり) | 単一タスクまたはアクティビティの期間 |
evaluate_project_health | EVM(アーンドバリュー管理) | これまでのスケジュールとコストのパフォーマンス |
compare_investment_options | TCO(総保有コスト) | 複数の選択肢を対象とした複数年のコスト比較 |
identify_schedule_risk | モンテカルロ分析 | プログラム全体のリスクとパーセンタイル日付 |
サーバーが提供する価値は、これらの手法をClaudeから一行の精度と一貫した出力スキーマで確実に呼び出せるようにすることです。Claudeは数値を推測するのではなく、ツール経由で正確な値を計算します — 大規模言語モデルはツールの助けなしでは数値計算が苦手だからです。
インストール方法は?
現時点ではソースコードからのインストールに対応しています(技術者向け):
git clone https://github.com/lemur47/logic.git
cd logic
uv run python -m mcp_server.server最初の uv run で依存関係が同期され、サーバーが stdio モードで起動します(停止は Ctrl+C)。すべてローカルで動作します — テレメトリーは送信されず、データは端末から出ません。
PyPI 経由の pip install pmorun-mcp はロードマップに含まれます。計算ロジックは現時点で安定しており、変わるのはインストール経路だけです。
Claudeへの接続方法は?
Claude Desktop は MCP の設定を ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) または %APPDATA%\Claude\claude_desktop_config.json (Windows) から読み込みます。ローカルにクローンしたディレクトリを指すエントリを1つ追加します:
{
"mcpServers": {
"pmo-logic": {
"command": "uv",
"args": ["run", "--directory", "/absolute/path/to/logic", "python", "-m", "mcp_server.server"]
}
}
}/absolute/path/to/logic をクローン先のディレクトリに置き換えてください。Claude Desktop を再起動すると、どの会話からも4つのツールが使えるようになります。
Linux 環境、あるいはターミナル派の方は、Claude Code が同じ MCP stdio プロトコルに対応しています:
claude mcp add pmo-logic -- uv run --directory /absolute/path/to/logic python -m mcp_server.serverツールの挙動は同一です — 2つのクライアントの間に機能的な差はありません。
実践例: ベンダーの見積もりはどこまで現実的か?
あるソフトウェアベンダーのPMが、カスタムAPI統合のために3点見積もり(7 / 14 / 21 営業日)を提示してきました。教科書どおりであれば95%上限(約19日)でコミットしたいところです。しかし、プログラム側には既知の摩擦が2つあります:
- ベンダーは異なるタイムゾーンに拠点を置いている(コミュニケーションの分断)。
- 統合先のレガシーなレポートシステムには、誰もマッピングできていない下流の利用者がいる(隠れた依存関係)。
ステップ1: 教科書どおりの PERT。Claude に estimate_task_duration(O=7, M=14, P=21) を呼び出してもらいます:
| 指標 | 計算式 | 値 |
|---|---|---|
| 期待値 | (O + 4M + P) / 6 | 14 |
| 標準偏差 | (P − O) / 6 | 2.33 |
| 95% 上限 | E + 2σ | 18.67 |
対称な入力は最頻値に収束します — 期待値14日、95%信頼区間でのコミットは19日です。
ステップ2: 摩擦を重ねる。2つのインサイトタグを付けて再度呼び出します:
estimate_task_duration(
optimistic=7, most_likely=14, pessimistic=21,
tags=[("FRAGMENTED_COMMUNICATION", 0.8),
("HIDDEN_DEPENDENCIES", 0.5)]
)出力が変化します:
| 指標 | 教科書値 | 調整後 |
|---|---|---|
| 期待値 | 14 | 16.96 |
| 95% 上限 | 18.67 | 27.55 |
| 合成倍率 | 1.0 | 1.846 |
コミット日は、教科書値の19日から、プログラムの実態に即した28日へとシフトします。ベンダーが間違っているわけではありません — ベンダーは、どちらの摩擦も見えない自分の側から見積もっているだけです。PMOの役割は、ベンダーには見えない摩擦のレイヤーを重ねることにあります。
実際のインサイト係数はMCPサーバーに含まれているか?
プレースホルダー係数のみ提供されており、機能も実装済みです。
v0.1 でリリースされたのは仕組みの部分です — 3つのインサイトタグ(FRAGMENTED_COMMUNICATION、HIDDEN_DEPENDENCIES、MULTIPLE_STAKEHOLDERS)に、それぞれプレースホルダーの倍率範囲が設定されています。深刻度 [0, 1] が各タグの範囲を線形補間し、タグは悲観値の側にのみ乗算的に合成されます。楽観値と最頻値はそのまま — 裾だけが広がる構造です。
これらの係数は、現場データから導いたものではなく、PMOの妥当な初期値です。深刻度0.8における FRAGMENTED_COMMUNICATION の42%倍率は、実際のベンダー見積もりデータセットから導かれたものではなく、PMOの経験則を初期値としてコードに落とし込んだものです。
v0.2 で予定しているのは、plugins/ レイヤーを通じた業種別の調整です — 業種(金融、製造、公共部門など)ごとの実プログラムデータから倍率範囲を導きます。これには estimation_log データソースが必要で、これこそが OSS ではなく有償レイヤーが担う部分です。
v0.1 を今日から使い始める場合は、調整後の見積もりをスポンサーとの「より鋭い議論を始めるためのきっかけ」として捉えてください。調整済みのコミットとしてではなく、対話の材料として。
v0.1 に含まれていないものは?
v0.2 以降に持ち越したのは次の6つです:
- PyPI 公開 — 公開パッケージとしてのインストール(
pip install pmorun-mcp) - ベイズ推定 — レイヤー2の調整には、まず現場データが必要
- ディリクレ–MC シミュレーション — 同様に現場データに依存
- ホスト型 Streamable HTTP トランスポート — v0.1 はローカル stdio のみ
- OAuth 2.1 認証 — ホスト型トランスポートと対で実装
- 現場で調整されたインサイトタグ係数 — 上述の通り商用調整レイヤーが担う部分
ローカル OSS パッケージは引き続き、計算ロジックとツール周りの更新を受け取ります。ホスト型(有償)版は、データレイヤーと調整の準備が整い次第提供します。
リポジトリをクローンして、実際の見積もりで試してみてください。ソース: github.com/lemur47/logic。Issue を歓迎します。