まず読み込み
最終更新
ローカルコーディングAI:補完とエージェントでは選び方が違う
コード補完からリポジトリ修正まで実作業で比べます
ローカルのコーディングAIは、エディターで次のコードを提案したり、関数を修正したり、複数ファイルを扱ったりできます。必要な作業を決め、同じ実作業を現在の機器で行い、テスト結果と確認時間を記録すると、必要なモデルとメモリを絞れます。
コードをすぐ表示することと、修正・確認を終えて作業を完了することは別です。短い提案、関数1か所の修正、リポジトリ内の複数ファイルの変更では、必要な文脈や実行権限が異なります。補完スコアやチャット応答速度だけでリポジトリ作業用モデルを選ぶと、実際の手順に合わないことがあります。
入力中に使える補完提案かを確認します
TypeScriptのフォームを書くとき、コード補完はカーソルの後に続く短いコードを提案します。提案が正しくても、次の行を書いた後に届けば役立ちにくくなります。同じファイルで提案の到着時点、採用したか、採用後に直した箇所を記録します。チャットで関数全体を作る作業は結果全体を読んで挿入することですが、入力中の提案は現在の行や変数の流れに合うかをすぐ判断する作業です。
まず利用中のエディターがモデルに対応しているか確認し、提案がプロジェクトの変数名やコードスタイルに沿うか見ます。関数全体を貼り付けて変数名を直す作業と、括弧や条件式を一行ずつ提案してもらう作業では確認基準が異なります。実際のエディターでよく使うファイルを開き、提案を採用した後の修正量も記録して、補完が作業に役立つか判断します。

関数修正では入力と期待する結果を対応させます
招待コードの検証関数を直すなら、空文字列とスペース3つは拒否し、AB-12はそのまま許可する基準を決めます。長さだけを調べるとスペース3つも通るため、前後の空白を除いて空かどうか確認します。この確認用の値をそのまま保存する必要はありません。有効なコードの大文字小文字や保存形式まで変えると依頼の範囲を超えることがあります。
再現用の入力、現在の結果、期待する結果をモデルに渡し、関連する関数と呼び出し元だけを見せます。diffでは変更ファイルと範囲を、テストでは3ケースの実際の結果を確認します。自動テストがなければ、3つの入力を使う小さな再現を作れます。1ケースが通ってもフォーム全体を検証したことにはなりません。検証関数と画面の送信・エラー表示の流れを分けて確認します。画面が送信を止め、必要なときにエラー表示を消すことまで見て、利用者がそのルールを正しく体験できるか確かめます。
テストが失敗したら、検証ロジックの問題か、画面から値を渡す過程の問題かを分けます。両方の層を変える必要があるなら、どこがルールを担うかを先に決め、変更ファイルを必要な範囲に限ります。これにより、一つの画面の例外処理が別のフォームの動作まで変えてしまうリスクを抑えられます。
リポジトリ全体ではなく関連する文脈をエージェントに渡します
複数ファイルを編集するエージェントは、依頼、コード、前の回答、ツール結果を文脈として使います。招待コードのルールが画面とテストにまたがるなら、関連ファイルを見つけて一緒に渡します。リポジトリ全体を入れると、無関係なコードまで加わり必要な箇所を探しにくくなる場合があります。長い文脈は多くの資料を含められますが、正しいファイルを自動で選ぶわけではありません。
ルールのある関数、その関数を呼び出す画面、既存テストを見つけます。似た名前の別フォームを編集したなら、まず検索経路を直します。正しいファイルを読んでも関数と画面のつながりを見落とした場合は、「検証関数を修正、呼び出し元を確認、エラー表示を確認」のように段階へ分けます。既存テストには関数名だけでは分からない例外ルールが含まれることがあるため、編集前に読み、エージェントの説明が実際に読んだファイルと合うか確認します。

ファイル編集とコマンド実行の権限を分けて与えます
ファイルの読み取り、編集の適用、テストやパッケージ導入コマンドの実行は、リポジトリや環境への影響が異なります。最初からリポジトリ全体、ターミナル、インストール権限をまとめて開かず、まず読み取りだけで必要なファイルを探します。編集段階ではdiffを確認し、テストはコマンドの影響を理解してから実行します。ローカルモデルを使っていても、検索ツールや外部API1までローカルで処理されるとは限りません。
招待コードの修正はコピーや別ブランチで試し、秘密鍵や実際の顧客データは入力しません。テストにネットワーク接続やインストールが必要なら、ファイル編集権限とは別に実行環境を確認します。機密性の高いリポジトリでは、外部送信の可能性があるツールを避け、元に戻せるコピーだけで実行権限を試します。
作業開始からテストまでの完了時間を測ります
同じTypeScriptフォームの作業で候補を比べます。コード補完では提案が入力の流れに合うか、関数修正では空値と空白だけの入力が拒否されAB-12が保たれるか、エージェントでは変更範囲とテスト結果が適切かを確認します。複数の役割を使う予定なら、実際に使うモデルの組み合わせと同時実行も試します。短い提案の速度から複数ファイル作業の完了時間は推測できません。
仮の2つの修正案を考えてみます。Aはコード生成に15秒、その後の人手修正に90秒かかり、合計105秒です。Bは生成に30秒、修正に20秒で合計50秒です。生成が遅いBのほうが作業全体を先に終えます。この数字は説明用の仮定であり、特定モデルの測定結果ではありません。公平に比べるにはテストと確認の度合いもそろえます。速度比較で候補を絞ったら、実際のフォーム作業をテストまで完了します。現在の機器で修正と確認が円滑なら、購入を先送りできます。

用語の注釈
API — 別のコードからプログラムの機能を呼び出すための決められたインターフェースです。
本文に戻る
よくある質問
- この記事で最初に確認すべきことは何ですか?
- ローカルのコーディングAIは、エディターで次のコードを提案したり、関数を修正したり、複数ファイルを扱ったりできます。必要な作業を決め、同じ実作業を現在の機器で行い、テスト結果と確認時間を記録すると、必要なモデルとメモリを絞れます。
この条件の応答を見る
機器とモデルを選択済みの速度シミュレーションです。
