AIネイティブに仕事をこなすために必要な「抽象化・具象化力」｜コーディングエージェントで速くなったのに組織の効率が上がらない理由と、違和感を言語化する力

こんにちは、株式会社TIMEWELLの濱本です。

コーディングエージェントを使い始めた人から、同じ話をよく聞きます。「自分の作業は明らかに速くなった。でもチームの成果物が早く出るようにはなっていない」。私自身、大企業や起業家向けにAI駆動開発のプログラムを運営する中で、この「個人は速いのに組織は速くない」現象を何度も見てきました。人手不足を補うはずのAIが、なぜ組織の数字に出てこないのか。この記事は、その原因を「抽象化と具象化」という古い言葉で説明し、これからの働き手に本当に要る力は何かを書くものです。

先に結論を書きます。原因は二つあります。ボトルネックではない場所を速くしていること。そして、AIにコンテキストを渡せば渡すほど、AIは「その文脈の中で辻褄の合う答え」に寄り、一段上から見た答えを出しにくくなること。この二つを埋められるのは、いまのところ人間だけです。具体的には、うまくいっていないことに気づく力と、その違和感を言語化する力です。自分やチームがいまどの段階にいるかを先に確かめたい方は、AIリテラシー診断で5分ほどの棚卸しができます。

「速くなった」のに、組織の効率が上がらない理由

まず、実感と実測がどれくらいずれるかを数字で見ます。

AI評価機関のMETRは2025年7月、経験豊富なオープンソース開発者16人に246件の実タスクをランダムに「AIあり」「AIなし」で割り当てる実験を公表しました。結果は、AIありのほうが19%遅い、でした。驚くのはそこではありません。開発者は事前に「24%速くなる」と予想し、実験で遅くなった後も「20%速くなった」と信じていたのです¹。速くなったという実感は、実測とは独立に生まれます。

METRは2026年2月、続報を出しています。2025年8月から始めた第2の実験では、AIなしで働くことを嫌って参加を辞退する開発者が増え、「AIなしではやりたくない」タスクを提出しない人が3割から5割に達したため、データの信頼性が落ちたと正直に書いています。生の数字では、元の参加者のサブセットで18%速くなる方向、新規参加者では4%速くなる方向でしたが、いずれも信頼区間がゼロをまたいでいます。METR自身は「2026年初頭にはAIで速くなっている可能性が高いが、われわれのデータはその大きさについて非常に弱い証拠しか与えない」と結論し、実験設計そのものを変えると宣言しました²。

ここで注目したいのは、同じMETRが2026年5月に出した自己申告調査のほうです。技術系の働き手349人に、AIによる「速度」の変化と「価値」の変化を分けて聞きました。速度の変化は中央値で3倍、価値の変化は中央値で1.4倍から2倍でした³。METRは、速度が価値を過大評価しがちな理由として、こんな例を挙げています。研究者がAIでデータのダッシュボードを短時間で作れたとします。AIなしなら何倍も時間がかかったはずですが、そのダッシュボードはプロジェクトにとって重要ではない、というものです。

これが、この記事で最初に言いたいことです。速くなった作業が、ボトルネックではなかったのです。

製造業には制約理論という古い考え方があります。工程全体の処理量は、いちばん処理の遅い工程、つまりボトルネックで決まります。ボトルネックで失った1時間は工程全体の1時間の損失ですが、ボトルネックではない工程で節約した1時間は、全体の処理量を1分も増やしません⁴。計算機の世界にも同じ法則があり、1967年にアムダールが示したように、逐次でしか進まない部分が残っている限り、他をどれだけ並列化しても全体の速度は頭打ちになります⁵。

事務仕事に置き換えると、こうなります。ある企画書の作成に2時間かかり、その承認に3日かかるとします。エージェントで作成を10分に縮めても、企画が動き出すまでの時間は3日と10分です。組織の成果物が出る速さは、承認という遅い工程で決まっているからです。それでも作成した本人は「2時間が10分になった」ので、12倍速くなったと実感します。METRの「速度3倍、価値1.4倍」は、この構図が世界中で起きていることを示しています。

もう一つ、マクロの数字も見ておきます。シカゴ大学の研究者がデンマークの大規模調査と行政記録をつないだ研究では、対象職種の多くの雇用主が生成AIを導入し、働き手は生産性の恩恵を報告しているにもかかわらず、所得と記録された労働時間への効果は精密なゼロで、ChatGPT公開から2年後の時点で2%を超える効果は棄却されました。変わったのは仕事の構造で、AIの監督や統合といった新しいタスクが生まれた、と分析しています⁶。個人の実感と組織の数字のあいだにある溝は、日本だけの話ではありません。

抽象化と具象化とは何か。仕事は往復でできている

ここで、記事のタイトルにある言葉を定義しておきます。

抽象化とは、目の前の具体的な出来事から、「何のためにやっているのか」「どんな構造の一部なのか」を取り出すことです。企画書を作るという作業から、「この企画書は承認を得るためにある」「承認は3日かかる工程の中にある」「工程全体の目的は来期の売上をつくることだ」と一段ずつ上がっていくのが抽象化です。具象化はその逆で、目的や構造から「では今日、誰が、何を、どう動かすか」に落とすことです。「承認を3日から1日にするには、承認者が見る項目を3つに絞った要約を先に出す」まで落ちれば、それは具象化です。

計算機科学者のダイクストラは、1972年のチューリング賞講演でこう言っています。「抽象化の目的は曖昧にすることではなく、絶対的に正確に語ることのできる新しい意味の階層をつくることである」⁷。私はこの一文を、仕事の技術としてそのまま使えると思っています。抽象化がうまい人は、ぼんやりした話をする人ではありません。「この案件のボトルネックは承認の工程だ」と、一段上の階層で正確に言い切れる人です。

日本語圏では、細谷功氏の『具体と抽象』が、抽象と具体の「往復」こそが知性の働きだと整理しています⁸。私もその立場です。仕事ができる人は、抽象度の高いところにずっといる人でも、具体的な作業をずっとしている人でもなく、往復の回数が多く、往復の幅が広い人です。

では、AIネイティブに仕事をこなすとは何でしょうか。私の定義は、「往復の一部をAIに任せながら、どの高さで問いを立てるかを人が決める働き方」です。エージェントは、具象化がとても得意です。「承認者向けの3項目の要約をつくって」と言えば、数分で出してきます。抽象化も、頼めばできます。「この業務フローのボトルネックはどこか」と聞けば、もっともらしい答えが返ってきます。問題は、その答えの質が、AIに渡したコンテキストの量と質に、私たちが思っている以上に左右されることです。

AIは抽象化できる。ただしコンテキストを抱えるほど「その文脈の答え」に寄る

「コンテキストをたくさん渡すほど、AIは賢くなる」。多くの人がそう思って、長いセッションを続け、資料を全部貼り付け、過去のやり取りを引き継ぎます。研究は、それが単純には成り立たないことを示しています。

2023年にスタンフォード大学などの研究者が発表した「Lost in the Middle」は、長い入力の中で関連情報が中央にあると、モデルの性能が大きく落ちることを示しました。冒頭と末尾にある情報は拾えるのに、真ん中は落ちるのです⁹。2025年のNoLiMaという研究はさらに厳しく、質問と答えのあいだに語彙の一致がない、つまり「連想」が必要な検索では、32Kトークンの時点で13モデル中11モデルが短文での性能の半分以下に落ちました。最も強かったGPT-4oでさえ99.3%から69.7%に下がり、推論機能や思考の連鎖を使っても維持できなかったと報告されています¹⁰。

2025年7月にChromaが出した「Context Rot」という技術報告は、18のモデルを対象に、入力が長くなるほど性能が不均一に劣化することを確かめました。私が特に重要だと思うのは、会話履歴から質問に答えるLongMemEvalという課題で、関連する部分だけに絞った約300トークンの入力のほうが、全文を渡すよりも一貫して高い性能を出したという結果です¹¹。渡す量を減らしたほうが、答えがよくなったのです。

Anthropicは2025年9月のエンジニアリング記事で、この現象を「コンテキストの腐敗（context rot）」と呼び、モデルには人間の作業記憶に似た「注意の予算（attention budget）」があり、新しいトークンを足すたびに予算が削られる、と説明しています。そのうえで、よいコンテキスト設計とは「望む結果の確率を最大にする、最小の高シグナルなトークンの集合を見つけること」だと定義しました¹²。同じ記事には、指示は「適切な高度（right altitude）」で書くべきだという表現もあります。細かすぎて壊れやすい指示と、曖昧すぎて手がかりにならない指示のあいだに、ちょうどよい高さがある、という指摘です。この「高度」という言葉は、抽象度の話そのものです。

研究の話を、実務の症状に翻訳します。エージェントとの長いセッションで、こんなことが起きていないでしょうか。最初は「この業務を自動化したい」という高い抽象度から始まったのに、やり取りを重ねるうちに「このボタンの位置を直して」「このエラーを消して」という具体の修正が積み上がり、いつの間にかエージェントは直近の指示に最適化した答えしか返さなくなります。「そもそもこの画面は要らないのではないか」という、一段上からの提案は出てこなくなります。これが、コンテキストを抱えるほど「その文脈の答え」に寄る、ということです。

正直に言えば、これは人間にも起きます。会議が長引くほど、その場の前提を疑う発言は出にくくなります。ただ、人間とAIには一つ違いがあります。人間は「なんか変だ」という違和感を、文脈の外側から持ち込めることです。少なくとも、いまのところは。

違和感に気づき、言語化する。トヨタが「人の知恵」と呼んだもの

トヨタ生産方式には、二本の柱があります。一つはジャストインタイム、もう一つが「自働化」です。トヨタ自身の説明では、自働化とは「人の知恵を加えた自動化」で、設備の異常、品質の異常、作業の遅れといった異常が起きたときに機械が自分で止まる、または作業者が紐を引いてラインを止めることを指します¹³。異常を検知して止めるから、不良品が流れず、異常の原因を潰せます。そして同じページには、「機械やロボットやITがどれほど優れていても、それ自身では進化できない。進化のために改善できるのは人間だけだ」とも書かれています。

私は、AIネイティブな働き方の核心は、この「自働化」の思想にあると考えています。エージェントは止まりません。「ほぼ正しい」答えを、止まらずに出し続けます。Stack Overflowの2025年開発者調査では、AIツールへの最大の不満として66%が「ほぼ正しいが、完全ではない答え」を挙げ、45%が「AI生成コードのデバッグに時間がかかる」と答えています。精度を信頼している開発者は33%、信頼していない開発者は46%でした¹⁴。「ほぼ正しい」が積み上がったとき、紐を引くのは人間です。

では、紐を引くために何が要るか。違和感に気づく力と、違和感を言語化する力の二つです。気づく力は、抽象化の力とほぼ同じものです。「この作業を速くしても、全体は速くならないのではないか」という気づきは、一段上の階層から現在地を見ないと生まれません。エージェントが具体の修正を積み上げている最中に、ふと「何のためにやっていたんだっけ」と高度を上げること。それが気づきです。

言語化の力は、気づきを検証できる文に変える力です。私は四行で書くことを勧めています。

行	書くこと	例
一行目	期待していた状態	企画が承認されて動き出すまでが半分になる
二行目	実際の状態	企画書は10分でできるが、承認は相変わらず3日
三行目	差分	速くなったのは作成で、承認の工程には触れていない
四行目	放置したときの影響	作成の速さに合わせて企画の本数だけが増え、承認待ちの山が高くなる

四行目まで書けると、違和感は「なんか変」から「承認の工程に手を入れないと、むしろ悪化する」という判断に変わります。そして、この四行はそのままエージェントへの次の指示になります。「承認者が見る項目を3つに絞った要約を、企画書の冒頭に置く形式に変えて」と、正しい高度で具象化できます。

大事なのは順番です。違和感があったら、AIに聞く前に自分で四行を書きます。AIに「何が問題だと思う？」と聞くと、AIはこれまでのコンテキストの中で辻褄の合う問題を見つけてきます。それはたいてい、直近の作業の延長線上にあります。四行を自分で書いてから渡せば、AIは一段上の高度から具象化を始められます。

明日からできる5つの実践

ここまでを、明日の仕事に落とします。

一つ目は、自動化する前に、工程を一枚の紙に描くことです。企画が生まれてから顧客に届くまで、誰が何をして、それぞれ何日かかっているか。矢印で結んで、いちばん長い箇所に丸をつけます。それがボトルネックです。エージェントに何を任せるかは、その丸を見てから決めます。丸のついていない工程を速くしても、METRの言う「速度3倍、価値1.4倍」を自分で再現するだけです。

二つ目は、エージェントに渡す前に、目的を一行で書くことです。「承認を3日から1日にするために、承認者向けの要約形式をつくる」。この一行が、指示の高度を決めます。一行が書けないときは、自分がまだ抽象化できていない合図なので、作業を始めずに工程の紙に戻ります。

三つ目は、抽象化が要る問いは、空のコンテキストで投げることです。長いセッションの中で「そもそもこの設計でいいか」と聞いても、その文脈の答えが返ってきます。別のセッションを開き、現状を要約した数百字だけを渡して「この工程のボトルネックはどこか」と聞きます。Chromaの実験で、約300トークンに絞った入力のほうが全文より高い性能を出したのは、この使い方の裏づけです¹¹。サブエージェントに切り出す、要約だけを引き継ぐ、といった運用の細部はAGENTS.md、Skills、Hooks、cronの組織運用に書きました。

四つ目は、違和感ログをつけることです。週に一度、四行の型で違和感を三つ書きます。書けない週は、高度を上げる時間がなかった週です。ログは自分の抽象化力の記録になり、半年後に読み返すと、自分がどの階層の違和感を拾えるようになったかが分かります。

五つ目は、組織として「止める」を評価することです。トヨタが紐を引く作業者を責めないように、「このまま自動化しても全体は速くならない」と言った人を、進捗を止めた人ではなく、無駄を止めた人として扱います。ここは、経営と管理職の仕事です。エージェントの導入本数や削減時間ではなく、ボトルネックが何日縮んだかで測ります。測り方を変えないと、速くなった実感だけが増えていきます。

私たちが大企業や起業家向けに運営しているAI駆動開発のプログラムでは、この五つを、実際の業務を題材にして回します。コーディングエージェントの操作を教える時間より、工程の紙を描く時間と、四行を書く時間のほうが長いくらいです。それは、操作は数日で覚えられても、高度を上げ下げする習慣は、繰り返しでしか身につかないからです。プログラムの構成はWARPのページにまとめています。

まとめ

コーディングエージェントで作業は速くなります。それは本当です。ただし、速くなった実感と組織の数字はずれます。METRの実験では開発者は20%速くなったと信じながら19%遅く、2026年の調査でも速度は3倍で価値は1.4倍から2倍、デンマークの行政記録では所得と労働時間に2%を超える効果は出ていません。原因は、ボトルネックではない工程を速くしていることと、AIがコンテキストを抱えるほどその文脈の答えに寄り、一段上からの答えを出しにくくなることです。

だから、これからの働き手に要るのは、抽象化と具象化の往復を自分で回せる力、そして往復の途中で「なんか変だ」と気づき、四行で言語化して紐を引く力です。AIは止まりません。止めるのは人です。

明日、まず一つだけやるなら、いま自分がエージェントに任せている作業について、「これは工程のどこで、その工程はボトルネックか」を一行で書いてみてください。書けなければ、それが最初の違和感です。自社の業務でこの往復を設計するところから一緒に始めたい方は、個別相談でお話ししましょう。

Footnotes

1. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity（METR、2025年7月10日）。16人・246タスクのランダム化比較試験。事前予想24%、事後の自己評価20%の速度向上に対し、実測は19%の遅延 ↩

2. We are Changing our Developer Productivity Experiment Design（METR、2026年2月24日）。第2実験の選択バイアスと、生の推定値（元参加者-18%、新規-4%。いずれも信頼区間がゼロをまたぐ）は同記事による ↩

3. Measuring the Self-Reported Impact of Early-2026 AI on Technical Worker Productivity（METR、2026年5月11日）。2026年2〜4月、技術系349人の自己申告調査。価値の変化 中央値1.4〜2倍、速度の変化 中央値3倍 ↩

4. Eliyahu M. Goldratt, Jeff Cox『The Goal』（North River Press、1984年）。邦訳『ザ・ゴール』（ダイヤモンド社）。制約理論（Theory of Constraints）の原典 ↩

5. Validity of the single processor approach to achieving large scale computing capabilities（Gene M. Amdahl、AFIPS 1967） ↩

6. Still Waters, Rapid Currents: Early Labor Market Transformation under Generative AI（Anders Humlum, Emilie Vestergaard、NBER Working Paper 33777、2025年5月、2026年3月改訂）。旧題「Large Language Models, Small Labor Market Effects」 ↩

7. The Humble Programmer（Edsger W. Dijkstra、1972年 ACMチューリング賞講演、EWD340）。原文は "the purpose of abstracting is not to be vague, but to create a new semantic level in which one can be absolutely precise."（筆者訳） ↩

8. 細谷功『具体と抽象 世界が変わって見える知性のしくみ』（dZERO、2014年） ↩

9. Lost in the Middle: How Language Models Use Long Contexts（Nelson F. Liu ほか、arXiv:2307.03172、TACL 2024） ↩

10. NoLiMa: Long-Context Evaluation Beyond Literal Matching（Ali Modarressi ほか、arXiv:2502.05167、2025年） ↩

11. Context Rot: How Increasing Input Tokens Impacts LLM Performance（Chroma、Kelly Hong ほか、2025年7月14日） ↩ ↩²

12. Effective context engineering for AI agents（Anthropic、2025年9月29日）。「context rot」「attention budget」「right altitude」の各表現は同記事による（筆者訳） ↩

13. Toyota Production System（トヨタ自動車 グローバルサイト）。自働化（Jidoka）を "automation with a human touch" と説明し、異常時に止めること、改善は人間にしかできないことを述べている ↩

14. 2025 Developer Survey: AI（Stack Overflow、2025年）。「ほぼ正しいが完全ではない答え」66%、「デバッグに時間がかかる」45%、精度への信頼33%、不信46% ↩