この記事は、note で連載した「自動売買をつくってみる」第7回の転載です（全9回）。
元記事: https://note.com/suisei498/n/nf6ca47c9caa3
前回まで書いてきたとおり、開発する母艦と、売買を動かす専用機の2台になりました。
どちらでもAIエージェント（Claude Code）を動かしています。母艦から専用機へは遠隔で入れるので、作業自体は困りません。
困ったのは別のところでした。2つのセッションは、互いの存在を知りません。 片方の出力をコピーしてもう片方に貼る、という仲介を、私が毎回やっていました。
※この回は2026年8月、まだデモ口座だけで動かしていた時期の記録です。特定の手法や銘柄を勧めるものではありません。
認識がずれた
ある日、専用機の側からこういう報告が来ました。
移設したコードの戦略構成が、引き継ぎ書と食い違っています。2つの戦略が削除され、別の戦略が1つ追加されています。8月に母艦で変更されたものと思われますが、引き継ぎ書が更新されていません。
事実はこうでした。
- その変更は同じ日の午前に母艦で行い、遠隔で配ったもの
- 「8月に」という推測は外れていた（その日の話です）
- 相手には経緯がなかったので、推測するしかなかった
指摘そのものは正しいのです。実態と記録が食い違っている。ただ、いつ・誰がやったのかを復元できないので、時期の推定を間違えました。
ここが今回の核心でした。足りなかったのは「共有」ではありません。 同じファイルを見ていても、同じずれは起きます。実際、食い違いに気づいたのは同じファイルを読んでいたからです。
足りなかったのは、いつ・誰が・何を変えたかの履歴でした。
「両方から編集できるようにする」はやめた
最初に考えて、やめた案があります。共有フォルダを1つ置いて、両方から自由に書けるようにする案です。
やめた理由は3つあります。
2つのエージェントは、相手が作業中であることを知りません。 片方が編集している最中にもう片方が書き戻せば、どちらかの変更が黙って消えます。人間同士なら「いま触ってる」と言えますが、その手段がない。
クラウド同期を挟むと競合ファイルが生まれます。 同じ名前の別バージョンが増えて、どれが正しいのか分からなくなる。ずれを直すために入れた仕組みが、新しいずれを作ります。
そもそも今回のずれは、共有していても起きました。 片方が古い節を読んでいただけなので、書き込み先を共通にしても解決しません。
同時に編集できるようにすることは、問題の解決ではなく、別の問題の追加でした。
決めた4つのルール
実体はファイル2枚だけです。専用機側に置き、母艦から遠隔で読み書きします。
- 母艦から専用機へのファイル：書くのは母艦だけ。読むのは両方
- 専用機から母艦へのファイル：書くのは専用機だけ。読むのは両方
ルールは4つ。
1. 一方向にする。 同じファイルを両方から書かない。書くのは1台、読むのは両方。これだけで、上書きで消える事故が構造的に起きなくなります。
2. 追記だけにする。 過去の記述は書き換えず、訂正は下に足す。書き換えてしまうと履歴が消えるからです。今回足りなかったのがまさに履歴なので、ここは譲れませんでした。
3. 正典を1つに決める。 ドキュメントの正典は母艦側とし、専用機は「実態と食い違う」と指摘だけを書く。正典が2つあると、必ず食い違います。 どちらが正しいかを決める作業が毎回発生するくらいなら、最初に決めておく方が安い。
4. 見出しの時刻は、書く直前に取得した実測値にする。
4つ目だけ、生まれた経緯が少し情けないので書いておきます。
両方とも、実際より40分先の時刻を書いていた
やり取りを始めた最初の日、双方が見出しに「16:00」「16:35」と時刻を書いていました。
あとでファイルの更新時刻を確認したら、実際は15:42と15:48でした。
両方とも、実時刻より40〜50分先の時刻を書いていたわけです。時計を見ずに、だいたいの感覚で書いたためです。
申し送りは時系列が命なので、以後は書く直前に現在時刻を取得してから書く運用にしました。人間同士でも起きるミスですが、片方が推測で補うと今回のような取り違えに繋がります。
技術文書を書くと、文字が消える
実装で一番はまったのは、まったく別のところでした。
相手が書いた文面の2箇所が壊れていたのです。
c ではなくログ本文で見るのは、
c=1 が接続失敗以外でも立つため。
**
esults/ 配下はUTC、
正しくはこうです。
rc ではなくログ本文で見るのは、rc=1 が接続失敗以外でも立つため。
results/ 配下はUTC、
rc の r が消え、results の r が改行に化けています。
原因はPowerShellのヒアドキュメントでした。二重引用符で囲むと、中でバッククォートがエスケープとして解釈されます。バッククォートに続く r は復帰、n は改行になる。
そしてMarkdownでコードやパスを書くとき、私たちはバッククォートで囲みます。rc と書けば、バッククォートの直後の r がエスケープとして食われる。実ファイルには単独の復帰文字が3個混入していました。
なぜ二重引用符を使ったかというと、見出しに現在時刻を差し込みたくて変数展開を有効にしたからです。ルール4を守ろうとして踏んだ罠でした。1回目の追記は単一引用符だったので無事でした。
対策は、単一引用符のヒアドキュメントを使うことです。中でエスケープが働きません。時刻を差し込みたいときは、本文を単一引用符で書いてから置換するか、その行だけ別に書きます。
コードやパスをバッククォートで囲むほど踏みやすい。技術文書を生成する処理ほど危ない。
同じ罠を、この記事の素材を作っている最中にも踏んだ
これはPowerShell固有の話ではありませんでした。
この連載の素材ファイルを用意しているとき、索引を書き込むコマンドで同じことが起きました。二重引用符の中にファイル名をバッククォートで囲んで書いたところ、シェルがそれをコマンドとして実行しようとしたのです。
当然そんなコマンドはないので失敗し、置換結果は空文字になりました。書き込まれたファイルからは、ファイル名だけが消えていました。
- … ★最有力。監視の穴3例
- … 頑健性検証
エラーは表示されました。しかし書き込み自体は成功として終わっています。気づいたのは、書いたあとにファイルを開いて確認したからです。
第4回に書いた「動いているのに仕事をしていない」と、まったく同じ形でした。書き込みが成功したことと、意図した内容が入っていることは別物です。
やってみて分かった限界
運用してすぐ、はっきりした限界がありました。
相手は常駐していません。
仕組みを作った翌日、私が書いた報告に8時間返信がありませんでした。専用機側のエージェントは、そのPCでセッションが開かれたときだけ動きます。「見ておいてほしい」と書いても、起動されなければ実行されません。
これは直せないので、使い方を変えました。
- すぐに要る確認は、自分で遠隔から取りに行く。 相手を待たない
- この仕組みは「相手が次に起動したときに読む申し送り」として使う
- 流すのは異常と変更だけ。定常運用の報告は書かない
副産物：主張を実測で突き合わせる関係になった
思わぬ効果もありました。
- 相手「再起動は5回、すべて正常」→ こちらがイベントログを全件取り直すと7回あった
- こちら「通算11回」→ 相手が日付で全件取ると12回だった（こちらが数え落としていた）
- 相手「建玉は無い」→ 実は古い日付のログを見ていた
どちらも「そのセッション中に自分が見た分だけを数えた」ことが原因です。以後はイベントログを日付で全件取ってから数えると決めました。
面白いのは、これが一方向にしたから成立したことです。同時に編集できるようにしていたら、片方が相手の記述を直して終わりだった。書き換えられないから、突き合わせるしかなくなったわけです。
次回
次は、その遠隔操作そのものが効かなくなった話を書きます。
画面は映っているのに、クリックもキー入力も一切通らない。 現地で実機のマウスを触ると、それ以降は正常に操作できる。毎回起きました。
最初に立てた仮説は、一言で否定されました。
連載の全9回は note にまとまっています → https://note.com/suisei498