AIに「もっと大きな仕事を任せよう」と言われても、依頼をどう変えればよいのかは分かりにくい。公開記事「How to be more ambitious: A tutorial for humans with models」は、その曖昧な助言を、速度・高度・深さ・広さという方向に分けています。
同じ仕事を速く終える「速度」はすでに馴染みがあるとして、記事が掘り下げるのは残りの方向です。Claudeを使った例が中心ですが、特定のモデルに限った話ではありません。注目したいのは、指示を壮大にするだけでなく、元データ、道具、結果を確かめる手段まで用意するという条件です。
高度を上げるとは、成果物の先を聞くこと
記事は架空の会社の四半期レビューを例にしています。「スライドを作って」から、「何が変わり、なぜ変わり、何をすべきか調べて」へ。さらに、経営陣が問題を早く見つけ、人員や予算を動かすことが目的なら、四半期ごとの資料よりよい仕組みを考えられないか、と問い直します。
これは、資料の枚数を増やす話ではありません。いま頼んでいる作業が、どんな結果を得るための手段なのかを一段上から見る方法です。記事でも、明確な最終成果がある仕事に向いており、創作には同じように当てはまるとは限らないとしています。
ただし、目的を渡せば環境の不足まで埋まるわけではない。記事にあるアプリのクラッシュ対策では、レポートの取得、アプリのバージョンとGitコミットの対応、各OSでの再現・検証環境を整えたうえで、個別修正から継続的な対策へ任せ方を変えています。依頼の範囲と、実際に調べられる範囲を揃える必要があります。
深さは、専門家らしい口調ではなく手法で測る
「専門家として考えて」と頼むと、手法は変わらず語彙だけが専門的になることがある。記事のこの指摘は、依頼を見直す基準になります。
解約の原因を調べるなら、整った表を出して終わるのではなく、元のログやデータベースへ戻る。「原因はオンボーディングだ」という前提をデータから再検証し、未知の兆候が見つかったなら、まだ見ていないデータでも予測が成り立つかを確かめる。記事が提案する「深さ」は、説明の長さではなく、材料と方法の変更です。
ここで外せないのが、モデル自身の評価だけで正しさを決めないこと。記事は外部の検証手段を求め、とくにモデルが実行してすぐに結果を受け取れる道具を勧めています。Claude Codeの公式ガイドも、テスト、ビルドの終了コード、画面の比較など、作業結果を確認する手段を与えるよう案内しています。「できた」という返事ではなく、何を実行し、どう確かめたのかを見るわけです。
広さを出すなら、役柄より作業を借りる
「広さ」は、別分野の方法を持ち込むことです。記事では、資料という名詞を、因果関係を伝えて不確実な状況で判断してもらう、という動作に置き換えます。そうすると、分析だけでなく、取材や編集、反証を探す調査といった方法も候補に入ります。
ただし、複数の専門家を演じさせるだけでは、会話が奇妙になるだけで成果はよくならない、と記事は釘を刺しています。欲しいのは登場人物ではなく、その分野で実際に使う調査や検証の手順です。
最初から大規模な自動化を目指すより、手元の依頼を一つ選び、「何を達成したいか」「どの元データと道具を使うか」「何で正しさを判定するか」を書き直す。この読み方なら、野心を大きくすることと、確認を省かないことは両立します。任せる範囲を広げる前に、成功を見分ける方法を用意しておきたいところです。