対話型AIやエージェント型でいうと、Claude Chat Claude Design Claude Code Claude Cowork Claude in Chrome 、Claude 内蔵機能では、Projects Artifacts Memory Skills Plugins Connectors / MCP Monthly recap、APIなどの開発者基盤では、Claude API（Claude Developer Platform） Claude Agent SDK Managed Agents Console / Playground などなど。
業務ツールへの組み込みツールも、Claude Tag（Slack） Claude for Microsoft 365 Claude for Governmentなどなど。こういうのを無造作に提示されても、意味がわからないです。ただ、必要なものを使うと自ずとその次に必要なものが明確になってきます。
しかしながら、これまでの事物の整理の仕方をちょっとやめて、新しい概念として位置づけるのがベストです。実際に使ってみるとわかりますが、機能の差というのが非常に曖昧になっています。例えばCoworkはエクセルやその他のアプリケーションファイルを修正したり編集したりできますが、実はClaude codeもある程度できたりします。Pythonのコードをその場で組み立てて実行しているので、サービス名はさほど意味をなしていません。しかし、特化された差分がいくつかあります。Claude Chatは対話や会話の中で様々な発見をすることができます。まるで人間と対話しているようにその中で解決策を見つけたり、温存したり、実行したり破棄したり、練り直したりすることができます。しかし反対に（ある程度会話もできますが）Claude codeは仕様と設計から結果を出すことを急ぎます。そういった性格があります。実はサービスの内容ではなく、性格といった方が理解しやすいものになります。つまり、Anthropic 自身が機能を製品に固定するのをやめて、共通の部品として切り出して全surfaceに配るやり方に寄せているわけです。エンジンも Agent SDK として一本化されています。最終的には極端な話、AIとして統一されたものになるでしょう。ChatからAPIに接続した結果を経て分析したものを出力するとか、Designから生成したものをそのままコーディングに回せるとか（すでに一部そのようなことができますが）そのように統一されたものになる方向で進んでいます。作業の流れに本来境界線はないとAnthropicは考えています。
Chat / Code / Cowork
現在の大きな入口は、この3つです。しかし前述したように境界線は曖昧で簡単な作業は、この３つのどれを使っても同じ結果出してくれます。Chatはファイルを生成しないので、コピペで作成可能な文字列を排出してくれます。CodeとCoworkはファイルを直接修正してくれるでしょう。現行の今時点での機能差は以下です。
| 製品 | 起動時のスコープ | 成果物 | 向いている仕事 |
|---|---|---|---|
| Chat | なし（毎回添付で手渡し） | 会話、Artifacts、単発のファイル | 考える、調べる、下書きする |
| Code | リポジトリ全体 + git | 動くコード、コミット | コードベースを育てる |
| Cowork | 接続したフォルダ + Drive等の外部サービス | 資料・データファイル、フォルダ内の更新 | コード以外の実務全般 |
Chat は対話中心ですが、添付すれば読むし、Pythonを動かして集計もします。ダウンロードファイルも作成できます。しかし、できないのは「ローカルPCのフォルダやファイルを継続的に見にいくこと」です。毎回手渡しが必要で、直接ファイルを扱うことをしません。PC内のファイルを基本的には直接扱わないので、CodeとCoworkと共同作業ができません。（ここが要注意です）CodeはUIは対話型ですが、ファイルからの読み込みで、複数の複雑なタスクを実行できます。どちらかというと、むしろ書き込みが本業であり常に成果物を出そうとします。ファイルを新規作成し、既存を書き換え、git にコミットし、テストを走らせる。読む機能は書くための下準備であり、実行タスクの理解のための読み込み機能です。Coworkは、バッチ的な処理で、多重タスクを実行してくれますが、これはCodeでも可能です。ここでは実際のプログラムコードを扱うのか、通常のアプリケーションファイルを扱うのか？という区別が明確になると思います。
いずれにしろ、この3つのどれかを使って、Claudeを使いこなすという話になります。
Skills、Projects、Artifacts、Memory、MCP／Connectors
このお話は、実際問題として何ひとつ覚える必要がないと言っても過言ではないのですが、毎回何かしら同じ指示を出さなければならないとか、すでに完全なルーチンワークが存在する場合は、これらの多いに活用してゆくのがよいということになります。（私は個人的には、使っていません。すべてClaudeが管理してくれている流れに任せています。）
覚え方としては、Skills = 動詞、Projects = 名詞、Memory = 主語、Artifacts = 目的語、MCP = 前置詞、くらいの感覚が近いです。ちょっと勘違いしてしまいがちなのは、CodeやChatでPC内のファイルを操作する際は、Claude AIがMCPを介してローカルのファイル群を操作しています。何となくMCPサーバーとかMCPコネクションなどといいますが、RemoteのMCP ServerとLocalのMCP Serverがあると思ってください。これはClient (Claude)に対する対義語ということになります。MCPの先はいつもwhereであるということになります。
| 機能 | 何を保存するか | 効く範囲 | 誰が書くか |
|---|---|---|---|
| Skills | やり方・手順 | 全surface | あなた（or 配布物） |
| Projects | 資料・知識 | そのプロジェクト内 | あなた |
| Artifacts | 成果物 | URL単位・共有可 | Claude |
| Memory | あなたの情報 | 全会話横断 | Claude（自動） |
| MCP / Connectors | 接続先 | 接続したセッション | あなた（設定） |
これらは実ファイルで存在します。
~/.claude/
├── skills/ ← Skills
├── plugins/ ← Plugins
├── projects/ ← プロジェクトごとの memory と会話ログ
├── sessions/
├── uploads/
└── settings.json (settings系の json)
とはいえ、これも一種の目安であり、このようにファイルをセットして仕様を明確にしないと動かないなどということはないのです。
.mdと.json
今のところ、Claudeが読み取る多くの設定ファイルや指示書は、MarkdownとJSONのみになっています。エクセルとかパワポも読んでくれるんですが、Claudeにとってはやや重いので、プレーンのテキストファイルが彼等にとって親切なフォーマットになりそうです。
できることを調べて整理するのは無駄
このようなClaudeができる様々な仕様を調べて、社内の業務効率化を狙うというのは、おそらく愚の骨頂でしょう。すでに行われている業務をAIに渡してゆくというだけで、殆ど100%が計画的な作業ではなく、実質的な実行作業になります。
かつて、クラウドサーバーと言われるAWSやGCPが出現したときもサーバー設計などレガシーなことに時間をかけていたエンジニアがいましたが、クラウドの特性上、LBにWEBサーバーを２台ぶら下げておけば、後は減らしたり増やしたりって話なので、WEBサーバーが◯台とか最初に考えることではないんですね。同様にして、我々の設計や計画、業務遂行の発想や内容がかなり変化してきたと言えます。
とにかく使ってみてなんぼの世界です。