Claude CodeのようなAIコーディングエージェントを個人開発で使うのと、クライアントワークで使うのとでは、気をつけるべきことがまったく違う。個人開発なら多少雑に扱っても自分が困るだけだが、クライアントワークでは、コンテキストに何を読み込ませるか、何を書き込ませるかが、そのままセキュリティ・契約上のリスクになる。
私はFDEとしてクライアント先の現場でClaude Codeを日常的に使っている。ここでは、その中で固めてきた運用設計を書く。
目次
コンテキスト管理: 何を読み込ませていいかを最初に線引きする
クライアントワークで最初に決めるべきは、「Claude Codeにどこまで読み込ませるか」の境界線だ。
リポジトリ全体を無条件に読ませるのは避けたい。特に、認証情報や顧客の実データが混在しているディレクトリは、.gitignoreと同じ発想で、AIエージェントからも隔離しておく必要がある。私の場合、機密性の高いファイル（.env、認証トークン、実データのサンプル）は明示的にアクセス範囲の外に置き、必要な操作だけをスクリプト経由で行うようにしている。
もう一つ重要なのが、契約先の他プロジェクトの情報を混ぜないことだ。複数のクライアント案件を並行して抱えている場合、ワークスペースを完全に分離し、あるクライアントの案件で得た知見をコンテキストとして別のクライアントの作業に持ち込まないようにする。これは守秘義務の観点で必須の運用だ。
セキュリティ: 権限とログの設計
AIエージェントに何ができるかを、必要最小限に絞る。ファイルの読み書き、コマンド実行、外部APIへのアクセスといった権限は、そのタスクに必要なものだけを都度許可する形にしている。
特にクライアント環境で気をつけているのは、本番データベースや本番環境への直接アクセスをAIエージェントに与えないことだ。検証や実装作業はステージング環境やローカルで行い、本番への反映は人間が最終確認した上で別途実行する。AIエージェントの提案は基本的に正確だが、「たまに間違える」という前提を運用設計に織り込んでおくことは、以前の記事で書いたPoC設計の考え方とも共通している。
もう一つ、実行ログを残すことも意識している。AIエージェントが何を読み、何を変更したかの記録は、後から問題が起きたときの原因調査に必要になる。特にクライアントの資産に触れる作業では、このログが説明責任を果たす材料にもなる。
成果物のレビュー: AIの提案をそのまま採用しない
AIエージェントが生成したコードや文書は、必ず人間のレビューを挟む。これは当たり前のようで、スピードを求められる現場では省略されがちなステップだ。
私が意識しているのは、レビューの視点を「動くかどうか」だけに留めないことだ。クライアントのコーディング規約に沿っているか、セキュリティ上の懸念がないか、契約上開示してはいけない情報が意図せず含まれていないか——AIエージェントは指示された範囲では優秀だが、クライアント固有の暗黙の制約までは把握していない。この部分を埋めるのが人間の役割になる。
まとめ
クライアントワークでClaude Codeを使う上での運用設計は、大きく3つに集約される。
- コンテキストの境界線を最初に引く（機密情報の隔離、クライアント間の分離）
- 権限とログを絞り込んで設計する（本番環境への直接アクセスを避ける、実行ログを残す）
- AIの提案を無条件に採用せず、クライアント固有の制約まで含めてレビューする
AIコーディングエージェントは強力な道具だが、クライアントワークでは道具の使い方そのものが信頼の一部になる。この運用設計は、今後もクライアントワークの中で更新していくつもりだ。
