「もっと詳しく書けば伝わるだろう」と、長い依頼文を作っていた時期があります。ところが、情報を足すほど大事な条件が埋もれる。今は、まず短く渡して、足りない部分だけ会話で詰めています。
1依頼を4行に分ける
最初に書くのは、目的、触る場所、守る条件、終わりの基準。この4つです。文章としてきれいにつなぐ必要はありません。
目的: 記事一覧にカテゴリ絞り込みを追加
対象: index.html と script.js
制約: 既存URLは変えない
完了: モバイルでも選択できるこの形にしてから、「どこまで直せばいいですか」という往復がかなり減りました。
2AGENTS.mdを先に置く
毎回説明するルールは、会話ではなくリポジトリに置きます。テストコマンド、命名、触ってほしくないフォルダ。このあたりが書いてあれば十分です。
3必要なファイルだけ渡す
資料を全部読ませると安心したくなりますが、たいてい逆効果です。対象ファイルと、その判断に必要な背景だけを選びます。迷ったら、まずCodexに「どのファイルが必要そうか」を調べてもらうのも手です。
広告について
今後、このブログではアフィリエイトリンクを使う予定です。ただし、紹介するのは実際に試したサービスに限ります。リンク経由で申し込んでも、読者の支払額は変わりません。
4変わる情報は検索する
料金、利用上限、新機能はすぐ変わります。ここをモデルの記憶に任せるのは危険です。私は「検索結果を出して」で終わらせず、公式ページを開き、更新日まで見るよう頼んでいます。
Xは話題を見つける場所。仕様を確定する場所ではない。
5画面はブラウザで見る
コードが通っても、見た目が正しいとは限りません。長い見出しがスマホで妙に折れたり、固定メニューが本文を隠したりします。これはソースだけ眺めていても分かりません。
最低でも、PC幅とスマホ幅で一度ずつ開く。フォームがあるなら実際に押す。地味ですが、効きます。
6権限は小さく始める
最初から広い書き込み権限を渡さないようにしています。削除、外部送信、公開につながる操作は、対象が見えてから許可する。面倒に見えて、事故後の確認よりずっと早いです。
7最後に差分を読む
テストが通ったあとに見るのがGit差分です。私はここで、頼んでいない文言変更や、消し忘れたデバッグ表示を何度か見つけています。
git status --short
git diff --check
git diff「動いた」と「意図した変更だけ入った」は別の確認です。
8分けられる仕事だけ分ける
調査、実装、表示確認のように、答えを別々に出せる仕事は並行化しやすいです。一方で、同じCSSを複数の担当に同時編集させると、あとで合わせるほうが大変になります。
速くするための分担なのか、役割を明確にするための分担なのか。先にどちらか決めておくと迷いません。
9外部連携は境界から決める
MCPでGitHubやドキュメントにつなぐと、できることは一気に増えます。そのぶん、「何ができるか」より「何をしてよいか」を先に決めます。読むだけなのか、下書きまでなのか、公開も任せるのか。ここは曖昧にしないほうがいいです。
10定期化は3回試してから
一度うまくいった作業を、すぐ自動化しない。私はまず同じ手順を3回動かして、毎回変わる部分と固定できる部分を分けます。
AIニュースの収集なら、取得元、重複の扱い、記事にしない条件、公開前の確認者まで決めておく。自動化は「成功したとき」より、情報が取れなかった日にどう止まるかが大切です。