トークンマキシングの両義性と、
ローカルエージェントが開く「業務の一元テレメトリ」

AI エージェント時代の生産性計測と統制スタックの再編

 

本稿の論点

Token Maxxing は学習曲線の初期には正当な戦略である。しかし組織の成熟とともに、計測の単位は「量」から「行動」へと移行しなければならない。そしてその行動ログを初めて統一的に取得できる層として、ローカルエージェントの hooks が立ち上がりつつある。これは MDM・CASB に続く第三の統制レイヤーであり、EUC 復活の自由と、エンタープライズ統制の両立という長年の矛盾を解く鍵でもある。

※ 本稿における MDM は Mobile Device Management(デバイス管理)を指す。

1. まず、トークンマキシングには一定の理がある

Token Maxxing——より多くのトークンを使うほど価値が出る、あるいは生産的だ——という言説は、しばしば過剰な期待とともに語られる。だが、これを頭から否定するのは公平ではない。学習曲線の観点から見れば、新しい道具やパラダイムに触れた初期において、まずは量をこなすことには明確な意義がある。
AI エージェントを使いこなすスキルは、ドキュメントを読むだけでは身につかない。どの場面でどのようにプロンプトを組み立て、どのタイミングで介入し、どこまで任せるか——こうした感覚は、反復と失敗を通じてしか獲得できない。初学者にとっての 10,000 時間の法則が、エージェント活用にも緩やかに当てはまる。トークン消費量は、この段階では「努力量」の代理指標として一定の意味を持つ。
組織レベルでも同じことが言える。全社にエージェントを導入した直後のフェーズでは、「誰がどれだけ使っているか」という粗い指標でも、採用の濃淡を把握する上で役に立つ。使われていない部門を見つけ、導入支援を打つための一次スクリーニングとして、量の計測は妥当である。

問題は、この初期仮説をそのまま中長期の KPI に固定してしまうことにある。

2. しかしトークンは「仕事の影」であって仕事ではない

学習曲線の初期を過ぎれば、計測の単位は移行しなければならない。工場の生産性を「電力消費量」で測り続ける経営者はいない。電力は投入資源であって、アウトプットではないからである。トークンも同じく入力側の代理指標にすぎず、「何が起きたか」は何も教えてくれない。

本当に問うべきは、そのトークンが、どのツールを何回起動し、どのファイルを変更し、どのテストを通し、どの承認フローを経たか、である。つまり、トークン量ではなく行動ログこそが、成熟フェーズにおける生産性の一次データだ。そしてこの行動ログを、組織横断で、しかも統一フォーマットで取得する手段が——SaaS 時代には決定的に欠けていた。

トークンマキシングの誤謬は、「量をこなすこと」自体にあるのではない。量から行動へ、行動から成果へと、計測単位を段階的に昇華させていく経路が見落とされている点にある。

3. SaaS 時代の計測不能問題

プロセスマイニングは Celonis を筆頭に一大市場を築いたが、その射程は常に ERP や CRM のイベントログに制約されてきた。理由は単純で、業務が SaaS に分散した結果、組織の仕事の実態は「数十のサイロに散逸したログの連邦」になり、横断的な観測が構造的に不可能になったからである。

データガバナンスやコンプライアンスの苦闘も、根はここにある。統一された観測点が存在しない世界では、統制は常に後追いの突き合わせ作業にならざるを得ない。プロセスマイニングが ERP イベントから業務を「逆算」してきたのは、その象徴である。

この構造が、AI エージェントの登場で静かに反転しつつある。

4. ローカルエージェントという新しい「観測の隘路」

Claude Code のようなローカルで動くコーディング/業務エージェントは、単なる便利ツールではない。業務のオーケストレーションレイヤーとして機能し始めている。ファイル編集、シェルコマンド、Git 操作、ブラウザ操作、API 呼び出し、スプレッドシート更新——あらゆる作業がエージェントのツール呼び出しを通過する。
ここで決定的に重要なのが hooks の存在である。Claude Code の PreToolUse / PostToolUse フックは、エージェントが何かを実行する「前後」に任意のスクリプトを差し込める。これは技術的には些細な機能に見えて、ガバナンス的にはきわめて深い意味を持つ。
なぜなら、hooks は「すべてのツール呼び出しが通過する単一の観測点」だからである。SaaS 時代には数十のコネクタを繋いで無理やり集約していたプロセスログが、エージェント時代にはエージェント境界で自然に一元化される。業務プラットフォームが個人のローカル環境に降りてきた結果、皮肉にも組織が求めてきた統合テレメトリが、そこに初めて実現可能な形で現れる。

逆算から直接観測へ

プロセスマイニングが ERP の事後イベントから業務フローを逆算していたのに対し、エージェント層では業務が最初からタスク単位で記録される。これは観測パラダイムの断絶である。

5. 統制スタックの再編:MDM・CASB・エージェント層

従来のエンタープライズ統制は、大きく二層で構成されてきた。ひとつは MDM・EDR・DLP といったエンドポイント層——誰がどの端末で、どのアプリを起動し、どのファイルを外に出したかを見る層。もうひとつは SaaS 側のアクセスログや CASB である。この二層の間に広がる「実際にその人が何の仕事をしていたか」という領域は、長らく観測不能地帯だった。キーストロークロガーのような粗い監視か、自己申告のタイムシートしかなかった。

ローカルで動く AI エージェントの登場は、この中間層に初めて意味のある観測点を差し込む。MDM が「端末とアプリの統制」、CASB が「サービスへのアクセス統制」を担ってきたのに対し、エージェント hooks は「業務行為そのものの統制と記録」を担える。粒度がまったく違う。
この観点で捉え直すと、エンタープライズの統制スタックは次のように三層に再編されつつある。

レイヤー 観測の主語 担う統制領域
端末層 端末 MDM / EDR / DLP:デバイスとOSの健全性
アクセス層 セッション ZTNA / CASB:サービス境界の防衛
エージェント層 タスク hooks テレメトリ:業務行為そのものの記録と統制

興味深いのは、この三層がそれぞれ異なる主語を観測している点である。MDM の主語は端末、CASB の主語はセッション、そしてエージェント hooks の主語はタスクだ。タスクを一次データとして持てる観測層は、歴史上これが初めてに近い。

6. EUC 復活の「統制側の答え」

個人が自分のワークフローをエージェントに組み立てさせる世界は、クライアント/サーバー時代の Access や Excel マクロの再来であり、EUC(End User Computing)の復活と呼べる現象である。そして統制側から見れば、これは悪夢でもある。分散し、見えず、監査できない——それが EUC の歴史的な弱点だった。

だが hooks 経由のテレメトリは、この弱点を初めて構造的に埋める。個人が自由に組み立てたワークフローであっても、エージェントを通過する限り、「何のツールが・誰によって・何の目的で・どの成果物に対して」呼ばれたかが、統一スキーマで記録できる。EUC の自由と、エンタープライズ統制の両立という、長年矛盾とされてきた二つが、エージェント層という新しい抽象で和解する可能性がある。

データ品質の観点でも含意は大きい。従来は「どのシステムが真実か」を事後的に調停してきたが、エージェント層に統一された書き込みログが存在すれば、SSoT(Single Source of Truth)は事後調停ではなく観測事実として立ち上がる。

7. 経営層が今問うべき三つの問い

  • 第一に、組織はどの AI エージェントを「業務プラットフォーム」として採用するのか。これはもはやツール選定ではなく、将来の業務観測基盤を選ぶという意思決定に近い。
  • 第二に、hooks レベルのテレメトリを誰がどう設計するのか。所有権の議論は、BPM 導入時の議論とよく似ているが、射程ははるかに広い。
  • 第三に、生産性 KPI を「量」から「行動」へ、そして最終的に「成果」へと、段階的に昇華させていく道筋を描けているか。Token Maxxing を初期の助走として肯定しつつ、そこに留まらないための地図が必要である。

結語

Token Maxxing は否定すべき誤謬ではなく、乗り越えるべき通過点である。量をこなす段階、行動を観測する段階、成果で評価する段階——この三段階の移行を支える観測基盤こそが、エージェント hooks のテレメトリである。MDM がデバイスを、CASB がセッションを観測してきたのと同じ意味で、hooks はタスクを観測する。そしてタスクこそが、経営が本当に管理したかった単位である。

 

一覧に戻る

採用情報

DELTAでは、「エンジニアのためのエンジニアチーム」で一緒に働く仲間を募集しています。ぜひご気軽にカジュアル面談をお申し込みください。

採用情報を見る

お問い合わせ・ご相談

サービスに対するお問い合わせや、メディア関連のご担当者様はこちらよりご連絡ください。

問い合わせフォームへ