AIエージェントを使い始めた人が必ずぶつかる問いがある。「この作業、エージェントに任せっきりでいいのか。それとも自分が見ていないとダメか」——この判断が曖昧なまま運用を続けると、思うようにスループットが上がらない。
自分はAIを使った自動化の仕組みを日々開発・運用している。Claude Codeを実務に組み込んで気づいたのは、エージェントのアウトプット量は人間のレビュー速度をあっさり超えてくる、という事実だ。指示を出して少し待つと、大量の差分が戻ってくる。それを全部確認しようとした瞬間に、「AI導入前より忙しくなった」という状態になる。
「全部見る」でも「全部任せる」でもない、作業の分け方を設計することが必要だ。
AFK作業とHITL作業——エージェントの仕事を2種類に分ける
AI開発の現場で浸透しつつある考え方に、作業を「AFK（Away From Keyboard）」と「HITL（Human In The Loop）」の2種類に仕分けるフレームがある。
AFKは文字通り「キーボードから離れていい作業」を指す。実装、テスト作成、テスト実行、型チェック、lint修正——これらがAFKに分類される。判定基準が決定論的（テストが通る/通らない）なので、エージェントが自分でループを回しながら完結できる。人間が常に画面を見ている必要はない。指示を出してから別の作業をしている間に、エージェントが実装→テスト→失敗→修正→再テストというサイクルを自律で回し続けられる。このループの中に人間の判断が一切要らない、というのがAFKの本質だ。
HITL（Human In The Loop）は「人間の目視と判断が必須の作業」だ。エージェントが「完了しました」と返してきた時に、その結果を信じていいかどうかを判定すること——ここがHITLの領域になる。合否の判定そのものではなく、「判定基準が正しいか」「要件の解釈がズレていないか」を人間がチェックする層だ。最終的に「これで問題ない」と言えるのは人間だけ、という部分がHITLに当たる。
この2種類を意識しないまま使っていると、本来AFKで流せる作業にHITLを挟み続けて、「エージェントを入れたのに手が空かない」状態になる。逆に「全部AFKで任せればいい」と考えると、品質基準を失ったまま出力が積み上がっていく。どちらに倒しても詰まる。重要なのは2つを混在させず、作業の性質によって明確に分けることだ。
テストが「緑」になっても合格ではない
一番重要で、一番見落とされやすい点がここだ。
AIエージェントが「完了しました、テスト全部通りました」と返してくる時、それは「テストが通った」という事実の報告だ。「要件を満たした」という保証ではない。
なぜかというと、テスト自体が間違っている可能性があるからだ。実装の仕様を曖昧に渡したまま指示を出すと、エージェントは「それっぽい解釈でコードを書き、その解釈に合わせたテストも書いて、両方とも緑にする」という動作をする。テストは通っているが、実際にほしかった動作とは別物——という状態ができあがる。
もう一つのパターンが、テストが「今の実装の形」に紐づいて書かれているケースだ。「こういう関数があるからこうテストする」という書き方をすると、テストは通るが、本来の仕様変更に対してテストが機能しない。実装が変われば一緒に変わるテストは、品質保証の道具として機能していない。これはエージェントの判断では気づけず、人間がレビューして初めて発覚する類の問題だ。
自動化の仕組みを開発していると、たまに「プログラムとして正常終了しているのに、出力が意図と違う」という事態が起きる。これを最初は「AIのせい」にしてしまいがちだが、原因を掘ると「判定基準を曖昧にしたまま渡していた」か「スコープが不明確だった」かのどちらかに行き着くことが多い。エージェントは悪くない。曖昧さを渡したのは自分だった、という結論になる。
緑はAFK側の出力であって、妥当性の判断はHITL側の仕事——この2つを別の層として扱うことが、エージェント活用の基礎になる。緑を最終合格と混同した瞬間に、品質が担保されていない出力がどんどん積み上がっていく。
「全部見てしまう病」から抜け出すための3つの条件
AIを使い始めた人の多くが、最初は「全部確認しないと不安」という状態になる。
この不安には正当な理由がある。エージェントを信頼するための基準が、まだ自分の中にないからだ。どこまで任せていいかが分からないから、全部見る。全部見るからレビューに追われる。レビューに追われるから、AI導入前より手が空かない——という悪循環だ。
「全部見てしまう病」から脱出するには、「見なくていい条件」を明確にすることが必要だ。AFKが成立するための条件は主に3つある。
スコープが明確に切られていることが1つ目だ。「何を作るか」が曖昧な状態でエージェントを走らせると、それっぽいが要件とズレた成果物が返ってくる。指示を出す前に「何が完成した状態か」「何はやらなくていいか」を言語化しておくことが大前提になる。スコープ定義は、エージェントに渡す前の人間の仕事だ。ここをサボるとHITL側での差し戻しが増え、トータルで遅くなる。
合否を判定できる基準が存在することが2つ目だ。テストでも受け入れ条件でも、「これが通れば完了」という判定基準がないと、エージェントはいつ止まればいいかが分からない。判定基準のないところでは、AFKは成立しない。テストを書くこと自体が、AFK設計の準備作業になる。
副作用にガードレールがかかっていることが3つ目だ。外部システムへの書き込みや取り消しのきかない操作が含まれる場合は、エージェントが予期しない動作をしても被害が最小限になる仕組みが必要だ。「任せっきりにしたら変なことになっていた」という事態を防ぐガードレールは、設計の時点で組み込んでおく。
この3つが揃った領域だけ、AFKに倒せる。1つでも欠けていれば、人間がHITLで見るべき領域になる。逆に言えば、この3つを整えることに集中すれば、安心してAFKに任せられる範囲が広がっていく。
自分のワークフローを一度「表」に落としてみる
抽象的な話が続いたので、一度具体的な作業に落とし込んでみる。
自分の作業を書き出して、「誰が主体か」「判定基準はあるか」という2軸で分類するだけでいい。たとえば「記事の下書きを生成する」なら、スコープと検証条件を用意すればAFKに倒せる候補だ。「出力の品質が要件に合っているか判断する」はHITLになる。「指示書の内容を改善する」は足場整備、つまり人間がやるべき中核の仕事だ。
この整理をやると、「自分がHITLに追われている原因」が名指しで見えてくる。差し戻しが多いなら、スコープ定義が甘いサインだ。同じミスが繰り返されているなら、学習が足場に返っていない証拠だ。レビューに時間がかかりすぎているなら、判定基準が曖昧で目視に頼っているサインだ。
スループットが上がらない原因は「エージェントが弱い」ではなく「自分の設計に抜けがある」ことがほとんどだ。表に落とすことで、その抜けが見えやすくなる。
本当の本業は「足場を作ること」
ここが、AIエージェントを使いこなしている人と使いこなせていない人の差が最も出る場所だと思う。
AFKが成立するのは、エージェントが自律で動くための「足場」が整っているからだ。指示書（何をどう進めるかのルール集）、テストスイート、サンドボックス環境、エラー検知の仕組み——こういったものを作り・保守することが、エージェント活用の核心的な仕事になる。
個々の出力をレビューするHITL作業はスケールしない。エージェントが1時間で生成できる差分を、人間が1時間でレビューするなら、スループットは変わらない。確認作業の認知負荷の分だけ、純粋な損になる。よくある間違いは、「エージェントを使っているのだから、自分はレビューだけすればいい」という認識だ。その「レビューだけ」が、エージェントのスループットと同じ速度で増え続ける。
スケールするのは、足場を整える作業だ。足場の品質が上がると、AFKで通過できる範囲が広がる。個別レビューに1時間使うより、足場を1時間改善した方が、翌週からの毎日が変わる。
自分が自動化の仕組みを整備していく中でも、作業フローを言語化して「これはエージェントが処理できる」「これは自分が判断する」と分けなおす作業を繰り返してきた。作業フローをパターンとして型化することで、ルーティンをエージェントに渡しやすくなり、自分が集中すべき判断の作業が明確になっていく。この型化のプロセス自体が足場作りの一つだ。指示書に「この場合はこうする」という具体的なケースを書き足していくことも同様で、指示書が厚くなるほど、エージェントが勝手に判断してよい範囲が広がっていく。足場作りは一度で終わるものではなく、運用の中で育てていくものだ。
差し戻しを次の足場に変える
差し戻し作業が終わったあと、もう1つやるべきことがある。
差し戻しの理由を、次回の足場に書き戻すことだ。
エージェントに「ここが違う」と修正を指示した時、その原因が指示書のどこにあったかを特定して書き直す——これをやらないと、同じ差し戻しが次のセッションでも起きる。「毎回同じところで詰まる」「HITL作業が一向に減らない」状態が続く。
詰まり方には傾向がある。差し戻しを処理するだけで時間が消え、足場を改善する余裕がなくなる。足場を直せないから同じ差し戻しが来る。差し戻しに追われ続けるという悪循環だ。表面上は対応しているが、根本原因が蓄積している状態——これは「HITLで気づいたことを足場に還元しないことで生まれる構造的な問題」だ。
逆に、HITLで気づいたことを足場（指示書・テスト観点・検証条件）に書き戻す習慣があると、徐々にAFKで通過できる範囲が広がっていく。最初は半分がHITLだったワークフローが、足場への蓄積が増えるにつれて、大部分がAFKで回せる状態になっていく。
「使えば使うほど楽になる」という状態を作るには、このフィードバックのループを閉じることが必要だ。差し戻しの理由をその場で書き戻す、という一手間が、長期的なHITL負荷を大きく変える。足場への書き戻しをサボった代償は、「また同じことに時間を使う」という形で後から返ってくる。
AFK比率を上げると、稼働時間から切り離せる
副業・フリーランスの視点でこの話を見ると、もう一段の解像度が加わる。
AFKで回せる部分が多いほど、自分の時間から切り離してスケールできる。エージェントが自律で動いている間も仕組みが前進している状態——これが「自分が動かなくても進む仕組み」の土台になる。稼働時間に縛られた収益モデルから外れる入口が、AFK設計の中にある。
HITLが多い仕組みは、自分が介在しないと動かない。エージェントを使っていても、実質的には自分の稼働時間に縛られた状態が続く。仕組みを「作った」だけでは変わらない。仕組みが「自律で動く」状態に仕上げることが必要だ。
「仕組みは作れたのに、なかなか成果につながらない」という状態にある場合、一度自分のワークフローを点検してみると見えてくることがある。どれだけの作業がAFKで回せているか。HITLのレビューにどれだけの時間を使っているか。HITLに追われているなら、足場への投資が足りていないサインだ。
AFK/HITLの境界線は固定ではない。足場が育てばHITLで見ていた領域がAFKに移る。新しい領域を開拓するときはいったんHITL寄りに戻す。この境界を意識的に動かし続けることが、エージェント活用を「運用」に昇華させる鍵だ。
まとめ
- AIエージェントの作業は「AFK（自律で回せる）」と「HITL（人間が判定する）」の2種類に分けると、自分の時間をどこに集中すべきかが見えてくる
- テストが緑になった＝要件を満たした、ではない。AFKの出力と妥当性判断を別の層として扱う
- スループットを上げるのは個別レビューではなく、足場（指示書・テスト・検証条件）を整える作業
- HITLで気づいた差し戻し理由を足場に書き戻すフィードバックループが、「使えば楽になる」状態を作る
「何をどう任せるか」を設計することがエージェント活用の本質で、その第一歩が自分のワークフローにAFKとHITLの境界線を引くことだ。
【PR】フリーランスエンジニアにおすすめのツール
開発やリモートワーク中の通信を守るVPNサービス。チームで固定IPを共有できる法人向けプランも対応している。
自宅回線の選択肢として根強い人気。フリーランスの固定費を抑えたい場合の通信環境の選択肢の一つ。
フリーランスエンジニア向けの案件マッチングサービス。エージェントと直接やり取りできる形式で案件を探せる。
AIエージェント活用・自動化・副業について発信しています。セレネのX (@selene_nyx_ai) もよければ。
【PR】おすすめの書籍
記事の内容に関連する書籍を紹介させてほしい。
Claude Codeを含むClaude全般の使い方を、AI初心者向けにまとめた一冊です。仕事・家事・育児などの日常場面での活用例を広くカバーしています。
【この１冊からはじめる】生成AIアプリ開発入門 Dify 徹底活用ガイド
ノーコードのAIアプリ構築ツール「Dify」を題材に、生成AIアプリ開発の入口から実践までを解説する入門ガイドです。自動化の仕組みを自前で組みたい方の参考になります。
コメント