1人あたり月30万円──「トークンマキシング」は失敗だったのか
始まりは2025年12月ごろだった。LayerXは社内ツール「Shepherd」を全従業員に配った。中核でコーディングエージェントが動き、社内のさまざまなシステムとMCPでつながり、安全のための制約（ガードレール）、定時実行、タスクに応じたAIモデルの振り分け、コスト管理といった機能を備えたデスクトップアプリである。
エンジニアだけでなく、ビジネス職やコーポレートのメンバーも、SnowflakeやSalesforceにたまったデータを使ってプロダクトごとの失注分析をしたり、マーケティングのアイデアを考えたりと、あらゆる業務でこれを使った。
当時500人を超えていた組織で、一人あたり20万〜30万円を超える利用が生まれ、平均は月30万円に達した。
「当社の平均給与はおおよそ800万円なので、人間の給与の3割から4割ぐらいのお金を、トークンコストとして使うことが起こりました。純粋に人件費が1.4倍になるような世界です。経営者の方なら、その恐ろしさが分かると思います」
トークンを大量に消費するほど偉い、とするこうした風潮は「トークンマキシング（Token Maxxing）」と呼ばれる。世の中では、トークンマキシングは失敗だった、やらかしだったと評する議論もある。だが、福島氏はその見方をとらない。
AIの導入は技術の問題であると同時に、組織の仕組みやカルチャーをどう入れ替えるかという組織変革の問題でもあり、後者はエンジニアリングと同じくらい大きい。トークンマキシングはそのカルチャー変革を突破するうえで「すごく有用だった」というのが、同社の1年の総括だ。
とはいえ、そのまま続ければ赤字が膨らむ。そこでLayerXは、トークンの使い方の制御に乗り出した。1つは「LLM Gateway」だ。1つのAPIの裏側で、このタスクはオープンウェイトモデルへ、このタスクはClaudeでもSonnetで十分、といった振り分けを行う。標準で選ばれるAIモデルや推論の設定も見直した。
もう一つが「AI Token Cost Analyzer」で、全プロンプトを解析し、プロンプトキャッシュが効いていない、30分放置したせいでキャッシュが切れた、このプロンプトの書き方は改善できる、といったフィードバックを個人に返す。福島氏自身も、Shepherdにログインすると真っ先にそれが表示されるという。
社内で共通して行われているタスクは、営業ツール「Salesportal」などに統合し、LLMには判断だけをさせて、処理そのものはスクリプトやSQLで走らせる形に置き換えた。
では、コストを抑えるために使う量を絞ったのかといえば、そうではない。
「トークンコストはだいぶ抑えられていますが、トークンの利用量は全然変わっていないのです。むしろトークンマキシングをしていた頃よりも利用量は増えています。それでも、コストはコントロールできています」
開発の生産性は、コミット数ベースで3倍以上になった。コミット数が本当にアウトカムなのかという議論はあると断ったうえで、全体の傾向を見る指標として示された数字である。事業開始から5年目を迎えたバクラクでは、それまでの4年間に出したのと同じ数のプロダクトを、この1年で出した感覚だという。
「まず作ってみる。社内全体でトークンマキシングをする。そしてコントロールする。この流れを経ないと、なかなかAI活用は進まないと思います。これから、いろいろな会社がこの山を登っていくのではないでしょうか」
実装が安くなり、ボトルネックは「何を作るか」へ移った
開発が3倍速くなったことで、別の場所が詰まり始めた。LLMとコーディングエージェントの進化によって、コードを書くこと自体は安くなった。難しくなったのは、その前後の工程だ。
「仕様、つまり何をどのような形で作るのか。そこにボトルネックが移動しています」
後工程の検証も重くなった。QAやセキュリティなど、良いものが堅牢に作れたかを保証する部分だ。スライドには「実装物が増え、安全に、正しく動作するものか把握するコストが大幅に上昇」とある。しかも福島氏によれば、検証が難しくなる原因の一部は、最初の仕様や指示、意図のあいまいさにあるという。
何を作るかを決め、作ったものが正しいかを確かめる。プロダクトマネージャーの仕事の中心にあたる工程が、そのままボトルネックになったことになる。
では、仕様決めと検証をどう回すのか。ここで冒頭の「ループを閉じる」が具体的な形をとる。LayerXが社内で作ったリモートのコーディングエージェント「haro（ハロ）」について、福島氏はこう表現した。
「コーディングエージェントそのものを使っているというより、ハーネスを作っているというイメージです」
エージェントは、AIモデルにハーネス（知識やツール、権限、ガードレールといった周辺の仕組み）がくっついたものだ、というのが同氏の整理である。そのハーネスを育てる仕組みとして示されたのが、3つのループだった。
1つ目の「Inner Loop」は、目の前の1件の仕事を片付けるための循環だ。イベントやゴールを受けて計画し、実行し、評価・検証して補正する。実行の場面には人間も入る。
2つ目の「Outer Loop」は、仕事をまたいで経験を蓄える循環である。熟練のエンジニアがプロジェクトや実際のインシデントから学ぶように、Inner Loopで得た学びを知識・記憶として残し、次の仕事の計画に生かす。
そして3つ目の「Harness Optimization Loop」は、システムプロンプトやメモリー、ツールの権限といった、AIモデルの外にある構成要素そのものを直す循環である。
例に挙げたのは予算作成だ。エージェントにバクラク内のデータしか見る権限がなければ、スプレッドシートにある重要な予算データを見落とし、必ずミスをする。そのミスを分析して、データアクセスの権限がなかったことが原因だと突き止め、権限の設定を直す。手続きの知識が間違っていれば、ワークフローを組み替える。こうしてエージェントは、使えば使うほど、その会社の業務にフィットしていく。
LayerXでは、この改善役そのものを最先端の高性能なAIモデルに任せる試みが、うまくいき始めているという。ただし福島氏は、AIに丸ごと任せて自己改善できるほど、まだ整ってはいないとも付け加えた。方向性やハーネスの骨格ができるまでは、人間の介入がかなり必要だという。
