0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Claude Code Harnessと長いAI作業の費用

0
Posted at

KarpathyがClaude Code Harnessに関する長い記事を共有したことは、小さな合図に見えて大きな意味を持っていた。AIコーディングの重心は、気の利いたプロンプトから実行システムへ移っている。プロンプトはモデルに助けを求める。Harnessはモデルに作業場所、記憶の跡、道具、確認点、そして一つの会話を超える仕事を続けるためのリズムを与える。

この変化は、harness方式がなぜ魅力的なのかを説明する。同時に、それがまた一つのtoken消費装置に見える理由も説明する。私たちがAI代理により多くの責任を渡すほど、AI代理はより多くの文脈を読み、保存し、比較し、検証し、整理しなければならない。夢は自律的な前進である。請求は、計画のtoken、道具出力のtoken、引き継ぎのtoken、検証のtoken、整理のtokenとして届く。

なぜ共有が重要だったのか

Karpathyは、作り手の行動を変える考えを見分ける有用な信号になっている。彼がClaude Code Harnessの議論に注目したことが重要なのは、実用上の真実を指しているからだ。AI代理の次の性能向上は、モデル自体だけでなく、モデルを取り巻く枠組みからも生まれうる。

Claude Codeは、この枠組みがなぜ重要なのかをすでに示している。AnthropicはClaude Codeを、コードベースを読み、ファイルを変更し、テストを実行し、コミット済みのコードを届けるシステムとして説明している。これはチャットの回答とはまったく違う体験だ。モデルは中心にあるが、周囲の作業手順が、モデルが何を見るか、どの道具に触れるか、いつ止まるか、どう進捗を残すか、どう完了を証明するかを決める。

harnessに関する長い文章は、同じ点をさらに鋭くしている。長く走るAI代理の仕事は、よくある形で失敗する。十分な文脈を集める前に始める。計画から外れる。文脈窓が埋まると不安になる。複雑な仕事を小さく見せて避ける。弱い検査を書き、早すぎる成功を宣言する。古い文書と矛盾した状態を残す。Harnessは、こうした失敗を見過ごしにくくするために存在する。

タスクから生まれる実行フレーム

最も面白い考えは、harnessがタスクに合わせて作られるべきだという点だ。小さな不具合修正、研究まとめ、フルスタックアプリ、科学作業の流れを同じ運用形式で扱うのは難しい。それぞれのタスクには、それぞれの実行フレームが必要である。

コーディングのタスクなら、そのフレームは機能一覧、進捗ファイル、initスクリプト、各セッションが一つの機能だけに取り組む規則を作れる。デザインのタスクなら、計画者、生成者、評価者を置ける。研究のタスクなら、出典マップ、主張表、最後の矛盾確認を作れる。利用者は目標を説明する。AI代理はまず、仕事を正直に保つ足場を作る。

ここに方式の力がある。曖昧な依頼が具体的な作業環境に変わる。タスクは分割される。未知の点には名前が付く。停止条件は書き残される。検証は生成から切り離される。新しい文脈を持つ評価者は、前の進み方に縛られにくい状態で結果を見られる。AI代理の仕事が人間の点検できる成果物を残すため、監督もしやすくなる。

費用も明確だ。すべての成果物はtokenを使う。すべての評価工程はtokenを使う。すべての引き継ぎ要約はtokenを使う。弱いharnessは手続きのためにtokenを浪費する。良いharnessは高価な失敗を防ぐためにtokenを使う。

token経済

大事な問いは、harnessが多くのtokenを使うかどうかではない。使う。大事な問いは、追加のtokenが信頼性、速度、そして人間の介入の少なさを買っているかどうかである。

小さな仕事では、モデルだけでも速く安く答えられる。しかし仕事が多くのファイル、多くのセッション、多くの判断に広がると、安い対話はしばしば高い手戻りへ変わる。Harnessは最初に多く使うことで、後から隠れた誤りの代金を払わずに済むようにする。

これはAI代理の作業手順ですでに見えている。リポジトリを読むことはtokenを使うが、文脈を飛ばすと誤った計画が生まれる。進捗ファイルはtokenを使うが、状態を失うと次のセッションがプロジェクトを再発見しなければならない。別の検証者はtokenを使うが、同じAI代理に自己評価させると弱いテストが生まれやすい。整理はtokenを使うが、乱れは次のタスクを難しくする。

token消費装置という表現は、harnessが規律なく膨らむときには妥当だ。けれどharnessが人間の調整、プロジェクト管理、テスト設計、コードレビューを肩代わりするなら、評価は変わる。実用的な尺度はtokenあたりの成果である。Harnessが十倍の文脈を使い、重大な偽の完了を一つ防ぐなら、その費用は低いかもしれない。美しい手順メモだけを作り、最終結果がもろいままなら、それは計測される雑音である。

作り手に役立つ型

良いharnessは小さく、タスクに敏感である。第一に、文脈収集を強制する。AI代理は計画の前に、重要なファイル、出典、制約、未知の点を特定するべきだ。第二に、見えるタスク台帳を作る。台帳には、試したこと、通ったこと、失敗したこと、残っていることが見える必要がある。第三に、検証を独立させる。確認役は、テストしやすい振る舞いではなく、依頼された振る舞いを評価する。第四に、前進した後で作業場所を整理する。文書、使われないコード、古い前提もタスクの表面に含まれる。第五に、token予算と停止規則を置く。自律性は、いつ続けるか、いつ尋ねるかを知るときによりよく働く。

この型はコードの外でも重要だ。研究者はMiss Formulaを使って数式画像を使える数学表記に変換し、ChatGPTGeminiに解釈を比較させ、その後Editable FigureでAIが生成した論文図を編集可能なベクトル形式に変換できる。同じharnessの論理が当てはまる。入力を保持し、主張の流れを保存し、出力を検証し、最終成果物を編集可能に残す。

より大きな意味

harnessの議論は信頼についての議論である。人々が求めているのは、自信ありげに話すだけのAI代理ではない。方向を保ち、制約を尊重し、自分の状態を見せ、失敗から戻れるAI代理である。タスクから作られる実行フレームは、その要求への一つの答えである。

そのフレームはtokenを使う。使うべきだ。長い仕事には記憶、確認、調整が必要である。重要なのは、てこになる場所にtokenを使うことだ。KarpathyがClaude Code Harnessの議論を共有したことで、単純な教訓に注目が集まった。AI作業の未来は、モデル、道具、そしてそれらをつなぐ規律ある運用システムによって形作られる。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?