はじめに
Fable 5 が実務に復帰し、Claude Tag は Slack と接続されるようになりました。この変化は、単にモデルが強力になったとか、チャットインターフェースがひとつ増えたという話ではありません。これはソフトウェアエンジニアリングにおける、より大きな転換を示しています。AI は「次の1行を書くのを手伝って」から、「このタスクを引き受けて、進めて、プルリクエストを持って戻ってきて」へと移行しているのです。
それに伴い、人間のエンジニアが担う役割も変わります。AI エージェントが何時間も、あるいは何日も動き続け、ツールを呼び出し、コードを書き、結果を分析し、PR を作成できるようになると、人間にとって最も価値のあるスキルは、単に素早くコードを書くことだけではなくなります。重要になるのは、タスクを適切に定義すること、受け入れ基準を設定すること、結果を確認すること、そして AI の作業を安全にマージしてよいかを見極めることです。

出典注記:この記事は、BAAI Hub の記事「Fable 5解禁即上岗,工程师改行当『验收员』」をもとにした、英語による SEO 向けオリジナル再構成版です。元ページには、記事の出典が WeChat であると記載されています。逐語訳ではありません。宣伝画像、QR コード、本文と関係のない装飾画像は除外しています。また、後半のコメント部分付近にあったインライン画像のひとつは、抽出時に信頼できる形で取得できなかったため、挿入していません。
コーディング支援から AI チームメイトへ
AI 支援プログラミングの初期段階はシンプルでした。ひとりの人間がエディタの前に座り、モデルが次の1行を提案したり、関数の補完を手伝ったりするという形です。主導権は依然として人間が握っていました。次に何をするかを毎回決め、小さな変更をひとつひとつ確認し、手動でプロジェクトを前に進めていたのです。
その後、より並列的なワークフローが登場しました。ひとりの開発者が、複数の Claude セッションを同時に走らせることができるようになったのです。あるセッションは機能を実装し、別のセッションはバグを修正し、さらに別のセッションはデータを調査する、といった具合です。エンジニアは、もはやただ入力するだけの存在ではなくなりました。調整役になったのです。
そして今、Claude Tag はそのワークフローをチーム空間へと押し広げています。Claude は Slack 内で動作し、チャンネルで共有される文脈を読み取り、チームメイトのようにタスクへタグ付けして参加できます。やり取りは「チャットボットに質問する」というより、「チーム全体から見えるエージェントに仕事を委任する」に近いものになります。

Anthropic による Claude Tag の発表によれば、Claude Tag はまず Slack で始まり、チームは選択したチャンネル、ツール、データ、コードベースへのアクセスを与えることができます。アクセスが設定されると、チャンネル内の人々は @Claude をタグ付けし、自分たちは他の優先事項に取り組みながら作業を委任できます。
それこそが本当の違いです。モデルはもはや
もはや単なるコード補完レイヤーではありません。タスク、ツール、コンテキスト、レビューを備えた共同ワークフローの一部になるのです。
1人でもClaude部隊を持てる
Anthropicは、Claude TagをClaude Codeの進化形として説明しています。Claude Codeは引き続き、コードベースを直接扱うためのツールです。ファイルの読み取り、コード編集、コマンド実行、バグ修正、変更作成を担います。Claude Tagは、それに加えてSlack上でチーム向けの入口を提供します。
実際には、この3つの要素は次のように機能します。
| コンポーネント | 主な役割 | もたらす変化 |
|---|---|---|
| Claude Code | コード実行とコードベース作業 | ファイル編集、コマンド実行、変更のテスト、コード修正の作成を支援する。 |
| Claude Tag | Slackでのチーム向けタスク委任 | チームがスレッドやチャンネル内でClaudeを呼び出し、共有コンテキストから作業を割り当てられるようにする。 |
| Fable 5 | 高性能なモデルレイヤー | より野心的で、長時間にわたり、複数段階にまたがるエージェント作業を支える。 |
Claude Codeは「手」です。Claude Tagは、チームが作業を割り当て、進捗を追跡する場です。Fable 5は、その下で大きなタスクを支える、より強力なエンジンです。

Anthropic自身の製品資料によれば、Claude Tagは、長いスレッドの内容把握、数値の抽出、バグ報告をPRドラフトに変換すること、通話準備、チャンネル監視といったタスクに使えます。これらは単発のプロンプトではありません。コンテキストと、権限管理されたツールアクセスに依存するワークフローです。
開発者にとって、これは近いうちに1人で複数のAIワークストリームを同時に管理するようになることを意味します。あるClaudeはバグを調査し、別のClaudeは移行計画のドラフトを作成し、さらに別のClaudeはメトリクスを監視したりレポートを準備したりできます。人間がいなくなるわけではありませんが、その役割は一段上のレイヤーへ移ります。
Claude Code、Claude Tag、Fable 5はそれぞれ役割が異なる
これらの名前は混同しやすいですが、同じものではありません。
Claude Codeは、エージェント型のコーディングツールです。Claudeがコードベースを理解し、ファイルを編集し、ターミナルコマンドを実行し、開発ツールと連携し、実際に動く変更を出荷できるよう支援してほしい開発者向けに設計されています。
Claude Tagは、共同作業のためのインターフェースです。Slack上に存在し、チームが共有された会話から作業を割り当てられるようにします。別のチャットウィンドウを開く代わりに、チームメンバーは、バグ報告、プロダクトに関する質問、データ要求がすでに存在する同じスレッド内でClaudeにメンションできます。
Fable 5は、より難しく長期的な作業のために構築されたモデルレイヤーです。AnthropicのFableページでは、長時間続くエージェントセッション、大規模な移行、複雑な実装、複数段階のタスクなどを含む、野心的なコーディングや専門業務のためのモデルとして説明されています。
要するに、
- Claude Codeはコードベースを扱う。
- Claude Tagはチームへの委任と共有された可視性を担う。
- Fable 5は、エージェントが試みられることの上限を引き上げる。
これらが組み合わさることで、AIコーディングは単一ユーザー向けのアシスタントから、チームのワークフローシステムへと変わります。
エンジンはFableだ
5
Claude Tagは入口であり、Claude Codeは作業環境です。しかし、エージェントが破綻する前にどれだけの複雑さを扱えるかを決めるのは、モデルそのものです。
Fable 5が重要なのは、長時間にわたる多段階の作業を対象としているからです。AnthropicのFableページでは、このモデルはClaude CodeやClaude Managed Agentsのようなエージェント実行環境で何日にもわたって作業でき、段階をまたいだ計画立案、サブエージェントへの委任、自身の作業の検証まで行えると説明されています。
だからこそ、議論の焦点は短いコードスニペットから、完全なタスクへと移りつつあります。より強力なエージェントは、単に1つの質問に答えるだけではありません。より大きな目標を追跡し、それを段階に分解し、作業を進め、人間がレビューできる成果物を持ち帰ることができます。
この記事の要点は、エンジニアがコードベース全体を無批判に丸ごと渡すべきだということではありません。より有益な示唆はこれです。作業単位が大きくなっているのです。以前は1つの関数に対するプロンプトだったものが、今ではレビュー可能な小さなプルリクエストの依頼になり得ます。
長期的なエージェントはシステムの問題である
長時間稼働するエージェントの作業は、モデルだけの問題ではありません。周辺システム、つまりメモリ、タスクの引き継ぎ、ツール、権限、テスト、ログ、レビューのチェックポイントにも依存します。
元の記事では、「シフト引き継ぎ」の問題が例として使われています。エージェントが別々のセッションで作業する場合、新しいセッションごとに重要なプロジェクト文脈が失われる可能性があります。モデルは1回であまりにも多くを終わらせようとしてコンテキストウィンドウを過負荷にしたり、部分的な進捗を完了と取り違えたりするかもしれません。
よりよいアプローチは、段階的なワークフローです。
- 初期化エージェントが環境をセットアップする。
- タスクリストと進捗ファイルを作成する。
- 各コーディングエージェントが、範囲の明確な1つの作業を担当する。
- 進捗をコミットし、記録する。
- 次のエージェントが、明確な引き継ぎ地点から作業を続ける。
- 人間が受け入れる前に結果をレビューする。
だからこそ、エージェント型コーディングは、単なるプロンプト作成ではなく、エンジニアリングプロセスの設計として扱うべきなのです。モデルは重要ですが、結果が安全で実用的なものになるかどうかを決めるのは、モデルを取り巻くワークフローです。

METRによる長時間タスク評価の研究は、ここで有益な文脈を提供しています。METRは、AIの能力は静的なベンチマークスコアだけでなく、モデルが完了できるタスクの長さによって測定すべきだと主張してきました。彼らの研究は、50%のタスク完了時間の地平線が時間とともにどのように伸びてきたかを追跡しています。これはより大きな論点を支持しています。すなわち、エージェントがより長いタスクを扱えるようになるほど、人間によるレビューとタスク設計はますます重要になるということです。
プルリクエストが新たな成果物単位になりつつある
一般の開発者やチームにとって、最も安全な出発点は「AIにすべてを任せる」ことではありません。よりよい出発点は、テストとレビューが可能な、低リスクで境界が明確なタスクを与えることです。
数分で紹介サイトを作り、リード獲得を伸ばす
アイデアを一文で入力するだけで、We0 AI が紹介サイト、ページ、CMS を生成し、公開後の顧客獲得と流入拡大を支援します。
適した候補には、次のようなものがあります。
- 再現手順が明確な小さなバグ修正。
- スクリーンショット付きのUI調整、または
視覚的な受け入れ基準。
- 既存の挙動に対するテスト追加。
- 既知の機能に紐づくドキュメント更新。
- 期待される出力形式が明確なデータチェック。
- テストでカバーされており、容易にロールバックできるリファクタリング。
境界線は、チームにAIを信頼するだけの勇気があるかどうかではありません。境界線は、チームが適切な粒度で作業を定義できるかどうかです。

AnthropicのClaude Tagに関する発表によれば、同社のプロダクトチームのコードの65%は、社内版のClaude Tagによって生成されています。これは、プルリクエストの65%が完全自律で作られているという意味でも、人間がもはやコードレビューをしないという意味でもありません。これは、そのワークフローの中で、AI生成コードが開発プロセスの主要な一部になったことを意味します。
重要な考え方は、プルリクエストが委任の実務的な単位になるということです。人間はすべてのキーストロークを確認する必要はありません。代わりに、人間はPRをレビューし、テストを確認し、要件を検証し、その変更をマージすべきかどうかを判断します。

新しい閾値はプロンプトではない
AIコーディングツールが主にプロンプト駆動だった頃は、より上手に質問できる人に優位性がありました。プロンプトは今でも重要ですが、もはやそれがすべてではありません。
AIが複数日にわたるタスクを実行し、プルリクエストを作成できるようになると、人間の優位性は受け入れ設計へと移ります。エンジニアとプロダクトチームは、エージェントが作業を始める前に、「完了」とは何を意味するのかを明確に定義する必要があります。
実用的なAIタスクには、次の要素を含めるべきです。
- 明確な目標: 何を変更または生成すべきか。
- 狭い境界: どのファイル、システム、または挙動に手を触れてはいけないか。
- 受け入れ基準: 作業を受け入れる前に何が真でなければならないか。
- テスト要件: 追加または実行すべきテストは何か。
- レビューチェックリスト: 人間のレビュアーが何を確認しなければならないか。
- ロールバック計画: 問題が発生した場合に変更をどう元に戻すか。
これこそが本当の新しいスキルです。コードを書くことは簡単になりつつあります。安全にコードを受け入れることは、より難しくなりつつあります。
これがエンジニアにとって意味すること
エンジニアの役割が消えつつあるわけではありません。再編成されつつあるのです。
将来のエンジニアリングのワークフローは、次のようなものになるかもしれません。
| 従来のワークフロー | 新しいAIエージェントのワークフロー |
|---|---|
| 自分でコードを書く | タスクと受け入れ基準を定義する |
| AIに関数を依頼する | AIにレビュー可能なPRを依頼する |
| ツールを手動で切り替える | エージェントに承認済みツールを使わせる |
| 生成された各行をすぐにレビューする | 最終的な差分、テスト、ログ、挙動をレビューする |
| 一度に1つのタスク | 複数のAI作業ストリームを並行して進める |
最も優れたエンジニアには、引き続き技術的判断力が求められます。むしろ、判断力はさらに重要になります。
出力量が増えるため、より重要になります。AI生成コードが増えるということは、レビュー判断が増え、リスク管理が増え、強力なエンジニアリング基準の必要性が高まることを意味します。
これが、「AI作業レビュアー」が地位の低い役割ではない理由です。むしろテクニカルリードに近い役割であり、何の作業を行うべきかを判断し、品質基準を定め、不適切な変更が本番環境に到達するのを防ぎます。
FAQ
Claude Tag とは何ですか?
Claude Tag は、Anthropic の Slack ベースのチーム向け AI エージェントです。管理者がアクセスと権限を設定していれば、チームは Slack のチャンネルやスレッドで @Claude にメンションし、共有された文脈に基づいてタスクを割り当てることができます。
Claude Tag は Claude Code とどう違うのですか?
Claude Code は、ターミナル、IDE、ブラウザ、デスクトップ、Slack などの開発者向け環境を通じてコードベースを扱うことに重点を置いています。Claude Tag は Slack 上でのチームコラボレーション向けに設計されており、Claude は共有された会話から作業を割り当てられ、スレッド内で進捗を報告できます。
Fable 5 は何に使われますか?
Fable 5 は、意欲的なコーディング、長時間にわたるエージェント作業、複雑な専門業務のための Anthropic の高性能モデルです。ここで関連があるのは、より強力で長期的な対応が可能なモデルによって、エージェントが多段階のワークフローを完了することがより現実的になるためです。
Claude Tag はプルリクエストを自動的に作成しますか?
Claude Tag は、接続されたリポジトリなど適切なツールへのアクセス権があれば、バグレポートやタスクをドラフト PR に変換する支援ができます。それでも、人間のレビュアーが変更内容を確認し、テストを検証し、マージするかどうかを判断する必要があります。
AI コーディングは本番業務に対応できる段階ですか?
AI コーディングは、タスクの範囲が限定され、テストされ、レビューされている場合には、本番ワークフローで有用です。受け入れ基準、テストカバレッジ、権限管理、ロールバック計画なしに、大規模で曖昧な変更を任せるのは危険です。
AI エージェントがより多くのコードを書くようになると、どのようなスキルがより重要になりますか?
タスク定義、システム設計、テスト、コードレビュー、セキュリティ判断、プロダクトに関する意思決定がより重要になります。エンジニアは、どのように境界を設定し、AI が生成した成果物が正しいかどうかを検証するかを理解している必要があります。
チームはまず AI エージェントに大規模な移行作業を任せるべきですか?
ほとんどのチームは、より小規模で低リスクなタスクから始めるべきです。高度なエージェント構成であれば大規模な移行も可能かもしれませんが、そのためには強力なテストカバレッジ、段階的な引き継ぎ、明確な責任分担、そして慎重な人間によるレビューが必要です。
関連ツール
- Claude Tag: 共有されたチームチャンネル内でタスクを割り当てるための、Slack ベースの Claude 体験。
- Claude Tag Documentation: セットアップ、使用方法、セキュリティ、管理者統制によるアクセスに関する公式ドキュメント。
- Claude Code: コードベースの読み取り、ファイル編集、コマンド実行、変更のリリース支援を行う Anthropic のエージェント型コーディングツール。
- Claude Fable: 提供状況、ユースケース、安全対策、ベンチマークを含む、Anthropic の Fable モデル紹介ページ。
- Slack: Claude Tag が最初に利用可能になっているコラボレーションプラットフォーム。
- GitHub: 一般的に使用されているリポジトリおよびプルリクエストのワークフロー。
AI支援開発。
- METRのタイムホライズン: AIがタスクを完了するまでの時間的範囲を追跡する研究リソース。
関連リンク
- BAAI Hubの元記事: この英語版の元になった中国語の記事。
- Claude Tagの紹介: Claude Tagに関するAnthropicの公式発表。
- Claude Tagの活用方法: Claude Tagの仕組みと、チームでの活用方法を説明する公式ドキュメント。
- Claude Code製品ページ: Claude Codeとその開発ワークフローの公式概要。
- Claude Fableモデルページ: Claude Fable 5に関する公式モデル情報。
- Fable 5の再展開: Fable 5の提供状況と安全対策に関するAnthropicの更新情報。
- AIの長時間タスク完了能力の測定: 長期的なAIのタスク完了能力の測定に関するMETRの研究記事。
- 最先端AIモデルのタスク完了時間のタイムホライズン: 最先端モデルの時間的ホライズン測定に関するMETRの最新版ページ。
要約
Claude TagとFable 5は、AIによるソフトウェアエンジニアリングの明確な方向性を示している。AIはもはや、1行のコードを書くことや短いプロンプトに答えることだけにとどまらない。共有されたチームのワークフロー、長時間にわたるタスク、そしてPRレベルの成果物へと進みつつある。
だからといって、エンジニアがプロセスから外れるわけではない。変わるのは、エンジニアリングのスキルが最も重要になる場所である。人間の役割は、タスクの定義、受け入れ基準の設定、テスト、レビュー、そしてマージ判断へと移っていく。
次に重要となるエンジニアリングスキルは、単により良いプロンプトを書くことではない。AIが生成した成果物をどのように定義し、検証し、安全に受け入れるかを理解することだ。



