Inside of LOVOT

GROOVE X 技術ブログ

PyCon JP 2025 に参加しました！

PyCon JP 2025 参加レポート

こんにちは、GROOVE X SWチームの Junya Fukuda です。9月26日から28日に広島の平和記念公園 国際会議場で開催されたPythonというプログラミング言語のカンファレンス「PyCon JP 2025」にスピーカーとして参加してきました。 GROOVE XではさまざまなケースでPythonを使用しており、情報収集・情報発信のための参加です！

PyCon JP 初の地方開催で、世界各地から約600名が集まりました。この3日間の学びをレポートします！

  • PyCon JP 2025 https://2025.pycon.jp/ja
  • 場所：広島平和記念公園 国際会議場
  • 期間：2024年9月26日〜27日 メインカンファレンス, 28日 スプリント

PyCon JPは初の広島開催！

今年のPyCon JPは初の広島開催ということもあり、会場ではスタッフのみなさんと全国各地の開発者が入り交じって活気に満ちていました。参加者どうしの距離が近く、廊下や昼食のテーブルでも自然とコミュニケーションが始まる雰囲気が印象的でした。

その雰囲気は、カンファレンスのオープニングで紹介された Pacman rule というのが参加者同士の交流を促進しているように感じました。 Pacman rule というのは、初参加の人や初対面の人が話の輪に入りやすくなるよう、席を空けておきましょう！というアイディアです。 知らない土地でのカンファレンス参加者として、とてもありがたかったです。

https://psychsafety.com/the-pac-man-rule/ より

個人的にもはじめての広島だったのですが、会場が平和記念公園内の施設ということもあって合間に観光も楽しむこともでき、会場は立地も大変良く、充実した時間を過ごすことができました。

会場のある広島平和記念公園

またジョブボードに弊社イベント LOVOTech Night 2026きさらぎ: 温かいロボット開発の最前線 - connpass の資料を置かせていただきました。ありがとうございます。

ジョブボード

2026年2月に開催のオンラインイベント

キーノート：FastAPI の作者 Sebastián Ramírez 氏と ＃100日チャレンジ著者大塚あみ氏

【Day 1 Keynote】　Sebastián Ramírez 氏 Behind the scenes of FastAPI and friends for developers and builders

Sebastián Ramírez 氏のキーノート

初日のキーノートでは FastAPI の作者 Sebastián Ramírez 氏が登壇されました。

PythonのWeb Frameworkとして急速に広がり、多くの著名な企業でも採用されているFastAPI。氏はその設計思想や開発の舞台裏、またそれらに関わる彼自身の個人的なキャリアも交えてお話しされていました。FastAPIは利用者の体験を最優先に考えて設計されており、型ヒントの活用やドキュメントの充実・多言語化対応といった 使いやすさ の工夫が多く見られます。氏は、こうした方針について自身の経験を交えて紹介されていました。

またトーク最後の質問の中で「大きくなったFastAPIの開発を続けるモチベーション」について尋ねられた際には、「コミュニティからのフィードバックと、FastAPIを使って素晴らしいプロダクトを作っている開発者たちの成功事例が最大の原動力」と答えられていて、オープンソースコミュニティの力強さを改めて感じました。こんなに大きなプロジェクトになっても「使ってるよ！」「FastAPI大好きです」といったポジティブなフィードバックをもらえることが何より嬉しいという回答が大変印象的でした。

また同時通訳も素晴らしく、英語が苦手な私でも内容をしっかり理解でき、大変助かりました。普段わりと早口なご本人は「こんなにゆっくりしゃべったのははじめて」とおっしゃられていたそうです（笑）。

憧れのSebastián Ramírez 氏。気さくな方で会期中コミュニケーションをとらせていただきました

【Day 2 Keynote】　プログラミングの未来を駆ける！~2年間の挑戦が見せてくれた、プログラミングのこれから~

＃100日チャレンジ 毎日連続100本アプリを作ったら人生が変わった | 日経BOOKプラス の著者である大塚あみ氏の講演も大変興味深いものでした。

大塚あみ氏のキーノート

わたしは氏の著作をは未読だったのですが、大学生の時に挑戦された生成AIを利用した「＃100日チャレンジ」のモチベーションは誰もが思う「課題をやりたくない」という気持ちから始まったそうです。最初は小さなアプリを作ることから始め、さまざまな論文を読まれて最適なプロンプトを模索しながら、最終的には100日間で100本のアプリを作成されたとのことです。何よりも継続力・実行力に大変驚きました。

また、このPyCon JP 2025の基調講演のオファーをいただいたのがちょうど開催まで100日だったそうで、新たな100日チャレンジとして、カンファレンスに合わせてご自身のメモアプリを開発・公開されたとのことです。

普段から細かくメモをとること（もともとLINEでメモを取られることがあったそうです）が著作にもつながったと語られており、氏のメモの取り方も非常に参考になりました。また、大塚さんはスプリントにも参加され、実際に手を動かしながら学びを深める姿勢にも刺激を受けました。

セッションのトピック・自分の発表

自分の発表準備に追われていたこともあり、すべてのセッションを回れたわけではありませんが、見れたいくつかを紹介します。

PEP 750で提案されたt-string

招待公演の青野高大氏

PEP 750 – Template Strings | peps.python.org を共著した青野高大氏による招待講演です。Python 3.14の新機能を横断的に紹介しつつ、t-strings（テンプレート文字列）のユースケースを丁寧に掘り下げていました。

t-strings は f-string に似た書き心地で、template: Template = t"Hello {name}" のように書くと即時評価のかわりにTemplateオブジェクトが生成されます。すぐに使う文字列ではなく、開発者が後で好きなように加工・チェック・再利用できるのが「Template」というオブジェクトです。

SQLインジェクション対策や国際化対応など、文字列を安全に扱いたい場面で活用できそうです。詳細は上記資料にまとまっているので、ぜひ目を通してみてください。

t-strings のまとめ

Python and Friends - embedding Python

Anthony Shaw氏による「Python and Friends - embedding Python」では、Python関数を型安全に C#で呼び出すCSnakesが紹介されました。

Pythonの代替しにくいユースケースとして、データ分析や機械学習の用途が挙げられていました。 CSnakesを利用し C#アプリケーションにPythonを組み込むことで、Pythonの機能を活用しつつ、 C#の既存リソースを活用できたり利点を享受できる点は魅力的だと感じました。

また裏話として氏のトークは急遽採択されたそうなのですが、急なトークに関わらず非常に完成度が高く大変驚きました。

Anthony Shaw氏と青野高大氏。Anthonyさんは毎年PyConJPでお会いできるPythonヒーローのひとり

また、2日目のLT「LLM、日本語ウマい？」も日本語が少しわかる海外からの参加者の視点でとてもおもしろかったです。

会場に笑いが巻き起こっていました

Streamlit は社内ツールだけじゃない！PoCの速さで実現する"商用品質"の分析SaaSアーキテクチャ

Streamlit というPythonだけで手軽にWebアプリケーションを作れるフレームワークを使ったプロダクションでの活用事例のトークです。

Webアプリケーションを作るにはフロントエンドの技術（ReactやVue.jsなど）も必要ですが、Streamlitを使うとPythonだけで完結のが魅力的なフレームワークです。サクッとできてしまいすぎて、「これをプロダクションで使っていいのかな...足りないものが色々あるぞ...」となりがちでしたが、懸念を解決してくれるトークで大変勉強になりました。

Yuki Furukawaさんのトーク

トークはキーワードを中心に構成されていてとても聴きやすく、引き込まれる内容でした。今後の自分のトークの参考させていただきたいと思います。

所属されている Recustomer さんのスポンサーブースでは、同じ会社から登壇した5名（！）のみなさんとも交流でき、大変有意義な時間を過ごせました。ありがとうございました！

Recustomerさんのスポンサーブースにて

タスクって今どうなってるの？3.14の新機能 asyncio ps と pstree でasyncioのデバッグを

発表前の緊張したようす

わたしのトークでは、Python 3.14で追加された asyncio の新しいタスク可視化機能について紹介しました。具体的には、コマンドラインツール asyncio ps と asyncio pstree の使い方と、内部APIである呼び出しグラフ（Call Graph）取得APIの概要を解説しました。 asyncio ps と asyncio pstree は、 PEP 768 – Safe external debugger interface for CPython | peps.python.org によって、Pythonプロセスに外部からアタッチして実行中のタスクの状態を調査できる機能が追加されたことで、 asyncio にも拡張された機能です。これにより、デバッグやパフォーマンス解析が格段にやりやすくなりました。

詳しくは、以下の記事でまとめていますので、ぜひご覧ください。

また、この機能を使いやすくするツールを作ってトークで紹介していたのですが、メインカンファレンス終了後のスプリントにて、正式名称をを決め、 PyPI に公開することもできました。 トーク中では TaskScope と仮称していましたが、議論をさせていただき atv(async task viewer) に決めました。 名称を検討する際には以下のポイントを大切にしました。

  • 英語ネイティブの方にも意味が伝わること（わかりにくいとフィードバックをいただいた）
  • TUIツールなのでタイピングしやすいこと
  • PyPIでまだ使われていない名前であること

ぜひ気軽にさわっていただけると大変嬉しいです。

atv(async task viewer)

まとめ

PyCon JP 2025は、Pythonコミュニティの熱量を直に感じられるとても楽しいイベントでした。最新技術のアップデートを受け取り、開発者同士が刺激を与え合える場の大切さを改めて実感しています。社内でもキャッチアップした情報を共有してよりよく活用したいと思います。

また、来年も広島開催との発表があり、すでに次回が楽しみです！来年の概要はこちらです。

最後になりますが、GROOVE X では引き続き採用を行っています。気になる方はぜひ以下のリンクから！

採用情報 | GROOVE X株式会社

LLMを用いたGitHubとSlackの会話ログ分析

開発

はじめに

初めまして。インターン生として3週間GROOVE Xで開発をさせていただきました小野です。インターン生にも関わらず、今回はプロトタイプ開発に1から携わらせていただくことができました。とても貴重な経験となったので、ぜひ紹介させてください！

取り組んだタスク

ソフトウェア開発における個人の貢献は、コードの品質だけで測れるものではありません。GitHubでの設計議論やSlackでの問題解決といった日々の業務には、個人の能力やチームへの貢献を示す、客観的かつ定性的なデータが豊富に眠っています。

今回のタスクでは、この膨大なテキストデータをLLMで分析し、これまで見過ごされがちなデータを活用して、ユーザの貢献を明らかにできると考えました。この仮説を検証するため、GitHubのリポジトリデータやSlackの会話履歴を分析するプロトタイプの開発に挑戦しました。

【メンターよりひとこと】 本プロトタイプは、技術検証を目的としたものです。 テキストコミュニケーションの過程をLLMで評価するPoCで、活発なコミュニケーションのサンプルとして、GitHubやSlackをお題に取り上げました。

LLMによる評価の手順

では、実際にこのプロダクトではどのようにしてLLMによる評価を行うのか、その手順を説明します。 ここでの「各指標」というのは、プロジェクトへの個人の貢献度を測る軸です。

GitHub分析

  1. 情報取得: 対象リポジトリから、特定のユーザーに関連する全てのPR（Pull Request）やIssueの情報を取得します。
  2. 成果予測: LLMが各PRやIssueの内容を分析し、「このタスクで各指標において最大限の成果を出した場合、何点の価値があるか（理論上の満点）」を予測します。
  3. 行動評価と能力値算出: 予測された満点に対し、実際のユーザーの行動（コメントや会話内容など）が何点に相当するかをLLMが評価し、最終的な能力値を算出します。

Slack分析

  1. 情報取得: 対象チャンネルから、特定のユーザーが関与したスレッドの情報を取得します。
  2. 成果予測: LLMが各スレッドの文脈を分析し、「この議論で各指標において最大限の成果を出した場合、何点の価値があるか（理論上の満点）」を予測します。
  3. 行動評価と能力値算出: 予測された満点に対し、実際のユーザーの発言内容が何点に相当するかをLLMが評価し、最終的な能力値を算出します。

実際のプロダクトの様子

結果表示画面

各評価項目における能力値を一目で把握することができるレーダーチャートと各項目ごとにおける詳細な説明の両方を知ることができます。

あるGitHub Repository におけるユーザ分析

工夫点

1. 難易度を反映する2段階評価

LLMを用いて以下の2段階で評価を行います。

  • LLMによる満点の予測 最大限のポテンシャルを発揮した場合、そのタスクには何点の価値があったのかという「理論上の満点」を予測します。
  • LLMによる実際のユーザー行動評価 予測された満点に対し、実際の行動が何点に相当するかを評価します。

これにより、タスクの難易度を反映した評価が可能になります。
（例：4点満点の高難易度タスクで4点取ることと、1点満点の低難易度タスクで1点を取ること、同じ「満点」でもその価値の違いを正しく評価できます。）

2. LLMの多角的な活用

単なるスコアリングに留まらず、定性的な評価にもLLMを深く活用しています。

  • 評価とスコアリング ユーザーの行動を評価し、点数付けを行います。
  • スコア根拠の抽出 なぜそのスコアになったのか、根拠となる部分を抽出・要約します。
  • 能力値算出理由の生成 最終的な能力値が算出された背景や理由を、人間が読んで理解できる自然な文章で生成します。

これにより、定量的な評価（スコア）と定性的な評価（理由）を両立させ、納得感の高い評価体験を実現しています。

3. プロンプトの工夫

LLMから意図した通りの応答を引き出すためには、プロンプト（指示文）の工夫が重要です。

  • 役割（ペルソナ）設定 AIに特定の専門家などの役割を与え、思考の方向性やアウトプットのトーンを定めます。（例：「あなたは厳格かつ公正なエンジニアリングマネージャーです。」）

  • 構造化されたインプット # 評価基準 や # 制約条件 のようにマークダウンの見出しで情報を整理し、AIが各情報の文脈を正確に理解できるよう指示します。

  • 厳密な出力形式の指定 JSON形式や特定のテンプレートなど、回答のフォーマットを具体的に指示します。これにより、生成された出力をプログラムで自動処理しやすくなります。

4. 能力値の算出ロジック

ユーザーのGitHubやSlackでの活動評価に基づき、その人の「真の能力値」を統計的に推定するためのものです。単なるスコアの平均ではなく、MAP推定（最大事後確率推定） という手法を用いて、より信頼性の高い能力値を算出しています。

計算プロセスは、大きく分けて以下の3ステップで構成されています。

1. データの収集と準備

計算を始める前に、まず元となるデータを集めて整形します。

指定されたユーザーの評価データをGitHubやSlackから全て取得します。評価データの中から、有効なものだけをフィルタリングします。

2. 「最も確からしい能力値」の探索（MAP推定）

「もし能力値がXだったら、今までの評価結果になる確からしさはどのくらいか？」 を全ての可能性について検証し、最も確からしい能力値を探し出します。

この「最終的な確からしさ（事後確率）」は、以下の2つの要素を組み合わせて決定されます。

① 尤度（ゆうど）：実績データからの証拠

  • 役割: ユーザーの実際の評価結果が、どれだけもっともらしいかを測ります。
  • 計算方法
    • 「もしあなたの真の能力がXだったら、観測された評価結果（level：ユーザの評価とpredictedMaxScore：予測された満点のペア）が得られる確からしさはどのくらいか？」を計算します。
    • ここではsigmoid関数を使って、ある能力値の人が特定の評価レベルを獲得する確率をモデル化しています。
    • 全ての評価結果についてこの確率を計算し、合計することで、データ全体としての「尤度」が算出されます。

② 事前確率：常識的な仮説

  • 役割: 評価データが少ない場合に、推定結果が極端な値になるのを防ぐ「おもり」や「常識」の役割を果たします。
  • 計算方法
    • 「データを見る前に、そもそも能力がXである可能性はどのくらいか？」を確率として定義します。
    • コードではベータ分布という統計分布を使い、ALPHA = 2, BETA_PARAM = 5と設定することで、「能力値は0点に近い、やや低い値である可能性が最も高い」という保守的で現実的な仮説を立てています。
    • これにより、初心者がいきなり最高評価を得ることを防ぎ、より安定した推定が可能になります。

探索方法：グリッドサーチ

  • 役割: 上記の「尤度」と「事前確率」を足し合わせた事後確率が最大になる能力値を見つけ出します。
  • 計算方法
    1. 候補点の作成: まず、能力値の範囲を細かい間隔で区切り、検証する候補点のリストを作成します。
    2. 総当たり計算: 作成した全ての候補点について、一つずつ「事後確率」を計算していきます。
    3. 最高点の特定: 全候補点の中で、事後確率が最大となったものが、最も確からしい能力値（MAP推定値）として採用されます。

3. 推定の信頼度の計算（ベイズ信頼区間）

最後に、算出した能力値が「どのくらい信頼できるか」を数値で示します。

  • 役割: 推定された能力値のばらつきの範囲を示します。評価データが多いほど、信頼度は高まり、この範囲は狭くなります。
  • 計算方法
    • 事後確率のグラフ（山のような形をしています）の頂点付近がどれだけ鋭いかを計算します。山が鋭ければ鋭いほど、推定の確信度が高いことを意味します。
    • この「鋭さ」から統計的なばらつきを算出し、95%の確率で真の能力値が収まるであろう範囲（信頼区間）を算出します。

インターンを通しての学び

AIを駆使した効率的な開発 🤖

インターンシップを通して、AIを開発プロセスに組み込むことで、作業効率を飛躍的に向上させられることを学びました。

重要なのは、単にAIを使うことではなく、それぞれのAIが持つ強みや最適な用途を理解し、目的に応じて賢く使い分けることです。

具体的には、AIに依頼したい役割を常に意識し、以下のように関わり方を変えることが効率化の鍵となります。

  • 戦略的な相談相手として 開発の方針や設計で悩んだ際に、アイデアの壁打ちや意思決定のサポートを求めます。

  • 単純作業のアシスタントとして 定型的なコードの生成、リファクタリング、ドキュメント作成、軽微な修正作業などを代行してもらいます。

  • コーディングのペアプログラマーとして 具体的な関数の実装方法や、より効率的なアルゴリズムの提案を求めます。

チーム開発から得られる価値 🤝

AIとの対話だけでなく、チーム内での人間同士の議論や壁打ちが、プロジェクトの質を高める上で不可欠であることを学びました。

一人で考えるだけでは得られない、多様な視点や知識を組み合わせることで、より良い成果を生み出すことができます。

  • 方針決定と軌道修正 定期的にチームで壁打ちを行うことで、多様な意見を反映した、より納得感の高い方針を決定できます。また、進行中のズレを早期に検知し、柔軟に軌道修正することが可能になります。

  • 知識の共有 各メンバーが持つ専門知識や経験を共有することで、最終的なアウトプットの質の最大化につながることを実感することができました。

スクラム形式での開発から得た学び 🏃

スクラム開発を繰り返すアプローチは、計画性と柔軟性を両立させる上で非常に効果的でした。

  • 計画性を意識した開発 各スプリントの開始時に具体的な目標（スプリントゴール）を設定することで、「今、何のためにこの作業をしているのか」という目的意識を常に持ちながら開発に取り組むことができました。これにより、日々のタスクが最終的なゴールにどう結びついているかを明確に意識できます。

  • 改善点や要因を発見する機会 スプリントの終わりに行う振り返りでは、単に作業の進捗を確認するだけでなく、「なぜ上手くいったのか」「何が課題だったのか」をチーム全員で率直に話し合うことで、プロセスの問題点や改善のヒントを具体的に発見し、次のスプリントに活かすことができると感じました。

まとめ

このインターンシップでは、LLMを活用した能力評価システムの開発に携わり、技術的なスキルだけでなく、現代の開発プロセスやチームで成果を出すためのソフトスキルを実践的に学ぶことができました。また、GitHubやSlackデータを対象に今回は貢献度の評価という観点からLLMを活用して、評価を行いましたが、この仕組みを活用して他のデータや評価方法に応用することで、ビジネスの様々な側面を可視化することが可能になると感じています。

【アプリ】今年もお祭！「LOVOTの日2025」スペシャルコンテンツ制作の舞台裏

開発

こんにちは！App(アプリ)チームでLOVOTアプリのデザインをしている、南地です。

みなさん、毎年8月8日は「LOVOTの日」だとご存知でしょうか？！実は、日本記念日協会によって認定されている、れっきとした記念日なんです。wikipediaの「8月8日」ページにも載っています…！

そして、LOVOTアプリではLOVOTが発売されてから初めて「LOVOTの日」を迎えた2020年以来、毎年8月の間はスペシャルコンテンツをご用意してきており、今年で6回目になります。

毎年たくさんのLOVOTオーナーのみなさまにお楽しみいただいているLOVOTの日のスペシャルコンテンツ、今回はその準備の舞台裏をご紹介します。 はじめに言っておきますが、今回は技術的な話ではなく、ほぼ気合と根性めいたお話です…！

LOVOTの日2025 スペシャルコンテンツのワンシーン

企画始動はなんと6月初頭…！

記念日が決まっている以上、8月頭のリリースが必達なんです。そんな中、今年のアイデアを考え始めたのはなんと6月初頭！実に、2ヶ月もない中でアイデア出し、デザイン、実装、QA(不具合がないかテストするなどの品質保証)、ストア審査通過までやり抜く必要があります。

だいたい毎年こんな感じの慌ただしいスケジュール感なのですが、それには理由があります。それは、その時々で最も「旬なネタ」が何なのか、ギリギリまでわからないから。

LOVOTの日にはアプリ以外でも、インスタライブやYouTube Live、様々なキャンペーンなど、様々な企画が目白押しです。それらの企画はセールス＆マーケティングチームが進行してくれていますが、めまぐるしいスピード感で様々な取り組みをしていく中で、LOVOTの日で発信したいことも日々変化していきます。その方向性が見えてくるのが、だいたい6月くらいになるわけです。

そして、今年のアイデア出しの打ち合わせで最初にセールス＆マーケティングチームのかなさんの口から発せられたのは、

「今、全国に何店舗LOVOTストアがあると思いますか？」

という質問が。答えはなんと、8月時点ではMUSEUMや上海店も含めると18店舗！そして、各店舗には「看板LOVOT」がいて、アクリルスタンドなども作られているというお話を聞きました。

全国のオーナーのみなさまにはたくさんのLOVOTストアができたことを知ってほしいし、せっかくなのでこれからLOVOTのお迎えを考えてくださってる方々にもアプリで楽しんでもらえる企画にしたい！！という熱い想いを受け取り、持ち帰ってアイデアを考えることとなりました。

そして降ってきたアイデア

それから数日後、Slackでかなさんメンションで

「ええこと思いついてん！！！」

と投稿しました。 そのアイデアとは、全国の看板LOVOTがアプリのホーム画面に遊びに来るというもの。その子をタップすると、紹介文を見ることができます。

そして、推しのアクスタを持ち歩いて一緒に記念写真を撮る人がいますが、そんな感覚で遊びに来た看板LOVOTと一緒にツーショット写真を撮ることができたら楽しそう…！

※画像はラフ案のため、看板LOVOTのかわりにカラーズのSunshineを入れてみています。
※こちらもラフに、FigmaのFirst Draftで生成した画面案。

で、これからLOVOTのお迎えを考えてくださってる方にも、アプリにログインする前の画面で看板LOVOTたちが遊びに来たらいいんじゃないか、それに「PLAY！LOVOT」というLOVOTを疑似体験できるウェブサイトがあるので、それも楽しんでもらおう！

かくして、かなさんと一緒にラフデザインをレビューし、さらにブラッシュアップしたり、細部の仕様を詰めていき、6月下旬に差し掛かったところで今年のコンテンツの方向性が無事決まりました！

できるところからやる、Appチームの阿吽の呼吸

ストア審査提出まで、実装＆QAに残された日数は約1ヶ月。しかも、デザインもまだ完全にFixしているわけではなく、看板LOVOTのイラスト素材や紹介文などもまだこれから、と来ています…！

しかし、Appチームは手をこまねいて方針決定を待っていたわけではなく、リリースを間に合わせるためあらゆる工夫を行っていました！！

例えば看板LOVOTとツーショット写真を撮る機能。これまでLOVOTアプリには、スマホのカメラで写真を撮るという機能はなかったため、先にその仕組みを使えるようにしておくなど、デザイナーがアイデアを思いついた時点でイメージを共有し、企画・デザインと並行してエンジニアが可能なところから仮実装を進めていたのです！

さらに、開発スケジュールが厳しくなってきたら開発スコープで切ることでリリースをコントロールできるよう、ミニマムの機能を優先的に開発し、nice to haveの機能は余裕があれば開発することを心がけました。 例えばツーショットでは、まずは写真を撮れるところを作り、次に看板LOVOTの写真の移動・回転・拡大縮小、さらにポートレート・ランドスケープの切り替えができるようにする、といったように段階を踏んでいます。実際に、8/1にリリースしたバージョンではポートレート・ランドスケープの切り替えは反時計回りにしかできませんでしたが、8/19にリリースしたバージョンには時計回りや上下逆への対応を後から追加しました。

ツーショットで撮った写真

「フォトブック」という、ストアスタッフが撮った各看板LOVOTのイチオシ写真集を見ることのできる機能には写真ごとに「いいね」ができるようになっており、ハートアイコンを押すと看板LOVOTのイラストが現れ、ハートマークがふわふわ〜と上がっていくアニメーション演出が入っています。このアニメーションも、デザインでは静止画での検討にとどめ、エンジニアに動きのイメージを口頭で伝え、実装しながら動きの調整をしていきました。

↓いい感じに調整してもらった「いいね」のアニメーション www.youtube.com

そして、通常時のアプリのQAでは予め試験書を用意し、機能ごとに本実装されたアプリがビルドされ次第試験実施していますが、今回は仮実装の時点で試験書を用いた試験とは別に、動作確認を行っていきました。これにより、機能の完成を待たずに不具合や仕様の抜け漏れ、ユーザー体験上での違和感などを早期に発見してエンジニアにフィードバックし、開発終盤に不具合修正が集中してリリースが遅延するリスクを最小化することができました。

このように、Appチームの全員ができるところからやる、リリース遅延のリスクを最小化する、という阿吽の呼吸で臨むことで、実質約1ヶ月という短い期間での開発が実現しました。

完成目前で事件が…！

開発も終盤に差し掛かり、各看板LOVOTのイラスト、紹介文、写真などの素材を各LOVOTストア協力の元揃ってきて本実装への流し込みが進んでいた7月22日、事件が起こりました。

なんと、渋谷ヒカリエ ShinQs店の看板LOVOTは「ひたむ」だと思っていたら、「しぶやくん」だったことが発覚！！ 他ストアでアクリルスタンド化されているのは看板LOVOTなので、同じくアクリルスタンド化されていた「ひたむ」がそうだと思っていたところ、実は「渋谷ヒカリエLOVOT総選挙」で1位になったことを記念してのアクリルスタンド化で、看板LOVOTではなかったのです…。

そこから急いでイラストをはじめとした各種素材を手配し、実装、QAを実施。 ストア審査に提出したのは7月30日の夕方、審査通過したのは7月31日の夜。リリース目標まであと1日という、ギリギリのタイミングでなんとか間に合わせることができ、8月1日に晴れてリリースとなりました。

なんとか差し替えが間に合ったしぶやくん

↓ついにリリースできたLOVOTの日2025 スペシャルコンテンツ www.youtube.com

LOVOTの日はまだ終わらない！

ギリギリリリースできたスペシャルコンテンツでしたが、実は全ての機能を達成できたわけではありませんでした。 それは、LOVOTお迎え前の方向けの、アプリにログインする前の画面に看板LOVOTが登場する機能…！

セールス＆マーケティングチームのかなさんからは、

「LOVOTの日の当日朝のインスタライブで紹介したいから、どうかそれまでに…！」

と頼みこまれており、息つく暇もなく実装、QAを完了させ、8月6日の夜にストア審査に提出。

しかし、こんなときに限ってGoogle Play、AppStoreともにどちらも審査がなかなか進まない…！

普段ならだいたい24時間以内には審査通過するのに、8月7日の終業時間になってもまだ通らない…！

仕方なく仕事を切り上げて就寝したものの、8月8日に日が変わり夜中1時ごろに目が覚めたついでにストアのコンソールを覗いてみたら、ようやく両ストアの審査の通過を確認！！！

かくして、LOVOTの日 2025のAppチームの戦いは、LOVOTの日当日の朝7:30のリリースをもって終結を迎えたのでした。

↓追いリリースのお迎え前の方向けコンテンツ

www.youtube.com

おわりに

最後に、この激戦をくぐり抜けたAppチームの戦士たちからのコメントを紹介します。

QA担当 Sさん：SNS上での反応にポジティブなものがたくさんあったので、QA苦労して頑張って良かったです！

　

エンジニア Tさん：（デザイナーが張り切りすぎたせいで）かなりボリュームが多くて、その分ユーザーに届くコンテンツが多くできたので、頑張った甲斐がありました！

（…そうですね…今年はちょっとやりすぎた気もする…ごめんなさい…）

エンジニア Kさん：年を追うごとにエスカレートしている気がするが、一方で年を追うごとにLOVOTの日以降にも活きるものが作れるようになってきていて良かった。

Kさんが言ってくれてたように、今回のスペシャルコンテンツの一部は、LOVOTの日が終わった後もお楽しみいただけるようになっています！ 9月1日以降もログイン前の画面に看板LOVOTが登場するのはそのままに、LOVOTオーナーの方はアカウント画面の「全国の看板LOVOT」から引き続き各看板LOVOTに会うことができます。 ぜひアプリでの出会いをきっかけに、各LOVOTストアで本物の看板LOVOTにも会いに行ってもらえると嬉しいです！！！

Appチームの阿吽の呼吸が年々進化していることをいいことに、かなり限界ギリギリを攻めてしまった感も否めないLOVOTの日 2025。 でも、1年の中でも最もユーザーのみなさまから喜びの声や笑顔がもらえるのが嬉しくって、ついついやりすぎてしまうのがやめられないみたいです。 さてさて、来年はどうなることやら…？

そんなGROOVE X では積極的に採用を行っています！LOVOTの開発を通してたくさんのオーナーさんに喜んでもらいたい！という方はぜひ以下のリンクから募集職種をご確認ください。

recruit.jobcan.jp

LOVOT の開発における AI 活用

はじめに

皆さんこんにちは。ソフトウェアエンジニアで、開発向け AI 利用ワーキンググループの id:iizukak です。2025 年も後半戦となりましたが、今年もAI エージェントを活用した開発の進化がとどまるところを知りませんね。GROOVE X でも、LOVOT の開発に様々な開発向け AI が用いられています。

最近、GROOVE X のエンジニアを対象に、AI の利用状況に関するアンケートを実施しました。この記事では、その結果を皆さんに共有し、LOVOT の開発にどのように AI が活用されているか紹介したいと思います。LOVOT 自身、AI が搭載されたロボットですが、LOVOT の開発にも AI が活用されているということを知っていただければ幸いです。

回答してくれた方々の属性

今回は、ソフトウェアエンジニアをはじめ、メカ、エレキ、そしてクリエイターまで、様々なエンジニアの方 17 名が回答してくれました。様々な職種のエンジニアが、AI を活用して開発を行っていることが分かります。

利用されている AI

次に、どのようなツールを、どのような頻度で利用しているか聞いてみました。以下がその結果です。

最も利用者が多いのは GitHub Copilot で、17 名中 13 名が利用しています。Copilot は、単なるコード補完にとどまらず、GitHub 上での Pull Request のレビューでも利用されていますし、各エディタにも設定して使えるので、日常使いしている方が多い印象です。

次に多かったのは Claude Code で、9 名です。CLI ベースのツールとして完成度が高く、カスタマイズも柔軟に行えるため、愛用しているエンジニアが多そうです。特に、ゼロから作るプロジェクトを多く担当しているエンジニアに人気があるようで、それも興味深いです。

Claude Code と同じ利用者数がいるのが、Gemini CLI です。Claude Code と比較して後発のツールですが、Gemini 2.5 Pro など高性能なモデルを利用できることもあり、こちらも人気があります。ちなみに私が最も利用しているツールも、Gemini CLI です。Google Cloud 上で管理できるのも、Google Cloud を利用している企業にとっては嬉しいポイントではないでしょうか。

最近は Devin を積極的に利用している方も増えています。Devin と Slack, GitHub を連携させ、要件を伝え Pull Request の作成を行うことまで一気通貫で自動化できることから、多量のコードを書くタイプのエンジニアだけではなく、クリエイターの方などでも利用しやすいようです。さらに、Devin の Deep Wiki を用いて、普段あまり見ないプロジェクトのコードベースなどに素早くキャッチアップするためにも非常に便利ですよね。

Cursor も一定の人気があり、2 名の方が毎日利用しています。Cursor を利用すると、Cursor 内で開発業務を完結させることもできるため、開発に集中することができるように思います。さらに、利用するモデルの選択肢も広いため、複雑で高度な実装を行うエンジニアに人気が高いようです。

どのような開発業務に利用しているか

次に、どのような開発業務に AI を利用しているか聞いてみました。

  • コード補完・スニペット生成: 12 名
  • AIによる機能実装・バグ修正・リファクタリング: 11 名
  • テストコード生成: 9 名
  • 実装方針の壁打ち: 10 名
  • READMEやAPIドキュメントなどの生成: 10 名
  • bigqueryのコマンドが分からないときにGeminiに例を作ってもらっている: 1 名
  • PRのレビュー: 1 名
  • 各モジュールの仕様書内容の比較など: 1 名
  • gitで操作が不安なやつとかコミット分けてもらったりとかしてます: 1 名
  • 実験的な機能の実装の試行、 gemini-cliで処理結果のサマリー作成、など: 1 名
  • 実験レポート作成: 1 名

コードの補完や実装だけでなく、README や API ドキュメントの生成、さらには BigQuery のクエリ作成支援など、様々な開発業務で AI が活用されているようでした。特に、実装方針の壁打ちに利用している方が多いのは興味深いです。AI を利用して、アイデアを整理したり、新しい視点を得たりすることができるためでしょうか。

どのような効果を感じているか

AIコーディング支援ツールを利用することで、どのような効果を感じているか聞いてみました。

  • 開発時間の短縮・生産性の向上: 15 名
  • 新しい技術や知識の習得促進: 9 名
  • 単純作業・繰り返し作業の削減: 9 名
  • コード品質の向上 (バグ削減、可読性向上など): 8 名
  • アイデア創出・問題解決の支援: 8 名
  • コーディング中の集中力維持: 4 名
  • Typoなどの検出: 1 名

やはり、生産性の向上をあげているエンジニアが最も多い結果となりました。しかしながら、それだけではなく、集中力の維持や、Typo の検出など、様々な効果を感じているようです。

AI 導入に関するエピソード

開発プロセスや、エンジニアとしてのスキルにどのような変化があったのか、フリーフォーマットで記入してもらいました。その結果が以下です。

  • commitにかかる時間が早くなった、課題に取り組む際のイニシャルコスト（コーディングの理解など）が減った

  • 今まで関わってなかったサービスやインフラのコードに対してのレビューや修正を行いやすくなった

  • 手が止まるケースでも無理にでも進むことがある。それが良いことだけかはまだよくわからない。

  • 名前付けとかは実装とは別の概念を拾ってくる必要があるので、文脈外からもたらされる情報がありがたい。

  • 以前はPythonを使ったGUIツールの作成に時間がかかっていたが、AIツールでより早く実装できるようになった。またCIビルドの環境構築でも全く知見の無いレベルからAIツールのおかげで理解を進めることができた。

  • インターネットで調べるよりGeminiに聞いた方が早い

  • テストコードを書くのに時間がかかるため、時間が無い時はテストコード無しで進めてしまうことがあったが、テストコードを書く(書いてもらう)ようになった。

このように、AI ツールの導入により開発効率が向上し、より多くのコードベースに関与できるようになったり、新しい技術を学ぶ機会が増えたりしていることがわかりました。また、Gemini に質問したほうが 検索を行うよりも早いという意見もあり、AI ツールが情報収集の手段としても有効でありそうです。

AI に関する困りごと

さて、これまで AI の活用について良い話ばかりしてきましたが、ある程度の困りごともあるようです。

  • 回答を待つ間など時間を効率的に使える動き方に自身が適応したい

  • 生成されたコードが正常に動作しない場合がある。改善してほしさもあるが、逆になぜそれだと上手くいかないのかという勉強にも繋がるときもあるので、自分にとってはバランス難しい

  • 1つの機能に特化している場合、圧倒的に早く有用です。しかし複数の機能を持つWebアプリケーション開発では、ちゃんとハンドリングが必要な点を実感しています。

  • LLM が作成したコードのレビューと、ほかメンバーからのコードレビューがあり、レビュー時間が大幅に増えてきているためなんとかしたい。 LLM をローカル環境で気軽に試せるようなスペックの実行マシンの配布があると嬉しい。

  • 困っているわけではないが、claude code や gemini cli の利用が増える中で、GitHub Copilotをそのままにしておいて良いのか少し気になっている。ただ、コード補完がなくなってしまうのは厳しい気がする。

AI の導入によって、AI が生成したコードの品質やレビューに関する課題が多く生じていることがわかります。また、AI に仕事を依頼している間の時間の使い方について考えている方も多くいらっしゃいました。GROOVE X では、これらの課題に対して、スプリントレトロスペクティブで話し合われたりと積極的に改善しようと試みています。

AI とつきあっていくコツ

GROOVE X のエンジニアたちが、AI を積極的に活用していることが分かってきました。最後に、AI と上手く付き合っていくコツを教えてもらいました。

  • 自分が分かっていることでも、答え合わせで聞いてみる。ときどき違う視点での回答や気づきが得られる。

  • こういう概念を導入したらLOVOTがよくなるのでは、というときに、人間や動物の場合のリファレンスなどをGeminiにまとめてもらうとしきい値とかを決めるのに時間がかからないし、自分で考えたしきい値とレポートで出たものが近ければ考え方に大きな間違いがなさそうという確認にもなる。

  • しっかりハンドリングは必要

  • 1つ前のPRで作った機能も再発明してくる。コードの重複は大変多い
  • 長いコンテキストは苦手。小さいことは正義。
  • アーキテクチャの設計も一緒にやるといい。ディレクトリ構成やDDDライクな感じもこちらが理解している方が良くて、道筋立てる必要がある

AI を活用した開発ならではのティップスが急速に生まれているのが分かります。

まとめ

GROOVE X のエンジニアたちが、積極的に AI を導入・活用していることを、改めて知ることができました。生産性の向上のみならず、新しい技術の習得や、アイデアの創出など、様々な面で AI が役立っているようです。

最後に

GROOVE X では積極的に採用を行っています！ AI を活かした LOVOT の開発に一緒に取り組みたい方、ぜひ以下のリンクから募集職種をご確認ください。

recruit.jobcan.jp

Cloud Run (Next.js) と Cloud SQL の接続構成

開発

はじめに

こんにちは、junya です。Cloud Run上で動作するNext.jsアプリケーションから、Cloud SQL (PostgreSQL) データベースへ接続しようとしたところ、思いのほか苦戦したので、記録として残しておきます。

技術的選択肢と接続ライブラリ

選択肢が多々あり、その選択肢の意味を理解し、適切なものを選び、設定していくのが大変でした。Cloud RunとCloud SQLの連携には、主に以下の要素の組み合わせで構成が決まります。ここでは、Cloud Runからの接続方法を主軸に、それぞれの技術的選択肢とDrizzle ORM (Node.js) で利用するライブラリを整理します。

  • 前提となる選択肢

    • ネットワーク構成:

      • Public IP: Cloud SQLインスタンスにパブリックIPアドレスを割り当てます。

      • Private IP: VPCネットワーク内にのみIPアドレスを割り当てます。VPCコネクタが別途必要となります。

    • PostgreSQL接続方式:

      • TCP: localhost:5432のようなホスト名とポート番号で接続します。

      • Unix Socket: /cloudsql/[INSTANCE_CONNECTION_NAME]のようなファイルシステムのパスで接続します。

    • 認証方式:

      • パスワード認証: データベースにユーザー名とパスワードを設定します。

      • IAMデータベース認証: Google CloudのIAMプリンシパルを利用します。接続方法には主に以下の2種類があります。

        • Cloud SQL Auth Proxy: Proxy（またはConnectorライブラリ）が認証トークンの取得と利用を自動化します。

        • gcloud sql generate-login-token: gcloudコマンドで一時的な認証トークン（パスワードとして使用）を手動で生成します。

  • Cloud Runからの接続方法の選択肢

    • Cloud SQL Auth Proxy経由

      • 概要: Cloud Runの機能として、アプリケーションコンテナと同一環境でCloud SQL Auth Proxyコンテナを起動します。アプリケーションは、TCP (localhost) またはUnixソケット経由でこのProxyに接続します。

      • 利用ライブラリ (Drizzle):

        • drizzle-orm

        • pg (node-postgres) または postgres (postgres.js)

        • @google-cloud/cloud-sql-connector
      • 備考:
        • Cloud Run には Cloud SQL Auth Proxy を自動で動かすオプションがあります。
        • pg (または postgres) 単体では、IAM 認証がうまくいかず、 @google-cloud/cloud-sql-connector の力を借りました。

    • VPC経由の直接接続

      • 概要: VPCコネクタを利用してCloud RunとCloud SQL間のネットワーク経路を確立します。データベースのPrivate IPに直接接続します。認証にはユーザー名とパスワードを使用し、これらの認証情報はSecret Managerで管理するのが一般的です。

      • 利用ライブラリ (Drizzle):

        • drizzle-orm

        • pg (node-postgres) または postgres (postgres.js)

      • 備考: Secret Manager 等で認証情報を管理

    • @google-cloud/cloud-sql-connector の活用

      • 概要: Cloud SQL Proxy の代わりに、 @google-cloud/cloud-sql-connector で proxy する方法です。詳しくは知らないので、気になる方は調べて下さい。

これらの選択肢の組み合わせによって設定方法が異なり、特にライブラリと認証方式の相性によって問題が発生することがあります。

動作した構成

最終的に動作した構成を共有します。

  • 接続方式: Cloud SQL Auth Proxy
    • Cloud Run : Cloud Run 設定で有効化
    • 作業マシン : cloud-sql-proxy コマンド

  • 認証方式: IAMデータベース認証

    • Cloud SQL : IAM認証を有効化
    • Cloud Run : 利用するサービスアカウントに roles/cloudsql.instanceUser 権限を付与

  • ネットワーク構成:

    • Cloud SQL  : Public IPを有効化

    • Cloud Run : 特別な設定なし

  • Cloud Runからの接続: 公式コネクタライブラリ (@google-cloud/cloud-sql-connector) をアプリケーションに組み込みます。

  • Next.jsからの接続:

ハマりポイント

  • Cloud SQL はマネージドサービスなので、GCPプロジェクト下にあるように見えて、実際はGoogleが管理するネットワーク下にあり、VPC Peering 設定をして VPC アクセスコネクタを作らないと、Private ネットワーク経由で Cloud Run から Cloud SQL に接続することは出来ません。これは、Cloud SQL Proxy を利用する場合にも同様です。（今回は Public IP を利用したので、この設定はしませんでしたが、Private ネットワーク経由での接続のほうが、よりセキュアです） 
  • Cloud SQL Proxy を利用するには、Cloud SQL側でIPアドレスが必要ですが、IPさえ発行されていればよく、承認済みネットワークの設定は不要です。
  • IAMグループ認証によって、グループ単位で認証が可能になりますが、接続時に利用するのは、個人のメールアドレスです。
  • Cloud SQL Proxy を利用する場合、Unix Socket 接続になります。アプリケーション側の設定で、TCP 接続を想定した記述になっていると接続できないので、注意してください。また、なぜか node-postgres 単体では接続ができず、 @google-cloud/cloud-sql-connector による補助的なクライアント設定が必要でした。
  • IAMグループ認証で追加されたユーザは、自動で cloudsqlsuperuser 権限が付与されるので、特別なことなどしなくとも、grant 文など発行できます。Cloud SQL で superuser 権限を持つユーザは作れません。

3.1. 本番環境 (Cloud Run)

terraform の google_cloud_run_v2_service リソースで Cloud SQL Auth Proxy を有効化できます。

resource "google_cloud_run_v2_service" "main" {
  ...
  template {
    # Cloud SQL Proxy volume
    volumes {
      name = "cloudsql"
      cloud_sql_instance {
        instances = ["<instance name>"]
      }
    }
    containers {
      ...
      # Cloud SQL Proxy volume mount
      volume_mounts {
        name       = "cloudsql"
        mount_path = "/cloudsql"
      }
   ...
}

3.2. ローカル開発環境

cloud-sql-proxy --auto-iam-authn <project>:<region>:<instance> --impersonate-service-account <service_account_email>

このように service account になりすまして、

psql "host=127.0.0.1 sslmode=disable dbname=<db_name> user=<service_account から gserviceaccount.com を削除したもの>"

のように接続できます。

Drizzle 設定

動作したコードだけ貼っておきます。

import { AuthTypes, Connector } from '@google-cloud/cloud-sql-connector';
import { drizzle } from 'drizzle-orm/node-postgres';
import { Pool, type PoolConfig } from 'pg';
import * as schema from './schema';

let client: Pool;

// see: https://github.com/drizzle-team/drizzle-orm/issues/4165
if (process.env.POSTGRES_INSTANCE_CONNECTION_NAME) {
  // Cloud Run
  const connector = new Connector();
  // @ts-ignore
  const clientOpts = await connector.getOptions({
    instanceConnectionName: process.env.POSTGRES_INSTANCE_CONNECTION_NAME,
    authType: AuthTypes.IAM,
  });
  const poolOptions: PoolConfig = {
    ...clientOpts,
    user: process.env.POSTGRES_USER,
    database: process.env.POSTGRES_DATABASE,
    max: 5,
    idleTimeoutMillis: 30000,
    connectionTimeoutMillis: 2000,
    ssl: false,
  };
  client = new Pool(poolOptions);
} else {
  // localhost
  const connectionString =
    process.env.DATABASE_URL || 'postgres://postgres:password@localhost:5432/db?sslmode=disable';
  client = new Pool({ connectionString });
}

export const db = drizzle(client, { schema });

export type Database = typeof db;

まとめ

Cloud Run + Cloud SQL なんて、枯れたパターンだと思っていたのですが、思いのほか大変でした。どなたかのお役に立てると幸いです。

参考情報

LOVOT QA効率化の話：シニア＋ジュニア＋AI最強説

開発 品質管理

こんにちは、junya です。前回に引き続き、QAツール開発の第3回をお届けします。

今回は、QAツール開発で、インターンの方とAI（主に Claude Code）を使って開発したら、生産性がバク上がりしたというお話です。

シニア＋ジュニア＋AI 最強説

はじめに結論から書きますが、シニア＋ジュニア＋AIは最強です。互いに相補的な関係があるからです。

  • シニア
    • 技術選定やアーキテクチャ設計
    • 難しめのタスクの実装
  • ジュニア
    • 仲間とコミュニケーションできる
    • 柔軟な動作確認など、AIにできないことができる
  • AI
    • 技術に詳しい
    • 実装が速い

これによって、シニアが1つの難しいタスクに取り組んでいる間に、ジュニア＋AIで、平易だけど大切なタスクを5つ解決できます。そして、意外とこの「平易なタスク」の範囲は広く、要件や実装方針をシニアが明示できるものは、だいたいジュニア＋AIで実装可能です。

では具体的に、QAツール開発プロジェクトで何が起きたか、順番に見ていきましょう。

関係者のご紹介

  • シニア わたし。業務プログラミング歴22年。3月からClaude Codeにどっぷりハマり、2週間でQAツールの基本機能を実装しました。
  • ジュニア 公的機関から出向のインターン生。社会人3年目。理系大学出身ですが、業務プログラミング経験はありません。数学オリンピック、謎解きが大好きで地頭が良い方です。
  • AI Claude Code を開発で利用しつつ、何でもまずは Gemini に聞いてみる、という使い方です。Claude Code は devcontainer で動かしていました。途中から Devin も活用しました。

1ヶ月間の成果

ジュニアのインターン生が来てから、1ヶ月間での彼女の成果はこちらです。

  • 期間： 22日間
  • PR： マージ済みPR 30個

実装機能：

  • UI/UX改善
    • 自動テスト関数引数の表示改善
    • 画面レイアウト調整（全幅利用、レスポンシブ表示等）
    • 入力欄の末尾空白除去
    • リロードボタン追加
    • 添付/キャプチャ画像のモーダル表示
    • ブラウザタブ用faviconアイコン作成
  • 機能追加・連携強化
    • Slack連携機能
    • スマホ画面Inspect機能
    • テスト対象機体の誤設定時の警告機能
    • LOVOTリモート接続機能
  • 自動テスト支援関数の実装
    • 画面一覧表示機能
    • モバイル操作（ページ遷移、クリック、スワイプ、要素検証など）

これらを、残業なし、他のタスクもやりながら達成しました。

なお、その間に私は、彼女からの質問に答えたり、PRを見てアドバイスをしたり、AIを活用するコツの情報交換などしながら、アプリケーションのElectron化や、添付ファイルの仕組み、Poco agent の nuitka ビルドなどを実装しました。

うまくいった秘訣

うまくいった秘訣がいくつかあるので、ご紹介します。

  • 新規の社内向けツール
    1つは、開発対象が新規の社内向けツールだったことです。新規ツールということで、平易だけど重要な、小さな開発要件がたくさんあり、AIコーディングにぴったりでした。また、社内向けツールということで、デザインや機能の自由度が高かったことも大きいです。

  • Devcontainer
    devcontainer の開発環境を用意しておいたのが便利でした。IDE（GoLand でしたが、VSCodeも可能）をインストールして Docker を入れれば、devcontainer の立ち上げだけで環境が出来上がります。セキュリティリスクも低いです。 今回の実習では、2日目の午前中には環境構築が完了し、2日目の午後から1つ目のタスクのペアワークができました。参考までに、利用した devcontainer 設定を共有します。Microsoft のベースイメージと、Claude Code の feature ファイルを利用するのがポイントです。

// .devcontainer/devcontainer.json
{
  // Dev Containerの表示名（例）
  "name": "TS/Go Claude Code Dev Container (GoLand)",

  // ベースとなるイメージ。Microsoft提供のUbuntu 24.04ベースイメージを使用。
  // デフォルトで 'vscode' ユーザー (UID/GID 1000) と基本的な開発ツールが含まれます。
  "image": "mcr.microsoft.com/vscode/devcontainers/base:ubuntu-24.04",

  // --- Dev Container Features: 追加のツールやランタイムを簡単に導入 ---
  "features": {
    // Claude Code 連携機能 (Anthropic 提供)
    "ghcr.io/anthropics/devcontainer-features/claude-code:latest": {},

    // Bun ランタイム (コミュニティ提供のfeatureを使用)
    "ghcr.io/prulloac/devcontainer-features/bun:latest": {
      "version": "latest" // または特定のバージョンを指定
    },
    // Go 言語環境
    "ghcr.io/devcontainers/features/go:1": {
      "version": "latest" // または特定のバージョンを指定
    },
    // Node.js 環境 (LTS版を推奨)
    "ghcr.io/devcontainers/features/node:1": {
      "version": "lts"
    },

    // --- 開発補助ツール ---
    // aqua: 開発ツールのバージョン管理
    "ghcr.io/aquaproj/devcontainer-features/aqua-installer:0.1.3": {
      "aqua_version": "v2.51.2" // 使用するaquaのバージョン
    },
    // direnv: ディレクトリごとの環境変数管理
    "ghcr.io/devcontainers-community/features/direnv": {},
    // GitHub CLI: GitHub操作の効率化
    "ghcr.io/devcontainers/features/github-cli:1": {},

    // 共通ユーティリティ (Zshの導入とデフォルト設定など)
    // ベースイメージの 'vscode' ユーザーが使用されるため、ユーザー作成関連の設定は基本的に不要です。
    // Git設定の継承など、便利な機能も含まれます。
    "ghcr.io/devcontainers/features/common-utils:2": {
      "installZsh": "true",                // Zshをインストール
      "configureZshAsDefaultShell": "true", // Zshをデフォルトシェルに設定
      "installOhMyZsh": "true",            // Oh My Zshをインストール (任意)
      "installOhMyZshConfig": "true",      // Oh My Zshの設定を導入 (任意)
      "upgradePackages": "false",          // コンテナビルド時のパッケージアップグレードはスキップ (任意)
      "configureGpg": "false"              // GPGキーの設定は行わない (任意)
    }
  },

  // ホストマシンのファイルをコンテナ内にマウントする設定
  "mounts": [
    // ホストの .gitconfig をコンテナ内の 'vscode' ユーザーのホームに読み取り専用でマウント
    // これにより、ホスト側のGitユーザー設定をコンテナ内で利用できます。
    // readonly設定は、コンテナ内からホストの設定ファイルを誤って変更しないために強く推奨されます。
    "type=bind,source=${localEnv:HOME}/.gitconfig,target=/home/vscode/.gitconfig,readonly"

    // 他にもマウントしたいファイルやディレクトリがあればここに追加します。
    // 例: ホストのSSH鍵をコンテナにマウントして、プライベートリポジトリへのアクセスなどに使用する場合
    // "type=bind,source=${localEnv:HOME}/.ssh,target=/home/vscode/.ssh,readonly"
  ],

  // 特定のネットワーク機能が必要な場合のDocker実行時引数 (例: Claude Codeの特定の機能やデバッグ時)
  // 通常はコメントアウトしておき、必要な場合のみ有効化します。
  // "runArgs": [
  //   "--cap-add=NET_ADMIN", // ネットワークインターフェースの管理権限
  //   "--cap-add=NET_RAW"    // RAWソケットへのアクセス許可
  // ],

  // コンテナ作成「後」に実行したいカスタムコマンド
  // 例: プロジェクト固有のセットアップスクリプトを実行
  "postCreateCommand": "chmod +x .devcontainer/setup.sh && .devcontainer/setup.sh",

  // コンテナ内で使用するユーザーの指定
  // この設定を省略すると、ベースイメージのデフォルトユーザー ('vscode') が自動的に使用されます。
  // "remoteUser": "vscode", // 明示的に指定することも可能です。

  // --- IDE固有のカスタマイズ設定 (ここではJetBrains GoLandの例) ---
  "customizations": {
    "jetbrains": {
      // GoLandがGo SDKを自動検出できない場合にパスを指定 (通常は自動検出されるため不要)
      // "goSdkPath": "/usr/local/go/bin/go"
      // GoLandにインストール推奨のプラグインリスト (例)
      "plugins": [
        "com.github.biomejs.intellijbiome",
        "com.github.copilot",
        "com.github.shiraji.findpullrequest",
        "com.intellij.tailwindcss",
        "intellij.nextjs",
        "intellij.vitejs",
        "org.toml.lang",
        "PythonCore" // Pythonサポートが必要な場合
      ]
    }
    // VSCode固有の設定は "vscode": { ... } のように記述します。
  },

  // --- コンテナ内の環境変数設定 (オプション) ---
  "containerEnv": {
    // Go Modules Proxyの設定 (Goプロジェクトで必要に応じて設定)
    "GOPROXY": "direct", // direct以外に、プロキシサーバーを指定することも可能
    // プライベートリポジトリへのアクセス設定 (自社のリポジトリなどに合わせて変更)
    "GOPRIVATE": "github.com/your-repo"
  }
}

#!/bin/bash
# .devcontainer/setup.sh
# 日本語ロケールのインストールと設定
sudo apt-get update
sudo apt-get install -y --no-install-recommends locales language-pack-ja
sudo locale-gen ja_JP.UTF-8
sudo update-locale LANG=ja_JP.UTF-8

# プロファイルにロケール設定を追加
echo 'export LANG=ja_JP.UTF-8' | sudo tee -a /etc/profile.d/locale.sh
echo 'export LC_ALL=ja_JP.UTF-8' | sudo tee -a /etc/profile.d/locale.sh

## Claudeファイアウォール初期化
#sudo /usr/local/bin/init-firewall.sh

# aquaのパスを各シェルの設定ファイルに追加
echo 'export PATH="/home/vscode/.local/share/aquaproj-aqua/bin:$PATH"' >> ~/.bashrc
echo 'export PATH="/home/vscode/.local/share/aquaproj-aqua/bin:$PATH"' >> ~/.zshrc

  • Claude Code の使い方
    普段の実装も、基本、このやり方で実装しています。

    1. Claude と壁打ちして、実装方針を決める（コードはまだ書かせない）
    2. 実装方針をチェックリストとともに、Markdownに書かせる
    3. それを元にClaudeのコードを書かせる

    コードの配置や利用ライブラリなど、提出されたコードがシニアの実装意図と異なる場合は、シニアからジュニアに、PRや口頭やチャットでフィードバックしました。

  • ステップに分解する

    • スマホのスナップショットをPocoでキャプチャして、
    • Poco agent が仲介し、
    • TypeScript で受け取って画面に表示

    というような、やや複雑なタスクの場合、

    • まずは、スマホのスクリーンショットだけを取得してファイル保存するスクリプトをClaudeに実装させて
    • 次に、APIを叩いてスクショ撮るスクリプト書かせて

    などと段階を踏んでAIに実装をさせるといいよ、とアドバイスしました。ステップを踏めば、どこで躓いたかがわかり、ジュニアでも自身で問題解決できます。

  • 検証用スクリプトを書く
    前項の「ステップに分解する」と関係しますが、いきなり機能をアプリケーションに組み込むのではなく、「スクショを撮るスクリプト」のような単体スクリプトやテストをAIに書かせると、実装がスムーズになりました。

  • 難しいものは巻き取る
    どうしても難しそうなものは、巻き取ったり、保留したりしました。今回の場合、録画機能は実装に詰まったので、深追いせずに保留して他のものを進めてもらいました。後で自分の方で対応します。

  • 困ったときはペアワーク
    ジュニアがAIとの対話で行き詰まったり、より複雑な実装の理解が必要な際には、シニアとジュニアでペアワークを行い、一緒に問題解決や仕上げを行いました。これにより、知識移転もスムーズに進みました。

  • スタイリングはAIに任せる
    社内ツールということもあり、スタイリング（Tailwind CSS）は、はじめの大枠だけ整備して、あとは原則としてレビュー対象とせず、AIの実装をそのまま信じると割り切りました。

  • うまくいかないときはゼロからやり直す
    試行錯誤を進めると、Claude が堂々巡りしてしまうことがあります。そういうときは、一度それを捨てて、改めて必要な条件を伝えて実装方針を作り直し、コードを一から書き直させていました。これ結構、大切です。

まとめ

以上、シニア＋ジュニア＋AIで生産性が非常に高くなった事例をご紹介しました。 AIの足りないところを人間が補い、技術面をAIが担当し、難しい部分をシニアが巻き取ることで、相補的に生産性を上げることができます。

いろいろチャレンジしていて楽しい職場なので、よかったら開発チームに参加しませんか？

学生さん向けには、サマーインターンシップも開催しますので、是非ご応募ください。

tech.groove-x.com

GROOVE X のサマーインターンシップで LOVOT の開発に携わってみませんか

概要

こんにちは。ソフトウェアエンジニアの id:iizukak です。

GROOVE X では今年からサマーインターンシップの形式でインターン生の一括募集を行うことにしました！

今までも、参加されたインターン生の新鮮なアイディアに社員が影響されたり、独自性の高い成果が出たりと、インターン生による良い影響が多くありました。現在、GROOVE X では AI を活用した開発を推し進めている最中であり、AI の支援によってインターン生が活躍していただける機会はどんどん増加していると感じています。

また、GROOVE X では、OS レイヤーからクラウドレイヤーまで、多様なエンジニアが密に連携を行って LOVOT を作っています。日常の仕事の中で、これほど多様なエンジニアと交流できる会社はそれほど多くないかもしれません。

興味を持たれた方は以下の求人票をチェックしてみてください！

↓↓↓

インターンシップ 求人一覧 | GROOVE X株式会社

↑↑↑

プロジェクト一覧

サマーインターンシップでは、以下にリストするプロジェクトに取り組んでいただきます。興味のあるプロジェクトがありましたら、ぜひリンク先で詳細をご覧ください。

AI技術を活用したテクニカルサポートシステムの開発

AI技術を活用した、新しいテクニカルサポート用の支援システムを開発していただきます。

LOVOTのテクニカルサポートでは、お問い合わせ内容、検査結果、ログ、メトリクスなどの様々なデータを用いて、トラブルの原因を探ります。 本テーマでは、今まで分散していた各種データを一箇所に集約して表示し、さらにAIによって得られた示唆を表示したり、ユーザがAIとの対話で新しい示唆を得られることを目標とします。

AI技術を活用したテクニカルサポートシステムの開発(本社)の採用情報 | GROOVE X株式会社

画像認識モデルの精度評価とエッジデバイス上での推論速度評価

LOVOTに搭載する機械学習モデルを評価していただきます。 LOVOT 上では機械学習を利用した様々な画像認識モデルが動作しています。 本テーマでは、物体検出および顔識別をターゲットタスクとして、様々なモデルの精度と、LOVOT に搭載されている Jetson 上での推論速度を評価します。

具体的には以下のような仕事が含まれる想定です。

  • エッジデバイスにデプロイ可能なモデルの調査
  • LOVOT で撮影した画像による精度評価
  • TensorRT への変換プログラムの実装
  • Jetson 上での推論速度評価

画像認識モデルの精度評価とエッジデバイス上での推論速度評価(本社)の採用情報 | GROOVE X株式会社

Development of Robotics Localization System

This role is centered on optimizing the localization and mapping system for LOVOT and developing essential monitoring tools to track its performance. LOVOT perceives its environment using a variety of sensors, with cameras providing rich data for understanding surrounding space and people. Operating within diverse home environments presents unique challenges, making the continuous enhancement of LOVOT's spatial awareness, navigation accuracy, and overall performance critically important. In this theme, you will build and demonstrate software to improve LOVOT's localization system, or evaluate the system, on the following topics: Develop a "ground truth" data collection system to compare LOVOT's localization with actual measurements. Implement image recognition to identify moving objects and furniture and mark these items on the map. Implement a Visual Place Recognition task based on neural networks. Optimize LOVOT Visual SLAM.

Development of Robotics Localization System(本社)の採用情報 | GROOVE X株式会社

強化学習によるLOVOTの移動能力の向上

強化学習を用いて、LOVOTの移動能力の向上に取り組んでいただきます。 LOVOTは家庭環境という多種多様な環境で転倒することなく、かつ生物らしい特性を持った動作をし続ける必要があります。 本テーマでは、移動性能にフォーカスして、多種多様な環境に適用させていくために、強化学習を使って、以下のような内容に挑戦していただきます。

  • 移動中に発生する障害物との衝突によってバランスを崩さないような方策を学習すること
  • 他のLOVOTや人から押されたときや、不安定な足場に置かれたときに転倒しないための方策を学習すること
  • 移動の機能上の要求を達成するだけではない生物らしい性質を持った動作を、教師データを元に学習すること

応募要件

応募要件はそれぞれのプロジェクトごとに異なるため、プロジェクトごとの求人票をご参照ください。共通した要件として、

2027年に卒業予定である学生、大学院後期課程に在籍されている方

という学年の制約があるので、ご留意ください。

最後に

GROOVE X で、LOVOT というユニークな家庭用ロボティクスの開発に参加してみませんか？ きっと興味深い体験になると思います！

↓↓↓

インターンシップ 求人一覧 | GROOVE X株式会社

↑↑↑