- AIの活用によってコードやドキュメントの作成は速くなりましたが、それがそのままチームの進捗につながるわけではありません。個人の作業速度をチームの生産性につなげるために備えるべき吸収能力を、判断可能性、追跡可能性、復旧可能性という観点から確認します。
最初は、自分が使っていたAIワークフローを整えてチームに共有すれば十分だと思っていました。ルールとコマンドを整理して共有すれば、自分が実感した速度向上をチームにも広げられると期待していました。
しかし、実際のボトルネックは別のところにありました。AIのおかげでコードやドキュメントはすぐに作成できましたが、その速度がチームの速度として十分に発揮されることはありませんでした。
この違いがなぜ生じるのかを調べているうちに、吸収能力（Absorptive Capacity）という概念を知りました。組織論でいう、外部の知識や情報の価値を認識し、それをチーム内部の能力に変えて活用する能力です。
AIが作成したコードやドキュメントも、最初は外部の知識に近いものです。見た目にはチーム内に存在していても、すぐにチームの能力になるわけではありません。
ボトルネックは作成から吸収へ移った
AI以前にも、コンテキストが不足したPRや形式的なレビューはありました。ただ当時は、成果物が現在のような速さで積み上がることはありませんでした。コードを書き、ドキュメントを整えるには時間がかかり、その時間が作成者に自分の選択をもう一度整理する余裕を与えることもありました。
AIは最初の成果を作る時間を大幅に短縮しました。今では、慣れていない領域でも設計案やコード、テストまで短時間で提示できます。
しかし、見た目には完成していることと、チームが受け入れられる水準にあることは別です。チームの基準で検証されているか、どこまで確認し、何がまだ残っているのか、次の人が引き継げるコンテキストが残されているかを、併せて確認する必要があります。
この方法を備えたチームは、向上した個人の生産性をチームの進捗に変えます。反対に、その方法が弱いチームでは、作成速度の向上がかえってボトルネックにつながります。
チーム内に入ったからといって、チームの知識になるわけではない
AIが作成した成果物は、簡単にチームのワークフローへ入ってきます。コードはリポジトリに上がり、ドキュメントはWikiに残り、分析結果は会議の議題になります。見た目には、すべてチームの資産のように見えます。
しかし、作成中に交わされた判断は、別途記録しておかなければ伝わりません。AIセッションや会話ログにしか残っていない判断は、チームのコンテキストにはなりません。
このように形式は整っていても仕事を前に進められず、受け取る人に解釈と検証の負担を押し付ける成果物をワークスロップ（Workslop）と呼びます。問題は、単にレビュー時間が増えるだけではありません。そのような成果物を受け取ると、レビュー時間が増えるだけでなく、チーム内の信頼まで同時に損なわれます。
これは作成者個人の丁寧さに任せるべき問題ではありません。ワークスロップが繰り返されるなら、まずチームがどのような条件で成果物を受け入れているのかを確認する必要があります。
チームの資産になるための三つの条件
成果物がチームの資産になるには、三つの問いに答えられなければなりません。
-
チームが合意した基準で判断できるか？
-
時間が経っても、決定の根拠を追跡できるか？
-
間違っていたとき、すぐに認識して元に戻したり、修正したりできるか？
この問いはコードだけでなく、ドキュメントや技術的な意思決定、運用ポリシーなど、チームが引き継ぐすべての成果物に当てはまります。
判断可能性
判断可能性（Reviewability）とは、第三者が成果物を理解し、評価できるだけの根拠が十分に示されているかを意味します。単なる可読性の問題ではありません。一つのレビュー単位として整理され、どのような問題を解決しようとしたのか、どこまで影響するのかが明確に示されていなければなりません。
チームが合意した基準で確認できなければならないという意味でもあります。もっともらしく見えても、チームが合意したアーキテクチャ、命名、例外処理、テスト方法から外れていれば、チームの資産として受け入れるのは困難です。特にAIの成果物は見た目の完成度が高いため、実際には判断が難しいにもかかわらず、検証が完了したように錯覚しやすくなります。
追跡可能性
追跡可能性（Traceability）とは、時間が経った後でも、決定の根拠と関連性をたどれるかという問題です。AIを使うと成果物はすぐに作成でき、会話記録や要約も併せて残せます。しかし、記録があるからといって、チームがすぐに理解できるとは限りません。どのような問題から始まり、どのような判断を経てコードやドキュメント、成果物につながったのかが、チームにとって読み取れる形で残されていなければなりません。
そうすることで、後から同じ判断を繰り返さずに済み、状況が変わったときには既存の決定を見直せます。
復旧可能性
復旧可能性（Recoverability）とは、問題が起きたときにそれをすぐに察知し、修正できる能力を指します。
AIが作成した成果物はもっともらしく見えるため、レビューを簡単に通過してしまいがちですが、後になって予期しないリスクが明らかになることがあります。したがって目標は、ミスを完全に防ぐことではなく、問題が発生したときにチームが許容できる範囲で安全に収束させられるシステムを作ることです。
チームの境界で確認すべき基準
個人の作業方法は異なっていても問題ありません。ただし、成果物がチームの境界を越えるときには、前述の三つの条件を確認できなければなりません。
最も身近な例であるPRを見てみましょう。
前回の記事「60日間のAIエージェンティックワークフロー」で取り上げた方法で作業したPRの一部です。
目的は、PR本文を詳しく書くことではありません。問題の原因は何か、どこまで検証したのか、レビュアーは何を見るべきか、問題が起きたらどのように対応すべきかなど、チームが受け入れる前に必要な内容を漏らさないための最低限の仕組み（harness）になる必要があります。
しかし、これを毎回作成者の誠実さだけに任せるのでは、持続可能ではありません。個人のチェックリストではなく、チームのワークフローに組み込まれていなければなりません。誰がどのツールを使うとしても、チームの境界を越えるときには、同じ基準の情報が残る必要があります。
良いPRの基準はAI以前と変わっていません。ただ、AIという増幅器が生まれた今、以前は守ると望ましい習慣だったものが、今では守らなかったときに支払う代償がはるかに大きくなっています。
チームの進捗は吸収から生まれる
AIがこれまでになかった新しい基準を作ったわけではありません。ただ、AIの成果物がチームに入ってくる速度が変わったことで、既存のエンジニアリングシステムの長所と短所が、より早く明らかになり始めました。
個人の作業をチームが責任を負える状態で受け入れるプロセスが確立されているチームは、AIによって高まった速度をチームの生産性として吸収できます。反対に、そのプロセスが不十分なチームは、何かを生成する速度だけが速くなる一方で、チームはなかなか前に進めません。
チームごとにボトルネックとなる箇所は異なるかもしれません。しかし、個人の作成速度は速くなったのにチームの進捗が変わらないのであれば、まずはその速度をチームが消化できるシステムを備えているか確認する必要があります。
これまで述べてきた チームは 人だけを指すものではありません。次の作業を引き継ぐ主体は、人かもしれませんし、AIかもしれません。AIもまた、チームに残された文脈をもとに動きます。文脈が空白だと、その内容を再び推論するためにコストを費やし、空白をもっともらしく埋めようとする過程で、幻覚や誤った判断につながる可能性があります。
組織が目を向けるべきなのは、「AIをどれだけ多く使ったか」や「成果物をどれだけ多く作ったか」ではありません。
AIが作った成果物を、チームが責任を持てる知識として吸収しているか？
この問いに答えられなければ、速くなった速度はチームが返済しなければならない負担として残ります。
参考資料
- Cohen & Levinthal, ["Absorptive Capacity: A New Perspective on Learning and Innovation"] (Administrative Science Quarterly, 1990)
- Kate Niederhoffer et al., ["AI-Generated 'Workslop' Is Destroying Productivity"] (Harvard Business Review, 2025-09)
TaeZ