AIコーディングを続けていると、最初は「情報は多いほどいい」と思いがちです。私も前は、関係しそうな会話、ファイル、前提、過去の判断をできるだけ全部渡したくなっていました。
でも、長く使うほど逆効果になる場面が増えました。情報が多いほど安心できるように見えて、実際には重要な条件が埋もれたり、過去の話に引っ張られたりします。AIだけでなく、自分の判断も鈍ります。
最近は、コンテキスト管理を「何を渡すか」だけでなく、「何を渡さないか」を決める作業として見るようになりました。今回は、AIコーディングで私がやめたことを、実務の感覚に寄せて整理します。
- AIコーディングでは、長い会話を全部引き継ぐより、今回必要な前提だけを切り出すほうが安定しやすいです。
- 情報不足だけでなく、重要度が見えない状態もAIの判断をぶらしやすくします。
- 会話を切ることは非効率ではなく、作業単位と判断基準を見えやすくする工夫になります。
やめたのは、前回の会話を全部引き継げば安心だと思うこと
長い会話には安心感があります。前提をまた説明しなくてよいですし、これまでの流れも残っているように見えます。でも、その安心感と作業の安定は同じではありませんでした。
前回の会話には、うまくいった判断だけでなく、途中でやめた案、試して失敗した案、今は不要になった条件も残っています。それを全部抱えたまま続けると、AIが古い前提を拾ったり、自分も「どれが最新だっけ」と迷ったりします。
概念としてのコンテキスト長は、以前こちらで整理しています。
今回はそこから一歩進めて、実際の作業で何をやめたのかに絞っています。
今は、前回の会話を丸ごと引き継ぐより、今回の作業に必要な前提だけを短く切り出すほうが安定すると感じています。会話を続けることより、判断に必要なものを見える形で渡すことのほうが大事でした。
特に、前回の作業で一度捨てた案や、途中で仮に置いた条件が残っていると危険です。AIがそれを最新の前提として拾うことがあります。人間側も「たしか前に話したから大丈夫」と思ってしまい、確認が甘くなります。
やめたのは、関係しそうな情報を全部入れてから始めること
以前は、関係しそうな情報をできるだけ多く渡してから作業を始めたほうが、AIが賢く判断してくれると思っていました。関連ファイル、過去ログ、ルール、参考記事、気になっていること。全部入れておけば安心だと思っていたのです。
でも、情報を全部渡すと、AIが何を優先すべきか分かりにくくなることがあります。必要な情報が足りないのも問題ですが、多すぎる情報の中で重要度が見えない状態も同じくらい危ないです。
今は、最初に渡すものを絞っています。今回の目的、対象ファイルや対象記事、守るルール、触らない範囲、完了条件。まずはこのあたりに限定して、必要になったら追加で渡すほうが、作業が散らばりにくくなりました。
- 今回の目的
- 対象ファイルや対象記事
- 守るルールや禁止事項
- 完了前に確認すること
全部を最初に渡すのではなく、最初に見るべき地図だけ渡す。そう考えると、依頼文もかなり短くできます。
やめたのは、重要度の判断までAIに丸投げすること
詰まりやすいのは、情報不足より「何が重要か見えない状態」でした。AIにたくさん情報を渡しても、どれを最優先にするかが曖昧なら、出力はそれらしくても芯がずれます。
たとえば記事修正なら、文字数、マーカー、内部リンク、Gutenberg形式、本文の自然さ、読者の判断基準など、見るべき項目はいくつもあります。全部が大事でも、順番を決めていないと、形式を満たすために本文の意味が崩れるようなことが起きます。
コード修正でも同じです。見た目を整えるのか、不具合を直すのか、既存仕様を守るのか、テストを通すのか。優先順位が曖昧なままだと、AIは目の前の修正をうまく進めてくれますが、こちらの意図とは違う方向へ進むことがあります。
だから私は、重要度の判断だけは人間側で先に置くようにしています。今回は本文の意味を最優先にする。今回は既存仕様を変えない。今回は提案だけで、書き換えはしない。こうした優先順位を出すだけで、コンテキストの使われ方が変わります。
会話を切ることは、非効率ではなく作業を戻しやすくする工夫
新しい会話を切るのは、最初は面倒に見えました。前提をまたまとめる必要があるからです。でも、実際には作業単位が分かれ、後で見返しやすくなりました。
会話を切るときは、引き継ぐ要点だけを残します。今回の目的、今決まっている方針、触ってよい範囲、触らない範囲、未解決のこと、次に確認すること。これだけあれば、新しい会話でも作業を再開しやすいです。
モノレポや文脈設計の話ともかなりつながります。
ファイル構造を整理するのと同じように、会話も作業単位で整理したほうが、後から追いやすくなります。
長い会話を続けることにこだわると、途中で起きた迷いまで次の判断に混ざります。会話を切るのは流れを捨てることではなく、必要な判断だけを持ち直すことでした。
私は会話を切る前に、最後に小さな引き継ぎメモを作るようにしています。そこに「何が決まったか」「何はまだ決まっていないか」「次にやること」を書いておくと、新しい会話に移っても作業が途切れにくくなります。
コンテキストを減らすときは、捨てるのではなく要約して残す
コンテキストを減らすといっても、全部を捨てるわけではありません。むしろ、必要なものだけを残すために要約します。ここを間違えると、情報を減らしすぎて逆に失敗します。
私が残すようにしているのは、結論、採用した理由、捨てた案、未確認のこと、次の作業です。特に「捨てた案」を残すのは大事でした。なぜやめたのかを書いておかないと、次の会話で同じ案に戻ってしまうからです。
- 今回の結論
- 採用した理由
- 採用しなかった案と理由
- まだ確認できていないこと
- 次に頼む作業
このくらいに絞ると、長いログを抱えなくても、次の判断に必要なものは残せます。コンテキストを減らすことは、記録を雑にすることではありません。むしろ、記録を使いやすくする作業に近いです。
ここで大事なのは、要約をきれいな文章にしすぎないことでした。次の作業で使うためのメモなので、短い箇条書きで十分です。むしろ、見栄えを整えるより、判断に必要な条件が落ちていないかを優先しています。
次は会話を切る基準と、引き継ぎテンプレートを残したい
今回わかったのは、コンテキスト管理は「長く続ける技術」だけではないということです。必要な情報を残し、不要になった情報を切り、重要度を見えるようにする。そうしないと、会話が長いほど判断がぼやけます。
次にやりたいのは、会話を切り替える基準と、引き継ぐ要点のテンプレート化です。何分続いたら切る、何回同じ修正をしたら切る、前提が変わったら切る。そういう基準があると、迷いながら長い会話を引っ張ることが減ります。
あわせて、コンテキストを減らしたほうがうまくいった実例と、逆に不足して失敗した実例も並べて見たいです。減らせば必ずよいわけではないので、どの情報は残すべきかも見直す必要があります。
たとえば、作業対象のファイル名や記事IDは残すべき情報です。一方で、もう採用しない案の長い説明や、途中の雑談に近いメモは減らしてもよいかもしれません。この線引きを実例で見たいです。
AIコーディングを静かに進めるには、全部を抱え込むより、今の作業に必要なものを選び直すほうが合っていました。続ける工夫だけでなく、切る工夫も持っておく。これが、今の私にとってのコンテキスト管理です。情報を増やすより、今見るべきものを選び直すほうが、長い作業では効きました。次の依頼も、その前提で短く始められます。迷いも減ります。確認も楽になります。後戻りも減ります。
