Claude Codeの次は「AI同僚」だったKarpathyが語るAgentic Workの未来
Claude Codeの次に来るのは、AIを「同僚」としてチームに迎える形でした。
これがいま、Agentic Workという流れの中で、実際に動き始めています。
AIの使い方は、もう「どのモデルが一番賢いか」を競う段階を超えようとしているんです。
ChatGPTとClaudeはどっちが優秀なのか。
どのモデルがベンチマークで勝ったのか。
文章生成、画像生成、プログラミングでは、どれを使うべきなのか。
生成AIの進化は、これまで主に「モデルの能力競争」として語られてきました。
でも、Andrej Karpathyが2026年5月以降に語っている内容を追っていくと、本当の争点はそこじゃない、ということが見えてきます。
いま動いているのは、AIが置かれる場所と、AIに与えられる役割なんです。
これまでのAIは、人間がWebサイトを開いて、質問を書いて、回答を受け取るものでした。
そこからClaude CodeのようなAIが、パソコンやターミナルの中に入って、ファイルやコードを操作するようになりました。
そして次の段階では、AIがSlack、コードベース、社内データ、業務ツール、チームの会話の中に入り込んで、組織の中で継続的に働き始めます。
AIは「質問に答えるチャットボット」から「仕事を任せられるエージェント」へ進んで、さらに「チームで共有される同僚」のような存在に近づいています。
その変化を象徴しているのが、KarpathyのAnthropic参加と、Claude Tagの登場です。
KarpathyはなぜAI業界で特別な存在なのか
Andrej Karpathyは、単に有名なAI研究者というだけの人ではありません。
Stanford大学では、コンピュータビジョンと深層学習を扱う講義「CS231n」の設計と教育に携わりました。
その後はOpenAIの創設初期メンバーとして研究を行い、TeslaではAI部門を率いて、Autopilotのコンピュータビジョン開発に関わってきました。
さらに、micrograd、nanoGPT、「Neural Networks: Zero to Hero」といった教材を公開して、ニューラルネットワークやLLMの仕組みを、コードを通して理解できる形で伝えてきました。
高度な研究を理解する力と、それを一般の開発者にかみ砕いて説明する力を同時に持っている。
そこがKarpathyの大きな特徴です。
Karpathyは2025年に「vibe coding」という言葉を広めて、自然言語でAIに指示しながらソフトウェアを作る、新しい開発スタイルを象徴する人物にもなりました。
その後は、もっと本格的なソフトウェア開発を表す概念として「Agentic Engineering」を提唱しています。
そんなKarpathyが、2026年5月19日にAnthropicへ参加しました。
本人は、LLMのフロンティアにおける今後数年が特に重要な形成期になると述べて、もう一度、研究開発の現場に戻ることを明らかにしています。
配属先は、Claudeの根本的な能力を作るpretrainingチームです。
さらにAnthropicは、KarpathyがClaudeを使ってpretraining研究そのものを加速するチームを立ち上げる、としています。
これは、ただの転職ニュースじゃありません。
AI教育や個人プロジェクトに力を入れていたKarpathyが、もう一度、最先端モデルの学習現場に戻ってきた。
しかも、その場所として選んだのがAnthropicでした。
彼はClaudeについて外から論評するだけじゃなく、Claudeの基礎能力を作る側に回ったんです。
なぜ「pretraining」が重要なのか
生成AIの性能向上というと、ユーザー向けの新機能や、回答の仕方の改善に注目が集まりがちです。
でも、大規模言語モデルの能力は、大きく2つの段階で作られています。
1つ目がpretraining、つまり事前学習です。
膨大なテキスト、コード、画像、その他のデータから、言語や世界についてのパターンを学習します。
モデルが何を知っているか、どのくらいの推論や抽象化ができるか、どれだけ広い領域を扱えるか。
その基礎の部分が、ここで形づくられます。
2つ目がpost-trainingです。
人間の指示への従い方、回答の安全性、推論の進め方、ツールの使い方などを調整します。
ユーザーが実際に触れたときの使いやすさや、人格的な部分には、このpost-trainingが大きく関わってきます。
Karpathyが入ったのは、前者のpretrainingです。
つまり、Claudeの使い方を表面的に調整するだけじゃなく、次世代Claudeの知識、推論力、学習能力、世界理解の土台を作る領域に入った、ということになります。
さらに重要なのが、Claudeをpretraining研究そのものに使う、という部分です。
AI研究者は、モデルの学習データを調べて、実験コードを書いて、学習結果を分析して、失敗の原因を探って、新しい仮説を立てます。
こうした研究工程をClaudeが支援するようになれば、AIがAI研究のスピードを上げることになります。
ただ、これは「AIが勝手に次のAIを生み出す」という単純な話ではありません。
いまの時点では、人間の研究者が研究目標を定めて、実験を設計して、結果を評価します。
その一つひとつの工程を、AIが高速化する形です。
それでも、研究サイクルが短くなれば、
より強いClaudeが研究を支援する → 研究速度が上がる → さらに強いClaudeが作られる → そのClaudeが次の研究を支援する
という、ぐるぐる回る再帰的なループが生まれます。
KarpathyのAnthropic参加が重要なのは、この「AIによってAI研究を加速する」ループの真ん中に、彼自身が入ったからなんです。
AIは「検索窓」ではなくなり始めている
これまでの生成AIの代表的な使い方は、質問と回答でした。
人間がChatGPTやClaudeのWebサイトを開いて、プロンプトを入力する。
AIが回答を返して、人間がそれを読む。
必要なら追加で質問する。
この形だと、AIは基本的に受け身の存在です。
人間が会話を始めなければ、何もしません。
仕事の背景は毎回説明する必要があります。
回答を受け取ったあとの作業は、人間が別のアプリやシステムに移動して進めることになります。
たとえばAIに市場調査を頼んだ場合、AIがレポートを書いてくれても、それをNotionに移して、チームに共有して、タスクを作って、担当者を決めるのは人間でした。
プログラミングでも同じです。
初期のAIコーディング支援は、コードの続きを提案したり、関数を書いたりするものでした。
AIが生成したコードを人間がコピーして、エディタに貼り付けて、実行して、エラーをまたAIに伝える必要があったんです。
ところが、Claude Codeによって、この関係が変わりました。
Claudeがターミナル、ファイルシステム、コードベース、テスト環境にアクセスして、自分でコードを読んで、変更して、実行して、結果を確認できるようになりました。
AIは「答えを生成するもの」から「コンピュータ上で作業するもの」へと変わったわけです。
そして2026年6月、Anthropicはさらにその先を示すClaude Tagを発表しました。
Claude Tagとは何か
Claude Tagは、ClaudeをSlackのチームメンバーとして参加させる仕組みです。
管理者が、Claudeにアクセスを許可するSlackチャンネル、ツール、データ、コードベースを設定します。
そのあとは、チームメンバーがSlack上で、人間の同僚を呼ぶのと同じように @Claude とタグ付けして、仕事を頼めるようになります。
Claudeは依頼を受けると、必要な工程を分解して、アクセスを許可されたツールを使って作業して、完了後にSlackスレッドへ成果を返します。
2026年6月23日に、Claude EnterpriseおよびTeamユーザー向けのベータ版として提供が始まりました。
ただ、「SlackからClaudeを使える」という説明だけだと、Claude Tagの本当の重要性はつかめません。
SlackとAIを連携させるサービスは、以前から存在しています。
質問に答えるボットや、会話を要約する機能、社内ドキュメントを検索するRAGシステムも珍しくありません。
Claude Tagには、それらとは違う4つの性質があります。
- チームで一つのClaudeを共有する
ふつうのチャットAIだと、一人ひとりが別々の会話を持ちます。
AさんのClaudeとBさんのClaudeは、それぞれ違う文脈を持っているんです。
だから、AさんがAIと進めていた仕事をBさんが引き継ぐには、内容をもう一度説明しないといけませんでした。
Claude Tagでは、同じSlackチャンネルの全員が、同じClaudeとやり取りします。
Claudeが何をしているかをチーム全体で確認できて、途中から別のメンバーが指示を足したり、前の会話を引き継いだりできます。
AIとの仕事が、個人の閉じたチャットから、共有されたチーム活動へ変わるわけです。
Anthropicは、この性質を「multiplayer」と表現しています。
- チャンネルの文脈を継続的に蓄積する
Claude Tagは、参加を許可されたチャンネルの会話から、仕事に関係する情報を蓄積していきます。
プロジェクトの目的、過去に決まったこと、設計上の判断、チーム特有の用語、誰が何を担当しているか。
そういった情報を、毎回ゼロから説明する必要が少なくなります。
企業の中の大事な知識って、必ずしも正式なドキュメントに整理されているわけじゃないですよね。
「その方針は先月の会議で却下された」「この顧客だけは例外対応が必要」「この機能は技術的には可能だけど、法務の判断で見送った」。
こういった暗黙知は、Slackの会話やスレッドの中に残っています。
Claude Tagは、この散らばった会話を作業文脈として使います。
ただし、すべてのチャンネルを無制限に読むわけではありません。
管理者が許可したチャンネルやデータだけが対象で、用途の違うClaude同士で記憶が混ざらないように、スコープを分けられます。
- 人間が待っていなくても非同期に作業する
従来のチャットAIでは、ユーザーが画面の前で回答を待つ使い方が中心でした。
Claude Tagでは、仕事を頼んだあと、人間は別の作業に移れます。
Claudeは数時間、場合によっては数日にわたって作業を続けて、進捗や結果をSlackに返します。
複数のClaudeに、別々の調査や実装を並行して任せることもできます。
これは、AIとの関係を「一問一答」から「委任」へ変えるものです。
人間は1つのAIの回答を待つんじゃなくて、複数のAIに仕事を割り振って、返ってきたものから確認していく。
Anthropic自身も、Claude Tagによって、複数のClaudeへ並列に仕事を委任する時間が増えた、と説明しています。
- 必要に応じて自分から動く
Claude Tagには、状況に応じて情報を知らせたり、止まっているタスクを追いかけたりする「ambient」な動きも用意されています。
たとえば、重要な指標に変化があった、関連する別チャンネルで新しい情報が出た、未解決のスレッドが長いあいだ止まっている。
こういう場合に、Claude側から知らせることができます。
AIは人間から呼ばれるまでただ待つだけじゃなく、許可された範囲で周りを観察して、必要なときに参加する存在になっていきます。
Karpathyが「LLMの第3のUI」と呼んだ理由
KarpathyはClaude Tagについて、LLMのUI／UXにおける「3回目の大きな再設計」だ、という趣旨の評価をしています。
彼の整理では、第1の形はWebサイトです。
ChatGPTやClaude.aiにアクセスして、チャット画面でAIと会話する。
AIを使いたい人間が、AIのいる場所まで行く形ですね。
第2の形はアプリです。
Claude Codeや各種コーディングエージェントのように、AIを自分のコンピュータへ導入します。
AIはローカルファイルや開発環境にアクセスして、個人の仕事を直接手伝います。
そして第3の形では、AIが自己完結的で、継続的に存在して、非同期に動いて、組織全体のツールと文脈を持つ存在になります。
人間がAI専用の画面へ移動するんじゃありません。
AIがSlackなど、人間がすでに仕事をしている場所へ入ってくるんです。
Karpathyは、Claude Tagを単なるSlackボットではなく、組織レベルの「harness」だと説明しています。
基本的なデモを作ること自体は難しくないけれど、企業で本当に動かすには、ツール連携、実行環境、記憶、セキュリティ、権限、監査、コスト管理などを、一体として成立させる必要がある。
そういう見方です。
この「harness」という言葉は、これからのAIを理解するうえで、けっこう重要になってきます。
モデルより「harness」が重要になる
harnessは、日本語に直訳すると馬具や制御装置という意味です。
AIの分野では、モデルを実際の仕事に使える形にするための、周辺システム全体を指すことが多いです。
どれだけ賢いモデルでも、それだけでは企業の仕事を進められません。
仕事をするには、少なくとも次のような仕組みが必要になります。
- どの情報を読めるのか
- どのツールを使えるのか
- どの操作を自動で実行できるのか
- どの操作には人間の承認が必要なのか
- 過去の情報をどこまで記憶するのか
- 長時間のタスクをどう続けるのか
- 失敗したときにどう再試行するのか
- 誰が何を依頼したかをどう記録するのか
- 利用料金やトークン消費をどう制限するのか
- 結果が正しいかをどう検証するのか
モデルは「頭脳」に近い存在です。
harnessは、その頭脳に、目、手、記憶、作業机、社内ルール、身分証明、アクセス権限、報告経路を与える仕組みです。
Claude Tagでは、管理者が用途ごとにClaudeの権限を分けられます。
営業用のClaudeがエンジニアリングの機密情報へ勝手にアクセスしたり、エンジニアリング用のClaudeが営業チームの記憶を無断で共有したりしないように設計されています。
また、管理者は組織全体やチャンネル単位の利用上限を設定できて、Claudeが行った作業と依頼者をログとして確認できます。
Claude Tagの本質は、AIをSlackに表示したことではありません。
組織の中でAIが働くために必要な権限、文脈、ツール、記憶、実行、監査を、1つのシステムとしてまとめたところにあります。
Claudeは「便利な道具」から「作業主体」へ変わる
ここで起きている変化を、「AIが人間のようになった」と表現するのは、正確ではありません。
Claudeに人間と同じ感情や責任が生まれたわけじゃないし、最終的な責任を負うこともできません。
それでも、仕事の進め方という観点で見ると、AIが単なる道具から作業主体に近づいているのは確かです。
従来の道具は、人間が操作しているあいだだけ動きました。
表計算ソフトは、人間が数式を入力しないと計算しません。
検索エンジンは、人間が検索語を入れないと情報を探しません。
IDEは、人間がコードを書かないとプログラムを作りません。
エージェント型AIだと、人間が細かな操作をすべて指定する必要がなくなります。
人間は「どのボタンを押すか」じゃなくて、「何を達成したいか」を伝えます。
AIが目的を工程に分解して、必要なツールを選んで、実行して、途中で結果を確認して、問題があれば直します。
つまり、人間からAIへ渡されるものが、操作命令から目標へ変わるんです。
そして、AIから人間へ返ってくるものも変わります。
単なる文章回答から、コード、プルリクエスト、分析結果、修正済みファイル、ダッシュボード、調査レポートといった、完成物へ変わっていきます。
これがAgentic Workの中心にある考え方です。
Claude Opus 4.8が示した「長時間働くAI」
Claude Tagの直前、Anthropicは2026年5月28日にClaude Opus 4.8を発表しました。
Opus 4.8では、コーディング、エージェント型タスク、専門的な知識労働が強化されました。
Anthropicは、以前のモデルよりも判断の一貫性が高くて、長時間の作業でも文脈や目的を保ちやすくなった、としています。
重要なのは、同時に導入された2つの仕組みです。
1つ目はeffort controlです。
ユーザーは、Claudeが1つのタスクにどれだけ多くの計算や推論を使うかを調整できます。
簡単な質問では低いeffortを選んで、素早く答えさせる。
難しい調査や長時間の開発では高いeffortを選んで、より深く検討させる。
AIをいつも最大出力で使うんじゃなくて、仕事の重要度や難しさに合わせて「どのくらい考えさせるか」を選ぶ、という考え方ですね。
2つ目が、Claude Codeのdynamic workflowsです。
Dynamic Workflowsは何を変えるのか
ふつう、1つのAIエージェントには1つのコンテキストウィンドウがあります。
タスクが大きくなりすぎると、情報が混雑して、最初の目的を見失ったり、途中で得た知識をうまく整理できなくなったりします。
複数の問題を1つの会話で同時に扱うと、推論が干渉してしまうこともあります。
Dynamic Workflowsでは、Claudeがタスクに合わせたオーケストレーション用のスクリプトを作って、数十から数百のサブエージェントを並列に動かします。
あるエージェントはコードベースを調査して、別のエージェントはテストを作ります。
別のエージェントはセキュリティ上の問題を探して、さらに別のエージェントが各成果をレビューします。
最後にClaudeが結果を統合して、検証してから人間へ返します。
Anthropicは、数十から数百の並列サブエージェントを動かすことで、これまでなら数週間から数カ月かかった仕事を、数日単位に短縮できる可能性がある、と説明しています。
大規模なバグ調査、コードベース全体の移行、セキュリティ監査、複数案の比較、独立した検証などが主な用途です。
ここで大事なのは、AIが既成のワークフローをただ実行するだけじゃない、という点です。
Claudeは、与えられた問題に合わせて、その場で専用のharnessや作業手順を組み立てます。
小さなタスクなら、1つのエージェントで処理します。
コードベース全体の調査なら、ディレクトリやサービスごとに担当エージェントを分けます。
重要な変更なら、実装担当とは別に、レビュー担当や反証担当を置きます。
AIは仕事を実行するだけじゃなく、その仕事に合ったAIチームの構成まで設計するようになる、ということですね。
一方で、Dynamic Workflowsは通常のClaude Codeよりも、大量のトークンを使います。
Anthropicも、最初は範囲を限定したタスクで試すことをすすめています。
並列化すれば必ず効率が上がるわけじゃなくて、仕事の分割の仕方や検証の設計が悪ければ、コストだけが増えてしまう可能性もあるからです。
Vibe Codingの次に来る「Agentic Engineering」
Karpathyは2025年に、AIへ自然言語で指示して、コードの細部をあまり意識せずにソフトウェアを作るスタイルを「vibe coding」と呼びました。
vibe codingは、ソフトウェアを作れる人の範囲を広げました。
プログラミング経験が少ない人でも、作りたいものを文章で説明して、エラーをAIへ返しながら、Webアプリや小さなツールを作れるようになりました。
ソフトウェア開発の参入障壁を下げたという意味で、大きな変化でしたよね。
でも、プロトタイプを作ることと、企業で長く使われるシステムを作ることは、別の話です。
業務システムには、セキュリティ、保守性、テスト、データの整合性、アクセス制御、障害対応、法令順守が必要になります。
AIが出したコードを理解しないまま、そのまま本番環境へ入れることはできません。
そこでKarpathyが使い始めたのが、Agentic Engineeringという言葉です。
彼は、vibe codingがソフトウェア開発の「床」を引き上げる一方で、Agentic Engineeringは優秀な開発者が到達できる「天井」を引き上げるものだ、と整理しています。
Agentic Engineeringでは、人間がコードを一行ずつ書くことが中心ではなくなります。
代わりに、人間は次のような仕事を担います。
- 何を作るべきかを定義する
- 要件や制約を言語化する
- AIが参照すべき文脈を整える
- タスクを適切な大きさに分解する
- アクセス権限と実行環境を設計する
- テストや評価基準を用意する
- AIが作ったものをレビューする
- 間違った方向へ進んだときに修正する
- セキュリティや長期的な保守性を守る
つまり、AIにすべてを丸投げする技術ではありません。
強力だけど確率的で、間違えることもあるAIを、品質を落とさずに使いこなす工学なんです。
Claude CodeのDynamic WorkflowsやClaude Tagは、このAgentic Engineeringを、個人の開発から組織全体の仕事へ広げる仕組みだと考えられます。
Software 3.0では「コンテキスト」がプログラムになる
Karpathyは、ソフトウェアの歴史をSoftware 1.0、2.0、3.0という3つの段階で説明しています。
Software 1.0は、人間が明示的なコードを書く世界です。
開発者がPython、Java、C++などを使って、コンピュータが実行すべき手順を一つずつ書いていきます。
Software 2.0は、ニューラルネットワークの世界です。
人間が直接ルールを書くんじゃなくて、データ、モデル構造、目的関数を用意して、学習によってプログラムの動作を作ります。
画像認識や音声認識では、人間がすべての判断条件を書くんじゃなくて、ニューラルネットワークの重みに知識が格納されます。
Software 3.0では、大規模言語モデルそのものが、自然言語でプログラム可能になります。
人間はモデルの重みを変えなくても、プロンプト、例、文書、ツール、メモリ、指示、評価基準をコンテキストとして与えることで、モデルの振る舞いを変えられます。
Karpathyは、LLMによってニューラルネットワークが「プログラム可能になった」という趣旨の説明をしています。
この世界では、コンテキストウィンドウが一種のプログラムになります。
たとえば、Claudeに次のような情報を渡すとします。
- 会社の方針
- 製品仕様
- コーディング規約
- 顧客の条件
- 過去の意思決定
- 利用できるツール
- 実行してよい操作
- 禁止されている操作
- 成功とみなす条件
- 出力してほしい形式
Claudeはそれらを読んで、状況に応じた処理をします。
従来のプログラムが「入力Aなら処理Bをする」と固定的に書かれていたのに対して、Software 3.0では、自然言語で表現された目的や制約を、LLMが状況に応じて解釈します。
だから、AI時代の開発力は、単なるプロンプトのうまさだけでは決まりません。
どの情報をコンテキストに入れるか。
どの情報を分離するか。
古くなった情報をどう更新するか。
モデルの判断を、どのテストで検証するか。
こういったことを設計する力が、重要になっていきます。
「文章を出すAI」から「インターフェースを作るAI」へ
Karpathyが2026年5月に投稿した、もう1つの重要な話があります。
AIの出力形式についての考察です。
彼は、LLMへの依頼の最後に「回答をHTMLとして構造化して」と加えて、ブラウザで表示する方法がよく機能する、と紹介しました。
HTMLはMarkdownよりも表現力が高いです。
文章や見出しだけじゃなく、レイアウト、グラフ、カード、画像、タブ、ボタン、アニメーション、操作できる要素を組み込めます。
AIの回答を「読む文章」から「操作できる成果物」に変えられるんです。
これは単なる見た目の改善ではありません。
長い調査結果がMarkdownで数百行表示されると、人間は中身を十分に読まずに、スクロールして終わってしまうことがありますよね。
同じ情報でも、重要な数値がダッシュボードに整理されて、比較項目が表になって、時系列がタイムラインとして表示されれば、ぐっと理解しやすくなります。
Karpathyの考えを整理すると、AIの出力は次の方向へ進んでいます。
生のテキストからMarkdownへ。
MarkdownからHTMLへ。
HTMLから、動きのあるインターフェースやシミュレーションへ。
最終的には、AIが文章で説明するだけじゃなく、理解したい対象をその場で可視化して、触って試せる環境を作るようになります。
たとえばAIに新しい経済政策を説明させる場合、長い文章を出すだけじゃなくて、税率や人口条件を変えられるシミュレーターを生成する。
新しい製品戦略を検討する場合、レポートを出すだけじゃなくて、顧客セグメントごとの売上予測を操作できるダッシュボードを作る。
学習用途では、物理現象を文章で説明するだけじゃなくて、パラメータを動かすと結果が変わる教材を作る。
AIの役割は「答えを書く」ことから、「人間が理解して、判断するための環境を生成する」ことへ広がっていきます。
Claude Fable 5が示した質的な変化
Anthropicは2026年6月9日、Claude Fable 5とClaude Mythos 5を発表しました。
Anthropicの説明では、Fable 5とMythos 5は同じ基盤モデルを使っています。
Fable 5は一般利用向けに強い安全策を加えたモデルで、Mythos 5はサイバー防御や重要インフラなど、信頼された利用者向けに一部の制限を調整したモデルとして設計されました。
Fable 5は、ソフトウェア開発、知識労働、視覚、長期記憶、科学研究などで、従来のClaudeを上回ると発表されました。
特に、仕事が長く複雑になるほど、以前のモデルとの差が大きくなる、というのがAnthropicの主張でした。
KarpathyはFable 5について、単なるベンチマークの改善じゃなくて、メジャーバージョンアップと呼ぶに値する質的な段差がある、という趣旨の評価をしています。
特に、長く複雑な問題を解かせたとき、以前よりずっと野心的な仕事を任せられると述べています。
モデルが意図をつかんで、長時間進み続ける感覚が強まって、コードを確認しなくてもいいんじゃないかと思うほどだ、としつつ、本番用途ではやっぱり人間がコードを見るべきだ、とも注意していました。
ここで大事なのは、モデル性能の評価軸が変わってきている、という点です。
これまでは、1つの質問に正しく答えられるか、短いコード問題を解けるかが注目されていました。
Fable 5で重視されたのは、長時間にわたって目的を保てるか、途中で得た情報を記憶できるか、自分の仮説を修正できるか、複数工程を最後まで完了できるか、という能力でした。
AIの価値は、一問一答の正答率から、人間がどれだけ大きな仕事を安心して任せられるか、へ移っているんです。
Fable／Mythosの停止が示した「能力と統治」の問題
ただし、Fable 5とMythos 5は、発表からわずか3日後の6月12日に利用停止になりました。
米国政府が国家安全保障上の権限を理由に、米国内外を問わず、外国籍の人がFable 5とMythos 5へアクセスできないように求める、輸出管理上の指示を出したからです。
外国籍のAnthropic従業員も、その対象に含まれました。
Anthropicは、利用者の国籍を完全に判別して制御するのが難しいため、指示に従うにはすべての顧客に対して両モデルを停止せざるを得なかった、と説明しています。
2026年6月25日の時点でも、公式には停止状態が続いています。
Anthropicによると、政府の懸念はFable 5の安全策を回避する、特定のjailbreak手法に関するものでした。
一方でAnthropicは、提示されたデモで見つかったのは既知の比較的小さな脆弱性で、他の公開モデルでも安全策の回避なしに見つけられる、と主張しています。
同社は、政府、英国のAI Safety Institute、外部組織、社内チームと、数千時間規模の安全性検証を行った、とも説明しています。
ここは、「AIが強すぎたから政府に禁止された」と単純化すべきではありません。
政府とAnthropicのあいだでは、具体的なリスクの大きさや、どのくらいの制限が妥当かについて、見解が食い違っています。
それでも、この出来事が象徴していることは大きいです。
モデルが便利なチャットボットであるうちは、主な問題は誤情報や不適切な回答でした。
でも、モデルがソフトウェアの脆弱性を探して、コードを書いて、長時間自律的に作業して、重要システムへ影響を与えられるようになると、AIモデルは国家安全保障や輸出管理の対象になり得ます。
AIが「情報を出す技術」から「現実世界で能力を行使する技術」へ移るほど、権限と規制の問題が大きくなっていきます。
AI Exponentialが意味するもの
Anthropicは、この急速な能力向上を「AI Exponential」という政策的な枠組みで捉えています。
同社の主張は、AIの進歩が指数関数的に進む一方で、法律、政策、企業制度、教育制度は、もっと遅い技術進歩を前提に作られている、というものです。
そのためAnthropicは、強力なAIシステムに対する透明性、独立した能力評価、危険なデプロイを政府が止める権限などを含むAdvanced AI Frameworkと、労働市場や富の分配への影響を扱うEconomic Policy Frameworkを提案しています。
この考え方は、Karpathy本人が作った政策ではありません。
ただ、Karpathyが「今後数年はLLMのフロンティアにとって特に形成的だ」と述べてAnthropicへ入ったことと、AnthropicがAI Exponentialを掲げていることは、同じ方向を向いています。
両者が見ているのは、AIが少しずつ便利になる未来ではありません。
AIの能力、働き方、研究速度、企業構造、規制のあり方が、短い期間のうちに同時に変わる未来です。
AIがAIを作る「再帰的自己改善」は始まっているのか
Anthropicは2026年、社内でClaudeが開発作業へ与えている影響について、いくつかのデータを公開しました。
同社によると、2026年5月の時点で、Anthropicのコードベースへマージされたコードの80%以上が、Claudeによって作成されています。
Claude Codeが研究プレビューとして登場する前は、その割合は数%程度だったそうです。
また、2026年第2四半期には、エンジニア一人あたりが1日にマージするコード量が、2024年の約8倍になった、としています。
ただしAnthropic自身も、コードの行数は品質や実際の生産性を正確に表す指標ではなくて、8倍という数字は本当の生産性向上を過大評価している可能性が高い、と注意しています。
同社は、2026年3月に研究部門の従業員130人へ行った調査で、Claude Mythos Previewによって自分のアウトプットが平均で約4倍になった、という自己評価が得られたとも報告しています。
これについても、主観的な評価であって、実際の上昇幅はもっと小さい可能性がある、と認めています。
さらに2026年4月には、ClaudeがAPIエラーの一種を減らすために800件以上の修正を行って、エラー発生を約1000分の1にした、という事例が紹介されました。
担当エンジニアは、同じ作業を人間だけでやれば約4年かかった可能性がある、と見積もっています。
こうした事例を見ると、限定された意味では、AIによるAI開発の加速はすでに始まっています。
ClaudeがAnthropicの開発ツールや学習基盤を改善する。
改善された基盤によって、次のClaudeをより速く研究できる。
新しいClaudeが、さらに多くの研究や開発を支援する。
ただし、「完全に自律したAIが、自分を無制限に改善している」わけではありません。
研究テーマの選択、実験設計、計算資源の配分、安全性の判断、モデル公開の決定は、いまも人間と組織が行っています。
いま起きているのは、自律的な知能爆発というより、人間が管理する研究開発ループの各工程にAIが入って、その回転速度を上げている状態、と考えるほうが正確です。
KarpathyがClaudeを使ったpretraining研究に取り組む意味も、ここにあります。
人間の専門性は不要になるのか
AIが大量のコードを書けるようになると、「エンジニアの知識はもういらないんじゃないか」と考えたくなりますよね。
でも、Anthropicが約23万5000人による約40万件のClaude Codeセッションを分析した研究では、少し違う結果が出ています。
この研究では、人間とClaudeのあいだに、いまの時点で比較的はっきりした役割分担が見られました。
人間が「何を作るか」を決めて、Claudeが「どう作るか」を決める、という分担です。
しかもセッションを成功させるうえでは、単なるコーディング能力よりも、その問題領域についての知識のほうが重要でした。
対象の業務を理解している人ほど、AIが間違えたときに気づきやすくて、誤解が生じたときに直しやすくて、最終的な成功率も高かったんです。
Anthropicは、コーディングエージェントが専門知識を代替しているんじゃなくて、専門知識を持つ人の能力を増幅している、と分析しています。
たとえば、医療業務用のソフトウェアを作る場合、AIはコードを書けます。
でも、どの情報が臨床的に重要か、どの判断を自動化してはいけないか、何を誤ると患者に危険が生じるかを理解するには、医療分野の知識が必要です。
会計ツールでも、AIは計算処理を実装できます。
でも、どの取引をどう分類するか、どの国の規制が適用されるか、どの例外を人間が確認すべきかを決めるには、会計や法務の専門性が必要になります。
AI時代に価値が下がりやすいのは、決められた仕様をそのままコードへ変換する作業です。
一方で価値が上がるのは、次のような力です。
- 本当の問題を特定する力
- 要件を明確にする力
- 正しい評価基準を作る力
- AIの出力を疑う力
- 専門領域の例外を理解する力
- 複数の利害や制約を調整する力
- 最終的な責任を引き受ける力
AIが実装を担うほど、人間には「何を実装すべきか」と「それは本当に正しいか」を判断する力が求められます。
「書く力」より「任せる力」が重要になる
従来のソフトウェア開発では、優秀さはコードを書く速さや、技術的な詳細を知っていることと、強く結びついていました。
Agentic Engineeringでは、それに加えて「任せ方」の能力が重要になります。
ただ、これはプロンプトをきれいに書く、というだけの話ではありません。
曖昧な仕事をAIに丸投げすると、AIは曖昧なまま実行します。
生成スピードが速いぶん、間違った方向にも速く進んでしまうんです。
優れた委任には、いくつかの要素があります。
まず、目的が明確であること。
「売上を分析して」じゃなくて、「過去12カ月の売上を製品・地域・顧客規模で分解して、減少要因を特定して、根拠となるデータと一緒に優先度の高い3つの施策を出して」と依頼します。
次に、制約が明確であること。
使ってよいデータ、変更してよいファイル、守るべき法律、触れてはいけないシステム、使える時間や予算を指定します。
さらに、完了条件が明確であること。
テストがすべて通る、既存APIとの互換性を保つ、数値の出典を示す、意思決定者が10分以内に理解できる形式にする、といった基準を用意します。
最後に、検証の方法があること。
別のエージェントにレビューさせる。
既存テストを実行する。
複数の情報源を照合する。
重要な操作では、人間の承認を必要にする。
AI時代の「任せる力」は、管理職の能力とよく似ています。
だからこそ、Claude Tagを使った人が、全員がマネージャーになったように感じる、という表現が出てくるんですね。
ただし、これは必ずしも人間を管理するという意味ではありません。
複数のAIへ仕事を分けて、進捗を確認して、結果を統合する、プロセスマネージャーになるという意味です。
AIが入ると組織構造も変わる
Claude Tagが広まると、変わるのは個人の生産性だけではありません。
組織の仕事の流れそのものが、変わる可能性があります。
これまで、仕事は人から人へ受け渡されていました。
営業担当者が顧客の要望を聞いて、プロダクトマネージャーが要件を整理して、エンジニアが実装して、データ担当が効果を分析して、サポート担当が顧客へ案内する。
それぞれの工程には待ち時間があって、説明のやり直しがあって、情報の欠落も起きます。
組織の中のClaudeが、営業、開発、分析、サポートの文脈にアクセスできるようになると、Claudeが一部の受け渡しをつなげられます。
たとえば顧客から不具合報告が来た場合、Claudeがサポートチャンネルから内容を読んで、ログを調べて、関連するコード変更を確認して、原因候補をまとめて、必要なら修正用のプルリクエストを作って、進捗を同じSlackスレッドへ返します。
これまで複数人が複数のシステムを移動してやっていた調整作業を、1つのエージェントが横断して進めるわけです。
このとき、組織の競争力は「誰が一番高性能なAIを契約しているか」だけでは決まりません。
社内情報が整理されているか。
業務ツールにAPIがあるか。
アクセス権限が明確か。
成果物を自動で検証できるか。
意思決定が記録されているか。
AIへ仕事を渡せるように、業務が構造化されているか。
こうしたAgent Readinessが重要になります。
ドキュメントが古くて、権限が混乱していて、決定事項が口頭でしか共有されなくて、成果の評価基準が存在しない組織では、どれだけ高性能なAIを入れても、十分に働かせられません。
SaaSは「画面を使うもの」から「AIが操作するもの」になる
Claude Tagのようなエージェントが企業の中に入ってくると、既存のSaaSにも影響が出ます。
いまのSaaSは、人間が画面を開いて操作することを前提にしています。
CRMなら顧客画面を開いて、項目を更新する。
分析ツールならダッシュボードを開いて、条件を設定する。
プロジェクト管理ツールならチケットを作って、担当者を割り当てる。
AIエージェントが操作の主体になると、人間が各SaaSの画面を直接触る頻度は減る可能性があります。
人間はSlack上で、こんなふうに依頼します。
「今週失注した案件を分析して」
「重要な顧客から来ている未回答の問い合わせを整理して」
「昨日のリリース以降に悪化した指標を調べて」
そうすると、ClaudeがCRM、メール、分析基盤、コードベース、チケットシステムを横断して、結果だけを返します。
この世界では、SaaSの価値は人間向けの画面だけじゃなくて、AIが安全に操作できるAPI、権限設計、監査ログ、データ品質へ移っていきます。
また、料金体系も、一人あたりの月額課金から、処理した仕事量、使った計算資源、完了した成果物などを基準にした形へ変わる可能性があります。
これはいまの時点では将来予測ですが、Claude Tagが示している方向から、自然に導かれる変化です。
ソフトウェアの需要は減るのか、それとも増えるのか
AIによってソフトウェアが簡単に作れるようになると、ソフトウェアエンジニアの仕事が減ると考えられがちです。
でもKarpathyは、ソフトウェア生成のコストが下がることで、むしろ作られるソフトウェアの量が大幅に増える可能性を示しています。
これまでは、小さな業務のためだけに専用アプリを作るのは、割に合いませんでした。
数日しか使わない分析ツール。
一度だけ行うデータ移行用の画面。
特定の顧客専用のレポート生成システム。
社内イベントだけで使う管理アプリ。
1つの研究プロジェクト専用の可視化ツール。
開発費が高いので、人間は表計算や手作業で代用してきました。
AIによってソフトウェア生成のコストが大きく下がれば、こういった一時的・個別的なソフトウェアも作れるようになります。
ソフトウェアが安くなることで、需要が減るんじゃなくて、これまで存在しなかった需要が表に出てきます。
これはJevonsのパラドックスに近い話です。
ある資源を使う効率が上がると、使用量が減るんじゃなくて、用途が広がって総消費量が増えることがある、というものです。
コードを書く仕事の単価は、下がるかもしれません。
でも、「自分たちの問題に合わせてソフトウェアを作る」という行為は、あらゆる職種へ広がる可能性があります。
AnthropicのClaude Code利用分析でも、コード修正だけじゃなく、ソフトウェアの運用、データ分析、文章やプレゼンテーションの作成へと、用途が広がっています。
2025年10月から2026年4月にかけて、コード修正が占める割合は低下して、ソフトウェア運用、データ分析、文書作成が増加しました。
つまり、プログラミングが1つの専門職だけの仕事じゃなくて、一般の知識労働に組み込まれていく可能性がある、ということです。
それでも「AI同僚」を無条件に信じてはいけない
Claude Tagを「同僚」と表現すると、人間と同じように信頼できる存在だと誤解される危険があります。
実際には、AIエージェントには重大な制約があります。
AIは自信を持って間違える
モデルは、もっともらしい推論や説明を作れても、それが正しいとは限りません。
長時間のタスクでは、小さな誤解があとの工程へ伝わって、最終成果の全体を間違ったものにしてしまう可能性があります。
Opus 4.8では、根拠のない進捗報告や、作成したコードの問題を見落とす割合が改善された、とAnthropicは説明しています。
それでも、問題がなくなったわけではありません。
文脈が多ければよいとは限らない
大量のSlack会話を読めることは利点ですが、その中には古い方針、冗談、誤情報、未確定のアイデアも含まれます。
AIが、何を正式な決定として扱って、何を単なる会話として扱うかを、間違える可能性があります。
「文脈を覚えるAI」には、忘れる仕組み、訂正する仕組み、情報の権威性を示す仕組みも必要になります。
権限が強いほど事故の影響も大きい
読み取り専用のAIが間違えても、被害は限定的です。
でも、コードを変更できる、メールを送れる、顧客データを更新できる、本番システムを操作できるAIが間違えれば、現実の損害につながります。
だからこそ、タスクごとに最小限の権限を与えて、重要な操作には人間の承認を入れる必要があります。
監査可能性が必要になる
AIが何を読んで、どのツールを使って、どの判断で操作したのかを、あとから確認できなければ、事故の原因を調べられません。
特に金融、医療、法律、公共インフラでは、最終結果だけじゃなく、作業履歴と責任の所在が重要になります。
組織内の会話が萎縮する可能性がある
Claudeがチャンネルの会話から継続的に学ぶようになると、従業員が「この発言もAIに記憶されるのか」と感じる可能性があります。
自由なブレインストーミング、失敗の共有、未完成なアイデア、個人的な相談がしにくくなるかもしれません。
AIを参加させるチャンネルと、人間だけで話すチャンネルを、意識的に分ける必要があります。
ベンダーロックインも起きる
AIが長期間にわたって、組織の知識、仕事の履歴、専用ツール、評価ルールを蓄積すると、そのAI基盤から別のサービスへ移るコストが高くなります。
モデルの性能だけじゃなく、記憶、権限設定、コネクター、監査データを移行できるかが重要になります。
Claude Tagが「同僚」になるほど、その同僚を別の会社のAIへ交代させる難しさも増していきます。
企業は何から始めるべきか
Claude TagやAgentic Workを導入するとき、最初から会社全体の仕事をAIへ任せるべきではありません。
まずは、結果を確認しやすくて、失敗しても被害が小さくて、繰り返し発生する仕事を選ぶのが現実的です。
たとえば、次のような仕事が候補になります。
- 定期的な指標の集計
- 社内文書の整理
- 未回答チケットの分類
- コードベース内の重複や古い処理の調査
- テストケースの追加
- 会議内容からのタスク抽出
- 既存データを使った定型レポート作成
次に、その仕事の完了条件を明確にします。
「よいレポートを作る」では、曖昧すぎます。
必要な項目、利用できる情報、数値の出典、提出形式、確認者、期限、誤りがあった場合の対応を定義します。
権限は、最初は読み取り専用にします。
AIが安定して動くことを確認してから、下書き作成、テスト環境での変更、承認付きの実行へと、段階的に広げます。
さらに、AIが使う情報の品質を整えます。
正しい仕様書、最新の手順、意思決定の記録、用語集、データ定義がなければ、AIは不完全な文脈をもとに仕事をしてしまいます。
そして、人間のレビューを単なる最終確認にしないことも大事です。
何を重点的に確認するか、どんな誤りが起こりやすいか、どの結果なら自動承認できるかを決めます。
レビューの結果を、次の指示や評価基準へ反映していきます。
AI導入の本質は、社員にプロンプト講座を受けさせることではありません。
仕事を、AIへ安全に委任できる構造へ作り替えることなんです。
Karpathyが見ている「AIの次の姿」
2026年5月以降のKarpathyの発信を1つにつなげると、彼が見ている方向はかなりはっきりしてきます。
1つ目は、AIの能力が一問一答から長時間の仕事へ移っていることです。
Claude Opus 4.8、Dynamic Workflows、Fable 5では、AIが大きな目標を複数工程に分解して、長時間作業して、複数のサブエージェントを動かして、結果を検証する方向へ進みました。
2つ目は、AIのインターフェースがチャット画面から組織へ移っていることです。
Claude Tagによって、AIは個人が訪れるWebサイトでも、個人のパソコンに入れるアプリでもなくなって、チームの会話、ツール、データ、コードベースの中に常駐するようになります。
3つ目は、ソフトウェアの作り方が変わっていることです。
Software 3.0では、コードだけじゃなく、プロンプト、コンテキスト、ツール、メモリ、権限、評価基準が、プログラムの一部になります。
4つ目は、人間の仕事が実行から設計へ移っていることです。
AIがコードや資料を作るほど、人間には問題設定、仕様、判断、専門知識、評価、セキュリティ、責任が求められます。
5つ目は、AI研究そのものがAIによって加速されることです。
KarpathyはAnthropicのpretrainingチームで、Claudeを使ってClaudeの研究を進めます。
AIが研究開発ループの内部に入って、次のAIを作る速度を上げていきます。
そして6つ目は、AIの能力向上が技術だけの問題ではなくなったことです。
Fable 5とMythos 5の停止が示したように、強力なAIは国家安全保障、輸出管理、サイバーセキュリティ、企業統治、労働市場の問題と、直接つながっています。
AIは「使うもの」から「一緒に働くもの」へ
Claude Tagを見て、「SlackでClaudeが使えるようになっただけ」と考えることもできます。
実際、構成要素の一つひとつは、新しくありません。
Slackボットも、RAGも、AIエージェントも、ツール連携も、長期記憶も、非同期タスクも、それぞれ以前から存在しています。
でも、技術の転換点は、必ずしも完全に新しい発明から生まれるわけじゃありません。
既存の技術が十分な品質で組み合わさって、実際の仕事の中で自然に使えるようになったとき、人の行動様式が変わります。
スマートフォンも、電話、カメラ、GPS、インターネットという既存技術を1つにまとめたものでした。
重要だったのは個々の技術じゃなくて、それらが常に持ち歩ける形で統合されたことです。
Claude Tagも、同じ可能性を持っています。
モデル、ツール、記憶、権限、実行環境、Slack、コードベース、監査を1つにまとめて、AIを組織の仕事の流れへ入れます。
この変化が進むと、AIは特別なときに開くサービスではなくなります。
人間の同僚と同じチャンネルにいて、仕事を頼まれて、進捗を報告して、過去の経緯を覚えて、必要なツールを使って、完成物を返します。
ただし、それは人間と同じ同僚ではありません。
法的責任を負わなくて、常識が不均一で、もっともらしく間違えて、権限を誤れば大きな損害を起こし得る同僚です。
だからこそ、人間はAIを擬人化して信頼するんじゃなくて、権限、評価、監査、承認、停止手段を備えたシステムとして管理しないといけません。
最後に
Karpathyが2026年に示している、いちばん重要なメッセージは、「AIがさらに賢くなる」というだけではありません。
AIは、新しいプログラム可能な層になりました。
そして、その層はチャット画面の中から出て、パソコン、コードベース、研究環境、Slack、企業組織へ入り始めています。
これから重要になる問いは、「どのAIモデルが一番賢いか」だけじゃありません。
AIを組織のどこに置くのか。
どの情報とツールにアクセスさせるのか。
どの仕事を任せて、どの判断を人間に残すのか。
AIの成果を、何によって評価するのか。
間違えたときに、誰が止めて、誰が責任を持つのか。
Claudeは、チャットボットから同僚へ近づいています。
でも、その未来の本当の競争力は、Claudeを導入したことでは決まりません。
AIが働ける文脈、権限、評価、組織文化を設計して、人間とAIの役割を正しく分けられるかどうかで決まります。
Karpathyが見ているのは、AIに人間の仕事がすべて奪われる、単純な未来ではありません。
人間が一つひとつの作業を行う世界から、AIに目的を渡して、複数のAIを動かして、成果を評価して、より大きな仕事を進める世界への移行です。
AIは、検索窓ではなくなりつつあります。
コード補完でもなくなりつつあります。
次に現れるのは、組織の中に入って、人間のチームと並んで働く、継続的な作業主体としてのAIです。
そしてClaude Tagは、その未来が単なる予想じゃなくて、すでに実際の製品として始まっていることを示しています。
