同じフロンティアAIモデルを同じツールで使っても、得られる結果は人によって大きく変わります。優れたエンジニアは同じツールから平均的な利用者の10倍から100倍の価値を引き出すこともあり、その差は野心、つまりモデルにどれだけ大きな仕事を任せるかから生まれるようです。10月13日に公開されたエッセイで、AnthropicでClaudeを担当するエンジニアリングリードは、その野心を速度、高度、深さ、幅という4つの軸に分けました。本記事では後半の3つを取り上げ、Claude Codeをはじめとするエージェント、つまりツールを使って複数の手順からなる作業を自律的にこなすAIシステムにどう応用するかを解説します。
コード生成だけでは差がつかない
Anthropic自身の採用記録を見ると、期待がどれほど速く変わったかがわかります。2024年には、Anthropicの技術職の採用担当者による評価メモのうち、候補者のAIツール活用実績に触れたものは約5%、非技術職では約7%でした。2026年には、その割合がそれぞれおよそ3倍と4倍になっています。Claudeに単独の機能を書かせることはもはや当たり前であり、基本的なコード生成が安くなるなかで、そこで止まるエンジニアは取り残されるおそれがあります。
4つの軸は次のとおりです。
| 軸 | 意味 | 例 |
|---|---|---|
| 速度 | 手作業でしていた仕事をClaudeで速く終える | 最も基本的な段階 |
| 高度 | 指示を作業から成果へ、さらに目標へと引き上げる | クラッシュを1件直すことから、アプリをクラッシュのない状態に保つことへ |
| 深さ | 1つの作業をその分野の一流の専門家のやり方でこなす | 推測ではなくプロファイリング |
| 幅 | 別の分野がすでに同じ問題を解いていることに気づく | エラーメッセージをサポート業務として捉える |
速度は入り口にすぎないため、本記事では残りの3つを扱います。
高度：手順ではなく成果を任せる
高度を上げるとは、指示をはしごのように上へ移していくことです。手順的な作業から望む成果へ、さらにその成果の背後にある目標へと進みます。手順を一つひとつ指定するプロンプト、つまりモデルに与える指示は、結果をあなた自身の技術知識の範囲に縛ります。目標を与えれば、モデルはより良い設計や解決策へと自ら推論を進める余地を得ます。
データベースの性能問題を例にすると、3つの水準は次のようになります。
| 水準 | Claudeへの指示 |
|---|---|
| 作業 | 注文クエリにインデックスを追加して |
| 成果 | 実際のユーザーに対して、すべてのページが200ミリ秒以内に表示されるようにして |
| 目標の先の目標 | ユーザーが仕事を早く終えられるようにして。待たされたり、あちこちクリックしたりしている箇所を見つけて、なくして |
成果レベルのプロンプトなら、Claudeはまず、インデックス、つまりデータベースの読み取りを速くする検索用の構造が、そもそも正しい解決策かどうかを判断できます。前述のAnthropicのエンジニアリングリードも同じ道をたどりました。約20カ月前にはClaudeに個々のクラッシュを直すよう頼んでいましたが、段階的に水準を上げ、最終的な指示は「アプリをクラッシュのない状態に保つ」だけになりました。この高度で働くには、クラッシュの記録と、Windows、macOS、Linuxでバグを再現できる環境が必要です。
まずエージェントにツールを渡す
クラッシュゼロのような目標を設定する前に、成功するためにどんなツール、認証情報、環境へのアクセスが必要かをエージェントに直接尋ねます。実践的な構成の一つが、クラッシュゼロの目標専用のSlackチャンネルです。エージェントはそこで目標を受け取り、必要な設定と権限を尋ねられ、12時間ごとに自律的に動きます。リポジトリと依存関係を調べ、サンドボックスでの実験用に支出上限を設けた別のAWSアカウントのようなリソースを求めることもあります。チャンネルは双方向で使えるようにし、新しい権限が必要になったときにエージェントが人にメンションできるようにしておきます。
エージェントが足りないツールを自分から求めることはめったにないため、準備は前もって済ませておく必要があります。ツールを先に整えた環境には、次のものが含まれます。
- エラーログと分析イベントへのアクセス
- Stripeのような業務システムへの読み取り専用アクセス
- テスト用デバイスと有効なユーザーログイン
- サンドボックス用のテストアカウントを作成する権限
インフラを作成する広い権限をエージェントに与える前に、サンドボックスには明確なコスト上限と安全上の境界を設けてください。
人が仲介役をやめる
手作業の運用では、人がサポートチケットを1件ずつ読み、Claude Code向けのプロンプトに書き直し、結果をテストし、何度もやり取りを繰り返します。その人はメッセージを中継しているだけで、その中継がボトルネックになります。
代わりになるのが、自律的なトリアージのループです。Model Context Protocolを使ってAIモデルを外部のツールやデータにつなぐMCPサーバーを通じて、サポートの受信箱をエージェントに接続し、Sentryのリアルタイムのエラーログも加えます。エージェントは届いた報告をそれぞれ対応するクラッシュの記録と照らし合わせ、仮想環境でバグの再現を試みます。再現できなければ、どのブラウザーを使ったか、ショートカットをどう設定しているかなどをユーザーに直接尋ねます。ある事例では、あるアプリの顧客がショートカットの問題について日本語で問い合わせてきました。エージェントはmacOSのマシンを借りて問題の再現を試み、「キー」がキーボードショートカットを指すのかAPIキーを指すのかを確かめる追加の質問を作成しました。
▲ 顧客が報告したバグを再現するエージェント
ダッシュボードの代わりに、問いを立てるエージェントを
分析サービスをMCPサーバー経由でエージェントにつなげば、複数のデータを組み合わせたダッシュボードを必要なときに簡単に作れます。しかし、ダッシュボードの役割はビジネス上の問いに答えることです。それなら目標そのものをエージェントに渡しましょう。
顧客にもっと満足してもらい、売上も伸ばしたい。そのために毎週いちばん重要な10個の問いを考えて、答えを出し、結果をグラフ付きのレポートにまとめて。
この指示を受けたエージェントは、初回訪問から購入までの時間の中央値が約4分であることを突き止めました。衝動買いの表れです。また、プロモーション動画を最後まで見た人ほど購入しにくいこともわかりました。動画を最後まで見る人の割合が高いほど、売上は低くなっていたのです。
指標を任せ、システムに狙いを定める
次の段階は、何かが壊れるたびに手動でエージェントを動かすのをやめることです。代わりに、売上、登録数、返金、解約、アプリケーションのエラーといったビジネスの計器をエージェントが受け持ちます。エージェントはそれらを毎日または数日おきに確認し、何かおかしいと見えたときだけ人に知らせます。
最も高い高度にあるのがソフトウェアファクトリー、つまり個々の機能ではなく、ソフトウェアを生み出すシステムそのものです。システムに向けられたエージェントは、常に監督されなくても複数のアプリケーションにまたがって機能を作り、バグを直し、開発のワークフローを回します。根本にあるパターンを直せば、その修正はそこに依存するすべてのアプリや画面に広がります。あるGitHubリポジトリでは、ボットのエージェントが課題を見つけ、プルリクエスト（コード変更の提案）を出し、検証を実行し、修正を昼夜を問わずマージしています。定型的な作業やバグはエージェントに任せられますが、非常に大きく重要な機能には、今も人が直接関わって監督する必要があるようです。
深さ：専門家の語彙ではなく、専門家の手法を
深さとは、1つの作業をその分野で最も優れた専門家の水準でこなすことです。モデルに「プロのようにやって」と言っても、たいていは話し方が変わるだけです。p値やコホート別の継続率に触れるようにはなっても、手法は変わりません。本当の深さは、手早く作ったMarkdownの表や当て推量ではなく、実際のデータベース、統計モデリング、回帰分析のツールを使わせることで生まれます。
読み込みに10秒かかるアプリを例にとります。単に速くしてほしいと頼むと、必要になるまで読み込みを遅らせる遅延読み込みや、ReactのuseMemoといった一般的な助言が返ってきがちです。そうではなく、パフォーマンスエンジニアと同じように、プログラムの各部分がどこで時間を使っているかを示すタイミングの記録であるプロファイラーのトレースから始めるよう、Claudeに求めます。するとClaudeはルーティング、認証、レンダリング、データベースのクエリを一つずつ調べ、時間のかかるデータベースのクエリのような本当のボトルネックを突き止めます。
目標の置き方も重要です。5秒で許容できる場面でも200ミリ秒を求めるような、無理に見える目標を掲げ、エージェントが最初に不可能だと答えても押し続けます。そうした圧力が、モデルを表面的な手直しの先にある構造的な最適化へと進ませることがあります。
エッセイでは、普段のプロンプトを厳密な仕様に書き直すためのプロンプトである、4段階のメタプロンプトも紹介されています。モデルには次のことを求めます。
- 一流の専門家なら頼りにするのに、自分のプロンプトから抜けているものを指摘する
- 作業の土台にする生の資料を特定する
- 専門家が使うツールを明示する
- 結果を確かめられる客観的な検証方法を定める
幅：名詞を動詞に言い換える
幅とは、目の前の問題をまったく別の職業がすでに解決していることに気づく力です。専門家はこうしたつながりを見落としがちなので、作業の中心にある名詞を、人が何をなぜする必要があるのかを表す動詞句に書き換えることが勧められています。「プレゼン資料」は「忙しい人たちに因果関係のストーリーを納得させ、不確実な状況でも30分以内に判断できるようにする」になります。こう捉え直すと、記者、編集者、アナリストの手法が使えるようになります。どの分野が当てはまるかわからないときは、Claudeにその問題について自分へインタビューさせ、同じ構造の問題を抱える職業を挙げてもらいます。
エラーメッセージをサポート業務として捉える
HTTP 500（内部サーバーエラー）のページに当てはめると、「エラーメッセージ」という名詞は「困っている人が誰にも連絡せず、自力で問題を解決できるよう手助けする」になります。これはサポート担当者の仕事です。Claudeは6カ月分のサポートチケットを分析し、エラーを頻度ごとにまとめました。ログイン、アップロード、支払い、エクスポートの4種類のエラーが、全チケットの約61%を占めていました。サイズが原因でアップロードに失敗した場合は、「後でもう一度お試しください」という一般的な通知の代わりに、6GBのファイルがプランの上限である5GBを超えていることをはっきり伝え、その場でファイルを圧縮するかプランをアップグレードする選択肢を示します。
機能要望を症状として読む
ユーザーがCSVエクスポートのボタンを繰り返し求めてくると、ボタンを実装してチケットを完了にするのが普通の対応です。一方で優れた医師は、抗生物質を求める患者に別の対応をとり、処方箋を書く前に症状を調べます。診断する医師として振る舞うよう指示されたClaudeは、43件のCSVエクスポートの要望を検討しました。
| 根本にあるニーズ | 要望数 |
|---|---|
| 毎週月曜日のGoogle Sheets自動同期 | 29 |
| ユーザーが手作業で会計士にメール送信していた明細書 | 8 |
| 単独のCSVダウンロードボタン | 6 |
この診断からは、基本的なエクスポートボタンに加えて、Google Sheetsの自動同期や月次明細書の定期送付といった、より効果の大きい機能が見えてきます。現在のフロンティアモデルは、初期状態では幅のある発想に手を伸ばさないため、利用者がまだ明示的にプロンプトで促す必要があります。将来のモデルは自然にそうできるようになるかもしれません。
▲ 症状として読み解く機能要望
期待がモデルに追いついていない
エッセイは、大きな成果を達成できるという信念である自己効力感の話で締めくくられます。モデルの能力は2週間ごとに段階的に上がっているように見える一方、人の期待は変わらないままで、その差が人為的な天井になっています。誰かが難しいことを成し遂げるのを見ると、その天井はリセットされます。1954年5月にロジャー・バニスターが1マイル4分の壁を破ると、わずか46日後に別のランナーも同じことを成し遂げました。サバスチャン・サウェはロンドンでマラソン2時間の壁を破りました。数学者のジョージ・ダンツィークは、カリフォルニア大学バークレー校の授業に遅刻し、黒板にあった有名な未解決の統計学の問題2つを宿題だと思い込み、両方とも解きました。他の人がエージェントで何をしているかを見ることが、自分の期待を引き上げる最も簡単な方法かもしれません。
次のプロンプトで変えること
同じモデルからより多くを引き出すとは、より高く狙い、より深く掘り下げ、より広く見渡すことです。実践のステップは次のとおりです。
- 次にClaude Codeに出す指示を、作業、成果、目標の先の目標という3つの水準で書き直します。
- 大きな目標を任せる前に、必要なツール、アクセス、設定をエージェントに尋ね、サンドボックスにコスト上限と安全上の境界を設けます。
- サポートチケットとエラーログをMCP経由でエージェントにつなぎ、バグを再現できないときはユーザーに直接尋ねさせます。
- ダッシュボードの確認をやめ、毎週の10個の問いと、その答えをまとめたレポートに置き換えます。
- 性能改善では、プロファイラーのトレースと野心的な目標を求めます。行き詰まったら課題の名詞を動詞に言い換え、すでにそれを解決した職業を探します。
最も大きく重要な機能には引き続き人がしっかり関わりつつ、定型的な作業から目標レベルの指示に移し始め、同じモデルでどれだけ多くのことができるかを確かめてください。