見出し画像

コストかけずにAI分析を自動で毎日回す方法【スマホで周回!#10】

こんにちは、スマホ投資パパです。

スマホだけでできる米国株の自動分析システムの第10回目になります。

前回の記事では、私が運用している自動分析システムの全体設計と各モジュールの役割、そしてなぜ私が自分のシステムを公開しようと思うに至ったかを紹介しました。

今回は、このシステムから直接、生成AIを呼び出せるという話をします。

スマホで運用している自分のシステムが、必要な時にGPT-4系のような高機能LLMをAPI経由で叩いて、結果を受け取る。ChatGPTの画面を開いて貼り付けて……みたいな手作業ではなく、自動で生成aiに指示して動かすことができる。

しかも個人運用の範囲なら、追加料金をほとんど払わずに使える仕組みがあります。

これ、まあまあすごいことだと思いませんか?

本記事を読むと、以下が分かります:

- 自分のシステムからLLMを直接呼ぶ、とはどういうことか
- GitHub Models APIという選択肢
- 私がこれまでに試したLLMツールたち
- どんな用途ならLLMが活きそうか
- 取っかかりとなるプロンプトの例


1. 自分のシステムからLLMを呼ぶとは

私のシステムは数値の集計・スコアリング・ブレイクアウト検知などを自動化してきました。すべて数値の世界の話です。

ところが、相場の判断に必要な情報は、数値だけではありません。決算ニュース、業界動向、地政学リスク。こうした文章で書かれた情報は、自動化のループから外れがちです。

ここでLLMが登場します。
LLM(Large Language Model)は、ChatGPTの中身でもある「大規模言語モデル」のことで、APIから直接呼び出して自分のシステムに組み込むことができます。

LLMをAPI経由で呼べば、自分のシステムが必要な時に:

- 大量のニュースを要約してSlackに送る
- 決算資料の論点を抽出してCSVに整理する
- 銘柄のテーマを自動でタグ付けする

こうした「自然言語が絡む処理」を、自動処理の中に組み込めます。

これがChatGPTを開いて貼り付けて……の世界と決定的に違うのは、人手を介さずシステムが直接呼び出せる点です。GitHub Actionsでスケジュール実行している自動分析の流れの一部として、LLMが組み込まれている。スマホだけで運用している自分のシステムが、必要な時に高機能LLMを叩いて結果を受け取る。

地味ですが、数年前なら考えられなかった世界です。


2. GitHub Models APIという選択肢

その世界を実現する手段の一つが、GitHub Models APIです。

GitHubが提供する開発者向けのLLM呼び出しサービスで、特徴は以下の通り:

- GitHubアカウントだけで始められる:複数のLLMを共通インターフェースで呼び出せる
- 対応モデルが豊富:GPT系、Claude系、Llama系などを切り替え可能
- 共通APIで叩ける:モデルが違ってもコード変更が最小で済む
- GitHub Actionsとの相性が良い:認証が同じエコシステム内で完結する

無料枠も用意されていて、個人運用の範囲なら基本的にこの枠内で収まります。レート制限は厳しめですが、私のような日次処理のスケジュールであれば、引っかかることはほとんどありません。

注意点もあります:

- レート制限あり(連続で大量に叩くと制限がかかる)
- 商用利用には別途条件がある(個人の自動分析なら問題ないケースが多い)
- モデルの更新・廃止のタイミングは公式アナウンスを見る必要がある

詳細は公式ドキュメントを参照してください。

GitHub Actionsから呼び出す場合は、Actions実行時に自動で付与される標準のトークンで認証できるため、追加のシークレット登録は不要です。


3. 私が試した複数視点の銘柄判定


最初に作ったLLMツールは、本体システムが絞り込んだ注目銘柄を入力にして、「今買うべきか」を複数の著名トレーダーの視点で判定してもらうものでした。

入力するのは:

- 各銘柄の価格・出来高・移動平均線などのテクニカル指標
- 企業概要(業種・時価総額・業績の一部)
- マーケット全体の状況(主要指数・原油・金・債券などの動き)

これらをまとめてLLMに渡し、視点別に「buy / hold / skip」のシグナルと確信度、理由をJSON形式で返してもらう構成です。出力をSlackに整形して送る作りで、必要な時に手動で叩いて使うツールとして仕上げました。

実装は動きました。出力もそれなりに納得感のあるコメントが返ってきます。

ただし大きな課題が一つあります:同じ入力でも、実行ごとに判定がブレる。日をまたぐとブレるどころではなく、同じ日に連続で叩いただけで結果が変わります。temperatureを下げる、seedを固定する、といった設定変更でブレを減らすことはできますが、完全には抑えきれません。

これが、私が本体に組み込まないことを選んだ最大の理由です。

同日1回目の実施結果
同日2回目の実施結果
何回やっても回答が微妙に変化します

4. 正直に言うと:メイン処理には組み込んでいない


ここまでの話を整理すると、私はLLMの呼び出し基盤は持っているし、複数視点判定も含めていくつかのツールを作っています。

ただし、メイン処理には組み込んでいません。

理由はシンプルで、再現性が低いからです。本体のスコアリングや銘柄判定は、毎日同じ入力に対して同じ結果を返さないと、改善サイクルが回りません。プロンプトを変えたのか、モデルがブレたのか、判別がつかなくなる。

本体は機械的に淡々と動かして、LLMはその外側で補助的に使う。この線引きが、私のAI活用の現状です。

ただ、これはLLMが使えないということではありません。むしろ、用途を選べば十分に活きる場面はあります。次の章でその方向性を整理します。


5. LLMの強みを活かせる方向性(試験中の4+1テーマ)


LLMが本来得意なのは、自然言語の理解と生成です。テキストの要約、整理、分類、抽出。こういった用途なら、多少のブレがあっても運用に乗せやすい。

私が今、試験中の4つの方向性を紹介します。

A. 保有銘柄ニュースの日次サマリー

保有銘柄について、英文ニュースを集めて日本語で要約する。米国株運用者にとって「英語情報の山」は永遠の課題で、ここをLLMで圧縮できれば朝の情報収集が劇的に楽になります。

試作レベルでは動かせています。要約の質も実用的でした。ただ私の場合は元々ニュースを追う頻度が低く、運用には乗せていません。とはいえ、保有銘柄が増えてきたら本格的に組み込むかもしれない、という温度感です。

B. 決算発表の論点抽出

決算プレスリリースを入力にして、売上・利益率・ガイダンス・注目すべき変化点を構造化して取り出す。決算シーズンに毎日大量の発表が出る中で、ここを自動化できれば判断の高速化に直結します。

これも試作で動くところまで作りました。出力もそれなりに使える形でした。

私の場合、決算を満遍なくチェックするスタイルではなく、価格が大きく動いた銘柄(EP的な動き)について、その動きの理由を後追いで確認するために決算やニュースを見ることが多いです。なので、急変銘柄をトリガーに該当する決算情報を要約させる、という形ならメイン処理への組み込みもありかもしれません。

決算を詳しく追いたいけれど時間がない、という読者には、定常的なダイジェストとして主戦力になる用途だと思います。

C. テーマタグ付け・類似銘柄抽出

注目銘柄や保有銘柄に「AI」「半導体」「医薬品」「ディフェンシブ」などのテーマタグを自動付与する。さらに、類似テーマの銘柄を集めて分類する。ポートフォリオの偏りを可視化するのに役立ちます。

これも試作で動かしました。タグ付けの精度はそれなりです。私の場合、業種ローテーション分析で似た役割をカバーしているため運用には乗せていませんが、テーマ投資をする読者には刺さる用途だと思います。

D. 異常値や急変の言語化

システムが検知した異常値や急変について、「なぜ起きているか」の文章での説明を生成する。数値だけでは見えない背景の補完情報になります。

これは私もまだ試していません。実装の余地はあると思っていて、いずれ手を出したいテーマです。

また、LLM活用の応用例として、週1回の米国株観測記事も試しています。

毎日の自動分析システムが出した全体相場、業種スコア、観測銘柄の動きをもとに、生成AIで記事の下書きを作り、人間が最後に確認する流れです。

AIに売買判断を任せるのではなく、数値の集計はシステム、文章の整理はLLM、最終確認は人間。

この役割分担なら、週次の市場振り返り記事にもかなり使えそうだと感じています。

今後は、週1回の市場観測記事として試験的に公開していく予定です。


6. 取っかかりのプロンプト

最後に、自分のシステムからLLMを呼ぶ仕組みを作るための取っかかりプロンプトを一例だけ載せておきます。

このアプローチには2つの理由があります。1つは、自分のシステムに合わせて細かい部分を調整したいので、丸ごとコピペできるコードよりも生成元のプロンプトを持っておく方が便利なこと。もう1つは、本記事のテーマ通り「生成AIに丸投げしない」ためには、コードを直接コピーするより、自分で要件を整理してAIに生成させる方が学びが大きいことです。

GitHub Models APIを使って、米国株分析システムから生成AIを
呼び出すPythonスクリプトを書いてください。

【要件】
- HTTPリクエストはrequestsライブラリを使用
- 認証はGitHub Actions実行時に付与されるGITHUB_TOKEN環境変数を使用
- エンドポイントは https://models.github.ai/inference/chat/completions
- モデルはopenai/gpt-4.1(環境変数BRIEFING_MODELで切り替え可能に)
- temperature/seedを指定可能に(デフォルト 0.15 / 42)
- システムプロンプトとユーザープロンプトを分けて引数で渡す
- レスポンスはJSON形式で受け取る(response_format指定)
- レート制限(HTTP 429)対策として3回までリトライ
  Retry-Afterヘッダがあればその秒数だけ待つ
- 最小限のログ出力(標準出力でOK)
- エラーハンドリング(タイムアウト、ネットワーク障害、JSONパース失敗)

【入力データの想定】
- 銘柄ティッカー、価格、出来高、移動平均線、企業概要、市場全体の状況

【出力データの想定】
- 各銘柄ごとに ticker / signal (buy/hold/skip) / confidence / reason
  のJSON配列で返す

コード全体を1ファイルにまとめ、関数として呼び出せる形にしてください。

このプロンプトをChatGPTやClaudeに貼ると、それなりに動くPythonコードが返ってきます。要件の追加・削除は自由です。「Slack送信機能も加えて」「pandas DataFrameを直接渡せるようにして」など、自分の用途に合わせて調整してください。

ただし、一発で満足できる結果が出るとは限りません

私自身、いくつかのLLMツールを今の形にするまでに、プロンプトを何十回書き直しました。出力ログを見返すと、それくらいの試行錯誤を経ています。

具体的には:

- 出力が浅い(「リスク管理が大事です」レベルで止まる)
- 入力データを無視して一般論を返す
- JSON形式が崩れる
- 同じ入力でも実行ごとに結果がブレる

これらを直していく作業は、第3回【改善サイクル編】で書いた仮説→実行→検証→改善のループそのものです。第5回【AIガードレール編】で書いたシステムプロンプト・ガードレールも併用すると、AIに修正を依頼する時に余計な改造を防げます。

完璧を目指して止まるより、動くものを出して少しずつ育てる。これが現実的です。


7. AIと人間の役割分担

最後に、私が一番大事にしている考え方を書いておきます。

AIは強力ですが、判断の責任を引き受けてはくれません

「AIが買えと言った」「AIが大丈夫だと言った」は、損失が出た時の理由にはなりません。最終的にエントリーボタンを押したのは自分です。

私の整理はこうです:

- 数値の集計・スコアリング:本体システムで機械的に処理する
- テキストの要約・整理・分類:LLMの試験運用で材料を増やす
- 最終的な売買判断:自分でやる

AIの出力を判断材料の一つとして使う。最終決定権は自分が握り続ける。役割を分けて、それぞれの強みを活かす。これが私のAI活用の現在地です。

最後の判断は人間がやる

まとめ

スマホで運用している自分のシステムから、生成AIを直接呼び出せる時代になりました。GitHub Models APIを使えば、追加料金もほぼかからず、個人運用の範囲で活用できます。

ただし、すべてが一発でうまくいくわけではありません。再現性の問題でメイン処理に組み込めない用途もあれば、要約や整理のように十分に使える用途もある。

私自身、複数視点判定や日次ニュースサマリー、決算論点抽出、テーマタグ付けなど、複数のLLMツールを試行中です。どれもまだ試験段階ですが、使い方次第ではメイン処理への組み込みも視野に入れています。

次回は、このシステムの土台になる「保有銘柄情報の更新」に入っていきます。
どれだけ分析ロジックを作り込んでも、保有情報がズレていたら、後段の処理もズレます。
特にスマホ運用では、手入力ミスは普通に起きます。
だからこそ、「どう更新するか」そのものが重要になります。
この更新フローについて私が実際にやっていることを紹介します。

スキを押してもらえると、続きの公開が早まります。
気になる部分があればコメントで教えてください。


最後にひとつだけ。
この記事は、米国株の売買そのものをおすすめするものではなく、あくまで分析や仕組み作りの考え方をまとめたものです。
実際の投資判断は、ご自身の責任でお願いします。

いいなと思ったら応援しよう!

この記事は noteマネー にピックアップされました

noteマネーのバナー