はじめに こんにちは！新卒1年目のなべしまです。 現在、ジョブローテ期間中で、サービスシステムグループ 第二開発チームに所属しています。所属先では、ニフティポイントクラブの運用開発業務を日々行っています。 ニフティポイントクラブでは、開発言語としてRubyを利用しています。今回は、開発環境を構築する中でつまずいたことやそこから得た学びをまとめてみました。 この記事を通して、知識の整理や新たな学びのきっかけになれば嬉しいです。 筆者プロフィール 入社：2025年4月 入社前のスキル Ruby：名前を聞いたことはある程度、環境構築はしたことがない 現在の担当：サービスシステムグループ 第二開発チーム（ニフティポイントクラブ） RUBY_CONFIGURE_OPTS でのつまづき 今回、macOS でrbenv というツールを利用して、Ruby のインストールを行いました。このとき、SSLライブラリを指定してインストールを実行しました。 環境構築ログ $ brew install openssl@3 ... $ export RUBY_CONFIGURE_OPTS="--with-openssl-dir=$(brew --prefix openssl@3)" $ rbenv install 3.3.3 ==> Downloading ruby-3.3.3.tar.gz... -> curl -q -fL -o ruby-3.3.3.tar.gz https://cache.ruby-lang.org/pub/ruby/3.3/ruby-3.3.3.tar.gz % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 21.0M 100 21.0M 0 0 11.9M 0 0:00:01 0:00:01 --:--:-- 11.9M ==> Installing ruby-3.3.3... ruby-build: using libyaml from homebrew ruby-build: using gmp from homebrew -> ./configure "--prefix=$HOME/.rbenv/versions/3.3.3" --enable-shared --with-libyaml-dir=/opt/homebrew/opt/libyaml --with-gmp-dir=/opt/homebrew/opt/gmp --with-ext=openssl,psych,+ --with-openssl-dir=/opt/homebrew/opt/openssl@3 -> make -j 10 -> make install ==> Installed ruby-3.3.3 to /Users/{ユーザ名}/.rbenv/versions/3.3.3   ここで、こんなことを思っていました。 export コマンドを実行しているな… 確かこのコマンド、シェル起動時の設定ファイルで使っていた気がする！ RUBY_CONFIGURE_OPTS は .zshrc や .zsh_profile に記録されているのでは？ しかし、 .zshrc や .zsh_profile の中身を見ても RUBY_CONFIGURE_OPTS は記録されていませんでした。ここが今回の私の 勘違いしていた点 でした。 改めて環境構築のログを見てみると以下のコマンドが実行されています。 ./configure make make install よく調べてみると、これらはソースコードからソフトウェアをビルド・インストールするための標準的な手順のようです。 RUBY_CONFIGURE_OPTS は ビルドプロセス中に使われる環境変数 だったのです。 今回はこの気づきをきっかけに、 ソフトウェアがどのようにインストールされるのか その基本的な流れについて整理してみたいと思います。 ソフトウェアがインストールされるまで ソフトウェアがインストールされるまでの処理を、３つのコマンドとともに説明していきます。 configure ./configure は、ソフトウェアをビルドするための設計図を作成する処理です。 $ ./configure [オプション] ./configure では主に以下の処理が行われます。 使用されている環境（OSやライブラリ）を調査 その結果をもとに、環境に最適な設定ファイル（Makefile など）を自動で作成 環境構築ログの ./configure が実行された行を見てみると、 --with-openssl-dir=/opt/homebrew/opt/openssl@3 というオプションが含まれています。これは最初に設定した環境変数 RUBY_CONFIGURE_OPTS の内容が反映されていることを示しています。 今回の export コマンドは、このオプションを指定するために使用したコマンドであることがわかりました。 -> ./configure "--prefix=$HOME/.rbenv/versions/3.3.3" --enable-shared --with-libyaml-dir=/opt/homebrew/opt/libyaml --with-gmp-dir=/opt/homebrew/opt/gmp --with-ext=openssl,psych,+ --with-openssl-dir=/opt/homebrew/opt/openssl@3 make make は、作成された設計図を基に、ソフトウェアを組み立てる処理です。 $ make [オプション] [対象ファイル] make では、主に以下の処理が行われます。 configureで作成されたMakeFileに基づいてソースコードをコンパイル 実行ファイルを作成 環境構築ログでは、以下のように make が実行されていました。このコマンドでは対象ファイルが指定されていないため、デフォルトで Makefile を参照しています。そして、 -j オプションは複数の処理を並列で実行するためのものです。rbenvではシステムの CPU コア数を取得して、自動的に -j の値を調整しているようです。 -> make -j 10 make install make install は、組み立てられたソフトウェアを配置（インストール）する処理です。 $ make install make install では、主に以下の処理が行われます。 Makefile に定義された install というラベルから処理を実行 make によって作成された実行ファイルを指定されたディレクトリにコピー 環境構築ログでは、以下のように Ruby が /home/hogeta/.rbenv/versions/3.3.3 にインストールされていたことがわかります。このインストール先のパスは、 ./configure の実行時に指定したパスに基づいています。 -> make install ==> Installed ruby-3.3.3 to /Users/{ユーザ名}/.rbenv/versions/3.3.3 例えるならば… ソフトウェアをインストールの流れを、通販で例えてみると… ./configure は「通販の注文フォームに入力」 make は「注文を受けて、倉庫で商品を組立て」 make install 「商品を家に配送」 fig. ソフトウェアインストールと通販の対応関係 このように置き換えることで、ソースからのインストール手順がどのように役割分担されているかがイメージしやすくなったのではないでしょうか。 まとめ export RUBY_CONFIGURE_OPTS="--with-openssl-dir=$(brew --prefix openssl@3)" は、シェル起動時の設定ではなくrbenv install のための設定だった 今回のようなインストール時に標準と異なる設定を使用するケースでは、この一連の流れを知っておく必要がありそうです。 普段何気なく使用しているツールやコマンドでも、原理を知ることで対応できる問題が増えると感じました。 今回の経験を活かして、今後も実行されている処理を分析しながら業務に励んでいきたいと思います。 学生の皆様に向けて ニフティには、今回の環境構築をはじめ、些細な疑問でも気軽に議論ができ、丁寧にアドバイスをもらえる文化があります。 今回の件を通して、ニフティでは 日頃から活発なコミュニケーションが行われている ことを改めて実感しました。 私は会社で働くうえでコミュニケーションは欠かせない要素だと考えています。その点において、ニフティは非常に良い環境だと感じています。 そんなニフティで、一緒に楽しく働いてみませんか？皆様とご一緒できる日を、心から楽しみにしています！ 参考文献 https://www.postgresql.jp/docs/17/install-make.html#CONFIGURE https://github.com/rbenv/ruby-build/blob/master/bin/ruby-build https://www.ibm.com/docs/ja/aix/7.2.0?topic=m-make-command#make__row-d3e116694

オープンスペーステクノロジー(OST)を社内と社外でそれぞれ実践した二人の司会者による対談記事です。どちらも10人規模で行われたOSTですが、 テーマは違えどOST自体に対する成果や課題には興味深い違いがありました。 はじめに オープンスペーステクノロジー（Open Space Technology、以下OST）は、参加者が自由にテーマを出し合い、自発的に話し合う場を作る手法です。 「4つの原則」があります。 ここにやってきた人は、誰もが適任者である 何が起ころうと、それが起こるべき唯一のことである いつ始まろうと、始まった時が適切な時である いつ終わろうと、終わった時が終わりの時である 要するに、上下・役割関係なく誰でも参加していいし、OSTで話されることは全部学びとなる。また、いつ話し出してもいいし、いつ話を終えてもよいです、ってことです。めっちゃいいね、ってことで特に技術勉強会やテックカンファレンスの中でよく行われる場の作り方になります。 詳細は、 「オープンスペーステクノロジー（OST）」でググってみてください！ （他にも蜂とかキリンなど、4 つの役割なんてのもあります。） 今回は、社外コミュニティと社内チームでそれぞれOSTを実践した芦川（私）と西原さんに、その違いについて雑談したことがあったので、それをネタに対談風に記事にしました。 司会者プロフィール 芦川：InnerSource Commons Japan Meetupで「チームの壁、ぶっ壊そ！壁の乗り越え方、一緒に考えよう！」というテーマのOSTを主催。インナーソースの実践者コミュニティでのファシリテーターを務める。（InnerSource Commons Japanは、 InnerSource Commons の日本ローカルコミュニティです。OSSの開発の仕方・コミュニティの形成方法などいいところを社内に取り入れようぜ、というものです。） 西原：社内で「職場での悩み事」をテーマにしたOSTを実施。労働組合の執行委員長という立場から会社内のコミュニケーション活性化や関係性醸成に取り組む。 対談 ― それぞれのOSTのテーマと参加者層について教えてください 芦川：社外OSTでは「インナーソース 組織内の壁と感じていることはなにか？」という大テーマで開催しました。参加者は約10名で、インナーソースに関心がある、あるいは既に実践している方々が集まりました。業界も会社も違う方々が集まり、「上下関係の壁」「チーム間の利害関係」などについて議論しました。 資料は公開しておりこちらです。 西原：社内OSTでは「職場での悩み事」という大テーマで、運営サイドもあわせて10名ほどが参加しました。OSTそのものの馴染みが薄いと思っていたのでイベントタイトルを「ユニオンカフェ」とし、「抱えてるモヤモヤ、誰かと話し合ってみませんか？」という謳い文句で「OST」という単語はあまり出さずに募集をしました。テーマとしては「新規事業について」「今後のキャリアについて」「評価の上げ方」など、かなり具体的な職場の課題が挙がりました。全一般社員を対象にしたのですが、参加者の大半がエンジニア職でした。このあたりはイベント参加に対する部署ごとの文化の差もあったのかなと思います。 ― 参加者の積極性や議論の深さやオープンさに違いはありましたか？ 芦川：社外の場合、みなさん自発的に参加されているので、積極性が高かったですね。特に「インナーソースについて知見がある人・何らかの形で実践している人・悩みを抱えている人が集まった」ので、非常に濃い議論ができました。新しい参加者と運営の方の人数バランスも良かったと思います。会社名や具体的な事例を出しながらも、比較的オープンに話せる雰囲気がありました。異なる会社の方々だからこそ、「こうしたら解決した」「うちではこうしている」といった経験を率直に共有できたと思います。 西原：社内の場合は少し違いました。社内のセミナー用会議室を借りての開催でしたので「とりあえず来てみた」という声もあり、参加の動機が様々でした。セッションがスタートすると、どの卓も活発に議論がされていました。 芦川：印象に残ったセッションとかありました？ 西原：自分も参加したのですが、営業の方が出した「エンジニアにやりたいことを伝えるには」というテーマのセッションが印象的でした。エンジニアには「これをやりたいです」と伝えるより「これってどうやったら実現できますか？」って聞くほうが前のめりになりそうという話で盛り上がりました。ただ、ここで１つ気づきがありまして、同じ社内でバックグラウンドが共通しているほうが議論しやすいだろうと思っていたのですが、むしろ社外の人同士のほうが後腐れがないため、深く話せるのではないかということにも気づきました。これは正直なところ盲点でした。 芦川：いや、そうかもしれませんね。社外OSTでは、もともとの人間関係が薄い分、悩みだけにフォーカスすることができて深く相談できる、なんてことはカウンセラーに相談する、とかそういったことに近いのかも。 西原：もう少し人数が集まるかなと思っていたんですが、参加者募集時に「職場での悩み」の例として挙げたものが「キャリアプラン」や「チームビジョン」などで、重たい印象を与えて参加のハードルをあげてしまっていた可能性もあります。もっとライトな例を多く用意してもよかったかもしれません。 ― 場の雰囲気づくりで工夫した点はありますか？ 芦川：社外OSTではWeWorkという場所を選び、ドリンク（ビールも！）を用意したのが好評でした！「ビール飲みながらは最高」「場所の静かさ・ゆるさ（空気感）など、非常に良かった」という声がありました。リラックスした雰囲気が対話を促進したと思います。 西原：芦川さんの社外OSTを参考に、こちらもアルコールを含めたドリンクと、あとはサンドイッチやおにぎりなどの議論の合間に片手で食べられる軽食を用意しました。食べることに集中してしまわないように箸やフォークが必要なオードブルなどは避けました。開始まではゆるめのBGMを流したりしたのですが参加人数が少ないこともあってか最初は少し重ための空気でした。 芦川：なるほどね、BGM。場作りはほんと大事ですよね。WeWorkはそもそも普通にコワーキングスペースとして働いている方がいる中だったので、カフェのような生活音があるような感じでした。そこもよかったのかもしれない。 西原：そうか、社内OSTであってもコミュニティスペースなどすこし広い場所でやってもよかったのかな。途中参加してもらえる人もいたかも。 ― セッションの進め方に違いはありましたか？ 芦川：社外OSTでは「1セッション35分（議論30分、発表5分）はちょうどよかった」という評価を得ました。また、2セッション目では「その場の流れで深追いしたいところについてテーマを新しく作成した」という柔軟な対応も行いました。ただ、司会者側がここ深堀りしたいと決めてしまったところがあり、これはよかったのか悪かったのか。 西原：社内OSTでもほぼ同様の時間配分でしたが、テーマが「昼食の場所や宴会のお店選び」から「キャリアプランの悩み」まで幅広く、時間配分の調整が難しい場面もありました。また今回一般参加者が少ないことから私含め運営側も全員セッションに入ってしまったことで、厳密なタイムキープが出来なかったのは反省です。 ― OST実践から得た最大の学びは何ですか？ 芦川：「InnerSourceという同じ軸でも、悩み方の軸に対する考え方は多様だ」という気づきが大きかったです。また、参加者からは「定期開催したい！」という声もあり、継続的なコミュニティ形成の場としての価値も感じました。 西原：「社内の知らない人に悩みを話すことのハードル」に対する認識を得たのと「部署によって文化に差がある」ことを再認識しました。他には「悩み」や「モヤモヤ」というマイナスのテーマで募るより、「いまの職場環境をよりよくする方法」のようなプラスのテーマで検討するべきだったかと思いました。ただ、参加者からは好評の声も多く聞こえたので次回につなげたいと思っています。 ― お２人お話ありがとうございました！では、社内・社外OSTのお話から、今後のOST開催に関する成功要因をまとめてみたいと思います。 これが OSTの成功要因！！ 意欲ある多様な参加者を集める 自発的に参加しようとする人が多いほど議論は活発になる。 異なる部署・会社・業界の人が集まると、率直な意見交換や具体的な経験共有がしやすい。 新規参加者と運営メンバーの人数バランスがよいと安心感が生まれる。 適切なテーマ設定 社外OSTでは「組織の壁」という抽象度のあるテーマで広がりのある議論が可能になった。 社内OSTでは「職場の悩み」をテーマにしたが、例示された議題の重さと社内の人に話すことに対する心理的ハードルなどもあり参加者が増えにくかった。 ライトなテーマや具体例を混ぜることで、参加のハードルを下げられる。 安心感ある場づくり 社外OSTでは人間関係が希薄なため、むしろ率直に悩みを深く話しやすかった。 社内OSTでは関係性が近い分、テーマによっては話しにくさが出る場合がある。ここはテーマ選びをちゃんと考える必要がある点。 WeWorkといった快適な場所選びやドリンク（ビール含む）の用意が好評。 静かでゆるい空気感が対話を促進し、意見交換を自然に進めやすくした。生活音があるような空間がよいのかも。 クローズドな場よりもオープンな場がよさそうだ。 まとめ 社外と社内、どちらが良いということはありませんが、OSTは場のデザインによって大きく成果が変わることが今回2つのOSTの結果を比較することでわかりました。 みなさんもOSTを実践する際には、「参加者」「テーマ」「場」の特性を考慮したデザインを心がけてみてください！！ OSTめっちゃいいですよ！！

はじめに こんにちは。ニフティの仲上です。 今回は、Terraformを使用してECSクラスターで「Container Insights」を有効にする方法を説明します。 Container Insightsとは 「Container Insights」は、Amazon EKSやAmazon ECSで動作するコンテナ化されたアプリケーションやマイクロサービスの監視・分析を行うAWSサービスです。コンテナの健全性やパフォーマンスを包括的に把握できます。 実は「Container Insights」には「オブザーバビリティが強化された Container Insights」という、もう1つの設定があります。 「オブザーバビリティが強化された Container Insights」は、「Container Insights」の進化版で、従来の監視機能を大幅に拡張したサービスです。 従来の「Container Insights」は、CPU使用率やメモリ使用量などのインフラレベルの監視が中心でしたが、「オブザーバビリティが強化された Container Insights」では、APIのレスポンス時間やエラー率など、アプリケーションレベルの詳細な追跡が可能となっています。 「オブザーバビリティが強化された Container Insights」を使用することで、障害の根本原因をより迅速に特定できるようになります。 Terraform で Container Insights を有効にする方法 クラスターの設定に以下の項目を入れると「Container Insights」が有効になります。 resource "aws_ecs_cluster" "blacklist_db_update_batch" { name = "test-cluster" setting { name = "containerInsights" value = "enabled" } } 先ほど紹介した「オブザーバビリティが強化された Container Insights」を使う方法を調べてみました。 どうやら enhanced という設定があるようです。 resource "aws_ecs_cluster" "blacklist_db_update_batch" { name = "test-cluster" setting { name = "containerInsights" value = "enhanced" } } 設定できました！ おわりに 今回は、Terraformを使用してECSクラスターで「Container Insights」を有効にする方法を説明しました。 簡単に設定できるので、ぜひ「オブザーバビリティが強化された Container Insights」の設定を検討してみてください。

はじめに 皆さんこんにちは！ 新卒一年目の宮村です！ 現在の業務では、主にOpenID Connect(OIDC)を使用した基幹システムを運用しています。 そのため今回は、業務を通じて学んだOIDCの基礎について発信していきたいと思います。 この記事の前提 今回のハンズオンはWindowsのPowerShellを前提にしています。 おそらく、MacやLinuxでも動作すると考えておりますが、保証はできません。 以下の記事等を閲覧し、OIDCの概要がわかっている前提で説明します。 https://qiita.com/TakahikoKawasaki/items/498ca08bbfcc341691fe   ハンズオン準備 今回使用するソースコードのクローン まず、準備として今回使用するOIDCのサーバー django-oidc-provider をGit cloneし、exampleディレクトリに移動します。 $ git clone https://github.com/juanifioren/django-oidc-provider.git $ cd django-oidc-provider/example   このexampleディレクトリには、実際にdjango-oidc-providerを導入した際のOpenID Provider(OP)の実装例があります。 Dockerコンテナの作成 exampleが少し古くそのままでは動かなかった点と今回のハンズオンの都合上、DockerFileの内容を以下に変更してください。 ※あくまでテストであるため、スーパーユーザー情報をファイルに直書きしています。 FROM python:3.10 WORKDIR /app COPY . /app RUN pip install --upgrade pip RUN pip install --no-cache-dir -r requirements.txt RUN python manage.py migrate RUN python manage.py creatersakey # 環境変数でデフォルトのスーパーユーザー情報を設定 ENV DJANGO_SUPERUSER_USERNAME=admin ENV DJANGO_SUPERUSER_EMAIL=admin@example.com ENV DJANGO_SUPERUSER_PASSWORD=admin # スーパーユーザーを作成（既存の場合はスキップ） RUN python manage.py createsuperuser --noinput || echo "Superuser already exists" EXPOSE 8000 CMD ["python", "manage.py", "runserver", "0.0.0.0:8000"]   以下のコマンドで実際に起動してみましょう！ $ docker build -t django-oidc-provider . $ docker run -d -p 8000:8000 django-oidc-provider   http://localhost:8000 で以下の画像が確認出来たら成功です。 テストClientの追加 Create your clients をクリックしましょう。 ここでいうclientはOPを使用するクライアントのことを指し、Relying Party(RP)とも呼ばれます。 クリック後、ログイン画面が表示されるため、ID、パスワードどちらも admin を入力しましょう。 ログイン後は 左サイドバーのClientsの隣 にある +Add をクリックします。 その後、以下を入力します。（それ以外はそのままでOKです） Name: テスト Response types code id_token id_token token Redirect URIs: http://example.com Scopes: openid profile email address phone 入力例 この後、Saveをクリックし、生成したclientを確認すると以下のようにClient IDとClient Secretが自動生成されたことが確認できます（以下はあくまで例です）。 これらの情報は、リクエストを送信したclientが正規のclientであることをOPが確認するために使用します。 この後のハンズオンで使用するため、これらの情報をメモしておきましょう。 テストユーザの作成 左サイドバーのUsersの隣 にある +Add をクリックします。 すると、以下の画面に遷移するため、以下の情報を入力しSaveをクリックします Username: test_user01 password: test_user01 すると、以下の画面へ遷移するため First name: user01 Last name: test Email address: example@google.com と入力しSaveをクリックします。 これで、下準備は完了しました。 ハンズオン 実際に設定したOPに対してログインしてみましょう。 今回は、OIDCのシーケンスの中で最も一般的なAuthorization Code Flowで試してみます。 ログイン（Authorization Request） 初めにブラウザの シークレットブラウザモード を立ち上げ、以下のURLを張り付けてください。 http://localhost:8000/authorize/?client_id=【先ほど生成されたClient ID】&redirect_uri=http://example.com&response_type=code&state=123456&scope=openid+profile+email   このURLは、OPに対して認可コードの発行を要求するAuthorization Requestです。 ここでは、 /authorize エンドポイントを指定していますが、エンドポイントがどのURLに存在するかの情報は、 .well-known/openid-configuration を参照すれば知ることができます。 実際にブラウザでアクセスしてみると、今回使用する authorization_endpoint 等のURLが記載されているのが確認できます。これはOIDCのDiscovery（発見）機能と呼ばれます。 以下に主要なパラメータの詳細を一部抜粋して説明します。 client_id : client(RP)の識別子 redirect_uri : 認証終了後にリダイレクトされるURI。 response_type : 認証後にどの情報を返すか（Authorization Code Flowだと code を指定） scope : ClientがOPに要求したいユーザー情報の範囲（プロフィール、メールアドレスなど）を指定します。ここで要求したスコープに対応する情報が、後のUserInfoレスポンスで取得できます。 張り付けた後Enterを押すと、ログイン画面が表示されるため、先ほど作成したユーザでログインします。 以下の画面へ移動します。 この画面は、Clientに対して以下の情報を渡すことをユーザに対して許可を求めていることを意味します。 ここではAcceptをクリックします。 その後、example.comにリダイレクトします。 リダイレクトした際のURLパラメータに存在するcodeは認可コードのことを表し、トークンの発行に使用します。 この認可コードを使用して、実際にトークンを発行してみましょう。 以下のコマンドをPowerShellに張り付けましょう。 このコマンドはToken Requestを送信するものであり。OPに対してトークンの発行を申請します。 $ curl -s -X POST -H "Cache-Control: no-cache" -H "Content-Type: application/x-www-form-urlencoded" "http://localhost:8000/token/" -d "client_id=【先ほど生成されたClient ID】" -d "client_secret=【先ほど生成されたClient Secret】" -d "code=【発行された認可コード】" -d "state=123456" -d "redirect_uri=http://example.com" -d "grant_type=authorization_code"   すると、以下の例のようなレスポンスが返ってきます。 { "access_token": "df6e0afa50e14a879f151feda46295b7", "refresh_token": "d6649365913f4c56abefe3f2b8b8732d", "token_type": "bearer", "expires_in": 3600, "id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6Ijk1YjBmY2I5NDI4NTI1YjM0MGRlZWM4ZjJlNTFhYmNlIn0.eyJpc3MiOiJodHRwOi8vbG9jYWxob3N0OjgwMDAiLCJzdWIiOiIxIiwiYXVkIjoiOTI0NDIyIiwiZXhwIjoxNzU0OTgxMTkwLCJpYXQiOjE3NTQ5ODA1OTAsImF1dGhfdGltZSI6MTc1NDk3NjE0MiwiYXRfaGFzaCI6ImlkRHRjVjdvYzl4Ny1yTFNoSTg5bHcifQ.fzlqjsHJycYrSx2EsGjsGsgLZC3z4mRVpKPATG0D_mU6bDD7ZLv4G3Sk5kXmibBekaLR5zBIUr84ZmQ77qo3CdARxLOn7rB4CLE3-9d-JEoQpwI9uHac3iQXdx6HVN2zBQJjm6CPkx8t0Z9-d1ErRzJiAeiJChPq4JbxsmtFJzgFwssdKeUdMwgsjR64wIY8uP9KV9NFG3X0vKfnAVSPdsp9QpfV68xkqwmhnotKHShSbDYsNPOAIGvryCxyb74h87BEVxk8OHmg79SsyXkf2eBpaA9ykg43EK-tMh2MZg3dfLqoFb0ZbUYgojJACMBsXAo9_WdF5MeEUczMsSs8HQ" }   主要な部分を抜粋すると、 Access Token : ユーザ情報を取得するために使用されるトークンです。 Refresh Token : ID TokenとAccess Tokenを再生成する際に使用されるトークンです。 IDトークン は: OPが正規なものであることと、ユーザーが認証されていることを証明するトークンです。 IDトークン検証 この後、ID Tokenの中身を検証し、OPが正規なものであるか確認します。今回は手動でIDトークンを検証しましょう。 以下のWebサイト(jwt.io)にID Tokenを張り付けてみましょう。 https://www.jwt.io/ja 張り付けた後、以下の画面が右側表示されるはずです。 主要な部分を以下に抜粋します。 ヘッダー部分 alg : 署名アルゴリズム kid : 署名の検証に使用する鍵のid ペイロード部分 iss : ID Tokenの発行元でURLが表示されます。 sub : ユーザの識別子（ID）を示します。 aud : ID Tokenを使用するClientを示します。 exp : ID Tokenの有効期限（Unix time） at_hash : アクセストークンをハッシュ化したもの。アクセストークンが正しいものかどうかを検証するために使用 これらの値を実際のものと見比べると正しいものであることを確認できるはずです。   また、IDトークンは . で区切られた3つの部分（ヘッダー・ペイロード・署名）から構成されており、最後の部分が署名です。 http://localhost:8000/jwks にアクセスすると署名の検証に使用する公開鍵の情報があります。 IDトークンの署名は、ヘッダーとペイロードを . で連結したものから計算したハッシュ値を、OPが持つ秘密鍵で暗号化したものです。RP側では、OPの公開鍵を使ってこの署名を 検証 します。これにより、トークンが改ざんされておらず、確かにそのOPから発行されたものであることを確認できます。詳しい検証プロセスは複雑なため省略します。 ※余談ですが、jwt.ioの仕様上ID Tokenから署名の検証に必要な公開鍵を、左下に自動で割り出してくれます。実際に、 http://localhost:8000/jwks の情報と比較してみると一致するはずです。 UserInfo Request IDトークンの検証が終了した後、実際にユーザ情報を取得します。 以下のコマンドをPowerShellで叩いてください。 $ curl -s -X GET -H "Authorization: Bearer 【発行されたアクセストークン】" "http://localhost:8000/userinfo/"   すると、Authorization RequestのScopeで指定した、profile, emailの情報が取得できます。 { "sub": "2", "given_name": "user01", "family_name": "test", "nickname": "test_user01", "email": "example@google.com" }   最後に OIDCはだいたい、このような流れとなっています。 今回は一連の流れを手作業で行いましたが、実際使用する際は、OIDCのClient用ライブラリを使用するため、OPのアドレス（issパラメータ）やClient ID, Client Secretさえ指定してしまえば、あとはほぼすべて自動でやってくれます。

概要 こんにちは。ニフティの山田です。 2025/07/17に、ECS組み込みBlue/Greenデプロイがリリースされました。 https://aws.amazon.com/jp/blogs/news/accelerate-safe-software-releases-with-new-built-in-blue-green-deployments-in-amazon-ecs/ 従来、ECSの組み込みデプロイ機能はローリングアップデートにしか対応しておらず、Blue/Greenデプロイを行うためにはCodeDeployを使用する必要がありました。 今回の変更によりECSだけでBlue/Greenデプロイが可能になったほか、CodeDeployによる制約がなくなりました。 これらの変更点について解説していきます。 ALB + ECS構成の場合に従来と比べてどうなるかを解説します CodeDeploy Blue/Greenデプロイと比べて変わること 単にCodeDepoloyが要らなくなる、という点以外にも仕様の違いはいくつかあります。 切り替え方法 (上記はテストリスナー(ルール)有効時のパターンですが、無効時はテストトラフィックのシフトはスキップされます) 基本的な動作原理はCodeDeployのものと同じですが、以下の点で異なります。 本番・テストトラフィックの管理がリスナー単位からリスナールール単位に変わった CodeDeploy Blue/Greenでテスト用アクセスを行うにはポートを変えるしかなかった ルールに変わったことにより、ヘッダなどの条件でも切り替えられるようになった 常にBlue/Green両方のターゲットグループへの参照を保持するようになった CodeDeploy Blue/Greenでは使わない方のターゲットグループへの参照は外れていた ECS Blue/Greenでは重み付きで両方保持するようになった ライフサイクルフック CodeDeploy同様に、決められたタイミングにライフサイクルフックが設定されており、Lambdaを呼び出して処理を実行、必要に応じてデプロイを停止させることができます。 フックの種類 名前は異なっていますが、同等+αのフックが用意されています。 CodeDeploy Blue/Green BeforeInstall / AfterInstall AfterAllowTestTraffic BeforeAllowTraffic / AfterAllowTraffic ECS Blue/Green PRE_SCALE_UP / POST_SCALE_UP TEST_TRAFFIC_SHIFT / POST_TEST_TRAFFIC_SHIFT PRODUCTION_TRAFFIC_SHIFT / POST_PRODUCTION_TRAFFIC_SHIFT REONCILE_SERVICE フック戻り値の種類 フックで呼び出されたLambdaが返すことのできる値として、 IN_PROGRESS が追加になっています。 SUCCEEDED 成功(デプロイ続行) FAILED 失敗(デプロイを停止してロールバック) IN_PROGRESS 実行中 IN_PROGRESSを返した場合、30秒後にまたLambdaが呼び出されます。 別途ロングランの確認(ex. E2Eテスト)を呼び出し、その終了を待つ、といった場合に使用できます。 CodeDeployの制約からの開放 CodeDeployを使用する場合、ECSのDeploymentControllerとして CODE_DEPLOY を指定する必要があります。このモードではECS serviceの保つ機能が制限されるという問題がありました。 ex) networkConfigurationなど、一部のECS serviceの設定を直接更新できなくなり、CodeDeployでのデプロイで更新する必要がある このせいでデプロイ側でサービス定義を管理する必要があった ECSが持つサーキットブレーカーの機能は使えず、CodeDeploy側の機能で代替する必要がある ECS Service Connectが使えない ECS Blue/Greenでは ECS の指定になるため、この制約がなくなります。 以上、基本的にはECS Blue/Greenの方が使い勝手が良くなっています。 AWS公式としてもECS Blue/Greenを推奨しており、AWSコンソール上では既にECSサービスの新規構築時にCodeDeployが選択できなくなっているため、今後の構築にはECS Blue/Greenを使いたいところです。 (後述の注意点を要確認)  Terraformでの設定 ECS Blue/Green対応は AWS Provider v6.4.0から入っていますが、不具合があるためv6.6.0以降を使ってください https://github.com/hashicorp/terraform-provider-aws/issues/43552 考慮事項 ECS Blue/Greenではリスナールール単位でトラフィックを管理するようになったのだが、これによりTerraformでは設定できないパターンが発生してしまっている問題があります。 リスナーにルールが1つしかない場合、以下のように設定してきたかと思います。 resource "aws_lb_listener" "listener" { ... default_action { type = "forward" target_group { ... } } } ここで default_action でデフォルトリスナールールのアクションを定義しますが、このルールのARNは Terraformで取得することができません 。ECS Blue/Greenの設定時にARNが必要になるため、この設定は行えないことになります。 なので、default_actionはダミーの設定として実質使用せず、別途リスナールールを定義する必要があります。 なお、以下のようにdataで取得できないかも検証しましたが、priorityの値にdefaultを受け付けず失敗しました。 ata "aws_lb_listener_rule" "default" { listener_arn = aws_lb_listener.listener.arn priority = "default" } 設定 ALB resource "aws_lb_listener" "listener" { ... # 基本的にこのルールには来ない想定 default_action { type = "fixed-response" fixed_response { content_type = "text/plain" message_body = "Not Found" status_code = "404" } } } # ARNを取得できるように、別途リスナールールを用意 # テスト用ルールを用意する場合は、別途もう1つ作る resource "aws_lb_listener_rule" "prd" { listener_arn = aws_lb_listener.listener.arn priority = 100 action { type = "forward" # CodeDeployと異なり、2つのTGを両方登録してweightで制御する forward { target_group { arn = aws_lb_target_group.blue.arn weight = 100 } target_group { arn = aws_lb_target_group.green.arn weight = 0 } } } # default_action代わりに使う場合は、必ずヒットする条件にしておく # 他のルールがある場合はpriorityとあわせて要調整 condition { path_pattern { values = ["*"] } } } 上記考慮事項を踏まえ、 default_action をダミーにして別途リスナールールを用意 CodeDeployと異なり、ターゲットグループを2つとも登録しておく必要あり ターゲットグループ自体の設定は従来と変わらないので割愛 ECS resource "aws_ecs_service" "service" { ... deployment_controller { type = "ECS" } deployment_configuration { strategy = "BLUE_GREEN" bake_time_in_minutes = 1 # 切り替え後にGreen環境を残しておく時間(分)、要調整 } deployment_circuit_breaker { enable = true rollback = true } network_configuration { # ここは変わらず } load_balancer { target_group_arn = aws_lb_target_group.blue.arn container_name = "app" container_port = 8080 advanced_configuration { alternate_target_group_arn = aws_lb_target_group.green.arn production_listener_rule = aws_lb_listener_rule.prd.arn # テスト用リスナールールを用意する場合 # test_listener_rule = "<テスト用リスナールールARN>" role_arn = "<Blue/Green切り替え用のARN>" } } lifecycle { ignore_changes = [ task_definition, desired_count ] } depends_on = [ "<ALB>" ] } 従来との主な違い  deployment_controllerを type = ECS に設定したうえで、deployment_configurationで strategy = BLUE_GREEN を設定することでECS Blue/Greenの設定になる load_balancerの設定に advanced_configuration が増える alternate_target_group_arn: Green側のターゲットグループARN production_listener_rule: 本番用リスナールールARN test_listner_rule: テストリスナールールARN role_arn: Blue/Green切り替えに使われるRoleのARN(別途作成が必要) 必要なポリシー Assume Role Policy { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowAccessToECSForInfrastructureManagement", "Effect": "Allow", "Principal": { "Service": "ecs.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } Policy AmazonECSInfrastructureRolePolicyForLoadBalancers 中身 { "Version": "2012-10-17", "Statement": [ { "Sid": "ELBReadOperations", "Effect": "Allow", "Action": [ "elasticloadbalancing:DescribeListeners", "elasticloadbalancing:DescribeRules", "elasticloadbalancing:DescribeTargetGroups", "elasticloadbalancing:DescribeTargetHealth" ], "Resource": "*" }, { "Sid": "TargetGroupOperations", "Effect": "Allow", "Action": [ "elasticloadbalancing:RegisterTargets", "elasticloadbalancing:DeregisterTargets" ], "Resource": "arn:aws:elasticloadbalancing:*:*:targetgroup/*/*" }, { "Sid": "ALBModifyListeners", "Effect": "Allow", "Action": "elasticloadbalancing:ModifyListener", "Resource": [ "arn:aws:elasticloadbalancing:*:*:listener/app/*/*/*" ] }, { "Sid": "NLBModifyListeners", "Effect": "Allow", "Action": "elasticloadbalancing:ModifyListener", "Resource": [ "arn:aws:elasticloadbalancing:*:*:listener/net/*/*/*" ] }, { "Sid": "ALBModifyRules", "Effect": "Allow", "Action": "elasticloadbalancing:ModifyRule", "Resource": [ "arn:aws:elasticloadbalancing:*:*:listener-rule/app/*/*/*/*" ] } ] }   参考: Amazon ECS infrastructure IAM role for load balancers (EFSをつけたり、Service Connectをつけたりしている場合は追加のポリシーが必要なので注意) 従来はecs_serviceのほとんどの項目を ignore_changes で無視する必要があったが、その必要はなくなる デプロイで変わるtask_definition、オートスケールで変わるdesired_countだけignoreすればよい serviceはすべてTerraformで管理する形にできそう もちろん従来同様の管理方法にしてもよい その他 デプロイ時のRole(or User)に以下のポリシーが必要 { "Version": "2012-10-17", "Statement": [ { "Action": "iam:PassRole", "Effect": "Allow", "Resource": ["{上記role_arnに指定したarn}"], "Condition": { "StringEquals": {"iam:PassedToService": "ecs.amazonaws.com"} } } ] } CodeDeploy Blue/Greenからの切り替え 公式に移行方法が解説されています。 が、稼働中のシステムを移行させるのは正直困難だと思った方が良いです。 前述のように構成が一部変わっており、デプロイ前に変更しなければならない 切り戻しができない deploymentControllerをCODE_DEPLOY → ECSにはできるが、逆は不可能 切り戻せないのが致命的なのでインプレースでのアップデートは避けたほうが良く、やるならALB+ECSのセットをもう1つ作って切り替えるのがよいでしょう。 注意事項 リスナールールのforward以外のアクションが消滅する 2025/08/01時点で本事象について暫定対応され、forward以外のアクションが設定されていると デプロイが失敗する ようになりました Blue/Greenデプロイ対象となるリスナールールには通常、forwardアクション1つだけがついている状態になっているはずです。 一方、 authenticate-oidc のように認証を付けた場合、アクションは2つになります。 ex) Terraformでの例 resource "aws_lb_listener_rule" "prd" { ... action { type = "authenticate-oidc" ... } action { type = "forward" ... } } この状態でBlue/Greenデプロイを行うと、 forward以外のactionが消滅します 。上記ではauthenticate-oidcのアクションが消えてしまいます。 CodeDeploy Blue/Greenでは保持してくれるので、ECS Blue/Greenのみで発生する事象です。 Canaryリリースが未実装 CodeDeployと異なり、リリース戦略を選択するパラメータが存在せず、Canaryリリースができません。 そのうち実装されそうではありますが、現段階では一括リリースしかできません。 ecspressoの取り扱い デプロイにecspressoを使用している場合のみ影響します。 ECS Blue/Greenに移行することにより、サービス定義を全てTerraformで管理できるようになり、デプロイでの書き換えが不要になりました。つまり、タスク定義のみのデプロイでよくなったということになります。 一方でecspressoはサービス定義・タスク定義をセットで管理することを前提としており、この恩恵を受けることができません。一応タスク定義のみでの実行は可能だが想定した使い方ではなく、サポート外と明言されています。 https://github.com/kayac/ecspresso/issues/871 このため、 サービス定義をデプロイ側で管理する(Terraform側で変更しない)運用を継続する ecspressoでのデプロイをやめる サポート外と知りつつ(自己責任で)使う の3択を迫られることとなります。 おわりに 今回は、2025/07/17にリリースされた、ECS組み込みBlue/Greenデプロイについて解説しました。 参考になれば幸いです。

この記事は、リレーブログ企画「25新卒リレーブログ」の記事です。 はじめに こんにちは。新卒1年目の大村です。 先日、初めてfirewalldというツールに触れました。 これを一般的なACLと同じように送信元アドレス(sources)について設定したら、意図しないパケットが通過してしまい設定に悩まされました。 今回なぜこのような挙動になったのか、想定通り動作させるにはどのような設定にすれば良いかについて、この経験を踏まえたうえで、firewalldに始めて触れる人に向けてまとめたいと思います。 筆者プロフィール 入社時期: 2025年4月 入社前のスキル: ネットワーク, Linux 現在の担当: ISPオペレーション・OAチーム 今回どのような設定を投入していたのか あるインタフェース(仮: eth1)において、IPアドレス(仮: 192.0.2.1)からのみサービス(仮: 22/tcp)を許可するルールを追加することになりました。 このとき、私は以下のような設定に変更しました。 意図としては”eth1に到達したパケットについて、送信元IPアドレスが192.0.2.1、宛先ポートが22/tcpなら許可”といった具合です。 しかし、実際の挙動としては、 192.0.2.1以外のホストもアクセス可能 となりました。 firewalld基本とACLとの違い なぜこのような挙動になったのかの前に、まずfirewalldがどのよう動作するかを紹介しようと思います。 まず、firewalldは、多くの人が触れてきたであろう”プロトコル、IPアドレスとポート番号の送信元や宛先、許可/拒否のみでルールを記述するACL”とレイヤが異なるものです。 ACLイメージ図 firewalldは独自の概念に基づいて設定し、上記のようなルールを生成するものであるという認識が重要になります。 一般的なACLは、インタフェースが中心であり、インタフェースごとにルールを追加していくかと思います。 一方、firewalldは、” ゾーン “というものが中核となっており、このゾーンにインタフェースや送信元IPアドレスを追加していきます。 このゾーンとは、そのインタフェースや送信元IPアドレスがどの程度信頼できるか、どのようなルールでパケットを通過させるかのプロファイルのようなものです。 firewalldにデフォルトで存在するゾーンの種類 1 パケットが到達すると、送信元IPアドレス、次にインタフェースの順で先にマッチしたゾーンに割り振られます 2 。 最初に送信元IPアドレスがマッチするか判定する 1でマッチしなければ、次に受信したインタフェースで判定 またゾーンには、通過が可能なポート番号やプロトコル、後述するリッチルールを割り当てられます。 最初の設定の問題点 ACLでは送信元IPアドレスは許可(拒否)のルールの一部なため、同様だと認識していました。 しかし、firewalldにおいての送信元IPアドレスは、ゾーンの振り分けのためのルール 3 です。 今回のケースは、sourcesにマッチしなくても、interfacesにマッチしてしまい、publicゾーンで評価されるようになったため、アクセスが可能となった訳です。 では、意図した通りの動作をさせるにはどのようにするか。 私は次のようにリッチルールを使用して設定を変更しました。 リッチルールでは、ACLのルールと似たような設定方法で、送信元/宛先のIPアドレス、ポート番号、プロトコルの組み合わせで許可/拒否が可能です。 今回の要件では、”192.0.2.1からのSSH”を許可が要件なため、以下のようなリッチルールを追加しました。 これで意図したように192.0.2.1からのみSSHが通るようになりました。 firewalldで設定するには firewalldを上手く設定するには、まずfirewalldのアプローチを理解することが大切です。 インタフェースや送信元アドレスでゾーンに振り分け、そのゾーンでパケットを通過させるかを決定します。 この仕組みを理解したうえで、通過させたいルールを宛先ポート番号やリッチルールなどに落としこむことが鍵になるかと思います。 まとめ firewalldにおけるsourcesは、一般的なACLのような”許可/拒否するIPアドレス”の設定ではありませんでした。 sourcesはゾーンを選択するための設定項目です。 もし、ACLのような設定を追加するのであれば、リッチルールを使用することで可能となります。 【終わりに】 学生の皆様に向けて まだ入社して間もないですが、ニフティには、成長・挑戦を支えてくれる仕組みが整っていると感じています。 制度は こちら で紹介されているものや無料で使えるUdemyなど数多く揃っていますし、入社後の 研修 も魅力の一つです。 また、配属後も困っていることがあれば丁寧に指導頂け、挑戦したいことがあれば、それを受け入れる文化もあります。 そんなニフティでは、この制度・文化を活用して挑戦していける仲間を募集中です。 成長・挑戦を軸にしている人には、とても良い環境だと思います。 この記事をご覧になっているあなたが、一緒に働きたいと思って頂けますと幸いです。 次は、なべしまさんの記事です。 どんな記事か楽しみですね。 参考文献 各事前定義されたゾーンについて: https://docs.redhat.com/ja/documentation/red_hat_enterprise_linux/10/html/configuring_firew all s_and_packet_filters/using-and-configuring-firewalld#firewalld-zones ︎ Previous Behaviorのセクション: https://firewalld.org/2023/04/zone-priorities ︎ https://docs.redhat.com/ja/documentation/red_hat_enterprise_linux/10/html/configuring_firewalls_and_packet_filters/adding-a-source ︎

はじめに おはようございます。IWS です 最近、クラウドコスト把握のため、AWS Lambda を使って各アカウントの利用料を取得するというのをしていました。いくつかあるアカウントからデータを取得しようとしていたのですが、それぞれに AWS Lambda を作るというのはしたくなかったのでスイッチロールを使って他所のアカウントのデータを1箇所から取得できるようにしました。今回はそのことについて書いてみようかと思います。   スイッチロール？ 簡単に言うと IAM ロールを使って各アカウントの切り替えを簡単にできるようにするものです。 作成した IAM ロールの持っているポリシーの範囲内でスイッチ先のアカウントを操作できます。今回は スイッチ元のアカウント A にある AWS Lambda からスイッチ先の アカウント B で get_cost_and_usage を使ってコストを取得します。   やってみる まずはスイッチ先のアカウントで IAM ロールを作成します。 IAM ロールの作成の信頼されたエンティティで「AWS アカウント」を選択、下の選択では「別の AWS アカウント」でスイッチ元のアカウント ID を入力します。 これだけです。あとは通常のロール作成時と同じようにポリシーの設定などを行ってください。スイッチ先のアカウントの準備はこれだけです。 AWS Lambda 側準備 使用するのは boto3 の sts_client.assume_role です # スイッチ元のセッション base_session = boto3.Session(region_name="ap-northeast-1") sts_client = base_session.client("sts") # スイッチ先のセッション assumed_role = sts_client.assume_role( RoleArn="<作成した IAM ロールの ARN>", RoleSessionName="AssumeRoleSession", )   なんとこれだけです。レスポンスの Credentials の中にアクセスキーやシークレットキーといった情報が入っているのでこれを使って新しいセッションを発行するだけでスイッチロールができます。 credentials = assumed_role["Credentials"] assume_role_session = boto3.Session( aws_access_key_id=credentials["AccessKeyId"], aws_secret_access_key=credentials["SecretAccessKey"], aws_session_token=credentials["SessionToken"], ) # スイッチ先アカウントで ce が使える！ ce = assume_role_session.client("ce")   あとは client("ce") などを使ってポリシーの範囲内で操作ができます。 res = ce.get_cost_and_usage( TimePeriod={"Start": start, "End": end}, Granularity="MONTHLY", Metrics=["UnblendedCost"], ) total_amount = float(res["ResultsByTime"][0]["Total"]["UnblendedCost"]["Amount"]) # アカウント B の料金 : 300 USD   まとめ 別の AWS アカウントを操作できる「スイッチロール」をやってみました。今回はコストを取得してみただけですが、ポリシーを変えれば当然 Amazon ECS を操作したり Amazon Cloudwatch を操作したりもできるため、あるアカウントから別のアカウントに対して簡単に CLI が使えるということだけでも覚えておくといつか役に立つかもしれません。 みなさんもぜひ「スイッチロール」役立ててみてください！

こんにちは。NIFTY engineeringブログ運用チームです。 ブログ運用チームでは、ニフティのエンジニアについての情報を世の中に広めるための活動をしています。 その活動の一環として、リレーブログを実施しています。 昨年好評だった新卒リレーブログを今年も実施しています！！ 【リレーブログ企画】24新卒リレーブログをやります！ 本記事に、25新卒社員のブログ記事のリンクをまとめていきますので、ぜひチェックしてください。 25新卒リレーブログは以下のスケジュールで投稿予定です。お楽しみに！ 投稿予定 執筆者 記事タイトル 2025年7月28日 宮村さん 【イベント参加レポ】いままでAWSを触ってこなかった一年目が、AWS Summitに参加してきました 2025年7月29日 moriさん Rancher Desktopにディスクが異常消費される問題の対処法 2025年8月5日 大村さん (仮)Firewalldの引っかかったポイント 2025年8月13日 石田さん 未定 2025年8月19日 なべしまさん 未定 2025年8月22日 高垣さん gitコマンドを使わずにcommitする 2025年8月26日 パクさん 未定 2025年8月29日 やまだ25さん （仮）オンプレのファイルサーバをAzureファイル共有へリプレイス

はじめまして！ こんにちは！2025年度新卒エンジニアのパクです。 OJTとしてマイニフティチームに所属しています。 よろしくお願いします   AWS Summitって何？ AWS Summitは、 AWS(Amazon Web Service) の技術を中心に開催されるITイベントです。Amazonというと、「あの物流会社の…?」と思うかもしれませんが、その通りです！   そのアマゾンが運営するAWSは、簡単に言うと、 インターネットでコンピュータを借りるサービス です。 以前はWebサイトをサービスするには、24時間稼働できる高価なPCサーバーを購入し、自分で管理しなければなりませんでしたが、AWSを使えば、ネットで必要な分だけ柔軟にコンピュータを借りることができます。 そんなAWSに関連するすべてのことが集まり、年1回開催される日本最大のクラウドコンピューティングイベントがAWS Summitです！ 今年は6月25日と26日の2日間、幕張メッセで開催され、私は2日連続で参加しました。   参加申し込みからセッション予約まで AWS Summitに参加のためには、公式Webページから事前に申請する必要があります！ https://aws.amazon.com/jp/summits/japan (来年はリンクが変更される可能性があります) リンクをクリックすると、イベント全体の内容とともに、どんな技術講演(セッション)があるのかが確認できます。様々なセッションがありますが、各セッションには 「Level」 があります。AWSに慣れていない方は、AWS初心者向けのLevel 100～200のセッションを先に予約することをおすすめします。 人気なセッションはすぐに満席になってしまいますが、当日会場に空席があれば、自由に入場して聞くこともできるので、あまり心配する必要はありません。   私は聞きたかったセッションがほとんど満席で予約は出来なかったのですが、当日会場で全部参加できました。 何をもっていけばいいかな？ 必須 事前予約の後、マイページからアクセスできるQRコード 身分証 (名刺、免許証等) あるといいもの 水 バッグパック (ノベルティを沢山もらうなら) PC（ワークショップに参加するなら)   幕張メッセへGo！ 会場に入場するためには、事前登録の後に発行されるマイページの QRコード と 身分証 を用意します。 入口で確認後、入場証（チケット）を受け取ることができます。 午前9時から始まる「ウェルカムパフォーマンス」が気になったので、少し早めに到着しました。早い時間だからか、思ったより入場列は長くなかったです。   今年は先着4,000人にクッションとお弁当がもらえる特典がありました！クッションは基調講演を事前に予約していれば、その講演会場の席で受け取ることができ、お弁当は9時20分頃に配布が終了しました。 来年もお弁当がほしいなら、少し急いだ方がいいですね   さあ、お楽しみの時間です！ 会場に入ったら、いよいよ本格的にSummitを楽しむ時間です！初心者の視点で、2日間回りながら「これは楽しめる！」と思ったことを紹介します。 まずは基調講演を聴こう 数あるセッションの中で何を聞くべきか迷ったら、基調講演を聴きましょう。 AWS Summitの最も核となるセッションで、AWSの新しい技術と様々な企業の成功事例を紹介します。 基調講演を聞いて、「AWSが日本国内で貴重な価値を生み出しているんだ」「思った以上に巨大な技術なんだな」と気づき、AWSへの興味が湧きました。   企業ブースも一通り回ってみよう GitLab、IBM、IBM、Postman、AMDなどなど馴染みのある企業はもちろん、「こんなサービスもあるんだ！」と思う企業まで、様々な企業が出展しています。 各ブースでは、自社の技術やサービスをアピールするために独特なイベントを開催しており、それを見るだけでもとても興味深く、楽しい経験でした。 一部のブースでは、その場で気軽に聞ける ミニセッション を開催しているところもあるので、興味のあるテーマがあれば参加するのもいいでしょう。 そして、ブースを回っていると、両手一杯の 戦利品 を手に入れることができます。かわいいステッカーや便利グッズを申し訳ないくらいたくさんもらえますので、AWS Summitに参加するときは、ぜひバッグパックを持って行きましょう！   ゲームで学ぶ、AWS体験ラボ 「セッションが難しいです」と思う方には、ここもおすすめです！ AWS体験ラボはAWSに初めて触れる初心者の方もゼロから楽しく学習できる体験型ブースです。 Cloud Quest: ゲームでAWSのスキルを学んでいきます。 SIMULEARN : チャットでAIと話ししながら、ビジネス問題をAWSでどのように解決するかを学ぶシミュレーションです。 私はCloud Questを1時間ほど体験してみました。体験を始めると、実習用の仮AWSアカウントがすぐに作成され、必要なファイルもすべて用意されているので、本当に「学習」に集中できたのが良かったです。 「AWS何もわからない素人だけど…」という方はぜひ参加してみてください！   この他にも ハンズオン、ワークショップできる エキスポ や、AWSの技術を活用した様々なプロジェクトが展示されている 展示ブース もありました。 余裕があったら回るのも楽しみの一つです！   最後に 最初は、「AWSの知識がないと楽しめないのでは…」と心配していたのですが、AWS Summitは「専門家だけのイベント」ではなく、私のような新人エンジニアも一緒に楽しみながら学べる、とても有意義で楽しい時間でした。 ITを超え、アニメーション制作、物流の自動化、食品廃棄物の問題解決に至るまで使われるAWSの姿に、クラウドコンピューティングの無限の可能性を感じました。 今回の経験で、AWSは難しい技術とした偏見がなくなり、今後ニフティで新しい技術をもっと探求したいと思う貴重なきっかけを得ました。 この記事を読んでいる皆さんも、次のSummitでお会いできることを願っています  

CCoEや生産性向上に関する仕事をしている石川です。 今回は開発生産性向上を目指して、2025年3月から様々なAIエージェントを試してみた 個人的な 感想を書いていこうと思います。GitHub Copilot以外のツールは数日から1ヶ月使用しただけなので、深く使い込んだわけではありません。 GitHub Copilot Agent mode / Coding Agent 良い点 GitHub提供の安心感と将来性への期待 GitHubとの高い親和性 困る点 従量課金要素がある（Premium Request） 世間で流行している機能が実装されるまで時間差がある ChatGPTで簡単なコード生成を試した以外では、GitHub Copilotが私が本格的に使った最初のコーディングAIです。ニフティでは2023年9月から正式導入されています。 VSCodeと統合されているため使い方に迷うことがなく、初めてコーディングAIを使う方にも最適だと思います。GitHub.com上でレビューやスキャン結果を即Copilotで修正できるのも親切です。 約2年間使い続けていますが、その間に利用可能なモデルが増え、EditモードやAgentモードなども追加され生産性は大幅に向上しています。最近ではInstructionファイルを認識してくれるケースも増え、日々着実に便利になっています。 一方で、最新のトレンド機能がまだ取り込まれていないこともあります。ですが必要な機能は最終的にすべてCopilotに統合され、結局はCopilotに落ち着くのではないかと個人的には期待しています。 Cline / Roo Code Copilot Agent modeが一般公開されるまでの間に、ClineやRoo Codeなどのツールを試したことはありますが、十分な感想を書けるほど使い込んでいないため、ここでは割愛します。 Devin ※2025年3月時点におけるDevinの感想となります 良い点 早い段階から自立型AIエージェントとして完成度が高かった GitHubやSlackから簡単に利用できる Devin自体がブラウザやエディターを内蔵しており、独立した環境でタスクを実行できる 困る点 認証情報の管理が難しい BotとしてのDevinに強い権限が付与される SAML/SSOを利用するにはEnterpriseプランが必要 自立型AIエージェントを体験するのに最適なSaaSだと思います。 Devin上で様々な機能を試せますし、GitHubやSlackなど必要なIntegrationも揃っています。 限られた範囲で使う分には問題は少ないですが、全社展開を考えると、アカウント管理、認証情報管理、従量課金の予算管理などの課題が出てきます。これらに対応するには運用ルールをしっかり決めておく必要があります。Devinが予期せぬ動作をした場合、社内のAI普及にも悪影響を及ぼす可能性があるため、展開するとしてもチーム単位で段階的に進めるのが賢明です。 Jules 良い点 Google提供のコーディングエージェント 無料で使える（1日60タスク） 困る点 まだパブリックベータ段階で機能が限定的 GitHubリポジトリとの連携が必須 現時点ではエンジニア向けの無料AIコーディング体験SaaSという印象です。 純粋なコーディングエージェントなので、Devinのような汎用性はなく、GitHubとの連携が必要となります。Devinが自動的にプルリクエストまで作成するのに対し、Julesはブランチ作成までで止まるなど、提供会社ごとにAIエージェントの作業範囲も異なります。 Claude Code 良い点 内部プロンプトの優秀さを実感できる エディターやGUIに縛られずに利用できる 困る点 従量課金要素がある（API） CLIだと日本語入力がやや不便 使用前は世間のあまりの評判の高さに懐疑的でしたが、実際に使ってみると体験が非常に良かったです。 他のAIエージェントと同様に「計画立案 → タスク化 → 処理」という基本的な流れは共通していますが、進捗の伝え方、結果サマリーの適切さ、そして他の作業を邪魔せずに動作する点が優れています。内部で使われているであろうプロンプトが非常に優秀だということも伝わってきて、これらが総合的に良い体験を生み出しています。 CLIについては、エディターを占有しない＆複数のタスクを並列実行できる点で有利なインターフェースだったんだと再発見した気分です。 CLIでの日本語入力はやや不便ではありますが、長文のプロンプトが必要な場合はカスタムスラッシュコマンドを活用できますし、最悪コピペすればいいので慣れればそこまで困るものではありませんでした。 Kiro 良い点 Specモードによる要件定義から行う体験が優れている AWS提供のエディター 困る点 利用にはWaitlistの登録が必要 Kiroによるコーディング処理が非常に遅い セッション切れによるIAM Identity Centerログインし直しがちょっと面倒 Kiroはエディターの基本機能として、AIエージェントを効果的に活用するための一つの模範解答を提供しています。 Claude CodeのPlanモードやRoo CodeのArchitectモードなど類似機能はありましたが、「要件定義 → Design Doc → プラン作成」を対話形式で自動化してくれる体験はすばらしかったです。既存の重厚なプロンプトテンプレートを持っていない限り、SpecモードでAIとプランを立てる体験は、今後のAIエージェントとの効果的な関わり方を学ぶ良い機会になると思います。 Gemini Canvas コーディングやエージェント以外に、情報収集やスライド作成に関するツールも調査していたので、おまけとして紹介します。 良い点 Geminiの一機能として手軽に利用できる Deep Researchで調べた結果を即座にレポートや一枚絵（html）にまとめられる 困る点 Googleスライドに直接流用できない（キャプチャなら可能） スライドに適したフォーマットをプロンプトで指定するのが面倒 私は発表用のスライドをGeminiに与え、Canvasでhtmlページを作成し、それをキャプチャしてスライドに挿入する方法で活用していました。便利ではありますが、デザインの微調整が非常に難しいのが欠点です。 この問題を解決してくれるツールとして Manus があります。スライド機能やデータ可視化機能は非常に優秀ですが、気になる点もあるため現時点ではプライベートでの検証に留めています。 ほかにも ChatGPT Agentでもスライドが作成できるようになりました し（現状ではデザイン面が不十分）、数ヶ月後には他のツールも対応してくると思われる（願望）ので、このあたりはまだ様子見でも良いかもしれません。 まとめ GitHub CopilotやNotion AIを過去に導入した経緯もあり、流れで最近のAIエージェントも調査を進めてきましたが、種類の多さと進化の速さに追いつくだけでも疲弊しますね。 半年から1年ほど待って落ち着いてから導入を検討するのが最も効率的ではありますが、AI技術は実際に体験して初めて理解できる要素が多いと考えています。日々の情報収集と手を動かすことで得られる経験値が非常に重要だとも思います。 様々なツールを検証した結果、主な使い方と必要となる情報（InstructionやKnowledgeなどのカスタム要素）さえ集約できていれば、自分に合ったものを選んで使うのが現時点での最適解でしょう。さらに言えば、一つのツールに固執せず、様々なものを試す柔軟な姿勢も大切だと思います。 未来は常に変化していくため、どのツールをどの程度社内に展開するかの計画は立てにくいですが、実際に優れた体験価値を提供したツールについては積極的に社内展開を進めていきたいと考えています。

はじめに 皆さんこんにちは、宮村です。 今回は、2025年 6月25日と6月26日にAWS Summit Japan 2025に参加してきたため、アマゾン ウェブ サービス（AWS）をほぼ触っていない入社一年目のエンジニアの目線で感想を語っていきたいと思います。 AWS Summitとは 公式サイト での記載は以下の通りです。 AWS Summit は、共に未来を描くビルダーが一堂に会して、アマゾン ウェブ サービス (AWS) に関して学習し、ベストプラクティスの共有や情報交換ができる、クラウドでイノベーションを起こすことに興味がある全ての皆様のためのイベントです。 https://aws.amazon.com/jp/summits/japan/ 簡潔に言うと、Amazon Web Services, Inc.様をはじめとする多くの企業が一堂に会し、情報交換を行ったり、企業が抱える課題を解決するための製品やサービスを紹介したりする場、と言えるでしょう。 なぜ参加したのか 弊社では全社的にAWSが使用されているため、技術的知見を増やしたかった点と、一人のビジネスパーソンとして技術系イベント参加したかったためです。   会場の様子 会場は多くの来場者と出展企業で、大変な熱気に包まれていました。 Amazon Web Services, Inc.様やその他の様々な企業によるセッション会場のほか、ブースがたくさんありました。 この業界ではなじみの深いAMD様やGitLab様、いま注目を集めているAnthropic様など、多種多様な企業が集っていました。 ブースでは、様々な企業様から「自社の製品いかがですか？」とアピールしてきます。 事前に自社や担当プロダクトの課題を整理しておくと、『この製品はあの課題を解決できるかもしれない』といった発見があり、より有意義にブースを見て回れると感じました。 また、話を聞いていると、いろいろなノベルティやオリジナルステッカーなども配布されていました。 特に印象的だったのは、Red Hat様のブースで配布されていたred hat（トレードマークの赤い中折れ帽）です。   セッションの様子 両日とも、10時から11時半まで基調講演があり、その後各ブースで個別セッションが行われる形です。 来年参加される方へのアドバイスですが、基調講演を良い席で聞きたい場合、早めに会場へ到着することをおすすめします。今年の例では、開場後すぐに席が埋まり始め、早く来た人にはクッションや昼食券が配布されるなどの特典もありました。 様々なセッションを見ましたが、その中でも特に印象に残ったものをいくつかピックアップして紹介したいと思います。 Amazon Web Services, Inc.様による「生成 AI を活用したデータベースのスキーマ変換で移行を加速しよう : AWS Database Migration Service Schema Conversion」 生成AIを活用することにより、自社で保有しているサーバからAWSへのデータベース移行を大きな労力をかけずに実現できるとのことです。 これまでは、Oracle DatabaseなどからAWSのデータベースへ移行する際、関数やストアドプロシージャといった複雑なコードは自動変換が難しく、手作業での修正が多く発生していました。 セッションによると、従来は全体の8%程度しか自動変換できなかった処理が、生成AIを活用することで約85%まで自動化できるようになったとのことです。 これも、ただ、生成AIを活用すればいいだけでなく、コンテキストや難読化したコードの修正やLarge Language Model（LLM）の選定等、考慮事項が多いため、AIをどう活用していくかが重要となりそうだと感じました。 弊社でもこのようなAWSへの移行は課題となっているため、参考にしたいと思いました。 Amazon Web Services, Inc.様による「セキュアなソフトウェア開発ライフサイクルのための生成 AI」 本番環境へのデプロイ後等に、脆弱性が見つかることはたびたび発生するため、継続的なスキャンや、依存関係になっているシステム全体の把握が必要となります。 近年のサイバー攻撃の巧妙化を受け、ソフトウェアを構成するコンポーネント（部品）を一覧化した『ソフトウェア部品表（SBOM）』の重要性が高まっています。しかし、開発の過程で常に最新の状態に保つのは容易ではありません。 この課題に対し、AWSの脆弱性管理サービスである『Amazon Inspector』は、スキャンしたリソースからSBOMを自動で継続的に生成・管理してくれるとのことです。 弊社でも、SBOMに関する話が出始めており、この分野に関する知見をより広げていこうと感じました。 株式会社ドワンゴ様による基調講演および、個別セッション「ニコニコの大規模セキュリティ改革」 ネット文化を代表するサービスの一つともいえる『ニコニコ』を運営する株式会社ドワンゴ様は2024年6月に大規模なサイバー攻撃を受けました。 対応の際には、Amazon Web Services, Inc.様の社員の方々も含めてセキュリティチームを構成したそうです。 発表によると、攻撃を受けた際、自社で運用していたオンプレミス環境は大きな被害を受けましたが、以前から移行を進めていたAWS上の環境は被害を最小限に食い止められたとのことです。 この経験から、残っていたシステムのAWSへの移行計画を大幅に前倒しして、サービス復旧を進めたそうです。 AWSが提供する堅牢なセキュリティ基盤の有効性を、改めて認識させられる事例でした。 また、このような被害は他人ごとではないという言葉が、特に印象に残りました。 全体を通しての感想およびまとめ この二日間を通して、AWSに対する興味がより一層上がりました。 AWSにより、様々なソリューションを実現できることを知り、弊社でも活かしてみたいとも思いました。 私のようなAWS初心者でも、Simple Storage Service（Amazon S3）やAmazon EC2といった基本的なサービスの役割を把握していれば、各セッションの目的を理解できると感じました。 来年の開催までには、さらにAWSの知識や自社の課題への理解を深め、より多くの学びを得られるよう再挑戦したいです。

はじめに はじめまして。ニフティ株式会社の森です。 筆者プロフィール 入社時期: 2025年 4月 新卒入社 入社前スキル: 言語: C, Python, JavaScript 他: Docker, Linux, Flutter, AWSは未経験 現在の担当: 課金システムチーム 現在弊社では、Docker Desktopの代替としてRancher Desktopを使用しています。 そのRancher Desktopにディスクを異常に消費されたので、原因と対処法について記しておきます。 Rancher Desktopの利用も広まっていますので、同問題に直面する人の助けになれば幸いです。 環境 OS: Windows 11 24H2 ハードウェア構成は関係ないと思いますので割愛します。 背景 Docker Composeを使用したローカル検証環境作成の過程で、コンテナを何度も作成、削除する作業を繰り返していたところ、マシンのディスク使用量が急激に増加するという問題が発生しました。 当初、イメージやコンテナに対してpruneコマンドを実行して一時的な対処をしていましたが、根本的な解決には至りませんでした。 結果として、使用しているマシンのディスクが埋め尽くされ、作業に支障が出る状況になりました。イメージやコンテナ、ボリュームを削除しても、ディスクの消費量は増え続けるようです。 肥大化した仮想ディスクファイル 原因 Rancher Desktopがデータを保存する仮想ディスクである C:\\Users\\{ユーザ名}\\AppData\\Local\\rancher-desktop\\distro-data\\ext4.vhdx のサイズが大きくなったまま縮まないことが原因です。 コンテナの作成→削除には以下のような処理が実行されていると考えられるのですが、中にあるデータが消去されたあとも、仮想ディスクが確保した領域が開放されず、サイズが大きくなり続けているようです[1,2]。 コンテナが作成される コンテナのデータを保存するために仮想ディスクファイルのサイズが大きくなる コンテナが削除される 仮想ディスク内のデータ”は”削除される 一度仮想ディスクが膨らんでしまうと、中身を消しても効果がありませんでした。 それに気づかないまま compose up , compose down を繰り返した結果が先程の画像です。 pruneコマンドを使用してリソースを削除しても仮想ディスクが縮まない様子 解決方法 調査した中で効果の確認できた解決方法は2つです。 diskpartを使用して仮想ディスクを縮小する Factory ResetをしてRancher Desktop環境を再構築する diskpartを使用した方法だと、若干手間がかかりますが必要なデータを残したまま仮想ディスクを縮小できます。Factory Resetですと作業は単純ですが全てのコンテナやイメージが消えるのでご注意ください。 diskpartを使用した仮想ディスクの縮小方法 事前に不要なコンテナ、イメージ、ボリューム等を削除して仮想ディスクの使用量を下げる PowerShellから wsl --shutdown を実行してWSLを終了させる diskpart もしくは diskpart.exe を実行 diskpartで select vdisk file=”C:\\Users\\{ユーザ名}\\AppData\\Local\\rancher-desktop\\distro-data\\ext4.vhdx” を実行、ユーザ名は自分のものに置き換えてください。 diskpartで compact vdisk を実行 この際「ディスクが使用されている」のようなエラーが出て失敗した場合WSLが終了していないです Factory Resetをする方法 こちらは仮想ディスクファイルを縮小させるというよりは、一旦全てを削除してしまう方法です。 私の場合は、イメージの数が多くなりすぎて必要、不要の判断ができない状況に陥ってましたので、こちらを実行しました。先ほども書きましたが、コンテナやイメージなど全てが消えますのでご注意ください。 手動で仮想ディスクファイルを削除した後、WSLインスタンスの削除、Rancher Desktopの再セットアップを行っても、同じ効果を得られますが、ひと手間かかります。 Troubleshootingを選択 Factory Resetを押す 警告が出るのでOKを選択 再びRancher Desktopを開くと、インストール時と同じようなウィンドウが出るのでそれぞれの環境にあったセットアップをしてください。 参考資料 https://github.com/rancher-sandbox/rancher-desktop/issues/2398 https://qiita.com/tamanegisoul/items/82b1fe8ed638c79cbe96 終わりに 今回はRancher Desktop使用時にディスクを異常消費される問題への対応策を調査、紹介しました。 同じ問題に遭遇した人の助けになれば幸いです。 この記事を読んだ学生さんに向けて この記事を書いた時点で入社して半年経たないですが、弊社では新人でも様々なことに挑戦できる環境だと感じています。 例えば私の場合は、既存プロジェクトの使用している言語、ライブラリの更新を提案したところ挑戦させてもらい、改修に参加しています。 このように、年次や経験にかかわらず、アイデアは積極的に取り入れ、挑戦の機会を与えてくれるのが弊社の文化です。もちろん、わからないことを聞けば経験豊富な先輩方がしっかり教えてくれるので、失敗を恐れず安心して新しいことに取り組める環境です。

こんにちは。ニフティ株式会社の仲上です。 今回は、先日開催された SRE NEXT 2025 での発表内容と補足情報についてご紹介します！ イベント概要 先日、SRE NEXT 2025 が開催されました。 https://sre-next.dev/2025/ 当社はゴールドスポンサーとして参加し、スポンサーブースの出展などを行いました。 当社が力を入れている分野については、技術広報もさることながらコミュニティとの繋がりも重視しているのでイベントの協賛を行っています。 SREもその分野の1つで、「SRE NEXT」のような大きなイベントには、2022年から毎年協賛しています。 ブースの詳細については担当者が別記事を作成していますので、こちらをご覧ください！ SRE NEXT 2025に参加してきました！ 登壇内容について 本イベントでは10分間の登壇枠をいただき、私のチームが実施した監視基盤リプレイスについて発表しました。 初めての外部イベント登壇だったため緊張しましたが、非常に貴重な経験となりました。 発表資料はSpeakerDeckに公開していますので、興味のある方はぜひご覧ください。 本日発表した、仲上の資料です。 モニタリング統一への道のり 〜分散モニタリングツール統合のためのオブザーバビリティプロジェクト〜 https://t.co/h4DrxdWz5V #srenext — NIFTY Developers (@NIFTYDevelopers) July 11, 2025 発表内容の補足 発表時間が限られていたため内容を圧縮せざるを得ず、いくつか説明が不足していた部分がありました。この場を借りて補足説明をさせていただきます。 Grafana/Prometheusのコスト評価について 発表時の比較表では、Grafana + Prometheus の構成をコスト面で「高い」と評価しました。 この評価は、純粋なインフラコストだけでなく、運用工数も含めた総合的なコスト計算に基づいています。 Grafana + Prometheus はオープンソースツールであり、サーバーにインストールするだけで利用できますが、実運用では設定や基盤の運用・メンテナンスに予想以上の工数がかかるため、総合的なコスト面で「△」評価としました。 今回は時間の制約から、すでに利用経験のあるOSS版のみを検証対象としましたが、クラウドサービス版では結果が異なる可能性もあります。 もし同様の比較検証をされている方がいらっしゃれば、ぜひ情報共有いただけると幸いです。 具体的なコスト試算結果 今回は以下の条件でコスト試算を実施しました。 監視対象: サーバー20台 ログイベント: 800万イベント/月 ログ保持期間: 30日間 ログデータ量: 1イベントあたり1KBと仮定し、月間 8GB のログデータ（800万イベント × 1KB/イベント ≈ 8GB） 為替レート: $1 = 158円 リージョン: AWSは東京、Azureは東日本リージョン、Datadogは日本 試算結果は以下の通りです。 サービス メトリクス ログ 合計（月額） Datadog ¥72,680 ¥2,150 ¥74,830 Amazon CloudWatch ¥6,600（詳細メトリクス有効時） ¥1,000 ¥7,600 Azure Monitor ¥0（メトリクスはログ料金に含む） ¥6,300 ¥6,300 Azure Monitor については、DCR（データ収集ルール）の設定により保存料金が変動しますが、おおよそAWSと同程度のコスト感になると予想されます。 クラウドネイティブな監視ツールはコスト面で明らかな優位性がありますが、機能性や使いやすさ、既存環境との親和性なども含めた総合的な判断が重要です。 Ask the speaker について Ask the speaker では、監視設定周りの管理が課題になっていたという話題で盛り上がりました。実際、監視周りはGUIでつけるとルールが煩雑になって管理が大変なのでコードで管理したほうが良いですが、コードで管理すると作成コストが重くのしかかってきます。 今回の発表で紹介したコードのエクスポート機能はコードの作成コストを大きく抑える事ができるので、みなさんもぜひ試してみてください！ また、オンプレミス環境や他クラウド環境への監視についても話題があがりました。現状はまだ監視できていませんが、環境のリプレイスが増えてきたら必要に応じて監視対象にする予定です！ まとめ SRE NEXT 2025での発表を通じて、監視基盤リプレイスに関する経験や知見を多くの方と共有できたことを嬉しく思います。 今後も監視基盤の改善を継続し、このブログ記事が皆さんの参考になれば幸いです。 最後に、SRE NEXTを開催してくださった運営・関係者の皆様・ブースに来ていただいた皆さん、発表まで支えてくれた仲間たち、その他関係していただいた方に心より感謝申し上げます。 ありがとうございました！

はじめに こんにちは！ニフティ株式会社の坂野です！ 弊社は 2025年7月11日（金）と12日（土）の二日間にわたって開催された「SRE NEXT 2025」にゴールドスポンサーとしてブースを出展しました。 今回は、SRE NEXT 2025で個人的に聴講したセッションの内容の紹介と当日のニフティブースの様子についてお伝えします。 聴講セッションレポート 当日は多くの興味深いセッションが開催されていましたが、本記事では特に学びが多かった2つのセッションについてご紹介します。 複雑なシステムにおけるUser Journey SLOの導入 株式会社メルカリの土屋様により、お客様目線のSLOである「User Journey SLO」の導入についてご紹介いただきました。 「User Journey SLO」とは、個々のサービスにフォーカスしがちな開発者目線のSLOとは異なり、お客様の体験に焦点を当てた、サービス横断のSLOを指します。 土屋さんによると、SREチームはサービス全体の品質向上を目指していますが、全てのマイクロサービスを監視するのは現実的ではありません。そのため、コアサービスが機能しなくなるほどの「クリティカルな障害」を検知することに注力しているとのことです。 セッションでは、この障害を検知するための具体的な実装例として、クリティカルなAPIの探索方法とその自動化、障害発生時におけるユーザーへの影響範囲の自動通知などが提示されました。多数のサービスを運用する当社にとっても、大変参考になる内容でした。 サービス連携の“謎解き”を可能にする Datadogによる分散トレース導入の一歩 株式会社タイミーの徳富様により、サービス間のボトルネック発見を容易にするための分散トレーシング導入について、ご紹介いただきました。 講演では、分散トレース情報をサービス間で連携させる方式、特に伝搬フォーマットの切り替えや複数フォーマットへの対応を可能にするInject/Extractを用いた実装方法など、その詳細な仕組みまで丁寧に解説されていました。 私自身、分散トレーシングは概念しか知りませんでしたが、具体的な仕組みを学ぶことができ、大変勉強になりました。 当日のブース出展の様子 続いて、私たちがゴールドスポンサーとして出展したニフティブースでの活動についてご紹介します。 弊社のブースでは、技術的なご紹介だけでなく、ご来場の皆様と双方向のコミュニケーションを楽しむための中心企画として、パネルアンケートを実施しました。 当日は多くの方にご参加いただき、シールの数から皆様の興味や関心の方向性をリアルタイムに感じることができました。 今回はどら焼きやその他ノベルティに加え、「NIFTY Tech Book」を配布しました。これが想定をはるかに超える人気で、「本業がありながらこのレベルのものを執筆できるのは本当にすごい」と熱心に感想を伝えてくださる方もいました。 また、パネルアンケートの「ニフティを知っていますか？」という質問には、非常に多くの方が「知っている」にシールを貼ってくださり、中には「パソコン通信時代から！」といった嬉しいお声もいただきました。また、「ニフティのサービス」では、やはり主力サービスの「@nifty 光」の知名度が高く、ココログやホームページサービスといった長年提供しているサービスにも多くのシールが集まり、弊社の歴史と現在を改めて実感する結果となりました。 アンケートにご協力いただいた皆様、そしてブースで貴重なご意見を聞かせてくださった皆様、本当にありがとうございました。 おわりに 今回の「SRE NEXT 2025」、私自身は一日目のみの参加ではありましたが、セッションやブースでの交流、そして当社の 仲上によるスポンサーセッション のすべてを通じて、学び多き一日となりました。 そして、他社の皆様の活動から得た気づきを参考に、自分たちのSRE活動をさらに良くしていきたいです。 最後になりますが、素晴らしい学びの場を提供してくださった登壇者の皆様、運営スタッフの皆様、そしてブースにお立ち寄りいただいたすべての皆様に、心より御礼申し上げます。ありがとうございました。

はじめまして。 ニフティ株式会社の浅利です。 現在、私は既存のクラウド環境から新しいクラウド環境への移行するプロジェクトを推進しています。 移行の対象システムには、長年の運用を経て内部構造が複雑化し、いわゆる「ブラックボックス」となってしまったシステムもいくつか含まれています。 他にも要因はあるのですが、プロジェクト全体のスケジュールにも遅延が見え始めてきました。 この状況をどう乗り越えるべきかをAWSの方との定例相談会でこの課題を共有したところ、この記事のタイトルにある構成を紹介いただいたので、今回は導入部分と実際の利用の二回に記事を分けてお送りします。 導入にあたって事前に確認したポイントも併せてご紹介しますので、同様の課題を抱える方の参考になれば幸いです。 利用するサービスについて Cline, Amazon Bedrock Cline VSCode上で動作する拡張機能です。ユーザーがAIに指示を出す対話インターフェースとして機能し、その内容を背後にあるAmazon Bedrockへ送信する役割を担います。 Amazon Bedrock Clineからのリクエストを受け取るAWSのサービスです。Amazonやサードパーティ製の様々なAIモデルの中から、指定されたモデルを使って指示を処理し、結果をClineに返します。 Amazon Q, Amazon Q Developer Amazon Q VSCode上で動作する拡張機能で、開発者が直接対話するAIアシスタントの窓口です。コード生成などの指示を受け付け、そのリクエストをAmazon Q Developerに送ります。 Amazon Q Developer Amazon Q Developerは、リクエストに応じて最適な基盤モデルを呼び出して処理を実行します。 AI利用における情報漏洩や目的外利用のリスク 社内ソースコードをツールに入力した際、そのデータが外部のAIモデルの学習に利用されたり、意図せず外部に共有されたりしないかを確認しました。 結論から言うと今回の構成であればAIモデルの学習に利用されません。 Cline(VS Code拡張機能) Clineは、APIプロバイダーとして「Amazon Bedrock」を選択した場合、ユーザーのデータ（ソースコードやプロンプト）を自社サーバーを経由させず、直接AWSのエンドポイントに送信する仕組みになっています。 これはClineの利用規約にも明記されており「ユーザーが管理するインフラストラクチャ（Amazon Bedrockなど）経由ですべてのモデル呼び出しを指示する場合、Clineはユーザーの入力トークン、出力トークン、基盤となるコード、またはその他のユーザーコンテンツを受信または保存しない」と記載されています。 Cline Terms of Service (セクション3 “User Content”) Amazon Bedrockのデータ取り扱いについて AWSは、Amazon Bedrockに送信された顧客のコンテンツ(ソースコード、プロンプト、生成結果)を、ベースモデルの改善（学習）には使用せず、いかなるモデルプロバイダー(Anthropic社など)とも共有しないことを公式に明言しています。 Amazon Bedrock FAQs Amazon Bedrock Security and Compliance Amazon Q Developer AWSは公式FAQページで、Proプランのデータ保護について以下のように明記しています。 Pro Tier で Amazon Q Developer にアクセスするユーザーのコンテンツが、サービスの改善や、基礎となる基盤モデル (FM) のトレーニングに利用されることはありません。 https://docs.aws.amazon.com/ja_jp/amazonq/latest/qdeveloper-ug/data-protection.html (プライバシーのセクション「Amazon Q Developer はモデルのトレーニングに私のコンテンツを使用しますか?」) Cline + Amazon bedrock の導入 IAMユーザーの作成とアクセスキーの取得 マネジメントコンソールから「IAM」にアクセスし、ユーザーを作成します。 アクセスキーを作成し、キーとシークレットキーを取得します。 また、作成したユーザーにカスタムポリシーをアタッチします。 (ご利用の環境にあわせて適宜変更ください) モデルアクセスの有効化 今回は Amazon Bedrock で Claude Sonnet 4 を使用します。 使用可能なモデルはリージョンに依存しますが、Claude Sonnet 4 が利用可能な「オレゴンリージョン(us-west-2)」に切り替えておきます。 マネジメントコンソールから「Amazon Bedrock」にアクセスし、メニュー下部にある「モデルアクセス」をクリックします。 「特定のモデルを有効にする」のボタンをクリックし、「次へ」ボタンを押します。 必要な情報を入力し、「次へ」ボタンを押します。 最後に入力した内容を確認して送信します。 アクセスが付与されるまで数分待ちます。 Clineのインストールと設定 Visual Studio Codeを開き、拡張機能から「Cline」をインストールします。 Clineの拡張機能を開き、「Use Your Own API Key」を選択後、以下の設定を入れます。 「AWS Access Key」と「AWS Secret Key」にアクセスキーの情報を入力 Use cross-region inference にチェック (普段開発しているリージョンで、使いたいAIモデルが提供されていない場合) Use Prompt caching にチェック (応答速度を求める場合やコストを抑えたい場合) Modelは「anthropic.claude-sonnet-4-20250514-v1:0」を選択 これで「Cline + Amazon bedrock」側の導入は完了です。 Amazon Q + Amazon Q Developer の導入 IAM Identity Center ユーザの作成 IAM Identity Centerでサブスクライブ対象のユーザを作成します。 Organization環境下どうかで手順が異なりますので、ここでは詳細は割愛させていただきます。 ご利用の環境にあわせて、AWS公式ドキュメントなどを参考にユーザーの作成を進めてください。 Amazon Q Developer プロファイル作成 Amazon Q Developer プロファイルを作成し、VS Code で Amazon Q Developer にアクセスするための「スタートページ URL」を取得します。 マネジメントコンソールから「Amazon Q」にアクセスし、Amazon Q Developer の使用を開始します。 サブスクライブ対象のユーザのEメールを入力し、「続行」をクリックします。 Amazon Q Developer プロファイルを作成します。 (表示されているプロファイル名はデフォルトになります) プロファイルの作成が完了すると以下の画面になるので、「設定」ボタンを押すとセッティング画面に遷移するのでそこで「スタートページ URL」を取得します。 Amazon Q のインストールと設定 Visual Studio Codeを開き、拡張機能から「Amazon Q」をインストールします。 インストール後、サインインの選択画面で「Company account」を選択します。 取得した「スタートページ URL」の入力と、Regionには IAM Identity Center が存在するリージョンを選択します。 「アクセスの許可」をクリックするとRequest approved の画面が開きます。 以下の様に VScode でAmazon Q が利用可能になります。 これで「Amazon Q + Amazon Q Developer」側の導入は完了です。 次回は実際の利用とそれぞれの構成による違いについて触れます。

はじめに こんにちは。NIFTY engineering ブログ運営チームです。 ブログ運営チームでは、ニフティのエンジニアに関する情報を広く世間に発信する活動を行っています。 本記事では、前回の記事から新しく行った活動についてご紹介します。 前回の記事については、 【祝20,000MAU！】NIFTY engineering ブログ運用チームの活動まとめてみた をご確認ください。 前々回の記事は、 【祝10,000MAU！】NIFTY engineer blog運用チームの活動まとめてみた をご確認ください。 ここで、改めてブログ運営チームについて少し紹介させてください。 ブログ運営チームについて ブログ運営チームは、弊社の採用をブランディングしているワーキンググループのうちの1サブチームとして活動しています。 現在、メンバーは4人で、全員専任ではなく自身の業務の兼務で活動しています。 それでは本題に入ります。 今回の活動紹介 NotionからWordPressに自動連携プラグイン追加 前回の記事で最後にご紹介したNotion連携について、社内で利用を開始しました。 本プラグインは、Notionで書いたものを、WordPress上に自動で連携してくれます。 また本文中内の画像や、WordPressの記事公開するときに必要なアイキャッチ画像や、タグについてもNotionのDBで設定すると、自動でWordPressに反映してくれます。 ブログ講習会開催 ブログ執筆に関するアンケートを毎年ブログ運営チームでエンジニア向けに実施しています。 そちらのアンケートで、WordPressの操作方法や文章の書き方、公開までのフロー、執筆のガイドラインがわからないといった声が多く寄せられていました。 そこで、ブログ運営チームではデモを用いたブログ執筆の講習会を実施することにしました。 ブログ講習会では、ニフティでのブログ執筆の仕方や、公開方法、また前述のNotionのWordPress連携の使い方を実際にデモしながら説明し、実際の執筆イメージをもっていただくようにしました。 この講習会には、希望者の他に、先輩を見習ってたくさん記事を執筆してほしいという思いを込めて、エンジニアの新人にも参加してもらいました。 アンケートでは、講習会自体の満足度は高く、積極的に書いていきたいや余力があれば書いていきたいといった声が多数寄せられたので、今後も継続的に実施を検討しようと思います。 リレーブログの継続 今回も前回に引き続き、リレーブログを実施しました。 今回のリレーブログ： 【リレーブログ企画第三弾】CI/CDリレーブログをやります！ また今後、以下のリレーブログの実施も予定しています。 今後のリレーブログ：25年新卒リレーブログ（近日中）etc その他細かい改善 ブログ運営チームでは、前述のブログアンケートで使いづらい点などが寄せられていたものなどをプラグインを追加したり、ソースを修正したりして、日々改善していっています。 直近ですと、シンタックスハイライトがわかりにくいという意見があったので、それを改善するプラグインとかを導入するなども実施しました。 おわりに 本記事では、最近のブログ運営チームの活動をご紹介いたしました。 こちらの活動のご紹介が、皆様のお役に立てれば幸いです。

はじめに こんにちは、添野 隼矢です。 ニフティでは、インナーソース活動が活発的に行われています。 その中で、私は今年からインナーソースを率先して広めていく活動に参加しています。 本記事では、インナーソースを社内に広めていく活動の一環として、第2回コントリビュートお試し会※1を先日開催したので、そちらについて執筆したいと思います。 ※1 第1回コントリビュートお試し会は、去年の12月に開催しました。 コントリビュートとは？ まずコントリビュートとは、オープンソースプロジェクトやインナーソースプロジェクトなどにおいて、コードの修正、バグの修正、機能追加、ドキュメントの追加など、何らかの形で開発に貢献することを指します。 今回はこのコントリビュートを試してもらうという会になります。 コントリビュートお試し会について まずコントリビュートお試し会を開催するにあたり、Good First Issueがたくさんあり、比較的触りやすいツールやプロジェクトを探しました。 今回は、以前本ブログで紹介した「 もじこえ 」と「 myfriendGPT 」の2つを、コントリビュートを体験してもらうリポジトリとして選定し、その2つのリポジトリのトラステッドコミッターにも協力してもらいました。 次に、社内のエンジニアのSlackチャンネルで、参加者を募集しました。 結果、今回は6名に参加していただけました。 ~~ コントリビュートお試し会当日 ~~ まず始めに、インナーソースについての説明と、コントリビュートなどをするためのインナーソースガイドラインが弊社では作成されているので、そちらをもとに座学を実施しました。 その後、前述のトラステッドコミッターの協力のもと、コントリビュートの流れを実際に体験してもらうハンズオンを参加者に経験してもらいました。 参加者からの感想 この会の実施後、参加者にアンケートをとったところ、以下の結果になりました。 また以下のようなコメントももらいました。 インナーソースをコントリビュートする流れや心構えについて理解できた。 一通りの流れを実際に見ることができてよかったです。 コントリビュートの手順や思っていたよりも難易度は低くてやりやすさを感じました。 今後について 社内にインナーソースを広めていくため、今後も定期的にコントリビュートお試し会は開催していこうと思います。 また組織的な話でいいますと、ニフティでは InnerSource Commons というコミュニティに参加し、日本のインナーソース活動を広めていく活動にも協力しています。 InnerSource Commonsの Connpass の参加、お待ちしています。 もちろん、ニフティの Connpass 参加もよろしくお願いします。

はじめに こんにちは。ニフティの並木です。 今回は、「Amazon CloudFront」+「Amazon S3」で構成されているサイトのキャッシュを削除する方法をまとめました。 手順 AWSマネジメントコンソールで、キャッシュ削除の対象となるCloudFrontを選択します。 「キャッシュ削除」タブを選択し、「キャッシュ削除を作成」を押下します。 オブジェクトパスにS3バケット名を入力し「キャッシュ削除を作成」を押下します。 おわりに 「修正したはずなのになぜか反映されていない…」という場合はキャッシュが原因かもしれません。 そのような場合は、ぜひ今回の手順でキャッシュクリアを試してみてください。

はじめに 半年近くブログをサボっていた宮本です。意識していないと、なかなか書かないですね……。 今回はTerraformでNodeランタイムのAWS Lambdaを複数同時に作成しようとしたとき、遭遇した問題とその解決策についてご紹介しようと思います。 問題の発生した構成 業務でAWSを利用する際は基本的にTerraformを利用しており、Lambdaの管理もTerraformで実施しています。ただしLambdaはコンテナ形式では無く、昔ながらのコードをzipで固めてデプロイする形式にしていました。 このLambdaはNode.jsのランタイムを利用しており、コード自体はTypeScriptで開発してデプロイ時にterraform_dataリソースを使ってビルドしています。また、パッケージ管理にはyarn v1を利用していました。 resource "terraform_data" "build_code" { provisioner "local-exec" { working_dir = "${path.module}/app" command = <<EOT #!/bin/sh # 依存関係のインストール yarn install # ビルドコマンドの実行 yarn build EOT } } これ単体は正常に動作していたのですが、1つのプロジェクト内で同様の構成のLambda複数デプロイしようとしたところ yarn install のタイミングでエラーが発生するようになってしまいました。 error https://registry.yarnpkg.com/<パッケージパス>: Integrity check failed for "<パッケージ名>" (computed integrity doesn't match our records, got "<ハッシュ>") terraform_data同士に依存関係もないためTerraform上で同時に yarn install が動作したらしく、さらにこの2つの yarn install でインストールするパッケージに同一パッケージの異なるバージョンが含まれていたため、エラーが発生してしまったようです。 解決方法 今回試した限りでは、次の2種類の方法どちらかで回避できました。 yarnの実行時にキャッシュディレクトリを指定する yarn v1の利用をやめてpnpmやyarn v4に移行する yarnの実行時にキャッシュディレクトリを指定する yarnはパッケージのインストール時に、次回以降のインストールを高速にするためキャッシュを保存します。これがyarn v1だと、該当のプロジェクトではなくPC全体のグローバルなキャッシュとして保存しています。 今回は同一パッケージの別バージョンをよりにもよって同時にinstallしようとしたため、そのキャッシュ周りがおかしくなったことが直接の原因でした。 この解決策としては、実行時にyarnのキャッシュディレクトリを指定することで対処できます。 resource "terraform_data" "build_code" { provisioner "local-exec" { environment = { # キャッシュフォルダを指定 YARN_CACHE_FOLDER = ".yarn-cache" } working_dir = "${path.module}/app" command = <<EOT #!/bin/sh # 依存関係のインストール yarn install # ビルドコマンドの実行 yarn build EOT } } yarn v1の利用をやめてpnpmやyarn v4に移行する もう一つの解決策として、yarn v1の利用をやめることがあります。 同じyarnでもv4だとグローバルキャッシュ周りの動作が改善されているらしく、同じプロジェクトでも問題は発生しませんでした。また、pnpmでも試してみましたがこれも問題は発生しませんでした。 最新のパッケージ管理ツールだと、パッケージ同士の依存関係のバージョン差分の問題なども解決してくれるため、こちらの方がスマートな気はします。もっとも、パッケージ管理ツールを移行するとなると足が重いのも事実ですが……。 少なくとも、今後新しいNode.jsのプロジェクトを利用する場合は、最新のパッケージ管理ツールを利用したいですね。 おわりに 今回は、Terraformから複数のNode.jsのプロジェクトをビルドしようとした際に発生したエラーについて紹介しました。必ずしも発生する問題ではないと思いますが、もしyarn v1を利用していて似たような自体が発生した際に参考になれば幸いです。 参考 Provisioner: local-exec | Terraform | HashiCorp Developer yarn cache | Yarn

はじめに こんにちは。新卒1年目の大村です。 6月27日に開催されたDNS Summer Day 2025に先輩社員2名と共に参加してきました。 その感想をまとめていきます。 DNS Summer Dayとは https://www.dnsops.jp/event20250627.html 今年は日本橋のTKPガーデンシティPREMIUMで開催されました。 イベントの概要については、connpassに以下のような記載があります。 DNSは多くの重要な役割を持つ、代替となるものがないインフラサービスとなっています。一方で、DNSの運用については権威側にもリゾルバ側にも十分な関心が払われておらず、必要な予算や人材などもきちんと割り当てられているとは言えない状況が相変わらず継続しています。その状況を鑑み、DNSの基本的な話から突っ込んだ話までカバーしたイベントを開催します。 https://dnsops.connpass.com/event/358220/ イベントの応募には、キャンセル待ちが出るほどの参加希望者がいました。 会場の様子 広めの会議室が満席になるほどの盛況ぶりでした。 connpass応募者数の通りなら140人ほどだと思います。 あまり堅苦しい感じもなく、良い雰囲気のコミュニティといった雰囲気でした。 また、後方にはスポンサーのブースもありました。 なぜ参加したのか 私はOJTで「ISPオペレーションサブチーム」に配属となりました。このチームではDNSサーバの運用管理も担当しています。 ISPオペレーションサブチームの紹介はこちら 【インタビュー】ニフティのISPオペレーションチームについて【ISP前編】 【インタビュー】ニフティのISPオペレーションチームの過去と未来について【ISP後編】 チームとしてはDNS運用に役立つ情報収集のため、また私個人としてはDNSへの理解を深めるために参加しました。 参加してみての感想 特定のソフトウェアの仕様など詳細な話から、比較的理解しやすくても実践的な内容まで、多くの学びを得ることができました。 中にはユーモアあふれる発表もあり、DNSのみならず今後のプレゼンテーションの参考にもなりました。 このようなイベントにはほとんど参加したことがなかったのですが、今まで参加してこなかったことがもったいないと感じるほど充実した学びの場でした。 今回はブースを回るのも少し遠慮してしまったので、次回は積極的に参加したいと思います。 学び DNSについては初学者のため、見聞きしたもの全てが新たな学びでした。その中から特に印象に残ったものをいくつかを紹介したいと思います。 初めて“イベント”に参加してみて 前述の通り、私はこれまでこのようなイベントに参加したことがありませんでした。 しかし、初めて参加してみて次のような気づきがありました。 思ったよりも理解できる話が多かった 歴戦の猛者の集まりで、話がとても難しいようなイメージがありました。もちろん、そのような内容のものもありましたが、大半はある程度の事前知識があれば理解できるものでした。 雰囲気が良かった もっと堅苦しい超真面目な発表のイメージもありました。ですが実際は、ユーモアにあふれる発表が多かったです。 もっと声をかけてみても良かった 参加してみると、ブースの方とであったり、他の参加者と会話している人が多くいました。今回はかなり遠慮してしまったので、もっと積極的にしても良かったかなと思いました。 ドメインの廃止について ドメインの廃止には慎重にならなければならないということを学びました。 廃止した後に「ドロップキャッチ**」され悪用される可能性を考慮し、そのドメインがどのように運用されていたかの記録が十分に薄まるまで保持すべきとのことです。 つまり、廃止後もしばらくコストがかかるということですね。 将来、もしも新規ドメインの取得や廃止の話が出た際には、この話を思い出して検討したいと思います。 ** ドロップキャッチ: 他者が放棄したドメインを再取得可能になった瞬間に取得すること。詐欺などに悪用される可能性がある。 DNS as Codeについて 今回のイベントでは、DNSControl、octoDNSといった”DNS as Code”に関するセッションがありました。 DNS as Codeは初めて触れた概念で、非常に興味深く感じました。この手法は今後のDNS運用にかなり役立つのではないかと期待しています。 また、DNSには比較的硬派なイメージがありましたが、DNS as Codeと組み合わせて運用することで、そのイメージがかなり変わるだろうと思いました。 どこから情報を仕入れるか 登壇者の方々が詳しいのはもちろんですが、どこから情報を仕入れているのかが気になりました。 イベント全体を通して話を聞いていると、論文やRFC、ICANNのレポートなどを参照していることがわかりました。 まとめ DNS Summer Day 2025に参加しました。 イベントを通じて、DNSについて多くの知識と学びを得ることができたました。 今回はDNSに詳しくない状態での参加でしたが、今後知識を深めることでさらに理解が進み、より面白く感じられるだろうと思います。これからも学習を続け、来年もぜひとも参加したいと思います。