10秒でいうと
外部のデータをMCPでつなぎ、指標や考え方を自分で検証する実践例です。
発注と自動売買は扱いません。判断の話はNo.69にあります。
No.48で自作の話をしました。ここでは具体例を1つ通します。題材は市場データですが、やっているのは、外部のデータ提供サービスにつないで、取ってきて、確かめるという汎用的な形です。
先に範囲を書いておきます。このページはデータの取得・可視化・検証までです。注文を出す、自動で売買する、といった話は扱いません。投資判断そのものについてはNo.69で扱います。
なぜこの題材か
3つの理由があります。
外部サービスの仕様が変わりやすい。データ提供サービスのAPIは予告なく変わります。壊れることを前提にした設計を練習するのに向いています。
検証の必要が明確。過去のデータで良い成績が出ても、それが将来を保証しないのは誰でも分かります。AIの出す答えを鵜呑みにしない練習になります。
読み取り専用で完結する。注文を出さないなら、書き込む道具が要りません。No.47で書いた「読むだけから始める」がそのまま成立します。
つなぐ形
具体的なサービス名は挙げません。サービスの提供状況や仕様は頻繁に変わるので、書いた時点で古くなります。代わりに形を書きます。
すでにMCPサーバーがある場合。そのサービスの公式ドキュメントを見て、No.46の手順でつなぎます。読み取り専用の権限で認証を通してください。
無い場合は自作します。No.48の形で、道具を2つか3つ作れば足ります。
@mcp.tool()
async def get_price_history(symbol: str, days: int = 90) -> str:
"""指定した銘柄の日次の終値を取得する。
取得できるのは終値のみ。板情報や約定履歴は扱わない。
データ提供元の都合で欠損する日がある。欠損は「なし」と明記して返す。
Args:
symbol: 銘柄コード
days: 取得する日数。既定90日、最大365日
"""
扱わない範囲と、欠損の扱いを説明文に書くのが要点です（No.48）。データの欠損を黙って埋められると、検証そのものが無意味になります。
使い方の型
第1段階：取ってきて、ファイルに残す。
（銘柄）の直近1年の終値を取得して、data/prices.csv に保存してください。
欠損した日があれば、別途 data/missing.md に一覧を作ってください。
第4章のNo.30と同じで、ファイルに残させるのが要点です。あとから検証できます。
第2段階：可視化する。
data/prices.csv を読んで、終値の推移をグラフにしてください。
出力は data/chart.png。欠損した日は線をつながず、切ってください。
欠損は線をつながない、という一行が地味に効きます。つないでしまうと、無かったデータがあったように見えます。
第3段階：考え方を検証する。
ここが本題です。
data/prices.csv を使って、次の考え方を検証してください。
考え方：（検証したい仮説を1文で）
・検証の手順を先に示して、いったん止めてください
・過去のデータでの結果と、その結果が信頼できない理由を両方書いてください
・「この結果では判断できない」という結論もありうるものとして扱ってください
最後の1行が最も重要です。書かないと、何らかの結論が出てきます。No.02で書いたとおり、Claudeは「分かりません」より「ありそうな答え」を出す性質があります。
検証で必ず聞くこと
出てきた結果に対して、こう聞いてください。
いまの検証について、次を教えてください。
・データの期間が違ったら結果は変わるか
・銘柄が違ったら結果は変わるか
・この検証で確かめられていないことは何か
・偶然でこの結果が出る可能性はどれくらいか
都合のよい期間を選べば、たいていの仮説は成立して見えます。それを自分で潰す質問です。
そして過去のデータで良い成績が出ることは、将来を保証しません。これはNo.69でも繰り返します。
壊れることを前提にする
外部サービスは変わります。鮮度台帳に載せる対象です（本ガイドでは60日ごとに確認しています）。
設計に入れておくとよいもの。
- 取得に失敗したら止まる。古いデータで続けない
- 取得した日時をデータと一緒に残す
- 件数が想定と違ったら報告させる（第4章No.33の「件数を数える」）
3つ目が効きます。1年分を頼んで250件返るはずが80件だったようなとき、気づかないと検証が全部おかしくなります。
やってみよう：検証を、否定側から設計する（5分）
実際にデータをつながなくても構いません。設計の練習です。
プロンプト
“`
次の仮説を検証する手順を設計してください。仮説：（確かめたいことを1文で）
・まず「この仮説が間違っていた場合、どういうデータが観測されるか」
を書いてください
・そのうえで、その観測が可能な検証手順を設計してください
・都合のよい期間を選ぶことで結論が変わりうる箇所を指摘してください
“`期待される結果：先に「間違いの形」が出てから、手順が来る。期間の選び方で結論が変わる箇所が指摘される。
うまくいかないとき：仮説を肯定する手順ばかり出るなら、1つ目の指示が効いていません。「反証の形を先に書く」だけを頼んで、いったん止めてください。
つまずきポイント
データの欠損に気づかない。いちばん多い失敗です。件数と欠損を必ず報告させてください。
都合のよい期間で満足する。期間を変えて再検証する。それだけで多くの仮説が崩れます。
書き込む道具を作ってしまう。このページの範囲では要りません。読むだけで完結します。
検証の結果を判断に直結させる。検証はデータの性質を知るためのものです。判断はNo.69の話で、そこでも銘柄の推奨や売買タイミングは扱いません。
関連ページ
- No.48 MCPサーバーを自作する — つなぐ形
- No.69 投資とお金の学び — 判断についての方針
- No.80 間違いを前提に付き合う — 検証の手順
まとめ
- 扱うのは取得・可視化・検証まで。発注と自動売買は範囲外
- 説明文に扱わない範囲と欠損の扱いを書く
- 判断できない、という結論もありうると明示する
- 外部サービスは変わる。取得の失敗で止まる設計にする
次に読む
※本記事の情報は 2026年8月時点のものです。