結論から書くと、Claude Code に任せられるのは 結果を機械や人が確認できる作業 です。コードの調査、既存の書き方に沿った実装、テストの追加などがこれにあたります。逆に任せられないのは、何が正しいかを決める判断と、取り返しのつかない操作 です。要件の確定、設計上のトレードオフの決定、本番の操作、最終的な品質の責任は人に残ります。
受託開発では、この線引きが自社開発より重要です。お客様のコードと業務を預かり、成果に責任を負っているからです。
Claude Code の公式ドキュメントにも、提案されたコードとコマンドを承認前に確認する責任は利用者にあると明記されています。AI が書いたコードでも、納品するなら自分の成果物です。
工程ごとの線引き
h-system で開発の工程ごとに分担している内容をまとめると、次のようになります。
| 工程 | AI に任せること | 人が決めること |
|---|---|---|
| 要件の確認 | 議事録の整理、確認事項の洗い出し | 何を作るか、お客様との合意 |
| 既存コードの調査 | 処理の流れの説明、影響範囲の候補出し | 調査結果の検証、重要箇所の確認 |
| 設計 | 選択肢とトレードオフの提示 | どの案にするかの決定 |
| 実装 | 既存の書き方に沿ったコード作成 | 差分の確認 |
| テスト | テストコードの作成と実行 | 何を確認すべきかの決定、結果の確認 |
| レビュー | 差分の下読み、見落としの指摘 | 指摘の採否、最終判断 |
| リリース | 手順書の下書き | 本番への反映と本番の操作 |
ここで大切なのは、右の列が「時間があれば確認すること」ではないという点です。右の列を省くと、受託開発としては成り立ちません。
任せやすい工程
既存コードの調査
初めて触るコードを読むのは、最も効果を感じやすい使い方です。「この画面の登録ボタンを押すと、どのファイルのどの処理を通るか」「このカラムを更新している箇所はどこか」といった質問に、ファイルをまたいで答えを返してくれます。
ただし、もっともらしく間違えることがあります。答えと一緒に、ファイル名と行番号を出させて確かめます。特に PHP の古いシステムでは、動的なメソッド呼び出しや文字列で組み立てたファイル名が多く、検索だけでは追えないことがあるので注意が必要です。
既存の書き方に沿った実装
周囲に手本があるほど精度は上がります。同じ構造の画面を追加する、バリデーションを追加する、といった作業は任せやすい部類です。
テストの作成と実行
公式のベストプラクティスに「合否が返るものを Claude に実行させる」という趣旨の助言があり、これは実務の感覚とも一致します。確認の手段がないと、Claude は「できたように見える」ところで止まってしまいます。テストがあれば、失敗を見て自分で修正を繰り返せます。
同じ箇所では、完了の報告には実行したコマンドと出力、スクリーンショットといった証拠を求めるよう勧めています。「修正しました」という文章だけでは、確認したことにはなりません。
定型的な修正と機械的な置き換え
古い関数の置き換えや、多くのファイルにまたがる同じ形式の修正も任せやすい作業です。PHP のバージョンアップで大量に出る非推奨の修正などが典型です。ただし、一括で修正させた差分は量が多くなり、確認が雑になりがちです。ファイルや機能のまとまりごとに分けて進め、テストや構文チェックをその都度通します。
差分の下読み
実装したセッションとは別のセッションにレビューさせると、書いたときの思い込みを引きずらない指摘が得られます。公式でも、別のセッションを独立したレビュアーとして使う方法が紹介されています。ただ、問題ないと言われたことを、問題がない証拠にしてはいけません。
任せてはいけない工程
要件と仕様の確定
AI は依頼に対して、それらしい答えを必ず出します。要件があいまいなまま頼むと、あいまいな部分を自分で埋めて、きちんと動くものを作ってしまいます。動いているので、間違った前提に気づきにくくなります。お客様に確認すべきことは、確認事項として出させて、人が聞きに行きます。
設計上のトレードオフの決定
選択肢を出させるのは有効ですが、どれを選ぶかには、お客様の予算、今後の変更の見通し、運用する人の技術力といった、コードにない情報が必要です。
本番環境の操作
本番への反映、本番データベースの操作、課金に関わる操作、メールなどの外部への送信は、h-system では必ず人が実行するか、人の承認を通すルールにしています。これらは間違えたときに取り返しがつかないからです。
このルールをエージェントの指示ファイルに書くだけでは不十分です。公式ドキュメントにも、CLAUDE.md は強制力のある設定ではなく文脈として扱われるとあります。止めたい操作は、権限設定のように仕組みの側で止めます。
お客様への説明と約束
見積の金額、納期、不具合の原因の説明など、お客様への約束につながるものは、下書きに使っても、内容を確定するのは人です。AI が出した見積の根拠や原因の説明は、もっともらしくても検証されていません。そのまま伝えて間違っていた場合の責任は、受託した側が負います。
秘密情報の扱い
.env や接続情報は読ませない設定にします。公式の権限設定では Read(./.env) のように読み取りを拒否できます。ただし、スクリプトが自分でファイルを開くような間接的な読み取りには適用されない、という制限も明記されています。設定を入れたから安心、とは考えないほうが安全です。
お客様のコードを扱う以上、データの扱いも確認が必要です。公式のデータ利用の説明では、商用の利用条件について、顧客が選択しない限りモデルの学習に使わないと説明されています。条件は契約の形態で変わり、変更もあり得るので、契約時に確認します。また、お客様との秘密保持契約で外部サービスの利用が制限されていないかも、あわせて確認します。
受託で使うときの運用ルール
最後に、線引きを実際の運用に落とすときのポイントです。
- お客様に AI の利用を伝える。 どの工程で、どのように使い、どう確認するかを説明し、契約上の制限も確認します。
- 小さく頼み、都度確認する。 大きな変更を一度に頼むと、差分を確認しきれなくなります。確認できない差分は、納品できない差分です。
- 確認の手段を先に用意する。 テスト、構文チェック、画面確認の手順を準備してから実装を頼みます。
- 同じ修正を繰り返さない。 公式でも、同じことを2回直しても間違うなら、会話を続けるより
/clearでやり直すほうがよいとされています。 - 共通のルールは指示ファイルに書く。 毎回説明していることは、AGENTS.md や CLAUDE.md にまとめます。
h-system でできること
h-system では、業務システムの開発や保守に AI を組み込んでいます。調査と実装に AI を活用して速く進め、何を作るか、どう設計するか、リリースしてよいかは開発者が判断します。AI がすべてを自動で完成させるとはお約束しません。自社で運用するサービスの開発でも、調査、実装、レビュー、テストに AI を組み込んだ流れで進めています。AI の取り入れ方についてのご相談は、初回相談（オンライン30分程度）を無料で承ります。