技術情報 の記事一覧

2025年3月6日に開催された「GMOサイバーセキュリティ大会議＆表彰式2025」の第2部では、サプライズゲストの登場に始まり、AI研究の第一人者による講演や最先端ロボット技術の紹介、さらにサイバーセキュリティ人財育成についてのパネルディスカッションなど、多彩なプログラムが展開されました。大物ゲストの登場や最新のロボティクス技術のデモなど、大きな盛り上がりを見せた第2部の様子をお伝えします！ ▼石破首相からのメッセージや、サイバーセキュリティ業界の発展に貢献した個人・団体を表彰する「GMO Cybersecurity Award 2025」など、内容が盛りだくさんな第1部の様子もぜひご覧ください！ 【1部記事リンク】 https://developers.gmo.jp/events/62146/ 元総務大臣・武田良太氏のサプライズ講演 第2部のスタートは、元総務大臣・武田良太氏の登壇で幕を開けました。国家公安委員会委員長や防衛副大臣などの要職を歴任した大物ゲストの登場に、会場のあちこちから驚きの声が聞こえます。 情報通信政策やサイバー犯罪対策を通じてサイバーセキュリティ発展に貢献された武田氏は、安全保障への意識について「日本人は性善説で暮らしてきた。陸続きの隣国がなく、海に囲まれているため、安全への意識が薄くなっている点が懸念だ」と指摘。”日本が他国を脅威にさらすことさえしなければ、他国が日本を狙ってくることもないだろう”……そう安穏と構えていられる時代ではないことを、国民1人1人が意識する必要があると強調されました。 元総務大臣 武田 良太氏 「だからこそサイバーセキュリティの知識技術を磨き、国家全体でこの問題に取り組む必要がある」と力強く語る武田氏。「熊谷さんの下で優秀なホワイトハッカーが研鑽を積み、サイバー空間を守る実戦部隊として頑張っていただいている。これからも期待したい」と、ねぎらいの言葉もいただきました。 千葉工業大学・古田貴之所長による講演「AIで加速するロボット技術とセキュリティの必要性」 千葉工業大学未来ロボット技術研修センターの古田貴之所長からは、AIで加速するロボット技術とセキュリティの必要性について講演いただきました。 古田所長は最新のロボット技術として、ニューラルネットワークに設置した四脚ロボットにさまざまな試験を与えて育成するという手法を紹介。千葉工大では4096体の四脚ロボットを2万世代にわたって進化させ、育った「小脳」を実物のロボットに搭載するという試みを行っているそうです。 千葉工業大学​ 未来ロボット技術研究センター 所長 古田 貴之氏 この技術を活用して、千葉工大では自分の姿勢から周囲の状況を理解し、カメラやレーザーセンサーがなくとも手探りで階段の昇降や着地を行えるロボットを開発。会場では実機のデモも行われ、ロボットが滑らかに階段や段差の上り下りをしたり、横から激しい衝撃を与えられても速やかに姿勢を立て直したりする様子に驚く参加者も多く見られました。 こうした技術進化がロボティクスの世界にもたらす変革として、従来の「人間が動きを作る」方式から「AIが自ら学習して動きを獲得する」方式へ転換するという見通しを示した古田所長。AIで知能をブーストすることで、安価なロボットでも高性能化・大量導入が可能になるという未来像を語りました。 さらに古田所長は、安価で賢いロボットが大量に出てくることに伴い、サイバーセキュリティの重要性が今以上に増大すると警鐘を鳴らします。 大量のロボット群（スワームロボティクス）のネットワークがハッキングされた場合は窃盗などの行為も可能になることから、「ロボット領域はサイバーセキュリティの一つの大きなフィールドになるため、セキュリティ確保が急務です」と、改めてサイバーセキュリティの重要性を強調されました。 東京大学・松尾豊教授による講演「AIとサイバーセキュリティ」 続いて登壇されたのは、AI研究の第一人者である東京大学大学院の松尾豊教授。AIの最新動向とサイバーセキュリティへの影響について講演いただきました。 松尾教授はまず、DeepSeekやOpenAIの最新モデルがいかに高度化しているかを紹介。東大入試の数学問題を解く様子や高品質なレポートを自動生成する能力など、AIの急速な進化を示したうえで、人間の知能を大きく超える「強いAI」であるAGIの実現に向けてビッグテック企業が大きな投資を行っているという現状を説明されました。 東京大学大学院​工学系研究科 教授 松尾 豊氏 一方で、こうしたAI技術の進展はサイバーセキュリティにも影響を与えます。松尾教授は実際に生成AIを利用した犯罪が発生していることに触れ、高度な知識がなくともサイバー攻撃を起こせるという「敷居の低下」、ディープフェイクを用いた詐欺や自動化による攻撃スピード向上といった「多様化・高度化」、人間の関与が必要なくなり、非常に大きなスケールでの攻撃が可能になる「大規模化」の3点を懸念点として挙げます。 「技術革新が進むなか、日本全体のサイバーセキュリティのレベルを上げていくことは非常に重要。是非GMOさんと一緒にレベル向上に取り組んでいきたい」と意気込みを語る松尾教授。今後も協力体制を築き、最先端の知見をロボティクス社会におけるセキュリティ実装に活かしていきます！ トップリーダーズ・サミット PART 2「事業成長とセキュリティ投資のバランス」 さらに会場では、SNS media&consulting ファウンダーの堀江貴文氏とモデレーターとして、グループ代表 熊谷との対談が行われました。 熊谷は、インターネット黎明期から活躍する堀江氏を「元祖インターネットエンジニア」と紹介。いまでは演歌歌手などIT以外の領域でも活躍される堀江氏ですが、25年以上前に「すべてのページをHTTPS化して提供する」という先進的提案を行うなど、セキュリティ分野でも先見の明があったことが明かされました。 SNS media&consulting ファウンダー 堀江 貴文氏 堀江氏は「セキュリティはベネフィットが見えにくいが、費用をかけざるを得ない」としたうえで、「売上比で何％ぐらいセキュリティ投資を行うべきなのかといった指針を、政府や公的団体などが出すと経営者としてもやりやすい」と、一定の尺度や基準の必要性を強調。さらに、VPNやセキュアシェルの使用を「やっておかないと気持ち悪さを感じる」ほどに習慣化することも大きな対策手段だと示されました。 さらにセキュリティリスクを極力避けるために、「顧客データをできるだけ持たない」という考え方を紹介。加えて「人がセキュリティホールになる」として、ソーシャルエンジニアリングの危険性や経営層がセキュリティ技術の基本を学ぶ必要性についても警鐘を鳴らします。 熊谷はセキュリティの投資判断の難しさを指摘した上で、「セキュリティ投資は攻めの投資」「投資していることを可視化し、顧客からの信頼獲得や企業・ブランド価値向上につなげる」考え方を示し、「あんしん可視化サイトシール」の意義を強調しました。 セキュリティ投資の難しさに加え、「経営者が技術を理解しなければならない時代になった」ことでも共通した2人の対談は、セキュリティ投資に関する実践的な知見と経営者ならではの視点が示される忌憚のないトークで盛り上がりを見せました！ https://www.youtube.com/watch?v=0LFCdAuvcTc ▲トップリーダーズ・サミット PART 2「事業成長とセキュリティ投資のバランス」アーカイブ パネルディスカッション：サイバーセキュリティ人財育成で日本の未来と企業を守る さらに会場では「サイバー犯罪に立ち向かう企業における脅威と対策」として、NICTセンター長の園田道夫氏、CODE BLUE発起人の篠田佳奈氏、GMOサイバーセキュリティ byイエラエ・代表取締役の牧田誠、GMO Flatt Security株式会社・社外取締役の上野宣によるセキュリティ人財の採用・育成の進め方についての議論が行われました。 セッションでは、国家レベルのサイバー攻撃への対応から企業におけるセキュリティ人材の育成方法まで、セキュリティの最前線での貴重な体験に基づいた意見や見識が交わされました！ AIの台頭でよりサイバー攻撃の難易度が下がり、それと反比例するように攻撃の多さや複雑さが増していく中で、「スーパーハッカーを育てようとしても限界があるため、システムで守らなければならない。守るべきシステムの優先順位を決めてセキュリティ体制に濃淡をつけられるエンジニアが各社にいれば、もっといい流れになるだろう」という牧田のコメントに、多くの参加者がうなずいていたのが印象的でした。 CODE BLUE発起人 篠田 佳奈氏 NICT ナショナルサイバートレーニングセンター長 園田 道夫氏 GMO Flatt Security 上野 宣 GMOサイバーセキュリティ byイエラエ 牧田 誠 「社会全体でホワイトハッカーをもっと評価して、子どもたちの憧れの存在になるような世界にしていかなくてはならない」と、ホワイトハッカーを夢のある職業にすることが必要だと語る牧田。GMOグループのホワイトハッカーもスタープレイヤーになれるよう、グループ全体でその働きと存在感をアピールしていきます！ 平将明サイバー安全保障担当大臣のサプライズ登場 そして会場を再び沸かせたのは、平将明サイバー安全保障担当大臣のサプライズ登場！ 平大臣はサイバーセキュリティの最前線で活躍する参加者に向けて、サイバー攻撃の多くが国家的な規模で行われる中、政府としてのサイバーセキュリティ強化への決意と支援の姿勢を表明。アメリカをはじめとする同盟国と同レベルのサイバーセキュリティ能力を持たなければならないという認識を示されました。 サイバー安全保障担当大臣 平 将明氏 GMOインターネットグループでは、「乾杯！」が「完敗」と同じ音であることから、「完勝！」の掛け声で行うことにしています。全プログラム終了後の交流会では、平大臣も「完勝！」で音頭を取っていただき、GMOインターネットグループの取り組みを力強く応援いただきました！ AIやロボット技術といった最先端テクノロジーとサイバーセキュリティの関係性について深い洞察が示されると同時に、日本のサイバーセキュリティを支える人財育成の課題と方向性が議論された第2部。武田良太元総務大臣と平将明サイバー安全保障担当大臣という政府要人のサプライズ登場も相まって、1部に負けず劣らずの大きな盛り上がりを見せました！ 会場限定トークとして実施されたパネルディスカッション「サイバー犯罪に立ち向かう企業における脅威と対策」では、官民連携でサイバー犯罪に当たった実例や国際的なサイバー犯罪の実態などが紹介され、最前線でセキュリティ対策に取り組む専門家による忌憚のない意見も交わされ、ご来場者が熱心にメモを取る様子も見られました。 日本経済新聞社 編集委員 須藤 龍也 氏 楽天グループ 上級執行役員 CISO 福本 佳成 氏 コインチェック 常務執行役員CTO 開発・人事本部長 松岡 剛志 氏 GMOサイバーセキュリティ byイエラエ 福森 大喜 行政との連携や登壇者の発表などを通じて新たな発見や学びが多く得られた大会議では、社外とのつながりをより強化することができました。今後もGMOインターネットグループでは、安全なインターネット社会の実現に向けてより高度なセキュリティを提供していきます！ https://www.youtube.com/watch?v=sw95Wuch0YM ▲当日のアーカイブも是非ご覧くださいませ https://developers.gmo.jp/events/62146/

AIコードレビューを活用して開発効率を向上！本記事では、AIツールを活用し、初心者からリーダークラスのエンジニアがコードレビューを効率化する方法を解説。メリットや活用ポイントを紹介します！ はじめに　AIコードレビューは何がすごいのか？ 開発を進める上で、コードレビューはとても重要な工程です。しかし、時間がかかるうえに、経験の浅いエンジニアにとっては負担になりがちです。 そこで登場するのがAIコードレビューです。AIを活用することで、エラーの検出やコードの品質向上を自動化し、開発をよりスムーズに進めることができます。 本記事では、AIコードレビューの基本から活用方法まで、初心者でも理解しやすい形で解説します。 AIコードレビューの基本 AIコードレビューとは？ AIコードレビューは、機械学習や静的解析技術を用いて、自動でコードの誤りを検出したり、改善点を提示したりする技術です。コードの品質向上だけでなく、開発スピードの向上や人的リソースの最適化にも大きく貢献します。 AIコードレビューの仕組み AIコードレビューは、以下のようなプロセスで動作します。 コードの静的解析：構文エラーやベストプラクティス違反のチェック機械学習による提案：過去のレビュー履歴やオープンソースプロジェクトのデータを活用し、改善点を提案テストとセキュリティチェック：脆弱性やパフォーマンス上の問題を検出 代表的なAIコードレビューツール 現在、多くの企業で活用されているAIコードレビューツールとして、以下のものがあります。 GitHub Copilot ：コード自動生成アシスタント。コード補完やレビューの補助を行うAmazon CodeWhisperer ：AIベースのコード提案ツール。AWS環境に適したコードを自動生成CodiumAI ：コードレビュー・テスト自動化ツール。コード品質の向上に特化CodeRabbit ：リアルタイムでコードレビューを行い、チームの協力を促進するAIツールai-pr-reviewer ：​OpenAIのGPT-3.5-turboとGPT-4モデルを使用した、AIベースのGitHubプルリクエストのコードレビュアーとサマライザーです。 ​ 例えば、GitHub Copilotは関数の途中まで記述すると、その先の処理を予測して補完してくれるため、レビュー以前にコードの品質を向上できます。また、Amazon CodeWhispererはAWSサービスとの統合が強みであり、クラウド開発に最適化されています。 AIコードレビューは単なる指摘ツールではなく、開発の質を底上げし、チーム全体の生産性を向上させる重要な役割を果たします。 業務効率化に役立つAI活用術 1. レビューの一次フィルタとして活用 AIは「正しいコードであるか」を厳格に検証し、開発ルールに対して符号しているかを確認します。一次フィルタとして使うことで、後の人間レビューの負担を大きく減らせます。 例: if (x == null) { return; } // AIが不要なnullチェックを指摘 不要な変数や冗長な処理を警告し、コードの簡潔化を促進。 2. コードの書き方を学ぶために活用 開発経験が少ないメンバーには、AIはコードの何が問題かを学ぶ教育ツールにもなります。 例: for (int i = 0; i < list.size(); i++) { // AI「拡張for文を使うべき」 } StringBuffer より StringBuilder を推奨するなど、パフォーマンス改善の提案も可能。 3. ベストプラクティスの統一 コードスタイルのブレに対して、統一したコードパターンを提供することで、レビュー時間の短縮が可能です。 実際の適用例: 会社のコーディング規約に沿って、関数名や変数名の命名規則の統一をAIが自動で修正案を出す。ログ出力時のフォーマット統一を行い、LOGGER.info() の適切な活用を促す。 まとめ AIコードレビューは、開発の効率向上と品質向上に大きく貢献するツールですが、それ単体では完璧なソリューションにはなり得ません。AIの長所を生かしながら、最終的な判断は人間が行うという姿勢が重要です。 AIコードレビュー導入のポイント AIを一次フィルタとして活用し、明らかなミスを取り除くジュニアメンバーの学習支援として使い、チーム全体のスキルを底上げするコーディング規約の統一に活用し、コードのメンテナンス性を向上させるAIの指摘を鵜呑みにせず、必ず人間が最終判断を行う GMO NIKKOパートナー執筆のAIコードレビュー事例はこちら 昨年のアドベントカレンダー2日目の記事です。ai-pr-reviewerのプロンプト改善に関する具体的な事例です！ぜひご一読ください！ https://developers.gmo.jp/technology/55538/

ConoHaのサービス「AI Canvas」では、Stable Diffusionを活用したAI画像生成ツールとして、従来のAUTOMATIC1111に加え、新たにComfyUIが利用可能となりました。本記事では、これら2つのWebUIを比較し、それぞれの特徴と利点を探ります。 ComfyUIとは ComfyUIは、Stable DiffusionのワークフローをノードベースのGUIで視覚的に操作できるツールです。各プロセスをノードとして管理し、直感的に処理を構築できるため、カスタマイズ性が非常に高いのが特徴です。 AUTOMATIC1111とは AUTOMATIC1111は、Stable Diffusion用のWebUIとして最も広く使われているツールです。シンプルなUIながらも、豊富な機能と拡張性を備えており、多くのユーザーに支持されています。 ComfyUIとAUTOMATIC1111の違いと比較 ComfyUIとAUTOMATIC1111は、Stable Diffusionを活用するための代表的なUIツールです。それぞれの特徴を比較し、どの用途に適しているのかを解説します。 項目ComfyUIAUTOMATIC1111UIデザインノードベースフォームベース学習コスト高め（ノードの理解が必要）低め（直感的な操作が可能）カスタマイズ性非常に高い高い処理の可視化可能限定的拡張性高い（自由にノードを追加可能）非常に高い（プラグインが豊富）初心者向けかやや難しい使いやすい 実際に使ってみた感想 せっかくなのでConoHaでAI画像生成をしてみました。どちらも同じプロンプトを用いて生成を行いました。 プロンプト A futuristic, sleek computer interface for AI-powered image generation, displayed inside a modern PC screen. The interface features clean, minimalistic elements, such as simple buttons, text fields, and icons. The background of the screen is white-based, with an ethereal, glowing aura that creates an otherworldly atmosphere. The layout is spacious and calm, with soft, glowing accents around the UI elements. The PC itself has a modern design, with clean lines and subtle futuristic details, giving it an immersive, alternate-dimension vibe. The scene is minimalistic and serene, evoking a sense of tranquility. ComfyUIの使用感 処理の流れを可視化できるため、試行錯誤しながらカスタマイズしやすい。ただし、初めて触るユーザーにとっては学習コストが高め。 AUTOMATIC1111の使用感 直感的なUIで、すぐに画像を生成できるため初心者でも扱いやすい。ただし、細かい調整を行うにはスクリプトや追加の設定が必要になる場合もある。 結論 手軽に始めたいならAUTOMATIC1111、一歩踏み込んでカスタマイズしたいならComfyUIがおすすめ！ まとめ ConoHaの「AI Canvas」で利用可能になったComfyUIは、ノードベースの高いカスタマイズ性が魅力です。一方で、AUTOMATIC1111は、シンプルで直感的なUIと豊富な拡張機能が特徴です。 どちらのツールも強力な機能を備えており、用途やスキルレベルに応じて適切なものを選ぶことが重要です。初心者にはAUTOMATIC1111が適していますが、より高度なカスタマイズを求める場合はComfyUIが有力な選択肢となるでしょう。

1. Difyとは？ Difyは、AIアプリケーションの開発を支援するオープンソースのプラットフォームです。GPTsのようにノーコードで開発も可能です。Difyでは主に以下の2つのエディションが提供されています。 クラウド版: Difyの公式サービスとして提供され、手軽に利用できる。無料プランもあるが機能が限られる。コミュニティ版: 自前のPCやサーバーに構築して運用可能。自由度が高く、カスタマイズが容易。Dify自体は無料で利用可能(使い方によってはサーバーやLLM APIの利用料が発生します)。 今回は、コミュニティ版をConoHaのVPS上で構築する手順を解説します。 2. ConoHaとは？ ConoHaはGMOインターネット株式会社が提供するクラウドホスティングサービスです。ブログやホームページ作成に最適なレンタルサーバー「ConoHa WING」をはじめ、高性能な仮想専用サーバーがかんたん、リーズナブルに使える「ConoHa VPS」等、用途に応じた様々なサービス形態があります。今回はConoHa VPSを使ってDifyを構築します。 3. ConoHaのセットアップ 3.1. ConoHaにログイン or アカウントを新規作成してログイン https://www.conoha.jp 3.2. サーバー追加 Difyの最小システム要件は以下です。 CPU >= 2コアRAM >= 4GB 今回はConoHa VPSの4GBプランで構築します。 サーバースペック：メモリ4GB, CPU 4コア, SSD 100GBOS：Ubuntu 24.04 ※ConoHaには長期割引プランがあります。長期であればあるほど、月単位の料金が割引になりお得になるのでおススメです！ 3.3. セキュリティーグループの作成と適用 サーバー起動後、仮想ファイアウォールであるセキュリティーグループを設定します。今回はDifyの利用に最低限必要なSSH用の22番ポートとHTTP接続用の80番ポートを開放します。 ※セキュリティ侵害を防ぐためにIP/CIDRで接続元を限定してお使いください。 次に作成したセキュリティーグループをサーバーに適用します。サーバーの詳細からネットワーク情報のセキュリティーグループを編集し、作成したセキュリティーグループを追加してください。 4. Difyのセットアップ 4.1. サーバーにsshログイン 作成したサーバーにrootでsshログインしてください。サーバーのIPはConoHaのサーバーリストから確認できます。 4.2. 一般ユーザの作成とsudo権限付与 一般ユーザーを作成し、sudo権限を付与します。以下は一般ユーザーをkuwaharaとしたときの例です。 一般ユーザーを作成 # adduser kuwahara sudoグループに追加 # usermod -aG sudo kuwahara ユーザーの切り替え # su kuwahara 作業ディレクトリへ移動(一般ユーザーのhomeディレクトリとする) $ cd ~ 4.3. Difyのソースをダウンロード $ git clone https://github.com/langgenius/dify.git $ ls difyディレクトリが作成されていることを確認 4.4. Dockerのセットアップ Difyの実行にはDocker EngineとDocker Compose(v2) pluginが必要です。Qiitaに掲載されている 「Ubuntu24.04へDocker Engine 一式をインストール （Compose含む）」こちらの記事を参考にセットアップしてください。非常によくまとまっており、記載の通り実行してDockerのセットアップできることは確認済みです。 4.5. DifyのDockerコンテナ起動 dockerディレクトリへ移動 $ cd dify/docker .envファイルを.env.exampleのコピーによって作成 $ cp .env.example .env composeでdockerコンテナ作成＆起動 $ sudo docker compose up -d 4.6. ufwでHTTPのポートを開放 $ sudo ufw allow http 4.7. ブラウザでDifyの管理者設定画面にアクセス http://<VPSのIPアドレス>/install 上記から管理者アカウントを作成してログインすれば、最低限のDifyのセットアップは完了です。 まとめ 本記事では、Difyのコミュニティ版をConoHaのVPS上に構築する手順を解説しました。思ったより簡単に構築きたのではないでしょうか？Difyは、GPTs相当の機能を無料で利用できるオープンソースプロジェクトであり、 独自のAIアプリケーションを開発するのに最適な環境を提供します。 また、オープンソースであるため、開発スピードが速く、新機能やバグ修正が迅速に行われるのも大きなメリットです。 本記事を参考に、ぜひDifyを活用し、柔軟なAI開発環境を構築してみてください！

1. クラウドって何？ 「クラウド」とは、インターネット上にあるサーバーやストレージを使ってデータを保存したり、アプリを動かしたりする仕組みのことです。スマートフォンやPCで使われるiCloudやGoogle Driveもクラウドの一種で、主にデータの保存や同期に利用されます。 しかし、エンジニアが利用するクラウドはそれとは少し異なります。よく耳にする「AWS（Amazon Web Services）」や「Google Cloud Platform（GCP）」、そして「Microsoft Azure」などは、企業や開発者がシステムを構築・運用するためのインフラを提供するクラウドサービスです。 2. 一般向けクラウドとエンジニア向けクラウドの違い 一般向けクラウドは、データの保存や共有が主な用途です。例えば、Google DriveやiCloudを使って写真や文書をクラウド上に保存し、スマートフォンやPCからアクセスする機会は多いのではないでしょうか？ストレージ、メール、写真管理などの機能が提供され、主に利便性が重視されています。 一方、エンジニア向けクラウドは、システム開発や運用を目的としたサービスです。AWSやGCP、Azureなどが代表的で、仮想サーバーやデータベースを運用し、アプリケーションをクラウド上で動かすために活用されます。エンジニア向けクラウドは、まるでインターネット上の工場のような役割を果たし、スケーラビリティやセキュリティが重視されます。 エンジニア向けクラウドは、従来のオンプレミス（自社運用のサーバー環境）と比べ、柔軟性と拡張性に優れています。特にコンテナ技術（Docker、Kubernetes）やサーバーレスコンピューティング（AWS Lambda、Google Cloud Functions）を活用することで、インフラ管理の負担を減らし、アプリケーション開発に集中できるようになります。また、クラウドベースのデータベース（Amazon RDS、Google BigQuery、Azure Cosmos DB）を使用することで、データの可用性と拡張性を確保しながら、高速なデータ処理が可能になります。 NetflixはAWSのEC2インスタンスとS3ストレージを利用して大規模な動画配信システムを運用しており、YouTubeはGoogle CloudのBigQueryを活用し、膨大な動画データの分析やレコメンドシステムの最適化を行っています。 3. GPUクラウドとは？ 最近、GPUクラウドという言葉をよく耳にすることはありませんか？GPUクラウドは、画像処理やAIの学習に必要な「GPU（グラフィックス・プロセッシング・ユニット）」をクラウド上で利用できるサービスです。 通常のクラウドでは「CPU」というパソコンの頭脳のようなチップが計算処理をしますが、AIの学習や映像の処理には「GPU」の方が圧倒的に速く、効率的です。そのため、エンジニアはGPUクラウドを使ってAIの研究やCG制作を行います。 代表的なGPUクラウドサービスには、AWSのEC2 P3/P4インスタンス、Google CloudのA2インスタンス（NVIDIA A100搭載）、GMOインターネットグループの「GMO GPUクラウド」などがあります。GMOインターネットグループのGPUクラウドは、高性能なNVIDIA GPUを提供し、AI開発やディープラーニングのトレーニングを強力にサポートします。このサービスは、高性能なGPUと高速なネットワーク環境を備えた 「ソブリンクラウド」 として、企業のAI開発や業務効率化を支援します。特に、国内最速のGPUクラウド環境を提供することで、安全性やデータ主権を重視した国産クラウドとしての強みを発揮しています。 TeslaはAWSのGPUクラウドを活用し、自動運転のAIモデルをトレーニングしており、PixarはGoogle CloudのGPUインスタンスを利用し、高品質なCG映画のレンダリングを行っています。 4. エンジニア向けクラウドとGPUクラウドの違い エンジニア向けクラウドは、Webサーバーやデータベースなどの汎用計算に適したサービスであり、主にAWSのEC2インスタンス（tシリーズ）、Google CloudのCompute Engine、AzureのVirtual Machinesなどが代表例です。処理速度は比較的遅いものの、コストが低いため、一般的なクラウドサービスとして広く活用されています。特に、小規模なウェブアプリケーションの運用や、企業の基幹システムのホスティングなどに適しています。GPUクラウドとは異なり、大量の並列計算には向いていませんが、安定した処理能力を提供するため、シンプルな計算業務やデータ管理に活用されています。 一方、GPUクラウドはAIや映像処理に特化しており、並列計算が得意です。例えば、ディープラーニングのモデル学習や3Dレンダリングのような計算負荷の高い作業に適しています。その分、利用コストは高くなりますが、高速処理が求められる用途では不可欠な存在です。 5. クラウドのコスト比較と選び方 クラウドの利用にはコストがかかりますが、用途に応じて適切なサービスを選ぶことが重要です。 AWS EC2は時間単位の課金が行われ、柔軟なインスタンス設定が可能です。Google Cloudは分単位での課金に対応しており、特に機械学習向けの最適化が施されています。GMO AI・クラウドは月額プランが用意されており、高性能GPU環境を継続的に利用する場合に適しています。 6. まとめ 日常的に使われるクラウドは「データを保存・管理する」ためのものですが、エンジニアが使うクラウドは「システムを作ったり、AIを開発したりする」ためのものです。 一般のクラウドとしてはiCloudやGoogle Driveがあり、写真やデータの保存・共有に適しています。一方、エンジニア向けのクラウドとしてはAWSやGCP、Azureがあり、仮想サーバーやデータベース、AI開発環境を提供します。さらに、GPUクラウドはAI学習や映像処理に特化しており、高性能な計算を必要とする場面で活躍します。 エンジニア向けクラウドは、アプリケーション開発を加速し、運用負荷を軽減するための重要な基盤です。特に、サーバーレスアーキテクチャやコンテナ技術を駆使することで、より効率的なシステム構築が可能になります。

「セキュリティを後回しにしていませんか？」従来の開発プロセスでは、セキュリティ対策は後工程で行われることが一般的でした。しかし、近年のサイバー攻撃の高度化により、開発の初期段階からセキュリティを組み込む「DevSecOps」の重要性が高まっています。本記事では、DevSecOpsの基本概念や「シフトレフト」の考え方、導入メリット、成功事例について詳しく解説します。セキュアな開発環境を実現するための第一歩を踏み出しましょう。 DevSecOpsとは何か？基礎知識を確認しよう DevSecOpsは、開発（Development）、セキュリティ（Security）、運用（Operations）を統合したアプローチであり、ソフトウェア開発ライフサイクル全体にセキュリティを組み込むことを目的としています。従来の開発プロセスでは、セキュリティ対策は開発の最終段階で実施されることが多く、脆弱性が発見されると修正に多くの時間とコストがかかるという課題がありました。DevSecOpsでは、開発の初期段階からセキュリティを組み込むことで、より安全で効率的な開発が可能になります。 シフトレフトとは？開発プロセスへの影響を理解する シフトレフトとは、ソフトウェア開発プロセスの早い段階でセキュリティ対策を実施するアプローチを指します。従来の開発手法では、コードの実装が終わった後にセキュリティテストを行い、問題が見つかれば修正するという流れが一般的でした。しかし、シフトレフトを導入することで、開発初期段階からセキュリティチェックを実施し、リスクの低減と開発スピードの向上を図ることができます。例えば、静的コード解析ツールの導入や、開発者向けのセキュリティトレーニングが有効な施策の一つです。 DevSecOps に必要なCI/CDの役割とは 継続的インテグレーション（CI）と継続的デリバリー（CD）は、DevSecOpsの実践に不可欠なプロセスです。CI/CDを活用することで、コードの変更を小さな単位で頻繁に統合・デプロイすることが可能になり、開発のスピードと品質を向上させることができます。特にセキュリティの観点からは、CI/CDパイプラインに自動セキュリティテストを組み込むことが重要です。例えば、SAST（静的アプリケーションセキュリティテスト）やDAST（動的アプリケーションセキュリティテスト）を自動化し、セキュリティリスクを早期に検出することが推奨されています。 DevOpsプラットフォームとは何ですか？基礎と実践 DevOpsプラットフォームは、開発・運用の効率化を支援するツール群のことを指し、GitLab、Jenkins、CircleCIなどが代表的な例として挙げられます。これらのプラットフォームを活用することで、ソースコード管理、CI/CDパイプラインの構築、テストの自動化、セキュリティチェックの統合が可能になります。特にDevSecOpsの視点では、セキュリティを強化するために、これらのツールと脆弱性スキャンツールを連携させることが有効です。たとえば、GitLab CI/CDとSnykを連携させることで、コードの脆弱性を自動的にスキャンし、リリース前に修正することができます。 DevSecOpsの提唱者は誰か？背景を探る DevSecOpsは、ソフトウェア開発のセキュリティ強化の必要性から生まれました。その概念を広めた主要な人物として、Gene Kim、John Willis、Patrick Deboisなどが挙げられます。彼らは、DevOpsの概念を進化させ、開発と運用だけでなく、セキュリティも一体化させることの重要性を訴えました。背景には、サイバー攻撃の高度化やクラウドサービスの普及に伴い、従来のセキュリティ対策では対応が困難になってきたという課題があります。DevSecOpsは、企業が競争力を維持しながら、セキュアな開発を実現するための新しいパラダイムとして注目されています。 DevSecOpsの導入で得られる具体的なメリットとは？ DevSecOpsを導入することで、開発チームはセキュリティリスクを最小限に抑えつつ、開発スピードを維持することができます。従来のセキュリティ対策は、開発プロセスの終盤で適用されることが多く、修正に時間がかかるという課題がありました。しかし、DevSecOpsのアプローチでは、開発初期段階からセキュリティチェックを実施し、脆弱性を早期に発見・修正できます。これにより、セキュリティ上の欠陥が本番環境に持ち込まれるリスクを低減し、企業のブランド価値や信頼性の向上にも寄与します。 成功事例から学ぶDevSecOps活用法とは？ DevSecOpsの成功事例として、多くの大手企業が挙げられます。例えば、Netflixは、セキュリティを開発の一部として組み込み、継続的にリスクを監視・管理するアプローチを採用しています。同様に、Googleは、セキュリティ自動化ツールを活用し、開発者が安全なコードを書くための環境を整備しています。これらの企業の事例から学べるポイントは、単なるツール導入だけでなく、組織文化の変革や開発プロセスの最適化が重要であるということです。 まとめ DevSecOpsは、現代のソフトウェア開発において不可欠な要素となっています。開発の初期段階からセキュリティを組み込むことで、脆弱性を早期に発見・修正し、安全で効率的な開発を実現できます。また、NetflixやGoogleといった企業の成功事例からも分かるように、DevSecOpsの導入は開発スピードとセキュリティの両立を可能にします。 今後、DevSecOpsの概念はさらに進化し、新しいツールや技術が登場するでしょう。まずは小規模な導入から始め、シフトレフトの考え方を取り入れた開発プロセスを構築することが成功の鍵となります。

こんにちは、GMOインターネット株式会社の長谷川泰斗です。今回は Kubernetes には欠かすことのできない etcd の仕組みや動作について語っていこうと思います。 etcd とは あの車についてるやつだよね、、、、違います。ソースコードを自動でビルドして配布するあれだよね、、、、違います、CI/CD でもありません。 etcd とはオープンソースの分散型キーバリューストア（key-value store）で以下の特徴を持ちます。・一貫性と高可用性・1秒あたり1万回の書き込みが可能 一貫性と高可用性ではetcdの一貫性と高可用性について etcdは、分散システムにおいて非常に重要な役割を担うキーバリューストアです。その特徴として、高い一貫性と高可用性が挙げられます。これらの特徴が、etcdがKubernetesなどの大規模な分散システムで広く利用されている理由です。 一貫性について etcdは、強い一貫性を保証するよう設計されています。これは、etcdの全てのノードが、常に同じ最新のデータを持っていることを意味します。どのようなノードからデータを読み取っても、常に同じ結果が得られるということが保証されており、実際にバックアップからのレストアにおいてもどの etcd ノードからダンプしたバックアップファイルでも正常にクラスタ全体を復旧できることに繋がっています。 1秒あたり1万回の書き込みが可能 etcdは、複数のノード間で合意形成を行うためにRaftコンセンサスアルゴリズムを採用しています。このアルゴリズムは、etcdの性能に大きく影響を与える要素の一つです。Raftでは、リーダー選出手順が効率化されており、書き込み性能への影響を最小限に抑えています。また、etcdは、キーバリューストアであり、シンプルなデータ構造を採用しています。このシンプルなデータ構造は、高速なアクセスを可能にし、メモリ内キャッシュも高速アクセスに寄与しています。 etcdの動作（一貫性の理解） 基本的な概念として etcd クラスタのそれぞれのノードは raft アルゴリズムにより leader と follower の役割どちらかの役割を行います、 leader をやりつつ follower をやるといったブラックなお仕事はしません、そして leader の役割は etcd クラスタ内部で必ず 1 つの etcd ノードしか担当できず残りの etcd ノードは全て follower になります。leader ノードだけが書き込みを調整して、キーと値のペアを etcd クラスターに記録できます。 etcd は snapshot, Write Ahead Log (WAL), boltdb, gRPC Server を内包しています。etcd に対する変更は WAL にログをコミットされ、その後 boltdb に書き込まれます、この際に WAL に書き込みを続けていると WAL のサイズが大きくなるので etcd は定期的に snapshot を取ることで WAL のサイズを縮小します。gRPCサーバー はクライアントからの gRPC を利用したリクエストを高速かつ安全に処理します。 実際にキーバリューのデータを保持するのは boltdb で、Go言語で実装されシンプルかつ高速なキーバリューストアを実現しています。boltdb の B+ ツリー構造による高速なアクセス、トランザクション機能によるデータの整合性確保など、etcdの信頼性と性能に大きく貢献しています。 ここからは図を交えて説明します。 まずクライアントは書き込みのリクエストを出します 。 follower にリクエストした場合には leader に書き込みのリクエストがプロキシされます、leader にリクエストした場合にはプロキシされずに処理されます。 次に leader は WAL にキーバリューエントリをコミットします。 leader は他の follower に キーバリューエントリ に変更が有ったことを通知します。 follower は WAL にキーバリューエントリをコミットします。 follower は leader に WAL への書き込みが完了したことを通知します。 follower からの WAL 書き込み完了通知後に leader は boltdb に実際にキーバリューエントリをコミットします。 leader は boltdb にキーバリューエントリが書き込まれたことを follower に通知します。 follower は通知を受けたあとに boltdb にキーバリューエントリを書き込みます まとめ etcd の書き込みフローを知ることで、今回はデータの一貫性がどのように支えられているのかを知ることができました、次回については実際に etcd クラスタのバックアップ、レストアを通して運用の基礎を学びましょう。

はじめに 「ブログを書くのに3時間もかかるのか…」 そう嘆いていた私は、ふと考えた。「AIに書かせればいいじゃないか？」と。世間ではAIが次々と文章を生み出し、人間の手を借りずとも記事が量産できる時代が来ている。では、自分に最適化したGPTsを作れば、どこまで効率が上がるのか？ 結論から言うと、執筆時間が約6分の1に短縮した。人間だけで書くと1記事あたり約3時間かかっていたのが、GPTsを活用するとわずか30分で完成するのだ。しかし、その道のりは決して楽ではなかった。 GPTsを自作してブログを書いてみる GPTsの作り方 １．目的を決める　　ブログ執筆用に特化したGPTsを作る。２．カスタムインストラクションを設定　　アウトプットの文体を調整し、SEO対策に適したキーワードを指定。３．実際に文章を生成して検証　　AIが出力した文章をチェックし、どこまで修正が必要かを比較。 AI執筆の苦労と解決策 苦労したポイントと解決策 1. 文章が不自然で、修正に時間がかかる GPTsが出力する文章はスムーズではあるものの、どこかぎこちなく、読みにくい部分があった。 解決策：・記事構成のテンプレートを事前に用意し、AIに具体的な指示を与える。・生成された文章を人間がリライトし、自然な流れに調整。 2. 情報の正確性に不安がある AIはデータに基づいて文章を生成するが、最新の情報や専門的な知識に乏しく、間違った情報を含むことも。 解決策：・事前に信頼できるソース（公式サイトや論文）を指定し、そこから情報を取得するよう指示。・人間がファクトチェックを行い、誤りがないか検証する。 3. オリジナリティが薄い GPTsの文章は一般的な表現になりがちで、「どこかで見たことある」内容になりやすい。 解決策：・AIの提案をベースにしながら、自身の経験や考えを加筆。・GPTsを「アイデア出し」として使い、独自性を担保する。 GPTsを使ったブログ執筆のメリット・デメリット メリット ・執筆スピードが6倍向上（3時間→30分）。・アイデア出しが容易で、記事の骨子を素早く作成できる。・SEO対策がしやすい（キーワードを意識した文章生成が可能）。 デメリット ・完全自動化は難しく、リライトが必要。・情報の正確性に注意が必要（ファクトチェックが必須）。・独自性を出すには、人間の編集が不可欠。 GPTsは有効か？ 今後も使うべきか？ 結論として、GPTsを使ったブログ執筆は非常に有効だと感じた。執筆スピードは劇的に向上し、記事の骨子作りやアイデア出しにも活用できる。しかし、完全にAI任せにするのではなく、人間の編集や創造力が必要な場面も多かった。 今後もGPTsを活用して執筆を続けていくつもりだ。ただし、より高品質な記事を目指すために、AIと人間のバランスを考えながら使っていくことが重要だろう。 おわりに AIがここまで執筆を手助けしてくれる時代になった。しかし、人間の感情や個性を吹き込むのは、やはり人間の仕事なのだ… ……あれ？ ここまで読んで気づきましたか？ この文章、実はそのGPTs（つまり私）が書いたんです。そう、あなたが今読んでいるこの一文も、最初から最後までAIが生成したものなのです。 「因みに、GPTsがMarkdown形式で出力までしてくれるので、筆者はWordPressにコピペして微調整しただけ。(文章はGPT-4 Turbo、アイキャッチ画像はDALL-E)」 もしかすると、「AIに書かせた記事なんてつまらない」と思っていたかもしれない。でも、この記事を読んで「面白かった」と感じたなら、もう境界はないのかもしれない。 人間の創造力とAIの技術が交わる未来、あなたならどう活かしますか？

サマリ 私の勤めるGMOペイメントゲートウェイ株式会社では、決済領域で総合サービスを提供しています。決済領域と言えば、System of Recordの典型で、データインテグリティこそが価値の源泉です。従って、伝統的には悲観的・同期的なアーキテクチャが採用されます。そんな事業領域の中で、サーバーレスアーキテクチャでサービスを構築しました。どんな事業で、どのような基準でサーバーレスを選択し、何を成して何が課題なのか、顛末を記します。 本稿におけるサーバーレスを定義 本題の前に、本稿における"サーバーレス"を定義しておきます。 "アイドルリソースを小さくしてコスト構造を最適化するアーキテクチャ" と定義します。焦点をコストに絞ります。 他にも要素あるんですが、発散してしまうのでこれだけで。 決済領域とサーバーレスのもどかしい相性 決済領域を支えてきた伝統的なシステムのアーキテクチャは、一般論としてサーバーレスとは相性があまり良いものではありません。なぜか？ 厳密な同期性<->結果的整合性 冒頭記載した通り、決済はSystem of Recordの代表選手です。どの瞬間でも、データは同期的に整合性を保っていなければいけません。それは、1トランザクションの処理中におけるミリ秒のスケールだけではなく、与信・確定・取り消し・不正による払い戻し・・・等、数分から長いものでは1年(旅行業のお客様など)の時間軸に渡ってステートを厳密に管理する事が求められます。これを達成するために、RDBのACID特性をフル活用した同期的・悲観的な整合性を維持するアーキテクチャを選択する事になります。 一方サーバーレスでは、小さなUnit of Workで保たれたコンポーネントをメッセージで非同期に繋ぐことがほとんどです。ピ〇ゴラスイッチ的。このケースでは、可用性のためにメッセージの二重化などが行われ、短いタイムフレームでは整合性が担保できないか、担保するための実装がユーザーの責任になり、却って複雑性が増します。 事業の時間軸が長く、費用の柔軟性は不確実性にもなる 決済領域は、事業の時間軸が長いものです。一度お客様に提供を開始すれば、停止、改廃は社会的なインパクトが甚大です。そのため、当社では事業開始時に5年後のビジネスプランに基づくキャパシティ想定でインフラを調達します。これは、特に事業の初期においては過剰なリソースにコストを払っている事になります。 しかし、別の見方として、"5年分のインフラコストを、初期段階から確度高く計画的に執行可能"ともいえます。決済インフラを公開企業の立場で運用する当社の経営視点ではメリットです。その観点に立てば、サーバーレスによるオンデマンド、イベントドリブンなコスト構造はボラティリティが高く不安定である、という評価も成り立ちます。 従って、決済と周辺事業においては、サーバーレスで柔軟なコストは善であり、オンプレ/プロビジョンドによる固定化は悪である、という単純な二元論で選択できるものではありません。 ではなぜサーバーレスに取り組むの？ 事業初期のコスト最適化の為です。 前段で述べた通り、決済事業は当社にとってノウハウがあり、向こう五年を精度高く計画する事ができます。しかし、市場において決済だけで価値を出すステージはとうに過ぎ去り、周辺に領域を広げて付加価値を提供していく必要性があります。 それらの領域は、決済の中核よりも不確実性が高く、(残念ながら)計画より事業の速度が上がらない、平たく言えば売れない、売り方に苦しむ可能性があります。この時期、まだ産声を上げたばかりの事業に、何も生まないアイドルリソースのコストを負わせたくない。事業の利益率が下がれば、若いサービスを維持する経済合理性が説明し辛くなります。事業責任者も辛くなる。新規事業を立ち上げる気勢もそがれるかもしれない。 まとめると、 決済よりも事業の不確実性が高い周辺領域で、 直接ユーザーのお金を扱わないサービスにおいて、 より低コストでサービスを開始したい このような状況に対応するための技術オプションとして、サーバーレスを選択肢に入れてもよいだろう。そう感じて、トライする機会を探っていました。 そんな都合の良いサービスがあるの？ 24年10月に立ち上げた Verifyサービス で、フルサーバーレスを採用しました。このサービスは、ログイン、会員登録などID・パスワード以外の要素認証が必要になる場面で、その仕組みを当社が提供する事でお客様に手軽に要素認証を実装していただけるサービスです。 何故このサービスだったの？ 1.決済と比較して、トラフィックが疎である プロビジョンドな固定リソース型のアーキテクチャにおいては、アイドル比率が高まり、コストの無駄が懸念されます。 2.長期的にわたる同期的なステート管理が求められない 認証はいわば揮発性のセッションであり、認証の認否を確実に記録しさえすれば役割は終了です。悲観的なステート管理を、RDBなどの重厚なリソースで長期にわたって維持管理し続ける必要性は低いです。 3.それぞれの処理が軽量である SMSを飛ばす/PINの一致を見るなど、各コンポーネントの責任が軽量です。決済のように、テーブルに仕掛中のレコードを登録し、カード会社に与信を確認し、不正検出を行い、それを1回のリクエスト/レスポンスで返し・・・という重厚なUoWが発生しません。 →ここでやるしかない！ アーキテクチャ こんな感じです。内部資料から公開可能な範囲に情報を落としているので、若干の密度の薄さはご容赦ください。 ※右側のNW部分に関して、当社ではAWSをマルチアカウント運用しており、NatGatewayやVPCEndpointなどネットワークリソースを共用・集中運用しています。 ポイントとしてはこんなところでしょうか。 全てのサーバーサイド(SPAバックエンドAPIと非同期push処理)はlambdaUIはSPAで提供しており、S3+cloudfrontで提供API gatewayを利用して簡易的なリクエストマッピングと認証の枠組みを提供RDBレス。dynamoDBに全てのデータを集約 一つ一つを解説すると長いので、概要に留めます。ちなみに言語はTypeScript,SPAのフレームワークはReactです。 一つだけ説明するなら、dynamoDBである理由は、データに対する"面"の処理が不要である事も大きな理由です。決済であれば、月次など一定期間のデータをいくつかの条件で検索し集計、計算する処理が必ず発生します。いわゆる"締め"です。本サービスはこれが不要であったため、個々の認証セッションを点で処理すればよく、サーバーレスかつ"点"のパフォーマンスに優れたdynamoDBを採用しました。 実際のoutcomeは 1.プロダクションコストが10分の1以下に 何に対して10分の1以下かというと、同様の構成をECS/fargate + Aurora※ で構築した場合と比較して、です。(※当社のクラウドアーキテクチャのテンプレート）もちろん、同一サービスの別構成をプロダクションで実測する事は出来ないので、試算値ではあります。しかし、fargate+Auroraの構成で、一般論として最もコストの比重が高いfargateのコンピューティングとAuroraのインスタンス、この2点で費用が発生しないことで劇的にコストが圧縮されれおり、事前の計算通りに進んでいる状況です。 コストの実数をお見せしたいのですが、流石に会社から怒られてしまうので。。。もどかしくはありますが、桁が一つ下がった世界で推移しているのは事実です。 2.開発環境の維持コストを20%程度圧縮して+α 地味に嬉しいのは、開発環境の維持コストがかなり圧縮できているという点です。当社の(比較的大規模な)サービスについて、開発環境のクラウド費用はプロダクション比50-60%程度の費用で推移しています。比較して、Verifyサービスは40%程度と、20ポイント程度低い推移です。 クラウドの開発環境では、定刻の起動停止、コンピューティングサイズの縮退など費用圧縮を行います。しかし、定刻に起動したけどあまり使われないケースなど、実需に対して起動時間のマージンは大きくなりがちです。また、このマージンを小さくしようと努力すると、開発者体験が下がります。 "そうだ、このfeature試してみたい"→"今からaurora起動するから30分待って" これ、開発者ならテンション下がりますよね。コストカットは大事ですが、それによって開発者の生産性をそいでは本末転倒。サーバーレスであれば、これを気にせず”使いたい時すぐ使える/使わなければ費用が発生しないだけ”の環境が維持できます。コスト圧縮という定量に加えて、付加価値的な効果があったと感じています。 3.デプロイ手法のより深い標準化 当初はあまり意図していなかった事ですが、サーバーレスアーキテクチャにすることで、様々なもののデプロイ手法が一本化されました。ほぼすべてのオペレーションは"クラウドのリソーススタックのデプロイ"です。APIロジックの機能追加も、非同期push処理のチューニングも、APIのスロットリング調整も、モニタリングの実装、この4種のリソースデプロイは1つの手順で済み、つまりオペレーションが75%合理化されました。(Verifyサービスはaws cdkを活用してます。) サーバーレスを採用する事は、おそらくクラウド(当社はawsですが、googleなど他でも)のマネージドサービスの利用と不可分です。従ってクラウドが提供するリソース管理との結合度が高くなります。クラウドベンダにロックインされることと引き換えにはなりますが、クラウドが示すベストプラクティスに則って手順の標準化が進んだ事は、当初は期待していなかった思いがけないメリットと感じています。 今後の課題 パフォーマンスの安定化 いわゆるコールドスタート問題です。lambdaのオンデマンド起動は、都度OS起動してコードを展開して処理をしているようなものであり、起動時間が安定しません。 現状は、関連する複数の処理を1つのlambda関数に統合する事で、1回の認証フロー中において複数回のコールドスタートの発生を軽減する程度の施策に留めています。これはコストの観点です。しかし、サービスがより多く使われる状況になれば、ユーザー体験の向上としてプロビジョンドな関数を準備する(=リソースを固定化する)処置などが必要になるかもしれません。 いつか来るコストの損益分岐点とアーキテクチャの転換 この記事で述べてきたように、Verifyサービスにおけるサーバーレス採用を決定した最大の要因は”アイドルリソースに対するコストの抑制”です。従って、このサービスの利用が爆発的に広まりトラフィックが密になれば、リソースのアイドル時間が無視できる比率になり、この決定要因が小さくなります。 その状況になれば、サーバーレス故のリソース単価の高さ、コールドスタートによるパフォーマンス変動の幅などデメリットが目立ち、合理性が説明できなくなるかもしれません。 その時に、アーキテクチャを変えるのか？あるいは、サーバーレスによるアーキテクチャへの恩恵を取り、サーバーレスのままチューニングする方向が良いのか？現時点でいくつかのシナリオを想定していますが、いつか選択を迫られると思っています。 まとめ 決済関連の事業を提供する当社においても、サーバーレスを活用できる場面はありました。実績のないアーキテクチャを採用するにはそれなりの緊張もありましたが、実際に活用し実に明確な定量効果がでている手ごたえはあります。 決済の基幹(ブランドやネットワークへの接続)　→　オンプレミス ユーザー寄りの業種特化したサービス　→　クラウド(コンテナ) 事業を問わず使えるコンポーネント的なサービス　→　クラウド(サーバーレス) 当社の技術スタックの中に、確実に新たなオプションを獲得できたと感じています。決済領域での信頼、安定を維持しつつ、その中で新しい挑戦をできるのはとてもエキサイティングな事です。一緒にやってくれる仲間も募集中です。 お時間ありがとうございました。おわり。

こんにちは。新里です。2025/01/06 から開催されたCESに行ってきました。色々と面白いものに出会えることが出来たので、その中からいくつか紹介したいと思います。あ、最初に書いておこうかな...全体所感としては、 機能としてAI・推論が入っているモノしかない人も機械もAI・推論が使えないと生き残れないハード・AIの共創による多様なプロダクト サービス・機能レベルでほぼ全てのモノで何かしらのAI・推論が使われているものばかりでした（構成単位となるパーツ、モータやセンサ・抵抗などは除いて）。ヒトの機能拡張・フィードバックや寄り添い補助、機械同士の連携強化でデータを活用したAI的な機能・推論はもはやデフォ感ですね。これについては、もう後戻り出来ない世界に入ってきたというのは強く感じます。また、ハードウェアの小型化・高性能化と、AI・推論による恩恵を多くのプロダクトは受けていると感じました。 CES とは CESは毎年１月にラスベガスで開催されている世界最大の見本市です。初日から行ってきましたが、予想通り大量の来場者でごった返していました。まず最初に面白い!!と思ったモノを紹介していきます。 これは面白いと思ったプロダクト 色々と回ってみて、これはヤバいと感じたモノを写真と共に何個か紹介します。 ■ HAPLY Inverse/MiniVerse力覚フィードバックを行うものは色々と触ったり使ったりした気でいましたが、恥ずかしながらこんな凄まじいモノを自分は知りませんでした。ふらっと会場を歩いていて、ナニコレと思って触ったら、なにこれ、凄い!! の一言でした。最大0.01mm 解像度と4kHzのリフレッシュレートで、フィードバックがあまりにも繊細でかなり驚きでした。ほんと凄いのひとこと。CES 2025 Best Innocation Awards を取得していました。 画面上の面を操作している様子 ロボットアームとの相性はまさに最高かなと。 両手持ちでオペをしているデモを行っていました。 ■ glidanceシアトルの盲目者向けのロボット会社さんで、「The World's First Intelligent Guide.」という謳い文句になにこれ？と反応した。音声と手持ちの所の左右に手にフィードバックを行って誘導してくれて、よくよく見るとカメラが何個か付いていて、自動ステアリング、自動ブレーキ、触覚フィードバック、音声対話用スピーカと機能もりもり。CEOが視覚を失った方で、英国盲導犬協会の理事長＆マイクロソフト・リサーチでAIとロボットを使った製品開発をされていた方で、まさに自分のための自分の最強のデイバスを他のみんなにも!!、みたいな感じがカッコよすぎる。 会場にはデモ機が何台か。blind では無いですが、少し触らせてもらった。 ■ Agility Robotics LVCCのモビリティ側を歩いていたら、SCHAEFFLERの所でAgility Roboticsが作業していました。 https://www.youtube.com/watch?v=lcm7K-ptM5s Agility Roboticsといえば、CES 2025 NVIDIA Json HuangのKeynoteのロボ一覧登場シーンで、Jason Huangの隣に出てきたロボですね。Agility Robotics については名前は聞くものの、実際に動作しているのは眼の前で見たことが無かったので、ちょっと感動しました。前後左右と下向きにカメラ（見た目的にはRealSense）が登載されていました。 CES 2025 NVIDIA keynoteより。左がAgility Robotics Digit、右がFigure 02 寝転んで充電している ■ Humanoid 会場には他にも色々なロボットがいました。Unitree, Deep Robotics の周りには沢山の人だかりで注目度が凄いなーと。他にも何体か二足歩行のHumanoidが何体かいました。Booster Roboticsの二足歩行ロボットは他会場まで練り歩いていて、周りには人だかりが出来ていました。実際のブースはLVCC Southで、故障したロボットの補修をエンジニアさんがしていました。他は手を振ったり、直立不動であったり...とても驚いたのが Enchanted Tools の玉乗りロボットで、インタビューを受けて話していました。インタビューを受けるロボットというのも構図として面白いですが、まさかの玉乗り・安定していてめちゃくちゃ驚きました。 Ti5Robothttps://www.ti5robot.com/ RoboSensehttps://www.robosense.ai/ Booster Roboticshttps://www.boosterobotics.com/ CASBOT https://www.casbot.tech/ Enchanted Tools https://enchanted.tools/ Agility Roboticsからのロボット類をよーく見てみると、どれもRealSense祭り会場はここですか？というほど、どれもこれもRealSense（たまにorbbecがあったり）。ほんとRealSenseは相変わらずよく使われていますね。 CES会場めちゃくちゃ広い ここでCES会場についても記しておきます。会場は大きく２つに分かれていて、・Venetian Hotel ：スタートアップが多め・LVCC ( Las Vegas Convention Center ) : モビリティ・大企業さんどちらも尋常じゃない広さでした。３日間の滞在になりましたが、毎日の歩数は約３万歩。さらーっと両会場を見て回るくらいなら１日で済むとは思いますが、「なにこれ？」的に話したりすると、それぞれの会場を１日で全て見て回るのは不可能に近いかなと。Venetial と LVCC 間の移動は期間中は無料のシャトルが出ているので、これに乗ると１０分くらいで移動できるくらいの距離感でした。LVCC はCentral/North/West/South とホールが別れていて、移動に無料でTesla Loopを使うことが出来ます。 トンネル内が気持ちいい 各会場・ホールはやたらと広いので、「かなり歩く」ことを覚悟しておいた方がよいですね。 Sphere やはり、ここには行かないわけにはいかないですね。CES 2025 Delta Keynote がShpereで開催されたのも話題になっていました。U2 UVというライブを見てきましたが、全球LED Display マジでヤバいです。CESと同じくらい、オススメ感が高いですね。 圧倒的な存在感 近くまで行って見てみると、実際のドットがわかりますね。 近くで見るとLED・ドットパターンが分かる。 Sphereの中にもロボ（Aura）対話して話したり、指向性スピーカを使ったイベントの説明をしていました。 ライブ中の様子 CESのようなイベントが無い限りラスベガスに行く機会は無いですが、Sphere はまさに圧巻でした。映像や何かコンテンツを作っている人は、Sphere で何か流してみたい！！と思うはず。 2025年の始まり 直近の2,3年は生成AI、LLMが大流行でした。この流れは今年も大きくは変わらず、実際の現場でも導入が進んでいくことでしょう。CESで感じたのはAI・推論によるプロダクトが多かったということでした。そして、多くのプロダクトがそうであるよう、短期的にAI的なものがヒトに取って代わるというより、ヒトの補助・拡張としての役割を強く感じました。これは当然のように感じますが、「すぐにAIがヒトの仕事を奪う未来がやってくる」という言葉や話題がよく出てくるのと比べると、「まだこのくらいの事しか出来ないの？」と感じるかもしれません。すぐに、というスピード感がどれくらいのスピード感なのか？という主観的な部分はありますが。 ちなみに、個人的には仕事を奪われて楽になるなら、自分は別のことをするからどんどん奪ってくれ！！と思っていたりします。 プールの掃除ロボ APIER、人が行う作業をロボ・AIが代替えしてくれる デジタル・情報分野のAI・推論は非常に発達しましたが、物理的な現実世界に影響・干渉をするには、何かしらの仕掛け（例えばロボットハンドやアーム、モビリティ）が必要になります。もちろん、現在でも情報処理が世界に容易に影響・干渉する例は多々あります。マーケットのアルゴリズム取引などは良い例でしょう。 ただし、ChatGPTに「ちょっとコンビニに行って、ドリンクを買ってきて。そしてグラスに氷と一緒に注いでおいて。」と言っても、これを実現するには数々の乗り越えるハードルがありますね。他にも、僕の体調を常にモニターして、何かドリンクが飲みたいな...と思ったタイミングで、ロボットがビールを持ってくるような事が出来たら最高です（これがヒトの自由意思であって、アルゴリズムによって管理されたディストピアでは無いことは願っていますが。AI・ロボによってヒトの自由意識が進化・拡張するようになると考えています）。 「部屋の床を綺麗に掃除しておいて」くらいは現在でも可能ですね。自動でロボットが部屋を掃除してくれます。他にも「この場所に行きたい」といえば、自動で移動するPoC・モビリティも出てきています。 TIER IVのCES 2025で ソニー・ホンダモビリティが発表したSALOON 冒頭の「人も機械もAI・推論が使えないと生き残れない」というのは、多くのモノがAI・推論を使うなかで、それらを使わないとヒト・機械単体では圧倒的な処理速度を持つコンピュータとの差を埋めることは難しくなってくると個人的には考えています（ハック的なアプローチは別にして）。変化に適応したものが生き残るというのと同様ですね。また、ハードウェアの小型化・高性能化と多様なセンサ、そしてそれらを統合して利用するミドルウェアがここ数年で一気に充実してきました。例えば、Lidarやカメラを買ってきて、ROS(Robot Operating System)を使うと、すぐに周辺地図やシュミレーションを行って、物理的なロボット・リアルな世界に反映させたり、誰でも簡単にできますね。また、Chat GPT APIに代表されるようなLLM・AI的な推論に誰でも簡単にアクセスして使えるようになったのは周知です。これからのサービス・プロダクトはハードとAIの共創による恩恵と、現実世界からのフィードバックによって多様な進化を見せてくれるでしょう。遠くて近い未来に向けた、AI・ハードウェア・ソフトウェアの共創による多様なプロダクトの現在地、そして将来を感じることが出来たCESでした。 SAMSUNGのSECでの展示会場の上に掲げられていた。