モンテカルロ・シミュレーションは、1つの完了日ではなく確率を示します。Merlin Project の新しい MCP サーバーを使えば、Claude に一文で、プランを読み取って10,000通りのプロジェクト推移を計算するよう頼めます。その進め方を紹介します。
モンテカルロ・シミュレーションは、不確実性を確率に翻訳します。単一の納期ではなく、起こりうる完了日の分布が得られます。Merlin Project の MCP サーバーを使えば、専用アドインも、手間をかけて維持する見積もりも、もはや必要ありません。Claude への一文で十分です。
モンテカルロ・シミュレーションが正確には何であり、なぜクリティカルパスに勝るのかは、プロジェクト管理におけるモンテカルロのガイドで解説しています。ここでは実践、すなわち Merlin Project と MCP サーバーで実際にシミュレーションを計算する方法を扱います。
Merlin Project と MCP サーバー
Merlin Project には MCP サーバーが付属します。MCP は Model Context Protocol の略で、AI アシスタントに外部アプリケーションとの構造化された安全な接続を与えるオープンな標準です。サーバーはお使いの Mac 上でローカルに動作し、リモートからはアクセスできません。サーバーが自ら何かをアップロードすることはなく、AI が実際に問い合わせた内容だけを開示します。ただし、AI が読み取った内容は、それぞれのプロバイダー側で処理されます。Claude のようなクラウドクライアントの場合、読み取られたプランデータはそのプロバイダーの API に送信されます。どのプロジェクトを共有するかはお客様が管理でき、まさにデジタル主権の精神にかなっています。有効化はプロジェクトごとに、ドキュメントのツールバーにある「AI ツール」ボタンから行います。Claude Desktop、Claude Code、その他のクライアント向けの完全なセットアップは、MCP ドキュメントに記載されています。
読み取りアクセスで十分
MCP サーバーは現在、プロジェクトデータへの読み取り専用アクセスのみを提供します。モンテカルロ・シミュレーションには、それがまさに適切です。クライアントはプランを読み取ることしかできず、プラン自体は何も変更されません。シミュレーションはプランを一度だけ読み取り、確率的な計算はすべて Merlin の外で実行されます。ライブのプランに書き戻されるものは何もありません。プロジェクト構造は手を加えられない単一の信頼できる情報源であり続け、何度でも、どのプラン状態でもシミュレーションできます。
AI はプランから3つのものを読み取ります。第一に、計画期間を伴うアクティビティ。第二に、ネットプランの論理、すなわち先行と後続のアクティビティ間の依存関係、そして配置関係とバッファを含むものです。第三に、不確実性の所在、すなわちどのアクティビティにリスクが結びついているかです。ネットプランの論理が核心です。依存関係の辺がなければ、ネットプランを計算する代わりに、期間を足し合わせるだけになってしまいます。
要点：不確実性はまだプランに含まれていない
Merlin はアクティビティごとに計画期間を、後には実績値を保存しますが、ネイティブな3点見積もりは保持しません。これを解決する方法は3つあります。
- 独自フィールド。 O と P をテンプレート内のユーザー定義フィールドとして作成し、MCP で併せて読み取ります。テンプレートを自分で管理できる場合の、最もすっきりした解決策です。
- 全体的な不確実性の帯。 計画期間にプラスマイナス X パーセントを三角分布または PERT として適用し、必要に応じてフェーズやアクティビティの種類ごとに調整します。
- ハイブリッド。 注記を付けたリスクのあるアクティビティには独自の帯を、残りには既定値を与えます。
どの方法を選ぶにせよ、不確実性がどこから来るのかを透明に示してください。まさにそれが、シミュレーションを信頼に足るものにします。
エージェント的な流れと、避けるべき考え違い
ここに最もよくある誤解があります。Claude は10,000回の反復を自ら手作業でたどるわけではありません。どの言語モデルも、頭の中で10,000回の無作為標本を引くことはしません。それはトークンを大量に消費するだけでなく、統計的にも無意味です。言語モデルは無作為生成器として不向きだからです。反復はコードの中にあるべきです。
鍵は「Python スクリプト対 MCP クライアント」ではなく、クライアントによるコードの実行です。流れは3つのステップから成ります。
- 読み取り。 Claude は Merlin MCP サーバーの読み取りツールを呼び出し、アクティビティ、期間、依存関係を取得します。
- 計算。 Claude はシミュレーションを数行の numpy として自ら書き、コード環境で回答の一部として実行します。これにはコードを実行できるクライアント（例：Claude Code）が必要です。コード実行のない通常のチャット画面では反復計算はできません。反復ごとにモデルは各アクティビティの期間を1つ引き、トポロジカル順にネットプランをたどり（先行アクティビティとラグを考慮し）、すべての終端ノードの最も遅い終了をプロジェクト完了とします。
- 説明。 Claude は S カーブ、P50・P80・P90、およびトルネード図を返し、結果を分かりやすい言葉で解釈します。
あなたの視点からは、筋書きはシンプルです。自然言語で質問を投げかけます。
Merlin Project からアクティブなプロジェクトを読み取り、10,000通りの起こりうる
プロジェクト推移をシミュレーションして。各アクティビティについて、計画期間の
プラスマイナス20パーセントを PERT 分布として想定して。S カーブと P50・P80・P90 の
日付を見せて。Claude はプランを読み取り、計算し、確率曲線を示します。その背後のコードは実装の詳細であって、学習のステップではありません。電卓のようなものです。頭の中で掛け算する代わりに、それを使うのです。
ちなみに、トークンを大量に消費するのは反復ではなく（コードの中ではほぼ無料です）、300行のアクティビティ一覧をコンテキストに取り込むことです。そのため、はじめのうちは次のことが当てはまります。あえて小さく整理された、15 から 25 個のアクティビティから成る例となるプランです。これはパス収束や興味深いトルネードを生むのに十分な大きさであり、会話全体が画面1ページに収まる程度の小ささです。
10,000回の試行から得られる結果
上のプロンプトに対する Claude の回答は、小規模な建設プロジェクトのプランで計算すると、次のようになります。Claude はアクティブなドキュメントに接続し、アクティビティ、リンク（終了-開始が26回、開始-開始が1回）、カレンダー（月曜日から金曜日、1日8時間）を読み取り、ネットプランを再構築して、計画完了日と照合します。モデルはそれを正確に再現します。60営業日、すなわち2026年8月21日です。そして10,000回の試行が実行されます。
この例題プロジェクトはおよそ2ダースのアクティビティしか含まず、その納期は長い直列のチェーンによって決まります。そのため P10 と P90 の間の幅は約1週間とあえて狭くなっています。より大きな、あるいはより分岐の多いプロジェクトは、たいていはるかに大きくばらつきます。
| 信頼水準 | 日付 | 計画比（8月21日） |
|---|---|---|
| 計画納期 | 2026年8月21日 | 達成確率は約49パーセント |
| P50 | 2026年8月24日 | プラス1営業日 |
| P80 | 2026年8月25日 | プラス2営業日 |
| P90 | 2026年8月26日 | プラス3営業日 |
全10,000回の試行にわたる幅は、最早で8月17日から最遅で9月1日までです。
読み取り方は明確です。計画納期は五分五分の納期です。試行のおよそ半分では守られ、残りの半分では超過します。これは典型的な結果です。確定的な計画はほぼ常に楽観的な P50 に着地し、信頼できる納品日には着地しないからです。90パーセントの確実性で約束したいなら、8月26日、すなわち約3営業日のバッファを伝えます。
Claude はその際、自らの前提を明らかにします。ここでは計画期間を最可能値とし、O を −20 パーセント、P を +20 パーセントとする対称的なPERT-ベータ分布を用いました。プランに格納された実際の、部分的に非対称な3点見積もりを用いると、右の裾はより長くなり、P90 はより遅くなります。離散的なリスク事象、すなわちサプライヤーの脱落と構造設計者の脱落は、ここではまだモデル化していません。これは純粋な期間のばらつきでした。それこそを、次の2つの例で計算していきます。
例 A：サプライヤー比較
最も強力な例は、単なる予測の問いではなく、意思決定の問いに答えます。納入に依存する1つのアクティビティを思い浮かべてください。サプライヤー A は経験上、一部のケースでは時間どおりに納入し、それ以外では数日の遅延を伴います。ここで重要なのは分母です。100回の納入のうち10回の遅延は、15回のうち10回とは別のリスクです。まさにここでモンテカルロは真価を発揮します。根拠のない想定で計算するのではなく、実際の納入履歴を予測に翻訳するからです。
本当の価値は、お金とリスクのトレードオフにあります。サプライヤー A はより安価ですが信頼性に劣り、サプライヤー B はより高価ですが安定しており、4,000 € 多くかかります。この上乗せ分は見合うのでしょうか。この問いを経営陣はすぐに理解し、モンテカルロは勘ではなく数字でそれに答えます。
こうした問いは、Claude に一文で投げかけられます。
アクティビティ19「資材の取り付け」は納入に依存している。サプライヤー A は経験上、
85パーセントのケースで時間どおりに納入し、それ以外では10日の遅延を伴う。これが
完了日にどう影響するかをシミュレーションして、常に時間どおりに納入するが
4,000 € 多くかかるサプライヤー B と比較して。Claude はリスク・スイッチを納入に結びつけ、両サプライヤーを同じ無作為抽出（Common Random Numbers）で計算します。これにより、違いがきれいに納入のみに依存するようにします。結果は驚くほど明確です（数値の単位は営業日です）。
| 信頼水準 | サプライヤー A（85% 時間どおり、それ以外 +10営業日） | サプライヤー B（常に時間どおり、+4,000 €） |
|---|---|---|
| P50 | 2026年8月21日 | 2026年8月21日 |
| P80 | 2026年8月25日 | 2026年8月25日 |
| P90 | 2026年8月25日 | 2026年8月25日 |
| 計画納期の達成 | 50.5% | 50.5% |
| A による完了日のずれ | 0.00% | 基準 |
10,000回の試行のうち、信頼性に劣るサプライヤー A が完了日をずらすものは1つもありません。2つの分布は完全に重なります。理由はプランにあります。アクティビティ19「資材の取り付け」は2つの先行アクティビティ、すなわち納入と、クリティカルパス上にある屋根に依存しています。屋根は体系的に遅れて完成するため、「資材の取り付け」はいずれにせよファサードの納入ではなく屋根を待ちます。納入と取り付けの間には中央値で21営業日のバッファがあり、最も圧縮された試行でさえなお17営業日ほどあります。10営業日の遅延がこの限界に達することはありません。
これは感度を見るのが最も分かりやすいでしょう。完了日を動かすには、そもそも遅延がどれほど大きくなる必要があるのでしょうか。
このバッファの限界を超えて、つまりおよそ 17～21 営業日を超えて初めて、何かが影響し始めます。25日では試行の7パーセントがずれ、30日では約15パーセントです。これでコストの判断は明確です。これらの前提のもとでは、サプライヤー B のための 4,000 € は納期上の利得をまったく買いません。回避が期待される遅延は0.0営業日です。純粋に納期の観点からは、サプライヤー A が合理的な選択です。その金額は、プランがバッファを通じてすでに負っているリスクのために支払われることになります。B が見合うのは、前提が変わったときに初めてです。遅延が10日よりも大幅に大きくなる場合（地域内の納入ではなく輸入コンテナ）、躯体工事がはるかに早く完成してバッファが縮む場合、あるいはファサードの系列に違約金付きの独自の中間納期がぶら下がっている場合です。まさにそれは、純粋に確定的なプランでは決して示せないことです。
正直な補足です。2つの例は、それぞれのリスク・スイッチを伴う個別のシミュレーション試行です。前出の S カーブと比べて基準納期が1日ずれるのは、通常のサンプリングのノイズであって、矛盾ではありません。モンテカルロは分布を推定するものであり、固定された小数点以下の桁を持つ電卓ではありません。
例 B：リソースの脱落
2つ目の例は、別のつまみを回します。期間ではなく、離散的な事象です。重要なリソースが脱落する可能性があります。ここでは、2つのアクティビティ、すなわちプロジェクト初期の構造設計と後期の構造検収に従事する構造設計者です。彼が脱落するか、そしてもしそうなら、いつのほうがより厳しく響くのでしょうか。
私のプロジェクトを3つのケースでシミュレーションして。リソース「構造設計者」が
脱落しない、第3週に10日間脱落する、第8週に10日間脱落する。それぞれ
P50/P80/P90 と、どの脱落時点が完了日に最も強く響くかを見せて。ここでも Claude は3つのケースすべてを同じ無作為抽出で計算し、違いがきれいに脱落のみに依存するようにします。
| ケース | P50 | P80 | P90 | ずれ |
|---|---|---|---|---|
| 脱落なし | 2026年8月21日 | 2026年8月25日 | 2026年8月25日 | 基準 |
| 早い脱落（構造設計） | 2026年9月4日 | 2026年9月8日 | 2026年9月8日 | +10営業日 |
| 遅い脱落（構造検収） | 2026年9月2日 | 2026年9月4日 | 2026年9月7日 | +8営業日 |
どちらの脱落も計画納期を確実に超過させ、達成確率は50パーセントから0パーセントへ下がります。興味深いのはその差です。早い脱落のほうがより厳しく響きます。100パーセントの試行で、遅い脱落よりも完了日を遠くへずらし、平均で2営業日です。理由は時点そのものではなく、ここでもバッファの状況です。構造設計はクリティカルパス上に完全に乗っており、バッファがありません。その10日の脱落は1対1で影響し、どの試行でもきっかりプラス10営業日となります。一方、構造検収は並行する系列から小さな残りバッファを引き出し、それが10日のうち2日を吸収してから、自らが拘束的なアクティビティになります。残るのはプラス8営業日です。
これが例 B から得られる確かな教訓です。同じ長さの脱落でも、影響を受けるアクティビティがどれだけバッファを持つかによって、そのコストは異なります。代替要員、前倒し、予備は、まずバッファを持たないクリティカルパス上のリソースに充てるべきです。
クリティカルパス対バッファ：共通の要点
どちらの例も、核心では同じことを語っています。決め手はリスクそのものではなく、それがネットプランのどこに位置するかです。同じ遅延でも、バッファを持つアクティビティでは何のコストもかからず、クリティカルパス上ではすべてを失わせます。モンテカルロが示すのは「遅延は悪い」ということではなく、リスクがいつ突き抜け、プランがいつそれを吸収するかです。だからこそ、例 A では安価なサプライヤーが合理的な選択であり、例 B では早い脱落が高くついたのです。前者ではバッファがリスクを受け止め、後者ではそれが欠けているからです。Merlin Project でクリティカルパスを的確に調整する方法は、このガイドで示しています。
試してみてください
モンテカルロの背後にある技術は数十年前からあります。新しいのは、それがどれほど簡単になったかです。Merlin Project の MCP サーバーを使えば、あなたのプランはすでに、AI が読み取って計算できる形になっています。自前のデータ管理を伴う専用アドインが、Claude への一文になります。
すでに Merlin Project をお使いなら、あるプロジェクトで MCP サーバーを有効化し、最初の質問を投げかけてみてください。セットアップはMCP ドキュメントに記載されています。Merlin Project をまだご存じない場合は、製品ページでご確認いただくか、お試し用に直接ダウンロードしてください。
結果を手作業でまとめる必要もありません。ご希望に応じて、Claude は一連の試行をステークホルダー向けの完成したレポートにまとめます。この例題プロジェクトの完全なレポートをご覧ください：モンテカルロ・レポートをダウンロード（PDF、英語）。
このブログ記事についてご質問やご意見がございましたら、ぜひフォーラムへのご投稿をお待ちしております。
よくある質問
MCP サーバーでモンテカルロ・シミュレーションを行うにはプログラミングの知識が必要ですか。
いいえ。自然言語で質問を投げかけるだけで、Claude がシミュレーションを自らコードとして書き、実行します。必要なのは Claude Code のようなコード実行が可能なクライアントだけです。
シミュレーションは Merlin Project のプランに変更を書き戻しますか。
いいえ。シミュレーションには読み取りアクセスだけで十分です。AI はプランを一度だけ読み取り、Merlin の外で計算し、ライブのプランには何も書き戻しません。プロジェクト構造は手を加えられないままです。
シミュレーションを計算するにはどのクライアントが必要ですか。
コード実行が可能な MCP クライアント、例えば Claude Code です。コード実行のない通常のチャット画面では、10,000回の反復を計算できません。
MCP サーバーで私のプロジェクトデータは安全ですか。
MCP サーバー自体はお使いの Mac 上でローカルに動作し、リモートからはアクセスできません。サーバーが自ら何かをアップロードすることもありません。ただし、AI が読み取った内容は、それぞれのプロバイダー側で処理されます。Claude のようなクラウドクライアントの場合、読み取られたプランデータはそのプロバイダーの API に送信されます。AI が何を見てよいかはプロジェクトごとにお客様が許可し、プランに書き戻されるものは何もありません。
はじめのうち、プランはどのくらいの大きさが適していますか。
あえて小さく、15 から 25 個のアクティビティから成るプランが理想的です。パス収束や意味のあるトルネードを生むのに十分な大きさであり、会話全体が見通しよくまとまる程度の小ささです。
