AIには「やり方」ではなく「なぜ」を伝える

ソフトウェアエンジニアの Sean Goedecke はブログ記事の中で、最先端の AI Agent に要件を提示する際、指揮官のように具体的な手順を細かく指示するだけでなく、最終目標、背景にある理由、優先順位のトレードオフを明確に伝えるべきだという見解を述べている。

核心的な変化：AI はもはや「おバカ」ではない、欠けているのは全体の背景だ

• 過去の AI（熱心な愚か者）：やるべきことを極めて具体的に指示する必要があった。たとえば「クラス B にメソッド A があるので、クラス C から F にそれぞれ同等のメソッドを追加してください」といった具合であり、そうでなければ完全に間違った処理をしてしまう。
• 現在の最高峰モデル：脱線するのは通常、理解できなかったからではなく、こちらの意図に対して誤った前提を置いたためだ。たとえば GPT-6-Astra は、コードが自分専用だと考えると、スペースやフォーマットを省いた圧縮コード（minified code）を書いてしまう。Flask の作者である Armin Ronacher は、モデルがツールを呼び出す際に token を節約しようとして極力短い書き方を身につけ、それがコミット対象のコードに漏れ出たのではないかと推測している。彼の試算によると、このように書かれたユニットテストは、フォーマットされたものに比べて約 10% の token を節約できるという。また彼は、誰も見ていないように見えるプロセス（サブAgent の作業やテストコードなど）ほどこうした書き方が現れやすいことにも気づいたが、モデルが本当に誰も見ていないと思っているのかは定かではないとも述べている。逆に、誰かがコードを読むのだと伝えさえすれば、人間が読めるコードを書いてくれる。Sean がこれを使って Go を書かせたところ、数千行の「許容できる」コードが得られた（彼が試したのは Go のみである）。人間が書いたコードベースの中であれば、その一言すら添える必要はなく、周囲のコードスタイルに自ら従う。

重要な運用ルール：「なぜ」と「トレードオフ」を伝える

• 大局的な目標を明確にし、実装アプローチを性急に固定化しない：具体的な技術仕様をいきなり投げつけるのではなく、最終的に何を解決したいのかをまず明確に説明する。やり方をガチガチに固定してしまうと、モデルはそれに従うしかなくなり、目標に沿ったより適切な解決策を見つけ出す手助けができなくなる。Sean が Deckard プロジェクトを立ち上げた際、プロンプトの約半分の分量を背景説明に費やした。Webページの AI コンテンツを自動で非表示にするローカルプログラムまたはブラウザ拡張機能を作りたいこと、短期的には MacBook を発熱させず、バッテリーを使い果たさない検出モデルを探す必要があること、そしてこれは自分自身が使うためのものであることを伝えたのだ。
• 裁量の余地を残し、最適解の取りこぼしを防ぐ：自身の技術的な構想を書いてもよいが、命令ではなく議論の出発点として提示すべきだ。Sean はプロンプト内で EditLens と RoBERTa をあくまで「私の推測」として記載するにとどめ、末尾には「もし私の目標を達成するより良い方法があれば教えてほしい、相談しよう」という一文を添えた。もし当初から明確な技術仕様として固定してしまっていたら、後に採用されることになる native messaging や Gradient モデルを見逃していただろう、というのが彼の判断だ。このプロジェクトは Sean と Astra が共同で進めたもので、彼が大枠の方向性の決定を担当し、自身があまり詳しくないものの、より適した言語を選択することさえできた（推論には Python ではなく C++ を採用）。一方モデルは、ローカル HTTP の代わりに native messaging を使用するなど、彼自身では思いつかなかったアプローチを提示した。
• 「相対的な優先順位」を明確にする：実務で技術要件を提示する際、バグの少なさ、可観測性、既存コードへの優雅な統合、パフォーマンスをすべて列挙して「どれも重要だ」と言ってはならない。Sean の実践方法は、専用の段落を設けてこれらにどのような優先順位があるのかを説明し、どれをそれほど重視しておらず他に譲っても構わないかを明示することだ。そうすることで、複数の目標が衝突した際に、モデルはどれを妥協すべきかを把握できる。書き方のイメージ（当サイトによる例）：「今回最も重要なのはバグを持ち込まないことであり、次に重要なのは既存コードへ自然に馴染ませることです。可観測性は現状維持で構いません。パフォーマンスは重点事項ではないため、上位2つのために多少犠牲にしても構いません。」
• 「XY 問題」に注意する：XY 問題とは、真に解決したい課題が X であるにもかかわらず、その解決策は Y だと思い込み、Y の方法だけを尋ねてしまうことを指す。典型的な例として、「ファイル名の末尾3文字を出力する方法」を質問し、詳しく問い詰めて初めて拡張子が欲しかったのだと判明するケースがある（拡張子は .jpeg のように必ずしも3文字とは限らない）。現代のモデルは、提示された全体目標に対して有益なアドバイスを提供できるほど十分に賢くなっている。背景を伝えずに具体的な技術仕様だけを渡すのは、病院に行って特定の薬の飲み方だけを尋ねるようなものであり、医師がより適切な治療法を見つける手助けはできなくなってしまう。

完全な例：Sean が Deckard のために書いたプロンプト

Deckard は Sean と Astra が共同で制作した Chrome 拡張機能であり、Mac 上でローカルに動作する小型モデルを呼び出して、Webページ内の AI が書いた疑いのあるテキストを自動的にハイライトする。プロンプトに登場する Pangram は、現時点でほぼ唯一の実用的な商用 AI テキスト検出サービスであり、EditLens はそのモデルである。Runpod は、Sean が MCP を経由してモデルに提供したリモートの計算リソースであり、ローカルで実行するには発熱が激しすぎる、時間がかかりすぎる、または遅すぎる実験を実行するために使用された。プロジェクトの開始にあたり、彼は以下のようなプロンプトを送信した。

英語原文

Hello. You should have Runpod access via MCP (if not, tell me and I’ll fix it).

I have the long-term goal of building a local program or browser extension to automatically scan pages I load for AI content and hide it. I have the short-term goal of figuring out the best AI detection model I can run on my macbook without killing my battery or making it hot, and (relatedly) figuring out how to run the model most efficiently. My guess is that Pangram’s EditLens 3B or the smaller Roberta model might be a good place to start, though they might require quantizing and will definitely require some work to make them run as efficiently as possible on my macbook.

I would like you to use my Runpod account to start answering these questions. Eventually we’ll move to doing things on this macbook pro, but my hope is that Runpod can help with some experiments that are too hot/long/slow to run locally. You are a smart model; if you can see a better way to achieve my goals, please let me know and we’ll talk about it. Good luck.

日本語訳

こんにちは。MCP 経由で Runpod にアクセスできるはずです（もしできなければ、教えてください。私が修正します）。

私の長期的な目標は、読み込んだページから AI 生成コンテンツを自動的にスキャンして非表示にするローカルプログラムまたはブラウザ拡張機能を構築することです。短期的な目標は、MacBook を発熱させたりバッテリーを消耗させたりすることなく実行できる最適な AI 検出モデルを見つけ出すこと、そして（それに関連して）そのモデルを最も効率的に実行する方法を見極めることです。私の推測では、Pangram の EditLens 3B や、より小型の RoBERTa モデルが良い出発点になるかもしれませんが、それらは量子化が必要になる可能性があり、私の MacBook 上で可能な限り効率的に動作させるには間違いなく一定の作業が必要になります。

これらの問いへの答えを探り始めるために、私の Runpod アカウントを使ってほしいと思います。最終的にはこの MacBook Pro 上での作業に移行しますが、ローカルで実行するには発熱が激しすぎる、時間がかかりすぎる、あるいは遅すぎる実験について、Runpod が役立ってくれることを期待しています。あなたは賢いモデルです。私の目標を達成するためのより良い道筋が見えたら、私に知らせてください。一緒に検討しましょう。幸運を。

このプロンプトを詳しく見ると、約半分の分量が背景の説明に割かれている。プロジェクト全体の目標、これが仕事用ではなく自分自身で使うためのものであること、そしてノートPCを発熱させず、バッテリーを使い果たさないことなどだ。

このプロンプトでは、どのモデルを選ぶべきか、そして発熱や電力消費を抑えながらいかに MacBook 上で動かすかという 2 つの点を尋ねている。Deckard が最終的に導き出した答えは以下の通りだ。

• どう動かすか：モデルが示唆した native messaging を採用し、別途ローカルの Web サービスを立ち上げることなく、Chrome 拡張機能からマシン上のモデルプログラムを直接呼び出すようにした。使用時にのみ起動し、5 分間使わなければ自動的に終了する。実行時のメモリ消費量は 400MB–1.2GB で、ブラウザのタブを 5〜6 個余分に開くのとほぼ同等だ。Sean は MacBook Pro の発熱やバッテリー低下に気づかなかったが、別のマシンであれば結果が異なる可能性もあると述べている。
• どのモデルを選ぶか：当初推測していた EditLens は採用せず、Gradient の MLX 4-bit 版（圧縮され、Apple のコンピュータ上で動作可能なバージョン）を選択した。このモデルは約 52% の AI テキストを検出し、人間が書いた文章を AI と誤判定する確率は約 2.7% だった。商用サービスの Pangram は 99.66% を検出し、誤判定はわずか 0.004% だと自称しており、大きな開きがある。しかし Sean はこれで十分だと考えている。1本の記事のすべての文を漏れなく捉える必要はなく、数箇所ハイライトされれば疑いを持つには十分だからだ。ただ誤判定が約 2% あるため、単一のマーキングを決定的な証拠として扱うことはできない。