背景
もうずっと。そうですね1年以上。コーディングエージェント（私の場合は GitHub Copilot）にかなりの量のタスクを投げています。
Template化しているPromptはこちらのBlog Postでも共有しました。
機能の実装、バグの根本原因の調査、設計の見直し。気づけば一日の作業の多くが「エージェントへの依頼文を書く」ことに変わってきました。
そんな中で、ふと違和感がありました。
同じ「お願い」でも、サッと一言で終わるものもあれば、何往復もして、しかも途中で「いったんレビューして」と差し込むものもある。自分の中で、無意識に「頼み方の型」を使い分けているような気がしたんです。
正直、これは感覚の話でした。なので、せっかくなら自分のチャット履歴を実際に集計して、その「型」が本当に存在するのかを確かめてみることにしました。
ついでに言うと、今回これができたのは、特別なことをしたからではありません。普段のチャット履歴が手元に残っていた、ただそれだけです。
正直、履歴なんて流れて消えていくものだと思っていました。でも、過去の自分のやり取りがデータとして残っていたからこそ、今日それを並べて「型」を数えられた。リアルタイムの感覚だけでは、こうはいきません。私も最初から型を意識していたわけではなく、後から見て初めて気づいたクチです。
この記事は、その振り返りの記録です。
注意点 / 前提
先に、いくつか断っておきます。
- これは私個人のチャット履歴を分析した、個人の見解です。一般論として言い切るものではありません。
- 分析できたのは、手元の端末に残っていたローカルのセッション履歴だけです。クラウド同期側は分析時にうまく取得できなかったため、他のデバイス分は含まれていません。つまり「私の全活動」ではなく「ある期間・ある端末の活動」のサンプルです。
- 集計対象は、ある約10日間の23セッション（うち中身のあるもの19件）でした。母数としては小さいです。
- なので、ここで出てくる「型」は、プロダクションのチーム運用にそのまま当てはめられるものではありません。あくまで、自分のプロンプトの傾向を観察した結果として読んでください。
ここを最初に置いておかないと、後半が「こうすべき」という押し付けに見えてしまうので、先に明確にしておきます。
整理・考え方
本題に入る前に、用語と切り分けを一度そろえておきます。
今回の分類の軸になったのは、私が依頼文の中でよく使う 「敵対的レビュー」 という指示です。
これは「あなたは今からこの成果物の作成者ではなく、敵対的レビュアーとして振る舞ってください。作成者の意図に共感せず、問題の発見に集中してください」というような、わざと粗探しをさせるレビューを指示するものです。自分が作ったもの（あるいはエージェントが作ったもの）を、いったん突き放して点検させる狙いがあります。
履歴を見ると、この「敵対的レビュー」が出てくるパターンは大きく2種類ありました。
- 独立ペルソナ型：「この設計書に対して、敵対的レビュアーとして振る舞って」と、レビューだけを単独のステップとして切り出すもの
- ワークフロー指示型：「タスクを1つずつ実行して、1つ終わるたびに必ず敵対的レビューを行って、その結果を反映してから次へ進んで」と、実行プロセスの中に埋め込むもの
そのうえで、私のタスクを3つに切り分けてみました。
- 簡単：敵対的レビューを一度も挟んでいない
- 複雑：敵対的レビューを1回以上挟んでいる
- 最難易度：似たテーマを何度も往復しつつ、しかも**「作った計画そのもの」をレビュー対象にしている**
ここで大事なのは、「何が複雑さの境目なのか」を切り分けることです。
私の場合、複雑さを決めていたのは「タスクそのものの大きさ」よりも、むしろ**「どれだけ自分の出力を疑ってかかったか」**でした。レビューを挟むかどうか、そして何をレビュー対象にするか。そこに型が出ていました。
逆に言うと、「ターン数が多い＝難しい」とは限りません。実際、20往復もしたセッションが最難易度だったわけではなく、4〜6往復のものが一番手厚い手順を踏んでいたりします。ここは後で具体例で見ていきます。
本文：3つの型と、その具体例
では、実際の依頼文（自分が書いたもの）を引きながら見ていきます。
型1：簡単 ― 単発で投げて、単発で返ってくる
一番多かったわけではないですが、わかりやすいのがこれです。敵対的レビューは登場しません。
具体例として、こういう依頼がありました。
「ターミナルの実行時にエラーが発生しました。根本原因を調査してください。」
これ、1往復で終わっています。
ほかにも「Windows の setup スクリプトの後でパッケージが足りないようなので、すぐ起動できるようにして」といった、その場で直してほしい系もここに入ります。
特徴を整理すると、こうなります。
- ターン数が極端に少ない（このグループの平均は1.5往復）
- 「調査して」「教えて」「直して」で完結する
- 成果物をわざわざ点検し直すステップを挟まない
もう少し具体的に、私以外の人がそのまま使える形にすると、こんな依頼になります。
setup スクリプトを実行したら、パッケージが1つ足りずにアプリが起動しませんでした。
原因を調査して、すぐ起動できる状態にしてください。
- 結論と理由を先に教えてください
捏造は禁止です。わからない点は「不明」と明記してください。
ポイントは、段取りを足していないことです。レビューも、計画フェーズも、わざと入れていません。答えがすぐ確かめられるタスクなので、これで十分なんです。
なぜこう頼むのかを自分なりに考えると、答えが一意に決まる、あるいは間違っていてもすぐ気づける種類のタスクだからです。リスクが低いので、わざわざレビューの手間をかけない。これは自然な判断だと思います。
実務への影響でいうと、ここで重要なのは「簡単なタスクにまでレビューを盛らない」ことです。なんでもかんでも厳密な手順を踏ませると、単純に遅くなります。軽いタスクは軽く投げる。これはこれで合理的です。
ただし注意もあります。「調査だけ」のつもりで投げた依頼が、実は奥が深かった、というのは現場ではよくあります。後述しますが、実際に私の履歴でも、最初は軽い調査だったものが、後日もっと重い対応に育っていったケースがありました。
型2：複雑 ― 「まだ直さないで」と一度止める
中身のあるセッションの約7割がここでした。つまり、私が普段やっているタスクの多くは、軽いお願いではなく、レビューを挟むものだったわけです。これは自分でも少し意外でした。
具体例です。GUI アプリの挙動を調べたときの依頼がこうでした。
「実行中に警告が表示されています。詳細な根本原因を調査してください。まだ修正はしないでください。 捏造は絶対に禁止です。」
ポイントは「まだ修正はしないでください」です。
私はここで、いったんエージェントの手を止めて、調査結果を確かめてから次に進むという型を使っています。そして実装に入った後も、「1つタスクが終わるたびに敵対的レビューを行って、その結果を反映してから次へ」と、レビューをプロセスに織り込んでいました。
このグループの特徴はこうです。
- 平均で7往復くらい。段階的に進む
- 「調査 → いったん止める → 計画 → 実行」というゲートを置く
- 実行の途中、あるいは節目でレビューを挟む
これも、そのまま使える形に起こすとこうなります。型1との違いは、「まだ直さないで」というゲートと、実行中のレビューが入っている点です。
管理画面を開くたびに、コンソールに警告が出ます。詳細な根本原因を調査してください。
まだ修正はしないでください。捏造は禁止です。
- まず原因の見立てと、該当しそうなファイルを教えてください
- 私が確認したら、修正プランを作ってください
- 実装は1つずつ進め、各ステップの完了ごとに敵対的レビューを挟み、結果を反映してから次へ進んでください
なぜこう頼むのか。機能実装やバグの根本原因の調査は、最初の見立てが外れると、その上に積んだ作業が全部やり直しになります。だから「土台が合っているか」を一度確認したい。気持ちとしては、コードレビューの前に設計を確認するのと同じ感覚です。
実務への影響としては、この「まだ直さないで」の一言がけっこう効きます。エージェントは放っておくと気を利かせて先に進んでしまうことがあるので、調査と実装の間に明示的な区切りを入れるだけで、手戻りが減ります。とはいえ、毎回これをやると重いので、リスクのあるタスクに絞るのが現実的だと思います。
型3：最難易度 ― 「作った計画そのもの」をレビューさせる
ここが今回いちばん面白かった発見です。
複雑タスクの中でも、ごく少数だけ、明らかに他と違う手順を踏んでいるものがありました。件数でいうと3〜4件。10日間の中でこれだけです。
何が違うのか。レビューの対象が「成果物」ではなく「計画」だったんです。
具体例を2つ挙げます。どちらも自分が書いた依頼文の原文です。
「作成した修正プランについて、あなたは今から敵対的レビュアーとして振る舞ってください。」
「作成した修正プランを対象に、あなたは今から敵対的レビュアーとして振る舞ってください。」
もう一つ、設計書を相手にしたものもありました。
「更新した設計書に対して、あなたは今から敵対的レビュアーとして振る舞ってください。」
普通、レビューは「できあがったもの」に対して行います。でもここでは、まだ実装に入る前の「計画」や「設計」の段階で、それを突き放して点検させているわけです。
このグループのタスクは、だいたい次のような流れになっていました。
- まず調査する
- 調査結果をレビューする
- 詳細な実装・修正プランを作る
- そのプランそのものをレビューする（←ここが型3だけの特徴）
- （自分が確認してから）実行に入る
- 実行結果を全部レビューする
4番が、型2と型3を分ける決定的な違いでした。
これも、そのまま使える形にするとこうなります。型2との違いは、実装に入る前に「プランそのもの」を敵対的レビューさせているところ、そして最後に全体の結果ももう一度レビューさせているところです。
○○ワークフローの作業フォルダの入出力が、ステップ間で食い違っているようです。
最終的に堅牢に直したいです。捏造は禁止、存在しない問題は挙げないでください。
- まず整合が取れていない箇所を調査して、修正プランを work/plans/ にファイルで作ってください
- そのプラン本文を対象に、あなたは敵対的レビュアーとして問題を洗い出してください
- 私がプランを確認・指示してから、1つずつ実装し、各完了ごとに敵対的レビューをして反映してください
- 最後に、全体の実行結果をもう一度敵対的にレビューしてください
なぜここまでやるのか。対象が、ワークフローの基盤そのものだったからだと思います。一度作って動かし始めると、後から土台を変えるのが非常に高くつく領域です。だから「実装する前に、計画の段階で叩いておく」価値がある。逆に言えば、毎回ここまでやる必要はなくて、影響範囲が広いものに限って手間をかけている、ということです。
実務への影響として、これは「計画のレビュー」という考え方が効くケースがある、という話につながります。コードのレビューは当たり前にやりますが、計画のレビューは意外と省略されがちです。手戻りのコストが大きい仕事ほど、前倒しで疑っておく。これは人間同士の設計レビューでも同じだと思います。
なお、似たテーマが何度も登場していた点も、型3の背景にあります。たとえば、同じワークフロー（私の環境でいう ASDW-WEB という処理）に関する依頼が、計画づくり・エラー対応・修正と、複数のセッションに分かれて繰り返し出てきていました。「一発で終わらず、何度も向き合っているテーマ」ほど、計画のレビューまで踏み込んでいた、というのは納得感があります。
一方で、面白い反例もありました。「Session State の実装を調査して、修正プランも作って」という依頼は何度も繰り返していたのに、敵対的レビューは挟んでいませんでした。つまり、「繰り返している」だけでは型3にならない。繰り返し、かつ計画そのものを疑う、その両方がそろって初めて最難易度になっていたわけです。
そして、履歴を並べて初めて見えた反省もありました。型3のような重いセッションほど、調査で読んだログやファイルを抱えたまま最後まで走らせていて、途中で一度も整理し直していなかったんです。当時は気づきようがなかった。後からデータとして眺めて、ようやく見えた話です。これは次の章で少し触れます。
ここまでの整理
いったん、ここまでを箇条書きでまとめます。
良い点（自分の型として機能していたこと）
- 「敵対的レビューを挟むかどうか」が、タスクの重さの実用的な目印になっていた
- リスクの低いタスクは軽く、重いタスクはレビューを挟む、という使い分けが自然にできていた
- 最難易度では「計画そのものを点検する」という、手戻り防止に効く手順を踏めていた
注意点
- これは自分のプロンプトの傾向であって、誰にでも当てはまる分類ではありません
- ターン数の多さは難しさと一致しません。手順の質のほうが効いていました
- 「簡単」に分類したものが、後から重いタスクに育つこともありました
限界
- 母数が小さく（中身のあるセッション19件）、期間も短いです
- ローカル履歴のみで、他デバイス分は含まれていません
- プロンプトの文面から分類しているので、エージェントが実際にどう動いたかまでは見ていません
この3点を意識しておかないと、「型に当てはめれば大丈夫」という話に滑ってしまいます。型は万能ではありません。
最初の一手：タスクの難易度を、先に仕分けるプロンプト
ここまでで「型」と、それを分ける軸（手戻りの大きさ、計画そのものをレビューするか）が出そろいました。せっかくなので、これをいちばん最初の一手にしておきます。つまり、「xxx の機能を追加して」「yyy のエラーの原因を調査して」と投げる前に、そのタスクがどの型かを先に判定させるわけです。
正直、個別のテクニックより、この「最初の仕分け」がいちばん効く気がしています。重さを見誤って軽いタスクに重い段取りを盛ると遅くなるし、逆に重いタスクを軽く投げると手戻りで余計に時間がかかる。だから実装に入る前に一度だけ難易度を判定させて、それに合った手順を選ぶ。そういう使い方を想定したプロンプトです。
これから私が「○○の機能を追加して」「○○のエラーの原因を調査して」といったタスクを伝えます。
実装や調査に入る前に、まずそのタスクの難易度を次の3つに分類し、理由を1〜2行で添えてください。
判定軸（上から優先）:
1. 失敗したときの手戻りの大きさ。やり直しのコストは小さいか、大きいか
2. 答えがほぼ一意に決まるか／間違ってもすぐ気づけるか
3. 計画や設計の土台に関わるか。影響範囲は広いか
4. 同じテーマを何度も触っているか（繰り返している領域か）
分類:
- シンプル: 答えがほぼ一意、またはすぐ気づける。手戻りが小さい単発の調査・即時修正。レビューは不要
- 複雑: 見立てが外れると手戻りが大きい。実装や根本原因の調査。途中でレビューを挟む価値がある
- 超複雑: 土台・基盤に関わり影響範囲が広い、または繰り返し触っているテーマ。計画そのものをレビューする価値がある
出力フォーマット:
- 難易度: シンプル / 複雑 / 超複雑
- 理由: （1〜2行）
- 推奨の進め方: （この難易度に対応する段取りをひとことで）
判定だけを先に返してください。私が確認してから、その難易度に合った手順で進めます。捏造は禁止です。
この判定が返ってきたら、あとは難易度に応じた段取りを順に流すだけです。記事の最後に置いた「シンプル版／複雑版／超複雑版」のテンプレートが、ちょうどその「難易度ごとの段取り」にあたります。判定 → 対応するテンプレを選ぶ → ステップ順にキューへ積んで実行、という形にしておくと、毎回ゼロから依頼文を組み立てずに済みます。
とはいえ、判定はあくまで出発点です。実務では話が変わることも多いので、ズレを感じたら手で上げ下げすればいい。最初の仕分けを一回挟むだけで、後の段取りがだいぶ素直になります。
これから直したい点（履歴が教えてくれた伸びしろ）
同じ履歴は、分類だけでなく「自分の非効率」も映し出してくれました。どれも能力の問題ではなく、文脈（エージェントに渡している会話の中身）の扱い方の癖です。そして面白いことに、直し方はどれも「次から、こういう一言を足す」だけで済みました。せっかくなので、当時の自分の状態と、これから足すつもりのプロンプトをセットで残しておきます。
1. 長く続いたセッションを、途中で畳む
当時の私は、20往復・60ファイル超に膨らんだセッションを、一度も要約せず最後まで走らせていました。履歴を見ると、文脈を畳んだ形跡（コンパクション）はゼロ。重いものほど、過去のやり取りを全部抱えたまま進めていたわけです。これは毎回、過去ログを丸ごと運び直しているのと同じで、後半ほど重くなります。
VS Code のチャットなら、節目で /compact を打つ。プロンプトで畳むなら、こう一言入れます。
ここまでの内容を、これからの実装に必要な結論・決定事項・参照パスだけに要約してください。
ログ全文や探索の途中経過は省いて構いません。以降はその要約だけを前提に続けてください。
2. 広い調査は、サブエージェントに任せて結論だけ受け取る
「全ワークフローの入出力を調べて」のような広い調査を、私はメインの会話に全部流し込んでいました。あるセッションは4往復で46ファイルを読んでいて、その中身がぜんぶ会話に居座っていたんです。
ここは、調査だけ別の担当（サブエージェント）に投げて、結論だけ受け取る形にします。
この調査はサブエージェント（Explore）に委譲してください。
返してほしいのは (1) 結論 (2) 該当ファイルと役割 (3) 原因の候補 だけです。
読んだファイルの全文はメインの会話に持ち込まないでください。捏造は禁止です。
3. 巨大なログは「貼らない」。ファイルに置いて参照させる
これは正直、いちばん恥ずかしい癖でした。2万字を超えるログを、隣り合うやり取りで二度貼っていた跡が残っていたんです。貼り付けたテキストは、その後の会話にずっと居座って、毎回運ばれ続けます。
なので、長いログはファイルに置いて、パスだけ渡すようにします。
エラーログは work/logs/warning-2026-06-12.log に保存しました。全文を会話に貼らないでください。
このファイルを読み、関係する箇所（末尾のスタックトレース付近）だけ引用して進めてください。
4. 同じテーマは、仕切り直さず「結論」を残して引き継ぐ
同じ依頼文と、同じ5千字ほどのログを、2時間後に別のセッションでもう一度貼り直して、ゼロから始めていたことがありました。再ペーストの重さと、再調査の時間。二重に損をしていたわけです。
調べたら、結論を短いメモに固定しておく。次回はそれを読めば済みます。
ここまでの調査結論を work/notes/warning-findings.md に書き出してください。
粒度は「別セッションから読んで作業を再開できる」レベルで、
原因・影響範囲・次の一手・参照ファイルパスに絞ってください。
5. 毎回探し直す中核ファイルは、最初に「地図」を渡す
履歴を横断して見ると、同じファイルを毎回ゼロから探し直していました。実行系の中核ファイルは10ものセッションで、ほかの中核ファイルも7〜8セッションで、そのつど探索からやり直していたんです。
これは、最初に「起点はここ」と地図を渡すだけで、探索のフェーズを丸ごと飛ばせます。
作業に入る前に、今回触る領域の起点ファイルだけ確認します（私の環境での例です）。
- GUI ページ実装: hve/gui/page_workbench.py
- ワークフロー実行: hve/runner.py
- DAG 統括: hve/orchestrator.py
これら以外を広く探索する前に、まずこの3つを起点に見てください。関係なければ「対象外」と言ってください。
正直、どれも「言われれば当たり前」です。とはいえ、当たり前を毎回できているかは別の話で、私はできていませんでした。逆に言えば、ここは直せば待ち時間も手戻りも減らせる、わかりやすい伸びしろです。そして念のため繰り返すと、これも履歴が残っていなければ、一つも気づけませんでした。
ひとつ補足を。これらは型2・型3のような、長く重いタスク向けです。型1の一言で終わる調査にまで持ち込むと、かえって段取りが増えて遅くなります。重いものにだけ、必要な分だけ。ここは前半の「軽いものは軽く」と同じ考え方です。
まとめ
自分のチャット履歴を振り返って分かったのは、複雑さを決めていたのは**タスクの大きさそのものではなく、「どれだけ自分の出力を疑ってかかったか」**だった、ということでした。
- 軽いものは、軽く投げる
- 失敗の手戻りが大きいものは、調査と実装の間に区切りを入れる
- 土台に関わるものは、実装前に「計画そのもの」をレビューする
並べてみると当たり前のことばかりです。でも、当たり前を毎回ちゃんと選べているかは別の話で、私はわりと無意識にやっていました。今回それが可視化できたのは収穫でした。
エージェントを使う頻度が上がるほど、「どう実装させるか」と同じくらい「どう頼むか」が効いてきます。とはいえ、いきなり厳密な手順を全部に適用する必要はありません。まずは「このタスク、調査と実装の間に一回止めたほうがいいかな?」と一拍置くところから始めれば十分だと思います。
もう一つ、今回いちばん伝えたいことがあります。
この振り返りができたのは、頼み方が上手かったからではありません。過去のチャット履歴が、データとして残っていたからです。プロンプトの工夫はもちろん大事です。でも、その工夫が本当に効いていたかを後から確かめるには、記録がいります。記録がなければ、改善はいつも「なんとなくの記憶」頼みになってしまう。
私は完璧な使い方をしているわけではなく、今もはっきり成長の途中です。だからこそ、「履歴を残す → 後で分類する → 改善点を洗い出す → 次に活かす」というサイクルが回せること自体に価値があると感じています。今日やったのは、ちょうどその一周目でした。
プロンプトのうまさは、一回ごとの勝負です。一方で、履歴をデータとして貯めておくことは、その勝負を後から何度でも見直せる資産に変えてくれます。実際には、後者のほうが効いてくる場面が多いのかもしれません。
もし興味があれば、ご自身のチャット履歴も一度眺めてみてください。自分がどんな「頼み方の型」を持っているのか、そしてどこに伸びしろがあるのか、思っていたものと違っていて、けっこう面白いはずです。まずはここまでで十分です。
おまけ：そのまま使える汎用プロンプト3種
最後に、ここまでの話を「そのままコピペで使える」形にしておきます。タスクの重さに合わせて、シンプル版・複雑版・超複雑版の3つです。
注意点をひとつ。シンプル版にわざと余計な手順を入れていないのは、軽いタスクに重い段取りを持ち込むと遅くなるからです。重さに合わせて選んでください。角カッコ ［ ］ は自分の対象に置き換えて使います。
シンプル版（型1：軽い調査・即時の確認）
［対象・エラー内容］について調査してください。
- 結論と理由を先に教えてください
- 必要なら、直す方針も
捏造は禁止です。わからない点は「不明」と明記してください。
複雑版（型2：調査 → いったん止める → 計画 → レビューしながら実行）
［対象］について、詳細な根本原因を調査してください。まだ修正はしないでください。捏造は禁止です。
進め方:
1. 広い調査はサブエージェント（Explore）に委譲し、結論・該当ファイル・原因候補だけ返してください
2. 長いログは会話に貼らず、work/logs/ に置いたファイルを参照してください
3. 調査結論を私が確認したら、修正プランを作成してください
4. 実装は1つずつ進め、各完了ごとに敵対的レビューを行い、結果を反映してから次へ進んでください
やり取りが長くなったら、節目で「結論・決定事項・参照パス」だけに要約してください。
超複雑版（型3：計画そのものもレビューし、結果もレビューする6段）
［対象］について、最終的に堅牢な実装まで進めたいです。捏造は禁止、存在しない問題は挙げないでください。
■ 調査
- 範囲が広いのでサブエージェント（Explore）に委譲。結論・該当ファイル/行・原因仮説だけ返してください
- ログは会話に貼らず、work/logs/ のファイルを参照してください
■ プラン
- 詳細な修正／実装プランは work/plans/xxxx.md にファイルとして出力してください
- プランをレビューする前に、調査フェーズの途中経過とログは要約に畳んでください
- そのプラン本文を対象に、あなたは敵対的レビュアーとして問題を洗い出してください
■ 実行（私がプランを確認・指示してから）
- 1つずつ実行し、各完了ごとに敵対的レビュー → 反映 → 次へ
- 1つの波が終わるたび、実行ログは結論だけに要約して畳んでください
- 重い再調査が要るサブタスクは、サブエージェントに投げて結論だけ戻してください
■ 仕上げ
- 実行結果のログは work/logs/ を参照（貼らない）。失敗・警告のあった箇所だけ引用し、全体を敵対的にレビューしてください
この3つは、あくまで出発点です。実際には対象によって増えたり減ったりしますし、毎回フルで使う必要もありません。とはいえ、手元に「重さ別のたたき台」があるだけで、毎回ゼロから依頼文を組み立てる手間は減ります。
そして、このたたき台自体も、過去の履歴を並べたから書けたものです。記録を残しておくと、こうして後から「次に使える形」に変えられる。今日いちばん実感したのは、結局そこでした。