駆動開発をしていると、どうしても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の承認確認は「邪魔なもの」ではなく「安全装置」だ。

面倒に感じるのはわかる。でも組み込み開発では「動いた」と「正しい」は別物で、「取り返しのつかない変更」が実機に入ってからでは遅い。承認を全部「はい」にすることは、その安全装置を全部外すことと同じだ。

「面倒だ」と思ったら、タスクの粒度を小さくする方向で解決するのが正しい。「このファイルのこの関数だけ」に絞れば、承認の頻度も下がるし、変更の影響範囲も把握しやすくなる。

全承認は便利そうに見えて、一番危ない使い方だった。