「作って」ではなく「約束」を書く：Claude Codeに渡した構築プロンプトの設計図 では、個人開発者が日本株AIスクリーニングツールをClaude Codeと開発した過程が紹介されています。最初に渡したのは機能一覧ではなく、「作らないもの」「厳守ルール」「未決事項」「受け入れ基準」を軸にしたMarkdown1枚の構築プロンプト。これにより、翌朝までの実装作業を人間はほぼ「次」「続行」の2語で進められたといいます。
この事例が示しているのは、プロンプト設計の力点が「何を作るか」から「どこまでを任せられるか」へ移りつつあるということです。
境界線を先に引くほど、任せられる幅が広がる
AIエージェントは基本的に「気を利かせて」機能を広げる方向に働きます。裏を返せば、Out of Scopeや厳守ルールが明文化されていれば、その範囲内でAIが自律的に判断・実装を進める余地が広がるということでもあります。今回のケースでは「実発注はしない」「前身ツールのロジックは移植する」といった一文が、深夜から早朝にかけての長時間の自律実行を成立させる土台になっています。人間が細かく口を挟まなくて済んだのは、判断に迷う余地そのものを事前に潰していたからです。
受け入れ基準は、成果を検証可能にするための投資
もう一つ見逃せないのが、受け入れ基準（Definition of Done）を独立した章として持たせている点です。AIが生成した設計書やコードをそのまま信用するのではなく、「何を満たせば完了とみなすか」を先に定義しておくことで、成果物の検証コストを下げ、次の指示に進む判断を人間が素早く下せるようになります。これは、AIに渡す作業の粒度を大きくしていくための前提条件と言えます。未決事項をあえて「未決」と書き残す運用も同様に、判断保留の範囲を明示することで、AIが誤って判断を先取りしてしまう事態を防いでいます。
プロンプトを「育てる」という発想が持つ可能性
この構築プロンプトは使い捨てではなく、運用で得た知見を書き足しながら次の開発の原本として育てられている点も特徴的です。制約と基準を中心に据えたドキュメントは、機能一覧よりも再利用・蓄積に向いています。機能は開発が進めば陳腐化しますが、境界線やルールはプロジェクトが続く限り有効であり続けるからです。
エンジニアやテックリードにとって、この事例が示す実務上の示唆は明快です。AIへの指示を「何を作ってほしいか」の一覧として書くのではなく、「どこまでは踏み込んでよく、どこからは人間の承認が要るか」を先に言語化する。その投資が、結果としてAIに渡せる作業範囲そのものを広げていく、という可能性です。
関連記事
- Co-creating the future of fashion with Google
- ゲーミングモニターのAI機能は購入判断を左右する実用機能なのか？
- Rebuilding AUTOMATIC1111 with Gradio Workflow
参考文献
コメント