生成AIのためのGit入門 第8章：Claude Codeに任せる作業、人間が見るべき作業
山崎講師Claude Codeを使うと、開発作業の多くをAIに手伝ってもらえます。
Claude Code公式ドキュメントでは、Claude Codeはコードベースを読み、ファイルを編集し、コマンドを実行し、開発ツールと連携できるエージェント型のコーディングツールだと説明されています。さらに、公式のCommon workflowsでは、コードベースの探索、バグ修正、リファクタリング、テストなどの日常的な開発作業のガイドが用意されています。
つまり、Claude Codeはかなり頼れる助手です。
ただし、ここで大事なことがあります。
頼れることと、丸投げしてよいことは違います。
Claude Codeに任せてよい作業もあれば、人間が必ず見るべき作業もあります。
新人エンジニアのうちは、ここを間違えやすいです。
「AIが作ってくれたから正しいはず」
「Claude Codeが直してくれたから、そのままコミットしてよさそう」
こう考えてしまうと危険です。
Claude Codeは作業を速く進めてくれる助手です。
でも、最終的に仕様を判断し、品質を確認し、チームに説明する責任は人間にあります。
たとえるなら、Claude Codeはとても優秀な料理アシスタントです。
野菜を切ったり、下ごしらえをしたり、レシピ案を出したりできます。
でも、「この料理をお客様に出してよいか」を決めるのは料理長です。
開発でいう料理長は、人間のエンジニアです。
Claude Codeに任せやすい作業
まず、Claude Codeに任せやすい作業から見ていきましょう。
ポイントは、「答え合わせしやすい作業」です。
AIに作らせたあと、人間がgit diff、テスト、実行結果、コードレビューで確認できる作業は、Claude Codeと相性がよいです。
| 任せやすい作業 | 理由 |
|---|---|
| DTOやPOJOの作成 | フィールド、getter、setterなどの形が決まっているため |
| DAOの雛形作成 | Connection、PreparedStatement、ResultSetの流れが定型的なため |
| テストコードの追加 | 期待値を人間が確認しやすいため |
| リファクタリング案の作成 | 重複削除やメソッド分割を提案させやすいため |
| エラー原因の調査補助 | ログやスタックトレースをもとに仮説を出せるため |
| ドキュメント下書き | コードの説明や手順の整理を任せやすいため |
たとえば、DTOの作成はClaude Codeに向いています。
DTOとは、Data Transfer Objectの略で、データを受け渡しするための入れ物です。
フィールド、コンストラクタ、getter、setter、toStringなど、ある程度パターンが決まっています。
このような定型作業はAIに任せやすいです。
学校でたとえるなら、同じ形式のプリントを何枚も作る作業に近いです。
人間が1枚ずつ手で作るより、AIに作らせて、人間が内容を確認するほうが効率的です。
Claude Codeに依頼しやすいプロンプト例
Claude Codeに任せるときは、作業範囲を具体的に伝えましょう。
悪い依頼例です。
いい感じに直してください。
この依頼はあいまいです。
どこを直すのか、どこまで変更してよいのか、何を守るべきなのかがわかりません。
良い依頼例です。
MatchedUserDtoを作成してください。
フィールドはmatchedUserId、matchedUserName、commonLikeCount、commonItemTitlesです。
getter、setter、toStringを追加してください。
DAO、Service、Controllerは変更しないでください。
この依頼はかなり具体的です。
作るもの、フィールド、追加するメソッド、変更してはいけない範囲が明確です。
Claude Codeに作業を任せるときは、「何をするか」だけでなく、「何をしないか」も伝えると安全です。
| 伝えること | 例 |
|---|---|
| 作業目的 | マッチング結果用DTOを作る |
| 変更してよい範囲 | model.dtoパッケージだけ |
| 変更してはいけない範囲 | DAO、Service、Controllerは触らない |
| 守るルール | 既存の命名規則に合わせる |
| 作業後の説明 | 変更ファイルと理由を説明する |
Claude Codeは便利ですが、何でも自由にやらせるより、範囲を決めて任せるほうが安定します。
部活で後輩に仕事をお願いするときも、「準備しておいて」だけではなく、「ボールを10個出して、コーンを5個並べて、ゴールはまだ動かさないで」と伝えたほうがうまくいきますよね。
人間が必ず見るべき作業
次に、人間が必ず見るべき作業を整理します。
ポイントは、「正解がコードだけでは決まらない作業」です。
仕様、設計、セキュリティ、データの扱い、業務ルールなどは、人間が判断する必要があります。
| 人間が見るべき作業 | 理由 |
|---|---|
| 仕様判断 | 何を作るべきかは業務やユーザー価値で決まるため |
| 設計方針 | 将来の拡張性や保守性に関わるため |
| DB設計 | データの整合性や運用に大きく影響するため |
| セキュリティ判断 | 情報漏えいや不正アクセスにつながる可能性があるため |
| 個人情報の扱い | 法務や社内ルールに関わるため |
| 本番反映の判断 | ユーザー影響や障害リスクがあるため |
たとえば、Claude Codeに「ユーザー削除機能を作って」と頼んだとします。
AIはDELETE文を書くかもしれません。
でも、本当に物理削除してよいのでしょうか。
それともdeleted_atを使って論理削除すべきでしょうか。
この判断は、単なるコードの問題ではありません。
運用、復元、監査、個人情報管理、業務ルールに関わります。
つまり、人間が決めるべき領域です。
Claude Codeは実装案を出せます。
でも、「その実装方針でよいか」を判断するのは人間です。
仕様判断はAIに丸投げしない
仕様とは、システムが何をするべきかを決めたルールです。
たとえば、ユーザーマッチング機能なら、次のような仕様があります。
| 仕様の例 | 判断が必要な理由 |
|---|---|
| 同じ商品にLIKEしたユーザーを何名返すか | 1名なのか複数名なのかで体験が変わる |
| すでにマッチ済みのユーザーを除外するか | 同じ相手ばかり出る可能性がある |
| ブロック済みユーザーを除外するか | 安全性やユーザー体験に関わる |
| 共通LIKE数が同じ場合にどう並べるか | 結果の公平性や再現性に関わる |
| 削除済み商品へのLIKEを使うか | 古いデータを判断材料にしてよいか検討が必要 |
Claude Codeに仕様判断まで丸投げすると、AIがそれらしいルールを勝手に作る可能性があります。
でも、それがビジネスやチームの意図に合っているとは限りません。
レストランでたとえるなら、AIは料理を作るのが得意です。
でも、「今日はアレルギー対応メニューにするべきか」「子ども向けの味付けにするべきか」「価格をいくらにするべきか」は、お店の方針やお客様の事情を知っている人間が判断する必要があります。
設計方針は人間が責任を持つ
設計とは、システムをどのような構造にするかを決めることです。
新人エンジニアのうちは、設計という言葉が少し難しく感じるかもしれません。
簡単に言うと、「あとから直しやすい形にするための組み立て方」です。
家づくりでたとえるなら、設計は間取りです。
キッチン、リビング、寝室、トイレをどこに置くかで、住みやすさが変わりますよね。
コードも同じです。
Controller、Service、DAO、DTOをどう分けるかで、保守しやすさが変わります。
Claude Codeに設計案を出させるのは有効です。
この機能をController、Service、DAO、DTOに分ける設計案を3つ出してください。
それぞれのメリットとデメリットも説明してください。
このように相談相手として使うのは良い使い方です。
ただし、最終的にどの設計を採用するかは人間が決めます。
なぜなら、設計にはチームの方針、既存コードの流れ、今後の拡張予定、メンバーの理解度が関わるからです。
AIはコードを読めますが、チームの歴史や運用上の事情までは完全にはわかりません。
セキュリティは必ず人間が確認する
セキュリティに関わる部分は、Claude Codeに任せっぱなしにしてはいけません。
たとえば、次のような箇所です。
| 確認箇所 | 見る理由 |
|---|---|
| SQLの組み立て | SQLインジェクションを防ぐため |
| 認証処理 | ログインしていないユーザーのアクセスを防ぐため |
| 認可処理 | 他人のデータを操作できないようにするため |
| パスワード処理 | 平文保存やログ出力を防ぐため |
| 個人情報の表示 | 必要以上の情報を返さないため |
SQLインジェクションとは、悪意のある文字列をSQLに混ぜて、意図しないDB操作をさせる攻撃です。
新人エンジニア向けに言うと、「入力欄に普通の名前ではなく、SQLを壊すような文字列を入れられる攻撃」です。
そのため、SQLに値を直接文字列連結するのは危険です。
PreparedStatementを使って、安全に値を渡す必要があります。
Claude CodeがPreparedStatementを使っているか。
パラメータ番号がずれていないか。
不要な個人情報をSELECTしていないか。
こうした確認は、人間が必ず行いましょう。
Claude Codeに任せる作業と人間が見る作業の分担表
ここで、役割分担を表にまとめます。
| 作業 | Claude Codeに任せる | 人間が見る |
|---|---|---|
| DTO作成 | フィールド、getter、setterの作成 | 項目名や型が仕様に合っているか |
| DAO作成 | SQLとJDBC処理の雛形作成 | SQL条件、deleted_at、PreparedStatementの安全性 |
| テスト追加 | テストコードの下書き | 期待値が正しいか、都合よく変えていないか |
| リファクタリング | メソッド分割や重複削除案の作成 | 動作が変わっていないか、読みやすくなったか |
| 設計案 | 複数案の提案 | チーム方針や将来性に合うか |
| エラー調査 | 原因候補の洗い出し | 本当の原因か、修正してよいか |
| 本番反映 | 手順の下書き | 実行判断、影響確認、ロールバック計画 |
この表で大切なのは、Claude Codeを使わないという話ではない点です。
むしろ、Claude Codeは積極的に使います。
ただし、人間が確認すべき場所を残しておくのです。
AIに手を動かしてもらい、人間が頭を使って判断する。
この分担が、AI時代の開発では重要になります。
AIに任せる前に人間が決めること
Claude Codeに作業を頼む前に、人間が決めるべきことがあります。
ここを決めないまま依頼すると、AIがそれらしい形で補完してしまいます。
| 人間が先に決めること | 例 |
|---|---|
| 目的 | 同じ商品にLIKEしたユーザーを1名取得したい |
| 対象範囲 | DAOとDTOだけ作る |
| 使うデータ | user_actionsのLIKEだけを見る |
| 除外条件 | 自分自身、削除済み商品、ブロック済みユーザーを除外する |
| 戻り値 | MatchedUserDtoを返す |
| 実行方法 | ServiceやREST APIは使わず、mainメソッドで確認する |
たとえば、次のように整理してから依頼すると、Claude Codeの出力は安定しやすくなります。
対象ユーザーと同じ商品にLIKEした別ユーザーを1名取得したい。
条件：
ユーザーアクションはLIKEだけ使う。
ServiceとREST APIは作らない。
SuperDaoを継承したDAOにmainメソッドを作る。
DTOはMatchedUserDtoを使う。
削除済み商品は除外する。
共通LIKE数が多いユーザーを優先する。
目的：
このように、人間が仕様の骨組みを決めてからAIに渡すと、作業がかなり進めやすくなります。
地図を持たずにタクシーに乗って「いい感じの場所へ行ってください」と言うより、「東京駅までお願いします」と言ったほうが目的地に着きますよね。
Claude Codeへの指示も同じです。
AIの出力を確認するときの人間のチェックポイント
Claude Codeが作業したあと、人間は次の流れで確認します。
git status
git diffGit公式のリファレンスでも、status、diff、commit、restore、resetなどは基本的なスナップショット管理や差分確認に関わるコマンドとして整理されています。Claude Codeの変更を確認するうえでも、git diffやgit statusは重要な確認手段になります。
確認ポイントは次の通りです。
| チェック | 確認内容 |
|---|---|
| 1 | 依頼した範囲だけ変更されているか |
| 2 | 仕様にない処理が追加されていないか |
| 3 | SQLの条件が正しいか |
| 4 | セキュリティ上危険な書き方がないか |
| 5 | 既存の命名規則に合っているか |
| 6 | 例外処理やNULLチェックが適切か |
| 7 | テストや実行結果が期待通りか |
| 8 | 自分が変更理由を説明できるか |
最後の「自分が変更理由を説明できるか」は、とても大切です。
レビューで先輩に聞かれたときに、「Claude Codeがそう書いたからです」では不十分です。
AIが書いたとしても、コミットするのは自分です。
自分の変更として説明できる状態にしましょう。
Claude Codeに聞いてよいこと、聞いたあとに人間が判断すること
Claude Codeには、どんどん質問して大丈夫です。
むしろ、質問しながら使うほうが学習になります。
| Claude Codeに聞いてよいこと | 人間が判断すること |
|---|---|
| このSQLの意味を説明してください | 仕様に合っているSQLか |
| このエラーの原因候補を出してください | どの原因が本命か |
| このクラスの責務を整理してください | 分割方針を採用するか |
| テストケース案を出してください | 期待値が正しいか |
| リファクタリング案を出してください | 今やるべき変更か |
Claude Codeを「答えを出す神様」として使うのではなく、「優秀な相談相手」として使いましょう。
相談相手がよい案を出してくれても、最終的に採用するかは自分で決めますよね。
開発でも同じです。
新人エンジニアが特に人間として見るべきところ
新人エンジニアは、すべてを完璧にレビューするのは難しいかもしれません。
でも、最低限ここだけは見てください。
| 見るべきところ | 理由 |
|---|---|
| 変更ファイル一覧 | 関係ないファイルが変わっていないか確認するため |
| 削除されたコード | 重要なチェック処理が消えていないか確認するため |
| SQLのWHERE句 | 取得条件や更新条件が変わるため |
| deleted_at IS NULL | 削除済みデータを除外できているか確認するため |
| PreparedStatement | SQLに安全に値を渡せているか確認するため |
| コミットメッセージ | 変更内容をあとから説明できるようにするため |
特に、削除されたコードは必ず見ましょう。
追加されたコードより、削除されたコードのほうが危険な場合があります。
AIが「不要そう」と判断して消したコードが、実は重要な安全装置だったということもあります。
車でたとえるなら、軽量化のためにブレーキを外してしまうようなものです。
見た目はすっきりしても、危険ですよね。
Claude Codeに任せすぎるデメリット
Claude Codeは便利ですが、任せすぎるとデメリットもあります。
| デメリット | 内容 |
|---|---|
| 理解が浅くなる | AIが書いたコードを説明できなくなる |
| 仕様が曖昧になる | AIが勝手に補完したルールが混ざる |
| レビューが甘くなる | 動いたからOKと判断してしまう |
| チームの設計方針とずれる | 既存コードと違う書き方が増える |
| 責任の所在が曖昧になる | 誰が判断した変更なのかわかりにくくなる |
AIを使うほど、人間の確認力が大切になります。
Claude Codeがコードを書く時間を短くしてくれるなら、人間はその分、仕様理解、差分確認、レビュー、テストに時間を使いましょう。
AI時代の新人エンジニアは、ただコードを書く人ではありません。
AIが作った変更を理解し、説明し、正しく管理する人になる必要があります。
Claude Codeに任せるメリット
もちろん、Claude Codeに任せるメリットは大きいです。
| メリット | 内容 |
|---|---|
| 実装速度が上がる | 定型コードや修正作業を速く進められる |
| 調査がしやすい | コードベースの説明やエラー原因の仮説を出せる |
| 学習に使える | 差分を見ながら実装パターンを学べる |
| リファクタリング案を得られる | 自分では気づきにくい整理案を出せる |
| テスト作成のきっかけになる | テストケース案や雛形を作れる |
大切なのは、任せる範囲を決めることです。
AIに全部任せるのではなく、AIに作業を手伝ってもらい、人間が判断する。
この形が一番安全で、学習効果も高いです。
作業前・作業中・作業後の役割分担
Claude Codeと人間の役割を、作業の流れで整理してみましょう。
| タイミング | 人間の役割 | Claude Codeの役割 |
|---|---|---|
| 作業前 | 目的、仕様、変更範囲を決める | 設計案や実装案を提案する |
| 作業中 | 必要に応じて指示を修正する | コード編集、調査、テスト実行を行う |
| 作業後 | git diff、テスト、レビューで確認する | 変更内容や影響範囲を説明する |
| コミット前 | 変更理由を理解し、コミットするか判断する | コミットメッセージ案を出す |
| レビュー時 | チームに説明し、必要なら修正する | 指摘対応の下書きを作る |
この流れを意識すると、Claude Codeを安全に使いやすくなります。
AIが全部やるのではありません。
人間が目的地を決め、AIが移動を手伝い、人間が到着確認をする。
カーナビに似ています。
カーナビは道を案内してくれます。
でも、目的地を決めるのは運転手です。
本当にその道を通るか判断するのも運転手です。
Claude Codeへの良い指示テンプレート
最後に、Claude Codeに作業を頼むときのテンプレートを紹介します。
目的：
何を実現したいかを書く。
変更範囲：
変更してよいファイルやパッケージを書く。
変更禁止：
触ってほしくないファイルや層を書く。
条件：
使うテーブル、使うアクション、除外条件などを書く。
確認：
変更後に説明してほしいことを書く。
具体例です。
ここまで書くと、Claude Codeの出力はかなり安定しやすくなります。
AIにうまく働いてもらうには、人間側の指示力が重要です。
第8章のまとめ
Claude Codeに任せる作業と、人間が見るべき作業は分けて考えましょう。
Claude Codeはコードベースを読み、ファイル編集やコマンド実行、バグ修正、リファクタリング、テストなどの日常的な開発作業を支援できる強力なツールです。だからこそ、人間が仕様、設計、セキュリティ、品質を確認する役割を持つことが重要です。
| ポイント | 内容 |
|---|---|
| Claude Codeに任せやすい作業 | DTO作成、DAO雛形、テスト下書き、リファクタリング案、調査補助 |
| 人間が見るべき作業 | 仕様判断、設計方針、DB設計、セキュリティ、本番反映 |
| 大切な考え方 | AIは実装の助手、人間は判断の責任者 |
| 確認方法 | git status、git diff、テスト、レビューで確認する |
| 新人エンジニアの目標 | AIが書いたコードを自分の言葉で説明できるようにする |
一言でまとめるなら、こうです。
Claude Codeには手を動かしてもらい、人間は判断する。
AIに作業を任せるほど、人間の確認力、設計力、説明力が重要になります。
新人エンジニアのうちは、Claude Codeが作ったコードをそのまま受け入れるのではなく、git diffを見て、なぜその変更が必要なのかを説明できるようにしてください。
AIを使いこなすエンジニアとは、AIに丸投げする人ではありません。
AIの力を借りながら、正しい判断を積み重ねられる人です。
セイ・コンサルティング・グループでは新人エンジニア研修のアシスタント講師を募集しています。
投稿者プロフィール
