個人開発でAIに触らせていいファイル・触らせないファイル

Published 2026年6月22日

Author AI Media Lab

Category ai-technology

AI開発では、何をAIに書かせるか、どのファイルを編集させるかの判断が重要です。ファイル境界を明確にする実務的なガイド。

個人開発でAIに触らせていいファイル・触らせないファイル

はじめに

Claude CodeなどのAIコーディングアシスタントの大きな利点は、コード生成の速度です。しかし「速度が出るから、全部AIに任せよう」という判断は、実は危険です。

重要な問いは「AIは何を書けるか」ではなく、**「どのファイルをAIに編集させて良いのか」**です。Claude Codeの基本ガイドでは安全なプロンプトを、AI開発時の危険性ではスコープ管理を、Git運用ルールでは変更の追跡方法を解説しました。

本記事では、その次のレイヤー——ファイル境界の定義——を詳しく解説します。

なぜファイル境界が重要なのか

AIの広範な変更

AIアシスタントは、複数ファイルを一度に変更できます。「このバグを直して」という指示に対して、関連する全モジュールを修正しようとするかもしれません。

ファイルの種類による被害の大きさ

全てのファイルが同じではありません。

修正されたら大問題になるファイル例：

.env
├─ API キー、データベース URL
└─ 漏洩 → 本番環境アクセス可能、サービス停止

migrations/
├─ スキーマ変更
└─ 誤削除 → データ損失、復旧困難

.github/workflows/
├─ CI/CD 設定
└─ 誤変更 → 自動デプロイ失敗、本番障害

package.json (dependencies)
├─ 依存関係のバージョン
└─ 誤変更 → 予期しないパッケージ更新、互換性エラー

これらのファイルが予期しない形で変更されたら、手作業での復旧は困難です。

人間の確認の限界

AIが変更を完了してから、全てのファイルを確認することは実際には困難です。git diff で数百行の差分を見ても、細部の誤りを見落とす可能性があります。

対策: 事前に「どのファイルは変更してよいか」を明確にして、AIがその境界を超えないようにする。

AIに触らせてよいファイル

以下のカテゴリのファイルは、一般的にAIに編集させても安全です：

機能実装ファイル

新しい機能を追加するときのコアロジック：

✅ src/features/user-profile.py
✅ src/components/UserCard.tsx
✅ src/api/endpoints/users.py

理由：新規実装なので、既存環境への影響が少なく、テストで確認しやすい。

小さいユーティリティ

単純で依存性が少ないモジュール：

✅ src/utils/date-formatter.ts
✅ src/helpers/string-utils.py
✅ src/lib/math-helpers.js

ローカルテストファイル

本番に含まれないテストコード：

✅ tests/unit/feature-test.py
✅ __tests__/component.test.tsx

ドキュメントと例

✅ docs/api-guide.md
✅ examples/sample-code.js
✅ README sections

事前確認してから触らせるファイル

以下のファイルは、AIに一度の変更を許可する前に、必ず人間が確認してください：

共有モジュール・共通ライブラリ

△ src/lib/database.ts
△ src/middleware/auth.ts
△ src/services/api-client.ts

理由：複数の場所から使われるので、変更の影響が広範。

設定ファイル

△ config/database.yml
△ settings.json
△ constants.py

理由：アプリケーション全体の動作に影響。変更に誤りがあると、全機能が停止する可能性。

パッケージメタデータ

△ package.json
△ requirements.txt
△ setup.py

理由：バージョン指定が誤ると、予期しないパッケージ更新が発生。

CI/CD設定

△ .github/workflows/deploy.yml
△ .gitlab-ci.yml
△ Jenkinsfile

理由：自動デプロイやテスト実行に直接影響。誤変更は本番障害につながる。

Docker設定

△ Dockerfile
△ docker-compose.yml

理由：環境セットアップを制御。誤りは開発環境と本番環境の不一致を招く。

原則として触らせないファイル

以下のカテゴリのファイルは、明示的な承認なしでAIに編集させないでください：

環境変数と認証情報

❌ .env
❌ .env.local
❌ .env.production
❌ secrets.json
❌ credentials.yaml
❌ .npmrc
❌ .aws/credentials

理由：漏洩時の被害が最大。APIキー、データベースパスワード、トークンなど。

マイグレーション

❌ migrations/
❌ db/schema.sql
❌ alembic/versions/

理由：データベーススキーマ変更は、データ損失や構造的な問題を引き起こす。

ロック・バージョン管理ファイル

❌ package-lock.json
❌ yarn.lock
❌ Pipfile.lock
❌ poetry.lock

理由：手動編集は依存関係の整合性を破壊。

セキュリティ・認証ロジック

❌ src/auth/authentication.ts
❌ src/security/password-hash.py
❌ src/middleware/jwt-validator.js

理由：セキュリティバグは、本番環境へのアクセス可能や個人情報漏洩につながる。

課金・支払いロジック

❌ src/billing/payment-processor.py
❌ src/payment/stripe-integration.ts

理由：誤りは金銭的なシステムを破壊。

デプロイメント定義

❌ deploy/
❌ .github/workflows/
❌ terraform/
❌ ansible/

理由：本番環境へのアクセスと自動デプロイを制御。誤変更は本番障害につながる。

ファイル境界をClaude Codeへ伝える指示例

危険な指示（ファイル境界不明確）

❌ 「このバグを全部直して」
❌ 「関連ファイルもいい感じに修正して」
❌ 「テストが通るように全部変更して」
❌ 「依存関係を解決して」

これらの指示では、AIが「どのファイルを変更すべきか」を自由に判断するため、禁止ファイルまで手をつける可能性が高いです。

より安全な指示

✅ 「編集してよいファイルは、以下のみです：
  - src/features/payment-retry.py
  - tests/test_payment_retry.py

他のファイルが必要な場合は、変更前に相談してください。」

✅ 「変更計画だけ出してください。
どのファイルをどう変更する予定か説明してください。

禁止ファイル：
  - .env, .env.production
  - config/
  - migrations/
  - .github/workflows/」

✅ 「以下の操作は禁止です。
  - package.json の dependencies 欄は変更しない
  - Dockerfile を変更しない
  - .env ファイルに何か追加しない

まず変更対象ファイルだけリストアップしてください。」

変更後に必ず確認するGitコマンド

AIが変更を完了したら、以下のコマンドで確認します：

# 変更されたファイルリスト（ファイル名のみ）
git diff --name-only

# ファイル別統計
git diff --stat

# 詳しく確認
git diff

# 特定ファイルだけ確認
git diff src/specific-file.py

確認チェックリスト

□ 禁止ファイル（.env, migrations/, workflows/ など）が変更されていない
□ 事前確認予定だったファイルだけが変更されているか
□ 予期しないファイル削除がないか
□ 設定ファイルに余計な変更がないか
□ セキュリティ関連ファイルが触られていないか

もし禁止ファイルが変更されていたら、git restore で戻します：

# 特定ファイルを戻す
git restore .env

# ステージ後なら --staged も使う
git restore --staged .env

個人開発でのおすすめ運用フロー

8ステップワークフロー

1. タスク定義
   └─ 「このバグを修正」など、目的を明確に

2. 編集OK ファイルリスト作成
   └─ 「src/features/X.py, tests/test_X.py のみ」

3. 編集禁止ファイルリスト作成
   └─ 「.env, migrations/, .github/ は絶対に触らない」

4. Claude Code に変更計画だけ出させる
   └─ 「ステップ2, 3のファイルリストを確認した上で、
      変更計画を出してください。実装はまだ。」

5. 計画を確認
   └─ 対象ファイルが OK リストのみか？
      禁止ファイルに変更がないか？

6. git diff でレビュー
   └─ 実装完了後、必ず --name-only で確認

7. テスト実行
   └─ 対象機能が動作するか

8. コミット
   └─ git commit で記録

まとめ

AI開発では、「AIに何をさせるか」と同じくらい、「AIに何をさせないか」を明確にすることが重要です。

ファイル境界を明確にすることで：

セキュリティを守る：認証情報や秘密情報が露出しない
誤削除を防ぐ：重要なデータやマイグレーションが破壊されない
本番環境を守る：デプロイメント設定やCI/CD定義が誤らない
依存関係を守る：パッケージバージョンが意図しない更新を受けない

Claude Codeの基本ガイド、委譲の危険性、Git運用ルールと合わせることで、個人開発から小規模チーム開発まで、安全で効率的なAI支援開発を実現できます。

AI の力を活かしながら、人間が制御を失わない——それが現代的な開発の形です。