クラウドストレージから資料を回収し、原本を消さずに整理する流れをスキルにした

「アクセスできるんでしたっけ。ちょっと試してもらっていいですか」から始めた作業だった。 つながるかどうかを確かめたかっただけで、その日のうちに 3.4GB を手元へ落とすことになるとは思っていない。

読めることと、落とせることは別だった

支援先の事業者の資料がクラウドストレージに置いてある。 まず Claude Code からつながるかを試させたら、あっさり読めた。 直近のファイル10件が並んで返ってくる。 検索も本文の読み取りも通る。

そのまま「今日入った2件を、作業ディレクトリの下にディレクトリを切って落としておいて」と頼んだ。 ここで止まった。

読み取りに使っている経路と、ファイルを落とす経路が別だったからだ。 落とす側は CLI ツールで、移ってきたばかりのこの Mac では未認証のまま置いてあった。 代わりに使える経路も無い。 同意画面をブラウザで踏めるのは自分だけなので、ここから先は AI 側で一歩も進まない。

報告は正直だった。

ローカルにはまだ1バイトも落ちていません。

読めているのはクラウドを直接叩いているからで、手元には何も無い。

最終版がどれかを、更新日時とファイル名から突き止める

次に頼んだのは、最終版の計画書がどれかを突き止めることだった。

その前に「計画書がこれから入ってくるので、中身を見て、やりたいことを把握しておいて」と投げていた。 ただ、このときはまだ届いていなかった。 名前に「計画」の付くものは引っかかる。 ただしどれも既存の様式やテンプレートで、探しているものではない。

ディレクトリが散らかっている可能性は高いと思っていた。 そこで、いきなり最終版を当てにいかせず、手前に1つ挟んだ。 ファイル名と更新日時で構成を一通り把握して、テキストに書き出しておくこと。

一覧は次ページのトークンが尽きるまで回させて、ツリーを組み直させた。 この時点でも、ローカルには何も落ちていない。 落とす経路が塞がったまま、読む経路だけで棚卸しが進んでいる。

先に一覧が手元に出ると、「最終版はどれか」は目で追える問題に変わる。

120秒でタイムアウトした認証は、失敗していなかった

自分でターミナルに認証コマンドを打った。 120秒で返ってこず、バックグラウンドに移されたというメッセージが出る。

失敗したと思った。 「これはうまくいったんですか。タイムアウトしてますね」と聞いて、もう自分でダウンロードしたほうが早いかもしれないとまで言っている。

原因を調べさせたら、そうではなかった。

プロセスは生きていた。 ローカルポートで待ち受けたまま、ブラウザの同意を待っている。 120秒はコマンドを走らせた側の待ち時間の上限であって、認証が落ちた印ではない。 開いていなかったのは同意画面のほうだった。

ブラウザを開かせてアカウントを選び、許可を押した。 それで exit code 0 が返ってきた。 自分が踏むべき一歩を踏んでいなかった、というだけの話だった。

続きも素直ではない。 認証は通ったのに、最初の一覧が空で返る。 個人の領域ではなく共有領域に置かれたファイルは、フラグを足さないと見えない仕様だった。 フラグ付きで叩き直したら中身が出た。 ログイン直後の1回目だけ API がエラーを返したが、これは一過性らしく、再実行で通っている。

690ファイル、3.4GB、失敗0

経路が開いたので、あとは量の問題になった。 サブエージェントを8系統に分けて投入し、うち6系統を並列で走らせる。 系統ごとに担当が重ならないよう、除外指定を渡せるようにしてから流した。

途中経過は100ファイルで168MB、次に見たときは637ファイルで3.4GB。 完走の報告は690ファイル、失敗0だった。

数は突き合わせて確かめた。 ローカルのファイル数がクラウド側より多い。 内訳を出させると、各系統が書き出した一覧ファイルが7件と、macOS が勝手に作る隠しファイルが3件あった。 差はそれで全部だった。 クラウド側687に対してローカルも687で、取得漏れはゼロだった。

事前の一覧が間違っていた箇所も出てきた。 動画は8本と数えていたが、実際は9本で 2.0GB あった。 棚卸し表を作った時点ではあくまで仮説で、実測が出たら直す。

原本は消さない。コピーの上でだけ整理する

回収した中には、Thumbs.db のようなゴミが混ざっている。 クラウド側にも28件あって、消す権限は全件そろっていた。

それでも消さない方針にした。 落としたままの原本ディレクトリには触らず、別のディレクトリへコピーして、その中だけで整理する。 旧版もゴミも捨てず、アーカイブとして脇に寄せる。

理由は単純で、支援先から預かった資料だからだ。 消す判断を1回でも入れると、あとから「元は何件あったのか」を確かめる手段が無くなる。 残しておけば、整理の結果が気に入らなくてもやり直せる。

整理後は687件で、うち本体が602、アーカイブが85だった。 原本697ファイルはそのまま残っている。

同じことを、次の事業者でもやる

ここまでの流れは、この1件で終わらない。 回収して、コピーして、整理して、最新版を特定する。 支援先が変わっても、順番は同じになる。

欲しかったのは手順そのものより、途中でどう線を引いたかのほうだった。 何を一覧に載せるか、どれをアーカイブへ回すか、何を消さないと決めるか。 次に同じ作業をするとき、この基準を毎回ゼロから作り直したくない。

だからスキルにしてもらった。 既存スキルの書式を確認させてから書かせた。 できたものはローカルサーバー経由で Chrome に出させ、表と目次とコードブロックが崩れていないところまで見た。 file:// は拡張機能から開けないので、そこだけサーバーを噛ませている。

置き場所は直させた。 最初はユーザーレベルに書かれていた。 全リポジトリで読まれる場所だ。 このスキルは支援先1件ぶんの作業ディレクトリでしか使わない。 プロジェクト側の .claude/skills/ へ移させて、ユーザーレベルに残っていないことも確認させた。

道具を1つ増やすと、それが読まれる範囲も一緒に決まる。 範囲を広く取れば、関係ないリポジトリでも毎回読まれることになる。

今日わかったこと

• 読める経路と落とせる経路は別だった。クラウドを直読みできても、手元に落ちるとは限らない
• 120秒のタイムアウトは、コマンドが待たされた印であって、失敗の印ではなかった。プロセスが生きているかを見れば区別が付く
• 認証を通したあとも、共有領域のファイルはフラグ1つで見えたり見えなかったりする
• 棚卸し表は仮説として作って、実測で直す。動画の本数は事前カウントより1本多かった
• 消さないと決めておくと、整理の判断が軽くなる。原本を残したまま、コピーの上でだけ動かす
• 同じ作業を別の相手でも繰り返すなら、手順より線引きの基準を残す。置き場所は、その作業が起きるプロジェクトの側にする