プロンプトに「あなたは世界最高の専門家です」と書く手法がある。
最新のベンチマークで、モデルは同じでも正答率が7.8%から38.3%まで約5倍に向上した。
変えたのはプロンプトの文章ではない。推論プロセスを保持し、データを圧縮するシステム側の設定だ。
AIの性能を引き出すのはプロンプトの演出ではなく実行環境のハーネス設計だ。
Claude Codeで1人SaaS開発を行う視点から、プロンプトの幻想を捨てて結果を出すためのシステム設計を解説する。
SNS運用を自動化しませんか?
ThreadPostなら、投稿作成・画像生成・スケジュール管理までAIがサポート。
推論保持とコンパクションがもたらした数値
検証対象は、未知のルールを持つ2DパズルゲームをAIに解かせるARC-AGI-3ベンチマークだ。
標準的なテスト環境におけるGPT-5.6 Solのスコアは13.3%だった。
前世代のGPT-5.5はわずか0.4%だ。
原因はモデルではなく実行環境(ハーネス)の制約にある。
API設定で推論の保持とデータ圧縮(コンパクション)を有効化した。
過去の思考プロセスを破棄せずに次のステップへ持ち越し、コンテキストの膨大化を抑える構成へ変更した。
結果は明確だ。
パブリックタスクセットにおけるスコアは13.3%から38.3%へ引き上がった。
人間の平均スコアである48%に迫る数値だ。
出力トークン数は6分の1に激減した。
従来のテスト環境では突破できなかった最高難度のゲームで、全6ステージを完全クリアした。
しんたろー:
トークン数が6分の1でスコアが3倍近くになるのは別物だ。Claude Codeでコードを書く際、コンテキストが溜まりすぎて挙動が怪しくなる現象に遭遇する。システム側のコンパクションの影響を実感する。
この結果は、AIの性能を決定づける要因を示している。
多くの開発者は「あなたは世界最高の専門家です」といった専門家ロールに頼ってきた。
プロンプトで立場を指定しても内部の知識は増えない。
増えるのは権威的な言い回しや断定口調といった演出装置としての機能だ。
本質的な精度向上は、プロンプトの文章調整ではなく、推論プロセスを正しく保持するシステムレベルの設計から生まれる。
実際のシステム開発では、文章を生成する質疑応答モデルと、意味の近さを数値化して情報を探すEmbeddingモデルを切り分ける設計が標準化している。
タスクに応じた適切な環境と組み合わせを提供する設計が、AIの真価を引き出す。
※この記事は、Claude Codeで1人SaaS開発しているしんたろーが、海外AI最新情報を開発者目線で解説する「AI活用Tips」です。
プロンプトの「呪文」を捨て、システム設計に集中する理由
AIモデルの性能を左右する要素は、プロンプトの書き方からシステム環境の設計へシフトした。
推論の記憶を保持する設定と、不要な文脈を切り落とすコンパクションというデータ圧縮技術がある。
この2つの環境設定を有効化しただけで、難解なパズルゲームのベンチマークスコアが13.3%から38.3%へと跳ね上がった。
出力トークン数は6分の1まで削減されている。
モデルそのものを書き換えなくても、周囲の仕組みを整えるだけで性能が約3倍に向上する。
しんたろー:
Claude Codeを使い倒すと痛感する。プロンプトを「プロっぽく」書き直すより、過去の推論コンテキストをどう保持させるかが重要だ。APIの設定変更だけでスコアが13.3%から38.3%に変わるのを見ると、プロンプトの微修正に費やす時間が惜しくなる。
多くの開発者は「あなたは世界最高のエンジニアです」といった専門家ロールをプロンプトの冒頭に仕込んできた。
プロンプトに権威的な肩書を付与しても、モデル内部の知識や推論能力は増えない。
増えているのは、専門家らしい難解な語彙や断定的な言い回しといった外観の演出だけだ。
内容の正確性が上がったのではなく、読者が「賢そうな回答だ」と認識しやすくなったに過ぎない。
問題解決を目指す開発者が向き合うべきは、プロンプトの呪文ではなく、システムアーキテクチャの構築だ。
AIを活用したシステム設計は、明確に3つの層に分解できる。
* モデル単体の基本能力: 基礎的な言語理解やロジック構築力
* 文脈の制約定義: 入力条件や出力フォーマット、対象読者の指定
* ハーネスと実行パイプライン: 推論ステートの保持、データの圧縮、外部ツールの統合
性能を変えるのは、3つ目のハーネスと実行パイプラインの層だ。
複雑なタスクを処理する際、モデルが過去にどのような思考プロセスを経て結論に至ったかという推論ログを保持する仕組みが不可欠だ。
推論プロセスを破棄せずに次の入力へと引き継ぐことで、モデルは過去の失敗や仮説を前提とした思考を継続できる。
肥大化するコンテキストを自動で圧縮するパイプラインを組まなければ、APIコストと応答速度が破綻する。
コンテキストの長さを抑えつつ思考の文脈だけを維持する技術が、実運用におけるボトルネックを解消する。
単一のモデルにすべてを処理させる設計も見直されている。
検索や分類には計算コストの低いEmbeddingモデルを割り当て、高精度なテキスト生成には質疑応答モデルを配置する。
役割を明確に分担させる設計手法は、RAG(検索拡張生成)などの実務で標準化している。
僕が個人開発しているThreadPostの裏側でも、モデルに万能さを求めるのではなく、データの検索と文章の生成を別々の処理ラインとして切り離す設計を意識している。
プロンプトを調整して「それっぽい回答」を作らせる段階は終わった。
推論の記憶をどのように管理し、適切なモデルへとタスクを流すかというパイプラインの構築が、これからのAI開発者にとっての差別化要因だ。
ここまで読んだあなたに
今なら無料で全機能をお試しいただけます。設定後はAIが投稿案を毎日生成。確認して選ぶだけ。
プロンプト調整の手を止め、コンテキスト管理コードを書く理由
明日からの実務で変えるべき行動はシンプルだ。
プロンプトの冒頭に「あなたはプロの〜」と書き加える時間をゼロにして、API呼び出しの前後処理を実装する時間に回す。
AIの出力精度が上がらないときにプロンプトの文言ばかりをいじってきた。
本質的な精度の差を生んでいたのはプロンプトの単語選びではない。
過去の思考プロセスをどう保持し、トークンをどう圧縮してモデルに渡すかという実行環境(ハーネス)の設計だった。
実務で意識すべきポイントは3つの設計変更だ。
- プロンプトの演出を削り、条件と制約の明確化に特化する
「世界最高のエンジニアとして回答して」といったロール設定は、文体を賢そうに見せる効果しかない。
実務で必要なのは、出力フォーマットの指定、明確な境界条件、失敗時の挙動といった厳密な制約定義だ。
演出のためのプロンプト調整に時間をかけるのではなく、入出力の型を定義することに集中する。
- 推論プロセスの状態管理をシステム側に組み込む
複雑なタスクを解かせる際、一回のAPI呼び出しで完結させず、中間の思考ログを保持して次のリクエストへ引き継ぐ構造を作る。
会話が長くなった際に、トークン消費を抑えるためにコンテキストを自動で要約・圧縮するコンパクション処理をパイプラインに挟むことが不可欠だ。
しんたろー:
プロンプトに呪文を付け足す作業は正解がないため時間を吸われる。プロンプトをコネコネする時間を削り、APIレスポンスの中間状態を保持して次の入力に繋ぐような地味な処理を書く方に時間を投資する。
- 単一のモデルにすべてを任せず、タスクごとにモデルを使い分ける
ユーザーの入力から関連情報を探す処理には計算コストの低いEmbeddingモデルを使い、得られた情報をもとに回答を組み立てる処理には高精度な質疑応答モデルを使う。
探す係と答える係をシステム側で分離することで、処理速度とコストを最適化できる。
Claude Codeを使っていると、AIが自律的にコードを読み、修正していく凄さを体感する。
その裏で成果を支えているのは「過去の試行錯誤をどう保持し、どのタイミングで圧縮するか」というシステム側のロジックだ。
AIモデル単体の「素の賢さ」や魔法のプロンプトに期待する時代は終わった。
これからの開発者に求められるのは、AIが本来の能力を発揮できるような推論パイプラインをコードで構築する力だ。
よくある質問
「専門家ロール」を指定しても、AIの回答精度は上がらないのですか?
出力のトーンやフォーマットを整える演出としては機能するが、モデルの推論能力そのものが上がるわけではない。
精度を高めたいなら、「あなたは世界最高のエンジニアです」と書く時間でタスクの明確な分解や制約条件の定義を行う。
AIに深い思考をさせたい場合は、思考プロセスを順を追って出力させるChain of Thoughtの導入や、文脈の整理にリソースを割く方が確実だ。
推論の保持(Retained Reasoning)は、具体的にどのようなコード構造で実現するのですか?
モデルが思考した中間プロセスを捨てずに、次のループのプロンプトへ引き継ぐパイプラインを構築する。
API呼び出し時に過去の思考ログをコンテキストに保持し続けるか、生成された思考ステップを構造化データとして保存して再参照させる手法が一般的だ。
ゼロから思考をやり直させない仕組みを作ることで、複雑なマルチステップのタスクでもロジックの破綻を防ぐことができる。
「探す係」と「答える係」でモデルを分離する設計は、個人開発のプロダクトでも効果がありますか?
コストと応答速度の面で大きなメリットがある。
全データを高価な生成モデルに読み込ませると、API費用が膨らみレスポンスも遅くなる。
計算コストの低いEmbeddingモデルで関連情報だけを抽出し、その結果だけを生成モデルに渡す設計にすることで、開発コストを削減しながら高速な応答を実現できる。
まとめ
AIの性能を「呪文」で誤魔化す時代は終わった。
勝負を分けるのは、プロンプトの工夫ではなく、推論プロセスをどう保持してシステムを組むかだ。
僕もClaude Codeで開発しながら、アーキテクチャ設計こそがプロダクトの精度を決めると日々感じている。
推論を保持し、システムで解決するエンジニアリングの真髄を試していこう。

この記事が参考になったら、ThreadPostを試してみませんか?
投稿作成・画像生成・スケジュール管理まで、AIがサポートします。
ThreadPostをもっと知る