Claude Code Meetup #4に参加してきました！
1. はじめに
ソフトウェアエンジニアリングの世界は、地殻変動とも言うべき大きな転換期を迎えています。GitHub Copilotの初期バージョンに代表されるような、単なる「補助ツール」「自動補完ツール」としてのAIの時代は急速に過ぎ去り、Claude Codeのようなエージェントが主導する「自律的な開発者（autonomous developer）」の時代へと突入しつつあります。
この転換こそが、2026年4月10日にメルカリ本社で開催された Claude Code Meetup Japan 4 の中心的なテーマでした。本イベントは、日本の 「AI-Driven Development（AIDD）」 コミュニティによって運営されました。全10セッションが行われ、本記事ではそのうちのいくつかをご紹介します。
2. 仕様通り動くの先へ。Claude Codeで「使える」を検証する
CCS SDD ツールの作者であるGotaさんは、単なるコード生成の先にあるものについて、見事な解説を披露してくれました。彼の主張はシンプルです。現在のAI開発におけるボトルネックは、人間が介入する際の認知的負荷である、と。その解決策として提案されたのが 「Autonomous Harness（自律的ハーネス）」 です。
このアーキテクチャは、3つのサブエージェントから構成されます。
- Planner（プランナー）: 実装手順を戦略的に組み立てる
- Builder（ビルダー）: 実際のコーディングを実行する
- Evaluator / UX Reviewer（評価者）: 出力結果を検証する
特に技術的に印象的だったのは、Evaluatorの役割にAnthropicの 「Computer Use」 機能を活用している点です。実際にスクリーンショットを撮り、UIを操作することで、AIは出力が単に構文として正しいだけでなく、機能としても期待通りに動作するかを検証します。
「Opus 4.6（あるいは次世代のClaude）のような高性能モデルを使う場合、その真価はハーネスにこそ現れます。1〜3時間にわたる自律的な実行サイクルを可能にし、人間の役割を『コーダー』から『ループの設計者（architect of the loop）』へと変えてくれるのです。」
（注：「Opus 4.6」はトーク内で言及されていましたが、おそらく実験的または将来のモデルバージョンを指していると思われます。重要なのは「高度な推論を行うモデルを地に足の着いたものにするには堅牢なハーネスが必要だ」という原則のほうです。）
3. 人間は意図、AIは実装：要件を伝えるだけのAI駆動開発ワークフロー
Jun（CyberAgent）さんは、Human Y（Why：なぜ） と AIによる実装 を区別する6ステップのパイプラインを発表しました。彼が用いたのは、Googleマップのアナロジーです。人間が目的地（intent：意図）を設定し、AIは最適な経路（implementation：実装）を提案する、という構図です。
このワークフローでは、人間が PRD（Product Requirement Document） を管理し、AIは進捗を追跡するために専用の context.json を生成します。これにより、AIは機能の背後にある「なぜ」を理解した上で動作するため、技術的には正しくても論理的には無意味な実装に陥るリスクを防げます。
4. Claude Codeで研究を加速した学生の話
博士課程の学生であるHiro Yoshiokaさんは、Claude Codeを活用することで、自身が「Yes/Noの意思決定者」として機能できるようになったと語りました。以前は、研究のベースラインを実装し、デバッグするのに丸1か月かかっていたそうですが、現在ではClaude Codeが論文を解析し、コードベースの差分（delta points）を特定し、約30秒で実装を完了させてしまうとのことです。
Yoshiokaさんが強調したのは、ある興味深い 「カルチャーショック」 ―― Brute Force（力技）の哲学 です。人間の開発者は、エレガントでパラメトリックなコードを書こうとします。しかしAIは、動くものを見つけるために100通りのバリエーションを「ハードコード」することを厭いません。慎重で漸進的な変更を旨とする伝統的な開発に慣れている人にとって、ソースコードを大胆に書き換えていくこの姿勢は、まさにパラダイムシフトと言えるでしょう。
5. 10年分の技術的負債、完済へ ― Claude Code主導のAI駆動開発でスポーツブルを丸ごとリプレイスした話
Sportsbull のNero15さんは、衝撃的な事例を共有してくれました。10年もののスタック（PHP / Swift / Kotlin）を、モダンな環境（Go / Next.js / React Native）へ置き換えた、というものです。しかも 新しいコードの90%はClaude Codeによって書かれた とのこと。
この「レガシー移行」の鍵となったのは、Specification-Driven Development（SDD） でした。彼らは、厳密なディレクトリ構成のmarkdownファイルを活用しています。
design.md: アーキテクチャ上の意図requirements.md: 機能要件tasks.md: 個別の実行ステップ
AIをこの「仕様の檻（specification cage）」に収めることで、彼らは10年分の技術的負債を、従来のほんの一部の時間で近代化することに成功しました。
6. 全社員のClaude Code・Coworkの利用状況をOpenTelemetryとGrafanaで可視化した話
Kurashiru（dely, Inc.） のRakさんは、エンタープライズにおけるAIのROIモニタリングという課題に取り組みました。彼のチームは OpenTelemetryとGrafana を導入し、数百台のPCにわたってClaude CodeとCoworkの利用状況を追跡しています。
人為的なミスを排除し、テレメトリの一貫性を保つために、彼らは MDM（Mobile Device Management） を通じて 「Managed Settings（JSON）」 を配布しています。これらの設定はエンドユーザーが変更できないため、すべてのインタラクションが必ずログ化され、中央のダッシュボードで可視化されます。これにより、組織は全部署にわたってAIの定量的なインパクトを計測できるようになりました。
7. メルカリのClaude Codeセキュリティ設定の組織配布戦略
Mercari のAkamatsu（Hi120ki）さんは、自律エージェントにおける「悪夢のシナリオ」、つまり誤った rm -rf の実行や、curl コマンドによるデータ漏洩について語りました。スケールにおけるセキュリティは、単なる信頼だけでは成り立ちません。それを支えるインフラが必要なのです。
メルカリではMDMツールとして Jamf を採用し、厳格なセキュリティガードレールを配布しています。さらに、ポリシーは対象に応じて差別化されています。エンジニア以外の社員には最大限の制約（特定のターミナルコマンドの無効化など）を、開発者にはより柔軟な設定を、というように。エージェント型のワークフローを導入したい企業にとって、ローカルマシンの整合性を損なわずに済むこのような階層化された配布戦略は、まさに不可欠なものです。
8. 個人的な感想
どのセッションもAIエージェントに対するユニークな視点を提供してくれましたが、オープニングセッションで語られた Spec-Driven Development（SDD） は、根本的なパラダイムシフトに感じられました。cc-sddリポジトリが示すコアアイデアは、.mdやテキストファイルといった「仕様（Spec）」を、開発ループ全体を駆動する single source of truth（唯一の真実の源） として扱う、というものです。これは、「明確なコミュニケーションが今やコア技術スキルである」 ことを強調している点で、特に強力だと感じました。
東京近郊への引越しを決めた主な理由のひとつは、こうした会話が実際に行われている「現場」に身を置きたかったからです。オンラインで技術記事を読むだけの段階から脱却し、イベントに参加してコミュニティに加わりたかったのです。今回が東京で初めて参加したイベントとなり、東京での新しい章のスタートとして、素晴らしい一歩になりました。
9. おわりに
要約すれば、結局のところすべては「人」に行き着きます。すべてのトークを貫く共通のテーマは、Masaki.Kさんが見事に言い表してくれていました。「最高のログ基盤、プラグイン、ダッシュボードを作ったとしても、最終的にはやはり 人 の話なんです」と。普及には、組織内での「後押し」とメンタリングが必要です。AI-Driven Developmentとは、単にスピードを上げることではなく、プロセス そのものを変えることなのです。認知的シャットダウンを防ぐためのペルソナ活用にせよ、10年分のレガシーコードを仕様で一掃するにせよ、焦点は「How（どう作るか）」から「Why（なぜ作るか）」へと移ったのです。
最後に、こう問いかけたいと思います ―― 「コードの実装者」であることをやめ、「AIの意図のデザイナー」になる準備はできていますか？ ほぼ即時に実装が完了する世界において、唯一残されたあなたの差別化要因は、アイデアの質だと思います。
