個人の株価アプリで市場データを扱うとき、「1つのAPIから全部取る」方が単純に見えます。しかし実際には、データソースごとの得意・不得意を分けて使う方が、後々のバグを減らせます。ある個人開発アプリの、J-Quants×yfinanceのハイブリッド設計とAPIキー管理の実例を見ていきます。

役割を分けた2つのデータソース

J-Quants Freeプランの銘柄マスターには更新の遅延があるため、このアプリでは「当日価格の確定した根拠」としては扱わず、銘柄の適格性確認（上場しているか、どんな種別か）だけに用途を絞っています。価格系列そのものはyfinanceの日足に統一しています。

複数ソースの価格を無造作に混ぜない

「データソースが複数あるなら、欠けている部分を別ソースで補えばいいのでは」と考えたくなりますが、この設計ではあえてそれをしていません。理由は、株式分割・配当調整の基準日やタイムゾーンの扱いがソースごとに微妙に異なり、無造作につなぐとデータの継ぎ目に別のバグを作り込んでしまうためです。価格の正はyfinance、銘柄の正はJ-Quantsと役割を固定することで、「どちらの値が正しいか」という判断が発生しない設計にしています。

APIキーは環境変数に直書きしない

APIキーの扱いにも明確なルールがあります。JQUANTS_API_KEY_FILEという環境変数が、キーを1行だけ書いたローカルファイルのパスを指し、実行時にそこから読み込む方式です。

$env:JQUANTS_API_KEY_FILE = "C:/path/to/JQUANTS_API_KEY.txt"

「.envに直書きしない」というだけでなく、Git・APIレスポンス・ログ・記事・スクリーンショットのいずれにもキーを含めない、という徹底したルールが記録されています。個人開発では「動けばいい」でキー管理が雑になりがちですが、この設計は最初から公開前提（記事化・共有）のワークフローを見据えて作られている点が特徴です。

エラーメッセージも意図的に情報を絞る

外部APIとの通信エラーは、詳細を伏せた汎用的なエラー型（JQuantsError・YFinanceError）として扱われています。これはログ上に秘密情報が漏れることを防ぐための設計判断で、代わりにデバッグのしやすさを一部犠牲にしている、とトレードオフとして明記されています。何でも詳細にログへ出すのではなく、「本番運用で何を漏らしてはいけないか」を先に決めておく発想です。

個人開発のデータ設計に応用できる点

• 複数のデータソースを使うなら、どちらが「正」かをソースごとに固定する
• 無料プランのデータ遅延など、既知の制約を隠さずコードとドキュメントに明記する
• 秘密情報はファイルパス経由で読み込み、直書きを避ける
• エラーメッセージの詳細さと、ログ漏洩リスクのトレードオフを意識する

派手な機能ではありませんが、こうした地味なデータ設計の積み重ねが、後から「動かない」「漏れた」で苦しまないための土台になります。