2026年6月11日

PMOをサポートするClaudeとMCPサーバー：ステアリングコミッティの対話をアップグレードする秘策

PMOが直面する4つの難題に、勘や雰囲気ではなく、根拠があり再現可能な数字で答える。pmo.runのMCPサーバーとClaudeの実践的な使い方を、仮想事例とコードで解説。

ステアリングコミッティは、基本的に4つの質問で動いています。どれくらいかかるのか、リスクはどれくらいか、どの選択肢が良いのか、計画どおりに進んでいるのか？

多くのプログラムの回答は「だいたいの雰囲気、どんぶり勘定」で提示されます。良くいえば、ベテランの勘をビジュアルで上品に包んだスライドが投影されます。悪くいえば、会議を乗り切るためのやっつけ仕事になります。

ClaudeとMCPサーバーの組み合わせは、この対話力学そのものを変えます。

PMOが資料を準備するための対話で、Claudeが聞き役・質問役・説明役を担い、pmo.runのMCPサーバーが計算を担います。同じ数式を使い、監査可能で状況に応じた示唆を提示します。

本稿では4つの質問に対する準備を、実際のツール呼び出しとその出力とともに紹介します。

題材として、意図的に架空のプログラムを使います。API を持たない独自開発の古い基幹システムに AI 駆動の BI レイヤーを載せる、12ヶ月・約10名体制のプロジェクトです。以下の数字はすべてサンプルであり、実案件のデータではありません。しかし、パターンには見覚えがあるはずです。

2分で終わるセットアップ

サーバーは PyPI で公開済みです。uvx を使えばインストール不要で起動できます：

claude mcp add pmo-logic -- uvx pmorun-mcp

Claude Code のセットアップはこれだけです。Claude Desktop も基本設定は同じです。詳細は技術ドキュメントをご覧ください。すべてローカルで動作し、データが手元のマシンから出ることはありません。アカウント登録すら不要です。

ポイントはMCPサーバーが部品として動作する「全体構成」にあります。

Claude 単体では精査が必要なコードが会話と共に出力されます。毎回レビューコストがかかります。もしくは、レビューせずに資料化し、誤った情報で意思決定をする可能性すらあります。

しかし、データ系 MCP（Airtable、Jira、スプレッドシート）を加えると、プロジェクトの実データから状況が見えるようになります。さらに pmorun-mcp を加えると、その状況に対して計算や分析ができるようになります。しかも、チーム全員が共有する手法で示唆が出せます。それはもはや「共有知」です。

データ系MCPとpmorun-mcpを組み合わせたClaude：質問を入れると、根拠のある数字が返る

準備その1：「調査フェーズはどれくらいかかるのか？」

Claude に、普通の言葉でこう聞きます：

基幹システムの調査フェーズを見積もって。チームの見立ては楽観4週・最可能性6週・悲観8週。ただしコミュニケーションは3社のベンダー間で分断されていて、ドキュメントは古い。

Claude はインサイトタグ付きで estimate_task_duration を呼び出し、こう返します：

{
  "textbook": { "expected": 6.0, "std_dev": 0.67, "range_95": [4.67, 7.33] },
  "adjusted": {
    "expected": 7.72, "std_dev": 2.39, "range_95": [2.95, 12.5],
    "pessimistic": 18.33,
    "tags_applied": [
      { "name": "FRAGMENTED_COMMUNICATION", "severity": 0.7, "multiplier": 1.38 },
      { "name": "MULTIPLE_STAKEHOLDERS",   "severity": 0.6, "multiplier": 1.66 }
    ]
  }
}

Before:「チームは6週といっています。」
After:「6週は教科書的な数字です。すでに特定済みのコミュニケーション摩擦を加味すると期待値は8週弱、信頼できる最悪ケースは12週 — それを動かしている2つの要因はこれです。」

まさにこの条件下の調査フェーズは、計画見積もりの1.5〜2倍に膨らむのが通例です。委員会はその理由を、謎の遅延ではなく、名前のついた乗数として見ることができます。

準備その2：「どの日付ならコミットできるのか？」

ガントチャートは最長パス（クリティカルパス）に沿って最可能性値を足し上げ、「13週」と宣言します。Claude にこう聞きます：

スケジュールをシミュレーションして。調査（4/6/12）のあと、コネクター実装（2/4/10）とデータクレンジング（3/4/9）が並行で走り、両方が終わったら BI 統合（2/3/6）。

Claude は identify_schedule_risk を呼び出します。依存関係グラフ上で1万回のモンテカルロシミュレーションを実行するためです：

{
  "n_simulations": 10000,
  "percentiles": { "P50": 15.26, "P75": 16.66, "P85": 17.42, "P95": 18.68 },
  "critical_path_frequency": {
    "investigation": 1.0,
    "connector_implementation": 0.48,
    "data_cleansing": 0.52,
    "bi_integration": 1.0
  }
}

1万回のシミュレーションによる完了週の分布：ガント上の13週計画が実現する確率は11.5%。P85は17.4週

Before:「計画では13週です。」
After:「13週で終わるのは、およそ9回に1回です。100回中85回守れる日付をコミットするなら17.4週 — そして注目すべきは、皆が心配しているコネクターよりも、データクレンジングのほうがわずかに高い頻度でクリティカルパスに乗っている点です。」

同じ入力、同じシード、同じ答え。来週誰かに突っ込まれても、同じ数字が再現できます。

準備その3：「統合担当の席は、社員か業務委託か？」

毎月、単価だけで議論される定番の要員問題です。Claude に、3年スパンで社員と業務委託を比較するよう依頼します（数値は中立的な単価）：

{
  "results": [
    { "name": "employee_seat",   "monthly_cost": 10.0,  "total_cost": 360.0, "npv_tco": 340.79, "rank": 1 },
    { "name": "contractor_seat", "monthly_cost": 12.92, "total_cost": 465.0, "npv_tco": 438.61, "rank": 2 }
  ],
  "best_option": "employee_seat"
}

compare_investment_options は、月額の表示価格が隠しているものを織り込みます。片側には採用コストと立ち上がり期間、もう片側には長期的な雇用リスクを負わない身軽さ、そして両側に NPV の割引です。

Before:「業務委託のほうが高いです。」
After:「3年トータルでの差は1.3倍 — 月額単価が示唆する1.6倍ではありません。社員の席は安く、かつ知識が組織に残る。業務委託の席は、柔軟性を価格のついたプレミアムとして買うものです。」

委員会が議論すべきは前提条件であって、目先の単純計算ではなくなります。

準備その4：「本当に計画どおり進んでいるのか？」

6ヶ月目。ステータスレポートは「黄色」です。トラッキング用の MCP からそのまま取り出した4つの数字 — 計画価値120、出来高96、実コスト126、総予算240 — を Claude に渡すと、evaluate_project_health を呼び出します：

{
  "metrics": {
    "spi": 0.8, "cpi": 0.7619,
    "eac": 315.0, "vac": -75.0, "tcpi": 1.2632,
    "percent_complete": 40.0, "percent_spent": 52.5
  },
  "health": {
    "status": "off_track",
    "reasons": ["Schedule: SPI 0.8 < 0.9 threshold", "Cost: CPI 0.7619 < 0.9 threshold"],
    "summary": "Project off track — immediate attention required."
  }
}

Before:「少し遅れている感はありますが、なんとか間に合うと思います。」
After:「作業の40%を終えた時点で、予算の52.5%を消化しています。この効率のままなら完成時コストの予測は315で、予算は240。予算内で着地するには1.26のコスト効率が必要ですが、これまで一度も達成できていません。データクレンジングの超過は一時的なブレではなく、織り込むべきリスクです。」

ステータス「黄色」は、天気予報「曇り」のような、なんとなくの気分ではなく、意思決定の材料になります。

批判「でも、その計算なら ChatGPT でもできるのでは？」

できます。ただし、1回きり、手作業で、毎回違うやり方で、監査証跡なしで。汎用 LLM にモンテカルロシミュレーションを即興させると、それらしい Python とそれらしい答えが返ってきます。翌日もう一度聞くと、少し違う答えが返ってきます。誰もそれを再現できず、検証できず、改善できません。

前述の通り、論点は「レビューコスト、間違った情報に依拠した意思決定、共有知の欠如」です。差別化要素（moat）は貴社の「共有知と組織構造」です。

チーム全員が同じやり方で呼び出すツールは、ステアリングコミッティが再現でき、検証でき、時間をかけて校正できる数字をくれます。本稿のすべての出力は、シード固定・バージョン管理されたオープンソースの実行結果です。今日そのまま再実行すれば、同じ結果が得られます。

ご自身のプログラムで試す

claude mcp add pmo-logic -- uvx pmorun-mcp

そして、次のステアリングコミッティであなたが受けるはずの質問を、Claude に聞いてみてください。ソースコードは MIT ライセンスで github.com/lemur47/logic に公開されています。セットアップの詳細は技術ドキュメントをご覧ください。