Claudeまわりの道具は増えました。API、CLI、MCP、Skillsを同じ棚に入れると、運用が崩れます。役割を分けると、設計はかなり単純になります。

この記事では、Claude開発でそれぞれをどう切り分けるかを整理します。

  • 何をAPIに寄せるべきか
  • 何をCLIに寄せるべきか
  • 何をMCPに寄せるべきか
  • 何をSkillsに寄せるべきか

https://docs.anthropic.com/en/docs/mcp

まず結論

Claude開発では、直接APIは「自前の制御面」、CLIは「人間が叩く操作面」、MCPは「外部ツール接続面」、Skillsは「作業手順の再利用面」と考えると整理しやすいです。これを混ぜると、同じ処理を複数の場所で持つことになり、保守が重くなります。

ClaudeDevsの投稿が示しているのは、まさにこの分業です。エージェントを強くしたいなら、何でも一つの仕組みに押し込まず、用途ごとに最短の経路を選ぶべきです。

APIは制御の本体

APIは、アプリやバックエンドからClaudeを呼ぶための本体です。入力、出力、認証、再試行、ログ、課金制御をまとめて管理できます。外部サービスとの連携を製品に組み込むなら、最終的にここが主戦場になります。

MCPの公式ドキュメントでも、MCPはアプリケーションがLLMに文脈を渡すための標準プロトコルとして位置づけられています。つまり、APIはClaudeそのものを動かすレイヤー、MCPはClaudeに与える接続の標準化レイヤーです。ここを分けると、責務が明確になります。

APIに置くべきなのは、次のような処理です。

  • 認証と権限の判定
  • リクエスト単位の制御
  • モデルやプロンプトの切り替え
  • レート制限とコスト管理
  • 監査ログの保存

逆に、作業手順の細かい説明や、特定チーム向けの運用ノウハウをAPIに埋め込むのは避けるべきです。そうした知識は、別の層に逃がしたほうが更新しやすくなります。

CLIは人間の操作面

CLIは、開発者が手元で素早く扱うための操作面です。Claude CodeのCLIは、対話実行、再開、パイプ入力、MCP設定などをコマンドで扱えます。これは、日常の試行錯誤に向いています。

CLIの強みは、見通しのよさです。実行した内容がそのままコマンドとして残るので、再現しやすく、チームで共有しやすいです。特に、

  • 一度だけ試したい
  • ローカルファイルを対象にしたい
  • シェルの流れに組み込みたい
  • 人が途中で判断したい

という場面では、APIよりCLIのほうが速いです。

一方で、CLIにすべてを寄せると、長期運用で破綻します。ユーザーごと、プロジェクトごとに設定が増え、権限管理も散らかります。CLIは作業用であり、プロダクトの中核ではありません。

MCPは外部ツール接続面

MCPの役割は明快です。Claudeを外部ツールやデータソースに安全に接続することです。Anthropicの文書では、MCPサーバーを通じてClaude Codeがツール、データベース、APIへアクセスできると説明されています。

この設計の良さは、接続先ごとに実装を壊さずに済むことです。たとえば、GitHub、Slack、Postgres、社内APIをそれぞれ個別実装でつなぐと、将来の保守が苦しくなります。MCPに寄せれば、接続の契約が揃います。

MCPが向いているのは、次のようなケースです。

  • 社内DBや業務APIをClaudeに見せたい
  • 監視基盤やチケット管理と連携したい
  • 複数ツールを同じエージェントに渡したい
  • ツール群を別クライアントでも再利用したい

重要なのは、MCPは業務ロジックの置き場ではないことです。MCPサーバーは接続と公開の標準化に向いていますが、複雑な業務判断は別レイヤーに置いたほうが安全です。

Skillsは作業手順の再利用面

Skillsは、特定作業のやり方をClaudeに教える仕組みです。AnthropicのSkills発表では、Skillsは指示、スクリプト、リソースをまとめたフォルダとして説明されています。必要なときだけ読み込まれるので、常時すべてを与えるより軽い設計です。

Skillsの価値は、手順を資産化できることです。たとえば、社内のレビュー手順、デザイン規約、リリース前チェック、文章の書式ルールをSkillとしてまとめると、毎回プロンプトを長く書かなくて済みます。

Skillsが向いているのは、次のようなものです。

  • チーム共通の作業手順
  • 文章やデザインの規約
  • 定型的なファイル生成
  • 特定業務の判断基準

Skillsはツール接続ではありません。手順と知識のパッケージです。だから、MCPよりも人の運用に近い層を担当します。

4つを混ぜない設計

実務でよくある失敗は、1つの仕組みに全部を載せようとすることです。APIに手順を書き、CLIに権限ロジックを入れ、MCPに業務ルールを埋め、Skillsに接続処理まで持たせると、すぐに読めなくなります。

分け方の基準は単純です。

  • 制御したいならAPI
  • 人が直接使うならCLI
  • 外部ツールにつなぐならMCP
  • 手順を再利用するならSkills

この割り当てにすると、変更時の影響範囲が狭くなります。たとえば社内DBの接続先が変わっても、MCP側の差し替えで済みます。レビュー手順が更新されても、Skillsだけ直せばよいです。モデルの呼び出し条件が変わるなら、APIの制御面を直します。

実装の考え方

小さく始めるなら、次の順で組むと失敗しにくいです。

  1. まずAPIでモデル呼び出しを安定させる
  2. 次にCLIで手元検証の導線を作る
  3. 必要になった接続だけMCPに切り出す
  4. 反復される作業だけSkillsにまとめる

この順番だと、最初から大きな抽象化を抱えずに済みます。特に、まだ業務フローが固まっていない段階でMCPやSkillsを大量導入すると、設定だけ増えて価値が見えにくくなります。

逆に、運用が固まっている組織ではSkillsが先に効くことがあります。手順が明確で、チーム間で差し戻しが多いなら、知識の共通化を先にやるほうが効果が出ます。

まとめ

Claude開発で重要なのは、道具を増やすことではなく、役割を固定することです。APIは制御、CLIは操作、MCPは接続、Skillsは手順。この4層に分けると、実装も運用も崩れにくくなります。

今後のClaude開発では、何をどこに置くかが競争力になります。便利そうだからといって全部を同じ層に入れず、責務の境界を先に決めるべきです。