AI開発支援ツールを使うと、コードを書くスピードはかなり上がります。
Claude Code、Codex、そのほかのAIコーディング支援ツールを使えば、既存コードを読ませて修正案を出したり、テストを追加したり、ドキュメントを整えたりできます。
ただ、実務で使っていると強く感じることがあります。
AIに任せる前に、人間が決めておくべきことがある。
ここを曖昧にしたまま進めると、AIはそれっぽく作ってくれます。
でも、それが本当に運用に耐えるかどうかは別です。
私たちがWP Maintenance ManagerのようなWordPress保守アプリを育てていく中でも、重要だったのは「AIにどんなコードを書かせるか」より先に、「AIが迷わないルールをどう作るか」でした。
AIは速いが、責任範囲までは勝手に決めてくれない
AIは、コードを書くのが速い。
既存の関数を参考にして、似た処理を追加する。エラー文から原因を推測する。テストコードの雛形を作る。説明文を整える。
こうした作業は、人間だけで進めるよりかなり速くなります。
一方で、AIはプロジェクトの責任範囲を最初から理解しているわけではありません。
どこまで変更してよいのか。
どのファイルは触ってはいけないのか。
既存ユーザーに影響する変更なのか。
WindowsとMacの両方で考える必要があるのか。
本番サーバーに反映してよいのか。
こうした判断は、プロジェクトごとに違います。
だからこそ、AIに作業を頼む前に、人間側が責任範囲を言葉にしておく必要があります。
最初に決めるべきは「禁止事項」
AI開発で最初に決めておきたいのは、便利な機能一覧ではなく、禁止事項です。
たとえば、次のようなルールです。
- 本番データを削除しない
- 既存ユーザーの設定ファイル形式を壊さない
- 触ってよいファイルと触ってはいけないファイルを分ける
- 秘密情報をコードやメモに書かない
- 公開前の記事を勝手に公開しない
- バージョン通知につながるファイルは最後に更新する
AIは、目的を達成するために近道を選ぶことがあります。
それ自体は悪いことではありません。
ただ、実務では「近道してはいけない場所」があります。
本番環境、ライセンス管理、決済、ユーザーデータ、公開記事、アップデート通知。
こうした部分は、便利さより安全性を優先する必要があります。
禁止事項を先に決めておくと、AIの提案を人間が判断しやすくなります。
変更後に何を確認するかまで決める
AIにコードを書かせるとき、修正そのものより大事なのが確認です。
1つの関数を直したら、その関数だけ見ればよいわけではありません。
呼び出し元はどこか。
似た処理が他にもあるか。
テストは通るか。
WindowsとMacで差が出ないか。
本番サーバーで動く前提が変わっていないか。
こうした確認を毎回人間が思い出すのは大変です。
だから、確認手順をルールとして書いておきます。
「コード変更後は、変更した関数の呼び出し元を確認する」
「同じパターンが他にないか検索する」
「パスや改行コードなど、OS差が出るところを確認する」
このように書いておくと、AIに対しても、自分自身に対しても、作業品質の基準になります。
優先度を分けると、AIへの指示が安定する
すべてのルールを同じ重さで並べると、AIも人間も判断しにくくなります。
そこで、ルールには優先度を付けた方がよいです。
たとえば、次のように分けます。
| 優先度 | 内容 | 例 |
|---|---|---|
| P1 | 絶対に守る | データ削除禁止、本番公開禁止、互換性破壊禁止 |
| P2 | 原則守る | ドキュメント更新、周辺確認、テスト追加 |
| P3 | できれば行う | 改善提案、次回作業のメモ、リファクタ候補 |
この分け方をしておくと、作業中の判断がかなり楽になります。
時間がないときでも、P1は絶対に落とさない。
P2は基本的に守る。
P3は余裕があれば提案する。
AIに指示するときも、「これはP1なので絶対に守る」と伝えられます。
AIがすべてを完璧に覚えるわけではありません。
それでも、優先度が明文化されているだけで、人間がレビューするときの基準ができます。
仕様書は、AIのためだけでなく人間のためにもある
AI開発支援を使い始めると、仕様書や運用メモはAIに読ませるためのものに見えるかもしれません。
しかし実際には、人間のためにも重要です。
なぜこの設計にしたのか。
どのファイルを同時に更新する必要があるのか。
ビルド時に守るべき条件は何か。
過去にどんな失敗があったのか。
次に同じ問題が起きたとき、どう判断すべきか。
こうした情報が残っていると、未来の自分が助かります。
AIにとっても、文脈があるほど的外れな提案を減らしやすくなります。
仕様書は、完成後に整える飾りではありません。
AIと一緒に開発を続けるための、作業現場そのものです。
「できた」より「壊していない」を確認する
AIに頼んだ作業は、見た目にはすぐ完成したように見えます。
ボタンが増えた。
画面が動いた。
エラーが消えた。
記事が生成された。
しかし、実務では「できた」だけでは足りません。
既存機能を壊していないか。
以前のデータが読めるか。
別の画面で同じ部品が崩れていないか。
ログやレポートに正しく反映されるか。
公開してはいけないものを公開していないか。
ここまで確認して、初めて仕事として扱えます。
AIが作ったものほど、人間側は「何ができたか」だけでなく、「何を壊していないか」を見る必要があります。
小さなルールが、あとから大きな事故を防ぐ
AI開発のルールは、最初は少し面倒に感じます。
ファイルを同時に更新する。
テストを確認する。
サーバーに置く一時ファイルの場所を決める。
公開前の操作を禁止する。
作業後にメモを更新する。
ひとつひとつは地味です。
でも、こうした小さなルールが、あとから大きな事故を防ぎます。
特に、WordPress保守や本番サイト運用のように、既存ユーザーやクライアントの事業に関わる領域では、速さよりも安全に進める設計が重要です。
AIを使うほど、ルールはいらなくなるのではありません。
AIを使うほど、ルールが効いてきます。
まとめ
AI開発支援ツールは、とても便利です。
ただし、AIに任せる前に、人間が決めるべきことがあります。
禁止事項。
責任範囲。
確認手順。
優先度。
ドキュメント更新。
本番操作のルール。
これらを明文化しておくことで、AIは単なるコード生成ツールではなく、実務の中で使える開発支援になります。
AIに良いコードを書かせることも大事です。
しかし、その前に大事なのは、AIが迷わない作業環境を人間が用意することです。
ルールを作ることは、AIを縛ることではありません。
安心して任せられる範囲を決めることです。
その範囲がはっきりしているほど、AI開発支援は実務で使いやすくなります。
