AIコーディング委任、モデル選びで失敗しないための考え方

AIコーディングエージェントにWebアプリの機能追加や改修を任せるとき、最初に決めるべきなのは「どのモデルを使うか」だけではありません。

実務では、モデルの地力と推論強度、つまりどれだけ丁寧に考えさせるかを分けて見る必要があります。小型・低コストモデルに重い改修を任せると、指示には従っているように見えても、既存コードの前提を読み違えたり、必要な処理を巻き込んで消してしまったりすることがあります。

この記事では、個人開発でAIエージェントに実装を委任する前提で、モデル選定と推論強度の考え方を整理します。

• 対象: CLI型のAIコーディングエージェントを使う個人開発・小規模開発
• 前提: 指示書を渡して実装させ、差分を人間または別AIが確認する運用
• 結論: 軽い作業は節約枠、壊れると痛い作業は上位モデル、最後は差分精査までをセットにする

「AIに開発を任せる」ときに最初にぶつかる選択

AIエージェントに開発を委任する流れは、だいたい次のようになります。

1. 人間が要件を指示書や仕様書にまとめる
2. CLI型のAIエージェントに渡して実装させる
3. 上がってきた差分を人間、または別のAIで精査する
4. 問題がなければ取り込む

この分業は便利です。細かな修正、定型的な追加、テストの補助、既存コードの整理などを任せられます。

一方で、個人開発では利用料の制約があります。常に最上位モデルを使えば安心に寄せられますが、消費レートが重くなります。そこで「小型モデルで済む作業」と「上位モデルを使うべき作業」を分けたくなります。

ここで重要なのは、安いモデルを使うこと自体が問題なのではなく、安いモデルに任せるタスクの種類を間違えると、手戻りでかえって高くつくという点です。

バージョン更新で“前は動いた”が壊れる話

AIエージェント運用では、モデルだけでなくCLIツール側の変化も見落とせません。

実際に、CLIツールのバージョン更新によって、以前は使えたオプションが廃止され、実行エラーになった事例がありました。これはコードの品質以前に、作業を開始するための足場が変わる問題です。

CLI型エージェントを使う場合、次の情報は固定値として思い込まないほうが安全です。

• コマンド名
• オプション名
• 推論強度やモデル指定のパラメータ
• 設定ファイルの形式
• デフォルト挙動

特にAI関連ツールは変更が速いので、「前に動いたコマンド」は根拠として弱くなります。実行前に、利用中のバージョンでヘルプ、リリースノート、公式ドキュメントを確認する運用が必要です。

ここがポイント: モデル選び以前に、CLIのバージョン差で委任の入口が壊れることがある。コマンドやオプションは、利用中のバージョンで要確認。

小型モデルに重い改修を任せたら起きたこと

より大きな問題は、実装差分の中で起きました。

小型・低コストモデルに、複数ファイルにまたがる重い改修タスクを委任したところ、リファクタの過程で既存の必須処理、具体的には必要なメソッドが誤って削除され、機能が動作不能になる事故がありました。

この問題は、後から差分を精査することで発見され、修復されました。つまり、実行結果だけを見ていたら見逃していた可能性があります。

この事例から見えるリスクは、単なる「指示ミス」ではありません。

• 複数ファイルをまたいだ変更で、依存関係を追い切れない
• リファクタ中に、使われていないように見える処理を削除してしまう
• 既存コードの暗黙の前提を読み落とす
• 変更後の整合性を最後まで確認しきれない

もちろん、これだけで「小型モデルは使えない」とは言えません。軽いタスクなら十分に役立ちます。ただし、壊れると痛い処理を含む改修では、モデルの節約がそのまま安全とは限りません。

「地力」と「考える量」は別物である

モデル選定で混同しやすいのが、「モデルの地力」と「推論強度」です。

推論強度を上げると、エージェントはより丁寧に考え、手順を追いやすくなります。しかし、それでモデル本体のコード読解力や設計感覚が別物になるわけではありません。

推論強度で改善しやすいもの

推論強度を上げると、次のような領域は改善しやすくなります。

• 作業手順を細かく分ける
• 指示書の項目を見落としにくくする
• 変更後に自己点検する
• エッジケースを列挙する
• 長い指示に粘って追従する

これは「丁寧さ」や「粘り」に近い領域です。軽量な修正でも、確認漏れを減らしたいときには効きます。

素体に依存しやすいもの

一方で、次のような領域はモデルの素体に依存しやすいと整理できます。

• 既存コードの深い読解
• 暗黙の前提の察知
• コードベースの質感に合わせた変更
• 副作用の予見
• 「消してよさそうに見えるが実は必要」な処理の判別

ここは、推論強度を最大にしても限界が残りやすい領域です。

たとえるなら、推論強度は作業時間や見直し回数を増やす設定に近く、素体はそもそもの読解力や設計判断の土台です。時間を増やせばミスは減るかもしれませんが、読めていない依存関係を正しく読む力そのものが急に補われるとは限りません。

推論の設計思想：段階で選ぶか、予算で割り当てるか

AIエージェントやモデルの提供元によって、推論の指定方法にも違いがあります。

ここでは具体的な製品仕様としてではなく、運用上の考え方として、2つの型に分けて整理します。実際のコマンド、オプション名、設定値はバージョンで変わるため、利用中の環境で確認してください。

段階指定型

一方の設計は、推論にかける量を段階で指定する考え方です。

たとえば「低・中・高」のように、離散的なレベルを選ぶイメージです。モデルは常に推論し、その強さを段階で調整します。

この方式は、運用ルールに落とし込みやすいのが利点です。

• 軽微な修正: 低または中
• 複数ファイルの変更: 中以上
• 壊れると痛い改修: 高

設定が単純なので、チームや個人のメモにも残しやすいです。

予算割り当て型

もう一方の設計は、思考トークンの予算を割り当てる考え方です。

思考のオン・オフや量をより連続的に調整でき、場合によってはキーワードなどで段階指定する抽象化もあります。

この方式は、細かくコストを制御したいときに向いています。たとえば、軽い作業では思考量を抑え、仕様変更の影響範囲を見たいときだけ多めに割り当てる、といった運用ができます。

ただし、細かく調整できる分、設定の意味を理解しないまま使うと、品質とコストの見積もりが曖昧になります。

事故りやすい組み合わせはどれか

事故りやすい組み合わせは、経験則としては 小型モデル × 重いタスク × 壊れると痛い領域 です。

これは定量的に証明された一般法則ではありません。限られた事例と概念整理に基づく見立てです。ただ、実務上の警戒ラインとしては使えます。

小型モデルに向きやすい作業

小型・低コストモデルは、次のような作業に向いています。

• 誤字修正
• コメントやREADMEの軽い整理
• 小さな関数の追加
• 既存パターンに沿った単純な変更
• テストケースのたたき台作成
• 差分の要約

これらは、失敗しても影響範囲を確認しやすく、手戻りも小さく済みます。

上位モデルに寄せたい作業

反対に、次の作業は上位モデルを使うほうが安全です。

• 複数ファイルにまたがるリファクタ
• 認証、課金、公開範囲に関わる変更
• データ削除や更新処理を含む変更
• 既存仕様を保ったまま内部構造を変える作業
• 失敗するとユーザー操作や投稿処理が止まる機能
• 長い指示書を読み、複数条件を同時に満たす必要がある作業

この種のタスクでは、単にコードを書けるかではなく、既存の意図を壊さずに変更できるかが重要になります。

「速いモデル」と「小さいモデル」も混同しないほうがよいです。高速に応答することが、そのまま性能を落とした版であるとは限りません。モデル名や価格、性能の具体値は変わるため、固定的に決めつけず、実際のタスクで確認する必要があります。

コストを抑えつつ品質を守る使い分け

個人開発では、コストを無視できません。だからこそ、全部を高価なモデルに投げるのではなく、タスクごとに役割を分けるのが現実的です。

使い分けの目安

モデル階層は、厳密な性能等価ではなく、次のような運用上の枠として見ると扱いやすくなります。

• 小型・低コストモデル: 節約枠。軽量・低リスク作業に使う
• 主力モデル: 標準枠。通常の機能追加や中規模修正に使う
• 最上位モデル: 地力枠。複雑な読解、リファクタ、失敗時の被害が大きい変更に使う

同格モデル同士の優劣は、タスク相性で変わります。特定ベンダーが常に優れていると見るより、同じ重さのタスクを投げたときに、どちらが自分のコードベースで安定するかを見たほうが実用的です。

手戻り込みで考える

安いモデルで1回の実行コストを抑えても、壊れた差分の調査、修復、再委任が必要になると、結果的に高くつくことがあります。

特に次のような兆候がある作業は、最初から上位モデルに寄せる判断がしやすいです。

• 指示書が長い
• 変更対象ファイルが多い
• 既存機能の維持条件が多い
• テストが薄い
• 失敗時にデータや公開状態へ影響する

重要タスクでは上位モデルを使うほうが、手戻りを含めると安く済む可能性があります。これは経験則であり、常に成り立つ断定ではありませんが、個人開発の運用ルールとしては十分に検討する価値があります。

任せた後の「精査」までがセット

AIエージェントへの委任は、実装が返ってきた時点では終わりません。差分精査まで含めて1セットです。

今回のように、必須メソッドがリファクタ中に削除される事故は、見た目の変更量だけでは分かりません。差分を見て、意図しない削除や副作用を確認する必要があります。

確認するときは、次の観点をチェックリストにしておくと再利用しやすくなります。

• 指示していないファイルが変わっていないか
• 既存の必須処理が削除されていないか
• リネームや整理のつもりで参照切れが起きていないか
• 既存の入出力形式を壊していないか
• 認証情報、公開範囲、課金、削除処理に触れていないか
• テスト、ビルド、静的解析で確認できる範囲を通しているか
• モデルが勝手に仕様を補完していないか

人間が全部を読むのが重い場合は、別のAIにレビューさせるのも有効です。ただし、その場合も最終判断は人間側に残します。AI同士で通ったから安全、とは扱わないほうがよいです。

まとめ

AIコーディング委任で失敗しないための軸は、シンプルに整理できます。

• モデルの地力と推論強度は別物として見る
• 推論強度で伸びるのは、手順の丁寧さや自己点検の部分
• 既存コードの深い読解や副作用の予見は、素体に依存しやすい
• 小型モデルは軽量・低リスク作業に使う
• 複数ファイルの重い改修や壊れると痛い処理は、上位モデルに寄せる
• CLIのコマンドやオプションは、利用中のバージョンで確認する
• 委任後の差分精査までを作業に含める

コストを抑えることは大事です。ただし、節約する場所を間違えると、後から差分調査と修復に時間を払うことになります。

次に見るべきポイントは、手元のタスクを「軽い作業」「標準作業」「壊れると痛い作業」に分けることです。その分類ができると、モデル選びはかなり現実的になります。

参照リンク

• なし