AIを活用した開発に興味があるけれど、作業フォルダの指定やコンテキストの制御と言われると難しそうで難航していませんか。特にcodexのフォルダ指定やパス設定、セキュリティ周りの機能は、初心者にとって最初の大きな壁になりがちかなと思います。この記事では、AIツールを安全に使いこなすためのフォルダ指定の基本から、CursorやRoo Codeといった主要エディタでの具体的な設定手順までを分かりやすく解説します。読み終える頃には、自分のローカル環境を汚さずに、安心してAIエージェントと開発を進められるようになるはずですので、ぜひ参考にしてみてくださいね。
- WordPressから最新AIツールまでにおけるフォルダ指定の意味と違い
- OpenAI Codexをローカル環境やCLIで動かすための基本コマンド
- CursorやRoo CodeでAIに正しくフォルダを参照させる実践テクニック
- 機密情報の漏洩を防ぐためのIgnore（除外）設定とセキュリティ対策
codexのフォルダ指定で迷わないための基本
AIエージェントに自律的な作業を任せるためには、まず「どのフォルダで作業してもらうか」という境界線をはっきりと決めておく必要があります。ここでは、環境ごとの初期設定やフォルダ指定の基本について、初心者の方に向けて丁寧にひも解いていきますね。
wordpressでのインストール先ディレクトリの設定
検索エンジンで「Codex」と調べると、AIの話だけではなく、古いWebシステムであるWordPressの公式マニュアル（WordPress Codex）に関する情報もヒットすることがあります。このレガシーな文脈におけるフォルダ指定とは、Webサーバー上にWordPressのパッケージをインストールする際の「wp」などのディレクトリ名を指しています。現代のAI開発ツールの設定とは全くの別物ですので、まずはこの2つの意味が混ざらないように整理しておくことが大切かなと思います。
ちなみに、WordPressを動かすためのサーバー環境や設置方法について、詳しく知りたいという方もいるかもしれません。PHPのバージョンやデータベースの構築など、Webシステムとしての土台を整える手順については、こちらの記事（WordPressのおすすめサーバーと初期設定の完全ガイド）で詳しく解説されています。AIツールを導入する前に、ご自身のWebサイトのインフラ環境を一度見直しておくと、後々のデータ連携などもスムーズに進むのでおすすめですよ。
歴史的な背景として、WordPress Codexは長年にわたり開発者の聖典として機能してきましたが、現在は新しいドキュメントサイトへの移行が進んでいます。一方で、私たちが今まさに活用しようとしているAI分野の「Codex」は、プログラムコードを生成・解釈するための大規模言語モデル（LLM）や、それを組み込んだエージェントツールを指します。フォルダ指定という同じ言葉を使っていても、一方は「Webサーバー内の公開ディレクトリの階層構造」であり、もう一方は「AIが読み書きを許されたローカルPC内の開発ワークスペース」という決定的な違いがあります。この前提をしっかりと頭に入れておくことで、ネット検索時に不要な情報に惑わされるリスクをぐっと減らすことができますね。
openaiのデスクトップアプリでの初期設定
デスクトップ版のOpenAI Codexや、それを応用した最先端のAIエージェントアプリをローカル環境で起動する際は、最初にAIが自由にファイルを読み書きして良いフォルダ（ワークスペース）の絶対パスを指定することになります。アプリを立ち上げてアカウント認証を済ませたら、セットアップ画面の指示に従って対象となるローカルフォルダやGitリポジトリを選択しましょう。ここで指定したフォルダが、AIエージェントにとっての「活動拠点」になります。
初期設定時によくある失敗として、PCの「デスクトップ」や「ダウンロード」といった、ノイズとなるファイルが大量に存在する親フォルダをそのまま指定してしまうケースが挙げられます。これをやってしまうと、AIが指示文（プロンプト）を処理する際に、関係のない不要なファイルまで巻き込んでスキャンしてしまい、動作が著しく重くなったり、トークンと呼ばれるAIの消費コストが無駄に跳ね上がったりする原因になります。そのため、初期設定を行う前には、あらかじめ「ai-project」や「codex-workspace」といった専用の空フォルダを任意の場所に作成しておき、そこをピンポイントでアプリ側に登録するのがスマートな運用方法かなと思います。
また、アプリによっては、初回起動時に特定の構成ファイルやキャッシュデータを指定フォルダ内に自動生成するものもあります。一度拠点を決めたら、原則としてそのフォルダの場所（パス）をむやみに変更しないことが、システムを安定して飼い慣らすための秘訣です。万が一、パスを変更したくなった場合は、アプリ内の設定メニューからワークスペースの再指定を行うか、設定ファイルを直接編集して参照先を書き換える必要があるため、最初のフォルダ選びは慎重に行うのが吉ですね。
cli環境で使うカレントディレクトリの操作コマンド
黒い画面（ターミナルやコマンドプロンプト）で動かすCLI版の場合、AIが今どのフォルダを見ているかを明示的に操作する必要があります。基本となるシェルコマンドをいくつか覚えておくとスムーズですよ。
よく使う基本コマンド一覧
cd フォルダ名：操作対象とするディレクトリを切り替えるls（Mac/Linux）またはdir（Windows）：現在のフォルダ内にあるファイル一覧を表示するmkdir フォルダ名：新しい作業用フォルダを作成する
また、起動時に --cd フォルダパス というオプションを付けて引数を指定すれば、最初から特定のディレクトリを作業空間として固定してタスクを開始させることも可能です。CLI環境での操作に慣れていない方は、まず自分が「今どこにいるのか」を見失いがちですが、pwd コマンド（Print Working Directory）を叩けば、現在地を絶対パスでいつでも確認できるので安心してくださいね。
AIエージェントをCLIから呼び出す際、カレントディレクトリ（現在作業しているフォルダ）の設定が間違っていると、「指定されたファイルが見つかりません」といったエラーを連発することになります。例えば、デスクトップにある「project」フォルダの中のコードをAIに修正させたい場合は、まずターミナルを起動した直後に cd ~/Desktop/project と入力して、正しい場所に移動してからAIの起動コマンドを実行する必要があります。この手順を飛ばしてホームディレクトリのままAIを動かしてしまうと、AIはプロジェクトの全体像を把握できず、的外れなコードを生成してしまう可能性が高くなります。パスの指定方法には、現在地を基準にする「相対パス」と、システムの最上階から指定する「絶対パス」の2種類がありますが、確実性を期すなら引数オプションに絶対パスを直接放り込むのが一番確実で迷わない方法かなと思います。
空のフォルダが量産されてしまう原因と対策
AIツールを使い始めたばかりの頃、UIの導線に迷って「新規作成」を何度もクリックしてしまい、パソコンの中に中身が空っぽの類似フォルダが大量にできてしまった、というトラブルがよく起こります。これを防ぐためには、既存のプロジェクトを再開する際に必ず「既存のフォルダを使用する」という選択肢を明示的に選ぶことが大切です。作業の原点（ホームディレクトリ）を恒久的に固定することで、AIも開発者迷子にならずに済みますよ。
なぜこのような現象が起きるかというと、多くのAI開発支援ツールは、ユーザーが明確な指示を与えずに「新しくチャットを始める」や「新しいタスクを作る」を選択した際、裏側で自動的にテンポラリ（一時的）な作業スペースを確保しようとする仕様になっているからなんです。これが積み重なると、気づいた時には「untitled-folder1」「untitled-folder2」といった、幽霊のようなフォルダがPC内に溢れかえることになります。このカオスな状況を未然に防ぐための最大の対策は、ツールの起動ショートカットやデフォルト設定を見直し、常に特定のメインワークスペースが自動で開くように固定（永続化）しておくことです。
一見不要に見える起動用の空フォルダですが、システムチェックの足場として機能している場合があります。不用意に削除すると次回起動時にエラーの原因になることもあるので注意してくださいね。
もし、どうしても不要になった空フォルダを大掃除したい場合は、手動で1つずつ消していくのも良いですが、CLIの強力なコマンドを使う方法もあります。例えばMacやLinux環境であれば、ターミナルで find . -type d -empty -delete というコマンドを実行することで、現在地より下にある空のディレクトリだけを安全に一括削除することができます。ただし、ツールが現在進行形でバックグラウンドで使用している一時フォルダまで巻き添えにしてしまうと、アプリがクラッシュする原因にもなり得ます。クリーンアップを実行する際は、関連するAIツールやエディタを一度完全に終了させてから行うのが、トラブルを避けるための大原則かなと思います。
変更履歴が消えるリポジトリ削除のリスクと回避策
AIのテスト用に作った環境だからといって、フォルダをFinderやエクスプローラーから直接ゴミ箱にポイと捨ててしまうのはちょっと待ってください。そのフォルダの内部には、普段は見えない .git という隠しディレクトリが存在している可能性が高いです。これを知らずにフォルダごと削除すると、それまで積み重ねてきた大切なGitの変更履歴やブランチ情報がすべて完全に消去されてしまうという重大なリスクがあります。クリーンアップする前には、必ずターミナル等で未コミットの重要な変更が残っていないか確認する癖をつけましょう。
AIエージェントにコードの生成や修正を依頼すると、AIは私たちが想像する以上のハイスピードで何十個ものファイルを書き換えていきます。そのため、変更前の正常だった状態にいつでも巻き戻せる（ロールバックできる）ように、作業フォルダをGitリポジトリとして初期化（git init）しておくのはほぼ必須のエンジニアリングマナーと言えます。しかし、実験が終わったから、あるいはAIが生成したコードがバグだらけで気に入らないからといって、フォルダごと物理削除してしまうと、過去の成功していたバージョンのログまで道連れにしてしまいます。一度失われた .git 内のオブジェクトデータを復元するのは、専門家でも極めて困難です。
この致命的なミスを賢く回避するためには、フォルダそのものを消すのではなく、Gitの機能をフル活用して「過去の状態にチェックアウトする」か、あるいは git clean -fd などのコマンドを使って、AIが勝手に作り出した未追跡のファイル群だけをピンポイントで消去するアプローチを学びましょう。どうしてもフォルダ構造自体をリセットしたい場合は、事前に git remote -v でリモートリポジトリ（GitHubなど）に最新の状態がプッシュされているかを指差し確認するか、フォルダの複製（バックアップ）を一時的にデスクトップ等に退避させてから作業に臨むのが、傷を浅くするための鉄則かなと思います。
安定稼働に必要なシステム要件とnodeのバージョン
ローカル環境でAIエージェントを安定して動かすためには、パソコンのスペックや環境の準備も欠かせません。あくまで一般的な目安ですが、以下のシステム要件を確認しておくと安心かなと思います。
| 項目 | 必要・推奨環境 |
|---|---|
| RAM（メモリ） | 物理メモリ4GB以上必須（快適な開発には8GB以上、複数ツール併用なら16GB以上を強く推奨） |
| Node.js バージョン | バージョン22以降（長期サポートであるLTS版の使用を強く推奨） |
| ディスク空き容量 | SSD 10GB以上の空きスペース（AIモデルのキャッシュや依存パッケージ用） |
| OS環境 | Windows 11（WSL2推奨）、macOS Ventura以降、またはLinux |
また、認証用のAPIキーが消えてしまわないよう、シェルの設定ファイル（.zshrc や .bashrc）に export OPENAI_API_KEY="あなたのキー" のように記述して、環境変数として恒久化しておくのがおすすめスタイルです。
特に見落としがちなのが「Node.js」のバージョン管理です。多くのAI開発ツールや拡張機能は、バックグラウンドでNode.jsを動かしてローカルファイルの制御やトークンの計算を行っています。古いバージョン（例：v18やv20など）のまま放置していると、最新の非同期ストリーミングAPIや暗号化モジュールが正常に動作せず、フォルダの指定自体は合っているのに「原因不明の通信エラー」や「モジュールが見つかりません」といった理不尽なバグに泣かされることになります。環境をクリーンに保つためにも、fnm や nvm といったバージョン管理ツールを導入し、プロジェクトごとに最適なNode環境を瞬時に切り替えられるように土台を整えておくことが、巡り巡ってトラブルのないAI開発ライフを送るための近道になりますよ。
設定ファイルによるプログランプトの日本語化
AIの基本動作や出力の癖を一括で制御したいときは、ホームディレクトリに ~/.codex/AGENTS.md というグローバル指示ファイルを配置するのが便利です。このファイルの中に「日本語で回答してください。」といった明確なルールを一行書いておくだけで、すべてのトークルームにおいて出力言語を一貫して日本語に保つことができるようになります。英語の回答に翻訳ツールを通す手間が省けるので、最初に設定しておきたいポイントですね。
この設定ファイルは、一般的に「システムプロンプト」や「カスタムインストラクション」と呼ばれる領域をローカル側から強制的に上書きするための仕組みです。AIエージェントは非常に柔軟な反面、コンテキストが初期化されると、デフォルトの言語設定（多くは英語）に先祖返りしてしまう性質を持っています。毎回新しいチャットを立ち上げるたびに「日本語で話して」と打ち込むのは、地味にストレスが溜まりますよね。そこで、指定のフォルダ階層に共通のルールブックを置いておくことで、AIは起動時に必ずそのファイルを最優先で読み込み、自分のアイデンティティとして脳内に刷り込んでくれるわけです。
さらに踏み込んだ応用テクニックとして、単に言語を日本語にするだけでなく、「コードの説明は最小限にし、リファクタリング案は箇条書きで3つ提示すること」「シニアエンジニアのような口調でレビューして」といった、自分の好みの開発スタイルや成果物のフォーマットをこの AGENTS.md 内に構造化して書き込んでおくことも可能です。マークダウン形式（Markdown）がサポートされているため、見出しや箇条書きを使って綺麗に指示を整理しておけば、AIの理解度も劇的に向上します。自分専用にパーソナライズされた、最高に頼れるAIパートナーをフォルダ1つで生み出せると思えば、ワクワクしてきませんか。
最新aiツールにおけるcodexのフォルダ指定と活用
ここからは、OpenAIの技術をルーツに持つCursorやRoo Code、GitHub Copilotといった人気の最新ツールにおいて、どのようにフォルダを指定し、コンテキスト（文脈）を制御していくのかを解説します。
cursorでフォルダを丸ごと参照させる設定
大人気のエディタ「Cursor」には、チャット欄で @ と入力するだけで、ファイルやフォルダを簡単にAIへ引き渡せる「Context Mentions」という超強力な機能が備わっています。@Folders を使って任意のディレクトリをフォルダごと指定すれば、その構造と内部ファイルの中身をAIが一括して解析してくれます。また、設定のBeta機能にある「自動フォルダ読み込みオプション」を有効にしておくと、対話中にフォルダのパスが話題に上った際、AIが自動的にその内容を読み込んでコンテキストに格納してくれるのでとても便利ですよ。
この機能の真骨頂は、大規模なソースコードの全体像をAIに瞬時に把握させられる点にあります。例えば、「src/features フォルダの設計思想を踏襲して、新しい機能を追加して」という風に @features とフォルダを指定して指示を出すだけで、AIはそのフォルダ内にある複数のファイルを網羅的に巡回し、命名規則やデザインパターン、エクスポートの手法を完璧に模倣したソースコードを仕立て上げてくれます。これにより、ファイル1つ1つをコピペしてAIに読み込ませていた時代とは比較にならないほどのスピード感が手に入ります。
ただし、強力すぎるがゆえの注意点として、あまりにも巨大なライブラリや、node_modules のような自動生成された依存関係フォルダまで丸ごと @ で参照させてしまうと、AIのメモリ（コンテキストウィンドウ）の限界値を超えてしまい、重要な情報が頭から溢れ出てしまう（ロストインザミドル現象）が発生することがあります。Cursorを賢く使いこなすためには、プロジェクトのルートフォルダをただ漫然と指定するのではなく、今から修正したいスコープ（範囲）に絞った中規模・小規模のサブフォルダを狙い撃ちでアタッチするのが、AIから最高精度の回答を引き出すための大人のテクニックかなと思います。
roo codeでのファイルメンションとエラー修正
VSCodeの拡張機能として動く「Roo Code」（旧Cline）でも、プロンプト内で @/src/components/Button.tsx のように明示的にメンションを付与することで、特定のファイルの実体を正確にAIに読み込ませることができます。さらに、未コミットの差分情報（@git-changes）や、エディタ上のProblemsパネルに表示されているリアルタイムなコンパイルエラー（@problems）をプロンプトに統合できるため、現在の不具合をピンポイントでAIに修正してもらう指示もすんなり出せちゃいます。
Roo Codeが特に優れているのは、開発者が手動でファイルを指定するだけでなく、AIエージェント自身が「目的を達成するために必要なファイルやフォルダを自分で探して自律的に読み込む」という高度な探索能力を備えている点です。例えば、「バグを直して」という大雑把な指示を投げるだけで、Roo Codeは grep コマンドのような探索処理をバックグラウンドで自走させ、エラーの原因になっていそうなフォルダ階層を突き止め、ピンポイントでそのコンテキストを自ら召喚します。この挙動は、まるで有能なジュニアエンジニアが隣でコードを調べてくれているかのような感覚を覚えるほどです。
もしAIがフォルダの読み込み段階でアクセス権限のエラーに遭遇したり、パスの解釈を間違えておかしな挙動を示した場合は、あわてずチャット画面のインターフェースから「実行の中断」ボタンを押し、プロンプトで @problems を付与し直して「今のエラー内容を考慮して、正しいフォルダパスでアプローチをやり直して」と優しく軌道修正してあげましょう。AIと人間の対話を通じて、ローカルフォルダ内のファイル構成を段階的に洗練させていくプロセスこそが、Roo Codeにおけるデバッグ作業の醍醐味であり、最も効率的な活用法と言えますね。
情報漏洩を防ぐignore設定とアクセス制御
AIにフォルダ全体を丸ごと参照させるのは開発スピードが爆発的に上がる一方で、秘密鍵やパスワード、環境変数ファイル（.env など）を誤って外部のAIサーバーへ転送してしまう深刻なリスクを孕んでいます。これらをシステム的にブロックするために、各ツールには特定のファイルへのアクセスを強制拒否する「Ignore（除外）設定」が用意されています。例えばCursorであれば、プロジェクトのルートに .cursorignore というファイルを配置し、見せたくないファイル名を記述することで、AIの視界から物理的に隠すことができます。
このIgnoreファイルによるアクセス制御は、現代のAI駆動開発におけるセキュリティの最前線です。記述の文法は、開発者にお馴染みの .gitignore とほぼ同じ（グロブパターン）なので、参入ハードルも非常に低いのが嬉しいポイントですね。設定を怠ったまま、企業の機密データや個人情報、あるいはAPIのマスターパスワードが含まれたフォルダを丸ごとAIのコンテキストに投入してしまうと、それらのデータがLLMのプロバイダー側に送信され、最悪の場合はモデルの再学習に利用されて他人の回答に混ざって露出してしまう、といった悪夢のようなセキュリティインシデントに繋がりかねません。
.cursorignore の記述例
.env
.key
*.pem
secrets.json
dist/
build/
チーム開発の際は、機密情報の共有漏れを防ぐためにも、この除外定義をあらかじめプロジェクト内で共通化しておくのが安全な選択ですね。
新しくAIプロジェクトを立ち上げる際は、コードを書き始める前に、まず何よりも先にこの除外設定ファイルをルートディレクトリに生成する癖をつけましょう。たった数行のテキストファイルを置いておくだけで、AIの不注意なファイル全スキャンから大切なアセットを完全に守り抜くことができるのですから、これほどコストパフォーマンスの高い防御策はありませんよね。自分だけでなく、チームメンバーやクライアントの信頼を裏切らないためにも、必須の防衛ラインとして徹底していきましょう。
安全な開発のための機密情報と環境変数の管理
GitHub Copilotなどのエージェントモード（AIが自律的にコマンドを実行するモード）では、AIが cat や grep といったシェルコマンドを裏で実行して、クライアント側の除外フィルターを迂回して秘密ファイルを読み出してしまう「エージェント・バイパス」のリスクが指摘されています。そのため、最も安全な運用方針は「除外設定に過度に依存せず、そもそも作業ディレクトリ内に本番用の機密データを平文のファイルとして放置しないこと」です。認証情報の管理には、ファイルではなくOS付属のセキュアなキーチェーンや環境変数管理ツールを活用しましょう。ファイルのパーミッション（権限）を chmod 600 .env に制限しておくのも実効性の高いアプローチです。
この問題をさらに専門的に掘り下げると、AIエージェントにターミナルの実行権限（Read/Write/Execute）を与えている場合、AIはプロンプトの指示を独自の解釈でパースするため、開発者が設定したUI上の「見せないフィルター」の裏をかくような動きを意図せず行うことがあります。たとえば、直接ファイルを開くことは禁止されていても、シェルスクリプトを自動生成してそれを実行させ、その出力結果経由で .env の中身をチャット欄に表示させてしまう、といった一種のインジェクション攻撃のような現象が、AIの「親切心（タスクを何としてでも遂行しようとする熱意）」によって引き起こされるケースがあるのです。
これを根本から防ぐためには、開発環境の設計そのものを「ゼロトラスト（何も信用しない）」の観点にシフトさせる必要があります。開発に必要なAPIキーは、ローカルのファイルに直接書き込むのではなく、環境の実行時（Runtime）にのみメモリ上に展開されるようにシステムを組むか、Dockerコンテナなどの隔離されたサンドボックス環境の中にAIの作業フォルダを閉じ込め、ホストOS側のリアルな秘密鍵へのアクセス経路を物理的に遮断するのが最も堅牢です。また、ローカルファイルにどうしても残さざるを得ない場合は、ファイル自体の権限を厳格に絞り込み、現在のログインユーザー以外（そしてAIツールが動かすサブプロセス以外）は容易に読み取れないようにガードを固めるのが、プロとしての一歩進んだリスクマネジメントかなと思います。
画面ロック時の自動操作におけるセキュリティと制限
最新のアップデートにより、マシンの「画面ロック状態」であっても、AIエージェントがバックグラウンドで自動的にデバッグやテストなどのタスクを続行できる機能が一部で実装されています。深夜の寝ている間に作業を進めてもらえるのは魅力的ですが、これは物理的なアクセス権をAIに委譲するようなもの。そのため、人間がキーボードやマウスに触れた瞬間に処理を即時中断して強制再ロックするなどの強固な防御機構が組み込まれています。とはいえ、ブラウザ上でクラウドの管理画面や決済プラットフォームにログインしたまま席を外すと、AIが意図しない操作をしてしまう可能性はゼロではありません。信頼しきれないツールに対して「常に許可」を設定するのは厳禁かなと思います。
この「無人オートメーション」とも言える機能は、開発生産性を極限まで高めてくれる一方で、物理セキュリティとデジタルセキュリティの境界線を曖昧にする諸刃の剣です。例えば、あなたがオフィスで席を立ち、PCを画面ロックしたとしても、バックグラウンドで動いているAIエージェントが「テストの実行のためにローカルサーバーを起動し、外部ポートを開放する」といった操作を自動で行ってしまった場合、社内ネットワークへの脆弱性をその瞬間だけ無自覚に作り出してしまうリスクがあります。また、AIが生成したコードの無限ループバグによって、無人のPCが過熱し、ハードウェアにダメージを与える物理的な危険性も考慮しなければなりません。
こうした不測の事態を避けるための運用の制限として、画面ロック時の自動操作を許可する場合は、事前に「実行可能なコマンドのホワイトリスト登録」を徹底することが推奨されます。ファイル削除コマンド（rm -rf）や、ネットワークの外部通信を伴うコマンド、パッケージの新規インストールなどは、人間が目の前で監視している時（インタラクティブモード）にしか実行できないようにツールの設定ファイル側で明示的に制限をかけておくべきです。利便性の誘惑に負けてAIにフリーハンドの万能権限を与えてしまうのではなく、超強力な自律型ロボットを檻の中で安全に働かせるような、スマートで節度ある付き合い方を心がけたいですね。
まとめとしてcodexのフォルダ指定で大切のポイント
AIネイティブな開発環境における「codex의 フォルダ指定」というタスクは、単なる初期ディレクトリの選択ではなく、AIエージェントに対して「見せてよい情報」と「実行できる権限」の境界線を引き、コントロールするための統合的なシステム設計そのものです。本番コードを汚さないための空の「入口フォルダ」の活用、.cursorignore などの除外ファイルの徹底、そして平文でのパスワード放置をなくすセキュリティ意識を持つことで、リスクを極小化しながらAIの圧倒的な開発生産性を安全に引き出すことができます。まずは安全なフォルダを1つ指定するところから、一歩を踏み出してみてくださいね。
最後に、ここまでの学びを整理し、明日からのAI開発をノーリスクで加速するための3つの黄金原則を振り返っておきましょう。
安全にAIと開発するための3大原則
- コンテキストの断捨離：不要な親フォルダは指定せず、プロジェクト単位で作業階層を明確に分ける。
- Ignoreの徹底配置：
.cursorignoreを親の顔より見るレベルで初期設定し、機密情報を物理的に隠蔽する。 - Gitによる保険：AIにフォルダを弄らせる前に必ずコミットし、いつでも「過去の平和な世界」に戻れるようにしておく。
AIは私たちの開発効率を10倍にも20倍にも高めてくれる最高の相棒ですが、それもすべては「正しいフォルダ管理と境界線の設定」という基本があってこそ成り立ちます。フォルダ
