「動く」ことと「価値を生む」ことは違う
記事の中で繰り返し出てくる概念がある。「運用エントロピー」とでも呼ぶべき状態の増加だ。タスクを明確に渡したはずのエージェントが、古いマイグレーションを現行仕様だと勘違いし、対症療法で症状だけを塞ぎ、自分の履歴をコンテキストに積み上げていく。数回ツールコールを重ねたあたりから、次のステップの確度は最初のほうより下がる。
ここに人間の手で入る価値が生まれる。失敗するテスト、厳密なデータコントラクト、決定論的なツール、そして「何が間違っていたか」を明示する評価——これらがフィードバックの信号になる。エージェントは確かに運動を生成する。だが、その運動を意味ある仕事に変換するのは、周囲に張られた制約の網のほうだ。
もうひとつ効いてくるアナロジーが「無限の猿定理」。エージェントはコンパイラとリポジトリとテストを持つ賢い猿で、やっていることは「提案→実行→観察→修正→再挑戦」の反復だ。入力スキーマと出力スキーマが固定されていて、コードベースが小さく、失敗を捕まえるテストが揃っていれば、ループは収束する余地を持つ。逆に言えば、エンタープライズのような巨大で静けさの少ないシステムでは、その収束条件を整えるのが人間の側に残されている。
個人開発に翻訳する
LaravelとDockerで小さなプロダクトを運用している側の話に置き換えると、見え方が少し変わる。エンタープライズほどの巨大な検索空間を持たないぶん、エージェントが回りやすい「静けさ」は自前で作りやすい。今のプロダクトで効きそうな打ち手を、自分用のチェックリストとして書き出す。
まずテストを先に書く。AIエージェントに渡す前に、期待する振る舞いをPHPUnitで固定する。境界線が言語化されていると、エージェントの「次の一手」がぶれにくい。次にマイグレーションとスキーマをコードに寄せる。DBの状態をREADMEや記憶ではなく、Laravelのmigrationファイル一意にする。エージェントが「現在の仕様」として参照できるソースが一つになる。
そしてDocker Composeで再現可能なループを回す。ローカルでもCIでも同じコンテナでテストが走る状態にしておくと、フィードバックの往復速度がそのままエージェントの精度に効く。APIを持つサービスなら、入力と出力の形をOpenAPIかPHPの型定義で明示しておく。エージェントが推測で形を作る余地を塞ぐ、というのも同じ理屈だ。
記事に流れる「フィードバックが次の試行を導く」という原則は、そのまま個人開発の運用ルールに翻訳できる。
次に試したいこと
ぼく自身、ここ数週間で「エージェントにどこまで任せるか」の境界線を少しずつ引き直している。正直に言って、まだ答えは出ていない。プロダクトの規模感によって、境界線の引き方が違って見えるからだ。
ただ一つ感じているのは、「エージェントが壊せない境界」を引くのは、結局のところプロダクト設計そのものだということ。Laravelのルート定義ひとつ取ってみても、どこにバリデーションを置くか、どこで認可を担保するか——そこに書かれた境界が、エージェント時代の安全性になる。
今夜のお題を一つだけ決めて、この稿を閉じる。自分のプロダクトで「エージェントに踏み入れられたくない一線」を、とりあえず一本だけ書き出してみる。そこからまた検証のはずだ。