2026年7月31日の開発日記 - 消えたファイルの原因を物証で特定した日
2026年7月31日の開発日記
スタート検索にスキャナの取り込みアプリの名前を打ち込んでも、候補に出てこない。 この違和感から、2日前のファイル消失事故を洗い直すことになった。 原因を指したのは、消えたディレクトリの外に落ちていた出力ファイルだった。
残りの時間は、ランチェスター戦略のスキル化と実機テスト、決算コメントの検算、蔵書データベースの運用、デプロイまわりの整理に使った。
今日のタイムライン

- ログ管理(mdx-playground): 22時間50分、18セッション、6,565メッセージ
- ナレッジ管理(book-knowledge-base): 4時間58分、2セッション、1,351メッセージ
- 稼働はおおむね 06:35 から 15:28 まで
セッションを並行して走らせているため、合計は実時間を超える。
今日やったこと
1. 消えたファイルの原因を物証で特定した
2日前に ~/.claude が消えた事故の被害範囲が、こちらの把握よりずっと広かったと分かった。
ProgramData 配下のショートカット、スキャナのドキュメントプロファイル、スキャンPDFの保存先フォルダまで消えていた。
ごみ箱、イベントログ、シャドウコピーを順に当たったが、どれも空振りに終わった。
決め手は、~/.claude の外にある一時ディレクトリに残っていたバックグラウンドコマンドの出力ファイルだった。
cp932 でデコードし、8.3短縮名を実名に解決すると、再帰削除が2回走った痕跡が読めた。
主な成果:
- 証拠一式を外部SSDへ保全した
- 再発防止を4層で入れた(再帰削除の無条件ブロック、条件判定するフック、削除ログの記録、auto mode の分類器設定)
- 設計判断として、フック本体を消える側のディレクトリに置かないことを決めた
- 体感速度への影響を実測した(測定設計の失敗も含む)
- 削除コマンドの全文と実行に至った動機は、不明のまま残した。筋の通った仮説を2つ立てたが、裏が取れずに取り下げた
2. ランチェスター戦略を2段スキルにして自分の事業で実機テストした
蔵書データベースに入れた戦略理論の1冊を読み込ませ、スキルの形を検討した。 最初に出てきたレポートは整っていたのに、読んでも明日やることが出てこない。 現状診断と戦略策定の2工程に絞り、さらに更新頻度の違いから「自社プロファイル作成」と「競合局面診断」を別スキルに分けた。 プロファイルのほうは複数の局面で使い回す。 自分のコンテンツ事業を題材に実機テストして、出てきた不具合をスキル側へ書き戻した。
主な成果:
- 「戦場を1つ選べ」に対して、全局面を分岐させる形で診断させた。テスト結果を受けて、複数局面を同時に走らせる形を既定に昇格した
- 外部AIのDeep Researchを競合調査に組み込んだ。プロンプトが空のまま走る事故が起きたので、スキルに注意書きを追記した
- 検討結果はHTMLにしてブラウザに表示し、判断事項はHTMLの選択フォームで回答した
- 成果物から「結局どう進めばいいのか」が読み取れず、結論セクションを冒頭に足させた
- スライドに出てきた「止まっている先行者」が自分の講座だったので、競合リストから自社を除外する一行をスキルに加えた
詳細: ランチェスター戦略の競合診断をClaude Codeの2段スキルにして自分の事業で実機テストした
3. 決算コメントの「3年未満で回収」を原文で検算した
回ってきた5点の要約を、原文と決算リリース、10-K に当たって突き合わせた。 「3年未満で回収」の主語はサーバーとネットワーク機器に限られる。 5点目については、そもそもそういう言い方をしていなかった。 過去記事から「1ドルの支出で4年間で5ドルの収入」を拾おうとしたが取れず、全文検索させたところ今回が初出だった。
午後は3社比較に移った。 EDGARから一次情報を取得し、予測の起点を2025年通年に作り直した。
主な成果:
- 27%で噛み合う検算をSVG図解にした。半導体メーカー側トップの発言と整合するという指摘も記事に足した
- ラベル配置を「順位 → 衝突検出 → 下へ逃がす」方式に変更した
- 純粋関数
cloudFcfProjection.tsとchartAxis.tsを切り出し、テスト26件を追加した(全体19,376件) - 公開記事2本にまとまった: Amazonの「設備投資は3年未満で回収」を原文で確認した / クラウド3社の設備投資とフリーキャッシュフロー
詳細: 決算コメントの「3年未満で回収」を原文で検算し、クラウド設備投資チャートと純粋関数に落とすまで
4. 蔵書データベースの運用整備と認証情報の正本移行
朝いちばんは取り込みだった。 電子書籍リーダーで開いていた2冊を、撮影からOCR、DB投入、再構造化、画面確認まで通した。 そのあと「別のPCでクローンすれば本棚が開くのか」を調べ直したら、認証情報ファイル1つで足止めされると分かった。 正本を1Passwordに置き、ローカルは書き出した派生物として扱う方針に決めた。 実行のたびに注入する形も検討したが、参照箇所が93と243あって現実的ではなかった。
主な成果:
- 裁断スキャンPDF3冊の重複判定とOCR、再構造化を回し、飛ばしていた図表クリーンアップ工程を見つけた
- 5GB超あったリポジトリの内訳を調べ、変換時の残骸を掃除して .gitignore に追加した
- 353バイトと4,826バイトのファイルを取り違えて誤診した。調べ直したら、片方は誰からも読まれていない残骸だった
- 別の1冊をDBから取り出してスキル化の準備をした。テストは翌日に持ち越してタスク登録した
詳細: 蔵書データベースの運用整備と、認証情報の正本を1Passwordに置く判断
5. dev を止めずにデプロイできるようにした
前日に入れたポート3000のガードで所要時間の計測スクリプトが止まった。
原因は pnpm dev と pnpm generate が .nuxt と Content の SQLite を共有していたことだった。
禁止するのをやめ、generate 側だけ .nuxt-build と .data/content-build に逃がして競合そのものを消した。
dev を動かしたままの generate 検証は途中で二度止まった。
0xC0000142 の正体は、dev 3つと chrome-devtools MCP 4つで 9.7GB を食っていたメモリ枯渇だった。
掃除して完走させると、7/30 に落ちた検証2本が両方パスした。
主な成果:
- 走りっぱなしのプロセスを自分では検知できない問題から、ステータスライン表示と
/procsを作った - Claude Code 2.1.210 の更新で効かなくなっていた権限設定の行を削除した
詳細: dev サーバーを止めずにデプロイできるよう、Nuxt のビルド出力先と Content DB を分けた
6. その日書いた他の記事
- ランチェスター戦略の要点をまとめた解説を、非公開から公開に切り替えた: ランチェスター戦略のエッセンスレポート。あわせて事例図6枚を「Before/After を左右、打ち手を下段」の2段構成に変更した
- 知人とのやりとりをきっかけに、なぜ個別株の現物を中長期で持つのかを書いた: 個別株を現物で中長期に持つ理由
- キャッシュレス決済手数料を、クレカ分とコード決済分で分ける消費税の扱いを解説した: キャッシュレス決済手数料の消費税区分と仕訳
- 職務経歴書の書き方の図を、使い回しの効くポンチ絵として作り直した: 職務経歴書は3つの図形で語る
今日の試行錯誤
| # | テーマ | 試したこと | 結果 | 気づき |
|---|---|---|---|---|
| 1 | 消えたファイルの追跡 | ごみ箱、イベントログ、シャドウコピー、復元ポイントを順に確認 | 失敗 | Windows は既定でファイル削除を監査しない |
| 2 | 同上 | ~/.claude の外の一時ディレクトリに残ったコマンド出力を探した | 成功 | 爆心地の外に落ちた副産物が唯一の物証になった |
| 3 | 物証の解読 | 出力をそのまま読もうとした | 失敗 | cp932 デコードと8.3短縮名の解決が要る |
| 4 | 事故の動機の特定 | 筋の通った仮説を2つ立てた | 取り下げ | 裏が取れないものは推測で埋めない |
| 5 | ランチェスターのスキル化 | 書籍の内容をそのままレポートにさせた | 失敗 | 整ってはいるが明日やることが出てこない |
| 6 | 同上 | 現状診断と戦略策定の2工程に絞り、2段スキルに分けた | 成功 | 更新頻度が違うものは別スキルにすると使い回せる |
| 7 | 競合調査の外注 | 外部AIのDeep Researchに投げた | 事故 | プロンプトが空のまま走った。スキルに注意書きを追記 |
| 8 | 診断結果の受け取り方 | 成果物をそのまま読んだ | 失敗 | 「結局どう進めばいいのか」が読み取れず、結論を冒頭に足させた |
| 9 | 決算コメントの検算 | 過去記事から数字を拾おうとした | 失敗 | その表現は今回が初出だった |
| 10 | 同上 | 原文と決算リリース、10-K に当たり直した | 成功 | 要約の主語が限定されていることに気づけた |
| 11 | デプロイのガード | dev を止めてからデプロイする運用にしようとした | 却下 | 止めずに済む方法があるなら禁止で解決しない |
| 12 | 同上 | generate のビルド出力先と Content DB を分けた | 成功 | 競合そのものを消せば禁止が要らなくなる |
| 13 | generate が途中で止まる | 再実行した | 失敗 | 0xC0000142 はメモリ枯渇のサイン |
| 14 | 同上 | 走っていた dev 3つと MCP 4つを掃除した | 成功 | 自分では検知できないので一覧と掃除の口を作った |
| 15 | 認証情報の置き場 | 実行のたびに1Passwordから注入する形を検討 | 却下 | 参照箇所が93あって現実的でない |
| 16 | 同上 | 正本を1Passwordに置き、ローカルは書き出した派生物とした | 成功 | コードを1行も変えずに正本を移せる |
| 17 | ファイルの取り違え | サイズだけ見て同じものだと判断した | 失敗 | 353バイトと4,826バイトは別物。片方は誰も読んでいない残骸だった |
今日の学び
- 消えたものを全部特定できないのには、構造的な理由がある。失敗した削除しか記録に残らない
- 安全機構は、それ自身が消される側に置いてはいけない
- 裏が取れない仮説は、筋が通っていても取り下げる
- スキルは「読める成果物」ではなく、「明日やることが出てくる成果物」を出させる形にする
- 禁止で解決する前に、競合そのものを消せないか考える
- 正本をどこに置くかを決めれば、コードを変えずに運用を変えられる
明日やること
- 対人コミュニケーションの1冊から作ったスキルのテストを書く(タスク登録済み)
- 韓国の7月分輸出統計を取り込む(本日の実行時点では未公表)
- 決算データ取得元の再ログイン後に、7/31 発表分の四半期データを反映する