ふくふくHukuhuku Inc.
SERIES

Python データ取得レシピ

「そのデータ、Python でどう取るのか」だけを扱う連載シリーズ。ライブラリの選び方、認証、レート制限、欠損や単位のクセまで、動くコードと一緒に。読者リアクションに応じて拡充していきます。

対象読者: データエンジニア / データアナリスト / 分析をする人
シェア
この連載をRSSで購読
40 記事
01EP.1 9分

その API を叩く前に決めておく5つのこと

動くコードはすぐ書けます。つらくなるのは、動いたあとです。タイムアウト・再試行・名乗り・並列度・保存先。この5つを最初に決めておくと、後から書き直す量が激減します。

2026-09-02読む
02EP.2 10分

ページングの4つの型と、取りこぼしが起きる条件

1000件あるはずが980件しか取れない。原因はたいてい offset 方式です。offset / カーソル / Link ヘッダ / 継続トークンの違いと、どれがどう取りこぼすかを整理します。

2026-09-02読む
03EP.3 10分

429 と向き合う ── Retry-After と、ゆらぎを足す理由

「1秒待って再試行」を全員が同時にやると、1秒後にまた混雑します。待ち時間を倍にしていくだけでは足りず、ゆらぎを足す必要がある。その理由を実験で確かめます。

2026-09-02読む
04EP.4 9分

認証の型を見分ける ── APIキー・Bearer・OAuth2・署名

ドキュメントに「認証が必要です」とだけ書いてあるとき、何をどこに載せればいいのか。4つの型それぞれの見分け方と、鍵をコードに書かずに済ませる方法をまとめます。

2026-09-02読む
05EP.5 9分

生データを捨てない ── 取得層と加工層を分ける

取ってきたその場で整形すると、あとで「あの列が要る」となったときに取り直しになります。相手が過去分を配信していなければ、取り直せません。層を分けるだけで防げます。

2026-09-02読む
06EP.6 10分

差分だけ取る ── 毎回の全件取得をやめる

件数が増えると全件取得は必ず限界を迎えます。更新日時で絞る方法には落とし穴があり、素直に実装すると取りこぼします。境界の決め方を扱います。

2026-09-02読む
07EP.7 9分

途中で落ちても、続きから再開できる取得にする

8時間かかる取得が7時間目で落ちる。最初からやり直すと、また7時間かかったうえで同じ場所で落ちるかもしれません。再開できる形にしておく方法です。

2026-09-02読む
08EP.8 10分

取得コードをテストする ── 本物のAPIを叩かずに壊れを見つける

テストのたびに本物のAPIを叩くと、遅く、不安定で、相手にも迷惑です。かといってすべて作り物にすると、実物とずれたことに気づけません。その折り合いの付け方です。

2026-09-02読む
09EP.9 9分

pandas.read_html で表を取る ── 動く場面と、動かない場面

Web ページの表を1行で取れる便利な関数ですが、動かないときの理由がわかりにくい。どういう表なら取れて、取れないときは何が起きているのかを整理します。

2026-09-02読む
10EP.10 9分

開発中に相手を叩きすぎない ── 応答を手元に貯める

コードを直しては実行、を繰り返すと、同じデータを何十回も取りに行くことになります。相手にも迷惑ですし、自分の待ち時間も無駄です。手元に貯めれば両方が解決します。

2026-09-02読む
11EP.11 10分

並行して取る ── 速さより先に、相手への礼儀を決める

1件ずつ取ると1000件で1時間かかる。並行にすれば数分で終わりますが、上限を決めずにやると相手を潰します。同時実行数の決め方から書きます。

2026-09-02読む
12EP.12 9分

CSV をやめて Parquet にする ── 型が消えない保存形式

CSV は誰でも開けますが、型を持ちません。保存して読み直すたびに、日付が文字列になり、先頭ゼロが消えます。取得したデータの保存先としては向きません。

2026-09-02読む
13EP.13 10分

取ったその場で検算する ── DuckDB でファイルに直接問い合わせる

取得が成功しても、中身が正しいとは限りません。件数が半分、日付が1日ずれている、同じIDが重複している。読み込む前にファイルへ直接問い合わせて確かめます。

2026-09-02読む
14EP.14 9分

応答の形を固定する ── 壊れたまま先へ流さない

配信元が項目名を変えても、型を変えても、辞書として読んでいる限りエラーは出ません。壊れた値が下流まで流れて、遠い場所で意味不明な失敗になります。

2026-09-02読む
15EP.15 9分

文字化けと改行 ── 取得した直後に壊れる

日本語のデータでは、いまだに Shift_JIS 系のファイルが配布されています。推測に任せると化け、化けたまま保存すると元に戻せません。入口で決着をつけます。

2026-09-02読む
16EP.16 9分

スクレイピングに手を出す前に ── 確認することと、やらない判断

技術的に取れることと、取ってよいことは別です。確認すべき3つと、代わりに探すべきもの、そして「やらない」という選択肢について。

2026-09-02読む
17EP.17 10分

株価が急落しているように見えるとき ── 調整後終値と株式分割

ある日を境に株価が半分になっている。事件ではなく株式分割です。素の終値をそのまま時系列に並べると、企業の行為が値動きとして混ざります。

2026-09-02読む
18EP.18 10分

分足・ティックはなぜ難しいのか ── 量と、時刻の意味

日足なら1年で250行ですが、分足だと年間9万行、ティックなら数千万行になります。量の問題だけでなく、時刻が何を指すかという問題も出てきます。

2026-09-02読む
19EP.19 9分

投資信託の基準価額を取る ── 株価と同じ扱いをすると間違える

1日1回しか更新されず、分配金を出すと下がる。株価と同じ感覚で騰落率を計算すると、分配金を出した日だけ大きく下落したことになります。

2026-09-02読む
20EP.20 9分

暗号資産のデータを取る ── 取引所ごとの差を吸収する

取引所ごとに認証も、ページングも、レート制限も違います。1つずつ実装すると数が増えるほど破綻するので、差を吸収する層を使います。

2026-09-02読む
21EP.21 9分

債券利回りを取る ── 価格ではなく利回りが動く世界

株価と同じつもりで扱うと混乱します。債券は価格ではなく利回りで語られ、しかも同じ発行体でも残存期間ごとに別の数字が並びます。

2026-09-02読む
22EP.22 10分

銘柄コードは一意ではない ── 識別子の突き合わせ

同じ会社でも市場ごとにコードが違い、廃止されたコードは別の会社に再利用されます。コードだけを鍵に結合すると、別の会社のデータが混ざります。

2026-09-02読む
23EP.23 10分

市場データの時刻 ── タイムゾーンと立会時間で1日がずれる

UTC のまま日付で区切ると、日本市場の午前と午後が別の日に割れます。夏時間のある市場を混ぜると、ずれ幅が季節で変わります。

2026-09-02読む
24EP.24 9分

指数の構成銘柄を取る ── 「今の一覧」では過去を再現できない

現在の構成銘柄で過去にさかのぼって集計すると、途中で除外された銘柄が消えます。生き残った銘柄だけで計算した結果は、実際より良く出ます。

2026-09-02読む
25EP.25 9分

土地の価格データを取る ── 公示地価と取引価格は別物

地価公示は取引が無い場所にも値が付き、取引価格情報は個人が特定されないよう丸められています。どちらを使うかで、出せる結論が変わります。

2026-09-02読む
26EP.26 9分

電力需給データを取る ── 30分ごとに動く公的データ

年次の統計と違い、電力の需給は30分ごとに記録されます。気温や経済活動と強く連動するので、他のデータに重ねる素材として使いやすい部類です。

2026-09-02読む
27EP.27 10分

数字が後から変わる ── 速報値と確報値をどう保存するか

去年と同じ集計を今日実行したら、去年と違う数字が出た。バグではなく、統計が改定されただけです。この前提を無視した保存は、いずれ矛盾します。

2026-09-02読む
28EP.28 10分

人が読む表を、機械が読める形に直す ── セル結合と多段の見出し

公的統計の表は、印刷して読むために作られています。セル結合、多段の見出し、注記の記号、合計行。そのまま読み込むと、まともに使えません。

2026-09-02読む
29EP.29 9分

スプレッドシートから取る ── 人が編集し続けるデータ源

誰かが今も編集している表を、機械が読みに行く。列が増え、行が挿入され、型が揺れる。人の運用に合わせた取得の作り方です。

2026-09-02読む
30EP.30 9分

Notion のデータベースを取る ── 型はあるが、形が入れ子

表計算ソフトと違って列に型があるので壊れにくい。ただし応答が深く入れ子になっていて、値を取り出すだけで一手間かかります。

2026-09-02読む
31EP.31 9分

更新を追うなら RSS ── 画面を解析する前に確認する

新着記事や更新のお知らせを追いたいとき、ページを解析する前にフィードの有無を確かめてください。あれば作業のほとんどが消えます。

2026-09-02読む
32EP.32 10分

PDF から表を取る ── 最後の手段だと理解したうえで

PDF は印刷のための形式で、表という構造を持っていません。文字が座標付きで並んでいるだけです。だから抽出は必ず推測になります。

2026-09-02読む
33EP.33 10分

社内のデータベースから取る ── 本番を止めないための作法

自社のデータなので好きに取れる、とはいきません。分析のための重い問い合わせが、業務システムの応答を遅くします。同じ社内だからこそ配慮が要ります。

2026-09-02読む
34EP.34 9分

メールの添付から取る ── いまだに現役の経路

取引先から毎月ファイルがメールで届く。時代遅れに見えますが、相手の運用を変えられない以上、これが唯一の経路になることがあります。

2026-09-02読む
35EP.35 10分

取りに行かずに受け取る ── Webhook を使うときの注意

定期的に問い合わせる方式は、無駄と遅れの両方を抱えます。相手から通知してもらえるなら、そちらのほうが速くて軽い。ただし受け取る側の責任が増えます。

2026-09-02読む
36EP.36 9分

定期実行を組む ── 手元の cron から始めない

自分のパソコンで cron を回すと、休んだ日にデータが欠けます。実行ログも残りません。最初から他の場所で回すほうが、結局は楽になります。

2026-09-02読む
37EP.37 10分

失敗に気づく ── 通知は「送る」より「見てもらえる」が難しい

通知を送る仕組みは簡単に作れます。難しいのは、それが読まれ続けることです。毎日鳴る警告は、1か月で誰も見なくなります。

2026-09-02読む
38EP.38 9分

何がどこから来ているのか ── 取得の一覧を持つ

取得処理は少しずつ増えます。3か月後には、誰も全体像を把握していない状態になります。一覧が無いと、止めることも直すこともできません。

2026-09-02読む
39EP.39 9分

使われていない取得を止める ── 増やすより難しい

取得は増える一方で、減ることがありません。誰も使っていないデータを毎日取り続け、相手の負荷と自分の保守を消費し続けます。

2026-09-02読む
40EP.40 9分

ここまでを振り返る ── データ取得で本当に効いたこと

40回ぶんを通して繰り返し出てきた考え方を、いくつかにまとめます。個別の技術より、この数個の判断のほうが結果を左右します。

2026-09-02読む

まずは、現状を聞かせてください。

要件が固まっていなくて大丈夫です。現状診断と方針提案までを無料でお手伝いします。

無料相談フォームへ hello [at] hukuhuku [dot] co [dot] jp