ブログ向けなら、少し自虐と現場感を混ぜた日記風のほうが読みやすいですね。
Claude Codeを「有能な部下」にするための安全管理術
最近、Claude Codeを触っていて思うことがある。
SNSを見ていると、
「AIに全部やらせた」 「朝起きたら機能が完成していた」 「もうプログラマはいらない」
みたいな話が流れてくる。
もちろん、あれはあれで面白い。
だが、長年エンジニアをやっている身としては、どうしても別の感想が先に出てしまう。
「それ、本番環境でやる勇気あるの？」
というやつだ。
AIに丸投げするのは、無責任な管理職と同じ
昔、管理職をやっていた頃に学んだことがある。
部下に対して、
「好きにやっていいよ」
と言う上司は、一見すると寛容に見える。
だが実際は違う。
責任を放棄しているだけだ。
逆に、
「全部報告しろ」 「全部確認を取れ」
も組織は動かない。
結局のところ必要なのは、
任せるところは任せる。止めるところは止める。
というバランス感覚だった。
Claude Codeも同じだ。
全部イエスでもダメ。
全部ノーでもダメ。
Claude Codeは「部下」だと思うと理解しやすい
最近のClaude Codeはかなり優秀だ。
ファイルを読んで、 コードを書いて、 リファクタリングして、 テストまで実行する。
下手をすると新人エンジニアより仕事が速い。
ただし、新人エンジニアと同じ欠点もある。
自信満々に間違える。
だから管理が必要になる。
権限モードは「指示の出し方」そのもの
Claude Codeには権限モードがある。
私はこれを「部下への指示レベル」だと思っている。
default モード
基本はこれ。
何かやるたびに確認が入る。
新人が
「これ削除していいですか？」
「このファイル変更していいですか？」
と聞いてくる状態だ。
少し面倒だが、一番安全。
auto モード
慣れてきたら使う。
テスト実行や軽微な修正程度なら勝手に進めてくれる。
ただし、
「優秀だから放置する」
のではなく、
「比較的安全な仕事だけ任せる」
という感覚が大事だ。
経理担当に会社の金庫を渡さないのと同じである。
plan モード
個人的にはかなり好きだ。
コードは触らせず、
「まず計画だけ出せ」
と言うモードである。
初見の巨大システムや複雑な改修の時は、まずこれを使う。
人間同士でも、
「いきなり作るな。まず設計書を書け」
と言うだろう。
あれと同じだ。
聖域は物理的に守る
人間はミスをする。
AIもミスをする。
だから私は精神論を信用していない。
物理的に防ぐ。
.claudecodesignore
ここに触ってほしくない場所を書く。
例えば、
- .env
- シークレット情報
- 本番設定
- 外部ライブラリ
などだ。
「触るな」とお願いするのではない。
そもそも見せない。
これが一番強い。
CLAUDE.md
こちらはプロジェクト憲法みたいなものだ。
例えば、
- Gitコミットは細かく分ける
- 破壊的操作は許可を取る
- .envは禁止
- テスト必須
などを書く。
面白いのは、人間向けの開発ルールがそのままAIにも通用することだ。
結局、優秀な部下に求めることと大差ない。
本当に重要なのはGitだった
Claude Codeの話をしているようでいて、実はそうでもない。
最後の安全装置は昔から変わっていない。
Gitである。
私はAIに作業させる時、
まず作業ブランチを切る。
好きに修正させる。
そして最後にPRを見る。
この流れを崩さない。
どれだけAIが賢くなっても、
最終レビューは人間がやる。
これは今のところ変わらない。
離席中の「業務報告」
最近少し面白いと思ったのが awaySummaryEnabled だ。
離席して戻ると、
「何をやったか」
を要約してくれる。
まるで部下の日報みたいである。
実際、AIエージェントを使っていると、
だんだん感覚が管理職に近くなってくる。
自分でコードを書く時間より、
レビューする時間の方が長くなる。
AI時代に必要なのは管理能力かもしれない
AIがコードを書く。
AIがテストする。
AIが調査する。
そういう時代になってきた。
だが、使っていて思う。
本当に価値が残るのは、
「コードを書く能力」
だけではない。
何を任せるか。 どこまで権限を与えるか。 どこにガードレールを置くか。
そういう管理能力の方かもしれない。
昔は人間の部下を管理していた。
これからはAIの部下を管理する。
やっていることは意外と変わらない。
違うのは、深夜2時に仕事を振っても文句を言われないことくらいだろう。
このオチだと、あなたの普段の「現場で長くやってきたエンジニア視点」とも合いますし、「AI礼賛」でも「AI否定」でもない、ちょっと皮肉の効いた日記風になります。