実行者からオーケストレーターへ：AIは個人貢献者の仕事をどう書き換えているか

著者: Victor Hoang · 更新日: 2026年9月22日

オーケストレーターの役割とは、AIエージェントが実行の割合を増やしていく中で、個人貢献者（IC）の仕事が変わっていく姿です。成果物を自分で直接作る代わりに、問題を定義し、ブリーフを整え、何を任せるかを決め、結果を検証します。「自分で作業する」立場から、「他の誰か、あるいは何かが行った作業に責任を負う」立場への転換です。

昇進のように聞こえるかもしれません。しかし実際には、より難しいスキルセットを要する別の仕事であり、ほとんどのICはそのための訓練を受けていません。

重要なポイント

• リーダーの36%が、5年以内にチームがAIエージェントを管理するようになると見込んでおり、67%のリーダーがすでにエージェントに詳しいと答えています（従業員では40%）。出典：Microsoft, "The 2025 Annual Work Trend Index"
• BCGのコンサルタント758人を対象とした対照研究では、AIの能力の境界内にあるタスクでGPT-4を使った人は、AIを使わない対照群と比べて、完了したタスクが12.2%多く、作業は25%速く、成果物の品質評価は40%高くなりました。出典：Harvard Business School AI Institute, "Navigating the Jagged Technological Frontier"
• その境界の外にあるタスクでは、AIを使った同じコンサルタントが正しい提言を出せる確率が、対照群より約19ポイント低くなりました（対照群はAIなしで84.5%の正答率）。出典：Karim Lakhani, HBS, on the jagged frontier study
• MITのProject NANDAによると、企業の生成AIパイロットの95%は、損益に測定可能な影響をもたらしませんでした。出典：Fortune, reporting on MIT Project NANDA
• 検証の労力を増やすと、自動化システムの出力が誤っていても精査せずに受け入れてしまう傾向である「自動化バイアス」が、測定可能な形で減少します。出典：Microsoft Research, "Overreliance on AI: Literature Review"

仕事は縮小したのではなく、移動した

この点については、フロンティア企業とエージェントボスの台頭がすでに組織レベルでの姿を扱っています。Microsoftが、AIエージェントが日常のワークフローの中で働く企業を指して使う用語で、かつてマネージャーが人を管理したように、すべての働き手がエージェントを作り、任せ、管理するようになる状態です。その記事は文化と組織図の話でした。本稿は、それが自分自身に当てはまるようになったとき、実際の仕事に何が起こるのかを扱います。

コードを書く、コピーを起草する、モデルを構築する、サポートチケットを処理する。いずれの仕事でも、作業を実際に生み出す行為のうち、かなりの割合を、いまやエージェントが試みることができます。完璧ではなく、すべてでもありませんが、その範囲は広がっています。「領域を理解し、成果物を作る」ことだったあなたの仕事の一部は、2つの別々のスキルに分かれつつあります。領域を理解していることと、成果物の初稿を生み出すエージェントに指示を出すことです。

間違いは、後者のスキルが前者の縮小版であり、数週間チャットインターフェースを使えば身につくものだと思い込むことです。そうではありません。エージェントが正しく実行できるほど正確にタスクを指定し、そのうえで失敗の仕方を見抜くことは、自分でタスクをこなす場合とは異なる部分の専門性を使います。人とエージェントのチームは、この違いを人々が理解しているときにうまく機能し、作業をこなす力がそのまま指示を出す力に移ると誰もが思い込んでいるときにはうまく機能しません。人とエージェントのチームにおけるチームトポロジーは、この転換を一段上のレベルに引き上げ、エージェントが1人のタスクリストの中だけでなく、チーム構造のどこに位置するのかを扱っています。

「オーケストレーター」とは実際に何を意味するのか

この役割を定義する転換は2つあります。言葉にするのは簡単ですが、実際に生きるのは難しいものです。

作ることから、指定することへ

オーケストレーターの主たる成果物は、もはや納品物ではありません。ブリーフです。問題の記述、制約、「完了」とはどういう状態かを示す例、そしてエージェントが自分で判断してよい範囲の境界です。ブリーフが間違っていれば、基盤となるモデルがどれほど高性能でも出力は間違います。これはプロンプトエンジニアリングと同じ規律ですが、1回限りの巧みな指示から、1回目だけでなく5回目も50回目も機能する、持続的で再利用できる仕様へと規模を広げたものです。

実行から、本当の責任を伴うレビューへ

エージェントの出力をレビューすることは、後輩の同僚の仕事をレビューすることとは違う行為であり、同じものとして扱うのは、よくある失敗パターンの1つです。知らないことがある後輩は、たいていそう言うか、目に見えて粗い仕上がりのものを出します。高性能なモデルは、正しいかどうかにかかわらず、自信にあふれ、整った形式で、もっともらしい出力を生み出します。この差は、この分野でAIハルシネーションと呼ばれています。成果物自体が発しない疑いの目を、オーケストレーターが補わなければなりません。

オーケストレーターの役割における4つの中核スキル

1. 問題の分解

エージェントにタスクを渡す前に、それを「正しい」か「正しくない」かを確認できるほど小さく明確な単位に分解する必要があります。「このプロセスを改善して」という曖昧な依頼は、人間にもエージェントにも任せられません。分解された形、たとえば「このプロセスのうち所要時間が最も長い3つのステップを特定し、それぞれを20%短縮する提案を起草して」であれば任せられます。これはかつて、主にリーダーやマネージャーが実践するプロジェクト管理のスキルでした。いまでは、エージェント型ワークフローへの指示を仕事に含むすべての人に求められる基本的な期待値です。

2. コンテキストの設定

エージェントが知っているのは、ブリーフの内容、学習データ、そして取得できる情報だけです。この文書の前のバージョンがなぜ却下されたのかという社内の経緯も、実際に拒否権を持つ関係者が誰なのかも、CEOが長いメモを嫌うために「簡潔」がこの会社では特別な意味を持つことも、エージェントは知りません。コンテキストの設定とは、普段なら無意識に適用している暗黙知を外に出す作業のことです。そうすることで、エージェントが、知りようのない理由で失敗する、技術的には正しい成果物を作らずに済みます。AIエージェントをチームの一員として管理するは、これと同じスコーピングの規律を、1回限りのブリーフではなく継続的な運用業務として扱っています。最初のタスクが終わった後も機能し続ける品質基準、引き継ぎ、エスカレーション経路です。

3. 品質基準の設定

「十分に良い」というのは判断の問題であり、作業を始める前に決めておく必要があります。後から決めると、レビューのプロセスが、動き続ける的を相手にした自問自答の議論になってしまいます。基準を設定するとは、出力が満たすべき根拠、形式、トーン、厳密さの水準を定義することであり、第二の人物（あるいは第二のエージェントの実行）が同じ基準に照らして作業を確認できるほど明確に行うことです。このステップを省くチームは、不安から何でも過剰にレビューするか、疲労から何でも不十分にしかレビューしなくなりがちです。どちらの失敗も、一部のチームがワークスロップと呼び始めた、手間をかけない大量の出力という形で表れます。

4. 自分でやるべきときを見極める

これは最も注目されにくく、最も重要なスキルです。BCGとハーバード・ビジネス・スクールのフィールド調査では、AIを使うコンサルタントは、モデルの能力の境界内にあるタスクでは劇的に優れた成果を上げ、境界の外にあるタスクでは明らかに成果が悪化することがわかりました。しかもその境界自体がギザギザしています。人間には同じくらい難しく見える2つのタスクが、境界の反対側にあることもあります。研究者たちは、プロフェッショナルの使い方が明確なパターンに分かれることも見出しました。およそ3分の1が「ケンタウロス」として行動し、AIに任せる仕事と自分で持つ仕事の間に明確な線を引いて、より難しい半分では自らの判断力を保っていました。これよりはるかに大きなグループは、AIをあらゆるものに無差別に混ぜ込んでいました。目の前のタスクがどのカテゴリーに属するのかを見極め、難しく、曖昧で、リスクの高い部分を自分の手元に残す規律を持つことは、オーケストレーターの役割で最も難しい判断です。エージェントはどちらの場合でもタスクを試みようとし、自分の力が及ばないと伝えてくることはほとんどないからです。

従来のICスキルと、それに対応する新しいオーケストレーションのスキル

直接的な制作は成果物を作り上げます。オーケストレーションは、タスクを定義し、実行を任せ、結果を検証します。

なぜ聞こえ以上に本当に難しいのか

オーケストレーションを、自分でタスクをこなすよりも単純に少ない作業だと考えたくなります。そう言える場合もあります。しかし、3つの要因によって、このスキルは身につけやすいものではなく、むしろ上手に身につけにくいものになっています。しかも、マネージャーが十分に監督できる人数を制約するのと同じ上限が、1人のオーケストレーターがレビューを浅くせずに実際に指示できるエージェントの数も制約します。エージェントが仕事をするときのスパン・オブ・コントロールは、この上限を直接扱っています。

境界は動き、しかも表示されない

いま任せたタスクが、モデルの本当の能力の境界の内側にあるのか外側にあるのかを教えてくれるものは、画面上には何もありません。BCGの調査で、境界外のタスクでの正答率が19ポイント低下したのは、平均的には仕事のできるコンサルタントが、先端のモデルを使っていた場合です。失敗の原因は、AIの使い方のスキル不足ではありませんでした。カテゴリーの誤認でした。定型的に見えたタスクを、実際には違うのに境界の内側にあるものとして扱ったのです。自分の領域でそれに気づける判断力を養うには、ツールに慣れるだけでなく、意図的な練習が必要です。

検証は、作ることとは異なる認知的負荷である

作業を生み出している間は、ずっと問題の内側にいます。1つずつ組み立てているため、矛盾は起きた時点で気づきます。他の誰か（人間でもエージェントでも）が完成させた出力をレビューするには、その同じ理解を外側から再構築する必要があり、しかも最初に作ったときより速く行わなければならないことがよくあります。これは本物の認知的な努力であり、それを省くことこそ、もっともらしい誤りがすり抜ける原因です。検証は「自分でやるより少ない作業」ではありません。別の作業です。それを軽い選択肢として扱うことが、オーケストレーションが静かに失敗する道です。

ほとんどの組織は、意図的にこのスキルを育てていない

MITのProject NANDAは、企業の生成AIパイロットの大半が測定可能な財務的リターンを生まなかったことを明らかにしました。失敗に共通していたのは、モデルではなく、それをうまく使うために必要な組織としての学習のループが欠けていたことです。明確なオーナーシップ、ワークフローの再設計、そしてツールにアクセスできるだけでなく、実際に指示の出し方を知っている人材です。上記のオーケストレーターのスキルは、その欠けているループを、1人の仕事のレベルに当てはめたものです。この転換を「ツールを渡して、あとは各自で何とかしてもらう」で済ませる企業は、新しいスキルのための訓練を省き、古いスキルがただで引き継がれることを期待しているのです。

リスク：もはや理解していない仕事のレビュアーになること

はっきりと名前を付けておくべき特有の失敗パターンがあります。ICが実行を十分に、そして十分長い期間にわたって任せ続けた結果、その基礎となる仕事への自分自身の実践的な習熟が静かに衰えていくのに、肩書きの上では依然としてその仕事に責任を負っているという状態です。

これは、自動化バイアスの実践的で個人レベルの姿です。自動化システムの出力を、本来必要な精査よりも甘く受け入れてしまうよく知られた傾向で、特に、十分な回数正しかったことで信頼を得てしまった後に強まります。Microsoftがレビューした研究では、検証の労力を意識的に増やすことが、これを確実に減らせる数少ない介入の1つであることがわかりました。これは性格ではなく、身につけられる具体的な習慣です。チーム内でも名前を付ける必要があります。「レビュアー」という役割があれば確認が行われると思い込むのではなく、誰かが再確認を明示的に担う必要があります。

経済学者David Autorによる、自動化と専門性がどう相互作用するかという枠組みは、ここで有益な線引きをしています。ツールには、専門性の必要性をなくすものと、専門性を何倍にも増幅するものがあり、どちらになるかはツールそのものではなく、使い方によって決まります。仕事のうち最も難しい20%、つまりモデルが間違える部分を、自ら行い続けているオーケストレーターは、AIを自分の判断力のための増幅装置として使っています。それを静かにやめてしまったオーケストレーターは、もはや実践していない領域のレビュアーになってしまうリスクを負い、責任を負う立場としてはもろい場所に立つことになります。ヒューマンインザループは、その人間が間違いに気づけるだけの立場を保っている場合にのみ意味を持ちます。

年功と仕事の満足度に何が起こるか

年功は以前、一部は、その人が個人でどれだけの仕事をどれだけ速く生み出せるかで測れるものでした。その尺度は不鮮明になりつつあります。うまく作られたエージェントのワークフローを持つ若手アナリストが、いまや、シニアの人の丸1週間分に相当した量の初稿を生み出せるのです。簡単には置き換えられないのは、判断です。タスクのうち、どの20%を手で慎重に行う価値があるのかを知ること、エージェントの自信に満ちた答えが静かに間違っているときに気づくこと、そして違いを確認できるほど精密な品質基準を設定することです。これはまさに、AutorとThompsonが、消えるのではなく増幅されると述べている専門性であり、「X個の機能をリリースした」や「Y本のレポートを書いた」ほど履歴書に書きやすいものではありません。

仕事の満足度も、これに関連して打撃を受けます。正直に言及しておくべきでしょう。多くの人は、成果に責任を負うことだけでなく、作業そのものを楽しんでいました。一文ごとの職人芸、何かを最初から最後まで作り上げるフロー状態、モデルというパズルなどです。オーケストレーションは意思決定を残しながら、フローのように感じられたものの多くを取り去ります。その満足の一部は、残るもの（問題の捉え方、判断、本当の問題が浮かび上がる瞬間）に移りうるものの、この取引が誰にとっても差し引きゼロだと装うのは誠実ではありません。心理的安全性はここで特に重要です。「この部分を自分でやるのが恋しい」と打ち明けることが、変化への抵抗と受け取られてはならないからです。

マネージャーはこの移行をどう支えるべきか

上記の4つのスキルは、エージェントにアクセスできるようになったからといって自動的に身につくものではありません。チームに実際にそれらを育ててほしいマネージャーは、次のことを行ってください。

• 分解を明示的に教えてください。 かつてオンボーディングで特定のツールの使い方を教えたのと同じようにです。実際のブリーフをいくつか一緒にレビューし、曖昧な依頼がどこで3つの別々の判断を隠しているかを指摘します。
• 検証のための時間を確保してください。 より多くの成果物を生み出す時間だけでなく、です。エージェントが起草時間を半分に減らしても、その節約分がすべてさらなる量に吸収されるなら、より厳しく確認する人は誰もいません。
• 自チームにおける「シニア」の成果とは何かを、明示的に再定義してください。 価値をもはや反映しない量の基準で、静かに測られることのないようにするためです。これはスキルの問題であると同時に、組織設計と評価の問題でもあります。この転換のより広い議論はAI対応の文化づくりをご覧ください。
• ツールの使い方だけでなく、判断力のための意図的な反復を設けてください。 パイロットが、すべてがうまくいくときだけ飛ぶのではなく、模擬的な故障を使って訓練するように、エージェントの出力に仕込まれた誤りを見つける練習をしてもらいます。
• これは古い仕事の高速版ではなく、別の仕事だと口に出して伝えてください。 スキルギャップに正直に名前を付けることで、まだ埋められていないと認めても安全になります。それが、実際に埋めるための前提条件です。

この役割がうまく果たされている姿を思い描いてみてください。初稿を打ち込む時間は減り、初稿が存在する前に「正しい」とは何を意味するのかを決める時間が増えた人。出力のどの部分に自分の名前を懸けられるか、どの部分はまだ信頼できるほど丁寧に確認していないかを、正確に言える人です。そのような人材は採用するのも育てるのも難しい仕事ですが、いま実際に手に入る仕事はこれです。キーボードが速くなっただけの同じ仕事だと思い込むことで、チームは自信満々で未レビューの出力と、それに気づく責任を誰も負わない状態に陥ります。