AI コード進行アプリを2年運用して分かったこと（GPT-4o から Claude へ、2024→2026）

Chord Eureka は、「切ない」「ジャジー」のようなキーワードからコード進行を作る Web アプリです。2024年12月に公開してから、もうすぐ2年になります。

この2年で、裏で使う AI のモデルは5回変わりました。

時期	モデル
2024年12月（公開）	GPT-4o
2026年2月	Claude Sonnet 4 → Sonnet 4.5
2026年6月	Sonnet 4.6
2026年7月	Sonnet 5
2026年10月	Sonnet 5.5

アプリの見た目や機能よりも、AI との付き合い方 のほうが大きく変わりました。git の履歴を見返しながら、何に困って、どう変えてきたかをまとめます。

2024年：GPT-4o でないとまともな進行にならなかった

作り始めた当時、安いモデルでは使えるコード進行が出ませんでした。コード数が合わない、存在しないコード名が混ざる、毎回同じような進行になる、といった具合です。実用になったのは GPT-4o でした。

ただ、GPT-4o は個人の無料アプリで使うには高いモデルです。モデルを下げられないなら、1回あたりの量を減らすしかありません。そこで次のようにしました。

• プロンプトを短くする：フロントからはキーワードと小節数だけを送り、サーバー側で「〇〇から連想されるコード進行を、〇小節で」という短い文に組み立てる
• 出力をコードだけにする：「コード進行をスペース区切りで出力。例: C Am7 F G7」と指示し、解説は書かせない。出力トークンが少ないほど安くなるからです

困ったのは、出力の形が ときどき崩れる ことでした。当時はこのアプリで出力の形式（スキーマ）を指定しておらず、返ってくるのはただの文字列です。前置きの文が付いたり、コード名の表記が揺れたりします。そのため、受け取った文字列をスペースで区切り、コードとして読めないものは読み飛ばしてから MIDI にしていました。

2026年2月：Claude に移行する

しばらくして、ChatGPT の出力の質が落ちたと感じる時期がありました。そこでアプリの名前を Chord Pilot から Chord Eureka に変えて作り直すときに、Claude（Sonnet）に切り替えました。それ以来、Claude を使い続けています。

API を差し替えるだけなら、変更は数十行で済みました。手間がかかったのは、その後の出力の調整です。

• プロンプトを別ファイルに切り出し、「シンプルな三和音から複雑なテンションまで、キーワードに合うものを選ぶ」「指定されたコード数を厳守」と書き足す
• temperature（出力のランダムさ）を 1.0 から 0.8 に下げ、コード数のずれや突飛な進行を減らす
• 出力の表記ゆれを直す処理を足す。♭ や ♯（全角の記号）を b と # に、Cm(maj7) を CmM7 に書き換えてから解析する

この時点でも、出力は「スペース区切りの文字列」のままでした。プロンプトで頼み、崩れたら後ろで直す、というやり方は GPT-4o のころと変わっていません。

2026年7月：temperature の廃止で、本番が約1週間落ちた

運用中で一番の失敗はこれです。

7月にモデルを Sonnet 5 に上げたとき、temperature の指定（0.8）を残したままにしていました。Sonnet 5 からは temperature を送れなくなっており、生成のリクエストがすべて失敗する状態 になりました。画面には「コード進行を生成できませんでした」と出るだけです。

姉妹アプリの Chordpernicus で同じ原因のエラーが見つかり、それでこちらも気づきました。モデルを上げてから直すまで、約1週間かかっています。

原因は2つあります。

1. モデル名だけを書き換えて、送っているパラメータを見直さなかった。temperature は「GPT-4o の出力を安定させるため」に入れた値で、そのまま引き継いでいました
2. 本番で生成を試していなかった。テストは解析のロジックだけで、AI の呼び出しが通るかどうかは確かめていませんでした

いまは、Claude 呼び出しをモックした API のテストを足し、temperature などのサンプリング系パラメータは送らないことをプロジェクトのルール（CLAUDE.md）に書いてあります。モデル更新のときは、そのモデルで使えるパラメータを先に確認する ようにしました。

2026年9月：構造化出力で「後ろで直す」を減らす

9月に、Claude 呼び出しを作り直しました。一番大きいのは 構造化出力（出力を JSON スキーマで縛る機能）を使ったことです。

8小節なら chord1 から chord8 までの8項目を持つスキーマを、リクエストごとに作って渡します。各項目には「1小節分のコードネーム1つ。Dm7G7 のように2つを連結しない」という説明を付けます。

こうすると、コード数がずれることがなくなります。2年間プロンプトで「厳守してください」と頼み続けていたことが、仕組みで保証されるようになりました。あわせて次も入れています。

• 応答が最後まで返ってこなかった場合（打ち切り・拒否）は、エラーとして扱う
• エラー文をコード進行として画面に出さない。以前は失敗時の文言をそのまま進行として返す作りでした
• 生成の思考量（effort）を medium にし、応答時間と品質のバランスを取る

一方で、コード名の中身 は縛れません。Em7b9 や Cm(maj9) のように、解析ライブラリ（Tonal.js）が読めない綴りは今も出ます。これは構成音から和音を組み立てる処理や、読める綴りに言い換える処理で鳴らせるようにしました。出力の形はスキーマで、中身の解釈はプログラムで、という分担です。

2026年10月：新しいモデルは測ってから入れる

10月に Sonnet 5.5 が出たとき、すぐには切り替えず、まず比べました。31個のキーワードでそれぞれ5回ずつ生成し、次の項目を数えています。

構成	キーワードの遵守率	重複なし	応答時間（中央値）	出力トークン（平均）	出力の料金／回
Sonnet 5（それまで）	96%	88%	7.2秒	483	$0.0048
Sonnet 5.5	97%	69%	3.5秒	254	$0.0025
Sonnet 5.5 ＋ 解釈の軸を指定（採用）	96%	91%	3.3秒	271	$0.0027

「遵守率」は、「ツーファイブ」「偽終止」のような理論用語のキーワードで、実際にその技法が入っていた割合です。「重複なし」は、同じキーワードの5回で別々の進行が出た割合です。

Sonnet 5.5 は、速さが約2倍、出力の料金が約半分 で、遵守率も変わりません。ここだけ見ればすぐ切り替えるところですが、同じキーワードで同じ進行を返しやすくなっていました。「もう一度生成」を押しても同じ進行が出るのでは、アイデア出しのアプリとして困ります。

以前なら temperature を上げて対処するところですが、もう使えません。そこで、ばらつきを出す方法を3つ試しました。

• リクエストごとに無意味な文字列を混ぜる
• 複数案を出させて1つを選ぶ
• 「今回は特にキーワードの『感情／雰囲気／色彩／物語性』を軸に解釈して」と、軸をランダムに1つ指定する

一番よかったのは3つ目で、遵守率と速さを保ったまま、重複なしが 88%→91% と以前より上がりました。これを採用して、Sonnet 5.5 に切り替えています。

比べる前に切り替えていたら、「速くなった」だけを見て、同じ進行が出やすくなったことには気づかなかったと思います。

2年やって分かったこと

モデルに合わせた工夫は、モデルが変わると負債になる

temperature 0.8 も、「コード数を厳守して」という念押しも、出力の表記を直す処理も、その時のモデルの弱点を補うための工夫でした。モデルが変わると、それらは 不要になるか、邪魔になる かのどちらかです。temperature は邪魔になったうえに、本番を止めました。

工夫を入れるときは、なぜ入れたのか（どのモデルの、どの問題に対してか）をコメントやドキュメントに残すようにしています。次にモデルを変えるとき、外してよいかを判断できるからです。

AI に任せるのは「発想」だけにする

このアプリで AI が担当しているのは、キーワードから進行を考えるところだけです。進行名の判定（カノン進行・王道進行など）、キーの推定、珍しさの採点は、すべてプログラムで計算しています。

分析まで AI に任せると、同じ進行でも聞くたびに答えが変わります。モデルを変えれば結果も変わります。答えが一つに決まるものはプログラムで計算する ようにしておくと、モデルを変えても影響は生成の部分だけで済みます。

モデルは切り替えられるようにして、自分の目で選ぶ

一番の教訓はこれです。

• モデル名と、そのモデルに送る設定を1か所にまとめる。移行も更新も、そこを変えるだけで済むようにする
• 比べるための測定スクリプトを持っておく。キーワードごとの遵守率・重複・速度・トークン数を数えておけば、新しいモデルが出たときにすぐ判断できる
• ベンチマークの評判ではなく、自分のアプリの出力で決める。「コード進行が毎回ばらけるか」は、このアプリでしか測れない

GPT-4o から Claude へ、Claude の中でも5世代と変えてきましたが、どのモデルが一番よいかは、自分のアプリの出力を見ないと分かりませんでした。

最近は出力がかなり安定していて、構造化出力のおかげで形が崩れることもなくなりました。2024年に、崩れた文字列を切り貼りしていたころと比べると、ずいぶん楽になっています。測定の方法（ローカルの Claude Code で数百件を生成して自動で採点したやり方）は、別の記事で書く予定です。