コンテンツにスキップ

AIにEA開発を任せる時代の品質管理——「報告」を信じるのをやめた話

発注書と検収印——高いAIの決定と安いAIの実装

私のPCでは毎晩、AIがFXのEA（自動売買プログラム）を自動生成しています。この開発パイプラインの裏側で、最近もう一つ大きな作り替えがありました。実装作業そのものを、賢いAIから安いAIへ外注する仕組みです。

コンパイルが通る、動く、儲かるは別問題

EA開発をAIに任せていて痛感するのは、「コンパイルが通る」「実際に動く」「取引して意味のある結果になる」がそれぞれ別問題だということです。もっともらしく見えるコードほど、一見動きそうで実は一度も取引しない、という落とし穴があります。

同じ落とし穴は、EAのコードに限らず、AIに実装作業全般を任せるときにも顔を出します。実装を担当したAIは、たいてい「完了しました。テストも通っています」と自信満々に報告してきます。以前、AI同士にコードレビューをさせる会議形式の検証で、最強クラスのAI自身が、自分の書いたコードを「テスト全部green、完璧です」と誤認していたことがありました。実際には複数の別AIが独立に同じバグを指摘していたのです。最強のAIですら自分の報告を過信するなら、安いAIの「完了しました」を鵜呑みにする理由はありません。報告は成果物ではない——これが、今回の作り替えの出発点でした。

なぜ「安いAIに実装させる」のか

最もクラスが高いAIは、API換算で出力100万トークンあたり50ドルします。しかも使える量に上限があり、常時お願いし続けることはできません。一方、実装作業のトークンの大半は「計画の詳細化」「コード本文」「検証ログを読む作業」で占められています。賢さが本当に必要なのは、何を作るか・何を作らないか・合否をどう判定するかという、ごく一部だけでした。

そこでまず試したのが、高いAIが計画書を書き、安いAI（API換算で出力100万トークンあたり15ドル、導入価格なら10ドル）が実装するという単純な分業です。コストは下がりましたが、冒頭の「完了しました」を信じられない問題は残ったままでした。

解決策：受け入れテストを、発注前に書く

作り替えの核は「受け入れ契約」です。発注する前に、高いAIが合否の定義そのものを、実行可能なテストとして書いておきます。実装担当のAIは、このテストファイルに触れることを許されません。テストが緑になるまで、完了とは名乗れない。検収は目視の確認ではなく、テストの再実行に置き換わりました。

この作業の途中で、良い気づきがありました。「トーンが良い」「なんとなく綺麗」といった、テストに書き下せない品質基準が残っているなら、それはまだ発注してはいけないタイミングだということです。曖昧な仕様を実装者に押しつけていただけでした。

さらに、委譲のたびに予測した手戻り回数と実際の手戻り回数を記録に残し、そのズレから発注書の書き方自体を較正していきます。実装者が現場で踏んだ落とし穴は、申し送り書として自動的に蓄積され、次に実装を任されるAIが必ず最初に読む仕組みにしました。回すたびに、外注の精度が上がっていきます。

実測：計画書69行、実装171行、差し戻しゼロ

最初にこの仕組みで委譲したのは、この外注管理の仕組みそのものを外注するという、少しメタな初仕事でした。高いAIが書いたのは計画書69行と合否テスト96行だけ。安いAIが書いた実装は171行とテスト一式で、差し戻しはゼロ、一発で検収を通りました。

仮定つきの試算も置いておきます。中規模の実装1件を「入力30万・出力3万トークン」と仮定すると（1ドル=150円換算）、全部を高いAIにやらせた場合は約4.5ドル（約680円）、全部を安いAIにやらせた場合は約1.35ドル（導入価格なら0.9ドル）。分業なら約2.2ドル前後、ほぼ半額という計算になります。出力単価そのものの差は約3.3〜5倍です。これらはAPI換算の試算であり、実際には契約プランの枠内で高いAIを動かしていることがほとんどです。

ただし、本当の節約は円ではありません。高いAIの持ち時間です。実装本文を書かせないことで、高いAIの出力は計画・契約・レビューの短いやり取りに圧縮されます。

EA開発・自動売買の現場への教訓

この話は、AIの実装外注に限った話ではないと思っています。人間の業者にEA開発を外注するときにも、そのまま使える教訓です。

  • 検収条件（何をもって合格とするか）を書けないなら、発注してはいけない
  • 合否基準は発注者が書く。受注者に基準づくりまで任せてはいけない
  • 外注がうまくいかなかった記録は残し、次の発注に活かす

「コンパイルが通ったから完成」「テストが通ったと言われたから完了」——EA開発でも、このあたりの検収の甘さが後になって効いてきます。合否の基準を、発注する前に、検証可能な形で言語化しておくこと。それだけで、外注の精度は大きく変わります。

まとめ

  • 実装のうち賢さが必要なのは「何を作るか・作らないか・合否をどう決めるか」だけ
  • 報告は成果物ではない。検収は目視でなくテストの再実行で行う
  • 発注前に合否テストを書けないなら、仕様が固まっていないのは発注者の方
  • 外注の失敗は記録に残し、次の発注書の精度に反映する

自動売買EAの開発パイプラインも、結局のところ同じ規律で回っています。今後もこのコラムで、開発体制の裏側を報告していきます。

本記事は個人の検証メモです。AIサービスの料金・仕様は2026年7月時点のもので、今後変わる可能性があります。EA自動売買には元本割れのリスクがあります。投資判断はご自身の責任でお願いします。

関連リンク

— SPONSORED —