勉強会の概要

2026年6月10日、Village AI の定例「AI活用勉強会」がオンラインで開催されました。取締役の戸嶋を中心に、社内メンバーが日々の実務で試したこと・つまずいたことを持ち寄り、リアルタイムでアドバイスを受ける場です。この日の参加者は9名でした。開始直後から「新しいモデルが出た」「もう試した」「消費量がやばい」と声が飛び交い、活気のある会となりました。

「探索と実装を分ける」という視点

今回の勉強会全体を通じて戸嶋が繰り返したのは、「ゴールが見えないまま実装に入ると失敗しやすい」という一点でした。「まずディープリサーチで調べて、要約させて、方針を固める。そのうえでプランモードに切り替えてClaude Codeで実装する。このループを回せるようになると、一人でも開発を前に進められるようになる」——この言葉が、この会を貫くテーマとなりました。ゴールが見えない状態で手を動かすのは、AIへの指示においても人間の作業においても同じ失敗につながります。そのシンプルな指摘が、この後の個別相談の事例を聞くたびに頭の中でこだました。

メンバーが持ち込んだ実務の悩みと突破口

後半は個別相談の時間です。それぞれが抱えるリアルな課題を持ち込み、戸嶋と参加者が一緒に考えていく形式です。今回は3名から事例が共有されました。

競馬予測AIの精度問題——「過学習」という落とし穴

過去のレース結果から1位馬の特徴を抽出し、予測に活かす取り組みを進めているメンバーがいました。「2025年のデータで条件を絞り込み、他の年でも同じ条件が出るか確認しています」という説明に、戸嶋が核心を突きました。「それ、いまあるデータで最強のパターンを探しているので、別の期間に当てると全然当たらない——いわゆる過学習が起きやすい状態です。データを訓練・検証・テストの3つに分けて、翌年に当てたときに再現するかを確認しないといけない。」さらに「馬は翌年には年をとる。年齢のトレンドを加味しないと、去年3歳だった馬が来年も同じ動きをするとは限らない」という一言に、「年齢は考えてなかった。確かに」と思わず声を上げる場面もありました。データの中身より期間の絞り方に意識が向きがちになる——そういう見落としの種が、会話の中からするりと浮かび上がった瞬間でした。「今日の議事録をそのままコピーして、プランモードで『上司からこのアドバイスをもらいました。改善計画を立ててください』と投げてみるのが一番手っ取り早い」という提案で、この話題は締めくくられました。

営業メール自動化のテスト設計——E2Eを忘れずに

営業メール自動化ツールを開発中のメンバーから、テスト設計の体系化が課題として共有されました。「テストの観点はある程度あるんですが、体系的に整理できていなくて」という悩みに、戸嶋からは3つのアドバイスが出ました。まず「正常系と異常系のチェック項目を全て書き出してから、AIにテストコードへ変換させる」。次に「Claude CodeとCodexにそれぞれ同じ仕様でテストを書かせて、お互いに『抜け漏れを遠慮なく指摘してください』と言わせると弱点が浮かび上がる」。そして強調されたのがエンドツーエンドテスト（E2E）の重要性でした。「単体テストだけだと、繋げたら動かないという問題が頻発します。『エンドツーエンドで一連の動作が繋がることを保証するテストも書いてください』と必ず一言足すこと。これを書かないとAIはサボりますよ」という言葉に、「確かに繋げてみたら動かなかった、ということがあった」と、思い当たる声が上がりました。

Notionの表フォーマット変換——自動化の先に事例化も

「Notionに表を貼りたいんですが、標準では表が作れなくて、今はスクリーンショットを手動で貼り付けている」という報告に、戸嶋がすぐさま方向性を示しました。「MarkdownからNotionに投稿できるHTMLへ自動変換するスクリプトを、生成AIに書かせればすぐできます。先週話していたWeb操作の自動化と同じ流れです。」さらに「このツール、オープンソースで公開したら会社の事例にもなるし、『生成AIでこんなに簡単にできる』という記事コンテンツにもなりますよ」という一言で、場の雰囲気が一気に前向きになりました。課題を持ち込んだはずが、いつの間にか「これ、事例として発信できる」という話になっている——この勉強会らしい着地でした。

議論が深まった瞬間：AI活用の次のステップへ

個別相談が一巡したあと、個別事例を超えた汎用的な議論が生まれました。AIツールの使い方にまつわる、実践者ならではのリアルな知見が次々と共有された時間です。

「AIが勝手に動きすぎる」を防ぐTips

AIが期待していない処理を自動で実行してしまうという声も上がりました。「検索をかけたら、AIが勝手にディープリサーチを使い始めて、気づいたらトークンがどんどん減っていった」という体験談に、参加者から笑い交じりの共感の声が続きました。戸嶋が示した対策はシンプルでした。「CLAUDE.mdなどの設定ファイルに、『ディープリサーチを使う前は必ず確認する』というルールを書いておくと、自動での実行を防げます。費用が発生する環境では特に書いておいた方がいい。」AIが自律的に動くからこそ、「動いていい範囲」を設計することが、AIと働くうえでの基本になります。そう気づかされた場面でした。

「モデルの調子が悪い」と感じたら

勉強会では、「最近使っているモデルの察し能力が落ちた気がする」という声も上がりました。これに対して戸嶋が語ったのは、新モデルのリリース前後に起きる現象についてでした。「新しいモデルが出る準備中は、計算リソースの調整で既存モデルの処理が抑えられることがあるらしい。見た目のモデルは同じなのに、粘ってくれなくなる。あくまで”らしい”という話ですが、運悪くそのタイミングにぶち当たっている可能性があります。」対処法はシンプルで、新しいモデルが出たタイミングで切り替えて試してみるのが一番早い、と戸嶋は言いました。「モデルの機嫌が悪い時期がある」——そう感じた経験は、この場の参加者だけのものではないはずです。

エージェント設計は「古き良きウォーターフォール」が効く

「開発担当と品質担当でエージェントを分けるといいという話を聞くが、実際どうか」という参加者の問いから、エージェント設計の議論が始まりました。戸嶋は「役割は分けた方がいいが、過剰に分割するのも逆効果になることがある」と前置きしつつ、現状の最適解を語りました。「AIの察し能力が低い段階では、要件定義→詳細設計→製造→単体テスト→結合テスト→リリース、という古典的なウォーターフォールをそのまま守らせるのが安定します。察した内容がこちらの意図とズレる問題を防ぐには、手順を明示的に定義するのが一番。」「古き良き」というフレーズにクスリとした空気が流れながらも、「確かにそれで安定することが多い」という共感の声もあわせて返ってきました。AIが発展した今こそ、人間が長年磨いてきた開発プロセスの知恵が生きます。この日の勉強会でもっとも腑に落ちた一言でした。