結論から書きます。AI（大規模言語モデル、以下LLM）に自分の取引ルールを読ませる価値は、「良い改善案をもらうこと」ではなく「自分が書いたつもりで書けていなかった箇所を指摘させること」にあります。矛盾・未定義・曖昧という三種類の指摘だけを拾い、改善案は採用せず仮説としてバックテスト（過去データでの検証）行きにする。この線引きを守れば実用的な点検ツールになり、守らないと検証していないパラメータが静かに混入します。
この記事では、読ませる前の準備、質問の型、指摘の仕分け方、そしてこの使い方が機能しない条件までを順に書きます。
なぜAIの指摘をそのまま採ってはいけないのか？
理由は三つあります。
一つ目は、LLMが提示する改善案は一般論であって、あなたの口座・通貨ペア・時間足での検証を経ていないからです。「損切り幅はATR（平均的な値幅を表す指標）の何倍にすべき」といった提案は、文章としてはもっともらしく出てきますが、その倍率の根拠はあなたのデータにありません。採用した瞬間、あなたのルールの中に「誰も検証していない数字」が1つ増えます。
二つ目は、ハルシネーション（事実でない内容をもっともらしく生成する現象）です。指標名の定義、取引時間、仕様の説明などを断定口調で誤ることがあります。一方で「この条件とこの条件が同時に成立したときの優先順位が書かれていない」といった、入力テキスト内部の整合性に関する指摘は、原文と突き合わせれば自分で真偽を確認できます。検証コストが低い指摘ほど価値が高い、という順番で扱うのが安全です。
三つ目は追従性です。対話を続けるほど、こちらの意図に沿った回答へ寄っていく傾向があります。「このルール、良いと思いますか」と聞けば肯定が返りやすい。だから聞き方を設計する必要があります。この境界の考え方はAIのチャート読みは「仮説生成」までが安全圏 ― 売買判断に渡してはいけない境界線で書いた線引きと同じで、出力の用途を事前に固定しておくことが前提になります。
読ませる前に、ルールを「実行手順」に書き直す
点検の精度は、入力の形で決まります。「トレンドに沿って押し目で買う」という書き方のまま読ませると、LLMは不足部分を自分で補完して読んでしまい、矛盾が表面化しません。次の形に書き直してから渡します。
- 判定時点を明記する — 「確定足の終値で判定」「ティック到達で即時判定」など。未確定足を参照していないかを後で検査できる形にする
- 入力データを列挙する — 通貨ペア、時間足、使う指標とそのパラメータ、参照する期間
- 条件を番号付きの箇条書きにする — 「かつ」「または」を日本語で明示し、入れ子は分解する
- 状態遷移として書く — 待機 → エントリー保留 → 保有 → 部分利確後 → 手仕舞い済み、のように状態を定義し、各状態で許される行動を書く
- 例外と停止条件を分けて書く — 停止の設計は連敗後の停止ルールは回数で決めないで扱った通り、回数以外の基準を含めて明文化しておく
この書き直し作業それ自体で、抜けの半分近くが自力で見つかることがあります。AIに渡す前の工程が、すでに点検です。
AIに何を聞けば矛盾が出るのか？
「改善点を教えて」は最も効率の悪い指示です。一般論の羅列が返ってきます。検査項目を指定して、テキスト内部の整合性だけを見させます。
- 未定義の検出「このルールのどの条件にも当てはまらない市場状態を、具体的に列挙してください。該当なしなら、そう書いてください」
- 優先順位の欠落「複数の条件が同時に成立し得る組み合わせを列挙し、それぞれ優先順位が本文に書かれているかを○×で示してください」
- 曖昧語の抽出「人によって解釈が割れる語を本文から抜き出し、なぜ割れるかを書いてください」
- 未来参照の疑い「各条件について、判定時点で実際に入手できるデータだけで判定できるかを確認してください」
- 再現性テスト「このルールだけを読んだ第三者が、同じ場面で同じ判断に至りますか。至らない箇所を指摘してください」
加えて有効なのが反対役を明示的に割り当てるやり方です。「あなたはこのルールの欠陥を探す検査役です。良い点は書かないでください」と役割を固定すると、追従による肯定が減ります。さらに、同じ入力を別セッションで独立に複数回投げ、繰り返し出てくる指摘を優先する、という使い方もできます。会話を続けて深掘りするより、独立した一発質問を並べるほうが指摘の偏りを見やすくなります。
見落とされやすい抜けはどこに出る？
経験上、指摘が集まりやすいのはエントリー条件ではなく、その周辺です。自分で点検するときのチェック項目としても使えます。
- エントリー待機中に反対方向のシグナルが出た場合の扱い
- 指値が約定しなかった場合に、注文をいつ取り消すか
- 部分利確した後の損切り位置を、動かすのか動かさないのか
- 保有中に経済指標やイベントが来る場合の扱い。週末・連休をまたぐ場合の扱い
- スプレッド拡大時・約定拒否時の代替行動
- ロットを資金比率で決めている場合、残高を再評価するタイミング
- データ配信が止まった、指標値が欠損した場合の既定動作
たとえば次のような場面です。「終値がラインを上抜けたら買い」と書いてあるが、同じ足で別条件の売りシグナルも成立していた。ルール本文には優先順位の記述がなく、過去の自分は都度その場で判断していた——こういう箇所は、記録を見返しても気づきにくい一方、テキスト検査ではほぼ確実に表面化します。
指摘をどう仕分ける？ — 採用・保留・却下の三分類
返ってきた指摘は、内容ではなく検証の必要性で分類します。
| 分類 | 該当する指摘 | 次の行動 |
|---|---|---|
| 即時採用 | 矛盾・未定義・曖昧語の指摘で、原文と照合して事実だと確認できるもの | ルール文書を改訂。売買の中身は変えず、書き方だけを確定させる |
| 保留（仮説） | パラメータ変更、条件追加、フィルタ提案など、優位性に関わる改善案 | 仮説リストに入れ、バックテストと前進検証を経てから判断。未検証のまま入れない |
| 却下 | 事実関係の誤り、一般論の繰り返し、出典のない数値、自分の運用時間や資金で実行できない提案 | 却下理由を1行で残す。同じ指摘が再発したときの判断材料になる |
重要なのは即時採用の対象が「書き方の修正」に限られる点です。優先順位を明記する、曖昧語を数値条件に置き換える、未定義状態に既定動作を与える——これらはルールの挙動を確定させるだけで、新しい賭けを増やしません。一方、条件追加は賭けを増やします。両者を同じ机で処理すると、改訂のたびに未検証要素が積み上がり、どこから成績が変わったのか追えなくなります。
なお、保留に回した案を検証するときは、採用したい気持ちが先に立ちやすい点に注意が必要です。提案を思いついたのがAIでも自分でも、過剰最適化（過去データに合わせ込みすぎて将来に通用しなくなること）のリスクは変わりません。
この使い方が機能しない条件
万能ではありません。次の場合、点検の精度は大きく落ちます。
- 裁量の比率が高い手法 — 「地合いを見て」が判断の中心にある場合、テキスト化した時点で別物になります。検査できるのは言語化できた部分だけです
- ルール文書が長すぎる — 入力が長いと後半の読み落としが起きやすくなります。セクション単位に分割して渡し、最後に「セクション間の矛盾」だけを別途聞くほうが確実です
- 同じモデルに繰り返し聞く — 同種の指摘に収束し、見えていない穴は見えないままになります。指摘が出なかったことは、穴がないことの証明にはなりません
- 検証環境が無い段階 — 保留に回した仮説を処理できないため、提案が溜まるだけになります
- 機密性の扱い — 口座番号や個人を特定し得る情報は入れない。入力の取り扱いは利用するサービスの規約を自分で確認してください
また、生成されたコードをそのまま動かす場合は、文章の点検とは別の確認が要ります。実装側の落とし穴はAI生成の売買コードで最初に潰す3つの穴にまとめています。
まとめ
整理します。
- 渡す前に、ルールを状態遷移と判定時点を含む実行手順へ書き直す。ここで抜けの一部は自力で見つかる
- 「改善点」ではなく「矛盾・未定義・曖昧語の検出」を指示し、検査役を割り当てる
- 返ってきた指摘を、即時採用（書き方の修正）・保留（要検証の仮説）・却下に三分類する
- 優位性に関わる提案は、検証を通るまでルールに入れない
- 指摘が出なかったことを、穴がないことの根拠にしない
この手順は、勝率を上げるためのものではありません。同じ場面で同じ判断ができる状態をつくり、成績の変化を後から追える形にするためのものです。ルールが確定していなければ、検証結果も記録も意味を持ちません。記録側の整備については売買記録をAIに読ませる——「当たる予想」ではなく自分の癖を言語化するための使い方も併せて参照してください。
最後にリスクについて。AIの出力には誤りが含まれ得ます。本記事の手順を踏んでも損失を避けられるわけではなく、相場環境が変わればどんなルールも機能しなくなります。ルール文書の改訂履歴を残し、変更前後で成績を分けて記録することを前提に、自己責任の範囲で進めてください。
この記事は、AI で下書きを作り、益山康秀（運営者）が内容を確認して公開しています
この記事は情報の提供を目的としたもので、特定の金融商品の売買をすすめるものではありません。売買の判断は、ご自身の責任で行ってください。（運営者情報）
