「FX」タグアーカイブ

コンピュータ

AIによる開発の落とし穴と「賢さ」の正義

コメントする

～Claude Code Sonnetで組んだfx-botがBT通りに動かない理由 —— Fable5に「ダメ出し」させて分かったこと～

はじめに

最近、Claude Codeでfx trade botの開発をしていた。 私自身はそんなにコードを書けないので、Claude Code正に神器と歓喜した。 FX自体はやっていたのでいろんな手法は知っている。その手法をClaude Codeに話して実装してもらう Claude Codeは計画を立て(計画はOpus 4.8を使用)プログラムを書きテストも自動でやってくれる。実に素晴らしい。 BT(バックテスト)結果も好調で、いざ動かしてみると、結果は惨憺たるものだった。「全然、BT通りに動かない（勝てない）」。

いざ走らせてみると

バグがいっぱい出た。。。まぁ、それはClaude Codeで直せばいいが。 しかし、テストしてるのになぜこんなにもBUGがある。。。

さらに、BUGを直しても勝てない。 BTでは勝っているのになぜ？

Fable5という「厳しい監査役」の登場

1週間弱、幻のFable5が使える時期があったので、このを逃さず何が問題なのか聞いてみた。

実装したコードをそのままFable5に読み込ませ、「この実装に潜む論理的な欠陥や、バックテストと実運用の乖離を生む要因を徹底的に分析せよ」と指示を出した。

結果は、目から鱗が落ちるような「ダメ出し」の嵐だった。

Fable5は、単にコードの書き方を修正するのではなく、「トレードシステムとしての整合性」というメタ視点から実装を分析した。

  • 「この条件判定のタイミングでは、まだ確定していない足の値を参照している可能性がある」
  • 「このロジックでは、〇〇のような相場状況においてエントリが重複し、リスク管理が破綻する」
  • 「BTで良好だったのは、この〇〇という実装上のミスが偶然に有利に働いていたからではないか」

まぁ、確かにそんな指示はしてないので、漏れてても文句は言えないのだが。。。

結論：やっぱり「賢さ」が正義である

Claude Code (Sonnet) は素晴らしい「プログラマー」だが、予測域が一般人並み（いや、それでも私よりは十分賢いのだが）。それに対し、Fable5はもはや専門家。任せておけば万事OKな安心感がある。 が、さすがに全行程Fable5にやらせるのは個人では厳しい。しかも今後はAPI課金に変わると言うし（というかその前にアメリカ政府により利用停止になってしまったが。。。）なので、計画、設計はFable5。コーディング、テストはSonnet、評価、改善はFableってのが良さそう。 やっぱり、こういう領域では「賢さ」こそが正義だ。

Fable もう使えるようにならないのかなぁ。。。(Q_Q

コンピュータ

Hermes Agent + Qwen36-35B-A3B に「自律修正」を任せてみた

コメントする

VPS上で動かしているFXボット群の監視・改善を、Hermes AgentにQwen3-35B-A3Bを載せて自律的にやらせてみた。指示は「問題を見つけたら自分で直せ」。結果は「発見はできる。修正は荷が重かった」。

何をやらせたか

VPS上で複数のFXボット（bot_pattern、bot_gmo、bot_ha_ema など）が稼働している。
Hermes Agentに「ログやコードを見て、問題を自発的に発見・修正せよ」という自律タスクを与えた。

モデルはQwen36-35B-A3B（Mixture-of-Experts、アクティブ3B/総35B）。
ローカルで動かせるサイズ感でエージェントに使うには悪くない選択肢のはず…だった。

Hermes Agentが出した報告

「GMO APIにレートリミットが出ている」

Hermes Agentが真っ先に報告してきた内容がこれ。「HTTPステータス429が大量発生している」と。

実際にVPS上のログを精査すると――

18:15:34,429 [INFO] ...

ログのタイムスタンプのミリ秒部分だった。34,429 の ,429 を HTTP 429 と読み間違えた。

実際のAPIアクセス数は約500〜700回/日。GMO公式制限（GET 6回/秒 ≒ 518,000回/日）の0.1%以下で、レートリミットは欠片も発生していなかった。

ERR-5218（取引時間外発注）の連続発生

429誤報の調査中に、今度は本物の問題を見つけてきた。

bot_mtf_tb_eurusd が週末（土曜07:00〜月曜07:00 JST）にもGMO APIへ発注リクエストを送り続け、ERR-5218: The order was rejected for trading close. が4時間おきに9回連続発生していた。

2026-05-16 20:30 [ERROR] 発注失敗: ERR-5218
2026-05-17 00:30 [ERROR] 発注失敗: ERR-5218
2026-05-17 04:30 [ERROR] 発注失敗: ERR-5218
...（9回）

dry-runのため実損はないが、無駄なAPI呼び出しとログ汚染が続いていた。これは正真正銘の問題。

修正フェーズで何が起きたか

「修正せよ」と指示していたので、Hermes Agentはコードに手を入れた。

しかし確認すると、Git管理外で直接ファイルを書き換えていた。git status には何も出ないが、実ファイルは変更済みという状態。発見後、git stash で退避して git pull で正しいリビジョンに戻した。

修正内容の方向性は間違っていなかった（取引時間チェックを入れるべき、という判断は正しい）。ただし実装をGitフローに乗せられなかった。コミットもなく、レビューも通っていない変更がVPSに存在している状態は困る。

実際の修正は自分でやった。_is_market_open() を追加して run_once 冒頭でスキップ処理を挟むだけなので5分で終わった。

def _is_market_open(now_jst: datetime) -> bool:
    wd = now_jst.weekday()  # 0=月 … 5=土, 6=日
    if wd == 6:  # 日曜は終日クローズ
        return False
    if wd == 5:  # 土曜06:55以降はクローズ
        return now_jst.hour < 6 or (now_jst.hour == 6 and now_jst.minute < 55)
    return True

わかったこと

発見は得意、修正は荷が重い。

タスク 結果
ログの異常パターン検出 △（誤認あり）
本物のバグ発見 ○（ERR-5218を発見）
修正方針の立案 ○（方向性は正しかった）
Gitフローに沿った実装 ✗（管理外変更）

Qwen36-35B-A3Bのサイズでエージェントとして動かすと、「何かを見つけて報告する」は回るが、「コードの文脈を保ちながら適切に変更を加えてGitに乗せる」はまだ確率が低い。ツール呼び出しの連鎖が長くなるほど途中でコンテキストが崩れる感覚がある。

次の方針

Hermes Agentの役割を「発見専門」に絞る。

  • 発見 → Hermes Agentがチケットを起票して終了
  • 修正 → 人間（または別途レビューを通したエージェント）が実施

「自律修正」はまだ早かった。でも「自律発見」は普通に役立つ。今回もERR-5218は放置していたら次の週末まで気づかなかったと思う。

検証環境: VPS (Ubuntu) / Hermes Agent / Qwen36-35B-A3B / GMO クリック証券 FX API