2026-06-11
2026年5月27日、Village AIでは第三回「Claude Code 活用勉強会」をオンラインで開催しました。取締役の戸嶋を招き、社内メンバーが実際に取り組んでいる業務自動化の課題を持ち寄り、具体的なアドバイスをリアルタイムで受ける実践的な場となりました。
勉強会を通じて共通して語られたのが、AIの使い方に対する考え方の転換です。戸嶋はこう語りました。「エンジニアがプログラムを書くときにやっていた『インプット・アウトプット定義 → 処理分解 → 問題先回り』が、今や自然言語でできる時代。生成AIをうまく使いこなすことは、エンジニアを外注でうまく使いこなすスキルとイコール。」このフレームが、今回の勉強会全体を貫くテーマとなりました。
今回の勉強会では、Facebook広告に関する2つの異なるアプローチが共有されました。どちらも「Claudeに広告業務を任せる」という目標は同じでしたが、課題と解決策はそれぞれ異なるものでした。
ひとつは、Claude Desktopを使ってFacebook広告の管理画面(Ads Manager)をClaudeに直接操作させる試みです。スクロールやクリック、プルダウン選択など、あらゆる操作で承認プロンプトが発生してしまい、自動化の妨げになるという課題がありました。「承認ボタンを押し続けるだけで作業時間が溶けていく」と担当者が苦笑いしながら語った言葉が、その苦労をよく表していました。
戸嶋からは2つのアプローチが提示されました。非エンジニアには「設定ファイルに承認不要な操作を記述する方法」、定型操作を安定させたい場合は「SeleniumなどのPythonスクリプトを用意し、ClaudeはそのスクリプトをCallするだけにする」というアーキテクチャです。後者の設計にすることで、トークン節約・処理安定化・承認プロンプト削減という複数の課題を同時に軽減できます。「ClaudeはスクリプトをCallするだけにする」という役割の切り分けが示された瞬間、「なるほど、そういう切り分け方か」と感嘆の声が相次ぎました。
もうひとつは、ClaudeにPythonスクリプトを書かせ、広告タイトル・本文・予算・ターゲット設定を自動で行う仕組みの構築です。こちらの課題は「スキルの設計が甘く、Claudeが期待通りのパラメータを設定してくれない」という精度の問題でした。何度試行錯誤してもClaudeの出力がズレてしまい、担当者は「設計の問題なのか、指示の問題なのかもわからない」という状態が続いていました。
解決のポイントは、スキルの冒頭に「この操作に必要な項目リスト」をすべて書き出し、必須入力とデフォルト値あり項目を明確に区別することです。そうすれば、情報が不足していればClaudeから確認が来る仕組みになります。また、スキルを作る前にプランモードで「何が必要か」を整理するステップも有効です。Claudeに「こういうスキルを作りたいので、必要な情報を整理して」と投げると、Claude自身が質問を返してくれます。その整理結果をそのままスキルのプロンプトに転用するのが現在のベストプラクティスです。「そのやり方、すぐ試してみます」という声が上がるなど、この解決策は参加者の共感を集めていました。
社内ブログ記事の作成フローにClaudeを活用している事例も共有されました。記事を書く → レビュー依頼 → 修正というサイクルを繰り返す中で、レビュー工程が担当者の負担になっていました。マークダウンで書いたルールをセッションごとにClaudeに渡して対応していましたが、スキルとして定着させられていないという課題がありました。
担当者にとって、セッションのたびにマークダウンのルールを渡し直す作業は地味に積み重なる手間で、「毎回同じことをしている感覚が抜けない」というもどかしさがありました。戸嶋が提案したのは、マークダウンで渡しているルールをスキルとして独立させ、「文法チェック」「記事内容チェック」「口調変換」の3つに機能を分割することです。分割することで各スキルを独立して改善でき、一部だけブラッシュアップすることが可能になります。それぞれのスキルをサブエージェントとして切り出すことで、メインのコンテキストを消費せず、チェック処理をサブで完結させることができます。これにより、メインの精度が落ちにくくなるというメリットもあります。「スキルを3分割するだけでここまで変わるんですね」という驚きの反応がチャットに流れ、会場がひとつにまとまった瞬間でした。
話題が品質担保に及んだとき、戸嶋が持ち出したのがテスト駆動開発(TDD)の考え方でした。「こう動いたら正解」という仕様をあらかじめすべて書き出し(=テストケースを先に定義)、pytestなどの自動テストツールで機械的に確認する方法です。Claudeが生成するコードが増えても、テストがあれば品質担保ができる──この考え方は、コードを書かないメンバーにとっても腑に落ちる話でした。入門書をClaudeと一緒に読み、理解確認テストもClaudeに作らせるという新しい活用法も紹介され、学び方そのものが変わってきていることを感じさせる場面でした。
後半の質疑応答では、日々の業務でClaudeを使う中で感じるリアルな悩みが共有されました。
この質問が出た瞬間、おそらく多くの参加者が「あ、自分もそれ」と感じたのではないでしょうか。チャットにも「わかります」「同じです」のコメントが一斉に流れました。「質問がふわっとしてしまい、うまくClaudeに伝わらない」という悩みに対して、戸嶋は、まず「今からとてもふわふわした質問をします」と前置きしてプランモードに投げることが有効と述べました。Claudeが質問を整理・明確化する手伝いをしてくれます。同じ状況が繰り返されるなら「問題を分解・明確化するためのスキルを作っておく」ことも有効です。また、15分解決しない場合は人に聞くという判断軸も重要で、AIより人間の専門家が早いケースも多いです。この割り切りを持てるかどうかが、AIを道具として使いこなす上での分岐点になります。
「あー、それうちもです」と言わんばかりに、この質問への反応は特に大きいものでした。資料作成は業務の中心にある作業だけに、画面越しでも参加者が前のめりになっているのが伝わってくるようでした。LPや資料作成でPowerPointの品質が崩れてしまうという課題に対し、戸嶋は「PowerPointを直接操作させるには現状限界がある」と指摘しました。現状のベストは「HTMLでスライドを生成させること」で、バージョン管理の観点で安定しており、HTMLに慣れた担当者にとっては編集もしやすいです。あらかじめカラーセットやテンプレートを定義しておき、Claudeにはデータを埋め込む役割だけを担わせることが重要です。今後「HTML→PowerPoint変換」ツールが整備されれば、さらに理想的なフローが構築できます。また、品質チェックテンプレートで一度確認 → 課題抽出 → エージェントでブラッシュアップという2段階フローも効果的で、複数エージェントが連携してチェックリスト方式で抜け漏れを防ぎます。単体ツールとして使うより、エージェント同士が役割を分担するフローを前提に設計する発想が、次のステップになりそうです。