AIで保有株の状況確認から売買判断までを手順化した話...Skills

Claude.aiには「Skills」という仕組みがある。会話のたびにAIが参照する「手順書」をMarkdownで書いておくと、その手順をベースにプロンプトを実行する。

これを使って、保有株の状況確認から売買判断までの一連の流れをSkillにまとめた。やってみて分かったのは、これは単なる自動化ではなく、AIとの協業における「品質管理」の仕組みだということだ。

なぜ毎回の会話では不十分だったか

AIに「今日の保有株はどうか」を聞くこと自体は、Skillがなくてもできる。データを渡して「分析して」と言えばいい状態だった。

問題は、AIが毎回ゼロから始めることだ。

• 前回どこで数字を読み間違えたか、知らない
• 「含み損がある＝損切り検討」と短絡する（保有し続ける理由を知らないから）
• 「もっと早く売っていれば」と言うが、実際に計算すると遅延のほうが得だったりする
• 直近1日のデータだけ見て「分析完了」とする

つまり、過去に犯したミスを毎回繰り返す。人間の担当者なら「前回もそれ言ったよね」で済むが、AIには文脈の持続がない。

Skillとは「対話から蒸留した手順書」

Skillとは、Claude.aiで使えるMarkdownファイルで、特定のタスクに対してClaudeが参照するガイドラインだ。

まとめたSkillの構成は、大きく3層になっている。

第1層：ワークフローの定義

保有株の確認から判断までの手順を7つのステップに分解した。

1. ツールの準備
2. データ取得（当日の保有状況＋過去数日の履歴）
3. マーケット環境の調査（日経平均、為替、原油、金利）
4. データの整理と比較テーブル作成
5. AI分析（市場コンテキスト付き）
6. チャート可視化
7. レポート出力

ポイントは、各ステップに「省略禁止」のルールを入れていることだ。「履歴データは最低3営業日分取得する」「市場環境サマリーを渡さずに売買判断を始めることは禁止」といった制約がある。

これらはすべて、過去の会話で実際に起きた手抜きから導かれたルールだ。

第2層：前提条件の明示

AIが判断する際に必要な「自分の事情」を書いておく層だ。なぜその銘柄を持っているのか、いつ売る予定なのか、税務上の制約は何か。会話のたびに説明し直すのが面倒な情報をここに置く。

これがないと、AIは表面的な数字だけ見て動く。含み損があれば「損切りを検討」と言うが、税損ハーベストのために意図的に持ち続けている銘柄に対してそれを言われても意味がない。個別の事情を織り込んで初めて、汎用的なアドバイスではなく「自分の保有株に対する判断」になる。

第3層：判断の検証フレームワーク（これが本体）

正直に言うと、ワークフローやプロファイルは「あると便利」程度のものだ。Skillの真の価値は、過去の誤判断を構造化したフレームワークにある。

たとえば、こういうルールがある。

「売るべきだった」と言う前に、両方のシナリオを計算しろ

AIは「辛口分析」を求められると、過去の判断を批判しがちだ。だが計算してみると、売却を遅らせたほうが結果的にプラスだったケースがある。このルールは、実際にAIが「売却遅延で約10万円のコスト発生」と分析し、検算したら逆に＋4.3万円のプラスだった経験から生まれた。

結果の良さと判断の質を混同するな

偶然うまくいった取引を「素晴らしい判断」と評価するのも、偶然うまくいかなかった取引を「失敗」と断じるのも、どちらも間違いだ。Skillには「判断品質マトリクス」を入れてあり、「順当／不運／幸運／失敗」の4象限で評価させるようにしている。

過去の誤判断テーブル

Skillの末尾には、過去に実際に発生した誤判断の一覧表がある。何を間違えたか、なぜ間違えたか、実態はどうだったかを記録している。AIはセッションごとにこのテーブルを読むので、同じパターンの誤りを繰り返しにくくなる。

これはいわばAIに渡す「失敗事例集」だ。組織でいえばインシデントレポートに近い。

SkillとMCPサーバーの使い分け

実際のデータ取得は別のMCPサーバーが担っている。MCPサーバーはローカルPCで動くプロセスで、証券口座へのログインやデータ取得など、Claudeのサンドボックスからはできない処理を受け持つ。

Skillはそのデータをどう取得し、どう解釈し、どう売買判断に結びつけるかを定義する層だ。料理に喩えるなら、MCPサーバー（というかPythonコード）が食材の仕入れ担当で、Skillがレシピと品質基準書にあたる。

やってみて思うこと

約20回分のセッションの試行錯誤がこのSkillには圧縮されている。最初は「今日の保有株を確認して」の一言で始まった会話が、AIの力も借りながら、いまでは500行のワークフロー定義になった。

面白いのは、このSkillの改善プロセス自体がAIとの対話で進むことだ。判断に問題があれば指摘し、その指摘をSkillに反映する。次のセッションではその問題は起きない。AIが賢くなったのではなく、手順書が賢くなったのだ。

これはプログラミングでテストケースを積み上げていく作業に似ている。バグを見つけたらテストを書く。テストがあるから同じバグは再発しない。Skillは、AIとの売買判断における「テストスイート」のようなものかもしれない。

使った事例が株の売買判断だったのは、正直なところ例題として最善ではなかったかもしれない。AIの分析はあくまで判断材料であって、最終決定を委ねるものではないという限界もある。

ただ「AIに繰り返し作業をさせるとき、品質をどう担保するか」という問いは、株に限らず普遍的だ。プロンプトを毎回書き直すのではなく、Skillの改善を現在進行形で続けながら、学びを構造化して永続させる。Skillsはその一つの方法だった。