AIエージェントでEA開発したらプロップ口座が失格｜バイブコーディングで起きた実事故と対策

まず知っておきたい用語｜EA・cBot・AIエージェントとは？

この記事には、FXやAI開発に関する言葉が登場します。 最初に、重要な用語だけ簡単に整理しておきます。

例えばAIエージェントに「日次損失を管理するEAを作って」と指示すると、AIは必要なプログラムを考えて作成してくれます。

MT4版をMT5版へ作り直したり、cBotに新しい機能を追加したりすることもできます。

便利なのは、細かなコードを人間がすべて書かなくてもよい点です。

ただし、人間が説明していない部分までAIが判断してくれることが、思わぬ問題につながる場合もあります。

今回の事故は、まさにその例でした。

実体験｜利益が出ていたチャレンジ口座が日次損失で失格した

私がプロップファーム向けに開発しているEAには、損失が一定額に達したら取引を停止する機能を組み込んでいます。

これは、プロップファームの失格条件に触れないようにするためです。

例えば、規約上の日次損失上限が5％だったとしても、私は5％ぎりぎりまで取引する設計にはしません。

価格が急に動いたり、決済注文が予定どおりに成立しなかったりする可能性があるためです。

※5％・4.5％・4.0％は仕組みを説明するための例です。実際の設定は各社・プランのルールやEAの取引内容によって変わります。この設定で失格を防げると保証するものではありません。

ところが、失格後にコードを調べたところ、規約上限の5％そのものが強制決済の開始ラインになっていました。

つまり、損失が5％に達した瞬間に決済を始める設計です。

私はAIへ、安全のために余裕を持たせる意図を伝えたつもりでした。

しかし、何度か修正を重ねるうちに、その考え方が最終的なプログラムから抜け落ちていました。

結果として、売買手法ではなく、損失を管理するプログラムの設定が原因でチャレンジ口座を失うことになりました。

一番怖いのは「プログラムは正常なのに失敗する」ケース

今回の経験で特に重要だと感じたのは、プログラムの不具合と、設計そのものの間違いは別だということです。

この場合、AIが作ったコードは正常に動いているかもしれません。

損失が4.9％なら取引を続け、5％になったら決済処理を始める。 プログラム上の条件判定は正しく動いています。

それでも、プロップファームで安全に運用するという目的には合っていません。

AIを使った開発では、コードを見るだけでなく、AIがどのような動作を正しいと考えて作ったのかまで確認する必要があります。

「日次損失5％を守る」だけでは指示が足りない

現在の私なら、AIへ「日次損失5％を超えないようにしてください」とだけ指示することは避けます。

代わりに、どの数値になったら何をするのか、具体的に決めます。

例えば、規約上限が5％の場合でも、新規注文を4％で止め、4.5％で保有ポジションを決済する、といった設計が考えられます。

ただし、損失の計算方法はプロップファームによって異なります。

現在の口座残高を基準にするのか、含み損益を含めた口座資産額を基準にするのか、日付が変わったときにどの値を使うのか。

こうした条件も確認しなければなりません。

また、ポジションを複数持っている場合は、それぞれの損失だけではなく口座全体の損失を見ます。

安全マージンは、AIが適当に決めてよい数値ではありません。 EAを運用する人間が、ルールとリスクを確認して決めることが重要です。

2026年10月｜高性能なAIに変えれば事故はなくなるのか？

AIの性能は短期間で大きく進化しています。

私自身もCodexを中心に開発し、作業内容やコストに応じてAIモデルを使い分けています。

2026年9月29日には、OpenAIがGPT-6.1 Solを公開しました。 また、GPT-6 SolやGPT-6 Lunaなど、用途や性能の異なるモデルも提供されています。

では、より高性能なAIに変更すれば、今回のような事故はなくなるのでしょうか。

私はそうは考えていません。

性能が向上すれば、複雑なコードの理解や修正、プログラムの不具合を見つける能力も改善する可能性があります。

しかし、人間が決めていないルールについては、高性能なAIでも何らかの判断をしなければなりません。

例えば「安全にしてください」と依頼しても、どこまで損失を許容するかが決まっていなければ、AIはその部分を推測します。

OpenAIが2026年10月2日に公開したモデルガイドでも、AIに求める結果や守るべき条件を明確にし、どの判断に人間の承認が必要なのかを決める考え方が示されています。

EA開発では売買手法より「動かし続ける仕組み」が難しい

エントリー条件と決済条件だけなら、現在のAIでもかなり速くEAを作れます。

しかし、実際に自動売買を動かす場合は、それだけでは足りません。

例えば、損失上限へ近づいたためEAが取引を停止したとします。

その直後にVPSを再起動したら、どうなるでしょうか。

EAが停止したことを忘れて、再び新規注文を出してしまったら危険です。

反対に、翌日になっても前日の停止状態が解除されず、いつまでも取引できないのも問題です。

つまり、EAには「いつ止めるか」だけではなく、「いつ、どの条件で再開してよいか」も必要になります。

cTraderでは、CloudとローカルPC・VPSによって保存データの扱いも変わります。

この違いは、 cTrader CloudとVPS・ローカルでcBotの保存・再起動の仕組みを解説した記事 で詳しく説明しています。

6社×複数ロジックでは、AIの作業範囲も管理する必要がある

今回、もう一つ大きな問題になったのが、AIエージェントに任せる作業の範囲でした。

私は現在、おおよそ6社のプロップファームに対して、5種類程度の売買ロジックを組み合わせています。

単純に掛け合わせるだけでも約30系統です。

さらに、各社のプランやMT4・MT5・cTraderの違いを考えると、管理するプログラムはもっと増えます。

そこで私は、プロップファームやプラン、取引ツールごとにフォルダを分け、AIエージェントにも担当する範囲を分けて作業させていました。

半年以上その方法で開発を続けていましたが、ある日、大きな事故が発生しました。

AIが修正範囲を広げ、関係ない大量のEA・cBotまで書き換えた

あるプロップファーム向けのEAで見つかった問題を参考に、別のプロップファーム側にも同じ修正を入れるようAIへ依頼しました。

私が想定していたのは、限られたファイルだけの修正です。

ところがAIは、その変更を「ほかのシステムにも共通して必要な改善」と判断したようでした。

その結果、別会社のフォルダや、修正を依頼していないEA・cBotまで書き換えられてしまいました。

便利な機能ですが、AIと人間で「どこまで直すのか」という認識が違うと、想定外の変更につながります。

気づいたときには、多数のファイルが変更済みでした。

そこで「すべて元に戻して」とAIに頼んでも、必ず元どおりになる保証はありません。

変更前のファイルが残っていなければ、何十ものプログラムを完全に復元することは難しいからです。

数時間かけて復旧できたのはバックアップが残っていたから

幸い、私は開発作業がある程度まとまるたびに、ファイル一式をZIP形式で保存していました。

さらに、実際に稼働していたEA・cBotのファイルも、VPSや取引環境などに残っていました。

そのため、変更前のファイルと現在のファイルを比べながら、必要な部分を戻すことができました。

それでも、復旧には数時間かかっています。

特にプロップファーム向けEAでは、売買手法と損失管理の設定が密接に関係します。

一部の修正が別のEAへ影響すると、複数口座で同時に問題が発生する可能性もあります。

バックアップは単なる保険ではありません。 AIを使って安全に開発を続けるための基本的な仕組みだと考えています。

AIエージェントには「変更してよい範囲」を明確に伝える

今回の経験を踏まえると、AIへプログラムを修正させる場合、作業内容だけでなく、変更できる範囲も伝える必要があります。

例えば「このEAの損失管理を直してください」だけでは、関連する別のEAまで修正される可能性があります。

私なら、次のように指示します。

さらに重要な設定を変更するときは、AIが勝手に判断しないようにします。

このように、AIが作業できる範囲と、人間の許可が必要な範囲を分けておくと管理しやすくなります。

ただし、文章で制限を伝えるだけで完全に防げるわけではありません。 実際の作業フォルダや書き込み権限も分けるなど、仕組みで制限する方法も重要です。

すべてを「AIのハルシネーション」で片付けない

AIで問題が発生すると、何でも「ハルシネーションだった」と説明されることがあります。

ハルシネーションとは、AIが事実と異なる情報を、正しい情報のように出力してしまう現象です。

しかし今回のようなEA開発では、問題の原因を分けて考えた方が対策しやすくなります。

例えば、古いルールを参照したことが原因なら、AIの性能を上げるだけでは解決しません。

一方、修正範囲を広げすぎたことが原因なら、情報を新しくするだけでは意味がありません。

何が間違っていたのかを正しく見つけ、その原因に合った対策をすることが大切です。

プロップファームでは「古い規約を正確に実装」しても失敗する

プロップファーム向けEA・cBotでは、AIが参照する情報の新しさも重要です。

各社の日次損失、最大損失、ニュース取引、週末のポジション保有、自動売買やコピー取引の条件などは、変更される場合があります。

例えば、AIが古いルールを読み込み、その内容を正確にプログラムへ組み込んだとします。

コードには間違いがなくても、現在の規約と違う設定になっていれば問題です。

私なら、プロップファームのルールもEAの設定ファイルと同じように管理します。

公式ルールが変わったら、現在使っているEA・cBotの設定と比較し、必要な箇所だけ修正します。

そして、変更したプログラムをテストしてから本番環境へ反映します。

プロップファームの重大な禁止事項については、 プロップファームで失格・利益取消しを避けるために確認したいルール5選 でも整理しています。

AIに投資判断や安全設計まで丸投げしない

AIの性能が高くなるほど、「勝てるEAを作って」「プロップファームに合格するEAを作って」という指示でも、完成品のようなコードが出てきます。

しかし、それをそのまま実運用できると考えるのは危険です。

利益が出るかどうかだけではなく、損失をどこまで許すか、相場急変時にどうするか、ルールに触れそうなとき何を止めるかを考える必要があります。

私の考えでは、AIをすべての判断を任せる責任者にするより、プログラム作成、コードの確認、テストを支援する担当者として使う方が管理しやすいと感じています。

人間がルールを決め、AIがそのルールを実現する。

そして、完成したプログラムが本当に期待した動作をするのか、人間が確認することが大切です。

バックテストで勝っても、実際の運用が安全とは限らない

EA開発では、バックテストの利益グラフへ目が行きがちです。

バックテストとは、過去の価格データを使って売買プログラムの動きを検証する方法です。

しかし、過去の相場で良い成績が出たとしても、実際の運用で問題なく動くとは限りません。

例えば、VPSを再起動したときに損失管理が正しく復元されるかどうかは、通常の売買バックテストだけでは十分に確認できません。

フォワードテストとは、過去データではなく、現在動いている相場でプログラムの動作を確かめる方法です。

また、EAの設定を過去の相場に合わせすぎると、バックテストだけ良い成績になり、将来の相場では通用しない場合があります。

私はEAを作るとき、利益率だけでなく、最大連敗や最大ドローダウン、複数ポジションを持ったときの損失も確認するようにしています。

私ならAIエージェントでプロップファーム向けEAをこう開発する

今回の経験を踏まえると、AIを使ったEA開発は「指示を出してプログラムが完成したら終了」ではありません。

ルール確認、設計、プログラム作成、テスト、実運用、その後の更新までを一つの流れとして考える必要があります。

特に重要なのは、問題が起きたときの動作です。

例えば、口座情報を正しく取得できなかった場合、損失管理の基準が分からなくなることがあります。

そのような状態で新規注文を続けるのではなく、少なくとも新規注文を停止し、状況を確認できるようにする設計が考えられます。

ただし、通信障害中はEA・cBotからの決済指示も成立しない場合があります。 プログラムだけですべてのリスクを防げるわけではありません。

日次損失と最大損失の管理に加え、重要経済指標の発表前後に新規注文を止める機能や、複数ポジションをまとめて監視する機能も必要に応じて組み込みます。

また、VPSやcTrader Cloudなど実際に利用する環境で動作を確認します。

これらの検証を終えてから本番環境へ反映する方が、AIの修正による予期しない問題を減らしやすくなります。

AIを使う目的は、最終的に人間の操作ミスを減らすこと

今回、私はAIを使った開発で二つの大きな失敗を経験しました。

一つは、損失管理の設定が意図どおりになっていなかったことで、チャレンジ口座が失格したことです。

もう一つは、AIが修正対象を広げ、関係のない大量のEA・cBotまで変更してしまったことです。

それでも私は、AIをEA開発から遠ざけるべきだとは考えていません。

プロップファームでは、ロットの入力ミス、損切り設定の間違い、取引停止の忘れなど、人間が手作業で行うことにもリスクがあります。

こうした作業を適切にプログラム化できれば、操作ミスを減らせる可能性があります。

大切なのは、AIにすべて考えてもらうことではありません。

人間が判断すべきことを明確にし、AIの得意な作業を活用すること。

これが、現在の私が自動売買システムを開発するときに重視している考え方です。