はじめに

生成AIをコーディングに使い始めた頃は、変更するファイル、使う関数、実装手順、期待するコードの形まで具体的に指示した方が、うまくいく場面が多くありました。

モデルがコードベース全体を十分に探索できず、長い作業を自律的に進めることも苦手だった時期には、細かい作業分解は合理的でした。

一方で、現在のコーディングエージェントには、コードベースを検索し、関連ファイルを読み、既存の実装パターンを調べて、変更箇所を判断できるものがあります。AIの能力が変われば、良い指示に含めるべき情報も変わります。

この記事では、実装詳細を先に決める代わりに、人間しか渡せない文脈、目的、制約、判断基準を渡す考え方を整理します。

昔は細かく指示することに意味があった

AIが一度に扱える文脈や、自律的に実行できる作業が限られていた頃は、人間がタスクを細かく分解する必要がありました。

UserService.tsを開く。
getUserメソッドを修正する。
sessionStorageから検索条件を取得する。
値が存在しない場合は初期値を使う。
既存の型定義は変更しない。

ここまで分解すれば、AIが途中で迷う可能性を減らせます。人間が設計と作業分解を行い、AIには実装を担当させる形です。

現在は、同じ問題を次のように渡せる場面があります。

検索条件をタブごとに独立して保持したいです。
現在は別タブの検索状態が混ざる問題があります。

ブラウザを閉じた後まで検索条件を残す必要はありません。
既存実装を調査し、影響範囲を確認した上で修正してください。
必要なテストも追加してください。

この依頼では、UserService.ts を変更するとも、sessionStorage を使うとも決めていません。どこに問題があるかを調べ、適切な実装方法を選ぶこともタスクの一部として渡しています。

AIが自分で確認できる情報まで毎回指示書に転記すると、人間側の調査がボトルネックになります。

AIに積極的に渡したいのは、実装手順より次の情報です。

対象クラスの場所、既存処理の呼び出し元、プロジェクト内の実装パターン、変更すべきファイルは、コードベースから確認できるならAIに調べてもらえます。

たとえば、customer、applicant、contractHolder が業務上別の概念なら、その区別は単なる命名の好みではありません。名前の違いそのものがドメインモデルを表します。このような情報は、コードだけでは十分に判断できない場合があります。

人間は「この変数名にする」と細部まで決めるより、AIが適切な名前を選べるように意味とドメイン知識を渡します。既存コードから推測できる命名規則や表現は、調査の対象にできます。

人間が最初から「このクラスを変更する」と決めると、本来は別の層を変更した方が自然でも、AIはその指示に従おうとします。

目的、制約、ドメイン知識、完了条件を渡し、AIに調査と実装案の比較をさせると、設計上の選択肢を確認できます。ただし、アーキテクチャ上の決定、セキュリティ要件、変更してよい範囲は、AIに推測させず明示する必要があります。

重要なのは、必要な制約と、AI自身が確認できる実装詳細を区別することです。

実装詳細をAIに任せても、人間の役割がなくなるわけではありません。人間は、問題と完了条件の定義、コードから分からない業務知識の提供、制約と公開範囲の決定、出力の検証、本番反映や外部公開の最終判断を持ちます。

AIに任せる範囲を広げるほど、何を確認すれば失敗を検出できるかを先に決める必要があります。テスト、レビュー、差分確認、ロールバック手段がない作業まで無条件に任せるべきではありません。

AIへの良い指示は固定されたものではありません。

AIが実装詳細を自力で確認できないなら、人間が作業を分解して渡します。AIがコードベースを調査し、実装方法を比較できるなら、人間は文脈、目的、制約、ドメイン知識、完了条件を渡します。

大切なのは、詳しい指示を減らすこと自体ではありません。AIが確認できることと、人間だけが判断できることを分け、使っているAIの能力に合わせて責任境界を見直すことです。