AI が数秒で下書きを作っても、会社の仕事が減ったとは限りません。
誰かが正しいファイルを探し、最新版を説明し、整って見える回答を原資料と照合します。足りない背景を次のツールへ運び、問題があれば別の人が下流で作り直します。
モデルは速い。ワークフローは速くない。
Buda は、ここを明確に分けて考えます。AI の出力は中間状態です。 コンテキスト、実行、判断、フィードバックが一つの仕組みとしてつながって初めて、個人の速さが会社の速さになります。
個人が速くなっても、会社が速くなるとは限らない
Glean Work AI Index 2026 は、この生産性の差を具体的な数字で示しています。
米国、英国、オーストラリアのフルタイムのデジタルワーカー 6,000 人を対象にした調査では、87% が仕事で AI を使い、75% が生産性の向上を感じています。回答者は、AI 自動化によって週に約 11 時間を節約できると見積もりました。
一方、AI が組織の業績と成果を大きく改善したと答えたのは 13% でした。
二つの数字は同じ指標ではありません。11 時間は自己申告の節約時間で、組織の改善も別の主観回答です。調査は 2025 年 12 月から 2026 年 1 月に行われ、デジタル中心の職種に偏り、発行元の Glean も企業向け AI ベンダーです。
それでも、実務上の問いは残ります。個人が速くなったと感じるなら、その利点は会社へ届くまでのどこで消えるのでしょうか。
多くは「生成完了」と「使える仕事」の間で失われます。
見落とされているのは、AI の周囲にある仕事
Glean は、この見えない作業を Botsitting と呼んでいます。欠けたコンテキストの提供、出力の確認、エラーの修正、Prompt の再実行、下流の後処理、分断されたツール間での意図の運搬です。
報告は、この作業を週平均 6.4 時間と推計しています。AI と関わる時間の内訳は次の通りです。
- 37% AI を使える状態にする作業
- 36% AI で実際の成果物を作る作業
- 27% ツールの学習と Agent の構築
確認作業のすべてが無駄という意味ではありません。
契約、財務モデル、顧客への約束、公開コンテンツには検証が必要です。モデルが知り得ない専門判断を加えることにも価値があります。責任あるチームが、こうした時間まで自動化する必要はありません。
減らすべきなのは、同じ状況を何度も作り直す作業です。同じ背景を貼り直し、承認済みファイルを探し直し、どのツールにも十分な文脈がないため複数の回答を比較し、本来は次工程へ進むべきでなかった誤りを修正する作業です。
AI の回答と業務成果の間にある四つのコスト
推計 6.4 時間は、四つに分かれます。
- 2.3 時間 AI へのコンテキスト提供
- 2.2 時間 出力の監督と確認
- 1.7 時間 デバッグ、再指示、モデル変更
- 0.2 時間 後処理とツール切り替え
最大の項目は、Prompt の書き方ではありません。Prompt の周囲にある仕事の状況を毎回再構築することです。
モデルがフォルダ全体を読めても、承認済みの表、対象年度、個別の顧客条件、昨日決めた例外までは自動で理解できないことがあります。
ファイルだけではコンテキストになりません。権威性、鮮度、関係、制約、現在の作業状態も必要です。
この構造がないと、従業員が実質的な統合レイヤーになります。
ツールを接続しても、切り替えコストは消えない
報告では、AI 利用者の 77% が毎週複数のツールを行き来し、33% が四つ以上を使い、60% が最初の回答に満足できず同じ Prompt を別のツールで再実行しています。半数以上が、仕事に必要な重要情報へ AI ツールからアクセスできないと答えました。
接続は有用ですが、共有された作業記憶とは違います。
API や MCP によって Agent がデータを取得できても、正式な記録、検証済みの方法、エスカレーション条件、このタスクにおける完了の定義までは自動で与えられません。
すべてのツールが空の会話から始まるなら、意図を運ぶのは人です。会社は複数の AI 利用を数えていても、一人の従業員が同じ背景を何度も作り直しているだけかもしれません。
出力が完成品に見えるほど、判断は飛ばされやすい
以前の質の低い知識労働には、粗い構成、不自然な文章、未完成の表といった警告がありました。その摩擦が、人に確認を促していました。
AI は多くの警告を消します。
流暢で、完成して見え、事実は間違っているという出力が可能です。
報告では、AI 利用者の 69% が、十分に確認していない、または理解していない AI 出力を扱う行動を少なくとも一つ認めています。41% は説明できない成果物を提出することがあり、77% は前月に AI 支援の仕事を修正またはやり直していました。
解決策は、人が常に AI を監視することではありません。レビューを先に設計することです。
実行前に、次を決めます。
- 正式な情報源
- 合格する結果
- 検証が必要な内容
- Agent が中断せず進められる操作
- 人の判断で止める条件
- 最終結果の責任者
レビューの強さはリスクに合わせます。公開情報の整理と支払い指示に、同じゲートを使うべきではありません。
Prompt の繰り返しを、実行システムに変える
方法が現在の会話を離れても残るとき、生産性の差は縮まり始めます。
実用的な AI システムには五つの層が必要です。
- 持続するコンテキスト： Agent が同じ資料、判断、作業状態へ戻れる。
- 再利用できる方法： 成功した手順を Skill やワークフローにする。
- 見える成果物： 実行中のファイル、調査、計算、下書きを確認できる。
- リスクに応じたレビュー： 定義した判断点で人が入り、無害な操作を毎回止めない。
- 結果のフィードバック： 合格、失敗、手戻りが次の実行を変える。
アカウント数、Prompt 数、Token 使用量、自己申告の節約時間だけでは、AI の価値を測れません。
初回レビューの合格率、コンテキスト再構築の時間、下流の手戻り、例外率、別の人が同じ方法を最初から説明せずに使えるかを測るべきです。
Buda は Prompt の後にある実務を管理する
Buda は、実際のタスクに必要なものを同じ場所に保ちます。
資料と業務コンテキストを Drive と Memory に置きます。Agent は持続する Agent Workspace で動き、会話、ファイル、ツール、成果物は見える状態に残ります。実務で検証した方法は、個人のチャット履歴ではなく、再利用できる Skills と Automations にできます。
実行は Agent が担い、目的、品質基準、例外、最終判断は人が持ちます。
これは、自動化の前に不要な仕事を削るという原則と同じです。残す価値がある仕事を見極め、その仕事に十分なコンテキスト、構造、レビューを与えて再現可能にします。
今日最も手戻りが多いタスクから始めてください。Buda ダッシュボードで実行し、コンテキストを仕事と一緒に残します。次の人が受け取るものが、修正の必要な整った下書きではなく、使える結果になったかを測ります。