【検証修正版】Claude Code + Serena連携でトークン消費量1.7倍の原因:Claudeによる技術スタック選択の違い
前回記事の振り返り
先日公開した記事では、Claude Codeを使って同じニュース配信ツールを2つの方法で開発し、トークン消費量を比較検証しました:
前回の記事はこちら:
👉 Claude Codeでニュース配信ツール開発:Serena連携でトークン消費量が1.7倍になった話
検証概要
- 開発ツール: テックニュース自動配信システム(RSS取得→翻訳・要約→Slack配信)
- 同じ条件: 要件定義書(1,500文字)、プロンプト(「要件定義を読んでみて」「開発を進めて」の2回のみ)
- 異なる条件: Serena MCP連携の有無
当初の結果
項目 | Serena連携あり | Serena連携なし | 差分 |
---|---|---|---|
Total Tokens | 1,419,778 | 819,618 | +73% (1.7倍) |
コスト | $1.04 | $0.60 | +73% |
当初の結論: 「Serenaの文脈理解機能がトークン消費量を大幅に増加させる」
問題発見:検証の前提に重大な見落とし
しかし、改めて検証結果を見直したところ、検証の前提条件に重大な見落としがあることに気づきました。
その結果、トークン消費量の差の原因は、Serena連携そのものではなく、AIが選択した技術スタックの違いにあったことがわかりました。
発見:同じ要件なのに異なる技術スタック
両プロジェクトのpackage.jsonを比較すると、違いに気づくことができました:
Serena連携版(news-jockey)
{
"name": "news-jockey",
"dependencies": {
"@google/generative-ai": "^0.21.0",
"@line/bot-sdk": "^10.0.1",
"next": "^15.1.3", // Next.js!?
"react": "^19.1.0", // React!?
"react-dom": "^19.1.0", // React DOM!?
"lucide-react": "^0.460.0", // UIアイコン!?
"tailwindcss": "^4.0.0" // CSS フレームワーク!?
}
}
非連携版(tech-news-delivery-system)
{
"name": "tech-news-delivery-system",
"dependencies": {
"@google-cloud/translate": "^8.0.2",
"@slack/web-api": "^6.12.0", // Slack API
"node-cron": "^3.0.3", // cron処理
"rss-parser": "^3.13.0" // RSS解析
}
}
問題の本質:要件とソリューションのミスマッチ
バックエンドツールを作るべき要件なのに、Serena連携版はフロントエンドアプリケーションとして実装されていました。
要件定義の内容(再確認)
- RSS取得による自動ニュース収集
- 翻訳・要約処理
- Slack自動配信(毎朝8時)
- cron実行による定期処理
これは明らかにバックエンドツールの要件です。
実際の実装
- Serena連携版: Next.js + React(Webアプリケーション)
- 非連携版: Node.js + TypeScript(CLI/バックエンドツール)
なぜこの違いが生まれたのか?
仮説1: Serenaの過剰な文脈理解による影響
package.jsonの"name": "news-jockey"
は私の過去のプロジェクト名です。この過去プロジェクトは主にフロントエンド開発を行っていたものです。
Serenaが過去のプロジェクト履歴や文脈を参照し、以下の判断を行った可能性があります:
-
news-jockey
プロジェクトの過去の技術スタック情報を参照 - フロントエンド中心の開発履歴から「このプロジェクトはWebアプリケーション」と推論
- バックエンドツールの要件にも関わらず、過去の文脈に引きずられてNext.js + Reactを選択
これはSerenaの強力な文脈理解機能が裏目に出たケースと言えます。本来は有用な機能である「プロジェクト履歴の参照」が、今回は要件とは異なる技術選択を引き起こしてしまいました。
トークン消費量差の真の原因
技術スタックの違いによる実装複雑度の差が、トークン消費量に大きく影響していました:
Next.js実装の複雑さ
- ページルーティング設定
- React コンポーネント設計
- UI実装(本来不要)
- SSR/CSRの考慮
- クライアント・サーバー分離
Node.js実装のシンプルさ
- 単一実行ファイル
- 直接的なAPI呼び出し
- シンプルなcron設定
- 最小限の依存関係
実行効率の観点・過剰な機能:
Next.jsはUIのレンダリング、ページルーティング、クライアントサイドのJavaScriptバンドルなど、今回の目的には不要な多くの機能を持っています。
フロントエンドの技術スタックを使ったことで、開発時のトークン消費量が増えている可能性は非常に高いです。
理由は以下の通りです。
-
コンテキストの増大: AIがコードを理解・修正する際、Next.jsの規約や設定ファイル(next.config.ts, tsconfig.json, next-env.d.tsなど)を読み込む必要があります。これらは純粋なバックエンド処理には不要な情報であり、プロンプトに含まれるトークン量を増やします。
-
ボイラープレートコード: Next.jsのAPIルートを作成するには、export async function GET(req) { ... }
のような定型文(ボイラープレート)が必要です。単純な関数をエクスポートするのに比べ、ファイルあたりのコード量が多くなり、読み書き双方のトークンを消費します。 -
関連ファイルの多さ: Next.jsプロジェクトは、.nextディレクトリや多くの設定ファイルなど、自動生成されるファイルやディレクトリが多数あります。AIがプロジェクト構造を把握しようと ls や globを実行した際の出力が多くなり、それもトークン消費につながります。
学び
今回私が感じたことは、AIコーディングツールを使っても、基礎知識は必要だということです。
基本的な知識を身につけ、AIを活用してより効率的な開発を目指します。
対策:AIコーディング効果最大化のための実践的アプローチ
Claude Code + Serenaを効果的に活用するための具体的な対策をまとめました。
対策1: 文脈のクリーンアップ
新規プロジェクト開始時は必ず文脈をリセット
Serenaは独自のメモリシステムを搭載しており、プロジェクトごとの情報を永続的に保存します。新しいプロジェクトを開始する際は、以下の方法で文脈をクリーンアップしましょう:
方法1: プロジェクトメモリの削除
# Serenaのdelete_memoryツールを使用
# Claude Code上で以下を実行
"delete_memory"ツールを使って過去のプロジェクト情報をクリア
方法2: .serenaディレクトリのリセット
# プロジェクトの.serenaディレクトリを削除
rm -rf .serena/
# 再度Serenaを初期化
方法3: 新しいプロジェクト名での明示的な初期化
# 明示的に新しいプロジェクト名を指定
claude mcp add serena-new -- uvx --from git+https://github.com/oraios/serena serena-mcp-server --project-name "new-project-name" --project $(pwd)
対策2: 技術要件を含む要件定義の作成
「何を作るか」だけでなく「どう作るか」も明確に定義
従来の要件定義書では「何を作るか」に焦点を当てていましたが、AIツール使用時は「どう作るか」も明確に定義する必要があります:
技術要件の明示(例)
## 技術要件
- **実行環境**: Node.js (≥18.0.0)
- **言語**: TypeScript
- **アーキテクチャ**: CLI/バックエンドツール
- **実行方式**: cron実行による定期バッチ処理
- **UI**: なし(コマンドライン実行)
技術スタックの指定(例)
## 使用技術スタック
- **ランタイム**: Node.js + TypeScript
- **HTTP Client**: 標準fetch API
- **RSS Parser**: rss-parser
- **翻訳API**: Google Cloud Translation API
- **Slack API**: @slack/web-api
- **スケジューリング**: node-cron
除外技術の明記(例)
## 使用しない技術
- Webフレームワーク(Express, Next.js等)は使用しない
- フロントエンド技術(React, Vue等)は使用しない
- データベースは使用しない(設定ファイルで管理)
プロジェクトの初期化要件
## プロジェクト初期化要件
- **新規プロジェクト開始時**: 過去のプロジェクト文脈をクリーンアップする
- **プロジェクト名**: 過去のプロジェクトと重複しない一意の名前を使用
- **文脈の分離**: 各プロジェクトの技術要件を独立して管理
なぜこれらの対策が重要なのか
-
AIの技術選択ミスを防ぐ
- 要件の曖昧さによる誤解を排除
- 適切なアーキテクチャパターンの選択を促進
-
開発効率の向上
- 不要な技術の排除によるシンプルな実装
- 目的に最適化された技術選択
-
コスト最適化
- 過剰設計による無駄なトークン消費を防止
- 必要十分な実装への誘導
-
文脈の汚染防止
- 過去のプロジェクトの影響を排除
- 各プロジェクトに最適な技術選択の実現
まとめ
AIコーディングは、エンジニアとしての基礎力と判断力のうえに成り立つ—これが今回の検証から得られた学びです。
Discussion