最近、ObsidianのVaultをGitHubで管理しています。
せっかくGitHub上にデータがまとまっているので、ある時ふと思い立って、うちのClaude CodeにGitHubのデータを使って思考・提案をやってもらおうと考えました。（厳密には、Claude Codeをスマホから操作して、Obsidianに書き溜めているレシピをもとに数日間の献立を提案してもらおうと思ってました）
そこで早速スマホのClaudeアプリを起動。GitHubリポジトリをClaude Codeに読み込ませて、Vault内のレシピを参照…してもらおうとしたのですが、
なぜか、肝心のリポジトリが読み込めない。
「このリポジトリだけ」読み込めない
最初は、リポジトリそのものに何か問題があるのだろうと思いました。そこで念のため、手元にある別の公開・非公開GitHubリポジトリでも試してみることに。
すると、
公開リポジトリ
非公開リポジトリ
結果としては、
- 公開リポジトリ → 読み込める
- プライベートリポジトリ → 読み込める
- 問題のObsidian Vaultのリポジトリ → 読み込めない
となりました。
GitHubの認証やアクセス権限の問題ではなさそうです。
では、いったい何が違うのか。
とりあえず必要なファイルだけにしてみる
原因がよく分からなかったので、いったん問題のリポジトリから、今回のツールに必要なデータだけを抜き出したブランチを作ってみました。
そして、そのブランチをAIエージェントに読み込ませてみると、今度はうまくいきました。
「じゃあ、やっぱりリポジトリの中身のどこかに問題があるのか……？」
そう思いながら、そのブランチを使ってClaude Codeとしばらく会話していました。
すると、あるときClaude Codeがぽろっとこんなことを言いました。
なんだって？
犯人はファイル名
「ファイルが長い」とはどういうことなのか。
問いただしてみると、Claude Codeが具体的なファイル名を挙げてくれました。
実際にファイル名を見てみると…確かにかなり長い。
志望理由の設問をそのままファイル名にしていた
エラーの原因としては、（検索しやすいようにテキストで記録しておくと）
ファイル名本体だけで100文字近くあり、多くのファイルシステム（多くのLinux環境ではファイル名は255バイト制限）に対して、日本語（マルチバイト文字）を含むためバイト数換算で上限を超えてしまい、
git checkoutやgit worktree addでこのファイルを書き出そうとした時点でFile name too longエラーになりました。
とのこと。
Obsidianで管理しているノートなので、自分としては「後から見ても何のファイルか分かるように」と、かなり丁寧に名前をつけていました。
人間が読む分には分かりやすい。でも、AIエージェントに大量のファイルを読み込ませるという観点では、これが思わぬところで問題になっていたようです。
そこで、他にも長そうなファイル名をいくつか見つけて、適度に短く変更。その後、改めてmainブランチを読み込ませてみました。すると……
無事、リポジトリの読み込みに成功しました。やったね。
教訓：ファイル名を侮るなかれ
今回の一件で学んだのは、ファイル名、意外と侮れない。 ということでした。
ファイル名なんて、人間が見て分かればそれでいいだろうと思いがちです。私自身、「どんな内容のファイルなのか一目で分かるように」と、長めのファイル名をつけていました。
しかし、AIエージェントやその他のツールにリポジトリを丸ごと読み込ませる場合、ファイル名の長さそのものが処理上の制約に引っかかることがある。また、今回のように、エラーメッセージ単体では原因が分かりにくいケースもあります。
なので、今後は 「分かりやすければいい」ではなく、「分かりやすく、かつ簡潔に」 を意識してファイル名をつけようと思います。
結論。ファイル名を侮るなかれ。
分かりやすさは大事。でも、長すぎる名前もほどほどに。