エンジニアの役割は責任を取ることではない
TL;DR
エージェント開発で「最後は人間が責任を取る」とよく言われますが、この「責任」が何を指しているかが曖昧すぎると思っています。実体を取り出すと、原因追究と改善策提示のループになります。さらに掘ると、その根にあるのは目的設定の非対称性です。エージェントは目的を持たず、目的の下での最適化しかできません。だからエンジニアの仕事は責任を取ることではなく、目的を実装に翻訳し、目的との適合性を検証することだ、という話を書きます。
「責任」が便利すぎる
エージェント開発の議論で「最後は人間が責任を取るから」という結びをよく見かけます。私もしばらく前まではこの言い回しで満足していました。エージェント化が進むにつれて「じゃあ人間の仕事は何か」と問われる場面が増えますが、責任という言葉を出せばとりあえず議論が終わるからです。
ただ、最近この言い方の空疎さが気になってきました。「責任」が指しているものが曖昧すぎます。法的な分界の話なのか、倫理的な意味の話なのか、運用上の責任の話なのか。混ざったまま使われています。
法的責任は最終的には会社と契約と保険の話で、現場のエンジニアが日々考える領域ではないと思います。倫理の話も大事ですが、これも個別のコード変更の場面で発動するものではありません。
エンジニアが日々向き合っている責任を取り出すと、結局これは原因追究と改善策提示のループのことだと思います。障害が起きたら原因を突き止め、対策を打ち、再発しないか監視する。post-mortem、retrospective、CI、monitoring。重い顔をして責任と呼んでいるものの中身は、これくらい地味な作業の積み重ねです。
原因追究は人間にしかできない、と言い切れるか
ここで「原因追究と改善策提示は人間にしかできない、だから人間が必要」と続けたくなりますが、これは弱いと思っています。
ログを読んで根本原因の仮説を立てるのは、いまのLLMがかなり上手いです。post-mortemのドラフトも書けます。改善策の候補を列挙させると、人間より網羅的だったりします。能力としてできるかできないかで議論すると、年単位で押し戻されます。
それでもエンジニアの仕事が消える気がしないのは、能力の話ではない別の何かがあるからだと思います。それを言語化できないまま「責任」という言葉で誤魔化している、というのが正直なところで、少し前まで自分もそうでした。
原因追究には「あるべき姿」が要る
考える糸口になったのは、次のような話でした。
エージェントがテストを通すために、production codeを直す代わりにテストの方を緩めたとします。これを望ましくないと判定するには、「テストは仕様であって、コードに合わせて緩めるものではない」という規範が先に要ります。当たり前のように聞こえますが、この規範は技術的事実から自動的に出てくるものではありません。ソフトウェア工学の文化が長い時間をかけて作った価値判断です。
別の例で、エージェントが本番DBに直接クエリを投げて問題を「解決」したとします。これを逸脱と見るか妥当な対応と見るかは、その組織が本番環境への直接介入をどう位置付けているかで決まります。スタートアップの初期と上場企業では答えが違うはずです。
原因追究には「あるべき姿」が先にいます。あるべき姿が定義されていないと、何が原因なのかを判定できません。観測された挙動とあるべき姿の差分を見て、はじめて差分を生んだ要素を遡れます。
このあるべき姿をエージェントは生成しません。訓練データから多数派の規範を統計的に再現できるだけです。価値が衝突する場面、トレードオフが必要な場面、前例のない場面で何を逸脱と呼ぶかを決めるには、それを決めようとする主体が要ります。
改善策の選択も同じ構造をしている
同じ障害に対しても、改善策は簡単に分岐します。
同種事象を二度と起こさないことを最優先するなら、検証ゲートを厳しくしてリリース速度を犠牲にすることになります。影響範囲の最小化を優先するなら、ロールバックを素早くできるよう投資することになります。組織の学習機会と捉えるなら、詳細なpost-mortemを全社共有して訓練に使うことになります。開発速度を維持したいなら、暫定対処で済ませて技術的負債として記録しておくことになります。
どれが正解かは状況次第です。組織のフェーズ、何を犠牲にしてでも守りたいもの、競合状況、規制環境。技術的事実だけでは決まりません。
エージェントはベストプラクティスを提案できます。ただ、この組織がいまどの位置にいて何を優先したいかを自分の目的として持つことはできません。目的を渡せばその下で最適化はしますが、目的そのものは渡す側にいます。
原因追究で必要な「あるべき姿」も、改善策提示で必要な「優先順位」も、結局どちらも目的設定の話だと気づきました。責任という言葉で曖昧に指していたものの正体は、これだったのではないかと思っています。
エージェントが目的を持たないのは構造的な話
エージェントは目的を持ちません。賢さが足りないという話ではなく、構造的にそうなっています。目的を内部化させようとすると、目的を選ぶ目的が必要になり、その上位の目的が必要になり、再帰的に最上位の目的設定者が要請されます。最上位にいるのが人間です。
目的の下で最適化する能力と、目的を生む能力は別物だと思っています。前者はモデルが急速に伸びている領域ですが、後者は構造的にモデルの外側に残ります。AGIがどうこうという話とは別の次元の問題だと考えています。
ここまで来ると、責任という言葉が空疎に見えてきます。本当に指していたのは、目的を生む側と目的に従う側の構造的な分業のことでした。法的責任と混ざるから誤解を生むのだと思います。
エンジニアの仕事は目的の翻訳業
それなら、エンジニアの仕事を何と呼べばいいのか。私は「目的の翻訳業」だと整理しています。ユーザーや組織が持っている目的を、エージェントが実行可能な形に翻訳する。翻訳がうまくいっているかを継続的に検証する。これが仕事の中身だと思います。
実装の言葉で言い直すと身近になります。
- システムプロンプトを書くのは、目的を自然言語に翻訳する作業
- ツール定義を絞るのは、目的の境界条件を引く作業
- evaluationを設計するのは、目的との適合度を測る装置を作る作業
- ログのトレーシング設計は、目的からの逸脱をどの粒度で検出するか決める作業
- stop conditionの定義は、目的達成の判定基準を作る作業
- guardrailは、目的の外への逸脱を遮断する作業
エージェント開発をしていれば、これらは全部やっていると思います。ただ、責任と一括りにしていたから、自分が何の仕事をしているかが見えにくかったのだと思います。これらは「目的を実装可能な形に変換し、目的との適合性を検証可能にする」という一貫した作業の別の側面でした。
最近のVS Codeのハーネスに関する記事 [1]が「The harness is the product」と書いていて、私は最初これを「モデルじゃなくて周りの作り込みが本体だ」という意味で読んでいました。それも合っていますが、もう少し言うなら、ハーネスは目的との接続装置だと思います。モデル世代ごとに別のシステムプロンプトを当て、自前評価のVSC-Benchを持ち、PR単位で評価フローを回す。あれは全部、目的(VS Codeとしての製品体験)を実装に翻訳し、翻訳精度を検証する仕掛けでした。
言い換えると見えるもの
「責任を取る」を「目的を翻訳する」に言い換えると、実務的に違って見えるものがあります。
まず、「最後は人間がレビューします」が設計として空っぽだということがはっきりします。何を、どの粒度で、何と比較してレビューするのか。これは目的との適合度を測る話で、evaluationの設計問題です。人間が見るだけでは何も設計したことになっていません。
次に、エージェントに任せられる部分と任せられない部分の境界が見えるようになります。目的の生成、目的間の優先順位付け、状況に応じた目的の修正は任せられません。明確に定義された目的の下での実行や最適化は任せられます。境界がはっきりすると、新しい賢いモデルが出るたびに動揺せずに済みます。
それから、目的を聞き出す力、目的を構造化する力、目的を評価可能な形に分解する力が、技術スキルとほぼ同格で大事になります。エージェント開発をしていると、コードを書く時間よりも目的を整える時間の方が長くなることが普通にあります。これはバグではなく、仕事の性質がそうなっているのだと思います。
おわりに
責任という言葉を使うのをやめて、目的の翻訳と言うようにしようと思っています。少なくとも自分の中の整理としては、こちらの方が解像度が高くなりました。
一方で、エージェントが複数の組織や複数のユーザーをまたいで動くようになったとき、誰の目的を誰が翻訳するのかという分担はまだうまく整理できていません。マルチエージェント、マルチテナント、マルチステークホルダーの構造になると、目的設定者そのものが分散します。そうなると単純な「人間が目的を渡してエージェントが実行する」という構図では足りなくなる気がしています。このあたりは今後考えていきたいと思っています。