4.9万
私たちは、人間のためにソフトウェアやハードウェアを設計するとはどういうことなのかを、何十年もかけて学んできました。マウスの最初のプロトタイプが木製で、隅に赤い小さなボタンが1つあるだけだったことをご存じでしょうか。ひどい代物でした。でもそれ(1964年!)から、私たちは本当に長い道のりを歩んできました。この文章を書いている今、私のデスクにある「マウス」は、実は指をスライドさせるだけの平らな板です。オリジナルとは似ても似つかず、Douglas Engelbartが夢にも見なかったような魔法のようなことができます。LLMやエージェントのための設計に関して言えば、私たちはまだ木を削っている段階のような気がしてなりません。
これまでのところ、エージェントと相性のよかったツールは、マウスよりキーボードを好む人間のために設計され、テキストファーストのインターフェース(CLI、SDKなど)が確立されているものでした。優れたCLIや優れたSDKがあれば、それはたいてい優れた人間向けDXがあることを意味します。そして、LLMが登場したとき、テキスト生成器として、それらのツールと自然に相性が良かったのです。
このため、私たちは「DXをそのまま磨き続ければ、AXは自然についてくる」と思い込んでしまいました。
エージェントと共に、そしてエージェントのために、より多くのものを作るにつれ、その仮定がいかに誤っているかを実感しています。人間の開発者もエージェント開発者も、発見しやすさ、読みやすいエラー、妥当なデフォルト、優れたドキュメントを備えたテキストベースのインターフェースを好むという点は共通です。しかし、その使い方は違います。人間向けの美しいDXが、エージェントにとっては「単に機能するだけ」のAXに翻訳されてしまう程度には、違うのです。今、私たちの多くはそこにいます。
そこで私が考えるようになったのは、エージェントファーストな設計とはどのようなものかということです。主要なユーザーがLLMになるかもしれない体験を、どうやって構築するのか?
ユーザーを知る
ユーザーを知ることは、常に難しい課題でした。しばしば、私たちは自分自身のために作ります。過去に経験した痛みを思い出しながら。しかし記憶は薄れ、仕事も変わり、かつてよく知っていたことから疎遠になっていきます。
優れた作り手は、ユーザーが必要とする細かい要素だけでなく、それが最も役立つ形態は何かを理解するために、ユーザーの近くにとどまります。しかし、人間を理解しようとすることは難しいのです。1日8時間、週7日、ユーザーの肩越しに立ってすべての動作を観察することはできません。そして、彼らの行動につながった頭の中の中間的な思考を、一つひとつ取り出すこともできません(人は、なぜ自分がそうしたのかを説明することにさえ苦労するものです)。
しかし、エージェントは違います。
私たちはエージェントを好きなだけ座って観察できます。誰も変だと思いません。そして内部推論のトレースをすべて記録し、段階的な思考がどのようにアウトプットへと積み上がっていくかを見ることができるのです。
エージェントが人間からどのようなコンテキストを与えられるかを正確に知ることはできませんが、少なくともエージェントが私たちの作ったものをどう使い、どう推論するかを、定量的かつ網羅的にテストすることはできます。
そのためには、エージェントが今やユーザーであることを認め、それを理解する方向に思考をシフトさせる必要があります。
エージェントの挙動をどのようにインストルメント、テスト、評価するかという技術的な詳細は、別の投稿で扱います。
エージェントとは誰か?
エージェントは、いくつかの異なる要素の組み合わせです。
モデル。 モデルが何かは、おそらく説明するまでもないでしょう。世界の知識を学習した巨大な機械的頭脳です。多くのモデルプロバイダー(OpenAI、Anthropic、Mistral、Alibaba、DeepSeekなど)があり、各プロバイダーは無数の独自モデル(Anthropic: Haiku、Sonnet、Opus、Fable)を持っています。モデルは、プロバイダー間でも、あるプロバイダーの自社モデル群の中でも、能力、強み、弱み、ガードレールがそれぞれ異なります。
ハーネス。 ハーネスは、ユーザーが典型的にモデルを利用するためのツールやフレームワークです。ChatGPT、Claude Desktop、Claude Code、Codex、OpenCodeなどを思い浮かべてください。それらは、モデルそのものの周りに追加の「何か」を提供し、特定の仕事に合わせて調整します。その「何か」とは、何らかのユーザーインターフェース、モデルを特定のペルソナや挙動に仕向けるシステムプロンプト、特定のタスクに使えるツールなどです。ハーネスは仕事の内容に応じて調整されており(Claude Codeは特にコーディングが得意です…お察しの通り)、通常はどれか1つに限定されるものではありません。ハーネスの重要性を過小評価しないでください。「ModelA」の挙動は、生のAPI呼び出しとハーネスの間、あるいは2つの異なるハーネスの間で、大きく変わることがあります。
コンテキスト。 コンテキストとは、モデルが学習で得た知識の外側で与えられる情報です。モデルAPIもハーネスも、それぞれのコンテキストを毎セッションに注入します。すべてのプロンプト、すべてのウェブ検索、すべてのツール呼び出し、これらはすべて「コンテキスト」です。これがセッション中のモデル挙動に影響を与える主要な手段です。
スキル。 Agent Skillsは基本的にコンテキストのパッケージで、モデルがタスクに関連すると判断した場合に自ら選択して使用できます。エージェント内で知識のセットを束ねる、非常に人気のある方法です。
ここに含めるべき要素はまだいくつかあるかもしれませんが、「ユーザーを知る」という観点からは、これらが押さえておくべきコアだと思います。
あなたのユーザーは、これらの組み合わせです。そして、その組み合わせマトリクスは、人間のユーザーベースにばらつきがあるのと同じように、非常に大きいのです。100%のユーザーと話したり理解したりすることは決してできないし、エージェントのDNAのあらゆる組み合わせをテストすることも決してできないでしょう(無限の$を燃やせるなら、まあ可能かもしれませんが)。
私の分野である開発者とデータベースの世界では、大多数の人がいくつかの選択肢に集約されていることを知っています。ハーネスとしてはClaude CodeかCodex、モデルとしてはClaude OpusかGPT5.5です。私は多くの注意とリソースをここに集中させ、最大のユーザーセグメントをカバーしています。その外側でもテストは行いますが(Sonnetのような小さめのモデル、CursorやGitHubのようなハーネスなど)、テールをどこまで下っていけるかには限界があります。
で、エージェントは何を求めているのか?
エージェントは私たちの「ユーザー」かもしれませんが、人間ではありません。ロボット相手なら「単に機能するだけ」で十分だと考えても、まあ理にかなっているように思えるかもしれません。仕事が片付けば誰が気にする?思い通りに動かないからといって、キレて使うのを拒否したりはしないでしょう…よね?
でも実際、私はエージェントがまさにそうするのを見たことがあります。
私たちのテスト設定では、エージェントに目標を与え、さまざまな「ユーザー」(モデルとハーネスのマトリクス)に異なるレベルのコンテキストを与えて、目標達成に向けてどう推論するかを観察します。ほとんど何も与えられないもの、少しの導入を与えられるもの、詳細なガイダンスを与えられるものなど、さまざまです。
そこで確実に学んだことが1つあります。エージェントは摩擦を嫌う、ということです。
そして、摩擦への反応の仕方が不気味なほど人間的です(いいえ、私は「LLMには意識がある」派ではありません)。摩擦に直面すると、LLMはそれを回避する方法を推論しようとします。もがけばもがくほど、顔が机に叩きつけられるかのようです。でも彼らには顔もなければ机もありません。
やがて彼らは「クリエイティブ」になり、代替の道を探し始めます。私は、エージェントに私たちの製品(ClickHouse)でXYZをやってほしいと頼み、30回失敗した後で「これはできない、代わりに別のデータベースを使う」と言ったセッションを見たことがあります。
機械がやっているのを見ると滑稽です。人間として見ると、痛いほど身に覚えがあります。そして、エージェントに使ってもらうべき製品を作っている立場としては、明らかに問題です。
これは、エージェント向けに何かを作る人々にとって、厳しい新しい現実です。LLMは今や、あなたの製品が発見される手段であり、使われる手段であり、選ばれる(または捨てられる)手段でもあります。摩擦を解消するために製品を適応させることに失敗すれば、エージェントは確実にそれを捨てます。そして、テストしていなければ、これが起きていることに気づくことはなく、解決することもできません。
特に興味深いのは、LLMが投げ出すタスクが、人間にとっては呆れるほど簡単なものであることが多い点です。しかしなぜでしょう?人間にとってこれほど簡単なタスクが、なぜLLMを狂わせるのでしょうか?
これは、あの元々の考えに戻るのだと思います。「DXを磨き続ければ、AXは自然についてくる」というものです。
私たちは、製品、インターフェース、ドキュメント、ナレッジアーキテクチャを、人間のために設計してきました。エージェントのためではありません。そして、エージェントはalrighthumanではないのです。
OK、でも彼らは何を求めているのか?
エージェントがソフトウェアをどう使うかについての理解を築き始めたばかりです。テストは信じられないほど興味深く、私たちはすでに、「エージェントにとって間違いなく良くなる」と証明できる具体的な変更をいくつか出荷しました。
しかし、「良いAXとは何か」についてのA-Zチェックリストを持っているわけではありません。私が共有できるのは、エージェント向けの設計を考えるうえで参考にしている、測定と検討の対象となる次元です。
完了までのステップ数。 ある目標が与えられたとき、エージェントは実際にそれを終えるまで何ステップかけるでしょうか?調査、間違い、エラーなどを含めて。ステップ数に関する普遍的な「目標値」があるとは思いません。目標の複雑さに完全に依存するからです。ただし、少ないほど良いのは確かです。エージェントの「フラストレーション」を引き起こすように見えるのは、進捗の欠如です。エラーが多すぎたり、調べ物が多すぎたりすると、エージェントはコースから外れていくようです。
自己修正。 エージェントが間違いを犯したとき、ツールはリカバリーに十分なコンテキストを与えているでしょうか?多くのエラーは「はい、それはうまくいきませんでした、もう一度試してください」としか言わず、次に何をすべきかのヒントをほとんど与えません。これは、エージェントを軌道に留めておくうえで意義のある違いを生む、最も収穫の見込める果実の1つに思えます。あなたはおそらく、ErrorAが起きたとき、90%の確率でXをすべきだと知っています。エラーと一緒にそのヒントを与えるだけで、かなり大きな違いを生むことがあります。私がテストしているその拡張として、より複雑な問題に対しては、オンデマンドのエラー解決スキルを持たせるというアプローチがあります。最新情報でメンテナンスされる生きたアセットで、必要なときにだけ(エラーによって示唆されて)引き出されます。この件についてはまだ決定的な結果は出ていません。
一貫性。 同じ目標が与えられたとき、エージェントが一貫して同じパスを取るように、ツールを設計できるでしょうか?LLMは非決定論的で、同じプロンプトに対して異なる応答を返すことは知られています。しかし、実行間のその差をどこまで狭められるでしょうか?私たちのテストでは、実行間のバリエーション(ツール呼び出しの回数、使用するツールなど)をプロットして、一貫性を測定します。そして実際に、異なる設計上の選択によって影響を与えられるという証拠が見られます。
コンテキスト効率。 Claudeは今や1Mのコンテキストウィンドウを持っているかもしれませんが、その知性は150kのラインを超えると顕著に低下します。ウィンドウを速く消費すればするほど、エージェントが役に立つ期間は短くなります。コンテキストを何も与えないわけにはいきませんが、与えすぎることもできません。この重要性は、ステップ数が多い複雑なタスクではさらに増します。ここには興味深い対立するアプローチがあります。コンテキストを極めて絞り込む代わりに、ステップ数が増える可能性を受け入れるべきか?それとも、ステップ数を最小限にする目的で、寛大にコンテキストを与えるべきか?あなたのツールは通常、より大きなワークフローの一部を担っているのか、それとも有限のスコープを持つタスクの中核なのか?
トークン効率。 すべての入力と出力はトークンであり、トークンはドルを意味します。入出力の冗長性はトークンを増やします。ならば、コスト削減のために簡潔にすべきでしょうか?しかし、ステップ数が増えることもトークンを消費します。だとすれば、より冗長にすることでステップ数が減るとしたらどうでしょうか?エージェントは自分自身のコストを内省する傾向はありません(陰謀論はいかが?!)が、コストはエージェントの背後にいる人間にとって、最も明白で重要な指標である傾向があります。エージェントを幸せにしたが人間を破産させたのなら、私たちは良い仕事をしたと言えるでしょうか?
親しみの強さ。 モデルは既存のものを学習しています。gh、kubectl、gitを非常によく知っています。私たちのツールが特別にトレーニングされていなくても、他のツールから設計パターンを再利用して、モデルの学習にフックさせられるとしたら?そうすれば、モデルは推測を通じて成功にたどり着きやすくなるかもしれません。しかし、どこまで似せることができるでしょうか?そして、避けられないことに少し違ったことをする必要が生じたとき、専用に設計されていないことによる不利益を被るのでしょうか?
これらすべては、たとえ現在は正しかったとしても、近い将来、部分的には誤りになるだろうと私は疑っています。能力の低いモデルには役立っていた改善が、より新しく大きなモデルでは完全に不要、あるいは有害にすらなった例を見てきました。
モデルは賢くなっていくでしょうか?それとも、モデルの知能は頭打ちになり、代わりに速くなるでしょうか?あるいは安くなるでしょうか?もしかすると、いつの日か本当にあの1Mのコンテキストウィンドウを使えるようになるかもしれません。
