AI開発支援ツールを使うようになってから、仕様書や作業メモの意味が少し変わったと感じています。
以前の仕様書は、人間があとで読むための記録という意味合いが強かったかもしれません。
どんな機能を作ったか。
どのファイルに何があるか。
どんな経緯で今の設計になったか。
もちろん、それも大事です。
しかし、AIと一緒に開発する場合、仕様書は単なる記録ではなくなります。
AIが作業する前に読む、操作ルールになります。
何をしてよいか。
何をしてはいけないか。
どの順番で確認するか。
変更後に何を更新するか。
そこまで書いてあると、AIとの作業はかなり安定します。
AIは文脈がないと、正しそうな近道を選ぶ
AIは、与えられた目的に向かってかなり上手に進みます。
ただし、プロジェクト固有の文脈を最初から知っているわけではありません。
このファイルは触ってよいのか。
本番へ反映してよいのか。
この変更は英語版にも必要なのか。
公開してはいけない下書きなのか。
過去に同じ変更で事故が起きたのか。
こうした文脈がないと、AIは一般的には正しそうな近道を選ぶことがあります。
それが、小さな修正なら問題にならないこともあります。
しかし、本番サイト、ライセンス管理、WordPress保守、ブログ投稿、決済、ユーザーデータが絡むと危険です。
AIに任せるほど、文脈を文章として渡す必要があります。
仕様書には、完成形だけでなく禁止事項を書く
仕様書というと、完成形や機能一覧を書きたくなります。
しかし、AIと一緒に使う仕様書では、禁止事項がとても重要です。
- 本番記事を勝手に公開しない
- 秘密情報を書かない
- 指定外のサーバーディレクトリを汚さない
- バージョン通知につながるファイルは最後に更新する
- 既存ユーザーの設定形式を壊さない
- 画像やアップロード領域を不用意に削除しない
こうしたルールは、普通の仕様書では後回しにされがちです。
でも、AIに作業させるなら最初に必要になります。
禁止事項があることで、AIの提案を人間が判断しやすくなります。
また、AIが一見便利そうな方法を出してきたときに、「このプロジェクトではその近道は使わない」と止めやすくなります。
手順は、細かすぎるくらいでちょうどいい
人間同士なら「いつもの手順で」で通じることがあります。
しかし、AIには「いつもの」がありません。
だから、作業手順は細かく書いておいた方がよいです。
たとえば、ブログ記事作成なら次のような流れです。
- draft.mdを作る
- Gutenberg HTMLを作る
- アイキャッチ画像を作る
- 本番WordPressに下書き投稿する
- 投稿者、カテゴリー、タグ、抜粋、スラッグを設定する
- アイキャッチをメディア登録して設定する
- X投稿案を作る
- ネタ帳にPost IDやURLを記録する
- 公開はユーザーが明示するまで行わない
人間にとっては少し細かく見えます。
でも、この粒度で書いてあると、AIは作業を途中で止めにくくなります。
「原稿だけ書いて終わり」ではなく、「下書き投稿まで」が完了条件だと分かります。
完了条件が明確だと、作業品質も安定します。
仕様書は、作業のたびに育てる
AIと使う仕様書は、一度書いたら終わりではありません。
作業していると、新しい注意点が出てきます。
同じミスを繰り返しそうな場所が見つかります。
本番サーバーの作業ディレクトリを決める必要が出てきます。
画像の方針が変わります。
Gutenberg HTMLのブロック規約が決まります。
WordPress側でタイトルを編集する運用が分かります。
こうした情報は、次の作業のために仕様書へ戻した方がよいです。
仕様書は、過去の記録であると同時に、次回の作業品質を上げるための道具です。
AIと仕事をしていると、この更新がとても効いてきます。
AIに読ませる文書と、人間が判断する文書は分けすぎない
AI用のプロンプトと、人間用の仕様書を完全に分ける方法もあります。
しかし、実務では分けすぎるとズレやすくなります。
人間が読んでいるルールと、AIに読ませているルールが違う。
古いプロンプトだけ残っている。
仕様書には書いたが、AIの作業前には渡していない。
こうなると、ルールがあっても守られません。
できれば、作業の基準になる文書は、AIも人間も同じものを読む形に寄せた方がよいです。
そのうえで、必要に応じて短い依頼文を足す。
この方が、運用がシンプルになります。
AIのためだけに特別な指示を増やすより、プロジェクトのルールそのものを整える方が長く使えます。
本番作業では、仕様書がブレーキになる
AIは作業をどんどん進められます。
だからこそ、本番作業ではブレーキが必要です。
たとえば、WordPress本番投稿では「公開はユーザーが明示するまでしない」というルールが重要です。
サーバー作業では「一時ファイルは決めた場所に置く」というルールが必要です。
テーマ変更では「触る前にバックアップや差分確認をする」というルールが必要です。
このようなルールが仕様書に書かれていると、AIも人間も立ち止まれます。
AI開発支援では、アクセルだけでは危険です。
どこで止まるか。
どこで確認するか。
どこから先は人間の明示が必要か。
仕様書には、このブレーキの役割があります。
仕様書があると、別セッションでも続きから進めやすい
AIとの作業では、毎回同じ相手と同じ文脈で続けられるとは限りません。
セッションが変わることもあります。
時間が空くこともあります。
別の作業と混ざることもあります。
そのときに、仕様書や引き継ぎメモがあると、作業を再開しやすくなります。
どこまで終わっているか。
何が公開済みか。
どの投稿が下書きか。
どのファイルを最初に読むべきか。
どのサーバーにどう接続するか。
こうした情報がまとまっていると、AIは最初からやり直さずに済みます。
人間にとっても、「前回どうしたっけ」と探す時間が減ります。
仕様書は、AIの記憶の代わりではありません。
作業を継続するための共有地です。
まとめ
AIと一緒に開発するなら、仕様書は単なるメモではありません。
AIに渡す操作ルールです。
禁止事項。
完了条件。
確認手順。
本番作業のブレーキ。
更新すべき記録。
こうしたものが書かれているほど、AIとの作業は安定します。
AIは便利です。
しかし、文脈なしで任せると、正しそうな近道を選ぶことがあります。
その近道が、実務では危ないこともあります。
だからこそ、人間側が仕様書を育てる必要があります。
仕様書を整えることは、AIに仕事を丸投げするためではありません。
AIと人間が同じ判断基準で進むための準備です。
そこまで整っていると、AI開発支援はかなり頼もしい道具になります。
