Hermes AgentでAIが自律的にMD計算ができたらいいなと思って、いろいろ試していました。まだ納得のいく状態にはなっていませんが、試行錯誤をしていて気づいたことをまとめていきます。
まず一番大事なことは、お前の相棒はお前が育てろ!ということです。
昨今、AIエージェントの活用は様々な分野で取り組まれています。様々な活用方法がシェアされているのですが、型にはまった使い方だけで上手くいくものではありません。使い方は人それぞれで、その人に合ったAIエージェントを育てるということが必要不可欠です。
計算化学をやっている人は、ターミナル操作だけで作業をする人もいれば、GUIメインの人もいるし、C言語しか書けない人もいればPythonしか書けない人もいます。LAMMPSを使う人、Gromacsを使う人、Gaussianを使う人、それぞれやっていることは違います。無機結晶を扱う人、有機化学の人、などなど様々な人がいます。計算サンプルの作り方だって、オンラインのデータベースからダウンロードするだけの人もいれば、自分でサンプル作成コードを書いて実行する人もいます。
あなたのワークフローをサポートするAIエージェントはあなたにしか育てられません。
なので、まずはあなたの仕事のスタイルをAIに学ばせるのが一番最初にやることです。
環境構築とワークフロー構築は人間の仕事
AIは計算化学のことはあまりよく分かっていませんし、あなたの作業スタイルのことは何も知りません。ここを過信しすぎると後で痛い目を見ます。
バイブコーディングをやっていると、ユーザがふわっとした仕様を伝えてAIがコードを書いてくれて、ユーザは「承認!」「承認!」「承認!」でいい感じのものを作ってくれるのですが、MD計算でそれをやると酷いことになります。
- ユーザが理解していない環境をAIが使うとデバッグで詰む。
- エラーが出た時にAIは意外と対処できない。ユーザの助言は必要。しかし環境を理解していないと何もできない。
- モデル構築や計算条件やワークフローがブラックボックス化する。
- 内容をユーザが検証できない。(検証が面倒くさい)
- 計算を実行してもエラー終了することが多い
- 「計算がスタートする」と「計算が最後まで止まらずに終わる」は違う。
なので、まずやるべきことは、あなたの計算フォルダをAIに見せることです。
計算の進め方を学ばせる。
- AI用の作業フォルダを作る。
- あなたの計算フォルダのいくつか見せてもいいものをAI作業フォルダにコピーする。
- AIにフォルダ内を読ませる。
注意点
クラウドLLMに読ませる場合は、未公開構造、顧客データ、ライセンスファイル、APIキー、商用ソフトの設定ファイルなどを含めないよう注意する。必要ならAI学習用に匿名化・簡略化したサンプルプロジェクトを作る。
AI用フォルダは分けたほうがいいです。勝手にファイルやフォルダを消すことがあるからです。
また、環境構築はAIにやらせないほうがいいです。
既存の環境をそのまま使わせる、またはAI用のvenv等を作成して同じ環境を用意してやるのがいいです。
実行環境ルールを明確に定義する。
例
- (.bashrcでPATHを通しておいて)使えるコマンド一覧を教える。
- 使っていいvenvやconda仮想環境を教える。
- pip等で追加インストールすることを禁止する。
- 作業フォルダの命名規則を考える。フォルダ名はYYYYMMDD_projectNameとする、等。
- 作業ルールをスキル化する。
例えば以下のコマンドを必ず実行する。- source ~/work/.venv/bin/activate
- cd ~/work/<projectDir>
人間がこれくらいの準備をしておくと、AIは迷わずにあなたの流儀を真似してくれるはずです。
ルール定義は賢いモデル、作業はローカルモデル
AIエージェントが実際に動く際のルールはAIに書かせます。人間は直接書きません。
あなたの計算フォルダや計算環境をAIに与えたうえで、次のような内容をAIに伝えます。
- あなたは私の計算タスクをサポートするアシスタントです。
- 私の計算データを~/work/examplesディレクトリに置きました。
- 私の計算環境や使用コマンドについては~/work/examples/memoに記載しました。
- 私の計算タスクの進め方を読み解いて、あなたが私と同じように計算タスクを進められるように行動ルールを明文化してください。
まずはこれくらいのプロンプトでいいと思います。明文化したルールを確認し、問題がなければ次に適当なテーマを与えて、計算タスクをやらせてみてください。期待通りの成果が出ればよし、出なければフィードバックをします。
ここまでの作業は賢いモデルを使うのがオススメです。gpt-5.5とか、geminiのproとか。なぜなら、AIに成功体験をさせないと、成功パターンをインプットできないからです。もちろん失敗も財産です。失敗して改善していく中でAIも成長します。ユーザ側も、AIの特性を理解することが必要なので、失敗に対して上手にフィードバックすることも大事です。この作業は絶対に賢いモデルを使うべきです。逆に、この作業を軽量モデルにやらせるのは苦痛ですし、何の成果も得られないこともあります。このフェーズでは多少の課金を覚悟して賢いモデルを使いましょう。
AIが計算タスクのトレースができたら、それを元にAIに作業手順書を書かせます。例えば次のような内容を伝えるといいと思います。
- 今回成功した計算プロジェクトについて、進め方を作業手順書として明文化してください。
- この作業手順書は、性能が低いAIモデルであっても理解できるように作成してください。
- 今回の計算で使用したコマンドの実行順序など、共通化して再利用できる内容はスキル化してください。
コマンドやファイルパスなどは、文章ファイルとしてではなくスキルとして固定化すると、軽量なAIモデルであっても実行時のブレは少なくなります。
ここまでできたら、ローカルモデルや安価なモデルに切り替えて、設計通りにAIエージェントが動くかどうかをテストしましょう。
AIがやっていいこと・ダメなこと
環境構築やワークフロー構築をフルAIでやってはいけないということはすでに述べましたが、ここで改めて、AIがやっていいこととダメなことを確認しておきます。以下はあくまで例です。
| 内容 | AIがやっていい |
|---|---|
| 既存スクリプトの実行 | OK |
| 計算ジョブの投入 | OK (コマンドを固定する) |
| ログの確認 | OK (成功条件を明文化する) |
| ポテンシャル・力場の選定 | NG (割り当て方法や使用可能な力場はユーザが決定) |
| 環境構築 | NG (ユーザがやる、またはAIがやるなら賢いモデルを使う) |
| 新規ワークフロー設計 | NG (賢いモデルかつユーザのレビュー必須) |
| 失敗時の自動修正 | 範囲を限定する |
AIに何でも勝手にやらせると「違う、そうじゃない」ということを連発して、期待した成果が得られないことが多いです。それを防ぐために、あらかじめAIがやっていい範囲を明確にしておくと、人間がコントロールしやすいです。
タスクリストの作成
AIが進めるべきタスクを人間とAIの両方が参照可能な形でファイル化します。
例えば、計算タスクをマークダウンファイルに書く運用ルールを以下のように定義します。
- ~/work/TODO.mdを作成する。
- タスク1件は以下の項目で構成される。
- タスク名(プロジェクト名)
- パス (~/work/YYYYMMDD_ProjectName)
- 作成日時
- 内容
- ステータス(Todo, InProgress, Done, Error)
- TODO.mdファイルは、ユーザからの依頼に基づいてAIが作成する。
- ユーザからの依頼に不明確な点があったら、それが明確になるまでユーザに繰り返し質問をする
- 全ての内容が明確になってタスクが開始可能な状態になったらTODO.mdに記載する。
- タスクのステータスが変化したタイミングでDiscord等でユーザに通知をする。
- ~/work/YYYYMMDD_ProjectName/WORK_LOG.mdに、そのタスクの実行メモや次のアクションを追記していく。
これは例です。もっと要件を増やしてもいいです。自分流で進めやすいようにいろいろルールを考えてみるといいと思います。
計算作業を自律的に進める工夫
OpenClawであれHermes Agentであれ、それぞれのツール内にcron機能が搭載されています。それを活用することで、24時間動き続ける計算AIができあがります。また、AI-ユーザ間の連絡手段を用意しておきましょう。
- 計算完了時やエラーなどの緊急時の連絡先チャンネルを用意する。
- Discord、Slack、メールなど。
- 計算プロジェクト進行Cronを設定する。
- 頻度は10分毎とか30分毎。
- 使用モデルはローカルモデルや安価なモデル。
- cronは独立セッション。cron毎に新規セッションで行う。(コンテキストの膨張を防ぐため)
- 指示は
- タスクリストを読んで、実施すべきタスクを1つだけ進める。
- ステータスが変化したらタスクリストのステータスを書き換える。
- 計算の進め方や実行環境のルールを遵守する。
- ~/work/<projectDir>/WORK_LOG.mdが未作成なら作成し、目的達成のための実施計画を記載する。作成済みならそのファイルを読む。
- WORK_LOG.mdに、これからやる作業について記載する。
- 作業を進め、1つの作業の完了ごとにWORK_LOGに短くメモを残す。
- 計算コマンドの実行には時間がかかることがあるので、ジョブスケジューラを使用する。
- 計算コマンド投入直後に可能なら一度確認、計算が進行中であればその旨をWORK_LOGに記載し、次回のCron時に再度状況を確認する。投入直後の確認で完了している、あるいはエラー終了していた場合は、適切な作業を実施する。
- エラーを繰り返してしまい、プロジェクトが続行不可能と判断された場合はステータスをErrorにしてユーザに通知する。
- (賢いモデルを使ってもいい場合)エラーを繰り返した場合は賢いモデルでサブエージェントを召喚して解決策を考え、ファイル修正等を行いWORK_LOGに記載する。
最後に
現時点で現実的なのは、AIがMD研究者を置き換えることではありません。
ユーザが検証済み環境とワークフローを用意し、AIはそれを監視・実行・記録・報告する副操縦士として使う形です。
人間:
- 計算目的を決める
- 力場や計算条件を決める
- 環境と標準スクリプトを検証する
- 最終結果を判断する
AI:
- タスクリストを読む
- 検証済みスクリプトを実行する
- ジョブスケジューラを確認する
- ログを読む
- 成功/失敗を判定する
- ユーザに報告する
なお、この記事に書いたフォーマットでAIエージェントを育てても、上手く動くとは限りません。最初は上手く動かず、ユーザによるフィードバックを何回も何回もやることによって、徐々に育っていきます。
AIエージェントは育てるものです。
実は結構めんどくさいです。
実際に動かしてみた
実際にHermes Agentにこの記事のURLを読ませて自律動作のルール作りと簡単な計算をやらせてみました。基本的には動きましたが、使用するモデルの性能に依存する部分も大きかったです。
- 実務担当はgemma-4-26b-a4b q8_0、監督役はgpt-5.5。
- 監督役・ユーザとの対話チャンネルは賢いモデルが望ましい。
- 実務はローカルモデルでいい。12BのQATとかでも動くかも。
- いきなりローカルモデルonlyは難しい。失敗や成功をルールやテンプレートに反映して、ゆくゆくはローカルモデルonlyを目指す。
- 使っていくと、エージェントも育つしユーザの指示出しも上手くなる。
- ユーザがかなり細かく指示を与えることが重要。
「AI研究者を作る」というのは違います。
「人間の研究をサポートするアシスタント・副操縦士を作る」というのが目指すべきところです。
コメント