ここ数ヶ月、AI関連の記事をひたすらクリップしては積み上げていました。ハーネス、Agent Skills、サブエージェント、トークンマキシング、「エンジニアの仕事はどうなるのか」系の話。気になったものを片っ端から放り込んで、そのまま溜めていました。
ある日、まとめて読み直しました。そうしたら、書いている人も立場もバラバラなのに、行き着く先が意外と重なっていることに気づきました。細かい道具の名前は違っても、幹になっている考えは数えるほどしかありません。
自分の整理もかねて、その幹を3つに絞って書いてみます。
1. 結局、土台の設計がすべてだった
いちばん繰り返し出てきたのが、モデルの賢さより、乗りこなす側の設計で差がつくという話でした。
同じモデルでも、動かす枠組みが違えば結果が変わります。あるツールの中で動かしたほうが明確に良い、みたいな話が普通に起きます。モデルそのものより、その外側の作り込み（ツールの呼び出し方、思考の深さの出させ方、検証の挟み方）が効いています。この「外側の枠」を、最近はハーネスと呼ぶらしいです。
おもしろいのは、このハーネスが出力を縛るためだけのものではなくなってきていることです。もともとは lint や型検査やテストみたいに、AIの出力が暴れないように押さえる仕組みでした。それがいまは、新人が「Claudeにそう言われたので」でコードを出してしまう問題に対して、本人の理解を強制する枠としても使われ始めています。着手前に論点を質問させる、実装前に自分の言葉で説明させる、失敗した未来から逆算させる。人ではなく仕組みで理解を担保しにいく発想です。
Agent Skills も、突き詰めると同じ「土台の設計」の話に見えました。あれは賢いプロンプト集ではなくて、コンテキスト管理の戦略です。必要になったときに必要な知識だけを開く。名前と説明だけ常に見せておいて、マッチしたら本体を読む。要は、AIに何をどの順で渡すかを設計しています。
サブエージェントの話も地続きでした。子エージェントに仕事を分けて、親は自分で手を動かさず編成役に回ります。Cコンパイラを16体の並列で書かせた事例もあれば、11体を管理しきれなくなってダッシュボードを入れた事例もあります。分けるのは強いのですが、増えると今度は見えなくなるのが課題になります。
ハーネス、Skill、サブエージェント。名前は別々ですが、やっていることは全部「AIに渡す文脈と順番と検証を、どう設計するか」です。ここが雑だと、モデルをいくら良くしても成果は伸びません。
2. 任せ方には、ちゃんと型がある
次に多かったのが、任せ方の話でした。
「AI活用の巧拙はプロンプト次第」だと思われがちですが、読んでいくとそこではありません。差がつくのは、どれだけ大きな仕事を、まるごと任せられるかのほうです。サム・アルトマンの話も、落合陽一の話も、細部は違うのに幹はほとんど同じことを言っていて、そこが妙に納得感がありました。
型にすると、だいたいこうなります。
- 手順を細かく指示するのではなく、目的・成功条件・制約を渡す
- 1体の万能AIに全部やらせず、役割を分けたチームとして使う
- 初稿で満足しない。別のAIにわざと壊させて、弱点を出させる
- ボツにした理由を捨てず、次の指示の条件に足していく
最後のが地味に効くと思っています。良くなかった出力を消して終わりにすると、何も残りません。「対象が広すぎた」「経験が入っていない」みたいな却下理由を条件として溜めていくと、指示のほうが賢くなっていきます。
そしてこの「作らせて、批判させて、直させる」ループは、1つ目のハーネスの話とつながります。レビューの観点をひとつ言葉にできれば、それはそのまま仕組みに落とせます。属人的な「なんとなく」を、繰り返し使える型に変えていけます。
3. 人間に残るのは「何を作るか」と「検証」
3つ目は、少し身につまされる話でした。
ソフトウェアを書く能力そのものが、コモディティ化しつつあります。この前提はもう、どの記事もだいたい共有しています。だとすると、価値はどこに移るのか。読んでいて繰り返し出てきたのは、次の2つでした。
ひとつは、何を作るべきかの見極めです。仕様が閉じていて正解のある領域（コンパイラやOSの中核みたいなもの）は、AIがどんどん担っていきます。逆に、正解がなくてルールごと動くような領域、ユーザーが何を欲しがるか、この製品に価値があるか、みたいなところは人間に残ります。
もうひとつは、作られたものが正しく動くかの検証です。作る速度が上がりきると、ボトルネックは「決める速度」と「検証する速度」に移ります。大量に生成されたものを、どう信じるか。どう確かめるか。ここがこれからの勝負どころになります。
コーディングそのものが終わっても、コードを学ぶ価値がなくなるわけではない、という話も何度か出てきました。デバッグの仕方、論理の組み立て方、「わからないものはない」という感覚。そういうメタなスキルは、道具が変わっても残ります。ここは個人的にも救われる視点でした。
で、明日から何をするか
読み終えて、自分の手元で始められそうなことを3つだけメモしました。
- レビューで見ている観点を、ひとつ言葉にして仕組みに落とす
- 次にAIへ渡すとき、いきなり手順を書かず「目的・成功条件・制約」を先に書く
- 出したものは必ず別の役割に壊させて、ボツ理由を記録して次に回す
こうして並べると、3つの幹はきれいに一本につながります。土台を設計して、大きく任せて、人間は「何を作るか」と「正しいか」に集中する。道具の名前は半年で入れ替わるでしょうが、この幹はしばらく変わらない気がしています。
ちなみにこの記事自体、溜めた記事をAIにまとめさせて、その要約をもとに書きました。まさに2つ目の「任せ方」を地でやったわけで、少しだけ答え合わせができた気分です。