株価の自動売買を実現するには、「データの取得」「分析」「可視化」「注文実行」を一貫して扱う基盤が必要です。本記事では、それらを複数サービスに分離した構成で自作しているプロジェクトの構想と、現時点での実装状況をまとめます。個人の学習・検証用途を想定しており、本番の自動売買に至るまでの道のりを記録する目的です。

構想

全体像

自動売買の基盤を次のように整理しています。

データベースは TimescaleDB（PostgreSQL 系） を中核に置き、各サービスが DB または HTTP API 経由で連携する形を想定しています。将来的に「シグナル生成 → 注文」を自動化する戦略エンジンを載せる土台として、まずは取得・分析・表示・注文の各機能を独立したサービスとして実装し、組み替えや拡張がしやすいようにしています。

技術選定

• 言語: Rust（パフォーマンスと型安全性を重視）
• Web フレームワーク: Axum
• DB アクセス: SQLx
• 時系列データ: TimescaleDB のハイパーテーブルで株価を保存

現在の構成（サービス一覧）

各サービスは別ポートで起動し、必要に応じて他サービスの API や共有 DB を参照します。

chat から MCP 経由でアクセス

この基盤には、chat（例: Cursor のチャットなど）から MCP（Model Context Protocol） 経由でアクセスすることもできる。MCP サーバーが stock_get や stock_view の API を呼び出すツールを提供しており、チャット画面から監視銘柄一覧の取得・銘柄検索・板情報の参照などを自然言語で依頼できる。将来的には注文の実行も MCP 経由で行えるようにする想定だ。

作成状況

1. stock_get（株価取得システム）

状況: コア機能は実装済み。

• 監視銘柄管理: Web UI で銘柄の追加・削除・更新。複数時間足（日足・週足・月足）に対応。
• 株価データ取得: Stooq API をメインに使用（無料・認証不要）。J-Quants API・Yahoo Finance API はフォールバック・補完用として仕様はあるが未実装。
• データカバレッジ管理: 銘柄・時間足ごとの連続取得期間を管理。Web UI で横棒グラフ表示。
• スケジューラー: 指定時刻（既定 19:00）に全監視銘柄の株価を一括取得。平日のみ実行オプションあり。
• その他: 先物（Twelve Data）、ADR（Yahoo）、日経平均株価（Yahoo）の定期取得スケジューラーあり。

2. stock_tran（注文・保有同期）

状況: 立花証券 API 連携の基本は実装済み。注文はデモ環境でのみ有効。

• 認証・セッション: ログイン・セッション維持。テストモードフラグでデモ/本番を切替。
• 保有銘柄同期: API から取得した保有一覧を DB に反映。Web UI で表示。
• 注文送信: 成行・指値、買い・売りを API で送信可能。本番環境では意図的に注文送信を無効化しており、テストモード時のみ動作。
• 注文履歴: 送信した注文を DB に記録し、一覧取得 API を提供。

本番で自動売買を行う場合は、別途「戦略エンジン」から注文 API を叩く形を想定しており、その前にリスク管理・約定確認フローなどの検討が必要です。

3. stock_view（表示・外部 API）

状況: 表示機能と外部 API は実装済み。株価チャート（複数銘柄・時間足・期間選択）、監視銘柄一覧、データ取得状況のヒートマップ、API キー認証・レート制限付きの外部 API（MCP や他ツールから利用可能）。

4. stock_analyze（分析）

状況: 3 機能とも実装済み。風読みシナリオ（日経先物から市場の強弱）、業界ランキング（ADR から業界リーダーの寄付き状況）、異常出来高アラート。いずれも REST API で結果を返し、自動売買の「シグナル」の入力として利用する想定です。

今後の予定（イメージ）

• 戦略エンジン: 分析結果や株価データを入力にシグナルを生成し、stock_tran の注文 API を呼び出すコンポーネント。ルールベースやバックテストを検討中。
• 本番注文の有効化: リスク管理・約定確認・障害時のフォールバックを設計したうえで判断する予定。
• J-Quants / Yahoo の実装: stock_get のフォールバック・補完データ源として実装し、取得の安定性を高める。

まとめ

まだ「自動で売買が回る」ところまでは至っておらず、基盤ができつつある段階です。進捗に応じてまた記事を更新する予定です。

作成日: 2026年3月

デスクトップPCで大容量 HDD を使いつつ、SSD 並みの速度を得たい ── そんな要望に応えるのが Linux カーネル標準の dm-cache（lvmcache） だ。本記事では、2TB HDD のルートパーティションを NVMe SSD でキャッシュし、高速化している実際の構成を紹介する。

環境

ストレージ構成

NVMe SSD (WD Blue SN550 / 465.8GB)
├─ nvme0n1p1  200MB  EFI       → /boot/efi
├─ nvme0n1p3  243GB  BitLocker → Windows
└─ nvme0n1p6  221GB  LVM       → キャッシュプール (180GB data + 2GB meta)

HDD (Seagate ST2000DM001 / 2TB)
├─ sda1       928GB  BitLocker → Windows
├─ sda2       488GB  LVM       → ルートLV のオリジン (320GB)
└─ sda3       447GB  ext4      → /mnt/backup

LVM 構成:
  VG: vg_main
  ├─ root_lv        320GB  ext4  → / （キャッシュ済み）
  ├─ root_lv_corig  320GB        → オリジンデータ（HDD sda2 上）
  └─ cache_lv_cpool              → キャッシュプール（SSD nvme0n1p6 上）
      ├─ cpool_cdata  180GB      → キャッシュデータ
      └─ cpool_cmeta    2GB      → キャッシュメタデータ

ポイント

• Windows とのデュアルブート環境で、Linux パーティションのみ LVM キャッシュを適用
• HDD の 488GB パーティション上に 320GB のルート LV を配置し、SSD の 180GB でキャッシュ
• SSD の容量は HDD の約 56% をカバーしており、高いヒット率が期待できる

LVMキャッシュ（dm-cache）の仕組み

アプリケーション
      ↓
  root_lv（320GB / ext4 / マウント: /）
      ↓
  dm-cache（カーネル層）
  ├─ キャッシュ HIT  → SSD（NVMe）から高速読み出し
  └─ キャッシュ MISS → HDD から読み出し → SSD にキャッシュ保存

dm-cache は Linux カーネルの Device Mapper サブシステムに含まれるブロックレベルのキャッシュ機構。LVM2 が lvmcache コマンドとしてフロントエンドを提供しており、LVM の論理ボリュームに対して透過的にキャッシュを追加できる。

キャッシュモード

本構成では writethrough（デフォルト）を採用。読み込みが SSD 速度になり、書き込みの安全性も確保される。

キャッシュポリシー: smq

Linux 4.2 以降のデフォルトポリシー smq（Stochastic Multiqueue） を使用。アクセス頻度に基づいてキャッシュ対象を自動選択し、メモリ消費も少ない優れたアルゴリズム。

セットアップ手順

1. 前提条件

• LVM2 がインストール済みであること
• キャッシュに使う SSD パーティションが同じ VG に属していること

sudo apt install lvm2

2. 物理ボリューム（PV）の作成

# HDD パーティション
sudo pvcreate /dev/sda2

# SSD パーティション
sudo pvcreate /dev/nvme0n1p6

3. ボリュームグループ（VG）の作成

sudo vgcreate vg_main /dev/sda2 /dev/nvme0n1p6

4. ルート論理ボリューム（LV）の作成

# HDD 上にオリジン LV を作成
sudo lvcreate -L 320G -n root_lv vg_main /dev/sda2

# ファイルシステム作成
sudo mkfs.ext4 /dev/vg_main/root_lv

5. キャッシュプールの作成とアタッチ

# SSD 上にキャッシュプール LV を作成
sudo lvcreate --type cache-pool -L 180G -n cache_lv_cpool vg_main /dev/nvme0n1p6

# キャッシュプールをルート LV にアタッチ
sudo lvconvert --type cache --cachepool vg_main/cache_lv_cpool vg_main/root_lv

これだけで root_lv へのアクセスが自動的に SSD キャッシュ経由になる。既存のマウントポイントやファイルシステムの変更は不要。

6. 確認

# キャッシュの状態確認
sudo lvs -a -o +cache_mode,cache_policy vg_main

# Device Mapper の状態確認
sudo dmsetup status vg_main-root_lv

現在の使用状況

$ df -h /
Filesystem                    Size  Used Avail Use%  Mounted on
/dev/mapper/vg_main-root_lv  315G  107G  194G  36%  /

使用量 107GB に対してキャッシュが 180GB あるため、頻繁にアクセスされるデータのほぼすべてが SSD 上にキャッシュされ、高速にアクセスできる状態にある。

Bcache との比較

同じ「SSD で HDD をキャッシュする」仕組みとして Bcache がある（Raspberry Pi 5 での Bcache 構成記事を参照）。両者の違いを整理する。

LVM を既に使っている環境であれば lvmcache が管理しやすく、Bcache は LVM を使わない構成や Raspberry Pi のような環境で手軽に導入できる利点がある。

まとめ

LVM キャッシュは既存の LVM 環境に対して lvconvert 一発でキャッシュを追加でき、ファイルシステムの変更も不要という手軽さが最大の利点だ。2TB の HDD を 500GB の NVMe SSD でキャッシュすることで、日常的なデスクトップ用途ではほぼ SSD の速度で動作する環境を実現できている。

作成日: 2026年3月

Raspberry Pi 5 は USB や SATA 接続のストレージを活用できるが、大容量 HDD は読み書き速度が遅いという課題がある。
本記事では、安価な SSD をキャッシュとして使う Linux のカーネル機能 Bcache を活用し、HDD の速度を SSD 並みに引き上げる構成を紹介する。

環境

ストレージ構成

SSD (MSI S270 240GB / SATA)  ← キャッシュデバイス
 └─ sda2 (200GB) → bcache キャッシュ

HDD1 (1.8TB / sdb)
 ├─ sdb1 (1.5TB) ─┐
 └─ sdb2 (327GB)  ─┤
                   │ RAID1 (ミラーリング)
HDD2 (3.6TB / sdc) │
 ├─ sdc1 (1.5TB) ─┤→ md2  (1.5TB RAID1) → bcache0 → /data (1.5TB)
 └─ sdc3 (336GB)  ─┘→ md127 (327GB RAID1) → bcache1 → /     (327GB)

ポイント

• 2 台の HDD を RAID1（ミラーリング） で冗長化 → 片方の HDD が壊れてもデータを保護
• SSD をキャッシュ として RAID1 ボリュームに重ねることでアクセス速度を向上
• ルートパーティション (/) とデータパーティション (/data) をそれぞれ独立した bcache デバイスとして構成

RAID1（ミラーリング）の構成

RAID1 とは

RAID1 は 2 台以上のディスクに同じデータを書き込むミラーリング方式。
片方のディスクが故障しても、もう片方から読み出し続けられるためデータを失わない。

書き込み → [HDD1] ─┐
                   ├─ 同一データ
           [HDD2] ─┘

HDD1 故障時 → HDD2 から自動的に読み続ける（無停止）

本構成での RAID1

RAID1 セットアップ手順（mdadm）

1. mdadm インストール

sudo apt install mdadm

2. RAID1 アレイ作成

# /data 用 (1.5TB × 2)
sudo mdadm --create /dev/md2 --level=1 --raid-devices=2 /dev/sdb1 /dev/sdc1

# / 用 (327GB × 2)
sudo mdadm --create /dev/md127 --level=1 --raid-devices=2 /dev/sdb2 /dev/sdc3

3. 設定を永続化

sudo mdadm --detail --scan | sudo tee -a /etc/mdadm/mdadm.conf
sudo update-initramfs -u

RAID1 の状態確認

cat /proc/mdstat

正常時の出力例：

md2 : active raid1 sdc1[1] sdb1[2]
      1610480640 blocks super 1.2 [2/2] [UU]

md127 : active raid1 sdc3[0] sdb2[1]
      342768704 blocks super 1.2 [2/2] [UU]

[UU] = 両ディスク正常稼働。[_U] や [U_] になった場合は片方が故障。

故障時の対応

# 故障ディスクを取り外す
sudo mdadm /dev/md2 --fail /dev/sdb1 --remove /dev/sdb1

# 新しいディスクを追加してリビルド
sudo mdadm /dev/md2 --add /dev/sdb1

# リビルド進捗確認
watch cat /proc/mdstat

Bcache の設定内容

bcache0（/data 用・1.5TB）

bcache1（/ 用・327GB）

キャッシュヒット率（実績）

ルートパーティションで 96% のキャッシュヒット率を達成しており、HDD 単体と比較して体感速度が大幅に向上している。

Bcache の仕組み

アプリ
  ↓
bcache（カーネル層）
  ├─ キャッシュHIT → SSD から高速読み出し（μs オーダー）
  └─ キャッシュMISS → HDD から読み出し＆SSD にキャッシュ保存（ms オーダー）

writeback モードとは

書き込みリクエストをまず SSD に書き込み、後から HDD へ非同期に反映するモード。

• メリット: 書き込み速度が SSD 速度になる
• デメリット: SSD が突然故障した場合、キャッシュ上の未書き込みデータが失われる可能性がある（本構成では RAID1 で HDD 側を保護）

Bcache セットアップ手順（概要）

1. パッケージインストール

sudo apt install bcache-tools

2. キャッシュデバイスの作成（SSD 側）

sudo make-bcache -C /dev/sda2

3. バッキングデバイスの作成（HDD/RAID 側）

sudo make-bcache -B /dev/md2
sudo make-bcache -B /dev/md127

4. キャッシュデバイスを登録・アタッチ

# キャッシュセット UUID を確認
ls /sys/fs/bcache/

# バッキングデバイスにキャッシュをアタッチ
echo <UUID> | sudo tee /sys/block/bcache0/bcache/attach
echo <UUID> | sudo tee /sys/block/bcache1/bcache/attach

5. キャッシュモードを writeback に変更

echo writeback | sudo tee /sys/block/bcache0/bcache/cache_mode
echo writeback | sudo tee /sys/block/bcache1/bcache/cache_mode

6. 設定を永続化（/etc/rc.local や udev ルールで起動時に適用）

# /etc/rc.local の例
echo writeback > /sys/block/bcache0/bcache/cache_mode
echo writeback > /sys/block/bcache1/bcache/cache_mode
echo 0 > /sys/block/bcache0/bcache/sequential_cutoff

現在の使用状況

/dev/bcache1 (/)    321GB 中 117GB 使用（39%）
/dev/bcache0 (/data) 1.5TB 中 601GB 使用（42%）

まとめ

Raspberry Pi 5 のような非力なシングルボードコンピューターでも、Bcache を組み合わせることで 実用的なファイルサーバー・ホームサーバー として活用できる。
96% というキャッシュヒット率は、日常的なワークロードではほぼ SSD の速度で動作していることを意味する。

作成日: 2026年3月

OpenAIの基本的な使い方を備忘録として記載。

Toolsを使った呼び出し例

脳の神経細胞の動きをシミュレーションをし、３層のニューラルネットワークを作成。教師信号を用意し単純なモデルの学習を始める。

Mark1 OpenAI APIを使う（2024年～）

PythonからOpenAI APIを使って、会話形式でやり取りを実現

どのAIも最新情報での学習は行われていなく最新の情報について答えられない状況だったが、OpenAIから外部ツールを呼べるようなり、そこで様々な最新情報を入手できるようになった。早速その外部ツールを呼び出す機能を使って、現在の時間、現在の天気予想、地名から経度・緯度を変換するツールを登録。

Mark2 Discord経由でOpenAI APIを使う

Pythonを起動しコマンドプロンプトで会話をしていが、外出先でも利用ができるように仕様変更を検討。

LineとPython の連携を考えたが、LineAPIは一定の件数を超えたら有料。そのため無料のDiscordのボットに、本AIエージェントを登録（自分専用）。これでリモートからのやりとりが可能になる。

Mark2.1 OpenAI APIから外部ツール（外部API）を使う

外部ツールで取得できる情報が限定的なため外部検索エンジンと連携ができるように検討。
GoogleAPIを使って、Google検索を本AIエージェントから直接利用できるようにし、取り扱える情報の強化に成功

Mark2.2 OpenAI APIで永続的な会話を成り立たせる

OpenAIのAPIは、セッション内であれば、一定期間の会話は覚えているが、一定期間を超えたりセッションを新規に作成（または、プログラムの再起動）をすると、毎回初めましてといった状態になる。
OpenAI APIで取得したデータは学習には使わないということ（2025年7月現在）なので、これを避けるために、過去の会話を会話のたびに追加するように実装。過去に会話した内容もすべての記録されているため、割と矛盾なく会話が成立するようになる。過去の会話から普段住んでいるところ、会社まで交通ルートなどもわかるため、会社に最短でいつつくといった情報にも、個人的なルートを加味して回答するようになる。ただし、会話が続くと消費するトークンが雪だるま式に増えるため課題が残る。

Mark2.3 OpenAI APIで節約しながら永続的な会話を成り立たせる

消費するトークン量を節約するために過去の会話を要約する機能を実装。

Mark2.4 OpenAIを同時実行するマルチスレッド対応

OpenAIの１つしか呼べないような実装をしたたため、マルチスレッド対応に変更
これで、会話中に次の質問・依頼をしても対応するように改善

Makk2.5 OpenAI APIで永続的な会話を実現するための情報をカテゴリに分けて管理する

会話を要約する際に、カテゴリごとに分けて管理するように修正。

会話の中から、どのように要約するかを確認しプロンプトを微修正

Mark2.6 OpenAI APIを使ってやり取した会話を自ら保存し、必要に応じて引き出すようにし、効率化（≒無駄が少ない、＝節約した）を図る

要約したものの要約データが大きくなり、会話ごとに毎回読み込むとまたトークン消費につながるため、要約した情報をカテゴリごとにファイル保存し、必要に応じてOpenAIが該当するカテゴリファイルを読み込む方式に変更。それに合わせて、会話した内容から新たなものや変更になったものを、既存のカテゴリの毎の要約ファイルと比較し、整合のとれたカテゴリごとの要約ファイルを作成するように修正。

これで、例えば今日の予定は？と聞くと、要約ファイル（タスク）をOpenAIが自動的に読み込み、その情報をもとに会話ができるようになった。

Mark2.7 OpenAI　APIを使い、タイマー機能を実装

会話の中からあとで教えらしてほしい情報を抽出し、タイマー情報として記録する

本プログラムが起動した際に、別スレッドを起こし、タイマー用の機能を別スレッドで実行し、
上記で登録したタイマー情報を読み込み、該当する時間になった際に、Discordにメッセージを送信する機能を実装する。

Mark2.8 株価情報を取り扱えるように、お気に入り銘柄の管理と株価情報の取得、取得したデータの可視化（グラフ化）の機能を実装

AIとの会話を通し、お気に入り銘柄を登録・リスト化。
AIとは別のタスクとして、お気に入り銘柄の株価情報をバックグラウンドで取得、保存する機能を実装。
AIに対しては、株価情報を管理するツールを適用し、必要な株価情報をAIに提供できるようにした。
株価情報は保存されていればそれを利用し、なければネットから取得を行ってくる。
しかし、リアルタイムのデータは、売り物だということを知らなかった。現在は２営業前くらいの情報を無料枠の中で処理している。

Mark2.9 外部関数のマルチタスク化を実装、その他

OpenAIが扱える関数のマルチスレッド対応を実施。
その他、株価情報の取得機能とグラフ化の機能を統合。グラフを作る際にデータがなければデータを取得するように統合化。グラフタイトルに日本語が扱えるよう環境修正。
タスクリストデータのJSON化を行い、各タスクの期限、ステータスを管理できるように修正。
前回株価を確認した時間を管理するように変更。

Mark2.10 AIが扱いやすいようデータ保存形式を見直し

保存している記録情報をJSON形式に変更。JSON形式にしたことにより部分的なデータの抽出、置き換え、削除をAIから直接、精度を高く実現できるようにした。

Mark2.11 ResponseAPIに実装を変更

AssistantAPIを使っていたが、将来廃止されるとのことだったので、ResponseAPIに実装を変更。
正直使いにくくなった。元の実装はAIが考えているToolが要求されたら、その都度Toolを実行しAI に返却する実装をしていたが、それが出来なくなった。（正確にはわからないだけかも）。その対応が割と実装が大変だった。

追伸：かなりはまって２週間ほどデバッグにかかった（泣）。

Mark2.12 OpenAIのBatch対応

AIエージェントとの会話ログが大量になってきたので、整理するためにバックグラウンドで圧縮するためにBatch対応を実装。そのほか、全面的にソースのリファクタリングとエラー処理を強化し随分安定した。

Mark2.13 GoogleCalendar連携対応

AIエージェントからGoogleCalendarの操作を出来るようにした。会話の中から予定を確認したり、予定を書き込んだりできるように機能強化。

ちなみに後で2台目のHDDを準備する場合は、以下のコマンドのようにmissingを指定すれば、
1本のHDDでRaid1(ミラー）の縮退構成としてセットアップすることができる。
mdadm --create /dev/md0 --level=1 --raid-devices=2 missing /dev/sda1

/proc/mdstatを見ると、Raidの状態を確認することができる。

ちなみに、HDDが準備できたら、以下のコマンドで組み込めばOK

mdadm /dev/md0 -a /dev/sdXX

PCとMicroSDカードが書き込める環境がること

OSの入手方法

RaspberryのサイトからインストーラーをRaspberryPIで認識させるためのSDカードを作るためのソフトウェアを入手する

OSは、以下から選択。デスクトップ（GUI）を使わなければLiteで十分。

あとは、書き込んだSDカードをRaspberryPIに差し込んで起動する

SSHの有効化

必須ではないが、RaspberryPIのコンソールからインストール作業をするのはちょっと不便なので、SSHを有効化する。
sudo raspi-config

でコンフィグ画面を起動し３を選択

次にI1を選択

I1を選択しSSHを有効化。

RaspberryPI独自のコマンドとして、サーバにSSHホスト鍵が存在しない場合に生成することができる以下のコマンドを必要に応じて実行

ssh-key-gen -A

補足説明

インターネット回線は一般家庭のフレッツ光などの回線を使っており課金して固定IPとしていないため、IPアドレスが変更されても問題とならないDDNSでドメイン登録する方法を選んだ。
私はサブドメインでもいいので無料で使えるDDNS Now(https://ddns.kuku.lu/)を利用（無料）した。
※サブドメインなのでf5.siの下にgontaを申請。IPアドレスがころころ変わるので、
　DDNS Nowに向けて定期的にIPアドレスを通知

更に、SSL用証明書は、無料のLet’s Encryptを利用を利用した。
余談だけど、今は無料でブラウザから信用されている認証局から発行される証明書を取得できるなんて便利な世の中だと思う。
このサービスで発行される証明書の有効期間は数日とかなり短いため、定期的に更新するスクリプトを実装する必要がある。

余談

Raspberry Piのボードに内蔵されているWifiユニットが不安。
※後で調べてみたところ、省電力モードをOFFにすると改善されるという事例あり。
私は無線は使っていないので未検証。
特にCPU使用率が高い際は、ノイズがでているようで頻繁にWifiが切れてしまう。そのために有線接続を実施

補足説明

インターネット回線は一般家庭のフレッツ光などの回線を使っており課金して固定IPとしていないため、IPアドレスが変更されても問題とならないDDNSでドメイン登録する方法を選んだ。
私はサブドメインでもいいので無料で使えるDDNS Now(https://ddns.kuku.lu/)を利用（無料）した。
※サブドメインなのでf5.siの下にgontaを申請。IPアドレスがころころ変わるので、
　DDNS Nowに向けて定期的にIPアドレスを通知

更に、SSL用証明書は、無料のLet’s Encryptを利用を利用した。
余談だけど、今は無料でブラウザから信用されている認証局から発行される証明書を取得できるなんて便利な世の中だと思う。
このサービスで発行される証明書の有効期間は数日とかなり短いため、定期的に更新するスクリプトを実装する必要がある。

余談

Raspberry Piのボードに内蔵されているWifiユニットが不安。
※後で調べてみたところ、省電力モードをOFFにすると改善されるという事例あり。
私は無線は使っていないので未検証。
特にCPU使用率が高い際は、ノイズがでているようで頻繁にWifiが切れてしまう。そのために有線接続を実施