この記事はnoteに書いた文章をエンジニア向けに加筆修正したものです。
結論から言うと、次で示す「AI活用レベル8段階」の表はチームの実力指標ではなく手段の分類です。 レベルは「どのツール構成を使っているか」の分類であって、「AIの出力に対して何ができるか」という実力とは別の軸です。しかも出典元のEvery誌自身が「レベルが高いほど優れているわけではない」「レベル5〜8はエンジニア領域で、フロンティアのエンジニアでもレベル8は人間が担っている実験段階」と繰り返し留保しているにもかかわらず、SNS上ではその留保だけが削ぎ落とされ、「階段を登るほど優れている」という誤読が独り歩きしています。
指標にすべきは、レベルの数字ではなく「AIが人間の介入なしに良い仕事をすることをどれだけ信頼できるか」「失敗した時にどれだけの損害になるか」という二つの物差しです。この記事では、その根拠となった一次資料の検証過程と、自分なりに設計した実力ベースの代替指標（級表）を紹介します。
X（旧Twitter）で「チームメンバーのAI活用レベルの差が大きすぎて、客観的な指標が欲しい」という投稿を見かけました。リプライには「@every参照」という一言とともに、画像が一枚貼られていました。
チャットボットからオーケストレーターまで、AIの活用度を8段階に整理した表です。リンクは貼られておらず、画像だけでした。
表だけが独り歩きしていた
貼られていた画像はこの表でした。
| レベル | 説明 |
|---|---|
| レベル1 — チャットボット | AIに指示を出すと、回答を返してくれる |
| レベル2 — コパイロット | AIがあなたのファイル内で動作し、作業を隣で支援してくれる |
| レベル3 — エージェント | やりたいことを伝えると、AIが手順を考えながら実行し、重要な場面では承認を求めてくる |
| レベル4 — オートパイロット | 承認を省略し、AIがタスクを最後まで自律的に実行。人間は結果を確認する |
| レベル5 — ワークフロー | AIの成果物を安定して高品質にするための仕組み（ワークフロー）を構築する |
| レベル6 — アシスタント | AIが指示を待つのではなく、バックグラウンドで自発的に動き続ける |
| レベル7 — マルチエージェント | 複数の長時間動作するAIエージェントを同時に管理・運用する |
| レベル8 — オーケストレーター | マネージャーAIが複数のサブエージェントを統括し、チームとして仕事を進める |
チームのスキルマップとして使うには十分そうに見えます。「うちのメンバーは今どのレベルか」を判定基準にすれば、育成計画やタスクの割り振りにも使えそうです。実際、この表を評価軸のように扱っている現場を見かけたこともあります。
これは本当に評価指標になるのか。気になって出典を探しました。「@every」というリプライの一言だけが手がかりで、リンクは貼られていません。検索してたどり着いたのが、Every誌の元記事 The Eight Levels of AI Adoption（著者：Mike Taylor、Laura Entis、Claude）でした。
元記事が実際に言っていること
読んで最初に驚いたのは、著者が「レベルが高いほど優れている」という読み方を、記事の冒頭で明確に否定していたことです。
A higher level isn't necessarily better. The most sophisticated AI users I know operate at several levels at once, identifying the best level to work within based on the specific challenge in front of them.
レベルが高いことは必ずしも良いことではない。私が知る最も洗練されたAIユーザーは、複数のレベルを同時に使い分けており、目の前の課題に応じて最適なレベルを選んでいる。
どのレベルが適切かは、「AIが人間の介入なしに良い仕事をすることをどれだけ信頼できるか」と「失敗した時にどれだけ痛手か」で決まる、と著者は書いています。エンジニアリング的に言い換えれば、モデルの出力に対する信頼区間の見積もりと、障害時のブラストラディウス（影響範囲）の見積もりです。ハイステークスな本番系なら低いレベルに留めて人がレビューするか、高いレベルで同等の信頼性を出すためのテスト・ガードレール・ロールバック機構に工数を投資する。どちらもリスクの引き受け方の選択であって、優劣ではありません。
さらに著者は、レベル別の主戦場についても具体的に書いています。
The sweet spot for knowledge workers right now falls somewhere between Levels 1 and 4. Engineers are more often in Levels 5 through 8, partly because they can build the scaffolding that makes newer, less stable systems usable before they're ready for everyone else.
一般的な知識労働者の現在地は、レベル1〜4のどこかに落ち着く。エンジニアがレベル5〜8にいることが多いのは、まだ誰にとっても安定していない新しいシステムを、他の人が使えるようになる前に使いこなすための土台＝足場を自分で組めるからだ。
レベル5「ワークフロー」の項目には "This level is primarily the domain of engineers."（このレベルは主にエンジニアの領域である）と明記されています。レベル7「マルチエージェント」には "This level is firmly in senior engineering territory—it is rare for knowledge workers to be running multiple parallel agent sessions."（このレベルは明確にシニアエンジニアの領域であり、知識労働者が複数のエージェントセッションを並行運用するのは稀）とあります。
そしてレベル8「オーケストレーター」には、もっとも踏み込んだ留保が置かれていました。
It's critical to note that this level is highly experimental. Even engineers operating at the frontier still largely fill the role of orchestrator themselves rather than trusting an orchestrator agent to handle complex coordination work.
このレベルは極めて実験的であることに注意してほしい。フロンティアで活動するエンジニアでさえ、複雑な調整作業をオーケストレーターエージェントに任せるのではなく、多くの場合自分自身がオーケストレーター役を務めている。
フロンティアのエンジニアですら、レベル8はまだ人間がオーケストレーター役を担っている。著者はそう言い切っています。マルチエージェントのオーケストレーションフレームワークを触ったことがあるエンジニアなら、この一文の重みが分かるはずです。エージェント間の状態共有・エラー伝播・タスク分割の妥当性を、現状のツールだけで完全に任せきれる段階には来ていません。
削ぎ落とされたのは「使い方の注意書き」だった
X（旧Twitter）で流通していた画像には、この一連の留保がすべて含まれていませんでした。Level と Description の2列だけが切り出され、「レベルが高いほど優れている」という読み方を否定する冒頭の一文も、「レベル5・7・8はエンジニア領域」という明記も、まるごと抜け落ちていました。
「客観的な指標が欲しい」という需要に対して、著者が明示的に否定した「階段としての読み方」だけが生き残り、評価指標として消費されていく。これは悪意ある改変ではなく、表は表として単体で完結して見えるため、切り出しやすかっただけだと思います。ただ、切り出された瞬間に、著者が最も強く警告していた部分が消えるという構造は残ります。ドキュメントからコード片だけを抜き出してコピペし、前提条件や制約のコメントを落としてしまう事故と同じ構図です。
著者が本文でどれだけ「レベルが高いほど良いわけではない」と書いても、Level 1からLevel 8という通し番号を振った時点で、序列として読まれる土台はすでにできています。X（旧Twitter）での誤読は、画像が留保を削ぎ落としたことに加えて、採番という形式そのものが誤読を呼び込みやすい構造を最初から抱えていたことも、重なって起きたのだと思います。
コラム：採番は序列を暗示する
分類する側が言葉を尽くして「これは序列ではない」と説明しても、記号そのものが持つ序列の暗示力の方が強く働く例は、AI活用の外にもあります。近所の川の看板に「一級河川」と書いてあるのを見て、「こんな細い川が一級なのか」と思ったことはないでしょうか。一級・二級という区分は、川の大きさや水質のランクではありません。実際の基準は流域の重要性と管理者の違い（一級は国土交通大臣、二級は都道府県知事が指定・管理）です。小さな川が一級河川に指定されている例も、大きな川が二級河川止まりの例も、全国に普通にあります。それでも「一級」「二級」という記号を見ると、多くの人はまず優劣の並びとして受け取ります。Every誌の"Level"も同じ構造を抱えています。
実務未経験でオーケストレーションをやりたがる現象
自分の観測範囲でも、最近「レベル7・8をやりたい」という声を見かける機会が増えました。マルチエージェントを回してみたい、オーケストレーターを組んでみたい、という声です。
その動機の中には、実務上の必要に迫られてというより、X（旧Twitter）で見かける「AIエージェントに仕事を任せたら月に何千ドル」といったAI驚き屋の存在が大きいと踏んでいます。
モノは試しと自分でもマルチエージェント構成を作ってみましたが、これをやるには、対象業務に対する深い業務知識と、それをエージェントの指示書（Markdown等）として、曖昧さなく正確に記述できるスキルが必要でした。片手間でできるようなものではありません。
先に見た通り、そのレベルはフロンティアのエンジニアですらまだ人間が担っている実験段階です。レベル5の項目には、その手前の段階で必要になる作業についてこう書かれています。
Reviewing a plan, evaluating which tests need to be done, and designing the harness that keeps the agent from going off the rails all require an understanding of what's happening under the hood.
計画をレビューし、必要なテストを見極め、エージェントが脱線しないようにする仕組み＝ハーネスを設計すること。これらはすべて、内部で何が起きているかを理解していることを前提とする。
土台（内部の仕組みへの理解、失敗時に自分でデバッグ・ロールバックできる技術力、障害の影響範囲を引き受けられるリスク許容度）を積む前に、階段の上の段だけを目標にすると、著者が最初に否定した「レベルが高い＝優れている」という読み違いを、そのまま実行に移すことになります。表を評価指標として受け取った時点で、すでに著者の警告と逆方向を向いてしまっているからです。
この手の表は「現在地」も「目的地」も示せていない
似た形の表は、Every誌の8段階だけではありません。「AIとの関係」を検索エンジン・作業アシスタント・専門パートナー・業務システム・開発基盤という段階に分け、それぞれに級を振った表を見かけたこともあります。中身は違っても、構造は同じです。段階を並べ、下から上へ登っていくものとして提示する。
こうした表は、一見すると「自分（あるいはチームメンバー）が今どこに立っていて、次にどこを目指すべきか」を示すスキルマップに見えます。スキルマップだと思って眺めていたが、よく見ると現在地の針が動きません。
Every誌自身が書いている通りだからです。「最も洗練されたAIユーザーは、複数のレベルを同時に使い分けている」。あるタスクはレベル2、別のタスクはレベル6ということが普通に起こる以上、「このメンバーは今レベル5です」という一点の評価は最初から成り立ちません。目的地も示せません。著者は「レベルが高いほど良いわけではない」「レベル5・7・8はエンジニア領域で、フロンティアのエンジニアでさえレベル8は人間が担っている」と繰り返し釘を刺しています。目指すべき理由が示されていない到達点は、目的地とは呼べません。
これらの表が実際に示しているのは、現在地でも目的地でもなく、「どのツール構成を使っているか」という道具の分類です。チャットボットを使っているか、エージェントを使っているか、複数のエージェントを組んで使っているか。それは構成の違いであって、能力の違いではありません。
指標と呼べるものがあるとすれば、それは「どのツールを使っているか」ではなく「AIの出力に対して何ができるか」のはずです。同じレベル4（オートパイロット）を使っていても、生成されたコードの妥当性・境界値の抜け漏れ・パフォーマンス劣化を見極められる人と、テストが通ったからとそのままマージする人とでは、実力はまったく違います。逆に、チャットボット（レベル1）しか使っていなくても、プロンプトの立て方一つで出力の精度を大きく変えられる人もいます。**ツール構成の高度さと、使い手の実力は別の軸です。**この表を「実力の指標」として読んでしまうのは、CIパイプラインの複雑さをそのままエンジニアの技量スコアとして扱うようなものだと思います。
指標にすべきは「レベル」ではなく「二つの物差し」
X（旧Twitter）の元の投稿が求めていたのは「客観的な指標」でした。答えを出すなら、8段階の表そのものは評価指標にはなりません。指標にすべきは、著者が繰り返し使っている二つの物差しの方です。
- AIが人間の介入なしに良い仕事をすることを、どれだけ信頼できるか
- その仕事が失敗した時に、どれだけの損害になるか
この二つに照らして、今のタスクにどのレベルが適正かを決める。レベルの数字は結果であって、目標ではありません。「あのメンバーはレベル3で止まっている」ではなく「このタスクは、信頼度とリスクを踏まえるとレベル3が適正」という順番で考えるなら、同じ表でも読み方はまったく違うものになります。
そしてこの二つの物差しも、突き詰めれば「何ができるようになったか」を問う道具です。AIの判断をどこまで信頼できるかを見極められること自体が実力であり、障害の損害を正しく見積もれること自体が実力です。ツール構成のレベルを追いかけるのではなく、ツールを使いこなす自分の判断力を鍛える。評価指標を探すなら、そちらに向けた方がいいと思います。
もし自分でスキル指標を設計するなら
それでも段階を作りたいなら、「どのツールを使っているか」ではなく「AIの出力に対して何ができるか」で区切ります。試しに作るとこうなります。
| 級 | 見出し | 何ができるか |
|---|---|---|
| 5級 | 気づけない | AIの出力をそのままマージ・採用する。誤りに気づかず、後工程やレビューで発覚する |
| 4級 | 気づける | AIの出力の誤りに、自分でレビュー時に気づける。ただし修正は自分の手作業に頼る |
| 3級 | 直させられる | 誤りに気づいた上で、AIに指示を出し直して修正させられる。往復のコストを許容できる |
| 2級 | 見極められる | 依頼する前に、そのタスクがAIの誤りやすい領域（並行処理・境界値・セキュリティなど）かどうかを見極められる。事後レビューではなく、事前の設計・プロンプト設計でリスクを減らせる |
| 1級 | 仕組み化できる | 自分がレビューしなくても誤りが起きにくい仕組み（CI・静的解析・承認フロー）を、チームやAI自身に運用させられる |
同じチャットボットしか使っていなくても2級の人はいますし、オーケストレーターを回していても5級の人はいます。
当面の目標としては3級（直させられる）を目指すのが現実的だと思っています。誤りに気づき、指示を出し直して修正させられる段階まで来れば、日常業務のほとんどは回せます。2級・1級（見極められる・仕組み化できる）は、Every誌がレベル5・7・8を「エンジニアの領域」「フロンティアのエンジニアでも人間が担っている実験段階」と位置づけていたのと同じ意味で、まだエンジニアの試作領域だと思います。事前設計でリスクを潰す、あるいは仕組みそのものを他人やAIに運用させるところまで安定して持っていくには、事後レビューの経験を積み重ねた先の話です。3級を飛ばして2級・1級の看板だけを掲げても、中身が伴いません。
この五段階の差は、実際に手を動かすとどう出るでしょうか。たとえば文章の推敲にAIを使う場面で考えてみます。5級の人はAIが生成した文章をそのまま使います。つまりAIスロップの量産です。3級の人は、生成された文章に自分の思い・言いたいことが正しく表現されているかをチェックし、修正を繰り返すことで品質を高めます。2級・1級の人は推敲ロジックそのものを仕組みに組み込みますが、これができるのはルールの下で作成する定型文書・技術文書・操作マニュアルなど、正誤の基準が明確な文章に限られます。書き手の解釈や語り口が問われる文章では、推敲ロジックを機械的なルールに落とし込むこと自体がなかなか思いつきません。ここは人間のスキルとして、どれだけ抽象的に分析表現できるかというスキルに関わってきます。だから2級・1級は、エンジニア領域であると同時に、対象文書の専門領域にも依存するのです。
同じレベル8というツール構成でも、使う人の級によって「誤りの増幅装置」にも「誤りを止める仕組み」にもなる。この振れ幅は、Every誌の8段階を見ているだけでは分かりません。「どのツール構成を使っているか」という軸と「使い手が何を見抜けるか」という軸は別物で、この両方を重ねて初めて、「誰が使うと何が起きるか」まで見えてきます。
1on1で「レベル7・8を目指したい」というメンバーがいたら、まず聞くべきは「そのツールを使ってみたいか」ではなく「今のタスクで、AIの出力のどこまでレビューできているか」だと思います。