なぜClaude Code実践者はプロンプトより自社仕様書を書くのか。Composer 2が変えるAI開発の常識

汎用タスクの終焉と新たな戦場の幕開け

出た。またAI開発の前提が根底から覆った。

コーディング特化AIの入力コストが$0.50/Mまで暴落した。

同時に、クラウド上でAIが勝手にCIのエラーを修正し、プルリクエストのレビューに対応する機能まで標準搭載されようとしている。

汎用的なコーディングタスクやバグ修正は、完全にコモディティ化した。

AIに「どうコードを書かせるか」を悩む時間は終わった。

僕ら開発者が今すぐ向き合うのは、AIが参照するための「劣化しない自社固有のコンテキスト」をいかに構築するかだ。

激変するAIコーディング環境の全貌

今週は開発者の実務に直結する強烈なアップデートと研究発表が連続している。

大きく3つの事実が、今後のAI開発の方向性を決定づけている。

第一に、コーディング特化AIの最新モデルの登場だ。

ベースモデルに初めて継続事前学習を施し、その上で強化学習を20倍にスケールさせるという2段階のアプローチが採用された。

特筆すべきは、モデル自身が長大なコンテキストを要約する「自己要約機能」が、強化学習のトレーニングループに直接組み込まれたことだ。

要約の質が高くタスクが成功すれば報酬が与えられ、失敗すればペナルティが課される。

結果として、100,000トークンを超える巨大な文脈を自律的に約1,000トークンに圧縮しながら、170ターンもかけて複雑なコンパイルタスクを完遂したというデータが報告されている。

第二に、破壊的な価格設定だ。

最新モデルには2つのバリエーションが用意された。

高速モデルは入力$1.50/M。

そして標準モデルは入力$0.50/Mという、既存のハイエンドモデルの約10分の1のコストを叩き出した。

それにもかかわらず、ターミナル環境でのエージェント評価ベンチマークでは、既存のトップモデルを約29%上回るスコアを記録している。

圧倒的な低コストと高性能の両立だ。

第三に、クラウドベースでの自律型コード修正機能の台頭と、それに伴う「コンテキスト管理」の新たなアプローチだ。

開発者が離席している間に、AIがCIの失敗を検知してコードを直し、レビュアーのコメントに返信して修正コミットまで積む機能が現実のものとなった。

これと並行して、長文脈の対話でAIが過去の指示を忘れる「コンテキストの腐敗」を防ぐための研究も進んでいる。

AI自身に要約のタイミングを任せるのではなく、トークン数の閾値で機械的に圧縮を行う決定論的制御の概念だ。

生データを不変のまま保存し、要約を深さ0から深さ2までの階層構造で管理することで、情報の劣化を防ぐという。

※この記事は、Claude Codeで1人SaaS開発しているしんたろーが、海外AI最新情報を開発者目線で解説する「AI活用Tips」です。

開発者目線の解説：3つの評価層と残された「堀」

これらの一連の動向を見て、AIによるコード評価や自動生成は、今まさに明確な3つの層に分断されつつある。

この構造を理解しないと、僕らは無駄な努力に時間を溶かすことになる。

層1は「実装品質」の評価だ。

コードにバグがないか。

テストが通るか。

型チェックに違反していないか。

Lintのルールを守っているか。

クラウドでの自動修正機能の登場は、この層が完全にAIプロバイダーの標準機能に吸収されたことを意味する。

自前でCI連携のレビューボットを作ったり、構文エラーを直すためのプロンプトを工夫したりする意味は完全に消滅した。

ここは資本力のあるプラットフォーマーが圧倒的な計算リソースで制圧する領域だ。

層2は「アーキテクチャ」の評価だ。

特定のフレームワークのベストプラクティスに従っているか。

一般的なデザインパターンを適用しているか。

これも各社が蓄積しているベストプラクティスデータベースが充実するにつれて、急速に均一化が進んでいる。

「ここではこの関数を使うべき」「このデータフェッチの手法は古い」といった判断は、公式ドキュメントを読み込んだAIの最も得意とする分野だ。

ここでも独自性を発揮する余地は少ない。

そして残されたのが層3、「ドメイン知識」の評価だ。

自社特有のビジネスルール。

過去のインシデントから得た血の通った教訓。

なぜその技術を選び、なぜ別の技術を捨てたのかという意思決定の歴史。

業界特有の規制や、顧客固有の暗黙の要件。

これらだけは、AIがインターネットの海から勝手に学習することができない。

開発者が明文化し、構造化してAIに与えない限り、絶対に存在しない情報だ。

ここだけが、AI時代における開発チームの唯一の競争力、つまりmoat（堀）となる。

しんたろー：
汎用的なレビューボット作ろうとしてた過去の自分を全力で止めたい。
公式が全部乗せの機能をクラウドで出してくるんだから、層1で戦うのはマジで不毛だ。
過去の自分に「プラットフォームの垂直統合を見くびるな」と言いたいが、どうせ聞かなかっただろうな。

さらに興味深いのは、AIの進化の方向性に生じている明確な対立構造だ。

最新のコーディングモデルは、強化学習のループ内に「自己要約」を組み込んだ。

AI自身が「何を記憶に残すべきか」を判断し、長大なコンテキストを自律的に圧縮する。

これは短期的なタスク解決や、単発の複雑なバグ修正には大きな効果を発揮する。

モデル自身の能力に依存する、いわば内製化されたコンテキスト管理だ。

しかし、数ヶ月・数年単位で続く実際のプロダクト開発ではどうだろうか。

AI任せの要約には常に「情報の欠落」という致命的なリスクが伴う。

AIの確率的な判断次第で、重要なビジネス要件や過去の障害対応の経緯が、要約の過程で抜け落ちる。

長期間の対話になればなるほど、この「コンテキストの腐敗」は確実に進行する。

だからこそ、外部からの決定論的なコンテキスト管理が必要になる。

AIの自己要約能力にタダ乗りするだけでなく、情報を構造化し、劣化しない形でAIに渡し続ける仕組みだ。

生データを不変のストアに保存し、トークン数の閾値という機械的なルールで圧縮を制御する。

モデルの気分に依存しない、堅牢な情報アーキテクチャの構築だ。

プロバイダーは全ユーザーに共通する水平展開しかできない。

特定企業に固有の垂直展開は、構造的に開発者にしかできない。

実務への影響：コンテキストエンジニアリングの実践

では、明日から開発スタイルはどう変わるか。

結論は極めてシンプルだ。

コードを書く時間や、プロンプトの語尾を微調整する時間を極限まで削る。

その代わりに「自社固有の仕様書」を書く時間を圧倒的に増やす。

ただし、それは人間が読むためのきれいなドキュメントではない。

AIが高速かつ正確に読み取るための、構造化されたコンテキストだ。

この作業を「コンテキストエンジニアリング」と呼ぶ。

具体的には、プロジェクトのルートディレクトリに専用のフォルダを構築する。

そこに、自社のドメイン知識を徹底的に叩き込み、細分化して保存する。

やるべきアクションは以下の5つに集約される。

* ビジネス用語の厳密な定義: 業界特有の専門用語、社内スラング、DBのテーブル名とビジネス概念の紐付けをマークダウンでリスト化する。AIに「売上」という言葉の自社での正確な定義を教え込む。

* 設計決定の記録（ADR）: なぜその技術を選んだのか。より重要なのは「なぜあの技術を採用しなかったのか」という見送りの理由だ。これを残さないと、AIは毎回同じ「一般的なベストプラクティス」を提案してくる。

* インシデントの解剖記録: 過去に起きた致命的なバグの原因と、具体的な再発防止策をまとめる。これを読ませることで、AIは「自社の弱点を知り尽くしたシニアエンジニア」としてコードをレビューするようになる。

* セキュリティと権限の絶対ルール: 必須のロールチェック、テナント分離のロジック、データ保護の社内基準を明記する。層1のLintでは防げない、ビジネスロジックレベルの脆弱性をAIに監視させる。

* プロジェクト固有のコーディング規約: 汎用的なフォーマットルールはAIに任せる。ここに書くのは「自社のこのAPIを叩く時は必ずこのラッパーを通す」といった、固有の制約だけだ。

これらを巨大な1つのファイルにまとめるのは最悪の手だ。

AIが必要な時に必要な情報だけをピンポイントで引き出せるように、ファイル単位で細かく分割し、階層化して整理する。

ディレクトリ構造自体が、AIにとってのインデックスになる。

しんたろー：
頭の中にある「暗黙の了解」を全部言語化してファイルに落とすの、正直めっちゃ面倒くさい。
でも一回これを整備してClaude Codeに読ませると、出力の精度がバグったように跳ね上がる。
仕様書を書きながら「俺、今コード書いてないな」と思う瞬間が一番生産的だったりする。

AIにコードを修正させる時や、新しい機能を実装させる時、これらのファイル群を常にコンテキストとして読み込ませる。

汎用的なバグ修正能力（層1・層2）と、自社固有のドメイン知識（層3）がここで初めて融合する。

入力コストの暴落が、この運用を完全に後押ししている。

$0.50/Mという価格破壊により、数十万トークンの仕様書を毎回AIに読ませても、コストは文字通り数十円の世界だ。

トークン数をケチる時代は終わった。

ありったけのコンテキストを構造化してAIにぶつける。

これが、低コスト・超高性能化する最新モデルの最も正しい使い方だ。

自動修正機能がCIに完全に組み込まれ、AIが自律的にプルリクエストを処理する未来はすでに始まっている。

その時、あなたのプロジェクトには「AIが参照すべき独自のルール」が存在しているだろうか。

何もない空っぽの状態でAIにレビューさせても、教科書通りの一般的な指摘しか返ってこない。

これからの開発者の価値は、タイピングの速さでも、プロンプトの巧みさでもない。

積み上げたドメイン知識の量と、それをAIに劣化させずに伝えるコンテキストエンジニアリングの質に完全に依存する。

AI活用Tips FAQ

Q1: 最新のコーディングモデルにある2つのバリエーションは、実務でどう使い分けるべきですか？

対話的なコーディングや、即時性が求められるターミナルでの作業には、応答速度が約2倍速い高速モデルが絶対的に適しています。思考のテンポを崩さないことが最優先です。一方で、時間的余裕のある深夜のバッチ処理、大規模なリポジトリ全体のリファクタリング、あるいはCIに組み込んで自動レビューさせるような場面では、入力$0.50/Mと極限まで安価な標準モデルを使用するのが推奨されます。用途に応じたコスト最適化が鍵です。

Q2: コンテキストエンジニアリングとは、具体的に日々の実務で何をすればいいですか？

プロジェクト内に専用のディレクトリを作成し、自社特有の情報をマークダウン形式で明文化して蓄積し続けることです。具体的には、ビジネスルールの定義、過去の障害報告書（ポストモーテム）、設計の決定理由（ADR）、ドメイン固有の用語集などです。これらを細かくファイル分割して保存することで、AIが汎用的なネットの知識ではなく、あなたのプロジェクトに完全に即した精度の高いコード生成やレビューを行えるようになります。

Q3: 長い対話でAIが過去の指示や前提条件を忘れてしまうのを防ぐにはどうすればいいですか？

モデル自身のコンテキストウィンドウの広さや自己要約能力に依存するだけでは不十分です。重要な決定事項やビジネス要件は、チャットの履歴に流すのではなく、都度別ファイル（ルールファイルやADR）に切り出して保存し、AIに常にその外部ファイルを参照させる運用を徹底してください。将来的には、情報を階層化して劣化させずに保持する決定論的なコンテキスト管理ツールの導入も視野に入ります。

独自の文脈こそが最大の武器になる

汎用的なコーディング能力とバグ修正は、もはや電気や水道と同じインフラになった。

時間を投資するのは、自社固有の文脈を言語化し、AIにインストールし続けることだ。

コンテキストエンジニアリングを制する者が、これからのAI開発の主導権を握る。

しんたろー：
Claude Codeで毎日開発してると、コンテキストの渡し方一つでAIの挙動が別物になるのを痛感する。
プロンプトの言い回しをこねくり回す暇があったら、仕様書とADRを1行でも多く書いた方が絶対にいい。
「プロンプトエンジニアリング」って言葉、3年後には死語になってると思う。

👉 ThreadPostでSNS運用を自動化する