新着 の記事一覧

はじめに こんにちは！今年の4月に新卒入社したどすこいです。GMOペパボでフルスタックエンジニアとして日々学びながら開発しています！現在は、マルチプレイ用ゲームサーバーを簡単にセットアップできる「ロリポップ! for Gamers」を展開しています。 今回お話しするのは、社内のAI活用を進めるためにDify講習会を行ったお話しです！この講習会は全部で6つの部署と3拠点で開催しました。その結果、パートナーのLLMアプリケーション開発の解像度が高まったり、誰でも実用化できるLLMアプリケーションを自作できるようになりました。 本記事では、その行動の契機や内容、その後の効果や今後の展望について紹介します。社内のAI活用推進の際のヒントになったり、そもそもDifyってなんぞって人のサポートになれば幸いです！ Difyとは Difyは、直感的なインターフェースを通じてAIアプリケーションを簡単に開発できるオープンソースのプラットフォームです。GPT-4やClaude 3などの最新のAIモデルを統合し、RAG（Retrieval-Augmented Generation）エンジンを搭載することで、幅広い分野で高性能なAIアプリケーションの開発を可能にしています。弊社では自社のDifyワークスペースをホストして全パートナーで利用しています！ 個人的なポイントとして、以下の点が特に良いと思っています！ 感的でわかりやすいインターフェースであり、誰でも使いやすい。LLMマルチエージェントの作成が簡単で、複雑な命令に関しても複数LLMで処理する仕組みが簡単に実現できる。LLMのハイパーパラメータのチューニングやプロンプティングによる比較をしやすい。画像などを用いたマルチモーダルなアプリケーションの開発や、RAGを用いたアプリケーションの実装方法がわかりやすい。 Difyで開発できるLLMアプリケーションの例 LLMのモデル比較の画面とハイパーパラメータの設定画面 きっかけ お産合宿 GMOペパボでは毎年お産合宿というものが開かれています。(これは2023年の紹介記事です！)これは、事業部も職種も超えてチームを作り、2日間という限られた時間でアウトプットをする開発合宿です。自分のチームはこのイベントで、配信を盛り上げるコメントを生成するbot”わいわいAI”を開発しました。 このAI部分に関してLLMマルチエージェントを採用し、バラエティーに富んだコメントを生成できるようなLLMアーキテクチャを実装しました。この際に用いたのがDifyであり、この時に試しに触ってみたのがきっかけでした。 わいわいAIの動作例 バックオフィスの方とのランチ その後、新卒エンジニアとして色々な事業部の方とランチを一緒に行くというアクションがありました！その中で、バックオフィスの方とランチに行ったときに、上記のDifyについての紹介と普段の業務についてのお話をしました。この際に、AIアプリケーションによって自動化できそうな業務があったり、具体的にどういうことができるのかというのをイメージしたいという話がありました。そこで、まずはDifyを触ってもらって、できることやできそうなことの具体的なイメージを持っていただくとよさそうだと思いました！ その後、バックオフィス向けにしたDify講習会を他の事業部の方にも取り上げてもらったり、全社向けに紹介してもらうことで「うちの事業部でもやって欲しい！」「こういうのもやって欲しい！」という声をいただき、多くの事業部で実施することになりました！ Dify講習会の内容 この講習会は、エンジニアでなく、まったくDifyを触ったことない人でも、実用化できそうなLLMアプリケーションを作ることを目的に組み立てました。そのため、基礎から丁寧に説明し、実際に手を動かしてもらうハンズオン形式で実施しました！また、進捗具合がわかりやすい点や気軽に質問をしたり回答したりしやすい点から、可能な限りオフライン開催をするようにしました。 講習会の目標を、基礎の内容から実用化のレベルまで以下のように設定しました。 レベル1: 入力された日本語を英語に変換してくれるワークフロー レベル2: 入力された文書の画像を文字に変換してくれるワークフロー レベル3: 入力された画像から契約書の種類を読み取り、それぞれで別の処理をするワークフロー また、レベル3に関しては、実際の業務に近そうな内容にするため、アレンジしたりもしました。 最初の導入 最初はサインアップをしてアカウントを作成すること、アカウントにログインして簡単なアプリケーションを作ることから始めました。これは、社内で「なんかすごそうだけど、はじめ方がわからない」、「なんとなくはじめるのが難しそう」という声があったため、まずははじめるまでをスムーズにできるようにしました。 また、レベル1にあるような単純なLLMアプリケーションを作るという課題を取り組んでいただく中で、Difyの仕様に慣れてもらいました。今回はDifyの”ワークフロー”の作成をしたのですが、慣れるまで以下のような使い方を詳細に説明しました！ そもそもブロックをどのように出すのかどうやって入力を設定するのか入力した文字列をどのようにLLMに渡すのか終了ブロックとは何かLLMの設定ってどうするのか このような感じで、簡単な課題を通してDifyのチュートリアルを最初に行いました。 自動判別するLLMアプリケーション その後、画像を入力とするLLMアプリケーションの実装方法を紹介したのちに、実用できるLLMアプリケーションを構築することに取り組んでいただきました。具体的には、「入力された画像から契約書の種類を読み取り、それぞれで別の処理をするワークフロー」を開発してもらいました。 こちらに関しては、”質問分類器”というものを使ってもらって実装してもらうのですが、これまでの課題と異なってブロックが大きなアプリケーションになるので、まずは全体像の組み立てから行ってもらいました。 最終的な目標のアプリケーション例 アドバンスなコンテンツ 上記の入門的なワークショップの他にも、ディレクター向けのLLMアプリケーションをモブプログラミングのような形式の講習会も実施しました。そこではRAGを用いたアプリケーション開発を実施してもらいました。 RAG（Retrieval-Augmented Generation）は、外部の知識を検索して、大規模言語モデル（LLM）を補強するというアプローチです。具体的には、LLMだけに頼らず、外部データベースやドキュメントから関連情報を動的に取り出し、それを元に回答を生成します。これを用いることで、特定の情報からLLMが関連する情報を参照しつつ、回答生成するアプリケーションを作ることができます。 この時の講習会では、社内で貯められた知見をもとに、ディレクターのお仕事をサポートするAIアプリケーションを作成しました。このアプリケーションによって、AIがタスクの叩き台を作ったり、人間が作ったもののフィードバックや修正をAIが行うようにしました。 講習会の効果 業務で使うLLMアプリケーションを作れるようになった ディレクター職やCS職の普段の業務をサポートするLLMのアプリケーションを自分らで作ってくださいました！開発したアプリケーションを横展開していただくことで、チーム全体の業務時間削減に寄与しています。 例えば、CSの方が作ってくださったものの例では「インフォメーションを作ってくれるbot」があります。こちらは、 ヘルプのドキュメントをRAGで取得インフォメーションをLLMで作成LLMで誤字脱字チェック別媒体のインフォを作成する といったものです！エンジニアの手を介さずに、業務に携わっている方がLLMアプリケーションを開発することで、要件やユースケースが明確な状態でアプリケーションを作れるので、とても良いと思いました。 CSの方が作ってくださったアプリケーションの例 新たに「この業務が自動化ができるのではないか」という具体的な提案をいただけるようになった 講習会を受けたパートナーから「講習会で作成したようなLLMアプリケーションがつくれるなら、こういう業務も自動化できるんじゃないですか？」というような提案を受けるようになりました！実際に手を動かして作ってもらったことで、LLMアプリケーションの解像度が上がったという感想がありました。この高い解像度によって、日々の業務でAI化できるところが見つかってきたのではないかと考えています。 今後の展望 新たなプラットフォーム 今回はDifyの活用を推進しましたが、Difyだけでは、SlackやGoogle Workspaceとの連携が完璧じゃないことがあります(一部機能では簡単に連携できるものもあります！)。一方、n8sと連携して自律的なAIエージェントアプリケーションをつくっている事例を伺いました。2025年では、これらのプラットフォームとの連携に関しても推進していくことで、誰でも自律的なAIエージェントが作れるようにしたいと考えています。 複雑なアプリケーションの構築 LLMマルチエージェントモデルやRAG、写真などのマルチモーダル機能の紹介はしたのですが、これらを組み合わせたアプリケーションまでは講習会で説明できてないです。導入部分の講習会は実施したので、今後はもう少し複雑なアプリケーションの作成までをサポートし、業務にさらにマッチしている複雑なLLMアプリケーションを開発できるように資料を整えたいと考えています。 まとめ AIが目まぐるしく進歩していく中、AIで未来を創るNo.1企業グループとなるべく弊社では様々な活動を行っています。今回はその事例の一つを紹介しました。弊社で行なっている”AIやっていき”に関して興味のある方は、ぜひ一緒に働きましょう！

こんにちは、GMOインターネットグループの若林です！GMOインターネットグループは、11/14（木）15日（金）に実施された「CODE BLUE 2024」にTOPスポンサーとして協賛しました。イベント当日の様子に加え、出展ブースやスポンサーセッションについて、ご紹介いたします。 イベント概要 日時：2024年11月14日（木）〜15日（金）会場：ベルサール高田馬場（住友不動産新宿ガーデンタワーB2・1F）参加費用：有料・事前登録制開催形式：対面形式でのカンファレンス主催：CODE BLUE実行委員会公式HP：https://codeblue.jp/ CODE BLUE とは？ CODE BLUEは、世界トップクラスの情報セキュリティ専門家が集まり、最先端の技術や研究成果を共有する国際会議です。日本を含むアジア各国と欧米の著名な研究者が集い、国際的なセキュリティコミュニティの形成を目指しています。今回は第12回目の開催となり、基調講演としてARIA（英国高等研究発明庁）の「Safeguarded AI」プログラムのディレクターを務める研究科学者デビッド・A・ダリンプル氏を招へいするなど、大変盛り上がりを見せました。 ブース出展について GMOインターネットグループでは、ブースにて以下2つの企画を実施しました。 企画①「ガチャガチャを回して豪華景品をゲットしよう！」 ブースでは、豪華景品が当たるガチャガチャを実施しました！CODE BLUEは国際的なセキュリティカンファレンスであるため、多くの海外参加者の方々もブースに訪れていただきました。日本文化として人気の「ガチャガチャ」は海外勢から大変好評で、学生スタッフから海外の参加者に至るまで、幅広い層にご参加いただけました。 ガチャガチャのPOPも新しく制作しました！ ガチャガチャブース ガチャガチャの景品はハズレ無しで、基本賞としてGMOサイバーセキュリティbyイエラエのカルチャーを表したデザインのオリジナルステッカー、豪華景品としてSecurity SmartTrack Card (Airタグ)ほか5点を用意しました。 GMOイエラエ カルチャーステッカー 豪華景品もすべてSOLDしました！ ありがたいことに想定よりも多くの方にご参加いただき、2日間とも夕方にはすべての景品が完売となりました！ 今回のガチャガチャ企画では、CODE BLUE 2024に参加された皆さまにGMOのブースを訪れていただき、楽しみながら交流を深めることを目指していました。2日間でなんと350名の方々がガチャガチャに挑戦していただき、多くの方とコミュニケーションを取ることができました！ご参加いただいた皆様、本当にありがとうございました。 企画②「超簡単！スキミングのリスクをデモで体験！」 ブースでは、ガチャガチャに加えGMOサイバーセキュリティbyイエラエが開発したスキミングデモ体験コーナーを設置しました。この企画のために特別に制作された「スキミング体験用認証システム」を活用し、参加者は非接触ICカードリーダーを使ってカード情報の不正コピーを実際に体験しました。 スキミング体験用認証システム 体験された方には、オリジナルスキミング防止カードをお渡し！ 参加者にはノベルティとしてオリジナルのスキミング防止カードもプレゼントしました！そしてデモ体験の最後には、お渡ししたスキミング防止カードを非接触ICカードリーダーでスキャンし、カード情報の不正コピーがしっかり防げることを一緒に確認しました。CODE BLUEはセキュリティに関心がある方々が集まっているイベントだけあって、たくさんの方から「面白い！」とご好評をいただきました。 スキミングデモ体験ブースの様子 また、このデモ体験を通してセキュリティ対策の大切さや、日常での簡単な防御策についても一緒に学ぶことができ、参加者の皆様との交流を一層深めるきっかけとなりました。 スポンサーセッション スポンサーセッションとして、GMOサイバーセキュリティ byイエラエに所属するホワイトハッカー11名が登壇しました。 各分野のスペシャリストが集結し、最先端のサイバー犯罪とその対策について、質疑応答を含め語り合いました。 「GMOイエラエ全員集合！！進化するサイバー攻撃への対策最前線」 2024/11/15　16:00〜16:45 Track 2/OpenTalks（45分） 登壇内容については、以下の記事に詳細を記載しておりますので、ぜひご覧ください！「攻めと守りの融合」でサイバー犯罪に立ち向かう　ホワイトハッカー集団・GMOイエラエが語る、サイバーセキュリティの最前線 会場の様子 登壇者11人は非常に迫力がありました！ 会場には立ち見の方もいらっしゃるほど、たくさんのお客様にお集まりいただきました。今回の登壇を通じて、GMOサイバーセキュリティ byイエラエには、多岐にわたる分野のスペシャリストが在籍していることを強く印象付けられたのではないでしょうか。 AfterParty@CÉ LA VI CODE BLUE 2024の2日目終了後、お客様とセキュリティ関係者の皆様への感謝の意を込めて、渋谷のCÉ LA VI TOKYOでGMOサイバーセキュリティ byイエラエ主催のアフターパーティを開催しました。 このパーティには、CODE BLUE 2024に参加された皆様を含め、約400名近くの方々にご参加いただきました。セキュリティ関係者との交流を深めながら、皆様の心に残るような盛り上がりを見せるパーティーとなりました！ 最後に CODE BLUE 2024への協賛を通じて、参加者の皆様やスポンサー企業様を含め、多くの方々と貴重な交流を持つことができました！また、安心・安全なインターネット社会の実現を目指すGMOインターネットグループの取り組みやサービスを幅広い方々に知っていただく機会となり、多くの温かい反応をいただけたことを大変嬉しく思います。また来年お会いしましょう！

みなさんこんにちは、デベロッパーエキスパートの小島です。先日JPAAWG 7th GeneralMeetingに参加してきましたので、そこで得られた気づきについて少し語ってみたいと思います。 JPAAWGとは？ Japan Anti-Abuse Working Group (JPAAWG) は、 インターネットを中心とした電気通信環境の利用促進を目的とし、 それらの健全な発展を脅かす各種ネットワーク上の脅威に対抗するため、 Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG) と連携した活動を行う組織です。※JPAAWG公式サイト(https://www.jpaawg.org/)より引用 JPAAWG General Meetingとは？ 年に一回開催される会合です。オンライン・オフラインのハイブリッド開催ですが、発表者と参加者、参加者同士のコミュニケーションを重視しているため、基本的にはオフライン参加が推奨されています。 参加者はオンオフ含めた登録者は600人以上、そのうちオフライン参加者は300名弱と盛況でした。主な参加者としては、スポンサー企業をはじめとしたメール系のソリューションベンダー、メール送信サービスプロバイダ、メールホスティングプロバイダ、通信キャリア等で実務を担当されている方が多く、発表者のみならず参加者同士で現場担当者ならではの話を聞けるのが醍醐味です。 メールシステムシステムの運用というと、利用者からは「今まで通りに使えればそれでいい」と言われることが多いです。しかしそれを維持するためには「今まで通りのシステムのままでは駄目」であることはなかなか理解してもらえません。昨年のgmail認証強化のニュースは、メール業界以外の方も久々メールに目を向ける大きな出来事でした。ご存知ない方に簡単に説明しますと、gmail向けに一日5000件以上のメールを送る送信者に対して、SPF,DKIM,DMARCの対応を必須としました。例えるなら今まで自由に手紙を投函できたのが、差出人の名義に間違いがないか身分証による本人確認が必須になるような変化です。そのように周囲の状況が変化する中で、自分は今まで通りポストに投函した手紙が届いてくれるだけでいい、余計なことはしたくない、と言われても困りますよね。そのような話でどこも同じ悩みを抱えているんだなと共感したり、先進的な取り組みをされて成果を出している方の話を聞いたりするのが楽しみです。 JPAAWG General Meetingに参加して さてイベントの内容です。key noteでは本家M3AAWGの方から、M3AAWGの組織について知らない人向けの簡単な紹介と最近の会合に置けるトピックの共有が行われました。先日のIETF121でDKIM2の提言が行われたという話は気になります。そしてgoogleからセキュリティ担当の方がリモート参加され、送信制限の導入に至った理由とその効果についてお話がありました。gmailの送信制限については多くのサービスで既に対応が済んでいる時期でしたが、当事者からのお話ということで皆かつてないほど真剣に聞き入っていたと思います。 参加したセッションについては全てを取り上げることはできませんが、私が特に感銘を受けブログでの紹介についても発表者から個別に許諾をいただいたものを紹介します。IIJ古賀様による発表です。どのメールホスティングでも、利用者のsmtpアカウントが乗っ取られてspam送信に利用される事態の対応には頭を悩ませていると思います。時間当たりの送信数が基準値に達したらそれ以上送信できないよう自動的に制限を入れる取り組みはどこも行われていると思いますが、どうしても事後対応となるためある程度のspam送信は実行され、それによるIPのレピュテーション低下は起きてしまいます。IIJ様では、これをなんとか事前に抑止できないかという視点で取り組まれました。まずはメールサーバのログをすべてsplunkに入れて分析を行ったそうです。その結果spam送信が実行される前にある程度共通する事前準備、事前確認と思われるパターンを見つけたとのこと。この兆候を見つけるだけでもすごいことですが、兆候を見つけただけで制限をするわけにもいきません。まだそのアカウントはサービスに対して損害を与えていないのです。そこで次は法務部門や事業部門を巻き込んで、事前準備の兆候を見つけたらspam送信が行われる前に制限を実施するにはどうすればよいか、原稿の規約の解釈、変更後の規約の文言の検討、それに向けて法務や事業部門が求める観点でのデータ提出を行いつつ進めていき、ついに規約の改定と事前制限の実施にこぎつけたとのこと。法務と事業部門との関係性といえば、「こういうことをやりたいが法的に問題ないか？」という問いにyes/noを返してもらうだけ、という関わりが多いかと思います。そこを一歩進めて、事業側でこんなことをやりたいがどんな進め方をすればよいかという段階から法務にも協力してもらいつつ進めたというのが斬新でした。そしてこの取り組みの結果、契約者アカウントによるspam送信のabuse対応工数を30%削減できたそうです。この30%という数字が、かける金額と工数以上の成果となるかは組織によって異なると思いますが、同じような問題を抱えているサービスから見れば一歩も二歩も先を行った事例だと思いますので紹介させていただきました。 また今回はLTやその場でテーマを決めての議論も活発に行われました。その中でも印象に残っているトピックをいくつか紹介します。特定のIPを制限する対応や海外のIPを制限する対応を行っているサービスは多いと思いますが、エンドユーザの利用しているメール送信サービスがクラウドの海外リージョンに移行した結果、突然海外IPからの接続になってしまいトラブルとなった事例が紹介されるなど、IPによる制限はどんどん効果が薄くなっているという現状が共有されました。またgmailはIPv6に対応していますが、v6からの送信がどんどんブロックされるようになってきて、gmail宛ての送信はv4に回帰しているという話もありました。以前RBLを運用している方に話を伺ったとき、IPv4のRBLはブラックリスト方式だがv6になったらホワイトリスト方式でなければ無理だと話されていたのを思い出しました。LTにおいてはVadeSecure平野様による発表が圧巻でした。内容としてはwhoisの返す結果のフォーマットには特に決まりが無く各国のwhoisサーバ毎に異なり、プログラムで処理するのが非常に面倒であること、たとえばpythonのwhoisライブラリもいくつか出ているがJPNICのwhoisの結果を満足にパースできないこと等の比較と実証なのですが、なんと59ページに及ぶスライドを不自然にページを飛ばすことも無く5分で話しきるという離れ業をやってのけました。本当に5分で終わったのか思わず時計を確認したほどです。 さいごに JPAAWGのGeneralMeetingは一昨年は長崎、昨年は金沢、そして今年は札幌と、なかなか現地参加のハードルが高い場所での開催が多いですが、上記のような体験も現地参加でなければできないことですので、今後も参加を続けていきたいと思います。

この記事は GMOインターネットグループ Advent Calendar 2024 20日目の記事です。 はじめに プレゼン資料や新聞、ニュースなど至る所で目にするグラフ。データを整理し、一目で情報を伝えるために欠かせないツールです。しかし、グラフの種類や使い方を意識して選んでいる人はどれくらいいるでしょうか？適切なグラフを用いデータを可視化することで、データの本質を分かりやすく伝えることができます。本記事では、グラフの種類と使い分けを解説するとともに、実際に障害調査でグラフを活用した事例を交えながら、可視化の重要性について掘り下げていきます。 グラフの使い分け ばらつきを見る ヒストグラムストリップチャート箱ひげ図 値を比較する 棒グラフ 割合を見る 円グラフ積み上げ棒グラフ 時間変化を見る 折れ線グラフ積み上げ棒グラフ積み上げ面グラフ 値の関係を見る 散布図バブルチャート複合グラフ 主なグラフ ヒストグラム 用途：ばらつきを見る 次のグラフは、総務省の家計調査による「貯蓄現在高 階級別世帯分布（二人以上の世帯）2021年」です。ヒストグラムは棒グラフと似ていますが、棒（ヒストグラムではビンと言います）の幅で横軸の数値の範囲（階級数と言います）を表すことができます。 例えば、100～1000は100刻みですが、1000～2000は200刻みのため、1000～2000のビンは横幅が2倍に伸びています。2000～2500は横幅が5倍です。棒グラフでは見落としがち階級数も、グラフで表現することができます。 https://www.stat.go.jp/data/sav/sokuhou/nen/pdf/2021_yoyaku.pdf ストリップチャート 用途：ばらつきを見る 次のグラフは、47都道府県の2022年の平均気温です。ストリップチャートは1次元散布図とも言います。データの重なりが多いと解釈が困難なため、少量のデータをコンパクトに表示したい時に使います。 https://www.e-stat.go.jp/ 箱ひげ図 用途：ばらつきを見る 昔は数学Ⅰで習うものでしたが、2021年度の学習指導要領から中学2年生の数学で習うようになったようです。ストリップチャートよりシンプルな表現でばらつきが確認できます。 値の大きさではなく値の個数に着目し、昇順に並べ替えたデータに対し、先頭から数えて全体のx％目に位置するデータをxパーセンタイルと呼びます。また、25%ごとのパーセンタイルを四分位数（しぶんいすう）と呼びます。 25パーセンタイルの値：第一四分位数50パーセンタイルの値：第二四分位数（中央値）75パーセンタイルの値：第三四分位数 さらに、25～75パーセンタイルの値の範囲を四分位範囲（IQR：Interquartile Range）と呼びます。 そして、第三四分位数からIQR×1.5を上限に最も大きい値を最大値、第一四分位数からIQR×1.5を下限に最も小さい値を最小値、最大値・最小値の範囲外の値を外れ値として表現します。平均値を補記する場合もあります。 https://www.e-stat.go.jp/ 棒グラフ 用途：値を比較する 説明不要のおなじみの棒グラフですが、1つ注意点です。棒グラフは原点０を表略することができないものです。原点０を省略した場合、差異を過大に感じさせることに繋がります。テレビや広告などで原点０を省略した棒グラフを時々見かけることがありますが、印象に惑わされないよう注意が必要です。 https://www.e-stat.go.jp/ 円グラフ 用途：割合を見る 次のグラフは、2024年の日本におけるデスクトップ版ブラウザシェアです。円グラフは1/2、1/3のように割合が一目で分かりやすいです。 https://gs.statcounter.com/ 積み上げ棒グラフ 用途：割合を見る 割合は積み上げ棒グラフでも表現することができます。円グラフより省スペースに記載できる特徴があります。 折れ線グラフ 用途：時間変化を見る 次のグラフは、2023年の札幌市における月別平均気温です。気温のグラフは折れ線グラフがよく使われます。時間変化に棒グラフを使うことも可能ですが、気温は棒グラフに必要な原点０が存在しないため、棒グラフが使えません。 https://www.data.jma.go.jp/stats/etrn/index.php 折れ線グラフですが1つ注意点です。次の左側のグラフは3月から4月に掛けて"急激に減少"と表現されていますが、グラフを縦横に引き延ばすと右側のグラフは変化が緩やかに感じます。折れ線グラフは傾きで増減を表現する手法のため、増減の傾向の把握に留め、値の評価には注意が必要です。 積み上げ棒グラフ 用途：時間変化を見る 次のグラフは、当社のIR資料のうち、ビジネスモデル別の連結売上高です。全体と内訳両方の時間変化を確認することができます。 https://www.gmo-pg.com/news/pdf/20241113_gmo-pg_kessan.pdf 積み上げ面グラフ 用途：時間変化を見る 再び、日本におけるデスクトップ版ブラウザシェアです。割合の時間経過も積み上げ棒グラフで表現できますが、詳細なパーセンテージを示す必要がない場合は、積み上げ面グラフで省スペースに表現が可能です。 散布図 用途：値の関係を見る 47都道府県の年平均気温と最高気温（日最高気温の月平均の最高値）の関係性を表したグラフです。2値が相関していることが一目で分かります。 https://www.e-stat.go.jp/ バブルチャート 用途：値の関係を見る 先ほどの散布図に、最低気温（日最低気温の月平均の最低値）を円の大きさとして追加したものになります。3値を可視化することが可能です。 複合グラフ 用途：値の関係を見る 関連する棒グラフや折れ線グラフなどを1つの図に集約することで、複数の値の関係を表現します。 障害調査でデータを可視化した例 弊社は決済サービスをビジネスとしている会社で、日々オーソリ処理（クレジットカード決済の際に、カード会社に顧客の与信情報を照会して決済の可否を確認する手続き）を行っています。ある日、特定のカード会社起因で、本来オーソリNGにしてはならないカードが数百件レベルでNGと誤判定される障害が発生しました。事態はお客様からの連絡により数日後に知ることになったのですが、今後は我々で予め検知できるように、一定の閾値（NG率）を超えたらアラート通知することにしました。 問題は、アラート通知する閾値をどうするかです。まず、半年分のオーソリ件数とNG率をデータベースから抽出し、表に整理しました。数値は非公開となるため、下表は次の加工をしています。（実際の表は実数） 障害日（黄色）のNG率をｘ％とおく。NG率が障害日より高い日をオレンジ色、僅差で低い日を青色、その他は空白で記載オーソリ件数は障害日を「100,000」とした場合の比率を記載 障害日のNG率は確かに高めではあったものの、障害日より高い日や、僅差で低い日もあることから、障害日のNG率が突出して高いとは言えず、NG率のみで閾値を決めることができません。 二次元の表を眺めてても糸口が掴めないため、オーソリ件数とNG率の関係を見るために散布図に変換します。 散布図に変換することで、オーソリ件数が少ない日はNG率にバラツキがありますが、件数が増えるにつれてNG率がある程度収束していくことが一目で分かるようになりました。また、障害日が明らかに外れ値であることも散布図から分かります。 この分析結果を元に、ｘｘｘ件以上の時にα％以上のNG率（非公開）でアラート通知するように実装しました。 まとめ データの可視化は、膨大な数値データを直感的に理解しやすくするために重要です。グラフを用いることで、データ間のパターン、傾向、相関関係を迅速に把握でき、意思決定をサポートします。また、視覚化は複雑な情報を簡潔に伝える手段として、他者との効果的なコミュニケーションにも寄与します。さらに、異常値や潜在的な問題を発見する助けにもなり、問題解決や戦略策定において必要不可欠なものです。

はじめに Aレコード（ドメイン名をIPv4アドレスにマッピングするためのDNSレコードの一種）の変更作業はそれほど頻繁には発生しないかもしれませんが、複数のサイトを運営していると、この作業が必要になることがあります。Cloudflareに登録しているサイトのAレコード変更は、一般的にはブラウザから行いますが、ドメインが多数ある場合、対象の項目にたどり着くまでにかなりの時間がかかることもあります。そこで今回は、APIを利用してAレコードを変更する方法を試してみたいと思います。手順については、公式サイトやGoogleで検索して確認するのが一般的ですが、最近ではAIを活用して工数を削減することが一般的になっています。そこで、一例としてAIを利用した手順を紹介します。AIにはChatGPTやGemini、Claudeなどさまざまな選択肢がありますが、今回はPerplexityを用いた場合の簡易手順を紹介します。 Cloudflareとは Cloudflareは、ウェブサイトのパフォーマンス向上とセキュリティ強化を実現するための多様なサービスを提供しています。主な機能には、コンテンツデリバリーネットワーク（CDN）、DDoS攻撃防御、Webアプリケーションファイアウォール（WAF）、DNS管理、そしてZero Trustセキュリティがあります。これにより、ユーザーは高速で安全なオンライン体験を享受でき、悪意のある攻撃からウェブサイトを保護することが可能です。また、Cloudflareは簡単な設定で導入できるため、多くの企業にとって利用しやすいソリューションとなっています。 Perplexity AIとは Perplexity AIは、2022年に開発された対話型AI検索エンジンです。このプラットフォームは、自然言語処理や機械学習技術を活用し、ユーザーからの質問に対してリアルタイムで情報を検索し、出典元を明記した回答を提供します。特に、従来の検索エンジンとは異なり、ユーザーが自然な言葉で質問でき、その質問に対して直接的な回答が得られる点が特徴です Cloudflareに登録のあるAレコード（ IPアドレス）の変更作業の流れ Aレコードの変更作業は、特に異なるFQDN（完全修飾ドメイン名）を扱う場合、慎重に行う必要があります。誤って全く異なるFQDNのIPアドレスを変更してしまうと、サイトに影響を及ぼす可能性があります。そのため、まず対象の”FQDNのIPアドレスを確認するためのスクリプトA”を作成し、現在のIPアドレスを取得して正確な情報を確認します。その後、”IPアドレス変更用のスクリプトB”を作成して実行し対象のIPアドレスの変更を行います。（スクリプトAはdigコマンドでも可能ですが、API経由での情報の取得確認も兼ねております）Cloudflare APIを利用したスクリプト作成はAIにヒアリングしながら進めていきます。これにより、手動での操作ミスを防ぎつつ、効率的にIPアドレスの管理が可能となります。 Perplexity AIを利用するため、https://www.perplexity.ai/にアクセスします スクリプトA （IP確認用スクリプト） プロンプトに以下の様に入力します 以下のようなレスがあります スクリプトAの準備ができました。 しかし、スクリプトAを実施するにあたり、必要な情報（API_TOKEN、ZONE_ID）が不足しているため、さらに検索を行います。AIは前回の会話を記憶しているため、知りたい点だけを質問することで、効率的に情報を得ることができます。これにより、必要な情報を迅速に収集し、スクリプトの実行準備を整えることが可能です。 プロンプト: API_TOKENの確認方法は？ プロンプト: example.comのZONE_IDの確認方法は？ ※ zoneですので、FQDNの www.example.com ではなく、example.com になる点に注意 これでスクリプトAを実行するにあたり、必要な情報が揃いました。ローカル端末にて、スクリプトA（a.sh）を作成します※ ”API_TOKEN”と”ZONE_ID”を適切に置換が必要です スクリプトを実行する前に、以下の点を確認しておくと良いでしょう。1．APIトークンの取得: CloudflareのAPIトークンは、特定の権限を持つように設定されていることを確認してください。 特に、DNSレコードの編集権限が必要です。2．ゾーンIDの確認: 対象のドメインに関連するゾーンIDが正しいかどうかを確認します。 これには、Cloudflare APIを使用してゾーン情報を取得するコマンドを実行することができます。 スクリプトAの実行 結果を確認して、IPアドレスが正しく変更されたかどうかを検証します。問題が発生した場合は、エラーメッセージやログを参照し、必要に応じて修正を行います。このプロセスにより、安全かつ確実にIPアドレスの変更作業を進めることができます。 ※実際には、www.example.comではなく、実在するFQDNで仮作業を行いましたが、設定していた「1.1.1.1」と正しいIPアドレスが表示されることを確認できました。（digコマンドでも確認できますので一致しているか確認も有効です） スクリプトB（IP変更用スクリプト） 次に、IPアドレスを変更するためのスクリプトBを作成します。 スクリプトBの準備ができました。 ※ b.shのスクリプトにおいてIPアドレスを変更する際には、$RECORD_IDが必要です。この部分が自動で取得できるように記述されている点は、工数の削減につながる重要な要素です。 スクリプトBの実行 ローカルの端末でスクリプトB（b.sh）を作成し実行します。さらに変更されたIPアドレスを確認するために再度スクリプトA(a.sh)も実行します。これにより、IPアドレスの変更が正しく行われたかどうかを確認できます。 IPアドレスが変更されていることが確認できました。（実在するFQDNで実施しているため一部修正してあります） ただ、実行結果のメッセージ　"ttl":1　が気になります TTLが1秒という設定は気になります。非常に短いTTLは、DNSレコードのキャッシュが頻繁に更新されることを意味し、サーバーへの負荷が増加する可能性があります。このため、digコマンドを使用してIPを確認するとともに、権威DNSサーバーからTTLを確認してみることにします。 localhost% dig @権威DNS www.example.com （実在するFQDNで実施しているため一部修正してあります） 変更後のIPアドレスの確認とともに、TTLが300秒であることが確認できました。1秒ではありませんでしたが、やはり短めな設定であると感じます。このため、普段の運用ポリシーに基づいてTTLを見直すことをお勧めします。 最後に AIは手順の確認や補助的な役割として活用することが最も効果的です。AIを利用する際は、その利点を最大限に引き出すために必要な前提知識を持ち、自ら確認・判断することが重要です。特に、自動化されたプロセスは手動でのエラーリスクを低減し、工数削減にもつながりますので、積極的に取り入れていくべきです。また、変更した箇所以外の正常性確認を実施することも、システムやウェブサイトの運用において非常に重要であり、全体の安定性を保つためには欠かせないプロセスです。

この記事は「GMOインターネットグループ Advent Calendar 2024」19日目の記事です。こんにちは、GMO NIKKOの横内です。普段はRuby on Railsを使った開発やプロダクトの脆弱性診断などセキュリティ関連の業務をしています。今回はWebブラウザで広く利用されているCookieの脆弱性について書いていきたいと思います。 はじめに 今回この記事を書こうと思った経緯としては、最近の業務でCookieについて理解を深める機会がありそれを共有しようと思ったからです。Cookieは普段あまり意識することなく使用していますが、適切な設定を行わなければ容易に脆弱性になりうることを再確認し、今回ブログにて共有しようと思った次第です。 Cookieの基礎知識 Cookieは、ウェブサイトがユーザーのブラウザに保存する小さなテキストファイルで、ユーザーの情報や設定を保持するために使用されます。具体的には、ユーザーがウェブサイトを訪問するたびに、ブラウザは対応するCookieをサーバーに送信し、ユーザーの状態を管理します。CookieはステートレスなHTTPプロトコルの性質上、ユーザーのセッション情報や個別の設定を維持するための重要な役割を果たします。 Cookieは「送信される対象のドメインやパス」「有効期限」のような複数の属性を持つ構造で、これらの属性によってCookieの動作や有効範囲が制御されます。 そして今回はCookieのセキュリティを強化するSecure属性、HttpOnly属性、SameSite属性について触れていきたいと思います。 Secure属性 Secure属性は、CookieがHTTPS接続時にのみブラウザからサーバーに送信されるように制限する属性です。これにより、通信が暗号化されていないHTTP接続を介してCookieが送信されるリスクを低減します。 Secure属性が設定されていない場合、それを利用しセッションハイジャックや中間者攻撃などの攻撃を受ける可能性があります。 セッションハイジャックの例 Secure属性を設定していないWebサイトを利用したセッションハイジャックの例を紹介します。 ① 攻撃者が公衆Wi-Fiネットワークを設定 まず攻撃者は、カフェや空港などの公衆の場で偽のWi-Fiアクセスポイント（ホットスポット）を設置します。正規のネットワーク名（SSID）に似せた名前を使用することで、ユーザーが誤って接続するよう誘導します。 ② ユーザーが公衆Wi-Fiに接続し、ターゲットサイトにアクセス そしてユーザーが攻撃者の偽装した公衆Wi-Fiに接続した状態で、ログイン機能のあるSecure属性が設定されていないWebサイトにアクセスします。Secure属性が設定されていないため、セッションCookieはHTTPおよびHTTPS接続の両方で送信されます。 ③ 攻撃者が通信を傍受し、セッションCookieを取得 攻撃者は、偽のWi-Fiネットワークを通じてユーザーとサーバー間の通信を傍受します。Secure属性が設定されていないCookieは、暗号化されていないHTTP接続でも送信されるため、攻撃者はセッションCookieを容易に取得できます。 ④ 攻撃者が取得したCookieを使用してターゲットサイトに不正アクセス 攻撃者は取得したセッションCookieを自分のブラウザに設定し、ターゲットサイトにアクセスします。これにより、攻撃者はユーザーのセッションとして認識され、認証された状態で不正にアクセスが可能になります。結果として、ユーザーの個人情報やアカウント情報が漏洩するリスクが発生します。 対策 CookieにSecure属性を設定し、HTTPS接続時のみ送信されるようにします。これにより、暗号化されていないHTTP経由でのCookie漏洩を防ぎ、セッションハイジャックのリスクを低減します。ウェブサイト全体でHTTPSを徹底し、Secure属性を適用することが重要です。 HttpOnly属性 HttpOnly属性は、Cookieがクライアントサイドのスクリプト（例えばJavaScript）からアクセスできないようにする属性です。これにより、クロスサイトスクリプティング（以下XSS）攻撃を通じてCookieが盗まれるリスクを低減します。 XSSの例 HttpOnly属性を設定していないWebサイトにてXSSを利用しCookieを悪用する例を紹介します。 ①攻撃者がウェブサイトに悪意のあるスクリプトを注入まず攻撃者は、XSSを利用してターゲットウェブサイトに悪意のあるJavaScriptコードを注入します。これには、コメント欄やフォーム入力など、ユーザーが入力を行う部分を狙うことが一般的です。 ②ユーザーが感染したページを閲覧ユーザーが攻撃者によって改ざんされたページを閲覧すると、悪意のあるスクリプトがブラウザ上で実行されます。 ③悪意のあるスクリプトが実行され、セッションCookieを取得実行されたスクリプトは、document.cookieを利用してセッションCookieを取得し、攻撃者が管理するサーバーに送信します。HttpOnly属性が設定されていない場合、JavaScriptからCookieにアクセス可能となります。 ④攻撃者が取得したCookieを使用して不正アクセス攻撃者は取得したセッションCookieを自分のブラウザに設定し、ターゲットサイトにアクセスします。これにより、ユーザーのセッションとして認識され、不正にアカウントにアクセスできます。 対策 CookieにHttpOnly属性を設定し、JavaScriptからのアクセスを防ぎます。これにより、XSS攻撃によるセッションCookieの盗難を防ぎ、セッションハイジャックのリスクを大幅に低減します。HttpOnlyを有効にすることで、ブラウザ上での不正なスクリプト実行からCookieを保護します。 SameSite属性 SameSite属性は、Cookieがクロスサイトリクエスト（異なるサイトからのリクエスト）と共に送信されるかどうかを制御する属性です。Strict、Lax、Noneの3種類があり、特にクロスサイトリクエストフォージェリ（以下CSRF）攻撃の防止に有効です。 Strict 完全に同一サイトからのリクエストのみCookieが送信されます。Lax クロスサイトリクエストではCookieが送信されず、トップレベルナビゲーションでは送信されます。None クロスサイトリクエストでもCookieが送信されます。 SameSite属性が適切に設定されていない場合、それを利用しCSRFやセッションハイジャックの攻撃を受ける可能性があります。 CSRFの例 ①ユーザーがターゲットサイトにログインユーザーは正規のウェブサイトにログインし、認証Cookieがブラウザに保存されます。このとき、SameSite属性が適切に設定されていない場合、他サイトからのリクエストでもCookieが送信されます。 ②攻撃者が悪意のあるサイトを用意攻撃者は、ユーザーを誘導するための偽のウェブサイトやメールを用意します。このサイトには、不正なアクションを実行するリクエストを自動的に送信する仕掛けが組み込まれています。 ③ユーザーが攻撃者のサイトを訪問し、不正なリクエストを送信ユーザーが攻撃者のサイトを訪問すると、悪意のあるスクリプトやフォームが自動的に実行され、ターゲットサイトへの不正なリクエスト（例：送金リクエスト）が送信されます。このとき、SameSite属性がNoneや適切に設定されていないため、認証Cookieがリクエストと共に送信されます。 ④ターゲットサイトがリクエストを正当なものとして処理ターゲットサイトは受信したリクエストを正当なユーザーからのものと認識し、リクエストされたアクション（例：送金）を実行します。これにより、ユーザーの意図しない操作が行われ、被害が発生します。 対策 CookieにSameSite属性をStrictまたはLaxに設定し、他サイトからのリクエストでCookieが送信されないようにします。これにより、CSRF攻撃を防ぎ、認証Cookieの不正利用を防止します。 最後に 今回はCookieの脆弱性について書いてみましたがいかがだったでしょうか。 日々の開発業務に取り組む中で、Cookieについてはまだまだ理解が足りない部分があることに気づきました。今回の記事を書くことでCookieの重要性やセキュリティについてしっかり学ぶことができてとても良かったです。これからの開発ではCookieの管理も意識することでよりセキュアな開発をしていきたいと思っています。皆さんもぜひCookieの扱いに注意してみてください！

この記事は GMOインターネットグループ Advent Calendar 2024 18日目の記事です。 1. はじめに GMO ReTechの永橋です。サービスをローンチしてから4年が経ちましたが、4年間のほとんどがオフショア開発とともにありました。記事のタイトルには「支える技術」とありますが、ここでは技術（テクノロジー）面ではなく、オフショア開発におけるチームマネジメントの工夫（スキル）に焦点を当てたいと思います。 2. 開発チームの現状 2.1 チーム体制 現在のチーム体制は以下の通りです。 日本：3名 ・プロダクトマネージャー：1名・プロダクトアーキテクト：1名・デザイナー：1名 オフショア：23名 ・プロジェクトマネージャー：1名・BrSE（ブリッジSE）：3名・フロントエンドエンジニア：7名・バックエンドエンジニア：3名・アプリエンジニア：3名・品質管理：6名 GMO ReTechに所属し、賃貸DXの開発に携わるメンバーは私を含め3名で、開発の多くはGMOインターネットグループのオフショア開発チームの協力のもと行っています。現在はベトナムから23名がプロジェクトに参画しています。つまり、チーム全体では26名で賃貸DXの開発を行っています。 2.2 プロダクトアーキテクトの役割 私の立ち位置はプロダクトアーキテクトで、普段は賃貸DXの設計、開発、運用を担当しているエンジニアです。オフショア開発に関しては、技術的な仕様や課題に関するサポートを行っています。また、プロダクトマネージャーはオフショア開発を管理しており、日本とベトナムのコミュニケーションを円滑にする役割を担っています。 2.3 ブリッジSEの存在 オフショアチームにはブリッジSEというポジションのメンバーがおり、このメンバーが日本語で伝えた要件や仕様をベトナム語に翻訳し、開発工程に落とし込みます。このブリッジSEのメンバーはとても日本語が堪能でスラングもバリバリ使いこなします。非常にありがたい存在で、私たち日本のメンバーは言語の壁を感じることなくコミュニケーションが取れています。 3. オフショア開発で直面した課題と解決のための取り組み ここでは、オフショア開発で直面した課題を大きく3つご紹介します。 3.1 スケジュール管理の難しさ 3.1.1 祝日のズレと稼働日の可視化 まずは祝日による休みのズレです。例えば正月で言うと、ベトナムは旧正月なので、年末年始はベトナムが稼働している代わりに日本がお休み、旧暦1月1日の旧正月はベトナムがお休みで日本が稼働している…というように、休みのズレが生じます。そのため、リリースを終えてから次のリリースまで実質10日程しかない、ということもあります。 スプレッドシートで管理されているWBSに日本とベトナムの休日・祝日も記載し、休みをスケジュールに可視化しました。こちらが実際のスケジュール管理シートです 実際に2024年の1月リリースから2月のリリースまでの間は、フル稼働しているのは10日しかありませんでした…。濃い赤は祝日、薄い赤は祝日に合わせて休暇を取るメンバーが多く、稼働率が低い日であることを表しています。 とても初歩的ですが、WBSを見た瞬間に営業日がどれほどあるかわかるのは、期日を確認するうえでとても重要です。 3.2 UI・UXに対する認識の違い 3.2.1 感性・文化の壁と伝わらない例示 次に、感性や文化の壁です。オフショアチームのブリッジSEメンバーは非常に日本語が堪能なのですが、細かい部分でニュアンスが伝わらないことは避けられません。また、良かれと思って出した例が伝わらないことも多々あります。例えば日本で使われているメッセージングやSNSアプリに実装されている機能を参考に伝えても、ベトナムで使われているとは限りません。ゲームや娯楽も共通のものがなかなか無いため、うまく伝えるためには言葉だけでも画像だけでもなく、動画での動作イメージ共有が非常に大切です。（例えば、ボタンを押したときのアニメーションを◯◯のアプリのようにしたい、とした場合、スクリーンショットだけだと不十分ですよね） ここで重要になるのが「ノンバーバルコミュニケーション」の活用です。言語情報だけでなく、画面共有や動画、アニメーションを用いて非言語的な情報を伝えることで、細かいニュアンスまで共有しやすくなります。 3.2.2 具体的な要件伝達の重要性 コーディングやデザインについても同じことが言えます。具体的にどこまで伝えるかは難易度や規模によって変わりますが、・テーブル構成・ビジネスロジック・利用するメソッドやライブラリの選定・画面イメージはできる限り具体的に伝えたほうが、結果的に相違を抑えて進められます。 3.2.3 コミュニケーション頻度・密度の向上 これらの認識の違いの差は、コミュニケーションの頻度と密度を高めることで埋めることにしました。まず、毎日ブリッジSEのメンバーとZoomでの朝会を実施し、疑問や課題の共有の場を作ることで迅速に問題を察知できるようにしました。 Zoomで定例を実施するにあたって注意すべきは会議時間です。最近までは1時間実施していましたが、時間オーバーしてしまうことが多いので30分に減らし、会議時間を意識するようにしました。結果として、議題が選別されたり会話の応答速度が上がり、8割以上時間内に終わるようになりました。また、Zoomによる朝会を実施することにより、テキストによるコミュニケーションでは伝わりにくい事柄は画面共有を交えて伝わるようになり、細かいニュアンスが伝わりやすくなりました。不具合が生じた際は、朝会とは別にすぐにZoomで会話をします。ときにはオフショアのエンジニアもZoomに参加することで、リアルタイムに通訳してもらいながら解決を図ります。 デザイナーはFigmaを利用することで画面イメージを明確に伝えています。 スケジュールの都合上デザイン無しで開発を依頼することもありますが、やはりアウトプットに明確な違いが出ます。細かく伝えることはオフショアに限らず手戻りを増やさないために重要です。さらに言えば伝えるための手法も工夫しないと結局意図していたものと違う成果物があがってくる、ということです。 3.3 コード品質の担保 3.3.1 言語の壁とレビューラグ 成果物を確認する際はもちろんコードレビューを行いますが、言語による壁が発生します。日本語でレビューコメントを書き込んだ場合、それをブリッジSEのメンバーが翻訳したうえでオフショアのエンジニアに伝えるわけなので、当然伝達までにラグが発生します。また、ブリッジSEを介することで、エンジニア間では伝わる会話が正しく伝わらないことも多々あります。 3.3.2 AIコードレビューの活用 解決方法として、CodeRabbitというAIコードレビューツールを使用しています。 https://www.coderabbit.ai 製品仕様に関わるロジックの齟齬などはなかなか検出できませんが、細かいtypoやコードの改善提案などは十分に機能します。ベトナム語を指定することでコメントを直接ベトナム語にしたり、中間言語として英語を利用することも可能です。 4. その他ツールを利用した取り組み 4.1 CircleCIによる自動化 前述のZoom、スプレッドシート、CodeRabbitといったツールのほか、CircleCIを利用しています。 CircleCIでは通常のテストに加え、アプリのビルドを自動化しています。TestFlightやFirebase App Distributionへ自動で展開するため、開発内のテストやリリース前テストにおいてスムーズなテストを実現しています。 4.2 タスク管理ツールの試行錯誤 また、過去にはタスク管理としてTrelloを利用してKPT管理を行っていましたが、これについては失敗でした。Zoomでカンバンの整理をしながら話していると会議の時間が2時間と長時間になってしまったのが原因です。自前でスプレッドシートにまとめて簡易的に課題管理することで落ち着きました。 5. コード品質と設計思想 5.1 製品仕様に関わる指摘の難しさ コード品質の担保にAIコードレビューを使用していることは書きましたが、これでは製品仕様に関わる指摘はできません。そのため、別の方法で担保する必要があります。 5.2 設計段階での詳細化の重要性 オフショア開発に限らず、外部に開発を依頼する場合はどの程度自社で設計を行うかによって、最終的なアウトプットの品質が大きく変わってきます。つまり、機能の設計を細かくやればやるほど、成果物が想定したものから乖離することを抑えられるということです。 前述しましたが、オフショア開発の場合感性や文化の違いもあります。「こんな機能を作りたいんだ、よろしく」と丸投げすると、私たちの想像した機能とは似ても似つかないものが出来上がるのです。絶対にイメージしたものは出来上がらない、と断言できます。 5.3 将来連携や拡張性を考慮した設計 例えば機能Aに対して、将来的に機能Bと連携できるようにしたいと考えていたとしても、将来の連携を見越してを機能設計に正しく落とし込めなければ負債となり、機能Bとの連携を実装する際には大改修が必要になります。まさに、オフショアチームに設計の多くを丸投げしていた状況が2年ほど前の賃貸DXであり、現在は機能アップデートのたびに既存機能の設計変更を余儀なくされています。 現在では新規機能などテーブル変更や大きな仕様変更を伴う改修には、プロダクトアーキテクトを交えて日本側の設計思想を細かく伝えるようにしました。特に意識しなければならないのはパフォーマンスに対する考慮と機能に対する将来予測です。100レコード程度なら軽快に動く機能も、設計が悪ければ100万件、1億件のデータが入ったら目も当てられません。 また、将来的に機能をどのように発展させていきたいか、という展望はオフショア開発チームは持っておらず、あくまでも依頼されたものを作っています。将来的なことも踏まえた設計というのは自社で設計するからこそできることなので、その点も盛り込んで設計する必要があります。 簡単にまとめると、外出しするべきは「開発」であって、サービスの形を担う「設計」は自社で全て行うべき、ということです。当社のように自社のエンジニアが少ないとどうしてもオフショアチームに頼ってしまいがちですが、良いものを作るためには自社での設計を死守しなければなりません。開発を外部に委託する場合であっても、フレームワークの選定や既存機能の仕様、テーブル設計など、サービス全体を把握している人間が成果物を監督できれば品質が格段に向上します。 6. チームと個人のマインドセット 6.1 チームとしての優先順位 設計の重要性について書きましたが、チームとしては「期限＞品質」が重視されています。品質は後から改善できますが、期限は戻ってきません。まずは完成させ、機能を確実にお客様に提供することを第一に開発をしています。もちろん品質は重要ですが、いつまでに提供すると言った期限は必ず守るように動いています。 6.2 個人レベルでのスケジュール管理工夫 また、個人としては、 ・オフショアチームに伝える期限を実際の期限よりも短く設定し、・重要なタスクを優先的に渡し、・作業量が多くなりそうな場合は、タスクを細分化して調整する を徹底することで、スケジュール管理にある程度の柔軟性を持たせることができます。 7. 課題と今後の展望 7.1 感性・文化の違いとコミュニケーション課題の現状 オフショア開発においては、大きく感性や文化の違いによる課題と依頼・被依頼の立場による設計の課題があります感性や文化の違いはコミュニケーション頻度やツールの工夫によりそれほど意識することなく進めることができるようになっています。 7.2 設計上の課題と依存度低減への展望 設計に関してはサービスに精通しているプロダクトアーキテクトを交えることで、以前よりも細かく開発のハンドリングを行うことができるようになっています。 日本チームは現在少人数で開発にあたっており、スケジュール管理や設計は様々な工夫をすることで成り立っています。しかし、まだまだ改善しなければならないことは山ほどあり、理想を言えば細かい改修についてもすべて日本チームで設計を行った上で開発を依頼するのが望ましいです。しかし、程度はどうあれ、まだまだオフショアチームへの依存度が高いというのが実情です。今後更に品質の高いサービスにしていくことを目指し、この依存度を下げていくよう更に工夫をしていきたいと思います。

GMOインターネットグループは、世界トップクラスの情報セキュリティ専門家が集う国際会議「CODE BLUE 2024」にトップスポンサーとして協賛、登壇いたしました。このレポートではパネルディスカッション「GMOイエラエ全員集合！！進化するサイバー攻撃への対策最前線」の様子についてお届けします。 ホワイトハッカーが語る、最先端のサイバー犯罪とその対策 デジタル社会の進展とともに、サイバー攻撃の手法は日々進化を遂げています。企業や組織を狙ったランサムウェアやフィッシング詐欺など、その手口は巧妙化の一途をたどり、従来の防御態勢では対応が困難になりつつあります。近年進むIoTやスマートホームもこうしたサイバー攻撃の糸口となることもあり、現代のサイバーセキュリティ対策は技術の進化や人材育成・組織構造など多角的なアプローチが求められるといえるでしょう。こうした最先端のサイバー犯罪とその対策について、GMOサイバーセキュリティ byイエラエ（以下、GMOイエラエ）に所属する各分野のホワイトハッカー11名が語りました。 「困っている誰かを助ける」を軸に据えた技術と組織 林：本日はたくさんの方にお越しいただき、ありがとうございます。「GMOイエラエ全員集合！！進化するサイバー攻撃への対策最前線」というタイトルで、オープントークをさせていただきます。モデレーターの林（林 彦博/上席執行役員）です。 林 彦博（上席執行役員） 三村：同じく、モデレーターの三村（三村 聡志/セキュリティエンジニア）です。GMOイエラエはペネトレーションテスト（※1）のイメージが強いですが、実際には攻撃側に強い「レッド」、守りに強い「ブルー」、どちらも兼ね備えた企業です。本日はそんなイエラエの奥行きを皆様に感じていただければ幸いです。※1 ネットワークやシステムのセキュリティを検証するために、専門家が実際に攻撃を仕掛けることでセキュリティの対策状況やリスクを評価する取り組み。 三村 聡志（セキュリティエンジニア） 三村：というわけで、まずは牧田（牧田 誠/代表取締役社長）さんに、GMOイエラエについて聞いてみましょう。牧田さん、GMOイエラエはどういう会社でしょうか？ 牧田：GMOイエラエの根底にあるのは「誰かを助ける」精神です。ただし、誰かを助けたいなら自分たちが強くなければいけません。そこで「強い人」たちを募り、力を合わせて誰かを助けようとしている会社だと思っています。 林：ありがとうございます。では次に、インターポールで働いていたという福森（福森 大喜/サイバー犯罪対策センター長）さん。大変興味深いお仕事ですが、可能な範囲で、何をしていたのか聞かせていただけますか？ 福森：インターポールは皆さんご存知のように、国際的なサイバー犯罪への対処や、対処するための組織を育成していく組織です。そこで犯罪捜査の支援やトレーニング、各国警察官に対するものをやっていました。 林：「守る」という観点からいえば、ルスラン（サイフィエフ ルスラン/執行役員）さん。日本企業のセキュリティは破りやすいですか？ ルスラン: 非常に破りやすいですね。 林：（笑）。これは手厳しい。阿部（阿部 慎司/執行役員）さん、SOC（Security Operation Center）（※2）サービスを提供するイエラエとして、この状況にどう立ち向かいますか。※2 組織のITインフラを24時間365日監視し、セキュリティインシデントの早期発見や対応を行う専門チームまたは施設。 阿部：我々は誇りを持ってSOCサービスを提供していますが、残念ながら「痒いところに手が届かない」部分も残されているのが実情です。 例えばですが、SOCという形に必ずしもこだわらず、「イエラエとご契約いただければ、どの製品でも必ず見解を出す」のように、踏み込んだサポートを提供できるとよりよいのかなと。「皆さんの困りごとに対して何ができるか」という軸は変えずに、「痒いところ」を逃がさないような新しい形のSOCが実現できるように頑張っているところです。 阿部 慎司（執行役員） 林：なんて言っていたら、馬場（馬場 将次/セキュリティエンジニア）さんと目が合いましたね。何かご意見はありますか？ 馬場：GMOイエラエのいいところは、他社の製品報告についての脆弱性を発見すると、会社から報奨金を支給してもらえるところです。自分は最近、太陽光発電を自宅に導入したのですが、さっそく脆弱性を発見し、報告して報奨金をもらいました（笑）。 どのようなプロダクトでも良いわけではなく、ある程度普及しているプロダクトという前提はありますが、脆弱性を見つけるのが得意な人は、ぜひGMOイエラエに入ってください。 林：今年は何件ぐらい見つけたんですか？ 馬場：10件ほどですね。でも、もっと見つけている人も全然います。実は世の中のプロダクトって脆弱性だらけなので、みんなで一緒に社会を守れれば嬉しいですね。 馬場 将次（セキュリティエンジニア） 林：攻撃の技術を守りに使っていく、まさにホワイトハッカーですね。そういえば市川（市川 遼 開発部長）さんは今、現状を可視化してどういう対策をしていけばいいか示すというサービスを提供していますね。せっかくなのでご紹介いただけますか？ 市川：私が取り組んでいるのは「GMOサイバー攻撃ネットde診断」というサービスで、一般的にはASM（Attack Surface Management）（※3）と呼ばれるものです。他にも脆弱性診断をツール化・自動化して、お客様のセキュリティに貢献するサービスも提供しています。※3 インターネットから アクセス可能なIT資産の情報を調査し、それらに存在する脆弱性などのリスクを継続的に検出・評価する取り組みです。 これらのサービスはいわば、我々の持っている知見をサマライズし、ツールに落とし込んだものです。イエラエの技術力を皆さんにおすそ分けするイメージですね。 林：素晴らしいです。奥野（奥野 史一/執行役員）さんはどうですか？ 奥野：私は官公庁の事業を担当し、ペネトレーションテストからサイバー演習まで幅広い領域を扱っています。最近ではグローバルの官公庁、たとえばモンゴルのウランバートル市に「ネットde診断」が入りましたし、大手銀行の方でも脆弱性やスマホアプリの診断をしています。 このメンバーを見ていただければわかるように、せっかくの技術がグローバルに出ないのはもったいないので、これからどんどん世界に出ていきたいなと、一生懸命やっています。 奥野 史一（執行役員） 林：広い視野で取り組んでいるわけですね。モンゴル出張はよく行かれるんですか？ 奥野：行くこともあります。2月に行ったときはマイナス30度でした。覚悟して行きましたが、意外と大丈夫でした（笑）。これだけ寒いと、データセンターが効率的に冷えるのでいいですね。ちなみに、モンゴルの一番のおもてなしは羊の丸焼きです。2回出てきました。 組織&人材育成に多くのメリットをもたらすCTF 林：さて、CTF（Capture The Flag）（※4）については、小池（小池 悠生/執行役員）さんに聞かなければなりません。技術をどう伸ばすか、素晴らしいエンジニアをどう育成していくか。この点について、どうでしょうか。※4 セキュリティ分野で行われる競技形式のセキュリティコンテスト。参加者は専門技術や知識を駆使して特定の課題を解くことで「フラッグ」を獲得し、時間内に獲得した合計点数を競い合う。 小池：私はIoTのペネトレーションまわりのマネジメントをしている立場になりますが、それとは別に、執行役員として会社ブランドの取りまとめにも携わっています。そのための取り組みの一例が、先ほど出てきた脆弱性発見の報奨金制度や、CTFへの参加推奨ですね。 これは牧田さんも同意してくれるところだと思うんですけど、CTFセキュリティコンテストで上位の成績を上げているような人たちは、実際の業務においても非常に優秀な成果を出してくれます。 小池 悠生（執行役員） 三村：うちの会社は、社長が「鶴の一声」で採用を決めることがありますが、そうしてジョインする方は、一芸に秀でている人が多い印象ですよね。 牧田：一芸はめちゃめちゃ大事です。まさにCODEBLUEで出会ってスカウトした方もいますが、とても活躍されているので、「鶴の一声」形式は間違ってないはず（笑）。みなさん素晴らしい方ばかりです。 林：王（王 瀚邦/リバースエンジニア）さんもCTFのトッププレーヤーとして活躍されていますよね。何をモチベーションにされていますか？ 王：CTFに取り組み始めたのは4年ほど前になりますが、私が好きなパズルゲームのように「壊して、つくる」楽しみがモチベーションになっています。これは、リバースエンジニアリング（※5）にも似ている部分ですね。※5 既存のプログラムから設計情報を抽出し、構造や動作を解析する技術。動作理解や改良、セキュリティ検証に活用される。マシンコードに複合させたり、一般的に組み立てたりする点に近しいものを感じます。そのうえで、物事がどのように機能しているか解き明かすことに楽しみを見出しています。 三村：私も以前、CTFの力を高めるために「Baba Is You」（思考力が鍛えられると話題のインディーズゲーム）をやれと言われたことがあります。馬場さんは普段、どういう形で頭を鍛えたり休ませたりしていますか？ 馬場：頭の鍛え方はやっぱり脳トレがベストですね。「Baba Is You」のいいところって、「こういう操作はできないだろう」という思い込みがあると、絶対に解けないところなんです。機転を効かせた発想を学べるので、あれは真面目に、良いトレーニングになると思いますね。みなさんもBabaになりましょう（笑）。 三村：CTFでも、本来の用途からひねったデータを使って攻撃コードを組んだりとか、そういうのが求められるので、柔軟さは必要になってきますもんね。他にも、教育とか育成という観点で、ルスランさんいかがですか？ ルスラン：皆さんにぜひ育てていただきたいのは、クリエイティビティです。それがないと、いくら勉強しても限界があるので…。頭を柔らかくして「どうやって解くべきか」の引き出しを増やし続けるのが一番良いと考えています。 サイフィエフ ルスラン（執行役員） 林：福森さんはどうですか？インターポール時代にこうしたストーリーはありませんでしたか？ 福森：インターポールは197か国からなる組織なので、中には「どうせ自分たちなんかダメだろう」「FBIが出てきたから、出る幕がないな」と卑屈になってしまう人もいました。そういう人をいかにモチベートするかは、大きな課題でしたね。 そんなときには、たとえば「フリーツールだけでも、FBIが見つけられないような脆弱性を見つけられる」という経験をさせ、小さい成功体験から自信を持ってもらうようにしていました。 福森 大喜（サイバー犯罪対策センター長） 三村：守るためには技術だけではなく、人とのつながりも重要です。当社には仲間づくりのプロである林がおりますが、そういう点ではどうでしょう。 林：セキュリティへの取り組みを自分だけで考えるのには限界があるので、外の知見やコミュニケーションがすごく大事だなと、昔から思っていました。なおかつ、セキュリティの人たちって、ときには「余計なお世話」と思えるくらい親切な人が多くて、質の高いアドバイスをもらえるのが嬉しいところです。 質のいいコミュニティとの縁をつなぎ、いい仲間作りをしていくことが、巡り巡ってセキュリティへの知見のレベルも高めてくれているような気がします。 攻撃の手法から対象まで、日々進化するサイバー攻撃との終わりなき戦い 三村：小池さんは最近、「面白いな」と感じた攻撃や、CTFはありますか？ 小池：NDAの関係であまり言えなかったりするんですが、最近面白いなと思ったのは、いわゆるプロンプトインジェクションですね。攻撃者がLLMに対して与えるプロンプトを上書きして、LLMが意図しない挙動をさせるという。 そこからいろんな攻撃に繋げていくわけですが、対策はいたちごっこになっていまして、対策をさらに回避させるような攻撃があったりします。 例えば、モールス信号をプロンプトとして与えるという攻撃手法が最近有名になりましたね。自然言語での入力は対策されていますが、モールス信号のような非言語は想定されていなかったので、上位モデルのLLMではモールスでそのまま返しちゃう、と。 牧田：それでいうと、スマートシティ社会になっていく中で、アタックベクターも多彩になってますね。手法自体もリビングオフザラウンドとか、そもそもマルウェアを使わないとか。 太陽光発電の脆弱性でいえば、天気がいいときは蓄電池に積極的に貯めて、雨の日は使用を控えるといった制御機器の脆弱性には注意が必要です。またこうした制御機器は、他の家電と連携して操作するリモコンの役割も果たしていたりするので、いま話題の闇バイトにも悪用されかねない怖さがあります。 林：予想もしないリスクが潜んでいるということですね。次は阿部さん、SOCやブルーチームのホットトピックがあれば伺いたいです。 阿部：他の方からもお話があった通り、ちまたを賑わせるインシデントはものすごく多く、攻撃はどんどん分かりにくくなっています。その結果、守る側としても、トレーニングの仕事やインシデントレスキューの機会が増えてきている印象です。 三村：会社で見ていても、SOCの名将と呼ばれる阿部さんの額に流れる汗の量が日に日に増えているのを感じます（笑）。 阿部：（笑）。ここ数年で流行っているEDR（※6）やAIのふるまいなど、守るべき点は多岐にわたります。外部脅威からの保護はもちろんですが、組織やビジネスとしてのリスクも考えながら対策を講じなければなりません。※6 エンドポイント（PCやスマートフォンなど）を監視し、不審な挙動を検知・分析して適切な対応を行うセキュリティ対策。 そのため、これからのセキュリティ事業者には、単に知見を持つだけでなく、クライアントと幅広く同じ目線で考え、積極的に提案できる会社であることが求められるでしょう。そうしたときにイエラエの強みが生きるように思います。 AI活用も進めつつ、ホワイトハッカーを「億万長者」に 三村：ASMではどうですか？ 市川：ASMについては、昔から言われてきた「サーバーのバージョンをちゃんとアップデートしましょう」といったレベルから大きく変わったところはありません。可視化が進んだことにより、対策しやすくなった面はありますが。 ただ、世の中のサイバー攻撃は、未知のゼロデイ（※7）がどんどん飛んでくるというよりも、権限設定が甘かったり、個々のPCが狙われていたりするものが圧倒的に多いので、こうした対策を徹底するのは依然として重要と言えます。このあたり、会社のガバナンスがうまく効いてないとかなり危ないことになるケースもあります。※7 未公開で修正パッチが存在しない脆弱性を指す。攻撃者は開発者が脆弱性を認識し対処する前に攻撃を仕掛けるため、非常に危険とされる。 市川 遼（開発部長） 林：王さんにも聞いてみましょう。王さん、テクノロジーやエンジニアリング周りで、ホットトピックはありますか？ 王：最近、CTFのリバースエンジニア・チャレンジに参加したのですが、他のリバースエンジニアとどうやってその課題を解決したかを話したら、みんな、「AIに入力しただけだよ」と。 どうやらAIは、課題のコードを入力するだけで、それを解いてくれる段階まで来ているようです。なので「僕はもう必要とされていない」と悲しく思うと同時に（笑）、AIの使い方も学ばなければと感じています。 王 瀚邦（リバースエンジニア） 三村：では締めとして牧田さんから、今後イエラエという船がどう進んでいくのかという展望、これからイエラエに来てみたいという人に向けてひとことお願いします。 牧田：我々イエラエの手が届く範囲は、今や日本全体に広がりました。とりあえずここをやり切り、その後はアジア、そして世界へと、グローバルに戦いの場を移していく所存です。 また僕のサブミッションとして、「社内のセキュリティエンジニアを億万長者にする」ことがあります。みんなが成果を出して巨万の富を得られれば、子どもたちが「ホワイトハッカーになりたい」という世界観ができるかもしれません。そうなれば、そのエコシステムで社会全体が良くなっていくじゃないですか。 エンジニアに利益を還元することで、自然と次世代を担う子どもたちから「ああいうふうになりたい」と思ってもらえる未来を実現したいです。多分、ここにいるみんなも初めて聞く野望かもしれませんが（笑）、そんな未来がたぐり寄せられるように、日々の業務に邁進します！ 牧田 誠 代表取締役社長

この記事は GMOインターネットグループ Advent Calendar 2024 17日目の記事です。みなさん、おはようございます！こんにちは！こんばんは！GMOペパボ株式会社の横山です。今回のアドベントカレンダーでは、被写体を切り抜いて、簡単に背景を簡単に変更・生成できるアプリケーションを学習しつつ作ったときの記録を残したいと思います。 はじめに こんにちは！GMOペパボ株式会社所属の横山です。社内ではあだ名で呼び合う文化があり、はるおつと呼ばれています。普段は誰でも簡単にマルチプレイ用ゲームサーバーが立てられる機能を提供する、ロリポップ for gamersでエンジニアをしています。 さて、みなさんAIしていますでしょうか。大AI時代のビッグウェーブに常に乗っていたいですね。今回は私がそんな気持ちでふと、画像生成AIを使ってみたい、どうせなら実応用できそうなもので試してみるかという気持ちで学習しつつ作ったアプリケーションについて紹介します。 SNSやフリマアプリに画像をアップロードする際、次のような経験はありませんか？ 背景がごちゃごちゃしていて見栄えが悪い。テーマに合った背景や撮影環境を整えるのが大変。 今回私が作ったアプリケーションはこんな悩みを解決できるかもしれません。 どんなものを作ったのか？ 今回、yahoo-inc/photo-background-generationモデルを使用し被写体を切り抜いてその背景を自由に生成・変更できるようなアプリケーションを作成しました。 ユーザーが画像をアップロードした際に、その画像のメインとなる被写体を切り抜いて、 背景画像が用意されている場合には、それと合成する背景画像が用意されていない場合には、プロンプトに基づいた背景を生成して合成する 仕様になっています。(カッコつけてProdDiffuserという名前を付けました。) https://github.com/hrt-ykym/ProdDiffuser 動いているところを見てみましょう 例えば、被写体として以下のようなカメラの画像があるとします。 この被写体に対して、背景画像が用意されている(左図)場合、カメラ部分だけを切り抜いて、指定された背景と合成します(右図)。 次に、背景画像がなく、AIによって生成したい場合について、例えば「on the beach」というプロンプトを入れたとします。すると以下のような画像が生成されます。このようにAIが生成した背景画像を、被写体画像と合成することで、テーマに合った画像が簡単に作れる仕様になっています。 実装のポイント 背景生成に使用した yahoo-inc/photo-background-generation 背景生成には、Hugging Faceで提供されているyahoo-inc/photo-background-generationモデルを使用しました。このモデルは、背景生成に特化したDiffusion Modelであり、被写体と背景の境界部分が滑らかに融合するため特徴を持っています。 背景生成のみに焦点を当てたDiffusion Model 通常のDiffusion Modelは、画像全体を生成対象とします。しかし、このモデルは背景部分に特化した生成を行い、被写体を破壊しないという独自の設計思想を持っています。背景領域のみに制約をかけることで既存の生成モデルでみられる、被写体と背景の区別が曖昧になり被写体と合成したときの不自然になってしまう問題を解決しています。 ControlNetによる領域制御 ControlNetは、条件画像（ここでは被写体の形状や配置を反映したマスク）を基に生成領域をピクセル単位で指定できるのが特徴です。 他の生成モデルでは背景を制御する手段が限られていますが、本モデルはControlNet技術を採用し、被写体を除外した領域（背景）にのみ生成を限定します。これにより、背景部分をピクセル単位で精密に制御可能です。被写体の形状や配置に基づくマスクを入力することで、生成対象を意図的に限定できるため、より正確で自然な背景を作成できます。 テキストプロンプトとマスクのハイブリッド活用 一般的な生成モデルは、テキストプロンプトだけ、または画像の構造だけを条件として利用します。しかし、本モデルテキストプロンプトとマスク画像を組み合わせることで、背景に対して物理的な制約を同時に満たす画像を生成することができます。つまり、物理的にありえない画像は生成しないということです。例えば、「on the beach」というプロンプトと被写体の形状マスクを組み合わせることで、背景全体に砂浜の風景を適用しつつ、被写体周囲の細かいエッジ処理を自然に行います。影などが生成されるのもこの影響と考えられます。 被写体の切り抜き 製品画像から被写体を切り抜くには、transparent-backgroundライブラリを使用しています。このライブラリは画像を解析して背景を透明化するシンプルなインターフェースを提供します。 from transparent_background import Remover from PIL import Image def process_foreground(product_image_path): remover = Remover() product_image = Image.open(product_image_path).convert("RGB") return remover.process(product_image).convert("RGBA") これにより、被写体部分のみを切り抜いた画像が得られます。この結果はRGBA形式の画像として保存され、次の合成処理で透明部分を考慮した操作が可能になります。 工夫した点 今回、yahoo-inc/photo-background-generationモデルをそのまま使用するだけでなく、実用性を高めるためにいくつかの工夫を施しています。これにより、ユーザーがより簡単かつ直感的に利用できるようになっています。 背景生成と用意された背景画像の両対応 公式モデルでは背景生成が主なユースケースですが、本アプリケーションでは、すでに用意された背景画像を使用できるオプションを追加しました。 def combine_foreground_with_background_centered( foreground, background_image_path, target_size=(512, 512), scale=1.0, position=None ): background_image = Image.open(background_image_path).convert("RGBA") # 背景画像をリサイズしてアスペクト比を維持 background_image = resize_with_aspect_ratio_and_padding(background_image, target_size) # 被写体画像をスケール調整 new_width = int(foreground.width * scale) new_height = int(foreground.height * scale) foreground = foreground.resize((new_width, new_height), Image.Resampling.LANCZOS) # 被写体画像を中央に配置 if position is None: x = (background_image.width - foreground.width) // 2 y = (background_image.height - foreground.height) // 2 else: x, y = position # 背景と被写体を合成 combined_image = background_image.copy() combined_image.paste(foreground, (x, y), foreground) return combined_image パラメータ 背景生成において、ユーザー自身でのカスタマイズ性を保つために、関数の引数をもたせました。しかし、すべてユーザーに設定させるのは非効率であるため、デフォルト値も一般的なユースケースに合わせて設定しました。 result_image = generate_background_with_prompt_and_mask_or_combine( product_image_path="assets/product_image.jpg", prompt="on the beach", # 背景生成用プロンプト background_image_path=None, # 背景画像がある場合はパスを指定 seed=13,　# シード値 target_size=(512, 512), scale=0.3, # 被写体スケール position=None, # 被写体の配置 num_inference_steps=20, # 推論ステップ controlnet_conditioning_scale=1.0 # ControlNetの条件付け ) 被写体マスクの自動生成とエッジ融合の工夫 被写体の輪郭を正確に保持するため、被写体のアルファチャンネルを反転してマスクを生成することで、背景生成が不要な領域を除外し、自然な合成が可能です。 from PIL import ImageOps def generate_mask(image): # アルファチャンネルを反転し、背景領域を明示 return ImageOps.invert(image.split()[-1]) # 最後のチャンネルを反転 被写体切り抜きを調整したい場合 デフォルトの設定でも十分な被写体切り抜きが可能ですが、もしどこからどこまでが被写体なのかを判別するかをチューニングしたい場合には、以下のように背景と被写体の境界を判定するしきい値を動的に変更することで、より柔軟な抽出が可能であることを確認しています。 def tune_mask(mask_image, threshold=0.5): mask_array = np.array(mask_image) # しきい値処理 adjusted_mask = (mask_array > threshold * 255).astype(np.uint8) * 255 return Image.fromarray(adjusted_mask) この処理をtransparent_backgroundのRemoverクラスの後処理としてこの関数を組み込むことで、ユーザーが簡単にしきい値を設定できるようになります。例えば、被写体が背景に溶け込みやすい場合は、しきい値を下げるなどして対応が可能となります。 GPUとCPU環境での柔軟な動作 だれもがGPU (CUDA)を積んだPCを持っているとは限らないため、モデルの高性能を活かすため、NVIDIA GPUがある場合は自動で切り替え、ない場合はCPUで動作するように設計しました。 device = "cuda" if torch.cuda.is_available() else "cpu" pipeline = DiffusionPipeline.from_pretrained(model_id, custom_pipeline=model_id) pipeline = pipeline.to(device) # 使用可能なデバイスに移行 なお、もしCUDAを用いたGPUの設定に困っている場合は別途記事を書いたのでこちらを参考にしてください。 類似ソフトウェアとの違い 被写体切り抜きと背景生成を組み合わせたアプリケーションは、近年さまざまなプラットフォームやツールで提供されていますが、今回のアプリケーションは以下のような特徴を持っています。 ControlNet技術を活用して、背景生成領域をピクセル単位で制御するため、被写体と背景の統合精度が非常に高い。被写体と背景の合成を行った際に境界が不自然になりがちだが、自然なエッジ融合を可能にしている。背景をすでに用意している場合としていない場合の柔軟な対応が可能にしている。背景をすでに用意している場合としていない場合の柔軟な対応が可能にしている。GPU/CPUのいずれの環境でも動作可能で、オンプレミスやクラウド上での運用がすぐに可能にしている。 まとめ 今回の記事では、画像生成AIを組み合わせた被写体の切り抜きと背景生成・変更を簡単に行えるアプリケーションを作った時の記録を紹介しました。SNSやフリマアプリ、さらにはECサイトの商品画像など、幅広いシーンで活用されれば嬉しいなと思います。 今後やりたいこと ここまでお読みいただきありがとうございます！最後に今後やってみたいことを書いておきます。ぜひ他にも「こんな機能があったらいいな」「こうしたらもっと使いやすくなる」などのアイデアがあれば、ぜひ教えてください！GitHubのリポジトリやSNSを通じてコメントをいただけると嬉しいです。 日本語プロンプト 今回、yahoo-inc/photo-background-generationモデルを使用した都合上、背景生成の際に入力するプロンプトは英語のみとなっています。これを日本語にも対応させることがもし実際の場面で使用する場合には必要になるかと思います。手法としては、実現方法としては以下を検討中です。 ユーザーが入力した日本語のプロンプトを自動で英語に翻訳し、それを生成モデルに渡す仕組み。Google TranslateやDeepL APIを活用する対応日本語プロンプトを直接解釈できる生成モデルを用いたり、本モデルのアルゴリズムを用いて日本語で再学習したりする日本語対応モデルによる対応 複数画像のバッチ処理 現在は一枚ずつ画像をアップロードして加工する形をとっていますが、複数の画像を一括で処理できる機能を実装すれば、商品画像やSNS投稿用画像の一括加工といった場面での活用が期待されます。

この記事は GMOインターネットグループ Advent Calendar 202416日目の記事です。GMO NIKKOの野田です。現在GMO NIKKOでは新規プロダクトの開発を行っており、fincode byGMOでプラン別の決済機能を実装しました。今回はfincode byGMOの使用例として参考にしていただけるように記事を書きました。 fincode byGMOとは GMOイプシロン株式会社が提供する決済サービスです。https://www.fincode.jp/ 「エンジニアファーストの設計、洗練されたUXで最高の開発体験を」という言葉通り、エンジニアにとって使いやすく、ドキュメントも充実しています。https://docs.fincode.jp/GMOインターネットグループの決済サービスには、GMOペイメントゲートウェイ株式会社が提供する、PGマルチペイメントサービスという業界を代表するサービスもあります。https://www.gmo-pg.com/service/mulpay/ PGマルチペイメントサービスの使用も検討しましたが、fincode byGMOはスタートアップ向けということで、新規プロダクトの要件にも合っていたので、今回はfincode byGMOを使うことになりました。 fincode byGMOのテスト環境について fincode byGMOにはテスト環境が用意されています。https://docs.fincode.jp/tutorial/test_sign_upこちらはfincode byGMOの申し込み前からアカウントを作成できるので、事前にAPIの検証を行うことができます。テストで使用できるカードも用意されているので、決済のテストも行うことができます。https://docs.fincode.jp/develop_support/test_resources プラン別決済機能の実装 プラン別決済機能とは プラン別の決済機能は、以下のようなイメージです。 ユーザーが選択したプランに応じて、毎月、毎年などの期間ごとに設定された金額で決済を行います 事前準備 プラン別決済機能の実装のためには、以下のデータが必要になります。 顧客カード（カード決済の場合）プランサブスクリプション プラン別決済機能で使用するプランのデータを作成し、それをサブスクリプション機能で顧客に割り当てるイメージです。今回の記事では、サブスクリプションをAPI経由で作成する方法について記載し、その他のデータはfincode byGMOの管理画面から作成しました。管理画面からの作成方法は、公式のブログが参考になります。https://blog.fincode.jp/product_blog/376-2/ サブスクリプションの作成 ユーザーがサービスの申し込みをした時に、サブスクリプションというデータを作成し、ユーザーにプランを割り当てます。 （画像はテスト環境のものです。）サブスクリプションについては以下に説明が記載されています。https://docs.fincode.jp/payment/subscriptionfincode byGMOには決済APIもあり、そちらで決済処理を行うこともできますが、サブスクリプションを作成することで定期的な決済処理を行うことができます。サブスクリプションには、課金開始日や初回利用金額を設定できるので、無料期間の設定や、課金日を月初や月末にする場合に、申込日に応じた日割り課金の設定も行うことができます。サブスクリプションは実際の運用でもAPI経由で作成するので、今回はいくつかのパターンでサブスクリプションをAPI経由で登録するソースコードを作成しました。ちなみに、今回記載した例は、実際のプロダクトの仕様とは異なる場合があります。（今回は消費税の計算については省略しています。） サブスクリプションを作成する処理 サブスクリプションの登録、解約、取得を行う処理を作成しました。こちらを使用して各パターンの決済処理を行います。 package fincode import ( "bytes" "encoding/json" "fmt" "io" "log" "net/http" "net/url" ) type FincodeClient struct { apiKey string apiUrl string httpClient *http.Client } func NewFincodeClient() *FincodeClient { return &FincodeClient{ apiKey: "fincode byGMOの管理画面から取得したkey", apiUrl: "https://api.test.fincode.jp", httpClient: &http.Client{}, } } func (c *FincodeClient) CreateSubscription(request *CreateSubscriptionRequest) (*CreateSubscriptionResponse, error) { requestBody, err := json.Marshal(request) if err != nil { return nil, err } // リクエストの作成 req, err := http.NewRequest("POST", fmt.Sprintf("%s/v1/subscriptions", c.apiUrl), bytes.NewBuffer(requestBody)) if err != nil { return nil, err } req.Header.Set("Authorization", fmt.Sprintf("Bearer %s", c.apiKey)) req.Header.Set("Content-Type", "application/json") // リクエストの送信 res, err := c.httpClient.Do(req) if err != nil { return nil, err } defer func(Body io.ReadCloser) { err := Body.Close() if err != nil { log.Fatal(err) } }(res.Body) responseBody, err := io.ReadAll(res.Body) if err != nil { log.Fatalf("Failed to read requestBody: %v", err) } var response CreateSubscriptionResponse err = json.Unmarshal(responseBody, &response) if err != nil { return nil, err } return &response, nil } func (c *FincodeClient) DeleteSubscription(subscriptionID string) (*CreateSubscriptionResponse, error) { // リクエストの作成 params := url.Values{} params.Add("pay_type", "Card") req, err := http.NewRequest("DELETE", fmt.Sprintf("%s/v1/subscriptions/%s?%s", c.apiUrl, subscriptionID, params.Encode()), nil) if err != nil { return nil, err } req.Header.Set("Authorization", fmt.Sprintf("Bearer %s", c.apiKey)) // リクエストの送信 res, err := c.httpClient.Do(req) if err != nil { return nil, err } defer func(Body io.ReadCloser) { err := Body.Close() if err != nil { log.Fatal(err) } }(res.Body) responseBody, err := io.ReadAll(res.Body) if err != nil { log.Fatalf("Failed to read responseBody: %v", err) } var response CreateSubscriptionResponse err = json.Unmarshal(responseBody, &response) if err != nil { return nil, err } return &response, nil } func (c *FincodeClient) GetSubscription(subscriptionID string) (*GetSubscriptionResponse, error) { // リクエストの作成 params := url.Values{} params.Add("pay_type", "Card") req, err := http.NewRequest("GET", fmt.Sprintf("%s/v1/subscriptions/%s?%s", c.apiUrl, subscriptionID, params.Encode()), nil) if err != nil { return nil, err } req.Header.Set("Authorization", fmt.Sprintf("Bearer %s", c.apiKey)) // リクエストの送信 res, err := c.httpClient.Do(req) if err != nil { return nil, err } defer func(Body io.ReadCloser) { err := Body.Close() if err != nil { log.Fatal(err) } }(res.Body) responseBody, err := io.ReadAll(res.Body) if err != nil { log.Fatalf("Failed to read responseBody: %v", err) } var response GetSubscriptionResponse err = json.Unmarshal(responseBody, &response) if err != nil { return nil, err } return &response, nil } type PayType string const ( PayTypeCard PayType = "Card" PayTypeBank PayType = "Bank" ) type CreateSubscriptionRequest struct { ID *string `json:"id,omitempty"` PayType PayType `json:"pay_type"` PlanID string `json:"plan_id"` CustomerID string `json:"customer_id"` CardID *string `json:"card_id,omitempty"` PaymentMethodID *string `json:"payment_method_id,omitempty"` StartDate *string `json:"start_date,omitempty"` StopDate *string `json:"stop_date,omitempty"` EndMonthFlag *string `json:"end_month_flag,omitempty"` InitialAmount *string `json:"initial_amount,omitempty"` InitialTax *string `json:"initial_tax,omitempty"` Remarks *string `json:"remarks,omitempty"` ClientField1 *string `json:"client_field_1,omitempty"` ClientField2 *string `json:"client_field_2,omitempty"` ClientField3 *string `json:"client_field_3,omitempty"` } type CreateSubscriptionResponse struct { ID string `json:"id"` ShopID string `json:"shop_id"` PayType PayType `json:"pay_type"` PlanID string `json:"plan_id"` PlanName string `json:"plan_name"` CustomerID string `json:"customer_id"` CardId string `json:"card_id"` PaymentMethodId string `json:"payment_method_id"` Amount int `json:"amount"` Tax int `json:"tax"` TotalAmount int `json:"total_amount"` InitialAmount int `json:"initial_amount"` InitialTax int `json:"initial_tax"` InitialTotalAmount int `json:"initial_total_amount"` Status string `json:"status"` StartDate string `json:"start_date"` NextChargeDate string `json:"next_charge_date"` StopDate string `json:"stop_date"` EndMonthFlag string `json:"end_month_flag"` ErrorCode string `json:"error_code"` ClientField1 string `json:"client_field_1"` ClientField2 string `json:"client_field_2"` ClientField3 string `json:"client_field_3"` Remarks string `json:"remarks"` Created string `json:"created"` Updated string `json:"updated"` } type DeleteSubscriptionResponse struct { ID string `json:"id"` ShopID string `json:"shop_id"` PayType PayType `json:"pay_type"` PlanID string `json:"plan_id"` PlanName string `json:"plan_name"` CustomerID string `json:"customer_id"` CardID string `json:"card_id"` PaymentMethodID string `json:"payment_method_id"` Amount int `json:"amount"` Tax int `json:"tax"` TotalAmount int `json:"total_amount"` InitialAmount int `json:"initial_amount"` InitialTax int `json:"initial_tax"` InitialTotalAmount int `json:"initial_total_amount"` Status string `json:"status"` StartDate string `json:"start_date"` NextChargeDate string `json:"next_charge_date"` StopDate string `json:"stop_date"` EndMonthFlag string `json:"end_month_flag"` ErrorCode string `json:"error_code"` ClientField1 string `json:"client_field_1"` ClientField2 string `json:"client_field_2"` ClientField3 string `json:"client_field_3"` Remarks string `json:"remarks"` Created string `json:"created"` Updated string `json:"updated"` } type GetSubscriptionResponse struct { ID string `json:"id"` ShopID string `json:"shop_id"` PayType PayType `json:"pay_type"` PlanID string `json:"plan_id"` PlanName string `json:"plan_name"` CustomerID string `json:"customer_id"` CardID string `json:"card_id"` PaymentMethodID string `json:"payment_method_id"` Amount int `json:"amount"` Tax int `json:"tax"` TotalAmount int `json:"total_amount"` InitialAmount int `json:"initial_amount"` InitialTax int `json:"initial_tax"` InitialTotalAmount int `json:"initial_total_amount"` Status string `json:"status"` StartDate string `json:"start_date"` NextChargeDate string `json:"next_charge_date"` StopDate string `json:"stop_date"` EndMonthFlag string `json:"end_month_flag"` ErrorCode string `json:"error_code"` ClientField1 string `json:"client_field_1"` ClientField2 string `json:"client_field_2"` ClientField3 string `json:"client_field_3"` Remarks string `json:"remarks"` Created string `json:"created"` Updated string `json:"updated"` } プラン申し込みのケース（1） 月額プラン（￥77,000）月の途中（2024年12月16日）から利用開始申込日から課金開始7日間の無料期間あり 申込日からサブスクリプションを開始するパターンです。7日間の無料期間があるので、課金開始日を1週間後の2024年12月23日に設定します。この場合は毎月23日に課金が行われます。 func main() { client := fincode.NewFincodeClient() // 管理画面から作成したデータのIDを使用 customerID := "c_1xTBQEx5Qz6Xl7DnJ8RqUA" cardID := "cs_sP3jWEe-R-m8cU5fomDLXg" planID := "pl_0iii1LkUS-OBbqQDtajmBg" // 対象月の金額 totalAmount := 77000 // stringに変換 initialAmountString := strconv.Itoa(totalAmount) // 課金開始日を7日後の日付にする(7日間の無料期間を設定) now := time.Now() startDate := now.AddDate(0, 0, 7).Format("2006/01/02") // リクエスト内容を作成 createSubscriptionRequest := &fincode.CreateSubscriptionRequest{ PayType: fincode.PayTypeCard, PlanID: planID, CustomerID: customerID, CardID: &cardID, StartDate: &startDate, InitialAmount: &initialAmountString, } // サブスクリプションの作成 subscription, err := client.CreateSubscription(createSubscriptionRequest) if err != nil { log.Panicln(err) return } // レスポンスを出力 log.Println(subscription) } プラン申し込みのケース（2） 月額プラン（￥77,000）月の途中（2024年12月16日）から利用開始月末課金（当月分を月末に課金）日割り課金あり 日割り課金があるので、初月は残り日数の16日分の、（￥77,000 ÷ 31）× 16 = ￥39,741を課金します。（小数点以下は切り捨てています。）月末課金を行うので、月末課金フラグをONにします。月末課金フラグをONにする場合は、課金開始日を月末の日付にする必要があります。 func main() { client := fincode.NewFincodeClient() // 管理画面から作成したデータのIDを使用 customerID := "c_1xTBQEx5Qz6Xl7DnJ8RqUA" cardID := "cs_sP3jWEe-R-m8cU5fomDLXg" planID := "pl_0iii1LkUS-OBbqQDtajmBg" // 対象月の金額 totalAmount := 77000 // 対象月の日数 now := time.Now() firstDay := time.Date(now.Year(), now.Month(), 1, 0, 0, 0, 0, time.Local) nextMonthFirstDay := firstDay.AddDate(0, 1, 0) targetMonthDays := nextMonthFirstDay.Sub(firstDay).Hours() / 24 // 対象月の残日数(当日を含める) remainingDays := (targetMonthDays - float64(now.Day())) + 1 // 日割り課金金額 remainingTotalAmount := (float64(totalAmount) / targetMonthDays) * remainingDays // int型に変換して端数を切り捨てる initialAmount := int(remainingTotalAmount) // stringに変換 initialAmountString := strconv.Itoa(initialAmount) // 課金開始日を月末の日付にする startDate := nextMonthFirstDay.AddDate(0, 0, -1).Format("2006/01/02") // 月末課金フラグをONにする endMonthFlag := "1" // リクエスト内容を作成 createSubscriptionRequest := &fincode.CreateSubscriptionRequest{ PayType: fincode.PayTypeCard, PlanID: planID, CustomerID: customerID, CardID: &cardID, StartDate: &startDate, InitialAmount: &initialAmountString, EndMonthFlag: &endMonthFlag, } // サブスクリプションの作成 subscription, err := client.CreateSubscription(createSubscriptionRequest) if err != nil { log.Panicln(err) return } // レスポンスを出力 log.Println(subscription) } プラン変更のケース 月額プラン（￥77,000）から月額プラン（￥132,000）にプラン変更2024年11月1日から利用開始申込日から課金開始月の途中（2024年12月16日）にプラン変更日割り課金あり プラン変更は、サブスクリプションの登録と解約を組み合わせて行います。2024年11月1日に利用開始しているので、課金日は毎月1日です。2024年12月16日にプラン変更をするので、変更前のプランの利用期間は2024年12月1日から2024年12月15日で、2024年12月16日から2024年12月31日までの期間の金額は、新しいサブスクリプションの初回利用金額から割り引きます。割引後の金額￥132,000 -（￥77,000 ÷ 31）× 16 = ￥92,258既存のサブスクリプションは、新しいサブスクリプションを登録してから解約処理を行います。 func main() { client := fincode.NewFincodeClient() // 管理画面から作成したデータのIDを使用 customerID := "c_1xTBQEx5Qz6Xl7DnJ8RqUA" cardID := "cs_sP3jWEe-R-m8cU5fomDLXg" planID := "pl_bXTFEfvYTlSOw-ceQGHVVQ" subscriptionID := "su_7uH6dVQbRpiXpLwBg2yvvA" // 変更前のサブスクリプションの取得 previousSubscription, err := client.GetSubscription(subscriptionID) if err != nil { log.Panicln(err) return } // 変更前プランの次回課金日 nextChargeDate, err := getNextChargeDate(previousSubscription.NextChargeDate) if err != nil { log.Panicln(err) return } // 変更前プランの前回課金日 previousChargeDate, err := getPreviousChargeDate(previousSubscription.StartDate, *nextChargeDate) if err != nil { log.Panicln(err) return } // 変更前プランの次回課金日と前回課金日の差の日数 targetDays := nextChargeDate.Sub(*previousChargeDate).Hours() / 24 // 当日の日付 now := time.Now() today := time.Date(now.Year(), now.Month(), now.Day(), 0, 0, 0, 0, time.Local) // 変更前プランの残日数(当日を含めない) remainingDays := nextChargeDate.Sub(today).Hours() / 24 // 変更後の課金開始日は当日の日付 nextStartDate := now.Format("2006/01/02") // 変更前のプランの金額 previousTotalAmount := 77000 // 変更後のプランの金額 nextTotalAmount := 132000 // 変更前のプランの残りの期間の金額 remainingTotalAmount := (float64(previousTotalAmount) / targetDays) * remainingDays // 変更後のプランの金額から変更前のプランの残りの期間の金額を引く nextInitialAmount := float64(nextTotalAmount) - remainingTotalAmount // int型に変換して端数を切り捨てる initialAmount := int(nextInitialAmount) log.Println("initialAmount", initialAmount) // stringに変換 initialAmountString := strconv.Itoa(initialAmount) // リクエスト内容を作成 createSubscriptionRequest := &fincode.CreateSubscriptionRequest{ PayType: fincode.PayTypeCard, PlanID: planID, CustomerID: customerID, CardID: &cardID, StartDate: &nextStartDate, InitialAmount: &initialAmountString, } // 新しいサブスクリプションの作成 subscription, err := client.CreateSubscription(createSubscriptionRequest) if err != nil { log.Panicln(err) return } // レスポンスを出力 log.Println(subscription) //既存のサブスクリプションの解約 deleteSubscription, err := client.DeleteSubscription(subscriptionID) if err != nil { log.Panicln(err) return } //レスポンスを出力 log.Println(deleteSubscription) } func getNextChargeDate(nextChargeDateString string) (*time.Time, error) { t, err := time.Parse("2006/01/02 15:04:05", nextChargeDateString) if err != nil { return nil, err } nextChargeDate := time.Date(t.Year(), t.Month(), t.Day(), 0, 0, 0, 0, time.Local) return &nextChargeDate, nil } func getPreviousChargeDate(startDate string, nextChargeDate time.Time) (*time.Time, error) { // 変更前プランの課金開始日 t, err := time.Parse("2006/01/02 15:04:05", startDate) if err != nil { return nil, err } // 次回課金日の月の初日 firstDayOfNextChargeMonth := time.Date(nextChargeDate.Year(), nextChargeDate.Month(), 1, 0, 0, 0, 0, time.Local) // 次回課金日の前月の最終日 lastDayOfPreviousMonth := firstDayOfNextChargeMonth.AddDate(0, 0, -1) // 次回課金日の前月における課金開始日の日の日付 chargeStartDayOfPreviousMonth := time.Date(lastDayOfPreviousMonth.Year(), lastDayOfPreviousMonth.Month(), t.Day(), 0, 0, 0, 0, time.Local) // 前回の課金日 // 課金日の日付が存在しない場合(30日までの月で31日が課金日の場合など)は、 // 月の最終日が課金日となるので、その場合は最終日を返す。 var previousChargeDate time.Time if lastDayOfPreviousMonth.Year() < chargeStartDayOfPreviousMonth.Year() || lastDayOfPreviousMonth.Month() < chargeStartDayOfPreviousMonth.Month() { previousChargeDate = lastDayOfPreviousMonth } else { previousChargeDate = chargeStartDayOfPreviousMonth } return &previousChargeDate, nil } まとめ 今回はfincode byGMOの使用例についての記事でした。紹介したサブスクリプション機能以外にも、決済機能や請求書機能などがあるので、決済関連で必要な要件はfincode byGMOで一通り実現できると思います。今後決済機能を実装する際の参考にしていただけると良いです。