この記事ではClaude Codeの3つのモデルOpus、Sonnet、Haikuの使い分けの判断の参考にするために、「チベット文字の読み方を表示するウェブページ」という課題を各モデルに実施させて、色んな方面で結果を比較します。
はじめに
今年の後半から、会社でClaude Codeを使って作業するようになりました。その後個人でもClaudeを契約して、今では家でも毎日Claude Codeを使っています。
最初はほとんどOpusばかり使っていましたが、仕事が増えるにつれて使用量の上限が厳しくなってきました。そんな時に最近Haiku 5.5が公開されて、評判もいいと聞いたので、使ってみようかと考えるようになりました。
ただ、どのモデルをどんな時に使えばいいかはなかなか悩ましいところです。それを掴むために、ある課題を作ってOpus・Sonnet・Haikuの3つのモデルにやらせて、その結果を比べてみることにしました。
今回思いついた課題は「チベット文字の読み方を表示するウェブページ」です。
私は言語学が趣味で、色んな文字を勉強してきて読めるようになりました。以前もこのように記事を投稿しました。
その中でも特に気に入っているのがチベット文字です。書きやすくて美しい文字ですが、実はこの文字の読み方はとても複雑で、習得するのはかなり大変です。だからこそ課題としてちょうどいいと思いました。
この課題には次のような要素が含まれています。
- 情報収集：チベット語の発音のルールを正しく調べられるか
- プログラミング：複雑な綴りの規則を正しく実装できるか。Vue.jsでページを組み立てられるか
- 文章：変換ルールを日本語でわかりやすく説明できるか
一つの課題でプログラミングと文章の両方の能力を見られるのがポイントです。
この記事の書き方について
最初に言っておきたいことがあります。この比較実験の準備や実行、つまりテスト用の単語の収集や、モデルの実行、採点役のAIの準備などは、Claude Code（Opus 5.5）の補助を受けながら進めました。この記事の文章もClaude Codeに下書きを手伝ってもらっています。
ただし、実験の方針や評価の観点は全部私が決めたし、結果も私が自分の目で確認した上で書いています。このようにAIの比較をAIに手伝ってもらうのも今どきのClaude Codeの使い方の一つだと思います。
チベット文字とは
チベット文字（བོད་ཡིག）はチベット語を書くための文字です。7世紀頃、インドのブラーフミー系の文字を元に作られたと言われています。伝説では、ソンツェン・ガンポ王の命令で大臣のトンミ・サンボータがインドに留学して作ったとされています。
今でもチベット自治区や青海省などの中国のチベット族の地域、ブータン（ゾンカ語）、ネパールやインドのヒマラヤ地域などで使われています。
文字の仕組み
チベット文字はアブギダの一種です。子音字30個がそれぞれ母音「a」を含んでいて、他の母音は記号を上下に付けて表します。
| 文字 | ཀ | ཁ | ག | ང |
|---|---|---|---|---|
| ラテン文字転写 | ka | kha | ga | nga |
| 文字 | ཀ | ཀི | ཀུ | ཀེ | ཀོ |
|---|---|---|---|---|---|
| ラテン文字転写 | ka | ki | ku | ke | ko |
音節と音節の間には「ツェク」（་）という点を打って区切ります。単語の間には空白を入れません。文の終わりには「シェー」（།）を書きます。
読み方が難しい理由
チベット文字の綴りは9世紀頃に固まって、それ以来ほとんど変わっていません。一方で、発音の方は千年以上の間に大きく変化しました。その結果、今の発音では読まない文字が沢山あります。
一つの音節は最大でこのような構造になっています。
前置字 + 上置字 + 基字 + 下付字 + 母音記号 + 後置字 + 再後置字
例えば「8」を意味する བརྒྱད（ラテン文字転写：brgyad）は、b・r・g・y・dの5つの子音字で書かれて、古代チベット語では文字通り[brɡʲat]（ブルギャット）と発音していたが、現代のラサの発音は［cɛː˩˧˨］（チェー）です。最初のbとrは読まず、gとyが合わさって一つの子音になり、最後のdは読まずに母音aをɛに変えて長くします。
また、ラサの発音には声調があります。これは昔の有声音と無声音の区別や前置字の有無が、音の高さの違いに変わったものです。綴りに声調は書かれていないので、綴りの規則から推測する必要があります。
このように、綴りから発音を求めるには規則を幾つも重ねて適用する必要があるので、プログラムで変換するのは意外と大変です。
日本語のカタカナ表記について
チベットの地名や人名などは、日本語では慣習的なカタカナ表記がよく使われます。しかし、これらの多くは綴りのラテン文字転写や英語表記、または他の言語から来たもので、実際のラサの発音とは違う場合が多いです。
| 語 | 綴り（転写） | よく使われる表記 | ラサの発音（Wiktionary） | IPA通りのカタカナ |
|---|---|---|---|---|
| ཏཱ་ལའི་བླ་མ | tā la'i bla ma | ダライ・ラマ | ta˥˥.lɛː˥˥ la˥˥.ma˥˥ | タレーラマ |
| དབུས | dbus | ウー | ʔyː˥˨ | ユー |
| བོན | bon | ボン（ボン教） | pʰø̃˩˨ | ポェン |
| གཏོར་མ | gtor ma | トルマ | toː˥˥.ma˥˥ | トーマ |
| གཡག | g.yag | ヤク | ja˥˨ | ヤ |
どれも、各音節を1音節の規則だけで読めば正しい発音になる例です。
- 「ダライ」は元々モンゴル語で「海」という意味の言葉で、チベット語ではこれを ཏཱ་ལའི と音写しています。ラサでは「タレー」のように発音します。後ろに付いている འི（属格の「〜の」）が、母音 a を ɛ に変えて長くするからです
- 「ウー」（中央チベットの地域名）は、後置字 ས が母音 u を前寄りの y（ドイツ語の ü）に変えるので、IPA通りに書くと「ユー」に近くなります
- 「ボン」は、ラサの発音では綴りの b が無声の有気音 pʰ になり、後置字 ན で母音 o が ø の鼻母音になります
- 「トルマ」や「ヤク」は綴りの r や g をそのまま読んだ形ですが、ラサの発音では後置字 ར は前の母音を長くするだけで、後置字 ག はほとんど聞こえません
今回の課題ではIPA通りのカタカナを要求しているので、こういった慣習的な表記に引きずられないかも注目点の一つです。
Unicodeでの扱い
プログラミングの観点で言うと、チベット文字はUnicodeのU+0F00〜U+0FFFに収録されています。面白いところは、上下に重ねた文字の表し方です。例えばསྐ（ska）は「ས」（U+0F66）と、下に付く形の「ྐ」（U+0F90）の2文字で表されます。普通の「ཀ」（U+0F40）とは別の文字コードなので、変換プログラムではこの区別も正しく扱う必要があります。
課題の内容
3つのモデルに出した指示は次の通りです。3つとも一字一句同じです。
チベット文字を読み方に変換するためのウェブページを作ってください。
- チベット文字を入力するテキスト欄と、その下に結果のIPAとカタカナを表示する。
- 発音はラサの標準チベット語のみ。
- カタカナ表記はIPA通りにする。よく使われているチベット地名のカタカナ表記とは違う場合が多いので注意。
- 変換ツールの下に変換ルールを書く。読み方のルールは表で説明する。その表は実際の変換ルールに合わせ、HTMLに直接書くのではなくJSで生成する。
- ページはVue.jsで作る。<script src="https://unpkg.com/vue@3/dist/vue.global.js"></script>
- 全部一つのHTMLファイルにまとめ、このフォルダに保存する。
声調をどう表すかは、わざと指定しませんでした。声調を扱うかどうか、扱うならどう表すかも、各モデルの判断に任せて評価の対象にしました。
CLAUDE.mdについて
Claude Codeでは、~/.claude/CLAUDE.mdに書いたユーザー共通の指示が毎回自動で読み込まれます。私のCLAUDE.mdには資料を作る時のスタイルが色々書いてあるので、直接の指示に加えて、これも結果に影響するはずです。
ダミーに差し替えることも考えましたが、普段の使い方での比較にしたいので、本物をそのまま使うことにしました。ここでは関係ある部分だけ載せておきます。「<p>を使わない」「idやclassは日本語」「目次と🏠を付ける」「変数名に複数形を使わない」などの細かい規則があるので、これをどれだけ守れるかも評価の観点の一つになります。
CLAUDE.mdの一部
# 資料作成
- ファイル名は内容の言語に合わせる。ANSIに拘る必要がない
- 説明資料と文章は特に指定がない限りhtmlで作成する
- 指定がない限り資料は作業フォルダ内でファイル保存する
- 特に言語指定がないかぎり、命令を書いた言語で資料を作成する
- 4セクション以上あったら目次も作る
- 各セクションの見出しの右に、クリックで目次へ移動する「🏠」文字を置く
- 参考書に同じウェブサイトの複数ページがある場合、一緒に纏めて<li>の中のサブ項目にする
- 重要な人名や地名は文章の中で初登場の時は強調を付ける
- 文章のメイン言語と違う言語の固有名は、最初に登場する時だけ元の言語を括弧に入れる
## html資料
- <html>、<body>、<head>タグは不要
- <header>、<footer>、<p>タグを使わない
- <meta charset="UTF-8"><title>で始まる
- 目次は「a href」ではなく、JavaScriptによるページ内移動を使う
- idやclassは英語ではなく、資料の言語と同じ言語を使う
- 参考資料はリンクを付ける
- リンクは「target="_blank"」を使う
- CSSは冗長な重複を避け、必要最低限の記述に留める(テーマ変数などの重複ブロックはまとめる)
- <style>の中のCSSはタグ名単体ではなく、常にidとclassを書く。ただし親要素に書いてあったら子要素は書かなくてもいい
# コーディング
- 変数や関数などの名前は絶対に複数形の英単語を使わない
- リストや配列の変数であることを明記したい場合、「_list」語尾に付けるのが好ましい
実験の方法
モデルの実行
3つのモデルは、Claude Codeのヘッドレスモード（claude -p）で別々のセッションとして同時に実行しました。
claude -p "$(cat ../指示.md)" --model claude-opus-5-5 --effort medium \
--permission-mode acceptEdits \
--allowedTools "Read Write Edit Glob Grep Bash WebSearch WebFetch" \
--output-format stream-json --verbose > ../記録_C.jsonl
条件は次の通りです。
- effortは3つともmediumに揃えた。実は私の
settings.jsonでは、普段Opusはmedium、Haikuはxhighに設定していたので、今回はコマンドで指定して揃えた - Web検索は許可した。情報を集める力も評価の対象になる
- ヘッドレスモードなので、途中でユーザーに質問はできない
- 作業フォルダは「A」「B」「C」という名前にして、フォルダ名からモデルがわからないようにした。どのフォルダをどのモデルに割り当てるかはランダムに決めた
- 各モデル1回ずつ実行した。修正の依頼はしていない
テスト用の単語
変換が正しいかどうかを確かめるために、1音節の単語を100語用意しました。
正解の基準にしたのは、英語版Wiktionaryのラサ方言のIPAです。Wiktionaryでは{{bo-IPA}}というテンプレートで発音を書いていて、編集者が入力したチベット語のピンイン（Tibetan pinyin）から、モジュールがIPAを自動で生成しています。
1音節の単語だけにした理由
チベット語では、音節が続くと発音が変わることがよくあります。例えば、前の音節の母音が後ろの音節の母音に引かれて変わったり（母音調和）、子音が隣の子音に合わせて変わったり（同化）、2音節目の母音が弱くなったりします。
| 語 | 綴り（転写） | 1音節ずつ読むと | Wiktionary |
|---|---|---|---|
| ཨ་མདོ（アムド） | a mdo | ʔa.to | ʔam.to |
| དགོན་པ（寺） | dgon pa | kø̃.pa | kom.pa |
| ཉི་མ（太陽） | nyi ma | ɲi.ma | ȵi.mə |
3つのモデルとも、こういった2音節以上の規則はほとんど扱っていませんでした。SonnetとHaikuは全く扱っておらず、Opusも語中の ག を k、語中の བ を w にする2つだけで、前鼻音化などは「実装していない」とページに書いています。どのモデルも実装していない規則でテストしても、モデルの間の差は見えず、全員が同じように間違えるだけです。
そこで、テスト語は1音節の単語だけにして、数も切りのいい100語にしました。
単語の選び方
Wiktionaryの「Tibetan terms with IPA pronunciation」の分類にあるページは1604あり（2026年10月12日時点）、そのうち1音節の語は519、ラサのIPAが取れたのは453語でした。
この453語から、規則通りに読む単語を選ぶために、1音節の規則だけで読みを出す簡単な変換プログラムを書いて、Wiktionaryと比べました。結果は次の通りです。
- 一致した：340語
- 一致しなかった：67語
- 読みが複数ある、または変換プログラムでは扱えない綴り：46語
一致しなかった67語には、本当の例外的な読みのほかに、Wiktionaryの入力ミスと思われるもの（ཁང が khaŋ になっている、など）や、他の方言の表記が混ざったものもありました。
選んだ100語は一致した340語の中から、次のような規則が一通り含まれるように選びました。
- 前置字・上置字・下付字の扱い
- 後置字による母音の変化（ä ö ü）、長母音、鼻母音
- 声調の高低
- ལྷ→ɬ、དབ→w、སྨྲ→m などの特別な綴り
採点
採点は、モデル名を伏せた状態でOpus 5.5（effortはhigh）にやらせました。3つの成果物は「甲」「乙」「丙」という名前にしてランダムに並べ、採点者にはどれがどのモデルの作品かを教えていません。
採点者には、テスト語を各ページで実際に変換させました。採点者はヘッドレスChromeで各ページを開き、テキスト欄に単語を1つずつ入れて、画面に出た結果を記録しました。変換のコードには手を加えていません。
変換の正確さの判定方法
テスト語の判定は、判定用のスクリプトで機械的に行いました。
まず、表記の流儀の違いを揃えてから比べます。3つのモデルもWiktionaryも、IPAの書き方が少しずつ違うからです。
-
t͡ɕとtɕ、ȵとɲは同じとする。反り舌音のʈ͡ʂ・tʂ・ʈも同じとする - ར の音を表す
r・ɹ・ɻ・ʐは同じとする - 語頭の
ʔ、無開放の記号̚、ˀは取り除く - 声調は高低だけを見る。
˥˥・˥˨・áなどは「高」、˩˨・˩˧˨・àなどは「低」とする。上がるか下がるかといった形の違いは問わない - 後置字 ག の音節は、
ʔ・k・末子音なしのどれでも正解とする - 後置字 ད の音節は、長音の
ːと声門閉鎖音のʔのどちらかがあれば正解とする。どちらで表すかは研究者によって違うからである - 後置字 ན の音節は、鼻母音
ɛ̃の代わりにɛnと書いても、鼻音化は正解とする - 後置字 ར の音節は、母音が長いか、末子音 r があれば正解とする。Wiktionaryでは
kʰaː(ɹ)のように、r は括弧付きで「読んでも読まなくてもいい」という扱いになっている。r を末子音として読むなら、母音は長くなくてもいい
（1音節100語に替えた時に、ʐ と後置字 ར の扱いを足しました。ʐ はWiktionaryが ར の音を表す記号で、最初の73語には ར で始まる語がなかったので問題になりませんでした。また、ལྕགས のように ག の後に ས が付く音節も後置字 ག として扱うように、スクリプトを直しました）
その上で、次の6つの特徴を比べます。
- 子音
- 有気性
- 母音の質（ä ö ü など）
- 鼻音化
- 韻尾（母音の長さと末子音）
- 声調の高低
1つの単語で、誤りがなければ1点、1つなら0.5点、2つ以上なら0点です。テスト語は100語なので、合計点がそのまま百分率の正答率になります。「変換の正確さ」の点は、この合計点に0.3を掛けたものです（配点は30点）。
それ以外の観点（声調の扱い、カタカナ、ルール表と説明など）は、採点者がコードと画面を読んで判断しています。
配点は次の通りです。
| 観点 | 配点 | 見るところ |
|---|---|---|
| 変換の正確さ | 30 | テスト語の正答率 |
| 声調の扱い | 10 | 声調を扱っているか。扱っているなら規則は正しいか |
| カタカナ | 10 | IPAとの対応が一貫しているか |
| ルール表と説明 | 15 | 表が実際の変換データから生成されているか。説明が正しくわかりやすいか |
| コードの品質 | 10 | 読みやすさ、Vueの使い方 |
| CLAUDE.mdと指示の遵守 | 10 | CLAUDE.mdの規則を守っているか |
| 見た目と使いやすさ | 10 | レイアウト、使いやすさ |
| 頑健性 | 5 | 空欄、チベット文字以外の混在、サンスクリット由来の文字などへの対応 |
採点者への指示の全文
このフォルダには、同じ指示（指示.md）で3つのAIモデルが作った「チベット文字を読み方に変換するウェブページ」が3つある（甲.html・乙.html・丙.html）。どれがどのモデルかは知らされていない。作成時には 作成時のCLAUDE.md も自動で読み込まれていた。これらを公平に採点してほしい。
## 手順
1. 指示.md と 作成時のCLAUDE.md を読む。
2. 3つのページのコードを全部読む。
3. テスト語.csv の100語を各ページで実際に変換して、出力を記録する。ページはVueをunpkgから読み込むので、ヘッドレスChrome（/Applications/Google Chrome.app）を使ってもいいし、変換ロジックを取り出してNodeで実行してもいい。ただし、変換ロジックには手を加えないこと。
4. 正解はWiktionaryのIPA（テスト語.csvの3列目）。表記の流儀の違い（t͡ɕ と tɕ、˥˥ と高声調を表す別の記号、長音の ː の有無の扱いなど）は、音として同じなら正解とする。判定するのは、子音・有気性・母音の質（ä ö ü など）・母音の長さ・鼻音化・末子音・声調の高低。声調を出力しないページは、声調以外の部分で判定し、声調を扱わなかったことは別の項目で評価する。
5. 頑健性も確かめる。次の入力を試す: 空欄、`ཁྱི། མི`（シャッドと空白）、`བོད་ཡིག abc 123`（チベット文字以外が混ざる）、`ཀྵ`・`ཧཱུྃ`（サンスクリット由来の結合文字）、`༡༢༣`（チベット数字）。
6. 必要なら、Web検索で言語学的な説明の正しさを確かめてよい。
## 評価の観点（合計100点）
| 観点 | 点 | 見るところ |
|---|---|---|
| 変換の正確さ | 30 | テスト語100語の正答率。部分的に正しいものは部分点 |
| 声調の扱い | 10 | 声調を扱っているか。扱っているなら規則は正しいか |
| カタカナ | 10 | IPAとの対応が一貫しているか。慣用表記に流されていないか |
| ルール表と説明 | 15 | 表が実際の変換データから生成されているか、表と実際の動作は一致するか、説明は言語学的に正しくわかりやすいか |
| コードの品質 | 10 | 読みやすさ、Vueの使い方、データとロジックの分け方 |
| CLAUDE.mdと指示の遵守 | 10 | 指示.md と 作成時のCLAUDE.md の規則（html・CSS・命名など）を守っているか |
| 見た目と使いやすさ | 10 | レイアウト、入力した時の反応、読みやすさ |
| 頑健性 | 5 | 手順5の入力への対応 |
## 出力
- 採点結果.md を日本語で書く（このファイルだけはMarkdownでよい）。中身は次の通り。
- 点数表（観点ごと・合計）
- テスト語100語について、各ページの出力と正誤を並べた表
- 各ページの長所と短所。具体的な例とコードの行番号を付ける
- CLAUDE.md違反の一覧
- 総評
- 3つのhtmlファイルは変更しないこと。作業用のファイルは 作業/ フォルダの中に作る。
結果
点数
| 観点 | 配点 | Opus | Sonnet | Haiku |
|---|---|---|---|---|
| 変換の正確さ | 30 | 30 | 22.1 | 13.7 |
| 声調の扱い | 10 | 9 | 5 | 3 |
| カタカナ | 10 | 9 | 6 | 5 |
| ルール表と説明 | 15 | 14 | 8 | 4 |
| コードの品質 | 10 | 8 | 8 | 7 |
| CLAUDE.mdと指示の遵守 | 10 | 9 | 8 | 5 |
| 見た目と使いやすさ | 10 | 8 | 8 | 7 |
| 頑健性 | 5 | 5 | 4 | 3 |
| 合計 | 100 | 92 | 69.1 | 47.7 |
| テスト語の合計点 | 100 | 100 | 73.5 | 45.5 |
| テスト語の完全正解 | 100 | 100 | 54 | 24 |
Opusが圧勝でした。点数の差のほとんどは、変換の正確さと、ルールの説明の正しさから来ています。コードの品質や見た目では、3つの差はあまりありません。
（「変換の正確さ」は1音節100語で判定し直した点数です。2音節を含む最初の73語では、Opus 29.3・Sonnet 23.3・Haiku 15.5で、順位は同じでした）
Opusが満点にならなかった理由
Opusは92点で、8点を落としています。テスト語は100語全部正解だったので、減点は全部それ以外の観点です。どこで減点されたのかをまとめます。
| 観点 | 減点 | 理由 |
|---|---|---|
| 声調の扱い | 1 | 高低は100語全部正しいが、下降調（˥˨）は再後置字 ས・ད がある時にしか付けない。そのため閉鎖音で終わる ཁྲག・ཚིག なども平らな ˥˥ になる。ただし、この簡略化はページに明記している |
| カタカナ | 1 | 採点者は「一貫している」とだけ書いていて、具体的な減点理由は書いていない。音節の区切りがなく読みにくいこと（見た目の項目を参照）が影響したと思われる |
| ルール表と説明 | 1 | 採点者は「正確で網羅的」とだけ書いていて、具体的な減点理由は書いていない |
| コードの品質 | 2 | 変数名が r・L・p のように短すぎる。v-for に :key がない。表のテンプレートで <tbody> を省いたので、Vueの警告が出る |
| CLAUDE.mdと指示の遵守 | 1 | classの名前に英字の .IPA を使っている（略語なので軽微） |
| 見た目と使いやすさ | 2 | 音節を区切らないので、pʰøʔ˩˨jiʔ˩˨、「ポェッイッ」のように読みにくい。目次と説明が上にあって結果が画面の下にはみ出し、ページ全体もとても長い |
変換の正確さは満点なので、減点の多くはコードの書き方や見た目の細かいところです。採点者が理由を書いていない減点もあるので、満点との差は「完璧ではないが、大きな問題もない」くらいの意味だと思います。
なお、Opusは後置字 ར を r のまま出します（མར → mar、ཤར → ɕar）。ラサの発音では、ར は普通は読まずに前の母音を長くするだけですが、丁寧に発音すると r が残るという記述もあり、Wiktionaryでも kʰaː(ɹ) のように括弧付きで r を書いています。なので、r を末子音として読むなら長音でなくても正解としました。
時間と費用
| Opus | Sonnet | Haiku | |
|---|---|---|---|
| 所要時間 | 10.7分 | 8.8分 | 6.1分 |
| ターン数 | 12 | 3 | 9 |
| 出力トークン | 62,375 | 68,968 | 83,858 |
| うち思考トークン | 42,008 | 55,246 | 72,451 |
| 費用（API料金換算） | $2.01 | $1.03 | $0.12 |
| 使ったツール | Bash 5、Edit 3、Write 1、WebFetch 1 | Write 1、Bash 1 | Bash 5、Edit 2、Write 1 |
| ファイルの大きさ | 32KB | 24KB | 17KB |
費用はclaude -pの結果に出るtotal_cost_usdの値で、APIの料金で計算したものです。サブスクリプションで使う場合、実際に払う金額とは違います。ちなみに採点の方は9.5分、$2.71でした。
Haikuは安くて速く、費用はOpusの約16分の1でした。面白いことに、思考トークンを一番多く使ったのはHaikuです。
ターン数とは
「ターン数」は、claude -pの結果に出るnum_turnsの値です。Claude Codeは、モデルがツールを呼び出す → ツールの結果を受け取る → それを見てまた考える、という往復を繰り返して作業を進めます。ターン数は、大まかにはこの往復の回数に最後の報告を足したものです。実際のログを数えると、どのモデルも「ツールを使った回数＋1」になっていました。
- Sonnet（3ターン）：ファイルを1回で書いて（Write）、Bashで1回確かめて、報告して終わり
- Haiku（9ターン）：書いた後、Bashで動作を確かめてはEditで直す、を繰り返した
- Opus（12ターン）：WebFetchで調べてから書き、確認と修正を繰り返した。表のツールのほかに、WebFetchを使えるようにするためのToolSearchも1回使っている
ただし、ターン数はモデルへのリクエストの回数とは少し違います。Opusは1回のリクエストで複数のツール（例えばEditを3つ）を同時に呼び出すことがあったので、ターン数は12でも、実際のリクエストは9回でした。
ターン数そのものは、成果物の良し悪しを表す数字ではありません。ただ、次の2つの意味で少し参考になります。
- 作業の進め方：ターン数が多いほど、書いた後に確かめたり直したりしている。Sonnetは3ターンしかなく、ほとんど確かめずに出したことがわかる
- 費用：リクエストのたびに、それまでの会話を全部キャッシュから読み直すので、ターン数が多いほどキャッシュ読み込みの費用が増える（後の「費用の詳細」を参照）
結局、重要なのは所要時間と費用の方なので、ターン数は「どんな作業をしたか」を見るための補助的な数字だと考えればいいと思います。
費用の詳細
モデルを選ぶ時に一番気になるのはやはり費用なので、ここでは詳しく見ていきます。
Haikuを1とすると何倍か
先に結論を書きます。Haikuの費用を1とした時、OpusとSonnetの費用は次の通りです。
| Opus | Sonnet | Haiku | |
|---|---|---|---|
| 今回実際にかかった費用 | 16.2倍 | 8.3倍 | 1 |
| 公式の料金表（入力・出力の単価） | 40倍 | 20倍 | 1 |
| 公式の料金表（Haikuのプロンプトが10万トークンを超えた場合） | 8倍 | 4倍 | 1 |
OpusはSonnetの約2倍、SonnetはHaikuの約8倍、OpusはHaikuの約16倍でした。
料金表だけを見るとOpusはHaikuの40倍もしますが、実際には16倍くらいで済みました。理由は後で説明します。
公式の料金
料金のページによると、100万トークンあたりの料金は次の通りです。
| Opus 5.5 | Sonnet 5.5 | Haiku 5.5（10万トークン以下） | Haiku 5.5（10万トークン超） | |
|---|---|---|---|---|
| 入力 | $4 | $2 | $0.10 | $0.50 |
| キャッシュ書き込み（1時間） | $8 | $4 | $0.20 | $1 |
| キャッシュ読み込み | $0.20 | $0.10 | $0.01 | $0.05 |
| 出力（思考を含む） | $20 | $10 | $0.50 | $2.50 |
注意すべき点がいくつかあります。
- Haiku 5.5だけは、1回のリクエストのプロンプトが10万トークンを超えると、全部の単価が5倍になる。プロンプトの長さにはキャッシュから読み込んだ分も含まれる。OpusとSonnetは100万トークンまで同じ単価
- OpusとSonnetのキャッシュ読み込みは入力の0.05倍で、他のモデル（0.1倍）より割引が大きい
- 思考トークンは出力トークンとして課金される
Claude Codeでは、システムプロンプトやそれまでの会話は毎回キャッシュから読み込まれます。そのため実際の費用は「入力」の単価よりも、キャッシュの書き込み・読み込みと出力の単価で決まります。
費用の内訳
使ったトークンの数と、それに単価を掛けた費用の内訳です。
| Opus | Sonnet | Haiku | |
|---|---|---|---|
| キャッシュ書き込み | 80,688トークン | 81,551トークン | 98,656トークン |
| キャッシュ読み込み | 546,271トークン | 122,250トークン | 755,275トークン |
| 出力 | 62,375トークン | 68,968トークン | 83,858トークン |
| キャッシュ書き込みの費用 | $0.646 | $0.326 | $0.033 |
| キャッシュ読み込みの費用 | $0.109 | $0.012 | $0.036 |
| 出力の費用 | $1.248 | $0.690 | 約$0.055 |
| うち思考の費用 | $0.840 | $0.552 | - |
| その他 | $0.008 | - | - |
| 合計 | $2.010 | $1.028 | $0.124 |
- 入力（キャッシュを使わない分）は3つとも20トークン以下で、費用はほぼ0なので省いた
- Opusの「その他」は、Claude CodeがWebFetchの結果を要約するために裏でHaikuを使った分
- Haikuの費用はリクエストごとに単価が変わるので、出力の費用は合計から逆算した
どのモデルも、費用の半分以上は出力（思考を含む）です。特に思考だけでOpusは$0.84、Sonnetは$0.55かかっていて、合計の4〜5割を占めています。
面白いのは、キャッシュ読み込みの費用ではSonnetの方がHaikuより安かったことです。Sonnetはわずか3ターンで作業を終えたので、キャッシュの読み込みが少なかったからです。
なぜ40倍ではなく16倍なのか
理由は2つあります。
一つ目は、Haikuのリクエストの多くが10万トークンを超えて、高い方の単価になったことです。Haikuは9回のリクエストのうち7回でプロンプトが10万トークンを超えていました。Claude Codeのシステムプロンプトとツールの説明だけでも2万トークンくらいあるので、作業が進んでファイルの内容などが会話に溜まると、すぐに10万トークンを超えてしまいます。
もし全部のリクエストが10万トークン以下で収まっていたら、Haikuの費用は約$0.069で、Opusは約29倍、Sonnetは約15倍になっていた計算です。
二つ目は、Haikuの方がトークンを多く使ったことです。出力はOpusの1.3倍、キャッシュ読み込みは1.4倍でした。
つまり、Claude Codeで普通に作業をさせると、Haikuの「40分の1」という安さはそのままでは得られません。今回の場合は「16分の1」でした。
以前の実験との違い
実は以前、別の課題でも同じように3つのモデルを比べてみたことがあります。その時はOpusの費用がHaikuの5倍くらいでした。今回の16倍とはかなり違います。
料金表から考えると、Haikuのリクエストが全部10万トークンを超えた場合、単価の差は8倍まで縮みます。5倍ということは、それに加えてHaikuの方がOpusよりトークンをかなり多く使ったということになります。
今回は逆に、Haikuの高い単価が費用の大きい部分にはあまりかかりませんでした。Haikuのリクエストごとのプロンプトの長さを見ると、次のようになっています。
| リクエスト | 1 | 2 | 3 | 4〜9 |
|---|---|---|---|---|
| プロンプトの長さ | 2.3万 | 9.3万 | 10.1万 | 10.2万〜10.9万 |
| やったこと | ページ全体を書く | Nodeで確かめる | 直す | 確かめては直す |
Haikuは最初のリクエストでページ全体を一気に書いていて、出力の大部分（思考を含めて約7万トークン）はここで出ています。この時のプロンプトはまだ2.3万トークンなので、安い方の単価です。10万トークンを超えたのは3回目以降で、その頃は少しずつ直すだけで出力は少なく、高い単価がかかったのは主にキャッシュ読み込みでした。キャッシュ読み込みは高い方の単価でも100万トークンあたり$0.05なので、全体の費用はあまり増えませんでした。
逆に、例えば調べ物をしながら長い文章を書くような課題では、検索結果や読んだページの内容が会話にどんどん溜まって、最後に文章を書く時にはプロンプトがとっくに10万トークンを超えています。そうなると、一番量の多い出力にも5倍の単価がかかります。さらに会話が長いほどリクエストの回数も増えるので、キャッシュ読み込みも増えます。こういう課題では、OpusとHaikuの差は8倍かそれ以下まで縮まると考えられます。
つまり、OpusとHaikuの費用の差は、課題の内容と進め方によって大きく変わります。「Haikuは何十分の1の費用」と単純に考えない方がいいです。
正解1語あたりの費用
最後に、費用を成果で割ってみました。
| Opus | Sonnet | Haiku | |
|---|---|---|---|
| 費用 | $2.01 | $1.03 | $0.12 |
| テスト語の完全正解 | 100語 | 54語 | 24語 |
| 正解1語あたりの費用 | $0.020 | $0.019 | $0.005 |
| 1点あたりの費用 | $0.020 | $0.015 | $0.003 |
こうして計算すると、一番「コスパ」がいいのはHaikuになります。ただし、これは間違いを人間が直す手間を全く考えていない数字です。この点については考察で書きます。
情報収集
Web検索を許可していたにもかかわらず、3つのモデルともWebSearchを一度も使いませんでした。
外の情報を見に行ったのはOpusだけで、英語版Wikipediaの「Lhasa Tibetan」のページを1回WebFetchで読みました。その時の指示は「声調の体系、前置字・上置字・下付字による発音の変化、後置字による母音の変化について抜き出せ」というもので、何を確かめるべきか分かった上で読みに行っています。
SonnetとHaikuは、自分の知識だけで書いています。Sonnetは1回で全部書いて、Bashで1回確かめただけで終わりました。
単語の変換例
テスト語の中から幾つか抜き出してみます。まずIPAです。○は完全に正解、△は一部が間違い、×は大きく間違っている、という意味です。
| 語 | 正解（Wiktionary） | Opus | Sonnet | Haiku |
|---|---|---|---|---|
| བོད（チベット） | pʰøː˩˧˨ | pʰøʔ˩˨ ○ | pø̀ × | pøʔ˩ △ |
| སྐད（言葉） | kɛː˥˨ | kɛʔ˥˥ ○ | kɛ́ △ | kʰaʔ˥ × |
| གཉིས（2） | ȵiː˥˥ | ɲiː˥˥ ○ | ɲí △ | ɲi˩ × |
| ལྔ（5） | ŋa˥˥ | ŋa˥˥ ○ | ŋá ○ | la˥ △ |
| དབུས（ウー） | ʔyː˥˨ | yː˥˥ ○ | ý △ | pu˩ × |
| ཡུལ（場所） | jyː˩˨ | jyː˩˨ ○ | jỳː ○ | jul˥ × |
| ལྷ（神） | ɬa˥˥ | ɬa˥˥ ○ | ɬá ○ | la˥ △ |
| མར（バター） | maː˩˨ | mar˩˨ ○ | màː ○ | maɻ˥ △ |
Opusの出力は、よく見るとWiktionaryと完全に同じではありません。それでも正解としたのは、前の「判定方法」で揃えた表記の流儀の違いだけだからです。
- བོད の pʰøʔ と pʰøː、སྐད の kɛʔ と kɛː：後置字 ད を声門閉鎖音 ʔ で表すか長音 ː で表すかの違い
- མར の mar と maː：後置字 ར を末子音 r で読むか長音で読むかの違い
- བོད の ˩˨ と ˩˧˨、སྐད の ˥˥ と ˥˨：声調の形の違い。高いか低いかは合っている
- གཉིས の ɲ と ȵ：同じ音を表す記号の違い
- དབུས の yː と ʔyː：語頭の ʔ は取り除いて比べる
一方、Sonnetの བོད（pø̀）は有気性（ʰがない）と後置字 ད の扱い（ʔ も ː もない）の2つが間違っているので×です。Haikuの སྐད（kʰaʔ）は、余計な有気音と母音（a ではなく ɛ）の2つが間違っています。
次はカタカナです。カタカナは正誤の判定には使っていませんが、各モデルのカタカナの付け方の違いがわかります。
| 語 | Opus | Sonnet | Haiku |
|---|---|---|---|
| བོད | ポェッ | ピョ | ポッ |
| སྐད | ケッ | ケ | カッ |
| གཉིས | ニー | ニ | ニ |
| ལྔ | ンガ | カ゚ | ラ |
| དབུས | ユー | ユ | プ |
| ཡུལ | ユー | ユー | ユル |
| ལྷ | ㇵラ | ラ゚ | ラ |
| མར | マル | マー | マル |
IPAとカタカナの対応
3つのモデルとも、カタカナは「IPAの子音×母音」の対応表から機械的に作っています。指示通り、慣用表記に引きずられたモデルはありませんでした。ただし、日本語にない音をどう書くかはモデルによってかなり違います。コードの対応表と実際の出力から整理すると、次のようになります。
| IPA | 例 | Opus | Sonnet | Haiku |
|---|---|---|---|---|
| 有気音 ʰ | ཁྱི cʰi | 書かない（キ） | ʰ をそのまま付ける（キʰ） | 書かない |
| ŋ（語頭） | ལྔ ŋa | ンガ | カ゚ | ンガ |
| ɬ | ལྷ ɬa | ㇵラ | ラ゚ | （ɬ を出さない） |
| c | ཁྱི cʰi | キ（キャ行） | キ（キャ行） | （c を出さない） |
| ʈ（反り舌音） | རྟ / ཁྲག ʈʰa | タ（t と同じ） | タ（t と同じ） | チャ（tɕ と同じ） |
| ø | ཆོས tɕʰøː | オ段＋ェ（チョェー） | ヨ段（チョ、ピョ） | オ段（ポ） |
| y | ཡུལ jyː、ཀུན kỹ | ユ段（ユー、キュン） | ユ段（ユー、キュン） | （y を出さない） |
| ɛ | སྨན mɛ̃ | エ段（メン） | エ段（メン） | （ɛ を出さない） |
| 長音 ː | ཟས sɛː | ー（セー） | ー | 書かない（長音を出さない） |
| 鼻母音 ̃ | ཀུན kỹ | ン（キュン） | ン（キュン） | ン（n として） |
| 末尾の ʔ | ཕྱག tɕʰaʔ | ッ | ッ | ッ |
| 末尾の p | ཞབས ɕap | プ（シャプ） | ㇷ゚（シェㇷ゚） | （p を出さない） |
| 末尾の k（語中） | ལག་པ lak.pa | ク（ラクパ） | （k を出さない） | （k を出さない） |
| 末尾の r | མར mar | ル（マル） | ー（マー。IPAで r を出さず長音にする） | ル |
| 区切り | 単語の間に「、」 | 音節の間に「・」 | 音節の間に「・」 | |
| 声調 | 書かない | 書かない | 書かない |
（「〜を出さない」は、IPAの段階でその音が出てこないので、カタカナにも現れないという意味です）
Opusは、日本語にない音を「ㇵラ」「ポェ」のように小さい仮名を組み合わせて表し（「ㇵ」はアイヌ語の表記のために作られた小さい仮名です）、ʰ はカタカナには書かないという方針で一貫しています。このことは、ページの説明にも書かれています。
Sonnetは、ŋ を「カ゚」、ɬ を「ラ゚」のように、半濁点を付けた仮名で表しています。「カ゚」は日本語の鼻濁音を表す時に使われる書き方なので、ŋ には合っています。この書き方自体は一貫しています。しかし、ʰ をカタカナにそのまま混ぜると読めなくなります。また、ø をヨ段で書くので、pø が「ピョ」になって［pjo］のように読めてしまいます。
Haikuは、カタカナの対応表自体は単純でわかりやすいです。しかし、IPAの段階で ø 以外の母音の変化や長音が出てこないので、カタカナも綴りを読んだような形（ユル、マン）になります。また、表にない子音の組み合わせ（ɹj、sl、pl など）は、後ろから1文字ずつ削って一致する行を探すので、ラッ（brgyad）のように一部の音がカタカナから消えてしまいます。
各モデルの成果物
3つのページは後でGistで公開しますが、まずここではスクリーンショットだけ載せます。
同じ入力「བོད། སྐད། དབུས། ལྷ། མར།」（チベット。言葉。ウー。神。バター。）を入れた時の画面です。上の変換例の表と同じ1音節の単語を、シェー（།）で区切って並べました。
Opus
一番上に12節の目次があり、その下に変換ツールがあります。例のボタンを押すと入力できるようになっていて、声調記号の表示も切り替えられます。「音節ごとの解析結果」を開くと、各音節の前置字や基字などの分析も見られます。
良かったところ：
- 基字を5つの類に分けて、声調と有気性をまとめて決める仕組みにしている。「有声字は単独なら有気音・低声調、前置字や上置字が付くと無気音・低声調」「鼻音などは単独なら低声調、前置字や上置字が付くと高声調」という規則を正しく実装している
- ཟླ→t、ལྷ→ɬ、དབ→wも正しく扱う。2音節以上の規則も、語中の ག→k と བ→w の2つだけは入れている（ཟླ་བ が正しく「タワ」になる）
- 規則の表は12節あり、全部実際の変換関数に例を通して生成している。後置字の表は、母音5つ×後置字15種を実際に変換した結果
- 実装していない現象（低声調の有声化や前鼻音化など）をページに明記している。参考資料を6つ挙げ、どれも実在するものだった
- チベット文字以外の文字はそのまま残し、ཧཱུྃ のような長音記号やアヌスヴァーラも処理する
悪かったところ：
- 変数名が
r、L、pのように短すぎるところがある - 出力で音節や単語を区切らないので、IPAとカタカナがやや読みにくい
- 目次と説明が上にあるので、結果を見るにはスクロールが必要
Sonnet
目次・見出し・🏠・表の全部をデータからv-forで作る構成になっていて、コードの作りはきれいです。変換できない音節があると警告を出す機能もあります。
しかし、声調の規則に根本的な間違いがあります。「前置字や上置字が付いた有声字は高声調」と実装していますが、実際は低声調のままです。そのためབཞི（4）、དགུ（9）、བརྒྱད（8）などが全部高声調になります。しかもこの誤った規則がルール表の説明にもそのまま書かれているので、ページを読んで勉強した人は間違った規則を覚えてしまいます。
他にも：
- 単独の有声字を無気音にしている（བོད → pø̀、正しくは pʰøː）
- 再後置字の ས でも母音を変化させている（གངས → kɛ̀ŋ、正しくは kʰaŋ）
- カタカナに「キʰ」「カʰー」のようにIPAの ʰ を混ぜている。また、ø をヨ段で書くので、pø が「ピョ」になる
- IPAの表示にもチベット文字のフォントを指定しているので、IPAの見た目が変になっている（画像の通り）
Haiku
コードは短くて読みやすく、音節ごとの結果を表で見られるところはいいです。規則表も、ちゃんと実際の変換関数を通して生成しています。
しかし、言語学的な間違いが多いです。
- ོ を常に ø にしている（ཞོ → ɕø、ལོ → lø）。本当は後置字 ད ན ལ ས が付いた時だけ ø になる。逆に、その後置字による母音の変化は実装していない（སྐད → kʰaʔ）
- 鼻音などの声調が逆。前置字があると低声調にしているが、実際は高声調になる
- 「前置字 ས は後ろの無気音を有気音にする」という存在しない規則を作っている（སྐད → kʰaʔ、སྟོང → tʰøŋ）
- 上置字の ར と ལ を扱っていない（ལྔ → la、རྟ → ɹa）
- ルール表の例に、དཡ や བཡ のような実在しない綴りを使っている
- CLAUDE.mdの「目次を付ける」「見出しに🏠を付ける」を守っていない
ただ、Haiku自身も最後の報告で「これは簡略化したルールで、専門書との照合はしていません」「正確な音声記述は Tournadre & Dorje の Manual of Standard Tibetan などで確認してください」と書いていました。自分の知識が足りないことには気づいていたようです。それなら調べればよかったのに、と思いますが。
考察
知識が必要な課題ではモデルの差が大きい
コードの品質や見た目の点数はほぼ同じなのに、変換の正確さでは大きな差が出ました。ページを作る力そのものには大きな差がなく、差を生んだのは主にチベット語の音韻についての知識です。
規則はどこから来たのか
チベット語の読み方の規則は、ネットで調べればある程度わかります。しかし、今回は3つのモデルとも検索をしませんでした。SonnetとHaikuは外の資料を一度も見ていないので、変換の規則は全部、元から持っている知識で書いたことになります。
モデルは学習の時に、チベット語の教科書や文法の解説、Wikipedia、Wiktionary などの文章を読んでいるはずです。なので「チベット語を学んだ」というより、「チベット文字の読み方を説明した文章を沢山読んだことがある」と言った方が近いと思います。単語と発音の例を沢山見て自分で規則を見つけたのではなく、どこかで説明されていた規則を思い出して書いた、ということです。ただ、どの資料から覚えたのかはモデル自身にもわかりません。
Opusだけは英語版Wikipediaの「Lhasa Tibetan」を読みました。しかし、ログでWebFetchの結果を見ると、このページには前置字・上置字・下付字がどう発音に影響するかは書かれていなくて、「このページには文字ごとの発音の対応は書いていない」という返事が返ってきていました。つまり、Opusの変換の中心である「基字を類に分けて、前置字や上置字で声調と有気性が変わる」という仕組みや、ཟླ→t、ལྷ→ɬ、དབ→w などの特別な綴りは、Wikipediaではなく、元から持っていた知識で書いたものです。
逆に、Wikipediaから取り入れたと思われる部分もあります。声調の形です。Wikipediaには「ཁམ（kham）は高平調、ཁམས（khams）は高降調」という例が載っていて、Opusはこれを「再後置字があれば下降調」という規則にしていました。その結果、ཁྲག や ཚིག のような閉鎖音で終わる音節も平らな ˥˥ になっています。1つの例だけを元に規則を作った形で、資料を読んでも、その一部だけを当てはめると不正確になることがあるという例です。
確かめても知識の間違いは見つからない
SonnetもHaikuも、書いた後にNodeで変換を実行して確かめています。特にHaikuは何度も確かめては直していました。しかし、それで見つかったのはプログラムのバグだけです。
例えばHaikuは、སྐད が saʔ になるバグに気づいて直しました。直した後の出力は kʰaʔ で、Haikuは「想定どおりになりました」と報告しています。しかし、正しい発音は kɛː（または kɛʔ）なので、有気音と母音の2か所がまだ間違っています。Haikuが「想定」していた規則そのものが間違っていたので、確かめても気づけなかったわけです。
プログラムをテストすれば「自分の思った通りに動くか」は確かめられますが、「自分の思ったことが正しいか」は確かめられません。それには外の資料と比べるしかないのですが、今回はどのモデルもそれをほとんどしませんでした。Haikuは最後の報告で「専門書との照合はしていません」と自分で書いていたので、知識が足りないことには気づいていたはずです。
2音節の規則は知らなかったのか
前に書いた通り、2音節以上の単語の規則（前鼻音化や声調の変化など）はどのモデルも本格的には扱っていませんでした。では、知識が2音節の規則まで届いていなかったのかというと、そうとも言い切れません。
Opusは語中の ག→k と བ→w を実装していて、前鼻音化などは「実装していない」とページに書いていました。知らなかったのではなく、知っていて範囲の外にした部分があるということです。また、2音節の規則は単語の区切りや個々の単語によって変わるので、辞書なしで規則だけで処理するのはもともと難しいです。モデルがそれを判断して範囲を絞った可能性もあります。
一方、SonnetとHaikuは1音節の規則の時点で間違いが多いので、2音節以前の問題です。結局、1音節の規則ではモデルの知識の差がそのまま点数に出ましたが、2音節の規則を扱わなかったのが知識の限界なのか、範囲を絞った判断なのかは、今回の実験ではわかりません。
小さいモデルに知識が必要な作業をさせるなら
今回の結果から考えると、HaikuやSonnetに専門知識が必要な作業をさせる場合は、規則を人間が与えるか、少なくとも「資料を調べて確かめてから書いて」と指示した方がいいと思います。今回の指示には「調べてから書いて」とは書いていませんでした。Web検索は使える状態でしたが、どのモデルも自分の知識で十分だと判断したようです。
間違いを自信満々に書く
一番怖いと思ったのは、SonnetとHaikuが間違った規則を、ルール表の説明に堂々と書いていることです。変換結果だけが間違っているなら「バグ」で済みますが、説明の方まで間違っていると、読んだ人が間違ったことを覚えてしまいます。
私はチベット文字が読めるから間違いに気づけますが、知らない分野でこういうページを作らせたら、間違いに気づかないかもしれません。
費用と性能
HaikuはOpusの約16分の1の費用でしたが、テスト語の完全正解はOpusの4分の1くらいしかありませんでした。正解1語あたりの費用ではHaikuが一番安いですが、残りの76語の間違いを直すのは人間（またはOpus）になるでしょう。
金額で見ると、Haikuの方は安いが、Haikuのページを直すには、まず間違いを見つけて、正しい規則を調べて、それを指示し直す必要があります。それは数十分から1時間はかかるかもしれません。その手間を考えると、今回のような専門知識が必要な課題では、最初からOpusを使った方が結局安くつくと思います。
また、Haikuの安さはプロンプトが短い時に一番活きます。Claude Codeのように会話がすぐ10万トークンを超える使い方では単価が5倍になるので、今回もOpusとの差は40倍から16倍に縮まりました。前に書いた通り、課題によっては5倍くらいまで縮むこともあります。Haikuは短いやり取りで済む簡単な作業に向いていると言えます。
Sonnetは費用がOpusの約半分で、ページの作りは悪くないので、規則を人間が細かく指示できるなら十分使えるかもしれません。ただ、費用が半分で完全正解も半分ほど（Opusの100語に対して54語）なので、費用あたりの成果はOpusとあまり変わりません。それなら、間違いを直す手間がない分、最初からOpusを使った方がいいと感じました。
この実験の限界
- 各モデル1回しか実行していないので、運による違いもあり得る
- 正解の基準にしたWiktionaryの発音も、一つの分析に過ぎない
- 採点者はOpusなので、Opusの作品を贔屓している可能性もゼロではない（採点者にはどれがどのモデルかを教えていないが）
まとめ
Claude CodeのOpus・Sonnet・Haikuの3つのモデルに、同じ指示で「チベット文字の読み方を表示するウェブページ」を作らせて比べました。
| Opus | Sonnet | Haiku | |
|---|---|---|---|
| 総合点 | 92 | 69.1 | 47.7 |
| テスト語100語の完全正解 | 100語 | 54語 | 24語 |
| 費用（Haikuを1とすると） | 16.2倍 | 8.3倍 | 1 |
| 所要時間 | 10.7分 | 8.8分 | 6.1分 |
わかったことをまとめます。
- Opusの圧勝：1音節の単語なら100語全部を正しく変換した。規則の説明も正確で、実装していない部分はそう明記していた
- 差を生んだのは知識：コードの品質や見た目には大きな差がなかった。差が出たのは、チベット語の発音の規則をどれだけ正しく知っているかだった
- 確かめても知識の間違いは直らない：SonnetとHaikuも出力を確かめていたが、元の規則が間違っているので気づけなかった。しかも間違った規則をルール表の説明に堂々と書いていた
- どのモデルも検索しなかった：Web検索が使えたのに、3つとも自分の知識だけで書いた（Opusは1回だけWikipediaを読んだ）
- 費用の差は料金表ほど大きくない：料金表ではOpusはHaikuの40倍だが、今回は16倍だった。Haikuは10万トークンを超えると単価が5倍になるので、課題によってはもっと差が縮まる
今回のように専門知識が必要な課題では、Haikuは安くても、間違いを見つけて直す手間を考えると結局高くつきます。しかも、その間違いに気づくには、作らせた人間の方に知識が必要です。自分がよく知らない分野ほど、Opusを使った方が安心だと思いました。
一方で、規則がはっきりしていて人間が指示できる作業や、知識よりもコードを書く量が多い作業なら、SonnetやHaikuでも十分かもしれません。今回の結果でも、ページの作りそのものには大きな差はありませんでした。
最初に書いた通り、この実験を始めたのは使用量の上限が気になってきたからでした。結論としては、「知識が要るかどうか」でモデルを使い分けるのがよさそうです。Haikuを使う時は、規則や資料をこちらから渡すか、少なくとも「調べてから書いて」と一言付け足そうと思います。