RoastPilot

Name: RoastPilot
Author: syamaner

ローカル

github.comゲーム・エンタメ02 週間前に更新

リポジトリ公式サイト

RoastPilot について

RoastPilotは、コーヒーロースターの制御、テレメトリー、焙煎セッション管理、ログ出力を行うローカルMCPサーバーです。運用者やエージェントのワークフロー向けに、モック対応モードとHottop制御、一爆検出の連携を備えています。

主な機能

01ロースター制御とセッションイベント
02ライブテレメトリーと焙煎指標
03一爆検出との連携
04T0イベントの自動処理
05JSONLとCSV形式の焙煎ログ出力
06モック対応のローカル動作

活用シーン

01焙煎セッションの制御と監視
02一爆や豆投入イベントの記録
03焙煎テレメトリーとセッション概要の出力
04ロースターなしでMCPワークフローをテスト

MCP 対応

ローカルstdio MCPツールで、焙煎セッション制御、状態とテレメトリー、一爆イベント、安全操作、ログ出力を提供します。既定のモック設定では、ロースター、マイク、モデルファイル、ネットワークなしでクライアントをテストできます。

設定

ローカルサーバーの設定はどのクライアントでも共通です。コピーしてクライアントの MCP 設定ファイルに貼り付けてください。

mcp.json · 共通設定

{
  "mcpServers": {
    "syamaner-coffee-roaster": {
      "command": "uvx",
      "args": [
        "coffee-roaster-mcp"
      ]
    }
  }
}

起動コマンドuvx coffee-roaster-mcp

ローカルサーバーにはマシン上の実行環境（Node.js 18 以上など）が必要です。設定ファイルの場所はクライアントごとに異なります。

パッケージ

pypicoffee-roaster-mcp0.2.4stdio

ツール

掲載時のツール一覧 · 2 週間前に更新

このツールにパラメーターはありません。

詳細

RoastPilot

RoastPilot は、コーヒー焙煎機のテレメトリと制御された動作のための MCP サーバーです。

パッケージ名は coffee-roaster-mcp です。本番用 PyPI で公開され、MCP Registry には io.github.syamaner/coffee-roaster-mcp として登録されています。

RoastPilot は、焙煎機の制御、テレメトリ、ファーストクラック検出との連携、焙煎指標、ログのエクスポートに対応するローカル MCP ランタイムを 1 つ提供します。

ステータス

✅ v0.1 のコンポーネント範囲が完了し、PyPI と MCP Registry で公開済みです。また、2026-08-16 までに、監督下でエージェントが制御するハードウェア焙煎で検証済みです。

最新の統合エビデンスは、2026-08-16 に完了した 2 回の Hottop 焙煎です。これらを通じて、リアルタイムのテレメトリと制御、自動 T0、ファーストクラックへの対応、ファーストクラック後の判断、安全性の評価、アドバイザーによるドロップのトリガー、オペレーターによる冷却完了の制御、周囲環境のセンシング、ログのエクスポート、およびペアマイクによる録音を検証しました。エージェントの台帳には、成功したアドバイザー判断が 19 件記録されており、それぞれが allow の安全性評価に紐付いています。アドバイザーが提案したドロップは両方とも実行され、完了したいずれの焙煎でも、コマンドイベントの失敗や安全アラートはありませんでした。

これらの焙煎では、固定された coffee-roaster-mcp 0.1.13 ランタイムを使用しました。バージョン 0.1.14〜0.1.16 はメタデータ／ドキュメントのリリースでした。公開 PyPI メタデータには 0.2.3 が記載されており、対応するリリースワークフローでは PyPI と MCP Registry への公開成功が報告されています。現在の MCP Registry の公開リストは独立して確認していません。これらは公開メタデータとワークフローの観測結果であり、公開成果物のバイト列、内容、タグの出所、インストール済みバイト列を独立して検証したものではありません。

リポジトリの 0.2.3 候補記録には、D209 の型付きの低温専用の温度およびパケットの射影と、#222 の焙煎ファン専用の低温セッションにおける get_roast_state の観測、ならびに PR #231 の停止状態の障害に対する、正確なセッションを対象とした復旧セマンティクスが含まれています。#222 の観測が報告するのは、指令された焙煎ファンの状態のみです。 D209 の射影は、テレメトリ、パケットの有効性とカウンター、生の温度情報および型付きの温度情報を報告します。パケット進捗のスクリーニングは、観測結果間のエージェントによる比較であり、継続的な鮮度監視やリンク監視ではありません。これらのソース記録と公開の観測結果は、物理的な動作、キャリブレーション、精度、継続的な鮮度、リンクの健全性、準備状況、または安全性を証明するものではありません。Issue #225 はリリースプロセスの調整のため未解決のままです。Issue #227 は D209 のソフトウェア射影に関してクローズされています。

公開中の現行タグのソース 3e40487686880825f93ae2015cc4253d9183623b と比べて、0.2.4 の新しいランタイム内容は S1 の遅延されたローカル SciPy 対称 Hann ウィンドウのインポートのみです。数値出力とインターフェースに変更はありません。バージョン文字列、ホイール名、または宣言されたコマンドラインのダイジェストは、意図したインタープリターがどのバイト列をインポートするかを証明しません。インストール済みバイト列の検証は別個のゲートであり、オペレーターの承認が必要です。このドキュメントは、いずれの配布についてもその検証を実施しておらず、実施したとは主張しません。0.2.4 の準備が完了しているのは、マージ済みの HEAD と公開を伴わないドライランの成功までです。タグの作成、保護された release 環境の承認、公開、公開成果物の実環境での検証は、引き続き人間のオペレーターが行う作業です。これはハードウェアや豆の使用、あるいは準備完了の主張を許可するものではありません。マージ後に、公開を伴わないドライランの成功を記録する必要があります。ここでは、保留中のドライランが成功したとは主張していません。

このパッケージに含まれる README の「ステータス」は、準備時点のスナップショットです。上記の現行ソースと公開メタデータの観測結果を記録したものであり、 0.2.4 の現在の公開状況を主張するものではありません。 D191で承認された制限は引き続き N = 1 および X = 200 ms であり、本番環境での致命的エラー連続発生数も引き続き 30 です。D190は人工音楽を使用したMCP専用のコンポーネント特性評価でした。オーバーフローが観測されなかったことは、他の条件で余裕があることを示すものでも、ゼロではない許容値が必要であることを証明するものでもありません。サニタイズ済みのレビューでは非公開の証拠を再検討しておらず、検出器、ライブ焙煎、フルスタック、または複合的な受け入れ評価ではありません。D192のフルスタック30+30と、これとは別の監督下での20分以上のライブ焙煎は、引き続き未完了です。#157と#194は引き続きオープンです。公開は、マージ、リリースワークフローのドライランの成功、および保護された環境での承認を経た後に限り、引き続きオペレーターのみが実施します。権限台帳、セッション、周囲環境、キャプチャの証拠と、その出所に関する制限については、 2026-08-16のエージェント焙煎検証レポートを参照してください。

最初に公開されたパッケージのベースラインは、引き続き2026-06-07の検証です。

公開済みの coffee-roaster-mcp 0.1.3パッケージをMCP Registryのuvx経由でWarpエージェントにインストールし、接続されたHottop KN-8828B-2K+で監督下の焙煎を2回完了しました。シリアル、制御、テレメトリーの障害は発生しませんでした。

検証項目	結果
インストール経路	実際のMCPクライアント（Warp）で`uvx`経由の公開PyPI 0.1.3を使用
ハードウェア制御	ドライバー経由のMCPツールを通じた加熱／ファン／ドロップ／冷却のライブ制御
自動T0	豆温のチャージによる低下から検出された`beans_added`（`source: auto_t0`）
1ハゼ検出	実際のUSBマイクで、リリース済みINT8 ONNXモデルが音声からライブ検出 — スライディングウィンドウによる確認、信頼度0.907（しきい値0.6超）、5/5のウィンドウで陽性
安全アクション	同日に実施した保護付きの`hottop-validate`実行で、ドロップと緊急停止を含む8/8ステップに合格
ログのエクスポート	完全な1ハゼおよび自動T0のメタデータを含む`roast.jsonl`、`roast.csv`、`summary.json`

証拠：

焙煎当日の検証レポート（両方の焙煎についての正式な合否分析）
焙煎#1のテスト概要および焙煎#2の自動検証概要（タイムライン、指標、スクリーンショット）
コミット済みの成果物（焙煎ログ、保護付き検証のJSON、トランスクリプト、スクリーンショット、チェックサム）

計画と状態の履歴については、v0.1全体計画およびプロジェクト状態レジストリを参照してください。

RoastPilot とは

RoastPilot はユーザー向けの製品名です。coffee-roaster-mcp は、このリポジトリ、Python パッケージ、および公開ディストリビューションで使用されるインフラストラクチャとパッケージングの名称です。

v0.1 のスコープは、以下を担う単一のローカル stdio MCP サーバーです。

ロースターの制御
焙煎セッションのタイミングとイベント
1ハゼ検出との連携
派生焙煎指標
焙煎ログのエクスポート

MCP コンポーネントの v0.1 エピックはすべて完了し、実機での検証も済んでいます。パッケージのスキャフォールド、設定の読み込み、ローカル開発コマンド、プルリクエスト CI、stdio MCP エントリーポイント、焙煎セッションのツール群、Hottop ドライバー、音声による1ハゼ検出のランタイム、自動 T0 の経路、指標とログのエクスポート、リリースワークフロー、MCP Registry のメタデータが整備されています。また、公開パッケージを通じて、接続された Hottop 実機と実際のマイクを使ったエンドツーエンドの全経路を検証済みです（E7-S6）。

インストール

現在のローカル開発では、次を使用します。

python3.11 -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip
python -m pip install -e . --group dev

ユーザー向けのインストール対象は、公開済みの coffee-roaster-mcp パッケージです。

python -m pip install coffee-roaster-mcp

モックのインストール、Hottop の設定、Hugging Face モデルの設定、オフラインモデルのパス、ログの出力先など、オペレーター向けのセットアップについては、インストールとハードウェアのセットアップガイドを参照してください。

ローカル開発

セットアップ

インストールセクションのコマンドを使用し、以下のチェックに進んでください。

テスト

python -m pytest

カバレッジ

python -m pytest --cov=coffee_roaster_mcp --cov-report=term-missing:skip-covered --cov-report=html:htmlcov --cov-report=json:coverage.json
python .github/scripts/write_coverage_summary.py coverage.json

プルリクエスト CI は、Checks ジョブのサマリーに Markdown 形式のカバレッジ概要を公開し、ファイル単位で詳細を確認できるよう、ワークフロー成果物として html-coverage-report をアップロードします。

Lint

python -m ruff check .

フォーマットチェック

python -m ruff format --check .

型チェック

python -m pyright

CLI スモークテスト

coffee-roaster-mcp --help
coffee-roaster-mcp --version

ハードウェアと音声のチェック

焙煎を開始せずに、設定済みマイクと独立した複数デバイスの録音経路を確認する、明示的な焙煎前チェックが2つあります。

coffee-roaster-mcp mic-check --config coffee-roaster-mcp.yaml
coffee-roaster-mcp record-check --config coffee-roaster-mcp.yaml

mic-check は、選択した入力に実際の信号が含まれているかを報告し、簡易な JSON 証跡レコードを書き出すことができます。record-check は、設定済みの各録音デバイスで一時ディレクトリまたは明示的に指定した出力ディレクトリに録音し、結果を報告します。録音された音声には周囲の会話が含まれる場合があるため、コミットしないでください。

ローカルモック実行

デフォルトのローカル実行経路は、意図的にモックで安全に動作するようになっています。

デフォルトのロースタードライバー：mock
デフォルトの1ハゼ検出モード：disabled
ロースターのハードウェアは不要
マイクは不要
モデルのダウンロードは不要

RoastPilot には現在、モックで安全に動作する焙煎セッションのツール群を備えた、ローカル stdio MCP サーバーのエントリーポイントがあります。デフォルト設定では、ロースターのハードウェア、マイク入力、モデルファイル、ネットワークアクセスなしで、MCP クライアントが焙煎を開始し、制御を調整し、デバイスとセッションの現在の状態を読み取り、明示的なオーバーライドイベントを記録し、豆を冷却工程に移し、スナップショットログをエクスポートできます。

ローカル MCP サーバーの起動

coffee-roaster-mcp serve

現在の MCP ツール群は次のとおりです。

get_server_info
get_runtime_config
start_roast_session
get_roast_state
set_heat
set_fan
mark_beans_added
mark_first_crack
drop_beans
start_cooling
stop_cooling
export_roast_log
emergency_stop
set_recording_metadata
finalise_cold_characterisation_session

ポーリングごとの低温特性評価の観測

get_roast_state.cold_characterisation_observation は、purpose="cold_characterisation" のセッションでのみ意味を持ちます。利用側は session_purpose に基づいて使用可否を判定する必要があります。これは、指令されたロースターファンのレベルを、型付きの読み取り専用観測値として報告します。物理状態、リンク、鮮度の証明ではなく、device_state とのアトミック性もありません。また、熱、メインファン、冷却の状態を重複して示すものでもありません。

コールドキャラクタリゼーションの終了処理

finalise_cold_characterisation_session は、purpose="cold_characterisation" を指定して開始された、アクティブな最新セッションを終了するための、機器を作動させないツールです。通常の焙煎には使用しません。既知の接続済み安全ゼロ状態のドライバー証拠のみを受け入れたうえで、サンプリングとキャプチャを停止し、記録アーティファクトを検証してから切断します。 clean は、すべてのステージが完了した（または該当しなかった）、切断が確認された、かつ最終的なドライバー証拠が安全ゼロ状態のままであることを意味します。partial と disconnect_indeterminate では、後で再試行できるよう証拠が保持されます。これは、いかなる準備状態も保証するものではありません。 D195 の完全な安全ゼロエンベロープは、引き続き終了処理専用です。終了処理が完了しても、セッションフェーズは変わりません。完了をフェーズから推測せず、利用側では active と session_active_after を使用する必要があります。 completed_not_clean は、準備状態や安全性を確認するものではありません。新しいセッションを開始する前に調査してください。

export_roast_log は、現在のプロセス内セッションの roast.jsonl、roast.csv、summary.json ファイルを書き出します。焙煎中は、ランタイムイベントとサンプリングされたテレメトリも roast.jsonl に追記されます。

記録付きの焙煎を行う前に、set_recording_metadata で、キャプチャのファイル名とセッションサイドカーに使用する豆の産地スラッグと焙煎番号を保存します。ハードウェアコマンドは送信せず、汎用的なファイル書き込みやツール実行の機能も公開しません。

運用 MCP フロー

モックを安全に使う Claude／オペレーターのフローは次のとおりです。

start_roast_session を呼び出して、アクティブな焙煎セッションを 1 つ作成し、設定済みのドライバーに接続します。
運用上の判断に応じて、set_heat と set_fan を呼び出します。これらのツールは、設定済みの RoasterDriver 境界を介して動作します。デフォルトのモックドライバーは、ローカルで決定論的に動作します。
get_roast_state を呼び出して、権威あるセッション状態と、現在の設定済みデバイスの状態を読み取ります。レスポンスには、ドライバー ID、接続状態、取得可能な場合は豆と環境の温度、火力／ファンのレベル、冷却状態、安全な生の診断情報、T0 の状態、1 ハゼの状態、豆投入、1 ハゼ、豆のドロップ、冷却開始、冷却停止のライフサイクルタイムスタンプが含まれます。
通常のドロップコマンドとして drop_beans を使用します。モック経路と Hottop の複合ドロップ経路では、これにより beans_dropped が記録され、ドライバーが冷却中と報告した場合は cooling_started も記録され、火力がオフになり、ファンが 100% に設定され、冷却フェーズに入ります。
冷却が完了したら、stop_cooling を使用します。start_cooling は、通常の焙煎フローで drop_beans の後に使うものではなく、明示的な高度な手動復旧ツールとして引き続き利用できます。加熱済みのモックリハーサルでは、その後、安全なゼロ状態での最終処理を行う前に、空のドロップ／冷却／冷却停止のフローを経て set_fan(0) を呼び出す必要があります。

mark_beans_added と mark_first_crack は、明示的なオーバーライドツールです。オペレーターによる復旧や、制御された手動運転のために利用可能な状態が維持されています。主な自動実行経路は内部処理です。session.auto_t0_detection_enabled が有効な場合、自動 T0 検出によって beans_added を記録できます。また、first_crack.mode: audio が意図的に設定されている場合、音声モードでの1ハゼ確認は、セッションが所有する1ハゼランタイムが担います。

自動 T0 はデフォルトで無効です。有効にすると、get_roast_state は設定済みのドライバーを読み取り、T0 前の豆の最高予熱温度を追跡し、現在の豆の温度がその最高値から session.auto_t0_drop_threshold_c 以上低下した時点で beans_added を記録します。自動 T0 によってイベントが記録されると、get_roast_state.t0_status に設定済みのしきい値、追跡中の投入温度、現在の温度低下幅、検出された豆の温度が示されます。

オプションの周囲温度センシングと焙煎録音も、デフォルトでは無効です。意図的に有効にすると、get_roast_state でフェイルソフト方式の Yoctopuce 周囲温度測定値と、マイク／オーバーフローのライブ状態を確認できます。また、録音ランタイムでは、セッション単位のディレクトリに 1 つ以上の独立したマイクストリームを録音できます。録音では音声による1ハゼ検出のキャプチャランタイムを使用するため、first_crack.mode: audio が必要です。焙煎中のライブ録音には、audio.source: microphone に加え、recording.enabled と recording.autocapture の両方を true に設定する必要があります。recording.devices が設定されている場合、最初のエントリは audio.input_device と一致している必要があります。このストリームは検出器によってキャプチャされ、独立して開かれるのではなく、最初の WAV ファイルにも分岐して書き込まれます。追加のエントリは、独立した録音ストリームとして開かれます。これらの経路は、現在の検証レポートに記載された 2026 年 8 月のハードウェア焙煎で、組み合わせて動作確認されています。

get_roast_state.first_crack_status.status の値は次のいずれかです。

disabled：1ハゼ検出は無効で、1ハゼイベントも存在しません。
manual：手動の1ハゼモードが設定されており、オーバーライドツールが利用可能です。
pending：音声検出が設定され、確認済みイベントを待機しています。
detected：権威あるセッションタイムラインに1ハゼイベントがあります。
faulted：検出器ランタイムまたはセッションで障害が発生しています。
unavailable：設定、アーティファクト、音声キャプチャ、または手動オーバーライドの設定により、1ハゼ検出を利用できません。

モック安全性を確認するブートストラップスモークテスト

このモック安全性を確認するブートストラップスモークテストを使い、確実に空の一時ディレクトリから、デフォルトのローカルパスがハードウェアもモデルも不要な状態を維持していることを確認します。

python -c "import os, tempfile; from coffee_roaster_mcp.config import load_config; tmp = tempfile.TemporaryDirectory(); os.chdir(tmp.name); c = load_config(environ={}); print(c.roaster.driver, c.first_crack.mode, c.first_crack.precision); tmp.cleanup()"

期待される出力：

mock disabled int8

これにより、ブートストラップのデフォルト設定が引き続きモックの垂直スライス計画に沿っていることを確認できます。

Hottop の設定と検証

簡潔なセットアップ手順については、インストールとハードウェアのセットアップガイドを参照してください。このセクションでは、ガード付き検証ワークフローを要約します。

Hottop のサポートはRoasterDriver抽象化の背後にあります。このドライバーは、ライフサイクル、コマンドループ、パケット、制御状態、温度単位をサポートしており、接続したハードウェアでの全ガード付き検証（ドロップと緊急停止を含む）に合格しています。直近では2026-06-07に公開済みの0.1.3 PyPI パッケージを使って検証し、その後、MCP ツール経由で監督下におけるライブローストを2回完了しました。新しいハードウェア構成を操作する前には、ガード付きの手動検証を必ず実施してください。

設定はcoffee-roaster-mcp.yamlに記述します。接続した Hottop ハードウェアを意図的に検証する場合を除き、ローカル開発ではモックドライバーを使用してください。

roaster:
  driver: mock
  port: null
  baudrate: 115200
  temperature_unit: celsius
  command_interval_seconds: 0.3

ガード付きハードウェア検証では、driverをhottop_kn8828b_2k_plusに切り替え、シリアルポートを明示的に設定し、エビデンスの出力先を指定して検証ハーネスを実行します。

coffee-roaster-mcp hottop-validate \
  --config coffee-roaster-mcp.yaml \
  --output docs/validation/hottop-e3-s9-non-destructive.json \
  --i-understand-this-controls-hardware

不可逆操作と安全動作のチェックは、オプトインで実施します。

coffee-roaster-mcp hottop-validate \
  --config coffee-roaster-mcp.yaml \
  --output docs/validation/hottop-e3-s9-full.json \
  --i-understand-this-controls-hardware \
  --include-drop \
  --include-emergency-stop

ここではハードウェアの安全性が重要です。コマンドループの間隔、パケット処理、温度単位、ドロップ動作、冷却動作、緊急停止、クリーンアップについては、Hottop の経路をリリース可能と判断する前に、監督下のロースターで検証する必要があります。現在の MCP ローストセッション用ツールは設定されたドライバーの境界を呼び出すため、ガード付き Hottop 検証の実行を明示的に意図している場合を除き、通常の開発ではモックドライバーを使用してください。

Hottop のオプションのライブ MCP 検証は、ゲート付きの手動作業です。監督下のロースター、明示的なhottop_kn8828b_2k_plus設定、既知のシリアルポート、明確な停止計画が揃っている場合にのみ実行してください。合格を示すエビデンスとして、MCP クライアントが1つのセッションを開始し、熱量とファンを設定し、妥当な温度を含む接続デバイスの状態を読み取り、drop_beansを呼び出してドロップと冷却を開始し、get_roast_stateからbeans_droppedとcooling_startedのタイムスタンプを読み取り、ロースターが冷却停止を報告した時点で冷却を停止し、障害が発生した場合はそれをフォールトイベントとして記録できる必要があります。シリアル通信、テレメトリー、コマンドループ、安全性に少しでも不確実な点があれば、検証は不合格として扱い、通常の CI では必須にしないでください。

設定

RoastPilot は、デフォルトでカレントディレクトリにあるcoffee-roaster-mcp.yamlから設定を読み込みます。ファイルが存在しない場合は、モック安全性を考慮したデフォルト設定が使われるため、ローカル開発にロースターハードウェア、オーディオハードウェア、モデルのダウンロードは不要です。

モックインストール、Hottop の設定、Hugging Face モデルの設定、オフラインのモデルパス、ログの出力先など、セットアップを中心とした例については、インストールとハードウェアのセットアップガイドを参照してください。

transport:
  type: stdio

roaster:
  driver: mock
  port: null
  baudrate: 115200
  temperature_unit: celsius
  command_interval_seconds: 0.3

first_crack:
  mode: disabled
  repo_id: syamaner/coffee-first-crack-detection
  revision: null
  precision: int8
  local_model_dir: null
  onnx_threads: 2
  confidence_threshold: 0.9
  min_positive_windows: 1
  confirmation_window_seconds: 20.0
  allow_manual_override: true

audio:
  source: microphone
  input_device: null
  sample_rate: 16000
  wav_path: null
  replay_mode: realtime
  window_seconds: 1.0
  overlap: 0.0
  hop_seconds: null

ambient:
  mode: disabled
  device: null
  poll_interval_seconds: 30.0

recording:
  # Recording runs through the audio first-crack capture runtime.
  # Live capture also requires first_crack.mode: audio and audio.source: microphone.
  enabled: false
  autocapture: false
  export_location: null
  sample_rate: null
  # When set, the first entry must match audio.input_device.
  devices: null

logging:
  log_dir: ./logs
  sample_interval_seconds: 5.0
  export_formats:
    - jsonl
    - csv
    - summary

session:
  auto_t0_detection_enabled: false
  auto_t0_drop_threshold_c: 25.0
  ror_window_seconds: 60
  ror_min_sample_seconds: 10

サポートされている環境変数による上書き設定：

COFFEE_ROASTER_MCP_CONFIG
COFFEE_ROASTER_DRIVER
COFFEE_ROASTER_PORT
COFFEE_ROASTER_TEMP_UNIT
COFFEE_FIRST_CRACK_MODE
COFFEE_FIRST_CRACK_REPO_ID
COFFEE_FIRST_CRACK_REVISION
COFFEE_FIRST_CRACK_PRECISION
COFFEE_FIRST_CRACK_LOCAL_MODEL_DIR
COFFEE_FIRST_CRACK_ONNX_THREADS
COFFEE_FIRST_CRACK_CONFIDENCE_THRESHOLD
COFFEE_FIRST_CRACK_MIN_POSITIVE_WINDOWS
COFFEE_FIRST_CRACK_CONFIRMATION_WINDOW_SECONDS
COFFEE_AUDIO_SOURCE
COFFEE_AUDIO_INPUT_DEVICE
COFFEE_AUDIO_SAMPLE_RATE
COFFEE_AUDIO_WAV_PATH
COFFEE_AUDIO_REPLAY_MODE
COFFEE_AUDIO_WINDOW_SECONDS
COFFEE_AUDIO_OVERLAP
COFFEE_AUDIO_HOP_SECONDS
COFFEE_AMBIENT_MODE
COFFEE_AMBIENT_DEVICE
COFFEE_AMBIENT_POLL_INTERVAL_SECONDS
COFFEE_RECORDING_ENABLED
COFFEE_RECORDING_AUTOCAPTURE
COFFEE_RECORDING_EXPORT_LOCATION
COFFEE_RECORDING_SAMPLE_RATE
COFFEE_RECORDING_DEVICES
COFFEE_ROAST_LOG_DIR
COFFEE_AUTO_T0_DROP_THRESHOLD_C
HF_HOME

audio.sourceにはmicrophoneまたはwavを指定できます。マイク入力の取得にはPortAudioベースのsounddeviceストリームを使用し、macOS、Linux、Raspberry Piのホストで設定したデバイス識別子をオーディオ入力境界の内側に保持します。WAVの再生にはPCM .wavファイルを使用し、チャンネルをマイク入力と同じモノラル浮動小数点サンプルの形式に変換します。また、ファイルのサンプルレートはaudio.sample_rateと一致している必要があります。WAVの再生では、デフォルトでバックグラウンドのrealtime取得パイプラインを使用します。ローカルのラベル付きフィクスチャを検証するには、audio.replay_mode: detector_pacedと、検出器に適合するaudio.window_secondsおよびaudio.overlapまたはaudio.hop_secondsを設定します。これにより、壁時計による待機や通常のキューのドロップなしで、検出器／ランタイムの準備ができ次第、WAVの各ウィンドウ全体を処理します。

通常、このリポジトリにオーディオはコミットされません。現時点で唯一の例外は、tests/fixtures/audio/にある小さな派生E7-S5aラベル付き再生フィクスチャです。このフィクスチャはトリミング、リサンプリング、タイムスタンプの再設定が行われ、マニフェストで説明されています。生の録音、広範なトレーニング／評価用オーディオ、モデルアーティファクト、焙煎ログ、シリアルキャプチャは、引き続きgitの対象外です。

リリース済みモデルを使ったラベル付き再生の検証は、オプトインのローカル検証であり、デフォルトのCIスイートには含まれません。

./.venv/bin/python scripts/validate_first_crack_wav_replay.py

このスクリプトは、ピン留めされたINT8 Hugging Faceアーティファクトと検出器ペースのWAV再生を使用して、モック焙煎機上でstdio MCPサーバーを起動します。その後、公開MCPツールを使って、フィクスチャのラベルに対するファーストクラック検出を検証し、roast.jsonl、roast.csv、summary.jsonをエクスポートします。

マイク入力を取得する際、audio.input_device: nullを設定すると、システムのデフォルト入力デバイスが使用されます。特定のマイクを指定するには、audio.input_deviceにPortAudioで解決可能なデバイス名またはプラットフォームのデバイス識別子を設定します。LinuxおよびRaspberry Piでは、arecord -lとarecord -Lを使ってALSAデバイスを確認できます。plughw:1,0などの値は、ALSAによるフォーマット変換が可能なため、未加工のhw:1,0よりも柔軟に動作することがよくあります。macOSでは、システムのサウンド設定を使うか、手動検証時にsounddeviceのデバイス一覧を確認してください。実際のマイクを使った確認は任意であり、first_crack.mode: audioとaudio.source: microphoneを意図的に設定した場合にのみ実施してください。

実際のマイクを使った任意の検証は、手動で行う作業です。実行前に、リリース済みのHugging Face ONNXアーティファクトまたは検証済みのfirst_crack.local_model_dirを設定し、使用するマイクを選択して、アーティファクトやオーディオ取得のエラーなしにMCPプロセスが起動できることを確認してください。検証に合格したことを示す証拠として、監視下での焙煎または制御された再生中にget_roast_state.first_crack_statusがpendingからdetectedへ変化すること、記録されたfirst_crack_detectedイベントに検出器のメタデータが含まれること、通常の焙煎制御が引き続き動作することが求められます。アーティファクトの欠落、利用できないオーディオデバイス、検出器の障害は、unavailableまたはfaultedのステータスとして表面化する必要があり、通常のCIの対象外としてください。 HF_HOME は RoastPilot の設定オブジェクトにコピーされるのではなく、Hugging Face のツールによって直接使用されます。

Hugging Face モデルの境界

このリポジトリでは、ファーストクラックモデルのトレーニング、エクスポート、同期、公開は行いません。

coffee-first-crack-detection リポジトリが引き続き以下の信頼できる情報源です。

モデルトレーニング
ONNX エクスポート
Hugging Face アーティファクトの公開
モデルカード
データセットカード

RoastPilot は syamaner/coffee-first-crack-detection のリリース済みアーティファクトのみを使用します。このリポジトリの実行時の対象範囲は、推論時の設定とモデル選択であり、モデルのライフサイクル管理ではありません。

現在のファーストクラックのデフォルト設定は、ローカル開発で安全に使えるようにしています。

mode: disabled
precision: int8
repo_id: syamaner/coffee-first-crack-detection

このデフォルト設定により、オーディオモードを意図的に設定するまで、ローカルのセットアップで Hugging Face ネットワークにアクセスする必要はありません。 first_crack.mode: audio を意図的に設定すると、RoastPilot は ONNX Runtime でリリース済みの ONNX アーティファクトを使用し、MCP が管理する NumPy/SciPy MelFrontend でリリース済みの AST プリプロセッサ設定を処理します。モデルのトレーニング、エクスポート、Hub への公開は引き続きこのリポジトリの対象外です。

オーディオモードでは、焙煎セッションの開始時に、設定済みのオーディオキャプチャパイプラインとリリース済みアーティファクトを使う検出ランタイムが準備されます。検出ウィンドウの処理は、T0 が記録され、アクティブなセッションが roasting になった後にのみ行われます。検出結果が確定すると、正規のセッションタイムラインを通じて first_crack_detected が一度だけ記録されます。ファーストクラックが自動的に記録された場合、または明示的な手動オーバーライドによって記録された場合、さらにドロップ、冷却完了、緊急停止、プロセスのシャットダウン時にも、ランタイムは停止します。アーティファクトの欠落、オーディオキャプチャの利用不可、検出エラーは、通常の焙煎操作をクラッシュさせるのではなく、get_roast_state.first_crack_status に unavailable または faulted として示されます。無効モードと手動ファーストクラックモードでは、オーディオキャプチャも検出ランタイムも開始されません。

ログのエクスポート

RoastPilot は現在、進行中のプロセス内セッションを対象とする export_roast_log によるスナップショットのエクスポートをサポートしています。

現在のエクスポートファイル：

roast.jsonl：焙煎中の追記専用イベントおよびサンプリングされたテレメトリの行
roast.csv：タイムスタンプ、経過秒数、フェーズ、温度、制御、イベントフラグ、現像率、RoR／デルタ指標、ファーストクラックモデルのメタデータに関する計画済みの CSV 列を使用した、テレメトリとイベントの行
summary.json：セッションのタイムスタンプ、焙煎の合計秒数、現像指標、ロースターのドライバー、ファーストクラックモデルのメタデータ
出力先：logs/roasts/{session_id}/

形式をまたいだログスキーマの完全性テストを実施しています。2026 年 6 月の公開パッケージベースラインと、2026 年 8 月のエージェントによる統合焙煎レポートに、現在の実環境での検証範囲を記録しています。新しいハードウェア構成には、それぞれ監督下での検証が必要です。

Markdown 対応

ログインしてコメント

基本情報

作者: syamaner
言語: python
バージョン: 0.2.4
トランスポート: stdio
掲載日: 2026年10月13日
最終更新: 2 週間前
公式 Registry: io.github.syamaner/coffee-roaster-mcp

問題を報告

MCP は初めてですか？

プロトコルの概要から最初のサーバーの導入まで、よくある疑問にまとめて答えます。

入門ガイドを読む

AI アプリケーションが外部のツールやデータソースに統一的な方法で接続するためのオープンなプロトコルです。クライアントはモデルとの対話を担い、MCP サーバーはツール・リソース・プロンプトテンプレートを提供します。標準メッセージでやり取りするため、1 つのサーバーを複数のクライアントで再利用できます。

RoastPilot

RoastPilot について

主な機能

活用シーン

MCP 対応

設定

ツール

詳細

RoastPilot

ステータス

関連するプロジェクト成果物

RoastPilot とは

インストール

ローカル開発

セットアップ

テスト

カバレッジ

Lint

フォーマットチェック

型チェック

CLI スモークテスト

ハードウェアと音声のチェック

ローカルモック実行

ローカル MCP サーバーの起動

ポーリングごとの低温特性評価の観測

コールドキャラクタリゼーションの終了処理

運用 MCP フロー

モック安全性を確認するブートストラップスモークテスト

Hottop の設定と検証

設定

Hugging Face モデルの境界

ログのエクスポート

コメント

MCP は初めてですか？

MCP（Model Context Protocol）とは？

MCP サーバーとクライアントの違いは？

ローカルとリモート、どちらを選ぶべき？

Claude や Cursor にサーバーを導入するには？

掲載プロジェクトは審査されていますか？「認証済み」とは？

自分のプロジェクトが掲載されています。どう申請できますか？