新着 の記事一覧

こんにちは、GMOインターネットでサーバインフラを担当している小島です。今回は弊社で採用しているNFSを用いたクラスタシステムで、NFSのI/Oが極端に遅くなるトラブルに対処したときの話をしたいと思います。 はじめに みなさん、NFS使ってますか？NFSって便利ですよね。どんな時に便利かというと、複数のサーバで一つのファイルシステムを共有する時です。ではなぜこんなことをするのでしょうか。それはサーバの一つが落ちた時でもシステム全体ではサービスを維持する、つまり耐障害性向上のためです。 昨今ではVMのリブートなら20-30秒で上がってきますし、最悪VMが起動しなくてもボリュームを別のVMにアタッチして起動することも簡単にできます。そのため以前に比べると、シングル構成でも耐障害性が上がってきてはいるのは確かです。 一方でクラウドの利用が進み、スケールアップではなくスケールアウトの考え方が浸透し、システム間で共有する一意なデータの置き場所に悩む場面も増えてきたのではないかと思います。 データ共有アーキテクチャの比較 さて、耐障害性向上のため一つのデータ領域を複数のサーバで共有する仕組みには、いくつか種類があります。まずはこれらをおさらいしておきましょう。 一つのディスク装置(ストレージ)を複数のサーバ機器にSCSI等で接続したシステムです。それぞれのサーバからはストレージをローカルディスクのように扱うことができます。昔から基幹データベースなどに用いられていた構成で、性能も高いですが価格も高くなります。 二台のサーバ上のディスクをレプリケーションさせ、仮想的な共有ディスクをソフトウェアで実現する仕組みです。DRBDのソフトウェアそのものは無償で利用できますが、安定した運用を行うには技術が必要だと思います。また、基本的には二台限定の構成になります。 NFSサーバとクライアントによって、ネットワーク越しのファイルシステムをローカルファイルシステムにマウントし、読み書きできるようにするものです。一つのファイルシステムを複数のクライアントから同時にマウントする、それも2台限定ではなく3台4台・・・と多くのクライアントで共有することも問題なく行えます。 オブジェクトストレージそのものはREST APIを通じてファイルの読み書きをすることが一般的ですが、そのAPI層をラップしてローカルファイルシステムにマウントする(したように見せる)仕組みがあります。s3fs等ストレージ側との通信はあくまでAPIによって行われるため、複数のクライアントで一つのファイルシステムを同時にマウントすることもできますが、I/O性能は著しく低いため汎用ファイルシステムとして利用するのは厳しいでしょう。読み書きは遅くてもいいから安く大容量のストレージを使いたいといった限定的な用途では役に立つ場面もあると思います。 過去のNFSトラブルとその対処 さてそんな理由で、20年以上前からレンタルサーバーシステムでもNFS上にDocumentRootを置いたwebシステムやNFS上にメールボックスを配置したメールシステムを稼働させてきました。 ケース１　diskのI/O性能不足まだSSDが普及する前のこと、73GBのSCSI HDDを束ねたストレージでは容量的に限界を迎えており、500GB SATA HDDを数十本搭載したストレージに移行しました。しかしほどなくしてNFSサーバの応答遅延に悩まされることになります。応答遅延に悩まされたのはメールボックスを置いたNFSサーバの方で、特に多くの人が週末に溜まったメールのチェックを始める月曜の朝が顕著でした。NFSサーバの状況を見ると数十本のHDDのそれぞれのI/O waitが100%に張り付き、キャッシュヒット率も低迷している状態です。我々のメールサービスではメール1通が1ファイルとなるMaildir形式を採用しており、何千何万というファイルに対する読み込み要求が殺到します。HDDは磁気ヘッドがプラッタ上のデータがある場所を探しに行くという構造上、このようなランダムアクセスにはどうしても弱くなります。この時はメモリを追加して読み込みキャッシュを拡張し、キャッシュヒット率を改善させてHDDへのアクセスが極力発生しないようにしました。 ケース２　ネットワーク輻輳上記のケース改善後しばらくの間、順調にサービスも拡大しNFSサーバとweb/メールサーバの台数も増え続けていました。当時のシステムではサーバ用ラックとNFS用(ストレージ用)ラックを分け、それぞれに増設を行っている状態でした。そんなある日、急にNFSの応答性能が遅延する事態になりました。この時はNFSサーバ側も負荷は上がっておらず余裕がある状態で、NFSサーバ側から見ると受け取った要求には迅速に応答している状態。しかしマウントしているサーバ側から見ると応答が遅延している状態でした。この時はサーバ用ラックとストレージラックを結ぶネットワークの帯域が限界に達していたのが原因でした。これ以降、NFSサーバとそれをマウントするサーバは基本的に同一ラック同一スイッチに接続する方針に改めました。 直近の問題と対応 このように紆余曲折ありながらも長年運用してきたシステムを、この度リプレースすることになりました。これまでの経験を活かし、NFSサーバのdiskは全てSSDかつ十分なキャッシュ用メモリを搭載、NFSサーバとそれをマウントするサーバは同じスイッチに接続しNWの遅延は起こらない、なおかつサーバスペックも上がりOSやその他ソフトウェアのバージョンも上がり、NFSも最新のv4.2になる。このように割と自信を持って構築し、事前の性能検証も問題なくいざ本番となったのですが、稼働後1～数時間で極端にI/O性能が劣化するというトラブルに見舞われました。再マウントやリブートで一旦は復旧するものの、しばらく時間を置くと不定期に発生し、一度発生してしまうと再マウントやリブートするまで直らないという状態です。 その時のNFSサーバとの間の通信をモニタすると、以下のような状態でした。延々とTEST_STATEIDのリクエストを投げています。 25 0.441018 172.16.XXX.YYY → 172.16.XXX.ZZZ NFS 218 V4 Call TEST_STATEID 26 0.441090 172.16.XXX.ZZZ → 172.16.XXX.YYY NFS 166 V4 Reply (Call In 25) TEST_STATEID 27 0.481149 172.16.XXX.YYY → 172.16.XXX.ZZZ NFS 218 V4 Call TEST_STATEID 28 0.481220 172.16.XXX.ZZZ → 172.16.XXX.YYY NFS 166 V4 Reply (Call In 27) TEST_STATEID 29 0.520711 172.16.XXX.YYY → 172.16.XXX.ZZZ NFS 218 V4 Call TEST_STATEID 30 0.520914 172.16.XXX.ZZZ → 172.16.XXX.YYY NFS 166 V4 Reply (Call In 29) TEST_STATEID 通常NFS上のファイルを読み込むときは以下のようになるはずです。GETATTR,OPEN,READ,CLOSEという基本的な流れですね。 57 72.276233415 172.16.XXX.YYY → 172.16.XXX.ZZZ NFS 250 V4 Call GETATTR FH: 0xe91f0f38 58 72.276513199 172.16.XXX.ZZZ → 172.16.XXX.YYY NFS 310 V4 Reply (Call In 57) GETATTR 59 72.276531322 172.16.XXX.YYY → 172.16.XXX.ZZZ TCP 66 809 → 2049 [ACK] Seq=1229 Ack=1961 Win=7613 Len=0 TSval=364771848 TSecr=1008280430 60 72.276621742 172.16.XXX.YYY → 172.16.XXX.ZZZ NFS 330 V4 Call OPEN DH: 0x22d71008/ 61 72.276730044 172.16.XXX.ZZZ → 172.16.XXX.YYY NFS 422 V4 Reply (Call In 60) OPEN StateID: 0xe470 62 72.276817378 172.16.XXX.YYY → 172.16.XXX.ZZZ NFS 278 V4 Call READ StateID: 0x5324 Offset: 0 Len: 4096 63 72.276973612 172.16.XXX.ZZZ → 172.16.XXX.YYY NFS 186 V4 Reply (Call In 62) READ 64 72.277031738 172.16.XXX.YYY → 172.16.XXX.ZZZ NFS 270 V4 Call CLOSE StateID: 0xe470 65 72.277095753 172.16.XXX.ZZZ → 172.16.XXX.YYY NFS 182 V4 Reply (Call In 64) CLOSE さて、なぜこのような状態になったのか。結論から言うとNFSv4.2ではデフォルトで有効になっているdelegation機能が原因と考えられます。delegation機能が有効になっているとNFSクライアントは対象ファイルに対して一定時間NFSサーバと通信することなくファイルに対する操作を行えます。そして同じファイルをマウントしている他のクライアントが対象ファイルへの要求をNFSサーバに送信すると、 NFSサーバはdelegationを許可していたクライアントに権限移譲の返却を求めます。またクライアントは手元の情報とサーバ側の情報の間に不整合が出ないよう、NFS通信に問題があったときはtest_stateidを送って確認を行います。しかしこのtest_stateidばかりを延々送り続けるのは、クライアントから見てサーバ側でのファイル変更(他のNFSクライアントからの変更)によって手元の情報との乖離が発生し、同期をうまく取り直せない、取り直すのに時間がかかる状態だったと思われます。 対応としてはdelegationの無効化を行いました。まずオンラインで変更するには以下のようにします。 echo 0 > /proc/sys/fs/leases-enable またNFSサーバの再起動時にも反映されるよう、/etc/sysctl.confに以下の記述を追加しました。 fs.leases-enable=0 まとめ この設定が効いたのか、それ以降は大きな問題は発生していません。delegationは同時にアクセスするNFSクライアントが一つだけの構成ならば性能面で大きな助けになるでしょう。しかし複数のNFSクライアントから一つのファイルシステムを読み書きする構成、それも細かな大量のファイルに読み書きが発生する用途には不向きと言えます。 このdelegation機能、NFSv4.0の頃はNFSサーバからNFSクライアントに向けて、2049とは別のポートで接続を行っていました。NFSクライアント側では明示的に許可したポートの接続しか受け付けていないので、リプレース前のシステムでは意識せずdelegationが機能しなくなっていたためこの問題が発生しなかったと思われます。 NFSv4.0からv4.2差分としては機能が増えたわけでもなく、デフォルトで有効・無効が変更されたわけでもなく、元々別ポートで動いていた機能のポートの統合というあまり意識しない変更によって思わぬ影響が出た事例となりました。

こんにちは。GMOインターネット株式会社でWindows系インフラを担当している中島です。弊社では、社内のスタッフツール等の外部公開されていないWEBアプリケーションへ、Microsoft Entra アプリケーション プロキシ（英語: Microsoft Entra Application Proxy、旧 Azure Web Application Proxy）を利用して多要素認証を実装してセキュリティ強化をしています。今回はその中でも、一部のWEBアプリケーションに実装されていたWindows統合認証が、社内のNTLM認証廃止に伴って出た影響と、その対策を紹介します。 1. はじめに Microsoft は Windows 11 version 24H2 および Windows Server 2025 で NTLMv1 を削除し、NTLM 全バージョンの開発を終了して非推奨化を進めています。Microsoftのこちらの記事を見る限りは、2026年10月にはWindowsの更新プログラムによってNTLM認証のブロックが強制されるとあります。 弊社でもNTLMの段階的廃止を進めており、Microsoft Entra アプリケーション プロキシを導入している環境で影響がでました。 具体的には、Microsoft Entra アプリケーション プロキシサービスとイントラネットとの橋渡し役であるConnector サーバーをWORKGROUP 運用していたため、NTLM 廃止後に認証が通らなくなる事象が発生しましたが、その解決方法を以下にまとめます。 2. 環境の前提 フロントエンド：Microsoft Entra アプリケーション プロキシサービスバックエンド①：アプリケーションプロキシConnector サーバー(WORKGROUP 運用)バックエンド②：Webサーバー(IIS 上の Windows 統合認証を利用したWEBアプリケーション) 今回の事象が発生した環境は上述の様な構成です。 3.発生した事象 Entra アプリケーションサービスを導入している一部のWEBアプリケーションで実装されていたWindows統合認証で、認証情報を聞かれるようになり、正しい認証情報を入力しても弾かれてログインが出来ないとの問い合わせを受けました。 4. 原因 今回の事象が発生した原因は、Kerberos認証の前提条件を一部満たしていない事に起因して認証がNTLMに認証がフォールバックされ、さらに無効化された影響で今まで利用できていたものが弾かれる結果となりました。直接的な原因になった項目を記載します。 認証対象のADドメインにConnectorサーバーが未参加対象のFQDNがコンピューターオブジェクトの「SPNに未登録」 5. 実施した対策 結論から言うと、この件についてはEntra エンタープライズアプリケーションのSSOで利用可能な「Kerberos の制約付き委任」で解決可能です。以下にその手順を記載します。 5.1 AD ドメインに参加させたConnectorサーバーを用意 新規に Connector サーバーを構築し、Windows 統合認証のユーザーが所属する AD ドメインに参加させます。これにより、Connectorサーバー → バックエンドWEBサーバー 間で Kerberos認証を利用可能にする為の足がかりとなります。 5.2 WEBアプリケーションのFQDNをSPNへ登録する WEBサーバーはIISで構成されており、認証対象のADドメインに所属していますが、IISにホストされているサイトのFQDNはADドメイン参加しただけではサーバーオブジェクト内のSPNへの登録はされないため、追加で登録を行います。※作業はADDCで実行します。 SPN追加setspn -S HTTP/<サイトFQDN> <対象コンピューターオブジェクトホスト名> SPN登録状況確認setspn -L <対象コンピューターオブジェクトホスト名> 実際のキャプチャ 5.3 Microsoft Entra 管理センター上での設定変更 5.3-1 AD参加済みConnectorサーバー用コネクタグループ作成 5.1で作成したAD参加済みのConnectorサーバーを所属させるためのEntra上に専用のコネクタグループを作成します。 Microsoft Entra 管理センター > 管理 > アプリケーションプロキシを選択し、 新しいコネクタグループをクリックします。 名前と作成したAD参加済みのコネクタサーバーを選択、詳細設定は適宜設定し「＋作成」をクリックします。 5.3-2 エンタープライズアプリケーションへ作成したコネクタグループの割当 作成したコネクタグループを対象となるエンタープライズアプリケーションに割り当てます。 Microsoft Entra 管理センター > エンタープライズアプリケーション > <対象のWEBアプリケーション >管理 > アプリケーションプロキシ > コネクタグループ 5.3-3 エンタープライズアプリケーションのIWAを構成する Microsoft Entra 管理センター > エンタープライズアプリケーション > <対象のWEBアプリケーション >管理 > シングルサインオン 手順5.2で登録したSPNを「内部アプリケーションSPN」へ登録し、「委任されたログインID」は環境に合った適切なものを選択します。設定内容に問題がない場合はこのまま「保存」ボタンで保存します。 以上で設定は完了です。 実際のアクセス画面はお見せすることが出来ませんが、この設定を行うことでMicrosoft Entra アプリケーション プロキシを導入している環境下でWindows統合認証を実装しているWEBアプリケーションへの認証が通るようになります。 6.最後に NTLMは、依然として多くのオンプレミスAD環境で利用されていると考えられます。同時に、今回ご紹介したようなEntra IDとオンプレミスを組み合わせたハイブリッド環境を活用している企業も少なくないでしょう。 今後、NTLM廃止の流れはさらに加速し、Windows環境を管理するシステム管理者にとっては避けて通れない課題となりますので、今回ご紹介した事例と解決策が、同じ課題に直面している方々の一助となれば幸いです。

GMOインターネットグループでは、技術力の向上を目的に、毎年テクノロジーインターンシップを実施しています。 2025年度は、8月25日（月）から9月5日（金）までの期間で開催され、「データサイエンスコース」と「ML/Webコース」の2コースを開講いたしました。 本記事では、「ML/Webコース」に参加された学生にご執筆いただいた体験記をご紹介いたします。インターンシップを通じて得た学びや気づきをぜひご覧ください。 はじめに 非情な暑さにうだるような夏休み、8/25(月)~9/5(金)にかけて開催されたGMOインターネットグループの10daysテクノロジーインターンシップに参加してきました。この体験記では、今回のインターンの内容、参加しているインターン生はどのような人がいたのか、GMOがどんな会社だったか、などなどについて自分なりの総括をしたいと思います。 自己紹介 いろいろとまとめる前に前提となる自己紹介を少しだけ。私は東大のM1で、現在は工学系研究科のバイオエンジニアリング専攻で研究をしています。化学屋さんなので研究ではExcelのマクロをいじるぐらいが関の山で、研究外でもいわゆるAIなどはChatGPTやClaude CodeなどのLLMをサービスとして利用する程度にすぎません。 学部2年生の時に学園祭のIT部門の統括をしたり、全学的な新歓運営委員会のIT部門を一人で回したりしていました。現在はITスタートアップのエンジニアとして活動しています。 インターンは今回が初めてで他に応募しているインターンもないので最初で最後になると思います。 インターンシップに参加するまでの経緯 大学内でTEDxというイベントが開催された際に、GMOインターネットグループが出展していた「ホワイトハッカーへの第一歩！」というなんともウキウキするような企画に参加したことがきっかけでした。その時の内容は、ログインシステムのデモに対して不正にアクセスしてみようみたいなものだった気がします。まさに「ネットのセキュリティもGMO」のスローガンど真ん中の内容でした。その企画の最後に 新卒年収710万プログラム の紹介があり、すでに社会人だった連れから激アツやんと言われて、その場のノリで応募することを決めました。自己紹介でも書いた通り、面接の経験がほとんどなかったので、オンライン面接ではちぐはぐでズタボロな受け答えしかできなかったのをよく覚えています。落ちたなと思っていたらご縁を頂き、参加することになりました。 参加しているインターン生はどのような人がいたか 今回のインターンでは東京会場と大阪会場が設けられており、どちらの会場の学生もその多くが情報科学やデータサイエンスなどを研究の対象にしたり用いたりしており、深い知見を有しているように見受けられました。ほかにも、イラストを公開するためのプラットフォームを個人で開発して運用している人や、起業してITの受託をやっていた人、Kaggleのコンペに参加していた人など、実際に開発をしたり実践的に技術を磨いたりしている人が散見されました。一方で、研究で機械学習を扱ってはいるが、実際にチームで開発したり、誰かに使ってもらうことを前提として開発を行ったりということはしたことがない人も見られました。その点で、私の学園祭でのチームでの開発経験は、インターンの課題を進める中でかなり有効活用できたように思います。 今回のインターンの内容 今回のインターンでは、テクノロジーインターンシップという名の下で、【データサイエンス(DS)コース】と【機械学習/Webエンジニアリング(ML/Web)コース】の二つのコースが設けられていました。 DSコース このコースは GMOペパボ が運営している SUZURI のデータを利用したEC推薦システムの開発か、GMOペイメントゲートウェイ のオンライン決済データを利用した不正検知システムの開発が題材で、「データを分析して新しくロジックを作る」ということがテーマでした。私はこのコースではなかったので細かい部分の正確なことは把握していませんが、参加者それぞれが実装する機能を考えて、ロジックを実装していました。複数人のメンターが常駐しており、適宜質問や相談などを行っていたそうです。雰囲気としてはゴリゴリのハッカソンのような印象を受けました。 ML/Webコース このコースでは 天秤.AI のような複数のLLMモデルを比較できるようなサービスの開発か、コエテコStudyのような問題を生成できるLLMの利用方法の提案が題材で、「AIのさらなる可能性を検討する」ということがテーマでした。参加者が3~5人のグループとなって新しいサービスや機能を考え、一つのものを実装する形式で、それぞれのグループに1人メンターがつき、方向性や進捗の確認、相談などを行っていました。雰囲気としてはハッカソンとアイデアソンを混ぜたような印象を受けました。私はこのコースのコエテコStudyの方に取り組んだので、それについてより詳しく書きたいと思います。 コエテコStudyコース コエテコStudy は GMOメディア が提供している高校教員向けの課題作成サービスです。特許を取得した問題を生成するためのLLMによって、「情報Ⅰ」などのノウハウが蓄積されていない分野の教師の負担を軽くするというソリューションを提供しています。今回のインターンでは、OpenAIのGPT-4o miniを使ったモックアップがNext.jsを用いて用意されており、それをもとにサービスの概観を掴みながら新しい機能、サービスを考えて開発を行いました。他のコースと比べて、テーマの自由度が非常に高く、「問題生成AIを使った何か」ということ以外は制限がありませんでした。そのため、発想力と技術力のバランスが求められるやりごたえのあるコースでした。 実際、3チームあった中で、 チームAは画像認識を使った記述問題の自動採点機能や音声生成を使ったリスニング問題の作成、生徒データの一覧性と検証性の改善というテーマで開発を行い、 チームBはVoltAgentを用いてAIエージェントを構築し、UIをAIで生成したユーザー自身で状況を決められる恋愛シミュレーションゲームというテーマで開発を行っていました。 一方で私のいたチームCでは問題を生成するという機能を応用して、生徒の解答状況に応じて出題する問題の難易度を変えながら時間の限り無限に問題を出し続けることで生徒の技能を「速度」と「難易度」という二次元で評価するSPIのような試験の開発をテーマにしており、まったく違った内容が広がっていました。 これが私のいたチームCが実際に制作したサービスのデモです。 試験作成画面 解答画面 スコア画面 問題を生成して出題するまでのデータフローに関しては複数ユーザーでの運用を想定して下の図のようにしました。 スコアリングについては以下のような簡易的なロジックを採用しました。 私は、試験設定ページと問題解答ページのフロントエンド、問題解答後のデータ管理について担当していました。エディターとしてCursorが与えられ、天秤.AIのアカウントも渡されていたので、爆速で仕上げることができました。フロントエンドに関しては、Cursor君にほぼ丸投げしました。一方で、解答データの管理についてはかなり苦戦しました。学園祭での開発ではVue.jsだったのでReact.js特有のHooksのベストプラクティスを知らず、useState周りのバッチ処理を解決するためにほぼすべてのデータ操作でuseEffectを使うというごり押しをしてしまいました。時間が許せばデータベース設計や複数人での解答などの実装までやりたかったです。またスコアリングに関しては、得られる解答データを生徒の様々な技能の合成としてとらえた場合に、「速度」や「難易度」だけでなく「正答率」などの基本的な視点や「問題を切り捨てる能力」などの試験を解くための戦略というこれまでは評価しづらかった視点などにも分解できると考えられるため、そういったことにも挑戦してみたかったです。 インターンの流れ チームCの一日の流れ 毎日10時から19時までが勤務時間で、どうしても参加できない場合は申請すれば昼からの出社などが許されていましたが、ほぼ全員がフルで参加していました。基本的なブレストやディスカッション、開発の時間以外には以下のような時間が設けられていました。 10:00~10:15 | 朝会 12:00~13:00 | 昼食 15:00~15:30 | カフェタイム 17:40~18:00 | 夕会 朝会ではチームについているメンターと雑談したり、一日の流れや確認事項の共有、アドバイスや質疑などをしたりする時間でした。一日の出だしからある程度動きを想像できるので動きやすかったです。 昼食では、およそインターン生4人に対して1人のパートナー(GMOでは社員のことをパートナーと呼んでいるようです)が同卓となり、ゆっくり交流できる時間が設けられていました。ワイワイ喋りながら、社内の話を聞いたり進捗を共有したりできたので、とても楽しかったです。日替わりのビュッフェが豪華なのが幸せでした笑 カフェタイムでは、日替わりでグループ会社のCTOとZoomでコミュニケーションをとれる時間がありました。それぞれの会社の雰囲気や展望、CTOの人柄などを感じることができました。本当にいろんな人がいて、同じGMOでも会社によって雰囲気が違うのが面白かったです。 夕会ではチームでコースのメンター陣にその日の成果や今後の方針を報告する時間でした。夕会のために資料を用意する過程で進捗が整理できたり、丁寧にフィードバックがもらえたりしたのでインターン中の短期進捗目標を立てるのに有効でした。怖くないけど、なぜか緊張してました笑 10日間の流れ 10日というのは一般的なインターンと比較するとかなり長いですが、徹夜を強いられるようなハードなことがなく、内容を考えると必要十分な日程であったように思います。以下は、インターン中の日程感です。私のチームは進捗がよかったので、一日早く発表することになりました。 一週間目 1日目 | オンボーディング・環境構築・アイスブレイク 2日目 | ブレスト・モックアップのキャッチアップ 3日目 | アイデア決定・ユーザーストーリー練り上げ 4日目 | ユーザーストーリー確定・実装仕様書の策定 5日目 | 実装・合同説明会・懇親会 二週間目 6日目 | 実装 7日目 | 実装 8日目 | スライド作成 9日目 | スライド作成と発表 10日目 | 他チームの発表・懇親会 最初の3日間はみっちり実装するものの擦り合わせに時間を使っていました。そこから、ユーザーストーリーをもとにCursorを使って実装仕様書を書いて、再度擦り合わせをしてから3日間ほど実装にあてました。土日にある程度実装を進めたいなと思っていましたが、平日が全部つぶれるのでいろいろと後回しにしたことがやってきて、なかなか動けなかったのが悔しかったです。  GMOの雰囲気 素晴らしい会社でした。以下にざっくり良かった点をまとめたいと思います。 オフィス 渋谷駅から徒歩5分以内にある破格の立地にある総合型商業施設2つがGMOのオフィスです。渋谷スクランブル交差点を定点カメラよりも高い位置から見下ろせる高さにあります。席はほぼすべてフリーアドレスで大画面のモニターが設けられており、机の広さもかなりゆとりがあり、のびのびと開発できました。食堂兼カフェとしてはGMO Yoursがあり、毎日日替わりで豪華なビュッフェが楽しめたり、30種類程度の飲み物が飲み放題だったり、その場で焼いたパンが楽しめたりなど充実した環境が整っていました。 毎週金曜日にはBar Timeというイベントが開催され、GMO各社のパートナーなどが自由にお酒を飲みながら交流できるようになっています。気兼ねなくいろいろな人に話しかけにいけるような雰囲気が非常に楽しかったです。 雰囲気 とても明るく、フレンドリーな雰囲気が醸成されており、お互い冗談を言い合うような距離感が多く見られたように思います。廊下ですれ違った時にはどんな人でも挨拶をかわすというのが当たり前のように行われていました。その他にも、端々にコミュニケーションが生まれるような工夫があり、気軽に相談や雑談ができるような雰囲気でした。 働いている人 GMOで働いているということに誇りを感じている人が多かったように思います。優秀な人や意欲のある人が多く在籍しているというのがその誇りの一つの源泉のように思います。例えば私のチームのメンターはClaude CodeのContributorでしたし、自分が所有しているサーバーに対してハッキングをして遊んでいるような方もいました。技術と向き合うことを楽しんでいて、意欲的に取り組んでいる人が多かったです。 別の視点で言うと、キャリアを明確に見据えている人も多かったです。若いうちからある程度の裁量権を持って仕事ができるような構造になっていたように思います。グループ各社にある幅広い事業部の中で自分にあった事業部を見つけ、そこでチームとして活動する中で自分のロールを見極め、必要となる能力を身に着けていっている人が多かったです。また、キャリアラダーが規定されており、自分がどのようなルートでどのようなエンジニアになるのか、どのようなマネージャーになるのかそういったことをそれぞれ一人ひとりが明確に目標を持っていたように思います。 事業内容 何よりも幅の広さが尋常ではなかったです。グループ会社が110社ほどあり、総顧客数は1700万人にも上ります。ウェブサイトを作ったことがある人は一度は触ったことがあるようなドメインやVPSだったり、普段の買い物の中での決済サービスだったり、ネットバンクや広告などなど、その事業の広さは挙げ連ねるほうが難しいです。このような事業の広さはGMOが持っている知見の広さや柔軟さがよくわかる気がします。さらに、新しくGMO AIRというAI×ロボットを取り扱った事業にも取り組み始めており、前衛的な姿勢がよくわかります。 少なくとも今回のインターンを経験したうえで、がっかりすることはありませんでした。むしろ、GMOは某メガベンチャーなどと比較して少し古い会社という印象があった僕にとっては、いろいろと常識が覆されるわくわくするような体験でした。 学びや気づき インターンの取り組み方 今回、私は就職活動という視点では参加していませんでした。先述した通り、今回が最初で最後のインターンであり、スタートアップでの活動を考えていたため、どちらかというと日本IT業界の重鎮の中にはどのような環境が広がっているのかということを知りたいという目的で参加していました。 このような姿勢でインターンに臨んだことは非常に有意義であったと考えています。これは私の性分によるところもあるかと思いますが、就活という文脈の上でインターンに参加していた場合、評価してもらうために打算的に動くことがメインになってしまい、本来のインターンの目的であるべきの「俯瞰的に企業を評価する」ということができなかったと思います。今回私は、親から譲り受けたかのような無鉄砲さでメンターや人事の方々をはじめとして役員方にもいろいろと質問する機会を作ることができました。何よりも自分が「一パートナーになった」と仮定して参加するほうがイメージが湧きやすく、実際に採用されて働くということになった場合も違和感を覚えることがなくなるのではないかと思いました。 AIとの向き合い方 今回参加してみて、今後サービスのサイクルはとてつもなく早くなっていくと確信しました。AIと伴走することでこれまで律速となっていた開発という行程が大幅に短縮されることで、ユーザーに届くまでの速さが格段にあがり、それに伴って得られるフィードバックも早くなります。すなわちこれから必要になっていくのは、AIによる開発の速さに負けないような思考の速さであると感じました。常に潜在的に存在している可能性に意識を向けられるような姿勢を養うことが大切になっていくと気づきました。 パートナーと話す中でAIエンジニアの方と話す機会も多くありました。いくつも興味深い話があったので、3つほど並べておきたいと思います。 AIのやっていることを見極める審美眼が必要になる まだまだAIは「そうじゃないだろ」ということを返してくることも多いですが、今後その背景にある情報の確度があがったり、アルゴリズムが改良されたりするにしたがって、我々が「そうじゃないだろ」と認識できないような領域までいくことになるでしょう。そうなった場合に、AIがやったことに対して、それはどういうことなのか、正しいのかという「そうじゃないんじゃね」と感じるような審美眼を養うことが重要になります。 AIは脳を拡張するのではなく増やすために使うべき AIの利点に自分の知識の範囲以外のことまで思考できるという点があります。しかし、これは同様にあずかり知らぬところまでやってしまうというリスクでもあるわけです。つまるところ、AIは自分の脳の拡張として使うには危うい側面も備えているということです。なればこそ、AIが果たす役割は自分の脳をトレースして処理能力を増やすための装置として使うという意識が大切になるということです。 AIには責任が取れない どこまで優れたAIができたとしても、そのAIには責任を負わせることができません。結局はプログラムなわけであって、どのようにあったとしても最後は人間が判断して人間が責任を持たなければいけないわけです。 これらの話の本質はすべて共通しているように思います。それは、結局我々も学び続けなければいけないということです。AIが表世界に出てきて早4,5年、「それってAIにやらせればいいじゃん」という考え方がある程度定着してきたように思います。ただ、そこで見落としてはいけないのが、「自分でもできることは」という大前提です。AIはこれまで人間の手でやるには限界が存在したものを超越することができるツールです。自分個人の手でできないことをやらせるためのツールではないのです。この文脈で言えば、自分ができることを増やしていくことこそが、「それってAIにやらせればいいじゃん」と言える人間になるために大事なことなのではないでしょうか。 おわりに 今回の10daysインターンに参加した感想は「何も言えねえ」です。 自分がこれまで培ってきた性質、技能をフルで活用して頭を回し続けた2週間でした。自分がどこまで何ができるのか、何を今後伸ばしていくべきなのか、何が自分にはできないのか、人に頼るということはどういうことか、人と議論を重ねるということはどういうことか。様々なものへの解像度をあげることができましたし、かつてないほどに深くAIと向き合うことができました。このインターンのGMOインターネットグループサイドの意図として「GMOインターネットグループのファンを増やす」ということがあったようですが、まんまとファンになってしまいました笑。 百利あって一害なしです。

AIは今や、生活や仕事に欠かせない存在です。特にChatGPTに代表される対話型AIは、幅広いタスクをこなせる“万能アシスタント”として、多くの人に活用されています。一方で、よりクリエイティブな作業――たとえば画像や動画の生成に特化したAIサービスも登場しています。『ConoHa AI Canvas』もその一つで、ビジュアルコンテンツに強みを持ち、創作の可能性をさらに広げてくれるのが特徴です。今回、ConoHa AI Canvasには動画生成モデル「Wan2.2」と画像生成モデル「Qwen-Image」がプリインストールされ、すぐに利用できるようになりました。本記事では、ChatGPTとConoHa AI Canvasで実際に生成した画像を比較しながら、それぞれのAIをどのように使い分けると効果的なのかを探っていきます。 1. 画像生成比較 今回は、以下のプロンプトを使用し、ChatGPTとConoHa AI CanvasのQwen-Imageで生成した画像を比較しました。 古民家の木造の軒先に座る若い女性。夏の暑い日差し。彼女はスイカを食べている。女性はGMOと青字で記載されたTシャツを着ている。横では古い扇風機が回っている。日本の田舎の夏らしい雰囲気。アニメ風、明るく爽やかでノスタルジックな描写。 1-1. ComfyUIの起動 起動方法はこちらの記事をご覧ください。 1-2. テンプレート選択 ComfyUIのメニューから「テンプレートを参照」を開きます。 「画像」を選択し、「Qwen-Image Text to Image」を開きます。 1-3. Qwen-Imageで画像生成 プロンプトを入力し、「実行する」をクリックします 1-4. ChatGPTで画像生成 ChatGPTにも同じプロンプトを入力し、画像を生成します。 1-5. 生成された画像の比較 Qwen-Imageで生成した画像 ChatGPTで生成した画像 生成時間: 180秒 生成時間: 90秒 ピクセル: 1328 x 1328 ピクセル: 1024 x 1536 ※ブログ掲載用にサイズを調整し、クレジットを記載しています。 生成された画像の感想 　どちらの画像にもGMOのロゴは正確に描かれていますが、ChatGPTの方がより自然に背景になじみ、全体として違和感が少なく感じられます。扇風機も両方に描かれていますが、羽根は回転していません。一方で、Qwen-Imageはより立体的な表現がされているものの、左右の扉にずれがあり、全体の統一感という点ではChatGPTの方が優れています。 2. Qwen-Image Editで試すAI画像編集 次に、Qwen-Image Editを使用して生成した画像を編集しました。 2-1. テンプレート選択 テンプレートから「画像」を選択し、「Qwen-Image Edit」を開きます。 2-2. Qwen-Image Editで画像編集 先ほど生成した画像をアップロードし、プロンプトを入力します。 2-3. 生成された画像 アイスクリームを食べている 生成時間: 234秒 浴衣を着ている Qwen-Image Editを利用した感想 　メインの人物については表情やポーズを変更できますが、背景の要素を細かく指定して変えるのは難しいようです。たとえば「扇風機を回す」や「背後の扉を同じ模様にする」といった指示は、まったく反映されませんでした。Qwen-Image EditがあればAIで自由自在に画像を編集できると思っていましたが、現状ではまだ限界があると感じました。 3. Wan2.2で広がる「画像から動画」の表現 最後に、Wan 2.2を使用して「画像から動画」を生成しました。 3-1. テンプレート選択 テンプレートから「ビデオ」を選択し、「Wan2.2 14B Image to Video」を開きます。 3-2. Wan2.2で動画生成 先ほど生成した画像をアップロードし、プロンプトと動画の長さを指定します。 動画の長さはフレーム数となります。今回は81フレーム（5秒）に設定しました。 3-3. 生成された動画 生成時間: 228秒 Wan2.2を利用した感想 　Wan2.2は、事前の評判が良かったため期待していましたが、その期待にしっかり応えてくれました。5秒間の動画を約4分で生成でき、生成速度としてはかなり高速な印象です。 　プロンプトで特に指定していないにもかかわらず、背景の鳥が自然に動いており、細部の作り込みに驚かされました。全体的に見ると、細かい部分にはまだ改善の余地があるものの、現時点でも十分に高い完成度を感じます。今後のアップデートによる進化に期待が高まります。 4. まとめ 　今回の検証では、ChatGPT・Qwen-Image・Wan 2.2といった生成AIツールの連携によって、テキストから動画までを一貫して制作できる可能性を確認しました。各モデルの特性を理解し、目的に応じて使い分けることで、より効率的かつ高品質な成果物が得られると感じます。今後は、生成精度や編集自由度の向上にも注目していきたいと思います。

自己紹介 はじめまして。GMOインターネット株式会社 宮崎オフィスで勤務しております。フジモト ユウスケと申します。まずは簡単に自己紹介をさせてください。 普段はお名前.comというドメイン登録・販売サービスのデザインチームにてリーダーとして就業させていただいています。主に業務のリードやフォローをはじめ、マネジメント、採用活動、拠点で起こる事象や課題の対応などありがたいことに幅広い分野でお仕事をさせていただいています。 特徴のせいか、時折「変な人」と言われることもございますが、クリエイターとはそもそも“変”な人の集まりだと思っていますので、むしろ誇りに感じています。 クリエイターが採用活動をする意義とは？ さて、ここから本題です。今日お話しするのは、タイトルの通り「クリエイターが採用活動をする意義とは？」についてです。 採用活動は本来、人事部門の管轄であるのが一般的であり、クリエイターの主業務は「制作」です。制作物を通して事業や社会の課題を解決し、豊かな未来を築き上げていくことこそが、意義・義務・責任を伴うクリエイターの本分だと認識しています。 したがって、人によっては「採用に注力する私の姿」を異様に感じるかもしれません。 では、なぜ私がこれほどまでに採用に力を入れているのか――その理由は大きく4点あります。 1. 前任のリーダーから受け継いだ宮崎チームを成長・拡大させたい 2. 専門職のことは当人にしか分からない 3. 会社のブランディングに寄与したい 4. インハウスクリエイティブの楽しさを伝えたい 1. 前任のリーダーから受け継いだ宮崎チームを成長・拡大させたい まず一つ目の「宮崎チームの成長・拡大」についてです。私が宮崎オフィスに加わった当初は、チーム規模もまだ小さく、何を軸に成長していくか模索している段階でした。前任のリーダーから受け継いだ“挑戦する文化”や“自由な発想”を守りつつ、より多様なクリエイティブが生まれる環境をつくるには、仲間を増やし、新しい視点を持つメンバーと共に試行錯誤を重ねることが欠かせません。採用はその第一歩であり、未来の仲間を迎えることは、チームの未来を形づくる最も重要な施策だと考えています。 2. 専門職のことは当人にしか分からない 二つ目の「専門職のことは当人にしか分からない」という点も、クリエイター採用ならではの大きな理由です。デザインや開発の現場は、日々の技術進化やトレンド変化が激しい領域です。実際に手を動かしているクリエイターだからこそ、求職者が持つスキルやポテンシャル、そして現場で活躍できるかどうかを、より具体的に見極めることができます。人事だけでは把握しきれない「この人と一緒に作りたい」と感じる直感的な部分も、同じ専門領域のクリエイターだからこそ感じ取れるものがあります。また、これから共に戦っていく言わば戦友を直接スカウトしたり、チームでデザインするという目線もやりがいに繋がっています。 3. 会社のブランディングに寄与したい そして三つ目は「会社のブランディングに寄与したい」という思いです。採用活動は、会社の価値や魅力を世の中に伝える重要な接点です。クリエイターが前面に立ち、自らの言葉で働く環境や挑戦のリアルを発信することで、単なる求人情報では伝わらない“文化”や“空気感”が求職者に届きます。結果的に、"GMO"というブランドの信頼性や存在感を高めることにつながると考えています。特に宮崎では知名度こそ広がってきたものの、クリエイターがいる会社という認識は弱いと感じることも多く、ここ宮崎でも東京と同じレベル感の業務ができる楽しさは伝えていきたいと心がけています。 4. インハウスクリエイティブの楽しさを伝えたい 最後になりますが、「インハウスクリエイティブの楽しさを伝えたい」という思いです。社内に所属するからこそ、プロジェクトの最初のアイデア段階からリリース後の改善まで、すべてのフェーズに深く関われます。単発的な案件ではなく、サービスやブランドの成長を長期的に見守り、育てていけるのはインハウスならではの魅力です。 また、エンジニアやマーケターなど他職種のメンバーと日常的に近い距離で協働できるのも大きな楽しさです。多様な視点が混ざり合うことで、新しい発想や表現が生まれ、自分のクリエイティブが事業そのものに直結する手応えを日々感じることができます。成果がダイレクトにユーザーや社内外からの反応として返ってくる瞬間は、何度経験しても心が躍ります。 以上の理由から、私は「クリエイターが採用に関わる意義」があるのではないかと考えています。採用に関わることは、制作と同じく未来をデザインする行為なのではないでしょうか。新たな仲間との出会いは、私たちが生み出すプロダクトやサービス、そして宮崎から発信するクリエイティブを、より豊かにしてくれるはずです。 学び 私自身、この採用活動を通して多くの学びを得ています。候補者との対話は、単に人材を選ぶ場ではなく、自分たちの価値観やビジョンを改めて言語化する機会でもあります。「私たちは何を目指し、どんな未来を描きたいのか」──その問いを仲間と共有しながら考える時間は、制作現場の成長にも直結します。 また、採用は一方向の“選ぶ”行為ではありません。応募者の方々が「ここで働きたい」と思える会社であるかを、私たち自身が常に問われています。だからこそ、オフィスの雰囲気づくりやチームの文化をより良くしていく努力も欠かせません。採用に携わることで、組織を内側から磨き続ける責任を強く感じるようになりました。 これからも宮崎からクリエイティブを発信し、「この場所で一緒に挑戦したい」と思っていただける仲間を迎えるために、採用活動と制作活動の両輪を大切にしていきたいと考えています。 最後に 最後に、もしこの文章を読んで少しでも興味を持っていただけたなら、ぜひ私たちのチームに会いに来てください。新しい出会いこそが、未来をより鮮やかに彩る第一歩だと信じています。 最後までご拝読いただき、ありがとうございました。また次回の記事でお会いしましょう。

京都大学 学術情報メディアセンター 首藤研究室とGMOインターネットグループがタッグを組み、AI・ブロックチェーン・サイバーセキュリティなど、急速に進化するテクノロジーを「実践的」かつ「革新的」に学べる無料イベントです。アカデミアとビジネスの最前線で活躍するエキスパートが最新トレンドや実装事例をわかりやすく紹介いたします。現地参加者は講演後の懇親会にて議論やQ&Aの時間もたっぷり設けています。 イベント概要 開催日時：2025年12月12日（金）開催時間：17:30 ～ 20:30開催場所：オンライン配信・京都大学学術メディアセンターオフライン開催住所：京都府京都市左京区吉田二本松町 京都大学 学術情報メディアセンター南館参加費用：無料 イベントの申し込み/詳細はこちらから　 ※現地での参加については学生の方のみが対象となりますのでご了承ください。※当日、学生の方は受付にて学生証のご提示をお願いいたします。 こんな方におすすめ！ ●IT技術者や研究者を志す学生の方●IT業界で働いている方●先端技術に興味がある方 スピーカー情報 妹尾 卓磨 氏　（Turing株式会社 スタッフリサーチャー） 2020年Sony Researchに新卒入社し、社会人博士として慶應義塾大学でコンピュータサイエンスの博士号を取得。Sony Researchのシニアリサーチサイエンティストとして、Gran Turismo Sophyプロジェクトを牽引し、人間を凌駕するゲームAI開発に貢献する。2025年Turing株式会社に入社し、完全自動運転に向けた研究を行う。オフライン強化学習ライブラリ「d3rlpy」含め、オープンソース活動を行っており、国内外の主要学会での多数の受賞歴を持つ。 東風上 奏絵 氏（京都大学 大学院 情報学研究科 特定助教） 2023年より現職2015年東京大学工学部機械情報工学科卒業2022年東京大学大学院学際情報学府 博士課程修了2022 年東京大学大学院情報理工学系研究科特任助教博士 (学際情報学)専門はヒューマンロボットインタラクション特に、子どもとロボットのインタラクションや教育ロボットの研究に従事第38回日本ロボット学会 学会誌論文賞受賞（2024） 滝澤 照太　（GMOインターネットグループ株式会社 グループ研究開発本部 次世代システム研究室 シニアアーキテクト） 2018年 GMOインターネット株式会社に新卒入社。アプリケーションエンジニアとして、アドテク関連サービスやビッグデータ解析基盤の開発，複数の新規サービスの立ち上げに携わる。2024年よりヒューマノイドをはじめとするロボットの制御ソフトウェアの研究プロジェクトに参画。専門領域は低レイヤ・組み込みシステム。 タイムテーブル 17:10　開場、受付開始17:20　配信開始17:30　オープニングトーク17:35　Session1 18:00　Session2 18:30　Session3 19:20　配信クロージング、懇親会20:30　中締め、退場 懇親会（会費無料・飲食あり） 会場参加の学生の方にはセッション後の懇親会をご用意しております。登壇後のスピーカーへ直接質問できる機会ですので、お近くの方はぜひ現地にてご参加ください。皆さんのご参加をお待ちしています！ イベントの申し込み/詳細はこちらから　 ※現地での参加については学生の方のみが対象となりますのでご了承ください。※当日、学生の方は受付にて学生証のご提示をお願いいたします。

GMOインターネットグループは、2019年より小中学生向けのプログラミング教育カリキュラムの開発、IT企業4社や東急グループの社員を講師として派遣する渋谷区授業支援、教員に向けたプログラミング教育の研修、そのほかワークショップやイベントなどの実施を通じて、プログラミングへの興味喚起やキャリア教育を行う https://kidsvalley.jp/ の活動に参画しています。本編では今年度GMOインターネットグループが次世代のリテラシー人財を育てる取り組みについて詳しくお伝えいたします。 現場エンジニア・クリエイターが先生に！次世代教育への挑戦 GMOインターネットグループでは、2019年からプログラミング教育やPBL（プロジェクト型学習）授業の支援に取り組んできました。これまで各地で独自に展開してきた探究学習・プログラミングを軸とする教育プログラムを、より多くの小学生に届けるべく、今年はカリキュラムの全面アップデートを実施。さらに、教育支援に挑戦したいエンジニア・クリエイターをグループ横断で公募しました。 今年は、グループALLで挑む初年度。社内から選ばれた17名のエンジニア・クリエイターが、講師・メンターとして教育現場に立ちます。現場で培った最先端の技術や思考法を、子どもたちにわかりやすく届けることを通じて、学校教育と社会の現場をつなぐ新しい学びの提供に挑戦しています。 学校教育と現場経験をつなぐエンジニアの役割 AI・IoTの浸透、サイバー攻撃の高度化。ITが社会の根幹を支える一方で、その本質の理解や応用力は教育現場ではまだ十分に育まれていません。ここで重要なのは、単に技術知識を教えることではなく、「実際の現場で使われる技術や考え方」を子どもたちに伝えることです。民間企業のエンジニアは、最新の技術動向や実務経験を持ち、課題解決のプロセスやセキュリティの現場感覚を持っています。こうした知見は、教科書だけでは得られない実践的な学びとなり、子どもたちのITリテラシーや探究心を育てるうえで大きな力になります。 プロジェクト活動詳細 渋谷区小学校授業支援：PBL型授業で「考える力」を育む 今年は渋谷区の小学校で全34コマにわたるPBL型授業(課題解決型学習)に講師としてプロジェクトメンバーが参加しています。低学年では「伝えたいことを伝えよう」、高学年では「プログラムで紹介しよう」といったテーマで、対象学年に応じた課題設定や授業運営を行っています。 「なにを、だれに、どんなふうに伝えるか」「なにを、どうしたら、自分の思うようにプログラムを動かせるのか」を考える過程を通じて、子どもたちの論理的思考力や表現力、課題解決力を育みます。授業では、技術の仕組みや考え方に触れながら、実践的な学びを体験できる構成。プログラミングや物ごとの組み立て方などの知識を、身近なテーマに落とし込み、自ら考え伝える力を養うことを目指しています。 GMOデジキッズ：小学生向け夏休みイベント GMOインターネットグループでは、KidsVALLEY参画翌年の2020年から、小学生向けに夏休みイベント「GMOデジキッズ」も開催しています。今年のテーマは、デジタル時代を生きる子どもたちにとって欠かせない「サイバーセキュリティ」。講師は、グループでサイバーセキュリティ事業を担うGMOサイバーセキュリティ byイエラエ株式会社から2名が務めました。 イベントでは、パスワードの重要性を「自分たちを守るための最初の防御線」として伝え、親子で一緒に学べる形式で実施。「サイバー攻撃は遠い世界の話ではなく、身近に潜むリアルな脅威」であること、そして「どうすれば自分たちを守れるのか」を親子で考えながら学んでいただく貴重な機会となりました。 社会貢献の枠を超えた“リスキリング”と“共創” 本プロジェクトに参加したエンジニア・クリエイターが実感したのは、「社会貢献 × 自己成長 × 組織連携」という三位一体の価値です。単に子どもたちに教えるだけではなく、教える過程そのものが、技術者としての新たな学びの場になっています。 1.IT教育の現場で生まれる学びの循環 たとえば、子どもたちにプログラミングの考え方・セキュリティの本質を伝えるには、複雑な仕組みやルールを「比喩」や「体験」に落とし込む必要があります。 パスワードの大切さ＝自宅の鍵に例えるフィッシング詐欺＝”だます技術”の構造を解剖するホワイトハッカー＝”ネットの番人”というロールモデルを描くループ処理は「朝起きて歯を磨く→朝ごはん→登校」の毎日のルーティンに例える条件分岐は「もし雨なら傘をさす、晴れなら帽子をかぶる」といった日常の意思決定に例える こうした「複雑な概念をわかりやすく伝える」プロセスは、単なる授業の工夫にとどまりません。子どもたちがどこでつまずくかを観察し、伝え方や環境を試行錯誤する中で、エンジニア自身も学びの本質や社会における自身の技術や経験の意義を再認識することができます。子どもたちはPBL型授業を通して「考える力」や「課題解決力」を育むだけでなく、デジタル社会で安全かつ創造的に生きるためのリテラシー教育そのものにつながっていると現場レベルで実感しています。 2.次世代教育がつなぐ、仲間との社会的価値共創 本プロジェクトには技術領域も役割も異なるパートナーがグループの垣根を越えて集まり、「次世代のために」という共通の目的で動活動しています。この過程で生まれる社内横断のつながりや新たな価値創出は、グループとしても大きな財産です。 教育の現場で子どもたちに教えることは、同時に「自分の技術を言語化し、仲間とつながり、社会と向き合う」機会でもあります。 今後の展望 今後は、GMOインターネットグループが本社を構える渋谷区をはじめ、地方拠点への地域貢献を軸に、より多くの次世代にITリテラシー教育を届けられるよう、活動の幅を広げていきたいと考えています。地域に根ざした取り組みを出発点として、子どもたちが安全かつ創造的にITを活用できる力を育むための活動を、グループ一丸となって推進してまいります。

2025年7月30日、渋谷にある株式会社ココナラ本社にて「生成AI活用のリアルを語る」技術イベントが開催されました。GMOインターネットグループからは、エキスパート2名が登壇し、それぞれ異なる立場から生成AIの導入・活用の現場知見を共有しました。本記事では、当日の内容を技術広報視点で再構成し、「これから生成AI活用を推進したい」「PoCをどう進めるか迷っている」方々にとってのヒントをまとめます。 イベント概要 開催日時：2025年7月30日(水)19:00-21:30開催場所：株式会社ココナラ本社URL：https://coconala.connpass.com/event/359486/参加費：無料 GMOインターネットグループの登壇者 GMOインターネットグループ　エキスパート(Webアプリケーション開発）2016年GMOアドマーケティング株式会社に入社。2025年にGMOインターネット株式会社に転籍。入社以降、広告配信サービスの開発を担当し、現在は開発に携わりながら開発チームや組織のマネジメントも担当。GMOインターネットグループを横断した技術同人誌の制作や技術ブログでの情報発信の活動を通して、グループの垣根を超えたアウトプットや社内コミュニティの醸成に取り組む。 GMOインターネットグループ　エキスパート(データサイエンス）2023年にGMO NIKKO株式会社へ新卒入社。2025年にGMOインターネット株式会社に転籍。入社後は、グループ横断プロジェクト「AIしあおうぜ！」のアドバイザーを務めるほか、広告効果予測プロジェクトや漫画解析AI、マーケティングミックスモデリング（MMM）、新規事業におけるデータサイエンス業務など、幅広い開発に携わる。専門は時系列解析や数理最適化。趣味はバイク、釣り、ベースギターの演奏、料理。 開発組織における生成AI活用の舞台裏〜導入・推進・活用のリアル〜 組織単位で進める生成AI活用フェーズへ かつて開発現場における生成AIの活用は、コード補完やスクリプト作成など、比較的補助的な用途にとどまっていました。 しかし、AIコーディングエージェントの登場によりエンジニアの働き方は大きく変化し、 「組織としてどのように取り入れ、浸透させていくか」が重要なテーマとなっています。 石丸さんの発表では、2023年にGitHub Copilot、CodeRabbitの導入が始まり、 2025年にはDevinのTeamプラン導入を皮切りに、現在は組織全体でAIコーディングエージェントや関連ツールの活用が進んでいることが語られました。 利用率と成果 活用率：90％(20名中18名)毎日活用しているメンバー：約70％削減効果：76％が「週3時間以上の開発時間短縮」を実感主な使用ツール：Devin／Claude Code／GitHub Copilot AIコーディングツールの活用により、一週間あたりに削減できた時間は？ 削減した時間の再配分先は？ 削減された時間は、調査・検証や新機能開発に再配分されており、単なる時短効果にとどまらない好循環が生まれています。 推進を支える仕組みと文化 GMO AIブースト支援金（コスト支援制度）GMO Genius / 虎の穴　（パートナーの継続的な学習機会の提供）部署内ナレッジ共有会 GMOインターネットグループでは全社で生成AI活用を促進する仕組みが整備されています。AIブースト支援金については、エンジニア以外の業種でも、業務に応じて自由に生成AIを選択・導入でき、パートナー1人あたり最大1万円を目安とし、「天秤AI biz byGMO」をはじめとした複数の生成AIサービスの利用費用をグループ各社が支援するものです。そういった全社的な取り組みも相まって、経営層や非エンジニアの理解が得られやすいこともAI活用の推進・文化醸成の追い風になっていると石丸さんはいいます。 部署内ナレッジ共有においては、毎週の部署定例で持ち回りによるナレッジ共有会の開催しており、直近では Devinや Claude Code の業務活用事例を発信。ナレッジ共有専用の Slack Channelを作成し外部勉強会の情報や勉強会のレポート共有したり、各ツールのTipsを発信する取り組みを行っているそうです。 現場が感じている課題 情報キャッチアップの負荷（ツールの変化が早すぎる）AI出力の品質ばらつき（精度や整合性の不安）コードレビューの負担が増加 今後取り組みたいこと 効果測定/KPIFour Keys や Pull Request数 などをベースとした生成AI活用による生産性向上の可視化と計測 利用促進AIコーディングツール利用率100%に向けた情報発信やナレッジ共有の仕組み強化 セキュアで効率の良い環境整備Vertex AI, Bedrockの活用 技術広報が見た！開発現場の生成AI活用のリアルまとめ 石丸さんの登壇では、「ツール導入」ではなく“文化と制度による定着”に向けた取り組みが印象的でした。支援制度、教育コンテンツ、情報共有チャネルなど、開発者が迷わず使える環境を整える動きが見え、エンジニアの自走を支える設計が根付いていました。社内の生成AI活用を「組織にとって当たり前」にするには何が必要か。まだまだ利活用における組織課題は多くあれど、その問いに対する具体的なアクションとデータが語られたセッションでした。 機械学習エンジニアの生成AI活用法 前提知識：従来ソフトウェア vs 機械学習／生成AIの“品質”の違い 従来ソフトウェアの品質観点 仕様が明確に定義されている（例：API仕様書、画面設計書）品質＝「仕様どおりに動作しているか」要件定義で目的に合っているかを事前に担保 機械学習・生成AIの品質観点 仕様（モデルの振る舞い）は“学習”から得られる品質＝「得られた振る舞いが、目的に対して妥当か」「仕様どおりか」ではなく、「意図に沿っているか」が問われる この違いを理解していないと、生成AIを評価する際に「バグがない＝品質が高い」とか「他のモデルより複雑なタスクが解ける=品質が高い」という誤解をしやすくなります。 そこで杉浦さんは、AIでは「実装の正しさ」よりも「振る舞いの妥当性」をどう評価するかが鍵になると説いていました。 有効性目的に合致しているか（例：分類精度）信頼性同じ入力に対して常に同じ出力か安全性危険な出力がないか（例：自動運転）公平性バイアスを含まないか（例：人事評価）プライバシー個人情報の漏洩を起こさないかセキュリティ外部攻撃に強いか※以下の事例では、「有効性」と「信頼性」に焦点を絞って評価を実施 プロジェクト背景 目的：検索クエリから「ブランドワード」か「非ブランドワード」かを自動分類したい処理量：バッチで50万件／日技術構成：LLM（大規模言語モデル）＋ルールベース（パターンマッチング）併用 品質設計ステップ STEP1：品質項目の定義品質を「有効性」と「信頼性」に分解 項目定義対象処理有効性精度が高く分類できていること／処理時間が実用レベルであること精度／推論時間信頼性同一入力に対して常に同じ出力を返すこと一貫性（Deterministic性）※「公平性」や「倫理性」は今回の分類タスクには該当しないため除外 STEP2：評価指標の設計各品質項目を定量的に測れる形に落とし込む 品質項目評価指標補足有効性再現率（Recall）実際に正である中で正と分類できた割合有効性適合率（Precision）正と分類された中で本当に正だった割合有効性推論時間（スループット）1件あたりの処理時間信頼性一貫性率（Consistency）同じ入力を複数回通したときに、常に同じ分類結果になる割合 STEP3：目標値の設定目標値の設定にあたっては、PoC（概念実証）の結果や競合サービスの性能、業界全体でのベンチマーク値などを参考にし、「どれだけ実現できるか」よりも「ユーザーにとって妥当かどうか」という視点。また、同じ再現率（Recall）を達成していたとしても、どのような誤分類が含まれていたかによって"分類の質"は異なるため、単なる数値だけではなく実際の判定内容の妥当性も加味して評価を行うこととする。 STEP4：検証データセットの作成 検証データセットは、実運用で想定される検索クエリを人力でラベリングして構築する。 理想的には実運用のケースを網羅することが望ましいが、コストとのトレードオフがあるため、重要なケースに絞って作成する。 ここで特に重要なのは、正解ラベルの定義を厳密化し、人間側の誤分類を混入させないことである。 STEP5：アーキテクチャ設計 本システムでは、「初回推論はLLM」「二回目以降はキャッシュ」 という方針で設計を行った。 ・初回のみLLMで推論し、結果をキャッシュ化 ・同じクエリに対しては再推論せず、常に同じ結果を返すことで一貫性を保証する。 ・高速マッチングの併用 ・一部のケースではルールベースのパターンマッチングを導入。これにより、LLMを回さずに即座に判定可能なケースを処理し、スループットを向上させた。 ・クエリとブランドワードDBの連携 ・新たに分類されたクエリはブランドワードDBに蓄積され、以後は再利用される仕組みを採用。これにより「再現率」と「処理効率」の両立を実現している。 実測結果 プロジェクトでは生成AIのチューニングを繰り返し、目標値を達成することができた。 ただし、検証用データセットでの結果であるため、本番環境では一定のばらつきが生じる点に留意が必要である。 無駄に調整を繰り返すことなく、効率的に改善を進められた点も重要な成果だった。 技術広報が見た！杉浦くんの設計哲学！ それはズバリ！ 杉浦「品質指標には“正解”はない。なぜその項目を選んだのか、なぜその目標値にしたのかを“説明できること”が重要」だ とのことでした！プレゼンからは「精度の高いAIを作る」以上に、なぜこの評価軸なのか？説明責任をもって運用できる状態を目指すことこそが品質設計の本質であるということだと理解しました。単なる技術的な指標設定にとどまらないという責任感ある杉浦くんの設計思想が垣間見えました！世に新たな価値を生み出すエンジニアのみなさんはかっこいいですね・・。 さいごに 今回のエキスパート2人のセッションは、生成AI活用を「導入して終わり」にせず、現場の制度設計・品質担保の視点から深く掘り下げた実践知の共有でした。 石丸さんが語った“文化と制度で定着させる”という視点。杉浦さんが示した“説明責任を担保した設計”という思想。 どちらも「現場から生まれるAI活用のリアル」として、お越しいただいたみなさまの一助となっていましたら幸いです。 エキスパート活動について 今回登壇した石丸さん・杉浦さんを含め、GMOインターネットグループにはそれぞれの専門領域でグループひいては業界の技術・クリエイティブ力をけん引する使命を担った精鋭エキスパートが11名在籍しています。エキスパートの活動についても以下サイトで順次発信しておりますのでぜひご覧ください。 エキスパート制度 | GMO Developers

AIで広がる楽曲制作の新しい可能性と題しまして、"楽曲制作過程"とこれまでの制作に"AIの知識を取り入れ完成度を高める"ということを執筆していこうと思います。先にお伝えしますが、AIで生成した音は入っておりません。あくまでも自分が持ち合わせていない知識や表現を知るためにAIを活用した、ということがテーマになります。 前提 この記事の登場するキャラクターと楽曲を軽く説明します。 美雲このは 弊社サービス「ConoHa byGMO」の応援団長 兼 VTuber。 毎年、夏に「このはぴば！」という3Dライブを開催。合言葉は「清楚可愛い」。YouTubeは こちら 「このはぴば！2025」のアーカイブはこちら https://www.youtube.com/live/XiYGHdOKtCg 楽曲 今回紐解いていく楽曲は今年の「このはぴば！2025」で披露したオリジナルソング「サマーリフレイン」です。 https://www.youtube.com/watch?v=78rzyNnlU5Q 曲のテーマ 今回の楽曲は「恋をする（恋に気づき始める）女の子の夏」がテーマでした。テーマの理由は「このはぴば！2025」が「学生の頃のような青春夏祭りデート」だったためです。 長くなりましたがここから本題です。 楽曲制作過程 下準備 いきなりコードや歌詞を考える前に、制作の途中で楽曲がブレないよう登場人物の設定やちょっとした物語をいつも書いています。 楽曲の登場人物設定 今回はイベントに合わせて世界観に入り込んで欲しい、共感してほしいという想いがあったためそれぞれの名前はあえて決めませんでした。 楽曲の物語 登場人物を決めた後に軽い物語を書いているのですが最近はChatGPTに書いてもらってます。以前までの手書きだったのでそれに比べるとかなりの短縮になりました。 ただ一発で思った通りの物語にはならないためなんとなくイメージしている曲の展開と歌詞、それを何度も指示して調整していきます。今回は初期段階で急に戦闘ものになったりしました。 調整する過程で言語化できたり、ふんわりしていたイメージの輪郭が見えてきたりするのでこの時間も結構有意義です。 作曲 下準備をベースにコードとメロディを考えます。今回はコードから考えました。 明るめのコード進行をベースに恋心の複雑さを表現するためにオンコードを多用しています。複雑さに加えて、青春のエモさを出すためにセブンスやディミニッシュ、sus4やadd9等も"あえて"入れています。 ChatGPTに考えたコードを伝えて「もっと複雑にしてみて」のような感じで自分にない引き出しからヒントをもらった部分もあります。 今回、メロディはコードを作っている際にスキャットで口ずさんでいたものをほぼそのまま使いました。急に良いメロディが出ることもあるので忘れないようにずっと録音しながらコードを考えることが多いです。「口ずさみたくなる」「印象に残る」というよりもスッと入ってくるようなメロディを意識しました。 作詞 かなり苦戦したのが作詞でした。普段ちょっと捻った作詞をしているせいでスッと入ってくるようなメロディに合わせたストレートな歌詞が思い浮かびませんでした。 そもそも「恋」ってどんな感じだっけ…？そこから始まりました。 まず、ChatGPTに「恋」とは何か聞いてみました。あまり期待してはいませんでしたが辞書に載っているような感じではなく、しっかり気持ちやニュアンスを言語化して答えてきて驚きました。その後も初恋や青春等を噛み砕いていき最初にできた歌詞が下記です。 いつからだろう空をなぞったのは気づけば　同じ景色混ざりあって声が届く距離もどかしくて靴音だけ　やけに大きく響くリズム 悪くはないんですが伝わりにくい。ストレートな歌詞、スッと入ってくるような歌詞とは乖離していると感じつつも詰まってしまったため、ニュアンスを探るために少女漫画を読み漁りました。最終巻までではなくテーマである「恋に気づいた瞬間」までを何作品も読みました。何度も修正を重ねてできた歌詞がこちら いつからだろう雲をなぞったのは気づけば　蝉の声風に乗って手を引いて走るこの時間がざわめき　弾けるラムネみたい 夏の風景や高鳴る恋の予感のような描写が浮かぶような感じになったかと思います。 編曲 できたコードにいろんな楽器を乗せていく工程になります。 ここに関しては自分のサウンド感を頼りに1つずつ足していきます。今回の楽曲に関しては大体80トラックほどになりました。 曲中で2秒くらいしか鳴ってない音も1トラックと数えるので実際同時になっている音はそこまでおおくはありません。 パラmix ここからは複雑な話になってしまうためしばらく駆け足になります。 編曲までできたらパラmixという作業に入ります。パラmixとは編曲で重ねた音をより聴きやすく、狙ったサウンド感に近づける作業になります。今回はバンドっぽいサウンドに複雑な音や花火の音等重めのサウンドも多かったため苦戦しました。 ボーカルmix パラmixで出来上がった音源に収録したボーカルを馴染ませる作業です。どんなに歌が上手い人でもデジタルで配信する以上この作業はほぼ必須です。声をより良くリスナーに届けるために重要な工程です。 ここでも自分の耳が信じられなくなってきた時ChatGPTに聞いたりしてみました。完璧な返答ではないこともありますが、やっていることが正しいという根拠を提示してくれたり、別のアプローチを提案してきてくれます。実際に提案されたFXをボーカルに加えたりしています。 マスタリング 最終工程です。ボーカルmixで完成したものをYouTube等、再生される媒体に合わせて調整をしていきます。一般的にはあまり良くないかもしれないですが自分の楽曲に限り、「もう少しキラキラした質感が欲しい」「ちょっとだけ広がりが欲しい」という時、0.1db ~ 0.5dbくらいを目安に微調整することがあります。 それ以上の調整が必要な場合はパラmixから見直すようにしています。 楽曲制作の中でAIを活用した結果できたこと これまでの音楽経験に引っ張られないサウンドを提案してくれる（コードやmix）納期がある中、AIを活用したおかげでクオリティアップのための時間が作れる「ChatGPTに聞くために言語化しなければならない」ということがイメージの洗練に繋がる1人じゃない！感が少しある（作業中は孤独な戦いことも多いので…） 音楽生成AIはまだまだ風当たりが強いですが、AIの"相談役"という立ち位置は少しづつ浸透してきている印象です。クリエイターは必ず何かしらの壁にぶつかると思います。その時に自分と相談、誰かに相談の他に「AIに相談」を選択肢を持ってみてはいかがでしょうか？ 最後に 改めて「サマーリフレイン」の宣伝をさせてください。複雑な恋心の中にある真っ直ぐな想いを描いた曲です。学生だった頃を思い出してぜひ聴いてみてください！（自分にはこんな青春ありませんでしたけど！） https://www.youtube.com/watch?v=78rzyNnlU5Q

新卒採用サイトの制作の裏側を描きながら、プロジェクトをどう進めるか、人に頼ることや優先すべきことなど、実践的な学びを等身大にまとめています。 ただ「大変だった」だけではない挑戦の記録 新卒採用サイトは、単なる採用活動の一部ではありません。 GMOインターネット株式会社では、グループ再編とブランド統合に伴い、複数企業にまたがる採用サイトを一つにまとめるプロジェクトを進めました。  準備や調整、想定外の方針転換が重なり、決して平坦な道のりではありませんでした。 思うように進まないことも多い中で、ふと頭に浮かんでいたのが、GMOインターネットで大事にされているこの考え方です。  スピリットベンチャー宣言「可能性を信じよう」私たちには、自らが解決できる問題しか起こらない。今まで、私たちのところには100兆円の問題は起こったことが無い。私たちのところに起こる問題は、すべて「ちょっと努力が必要な」問題ばかりである。あなたに解決できない問題は、そもそもあなたには起こらない。スピリットベンチャー宣言全文：https://group.gmo/brand/sv/ 正直、作業の真っ只中では「本当に終わるんだろうか」と思うこともありました。それでも、少しずつでも進めていればいつか形になると信じていたのだと思います。 問題にどう立ち向かうか：私が意識していたこと  この記事では、新卒採用サイトの統合プロジェクトを進める中で直面した課題や迷いに、私がどんなふうに向き合ってきたかを振り返っています。  この姿勢や考え方は、今回のプロジェクトに限ったものではなく、これまでの仕事でも大切にしてきた“自分なりの問題解決スタイル”のようなものです。 経験を重ねる中で、「あ、こういう場面ではこう動くと前に進めるかも」と感じてきたパターンが、振り返ってみるとだんだん整理されてきました。  特に意識しているのは、次の5つです。  1.自分で解決する 例：作業時間をかける、情報収集をする、優先順位を見直す、スキルを上げる2.チーム・他者の力を借りる 例：人に相談してみる・作業を分担する・スキルが上の人にアドバイスをもらう3.マインドを変える 例：完璧主義を手放す、目的を見失わない、柔軟に切り替える4.仕組みを変える例：プロセスを改善する、ツール導入、フローを見直す5.お金・外部の力を使う 例：有料ツール・サービスを利用する、外注する、専門家の力を借りる このあと出てくる各エピソードの最後に「💡このとき私が選んだ解決方法」として、 どんな動き方が功を奏したのかを小さくまとめています。  もし似たような状況に出会ったとき、「こんなアプローチもあるのかも」と思ってもらえたら嬉しいです。  プロジェクトの全体像  プロジェクト期間  約5か月（要件整理〜公開準備まで）  主な工程  統合方針の策定 デザインとコンテンツ設計 撮影計画・ロケハン 開発・コーディング 最終確認と調整  参加メンバー  制作統括デザインカメラマン 開発エンジニア 広報・人事  全部まとめる？それとも分ける？情報設計の山場 最初に取りかかったのは、サイトの構造設計でした。 就活生がどのグループ会社から来たとしても、情報に迷わずたどり着けるように── それが一番大切にしたかったことです。  できれば「それぞれの会社らしさ」も伝えたい、という思いもありました。 でも、実際に仕上がった構成やデザインを見て感じたのは、 「らしさ」よりも「統一感」が強く出たな、ということでした。  もちろん、ブランドとしての一体感や信頼感は大切です。 けれど、各社のカラーや雰囲気を完全に表現するには、 一つにまとめるにはどうしても無理があったのかもしれない── そんなふうにも思いました。  そのジレンマを抱えつつも、私はとにかく手を動かして考えました。  学生が最初に見るページはどこか どの情報を先に提示すれば迷わないか 「分岐」の設計をどうすれば自然に見えるか  紙に図を描いて構造を整理したり、他社のサイトを比較したり、 何度も情報の並びを入れ替えながら、ようやく「これかも」という形が見えてきました。  💡 このとき私が選んだ解決方法 ：「自分で解決する」 特別なツールやスキルがあったわけではなく、ひたすら図に描いて、組み直して、直感とロジックの両方で納得できる構造を探し続けました。とても地味な作業でしたが、こういう「考え尽くす時間」こそが、設計に必要だったと感じています。  調整×調整×調整：14人撮影の裏側  撮影対象：14人。拠点：3ヶ所。スケジュール調整：無数。 このプロジェクトで、個人的に一番「詰まっていた」工程がここかもしれません。  当初は9名ほどを想定していた撮影対象が、最終的には14人へと増加。拠点も東京・宮崎・福岡の3ヶ所にまたがり、「誰を、どこで、どう撮るか」だけでなく、撮影そのものを進行させるタスクが山のように発生しました。 具体的には 3拠点のカメラマン確保撮影メンバーの選定と調整撮影場所のロケハンどんなシーンを撮るかの参考資料探し服装指定や小物などの準備物撮影者・メンバーの組み合わせ表の作成メインビジュアルでの構成パターン作成撮影日程の確定、会議室の確保広報への許可申請カメラマン向けの撮影指示書作成…など 複数拠点・複数人のスケジュール調整が必要で、 Slackでのやりとり、スケジュール調整、会議室確保、スプレッドシートでの情報管理── あちこちを行き来しながら、同時に進行中のデザイン作業や日常業務も抱えているという状態でした。  正直、「全部自分で把握しておきたい」「誰かに迷惑をかけたくない」という気持ちが強く、最初はすべて自分で進めていました。でも途中から、「これは限界だ」と判断。制作統括メンバーに調整業務の一部をお願いしたことで、視界が一気にクリアになりました。 任せられるところは任せる。自分が集中すべきタスクに時間を使う。そうすることで、撮影もデザインも、丁寧に向き合えるようになっていきました。 💡 このとき私が選んだ解決方法：「チーム・他者の力を借りる」「マインドを変える」 「全部自分でやらなきゃ」という気持ちが強かったのですが、それを手放して、頼れる人に任せる判断をしたことで、進行も精神的な余裕もずっと楽になりました。 一瞬の焦りと冷静な切り替え：会議室が“消えた”日のこと 東京での撮影は3日間にわたって行われ、拠点ごと・時間帯ごとに異なる撮影スケジュールが組まれていました。そのうちの1日、複数の重要な撮影が詰まったタイミングで、ちょっとしたハプニングが起きました。この日のスケジュールは、午前10時からフクラスでメインビジュアルの撮影、続けて11時からはフクラスの別フロアで別メンバーの撮影という流れ。事前に関係者との連携も済み、「あとは撮るだけ」の状態だったはずでした。 ところが朝9:40、最終チェックのために会議室の予約状況を確認しようとシステムを開くと── 「予約：なし」 一瞬、頭の中が真っ白に。3週間前に確かに押さえたはずの会議室が、なぜかキャンセル扱いになっていたのです。 幸い、すぐに制作ディレクションメンバーに連絡を取り、空いている会議室を探してもらったり、次の撮影の進行を柔軟に調整したりと、役割を分担。結果的に、約10分で代替会議室を確保でき、予定していた撮影をすべて完了することができました。 後で調べてみると、原因は「入室ボタンの押し忘れ」。GMOインターネットの一部会議室では、当日タブレットで“入室”操作をしないと、自動でキャンセルされる仕様になっており、それを完全に見落としていました。 焦ったのは事実ですが、助けてくれる人たちがいたこと、そして「完璧に進める」より「今できる最善を尽くす」に気持ちを切り替えられたことが、うまくいった理由だと思います。 💡 このとき私が選んだ解決方法：「チーム・他者の力を借りる」「優先順位を変える」突発的なトラブルに完璧を求めても仕方がないと割り切って、まずはリカバリーに集中。周囲の人にすぐに頼ることで、短時間で状況を立て直せました。 色味が違う写真たちを、“ひとつの絵”にするまで  撮影を終えたあと、次に立ちはだかったのが「写真の色味調整」でした。 撮影した14人はそれぞれ別の拠点・時間帯・場所での撮影。照明の色、自然光の入り方、壁の色、服のトーン──どれをとっても微妙に異なっていて、そのまま並べると“別の世界にいるような印象”になってしまいました。ここまで明確に色や光の違いが出た素材を扱うのは、私にとって初めてのことでした。これまでは、色味の多少の違いは「その場の雰囲気」として受け入れることが多く、“完璧に揃える”という意識で向き合ったことはありませんでした。でも今回は、「3人が並んだときに、1枚の絵として自然に見えること」が必要でした。 「どうやって合わせよう」と思いながらRAWデータを元にした調整を始めました。どこから手をつけていいか分からず、最初の30分はトーンカーブとにらめっこして「うーん…違う」の繰り返し。 そんな中で頼ったのは、自分よりも圧倒的に多くのビジュアル制作経験を持つ3人のメンバーでした。それぞれの方が、自分の目と感覚で判断してきたノウハウを惜しみなく教えてくれて、RAW現像での整え方や、肌のトーンの揃え方、レンズフィルターのかけ方、「ここを合わせれば印象が近づく」という基準も、丁寧に言語化してくれました。 途中で「もう色が違っててもそれぞれの個性ってことで…」と開き直りそうになったこともありましたが、「ここで手を抜いたら、並んだときに気持ちよく見えない」という想像が勝り、なんとかやり切りました。 💡 このとき私が選んだ解決方法：「チーム・他者の力を借りる」「自分で解決する」 自分だけでは進められなかったところを、経験豊富な3人のメンバーに「スキルが高い人に相談する」ことで、具体的な方向性が見えてきました。そのうえで、自分の手で何度も試しては修正を重ねながら、“色味を揃える”という未知の領域に一歩ずつ踏み込んでいけた感覚がありました。 やり切った、でも変わる。その瞬間をどう受け止めたか  すべての撮影が終わり、ページデザインもFIX。あとは細かなコーディングの調整を残すのみ──という段階になった頃、人事・広報からも「いい仕上がりだね」という声が届き始めていました。「ようやく、ここまで来た」とチーム全体でひと息ついたあの空気感は、今でも印象に残っています。 そして迎えた、経営レビュー。 「この構成、少しわかりにくいかもしれない」そのメッセージを見た瞬間、思わず固まりました。もう完成に近づいていると思っていたこのタイミングで、根本の方向性が見直されるかもしれない──その可能性に、少し動揺したのを覚えています。結果、サイトは「統合型」から「各社ごとの独立感を出す構成」へと方針が変わることに。ただし大きく作り直すというよりは、主に表現レベル（ボタン文言やラベル表記など）での微調整が中心でした。 その過程で、分かりにくかった部分を洗い出し、内定者や新卒メンバーにアンケートを取りながら表現を改善するというプロセスも加わりました。自分たちだけでは気づけなかった点も見えてきて、より“伝わるサイト”に近づけることができたと感じています。 たくさん準備してきたからこそ、内心では「ここまで整えたのに…」という想いもありましたが、“全部が無駄になった”わけではなく、むしろ軸は残しつつ、より現実に即した良いものに進化できたと感じています。 💡 このとき私が選んだ解決方法：「マインドを変える」 完成間近での大きな方向転換は、最初こそ心がついていきませんでしたが、「プロジェクトが失敗したわけじゃない」「目的に対して最善の判断がなされた」ということを自分の中で受け止め直すことで、次の一手に気持ちを向けることができました。 まとめ トラブルは想定していても起こる。冷静な切り替え力と代替案が命綱 「助けを求める力」もまた、プロジェクトを進める一つの技術 途中の方向転換は失敗ではない。最良のゴールを再定義するチャンス  これを読んでくれたあなたの現場でも、もし困難に出会ったら思い出してください。  「あなたに解決できない問題は、そもそもあなたには起こらない」  完成した新卒採用サイトはこちら👉 GMOインターネット株式会社 新卒採用サイト