データとプロンプト—入力構造と検証規律

1. 出発点：アウトプットの品質はインプットの構造に左右される

レッスン1では、AIが取引ワークフローのどこに組み込まれるかを6つの観点から概説し、情報整理を最前線に据えました。要約が不正確だったり、日付が混ざっていたり、出典が追跡できない場合、その後の仮説生成、バックテストの議論、リスク管理チェックリストは、最初のバイアスを増幅するだけです。そのため、レッスン2では「より良い質問をする」テクニックよりも、入力段階で必要な構造的な規律について議論し、モデルの出力はデフォルトで検証の対象とし、確立された事実として扱わないようにします。

取引の文脈におけるハルシネーションは、モデルが意図的に嘘をついているというよりも、流暢で自信に満ちた内容を生成するものの、検証可能な一次情報に紐づけられない状態を指します。具体例として、存在しない発表やリンクの捏造、循環供給量で時価総額を誤認させる、現在の問題に古いデータを当てはめる、アドレスや時間枠、統計基準を示さずに「オンチェーンデータが示す」といった表現が挙げられます。解決策はAIを完全に排除することではなく、意思決定チェーンに入るすべての情報に対して、ソースレベル、時間境界、検証手順を指定することです。

2. 情報源のグレーディング：実用的な分類フレームワークの構築

AIに資料を投入する前に、情報源をグレーディングし、プロンプト内で各重要ポイントにグレードをラベリングするようモデルに指示するのが望ましいです。グレーディングの目的は形式主義ではなく、どの内容が事実として述べられるべきか、どの内容が単なる手がかりや未検証の判断に過ぎないかを明確にすることにあります。

• 一次ソースには、公式プロジェクトウェブサイト、GitHubのリリース記録、取引所や規制当局の発表、ブロックチェーンエクスプローラー、エクスポート可能なトランザクションデータが含まれます。これらの資料は比較的信頼できますが、フィッシングページや偽造された発表に注意が必要です。リンクやドメインは手動で確認する必要があります。

• 二次ソースには、研究機関のレポート、監査文書、準備証明ページが含まれます。これらはメカニズムの理解に役立ちますが、発行日と監査範囲が現在の構造をカバーしているかどうかを確認する必要があります。

• メインストリームメディアによる政策の解釈は参照できますが、主要な結論は一次文書と照合する必要があります。

• ソーシャルメディア、KOL、コミュニティコンテンツは、問題発見の入り口としてのみ適しており、単独で取引を正当化すべきではありません。匿名のスクリーンショットや「内部情報」は、デフォルトで取引ロジックから除外されます。

プロンプトでは、事実の記述には高グレードのソースのみを使用し、中・低グレードのソースは「報告によると」または「未検証」とラベル付けし、ソースや日付のない項目は一律に検証対象としてマークするといった要件が必要になるかもしれません。モデルが誤りを続けても、この出力形式によって手動フィルタリングが容易になります。

3. タイムスタンプと基準：暗号資産データは「新しいコンテキストで古いデータ」になりがち

モデルのトレーニングデータと検索能力はリアルタイムの開発に遅れをとり、プロジェクトのメカニズムは頻繁にアップグレードされます。クエリの際は時間範囲を指定してください。たとえば、特定の日付以降の資料のみを分析し、古い可能性のある情報には「[日付]時点」とフラグを立てます。価格や指標を比較する場合は、ローソク足の間隔、取引所、取引ペア、スポットか先物かを指定します。オンチェーンの統計については、チェーン名、コントラクトアドレス、統計ウィンドウ、取引所の入出金を含めるかどうかを明示します。同じ質問でも基準が異なれば結論が逆になることがあります。基準は後付けではなく、固定のプロンプトフィールドとすべきです。

4. 生存者バイアスと矛盾する証拠

暗号資産に関する議論では、利益を出した事例だけが取り上げられ、強気相場のサンプルしか使われず、上昇局面のバックテストが引用されることがよくあります。AIのナラティブは、失敗した同時期のサンプルを無視して、話を完全なものに見せようとする傾向があります。対策としては、賛成と反対の両方の証拠を求めること、サンプルサイズと期間を指定すること、証拠が不十分な場合は「判断できない」と明示し、結論を無理に導かないことなどが挙げられます。研究志向の対話は、ロング/ショートの推奨を直接出力するよりも、シナリオや失敗条件を提示するのに適しています。

5. プロンプトの構造：修辞的な華美さよりも形式の制約

効果的なプロンプトには通常、4つの部分が含まれます：

• スコープステートメント：リサーチアシスタントの役割、トークンの推奨なし、リターンの保証なし

• 制約条件：捏造されたリンクなし、不確実性をマーク、ソースグレーディングルール

• 出力形式：論拠、根拠、ソースグレード、日付、無効化条件

• 検証手順：手動チェックが必要（例：発表URLの確認、オンチェーントランザクションハッシュの検証）

各会話の最後に、仮説や取引ステップに進む前に手動で完了すべき検証チェックリストを生成します。プロンプトの長さは重要ではなく、重要なのはソース、時間枠、基準が固定されているかどうかです。

6. データの分業：数字は人間が提供し、モデルが解釈を担当

より堅牢な分業とは、市場データとオンチェーンデータをAPI、取引所、またはエクスプローラーからエクスポートし、生のテーブルまたは明確なフィールドでAIに貼り付けることです。モデルはその意味を解釈し、不整合を特定し、仮説の構造化を支援しますが、重要な値を独自に生成することはありません。モデルが計算に関与する場合は、数式と中間ステップを表示させ、コアとなる結論は手動で再計算します。長い会話はコンテキストドリフトのリスクを伴います。重要なトピックは新しいスレッドで開始し、検証済みの事実は別個にアーカイブし、後続のやり取りでは参照のみとしてコンテキストの汚染を減らします。

7. レッスンのまとめ

このレッスンでは、AIを使用する前のステップ、すなわち資料の出所、日付や基準の有無、低グレードのソースが取引の根拠として使用できるかどうかについて扱いました。ハルシネーションやサバイバー・ナラティブは、通常、モデルが「意味不明なことを言っている」のではなく、入力に含まれる検証不可能な記述、古いデータ、または好都合な成功事例の選択に起因します。ソースグレーディング、時間的境界、検証チェックリストを固定プロセスに組み込むことで、出力はデフォルトでドラフトとなり、仮説やポジションの議論に入る前に検証が必要になります。次のレッスンでは戦略の検証を扱います。入力を整理した後、データ、コスト、アウトオブサンプルの結果を個別に精査する必要があります。バックテストの曲線だけでは戦略を検証できません。