AIのインライン補完を安全に使う｜タブ連打で混ざるバグの防ぎ方

グレーの薄い文字で、続きが勝手に出てくる。だいたい合っているから、タブ。また出てくるから、タブ。 その調子で30分書いて、ふと画面を見返したとき——「これ、どこまで自分で書いたんだっけ」と思ったことはないでしょうか。

動いてはいる。テストも通っている。でも、なんとなく落ち着かない。 その感覚は、たぶん正しいです。インライン補完（エディタ上でコードの続きを薄く提示してくれる機能）は、AIの使い方の中でいちばん速く、そしていちばん確認の隙間が薄い場所だからです。チャットに貼って相談するときは、読んで、直して、それから貼ります。補完は、読む前に指が動いてしまう。

結論：インライン補完で事故らないコツは、①タブを押す前の3秒で「名前・範囲・意図」だけ見る（変数名や引数が自分の意図と合っているか／どこまで入ったか／なぜそうなるか一言で言えるか）→ ②説明できない候補は受け入れず、自分で書き始める（書き始めると候補の質も上がります）→ ③押した後は差分（diff）でまとめて読み返す→ ④境界値と異常系だけは手で確かめる、の4つです。全部の候補を熟読する必要はありません。押す前の3秒と、コミット前の一回で十分間に合います。

補完を切れ、という話ではありません。速さは本物ですし、定型的な記述で助かる場面はいくらでもあります。 ただ、速さの代償として「読まずに入る行」が生まれる。そこにだけ、小さな関所を置きます。

なぜ補完だけ、すり抜けやすいのか

同じAIでも、チャットで相談するときと補完では、通る道が違います。

• チャットは「受け取る→読む→貼る」。読む工程が構造的に挟まっています
• 補完は「見える→押す」。読む工程を、意識しないと飛ばせてしまいます

そして補完の候補は、たいてい8割方合っています。この8割が曲者で、間違っている2割も同じ見た目・同じ雰囲気でやってきます。明らかに変なら気づけますが、「ほぼ合っている」ものほど、目が滑ります。

さらに、押した瞬間の心理も効いています。候補が出てから押すまでの間、頭は「次に書きたいこと」を考えています。目の前の行を評価するモードではなく、先へ進むモードです。注意が向いていない場所に、コードが入っていく——これが、補完だけ確認が薄くなる理由です。

これはあなたの集中力の問題ではありません。道具の作りがそうなっているだけです。だから、気合いではなく手順で埋めます。

タブを押す前の3秒——見るのは3つだけ

全部の候補を精読していたら、補完を使う意味がなくなります。見るのは3つだけで十分です。

1. 名前——自分が扱っているものと合っているか

補完がいちばん静かに外すのが、ここです。

• 似た名前の変数を取り違えている（userId と userIdList、total と subtotal）
• 引数の順番が入れ替わっている（copy(dst, src) と copy(src, dst)）
• 存在しないメソッドやプロパティを、それらしい名前で呼んでいる

とくに引数の順番は、型が同じだと言語やエディタも黙って通します。数値や文字列を2つ以上渡す呼び出しが出てきたら、そこだけは順番を目で追います。

2. 範囲——どこまで入ったのか

タブ1回で3行入ることも、20行入ることもあります。「1行だけのつもりが、ifブロックごと入っていた」は珍しくありません。

押した直後にカーソルがどこにあるか、画面の何行が新しくなったかを、一瞬だけ確認します。思っていたより多く入っていたら、それは読むべき合図です。

3. 意図——なぜそうなるか、一言で言えるか

いちばん効く問いです。「この行、なんでこうなってるの？」と聞かれて、一言で答えられるか。

答えられないなら、それは自分が書いたコードではなく、まだ預かっただけのコードです。預かったまま先に進むと、後日レビューやバグ調査で、他人のコードを読むのと同じ手間がかかります。

説明できないときの一手はシンプルで、受け入れずに、自分で最初の数語を書き始めること。書き始めると、補完はその意図に沿った候補を出し直します。白紙に出た候補を評価するより、自分の書き出しに続く候補のほうが、ずっと判断しやすくなります。

気をつけたい候補の型

現場でよく混ざるのは、この5つです。動いてしまうので、後から見つかりがちです。

どれも「知っていれば数秒で気づく」ものばかりです。逆に言えば、知らないと何度でも通ります。この5つだけ頭の隅に置いておく——それが、精読しないための備えになります。

古い書き方については、AIが学習時点の知識で答える性質そのものの話でもあります。詳しくはAIの知識は少し前で止まる｜古い情報で最新仕様を扱う注意点にまとめました。

押した後に拾う——2つの網

押す前の3秒ですべてを止めるのは無理です。すり抜けた分は、後段で拾います。網は2つで足ります。

1つ目は、コミット前の差分（diff）読み。 補完を使った日は、いつもより差分が膨らみます。コミット前にgit diffをひととおり通して読むと、「書いた覚えのない行」がはっきり浮きます。編集中は先へ進むモードなので気づけないものが、読むモードに切り替えると見えてくる——これが効きます。

複数ファイルにまたがったときの追い方はAIに複数ファイルの変更を任せる｜差分を見失わない追い方が使えます。

2つ目は、境界値と異常系の手当て。 補完は、うまくいく道を書くのが得意です。逆に、空・0件・null・上限超え・タイムアウトといった端の条件は落としがちです。ここだけは、ユニットテストを1つ足すか、手で動かして確かめる。全部でなくていいので、その日いちばん重要な処理ひとつで構いません。

観点の洗い出しは境界値・異常系をAIに考えさせて漏れを減らす手順、動作確認の最低ラインはAI生成コードの動作確認｜そのまま使わない最低限の型が参考になります。

明日、まず試すこと

一度に全部やらなくて大丈夫です。明日の作業で、上から順にできるところまでで十分です。

1. タブを押す前に、「名前」だけ見る。変数名と引数の順番が自分の意図と合っているか。まずはここ一点でいい
2. 説明できない候補は、受け入れずに自分で数語書き出す。書き出してから、続きの候補を見る
3. その日のコミット前に、git diff を一度通しで読む。「書いた覚えのない行」に印をつける
4. 印をつけた行のうち、いちばん重要な1つだけ、境界値（空・0件・上限）で動かしてみる
5. 補完が繰り返し外す場所があれば、その部分は補完を切って手で書くと決めてしまう

5つ目は、意外と楽になります。プロジェクト固有の規約が絡む箇所や、自分しか知らない業務ロジックは、補完が当てにいくほど外れます。「ここは自分で書く」と決めた場所があること自体が、残りを安心して任せる土台になります。

インライン補完 確認チェックリスト

全部に○が要るわけではありません。時間がない日は、太字の2つ——「名前を見た」「差分を通しで読んだ」——だけで及第です。

タブを押す前

• 変数名・引数の順番が、自分の意図と合っているか
• どこまで入るか（何行・どのブロックまで）を把握しているか
• なぜそうなるかを、一言で説明できるか
• 説明できないとき、受け入れずに自分で書き出したか

押した後・コミット前

• 差分を通しで読み、「書いた覚えのない行」を確認したか
• エラー処理・失敗時の分岐が飛ばされていないか
• 設定値やURLが、その場に直書きされていないか
• 境界値（空・0件・上限）を、重要な処理ひとつだけでも確かめたか
• 繰り返し外れる箇所を、自分で書くと決めたか

最後に

補完に任せた時間が長い日ほど、コードとの距離が少し遠くなる感じがあります。動いているのに手応えがない、あの感覚です。

でもそれは、手を抜いたからではありません。読む隙間を挟まずに進める道具を使っていたら、誰でもそうなります。だから、埋めるのは意志ではなく手順のほうです。押す前に3つ見る。コミット前に一度読む。それだけで、「なんとなく不安なコード」が「自分が通したコード」に戻ります。

明日ひとつ、タブを押す前に変数名だけ見る。それができた日から、速さと確かさは、どちらかを諦めるものではなくなります。

よければ、こちらも

• 補完に限らずAIコーディング全体の任せ方はAIコーディングは小さく切る｜関数1個から始めるスコープ設計
• 入ったコードが読みにくいまま残ってしまったときは「動くけど読めない」AI生成コードを保守可能にする手直し手順
• 任せる比率が上がってきたと感じたらAIに頼りすぎたときの品質低下のサインと、そっと戻る歯止め
• プロジェクトの書き方に沿わせたいときはAIにコーディング規約を守らせる｜指示とチェックの仕込み方

関連用語

• diff（差分）
• ユニットテスト
• ハッピーパス
• ハルシネーション