1 ポイント 投稿者 GN⁺ 4 시간 전 | 1件のコメント | WhatsAppで共有
  • 一般公開された最初のMythos級モデル Claude 5 Fableは、多段階の仕様書を受け取って最大十数時間にわたり自律的に作業を遂行し、これまで使ってきたあらゆるモデルを大きく引き離して上回る
  • 単一のプロンプトと1回のフィードバックだけで、精緻な社会科学論文から、すべての単語が s で始まる10ページの韻文詩まで生成
  • 作業中に別のAI(主に安価な Claude Sonnet)を直接実行して、調査・コーディング・検証を分担させ、2,200件超の航空便や鉄道時刻表、国別の道路速度データを収集
  • ユーザーの役割は指示と結果判定へと縮小し、モデルの意思決定プロセスは露出しないため、究極のブラックボックスとして機能
  • AIとの関係は、直接作業する「魔法使い」から、結果を依頼して判定する**「パトロン(patron)」へと移行**しつつあり、能力が高いほど人間が介入できる余地が減る可能性を示唆

Claude 5 Fableの性能と使用感 - Ethan Mollick

  • 一般公開される初のMythos級AIモデル、Claude 5 Fableをアーリーアクセスで先行利用する機会を得た
  • Claude 5 Fableは公開される最初の Mythos級AIモデルであり、ソフトウェアセキュリティへの影響について多く議論されてきたが、テストはその領域を除いて実施された
  • Fableのガードレールは、サイバーセキュリティ用途ではほとんど使えないほど強く機能する
  • 複数の実験で、Fableはこれまで使ってきたほぼすべての公開モデルよりも大幅に高い性能を示した
  • Fableはさまざまな問題で能力を発揮し、複数ページにわたる仕様をもとに最大12時間ほど作業を実行した

Fableの性能と出力物

  • 実施したすべての実験で、公開されている他モデルを大差で上回り、あらゆる課題で全体的な性能向上が確認された
  • 単一のプロンプトと1回のフィードバックだけで、これまでAIが作った中で最も精巧な学術的な社会科学論文を生成
  • Claude Codeでは、曖昧な初期プロンプトと "make it better" のような少しの追加フィードバックだけで、プレイ可能なゲームを制作
    • コイン投げゲームは、“Balatro, but for the game of coin flips” というプロンプトから始まった
    • 自己認識を持つヘビゲームは、ヘビが自己認識を持ち、奇妙なことが起きる構造になっている
    • 深部へ降りていくゲームは、下へ進みながら何があるのかを確かめていく構造
    • Claudeは画像を生成できないため、すべてのアートと3Dオブジェクトを外部アセットなしで数学演算だけで実装
  • より本格的な作業になるほど、このツール体験は楽しさと不安のあいだに位置する — 何かを頼めば、そのとおりに実現してしまうからだ

Maps and Methods — 等時線地図の制作事例

  • 等時線地図(isochrone map) は、与えられた時間内に移動可能な距離を示す地図で、最初の事例は1881年にロンドン発の移動時間を示すために作られた
  • 以前のモデルでは、この種の地図を半分でも実用的に作ることはできなかった。何千もの潜在的な移動距離の調査と、多数の細かな判断が必要だったからだ
  • 作業の進め方

    • 都市選択と空港・鉄道・徒歩・自動車を反映した、実データベースの独自デザイン地図を求めるプロンプトを入力し、データはリアルタイムである必要はないが、調査に基づく実データであるよう指示
    • モデルはまず1881年の原作スタイルで制作することを提案し、同意後に作業開始
    • 数時間にわたるビルドセッションの中で、多数の別AI(主に安価な Claude Sonnet)を実行して移動時間の調査を進行
      • TGVからShinkansenまでの鉄道時刻表、複数の学術論文に基づく国別道路速度、2,200件超の具体的な航空便データを確保
    • 調査エージェントが動いているあいだにコーディングを始め、コード検証用の追加エージェントとテストを実行しつつ進捗を記録
  • 遠隔地補正とトークン使用

    • Greenlandのような遠隔地が正確な数値ではなく推定値しか含んでいなかったため、実際の移動時間を取得するよう修正指示
    • 今回は、調査しつつ相互に結果を検証する敵対的エージェントグループ(adversarial groups) のワークフローを実行
    • PacificのPitcairn Islandへ船がどの頻度で運航しているか、OttawaからGrise Fjordまでどう到達するかを算出
    • 短時間で膨大な量のトークンを消費
  • ユーザーがやったことは、野心的な指示と少しのフィードバックだけで、モデルが何百もの細かな判断を自ら下し、その選択を理解したり介入したりする機会はなかった
    • 作業量だけでなく、モデルのやり方・アプローチ選択・結果の深さに対するコントロールも限定される
  • 成果物はクリックできる等時線地図として提供され、グラフ下部で方法と出典を確認できる

Working with a Mythos-class model — Concord事例

  • 最も野心的なプロジェクトは、人間が生み出す雑多な回答を適切に分類する研究課題だった — アイデアがどれほど革新的か、人々がなぜ特定の本を好むのかなどを判断するもの
    • これまでは人間の研究者が判断を下し、他の回答と統計的に比較してデータの信頼性を確認していた
    • AIと人間の判断のキャリブレーション(calibration)は難しく、コストも高い
  • Fableにこの問題の解決を依頼したところ、まず**19ページの複雑な設計文書**を生成し、その後に実行した
    • Fableはこれをもとに9時間30分作業した
  • できあがった成果物は、AIがConcordと名付けたソフトウェアで、複数データセットを入力として受け取り、人間とAIの応答を補正し、複雑なデータ分析を行う
    • 完璧ではなく、専門家の立場からいくつかの誤りや欠落(その一部は依頼した設計に起因)を見つけ、修正を指示した
    • 提供された範囲は、これまで見た何よりも広く、研究者が何年も必要としていたのに収益性がなく作られてこなかったソフトウェアだった
    • 残る潜在的なバグはソフトウェアエンジニアが解決でき、新しいソフトウェア活用の爆発的増加に対応するには、むしろより多くのコーダーが必要になるかもしれない
    • ConcordのコードはGitHubリポジトリで利用・修正できる

限界と制約

  • Fableの強力さには、見慣れなさと限界が伴う
  • トークンコスト

    • FableはOpus比で2倍高価で、プロダクションコストは "a lot" と表現されるほどトークンを急速に消費する
    • ただし、安価なモデルへの巧みな委譲によって、実コストはかなり下がる可能性がある
  • ガードレールとスタイル

    • セキュリティ問題のごくわずかな気配でもガードレールが作動し、性能の低いClaude 4.8 Opusへ切り替わってしまい、これがあまりにも頻繁に起きる
    • Mythosをめぐる議論は主にソフトウェアセキュリティへの影響に集中していたが、Fableのガードレールはサイバーセキュリティ用途を事実上遮断している
    • 依然として**ギザギザのフロンティア(jagged frontier)**が存在し、生成物や進捗レポートには独特の "Claudism" 的文体が残っている

魔法使いからパトロンへ — 人間の役割の変化

  • 昨年、この体験を『呪文を唱えると何かが起きる』魔法使い(wizard) にたとえた
  • Fableでは、その呪文が十分に強力になったことで、ユーザー自身は魔法使いというより**パトロン(patron)**に近くなる
    • 欲しいものを描写し、費用を払い、結果を判定する — 実際の作業(conjuring)は見えない場所で何百もの細かな選択を通じて進む
    • 作業はプロセスから結果へ移り、もはや操縦(steer)するのではなく依頼(commission)するようになる
  • 2つの可能性

    • インターフェースが追いついていない一時的な現象かもしれず、モデルの動作を覗き込み、途中で操縦するよりよい方法が現れる可能性がある
    • 逆に、モデルが有能であればあるほど、人間が意味のある形でできることは減り、そのブラックボックス性こそが能力の代償である可能性のほうが高いと見る
  • 明白な意味での制御喪失ではなく、依然として操縦可能で、指示にも非常によく従う指示が野心的であるほど結果はよくなる
    • しかし操縦はもはや直接実行と同義ではなく、モデルが自前のエージェントを立ち上げて調査・執筆・相互検証を終え、完成版を返してくる
    • パトロンが1人の芸術家に依頼するのではなく、Fableは作業現場に一歩も足を踏み入れないまま最終結果だけを承認する、スタジオ全体に近い形になっている

1件のコメント

 
GN⁺ 4 시간 전
Hacker Newsの意見
  • この記事では、生成されたコードの品質や媒体に関する実質的な内容がほとんどない点が興味深い
    コードにドキュメントやテストがあるのか、理解・拡張が可能なのか、安全なのか、どの言語・フレームワーク・データベースを使ったのかが気になる。著者は判断力とセンスについて語っていたが、実際のコードもセンスよく書かれているのかは分からない。新機能の追加を頼んだら、モデルが全体構造を組み直してまた9.5時間分のトークンを使うことになるのかもしれない、という疑問もある。研究部分はドメイン知識、つまり旅行の種類ごとに時間をどう換算して見やすくしたのか、という点だろうが、著者がそれをどう検証したのかも気になる
    こうした質問はAIにだけ当てはまるものではない。人間のエージェンシーに金を払って「動く」という成果物を受け取ったとしても、同じことを尋ねるだろう。評価する力がなければ、評価できる人を雇っていたはずだ。LLMで最も引っかかる部分は検証

    • こういう記事を書くのはソフトウェアエンジニアであることはほとんどなく、たいていは技術系の役員、引退したエンジニア、VCだ
      この著者はWharton School of Managementの教授らしい。こういう人たちは実際の製品をリリースしたり保守したりする必要がなく、ただサイドプロジェクトを作っているのに近い
      まともなソフトウェアエンジニアリングの観点は、Mitchell Hashimotoから見たものがほぼ唯一だった
    • LLMはリスクの低いプロジェクトを作るのが本当に得意だと気づき始めている
      上の質問はおおむね、もっと高いリスクを前提にしている。ソフトウェアが長く保守され、要件が進化し、ミスが許されない、というような話だ
      ソフトウェアでLLMをうまく使うコツは、あらゆるプロジェクトを低リスクにする方法を学ぶことなのかもしれない
    • この2年ほどのLLM議論はずっとこんな感じだった
      実質的な内容を求めると、「人間だってこれをうまくできないじゃないか!」という言葉が返ってくる。定量的な根拠は非常に少なく、純粋なレトリックばかりだ
    • モデルが良くなるほど、コードがどう見えるかは本当に重要ではなくなるのかもしれない、と思うようになってきた
      ソフトウェアの観察可能な振る舞いが良ければ、そのソフトウェアは良いものだ。どんな種類のバグでも、モデルがバイブコーディングされたコードベースで修正できるなら、修正可能なバグだ。悪用可能な脆弱性がなければ安全なコードであり、性能が十分なら高性能なコードだ
      外側でやるべきことを果たし、内側で問題が見つかったときにモデルが直せるなら、コードの見た目は重要ではない。ソフトウェアエンジニアリングはこれまで以上に、コードが意図どおりに動くかを確認する仕事になった
      たとえコードの見た目が重要だとしても、それもモデルに直させることができる
    • 例の一つである「ヘビが自意識を持って妙なことが起きるスネークゲーム」をクリックしてみたが、1〜2分遊んだ限りではただの1980年代風スネークゲームだった
      何か見落としたのか分からない。「自意識」というのは画面下の面白いメッセージ数個のことなのか? 「妙なこと」が何なのかも分からない
  • Fableに、私が手で検証していたモデルを入れてみた
    だいたい、Opusにシナリオをモデリングさせて、数式を見せてもらい、修正して繰り返し、最後にコードがモデルのロジックと合っているかを再確認する、というやり方だ。Fableは私が見つけたエラーをほぼすべて見つけ、追加変数についても興味深い提案をしてきた
    ただし利用上限を90年代末のHummerのように燃やし尽くしてしまった

    • Max 5xを契約しているが、Fableは40分のコードレビューセッションで週間上限の**16%**を使ってしまった
      レビューを終わらせることすらできず、しかも肝心の、Fableが必要だった重要なメモリ安全性の部分ではOpus 4.8に戻ることになった
      近いうちに、価格のせいでこういうモデルを使えなくなりそうな気がする。6月22日までにFableをできるだけ使い倒すべきかもしれない
    • いちばん重要な質問はこれだ。ここでの投資対効果はどれくらいあるのか?
  • 今日Fableで個人プロジェクトをやってみたが、かなり堅実に見える一方で、4.8からそこまで大きく離れてはいない
    同じハルシネーション、同じタイプのバグ、大きなプロジェクトでは頼まれたことだけをやって、それによって触れたり壊したり影響したりする可能性のある部分を無視する傾向も同じだ。最初はテストを回すが、文脈が大きくなると「あとで回す」と言い、罵声混じりで指示しない限り、結局最後まで回さない
    使い続けるつもりではあるが、今のところは漸進的改善であって、「OMG OMG OMG Mythosが来た!」というレベルではない

    • 私の経験は逆だ。Fableはすべてを先回りして、聞かなくても全部やってくれるように見えた
      とても印象的で、一緒に仕事しやすかった
      奇妙な現象でもない。最初に契約した頃のOpusもちょうどこんな感じだった。Anthropicが容量不足のためにOpusを弱体化させたというミームが広く流れているが、それが本当かは分からない。ただ、Fableも同じ運命をたどるのかは気になる
    • 私のプロジェクトでは、4.8が見落としたものをFableはすぐにはっきり見抜いた
      だが、その問題を次々に乗り越えて大いに感心させた後、ほどなくしていつものように、何かをする代わりに話し続ける無限ループにはまり、時々止まって、私が再度せかさなければならなかった
      だからAGIではない。それでも確かな改善ではある
  • この記事のこの短い一文が怖い。「しかし、ソフトウェアエンジニアが、私がすぐには見つけられなかった残りの潜在的バグを仕上げてくれるだろう」
    すべてのソフトウェア開発者は、これが非常に危険で非現実的な前提だと知っている

    • これは実質的に、あらゆる本当の作業を簡単に投げ渡してしまう短い一文だ
  • 著者が「AIが作った最も洗練された学術的社会科学論文」と呼んでいる文章の最初の数段落を読んでみたが、期待したほど印象的ではなかった
    「市場需要に関する事後信念は純粋に参照点依存である。調達額を一定に保つと、起業家は自ら設定した目標に対する成果だけを追跡する。閾値で標準偏差の半分だけ跳ね、その後の最初の10ポイントには急峻に反応し、それ以降は平坦化する」といった具合だ
    人は普通、データをこんなふうに言葉で解きほぐしては語らない。要約文書もかなり内容が水増しされている感じ

  • 問題が最も完璧に表れている箇所だ
    著者は、すべてのデータが実在し検証済みであるべきだとプロンプトに入れたあと、ただそうだと信じてしまった。データ駆動型のプロジェクトですらそうだった。人々は無数のこと、しかも重要なことですら、まったく同じことをするだろう

    • 人生でもっと早く知っておきたかったが、誰も確認しないのなら、もっとずっともっともらしく作り上げることができたのに
  • 「9時間半作業した」というくだりと、「完璧ではなかった。専門家としていくつかの誤りや抜けを見つけ、AIに修正させた」という部分が目を引いた
    1日に1つの問題にそこまで長く使うとは思っていないし、コアとなる報酬ループが数時間単位の成果物をまた修正するのに、そこまで長く使うとも思っていない
    私の顧客は現在、エージェントの応答時間を85秒から20秒未満に下げるよう求めている
    それと同時に、業界がエージェントによる1時間超の作業フローへ向かっているのを見ると、かなりちぐはぐに感じる

    • Claudeを擁護するなら、信じがたいが擁護することになるのだが、19ページの設計書からConcordのようなものを9.5労働時間で作れる単独の開発者は知らない
      昔のように、上司がなぜ座っているだけなのかと尋ねる時代に戻るのだろう。ただし「コンパイル中です」の代わりに「Claude待ちです」と言うようになるだけだ
    • この時点では、もっとずっと金を払ってくれるなら自分がやる
    • 私のOpus 4.8は、些細ではない単一のコーディング依頼でも定期的に10分以上作業する
    • 作業時間はそれほど価値のある測定値ではない
      たいていは、過程を直接コードで定義し、そのコードが作業の塊をモデルに委任するようにしたほうがよい。唯一の実際の問題は、プロバイダのサブスクリプション割引を活用しにくくなることだ
      逆に、モデルのルーティングを自前で行うのは簡単になる。一般的なチャットボットが数日・数週間単位の作業フローで一貫性を保つ方法は、まだ見たことがない
    • QWENモデルが出てきた時点で、すでにシグモイド区間に入ったと見ている
      プロジェクトをきちんと構造化すれば、望む拡張ポイントを示して30分ほど回し、機能を拡張させることができる。コード全体を対象に『神モード』を効果的にこなすわけではないが、注意深い観察者かつコードの専門家としては、128GB VRAM超が必須というわけでもない
      最新モデルの非対話処理がここまで来たのは驚きだが、中国がこうしたモデル向けのシリコンを作り始めたら決着がつく気がする
  • その詩のプロンプトが何だったのかものすごく気になる
    アイデアに見覚えがあって掘ってみたら、14年前のredditの詩を見つけた: [https://www.reddit.com/r/RedditDayOf/comments/tjjw2/may_12_a...]
    著者が共有したものほど長くはないが、同じアイデアだ
    これはポーランドの作家Stanisław LemのSF寓話集『The Cyberiad』に由来する。ある話で、ロボット製作者Trurlが詩を書く機械を作り、嫉妬深いライバルのKlapaucianがその機械に「散髪についての詩を! ただし崇高で、高貴で、悲劇的で、永遠で、愛と裏切り、報い、静かな英雄主義、確実な破滅を前にした詩で! 6行で、巧みに韻を踏み、すべての単語がsで始まらなければならない!」と要求する
    コンピュータはこう答える:
    “Seduced, shaggy Samson snored.
    She scissored short. Sorely shorn,
    Soon shackled slave, Samson sighed.
    Silently scheming,
    Sightlessly seeking
    Some savage, spectacular suicide”
    著者がFable/Mythosに課題を投げる際、この場面を参照していたとしか思えない。正確なプロンプトが気になる

    • 興味深いのは、これが英語訳の難度だということだ
      英語訳では、ポーランド語の原文とは異なる頭文字と異なる単語が使われている:
      Cyprian cyberotoman, cynik, ceniąc czule
      Czarnej córy cesarskiej cud ciemnego ciała,
      Ciągle cytrą czarował. Czerwieniała cała,
      Cicha, co-dzień czekała, cierpiała, czuwała...
      ... Cyprian ciotkę całuje, cisnąwszy czarnulę!!
      翻訳者の仕事をLLMと比較してみることができる。どちらも派生的な作業で、制約の中で働くが、創造性を発揮する余地がある
    • 著者がその場面を参照したのではなく、Anthropicがredditコメントのライセンスを取得しているので、学習データから吸い上げた可能性もある
  • まだ1時間も使っていないのだから、新技術に興奮している状態だという点を考慮すべきだ
    私のプロジェクト(https://github.com/tsz-org/tsz)のようなケースでは、モデルが十分に調べず、別の状況を考慮しないことにずっと苛立たされてきた。モデルは1つを直すコードを作り、「無関係に見える」2つのテストを壊すことを繰り返していた
    Fableは作業にずっと長い時間がかかるようで、まだFableのセッションでプルリクエストを見たことはないが、セッション記録を読むと、石を1つも取りこぼさないようにするやり方で正しいことをしているのがわかる
    記事でも言われているように、こうしたモデルの「感触」はプロジェクトごとにあまりにも違っていて伝えにくいが、共有してみる

    • それは、そのプロジェクトが機能を段階的に追加しやすい構造ではないことのサインではないか?
  • みんなが Mythos と Opus の間にそこまで大きな違いを感じるほど、いったい何をやっているのか気になる。
    自分でもかなり高度な作業をしていると思うけど、それでも Deepseek だけで十分なことのほうが多い。ここにいる人たちはみんな天才なのか?

    • 何を作っているか次第。
      Hades や Baazar みたいな、しっかりしたインディーゲーム級のビデオゲームを作って、有機的・インタラクティブ・アニメーション寄りの UI 要素や視覚効果、複雑なシェーダーなどを作ろうとすると、どのモデルでも簡単に片づけられるほど十分ということはまったくない。上位 3% レベルのゲームで出てくる問題のかなりの部分は、単純なプロンプトではどのモデルにとっても本当に難しい。
      個人的には自分でコーディングして学ぶのが好きなので、あまり気にしておらず、DeepSeek Flash くらいで十分。それでも、最高クラスのモデルでもまったく歯が立たないベンチマークを大量に作るのはとても簡単だし、そういう問題でモデルがどれだけ良くなっているかを試すのが好き。
      ちなみに Fable 5 は 4.8 より確実に少し良い
    • 新しいノートPCが発表されると、社員が急にみんなアップグレードが必要だと言い出すのと似ている。
      実際には 90% は Macbook Neo でも十分やっていけるはずなのに
    • 最近、Rust でよくある Web インフラ系のプロジェクトを実装している。
      rustls や Tokio といった Rust の優れた基本要素を多く使って、メモリ安全な、あるいはそれに近い nginx 代替を作ろうとしている。
      その作業の一環として、高品質な Lua in Rust リポジトリも作っている。gpt 5.5 と Opus 4.8 が詰まっていた自分の Lua インタプリタの性能問題を、Mythos で直しているところ。
      Mythos がこれを解けるかどうかは分からないが、もう数時間走らせていて、かなり有望な結果が出ている。
      興味があれば性能チャートはこちら: https://github.com/ianm199/lua-rs
    • 自分でプログラミング言語を作っている。
      貢献できそうなオープンソースプロジェクトも見て回っている。趣味開発者からプロへの移行に役立ちそうな何かを探しているが、今の時代にそんなことが可能なのかは分からない。
      Fable 5 はコードレビューで Opus 4.8 が見落としていた問題をかなり多く見つけた。くだらないサイバーセキュリティ関連の制限のせいでモデル性能が落ちていたのに、それでもそうだった。これ以上あまり語れないのは、Max 5x だと 5 時間ウィンドウごとに 1 セッションしか使えないから。今のところ 2 セッションしか回していない
    • 要求水準を上げ続ければ、どんなモデルでも限界まで追い込むのは難しくないはず。
      極端な例として、プロンプトが「機能が完全で完成度の高い Facebook クローンを作れ」だとしてみよう。Facebook は複雑ではあるが、技術的にはそこまで極端に難解ではない可能性が高い。それでもかなりのトークンを消費したあとには、そのプロンプトに対する各モデルの成果物に、さまざまな面で かなり大きな差 が見えてくるはず。
      もちろん上の依頼が実際に有用なわけではない。でも、限界に近づくまでより大きな塊の仕事を任せない理由があるだろうか? どこかの時点で境界に達し、差ははっきりするはずだ