トーク

AI AgentでPerlのコードを書くことはもちろんできるのですが、
プロジェクトの込み入ったコンテキストを把握してコード生成するのはまだ発展途上だと感じます。

「リポジトリを丸呑みして、コンテキストを把握してくれればいいのに…」

実際、リポジトリだけでコンテキストが完結することはないですし、丸呑みさせれば開発規模に比例してトークン量が増えて、破綻します。

そんな折、先日発表された Hono CLI のアプローチがいい感じだと思いました。
このCLIには、Honoに関する知識を検索し、必要そうな情報の詳細を確認して、できたアプリケーションをテストする機能があり、
これのおかげで必要なタイミングで必要な情報だけ取得するアプローチをAI Agentに組み込みやすくなっています。

「Perlでもほしい！」

ただ、いくつか課題があります。

課題1: 同じことをするにも複数やり方がある。

use Moose;  # え、うちMouseなんだけど...
use Path::Tiny;  # Path::Classじゃないの...？

本当は、プロジェクトで推奨している技術を空気読んで選んでほしいです。

課題2: 公式ドキュメントが過去の経緯も含め詳細な記述。

間違っていることではないですが、目の前の仕事を片付けるだけなら、もっと要点を絞ってもいいはず…!

課題3: レビューする人がPerlに詳しいとは限らない

飛躍した課題ではありますが、生成されたコードの正しさを人間が理解できた方がメンテナンスはしやすいと思います。

このLTでは、これらの課題へのアプローチを話したいと思います！

「あなたが本気で欲しいAI Agent」のLTです

Claude Codeをはじめとするコーディングエージェントは圧倒的な速さでPythonなどのコードを書きます。
ですが、生成されたPythonコードは「Pythonを理解している」とは言えません。
例えばf-string (f"Hello, {name}"のように文字列に式を埋め込める)はロギングのメッセージに使うべきではないのですが、平気で量産してきます。
私が決して書かないようなコードをコーディンエージェントが爆速生成し、私の名前でコミットされることにだいぶ耐えられませんでした。

そこで、コーディングエージェントにPythonを理解させようとClaude Codeのフックを使って教え込んでいます。
Claude CodeがPythonファイルを編集したときに、リンターを走らせ、「ロギングのメッセージにf-stringは使うべきでない」というエラーメッセージを見せて直すまで先に進まないようにブロックします。
LTではフックのデモをメインにし、さらなる工夫（サブエージェントの余地など）についてもお伝えします。
フック自体はPythonに限らず、自走するコーディングエージェントの一例になると考えています

概要

現代において我々は gpt-oss 等の優秀な事前学習済みモデルを自由に活用することができる恵まれた環境下にあります。
しかし、これらが会社の具体的なユースケースに完全にフィットしないケースも少なくありません。
私のバイト先のプログラミングスクールにおける生徒の離脱予測では、ユーザーの傾向の変化がしばしば相転移的な振る舞いをするために時系列のみを説明変数とする予測では相転移が起こる前に離脱の兆候を予測することができないという問題がありました。
そのため、時系列データに加えてテキスト情報を用いるマルチモーダルな推論が必要でしたが、これはデータの特性や制約によって既存のフレームワークでは対応できないという課題を抱えていました。
これに対し私は、既存の時系列基盤モデル (*1) のアーキテクチャを拡張する下記のライブラリを作成し、学習済みのモデルが拡張後のアーキテクチャに対応可能なように追加学習をする、という試みを行いました。
https://pypi.org/project/multimodal-timesfm/

話すこと

• そもそも時系列基盤モデルとは何なのか？実際のところ精度は出るのか？
• 事前学習済みモデルを自社サービスに特化させて活用するテクニックとしてはファインチューニングが一般的だが、なぜ「アーキテクチャ拡張」というアプローチを採るに至ったのか
• 基盤モデルを拡張する上での注意点、メリット・デメリット、今後の展望

補足

*1: 時系列基盤モデルとは、大規模言語モデルと同様の思想を時系列データに適用した機械学習モデルのことです。
言語モデルが大量のテキストデータで事前学習することで汎用的な言語理解能力を獲得するように、時系列基盤モデルは多様な時系列データで事前学習を行い、様々な予測タスクに適用できる汎用性を持ちます。

広告は「知らないサービスや体験への新しい出会いを作れる可能性」を秘めています。
私たちは「認知」のための広告ではなく「体験」をしてもらい、その体験から「よかった」と思える、そしてそれを実現できるプロダクト作りに日々励んでいます。
ですが広告主様×メディア様×生活者様と組み合わせが指数関数的に増え続け、人間ではカバーできない状況となっています。

AIを取り込んでいく中で「AIが体験を設計する」ことを見つけ、どう設計するか試行錯誤を重ねてきました。
驚くべきことに、既存の知識に縛られていない人たちがAIを柔軟に使いこなし、プロンプト設計を通じて組織全体が「AIの時代のエンジニアリング」を身につけました。

その過程で、組織は「ルール設計」に縛られており、体験設計の視野が狭くなっていることに気づきました。
「ガチガチに固めたルール」ではなく「コンテキストをおおまかに渡す」そうすることで、想定以上の体験設計を作り出すことに成功しました。
「正確性をどう上げるか」から「確度を持たせるために何を捨てるか」へチームの問い方が変わり、問題特定の速さも手に入れました。
「人の属人化は許容、AIの属人化はやめよう」本当の学習は、AIに任せるべきことを理解し判断を重ね、その反復を通じて得られるという組織における重要な価値観も形成されました。

AIへの投資を加速させ、会社のコア機能（プロダクト・DX基盤・AI基盤）をすべて繋げ、セールスも含めた全社でAIを組み込んだフローを使いこなしていく必要があります。
コアな部分がPerlだからこそ、エンジニアが「AIを使いこなし、レガシーと向き合う楽しさ」を感じ、同時に「AIも取り込んだ新しいアーキテクチャ思考」を磨いて価値を出していく——それがわたしたちの『Bet AI』であることをお話します。

私たちがAIにBetしたのは、「個人で使うAI」ではなく「チームで活用するAI」を実現するためです。
業務アプリ開発プラットフォーム「kintone」では、AIを使って“誰もがチームでより良く働ける環境”をつくることを目指しています。

AI開発の軸は「データ活用」と「市民開発」の2つ。
検索AIや分析AIでは、kintoneに蓄積されたデータから必要な情報を見つけ、チーム全体で知見を共有できるようにしています。
一方で、アプリ作成AIや設定レビューAIでは、専門知識がなくてもAIと相談しながら業務アプリを作れるようにし、市民開発を支援しています。

さらに、AIとの連携を支える技術基盤として「公式MCPサーバー」や「AIモデル JavaScript API」を整備し、開発者が自分たちのAIエージェントを柔軟に組み込める環境を提供しています。
これにより、社内外のサービスとAIを組み合わせた新しい活用が広がっています。

私たち自身の開発チームでも、設計レビューやドキュメント整理などでAIを日常的に活用し、開発のスピードと質を高めています。
このLTでは、プロダクトとチームの両面から、私たちがどのようにAIにBetしているのか、その背景と学びをお話しします。

カラオケ店舗の現場では、日々の「数字」と周辺商圏の状況や市況のトレンドといった「空気」を読みながらスペシャリストの経験と勘に基づいて売上を作っています。
しかし、全国400店舗分の売上データをすべて人の目で分析して追いかけるのは限界があります。店長は接客の時間を削ってレポートをまとめ、エリアマネージャーは複数店舗を管轄し、異常が起きていないかExcelと睨めっこしています。私たちはAI Agentによってその「人の手間」を減らしていきたいと考えています。

新たに構築したいと考えているAgentは、“現場が気づく前に店舗の異変に気づく”AI Agentです。
全店舗のPOSデータを監視し、売上の異常や傾向変化を自動で検知。異常が見つかると、周辺の天気・イベント・SNS投稿・競合店データを自動で収集し、「なぜその変化が起きているか」を分析してマネージャーに知らせます。
これを実現することで、マネージャーはお店の体験価値向上を“考えること”に集中し、店長は“お客様と向き合うこと”に集中できる。AIには「人間が人間にしかできないことに集中できる環境を作る存在」として店舗運営をサポートしてもらいます。

こうした仕組みを支えるために、私たちはデータ構造や分析フローを再設計し、店舗現場からのフィードバックを取り込みながら、AIが自然に働くシステム基盤の構築を目指しています。

AIが数字を追い、人が笑顔を作る。
テクノロジーが“現場を軽くする”とき、カラオケという価値は次のステージへ到達すると信じています。
その未来を、AI Agentと現場スタッフと一緒に作り上げていきたいと思っています。