触れない実機で開発する — 希少な実機時間をどう使うか

はじめに

2026年7月2日、日本科学未来館で開かれた LADEC 2026 で、実験ロボットを自然言語で操作するデモを3本、実機のライブ動作として実施した。テカンジャパン様の協力を得て開発したもので、対象はテカン社の分注ロボット Cavro® Omni Flex である。試薬や検体を決められた場所へ決められた量だけ吐出する、アームとピペットを持った装置だ。デモ3本の内容と当日の様子は Science Aid のブログに記録した（実験機器を動かすAIエージェント）。

このプロジェクトで最も希少だったのは、実機に触れられる時間である。機器は川崎のオフィスにあり、私が使っている間は他の人が使えない。開発日として触れられたのは5日だけだった。しかも物理の機械は速くならない。アームは決まった速度で動き、液体は決まった速さでしか流れないので、ソフトウェアのように並列化や高速化で試行回数を稼げない。

時間そのものを増やせないなら、1日あたりの前進を増やすしかない。この記事は、そのために何をしたかの記録である。方法は3つあった。分厚い仕様書を触れない時間にコードへ移すこと、モックサーバーを作って実機時間をすり合わせに使うこと、そして応答待ちの時間を削ること。

エージェントの設計そのもの（何をLLMに任せ、何をプログラムに閉じたか）は別の記事に分けた。→ LLMに計算させるな

実機でしか確かめられないことだけに、実機を使う

実機がない大半の時間は、機器がどう振る舞うかを推測しながら作ることになる。そして実機に触れる日に、その推測が合っていたかを確かめる。開発はこの繰り返しである。

だとすれば、先に決めるべきことがある。実機の日にしか確かめられないことは何か。 ここを取り違えると、資料を読めば決まることを実機の前で確かめてしまう。

区分	例
資料を読めば決まること（実機は不要）	命令の書き方、引数の数と種類、数値の取りうる範囲
動かしてみないと決まらないこと（実機が必要）	エラーとして実際に返ってくる値、機器の状態によって変わる挙動、容量とポンプの動作量の対応

この切り分けに意味があるのは、実機時間は希少で、実機なし時間は潤沢という非対称性があるからだ。資料で決まることを実機の前に作り切るほど、実機1日あたりの前進が大きくなる。以下の3つは、すべてこの切り分けから出てくる方法である。

① 分厚い仕様書は、触れない時間にコードへ移す

機器の仕様は資料として共有いただいた。ただし分量がある。オペレーターマニュアルが504ページ、ポンプのマニュアルが152ページ、設定ツールのマニュアルが60ページ。合わせて700ページを超える。コマンド体系、座標系、エラーコード、ポンプの仕様がここに入っている。

これを実機に触れない時間に読み解いた。Claude Code にマニュアルとサンプル実装を読ませ、必要な仕様を素早く把握する。全コマンドを人間が覚える必要はない。

重要なのはその次で、読み解いた結果をコードに変換して残した。命令の文法だけを抜き出し、713行の構造化データにした。コマンドごとに、名前・動作の要約・引数の種類・値の取りうる範囲が入っている。機台ごとに変わる値（軸の割り当て、較正済みの可動域、シリンジ容量）はここに書かず、別のファイルに分けた。

こうしておくと、以後誰もPDFを読まなくて済む。モックサーバーはこのカタログを見て書式を検証する。エージェントに渡すのも動詞の一覧だけで、マニュアルは渡さない。もし実機の前で「この命令の書式は何だったか」をそのたびにLLMへ調べさせていたら、分厚いPDFを毎回読み込ませることになり、応答は遅く、費用も嵩み、しかも間違いが混じる。

調査そのものはLLMに任せられる。だが調査結果をコードとして固定するかどうかは設計の判断で、ここを省くと、実機の前で毎回同じ調査を繰り返すことになる。

（この「決まっていることをコードに固定してLLMに渡すものを小さくする」という判断は、エージェント本体の設計でも中心になった。→ LLMに計算させるな）

② モックサーバーを作り、実機時間はすり合わせに使う

実機の代わりに命令を受け取って応答を返すモックサーバーを用意した。接続先をこちらへ差し替えれば、機器が手元になくてもエージェント側から見れば実機につないでいるのと同じ状態で開発とテストができる。

初日の実機は、デモを作るためではなくこのモックサーバーを作るために使った。どんな命令に機器がどう応答するかを観察して、手元に持ち帰る。

これが本番前の詰めを支えた。最後の1週間は手元で通しを繰り返し、デモ2本とも計画から実行まで5回試して5回成功、うち1本は5回とも生成される命令列が完全に一致している。ただし、そこまで使えるものにするには条件があった。

必要だったのは、モックではなくシミュレータだった

一般的なモックは、外部依存の代わりに決めた応答を返すものだ。データベースやAPIを本物で呼ぶと遅く不安定なので、偽物に差し替える。このとき検証したいのは呼び出す側のコードで、モックは決められた答えを返す役でよい。想定外の呼び出しが来たときどうするかは、あまり問題にならない。

今回は逆だった。検証したいのはモックに渡される命令そのものである。LLMが組み立てたコマンド列が実機で通るかを知りたい。だからモックが「成功」と返せば、それはそのまま「この命令は正しい」という判定になる。モックの応答が、評価結果そのものになるのだ。

つまり必要だったのは、決められた答えを返すものではなく、実機と同じ基準で受理・拒否を判定するもの——つまりシミュレータである。実機が拒否する命令は、こちらも拒否しなければならない。そうでなければ、手元で「通った」ことに何の意味もなくなる。呼び方はモックサーバーのままだが、中身はそういうものになった。

そこで、資料を読めば決まること——命令の書き方、引数の数、数値の範囲——をモックサーバー側で検証し、実機と同じようにエラーを返すようにした。判定の基準には①で作ったカタログを使う。

逆に、再現しないものは大胆に切る

とはいえ、機器の振る舞いを丸ごと再現するのは無理である。同じ命令でも、それまでに何をしたかで結果が変わるからだ。チップを装着したあとにもう一度装着しようとすれば機器は拒否するし、すでに取った穴へ取りに行っても、そこにはもう何もない。同じ「チップを取れ」が、それまでの操作しだいで成功にも失敗にもなる。しかも、どの穴を使ったかを機器は覚えていない。作業を進めるほど状態は変わり、それを持っているのはこちら側だけである。だから命令ごとに応答を記録しても足りず、状況との組み合わせを持つことになるが、それは現実的な数に収まらない。

そこで網羅を諦めた。再現すべきなのは全命令・全状態ではなく、デモで使う経路が正しく流れることと、弾きたい既知の失敗が弾けることだけでよい。チップの消費はデモの経路に直結するので模したが、デモで使わない機能は未実装のままにした。

代償は出る。本番当日、少量の液が狙いどおり届かない現象が出たが、これはモックが再現していなかったので手元では見えていなかった。網羅しないと決めた以上、実機で初めて見えるものは残る。

つまりこのモックの忠実度は、「実機にどれだけ似ているか」ではなく「実機に持ち込む前に弾きたいものが弾けるか」で決まる。似せること自体が目的ではないので、実機で出る差分が小さくなるところまで作れば止めていい。

実機日は、探索ではなく差分検出に使う

モックがあると、実機日の使い方が変わる。やることを3つに固定した。

デモの命令列を実機に流し、実機の応答とモックサーバーの予測を突き合わせる。 通信の記録を全部残しておくので、実機のログがそのまま校正の基準データになる。差分1件が修正1件になる。
失敗する命令をわざと送る。 チップがない状態で吸引する、初期化前に動かす。正常系をなぞるだけでは採れない、エラー時の実際の返り値を採取する。
未確認事項のリストを上から確定させる。 照会用の命令を送れば一発でわかるものを、その場で聞いておく。

確認した差分はモックサーバーへ反映し、回帰テストにする。こうして、実機で見つけた乖離は次から手元で再現できるようになる。

実機の前で「これはどう動くんだろう」と探索していると、時間はいくらでも使ってしまう。探索は手元で、実機では答え合わせだけをする。

③ 応答待ちの時間を削る — fast モードを2倍の単価で買う

実機の前での作業は「原因を推定する → コードを直す → もう一度流す」の反復になる。この1周にかかる時間が、実機1日で踏める検証回数を決める。

そこで6月15日以降の実機日とその前日作業では、Claude Code の fast モードを使った。使うモデルを下位のものに落とさずに、出力速度を上げるモードである。公式には出力トークン毎秒が最大2.5倍とされている（対応は Claude Opus 5 と Opus 4.8）。

代わりに単価が上がる。標準の Opus 5 が入力 $5 / 出力 $25 per MTok に対し、fast モードは $10 / $50 で、ちょうど2倍である。つまり2.5倍の速さを2倍の単価で買う取引になる。品質は同一と説明されている。

出典: Speed up responses with fast mode ／ Fast mode ／ Pricing

実機の前ではこの2倍を払う価値があった。応答を待っているあいだ、機器は止まったままで、こちらの実機時間だけが減っていく。腰を据えた設計は通常モードで、現場での高速反復は fast モードで、と使い分けている。

いくらかかったか

透明性のために、プロジェクト全体で使った Claude Code の実費を出しておく。

従量分は6月5日・6月24日・7月2日に $1,000 ずつ、計3回チャージした。名目 $3,000 のうち、実際に消費したのは残高 $756.95 を差し引いた約 $2,250 ぶんである。3回とも30%オフで購入していたので、消費分に対する実支払いは約 $1,575、日本円で約25万円だった。

fast モードを使ったのは実機日とその前日なので、この全部が2倍単価ぶんではない。それでも1人・実働約10.5人日・従量費約25万円で、性質の異なる実機ライブデモ3本を成立させている。

正確を期すための注記として、この約25万円には Claude Code を使うためのサブスクリプション料金が含まれていない。Claude Code は Team プランのプレミアムシート（公開価格で年払い月$100／席・月払い月$125／席。標準シートでは使えない）で利用でき、これは従量チャージとは別に月額で発生する。

この規模の実証が、個人が数十万円規模で回せる範囲に入っている。 「大がかりなチームと予算がなければ試せない」という前提は、いったん疑ってよい段階にある。

まとめ

実機に触れられる時間が5日しかない前提で、うまくいったことはこうだった。

実機でしか確かめられないことだけに、実機を使う。 資料で決まることを実機で確認するのは浪費である。
分厚い仕様書は、触れない時間に調べてコードへ移す。 調査はLLMに任せられるが、結果をコードとして固定しないと、実機の前で毎回同じ調査を繰り返すことになる。
モックサーバーを作り、実機時間はすり合わせに使う。 ただし必要なのは代役としてのモックではなくシミュレータだ。検証したいのは渡される命令そのもので、その応答がそのまま評価結果になるので、実機が拒否するものは拒否させる。逆に似せること自体は目的ではないので、実機で出る差分が小さくなるところまでで止める。
実機日は探索ではなく差分検出に使う。 実機の応答と予測を突き合わせ、差分1件を修正1件にする。探索は手元でやる。
応答待ちの時間を削る。 2.5倍の速さを2倍の単価で買う。実機が止まって待っているあいだも、実機時間は減り続ける。

本番当日、搬入の都合で実機に触れられたのは2時間半だけだった。それでも残る不確実性を「物理で完走するか」だけに絞れていたのは、手元でここまで固めておいたからである。

振り返ると、この記事の判断はどれも同じ形をしている。実機でしか確かめられないことと、手元で確かめられること。毎回調べることと、コードに固定しておくこと。何をどちらに割り当てるかを決めて、決めた側を固く作る。 別の記事に書いたLLMとプログラムの線引きも、同じ形である。→ LLMに計算させるな