こんにちは！マーケティングチームの加藤です。

Claude Code盛り上がってますね！私もサイト分析や広告運用で毎日のように活用しています。活用の中で1つ課題として感じているのは、個人での活用からチームでの活用にどうスケールさせるか、という点です。2026年6月16日に開催されたClaude Code Meetup Japan #6（Claude Code祭り！）で関連する発表がいろいろありそうだったので、参加してみました。

個人の生産性ツールとして使う段階から組織の開発フロー・PM業務・レガシーシステム保守・安全な実行環境まで広げていっている・広げるためにどうするか、という問題意識の発表は多く、登壇者それぞれが実運用の中から持ち寄った話なので、「自分の現場でも試せる」と感じる具体的な話が多かったです。印象に残ったセッションをまとめます。

目次

• Agent Skillsの設計哲学

• PM業務での活用

• 組織的な開発フローへの展開

• レガシーシステム保守への応用

• Sandboxによる安全な実行環境

• ソフトウェア開発のセルフサービス化

• スキルとMCPツールの責務分担：AIが迷わないインターフェース設計

• MCPとデータ連携について感じたこと

Agent Skillsの設計哲学

佐藤亮さん（@nobita2040）のセッション「Agent Skills 徹底解説！ ルール / Tool / Skill / MCP / Subagent — まず何で始めて、いつ何を足すか」は、「CLAUDE.mdとMCPとSkillsの違いは？」というClaude Codeを使い始めた人が最初につまずく問いを正面から整理した発表で、すっきりしました。

MCPとSkillsは別物、というのが特に重要な整理でした。MCPは他システムとつなぐインターフェース。SkillsはClaude Code内の作業手順を書いたマニュアル。この2つを混同すると設計が崩れます。MCPサーバーを軸にしたコミュニティ知見の集まりとしては、CData MCP ナイト！開催レポートも参照してほしい。kintoneやOracle NetSuiteを含む多様なデータソースへのMCP接続事例が紹介されています。

Agent Skillsの「段階的情報開示」という設計思想も面白かったです。最初にすべての指示を一括でロードするのではなく、必要になったタイミングで必要なスクリプトやリファレンスだけを読み込む。コンテキストを無駄遣いしないための工夫です。

発表者が特に強調していたのが、descriptionフィールドの設計でした。このフィールドはモデルが常に参照するため、スキルがいつ発火するかはここで決まる。「スキルを作ること自体より、いつ発動させるかの設計が難しい」という言葉は、自分でもまさにそうだと感じていたところだったので、共感しました。スキルの動作テストにはskill-creatorが使えるそうで、これは早速試してみたいと思っています。

ソフトウェア開発のセルフサービス化

Kenn Ejimaさんのセッション「AI駆動開発を爆速化する：Kanary / Gista.js開発者からみたClaude Fable 5の実力とは？」は、より大きな問いを投げかけるものでした。

「賢いモデルが来たら、難しいタスクをやらせよ」という言葉が印象的でした。Claude as PM、Codex as EMという役割分担の話も、近未来像として現実感がありました。Kanary（録音・文字起こし）やGista.js（技術選定 as a service）といったプロダクトの紹介もあり、ソフトウェア開発がセルフサービス化していく流れは確かに起きていると感じます。エンジニアが「コードを書く・読む」という行為から離れていくとしたら、社会的な役割をどこに見出すのかという問いは、答えの出ない問いとして参加者それぞれに残っていたように思います。

PM業務での活用

shimitomoさんのセッション「実装はしない。でも、誰よりもAIと喋っている。- Claude Codeで回すAI駆動PM -」は、「PMの仕事は会話が9割」という言葉から始まりました。Claude Codeの出力をそのままコードとして使う場面よりも、会話や議論の内容を構造化してアクションに変換する場面での活用が中心になっているという話でした。コードを書かないPMこそ、意外とClaude Codeが刺さるポジションかもしれません。

具体的には、SlackのスレッドやFigmaのコメント、GitHubのdiscussionといった分散した情報を集約して、/github-issue-writerのようなコマンドで実装可能な粒度のIssueに落とし込む使い方が紹介されていました。曖昧な会話から、エンジニアがそのまま着手できる仕様に変換するプロセスを自動化できるなら、PM業務のボトルネックはかなり解消できると感じました。

pmnoDreamという仕組みも印象的でした。1日の振り返りやSlackのチャット、ミーティングの録音をClaude Codeに集積させ、翌朝の判断材料として再構築するという使い方です。意思決定の文脈を翌日に引き継ぐ、という発想がよかったです。

組織的な開発フローへの展開

田口 悠希さん（ソフトバンク、satto開発責任者）の「大企業におけるClaude Codeでの開発はどこまで進んでいるのか？」と、吉本 圭さん（グリーエックス執行役員）の「Claude Codeで作る"ハーネス" — 個人技を組織に広げる実践録」、2つのセッションをまとめて紹介します。

satto workspaceの事例では、入社時点からClaude Codeを使う開発環境が整備されているという話がありました。「アサインされたらClaude Codeで開発し、ローカルで多層レビューを実行してからPRを出す」という流れが最初から標準化されている。個人が後付けで導入するのではなく、最初からチームのフローに組み込まれているのが大きな違いだと思います。スライドに出ていた数値が印象的で、全コミットの83%がClaude共著、チームで共有するスキル（手順書）は49本、領域特化の専門サブエージェントは22体という状態になっているそうです。

/diff-reviewerを使ったスコープ別の並列レビューも実用的でした。セキュリティ・パフォーマンス・設計などの観点を同時にレビューし、PR後にも/reviewで追加チェックを行う。コードレビューの品質を人的リソースに依存しすぎない設計で、属人化を防ぎながらアウトプットの品質を保つという課題に対する、ひとつの現実的な答えだと感じました。

レガシーシステム保守への応用

Tadashi Sugieさん（tdash）のセッション「AIはレガシーシステムを保守できるのか？」は、4GL製品（SQLWindows、PowerBuilder、Visual Basic 6.0）のようなレガシー環境でClaude Codeがどこまで機能するかを検証した話で、多くの参加者が関心を持っていたテーマだったと思います。VB6はいまでも国内の業務システムで現役です。

検証では、verifier（動作確認エージェント）と改修エージェントをループ状に組み合わせることで、一定の精度でレガシーコードの改修ができたという結果が報告されていました。完全な自動化は難しいが、「Claude Codeが改修案を出し、verifierが動作確認し、問題があれば再改修する」サイクルを回すことで、ゼロから書き直すよりも大幅に工数を削減できる可能性があります。

モデルが古い言語や独自フレームワークに対して知識が薄い状況でも、verifierというフィードバックループを設ければ補完できる、という設計の考え方は、他のレガシー対応にも応用できると感じました。

Sandboxによる安全な実行環境

tmkさん（@tmk2154）のセッション「Claude Code の Sandbox機能を Anthropic Sandbox Runtime (srt) で試そう！」は、「エージェントの非決定論的な挙動に疲れていないか」という問いかけから始まり、個人的には一番刺さりました。Claude Codeを実運用で使い続けていると、「予想外の動きをされると困る場面」を避けるために権限を絞りすぎて、結果として生産性が上がらないというジレンマに直面します。

Sandbox Runtimeは、コンテナを使わずにファイルシステムとネットワークレベルで実行環境を制御する仕組みです。たとえば「特定の.envファイルだけを参照可能にする」「特定ドメインへのHTTPアクセスだけを許可する」といった細かい設定ができます。「どこまでエージェントに任せるか」の境界を安全に広げるためのレイヤーとして、組織導入のうえで現実的な選択肢になると思いました。

スキルとMCPツールの責務分担：AIが迷わないインターフェース設計

ラストはCData 杉本さん！「スキルと MCP ツール、責務をどう分けるか？ AI が迷わないインターフェース設計の戦略」でした。

タイトルにある「責務の分担」というのは、こういうことです。スキル（CLAUDE.md/Skills）はAIに「解釈・判断・手順」を担わせる場所で、MCP ツールはコードとして決定論的な処理を実行させる場所。この2つを混ぜてしまうと、AIが迷うインターフェースになる。

「The model should interpret. Code should calculate.」というスライドが端的に表していましたが、「頼ってはいけないロジックはツールに固定する」という考え方です。たとえば払い戻し金額の計算のような確定的な処理はPythonのコード（MCPツール）に閉じ込め、LLMには解釈と構造化だけを任せる。これによってAIの非決定論的な挙動に左右されない、再現性の高い設計になります。

このセッションではAPI-led Connectivityの考え方も紹介されていました。コンシューマー（モバイル・Web・コールセンター）の種類が変わるたびにインターフェースを作り直すのではなく、Experience API・Process API・System APIの3層に分けて設計することで、接続先の変化に柔軟に対応できる。MCPが普及するなか、AIエージェントは新しい「コンシューマー」として Experience API レイヤーから接続してくる、という整理は非常に腑に落ちました。

スライドはSpeakerDeckで公開されています：スキルと MCP ツール、責務をどう分けるか？ AI が迷わないインターフェース設計の戦略

MCPとデータ連携について感じたこと

ここからは少し自分の仕事の話も交えます。今回のミートアップ全体を通じて、MCPが「Claude Codeを組織に展開するための接続点」になるという実感が強まりました。Agent SkillsもSandboxも、最終的にはエージェントがどのデータに、どこまでアクセスできるかにかかっています。

PMが使うSlack・Figma・GitHub、開発者が使うCI/CDやモニタリングツール、そしてSalesforceやSnowflake・Google Adsのような業務データを持つSaaSは、すべてMCPを通じてClaude Codeと接続できます。問題は、そのMCPサーバーをデータソースごとに個別に実装・維持するコストかなと思いました。

CDataでは、350以上のデータソースに対してMCPサーバーを標準化された形で提供するプロダクト（CData Connect AI）を開発しています。SalesforceやKintone、SAP、BigQueryへのアクセスを、MCP実装を一から書かずに試せます。「どのデータにエージェントがアクセスできるか」を設計することは、Sandboxによる実行制御と同じくらい組織導入の重要な課題になると思っているので、Claude Codeと自社データの組み合わせに興味がある方はぜひ試してみてください。