# トークン使い放題の時代は終わった――「Sonnet maxxing」とAIコーディングのROI

- 番組: [Agentic Conversations (formally mlops.community)](https://ai-curator.jp/podcasts/shows/cmv3z5c0n000l5o10j1ogyu9h)（Demetrios）
- 元のタイトル: Token Maxxing Is Over and Here Is What Comes Next
- 配信日: 2026年10月20日
- 長さ: 35分
- 要約作成日: 2026年10月20日
- トピック: [#LLM](https://ai-curator.jp/topics/LLM) [#AIコーディング](https://ai-curator.jp/topics/AI%E3%82%B3%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0) [#ROI](https://ai-curator.jp/topics/ROI) [#Claude Code](https://ai-curator.jp/topics/Claude%20Code) [#プロンプトエンジニアリング](https://ai-curator.jp/topics/%E3%83%97%E3%83%AD%E3%83%B3%E3%83%97%E3%83%88%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%83%AA%E3%83%B3%E3%82%B0) [#エージェント](https://ai-curator.jp/topics/%E3%82%A8%E3%83%BC%E3%82%B8%E3%82%A7%E3%83%B3%E3%83%88)
- URL: https://ai-curator.jp/podcasts/cmvfecm4t00004f10qshvxl4w

## 要約

元HelloFreshのプリンシパルエンジニアPepijn Senders（Pep）が、AI未経験の約200人のエンジニアに6か月でプラットフォームを再構築させた経験を語る。意図的にOpusではなくSonnetを選び、人間を開発ループに残した。トークン消費と成果を散布図で可視化してROIを議論する方法や、複数人で行うリファインメント、プロンプトの言葉選びがモデルを左右する実験、Claude Code上のメタハーネス構築も紹介された。

## ポイント

- Pepは推論ステップが少なく早く止まるSonnetを選び、開発者が途中で判断に関与し続けるようにした。銀行ソフトで業務ルールが厳しいことが理由で、80万行のコードのうち約6割をSonnetが書いたという。
- トークン消費をX軸、機能数・行数・マージしたPR数などの成果をY軸にした散布図を作成した。結論ではなく「何を作っているのか」という対話のきっかけとして使うのが狙い。
- ROIは「2倍・3倍の生産性」ではなく「本来30〜40人要る仕事を20人でやれた＝節約できた人員数」で語るべきだと述べている。HelloFreshでは自社の関心である機能ごとの出荷速度で語れず、証明に失敗したと振り返った。
- AIが提示する選択肢は、気づかないうちに選択を狭める。自分のコードベースで理解できない関数がすぐ見つかるかを試すことを勧めている。
- 全員参加のリファインメントセッションで、エージェントの質問にチームで答える運用が、うのみにする受け入れを防ぐ。
- 同じ一発プロンプトを設計者とエンジニアに与えた実験で、「React」「scalable」「maintainable」といった語が出力を大きく変えた。
- コードの85%が「リファインメント→仕様→実装→検証」の同じ流れだったため、Claude Code上にメタハーネスを構築し、各段階ごとのトークンなどを計測している。

## 章立て

- [01:02] **Pepの紹介とSonnet maxing** — PepはEposcaのプリンシパルエンジニア。AI未経験の約200人にOpusでなくSonnetを使わせた理由が説明される。
- [03:04] **6か月でのプラットフォーム再構築** — 80万行規模の再構築で、約6割をSonnetが書いた。人間を判断ループに残すため、Sonnetが途中で止まる性質を活かした。
- [06:08] **AIコーディングのROI証明** — AI導入前後で比較できるダッシュボードを作った。1%良い画面に2万ドル分のトークンを使う価値があるかを問う視点も語られる。
- [08:18] **HelloFreshでの挫折とトークン可視化** — HelloFreshでは機能ごとの価値で語れず証明に苦戦した。トークン消費と成果の散布図は、対話を始めるための道具だと説明された。
- [13:26] **人員換算のROIと人間の主導権** — 生産性の倍率でなく節約人員で語る考え方を示す。人間がコードを理解し続けることの重要性と、人間が方向修正した箇所の計測も語られる。
- [23:53] **マルチプレイヤー式リファインメント** — AIの提案に流されないよう、チーム全員でエージェントの質問を議論する。成果物は要約や意思決定の追跡にも使われる。
- [28:08] **言葉選びがモデルを動かす** — 設計者とエンジニアで出力が異なった実験を紹介する。設計者向けにSvelteと出力スタイルを設定した工夫にも触れる。
- [32:16] **社内メタハーネス** — コンテキストを整理し、段階別にClaude Codeを起動し直す仕組みを説明する。各段階のメトリクスも取得する。

## 解説記事

元HelloFreshのプリンシパルエンジニアで、現在はEposcaに勤めるPepijn Senders（Pep）が、Demetrios Brinkmannとの対談でAIコーディング導入の実践知を語った回。AIをほとんど使ったことのない約200人のエンジニアを抱える組織で、あえて推論の浅いSonnetを選んだ理由や、トークン消費をどう正当化するかが中心の話題だった。

#### 「Sonnet maxing」という選択

Pepは今年2月、AI未経験のエンジニア約200人がいる企業に加わった。それまで使っていたGitHub Copilotでもトークン消費はほぼゼロだったという。課題は、既存業務に多くの時間を取られる状況で生産性を上げることだった。

そこで彼が選んだのが、思考ステップが少なく早く止まるSonnetだ。扱うのは銀行ソフトで、業務ルールが厳しい。Opusなら「取引エンジンを作って」という指示をそのまま進めるかもしれないが、Sonnetは最初の段階で詰まり、人間が舵を取る必要が出る。Pepはこの性質が開発者をループに残すと考えた。結果として6か月で約80万行のコードを書き、その約6割をSonnetが担ったと述べている。

#### トークン消費をどう説明するか

Pepはトークンを使い放題にする風潮は終わりつつあると見ている。企業にはCFOがいて、請求も無限ではない。そこでAI導入前後が明確に比べられる強みを活かし、ダッシュボードを作った。

特に使うのが散布図だ。X軸にトークン消費、Y軸に出荷した機能数やマージしたPR数を取る。2万ドル使って大量のコードを出す人もいれば、1.5万ドルでPRが1件の人もいるが、後者は調査中かもしれない。Pepはこれを評価や処分の材料ではなく「対話の入口」と強調する。個人の用事にトークンを使うケースもあり、7割対3割程度で私的利用が混じっていた時期があると冗談交じりに話した。

ROIの伝え方では、生産性が2倍・3倍といった倍率は使わず、「30〜40人必要だった仕事を20人でこなした」と人員数で語ると述べる。一方、HelloFreshでは機能ごとの価値で語れず、6〜7か月戦っても十分に証明できなかったと率直に振り返った。収益に直結する機能にAIを当てて出荷が2倍速くなった、という物語にすべきだったという反省だ。

#### 人間が主導権を持ち続ける

Pepが最も懸念するのは、LLMにコードを任せきりにして、何が起きているか分からなくなることだ。自分のリポジトリを開き、用途が分からない関数を探せば、すぐ見つかるはずだと言う。未知の未知は本番障害の火種になる。

また、AIが示す選択肢は、気づかないうちに道を決めてしまう。Opusなどが理解しにくい質問をしてきても、つい受け入れてしまうという話題も出た。対策として、社内ハーネスで人間がモデルのデータ傾向に逆らって方向修正した場面を計測し、チームごとの傾向を見ている。ただしそれが良い兆候か悪い兆候かは状況次第で、ここでも結論ではなく対話のきっかけだとしている。

さらに、1対1でエージェントと進めると推奨をそのまま受け入れやすいため、チームで行う「マルチプレイヤー」のリファインメントを導入した。PRDを取り込み、全員で画面を開いてエージェントの質問に答える。プロダクトマネージャーも参加でき、集団の知識が「良さそうだから」という安易な承認を防ぐ。記録は要約に使え、意思決定の理由もさかのぼれる。

#### 言葉がモデルを動かす

Pepは、同じ一発プロンプトでページを作らせる実験をした。設計者の多くはHTML・JavaScript・CSSを1ファイルにまとめたが、エンジニアはReactやVueのアプリにした。エンジニアのプロンプトにある「React」「scalable」「maintainable」といった語が方向を変えたという。さらにOpusは誤ったトークンを遠くまで推し進めるのに対し、Sonnetは影響が小さい、とも述べた。

設計者向けには、専用リポジトリでSvelteを使わせ、出力スタイルも設計者向けの言葉遣いに変えた。ミスしにくい環境を先に用意する発想だ。

#### メタハーネスの構築

最後に、Claude Codeを束ねる社内のメタハーネスが紹介された。きっかけは、スキルを大量に入れたせいで開始時点でコンテキストが4万トークンに達していた同僚の例だ。Pepはコンテキストに何を入れるかを厳しく管理したい立場だ。

組織内の多くの人は決まった手順に従って働く。調べると、コードの85%が「リファインメント、仕様、実装、検証」という同じ流れで書かれていた。そこで各段階に最適なコンテキストとスキルを与える仕組みにした。システムプロンプトに「終わったら特定ファイルを触る」と指示し、ウォッチャーがそれを検知してClaude Codeを閉じ、次の段階の新しいセッションを開く。段階ごとにトークン量などの構造化データも取れる。

#### まとめ

この回の核心は、AIを最大限に走らせるより、人間の理解と判断を残したまま成果を測ることにある。日本企業でも、トークン費用の説明責任やAI導入の定着は共通の課題だろう。人員換算のROI、散布図を対話に使う姿勢、全員参加のリファインメント、段階別のコンテキスト管理は、すぐ試せる示唆だ。ただし数値はPep自身の経験談で、一般化には注意が要る。

> この要約・解説記事は、元の音声の文字起こしをもとに AI（Claude）が日本語で作成したものです。出典: Agentic Conversations (formally mlops.community)「Token Maxxing Is Over and Here Is What Comes Next」