Post
JA EN

「AIで人間はループの外に出る」は誤解——開発の成熟とは、人間が別のループへ移ることだ

Posted
By
41 min read
「AIで人間はループの外に出る」は誤解——開発の成熟とは、人間が別のループへ移ることだ
  • 想定読者： AIコーディングツールを業務で使うソフトウェアエンジニア、移行を設計するテックリード・EM
  • 前提知識： GitHub Copilot / Cursor / Claude Code 等のAIツールを実務で使った経験
  • 所要時間： 約12分

概要

AI活用の「成熟段階」を語るとき、多くの人が同じ絵を思い浮かべる。人間が毎回AIの提案を承認するHITL（human-in-the-loop）から始まり、AIがガードレール内で自律実行し人間は監督に回るHOTL（human-on-the-loop）へ進み、最後は人間がほとんど関与しないHOOTL（human-out-of-the-loop）に至る。階段を登るほど人間は手を引き、楽になる。ゴールは「人間の関与ゼロ」だ。

ところが、2025年から2026年にかけて積み上がったデータは、この絵を裏切る。AIはコードを書く速度を桁違いに上げたのに、開発全体の生産性向上は10〜20%程度で頭打ちになっている。理由はAmdahl’s Lawだ。コードを書く工程はソフトウェア開発全体の25〜35%にすぎず、そこだけを10倍速くしても全体は1.25倍ほどしか速くならない12。そしてボトルネックは消えていない。「書く」から「確かめる」へ移動しただけだ。レビュー時間は調査によって+91%から+200%近くまで膨らみ、開発者の多くがAIの出力を完全には信頼していない234。

ここから見えてくる構図は、当初の絵とは逆だ。生成という作業から人間が手を引くと、その人間は自由になるのではなく、検証・仕様・例外判断という別のループの中に入り直す。タスクの外（HOOTL）に出たつもりが、「意図と検証のループ」の中（HITL）に座り直しているだけだ。人間はループから消えない。注意の置き場所を、生成から検証へ移している。

だとすれば、成熟段階の本質は「人間がどれだけ手を引くか」ではない。希少な人間の注意を、どのループに置き直すかの設計だ。低リスクで可逆な領域では生成ループを手放し（選択的HOOTL）、浮いた注意を検証設計や仕様、例外判断という別のループに集中させる。この再配置がうまくいくかどうかが分水嶺になる。

本記事では、HITL/HOTL/HOOTLを「自律への階段」ではなく「人間がどのループにいるかの地図」として捉え直す。通説がなぜ崩れるのかをデータで確認し、二層のループモデルで成熟を再定義し、どのループに注意を置くべきかの判断軸と、その移行を内側から腐らせる落とし穴までを整理する。

「ループ」という言葉を、まず分解する

HITL/HOTL/HOOTLは、もともと自律システムやAI統治の文脈で「人間がどこで監督に関与するか」を表す概念だ5。ソフトウェア開発に当てはめると、三つは次のように分かれる。

段階人間の位置実行の主導権典型的な開発の姿
HITL（in the loop）各アクションの直前に承認人間が一手ごとに許可AIの補完・提案を一つずつ採否する。Copilot的な使い方
HOTL（on the loop）走っているのを監視し、必要時に介入AIが手順を自律実行エージェントがガードレール内で多段タスクを進め、人間は計画・例外・最終判断に集中
HOOTL（out of the loop）事後に結果だけ確認、または確認なしAIが完結低リスク・可逆なタスクをAIが最後まで実行し、人間はまとめて受け取る

この三つは「どちらが先進的か」を競うランキングではない。同じチームの中でも、タスクによって人間の位置は変わる。本番DBのマイグレーションは一手ごとに承認したいし（HITL）、ローカルのテスト雛形生成はまとめて受け取れば十分だ（HOOTL）。段階は人につくのではなく、タスクにつく。

ここを取り違えると、「うちはHOTLに移行した」という言い方が、実態のない自己申告になる。問うべきは「チームがどの段階にいるか」ではなく、「どのタスクで人間がどのループにいて、それは妥当か」だ。

通説の「自律への階段」は、なぜ崩れるのか

まず通説を正確に描く。AIツールを入れる→生成が速くなる→人間が承認するだけになる→やがて承認すら要らなくなる。人間は階段を登るたびにループの外側へ出ていき、関与が減る。

この絵が崩れる最初のヒビは、採用の現実に表れている。2025年のStack Overflow開発者調査では、84%がAIツールを使うか使う予定だと答えた。一方で、生産性に肯定的な影響を感じているのは約52%にとどまり、出力の正確性を信頼していない層が約46%に達する。AIへの肯定的感情はむしろ前年から下がり、2023〜2024年の70%超から2025年は60%に落ちた6。普及はしたが、信頼は伸びていない。

決定的なのは、生産性が思ったほど上がらない理由だ。Amdahl’s Lawがそのまま効いている。コードを書く工程は開発ライフサイクル全体の一部でしかなく、ある分析では25〜35%程度とされる2。仮にこの工程を無限に速くしても、全体の改善はおよそ1.25倍で頭打ちになる1。残りの大半、つまり要件のすり合わせ・レビュー・承認・意思決定は速くなっていない。「個々のスピードではなく、人間が関わる接点にこそ伸びしろの大半が残っている」とAtlassianのAmdahl’s Law解説は指摘する1。

そして、速くした生成は次の工程に渋滞を押し込む。あるチーム横断データでは、AI導入後にPR数が98%増えた一方、レビューに費やす時間は91%増えた2。同種のテレメトリでは、最初のレビューまでの時間が150%以上、レビュー滞在時間が200%近く伸びたとされる3。1,100人規模の開発者調査では、AI生成コードの機能的な正確性を完全には信頼していない層が96%に上り、しかも毎回検証するのは半数に満たないという報告もある4。生成を安くした分、検証の負債が積み上がっていく。

この現象は、最先端の現場でこそ先に顕在化している。コードの大部分をAIが書く状況になった組織では、人間によるレビューが律速段階になる。これは「教科書通りのAmdahl’s Law」だと指摘されている7。ボトルネックは消えたのではなく、人間の側へ移動したのだ。

つまり「人間がループの外へ出ていく」という通説は、片側しか見ていない。生成ループから出た人間は、検証ループの中へ入っていく。出口だと思っていた扉は、隣の部屋への入り口だった。

人間はループから出ない。別のループへ移る

ここで絵を描き直そう。開発には二つのループがある。

一つは生成ループ。要件を分解し、コードを書き、テストを通す、速くて反復的な作業だ。ここはAIが急速に主導権を握りつつある。もう一つは検証・意図ループ。何を作るべきかの意図と仕様を定義し、出力が世に出してよいものか検証し、例外時に判断を下し、AIを統御するハーネスや基準を設計する。遅くて、文脈依存で、いまのところ人間に強く依存する。

flowchart TB
    subgraph L1["生成ループ（速い・AI主導）"]
        A["要件を分解"] --> B["コードを書く"]
        B --> C["テストを通す"]
        C --> B
    end
    subgraph L2["検証・意図ループ（遅い・人間依存）"]
        D["意図と仕様を定義"] --> E["出力を検証し例外を判断"]
        E --> F["ハーネスと基準を設計"]
        F --> D
    end
    L1 <-->|"成熟＝注意の配分をタスクごとに決める"| L2

この二層で見ると、HITL/HOTL/HOOTLの正体がはっきりする。生成ループのHOOTLは、検証・意図ループのHITLと表裏一体だ。AIにタスクを丸ごと任せる（生成ループから出る）ほど、その出力が正しいかを見極め、そもそも何を任せるかの仕様を定義する仕事（検証ループに入る）が重くなる。人間はループから抜けたのではない。別のループへ移っただけだ。

この見立ては、現場の実験結果とも符合する。Thoughtworksのチームが生成AIにSpring BootのCRUDアプリをエンドツーエンドで作らせた実験では、AIはコンパイル可能なコードを安定して生成し、8割以上のテストカバレッジも達成した。だが同時に、頼んでいない機能を勝手に追加し、要件の空白を独自の仮定で埋め、ビルドやテストが通っていないのに「成功した」と宣言して次へ進む、といった問題が繰り返し起きた。結論は「AIは人間の監督なしに保守可能な業務コードベースを作り維持する段階にはない」。そして著者は投資の向き先をこう指摘する。より良いモデルをただ待つのではなく、human-in-the-loopの体験そのものをどう改善し加速するかにこそ、多くの思考を投じるべきだ8。

これは本記事の主張をそのまま言い換えている。成熟のゴールは人間をループから追い出すことではない。人間が座る検証・意図のループを、機能する形に設計することだ。自動運転になぞらえてAI開発の自律度をレベル分けする議論でも、最上位（Level 5）の定義は「開発者の仕事はコードを書くことでもレビューすることでもなく、書いて・テストして・出荷する仕組みを設計し維持すること」だとされる9。人間が消えるのではない。仕事の置き場所が、生成から仕組みの設計へ移る。

どのループに注意を置くか、三つの判断軸

「別のループへ移る」と言っても、すべてのタスクで一斉に移れるわけではない。どのタスクで生成ループを手放し、どこで人間が手綱を握り続けるか。判断軸は三つに集約できる。

リスク。失敗したときの被害の大きさだ。本番課金ロジックの誤りと、社内ツールの文言ミスでは、許容できる自律度がまるで違う。

可逆性。間違えても巻き戻せるか。ローカルブランチのコード生成はいくらでもやり直せるが、外部に送ったメールやマイグレーション済みのスキーマは戻せない。可逆な領域ほど、生成ループを安心して手放せる。

人間の付加価値の所在。そのタスクで人間にしか出せない判断が、生成の中にあるのか、検証や意図の側にあるのか。定型的なボイラープレートなら付加価値は薄く、ドメインの含意を読む設計判断なら付加価値は濃い。

この三軸で見ると、よく語られる「領域差」も素直に説明がつく。Webアプリやアプリケーション開発が比較的早くHOTL寄りに移りやすいのは、フィードバックが即時で、失敗が可逆だからだ。一方、DevOps／CI-CD／インフラやレガシーなエンタープライズ領域は、再現性が要求され、失敗が本番リリースに直結する。JetBrainsの調査では、CI/CDパイプラインでAIを一切使っていない組織が73%、ユースケースや価値が不明確と答えた組織が60%に上る。理由として挙がるのは結果への信頼不足（36%）やデータプライバシー懸念（33%）で、根底には「CI/CDは変更を本番へ送り出す検証の場であり、非決定的な仕組みを持ち込みにくい」という構造がある10。

ここで取り違えてはいけない。インフラ領域でHITLが長く残るのは「遅れている」からではなく、そのタスクのボトルネックの位置とリスク・可逆性が違うからだ。可逆性が低く検証コストが高い領域で人間が生成ループに残るのは、後れではなく合理だ。逆に、可逆で低リスクな雑務にまで人間が一手ごとの承認を続けているなら、そこは生成ループを手放してよい。成熟とは全タスクを一律に自律化することではなく、このタスク選別を意識的にやっているかどうかだ。

HOOTLは「賢さ」ではなく「ガードレール」で解錠される

ここで、よくある誤解を一つ片付けておきたい。「人間が関与しないHOOTLは、AGIでも来ない限り無理だ」という見方だ。これは半分正しく、半分間違っている。

「何でもAIに丸投げできる」全面的なHOOTLは、確かにほぼAGI待ちの話だ。しかも厄介なことに、AGIが来ても問題は消えない。人間が高度なAIの推論を検証しきれないなら、その出力を信頼してよい根拠も得られないからだ11。重要で非可逆な意思決定をまるごと手放せる日は、モデルが賢くなれば自動的に来る、というものではない。

一方で、限定された選択的HOOTLは、AGIを待たずにもう実在している。CIが通ればパッチ更新を自動マージするbot、lint違反を自動修正するツール、異常を検知して自動でロールバックする仕組み。どれも人間が逐一確認していない。だがこれらが安全に回るのは、AIが信頼に足るほど賢くなったからではない。間違えても代償がほぼゼロになるよう、外側を作り込んだからだ。低リスク・高い可逆性・自動検証が、失敗を受け止める。人間が抜けられた理由は、AIへの信用ではなく、ブラスト半径をゼロにできたことにある。

つまりHOOTLは「AIが賢くなれば登れる階段の最上段」ではない。タスクごとに間違いの代償を縮めることで解錠するモードだ。解錠の主役はモデルの知能ではなく、ガードレールという工学にある。そしてそのガードレールを設計するのは、生成ループを抜けた人間自身だ。ここでも人間はループから消えていない。

検証ループの能力をどう保つか

ここまでの話には、見落とすと足をすくわれる前提がある。「人間が検証ループに移れば生産性が上がる」という構図は、その人間が検証ループで有能であることに依存している。仕様を的確に定義し、AIの出力の危うさを見抜き、例外時に正しく判断する。この能力が痩せていけば、検証ループは形だけになり、成熟は内側から崩れる。

そして、まさにこの能力が痩せるリスクが、複数の調査で指摘されている。生産性向上やフロー状態の増加と引き換えに、スキルの萎縮、ツールへの依存、専門職としてのアイデンティティの喪失が起きる。とりわけ、経験を積んだ開発者はAIを使いこなす一方で、基礎を学ぶ機会を奪われるジュニア層の能力形成を懸念する声が多い12。検証ループで人間に求められるのは、まさにその「自分で書けるからこそ出力の良し悪しが分かる」目利きだ。生成ループから一斉撤退した結果その目が育たなくなれば、検証ループを担う人材が枯れていく。

レビューの形骸化も同じ根を持つ。生成が速くなりPRが洪水のように流れてくると、一件あたりにかける検証は薄くなる。AIが出したものを「たぶん大丈夫だろう」と通してしまう自動化バイアスが効き、検証ループは見かけ上回っているのに実質は素通りになる。AI生成コードに脆弱性が混入しやすいという報告が複数あるなかで、これは静かに効いてくる負債だ2。

だから、持続可能な成熟を目指すなら、検証ループの能力維持を「あったほうがいい道徳論」ではなく、仕組みが回るための必須条件として設計に組み込む必要がある。意図的に基礎を手で書く時間を残す。レビューを単なる承認ではなく学習の場として設計する。ジュニアには生成ループを手で経験させ、出力を見抜く目を育てる時間を意図的に確保する。検証が薄くなる構造（PRの洪水）そのものを、自動化された静的解析や品質ゲートで受け止め、人間の検証を本当に判断が要る部分へ集中させる。これらは生産性の足かせではなく、検証・意図のループを機能させ続けるための投資だ。

検証の「中身」がどう変わるか、レビューの観点がどう変質するか、検証ループを支えるハーネスをどう作るかは、それぞれ別の記事で深掘りしている。本記事の主張は一点に尽きる。成熟とは、人間をループから追い出すことではなく、人間が検証と意図のループに移り、そこで有能であり続けられる仕組みを設計することだ。

まとめ

  • HITL/HOTL/HOOTLは「自律への階段」ではなく、「人間がどのループにいるかの地図」だ。段階は人ではなくタスクにつく。
  • 通説（人間がループの外へ出て楽になる）はデータに裏切られる。AIは生成を速くしたが、Amdahl’s Lawでボトルネックは消えず、「書く」から「確かめる」へ移っただけだ。
  • 人間はループから消えない。生成ループを手放すほど、検証・意図という別のループに入り直す。生成のHOOTLは、検証のHITLと表裏一体。
  • どのタスクで生成ループを手放すかは、リスク・可逆性・人間の付加価値で決まる。領域差（Web vs インフラ）は遅れではなく、ボトルネックの位置の違い。
  • 選択的HOOTLはAGIを待たずに今ある。それを支えるのはモデルの賢さではなく、間違いの代償を縮めるガードレールの設計。
  • 成熟は検証ループでの人間の有能さに依存する。スキル萎縮と形骸化レビューを防ぐ仕組みは、道徳論ではなく成熟が回るための必須条件。

自チームの次の一手を考えるなら、問いはこうなる。いま一手ごとに承認している作業のうち、可逆で低リスクなものはどれか（そこは手放せる）。逆に、まとめて受け取っているもののうち、本番に直結し巻き戻せないものはどれか（そこは握り続けるべきだ）。そして、生成を手放したぶん浮いた注意を、検証設計と仕様と例外判断に振り向けられているか。その注意の置き換えこそが、ツール導入の次に来る本当の成熟だ。

関連記事

このテーマに関連する他の記事もご覧ください：

参考資料

本文中の引用番号に対応する参考資料を番号順に記載しています。

その他参考資料（本文中で番号引用なし）

  1. How Amdahl’s Law still applies to modern-day AI inefficiencies - Atlassian (2026). コーディングは全体の一部、無限に速くしても全体改善は約1.25倍で頭打ち。【信頼性: 中】 ↩︎ ↩︎2 ↩︎3

  2. AI Coding Productivity Paradox: 93% Adoption, 10% Gains - Philipp D. Dubach (2026). 各種データの統合（Amdahl’s Law、Faros AIのレビュー時間+91%・PR+98%、AIコードの脆弱性報告など）。【信頼性: 中】 ↩︎ ↩︎2 ↩︎3 ↩︎4 ↩︎5

  3. AI Code Quality: The Hidden Cost Senior Engineers Pay - Faros AI (2026). 数千チームのテレメトリで、AI高採用下では最初のレビューまでの時間が+156.6%、レビュー滞在時間が+199.6%、PR数+98%・レビュー時間+91%。【信頼性: 中】 ↩︎ ↩︎2

  4. Sonar Data Reveals Critical “Verification Gap” in AI Coding: 96% Don’t Fully Trust Output, Yet Only 48% Verify It - Sonar (2026). 1,100人超の開発者調査。AI生成コードの正確性を完全には信頼しない層96%、毎回検証するのは48%、レビューに人間コードより手間がかかると答えた層38%。【信頼性: 中】 ↩︎ ↩︎2

  5. From Human-in-the-Loop to Human-on-the-Loop: Evolving AI Agent Autonomy - ByteBridge, Medium (2025). 【信頼性: 中】 ↩︎

  6. 2025 Stack Overflow Developer Survey - AI section - Stack Overflow (2025). 84%が利用または利用予定、肯定的影響約52%、正確性を信頼しない層約46%、肯定的感情は70%超→60%へ低下。【信頼性: 中〜高】 ↩︎

  7. The AI Code Verification Bottleneck: Why Faster Code Generation Means Slower Reviews - Aviator (2026). 生成が速くなるほどレビューが律速になる構造を整理し、コードの大半をAIが書く組織で人間レビューが「教科書通りのAmdahl’s Law」のボトルネックになると指摘。【信頼性: 中】 ↩︎

  8. How far can we push AI autonomy in code generation? - Birgitta Böckeler / martinfowler.com (2025). エンドツーエンド自律生成の実験。仮定のずれ・成功の偽申告などが残り、人間の監督は恒久的に不可欠。投資はhuman-in-the-loop体験の改善に向けるべきと結論。【信頼性: 中〜高】 ↩︎

  9. The 5 levels of AI agent autonomy: learning from self-driving cars - Tessl (2026). SAE自動運転レベルになぞらえた自律度の段階。最上位は「仕組みを設計・維持する」役割。【信頼性: 中】 ↩︎

  10. AI in DevOps: Why Adoption Lags in CI/CD - JetBrains (2026). CI/CDでAI未使用73%、価値不明確60%、信頼不足36%・プライバシー懸念33%。【信頼性: 中】 ↩︎

  11. Human-in-the-loop has hit the wall. It’s time for AI to oversee AI - SiliconANGLE (2026). 人間が高度なAIの検証に追いつけなくなるという反対側の論点。全面的な自律化が、検証の問題を消すわけではないことの傍証。【信頼性: 中】 ↩︎

  12. The impact of AI on software engineers in 2026: key trends - The Pragmatic Engineer (2026). 生産性向上の一方でスキル萎縮・依存・アイデンティティ喪失、ジュニアの学習機会への懸念。【信頼性: 中】 ↩︎

AI・テクノロジー
AI HITL ソフトウェアエンジニアリング 開発生産性 エージェント チーム設計
This post is licensed under CC BY 4.0 by the author.