# MCP入出力の測定記録（2026年10月6〜7日）

2026年10月15日に技術記録として整理。本文の時制・道具数・クライアントの挙動・費用換算は計測当時の条件を指します。全9課題の測定値と表は維持し、品質全体が同じという断定、一般的な勝敗、将来の継続計測の約束を除きました。数値の出典は[facts.json](facts.json)と[facts-e5.json](facts-e5.json)。現行の使い方と成果物は[本記事](/articles/token-efficiency)から読めます。

## 比べたもの

4つの課題で、両方に同じ成果物を求めました。

| 課題 | 依頼 | 成果物 |
|---|---|---|
| T1 | 12 × 9 mの店舗：南の壁に入口、その近くにカウンターと展示台、長さ6 m以上の棚を2列（間の通路1.2 m）、通路はすべて0.9 m以上 | 寸法入りの `plan.svg`、3Dの表示、短い報告 |
| T2 | 同じ店舗の変更：1台目に接して2台目のカウンター、展示台を北へ2 m（0.9 mの通路を保てない場合は動かせる所まで） | 変更点の一覧、変更を書き込んだ新しい `plan.svg` |
| T3 | 30 × 20 mの倉庫：ドックドア4枚、奥行4 mの荷さばき場、6 × 4 mの事務所、背中合わせのパレットラック（1ベイ2.7 × 1.1 × 6 m、通路3 m）を入るだけ | 寸法入りの `plan.svg`、3Dの表示、ベイ数とパレット数 |
| T4 | 倉庫の受け渡し | 表題欄つきの縮尺図面 `drawings.pdf`、`quantities.csv` |

- **A：Codexだけ**。空のフォルダで、決まった形式の `model.json` に配置を持ち、`plan.svg` とthree.jsのページを自分で作り、重なりと通路幅も自分のコードで確かめる。
- **B：Codex＋Laydyne MCP**。開いているLaydyne Studioのタブに同じものを作り、`check_space` で確かめ、`get_view_image` が描く図面を保存する。

どちらもCodex CLI 0.160.1・gpt-6-astra（reasoning low）で、各課題2回ずつ。利用者の他のMCPサーバーとプラグインは両方とも止めました。結果は目ではなくスクリプトで判定しました（部屋の寸法、重なり、狭い隙間、通路幅、数、変更が指示どおりか、図面の寸法（PDFは文字かOCRで）、CSVとモデルの一致）。

## 数値

両方とも全回が同じ判定に合格しました（4課題×2回で各方式8回中8回、両方式で計16回中16回）。元記事の「それぞれ16回中16回」は合算の誤りで、2026年10月15日に `facts.json` の各課題2/2をもとに訂正しました。差はトークンです。

| 課題 | Codexだけ：入力トークン | Codex＋Laydyne：入力トークン | 推定API費用（だけ → Laydyneあり） |
|---|---:|---:|---:|
| T1 店舗 | 94,698 | 481,018 | $0.45 → $1.04 |
| T2 変更 | 89,478 | 453,216 | $0.37 → $1.03 |
| T3 倉庫 | 107,223 | 533,375 | $0.52 → $1.24 |
| T4 受け渡し | 246,915 | 655,818 | $0.70 → $1.40 |

![課題ごとの入力トークン](input-tokens.svg)

2回の平均です。Laydyneありでは入力トークンが2.7〜5.1倍。多くはキャッシュから読まれ、出力トークンはCodexだけより少ない（0.48〜0.76倍）です。gpt-6-astraの定価（100万トークンあたり入力$10・キャッシュ入力$1・出力$50。実行はChatGPTのサインインで、API課金ではありません）で換算すると2.0〜2.8倍。所要時間はほぼ同じでした（T1：Codexだけ125秒、Laydyneあり114秒）。

![課題ごとの推定API費用](api-cost.svg)

## なぜか

**モデルへの要求が多い。** Codexだけは生成スクリプトを1本書いて実行し、直して答えるので約4回。Laydyneありでは、道具を調べる・空間を読む・作る・確かめる・描く・保存するで約11回。Codexは要求のたびに自分の文脈（約2.1万トークン：指示、skillの一覧、権限の説明）とそれまでに集めたものを送り直すので、要求が1回増えるごとに数万トークン増えます。

**道具の説明を読む。** Codex 0.160はMCPの道具の定義を毎回は送らず、モデルが必要なときに一覧（`ALL_TOOLS`）から調べます。そのとき、サーバーの指示文を各道具の説明の前に付けます。Laydyneの指示文は9,006文字で、67個すべての道具の前に繰り返されていました。道具の説明は合計161,345トークン、その81%が同じ指示文の繰り返しです。Codexは一覧の表示を約1万トークンに切り詰めますが、切り詰めたものも後のすべての要求で送り直されます。推定では、Laydyneありの入力の約3分の1が道具の説明の参照でした。

**大きな結果をそのまま表示する。** エージェントは道具の結果を丸ごと表示することが多く、Laydyneの結果は同じJSONを2通り（文字列と構造化データ）で返し、空間の最初の読み取りには毎回同じ説明が約7 KB入っています。

## 試したこと、残したこと

道具の定義を毎回すべて送るクライアント（Claudeアプリ、ChatGPT、Cursorなど）では、一覧だけで1要求あたり約8.9万トークンかかります。すべての道具を呼べるまま、一覧を軽くする方法を試しました。

- ほぼ毎回使う道具は先頭に全文で、残りは簡略に（何の道具かと、上位の入力項目）。新しい `describe_tool` で、どの道具の全文の説明と入力仕様もサーバーから取り寄せられる。
- 簡略の入力仕様は全文の仕様を緩めたものなので、送る前に引数を確かめるクライアントでも正しい呼び出しは拒否されない。Studioはどの呼び出しも全文の仕様で確かめる。
- サーバーの指示文を9,006文字から1,192文字に。

![作業の前にLaydyneのMCPが使う分](tool-surface.svg)

計算上は、全道具を毎回読むクライアントの1要求あたり89,162→39,878トークン（−55%、o200k_baseで数えた推定）です。しかしCodexでは効果が出ませんでした。

- 上の4課題で測り直すと、変化は小さいものでした（T1 −3.6%、T2 −10.5%、T3 +56%、T4 +13%。各2回で、回ごとのばらつきの中）。
- 簡略表示になる道具を使う流れでも測りました。診療所の使用例の工程の実行と案の比較、階段と昇降機のある2階建て事務所です。どの一覧でも全回が目的を達成し、簡略の仕様だけを見て誤った引数で呼んだ失敗もありませんでした。ところが入力トークンは増えました。3つの流れの合計は、全文の一覧と長い指示文で263万、軽い一覧で377万（+43%）、その流れの道具を全文に戻した調整版で378万（+44%）、全文の一覧に短い指示文だけで325万（+24%）でした。

![簡略表示の道具を使う流れの入力トークン](brief-tool-flows.svg)

理由は2つあります。Codexは道具の定義を短いTypeScriptの宣言として読みますが、簡略表示の道具では `describe_tool` を呼び、宣言より重い全文のJSONスキーマを受け取ることになります。また、長い指示文はCodexが道具ごとに繰り返す分だけ重い一方で、手順の手引きとしても働いていて、短くすると探索や読み直しが増えました。

そこで、**軽い一覧と短い指示文は出していません**。コードは、全道具を毎回読むクライアントで試すためにブランチに残しています。出したのは、最も多かった失敗の修正です。部品の色を `"#dbeee7"` で渡すと拒否されていた件（最初の実行の失敗6件中4件）で、色の文字列と空のラベルを受け付けるようにしました。

## 要求回数と結果の大きさを減らした

数値から、こちらで変えられることは2つでした。エージェントが必要とする要求の回数と、道具の結果1つが、Codexが後の要求ごとに送り直す量をどれだけ増やすかです。10月7日に次のように変え、同じ4課題を各2回、同じ日のCodexだけと一緒に測り直しました。

- **結果を1通りに。** Laydyneは結果を、JSONの文字列と `structuredContent` の2通りで返していました。クライアントが読むのはどちらか一方です。
  - CodexとClaude Codeは `structuredContent` だけを読みます（Codexはそのとき画像も落とします）。
  - Cursorは文字列だけ、ChatGPTは両方を読みます。
  - 結果を表示したCodexのスクリプトには、2通りとも出ていました。

  今は、どのクライアントも読む文字列1つでJSONを返します。
- **毎回同じ説明は1回だけ。** 空間の最初の読み取り（`get_space` の `detail: "summary"`）には、機能・座標の約束・範囲の説明が毎回約6.6 KB入っていました。これは必要なときに `get_space {detail: "about"}` で読む形にし、空の床の要約は9,001文字から2,596文字になりました。
- **頼めば短い結果。** `create_space` に `result: "brief"`（全部品の代わりに部品数とID）を加え、編集の予行にも使えるようにしました。
- **指示文の先頭に手順の要約。** Codexは道具の入れ子の入力を `unknown` として見せるため、エージェントは宣言を読み直し、形を推測していました。
  - 指示文の冒頭に、よく使う5つの手順と入力の形を置きました。
  - 1つの段階の呼び出しは1つのスクリプトで順につなぎ、必要な所だけ表示するよう書きました。
  - ラックの並ぶ倉庫は、作成キットではなく `addArray` で作るよう案内します。キットはCodexのサンドボックスでは取得できませんでした。
- **同時に来た呼び出しは順番を待つ。** 並列に来た呼び出しには `busy` を返していましたが、最大8秒待たせ、変更は1つずつ通すようにしました。どの実行でも `busy` は出なかったため、この変更の効果は数値に表れていません。

| 課題 | 入力トークン：変更前 | 変更後 | 要求回数：前 → 後 | Codexだけ（同じ日）：入力（要求回数） | 推定API費用：前 → 後（Codexだけ） |
|---|---:|---:|---:|---:|---:|
| T1 店舗 | 520,728 | 244,564（−53%） | 12 → 7 | 135,326（5.5） | $1.09 → $0.60（$0.60） |
| T2 変更 | 613,148 | 391,216（−36%） | 13 → 11 | 117,899（4.5） | $1.35 → $0.75（$0.41） |
| T3 倉庫 | 581,063 | 334,425（−42%） | 11.5 → 9 | 121,202（5） | $1.38 → $0.78（$0.61） |
| T4 受け渡し | 506,980 | 375,160（−26%） | 11 → 9.5 | 257,262（7.5） | $1.20 → $0.80（$0.70） |

2回の平均です。前と後の違いがコードだけになるよう、「変更前」も10月7日に変更前のコードで測り直しました。上の10月6日の数値とは課題ごとに−23%〜+35%違い、日によるばらつきもこの程度あります（Codexだけも、T1は10月7日が135,326、10月6日が94,698トークン）。T1〜T4は、変更前・途中の変更・最終変更・同日のCodex単体の4条件を各2回、計32回実行し、すべて同じ採点に合格しました。表は途中の変更を除く3条件を示しています。

- エージェントが見た道具の出力は、1回あたり140,456文字から76,432文字に減りました。2重に表示された分（変更前は1回あたり17,650文字）はなくなりました。
- 長めの流れ（階段と昇降機のある2階建て事務所）でも、入力トークンは986,278から576,901に（−42%）、要求回数は19.5回から14回に減りました。前後とも全回が目的を達成しました。

それでもLaydyneの方が重いところ：

- **入力トークン。** Laydyneありの入力は、まだCodexだけの1.5〜3.3倍です。推定費用はT1でほぼ同じ、ほかは1.1〜1.8倍です。費用の差が入力の差より小さいのは、Codexだけの方が単価の高い出力トークンを多く書くためです。
- **道具の一覧。** Laydyneありの入力の約27%は、Codexが最初に表示する道具の一覧です。約1万トークンに切り詰められ、その後のすべての要求で送り直されます。
- **Codex自身の文脈。** 約57%は、Codex自身の文脈（約2.1万トークン）×要求回数です。どちらも結果の形では変わらず、減らせるのは要求回数だけです。
- **計測当時のPDF。** 当時のLaydyneは図面を150 dpiの画像としてPDFに埋め込み、エージェントはSVGから自分の道具で作り直していました。T4の回ごとの幅（238,334〜511,987トークン）の大部分はこれです。2026年10月13日にベクターPDFを公開しており、現在は文字を検索できます。この測定値を現在のPDF仕様の評価には使えません。
- **作らなかったもの。** ファイルを短命のダウンロードURLで渡す方式は作りませんでした。Codexの既定のサンドボックスにはネットワークがなく、OAuthで接続したエージェントはシェルで使える鍵を持ちません。鍵入りのURLは、URLに秘密を入れることになります。

## 追加の5課題：大きいモデル・図面・版管理

*2026-10-07に計測。出典つきの数値は facts-e5.json にあります。*

上の4課題は小さい作業でした。そこで、Laydyneがトークンに見合うと考えていた種類の作業を、同じ方法で測りました。両方に同じ依頼と成果物、スクリプトによる判定、Codex CLI 0.160.1。計測で使用したモデルは **gpt-6.1-sol（reasoning medium）** です（上の計測はgpt-6-astraなので、比べるのは倍率で、絶対値ではありません）。各3回、スキャンと版管理は各2回。

| 課題 | Codexだけ：入力トークン・推定費用・時間 | Codex＋Laydyne | Laydyne÷だけ（トークン・費用・時間） |
|---|---|---|---|
| **大きなモデルへの小さな変更**：20階・2,420部品の建物で、間仕切りを1本2 m動かし、壁を延ばし、2室の面積を直し、8席足す。他は一切変えず、その階の図面を出す | 437,329・$0.23・245秒 | 1,058,005・$0.32・180秒 | 2.42・1.40・0.73 |
| **理論値のあるシミュレーション**：窓口1人と2人（M/M/1とM/M/2）、種を決めた20回、95%区間、待ち行列理論との照合 | 89,427・$0.07・76秒 | 889,368・$0.24・190秒 | 9.95・3.39・2.50 |
| **図面から**：64 × 44 mの階の壁・扉・名前つきの15室・昇降機・階段・備品 | 286,692・$0.16・269秒 | 1,106,197・$0.42・247秒 | 3.86・2.59・0.92 |
| **同じ図面のスキャン風**（傾き・ぼけ・JPEG） | 760,691・$0.28・374秒 | 1,118,345・$0.39・285秒 | 1.47・1.43・0.76 |
| **3つの別セッションでの版管理**：版Aを発行、変更して版Bを変更の印つきで発行、版Aを正確に開き直して差をすべて挙げる | 926,352・$0.41・342秒 | 1,958,886・$0.61・308秒 | 2.11・1.51・0.90 |

中央値です（版管理は3セッションの合計）。費用はgpt-6.1-solの定価（1要求272K以下で100万トークンあたり入力$2・キャッシュ入力$0.10・出力$10）での推定で、実行はChatGPTのサインインです。

**定めた採点項目は両方が満たしました。** 見た目や引渡し後の使いやすさを含む品質全体の同等性は、この採点では確認していません。両方式とも、有効な13試行（大きいモデル・理論待ち行列・図面が各3回、スキャンと版管理が各2回）すべてが判定に合格しました。版管理の1試行は3セッションから成り、その全セッションが合格しています。変更は指示どおりで20階のどこも他は変わらず、シミュレーションの平均は理論値の幅に入り、図面から作った階は公開モデルと一致しました（品質点は両方とも1点満点で0.93〜0.96）。Laydyne側のモデル呼び出し（`read_underlay_with_ai` など）はどの実行でも使われていません。

**追加の5課題では、Codex単体の入力トークンが少なかった。** 作業が大きくなるほど差は縮みます。上の小さい課題では2.7〜5.1倍（モデルは別）、大きなモデルでは2.4倍、スキャンでは1.5倍です。Laydyneありの費用の多くが固定費だからです：Codexが毎要求で自分の文脈を送り直す分（Laydyneありの入力の約28〜41%）、道具一覧の読み込み（16〜37%）、空間の読み込み（11〜15%）。Codexだけは作業が難しくなるほど増え、スキャンでは要求が10回から23回になりました。道具一覧の分を0にできたとしても、大きなモデルの変更はLaydyneありの方が多くかかります（推定で約77万対43.7万）。

**所要時間と、採点対象外だった図面の内容。** 大きなモデル（180秒対245秒）と2つの図面課題で速く、図面は縮尺1:250・寸法・面積表・追加／移動／変更の凡例・表題欄つきの図面として出ました。Codexだけの図面は変更を色分けした自作の平面図で、縮尺も寸法もありません。依頼にはなかったので合否には入れていません。

**理論値のあるシミュレーションの条件と結果。** 指数分布の乱数を使う短いPythonで、M/M/1とM/M/2の理論値が95%区間に入る結果が、4回の要求で出ました。Laydyneのエンジンも同じ答えを出しましたが、費用は3.4倍でした。食い違いも見えました：Laydyneは準備期間の後、観測期間内に終わった待ちを数えます（定常状態でよく使う数え方）。依頼は到着時刻で客を選んでいたため、エージェントは種と窓口数の40通りを1回ずつ実行し、客ごとの記録から平均を計算しました。Laydyneが生きるのは、平面が効くシミュレーション（歩く経路、共有する資源、多くの工程）で、この課題では試していません。

**セッションをまたぐ版管理で採られた手順。** 3つの別々のセッションで「版を発行し、変更して次の版を発行し、最初の版を正確に開き直す」よう頼むと、Codexだけは版ごとにプロジェクトファイルの完全な写しとチェックサムを残し、開き直しはファイルを戻すだけでした（そのセッションは52〜57秒）。Laydyneありでは、エージェントは版をプロジェクト内の設計案ではなくブラウザ保存の別プロジェクトとして残したため差分の道具が使えず、保存したプロジェクト全体を読み直して比べ、開き直しに117〜121秒（中央値で時間2.2倍、入力4.1倍）かかりました。どちらも全セッションが正解でした。

**この測定から言えること：** 9課題でトークン削減の優位は確認できませんでした。大きいモデルと図面の一部ではLaydyne側の時間が短く、採点対象外の図面要素も出力されました。これらは当時の個別条件の観測であり、一般的な時間・費用・品質の優位を示すものではありません。全道具を毎要求読むクライアント、人とエージェントが一緒に編集する作業、平面が結果を左右するシミュレーションは、この計測の範囲外です。

## 自分で試す

空のフォルダを2つ用意して同じ課題を実行し、`codex exec --json` の `turn.completed` の行の使用量を比べてください。

```text
Design a small shop: a 12 m × 9 m room (12 m west–east, 9 m north–south). The front is the south side, with a 1.8 m wide entrance in the middle of the south wall.
Put in:
- a checkout counter near the entrance;
- two rows of shelving, each row at least 6 m long, shelves 0.5–0.6 m deep, with a 1.2 m clear aisle between the rows;
- a display table near the entrance.
Every passage must be at least 0.9 m wide, nothing may overlap, and the entrance must stay clear.
Check your result (overlaps, passage widths, dimensions) before you finish.
Deliver:
1. plan.svg in the current folder: a scaled 2D plan with the overall dimensions and the main aisle width dimensioned.
2. A 3D view of the shop.
3. In your final answer: what you placed, the narrowest passage, and what you assumed.
```

Codexだけの方には *"Work with files in the current folder only. Keep the design in model.json, make plan.svg from it, and for the 3D view make view3d.html with three.js from a CDN."*、Laydyneの方には *"Use the Laydyne MCP tools: build the shop in the Laydyne Studio I have open. Save the 2D plan as plan.svg (get_view_image with format "svg") and look at a 3D view with get_view_image."* を足します（計測は英語の課題文で行いました）。

```sh
codex exec --json --skip-git-repo-check -C ./alone - < prompt-alone.txt | grep turn.completed
codex exec --json --skip-git-repo-check -C ./laydyne - < prompt-laydyne.txt | grep turn.completed
```

2通りの手順を並べたものは [flow.json](measurement-flow.json) にあります。