はじめに

社会人になってから株式投資を始め、気づけば4年が経ちました。
最初のうちは、好きな銘柄を直感で売買していたのですが、「買った直後に下がる」といった苦い経験を何度も繰り返すうちに、テクニカル分析に興味を持つようになりました。

地道に勉強を続けていく中で、徐々にチャートや各種指標を使った市場分析ができるようになり、最近ではようやく自分なりの投資スタイルが見えてきたかな？と感じています。

話は少し変わりますが、私の投資スタイルは、日本株の個別銘柄を現物で売買するのが基本です。そして、売買判断の際には「信用取引の情報」を必ず確認するようにしています。

以前は「現物取引なら信用取引の情報は関係ないのでは？」と思っていたのですが、学んでいく中で、現物取引であっても信用取引の動向を知ることが非常に重要だと気づきました。

とはいえ、信用取引の情報を調べようとしても、意外と欲しいデータに簡単にはたどり着けません。特に制度信用取引に絞った情報は見つけにくく、「もっと手軽に確認できればいいのに」と感じる場面が何度もありました。

そこで、「信用取引の最新情報を、いつでも手軽に確認できる仕組みを作ろう」 と思い立ち、今回のWebアプリを開発しました。
本記事では、ツールを作ろうと思った背景から、開発の流れや工夫したポイントなどをご紹介していきます。

信用取引情報がなぜ重要なのか

信用取引とは

まず信用取引とは、証券会社から資金や株式を借りて行う取引手法で、いわば「借金をして投資する」ものです。
Wikiからの引用ですが：

信用取引（しんようとりひき）とは、金融用語の一つで、株取引において、現金や金融商品を委託保証金（margin）として差し入れ、証券会社より借り入れて株の売買を行う投資制度。

簡単に言えば、100万円の元手を担保にして300万円分の取引を行うようなものです（厳密にはもっと複雑ですが）。
信用取引には「空売り」など特有の手法もありますが、本題から逸れるのでここでは割愛します。

重要なのは、信用取引はハイリスク・ハイリターンであり、市場の動向に敏感な投資家が多いという点です。
つまり、信用取引の情報を追うことで「市場の反応が早い層の動き」を知ることができます。

一般信用取引と制度信用取引

信用取引には「一般信用取引」と「制度信用取引」の2種類がありますが、私が特に注目しているのは制度信用取引です。

その大きな理由は、返済期限の短さです。
一般信用が3年に対し、制度信用はわずか6カ月。つまり、半年以内に成果を出さないといけないので、より短期の市場変動に反応しやすい投資家が多く集まっています。

しかしながら、多くの証券サイトやツールでは「一般信用」と「制度信用」のデータが合算されていることが多く、一般信用、制度信用単体の情報が得られにくい状況でした。
これが、制度信用取引に特化した情報収集ツールを作ろうと思ったきっかけです。

開発の概要

ざっくりとしたイメージは以下です。
定期的にPythonベースで作ったスクリプトをCloud Functionsで実行し、FireStoreにデータを蓄積=>蓄積したデータをVue.jsのWebサイトに表示するだけです。

機能概要

大枠の機能としては以下の仕組みで作っています。
※粒度感に統一性がないですが、バックエンドは処理単位、フロントエンドは画面単位で記載

バックエンド(Pythonプログラム)

FireStoreに格納されている信用取引情報が最新になっているかを確認
証券取引所のサイトから最新の信用取引のPDFをDL
DLしたファイルを読み込んでCSV形式で抽出
抽出したデータをFireStoreに格納
DLしたファイルはバックアップとしてFirebase のStorageに格納
不要ファイルは削除（バックアップから再抽出も可能）

※２，３については以前投稿した記事の内容を使いまわしてます

フロントエンド(Vue.jsプログラム)

一覧画面
- 銘柄ごとの制度信用取引情報をテーブル表示
- ソート・検索機能付き
- 銘柄クリックで詳細画面へ遷移
- 最終更新日を表示
詳細画面
- 選択した銘柄の過去データをテーブルと折れ線グラフで表示
- スケール変更、凡例表示などのUI対応
- かぶたんページへのリンク表示
インフォメーション画面
- サイトの使い方や意図を説明

開発・テストの流れ

基本的にはスモールスタートで初め、少しずつ粒度を細かくしていく流れで進めました。
開発環境についてもその時の都合に合わせて変化させましたが、大筋として以下の通りです。
なおFirebaseの開発をする過程で色々調べはしたものの、あまり記事が見つからなかったので詳細な内容は別で記事を書こうと思います。

◇開発で使用した環境・ツール

GitHub
VsCode
ChatGPT
Ubuntu（開発用端末）
iOS, Android（PC以外での動作確認で使用）

◇開発・テストの流れ

GitHub Actionsを使ってCI/CDの設定をし、効率的に開発ができるような工夫もしました。

GitHubでIssueを作成してブランチを切る
VsCodeとGithub Copilot、ChatGPTなどを駆使して開発・デバッグ
テストコードを作成し、プルリク作成時にテストコードが実行されるように設定
GitHub上でプルリクをマージするとFireBaseにデプロイされるように設定

運用について

Firebase Cloud Functionsは週4（火〜金）でスケジュール実行。
平日は市場が開くため、データの更新が遅れることも考慮してこの頻度にしています。

また、処理は約60秒以内で完了し、月額コストは2円程度に収まっています。
データ不備時の補正ツールも自作しており、運用時の手間はほぼありません。

実際に作ったもの

一覧画面

精度信用取引の最新情報を一覧で表示するだけの機能ですが、制度信用倍率でソートしたりできるので今買い時はどこなのかサクッとみることができるようになっています。

詳細画面

詳細画面では各銘柄ごとの信用取引情報を見ることができます。
データについては2024/4/1から取得しているため、それ以降の信用取引のデータを見ることができます。

グラフは信用倍率のグラフだけではなく、以下３つのグラフも見ることができるようにしてます。
比較すると顕著ですが、2025/4/4時点では制度信用取引よりも一般信用取引の方が大きく変化しており、返済期間が長い一般信用の方ではトランプ関税により株価暴落は一時的なものとみなし、長期的に上がることを期待して買いに向かっている人が顕著に多いことが分かります。一方で、返済期間が短い制度信用取引については買いは入っているものの、やはり様子見する割合が一般信用取引に比べて多いのかな？という印象です。

◇信用取引情報

◇一般信用取引情報

◇制度信用取引情報

自作したツールを使い始めて気づいたこと

説明もなしに「信用倍率」という言葉を使ってしまいましたが、ここで簡単に補足しておきます。
信用倍率はざっくり以下の式で表され、以下のように読み取ることができます：

信用倍率 =\frac{信用買残}{信用売残}

信用倍率< 1  : 信用売りの方が多い＝＞株価が上がりやすく、下がりにくい

信用倍率> 1  : 信用買いの方が多い＝＞株価が下がりやすく、上がりにくい

ツールを使う前の理解

信用売りが多いということは、これから株価が下がる！と考える人が多いということですが、実際には下がると見ているけれど、将来的に買い戻さなければならない人が多い という意味でもあります。加えてもうひとつ大事なのが、信用取引をする人たちは市場の変化に敏感に反応する傾向がある、という点です。

つまり、信用売りが増えるというのは「短期的に株価が下がる」と考える投資家が増えているサインでもありますが、逆に言えば、そのポジションが解消されるとき（＝買い戻すとき）には、株価が上がる要因にもなり得ます。

同じように、信用買いが増えている場合には、将来的に「売るタイミング（＝利確や損切り）」が意識されることになり、株価が下がる動きにつながることもあります。

──と、ここまでが、ツールを使う前に持っていた理解でした。ただ、実際にこのツールを使いながら情報を見ていく中で、理解がより深まったと感じています。

ツールを使ってみて分かったこと

信用倍率はその時点の数値を見るだけではなく、「どのように推移してきたか」を見ながら判断することが大事だと気づきました。

たとえば、今が相対的に高いのか低いのかを見るには、ある程度の期間でグラフの形や傾向を見る必要があります。そしてそれが分かると、「今が買い時か売り時か」をより客観的に判断する助けになります。

私自身の売買判断の流れとしては、以下のようなステップになっています：

会社の業績情報やPER・PBRといった指標を参考に、銘柄を選定
選んだ銘柄のチャートや出来高などをもとに、テクニカル分析
信用倍率の推移を見ながら、今が買い時か売り時かを見極める

作るうえで苦労したこと

日本証券取引所からデータを取得し、Firestoreに入れるまでの全工程

最も苦労したのは、Cloud Functions の実装まわりでした。
日本証券取引所で公開されている信用取引情報はPDF形式で提供されており、このPDFからデータを抽出し、数値を加工（信用倍率の計算など）する必要があったため、Pythonで処理を組み上げました。

PDFは一定期間が経過するとダウンロードできなくなるため、バックアップの対応も求められます。また、さまざまな制約もあることから、作業は煩雑で、ネット上に参考となる情報もほとんどなかったため、実装にはかなりの試行錯誤を要しました。

特に苦労した点は以下のとおりです：

日本証券取引所で公開されるタイミングや情報（社名変更など）が変わる
Cloud Functions + Pythonについて公開されている情報が少なく、調査や検証のコストが高い
どのように設計すれば最も効率がよいかを模索する中で、実装に無駄が生じやすかった（面白いかったけども...）

具体例ですが、PDFのバックアップについては、当初はGoogleドライブに保存する形で対応を検討していましたが、Cloud Functionsと連携させる最適な方法がすぐには見つからず、最終的にGoogleドライブを捨ててFirebaseのStorageに切り替えました。

最終的には構成をできるだけシンプルに保ちながらも、必要な処理をきちんとこなせるよう調整し、設計の工夫を重ねながら実装を完了させました。

デグレの発生

Vue.jsでWeb画面を作成する過程において、複数回デグレが発生しました。当初はテストコードを作成することでデグレを防ごうと考えていましたが、なかなか着手することができず、ある程度できてから後追いでテストコードを作ることとなりました。このような状態になった要因は以下の通りです。

設計が固まっておらず、何をテストすればよいか判断できなかった
実装後に大幅な仕様変更が生じることが多く、既存のテストコードが無効となることが頻発した
テストコードの記述経験が乏しく、方法の調査や実装に手間取った

特に3の影響が大きく、Vue.jsでの実装経験が浅かったことに加え、UI実装時に都度調査が必要となり、さらにテストコード記述時にも別途調査が必要な状況でした。その結果、シンプルな実装であっても調査コストが高くなり、デグレ防止の取り組みに影響を与えていました。

新しい技術への挑戦であったため、ある程度の手戻りは想定内ではありましたが、デグレ発生時の心理的負荷は無視できないものがありました。

最後に

今回のWebアプリは、信用取引情報の可視化ツールとして、自分自身が投資判断をする時に使いたかったので開発しました。

ただ日本取引所のデータは著作物だったんじゃないかな？と思ってまして...
まあ、あんまりよく分からないんで一旦はURLを非公開にしておこうかなと思ってます。

一方で、開発の過程や考え方については、今後もQiitaなどで少しずつ共有していく予定なので、追ってやり方とか作るときの工夫などを記事にまとめて公開していこうと思います。
特にCloud FunctionsをPythonで実装するときは情報が少なくて苦労したので...