be-ambitious

野心的になりましょう

ここで紹介するアイデアはすべて、Felix Rieseberg の記事「How to be more ambitious: a tutorial for humans with models」（2026年10月13日）に基づいています。Felix は Anthropic で Claude の開発に携わっています。このスキルは、彼の記事をエージェントが実行できる手順に変換したものです。

多くの人は、自分が入力したタスクの規模に合わせてモデルを使います。モデルのスキルは一様には伸びず、「ある方向では驚異的だが、別の方向では不十分」（Terence Tao）です。だからこそ、驚異的な能力を見つける唯一の方法は、妥当だと思える範囲を超えて目標を高く設定することです。

最も重要なルール

1. 大きくではなく、より良く。 それぞれのタイプは、成果（Altitude）、基準（Depth）、または視点の幅（Range）のいずれかを高めます。どれも、成果物や機能、寄り道を増やすという意味ではありません。提案によって仕事が大きくなるだけで、より良くならないなら、取り入れないでください。
2. 専門家の話し方ではなく、専門家のやり方を取り入れる。 分野の知見を取り入れるなら、その分野の手法や計測ツールを使ってください。手法を変えずに用語だけ変えても、それは役割を演じているだけです。会話の記録が奇妙になるだけで、結果は変わりません。
3. 成果の判定は外部の評価者に委ねる。 自分の仕事を自分で評価してはいけません。結果が正しいことを示す、あなたやユーザー以外のものを見つけてください。テスト、ベンチマーク、再現、保留データ、測定値などが該当します。最善なのは、すぐにフィードバックを得られる実行可能なツールです。
4. 難しい目標を達成可能なものとして扱う。 目標が不可能に見えても、解決できると考えて取り組み続けてください。具体的で難しい目標は、「最善を尽くす」よりも効果的です（Felix が引用する、目標設定に関する35年間の研究をまとめた Locke と Latham のレビューを参照）。評価者に対しては、正直に報告してください。実測値を伴う難しい目標の未達成は、良い結果です。達成したと偽るのは違います。
5. アクセスを確保し、あるふりをしない。 これらを実行するには、ソフトウェアをインストールできるコンピューターと、MCP コネクター（エージェントを他のアプリに接続するプラグイン）などを通じて、実際のデータにアクセスできる環境が必要です。どちらかが欠けている場合は、何が不足していて、それがあれば何が可能になるのかを具体的に示してください。不足分を埋めるために、情報源やツール、結果を捏造してはいけません。

入力

タスクは /be-ambitious の後に続く内容です。何も続かない場合は、ユーザーの直近の依頼を使ってください。それもなければ、タスクを一行で尋ねて、そこで止めてください。

次に、渡された内容を判断してください。

• 実行するタスク（これを修正する、これを構築する、これを分析する）：野心的なレベルで計画し、実行してください。
• 改善するプロンプト（書き換えの依頼、または別のエージェントやツールに実行させるタスク）：書き換えたプロンプトを提示したら、そこで止めてください。

どちらか判断できない場合は、書き換えたプロンプトを提示したら、そこで止めてください。

適切なタイプを選ぶ

Felix は野心を4つのタイプに分類しています。Speed（同じ仕事をより短時間で行うこと）は、すでに多くの人が AI を使って実現しており、創造性を必要としないため、彼は対象から外しています。このスキルも同様です。残りの3つは、適切な場合にだけ使ってください。ほとんどのタスクでは、1つか2つで十分です。

タイプ	適する場合	避ける場合
Altitude	タスクが何らかの成果につながる場合。人々がそのために会議を開くようなら、よい目安です	成果そのもの以外に目標がない創作
Depth	タスクを非常に高い水準で仕上げる必要がある場合	使い捨ての作業
Range	人々に受け入れられる結果が必要な場合、または明白な分野からアイデアが出尽くした場合	正解が一つに定まる範囲の狭い修正

高度：目指す成果を定める

ユーザーが次に何を実現したいのかを尋ねます。その目標の先にある目標は何でしょうか。Felixは以前、Claudeに個々のクラッシュを修正するよう依頼していました。その後、アプリをクラッシュしない状態に保つよう依頼しました。

3段のはしごを作り、1段上がるごとに目標を大きくします。Felixの例は、四半期ごとの事業レビュー（QBR）資料です。

1. 記入するのではなく、理解する。 テンプレートの数値を更新するのはやめましょう。得られる限りのデータを取り込み、「今四半期に何が変わり、なぜ変わり、私たちは何をすべきか」を明らかにします。
2. 意思決定にたどり着く。 「学んだことすべてを踏まえて、最も急を要する3つの意思決定を見極め、賛成・反対の根拠を示しながら、方向性の候補を検討し始めます。」
3. 慣習そのものを置き換える。 「このレビューの目的は、経営陣が問題を早期に察知し、資金と人材を適切な場所に振り向けることです。四半期ごとの資料よりも優れた方法を設計し、自社の過去の記録から、より早く問題を察知できたことを示し、今の方法と並行して1四半期運用します。」

最上段にあるのは、持続的なワークフローです。人間をループから外すものです。多くの場合、まずセットアップが必要です。ClaudeがFelixのアプリをクラッシュしない状態に保てるようになる前に、クラッシュレポートを取得し、各アプリのバージョンをgitのコミットに対応付け、Windows、macOS、Linuxのマシンを使って修正を再現・検証する必要がありました。このセットアップも計画の一部として明記しましょう。

限界を見極めましょう。「お金を稼いで」は、ほとんどの企業にとってまだ目標が高すぎます。外部の評価者がいない段は、1段下がりましょう。

深さ：その分野の第一人者のように取り組む

タスクを一段掘り下げ、その根底にあるデータ、ツール、問題に取り組みます。その分野の第一人者でさえ、成果から何かを学べるところまで掘り下げ続けましょう。

• 専門家の道具を使う。 専門家の言葉をまねるだけではありません。Markdownの表を使う場面で、一流のデータサイエンティストならデータベースと統計モデルを使います。ユーザーは専門家が何を使うかを知る必要はありません。通常、それを把握しておくのはあなたです。
• 無理に思える目標を掲げ、達成可能なものとして扱う。 ページの読み込みに10秒かかり、ユーザーは5秒を求めているなら、200ミリ秒を目指しましょう。
• 誰もが信じていることに異議を唱える。 生データを入手し、反証を試みる形でその考えを検証します。「解約の原因はオンボーディングだと考えています。生データからその結論を再現してみてください。」
• 新たな知見を生み出す。 データを深く掘り下げたら、見落としを探します。「ログから過去1年間を再現する顧客シミュレーションを構築してください。次に、まだ把握していない解約の最も早い兆候を見つけ、未見のデータでも予測できることを示してください。」
• 外部の評価者を加える（ルール3）。

Felixのプロンプトを使って、深さを追求するたびに問い直しましょう。

このタスクを、規模ではなく深さの面で高めたいです。書き換える前に、次の点を述べてください。（1）この分野の一流の専門家なら、ここで私が求めていないどのようなことに取り組むか。（2）すでに加工された情報ではなく、どのような最も生の素材から着手するか。（3）どのような具体的な手法やツールを使うか。（4）あなたや私以外の何によって、結果が正しいと判断できるか。そのうえで、まさにそれを求めるように私のプロンプトを書き換えてください。

範囲：別の分野を取り入れる

これまで現実的ではなかったほど多くの分野の視点から、作業を見てみましょう。強盗映画はどれも、最初の30分を仲間集めに費やします。Felixはここに最大の可能性を見いだしており、最も創造性が求められる部分でもあります。

• 名詞を動詞に置き換える。 Tom KelleyとJonathan Littmanの著書『The Art of Innovation』から得たコツです。四半期レビューは「資料」ではありません。「忙しい人々に因果関係のストーリーを信じてもらい、不確実な状況で30分以内に意思決定してもらうこと」です。動詞に置き換えると、どの分野が役立つかが見えてきます。
• 仲間を集める。 重要性を高めます。資料が素晴らしくなければ宇宙人が地球を爆破する。人類は誰を送り込むでしょうか？品質を高めるなら、アナリスト、ジャーナリスト、編集者です。発表するなら、モーションデザイナーとオーディオデザイナーです。レッドチームとしてなら、空売り投資家とフォレンジック会計士です。
• その分野のツールを借りる。 分野がもたらすのはアイデアだけではなく、ソフトウェアもです。Felixの同僚であるAlex Albertは、3DツールのBlenderでインテリアデザインをレンダリングしています。
• 演じるのではなく、実行する（ルール2）。空売り投資家のように書くのではなく、空売り投資家が投資判断を調査する方法を実践してください。サブエージェントを実行できるなら、それぞれの分野に、その分野の手法とツールを使う専用のサブエージェントを割り当ててください。

出力

タスクに合わせて出力量を調整してください。書き換えたプロンプト自体が成果物なので、1行のプロンプトには数行の計画を添えます。次の順序で記載します。

1. 目標の先にある目標を1行で。
2. 適したタイプを、各タイプが適している理由とともに1行ずつ記載し、採用しなかったタイプも記載します。
3. 選んだ各タイプの計画。高度：3段階のはしご。深さ：Felixのプロンプトにある4つの回答と、明確な目標。範囲：動詞、次に分野としての仲間、その仲間が実際に行う作業、その作業に使う手法やツール。
4. 必要なもの：データ、ツール、アクセス権を挙げ、すでにあるか不足しているかを示します。
5. 書き換えたプロンプトを、ユーザーがコピーできるようにフェンス付きコードブロック1つに記載します。ユーザーが入力するような書き方にし、最後に外部評価者と合格条件を記載します。
6. 次のステップ。 現在のアクセス権で完了し、確認できる最も高い段階を選びます。改善用プロンプトの場合は、その段階を示して止めます。実行するタスクの場合は、1行でタスクを示して開始します。最初の段階にも必要なアクセス権がない場合は、それを求めて止めます。また、段階を上げるのではなくユーザーの依頼を置き換える場合、費用がかかる場合、元に戻せない場合も、先に確認してください。野心は基準を高めるためのものであり、権限を広げるものではありません。

短い例

/be-ambitious ログイン画面のクラッシュを修正して

• 目標の先にある目標： 誰でもいつでもログインできるようにする。
• タイプ： 高度と深さ。クラッシュ修正には正解が1つしかないため、範囲は対象外です。
• 高度のはしご： (1) 修正前は失敗し、修正後は成功するテストを用意して、このクラッシュを修正する。(2) クラッシュレポートを調べて同種のクラッシュをすべて見つけ、症状ではなく原因を修正する。(3) ログイン時のクラッシュをなくす。クラッシュレポートを取得し、バージョンをコミットに対応付け、すべてのプラットフォームで再現し、依頼を待たずに修正して検証する。
• 深さ： バグ報告ではなく、生のクラッシュダンプとログから始めます。修正前に再現します。目標はクラッシュを減らすことではなく、次のリリースでログイン時のクラッシュをゼロにすることです。
• 外部評価者： 失敗していたテストが成功し、レポートツールでそのビルドのクラッシュ率がゼロになっていること。

これが有効な理由

Felixは最後に自己効力感について述べています。自分の能力を信じる人はより多くを成し遂げ、その信念は意図的に生み出せます。George Dantzigは1939年、未解決だった統計学の問題を2つ解きました。それらが宿題だと思っていたからです。Roger Bannisterが1954年に1マイル4分の壁を破ると、46日後には別の人もそれを達成しました。『The Inner Game of Tennis』では、力みすぎるのをやめたときに最高のプレーができると論じています。ユーザーとモデルにも同じことが言えます。難しいことも可能だと伝え、誠実な評価者に対して失敗する自由を与えましょう。