記事
AI 活用の天井は、あなたの野心：スピード・高度・深度・幅の4つの次元
Anthropic のエンジニアリング責任者 Felix Rieseberg は、「AI にもっと野心的になる」ことをスピード・高度・深度・幅の4つの次元に分解しました。本記事では彼のやり方と事例をまとめ、さらに私の実践ノートを加えます。ゴール志向の指示を出し、Multi-AI Agents の専門家チームを動かして多視点のクロスレビューを行い、タスクの品質を高める方法です。
· 7 分で読めます
Anthropic のエンジニアリング責任者 Felix Rieseberg は、「How to be more ambitious: A tutorial for humans with models」の中で、他の人が AI で驚くような成果を出しているのを見ると、自分も周りの人も同じ反応をすると述べています。「自分たちはまだ十分に野心的ではない」。
私の解釈はこうです。人間が AI を使う際の上限は、モデルではなく、自分自身の野心と想像力で決まることが多い。
彼は「野心」を4つの次元に分解しています。
- スピード（Speed）：同じ仕事を、より短い時間で終わらせる。
- 高度（Altitude）：抽象度を引き上げ、単一のタスクではなく最終的な成果を見る。
- 深度（Depth）：その分野のトップ専門家の基準、ツール、方法で取り組む。
- 幅（Range）：単一の領域を飛び出し、分野をまたいで解決策を探す。
先に結論を述べます。ゴール志向の指示を的確に出し、Multi-AI Agents の専門家チームを動かして多視点の協働とクロスレビューを行うことで、タスク全体の品質が底上げされます。
一、スピード：最も基本的で、つまずく人が最も少ない#
同じ仕事をより短い時間で終わらせること。Felix は、これはすでに誰もがよく知っていると考え、記事では扱っていません。
私の見方です。スピードは AI の最も分かりやすい価値ですが、スピードだけを追っても、協働のやり方はあまり変わりません。本当に差がつくのは、残りの3つの次元です。
二、高度：「ゴールの先のゴール」を問う#
核心の問い：次に本当に欲しい成果は何か。ゴールの先のゴールは何か。
Felix の例：
- 1つの Crash を直すことから、App を Crash させないことへ。 彼は当初、Claude に1つの Crash の修正を頼んでいましたが、のちに App のクラッシュをゼロに保つことを求めるようになりました。これを継続的に自動で回すために、まず自分のプロセスを変える必要がありました。Crash レポートを取得しやすくし、App のバージョンを Git Commit に対応づけ、Claude が Windows、macOS、Linux のマシンを使って再現と修正の検証をできるようにしたのです。
- 四半期ビジネスレビュー（QBR）の3段階アップグレード：
- できるだけ生データを使い、今四半期に何が変わったのか、なぜか、次に何をすべきかを説明する。
- 最も差し迫った決定を3つ見つけ、それぞれに賛成・反対の論点を書き出す。
- 四半期の資料よりも早く問題に気づける代替の仕組みを設計し、過去データでテストしたうえで、現行のプロセスと並行して1四半期運用する。
彼は限界についても注意を促しています。2026年の時点では、「Claude、私のためにお金を稼いできて」のような曖昧なゴールはまだ通用しませんが、モデルが扱える抽象度は今後ますます上がっていくと見ています。
三、深度：その分野のトップ専門家の仕様に合わせる#
Felix のやり方：
- その業界が実際に使っているツールを使う。 モデルは言葉づかいだけ変えて方法は変えず、Markdown の表を1枚出して済ませがちです。データベースや統計モデルのような本物の分析ツールを使うよう、粘り強く求めます。
- 一見無理な目標を設定し、解けるとモデルに伝える。 彼の例：Web サイトの読み込み時間を10秒から5秒にしたあと、さらに200ミリ秒を求める。モデルが尻込みしたら、この目標は達成できると言い続けます。
- 自分が信じている前提に挑む。 生データをモデルに渡し、対抗的な視点で検証させます。例：「離脱の原因はオンボーディングにあると考えている。生データからこの結論を再現してみて」。
- 新しい知識を生み出す。 Logs からシミュレーションを作り、まだ知らない最も早い離脱のシグナルを見つけ、見たことのないデータで検証します。
- 外部の審判（Outside Judge）を置く。 モデルに自分の仕事を自分で採点させません。モデルが直接実行でき、すぐにフィードバックが返るツールをつないで検証するのが理想です。
彼のプロンプトの心得はこうです。求めるのは「より大きなバージョン」ではなく、「より深いバージョン」。 トップのプロフェッショナルなら余分に何をするか、最も生のデータはどこにあるか、どの方法とツールを使うか、そしてモデルやあなた自身の判断以外に、結果が正しいことを何が証明できるかを、モデルに挙げさせます。
四、幅：名詞ではなく動詞で考え、専門家チームを組む#
- 名詞ではなく動詞で考える。 この考え方を、Felix は The Art of Innovation から引いています。QBR は「1つの資料」というより、「30分で、忙しい人が因果を理解し、不確実な中で意思決定できるようにすること」です。動詞でゴールを定義すると、どの分野の力が必要かが見えてきます。
- チームを組む。 良い資料を作るにはアナリスト、記者、編集者を、発表するならさらにモーションとサウンドのデザイナーを加えます。対抗的なレビューをするなら、空売りファンドのリサーチャーとフォレンジック会計士を呼びます。
- 意味のないロールプレイはしない。 モデルに「空売りファンドの口調で書いて」と言うのではなく、空売りファンドが行うリサーチの一部の手法を実際に実行させます。口調を変えるだけでは、結果は良くなりません。
前提として、モデルにはソフトウェアをインストールできるコンピュータがあり、MCP コネクタなどを通じて関連データにアクセスできる必要があります。
五、私の実践ノート：「データの受け渡し」から「意図の達成」へ#
以下は、ソフトウェアアーキテクチャとエンジニアリングの実務を組み合わせた私の拡張であり、原文の内容ではありません。
1. Jobs to be Done と意図指向（Intent-Based）#
- 「何をするか」ではなく、「何を達成するか」を問う。 設計は
generate_deck_pdf() のような受け身のデータ受け渡しパイプラインにとどまらず、resolve_leadership_uncertainty_and_commit_budget() のような状態遷移の意図へ引き上げるべきです。
- 本物の損失関数を定義する。 成果物だけを求めると、モデルは完璧に見えるだけの中身のない文章を生成します。意思決定の不確実性の解消を求めてはじめて、モデルと Sub-agent は自ら論理の穴やリスクの境界を埋めにいきます。
2. 探索では発散し、検収では収束する#
- 探索のときは、まず発散して可能性を探り、そのあとで収束させる。
- 検収のときは、もう発散しない。「他にどんなやり方があるか」のような境界のない問いは、ありきたりな答えしか呼びません。
- ゴールの範囲、制約条件、客観的な検証ツールを明確に書く（特定のテストスクリプト、ビジネス指標のしきい値）。そうすれば、Multi-Agent チームは焦点の定まった枠組みの中でストレステストを行い、高品質な成果を出せます。
学びのまとめ#
- ゴール志向： 名詞ではなく動詞で考える。納品のためだけの成果物ではなく、問題を解決する成果を届ける。
- 探索と収束： 探索では発散して可能性を探り、検収では厳密に収束させて境界を検証する。
- 抽象度の絞り込み： 核心の問いから出発し、タスクの流れ全体を組み直す。
- 専門家の深度： 専門家の口調をまねるだけでなく、トップ専門家のツールと方法で問題を解くようモデルに迫る。
原文：How to be more ambitious: A tutorial for humans with models（Felix Rieseberg、2026-10-13）