自律型AIは本当に使えるのか？現場で役立つAIの現実！
引用元：https://news.ycombinator.com/item?id=44623207
AmazonのAIエンジニアと話したんだけど、Generative AIを顧客向けチャットで使ってる会社は、人間が必ず介入してるらしい。自動返信は古い技術で、Gen AIはまだ信頼性が低くて、誰も会社の評判をかけてまで使えないってさ。
昔は「古いAI」であるシンボリックAIとか古典的な機械学習を使ったエージェントに興味があったな。でも、いつもTransformer以前のニューラルネットを扱う仕事に就いてたよ。
人間が介在するシステムを構築して、評価・訓練データを集めてから、一部を自動化して品質を向上させるシステムを作るのが大事だね。
多くのテック企業がライブチャットサポートでGen AIを使い始めてるよ。sonder.comとかwealthsimple.comなんかがそうだね。LLMが答えられないクエリは、人間のサポートエージェントに転送されるのが普通だよ。
Air Canadaが昔これをやったんだけど、AIが葬儀の割引請求について間違った手続きを顧客に教えて、顧客が訴えたんだ。Air Canadaは、顧客がAIチャットボットを信用すべきじゃなかったって反論したけど、負けちゃったよ。
それって2022年の話で、LLMが登場する前のことだよ。「負けた」って言っても、482 USDを返済しただけだしね。
変な論点ずらしだね。GPT-3は1750億パラメータのモデルで、2020年には出てるんだから、LLM登場前なんてことないよ。ChatGPTより数週間前ってだけ。それに、「負けた」を引用符で囲む意味が分からないな。金額がどうであろうと、結果に影響はないでしょ。誰も破産するなんて期待してなかったし、元の合意に従うだけだよ。
使えるとは思うけど、問題はみんながAIを「脱獄」させたり、面白い応答を引き出してX（旧Twitter）に投稿したりするかもしれないってことだよ。LLMをFAQ転送ボットにする技術はあるだろうけど、それじゃLLMを使う意味がないよね。
それはサポートを売るための話だね。消費者向けドローンは、ちょっと手の込んだ広告バナーみたいなものだよ。これは、構造化された出力が必要な明確なワークフローの一部じゃないんだ。
多分ね。でも、そういうサービスを売る仕事の人が個人的に知らないってのは、意味深長だよね。
この技術はよく失敗するからさ、バックアップを用意しとけば大丈夫だよ。
Gen AIは人間をサポートするだけって感じ。うちは受信メールのスキャンとか、手書きメモの解析に使ってるけど、信頼性は完璧じゃないから自動応答は無理だね。
顧客にはチャットボットやAIを使いたくないし、データ保護の問題もあるから顧客情報の解析も大変だよ。
AIのコンテキストウィンドウって話が出てないけど、人間は得意分野だとかなり広いよね。LLMは学習データでなんとかするけど、根本的な解決策じゃないんだ。
結局プロンプトでコンテキストを圧縮するしかないのは、まるで呪文を唱えてるみたいで、決定論が失われてるのが問題だね。
人間はコンテキストと“重み”をはっきり区別してないよね。経験で常に“重み”が更新されていくけど、今のLLMは“重み”が読み取り専用だから、それができないのが問題だよ。
LLMは自然言語を使ってないと思うよ。自然言語ってのは生きてて、毎日変わるものなんだ。
LLM界隈の「使い方が悪い」とか「プロンプトが全て」って言うのは、結局プログラミングと一緒だよね。
Kubernetesのサービス名変更とかは便利だけど、APIエンドポイントのソートみたいな細かいのは、プロンプト学ぶ手間がプログラミングと変わらないし、エネルギーもすごい無駄だよ。
「プロンプトが全て」ってのは、まさにその通りだよね。コンピュータに言語で応答を求めるのは“プログラミング”だよ。これはただの高レベルなプログラミングの延長なんだ。これらのシステムは魔法じゃないし、これからもそうはならないだろうね。
そうだよね。LLMの仕組みに、僕らが世界のモデルをどう当てはめるかってのが、いかに難しいかを示したいんだ。LLMと人間の正確さを比較するコメントが多いけど、両者の違いを軽視しすぎてる気がするよ。
正直、人間の“コンテキスト”と“重み”の区別はよくわかんないよね。長期記憶や経験ってのはコンテキストに近い気がする。
楽器を始めたからって数学の問題の解き方を急に忘れたりしないように、人間の“重み”はLLMのコンテキストみたいに簡単に素早く更新されないんだよ。
人間は得意な問題だとコンテキストウィンドウが広いって言うけど、ホントかな？俺は違うよ。複雑な問題だとすぐに自分の“コンテキストウィンドウ”の限界にぶつかるんだ。人間がそんな広いコンテキストウィンドウを持つ問題の具体例を教えてくれない？
人間のコンテキストウィンドウは線形じゃないよ。穴があってもすぐに推測で埋められるんだ。
例えば、小説を読んだ後で別の話を聞かれても、その小説の内容は「読んだ」って思い出せるだろ？
人間は“コンテキストウィンドウ”だけじゃなくて、ワーキングメモリも持ってるからだよ。
もしLLMがクエリごとに重みを更新できたら、コンテキストウィンドウなんていらないはずだ。人間は新しい情報で重みを再学習するけど、LLMの今のアーキテクチャじゃ無理なんだよね。
人間ってすごく大きなコンテキストウィンドウを持ってて、それがギュッと圧縮されてるんだ。選んだPLの標準ライブラリ全部は知らなくても、ドキュメントの抜粋や経験から色んなことを知ってるし、バグとかエッジケースもわかる。それにプロジェクトのドメイン知識や顧客の使い方も含めて、同僚の反応まで推測できるんだ。これら全部を組み合わせて新しいことを生み出せるし、思い出すたびにコンテキストに動的に追加もできる。これは今のタスクだけのコンテキストで、君の全人生の経験の中にある一部でしかないんだよ。
50歳になったら、その人の性格は50年間の経験でできてるよね。つまり人間って、社会で”顔”を出す問題（社交のこと、人間が特に得意なやつ）を解決するために、何十年にもわたるすごく大きなコンテキストウィンドウを持ってるってことなんだ。
人間って作業を進める前に、途中でチェックポイントを設けて確認するじゃん？人間も100%正確じゃないからね。きっと未来のAIエージェントも、このチェックを組み込むように学習すると思うんだ。さらに進む前に、”この部分は99%正しくないとダメだ”みたいな簡単なリスク評価まで含めるようになるんじゃないかな。
Claude Codeってまさにそういうことするんだよ。常に立ち止まって、ユーザーに進めていいか尋ねるし、提案された変更を実装する前に見せてくれるんだ。これのおかげで、トークンの無駄遣いや”悪い”作業を防げるんだよね。
でも、もうその必要ないってAIが勝手に決めたり、忘れちゃったりする時もあるんだよね。
Claude Codeの普通の使い方って、定額制のサブスクリプションだよ。レート制限はあるけど、かなり良心的。APIトークンも使えるけど、そっちは5〜10倍も高いんだ。だから俺はおすすめしないな。
＞ APIトークンも使えるけど、そっちは5〜10倍も高いんだ。だから俺はおすすめしないな。
APIトークンを使ってる俺も100%同意だよ。でも、うちの会社がAnthropicのキーをくれて、「トークン燃やせ！」って言われてるからAPI使ってるんだ。（会社はみんながAI使ってるのを見たいだけで、コストは全然気にしてないんだって）。
費用は使い方によるね。俺はClaude Codeを1日に何回も使うけど、1セッション$0.05かかることは珍しいよ。一番高かったのでも$6くらいだった。作業するコードベースのサイズも関係する。古い大規模なコードベースだと高くなるけど、新しい小さめのコードベースだと0.1セントってこともザラにある。俺がやってることだと、APIキーで払う方がサブスクよりずっと安いんだ。
APIトークンが10倍も高いなら、定額制のサブスクリプションって、すごく補助されてるってことにならない？
契約者が割り当て量を使い切らないことに依存してるってこと？
うん、間違いなくそうだよ。月200ドルの契約で毎日100ドル以上のトークンを使い切ってる人たちのコメントを見たよ。Anthropicはトークン制限を厳しくし始めたばかりだから、もっと厳しくなるはず。だって持続可能じゃないからね。
https://techcrunch.com/2025/07/17/anthropic-tightens-usage-l…
もっとコメントを表示（1）
それか、彼らがトークン単価につけてるマークアップがとんでもなく大きいとか。
うちの会社は法人契約してるんだけど、すごいとは思う一方で、正直あんまり役に立たないんだよね。
一貫したスタイルで書かれた小〜中規模プロジェクトで一番役立つよ。だから個人プロジェクトにはすごいパワーになるけど、企業ではあんまり便利じゃないかな。Claude Codeを使ってこの小さな物を作ったんだ。30分しかかからなかったよ。これなかったら作れなかっただろうね。
https://github.com/Baughn/ScriptView
まさにそう！プログラムのロジックが100ユニット以下ならかなり快適だよ。でも、いろんな人が促した数百ユニットを統合したり、大量かつ秘密の仕事を書く時は問題だね。RAGを使ってもコンテキストは限られてるから、秘密情報でモデルを訓練する必要がある。だから今のところClaude Codeのキラーアプリは非商用利用だね。これに不満なビジネス関係者もいるだろうな。
多くのアプリケーションは、それを前提に再設計する必要があるね。LLMと相性が良いから、マイクロサービスアーキテクチャが再評価されるんじゃないかな。
誰かが全体像、つまりエンドツーエンドのユースケースやクロスサービス呼び出しスタックを把握する必要があるのは変わらないよ。それがマイクロサービスの最大の欠点だし、特にチームの境界とサービス境界が一致してるとそう。一方、LLMがサービス開発を実際にやってくれるなら、それはソフトウェアエンジニアが出来ることでもあるね。
AIツールは仕事で全体的にポジティブな経験だよ。休憩が必要な時とか、整理したり、勢いをつけたい時に小さなタスクを引き継いでくれるし、基本的には良い手助けになる。でも、もし俺の仕事を全部できても、コストはあっという間に積み重なるよ。Claude Codeは大規模コードベースだと1〜2時間で25ドルを簡単に消費する。自動で修正させたら時給50ドルとか、速度、精度、コストのトレードオフになるね。エージェントの場合、その三角形はまだ十分に数値化されてないから、興味深いけどまだリスクがあるよ。
LLMが自己修正を繰り返して、RAGなしでコードを全部コンテキストに入れるって考えは、トークン課金のビジネスモデルにぴったりだよね、って皮肉な話。
コミットをAIで複数ドラフト生成し、手動や自動で絞り込むってアイデアを試してるよ。タスクがデカいほど初期のズレがマズいから、並行して色々生成できるエージェントなら手戻り減らせるかもね。詳しいやり方はここ見て→ https://github.com/sutt/agro/blob/master/docs/case-studies/a…
AI持ってるけど、アップグレードは無制限アクセスじゃないっぽいんだよね。このコストのスケーリングは、AI従業員って話では問題になるはず。特にプロバイダーが今すごい割引してるならね。
OpenAIが巨額を浪費してるのに収益が少ないってことは、Samが投資家を騙せなくなったらトークン価格は爆上がりするだろうね。Amazon、Google、Microsoftが助けない限り、今の価格じゃ単独でやってけないと思うよ。
使用制限はあるけど、ガッツリYOLOモードでコードを書き換えまくらない限りぶつからないよ。少なくとも小さくてめんどくさいタスクならね。「docstring書く」とか「型アノテーション追加」とか「単体テスト一つ書く」みたいなのは、良いプロンプトと組み合わせれば10回未満のやり取りで済むことが多いよ。
「AIの課題は能力じゃなくて、エージェントが効果的に使えるツールとフィードバックシステムの設計だ」って部分には同意するよ。前はAIに懐疑的だったけど、最近エージェント開発のスタートアップに入って考えが変わった。対象をすごく狭くしてツールに集中すれば、高確率で成功するって信じてる。非決定性は受け入れにくいけど、良いツールと狭いスコープなら十分使えるね。
12個も生産AIエージェントシステム作ったって？一つ良い製品を作るのだって大変なのに、12個も作れたことに驚かないの？ウチのDefiniteは2年かかってやっと良くなったんだぜ。詳細: https://www.definite.app/
彼は12個の独立した製品を作ったって言ってるんじゃなくて、職場で必要な12個のツールを作ったってことだよ。シンプルで特定のタスクをこなすものなんだろうね。記事全体が「シンプルにすれば使える」って言ってるじゃん。
それが俺の言いたいことだよ。彼はAIエージェントに「賭けない」って言ってるけど、真剣に構築を試みてないからじゃないかな。「API呼び出しはできても、何が起こったか理解できないせいで複雑なタスクをこなせないエージェント」ってのは、うまくいくまで時間がかかるものなんだ。
フルタイムの仕事と並行して3年間で12個以上の製品を作ったって、なんか怪しいな。どういうことなんだろう？
彼の本業はAIシステム構築でしょ？もし作るのが単発ワークフローのAIなら、月に1個くらい作れてもおかしくないよ。それに、この記事自体がうまく書かれた宣伝みたいだしね。
俺もAIエージェント作ってるけど、オープンエンドなコーディングはマジでやめた方がいい。人間がチェックする仕組みや、限定的な質問に絞るのがベスト。コンテンツ生成はダメ、絶対後悔するからね。
俺もAIエージェントフレームワーク作ってて、GPTで50%も時間削減できたよ。でも10回に1回はミスるから、LLMのアーキテクチャが変わらないと厳しいね。それでも生産性向上はマジで半端ない。Google検索の質が落ちた分をLLMが補ってくれるし。LLMが自信度を返して、低い場合は人間が確認するようなワークフローなら、非重要タスクで人間を置き換えられる可能性あるね。結局、人を減らすんじゃなくて、チームの仕事を自動化してスリム化するのが目的だよ。
前CTOだけど、コーディングエージェントは使えないね。生成されるコードはマジでひどいし、プロンプトに時間取られすぎて思考停止するんだ。保守性もゴミになるから、AIでプログラマーを減らすのは危険だよ。hypeに流されると後悔するぞ。
お前、コーディングとロジックを勘違いしてるぞ。コーディングは俺らのロジックを構文に合わせるだけ。機械がそれをコードに翻訳できるなら、何が問題なんだ？それって俺らの夢じゃん？電卓を使わないのは、子供が割り算を学ばなくなるって心配するのと同じ。アセンブリ言語がC++より優れてるかって話？高水準言語が世界を席巻したじゃん。ちゃんとやれば、俺たちは英語で書かれた仕様書でコードを書くんだよ。
お前のコメント、マジで的はずれだよ。自分の意見を押し付けすぎだろ。俺が言いたいのは、LLMが作るコードはゴミだってこと。それに、LLM使ってると脳が「テレビ見てるモード」になっちゃって、結局結果もゴミになるんだよ。
「作られるものがゴミ」なんて、みんながそう思ってるわけじゃないぞ。素人が飛びついてるんじゃなくて、本物の技術者も使ってるんだからな。
電卓が出てきた時も、「子供がバカになる」って思った人もいるけど、新しいツールは人を早く、効率的にするって考えられないのか？
https://antirez.com/news/154
お前が引用した記事、その次のがまさに逆の意見じゃん！俺は18年の経験があるけど、AIエージェントなしの方が断然速くて、質の高いコードを書けるし、保守性も保証できるんだ。なんで俺がわざわざ変える必要があるんだよ？将来良くなるなんて、まだ証明されてないだろ。これは電卓じゃないんだから、的外れな比較はやめろ。LLMは速くも効率的にもならない。品質と保守性を犠牲にするだけ。それは違うトレードオフなんだよ。
だいたい同意なんだけど、AIエージェントで作られるシステムって、結局は「高価なワークフローシステム」だよね？古い技術でもできたはずだし…。LLMを使う本当の理由ってどこにあるの？
非構造化テキストから構造化データを抽出するのにLLMは良いね。以前は無理だったワークフローも、不確定な部分を繋ぐことで作れるようになったよ。うちのSaaSを使ってる人たちは、結果にすごく満足してるみたい。
まったく同感だね。LLMはヒューリスティックが必要なものにぴったりだよ。”このプロジェクトはクライアントAに合うか？仕様はこれで…1～10で評価して”みたいなね。要は、定義されてない探索空間＼問題の解決策として使ってるよ。
古い技術で特定のデータや情報を複数のサイトからチェックするボットを作るのに数ヶ月かかるって？じゃあ、LLMだとその時間が大幅に短縮されるってこと？俺、間違ってる？
数ヶ月？スクレイピング自体は昔からそんなに難しい問題じゃなかったよ。情報の分類はもっと複雑で、LLMはその点で得意なんだ。でも、LLM登場前もチャットボット経由じゃなくても分類手段はあったけどね。
もっとコメントを表示（2）
LLMを分類器として使うなら、従来のMLと比較検討すべきだと思うな。うまく定義されてる問題なら、SVMでサッと片付くこともあるしね。LLMの最大のメリットは、データ分割やクリーンアップ、指標比較なんかいらないから、そこそこ良い結果がかなり早く出るってことだと思うよ。
そう、同意だよ。現時点でのエージェントの最適ポイントは、超絞られた範囲＋リスクが低い＋雑用みたいなタスクだね。Markdownのdev-logをエージェントに補足させる、そういうタスクについてここにちょっと書いたよ：https://github.com/sutt/agro/blob/master/docs/case-studies/a…
人間による検証は、チェックポイントを導入する上で確かに最も信頼できる方法だよね。でも、他にもユニットテストの実行とか、システム全体のその場限りの検証とか、色々な方法があるよ。
それは言うまでもないね。でも、俺が言いたいのは、HITLはワークフローのパターンであって、それ以外はエンジニアリングのパターンだってことだよ。
同感。https://danieltan.weblog.lol/2025/06/agentic-ai-is-a-bubble-…根本的な違いは、君が挙げたエラーにつながるHOTLじゃなくて、エラーを減らすためにHITLが必要ってことだよ。
＞新しいやり取りごとに、これまでの全コンテキストを処理する必要がある”って話だけど、俺はこれを軽減する何らかのキャッシュメカニズムがあるって認識してたんだけどな。
各ステップで全トークンペア間のアテンションを計算すると、素朴な実装だとO(N^3)になるんだ。前の注意値をキャッシュすれば、新しいトークンと過去のトークン間だけで計算すればいいから、かなり改善されてO(N^2)でNトークンのシーケンスを生成できるよ。
キャッシュはコンテキストを保持するのに役立つけど、結局そのキャッシュされたコンテキストをまた読み込んで処理する必要があるなら、キャッシュって本当に必要なのかな？
推論の全状態をキャッシュできるんじゃない？実装の詳細は書いてないけど、Geminiのドキュメントにはコンテキストキャッシュがヒットすると75%割引って書いてあるよ: https://cloud.google.com/vertex-ai/generative-ai/docs/contex…
キャッシュって、その後のリクエストで全部のコンテキストを送る手間を省くだけなのかな？僕の理解だと、キャッシュはコンテキストを保持するのに役立つけど、推論中にそのコンテキストを何度も処理する必要は避けられないと思うんだけど。
最初のコンテキスト処理もキャッシュされるんだよ。だから入力トークンにかかるコストがかなり安くなるんだ。
一体何がキャッシュされてるんだろう？トークン推論の各ループって、全コンテキストとこれまでに推論されたトークン全部を取り込む再帰ループみたいなもんだよね？彼らは以前に推論された状態をキャッシュして、ただコンテキストをキャッシュして推論し直すよりも効率的に使えてるのかな？
推論でGPUメモリを使い切るような時、このキャッシュってどこに置くつもり？コンテキストをもっと扱えるスナップショットに圧縮する方法がない限り、クラウドプロバイダーが会話をメモリに保持するためだけにGPUを遊ばせておくなんてありえないよ。
うん、プロンプトのキャッシュはコストにすごく効くよ。でも、長いテキストのツール出力があると、まだコストがかかるね。僕はそれをサブタスクに分割すると、全体のコストがずっと現実的になることを見つけたよ。
僕の理解では、キャッシュは計算を減らすけど、結局入力全体は処理されるんだよね。彼らがキャッシュの仕組みを完全に開示してるとは思わないな。LLMはキャッシュがあっても長い入力だと性能が落ちるしね。
「Production systems need 99.9%+ reliability」って言うけど、全然そんなことないよ。会社のビジネスプロセスを考えてみてよ。1日1分26秒しか不安定／エラー／ダウンタイムが許されないってことだよ。人間はそんなSLAを満たしてないし、コーヒーブレイクで即アウトじゃん！AIを使ったビジネスプロセス自動化は完璧じゃなくていいんだ。現状より十分良くて、元が取れればいいんだから。
稼働時間だけの話じゃないんだよ。もし橋が崩れたら人が死ぬんだ。中には広告を売ってるだけじゃない人もいるんだから。
もしチームが1日1分26秒の「ダウンタイム」があったせいで「橋が崩れて人が死ぬ」って話してるなら、AIエージェントの性能よりもっと大きな問題を解決しなきゃダメだよ。
稼働時間と信頼性は同じじゃないんだ。橋を設計するのに、エンジニアが1日の99.9%の時間働き続ける必要はないけど、彼らが下す決定の99.9%は正しくなきゃいけないんだ。
別の言い方をすると、もしエンジニアが99.9%の決定で正しくないなら、橋は99.9%稼働するだろうね。
橋としてはかなりヤバイね haha
このコメントは、ソフトウェアがクラウドベースで稼働時間だけが重要だと仮定してるよね。昔バックアップアプリを作ってたんだけど、それはクライアントのマシンで動いてたんだ。顧客は1万以上いたよ。99.9%の信頼性だと、常に10人の顧客が問題抱えてるってことになるんだ。稼働時間の問題じゃなくて、この場合はデータの整合性の問題だよ。だから99.9%の信頼性でも、潜在的に10件の訴訟や1日約10件のサポート電話につながる可能性があったんだ。当時は1万顧客だったけど、もし何百万ってなったらどうなると思う？
君は信頼性と可用性を混同してると思うよ。信頼性っていうのは、誰かに何かを渡した時に99.9%の確率でそれが相手の望むものだってことだね。可用性っていうのは、僕がデスクにいてコーヒーマシンに行ってないってこと。人間はすごく99.9%正確だし、僕の成果物には自信がないことのリストまで付いてるんだから。
別の投稿で読んだんだけど、人間って呼吸でさえ99.9%正確じゃないんだって。だいたい1000回に1回は咳が出たり、気道がきれいになったりするからね。
僕の意見だけど、信頼性ってのは可用性かける正確性だと思うよ。（あなたの言いたいことは大体同じだけど、「信頼できる」を「正確な」に置き換えることで、もっと正確な定義になるね。）
