地味地味フォリオ

スマホで運用する注目銘柄watchlistとMBO/TOB候補発掘システム

8分で読めます

はじめに

ポートフォリオダッシュボード、AI週次考察、出口ルール、配当方針の調査と、保有17銘柄の管理は一通り形になりました。

次の課題は、新しい候補銘柄をどう見つけるかです。株サイトやSNSで気になる銘柄は日々目にしますが、それを体系的に評価して watchlist に組み込む仕組みがありません。

そしてもう一つ、温めていた仮説がありました。

これまでの投資人生で、保有銘柄が複数回 TOB や MBO の対象になった経験があります。その時に「なぜこの銘柄が選ばれたのか」を振り返ると、共通点があるように感じていたのです。

この感覚的なパターンを、AIに壁打ちしながらロジック化し、システムとして銘柄選定に組み込めないか。今回はその設計記録です。

Phase 1: 注目銘柄watchlistの構想

最初は全上場銘柄を毎日スキャンする案を検討しました。しかし、3,800銘柄を yfinance でフル取得すると2-3時間かかり、現実的ではありません。

そこで方針を変えました。全銘柄スキャンより、人間が選んだ候補を AI が評価する方が実用的だと。

株サイトや SNS で日々目にする銘柄から、興味あるものを inbox に追加。AI が自動評価して watchlist 入れ替えを提案する。watchlist は厳選10銘柄に絞る。

既存の増配期待スコアやバリュエーション分析がそのまま使えるので、実装コストも低くなります。

「過度な自動化より、適切な手動+AI が正解」。これはトークン削減で品質が上がった時の教訓と同じです。

オペレーション設計:Claude Code をスマホから操作する

当初は GitHub iOS アプリで inbox.yaml を手動編集する案でしたが、より良い方法に行き着きました。

Claude の公式スマホアプリから、VPS 上の Claude Code リモートセッションへ接続する方式です。

移動中に「KDDI を inbox に追加して、ソースは Twitter」と話しかけるだけで、Claude Code が yaml を編集して commit と push まで完了します。YAML を手入力する必要はありません。

既存の tmux dev session、git 管理、systemd timer といった VPS 資産をそのまま活用できるのも利点です。

Phase 2: MBO/TOB候補スクリーニングへの拡張

watchlist の設計を進める中で、もっと大きな課題に気づきました。

そもそも、どんな銘柄を inbox に入れるべきか

ここで、最初に書いた「過去の TOB/MBO 経験」が結びついてきます。

日本市場では TOB 件数が増加しています。2024年は過去最多の127件、2025年は6月末時点ですでに81件と過去最速ペースです。経産省データでは、上場廃止理由の44%が他社買収、27%が支配株主による買収、21%が MBO となっています。

つまり、**TOB/MBO は今や個人投資家にとって無視できない「銘柄の出口」**なのです。

過去のTOB/MBO経験から見出したパターン仮説

これまで自分の保有銘柄が TOB/MBO の対象になったケースを振り返ると、いくつかの共通点が浮かび上がります。

共通点①:高配当・割安

いずれの銘柄も、TOB が発表される前は配当利回りが高く、PBR1倍割れまたはそれに近い水準でした。市場が十分に評価していない期間が長く続いていた銘柄です。

共通点②:小型だが経営は安定

時価総額は決して大きくありません。しかし、業績は安定しており、財務も健全。派手な成長は期待できないが、堅実にキャッシュフローを生み続けるタイプです。

共通点③:地味で成熟した業種

介護、葬儀、地方サービス、ニッチ製造業。世間的に華やかさはなく、メディアにも取り上げられにくい業種です。

この3つの共通点を眺めて、ある仮説に至りました。

仮説:これらの銘柄は、上場しているメリットより、非公開化するメリットの方が大きいのではないか。

上場している意味は、本来「資金調達」「知名度向上」「優秀な人材獲得」「M&A の対価としての株式活用」などがあります。しかし上記のような銘柄では、これらのメリットが実質的に機能していないケースが多いのです。

  • 公募増資をほとんどしていない
  • 知名度を活かした顧客拡大には限界がある
  • 採用面で上場メリットは小さい
  • M&A も現金で完結する規模感
  • 機関投資家のカバーも薄い

それにも関わらず、上場維持には四半期決算開示、IR 対応、ガバナンス強化、監査費用といったコストがかかります。

この状況なら、経営陣・親会社・PE ファンドにとって、非公開化して「短期業績を気にせず腰を据えて経営する」方が合理的に見えます。

今回作りたいのは、この「非公開化の合理性」をスクリーニング条件として言語化したシステムです。

設計の難所と判断

ChatGPT と Claude の両方に設計案を見せて壁打ちしながら、いくつかの難所が見えてきました。

難所①: EDINETのXBRL解析

大株主構成を取得するには有価証券報告書が必要です。EDINET の API で取得できますが、XBRL 形式の解析は技術的に複雑で、会社により記載形式も異なります。完璧を目指さず、60-70%の精度で割り切る方針にしました。

難所②: 創業家判定

「同姓だから創業家と決めつけない」というのが鉄則です。山田太郎が役員にいて、大株主にも山田太郎がいたら関係ありそうですが、確証はありません。「事実」と「推測」を分け、根拠がない場合は unknown とする設計にします。

難所③: データソースの選択

yfinance か J-Quants か。J-Quants は日本株専用で信頼性が高い一方、無料プランは12週遅延という致命的な制約があります。月1,089円の Light プランなら最新データが得られますが、コストが発生します。

MVP は yfinance + JPX 公式 CSV で無料運用することに決めました。データ品質80-85%でも、まずは動くものを作る方が優先です。

ChatGPTとClaudeの役割分担

今回の設計で改めて感じたのは、2つの AI を使い分けることの有効性です。

ChatGPT はフレームワーク設計が得意でした。スコアリング項目を網羅的にリストアップし、見落としを指摘してくれます。私が作った初期案に対して、6セクション分の改善提案が一気に返ってきます。

Claude は実装可能性の判断と既存システムとの統合視点が強みです。「これは2-4週間かかる規模ですよ」「段階的MVPから始めましょう」と現実的なスコープに引き戻してくれます。

どちらか一方だけでは、おそらくこの設計には到達できませんでした。

MVP仕様

壁打ちを経て、Phase 1 MVP の仕様が固まりました。

  • データソース: yfinance + JPX 公式 CSV
  • 対象: 全上場約3,800銘柄、フィルタ後約1,300銘柄
  • スコア: 45点満点(割安度20点+財務余力15点+上場メリットの薄さ10点)
  • 実行: 週次(土曜23:00自動)
  • 出力: CSV + Markdown + メール通知
  • コスト: 完全無料

含めないものも明確にしました。EDINET 連携、創業家判定、バックテスト、AI 判定メモ自動生成は Phase 2 以降です。

段階的な実装プラン

Phase 1: 定量スクリーニング(1週間)← MVP
Phase 2: EDINET 統合・3軸スコアリング(1-2週間)
Phase 3: バックテスト・サイト表示(1-2週間)

いきなり完全版を作らない。動くものを作って、運用しながら改善する。これは出口ルール策定の時と同じアプローチです。

仮説検証としての位置づけ

このシステムは「TOB を予言する魔法」ではありません。

過去の経験から見出した「TOB/MBO されやすい銘柄のパターン」が本当に正しいかを、データで検証する仕組みです。

スクリーニング結果として高スコアになった銘柄に、実際に TOB/MBO されたものが含まれるか。自分の経験と一致するか。一致しない場合、仮説のどこに誤りがあるか。

これが Phase 3 のバックテストで検証したい内容です。

通常、銘柄の出口は売却・損切り・利確が中心です。でも、TOB/MBO による強制現金化も重要な出口です。特にバリュー投資では、市場が評価しない期間に TOB が「市場に代わって」価値を実現してくれることがあります。

仮説が検証されれば、TOB/MBO されやすい銘柄を意図的に保有するという戦略が成り立ちます。watchlist 選定の強力な軸として活用できます。

まとめ

注目銘柄 watchlist の構想から始まり、MBO/TOB 候補スクリーニングシステムの設計に至りました。

出発点は個人的な体験でした。過去に保有銘柄が TOB/MBO された経験から、「高配当・割安・小型・地味な業種」という共通点を感じていた。これを ChatGPT と Claude に壁打ちしながらロジック化していきました。

結論として導いた仮説は、こうした銘柄は上場しているメリットより非公開化するメリットの方が大きいというものです。この「非公開化の合理性」をスコア化するのが今回作るシステムです。

大切なのは、これが仮説検証システムだという認識です。動くものを作って、運用しながら検証する。一致しなければ仮説を修正する。

MVP の実装が完了したら、運用結果を記事にしたいと思います。地味にコツコツ、AI と二人三脚で。

シェア: X Bluesky はてブ

関連記事