AI が書く量が増えるほ⁠ど、自分の判断を大⁠切⁠に⁠したい。

日本語の翻訳や文章確認から始まり、学びながら Coding、SQL、学校の課題へと使い方が広がった。Cursor や Copilot を試すうちに、AI が書く速さだけでは進まない場面にも気づいた。

Context が長くなると前提が抜け、決めたことが崩れたり、実装が重なったりする。変化の中心は新しいモデルではなく、AI をどう仕事に参加させるかを考え始めたことだった。

使い方の変化概念図

まだ形のない考えを Chat で話し、質問と回答を重ねながら、要件、利用場面、Scope、技術の方向を整理する。必要なら別の AI にも見てもらい、自分の見落としを探す。

UI はイメージを先に形にし、納得できる方向を Demo として確かめる。決まった内容は Plan、AGENTS.md、DESIGN.md、変更範囲や Evidence に残し、Agent が毎回推測し直さない境界をつくる。

考える順序概念図

範囲がはっきりした小さな修正なら、Codex で素早く進めて確認する。大きな Context や複数の Agent を使うと、作業より準備が重くなることもある。

複数の領域にまたがる重要な作業では、Brainstorm、Spec、実装分担、別視点の Review、Evidence まで含める。作業の規模に合った手順を選ぶことも、開発の一部だ。

作業に合わせた二つの流れ概念図

AI には考える相手、実装する手、確認を手伝う役割がある。私は問題を定義し、方向を決め、Scope を伝え、結果を確かめる。

人の仕事は、要件の理解、構造の判断、優先順位、受け入れ基準へ移っていく。AI の能力を使いながらも、何を作り何を受け入れるかは自分で決める。

作業を分け、実装、難しい Debug、UI、Visual QA、Review などをそれぞれの Agent に任せることがある。大事なのは Agent の数ではなく、実装した側とは異なる視点で確認すること。

Review に渡す情報も絞る。DESIGN、PLAN、変更ファイル、テスト結果、スクリーンショットなど、判断に必要な Context を明示しておく。

Typecheck、Test、Build、変更範囲、スクリーンショットなど、作業に合った Evidence を見る。UI なら Reviewer が実際の画像を確認できているかも確かめる。

AI の Visual QA が PASS と言っても、それだけで受け入れない。実際の結果を自分で見て、必要なら直し、最後の判断をする。

テストが通っても、画面が意図どおりとは限らない。

Journal / Lab

以前は長い Context が切れた後、前に決めたことが伝わらず、実装をやり直したり機能が重なったりすることがあった。

Plan、Scope、Git の作業境界、別視点の Review、Evidence を加え、AI に自由に考えてもらう場所と、人が先に決めることを分けるようになった。

経験から変えたこと概念図

BEFORE

PROMPT → GENERATE → FIX → やり直し

NOW

DEFINE → BOUNDED BUILD → REVIEW → EVIDENCE

Local AI の実験では、モデルの能力だけでなく、VRAM、量子化、Context、速度、安定性やコストが使い心地を左右することを学んだ。今のところ、大きく複雑な開発ではクラウドのモデルを主に使い、Local AI は実験と研究を続けている。

私にとって AI-assisted Engineering は、人が問題、方向、境界、最後の判断を持ち、AI が考える力と実行力を広げること。使い方を学び続けながら、自分で確かめて進みたい。

翻訳から、開発の進め方を考えるまで。