はじめに
AI コーディングの議論では、「どこまで AI に任せられるのか」という問いがよく出ます。
ただ、実務で本当に重要なのは、もう少し具体的な問いです。
人間は何を決め、AI はどう実行するのか。
Anthropic が 2026 年 6 月に公開した Agentic coding and persistent returns to expertise は、この問いを考えるうえでかなり重要な一次情報です。約 40 万件の Claude Code セッション、約 23.5 万人のユーザー、2025 年 10 月から 2026 年 4 月までの利用データをもとに、Claude Code が実際にどのように使われているかを分析しています。
最近は「Loop Engineering」という言葉でも同じ潮流が語られています。ただし、少なくとも確認できる範囲では、Anthropic がその名称で公式レポートを出しているわけではありません。この記事では言葉の流行ではなく、Anthropic の公式データから見える「人間と AI の役割分担」を整理します。
人間は「何をするか」を決めている
Anthropic の分析で最も象徴的なのは、意思決定の分担です。
同レポートでは、Claude Code のセッション内の意思決定を、計画に関する判断と実行に関する判断に分けています。計画とは「何をするか」「どの方針で進めるか」「何をもって完了とするか」。実行とは「どのファイルを変更するか」「どんなコードを書くか」「どのコマンドを走らせるか」といった判断です。
結果として、典型的なセッションでは、人間が計画判断の約 70% を担い、実行判断の約 20% を担っていました。裏返すと、Claude は実行判断の約 80% を担っていることになります。
これは「AI が人間を置き換えた」という話ではありません。
むしろ、役割が分かれ始めているという話です。人間は、目的、制約、完了条件、優先順位、リスク許容度を決める。AI は、その範囲の中でファイルを読み、コードを書き、コマンドを実行し、結果を見ながら修正する。
AI 時代のエンジニアリングで価値が上がるのは、細かい作業指示を逐一出すことではなく、正しい問題設定と検証可能な完了条件を設計することです。
AI は「どう実行するか」を広く担い始めている
同じレポートでは、Claude Code の作業内容も分類されています。
約 56% のセッションは、コードの作成、修正、テスト、オーケストレーションに関わるものでした。さらに 17% はソフトウェアの運用、14% は計画や探索、13% はデータ分析や文章作成など、コード以外またはコードが副次的な成果物になる作業です。
ここから見えるのは、AI コーディングが「コード補完」からかなり離れていることです。
Claude Code は、1 回のユーザープロンプトに対して平均で約 10 個のアクションを実行し、場合によっては 100 個を超えるアクションを連鎖させています。ファイルを読み、差分を作り、コマンドを実行し、結果を見て次の手を決める。人間が一つひとつの作業を細かく指定するのではなく、AI が作業単位を内部で展開している状態です。
ここで人間に残る仕事は、「次にこのファイルを読んで」と指示することではありません。
AI が探索してよい範囲を決めること。失敗したときに戻る基準を決めること。通すべきテスト、見比べるべき画面、守るべき設計原則を用意することです。
Anthropic の Claude Code best practices でも、Claude にテスト、ビルド、スクリーンショット比較など、作業を検証できる手段を与えることが強調されています。AI に「完了したように見える」だけで止まらせず、合否の信号を読ませる。ここが、AI に実行を任せるための前提になります。
経験者ほど、AI に多くの仕事をさせている
興味深いのは、経験者が AI を「少なく使う」のではなく、むしろ「大きく使っている」点です。
Anthropic の分析では、ユーザーの専門性が高いほど、1 回の指示から Claude が実行する作業量が増えています。初心者に分類されたセッションでは、1 プロンプトあたり Claude のアクションは約 5 個、出力は約 600 語でした。一方、専門性が高いセッションでは、アクションは約 12 個、出力は約 3,200 語でした。
これは直感に反するようで、実務的には自然です。
専門性のある人ほど、AI に渡す問題設定が具体的になります。何を避けるべきか、何を検証すべきか、どこまで任せてよいかが明確になる。だから AI は、より長い実行の連鎖を進められる。
成果にも差が出ています。Anthropic は、セッションが成功したかどうかを、テスト通過、コミット、Pull Request、ユーザーの明示的な確認などの検証可能な信号から分類しています。その厳しい基準で見ると、初心者セッションの verified success は 15%、中級以上では 28〜33% と報告されています。
重要なのは、「コードを書ける人だけが AI を使える」という結論ではないことです。
レポートでは、ソフトウェア職以外のユーザーも、コードを生成するセッションでソフトウェア職に近い成功率を示しています。差を生むのは、職種名よりも、対象領域の理解です。会計、法務、業務運用、研究など、どの領域でも、問題の構造を理解している人ほど AI をうまく導ける可能性があります。
完全委任ではなく、監督と検証が残る
Anthropic 社内の調査も、この点を補強しています。
How AI is transforming work at Anthropic では、2025 年 8 月に 132 名の Anthropic のエンジニア・研究者を対象にした調査と、53 件のインタビュー、社内 Claude Code 利用データが分析されています。
その中で、社員は Claude を業務の約 60% で使い、平均で約 50% の生産性向上を自己申告しています。一方で、半数超の社員は、Claude に「完全委任」できる仕事は 0〜20% にとどまると回答しています。
この組み合わせが重要です。
AI は日常業務のかなり広い範囲に入り込んでいる。しかし、人間の監督や検証が不要になったわけではない。むしろ、高い生産性は「任せる対象を選ぶ」「途中で確認する」「出力を検証する」という人間側の判断とセットで成立しています。
別の Anthropic 公式レポート Measuring AI agent autonomy in practice でも、Claude Code の自律性は伸びています。長いターンの上位では、Claude Code が 1 ターンで動き続ける時間が 2025 年 10 月から 2026 年 1 月の 3 か月で 25 分未満から 45 分超へ伸びています。また、利用回数の少ないユーザー（50 セッション未満）の full auto-approve 利用は約 20%、750 セッション程度まで使ったユーザーでは 40% 超に増えています。
ただし、これは「何でも放置してよい」という意味ではありません。経験者ほど自動承認を使う一方で、介入すべきところでは介入する。AI を信用するというより、AI が失敗しても検知できる形に作業を置いている、と捉える方が実務には近いです。
これはプロンプト術から、仕様と検証の設計への移行である
ここで、最初の問いに戻ります。
人間は何を決め、AI はどう実行するのか。
Anthropic のデータから読むなら、人間の仕事は次の 4 つに集約できます。
- 目的を決める：何を作るのか、なぜ必要なのか
- 制約を決める：触ってよい範囲、守るべき設計、避けるべきリスク
- 完了条件を決める：何が通れば終わりなのか
- 検証方法を決める：テスト、ビルド、レビュー、画面確認、ログ確認
AI の仕事は、その設計の中で実行を展開することです。
ファイルを探す。コードを読む。修正する。コマンドを走らせる。失敗したら原因を探る。もう一度直す。必要なら計画を更新する。こうした実行のループを、人間が常に横で手動操作しなくても進められるようになってきています。
だからこそ、AI 活用の中心は「よいプロンプトを書くこと」から、「AI が実行できる仕様と、AI が読める検証信号を用意すること」へ移っていきます。
私たちが AI仕様駆動開発で重視し、独自メソドロジーとして公開してきたのも、まさにこの点です。
AI仕様駆動開発では、この 4 つをタスク、具体的には GitHub Issue という単位で決めます。Issue は、単なる依頼票ではありません。AI が自律的に遂行できる仕事の境界です。
Issue の中で、目的を決める。何を作るのか、なぜ必要なのかを書く。制約を決める。触ってよい範囲、守るべき設計、避けるべきリスクを書く。完了条件を決める。何が通れば終わりなのかを書く。検証方法を決める。テスト、ビルド、レビュー、画面確認、ログ確認のどれで合否を見るのかを書く。
ここを決める段階では、人間が深く関わります。むしろ、人間が最も考えるべき場所です。しかし、いったんタスクの目的、制約、完了条件、検証方法が定まれば、人間が実行中に逐一「次にこのファイルを読んで」「このコマンドを打って」と指示する必要は小さくなります。AI は Issue を読み、関連ファイルを探し、変更し、テストを走らせ、失敗すれば原因を探り、再実行する。
Issue、仕様書、受け入れ基準、レビュー観点、テストコマンド、運用ルールを、人間にも AI にも読める形で残す。AI はそれをもとに実装し、人間は目的と検証を握る。
プロンプトは、その場の指示です。仕様は、次の AI も読める組織の資産です。
フィールフロウからの視点
この変化は、エンジニアを不要にする話ではありません。
むしろ、エンジニアの役割が上流に寄っていく話です。
従来は、人間が設計し、人間が実装し、人間が検証していました。AI コーディングが実務に入ると、人間は「すべてを手で実装する人」から、「AI が安全に実行できる構造を設計する人」へ近づきます。
具体的には、次のような力がより重要になります。
- 問題を、AI が迷わず実行できる単位に分解する力
- 仕様、制約、完了条件を文章化する力
- テストやビルドなど、失敗が見える検証経路を用意する力
- AI の出力を読み、危険な賢さや見かけ上の成功を見抜く力
- 一度うまくいった作業手順を、Issue、AGENTS.md、Skill、Playbook として再利用可能にする力
AI に任せる範囲が広がるほど、人間の判断は不要になるのではなく、より前段に移ります。
Anthropic のデータが示しているのは、AI が実行を引き受け始めた世界で、人間の専門性がまだ強く効いているということです。人間の価値は、コードを書く手の速さだけではなく、何を作るべきかを見極め、どう検証すべきかを設計する力に移っていく。
この流れを、フィールフロウでは AI仕様駆動開発という独自メソドロジーとして実務に落とし込んでいます。単発のプロンプトではなく、仕様、Issue、検証、レビュー、公開までをつなぐ開発プロセスとして AI を組み込む。Anthropic のデータが示した人間と AI の役割分担は、私たちが現場で進めてきた考え方と重なります。そこに、これからの開発組織の差が出ると考えています。