Communitygithub.com

dinaf2026-web/aim-higher

作業開始前に目標の天井を引き上げます。Felix Rieseberg の2026年10月13日のエッセイにある4種類の野心(速度、高度、深度、範囲)を活用します。依頼が文字通りのタスクレベルでなされ、その背後にある成果にまで及んでいない場合に使用します。トラッカー、レポート、書簡、分析、照合、リスト作成、計画、構築、修正などに。また、「もっと高く」「もっと野心的に」「もっと大きく考えろ」「専門家ならどうするか」「もっと深く」といった指示にも使います。

aim-higher とは?

このスキルは、AI エージェント(Claude Code、Cursor、Codex 等)向けに設計された目標引き上げ技法です。Felix Rieseberg の理論に基づき、タスクの「速度」「高度」「深度」「範囲」という4つの野心レバーを順次適用し、作業開始前に目標を引き上げます。高度レバーではタスクの背後にある真の目標を探り、深度レバーでは分野の第一人者の手法とツールを導入し、範囲レバーでは他分野の視点と役割を取り込みます。各レバーには具体的な質問セットと評価基準(外部判定者)が組み込まれており、単なるプロンプト集ではなく、構造化された思考プロセスを提供します。特に目標を引き上げても主張の正確性は保たれるよう、結果検証とギャップ報告を必須とし、虚偽の主張を防ぐガードレールを備えています。小タスクには簡略化された適用が可能で、複数セッションの構築やフォレンジック分析など本格的な作業で真価を発揮します。

対応~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/dinaf2026-web/aim-higher/tree/HEAD/skills/aim-higher

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

ドキュメント

Aim Higher(目標を高く掲げる)

Felix Rieseberg の主張は、モデルが限界なのではなく、依頼の規模が限界だということです。彼は野心を4種類に分類し、最初のものは誰もが既に行っているため省きます。

種類行動ここでの位置づけ
速度同じ作業、短い時間すでにデフォルト。スキルは不要。
高度タスクではなく成果に取り組むレバー1
深度その分野の第一人者のように取り組むレバー2
範囲他の分野とその手法を取り入れるレバー3

これはプロンプト集ではありません。貼り付けたプロンプトは一回限りです。結果を変えるのは、作業を始める前に毎回3つの質問をし、想定ではなく実際にあるものに基づいて回答することです。

最初に来るガードレール

Rieseberg の深度テクニック「非現実的な目標を選び、モデルに『非常に現実的だ』と伝える」は理にかなっていますが、同時にこのスキルが実際に害を及ぼす可能性がある唯一の方法でもあります。

非現実的な目標は問題ありません。非現実的な主張は嘘です。 ページの読み込みに5秒かかるところに200msを要求するのは良い習慣です。目標だったから200msと報告するのは虚偽の記述です。これはあらゆる数値(再現率、照合合計、単語数、締切)にも当てはまります。

したがって、目標を引き上げることは試みる内容を変えるだけで、主張する内容については何も変えません。すべての主張はその出典を保持し、すべての計算値はそのセッションで実行されたツールから得られ、何も見つからなかった検索は存在するものについてではなく、どこを調べたかについての記述です。野心と検証が互いに競合する場合、検証が優先され、ギャップが明記されます:「目標はX、測定結果はY」。

このスキルが関わったすべての作業は、次の4行で締めくくります。

目標: <引き上げられた目標>
測定結果: <ツールが返した値、ツール名を明記>
ギャップ: <差異を率直に記述>
判断者: <それを確定した外部チェック>
未検証: <未解決の事項があれば名前を挙げる>

レバー1、高度:目標の向こう側にある目標とは何か

Rieseberg のテスト:次に何が起こるべきかを尋ね、その答えが文書でなくなるまで尋ね続けます。彼は、高度は作業が会議や意思決定に供するときに最も効果的であり、創作作業では最も効果が薄いと指摘しています。

3つの段階(ラング)を生成します。メニューを提示するのではなく、1つを選び、その下の段階をフォールバックとして指定します。

  1. 文字通りの依頼を、適切に実行する。 一言で述べ、下限を設定します。
  2. それが支える意思決定。 モデルに生の素材を与え、何が変わり、なぜか、そして何をすべきかを尋ねます。次に、真に緊急な2つまたは3つの意思決定を、それぞれの賛否とともに挙げます。
  3. 依頼に代わるもの。 成果物よりも優れたものを設計し、その設計をプロジェクト自身の履歴に対してテストし、現在の方法と並行して1サイクル実行することを提案します。

具体例:誰かが許可証トラッカーを依頼したとします。ラング1はトラッカー。ラング2は、どの3つの許可証が最も遅延しやすいかとそれぞれの対応策。ラング3は、相手側が気づく前に遅延を警告するプロセスであり、すでに遅延した許可証で検証済み。

人々がスキップする部分。 Rieseberg は、高度が可能になる前に自身のワークフローを変更する必要がありました。クラッシュレポートを取得可能にし、アプリバージョンをコミットにマッピングし、モデルに再現用のマシンを提供しました。その類推は、ほとんどの場合、要約ではなく生のソースへのアクセスです。欠けているアクセスを明示的に名指ししてください。それがなければラング3は単なるパフォーマンスです。典型的なギャップ:エクスポートされたレポートではなくポータル、スクリーンショットではなくコンソール、ステートメントPDFではなく会計ファイル、月次合計ではなく取引データ。

フィクションや音声作業ではこのレバーをスキップしてください。 書簡、メール、申請書は意思決定文書であり、高度は完全に適用されます。小説は違います。

レバー2、深度:その分野の第一人者のように取り組む

Rieseberg のフレームワークから始めます:タスクのより大きなバージョンではなく、より深いバージョン。ページ数が多いことは深さではありません。

  1. 第一人者が使う道具を使う。 正直な道具がデータベースと統計検定なら、Markdown テーブルを返してはいけません。手入力されたリテラル値の合計を持つスプレッドシートは、入力と矛盾できないため、エラーを報告することはありません。
  2. 非現実的な目標を選び、それを現実的として扱う。 上記のガードレールに従います。
  3. ユーザーが既に信じていることに挑戦する。 述べられた前提を最も生のソースに持ち込み、それを言い換えるのではなく、敵対的にテストします。データに耐えられない前提の部分を、耐えられる部分の前に述べます。
  4. 新しい知識を生み出す。 データの奥深くに入ったら、盲点を探します。小さなシミュレーションを構築し、その予測をまだ見たことのないデータに対してテストします。
  5. 自己評価ではなく、外部の判断者を使う。 Rieseberg は、理想的にはモデルが即座にフィードバックを得るために実行できるツールと言います。

外部の判断者はスキップされがちなレバー

判断者とは、拒否できるものです。セカンドオピニオンでもチェックリストでも再読でもありません。作業の種類ごとに1つ構築するか借用します。

作業の種類拒否できる判断者
複数部品の構築や監査実行可能なチェックと期待される出力を持つゲートファイル。チェックに合格しない限り完了の主張は失敗。
数値や合計入力から再計算し、不一致で非ゼロ終了するスクリプト。一致数は事前に表明。
「そこにはない」どのルートを完了できなかったかを報告する検索ツール。部分的なパスから存在しないと推測しない。
外部に送り出す文書識別子や未レビューの名前でブロックするスキャン。
スタイルルールに対する散文機械的に決定可能なルールに対するリンター。アドバイスではなく拒否する。
過去の結論出典と日付付きの決定台帳。再導出ではなく検証済み。

適切なツールがない場合、判断者は直接読み取られる一次情報源です。モデル自身の出力に対する自身の読み取りであってはなりません。

4つの質問による深度プロンプト

開始前に4つすべてに答え、書き換えた依頼を示します。

  1. この分野の最も優れた人物が、依頼されていないことで何をするだろうか?
  2. 彼らが開始するであろう最も生のソース素材は何か?要約ではなく、実際の文書名を挙げよ。
  3. 彼らが使用する具体的な方法とツールは何か?
  4. ユーザーやモデル以外に、結果が正しいことを示すものは何か?実行可能なチェックを挙げよ。

次に、その内容を正確に依頼するようにリクエストを書き換え、構築前に書き換えを示します。

ドメインごとの貼り付け可能な文言は references/prompts.md にあります。

レバー3、範囲:他の分野とその人々

  1. 名詞を動詞に置き換える。 成果物はモノであり、仕事は行動です。四半期レビューはデッキではなく、忙しい人々に因果関係のストーリーを信じさせ、不確実性の中で決断させることです。要求書は、支払いを相手方にとって最も安い経路にすることです。リスティングページは、見知らぬ人が未知の作者にリスクを負ってお金を投じる決断をすることです。Tom Kelley と Jonathan Littman 著『The Art of Innovation』より。
  2. チームを編成する。 強力なチームが持つであろう役割を、明らかな専門分野以外からも挙げ、レッドチームも含めます。Rieseberg の例:アナリスト、ジャーナリスト、編集者、作業が発表される場合のモーション&オーディオデザイナー、そしてレッドチームとしてショートセラー兼フォレンジック会計士。ドメインごとのチームは references/crews.md にあります。
  3. ロールプレイではなく、行動する。 役割が書く声ではなく、役割が行う仕事を依頼します。「フォレンジック会計士のように書け」は奇妙な散文とより良い回答を生みません。「開示されたすべての数値を銀行の明細行に結び付け、結びつかないものをリストアップせよ」は回答を生みます。

役割の命名について。 多くのプロンプトアドバイスはペルソナを割り当てるよう言い、Rieseberg はロールプレイを避けるよう言います。両方とも異なる点で正しいです。役割の標準が適用されるように名前を付け、次にその出力を依頼し、そのレジスター(文体)は決して依頼しません。

シーケンス

  1. プロジェクトの現在の状態が記録されているものがあれば、それを読む。それがなければ、高い目標は推測に過ぎない。
  2. 高度。 ラングとアクセスギャップを示す。1つ選び、フォールバックを指定する。
  3. 深度。 4つの質問に答え、判断者を指定し、書き換えた依頼を示す。
  4. 範囲。 動詞、名詞ではなく。チームを指定し、声ではなく作業を割り当てる。
  5. プロジェクトが使用するレビューと完了の規律に引き継ぐ。
  6. 目標に対して報告し、4行のクロージングラインで締めくくる。

これを小さなタスクすべてに実行してはいけません。30分の作業であれば、1つか2つのラングと名前付きの判断者がすべてです。完全なシーケンスは、複数セッションの構築、フォレンジック分析、定期成果物、または「ノー」と言える誰かが読むものにのみ、そのコストに見合う価値があります。

良い結果の見た目

このスキルからの返信はメニューで始まりません。引き上げられた目標を1行で示し、次にラング、そしてそれが機能したかどうかを判断する判断者を示します。フレームワークが適用されているように読め、より良い回答が提案されているように読めない場合、スキルは失敗であり、単純な回答のほうが正しかったことになります。

関連スキル