← ./articles-ja

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が正しい自由度で動けるようにするための作業です。