この記事の実施記録（2026年8月）: AmazonのKindle購入履歴を取得しようとしたが、公式APIは存在しなかった。Kindleアプリの操作もローカルDBの参照もできず、最終的に「コンテンツと端末の管理」画面が使う内部APIを叩いて888件の蔵書データを取得した。そのあとに申請した公式のデータリクエスト（注文履歴の開示）は、確認メール受信から46分後に完了メールが届いた。結論を先に書くと、同じデータが欲しい人にまず勧めたいのは内部APIではなく公式のデータリクエストのほうだ。この一連の調査・検証はClaude Codeに任せて進めた。

公式APIも、アプリもローカルDBも使えなかった

Amazonには個人の購入履歴を取得する公式APIが用意されていない。Product Advertising APIは商品情報のみ、SP-APIはセラー向けで、どちらも使えない。

Kindleアプリの直接操作は、Claude Codeのコンピュータ操作機能がポリシー上ブロックしていて選択肢から外れた。Kindle for Macのローカルデータベース（SQLite）も調べたが、中身は表示用キャッシュ11件のみで購入日を保持していなかった。

Gmailの注文確認メールは3世代で仕様が違った

次に、Gmailに残る注文確認メールを検索した。すると時期によって形式が3世代に分かれていた。

世代	期間	件名	書名の有無	サイズ
新形式	2025年8月〜	「ご注文: 〈書名〉」	件名・本文ともあり	約7万字（98%がHTMLタグ。実質1,417字）
旧形式	〜2025年7月	「ご注文D01-XXXX（1点）」	件名になし、本文にあり	約2.5KB、プレーンテキスト
なし	2019年以前	—	—	Gmailに1通も残らず

新形式は情報量が多い代わりにノイズも多く、7万字のうち使える情報は1,417字だけだった。旧形式は件名だけ見ると「情報が無い」ように見えるが、本文を開けば書名も金額もちゃんと記録されている。2019年以前のメールはそもそも1通も残っていなかった。

スニペットに情報が無いことは、存在しない証拠にならない

ここで判断を誤った。手元にある本が集計台帳に見当たらず「メールを削除したのでは」と推測したが、実際は購入済みでメールも残っていた。当時の形式が件名に書名を含まなかっただけだ。もう1件、「旧形式メールは書名を含まない」とも結論づけたが、実際には本文に書名・注文番号・金額がすべて入っていた。原因はどちらも、検索結果のスニペット(本文冒頭150字ほど)だけを見て本文を開かずに判断したことだった。

教訓はシンプルだ。スニペットに情報が出てこないことは、本文に情報が無いことの証拠にはならない。「存在しない」と結論づける前に、最低1件は実物を開いて確認する必要がある。

突破口：「コンテンツと端末の管理」の内部API

Gmailだけでは全期間をカバーできないとわかり、Kindleの蔵書一覧を表示する「コンテンツと端末の管理」というWebページに着目した。画面は25件ずつのページ送りだが、裏側の通信を覗くと、画面表示のために内部APIが蔵書データをJSONで返していることがわかった。公開ドキュメントには載っていない、Amazon内部の仕組みだ。

このAPIへのリクエストを工夫すると、ページ送りを待たず蔵書データを一括取得できた。取得件数は888件。書名・著者・取得日に加え注文IDまで含まれる。リクエストの種類を変えると、Audibleの購入履歴も15件取れた。

ここで一つ断っておきたい。この内部APIは公開ドキュメントがなく、Amazonの利用規約上どこまで許容される操作なのか明記されていない。自分自身のアカウントの、自分自身の購入データを見るためだけに使ったとしても、画面操作を経由しない直接アクセスが規約のグレーゾーンに触れる可能性はある。可否は各自で確認してほしい。仕様も予告なく変更・停止されうるので、この記事では具体的なエンドポイントやパラメータ名までは書かない。同じデータが欲しいなら、まず次の節で紹介する公式のデータリクエストを試すことを勧める。

この内部APIには限界もあった。金額は含まれず、金額情報はGmailに残るメールからしか取れない。件数も完全ではなかった。内部API経由で取れたAudibleの購入履歴は15件だったが、後述する公式データ開示で数え直すと、Audibleだけで23作品購入していたことがわかった。8作品を内部APIは取りこぼしていたことになる。

最後に、そしてもっと先に試すべきだった公式ルート

金額を全期間分そろえる課題が残ったため、最後の手段としてAmazon公式の「データをリクエストする」機能（アカウントサービス内）から注文履歴の開示を申請した。申請から受け取りまでの流れは次の通り。

アカウントサービス内の「データをリクエストする」機能から、注文履歴のデータを選んで申請する
申請直後に確認メールが届く（メール内のリンクは5日間で失効する）
リンクを開いて申請を確定させ、完了メールを待つ——今回は確認メール受信14:16から完了メール受信15:02まで46分だった
完了メールのリンクからZIPをダウンロードする（ダウンロード期限は完了後90日間）

Amazonの案内は「数日かかる」だったが、実際は1時間もかからなかった。届いたのはZIP84MB・1,454ファイルで、中身は以下の通り（数値はいずれもAmazon公式データ開示CSVの実測値）。

Digital Content Orders.csv（2,285行）: Kindle・アプリ・動画・ゲームのデジタル購入明細。2012年11月〜2026年8月
Order History.csv（2,537行）: 物理商品の注文履歴。2001年2月〜2026年8月の25年分
Digital Borrowed Items.csv（91行）: Kindle Unlimited 75件・Prime Reading 14件・Kindle Owner's Lending Library 2件
領収書PDF 1,443ファイル、返品・返金系CSV 4ファイル（Digital Returns.csvは返品日・ステータスを含む42行、残り3ファイルは数行程度）

内部APIを叩くよりも先に、この機能を試すべきだった。手間も待ち時間も少なく、物理商品25年分まで一度に手に入る。

届いたCSVにも4つの落とし穴があった

公式データも「そのまま使える」わけではなかった。実際に集計して踏んだ落とし穴は4つ。

1. 金額がカンマ区切り文字列: Order History.csvの金額列は「1,296」のようなカンマ区切り文字列。正常に完了した注文（Order Status: Closedが2,361件。全2,537件からキャンセル173件と未確定のAuthorized3件を除いた数）で集計すると、カンマ処理を忘れて数値変換した場合の合計は395,056円だったが、カンマを除去すると6,281,217円だった。正しい合計の6%程度にまで縮んでいたことになる。

2. 1購入が複数行に分裂、しかも打ち消しペアがある: Digital Content Orders.csvはComponent Typeが「本体価格」と「消費税額」に分かれ、同じ注文・商品で2行になる（2,285行中Price Amount 1,240行・Tax 1,005行）。両方とも同じPrice列の値を持つため、正常に完了した注文（Order Status: SUCCESS、2,284件）で単純合計すると1,745,806円になる。

ここでPrice列だけを見て「返金・再課金のマイナス行は無い」と判断してしまった——実際Price列に負の値は1件もない。だが金額の増減はTransaction Amount列に現れていた。同列が負の行は78件あり、同一注文・同一商品で完全に打ち消し合う組が23組見つかった。例えば「オーバーロード4」は同一注文内で[-2315, +2315, +185, -185]の4行に分かれ、合計は0になる。「マイナスが無いから返金は無い」という判断こそが、列を見誤った実例だった。

23組はすべてAudible作品（Seller of Record: AudibleJP）だった。うち8組は同じZIP内の返品専用CSV（Digital Returns.csv）にReturn Status: Customer Return Complete・Returned By: Customer Initiatedという記録があり、顧客都合の返品と確認できた。残り15組はこのCSVに該当する記録が見つからず、返品制度による返金・再課金と推測するにとどまる。

3. Price Taxは税額ではなく税込価格: 列名から税額そのものと誤読しやすいが、実際に1件確認するとPrice597円に対しPrice Taxは645円で、差額48円が消費税額だった。

4. 書籍と非書籍を判別する列がない: Seller of Record（販売者名）に出版社名が入る行もあるが、最大勢力「Amazon Services International LLC」には書籍・アプリ・動画・ゲームが混在する。ユニークASIN 1,009件中462件がこの表記で、名前だけでは仕分けられない。

こうしたCSVの前処理を自分の手でやってみたい人には、Excel処理・スクレイピング・大量ファイル操作までを一冊でカバーする『退屈なことはPythonにやらせよう第3版』が定番の入門書だ。今回私がClaude Codeに任せた作業も、突き詰めれば同じ発想の延長線上にある。

内部APIと公式ルート、どちらを使うべきか

冊数・書名・取得日だけなら内部API（「コンテンツと端末の管理」）が一番早い。ログインした状態からリクエストを送るだけで待ち時間なく返ってくる。金額・全期間の網羅性が欲しいなら公式のデータリクエストのほうが確実だ。25年分が1回の申請、46分で揃う。ただし上記4つの落とし穴があり、そのまま集計に使うと簡単に数字を誤る。

内部APIは公式ドキュメントに載っていない迂回路で、規約上の位置づけも曖昧なまま、いつ仕様変更で使えなくなってもおかしくない。最初にデータリクエストを申請していれば、内部APIを探し当てるまでの試行錯誤の一部は要らなかったかもしれない。

余談だが、この888件のデータで「なぜ年によって購入量が20倍近く変わるのか」を分析した読書量は「意志」ではなく「構造」で決まる——Kindle購入履歴888冊が教えてくれたことも別に用意している。技術的な探索過程を追うのが今回の記事なら、そちらはデータの中身を掘る記事だ。

内部APIを探り当て、公式ルートに突き当たり、CSVの落とし穴を1つずつ潰す——こういう探索は手順として整理しておくと後で効いてくる。Claude Codeにコードを書く以外の調査タスクを任せると、こういう地道な探索も代行してくれる。

こうしたエージェントとの付き合い方を積み上げた記録がコードを書けない私がClaude Codeで「AIチーム」を作るまで（序章・第1部無料）だ。

この記事ははてなブログからのクロスポストです。