fine-tuning、検索、それともprompt？判断基準は経済性です

「fine-tuneすべきか？」は、まるでmodelについての問いであるかのように尋ねられます。実際には予算についての問いです。どのbenchmarkも答えない形をしています。何を一度だけ払うのか、何を質問ごとに払うのか、そして世界が動くたびに何を再び払うのか。

この3つの経路は、1つのことを行う3つの方法でもありません。vendor自身も、多くのblog postよりはっきりそう言っています。OpenAI自身の表では、supervised fine-tuningが最も適している用途として4つが挙げられています。分類、ニュアンスのある翻訳、特定formatでのcontent生成、instruction-following failureの修正です。¹ そのどれも「modelに知らないことを教える」ではありません。利点の要約は「より短いpromptsを、より少ない例とcontext dataで使えるため、scale時のtoken costを節約でき、latencyも下げられる可能性がある」です — これは、その機能を売っている会社自身による、請求書についての議論です。

つまり：

• Fine-tuningが教えるのは形と振る舞いです。 tone、format、回答の形、説明は難しいが実演できる境界です。最も強い公開版はLIMAのSuperficial Alignment Hypothesisです。知識はpretrainingから来て、alignmentは主にどのformatのsub-distributionで話すかを教える — だからそこでは、厳選された1000例で十分でした。²
• 検索は変化する事実を供給します。 ドキュメントへの編集がmodelに触れず回答へ届くのは、この3つの中でこれだけです。
• Promptingは現実の大半を覆いますし、正直なbaselineです。In-context learningはLanguage Models are Few-Shot Learners以来のdefaultです。taskはprompt内で実演され、weightは動きません。³

中間の誤りには、2本の測定論文が扉を閉めています。Ovadiaらは、unsupervised fine-tuningで知識を注入する方法と検索で注入する方法を比較し、検索が一貫して勝ちました。base modelがpretrainingですでに見ていた事実でも同じでした。⁴ Gekhmanらはその損傷を測りました。新しい知識を導入する例はゆっくりfitされ、modelがついにそれらにfitすると、他の質問でのhallucination率が上がります。⁵ fine-tuningで事実を教えることは単に失敗するだけではありません。trainingしていない回答まで劣化させます。

その半分は決着済みです。経済の半分はまだです。そしてこの章の残りがそれです。

1つのケースを3通りで実行します。毎週変わる自社ドキュメントに対するtechnical supportです。

corpusは実在し、このdisk上にあります。稼働中のあるsoftware repositoryが内部ドキュメントとして保持している23個のMarkdown documentです — build guide、brand rules、translation brief、10本のservice manual、performanceとsecurity notesです。第7章のencodingであるo200k_baseで測ると：

documents                              23
characters                        159,223
words                              22,194
tokens (o200k_base)                42,921
tokens with per-file headers       43,158

43,000 tokenは、この判断には扱いやすい大きさです。現代的などのwindowにも入るので、3つの経路は本当に利用可能です。1000万tokenなら判断は自動的に決まります。検索です。

ここで「毎週」という言葉が担っている仕事です。ドキュメントのchurnはたいてい主張されるだけですが、ここではそのrepositoryのversion historyから数えています。

ドキュメントはおよそ隔週で動きます。user-visible strings — support deskが実際に質問される対象 — は存在していたすべての週で動き、週あたり約20 commitでした。どの経路を選んでもこれを生き残る必要があります。そして*「trainingした対象はどのくらい頻繁に変わるのか？」*には、意見ではなく自分のrepository内に数字があります。

このcorpusに対して、topicごとに1つ、現実的なサポート質問を20個書きました。以下のすべての数値は、その20個で計算しています。

動く最も単純な方法です。corpus全体をsystem promptに入れ、最後に質問を置き、modelに見つけさせます。

system instructions                       140 tokens
the 23 documents                       43,158 tokens
the question (median of 20 measured)       13 tokens
the answer (the one assumption)           150 tokens

最後以外の数字はすべて数えたものです。150 output tokensは仮定で、第16章が課金したassistant turnの範囲内で選びました。ここで実行していない唯一の数値であり、3つの経路すべてに同じように適用します。break-even sectionでは、それを変えると結論がどのくらい動くかを正確に示します。

2026年9月7日にproviderのページから読んだrate — input 100万tokenあたり$1.50、output 100万tokenあたり$9.00⁶ — では、質問あたり**$0.066317**です。13 tokenで答えるために、43,000 tokenを読み直す費用を払っています。

第16章の修正はそのまま適用できます。corpusは安定していて先頭にあるため、完璧なcache prefixです。読み戻しは10分の1になり、質問あたり**$0.007864**、88 %削減です。第16章の警告も同じく当てはまります。同章が指摘したものの価格を出さなかった形です。このproviderはwrite premiumを課しません。課すのはrentです。explicit cacheは保存tokenあたり1時間$0.000001かかるため、43,298 tokenを温め続けるコストは

誰も何も質問しなくても発生します。これは6か月で$189.78、空室に対する費用です。rentを質問ごとの節約額で割ると、条件は1行で出ます。このcorpusのcachingが元を取るのは、1時間あたり0.74質問を超えてからです — 週次cache rebuildも数えると月546件です。それ未満では、お金を節約するために有効にした機能がお金を失わせます。

同じ経路、同じcode、1つのflagで、請求額は5倍です。第16章では、timestampを置く場所のミスでこれが起きる版を見つけました。ここではtraffic以外に何も間違っていません。cacheはvolumeへの賭けであり、このproviderではそれを時間単位で張ります。

第19章のretrieverをそのまま使います。section boundaryで切り、contextual headerを付け、indexし、最良の4つの抜粋をpromptに入れます。20質問での測定結果です。

chunks produced from the corpus              330
mean tokens of a chunk's own text          124.9
mean tokens of the four retrieved extracts   884
prompt per question (140 + 884 + 13)       1,037
one-off embedding of every chunk        46,823 tokens

経路1よりprompt tokensは42分の1で、質問あたり**$0.002906です。index構築コストはembedding token 100万あたり$0.15⁶で$0.0070 — 質問3件分未満です — そしてドキュメントが変わるたびにscratchからrebuildしても同じ$0.0070です。6か月間、毎週index全体をrebuildしても18セント**です。

ここで立ち止まる価値がある点が1つあります。検索はprompt cachingを壊します。 安定したprefixは140 tokenのsystem instructionだけになります。token 141からpromptは毎call違います。抜粋が質問ごとに選ばれるからです。そして140 tokenは第16章で引用したどのcache minimumも下回ります。したがって経路2はまったくcacheできません。悪く聞こえますが、そうではありません。1,037 tokenをcacheしない方が、43,298 tokenをcacheするより安いからです。

持ち帰るべき一般則です。2つの大きなtoken節約手法は、同じcontent上では両立しません。勝つのは、より多くのtokenを取り除く方です。検索はその97.6 %を取り除きます。

house styleの200例でtrainingし、その後はドキュメントを一切添付せずに質問します。

training examples                            200
training tokens                           24,389
epochs                                         3
prompt per question (15 + 13)                 28

training costは24,389 × 3 × 100万あたり$10.00 = $0.7317です。これが構築費用のすべてで、コーヒー1杯未満です。だからこそ多くのteamは、役に立つか確認する前に払ってしまいます。

ここに罠があり、この章が存在する理由です。fine-tuned modelの実行コストはbase modelと同じではありません。pricing pageは1文で言っています。「Gemini 3以降のmodel inferenceについて、tuned model endpoint prediction priceはbase modelの1.5倍になる」。⁶ trainingではありません。inferenceです。すべてのtokenに対して、modelが生きている限りずっとです。

では式に入れます。$p_i$と$p_o$をbase inputとoutputの価格、$m$をtuned multiplier、$L_R$を置き換える経路のprompt length、$L_F$をfine-tuning後のprompt length、$O$をanswer lengthとします。fine-tuningが質問あたりで安くなるのは、次のときだけです。

第1項は明らかです。新しい短いpromptにmarkupが乗ります。第2項はそうではなく、ここにお金が流れます — answerへのsurchargeです。これはpromptとは無関係で、trainingでは短くできません。測定値 — $m = 1.5$、$L_F = 28$、$O = 150$、$p_o/p_i = 6$ — では、thresholdは

answer   50 tokens -> the prompt it replaces must exceed   192 tokens
answer  150 tokens -> the prompt it replaces must exceed   492 tokens
answer  400 tokens -> the prompt it replaces must exceed 1,242 tokens
answer 1000 tokens -> the prompt it replaces must exceed 3,042 tokens

測定したanswer lengthでは、492 token — そのうち450はpromptではなくanswer surchargeです。 それより短いpromptを置き換えると、どのvolumeでも、永遠に質問あたりの費用は高くなります。そしてthresholdはassistantがどれだけ話すかに比例して伸びるため、長い回答を書くassistantは、どれだけpromptを削ってもfine-tuneで安いtokenへはたどり着けません。

反対側から同じ事実を言うと、覚えるべき文はこれです。fine-tuned経路の質問あたり$0.002088のうち、97.0 %はanswerです。fine-tuningが最適化するのは残り3 %です。

これらの経路はどれも4つの数字で説明できます。一度だけ払うもの、ドキュメントが変わったときに払うもの、質問の有無にかかわらずhourlyで払うもの、質問ごとに払うものです。これは第16章のcomputeCostを、変更せずに拡張します。

import { computeCost, type Pricing, type Usage } from "./cost";   // Chapter 16

export interface Route {
  name: string;
  setupUSD: number;            // paid once, before the first question
  perRefreshUSD: number;       // paid every time the documentation changes
  standingUSDPerHour: number;  // paid per hour whatever the traffic
  pricing: Pricing;
  usage: Usage;                // one question and its answer
}

export const perQueryUSD = (r: Route) => computeCost(r.pricing, r.usage);

const HOURS_PER_MONTH = (24 * 365.25) / 12;

export function totalUSD(
  r: Route, months: number, queriesPerMonth: number, refreshesPerMonth: number,
) {
  return r.setupUSD
       + months * refreshesPerMonth * r.perRefreshUSD
       + months * HOURS_PER_MONTH * r.standingUSDPerHour
       + months * queriesPerMonth * perQueryUSD(r);
}

/** Monthly volume at which `b` overtakes `a`. null = it never does. */
export function crossover(
  a: Route, b: Route, months: number, refreshesPerMonth: number,
): number | null {
  const fixed = (r: Route) =>
      r.setupUSD
    + months * refreshesPerMonth * r.perRefreshUSD
    + months * HOURS_PER_MONTH * r.standingUSDPerHour;
  const dFixed = fixed(b) - fixed(a);                     // b's extra fixed cost
  const dVar = perQueryUSD(a) - perQueryUSD(b);           // b's per-question saving
  if (dVar <= 0) return null;                             // b is never cheaper
  return Math.max(0, dFixed / dVar / months);
}

tuned modelは別のprice listではなく、同じものに掛け算したものです。

const TUNED_MULTIPLIER = 1.5;   // read from the provider's pricing page, 2026-09-07

const scale = (p: Pricing, k: number): Pricing => ({
  input: p.input.map(t => ({ ...t, price: t.price * k })),
  cachedInput: p.cachedInput!.map(t => ({ ...t, price: t.price * k })),
  output: p.output.map(t => ({ ...t, price: t.price * k })),   
});

その強調された1行が、前sectionの議論全体をcodeで書いたものです。multiplierはoutputにも乗ります。

6か月、ドキュメントを毎週refreshした場合：

そしてcrossoverです。予算が実際に必要とする4つの数字です。

retrieval -> fine-tune, documentation never changes:     148 questions / month
retrieval -> fine-tune, documentation refreshed weekly: 3,989 questions / month
prompt (no cache) -> retrieval:                            1 question / month
prompt (no cache) -> prompt (cached):                    546 questions / month

最初の2つは一緒に読んでください。そこがこの章の要点です。静止したcorpusなら、fine-tuningは150質問で元が取れます。毎週変わるcorpusでは、同じcrossoverが27倍ずれます。modelについては何も変わっていません — 再び支払う頻度だけが変わりました。construction costは脚注です。maintenance costが判断そのものです。

ここで、忙しいsupport deskはfine-tuneすべきだと結論するなら、算術はあなたに同意します。それでも間違っています。次のsectionがその理由です。

コスト表には計算できない列が1つあるため、このsectionではfine-tuneを実行します。localで、小さなopen model上で、adapterはlibraryから持ってくるのではなく手で書きます。第11章ではLoRAを作りました。ここではQwen2.5-0.5B-Instruct全24 layerのq_projとv_projにrank 8で適用します。

class LoRALinear(nn.Module):
    def __init__(self, base: nn.Linear, r=8, alpha=16):
        super().__init__(); self.base = base
        for p in self.base.parameters():
            p.requires_grad = False              # the model is frozen  
        self.A = nn.Parameter(torch.zeros(r, base.in_features))
        nn.init.normal_(self.A, std=1 / r)
        self.B = nn.Parameter(torch.zeros(base.out_features, r))
        self.s = alpha / r
        self.on = True                           # so the same run can compare both

    def forward(self, x):
        y = self.base(x)
        return y + (x @ self.A.T @ self.B.T) * self.s if self.on else y

200個のtraining exampleはcorpusから機械的に作るので再現できます。questionはsection headingを質問に変えたもの、answerはそのsection自身のtextを硬いhouse styleにしたものです — Short answer:で始まる1行、file path付きのSource:で始まる1行。教えているformはformatであり、pathはfactです。 そして20個のheld-out questionで2つの数字を見ます。answerがhouse styleで出るか、本当に質問に答えるfileを名指しするかです。

表を読みやすくするためにbaselineを2つ置きます。どちらも後付けではなく第4章の主張です。20個の正解のうち10個は同じfileなので、質問を無視して常にCLAUDE.mdと答えるmodelは10/20点を取ります。そしてretrieverにも固有の上限があります。この20質問で4つの抜粋に正しいfileが含まれたのは14回、1位にrankされたのは7回なので、それを使うreaderが取れる最大は14/20です。

LoRA modules 48   trainable parameters 540,672 (0.109 % of the model)
400 steps, 2 epochs, 0.76 s/step on 16 CPU threads, 304 s in total
mean loss over the first 50 steps 3.7363 -> over the last 50 steps 2.4197

                                        house style   correct source
always answer the most common file             --          10 / 20
the retriever's own ceiling                    --          14 / 20
base model, closed book                    0 / 20           0 / 20
fine-tuned, closed book                   19 / 20           8 / 20
base model, four retrieved extracts       13 / 20           2 / 20
fine-tuned, four retrieved extracts        1 / 20           1 / 20

formは完全に、そして速く学習されました。 graphics cardの影もないprocessor上で5分trainingしただけで、540,672-parameter adapter — modelの0.109 % — が0から20問中19問へ行きました。

factは学習されませんでした。 20問中8問は、質問を完全に無視して得られる10問と区別できません。第4章の20 sampleのintervalもそうはっきり言います。それらのfile pathはtraining data内に3回ずつ入っていました。出てきたのは、もっともらしいSource:行で終える習慣でした。この章の冒頭の質問を投げると、fine-tuned modelはShort answer: 10.x . . .と答え、CLAUDE.mdをciteしました。正解はCLAUDE.mdにあり、18.17.0です。

そしてformが壊れました。これが実験を正当化する行です。 fine-tuned modelに、検索された抜粋1000 tokenを渡します — training promptはすべて28 tokenだったので、一度も見たことがないprompt shapeです — するとhouse styleは19/20から1/20へ崩れます。この章冒頭の質問には18.17.0と答えます — 正しいですが、trainingされたformatは何もありません。つまりfine-tuningはformatを教えたのではありません。training set内のpromptsに条件付けられたformatを教えたのであり、最初に違う見た目のpromptが来るとformatも一緒に消えました。fine-tuneした対象は何であれ、modelが得意になる唯一のinput distributionになります。そして誰もそれをspreadsheetには入れません。

metricについて最後に一言。第29章をまっすぐ指しています。「correct source」はformとfactを一緒に採点します。だから、その質問のfactは両方のmodelが正しく答えたにもかかわらず、retrievalの両rowはひどく見えます。1つのend-to-end numberが3つを隠していました — 14/20 recallのretriever、0.5B reader、citation formatです。どれを直すかを選ぶには、測る前にそれらを分ける必要があります。後ではありません。

次はvendorが勝手に埋める列です。fine-tuned modelはあなたが所有するassetではありません。他人のbase modelを借りるleaseであり、そこには終了日が印字されています。2026年9月7日、OpenAIのpricing pageのfine-tuning sectionには、このnoticeが全文掲載されていました。

OpenAIはfine-tuning platformを段階的に終了しています。このplatformは新規userにはアクセスできなくなっていますが、fine-tuning platformの既存userは今後数か月間training jobを作成できます。すべてのfine-tuned modelsは、それぞれのbase modelsがdeprecatedになるまでinferenceで利用可能です。⁷

timelineは日付付きです。2026年5月7日、fine-tuneしたことのないorganizationにはclosed。2026年7月2日、fine-tuned modelで60日間inferenceを実行していないorganizationにはclosed。2027年1月6日、新規jobは完全に停止です。⁸ 同じページはfine-tuned models自身のshutdownもscheduleしています — ft-gpt-3.5-turbo、ft-gpt-4、ft-gpt-4.1-nano、ft-babbage-002、ft-davinci-002 — 2026年10月23日に、それぞれにrecommended replacement base model付きで。これは丁寧な言い方で、つまり「もう一度trainingしろ」です。

もう一方のfrontier vendorは、そのleaseをそもそも売っていません。Anthropicのdocumentation indexには699 pageが並びますが、fine-tuningについてのpageは1つもありません。Bedrock pricing pageのmodel-customisation sectionはAmazon Nova、Amazon Titan、Cohere、Meta、OpenAI open-weight modelsを扱いますが、Claudeはありません。⁹¹⁰ あなたのarchitectureがfine-tuneに依存するなら、3つのfrontier familyのうち1つは、どんな予算でも利用できません。

self-hostingはmodelへのleaseをmachineへのleaseに置き換えます。そしてAWSはその算術を自分のpageに載せています。customised model用のprovisioned throughputの1 model unit、1か月commitmentは「1 model unit × $21.18 × 24 hours × 31 days = $15,757.92」/月です。¹⁰ metalを直接rentする方が安いですが無料ではありません — H100はon demandでGPU-hourあたり$3.99、preemptibleで$1.99¹¹ — 誰も質問しなくても起動していなければならない1枚のcardに月およそ$2,900です。月1万質問でのretrieval経路全体は、6か月で$174.52です。

ここでLoRAは、技術ではなく予算の議論として価値を持ちます。同じmodelで測ると、attentionとfeed-forward layers全体のrank-16 adapterは8,798,208 parameters — modelの1.781 %、bfloat16で17.6 MB — です。base weightsの0.988 GBに対し、そのoptimiserとgradient stateは140.77 MBで、full fine-tuningが必要とする7.90 GBの56分の1です。帰結はtrainingが安くなることではなく、1つのloaded base modelで多数のadapterをserveできることです。これがGPUのfixed costを何かで割れる唯一の方法です。managed trainingにもそれは反映されています。16Bまでのlow-rankは100万tokenあたり$0.48、fullは$0.54で、jobあたり$4.00 minimumがあります。¹¹ そのfloorが重要です。24,389 tokenを3 epochs回す場合、このcorpusのretrainingは毎回、計算上の$0.04ではなく$4.00請求されます — 週次26回で算術上は91セントなのに、minimumで$104です。

請求書にだけ現れる列が、さらに2つあります。

Data residencyは約10 %かかり、2つのproviderがその数字で一致しています。 OpenAIは2026年3月5日以降にreleasedされたmodelsのdata-residency endpointsに「10 % uplift」を課します。⁷ Vertexはnon-global endpointsを$1.50に対して$1.65にしており、同じ10 %です。⁶ tuned endpointにかかる50 %と比べれば、俗説は反転します。residencyは安く、fine-tuningは安くありません — しかもfine-tuningはprivate optionでもありません。corpusはどちらにせよproviderに届くからです。callごとではなく、training時に一度届くだけです。

あなたのdataに付けられた最も明示的な価格は同じページにあります。そこでは1つのfine-tuned modelが2回掲載されています。data sharing enabledでは、inferenceはちょうど半額です — inputは$4.00に対して$2.00、outputは$16.00に対して$8.00です。⁷ providerに送信内容を保持させることは50 % discountの価値がある、ということです。それが彼らにとってどれだけ価値があるかを教えています。

Distillation — 大きなmodelのanswerで自前の小さなmodelをtrainingすること — は、よく両方からの抜け道として提示されます。価格を付けると、そうではありません。teacherは置き換えようとしていたsystemそのものだからです。retrieval経路に200質問してtraining exampleを200個作るコストは、200 × $0.002906 = $0.58で、それらをtrainingする$0.73に上乗せされます。Distillationはretrieval pipelineが動いた後に、それを安くするために行うものです。そしてretrieverが間違えたfactをすべて継承します。

お金は見える半分です。もう半分は待ち時間として来ます。請求額と同じ原因です。modelは一言話す前にprompt全体を読みます。第13章では、触れるmodelでprefillとdecodeを測りました。ここでは同じ測定を、1 run、1 machineで、prompt lengthに対して行います。

絶対値は16 CPU threads上の0.5B modelのものであり、hosted frontier modelについては何も語りません。shapeはそのまま移ります。prefillはprompt lengthとともに増え、第9章の二次項が見え始めるとtokenあたりcostもじわじわ上がります — 1000 tokenで4.79 ms、8000 tokenで6.04 ms、長いだけで26 %のpenaltyです。

3つの経路への帰結は直接的です。経路1は質問ごとに43,000 tokenをprefillし、cache hitがそれを耐えられるものにします。第16章が理由を説明しました。cache readはprefill workを置き換えるため、latencyとお金を1つのtransactionで買います。経路2は1000 tokenをprefillし、先にindexへのround tripを追加します。経路3は28 tokenをprefillするだけで何も追加しないため、回答速度では3つの中で測定上最速です。ただし、間違ったことに答えているだけです。

model problemに見えてそうではないfailureが3つあります。ここで10分かければ、後で1か月を節約できます。

そして全体にかかる要件です。この判断はevaluation setなしにはできません。そしてfine-tuneを売るvendor自身がそう言っています。 OpenAIのguideは「evalsを設定した後でのみfine-tuningに投資してください。fine-tuned modelがbase modelより良くperformしているかを判断する信頼できる方法が必要です」で始まり、50個の良いexampleで何も変わらないなら、問題はtaskかpromptであってdata volumeではない、と付け加えます。¹ この章で使った20質問はmechanismを示すことはできますが、supplierを選ぶことはできません — 第4章ではその理由を測りました。そして20 caseしかないときに何をすべきか — 繰り返し、pairにし、run間のspreadを測る — は第29章です。

4列です。そして最後の列だけが決めます。

そこから出てくるruleは、覚えられるほど短いです。promptから始める。factが動くなら検索を足す。まだ足りないものがfactではなくshapeだと測定できたときだけfine-tuneする — そしてその前に、promptではなくanswerの価格を付ける。

すでに結論を決めて来た人にとって不快な版はこうです。この章で測定したcaseでは、月4000質問を超えるとfine-tuningは最安の経路です。それでもfactについては、すべてにCLAUDE.mdと答えることに勝てません。

ここまでの価格はすべてtoken単位で、すべての経路はtokenの並べ方の違いでした。それはもうすぐ成り立たなくなります。

第21章はtextを離れます。modelに入るimageはstringではなく、あなたが選んでいないtoken countを持つpatchのgridです。spoken minuteは、あるproviderでは秒単位で、別のproviderではaudio token単位で請求されます。synthetic speechは文字単位、transcriptionは分単位、raw computeはGPU-second単位で売られます。この章が1つのcost functionで答えた問い — どちらが安いか？ — は、unitが揃うまで問うことすらできません。そしてinternet上のcalculatorはそれらをnormaliseしてくれません。

ここで、trainingも再び登場します。trigger wordを持つimage adapterと、sampleからclonedされたvoiceです。そこで次章が開く問いが生まれます。これは修辞疑問ではありません。language modelのfine-tuningがほとんど常に間違ったpurchaseなら、なぜimage modelのfine-tuningはほとんど常に正しいのでしょうか？

この章のすべてのprice、threshold、multiplierは、2026年9月7日にprovider自身のpageから読み、その日付付きで引用しています。すべて動くからです。測定値 — token counts、chunk sizes、retrieval sizes、training loss、scores、latencies、version-history counts — は同じ日に1台のmachineで生成され、上で説明したcorpusから再現できます。

local experimentsはgreedy decodingでQwen/Qwen2.5-0.5B-Instructを使ったため、正確に再現できます。adapterは上に印字した12行のclassで、q_projとv_projにrank 8で適用しています。corpusは、稼働中のあるsoftware repositoryでtrackedされているMarkdown documentationで、2つのappend-only logを除いたものです。そのchange rateは、そのrepositoryのversion historyから数えました。