はじめに
AI コーディングエージェント（Claude Code など）を本格的に運用し始めると、ある時点で必ずこの問いにぶつかります。「この作業、エージェントに任せきりでいいのか？ それとも筆者が見ていないとダメなのか？」 です。
最初のうちは「全部見ていないと不安」で、結局すべての出力をレビューしてしまいます。すると、エージェントを導入したのにスループットが上がりません。逆に「全部任せる」に倒すと、verdict（合否判定）が雑なまま緑になったテストを信じてマージし、後で痛い目を見ます。
この問題を整理するうえで筆者が一番効いたのが、作業を「AFK 作業」と「HITL 作業」の2軸で仕分けるという考え方でした。本記事では、この2つの作業区分を中心に、関連する作業タイプも含めて「エージェント開発における作業の地図」を共有します。
この記事でわかること
- AFK 作業 / HITL 作業の定義と、どこに線を引くか
- 2つだけでは足りない理由と、間を埋める関連作業（Harness 整備・スコープ定義・割り込み操舵・知識の書き戻し）
- 自分のワークフローで「どの作業を誰がやるか」を表に落とす方法
対象読者
- Claude Code / Cursor などのエージェントを日常的に使っている人
- 「どこまで任せて、どこで自分が出るか」を一度言語化したい人
- エージェント運用の属人性を減らしたいチームリード
背景 ― なぜ「作業の仕分け」が必要か
エージェントのスループットは、人間のレビュー速度を簡単に追い越します。AFK（Away From Keyboard）スタイル、つまり「指示を出して席を離れ、複数セッションを並列で走らせる」運用にすると、生成される差分の量は一人の人間が目視できる量をあっさり超えます。
ここで起きるのが 「レビューがボトルネックになる」 現象です。添付記事では、エージェントのスループットに対してスケールするのは「個々の出力をレビューする human-in-the-loop」ではなく「ハーネスそのものを保守する humans on the loop」だけだ、と指摘しています（Harness engineering for coding agent users, 2026-04）。
とはいえ「全部ハーネスに任せて人間は手を引け」という話ではありません。人間の判断を“なくす”のではなく、“最も価値が出る場所に集中させる” ための仕分けが要る。その第一歩が、AFK 作業と HITL 作業の線引きです。
1. AFK 作業 ― エージェントが自律で緑にするところまで
AFK 作業とは、エージェントが人の立ち会いなしに自律的に進められる作業です。具体的には、実装・テスト作成・テスト実行・型チェック・lint 修正といった、「コードを書いて緑にする」までの機械的な工程を指します。
AFK の語源は文字どおり "Away From Keyboard"。Matt Pocock の AI コーディング用語集では、AFK を「セッションを開始して、エージェントを無人で走らせる作業パターン」と定義しています（dictionary-of-ai-coding / AFK）。
ここで強調したいのは、AFK は「エージェントに好き放題やらせる」ことではないという点です。AFK が成立する前提は次の通りで、これらはすべて人間側が用意します。
- スコープが明確に切られている（何を作るかが曖昧でない）
- 合否を判定できるテストや検証手段が存在する
- 副作用（commit / push / 外部呼び出し）にガードレールが掛かっている
筆者の場合、自作の test-harness MCP（dev サーバーの起動・停止・状態・ログ取得を4ツールに閉じ込めたもの）がこの「自律で回せる足場」の中核になっています。エージェントは harness_start でアプリを立ち上げ、smoke test を流し、harness_logs で結果を観測する、というループを人間抜きで回せます。
# AFK 作業の典型ループ（人間は不在）
1. 指示されたスコープのコードを書く
2. harness_start でアプリ起動
3. テストを実行 → 失敗ログを harness_logs で観測
4. 失敗を直す → 2 に戻る
5. すべて緑になったら停止して報告
このループの中に 人間の判断が一切要らない ことがポイントです。判定基準（テスト・型・lint）がすべて決定論的（computational）なので、エージェントは自分で回り続けられます。
2. HITL 作業 ― 人間の目視と判断が必須の作業
**HITL 作業（Human In The Loop）**とは、人間（あなた）の目視・判断がなければ前に進められない作業です。AFK のループが「緑になった」と言ってきた、その緑を 信じてよいか を決めるのが HITL の仕事になります。
筆者の運用で HITL に分類しているのは、主に次の2つです。
- verdict の妥当性レビュー ― エージェントが「テストは通った／要件を満たした」と出した判定（verdict）が、本当に妥当かを人間が確認します。テストが緑でも、テスト自体が間違っている／観点が抜けていることはよくあります
- Verify Gate の合否判定 ― マージや次工程に進めてよいかの関門。ここを通すかどうかは、最終的に人間の責任で決める
AFK 作業のところで「判定基準は決定論的」と書きましたが、現実の品質判断には 決定論では割り切れない領域（inferential＝確率的・意味的な判断） が残ります。Fowler はハーネスの制御を computational controls（lint・テストのような決定論的検証） と inferential controls（LLM による意味的判断） に分けていますが、HITL 作業はこの inferential の最終段に 人間 を据える行為だと捉えると見通しが良くなります。
重要なのは、Verify Gate を「テストが緑かどうか」だけで自動通過させないことです。緑は必要条件であって十分条件ではありません。緑の上に人間の verdict を一段重ねるのが HITL の本質です。
3. 2つだけでは足りない ― 間を埋める関連作業
AFK と HITL の2軸は強力ですが、実際のワークフローを回すと「どちらにも分類しづらい作業」が出てきます。ここを言語化しておくと、仕分けの解像度が一段上がります。筆者が補助線として使っている4つを紹介します。
3-1. Harness 整備作業（humans on the loop）
エージェントが AFK で回れるのは、ハーネス（CLAUDE.md・Skill・MCP・テスト・サンドボックス）が整っているからです。この ハーネス自体を作り、保守する作業 は、エージェントに任せきれない人間の中核仕事になります。
Fowler が「スループットに対してスケールするのは humans on the loop だ」と言うときの "on the loop" がまさにこれです。個々の出力を見る（in the loop）のではなく、出力を生み出す仕組みを見る（on the loop）。テストの観点を足す、MCP のツール description を直す、ガードレールを強化する ― これらは AFK の品質を底上げする一番効率の良い投資です。
3-2. スコープ定義作業（AFK の前提づくり）
AFK が成立するかどうかは、作業前にスコープをどれだけ明確に切れたかでほぼ決まります。曖昧な指示で AFK に入れると、エージェントは「それっぽいが要件とズレた緑」を作って戻ってきます。
要件を構造化して渡す（Structured Prompt-Driven Development 的なアプローチ）こと自体が、独立した人間の作業です。ここをサボると HITL の差し戻しが増え、結局トータルで遅くなります。
3-3. 割り込み操舵作業（steering）
AFK は「完全放置」と「常時監視」の二択ではありません。その中間に、走っている最中に方向修正だけ入れる作業があります。エージェントが明らかに筋の悪い方向に進み始めたら割り込んで軌道修正し、また AFK に戻す。
AFK 系ツールの中には、エージェントが詰まったら通知を飛ばして人間を呼ぶものもあります（Agent AFK は完了時／スタック時に push 通知を送る設計）。「ずっと見る」のではなく「呼ばれたら出る」運用にすると、並列セッションを破綻なく捌けます。
3-4. 知識の書き戻し作業（Feedback Flywheel）
HITL で「ここがダメだった」と判断したら、それを 次回の AFK 品質に反映する までが一仕事です。差し戻しの理由を CLAUDE.md やテスト観点、Skill に書き戻す。これをやらないと同じ差し戻しが永遠に続き、認知的負債（Cognitive Debt）が溜まります。
つまり HITL → Harness 整備への フィードバックループ を閉じることが、エージェント運用を「回せば回すほど楽になる」状態に持っていく鍵です。
4. 作業を一枚の表に落とす
ここまでの作業タイプを、「誰が主体か」「自律度」で整理すると次のようになります。
| 作業タイプ | 主体 | 自律度 | 具体例 |
|---|---|---|---|
| スコープ定義 | 人間 | 低 | 要件の構造化、受け入れ条件の明文化 |
| Harness 整備 | 人間（on the loop） | 低 | CLAUDE.md・Skill・MCP・テスト観点の保守 |
| AFK 作業 | エージェント | 高 | 実装・テスト作成・緑化・lint 修正 |
| 割り込み操舵 | 人間（呼ばれたら） | 中 | 方向修正、詰まりの解消 |
| HITL 作業 | 人間 | ― | verdict 妥当性レビュー、Verify Gate 合否判定 |
| 知識の書き戻し | 人間 | 低 | 差し戻し理由を共有資産へ反映 |
この表のいいところは、「自分のスループットが上がらない原因」がどこにあるかを名指しできる点です。たとえば「HITL でレビューに溺れている」なら、Harness 整備（3-1）と知識の書き戻し（3-4）への投資が足りていない、と原因を切り分けられます。
ハマりどころ
実際にこの仕分けで運用していて踏んだ罠を3つ挙げます。
緑を verdict と混同する
一番多いのがこれです。テストが緑になった＝合格、と短絡してしまう。AFK が出すのは「テストが通った」という事実であって、「要件を満たした」という保証ではありません。緑は AFK の出力、verdict は HITL の判断、と層を分けて扱うのが鉄則です。
Harness 整備をいつまでも後回しにする
目の前の差し戻し対応（HITL）に追われて、その原因をハーネスに書き戻す作業（on the loop）を後回しにすると、同じ差し戻しが延々と再発します。HITL で気づいたことは、その場で Harness 整備に1行でも反映するのが、結局いちばん速い。
AFK と HITL の境界をプロジェクトで固定してしまう
線引きは固定ではありません。ハーネスが育ってテスト観点が厚くなれば、これまで HITL で見ていた領域を AFK に倒せるようになります。逆に、新規性が高く検証手段が未整備な領域は、いったん HITL 寄りに戻すべきです。境界は「ハーネスの成熟度」とともに動くものだと捉えておくと、運用が硬直しません。
まとめ
- エージェント開発の作業は、まず AFK 作業（自律で緑にする） と HITL 作業（人間が verdict と Verify Gate を判定する） の2軸で仕分けると見通しが良くなる
- ただし2軸では足りず、間を スコープ定義・Harness 整備・割り込み操舵・知識の書き戻し が埋める。とくに Harness 整備（humans on the loop）と知識の書き戻しが、AFK の品質を底上げする投資になる
- 緑（AFK の出力）と verdict（HITL の判断）を層として分けること、そして HITL で得た学びを Harness にフィードバックして境界を動かしていくことが、回すほど楽になるエージェント運用の核心
エージェントのスループットは今後も上がり続けます。だからこそ、人間が「どこに出るか」をあらかじめ決めておく ― それが AFK / HITL という仕分けの実用的な価値だと筆者は考えています。
参考
- Harness engineering for coding agent users — Martin Fowler
- Humans and Agents in Software Engineering Loops — Martin Fowler
- AFK — dictionary-of-ai-coding (Matt Pocock)
- AFK | AI Coding Dictionary — aihero.dev
- Agent AFK — the coding agent that works while you're away
- awesome-harness-engineering — GitHub