blog
開発メモAIを入れる前に、gitを入れておくべきだった——受託でClaude Codeの修正が担当の境界を越えた話
受託の現場にAIコーディングエージェントを入れると、たしかに実装は速くなります。ただ、最初の1ヶ月で本当に困ったのは、AIの精度とは別のところでした。
いちばん肝が冷えたのは、AIの修正が、担当の境界を越えていたことです。技術の問題ではなく、受託という仕事の成り立ちに関わる問題でした。
この記事は、Claude Code を日々の受託業務に入れた最初の1ヶ月で何が起き、何を決め直したかの記録です。これから導入を検討している制作会社や受託開発の方が、同じ順番でつまずかないように書いています。
先に結論から
- 受託でいちばん怖いのは、AIの修正が担当の境界を越えることだった。 品質の問題ではなく、「誰が直したのか説明できない」という責任の問題になる。
- 速くなるのは実装。減らないのは判断。 実装の速度は目に見えて上がるが、承認・レビュー・要望との照合は人間に残る。
- 先に決めるべきは、使い方ではなく設計。 何を任せ、どこには触らせないのかを書き出しておかないと、同じツールが天才にも足手まといにもなる。
最初の事故は、担当の境界を越えたことだった
Claude Code を使い始めた当時、こちらの制作環境はバージョン管理を使っていませんでした。本番のファイルをFTPでローカルに落としてきて、そこで直して、また上げる。長く続けてきた、そういう体制です。
その状態のままAIに作業を任せたところ、一度の指示で多数のファイルがまとめて書き換わりました。修正そのものは的確だったのですが、どこがどう変わったのかを追う手段がありません。元に戻すこともできない。ローカルの作業ファイルが一気に触られて、収拾がつかなくなりました。
そして、いちばん困ったのがここです。
プログラム側を担当している別のメンバーの領域にまで、修正が入っていました。
動いてはいます。直し方も間違ってはいない。それでも、これは受託の仕事としてそのまま納品できる状態ではありませんでした。担当していない人間が、担当者の知らないうちに手を入れた形になっているからです。
ここが、社内ツールを触るのと受託が決定的に違うところだと思います。自分たちのプロダクトなら「誰が直しても、動けばよい」で済む場面もあります。しかし受託では、納品物に対して「これは誰が、どういう意図で直したのか」を説明できる状態を保っていないといけません。分担があるということは、責任の切れ目があるということです。AIはその切れ目を知りません。指示の範囲を切らなければ、範囲を切らずに直してくれます。
つまりこれは、AIの精度が高いほど被害が広がる種類の事故でした。人間より速く、広く、的確に直してくれるからこそ、越境する範囲も広い。「うまく動いているのに、まずい」という状態は、性能が低いツールでは起きません。
ここで痛感したのは、次の2つです。
- 指示の出し方を具体的に決めること。どのファイル、どの範囲までかを明示せずに頼むと、明示しなかった場所まで直される。
- どこを修正されたかを必ず確認する工程を、作業の中に組み込むこと。
そして、その確認を現実的な手間でやろうとすると、結局はバージョン管理に行き着きます。差分が見えれば、何が変わったかは一目で分かる。担当外の場所に手が入っていれば、その場で気づける。戻すこともできる。AIを入れる前に、gitを入れておくべきだった——これが最初の1ヶ月でいちばん強く思ったことでした。
導入を検討している段階で、まだFTPで本番ファイルを直接やり取りしている現場があれば、AIより先にバージョン管理を入れることをおすすめします。順番を逆にすると、便利さの分だけ後始末が増えます。
今は、こう確認している
いま同じ事故が起きないようにしているのは、次の3つです。特別なことはしていません。
1. 変更は必ず差分で見る
作業のあと、何が変わったかを差分で確認してから確定させます。担当の境界を越えた修正は、ここでほぼ捕まえられます。「動いているから大丈夫」で先に進まないことが要点です。
2. 触ってほしくない場所は、設定で宣言しておく
Claude Code には、許可する操作と禁止する操作を宣言する settings.json があります。公式ドキュメントでは、次のように allow と deny を書く例が示されています（Claude Code Docs / Settings）。
{
"permissions": {
"allow": [
"Bash(npm run lint)"
],
"deny": [
"Read(./secrets/**)"
]
}
}この ** はディレクトリ配下すべてを指す書き方です。つまり「このフォルダには一切触れさせない」を設定として書けるということになります。担当が分かれている領域や、手を入れてほしくない部分を、口頭の約束ではなく設定として残しておく。毎回の指示で気をつけるより、こちらのほうが確実でした。
この線引きをどういう考え方で決めているかは、AIにどこまで任せるか——戻せる作業は任せ、本番反映は自分で止めるに書いています。
3. 本番への反映だけは、人が止める
ローカルでの作業は任せますが、本番環境に反映する操作は人間が実行します。ここを自動で通してしまうと、間違いに気づく機会がなくなるためです。実際、完了したという報告を受けたのに本番には何も反映されていなかった、ということもありました（Claude Codeの「公開しました」を信じたら、本番には何も反映されていなかった）。反映できたかどうかの確かめ方そのものを間違えていた例は、確かめ方を間違えた3つの現場にまとめました。
速くなったのは、実装だった
受け皿を整えたあとは、素直に恩恵がありました。特に効いたのは実装の速度です。
- 自然言語とキャプチャだけで、ページを高い再現性で組んでくれる。 レイアウトの指示を文章と画像で渡すだけで、意図した形に近いものが出てきます。
- JavaScriptの挙動も含めて実装が通る。 見た目だけでなく、動きの部分まで任せられます。
- ファイル構成を適切な形で設計してくれる。 どこに何を置くかを毎回考えなくてよくなるのは、地味ですがかなり助かります。
これは最初の1ヶ月の話ではありませんが、その後SSH経由でのコマンド操作や wp-cli を組み合わせられるようになると、速度はもう一段上がりました。手元で書いて、確認して、反映するまでが一続きになるためです。ここで踏んだ環境まわりの落とし穴はwp-cliをSSH経由で叩くときの地雷にまとめています。
減らなかったのは、判断だった
一方で、期待したほど減らなかった仕事があります。むしろここが、導入前にいちばん見積もりを誤りやすいところだと感じました。
都度の承認が、思考を細かく分断する
AIは作業のたびに承認を求めてきます。安全のためには正しい設計なのですが、その都度こちらが判断を下さなければならないため、任せきりにはできません。別の作業をしていても呼び戻される。この頭の切り替えにかかる負担が、想像以上に大きいと感じました。
作業そのものの時間は短くなっているのに、体感としてはあまり楽になっていない。その正体は、この分断だったと思います。
「技術的に正しい」と「求められたもの」は別
実装後のレビューは、やはり人間に残ります。
検索エンジン向けの書き方、安全性に配慮した書き方、技術的な妥当性——このあたりはかなりの水準で任せられます。ただし、最終的に先方の要望に沿ったものになっているかどうかは、人間が判断するしかありません。要望は言葉になっていない部分を多く含んでいて、そこはやり取りの積み重ねの中にしかないためです。
もっともらしい嘘が混じることがある
事実と異なる内容が、自然な文章のまま出てくることがあります。制作物の種類によっては、事実確認の工程を別に用意する必要がありました。
確認が必要な量そのものをどう扱うかについては、AIに作業を任せても、確認する人は増えないで掘り下げています。
設計次第で、天才にも足手まといにもなる
1ヶ月を通して分かったのは、成果を決めるのは使い方の巧拙よりも最初の設計だということでした。
Claude Code には、プロジェクトごとの指示を書いておく CLAUDE.md と、権限を宣言する settings.json があります。ここに何を書くかが、そのまま日々の安全と速度を決めます。具体的に、先に決めておくとよかったと思うのは次の4つです。
- 何を任せ、何は人間が判断するか。 特に本番環境に触れる操作をどう扱うか。
- コーディングのガイドライン。 命名、インデント、使ってよいライブラリなど、自社の書き方。
- 自社独自の制作ルール。 納品時の体裁や、案件を通して守っている決まりごと。
- プロジェクト単位の注意事項。 このプロジェクトでは触ってほしくないファイル、変更してはいけない設定。
とくに4つ目が、担当の境界を守るための実務的な答えでした。逆に言えば、ここが空のまま使い始めると、精度の高い実装が、意図しない場所にまで及びます。基本設計次第で、同じツールが天才にもなれば、足手まといにもなる——1ヶ月使ってみての実感です。
これから入れる方へ
順番だけ整理しておきます。
- バージョン管理を先に入れる。 差分が見えて、戻せる状態を作る。担当外への越境に気づける仕組みでもある。
- 触らせない場所を設定に書く。
settings.jsonのdenyで、フォルダ単位で禁止できる。 - 速くなるのは実装だと理解しておく。 承認・レビュー・要望との照合は残る前提で、時間を見積もる。
この3つを先に済ませておけば、最初の1ヶ月で私たちが使ったやり直しの時間は、かなり短くできるはずです。運用の各論はClaude Code実務運用ガイドにまとめているので、あわせて読んでみてください。
一次体験・方針判断・最終確認は人間の筆者、構成・執筆・事実照合はAI（Claude）との協働。2026年8月時点の記録です。
