こんにちは。AIサービス開発に没頭している非エンジニアの私です。
前回の記事で紹介した「３つのプロンプト」を手がかりに、昨日から試しに新しい金融系サービスの開発を始めました。 ところが、始めてすぐに AI 開発ではよくある「コンテキストの壁」にぶつかります。 しかも、「ここはもう対策済みだろう」と思っていた箇所で問題が再発し、自分の想定の甘さがはっきりしました。
今日は、Claude Codeを使った開発における「コンテキストの圧縮やリセットと再開」の重要性と、そこから得られた「申し送り」の極意について共有します。
昨日からやっていたこと（目的）
開発環境は前回同様、CursorのターミナルでClaude Codeを呼び出し、直接指示を書き込むスタイルです。 私が作成した「3つのプロンプト」を順に投げ、初期リポジトリを一気に生成。その後、サービス実装のためにタスクを順次消化していく……という、完璧なフローのはずでした。
今回のターゲットは金融系のサービス。計算ロジックやデータ構造が少し複雑なため、AIへの指示も慎重に行う必要がありました。
どこで詰まったか（失敗・ハマりポイント）
ひとつのタスクを終えた時点で、コンテキスト（AIの記憶容量）の消費量を確認しました。すると……。
「消費量：90%」
なんと、たった1回のタスクで容量のほとんどを使い切っていたのです。 これでは次のタスクで確実にメモリ不足になります。そこで私は、Claude Codeのコマンドである `/compact` や `/clear` を使い、これまでの会話履歴を圧縮・消去して、メモリを回復させることにしました。
実は、この手順自体は想定内でした。事前に `.cursor/rules`（AIへの指示書）にも、「圧縮・消去後は、必要な情報だけを読み込んでスムーズに再開すること」と指示を書いていたつもりだったのです。
しかし、いざ再開してみると……。
「現状を把握するために、リポジトリ内のファイルを片っ端から読み込み始める」
「あれれ、これじゃいかん！」
私の指示がうまく機能しておらず、AIは記憶を失った不安からか、手当たり次第にファイルを読み込み始めました。結果、その読み込み作業だけで再びコンテキストを大量消費。「メモリを節約するためにリセットしたのに、再起動で浪費する」という、本末転倒な状態に陥ってしまったのです。
どう考え、何を試したか（試行錯誤のプロセス）
ここで一度手を止め、冷静に考えました。 ルールには書いていたはずですが、AIにとっては「具体的にどう再開すればいいか」が曖昧だったようです。指示が「ふんわり」していたせいで、AIが暴走してしまったのでしょう。
そこで、ChatGPTに相談し、以下の対策を徹底しました。
- `.cursor/rules` の再徹底 タスク終了時に「これまでの進捗」と「今後のアクション」をAI自身に作成させるプロセスを義務付けました。また、再開時に参照すべきファイルを事前に特定させる指示も明確に書き込みました。
- 「再開用プロンプト」の作成 ここが決定打でした。セッション開始時に投げかける言葉をアドリブにせず、「型」として決めることにしたのです。 ChatGPTに依頼し、「必要最小限のファイルだけを読み込み、直前のタスクの続きから即座に動けるようにする」ための専用プロンプトを作成してもらいました。
- 初期生成プロンプト（No.3）のアップデート これに合わせて、前回紹介した「プロンプト3」自体も、この運用フロー（終了時のまとめ作成など）を前提とした内容にバージョンアップしました。
【現在の運用フロー】
- タスクの終了時に、「ここまでの進捗」と「次の一手」をまとめてもらうよう指示しておく。
- `/context` でコンテキスト消費量を確認。
- 消費量が 7 割を超えていたら、一度 GitHub に現状を push しておく。
- `/compact` または `/clear` でコンテキストをリセット。
- 「再開用プロンプト」を投げて、迷わず次のタスクに再開する。
結果どうなったか
このフローを確立してからは、開発がよりスムーズになりました。 AIは「再開用プロンプト」の指示に従い、余計なファイルを読み込まず、ピンポイントで作業を再開してくれるようになりました。コンテキスト消費も抑えられ、何より「次に何をやるか」が明確なため、実装のスピードが落ちません。
現在は、この新しい運用ルールのおかげで、金融サービスの開発も順調に進んでいます。
医師×MBA視点での学び・示唆
今回の失敗は、医療現場における「申し送り（サインアウト）」のミスと全く同じだと感じました。
当直明けの医師が、次の医師に「あとはよろしく」とだけ言って帰ってしまったらどうなるか？ 引き継いだ医師は、患者さんのカルテを最初から読み直さなければならず、時間を浪費する上に、重要な治療方針を見落とすリスクも高まります。
「ルールがあるから大丈夫」と思っていても、具体的なフォーマット（型）がないと、現場（AI）は混乱して無駄な動きをしてしまうのです。
MBA的な視点で言えば、これは「スイッチングコスト」の管理です。 タスクを切り替える際にかかる認知負荷（AIの場合はトークン消費）を最小化するために、曖昧さを排除した「再開の儀式（プロンプト）」を設計する必要がありました。
最後に
今回改良した「プロンプト3（New Version）」と、新しく作成した「セッション再開用プロンプト」は、前回の記事に追記する形で公開しました。
前回の記事はこちら： https://note.com/entikemoto/n/na15487255729 https://note.com/entikemoto/n/na15487255729
もし私と同じようにClaude Codeで「指示したつもりなのにAIが暴走する」「コンテキスト不足に悩んでいる」という非エンジニアの方がいれば、ぜひ試してみてください。
それでは、また！