AIコーディングの「事故」を減らす3つの設計術

AIコーディングツールでUIを作るたびに、配色や余白がぶれて手直しが発生する。あるいはClaude Codeに作業させたら、意図しないファイルまで触られてヒヤリとした——そういった「AIの暴走」に近い体験が、開発者・ビルダーのあいだで共通の悩みとして浮上しています。

要は「AIの賢さの問題」ではなく「AIに何を渡すか・どこまで触らせるかという設計の問題」ということ。3つのトピックに共通するのはこの一点です。Googleが仕様をオープンソース化した「DESIGN.md」も、Claude Codeの作業ゾーン分割も、スマホからのリモート操作も、すべて「AIに渡す文脈と権限を設計側でコントロールする」という発想から出発しています。

AIコーディングが「書ける人だけのもの」から「ビルダー全員の道具」になりつつある今、問題は生成精度よりも「安定して使い続けられるか」に移ってきています。

注目したいのは、GoogleがDESIGN.mdの草案仕様をオープンソースとして公開したタイミングです。CursorやClaude CodeといったAIコーディングエージェントは、プロジェクト直下に置かれた.mdファイルを「文脈」として自動的に読み込む仕組みを持っています。RULES.mdやSYSTEM.mdで挙動を制御するアプローチ自体は以前から存在しましたが（SOUL.mdに一行書くだけでAI秘書が完成するでも触れた通り）、今回Googleが「デザインの意図を渡すための専用フォーマット」として仕様化したことで、ツール横断で使える共通言語が生まれつつあります。既製ファイルがすでに72本公開されているという点も、「個人が一から書く手間」を大幅に下げるという意味で実用性が高い。

もうひとつの軸は「権限スコープの管理」です。AIエージェントに作業させるとき、文脈を増やせば増やすほど出力の精度は上がりますが、同時に「予期しない範囲に手が届く」リスクも比例して高まります。これはモデルの性能とは独立した問題で、どれだけ賢いモデルを使っても「触っていいフォルダ」と「捨てていい一時領域」を分けておかなければ、誤削除・誤上書きのリスクはゼロにはなりません。複数の実践者がこの「ゾーン分割」に独立してたどり着いているという事実は、現時点のAIエージェント運用における構造的な課題を示しています。

リモート操作についても同様で、スマホからClaude Codeのセッションを操作するニーズ自体は以前からありましたが、tailscaleとTermuxを組み合わせたSSH接続という形で具体的な構成が共有されてきたのは最近の話。Claude Codeの実用範囲が「ローカル一台」から「マルチデバイス」に広がりつつあることを示しています。

Q. DESIGN.mdはCursorとClaude Codeのどちらで使えますか？

どちらでも使えます。仕様上はツール非依存で設計されており、プロジェクトルートに.mdファイルとして置けば、プロジェクト内ファイルを参照するAIコーディングエージェントであれば基本的に読み込まれます。ただし「どこまで厳密に守られるか」はモデルとツールの実装に依存します。公式仕様ページには対応ツールのリストが随時更新されているため、使用前に確認するのが確実です。

Q. 「触っていいフォルダ」を分けただけで本当に事故は防げますか？

ゼロリスクにはなりません。ただし「どこまで触らせるか」を明示していない状態よりは、誤操作の発生頻度と影響範囲を絞れます。AIエージェントはフォルダ構造を文脈として読み取るため、ディレクトリ分離＋指示文での明示という二重のガードが現実的な対策です。加えて、本番環境は.gitignoreで除外する・Git管理下に置いて変更履歴を追えるようにするといった基本的な安全策との組み合わせが前提になります。

Q. DESIGN.mdの既製ファイルは無料で使えますか？

Googleのオープンソースリポジトリとして公開されているため、ライセンスの範囲内で無料で利用できます。72本の既製ファイルはコミュニティによる貢献も含まれており、今後も増える見込みです。ただし内容の正確性は各ファイルのメンテナーに依存するため、本番利用前に自分のプロジェクトの要件と照合して確認する手間は必要です。