駆動開発をしていると、どうしてもAIに任せっきりとなってしまいます。
Claude Codeは一つ一つの作業に関して確認をしてくれますが、それにはちゃんと？意味があります。
ClaudeCodeの承認とは何か
ClaudeCodeはファイルの読み書きやコマンド実行など、PCに影響を与える操作を行う前にユーザーに確認を求める。これがデフォルトの動作だ。
確認が来る主な場面はこうだ。
- ファイルを書き換えようとするとき
-
rmなどのファイル削除コマンドを実行しようとするとき -
git commitやgit pushを実行しようとするとき - ネットワーク通信を伴う操作をしようとするとき
- シェルスクリプトを実行しようとするとき
これを「全て許可」に設定すると、ClaudeCodeは確認なしに全ての操作を自律的に実行し続ける。
何をやったか
組み込みFirmwareプロジェクトのリファクタリングをClaudeCodeに任せた。指示はこうだ。
プロジェクト全体のCコードをリファクタリングしてください。
- 未使用変数を削除する
- マジックナンバーを定数に置き換える
- 関数が長すぎる場合は分割する
承認を全て「はい」にした状態でタスクを投げて、コーヒーを取りに席を立った。
5分後に戻ってくると、ClaudeCodeは作業を完了していた。
何が起きていたか
まずビルドを試みた。通らなかった。エラーが大量に出た。
error: 'UART_TIMEOUT' undeclared (first use in this function)
error: 'ADC_SAMPLE_RATE' undeclared (first use in this function)
error: implicit declaration of function 'uart_send_packet'
コードを見ると、ClaudeCodeは「未使用変数の削除」を解釈して、複数のファイルにわたって変数と関数を削除していた。
問題はここだ。削除された変数の一部は「このファイルでは使っていないが、別のファイルから参照されている」ものだった。ClaudeCodeはファイル単位で「使われていない」と判断して削除したが、プロジェクト全体で見ると参照されていた。
さらに悪いことに、git commitも全承認の対象だったため、ClaudeCodeはリファクタリングの途中で何度かコミットしていた。Gitの履歴がClaudeCodeの作業ログで埋まっていた。
commit a3f291c "refactor: remove unused variables in uart_driver.c"
commit b82e4d1 "refactor: extract magic numbers in adc.c"
commit c91f3a8 "refactor: split long functions in sensor.c"
commit d4a7b2c "refactor: remove unused variables in main.c"
...（14コミット）
本当に怖かったこと
ビルドエラーだけなら修正できる。本当に怖かったのは別のことだ。
ClaudeCodeはリファクタリングの過程で、「この定数は別の定数で置き換えられる」と判断して、#defineを削除しながら別の箇所を書き換えていた。その中に、製品の安全動作に関わるしきい値が含まれていた。
/* 元のコード */
#define MOTOR_CURRENT_LIMIT 2500 /* mA: 安全電流上限。これを超えたら即停止 */
/* ClaudeCodeが「マジックナンバー」と判断して削除し、
呼び出し元を直接数値に書き換えた */
if (motor_current > 2500) {
emergency_stop();
}
コメントの意味を読み取れず、「この定数は1箇所しか使われていない、インライン化して問題ない」という判断をした。定数が消えた時点でコードの意図が失われ、後でこの数値を変更すべき場面が来たとき、見落とすリスクが生まれた。
製品の安全設計に関わる数値が、コンテキストのないマジックナンバーになっていた。
幸いビルドが通らなかったため、実機には書き込まれなかった。でも全承認のままgit pushまで実行されていたら、レビューなしで変更がリモートに上がっていた可能性があった。
なぜ全承認が危険なのか
ClaudeCodeが確認を求めてくるのは「うるさいから」ではない。その操作が取り返しのつかない結果を生む可能性があるからだ。
確認の仕組みは「人間が介在するポイント」を強制的に作っている。
| 確認なし（全承認） | 確認あり（デフォルト） |
|---|---|
| AIが判断 → 即実行 | AIが判断 → 人間が確認 → 実行 |
| 人間が気づくのは「後から」 | 人間が問題を「実行前」に止められる |
| 複数ファイルの変更が連鎖する | 1操作ごとに確認できる |
ClaudeCodeは「文脈の全てを把握している」わけではない。プロジェクト固有のルール、安全設計の意図、チームの暗黙の了解、こういったことはCLAUDE.mdに書かない限り知らない。知らない状態で全承認すると、AIが「正しいと判断したこと」が実行され続ける。
全承認が向いている場面・向いていない場面
反省を踏まえて、今はこういう使い分けをしている。
全承認してもいい場面
- 新規ファイルを作るだけのタスク（既存コードを触らない）
- 読み取り専用の調査タスク（ファイルを読んで質問に答えるだけ）
- 使い捨てのスクリプト生成（本番コードに関係ない）
- テスト用の隔離フォルダ内での作業
絶対に全承認しない場面
- 既存コードの修正・削除が伴うタスク
-
git commit/git pushが含まれる可能性があるタスク - 本番環境や製品コードへの変更
- 複数ファイルにまたがるリファクタリング
設定の直し方
ClaudeCodeの承認設定はセッション中でも変更できる。
全承認モードから抜け出すには、ClaudeCodeのプロンプトで以下を実行する。
/permissions
または設定ファイル（~/.claude/settings.json）のallowedToolsを確認して、不要な自動許可を削除する。
リファクタリングのような「多くのファイルを触る可能性があるタスク」は、最初から手動承認モードで進めて、変更内容を1つずつ確認しながら進める方が結果的に速い。差し戻しになった後で全部やり直す時間の方がはるかに長いから。
まとめ
ClaudeCodeの承認確認は「邪魔なもの」ではなく「安全装置」だ。
面倒に感じるのはわかる。でも組み込み開発では「動いた」と「正しい」は別物で、「取り返しのつかない変更」が実機に入ってからでは遅い。承認を全部「はい」にすることは、その安全装置を全部外すことと同じだ。
「面倒だ」と思ったら、タスクの粒度を小さくする方向で解決するのが正しい。「このファイルのこの関数だけ」に絞れば、承認の頻度も下がるし、変更の影響範囲も把握しやすくなる。
全承認は便利そうに見えて、一番危ない使い方だった。