実験機器を動かすAIエージェント — 自然言語で分注ロボットを操作する、LADEC 2026実機ライブデモの記録

この記事について こんにちは、Science Aid株式会社で代表を務めている山田です。テカンジャパン様の協力を得て、AIエージェントに実験ロボットを操作させるための開発を進めています。2026年7月2日、その途中経過を、LADEC 2026（日本科学未来館）のセッションで、実機のライブデモ3本として発表しました。この記事はその報告です。何ができるようになったのか、それをどのように確かめたのか、そして同じことを自社で試すとしたら何が必要になるのかを、順に書いていきます。

0. この記事の要点

実験手順書（SOP）や日本語の指示を受け取って、Tecan社のCavro^® Omni Flexという分注ロボットを操作するAIエージェントを開発しました。AIが実験の計画を立て、その内容を人が確認して承認すると、実機が動きます。
LADEC 2026のセッションで、性質の異なる3つの実験を実機のライブデモとして実施しました。事前に録画した映像は使っていません。
対象とした分注ロボットは、PCやマイコン経由で装置の制御コマンドを実行する仕様で、外部のプログラムからネットワーク越しに命令を送るための手段が用意されていません。機器の構成には手を加えず、この機器をAIから操作できるようにしました。
開発の担当は1名、実働は約10.5人日です。実機に触れられたのは5日間（うち2日は半日）で、残りの期間は、実機と同じ応答を返すモックサーバー（実機の代わりになる模擬的な環境）で開発しました。
計画・実験・解析をひと続きのサイクルとして動かすこと、そしてAI・ロボット駆動科学を実現することを、この先の目標にしています（§6）。

この先は、§1から§4で何を作り、それをどのように確かめたのかを書き、§5で、同じことを自社で試すとしたら何が必要になるのかをまとめます。

LADEC 2026のセッション会場。壇上に分注ロボットの実機を置き、奥のスクリーンにデッキの様子を2つのアングルで映している — LADEC 2026のセッション会場。壇上に実機を持ち込み、スクリーンにデッキの様子を映しながらライブデモを実施しました（オンライン配信の録画より）

1. 何ができるようになったのか

1.1 作ったもの

人が書いた実験手順書（SOP）や日本語の指示を受け取り、機器を動かすためのコマンド列をAIが自分で組み立てて実行するシステムを作りました。

分注ロボットを動かすには、これまで「どの座標へアームを動かし、何µL吸って、どこへ吐くか」というコマンド列を、人があらかじめ用意しておく必要がありました。これを書けるのは、機器メーカーの担当者と同じくらい機器の仕様に詳しい人に限られます。この中間の工程を、AIに任せました。

今回の対象について書いておきます。使ったのは、Tecan社のCavro^® Omni Flexです。試薬や検体を、決められた場所へ決められた量だけ吐出する分注ロボットで、Windows PCなどを通じてコマンドを送り操作します。

この機器には、ひとつ前提になる制約がありました。別のコンピュータで動くプログラムから、ネットワーク越しに「この動作をしてほしい」と命令を送るための手段が用意されていないのです。つまり、AIをどれだけ賢くしたところで、その指示を機器まで届ける経路がそもそもない、という状態でした。

そこで今回は、その経路を自分たちで用意しました。機器につないだWindows PCの上に、命令を受け取って機器へ渡すだけの小さなプログラムを常駐させ、AI側からはそこへ命令を送る形にしています（§4.2）。

用語: SOPは標準作業手順書、つまり科学者が書く実験手順のことです。段階希釈は、一定の比率で段階的に薄めていく操作を指します（今回のデモでは2倍ずつ6段）。

1.2 指示を出すと、何が起きるか

指示を出してから実機が動くまでには、4つの段階があります。

指示: 手順書（SOP）を添付して、同僚に頼むときのように、日本語で「これをやってほしい」と伝えます。
計画: AIは機器を動かさずに、計画だけを最後まで作ります。人が読める粒度の手順を組み、それを機器の命令（座標つき）に変換し、実行が終わったあとにどういう状態になるかまで予測します。
承認: 手順と予測結果を人が確認し、実行してよいかどうかを判断します。
実行: 承認された計画が、そのまま実機へ流れます。

2. LADEC 2026での実証

2.1 3本の実機ライブデモ

2026年7月2日、日本科学未来館で開かれたLADEC 2026で、AIエージェントと実験機器の接続をテーマにしたオーガナイズドセッションを、テカンジャパン様と共催しました。

LADEC（Laboratory Automation Developers Conference）は、一般社団法人ラボラトリーオートメーション協会（LASA）が主催する、研究の自動化をテーマにした学会です。自動化装置の開発者やユーザー、生命科学・化学・材料の研究者、ロボットやITの技術者が、所属の垣根を越えて集まります。2026年は7月2〜3日の開催でした。出典: LADEC 2026公式サイト

セッションの中心は、3本の実機ライブデモです。事前に録画した映像を流すのではなく、その場で分注ロボットが動くところをご覧いただきました。

デモ	内容	当日の実行方式
①単純分注	赤い液を100µLずつ5か所へ	「赤い液を、100µLずつ、5カ所に分注して」と入力 → AIが計画 → 承認 → 実機実行
②ELISA検量線	検量線のための2倍段階希釈（6段）	SOPを添付して「このSOPで検量線スタンダードを作って」と入力 → AIが計画（2倍×6段・各100µL）→ 承認 → 実機実行
③NGSサンプルの等モル化	検体ごとに濃度が違う原液で、目標濃度に揃える必要量を計算して分注	AIが組み立てた機器への命令を画面に映しながら、開発時に使っているツールからそのまま実機へ送信

3本とも、その場で実機が動きました。

2.2 この実証で確かめられたこと

ひとつは、外部から操作されることを想定していない機器を、日本語の指示で動かせたことです。ここが、今回最も確かめたかった点でした。

近年の機器のなかには、Pythonなどから呼び出せるAPIが公式に用意されているものもあります。そうした機器であれば、外部のプログラムから動かすこと自体は難しくありません。しかし、いまラボで実際に稼働している機器の多くは、そうではありません。ネットワーク越しに命令を受け取る仕組みを持たず、付属のGUIソフトウェアを人が操作する前提で作られています。AIから動かそうとすると、どう賢く指示を出すかを考えるより前に、命令を送る手段がない段階で止まってしまいます。Cavro^® Omni Flex向けに提供されていたのも、Windows用の制御部品（DLL）だけでした。そこで、仕様書とサンプル実装を読み解いたうえで、中継サーバを設けています。APIを持たない機器であっても、いま現場にある構成のままAIにつなげる余地があります。今回確かめられたのは、その点です。

もうひとつは、性質の異なる3つの実験を、専用のプログラムを作り分けずに動かせたことです。単純分注、段階希釈、濃度計算を伴う等モル化。手順の性質はまったく異なりますが、同じ仕組みに手順書を渡し替えるだけで動きました（①②は本番の実機で、③はモックサーバーで通し確認しています）。判断をAIに、正確な計算をプログラムに寄せた設計が、ここで効果を発揮しています（§4.1）。

3. なぜ今「実験機器×AI」なのか

3.1 世界と国内の動き

2025年は「AIエージェント元年」と呼ばれました。コーディング、文書作成、データ解析といった、コンピュータの中で完結する仕事では、AIが人の作業をかなりの範囲で肩代わりできる水準に達しています。科学研究でも同じで、PCの中で閉じるタスクの自動化は次々に成果が出ました。機械学習研究をエージェントが回すSakana AIのAI Scientist、既存薬から治療仮説を立てるFutureHouseのRobin（ともにNature 2026）、前処理済みデータの解釈を専門家2人×数週間から数時間に縮めたGinkgo Datapoints×Biomni、解析から再現性管理までを一つの環境に収めたAnthropicのClaude Science、といった例があります。

実験科学の営みを「計画 → 実験 → 解析」の3ステップで見ると、急速に強くなったのは計画と解析です。どちらもコンピュータの中で完結します。残るのが実験、つまり実機が物理的に動く部分で、私たちが取り組んでいるのはここです。

この領域は、ソフトウェアで完結する領域に比べると、まだ事例が少ない段階です。Ginkgo Bioworks×OpenAIやOpentronsのように、AIが物理の世界に関わりはじめた例は出てきていますが、先に挙げた分野のように人の作業を大きく肩代わりできる水準には、まだ届いていません。

進みにくい理由は、はっきりしています。まず、実機を用意すること自体の負担が大きいことです。ソフトウェアであれば手元のPCで今日から始められますが、実験機器はそうはいきません。次に、物理的な動作には時間がかかることです。アームは決まった速度で動き、液体は決まった速さでしか流れないため、並列化や高速化によって試行回数を稼ぐことができません。そして最も難しいのが、機器が外部からの自由な操作を前提に作られていないことです。ラボの機器はメーカーごとにコマンド体系も座標系も接続方式も異なっており、その仕様を一つずつ把握していく労力が必要でした。

この3つ目の点に、LLMの進展が大きく作用しました。分厚い仕様書とサンプル実装を読み解いて機器のコマンド列を組み立てる作業は、かつては人が時間をかけて越えるしかありませんでした。それを、AIと一緒に越えられるようになりました。2026年は、この「実験の実行」でも成果が出てくる年になると考えています。今回のプロジェクトを1人で進められたのも、この変化があったからです。

国内の動きも本格的です。文部科学省は2026年4月、AI for Science革新的研究推進事業（ARiSE）の基本方針を公表しました。JSTの公募説明資料は、事業概要を「AIを活用することで研究プロセスへの変革をもたらすことが可能な、科学基盤モデル、AIエージェント、次世代AI駆動ラボシステムなど、革新的な基盤技術の創出に取り組む」と説明しています（予算総額320億円・研究期間約2.5年）。国のフラグシップ事業の創出対象にも「次世代AI駆動ラボシステム」が明記されました。AIを実験の現場へ持ち込む方向に、国としても重点が置かれています。

出典: ARiSE事業概要（JST）／ARiSE公募説明会資料（JST・PDF）／ARiSE基本方針（文部科学省）／Claude Science

3.2 機器メーカーとAI開発者が組む

このプロジェクトは、テカンジャパン様の協力を得て進めています。対象はCavro^® Omni Flexで、2026年3月9日には、自然言語で実験ロボットを操作するAIエージェントの開発に着手するとプレスリリースも出しました。出典: プレスリリース（2026年3月9日）

このプロジェクトを短い期間で進められたのは、この座組みによるところが大きいと思います。「機器・現場・AI」の三つを同時に持っている会社は、そう多くありません。異なる専門性を持つ相手とどれだけ早く組めるかが、そのまま開発の速度になります。私たちがAIエージェントの実装を担当し、テカンジャパン様からは次の三つをいただきました。

実機に自由に触れられる環境。川崎のオフィスにある機器を、まとまった時間、私たちが自由に使える形で用意していただきました。
機器の正式な仕様と資料。コマンド体系や座標系の正式仕様、シリンジ容量設定コマンドの正しい記法（マニュアルの記載訂正を含む）。
現場での技術サポートと助言。機器を日々扱っている方の知見に、何度も助けられました。具体的な場面は§4.1に書きます。

こうした協力をいただけたことで、実証は現実的な期間で進みました。

4. 設計で重要だった判断

ここからは、開発を進めるうえで重要だった判断を3つ書きます。実装の細かい話ではなく、どこをAIに任せ、どこを人が握るか、という考え方の話です。安全性も再現性も進め方も、この判断で決まります。エンジニアでない方にも読んでいただけるように書きました。

4.1 判断はAIに、正確な計算はプログラムに

最も効果が大きかったのが、この切り分けです。「どういう手順で進めるか」という判断はAIに任せ、座標、分量、命令の組み立て、実際の実行といった、答えが一つに決まる計算は、プログラムに任せます。

用語: ここでのAIは「LLMの推論に委ねる確率的な処理」、プログラムは「コードで機械的に解く決定的な処理」を指します。プログラムのコード自体もAIに書かせているので、どちらにもAIは関わっています。分けているのは、実行するたびに結果が揺らぐかどうかです。

処理	担当	例
手順の組み立て（何をどの順で何回）	AI	SOPを読み、「希釈液を配る→原液→連鎖希釈→余りを廃棄」の順序を決める
チップ戦略（使い分け・替えどき）	AI	交差汚染を防ぐため検体ごとに替える／同一試薬の連鎖は1本で通す
「赤い溶液」が設定上どれか	AI	自然言語の呼称を設定ファイルの該当項目に対応づける
希釈量・倍率の計算	プログラム	原液200µL → 各段100µLで1,2,4,8,16,32倍
座標の解決・単位換算・命令構成	プログラム	基準点＋ピッチで全座標を導出、µL→ポンプstep、命令文字列の生成
実際の実行	プログラム	承認された命令列を機器へ流す

AIは十分に賢いのですが、出力が確率的である以上、同じ指示に対して毎回まったく同じ結果が返るとは限りません。座標や分量のように、一度外れただけで物理的な事故につながる部分は、この揺らぎを許容できません。そこをプログラム側に寄せておけば、値が変わることはありません。反対に、手順の組み立てのように答えが一つに決まらない部分は、AIのほうが得意です。

判断の基準はシンプルで、「その処理は答えが一つに決まるか」「電卓で解けるか」を問うことです。解けるならプログラム、解けないならAIに任せます。そして、物理的に取り返しのつかない部分（衝突や上限量）は、必ずプログラム側のガードで守ります。AIは提案するだけで、ガードがそれを拒否できる形にしておきます。

精度にも、はっきりと表れました。手順そのものをAIに短いコードとして書かせ、計算はその実行系に委ねる方式に変えたところ、同じAIモデルのまま、段階希釈の正答が0/6から6/6になっています。違いは、計算をAIの推論に任せなかったこと、それだけです。

この切り分けには、続きがあります。どこで判断すべきかを決めるのは、多くの場合ドメイン知識です。

デモ③では、小さいウェルへの少量（数µL〜数十µL）の分注がどうしても通らず、当日の限られた実機時間のうち1時間ほどを費やしました。私たちが用意した判断ロジックは、吐出するたびに液面を検知しに行くコマンド列を組んでおり、少量だと液面に届かずに失敗していたのです。試行錯誤を重ねても解決に至りませんでした。そこに、テカンジャパン様の現場の方から一言いただきました。

吐出のときは液面検知をしない。決め打ちの高さで出す。液面検知は、吸うときだけ。

これで方針が変わり、すぐに実機で動きました。どこで検知すべきかという判断はドメイン知識、決め打ちの高さをどう座標に落とすかという実装はプログラム。切り分けの好例であると同時に、1人で抱えていた問題が専門家の一言と数分で解けることを実感した場面でもありました。

4.2 外部から操作できない機器に、中継役のプログラムを挟む

既存の機器をAIにつなぐとき、最初に問題になるのは、外部のプログラムから操作する手段が用意されていないことです。Cavro^® Omni FlexもPCやマイコンからコマンドで操作する前提で作られており、外部から直接コマンドを送る方法がありませんでした。

そこで行ったのが、機器につないだWindows PCに、AIからの命令を受け取って機器へ渡すだけの小さなプログラムを常駐させることでした。以降、これを中継サーバと呼びます。判断ロジックは一切持たせず、外部に開けるのも、接続・実行・状態確認のためのごく限られた入り口だけです。AI本体は、ここへHTTPで命令を送ります。

[チャット画面]
      │
      ▼
[AIエージェント／中核ライブラリ]    … 開発者側のPC（OSは選ばない）
      │  HTTP（社内LAN）
      ▼
[中継サーバ]                        … 機器につないだWindows PC
      │
      ▼
  Cavro® Omni Flex実機

この形にすると、AI側が機器から独立します。UIを差し替えても、別の機器につなぎ替えても（中継サーバを足すだけです）、中核は影響を受けません。

もうひとつの効果として、実機に触れられない日でも開発を進められるようになりました。中継サーバの接続先を、実機の代わりに、実機とまったく同じ応答を返すモックサーバーへ差し替えます。こうすると、機器が手元になくても、AI側から見れば実機につないでいるのと同じ状態で開発とテストができます。実機に触れた初日に行ったのは、デモを作ることではなく、どんな指示に機器がどう応答するかを観察して、このモックサーバーを作ることでした。その結果、実機に触れるのは5日間で済み、残りの大半の時間は手元で進められています。実機は貸し出す側にとっても貴重な資産ですから、ここは重要な点だと思います。

外部から直接操作する手段がない機器を中継サーバ経由で動かすという形は、Windowsの制御部品をGUIソフトウェア経由で操作する機器であれば、機構としてはそのまま当てはまると考えています。ただし、制御方式も命令体系も機器ごとに異なるため、他の機種に適用する場合は、その機種に合わせた検証が個別に必要になります。自社の機器がこのタイプに当てはまるかどうかを見極めることが、PoCの出発点になります。

4.3 人が承認してから動かす

現在の設計では、AIが計画（手順と予測結果）を提示し、人が確認してから実行に移ります。§1.2に書いたとおり、承認された計画は再計算されずにそのまま流れるため、確認した内容と実行される内容が必ず一致します。

この一致は、再現性やトレーサビリティが問われる場面で意味を持つはずです。何が実行されるのかを事前に人が確認し、その通りに動き、ログにも同じ内容が残ります。問題が起きた場合は人が止め、戻して、もう一度実行します。失敗からの自動リカバリはあえて作り込まず、人の管理下に置いています。

承認をどこに、どの粒度で入れるかは、自由に設計できます。手順ごとに毎回挟むこともできますし、計画全体でまとめて1回にすることも、リスクの高い操作だけに絞ることもできます。今回は計画全体に1回の承認を挟む形にしましたが、現場の運用や求められる管理の水準に合わせて、この位置は動かせます。

今回の実装をどのように作ったのかという技術寄りの内容は、私の個人ブログで2本の記事として公開しています。AIに手順をコードとして書かせる方式と、AIとプログラムのどちらに何を任せるかの線引きについてはLLMに計算させるな — 確率論的な挙動と決定論的な挙動の線引き、実機に触れられる時間が限られるなかで開発を進めた段取りについては触れない実機で開発する — 希少な実機時間をどう使うかに書きました。開発者の方は、あわせてご覧ください。

5. 同じことを自社でやるなら

ここまでの内容を、同じことを自社で試すとしたら何が必要になるか、という視点で整理します。

5.1 試すときの体制と規模感

まず、規模感からお伝えします。今回の実績をそのまま出します。

項目	実績
開発者	1人
実働	約10.5人日（実機での作業約4人日＋手元での開発約6人日＋ LADEC当日）
実機に触れた日	5日（3/23・5/14・5/15・6/15・6/25。うち2日は半日で実働約4人日）＋ LADEC当日
対象機器	Cavro^® Omni Flex（外部APIなし、GUIと制御部品のみ）
成果	性質の異なる実機ライブデモ3本

進め方は3段で、役割分担ははっきりしています。

段	何をやるか	用意していただくもの	Science Aid側の担当
①接続	制御部品をHTTPで呼べる中継サーバを用意する	実機へのアクセス、制御部品と仕様	中継サーバの設計・実装
②手元開発	実機と同じ応答を返すモックサーバーを作り、AI側を開発する	初回の実機で「応答の観察」への立ち会い	モックサーバーの構築・エージェントの実装
③実機検証	物理で本当に動くかを実機で確認する	実機の時間、現場からの助言（液体の扱い等）	検証・調整・デモ化

規模は対象とする操作の複雑さによって前後しますが、まず1操作を実機で通す小さなPoCから始めるのが、最も確実です。

もうひとつ申し上げたいのは、自社のドメイン知識が、AI時代にはむしろ資産になるということです。液体の粘性や、少量が届きにくいことに応じた分注条件のような、機器と現場を知る側にしかない知見の価値は、AI化によって下がるどころか上がります。§4.1のエピソードが、その縮図です。現場の方の「吐出のときは液面検知をしない」という一言は、その日のうちにシステムの設定として固定され、以後のすべての実行で再現されるようになりました。経験として蓄積されてきた暗黙知を、データとして仕組みの中に取り込んでいく。これは、機器を作っている側と組まなければ進まない領域です。

秘匿や知財についても触れておきます。頒布はDockerイメージの形にし、ソースやAPIキーの混入は自動検査で機械的に防いでいます。より強固なコード保護は評価中です。機器の制御を外部に預けたくないという場合には、実装物を自社環境側に閉じて頒布する構成にできます。

5.2 手順書がそのまま入力になる

多くの実験機器は、本来、プログラムを組み替えることで多様な実験に柔軟に対応できる能力を持っています。ところが、そのプログラムは機器ごとの独自の記法で書かれており、普段からコードを書き慣れている人であっても、読み解いて使えるようになるまでには相当な時間がかかります。そのため、プログラムの改変はメーカーへの依頼になりがちで、時間も費用もかかります。ある研究室では、予算が潤沢だった購入時に初期設定とチューニングまでは依頼できたものの、その後の研究費が続かず、同じプログラムでしか動かせなくなったという話も聞きました。機器にはまだ余力があるにもかかわらず、プログラムのハードルが高いために使い切れていません。今回の実証が現場に対して持つ意味は、この構図に別の入り口がありうると示せたことだと考えています。

デモで使ったSOPは、機械向けに整形した特別な文書ではありません。人間の科学者に向けて書かれた現実的な手順書で、使用機器も消耗品も安全衛生上の注意も含まれており、今回の実験には必要のない記述も混ざっています。それをそのまま渡し、AIが必要な情報を抽出して計画を組みました。

SOPに書くこと（人＝科学者）	AI・システムが担うこと
検体数・目標濃度・段階数などの実験の意図	それを実現するコマンド列への変換（座標・分量・命令）
交差汚染を防ぐなど科学的に必須な手順（例: 検体ごとにチップを替える）	退避・チップ最適化・一括吸引などの機器の効率的な動かし方
使用機器・品質の狙い	実行時の計算・シミュレーション・実機への送出

独自の記法によるコマンド列はシステムが組み立てるため、科学者は「どういう実験をしたいか」に集中できます。実験を変えたいと思ったら、手順書を書き換えれば、その日のうちに次へ進めます。性質の異なる3つの実験を、専用のプログラムを作らずに同じ仕組みで動かした今回のデモ（§2）は、その最初の実例です。

安全と規制については、設計で担保する方向で考えています。AIが計画を提示し、人が承認してから動きます。承認した計画は再計算されず、そのまま実行されます（§4.3）。この性質は、再現性とトレーサビリティが問われる規制産業と相性がいいはずです。GxP監査に耐えるログ・電子署名・権限管理は次の段階の作り込みになりますので、要件を伺いながら、一緒に作らせてください。

6. おわりに

最後に、この先に何を目指しているのかを書きます。

最終的な目標は、計画 → 実験 → 解析を一連の動作として連携させ、さらに解析から計画へも繋いで、サイクルとして動かすことです。計画と解析の領域は、世の中でもエージェントの事例が数多く出ていますし、私たちもこの二つでは実績を重ねてきました。計画（調査・仮説生成）のエージェント（プレスリリース（2026））と、解析のエージェントです。今回そこに、実験、つまり実機を動かす領域での実績が加わりました。次はこの三つを繋ぎ、最終的にはループとして自走させたいと考えています。そこまで到達して初めて、真の意味でのAI・ロボット駆動科学だと考えています。

面白いのは、本当にできるのかがまだ分からないことです。分注精度、器具の寸法データの取り込み、液体条件の精緻化、実行結果の観測性。このあたりの改良については、やり方の目処が立っています。一方で、サイクルの自走については、まだ誰も答えを持っていません。あわせて、今回の設計を他の機器へ広げ、実験タスクを精度・コスト・実行時間で測る実機ベンチマークにも取り組みたいと考えています。

この挑戦は、機器を理解する側とAIを実装する側が組むことでしか前に進みません。今回のプロジェクトが、まさにそうでした。

「自社の装置をAIで操作できるか試したい」「この実験を自動化・省人化したい」「熟練者の手技を再現したい」。そうしたご相談をお待ちしています。手順書（SOP）と現場の知見をいただければ、自然言語で動かせる形に落とし込みます。どの操作から始めるべきか、精度や規制の要件をどう満たすか、といったところからご相談ください。

本記事は、LADEC 2026（2026年7月2日）での実機ライブデモ実証と、その開発過程の記録にもとづいて構成しています。数値・固有名詞・エピソードは当時の記録に拠ります。

Contact

Science Aidは、研究を中心とした幅広い領域をAIによって支援します。システム開発やコンサルティング、共同研究、セミナーのご依頼などお気軽にご相談ください

お問い合わせ