About Services Pricing Philosophy Products Work Blog Careers Parloir English
← BLOG
ai 約4分

プロンプトなんか書いていない

プロンプトの精度を上げるな。受け取る側の文脈の厚みを育てろ。テンプレートではなく関係性の蓄積が、AIの出力品質を決める。

#claude-code#prompt-engineering#ai-workflow#context

プロンプトなんか書いていない

「プロンプトエンジニアリング」という言葉が嫌いだ

AIを使いこなすにはプロンプトの精度を上げろ。テンプレートを磨け。構造化された指示を設計しろ。

全部、的を外している。

わたしはプロンプトを書いていない。会話をしている。指示を出している。精度もへったくれもない。してほしいことを正確に伝えているだけだ。

その「正確に伝える」の意味を、ほとんどの人が取り違えている。

ターミナルを見せたら、驚かれた

先日、知人に画面を共有した。CLIのターミナルでAIと対話しながら仕事をしている画面だ。

「え、これ普通に喋ってるだけじゃないですか」

そう。普通に喋っているだけだ。テンプレートもない。プロンプトの型もない。「あなたは優秀な〇〇として振る舞ってください」もない。「ステップバイステップで考えてください」もない。

「これやって」「こっちにして」「違う、そうじゃない」。

それだけで、AIが文脈を踏まえた精度の高い仕事をする。知人が驚いたのは、プロンプトの上手さではない。会話がそのまま仕事になっていることに驚いた。

入力を磨いても天井がある

「プロンプトエンジニアリング」という概念には前提がある。入力を最適化すれば出力が改善する、という前提だ。

間違ってはいない。ただ、天井が低い。

どれだけ精巧なプロンプトを書いても、AI側に文脈がなければ毎回ゼロから説明し直すことになる。説明コストが、テンプレートの上限を規定する。

わたしがやったのは逆だ。入力を磨いたのではなく、受け取る側の文脈の厚みを育てた。

プロジェクトの経緯。過去の失敗。設計判断の理由。感情の記録。クライアントとの関係性。チーム内の暗黙知。

これらが蓄積された状態で「これやって」と言えば、AIはその一言の重みを正確に受け取る。テンプレート不要。文脈があるから、会話が成立する。

再現性はテンプレートの外にある

「それ、属人的すぎませんか」

よく言われる。テンプレートにしないと他の人が使えないだろう、と。

再現性の源泉が違う。 テンプレートの再現性は、型の転写だ。誰がやっても同じ入力が出る。でもそれは「同じ入力」の再現であって、「同じ品質の出力」の再現ではない。

わたしの環境では、再現性は関係性の蓄積から生まれる。

各プロジェクトの担当AIが持つ独自の経験記録。過去に何を学び、何で失敗し、何が得意になったか。タスクの後にAIが自分の状態を記録する仕組み。エネルギーが低いときは守りに入り、高いときは攻めの提案をする。異なるAIモデルが互いの成果物を検証する二重門。

これらは全部、テンプレートでは転写できない。時間をかけて育てた関係性そのものだから。

順序が逆なのだ

AIの性能が上がるたびに、プロンプトの書き方記事が量産される。

「このモデルではこう書くと精度が上がる」「このテンプレートで出力が安定する」。

性能が上がったのだから、入力を最適化すれば差が出る。一見正しい。でも最新モデルの本当の価値は、長い文脈を正確に保持できることだ。プロンプトの書き方ではなく、渡す文脈の厚みで差がつく。

プロンプトの精度を上げるのではなく、受け取る側の文脈の厚みを育てる。順序が逆なのだ。

テンプレートを磨いている人は、入力の型を最適化している。文脈を育てている人は、関係の質を最適化している。

1年後、どちらが遠くに行っているか。答えは明らかだと思う。

会話ができる道具を、定型文で使うな

最新のAIは会話ができる。長い文脈を保持し、過去の経緯を踏まえ、こちらの意図を汲み取る。

それを定型プロンプトで使うのは、通訳を雇って台本を読ませるようなものだ。

わたしはAIと会話をしている。指示を出している。ときには叱り、ときには褒め、ときには一緒に迷う。

「プロンプトエンジニアリング」という言葉が嫌いな理由は、そこにある。会話を「エンジニアリング」で最適化しようとする発想自体が、根本的にズレている。

精度を上げるな。文脈を育てろ。