1. はじめに
2. ポイント1:設計書を書いてもらいましょう
3. ポイント2:Geminiを使うときの指示の出し方
4. ポイント3:自分で修正したら「読み直して」と必ず伝える
5. まとめ

はじめに

生成AIを使ってコード生成や修正を行うことは、もはや特別なことではなくなってきました。 Gemini や CodeX、Copilot、Cursor など、選択肢も増え、「うまく使えばかなり楽になる」という実感を持っている方も多いと思います。

• 途中から意図と違う方向に進み始める
• さっきまでの前提を忘れたような修正をしてくる
• replace に失敗して延々とやり直しを始める

この記事では、生成AIでコードを書くときに安定して進めるためのちょっとしたポイントを紹介します。 特に、コード生成や修正を生成AIに任せる機会が多い方に向けた内容です。

ポイント1：設計書を書いてもらいましょう

機能追加、不具合修正やリファクタリングを生成AIに依頼するとき、いきなり「ここを直して」と指示していないでしょうか。 実はこのやり方だと、生成AIが目の前の修正作業だけに集中してしまい、全体の前提を忘れることがよくあります。 おすすめなのは、最初に「どういう修正をしたいのか」を設計書（Markdown）として書いてもらうことです。

初回の出力は、設計書を書かなくても比較的安定して良い結果が出ることが多いです。 しかし、修正や追加依頼を繰り返していくうちに、最初の前提を少しずつ忘れ、 意図と違う方向へ進み始めることがあります。

設計書を用意しておくことで、 「今回はこの前提で直していたよね」と立ち返ることができ、 迷走を防ぐだけでなく、迷走後のリカバリーにも役立ちます。

例えば、

• どんな不具合を直したいのか
• どの方針で修正したいのか
• 影響範囲はどこか

といった内容をまとめたドキュメントを作り、その上で 「調査結果や修正方針をこの設計書に追記してください」 と指示します。

こうしておくと、修正や追加依頼を重ねたときに、 最初の前提が少しずつ崩れていくことを防ぎやすくなります。 生成AIが迷走し始めたときも、設計書という"基準点"に戻すことができます。 また、途中でセッションを切った後でも、「この設計書通りに進めたけど、ここに不具合があるんだよね」 と前提を思い出させることができます。 前の情報のうち「大事なことだけ」を引き継ぐ手段として、設計書はとても有効です。

ただし、生成AIも人間と同じで、情報を大量に与えられると注意が分散する傾向があります。

そのため、毎回すべての設計書を読ませるのではなく、 今回の修正と関連する方針だけを再掲するほうが、 生成AIの注意が分散せず、出力が安定しやすいです。

ポイント2：Gemini を使うときの指示の出し方

これは Gemini を使っている場合の話ですが、git の履歴や差分を調査させるときに、 そのまま git log や git diff を実行させると、なぜか数分待たされることがあります。

そこでおすすめなのが、 「調査結果を一度ファイルに保存して、そのファイルを見て判断してください」 と指示することです。

例えば、git log や git diff の結果を一時ファイルに出力させてから、それを読み取らせるようにすると、驚くほどスムーズに進むことがあります。 理由は正直よく分かりませんが、少なくとも体感としては そのままコマンドを実行させるより安定します。

Gemini 特有の挙動かもしれませんが、一度試してみる価値があります。

ポイント3：自分で修正したら「読み直して」と必ず伝える

これもGeminiを使う場合に多い話なのですが、LLM全般に少なからずあるポイントと思われます。 生成AIに修正を任せている途中で、自分でソースコードやMarkdownを少し直したくなることはよくあります。

• 改行を整えたい
• 「てにをは」を直したい
• 変数名を変えたい
• 行の順番を入れ替えたい

こうした修正を 自分で行った後に、そのまま続きを依頼すると、生成AIが大混乱することがあります。replace コマンドが失敗し、「もう一回やります」を繰り返し、気づいたら10分過ぎてしまった⋯ということもよくあります。

これを防ぐためには、

「こちらで修正したので、最新の内容を読み直してください」

と、明示的に伝えることで改善されることがよくあります。 それでもうまくいかない場合は、無理に続けず セッションを切って新しく始める方が早いこともあります。

おそらく、モデル内部に前回の状態を強く保持していて、差分がうまく当たらず混乱しているのだろう、というのが推測です。 理由を説明すると気をつけてくれることもありますが、体感では半分くらいは無視されてしまいます。 そういうときは、割り切って新しいセッションで続きの作業を進めることがおすすめです。

また、せっかく「てにをは」やトンマナを修正したのに、 追加のドキュメント修正を依頼したら元に戻されることや、 こちらで変数名を変えたのに別の箇所の再修正を依頼したら、変数名まで元に戻された⋯ こうした現象もよく起こります。

その場合は、無理に続けるよりも、 一度セッションを切り替えるほうが結果的に早いことも多いです。

そしてそのときに役立つのが、ポイント1で紹介した設計書です。 設計書があれば、前提を明示的に再共有できるため、 新しいセッションでも迷走しにくくなります。

まとめ

CopilotやCursorでは、ここまで気を遣わなくてもよい、という話もあるようですが、 今回紹介したやり方でかなり安定して生成AIを使えるようになりました。 また、今回コード生成にフォーカスしていますが、コード生成以外の場合でも今回の3つのポイントは有効だと考えています。

生成AIは賢いですが、前提をどう渡すか、どう指示を出すか、どこで区切るかによって、結果は大きく変わります。 もし最近「生成AIが言うことを聞いてくれないな......」と感じている方がいれば、ぜひ一度お試しください。