Cooling Planner

Cooling Planner v0.10 プレビュー

English | 日本語

モデル上の酪農牛舎で設備を操作し、環境、牛の熱損失、水とエネルギーの使用量を比較するブラウザーアプリです。v0.4 の形状、物理モデル、編集機能を再利用しつつ、画面と計算の連携を再構築しています。v0.9 では、設備の変更に連動する、群平均に基づく代表日の乳量推定（仮説モデル milk-heat-deficit-v0.1）を追加しました。v0.10 では、代表日の時間別気象データ（24 行）、日ごとの点・面積集計、および制約付き候補比較（compare_candidates）を追加しました。

このリポジトリは Dairy Horizon から切り出した単独バージョンです。FastAPI、API キー、親プロジェクトは必要ありません。 Node.js 22.12 以降が必要です。初回実行時は npm ci && npm run build を実行し、その後 npm start を実行してください。 リポジトリではソースとビルド済みの配布物の両方を管理しています。変更時は配布物を再生成してください。

ライブデモとブランチ

ブランチ	UI 言語	ホストされたデモ（AWS Amplify）
english	英語	https://english.da05znjm47ziu.amplifyapp.com/
main	日本語	https://main.da05znjm47ziu.amplifyapp.com/

english ブランチは海外のハッカソン向けに作成され、英語のみの UI（言語切り替え機能なし）を備えています。モデル計算、保存形式、MCP 用語はどちらのブランチも同一で、ユーザー向けの文字列のみが異なります。各ブランチは、プッシュ時にそれぞれの Amplify URL へ自動デプロイされます。以下に引用する UI ラベルは英語のものです。日本語の手順については、docs/README.ja.md をご覧ください。

クイックスタート

cooling-planner-v0.10.html は、CSS、JavaScript、計算ワーカーを含む単一ファイルです。解凍して、デスクトップ版の Chrome／Edge で開いてください。インターネット接続、ログイン、API キーは不要です。ブラウザーがローカルファイルを開けない場合は、以下のローカル HTTP サーバーを使ってください。

現在の対象範囲については現在の計画をご覧ください。受け入れ基準と現在のコードの対応については受け入れ基準をご覧ください。

乳量計算の仕様は熱負荷 → 乳量仮説モデル v0.1です。手順と検証については、実装計画とレポートをご覧ください。公開済みの 6 条件の乳量表は、参照画面に参考資料として収録しています。

検証の対象範囲と結果は単独版の検証記録に記載されています。 公開 HTTPS、file://、実機の Chrome／Edge／Safari のすべての組み合わせが確認されているわけではありません。

最初のステップ（3～5 分）

画面は納屋を中心とした HUD です。下部ドックから設備を配置し、右側のパネルで設定して、下部シートで結果を比較します。初回起動時には短いガイドが表示されます（スキップ可能です。「？」ヘルプから再表示できます）。

1. 初期計算が終わるまで待ちます。「ドラフト A」はベースラインのコピーとして開始するため、熱損失の差が 0 W でも正常です。
2. ドックの「屋根」ボタンから、「反射コーティング」と「20 mm 断熱材」を有効にします。給餌 7 の場合、局所気温は 36.5 → 33.0 °C になり、熱損失の改善量は約 +384 W です。これらはモデルによる計算値です。
3. ドックの「ファン」を押し、納屋の内側をクリックして新しい装置を配置します（Esc／「キャンセル」で中止）。既存のファンをクリックすると選択でき、ドラッグして移動できます。右側のパネルで高さと向きを変更します。背景をドラッグすると視点が回転します。「元に戻す」で 1 つ前の操作に戻ります。
4. 「結果と比較」→「タイムライン」で、60 分間の固定気象チャートと再生を確認します。左上のメトリックチップ（不足／改善／風速／気温）を切り替えると、床の色が変わります。カードと床の色は 60 分間の平均値を維持します。
5. 「結果と比較」→「影響の参考値」で、群れの平均的な代表日の乳量、ベースラインとの差、および受胎の参考条件を確認します。「公開済みの表を表示」では乳量の参考表を確認できます。
6. 「比較」で、平均／最大の不足量、ストール／給餌／待機場所での不足量、ベースラインとの水量／エネルギー差を確認します。不足量が最大の場所を押すと、床の不足量表示と、その地点の熱損失の内訳に移動します。
7. 上部の「保存」で配置と条件を JSON として保存し、「読み込み」で復元します。「比較」または「設定と保存」→「MCP シナリオ JSON をインポート」から、MCP シナリオ JSON を貼り付けることもできます。

UI 改修計画と検証については、ゲームスタイル UI の実装計画とレポートを参照してください。

ベースラインは「設備なし」ではありません。既存のファン 10 台とソーカー 12 台があり、屋根対策はありません。 ドラフト B は同じファンから開始し、ソーカーは停止、ミストは稼働しています。B の熱損失の差がマイナスの場合、それは「このベースラインより悪い」という意味であり、「ミストに効果がない」という意味ではありません。

ビルドとテスト

要件：Node.js 22.12 以降、TypeScript 5.8.3。3D レンダリングには Three.js 0.180.0 を使用します（ビルド時に npm 依存関係としてバンドルされます）。実行時に外部ネットワークや CDN は不要です。

npm ci
npm run typecheck
npm test
npm run build
npm start

npm start は dist-offline を http://127.0.0.1:4173/ で配信します。PORT でポートを変更できます。ビルド済みの配布物を表示するだけであれば、Node のみで npm start を実行できます。npm install や再ビルドは不要です。

ビルド出力：

• cooling-planner-v0.10.html：スタンドアロン HTML（旧版の cooling-planner-v0.9.html も残されています）。
• dist-offline/：静的ホスティング用の HTML／CSS／app.js／worker.js。フォルダー全体を配信してください。

ハッカソンの PoC では、エージェント側での検証は型チェック、関連する単体テスト／統合テスト、ビルドです。E2E テストと実ブラウザーでのチェックは人間と CI が担当します。エージェントは明示的に依頼された場合にのみ実行します。

以下の E2E 手順は、人間／CI 向けです。ブラウザーテストでは Python Playwright／pytest と Chromium を使用します。デフォルトはヘッドレスで、Xvfb は不要です。 CHROMIUM_PATH に既存の Chromium のパスを指定するか、省略して Playwright が管理するものを使用してください。 ヘッド付きで実行する場合は、ディスプレイを用意して HEADLESS=0 を設定してください。

python -m pip install -r requirements-test.txt
python -m playwright install chromium
npm run build
npm run test:browser

デフォルトでは、スタンドアロン HTML をインラインでテストします。別のターミナルで npm start を実行してから、 COOLING_PLANNER_URL=http://127.0.0.1:4173/ npm run test:browser を実行すると、HTTP 版を確認できます。 この設定でも、WebGL が利用できない場合のテストにはスタンドアロン HTML を使用します。

Python の参照実装：

(cd reference/thermal && python -m unittest -v)
(cd reference/fertility && python -m unittest -v)

node scripts/make-examples.mjs を実行すると、検証済みの入力例と統合計算結果が再生成されます。最初に npm run build を実行してください。

MCP と WebMCP（外部 AI クライアントとの連携）

デモに使用する連携方式を選択してください。

連携方式	目的	接続方法
WebMCP	表示中の英語または日本語の公開サイトを操作します。表示モード、All/Top/Side、回転、パン、ズームに対応します	Codex などのブラウザー対応 AI クライアント → Chrome DevTools MCP → 開いているサイト。WebMCP のセットアップを参照してください
ローカル MCP	ローカルで提供されている画面を 1 つ操作します	stdio サーバー + http://127.0.0.1:4174/?mcp=1。手順は以下を参照してください
リモート MCP	ブラウザー画面を操作せずにシナリオを評価します	ホストされた Lambda MCP。リモート MCP への接続を参照してください

WebMCP とローカル MCP は、ブラウザー側で稼働中の ProjectStore を使用し、画面の Undo 履歴を共有します。リモート MCP は、独立したステートレスな計算サービスです。実装の詳細については、ローカル MCP の計画およびWebMCP レポートを参照してください。

ローカル MCP：起動と接続

1. リポジトリ内で npm ci && npm run build を実行します。
2. 次の stdio サーバーを AI クライアントに登録します（パスは実際のリポジトリの場所に合わせて調整してください。npm run mcp と同等です）。

{
  "mcpServers": {
    "cooling-planner": {
      "command": "node",
      "args": ["/absolute/path/to/cooling-planner/scripts/mcp-server.mjs"]
    }
  }
}

Devin CLI の場合は、リポジトリ内で実行してください（.devin/mcp_config.local.json に登録します）。

devin mcp add cooling-planner -- node "$(pwd)/scripts/mcp-server.mjs"

3. http://127.0.0.1:4174/?mcp=1 を単一のタブで開きます。このモードでは npm start は不要です。MCP プロセスは dist-offline も配信します。
4. AI から get_state を呼び出します。

ツールは get_state / edit / evaluate / compare_candidates / describe_model / set_view / get_results / undo の計 8 個です。編集は現在のシナリオに適用され、画面にすぐ反映されて、既存の経路で再計算されます。人が画面上で行った操作と MCP 操作は、同じ取り消し履歴を共有します。

• evaluate：画面を変更せずに仮説を評価します。edit と同じ操作を配列で渡すと、確定済み状態のクローンに順番に適用され、シナリオのエリアごとの集計、リソース、屋根、および（includeDaily を指定した場合は）日ごとの乳量とベースラインとの比較統計が返されます。画面上のシナリオ、デバイス、取り消し履歴、再計算には一切触れないため、「この対策を実施したらどうなるか」や「不足をどこまで減らせるか」を検討するには、edit→undo ではなくこちらを使用してください。

• compare_candidates：1～3 個の候補操作リストを、同じ確定済みプロジェクトのクローンにそれぞれ適用し、日ごとの結果（平均不足量、水量、エネルギー使用量、悪化した地点）、制約の判定、順位を返します。候補で使用できるのは update_device / update_system / update_roof のみです。係数、天候、シナリオ切り替え、追加／削除は拒否されます。順位は呼び出し内でのみ有効です。

• edit / evaluate の add_device では、x と y（両方必須）を指定して任意の座標に配置できます。範囲外または障害物ゾーン内の位置はエラーになります。

• describe_model：モデルの計算構造、入力／出力フィールドの意味、主な仮定定数、制限、検証状況を返します。数値を解釈または説明する前に呼び出してください（サーバーの指示にも記載されています）。

• MCP 経由でモデル係数も変更できます。update_model（物理モデル：ジェットの拡散／減衰、対流熱伝達、放射オフセット、屋根モデル係数、profiles 感度仮定セットなど）、update_milk（乳量の仮説：Qref、beta、ラグ重みなど）、update_references（ベースラインの乳量と受胎率の基準値）を使用します。モデルの数式とバージョン識別子は変更できず、範囲外の値は既存の検証によって拒否されます。evaluate と組み合わせると、画面に触れずに異なる係数での結果を比較できます。

• MCP SDK は @modelcontextprotocol/server 2.1.0（v2 系列）で、ロックファイルによってバージョンが固定されています。

• ?mcp=1 を指定しない場合、ローカル WebSocket MCP 接続は開始されません。WebMCP ツールは、対応している場合に自動的に登録されます。?webmcp=0 を指定すると無効になります。

• 配信と WebSocket は 127.0.0.1 に固定されています。2 つ目のタブからの接続は拒否されます。認証、リモートアクセス、マルチユーザー機能、アプリ内チャットは PoC の対象外です。

• ポート 4174 が使用中の場合、サーバーは起動メッセージを出力して終了します。手動で実行した npm run mcp と、AI クライアントから起動したサーバーを同時に実行しないでください。COOLING_PLANNER_PORT でポートを変更できます（ブラウザーは開いたページのポートに自動接続します）。stdio クライアントが切断されると、サーバーは自動的に終了します。

• 数式、係数、保存スキーマに変更はありません。

ブラウザー統合チェック：CHROMIUM_PATH を設定し、python3 -m pytest tests/e2e/test_mcp.py を実行します（実際の MCP stdio セッションを操作し、画面の変更を検証します）。

WebMCP：デプロイ済み画面を操作

デプロイ済みの両ブランチで、同じ WebMCP ツールを利用できます：英語版デモ と 日本語版デモ。 このページは、ライブの ProjectStore に対して 8 つの WebMCP ツール、get_state、edit、set_view、get_results、undo、describe_model、evaluate、compare_candidates を自動登録します。クエリパラメーターは不要です。登録後、画面に WebMCP ready と表示されます。これは、ローカルの Cooling Planner サーバーや WebSocket リレーがなくても、HTTPS でホストされたページで動作します。AI はブラウザー MCP に接続されたタブを操作します。リモートの Lambda MCP は、独立したステートレスな計算サービスです。

WebMCP は実験的な機能です。インストール済みの Chrome DevTools MCP がサポートするバージョンの Chrome（現在の設定ドキュメントでは Chrome 150 以降が必要です）を使用し、--enable-features=WebMCP を有効にしてください。MCP の --categoryExperimentalWebmcp カテゴリーを有効にしてください。Chrome DevTools MCP の設定とWebMCP デバッグガイドを参照してください。

Codex では、MCP 設定に別のエントリーを追加するか、同じブラウザーに対して 2 つの MCP を起動するのではなく、既存の Chrome DevTools エントリーを更新してください。

[mcp_servers.cooling_webmcp_browser]
command = "npx"
args = ["-y", "chrome-devtools-mcp@latest", "--categoryExperimentalWebmcp", "--chromeArg=--enable-features=WebMCP"]

この設定では、画面に表示される Chrome が起動します。既存の Chrome に接続する場合は、MCP の --browserUrl オプションを使用し、そのブラウザーの起動時に WebMCP を有効にしてください。--chromeArg は MCP が起動したブラウザーにのみ適用されます。WSL を使用する場合も含め、Codex プロセスと画面に表示されるブラウザー間で接続が機能している必要があります。Codex MCP の設定を参照してください。

MCP 設定を更新した後、Codex セッションを再起動してください。デプロイ済みの上記 URL を開き、ページの WebMCP ツールを一覧表示して、まず get_state を実行するよう指示します。次に、その応答に含まれる ID を使用して edit を実行し、{"sheet":"compare"} を指定して set_view を実行します。計算後に get_results を確認してください。calculating または null はゼロではありません。describe_model ではモデルの前提条件を確認できます。evaluate と compare_candidates は複製上で実行され、画面は変更されません。

set_view では、画面上のボタンと同じ All／Top／Side のフレーミングを使って 3D カメラも操作できます。

操作	set_view の引数
標準 3D、All	{"mode":"3d","realistic":false,"cameraPreset":"all"}
リアルな 3D、Top	{"mode":"3d","realistic":true,"cameraPreset":"top"}
Side	{"cameraPreset":"side"}
30°回転し、10°上向きに傾ける	{"orbit":{"azimuthDeg":30,"elevationDeg":10}}
バーンの長さ／幅に沿ってパンする	{"pan":{"xM":2,"zM":-1}}
ズームイン／アウト	{"zoomFactor":0.8} ／ {"zoomFactor":1.25}
カメラの距離を絶対値で設定する	{"camera":{"distance":30}}
2D	{"mode":"2d"}

カメラ操作には 3D が必要です。2D から切り替える場合は、同じ呼び出しに "mode":"3d" を含めてください。標準 3D とリアルな 3D のどちらでも操作できます。引数を組み合わせた場合は、プリセット、絶対値の camera、相対的な orbit、pan、zoomFactor の順に適用されます。相対的なジェスチャーは画面上の制限に合わせて調整されます。絶対値のカメラ角度（azimuth、elevation）はラジアン、相対的な軌道角度は度です。距離とターゲット [x,height,z] の単位はメートルです。get_state().view.camera で適用されたカメラを確認できます。これらの操作はモデル入力や Undo 履歴を変更せずにビューを再描画します。orbit の呼び出しを繰り返すとカメラは段階的に移動します。連続アニメーション用のツールはありません。

未対応のブラウザーでは WebMCP unavailable と表示され、エラートーストなしで通常の手動操作を引き続き利用できます。?webmcp=1 は、失敗時にトーストも表示する診断用の別名として引き続き使用できます。?webmcp=0 を指定すると、ツール登録とステータスバッジが明示的に無効になります。登録では、現在の document.modelContext API と以前の navigator.modelContext API の両方をサポートしています。生成されるオフライン配布物とスタンドアロン HTML にはアダプターが含まれていますが、想定されているブラウザー環境は HTTPS でデプロイされたサイトです。 実装の詳細、検証結果、手動の受け入れチェックリストについては、WebMCP implementation reportをご覧ください。

AWS へのデプロイ

実装計画：docs/AWS_DEPLOY_PLAN.md。Amplify Hosting（静的サイト。GitHub に接続し、main/english へのプッシュ時に自動デプロイ）＋ Lambda Function URL（REST およびリモート MCP）。リモート MCP は、ステートレスでブラウザーを使用しないバージョンです。ツールは get_default_project / evaluate / compare_candidates / describe_model / get_doc です（ローカル版と同じ操作語彙を使用します）。

リモート MCP への接続

以下を Kiro、Claude、またはその他の MCP クライアントに登録します。公開デモトークン demo-581fKusGqNgk7YrycFNw6M_5 は誰でも使用できます（悪用された場合はローテーションされます）。非公開の管理者トークンは aws/deploy.local.json（コミット対象外）の mcpBearerToken です。

{"cooling-planner-remote":{"type":"http","url":"https://puzxplbkg2qglia72tkhs2z7km0jrusa.lambda-url.us-east-1.on.aws/","headers":{"Authorization":"Bearer demo-581fKusGqNgk7YrycFNw6M_5"}}}

cd aws && npm ci && cd ..
npm run deploy:aws   # site build → Lambda bundle → cdk deploy (Lambda backend only)

デプロイ状態（Bearer トークン、URL）は aws/deploy.local.json（コミット対象外）に保存されます。必要に応じて、初回デプロイ時に CDK のブートストラップが自動で実行されます。サイトの公開は、GitHub に接続された Amplify アプリがプッシュ時に amplify.yml を使用してビルドすることで行われます。

保存形式

schemaVersion: 10。配置、屋根の条件、天候（固定値＋代表日の時間別データ）、係数、参照モデルの前提条件、デバイスごとの日次開始時刻、牛乳モデルの設定、表示設定を保存します。v8/v4 JSON は変換せずに拒否し、現在のシナリオを維持します。既存の v8 本文とデータは別途保持してください。

配置 JSON に加えて、トップレベルに project を含む MCP evaluate の応答 JSON も読み込みまたは貼り付けできます。project の配置、天候、係数、ベースラインを検証して復元し、画面上で再計算します。受信した結果とハッシュは、表示用として信頼されません。最大 2 MiB で、サポート対象のバージョンは schema 10 です（v9 は自動変換されます）。

「Results JSON」は、プロジェクトと計算結果をまとめた検証用ファイルです。2 MiB 以下であれば、その project を抽出して復元できます。ただし、結果が含まれているため、通常のデータ交換には配置 JSON または MCP 応答の project を使用してください。

利用可能な場合はデバイス上のストレージを使用しますが、初回起動時は必ず標準デモから始まります。「Settings & save」からデバイス上の保存データを復元してください。シナリオ JSON は、デバイス上のストレージを利用できない場合でも動作します。

エリアごとの可視化

標準 3D／リアルな 3D／2D

牛舎の上にあるタブで切り替えます。従来のレンダリングは「標準 3D」として引き続き利用でき、配置、選択ポイント、結果を共有します。 「リアルな 3D」では、鉄骨部材、ストール、床材、牛／装置の形状、照明、影が追加されます。追加のダウンロードは不要です。 立位と休息時の姿勢を、ホルスタイン種に似た体型と大きな斑点で描画します。50 頭の牛のうち 3 頭は、細霧器のある給餌エリアに配置されます。牛の位置と姿勢は見た目だけのもので、評価ポイントや占有設定は変わりません。

• 背景をドラッグすると回転し、ホイールを操作するとズームし、Shift+ドラッグまたは右ドラッグするとパンします。
• ファン／ノズルを選択してドラッグすると、「標準 3D」と同じ装置を編集できます。元に戻す操作は共有されます。
• 「風」では流れの筋が表示され、「噴霧」では細霧器の液滴／霧の粒子が表示されます。時間スライダーで ON／OFF 動作を確認できます。
• 「マップ」では既存の結果を床面に重ねて表示します。「解析」では牛を非表示にしてヒートマップを表示します。
• 「屋根」では屋根の片側を表示します。内部構造を確認できるよう、柱とトラスは表示されたままになります。

風は、ファンの向き、モデルの拡散／減衰、障害物に基づく模式的な表現です。粒子の軌跡は CFD ではありません。 粒子アニメーションは表示専用です。時間を進めたり、モデルの結果を書き換えたりすることはありません。 マテリアルと形状はコードで生成しています。フォトグラメトリでも、写真品質の牛モデルでもありません。 実装と検証の詳細については、リアルな 3D の実装記録を参照してください。

エリア別の暑熱／冷却可視化仕様 v0.1を実装しています。50 のストール、12 の給餌エリア、8 つの待機エリアの面を、冷却不足量（Qref に対する 1 秒ごとの積分平均）、熱損失の改善量、風速、気温に応じて色分けします。面または表の行をクリックすると、対応する代表ポイントが選択され、濡れ具合、熱損失の内訳、装置動作の診断が表示されます。各面に表示されるのは、その面全体に対する空間計算値ではなく、対応するポイントの代表値です。schemaVersion は 10 です。

モデルの適用範囲

• フリーストール型のテンプレート 1 種、ストール 50 個、独立した評価ポイント 70 個です。CFD ではなく、実際の牛舎における精度を保証するものではありません。
• 熱と水の計算では、基準ステップ 1 秒で 60 分間、固定した気象条件を使用します。再生では事前計算済みのサンプルを表示します。
• 1 日あたりの乳量は、代表日の条件を用いた別計算です。固定した気象条件を 24 時間繰り返し、24 時間のウォームアップ後に 24 時間の評価時間枠を集計します。装置ごとの 1 日あたりの開始時刻、稼働時間、ON／OFF サイクル、および深夜を越えて持ち越される水膜が含まれます。
• 体感気温、熱損失の改善量 W、乳量、受胎率は、それぞれ意味の異なる指標です。
• 1 日あたりの乳量は、milk-heat-deficit-v0.1（demo_assumption）に基づく群平均の参考値です。H=max(0,Qref−Q) を 70 ポイント、エリアごとの占有割合（14／6／4 時間相当）、時間にわたって重み付けし、遅延反映された E から Y=Y0−min(Y0×25%, beta×E) を計算します。係数は文献の回帰値ではなく、実際の農場での精度は検証されていません。
• 公表されている乳量表の対象は、静的条件における RH 60～70% の全酪連の公表条件 6 件のみです。掲載されていない値は null であり、補間や外挿は行いません。参考資料として保持されています。
• 受胎率は、5 期間の THI 区分と仮定した基準受胎率を用いて計算される参考シナリオです。初期値には、26 °C／RH 70% の独立した代表条件と 40% の基準受胎率を使用します。装置による受胎率全体の改善を自動的に算出するものではありません。
• 60 分間の平均値を授精前後の 52 日間の代表条件に適用するには、参考画面で明示的にチェックボックスをオンにする必要があります。ファン／細霧器の熱損失 W が THI に変換されることはありません。
• 期間ごとの THI を受け取る関数はありますが、最初の UI で設定できるのは、すべての期間で共有される代表条件のみです。

ファイルガイド

docs/IMPLEMENTATION_REPORT.md：再構築の意図、実装、数値結果、検証、残課題。

docs/DECISIONS_v0_8.md：統合時に確定した実装上の契約。

docs/REUSE_MAP.json：v0.4 とのファイルごとの比較と SHA-256。

docs/evidence-v08/：分割前の v0.8 実装に関するログ、画面、計算結果。

evidence/：テスト時の出力先。Git では追跡されません。

reference/：相互確認に使用する元の Python モデルと仕様。

examples/：読み込み可能なスキーマ 9 の配置例。

課題とスタンドアロンリポジトリ

• 反射コーティングモデルと牛乳の基準値に関する課題：評価結果、感度チェック、未実装の改善候補。
• スタンドアロンリポジトリへの分割：ファイルの抽出、独立したビルド／起動、Git の初期化手順。
• AGENTS.md：このスタンドアロン版で作業するエージェントの対象範囲と検証ルール。

MCP で構築したシナリオを画面で確認する

1. 既存の MCP evaluate を使って AI にシナリオを計算させます。日次リソースの照合には includeDaily: true を指定してください。
2. 「evaluate のレスポンスにある project を JSON ファイルにしてください」と依頼します。クライアントが添付ファイルを作成できない場合は、JSON 本文を取得してください。
3. ファイルを上部の「Load」から開くか、「Compare」／「Settings & save」内の「Import MCP scenario JSON」に本文を貼り付けます。レスポンス全体の JSON も使用できます。
4. 再計算後、選択したシナリオ、配置、天候、エリアごとの不足量、水、エネルギーを確認します。読み込むとすべてのシナリオと共有条件が復元され、「Undo」で読み込み前の状態に戻ります。無効な JSON を読み込んでも、現在のシナリオは維持されます。

比較の平均値は、代表地点 70 点の単純平均であり、群れの規模や収容率による重み付けはありません。最大不足量は、地点ごとの 60 分平均不足量の最大値です。「不足量が減少していない」とは、依然としてベースライン以上の不足量がある地点を指します。「局所的な対策なし」は、局所的な装置の動作に関する診断です（屋根の対策は除外）。地点の熱損失内訳の差は、複数装置を同時に計算することによるものであり、装置ごとの独立した寄与によるものではありません。

MCP シナリオの復元と比較の実装レポートに、このラウンドの検証範囲を記録しています。ソース／配布物の更新と、公開 AWS デプロイへの反映は別の作業です。

今回の手動確認（人間／CI）

1. MCP シナリオ JSON を「Import MCP scenario JSON」に貼り付け、配置と屋根の条件が反映されることを確認します。「Undo」で以前の状態に戻ることも確認してください。
2. 「Compare」で不足量の平均／最大値、停止／給餌／待機、水、エネルギーを確認します。不足量が最大の地点を押し、選択地点と熱損失内訳が切り替わることを確認してください。

専用 E2E は python3 -m pytest tests/e2e/test_mcp_comparison.py -v の 2 テストに限られます。エージェント側での実行は省略しています。