自己株買いの規模を100倍取り違えていた

「NVIDIAは過去10年で何回株式分割していますか」。 朝いちばんに聞いたのはこれだけだった。

返ってきたのは2回。 2021年7月20日の4対1と、2024年6月10日の10対1で、合わせると1株が40株になる。 ここまでは確認で済んだ。 つまずいたのは、そのあとに自分が口にした数字のほうだった。

聞いたのは分割の回数だけだった

次にAppleを調べさせた。 過去10年では2020年8月28日の4対1が1回だけで、IPO以来の通算では5回になる。

ただ、最初に返ってきた答えには自己株取得の話まで付いてきた。 自己株買いを続けている事実そのものは知っている。 知らないのは分割の回数のほうだ。 そこだけを答えてほしいと言い直させると、今度は分割の回数が表になって返ってきた。

聞いていないことを足して答えられると、確認したかった一点がぼやける。 答えが質問からずれたら、その場で言い直させるのが早い。

30%と71億という記憶

そのまま「Appleは時価総額の30%を自己株買いで削ってきたという理解でよかったか」「10年合計で71億か」と口にした。 2点とも認識がずれていると返ってきた。

30%は時価総額ではなく、発行済株式数の減少率だった。 10年合計は71億ドルではなく、FY2016からFY2025で約7,132億ドル。 $713.2 billion、日本円にして約107兆円になる。 桁が100倍ずれていた。 FY2026の9ヶ月分を足すと約7,753億ドルまで伸びる。

分割で株数を増やしながら、買戻しで削り続けている構図で、株数は約31%減っている。 分割と自己株買いを別々の話として覚えていたのが、取り違えの元だったのだと思う。 片方は1株を細かくする操作で、もう片方は1株あたりの取り分を濃くする操作だから、株数という同じ数字の上で逆向きに効く。

ついでにNVIDIAについても聞いた。 フリーキャッシュフローの50%を株主還元に回すと言っている。 それを10年続けたらいくらになるのか。 返ってきたのは4,800億ドルから1兆5,000億ドルという幅だった。 FCFの水準をどう置くかで結果が大きく振れるので、ここは幅のまま受け取っておく。

初めて分割する会社

音声入力が「記憶シェア」と書き起こした会社があった。 キオクシア（285A）のことだ。

2026年7月31日に株式分割を発表していたので、過去にもやっていたかを調べさせた。 今回が初めてだった。 2024年12月18日の東証プライム上場からまだ1年8ヶ月で、上場前にも実施していない。

上場から1年8ヶ月で分割する会社もあれば、10年で1回のAppleのような会社もある。 回数そのものを会社の性格として読むのは無理がある。

AIに「なぜそう答えたか」を聞けるか

そのあとに見かけた主張が引っかかった。 Claudeは「なんで」そう答えたかを自分でも知らない、というものだ。 thinkingの内容は直近ターンのぶんしかコンテキストウィンドウに入っていない。 だから過去の自分のアウトプットだけを見て事後に推測するしかなく、それらしい嘘が混じる。

読んでいて、前提のところが気になった。 Claude Codeはセッションログを JSONL で持っている。 だったら、思考の記録を常時コンテキストに載せておかなくても、聞かれたときにそのファイルを読みに行かせれば直接答えられるのではないか。 毎ターン抱えさせる仕組みにすると、コンテキストを圧迫するだけで割に合わない。 「なんでこうしたの」と問われたときだけスキルを発動させて、元のセッションログを見に行かせればいい。 あるいは、その仕組みだけ伝えておけば足りるはずだ。

そう考えて、いま動いているセッション自身の JSONL を確認させた。

thinkingフィールドは記録されていた。 中身は空だった。"thinking":"" が並んでいるだけで、理由はどこにも書かれていない。

読みに行かせる先はあるのに、そこに何もない。 筋がいいと思った設計の前提が、ファイルの中身のところで抜けていた。

showThinkingSummaries を有効にすると、サマリーが JSONL に書き込まれるようになる。 そこで初めて、振り返る先が存在する状態になる。 元の投稿で効いているのはこの設定の部分だけで、その先の DuckDB と hooks を組む部分は過剰装備だという整理に落ち着いた。

セッションログをどう持つか

DuckDBの名前が出たので、SQLiteとの違いも聞いておいた。 SQLiteもDuckDBも、サーバー不要の単一ファイルで動く組み込みDBだ。 ただし、得意な仕事の向きが逆になる。 SQLiteは行指向で、1件ずつ読み書きする業務処理に向く。 DuckDBは列指向で、大量のデータをまとめて集計する分析に向く。

それを聞いて、もうひとつ思いついた。 セッションログはアーカイブしているが、中身は無加工のまま置いている。 これをDuckDBに入れて、そのDuckDBのほうを保存対象にしたら、バックアップの用途としては今より良くなるのではないか。

答えは逆だった。 正本は生の JSONL のままにしておくべきで、DuckDBを正本に置き換えるのはやめたほうがいい。 使うなら、rawから何度でも作り直せる使い捨ての分析用インデックスとして持つ二層構成になる。 その形なら、DuckDBファイル自体はバックアップの対象から外れる。

前提の訂正も入った。 いまの体制はセッション JSONL を gpg（AES256）で暗号化して Google Drive と F: の2系統へ日次で送っている。 だから「プレーンな生」という言い方は正確ではなく、「暗号化はされているが中身は無加工の raw JSONL」になる。 バックアップとして効いているのは、この無加工のほうだった。

運用を変える必要があるか

ここまで聞いたところで、最後の確認をした。 自分の運用からすると、特に何も変える必要はないという理解で合っているか。

合っている、と返ってきた。 バックアップ体制はそのままでよく、DuckDBは横断分析をやりたくなった日にその場で作ればいい。 いま準備しておくものはない。

ついでにバックアップのログも見ておいてもらった。 手動実行は両系統とも成功していて、鮮度も回復していた。 09:13時点で cutoff も前進していたので、再送の積み残しもなかった。

自分の側の前提

この日に調べた2件は、分野も使う道具もまるで違う。 共通していたのは、崩れたのが調べた対象ではなく自分の側の前提だったことだ。 片方は数字の桁で、片方はファイルの中身。 どちらも「たしかそうだったはず」で止めていたら、そのまま人に話していた。

Appleの10年で7,132億ドルという数字は、覚え直した。 showThinkingSummaries のほうは、次に「なんでそうしたの」と聞きたくなったときに考える。 振り返る先が空のままなら、聞いても事後の推測しか返ってこないと分かっただけで、いまはいい。