多くの企業に足りないのは、AI ではありません。
仕事そのものを設計し直す覚悟です。
ライセンスを購入し、実証実験を行い、AI 担当者も置いた。それでも日々の現場では、営業が CRM に手入力し、マネージャーが情報を集めて別のチームへ伝え、顧客は承認の列で待っています。会議は、誰も全体像を持っていないために必要なままです。
ツールは変わりました。会社は変わっていません。
Buda が重視するのは、「どこに AI を追加できるか」ではありません。Agent がコンテキストを読み、ツールを使い、仕事を前に進められるとき、どの仕事を残すべきかという問いです。
AI で生成した編集用イメージです。
AI Shuffle：技術のロゴだけが変わる
Collective[i] 共同創業者の Stephen Messer は、2026 年 8 月 15 日の Fortune への寄稿で、この状態を 「AI Shuffle」 と呼んでいます。技術のロゴを入れ替えながら、仕事の進め方にある前提は一つも変えない企業の習慣です。
よくある場面です。
営業担当者は以前、CRM を手入力していました。今は AI が文章を作り、担当者が同じ欄へコピーします。マネージャーは以前、5 本の週報を集めていました。今は AI が書いた長い週報を 5 本受け取ります。4 人の承認経路は 4 人のままで、それぞれが意見を書く速度だけが上がりました。
各工程は速く見えます。しかし、全体は短くなっていません。
自動化によって、不要な仕事が見えにくくなることもあります。連携、権限、ダッシュボード、担当者が付いた後では、最初に疑うよりも削除が難しくなります。
自動化の前に、仕事を減らす
Messer が示す順序は、より厳しいものです。
- すべての要件を問い直す。 なぜこの工程があるのか。元の条件は今も成立しているか。
- 不要な仕事を削る。 結果を改善しない受け渡し、報告、待ち時間、承認をなくす。
- 残った流れを単純にする。 入力、判断、成果物を必要最小限にする。
- 最後に自動化する。 最初の三つを通過した仕事だけを Agent に任せる。
この順序は変えられません。
悪いプロセスを自動化しても、良いプロセスにはなりません。悪い状態が速く、深く組み込まれ、後から外しにくくなるだけです。
そのため、「何人が AI を使っているか」だけでは変革を証明できません。顧客対応が速くなったか、ミスが減ったか、判断が必要な情報を持つ人へ近づいたかは、利用人数では分かりません。
AI ファーストの業務は、ツールではなく成果と制約から始まります。
売上予測：より賢い会議は必要か
Messer は売上予測を具体例に挙げています。
従来の流れは、営業が CRM に予測を入力し、マネージャーが集計・修正し、経営陣が会議で数字を調整するというものです。その数字に情報不足と各自の利害が含まれることは、参加者も分かっています。
会議が必要なのは、システムが顧客の購買プロセスを直接観察できないからでもあります。
Agent が顧客行動、コミュニケーション、時期、市場変化、関係性、過去の取引を継続的に読めるなら、同じ会議をきれいに準備することが目標ではありません。予測を継続更新し、異常、意見の相違、高リスクの判断があるときだけ人を呼ぶ設計も考えられます。
これは診断のための例であり、すべての企業に CRM や予測会議の廃止を求めるものではありません。データ品質、権限、商業判断、責任範囲は企業ごとに違います。問うべきなのは、その慣習が判断を生んでいるのか、見えない業務を補っているだけなのかです。
会社は情報の階層から学習ループへ変わる
多くの企業ソフトウェアは、人によるデータ入力と情報移動を前提に作られました。
人が出来事を記録し、システムが保存、タスク配信、レポート作成を行います。マネージャーは複数のシステムから状況を再構成し、会議で決め、その決定を組織へ戻します。
Agent がコンテキストを保持し、活動を観察し、ツールを使って次の工程を始められると、見直しの対象はソフトウェア機能だけではありません。情報の収集、翻訳、要約、伝達を主な役割にする仕事も再定義が必要です。
リーダーシップは消えません。人の判断は、むしろ重要な場所へ集中します。
目的、許容できるトレードオフ、リスクの境界、エスカレーション、最終責任は人が決めます。顧客や現場に近い人の重要性も増します。価値を生む工程と、古いシステムの都合で残った工程を見分けられるからです。
組織は長い報告階層から、短い学習ループへ移れます。
業務シグナルが入り、Agent が実行し、人が重要な判断を確認し、結果が方法を更新する。
持続する強みはモデルの上にある
モデルは強くなり、価格は下がります。今日だけの能力も、明日には多くの企業が買えるようになります。
誰でも借りられるモデルへのアクセスだけでは、持続する優位性になりません。
蓄積できる強みは、その上にあります。
- 企業固有の業務コンテキスト
- Agent が使えるツールと権限
- チームが検証した方法
- 顧客関係と運用シグナル
- 実行結果から得たフィードバック
- 明確な人のレビューとエスカレーション
同じモデルでも、二つの企業で生む価値は大きく変わります。違いは Prompt の上手さではありません。Agent が適切なコンテキストを得て、本当の仕事を完了し、結果から方法を改善できるかどうかです。
会社全体ではなく、一つの業務から再設計する
全社変革から始める必要はありません。
顧客調査、営業フォロー、週次報告、コンテンツレビュー、見積準備、問い合わせ分類など、繰り返し発生し、結果を確認しやすい業務を一つ選びます。
次の手順で小さく再設計します。
- 成果を決める。 対応時間、成約率、エラー率、手戻りなどを選ぶ。
- 現在の仕事を描く。 入力、待ち、受け渡し、判断、承認、成果物を並べる。
- すべて分類する。 削除、単純化、Agent へ移す、人の判断を残す。
- 範囲を限定して試す。 低リスクの仕事から始め、レビュー点を明確にする。
- 活動ではなく結果を見る。 Prompt 数ではなく、品質、速度、手戻りを比較する。
管理の強さはリスクに合わせます。公開情報の整理や社内初稿は早く試せます。支払い、契約、個人情報、正式な記録変更には、より強い権限管理とレビューが必要です。
選択肢は「完全自律」か「AI 禁止」ではありません。結果の重さに合わせて、人の判断を置くことです。
再設計した方法を、動く仕組みにする
Buda は、ホワイトボードでの議論の次を実行するためにあります。
資料と業務コンテキストを Drive と Memory に置きます。会話、ファイル、ツール、成果物が見える永続的な Agent Workspace で Agent を動かします。実際の業務で検証した方法は、再利用できる Skills と Automations にします。
実行は Agent が担い、目的、例外、最終判断は人が持ちます。
一度の AI 実験が企業の能力になるのは、このときです。古いプロセスにツールを足すのではなく、不要な仕事を取り除き、残った仕事を実行、確認、改善しやすくします。
Buda ダッシュボードで、一つの実業務から始めてください。