07HUMAN-IN-THE-LOOP
AI DEVELOPMENT WORKFLOW
判断と責任を人が持つ、AI協調開発のワークフロー。経験しながら整えている実践記録。
2025 - 2026
HOW I WORK WITH AI
AI は作品そのものではなく、考え、つくり、確かめるための力を広げる道具。方向と最後の判断は自分で担う。
方法のループ
- 01DIRECTION
方向と範囲を決める
- 02PLAN
境界と分担を固める
- 03BUILD
小さく実装する
- 04REVIEW
別の視点で確認する
- 05VERIFY
実際に操作して確かめる
- 06DECISION
採用するか、直して戻すかを決める
小さく明確な作業は軽い流れで進める。複雑な仕事は範囲を区切り、実装とは別の視点で確認する。AI の PASS だけで採用を決めず、最後は自分で確かめる。
Agent の分担、Context、Review、Visual QA、失敗からの学びは Journal に記録している。
開発ノートを読む01
ここまでどう使ってきたか
最初は日本語の翻訳と添削。そこからコード、学校の課題、ローカルモデルへ広がった。作るものが大きくなるにつれ、アイデアを伝えるだけでなく、仕様と分担を先に決める必要を感じた。
EVOLUTION
- 01LANGUAGE TOOL
翻訳・添削
日本語の翻訳と文の修正から始まった。
- 02CODING ASSISTANT
Coding / SQL
Coding と SQL、課題へ。Tab Completion と修正依頼から。
- 03VIBE CODING
説明して実装
速いが、Context が長くなると失速した。
- 04LOCAL AI
ローカル環境の実験
VLM・OCR・量子化と資源の取引を学んだ。
- 05SPEC / AGENT
参加の設計
Spec と複数 Agent で仕事を分ける。
道具は変わり続ける。残るのは、参加の設計である。
詳しい開発ノート
私はまだ開発を学んでいる途中にいる。だから AI を使うことは、経験者のふりをするためではなく、分からない部分を質問し、実装を小さく試し、結果を自分で確かめるために使っている。
最初は日本語の翻訳と添削のための道具だった。やがて Coding と SQL、学校の課題や小さなプロジェクトへ広がり、Tab Completion から始めて、質問し、AI に修正を頼むようになった。
Cursor によって「説明すると AI がそのまま実装する」流れが自然になり、多くの課題をその速度で作った。ただ、プロジェクトが大きくなり Context が長くなると、前の要件が忘れられ、できていたものが作り直され、機能が重複し、実装どうしが干渉した。ここが Vibe Coding の限界だった。
その後、ローカルの LLM・VLM・OCR に触れ、計算リソース、Context、量子化、速度、安定性、コストのトレードオフを直接知った。NOTERA のような卒業制作では、AI は「書いてくれるもの」から製品機能そのものの一部になった。
さらに Spec Kit や Superpowers のような計画の進め方、複数の Agent に仕事を分ける開発を試した。複雑な案件は仕事を分割し、範囲が明確な小さな作業には軽い流れを使う。今の関心は道具の数ではなく、どう参加させるかの設計にある。
02
曖昧な考えを、まず言葉にする
新しい機能を思いついたら、まず AI と話す。何を解決するのか。もっと簡単な方法はないか。まだ分からないことは何か。それを整理してから作るかどうかを決める。
01
漠然とした案
方向だけがあり、要件はまだ固まっていない。
02
問いを出させる
AI に質問させ、自分が答える。
03
議論を重ねる
利用場面と制約を言葉にしていく。
04
要件に落とす
要件、Scope、技術方向、UI を固める。
05
第二の視点
別のモデルに見せ、盲点を探す。
06
方向を決める
合意した方向を Demo と設計規則へ渡す。
漠然とした案問いを出させる
まず問いから始める。
問いを出させる議論を重ねる
問いと答えを往復する。
議論を重ねる要件に落とす
言葉になった制約を要件へ。
要件に落とす第二の視点
固まった案を別の視点へ。
第二の視点方向を決める
見落としを戻して方向を決める。
詳しい開発ノート
思いついた瞬間に Coding Agent へ書かせることはしない。まず Chat で長く話す。AI に質問させ、自分が答え、要件・利用場面・Scope・技術方向・UI を少しずつ固めていく。Brainstorm に近い往復である。
重要なプロジェクトでは、整理した案を別の AI に見せて Second Opinion を取る。多数決のためではなく、自分が気づかなかった点を別のモデルで探すためだ。UI の方向は画像生成で先に感覚を作り、違えば直し、近づいてから Demo にする。
03
議論を、Agent が守れる境界にする
話がまとまったら、要件、デザイン、変更しない範囲を文書に残す。次の Agent が引き継いでも、プロジェクト全体を推測し直さずに進められる。
AUTHORITY
01PLAN
計画
Plan / Implementation Plan を先に置く。
02AGENTS.md
作業の約束
Agent が従う規則を一箇所に置く。
03DESIGN.md
見た目の権威
見た目の判断を文書として固定する。
04SCOPE
触れない範囲
何を作らないか、何を変えないかを先に決める。
05EVIDENCE
確認済みの前提
確認済みの要件と検証結果を残す。
06GIT
変更の境界
branch と commit の単位を決めておく。
詳しい開発ノート
今は重要なプロジェクトで、議論の結果を正式な Authority に整理する。Plan / Implementation Plan、AGENTS.md、DESIGN.md、Scope と変更不可の範囲、確認済みの要件と検証結果、Git branch / commit の境界である。
この文書は Prompt を長くするためではない。毎回の Agent が「今なにを作るのか」を推測し直すのを避けるためである。Agent は自由に実装してよいが、その自由度は確認済みの境界の内側にある。
04
小さな作業に、全部隊は要らない
小さなバグや一つの修正は、軽く進めて確認する。複数モジュールや重要なデザイン変更には、計画、分担、レビューを用意する。作業の大きさに合わせて進め方を変える。
| Small / clear task | Complex / important project |
|---|---|
| 単一の修正、小さな Bug | 新規案件、複数モジュールの変更 |
| 軽い流れ、速い確認 | Brainstorm / Spec / Multi-Agent / Review / 検証の完全な流れ |
| Context は仕事を終えるのに足りればよい | 無差別に全部を渡さず、段階ごとに境界を切る |
詳しい開発ノート
小さな Bug、単一の修正、境界が明確な作業は、軽い流れで素早く処理する。ここで完全なワークフローを起動し、大量の Repository Context を読み込むと、作業が重くなるだけでなく Token も大量に消費する。
新規プロジェクト、複数モジュールにまたがる変更、重要な UI、構造の調整、リスクの高い修正 —— Complex で重要な作業だけが完全な流れを使う。原則は一つである。More context is not always better context。Context は仕事を終えるのに足りればよく、プロジェクト全体や過去の議論を無差別に詰め込むものではない。
05
AI は手であり、一緒に考える相手でもある
AI には方法の検討、実装、確認を手伝ってもらう。要件、優先順位、最後の採用判断は自分で決める。分からない書き方は説明してもらい、実際の機能で確かめる。
RESPONSIBILITY
01
AI
THINK WITH ME —— 一緒に考え、盲点を探す。 BUILD FOR ME —— 実装、Debug、Refactor、Test、Documentation。 REVIEW WITH ME —— 構造、Code、Visual QA、Regression、検証結果の整理。
02
HUMAN
DEFINE —— 問題と範囲を定義する。 DECIDE —— 採用・差し戻し・統合を決める。 DIRECT —— 優先順位と方向を指示する。 VERIFY —— 最後の結果を受け入れる。
見積項目 — AIで項目を作るための入力画面。
詳しい開発ノート
私のワークフローでは、AI には大きく三つの役割がある。THINK WITH ME —— Brainstorm、Research、Second Opinion、盲点探し。BUILD FOR ME —— Coding、Debug、Refactor、Test、Documentation、Implementation。REVIEW WITH ME —— Architecture Review、Code Review、Visual QA、Regression Check、検証結果の整理。
人は DEFINE → DECIDE → DIRECT → VERIFY を担う。Human as PM とは、人が技術から離れることではない。人の価値が、要件の理解、構造の判断、Scope、優先順位、受け入れへ移っていくということだ。
06
同じ AI に、すべての判断を任せない
重要な変更は、実装した Agent の自己確認に加えて別の Agent に見てもらう。視点を増やせば必ず正しくなるわけではないが、同じ会話では見落とした問題に気づきやすい。
INDEPENDENT REVIEW
- 01PLAN
計画
範囲と分担を先に決める。
- 02BUILD
実装
分担した役割が実装を進める。
- 03INDEPENDENT REVIEW
別の視点で確認
同じ Context ではない Agent が確認する。
- 04FIX
差し戻して直す
指摘を実装へ戻して直す。
- 05VERIFY
再確認
直した後に、もう一度確認する。
書いた人と確認する人を分ける。
詳しい開発ノート
複雑なプロジェクトでは、仕事を分けて別の Agent に渡す。実装、難しい Debug、UI、Visual QA、Review のように、得意な部分をそれぞれが担う。重要なのは、書いた人と確認する人を分けることである。An independent review from another context keeps one judgment source from deciding everything。
構造の議論を終えてから別のモデルに一度見せ、開発後には別の Agent に構造・変更範囲・検証結果を確認させることもある。AI を増やせば必ず正しくなるからではなく、すべての判断が同じ Context から出るのを避けるためである。
07
AI に、正しいものを見せる
画面の確認にはデザイン、変更ファイル、スクリーンショット。機能の確認にはテスト結果も渡す。資料の量より、その作業に必要な内容を届けることを大切にしている。
BOUNDED CONTEXT
01
渡すもの
DESIGN PLAN CHANGED FILES TEST RESULTS SCREENSHOTS
02
渡さないもの
Repository 全体の走査 過去の議論のすべて 無関係なサービス接続
詳しい開発ノート
AI が実際に何を見ているかを、より明確に制御できることである。たとえば Review の依頼では、DESIGN、PLAN、CHANGED FILES、TEST RESULTS、SCREENSHOTS だけを渡し、Reviewer に Repository 全体を走査させない。
こうすると Scope を制御しやすく、Review の結論がどの資料に基づくのかも分かる。無関係な情報を足すことは、Token を浪費するだけでなく、古い要件と今の Authority を混ぜてしまう。
08
すべての AI Code を、逐行では読まない
AI が書いたコードを毎回一行ずつ読んだとは言わない。まず自動チェックを行い、構造を理解し、実際に操作する。重要な変更は別の視点でも確認し、問題があれば直す。
REVIEW ORDER
- 01AGENT CHECKS
まず Agent に走らせる
LSP、Tests、Typecheck、Build と既存の審査。
- 02STRUCTURE
構造を見る
余分なファイル、重複機能、妥当性を確認する。
- 03EXPLAIN
濃縮して説明させる
どの構造と書き方を使ったかを説明させる。
- 04OPERATE
実際に操作する
機能と UI を自分の手で動かす。
- 05FIX
戻して直す
問題を Agent に戻し、直して再検証する。
- 06INDEPENDENT
別の AI で確認
重要な変更だけ、独立した視点で確認する。
詳しい開発ノート
私の Review は順番に進む。まず Agent 自身に LSP、Tests、Typecheck、Build と既存の審査プロセスを実行させる。次に全体の構造が妥当か、余分なファイルや重複機能がないかを見る。AI には使った構造と実装を要約して説明させる。実際に機能と UI を操作する。問題があれば Agent に戻して直し、再検証する。重要な変更は別の AI で独立に確認する。
「すべての行を読んだ」ことで自信を作るのではなく、構造の理解、自動検査、実際の操作、複数ソースの Review で判断する。
09
PASS には、見える根拠が要る
「完成」の一言だけでは足りない。バックエンドはテストと実際の応答、画面は表示、モバイル機能は操作の流れを確かめる。できたかどうかを判断できる確認を選ぶ。
VERIFICATION
01
作業ごとに必要な検証記録の種類
LSP、Tests、Typecheck、Build、Diff、Changed Files、Screenshots、Device Test、Review。
02
画面の写しと実機の結果
画面は実際の Pixel を見て、実機の結果は人が流れを通して確認する。
詳しい開発ノート
作業によって必要な検証記録は異なる。LSP、TESTS、TYPECHECK、BUILD、DIFF、CHANGED FILES、SCREENSHOTS、DEVICE TEST、REVIEW などだ。Backend、Frontend、設定変更、Mobile App では検証の仕方がもともと違う。
UI は Build と Test がすべて緑でも、画面が設計に合っているとは限らない。Mobile も Widget Test だけでは足りず、実機で一度流れを通す必要がある。工程の結果は AI を信じるだけではなく、判断できるだけの確認記録を残す。
10
Pixel PASS は、Human PASS ではない
テストがすべて通っても、読みにくい画面はできてしまう。スクリーンショットを見て、ページを開き、文字、余白、画像、モバイル表示を確認する。最後のデザイン判断は自分で行う。
最後は、自分で確かめて決める。
- 01BUILD
実装
変更を小さく進める。
- 02SCREENSHOT
画面を記録
各幅で実際の画面を見る。
- 03REVIEW
別の視点
画像を渡して確認する。
- 04HUMAN
自分で判断
読みやすさと方向を確かめる。
- 05VERIFY
採用・修正
必要なら直して再確認。
案件管理 — 案件と状態を一覧する。
詳しい開発ノート
AI は Screenshot、Spacing、Typography、Responsive を確認し、Visual QA PASS を返せる。しかし自分でページを開いて全体の方向が違うと感じたら、その PASS は私の判断を置き換えられない。
もう一つ重要な経験がある。Visual Reviewer は実際に画像 Pixel を受け取らなければならない。ファイル名、パス、Manifest、文字による説明しか読んでいないなら、それを本当の視覚的な検収として扱うことはできない。流れの最後は常に IMPLEMENT → SCREENSHOT → AI VISUAL QA → HUMAN REVIEW → ACCEPT / REVISE である。
11
制御できない Context から、何を学んだか
困ったのは、AI が書けないことより、前の決定を忘れて完成した部分を変えてしまうことだった。仕様、変更範囲、バージョンを残し、修正の出発点を明確にした。
FAILURE → LEARNING
変更前
- PROMPT
- GENERATE
- FIX
- GENERATE
- FIX
変更後
- DEFINE
- PLAN
- BOUNDED BUILD
- REVIEW
- EVIDENCE
- DECIDE
境界を先に決めると、失敗は戻る合図になる。
詳しい開発ノート
初期の開発では、長い Context が切れた後、Agent は前に確認した方向を忘れ、できていたものをまた改めた。別の回が機能の重複や、互いに干渉する実装を生むこともあった。
Plan、AGENTS.md、DESIGN.md、Git、Scope Boundary、Independent Review、検証記録を加えてから、開発はかなり安定した。流れは PROMPT → GENERATE → FIX → GENERATE → FIX から、DEFINE → PLAN → BOUNDED BUILD → REVIEW → EVIDENCE → DECIDE へ変わった。
12
実験は続けるが、神格化はしない
ローカルモデルは続けている実験。実際に動かすと、VRAM、量子化、コンテキスト長が速度と安定性に影響することが分かる。複雑な開発は今もクラウドを中心に、ローカルでは研究を続けている。
LOCAL POSITION
実験は続ける。複雑な開発は、今もクラウドが主である。
- ローカル環境はデータを手元に置き、コストを制御しやすく、実験に向く。
- モデルの能力だけが変数ではない。VRAM、量子化、Context、速度、安定性が体験を左右する。
- 現在の構成や機種の断定はしない。
詳しい開発ノート
ローカルで VLM、OCR、Coding Harness を実際に動かしてきた。その経験から、モデルの能力だけが変数ではないと分かる。VRAM、量子化、Context の長さ、推論速度、安定性、計算リソースが、実際の体験を直接左右する。
ローカルの利点は、データを自分の環境に置け、使用コストを制御しやすく、実験に向くことである。ただし現段階では、大きく複雑な開発は主に cloud モデルを使う。Local AI は研究と実験を続ける platform であり、すべてを Local-first にすべきだという主張ではない。
13
Vibe Coding から AI-assisted Engineering へ
小さなアイデアは AI とすぐ試せる。プロジェクトが大きくなれば、問題、範囲、分担、確認を明確にする。まだ学びの途中だからこそ、AI に任せた部分を自分で理解し、操作し、判断したい。
QUESTIONS
01DEFINED
問題は定義されているか
方向ではなく、問題として書かれているか。
02BOUNDARY
触れてはいけないものを知っているか
Scope と変更不可の範囲が共有されているか。
03CONTEXT
Context は正しいか
古い要件と今の Authority が混ざっていないか。
04SOURCE
判断ソースは一つではないか
書いた人と Review する人が分かれているか。
05EVIDENCE
Test、Screenshot、Device で確認した記録があるか
Build と Test だけで終わっていないか。
06HUMAN
人は最後の結果を見たか
PASS を、人の判断に置き換えていないか。
HUMAN-IN-THE-LOOP
- 01DEFINE
定義
問題、方向、境界を人が決める。
- 02PLAN
計画
範囲と分担を先に固める。
- 03BUILD
実装
分担した役割が実装を進める。
- 04REVIEW
検証
別の Context から確認し、検証記録を残す。
- 05HUMAN
人の判断
採用・差し戻し・統合を決め、次の工程へ渡す。
詳しい開発ノート
まだ学びの途中だからこそ、AI に任せた部分ほど自分の目で確かめる。できたことを大きく見せるより、次に直せる形で残すことを優先する。
小さな Prototype、素早い実験、急に思いついた新機能は、AI と一緒にすぐ作るのに向いている。それも私が AI Coding に多く触れた最初の方法だった。
しかしプロジェクトが大きくなると、気にするのは「Prompt がどれだけ上手いか」ではなくなる。問題は定義されているか。AI は触れてはいけないものを知っているか。Context は正しいか。書いた人と Review する人が同じ判断ソースではないか。最後に Test、Screenshot、Device などの確認記録があるか。人は最後の結果を本当に見たか。
私が今理解している AI-assisted Engineering はこうである。人が問題、方向、境界、最後の決定を担い、AI が思考と実行の能力を増幅する。AI が書くコードはこれからも増えるだろうが、人の仕事は消えるのではなく、判断がより重要な位置へ移る。