旺盛な学習意欲で自らのスキルや知見に磨きをかけ続けているGunosyのエンジニアメンバー。なかでも定期的に実施されている『はにびぶ』は、チームの垣根を超えて知識や情報をシェアしたり、失敗やしくじりから改善のヒントを得たりするための場として、社内で非常に大切にされている技術文化です。
この『はにびぶ』という名称は、名言「愚者“は”経験“に”学“び”、賢者は歴史に学“ぶ”」の「は・に・び・ぶ」から来ています。他チームの過去（歴史）を自らの学びに変え、改善のインスピレーションを得るという会の目的にぴったりの名前です。コロナ禍を経て、今回が待望のオフライン開催第2回目。会場となった会議室はテクノロジー本部の各チームに加え、新規事業開発室のメンバーも含めた多くのエンジニアが集結し、開始前からあちこちで技術談義が始まる熱気に包まれていました。
前半：LLM活用の試行錯誤と、手に汗握る「しくじり」の共有
前半戦は第1プロダクト、Ads、第2プロダクト、第3プロダクトの4チームが登壇。各チーム、スライドを駆使して現場のリアルな数字やコードを惜しみなく披露しました。
第1プロダクト — 現場で見えたLLM活用のリアル
トップバッターは第1プロダクトの永山さん。「クライアント開発でのLLM活用術とつらみ」と題し、iOS開発ではCopilot、Android開発ではClaude、技術調査ではGeminiといった使い分けの現状を共有しました。特に関心を集めたのは、AndroidのUI実装（XMLからComposeへの変換）におけるモデル別の精度比較です。永山さん個人の検証環境では、Claude Sonnetが80点、Haikuが60点、Gemini 3 Proが30点という生々しい結果に。Sonnetはパーツ単位の完成度は高いものの、全体のレイアウト構成に難があるといった具体的な「つらみ」が明かされました。「プロンプトを練る時間がコードを書く時間を上回る逆転現象」への言及もあり、AIを盲信するのではなく「人間が大枠を作り、AIにはミクロな実装を任せる」という現実的な着地点を提案し、会場の共感を呼んでいました。
Adsチーム — 全広告停止から学んだ教訓
続いて登壇したAdsチームの平尾さんは、「ヒューマンエラーとシステム不整合の教訓」というテーマで、直近半年間に発生した4つの障害事例を赤裸々に公開しました。なかでも「ノードグループの追加だから安全」という思い込みから全広告が4分間停止してしまったEKSアップデートの事例や、iOSのセルラー通信時のみ動画が表示されなかったパス設定ミスなど、非常に重みのある内容でした。平尾さんは「差分とログへの執着」の重要性を説き、対策としてTerraformに削除保護（prevent_destroy）を導入するなど、二度と同じ過ちを繰り返さないための徹底した仕組み化を紹介。失敗を隠さず「転ばぬ先の杖」として組織全体に共有する姿勢は、まさに『はにびぶ』の精神を体現するものでした。
第2プロダクト — 開発のジレンマと共通化への道
第2プロダクトの本多さんは、チーム名が「人事通達の殴り書き」から決まったというユーモア溢れる裏話を交えつつ、グノシー側とコンテンツ基盤側での「開発のジレンマ」を解説。Dripman（LLM記事タグ付け）や気象API、クローラーの統合など、特定プロダクトに最適化すべきか、汎用的な基盤として作るべきかというエンジニア特有の葛藤を詳細に語りました。成功例として紹介された「GPC（媒体社向け管理画面）」のように、各メディアが横断的に管理できる理想の状態を目指し、それぞれの視点を尊重しながら「できるところから共通化を進める」という前向きな方針が示され、組織横断チームならではの苦労と面白さが伝わってきました。
第3プロダクト — 秒間380から1500へ。Redis移行による負荷改善
前半のトリを飾ったのは、第3プロダクトの山田さん。人気機能「おかわりガチャ」の在庫リセット時間である朝7時にリクエストが集中し、RDSのデッドロックが発生した事例を報告しました。秒間380リクエストで限界を迎えていたシステムを、在庫管理をRedisに移行し、RDBへの書き込みを非同期化することで、秒間1500リクエストに耐えられるまで改善したプロセスを詳解。ここでもClaude Codeが負荷試験ツールの開発に役立ったことが触れられ、監視メトリクスに「CPU以外の待機時間」を加えるといった具体的なテクニックの共有には、多くのメンバーが熱心にメモを取っていました。
後半：MLのロジック進化と、スピード感溢れる新規事業開発
休憩時間には軽食を片手に、発表者への追加質問が活発に交わされました。後半戦はML、新規、QAの3チームが登壇し、さらに高度な活用事例が続きます。
MLチーム — ロングテールを支えるLLMタグ抽出
MLチームの上村さんは、ニュースアプリの多様性を支える「ロングテール対策」としてのLLMタグ抽出について発表。これまでの辞書ベースでは追いきれなかったニッチなワードや最新トレンドをLLMで抽出し、意味論的なスコアリングを行うことで、クリック率（CTR）だけに偏らない、ユーザーの深い興味に応える推薦ロジックを開発しているとのこと。LLMを「単なる翻訳機ではなく、コンテンツの深い理解者」として活用する試みは、メディアプラットフォームとしてのGunosyの未来を感じさせる内容でした。
新規事業開発室 — IR Hub改善と翻訳・OCR基盤のアップデート
新規事業開発室の井口さんは、『IR Hub』における怒涛の改善を振り返りました。PDF/DOCXファイルの翻訳において、レイアウトを崩さず、かつ「億」や「Billion」といったビジネス特有の単位変換をルールベースとLLMのハイブリッドで100%正確に行う工夫を披露。また、オンデマンドOCRへの移行により月額10万円のコスト削減に成功した事例は、技術とビジネスを直結させる新規事業らしいスピード感に満ちていました。さらに、LLMがコードを生成しやすいよう「Jira 1タスク = Figma 1URL」に整理するといった、開発プロセス自体のハック術も非常に印象的でした。
QAチーム — AIで進めるログ検証の自動化
最後を締めくくったのは、QAチームの宮城さん。「AIを活用したアプリログのテスト自動化」をテーマに、これまで膨大な目視確認を要していたイベントログの検証を、GPT-4oやGeminiを駆使して自動化した取り組みを紹介。期待値のJSONデータからテストコードを生成し、実際のログとリアルタイムで判定するツールを自前で構築し、すでに15%近い自動化を達成。これまでQAの負荷が高かった領域が劇的に効率化されている実績が報告されました。
フィッシュボウル座談会：AI時代の「エンジニアの価値」を問い直す
すべての発表後に行われた座談会では、中央の数名が入れ替わり立ち替わり議論する「フィッシュボウル」スタイルで、これからのエンジニアの在り方について熱い議論が繰り広げられました。
LLMは“特別なツール”ではなくインフラへ
冒頭、マネジメント層から「現場で実際にどうLLMを使いこなしているのか？」という問いかけがあり、議論がスタート。現場からは、もはやLLMは「特別なツール」ではなく、実装や検索、知識補完において「当たり前のインフラ」として溶け込んでいる現状が示されました。ツールの選択基準もシビアで、「実装力は高いがコストも高いClaude 3 Opus」をここぞという場面で使い、日常的な試行錯誤（バンバン叩く作業）には「速度が速く心理的障壁の低いGemini 3FlashをCursorやCopilot経由で使う」といった、徹底した使い分けの実態が明かされました。
Biz側の開発民主化とAI活用の広がり
その中で、特に驚きを持って迎えられたのは、「Biz側（非エンジニア）による開発の民主化」です。エンジニアではないメンバーがClaude Desktopを用いてRedashのSQL補完機能を自作したり、広告管理画面を便利にするブラウザ拡張機能を自ら開発したりしている事例が共有されました。「まずLLMにプロトタイプを作らせて、動作を見ながら仕様を詰める」という手法が非エンジニアにも広がっている事実は、組織全体の生産性向上を予感させました。こうした取り組みも、チーム内でのレビューやセキュリティ確認を行いながら進められています。
さらに話題は、お子さんのチームロゴ作成やゴルフのスイング解析、日報の4コマ漫画化といった実業務ではない部分での生成AI活用の話で盛り上がりました。「何をLLMに指示すべきか」を決めるのは、結局のところ広告やニュースといったドメインへの深い理解であり、そこが最大のボトルネックであるという指摘には多くの賛同が集まりました。
「開発そのものよりも、BizやPMとの合意形成・調整に最も時間がかかっている」という現状に対し、未来の展望として「システム構成を理解したボット同士が会話して仕様の矛盾を洗い出すマルチエージェント化」への期待が語られ、エンジニアがより本質的な課題解決に注力できる未来像が掲げられました。
第2回となったオフライン「はにびぶ」。閉会後も技術談義が尽きることなく続いていました。失敗をオープンに共有し、それを組織の血肉に変えていく。この「はにびぶ」という文化があるからこそ、Gunosyのプロダクトは進化を止めないのだと改めて確信できる、熱い3時間半でした。