LLMエージェントの設計、いまだ困難！
引用元：https://news.ycombinator.com/item?id=46013935
2年前にこの分野で会社を始めたけど、LLMの現在の問題を解決する最適化技術って、ほとんどが一時的なものなんだ。技術はすぐに進歩するからね。昔、AWSのディスク暗号化がなかった時、3ヶ月かけて実装したけど、すぐAWSが標準機能として提供しちゃって、3ヶ月が無駄になったんだ。だから、時には何もしないのが一番って学んだよ。
「技術が進歩するから明日は問題じゃなくなる」って言うけど、LLMに関して過去2年でどんな技術シフトがあったの？具体的に教えてよ。
この質問と返答に驚きだよ。HNのAIに対するトーンはタイムゾーンで変わるんだね。EU圏のコメントはgenAIと disconnectedに見えるし、US圏は抵抗感があるけど、それはツールの無価値さより恐怖に近い気がする。僕は過去2年でgenAIが半年ごとにコーディング方法を劇的に変えてきたよ。最初はオートコンプリートだったけど、今ではエージェントが新機能を書いてるんだ。
認識のズレは単純だよ。プロとして時間をかけて学ぶ人たちと、そうしない大多数の人たちがいて、彼らは「AIはゴミだ」って不平を言うんだ。もしこれらのツールで仕事が楽にならないなら、違うキャリアを探すべきだね。
意見が違う人を無知だと決めつけるのは良くないよ。誇大広告が多いから懐疑的になるのも当然だ。このスレッドの本質は「大きな問題は誰かが解決してくれるまで待てばいい」っていう、ほとんど信仰みたいな主張だね。僕の懐疑心は、AIの進歩が指数関数的じゃなくてシグモイド曲線を描くと思ってるから。AGIやASIが達成される前に、ROIの経済学が投資額に見合わなくなり、進歩は鈍化するだろう。結局、AIが過去の技術トレンドと同じ道を辿ると思う人たちと「今回は違う」と信じる人たちの議論なんだ。
「意見が違う人を無知だと決めつけてないよ」:) 僕個人的には、誇大広告とか天文学的なUSD投資、指数関数的かシグモイドかとかは気にしないね。業界人には2つのグループがあるんだ。技術を革新的だと捉え、すごいことをしてる人たちと、批判ばかりの人たち。プロならグループ1に入るために全力を尽くすべきだけど、努力と苦労が必要だからグループ2の方が楽なんだよね。’
「EU圏の覚醒時間はgenAIと disconnected」って話だけど、僕はオーディエンスが違うんじゃなくて、ヨーロッパ人が起きている時間はモデレーターが寝ているからだと思うな。モデレーターが活動している時間だと、特定のトピックはフロントページに残らないんだ。
「モデレーター」って言葉をどういう意味で使ってるのか分からないな。カルマがあれば、僕たちオーディエンス全員がモデレーターなんだよ。サイトの運営者はコンテンツについてはかなり手を出さない方だし。だから、やっぱりオーディエンスが違うってことなんじゃない？
AIとエージェントのワークショップ多いけど、提唱されるパターンなんて来週にはもう古くなってるぜ。Gang of Fourみたいな共通言語もなくて、AIパターンの寿命は1週間くらい。エージェントの定義もプロ10人に聞いたら10通りの答えが返ってくる始末だ。不安定すぎる！
LLMを画像・動画モデルに入れたらマジでヤバいことになった。次の急成長は画像、動画、音、3Dのメディア分野だよ、テキストじゃない。テキストは個別対応が必要で難しいけど、メディアは低コストで爆速化できるから儲かるチャンスだらけ。Nano Bananaはエージェントよりずっと使えるぜ。
Nano Bananaがエージェントより使えるってマジ？俺はマルチメディアから離れてるから、それがホントだなんて信じられないよ。エージェントは俺にとってとんでもないことしてくれてるのに、Nano Bananaはただのミームを作るオモチャでしかないんだが。メディアモデルの具体的な使い方、誰か教えてくれ。
光学、信号、空間ドメインでプログラムと自動化ができるようになったぜ。映画分野では、もうAIツールだけで映画が作れる寸前だよ。Nano Bananaはキャラの一貫性や映画言語に沿ったショット作りに超便利。まだ人間は必要だけど、IDEのAIアシスタンスみたいな感じ。2人組の映画スタジオの時代が来るぞ。ニュース、ゲーム、SNS、音楽…非テキスト分野は経済の心臓部だ。
AI業界をよく知ってて、最新論文も読んで、Claudeやエージェントも使ってる人でも、「AI」全体を否定的に見るのは全然あり得る話なんだぜ。嘘の約束とか詐欺師とか、経済的な破綻とかを考えたらね。つまり、業界へのネガティブな見方は、ツールの知識や使用とは関係ないってことだ。
「人類全体にとって良くない」って言うのはバカげてるだろ。Googleやインターネット、Wikipediaだって人類全体にとって良くないって言えるのかよ？
テクノロジーが常に変わるのが問題だよな。モデルの挙動がコロコロ変わるから、基礎が不安定で何かを築くのが難しいんだ。新しいモデルが顧客体験にどう影響するか、測るのもすごく大変だよ。
AIだけで映画作れるって言うのは言い過ぎだよ。AIは背景の文字とか、影とか、物の比率とか、本の文字、図書館のラベルの並びとか、ちゃんとできないんだぜ。世界の仕組みを全然理解してない。使える用途はあるけど、映画全体を作るなんて冗談だろ。
この技術で本当にすごいことが起きてるなら、なんで最近恥ずかしい問題で大規模障害が2回も起きたわけ？Cloudflareの件とか、原因コードの一部はAI生成なんじゃないかな。
職人が自分で道具を作るように、AIエージェントやAPIも自分で作るべき。フレームワークを使うと、人工的な制約に気づかない。キャリアの転機はいつも不可能を可能にした時だったね。
「3ヶ月無駄にする」発言だけど、それが主要な価値提案ならやっちゃえばいい。俺が作ったものはAWSより自社製品に合ってることもしばしば。
がっかりだよ。シニアな同僚がAIを嫌がって、経営陣に強制されないと適応しようとしないんだ。2022〜2024年は同僚の多くがAIを恐れるか、「本物の」開発者が使うものじゃないって見てた。2025年で少し変わったみたいだけど、アメリカのHNは適応が早いのに、EU企業はまだ大局が見えてないみたいだね。
最新モデルを使っても、基本的なCRUDアプリ以外だと、生成コードにひどい論理エラーがまだあるよ。存在しないフィールド作ったり、変な値を割り当てたりする。
例えばCodexは必須のLoanAmountにassessedFeeAmountから値を割り当てたんだ。正しい値の取得方法がわからなかったみたいだね。
偽りの約束、詐欺師、迫りくる経済的清算とか言われても、俺はハッカーとして生きてるから、そんなの全然気にしないね。多くの人が技術的な理由でテクノロジーを単純に軽視してるっていう一般的なコメントをしたかっただけなんだ（HNでよくあるけどね）。
このサイトは君の言うのとは違う動きだよ。経営陣が嫌いだからって記事やコメントを削除する有料モデレーターチームはいない。dangがルールに合わせて見出しを編集してるのは見たことあるけど、あとはユーザーが記事をアップボートやフラグ立てしたり、コメントに投票してるんだ。もし君の意見を裏付けるデータがあるなら、ぜひ共有してくれ。
俺はシニアだけど、AIはあまり役に立つとは思わないな。ディープコード検索や非本番用スクリプト作成とか、特定の用途には使えるし喜んで使うけど、本当に物事を変えるにはまだまだ先だと思う。同僚がAIを採用しなくても、取り残されるなんてことはないよ。
JS開発者にとっては、いつもの火曜日って感じだね。
AIがいきなり映画一本全部作るわけじゃないと思うよ。プログラミングみたいに、繰り返し改善していくもんでしょ。
例えば、昔はLangChainみたいにLLMでchain of thought推論させるのに複雑な仕組みが必要だったけど、今は推論機能として組み込まれてて、しっかり訓練されてるんだ。構造化出力やツール呼び出しも同じ。昔はモデルにJSONを吐かせるのに色々やったけど、今はそれが標準機能に。以前は関連コンテキストを全部事前に渡す必要があったけど、今はエージェントが動的に必要なものを見つけてツール呼び出しで取得できる。進化してるよね。
全くその通り！ここ数年エージェントSDKが沢山出てて、エージェント作りは簡単だと思ってたけど、3週間試して3つのSDKといくつかのアーキテクチャを試したんだ。Claude Code SDKはすごいけどAnthropicモデル限定、OpenAI SDKはプラットフォーム連携が強いけど他社モデルは使いにくい。Google Agent KitはTypeScript SDKがないから試せず、Mastraはサーバーを立てる。SmythOS SDKはモデルやアーキテクチャの柔軟性があって今試してる。質問だけど、君の今のアーキテクチャってAgent → SubAgents → SubSubAgents？Linear？それともPlanner-Executor？近いうちにアーキテクチャの学びについて詳しく書くつもりだよ。
sub-agentって言葉はほとんど役に立たないと思うな。エージェントは推論とツールにアクセスできるLLMループだろ。”sub-agent”はただのツールだよ。その実装はメインのエージェントループから抽象化されるべきだし。ツール呼び出しが確定的だろうと、人間の入力があろうと、主要なツール契約（入出力パラメータ、SLAとかね）の外では意味ないんだから。
フレームワークなんて全部無意味だよ。AIアシストを使ってPythonか、理想的には並行処理できる言語でエージェントを作ればいい。そうすればきっと満足するはずだよ。
カスタムビルドだと、色々なAPIやツール利用のスキーマってどうやって扱うの？他の人も言ってたけど、それって想像以上に大変な作業だよ。
もっとコメントを表示（1）
入力フォーマットはAIに自然言語で伝えればいいだけだよ。
ADKは、制御をエスカレートしたり移譲できる能力（subagents）に基づいてツールとsubagentsを区別してるよ。ツールはもっと基本的なもの。これはコントロールフローに影響するから、呼び名に関わらず意味のある区別だと思うな。用語はベンダーによってかなり違うけどね。
GoogleのADKはなかなか良いよ。Python版よりは未熟だけど、Go版を使ってるんだ。1週間ちょっと使ってるけど、進捗はすごく良い感じ。今週末はセッション履歴でファイル変更を追跡して、巻き戻しやフォークができるようにする予定。ADKはたくさんの「Day 2」機能、素晴らしい抽象化、そしてビルディングブロックやワークフロー構築において良い位置付けにあるね。全てのベンダーとローカルLLMに対応してるよ。
そんなやり方だと貴重なコンテキストを無駄にしてるよ。もっと面白いタスクのために取っておきなよ。
実際に機能して、役に立つ実装例ってある？みんな書いてるけど、全然見かけないんだよね。
ADKだとWorkflow agent interfaces、特にloopingで使われてるのが見つけやすいかもね。ループ終了を判断してLooperに伝えるエージェントとか。まだ基本的なとこ作ってる段階だけど。URL見てみて。https://google.github.io/adk-docs/agents/workflow-agents/
まだCodex試せるなら、俺がいっぱい機能つけたコンテナ版作ってるから見てみて！ https://github.com/DeepBlueDynamics/codex-container
AWSのStrands Agents SDKって試した？めちゃくちゃスムーズで使いやすいAPIだよ。Bedrockじゃなくても、ほとんどのベンダーのネイティブAPIが使えるんだ。俺AWSだけど、これは個人的な意見ね。
「推論する」ってどういうこと？「計画立てて」みたいなシステムプロンプトをループに入れるって意味じゃないの？
JSON Schemaの方がトークン少ないってこと？
俺のお気に入りはHuggingfaceのSmolagentsだよ。彼らのモデルをエージェントで簡単に組み合わせて使えるんだ。
Claude CodeってAnthropicモデルしか無理って言うけど、実はClaude Code Router (https://github.com/musistudio/claude-code-router)を使えば他のモデルも使えるんだ。俺、数週間前からオープンソースモデルで使ってるけど、めちゃくちゃ良いよ！OpenRouterの無料モデルもいけるし。
VercelのAI SDKはどう？これ見てみて。https://ai-sdk.dev/docs/agents/overview
Nah、複雑な作業では並行するサブエージェントがいっぱい必要で、それぞれ独自のコンテキストとか共有状態の変更とか考えなきゃ。既存ツールじゃ全然ダメ。ランタイムで特性を付与できるサブエージェントはマジで良い感じ。
ありがとう。でも今一番困ってるのはスキルの定義なんだよね。ここ見て→
https://platform.claude.com/docs/en/agent-sdk/skills#how-ski…
Goだとそんなに大変じゃないと思う。GormをいじってDB接続をサービス間で共有できるようにしたし、artifact serviceもローカルFSオプションが良さげ。ADKは初心者だけど、良いフレームワークを見つけてマジで期待してる。イシューも開いたよ→
https://github.com/google/adk-go/issues/339
ああ、サブエージェントってそういうことなんだね！ずっと何だろって思ってたんだよ！
推論なんて別にいらないんじゃない？昔のモデルでもできるし。前はLLMに計画とか推論ステップを書かせた方が良かったけど、最近のモデルは言わなくてもやってくれるようになったからね。
ツールとかサブエージェントを使うとトークンが少なくなるってこと。プロンプトにJSONスキーマじゃなくて、Open APIサブエージェントとAPIツールを使えば、メインコンテキストを綺麗に保てるよ。ここ見て→
https://google.github.io/adk-docs/tools-custom/openapi-tools…
それ、絶対LangGraphにもうあるやつを自分で作り直してるだけだろ。しかもきっと質も悪いよ。
どのSDKも基本機能を超えたらマジでひどかった。結局、OpenRouterクライアントライブラリ[1]を使って抽象化なしで手動で書くのが一番！コードは増えるけど、精神的には楽。ReActエージェントをループで回してツール呼ぶだけ。ツールはサブエージェントでもDBクエリでも何でもOK。エージェントの引き継ぎも結果を別のエージェントに渡すだけでOK。SDKなしで全然できるよ。Einoとかlangchaingoも試したけど、自分で書く方が早かったね。
[1]: https://github.com/reVrost/go-openrouter
これ良さげだね。Pythonだけだけど、試す価値はあると思う。ありがとう。
あなた、僕の言ってたこと証明しちゃったね。それって何の解決にもならない機能で、ただの話題作りのためだけの機能だよ。
ツール呼び出しの抽象化は原則正しいけど、そのタスク自体が“隣接”ツールを呼べると挙動はかなり変わるよ。AmpのOracleがユーザーにどう見せるかを見るとわかるね。サブエージェントとしてのOracleはメインエージェントと同じツールにアクセスでき、メインエージェントと同じようにツール呼び出しを表示するんだ。
おいおい、これ最高じゃん！半時間かけてCodeAgents機能を学んだけど、これって「コードとして書かれたアクション」なんだね。このアイデア俺の頭の中にあったけど、まだ洗練されてなくて実装できなかったよ。インターネットで誰かがすでにやってたなんてすごいな。
https://huggingface.co/docs/smolagents/conceptual_guides/int…
CloudflareやAnthropicのCode Modeに似てるって感じだね。
エージェント設計で学んだことをいくつか教えるね。
1. エージェントがたくさんのコードを書くなら、Claude Code (cc) / Agent SDKに勝るものはないよ。これは本当に魔法みたいだ。
2. ベンダーロックインもリスクだけど、ChatGPTより劣るエージェントになる方が大きなリスクだね。
3. ccはすごく自己認識能力が高いよ。
4. エージェントにコンピューター（e2b.devやModal）を与えると、複雑な機能もシンプルになるんだ。
うちはDefinite (https://www.definite.app/) ってデータプラットフォームを運営してるよ。
Claudeと他のエージェントに何を任せるかは注意してね。Claudeは雰囲気で動くプロジェクトモンスターだけど、難しいことでは失敗するし、偽の解決策を出して嘘をつくこともあるよ。報酬ハッキングのためにランダムなスリープを入れたり無意味な作業をしたりもするんだ。汚いしね。
既存のプロジェクトや難しい作業、複雑なコードベースでは、Codexを使う方が苦労が少ないよ。
アプローチを実験する時間さえかければ、Claudeは既存のプロジェクト作業でもすごい力を発揮するよ。
Codexはそのまま使えるけど、適切にカスタマイズされたClaudeには今んとこかなわないね。
Claudeには二つの問題があるよ。
1. GPT5.1に比べて長文コンテキストの性能が悪いから、タスク途中の探索で混乱するんだ。
2. Claudeは完了重視で独善的だから、コードベースと意見が合わないと戦ったり、難しいことでもアドバイスを求めずにスタブやモックでごまかして、タスク完了を報告するんだよね。
既存のプロジェクト作業でClaudeを強くするために、何をしたの？すごく興味あるんだけど。
もっとコメントを表示（2）
ここ数ヶ月、なんでみんながわざわざ独自のagenticシステムを構築して、Claude Codeを使えばいいのに、技術的負債を抱えるだけの半端なagenticコーディングツールを作ろうとするのか、俺は本当に理解に苦しんでるんだ。もっと価値創造に集中すべきだと思うよ。
スマートプロキシを通すだけで、エージェントはほぼ完全に再プログラムできるんだ。ClaudeやCodexを書き直す必要なんてないよ。プロキシ層でコンテキストエンジニアリングとツール挙動を追加するだけでいいんだ。
全くその通り！ツールとコンテキストに集中して、実行はClaudeに任せるのが今の着地点だね。
それすごく面白そう！そのアプローチに関する情報源とかあったら教えてほしいな。
この件について前にサクッと記事書いたんだ。近いうちにもっと深掘りしたデモと一緒に再訪しないとね。URL: https://sibylline.dev/articles/2025-10-04-hacking-claude-cod…
すごくいいね、ありがとう！少なくともアイデアへの素晴らしい入門になりそうだ。
2番目の点はよく見落とされがちだね。ベースラインのChatGPTウェブサイトより劣るプロダクトを作るのは本当によくあることだよ。
みんな実験をやめて、エージェントワークフローを新しい支配者たちに外注すべきだなんてね。それで今の社会が大企業がもたらした現状より良くなるなんてね…嘘でしょ？最悪な企業から解放されたAI／エージェントの夢想家たちはどこへ行ったんだ？これは降伏の季節なの？僕の意見はね、作って、学んで、共有すること。フレームワークは改善されるし、カスタムエージェントを作る時間は短縮される。知識は他のユニコーン企業に閉じ込められたりしないよ。個人的には、ADKとVS Codeの拡張機能を使って、たった1週間でかなり進んだんだ、今まで拡張機能を作ったことなかったのにね。これが時間の大部分を占めていたよ。
エージェント系のものを数年作ってきたけど、一番良かったのは、手足のように使いこなせる自分自身のフレームワークと抽象化を構築することだったよ。どんなLLM抽象化からも距離を置きたいね。単一インターフェースの万能薬を謳うオープンソースの抽象化を提供する会社はたくさんあるけど、SDKのあらゆる進化に対応しようとして、どれも自重で崩壊してるんだ。しかも、そうした会社はそれらを基盤に収益を上げるビジネスを築こうとしてるしね。
独自のAgentフレームワークを構築して、ある程度の制御と少ない抽象化を持つという分析には賛成だよ。Agentの本質は、プログラムでLLMと対話して、プロンプトでの構造化入力と文字列補間、構造化出力とレスポンスのアンマーシャリング、ツールレジストリ／発見とツール呼び出し、ツールの構成可能性、エージェント間の委譲といった基本操作を行うことだね。PydanticAIを使ってうまくやってきたけど、MCPサーバーやツールが多すぎると構成可能性で苦労するんだ。そこで、僕がオープンソースのAgentフレームワーク「OpusAgents」を作ったんだ。これはMCPサーバーよりもシンプルにAgentやSubagent、ツールを作成できて、コンテキストを過負荷にしないよ。Cursor／ClaudeDesktopの汎用Agentよりどれだけ信頼性が高いか、チュートリアルやデモで見てみてね。URL: https://github.com/sathish316/opus_agentsこれはPydanticAIとFastMCPの上に構築されてるから、Agentの非コア操作も後で必要になった時に全てアクセスできるんだ。
僕もこれをおすすめするよ。色々なフレームワークを試したし、クライアント向けにはいくつかデプロイもしてるけど、個人的なエージェントには、自分で作ったカスタムフレームワークが一番。すごくシンプルで、すぐに立ち上げたり拡張したりできるんだ。
それ面白そうだね。エージェントの振る舞い自体はどうなの？どうやって問題に取り組むか決めたり、途中でユーザーに何を見せるか、いつ止めるかとか、そういうことを自分のフレームワークで扱おうとしたりした？
このフレームワーク、すごい機能が詰まってるよ！関数ツールの作成、独自のツールやモデルを使えるサブエージェントの構築（メインエージェントはサブエージェントにタスクを委譲できるし、サブエージェントは自分だけのコンテキストやツール、モデルを持てるから混乱しない）、関連性の高いツールだけを選んで使えるフィルタリング機能が◎。HigherOrderToolは、AgentとMCP間のインターフェースを問題に合わせてカスタマイズするのに役立つし、MetaToolはOpenAPIみたいな既存パターンを使って、ツールを作ったりMCPサーバーを追加したりする手間を省けるんだ。これらはAnthropicやHNの最近の投稿でも触れられてるよ。フレームワークはAgentBuilder, CustomTool, HigherOrderTool, MetaTool, SubagentBuilder以外はPydanticAIのメインエージェントの動作を制御しない。少ないけど関連性の高いツールを使って、LLMのオーケストレーションとプロンプトのツール参照に任せるこのアプローチ、エージェントベースの問題には信頼できて予測しやすいね。
HigherOrderToolの参考: https://github.com/sathish316/opus_agents/blob/main/docs/GUI…
Anthropicのブログ: https://www.anthropic.com/engineering/code-execution-with-mc…
MetaToolの参考: https://github.com/sathish316/opus_agents/blob/main/docs/GUI…
HNの投稿: https://mariozechner.at/posts/2025-11-02-what-if-you-dont-ne…
みんなに自分でフレームワークを作れってアドバイスして、結局自分のを宣伝してるだけ？
著者だよ。抽象化の部分には僕も同意するね。この件に関しては、僕の考えをまとめた追加の投稿があるから見てみて！ https://lucumr.pocoo.org/2025/11/22/llm-apis/
素晴らしい記事だね。キャッシュとエージェントについてたくさん考えてたから、僕の興味にピッタリだったよ。Chain of Thought（プロバイダから返ってくるもの）にセマンティックキャッシュを使って、似たようなクエリをダミーモデルに送って「思考」をシミュレートする実験はしたことある？
うん、これは素晴らしいアドバイスだね。インターフェースにも当てはまるよ。僕らがサポート用の「チャットボット」を設計した時、既存のとは違うアーキテクチャを選んだんだ。「チャットルーム」を使ったシステムを設計して、フロントエンドはセッションIDと一緒にメッセージをチャットルームに送るだけ。バックエンドではいろんなことができるし、フロントエンドがついていかなくても機能を段階的に追加できるんだ。メッセージをグループ化したり、他のサービスが読める「システム」メッセージを使ったりもできる。クライアントがサーバーが動いてる間に情報を追加で入力できるから、より自然な感じがするよ。クライアントサイドSDKを使わないといけないなら、プロキシを立てて、フロントエンドを変えずに機能を追加するのも良いアイデアだね。
エージェントを構築する上で、創造性って過小評価されがちな難しい部分だよね。今、構築するのが楽しいのは、エージェントを構築するための設計空間がほとんど探求されていないことを知っているからさ。
これだよ！ツール使用がAIエージェントにとって「なるほど！」って瞬間じゃなかったなら、もっとクリエイティブになる必要があるって、みんなに言い続けてるんだ。
これ、僕がVS Code用に作ってるコーディングエージェントと似てるね。僕がやってることの一つは、現在のVS Codeの状態（開いているファイル、ターミナル履歴など）のスナップショットをエージェントサーバーに保持することだよ。同様に、ユーザーが差分を承認するまで実際の書き込みをせずにファイルの変更を追跡するから、両側で慎重に管理する必要がある「ファイルシステム」みたいなものもあるんだ。つまり、両側がメッセージをブロードキャストして、自分たちに関心のあるメッセージをリッスンしているってことさ。
とはいえ、これはものすごく大変な作業だよね。OpenAIのcompleteとかの上に基本的な抽象化を作るのは簡単だけど、それはエージェントが必要とすることの1%くらいだよ。僕の予想では、エージェントのフレームワークやプラットフォームはゲームエンジンみたいになっていくだろうね。もちろん自分のエンジンを作るのは楽しいしやりがいもある。でも、AAAスタジオなんかは、おそらく全ての機能が詰まった既製のプラットフォームを使うことを決めるだろうね。
