自動化にこだわるな！成果にこだわれ。AI活用のススメ
最近この連載で、AIを使い倒している人たちの実例をいくつも取り上げてきた。
Claude Codeを作った本人が去年11月からコードを書いていない話。
台本を渡すだけでプロ級のアニメーション動画を作る人たち。
今回はちょっと趣向を変えて、それらを並べて見えてきた「共通の軸」について書きたい。
きっかけは、2つの対照的な数字を見つけたことだった。
ソロで17日、$1M。60人足らずで、数百億円
1つ目は、インディーハッカーとして知られるPieter Levels氏（@levelsio）の話だ。
でも、使っているAIツールは普通だった
面白いのはここからだ。
Pieter Levels氏が使っているのは、特別な独自AIではない。
CursorとClaude Codeという、多くの人が使っているのと同じツールだ。
本人は自分のワークフローをこう表現している。
「Claude Codeを、便利なコーディング補助として使うんじゃない。
サーバーの中に住んでいる従業員として使うんだ」。
つまり差を生んでいるのは「どのAIを使っているか」ではなく、「同じAIをどう使っているか」の部分らしい、ということが見えてくる。
ここ最近、この「どう使うか」の部分に、ちゃんと名前がついていることを知った。
差の正体は「コンテキストエンジニアリング」という技術
コンテキストエンジニアリングという言葉がある。
Anthropic自身の定義を借りると、「LLMが推論する際に参照する、最適なトークン（情報）の集合を、選び取り、維持し続けるための一連の戦略」のことだ。
もう少し噛み砕くと、AIに何を見せるか・どんな形で見せるか・いつ見せるかを設計する技術、ということになる。
これは、これまでよく言われてきた「プロンプトエンジニアリング（指示文の言い回しを工夫すること）」とは、似ているようで軸が違う。
ある解説記事の言葉を借りると、「名詞や形容詞を言い換えているだけならプロンプトエンジニアリングのまま。
エージェントが何のデータを取得するかを変えているなら、それはコンテキストエンジニアリングだ」という。
指示の文面をこねくり回すのではなく、AIが判断材料として何を渡されているか、その設計自体を変える話だ。
これを踏まえて、この連載でこれまで取材してきた実例を見返すと、全員が形は違えどこの「コンテキストエンジニアリング」を実践していたことに気づく。
具体的に4つ、紹介したい。
実践①：手を動かす前に「計画」を材料として渡す
Claude Code開発トップのBoris Cherny氏は、作業の8割を「プランモード」から始めると語っていた。
ターミナルでShift+Tabを2回押すだけで、モデルへの指示に「コードはまだ書かないでください」という一文が差し込まれる。
AIはいきなり実装に入らず、まず計画を練って提示し、それを人間が確認・修正してから、初めて実装に進む。
これはまさにコンテキストエンジニアリングそのものだ。
「何を作るか」という指示だけを渡すのではなく、「まず計画という形で情報を整理させてから渡す」という一段階を挟む設計そのものが、最終的な精度を左右している。
実践②：一回きりの指示ではなく「使い回せる仕組み」を渡す
台本を渡すだけでアニメーション動画を作っていたわっくん氏の例では、本人が「台本の中身は関係ない」と語っていたのが印象的だった。
効いていたのは、Claude Codeに渡す指示書（mdファイル）やメモリに、あらかじめ作り込んでおいた「仕組み」の方だった。
どんな台本（＝素材）を渡しても、同じクオリティで出力できる型を、事前にコンテキストとして仕込んである、ということだ。
一回一回、思いついた指示を打つのではなく、繰り返し使える設計図を先に作っておく。
これも、AIに何を渡すかを設計するという意味で、同じ軸の話だと思う。
実践③：AIを「便利機能」ではなく「渡す権限と裁量」で捉える
Pieter Levels氏の「サーバーの中に住んでいる従業員として使う」という表現は象徴的だ。
従業員だと思えば、細かい作業を逐一指示するより、ある程度の裁量とツールを渡して、判断を任せる場面が増える。
Boris Cherny氏も同じことを語っていた。
「モデルを型にはめすぎない」こと。
道具とゴールだけを渡して、あとはモデル自身に考えさせるほうが良い結果になる、と。
指示を細かく刻むほど良い結果が出る、というのは実は思い込みで、AIに渡す情報の中に「どこまで裁量を渡すか」という設計も含まれている、ということなんだと思う。
実践④：安いモデル・少ないトークンをケチらない
最後はコンテキストの「量」の話だ。
Boris Cherny氏は「安いモデルを使ったからといって、必ずしも安く上がるわけではない」と語っていた。
知能の低いモデルは、同じ作業をこなすのに余計な手戻りやトークンを消費してしまうため、結局は一番賢いモデルを使ったほうがトータルで安く済む、という考え方だ。
Pieter Levels氏の運用でも、データ更新や通知、請求処理、マーケティング分析といった地味な作業まで含めて自動化の対象にしていて、「ここは人間がやる／ここはAIに任せる」の線引きを、かなりAI側に寄せている。
ケチらず十分な情報とリソースを渡すことも、コンテキスト設計の一部だ。
まとめ
ソロで年間$100万規模を17日で達成したPieter Levels氏も、社員60人足らずで年商数億ドル規模のMidjourneyも、使っているAIツール自体は特別なものではない。
差を生んでいるのは「コンテキストエンジニアリング」——AIに何を・どんな形で・どこまで渡すかを設計する技術。
この連載で見てきた実例に共通していたのは、①計画を材料として挟む、②一回きりの指示より使い回せる仕組みを作る、③裁量を渡して任せる、④情報・リソースをケチらない、の4つ。
「AIをどう使うか」というと精神論みたいに聞こえるけど、実際に結果を出している人たちを見ていくと、驚くほど具体的で、再現性のあるやり方に集約されていく。
派手なプロンプトのテクニック集より、この4つの軸の方が、たぶんずっと効く。
最後まで読んでくれてありがとうございます。
「おもしろかった」「これはやばい」と思ったら、スキ（♡）を押してもらえると嬉しいです！
AIのヤバい情報をたくさん投稿するので、フォローもお願いします！
参考・出典
Pieter Levels氏のプロフィール・実績まとめ：YesPress
Pieter Levels氏のAIワークフロー・fly.pieter.com実績：YouMind
Midjourneyの売上・従業員数：Value Add VC
コンテキストエンジニアリングの定義・プロンプトエンジニアリングとの違い：Sourcegraph Blog
Boris Cherny氏のプランモード等の実践（本連載過去記事より）：note
わっくん氏のClaude Code×Remotion実践（本連載過去記事より）：note
彼はNomad List、RemoteOK、PhotoAIといったプロダクトを、従業員ゼロ、たった1人で運営していて、ポートフォリオ全体の年間経常収益は310万〜350万ドルにのぼる。
極めつけは、ブラウザで動くフライトシミュレーター「fly.pieter.com」を一人で作り、公開からわずか17日でARR100万ドルに到達させたことだ。
しかも彼は自分の収益をリアルタイムで公開ダッシュボードに出していて、誰でも数字を確認できる。
2つ目は、画像生成AIで知られるMidjourneyだ。
従業員はわずか60人前後（一時107人いたが、むしろ減らしている）なのに、年間売上は3億〜5億ドル規模。
しかも外部投資家ゼロ、広告費ゼロで、この規模に到達している。
単純計算でも、従業員1人あたり数百万ドルという、テック業界でも異常な効率になる。
