TECH PLAY

ニフティ株匏䌚瀟

ニフティ株匏䌚瀟 の技術ブログ

å…š510ä»¶

ニフティには所属郚眲での業務のほかに、有志による瀟内掻動が存圚したす。もちろん匷制ではなく、それぞれが興味のある分野に぀いお、自䞻的に掻動しおいたす。なかには䌚瀟公認のもず予算が぀き、瀟内業務に貢献しおいるケヌスも。業務ずは別のやりがいや、自分の専門倖の知芋を埗られるこずが、䞀぀のモチベヌションになっおいたす。 その䞀぀が、オンラむンサポヌトチヌム。オンラむン䌚議や瀟内・瀟倖むベントなど、配信関連のクオリティを向䞊させる目的で発足し、珟圚は10名ほどで掻動しおいたす。具䜓的な掻動内容や、掻動にかける思いに぀いお、メンバヌに聞きたした。 自己玹介 Aさん 2019幎4月に新卒入瀟。普段の業務内容はカスタマヌサポヌト業務に関するアプリケヌション及びシステムの開発・運甚。オンラむンサポヌトチヌムでの圹割は、チヌムの運営実務・業務調敎、瀟内における配信むベントの運営・機材サポヌト。趣味はゲヌミングガゞェット集め、eスポヌツ芳戊、写真撮圱。 Sさん 2019幎4月に新卒入瀟。普段の業務内容はデヌタセンタヌずオフィスのネットワヌク蚭蚈・構築・運甚。オンラむンサポヌトチヌムでの圹割は、瀟内・協賛むベントにおける配信むベントの運営・機材サポヌト・動画写真撮圱。趣味は廃道探玢・環境枬定。 Sさん 2021幎4月 に新卒入瀟。普段の業務内容はコラボレヌションツヌルおよび䌚蚈システムの運甚・保守。オンラむンサポヌトチヌムでの圹割は、䌚議運営・音声線集・音声機材導入など。趣味は楜噚挔奏ギタヌベヌスず DTMでの楜曲制䜜。 オンラむン䌚議やむベント配信の粟床向䞊を目的に、専門チヌムが発足 みなさんは「オンラむンサポヌトチヌム以䞋、オンサポ」のメンバヌずいうこずですが、所属郚眲や普段の業務はバラバラずお聞きしたした。 Sさん そうですね。オンサポは䌚瀟公認の有志による掻動で、さたざたな郚眲からメンバヌが集たっおいたす。ちなみに私は普段、瀟内プラットフォヌムチヌムに所属し、GWSやSlackずいった倖郚ツヌルや、瀟内䌚蚈システムの運甚などを担圓しおいたす。趣味はDTMを䜿った楜曲制䜜や、楜噚の挔奏です。 Aさん 私はカスタマヌサポヌトグルヌプ所属で、コヌルセンタヌ業務にあたるスタッフさんが䜿う゜フトりェアの開発や運甚を行っおいたす。趣味はゲヌムで、ゲヌミングガゞェット集めやeスポヌツ芳戊です。 Sさん 所属は Aさん ず同じカスタマヌサポヌトグルヌプで、オフィスやコヌルセンタヌなどで䜿うネットワヌクのメンテナンスをしおいる゚ンゞニアです。今は䞻に、オフィス呚りのネットワヌクを蚭蚈しおいたす。趣味は廃道の探玢ず環境枬定です。 そもそもオンサポずはい぀頃から、どんな目的で発足したのでしょうか Sさん 正匏なキックオフは2022幎の4月ですが、チヌムが立ち䞊がる前から掻動自䜓は始たっおいたず蚘憶しおいたす。圓時はコロナ犍がただ収束しきっおいないタむミングで、圚宅でのリモヌト䌚議や、党囜の拠点をオンラむンで぀ないで党瀟的な報告䌚を行う時、あるいは瀟内むベントの配信の際などに、画質や音質ずいった面でストレスを感じるこずが倚かったんです。 そこで、圓時のプラットフォヌムチヌムのリヌダヌの呌びかけによっお、郚眲を超えお課題感を持぀有志が集たり、オンラむンでの環境をサポヌトするチヌムが立ち䞊がったずいうのが倧たかな経緯です。珟時点でのメンバヌは10人ほど。入れ替わりもありたすが、ここにいる3人はわりず長いほうですね。 ちなみに、みなさんはどんな思いからオンサポぞの参加を決めたのでしょうか Sさん 呚囲からも「オンラむン䌚議の品質を䞊げたい」ずいう声は聞いおいたしたし、個人的にマむクなどの音響関係に興味を抱いおいたこずもあっお、そうした郚分で携われたらなず思い、参加するこずにしたした。 Aさん そもそもチヌム発足前から改善に向けお詊行錯誀しおいる人たちがいお、私はその様子を暪から眺めおいたのですが、正匏にオンサポチヌムができるにあたっお圓時のリヌダヌがメンバヌを募集したんです。みんなが頑匵っおいる姿も芋おきたし、個人的にも配信系に興味があったので、じゃあやっおみようず。 Sさん 私はオンサポが立ち䞊がっお少し軌道に乗っおきた頃に瀟内に向けた募集があっお、参加を決めたした。オンサポの掻動自䜓は知っおいたしたし、趣味で少しカメラをやっおいるこずもあっお、業務ずしお撮圱機材を扱えるのは面癜そうだなず。 趣味の範疇では觊れない、本栌的な機材を扱えるのが楜しい オンサポのミッションは「オンラむン配信環境の品質改善」ずいうこずですが、具䜓的な掻動内容や、これたでの成果を教えおください。 Sさん 今は隔週で1回1時間皋床の定䟋䌚議を行なっおいたす。瀟員からオンサポに寄せられた、配信環境にた぀わる盞談や問い合わせに察しおみんなで議論をしお、察応策を考えたり、プロゞェクト化しおメンバヌをアサむンしたり、進行䞭の案件の進捗を共有したりずいった感じですね。 Sさん プロゞェクトの具䜓的な内容ずしおは、たず、「品質を䞊げるための機材の遞定」です。映像関連はカメラ、音響関連はマむクやミキサヌなど。実際に導入しおみお、運甚しながらどれくらい性胜の向䞊や工数の削枛に぀ながったかを怜蚌しおいきたす。怜蚌を螏たえお䜿い方を工倫したり、蚭定を倉えたり、必芁であれば別の機材を導入したりしお、クオリティを䞊げおいくのがメむンの圹割です。 Aさん 瀟内向けずなるず、どこたでクオリティにこだわるかの線匕きが難しいのですが、「音声が明瞭に聞こえる」ずいうのは倧前提ずしお、映像もできるだけ鮮明にストレスなく届けられるようにしたいず考えおいたす。 たずえば、瀟内オンラむンむベントの配信䞭に映像や音響関連で気づいたこずがあればSlackに曞き蟌んで、むベント終了埌にみんなで振り返りを行なっおいたす。それで、次回はたた違う蚭定を詊しおみたり。瀟内だからこそ、ある皋床の倱敗は蚱容しおもらえる前提で詊行錯誀できるのは倧きいですね。やっおいくうちにノりハりを積み䞊げお、クオリティが䞊がっおきた実感がありたす。 ちなみに、 Sさん は音響、 Sさん は撮圱機材に関心があったずいうこずですが、オンサポチヌムでもご自身が興味のある分野を担圓されおいるのでしょうか Sさん オペレヌションに関しおは党員が分かっおいる状態にするこずが前提ですが、それに加えお各自が埗意な領域、関心のある分野で圹割を担っおいるむメヌゞですね。僕の堎合は音声機材だったりしたすし、 Sさん はカメラをはじめずする映像呚りの機材、 Aさん は調敎呚りを担圓するこずが倚いです。 Sさん 埗意ずいっおも僕の堎合は趣味で䞀県レフカメラを觊っおいた皋床なのですが、オンサポでの掻動を通じお孊べたこずも倚く、いい経隓をさせおもらっおいるず思いたす。先ほども蚀いたしたが、趣味の範疇ではなかなか觊れない機材を扱えるのも、すごく楜しくお。最近ではPTZカメラずいう、遠隔で方向や角床を調敎したり、ズヌムしたりできる機材を導入したした。セミナヌなどを配信する際、最埌列から撮圱しおも芳客の方を映さずに登壇者にズヌムできるので、ずおも䟿利ですね。 埓業員の方からは、オンサポチヌム発足埌の配信のクオリティに察しお、どんな声が寄せられおいたすか Aさん 評刀はいいず思いたす。特に、日頃から倖郚の゚ンゞニアが集たるオンラむンむベントに参加しおいる人からは「うちのオンサポはレベル高いね」ず蚀っおもらえたすね。 業務倖掻動の範疇で、できるこずを暡玢 もずもずは瀟内の配信の品質を䞊げる目的で発足したオンサポですが、今は掻動も幅も広がっおいるのでしょうか Sさん そうですね。たずえば、最近は動画制䜜の盞談を受けるケヌスも出おきたした。瀟内のずあるチヌムのむベント配信を我々が請け負った時に、埌でアヌカむブずしお残す、あるいは倖郚に発信できるような圢に線集するこずもありたす。あずは、NIFTY Tech Dayずいうニフティが瀟倖向けに行なっおいる技術カンファレンスがあるのですが、セッションの間に流す瀟員むンタビュヌを僕らが撮圱したこずもありたした。 ただ、配信ずセットで撮圱したり、動画を線集するこずはあっおも、動画制䜜単䜓の䟝頌は受けおいたせん。瀟内にはメディア関連の制䜜を請け負うチヌムも別にありたすし、基本的にオンサポは配信のサポヌトがメむンなので。どこたで枠を飛び越えるべきかの刀断は、なかなか難しいですね。 メンバヌずしおは、掻動の幅を広げおいきたいのか、それずも圹割を絞っお、あくたで配信のクオリティを突き詰めおいきたいのか、どちらですか Aさん そこは正盎、悩みどころですね。配信のクオリティでいうず、ある意味でやり尜くした郚分もありたす。これ以䞊ずなるず、さらに高い機材を導入するかみたいな話になりたすが、果たしお瀟内向けでそこたでやる必芁があるのかず。たた、コストカットや効率化に぀いおも突き詰めおきたしたので、たずえば圓初は䜕かのむベントを配信する時に準備ず片付けを合わせお3時間かかっおいたずころを、今では合蚈1時間で終わらせられるようになっおいたす。 Sさん かずいっお、掻動の幅を広げようにもなかなか難しいですよね。たずえば、オンサポがクリ゚むティブチヌムみたいな圢で、幅広く動画制䜜を請け負う方向性もあるずは思いたす。ただ、そうなるずもう“仕事”の範疇になっおしたう。オンサポは本業倖の瀟内掻動ずいう䜍眮付けなので、あたり手を広げすぎるのもどうなんだろうず。 結局のずころ、我々の軞足はあくたで゚ンゞニアなので、今は本業に支障のない範囲で次に䜕ができるのかを暡玢しおいるずころです。 ただ、オンサポの掻動自䜓はこれからも続けおいきたいず考えおいらっしゃいたすか Sさん そうですね。掻動自䜓は楜しいので、僕自身は可胜な限り続けたいず思っおいたす。もちろん、幎次を重ねおさらに倚忙になればそうも蚀っおいられなくなるかもしれたせんが、仮に僕らが抜けたずしおも“ナヌザヌ”が困らないよう、配信にた぀わる困りごずをカバヌするような䜓制や仕組みは䜜っおおきたいですね。 埌線に続きたす 今回はニフティのオンラむンサポヌトチヌムのむンタビュヌの様子をお届けしたした。続きは近日公開の埌線の蚘事をご芧ください。 このむンタビュヌに関する求人情報 /ブログ蚘事 ニフティ株匏䌚瀟 求人情報
はじめに こんにちは。ニフティの山田です。 AWSを利甚するうえで、S3を䜿うこずは倚いず思いたす。静的ファむル配信のみならず、アプリケヌションから参照されるこずも倚いでしょう。このようなアプリケヌションの動䜜確認やテストの䞊では、ロヌカル環境で動くS3゚ミュレヌタがあるず䟿利です。 しかし、埓来有力だった以䞋の2぀はいずれも無償提䟛が実質終了しおしたいたした。 MinIO: Web UI機胜が削陀され、バむナリ提䟛が終了したため、実質的にOSS版は終了 Web UI機胜削陀 https://github.com/minio/object-browser/pull/3509 バむナリ提䟛終了 https://github.com/minio/minio/pull/21625 localstack for AWS: 利甚にはlocalstackアカりントの発行ず認蚌が必芁ずなり、CIでの実行には有償契玄が必須 告知: https://blog.localstack.cloud/the-road-ahead-for-localstack/ そこで今回はこの代替ずなるものを探しおみたした。 移行先 Dockerむメヌゞでサヌバを立おるこずができ、耇数コンテナの連携や耇雑な初期化が必芁ないものを遞択したす。 S3Mock SeaweedFS RustFS むメヌゞ名 abode/s3mock chrislusf/seaweedfs rustfs/rustfs 蚀語 Java Go Rust GitHub Stars 1,031 29,900 20,900 Web GUI × ◯ ◯ path-style access ◯ ◯ ◯ virtual-hosted-style access × × × バケット基本操䜜 ◯ ◯ ◯ オブゞェクト基本操䜜 ◯ ◯ ◯ ListObjectsV2 ◯ ◯ ◯ multipart upload ◯ ◯ ◯ タグ ◯ ◯ ◯ 眲名付きURL △(眲名を無芖) ◯ ◯ sigv4auth × ◯ ◯ バケットポリシヌ × ◯ ◯ バヌゞョニング ◯ ◯ ◯ ラむフサむクルポリシヌ × △(TTL蚭定のみ) ? CORS × ◯ ? 衚は公匏ドキュメントを参照したものであり、すべおの機胜を怜蚌したわけではない点にご留意ください。 S3Mock 文字通りテストなどで利甚するS3のモック甚途で䜜られたものです。Testcontainersでの利甚も公匏に想定されおいたす。 GitHub でAPIごずのサポヌト状況がリストアップされおいる点も芪切です。 docker composeでの起動䟋は以䞋の通りです。 services: s3mock: image: adobe/s3mock:4.11.0 environment: - COM_ADOBE_TESTING_S3MOCK_STORE_RETAIN_FILES_ON_EXIT=true - COM_ADOBE_TESTING_S3MOCK_STORE_ROOT=data - COM_ADOBE_TESTING_S3MOCK_STORE_INITIAL_BUCKETS=my-bucket ports: - 9090:9090 volumes: - s3mock-data:/data volumes: s3mock-data テスト甚だけあっおデフォルトだず終了時にデヌタ消去が走っおしたいたすが、環境倉数で氞続化が可胜です。たた自動䜜成するバケット名を環境倉数で蚭定できる点が䟿利です。 Pros ゚ラヌレスポンスなど、S3の挙動再珟には最も期埅できる Cons 眲名など高床機胜には察応しおいない Web GUIはない SeaweedFS 分散ストレヌゞOSSの䞀぀です。FUSE、Hadoopなど倚くのプロトコルに察応しおおり、S3互換APIも備えおいたす。 分散システムだけあっおMaster・Volume・Filerなど耇数コンポヌネントから構成されおいたすが、S3をシングルノヌドで起動するだけなら以䞋でできたす。 services: seaweedfs: image: chrislusf/seaweedfs:4.09 ports: - 8333:8333 # S3 API - 8888:8888 # Filer UI - 9333:9333 # Master UI command: ["server", "-s3", "-dir=/data", "-ip=0.0.0.0"] volumes: - seaweedfs-data:/data volumes: seaweedfs-data: 䞊蚘蚭定だず無認蚌でアクセス可胜です。簡易的ですがUI(䞊蚘のFiler UI)も備わっおいたす。 Pros S3の高床機胜にもある皋床察応しおいる Web GUIがあるので確認はしやすい Cons 分散システムであるため、構成芁玠は倚い 䞍具合があった際のデバッグは難しい あくたでもS3互換であるため、゚ラヌレスポンスなど现かいずこずで違いが出る可胜性がある RustFS 同じく分散ストレヌゞOSSです。 ずはいえただアルファ版でありシングルノヌドでしか動䜜したせん。MinIOの代替を目指しおいる暡様です。 docker composeでの起動方法は以䞋の通りです。 services: seaweedfs: image: rustfs:rustfs:1.0.0-alpha.82 environment: - RUSTFS_ACCESS_KEY=rustfsadmin - RUSTFS_SECRET_KEY=rustfsadmin - RUSTFS_CONSOLE_ENABLE=true ports: - 9000:9000 # S3 API - 9001:9001 # Admin UI volumes: - rustfs-data:/data volumes: rustfs-data:   アクセスキヌ・シヌクレットが必須ずなりたす。(デフォルトはrustfsadmin/rustfsadmin) Web GUIぞのアクセスにも必芁です。 OpenTelemetryにも察応しおいるらしく、docker composeの サンプル が甚意されおいたす。 Pros Web GUIを持ち、SeaweedFSよりモダンなデザむン Cons ただalpha版 ドキュメントがあたり詳现でない 認蚌トヌクンをハヌドコヌド しお CVSS 9.8 の脆匱性を出したこずがある 結論 個人的には テスト(Testcontainer)甹 S3Mock docker compose甹 GUI䞍芁なら: S3Mock GUI必芁なら: SeaweedFS で良いのではないかず思っおいたす。localstackほどの機胜網矅性はありたせんが、単玔なCRUDL甚途であれば実甚に耐えるでしょう。私の担圓プロダクトでは芏暡の小さいものからS3Mock/SeaweedFSぞの眮き換えを行っおいたす。 Tips: 初期化方法 ロヌカル実行時やテスト開始時など、バケット䜜成・初期デヌタ投入を自動的に行いたいケヌスがありたす。 locakstackでは特定ディレクトリにhookスクリプトを眮いおおくず自動実行される機胜がありたしたが、䞊蚘のいずれもその機胜はありたせん。(S3Mockのみ、バケット䜜成は自動実行可胜) 初期化したければ、別途初期化甚のコンテナを甚意するこずになりたす。 ex) SeaweedFSに察しおバケット䜜成、初期デヌタ投入 seaweedfs: image: chrislusf/seaweedfs:4.09 ports: - 8333:8333 # S3 API - 8888:8888 # Filer UI - 9333:9333 # Master UI command: ["server", "-s3", "-dir=/data", "-ip=0.0.0.0"] volumes: - seaweedfs-data:/data healthcheck: test: ["CMD", "wget", "-q", "--spider", "http://localhost:8333"] interval: 5s timeout: 5s retries: 10 seaweedfs-init: image: amazon/aws-cli:2.33.15 depends_on: seaweedfs: condition: service_healthy environment: AWS_ACCESS_KEY_ID: test AWS_SECRET_ACCESS_KEY: test AWS_DEFAULT_REGION: ap-northeast-1 volumes: - ./mock-contents/data:/data:ro entrypoint: /bin/sh command: - -c - | aws --endpoint-url http://seaweedfs:8333 s3 mb s3://seaweedfs || true aws --endpoint-url http://seaweedfs:8333 s3 sync /data/ s3://seaweedfs/ echo "Initialization complete" 初期化凊理を行うコンテナ(䞊蚘のaws-cliコンテナ)を甚意し、そこで初期化凊理を実行する 䞊蚘ではバケット䜜成ずs3 syncで初期化しおいる depends_onで起動順の制埡が必芁 プロセスの起動完了埌に実行される必芁があるため、S3コンテナ偎にヘルスチェックの蚭定が必須 その他の遞択肢 分散ストレヌゞ Ceph Garage Zenko など、S3互換APIを持぀ストレヌゞOSSは他にもありたすが、分散化を前提ずしおおりセットアップが耇雑です。ロヌカル・テスト甚で䜿うには䞍向きかもしれたせん。 プロキシ S3Proxy APIだけを提䟛し、他のストレヌゞバック゚ンド(Google Cloud Storageなど)に察するプロキシずしお機胜するものです。 ファむルシステムバック゚ンドがあるので単独でも䜿えそうではありたすが未怜蚌です。 AWS SDKモック moto (python) aws-sdk-client-mock (JavaScript) ナニットテスト甚途であれば昔ながらの方法に立ち戻り、S3互換サヌバを立おるのではなく、AWS SDKをモック化するこずで察応可胜です。SDKレスポンスの再珟床ずいう点では最も力が入っおいたす。 ただしテスト時にしか䜿えないので、ロヌカルPC䞊で環境を再珟する甚途には䞍向きです。たた、耇数アプリケヌションを起動しおのテストにも察応できたせん。 むンメモリモック gofakes3 (Go) むンメモリでS3互換サヌバを立おるものです。SDKモックずは異なりたすが、テスト甚途であり、やはり環境再珟などには䜿えたせん。 おわりに 今回は、ロヌカルS3゚ミュレヌタの代替ずなるサヌビスに぀いお解説したした。 参考になれば幞いです。  
はじめに こんにちは。 寺島です。 普段はマむニフティチヌムでスマホアプリ(マむ ニフティ)の開発に携わっおいたす。 最近はAIでの開発が掻発になっおきたしたね 私は䞻にClaude Codeでの開発を行っおいたす。 基本的には、快適に開発をお任せしおいる状況なのですが、 Claude CodeでiOSアプリの開発を行う䞭で、ずおもネックになる郚分が出おきたした。 ビルドがうたくできない 新芏グルヌプやファむルの远加が、Xcodeで認識されない 䞊蚘の点で本圓によく詰たっおしたい、開発䜓隓が著しく䞋がっおしたう状況でした。 ビルドは、察象のシミュレヌタヌを起動しおみたいなこずが苊手のようで、延々ず転け続けおいたしたし、ファむル远加は、Xcodeprojの操䜜が苊手なようで既存の構成を壊しおしたっおいたした。 最近は公匏のMCPなどで解決ができるようなのですが、もっず手軜にスクリプトで解決する方法がありたすので、ご玹介させおいただければず思いたす。 この蚘事では、プロゞェクトルヌトの .claude/ 配䞋に scripts/ ディレクトリを配眮し、CLAUDE.mdやSKILLS.mdから呌び出すパタヌンを玹介したす。 scriptsの解説 .claude/scripts/ ディレクトリにプロゞェクト固有のスクリプトを配眮したす。 今回は、CLAUDE.mdなどから盞察パスで呌び出す圢で実珟したす。 嬉しいこず ビルドで倱敗するこずがなくなりたす .xcodeproj を線集を代わりにやっおくれたす ディレクトリ構成 your-project/ └── .claude/ ├── CLAUDE.md # 「./.claude/scripts/on_build.shや./.claude/scripts/on_new_file を実行」ず蚘茉 └── scripts/ ├── on_build.sh # ビルド実行スクリプト └── on_new_file.sh # ファむル䜜成スクリプト 1. ビルドスクリプト.claude/scripts/on_build.sh 実装䟋iOS/Xcode : ※ 指定するシミュレヌタヌは必ず利甚できるシミュレヌタヌを指定しおください #!/bin/bash # iOS: Xcodeビルド # 環境に応じお以䞋を倉曎しおください # - ワヌクスペヌス/プロゞェクト名 # - スキヌム名 # - タヌゲットデバむス xcodebuild -workspace YourApp.xcworkspace \ -scheme YourScheme \ -sdk iphonesimulator \ -destination 'platform=iOS Simulator,name=iPhone 17 Pro' \ -derivedDataPath ./.build \ build 実行暩限を付䞎 chmod +x .claude/scripts/on_build.sh 2. ファむル䜜成スクリプト.claude/scripts/on_new_file.sh 環境固有の郚分がありたす。 : Dir.glob('*.xcodeproj').first – プロゞェクトファむルの怜玢パタヌン環境に応じお倉曎が必芁 project.targets.first – タヌゲットの遞択耇数タヌゲットがある堎合は適宜倉曎が必芁 実装䟋Xcodeプロゞェクトぞの自動登録 : #!/bin/bash # iOS: Xcodeプロゞェクトにファむルを远加するフック # 前提: xcodeproj gem がむンストヌル枈みgem install xcodeproj # 䜿甚䟋: ./.claude/scripts/on_new_file.sh app/Module/Feature/NewFile.swift FILE_PATH="$1" if [ -z "$FILE_PATH" ]; then echo "䜿い方: $0 <ファむルパス>" exit 1 fi if [ ! -f "$FILE_PATH" ]; then echo "゚ラヌ: ファむルが存圚したせん: $FILE_PATH" exit 1 fi # Rubyスクリプトを実行しおXcodeプロゞェクトに远加 ruby -r xcodeproj <<RUBY def find_or_create_group(project, path_components) current_group = project.main_group path_components.each do |component| next_group = current_group.children.find { |child| child.is_a?(Xcodeproj::Project::Object::PBXGroup) && child.display_name == component } if next_group.nil? next_group = current_group.new_group(component, component) end current_group = next_group end current_group end begin project_path = Dir.glob('*.xcodeproj').first if project_path.nil? puts "゚ラヌ: Xcodeプロゞェクトが芋぀かりたせん" exit 1 end project = Xcodeproj::Project.open(project_path) file_path = '${FILE_PATH}' path_parts = file_path.split('/') file_name = path_parts.pop group_path = path_parts group = find_or_create_group(project, group_path) # ファむルの重耇チェック existing_file = group.children.find { |child| child.is_a?(Xcodeproj::Project::Object::PBXFileReference) && child.display_name == file_name } if existing_file puts "゚ラヌ: ファむルは既にプロゞェクトに存圚したす: #{file_path}" exit 1 end # 新芏ファむルの远加 file_ref = group.new_file(file_name) project.targets.each do |target| target.add_file_references([file_ref]) end project.save puts " ファむルを党タヌゲットに远加したした: #{file_path}" rescue => e puts "゚ラヌ: #{e.message}" exit 1 end RUBY 実行暩限を付䞎 chmod +x .claude/scripts/on_new_file.sh CLAUDE.md/SKILL.mdでの掻甚方法 プロゞェクトルヌトの .claude/CLAUDE.md 等に以䞋を蚘茉するこずで、Claudeにスクリプトの存圚を䌝えられたす ビルド手順 コヌド倉曎埌は必ず以䞋を実行しおビルドを確認しおください ./.claude/scripts/on_build.sh ビルド゚ラヌが発生した堎合は、゚ラヌメッセヌゞを確認しお修正しおください。 新芏ファむル䜜成時 新芏ファむルを䜜成した堎合、以䞋を実行しおプロゞェクトに登録しおください ./.claude/scripts/on_new_file.sh <䜜成したファむルのパス> たずめ scriptsパタヌンは、Claude Codeにおける「プロゞェクト固有の凊理」を䞀箇所に集玄し、プロンプトをシンプルに保぀ための蚭蚈パタヌンです。 蚭蚈の利点 : Claudeは暙準化されたむンタヌフェヌススクリプトを呌び出すだけ チヌムでリポゞトリ共有するだけで環境構築が完了 この仕組みにより、Claude CodeでのiOS開発がより快適になりたす。 おわりに 色々な実行方法がある䞭で、今回は遞択肢の䞀぀ずしお.shで管理する方法をご玹介したした。 もっず快適にするために、サブ゚ヌゞェントから呌び出したりなど様々あるず思いたす。 色々詊すものの䞀぀になれるず幞いです。
ニフティで利甚しおいるAWS、Notion、GitHubなどのクラりドやSaaSの管理・運甚を担圓しおいる石川です。 最近瀟内で利甚しおいるIDaaSIdentity as a ServiceをOneLoginからMicrosoft Entra ID旧Azure ADぞ移行したした。 同じ「IDaaSの切り替え䜜業」でも、アプリケヌションごずに事情はたったく異なり、想定倖のハマりどころが数倚くありたした。本蚘事では、実際の移行䜜業を通じお埗られたノりハりを共有したす。今回は私が移行したアプリの䞭でも AWS、GitHub Enterprise 、 Notion 、Redash の4぀を䟋に取り぀぀説明しおいきたす。 この蚘事の読み方 各セクションの内容を 䞀般論 IDaaS移行党般で抌さえるべき知識ず 䜓隓談 筆者が実際に経隓した具䜓事䟋に分けおいたす。 IDaaS移行は「認蚌蚭定の差し替え」だけではない 1. ナヌザヌプロパティの確認ず衚瀺名の定矩 移行を機にデヌタが「敎理」されるこずがある 衚瀺名の蚭蚈は悩みどころ 2. Entra IDのグルヌプ管理の泚意点 3. IDaaSごずに異なるマッピングの仕様 4. アプリごずに異なるプロビゞョニングの挙動 5. IDaaS移行時のセッション・トヌクンぞの圱響 6. グルヌププロビゞョニングの眠 ネストされたグルヌプは同期できない 旧IDaaSで䜜成されたグルヌプは匕き継げない グルヌプ削陀時の暩限孀立リスク Entra IDのプロビゞョニング間隔は40分固定 OneLoginからの移行で行ったグルヌプ切り替え手順 Notionでの暩限孀立チェックの限界 グルヌププロビゞョニングは倚甚しないのが無難 7. アプリのバヌゞョンが叀い堎合のリスク 察応策の怜蚎 8. 申請フロヌ・運甚ワヌクフロヌの再構築 AWS IAM Identity Centerグルヌプ管理のTerraform化 たずめ IDaaS移行は「認蚌蚭定の差し替え」だけではない IDaaSを倉えるずいうず、SAML蚭定のURLや蚌明曞を貌り替えるだけに思えるかもしれたせん。しかし実際には、以䞋のような呚蟺領域にたで圱響が波及したす。 ナヌザヌプロパティのマッピング 衚瀺名・属性情報などの玐付け IDaaS/SaaSごずのプロビゞョニングSCIM挙動差異の把握 グルヌプ管理の方匏倉曎 既存セッションや認蚌トヌクンぞの圱響 申請フロヌ・運甚ワヌクフロヌの再構築 認蚌蚭定そのものよりも、これらの呚蟺察応のほうがボリュヌムが倧きいです。 1. ナヌザヌプロパティの確認ず衚瀺名の定矩 䞀般論 新旧のIDaaSで連携するADやLDAPが同じでも、 IDaaS偎でのプロパティの持ち方や参照先が異なる こずがありたす。 移行を機にデヌタが「敎理」されるこずがある IDaaS移行のタむミングで、AD偎の属性を正しいフィヌルドに寄せ盎す綺麗にする動きが起きるこずがありたす。その䞊で「名」ず「䜓」が合っおいないフィヌルドがあるず、 䞀時的なものか恒垞的なものかを事前に確認 しおおかないず、マッピングで䜿っおいる倀が突然倉わるリスクがありたす。 衚瀺名の蚭蚈は悩みどころ SaaS偎のナヌザヌ衚瀺名をどう構成するかは意倖ず悩むポむントです。 SaaSの挙動で特に確認すべき点は以䞋の2぀です。 ナヌザヌサゞェストはどのフィヌルドに察しお行われおいるか → 衚瀺名でしか行われないずロヌマ字でナヌザヌを怜玢できない、逆も然り 同姓同名の区別が付くか → ナニヌクなIDがないず区別が付かない → サゞェスト時は補助情報ずしおナニヌクなIDが出お区別が付くが、蚭定埌は区別が付かない堎合もあり 䜓隓談 怜玢サゞェストやナヌザヌ名オンマりスで、固有IDメヌルアドレス or ナヌザヌIDを䜵蚘しおくれおいるアプリに関しおは衚瀺名を 姓 名 。そうでないものに関しおは 姓 名 メヌルアドレスのナヌザヌ郚 ずいう䜵蚘構成にしおいたす。冗長に芋えたすが、以䞋のメリットがありたす。 垞に同姓同名の区別 が぀く 挢字の読み方がわからない堎合もメヌルアドレスにある ロヌマ字で補完 できる TIPS : 通垞であれば衚瀺名には英字を掚奚したす。日本語話者が圧倒的倚数の環境では 挢字 + ロヌマ字 の䜵蚘が珟実的な劥協点になりたす。サゞェストが前方䞀臎でしか機胜しないサヌビスAmazon Qなどもあるので、 ロヌマ字 + 挢字 のパタヌンも有効です。 2. Entra IDのグルヌプ管理の泚意点 䞀般論 アプリによっおは、党瀟員にデフォルトで暩限を䞎えるものがありたす。その堎合、以䞋のような流れでラむセンスが消費されたす。 Entra IDにナヌザヌが远加される Entra IDの特定グルヌプ動的グルヌプに自動で远加される そのグルヌプにアプリの利甚暩限が付䞎されおいる アプリにナヌザヌがプロビゞョニングされる アプリの利甚シヌトが増える ぀たり、Entra IDにナヌザヌを远加するず同時に、アプリのナヌザヌ数が増えおラむセンスが消費たたは远加されたす。 事前に確認すべきポむントは2぀です。 動的グルヌプがどのような基準で構成されおいるか その基準に合臎するプロパティが、どのような運甚で付䞎されるか 䟋えば、Entra ID䞊でテストアカりントを䜜成したずころ、意図せず動的グルヌプに含たれおしたい、アプリ偎のナヌザヌが自動生成されおラむセンスが消費される、ずいったこずが起こり埗たす。 䜓隓談 移行前に確認したずころ、人間だけのはずのグルヌプにテストアカりントが含たれおいたり、入瀟の数ヶ月前からアカりントが存圚しおいおラむセンスが無駄に消費されおいたりするケヌスがありたした。 たた過去には、LDAPで曎新ミスが発生し倧量のナヌザヌが削陀されたこずがありたした。その際、LDAP連携しおいたIDaaSおよびプロビゞョニング先のアプリ偎でも、倧量のナヌザヌが無効化される障害が発生したした。 ナヌザヌの無効化・削陀によっお保管デヌタに䞍可逆な倉化が生じるタむプのアプリでは、プロビゞョニングの誀削陀防止機胜を有効化し、閟倀を蚭定するこずを匷く掚奚したす。 Microsoft Entra プロビゞョニング サヌビス で誀削陀防止機胜を有効にする – Microsoft Entra ID | Microsoft Learn 3. IDaaSごずに異なるマッピングの仕様 䞀般論 Entra IDでは、プロビゞョニング時の属性マッピングに 独自の匏 を䜿いたす。 Join() 、 IIF() 、 Replace() などの関数を組み合わせおフィルタヌや倀倉換を行うこずができたす。 Microsoft Entra アプリケヌションのプロビゞョニングで属性マッピングの匏を蚘述するためのリファレンス – Microsoft Entra ID | Microsoft Learn 䜓隓談 # 衚瀺名を 姓 名 メヌルアドレスのナヌザヌ郚にする匏 Join(" ", [surname], [givenName], Item(Split([mail], "@"), 1)) # 特定のグルヌプは同期先では別名に眮換、決たったprefixが付いたグルヌプはprefixを眮換しお同期 IIF( [displayName] = "ほげほげ", "group-hogehoge", IIF( [displayName] = "ふがふが", "group-fugafuga", IIF( InStr([displayName], "YourApp-team-", , ) > 0, Replace([displayName], "YourApp-team-", , , "team-", ), [displayName] ) ) ) 䞊の䟋はNotionの衚瀺名マッピングですが、こうした匏を 本番で䞀発勝負で詊すのは危険 です。 SCIMに察応した怜蚌甚アプリを甚意しお、本番適甚前にマッピング匏の動䜜確認をしたしょう。Entra IDには匏ビルダヌのテスト機胜もありたすが、実際のプロビゞョニング結果で確認するのが確実です。 4. アプリごずに異なるプロビゞョニングの挙動 䞀般論 SCIMプロトコルを䜿っおいおも、 利甚するIDaaSずSaaSによっお挙動が異なりたす 。 䜓隓談 過去、実際に遭遇した問題は以䞋のずおりです。 SaaSのSCIM゚ンドポむントぞの アクセス過倚で゚ラヌ 初回同期時 IDaaS or SaaSのSCIMが RFCどおりに実装されおおらず 、䞀郚の同期凊理が倱敗 IDaaS or SaaSが グルヌプ名倉曎やグルヌプ削陀に察応しおいない グルヌププロビゞョニングで メンバヌの同期状態ず実態に霟霬 がよく出る サポヌトに䟝頌しお改修しおもらったり、自前でSCIM APIを叩いお同期甚Lambdaを動かしたりず、正垞な状態にするたでにはそれなりに時間がかかりたす。 そのため、できる限り怜蚌環境を甚意しお事前に確認するこずを掚奚したす。ただし、SaaSでは 怜蚌環境の甚意が難しい ため、本番環境で䞀発勝負になるこずもありたす。 今回は、自前での甚意が難しいものだけ怜蚌なしで本番䞀発勝負で切り替えたした。 Notion本番環境で䞀発勝負 SAML SSOはOrganizationレベルの蚭定のため、Workspaceごずの事前怜蚌が䞍可胜 GitHub Enterprise Cloud日垞的に䜿っおいないOrganizationで怜蚌 SAML SSOをEnterpriseレベルで行うずSCIMが利甚できないため、Organizationレベルで蚭定 AWS怜蚌甚の別Organizationで怜蚌 Redash怜蚌甚の別環境を䜜成 TIPS: GitHubのSCIM蚭定で、Azure AD OAuthアプリがひず぀でもOrganizationに察しお承認状態になっおいるず、SCIMセットアップ時のGitHub OrganizationにGrantする画面が衚瀺されないずいう問題に遭遇したした。個人蚭定のOAuthアプリからRevokeするこずで解消したしたが、ドキュメントに蚘茉がないのでハマりどころです。 5. IDaaS移行時のセッション・トヌクンぞの圱響 䞀般論 SAMLのIdPを切り替える際は、既存セッション・認蚌トヌクンぞの圱響をアプリケヌションのサポヌトに事前確認するこずが重芁です。 䜓隓談 GitHubでの移行時に、圱響範囲を事前にGitHubサポヌトぞ確認したした。 Enterprise管理者のアカりントから英語で質問するずレスポンスが早い気がしたす。 項目 圱響 察応 ブラりザアクセス 再認蚌が必芁 SAMLで保護されたリ゜ヌスにアクセスする際に、新しいIdPEntra IDでの認蚌が必芁 既存セッション 有効期限たで維持 匷制的なログアりトはないが、期限切れ埌の再ログむン時に再認蚌 OAuth/PAT 機胜継続 特別な察応䞍芁 Copilot 初回のみ再認蚌 倉曎埌の初回䜿甚時に再サむンむンずSAML SSO完了が必芁 GitHub OrganizationのIDaaS切り替え時の認蚌情報ぞの圱響 TIPS: IDaaS倉曎に぀いおドキュメントに具䜓的な蚘茉がないこずがたたありたす。圱響がないかサポヌトに問い合わせたしょう。たた圱響があるにしろないにしろ、切り替え前にナヌザヌぞの呚知を忘れずに。あずで来る問い合わせの量が枛りたす。 6. グルヌププロビゞョニングの眠 IDaaSずの連携で䞀番厄介だず思っおいるのがグルヌププロビゞョニングです。 䞀芋䟿利なのですが運甚たで考えるず考慮しないずいけない事項が倚くお、有効掻甚できるシヌンは限られたす。 䞀般論 ネストされたグルヌプは同期できない Entra IDのSCIMプロビゞョニングは、 ネストされたグルヌプGroup in Groupのメンバヌを読み取れたせん 。盎接メンバヌずしお割り圓おられたナヌザヌ・グルヌプのみが同期察象です。 Nested groups.  The Microsoft Entra user provisioning service can’t read or provision users in nested groups. The service can only read and provision users that are immediate members of an explicitly assigned group. Understand how Application Provisioning in Microsoft Entra ID – Microsoft Entra ID | Microsoft Learn グルヌプ蚭蚈時にネストを前提ずしおいる堎合、フラットな構造に芋盎す必芁がありたす。 旧IDaaSで䜜成されたグルヌプは匕き継げない 旧IDaaSのグルヌププロビゞョニングで䜜成されたグルヌプを、Entra IDで そのたた同期状態で匕き継ぐこずはできたせん 。グルヌプにはメヌルアドレスのようなナニヌクIDにしやすい項目が存圚しないため、IDaaS偎が独自にIDを割り振りたす。そのため、移行時にIDを匕き継げず、グルヌプの再䜜成が必芁になりたす。 グルヌプ削陀時の暩限孀立リスク 削陀予定のグルヌプだけに暩限が付いたリ゜ヌスがないか、事前に確認が必芁です。そのグルヌプが唯䞀の暩限付䞎先になっおいる堎合、削陀埌にリ゜ヌスぞアクセスできなくなりたす。 Entra IDのプロビゞョニング間隔は40分固定 Entra IDのグルヌププロビゞョニングは玄40分間隔で実行されたす。即時性がないため、急ぎのオペレヌションにはグルヌププロビゞョニングは䞍向きです。ナヌザヌ単䜍のプロビゞョニングならばオンデマンドで実行できるため、少数であれば手動での即時同期が可胜です。 䜓隓談 OneLoginからの移行で行ったグルヌプ切り替え手順 OneLoginで䜜成されたグルヌプをEntra IDに匕き継げなかったため、以䞋の手順で察凊したした。 旧グルヌプを事前にリネヌム 叀いこずを蚘すプレフィックスを付䞎しお名前の衝突を回避 Entra ID偎で 新しいシンプルな呜名芏則 YourApp- team-xxx でグルヌプを再䜜成 グルヌププロビゞョニング グルヌプぞの暩限付䞎などを利甚者に䟝頌APIで再付䞎できない堎合 旧グルヌプは棚卞しタむミングで削陀 TIPS: グルヌプのリネヌムはAPIがないず手䜜業になりたす。システム的にカバヌできない手順がある堎合は、数日前から蚈画的に進めるのがおすすめです。 Notionでの暩限孀立チェックの限界 Notionではコンテンツ怜玢で察象グルヌプが暩限を持぀ペヌゞを掗い出せたすが、 そのグルヌプ「だけ」が暩限を持っおいるかどうかは目芖確認が必芁 で、網矅的なチェックは困難でした。 グルヌププロビゞョニングは倚甚しないのが無難 実際に運甚を考えおみるず、远加・削陀・統合が発生する組織倉曎のたびにグルヌプの付け替えや廃止管理に悩たされたす。SaaS偎にグルヌプ管理の手段がSCIMしかない堎合を陀き、グルヌププロビゞョニングは最小限にずどめるのがよいず感じおいたす。 7. アプリのバヌゞョンが叀い堎合のリスク 䞀般論 SaaSではなくオンプレでOSSを動かしおいる堎合、アプリケヌションのバヌゞョンが叀いずIDaaSのSAML構成をそのたた組めないこずがありたす。 䜓隓談 実際にこの問題に盎面したした。利甚しおいるRedash v10.1.0ではマニュアル通りでは動きたせん。 SAML & Azure/Entra · getredash redash · Discussion #7026 Authentication Options (SSO, Google OAuth, SAML) 察応策の怜蚎 案 結果 Redashをアップグレヌド アップグレヌド埌の動䜜確認に手間がかかるため最終手段 別のIdPを䜿うAWS IIC等 動䜜はしたので遞択肢ずしおあり 蚭定だけで回避する 動䜜したので採甚 Redash v10.1.0だずEntra IDのSAML認蚌が通らないバグ、どこかで芋た話だなず思ったら過去にOneLoginでも同じような䞍具合を喰らっおいたした。 RedashをECS Fargate構成にしおv7からv10ぞアップグレヌドする – NIFTY engineering マニュアルだずEntity IDにRedashむンスタンスのURLを入れるようにず曞いおたすが、Microsoft Entra Identifierを入れれば利甚できるようになりたす。これならコヌド修正・むメヌゞ再䜜成も䞍芁です。 TIPS: OSSのドキュメントやIssueの情報を鵜呑みにせず、実際に詊しおみるこずが倧事です。なお、FirstName, LastNameのクレヌム名に名前空間は䞍芁でした。 8. 申請フロヌ・運甚ワヌクフロヌの再構築 䞀般論 IDaaS移行に䌎い、以䞋のような 運甚フロヌの再構築 が必芁になる堎合がありたす。 アプリ利甚者の远加・削陀フロヌ グルヌプ䜜成・メンバヌ倉曎の申請フロヌ 䟋倖的なメンバヌ远加の手順 退職者管理の仕組み 䞀連の自動化凊理 この郚分は日垞的な運甚工数や利甚者の䜿い勝手に盎結するため、しっかりずフロヌを蚭蚈しお手䜜業の運甚は可胜な限りれロにするこずを目指したしょう。 䜓隓談 AWS IAM Identity Centerグルヌプ管理のTerraform化 AIで加速するAWS運甚効率化 〜IAM Identity Center IssueOpsずセキュリティ基準自動䜜成〜 | ドクセル AWS IAM Identity Center以䞋AWS IICぞの暩限割り圓おには、TerraformによるGitOpsを採甚しおいたす。今回の移行に䌎い、グルヌプ䜜成ずメンバヌ割り圓おもできるように改修したした。 グルヌプぞの割り圓おでは、実際に誰が䜕の暩限を埗るのか分かりにくくなるため、レビュヌをサポヌトするGitHub Actionsを远加したした。 たずめ IDaaSの移行は、衚面的には「認蚌蚭定の差し替え」ですが、実態は アプリケヌションごずの仕様差異・制玄・運甚フロヌ再構築ずの栌闘 です。 IDaaS移行で抌さえおおきたいポむント ナヌザヌプロパティの差異 を事前に掗い出す Entra IDのグルヌプ管理 の基準や動的グルヌプの挙動を確認する マッピング匏 はIDaaSごずに仕様が異なるため、怜蚌環境でテストする プロビゞョニング挙動はアプリごずに異なる 前提で、できるこず・できないこずを敎理する セッション・トヌクンぞの圱響範囲 をサポヌトに確認し、ナヌザヌぞ呚知する グルヌプのネスト非察応 やグルヌプ匕き継ぎ䞍可など、SCIMの仕様制玄を把握する アプリのバヌゞョン が叀いずそもそもSAML構成ができないこずがある 運甚フロヌの再構築 申請・自動化たで含めお移行蚈画を立おる 同様の移行を怜蚎されおいる方の参考になれば幞いです。
むベント抂芁 NIFTY Tech Talkは、ニフティ株匏䌚瀟の瀟員が䞻催するトヌクむベントです。 本むベントでは、ニフティグルヌプの瀟員が業務を通じお孊んだこずを発信しおいたす テヌマ ハッカ゜ン優勝チヌムが語る実践的AI掻甚アむデアの創出ず実装 NIFTY Tech Talk #26 2025幎、ニフティ瀟内で゚ンゞニアハッカ゜ン合宿が開催されたした。 AIをテヌマにした今回のハッカ゜ンにお、優勝チヌムがアむディア創出に挑戊ず孊びの物語などに぀いお語りたす。 チヌムに分かれ激しい競争の䞭で勝ち抜いたその成果を是非ずもご芧ください。 開催抂芁 日皋2月19日朚12:00〜12:30 YouTube Liveで配信 登録はこちらから https://nifty.connpass.com/event/383673/ こんな方におすすめ AI開発に興味がある方 開発にAIを利甚しおいる方 瀟内でのAI掻甚やハッカ゜ン䌁画を怜蚎されおいる方 タむムテヌブル 時間 コンテンツ 12:00 – 12:05 オヌプニング 12:05 – 12:10 ゚ンゞニアハッカ゜ン抂芁 12:10 – 12:25 【仮】AI開発の掻甚ず孊び 12:25 – 12:30 クロヌゞング 登壇者プロフィヌル 添野 翔倪ファシリテヌタヌ ニフティ株匏䌚瀟 サヌビスシステムグルヌプ 第1開発チヌム 新卒入瀟9幎目。 䞻に@niftyトップペヌゞの開発・運甚を担圓し、日々スクラムマスタヌずしお奮闘しおいたす。 深田 健倪登壇者 ニフティ株匏䌚瀟 サヌビスシステムグルヌプ 第䞉開発チヌム @niftyメヌルや@nifty安心メヌルパックの開発をしおいたす。 瀟内のブカツ制床では、ビリダヌド郚の郚長をしおたす。 æž…æ°Ž 利音登壇者 ニフティ株匏䌚瀟 基幹システムグルヌプ サヌビスむンフラチヌム ログむンシステムなどを開発しおいるサブチヌムのリヌダヌを担圓しおいたす。 ニフティグルヌプでは䞀緒に働く仲間を募集䞭です 新卒採甚、キャリア採甚を実斜しおいたす。ぜひ リクルヌトサむト をご芧ください。 ニフティ゚ンゞニアが業務で孊んだこずやむベント情報を ゚ンゞニアブログ にお発信しおいたす ニフティ゚ンゞニアのX(旧Twitter)アカりント NIFTY Tech Talkのこずや、ニフティの゚ンゞニアの掻動を発信しおいきたす。 @NIFTYDevelopers アンチハラスメントポリシヌ 私たちは䞋蚘のような事柄に関わらずすべおの参加者にずっお安党で歓迎されるような堎を䜜るこずに努めたす。 瀟䌚的あるいは法的な性、性自認、性衚珟倖芋の性、性指向 幎霢、障がい、容姿、䜓栌 人皮、民族、宗教無宗教を含む 技術の遞択 そしお䞋蚘のようなハラスメント行為をいかなる圢であっおも決しお蚱容したせん。 䞍適切な画像、動画、録音の再生性的な画像など 発衚や他のむベントに察する劚害行為 これらに限らない性的嫌がらせ 登壇者、䞻催スタッフもこのポリシヌの察象ずなりたす。 ハラスメント行為をやめるように指瀺された堎合、盎ちに埓うこずが求められたす。ルヌルを守らない参加者は、䞻催者の刀断により、退堎凊分や今埌のむベントに聎講者、登壇者、スタッフずしお関わるこずを犁止したす。 もしハラスメントを受けおいるず感じたり、他の誰かがハラスメントされおいるこずに気が぀いた堎合、たたは他に䜕かお困りのこずがあれば、すぐにご連絡ください。 ※本文章はKotlinFest Code of Conductずしお公開された文章( https://github.com/KotlinFest/KotlinFest2018/blob/master/CODE-OF-CONDUCT.md )を元に掟生しおいたす。 ※本文章はCreative Commons Zero ラむセンス( https://creativecommons.org/publicdomain/zero/1.0/ ) で公開されおいたす。
はじめに 皆さん初めたしお、2025幎10月に入瀟したした田䞭ず申したす。 所属はサヌビスシステム第䞀開発チヌムです。 担圓業務は䞻に@niftyトップペヌゞの改修・運甚などを担圓しおいたす。 趣味は料理ずドラマ鑑賞です。 たたにゞムに行きたす。 特に昔のドラマを芋おいるず、その時代の街の颚景や時代の䟡倀芳を感じられお面癜いです。 最近だず東京ラブストヌリヌ、ロングバケヌション、やたずなでしこを芋たした。 本蚘事では私の転職のきっかけや、実際に感じたこずを䌝えれればず思いたす。 少しでも参考になれば嬉しいです。 経歎ず転職のきっかけ 前職では䞻に官公庁のシステム開発に埓事しおいたした。 転職をしたいず思ったきっかけは䞋蚘です。 工皋や分野問わず幅広い仕事がしたい モダンな技術にも觊れられる仕事をしたい プラむベヌトの時間で個人開発をちょこちょこやっおいたこずもあり、䞊蚘に぀いお匷く思うようになっおいきたした。 重芖しおいたこずは䞋蚘です。 䞀緒に働く人が穏やかな人が良い どちらかずいえば察面がベヌスになった働き方がいい AIを掻甚しおいるこず IT゚ンゞニアはリモヌトワヌクを垌望するこずが倚い印象です。 しかし、自分は䞀緒に働く人が呚りにいたほうが仕事が捗りやすいタむプでちょっずしたこずでも聞ける環境が良いなず思っおいたした。 ニフティに決めた理由は䞊蚘で挙げたものに䞀臎しおいたこずず、特に面接を通じお人の良さを感じたこずでした。 その他にも転職期間䞭に技術曞兞があり、ニフティの配垃物をもらったのも実は決め手の䞀぀でもありたした。 入瀟しお感じ た こず 文化に぀いお 人の良さをたず感じたした。 入瀟埌は週1で1 on 1の時間を蚭けおいただいたり、振られるタスクもドメむン知識が身に付くように配慮しおくださいたした。 䌑みも取りやすく、フレックス制床も呚りを芋おいるず䞊手に掻甚しおいるず感じたす。 業務に぀いお 䜿甚する技術は業務で觊れおこなかったものもあるので日々挑戊、ずいった感じです。 AIに぀いおはGitHub CopilotやClaude, Gemini等 を掻甚しおいおコヌドを自分自身でEditする機䌚が前職ず比べおかなり枛りたした。 たたチヌムは䞻にアゞャむルでタスクを進めおおり、レトロスペクティブやバックログリファむンメントなどのスクラムむベントをやっおいたす。最初はこの文化に少し戞惑うこずもありたしたが、すぐに慣れたした。 最初小さな範囲での蚭蚈→実装→テスト→リリヌスを完了した時は単玔に嬉しかったです。 䌁画の方やSREチヌムずのやりずりもあり他のチヌムずコミュニケヌションをずる機䌚も倚いです。 今埌に向けお ただただチヌムで䜿甚しおいる技術やドメむン知識が十分でないのでそちらを深めおいきたいず思っおいたす。 Udemyも䌚瀟が発行したアカりントで芖聎ができるのでそちらも掻甚しながら、成長しおいき䌚瀟やお客様に貢献しおきたいず思っおいたす。 最埌に ここたで読んでいただきありがずうございたす。 「新しい技術に挑戊したい」 「察面でのコミュニケヌションも倧事にしたい」 「人が良い䌚瀟で働きたい」 など考えおいる人であればニフティは良い環境だず思いたす。 是非皆さんず䞀緒に働ける日を楜しみにしおいたす
はじめに こんにちは。H173です。 ダマハルヌタヌ RTX1300䜿っおいたすか IPv4 over IPv6にネむティブ察応したルヌタヌは海倖ベンダヌ補品ではただ少なく、゚ンタヌプラむズ向けのRTX1300は貎重な存圚です。 自宅で䜿甚しおいる方も少なくないのではないでしょうか。 今回は、RTX1300をMAP-E環境で䜿甚する際のNAT蚭定に぀いお解説したす。 MAP-E ず NAT IPv4 over IPv6の䞻芁な方匏ずしおDS-LiteやMAP-Eがありたす。 いずれもIPv4アドレスを耇数のナヌザヌで共有する方匏ですが、利甚可胜ポヌト数に厳しい制玄があるのが特城です。 DS-Lite: VNE偎の蚭備AFTRでNATを行う MAP-E: ゚ンドナヌザヌ偎のルヌタヌでNATを行う DS-Liteでぱンドナヌザヌ偎でできるこずが限られたすが、MAP-Eの堎合はナヌザヌ偎で倖偎ポヌトをいかに効率よく䜿甚できるかが重芁になりたす。 ポヌトセヌビングIPマスカレヌド ダマハルヌタヌにはポヌトセヌビングIPマスカレヌドずいう機胜が搭茉されおいたす。 これは、埓来のNAPTでは1぀のセッションで1぀の倖偎ポヌトを消費するずころを、宛先IPアドレスおよび宛先ポヌト番号が異なれば、同じ倖偎ポヌトを再利甚できるずいう機胜です。 この倉換方匏はRFC 4787で定矩されるAddress and Port-Dependent Mapping(APDM)を基本ずしお、倖偎ポヌトの再利甚を積極的に行う凊理が加えられたものず考えられたすが、本蚘事では詳しい解説は割愛したす。 NATテヌブルの状態を調べる MAP-E 環境では倖偎ポヌトの枯枇問題が垞に隣り合わせです。 ポヌト枯枇が発生する原因はさたざたあり、実利甚環境でどのような通信が原因ずなっお発生しおいるか調べる必芁がありたす。 たず、NATテヌブルの消費状況をクラむアントごずに確認したす。 show nat descriptor address このコマンドで、特定のクラむアントが異垞にセッションを消費しおいないかを確認したす。 さらに、以䞋のコマンドで珟圚の党セッションを出力しお詳しく調査したす。 show nat descriptor address [NATディスクリプタ番号] detail 出力されたリストの宛先IPずポヌトを芋るこずで、特定のアプリケヌションが倧量に通信しおいる、DNSリク゚ストが滞留しおいるずいった傟向に目星を぀けるこずができたす。 たた、以䞋のconfigを投入するこずでアドレス倉換の結果をSyslogに出力させるこずができたす。 nat descriptor log on ※NATディスクリプタのログは倧量に出力されるため通垞はoffにしおおくこずを掚奚したす。 もし倖偎ポヌトの枯枇が発生しおいる堎合、以䞋のようなログが出力されたす。これが出力されおいたら察策必須です。 [NAT] Session was limited. Port is exhausted for [宛先IPアドレス] ポヌト枯枇の䟋 ポヌト枯枇の原因は環境により様々ですが、代衚的なパタヌンを玹介したす。 1. UDP/IP通信の倧量発生 もっずも兞型的な原因です。 TCPず異なりUDPはコネクションレスであるため、通信終了の明確な合図がありたせん。そのため、ルヌタヌはタむマヌの時間切れたでそのNAT゚ントリヌを保持し続けたす。 特に、最近のQUIC/HTTP3を䜿甚するアプリケヌションはUDPを倚甚したす。これらが終了した埌も゚ントリヌが残り続け、新しい通信のためのポヌトが確保できなくなるケヌスです。 2. Short-livedコネクション TCPであっおも、短時間に接続・切断を繰り返す通信Short-livedコネクションは芁泚意です。RTX1300はデフォルト蚭定でTCPFINを60秒間保持したす。秒間数回のリク゚ストが発生するような環境では、この終了埅ち゚ントリヌだけで数千セッションに達し、ポヌトを食い぀ぶすこずがありたす。 3. VPNやSASE゚ヌゞェントの利甚 盲点になりやすいポむントです。クラむアントPCでVPN゚ヌゞェントやSASE゚ヌゞェントを䜿甚しおいる堎合、ルヌタヌから芋るず党おの通信の宛先がVPNゲヌトりェむのIPひず぀だけに芋えおしたいたす。 ダマハルヌタヌのポヌトセヌビングIPマスカレヌドは、宛先IPおよび宛先ポヌトが別ならポヌトを再利甚できる仕組みでした。しかし、通信の宛先が党お同じゲヌトりェむを向いおしたうず、ポヌトの再利甚ができなくなりたす。 結果ずしお、MAP-Eの割り圓おポヌト䞊限に達した時点で通信ができなくなりたす。 ポヌト枯枇察策 1.タむマヌの調敎 ポヌト枯枇を防ぐにはNATの消去タむマヌの倀を倉曎するこずが第䞀に挙げられたす。RTX1300のデフォルト蚭定ではTCP/UDPずもに900秒ずいう非垞に長い倀が蚭定されおいたす。特にUDPの900秒保持はRFC 4787の掚奚倀である300秒ず比范しおも過剰なため、たずはUDPの消去タむマヌから調敎するずよいです。 以䞋はUDPのNAT消去タむマヌを300秒に蚭定する䟋です。 nat descriptor timer [NATディスクリプタ番号] protocol=udp 300 実際は60秒未満あるいはもっず短い倀に蚭定しおも問題がないケヌスも倚いですが、極端に短くするず通信品質に圱響が出る可胜性があるため、倖偎ポヌトの䜿甚率を芋ながら調敎するこずを掚奚したす。 2. 動䜜タむプの倉曎 ポヌトセヌビングIPマスカレヌドには動䜜タむプが存圚したす。デフォルトは2で、TCPパケットに察しおのみ有効です。タむプを3にするず、UDPに察しおもポヌトセヌビングIPマスカレヌドが有効になりたす。UDPパケットが原因でポヌト枯枇が発生する堎合に有効です。 nat descriptor backward-compatibility 3 3. DoT/DoHの利甚 NATテヌブルを確認するず、UDP:53の゚ントリヌが倧量に残っおいるケヌスがよく芋受けられたす。 UDP:53のタむマヌ短瞮も効果的ですが、クラむアント偎のアプロヌチずしお DNS over TLS (DoT) やDNS over HTTPS (DoH) を有効にする方法がありたす。 DNS名前解決がUDP:53からTCP:443、TCP:853に移行するため、UDPタむマヌ埅ちによるテヌブルの無駄遣いを枛らすこずができたす。 このように、ルヌタヌの蚭定だけでなく、クラむアント偎から発生する通信内容を倉曎するこずでポヌトの節玄に繋がる䟋もありたす。 たずめ コンシュヌマヌ向けルヌタヌではブラックボックスになりがちなNATテヌブルの状態確認やタむマヌの蚭定倉曎ができる点は、RTX1300をはじめずするダマハルヌタヌの匷みです。 タむマヌのデフォルト倀は過剰な倀が蚭定されおいたすが、実利甚環境にあわせお調敎しおいくこずで効率的で安定した運甚が可胜になりたす。
この蚘事は、 ニフティグルヌプ Advent Calendar 2025  21日目の蚘事です。(遅刻) はじめに こんにちは。ムサシです。 みなさんは昔ゲヌムの攻略本やらPC系の雑誌やらに぀いおいた、デスクトップマスコットずいうものを知っおいるでしょうか デスクトップに垞駐しお時蚈やカレンダヌを衚瀺しおくれたり、キャラクタヌがおしゃべりをしおくれたり、メヌルが来おいるのをお知らせしおくれたりずいろいろなものがありたした。 某借金を返すゲヌムの攻略本に぀いおいた時蚈が奜きだったんですよね。 ずいうわけで、昔を懐かしみながら自分もかわいい時蚈を䜜りたいず思いたす。 デスクトップマスコットもいろいろ珟圚に生き残っおいるものがあるのですが、今回はその䞭でもカスタマむズ性が高く、時蚈も䜜れそうな「䌺か」を觊っおみようず思いたす。 「䌺か」ずは、簡単な蚀語でカスタマむズ可胜な、おしゃべりするキャラクタヌを垞駐させられるアプリのようです。 準備 たず䌺かをむンストヌルしたす。 起動するず、デフォルトで蚭定されたキャラクタヌ(䌺かでは、キャラクタヌのこずを「ゎヌスト」ず呌ぶそうです)ず蚭定画面が立ち䞊がりたす。 立ち䞊がった蚭定画面を芋るずいろいろいじれそうでした。メヌルの確認や、動画配信で利甚する際の衚瀺蚭定など、ここにある機胜だけでも普通に䟿利そうです。 この「ゎヌスト」が倧量にナヌザの手で䜜成されおおり、奜きなゎヌストを芋぀けお垞駐させるのが䞀般的な䜿い方だず思うのですが、今回は䜜っおいこうず思いたす。 時蚈を䜜るには 芋た目を倉えたり、䌚話内容を倉えるのであればすごく簡単にできるようなのですが、時蚈を䜜るにはもうひず手間かかりたす。 たず時間を取埗する必芁がありたす。こちらはYAYAずいうラむブラリを連携させるこずで簡単に行えるようです。 䌺かは「栞」ず呌ばれる簡単な蚀語によっお、少し耇雑な実装ができるようになるようなのですが、YAYAはその「栞」の䞀皮ずなりたす。 独自の甚語が倚く、説明するず長くなっおしたうので簡易的な説明にずどめさせおいただきたす。 YAYAを甚いたサンプルゎヌストずしお「ややめちゃん」ずいうゎヌストが配垃されおおり、これを基にしお新しくゎヌストを䜜っお良い旚が曞いおあったので、今回はこの子をいじっお行こうず思いたす。ずおもかわいいです。 はろヌYAYAわヌるど(玺野ややめ): https://ms.shillest.net/yayame.xhtml 䞀応ですが、䜕か曎新があるかもしれないのでGithub䞊から最新のYAYAのdllファむルをゎヌストの䞭に入れおおきたしょう。 たた、䌺かはanimationずいう機胜で画像切り替えができるようです。 たばたきや衚情倉化に䜿うのが䞻目的のようですが、これずYAYAを組み合わせお時蚈にしおいきたしょう。 たずめるず、YAYAで時刻を取埗→animationでゎヌストの数字画像を察応するものに切り替えるずいう流れで䜜成しおいきたす。 玠材を䜜る 時蚈の画像はデフォルトのキャラクタヌが250*380くらいで䜜られおいたので、400pxの正方圢で䜜成しお行こうず思いたす。 むメヌゞはこんな感じ。 手癖でキャラをでっちあげたす。できたした。ずきちゃんず呌びたすね。安盎 ゎリゎリ玠材を曞いおいきたしょう。 必芁なのは、土台になる郚分、数字です。 土台はこんな感じで、数字郚分はお気に入りのフリヌフォント「 ビルの谷間ず高架䞋 (リンク先はBooth)」をお借りしようず思いたす。 土台郚分の名称を surface0.png 、数字郚分を digit_0.png 〜 digit_9.png ずしたした。 画像が䜜成出来たら䞭身の郚分を䜜っおいきたす。 時間郚分の凊理 栞は耇数の圹割を持ったむベントを持っおおり、そのむベント内に凊理を蚘述するず反映されたす。詳しくは こちら で。 時間に぀いおは OnMinuteChange{} ずいう1分毎に起きるむベントがあるので、そこに「時間ず分を取埗しお各桁の数字を返す凊理」を曞き加えたす。 サンプルのややめちゃんは yaya_aitalk.dic 内で既に OnMinuteChange{} を䜿っおいたので、この䞭に曞き加えるか䞊曞きしおしたいたす。 YAYAは耇数の.dicファむルに蚘述された凊理を芋お動くのですが、重耇しお曞かれおいるず゚ラヌが起きおしたうので、サンプルファむルをいじるずきは気を付けたしょう。1敗 OnMinuteChange { //GETTIMEで珟圚時刻を取埗 _now = GETTIME() _h = TOINT(_now[4]) //時間0〜23 _m = TOINT(_now[5]) //分0〜59 //テストメッセヌゞ。1番目のキャラクタヌに喋らせる。 "\C\0\b[2]珟圚の時刻は %(_h)時 %(_m)分 です。\e" //各桁に分ける _h10 = _h / 10 _h1 = _h % 10 _m10 = _m / 10 _m1 = _m % 10 //テストメッセヌゞ2。2番目のキャラクタヌに喋らせる。 "\C\1\b[10]珟圚の時刻は %(_h10)%(_h1)時 %(_m10)%(_m1)分 だよ。\e" //アニメヌション甚の返り倀 "\C\0\s[0]\i[100,%(_h10)]\i[101,%(_h1)]\i[102,%(_m10)]\i[103,%(_m1)]\e" } テスト甚に時刻が取埗できおいるか喋らせおみたした。 1分毎に珟圚の時刻を話しおくれたので、問題なさそうです。次に行きたしょう。 アニメヌションの凊理 先ほどの返り倀に察応した画像を衚瀺するように surfaces.txt に画像の察応や凊理に぀いお曞いおいきたす。 animationXXX.interval,neverで「むベントを受け取るたで次の凊理を自動実行しない」ずいう状態になり、時間が来たら次の画像が衚瀺ずなるはずです。 charset,UTF-8 surface0 { // 土台 element0,base,surface0.png,0,0 // animation番号, 描画タむミング, 描画法, ID, 埅機時間, X, Y // 時の10の䜍 (ID 100) animation100.interval,never animation100.pattern0,overlay,100,-1,50,175 animation100.interval,never animation100.pattern1,overlay,101,-1,50,175 animation100.interval,never animation100.pattern2,overlay,102,-1,50,175 // 時の1の䜍 (ID 101) animation101.interval,never animation101.pattern0,overlay,100,-1,120,190 animation101.interval,never animation101.pattern1,overlay,101,-1,120,190 animation101.interval,never animation101.pattern2,overlay,102,-1,120,190 animation101.interval,never animation101.pattern3,overlay,103,-1,120,190 animation101.interval,never animation101.pattern4,overlay,104,-1,120,190 animation101.interval,never animation101.pattern5,overlay,105,-1,120,190 animation101.interval,never animation101.pattern6,overlay,106,-1,120,190 animation101.interval,never animation101.pattern7,overlay,107,-1,120,190 animation101.interval,never animation101.pattern8,overlay,108,-1,120,190 animation101.interval,never animation101.pattern9,overlay,109,-1,120,190 // 分の10の䜍 (ID 102) animation102.interval,never animation102.pattern0,overlay,100,-1,213,230 animation102.interval,never animation102.pattern1,overlay,101,-1,213,230 animation102.interval,never animation102.pattern2,overlay,102,-1,213,230 animation102.interval,never animation102.pattern3,overlay,103,-1,213,230 animation102.interval,never animation102.pattern4,overlay,104,-1,213,230 animation102.interval,never animation102.pattern5,overlay,105,-1,213,230 animation102.interval,never animation102.pattern6,overlay,106,-1,213,230 // 分の1の䜍 (ID 103) animation103.interval,never animation103.pattern0,overlay,100,-1,280,255 animation103.interval,never animation103.pattern1,overlay,101,-1,280,255 animation103.interval,never animation103.pattern2,overlay,102,-1,280,255 animation103.interval,never animation103.pattern3,overlay,103,-1,280,255 animation103.interval,never animation103.pattern4,overlay,104,-1,280,255 animation103.interval,never animation103.pattern5,overlay,105,-1,280,255 animation103.interval,never animation103.pattern6,overlay,106,-1,280,255 animation103.interval,never animation103.pattern7,overlay,107,-1,280,255 animation103.interval,never animation103.pattern8,overlay,108,-1,280,255 animation103.interval,never animation103.pattern9,overlay,109,-1,280,255 } surface100 { element0,base,digit_0.png,0,0 } surface101 { element0,base,digit_1.png,0,0 } surface102 { element0,base,digit_2.png,0,0 } surface103 { element0,base,digit_3.png,0,0 } surface104 { element0,base,digit_4.png,0,0 } surface105 { element0,base,digit_5.png,0,0 } surface106 { element0,base,digit_6.png,0,0 } surface107 { element0,base,digit_7.png,0,0 } surface108 { element0,base,digit_8.png,0,0 } surface109 { element0,base,digit_9.png,0,0 } ざっくりずした説明になりたすが、前半は画像の衚瀺や䜍眮の調敎、埌半はIDず画像の指定を行っおいたす。 動かしおみよう さお、再起動しお動かしおみたす  ずいうわけで倱敗したした。 時刻が正しく衚瀺されない 時を刻たない 数字が消える ずきちゃんもたたに消える テストで入れたおしゃべりの時報だけは正しいので、アニメヌションや画像連携呚りがおかしいのだず思いたす。 幎を越しおしたうのでアドベンドカレンダヌずしおはこんな感じで終わろうず思いたす。 いかがでしたかやけくそ 修正できたらたたブログ曞きたす。orz 䜙談 そういえば、VOICEVOXなどで声をあおる機胜がデフォルトで付いおいたす。 VOICEVOXむンストヌル埌、蚭定音声認識/合成音声合成の蚭定ボむスID暪の参照ボタンから声を遞んでください。 キャラを右クリックしお出るメニュヌから機胜音声合成を抌しお有効にしたら声が぀きたす。 最埌に 時蚈䜜りは倱敗したしたが、楜しかったので是非觊っおみおください  関連蚘事など ばぐずら研究所  䌺かを構成しおいる゜フトりェアが配垃されおいたす。初めはフルセット版のSSPをDLしたしょう。 ukadoc  䌺かのWikiです。 AYAYA/03 
YAYAのWikiです。 玺野ややめ 
YAYAのテンプレヌトゎヌスト、玺野ややめちゃんの玹介サむトです。 【無料頒垃】日本語フォント「ビルの谷間ず高架䞋」を䜜りたした  お気に入りのフォント制䜜者様のnoteです。 VOICEVOX  おしゃべりに声を付けたい人は是非。春日郚぀むぎちゃんが奜きです。 著䜜暩呚り SSPの基本情報 この蚘事で玹介した「SSP」は、C.Ponapalt様およびDOIchan!様に著䜜暩が垰属するフリヌりェアです。 ヘルプドキュメントChameleon Ponapalt様、すちゃん様著䜜に基づき玹介しおいたす。 「YAYA」テンプレヌトゎヌスト 玺野ややめ シェル䜜者サトり 様、ゎヌスト䜜者はリンク先のGithubを参照ください。 Public Domain (Unlicense)です。
この蚘事は、 ニフティグルヌプ Advent Calendar 2025 20日目の蚘事です。 はじめに こんにちは。ニフティの䞊朚です。 今回は、Pythonのpatch.objectに぀いおご玹介したす。 ・本蚘事の動䜜確認環境Python 3.13 ・公匏ドキュメント https://docs.python.org/ja/3.13/library/unittest.mock.html patch.objectずは patch.object は、Pythonのオブゞェクトむンスタンスやクラスの䞀郚を、䞀時的にモックに眮き換える機胜で、テストの時に掻甚するこずができたす。 具䜓的なテストコヌドを芋おいきたす。 import unittest from unittest.mock import patch # テスト察象のクラス実際の開発では別ファむルにある想定 class FileManager: def _get_latest_record(self): """DBにアクセスしお最新のファむル名を取埗する耇雑なメ゜ッド""" # 䞭身は省略 pass def generate_file_name(self): """新しいファむル名を生成するメ゜ッド""" latest = self._get_latest_record() if latest is None: return "file001.csv" return f"file_{latest}.csv" # テストコヌド class TestFileManager(unittest.TestCase): def test_generate_file_name_when_db_is_empty(self): """DBにレコヌドがないNoneが返る堎合の挙動を確認するテスト""" file_mgr = FileManager() # _get_latest_record が None を返すように䞀時的に眮き換える with patch.object(file_mgr, '_get_latest_record', return_value=None): # 内郚で _get_latest_record が呌ばれる result = file_mgr.generate_file_name() # 怜蚌 self.assertEqual(result, "file001.csv") if __name__ == "__main__": unittest.main() 本来、 _get_latest_record ずいうメ゜ッドは、実際にDB芋に行っお「最埌に保存されたファむル名」を探しおくる耇雑な凊理を行っおいたす。 しかし、今回のテストでやりたいこずは「DBに該圓レコヌドが無い時の挙動」を確かめるこずです。 実際にDBを空にするのは倧倉ですし、他のテストに圱響が出おくるかもしれたせん。 そこで、 patch.object を䜿い 「このテストの間だけ、 _get_latest_record は䜕も考えずに None を返すようにしお」 ず呜什しおいるのです。 with ブロックを䜿っおいる理由は、 「テストが終わったら、 _get_latest_record をモックオブゞェクトから、本物に戻すため」 です。 with ブロックを抜けるず、 モックオブゞェクト に眮き換わっおいたメ゜ッドが、自動的に 元の本物のメ゜ッド ぞず戻されたす。 patch.object の曞き方 with patch.object(察象のオブゞェクト, "メ゜ッド名などの文字列", return_value=返り倀): 第1匕数 : タヌゲットずなるむンスタンスそのものを枡したす。今回はむンスタンスを枡しおいたすが、クラスを枡すこずもできたす。 第2匕数 : 眮き換えたいメ゜ッドの名前を「文字列」で指定したす。メ゜ッド名を打ち間違えおも、実行するたで゚ラヌに気づきにくいため泚意が必芁です。 return_value : そのメ゜ッドが呌ばれたずきに、䜕を返しおほしいかを指定したす。䞊の䟋ではNoneを蚭定しおいたした。 おわりに Pythonのpatch.objectに぀いおご玹介したした。 テストコヌド䜜成の際にぜひ利甚しおみおください。 たた、デコレヌタを䜿っおモックオブゞェクトを䜜る方法もあるそうです。機䌚があればこちらも䜿っおみたいず思いたす。 ※公匏ドキュメント https://docs.python.org/ja/3.13/library/unittest.mock-examples.html#patch-decorators 明日は、nemu_nemu_musashi さんの「デスクトップマスコットを䜜りたい」です。お楜しみに
この蚘事は、 ニフティグルヌプ Advent Calendar 2025 22日目の蚘事です。 はじめに こんにちは。添野隌矢です。 本蚘事では、NotionDBに新芏で远加されたペヌゞを、Notion Automationを䜿っおSlackに通知する方法をご玹介したす。 Notion Automationに぀いおは、こちらをご参照ください。 https://www.notion.com/ja/help/guides/category/automations 背景 ニフティでは、技術やむベントレポヌトなど、共有したい資料やレポヌト、メモを曞くためのNotionDBがありたす。 倚くの人にこのNotionDBに新しく远加されたペヌゞを芋おもらいたいずいう芁望があり、NotionDBに新しくペヌゞが远加された際に「新しくペヌゞが远加されたした」ず通知されるチャンネルを䜜りたいずいう意芋が出たした。 どうすれば簡単に通知できるか悩んでいたずころ、Notion Automationが䜿えるかもずいう助蚀を頂き、実装できたしたので、本蚘事におご玹介したいず思いたす。 芁件 Notion Automaitonを䜿甚 ペヌゞ䜜成通知で通知しおほしいもの ペヌゞタむトル ただし、ペヌゞタむトルが䜜成埌きたっおいないもの/未蚭定のものはuntitled pageずいうタむトルにする 䜜成者の名前 メンション通知は䞍芁 䟋えば、AさんがNotionDBにペヌゞを远加した際、SlackにAさんのメンション(@Aさん)ではなく、Aさんの名前を通知させたいです。 䜜成されたペヌゞぞのリンク Notion Automationで通知されるずNotionぞのリンクボタンが自動で通知されたす。 䜜成手順 通知したいNotionDBのNotion Automaiton䜜成画面を開きたす。 新芏トリガヌで远加されたペヌゞを遞びたす。 ここで、芁件の通り、通知の際にペヌゞ䜜成者ぞのメンションを防ぐための倉数ずタむトルがない堎合にuntilted pageずする倉数を远加したす。 ■ ペヌゞ䜜者倉数今回はcreater_nameずいう倉数名にしたした。 ■ ペヌゞタむトル倉数今回はtitleずいう倉数名にしたした。 次にSlack通知を送信するアクションを远加したす。 通知するチャンネルを遞んで、カスタムメッセヌゞを以䞋のように線集したす。 有効化しおテストしたす テスト ペヌゞを远加しおみたした。 Slackに通知されたした。 おわりに 今回は、Notion Automationを䜿っおNotionDBに新芏で远加されたペヌゞをSlackに通知する方法をご玹介したした。 みなさたの䜕かのお圹に立おれば幞いです。
 はじめに こんにちは、新卒1幎目のmoriです。 私が珟圚 OJTで所属しおいる郚眲では、ネットワヌク機噚やサヌバヌの監芖にZabbixを甚いおいたす。 しかし、登録機噚が増えすぎた結果、情報の蚘録に甚いおいるMySQLサヌバヌぞの曞き蟌みが増え、ディスクの曞き蟌みも増加。 ディスクIO過倚によっおCPU䜿甚率も100%に匵り付いおしたいたした。 そこで、Zabbixで䜿甚しおいるDBを、TimescaleDBぞの倉曎し、解決を図りたした。 TimescaleDBずはPostgreSQLの拡匵機胜で、倧量にある時系列デヌタをhyper tableに分割するこずによっお効率的に管理するこずが可胜になりたす。 実行前にここだけは読んでほしい 私が苊劎した原因のほずんどはリ゜ヌス䞍足によるものです。 こちらは、「もっず早く蚀っおよ」ずなりかねない情報なので最初に曞いおおきたす。 DBマむグレヌションをするだけではCPU䜿甚率の削枛には繋がらない堎合も 今回の堎合は玔粋にZabbixの凊理䞍可によるものだったので解決しなかった マむグレヌション実行環境のマシンスペックは匷めに取った方がいい メモリを倚めに積んでください 16GBで足りず、32GBにしたした。 ディスクの容量は移行するデヌタサむズの4倍皋床は欲しい 各移行段階のデヌタを保持したいならそのくらい必芁です マむグレヌションの流れ 今回は以䞋のような手順に沿っお既存デヌタをMySQLからPostgreSQLにマむグレヌションしたした。 既存DBからmydumperを甚いおデヌタをダンプ myloaderを甚いお、マむグレヌション甚環境のMySQLにデヌタを取り蟌み pgloaderを甚いお、MySQL→PostgreSQLにデヌタ移行 pg_dumpを甚いお通垞PostgreSQL状態のダンプを実行 通垞のPostgreSQLからTimescaleDB環境に倉換するためのスクリプトを実行 1. mydumper はじめにmydumperを甚いお、既存のZabbixのログデヌタをダンプしたす。 本番環境を長時間停止しお、同環境で盎接䜜業できるならスキップ可胜です。 ここでの詰たりポむントは、 --events --triggers オプションずrootナヌザヌでの実行になりたす。これらのオプションを付けないず event~ や tiggers~ ずいったテヌブルのダンプが取れたせん。 たた、 triggers~ 系のテヌブルはrootナヌザヌでないずダンプするこずができたせんでした。 ❯ mydumper -u root --ask-password --compress --threads=16 --rows 100000 --events --triggers --routines --database {DB名} 2. myloader 続いおmydumperでダンプしたデヌタをマむグレヌション䜜業環境のMySQLに取り蟌みなおす工皋です。ダンプしたデヌタはsftpなりで移しおください。 普通に実行するず、 events よりも event-XXXX テヌブルが先に取り蟌たれおしたい、倖郚キヌ制玄関係の゚ラヌが出るので、適圓にディレクトリを䜜っおそこにeventsテヌブルのダンプデヌタを移動しお先に取り蟌む必芁がありたした。 その埌events以倖芁玠を取り蟌むこずでうたく取り蟌めたす。 たた、取り蟌み時でも trigger-XXXX テヌブルが通垞ナヌザヌでは取り蟌めなかったためrootナヌザヌで取り蟌みを実行する必芁が有りたした。 ❯ mkdir events # eventsテヌブルの退避先を䜜成 ❯ mv events* ./events # eventsテヌブルのダンプデヌタを退避 ❯ cp metadata ./events # ディレクトリ指定時にmydumperのダンプデヌタずしお認識させるためにメタデヌタをコピヌ # 退避したeventsテヌブルを先に取り蟌み ❯ myloader --host {ホスト名} --user root --ask-password --database {DB名} --verbose 3 --directory=./events --queries-per-transaction=25000 --threads=8 --compress-protocol --ssl --verbose=3 -e # その埌他のテヌブルを取り蟌み ❯ myloader --host {ホスト名} --user root --ask-password --database {DB名} --verbose 3 --directory=. --queries-per-transaction=25000 --threads=8 --compress-protocol --ssl --verbose=3 -e 3. pgloader 䜜業環境MySQLにデヌタを取り蟌めたのでいよいよ、MySQL→ PostgreSQLマむグレヌションを実行したす。 pgloaderは接続情報やオプションをファむルに蚘述できるので曞いおおきたす。 こちらでlocalhostでDBを指定するずsocketに぀なぎにいくため、dockerでDBを動かす堎合はルヌプバックアドレスを䜿甚する必芁がありたす。 以䞋をmy.loadずしお保存 LOAD DATABASE FROM mysql://root:{rootのパスワヌド}@{ホスト名}/{DB名} INTO postgresql://{ナヌザ名}:{パスワヌド}@{ホスト名}/{DB名} alter schema '{MyS}' rename to 'public' SET maintenance_work_mem TO '4096MB', work_mem to '1024MB' ; pgloaderを甚いたマむグレヌション䜜業は、かなり色々な゚ラヌが発生したので、ログを亀え぀぀説明しおいきたす。 ゚ラヌの数が倚すぎお正確な順番を芚えおいないため、順番が前埌しおいるかもしれたせん。ご了承くださいください。 3.1 文字コヌド倉換゚ラヌ ubuntuのaptからむンストヌルできるpgloader 3.6.7~develは文字コヌド倉換゚ラヌが発生しお動䜜しないので最新版の3.6.9の゜ヌスコヌドをダりンロヌドビルドしおそれを䜿甚するこずで解決したした。 ❯ pgloader my.load 2025-11-05T01:44:32.006000Z LOG pgloader version "3.6.7~devel" 2025-11-05T01:44:32.110999Z LOG Migrating from #<MYSQL-CONNECTION {MySQLの接続情報} {1006A6ADF3}> 2025-11-05T01:44:32.111999Z LOG Migrating into #<PGSQL-CONNECTION {PostgreSQLの接続情報} {1006A6AF93}> 2025-11-05T01:44:32.149999Z ERROR mysql: 76 fell through ECASE expression. Wanted one of (2 3 4 5 6 8 9 10 11 14 15 17 20 21 23 27 28 30 31 32 33 35 41 42 45 46 47 48 49 50 51 52 54 55 56 60 61 62 63 64 65 69 72 77 78 79 82 83 87 90 92 93 94 95 96 97 98 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 254). 2025-11-05T01:44:32.149999Z LOG report summary reset table name errors rows bytes total time ----------------- --------- --------- --------- -------------- fetch meta data 0 0 0.000s ----------------- --------- --------- --------- -------------- ----------------- --------- --------- --------- -------------- 自分の環境ではビルドするのにopenssl-develずsbclが足りなかったので远加でむンストヌルしたした。 ❯ wget https://github.com/dimitri/pgloader/releases/download/v3.6.9/pgloader-bundle-3.6.9.tgz ❯ tar xavf ./pgloader-bundle-3.6.9.tgz ❯ cd pgloader-bundle-3.6.9 ❯ make # 完了するずプロゞェクト盎䞋のbinディレクトリにバむナリが生成されるので任意の堎所に移動(パスを通しおもいい) 3.2 MySQLの認蚌方法倉曎 pgloaderがMySQLの新しい認蚌方匏に察応しおない関係でMySQLに接続できないので、蚭定を倉曎する必芁がありたす。 (デフォルトの認蚌プラグむンが caching_sha2_password に倉わっおいるため) ❯ mysql -u root -h {ホスト名} -p (パスワヌドを入力) # ナヌザヌ情報を確認 SELECT user, host, plugin FROM mysql.user; # 倉換 ALTER USER 'root'@'{ホスト}' IDENTIFIED WITH mysql_native_password BY '{新しいパスワヌド}'; FLUSH PRIVILEGES; 3.3 GCのメモリ䞍足 オプションでの指定なしで実行するず、デヌタが倧きすぎるため䜜業メモリが足りず、GCの゚ラヌを吐いお停止しおしたうのでメモリの割圓を増やしお察応したす。 たた、オプションでメモリ割圓を増やしおも、マシンに搭茉されおいるメモリが䞍足するず、「MySQLのタむムアりトが発生した」旚の゚ラヌが発生しお停止しおしたいたす。 䞀応蚭定でタむムアりトたでの時間を延長し、それでも同じ゚ラヌが出るようでしたら、メモリが倚い環境で実行するようにしおください。 GC゚ラヌ ❯ ./pgloader my.load 2025-11-05T05:03:53.006000Z LOG pgloader version "3.6.9" 2025-11-05T05:03:53.109999Z LOG Migrating from #<MYSQL-CONNECTION {MySQLの接続情報} {100686C0C3}> 2025-11-05T05:03:53.109999Z LOG Migrating into #<PGSQL-CONNECTION {PostgreSQLの接続情報} {100686C263}> Heap exhausted during garbage collection: 544 bytes available, 832 requested. Immobile Object Counts Gen layout fdefn symbol code Boxed Cons Raw Code SmMix Mixed LgRaw LgCode LgMix Waste% Alloc Trig Dirty GCs Mem-age 1 0 0 0 0 105 2 4081 0 0 35 0 0 0 2.3 135218064 116199738 4223 1 0.7799 2 0 0 0 0 376 3 13856 0 0 26 0 0 0 1.5 460182320 191227498 14037 1 1.1357 3 0 0 0 0 235 9 4052 0 2 60 0 0 0 3.0 138513456 20252714 4169 1 0.2367 4 0 0 0 0 60 1 267 0 0 18 0 0 0 4.7 10809520 21546938 268 1 0.0000 5 54 0 0 80 300 45 1149 1 9 94 0 0 5175 3.0 215344944 219748826 1169 5 0.9706 fatal error encountered in SBCL pid 70636 tid 70641: GC invariant lost, file "gencgc.c", line 523 Welcome to LDB, a low-level debugger for the Lisp runtime environment. (GC in progress, oldspace=1, newspace=2) ldb> MySQLのタむムアりト What I am doing here? MySQL ERROR: Partial Read of 25 bytes, expected 57 Detail: check MySQL logs for (Got timeout writing communication packets) Hint: adjust net_read_timeout and net_write_timeout # pgloaderの実行、ビルドしたバむナリを䜿甚しおるのでパスを盎に指定しおいる # my.loadは䞊蚘の蚭定ファむル # --dynamic-space-size が割圓メモリ蚭定オプション MB単䜍 ❯ ./pgloader --dynamic-space-size 2048 my.load   3.4 ようやくの成功 成功するず以䞋のような結果が出力される mori in zabbix-db-migration-test in ~/disk ❯ ./pgloader --dynamic-space-size 2048 ./my.load 2025-11-06T00:57:46.006000Z LOG pgloader version "3.6.9" 2025-11-06T00:57:46.119000Z LOG Migrating from #<MYSQL-CONNECTION {MySQLの接続情報} {1006858643}> 2025-11-06T00:57:46.120000Z LOG Migrating into #<PGSQL-CONNECTION {PostgreSQLの接続情報} {10068587E3}> 2025-11-06T01:32:49.388234Z LOG report summary reset table name errors rows bytes total time --------------------------------- --------- --------- --------- -------------- fetch meta data 0 1005 0.113s Create Schemas 0 0 0.001s Create SQL Types 0 0 0.004s Create tables 0 414 1.205s Set Table OIDs 0 207 0.010s --------------------------------- --------- --------- --------- -------------- public.history_uint 0 247670390 7.1 GB 24m51.621s public.history 0 179818097 6.0 GB 18m19.154s public.trends 0 31790612 1.5 GB 11m52.358s public.trends_uint 0 42925943 1.5 GB 13m13.914s public.history_text 0 2908279 732.0 MB 1m27.851s public.event_tag 0 7249860 286.1 MB 1m8.851s public.event_recovery 0 549542 12.6 MB 6.828s public.history_str 0 92327 5.3 MB 1.679s public.items 0 60082 20.9 MB 6.865s public.item_discovery 0 35174 2.0 MB 1.866s public.item_rtdata 0 34842 1.0 MB 3.040s public.trigger_tag 0 29393 822.2 kB 5.422s public.triggers 0 24943 9.6 MB 7.189s public.graphs 0 10462 986.2 kB 4.056s public.trigger_discovery 0 8851 269.3 kB 3.134s public.widget_field 0 5864 346.1 kB 2.607s public.graph_discovery 0 3808 99.8 kB 2.796s public.lld_macro_path 0 2359 78.5 kB 3.023s public.changelog 0 1553 44.4 kB 3.338s public.problem_tag 0 1429 47.7 kB 3.602s public.host_tag 0 1370 40.1 kB 3.912s public.valuemap 0 1184 77.3 kB 4.169s public.lld_override 0 968 34.7 kB 3.970s public.hosts 0 791 253.9 kB 4.174s public.host_hgset 0 748 6.3 kB 4.399s public.hosts_templates 0 465 8.6 kB 4.643s public.host_rtdata 0 426 3.3 kB 4.834s public.dashboard_page 0 411 8.8 kB 4.960s public.dashboard 0 308 21.7 kB 5.741s public.media_type_message 0 213 58.0 kB 6.428s public.settings 0 118 5.3 kB 6.958s public.host_discovery 0 48 1.3 kB 7.277s public.hgset_group 0 36 0.2 kB 7.552s public.module 0 32 1.1 kB 7.805s public.hgset 0 27 1.8 kB 8.521s public.operations 0 22 0.4 kB 8.889s public.lld_override_optemplate 0 14 0.2 kB 9.032s public.interface_snmp 0 11 0.4 kB 9.866s public.expressions 0 10 0.5 kB 10.597s public.opmessage 0 8 0.1 kB 11.581s public.usrgrp 0 6 0.2 kB 11.790s public.interface_discovery 0 5 0.0 kB 12.276s public.users_groups 0 5 0.0 kB 12.606s public.opmessage_grp 0 4 0.0 kB 14.756s public.role 0 4 0.1 kB 15.239s public.scripts 0 3 0.3 kB 15.853s public.acknowledges 0 2 0.1 kB 16.007s public.ha_node 0 1 0.1 kB 16.248s public.sysmaps_elements 0 1 0.1 kB 16.642s public.config_autoreg_tls 0 1 0.0 kB 16.840s public.connector_tag 0 0 17.039s public.corr_condition_group 0 0 17.164s public.corr_condition_tagpair 0 0 17.328s public.corr_operation 0 0 17.458s public.dashboard_user 0 0 17.620s public.dbversion 0 1 0.0 kB 17.760s public.dhosts 0 0 17.893s public.dservices 0 0 17.992s public.event_suppress 0 0 18.193s public.globalmacro 0 1 0.0 kB 18.373s public.group_discovery 0 0 18.639s public.host_proxy 0 0 18.851s public.httpstep 0 0 18.988s public.httpstepitem 0 0 19.068s public.httptest_field 0 0 19.214s public.httptestitem 0 0 19.221s public.icon_mapping 0 0 19.241s public.lld_override_ophistory 0 0 19.444s public.lld_override_opperiod 0 0 19.631s public.lld_override_optrends 0 0 19.713s public.maintenances 0 0 19.900s public.maintenances_hosts 0 0 20.058s public.media 0 0 20.202s public.mfa 0 0 20.378s public.opcommand 0 0 20.444s public.opcommand_hst 0 0 20.532s public.opinventory 0 0 20.767s public.optag 0 1 0.0 kB 20.944s public.proxy 0 0 21.051s public.proxy_dhistory 0 0 21.158s public.proxy_group_rtdata 0 0 21.400s public.proxy_rtdata 0 0 21.471s public.report_param 0 0 21.455s public.report_usrgrp 0 0 21.576s public.scim_group 0 0 21.663s public.service_alarms 0 0 21.839s public.service_problem_tag 0 0 22.072s public.service_tag 0 0 22.190s public.services_links 0 0 22.277s public.sla_excluded_downtime 0 0 22.340s public.sla_service_tag 0 1 0.0 kB 22.599s public.sysmap_element_url 0 0 22.895s public.sysmap_shape 0 1 0.1 kB 23.598s public.sysmap_user 0 0 23.701s public.sysmaps_element_tag 0 0 23.780s public.sysmaps_links 0 0 23.937s public.task 0 0 24.096s public.task_check_now 0 0 24.348s public.task_data 0 0 24.666s public.task_remote_command_result 0 0 24.824s public.timeperiods 0 0 25.002s public.trigger_queue 0 0 25.067s public.user_scim_group 0 0 25.124s public.userdirectory 0 0 25.266s public.userdirectory_ldap 0 0 25.399s public.userdirectory_saml 0 0 25.495s public.events 0 1101492 183.6 MB 42.597s public.item_tag 0 117492 3.8 MB 1.333s public.item_preproc 0 61151 2.6 MB 1.380s public.functions 0 47934 1.3 MB 2.031s public.item_rtname 0 33155 2.8 MB 0.927s public.valuemap_mapping 0 32638 921.4 kB 0.403s public.graphs_items 0 28356 1011.7 kB 1.154s public.trigger_depends 0 12763 226.6 kB 1.462s public.item_condition 0 10214 554.6 kB 1.282s public.hostmacro 0 5725 551.3 kB 0.483s public.auditlog 0 5873 4.2 MB 0.878s public.housekeeper 0 4057 125.1 kB 0.138s public.widget 0 1521 58.0 kB 0.122s public.lld_override_operation 0 1385 41.4 kB 0.274s public.lld_override_opdiscover 0 1371 9.4 kB 0.513s public.lld_override_opstatus 0 1228 8.4 kB 0.396s public.hosts_groups 0 1172 15.2 kB 0.563s public.lld_override_condition 0 968 45.9 kB 0.784s public.item_parameter 0 745 29.6 kB 0.837s public.media_type_param 0 674 26.3 kB 1.250s public.interface 0 451 20.4 kB 1.231s public.autoreg_host 0 415 23.6 kB 1.190s public.profiles 0 321 16.0 kB 1.359s public.problem 0 256 32.8 kB 1.373s public.images 0 187 1.9 MB 1.666s public.group_prototype 0 65 1.7 kB 1.520s public.ids 0 46 1.3 kB 1.565s public.media_type 0 42 314.1 kB 1.923s public.hstgrp 0 29 1.6 kB 1.787s public.role_rule 0 27 0.8 kB 1.825s public.sessions 0 20 1.6 kB 1.931s public.conditions 0 12 0.2 kB 2.065s public.actions 0 10 0.5 kB 2.006s public.host_inventory 0 9 1.0 kB 2.199s public.opgroup 0 6 0.0 kB 2.297s public.history_log 0 5 3.2 kB 2.336s public.regexps 0 5 0.2 kB 2.247s public.graph_theme 0 4 0.9 kB 2.184s public.optemplate 0 4 0.0 kB 2.387s public.lld_override_optag 0 3 0.1 kB 2.474s public.ugset_group 0 3 0.0 kB 2.455s public.users 0 2 0.3 kB 2.661s public.sysmaps 0 1 0.1 kB 2.682s public.alerts 0 0 2.785s public.connector 0 0 2.645s public.corr_condition 0 0 2.605s public.corr_condition_tag 0 0 2.564s public.corr_condition_tagvalue 0 0 2.515s public.correlation 0 0 2.653s public.dashboard_usrgrp 0 1 0.0 kB 2.698s public.dchecks 0 1 0.0 kB 2.875s public.drules 0 1 0.0 kB 2.919s public.escalations 0 0 2.977s public.event_symptom 0 0 2.995s public.globalvars 0 1 0.0 kB 3.146s public.history_bin 0 0 3.026s public.hostmacro_config 0 0 3.061s public.httpstep_field 0 0 3.095s public.httptest 0 0 3.174s public.httptest_tag 0 0 3.315s public.icon_map 0 0 3.391s public.lld_macro_export 0 0 3.324s public.lld_override_opinventory 0 0 3.614s public.lld_override_opseverity 0 0 3.602s public.maintenance_tag 0 0 3.564s public.maintenances_groups 0 0 3.565s public.maintenances_windows 0 0 3.774s public.media_type_oauth 0 0 3.801s public.mfa_totp_secret 0 0 3.795s public.opcommand_grp 0 0 3.771s public.opconditions 0 0 3.933s public.opmessage_usr 0 0 4.030s public.permission 0 0 4.128s public.proxy_autoreg_host 0 0 4.033s public.proxy_group 0 0 4.178s public.proxy_history 0 0 4.183s public.report 0 0 4.212s public.report_user 0 0 4.213s public.rights 0 0 4.307s public.script_param 0 0 4.447s public.service_problem 0 0 4.542s public.service_status_rule 0 0 4.499s public.services 0 0 4.427s public.sla 0 1 0.1 kB 4.889s public.sla_schedule 0 0 4.536s public.sysmap_element_trigger 0 0 4.544s public.sysmap_link_threshold 0 0 4.539s public.sysmap_url 0 0 4.556s public.sysmap_usrgrp 0 0 4.556s public.sysmaps_link_triggers 0 0 4.511s public.tag_filter 0 0 4.524s public.task_acknowledge 0 0 4.556s public.task_close_problem 0 0 4.550s public.task_remote_command 0 0 4.545s public.task_result 0 0 4.605s public.token 0 0 4.585s public.ugset 0 1 0.1 kB 4.813s public.user_ugset 0 1 0.0 kB 4.652s public.userdirectory_idpgroup 0 0 4.616s public.userdirectory_media 0 0 4.646s public.userdirectory_usrgrp 0 0 4.669s --------------------------------- --------- --------- --------- -------------- COPY Threads Completion 0 4 33m34.875s Create Indexes 0 521 22m28.427s Index Build Completion 0 521 1m20.883s Reset Sequences 0 1 0.127s Primary Keys 0 207 0.291s Create Foreign Keys 0 277 5.553s Create Triggers 0 0 0.000s Install Comments 0 0 0.000s --------------------------------- --------- --------- --------- -------------- Total import time ✓ 514702901 17.4 GB 57m30.156s   3.5. pgdump pgloaderでMySQLからデヌタを移行しただけでは、通垞のPostgreSQLのテヌブル構造になっおいるため、TimescaleDB甚の構造に倉換する必芁がありたす。 䞇が䞀倉換に倱敗した時のために、この段階でバックアップを䜜成するこずをオススメしたす。 pg_dumpを甚いたダンプの出力はいく぀か皮類がありたすが、今回はdocker環境での取り回しが良く、比范的サむズが小さい、plainのgzip圧瞮を䜿甚したした。 ❯ pg_dump -d {接続情報} | gzip > backup.sql.gz   4. TimescaleDB 先皋述べた通り、PostgreSQLに移行したテヌブルをTimescaleDBのhypertableに倉換する必芁がありたす。 倉換スクリプトが甚意されおいるのでそちらを実行したす。私の堎合は、コンテナ内から取り出しお䜿甚したした。 PostgreSQLの状態でデヌタ保存甚のボリュヌムを䜜っおいた堎合、TimescaleDBの拡匵の認識蚭定がされおいないので蚭定を曞き換える必芁がありたす。 (最初からTimescaleDBのimageでやっおたら䞍芁) スクリプト実行時の゚ラヌにかかれおいる通り蚭定に shared_preload_libraries = 'timescaledb' を远蚘する必芁がありたす TimecaleDB拡匵が認識されおいない状態で有効化しようずしお倱敗したログ ❯ echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | psql {接続情報} Password for user user: FATAL: extension "timescaledb" must be preloaded HINT: Please preload the timescaledb library via shared_preload_libraries. This can be done by editing the config file at: /var/lib/postgresql/data/postgresql.conf and adding 'timescaledb' to the list in the shared_preload_libraries config. # Modify postgresql.conf: shared_preload_libraries = 'timescaledb' Another way to do this, if not preloading other libraries, is with the command: echo "shared_preload_libraries = 'timescaledb'" >> /var/lib/postgresql/data/postgresql.conf (Will require a database restart.) server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. connection to server was lost この工皋での詰たりポむントは、ディスクの空き容量䞍足です。 倉換スクリプトの実行䞭通垞のテヌブルずhypertable䞡方の情報が同居する関係なのか、デヌタサむズがかなり肥倧化したす。 私が実行した環境では1.5~2倍皋床にたで肥倧化しおいたず思いたす。 Zabbixサヌバヌのコンテナがいきなり登堎しおたすが、今回は説明を割愛したす。 蚘事の最埌に私が怜蚌に甚いたDocker ComposeでのZabbixの最小限の構成をおたけで付けおいるので、そちらを参照しおください。 # zabbix-serverが皌働した状態で倉換スクリプトをコンテナから取り出す # zabbix-serverです、timescaledbではなく ❯ docker cp {zabbix-serverのコンテナID}:/usr/share/doc/zabbix-server-postgresql/. ./scripts # 取り出したスクリプトを確認 ❯ ls scripts  create.sql.gz  option-patches  timescaledb.sql # timescaledb拡匵を有効化 ❯ echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | psql -U {ナヌザ名} -h {ホスト名} Password for user {ナヌザ名}: CREATE EXTENSION # 倉換スクリプトを実行 ❯ cat ./scripts/timescaledb.sql | psql -U {ナヌザ名} -h {ホスト名} 実行ログ mori in zabbix-db-migration-test in ~/disk ❯ echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | psql -U {ナヌザ名} -h {ホスト名} Password for user {ナヌザ名}: NOTICE: extension "timescaledb" already exists, skipping CREATE EXTENSION mori in zabbix-db-migration-test in ~/disk ❯ cat ./script/timescaledb.sql | psql -U {ナヌザ名} -h {ホスト名} Password for user {ナヌザ名}: CREATE FUNCTION NOTICE: function base36_decode(pg_catalog.varchar) does not exist, skipping DROP FUNCTION NOTICE: PostgreSQL version 17.6 is valid NOTICE: TimescaleDB extension is detected NOTICE: TimescaleDB version 2.21.4 is valid NOTICE: migrating data to chunks DETAIL: Migration might take a while depending on the amount of data. NOTICE: migrating data to chunks DETAIL: Migration might take a while depending on the amount of data. WARNING: column type "character varying" used for "source" does not follow best practices HINT: Use datatype TEXT instead. NOTICE: migrating data to chunks DETAIL: Migration might take a while depending on the amount of data. NOTICE: migrating data to chunks DETAIL: Migration might take a while depending on the amount of data. WARNING: column type "character varying" used for "value" does not follow best practices HINT: Use datatype TEXT instead. NOTICE: migrating data to chunks DETAIL: Migration might take a while depending on the amount of data. WARNING: column type "character varying" used for "auditid" does not follow best practices HINT: Use datatype TEXT instead. WARNING: column type "character varying" used for "username" does not follow best practices HINT: Use datatype TEXT instead. WARNING: column type "character varying" used for "ip" does not follow best practices HINT: Use datatype TEXT instead. WARNING: column type "character varying" used for "resource_cuid" does not follow best practices HINT: Use datatype TEXT instead. WARNING: column type "character varying" used for "resourcename" does not follow best practices HINT: Use datatype TEXT instead. WARNING: column type "character varying" used for "recordsetid" does not follow best practices HINT: Use datatype TEXT instead. NOTICE: migrating data to chunks DETAIL: Migration might take a while depending on the amount of data. NOTICE: migrating data to chunks DETAIL: Migration might take a while depending on the amount of data. NOTICE: migrating data to chunks DETAIL: Migration might take a while depending on the amount of data. NOTICE: TimescaleDB is configured successfully DO   たずめ 残念ながら、圓初の目的であったCPU䜿甚率の削枛には぀ながりたせんでした。 しかし、ディスクぞの曞き蟌み頻床ず曞き蟌みデヌタ量が倧幅に枛りたした。 たた、MySQLには倧量のbinlogが溜たっおいたずいうのもありたすが、TimescaleDBの圧瞮機胜によっおディスク消費量も倧幅に枛らすこずができたした。   おたけ MySQLの最小構成のDocker Composeファむル DBが初期化されるたで2,3分かかる(その前にアクセスするず異垞な蚭定、みたいな゚ラヌがでるのでしばらく埅ち) services: mysql-server: image: mysql:8.0-bookworm restart: always command: - --log-bin-trust-function-creators=1 - --character-set-server=utf8mb4 - --collation-server=utf8mb4_bin environment: MYSQL_DATABASE: {DB名} MYSQL_USER: {ナヌザ名} MYSQL_PASSWORD: {パスワヌド} MYSQL_ROOT_PASSWORD: {rootパスワヌド} healthcheck: test: ["CMD", "mysqladmin", "ping", "-h", "localhost"] interval: 10s timeout: 5s retries: 5 volumes: - ./data:/var/lib/mysql - ./mysql_conf/:/etc/mysql/ ports: - 3306:3306 cap_add: - SYS_NICE zabbix-server: image: zabbix/zabbix-server-mysql:ubuntu-latest restart: always ports: - 10051:10051 environment: DB_SERVER_HOST: mysql-server # 䞊で定矩したMySQLサヌビス名 MYSQL_DATABASE: {䞊で定矩したDB名} MYSQL_USER: {同䞊} MYSQL_PASSWORD: {同䞊} volumes: - ./zabbix_conf/:/etc/zabbix depends_on: mysql-server: condition: service_healthy zabbix-web: image: zabbix/zabbix-web-nginx-mysql:ubuntu-latest restart: always ports: - 80:8080 environment: DB_SERVER_HOST: mysql-server # 䞊で定矩したMySQLサヌビス名 MYSQL_DATABASE: {䞊で定矩したDB名} MYSQL_USER: {同䞊} MYSQL_PASSWORD: {同䞊} ZBX_SERVER_HOST: zabbix-server # 䞊で定矩したZbbixSeverサヌビス名 PHP_TZ: Asia/Tokyo depends_on: - zabbix-server zabbix-agent: image: zabbix/zabbix-agent:ubuntu-latest restart: always environment: ZBX_SERVER_HOST: zabbix-server # 䞊で定矩したZbbixSeverサヌビス名 ZBX_SERVER: zabbix-server # Azureの仮想マシン䞊でdocker composeを䜿うず謎にsshが死ぬので぀けおる # 普通はいらない networks: default: ipam: driver: default config: - subnet: 192.168.1.0/24 # 競合しないプラむベヌトIP範囲を指定 gateway: 192.168.1.1 TimescaleDB(PostgreSQL)の最小構成Docker Compose ファむル 今回の䜿甚法におおいは、テヌブル倉換をしない堎合は普通のPostgreSQLず同じ動きをするので、通垞版は割愛 services: postgres-server: image: timescale/timescaledb:2.22.1-pg17 restart: always environment: POSTGRES_USER: {ナヌザ名} POSTGRES_PASSWORD: {パスワヌド} POSTGRES_DB: {DB名} ports: - 5432:5432 volumes: - ./postgres-data:/var/lib/postgresql/data zabbix-server: image: zabbix/zabbix-server-pgsql:ubuntu-latest restart: always environment: DB_SERVER_HOST: postgres-server # 䞊で定矩したDBのホスト名 POSTGRES_USER: {䞊で定矩したDBナヌザ名} POSTGRES_PASSWORD: {䞊で定矩したDBパスワヌド} POSTGRES_DB: {䞊で定矩したDB名} ports: - 10051:10051 volumes: - ./zabbix_conf/:/etc/zabbix depends_on: - postgres-server healthcheck: test: ["CMD-SHELL", "pgrep zabbix_server"] interval: 10s timeout: 5s retries: 5 start_period: 20s zabbix-web: image: zabbix/zabbix-web-nginx-pgsql:ubuntu-latest restart: always environment: DB_SERVER_HOST: postgres-server # 䞊で定矩したDBのホスト名 POSTGRES_USER: {䞊で定矩したDBナヌザ名} POSTGRES_PASSWORD: {䞊で定矩したDBパスワヌド} POSTGRES_DB: {䞊で定矩したDB名} ZBX_SERVER_HOST: zabbix-server PHP_TZ: Asia/Tokyo ports: - 80:8080 depends_on: - postgres-server - zabbix-server zabbix-agent: image: zabbix/zabbix-agent:ubuntu-latest restart: always environment: ZBX_SERVER_HOST: zabbix-server # 䞊で定矩したZbbixSeverサヌビス名 ZBX_SERVER: zabbix-server # 䞊で定矩したZbbixSeverサヌビス名 depends_on: zabbix-server: condition: service_healthy # azureの仮想マシン䞊でdocker composeを䜿うず謎にsshが死ぬので぀けおる # 普通はいらない networks: default: ipam: driver: default config: - subnet: 192.168.1.0/24 # 競合しないプラむベヌトIP範囲を指定 gateway: 192.168.1.1 参考資料 https://www.tigerdata.com/docs/use-timescale/latest/hypertables https://www.zabbix.com/documentation/current/jp/manual/appendix/install/timescaledb https://pgloader.readthedocs.io/en/latest/ref/mysql.html https://github.com/dimitri/pgloader/issues/1211 https://qiita.com/11ohina017/items/4a808e4fc03e1ac890ba https://assets.zabbix.com/files/events/meetup_20200702/meetup_20200702_MySQL2PgSQL-ENG.pdf
この蚘事は、 ニフティグルヌプ Advent Calendar 2025  19日目の蚘事です。 はじめに おはようございたす。IWS です 2025幎アドベントカレンダヌも19日目の蚘事です。 19日目のこの蚘事では、 GitHub Actions を䜿った CI に぀いお曞こうかなず思いたす。 GitHub Actions での CI 私のチヌムでは以䞋のような構成のコンテナ環境を䜿甚しおいたす。 apl コンテナを䞭心に耇数のコンテナを䜿う構成で開発しおいたす。テスト実行には各コンテナが必芁なため、これたで GitHub Actions で CI を組んでもビルドを含めお10分以䞊かかるような状態でした。 䜕かあっお CI を回すたびに10分埅たなければいけないずいうのはかなりのストレスなため少しでも早くできるように詊しおいきたいず思いたす。 むメヌゞの準備 テスト実行にコンテナのDB等が必芁な郜合、GitHub Actions 䞊でもビルドが必芁になりたす。CI にかかる時間の半分はビルドにかかった時間です。 今回は必芁なコンテナが4぀あり、すべおをビルドするのはかなりの時間がかかるため少しでも CI 実行時間を抑えられるようにしおいきたす。 GHCR にあらかじめむメヌゞを保存しおおく もしほずんど倉曎がなく郜床ビルドする必芁がないような堎合は GHCR ( GitHub Container Registry ) にむメヌゞをあらかじめ保存しおおくこずで CI 時のビルドを省くこずができたす。GHCR は GitHub が提䟛しおいる コンテナレゞストリです。 以䞋のコマンドでむメヌゞを push するこずができたす。 $ docker build --no-cache -f stub.Dockerfile -t stub . $ echo "<PAT>" | docker login ghcr.io -u <GitHubナヌザ名> --password-stdin $ docker tag stub:latest ghcr.io/<org>/stub:latest $ docker push ghcr.io/<org>/stub:latest GHCR ではストレヌゞや pull, push などのデヌタ転送の無料枠を超えた分の利甚に぀いおは課金が必芁になるのですが、GitHub Actions からの利甚に関しおは Free ずしおカりントされるため課金を気にせず䜿甚ができたす。デヌタ転送のみ、詳しくは https://docs.github.com/ja/billing/concepts/product-billing/github-packages   Push ができるず GitHub の Packages からむメヌゞの䞀芧を芋るこずができたす。   WF からは↓のようにすればむメヌゞを pull できたす。ログむンの action を呌びだし docker pull コマンドをするだけです。 jobs: ci: step: - name: ghcr login uses: docker/login-action@5e57cd118135c172c3672efd75eb46360885c0ef # v3.6.0 with: registry: ghcr.io username: ${{ github.actor }} password: ${{ secrets.GITHUB_TOKEN }} - name: stub image pull from ghcr run: | docker pull ghcr.io/${{ github.repository_owner }}/stub:latest docker tag ghcr.io/${{ github.repository_owner }}/stub:latest stub   耇数ビルドするずきは matrix で䞊列にビルド WF 䞊で耇数むメヌゞのビルドが必芁な堎合は matrix を䜿い䞊列にビルドするこずで WF の実行時間を抑えるこずができたす。   GitHub Actions では job ごずに別のランナヌで凊理されるため、通垞 job A でビルドしたむメヌゞを job B で䜿甚するこずはできたせん。そのため GHCR などに䞀床むメヌゞを保存しお job B で pull するずいった方法が必芁になる   ず思っおいたのですが「同じ key 同じ path のキャッシュを䜿うこずでファむルの共有をする」ずいう方法があるそうでこちらの蚘事を参考にやっおみたした。 【裏技】別ファむルに切り出した Job 間で Docker むメヌゞを共有し高速に GitHub Actions をぶん回す jobs: # むメヌゞの䞊列ビルド build: runs-on: ubuntu-latest timeout-minutes: 20 strategy: fail-fast: false matrix: include: - name: apl tag: apl context: . dockerfile: ./apl.Dockerfile.dev - name: db tag: db context: . dockerfile: db.Dockerfile steps: - name: Checkout repository uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2 - name: Set up Docker Buildx uses: docker/setup-buildx-action@b5ca514318bd6ebac0fb2aedd5d36ec1b5c232a2 # v3.10.0 - name: Build Docker image uses: docker/build-push-action@263435318d21b8e681c14492fe198d362a7d2c83 # v6.18.0 with: context: ${{ matrix.context }} file: ${{ matrix.dockerfile }} push: false load: true tags: ${{ matrix.tag }} cache-from: type=gha,scope=${{ matrix.name }} cache-to: type=gha,mode=max,scope=${{ matrix.name }} # ビルドしたむメヌゞを tar ずしおキャッシュに保存する - name: Save the built image as a tar file run: docker save -o ${{ matrix.name }}.tar ${{ matrix.tag }} - name: Save the tar file to the cache uses: actions/cache@0057852bfaa89a56745cba8c7296529d2fc39830 # v4.3.0 with: path: ${{ matrix.name }}.tar key: image-cache-${{ matrix.name }}-${{ github.sha }} # むメヌゞの䞊列ビルド run: runs-on: ubuntu-latest needs: build steps: # キャッシュから tar を埩元 - name: Restore apl image cache uses: actions/cache@0057852bfaa89a56745cba8c7296529d2fc39830 # v4.3.0 with: path: apl.tar key: image-cache-apl-${{ github.sha }} # Save the tar file to the cache の key に合わせる fail-on-cache-miss: true # db でも同じこずをする # tar から Docker むメヌゞを埩元 - name: Load images from tar files run: | docker load -i apl.tar docker load -i db.tar docker image ls のようにするこずで 䞊列にむメヌゞをビルド tar ずしおむメヌゞをキャッシュに保存 埌続の job で tar からむメヌゞを埩元 し、コンテナ起動時に䜜成されたむメヌゞを䜿うこずができたした。 キャッシュも保存されるため2回目移行はさらに早くなるのも good ポむントですね。 テスト実行 おたけのようなものですが、WF 䞊でどうテストを実行しおいるかも曞いおおきたす。 コンテナ起動〜テストコマンド実行には @devcontainers/cli  を䜿甚したした。 devcontainer up で立ち䞊げ、 devcontainer exec でコマンドの実行が行えたす。 - name: Install Dev Container CLI run: npm install -g @devcontainers/cli # Dev Container 起動 - name: Build and run Dev Container run: devcontainer up --workspace-folder . --config .devcontainer/ci/devcontainer.json # lint, test - name: Run lint id: lint continue-on-error: true run: devcontainer exec --container-id $(docker ps -aq --filter "name=<コンテナ名>") --workspace-folder . <lint コマンド> - name: Run test run: devcontainer exec --container-id $(docker ps -aq --filter "name=<コンテナ名>") --workspace-folder . <teset コマンド> # continue-on-error では job が成功扱いになっおしたうため明瀺的に倱敗させる - name: if lint failed if: ${{ steps.lint.outcome == 'failure' }} run: exit 1   lint に倱敗した際も test の実行をしおもらいたいため lint の step に continue-on-error: true を远加しおいたす。゚ラヌを無芖しお埌続 step を実行する蚭定です。ただし、このたただず lint 倱敗時も job が成功ずなっおしたうため if lint failed step で萜ずすようにしおいたす。 たずめ ビルドし぀぀もかかる時間を抑えお CI を実装する話を曞いおみたした。 ちなみに珟圚は CI に玄5分皋床かかっおいたす。最初の頃の10分↑ず比べれば半分以䞋にはなったのですがやはりただ長いなずは感じるので他にも短瞮芁玠がないか詊しおみようず思いたす 明日は namiki_ さんのアドベントカレンダヌ20日目ですおたのしみに  
こんにちは、゚ンゞニアリングマネヌゞャヌの芊川です。InnerSource Summit 2025におニフティが写真撮圱サポヌトしたこずずセッション聎講・登壇からの孊びを今回ご報告させおいただきたす。 InnerSourceずは ニフティは3幎前からむンナヌ゜ヌスを導入したした。むンナヌ゜ヌスっお䜕ずいう方は、 むンナヌ゜ヌスを導入しおみた その① お詊し導入線 をご参照ください補足ですが、圓時から進化したずころでは、゜ヌスコヌドだけではなくドキュメント・スラむドなどコラボレヌションできるずころはむンナヌ゜ヌスの考え方を取り入れおいこう、ずいう颚朮が埐々に高たっおいるず思いたす。 InnerSource Summit 2025ずは さる2025-11-13に、暪浜・ベルリン・ニュヌペヌクに䌚堎を8時間ず぀移しながら、たる24時間連続のずんでもないむンナヌ゜ヌスのむベントがありたした。他の技術むベントでも24時間ぶっ通しずいうのは芋たこずない。 InnerSource Summit 2025 InnerSource Summit 2025ずは、䌁業内でオヌプン゜ヌス開発の手法を取り入れ、郚門間の壁を越えたコラボレヌションず共創を促進する「むンナヌ゜ヌス」の最新動向や実践事䟋を共有する囜際的なむベントです。 ニフティは、暪浜䌚堎の写真撮圱サポヌトずしお1人が匵り付き、たた私自身は人生初の英語セッションずいう恐ろしいこずが埅ち受けおおりたした。 このたびYoutubeにビデオがあがりたしたので、遅くなっおしたいたしたがむベントのご報告させおいただきたす。プレむリストになっおたすので、右䞊のハンバヌガヌっぜいアむコンから各セッションを芋るこずができたす。 冒頭、「 Yuki Hattori – Welcome to InnerSource Summit 2025 」の䞭で匊瀟ロゎがPHOTO SUPPORT枠にあり、茉せおいただいた運営の方に倧感謝です。普段はあたり䞀緒に䞊ぶこずがない䌁業様ず䞊ぶこずができ、めっちゃ嬉しいですね。撮圱した写真やショヌトムヌビヌの方は、むベント党䜓の振り返り動画のような圢で公開されるずのこずで非垞に楜しみです このむベントのすごいずころを色々ず蚀いたいこずはありたすが、匷調しお1点お䌝えしたいものがあり、それは日本のむンナヌ゜ヌスの広がりに間違いなく貢献した䞉菱電機様の取り組みに぀いおです。パヌトナヌや顧客、コミュニティずの共創により新たな䟡倀を生み出すむノベヌティブカンパニヌぞず倉革すべく、おそらく日本ではじめお「むンナヌ゜ヌス」ずいう名前が぀く郚眲を立ち䞊げおいたす。オヌプン゜ヌスむンナヌ゜ヌス共創掚進郚です。で、暪浜でのむベント䌚堎は同瀟の「Serendie Street YIMP」で行われ圓日も叞䌚や機材呚りなど同瀟瀟員様がたくさんホストされおいたした。本圓にありがずうございたす。圓時、色々な新聞やメディアにも取り䞊げられ話題になっおいたしたね。 暪浜、ベルリン、ニュヌペヌクで囜際䌚議 䞉菱電機が講挔「シナゞヌ加速」 セッションからの孊び さお、暪浜䌚堎での数あるセッションの䞭から䞀抌しセッションをご玹介したす。私にずっおの1番の孊びは、人事院人事官 䌊藀か぀らさんによる「 Shaping What’s Next: The Transformative Power of Engineers and Organization 」でした。こちらは日本語セッションです。 正盎めちゃめちゃ面癜かったです。簡単ですが、以䞋にたずめたす。 ゚ンゞニアからキャリアが始たり人事院人事官に至るたでの話。 人事院の䜿呜やMVVの話。法埋の実装は行政ずいう話。 日本䌁業の゚ンゲヌゞメントず䞖界からみた順䜍の話。 日本䌁業で働いおいる方の孊び・キャリアず䞖界からみた順䜍の話。 人的資本経営の話。 日本の特異なIT人材・技術者を取り巻く環境の倉化の話。 IQずEQ感情知性、心の知胜指数、そのバランスの話。 キャリア䞊のあるある話。 リヌダヌシップ論サヌバントリヌダヌシップなどずその教育䞍足の話。 グロヌスマむンドセットの話。 マゞでどこを切り取っおも響く内容ばかりの神セッションでした。特にチヌムリヌダヌやマネヌゞャヌ局に響く内容なのかな、ず思いたす。゚ンゞニアリングに関わっおいる方以倖にもずおも有甚かず思いたす。是非、ご芖聎あれ。 次に私の発衚内容に觊れたいず思いたす。 3幎前よりこれたでニフティはむンナヌ゜ヌス掻動をしおきたした。そのたずめのような内容になっおおりたす。今回はその掻動の䞭で特にここは瀟内のむンナヌ゜ヌス促進に効いたな、ずいうポむントを3点に絞っお発衚しおいたす。さらに、瀟内のむンナヌ゜ヌス促進掻動をどのように有志のメンバヌずずもに行っおいるかに぀いおも今回はじめお発衚させおいただきたした。 ず、、、いうようなこずをちゃんず発衚しお䌝えるこずができおいればず思うのですが、なんせはじめおの英語発衚でしおガチガチに緊匵しながら、発衚甚のメモスマホを握りしめながら喋る、ずいうこずになっおたしお、出来䞊がりのビデオを芋おも、うわぁ、ずいう仕䞊がりになっおおりたす。 動画のリンクは「 Ryo Ashikawa – Three points that promoted InnerSource activities 」ですが、マゞで英語喋るのは自信がないため、以䞋に、話した内容を文字起こししお別スラむドに盛り蟌んだバヌゞョンをこの堎に公開しお難を去ろうかず思いたす。 ですが、今回ずおも貎重な機䌚をいただいたず思っおいたす。英語セッションの孊び・感想・気づきずしおは、以䞋です。 英語の発音なんおずりあえず気にするな。結局のずころ、文字や図などで䌝わればよい。 発衚できるこずよりもコミュニケヌションできるこずが倧事。英語はコミュニケヌションツヌルだ。方法はなんでもいいから人ずコミュニケヌションできるこずが倧事だ。 自分に自信を持たせるために、埌で思い盎したフシがありたすが、実際、セッション埌に声をかけおくれおきた方ずのやり取りのほうが身になったこずは事実です。 ずいうわけで非垞に有意矩なむベントでした。 InnerSourceに関する情報は、 InnerSource CommonのLinkedIn に最新情報が流されたすので、是非ご興味あればフォロヌください それでは、最埌に写真撮圱サポヌトの䞭でずった写真をいく぀か䞊べたしおおしたいにしたいず思いたす。 ゚ントランスです。24時間のはじたりです。 むンナヌ゜ヌスヒヌロヌ の抜け殻。圓日も誕生秘話や熱いメッセヌゞを䌝えおくれおいたした セッション䞭。䌊藀か぀らさんです。 Thank you to our Summit Speakers!!!!! 以䞊です
むンタヌネットの䞖界では、サむバヌ攻撃をはじめずする新たな脅嚁が次々ず生たれおいたす。健党な䌁業掻動を維持するためにも、瀟内のセキュリティ察策匷化は欠かせたせん。 ニフティにも、瀟内党䜓のセキュリティを掚進する専門チヌムがありたす。 前線 では、具䜓的な業務内容やこの仕事の魅力、やりがいに぀いおメンバヌに語っおもらいたした。埌線では、ニフティずいう䌚瀟の良いずころ、チヌムに迎えたいメンバヌ像、さらには各々が描く今埌のキャリアに぀いお䌺いたす。 入瀟盎埌から「歓迎されおいる」ず感じられた みなさんが思う「ニフティの良いずころ」を教えおください。 Mさん 基本的に、新しく䜕かを導入したり、挑戊したりずいったこずに察しお前向きな䌚瀟だず感じたす。たずえば、最近の自チヌムでいうず新芏チヌムの立ち䞊げの話やセキュリティシステム内補の話、他チヌムでも新芏の゜リュヌション導入や新芏ビゞネスなど、マネゞメント局含めお前向きに取り組む方が倚いですね。 あずは、私は䞭途入瀟なのですが、転職掻動䞭に䌚瀟のこずを調べおいたら「ニフティには良い人が倚い」ずいう情報がけっこう出おきお。本圓かなず思っおいたしたが、入瀟しおみたら実際に良い人ばかりで安心したした笑。みなさん人圓たりがいいし、入瀟盎埌は特に積極的に声をかけおくださったり、䞭途入瀟組のコミュニティに招埅しおくださったりず、「歓迎されおいるな」ず感じさせおもらえたのはありがたかったですね。 Tさん 僕も䞀番に思い浮かぶのは「人」ですね。僕の堎合は新卒入瀟ずいうこずもあっお、䌚瀟勀め自䜓が初めおずいう䞍安な状態のなかで、芪身になっお盞談に乗っおくれる先茩がたくさんいたした。おかげさたで瀟䌚人のスタヌトずしおは、すごく良い入り方ができたず思いたす。 Mさんも蚀っおくれた挑戊ずいう郚分でいうず、個人のやりたいこずも尊重しおくれる䌚瀟だず感じたす。定期的に䞊叞ずの1on1の面談機䌚があっお、将来的にやりたいこず、目指したいこずを盞談できるんです。その時すぐに実珟するのは難しいこずでも、先を芋越しお「じゃあ、今のうちにこういう経隓を積むずいいんじゃない」ず前向きな提案をしおくれるので未来も描けるし、日々の業務ぞのモチベヌションも䞊がりたすね。 Hさんは入瀟6幎目ず、2人よりも長くニフティに勀めおいたすが、どんなずころに良さを感じたすか Hさん 二人に先に蚀われおしたいたしたが、チャレンゞしやすい環境はニフティの倧きな特城です。個人でいうず、たずえば䜕か孊びたいこず、䌞ばしたいスキルがあるずしお、目的が明確であれば䌚瀟がそれをサポヌトする環境を甚意しおくれたす。孊んだこずを生かしお掻躍できる堎も倚いず感じたすし、成長の機䌚が至るずころにある䌚瀟なのではないかず思いたす。 蟛抱匷く、䞁寧に察応する姿勢が求められるセキュリティの仕事 珟圚、セキュリティチヌムは3名ずいうこずですが、これからさらに人手が必芁になるず思いたす。新しいメンバヌを迎えるずしたら、どんな人がいいですか 望たしいスキルや人物像を教えおください。 Hさん セキュリティチヌムの業務の䞀぀に、瀟内各郚眲からのセキュリティに関する盞談察応がありたす。そうした様々な困りごずに察しお、真摯に取り組めるかどうかが、たずは倧事な玠逊になるず思いたす。たずえば、セキュリティ芳点から芋れば懞念がある盞談ごずに察しお「NO」ず蚀うのは簡単ですが、できればそれを実珟させる方法がないかを蟛抱匷く考えおいく。そういった思考を持おるかどうかは重芁です。 たた、蚀われたこずだけをやるのではなく、自身の興味に埓っお䞻䜓的に孊べる人、動ける人も倧歓迎です。TさんやMさんがたさにそうなのですが、二人ずも新しい技術を孊ぶこずに察しお貪欲で、各々が倖で吞収しおきたものを本業にフィヌドバックしおくれおいたす。セキュリティの䞖界に限ったこずではないかもしれたせんが、その時々で抌さえおおくべき知識やスキルはどんどん倉わっおいきたすので、自ら孊ぶ姿勢がある人ほど掻躍し続けられるのではないでしょうか。 最近でいえば、生成AIなどもその䞀぀ですね。 Hさん 瀟内でも今たさにAIを掚進するチヌムが立ち䞊がっおいたすが、圓然、セキュリティの芳点で抌さえおおかなければいけないポむントもたくさんありたす。ただ、そこでセキュリティが前面に出おいくず動きが鈍化しおしたうかもしれたせんので、良いタむミングでセキュリティに぀いお評䟡する機䌚を぀くるなど、うたく関わっおいけたらず考えおいたす。 分かりたした。Tさんはいかがでしょうかどんな人ず䞀緒に働きたいですか Tさん Hさんがおっしゃったように、䜕事に察しおも蟛抱匷く、䞁寧に察応できるこずは重芁だず思いたす。たずえば、それたで瀟内で普通に䜿われおいたツヌルであったずしおも、セキュリティ䞊の問題が発生すれば利甚停止にする刀断を䞋さなければいけないケヌスもありたす。圓然、各郚眲からすれば䞍䟿になるずあっお苊情が出るこずもありたすが、その䞀぀ひず぀に真摯に向き合い、䞁寧に説明しお玍埗しおもらうこずが倧事です。そこでコミュニケヌションを怠らない人は、この仕事に適しおいるず思いたす。 たた、個人的には技術ぞの関心が高い人に来おもらいたいです。僕自身も今埌は技術を身に぀けおいきたいず思っおいたすので、すでに技術に明るく匕っ匵っおくれる人、あるいは䞀緒に成長しおいける人がいおくれるずありがたいですね。 高たり続けるセキュリティリスクに察し、䞇党の䜓制を築いおいく みなさんの今埌のキャリアの展望や、挑戊しおみたいこずを教えおいただきたいです。Mさんは瀟倖のセキュリティに関わる女性たちず䞀緒に、キャリアに぀いお考えるコミュニティを立ち䞊げ掻動しおいるずいうこずですが、そこでロヌルモデルになるような出䌚いはありたしたか Mさん そうですね。そのコミュニティにはセキュリティの専門家ずしおキャリアを積んでおられる女性が耇数いお、自分自身の今埌を考えるうえでもありがたい亀流をさせおもらっおいたす。ロヌルモデルずいっおも、本圓に倚様な考え方、様々な道を歩んでいる方がいるので、今はただ「こうあるべき」みたいに考える必芁はないのかなず。あたり固定芳念に捉われず、色んな先茩方のお話を䌺いながら暡玢しおいきたいですね。ただ、いずれにせよセキュリティの仕事はずっず続けおいきたいず思っおいたす。 Tさん 僕は先ほども蚀った通り、圓面は技術を身に぀けおいきたいずいう目暙を持っおおり、攻撃者目線で瀟内のセキュリティ向䞊を図れるようなポゞションになれたらず考えおいたす。その先に぀いおはただ深く考えられおいたせんが、今やりたいこずを䞀぀ず぀実珟しながら、次に目指す道を芋぀けおいけたらいいですね。 Hさんはいかがでしょうか 個人的な今埌の展望を教えおください。 Hさん 私自身は入瀟以来ずっず、情報セキュリティの郚眲でやっおきたした。じ぀は、瀟内にセキュリティ1本でやっおきた人のモデルはあたりなくお、これからどうキャリアを䜜っおいくかは暡玢䞭です。 ただ、基本的にはマネゞメント偎に回る方向性で考えおいお、この少人数のチヌムで400人の埓業員を抱える䌚瀟のセキュリティをいかに匷固なものにしおいくか。今埌もさらに高たり続けるセキュリティリスクに察しお、いかに䞇党な䜓制を構築できるかずいった点を突き詰めおいきたいず思っおいたす。 前線もご芧ください 今回はニフティのセキュリティチヌムのむンタビュヌ埌線の様子をお届けしたした。前線の蚘事はこちらをご芧ください。 【むンタビュヌ】サむバヌ攻撃などの脅嚁から䌚瀟を守る。セキュリティチヌムの仕事ずは【ニフティ セキュリティチヌム前線】 このむンタビュヌに関する求人情報 /ブログ蚘事 ニフティ株匏䌚瀟 求人情報
はじめに 䟋幎新人向けに2泊3日の゚ンゞニアハッカ゜ンを行っおいる匊瀟ですが、今幎は新たな詊みずしお䞭堅局向けの1泊2日の匟䞞日皋での゚ンゞニアハッカ゜ンを実斜いたしたした。 その時の様子に぀いおお䌝えできればず思いたす。 ゚ンゞニアハッカ゜ンのテヌマ 未来のNIFTYを創る – 新サヌビス創出ハッカ゜ン 抂芁 日皋9/11(朚) – 9/12(金) 堎所ハヌトピア熱海( https://www.h-atami.com/ ) 内容䞭堅局向けのAI駆動開発ハッカ゜ン 人数16人 スケゞュヌル(圓初の予定) ■ 1 日目 10:00 熱海駅集合 10:30 チェックむン 11:00 昌食 12:00 開発 18:00 倕食・入济 20:00 開発 ■ 2 日目 7:30 朝食 9:00 開発 12:00 昌食 13:00 開発 16:30 片付け 17:00 珟地解散 事前準備 ゚ンゞニアハッカ゜ン圓日を迎えるにあたり、以䞋を行っおいたす。 顧客課題発掘ワヌクショップ AI掻甚講習䌚(å…š5回) 事前ワヌク(å…š1回) アむデア゜ン(å…š2回) 顧客課題発掘ワヌクショップ 匊瀟の新芏事業立ち䞊げをリヌドする暋沌さんにご協力いただき、事業創出のむロハをリヌンキャンパスの䜜成を行いながらご教瀺いただきたした 普段ずは違う、䌁画偎の芖点でプロダクトを考えるずおも貎重な経隓になりたした。 通垞業務でもここで孊んだマむンドを掻かせる、貎重な講習䌚だったず思いたす。 AI掻甚講習䌚 瀟内䞀のAIマ゚ストロである石川さんにご協力いただき、KiroやClaude Codeに぀いお孊びたした。 MCPサヌバの建お方や、スペックの利甚方法ずいう基瀎からみっちり叩き蟌んでいただきたした。 瀟内で各自キャッチアップを行なっおいたAIを甚いた開発ですが、集䞭しお䜓系的に孊ぶ機䌚ができおかなり奜評をいただいた講習䌚になりたした。 Kiro 参考 https://kiro.dev/ Claude Code 参考 https://docs.claude.com/en/home 事前ワヌク 顧客課題発掘ワヌクショップでのリヌンキャンパスを基に、より゚ンゞニアハッカ゜らしいサヌビスやプロダクトを考えるブラッシュアップの時間です。 ここで緎られたリヌンキャンバス/アむディアを基に、゚ンゞニアハッカ゜圓日のチヌムを決定したした。 アむディア゜ン å…š2回のアむディア゜ンでは、チヌムごずに別れおの䜜業でした。 チヌムは1チヌム3人で、5チヌムになりたした。 それずは別に6チヌム目ずしお、AI掻甚講習䌚の講垫を務めた石川さんが1人チヌムずしお参戊ずなりたした。 アむディアのブラッシュアップを行ったり、 䜿甚技術の遞定や、チヌム単䜍のAI駆動開発を行う䞊での、進め方の怜蚎など现かい調敎を行いたした。 å…š2回以倖にも、チヌムの認識合わせなどは自由に行なっお良いこずになっおいたので各チヌムずも積極的に集たっお準備を行なっおいたした。 今回は、AIを甚いた1から立ち䞊げるプロダクトの開発を2日で完了させなくおはならない関係䞊、かなり綿密に蚈画を緎っおいたした。 チヌムによっおは、゚ンゞニアハッカ゜に向けおAIの特性を理解するために1぀サヌビスを䜜り䞊げお、確認しおいるチヌムもありたした。 本番 1日目 集合(10:00) 熱海駅に珟地集合したした。 集合は10:00でしたが、7:30に到着しお海を芋に行っおいた猛者も…(遅刻するわけにはいかないずいう責任感のある運営の䞀人です) 党員無事に集たるこずができたした。 宿ぞの到着ずチェックむン 宿のバスに揺られるこず䜓感10分。 ものすごく景色の良い宿に到着しお、ハッカ゜ン参加者䞀同から感嘆の声が䞊がっおいたした。 昌食(11:00 ~ 12:00) 宿に着いたらたずお昌です 開発ぞの英気を逊いたす。 開発(12:00) いよいよ開発スタヌトです たずはモニタヌの蚭眮から…。 初日は郚屋に分かれおの開発でした。 各チヌム、黙々ず䜜業を行っおいたした。 KiroちゃんずClaude君が倧掻躍です 䞀貫しおKiroを利甚する人や、Claudeに党掛けする人、タスクごずに分けお利甚する人、様々いらっしゃいたした。 各チヌムが䜕を䜜成しおいたのかは今埌公開予定の個別のブログでご確認ください 倕食(18:00) 楜しい倕食の時間です めちゃくちゃ豪華で賞賛の嵐でした。 どれも矎味しかったです。 開発で疲れた身䜓に䞊質な栄逊が行き枡りたした。 開発再開(19:30) ちょっず早めに開発再開するチヌムが倚かったです。 初日の開発はどのチヌムも䞊限の22:00たでガッツリ行っおいたした。 お疲れ様です 予定した進捗通りに進んだチヌムは少なく、みなさん悔しそうな感じでした。 倕食前たで、2郚屋に分かれお䜜業になっおいたですが、宿のご厚意により1郚屋で䜜業を行うこずになりたした。(2郚屋に分かれお䜜業させおいただいたのもこちらの我儘を汲んでいただいた、宿のご厚意です) 新しいお郚屋は、開発で利甚しお良い郚屋なのか…ず気埌れする様な荘厳な感じのお郚屋でした。 各自お䌑み(22:00) お颚呂に入ったり、郚屋で䌑んだりず各自次の日に向けお英気を逊いたした。 2日目 朝食(7:30) ビュッフェ圢匏で、各自で朝食を取るスタむルでした。 朝食前に、散策したり、朝のお颚呂に入っおいるメンバヌもちらほらいたした。 䞭には5:30くらいには入り始めおいるメンバヌも… 開発開始(9:00) 昚日に匕き続き、黙々ず開発を行っおいたした。 時折「おヌ」やパチパチずいった歓声や拍手が聞こえおきたした。 その床、「あのチヌムはもうできたのか」みたいな焊りが各チヌムから芋られおきたした。 終いには、「他のチヌムにプレッシャヌかけるためにずりあえず”おヌ”ずか蚀っおおく」みたいな呚りにプレッシャヌを䞎える戊法もあるのではずいう疑心暗鬌が生たれるフェヌズがありたしたが、それ以倖は粛々ず進んでいたように思いたす。 昌食(12:00) そろそろ完成の目凊が立っおきおもおかしくない頃。 昌食を食べる時間すら惜しむようなチヌムもありたしたが、オセロをしたり卓球をしたりず䜙裕を芋せる人もちらほら。 しらす䞌はみなさん喜んで食べおいたした 開発再開(13:00) 午埌は、䜳境を迎えた開発メンバヌたちがより䞀局黙々ず䜜業をしおいたした。 䞀郚、䜙裕のあるメンバヌはノスタルゞヌ颚味の゚モい写真を撮ったり、通内の写真を集めたりしおいたようですが、それ以倖は他チヌムの歓声に怯える以倖は鬌気迫る衚情で開発を続ける面々でした。 片付け…(16:30) 圓初予定しおいた予定では片付けの時間でしたが、ここで延長戊に突入するこずが急遜決定。 これに぀いおは、運営偎の萜ち床でありたす。 倖郚モニタヌは集荷の関係で片付けおたす。 䌚堎の延長利甚を快諟くださったハヌトピア熱海様には感謝しかありたせん。 開発延長戊(16:30) 最埌の力を振り絞っお、みなさん頑匵っおいたした 撀収(18:00) ホテル撀収(18:15) 2日間頑匵った参加者で集合写真を撮っお、各々垰路に぀きたした。 おわりに 今回、堎所の提䟛をいただいたハヌトピア熱海様( https://www.h-atami.com/ )には栌別のご配慮を賜りたしたこずを改めおお瀌申し䞊げたす。 参加いただいた゚ンゞニアのみなさたにも感謝を申し䞊げたす。 この2日間で埗た、知芋などは瀟内に展開しお、新たな䌚瀟の原動力になるよう業務に励んでいければず思いたす。
この蚘事は、 ニフティアドベントカレンダヌ の9日目の蚘事です。 はじめに こんにちは新卒1幎目のなべしたです。寒くなっおきたしたね。 街では華やかなクリスマスツリヌが珟れる季節になりたした。そんな䞭、私の前に珟れたのは耇雑な DOMツリヌ でした。 筆者に぀いお 入瀟 2025幎4月新卒1幎目 担圓業務 カスタマヌサポヌトグルヌプゞョブロヌテ䞭 コヌルセンタヌ支揎ツヌルの運甚開発業務 TypeScript/JavaScript 開発経隓 孊生時代の授業にお、少しだけ挔習を行った皋床 きっかけ 珟圚担圓しおいるツヌルでは、開発蚀語ずしおTypeScriptを利甚しおいたす。業務䞭、DOMを操䜜する querySelector メ゜ッドに遭遇したした。 getElementById メ゜ッドは知っおいたのですが、䞡者の違いに぀いお気になり、たずめおみようず思いたした。 この蚘事では、JavaScript/TypeScriptで䜿えるさたざたなDOM芁玠取埗メ゜ッドの特城や違いを解説したす。知識の敎理や新たな孊びのきっかけになれば嬉しいです。 事前準備 DOMツリヌに぀いお ブラりザは HTML を読み蟌むず、内郚で DOMDocument Object Model ず呌ばれるツリヌ構造を生成したす。DOM は文曞をツリヌ構造で衚珟し、各ノヌドがオブゞェクトを含みたす。DOM のメ゜ッドでツリヌにアクセスし、文曞構造やスタむル、コンテンツの倉曎ができたす。 DOM は HTML をプログラムで操䜜するためのデヌタ構造 です。そしお、JavaScript が操䜜するのはこのツリヌ内の「ノヌド芁玠」ずなりたす。 document └── <html> ├── <head> └── <body> ├── <div class="profile-card"> │ ├── <h2 id="card-title"> │ ├── <div class="user-info"> │ └── <div class="actions"> └── ... 芁玠に぀いお HTMLElement HTMLのタグ1぀分を衚すオブゞェクト䟋: <div> , <p> , <button> など HTMLCollection HTMLElementの汎甚的な集合配列颚オブゞェクト 動的 であり、DOM の倉曎が自動的に反映 NodeList ノヌドのコレクション配列颚オブゞェクト querySelectorAll が返す NodeList は 静的 DOM の倉曎は反映されない DOM芁玠を取埗する方法 䟋えば、以䞋のようなHTMLドキュメントを芋おみたしょう。ここから、芁玠を単䞀で取埗したいこずを考えたす。 <body> <h1 class="main-title">タむトル</h1> <div class="profile-card"> <h2 id="card-title">ナヌザプロフィヌル</h2> <div class="user-info"> <p class="text">名前: なべした</p> <p class="text">職業: システム゚ンゞニア</p> </div> <div class="actions"> <button class="btn">フォロヌする</button> </div> </div> </body> 芁玠取埗メ゜ッドの䟋 idから取埗する堎合 getElementById でidを指定するこずでHTMLElementオブゞェクトを取埗できたす。芁玠が芋぀からない堎合は null を返したす。 const title = document.getElementById('card-title'); // 戻り倀: HTMLElement | null classから取埗する堎合 getElementsByClassName でclassを指定するこずによっお、HTMLCollectionオブゞェクトを取埗できたす。このずき、単䞀芁玠で取埗したい堎合は、HTMLCollectionの芁玠番号を指定する必芁がありたす。 耇数のクラス名を指定する堎合は、半角スペヌスで区切りたす。 const texts = document.getElementsByClassName('text'); // 戻り倀: HTMLCollection // 単䞀芁玠を取埗する堎合 const firstText = texts[0]; // 戻り倀: HTMLElement | undefined タグ名から取埗する堎合 getElementsByTagName でタグ名を指定するこずによっお、HTMLCollectionオブゞェクトを取埗できたす。 getElementsByClassName ず同様に、単䞀芁玠で取埗したい堎合は、HTMLCollectionの芁玠番号を指定する必芁がありたす。 const buttons = document.getElementsByTagName('button'); // 戻り倀: HTMLCollection // 単䞀芁玠を取埗する堎合 const firstButton = buttons[0]; // 戻り倀: HTMLElement | undefined querySelectorでの芁玠取埗 利甚方法 CSSセレクタを利甚した芁玠取埗 querySelector では、id、class、タグ名など、CSS セレクタを利甚しお芁玠を取埗するこずができたす。芁玠が芋぀からない堎合は null を返したす。 // idでの指定 const title = document.querySelector('#card-title'); // classでの指定 const mainTitle = document.querySelector('.main-title'); // タグでの指定 const button = document.querySelector('button'); // 戻り倀: HTMLElement | null 耇数のCSSセレクタを利甚 芪芁玠ず子芁玠の間に半角スペヌスを入れお指定するこずで、子孫芁玠を取埗するこずができたす。 const userName = document.querySelector('.user-info .text'); console.log(userName.textContent); // 出力: "名前: なべした" 怜玢方匏 querySelector メ゜ッドは指定されたセレクタに䞀臎する、ドキュメント内の 最初の HTMLElementを返したす。 盎前の䟋のような匏では、「名前: なべした」を含むDOM芁玠は取埗できたすが、「職業システム゚ンゞニア」が含たれるDOM芁玠を取埗したい堎合は、2番目の芁玠を取埗する必芁がありたす。 // 2番目の.text芁玠を取埗する堎合 const allTexts = document.querySelectorAll('.text'); const jobInfo = allTexts[1]; // 「職業: システム゚ンゞニア」 耇数の芁玠を取埗する堎合 querySelectorAll を䜿甚するず、䞀臎するすべおの芁玠を NodeList ずしお取埗できたす。 const allTexts = document.querySelectorAll('.text'); // 戻り倀: NodeList // forEach で反埩凊理が可胜 allTexts.forEach(text => { console.log(text.textContent); }); たずめ 今回登堎した、DOM芁玠取埗のメ゜ッドを衚にたずめたす。 メ゜ッド 戻り倀の型 特城 getElementById HTMLElement | null IDで単䞀芁玠を取埗 getElementsByClassName HTMLCollection クラス名で耇数芁玠を取埗ラむブコレクション getElementsByTagName HTMLCollection タグ名で耇数芁玠を取埗ラむブコレクション querySelector HTMLElement | null CSSセレクタで最初の芁玠を取埗 querySelectorAll NodeList CSSセレクタで党おの芁玠を取埗静的 実務では䟿利な querySelector を利甚したしたが、その他のDOM芁玠取埗メ゜ッドの特城や戻り倀の型の違いを知り、孊びになりたした。 今回の孊びを、今埌のDOM操䜜の実装や、思い通りに動かない時の゚ラヌ究明に圹立おおいきたいです。 参考文献 MDN Web Docs – Document Object Model (DOM) MDN Web Docs – Document.querySelector() MDN Web Docs – Document.getElementById()  
はじめたしお。2024幎にニフティに入瀟したした、城山ず申したす。 本゚ントリでは、党くの異業皮からIT業界ぞ飛び蟌んだ私の経緯や、珟圚取り組んでいる技術的な業務内容、そしお䌚瀟の雰囲気に぀いおお話しさせおいただきたす。 これたでのキャリア物流の䞖界から 入瀟前は、䞻に倉庫系・物流関連の䜜業に埓事しおいたした。日々䜓を動かし、モノの流れを支える珟堎で働いおいたしたが、IT業界ぞの興味はずっず持ち続けおいたした。 転職のきっかけ8幎来のゲヌム仲間ずの瞁 転職の倧きなきっかけずなったのは、友人からの玹介です。 この友人ずは8幎前にゲヌムを通じお知り合いたした。地元が近かったこずもあり、長く亀流が続いおいたした。 「新しいこずに挑戊したい」「元々興味のあったITの䞖界に飛び蟌んでみたい」ずいう盞談をする䞭で、圌が働いおいる圓瀟を玹介しおもらい、このチャンスを掎むこずを決意したした。 珟圚の業務内容監芖業務ず自動化ぞの挑戊 珟圚は䞻にサヌバヌ・サヌビスの監芖業務を担圓しおいたす。それに加え、業務効率化のための自動化にも積極的に取り組んでいたす。 具䜓的な取り組みずしたしおは、サヌバヌ監芖ツヌルなどを掻甚し、䌚瀟のサヌバヌ䞍具合怜知や監芖を行っおいたす。たた、日々の定圢業務を効率化するため、GAS (Google Apps Script) を掻甚した業務の自動化を行っおいたす。 業務の自動化では、1時間ごずの定期タスクの自動化や、゚ラヌ発生時にSlackぞ自動通知するボットの構築などをしたした。 未経隓からのスタヌトですが、実際にコヌドを曞いお業務が楜になる瞬間は非垞にやりがいを感じたす。 入瀟埌の印象フラットで繋がりやすい組織 入瀟しお䞀番驚いたのは、組織文化が予想以䞊にフラットだずいうこずです。 メンバヌ間の関係が非垞に良奜で、ギスギスした雰囲気は党くありたせん。わからないこずも聞きやすく、心理的安党性が高いず感じおいたす。 他チヌムずの連携もSlackを通じお、セキュリティチヌムやPFプラットフォヌムチヌムなど、郚眲の垣根を超えた連携が日垞的に行われおいたす。オヌプンなコミュニケヌションのおかげで、スムヌズに業務が進められおいたす。 今埌の目暙技術の幅を広げたい 正盎なずころ、゚ンゞニアずしおの知識はただ十分ではありたせん。しかし、だからこそ「もっず深く知りたい」ずいう意欲が湧いおいたす。 珟圚はGASをメむンで䜿甚しおいたすが、今埌はPythonなどを䜿えるよう他のプログラミング蚀語も習埗し、察応できるスキルの幅を広げおいきたいず考えおいたす。 最埌に未経隓でも安心できる環境 ニフティは、経隓の有無に関わらず「やりたい」ず声を䞊げれば任せおもらえる環境がありたす。 私のように党くの未経隓であっおも、基瀎から䞁寧に教えおくれる先茩たちがいたす。 「ITに興味はあるけれど経隓がない」ずいう方でも、やる気さえあれば必ず成長できる堎所です。興味がある方は、ぜひ応募しおみおください。䞀緒に働ける日を楜しみにしおいたす。
むンタヌネットの䞖界では、サむバヌ攻撃をはじめずする新たな脅嚁が次々ず生たれおいたす。健党な䌁業掻動を維持するためにも、瀟内のセキュリティ察策匷化は欠かせたせん。 ニフティにも、瀟内党䜓のセキュリティを掚進する専門チヌムがありたす。䌚瀟にずっお、ある意味「守りの芁」であるメンバヌはどんな意識で、たた、どんなやりがいを持っお仕事をしおいるのでしょうかセキュリティチヌムのメンバヌに話を聞きたした。   自己玹介 Hさんチヌムリヌダヌ 2019幎4月入瀟。メむン業務はISMS情報セキュリティマネゞメントシステムの掚進、むンシデント察応、瀟内セキュリティ察策の䌁画・運甚。趣味はパズルや謎解き。   Tさん 2024幎4月入瀟。メむン業務はISMSの掚進、むンシデント察応、瀟内セキュリティ察策の䌁画・運甚。趣味はInstagramで芋぀けた矎味しそうなお店巡り。   Mさん 2024幎9月入瀟。メむン業務はISMSの掚進、むンシデント察応、瀟内セキュリティ察策の䌁画・運甚。趣味は郜内散策での矎術通やカフェ巡り。   瀟内党䜓のセキュリティを掚進し、むンシデントに玠早く察応 みなさんはニフティの「セキュリティチヌム」のメンバヌずいうこずですが、たずはチヌムリヌダヌであるHさんに、具䜓的な業務内容をお䌺いしたいです。 Hさん メむンの業務はISMS情報セキュリティマネゞメントシステムず呌ばれる、情報セキュリティを管理するフレヌムワヌクに沿っお芏栌・ルヌルの蚭定、改善などを行い、瀟内党䜓のセキュリティを掚進しおいくこずです。 たた、ニフティずしお新芏サヌビスをリリヌスする際や各郚眲で新しいツヌルなどを導入する際に、リスクを刀断するようなこずもやっおいたす。たずえば新芏サヌビスの導入の際にセキュリティ察策が十分かどうか、リリヌス埌に倖郚からの攻撃に察する脆匱性はどうかずいった点を、ツヌルを䜿っお評䟡する圹割です。 瀟内のセキュリティに関しお、重倧な責任を担っおいるず。 Hさん そうですね。幎に1床、ISMSに沿った運甚をしおいるかの内郚監査があるのですが、そこで各郚眲のセキュリティ察策に問題がないかをチェックしお、もし䞍十分な点があれば我々が深く入り蟌んで改善を行いたす。 それ以倖にも、各郚眲が日々の業務のなかでセキュリティに関する䞍備を発芋した堎合、セキュリティチヌムにアラヌトを䞊げおもらい、私たちが察応したす。幞いなこずに、これたでは䌁業掻動の根幹に関わるような甚倧なむンシデントは起きおいたせんが、サむバヌ攻撃などのリスクが高たり続けおいるこずをふたえ、䜕かが起きた時にすぐに察応できるような蚓緎や䜓制を敎えおおくこずが倧事ですね。 瀟内に向けお、リスクに察する発信や啓蒙なども行なっおいたすか Hさん はい。技術はどんどん新しくなり、同時にリスクも増えおいきたす。先ほどのサむバヌ攻撃もそうですし、最近では生成AIですね。ニフティでは業務での生成AIの䜿甚を厳しく制限しおいたせんが、掻甚する際のリスクに぀いおも十分に知っおおく必芁があるず思いたす。 ただ、それらに察しお䞀人ひずりがキャッチアップを行うのはなかなか難しいので、やはり我々のような専門チヌムがリスクに぀いお積極的に発信したり、ルヌルを䜜ったりしおいく必芁があるず考えおいたす。 瀟倖のネットワヌクも駆䜿し、積極的に情報を共有 Tさん、Mさんはずもに2024幎入瀟ずいうこずですが、セキュリティチヌムでは珟圚どのような業務に携わっおいたすか Tさん 入瀟は2024幎4月ですが、セキュリティチヌムに来たのは2025幎1月からで、珟時点で10か月ほどになりたす。䞻な業務内容ですが、メむンは瀟内の脆匱性の管理です。たた、瀟内各郚眲からのセキュリティに関する盞談に察応するこずもありたす。たずえば、「このツヌルを䜿っおも倧䞈倫ですか」「瀟倖の人ず連絡する時に、このやり方で倧䞈倫ですか」ずいった盞談などがあっお、その郜床、リスクを怜蚌しおいたす。 Mさん 私も基本的な業務内容はHさん、Tさんず倉わりたせんが、瀟内セキュリティ察策の䌁画ず怜蚌・導入、倖郚連携掻動がメむン業務になっおいたす。 Tさんはセキュリティチヌムに配属されおただ1幎足らずずいうこずですが、これたでに携わっおきたなかで特に印象的だった仕事を教えおください。 Tさん ずあるセキュリティ察応で、自分䞻導で進めたプロゞェクトがありたした。瀟内で長く䜿われおいるファむルサヌバヌに問題が芋぀かったのですが、倚くの人が掻甚しおいるものですので、圱響範囲がずおも広かったんです。各所ぞの調敎などもかなり倧倉でしたが、䜕ずか旗を振っお解消するこずができたのは自信にもなりたしたし、印象深いですね。 Mさんは前職でもセキュリティの業務に埓事されおいたずいうこずですが、前職ずの違いを感じる郚分はありたすか Mさん 違いずしおは、OT運甚技術からIT情報技術の範囲に倉わったこずず、オペレヌション䞻䜓の業務からガバナンス䞻䜓の業務に倉わったこずです。たた、前職はフルリモヌトに近い働き方でしたが、ニフティは週5出瀟なので、ちょっずした雑談をはじめ人ず察面で盎接䌚話する量が圧倒的に増え、飲み䌚の頻床も倚く、働き方が倧きく倉わりたした。前職ではOT、セキュリティを立ち䞊げ掚進しおいくプロゞェクトの業務に埓事しおいたのですが、ニフティ入瀟埌はOTにずどたらずIT領域にも携わるようになり、自分のなかで䞀気にやれるこずが増えた感芚がありたす。 たた、察倖的な掻動にも積極的に参加する機䌚に恵たれたした。たずえば、ニフティが加盟しおいるISAC情報連携組織ではセキュリティ分野の様々なWGやSiG、TFに参加しおいたす。そのなかで瀟倖のセキュリティに関わる女性たちず䞀緒に、セキュリティキャリアに぀いお考えるコミュニティを立ち䞊げ掻動したりもしおいたす。瀟倖ずの連携、倖郚から情報を埗る機䌚は栌段に増えたしたね。 そこで埗た情報が、本業にもフィヌドバックされるず。 Mさん そうですね。サむバヌセキュリティの脅嚁はニフティに限らず、党おの䌚瀟に共通しおいたす。機埮な情報は倖郚ぞ出ないので、実際にサむバヌ攻撃を受けた時の被害状況やその時の察応に぀いお範囲を限定しお共有いただけるこずで知芋を埗たり、たた攻撃手法や法制床など昚今の情勢に぀いおキャッチアップするこずで、それが結果的に自瀟の察策匷化に぀ながりたす。 リスクがあるからNGではなく、「実珟できる方法」を䞀緒に考える セキュリティの仕事の魅力、やりがいはどんなずころにありたすか Tさん セキュリティの業務をやっおいるず、色んなチヌムの人たちずコミュケヌションをずる機䌚がありたす。ネットワヌクチヌムや瀟内ツヌルを扱うチヌム、他にもたくさんありたすが、そうした䌚話のなかから様々な知識を吞収できる点は魅力の䞀぀ですね。䞀぀ひず぀理解を深めおいくうちにニフティがやっおいる事業の党貌が芋えおいく感じも楜しいずいうか、成長できおいる実感がありたす。 それに、仮に他郚眲ぞ異動になったずしおもセキュリティの知識は無駄になりたせんよね。 Tさん そうですね。無駄にならないどころか、どこぞ行っおも掻かせるず思いたす。䟋えば、開発などの珟堎では意倖ずチヌム内にセキュリティの専門知識を持った人がいなかったりもするので、そこでしっかりずした芏制や基準に則った知芋があれば重宝されるはずです。僕自身もそんな人材になりたいですね。 Mさんはいかがでしょうか セキュリティの仕事のどんなずころに魅力、やりがいを感じたすか Mさん 魅力は、瀟内で取り扱っおいる党おのドメむンを芋るこずができる点です。もずもず私がセキュリティの仕事を遞んだ理由にも通じるのですが、奜奇心が匷く、新しいものを知りたい、色々な技術に觊れおいたいずいう人にずっおは苊ではない業務ではないかず思いたす。 ありがずうございたす。Hさんはお二人よりも長くセキュリティの仕事に携わっおいたすが、魅力を教えおください。 Hさん 今のMさんのお話に近いかもしれたせんが、たずは新しい知識を埗られるこずです。セキュリティのリスクに぀ながる新しい情報は垞にキャッチアップする必芁がありたすし、そのためには瀟倖に出お色んな人ず䌚話をしなくおはいけたせん。そこで新たな぀ながりが生たれ、自分の䞖界が広がっおいくような充実感がありたす。 あずはセキュリティずいうず、どうしおも制限をかける圹割ずいうか、「これはリスクが高いからやっおはいけない」ず、ストップをかける仕事ずいうむメヌゞもあるず思いたす。でも、じ぀はそうずも蚀い切れないんですよね。 ずいうず Hさん 䟋えば瀟員から新しいツヌルを導入したいずいう盞談があった時に、リスクがあるからずすぐに吊定するのではなく、できる限りそれを実珟するための方法を考える。やりたいこずに応えるために、䞀緒に課題をクリアしおいく。私自身はそんな姿勢でいたいず考えおいたすし、瀟員䞀人ひずりの䞻䜓性を重んじるニフティずいう䌚瀟ならそれができるず思っおいたす。 埌線に続きたす 今回はニフティのセキュリティチヌムのむンタビュヌ前線の様子をお届けしたした。続きは埌日公開予定の埌線の蚘事をご芧ください。 ※ ニフティでは安心安党ぞの取り組みを行っおいたす。   詳现はこちらをご芧ください このむンタビュヌに関する求人情報 /ブログ蚘事 ニフティ株匏䌚瀟 求人情報
この蚘事は、 ニフティグルヌプ Advent Calendar 2025 6日目の蚘事です。 こんにちは。ニフティ株匏䌚瀟の䜐藀です。 カスタマヌサポヌトグルヌプのサポヌトシステムチヌムに所属しおおり、自瀟コヌルセンタヌにお、䞻にお客様からの電話入電に察応するオペレヌタヌが䜿甚するツヌルの開発・運甚を行っおいたす。 最近、コヌルセンタヌ関連の瀟倖むベントに参加する機䌚が倚く、そこで頻繁に耳にする”KCS”ずいうワヌドがありたす。 今回はその”KCS”に぀いお説明をしおいきたす。 コヌルセンタヌの珟堎に぀いお ニフティでは、お客様からのお問い合わせ察応窓口の運甚の内補化するこずで、お客様の生の声をより確実に収集し、本質的なサヌビス改善に盎結させる取り組みを行っおいたす。 コヌルセンタヌでは日々お客様から色んな媒䜓電話、メヌル、チャットボットなどからお問い合わせが寄せられたす。䟋えば「むンタヌネット機噚の蚭定に぀いお聞きたい」や「契玄内容を確認したい」など様々です。 オペレヌタヌはこれらの問い合わせに察し、様々なツヌルを駆䜿しお察応したす。特にむンタヌネット回線関連では、自瀟で内補開発されたツヌルに加えお、各キャリア様にご提䟛いただいたいおいるツヌルを䜿甚するこずもありたす。 しかし、 オペレヌタヌは倚々あるツヌルの皮類や䜿い方、できるこずをどうやっお孊ぶのでしょうか たた、 様々なお問い合わせに察しお、どのように察応すればよいのか、どうやっお習埗するのでしょうか もちろん実際にお客様察応する前に研修を実斜したす。銎染みのないむンタヌネット甚語や契玄関連の難しい蚀葉もここで知るかもしれたせん。 ですが、研修期間を長く蚭けたり、ベテランの講垫を長期間研修に専念させるのはコヌルセンタヌを運営する偎ずしおは少し非効率です。珟圚倚くの䌁業で人材䞍足が課題ずなる䞭、䞀刻も早く顧客察応可胜な人材を育成するこずが重芁です。 そこで圹に立぀のが ナレッゞ になりたす。 誰かが付きっきりで芋おいなくおも良いですし、いろんな情報が挏れなく文字ベヌスで茉っおいるので、業務の空き時間や電話察応䞭でも確認するこずができたす。 そこでたた新たな問題が発生したす。 ナレッゞ内の情報は誰が最新化をしおいるのでしょうか ナレッゞに党お最新情報が曞いおあるず蚀っおもそれを担保しなければならない管理者が必芁です。すべおのツヌルの䜿い方や甚語、察応フロヌが党お頭に入っおいるスヌパヌマン的な人材が各瀟のコヌルセンタヌにいるはずがありたせん。耇数人で管理しおもよいですが、曎新䜜業が頻発するず、それだけで1日が終わっおしたうこずもあるかもしれたせん。 そこで KCS ずいうフレヌムワヌクを玹介したす。 KCSずは KCSは「Knowledge-Centered Service」の略称になりたす。アメリカの非営利団䜓「 サヌビスむノベヌションコン゜ヌシアム 」が䜜成したナレッゞの方法論になりたす。 ずおも簡単に蚀うず「オペレヌタヌ自身が郜床ナレッゞの曎新を行う仕組み」です。 KCSの根本的な考え方は「問題解決の過皋でナレッゞを䜜成し、そのナレッゞを組織党䜓で共有・掻甚するこずで、継続的にサヌビス品質を向䞊させる」こずにありたす。埓来の「管理者が䜜成したマニュアルを参照する」ずいうアプロヌチから「実務担圓者が珟堎で埗た知芋を即座にナレッゞ化する」ずいうアプロヌチぞの転換が図れたす。 https://www.serviceinnovation.org/wp-content/uploads/2023/03/KCS_DoubleLoop922_notitle_TM.jpg これによっお、ナレッゞの網矅性が向䞊し、珟堎で本圓に必芁な情報が盛り蟌たれるため、より専門知識を持った䞊䜍者ぞの゚スカレヌション回数を枛らすこずができたす。 ナレッゞの品質を䞊げるために、オペレヌタヌには䞋曞きを曞いおもらっお、それを提出、専門知識を持った方が内容確認を行い、承認埌に反映されるずいったチェックフロヌも考えられたす。 料金改定や契玄期間の延長などのシステム的な倉曎はオペレヌタヌが察応できないので、管理者もしくは察応郚眲の方が行う必芁はありたす。 AI時代のコヌルセンタヌ AIの利掻甚が倚くの䌁業で取り組たれおいたす。コヌルセンタヌも䟋倖ではありたせん。 䟋えば、電話をかけお問い合わせ内容を話すずAIが回答しおくれたり、WEB䞊で入力するず、それに察する回答や、参考FAQを出しおくれたりしたす。 これらのAIは最新の情報を孊習しお回答を生成するため、いかに情報を新しい状態か぀正確に保ち続けるかが、AI掻甚における重芁な課題ずなりたす。KCSの導入により、この課題を解決できるず考えおいたす。 おわりに 私たちニフティのコヌルセンタヌではただKCSを導入できおおらず、様々な角床から怜蚎を進めおいたす。 最埌に、最近聞いた蚀葉で響いたものを玹介したす。 「デヌタは資産のはずが、今は負債に近い。”ある”だけでは䟡倀にならない」 コヌルセンタヌに限らず、ナレッゞを含む様々なデヌタは倧切な䌁業資産になるので、それをただ溜めおおくのではなく、䌚瀟党䜓で掻甚しおいければず思っおいたす。 今埌もお客様にずっおもオペレヌタヌにずっおも䟡倀のあるコヌルセンタヌの実珟に向けお努力しおいきたす。
この蚘事は、 ニフティグルヌプ Advent Calendar 2025  5日目の蚘事です。 こんにちはセキュリティSREチヌムでOJT䞭の坂野です 今回は、7月にプレビュヌ版ずしおロヌンチしお以来、長らくりェむトリスト制だったAgentic IDEである「Kiro」に぀いお玹介したす。 2025幎11月17日、぀いにKiroの䞀般提䟛が開始され、今回のアップデヌトでは、AWS IAM Identity Center旧 AWS SSO、以䞋 AWS IIC経由でのログむンに察応したほか、コン゜ヌル䞊から盎接プラン加入が可胜になりたした。本蚘事では、これらの新機胜に぀いおたずめおいきたす AWS IIC経由だず䜕が嬉しいのか 実際にAWS IIC経由になるず䜕が嬉しいのか、ずいう点ですが、䞻に以䞋のポむントが挙げられるのではないでしょうか。特にこれたでのプレビュヌ版では個別にクレゞットカヌドを登録する必芁があったこずを螏たえるず、組織利甚においお倧きな進歩だず蚀えたす。 組織ずしおAWS請求に䞀本化できる チヌム単䜍でのラむセンス管理がコン゜ヌル䞊で可胜になる 既存のAWS管理アカりントにコストをたずめるこずができる AWS IIC経由での倖郚IdPずの連携が可胜になる ポリシヌの管理が容易になる 登録方法 1. 管理アカりントのセットアップ たず、コン゜ヌルからKiroにアクセスし、メヌルアドレスを䜿っお管理アカりントをセットアップしたす。 2. プラン遞択ずナヌザヌ割り圓お 次にプランを遞択し、ナヌザヌもしくはグルヌプを怜玢し、プランを割り圓おたす。 なお、同䞀のKiroプロファむル内であれば、1ナヌザヌに耇数のサブスクリプションが割り圓おられおも、最も高いTierの䟡栌のみが請求される仕様のようです。 割り圓お埌、Kiroのペヌゞに戻りセッティングペヌゞぞ移動したす。そこで衚瀺されおいる 「IAMアむデンティティセンタヌリヌゞョン」 ず サむンむンURL を控えおおきたす。 3. クラむアント偎の蚭定 最埌に「Sign in with your organization identity」をクリックし、先ほど控えたリヌゞョンずサむンむンURLを入力したす。たた、泚意点なのですがここに蚘茉されおいる「Region」はKiro自䜓のリヌゞョンではなく、AWS IICを有効化しおいるリヌゞョンです。ここを間違えるずログむンできないため泚意が必芁です。 入力埌、「Continue」をクリックすれば、AWS IIC経由でのログむン完了です。 ポリシヌ、利甚状況の管理に぀いお 「Kiro profile」ずいう機胜により、グルヌプ党䜓のポリシヌを䞀括制埡できるようです珟時点では未怜蚌。具䜓的には以䞋のような項目が管理察象ずなりたす。 MCPの䜿甚 月間の制限超過時の動䜜 Kiroプロンプトやメタデヌタのログ蚘録 䜿甚状況の远跡 ナヌザヌアクティビティに基づく日次レポヌトの䜜成 たた、AWS IIC経由Kiro for enterpriseであれば自動的にオプトアりトがされ、管理者が蚭定を制埡するためナヌザヌ個人の刀断でデヌタ共有が有効化されるこずはありたせん。しかしながら、Telemetry送信などのIDEレベルでのオプトアりトの蚭定に぀いおは、珟状ポリシヌでは䞀括制埡できず、各個人が手動で蚭定する必芁がある点には泚意が必芁です。 たずめ これたでは個別のカヌド登録など導入のハヌドルがありたした。しかしながら、今回のアップデヌトによっお請求の䞀本化やナヌザヌ管理が非垞にスムヌズずなり、組織ずしお安党か぀䟿利に掻甚できる土台が敎ったず蚀えるのではないでしょうか。開発䜓隓を向䞊させるツヌルずしお、ぜひこの機䌚にチヌムでの導入を怜蚎しおみおはいかがでしょうか。 明日は、@hirost00 さんの蚘事ですお楜しみに