Claude Codeのread-onlyモードで既存コードを壊さず分析するコツ

2026年3月9日

URLをコピーしました！

Claude Codeは、ターミナルから直接ファイルを操作できる強力なAIツールです。しかし、大規模なプロジェクトや大切なソースコードを扱うとき、「AIが勝手にコードを書き換えて壊してしまったらどうしよう」と不安に感じることはありませんか？

そんな心配を解消してくれるのが、ファイルの書き込みを一切行わない「read-only（読み取り専用）モード」です。この記事では、既存のコードを一文字も変えることなく、AIの知能を借りて深く分析するための具体的な手順と運用のコツを解説します。

Claude Codeのread-onlyモードが持つ役割

Claude Codeを読み取り専用で起動すると、AIは「腕利きのエンジニア」から「冷静な解析官」へと役割を変えます。まずはこのモードがどのような仕組みで動き、私たちの開発環境をどのように守ってくれるのかを整理しましょう。

本章では、read-onlyモードの定義と、通常モードとの決定的な違いを解説します。AIに「ペン」を持たせず「地図」だけを読ませることで得られるメリットを確認していきましょう。AIへの主導権を人間が握り続けるための重要なステップです。

ファイルの書き換えを物理的に禁止する

read-onlyモードで起動したClaude Codeは、ファイルの中身を書き換えるための機能にアクセスできなくなります。これにより、どれだけAIが「ここを直したい」と考えても、実際のソースコードに手をつけることは物理的に不可能です。

例えば、複雑なロジックを読み取らせている最中に、AIが良かれと思って「コードを整理しました」と報告してくる事故がなくなります。

私たちはAIが吐き出す「解説」や「分析結果」だけに集中して耳を傾けることができるのです。

AIに頼り切るのではなく、まずは自分自身の理解を深めるための「壁打ち相手」として使うのに最適です。

以下の表に、通常モードとの動作の違いをまとめました。

機能	通常モード	read-onlyモード
ファイルの読み込み	自由にできる	自由にできる
コードの新規作成	実行可能	実行不可
既存コードの修正	実行可能	実行不可
ターミナルコマンド	実行可能	実行不可（一部制限）

既存リポジトリへの影響をゼロにする

読み取り専用モードを使えば、Gitの管理下にあるファイルを汚す心配がありません。どれだけAIに無茶な質問を投げても、変更されたファイルが一行も出てこない安心感は格段に高いものです。

不慣れなプロジェクトに参加した直後は、どこを触るとどこが壊れるかの判断がつきにくいでしょう。

そのような場面で、まずは環境を一切変えずに「このコードは何をしているのか」をAIに問い続けることができます。

変更履歴を汚さない
修正の差し戻しが不要
差分（Diff）が出ない
本番環境でも安心

このように、心理的なハードルを下げてAIを活用できるのが、このモードの最大の魅力です。

まずは「壊れるリスク」を忘れて、自由にコードの森を探索してみましょう。

解析結果をテキスト出力に特化させる

read-onlyモードのClaude Codeは、コードを書く代わりに、言葉で説明することに全力を注ぎます。AIが生成する回答は、プログラムの修正案ではなく、構造の解説やバグの指摘といったドキュメント形式が主になります。

「修正後のコードをファイルに保存しました」と言われる代わりに、「この行にこのような問題があると考えられます」という論理的なフィードバックが返ってきます。

私たちはそれを見て、自分の頭で納得してから、自分の手でエディタを動かすことができます。

結局、自分の手でコードを書いた方が理解が深まることも多いのではないでしょうか？

AIを高性能なリサーチツールとして再定義することで、エンジニアとしてのスキルアップにも繋がります。

指示の出し方一つで、AIはあなたの知識を広げる最高のアドバイザーに変わります。

既存コードを壊さずに分析する必要がある理由

開発現場において、AIによる自動修正が常に歓迎されるわけではありません。特に歴史のあるコードベースや、多くの人が関わるプロジェクトでは、非破壊的なアプローチが不可欠な場面が多々あります。

本章では、なぜあえてAIの「書く力」を封印して分析に徹するべきなのか、その背景にあるリスクと開発者の心理にフォーカスします。安全第一で進めることが、結果として近道になる理由を整理しましょう。全体の構造を崩さずに知見を得るための土台を作ります。

予期せぬ自動リファクタリングによる事故を防ぐ

自律型のAIエージェントは、時に私たちの想像を超えた広範囲の修正を行おうとします。一つのバグを直すために、関係のない10個のファイルをリファクタリングし、意図しない破壊的変更を加えてしまうリスクはゼロではありません。

特に、テストコードが十分に整備されていない古いプロジェクトでは、AIの修正が正しいかどうかを瞬時に判断することが困難です。

「良くなったはずなのに、動かなくなった」という事態を避けるためには、まず分析フェーズで「どこに手を入れるべきか」を特定するだけに留めるのが賢明です。

例えば、以下のようなケースでは、まず読み取り専用での調査を推奨します。

本番環境に近いコード
テストカバレッジが低い
依存関係が複雑すぎる
共通部品の基幹ロジック

分析だけに徹することで、AIが暴走してプロジェクトをひっくり返す心配を根こそぎ断つことができます。

慎重すぎるくらいが、プロの開発現場ではちょうど良いバランスとなります。

開発者の心理的な安心感を確保する

AIにコードを任せるのは、まだ少し怖いと感じることはありませんか？

そう感じるのは、エンジニアとして健全な感覚です。read-onlyモードは、こうした心理的な不安に対する強力な特効薬になります。

自分の大切な作品であるコードに、正体の知れない知能が勝手に筆を入れることへの抵抗感は、誰にでもあるものです。

読み取り専用という制約をかけることで、「絶対にコードは変わらない」という担保が得られ、落ち着いてAIの意見を聞くことができるようになります。

AIを便利な道具へと変えるには、適切な距離感が必要です。

まずは情報を引き出すだけの道具として使い込み、信頼関係を築いてから「書き込み」の許可を与える。

この段階的な導入こそが、チームにAIを馴染ませるためのコツと言えます。

分析と修正の工程を明確に分離する

良いプログラムを書くためには、まず「現状を正しく把握する」ことが欠かせません。分析と修正を同時並行で行うと、場当たり的な対応になりやすく、根本的な解決から遠のいてしまうことがあります。

read-onlyモードを使うことで、強制的に「今は調べる時間」という区切りを作ることができます。

AIに現状の課題をリストアップさせ、人間が設計方針を固め、その上で修正に取りかかる。

このメリハリが、コードの品質を高く保つことに繋がります。

分析フェーズ：read-onlyモードで構造や課題を特定。
設計フェーズ：AIの意見を参考に人間が方針を決定。
修正フェーズ：通常モードまたは手動で変更を適用。

このように工程を分けることで、作業の抜け漏れを防ぎ、納得感のあるリファクタリングが可能になります。

AIのスピード感に流されず、自分のペースで開発をコントロールしましょう。

read-onlyモードで分析を開始する手順

Claude Codeで読み取り専用モードを使うのは、拍子抜けするほど簡単です。ターミナルでいつものコマンドに、魔法の合言葉を一つ添えるだけで、安全な探索の旅が始まります。

本章では、read-onlyモードを起動するための具体的なコマンドと、解析対象を賢く絞り込むための小技を紹介します。画面の向こう側のAIに、今日は読むだけだと正しく伝える方法をマスターしましょう。設定一つで、AIはあなたの忠実な観察者へと姿を変えます。

–read-onlyフラグを指定して起動する

Claude Codeを起動するときに、末尾に --read-only（または短縮形の -r）を付け加えます。これが読み取り専用モードのスイッチです。

claude --read-only

これだけで、Claude Codeは「ファイルの編集権限を持たないモード」で立ち上がります。

起動時に表示されるメッセージを確認し、書き込みが禁止されていることを確かめてください。

一度このモードで起動してしまえば、セッションが終わるまでAIがファイルを書き換えることはありません。

コマンドを一つ覚えるだけで、あなたは強力な解析ツールを、一切のリスクなしに手に入れることができるのです。

特定のディレクトリのみを解析対象に含める

プロジェクト全体を解析させると、AIが迷子になったり、関係のない古いファイルまで読み込んだりすることがあります。そんなときは、解析の「視界」を限定してあげましょう。

指示を出す際に、「まずは src/api ディレクトリの下だけを見て」と伝えることで、AIは狭い範囲の中でより深い洞察を返してくれるようになります。

src/ 配下に限定する
docs/ を優先的に読む
テストコードを除外する
特定の拡張子だけを追う

このように情報の入り口を人間がコントロールすることで、AIの回答はより具体的で、役に立つものに変わります。

広い海を闇雲に泳がせるのではなく、プールのコースロープを引いてあげるイメージで指示を出してみてください。

1回限りの解析用プロンプトを直接渡す

わざわざ対話モードに入るほどではないけれど、サッと解析してほしいと思ったことはありませんか？

そんなときは、コマンドラインから直接質問を投げるのが早くて便利です。

claude --read-only -p "このプロジェクトのディレクトリ構造を要約して"

このように -p フラグを使えば、AIは指示を遂行したあと、すぐに終了します。

これなら、ターミナルの履歴を汚さずに、知りたい情報だけをスマートに抜き出すことができます。

ちょっとした疑問が浮かんだときに、エディタを離れずにAIに尋ねる。

この手軽さが、開発のテンポを崩さずに知見を深める秘訣です。

以下の表に、よく使うコマンドの組み合わせをまとめました。

コマンド	用途	効果
`claude -r`	じっくり対話して解析	事故なしで徹底調査
`claude -r -p "..."`	ピンポイントな質問	最速で答えを得る
`claude -r --cwd ...`	別ディレクトリの調査	複数プロジェクトを横断

既存コードを安全かつ深く読み解くコツ

読み取り専用モードを最大限に活かすには、AIへの問いかけ方が重要になります。単に読んでと頼むのではなく、目的を持って情報を引き出すことで、コードの真の姿が浮き彫りになります。

本章では、複雑に入り組んだコードを解きほぐすためのアプローチを紹介します。AIを透視メガネのように使い、ソースコードの裏側に隠された意図を読み解いていきましょう。人間だけでは見落としがちな小さな矛盾や、改善のヒントを効率よくあぶり出します。

アーキテクチャの概要を要約させる

まずは木を見る前に、森全体を眺めましょう。Claude Codeに「このプロジェクトの設計思想と、主要なデータの流れを説明して」と依頼してみてください。

AIは複数のファイルを横断的に読み込み、フォルダ構成やクラスの継承関係から、そのプロジェクトがどのようなルールで動いているのかを抽出します。

人間が手動でフォルダをクリックして回るよりも、はるかに正確で整理された概略図を、テキストで示してくれます。

「あ、このプロジェクトはクリーンアーキテクチャを意識しているんだな」といった、設計者の意図に気づくことができれば、その後のコーディングはぐっと楽になります。

最初に全体の見取り図を手に入れることが、迷子にならないための最良の策です。

複雑な関数の処理フローを解説させる

数百行ある関数が、結局何を計算しているのかわからず困ったことはありませんか？

そんな難解なロジックに出会ったら、ステップ別に解説させてみましょう。

AIは一つひとつの命令の意味を噛み砕き、「ここでは入力をチェックしています」「ここではキャッシュを探しています」といった具合に、実況中継のように説明してくれます。

コードを読むのが苦手な方でも、日本語での解説を併読することで、ロジックの正体が手に取るようにわかるはずです。

さらに、「この処理の中で、特にエラーが起きやすそうな場所はどこ？」といった質問をぶつけてみるのも面白いでしょう。

AIは例外処理の漏れや、境界値の判断ミスなど、人間が見落としがちな弱点を鋭く指摘してくれます。

未使用のコードや重複しているロジックを特定する

長年開発が続いているプロジェクトには、誰からも呼ばれていないコードや、似たような処理が複数の場所に書かれたコピペコードが溜まりがちです。

read-onlyモードで、「プロジェクト全体で重複しているロジックをリストアップして」と指示を出してみてください。

AIはファイル間の類似性をチェックし、「この関数とあの関数はほぼ同じなので、共通化できそうです」といった提案をしてくれます。

未使用の関数
重複したバリデーション
似たようなCSSクラス
共通化できるユーティリティ

これらを特定するだけでも、コードの掃除に向けた大きな一歩になります。

書き換える前に「どこが汚れているか」を正確に把握することで、無駄のないリファクタリング計画が立てられます。

ファイル間をまたぐ呼び出し関係をマッピングする

ある変数を変えたとき、どこまで影響が及ぶのか。これを追いかけるのは、エンジニアにとって最も神経を使う作業の一つです。

「この userProfile という変数が、どこで使われていて、どこで上書きされているか全て追跡して」

このように指示を出せば、AIはプロジェクト全体をスキャンし、依存関係のリストを作り上げます。

呼び出し元ファイル	処理の内容	影響度
AuthService.ts	ログイン時の初期化	高
ProfilePage.tsx	表示用の読み込み	中
Logger.ts	デバッグ用の出力	低

このように整理された情報があれば、変更に伴う事故を未然に防ぐことができます。

複雑な繋がりを可視化することは、AIが得意とする点と点を結ぶ作業の真骨頂です。

自分の記憶力に頼らず、AIの網羅的な探索力を賢く利用しましょう。

read-onlyモードでできることと制限事項の境界線

読み取り専用といっても、具体的にどこまでが許されて、どこからが禁止されているのかを知っておかないと、作業中に戸惑ってしまいます。

本章では、このモードのできることとできないことの線引きを明確にします。AIが提供できるサポートの範囲を正しく理解し、スムーズなワークフローを構築しましょう。制限を知ることで、逆にAIの能力を最大限に引き出す使いかたが見えてきます。

ファイルの閲覧と高度な要約は自由に行える

read-onlyモードであっても、プロジェクト内のファイルを「読む」ことに関しては一切の制限がありません。むしろ、分析に特化している分、より深い洞察を得るための機能が開放されているとも言えます。

ファイルを開き、中身を比較し、矛盾点を探し、要約する。

こうした「考える作業」は通常モードと同じ精度で実行可能です。

また、AIが内部で持っている知識と、目の前のコードを照らし合わせることも自由です。

「この書き方は、セキュリティ的に安全？」といった相談には、喜んで応じてくれます。

情報のインプットに関しては、何一つ遠慮する必要はありません。

コードの書き換えや新規保存はすべて拒否される

一方で、一文字たりともファイルに「書き込む」ことはできません。これがこのモードの絶対的なルールです。

たとえAIが「完璧な修正案を見つけました！保存しますか？」と聞いてきても、システム側がそれをブロックします。

「ファイルを保存できませんでした（read-only mode）」といったエラーが出るのを見れば、逆に安心することでしょう。

AIが提案したコードを、やっぱり保存したくなったらどうすればいいのでしょうか？

その場合は、AIが画面に表示した修正案をコピーして、自分でエディタに貼り付けるか、一度Claude Codeを終了して通常モードで起動し直す必要があります。

この一手間こそが、無意識の事故を防ぐための防波堤となります。

手間を惜しまず、安全を確認してから実行に移しましょう。

シェルコマンドの実行提案には慎重に対応する

Claude Codeは、プログラムの実行やテストのためにターミナルでコマンドを叩こうとすることがあります。read-onlyモード中、これらの書き込みを伴う可能性のあるコマンドは、通常より厳格に制限されます。

特に、ファイルを削除する rm コマンドや、中身を書き換える sed などのコマンドは実行できません。

一方で、内容を表示するだけの ls や cat、grep といったコマンドは許可されることが多いです。

許可される例：ファイル一覧の表示、検索。
制限される例：ファイルの作成、削除、権限変更。

AIがコマンドの実行を求めてきたときは、画面に表示されるコマンドの内容をよく読んでください。

中身を確認するだけの操作であれば許可して問題ありませんが、少しでも不安を感じるなら拒否を選択しましょう。

常にあなたが主導権を握り、AIの行動を監督することが大切です。

分析精度を高めるプロンプトの出し方

AIを優れた解析官にするためには、情報の与え方に工夫が必要です。read-onlyモードという制限下で、いかに正確な答えを引き出すか。プロの開発者が実践しているテクニックを紹介します。

本章では、AIにプロジェクトの背景を伝え、的外れな回答を防ぐためのコツをまとめました。指示の質を上げることで、分析の密度は劇的に向上します。AIとの対話をより生産的なものにするための具体的な言い回しを確認していきましょう。

プロジェクトの背景情報を最初に共有しておく

AIはコードを読めますが、それがなぜ作られたのかまでは知りません。作業を始める前に、プロジェクトの前提知識をさらっと教えてあげましょう。

「これはECサイトの決済システムで、正確さが最も重視されます」

「これは個人の趣味のプロジェクトで、実行速度を優先しています」

このような一言があるだけで、AIのアドバイスの質はガラリと変わります。

状況に応じた忖度をAIにさせることで、あなたの価値観に合った分析結果が得られるようになります。

修正案ではなく課題のリストアップを求める

「ここを直して」と頼むと、AIは無理に修正コードを作ろうとして、モードの制約とぶつかりやすくなります。

代わりに、「ここに潜んでいる潜在的なバグを箇条書きで教えて」と頼むのがコツです。

修正をゴールにするのではなく、発見をゴールにするのです。

AIにバグの正体や改善のヒントを言葉で説明させることで、あなたは修正の理由を深く理解できます。

ロジックを理解しないままAIの修正案を受け入れるのは、将来の技術負債を抱えるようなものです。

なぜダメなのか、どうあるべきなのかを言葉で語らせる。

これが、AIを使いこなしながら自分の実力を高めるための最強のプロンプト術です。

読みやすさを重視した階層的な出力を指示する

AIの回答が長文の壁のようになると、読むのが疲れてしまいませんか？

そんなときは、「分析結果は、H2見出しと箇条書きを使って、構造的に出力して」と指示を加えましょう。

情報を階層化させることで、重要なポイントが一目で把握できるようになります。

また、「結論を最初に、その後に詳細な理由を添えて」と注文をつけるのも効果的です。

解析レポートの指示見本

Plaintext

以下の形式で分析してください。
1. 全体的なロジックの要約（3行以内）
2. 懸念されるバグや脆弱性のリスト
3. パフォーマンス改善の提案
4. 修正に必要なファイルの一覧

このように型を指定することで、AIの知能を整理されたレポートとして受け取ることができます。

読みやすいアウトプットは、あなたの意思決定を劇的に速めてくれるはずです。

APIコストを抑えて大規模プロジェクトを効率よく分析する方法

大規模なコードベースをAIに読ませると、APIの利用料金が気になりますよね。賢く節約しながら、爆速で解析を回すためのテクニックを伝授します。

本章では、無駄なスキャンを防ぐ設定と、AIの記憶を効率的に管理する方法を解説します。お財布にも優しい運用術を身につけて、心置きなく大規模解析に挑戦しましょう。コスト意識を持つことが、ツールを常用するための第一歩です。

.claudeignoreで不要なファイルをスキャンから隠す

Claude Codeがインデックスを作成する際、中身を読まなくていい巨大なディレクトリは徹底的に隠してしまいましょう。設定ファイルは、あなたの資産を守る盾になります。

例えば、node_modules やビルド後の dist フォルダ、巨大な画像アセットなどは、AIが読んでも一利もありません。

これらをスキャン対象から外すだけで、起動速度は上がり、API代は激減します。

インストール済みのライブラリ
自動生成されたキャッシュ
巨大なログファイル
画像、動画、音声データ

これらを「見せない」ことが、AIの思考をシャープに保つことにも繋がります。

情報のダイエットは、AI活用の基本中の基本です。

キャッシュ機能を有効にして再スキャンを最小限にする

AnthropicのAPIには、一度読み込んだ情報を記憶しておき、2回目以降の料金を安くするプロンプトキャッシュという仕組みがあります。Claude Codeはこの機能を賢く利用するように設計されています。

一度大規模なスキャンを行った後は、同じセッション内で質問を続けることで、このキャッシュの恩恵を最大限に受けられます。

逆に、何度もツールを起動し直すと、そのたびにフル料金がかかってしまう可能性があります。

「まとめて質問し、まとめて解析する」

このリズムを意識するだけで、月の請求額は大きく変わってきます。

賢いエンジニアは、ツールだけでなく、その裏側のコストの仕組みもコントロールします。

トークン消費を抑える引き算の指示を心がける

「このプロジェクトのすべてを教えて」という指示を出したことはありませんか？

それは、最もトークンを浪費する悪い指示の代表例です。情報は多ければ良いというものではありません。

「この関数に関連するファイルだけを読んで」

「最近更新された3つのファイルだけを比較して」

このように、AIが読むべき文字数を引き算してあげる意識を持ちましょう。

指示が具体的であればあるほど、AIがスキャンする範囲は狭まり、回答は正確になり、料金は安くなります。

最小限のデータで最大限の知見を得る。このストイックな姿勢が大切です。

チームでのコードレビューにread-onlyモードを導入するメリット

個人での利用だけでなく、チーム開発のプロセスにread-onlyモードを組み込むことで、レビューの質を底上げすることが可能です。

本章では、チームメンバーが書いたコードを客観的に評価し、議論を深めるための活用シーンを提案します。AIを公平な第三者として招き入れることで、より健全な開発文化を築いていきましょう。人間同士の感情的な対立を防ぐ効果も期待できます。

複雑なプルリクエストの概要を整理させる

同僚から送られてきた数百行に及ぶプルリクエストを見て、圧倒されたことはありませんか？

そんなときは、read-onlyモードのClaude Codeに「この変更内容を、要約して説明して」と頼んでみましょう。

AIは差分を読み取り、どのような意図でどこが変更されたのかを、中立的な視点でまとめてくれます。

「この変更はAというバグを直していますが、Bという処理に影響を与えている可能性があります」

といった指摘があれば、レビューの質は劇的に上がります。

人間が気づきにくい副作用をAIに先回りして探させる。

この共同作業により、不具合が本番環境に紛れ込むリスクを最小限に抑えることができます。

チーム独自の規約との不一致を探す

プロジェクトごとに決まっている命名規則やファイルの配置ルール。これを人間が目視でチェックするのは、非常に骨の折れる作業です。

「私たちのチームでは、非同期関数には必ず Async という接尾辞を付けます。このルールに違反している場所を探して」

read-onlyモードなら、安全に全ファイルをパトロールさせることができます。

キャメルケースの統一
コメントの必須化
ファイルの役割分担
循環参照の禁止

こうした細かいけれど大事なルールの監視役をAIに任せてしまいましょう。

機械的なチェックはAIに任せ、人間はロジックの美しさやユーザー体験の議論に集中すべきです。

開発者間の認識のズレを埋める壁打ちに使う

レビュー中のコメント欄で議論が平行線になったとき、AIに第三者の意見を求めてみるのはいかがでしょうか。

「Aさんは効率を重視してこう書きました。Bさんは可読性を重視してこう提案しています。両方のメリットを活かした第三の案はある？」

read-onlyモードなら、既存のコードを壊すことなく、安全に代替案を検討できます。

AIが出した客観的な分析結果をテーブルに乗せることで、感情的な対立を避け、建設的な議論ができるようになります。

AIは事実に基づいた選択肢を提示するだけです。

そのドライな分析力を、チームのコミュニケーションを円滑にするために活用しましょう。

トラブルを未然に防ぐチェックポイント

read-onlyモードは非常に安全ですが、それでも最低限の注意は必要です。運用を始める前に、自分の環境を再確認するためのポイントをまとめました。

本章では、パーミッションの設定や機密情報の取り扱いなど、エンジニアとして守っておきたいガードレールを確認します。足元を固めて、安心してAIの力を借りましょう。自分自身のミスで大切な情報が漏れないよう、最後の仕上げを行います。

パーミッション設定が正しく反映されているか確認する

非常に稀ですが、OS側のファイル権限の設定によっては、read-onlyモードでも予期せぬ挙動をすることがあります。

基本的にはClaude Codeが優秀にガードしてくれますが、自分でも ls -l コマンドなどでファイルの権限を確認する癖をつけておきましょう。

特に、AIに実行権限を与えているスクリプトなどがある場合は、注意が必要です。

ツールが守ってくれるから大丈夫と過信せず、最後の一線は自分の目で確かめる。

この慎重さが、大規模なシステムを守るプロフェッショナルには求められます。

万が一の事態を想定して、バックアップやGitの最新化は常に済ませておきましょう。

隠しファイルや環境変数が漏洩していないか注意する

read-onlyモードは書き込みは禁止しますが、読み込みは許可されています。つまり、設定を誤ると、AIがあなたの秘密鍵やパスワードが含まれる .env ファイルを読み込んでしまう可能性があるのです。

AIに送られたデータはモデルの学習には使われませんが、不要な個人情報を外部に送信するのは避けるべきです。

.claudeignore に、機密情報が含まれるファイル名を必ず登録しておきましょう。

ファイル名	除外の理由	重要度
.env	パスワード、APIキーが含まれる	最高
*.pem	秘密鍵が含まれる	最高
*.log	ユーザーの個人情報が含まれる可能性	高
.git/	内部のハッシュや履歴データ	中