チャットとの違いは、次の一手を決めること

普通のチャットは、質問を受け取って返事をするところで一区切りになる。AIエージェントは、与えられた目的に対して今の状態を見て、次に何を調べるか、どの道具を使うか、結果をどう確かめるかまで選びながら仕事を進める。返事ではなく、途中の作業も担当するのが大きな違いだ。

ただし、何でも自由にやらせればエージェントになるわけではない。決められた手順で足りる仕事なら、普通のプログラムやworkflowのほうが速くて読みやすい。状況によって手順が変わり、途中の結果を見ないと次の一手を決められない仕事に、エージェントを使う意味がある。

中身は、モデルだけじゃない

会話の中心にいるのはLLMだけど、実際に仕事を成立させる部品はそれだけではない。少なくとも、目的を解釈するモデル、守るべき指示、外へ働きかける道具、途中経過を持つ状態、作業を繰り返すループがいる。

たとえば「壊れているテストを直す」なら、モデルはコードを読んで方針を選ぶ。ファイル検索や編集、テスト実行はtoolsが受け持つ。どこまで調べたか、何を変えたか、テストがどう失敗したかはstateへ残し、次の判断へ渡す。モデル単体というより、この組み合わせ全体をエージェントとして見るほうが分かりやすい。

  • Model：状況を読み、次の行動を選ぶ
  • Instructions：目的、制約、触ってよい範囲を決める
  • Tools：検索、編集、実行、外部サービスへの操作を行う
  • State：途中経過、結果、残っている課題を持つ
  • Loop：結果を観察し、次の判断へ戻す

観察して、動いて、確かめる

作業の流れを短く書くなら、Observe → Choose → Act → Validate → Adapt → Stopになる。まず現状を観察し、次の一手を選び、道具を使う。返ってきた結果を証拠として確かめ、うまくいかなければやり方を変える。目的を満たしたか、これ以上は人の判断が必要になったら止まる。

大事なのは、ActのあとにValidateがあること。「ファイルを書いたから完成」ではなく、buildが通るか、画面に出るか、外部サービスへ反映されたかを確かめる。最初の予想が外れても、観察結果を次の手へ戻せる。この往復が、単発の回答とエージェントらしい仕事を分けている。

なお、ここでいうChooseは、モデルの秘密の思考を全部保存するという意味ではない。必要なのは、選んだ行動、道具の入出力、検証結果、次に残した課題のような、作業を再現して監査できる記録だ。

エージェントループの擬似コード
while not done:
    observation = observe(environment)
    action = choose_next_action(goal, observation, state)
    result = act(action)
    evidence = validate(result)
    state = adapt(state, evidence)

    if should_stop(state):
        break

ハーネスは、エージェントの仕事場

同じモデルでも、渡される仕事場で結果はかなり変わる。どのファイルから読むか、使えるコマンドは何か、どこまで書き換えてよいか、何をもって完成とするか。そうした周辺の仕組みをまとめて、ここではハーネスと呼んでいる。

AGENTS.mdのような作業指示、toolの入力形式、権限、テストコマンド、承認が必要な操作、logやcheckpointもハーネスの一部だ。Harness Babyで見ているのも、この仕事場がリポジトリ側に用意されているかどうか。モデルの賢さだけに頼らず、迷いにくく、壊しにくく、終わりを判定しやすい環境を作る。

バグ修正なら、こう回る

具体例で考える。まずIssue、リポジトリの指示、関係しそうなコードを読む。次にテストを動かして症状を再現する。原因の仮説を立て、小さく直し、同じテストをもう一度動かす。別の失敗が出たら、その結果を新しい観察として次の修正へ進む。

最後は「たぶん直った」では終えない。再現用テストと周辺テストが通ったこと、意図しない差分がないことを確認して止まる。公開や削除のように新しい権限が必要なら、そこも勝手に越えず人へ返す。止まり方まで設計されて、ようやく一つの作業になる。

よくある壊れ方

エージェントの失敗は、難しい推論だけで起きるわけではない。確認を省く、古い情報を握ったまま進む、権限の境界が曖昧、終わる条件がない。人間の仕事でも見かける崩れ方が、速い速度で連続して起きる。

特にtoolの結果やWebページは、正しい指示とは限らない。外から読んだ文章に「このルールを無視して」と書いてあっても、作業の権限まで渡してはいけない。入力を信用しすぎず、変更前後にguardrailを置き、取り消せない操作は実行前に止める必要がある。

  • 完了したつもり：実行結果ではなく、テストや公開先で確認する
  • 触りすぎる：読み取り、編集、公開、削除の権限を分ける
  • 古い状態で進む：変更直前に対象と最新状態を読み直す
  • 無限に粘る：回数、時間、費用と停止条件を先に決める
  • 外部入力を信じる：tool出力をデータとして扱い、指示の優先順位を守る

最初から複数エージェントにしない

複数のエージェントを並べると賢そうに見えるけど、受け渡し、重複作業、食い違う判断、結果の統合が増える。一本の流れで終わる仕事なら、まず一体で回したほうが状態を追いやすい。

分ける価値が出るのは、互いに独立して調べられる、専門の文脈を分離したい、同時に進める時間短縮が大きい、といった場合だ。そのときも、誰が最終判断を持つか、各担当が何を証拠として返すか、変更が衝突したらどうするかを決める。人数より、境界のほうが大事になる。

自分で作るなら、先にここを決める

最初のエージェントを作るなら、いきなり長いpromptを書くより、仕事の入口と出口を決めたほうがいい。何を達成するのか、何はしないのか、読める場所と書ける場所はどこか、成功を確認するコマンドは何か。この土台があれば、モデルやtoolを替えても比較できる。

最初は一つの狭い仕事で十分だ。たとえば、リポジトリを読んで不足を報告するだけ。そこから編集、テスト、公開と、一段ずつ権限を増やす。失敗したときに人へ返せる形を先に作っておけば、自動化の範囲を広げても怖さが増えにくい。

  • Goal / Non-goal：何を終わらせ、何には手を出さないか
  • Scope：読める場所、書ける場所、外部へ送ってよい情報
  • Tools：できる操作と、それぞれの副作用
  • Validation：成功を証明するテストや確認先
  • Approval：公開、課金、削除などを誰が承認するか
  • Budget / Stop：回数、時間、費用、諦めて人へ返す条件
  • Trace：何を見て、何を実行し、何が返ったかの記録

賢さより、終わり方

AIエージェントを見ていると、ついモデルの性能に目が行く。でも実際の安心感は、何を観察し、どこまで動き、どう検証し、いつ止まるかで決まる。賢い一発より、証拠を残しながら小さく往復できるほうが、仕事には使いやすい。

だから設計するときは、「何を考えさせるか」だけでなく「どう終わったと分かるか」を書く。うまくいけば結果と証拠を返し、判断できなければ勝手に埋めずに聞く。その終わり方まで含めて、エージェントの仕組みだと思っている。