新着 の記事一覧

GMOインターネットグループ株式会社・グループ研究開発本部のA.T.です。今回は、ラスベガスで開催されたCES 2026の現地視察より、特に熱気を帯びていた「ロボティクス関連企業」の展示を中心にご紹介します。なお、出発前の事前調査については、こちらの記事（事前調査編）をご覧ください。追記：現地の興奮と技術詳細を直接お伝えする報告会「GMO AIR┃CES報告会、フィジカルAIの未来」の実施も決定！ご興味のある方はぜひご参加ください！ はじめに：CES 2026で感じた潮流 今回のCESで特に強く印象に残ったのは、「フィジカルAI（Physical AI）とロボティクスの接続が、一気に“実装フェーズ”へ進みつつある」という点でした。会場を歩いて感じた全体的なトレンドは以下の通りです。 VLA（Vision-Language-Action）の一般化IK（逆運動学）で事前に作り込んだモーションを見せる展示から、VLAモデルを前提に「認識して、その場で判断して動く」展示へと、明確に軸足が移っているように見えました。 業界ごとに異なる参入の文脈家電メーカーは「スマートホーム」の延長として、産業系メーカーは「省人化・自動化」の延長として参入しており、同じヒューマノイドでも“解くべき課題”が異なることが際立っていました。 グローバル競争の加速米中に加え、韓国やシンガポール企業の存在感が増していると感じました。一方で、日本企業のロボティクス領域でのプレゼンスは、会場全体ではやや控えめに見えました。 1. NVIDIA：フィジカルAI開発の「基盤」を押さえる戦略 ロボティクス開発において、NVIDIAの存在感は別格でした。多くの企業が、シミュレーションや学習・評価の基盤としてNVIDIAのエコシステムを前提にしており、ハードウェア開発企業が「いかにこの基盤の上で開発ループを回すか」が、開発スピードを左右する段階に入っていると感じました。 特に、ロボット開発が「機体を作る」だけでなく、データ → シミュレーション → 学習/評価 → 実機展開を反復して成熟させるプロセスになっている以上、この“反復の速さ”を支える基盤の重要性は今後さらに増していくはずです。 2. 家電メーカーの参入：LG, Hisense 「規格化されていない環境」への挑戦 家電メーカー勢は、家電がAIによってスマート化していく文脈の中で、個人に最適化されたサービスを提供するインターフェースとしてヒューマノイドを位置づけているように見えました。 LG：生活に溶け込む「LG CLOiD」 LGはAI搭載ホームロボット「LG CLOiD」を発表し、洗濯機へタオルを投入するデモなどを披露していました。工場とは異なり、家庭内は環境が規格化されておらず、タスクに「正解」がありません。 散らかった部屋の認識 人や家具を傷つけない安全性 住人とのHRI（Human-Robot Interaction） LGはこれらの課題に対し、単なる家事代行だけでなく、声かけや状況理解といった「生活に溶け込む体験設計」を重視している点が印象的でした。 Hisense：家電メーカーが“ヒューマノイド”を持つ意味 Hisenseブースでは、ヒューマノイドロボットの展示が見られました。デモの詳細までは確認できませんでしたが、家電メーカーがヒューマノイドを「次のインターフェース（家の中の“動く端末”）」として捉え始めている兆候として興味深いと感じました。 3. 産業用メーカーの進化：Boston Dynamics, NEURA Robotics 「魅せる」から「使える」へのシフト Boston Dynamics：役割分担が成立している強さ Boston Dynamicsは新型Atlasを披露していました。かつてのようなパルクールによる運動性能アピールから一転し、車両組立など「現場でいかに使えるか」に焦点を当てたデモへ移っているように見えました。 特筆すべきは、エコシステムとしての“役割分担”が見えやすい点です。 機体：Boston Dynamics AI：Google DeepMind 実証フィールド：Hyundai この分担がうまく機能すれば、単体のロボット性能だけでなく「現場導入までの距離」を縮められる可能性があり、ロボティクス企業が目指すべき一つのモデルケースを示しているように感じました。 NEURA Robotics：実タスクに寄せた“堅実な前進” NEURA Roboticsは新型「4NE1」を披露し、NVIDIAとの協調も強く打ち出していました。また、衣類の仕分けのような実タスクを想起させるデモがあり、動作速度はゆっくりながらも、外乱への耐性や実運用を意識した堅牢さを感じました。 4. 新興企業の躍進：Sharpa, Realhand 「実タスク」へのこだわりと技術の可視化 Sharpa：触覚 × 長期推論 × HRI 今回の展示で個人的に最も印象に残ったのが、Sharpaによるデモでした。派手なバックフリップのような“運動性能”ではなく、以下の要素を同時に成立させる「実タスク」の構成になっていました。 紙風車の組み立て：長期的な工程遂行（Long-horizon tasks）ブラックジャックのディーラー：マルチモーダル推論＋対話自撮り補助：人との関わり（HRI） 手先の触覚制御と、長い工程を理解しながら遂行する推論能力を組み合わせていた点は、実用化への解像度が非常に高いと感じました。 Realhand：技術を「見える体験」へ セミヒューマノイドを展示したRealhandは、手先の精巧さが際立っていました。報道でも話題になったピアノ演奏のデモは、技術要素を誰もが直感的に理解できる「体験」に落とし込む好例として参考になります。 https://twitter.com/rohanpaul_ai/status/2009814233773703644?s=20 5. 依然として強い中国企業：Unitree, EngineAI 圧倒的な運動性能とパフォーマンス Unitree：ボクシングデモを披露。運動性能の高さはもちろん、開発者に対して高い自由度を提供している点が強みだと感じました。 EngineAI：新型「T800」によるデモが目を引きました。注目度は非常に高かった一方で、具体的な用途（Use Case）の着地点については、まだ探索段階に見えました。 まとめ：日本企業はどう戦うか CES 2026を通して、ロボットは「動くもの」から「考えて働くもの」へと、フェーズが確実に移行していることを実感しました。VLAモデルの実装が進むにつれ、ハードウェアの差分だけでなく、それをどう制御し、どのフィールド（家庭、工場、接客）に適用するかという「ソフトウェアとUX」の戦いになっていく印象です。 世界中で「百家争鳴」の様相を呈するフィジカルAI市場において、私たち日本の開発者がどのような価値を出していくべきか。大いに刺激を受けた視察となりました。

こんにちは、技術広報チームの田中です。GMOインターネットグループは、11月18日（火）、19日（水）に開催された「CODE BLUE 2025」にトップスポンサーとして協賛しました。本記事では、イベント当日の様子に加え、出展ブースやスポンサーセッションについてご紹介します。 イベント概要 日時：2025年11月18日（火）、19日（水）会場：ベルサール高田馬場参加費用：有料（参加チケット詳細はEventoryにて）開催形式：対面形式主催：CODE BLUE実行委員会公式HP：https://codeblue.jp/ CODE BLUE とは？ CODE BLUEは、世界トップクラスの情報セキュリティ専門家が集まり、最先端の技術や研究成果を共有する国際会議です。日本を含むアジア各国および欧米の著名な研究者が集い、国際的なセキュリティコミュニティの形成を目指しています。 今回は第13回目の開催となり、基調講演として、Mayhem（旧称：ForAllSecure）CEOであり、カーネギーメロン大学教授を務めるアプリケーションセキュリティ分野の第一人者、デイビッド・ブラムリー氏を招へいするなど、大きな盛り上がりを見せました。 ブース出展について CODE BLUE 2025 では、「ネットのセキュリティもGMO」をコンセプトとしたブース出展を行いました。「ネットのセキュリティもGMO」は、「すべての人に安心な未来を」というキャッチフレーズのもと、2025年2月より始動した GMOインターネットグループ横断プロジェクトです。 本イベントでは、トップスポンサーとして協賛した GMOインターネットグループブース内にて、GMOサイバーセキュリティ byイエラエ、GMOグローバルサイン、GMOブランドセキュリティ の3社が、パネル展示および体験型企画を実施しました。また、セカンドスポンサーとして協賛した GMO Flatt Security と横並びでの出展となり、グループとしてのセキュリティ領域における総合力を発信しました。GMOインターネットグループブースでは、以下4つの企画を実施しました。 企画①「ガチャガチャを回して豪華景品をゲットしよう！」 ブースでは、豪華景品が当たるガチャガチャ企画を昨年に引き続いて今年も実施しました。国際的なセキュリティカンファレンスということもあり、多くの海外参加者をはじめ、セキュリティ企業の方やセキュリティを学ぶ学生の方々がお立ち寄りくださいました。 日本文化として人気の「ガチャガチャ」は幅広い層の方々に好評で、多くの方がご参加くださいました。景品はハズレなしで、基本賞としてGMO BRAND SECURITYのオリジナルノートなど3点、豪華景品としてペンタブやスマートトラッカー等をご用意しました！ 想定を上回る多くの方にご参加いただき、全ての豪華景品が配布終了。本企画を通じて、多くのお客様と濃密なコミュニケーションを取ることができました。 企画② 体験ブース「GMOサイバー攻撃ネットde診断 ASM」 今回は新たな企画として、「GMOサイバー攻撃ネットde診断 ASM」のデモンストレーションコーナーを設けました。「GMOサイバー攻撃ネットde診断 ASM」はGMOサイバーセキュリティ byイエラエが提供するASM（Attack Surface Management）ツールです。外部に公開されたIT資産を自動で棚卸し・可視化し、セキュリティリスクの把握を容易にします。CODE BLUE 2025 の会場では、来場者の皆さまに 2種類のデモンストレーション体験 をご用意しました。1つ目は、ドメイン入力不要で実際の操作画面を体験できるデモ。2つ目は、自社ドメインを入力することで、その場で実データをもとに診断が可能な簡易診断デモです。お客様の関心や利用シーンに応じて、いずれかのメニューを体験いただきました。 企画③ ワークショップ「インターポールAIクエスト」 1日目には、GMOサイバーセキュリティ byイエラエ主催のワークショップ「インターポールAIクエスト」を実施しました。過去にインターポール向けに提供したCTFを初心者向けにアレンジした内容で、参加者はインターポールのサイバー犯罪捜査官という設定のもと、サイバー犯罪組織に立ち向かうといった体験ができます。 すべてのCTF問題をクリアした方には、GMOサイバーセキュリティ byイエラエのエンジニアが執筆した書籍をプレゼント。さらに、ノーヒントでボーナス問題を含むすべての課題をクリアした先着5名の方には、「超レアGMOイエラエ特製チャレンジコイン」が進呈されました。 多くの方から「面白い」との声をいただき、セキュリティ対策の重要性を学びながら交流を深める貴重な機会となりました。 企画④ ワークショップ「AI × セキュリティ診断最前線 『Takumi by GMO』体験会」 2日目には、GMO Flatt Security主催のワークショップ「AI × セキュリティ診断最前線 『Takumi by GMO』体験会」を実施しました。GMO Flatt Securityが開発・提供する日本初のセキュリティ診断AIエージェント「Takumi by GMO」との対話を通じて、AIによって進化するソフトウェアセキュリティ診断の世界を体験いただきました。 注目度は非常に高く、全4回の体験会はすべて満員となり、参加者から高い評価をいただきました。 スポンサーセッション スポンサーセッションでは、GMOサイバーセキュリティbyイエラエ株式会社 GMOサイバー犯罪対策センター 局長 の福森大喜が登壇。「AIが全てを灼き尽くす ～ 天使か悪魔かそれとも ～」と題し、AI for Security（AIを活用したセキュリティ強化）について講演しました。 セッションではブルーチームに焦点を当て、セッション冒頭でGMO AI・ロボティクス大会議にて茶圓氏が提唱した「AIの進化の3軸（モデルの進化、機能の進化、MCP）」を紹介し、モデルや機能の進化が成熟期にある一方で、MCPが今後の進化の主軸になる点や、USBハブのようにAIとSlackやGmailなどを接続する仕組みについて解説しました。さらに、AIにHack The Box Sherlocksを解かせた検証結果をもとに、フォレンジック調査やインシデントレポート作成への活用事例を紹介しました。人手では数日を要する作業を、AIエージェントにより約20分で完了した事例が示される一方、最終的な人の検証が不可欠である点にも言及しました。 AIと人材育成についても触れ、AI活用と人の成長を両立させる重要性を語りました。 After Party @CÉ LA VI CODE BLUE 2025の2日目終了後、感謝の意を込めて、渋谷のCÉ LA VI TOKYOにてGMOサイバーセキュリティ byイエラエ、GMO Flatt Security、GMOブランドセキュリティ共催のアフターパーティを開催しました。当日は大変多くのお客様にご参加いただき、セキュリティ関係者同士の交流を深める、活気ある場となりました。 最後に 今年もCODE BLUE 2025への協賛を通じて、多くの参加者やスポンサー企業の皆さまと貴重な交流の機会を得ることができました。また、安心・安全なインターネット社会の実現を目指すGMOインターネットグループの取り組みを幅広く知っていただく機会にもなりました。 また来年もお会いできることを楽しみにしております！

今回、社内向けのアプリケーションを開発するにあたり、上流工程を担当する機会がありました。せっかくなので「試せるところはすべてAIに任せる」といった方針でAIを使ってみました。実務メモとして、使用したプロンプト例と運用のコツを公開します。使用モデルはChatGPT（GPT-5）です。 背景 社内の顧客管理系スタッフツールを新規開発することになりました。スケジュールが厳しめだったこともあり、上流工程に割ける時間が限られている状況でした。「じゃあAIで上流を効率化しよう」と腹をくくり、試行錯誤しながらプロジェクトを進めました。 先に結論（うまくいったこと/難しかったこと） うまくいったこと 画面UIや構成図をSVGで出力し、編集可能なたたき台を高速で作成できたそのSVGを足がかりに、詳細設計のたたきや単体テストケースの初版まで作れたDB設計後の定型チェックを一気に回せた（表記揺れ、型の整合、ルール違反の洗い出し） 難しかったこと スケジュール作成は挫折（プロンプト設計の詰めが甘く、期待通りにならず）DB定義書のゼロから生成は非効率だった（要件伝達のコストが高く、自作の方が速い） 画面UIの叩き台をAIに任せてみた 関係者の合意形成と、開発メンバーとの同期のために画面UIのイメージが必要でした。前提として、今回は社内向けの小規模案件だったため、UIツールで作り込むよりも、納期遵守とスピード優先で「まず形を出す」ことに振り、GPTに依頼してみました。 プロンプト例 一般的な顧客管理用のスタッフツールの画面UIをSVGで生成してください。 構成要素： ・顧客情報、申請情報、お問い合わせ情報が管理されるアプリ ・サイドメニューとメイン画面の構成 ・メイン画面には顧客情報管理画面を表示 ユースケース： 1. 検索条件入力 → 検索実行 → 一覧表示 2. 行クリック → 詳細表示/編集 3. CSVダウンロード、メール送信 ルール： ・すべて日本語ラベル 出力：ダウンロード出来る形でSVGファイルを返すこと。 結果（生成されたSVGファイル） あっという間にこのクオリティの画像が生成されました。UIデザインのスキルがない自分にはこれは参考になります。ありがたい。２度３度と出力させてみても、色々な結果が出てきて勉強にもなります。 そして、このSVGファイルをPowerPointで、挿入＞画像から読み込みます。その後、グループ化解除を選択すると各要素を編集可能となります↓ 必要な要素の追加、不要な要素の削除、微調整などを行って、さくっと画面UIのイメージを作成できました。 実務メモ このフローはアプリケーション構成図にも流用できました。「まず1枚作ってから考える」用途なら、画面遷移図やデータフロー図などにも横展開できそう。実務では、作った画面イメージをGPTに読み込ませて、詳細設計のたたきや単体テストケースの初版まで発展させて生成させました。 DBテーブル定義書の一次レビューを任せてみた 次はDBテーブル定義書です。まずは、ゼロから定義書を作ってもらうのを試しましたが、要件を伝えるのに時間がかかってしまい、効率が悪かったため挫折しました。さらに要件伝達が甘いと、雰囲気のあるものは出るものの、結局全量精査が必要で自分で作った方が速いという結論です。一方で、完成済み定義書の機械チェックは強力でした。今回はExcelで作成した定義書を対象に、下記2工程でのチェックを行いました。(1)同名カラムの型・桁・NOT NULLや命名の揺れを横断比較(2)命名規則・型統一などのルール準拠を点検。 (1)のプロンプト例 添付のテーブル定義書のExcelをレビューしてください。 各テーブルを横断的に比較し、同じカラム名でデータ型・桁数・NOT NULL条件が異なる箇所や、命名の表記揺れがある箇所を洗い出してください。 出力： 問題一覧（テーブル/カラム/問題/根拠/修正案） (1)の結果 （実際の出力のため、テーブル名をマスキングしています）1つ目のチェック。初期のばらつきを一括で潰し、後工程の手戻りを防ぎます。 (2)のプロンプト例 添付のテーブル定義書のExcelをレビューしてください。 各テーブルが下記ルールに沿って定義されているかを確認し、違反している箇所を洗い出してください。 ルール： ・命名規則は小文字＋snake_caseで統一。略語やスペルミスも指摘してください ・主キーは数値のサロゲートキーであること。型はNUMBER(28,0)であること ・時刻型はDATEに統一 ・フラグの型はNUMBER(1)で制約はCHECK (col IN (0,1))、NOT NULL、DEFAULT 0であること 出力： 問題一覧（テーブル/カラム/問題/根拠/修正案） (2)の結果 2つ目のチェック。ルール違反を網羅的に拾ってもらいました。 この2工程で、見落としがちなばらつきを短時間で洗い出せました。 実務メモ 機械的チェックはAI、要件に適合しているかの最終チェックは人の役割として切り分けてレビューしました。定義書の丸投げは難易度が高かったです。ただし「一般的な会員テーブルに必要なカラム列挙」など部分タスクの支援は有効でした。定義書のフォーマットを固定しておけば、同プロンプトで同品質の機械チェックを繰り返し適用できます。 最後のまとめ 「試せるところは全部AI」に振り切ったことの学びとしては、うまく回せば上流工程でAIが生きる場面は多いなと気づけました。上流では、曖昧な要求を形にしていく場面が多いですよね。そこをAIに投げてみると、自分では出せなかったパターンや視点を提案してくれてかなり助けられました。（記事では割愛していますが、細かいタスクもいろいろお願いしています。通信フローの表をまとめてもらったり、ログ出力仕様を一緒に詰めたり、作成したテストの観点漏れを指摘してもらったり。）ただ、結局のところ現場や人によって最適解は違うと思います。今回は社内向けで図の品質基準もゆるめという前提だったので、「AIのたたき台→人の手直し」はハマったなと思っています。一方で、複雑な前提や厳密さが求められる成果物（DB設計や仕様設計など）は、最初から人が手を動かした方が効率的な場面もあると感じました。まずは何でも試して、広げていくのがいいんじゃないかなと。もしどこか一つでも持ち帰ってもらえるポイントがあれば嬉しいです。

1. Why Kubernetes & why k8s Operator 1.1 なぜ Kubernetes なのか？ 現代のアプリケーション開発において、コンテナ技術（Dockerなど）は「どこでも同じように動く」環境を提供し、開発とデプロイのポータビリティを劇的に向上させました。しかし、本番環境で多数のコンテナを運用しようとすると、新たな問題が発生します。 どのサーバーでどのコンテナを実行するか？トラフィックに応じてコンテナの数をどう増減させるか？ (スケーリング)コンテナが停止したらどう自動で復旧させるか？ (自己修復)複数のコンテナ間のネットワークをどう設定するか？ Kubernetes (K8s) は、これらの「コンテナオーケストレーション」の問題を解決するためのデファクトスタンダード（事実上の標準）となりました。Kubernetes は、インフラ全体を「宣言的API (Declarative API)」で管理可能にします。開発者が「（望ましい状態として）Webサーバーのコンテナが3つ欲しい」と YAML で定義すれば、Kubernetes が現在の状態を監視し、自動的に3つのコンテナが稼働する状態を維持・調整してくれます。これにより、アプリケーションのデプロイ(Day 1 オペレーション)の多くが自動化されました。 1.2 なぜ Kubernetes Operator が必要なのか？ Kubernetes は Deployment (ステートレスアプリ用) や StatefulSet (ステートフルアプリ用) といった強力なリソースを提供します。しかし、これら標準機能で自動化できるのは、一般的なアプリケーションのデプロイやスケーリング、ローリングアップデートまでです。複雑なミドルウェア（例：データベース、監視システム、メッセージキュー）の 「運用（Day 2 オペレーション）」には、ドメイン固有の専門知識（SRE や運用担当者の知識）が必要です。例えば、データベースクラスタを Kubernetes 上で運用する場合を考えてみてください。高度なアップグレード: スキーマ変更を伴う場合、単なるローリングアップデートでは対応できず、特定の順序での停止やデータ移行が必要です。バックアップとリストア: 定期的にバックアップを取得し、障害時には特定の手順でリストアする必要があります。自動フェイルオーバー: マスターノードがダウンした際、自動でレプリカをマスターに昇格させる複雑なロジックが必要です。状態に応じた調整: 負荷に応じて、リードレプリカの数を調整する。これらの運用作業は、Kubernetes の標準機能（YAML）だけでは定義できず、人手によるスクリプト実行や手動オペレーションに頼りがちでした。これではミスが発生しやすく、自動化の恩恵が限定的です。Operator ＝ 人間の運用者の「ドメイン知識」をソフトウェアとして Kubernetes に埋め込む仕組みここで Operator が登場します。Operator は、これらの複雑な運用手順（バックアップ、フェイルオーバーなど）をコード化し、Kubernetes のコントローラーとして組み込む仕組みです。Operator により、Kubernetes は「Nginx コンテナを3つ動かす」といった単純なタスクだけでなく、「データベースクラスタのバックアップを取り、マスター障害時には自動でフェイルオーバーする」といった高度な運用（Day 2）まで自律的に実行できるようになります。 2. Operator とは何か？ Operator は Kubernetes のコントローラーモデルの延長線上にあります。Kubernetes は内部的に複数の Controller が動作しており、常に以下のループで動いています：望ましい状態（Spec） ≠ 実際の状態（Status） → 調整（Reconcile）を行うOperator はこの仕組みをユーザー定義のリソース（CRD：Custom Resource Definition）に拡張したものです。 典型的な構成は：CRD（Custom Resource Definition）: 独自の API（Kind: DatabaseCluster など）を Kubernetes に追加します。Controller: CR の変更を監視し、「望ましい状態」に近づけるための処理（例：バックアップジョブの実行、フェイルオーバーのための Pod 設定変更）を実行します。 3. Operator を理解するために必要なコア概念 Operator は以下の Kubernetes の基本的な概念の上に成り立っています。 3.1 Spec（Desired State）と Status（Actual State） Spec: ユーザーが「こうあってほしい」と定義する「望ましい状態」Status: コントローラーが観測した「実際の状態」これはOperatorと関係がある概念だけではなく、Kubernetesにですごく重要な概念ではあります。例えば、一般的なpodの場合でも、spec と statusを持っています。 # kubectl get po nginx -o yamlapiVersion: v1kind: Podmetadata:......spec: container: - image: nginx...status: condition: ... containerStatus: ... Operator の仕事は、Spec を読み取り、Status をこの Spec に近づけ、結果を Status に書き戻すことです。 3.2 Reconcile ループ コントローラーが「Spec と Status の差分」を検知して実行する調整処理のこと。このループが Operator の中核です。このループは、Kubernetes が「宣言的API」を維持するための心臓部であり、Operator の「脳」にあたる部分です。 3.2.1 Reconcile ループの基本的な考え方 Reconcile ループの動作は、家庭にある「サーモスタット（自動温度調節器）」に例えると非常に分かりやすいです。 望ましい状態 (Spec): あなたがエアコンのリモコンで設定した「希望温度 25℃」。現在の状態 (Status): センサーが検知した「現在の室温 22℃」。調整 (Reconcile): サーモスタットが「(Spec 25℃) ≠ (Status 22℃)」という差分を検知し、「冷房を停止し、暖房を作動させる」という調整処理を実行します。ループ: 暖房が作動し、室温が 25℃ に達すると、サーモスタットは再び「(Spec 25℃) = (Status 25℃)」を検知し、暖房を停止します。もし室温が下がり始めたら、再びループが作動します。 Operator の Reconcile ループもまったく同じです。 Spec: ユーザーが AppCluster YAML に書いた「size: 3 (Pod が3つ欲しい)」Status: Operator が実際に観測した「Pod の数 1」。Reconcile: Reconcile 関数が起動し、「(Spec 3) ≠ (Status 1)」を検知。不足している Pod を2つ作成 (Create) します。ループ: 次に誰かが手動で Pod を1つ削除しても (Status が 2 になる)、Reconcile ループが再び起動し、size: 3 に戻すために Pod を1つ作成します。 3.2.2 Reconcile ループは「いつ」実行されるのか？ 重要なのは、Reconcile ループは「常に動き続けている (e.g., while true)」わけではないという点です。それは非効率的です。Reconcile ループは、イベントをトリガーとして実行されます。controller-runtime (Operator SDK の中核) は、Workqueueと呼ばれる仕組みを使い、以下のイベントが発生したときに、対象リソースの Reconcile をキューに入れます。監視対象リソース（CRD）の変更: ユーザーが kubectl apply で AppCluster の Spec を変更した (例: size を 3 から 5 に変更した)。管理対象リソース（子リソース）の変更: Operator が作成した Pod がユーザーによって手動で削除された、または Pod がクラッシュして停止した。 (Operator は自分が管理する Pod の状態も Watch しています)定期的な再調整 (Periodic Resync): 設定により、何も変更がなくても一定時間ごと（例：10分間ごと）に Reconcile を実行し、現在の状態が本当に Spec と一致しているかを確認することもあります。 3.2.3 Reconcile ループの「中身」 Reconcile 関数が実行されると、開発者は通常、以下のステップをコードとして実装します。Status 更新 (Update Status): 調整後の「実際の状態」を AppCluster リソースの Status フィールドに書き戻します（例：status.readyReplicas = 3）。取得 (Get): Reconcile のトリガーとなった AppCluster リソースの最新の状態を Kubernetes API から取得します。観測 (Observe):AppCluster が管理すべき現在の世界の実際状態を観測します（例：List API を使い、この AppCluster に属する Pod が現在いくつ存在するかを調べる）。比較 (Diff):AppCluster の Spec (望ましい状態) と、観測した実際状態 (Pod の数) を比較します。実行 (Act): 差分があれば、それを埋めるための処理（Create, Update, Delete）を実行します。Pod が足りない → Pod を Create する。Pod が多すぎる → Pod を Delete する。Pod のイメージが古い → Pod を Update (ローリングアップデート) する 3.2.4 設計上の最重要原則: 冪等性 (Idempotency) Reconcile ループは、ネットワークエラーなどで失敗し、何度もリトライ（再実行）されることを前提に設計しなければなりません。このため、「何度実行しても同じ結果になる」という冪等性（べきとうせい）が極めて重要です。悪い例 (冪等でない): 「"Pod を1つ作る" というイベントを受け取ったから、Pod を1つ作る」 → これではリトライの度に Pod が増え続けてしまいます。良い例 (冪等である): 「望ましい状態は Pod 3つ。現在の状態は Pod 2つ。だから Pod を1つ作る」 → このロジックなら、何度リトライされても、常に「望ましい状態 3」と「現在の状態」を比較するため、結果は必ず「Pod が合計 3つ」という状態に収束します。 3.3 OwnerReference (所有者参照) によるガーベジコレクション これは、リソース間に「親子の関係」を定義し、自動的なリソース管理（特に削除）を可能にするための Kubernetes の仕組みです。主な機能: ガーベジコレクション (GC) Operator は AppCluster（親）リソースの指示に基づき、Pod や Service（子）リソースを作成します。この時、子のリソースのメタデータに「私の所有者 (Owner) は AppCluster です」という印 (OwnerReference) を付けます。 こうすることで、ユーザーが kubectl delete appcluster my-cluster を実行して親を削除した際に、Kubernetes のガーベジコレクターがそれを検知し、その親に紐づく全ての子リソース（Pod, Service など）を自動的に削除してくれます。 もし OwnerReference がなければ、親を削除しても子は残り続け、「孤児リソース」としてクラスターにゴミが溜まってしまいます。もう一つの役割: 関係性の明示 この親子関係は、Operator 自身が「自分が管理すべきリソース」を識別するためにも使われます。Reconcile ループが「現在の Pod の数」を観測する際、OwnerReference をキーにして「この AppCluster が所有する Pod だけ」を正確にリストアップすることができます。Operator が子リソースを作成する際は、必ず OwnerReference を設定することが必須プラクティスです。 3.4 Event・Condition による状態通知 これらは、Operator が「今何をしているのか」「リソースの健康状態はどうか」を、人間や他のシステムに伝えるための重要な手段です。kubectl describe コマンドで表示される情報の多くは、これらによって提供されます。 Event (イベント): これは「点」の通知であり、何かが起こった瞬間の「ログ」や「通知」のようなものです。 特徴: 一時的であり、一定時間が経過すると（または数が増えすぎると）自動的に消えます。 例: 「Pod 'my-pod-xyz' を作成しました」、「バックアップジョブを開始しました」、「Spec.Size の変更を検知しました」、「イメージの取得に失敗しました」 用途: kubectl describe を実行したときに、リソースの直近の操作履歴を確認するために使います。 Condition (コンディション): これは「線」の状態であり、リソースの現在の「健康状態（Health Status）」を示す「ステータスライト」のようなものです。 特徴: Status フィールドの一部として永続的に保存されます。通常、Type（状態の種類）、Status（True/False/Unknown）、Reason（理由）、Message（詳細）のセットで表現されます。 例: Type: Ready, Status: True (リソースは正常に稼働し、利用可能です) Type: Ready, Status: False, Reason: PodsNotReady (リソースはまだ利用可能ではありません。理由: Podの準備ができていません) Type: Upgrading, Status: True (現在アップグレード作業中です) 用途: ユーザーや他の自動化システム（例: CI/CD パイプライン）が、「このリソースは正常か？」「アップグレードは完了したか？」を確実かつ一貫した方法で判断するために使われます。 4. オペレーター開発の技術レイヤー Operator を開発する際、私たちは Kubernetes API と対話するための「部品」を選びます。その選択肢は、低レベルで柔軟なものから、高レベルで定型的なものまで、複数のレイヤーに分かれています。 4.1 レイヤー1: client-go (基盤ライブラリ) これは、Kubernetes 自身が内部で使っている、公式の Go クライアントライブラリです。 役割: Kubernetes API サーバーと通信するためのすべての機能（Get, List, Create, Update, Delete, Watch）を提供します。コントローラーの構成要素: 高度なコントローラーを自前で実装するため、client-go は以下の低レベルなコンポーネント（「部品」）を提供します。 Informer: リソースの変更を Watch し、ローカルキャッシュを更新・維持します。 Lister: API サーバーに負荷をかけず、ローカルキャッシュから高速にリソースを Get/List します Indexer: オブジェクトを特定のキー（例：Namespace）で分類し、高速に検索できるようにします。 Workqueue: 変更イベントを受け取り、Reconcile 処理のキューイング（順序処理、リトライ制御）を行います。課題: 非常に強力で高性能ですが、これらの「部品」をすべて手動でセットアップし、キャッシュの同期を管理し、Workqueue を正しくハンドリングする必要があります。これは非常に複雑で、大量のお決まりのコード（ボイラープレート）が必要になります。例えるなら:client-go は「高性能なエンジン、トランスミッション、タイヤ」などの個別の部品です。これらを使って車（コントローラー）をゼロから自作するようなものです。 4.2 レイヤー2: controller-runtime (中核エンジン) client-go の複雑さを解決するために登場したのが controller-runtime です。これは Operator 開発の「中核エンジン」となるライブラリです。 役割: client-go の低レベルな「部品」をすべて内部にカプセル化（隠蔽）し、開発者を面倒なセットアップから解放します。提供するもの: Manager: Informer, Lister, Workqueue, キャッシュの管理をすべて自動で行います。 High-Level Client: 開発者が使う Client は、読み取り時は自動でキャッシュ（Lister）を使い、書き込み時は API サーバーに直接送るなど、最適な動作を自動で選択します。 Reconciler インターフェース: 開発者が実装すべきことを、Reconcile 関数（ビジネスロジック）だけに集中させてくれます。例えるなら:controller-runtime は「エンジンや足回りがすべて組み込まれた走行可能なシャーシ」です。開発者は、このシャーシの上にどんなボディを乗せるか、内装をどうするか（＝Reconcile 関数の実装）だけを考えればよくなります。 4.3 Kubebuilder と Operator SDK (開発フレームワーク) controller-runtime は強力な「エンジン（ライブラリ）」ですが、それ自体はプロジェクトのディレクトリ構成や Makefile、Dockerfile を生成してはくれません。Kubebuilder と Operator SDK は、controller-runtime を利用した開発を開始するための「雛形（スキャフォールディング）生成ツール」です。役割:init や create api といった CLI コマンドを通じて、Operator 開発に必要なプロジェクト一式（ディレクトリ、CRD の YAML、RBAC 定義、Makefile、Dockerfile など）を自動生成します。controller-runtime との関係: Kubebuilder と Operator SDK は、どちらも内部で「エンジン」として controller-runtime を利用しています。 したがって、どちらのツールを使っても、開発者が最終的に記述する Reconcile 関数の書き方（ロジック）はほぼ同じになります。両者の違い: Kubebuilder:controller-runtime の「上流」にある、Go 言語での Operator 開発の標準的な雛形ツールです。 Operator SDK: Red Hat が支援するプロジェクトで、Kubebuilder の機能（Go で の雛形生成）を包含するスーパーセットです。Go 以外に、Ansible や Helm を使った Operator 開発にも対応しているのが最大の違いです。 4.4 比較表 比較項目レイヤー1: client-goレイヤー2: controller-runtimeレイヤー3: Kubebuilder / Operator SDK位置づけ低レベル基盤ライブラリ中核エンジン (ライブラリ)高レベル・雛形生成ツール (CLI)抽象度低 (すべて手動)中 (ロジックに集中)高 (プロジェクト全体を自動生成)主な目的K8s API との通信手段を提供client-go の複雑さを抽象化controller-runtime を使った開発プロジェクトを自動生成開発者の主な作業Informer, Lister, Workqueue の手動セットアップと管理Manager に Reconcile 関数を登録し、ロジックを実装CLI コマンドで雛形を生成し、Reconcile 関数にロジックを実装利用関係（なし）client-go を利用するcontroller-runtime を利用する 5. Operator SDK を使った Operator 開発（実例付き） これまでの理論を踏まえ、いよいよ Operator SDK を使って、AppCluster という Kind を持つ Operator を開発していきます。 5.1 プロジェクト目標と環境準備 プロジェクト目標:AppCluster というカスタムリソースを作成し、以下の機能を実現します。環境準備: Go 言語、kubectl、Operator SDK がインストールされていることを確認します。 $ go versiongo version go1.24.5 linux/amd64$ kubectl version --clientClient Version: v1.33.3$ operator-sdk versionoperator-sdk version: "v1.33.0" 5.2 プロジェクト初期化 プロジェクトディレクトリを作成し、Go モジュールと Operator プロジェクトの骨格を初期化します。 # Go モジュールを初期化go mod init github.com/demo/appcluster-operator# Operator SDK でプロジェクト構造を初期化 (v4 プラグインを使用)operator-sdk init --plugins go/v4 --domain=demo.io --owner="Demo" このコマンドは、cmd/main.go（プログラム入口）、config/（K8s マニフェスト）、Makefile、Dockerfile など、プロジェクトの基本的な骨組みを生成します。 5.3 API と Controller の作成 AppCluster という Kind の CRD と、そのロジックを担う Controller の雛形コードを自動生成します。 $ operator-sdk create api --group demo --version v1 --kind AppCluster --controller --resource これにより、以下の2つの重要なファイルが生成されます。 api/v1/appcluster_types.go （CRD の型定義） internal/controller/appcluster_controller.go （Reconcile ロジックの実装） 5.4 CRD の定義 (types.go) api/v1/appcluster_types.go を編集し、Spec（望ましい状態）と Status（実際の状態）を定義します。 // AppClusterSpec defines the desired state of AppCluster.type AppClusterSpec struct { // Size is the number of pods to create (desired state) // ユーザーが指定する Pod の数（望ましい状態） // +kubebuilder:validation:Minimum=0 Size int32 `json:"size,omitempty"`}// AppClusterStatus defines the observed state of AppCluster.type AppClusterStatus struct { // Ready is the number of pods that are actually ready (observed state) // 実際に Ready な Pod の数（実際の状態） Ready int32 `json:"ready,omitempty"`} ポイント: Spec はユーザーが「どうなってほしいか」を定義します。Status は Operator が「実際どうなっているか」を報告するために使います。+kubebuilder:validation:Minimum=0 のようなマーカー（コメント）は、make manifests 実行時に CRD のバリデーションルール（この場合は size が0以上）を自動生成します。 5.5 Controller ロジックの実装 internal/controller/appcluster_controller.go に、Operator の「脳」となる Reconcile ロジックを実装します。 5.5.1 必要な import の追加 まず、corev1 (Pod) や apierrors (エラーハンドリング) などを import ブロックに追加します。 import ( "context" corev1 "k8s.io/api/core/v1" apierrors "k8s.io/apimachinery/pkg/api/errors" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" // ★ newPodForAppCluster で使用 "k8s.io/apimachinery/pkg/runtime" ctrl "sigs.k8s.io/controller-runtime" "sigs.k8s.io/controller-runtime/pkg/client" "sigs.k8s.io/controller-runtime/pkg/log" demov1 "github.com/demo/appcluster-operator/api/v1" // ★ 自身の API を import) 5.5.2 RBAC 権限マーカーの追加 Reconcile 関数の直前に、Operator が Pod を操作するための RBAC 権限をマーカーで定義します。 // (AppCluster への権限はデフォルトで生成される)//+kubebuilder:rbac:groups=demo.demo.io,resources=appclusters,verbs=get;list;watch;create;update;patch;delete//+kubebuilder:rbac:groups=demo.demo.io,resources=appclusters/status,verbs=get;update;patch//+kubebuilder:rbac:groups=demo.demo.io,resources=appclusters/finalizers,verbs=update// ★ Pods に対する権限を追記//+kubebuilder:rbac:groups="",resources=pods,verbs=get;list;watch;create;update;patch;delete 重要: この最後の行（pods への権限）がなければ、Operator は権限不足で Pod を作成・削除できません。 5.5.3 Reconcile 関数の実装 Operator の中核となるロジックです。「Get → Observe → Diff & Act → Update Status」のパターンで実装します。 func (r *AppClusterReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) { logger := log.FromContext(ctx) // 1. Get: まず、トリガーとなった AppCluster リソースを取得する var cluster demov1.AppCluster if err := r.Get(ctx, req.NamespacedName, &cluster); err != nil { if apierrors.IsNotFound(err) { // リソースが削除された場合。ガベージコレクションされるのでエラーとして扱わない logger.Info("AppCluster resource not found. Ignoring since object must be deleted") return ctrl.Result{}, nil } logger.Error(err, "unable to fetch AppCluster") return ctrl.Result{}, err } // 2. Observe: 現在の実際状態 (Pod の数) を観測する var podList corev1.PodList // client.MatchingLabels で、この AppCluster が管理する Pod のみを絞り込む if err := r.List(ctx, &podList, client.InNamespace(req.Namespace), client.MatchingLabels{"app": cluster.Name}); err != nil { logger.Error(err, "unable to list pods") return ctrl.Result{}, err } // 3. Diff & Act: 望ましい状態 (Spec.Size) と現在の状態 (podList) を比較し、調整する if int32(len(podList.Items)) < cluster.Spec.Size { // --- Pod が不足している場合、作成する (Act) --- logger.Info("Reconciling: Pod count is less than spec. Creating Pod.") newPod := r.newPodForAppCluster(&cluster) // ★ 必須: OwnerReference を設定する (GC のため) // これにより、AppCluster (親) が削除されたら、この Pod (子) も自動で GC される if err := ctrl.SetControllerReference(&cluster, newPod, r.Scheme); err != nil { logger.Error(err, "unable to set OwnerReference") return ctrl.Result{}, err } if err := r.Create(ctx, newPod); err != nil { logger.Error(err, "unable to create Pod") return ctrl.Result{}, err } // Pod を1つ作成したら、すぐに Requeue (再実行) を要求 // (残りの Pod を作成するため、冪等性を保ちながらループする) return ctrl.Result{Requeue: true}, nil } else if int32(len(podList.Items)) > cluster.Spec.Size { // --- Pod が多すぎる場合、削除する (Act) --- logger.Info("Reconciling: Pod count is more than spec. Deleting Pod.") podToDelete := podList.Items[0] // (単純な例として最初の1つを削除) if err := r.Delete(ctx, &podToDelete); err != nil { logger.Error(err, "unable to delete Pod") return ctrl.Result{}, err } return ctrl.Result{Requeue: true}, nil } // 4. Update Status: 状態が一致した場合、Status を更新する if cluster.Status.Ready != int32(len(podList.Items)) { cluster.Status.Ready = int32(len(podList.Items)) logger.Info("Updating Status", "Ready Pods", cluster.Status.Ready) if err := r.Status().Update(ctx, &cluster); err != nil { // Status 更新はリトライが必要な場合がある logger.Error(err, "unable to update AppCluster status") return ctrl.Result{}, err } } // 状態が一致 (Spec.Size == len(pods)) していれば、何もせず正常終了 logger.Info("Reconciling: Pod count is equal to spec. No action needed.") return ctrl.Result{}, nil} 5.5.4 補助関数 (Pod 定義) の追加 Reconcile 関数の外（同じファイル内）に、Pod のマニフェストを生成するヘルパー関数を追加します。 // newPodForAppCluster creates a Pod definition for the given AppClusterfunc (r *AppClusterReconciler) newPodForAppCluster(cluster *demov1.AppCluster) *corev1.Pod { labels := map[string]string{ "app": cluster.Name, // ★ List 処理で使う重要なラベル } return &corev1.Pod{ ObjectMeta: metav1.ObjectMeta{ GenerateName: cluster.Name + "-pod-", // Pod 名の重複を避けるため GenerateName を使用 Namespace: cluster.Namespace, Labels: labels, }, Spec: corev1.PodSpec{ Containers: []corev1.Container{ { Name: "nginx", Image: "nginx:latest", // Nginx イメージを使用 }, }, }, }} 5.5.5 SetupWithManager の更新 func (r *AppClusterReconciler) SetupWithManager(mgr ctrl.Manager) error { return ctrl.NewControllerManagedBy(mgr). For(&demov1.AppCluster{}). // AppCluster の変更を監視 Owns(&corev1.Pod{}). // ★ AppCluster が所有する Pod の変更も監視 Named("appcluster"). Complete(r)} ポイント: .Owns(&corev1.Pod{}) を追加することで、Pod が手動で削除された時にも Reconcile がトリガーされ、自己修復が可能になります。 5.5.6 CRD の生成とインストール コードが完成したら、依存関係を更新し、CRD と RBAC のマニフェスト（YAML）を生成します。 # Go の依存関係を整理go mod tidy# マニフェスト (CRD, RBAC) を生成make manifests 生成された CRD マニフェストをクラスタにインストールします。 # CRD をクラスタに適用make install 5.5.7 テスト用 CR の準備 config/samples/demo_v1_appcluster.yaml を編集し、テスト用の AppCluster を定義します。 apiVersion: demo.demo.io/v1kind: AppClustermetadata: labels: app.kubernetes.io/name: appcluster name: appcluster-samplespec: # Pod を 2 つ作成するように指定 size: 2 6. Operator の実行とテスト いよいよ Operator をローカルで実行し、動作をテストします。 6.1 起動 Operator（ローカル開発モード） まず、一つのターミナルで make run を実行し、Operator を起動します。 make run ログ（抜粋）: 2025-11-13T07:53:04+01:00 INFO setup starting manager2025-11-13T07:53:04+01:00 INFO Starting EventSource {"controller": "appcluster", "source": "kind source: *v1.Pod"}2025-11-13T07:53:04+01:00 INFO Starting EventSource {"controller": "appcluster", "source": "kind source: *v1.AppCluster"}2025-11-13T07:53:04+01:00 INFO Starting Controller {"controller": "appcluster"}2025-11-13T07:53:04+01:00 INFO Starting workers {"controller": "appcluster", "worker count": 1} Operator が起動し、AppCluster と Pod の監視を開始しました。 6.2 AppCluster リソースの作成 別のターミナルを開き、準備したサンプル CR を kubectl apply します。 $ kubectl apply -f config/samples/demo_v1_appcluster.yamlappcluster.demo.demo.io/appcluster-sample created 6.3 Reconcile ログの観察 make run を実行しているターミナルに戻り、Operator のログを観察します。 2025-11-13T07:53:12+01:00 INFO Reconciling: Pod count is less than spec. Creating Pod.2025-11-13T07:53:12+01:00 INFO Reconciling: Pod count is less than spec. Creating Pod.2025-11-13T07:53:12+01:00 INFO Updating Status {"Ready Pods": 2}2025-11-13T07:53:12+01:00 INFO Reconciling: Pod count is equal to spec. No action needed. ログ分析: size: 2 に対し Pod が 0 だったので、1つ目の Pod を作成 (Creating Pod.) し、Requeue。すぐに 2 回目の Reconcile が走り、Pod が 1 つだったので、2つ目の Pod を作成 (Creating Pod.) し、Requeue。3 回目の Reconcile で Pod が 2 つになったことを確認し、Status.Ready を 2 に更新 (Updating Status)。4 回目の Reconcile で spec.size (2) と len(pods) (2) が一致したので、何もせず終了 (No action needed.)。 6.4 動作確認（Pod と Status） kubectl で Pod と AppCluster の状態を確認します。 $ kubectl get podsNAME READY STATUS RESTARTS AGEappcluster-sample-pod-fpdzg 1/1 Running 0 19sappcluster-sample-pod-l8tf4 1/1 Running 0 19s size: 2 に従って、2つの Pod が作成されました。 $ kubectl get appcluster appcluster-sample -o yaml 出力（抜粋）: spec: size: 2status: ready: 2 # ✅ Status が正しく 2 に更新されている 6.5 自己修復（Self-Healing）のテスト Operator の真価である「自己修復」をテストします。 6.5.1 Pod の手動削除 kubectl delete で Pod のうち1つを強制的に削除します。 $ kubectl delete pod appcluster-sample-pod-fpdzgpod "appcluster-sample-pod-fpdzg" deleted 6.5.2 Operator の自動再作成を観察 make run のログを見ると、Pod の削除を検知（Owns のおかげ）して Reconcile が即座にトリガーされます。 2025-11-13T07:53:55+01:00 INFO Reconciling: Pod count is less than spec. Creating Pod.2025-11-13T07:53:55+01:00 INFO Reconciling: Pod count is equal to spec. No action needed. Operator が「Pod が 1 つ足りない」と判断し、新しい Pod を作成しました。 6.5.3 Pod の回復を確認 kubectl で確認すると、すぐに新しい Pod が作成され、合計2つの状態が維持されています。 $ kubectl get pods -l app=appcluster-sampleNAME READY STATUS RESTARTS AGEappcluster-sample-pod-l8tf4 1/1 Running 0 55sappcluster-sample-pod-wqbv7 1/1 Running 0 12s # ✅ 新しく作成された Pod 6.6 ガベージコレクション（GC）のテスト OwnerReference が正しく機能しているか（自動お片付け）を確認します。 6.6.1 AppCluster の削除 親である AppCluster リソースを削除します。 $ kubectl delete appcluster appcluster-sampleappcluster.demo.demo.io "appcluster-sample" deleted 6.6.2 Pod の自動クリーンアップを確認\ Kubernetes のガベージコレクターが OwnerReference を検知し、関連するすべての Pod を自動で削除します。 $ kubectl get pods -l app=appcluster-sampleNo resources found in default namespace. 関連する Pod がすべて自動的にクリーンアップされました。 7. 核心概念のまとめと次のステップ このチュートリアルで、私たちは強力な Operator パターンの核心に触れました。 7.1 核心概念のまとめ 宣言的API: ユーザーは「どうするか(How)」ではなく「どうあってほしいか(What)」(size: 2)だけを定義します。Reconcile ループ (調停ループ): 「理想 (Spec)」と「現実 (Observe)」の差分を埋め続ける (Diff & Act) という Operator の中核的な動作です。Level-triggered (レベルトリガー): Operator は「何が起きたか(Event)」ではなく、「今どうなっているか(State)」に基づいて動作します。これにより、イベントを見逃しても次のループで必ず自己修復できます。OwnerReference (所有者参照): SetControllerReference で設定した親子関係により、親（AppCluster）を削除するだけで子（Pod）が自動的に削除されるガベージコレクションを実現しました。Owns による監視: SetupWithManager で .Owns(&corev1.Pod{}) を設定することで、子の Pod が削除された際にも Reconcile がトリガーされ、自己修復が可能になりました。 7.2 プロジェクト構造 appcluster-operator/├── api/v1/│ ├── appcluster_types.go # CRD 定義 (Spec, Status)│ └── ...├── internal/controller/│ └── appcluster_controller.go # ★ Reconcile ロジックの核心├── config/│ ├── crd/bases/ # 生成された CRD (YAML)│ ├── rbac/ # 生成された RBAC (Role, RoleBinding YAML)│ └── samples/ # テスト用のサンプル CR├── cmd/main.go # プログラムの開始点 (Manager の起動)├── Makefile # (run, install, deploy などの便利コマンド)└── go.mod # Go の依存関係 7.3 本番環境へのデプロイ このチュートリアルでは make run を使い、ローカル PC 上で Operator を実行しました（デバッグに便利）。 本番環境では、Operator 自体もコンテナイメージとしてビルドし、Kubernetes クラスター内で Deployment として実行します。 # 1. Docker イメージをビルドし、レジストリに PUSHmake docker-build docker-push IMG=<your-registry/image-name:tag># 2. Operator を Deployment としてクラスタにデプロイmake deploy IMG=<your-registry/image-name:tag> 8. サマリー 本記事では、「なぜ Kubernetes Operator が必要なのか」という根本的な動機から始まり、Operator を支える中核的な理論、そして Operator SDK を利用した実践的な開発手法まで、ステップバイステップで詳細に解説しました。まず、Kubernetes 自身がコンテナの「デプロイ（Day 1）」を自動化する強力なプラットフォームである一方、データベースのバックアップやフェイルオーバーといった複雑な「運用（Day 2）」にはドメイン固有の知識が必要であり、それをソフトウェアとして実装する仕組みが Operator パターンであることを学びました。次に、Operator の「脳」として機能するReconcile ループ（調停ループ）の概念を深く掘り下げました。Operator は「Spec（望ましい状態）」と「Status（実際の状態）」の差分を常に監視し、その差分を埋めるために動作（Act）し続けます。このループは「冪等性（Idempotency）」を担保するように設計する必要があり、controller-runtime がその複雑な仕組み（イベント監視、リトライ）の多くを抽象化してくれることも理解しました。開発ツールのレイヤー構造（低レベルな client-go、中核エンジンの controller-runtime、雛形ツールの Operator SDK）を整理した後、私たちは実際に AppCluster という Operator をゼロから構築しました。実践編では、以下の重要なステップを実行しました。 operator-sdk init と create api でプロジェクトの雛形を作成。api/.../types.go で Spec と Status を定義。internal/controller/.../controller.go で Reconcile 関数（Get → Observe → Diff & Act → Update Status）を実装。RBAC マーカー（//+kubebuilder:rbac）で Pod への操作権限を付与。OwnerReference（SetControllerReference）を設定し、自動ガベージコレクション（GC）を実現。SetupWithManager で .Owns(&corev1.Pod{}) を設定し、Pod 削除時の自動「自己修復（Self-Healing）」を実現。 最後に、make run で Operator をローカル実行し、kubectl apply で AppCluster を作成すると Pod が自動生成されること、Pod を手動で削除しても即座に再作成されること、そして AppCluster を削除すると関連する Pod も一掃されることを確認しました。このチュートリアルを通じて、Kubernetes の宣言的APIの裏側で動くコントローラーモデルの強力さと、面倒な手動運用を自動化する Operator 開発の基本的な流れを完全に習得できたはずです。

AI 研究の世界で、ゲーム領域から現実世界へ技術をスケールさせる挑戦は多く語られてきました。しかし実際に、ゲームで育てたAIを“公道を走る自動運転AI”に進化させた研究者はそう多くありません。第5回京大ミートアップ＜後編＞は、強化学習の“限界”に挑むTuring妹尾氏のセッションをご紹介します。 Session3 『強化学習の限界を探る E2E 自動運転開発』 妹尾 卓磨 氏Turing株式会社 スタッフリサーチャー SONY時代：ゲームの中に“最強レーサーAI”を生み出す 妹尾氏がまず向き合ったのは、ソニーのレースゲーム「グランツーリスモ」を舞台に、強化学習で世界最強レーサーを超えるAI「GT Sophy」を作るプロジェクトでした。このAIはただ速いだけでなく、レースマナーまで理解し、人間のトッププレイヤーを凌駕。成果はNature誌に掲載され、世界的に注目されました。特に象徴的だったのが、その学習環境です。 SONY社内クラウドで大量の PlayStation を同時稼働 AI が自力でレースを“何十万回も走り続ける”訓練環境 制御・戦略・接触回避など複雑な行動を統合的に学習 つまり「大規模シミュレーション × 強化学習 × 実行環境のスケール」の力を最大限活用した研究でした。この経験が、後の自動運転研究の大きな土台となります。 Turingでの挑戦：公道を走る“学習型ドライバーAI”へ Turing転職後、妹尾氏が挑んでいるのは 画像入力のみで運転判断を行うEnd-to-End自動運転。技術はすでに高難度の走行レベルに到達していて、さらにその先を目指す技術基盤を構築しているとのことでした。 実写級3D再構成シミュレーター「ATLAS」 3D Gaussian Splatting技術を用いて、 実車走行の映像をそのまま3D化 任意の視点で自由に再シミュレーション “歩行者がいる左折1000シナリオ”などを自動生成 といった“現実をコピーして量産する”次世代シミュレーション環境を構築。これにより、従来のゲームエンジンでは再現困難だった複雑な運転状況でも、大量の学習データを瞬時に生成できます。 大規模計算資源 × 強化学習 Turingでは全体として富岳の約40％に相当する計算リソースを保有しており、この計算基盤があるからこそ、必要なタイミングで数百〜数千並列の強化学習実験を回せる環境が整っています。強化学習を活用することで、失敗から学ぶことや、運転行動の因果関係を捉えること、制御まで含めた最適化が可能になります。その結果、これまで苦手だった右折動作などについても改善が進み、入社後わずか3カ月で日本初となるE2E強化学習モデルの公道走行を実現しました。 次の一歩：VLA（Vision-Language-Action）モデルへ Turingはさらに、画像・言語・制御を統合した VLAモデル へと研究を拡大しています。これにより、 シーンを言語で説明しながら状況判断 レアケースにも柔軟に対応 “説明可能な自動運転AI” の可能性 が開けつつあり、“どんな状況でも運転できるAIドライバー”へ向けた布石が打たれています。 強化学習は、ゲームを越え、現実へ踏み出した ゲームの中で鍛えたAIが、現実世界で人と一緒に道路を走り始めようとしています。妹尾氏の挑戦は、強化学習が持つ“試行錯誤の力”を最大化しながら、その限界を押し広げていくプロセスそのものでした。ゲームから公道へ。 AIが“運転を学ぶ”時代は、もう始まっています。 妹尾氏のセッション映像はこちらから https://www.youtube.com/watch?v=iuv6X_oBBsE

GMOインターネットグループ株式会社・グループ研究開発本部の A.T です。今回は25新卒同期の藤間裕史さん（X）とともに、現地参加に先立ち、CES 2026の注目技術やトレンドを整理した事前調査レポートをお届けします。なお、現地参加後には藤間さんとともに CES 2026参加報告会 も実施予定です。実際に現地で得た知見とあわせて共有しますので、ぜひご参加ください。 はじめに 「2026年はヒューマノイド元年だ」——弊社 熊谷代表の言葉にもあるように、世界ではフィジカルAI／ヒューマノイドロボットの開発競争が加速しています（参考：日経ビジネスの記事）。その動向を最速で体感できるイベントの一つがCES（Consumer Electronics Show）です。CESは世界最大級のテックイベントで、スタートアップから大企業までが最新技術を発表・展示します。 特に昨年のCES 2025では、NVIDIAのCEOであるジェンスン・ファン氏がずらりと並ぶヒューマノイドロボットと共に「汎用ロボットの時代はもうそこまで来ている」と発言したことで、ヒューマノイドロボットの重要性が世界中に広まりました（参考：NVIDIA公式ブログ）。 本日のテーマ 本記事では、CES 2026の参加前に「CES 2026で展示が予定されているヒューマノイド関連企業」を事前調査し、注目すべき企業をピックアップしました。 https://twitter.com/CyberRobooo/status/2005638902061637734?s=20 引用元：X（@CyberRobooo） Unitree 現在、会場で見かける率が高い人型ロボットメーカーの一社。弊社でもG1を複数台使っており、動きの良さと手の届きやすさが魅力です。IREX2025では最新機H2も公開されていたので、CESでは実機デモでの仕上がりに注目です。 出典：Unitree公式サイト（H2） EngineAI ダイナミックでパワフルな動きのデモが得意なEngineAI。宙返りで注目されたPM01に加え、最新機種のT800がCEOを蹴り飛ばす動画などでも話題が尽きません（参考：Business Insider）。弊社もPM01を所有しているので、CESで何を見せてくるか楽しみです。 出典：ロボスタ LimX Dynamics 「人型」だけでなく、“変形できる二足プラットフォーム”として要注目なのがLimX Dynamics。TRON 2は、双腕／二足／車輪などをモジュールで切り替えられるのが面白いところ。研究用途でいろいろ試せそうで、現地で実機を触れるなら触りたい枠です。 出典：TRON公式（TRON 2発表） Deep Robotics 四足ロボットで知られるDEEP Roboticsも、人型のDR01を公開しています（参考：公式サイト）。歩行速度や段差・斜面対応など、現場動作を念頭に置いたスペックを前面に出している印象です。 出典：DEEP Robotics公式（DR01） LG 家電大手のLGが、家庭内タスクをこなすホームロボット「LG CLOiD」をCES 2026で初披露すると発表しました（参考：LG公式リリース）。Zero Labor Home（家事ゼロ）を掲げていて、情報はまだ少なめですが、会場でどこまで実作業を見せるかが見どころになりそうです。見た目はFourier GR-3に似た可愛いタイプに見えますね。 出典：LG公式リリース Boston Dynamics ロボット界の老舗中の老舗。Hyundai傘下で、Atlasは油圧機から全電動へ刷新され、実作業を見据えた方向に舵を切っています。最新AtlasがCESで展示されることも発表されています（参考：Hyundai Newsroom）。 出典：Boston Dynamics Agility Robotics 物流・倉庫の現場投入を本気で進めているのがAgility Robotics。二足ロボット「Digit」を軸に、量産に向けた専用工場RoboFabも公開しています（参考：公式ブログ）。研究デモから実地運用へ移る勢いがあるので、現地で実装のリアルを吸収したいところです。 出典：日本経済新聞 Realbotix 人と会話して関係性を築くコンパニオン系に強いRealbotix。外見のリアルさだけでなく、複数AIとつなぎ替えられる設計や、キャラクターとして発信する「Aria」なども特徴です（参考：公式サイト）。CESでは体験導線（会話・表情・反応速度）を見たいです。 出典：YouTube（Realbotix公式） まとめ CES 2026では、紹介した企業以外にも多数のヒューマノイドロボットが展示される予定です。全力で展示会を楽しんできますので、ぜひ参加報告編も楽しみにしていてください。 最後に、GMOインターネットグループでは、こうした先端的なAIロボット技術にも積極的に取り組んでいます。もしご興味がある方がいれば、ぜひ共に次の時代を創っていきましょう！

2025年12月12日、京都大学 学術情報メディアセンター 南館4Fにて、「第5回 京大ミートアップ supported by GMO」が開催されました。このイベントは、京都大学 首藤研究室とGMOインターネットグループが共催し、アカデミアとビジネスの垣根を越え、AI・ブロックチェーン・サイバーセキュリティなど先端テクノロジーの「実践知」を学ぶことを目的としています。今回は、こちらのイベント開催レポート前編・後編に分けてお届けします。 イベント概要 第5回 京大ミートアップ supported by GMOフィジカルAI最前線：自動運転・ヒューマノイドロボット・人とロボットの対話 日時：2025年12月12日（金）17:30～20:20場所：京都大学 学術情報メディアセンター 南館4F参加費：無料（学生限定、学生証提示あり）形式：現地＋オンライン配信、懇親会あり（飲食提供）https://kmu.connpass.com/event/372639/ Session1『ヒューマノイドの社会実装に向けた取り組みと技術的な課題』 滝澤 照太GMOインターネットグループ株式会社 まず1つ目の発表は、GMOインターネットグループの滝澤より当社が取り組むヒューマノイドロボット開発の最新状況と、その裏側で直面している技術・運用上の課題についてご紹介しました。滝澤は G R & D 本部として、グループ会社であるGMO AI & ロボティクス商事株式会社（通称GMO AIR）が展開するヒューマノイド事業を技術面から支援しており、派遣サービスや展示会運用など、多くの実働フィールドでロボットを動かしてきた経験を踏まえてお話ししました。 まず、国際ロボット展2025で披露したダンス・給仕・箱運搬などのデモを例に、ヒューマノイドの「運用の難しさ」が語られました。機体の重量や姿勢調整の大変さ、安全性・音・振動など、実際に現場へ持ち込むと見えてくる課題は多くあります。また、現在流通しているヒューマノイドは研究用が中心で、二次開発が必須である点も課題として挙げられました。 技術面では、低減速比モーターによる高い応答性やバックドライバビリティの重要性、さらにヒューマノイド制御に欠かせない運動学・逆運動学の考え方を解説しました。特に展示会で披露した“ダンス”は、モーションキャプチャー → リターゲティング → 強化学習モデル構築 → 実機デプロイというプロセスで実現しており、その技術的チャレンジが紹介されました。 最後に、滑りやすさやすり足への弱さなど、今回作成したモデルが抱える課題、産業利用に向けた安定化・省力化の必要性、そして従来のロボット技術との共存の重要性に触れ、GMOとして今後もヒューマノイド技術に注力していく姿勢をお伝えしました。 滝澤のセッション映像はこちらから https://www.youtube.com/watch?v=s2hlvpZ1vKQ Session2 『LLMを活用した教育ロボット研究事例紹介』 東風上 奏絵 氏京都大学 大学院情報学研究科 特定助教 京都大学ヒューマンロボットインタラクション研究室の東風上氏は、教育ロボットと大規模言語モデル（LLM）を組み合わせた最新研究を紹介しました。テーマは“大学の授業を学生と一緒に受講し、その場で質問を生成するロボット”。これまで主流だった子ども向け教育ロボットから一歩進み、**大人の集団授業でロボットは受け入れられるのか？**という挑戦的な問いに正面から取り組んだ研究です。 研究の出発点は、大学の授業が「静かすぎる」という問題意識。教員の多くは本来、学生の発言を促したいが、質問がないか問いかけても教室は静まり返ってしまうそう。そこで東風上氏は、ロボットが“同級生”として授業に参加し、教員が質問してほしいタイミングで質問をしてくれる仕組みを考案しました。 10名の大学教員へのインタビューを通じ、　① 質問するタイミングは教員が指定する　② 質問のタイプ（簡単・思考刺激・批判など）は教員が選ぶ　③ 質問内容はその場でLLMが生成するという“半操縦型デザイン”に到達。講義音声をリアルタイムに要約し、8種類の質問タイプに応じてLLMが動的に質問文を作り出す仕組みを構築しました。 実際に大学4クラスでロボットを運用したところ、学生が積極的に発言し始めるまでには至らなかったものの、ロボットが質問する瞬間には興味を示す様子が観察されました。教員からは「質問が生まれそうな空気ができた」「授業の振り返りに役立つ」と好意的な反応が寄せられたそうです。 研究はまだ初期段階ではあるものの、ロボットが授業に参加し、人の学びを後押しする未来が現実味を帯びつつあるそう。今後の発展が待ち遠しい領域です。 ｽﾀｯｸﾁｬﾝを用いた実演 東風上氏のセッション映像はこちらから https://www.youtube.com/watch?v=x4J3GnZ6aZs 前編はここまでです。お読みいただきありがとうございました！後編では、Turing妹尾氏のセッションを中心にご紹介します。

こんにちは。GMOインターネット株式会社の長谷川です。プロジェクト統括チームに所属しており、普段はプロジェクトマネジメント業務を担当し、プロジェクトの進捗管理や課題管理を行っています。元々はプログラマーを行っておりましたが、最近はプログラムに触れる機会が少なくなり、AIを用いた開発ってどんなんだろう、と思う機会が多くあります。Devinを用いたバイブコーディングを試したこともありますが、簡単なツールは作れるが、完成度の高いものを残すには、設計部分で不安があるという課題を感じていました。そこで浮かんだ仮説が、「設計をしっかりしたものから作ってもらえば、完成度の高いものになるのではないか?」というものです。この仮説を検証するため、ClaudeとDevinを組み合わせた開発を試してみました。今回は、その結果をご紹介したいと思います。 記事の対象者 本記事は、PHPやLaravelフレームワークに少し知識がある方であれば理解できる内容となっております。また、過去にプログラミングを行っていただけれども、最近あまり触れていないなどの方も今後のコーディング手段としてご利用できる内容となっております。 注意点 本記事の情報は、著者の個人的な見解に基づくものであり、正確性などを保証するものではありません。 今回の実施内容 テキストファイルに記載されたURLリストを読み込み、各URLにアクセスしてコンテンツを取得・データベースに保存する試験的なプログラムです。Laravel上で3層アーキテクチャを採用し、非同期処理(Queue)を活用した実装を行いました。 実行環境 AIツール: Claude Sonnet4、DevinOS: AlmaLinux 9.6 (Sage Margay)PHP: 8.1.33Framework: Laravel 10.49.0Database: MySQL 8.0.43Queue Driver: DatabaseVersion Control: Git + GitHub 開発フロー 【設計フェーズ】Claudeで壁打ち&設計書作成(約2時間) 初期の指示内容 まず、Claudで壁打ちを実施し、クラス図を作成、そこまでの壁打ち内容とクラス図をインプットにREADME.mdを作成してもらいました。 クラス図の作成 壁打ちの結果を基に、Draw.ioでクラス図を作成しました。 主要なクラス構成: Presentation Layer: RegisterDomainCommandDomain Layer: DomainService, HttpClientService, エンティティ群Infrastructure Layer: Domain Model, DomainRepositoryEloquent README.md内容 最下部に記載 【実装フェーズ】Devinでコーディング(約30分) 初回実装 README.mdをDevinに読み込ませて実装を依頼したところ、約3分で基本的な実装が完了しました。 発生した課題と対応 課題1: Callbackの実装不備 ファイル処理のCallback部分が正しく実装されていませんでした。 public function processFileLines(string $filePath): ProcessResult { if (!file_exists($filePath)) { return new ProcessResult(0, 1, ['File not found: ' . $filePath]); } $lines = file($filePath, FILE_IGNORE_NEW_LINES | FILE_SKIP_EMPTY_LINES); $successCount = 0; $errorCount = 0; $errors = []; foreach ($lines as $line) { $line = trim($line); if (empty($line) || str_starts_with($line, '#')) { continue; } if ($this->isValidDomain($line)) { $this->dispatchProcessDomainCheck($line); $successCount++; } else { $errorCount++; $errors[] = "Invalid domain format: {$line}"; } } return new ProcessResult($successCount, $errorCount, $errors); } コールバック用のメソッドとして以下を定義していたため、こちらを利用してファイル読み込み処理をコールバック処理にするように指示しました。 - processFileLines($filePath: string, $callback: Closure($lineNumber: int, $line: string)): void 結果、思ったよりもスムーズにコードの生成を実施してくれました。 public function processFileLines(string $file_path): ProcessResultEntity { if (!file_exists($file_path)) { return new ProcessResultEntity(false, 0, 1, ['File not found: ' . $file_path]); } $successCount = 0; $errorCount = 0; $errors = []; $this->__processFileLines($file_path, function(int $line_number, string $line) use (&$successCount, &$errorCount, &$errors) { $line = trim($line); if (empty($line) || str_starts_with($line, '#')) { return; } if ($this->isValidDomain($line)) { $this->dispatchProcessDomainCheck($line); $successCount++; } else { $errorCount++; $errors[] = "Invalid domain format: {$line}"; } }); return new ProcessResultEntity($errorCount === 0, $successCount, $errorCount, $errors); } private function __processFileLines(string $file_path, callable $callback): void { $handle = fopen($file_path, 'r'); if ($handle === false) { return; } try { $line_number = 0; while (($line = fgets($handle)) !== false) { $line_number++; $line = rtrim($line, "\r\n"); $callback($line_number, $line); } } finally { fclose($handle); } } 課題2: エラーハンドリング不足 URLにアクセスできない場合の処理が未実装でした。 対応: 以下の要件を追加指示 接続失敗時はスキップして次のURLへエラー内容をログに記録504 Gateway Timeoutとして統一処理 完成 待ち時間含めて30分程度で、実装が完成しました。 工数比較 項目従来の方法Claude × Devin削減率設計4時間2時間50%実装4時間0.5時間88%合計8時間2.5時間69% 通常であれば、8時間ぐらいかかるかな思いますが、今回のアプローチでは2.5時間で完了しました。 品質面での発見 良かった点: 実装が高速: READMEが明確だったため、Devinの実装が迅速だったコードの一貫性: アーキテクチャに沿った実装が保たれた 課題点: 初回実装の細かい漏れ: CallbackやエラーハンドリングなどDevinの実装には細部の見直しが必要README品質への依存: 設計書が不明瞭だと実装品質が下がる可能性 学びとポイント Claudeの得意なこと 設計の壁打ち相手: 曖昧な要件を対話で詰めていけるドキュメント作成: READMEの作成が得意 Devinの得意なこと 「どう作るか」の実行: 明確な設計書があれば高速に実装できる定型コードの量産: ボイラープレートコードの生成が速い基本的な実装: 標準的なパターンに沿った実装は安定している 分業のコツ Claudeで設計を固める: 実装前に設計を丁寧に作成するREADMEを丁寧に書く: Devinへの指示書として機能する設計書を作る検証と修正を織り込む: Devinの初回実装は60点と想定し、レビューと修正を前提とする 実装の詳細 Repository Patternの採用 インフラ層への依存を抽象化するため、Repository Patternを採用しました。当たり前かもしれませんが、Providersへの登録も行ってくれています。 // ドメイン層にインターフェースを定義 interface DomainRepository { public function findByUrl(string $url): ?DomainEntity; public function create(DomainEntity $domain): void; public function update(DomainEntity $domain): void; } // インフラ層で実装 class DomainRepositoryEloquent implements DomainRepository { // Eloquentを使った実装 } 今後の展望 さらなる改善の余地 テストコードの生成: 設計書からテストケースも生成できるか検証エラーハンドリング処理: エラーハンドリングの自動実装より複雑な要件での検証: マイクロサービスなど複雑なアーキテクチャでの適用 まとめ Claudeで設計、Devinで実装で比較的短時間で飽きることなく開発できました。まだ、試験的な利用しないツールの開発という意味のわからない実装をしてしまったため、次回は同じアプローチで実際に利用するツール開発を行いたいと思います。 プロジェクトマネージャーとして10年ぶりに本格的なコーディングに取り組んだ結果、AIとの協働によって、設計力を活かしながら実装速度を大幅に向上させるという新しい働き方の可能性を感じました。 みなさんも、ぜひこのアプローチを試してみてください。 次回も機会があれば、生成AIの活用方法について紹介していきますので、お楽しみにしてください。 README内容 # ドメインチェックプロジェクト設計書 ## プロジェクト概要 AlmaLinux 9.6 環境上で Laravel を使用したドメインチェック機能の実装。 TXTファイルからドメインリストを読み込み、HTTP接続確認を非同期で実行する。 --- ## 技術スタック ### 基盤環境 - **OS**: AlmaLinux 9.6 (Sage Margay) - **PHP**: 8.1.33 - **Framework**: Laravel 10.49.0 - **Database**: MySQL 8.0.43 - **Queue Driver**: Database - **Version Control**: Git + GitHub ### 外部ライブラリ - **HTTP Client**: Guzzle HTTP 7.x - **ORM**: Eloquent (Laravel標準) --- ## アーキテクチャ設計 ### パッケージ構成 ``` App/ ├── Console/Commands/ # Artisanコマンド │ └── RegisterDomainCommand ├── Domain/Monitoring/ # ドメイン監視ドメイン層 │ ├── Entities/ │ │ ├── DomainEntity # ドメインエンティティ │ │ └── ProcessResultEntity # 処理結果エンティティ │ ├── ValueObjects/ # 値オブジェクト │ │ └── HttpResponse │ ├── Services/ # ドメインサービス │ │ ├── HttpClientService │ │ └── DomainService │ └── Repositories/ # データアクセス抽象化 │ ├── DomainRepository (interface) │ └── TransactionManager (interface) ├── Infrastructure/Monitoring/ # インフラストラクチャ層 │ ├── Models/ # Eloquentモデル │ │ └── Domain │ └── Repositories/ # リポジトリ実装 │ ├── DomainRepositoryEloquent │ └── TransactionManagerEloquent # トランザクション管理実装 └── Jobs/ # 非同期処理 └── ProcessDomainCheckJob ``` ### 主要クラス #### 1. RegisterDomainCommand **責任**: TXTファイルからドメインリストを読み込み、ドメインチェックジョブを実行 - **名前空間**: `App\Console\Commands\` - **主要メソッド**: - `handle(): int` - コマンド実行メイン処理 - `validateFilePath($file_path: string): bool` - ファイルパス検証 - `displaySuccessResult($result: ProcessResultEntity): void` - 成功結果表示 - `displayErrorResult($result: ProcessResultEntity): void` - エラー結果表示 #### 2. DomainService **責任**: ドメインチェックのビジネスロジック統括 - **名前空間**: `App\Domain\Monitoring\Services\` - **依存関係**: HttpClientService, DomainRepository, TransactionManager - **主要メソッド**: - `processFileLines($file_path: string): ProcessResultEntity` - ファイル処理 - `checkDomain($url: string): bool` - ドメインチェック実行 - `__processFileLines($file_path: string, $callback: Closure($line_number: int, $line: string)): void` - ファイル行処理 - `dispatchProcessDomainCheck($url: string): void` - ジョブディスパッチ #### 3. HttpClientService **責任**: HTTP通信の抽象化 - **名前空間**: `App\Domain\Monitoring\Services\` - **依存関係**: Guzzle HTTP Client - **主要メソッド**: - `__construct($config: array = []): void` - 設定付きコンストラクタ - `get($url: string, $config: array = []): HttpResponse` - HTTP GET リクエスト #### 4. DomainEntity **責任**: ドメイン情報のデータ構造（ドメイン層エンティティ） - **名前空間**: `App\Domain\Monitoring\Entities\` - **属性**: - `$url: string` - ドメインURL - `$name?: string` - 名前 - `$status_code?: int` - HTTPステータスコード - `$contents?: string` - コンテンツ情報 - `$body?: string` - レスポンスボディ #### 5. ProcessResultEntity **責任**: ドメインサービスの処理結果（ドメイン層エンティティ） - **名前空間**: `App\Domain\Monitoring\Entities\` - **属性**: - `$success: bool` - 処理結果 - `$success_count: int` - 成功件数 - `$error_count: int` - 失敗件数 - `$errors: array = []` - 失敗内容 #### 6. ProcessDomainCheckJob **責任**: 非同期ドメインチェック処理 - **名前空間**: `App\Jobs\` - **属性**: - `$url: string` - チェック対象URL #### 7. DomainRepository (Interface + Implementation) **責任**: ドメインデータの永続化 - **インターフェース**: `App\Domain\Monitoring\Repositories\DomainRepository` - **実装**: `App\Infrastructure\Monitoring\Repositories\DomainRepositoryEloquent` #### 8. Domain (Eloquent Model) **責任**: データベースとのORM マッピング - **名前空間**: `App\Infrastructure\Monitoring\Models\` - **継承**: `Illuminate\Database\Eloquent\Model` #### 9. HttpResponse **責任**: HTTP レスポンス情報の値オブジェクト - **名前空間**: `App\Domain\Monitoring\ValueObjects\` - **属性**: - `$status_code: int` - HTTPステータスコード - `$body: string` - レスポンスボディ #### 10. TransactionManager (Interface + Implementation) **責任**: データベーストランザクションの管理と抽象化 - **インターフェース**: `App\Domain\Monitoring\Repositories\TransactionManager` - **実装**: `App\Infrastructure\Monitoring\Repositories\TransactionManagerEloquent` - **主要メソッド**: - `transaction(callable $callback): mixed` - トランザクション内で処理を実行 - `begin(): void` - トランザクション開始 - `commit(): void` - トランザクションコミット - `rollback(): void` - トランザクションロールバック **配置の理由**: - インターフェースをDomain層のRepositoriesに配置（DomainRepositoryと同じパターン） - 実装をInfrastructure層のRepositoriesに配置（DomainRepositoryEloquentと同じパターン） - テスタビリティの向上（モック可能） --- ## 機能仕様 ### 1. ドメインチェック機能 - **入力**: TXTファイル（ドメインリスト） - **処理**: HTTP/HTTPS接続確認 - **出力**: データベースへ結果保存 - **トランザクション**: 複数ドメインの一括登録時に一貫性を保証 ### 2. ファイル処理仕様 **対応形式**: テキストファイル (.txt) ```txt example.com google.com github.com # これはコメント（#で始まる行はスキップ） https://www.microsoft.com http://stackoverflow.com facebook.com https://qiita.com/tags/laravel amazon.co.jp https://docs.laravel.com/10.x invalid-domain-test twitter.com https://claude.ai http://example.org/path/to/page ``` **処理ルール**: - 改行文字・空白の自動削除 - 空行をスキップ - コメント行（# 開始）をスキップ - ドメイン形式の簡易バリデーション ### 3. HTTP接続チェック仕様 **プロトコル**: HTTPS → HTTP の順で試行 ```php $urls = [ "https://{$domain}", "http://{$domain}" ]; ``` **タイムアウト設定**: - **接続タイムアウト**: 5秒 - **レスポンスタイムアウト**: 10秒 **成功判定**: ステータスコード 2xx, 3xx **エラー処理**: 504 Gateway Timeout として統一処理 ### 4. 非同期処理 - **Queue Driver**: Database - **Job**: ProcessDomainCheckJob - **再試行**: エラー時60秒後に再実行 - **結果保存**: 成功・失敗・エラーをデータベースに記録 --- ## データベース設計 ### テーブル構成 ```sql -- ドメイン情報 CREATE TABLE domains ( id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, url VARCHAR(255) NOT NULL, name VARCHAR(255), status_code INT, contents TEXT, body TEXT, created_at TIMESTAMP, updated_at TIMESTAMP, INDEX idx_url (url) ); -- ジョブキュー（Laravel標準） CREATE TABLE jobs ( id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, queue VARCHAR(255) NOT NULL, payload LONGTEXT NOT NULL, attempts TINYINT UNSIGNED NOT NULL, reserved_at TIMESTAMP NULL, available_at TIMESTAMP NOT NULL, created_at TIMESTAMP NOT NULL, INDEX jobs_queue_index (queue) ); ``` ### データベース認証情報 ```env DB_CONNECTION=mysql DB_HOST=127.0.0.1 DB_PORT=3306 DB_DATABASE=domain_check DB_USERNAME=u_domain_check DB_PASSWORD=DomainCheck2025! ``` --- ## 実装順序 ### Phase 1: 基盤構築 1. **データベース・マイグレーション** ```bash php artisan make:migration create_domains_table php artisan migrate ``` 2. **基本モデル作成** ```bash php artisan make:model Domain ``` ### Phase 2: インフラストラクチャ層 3. **TransactionManager実装** - インターフェース定義: `App\Domain\Monitoring\Repositories\TransactionManager` - Laravel実装: `App\Infrastructure\Monitoring\Repositories\TransactionManagerEloquent` - ServiceProviderへの登録 ### Phase 3: ドメイン層 4. **ValueObjects実装** - HttpResponse値オブジェクト: `App\Domain\Monitoring\ValueObjects\HttpResponse` 5. **HttpClientService実装** - 名前空間: `App\Domain\Monitoring\Services\HttpClientService` - Guzzle HTTP設定 - エラーハンドリング実装 6. **DomainRepository実装** - インターフェース定義: `App\Domain\Monitoring\Repositories\DomainRepository` - Eloquent実装: `App\Infrastructure\Monitoring\Repositories\DomainRepositoryEloquent` ### Phase 4: ビジネスロジック 7. **DomainService実装** - 名前空間: `App\Domain\Monitoring\Services\DomainService` - ファイル処理ロジック - ドメインチェック処理 - TransactionManagerを利用したトランザクション管理 8. **ProcessDomainCheckJob実装** ```bash php artisan make:job ProcessDomainCheckJob ``` ### Phase 5: UI・コマンド 9. **RegisterDomainCommand実装** ```bash php artisan make:command RegisterDomainCommand ``` 10. **動作確認・テスト** --- ## 運用・保守 ### コマンド実行例 ```bash # ドメインチェック実行 php artisan domain:register /path/to/domains.txt # キューワーカー起動 php artisan queue:work # ジョブ状況確認 php artisan queue:monitor ``` ### ログ・監視 - **アプリケーションログ**: `storage/logs/laravel.log` - **ジョブ失敗ログ**: `failed_jobs` テーブル - **処理進捗**: コマンド出力＋データベース状態 ### セキュリティ考慮事項 - SSL証明書検証の適切な設定 - レート制限によるサーバー負荷軽減 - Personal Access Tokenの安全な管理 - データベース認証情報の適切な保護 --- ## 今後の拡張可能性 ### 機能拡張 - **Webインターフェース**: ファイルアップロード＋結果表示画面 - **API化**: RESTful API提供 - **レポート機能**: CSV・PDF出力 - **スケジュール実行**: 定期的なドメインチェック ### 技術改善 - **Redis Queue**: 高パフォーマンス化 - **並列処理**: マルチプロセス対応 - **WHOIS連携**: より詳細なドメイン情報取得 - **Docker化**: 環境構築の標準化 --- ## 参考資料 - [Laravel Setup Guide](laravel-setup-guide.md) - 環境構築手順 - [Laravel Documentation](https://laravel.com/docs) - 公式ドキュメント - [Guzzle HTTP Documentation](https://docs.guzzlephp.org/) - HTTP Client仕様 --- # Laravel Domain Check プロジェクト クラス設計 ## 📁 パッケージ構成 ### App\Console\Commands ```php class RegisterDomainCommand extends Command { - string $signature - string $description - DomainService $domainService + handle(): int + validateFilePath($file_path: string): bool + displaySuccessResult($result: ProcessResult): void + displayErrorResult($result: ProcessResult): void } ``` ### App\Domain\Monitoring\Services #### DomainService ```php class DomainService { - HttpClientService $http_client_service - DomainRepository $domain_repository - TransactionManager $transaction_manager + processFileLines($file_path: string): ProcessResult - checkDomain($url: string): bool - __processFileLines($file_path: string, $callback: Closure($line_number: int, $line: string)): void - dispatchProcessDomainCheck($url: string): void } ``` #### HttpClientService ```php class HttpClientService { - Client $client + __construct($config: array = []): void + get($url: string, $config: array = []): HttpResponse } ``` ### App\Domain\Monitoring\Entities #### DomainEntity ```php class DomainEntity { - string $url - string $name - int $status_code - string $contents - string $body + __construct($url: string, $name?: string, $status_code?: int, $contents?: string, $body?: string): void + getUrl(): string + getName(): ?string + getStatusCode(): ?int + getContents(): ?string + getBody(): ?string } ``` #### ProcessResult ```php class ProcessResult { - bool $success - int $success_count - int $errorCount - array $errors + __construct($success: bool, $success_count: int, $error_count: int, $errros: array = []): void + isSuccess(): bool + getSuccessCount(): int + getErrorCount(): int + getErrors(): array = [] } ``` ### App\Domain\Monitoring\ValueObjects #### HttpResponse ```php class HttpResponse { - int $status_code - string $body + __construct($status_code: int, $body?: string): void + getStatusCode(): int + getBody(): ?string } ``` ### App\Domain\Monitoring\Repositories #### DomainRepository (Interface) ```php interface DomainRepository { + findByUrl($url: string): ?DomainEntity + create(DomainEntity): void + update(DomainEntity): void + delete(DomainEntity): void } ``` #### TransactionManager (Interface) ```php interface TransactionManager { + transaction(callable $callback): mixed + begin(): void + commit(): void + rollback(): void } ``` ### App\Infrastructure\Monitoring\Models #### Domain (Eloquent Model) ```php class Domain extends Model { + int $id + string $url + string $name + int $status_code + string $contents + string $body + timestamps + array $fillable + array $casts } ``` ### App\Infrastructure\Monitoring\Repositories #### DomainRepositoryEloquent ```php class DomainRepositoryEloquent implements DomainRepository { - Domain $model + findByUrl($url: string): ?DomainEntity + create($domain_entity: DomainEntity): void + update($domain_entity: DomainEntity): void + delete($domain_entity: DomainEntity): void - modelToEntity($domain: Domain): DomainEntity - entityToModel($domain_entity: DomainEntity): Domain } ``` #### TransactionManagerEloquent ```php class TransactionManager implements \App\Domain\Monitoring\Repositories\TransactionManager { + transaction(callable $callback): mixed + begin(): void + commit(): void + rollback(): void } ``` ### App\Jobs #### ProcessDomainCheckJob ```php class ProcessDomainCheckJob implements ShouldQueue { + string $url + __construct($url: string): void + handle($domain_service: DomainService): void } ``` --- ## 🔗 クラス関係図 ### 依存関係 - `RegisterDomainCommand` → `DomainService` - `DomainService` → `HttpClientService` - `DomainService` → `DomainRepository` - `DomainService` → `TransactionManager` - `DomainService` → `ProcessDomainCheckJob` - `HttpClientService` → `HttpResponse` - `DomainRepositoryEloquent` → `Domain` (Eloquent Model) - `DomainRepositoryEloquent` → `DomainEntity` - `ProcessDomainCheckJob` → `DomainService` - `TransactionManagerEloquent` → `DB` (Laravel Facade) ### 実装関係 - `DomainRepositoryEloquent` implements `DomainRepository` - `TransactionManagerEloquent)` implements `TransactionManager` ### 組成関係 - `DomainService` creates `ProcessResult` - `HttpClientService` creates `HttpResponse` - `DomainRepositoryEloquent` converts between `Domain` ↔ `DomainEntity` --- ## 🏗️ アーキテクチャパターン ### レイヤーアーキテクチャ 1. **Presentation Layer**: Console Commands 2. **Application Layer**: Jobs (非同期処理) 3. **Domain Layer**: Services, Entities, Value Objects, Repository Interfaces 4. **Infrastructure Layer**: Models, Repository Implementations ### ドメイン駆動設計 (DDD) 要素 - **Entity**: `DomainEntity` - **Value Object**: `HttpResponse` - **Service**: `DomainService`, `HttpClientService` - **Repository Pattern**: `DomainRepository` interface + `DomainRepositoryEloquent` implementation - **Infrastructure Abstraction**: `TransactionManager` interface + `TransactionManagerEloquent` implementation ### 依存性注入 (DI) - Service Provider によるDI設定 - インターフェースによる抽象化 - テスタビリティの向上 ### トランザクション管理 - **責任分離**: Domain層がトランザクションインターフェースを定義 - **抽象化**: Domain層はLaravel固有の実装に依存しない - **実装**: Infrastructure層でLaravel DBファサードを使用 - **テスタビリティ**: モック可能なインターフェース設計 - **使用例**: ```php // DomainServiceでの使用例 public function processMultipleDomains(array $domains): ProcessResult { return $this->transaction_manager->transaction(function () use ($domains) { foreach ($domains as $domain) { $this->domain_repository->create($domain); } return new ProcessResult(true, count($domains), 0); }); } ``` --- ## 🔧 ServiceProvider設定 ### AppServiceProvider ```php public function register(): void { // TransactionManagerのバインディング $this->app->bind( \App\Domain\Monitoring\Repositories\TransactionManager::class, \App\Infrastructure\Monitoring\Repositories\TransactionManagerEloquent::class ); // DomainRepositoryのバインディング $this->app->bind( \App\Domain\Monitoring\Repositories\DomainRepository::class, \App\Infrastructure\Monitoring\Repositories\DomainRepositoryEloquent::class ); } ``` 戻る

この記事は GMOインターネットグループ Advent Calendar 2025 25日目の記事です。 はじめに こんにちは！GMOグローバルサインの漆嶌(うるしま)です。近年、量子コンピューターという爆発的な計算力を持つコンピューターが開発されており、計算に時間がかかることで守られたてきたこれまでの暗号が解読されてしまう可能性があります。量子コンピューターが実現したとしても解読されにくい暗号として耐量子計算機暗号(PQC、Post-quantum cryptography)が開発されました。いろんな国や業界から暗号をPQCに移行するためのガイドラインが出ており、エライ人から「君、我が社のPQC移行の計画を立てて推進してくれたまえよ。」なんて言われて困っている人がいたり、心配になってどうしようか悩んでいる人もいるかなと思います。安易に「2030年までにPQCに移行しろ」という人が多い中、「そう簡単じゃないんだよ。まだまだ課題がいっぱいあるんだよ。」ってことを紹介したいと思います。(あまりクリスマスにふさわしくありません。) RSA 2048ビットの公開鍵暗号はいつ破られそうか？ 現在多くの利用者証明書ではRSA 2048bitの公開鍵暗号が使われており、これがいつ破られそうかがみんなの関心事になっています。Craig Gidneyが2019年に「誤り率0.1%以下の2000万量子ビットを持つ量子コンピューターがあれば、RSA 2048bitを8時間程度で解読できる」と予測する論文を発表しました。そして2025年5月、Gidneyは新しい論文を発表し「RSA 2048bitはで誤り率が同程度の100万量子ビット未満の量子コンピューターで(多少時間を犠牲にして)1週間で解読可能」と予測しました。NTTとOptQCが共同で「2030年までに100万量子ビットの実現を目指す」としていると2030年ごろ破られてしまう可能性も出てきたということでしょうか？その他にも予測は様々で[「2039年よりも前にRSA 2048が解読される可能性は5%未満」とする研究発表や、「(2024年時点で)2039年までにRSA 2048が解読される可能性は39〜62%」という白書もあります。とある2025年10月のカンファレンスでは量子コンピューターの開発者の方が「(予測はいろいろですが)2045年にはRSA 2048が解けそうかなぁなんて思ってます。」と仰ってたりもしました。実際にいつ破られるかは別にして公開鍵暗号のPQC移行は2030〜2035年ごろには済ませておかないといけなそうです。 アプリケーション毎のPQC移行準備状況 PQC移行が必要そうなアプリケーションはTLS、SSH、X.509証明書などありますが、標準の策定状況、実装状況、市場普及状況などをPost Quantum Cryptography Coalitionがヒートマップの形で毎月公開してくれており、12月分を引用して貼っておきます。 やはり、鍵共有が署名よりも遅れているのがよくわかります。標準化までのステップがとても細かいですが、そこからが長いですよね。7の「Integrated in Libraries(ライブラリに標準が組み込まれた)」って言ってもそこからが普及まで遠いわけで、、、、 PQC対応暗号ライブラリ、ソフトウェアの状況 OpenSSL(3.5以降): Open Quantum Safeが3.5より標準サポートされた暗号ライブラリ。Apache HTTP Serverなどでも利用される。Bouncy Castle: Java用暗号とPKIのライブラリOpen Quantum Safe(liboqs): OpenSSL 3系向けのプロバイダとして提供されているPQCライブラリwolfSSL: 組み込み機器でよく使用されている暗号ライブラリ 最もメジャーな暗号ライブラリであるOpenSSLが3.5になってPQC対応されて良かったなぁと思います。ちょっと残念なのは2点 PQC Hybrid暗号に対応していない(pure PQCのみ)(smime, cmsは対応済な一方で)タイムスタンプ(ts)がPQCに対応していない OpenSSLのタイムスタンプはとても古いCMSベースじゃないPKCS#7ベースのコードでメンテされていんですよね。issueとしてはインプットしてみたんですが、なかなか対応されなそう。もう一点、PQC移行が心配なのが多くのブラウザに標準搭載されているW3C Web Cryptographyです。OpenID系の方々とか結構使ってらっしゃるのかなと思い、そのPQC対応が見えないのでちょっと心配しています。 世の中にあふれるPQC移行ガイドライン 2030〜2035年ぐらいには既存の公開鍵暗号からPQCに移行しとかないと、いよいよヤバそうだなということで、様々な国、業界、組織からPQC移行に関するガイドラインが公開されています。内容は似たり寄ったりな面も多くて全部に目を通す必要はないと思います。ざっくり以下のような移行ステップが書かれていることが多いです。 準備 - 資産棚卸し - 経営層、IT部門、セキュリティ部門を巻き込み責任者を任命 現状把握 - 各資産が使う暗号の棚卸し - 影響評価、リスク評価、優先順位決め 移行 - 暗号の選定、開発、実装 - パフォーマンステスト モニタリング - 問題ないか？ 私が是非おすすめしたいガイドラインは2つ 脆弱性情報提供で有名なMITREの組織。割と簡潔。- Post Quantum Cryptography Coalition: Post-Quantum Cryptograpy (PQC) Migration Roadmap (2025.05)大ボリュームだけどとてもおすすめ。ケース分け、移行フローも秀逸。背景情報も充実。- オランダ政府: The PQC Migration Handbook(2024.11) 特にPKI、署名関連のPQC移行計画の策定を阻む多くの壁 PQC鍵共有は良いがPQC署名への移行がヤバい PQC暗号移行には2つの種類。 ML-KEMなどの鍵共有アルゴリズム: 暗号通信の開始・更新のための鍵共有ML-DSA、SLH-DSAなどの署名アルゴリズム: 署名や認証のために用いられる 鍵共有については通信する双方の実装だけが対応していればよく、標準化も普及も順調でウェブブラウザやクラウドサービスでも既にPQC対応済です。VPN製品などのネットワーク機器なども順次対応製品が出てくるでしょうし、それを使えばいいだけなので話が簡単です。その一方で、PQC署名アルゴリズムやこれを使用するシステムの移行は関係が複雑で移行には相当時間がかかりそうです。多くのPQC移行ガイドラインで2030年とか2035年とかまでにはPQC移行すると言っていますが、相互に依存関係があり「ニワトリと卵」のような状態で一筋縄では行かなそうです。移行を妨げる多くの壁について紹介したいと思います。 認定を受けたHSM製品、スマートカード、USBトークンの不在 デジタル証明書を発行する認証局やデジタルタイムスタンプを発行するタイムスタンプ局などではハードウェアセキュリティモジュール(HSM)と言われるハードウェア製品で暗号鍵を管理しています。今年あたり、PQC署名アルゴリズムに対応したHSM製品が出始めましたが、TLSサーバー証明書などパブリックな証明書を発行する認証局は、FIPS 140 Level3やCommon Criteria(CC) EAL4+といったセキュリティ評価制度の認定を受けた製品を使用する必要があり、これらの認定品が出てくるのが来年ごろと言われているようです。結果的にPQC対応TLSサーバー証明書、コードサイン証明書などが出てくるのもそのずっと後ということになりそうです。スマートカード、USBトークン、TPMチップについても同様で、FIPSやCC認定品は出ていないので、認定品を使用することが要件となっている制度、ガイドラインは注意が必要です。 パブリックな認証局、証明書のガイドラインの対応 パブリックな認証局はCAブラウザフォーラム(CABF)のガイドラインに準拠していますが、PQC対応の認証局への対応にはまだまだ時間がかかりそうです。CABFでは証明書の用途種類毎に基本要求(baseline requirements)をまとめたガイドラインが発行されています。 TLSサーバー証明書の基本要求(2025年12月 2.2.1版): 対応予定未定コードサイン証明書の基本要求(2025年11月 3.10.0版): 対応検討中S/MIMEメール証明書の基本要求(2025年10月 1.0.12版): PQC(ML-DSA,ML-KEM)対応済 現時点ではS/MIME証明書が対応済、コードサイン証明書が対応検討に向けた議論中、最も利用されており影響の広いTLSサーバー証明書については議論の開始が遅れているようです。前述に加えてここでもTLSサーバー証明書の認証局のPQC移行は遅くなりそうです。 PQC証明書に対応するウェブブラウザの不在 Chrome、Edge、Safari、Firefoxなど主要なウェブブラウザは全てPQC証明書に対応しておらず、対応計画も明らかになっていないと認識しています。前述のパブリック認証局の対応が遅くなっていたとしても、OpenSSLが既にPQC対応していることによりHTTPサーバーもPQC対応しているので、プライベート証明書を使ってPQC証明書対応HTTPS通信が使えるようになっててもいいのではないかと思います。パブリック認証局の対応を待たずに早くウェブブラウザでもPQC証明書対応されると良いなと思います。 ルートプログラムのPQC対応 OSやブラウザにはルート(認証局)プログラムというものがあり、OSやブラウザでデフォルトで信頼されるルート認証局のリスト搭載、認定をする際の基準が定められています。プログラムによっては現時点ではPQCアルゴリズムのルート証明書に対応していないものもあり、これらのPQC移行も早めに進めていただく必要があるようです。改訂は文言だけの話なので、早めに認められるようになると良いと思うんですけどね。 Chrome Root Program: アルゴリズムには依存せずMicrosoft Root Program: RSA、ECDSAに制限Apple Root Program: S/MIMEのみRSA、ECDSAに制限Mozilla Root Program: RSA、ECDSA、EdDSAに制限 CRYPTREC電子政府推奨暗号に影響するシステム CRYPTRECでは、[日本の電子政府が調達のため参照すべき暗号リスト(CRYPTREC暗号リスト)](https://www.cryptrec.go.jp/list.html)を定めていて、民間でもこのリストがガイドライン等で参照され要件になっていることがあります。現時点では、ML-DSAやML-KEMといったPQC対応の暗号は掲載されていないので、リストに厳密に準拠するシステムはPQCが使えないということになってしまいます。CRYPTREC暗号リストは3つの種類のリストで構成されています。 電子政府推奨暗号リスト: 安全で市場利用実績があり利用を推奨する暗号推奨候補暗号リスト: 安全で将来電子政府推奨暗号リストに記載される可能性がある暗号運用監視暗号リスト: リスクが高まり推奨はできないが、互換性維持のために利用を容認する暗号 例えば、総務大臣の認定タイムスタンプでは実施要項に「電子政府推奨暗号リストに記載された公開鍵暗号技術を使うこと」となっています。CRYPTREC暗号リストでは、その暗号が日本で使って大丈夫かどうか安全性を評価し、最初に「推奨候補暗号リスト」に記載され問題がなければ次の改訂の際に「電子政府推奨暗号リスト」に記載されるという流れになっているそうです。評価に必要な時間、記載初版と改訂を考えるとPQCが記載されるまでに4〜5年かそれ以上かかりそうで一部のPQC移行期限の2030年を超えてしまいそうです。CRYPTREC暗号リストの影響を受ける制度は、それから数年を経て利用可能になるかもしれません。CRYPTREC暗号リストのPQC対応を待たずに、開発などできるところから先行して準備を進めておくなどの工夫が必要そうです。PQCの記載については、緊急措置、特別措置としてこれまでと違う記載に向けたプロセスが必要なのではないかと心配しています。 コード署名におけるLMS、XMSSの利用 ソフトウェアの改ざんから保護し製造者を証明するためにコード署名という方法が使われています。米国の政府システム調達に関する新しい基準CNSA 2.0では、様々な暗号利用用途の中でもソフトウェア、ファームウェアの移行は特に緊急性が高いとして以下と定めています。 2022年時点でも他よりも先に至急移行に着手しなければならない他よりも早く2030年までには移行が完了しなければならない使用するアルゴリズムはML-DSA署名アルゴリズムではなくハッシュベースのPQC署名アルゴリズムであるLMS、XMSSを使わなければならない 誤解していたらごめんなさいですが、このLMS、XMSSは少し厄介で、署名の度に秘密鍵がアップデートされます。認証局の秘密鍵はHSMを使うことになっていますが、何か問題が起きて秘密鍵をバックアップ、リストアする際に、巻き戻った秘密鍵を使用した場合、その間行った署名の扱いはどうなるか？という問題がありそうです。HSMベンダーはこのあたりを想定して、特許を取得した方式や様々な方法で対処するそうですが、これまでは秘密鍵は固定だったという常識から外れることになり、想定外の問題が起きないかと心配しています。 結局、2025年12月時点、どう対処するのがいいのか？(私見) 2025年12月の現時点から1年くらいは、PQCに対応するソフトウェアもハードウェアもOSも十分には揃っておらず、PQC移行計画の技術的な詳細真面目に検討してもしかたないと思います。経営層、IT部門、開発部門、セキュリティ部門を早めに巻き込んで、移行責任者を決め、ざっくりした計画と棚卸しを始めましょう。システムの棚卸しは早めにしておいた方がいいと思います。棚卸しもCBOMのように真面目にする必要はなく、おおまかな棚卸しをするだけで十分だと思います。情報収集は重要です。使用しているHSMベンダー、スマートカードベンダー、VPNなどのネットワーク機器ベンダー、OSベンダー、PKIベンダーから提供される情報はこれからも継続的に入手してください。2026年あたり、対応するハードウェア、OSの情報がアップデートされ真面目に検討できるようになりそうです。注視しといてください。詳しそうな人を誰か抱えて聞けるようにしておくのでも良いと思います。PQC対応のライブラリも出はじめてきたので、システムの試作、署名のパフォーマンステストなんかはしておくと良いです。 資産や暗号の棚卸し システム資産、暗号資産の棚卸しは、現時点ではざっくりで埋められるとこだけ埋めるで良いように思います。棚卸しで管理したほうがよさそうな項目は以下でどうでしょうか？ 名称: 資産、システムの名称- 担当者、主幹部門- 優先順位と対応PQC移行の緊急度  - 移行アクション: システム修正か再構築か機器リプレースか廃棄かなど システムと共通鍵暗号  - 機密性: 求められるデータの機密性  - 耐用年数: システムやデータを保護すべき年数  - 署名か鍵共有かそれ以外か  - 公開鍵アルゴリズム: システムが使用する公開鍵アルゴリズムと鍵長 依存関係  - 外部依存: 自社開発か外部ベンダー製品か  - 暗号モジュール: 使用している暗号モジュール、ライブラリ、ソフトウェア  - 依存する制度: 依存している制度、ガイドライン、標準(金融庁ガイド,大臣認定,CRYPTREC,CNSA2,CABF等) 最近、ソフトウェア部品表(SBOM: Software Bill of Material)を整備してライブラリなどの脆弱性の依存関係を調べやすくするといった活動の一環で、暗号部品表(CBOM: Cryptography Bill of Material)を整備しましょうという話も聞きます。しかしながら、依存しているライブラリや製品のベンダーが作ってくれないと作るのも管理するのも大変ですよね。現時点ではCBOMを使ってPQC移行の調査をしよう、進めようとするのは「労多くして益少なし」な気がしてやめておいた方がいいように思います。 テスト用PQC証明書 宣伝っぽくてすみません。他社も始めているようですが、弊社GMOグローバルサインからもテスト用PQC証明書をご提供させていただいております。 TLSサーバー証明書クライアント証明書ドキュメント署名用証明書S/MIME用証明書 など、様々な用途のテスト用証明書を発行することができ、失効情報も定期更新しており、証明書拡張の値などの記載内容も比較的柔軟にお受けできると思いますので、よかったら社内検証、開発の用途でご利用ください。 PQC移行で勇気づけられた講演の話 最後に一つ紹介させてください。2025年10月にマレーシアのクアラルンプールでPKI Consortiumという団体によるPQC Conference 2025というカンファレンスが現地とオンラインで開催されました。その中で、オランダ政府システムのPQC移行の責任者であるPieter Schneider氏の講演がとても勇気づけられました。講演の感動ポイントをいくつか紹介します。 PQC移行は短距離走じゃない、マラソンだ。PQC移行は単なるITプロジェクトではなく技術的と非技術的な多くの要素が複数のレイヤーで構成されていて、とてもじゃないが単一の組織では対処することができない。君は一人ではない。一人であるべきじゃない。みんなでやっていこう。 どこか1社でもPQC移行マラソンを完走してインタビューを放送してくれたりすると、救われた後続がどんどん出てきてみんな幸せになれるんじゃないかと思いました。 おわりに 以上、現時点では多くのシステムがPQC移行の具体的な計画を立てるには課題が多くて早すぎるということ、最低限、リーダーシップを決めて、システムの棚卸しをし、動向のウォッチをしておけば十分んなんじゃないか？システムの実装はこれからになりそうということをご紹介しました。なんか、PQC移行を心配する個人的な想いがあふれて、長文になってしまいごめんなさい。PQC移行に関係しそうな、あるいはしてしまった多くの方々が来年も幸せでありますように。メリークリスマス。 

GMOインターネットグループは、12月4日に国際サイバーセキュリティ会議「INCYBER Forum Japan」に出展しました。国内外のサイバーセキュリティ専門家が集結し、日本経済新聞様やPWC様など、計16社がブースを展開した本イベント。本会議において、GMOインターネットグループはブース展示と講演を行いました。およそ800人が訪れた会場の様子やGMOインターネットグループのブース展示を中心に、大盛況で幕を閉じた当日の様子をレポートします！ 真剣さと熱気に包まれた会場 午前10時からスタートしたINCYBER FORUM JAPAN 2025。この日は2つの演壇ブースで合計24講演が行われ、全席が埋まった講演では「立ち見」が出ることもありました。それでも講演に入りきらなかった参加者のために、ブースの外にはモニターとスピーカーが設置されており、映し出されたスライドを見ながら静かに説明を聞く方も多くいらっしゃいました。また国外からのスピーカーや参加者のために、英語・日本語による同時通訳が行われており、翻訳機を耳に当てながら話を聞く方の姿も印象的でした。 日本のデジタル主権を守り抜く「5つの盾」 GMOインターネットグループでは、「日本の”デジタル主権”を守り抜く。」という言葉のもと、世界トップクラスのサイバー防衛を提供しています。当日のブースでは、私たちが提供するサイバーセキュリティサービスについてのプレゼンも行われました。社会基盤のデジタル化やAIの台頭により、サイバー攻撃の激しさや手法は大きく進化しています。クレジットカードの機能不全といった社会インフラの麻痺、ランサムウェアによる情報流出・システムの不通など、我々の生活に影響を与える大規模な攻撃が行われることも珍しくありません。こうした状況の中、GMOインターネットグループでは、「予防」「検知」「組織」「信頼・認証」「未来」の5領域をフックに我々のもつセキュリティサービスをご紹介しました。 予防 セキュリティホールを未然に防ぐ「予防」においては、当社のホワイトハッカーが疑似的な攻撃を行うことで重要システムを診断する「ホワイトハッカー手動診断」や、セキュリティ診断AIエージェント「Takumi」、ツールによるセキュリティ診断「GMOサイバー攻撃ネットde診断 ASM」をご紹介しました。とくにホワイトハッカー手動診断では、世界最高峰のセキュリティコンテストであるDEFCONで優勝したチームを擁しており、サイバーセキュリティのプロフェッショナル集団として脆弱性発見・解消に取り組んでいます。 会場では、これまでに累計2,500社・12,600件以上の導入実績を誇るホワイトハッカー手動診断に興味を持つ来場者の方が、プレゼン後にパートナー（社員）へ質問する姿もみられました。 検知 「検知」では、GMOインターネットグループのSOC（Security Operation Center）についての紹介がありました。SOCは24時間365日稼働する「防衛拠点」であり、有事の際に被害を最小限にする役割を担っています。 組織 セキュリティ訓練やコンサルティングを提供する「組織」領域では、実践的なスキルをお教えすることで「受ける前と後で行動が変わる」講義を提供しています。さらに官民一体となってサイバー攻撃に対処するという取り組みの一例として、GMOインターネットグループが陸上自衛隊のサイバー学校で講義をさせていただいた事例も紹介されました。この日の講演では「官民一体となってサイバー攻撃の脅威に立ち向かうべき」という主張をされたスピーカーの方もいらっしゃったため、そうした講演を聞いた参加者の方からも熱い視線が注がれていたのが印象的でした！ 信頼・認証 「信頼・認証」の領域では、なりすましメールやフィッシング対策の取り組みとしてBIMIやVMCを提供する「VMC byGMO」と自治体・官公庁向けの「GMC byGMO」を紹介。20年以上の商標・ブランド管理の知見と、世界でわずか４つしかない認証局をもつ強みを活かし、安心・安定した運用をご提供しています。 未来 最後の「未来」領域では、GMOインターネットグループの展開する宇宙セキュリティについての説明がされました。この領域では衛星や地上局システムの網羅的な脆弱性診断、国際的企画の準拠支援など、産学官連携で対策を提供しています。 陸・海・空に次ぐ「第4の戦場」とも言われる宇宙空間の安全も、われわれGMOインターネットグループが支援してまいります！ サイバー空間&物理空間のセキュリティもGMO GMOインターネットグループのブースでは、セキュリティ領域の展示・プレゼンに加え、ロボティクス技術の展示も行われました。来たるロボット社会に向け、GMOインターネットグループでは2024年6月にロボット産業の金融×商社事業を行う「GMO AI&ロボティクス商事株式会社」を立ち上げています。同社では最先端のヒューマノイドを派遣し、展示会やイベントにおける人手不足解消などに貢献することを事業ビジョンに掲げています。この日のブースでは、パートナー（社員）が操作するヒューマノイドがお目見え。来場者に向けた操作デモも行われました。 ドローンやラジコンのようにリモコン式で動かすことができ、まるでゲーム感覚で操作できる手軽さが印象的です。まだまだこうしたロボットを街中で見かける機会も少ないため、中にはヒューマノイドの動く様子にびっくりされる方も。動かしているパートナー（社員）に質問したり、談笑したりといった場面も見られました。 この日とくに注目を集めていたのは、弊社内来客フロアで稼働をしてくれているデリバリーロボットです。事前にルートが設定されているため、注文を受けたロボットが品物を受け取ってお部屋まで届けてくれる仕組みになっています。この日もコーヒーやお茶菓子などを来場者にふるまい、かわいらしいデザインに思わず笑顔になる参加者の姿も見られました。こうしたロボティクスの普及において、セキュリティは欠かせない要素となります。ヒューマノイドのようなフィジカルAIが人々の生活を支える社会が到来したとき、悪意ある攻撃者によるハッキングを防ぐことも、GMOインターネットグループの重要な役割です。私たちはサイバー空間の安全だけではなくロボット産業の発展にも寄与し、人手不足や危険な作業における安全リスクといった社会課題の解決に注力してまいります。 GMOインターネットグループからの登壇 INCYBER Forumでは、GMOインターネットグループからGMOサイバーセキュリティ byイエラエで執行役員を務める奥野史一、GMOインターネットグループ株式会社 グループサイバー防衛事業推進本部「6」本部長の廣惠次郎が登壇しました。奥野はマルチドメイン戦におけるサイバーとAIの役割について、今後はAIエージェントとハイパーオートメーションが防衛のカギを握ると強調。将来の展望として、自身が提唱する未来のサイバーセキュリティのロードマップ「Three-Zero」の解説も行いました。前陸上自衛隊教育訓練研究本部長・元陸将の経歴を持つ廣惠は、ウクライナ・ロシア戦争におけるサイバー戦争の実態とそこから学ぶべき教訓・対策について講演。すでに局所的な戦闘が発生し、全面開戦直前のウクライナを訪問して得られた知見を惜しみなく伝えます。いずれに講演にも多くの参加者が詰めかけ、最新の知見や考えをお持ち帰りいただきました。さらに廣惠は、カナダ軍サイバー軍司令官のデイブ・ヤーカー少将や電通総研経済安全保障研究センター研究主幹の大澤淳氏、日本経済新聞社政治部・外務省キャップの甲原潤之介氏によるパネルディスカッションにも登壇。ディスカッションではハイブリッド戦の特徴や国際連携の枠組みについて所見を述べ、日本の現状に対する課題提起も行いました。各講演後は、GMOインターネットグループのブースで奥野・廣惠が参加者からの質問に答える場面も。質問する側・回答する側、どちらも真剣で熱い時間を過ごしていました！各講演のレポートはこちらにまとめてあります。サイバー攻撃への意識を高められる内容となっていますので、ぜひご覧ください！ すべての人に「安心な未来」を届けるために 国際情勢が日々変化する中、サイバー攻撃の手法は多様化し、その苛烈さもAIの台頭によって一層増しています。今回のINCYBER Forumでも、そうした脅威の実態と対策について、第一線で活躍する専門家たちから貴重な知見が共有されました。「ネットのセキュリティもGMO」というスローガンを掲げるGMOインターネットグループでは、サイバーセキュリティからロボティクスまで、幅広い領域で技術とサービスを提供しています。 変化し続ける脅威に対し、私たちも進化を止めることはありません。これからも最先端の技術と知見を結集し、社会の安全と企業の発展に貢献してまいります。