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?

AIエージェントに必要なのは「指示」ではなく「継投」だった。開発を野球の采配で回す話

0
Posted at

はじめに

私は野球が好きすぎて、野球分析の資格まで取ってしまったエンジニアです。

そんな人間がAIエージェントを業務で使い込んでいて、ある日ふと気づいてしまいました。

「これ、完投を狙わせるからダメなんだ。継投すればいいんだ」

1人のAIエージェントに、設計から実装、テスト、ドキュメントまで一気にやらせて、途中でおかしくなる。皆さんも経験ありませんか? あれは野球で言えば、エースに月曜から日曜まで毎日完投させている状態です。人間なら誰も許さない起用法を、私たちはAIに平気でやらせています。

この記事では、「AIエージェント運用は投手起用と同じ」という視点で、私の開発の回し方を紹介します。半分ネタに見えて、わりと本気の運用論です。

先発完投型の限界

まず、多くの人がやりがちな使い方から。

「この機能、設計して実装してテストも書いてドキュメントも作って」

これが先発完投型の起用です。序盤は素晴らしいピッチングをします。ところが、会話が長くなるにつれて(=球数がかさむにつれて)明らかに球威が落ちてくる。

  • 序盤に自分で決めた設計方針を、終盤に忘れる
  • 前半に書いたコードと矛盾する実装を平気で重ねる
  • 修正を頼むと、関係ない場所まで「ついでに」書き換え始める

人間の投手が100球を超えると被打率が上がるように、AIエージェントもコンテキストが長くなるほど制球が乱れます。これはモデルの性能の問題ではなく、起用法の問題です。

疲れているエースに「頑張れ」と声をかけても抑えられないのと同じで、劣化したセッションに「ちゃんとして」と言っても直りません。交代させるしかない。

私の継投プラン

というわけで、現在の私の「投手運用」です。

役割 野球で言うと 任せる仕事 交代の目安
先発 ゲームを作る 機能実装の本体 1機能ごとに降板。引っ張らない
スコアラー 相手チームの分析 ライブラリ調査・技術比較 試合(実装)が始まる前に仕事を終える
中継ぎ 火消し テスト失敗やビルドエラーの修正だけ 火が消えたら即降板
抑え 最終回のマウンド 差分レビューと指摘のみ。実装はさせない 1試合1イニングのみ
監督 ベンチの采配 人間(私)。方針決定・続投判断・責任 交代なし

ポイントは3つあります。

1. スコアラーと選手を兼任させない

調査させたセッションでそのまま実装に入ると、調査で読み込んだ大量の情報がコンテキストに残り続けて、実装の精度が下がります。偵察部隊の情報はレポート(Markdownファイル)にまとめさせて、先発にはレポートだけを渡す。試合前のスコアラーミーティングと同じです。

2. 抑えには絶対に実装させない

レビュー役のエージェントに「ついでに直しといて」をやらせると、レビューの厳しさが消えます。指摘する人と直す人が同じだと、自分に甘い判定になる。打者兼審判は成立しないのと同じです。

3. 続投判断だけは監督(人間)の仕事

「もう1イニング行けるか、代えるか」。ここをAIに委ねることはできません。同じ修正指示を2回出して2回とも的外れな答えが返ってきたら、それが交代のサインです。私はこれを2失点ルールと呼んで機械的に運用しています。粘って3球目を投げさせるより、新しいセッションに引き継ぎメモを渡して交代させる方が、結果的に早い。

名采配は「諦めの早さ」でできている

野球の名将の采配を分析していて面白いのは、成功の采配より、損切りの采配の方が勝敗に効いていることです。

AIエージェント運用もまったく同じでした。私の生産性が上がったのは、プロンプトが上手くなったからではなく、「このセッションはもうダメだ」と見切る基準を決めたからです。

逆に、私がやってしまった采配ミスも晒しておきます。

  • エースの酷使:調子が良かったセッションに愛着が湧き、タスクが変わっても使い続けて崩壊。「昨日良かったから今日も行ける」は、野球でもAIでも根拠になりません
  • 敗戦処理にエースを投入:どうでもいい定型作業に、わざわざ丁寧なコンテキストを積んだメインセッションを使ってしまう。もったいない起用でした
  • 監督が打席に立つ:AIの出力が気に入らず、結局全部自分で書き直す。それは采配の放棄です。指示(サイン)の出し方が悪かったと考えて、サインを見直すべきでした

ファーム(AWS)の話も少しだけ

この「継投」の考え方、実は個人の工夫の話にとどまらなくなってきています。

たとえばAWSのBedrock AgentCoreのようなエージェント基盤は、まさに「複数のエージェントに役割を分けて、監督(オーケストレーター)が采配する」構成をマネージドで組める仕組みです。私が手動でやっている継投を、球団のシステムとして仕組み化するイメージですね。

つまり「1人の万能AIに全部任せる」時代から「役割分担されたチームをどう編成するか」の時代に、業界全体が移っている。個人の開発スタイルで継投に慣れておくことは、そのまま次の時代の設計スキルになると思っています。

おわりに:エンジニアは監督になる

AIエージェント時代のエンジニア像として「AIを使いこなす人」という言い方をよく見ますが、私は「ベンチで采配する監督」の方がしっくりきています。

監督は自分でボールを投げません。でも、誰をいつ出すか、いつ諦めるか、負けたら誰が責任を取るか——そこは絶対に譲りません。

  • 完投させない。役割を分けて継投する
  • スコアラー、先発、抑えを兼任させない
  • 続投判断(2失点ルール)だけは人間が握る

皆さんのチームの「継投プラン」や「うちの2失点ルールはこれ」があれば、ぜひコメントで聞かせてください。他球団の采配、純粋に見てみたいです。

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?