最近 AI 界隈で「プロンプトは終わった、これからはハーネスの時代だ」「メタハーネスが来る」「LangChain で組み合わせる」といった話をよく目にします。SNS では AI 研究者の主張をインフルエンサーが拡散していて、議論としては確かに面白い。

ただ、見ていてどうしてもモヤッとするのは 「で、それを実際の開発現場のどこで使うの?」 という話が抜け落ちていることです。主張そのものに反対したいわけではなくて、地続きの実装シーンが見えてこないので、自分の中で位置づけられないだけ。日記なので結論は出ないと思いますが、書きながら整理してみます。

自分が AI を使っている範囲

仕事でも個人開発でも AI を使っています。最近やろうとしていることのひとつは、エージェントやスキルを固定化して、チームの他の人にも使ってもらえるようにすることです。ハーネスを組んでおけば、要件を入れるだけで AI が一連の作業を進めてくれる、という形を目指しています。

ただ、これが思ったほどうまく普及しません。理由はシンプルで、ハーネスを使う人が要件を把握していないと、ただボタンを押すだけの人になってしまうから。要件を理解している人 = ハーネスを作れる人、という構図になってしまい、結局は作った本人しか活用できない、ということがよく起きます。

「だったらその要件把握と評価まで含めて自動化すればいい」というのが、おそらく研究者の人たちが指摘している方向なんだと思います。実際、ある程度のところまでは自動化できる感覚もあります。でも、人間のチェックが完全にいらないレベルには届かない、というのが今の自分の実感です。

ここで一度整理: 自動化が効くのは「汎用 × 反復」の交わりだけ

実際にハーネスを作って配ろうとしてみて、もう一段整理がつきました。AI による自動化が効くのは 「汎用的」かつ「反復的」 な作業に限る、という二軸の交わりだけ、というのが今の自分の見立てです。

汎用じゃない作業: 結局はプロジェクトごとに作り込むことになるので、自動化基盤を整える時間と、対話で進める時間を比べると、対話の方が大抵早い
反復じゃない作業: そもそも何のために自動化するのかが分からない。一回切りのことに、エージェントもスキルもいらない

逆に、汎用 × 反復 が成り立つ領域はちゃんとあって、自分自身も使っています。例えば:

汎用的なコーディング規約を持たせたスキル
汎用的なレビュー観点を持たせた評価サブエージェント
スモークテストや E2E の常時実行
ハーネス自体の自動最適化 (評価指標を決めてループさせる)

このあたりは 評価関数が明確で、繰り返し回すこと自体に価値がある タスクなので、自動化の旨味がよくわかります。これらは確かに「自動化」と呼んでよい範疇です。

ただ、これは研究者やインフルエンサーが「ハーネスの時代」「全自動開発」と言っているスケールの話とは、だいぶかけ離れている気がしています。彼らが想定している全自動は、もっと 設計から実装まで人間チェックを抜いて夜中に走らせる 系の話に聞こえる。そこに違和感があります。

「寝てる間に開発」って、どんな開発の話なんだろう

引っかかっているのは、ここから先の主張です。「人間が寝ている間に AI が開発をまるごと進めてくれる」という未来像。

大規模開発の現場でも、いまはマイクロサービスで責務が分割されていて、1 サービスあたりのコードベースもコンテキスト量もそこまで巨大にはなりにくい構造になっています。それを 1 セットでまとめて、設計から実装まで全自動でやらせる というのは、汎用化の難しさとコンテキスト量の両面で、現実味が薄く感じます。

そもそも 「寝ている間に走らせたい」ほど時間のかかる開発って何だろう、という疑問もあります。先に書いた汎用 × 反復に当てはまる作業なら納得できるのですが、それ以外で「人間の関与なしに長時間走らせる価値があるタスク」は、自分には具体的に思い浮かびません。

もちろん、自分が思いつかないだけで、それが刺さる現場はきっとあるはずです。ただ、SNS で見かける議論からは、その現場の輪郭がどうしても見えてこない。だからモヤモヤしています。

少し調べたら、自分の仮説と実例の答えが噛み合ってきた

ネットで実例と研究者の最近の発信をひと通り眺めてみました。AI 関連は1年前の記事ですら陳腐化しているので、できるだけ直近 (2026年3〜4月) のものを見ています。すると、案外 自分の感覚と近い報告がすでに並んでいる ことに気づきました。

例えば Andrej Karpathy が 3 月の No Priors ポッドキャストで、「自分は AutoResearch では human in the loop を抜いて2日で 700 実験回す。でも普段の開発は監督・指揮役」 と話していました (No Priors: Code Agents, AutoResearch, and the Loopy Era, 2026-03-20)。Karpathy 本人ですら、評価が閉じる狭い領域でだけ完全自動を許して、それ以外は人間が指揮する という線引きをしていたのは意外でした。SNS のインフルエンサーが拡散しているスローガンよりも、ずっと現場寄りの整理です。

利用者側の体験記も生々しいものが出てきています。Claude Code の Routines を 3 日間運用した Qiita 記事 (2026-04-17) では、停止忘れで初日からトークン消費が想定の 3 倍、GitHub 通知が 2 分で 15 通の暴走、ルーチン重複登録、と 3 つの事故が同時に起きたことが報告されていました。Uber に至っては 「2026 年の AI 予算が 4 ヶ月で枯渇して計画段階に戻った」 という報告 (2026-04-16) すらあります。「夜中に走らせる」系の話には、ほぼ必ず注意書きが添えられているのが、いまの景色です。

それから個人的に印象に残ったのは、Anthropic 自身が 4 月 23 日に 「Claude Code の品質劣化はハーネス側の問題でした」 と認めた事後検証です。デフォルトの effort 設定変更、推論履歴を落とすバグ、冗長性を上げたプロンプトでコード品質が劣化、をまとめてロールバックした、という話。「モデルが劣化した」と感じていたものの正体が、実はモデル外の足回りだった という公式認定でした。SNS で見る「最近の Opus 性能ダウンしたよね」議論も、けっこうな割合がこういう細部の話だと思います。だからこそ、ハーネスの議論を抽象的にやる前に、まずこういう地味な細部から積むべきだとも感じました。

LangChain の Harrison Chase も最近のインタビューで、「エージェントは最終成果物ではなく、PR・要約・サポート対応の "first draft" を出すのが効く。最終承認は人間」 という整理をしていました。さらに評価系として「人間が trace にアノテーションして LLM-as-judge を align する」アプローチを推しています。要するに 評価系の構築コストが、自動化を成立させる前提 だ、という話。LangChain の発信ですら、"全自動" は前提にされていません。

これらを並べてみると、完全自動が成立しているのは、ざっくり 次の 3 つの条件のどれか を満たす場合に絞られそうです。

入出力が機械検証可能で、要件が明確な定型タスク (セキュリティ修正、コードマイグレーション、ドキュメント生成など)
読み取り中心で副作用が少ないドメイン (インシデント調査のように、複数エージェントで状況を並列に読みに行ってレポートを返す使い方)
そもそも検証可能な領域 (競プロや数学のように、答え合わせが機械的にできる領域)

これらは全部 「汎用 × 反復」の交わり に入っています。Karpathy の AutoResearch も、Harrison Chase の "first draft + Align Evals" も、結局この交わりの中で「人間チェックを部分的に抜く」という設計でした。「寝ている間に新機能が完成している」という未来像は、まだベンダーの理想像であって、現場では再現されていない、というのが2026年5月時点で見える率直な像です。

ちなみに「ハーネス」という言葉のもとになった定義として、Mitchell Hashimoto (HashiCorp 創業者) の 「エージェントがミスするたびに、二度とそのミスができないよう環境を作り直すこと」 という言い方が業界で引用されているそうです。これがとても腑に落ちました。ハーネスとは抽象的な万能装置ではなく、個別の失敗を環境側に閉じ込めていく地味な作業の積み重ね だ、という定義。これなら自分の現場感とも矛盾しません。

結局、自分の使い方は「対話」のまま

汎用 × 反復に当てはまる狭い領域を除けば、応答を見ながら対話で進めるほうが、いまのところ品質も納得感も高い というのが自分の実感です。エージェントに丸投げするより、AI と話しながら自分の頭も整理していく感覚に近い。

「プロンプトは終わった」という主張を見るたびに、自分の手元ではむしろプロンプト (というか対話) の比重が上がっているなあ、と思いながら、今日も Claude と話しています。

ハーネスやメタハーネスを 抽象的な万能装置として語る記事 ではなく、自分の現場で、どの失敗を環境に閉じ込めたか を書いた記事をもっと読みたいなあ、というのが正直なところです。