コーディングでの使いどころ

エンジニアでないあなたには「開発なんて自分に関係あるのか」と見え、エンジニアのあなたには「どの規模から割に合うのか」が気になる ── コーディングの回は、読者によって問いが分かれます。第5回は、その両方に答えます。

結論はどちらも同じ形をしています。規模で選ぶ、です。

前提として、コーディングは Fable 5 の性能が最もよく測られている分野です。実務のバグ修正に近いベンチマークである SWE-bench Pro の数字は第1回で見ました。この回では、その性能を「どこで使うと割に合うか」に絞って翻訳します。

小さな仕事は、安いモデルで十分

まず、Fable 5 が「いらない」場合をはっきりさせます。1ファイルで完結するスクリプト、数行の修正、エラーメッセージの意味を聞く ── こうした単発の仕事は Sonnet で十分です。第2回の基準どおり、1問1答で終わる仕事に価格差を払う理由はありません。

エンジニアの方なら、日常のコーディング支援の大半がここに入ります。まず Sonnet を既定にして、後述の「規模」に達したときだけ切り替える、が合理的な既定値です。

境目の感覚をひとつ挙げると、「修正の影響範囲を、頼む前に自分で言えるか」です。言えるなら、その仕事は小さく、安いモデルで足ります。影響範囲の調査自体をAIにやってほしい ── そう感じた時点で、それは複数ファイルの仕事であり、次の節の領域です。

Fable 5 の出番 ── 「マージできる品質」の領域

Fable 5 が割に合うのは、次のような仕事です。

• 複数ファイルにまたがる変更 ── 1箇所直すと他が壊れる、依存関係の把握が本体の仕事
• 大規模な移行・書き換え ── 古い言語やフレームワークからの載せ替え。導入事例では、5,000万行規模のコード移行で約2ヶ月の見積もりが大幅に短縮されたと報告されています
• テスト込みの品質が求められる開発 ── 動くだけでなく、検証されて、そのまま取り込める水準

とくに移行が現実的になった理由は、第3回と同じ言葉で言えます。長年動いてきたシステムのコードは、書いた人が去り、仕様書も残らず、読める人がいないという意味で「閉じた資産」 になっていました。触れないから、置き換えられない。AIがコードを読めるようになった瞬間、この閉じた資産が開きます。開いてしまえば、移行は「読めないものを書き直す賭け」ではなく、「読めたものを移す作業」に変わります。

3つ目を測るベンチマークに FrontierCode Diamond があります。「そのままマージできる品質のコードを出せるか」を問う難しいテストで、Fable 5 は 29.3%、ひとつ下の Opus 4.8 は 13.4% でした。まだ半分以上は人間の手が要る、とも読めますが、2倍以上の開きは実務では「任せられる範囲の広さ」の差になって表れます。

エンジニアの方に付け加えるなら、「マージできる品質」が上がっても、読んで責任を持つ仕事はなくなりません。変わるのは読み方です。1行ずつ書く時間が消え、設計方針を渡して、返ってきた変更をテストと差分で検証する時間が中心になる。第4回の3要素で言えば、設計方針が「制約」、テストが「完成条件」にあたります。移行のような大仕事も、いきなり全体を任せず、境界のはっきりした一区画で品質を確かめてから広げるのが安全です。

逆に、方針を渡さず、その場その場で書かせ続けるだけの使い方では、出てくるのは平均的なコードです(第1回で見た「平均への収束」です)。最上位モデルで平均を買うのは、いちばんの無駄遣いです。設計方針という「核」を渡すこと ── 価格差を回収する条件は、コーディングでも変わりません。

書かせる前に、探す ── 独自コードより、実績ある部品

費用に直結するスタイルの話を、もう一つだけ。何かを作らせるとき、すべてをゼロから独自のコードとして書かせる必要はありません。表の集計、PDFの読み取り、グラフの描画、ログインの仕組み ── 世の中で繰り返し必要とされてきた機能には、OSS(オープンソースソフトウェア。設計図が公開され、誰でも使えるソフトウェア)の実績ある部品 がすでにあります。

経済性の違いは、書いた後に表れます。AIに書かせた独自コードは、あなたしか持っていないコードです。直すのも、検証するのも、これからずっと自分の側の仕事になります。書かせた分だけ、抱える保守が増える のです。一方、実績ある部品は、世界中で使われ、テストされ、直され続けています。抱えるのは「部品の選び方」だけで済みます。

だから、頼み方に一文足すのが得です。「まず、使える実績ある部品を探してください。部品でできないうちの業務に固有の部分だけを、コードとして書いてください」── これだけで、書かせる量も、その後に直す量も減ります。第2回の基準で言えば、失敗とやり直しのコストを、頼む前に下げておく一文です。

エンジニアでない人へ ── 「業務ツールを作らせる」という選択肢

開発の依頼は、エンジニアの専有物ではなくなりました。毎月の手作業を、道具を作って消す ── そういう依頼が、日本語で成立します。第4回の3要素(目的・制約・完成条件)を使った実例です。

ポイントは完成条件に 動作確認 を含めていることです。コードが読めなくても、「正しく動くことの示し方」は指定できます。これが、コードの読めない人がコードを検収する方法です。

作って終わり、でもありません。翌月「費目の分類を1つ増やしたい」となったら、ツール一式を渡して同じように頼めばよい。自分専用の道具を持ち、必要になったら直させる ── 買ってきたソフトにはない身軽さです。毎月30分の手作業なら年間6時間。第2回の基準で言えば、ツール作成の依頼料は最初の1〜2ヶ月で回収できる計算です。

こうした関わり方をする人 ── 何を作るかを決め、AIに作らせ、結果を確かめて、責任を持つ人 ── を、ビルダー と呼びます。コードを書く力ではなく、業務の理解と、完成条件を言葉にする力が本体です。第1回の原則「方向性の決定は人間、実現はAI」を、開発の場面で担う役割 ── それがビルダーです。エンジニアであるかどうかは、もう入り口の条件ではありません。

Claude Code について ── 一言だけ

エンジニアの方は、Fable 5 をチャット画面ではなく Claude Code(ターミナルやエディタから使う開発ツール)経由で使うと、ファイルの読み書きやテスト実行まで含めて任せられます。本連載では深入りしませんが、「長い仕事を任せる」(第4回)の考え方がそのまま通用する、とだけ覚えておいてください。会社のIT基盤全体を、AIと一緒に開いて自前に置き直す実践は、別シリーズ「AIネイティブな仕事の作法 ── ソフトウェア開発編」が扱っています。

なお、コーディングの依頼では、安全分類器の働きで Fable 5 から Opus 4.8 に切り替わる場合があります。これは第7回で、まとめて説明します。

その仕事は、Fable 5 に頼む価値があるか?

第5回の答えです。1ファイルで終わる仕事なら Sonnet で十分。複数ファイル・移行・テスト込み ── 「規模」と「そのまま取り込める品質」が問われる開発 が、Fable 5 に頼む価値のある仕事です。そして書かせる前に、実績ある部品を探させること。エンジニアでなくても、完成条件に動作確認を書ければ道具は作らせられます ── それがビルダーの入り口です。

次回は、この「閉じた資産を開く」話を会社の道具立て全体に広げます ── Office スイートと業務システムを開いて、OSS につなぎ直す話です。

本記事の情報は2026年7月時点のものです。料金・提供状況は変わる可能性があるため、最新は Anthropic 公式情報をご確認ください。