この記事は、 ニフティグループ Advent Calendar 2025  3日目の記事です。 はじめに こんにちは！新卒1年目のパクパクです OJT中のタスクの中でGraphQLで処理していたIssue作成のプロセスを、GitHub CLI（ghコマンド）に処理する作業を行いました。 この過程で学んだghコマンドについてご紹介します。それでは Let’s go!   目標 ghコマンドを使い、メインIssueとサブIssueを作成してプロジェクトに追加する   1. プロジェクトデータの取得 (Get Project and Field IDs) Issueを作成してプロジェクトボードで管理するには、まず必要となる各種IDを収集する必要があります。 ghコマンド で情報を取得し、 jq を使ってJSONデータを使います。   gh project view gh project view [<number>] [flags] プロジェクトの詳細情報を取得します。 オレンジ色の情報をコマンドで取得します オプション [flags] --owner : 個人またはOrganizationのアカウント --format : 出力フォーマット   例えば、Organizationが my-org である 1 番プロジェクトに関する詳細情報を取得したい場合は、以下のように入力します。 入力 $ gh project view 1 --owner my-org --format json 出力 { "closed": false, "fields": { "totalCount": 10 }, "id": "ABC_dkBO...", "items": { "totalCount": 50 }, "number": 1, "owner": { "login": "my-org", "type": "Organization" }, "public": false, "readme": "プロジェクト Readme...", "shortDescription": "プロジェクト 説明...", "title": "GitHub CLIでIssueを作成しよう", "url": "https://github.com/orgs/my-org/projects/1" } 末尾の -q .id オプションで、プロジェクトIDの値だけ抽出しました。 PROJECT_ID=$(gh project view 1 --owner my-org --format json -q .id)   gh project field-list gh project field-list [<number>] [flags] プロジェクトのフィールド情報を一覧表示します。 オプション [flags] --owner : 個人またはOrganizationのアカウント --format : 出力フォーマット   入力 gh project field-list 1 --owner my-org --format json 出力 { "fields": [ (...) { "id": "PVT_kw...", "name": "Status" , "options": [ { "id": "98234798...", "name": "In progress" } (...) ], "type": "ProjectType..." }, { "id": "abc123", "name": "Sprint" , "type": "ProjectV2Field" }, { "id": "def456", "name": "Point" , "type": "ProjectV2Field" }, { "id": "ghi789", "name": "Priority" , "type": "ProjectV2Field" }, (...) ], "totalCount": 5 } Status フィールドの ID を取得するために、下記のコマンドを使いました。 gh コマンドの結果を jq に直接渡して ID を抽出します。 STATUS_FIELD_ID=$(gh project field-list 1 --owner my-org --format json | jq -r '.fields[] | select(.name=="Status") | .id')     gh project item-list gh project item-list [<number>] [flags] プロジェクトに追加されているアイテム（IssueやPRなど）を一覧表示します。 オプション [flags] --owner : 個人またはOrganizationのアカウント --format : 出力フォーマット 入力 gh project item-list 1 --owner my-org --format json 出力 { "items": [ { "assignees": [ "pakupaku" ], "content": { "body": "# 概要nサービスローンチに向けて...", "number": 1, "repository": "my-org/backend-api", "title": "ユーザー認証機能の実装", "type": "Issue", "url": "https://github.com/my-org/backend-api/issues/1" }, "due": "2025-12-15", "id": "PVID_abc123", "labels": [ "bug", "high-priority" ], "linked pull requests": [ "https://github.com/my-org/backend-api/pull/2", "https://github.com/my-org/backend-api/pull/3" ], "point": 1, "repository": "my-org/backend-api", "sprint": { "duration": 14, "iterationId": "abc12345", "startDate": "2025-11-18" , "title": "Sprint" }, "status": "In Progress", "title": "ユーザー認証機能の実装" }, (...) ], "totalCount": 3 } プロジェクトアイテムの中から現在のスプリント情報を特定するために、各sprintのstartDateを取得します。   2. Issueの作成 (メインIssueとサブIssue) gh issue create gh issue create [flags] 新しいIssueを作成します。   オプション [flags] R , -repo : Issueを作成するリポジトリを選択します。 t , -title : Issueのタイトルを指定します。 b , -body : Issueのボディ(内容)を指定します。 l , -label : Issueのラベルを指定します。   このコマンドで、GitHub上でIssueが作成されます。 入力 gh issue create --repo "my-org/my-repository" --title "ログイン画面のUI実装" --body "Figmaのデザイン案に従って..." --label "feature"     gh issue view gh issue view {<number> | <url>} [flags] Issueの詳細情報を表示します 入力 gh issue view "https://github.com/my-org/my-repository/issues/2" 出力 title: ログイン画面のUI実装 state: OPEN author: pakupaku labels: feature comments: 2 assignees: developer123, reviewer456 projects: Development Board (In Progress) milestone: v1.0.0 number: 2 url: https://github.com/my-org/my-repository/issues/2 -- Figmaのデザイン案に従って、ログインフォームを実装します。 メールアドレス、パスワードの入力フィールドおよびバリデーション（Validation）を含めてください。   ここでも -q .id を使って、作成されたIssueのIDだけ取得できます。 入力 gh issue view "https://github.com/my-org/my-repository/issues/2" --json id -q .id   3. Issueをプロジェクトに追加する gh project item-add gh project item-add [<number>] [flags] プロジェクトにアイテム（IssueやPR）を追加します。 オプション ([flags] -owner : 個人またはOrganizationのアカウント -url : プロジェクトに追加したいIssueやPRのURL 入力 gh project item-add 1 --owner my-org --url "https://github.com/my-org/my-repository/issues/2"     gh project item-edit gh project item-edit [flags] プロジェクト内のアイテム（IssueやPRなど）のフィールド値を変更します。   オプション [flags] -id : 編集したいアイテムのID -project-id : 対象のプロジェクトID -field-id : 値を設定したいフィールドのID -single-select-option-id : 単一選択フィールド（Single Select）で設定したいオプションのID -iteration-id : イテレーション（Iteration）フィールドで設定したい値のID -date : 日付フィールドに設定したい値（YYYY-MM-DD形式） -number : 数値フィールドに設定したい値   例えば、プロジェクトの日付を指定したりする場合に下記のコマンドを使います。 入力 gh project item-edit --id "PVTI_lA..." --project-id "PVT_kw..." --field-id "PVTF_lAD..." --date "2025-12-8"       4. メインIssueとサブIssueを紐付ける gh api gh api <endpoint> [flags] GitHub APIに対してHTTPリクエストを送信します。   Issueをメイン サブ関係で紐付ける機能は、 gh コマンドではまだサポートされていません。そのため、 gh api コマンドを使ってGitHub APIを直接呼び出すことで対応します。 Request Bodyとして送信するデータはJSON形で渡します。 入力 # サブIssueのIDを指定 SUB_ISSUE_ID="I_kwDO..." # Request BodyをJSON形式で作成 JSON_BODY=$(printf '{"sub_issue_id": "%s"}' "$SUB_ISSUE_ID") echo "$JSON_BODY" | gh api --method POST -H "Accept: application/vnd.github+json" -H "X-GitHub-Api-Version: 2022-11-28" "/repos/${OWNER}/${REPO}/issues/${MAIN_ISSUE_NUMBER}/sub_issues" --input -   このようにして、GitHub REST APIのエンドポイント（ .../sub_issues ）に対して直接POSTリクエストを送信し、Issueの親子関係を設定しました。 まとめ これまではブラウザ上で操作するのが当たり前だと思っていましたが、今回、GitHub CLI（ gh コマンド）を使ってみて、Issue作成から親子関係の紐付けまでできるということを学びました。 UIだけでなく、CLI環境でも色んな作業ができることを知り、これからもCLIツールを活用して、開発効率を上げていきたいと思います！ 明日は、中井さんの｢ファミコンのソフトを作る。Rust で｣です。 お楽しみです   参照 https://cli.github.com/

この記事は、 ニフティグループ Advent Calendar 2025 2日目の記事です。 こんにちは。ニフティポイントクラブ開発・運用担当の西根です。 この度、AWS認定資格の一つである SysOps Administrator – Associate (SOA-C02) に合格しました。 AWS Certified SysOps Administrator – Associate (SOA-C02)は2025年9月30日よりAWS Certified CloudOps Engineer – Associate (SOA-C03)に更新されています。 実は、上期の目標に設定していたにもかかわらず、9月に入るまで全く手をつけていないという状況でした…。 そこから 約3週間（実働学習20時間） という短期間で、なんとか合格までたどり着いた経緯と勉強法をご紹介します。 SAAは持っているけれどSOAはどうしようか迷っている方や、とにかく時間がない！という方の参考になれば幸いです。 筆者の前提スキルと状況 まずは、学習開始前の私の状況です。 保有資格: 1年前にSAA（ソリューションアーキテクト アソシエイト）に合格済み。 AWS実務経験: 業務でAWSは使用していますが、AWS Organizationsを使ったアカウント管理などは別部署が担当しており、知識・経験ともにほぼゼロの状態でした。 状況: 上期の目標達成のため、「とにかく最速で」 合格する必要がありました。 学習戦略 学習戦略は「とにかく問題演習から入る」にしました。 というのも、学習期間は 3週間（合計1200分 / 20時間） しかなく、動画教材を最初から全部見るような余裕はなく、以下の戦略を取る必要がありました。 まず問題演習（Udemy）を解く。 間違えた問題、理解が曖昧な問題の解説をしっかり読む。 どうしても概念すらイメージできないサービスだけ、ピンポイントで動画教材を視聴する。 AI（ChatGPTなど）を壁打ち相手として使い、知識の穴を埋める。 時間の作り方 確保した時間は以下の通りです。 平日: お昼休み: 40分（ご飯を食べながらUdemy動画を流し見 + 20〜30分の問題演習） 通退勤: 0〜30分（気が向いたらやる程度） 休日: 予定がない日に 2〜4時間 集中して確保 使用した教材 使用したのは以下の3つです。 [動画教材] AWS認定CloudOps Engineer Associate（SOA-C03）試験 対策トレーニング 主に知識補完用。全編は見ず、Systems Manager, Organizations, Service Catalog, Control Towerなど、全く知らないサービスの章だけを1.25倍速で視聴しました。 [問題演習：メイン] AWSトップ講師によるAWS認定SysOpsアドミニストレーター アソシエイト模擬試験問題集（5回分325問） 今回の学習の核です。 これをひたすら周回しました。 正答率を回数ごとに記録してもらえるので、成長が可視化されてモチベーションになりました。 [問題演習：直前] AWS認定資格 WEB問題集＆徹底解説 Udemyの問題に慣れすぎたため、受験前日〜当日にかけて「無料問題」のセクションを解き、知識の最終確認をしました。 AI活用が合格の鍵 今回の短期合格の要因として、 AIの活用 が非常に大きかったと感じています。 SAAと違い、SOAはSystems Manager (SSM) やOrganizationsなど、「実際に組織で使っていないとイメージが湧きにくい」サービスが頻出します。 これらをドキュメントだけで理解しようとすると時間がかかりますが、AIに壁打ち相手になってもらうことで、効率的に理解を深めることができました。 活用例1：サービスの比較と違いの明確化 例えば、SSMの「Run Command」と「Runbook (Automation)」の違いが曖昧でした。 そこで、AIに以下のように質問しました。 （質問） AWS SSMのRun CommandとRunbook（Automation）の違いを、初心者にもわかりやすく教えてください。 （AIの回答要約） Run Command: 目的: 複数のEC2やオンプレミスサーバーに対して「単発のコマンド（シェルスクリプトやPowerShell）」を実行する機能。 例: 「全サーバーにパッチを当てる」「ログファイルを収集する」 Runbook (Automation): 目的: もっと複雑な「一連の運用タスク」を自動化する機能。Run Commandの実行、Lambdaの実行、EC2の作成などを組み合わせたワークフローを作れる。 例: 「AMI（マシンイメージ）の作成とパッチ適用を自動化する」 このように、AIに「〇〇と××の違い」を平易な言葉で説明してもらうことで、公式ドキュメントを読むより早くイメージを掴むことができました。 もちろん、AIが常に真実を教えてくれるとは限らない（ハルシネーション）ため、 最終的なファクトチェックは必要 です。しかし、そもそも何から調べていいかわからない時の「とっかかり」として、非常に優秀でした。 活用例2：直前対策チートシートの作成 試験直前には、AIに「SOA-C03の試験に出る重要なサービスとキーポイントをまとめたチートシートを作って」と依頼しました。 作成されたリスト（SSM, CloudWatch, Organizations, Service Catalogなど）を眺めることで、頭の中を整理して試験に臨むことができました。 実務でSOAはどう活きているか？ 正直なところ、1年前に取得したSAAではAWSのサービスをある程度網羅的に学習することとベストプラクティスをインプットすることが主目的であり、日々の業務で「あ、これSAAでやったやつだ！」と直接的に感じる場面はそれほど多くありませんでした。 しかし、SOAに関しては実務で活かせているなという手応えがあります。 ログ監視の提案ができるようになった 具体的な変化として、チーム内で「システムのログ監視方法を見直したい」という話題が上がった際のエピソードがあります。 これまでの自分なら方法を調べることから始めていたと思いますが、「CloudWatch Logsのメトリクスフィルターを使用すれば、特定のエラー文字列を検知して簡単にCloudWatch Alarmを発火させられますよ」 と、具体的な実装方法を含めた提案を調べずに行うことができました。 自社サービスの開発・運用・保守を一貫して行うチームにおいて、「どう運用していくか」「どう守るか」というSOAの知識は、開発者にとって非常に強力な武器になると感じました。 まとめ 今回の合格の勝因は、以下2点に尽きると思います。 良質な問題集（Udemy）を周回したこと 使用したUdemyの模擬試験は、実際の試験より少し難易度が高めに設定されている印象でした。これを解き切ることで、本番で慌てず対応できる実力がつきました。 AIを「壁打ち相手」として活用したこと 実務で触れないサービスの理解を、AIとの対話でスピーディに補完できました。 SAAに合格したものの、次のステップを迷っている方にはSOAの受験をおすすめです。 SAAが「設計」にフォーカスしているのに対し、SOAは「運用・監視・トラブルシューティング」に重点が置かれており、AWSをより深く理解するのに役立ちます。 時間がない方も、問題演習とAI活用を組み合わせれば、効率的に合格を目指せるはずです。 次回はもう少し時間に余裕を持って効率よく勉強したいと思います！  

はじめに ニフティ アドベントカレンダー トップバッターの西野です。エンジニアブログではほぼ毎回スクラムの記事を書いています。アドカレの枠をとりにいった11月は「12/1、間に合いそう！」と思っているのに当日になって書いています。あわてんぼうのサンタクロースの前倒し精神を見習いたいです。 この記事では、AIを活用し「質の高いレトロスペクティブ」の準備を30分以内に終わらせるコツ、レトロスペクティブ中のアイデア発散と収束にどうAIを役立てるかという内容を、実際に自分たちのチームで活用している具体的なプロンプト付きで紹介しています。ぜひ拡散してください。 スクラムでどうAI活用するか 開発者にもプロダクトオーナーにもAIのビッグウェーブが来て早数年。 スクラムマスターとしてAIが使える領域がないかいくつか試してみたのですが、 ファシリテーション：特にアイデアの収束 チーム分析：特に会話ログに基づく感情・行動分析 この2点についてAI活用が効果的だと思うので、AI活用が向いている領域と具体的な使い方を紹介します。 スクラムでAI活用ができる領域 AI活用により実行時間が短縮できること アクションの作成 ブレスト内容からPBIの受け入れ基準を作成する ミーティングの最後に実行可能なアクションアイテムを生成する 課題の発見 ミーティングの会話内容、ベロシティといったデータに基づくチーム課題の発見 自分が知らないやり方の選択 レトロの手法、ミーティングの手法など AIじゃないと難しいこと 会話における客観的な感情分析 分析結果が正しいかどうかは別なので判断は人間がする 膨大な分析 1スプリント〜半年間の、トランスクリプト（Google Meetなどの文字起こしによる会話ログ）を分析 トランスクリプトの会話内容とベロシティの関係性 一番効果的だった使い方：レトロスペクティブ チームでやってみて一番効果的だったスクラムにおけるAI活用は、レトロスペクティブでした。 自分はスクラムマスターとしてレトロスペクティブの手法を学んで実施していますが、そのぶんレトロの準備やファシリテートが属人化しやすく、他のメンバーでファシリを回す場合でもサポートとして入るケースが多い状態でした。 しかし、AIを活用することでレトロスペクティブの質を維持してファシリをローテさせることが可能となり、レトロスペクティブの内容にもなりますが準備時間も おおむね30分程度 と大きく短縮できています。 データの仕込み方 Google CalendarのMeetを想定した方法となります。Zoomなどほかミーティングツールでも大きく方針は変わらないと思いますが、オンラインを介さずリアルの場でミーティングをする場合は文字起こしを忘れないようにする必要があります。 ここではGoogle MeetやGeminiを軸とした使い方を紹介しますが、ほかのツールでもおおまかな流れは変わりません。 可能な限りスクラムイベント（ミーティング）をGoogle Meetで開催する Google CalendarのMeet設定で、「会議を文字起こし」をデフォルトONにしておく。繰り返し予定に対して反映するとGOOD。 レトロスペクティブのテーマ Google Driveの「Meet Recordings」の「Geminiに相談」にプロンプトを投げる レトロスペクティブのテーマを決めるためのプロンプト例 シンプルなテーマ提案 過去1週間（※スプリントの長さに合わせる）の会話を分析して、レトロスペクティブのテーマとして最適なものを5つ提案してください 長所と課題分析 過去1週間の会話を分析して、チームの長所と課題を指摘してください 出来事を振り返る 過去1週間の会話を分析して、主要な出来事を挙げてください。具体的には、成功した点（Keep）、課題となった点（Stop/Improve）、そして議論の中で繰り返し現れた重要なキーワードやトピックを含めてください 頻発する課題の特定 過去1週間の会話を分析して、同じ問題が繰り返し議論されていた箇所を特定してください。 議論傾向の特定 過去1週間の会話を分析して、「プロセス・ツール」と「人間関係・コミュニケーション」の2つに分類し、どちらの課題の議論に最も時間が割かれていたか、その比率を示してください。そこから、より深い議論が必要な課題を5つ提案してください 感情分析 過去1週間の会話を分析して、チームの感情分析をしてください。そこから見つかったレトロスペクティブのテーマとして最適なものを5つ提案してください トランスクリプト（会話ログ）だけだと的外れな分析を返してくることも多いため、しっくりくるテーマになるかはファシリテーターが事前にトライアンドエラーしておきます。 AIを使ったレトロスペクティブの準備ではここが一番大変です。 レトロスペクティブの手法を決める チームの課題が絞り込めたら、その課題を解決するための方法を尋ねます。 レトロスペクティブに関する情報はそこまで多くないのか、目新しい振り返り手法の提案は基本的に出てこないように思います。 一方で、チームメンバーが「トラブルの振り返りで、変わったレトロスペクティブのやり方を提案してほしい」とAIに頼んで「過去の自分に宛てて手紙を書くなら、いつ、どんな内容にするか」という今までのレトロで採用したことがないアイデアが出てきて、新鮮なレトロスペクティブを開催することもできました。マンネリ化したテーマの場合は振り返り手法をゼロからAIに考えさせてみるのもいいかもしれません。 レトロスペクティブの手法を決めるための プロンプト例 シンプルな振り返り手法の提案 「複雑なタスクの見通しと計画」についてレトロスペクティブを行いたいと思います。どんなレトロスペクティブの手法を提案し、その理由を説明してください 感情にフォーカスした振り返り手法の提案 チームの心理的安全性を高めるのに役立つレトロスペクティブの手法（例：Mad Sad Glad、Sailboatなど）を提案し、その理由を説明してください 真因をさぐるための振り返り手法の提案 「障害がなぜ再発するか」については、根本原因の特定が必要であることを示唆します。根本原因の深掘りに適したレトロスペクティブの手法（例：5つのWhy、フィッシュボーン図など）を提案し、その理由を説明してください 新鮮な振り返り手法の提案 従来のレトロスペクティブの手法にとらわれない、ユニークで感情的な要素を含むレトロスペクティブの手法を3つ提案してください レトロスペクティブを組み立てる ここまでで、チームの課題とその課題の検討方法が決まりました。あとは時間配分を決めます。 AIの活用はレトロの準備だけでなく、アクションアイテムの絞り込みにも使うので、以下のようなプロンプトがおすすめです。 レトロスペクティブの組み立てをする プロンプト例 AIを活用したレトロスペクティブの時間配分とコツ 「障害がなぜ再発するか」というテーマで、5つのWhyを用いてレトロスペクティブを行います。時間配分をふくめて、1時間のスクラムイベントの組み立てをしてください。最初にアイスブレイクを入れてください。アクションプランの絞り込みは、出た意見に基づいてGeminiで行います。このレトロスペクティブのファシリテーションをするときのコツも添えてください。 レトロスペクティブを実施する あとは、決めた時間に沿って進行し、現状把握やアイデア出しを行います。 アイデアを出すフェーズは、おおまかに発散フェーズ（たくさんアイデアを出すフェーズ）と収束フェーズ（アイデアからアクションを絞り込むフェーズ）に分かれます。 AIを活用したアイデアの発散と収束 AIはあくまでミーティング中の会話しか知らないため、発散フェーズは「ミーティング以外の場で起きたことを知っている人」＝スクラムチーム本人に任せることをお勧めします。 収束フェーズはAIが得意とするところです。出たアイデアから意見をまとめたり、絞り込ませてスクラムチームがピンとくるアクションを出せるかを高速に試すことができます。 レトロスペクティブ中に出たアイデアの収束をする プロンプト例 （ホワイトボードのキャプチャや、アイデアリストなどのテキストデータをAIに伝えたうえで）出た意見をもとに、1週間（※スプリントの長さに合わせる）実行可能なアクションアイテムを5つ挙げてください 改善アクションの決定 このプロンプトで出たいくつかのアクションアイテムを選ぶ方法は、話し合いでもいいですし、良いアイデアが多くて意見が割れるようであればドット投票などの投票でもかまいません。 次のスプリントで実施するアクションアイテムを選んでAIを使ったレトロスペクティブの完了です。 最後に レトロスペクティブで大切なことは「チームが主体となって」スプリントを振り返ることです。より大量かつ詳細にチームのデータが取れるようになったときには、AIを活用するなかで意見を出すフェーズはAIに行わせて、収束するフェーズをあえて人間がやるという方向性もあると思います。 肝心なのは「レトロスペクティブの全てをAIに任せきりにしない」ことです。 今の時点のAIでは、チームに関する情報の全てを拾いきることはできません。たとえばAIは朝のチーム内の雑談も、隣の席同士で会話のなかで相談した設計の話も、机の散らかり具合も、チームの中に漂う空気感というのも正確にはわかりません。 スクラムチームについて一番詳しいのがスクラムチーム自身なのは、当面は変わらないと思います。 ここまでAIを活用する話を書いていますが、この記事を書くことそのものにはほとんどAIは使っていません。（プロンプトのアイデアや校正にはAIを活用しています） これは、ブログ記事でアウトプットすることで自分の考えを整理することを目的としているからです。スクラムマスターは、要所要所でAIを使うことがチームが目指す目的に沿っているのかも確認する目線があるといいと思います。 次回（自分の掲載が1日遅れなので今日ですが……）のアドベントカレンダーは西根さんによる「SAA持ちエンジニアがAI活用と問題演習でAWS SysOps (SOA-C03) に3週間で合格した勉強法」です。お楽しみに！

こんにちは！NIFTY engineeringブログ運用チームです！ 今年もあっという間に残りわずかとなりました。クリスマスが迫り、アドベントカレンダーの季節が到来しましたね！ ニフティグループでは毎年、アドベントカレンダーに積極的に参加しており、今年でなんと10回目の開催となります！ 日頃の知見をアウトプットする機会として、ニフティグループのエンジニアが楽しみながら成長していくことができています。 今年も皆様に新たな技術や知識をお届けできることを楽しみにしています！ アドベントカレンダーとは？ 元々はクリスマスまでの日数をカウントダウンするために使われていたカレンダーで、12月1日からはじまり、25個ある「窓」を毎日1つずつ開けて中に入っている小さなお菓子やプレゼントを楽しむものです。 このカレンダーにならい、定められたテーマに従い参加者が持ち回りで自身のブログやサイトに記事を投稿する、リレー形式のブログ執筆イベントです！ ニフティグループ アドベントカレンダー ニフティグループではフリーテーマとなっておりますので、好きに執筆してもらっています。 また、記事に関してはQiita様のアドベントカレンダーページにて登録させていただき、 公開自体は本ブログ（NIFTY engineering）や ニフティライフスタイル Tech Blog 、Qiitaにしていく予定です！（ニフティ、ニフティライフスタイル、セシールでそれぞれ投稿場所が異なります） ニフティグループ AdventCalendar 2025 アドベントカレンダーでは、ニフティグループのエンジニアが日頃の業務で培ったノウハウを共有していきますのでぜひチェックしてみてください！

この記事は、リレーブログ企画「Maker Faire Tokyo 2025ボードゲーム制作リレーブログ」の記事です。 こんにちは！Maker Faire Tokyo 2025 リレーブログ、前回のムサシさんからバトンを受け取りました、西根です。 前回までは、私たちが作ったオリジナルカードゲームのルールやデザインがどうやって完成したかをご紹介しました。 しかし、その時点ではルールもデザインも、まだすべてPCの中のデータに過ぎません。 この記事では、そのアイデアが、どうやって皆さんの手元で遊べる「モノ」になり、イベント当日を迎えたのか。その泥臭くも楽しかった「製造・出展プロセス」の物語を振り返ります。 初めての「仮入稿」と「仮印刷」 アイデアを初めて「紙」にする日。 デザイン担当の西野さんとイラスト担当のムサシさんが作ってくれた入稿データで「仮印刷」を試しました。 数日後、印刷所から届いた仮印刷のカードを初めて手にした時は、本当に自分たちが考えたものがボードゲームになるんだ…！と嬉しくなりました。 データ上で完璧に見えても、紙にした瞬間に「色が沈む」「文字が小さすぎる」といった問題が発覚するのが「印刷あるある」だと聞いていたのですが……今回はそれがほぼありませんでした。 むしろ「PP加工（ツルツルにする加工）なしでも、思ったより光沢があるかも？」といったポジティブなギャップがあったくらいです。 これは間違いなく、入稿データ作成に強いメンバーがいてくれたおかげだと、この時強く思いました。 これは本印刷後のカードですが、発色や光沢感もとても良い感じです！   カラフルな裏面も綺麗に印刷していただきました！   予期せぬミッションとクオリティの追求 「モノ」としてのクオリティをどこまで求めるか。これは予算とスケジュールの戦いです。 突然の追加ミッション：「急遽、パネル置けます！」 イベントが近づいてきたある日、「ブースにパネルを置けることになりました！」と連絡が。 嬉しいチャンスであると同時に、印刷所に入稿するとなるとデザイン担当の西野さんに追加のタスクをお願いしなければいけませんでした。 期限が迫っていたため、すぐに西野さんに「いつまでに何を決めて依頼すれば間に合うか」を相談し、パネルに載せる内容と構成を急いで決めました。 この時デザインしてもらったパネルの内容が、後述するルールブックの表面デザインにも活用できたのは、結果的にとても良かったです。 ルールブックも「本物」にしたい ルールブックは、当初は社内のプリンターで印刷する想定でした。 しかし、「せっかくカードを綺麗に作るなら、ルールブックもちゃんとしたものにしたい！」という思いが捨てきれず、なんとか予算を工面できないか調整を重ねました。 その結果、イベント直前の9月末頃、急遽「印刷会社で印刷できる」ことが決まりました！ 喜びと同時に、社内の発注プロセスを進めなければなりません。社内調整の知見が全くなかった私は、いっけいさんに泣きつき、発注から納品までをめちゃくちゃサポートしてもらいました。本当にありがとう、いっけいさん…。 写真だと伝わりづらいですが、ツヤっとした光沢紙に印刷したことで「本物」感が増しました！ イベント前日に西野さんとムサシさんにルールブックを綺麗に折ってもらい、当日の朝なんとか梱包を終えました。 スタッフ体験会 ゲームが物理的に完成し、イベント当日が近づいてきた頃、当日の運営を手伝ってくれるスタッフの皆さんに向けて体験会を実施しました。 そこで直面したのは、 「このゲームのことを全く知らない人に、口頭でルールを説明する難しさ」 です。 テストプレイに参加していた人も、普段からボードゲームをしている人が多く、ルールを理解するということに慣れているということをすっかり見落としていました。 イベント当日はお客様に体験してもらう予定だったので、口頭で説明するにはルールを複雑にしすぎたか…？と不安になりましたが、体験会が終わった後に「面白い」「カードがかわいい」といった感想をもらえたのは、本当に嬉しかったです。 同時に、こんな貴重なフィードバックももらいました。 「特殊カード、小さいお子さんにはちょっと複雑かもね…」 …確かに！ Maker Faireは親子連れも多いイベントです。このままでは楽しんでもらえない層が出てきてしまう。 私たちは急遽、当日スタッフの皆さんにお願いし、小さいお子様には「特殊カードをすべて『10』として扱う」という簡略化ルールで遊んでもらうことにしました。 これにより、ほぼ通常のブラックジャックと同じルールで遊べるようになり、当日は本当に色々な年代の方に楽しんでいただけたと思います。 体験会で率直な意見をもらうこと、そしてそれに応えてくれる当日スタッフの皆さんの柔軟な対応力に、心から感謝しています。 決戦のMaker Faire当日 そして迎えた当日。 自分たちが作ったゲームを、ブースに来てくれた人たちが手に取り、遊んでくれている。 その光景を見ているのは、なんとも言えない緊張と喜びが入り混じった時間でした。 アンケートでは「ルールが面白かった！」「子供が楽しんでいた」といった声をいただき、改めて「ものづくりって楽しいな」というシンプルな気持ちを思い出させてもらいました。 普段私が作っているものはソフトウェアですが、実際に手で触れる「モノ」があるものづくりも、やってみれば意外となんとかなる。そして、 自分が作ったもので誰かが喜んでくれる瞬間の嬉しさ は、ソフトウェアもボードゲームも変わらないんだな、と感じました。 アイデアを「形」にして学んだこと 振り返ってみて、学んだことは大きく2つあります。 当たり前ですが、ボードゲームを1から作るのは本当に大変でした。 決めることも、調整することも多い。でも、それ以上に、実際に遊んでいるところを見た時の嬉しさは格別でした。本当にやってよかったです。 色んな人を巻き込むと、思ったよりも快く協力してくれる。 ただし、丸投げはダメです。できるだけ「自分はこうしたい」という意見を持って質問したり、疑問点を言語化したりして相談に行くことで、お互いが幸せになれると実感しました。 有志で関わってくれた開発メンバー、デザイナーの皆さん、印刷所の方々、そして当日ブースに遊びに来てくれた全ての皆様に、心から感謝を伝えたいです。 本当にありがとうございました！

普段、何気なく使っているインターネットやWEBサービス。その要となるのが、通信端末や各種サーバーの間をつなぎ、情報の伝送を行うネットワークです。ニフティにも専門のネットワークチームがあり、データセンターやニフティ従業員が働くオフィスのネットワーク設計・構築・運用などを担っています。 「つながるのが当たり前」というプレッシャーのなかで、日々の業務にあたるネットワークチーム。 前編 では仕事のやりがいや、苦労などについてメンバーに語ってもらいました。後編ではニフティという会社の良いところ、チームに迎えたいメンバー像、さらには各々が描く今後のキャリアについて聞きました。 キャリアや部署の垣根を超えて交流できる機会が多い みなさんが思う「ニフティの良いところ」を教えてください。 Sさん ニフティの良さはなんといっても、社員同士のコミュニケーションが活発なことだと思います。懇親会など交流の場も多いですし、社内コミュニケーションツールも積極的に活用されています。それもあって年齢やキャリア、部署の違いに関係なく仲の良さ、距離の近さを感じますね。 他部署の人と気軽につながれるのはいいですね。普段の業務では触れる機会のない、さまざまな知見を得ることができそうです。 Sさん そうですね。知見をシェアする社内の勉強会なども定期的にあって、Slack内の勉強会を盛り上げるチャンネルがしっかり機能しています。誰かが投稿したメッセージに対するレスポンスも非常に多くて、みんながコミュニケーションを大事にしているというか、スルーしないのもニフティの特徴なのかなと思います。 それから、労働環境でいうと休日は多いですね。有給休暇も取りやすいですし、ワークライフバランスという点でも満足度の高い環境だと感じます。 Tさん 制度や待遇の面でいうと、フレックス勤務が認められていて勤務時間の自由度が高い点や、小学生以下の子供がいる場合は週3でリモートワークができる点、有給とは別に育児関連で取得できる休暇がある点など、かなり柔軟な働き方ができる制度が揃っています。 私自身はフレックス勤務をよく利用していますね。コアタイムが11時から14時までと定められていて、その時間さえ含めればいつ出社してもOKというルールです。前日の夜が遅かった時は翌朝の出社時間を11時にずらすなど、その時々の状況に合わせて調整することで、良いコンディションで働けていると思います。 制度以外の良さでいうと、何が浮かびますか？ Tさん Sさんも話してくれましたが、やはり社員同士の仲の良さは感じますね。私は中途入社なのですが、Slack上に中途入社組が集まるチャンネルもあって、みんなでご飯を食べに行くきっかけになっています。あとは社内部活もたくさんあって、同じ趣味を共有できます。私が所属するサバゲー部でも、色んな部署の人たちと週末にサバゲーをしています。他にも、2か月に1度くらい、オフィス内のセミナールームで自由に集まりお酒を飲む交流の場もあったりして、つながる機会はかなり充実していると思います。Sさんは毎回のように参加していますよね。 Sさん そうですね。他部署の人たちと気軽に話せる機会で、思いがけない知見や発見を得られることも多いので。 Mさんはいかがでしょうか？　ニフティの良さというと何が思い浮かびますか？ Mさん 二人がほぼ言ってくれましたが、あえて被せると柔軟に働ける環境という点ですかね。フレックスや休みの取りやすさも、業務調整をやったうえではありますが、申請してNGが出たことは一度もありません。そこは基本的に融通が利く会社だと思います。 それ以外で個人的に良いと思うのは、さまざまな技術についてキャッチアップしやすい環境であること。技術に対する感度が高く、それを周囲にシェアしてくれる人が多いんです。たとえば、Slack上に色んな分野の最新情報を書いてくれる人がいるので、それを追っていくだけで自分が普段カバーしている領域以外についても知ることができます。とてもありがたいですし、自分も情報を得たら積極的にシェアしようという気持ちになりますね。 ネットワークの知識をベースに、色んな技術を吸収できる人が理想 チームに新しいメンバーを加えるとしたら、どんな人に来て欲しいですか？　Mさんはリーダーの立場から、望む人物像や歓迎するスキルを教えてください。 Mさん ネットワーク関連の技術っていわゆる「枯れた」ものが多いイメージもあると思いますが、そのなかでも新しい技術はどんどん出てきていますし、自動化などによって運用面でも進化し続けています。そうした新しい技術に目を向けて、積極的に取り入れようとする好奇心を持った人が来てくれるといいなと思いますね。 性格的なところでいうと、この仕事はトラブル対応が一つの重要な役割になるので、イレギュラーな事象に対してパニックにならず、平静に構えていられること。心の中では動揺してもいいんですけど、そこで立ち止まらずに動き続けられる人がチームにいると非常に頼もしいです。 では、Tさん、Sさんはいかがでしょうか？ Tさん 今のMさんの話と少し被りますが、ネットワークに関する最低限の知識を持ったうえで、自動化のような新しいことに取り組んでもらえる人が来てくれると嬉しいです。現時点でそうしたスキルを備えていなくても、新しいことに関心があり、常にキャッチアップしていく意欲を持った人であれば、ニフティは成長できる環境だと思うので。 Sさん もちろんネットワークに関する知見やスキルを持っている人はすぐに活躍できると思いますが、それ以外にも何か得意なことがあると、なお良いのかなと思います。僕らが普段業務で取り扱わないような技術に長けている人が来てくれると、メンバーの視野も広がりますし、新しい刺激を得られるのかなという気がしますね。 たとえば、今は全社的にクラウド環境への移行が進んでいるのですが、ネットワークチームには現時点でクラウドに特化した知識を持ったメンバーはいません。一人でもクラウドに明るい人がいてくれたら、ネットワークチームでも移行がスムーズに進むのかなと思います。自分でもそこを補うために、勉強を始めようと考えているところです。 ネットワークのスペシャリストとして、さらに技術を磨いていきたい みなさんの今後のキャリアの展望や、挑戦してみたいことを教えてください。 Tさん 先ほどSさんが、「ネットワークに関する知識がベースにありつつ、プラスαの強みがあると良い」と言っていましたが、それは私も同感で。私の場合、直近でAWSの案件に携わっていたこともあって、AWS周りにもっと強くなりたいと思っています。そうやって得意なことを増やして、ネットワークエンジニアとしての幅をどんどん広げていきたいですね。そのうえで、色んなことに挑戦でき、学ぶ機会も多いニフティの環境はかなりの後押しになると思います。 Sさん 私はネットワーク機器を触り始めて2年ほど経ちますが、まだまだ知らないことがたくさんあると思っています。機器に関しても設定に関してもさらに吸収していきたいですし、これまで会社で取り扱ってきた機器だけでなく、他のベンダーさんの機器も触ってみたいという思いがありますね。 キャリアに関しては正直、そこまで明確なものはまだありません。ただ、今の業務内容は自分に合っていると思うので、当面はそのレベルを上げていくことに集中したいです。 Mさん 私もキャリアというより、「やりたいこと」になってしまうのですが、機械って壊れることもありますし、トラブルはどうしても生じてしまうものです。大事なのはトラブルが起きた時に、ネットワーク側で自律的に立て直していける仕組みを作ること。そのためには、ネットワークの知識だけでなく、設計や構築といった開発のスキルも必要です。今後はそうした設計力を磨いて、強固なインフラを構築できるエンジニアになりたいと考えています。 そうしたスキルを学ぶ環境も、ニフティにはあるのでしょうか？ Mさん そうですね。社内にも知見を持った人はいますし、社外のエンジニアのネットワークで公開している情報を拾ったり、勉強会に参加したりといったことも奨励されているので、学びやすい環境ではあると思います。毎週のチーム会でも、「こういう勉強会やイベントがあります」という情報は共有されますし、業務の調整さえできれば勤務時間の範囲で参加することも可能ですので。こうした環境をうまく利用して、ネットワークのスペシャリストとしての力を磨いていきたいと思っています。 前編もご覧ください！ 今回はニフティのネットワークチームのインタビュー（後編）の様子をお届けしました。前編の記事はこちらをご覧ください。 【インタビュー】「つながるのが当たり前」。だからこそ普段はなるべく目立たない存在でありたい【ニフティ ネットワークチーム前編】 このインタビューに関する求人情報 /ブログ記事 ニフティ株式会社 求人情報

はじめに こんにちは!!新卒一年目のパクパク、やまだ25、大村です。 本記事では、私達が参加したエンジニア定例合宿で開発した、ユーザ投票ベースの電車混雑予想アプリを紹介します。 エンジニア定例合宿の詳細につきましては以下の記事をご覧ください。 今年はいつもと違う？ハッカソン合宿に行ってきました！@マホロバ・マインズ三浦   メンバー紹介 パクパク 普段の業務 : 入会会員の運用 今回の担当 : フロントエンド ひとこと : アニメで見た合宿の宴会が実在してて感動しました。 やまだ25 普段の業務 : データ基盤 今回の担当 : バックエンド ひとこと : 3日目にホテルの窓からうっすらと富士山が見えて感動しました。 大村 普段の業務 : 会員基盤の運用 今回の担当 : バックエンド、DB ひとこと: ホテルで食べた7食全部が豪華でした。   アプリ紹介 概要 チームWATCHME.mdでは、主観ベースの混雑予想アプリを作成しました。 実装したもの: ユーザがある路線の区間の混雑率を投稿 選択した路線の混雑度をヒートマップのように、区間ごとで色分け 実装しきれなかったもの: 曜日や天気、祝日などを考慮して、混雑度に重み付け ユーザごとの混雑度の感じ方に応じて、表示を調整 成果物 検索画面   結果画面 経路上の各駅間において、 どのくらい混んでいるのかを色合いで教えてくれます 検索結果 どの程度混んでいたかを共有   使用技術 フロントエンド: React バックエンド: Python(FastAPI)、PostgreSQL その他: Docker、Docker Compose 開発の流れ 事前準備 アイデアソン 使用技術調査 1日目: 仕様書作成 機能要件 API設計 DB設計 GitHub、Dockerでチーム開発の環境構築 2日目: 環境構築･実装 午前 FastAPI、Reactの環境構築 テーブル作成 午後 メイン･結果画面実装 API 中身実装 3日目: 最終調整・成果発表 午前 テスト バグ修正 午後 成果発表   工夫したこと 画面レイアウトについて メインの画面を混雑率の検索画面とし、ユーザは路線名、出発駅、到着駅を選択するだけで混雑率をすぐに検索するように画面レイアウトを設計しました。 投票画面の部分も同様に路線名と出発駅、到着駅、混雑率を選ぶだけで投票できるように設計し、ユーザの操作数を少なくするよう工夫しました。 タスク管理について 我々のチームではタスク管理としてGitHub Projectsのカンバンを使いました。これにより、各メンバーの作業状況や各タスクの進捗状況を一目で確認することができ、さらに手が空いたら別のタスクにすぐに取り掛かることができました。 また、開発以外のタスク（勤怠の申請や日報の作成など）もカンバンに記載することで申請漏れなどを防ぐことができました。   学んだこと・成長したこと Zustand 今回の合宿では、フロントエンドの状態管理ライブラリとしてReduxの代わりにZustandを初めて使用してみました。Reduxと比較すると、Zustandはシンプルでした。 Reduxでは actions や reducer など複数のファイルにわたってコードを記述する必要がありましたが、Zustandでは一つのファイル（ appStore.ts ）で路線、駅、混雑度データなどすべての状態を管理できました。 // Redux: actionTypes.ts + actions.ts + reducer.ts + コンポーネント dispatch(actions.setDepartureStation(station)); // Zustand: appStore.ts + コンポーネント setDepartureStation(station); また、メイン画面で駅を選択すると、結果ページで props を渡さずに駅データをすぐに使用できた点も楽でした。 Zustandを使用することで、コード量を削減しながらも、コア機能に集中することができ、短時間で実装できました。   FastAPI バックエンドではFastAPIを使用しました。コードを書くだけでSwagger UIによりAPI文書が自動生成され、別途文書を作成する時間を削減できました。以前Flaskを使ったときより、APIを簡単に構築することができました。   AIの活用 今回の開発で、要件定義やAPI、DBの設計といった上流工程ではNotion AIを活用し、思考の整理やドキュメント化を高速化しました。 また、実装の部分ではClaude Codeを活用することで、コーディングに書ける時間を大幅に削減し、3日間という短い期間で効率的に開発を進めることができました。 開発終盤ではAIの出力結果に対してレビューが不足な部分があり一時的にアプリが起動しなくなる場面もありました。この経験から、AIの出力結果を鵜呑みにするのではなく結果の内容をレビューすることでAIのメリットを最大限活用することができることを学べました。   まとめ 今回のエンジニア定例合宿では、これまでの研修で培ったスキルだけでなく、初めて使用する技術やAIエージェントを最大限活用することができ、大変有意義なものとなりました。 会社の業務から離れて、3日間という短い期間の中で様々な技術を使って開発を進めることができた経験を糧に、今後の研修や業務で生かしていきたいです！

こんにちは。ニフティの長期インターンシップに参加した吉原です。 基幹システムグループ　インフラシステムチームのサブチームである、社内プラットフォームチームに所属し、社内の情報システム担当の一員としてインターンシップに参加しました。 軽く私の自己紹介をしますと現在、情報系の学部3年生で1、2年生の時は計算機や数理モデリングなどを幅広く学習し、現在は暗号の理論や応用などを研究できる研究室に所属しています。 今回は３ヶ月間行った長期インターンシップを通して学んだことなどをまとめていきたいと思います。 ニフティの長期インターンシップを知ったきっかけ 4月に研究室に会社紹介でいらした OBの方のお話 を聞き、内製で開発をする割合が高いことや会社として成長を後押ししてくれる環境であるニフティという会社に興味を持ちました。 大学生になってから、将来はエンジニアとして働くという目標はあったものの、本格的な開発経験はゼロでした。そんな私がニフティの長期インターンシップに参加することになったきっかけは、夏休み前に 大学の掲示板に貼られていた一枚のポスター です。 「本格的な経験が積めるチャンスがある！」と強く惹かれました。 自身での開発経験がなかったため、長期インターンは正直「自分には難しい」と考えていました。しかし、「要件定義から設計、実装まで体験」という言葉に強く惹かれ、「受かったらラッキー」くらいの軽い気持ちで、ダメ元で応募してみたのが正直なところです。 実際に行ったこと 今回の長期インターンシップでは、主に社内システムに関わる複数の業務を経験させていただきました。 1. 分離されたネットワーク間でファイルをやり取りするツールのエンハンス このツールは社内のセキュリティレベルをまたぐファイルの移行を、安全に実行するためのツールです。もう少し具体的にいうと、 機密性の高いネットワーク と 一般的な業務ネットワーク の間で、ファイルを移行する際に「このファイルは移動しても良いか？」「移動先のセキュリティレベルで扱っても大丈夫か？」をチェックする役割を持っています。また、このチェックでDLP（データ損失防止）を使用しており、一部ファイルでは自動でチェックしてくれます。 このプロジェクトでは、主に TypeScript を用いて既存のツールに機能を追加するエンハンス作業に取り組みました。私自身、TypeScriptはインターンシップで初めて触れる言語でしたが、チームメンバーへの質問や生成AIを利用して、一からキャッチアップしながら開発を進めました。 エンハンスの背景と目的 として以下のユーザー課題を解決するため、具体的な機能追加を行いました。 ファイルの判別性向上のため、ファイルが多くなった際に、どれが最新か/古いものか判別しやすくする機能を追加。 利便性の向上として、ダウンロードの進捗状況が確認できるように表示機能を改善。 セキュリティのためのセッション切れによる自動ログアウトを、ユーザーに通知する機能を追加。 ファイルの拡張子を見て、自動チェックの対象外か判断して通知する機能の追加。 2. 検収作業と購入手続きの理解 納品物（成果物）やライセンスなどが、発注内容に沿っているかを確認する 検収作業 を体験しました。 所属したチームは社内システムの運用を行っているため、検収作業が必要不可欠なのです。 この経験を通じて、会社がものやライセンスを どういう流れで購入するのか という、組織運営における重要なプロセスを認識できました。 特に高額なものを購入する際には「 稟議 」が必要となることを知り、初めてその言葉と手続きの重みを知りました。 3. アカウント発行申請のサポート 社員の入社時・退社時に行うアカウント関連の手続きについて社員の方と一緒に対応しました。 この業務を通して、社員の入退社に伴う手続きや、社内で使用するドライブの管理など、社内プラットフォームチーム が担う広範な管理業務 を認識することができました。 仕事に取り組む上で意識したこと 未経験で参加したからこそ、業務に取り組む上で以下の3点を常に意識して行動しました。 仕事の目的を考える ：目の前の作業をこなすだけでなく、その 一つ一つの仕事が何のために行われているのか という目的を考えながら取り組みました。これにより、業務の全体像やチームへの貢献度を理解する助けになりました。 自己解決能力と質問の質の向上 ：チームメンバーに質問する際は、まず自分で生成AIなども活用して徹底的に調べ、 自分がどこまで理解できていて、どこがわからないのかを明確にした 上で質問することを徹底しました。この結果、インターンを始めてすぐは自分がした質問がなかなかチームメンバーに伝わらないことが多かったのですが、インターンが終わる頃には自分の質問がしっかりと伝わるようになりました。 現場の雰囲気をつかむ ：真面目に業務に取り組む一方で、実際に働いている社員の方々の雰囲気や、チームの文化、働き方を間近で感じることも意識しました。これにより、チームとして大事にしていることと、将来自分が働いた時に、どんな現場で働きたいかのイメージが具体的につきました。 最後に 大学生活など様々なことと両立しながらの3ヶ月間の長期インターンシップは、私にとって非常に貴重な経験となりました。 インターンシップに参加する前、私は エンジニア＝開発をする役割 というイメージしか持っていませんでした。しかし、実際に現場に入ってみると、私が体験したような 運用や保守、検収、各種申請対応など、開発以外にも多岐にわたる重要な業務 があることを知りました。 この経験を経て、今ではツールのエンハンスだけでなく、 システムを安定稼働させるための運用や保守 にも非常に興味を持ち始めています。未経験で飛び込んだこのインターンで得た知見と経験を活かし、これからもエンジニアとしての目標に向かって邁進していきたいです。

この記事は、リレーブログ企画「Maker Faire Tokyo 2025ボードゲーム制作リレーブログ」の記事です。 はじめに Maker Faire Tokyo 2025 に向けて、ボードゲーム「通信パンク」のカード用イラストを担当しました。この記事では、やったことや工夫したことをサクッと振り返ります。 ちなみに「アグロ」ってなに？ 「アグロ」はカードゲームの用語です。低コストのカードで短期決着を狙うスタイルを指します。今回は工数とスピードを重視したので、「アグロ作画」と名付けました。 体制と役割分担 ポーズや全体デザインの提案：西野さん レイアウト、背景、配置、書体など：西野さん キャラクターの描き起こし（イラスト）：ムサシ 担当をはっきり分けたおかげで、迷いが少なくて進みが速かったです。イラストに集中できたのが効きました。ありがとうございます！ 表現方針：カードで映える「2〜3頭身」 カードサイズで“パッと可愛い”を狙って、2〜3頭身のデフォルメで統一。小さな面積でも情報が潰れにくく、視認性と個性のバランスが取りやすいのがポイントです。 制作プロセス（戻り少なめで一直線） 今回はこの順で進めました。初期に方向性を合わせたので、大きな差し戻しはほぼなし。 1. ラフ作成 2. チームで方向性の合意（ここでズレを解消） 3. 線画 4. 色塗り 5. 西野さんがカード用にデザイン調整（レイアウトや背景、配置など） 6. 最終チェック 目指すものがチームで一致していて、互いの専門性をリスペクトできていたのがスムーズさの理由でした。 ツールと制作環境 リモート期にセキュリティチームへ確認してペンタブの利用許可を取っていたため、自前の液晶タブレットで描きました。自宅は Windows、会社は Mac と環境が違っていて、しかも液タブは少し古めだったのでセットアップはやや大変でしたが、最終的には“慣れた道具”に寄せる判断が正解で、制作スピードをしっかり出せました。 これがあると助かるポイント どんなキャラクターか 性格、年齢感、世界観、参照イメージなどがあると精度が上がります どんなポーズ・シチュエーションか 表情やアクション、場面の意図が分かると初動が速いです この2点があるだけで工数がぐっと変わります。ラフや文字メモ、棒人間レベルでも伝わります。 かかり時間の目安（体感）｜キャラクター指定の有無で変わる話 時間がかかる順はこんな感じです。 完全おまかせ デザインに指定あり（指定が多いほど短縮しやすい） 既存キャラクターの使い回し “完全おまかせ”は自由度が高いぶん、方向性合わせに時間がかかりがち。逆に指定が多いほど、往復が減って仕上がりのブレも小さくなります。 今回の判断：既存キャラクターを活用｜キャラクター選定の理由 スケジュールがタイトだったので、既存キャラクター「BookBot ちゃんくん（としょだより、NIFTY Tech Book #1 にも登場）」を採用しました。 参考リンク 「としょだより」： こちら 「NIFTY Tech Book #1」： こちら （技術書典マーケットから無料DL可） メリット キャラクターデザイン案を決めるためのコミュニケーションの往復を短縮できる キャラクターデザイン側の微調整に他の時間を回せる 既にいるキャラクターなので、チーム内でイメージの整合がとりやすい 注意した点 「今回らしさ」をどこで出すかを先に決める 攻撃カードは悪そうにする 2Pカラーの差分を作る案もありました 直接的な表現ではなく間接的な表現にする 台風の影響で「トラフィックが遅くなる絵」ではなく、コミカルに「台風で困っている絵」を描く 配色、質感、目線の方向などの小さな差分でテーマの伝わり方が変わる 結果として、短期間でも統一感と読み取りやすさを両立できました。 おわりに 役割をクリアにして、最初に「キャラ」と「ポーズ・シチュエーション」をそろえる。ラフ段階で方向性を固めて、段階的に仕上げていく。これだけで制作はずっと滑らかになります。またカードを作ることがあれば、チームで速くて可愛い“カード映え”を積み重ねていきます。 次回はリレーブログ最終回、西根さんの「アイデアが”形”になるまでの物語。自作カードゲームの印刷からイベント出展までを振り返る」です！

概要 こんにちは。ニフティの山田です。 2025年10月21日に、Next.js 16がリリースされました。 https://nextjs.org/blog/next-16 大きな変更がそれなりにあるので、上記記事からピックアップしてみます。 破壊的変更点 ブラウザサポートのBaseline Widely Available基準への変更 Next.js 15からサポートブラウザが一気にバージョンアップしています。 Chrome Edge Firefox Opera Safari Next.js 15.5 64+ 79+ 67+ 51+ 12+ Next.js 16.0 111+ 111+ 111+ – 16.4+ これは単に上がったというだけでなく、 Web Platform Baseline におけるBaseline Widely Availableへの追従の結果としてこうなっています。 https://github.com/vercel/next.js/pull/84401  Widely Availableとなる要件は、主要ブラウザで30ヶ月以上利用可能であることです。 つまり、今後のNext.jsではメジャーバージョンアップのたびに 2.5年以上経過したブラウザは動作対象外 となることを想定する必要があります。 古いブラウザをサポートしたければ、 browserslistを設定してトランスパイルターゲットを変更 next.config.jsの transpilePackages で、クライアント側が使うライブラリをトランスパイル対象に追加 デフォルトではnode_modules以下はトランスパイル対象外となる… Fastly Polyfill などにより、トランスパイルで対応できない部分にPolyfillを追加 などの対応がより重要となってきます。特にpolyfillについて、Next.jsは独自に内蔵するpolyfillコードを使っているため、Next.jsサポート範囲外の対応には別のpolyfillコードを差し込まなければいけない点に注意が必要です。 middleware.ts → proxy.tsへの変更 middlewareの名前が変更となりました。 一般的にmiddlewareと呼ばれるものとは異なる機能であるため、わかりやすさのためにこうなったようです。 next lintコマンドの削除 以前のNext.jsでは eslint コマンドではなく、 next lint コマンドを利用してeslintを実行するのが推奨になっていました。eslint以外にもbiomeなどの選択肢が出てきたことから、この機能は削除となりました。今後は eslint コマンドを直接叩けばよいです。 なおNext.js 15.5の時点でdeprecatedになっていたので、そこで対応していれば問題ないはずです。 turbopackデフォルト化 バンドラとして従来使われてきたwebpackに代わり、ようやくturbopackがデフォルトとなります。 今まではturbopackを使用するのにCLIオプションが必要でした。 next dev --turbopack next build --turbopack 今後はturbopackがデフォルトとなり、逆にwebpackを使いたいときにのみオプションを指定する形となります。 next dev --webpack next build --webpack 新機能 Cache Components 今までExperimentalでPartial Pre-Rendering(PPR)やDynamicIOの名前で実装されていたものが正式版となります。 Next.js 13で導入されたApp Routerではキャッシュ制御が非常に重要になりますが、 fetch() がキャッシュ機能を持つものに暗黙的に置き換わるなど予測しにくい挙動をしていました。このため、Next.js 15でキャッシュのデフォルト無効化などの変更が行われる事態が発生しています。 そこで出来たのが新しい use cache によるキャッシュ制御です。以下はNext.js 16公式ブログから引用しています。 // File level 'use cache' export default async function Page() { // ... } // Component level export async function MyComponent() { 'use cache' return <></> } // Function level export async function getData() { 'use cache' const data = await fetch('/api/data') return data } use cache を記述することでキャッシュを有効化します。上記にあるように、記載位置によってファイルレベル・関数レベルでキャッシュ有効化単位を制御できます。 cacheLifeなど、キャッシュ時間を制御するための仕組みも増えました。 'use cache' import { cacheLife } from 'next/cache' export default async function Page() { cacheLife('hours') return <div>Page</div> } キャッシュの仕組みを変えることになるため、現状では設定しなければ有効になりません。 const nextConfig = { cacheComponents: true, }; export default nextConfig; おそらく今後はこちらを主流にしていくのではないかと思われます。 従来のキャッシュ制御も引き続き利用可能ですが、将来的にはどこかで移行することになるでしょう。 React Compiler対応 React CompilerはReactコードの最適化機能です。 https://ja.react.dev/learn/react-compiler ビルド時にコードを解析することで useMemo() や useCallback() などのメモ化コードを自動的に挿入し、レンダリングの最適化を行います。開発者はメモ化のことを意識しなくて良くなる、という機能です。 これがNext.jsでも使えるようになりました。 対応するには設定を加えたうえで const nextConfig = { reactCompiler: true, }; export default nextConfig; React Compilerのインストールが必要となります pnpm add -D babel-plugin-react-compiler 注意点として、React Compilerは babelプラグインとしての提供 となることが挙げられます。SWCで実行されないので、ビルドが遅くなる可能性が高いことに注意が必要です。 おわりに 今回は、2025年10月21日にリリースされたNext.js 16がリリースについて解説しました。 参考になれば幸いです。

はじめに こんにちは！新卒1年目のなべしま、宮村、坂野です。 ニフティでは、毎年新人育成の一環として「エンジニア定例」や、3日間にわたる開発合宿「エンジニア定例合宿」が行われています。 今回は、この「エンジニア定例合宿」で私たちが作成したアプリケーションを紹介します。 実際の合宿の様子や食事、成果報告会についてはこちらに載っていますので、ぜひご覧ください！ 今年はいつもと違う？ハッカソン合宿に行ってきました！@マホロバ・マインズ三浦 メンバー紹介 メンバーはこの3人です。動物（生き物）好きが多い気がします。 なべしま ダイアウルフかわいい 宮村 クラゲにハマっている 坂野 マヌルネコが好きすぎる アプリ紹介 概要 私たちは、食材管理とレシピ提案を統合したWebアプリケーションを作成しました。 主な機能として、AIが冷蔵庫の食材からレシピを自動提案する機能や、料理と連動した食材の自動消費管理機能などがあります。 アプリ画面・特徴 冷蔵庫画面 冷蔵庫内の食材がパネルとして整列しており、ここから直感的に材料の個数や量、消費期限の登録ができます。 このページはログイン必須で、冷蔵庫の中身はユーザーごとに独立しています。また、ユーザーがログインしていない場合は、Keycloakのログイン画面にリダイレクトされます。 レシピ詳細画面 材料の分量一覧と作り方を表示しています。 下の「材料を消費」ボタンを押すと、冷蔵庫の中身が、賞味期限が早いものから順に材料分だけ消費されます。 AIおすすめ機能 冷蔵庫の材料から、おすすめのレシピを提案します。 生成された料理名をクリックすると、レシピ詳細ページへ移動します。 使用技術 今回採用した技術スタックは以下の通りです。 これらを選定した理由としては、フロントエンドとバックエンドに分離しないシンプルなフルスタックアプリケーションにすることで、タスクの属人化や環境構築、学習コストを最小限に抑えることなどがあります。 アプリケーション: Next.js , Prisma , NextAuth.js データベース: PostgreSQL 認証基盤: Keycloak その他 : Amazon Bedrock (Claude Sonnet 4.5) そして、環境構築の時間を短縮するため、アプリケーションのベースには、社内プロジェクトである、 NIFTY Programming Best Practices(PBP) のNext.jsリポジトリを使用しました。 NIFTY Programming Best Practices(PBP)とは 開発のベストプラクティスを集約するProgramming Best Practicesプロジェクトです PBPは技術毎にベストプラクティスをドキュメントやテンプレートとして集積を行っており、標準化はどの技術を社内標準とするか決定しています。 社内ナレッジ NIFTY Programming Best Practices(PBP) 開発の流れ 1日目: 環境構築とプロジェクト設計 環境構築 、データベース設計 (午後) PBPを用いた初期のフロントエンド環境の構築 Claude Code Action の導入 Keycloak の導入 Prisma を用いたデータベースのセットアップとテーブル設計 タスクの具体化 (夕方) 実装すべき機能の具体化とタスクの洗い出し 2日目: 環境設定の最終調整とフロントエンド・認証機能の実装 環境構築の仕上げ (午前) Keycloak のRealm作成などの環境設定 データ投入、UI・認証機能の実装 (午後) レイアウト、メニューバーといったUI周りの実装 ログイン機能の実装 デモに必要なサンプルデータを追加 レシピ、冷蔵庫のビジネスロジックの実装 「冷蔵庫の中身からおすすめする機能」に関する調査、実装 最終日: 主要機能の仕上げと成果発表に向けた資料作成 機能実装の完了、AWS 整備 (午前) 未完了だったビジネスロジックの実装 CDパイプラインの構築やビルドプロセスの修正 発表資料の作成 (午後) 機能実装と並行して、 Marp を用いた発表資料の作成 開発工程でのGoodポイント Keycloakの利用によるユーザ管理の責務の分離 ユーザー管理の実装負荷や、その責務をWebアプリケーションから分離することを考え、外部IdPを利用する方針で進めていました。Amazon Cognitoを使用する予定でしたが、ローカル環境でのテストを考慮した結果、採用は見送りました。結果として、IdP側はKeycloak、認証ライブラリ側はNextAuth.jsを使用しました。この二つの連携や実装に関する情報はかなり豊富で、開発を円滑に進めることができたと感じています。 Claude Code / Claude Code Actionの活用 今回の開発では、Claude Code Actionを活用して人間のコーディング量を最小限に抑えることを目指しました。設計段階でMermaidで作成したER図をもとに、モデルファイルと関連する環境構築まで終わらせることができました。一方で、CIの修正の自動化やGitHub Actionsの権限の修正・調査に時間をかけられず、終盤まで活用し切ることはできませんでした。 常に情報共有を行い、最後まで挑戦し続けた 合宿の3チームの中で、雑談からカンバンのタスク内容や構造に関する議論まで、最も活発なコミュニケーションが行われたチームだと感じています。この常に共有する姿勢が、高いチーム結束力を生み出し、最後まで一丸となって課題に挑戦し続ける原動力になりました。 まとめ 今回は、3日間のハッカソンで開発したアプリケーションを紹介させていただきました。 AWSへのインフラ構築は残念ながら時間不足で実現できませんでしたが、認証機能の実装や環境構築など、実務にも活きる要素を利用した開発はとても良い経験となりました。また、これらを活用した開発や、チーム一丸となって取り組む姿勢は、今後の業務でも継続していきたいと感じました。 一方で、初めて使う技術の知識不足や、入念な設計の必要性など、自分たちの課題も認識できました。 合宿で得た経験を、これからの業務に活かしていけたらと思います！

この記事は、リレーブログ企画「Maker Faire Tokyo 2025ボードゲーム制作リレーブログ」の記事です。 記事の概要 ボードゲーム部がオリジナルカードゲームをつくるまでの道のりを紹介します。カードデザインの裏話も交えます。 はじめに ニフティには「ブカツ制度」があります。私が所属するのはボードゲーム部は、市販のゲームを持ち寄って遊ぶシンプルで楽しいブカツです。 ある日、Maker Faire Tokyo 2025 の推進メンバー寺島さんが自作ゲームを持参してくれました。イベントなどで個人制作のゲームをみることはありましたが、「自分でも作れるんだ」と実感したのはこの瞬間でした。 ISPでカードゲーム？ 数ヶ月後、Maker Faire Tokyo 2025 のニフティブースでオリジナルカードゲームを出そう、という話が始動します。ボードゲームは大好きですが、制作経験はゼロです。それでも「せっかくならやってみよう」と手を挙げました。 私は大学でデザインを学んでいたので、デザインまわりと初期ルール作成を担当しました。 ボードゲーム部でISPをテーマに募られたゲームのアイデアは大盛り上がりし、トークン（コマ）も自作できるのでは？ と夢が膨らむ時期でした。 今見ても結構おもしろかったので、メモを残しておきます。 HTTPステータスコードかるた（かるたは既存のものがかなりあるので頓挫しました） ネットワークの配線 サーバー運用 ニフティサーブをテーマにしたコミュニケーションゲーム スクラムのPBI分割をゲーム化 「22」と「パケット」をテーマにデザイン 検討の結果、既存ルールの発展形が進めやすいと判断しブラックジャックをベースにしました。 ブラックジャックは到達値が21です。けれどニフティといえば 22。これはニ(2)フ(2)ティの語呂です。 毎月「2」の日や「22」日はニフくじが当たりやすい ので、覚えておいてください！ テーマは「通信・トラフィック」。当初見積もりしていた納期が短期間だったため、ルール作成と並走でデザインを進めます。 裏面 初期案 「22」の中にカタカナの「ニフ」を入れ込んでいます。収まりが良く、ほぼこのまま採用しました。 表面 初期 テストプレイ用に、ムサシさんの既存イラストを仮素材で拝借しています。初期案では「数字を分割する」要素が一部残っていますね。 テストプレイは、元ネタがブラックジャックなのでトランプの代用で十分でしたが、そのおかげで、表面の情報が少ないことに気づき、役札へフレーバーテキストを入れる方針を前倒しで決められました。 表面のデザイン詰め 数字フォントを大きく置くだけでは間が持たなかったため、数字自体をデザインしています。数字は、デジタル感とパケットの粒感をイメージし、丸いドットでの構成にしました。 席の隣でムサシさんがラフを描いてくれていたので、役札に絵を当て込んだ瞬間「かわいい！」「カードゲームっぽい！」とその場で盛り上がりを共有できました。 数字のデザインは、数が大きくなるほどパケットの色味を増やし、トラフィックの混雑感を視覚化しています。 数字に関する社内フィードバックでは、 6 と 9 が判別しづらいという意見があり下線を追加して視認性を改善しています。 この段階でプリントしてカードサイズに切り、フレーバーテキストなど文章の可読性のチェックもしました。 こういった制作の進捗は Slack でこまめに共有し、リアクションなどで即フィードバックをもらいました。通常業務と並走しながらも、テンポよく前に進めたと思います。 入稿 カード 1 セット分の画像を量産するため、共通オブジェクト（インスタンス化）して配置しています。後からの編集もしやすくてラクでした。 トンボなど入稿要件は印刷会社に確認し、一次入稿でチェックを受け、最終までスムーズに運びました。 ロゴとパネル ブースにルールを書いたパネルも出すことになったため、ロゴとパネルを追加で制作しました。 文章はプロジェクトをリードしてくれた西根さんに依頼し、レイアウトを担当しています。 今回はパッケージがなくロゴの出番は少なめなので、終盤に一気に仕上げました。 ロゴの配色はカード表面と合わせ、統一感をだしています。 やってよかったこと 途中段階でも共有とレビューをしたことで、齟齬や手戻りを最小化 画像は PNG形式で共有ドライブに格納し誰でも扱える状態にし、つくりものの全体トーン統一 イラストとデザインの担当者が分かれていたが、一緒に作業してラフが出た時点でカードに当て込みをし、出来上がりのイメージを共有 最後に 印刷が上がった瞬間以上に、ブースで来場者が楽しそうにプレイしている姿は別格の喜びがありました。「遊ぶブカツ」から「作れるブカツ」へ、ひとつ階段を上れた気がします。 普段はスクラムマスターですが、久々に紙のデザインに向き合えたことも楽しかったです。 Maker Faire Tokyo 2025 はクリエイターのお祭りです。ニフティのクリエイティブな部分を、このカードゲームから少しでも感じてもらえていたら嬉しいです。 次回は、イラスト担当・ムサシさんの「イラスト制作：アグロ作画で可愛さ確定」をお届けします。

こんにちは。25年新入社員の高垣です。 私は、新人研修の一環として10月に開発合宿に参加しました。開発合宿については以下のブログをご覧ください。 今年はいつもと違う？ハッカソン合宿に行ってきました！@マホロバ・マインズ三浦 その時に、2025/10/13(米国時間)に一般公開されたAmazon Bedrock AgentCoreを使って開発しました。このブログでは、その感想や実装について述べようと思います。 Amazon Bedrock AgentCoreとは Amazon Bedrock AgentCore(以下AgentCore)とは、AIエージェントの構築からデプロイ・運用までできる基盤です。具体的には以下の7つのサービスがあります。 Runtime: サーバレスの実行環境 Identity: エージェントに対する認証情報(アウトバウンド・インバウンド両方)を管理するもの Memory: エージェントが何を記憶するかを制御する Code Interpreter: 分離されたサンドボックス環境内でコードを安全に実行する Browser: クラウドベースのブラウザ実行環境 Gateway: APIやLambda関数などの既存のサービスをエージェント互換のツールへ簡単に変換する Observability: エージェントのモニタリング どのように使用したのか 今回は実行環境としてRuntimeのみ使用しています。アプリケーション全体の構成は次の図のとおりです。Orchestratorエージェントはユーザからの入力を受け取り、Create_taskエージェントは入力に基づいたタスクを生成しています。詳細は以下のブログをご覧ください。 ハッカソン合宿制作記① | SolidStartとAgentCoreを使ったAIエージェント内蔵アプリケーションを作ってみた エージェントの中身について ２つのエージェントは役割が違いますが、中身はほとんど同じです。 両者共に、Bedrock AgentCore Runtimeフレームワークを使用してエージェントの振る舞いを定義しています。 例:Orchestratorエージェントの場合 @app.entrypoint def invoke(payload: Dict[str, Any]) -> str: try: # promptを読み取る request_text = payload.get("prompt", "") if not request_text: return json.dumps({ "status": "error", "message": "リクエストが指定されていません" }, ensure_ascii=False) # ユーザからの入力を分析し、適切なエージェントを決定 agent_decision = analyze_request(request_text) if agent_decision["action"] == "create_task": # Create_taskエージェントを呼び出す result = invoke_create_task_agentcore(request_text) # レスポンスを作る response = { "orchestrator_analysis": { "recommended_agent": agent_decision["agent"], "reason": agent_decision["reason"], "confidence": agent_decision["confidence"] }, "result": result } return json.dumps(response, ensure_ascii=False) @app.entrypointというデコレータでこの関数をAgentCore Runtimeのエントリーポイントとして登録しています。 Orchestratorエージェントの場合は、promptを読み取り、そこから適切なエージェントを決定して、エージェントに処理を投げています。 AIエージェントのフレームワークについては、最初に簡単な処理を作って動作を確認してからStrands AgentsかLangGraphを使おうと思っていました。ただ、時間がなかったので、今回はそれらは使用できませんでした(はじめからどちらかを使っておけばよかったと思っています…)。 デプロイについて AWSのチュートリアルではコマンドを使ってデプロイしています。 https://aws.amazon.com/jp/blogs/startup/5min-ai-agent-hosting/ ですが、今回はPythonのSDKを使ってデプロイしました(Claude Codeに作ってもらいました)。 例:Orchestratorエージェントをデプロイするコード import json import os import sys from pathlib import Path from bedrock_agentcore_starter_toolkit.notebook.runtime.bedrock_agentcore import Runtime # リージョン設定 REGION = "ap-northeast-1" PROJECT_NAME = "task-management" def deploy_orchestrator_agent(): """Orchestrator Agentをデプロイ""" print("\n Orchestrator Agent をデプロイ中...") # deployment_info.jsonからCreate Task AgentのARNを取得 deployment_file = Path(__file__).parent / "deployment_info.json" if not deployment_file.exists(): print(" deployment_info.jsonが見つかりません") print("先にCreate Task Agentをデプロイしてください:") sys.exit(1) with open(deployment_file, "r") as f: deployment_info = json.load(f) create_task_info = deployment_info.get("create_task_agent", {}) create_task_arn = create_task_info.get("agent_arn") if not create_task_arn: print(" Create Task AgentのARN情報が見つかりません") print("deployment_info.json:") print(json.dumps(deployment_info, indent=2, ensure_ascii=False)) sys.exit(1) print(f"✓ Create Task Agent ARN: {create_task_arn}") runtime = Runtime() # Orchestrator Agentの設定 config_result = runtime.configure( entrypoint="orchestrator/agent.py", agent_name="orchestrator_agent", requirements_file="orchestrator/requirements.txt", region=REGION, protocol="HTTP", memory_mode="NO_MEMORY", # メモリ不要 auto_create_execution_role=True, auto_create_ecr=True, disable_otel=False, # OpenTelemetry有効 non_interactive=True ) print(f"✓ 設定完了") print(f" Config: {config_result.config_path}") print(f" Dockerfile: {config_result.dockerfile_path}") # Bedrock AgentCore Runtimeにデプロイ（launch） print(" Bedrock AgentCore Runtimeにデプロイ中...") launch_result = runtime.launch( local=False, # リモートデプロイ local_build=False, auto_update_on_conflict=True, env_vars={ "CREATE_TASK_AGENT_ARN": create_task_arn, "AWS_REGION": REGION } ) print(f"✓ デプロイ完了") print(f" Agent ARN: {launch_result.agent_arn}") if hasattr(launch_result, 'agent_endpoint'): print(f" Agent Endpoint: {launch_result.agent_endpoint}") # デプロイ情報を更新 deployment_file = Path(__file__).parent / "deployment_info.json" with open(deployment_file, "r") as f: deployment_info = json.load(f) deployment_info["orchestrator_agent"] = { "agent_name": "orchestrator_agent", "agent_arn": launch_result.agent_arn, "agent_id": getattr(launch_result, 'agent_id', None), "agent_endpoint": getattr(launch_result, 'agent_endpoint', None), "status": "deployed", "create_task_agent_arn": create_task_arn } with open(deployment_file, "w") as f: json.dump(deployment_info, f, indent=2, ensure_ascii=False) print(f"\n デプロイ情報を更新: {deployment_file}") return { "agent_name": "orchestrator_agent", "agent_arn": launch_result.agent_arn, "agent_id": getattr(launch_result, 'agent_id', None), "agent_endpoint": getattr(launch_result, 'agent_endpoint', None), "status": "deployed" } def main(): print(" Orchestrator Agent デプロイスクリプト") print(f"Region: {REGION}") print(f"Project: {PROJECT_NAME}") print() try: orchestrator_info = deploy_orchestrator_agent() print("\n Orchestrator Agent のデプロイが完了しました！") print(f"\nAgent ARN: {orchestrator_info['agent_arn']}") if orchestrator_info.get('agent_endpoint'): print(f"Agent Endpoint: {orchestrator_info['agent_endpoint']}") except Exception as e: print(f"\n エラーが発生しました: {str(e)}") import traceback traceback.print_exc() sys.exit(1) if __name__ == "__main__": main() 苦労したこと 情報が少ない AgentCoreは2025年10月13日(米国時間)にリリースされましたが、その前にプレビューとして一部のリージョンで2025年7月16日に公開されていました。しかしながら、公開されてから3ヶ月弱しか期間がなく、AgentCoreに関する記事が十分にありませんでした。 そんな中でも、参考にしたサイトがいくつかあるので共有します。 https://blog.msysh.me/posts/2025/08/agentcore-runtime-stream-response-via-lambda.html#lambda-のコード-1—agentcore-からの応答をそのまま返す場合 https://aws.amazon.com/jp/blogs/machine-learning/build-multi-agent-site-reliability-engineering-assistants-with-amazon-bedrock-agentcore/ Amazon Bedrock Agentsとの違いを理解する必要がある AWSが提供しているAIエージェント系のサービスでAmazon Bedrock Agents(以下Bedrock Agents)というものがあります。 https://aws.amazon.com/jp/bedrock/agents/ こちらは、Amazon Bedrockの一部でLLMのモデルを指定するだけでAIエージェントを作成することができます。ただし、文字列のレスポンスを返したり、lambdaなどの関数を実行したりすることしかできないので、自由度は低めです。一方で、AgentCoreは実質Pythonコードを動かしているため、jsonを返したり、複雑な処理を実行することができます。この違いを理解しないと、開発途中で大きな手戻りが発生してしまう可能性があります。 今回の場合だと、初めはBedrock Agentsで開発していましたが、後から決まったレスポンスを返す必要があることがわかりました。いくらプロンプトを修正してもlambdaを実行してくれなかったり、lambdaへの入力が違ったりしたので、途中からAgentCoreを用いて開発しました。 参考程度に、Bedrock AgentsとAgentCoreの比較表を載せます。 Bedrock Agents AgentCore 役割 AIエージェント AIエージェントを実行する基盤 開発方法 AWSマネジメントコンソール Pythonコード(フレームワーク) 料金 Bedrockの料金体系 AgentCoreの料金体系 デプロイ 不要 SDKかAgentcore CLI Bedrock AgentsとAgentCoreの比較 AIエージェントを組み込んだプロダクトを作る際の前提知識が不足していた(わからなかった) 今回初めてAIエージェントを組み込んだプロダクトを作りましたが、前提知識が不足していたと思っています。理由としては、開発時に詰まった際に、「これがわからないからここを調べよう」というよりも、「ここがわからないけど、これはそもそもなんなんだ」と思うことが多くあったからです。前提知識がなく、時間があまりない中で調べながら開発したため、十分に開発することはできませんでした。 この経験から、前提知識として以下のようなものを知っておくことをおすすめします。 AIエージェントを組み込んだプロダクトに対するブログや記事があるか 先駆者の知識や経験は非常に参考になると思います LangGraphや Strands Agentsなどのフレームワークについて フレームワークの名前だけ知っていても十分だと思います インフラについて AgentCore以外にもVertex AI Agent BuilderやAzure AI Foundry Agent Serviceなどの選択肢があります AIエージェントのデザインパターンについて 感想 AIエージェントを使ったサービスを作りたい際は、Bedrock Agentsに比べてAgentCoreの方が柔軟に開発できるので、AgentCoreを使った方が良いと思います。ただし、Bedrock Agentsの方が比較的簡単に作れるので、初めにBedrock Agentsでプロトタイプを作ってから、AgentCoreで本番開発をするという流れでも良いと思います。 また、AgentCoreはあくまでも基盤なので、フレームワーク等でAIを呼ぶ処理を書くようにしましょう(1敗)。 最後に、AgentCoreを使った開発は楽しかったです。AIエージェントの可能性を感じることができましたし、情報があまりない中で調べながら開発することはとてもワクワクしました。

この記事は、リレーブログ企画「Maker Faire Tokyo 2025ボードゲーム制作リレーブログ」の記事です。 こんにちは！Maker Faire Tokyo 2025 リレーブログのバトンを受け取りました、西根です。 普段はニフティポイントクラブの開発・運用を担当していますが、プライベートではボードゲームで遊ぶのが大好きです。 そんな「ただのボードゲーム好き」な私が、今回ひょんなことから Maker Faire Tokyo 2025 に出展するオリジナルカードゲームの ルールデザイン を担当することになりました。 この記事では、専門知識ゼロの私たちが、どうやって「面白い」の核となるゲームルールを作り上げていったのかのプロセスをご紹介します。 ステップ1：ゲームの方針決め 何から手をつけるべきか全くわからなかったため、まずは「ボードゲーム 自作」などで検索し、先人たちの知恵が詰まった記事を数本読み漁るところからスタートしました。 なんとなく流れを掴んだところで、社内のボードゲーム好きな関係者を集めてキックオフミーティングを開催。 ここで、プロジェクトの「骨格」となる重要な方針を決めました。 1. コンポーネントを決める 「どんなゲームにするか」の前に、まず「何が作れるのか」という現実的な制約を確認しました。 事前にいくつかの印刷所を調べ、予算と納期、そして「ゲーム制作の難易度（＝コンポーネントの複雑さ）」を考慮し、今回は「カード」をメインにしたゲームに絞ることにしました。 2. 対象ユーザーを決める ゲームの難易度を決める上で、これは非常に重要な指標です。 Maker Faire Tokyoの参加者は半分近くが親子連れというデータを参考に、「持って帰って家族でも遊べると良いよね」という話になりました。 プレイ人数: 2〜4人 対象年齢: 小学5年生〜くらい （ちなみに、当日は想定より小さいお子さんもたくさん遊んでくれました！これは別の記事で詳しく書きますが、事前に「小さい子にはちょっと複雑かも…」という意見を受け、簡略化ルールを考えておいたのが功を奏しました） 3. テーマ・体験を決める せっかくニフティとして出すからには、「ネットワークやITに関連するテーマにしたい」という共通認識がありました。 また、ゼロから独創的なゲームシステムを考えるのはハードルが高いため、「既存のカードゲームやトランプをベースに、ニフティらしさをアレンジする」という方向性で話し合いました。 最終的に、ニフティという社名にちなんで、手札の合計値が22になることを目指すブラックジャックのようなゲームにすることに決定しました。 この日は、その場で既存ゲームをベースにしたアイデアをいくつか出し合い、解散となりました。 ステップ2：テーマとタイトル決定 次の打ち合わせでは、前回出たアイデアを3案に絞り込み、カードデザインの難易度や懸念点を考慮しつつテーマを何にするか話し合いました。 ソフトウェア開発（スクラム開発）に寄せるか、家庭内ネットワークに寄せるかなど議論がありましたが、インターネット通信について興味を持ってもらうきっかけになって欲しいという思いから、ニフティの主力事業である「ISP（インターネット・サービス・プロバイダ）」に絡めたゲーム案に決定しました！ タイトルはAIと多数決で テーマが決まればタイトルも必要です。ここでは生成AIが大活躍しました。 私たちが考えたゲームの概要をAIに渡し、とにかく大量のタイトル案を出してもらいました。 その中からキャッチーで良さそうなものを3つに絞り、ボードゲームに興味がある社内の人たちに投票してもらって決定。（面白いことに、投票結果はかなり偏り、「やっぱりこれが良いよね」と最初に盛り上がっていた案に収束しました） ステップ3：ひたすらテストプレイ ルール案の大枠ができたら、あとはひたすらテストプレイです。「面白くなかったら修正」を地道に繰り返しました。 1回目：身内（デザイン・イラスト担当） まずはプロジェクトメンバーのうち、コンポーネントに関係する人で実施しました。 まずはゲームの流れを確認し、社内のカードゲーム好きな人にゲームバランスの取り方などを聞きつつ、ターン数は有限にするのか、特殊カードの割合はどのくらいにするかなどを1から決めていきました。 2回目：外部（企画担当、無関係な人） 次に、このプロジェクトに全く関わっていない人も含め、 別の人 に遊んでもらいました。 ルール説明が伝わるか、直感的に面白いか、客観的な意見をもらう絶好の機会となったので、ルールデザイン中に実施してよかったです！ ルールの「解像度」を上げる ゲームを盛り上げるイベントカードにはISPらしさを持たせたかったので、実際にISPチームの人に「トラフィックが増えるイベントって具体的に何があります？」とヒアリングし、カード名にリアリティを持たせました。 最後は、AIにルールブックの草案を整形してもらい、ルールの穴や矛盾点がないかを客観的にチェックしました。（それでも後に穴が出てきたりはしましたが…） ルールデザインを終えてみて 今回、ルールデザインという大役を（勢いで）引き受けましたが、終わってみて感じたのは以下の3つです。 意外と初心者でもルールは作れる！ 既存のゲームをベースにすることで、面白さの土台が担保されるため、初心者でも十分に楽しんでもらえるゲームルールを作ることは可能でした。 「作り手のバイアス」を捨てる これが一番大事かもしれません。自分が作ったゲームは「ここが面白いだろ！」というバイアスにかかりがちです。テストプレイでは、とにかく素直に意見を聞き入れ、「どうするともっと面白くできるか？」を深掘りする構えが必要だと痛感しました。 AIは最高の壁打ち相手 タイトルの案出しやルールの穴探しなど、人間の思い込みを排除したい作業において、AIは最高のパートナーでした。AIをフル活用したことで、短時間でクオリティを上げることができたと思います。 なにより、当日のアンケートで「ルールが面白かった」というコメントを見つけた時は、本当に嬉しかったです！ 「ただのボドゲ好き」がどこまでやれるのか不安でしたが、挑戦して本当に良かったと思っています。 次回は、西野さんによる「ISPがつくる、カードゲームのデザインができるまで」です！  

この記事は、リレーブログ企画「Maker Faire Tokyo 2025ボードゲーム制作リレーブログ」の記事です。 はじめに Maker Faire Tokyo 2025 に向けて、私たちのブースでは「ボードゲーム」を制作しました！この記事では、限られた期間の中でどのように印刷・製作パートナーを選び、形にしていったのか、その裏側をご紹介します。 印刷所選定の状況 イベントまで約1カ月半。ボードゲーム専門の印刷所では納期が厳しい見通し…！ 企画内容も固めている最中で、仕様変更に柔軟に伴走してくれるパートナーが必要でした。 ここにお願いして正解だった話 以前、店舗用の什器の製作をしてくれて、グッズの制作からポスターの制作まで幅広く対応している「 東京リスマチック社 」に相談しました。 次に、トランプなどの事例を一緒に見ながら「ここはこうしよう」「この部分は調整しよう」と仕様を少しずつ固めていきました。東京リスマチック社様がとても柔軟に対応してくれて、こちらの事情に合わせた進め方に調整。結果として、納期にもちゃんと余裕を持てる進行に整えられました。 その結果、ボードゲームは予定通りに、むしろ少し早めに仕上がりました。会場でも「いいね」という声をいただけて、当日の運用もしやすい仕立てになったと感じています。 印刷の仕様 今回はブース参加者への配布を目的に小ロットで制作し、小ロットに適したオンデマンド印刷を採用しました。予算の都合により PP 加工は行わず、これらの選択によってカードゲームを比較的安価に印刷することができました。 感想 企画メンバーと東京リスマチック社様の間をスムーズにつなげられ、納期にしっかり間に合わせられてほっとしました！ 難易度の高い相談にも関わらず、柔軟にご対応いただき本当にありがたかったです！ 次回以降のイベント制作物についても、ぜひ東京リスマチック社様にご相談したいと思います！ まとめ 短い準備期間でも、要件を明確にし、柔軟に伴走してくれるパートナーと早期に連携できれば、品質とスピードを両立できます。今回の学びを次のプロジェクトにも活かしていこうと思います！ 次回は西根さんで「ただのボードゲーム好きがオリジナルカードゲームのルールをデザインした話」です！

11/13 に開催される 【日経×ニフティ×アンドパッド】モバイルアプリでつなぐ現場と暮らし〜情報が“届く”を再設計する〜 に当社エンジニアが登壇いたします。 ニフティのエンジニアの川上が、ニフティ会員向けiOS/Androidアプリ「 マイ ニフティ 」についてお話しします。 登壇のスケジュールは以下の通りです。 タイトル 「なぜかネットが遅い」を“見える化”する 〜マイ ニフティが繋ぐサポートと暮らし〜 日時 2025/11/13(木) 19:00 〜 21:00 （イベント開催期間） オンラインで視聴可能なイベントです。ぜひ以下のイベントページからご参加ください。 https://nikkei.connpass.com/event/372833/

はじめに こんにちは。25年新卒入社のmori、高垣、石田です。 私たちは今回、ニフティで毎年開催されている3日間の新人向けの開発合宿に参加してきました！ 本記事では、今回作成したwebアプリや得た学びについてご紹介します。 また、合宿全体の概要・様子はこちらの記事で公開しているので、ぜひ併せてご覧ください！ 今年はいつもと違う？ハッカソン合宿に行ってきました！@マホロバ・マインズ三浦 メンバー紹介 mori バックエンド担当 高垣 インフラ(AIエージェントを含む)担当 石田 フロントエンド担当 アプリ紹介 概要 今回作成したアプリは、「AIがサポートするタスク管理アプリケーション」です。ユーザがやりたいこと(目標)を入力すると、AIエージェントが実行可能なタスクに分解してくれます。未着手・進行中・完了といったステータス管理と優先度設定で、効率的な目標達成をサポートします。 画面 ホーム画面 ホーム画面では、画面中央のフォームから目標を入力し、「タスクに分解する」をクリックすると、AIエージェントがタスクを分解してくれます。 その後、タスク分解が完了すると、自動でタスク一覧画面に遷移します。 タスク一覧画面 このページでは、入力した目標に対して生成されたタスクが一覧表示されます。また、各タスクをドラッグ操作すると進捗状況を変更できるため、進捗管理もこの画面で完結できます。 各タスクをクリックすると、タスク詳細画面に遷移します。 タスク詳細画面 タスク詳細画面では、タスクの説明や期限等の情報が確認できます。 メニューバー   メインとして使用するのは上記３画面で、各画面間はメニューバーから簡単に遷移できます。 メニューバー左のハンバーガーメニューをクリックすると、目標が一覧表示されます。また、各目標はトグルになっており、クリックすると目標に紐づくタスクが表示されます。 このように、どの画面からでもホーム画面やタスク一覧・詳細画面に簡単に移動することができます。 使用技術 フロントエンド SolidStart バックエンド SolidStart インフラ AWS データベース PostgreSQL AIエージェント Bedrock AgentCore Runtime(基盤), Claude Sonnet 4.5(Bedrockから使用) ツール系 Claude Code, Spec Kit, Serena, mise, pnpm 構成図 今回作成したアプリの構成図は以下のようになっています。フロントエンドとバックエンドにSolidStartを使用し、データベースはPostgreSQLを使用しています。また、フロントエンドからはSolidStartのAPIエンドポイントを呼び出して、バックエンドがlambdaを介してBedrock AgentCore Runtimeで構築したエージェントを呼び出しています。AgentCore RuntimeのエンドポイントURLには、エージェントのARNが含まれており、エージェントのARNには、アカウントIDが含まれています。そのため、自前のバックエンドとlambdaを介すことで、フロンドエンドからアカウントIDが見えないようになっています。 開発の流れ 0日目: 事前準備 アイデアソン 技術選定・担当決め 1日目: 環境構築・実装 開発環境構築 要件定義・画面設計・テーブル設計など フロントエンド・バックエンドの実装 2日目: 実装 AIエージェントの実装 フロントエンドとバックエンドをそれぞれ分担して開発 フロントエンドとバックエンドの連携 3日目: 実装・成果発表 AIエージェントの調整 フロントエンドとバックエンドの最終統合 成果発表 工夫した点 ユーザビリティの向上 どの画面からでも、タスク管理へ遷移できるメニューバーを追加しました。 タスクの進捗が一目で確認できるよう、タスクボードはカンバン形式で実装しました。各タスクはドラッグ操作による進捗変更も可能で、タスク管理も簡単に行えます。 ユーザが操作しやすいよう、直観的なレイアウトになるよう工夫しました。 モダン技術の導入 以下のツールを採用しました。 Spec Kit ：仕様を読み込んで開発計画を作成し、ガードレール設定・一貫性のあるコード生成を支援します。 リリース：2025/9/2 Bedrock AgentCore ：AIエージェントの構築から運用までできる基盤です。今回はAIエージェントをデプロイをするために、AgentCore Runtimeを使用しました。 リリース：2025/10/13(米国時間)(合宿直前!!) SolidStart ：SolidJSをフロントエンドフレームワークとして使用するフルスタックフレームワークです。SolidJSについては以下の記事も併せてご覧ください。 リリース：2024/5 SolidJSという選択肢 mise ：事前に設定したツールチェインやタスクをファイルで共有することで、環境構築を簡易化し、プロジェクトでの管理を可能にしました。 miseを用いたツール管理 以下のツールをmiseを用いてインストール、管理したことによって、DBに用いたdocker以外すべてをプロジェクトによる管理下におきました。 node pnpm claude code serena aws cli また、DBのスキーマ生成やマイグレーション、テストの実行などのタスクもmiseを用いて管理することによって、未担当領域の実装内容であっても簡単に実行可能にしました。 mise.tomlの一部 [tools] bat = "latest" node = "latest" "npm:@anthropic-ai/claude-code" = "latest" "npm:difit" = "latest" "pipx:git+https://github.com/github/spec-kit.git" = "v0.0.64" "pipx:git+https://github.com/oraios/serena.git" = "latest" pnpm = "latest" [tasks.dev] description = "開発サーバーを起動" run = "pnpm run dev" [tasks.build] description = "本番用にアプリケーションをビルド" run = "pnpm run build" [tasks.start] description = "本番ビルドしたアプリケーションを起動" run = "pnpm run start"   Spec KitとClaude Codeを組み合わせた仕様駆動開発 仕様書に記述した要件を漏れなくコード化するため、実装忘れや仕様の解釈ミスが激減しました。 設計意図を正確に反映したコードが生成され、開発速度と品質を両立した開発が実現しました。 事前にclaude用のガードレールを用意し、担当領域の知識が少なくても安定して開発できるようにしました。 特に使用するUIコンポーネントやスタイリングに関する使用ライブラリを明示、使用方針を事前に用意することでフロントエンドのデザインを丸投げしても破綻せず最後まで走り抜けることができました。 Bedrock AgentCoreを使用したマルチエージェント構成 指示役(Orchestrator)と専門性があるサブエージェントに分ける構成にしました。 これにより他のサブエージェントに影響を与えずに、サブエージェントの追加・修正が可能となります。 3日間で、Orchestratorエージェントとタスクを細分化するcreate_taskエージェントを作成しました。 バックエンドでテストまで実装した事による最終統合の難易度低減 バックエンド側で想定する動作や役割を事前に詰め、型定義、モックを作成したことでフロントエンド統合時の競合を比較的減らす事ができました。 それでも型の定義共有が遅れたのと、想定が甘かったことでメンバ名の食い違いや状態を表すenumの表記ゆれなどの問題が発生しました。 実装できなかった機能 3日間で実装できなかった機能は以下のとおりです。 それぞれのタスクで具体的な手順や参考となる情報も提示してくれる ユーザのライフスタイルからAIが今日どのくらいタスクをこなせば良いかを提案する AIが今日やるべきタスクやユーザの動向に合わせたタスクを通知する 当初はAIが自発的にユーザに通知したり、タスクを考えたりする機能を実装する予定をしていました。そのため、自立型のAIエージェントをアプリケーションに組み込むことを目標としていました。しかしながら、時間の都合によりタスク分解の機能しか実装できませんでした。 成長したこと・学んだこと 今回の開発合宿を通して、私たちは多くのことを学び、成長することができました。 特に、AIコーディングエージェントに対する明確な仕様情報の伝達方法について深く理解しました。手戻りを防止するための情報伝達は、人間に対するものと同等かそれ以上に重要であることを実感しました。詳細な実装には細かい指示や方針が必要で、最終的には使用者自身のツールやフレームワークへの知識が問われます。 一方で、メンバー間の認識や事前知識の違いによって指示内容にブレが生じ、実装内容の食い違いにつながる場面もありました。本来であれば、このような問題はレビューによって発見・修正されますが、今回は完全に分業を行っており、レビューを実施していませんでした。 これらの経験を通して、以下のような学びと成長を得ることができました。 上流工程のスキル向上：設計段階での詳細な仕様定義の重要性を理解しました。 新規ツール・フレームワークへの理解：最新技術を活用するための知識習得をしました。 事前準備の重要性：環境構築や型定義の共有など、開発前の準備が開発効率に大きく影響することを学びました。 レビューの重要性：分業体制においても、相互レビューによる品質担保が不可欠であることを再認識しました。 おわりに 今回の合宿で私たちは、新規技術・手法を取り入れながら、AIエージェントを主軸としたアプリを3日間で開発しました。 仕様駆動開発による開発効率の向上や柔軟性のあるマルチエージェント構成など、速度と品質を両立した開発ができたと感じでいます。 一方で、事前準備やレビューの不足によって環境構築や型の不一致修正といった作業が発生し、工数を多く取られてしまう場面も見られました。 技術的な収穫はもちろん、日々の業務に対するモチベーション向上にも繋がりました。各々が得られた成長と課題を糧にし、今後の業務に取り組んでいきます。  

普段、何気なく使っているインターネットやWEBサービス。その要となるのが、通信端末や各種サーバーの間をつなぎ、情報の伝送を行うネットワークです。ニフティにも専門のネットワークチームがあり、データセンターやニフティ従業員が働くオフィスのネットワーク設計・構築・運用などを担っています。 「つながるのが当たり前」で、不具合があれば速やかな対応が求められる責任の重い業務。担当者たちはどんな意識で、また、どんなやりがいを持って仕事をしているのでしょうか？ネットワークチームのメンバーに話を聞きました。 自己紹介 Mさん（チームリーダー） 2008年2月入社。メイン業務はデータセンターとオフィスのネットワーク設計・構築・運用。趣味は音楽（聴くほう）。最近、「Nintendo Switch 2」の抽選販売に当選したことでゲーム熱が再燃。   Tさん 2024年2月入社。メイン業務はデータセンターとオフィスのネットワーク設計・構築・運用。趣味はスポーツ観戦（サッカー、プロレス、格闘技）と読書。   Sさん 2023年4月入社、メイン業務はデータセンターとオフィスのネットワーク設計・構築・運用。趣味は秋葉原のリサイクルショップ（ジャンク屋）でのお宝さがし。ラーメン屋巡り。 ミッションは「ネットワークを途切れさせず、快適に使える」ようにすること みなさんはニフティの「ネットワークチーム」のメンバーということですが、具体的な業務内容を教えてください。 Mさん 私たちのチームでは、ニフティのサービスの要となる「ネットワーク」にまつわる仕事を行っています。メインの業務は、ニフティのサービスを支えるデータセンターと、社員が勤務する新宿オフィスのネットワークを設計・構築・管理することです。 具体的に言うと、データセンターに関しては、各システムサーバー間の通信やクラウドへの通信などが滞りなく行えて、トラブルを起こせず使える状態にすること。新宿オフィスのほうは、ニフティの社員が業務を行うための無線LANをはじめとするネットワークが途絶えたりせず、快適に使えるようにすることをミッションとしています。 ニフティのサービスを提供するうえでも、従業員がオフィスで業務を行ううえでも、欠かせないチームですね。 Mさん ネットワークは24時間365日、「つながって当たり前」と思われているところがありますし、我々もそうあるべきだと考えています。また、つながるだけでなく、いかに滞りなく使える環境を提供できるかが重要。仮に機器に何かしらの問題が生じたとしても、システムのサーバー間の通信には影響が出ない仕組みを構築したり、日々の運用のなかで問題がありそうな箇所を見つけて手直しをしたりと、大きなトラブルに発展しないよう努めなくてはいけません。 Tさん とはいえ、それだけ万全に対策していてもトラブルが発生する可能性はゼロではありません。ですから、ネットワーク関係で仮に問題が起きた場合も迅速に解決できる体制を整えています。 たとえば、お客様が利用するサービスに影響を与えるトラブルであれば1秒でも早い復旧に努めますし、社内の通信環境のちょっとした不具合ならしっかりと原因を究明して根本的な解決をはかるなど、内容によって臨機応変に対応しています。 「つながる・つながらない」分かりやすく結果が出るのが面白い Mさんはニフティに入社した当初から、長くネットワークの業務に携わっているそうですね。 Mさん そうですね。この仕事に携わる以前からネットワーク関連の技術について自分で調べるなど、もともと興味を持っていました。ネットワーク業務の面白さはいくつもありますが、まずはトラフィックで色んなことが可視化されること。ちゃんと使われていることが分かったり、問題が解決してつながるようになったことを実感できたりと、やった仕事の手応えを感じられる点が魅力です。 また、たとえばネットワークを入れ替える際には過去にトラブルになった点をふまえ、それを解決できる環境や設計を考えます。その結果、これまで抱えていた課題を解消し、快適に通信できるようになった時は大きな達成感を覚えますね。 Tさんはネットワークの業務のどんなところに面白さや達成感を覚えますか？ Tさん Mさんのお話と少し被りますが、ネットワークは「つながる・つながらない」という分かりやすい結果が出る仕事なので、色々と試行錯誤をしたことでつながった時は喜びを感じます。私はMさんと違い、当初はそこまでネットワークに強い関心があったわけではありませんが、やっていくうちに面白さを感じ、ネットワークエンジニアとして頑張っていこうと思うようになりました。 先ほどMさんもおっしゃっていましたが、ネットワークはいつでも「つながって当たり前」と思っている人が多く、みなさんのご苦労がなかなか伝わらない辛さもあるのではないですか？ Tさん でも、その「当たり前を作る」というところにやりがいを感じますし、そこが私たちの仕事の頑張りどころかなと思います。 なるほど。Sさんは、いかがでしょうか？ Sさん 現在、私はネットワーク機器をリプレイスする業務を担当しています。たとえば、何年も前に導入した機器を見直さないまま使い続けていると不具合が出てきたり、メーカーのサポートがなくなってしまったりといった問題が生じます。それを回避するために、まあまあの頻度で後継機器にリプレイスする必要があるのですが、個人的には好きな仕事で楽しくやらせてもらっています。ベンダーさん経由で最新の機器に触れられるのも、どの機器をどう組みわせていくかといったコンフィグを組み立てるのも楽しいですし、実際に導入して想定通りに動いた時は達成感がありますね。 1年半を要したデータセンターの引っ越しプロジェクト これまでに携わってきたなかで、特に印象的なプロジェクトを教えてください。 Mさん 記憶に新しいところでいうと、昨年からスタートしたデータセンターの引っ越しですね。もともと都内の別の場所にあったデータセンターを、より新宿オフィスに近いエリアへ移すプロジェクトで、最終的に引っ越しが完了するまで1年半ほどかかりました。もちろん引っ越しの間も新宿オフィスは稼働していますので、通信を途絶えさせるわけにはいきません。機器やシステムを少しずつ移行しながら、業務やサービスに支障が出ないようネットワークを切り替える必要があったんです。うまく切り替えるためにはどんな設計が望ましいかというところから、非常に頭を悩ませました。 トラブルなく、無事に移行は完了しましたか？ Mさん 幸い、大きなトラブルはありませんでした。ただ、通信断を完全にゼロにすることは難しく、多少は発生してしまいます。そこで、社内への事前共有で「移行作業を行う時間帯は、通信が少し不安定になるかもしれません」という告知をしたり、各部署へのアンケートで「通信断があると困る時間帯」をヒヤリングしてそこは避けたりと、コミュニケーションを密に行い、なるべく迷惑をかけない方法を模索しました。そうなると、移行作業ができる時間帯が夜間しかなくなるなど、色んな意味でハードなプロジェクトでしたね。 Sさんは新卒で入社し3年目ということですが、これまでで最も印象深い仕事は何ですか？ Sさん 去年の後半から今年にかけて、新宿オフィスのネットワークをリプレイスするプロジェクトがあり、私が機器の入れ替えを担当しました。オフィス全体の機器を入れ替えるという大規模なものでしたので、台数もとにかく多いですし、かかる金額も非常に大きくなります。そうなると当然、「なぜ、それだけの入れ替えが必要なのか」について、会社を納得させられるだけの説明を求められるわけです。 正直かなり苦労しましたが、リプレイス後は明らかに通信状況が良くなり、社員からの改善要望や問い合わせも減りました。分かりやすい結果が出た手応えもあって、印象深い仕事の一つです。 導入する機器を選ぶだけでなく、そうした交渉ごとも自身でやるんですね。技術のことだけでなくコストパフォーマンスも考慮しなければいけないとなると、なかなか大変そうです。 Sさん ネットワークを作るには機器の購入だけでなく、ベンダーさんにお願いする作業の費用も発生します。かかるコストについて、しっかりロジックを立てて説明できなければ普通にNGが出てしまう。そこはいつも骨が折れますね。 ただ、個人的には良い経験ができていると感じます。チームによっては稟議書を全く書く機会がないケースもあるようですが、私の場合は技術以外にも幅広いスキルを身につけることができていると思います。 ネットワークの仕事は「注目されないこと」が大事 最新の機器や通信技術についてのキャッチアップはもちろん、コスト意識を持つこと、折衝能力を磨くことも欠かせません。ネットワークと一口に言っても、身につけなくてはいけない知識やスキルがかなり多いように感じます。 Tさん そうですね。この仕事には幅広い知識とスキルもそうですし、柔軟な発想力も求められます。それこそトラブル一つとっても、その要因を突き止めるためには頭を柔らかくして、あらゆる可能性を考慮する必要があるんです。 たとえば、新しい機器を入れて、正しい設定や使い方をしているのに不具合が度々起こるとします。あらゆることを試しても解消せず、ベンダーさんに問い合わせてみたら、実は機器側のバグが原因だったなんてこともある。そういう場合は新しいOSにアップデートしたら、案外あっさり解消することもあって、本当にどこに落とし穴があるか分かりません。 もしかしたら、ケーブルがしっかり挿さっていないだけかもしれません。 Tさん 実際、そういうこともよくあります。通信って本当にちょっとしたことでうまくいかなくなるものなので、固定観念にとらわれてはいけないなと。ただ、そこが難しさでもあり、面白さでもあるのかなと思いますね。 普段、インターネットを使う時には意識していませんでしたが、安定した通信環境はみなさんのようなエキスパートの方々の、表に出ない努力によって成り立っているのだと実感しました。 Mさん 繰り返しになりますが、ネットワークはつながることが当たり前であって、我々の仕事がクローズアップされるのは「つながらない時」なんです。だからこそ、いかに誰からも注目されることなく、滞りなく通信を届けるか。それが我々の仕事の肝だと考えています。 後編に続きます！ 今回はニフティのネットワークチームのインタビュー（前編）の様子をお届けしました。続きは後日公開予定の後編の記事をご覧ください。 このインタビューに関する求人情報 /ブログ記事 ニフティ株式会社 求人情報

(Connpass)Maker Faire Tokyo 2025 After イベント概要 NIFTY Tech Talkは、ニフティ株式会社の社員が主催するトークイベントです。 本イベントでは、ニフティグループの社員が業務を通じて学んだことを発信しています！ テーマ Maker Faire Tokyo After NIFTY Tech Talk #25 2025年10月4日、5日に Maker Faire Tokyo 2025 (以下MFT)が開催され、ニフティがブース出展しました。 このイベントでは、展示物の製作者に展示物の裏話や制作秘話などを語ってもらいます。 当日の雰囲気はこちらから – https://engineering.nifty.co.jp/blog/35365 – https://internet.watch.impress.co.jp/docs/news/2053422.html 開催概要 日程：11月11日（火）12:00〜13:00 YouTube Liveで配信 こんな方におすすめ 当日MFTに参加して、展示物の裏話に興味がある方 MFTには参加していないが、展示物に興味がある方 ITエンジニアの「メイカー活動」「部活動」に興味がある方 ISPの会社がなぜカードゲームを作ったのか気になる方 タイムテーブル 時間 コンテンツ 12:00 – 12:10 オープニング 12:10 – 12:30 LT1: なぜISPがメイカーイベントに出展したのか(仮) 12:30 – 12:50 対談1: 展示したボードゲームについて(仮) 12:50 – 13:00 クロージング 登壇者プロフィール 大村 柊人（ファシリテーター） ニフティ株式会社　基幹システムグループ/サービスインフラチーム 会員基盤の運用をしています。 好きなものはゲームとemacs。 藤川 宏之（登壇者） ニフティ株式会社　サービスシステムグループ / 第一開発チーム レガシーなシステムの運用・改善を行っています。 botじゃないよdaemonだよっ 西野 香織（登壇者） ニフティ株式会社 サービスシステムグループ/第２開発チーム 2019年からスクラムマスターとして、アプリ・WEBサービスに携わる。 スクラムエヴァンジェリストという強そうな名前でスクラムの導入を支援しています。 社内のブカツ制度では、ボードゲーム部 部長をしています。 増田 侑香里（登壇者） ニフティ株式会社　技術基盤グループ　SRE/QAチーム 運用作業が社内SRE勉強会を通して改善でき、SREに興味を持ちました。 SREメンバー募集中です！ 西根 千晴（登壇者） ニフティ株式会社 サービスシステムグループ 第二開発チーム ニフティポイントクラブの開発をしています。 許されるなら無限にボードゲームをしていたいです！ ニフティグループでは一緒に働く仲間を募集中です 新卒採用、キャリア採用を実施しています。ぜひ リクルートサイト をご覧ください。 ニフティエンジニアが業務で学んだことやイベント情報を エンジニアブログ にて発信しています！ ニフティエンジニアの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/ ) で公開されています。

(Connpass)Maker Faire Tokyo 2025 After イベント概要 NIFTY Tech Talkは、ニフティ株式会社の社員が主催するトークイベントです。 本イベントでは、ニフティグループの社員が業務を通じて学んだことを発信しています！ テーマ Maker Faire Tokyo After NIFTY Tech Talk #25 2025年10月4日、5日に Maker Faire Tokyo 2025 (以下MFT)が開催され、ニフティがブース出展しました。 このイベントでは、展示物の製作者に展示物の裏話や制作秘話などを語ってもらいます。 当日の雰囲気はこちらから – https://engineering.nifty.co.jp/blog/35365 – https://internet.watch.impress.co.jp/docs/news/2053422.html 開催概要 日程：11月11日（火）12:00〜13:00 YouTube Liveで配信 こんな方におすすめ 当日MFTに参加して、展示物の裏話に興味がある方 MFTには参加していないが、展示物に興味がある方 ITエンジニアの「メイカー活動」「部活動」に興味がある方 ISPの会社がなぜカードゲームを作ったのか気になる方 タイムテーブル 時間 コンテンツ 12:00 – 12:10 オープニング 12:10 – 12:30 LT1: なぜISPがメイカーイベントに出展したのか(仮) 12:30 – 12:50 対談1: 展示したボードゲームについて(仮) 12:50 – 13:00 クロージング 登壇者プロフィール 大村 柊人（ファシリテーター） ニフティ株式会社　基幹システムグループ/サービスインフラチーム 会員基盤の運用をしています。 好きなものはゲームとemacs。 藤川 宏之（登壇者） ニフティ株式会社　サービスシステムグループ / 第一開発チーム レガシーなシステムの運用・改善を行っています。 botじゃないよdaemonだよっ 西野 香織（登壇者） ニフティ株式会社 サービスシステムグループ/第２開発チーム 2019年からスクラムマスターとして、アプリ・WEBサービスに携わる。 スクラムエヴァンジェリストという強そうな名前でスクラムの導入を支援しています。 社内のブカツ制度では、ボードゲーム部 部長をしています。 増田 侑香里（登壇者） ニフティ株式会社　技術基盤グループ　SRE/QAチーム 運用作業が社内SRE勉強会を通して改善でき、SREに興味を持ちました。 SREメンバー募集中です！ 西根 千晴（登壇者） ニフティ株式会社 サービスシステムグループ 第二開発チーム ニフティポイントクラブの開発をしています。 許されるなら無限にボードゲームをしていたいです！ ニフティグループでは一緒に働く仲間を募集中です 新卒採用、キャリア採用を実施しています。ぜひ リクルートサイト をご覧ください。 ニフティエンジニアが業務で学んだことやイベント情報を エンジニアブログ にて発信しています！ ニフティエンジニアの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/ ) で公開されています。