新着 の記事一覧

GMOインターネットグループ株式会社の藤間裕史です。先日、AMD 主催の Open Robotics Hackathon に参加し、最優秀賞を獲得しました！この記事では、怒涛の日々を赤裸々に語るとともに、◆どんなハッカソンだったのか◆なにを開発したのか◆AIロボット技術がどこまで来ているのか紹介します。AIロボットの「今」と、日本での盛り上がりを少しでも感じてもらえたら嬉しいです。 🚀 ハッカソン概要 AMD Open Robotics Hackathon 本ハッカソンは、AMD主催（Hugging Faceも共催）した AIロボット（特にVision-Language-Actionモデル）に特化した実践型ハッカソンです。 特徴的だったのは、実用性の視点でAIロボットを設計し、学習～一連のデモまで作りきる形式だという点です。 開催期間：3日間（12/5 - 7）開催場所：東京・秋葉原（フランス・パリ、アメリカ・サンノゼでも開催）参加対象：学生・研究者・エンジニアなど なにより大変だった点として、なんと「国際ロボット展と丸被り」でした。 そのため開催期間は、昼は展示会対応、夜はハッカソン会場で朝まで作業の毎日でした。（※自分にとっては、ロボまみれで最高の日々） いい意味で異質だったGMO AIRのブース 🧰 支給された技術スタック 項目内容学習環境AMD Instinct™ MI300X GPU（AMD Developer Cloud）推論実行AMD Ryzen™ AI 搭載ノートPC（現地支給）ロボットキットSO-101 Robotics Kit AI学習フレームワークHugging Face LeRobot 展示会でも使用された、約5万円で作れるロボアーム「SO-101」 🤖 私たちが作ったもの 「ドーナッツ箱詰めAIロボット」 私たちが開発したのは、 「Vision-Language-Action（VLA）モデルをファインチューニングし、ドーナッツの箱詰め作業に特化させたAIを組み込んだロボット」です。 VLAモデルは、「カメラ画像＋プロンプトをもとに、ロボットの動作を出力するAIモデル」です。 このモデルを自前で集めたデータで学習させ、ドーナツショップ店員に改良しました。 https://youtu.be/vXm35VEmv4U?si=Z6Kib7bQ0DyOsLwh 実際のデモ 🔄 システム全体の流れ 画面表示、AIモデル推論、モデル切替を含めたAIロボットシステムとして設計しました。 🧠 技術的なポイント ロボットに動きを教えるためにまず、データを集めます。 遠隔操作でロボットを動かし、以下データを、それぞれ30データずつ集めました。 学習内容エピソード数（≒データ数）チョコドーナッツ箱詰め30イチゴドーナッツ箱詰め30箱を閉める動作30合計90 そして、小規模なVLAモデル「SmolVLA」をベースにして、集めたデータで学習させます。 タスクごとにAIモデルを分け、 ❶ドーナッツを箱に詰めるモデル ❷箱を閉めるモデル モデルの最後に「ベルを鳴らす」動作を含めることで「ロボ自らで制御するモデルを切り替える」仕様になっています。 🏆 なぜ評価されたのか（振り返り） ① 完成度 そもそものデモの完成度が高かったです。この難易度のタスクだと、数回中一回成功すればよいくらいですが、ほぼ100％に近い精度で動かすことができました。（メンバーのタスク選定と環境整備のセンスが光ってました。） ② 実利用を想定したUI・UX設計 単なるデモではなく、実際の店舗で使われることを想定したUIと操作フローを設計しました。ロボットの状態が画面上で分かる構成にした点も、デモとして伝わりやすかったと感じています。 ③ チームでの進め方 役割分担して、得意な部分を作業しました。3日間という制約を最大限活かせました。（チームメンバーにも本当に恵まれました、ありがとうございました🙏） 優勝の瞬間。電撃が走りました。 🧾 おわりに 今回のハッカソンを通して、 Vision-Language-ActionモデルをはじめとするAIロボット技術の発展スピードに驚かされると同時に、実用を想定した実装の大切さを改めて学びました。 この経験を、インターネット革命後半戦「AIロボティクス」の時代に存分に活かしていきます。 最後に、GMOインターネットグループでは、こうした先端的なAIロボット技術にも積極的に取り組んでいます。もしご興味がある方がいれば、ぜひ共に次の時代を創っていきましょう！

この記事は GMOインターネットグループ Advent Calendar 2025 23日目の記事です。みなさん、おはようございます！こんにちは！こんばんは！GMOペパボ株式会社の横山です！！！！！！ はじめに こんにちは！GMOペパボ株式会社所属の横山です。社内ではあだ名で呼び合う文化があり、はるおつと呼ばれています。普段はロリポップ・ムームードメイン事業部にてムームードメインの開発を主に行なっています。 今回のアドベントカレンダーでは、先月11月18日にリリースされたばかりの、「Google Workspace カード」の信頼性向上に向けて、「可観測性ってなに？」状態から行なった可観測性向上とSRE的アプローチについて、つまづきポイントとそこからの学びについてまとめたいと思います。 Google Workspaceカードとは？ みなさん、Google Workspaceカードを知っていますか？！？！ ムームードメインは、ドメイン取得サービスの一環として、2025年2月からは Google Workspace の販売も開始し、ドメインと Google Workspace のシームレスな連携を提供してきました。 今回、このドメインとGoogle Workspaceの連携を、家電量販店などでカードを購入することで、購入者に対して Google Workspace の契約管理からドメイン取得・管理まで一貫して提供することが可能になりました！ (ぜひお店で見かけた際には、あの記事のあれだ！と思ってくれたら嬉しいです) システム概要 ユーザーの購入フローは以下の通りです： 店舗でGoogle Workspace カードを購入⇩プロダクトキーを入力⇩ムームードメインでドメインを選択 (.com, .jp, .devなど)⇩Google Workspace情報の入力 (組織名, adminメールアドレスなど)⇩ムームードメインにログイン・登録⇩決済情報を入力⇩ドメイン取得やGoogle Workspaceのセットアップ処理開始 このフローでは、複数の外部APIとの連携、決済処理、ドメイン取得、Google Workspace設定など、多くのステップが連鎖的に実行されます。 Saga Orchestrationパターンの採用 このような長時間にわたる複数サービス間のトランザクションを安全に処理するため、Saga Orchestrationパターンを採用しました。 Saga Orchestrationパターンの特徴は以下の通りです： 長時間トランザクションを小さなローカルトランザクションの連鎖として実装各トランザクションには補償トランザクションを定義失敗時は実行済みステップを逆順で補償 具体的なステップ構成は以下のようになっています： [正常フロー]Step1: アカウント検証 ↓Step2: カードの利用 ↓Step3: 契約作成（DB書き込み） ↓Step4: 決済完了（3DS認証） ↓Step5: クレカDB登録 ↓Step6: ドメイン取得 ↓Step8: GWS設定（Google API） ↓Step9: 注文確定[補償フロー（失敗時は逆順に実行）]Step2の補償: カードの再有効化 ↑Step3の補償: 取得契約の削除 ↑Step4の補償: 決済返金 ↑Step5の補償: skip (ドメインは取得済みのため) ↑Step6の補償: skip (クレカの登録は削除する必要がないため) ↑Step8の補償: GWS設定解除job作成 現状の課題とやるべきこと 可観測性向上に取り組むにあたり、まずムームードメインにおける現状を整理しました。 観点現状やるべきことログ分散、非統一集中、構造化トレース一部のAPMEnd-to-End外部API部分的全てSagaログのみトレースで状態追跡、分散トレーシング 私はこのGoogle Workspace カードという新機能追加を切り口として、長年続くサービスに可観測性を組み込むチャンスと捉えました。 段階的アプローチ 一度に全てを実装するのではなく、価値の高い部分から小さくリリースしていく方針を取りました。 Phase1: OpenTelemetry基盤構築 → 全ての前提、ベンダーロックインを回避し観測の標準化 Phase2: BaseControllerトレーシング追加 → 全コントローラアクションでのトレース・スパン自動付与 Phase3: Sagaトレーシング → GWSカードにおける処理の根幹、最も影響が大きい Phase4: 外部API可視化 → 外部API起因の障害の見える化、既存システムの信頼性向上 Phase5: アラート、SLI/SLO設定 → 検知自動化で運用負荷削減 つまずきポイント①：SpanContextの永続化問題 問題 Sagaパターンでは、セッションとして状態を保存・復元する必要があります。補償処理を実行する際に、元のステップのSpanと関連づけたいと考えました。 OpenTelemetryのLink機能を使うためにSpanContextを使いたかったので、最初はセッションにSpanContextをそのまま保存しようとしました。 # 各ステップでSpanContextをそのまま保存 @step_results[step] = result.merge( span_context: span.context # ← OpenTelemetryオブジェクト ) session.saga = @step_results.to_json エラー発生 span.context.to_jsonを試みましたが、NoMethodErrorが発生して頭を抱えていました。 undefined method `valid?' for "#<OpenTelemetry::Trace::SpanContext:0x000055f2740a3c70>":String なぜシリアライズできないのか span.context # => #<OpenTelemetry::Trace::SpanContext:0x000055f2740a3c70 # @trace_id="\xA1\xB2\xC3...", (16バイトのバイナリ) # @span_id="\x1A\x2B\x3C...", (8バイトのバイナリ) # @trace_flags=1, # @trace_state=...> SpanContextの実体を見てみると： つまり、単にSpanContextは実行時の一時オブジェクトなのですね。改めてなぜOpenTelemetryがSpanContextをシリアライズ可能にしていないか考えてみると、以下のような納得感がありました。 SpanContextは実行時の一時オブジェクトとして設計されているトレースはOTLP Exporterで送信されるべきアプリケーション側で永続化されることを想定していない しかし、補償処理を実行する際に、元のステップのSpanと関連づけたい場合はどうしたらよいのでしょうか？そのほかにも、3DS認証などに対しても、同じような問題にあたるのではないかと思います。 解決策：Span属性による関連付け Linkを使う代わりに、trace_idとspan_idを文字列として保存し、Span属性でオリジナルのtrace_idを関連付ける方式に変更しました。 # ステップ実行時 @step_results[step] = result.merge( span_context: { trace_id: span.context.trace_id.unpack1('H*'), span_id: span.context.span_id.unpack1('H*') } ) # セッション保存 - 成功！ session.saga = @step_results.to_json # JSON化可能 # 補償処理実行時：Span属性として関連付け original_span_info = @step_results.dig(step, :span_context) tracer.in_span("saga.compensation.#{step}") do |span| if original_span_info span.set_attribute('muu.compensation.original_trace_id', original_span_info[:trace_id]) span.set_attribute('muu.compensation.original_span_id', original_span_info[:span_id]) end # 補償処理実行 end これにより、以下が実現可能となりました。 セッション復元後も使用可能Grafana/Tempoで検索可能因果関係の追跡が可能 つまずきポイント②：Sagaパターンのトレーシング設計 可視化したいもの Sagaパターンで可視化したいものを洗い出しました： フロー全体: Saga実行の成功/失敗個別ステップ: どのステップで失敗/遅延が起きたか補償処理: ロールバックが正しく動いたか Spanの階層設計 どこにSpanを貼るべきかを検討し、以下のような階層構造にしました： 階層構造で因果関係が一目瞭然各ステップの実行時間を個別に測定して改善可能補償処理と元のステップの関係を追跡可能 order_event_idによる全リクエスト追跡 もう一つの課題として、HTTPリクエストが分断される問題がありました。 例えば： リクエスト1: 申し込み開始 → Saga → 3DS認証へリダイレクト（HTTP分断）リクエスト2: 3DS認証完了 → Saga再開 → 完了 通常のtrace_idでは2つのリクエストが別々のトレースになってしまいます。 これを解決するため、ビジネスキーであるorder_event_idで全体の紐付けを行いました： # rb/app/controllers/concerns/google_workspace_card/tracing.rb def set_session_attributes(span) # セッション情報をSpan属性として記録 span.set_attribute('gws_card.session_id', current_gws_card_db_session.id) span.set_attribute('gws_card.current_step', current_gws_card_db_session.current_step) span.set_attribute('gws_card.order_event_id', current_gws_card_db_session.gws_order_event_id) span.set_attribute('gws_card.account_id', account_id) end これにより、ビジネスロジックとしてDBに保存しているキーからもトレースを可能にすることが実現できました！ 成果 これらの取り組みにより、Grafanaで以下のようなアラートルールを設定できるようになり、Google Workspaceカード、そしてそれを取り巻くムームードメインの既存資産の可観測性を向上させることができました。 Saga処理失敗補償処理失敗（データ不整合の可能性）各ステップの失敗（GWSカード利用、ドメイン注文、決済準備、決済完了、GWS設定など）外部APIの接続失敗エラー率上昇レート制限DB接続エラー など、アラートルールを設定し、問題の早期検知が可能になりました。 まとめ SpanContextを保存したい時の注意点 SpanContextはJSON化できない - OpenTelemetryの設計思想として、永続化は想定されていないtrace_id, span_idを文字列として保存し、Linkではなくspan属性で関連付ける 分散システムには分散トレーシングが効果的 Sagaパターンのような分散システムにはログのみで確認するのは厳しいOpenTelemetryで階層構造のトレーシングを実現小さな切り口から開始して、価値のある場所から攻める 「可観測性って何？」から始まった取り組みでしたが、新機能開発を切り口にすることで、段階的に可観測性を高めることができました。同じような課題を持つ方の参考になれば幸いです。 最後に、Google Workspace カードは家電量販店等で販売中です。クリスマスプレゼントにいかがでしょうか？！？！

本ブログではGMOインターネットが2025年夏に開催したサマーインターンのレポート後編を紹介します。前編はこちらをご覧ください。後編では、「セキュリティコース」と「AIコース」をご紹介します。 セキュリティコース セキュリティコースでは、「インシデントハンドリング」と「アイデアソン」の2つのコンテンツを実施しました。今回のインターンのテーマは「答えのない課題に対してチームで挑む」です。セキュリティの業務は、単独で完結することは稀で、他のチームや部署と協力しながら進めることが大半です。そのため、コミュニケーション能力や論理的思考力が非常に重要になります。今回のプログラムでは、そうした実務に必要なスキルを体感できる内容を用意しました。それぞれのプログラムについてご紹介します。 インシデントハンドリング 実際にセキュリティインシデントが発生した際、組織内でどのように対応を進めるべきかを机上演習で学びました。インシデント対応の流れを理解し、分析力・判断力・報告力を養うとともに、組織的な対応力の重要性を学ぶことが目的です。一度の実施では理解が不十分になるため、複数回繰り返し実施し、段階的に難易度を上げていく形式を採用しました。初回は、企業とシステムの構成図を基にインシデントが発生したというシナリオでスタートします。参加者全員がBlueチーム(防御側)として、システム部門へのログ調査依頼や事業部との情報共有を行いながら、インシデント対応を進めていきました。回を重ねるごとに、システム構成がより複雑になったり、Redチーム(攻撃側)として調査結果を提供する立場に変わったりと、徐々に挑戦的な内容へと発展していきます。最後にはインシデントシナリオの作成なども行いました。 アイデアソン 与えられたテーマについてチームで議論し、成果をまとめて発表する「アイデアソン」を実施しました。正解のない課題に取り組むことで、思考力やチーム内でのコミュニケーション能力を養うことが目的です。限られた時間内でアイデア創出から発表資料作成までを進めるフレームワークを学び、それに沿って実践しました。テーマは、セキュリティに直接関連するものから、会社で生成AIを導入する際のポリシー作成など、幅広い内容を設定しました。インシデントハンドリングと同様、繰り返し実施することでフレームワークの理解が深まり、思考力の向上につながりました。 今回のインターンでは、技術面だけに焦点を当てるのではなく、参加者同士で活発に議論する機会を多く設けたため、参加者間の絆も深まりました。CTFなどセキュリティのインターンでありがちなコンテンツではなく、実業務に近い内容にしたことで「実際のセキュリティ業務のイメージがつかめた」「現場の仕事を体験できて良かった」といった声が多くあり、有意義な時間になったと思います。参加者の皆さんが楽しみながら学んでくれたことが、何よりの成果でした。 AIコース 概要 今年初開催となるAIコースでは下記をテーマにデータ＆AIチームメンバーが実施しました。 RAGチャットボット構築を実践し、精度改善手法を学ぶLLMセキュリティを理解し、サービス開発運用をend-to-endで体験するGMOの様々なAIを活用した業務内容を理解する 10名の学生が3チームに分かれ、「北九州市ごみ分別チャットボット開発」という実用的な課題に取り組みました。各チームには弊社のConoHaのGPUサーバー(L4)を提供し、RAG(Retrieval Augmented Generation)を軸としたチャットボット開発を学生主体で進めていただきました。学生は与えられた課題を基に、環境構築、要件定義、モデル選定、技術選定、開発、セキュリティ対策、そして精度評価と改善のループまで、実務に即した一連のプロセスをハッカソン形式で体験しました。 5日間の進行 初日はキックオフとオフィス紹介の後、セルフホストのStable Diffusionを使った画像生成課題でアイスブレイク。美雲このはちゃんの課題画像の要素を再現し高得点を競う課題を通して、チームで交流を行ってもらいました。課題をきっかけに徐々に打ち解け、各チーム和気あいあいと取り組んでいました。まずは基礎課題としてローカルLLMを用いたRAGチャットボットの実装に取り組みます。GPUサーバへのローカルLLMのセルフホスト、分別早見表を基にしたRAGによる対話、Streaming形式のレスポンスに対応したUIの実装など、各チームが課題を基に要件を定義し技術選定を行いながら開発を進めました。課題の制約としてDifyなどのGUIフレームワークは使用不可としており、学生たちはコードベースでの実装を行いました。 インターン中盤では各チームが開発したチャットボットを利用して、 プロンプトインジェクション（Prompt Injection）対策バトル を実施しました。LLM-as-a-Judge（以下LaaJ）による採点システムを経由して互いのチャットボットに攻撃を仕掛け、攻撃成功・防御成功時には得点が入り、スコアダッシュボードでリアルタイムに順位が表示される実践的なコンテンツです。攻撃フェーズと改善フェーズを30分ごとに切り替えることで、 プロンプトインジェクションの攻撃手法と、Promptの工夫やフィルター機構などの防御手法の両面を実装・学習しました。ダッシュボードでリアルタイムにスコアが可視化されゲーム感覚で熱中でき、逆転の瞬間には歓声があがるほど盛り上がりをみせたパートになりました。 PIJバトル後には、LaaJの概要説明と実装を行いました。参考情報を提供し、学生自身でLaaJを実行して評価・改善のループを回していきます。4日目以降は、LaaJによる評価・改善のループを軸に自分たちのチャットボットを改善していくフェーズです。精度向上やセキュリティ強化に加えて、Fine-tuningやクラスタリング分析、音声入出力、UI改善など多岐にわたる追加課題にも挑戦しました。またカリキュラムにはなかったのですが、面談での学生たちの要望を受けてチーム間で開発物に関するディスカッションの時間を設けました。ディスカッションを通じて、チーム横断で開発に関する知識、実装方法や学習内容をさらに深めることができました。最終日はコンテンツやチーム間での交流を踏まえて成果発表に向けた資料作成と引き続きの改善に取り組み、各自が設定した事前目標とその達成度を軸とした成果発表を行いました。 アンケート結果と運営所感 終了後のアンケートでは、「実践的なコンテンツでよかった」「チーム開発で現場のフローを模した貴重な体験ができた」「あいまいな課題を要件に落とし込んで調査、実装を行うことが難しく取り組み甲斐があった」という声をいただきました。5日間のインターンを通して、ローカルLLMを中心としたAIアプリケーション領域の実務について深く理解していただいたと同時に、AIという進歩の速い分野で起こるリアルな課題と、それを解決していくことへの楽しさを感じていただけたと思います。 レポート前編はこちら

この記事は GMOインターネットグループ Advent Calendar 2025 22日目の記事です。昨年に引き続き執筆させていただきました！！毎日公開される記事が面白くて夢中で読んでいます。 こんにちは！ GMOペパボ株式会社 事業開発部 Alive Projectチームでエンジニアをしているてつをです。 Alive Projectとは「配信者のアウトプットを支援する」をミッションに昨年10月にローンチした新規事業です。現在、提供しているサービスは主に、配信者向けのウェブメディア「ストリーマーマガジン byGMOペパボ」、配信画面デザインツール「Alive Studio byGMOペパボ」（以下：Alive Studio）です。 今回は Alive Studio に2025年12月16日にリリースしたばかりの「Twitch（配信プラットフォーム）のコメントをリアルタイムに OBS の配信画面上に表示する機能」の仕組みや設計についてお話しします。 Alive Studioとは Alive Studio は、配信者に広く使われている OBS Studio 上で動作するWebアプリケーションです。OBS Studio 内蔵のブラウザ機能（CEF: Chromium Embedded Framework）を活用しており、プラグイン不要で配信画面のデザインやコメントの表示・切り替えが可能です。 Alive Studioの仕組みについてもっと知りたい方は、以下のスライドを是非ご覧ください！ https://speakerdeck.com/teppei0717/burauzasutoreziwohuo-yong-sita-fu-shu-apuriwomataguyong-sok-hua-toriakuteibunatong-qi 先述した通りAlive Studio は Twitch との連携機能を新たにリリースしました。Twitch 連携により、以下のようなことが可能になります。 Twitch OAuth 認証による新規登録・ログインTwitch コメントを配信画面上にリアルタイム表示コメントをトリガーとした、Alive Studio ならではのインタラクティブな体験(特定のコメントによるエフェクトの発火や、コメントを使って視聴者が投票できる機能など) これまでAlive Studio が提供してきた「配信者だけではなく視聴者も巻き込んだインタラクティブな体験」を、Twitch のコメントを起点にさらに拡張できるようになりました。 本記事では、これらの機能のうち、配信中の Twitch コメントを配信画面上にリアルタイムで表示する部分にフォーカスして、その裏側の設計について紹介します。 Twitch 連携で直面した課題 Twitch のコメントをリアルタイムに取得・配信するにあたり、いくつかの技術的な課題に直面しました。 現状の構成では、Twitchと接続するためのWebSocket 、SSE などのステートフルな接続を Alive Studio が直接保持する必要があるためメモリ負荷が高く、スケールが難しいこと。Twitch / YouTube / TikTokなどプラットフォームごとに異なるイベント仕様をUI側が理解する必要があり、拡張性が低いUIとリアルタイム処理が密結合で、クライアントアプリの責務が肥大化し続けていたこと 特に WebSocket は一度接続すると常に接続が維持され続けるため、接続数に応じてメモリ使用量が増えやすくなります。今後 Twitch に加えて他プラットフォームのストリーミング機能を追加していくことを考えると、Alive Studio 本体がすべてのストリーミング処理を抱え続ける構成では、負荷や複雑さが急激に増していくことが想定されました。 また、ストリーミング機能を利用していないユーザーに対しても、同じアプリケーション基盤の負荷増大という形で影響が及ぶ可能性がある点も課題でした。 これらの課題を解決するため、Twitch のストリーミング処理を Alive Studio から切り離し、専用のサーバー（以下：streaming-proxy ）に分離する設計を採用しました。 Alive Studio UIの表示とユーザー体験に専念 streaming-proxy Twitch との WebSocket 接続コメントなどのリアルタイムイベント処理接続管理・再接続制御 この責務分離により、Alive Studio 本体はシンプルでデプロイしやすい構成を保ちつつ、リアルタイム処理に最適化されたアーキテクチャを目指しました。 アーキテクチャ streaming-proxy では、既存インフラからのレイテンシを極力抑えながら運用コストを低減できるというメリットから Fly.io を実行基盤とし、Twitch API へのレートリミット対策やキャッシュにはFly.ioのアドオンとして利用できる Upstash Redis を採用しました。 また、WebSocket / SSE を含むリアルタイム処理を短期間で実装するため、ランタイムとしてだけでなくパッケージ管理やテスト周りも含めて Bun を採用し、フレームワークとしてシンプルで軽量な API サーバーを構築できる Hono を採用しました。（bun/honoの構成に関しては開発体験が良く、設計面・実装面ともに多くの学びがあったため、これらについては何かの形で改めてアウトプットしたいと思います。） 認証・認可については既存の基盤を活用し、これまで使用していた認証基盤である Alive Auth を認証サーバーとして、また Alive Studio を「そのユーザーはコメントを取得できるか」「そのユーザーはサブスクリプション状態を満たしているか」といった利用可否を判定する認可サーバーとして振る舞わせることで、streaming-proxy 自身は接続管理に専念できる疎結合な構成としています。 streaming-proxy では、クライアントとサーバー、サーバーと Twitch で通信の役割が異なるため、SSE（Server-Sent Events）と WebSocket を使い分ける設計を採用しました。 クライアント（OBS Browser）からサーバーへの送信は不要であり一方向通信で十分なこと、HTTP ベースでプロキシやロードバランサーとの相性が良いことから、クライアント側には SSE を採用しています。 一方、streaming-proxy と Twitch 間では、Polling と比較してリアルタイム性やAPI リクエスト数を大幅に削減してレートリミットを緩和できること、将来的に購読イベントが増えた場合でも安定してスケールできる点に優れている点を重視し、Twitch の EventSub WebSocket を使用しています。 ステートフルな接続をどう扱うか リアルタイム通信を扱う上で、最も注意が必要なのが ステートフルな接続の扱いです。WebSocket や SSE は一度確立するとサーバー側に状態を持つため、切断や再接続が正しく扱われないと、意図しない接続が残り続けてしまいます。 そこでstreaming-proxy では、 「クライアントに streaming-proxy の存在を意識させず、SSE 接続の状態に応じて、サーバー側の WebSocket 接続をあるべき状態に保てること」を意識しました。 また、一定時間 WebSocket を保持し続けるといった時間ベースの制御ではなく、接続・切断といったイベントを起点に状態を遷移させる設計とすることで、実際の利用状況と乖離しないシンプルな接続管理を実現しています。 接続管理の基本ルール streaming-proxy では、以下のルールで接続を管理しています。 streaming-proxy は、ユーザーごとの SSE 接続数を把握する同じユーザーのSSE 接続が1本以上存在する場合のみ、Twitch との WebSocket 接続を維持し、新しく接続を確立しない同じユーザーのSSE 接続がすべて切断された場合、Twitch との WebSocket 接続も切断する このルールにより、不要な WebSocket 接続が残り続けることを防ぎます。また、WebSocket の接続状態はサーバープロセスのメモリ上に保持されるセッション状態に依存しており、プロセスが停止・再起動・揮発したタイミングでその状態も同時に失われるという性質も利用しています。 クライアント側で起きること クライアント（OBS Browser）では、ユーザーが以下のような操作を行うことを想定します。 タブを閉じるリロードをする明示的に切断ボタンを押すネットワークが一時的に切断される これらにより SSE 接続が切断された場合、streaming-proxy 側では SSE 接続数を減算します。 // SSE 切断時のクリーンアップ return streamSSE(c, async (stream) => { const result = await createUserConnection(userId, sseWriter, /* ... */); // ... } finally { await removeSSEConnection(userId, sseWriter); } }); // SSE がなくなったら WebSocket も切断 export async function removeSSEConnection(userId: string, stream: SSEStreamWriter) { const connection = userConnections.get(userId); connection.sseConnections.delete(stream); if (connection.sseConnections.size === 0) { await disconnectUserConnection(userId); } } その結果、そのユーザーに紐づく SSE 接続がすべて 0 本になった時点で、Twitch との WebSocket 接続も切断されます。この仕組みにより、ユーザーが複数のタブを開いて同時に接続した場合でも、Twitch との WebSocket 接続はユーザーごとに常に 1 本だけ維持されます。各タブは独立した SSE 接続として扱われますが、それらはすべて同一の WebSocket 接続から配信されるイベントを受け取るため、無駄な接続の増加やリソースの浪費を防ぐことができます。 また、クライアント側では localStorage を用いて「接続中であったかどうか」を永続化しており、ページの再読み込みや一時的な切断が発生した場合でも、自身の状態に応じて再接続を試みることができます。 サーバー側で起きること サーバー側でも、意図せず接続が切断されるケースがあります。 デプロイによる再起動ネットワークエラーによる瞬断冗長構成におけるマシンの切り替え これらの場合、SSE 接続はサーバー側の再起動などによって終了し、クライアント側では接続切断として検知されます（内部的には abort として扱われます）。 // クライアントは切断イベントを検知し、自身の状態に応じて再接続を判断 export async function disconnectUserConnection(userId: string) { const connection = userConnections.get(userId); await disconnectEventSubWebSocket(connection.websocket, connection.accessToken); userConnections.delete(userId); } このとき streaming-proxy は、クライアントからの新たな接続がない限り WebSocket 接続を再確立しません。 再接続するかどうかの判断はあくまでクライアントに委ねられており、サーバー側が「とりあえず WebSocket を張り直す」といった振る舞いをしないことが単純ながらも重要なポイントです。 Twitch 側で起きること Twitch との WebSocket 接続も、さまざまな理由で切断される可能性があります。 レートリミットによるエラーユーザーが Twitch 側で連携を解除したTwitch 側のサーバーエラーやネットワーク障害 この場合、streaming-proxy は Twitch との WebSocket を切断すると同時に、クライアントとの SSE 接続も終了させます。その際、どこで・どのようなエラーが発生したのかを示す情報を SSE 経由でクライアントに返します。クライアントから見ると、問題がサーバー側で起きたのか、Twitch 側で起きたのかは分からないためです。 export type DisconnectReason = | { type: "normal" } | { type: "keepalive_timeout" } | { type: "network_error" } | { type: "revoked"; status: string }; const websocket = await connectEventSubWebSocket({ // ... onClose: (reason) => { // Twitch側の切断理由をクライアントに通知 broadcastDisconnect(userId, reason); disconnectUserConnection(userId); }, }); function broadcastDisconnect(userId: string, reason: DisconnectReason) { const connection = userConnections.get(userId); const data = JSON.stringify({ type: "disconnected", reason }); 　　// ... } 再接続を行うかどうかの最終判断は、ここでもクライアントが担います。 以上の設計により、streaming-proxy では SSE 接続の状態を唯一の起点として WebSocket 接続を制御する、イベント駆動な接続管理を実現しています。 クライアント・サーバー・Twitch のいずれかで切断やエラーが発生した場合でも、一度すべての接続状態をフラットに解消したうえ、再接続するかどうかの判断をクライアントに委ねることで、常に実際の利用状況と整合した状態を保つことができます。 まとめ 今回は、Alive Studio における Twitch コメントのリアルタイム表示機能を例に、ストリーミング処理を専用サーバーに分離し、ステートフルな接続をイベント駆動で管理する設計について紹介しました。今後、他の配信プラットフォームやストリーミング機能を拡張していく中でも、この考え方をベースに設計していきたいと思います。

こんにちは、 GMO インターネット株式会社 宮崎オフィスで Web デザイナーをしているモリンガです。私たち宮崎オフィスのクリエイティブチームでは、デザイナー、エンジニア、映像クリエイターなどが更新する「宮崎クリエイターズブログ」という技術ブログを運用しています。このブログは私が2022年にデザインをリニューアルし、その後も継続的に改善を続けてきました。今回は、そんなブログのデザインリニューアルから運用改善まで、実際に取り組んだ施策とその成果をご紹介します。 ブログリニューアルの背景 宮崎オフィスのクリエイティブチームでは、異業種から職業訓練校などを経てクリエイターに転職した方が過半数を占めます。（かくいう私もその1人！） そのため、ブログや勉強会を通じて自学自習やアウトプットの文化を大切にしてきました。特にブログは私たちにとって、日々の業務で得た学びを発信する場として欠かせないものです。 そんなブログが私の入社時に、100記事を突破しようとしていました。 そこで、記事が増えても読みやすくするためにデザインリニューアルのプロジェクトがスタート。当時 Web デザイナーになりたての私が、デザイン改修に携わることになりました。 デザインリニューアルのポイント 「見やすさとファンづくりを考慮したデザイン改修」のためにまず、ブログを象徴するコンセプトを決めることから始めました。 GMO インターネット株式会社は「インターネットの海でお客さまが笑顔になるサービスや情報を運ぶ仕事」をしています。そんな中で、宮崎クリエイティブチームのメンバーが協力して業務に取り組む姿勢や、それぞれが得意分野を活かしている様子を例えるなら「船乗り/クルー」がぴったりだと考えました。 そのため、船乗りたちが学びを届けるこのブログを「チームの拠点である船」と位置づけ、そのままコンセプトとしました。ヘッダーにセーラー服の襟をデフォルメするなど、デザイン全体に「海」や「船」に関わるモチーフを取り入れています。 コンセプトが決まってからは、それを詰め込んだブログのロゴを制作しました。ロゴは波から太陽が昇る様子が「宮崎クリエイティブ」の頭文字になっています。他にも海に関連するモチーフを詰め込みました。 新たに実装した機能 細かいデザインについてはこちらの記事にて詳しくご紹介していますので、今回は「新しい試み」をご紹介します！ ダークモード デザインの叩き台をチームに確認してもらった際に、「ダークモード機能を搭載して、海を深海にしたらおもしろそう」というアイデアをいただき、すぐに取り入れさせていただきました！（このチームのそういうところが大好きです！） ダークモードのデザインでは単純に背景を黒にしていたのですが、「目が疲れる」という指摘を受けたため、テキストエディタを参考に調整を繰り返しました。 SNS 的視点 リニューアル目的の一つである「ファンづくり」を叶えるため、今回のリニューアルでは SNS 的な視点を取り入れています。「執筆者一人ひとりがインフルエンサーだ！」という発想です。 まず、個性豊かな執筆者のファンを増やしたいという目的から、アイコンを各所に表示。メニューや記事一覧など、できるだけ執筆者の顔が見えるデザインにしました。 また「わざわざ一覧ページを切り替えてまで古い記事を読む人は少ないのでは」という仮説を立て、エンジニアさんにお願いして無限スクロールやキーワード検索窓を取り入れました。 運用改善の取り組み デザインリニューアルを終えてからは、正式にブログの管理運用を任せていただくようになりました。それからは少しずつ継続的な改善と運用の仕組み化に取り組んできました。 スケジュール管理 元々は各自、自由なタイミングで投稿していましたが、これだと記事の投稿タイミングにばらつきが出てしまい、更新頻度も保てません。 そこで現在では、メンバー全員の執筆頻度や希望を考慮しながら、AI を活用してスケジュール表を生成しました。またこまめな声掛けを徹底することで、着実に記事が積み上がるようになりました。 社内周知 ブログの継続年数が増え、特に執筆年数の長いメンバーはモチベーションの維持が課題でした。 そこで現状を振り返ったところ、「他部署に新しく入った方はこのブログの存在を知る機会が少ない」ことや「ブログの再訪問きっかけの少なさ」から、社内認知度が低いのではという仮説が立ちました。 私ができることは何か考え、社内チャットで毎週金曜日に周知ポストを開始することにしました。ポストごとに「○○特集」という形で記事のテーマを設け、現在も投稿を続けています。文字だけでは読んでもらえないと思い、バナー付きポストにしてみました。（詳細はこちら） これにより、社内認知度の向上だけでなく過去記事を読んでもらうきっかけも作れたのではないかと思います。 また、インターンシップや説明会など、社内外を問わずブログを宣伝し続けたこともあり、少しずつ認知度が広がっていくのを感じました。（本当に隙あらば宣伝してました…） 成果とまとめ こうした取り組みを続けた結果、ブログを取り巻く環境は少しずつ変化しました…！ まずなんと言っても、デザイン改修前（2022年頃/ PV 平均月3,000）と比べて、月間 PV 数が約2倍に成長したことは大きな成果でした！ また、採用イベントへ参加した際に、参加者の方から「ブログ読みました！」と言っていただける機会が明らかに増加。社内外を問わず、ブログを通じて「チームの雰囲気」や「働き方」を知ってもらえる機会が増えたことは、チームにとってかなりプラスの効果でした。 そして今までの「ブログに対する取り組み」を評価いただき、GMO アワードにノミネートしていただけました！ GMO アワードは、 GMO インターネットグループで最も活躍した仲間たちをたたえる「グループ最大級のセレモニー」です。各部門ごとに活躍した方をノミネートし、最終的には社員の投票で各部門のNo.1を決めるというものです。 残念ながら受賞はできませんでしたが、これまでの活動を評価いただき、コンテンツが育つ過程を経験できたことは1クリエイターとして励みになりました…！ もちろんブログはまだまだ発展途上です。今後も改善を続け、より多くの情報を発信していきたいと思います！ 社内ブログやオウンドメディアの運用でお悩みの方にとって、この記事が少しでも参考になれば幸いです。

今年もGMO kitaQでサマーインターンを開催しました。全4コースのうち、今回は「インフラコース」と「Webアプリケーション開発コース」のレポートを紹介します。後編では「セキュリティコース」と「AIコース」を取り上げます。 GMOインターネット・サマーインターン2025 開催概要（全コース共通） 期間：2025年7月28日～9月5日で、各コース5日間形式：オフライン(業務を疑似体験できる短期集中型)参加学生：全コース合計40名　※会場キャパの関係上、参加学生を限定 インフラコース ねらい（ゴール） インフラエンジニアの業務内容への理解を深め、自身の適性領域（設計・構築・運用など）を見極める。 概要 参加学生：9名（4グループ編成）内容：実際に当社でも利用している Kubernetes クラスタ環境を、物理～仮想レイヤまで構築し、運用まで一貫して体験。体験により、当社における多様なインフラエンジニア職の役割や業務内容を理解できる構成とした。 5日間の進行 Day1 [開発] 物理サーバ構築[座学] アーキテクチャ職、データセンター業務紹介[1on1] 個別面談（Day4まで継続） クラウドネイティブ世代が多いことを踏まえ、あえて物理サーバの組み立てから実施。ハードウェアの仕組みや役割を理解したうえで、インフラの基盤を体感してもらった。当社は IaaS を展開しており、ハードウェア理解は必須のスキルであることを学習した。座学では、サーバやネットワーク機器を収容するデータセンターの業務や、主要サービスのアーキテクチャ構成について紹介。当社パートナー（多様なインフラ職種・役職）が15〜30分の1on1を実施。進捗確認に加え、就職活動やキャリア相談にも対応し、技術課題の整理から翌日の行動設定まで伴走。日常的に相談できる1on1環境を整備した。 Day2 ［開発］ OS／仮想化環境構築（Ubuntu／KVM）、Kubernetes 構築開始［座学］ NWエンジニア職、GPUクラウドサービス紹介 Ubuntu のインストールおよび初期設定を行い、KVM 上で仮想マシンを構築。Kubernetes の概要を学習した後、Kubespray（Ansible ベース）を用いて仮想マシン上に Kubernetes クラスタ環境を構築。Day4 にかけて冗長化とアプリケーションの自動割り当てまでを体験。進行は学生主導とし、チューターが各テーブルを巡回して適宜支援を実施。座学では、今回は実機体験できなかったネットワーク業務の紹介に加え、GPUクラウドのサービス概要を解説。 Day3 ［開発］ Kubernetes 構築の続き［座学］ セールスマーケティング紹介［座談会］ 新卒パートナーとのキャリアQ&A セールスマーケティング担当より、法人営業で抽出した顧客課題を開発要件へ正確に翻訳する「橋渡し」の重要性を解説。要件定義や優先度調整を通じて、売上・提供価値の最大化を図る取り組みを共有した。新卒入社のパートナー3名が登壇し、入社のきっかけやキャリア形成の実例を紹介。学生からの質問にもフラットに応じ、キャリア選択の参考となる対話の場とした。 Day4 [開発] Kubernetes構築続き[運用] SRE業務紹介と体験 当社における SRE の定義と活動内容を紹介したのち、指定アプリを Kubernetes 環境にデプロイ。Grafana を用いて SLO／エラーバジェットを設定し、システムの安定性・品質を数値で評価した。 Day5 ［運用］ お客様問い合わせ対応の演習（トラブルシュート）［発表］ 個人ごとの成果発表 環境をConoHa WINGに切り替え、あらかじめ用意したログをもとにお客様対応の模擬演習を実施。例：Webサイトが表示できない、メールが送信できないケースの原因調査 など最後に各自が成果発表を行い、定めたゴールとその達成度を振り返った。 アンケート結果と運営所感 指標結果（4.0満点）補足総合満足度4.0最高評価総合難易度3.6数字が高いほど難しい 学生の成果発表を通じて、当社における多様なインフラエンジニア職への理解が一段と深まり、各自がインフラエンジニアとしての将来像をより具体的に描けるようになったことを確認できた。背景として、実務でも用いる Kubernetes クラスタ構築を中心に据え、物理層の組み立てから仮想化、論理設計・デプロイ、運用までを一貫して体験できる構成としたことが挙げられる。また、様々なGMOパートナーと日次の1on1面談による支援が、疑問の早期解消と学びの言語化を促し、役割意識とキャリア像の明確化につながったと考えてる。 参加学生の声（原文ママ） 「実務での設計や技術選定に対する理解を深めるとともに、会社の社風や自分の目指すエンジニア像を具体化することを目標に参加しました。ハンズオンや座学を通して、各設計や技術選定の考え方をより深く理解することができました。また、各チームによる職務紹介を通じて会社の雰囲気を感じ取り、日々の面談では自身のキャリア像を明確にする機会となりました。ボリュームのある実践的なハンズオンも、メンターの方々のサポートにより新しい技術を着実に理解でき、他のインターン生や社員の方々との交流も非常に有意義でした。」 Webアプリケーション開発コース 概要 今回のインターンは 「ConoHaのコンパネ開発」 を実施しました。実際にConoHaを触ってもらい、その中で感じた課題や改善できそうな点を自ら要件化し、新たにコンパネを開発してもらうという内容です。公開されているConoHaのAPIを利用して開発を行うため、実際の業務に近い形で開発体験を行えるのがこのコースの特徴です。 詳細 今年のコースでは、AIツールやAIエージェントを活用した開発スタイル が大きな特徴となりました。要件定義の段階からAIを利用し、課題整理や仕様策定、UI構成のアイデア出しを効率的に進めていました。さらに、開発フェーズでは GitHub Copilot、Gemini CLI、Cursor など、さまざまなAIツールを取り入れ、スピーディーに実装を進めていました。一方で、バックエンドAPIとの接続部分では苦戦する場面もあり、ときには弊社メンターがサポートに入りながら課題を一緒に解決していく姿も見られました。AIの活用によって生まれた新たな余白時間を、デザインのブラッシュアップやUX改善など“付加価値創出”に活かすなど、技術力と創造性の両面で挑戦する姿勢 が際立ったのが今年の印象です。 最終日には、各チームが開発したアプリケーションの成果発表とデモを実施しました。限られた期間の中でしっかりと要件を満たし、完成度の高いWebアプリケーションを披露してくれました。課題設定やUI/UXの工夫など、それぞれのチームで異なるアプローチが見られ、どの発表も非常に見応えのある内容でした。懇親会では「既存アプリの改修案を考えるのが難しかった」「サーバーに関する知識や新しい技術を習得する良い機会になった」といった意見も出ていました。また、「メンターのサポートが手厚かった」「就活や今後のキャリアの相談にも親切に乗ってくださった」といった声もあり、AIを活用しながらも、人の温かさやチームで協働することの大切さを実感する5日間 となりました。 レポート後編はこちら

この記事は GMOインターネットグループ Advent Calendar 2025 21日目の記事です。Claude Code を使い始めてから、「これ、夜寝ている間も動かせたら最強では？」と思い、半分ネタ・半分本気で「寝ながら開発」を試してみました。今回はMac + Claude Code + ちょっとした自動化についてで、寝ている間に開発を進めるために工夫したことをまとめます。⚠️ 先に書いておきますが、この方法は実験的です。安全対策は必ずしてください。 やりたいこと Claude Code に長時間タスクを任せたいYes/Enter を要求される処理で止まらせたくないタスクが終わったら次のタスクに自動で進ませたい寝ている間に Mac がスリープしないようにしたい ① AppleScriptで「Enter（Yes）」を定期的に押す Claude Code を使っていると、以下のような場面で処理が止まることがあります。 コマンド実行時の確認Yes / Enter を求められる場面 そこで、AppleScript で定期的に Enter を押す仕組みを用意しました。 サンプル AppleScript -- 設定値 set repeat_count to 540 -- 実行回数 (例: 5秒ごとに540回) set wait_seconds to 5 -- 待ち時間 (秒) -- システムイベントへのアクセスを許可する tell application "System Events" repeat repeat_count times -- Enterキー (key code 36) を押す key code 36 -- 指定した秒数待機する delay wait_seconds end repeat end tell display dialog "自動入力が完了しました (90分経過)" buttons {"OK"} default button "OK" 5秒ごとに Enter を押し続けますClaude Code が「Yes?」「Continue?」と聞いてきても止まりません ⚠️ 注意 フォーカスしているアプリに Enter が送られます不要なアプリは必ず閉じておきましょう ② Macがスリープしないようにする 寝ている間に Mac がスリープすると、すべて止まります。 ターミナルで実行 caffeinate 実行している間、Mac はスリープしませんターミナルを閉じると解除されます 時間を指定したい場合： caffeinate -u -t 7200 ③ Linear × MCPで「次のタスク」に自動で進ませる 寝ながら開発を成立させるための一番重要な工夫がこれです。 やったこと Linear（TODO管理サービス）を使ってタスクを管理Linear MCP（Model Context Protocol）で Claude Code と接続タスクを 上から順に実行1タスク完了 → 次のタスクへ自動遷移 イメージ こんな感じで Claude Code に対して、「この Linear のタスクを上から順に処理して1つ終わったら次に進んでください」という指示を出しておくことで、人間が起きていなくても開発が進む状態を作ることができました。 ④ 安全のために必ずやっておくこと これは本当に大事です。 Claude Code は sandbox モードを使う sandbox モードで実行 https://code.claude.com/docs/en/sandboxingファイル破壊・想定外の操作を防ぐ(sandboxを解除することもあるらしいので、注意は必要です...) まずは個人の Mac で試す 業務用 PC ではやらない仕事のリポジトリではやらない 「壊れてもいい隔離環境」を用意する ダミーリポジトリ使い捨てブランチ重要データがないディレクトリ はじめは「破壊されても笑える環境」以外ではやらないのが大事です まとめ AppleScript で Enter を自動入力caffeinate で Mac のスリープ防止Linear MCP でタスクを順番に実行sandbox & 隔離環境で安全確保 今回の方法は Mac 限定ですが、お手軽に「夜寝ている間に開発を進める」体験ができます。もちろん万能ではありませんし、目が覚めたら壊れている可能性もあります。それでも、「AI に任せられるところは任せる」という感覚を掴むには、とても良い実験でした。

この記事は GMOインターネットグループ Advent Calendar 2025 20日目の記事です。こんにちは、暗号のおねえさんことGMOインターネットグループ エキスパートの酒見(さけみ）です。現在のミッションとして、安心・安全・便利なインターネットの世界を目指して、先端の暗号技術の研究開発支援や標準化活動支援に取り組んでいます。今回の記事では、その活動の中でも今年一番、事態が動いた！？IETFでのペアリング標準化活動の取り組みについてご紹介したいと思います！ はじめに ペアリング（pairing）は、BLS署名や属性ベース暗号（ABE）、IDベース暗号（IBE）などの暗号方式を成立させるための基盤技術です。そして IRTF/CFRG では、これらで利用される pairing-friendly curves（ペアリング向け曲線パラメータ） を、セキュリティレベルや採用状況と合わせて整理し、推奨を提示するための文書(internet-draft、イメージとしてはRFCの赤ちゃん) をRFC化すべきアイテムのひとつとして取り扱っています。 この活動は、他のCFRGメンバーと文書の方向性のコンセンサスがなかなかとれず、2020年ごろから長らく停滞をしておりました。。。しかし、ペアリング曲線のRFCは必要であり、再開をリクエストいただく声を多数をいただきまして、この度、2025年11月にカナダ、モントリオールで開催されたIETF124の会合にて、再始動することを発表しました。 本記事では、そのinternet-draftの活動紹介にあたり、(1)ペアリングの要点、(2)ペアリングで“実用上”何が変わるか、(3)代表的な具体例、(4)なぜ曲線の標準化が重要か、(5)MLでの議論の現在地を、事実ベースで整理していきます。 IETF / IRTF / CFRGとは？ IETF：インターネット技術の標準化（RFCを中心に策定）IRTF：研究寄りの活動（研究成果の文書化など）CFRG（Crypto Forum Research Group）：IRTF配下で暗号を扱う研究グループ CFRG（Crypto Forum Research Group）とは 仕様そのものだけでなく、実装・相互運用・安全性評価・パラメータ選定といった「現場で事故りやすい論点」が集まりやすい場です。たとえば Hashing to Elliptic Curves（RFC 9380）はCFRG成果物としてDatatracker上でも明記されています。 ペアリング暗号とは？ ペアリング暗号は、通常の公開鍵暗号（RSA/ECDSA/ECDHなど）だけで同じ目的を達成しようとすると、そもそも達成できない/設計が複雑になりやすい／サイズや計算量が大きくなりやすい機能を、比較的シンプルに実現しやすくする暗号技術です。ポイントは、暗号の部品として「特別な写像（ペアリング）」を使えることで、プロトコル設計上の自由度が増える点にあります。(ここでは、数式などを用いた詳細説明は省略しております) その結果、ペアリングを用いると次のような性質を“実用的に”狙えるようになります。 多数を1つにまとめる（集約・圧縮） 多数の署名や同意を、よりコンパクトな形で表現できる（例：BLS署名の集約）。 「誰が復号できるか」を“証明書”ではなく“ルール”で表現しやすい（ポリシー暗号） メールアドレス等の識別子を公開鍵として扱う（IBE）、属性（役職・所属など）を満たす人だけ復号できる（ABE）といった設計が取りやすい。 （位置づけ）証明系の効率化につながる土台 ゼロ知識証明などでペアリングを使う方式がある 以下では、この「何が嬉しいのか」を押さえた上で、代表的な具体例（BLS/IBE/ABE）に進みます。 ペアリングでなにが実現されるのか？（代表例） 1）BLS署名（集約できる署名） CFRGのBLS署名ドラフトは、BLSを「aggregation properties（集約性）を持つデジタル署名」と説明しています。複数署名をまとめた“集約署名”を作れること自体が、用途を押し広げます。実利用の例（仕様ベースで確認できるもの）として、EthereumのConsensus Specsでは「Validator public keysはBLS12-381曲線上の点である」ことが明記されています。また同Specs内で「BLS12-381署名（proof of possession）」が登場し、BLS署名が前提で議論されていることも確認できます。 2) IBE（IDベース暗号） IBEは「メールアドレスのような識別子」を公開鍵として扱う設計が可能になり、証明書配布前提の運用と異なる鍵配布モデルを組めます。事例として、Common CriteriaのSecurity Target文書内で、Voltage SecureMail Suiteが「受信者の IBE 公開鍵（＝グローバルに一意な email address）」を用いて鍵配送を行う、という記述が確認できます。 3) ABE（属性ベース暗号） ABEは「利用者の属性に応じたアクセス制御」を暗号レイヤで表現できることが特徴です。公開情報として、NTT DATAとUTS（シドニー工科大学）が、UTS Vaultにおいて「属性に応じたアクセス制御ができるABE技術を活用したソリューションの商用利用に合意」した旨をリリースで明記しています。 実際にどのようなビジネス領域で利用されているのか？ 分散システム／ブロックチェーン（合意形成・大量署名） BLS署名の集約性が設計上効く。EthereumのConsensus SpecsでBLS12-381前提が確認できます。 メール／エンタープライズ暗号化（鍵配布モデル） IBEを使った製品仕様が文書で確認できる（例：Voltage SecureMail SuiteのSecurity Target）。 機密データ共有／データガバナンス（属性で復号） ABEの商用利用合意が公式リリースで確認できる（例：NTT DATA × UTS Vault）。 なぜ“曲線”を標準化するのか？ いちばん影響が大きいのは「弱いパラメータを選んで本番に載せる」事故Pairing-Friendly Curvesドラフトの目的が、まさに「安全性レベル整理＋推奨の提示」ペアリング暗号自体の安全性評価が非常に複雑・困難 この3点です。以下に詳細を説明していきます。 いちばん影響が大きいのは「弱いパラメータを選んで本番に載せる」事故 暗号は後から差し替えが効きにくく、移行時に鍵・署名・互換性・データ再暗号化などが連鎖しがちです。そのため、 “曲線・パラメータ選定を個人の勘にしない”ことに価値があります。 Pairing-Friendly Curvesドラフトの目的が、まさに「安全性レベル整理＋推奨の提示」 ドラフトは、(a)国際標準・ライブラリ・アプリでの採用状況を整理し、(b) 128/192/256-bitのセキュリティレベルに分類し、(c)「security」「widely used」の観点から各レベルの曲線を選定する、と概要で述べています。実務的にはこれが「選定ミスを構造的に減らすための共通根拠」になります。 ペアリング暗号自体の安全性評価が非常に複雑・困難 現行の楕円曲線暗号やRSAは、楕円曲線上の離散対数問題や素因数分解問題の難しさが安全性の根拠となっています。一方、ペアリング暗号では、複数の数学的問題が絡み合って安全性が成り立っており、評価が難しいという背景があります。とくに、今回のinternet-draft執筆のきっかけとなったKimらの攻撃により、ペアリング暗号の安全性評価はさらに難しくなりました。そのため、安易にパラメータを選んでしまうと、システムの安全性を脅かしてしまうリスクがあります。 CFRGのMLで議論されている Pairing-friendly Curves の標準化動向 IETF 124のプレゼン後、CFRG ChairのNick Sullivanが「更新版を出す／interimを開く前に、合意しておきたい未決論点」をMLで列挙し、意見募集を開始しています。 文書のスコープと構成曲線の選定インタフェース／関連プリミティブシリアライズ（符号化）フレーミングと実用性 列挙された論点は、実装者が事故を避けるうえで“そのまま重要ポイント”です。 文書のスコープと構成 曲線パラメータ＋テストベクタ中心に寄せるか、インタフェース指針・シリアライズ形式・チュートリアル要素まで含めるか背景説明は付録／別文書へ分離するか（タイトルや位置づけも見直すか） 曲線の選定 「BLS12-381 + BLS24を1つ + BLS48を1つ（=128/192/256-bit狙い）へ絞る」案BN曲線を外す案や、BLS用途だけ対象にするか、ZKPやIBE等も対象にするか インタフェース／関連プリミティブ mapping to G1/G2、hash-to-curve参照など、期待する抽象化やインタフェースを文書で書くかRFC 9380など他仕様に委ねて中立にするか最小ペアリングAPI（関数シグネチャ／domain separationガイダンス）まで踏み込むか フレーミングと実用性 Kimらの攻撃であるexTNFSなどを踏まえた安全性前提、subgroup checkなど実装リスク、適用可能なプロトコルクラスを明示すべきかテストベクタに中間値や複数エンコーディング結果も含めるべきか CFRGでのNext Actionとしては、MLで意見を集めた後、GitHub issue化し、必要なら短いinterimを検討する、という流れが計画されています。 おわりに ペアリング暗号は「高度で難しい話」に見えますが、実装者視点では結局 “安全なパラメータ選定” が勝負です。CFRGの Pairing-Friendly Curves は、曲線の推奨セットを作ろうとしていて、まさに今「何を文書に含めるべきか」「何を推奨し、何を外すか」がMLで具体的に詰められています。 安全なインターネットの世界を目指して、引き続き、Pairing-Friendly Curvesの標準化に取り組んでいきたいと思いますので、応援いただけるとうれしいです！ おまけ 最後に、GMOコネクトでは研究開発や国際標準化に関する支援や技術検証をはじめ、幅広い支援を行っておりますので、何かありましたらお気軽にお問合せください。 お問合せ: https://gmo-connect.jp/contactus/ 以上です。

この記事は GMOインターネットグループ Advent Calendar 2025 19日目の記事です。こんにちは！GMOペパボの事業開発部 即レスAIチームでディレクターをやっている中村侑聖と申します。普段は、GMO即レスAIで扱っているAIツールの設計・納品までを主に担当している私ですが、今回は「DifyとGASを使って、システム開発を行う」という、いつもとは違う挑戦をしました。 1. はじめに みなさん、AIを使ってなにか開発をしたことはありますか？ 実は、Dify（オープンソースのLLMアプリ開発プラットフォーム）とGoogle Apps Script（GAS）を組み合わせることで、エンジニアでなくても実用的なAIシステムを構築できます。 本記事では、DifyとGoogle Apps Script（GAS）を組み合わせ、AIコーディングアシスタントを活用しながら非エンジニアでも実用的なAIシステムを構築できることを、実際に構築したGmail自動返信システムの事例を通じてご紹介します。 2. なぜDify × GASなのか？ そもそもDify（ディフィー）とは何か？ Dify（ディフィー）は、生成AIアプリケーションを作成・運用するためのオープンソース・プラットフォームです。 高度なプログラミング知識がなくても、ブロックを組み合わせるような感覚で、自社専用のAIワークフローを構築可能です。 参照：https://docs.dify.ai/ja/use-dify/getting-started/introduction DifyとGASを組み合わせるメリット 「高度なAI」を「いつものGoogleツール」に、面倒な環境構築なしで直結できる点が最大のメリットです。 GmailやスプレッドシートとDifyを連携させることで、社内データを参照したAIアシスタントを業務フローへ組み込むことが可能になっています。 ＜Difyの魅力＞ 完全ノーコード/ローコード : エンジニアでなくともGUI上で複雑なワークフローが組める。モデルの自由度 : OpenAIやAnthropicなど、最新のLLMを柔軟に切り替えられるRAG対応 : 独自データ（マニュアル等）を参照させて独自の回答を生成できる。API連携：作成したワークフローをAPIを使って外部から呼び出す事が可能。 ＜GAS (Google Apps Script)の魅力＞ 環境構築不要:Google Workspaceを使っていれば、追加コストゼロですぐに動かせる。連携力: Gmailやカレンダーとの連携がスムーズで、業務フローに溶け込ませやすい。トリガー機能: 時間ベースやイベントベースの自動実行が簡単に設定できる。 3. 事例紹介：Gmail自動返信システム 想定される利用シーン 多くの企業で、お問い合わせメールへの対応に工数がかかっています。特に以下のような課題を抱えているケースが多いです。 課題1：メールの種類判定と条件分岐 Gmail自動返信システムを構築する際、単純に受信したメールすべてに返信するのではなく、メールの種類や状態を適切に判定する必要があります。 例えば、以下のような判定が必要になります。 1. 転送メールの検出 転送メールには、転送元のメール内容も含まれているため、AIで解析しようとすると二重で返信してしまう可能性があります。そのため、メールヘッダー（ReferencesやIn-Reply-To）を解析することで判定を行いました。 2.新規メールの判定 ユーザーから来たメールが「新規のお問い合わせメール」かどうかを分析し、適切な処理フローに振り分けます。お問い合わせ以外のメールも受信するため、それぞれのメールに相応しい処理を施すためにGASもしくはAIで仕分ける必要があります。 このような判定ロジックを実装することで、AIが不適切なタイミングで返信することを防ぎ、システムの堅牢性を確保できると考えています。 課題2：営業時間の判定と保留機能 AIなら「24時間即レス」することも可能ですが、実際の業務では「深夜や休日の自動返信は避けたい」というケースも少なくありません。 そのため、GAS側で日時を判定し、「営業時間内のみDifyを動かす」といった柔軟な制御を組み込んでおくと、より実務に即した安全な運用が可能になります。 システムに組み込むために以下のような実装を考えました。 営業時間内の判定：GASのDateオブジェクトを使って、現在時刻が営業時間内かどうかを判定。 営業時間内なら⇨即座にDify APIを呼び出して返信文を生成・送信。 営業時間外なら⇨Gmailのラベル機能を使って「保留」ステータスにし、翌営業日の開始時刻にトリガーを発火させて一括処理。 4. システム構成と設計のポイント この課題に対し、以下のようなロジックをGASとDifyで組み上げました。 システム構成図（概念） この流れをGASで制御し、AI生成部分をDifyに任せることで、シンプルかつ拡張性の高いシステムを構築しました。 こだわった3つの処理フロー システムを以下の3つの処理に分解して実装しました。 転送メール処理 ：メールヘッダー（References）を解析し、転送メールであればAI対応させず、人間に通知するための「有人対応ラベル」を付与して終了。誤爆を防ぎます。新規メール処理：真正面から来た新規のお問い合わせかどうかを検証。「今、営業時間内か？」を判定し、OKならDify APIを叩いて返信文を生成・送信します。遅延・保留メール処理：営業時間外に来たメールはいったんラベル機能を使って「保留」ステータスにします。営業開始時間（トリガー発火）になったら、保留分をまとめて処理・送信します。 5. 実装のポイント Dify APIとの連携 GASからDify APIを呼び出す際は、以下のようなポイントがあります。 APIキーの管理 : PropertiesServiceを使って安全に管理エラーハンドリング : タイムアウトやAPI制限を考慮した実装レスポンスの処理 : JSON形式のレスポンスを適切にパース GASでのメール処理 Gmail APIを使ったメール処理では、以下の点に注意が必要です。 メール取得 : ラベルや検索条件を活用して効率的に取得メール送信 : 適切な送信者情報と返信先の設定ラベル管理 : 処理済みメールの管理と追跡 6. 開発プロセス ディレクターである私は、こうしたシステムを構築するにあたり、AIコーディングアシスタントを「優秀なペアプログラミングの相手」として活用しました。おかげで、要件定義と処理フローの構築を検討しながら、それをコードに落とし込む作業は、AIツールと対話しながら、効率的に会話を進めることができました。 実際の開発は、要件定義のスキルと、AIツールの実装力を組み合わせ、以下のようなステップで進めていきました。 STEP 1：要件定義と設計 まずは「何を解決したいか」「どんな条件分岐が必要か」を明確に言語化します。この段階では、「Difyでできること」「GASでやるべきこと」の切り分けを意識して要件を固めます。 今回はDifyはAIワークフローの構築に特化しているため、メール内容の解析や返信文の生成はDifyに任せ、メールの取得・送信・ラベル管理などのGmail操作はGASで実装する、といった役割分担を明確にしました。 STEP 2：AIコーディングアシスタントとのペアプログラミングで実装 要件をもとに、AIコーディングアシスタント（Cursor）を使って機能を一つずつ実装していきます。いきなり全体を作ろうとせず、「まずはメールを取得する部分だけ」「次はDifyに投げる部分だけ」とパーツごとに作成し、段階的に進めていきました。 STEP 3：AIによるセルフコードレビュー 書いたコードが正しいかどうか、非エンジニアの方には判断が難しい場面があります。そこで、AIコーディングアシスタントに対して「このコードでバグが起きそうな箇所はある？」「もっと効率的な書き方はある？」と問いかけ、コードレビュー自体もAIを活用しながら品質の向上に注力しました。 STEP 4：フィードバックループによる改善 プロトタイプができた段階で実際に動作を確認し、フィードバックをもとに改善を繰り返します。「このパターンの転送メールが漏れている」などの細かな挙動の修正も、AIコーディングアシスタントがあれば即座にコードへ反映できるため、アジャイルに近いスピード感で改善を繰り返すことができます。 7. 開発後の学び AIをパートナーにコードを書き進める中で、自分自身が「どんなシステムを構築したいのか」を強く意識することの大切さに気づかされました。 もちろん、生成されたコードの品質や整合性を自分だけで判断するのは難しいため、そこはプロのエンジニアにレビューを依頼し、二人三脚で進行しました。 このプロセスを経て、コードを書く他に、ビジネス要件をシステムに落とし込む「設計力」や「全体構想力」も、開発に求められるスキルも重要だと実感しました。 そのため、今回の開発で得た経験を活かし、これからも「誰かのために役立つ」価値あるシステム開発に挑戦し続けていきたいと思います。 8. おわりに 今回紹介したGmail自動返信システムは、DifyとGASの組み合わせで実現できる事例の一つです。この組み合わせを使えば、他にも以下のようなシステムを構築できると考えています。 カレンダー予約の自動返信スプレッドシートのデータ分析とレポート生成 AIツールの進化により、非エンジニアでも実用的なシステムを構築できる時代になりました。DifyとGASの組み合わせは、その一つの選択肢として、ぜひ検討してみてください。 この記事が、同じようにAI活用や業務効率化に挑戦しようとしている方の参考になれば幸いです。

GMOインターネットグループは、2025年12月4日にザ・プリンス パークタワー東京にて開催された「INCYBER Forum Japan」に特別協賛として出展しました。「サイバーレジリエンスが築く、安心できる未来社会」をテーマに掲げた本イベントでは、サイバー領域の安全保障やウクライナ戦争から得られた教訓など、最前線で培われた知見が共有されました。このレポートでは、会場で行われたGMOインターネットグループからの講演についてお届けします。 「サイバー安全保障×AIの未来論 - マルチドメイン戦におけるサイバーとAIの役割」 「サイバー安全保障×AIの未来論 - マルチドメイン戦におけるサイバーとAIの役割」と銘打たれた講演では、GMOサイバーセキュリティ byイエラエ株式会社で執行役員を務める奥野史一が登壇。奥野はサイバー・AI・防衛・安全保障分野におけるスペシャリストとして、NATOのサイバー防衛演習や自衛隊が主催するサイバー防衛演習支援などを行っています。 GMOサイバーセキュリティ byイエラエ株式会社　執行役員・奥野史一 奥野はまず、マルチドメイン戦を陸・海・空・宇宙・サイバー・電磁波・認知の7つの領域で捉え、「サイバーと電磁波は全てをつなぐ神経のようなもの。この神経が麻痺すれば、物理的な領域も機能しなくなる」と解説。各ドメインをつなぐサイバー空間が突破されると、そのほかの領域も被害を受ける点を指摘しました。さらにデジタル化の進展に伴い、防御対象となるシステムやIoT機器は無数に増加しています。防御対象が増えることで、攻撃者から狙われる脆弱性の数も比例して増えていく現状について、奥野は「もう人力では防御不可能な時代になっている。AIと自動化が必須だ」と警鐘を鳴らします。そしてこうした現状を打破するためには、自律的に活動設定・計画・実行・学習を行うAIエージェントに加え、RPAや複数のAI技術等を組み合わせて業務を自動化する「ハイパーオートメーション」が鍵になると語りました。これらを実現する手段として挙げられたのが、奥野が提唱する「Three-Zero」というロードマップです。 Three-Zeroは、攻撃されても社会や事業が止まらないレジリエンスの確保を意味する「ゼロ停止」、人の手を介さずAIエージェントによる自動防御を実現する「ゼロ対応」、物理と仮想が融合する未来の世界における平和的解決を目指す「ゼロ犠牲者」という3段階の「0」から成り立ちます。とくにゼロ対応は、DARPA主催のAI Cyber Challenge（AIxCC）で実証が進みました。2025年の決勝では、上位チームがチャレンジ課題として投入された脆弱性の約77％を検出し、約61％を自動修正、さらに未知の脆弱性であるゼロデイを18件も見つける成果を示しています。この結果に対し、奥野も「まさに『ゼロ対応』が夢物語ではなく、実装可能であることを証明する結果だ」と高く評価しています。 さらに、AIの進化はサイバー攻撃側・防御側の両方に大きな影響を与えます。「判断や行動の遅延が致命傷になるAI対AIの戦いになったとき、勝敗を分けるのは学習データではなく、リアルタイムな現場環境のデータ」だと説く奥野。さまざまな要因を勘案して瞬時に最適解を導くのは人間には不可能であるとして、リアルタイムに変化する環境に合わせて意思決定支援AIが瞬時に最適解を出し続ける「メタ（Most Efficient Tactic Available）更新」、さらにその最適解を即時にアクションすることが勝敗を分ける世界観を示しました。こうした環境下において、人間の役割はプレーヤーから「審判」へと変わっていきます。奥野は「危険性のある部分は人が関与しましょう」とAIの手綱を握る必要性を強調したうえで、AIガバナンスの観点から「人間の承認が必要なもの：Human-in-the-loop」「緊急停止ボタンを人間が持つもの：Human-on-the-loop」「AIに完全に任せるもの：Human-off-the-loop」という3段階アプローチの実践を提案しました。 講演の締めくくりとして、奥野は「究極のサイバーセキュリティとは、攻撃を待つのではなく、平和な世界を積極的に自ら構築していくことだ」と力強く語り、未来を能動的に創る姿勢の重要性を訴えました。 GMOグループでは、200名以上のホワイトハッカーによる「ペネトレーションテスト」「脆弱性診断」に加え、自社開発の「ASM（Attack Surface Management)」「GMOサイバー攻撃ネットde診断」やセキュリティ診断AIエージェントサービス「Takumi byGMO」など、「ゼロ対応」を実現するサイバーセキュリティサービスを展開しています。今後もGMOグループは企業や社会をあらゆるセキュリティリスクから守り、奥野の掲げる「Three-Zero」の実現に向けて取り組んでまいります。 「有事に備える：ウクライナのサイバー教訓と日本の対策」 続いて登壇したのは、GMOインターネットグループ株式会社 グループサイバー防衛事業推進本部「6」本部長であり、前陸上自衛隊教育訓練研究本部長・元陸将の経歴を持つ廣惠次郎。ウクライナへの訪問経験に基づき、軍事的視点からサイバー戦の実態と日本への教訓を語りました。2025年11月にGMOインターネットグループに参画した廣惠は、最初にグループサイバー防衛事業推進本部の由来を説明。「6はサイバー戦闘・IT関連を意味する番号。これは世界共通の数字であり、会社の配慮で名付けていただいた」と語り、会場の関心を集めました。さらに、2020年にウクライナ軍総参謀部を訪問した際にキーウで受け取った盾や、当時すでに戦時下にあったドンバス地方を視察した際に司令官から授与された盾などを披露。いずれも日本に1つしかない貴重なものであり、とくに初公開となるシンボリカ（紋章）つきのウクライナ国旗の紹介の際には、スマホやカメラを構える参加者の姿も多く見られました。 GMOインターネットグループ株式会社 グループサイバー防衛事業推進本部「6」 本部長・廣惠次郎 「実際に足を運び、命がけで得てきた知見をお伝えしたい」と、意気込みを語った廣惠の講演は、2014年7月にウクライナ・ドンバス地方のゼレノピリアでロシア軍が行った「世界最初のマルチドメイン作戦」の解説から始まりました。この作戦ではロシア軍が電磁波妨害でウクライナ軍の無線を使用不能にした後、やむなく携帯電話で連絡を取る兵士たちの通信を傍受。電磁波部隊が電話番号から個人を特定し、兵士の家族あてに「息子さんが亡くなりました」という偽情報部隊が作成した偽のメッセージを送信しました。「家族は驚いて息子に電話をかける。その結果近くの基地局のトラフィックが上がり、ウクライナ軍の位置が特定されて攻撃を受けた。サイト探知から約20分で2個小隊が全滅した」と語る廣惠。この作戦が陸・電磁波・サイバー・認知という4つの領域を横断していたことを指摘し、11年前にすでに高度なマルチドメイン作戦が実行されていた事実を明らかにしました。この戦いでウクライナ軍はサイバーや認知領域の重要性を教訓として得た一方、2022年のロシア軍侵攻以降は、2014年当時はほぼ話題に上がらなかったAIの活用が際立っています。そしてAIやドローンをはじめとするロボティクス領域で作戦を展開しようとする場合、「サイバー領域で負けるわけにはいかない。それだけサイバーが大事になってきた」（廣惠）のです。 ウクライナから学ぶべき教訓として、廣惠は「最後は地上部隊が勝敗ラインを決めるが、サイバー優位と電磁波優位は勝利の必須条件だ」と総括。地上部隊を支援する、従来の航空優勢・海上優勢という概念に加え、サイバーと電磁波領域の優位がなければ戦争が成り立たない時代になったと指摘しました。そして日本への提言として、廣惠はイスラエルのベエルシェバや米国サイバーコマンドを例に挙げ、ドクトリンやトレーニング、装備品や教育などの充実や実践に官民連携で取り組む拠点の構築を提案しました。 講演の最後には、東京だけでなく地方にも拠点を分散させる「集中と分散」の必要性を訴え、「ウクライナがサイバー戦で頑張れている理由の一つは、この分散にある。ぜひ皆様のご協力をいただきたい」と呼びかけました。DDos攻撃やランサムウェアの被害を受けたというニュースが増えた昨今ですが、GMOグループではこうした脅威に対抗すべく、グループサイバー防衛事業推進本部「6」をはじめとした組織全体で、サイバー空間の安全確保により一層注力してまいります。 さいごに サイバー安全保障の最前線で活躍する専門家たちの知見が惜しみなく共有された本イベント。AIとサイバーセキュリティの融合、ウクライナ戦争から得られた実践的な教訓、そして官民・国際連携の重要性が多角的に語られました。 GMOインターネットグループでは、グループサイバー防衛事業推進本部「6」の新設をはじめ、国家のサイバー防衛に貢献する体制を強化しています。今後も官民の連携を深め、安心できる未来社会の実現に向けて歩みを進めてまいります！