十分ゆっくり学べば、学ばずに済む

前の記事ではプログラミングの三つの時代を語った。人が書く時代、機械が学ぶ時代、自然言語の時代。自然言語が新しいプログラミング言語になり、誰もが魔法使いになった以上、呪文を試したくてうずうずしているだろう。しかしAI時代にはこんなジョークがある――「十分ゆっくり学べば、学ばずに済む」。似た言い回しもある――「一晩寝たら、ずいぶん取り残された。一年経ったら、何も逃していなかった」。

「とりあえず学ぶ」から「使うときに学ぶ」へ

こうした冗談は、半分は当たっている。変化が速く、必要になったときにすぐ調べられる細部は、後で学べばいい。

プログラミングには遅延評価（lazy evaluation）という概念がある。式をすぐには評価せず、その値が本当に必要になるまで待つ。Haskellはこれを利用して無限長のリストを表現し、実際に使う部分だけを評価する。機械学習にも遅延学習（lazy learning）という概念がある。基本的なk近傍法はサンプルを蓄えるだけでパラメトリックな予測モデルを事前に学習せず、クエリが来てから比較する。AI時代の今、学ぶ価値のあるものは膨大にあり、学ぶ速度も格段に上がった。私たちの学び方も、これに倣ってよいはずだ。特に次のような知識はそうだ。

  1. 近いうちに使うとは限らず、いざ使うときには調べやすく学びやすいもの。
  2. 今はインプットとアウトプットだけ分かればよく、ブラックボックスとして扱えるもの。
  3. 変化が速く、先に覚えた細部を、使うころには学び直す必要があるかもしれないもの。

技術の進歩に伴い、調べることと学ぶことのコストが変わった。2011年にScienceに掲載された研究では、後でその情報にアクセスできると思っている場合、被験者は情報の内容自体を思い出しにくくなる一方、その保存場所はむしろよく覚えていることが分かった。私たちは記憶の一部を外部システムに預けている。AIはさらに一歩先を行く。見つけてくれるだけでなく、質問に合わせて解説し、例を示し、一緒に試してくれる。

この手の知識を集めずにはいられない人は多い。受験中心の学び方が尾を引いているのではないかと思う。資料を見られない試験で役に立つかどうかばかりを気にしている。しかし現実は、資料持ち込み可の試験だ。これまでは"just in case learning"、つまり「いつか使うかもしれないから、とりあえず学んでおく」ことが多かった。今は"just in time learning"、「使うときに学ぶ」でいい。これは一部のJITコンパイラのやり方に似ている。頻繁に実行されるようになったコードを、その時点で集中的に最適化する。学べば仕事の効率が上がると分かってから学んでも、遅くはない。

原理・原則の知識ほど、価値が長持ちする

早めに学んだ方がいい知識もある。新しい問題について判断するとき、何度も助けになるからだ。Transformerを導出できる必要はないが、いくつかのメンタルモデルは、一度築けばずっと使える。

**モデルが見ている文字は、あなたが見ている文字と同じではない。**モデルはまずテキストをtokenという塊に分割する。一つの単語のこともあれば、単語の一部のこともある。strawberryはあなたの目には10文字だが1、モデルの目には2〜3個のtokenかもしれない。初期のモデルが中のrを正しく数えられなかったのはこのためだ。粒度が違う。ただし、これがモデルの能力の限界というわけではない。分割自体は情報を捨てていないし、新しいモデルはこの種の問題をよりうまく処理する方法を学べる。ある世代のモデルの弱点を、すべてのモデルが永遠に超えられない壁と勘違いしてはならない。

**流暢だからといって、正しいとは限らない。**言語モデルの基本的な訓練目標は「先行するテキストを条件に、次に最もありそうなtokenを予測する」ことだ。この目標により膨大な知識と推論パターンを獲得できるが、訓練したからといって、事実を検証する機能まで付いてくるわけではない。だから話がすらすら出てくるほど、一度立ち止まって問いたい。この主張は自分で確かめられるだろうか。

**「さっき言ったじゃないか」――だがモデルにはもう見えていないかもしれない。**各モデルにはコンテキストウィンドウがある。一度に見られる量には上限がある。会話が長くなると、最初のやり取りはウィンドウの外に押し出されているかもしれない。対話の履歴はまだそこにあると思っていても、モデルにとってその部分はもう視界にない。また、会話中にモデルの重みはリアルタイムで更新されない。このターンで示した例からルールを拾えるが、会話を閉じれば忘れる。ただし、プロダクトに別途記憶機能があれば、保存しておける。モデルの知識のカットオフ日は訓練時に学んだ内容を制約するが、いま貼り付けた資料を読むことは妨げない。

2017年のあのAttention Is All You Needから今日まで、モデルの変化は巨大だが、token、コンテキストウィンドウ、訓練と推論の違いというこれらの概念はいまだに説明力を持っている。ある知識が長期的に学ぶ価値があるかを判断するとき、私はそれが複数の現象を説明できるか、ツールを変えた後もなお判断の助けになるかを見る。原理も修正される。良いメンタルモデルとは、自分の判断がどこで当てにならないかまで教えてくれるものだ。

システムプロンプトとユーザープロンプト

まずはChatGPTやClaudeのようなチャットボットの話から。対話ボックスに「アウトラインを作って」「ここをもっと短く」と打ち込む。これがユーザープロンプト（user prompt）だ。プロダクト側は裏でシステムプロンプト（system prompt）を用意し、アシスタントの基本的な役割や行動ルールなどを伝えている。派遣社員にたとえるなら、システムプロンプトは社則であり、ユーザープロンプトは具体的な仕事の依頼だ。プロンプトの書き方をもっと詳しく知りたければ、コミュニティが管理する流出したシステムプロンプト集を参照できる。余談だが、ユーザーにはこうした信頼形成に関わる情報を知る権利があるべきだと私は考えている。主流の汎用コンパイラがほぼすべてフルオープンソースであるのと同じように。

日常の会話では、対話ボックスに要件を述べるだけでいい。同じ対話の中では、それまでのメッセージも通常はコンテキストに含まれ、後続の回答に使われるため、毎回最初から説明し直す必要はない。「中国語で回答して、技術用語は英語のまま」のような繰り返し伝える好みがあれば、ChatGPTのカスタム指示に保存できる。特定の会話群にだけ適用される背景や要件は、Claudeのプロジェクト知識とプロジェクト指示に入れればいい。

これらはプロダクトが用意したカスタマイズ機能であり、メーカーのシステムプロンプトを直接編集することとは異なる。利用者としては、まず目の前のタスクを明確に伝えれば十分だ。何度も同じことを伝えていると気づいたら、保存しておけば毎回言わずに済む。システムプロンプトの優先度はつねにユーザープロンプトより高い。

エージェント内部でのプロンプトの配置はさらに複雑になる。それはまた別の機会に。

ロールプロンプティングは、もうただのコスプレだ

この役割分担を踏まえると、流行のプロンプト術を見ても、何を自分で補う必要があるのか判断しやすくなる。

スタンフォードの2025年秋学期CS146S: The Modern Software Developerの講義スライドにはこう書かれている――Use role prompting aggressively to make system prompts more powerful。いわゆるロールプロンプティングとは、冒頭で「あなたはトップクラスのフロントエンド専門家です」と一言入れることだ。多くの人がこれをお決まりの書き出しと見なしている。まるでこの一文がなければモデルはフロントエンドのコードを書けないかのように。

Fable 5.1 / GPT-6 Astraという十分にポストトレーニングされた現世代のアシスタントモデルでは、私は基本的に、この前置きを省いてタスクをそのまま伝える。問題を丁寧に理解し、関連知識を活用し、できるだけ役に立つ回答をする――これはまさにメーカーが訓練している行動だ。モデルを優れたアシスタントに仕上げる作業は、ユーザーの手に届く前にかなりの部分が済んでいる。

メーカーは指示チューニングとRLHFなどのポストトレーニング手法により、回答の手本や、どの回答がより望ましいかというフィードバックでモデルを調整し、リクエストへの対応力とユーザー支援能力を高めている。「役に立つアシスタントであれ」はすでにモデルの学習済みデフォルト行動であり、ユーザーが毎回の会話でゼロから教える必要はない。Anthropicのpersona selection modelも、ポストトレーニングがAssistantというペルソナを形作り、磨き上げるという見方を示している。

ペルソナを指定しなくても、目の前にいるのは、すでにアシスタントとしての振る舞いを学んだモデルだ。「Reactのウェブページを作って」というタスク自体がフロントエンド開発の文脈を提供している。「あなたはトップクラスのフロントエンド専門家です」の一文がどれだけ追加の価値をもたらすかは、この土台の上に何を補足しているかにかかっている。出力が変わったかどうかだけでは判断できない。

これが私が汎用的なペルソナ設定を省く理由だ。その一文がモデルに思い出させようとしている行動は、デフォルトのアシスタント行動とタスクの記述の中にすでに含まれている可能性が高い。ここで言う「調整済み」とは、ユーザー支援を目標に幅広いタスク向けに最適化されたデフォルト行動を指す。具体的なタスクの出来は、結局のところ結果で判断するしかない。だから私はまずタスクを述べ、不足を見つけてから要件を補足する。「あなたは専門家です」を必須の前置きにはしない。

「面接官のように一度にひとつだけ質問して」とか「アクセシビリティ監査者の観点でこのウェブページをチェックして」と頼みたいなら、話は別だ。そこで指定しているのは一緒に作業を進める方法やレビューの範囲であり、「ウェブページを作って」からは必ずしも推測できない情報だ。ペルソナはこうした要件を短く伝えるために使える。役に立つのは、それが補足するタスク情報なのだ。

既存の研究も、肩書きへの過信を戒めている。Zhengらの研究は2023年に初公開、2024年に確定稿が出た。162のペルソナをシステムプロンプトに入れ、4つのモデルファミリーに属する9モデルにMMLUの選択式問題2,410問を解かせて比較した結果、ペルソナの追加が全体の正答率を安定して向上させるという結果は得られなかった。この研究はFable 5.1世代のモデルをテストしておらず、それらの評価を代替するものではない。検証しているのは「ペルソナを付ければモデルが強くなる」という広く信じられている仮定だ。

CS146Sのスライドにあった例を、私はFable 5.1で実際に試した。同じ問題（最長回文部分文字列）を、二つのペルソナにそれぞれ解かせた。

Gen Z digital bestie ―― 会話ログ

A helpful assistant that loves programming at the level of a senior software developer ―― 会話ログ

今回はどちらも正しいプログラムを書き、より効率のよいManacherのアルゴリズムにも自発的に言及した。いちばん目立った違いは口調だった。

今回はコスプレのように見えた。あるいはVTuberと言ってもいい。ガワは変わったが、中の人は変わっていない。

ロールプロンプティングの使いすぎは結局のところ手抜きにすぎない。タスクの具体的な要件を考え抜かず、汎用ペルソナに代わりに考えてもらおうとしている。中国の大学入試（高考）の作文で冒頭に有名人の名言を引くのと同じだ。箔はつくが、その課題ならではの情報はほとんど増えない。

たった一文のペルソナ設定がなぜモデルの行動を変えるのかについては、LLMの原理をより深く掘り下げるとき、別の記事「なぜペルソナが行動を変えるのか」を書いて、条件付き確率、attention、役割表現を分解して説明する予定だ。

その技は、もうモデルに組み込まれている

2022年の論文では、“Let’s think step by step"というプロンプトを加えると、当時のモデルのMultiArithでの正答率が17.7%から78.7%に上がることが示された。たった一文がこれほどよく効き、幅広く使えるなら、システムプロンプトに組み込むべきだ。案の定、内部で推論するモデルがその後登場し、OpenAIのガイドはもうこの一文を加える必要はないと述べている。かつて人が手動で促さなければならなかった動作が、モデルのデフォルト行動になったのだ。

Zero-shotとfew-shotを使うと、この区別がよりはっきりする。中国語の“今天天气很好”を英訳させるとき、先に翻訳の手本を見せなければzero-shot（ゼロショットプロンプティング）。中国語と英語の対訳を数組先に示してから新しい文を訳させればfew-shot（フューショットプロンプティング）。ここで言う「ショット」はプロンプト内で示すタスクの実例を指し、モデルが訓練時に見たデータではない。GPT-3の論文のタイトルはそのままLanguage Models are Few-Shot Learnersだ。

モデルが指示を直接理解する能力が上がるにつれ、タスクによっては、まず例を示さずに試して、うまくできるか見ればよくなった。それでもfew-shotが時代遅れになったわけではない。特定の語調、三重にネストしたJSON構造、エッジケースで空配列を返すかエラーを投げるか――こうした場面では、ひとつの手本が千字の説明に勝ることがある。Show, don’t tell。文章を書くときにも昔から使われてきた技法だ。

こうしたプロンプトのテクニックは、今も役に立つ。あまりに幅広く使えるからこそ、技術の進歩とともにモデル内部やシステムプロンプト、あるいは開発元のharnessに組み込まれていく。不要になるのは、ユーザーがその都度、明示的に促すことなのだ。

モデル開発企業の仕事と私たちの仕事

Navalは2026年2月のポッドキャストA Motorcycle for the Mindでもっと率直に語っている。プロンプトの書き方やharnessの組み方といったコツを、熱心に学ぶ気はないという。技術が自分に適応する速度の方が自分が適応する速度より速いと信じているからだ。彼の見立てでは、それらのworkflowやツールの寿命は「週単位、せいぜい月単位であり、年単位ではない」。ただし例外をひとつ残した。今まさに最先端のプロダクトを作っていて、わずかな競争上の優位も逃せない場合は学ぶ価値がある、と。5月にはコーディング版を語った。Ralph Wiggum、OpenClaw、plan modeといった助言には乗らず、Codex、Claude、Geminiを同じ問題に繰り返し投入する――“waste tokens, save time”。

Navalの考え方に沿って、私はAIを使うためにかける労力を二つに分けたい。their jobとour jobだ。Their jobとは、モデルやツールの開発者が今まさに改善し続けていること――モデルの推論力を上げ、ツール使用の信頼性を高め、人の話し方への適応力を向上させる。ある技法がモデルの弱点を補うだけのものなら、その価値はモデルのアップグレードとともに下がりうる。もちろん、今日の仕事に役立つなら、今日学ぶことには意味がある。Our jobはまた別だ。Navalは技法を学ばないと言っているが、すぐその後に、こう続けている。

I just can speak English. And for someone like me who is relatively articulate with English and also has a structured mind, and I know how computer architectures work, and I know how computer programs work, and I know how programmers think, then I can actually very precisely specify what I want just through structured English.

これ自体が最強のプロンプト術だ。明晰な自然言語、構造化された思考、機械の仕組みを理解していること、プログラマの考え方を知っていること、そして、何を求めているかを正確に言葉にすること。Navalに技法がないのではない。彼の技法はAIが登場する前にすでに鍛え上げられていたのだ。それ以前に積み重ねた表現力、プログラミング力、判断力は、価値を失うどころか、AI時代にはさらに価値を増した。

本当に自分のものになるプロンプト術は、書く力だ

モデルの弱点を補うテクニックは、モデルの世代交代とともに必要なくなる。しかし、タスクそのものに関する情報を明確に伝える力は、いつまでも古びない。

モデルを、派遣会社から来たスタッフだと思えばいい。この人は途方もなく聡明で、多くの本を読み、さまざまな言語で書ける。しかし今朝あなたのオフィスに来たばかりだ。あなたたちが何のプロダクトを作っているか、誰に向けたものか、チームにどんな暗黙のルールがあるか、前回のトラブルはなぜ起きたか。そうしたことは知らない。すでに得意なことについてはforループから教える必要はない。手間をかけるべきは、このプロジェクト固有のコンテキストを渡すことだ。

プロンプトは最初から完璧に書く必要はない。良いプロンプト術はLLM-friendlyであるだけでなく、human-friendlyでもあるべきだ。毎回作業前に完全な仕様書を書かなければならないとしたら、作業に取りかかる前に、気後れしてしまうかもしれない。プロンプト手法を評価するとき、人が取りかかるまでに必要な労力も考えるべきだ。

『小さな習慣』は、毎日自分に課す行動を、ごく小さくすることを勧めている。フォッグ行動モデルも、行動の難度を下げることで行動が起きやすくなると強調する。この考え方を借りれば、AIとの協働の第一歩も小さくていい。やりたいことをまず口にする。考えがまとまっていなければ、AIに質問してもらいながら考えを整理し、一緒に試してみればいい。

最初の案ができたら、結果を見て要件を補う。文章を推敲するように、AIとの作業も直しながら進めればいい。最初のプロンプトでどれほどよい回答が出るかだけでなく、人が気軽に始められるか、少しずつ進めて最後までやり遂げられるかも大切だ。

本気でプロンプトを学ぶなら、私はまずモデル開発元の公式ガイドから始める。タスクを明確にし、背景を伝え、必要なら例を示す。こうした基本こそ、長く磨き続ける価値がある。公式の具体的なアドバイスも変わるから、使うときに最新版を確認し、実際の結果を見ればいい。AIは幅広く使えるのだから、AIについて学ぶときにもAIを使える。どう質問すればいいか分からなければ、AIに問いの整理を手伝ってもらえばいい。何かを学ぶために時間と労力を投じる価値があるか迷ったら、AIに聞けばいい。「AIの使い方」を学び終えてからAIを使い始める必要はないのだ。

Let them do their job, and we do ours.

さらに読む

  1. 初稿を書いているとき、私はこの実験を再現してみた。AIはrの数を正しく3個と答えたのに、今度は全体の文字数を数え間違え、9文字だと言った。 ↩︎