AIエージェントに実装を頼む前に境界条件メモを書く
AIエージェントに実装を頼むとき、プロンプトを長くすれば安全になるとは限りません。
むしろ重要なのは、実装前に「どこまで変えてよいか」「何を変えてはいけないか」「何をもって完了とするか」を短く固定することです。この記事では、それを境界条件メモと呼びます。
境界条件メモは設計書ほど大きなものではありません。数行で十分です。ただし、AIが勝手に解釈しやすい部分を先に潰すので、実装の精度が上がります。
なぜ境界条件が必要か
AIエージェントは、足りない情報を補って作業を進めます。これは強みですが、実装タスクではリスクにもなります。
たとえば「記事一覧を直して」とだけ頼むと、AIは次のような判断を勝手にします。
- 見た目の問題なのか
- ソートの問題なのか
- データ取得の問題なのか
- ルーティングの問題なのか
- テストまで追加すべきなのか
人間なら会話の流れで察する場面でも、コードベース上では複数の解釈が成立します。そのまま実装すると、依頼者が期待していないファイルまで触ることがあります。
境界条件メモは、この余白を減らします。
書くべきことは3つだけ
実装前に書く内容は、まず次の3つで十分です。
Goal: 記事一覧で日本語記事だけが日付降順で表示されるようにする
Scope: src/app/ja/page.tsx と src/lib/content.ts の読み取り範囲まで
Done: npm run typecheck と npm run build が通り、/ja に対象記事が出る
これだけで、AIが「英語トップページも同時に改善しよう」「カードデザインも整理しよう」と広げる余地が減ります。
さらに安全にしたい場合は、触らない領域も書きます。
Do not change: content/*.md, mcp-server/, package dependencies
これは特に、既に動いている周辺機能があるプロジェクトで効きます。小さな修正のつもりが、依存関係更新や共通コンポーネント改修に広がる事故を防げます。
「完了条件」は検証コマンドで書く
完了条件は、感覚ではなく検証できる形にします。
悪い例です。
Done: いい感じに直る
これではAIも人間も判断できません。良い例は次です。
Done: npm run typecheck が通る。npm run build が通る。/ja/articles/<slug>/ が404にならない。
検証コマンドがあると、AIは作業の最後に実行すべきことを迷いません。失敗した場合も「実装はしたが検証未完了」と切り分けやすくなります。
触るファイルを固定しすぎない
ただし、境界条件メモでファイルを固定しすぎるのも危険です。
たとえば、バグの原因が src/lib/content.ts にあるのに、依頼で src/app/page.tsx だけを触るように指定してしまうと、AIは表示側で無理に回避しようとします。結果として、根本原因が残ります。
おすすめは、書き込み範囲と調査範囲を分けることです。
Read: src/app/, src/components/, src/lib/content.ts
Write: src/app/ja/page.tsx only unless root cause requires content loader change
これなら、AIは必要な文脈を読めます。一方で、勝手な大規模改修はしにくくなります。
エージェントを複数使う時は所有範囲を分ける
複数のAIエージェントに並列で作業させる場合は、境界条件がさらに重要になります。
同じファイルを複数エージェントが触ると、差分が衝突します。同じビルド成果物に同時に書き込むと、.next/ や dist/ が壊れることがあります。
Next.jsで実際に .next/routes-manifest.json が欠ける場合の切り分けは、Next.jsでroutes-manifest.jsonが見つからない時は並列next buildを先に疑う で詳しく整理しています。
並列作業では、次のように分けます。
Agent A: investigate only, no file edits
Agent B: edit src/components/ArticleCard.tsx only
Main thread: run final build once after both finish
実装担当と調査担当を分けるだけでも、作業はかなり安定します。最後の検証は1か所で実行するほうが、原因不明のビルド競合を避けやすいです。
境界条件メモのテンプレート
小さな実装なら、次のテンプレートを使えます。
Goal:
Scope:
Read:
Write:
Do not change:
Done:
Risk:
すべて埋める必要はありません。空欄が多いなら、まだ依頼の形が粗いという判断材料になります。
重要なのは、AIに「自由に良くして」と渡す前に、ビジネス上・運用上の境界を先に示すことです。売上に直結するページ、認証、課金、SEO、広告まわりは特に、触ってよい範囲を明示したほうが安全です。
まとめ
AIエージェントへの実装依頼は、長文の説明よりも境界条件が効きます。
Goal、Scope、Doneを短く書くだけで、不要な拡張、触ってほしくないファイル変更、検証漏れを減らせます。複数エージェントを使う場合は、所有範囲と最終検証の担当も分けておくと安定します。
境界条件メモは、AIを縛るためではなく、AIが正しい自由度で動けるようにするための作業です。