GPT-5.6で巨大なプロンプトを書くのをやめた。短い指示で調査と実装を任せた結果

GPT-5.6向けのプロンプトを考えていた時、GPT自身に案を出してもらいました。

返ってきたのは、かなり長いプロンプトでした。役割、調査手順、使うツール、回答形式、実装前の確認、検証方法などが細かく並んでいます。

しかも、これをAIに作らせるだけでもトークンを使う。GitHub Copilotを使う時はAI Credits（AIC）も消費する。まだ調査も実装も始まっていないのに、プロンプトを考えるだけでコストがかかるのが、余計に損した気分でした。

さらに、GitHub Copilotは2026年6月1日からAI Creditsによる従量課金へ変わりました。仕事で使える予算にも上限があります。使いすぎないよう、何にAI Creditsを使うかまで考えなければならない。必要な調査や実装ならまだしも、その前段の長大なプロンプトを作るだけでAI Creditsが減っていく。これはもう、「損した気分」で済む話ではありません。死活問題でした。

これを毎回書かないといけないのか。正直、「すごい面倒くさい」と思いました。AIに作業を任せるために、毎回この長さの指示を整えるのは、なんか違う。

SKILLにも「このMCPを実行して、この順番で分析して、回答にはこれを詳細に書く」と詰め込んでいくと、AIに仕事を頼んでいるというより、日本語でプログラミングしているように感じました。しかも、そこまで手順を固定した結果、次の指示に応用が効かなかったり、指示にない分析をしなくなったりする。単純に私の手間が増えていました。

今は、巨大なプロンプトを作る方向から離れています。

GPT-5.6では、細かな作業手順を全部書くより、ゴール、参照してほしいもの、守ってほしい境界を短く渡す方が、私の仕事ではうまく回っています。

OpenAI公式が示しているプロンプトの要点

OpenAIのGPT-5.6向けModel guidanceを読むと、重複した指示や例は減らし、ツールの説明も短くする、とあります。GPT-5.6はコンテキストから目的や求められる作業レベルを推測しやすい。だから、多くの場合、すべての手順を一つずつ書く必要はない。

Pro modeの説明には、結果に焦点を当てたプロンプトとして、次の6項目が並んでいます。

  • 目的
  • 関連するコンテキスト
  • 制約
  • 必要な根拠
  • 成功条件
  • 出力形式

とはいえ、毎回6項目をきっちり埋める話ではないです。ドメインの前提、外せない制約、承認境界、成功条件は伝える。重要な曖昧さがあれば質問させる。公式ガイドでは、そのあたりを残すよう案内しています。

短い依頼を3つ試した

仕事では、GitHub CopilotでGPT-5.6 Lunaをメインに使い、画面や既存コードの調査をさせています。

詳細検索機能の追加

例えば、機能追加を考えていた時に渡した指示は、この程度です。

コンテキストに含めた画面と集計処理に、詳細検索機能を追加したい。現コードベースを調査し、現在の設計と実装を分析したうえで、適切に機能追加するための案を3つ提案して。リスクと推奨度もまとめて。

この短い依頼を、OpenAI公式の6項目で整理すると次のようになります。

項目 この依頼で書いていたこと
目的 詳細検索機能を追加したい
関連するコンテキスト コンテキストに含めた画面と集計処理、現コードベース、現在の設計と実装
制約 明示的なハード制約はない
必要な根拠 現コードベースの調査結果、設計と実装の分析
成功条件 適切な機能追加案を比較・検討できる
出力形式 修正案3つ、各案のリスクと推奨度

当時、必要な根拠や成功条件まで考えていたかというと、そこまでは考えていませんでした。あとから6項目に当てはめると、「調査・分析したうえで」「適切に機能追加するための案」がここに入ります。

「提案して」と書いたので、当然、提案で止まると思っていました。でも、「実装しない」とは書いていない。あとで調査だけのつもりが修正まで進んだことを考えると、「今回は提案まで。実装やファイル変更はしない」まで書いた方がよさそうです。

グラフ表示の不具合

別の不具合では、次のように頼みました。

コンテキストに含めた画面で、グラフ表示に不具合がある。ゴールであるExcel帳票と同等の表示にする方法を調査し、修正案を計画して。根本原因も説明して。

「このファイルを開いて、このクラスを検索して、この順番で処理を追って」とは書いていません。それでも、関連コードを調べ、現在の設計を読み、原因と修正候補をまとめてくれました。最初の回答が外れていた時も、検証結果を返すともう一度調べ直し、修正案を更新してくれました。

Lunaは、GPT-5.6系ではコスト重視のモデルです。公式には大量処理向け。それでも、私が使った範囲では「細かな手順を全部教えないと動けない」という感じはありませんでした。

Excelを正解として、AI自身に差異を調べさせる

特にビックリしたのは、既存のExcel帳票と同じものを出力する対応です。

この時は、次のように依頼しました。

ゴールとして渡した帳票（Excel）と同じ内容を出力したい。フォント、セルの位置、文字の大きさ、改ページ、グラフについて、現状のExcelと比較して差異を調査し、修正点をまとめて。まとめ終わったら修正を実装して。

この時に書いたのは、何を正解にするか、どこを見るか、修正まで進めてよいか。そこまでです。

AIはExcelを分析するためのプログラムを作り、1セルずつ、何が入っているかを数式込みで一覧にしたようでした。その一覧を使って既存の出力とゴールを比較し、差異を調べて修正に進みました。

しかも、調査から修正まで1時間ほどでした。途中で一覧を作って終わるのではなく、差異を特定し、修正し、最後までやり切った。ここは本当にビックリしました。

実際、グラフでは補助線やタイトル、X軸・Y軸の文言、線の描画などが不足していました。出力処理のコードだけを眺めて「同じようにして」と頼むより、正解となる帳票を渡して差異を調べさせる方が具体的でした。

画面の見た目でも、同じように差異を出させています。ゴールとなる画面と現在の画面を渡し、レイアウトや操作の差を洗い出させる。UI/UX上の改善点を先に列挙させ、どれを直すかはその後で判断する。自分では見落としていた違和感まで、候補に上がってきます。

細かく指示するより、正解を渡す方が使いやすかった

以前は、プロンプトやSKILLへ詳細な作業手順を書けば、回答の精度も上がると思っていました。

ところが、手順を細かく固定するほど、想定したケースにしか対応できなくなりました。MCPを呼ぶこと自体が目的になったり、指示した形式で回答を埋めることが優先されたりする。新しい状況が出るたびに、また指示を追加する必要もあります。

短くしても、ここは残しています。

  • 実現したい機能や修正内容
  • ゴールにするExcel帳票や画面
  • 比較・確認する項目（フォント、セル位置、文字サイズ、改ページ、グラフなど）
  • 調査だけで止めるか、実装まで進めるか

もちろん、丸投げではないです。ゴールにする帳票や画面、比較する項目、外せない条件、どこまでやってよいか。そこは書く。調べ方やツールの選び方までは、GPT-5.6に任せています。

プロンプトの外に置いていた情報

短い指示で進んだのは、プロンプトが短かったからだけではないと思います。リポジトリにはSKILL、README、設計書がある。必要ならAIが読める状態でした。だから、既存処理のルールや設計上の前提を、毎回プロンプトへ全部書き直す必要は特になかったです。

仕事で使っているGitHub Copilotでは、.github/copilot-instructions.mdやAGENTS.mdに、プロジェクト固有の指示を置いています。GitHub公式でも、利用環境に応じてこれらをカスタム指示として使えると案内されています。Skillsは、繰り返す作業を指示や参照資料、スクリプトと一緒に持たせ、必要な時だけ読み込ませる仕組みです。毎回長いプロンプトを貼らずに済むのは、こうした置き場所があるからでもあります。

READMEや設計書も同じです。公式の例でも、変更したコードやテスト、既存ドキュメント、PRの背景を突き合わせ、必要な範囲だけ更新する流れになっています。大きなコードベースを調べる時も、関連するファイルや機能範囲を手がかりに、処理の流れや影響範囲まで追う。毎回、私が全部を説明する前提ではありません。

短い指示で調査を任せられたのは、AIが参照できる前提を別の場所に置いていたからでもありそうです。

もちろん、何の知識もないまま、この形にたどり着いたわけではないです。OpenAIの公式ブログを参考にした記事などを読んでいて、目的や前提、制約を渡す考え方は多少知っていました。その下地があったから、短い指示でも意図を伝えられた部分はあります。

「原因を調査して」で修正まで進んだ

短い指示に変えて、困ったこともあります。

不具合原因の調査を頼んだ時、原因と修正案を見ながら壁打ちするつもりでした。ところが、AIはそのままコードまで直した。ここは想定と違いました。

私としては「調査して」としか書いていない。実装を頼んだつもりはありません。でも、どこで止まるかも書いていませんでした。GPT-5.6はゴール達成に修正が必要だと判断すると、そのまま進むことがあります。

長いプロンプトへ戻す必要はありませんでした。次の一文を足せば済みます。

今回は調査と提案まで。実装やファイル変更は、私が修正案を確認してから行って。

OpenAIの公式ガイドにも、調査、計画、修正ごとに、どこまで行動してよいかを決める、とあります。ここは、巨大な手順書より大事でした。

作業は任せるが、最後の判断までは渡さない

今の線引きは、こんな感じです。

コーディング、単体テストやCIの実行、ドキュメントの作成と修正、コードや帳票の調査は任せる。調査などの作業は、AIの方が自分で行うより速い。検証で問題が見つかれば、その結果を使って再修正もできます。

一方で、修正提案や調査結果の確認、コードレビュー、設計判断、最終的な検証は自分で行います。実画面を使ったデバッグ、結合テスト、操作感の確認まで、AIの回答だけで完了にはできません。

単体テストが通っていても、既存処理の不具合やパフォーマンスへの影響が残ることがあります。以前、AIのリファクタリング案を採用し、単体テストを通過したのに画面遷移や保存処理を壊した経験もあります。その時の失敗は、AIリファクタリングでシステムが壊れたに残しています。

Lunaで調査し、最後に上位モデルでレビューする使い分けについては、Geminiに課金しながらGPTをメインに使う理由にも書きました。今回プロンプトを減らせたのは、その運用を繰り返す中で、モデルに任せてもよい部分と自分が見る部分が分かれてきたからでもあります。

必要だったのは、巨大なプロンプトではなかった

プロンプトを短くすれば、常に良い結果になるとは思っていません。Excel帳票で外せない比較項目があるなら書くし、変更してはいけない処理があるなら制約として残します。

それでも、使うMCP、調査の順番、回答の書き方、実装の手順まで毎回指定するのはやめました。新しいモデルが自分で調査し、比較し、検証できる部分まで私が日本語でプログラミングする必要はないと感じたからです。

今プロンプトに書くのは、ゴール、正解として見てほしい帳票や画面、外せない条件、どこまで進めてよいか。このくらいです。

実装や調査はAIに任せる。ただし、設計判断と実際に動かした結果には自分で責任を持つ。この分け方が、現時点では一番しっくりきています。

参考資料

コメント

タイトルとURLをコピーしました