概要 こんにちは。ニフティの山田です。 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/ ) で公開されています。

はじめに window.alert() や window.confirm() など、ブラウザ組み込みのモーダルは使用を避けるべきです。 意外と知られてなさそうだったので共有させていただきます。 なぜなのか 機能しない可能性が高いためです。 モーダルはユーザの操作を強制的にブロックします。このようにユーザの意思に反して特定の操作を行わせるのはUX上よくないとされています。 これはブラウザに限ったことではなく、Androidの標準デザインシステムであるMaterial Designの ガイドライン においても、モーダル(ダイアログ)は優先度の高いメッセージにのみ使用すべきと規定されています。 また window.alert() はいわゆる「無限アラート」などのいたずらにも容易に使用できてしまいます。 このため、現代のほとんどのブラウザでは複数回モーダルダイアログが表示された場合、無視できるようにするオプションを挿入するようになっています。 1回目 2回目以降 ここでオプションにチェックを入れてしまうと、当該ドメインのサイトでは window.alert() などのモーダルが すべて表示されなくなり、強制キャンセル扱いになります 。 window.confirm() の場合は即falseが返るようになるため、ユーザからすると何回やっても処理が進まない、という状態になります。 厄介なのはユーザからすると「次から確認をスキップして進めるんだな」というように見える点です。 実際はその逆で、すべてキャンセルされてしまいます。 どうすればよいか まずはそのモーダルが本当に必要なのか考えます。 参考→ https://alistapart.com/article/neveruseawarning/ そのうえで必要であると判断した場合、取りうる道は主に2種類あります。 いずれもブラウザによるダイアログではなく、HTML要素としてレンダリングする方法です。 <dialog>要素を使う HTMLではダイアログ用にdialog要素が定義されているため、これを使うことでダイアログが表示できます。 参考→ https://developer.mozilla.org/ja/docs/Web/HTML/Reference/Elements/dialog 表示にはJavaScriptを使用し、モーダル(ユーザ操作ブロック)と非モーダル(ブロックしない)の両方の用途で使用できます。 HTMLDialogElement.showModal() : モーダル表示 HTMLDialogElement.show() : 非モーダル表示 ただし比較的新しい要素のため、古いブラウザでは使用できません。ブラウザ互換性が重要である場合は採用できない可能性があります。 IE11は非対応で、Safariも15.4以上を必要とします。 CSSで自前作成 dialog要素が使えない場合には、CSSの position: absolute や position: fixed を使用して要素をオーバーレイ表示させます。 ただし背面の要素を操作できなくするには ダイアログ外をクリック不可にする スクロールの無効化 タブ等によるフォーカス移動の無効化 などを実装する必要があり、実装工数が大きいです。 コンポーネントライブラリを利用している場合は実装済みのものを利用できることもあります。 ex) Chakra UIの Dialogコンポーネント おわりに window.alert() などのモーダルは古くから使われてきたAPIですが、現在においては無効化される可能性が高いため、使用を避けましょう。 UX上悪影響を与えるものでもあるため、真にモーダルが必要なのかを見極めたうえで、それでも必要性が認められる場合にのみ、適切な実装を選択するようにしましょう。

はじめに こんにちは。ニフティの山田です。 10/1にReact 19.2がリリースされました。 React 19.2 – React 最近のReactはServer Componentに関わる変更が多いのですが、今回はそれ以外にもActivity・useEffectEventという2種のAPIが追加になっていますので、本記事で解説しようとおもいます。 Activity コンポーネント出し分けの問題 従来、コンポーネントの表示・非表示ををフラグなどの状態に応じて出し分けるには以下の方法がありましたが、いずれも問題がありました。 コンポーネントごとアンマウントする方法 { enabled && <MyComponent /> } 最も標準的で、最初に考えつく方法かと思います。大抵の場合はこれで良かったのですが、以下の問題がありました。 再レンダリングが重い コンポーネントごと消えてしまうため、再度表示する際に1からレンダリングする必要があり、計算量が重い stateが消失する stateはコンポーネントに紐づくため、アンマウントされると消えてしまう フォームなどがあった場合、入力されたデータは消えることになる 状態管理ライブラリなどでglobal stateとして持てば解決はできるものの、局所状態の管理としては過剰 CSSで非表示にする方法 <MyComponent style={enabled ? undefined : { display: 'none' }}> アンマウントされるのがだめなら、要素は残したままCSSで消せばいいということになりますが、こちらも問題があります。 useEffectが走ってしまう データロード・通知などをuseEffectで行っていた場合、実行されてしまう Activityの動作 以上を解決できるものとして導入されたのがActivityです。childrenをとるコンポーネントであり、以下のように使います。 <Activity mode={enabled ? 'visible' : 'hidden'}> <MyComponent /> </Activity> modeの値に応じてchildrenコンポーネントの表示・非表示が決まります。 modeは現時点で2種類あり、以下のような動作となります(将来的に追加の可能性もあるようです)。 visible childrenコンポーネントが表示される useEffectなども動作する hidden childrenコンポーネントは非表示となる useEffectは停止する バックグラウンドで優先度低でレンダリングされる これにより、非表示時に 裏側でレンダリングが可能であり stateは維持しつつ effectは動作させない という動作が可能となりました。 必要があって生まれた機能ではありますが、Reactの「ロジックが(特別な記法なく)JavaScriptとして読める」という純粋性からは遠ざかる変更でもあります Vue界隈からは「これ v-if では?」と言われていたりもするようです useEffectEvent useEffectでイベントを発火させる際の課題 useEffectでイベントトリガーを仕込む場合、従来は課題がありました。 function ChatRoom({ roomId, theme }) { useEffect(() => { const connection = createConnection(serverUrl, roomId); connection.on('connected', () => { showNotification('Connected!', theme); }); connection.connect(); return () => { connection.disconnect() }; }, [roomId, theme]); ... } 以上は React公式ブログ の例を用いています。 これはコンポーネントがマウントされるとWebSocket的なものでチャットに繋がるサンプルですが、以下の問題があります。 依存配列にthemeが含まれているので、themeを変えただけでuseEffectが走り、再接続が実行されてしまう themeを依存配列から外すと、イベントハンドラが更新されず、通知のthemeが更新されなくなる このように、最新のprops・stateを参照し続けたいのですが、useEffectを再実行したくはない、という場合の対処が困難でした。 useEffectEventの動作 function ChatRoom({ roomId, theme }) { const onConnected = useEffectEvent(() => { showNotification('Connected!', theme); }); useEffect(() => { const connection = createConnection(serverUrl, roomId); connection.on('connected', () => { onConnected(); }); connection.connect(); return () => connection.disconnect(); }, [roomId]); ... } useEffectEventは新しく追加されたフックであり、イベントハンドラをラップする形で使用します。 useEffectEventを通すことで イベントハンドラ実行時にはuseEffectEventが常に最新のprops・stateを参照し useEffectの依存配列に含めなくてよい という動作が実現できるようになりました。 本フックはExperimental機能として以前から存在していましたが、React 19.2でstableになった形となります おわりに 本記事では、Reactの基本的なAPIとして追加されたActivity・useEffectEventの2種について解説しました。 既存コードにも無理なく導入できるものですので、今まで困っていたような方は導入を検討してみてはいかがでしょうか。

こんにちは、ニフティの佐藤と後藤です！ ニフティでは毎年、エンジニア定例という新卒1年目エンジニア向けの開発研修を行っています。 そして開発研修の集大成として、ハッカソン合宿を実施してきました！ 私たちも運営として合宿に参加してきたので、その様子を公開いたします！ また、以下のブログで今年度の講義内容についても公開しているので、気になる方はぜひ覗いてみてください！ ニフティ株式会社 エンジニア新人研修の内容を公開します | 2025年度版 合宿概要 目的 座学で学んだ技術を 実践 することで知識を定着させる 2泊3日というまとまった時間で 集中したアウトプット を出す経験をする 既存システムのエンハンスではなく、 0からシステムを作る力 を身につける 個人開発と チーム開発 の違いを学ぶ 自身の限界を早めに体験・実感 し、残りのOJT期間を過ごしてもらい成長に繋げる スケジュール 1日目 2025/10/15（水） 11:30 三浦海岸駅集合、送迎バス搭乗　 12:00 – 13:00 昼食 13:00 – 19:00 開発 19:00 – 21:00 懇親会 21:00 – 自由時間（開発除く） 2日目 2025/10/16（木） 06:45 – 09:00 朝食 09:00 – 12:00 開発 12:00 – 13:00 昼食 13:00 – 19:00 開発 19:00 – 20:00 夕食 20:00 – 自由（開発や入浴など）　　　　　 3 日目 2025/10/17（金） 06:45 – 09:00 朝食 09:00 – 12:00 開発 12:00 – 13:00 昼食 13:00 – 14:00 発表リハーサル 14:00 – 16:00 開発 16:00 – 16:45 現地から成果報告会（全社配信） 16:45 – 17:00 撤収作業 17:00 – 解散 場所 マホロバ・マインズ三浦 京急久里浜線 三浦海岸駅から徒歩7分（無料送迎バスあり） 合宿の様子 1日目 2025/10/15(水) 最寄りの三浦海岸駅に集合し、送迎バスを利用してマホロバ・マインズ三浦に到着！ 徒歩7分の距離ですが、道中かなり上り坂が多めだったので、送迎バスを利用して正解でした。 会議室に荷物を置いて、全員でホテルの昼食会場へ。 マグロのカマ焼き定食 マグロが有名な三崎漁港の近くに位置しているため、マグロは特に美味しかったです。 さて、お腹を満たしたところで、会議室のレイアウトを変えて、開発スタートです！ Before After 会議室には65インチモニターや問題なく作業ができるWi-Fi、マイク機材、延長コードが備わっており、別途有料で40インチモニターやホワイトボードもいくつかお借りしました。 開発するにはとても良い環境でした。 各チーム、事前のアイディアソンで考えてきたアイディアを元に作業を進めます。 合宿が始まるまでは開発禁止！のルールなので、全員が環境構築から始めます。 今回の合宿では全員がClaude Codeを使えるようにしたので、AIを使いながら実装を進めていきます。 あっという間に19時になり、夕食の時間がやってきました。懇親会ではお酒が飲めるので、本日の開発は終了となります。 大変美味しいお料理でした。 宿泊部屋は3人1部屋で、マンションの1部屋くらいのかなり広いお部屋でした。 リビング 寝室 施設には温泉も備わっていたので、各自入浴を済ませ、1日目終了です。 2日目 2025/10/16(木) 朝食を各自済ませ、9時から開発スタートです。この日は朝から晩まで開発です！ 各チームともGitHub ProjectsやGitHub Actions、AWSなどを駆使して開発を進めていきます。 今年は本格的にAIを使ってもOKという体制にしたので、例年よりも先輩社員への質問が少なく、どのチームも開発スピードが爆速です。 2日目は、まだ開発したいチームは残って開発をするというスタイルで、皆さん明日の発表に向けて、夜遅くまで作業していました。 3日目 2025/10/17(金) 最終日です！！！16時からの成果報告会に向けてラストスパートです。 運営も配信の準備を進めていきます。 配信スタート！ 全社配信をしており、50名近くの方に参加していただけました。 Slackに実況チャンネルを設けて、配信を視聴していただいている皆さんからの反応や質問なども、リアルタイムで見れるようにしています。 開発合宿に参加していたメンバーだけではなく、新人のトレーナーをしていた先輩社員や所属しているチームのマネージャー、人事や企画部門の社員など、多くの方に合宿の成果を見ていただける素晴らしい機会です。 では早速発表を見ていきましょう。 （本ブログ内では概要のみの紹介となります。開発物の詳細については、後日投稿予定の各チームのブログをご覧ください！） まずはチームAです。AIが冷蔵庫の食材からレシピを自動提案してくれるアプリケーション。 賞味期限が近い食材たちでレシピを考えてくれるのはとても助かる〜 次にチームBの発表。AIエージェントを用いた自立型のタスク管理アプリケーション。 数日前に一般提供が開始されたAmazon Bedrock AgentCoreの組み込みに挑戦し、無事開発し終えました。 最後はチームCです。公共交通機関の混雑率を共有できるアプリケーション。 路線図をヒートマップで視覚化することで、一目で混雑状況がわかるのはありがたいですね。 多くの方にご参加いただき、素晴らしい成果報告が実施できました！ ご参加いただいた皆様、ありがとうございました！ 終わりに 今年のハッカソン合宿は、例年と比較して、Claude Codeなど仕様検討やコーディングにて本格的にAIを使っても良い環境にしたため、高速かつ良質な成果物ばかりでした。来年は何か縛りを設けて難易度を上げようかなと思います。 使ったことのない技術なども積極的に取り入れ、運営の私たちも学びのあるハッカソン合宿となりました。 最後に、快適にハッカソン合宿ができる環境を提供してくださったマホロバ・マインズ三浦の皆さま、ありがとうございました！ 各チームの開発物のより詳細な仕様や開発秘話については、後日投稿予定の各チームのブログにてご覧になれます！お楽しみに！

はじめに おはようございます。IWS です。 先日 AWS のコストを眺めていた際、異様に CloudWatch のコストが高くなっていることに気づきました。さすがに少しは減らさないといけないと思い設定を見直し、結果 USD 500 ほど削減することができたのでその時のことを書き残そうと思います。 ちなみにこうなりました 7月：USD 906.26 → 9月：USD 156.19  CloudWatch が USD 750 減っています。（※うち USD 250 はログのインサイトの使用料のため、実際に削減した額は USD 500 ほどです） そもそも何でお金がかかってるのか Billing and Cost Management の請求書から CloudWatch の項目を確認してみると、どうやら $0.50 per GB of vended logs ingested in Standard log class for the first 10TB - US East (Northern Virginia) という項目で USD 533.84 ほどかかっているようです。 この項目は、標準クラスでのログ取り込みにかかっているコストの項目です。1,067.672 GB 取り込んでおりこれだけのコストになっているようです。  調べるとどうやらここには WAF のログが大量に吐き出されているようでした。1ヶ月で約 1TB なのでそこそこの量ですね。 この項目を減らすことができれば Cloudwatch のコストを大きく下げることができそうです。 コストを抑える手段 このコストを抑える手段としては ロググループを標準クラスから低頻度アクセスクラスやあるいは S3 に変更する 取り込むログの量自体を減らす の2通りがあると思います。 前者は 1GB あたりのログの取り込みなどにかかるコスト自体を抑える方法、後者はログ自体を減らすことでコストを抑える方法です。 ロググループを低頻度アクセスクラスや S3 に変更する S3 のストレージクラスのように何種類もあるわけではなく「標準」と「低頻度アクセス」の2種類だけですが、 CloudWatch Logs のロググループにも実はクラスがあります。 たとえば、低頻度アクセスでは、一部機能を使うことができない代わりにログの取り込みにかかるコストを標準の半分に抑えることができます。 代わりに、使用できなくなる機能としてサブスクリプションフィルターやメトリクスフィルターなどがありますが、検索程度であればログのインサイトで行うことができるため、必要なときにとりあえずログの調査ができればいいというような場合は低頻度アクセスにしてしまうことでコストを抑えることができます。 アクセス頻度の低いログ用の新しい Amazon CloudWatch ログクラスを割引価格で提供   Vended Logs 最初の 10 TB/月 の料金 東京 バージニア北部 標準 USD 0.76/GB USD 0.50/GB 低頻度アクセス USD 0.38/GB USD 0.25/GB S3 標準 USD 0.38/GB USD 0.25/GB https://aws.amazon.com/jp/cloudwatch/pricing/ 今までは WAF のログを CloudWatch Logs の標準クラスに吐き出していました。これを低頻度アクセスへと変更することでコスト削減をします。 今回は、ロググループを引き続き使用しますが、S3 に保存しておきクラスを適切に変えることでより多く削減できると思います。   ロググループのクラスは、作成後に標準から低頻度アクセスに変更する事はできず新規でロググループを作成する必要がある点はご注意ください。 新規で低頻度アクセスクラスのロググループを作成し、WAF の Logging destination を変更すればOKです。ロググループの名前の先頭に aws-waf-logs- とつけるのを忘れずに。 取り込むログの量自体を減らす 送られるログ自体を減らすことでコストを減らします。今回は WAF のログが原因なので、WAF から送られるログを減らすことができれば解決です。 WAF にはログのフィルター機能がありどの種類のログを残すか落とすかを設定することができます。 Filter logs から設定ができます。今回はおそらくログの大半を占めているであろう ALLOW のログを出さないように設定を変えてみました。   この設定をしてからはログの取り込み量が 7月：1,067.672 GB → 9月：1.071 GB にまで減りました。 低頻度クラスへの変更も含めて金額にすると USD 533.57 の削減です。 ↓ 最後に CloudWatch Logs と WAF を設定を少しだけいじり USD 500 の削減をしてみました！ ロググループを低頻度クラスに変更するだけでも取り込みコストを半分にすることができます。ぜひ皆さんのアカウントでも設定を確認して削減できる箇所がないか探してみてください！

はじめに こんにちは。 ニフティが出展した、Maker Faire Tokyo 2025のプロジェクト推進メンバーの寺島です。 Maker Faire Tokyo 2025については公式サイト： https://makezine.jp/event/mft2025/ をご確認ください。 先日のMaker Faire Tokyo 2025では沢山の方にニフティブースにお立ち寄りいただきました。 ありがとうございます。 今回は、ブースで展示を行っていたボードゲームの制作についてのリレーブログを実施します！！ 本記事に、ブログ記事のリンクをまとめていきますので、ぜひチェックしてください。 本企画は、ブログチーム管理ではなく有志によるリレーブログとなっています。 ブログチームの一員として嬉しい限りです。 はい、ブログチームの1人がいますが、寄稿のみでまったく無関係です！信じてくださいっ！！ なぜボードゲームを出展したのか 今回、ブースを出すにあたり、 ニフティキッズ の AIで絵本を作ろう！inメイカーフェアトウキョウ2025 の出店は決まっていました。 それ以外にもニフティの魅力をもっと伝えられないか、来ていただいた方にもっと楽しんでもらえる展示はないかを考えた時に、2つの案がでました。 そのうちの1つが今回出展したオリジナルボードゲーム制作です。 (もう一つは、 Wi-Fi速度低下についての実演展示 です) ボードゲームを制作することを選択した理由は、大きく4つあります。 社内にボードゲーム部があること 部の活動を通じて会社の雰囲気を知ってもらえると思ったこと 手に取れるものでインターネットについて考えてほしいと考えたこと ニフティらしさが伝えられること このゲームに込めた思いとしては、特にMaker Faire Tokyoに来場した 子どもたちにインターネット通信について興味を持ってもらう切っ掛けになって欲しい です。 今回「トラフィック」を題材にしていただきましたが、こう言った思いを上手に表現していただけたと思っています。 おわりに Maker Faire Tokyo 2025ボードゲーム制作リレーブログは以下のスケジュールで投稿予定です。 お楽しみに！ 投稿予定 執筆者 記事タイトル 2025年11月3日 篠崎さん Maker Faire Tokyo 2025 リレーブログ｜印刷所選定とものづくりの裏側 2025年11月4日 西根さん Maker Faire Tokyo 2025 リレーブログ｜ただのボードゲーム好きがオリジナルカードゲームのルールをデザインした話 2025年11月5日 西野さん Maker Faire Tokyo 2025 リレーブログ｜ISPがつくる、カードゲームのデザインができるまで 2025年11月6日 ムサシさん Maker Faire Tokyo 2025 リレーブログ｜イラスト制作・アグロ作画で可愛さ確定 2025年11月7日 西根さん Maker Faire Tokyo 2025 リレーブログ｜アイデアが”形”になるまでの物語。自作カードゲームの印刷からイベント出展までを振り返る

環境が整ったところで実際の検証に入りたいところですが、 ブログ前半 から時間が経ってしまったこともあり、今回は2025年9月末にリリースされたClaude 4.5 Sonnetを利用したいと思います。 Claude 4.5 Sonnet 利用にあたり、モデルアクセスの有効化とVScodeの設定を変更しておきます。 モデルアクセスの有効化 Cline + Amazon Bedrock Amazon Q Developer 検証の内容として、ブラックボックス化したシステムをAWSに移行することを想定、と行きたいところですが、ブラックボックス化したシステムを作るのは難しいので、今回はレガシーな処理、且ついくつか課題抱えているpythonファイル「legacy_process.py」を疑似的に作成し、この処理をAWS環境へ移行できるかを検証しました(ファイルの処理内容は後述のStep2を参照してください)。 legacy_process.py import csv import os import shutil from collections import defaultdict from datetime import datetime # --- レガシーなバッチ処理を想定したPythonスクリプト --- # NOTE: サーバーの固定ディレクトリパスに依存している INPUT_DIR = '/var/data/sales_reports/incoming' OUTPUT_DIR = '/var/data/sales_reports/processed' ARCHIVE_DIR = '/var/data/sales_reports/archive' def process_sales_csv(file_path, output_dir): """ 単一の売上CSVファイルを処理し、商品別の合計金額を集計して 新しいCSVファイルとして出力する。 """ print(f"Processing {file_path}...") product_sales = defaultdict(float) try: with open(file_path, mode='r', encoding='utf-8') as infile: reader = csv.DictReader(infile) for row in reader: try: product = row['product_name'] price = float(row['price']) quantity = int(row['quantity']) product_sales[product] += price * quantity except (KeyError, ValueError) as e: print(f"Skipping malformed row in {file_path}: {row} - Error: {e}") continue if not product_sales: print(f"No valid data found in {file_path}. Skipping output.") return # 出力ファイル名を作成 base_name = os.path.basename(file_path) output_filename = f"summary_{base_name}" output_filepath = os.path.join(output_dir, output_filename) with open(output_filepath, mode='w', encoding='utf-8', newline='') as outfile: writer = csv.writer(outfile) writer.writerow(['product_name', 'total_sales']) for product, total in product_sales.items(): writer.writerow([product, f"{total:.2f}"]) print(f"Successfully created summary file: {output_filepath}") except FileNotFoundError: print(f"Error: Input file not found at {file_path}") except Exception as e: print(f"An unexpected error occurred while processing {file_path}: {e}") def main(): """ 入力ディレクトリを監視し、CSVファイルがあれば処理を実行する。 """ print("--- Starting batch process ---") # 実行前にディレクトリが存在することを確認 for directory in [INPUT_DIR, OUTPUT_DIR, ARCHIVE_DIR]: os.makedirs(directory, exist_ok=True) try: files_to_process = [f for f in os.listdir(INPUT_DIR) if f.endswith('.csv')] if not files_to_process: print("No new files to process.") return for filename in files_to_process: file_path = os.path.join(INPUT_DIR, filename) process_sales_csv(file_path, OUTPUT_DIR) # 処理済みファイルをアーカイブディレクトリに移動 shutil.move(file_path, os.path.join(ARCHIVE_DIR, filename)) print(f"Archived {filename}") except Exception as e: print(f"An error occurred in the main process: {e}") finally: print("--- Batch process finished ---") if __name__ == '__main__': main() また、それぞれの構成についてなるべく同じ条件で動作・比較したいので、事前にAIへの指示書としてルールを定義し、それに従って実装してもらいます。ブログの趣旨と少しずれますが、こうすることでAIの振る舞いに一定のルールを設け、より公平に比較できると考えました。 そこでこの記事では、実際に以下の流れで検証を進めていきます。 AIエージェントに対して「要件定義」「設計」「実行計画」「実装」のルールを指定 AIによる開発プロセスの実行 それぞれの構成の比較と考察 Step 1: AIエージェントへのルールの指定 AIにプロジェクト専属の「プロフェッショナル」として振る舞ってもらうため、AIの思考方法から開発の進め方、プログラミング規約までを定義したルールを作成しました。 また、AIにいきなりコードを書かせるのではなく、まず「要件定義」から始め、「設計」「実行計画」「実装」と段階を踏んで開発を進めるプロセスを試してみました。 最近のAI開発ツール(kiroなど)でよく見られる、仕様から開発をスタートするアプローチです。本記事では、この手法を用いてClineとAmazon Qを比較検証します。 ちなみに、このルールはGeminiと対話しながら作成したものになります。このファイルをチーム内で共有することで、AIによるコーディングの精度向上にも役立つかと思います。 AIに与えたルール全体を見る # 最上位ルール - あなたは、レガシーシステムのAWS移行を専門とするプロフェッショナルです。 - 思考は英語、応答は日本語で行ってください。 - 私の意見に常に賛同するだけでなく、技術的なベストプラクティスとは異なる場合などは代替案や懸念点を提示してください。 - 「要件定義」「設計」「実行計画」「実装」の各フェーズは個別に実行し、一つのフェーズが完了するごとに、必ず承認を得てから次のステップに進んでください。 # プログラミングルール(Python版) - 全てのコードは原則として PEP 8 に準拠します。また、モジュールや関数には、その目的・引数・戻り値を説明する Docstring を記述します。 - 関数の引数と戻り値には型ヒント (`str`, `int`, `Dict`など) を付与し、コードの静的解析性と可読性を高めます。 - 基本的に関数やモジュールは一つの役割に限定し、肥大化させずに適切に分割します。 - 接続情報やAPIキーなどの設定値はコードに直接書かず、環境変数から読み込みます。 # 要件定義 1. 要求の分析と明確化 - 与えられた開発タスクを分析し、要求に曖昧な点や不足している情報があれば、憶測で進めずに、必ず具体的な質問を行い仕様を明確化します。 2. 要件リストの作成 - 明確化された仕様を元に、以下のシンプルなリストを作成します。 ```markdown # 要件リスト：[プロジェクト名] ## 1. プロジェクトの目的 このプロジェクトが解決する課題と、達成すべきゴールを記述する。 ## 2. 機能要件 システムが「何をしなければならないか」を明確なリスト形式で記述する。 ## 3. 完了の定義 このプロジェクトが「完了した」と見なされるための、客観的な基準をリスト形式で記述する。 ``` 3. 提示と承認 - 作成した要件リストを提示し、内容の合意と、次の「設計」フェーズに進むための承認を得てください。 # 設計 1. インプットの確認 - 承認済みの「要件リスト」の内容をインプットとし、そこに記載された全ての要件を満たすための技術的な設計を開始します。 2. 設計書の作成 - 要件を実装するための具体的な技術設計を行い、以下の構造で設計書を作成します。これは、続く「実行計画」「実装」フェーズの重要な設計図となります。 ```markdown # 設計書：[プロジェクト名] ## 1. アーキテクチャ概要 システム全体の構成要素と、それらの連携を表現するシンプルな図(Mermaid記法など)と、その説明を記述する。 ## 2. 技術スタック 開発に使用する主要な言語、ライブラリ、クラウドサービスなどをリスト形式で記述する。 ## 3. 主要コンポーネント設計 システムを構成する主要な部品(例：各Lambda関数、データベーステーブル)ごとに、その役割とインターフェース(入力・出力)を明確にする。 - コンポーネントA: - 役割: 〇〇を処理する。 - 入力: △△のデータ形式。 - 出力: ××のデータ形式。 - コンポーネントB: - 役割: ... ## 4. インフラ構成要素 Terraformなどで構築が必要な、具体的なクラウドリソース(例：S3バケット, IAMロール)をリストアップする。 ``` 3. 提示と承認 - 作成した設計書を提示し、技術的なアプローチや実現性に問題がないか確認を求めます。そして、次の「実行計画」フェーズに進むための承認を得てください。 # 実行計画 1. 設計書からの作業抽出 - 承認済みの「設計書」をインプットとして、実装に必要なすべての作業項目を抜け漏れなく洗い出してください。 2. 作業の分割と具体化 - 洗い出した作業項目を、1つあたり数時間で完了できる程度の具体的な作業にまで分割します。分割した各作業には、担当者が迷わず取り組めるよう、明確な「完了条件」を設定してください。 3. 実装計画書の作成 - 分割した作業を、以下の構造で実装計画書としてまとめます。 ```markdown # 実装計画書：[プロジェクト名] ## 1. 準備フェーズ - 作業1: [具体的な作業内容] - 完了条件: [この作業が終わったと判断できる客観的な基準] - 作業2: [具体的な作業内容] - 完了条件: [この作業が終わったと判断できる客観的な基準] ## 2. 実装フェーズ - 作業3: [具体的な作業内容] - 完了条件: [この作業が終わったと判断できる客観的な基準] ## 3. テスト・仕上げフェーズ - 作業N: [具体的な作業内容] - 完了条件: [この作業が終わったと判断できる客観的な基準] ``` 4. 提示と承認 - 作成した実装計画書を提示し、内容の合意と、次の「実装」フェーズに進むための承認を得てください。 # 実装 - タスクの宣言と計画 - これから着手するタスク(例：「`Task-01: ファイル検証Lambdaの作成`」)を明確に宣言します。そして、そのタスクを完了させるための具体的な手順やアプローチを簡潔に提示してください。 - 思考プロセスの提示 - コードを生成する直前に、どのような考え(例：「S3イベントの構造を考慮し、エラー処理はこうする」など)に基づいて実装するのか、思考の要点を箇条書きで示してください。 - 自己検証と報告 - コードを生成した後、それが「設計書」や「プログラミングルール」に沿っているか自己検証します。タスクが完了したら、作成したファイル名や成果物の概要を明確に報告し、次の指示を待ってください。 Step 2: 開発プロセスの実行 前のステップで紹介した手順で、各環境に上記のルールを読み込ませ、移行対象の legacy_process.py を分析させるところからスタートします。 Cline + Bedrock 環境での手順 VSCodeで対象のプロジェクトを開き、 .clinerules ファイルを新規作成し、ルールの内容をコピーします Clineのチャットパネルを開き、以下のプロンプトを入力します。Clineは .clinerules を自動で認識します。 AWSへの移行を計画しています。Pythonスクリプト「legacy_process.py」を分析し、以下の3つの観点からその概要を分析し、説明してください。 - このコードが持つ、主要な役割や機能を説明してください。 - 処理が開始してから終了するまでの、具体的な処理の順序を説明してください。 - このコードは、どのようなデータを受け取り(入力)、最終的に何を出力または影響を与えるのか説明してください。 Amazon Q Developer 環境での手順 VSCodeで対象のプロジェクトを開き、 PROJECT_RULES.md ファイルを新規作成し、ルールの内容をコピーします Amazon Qのチャットパネルを開き、最初に以下のプロンプトを入力します。 あなたの指示は、このプロジェクトのルートにある PROJECT_RULES.md ファイルに定義されています。このドキュメントに定められたすべてのルールと手順に従って、今後の対話を行ってください。Pythonスクリプト「legacy_process.py」を分析し、以下の3つの観点からその概要を分析し、説明してください。 - このコードが持つ、主要な役割や機能を説明してください。 - 処理が開始してから終了するまでの、具体的な処理の順序を説明してください。 - このコードは、どのようなデータを受け取り(入力)、最終的に何を出力または影響を与えるのか説明してください。 どちらの構成においても最初の分析結果を提示した後、こちらが指示する前に、ルールに従って自律的に「要件定義」フェーズを開始し、移行の目的や要件を明確化するための質問を投げかけてきました。 Cline + Bedrock 環境 Amazon Q Developer 環境 質問への回答内容 移行の目的は「保守性・運用性の改善」とする。 このlegacy_process.pyスクリプトのみをAWSに移行する。 既存の処理ロジック(商品別売上集計)は変更しない。 特定のS3バケットにCSVファイルがアップロードされたことをトリガーに、自動で処理が開始されること。 バッチ処理は1時間に一度動いており、1回あたり1〜10ファイル程度が不定期に発生する。 1ファイルあたりの規模として平均で1,000行程度のデータ。 定期的なスケジュール実行ではなく、ファイル到着を即座に検知する。 処理の実行状況（開始、成功、失敗）は、後から追跡できるようCloudWatch Logsに記録されること。 処理が失敗した際には、Slackなどで通知が送信されること。 既存システムとの連携はしていない。 検証のため「セキュリティ要件」「予算やコストに関する制約」「移行の完了希望時期」は考慮しない。 その後は、AIの質問に答え「承認します、次に進んでください」と指示するだけで、「要件定義」→「設計」→「実装計画」→「実装」と、開発の上流工程から下流工程まで一通りの作業をこなしてくれました。 (どちらの環境も一部IAMポリシーの定義などに苦戦していましたが、詳細はここでは割愛します) Step 3: 2つの構成の比較と考察 両環境とも最終的にAWSへのデプロイまで完了しましたが、実際に試すとプロセスと成果物に少し違いがあることが分かりました。  1. UI/UX・対話の丁寧さ 個人的な感想になりますが、Clineは応答が丁寧で、思考プロセスを細かく説明してくれる印象でした。特に設計フェーズで提示されたMermaid形式のアーキテクチャ図がVSCode上でプレビュー表示され、見やすかったのが特徴的でした。 構成図(Cline + Amazon Bedrock) 一方、Amazon Q Developer はコードで表示されたので、手動で図に変換したものを載せておきます。 構成図(Amazon Q Developer) 構成図(Amazon Q Developer)手動で図に変換 2. 特徴的な機能(Clineの「Plan/Actモード」) どちらもルールに定義した通り、ステップバイステップで進めてくれましたが、Clineには、AIがまず行動計画(Plan)を提示し、ユーザーが承認すると実行(Act)に移る「Plan/Actモード」が搭載されております。 この点は今回のルールベースの開発フローとも相性が良く、AIによる次の処理を常に確認しながら開発を進めることができました。 3. 生成されたリソースの比較   両環境で最終的に作成されたAWSリソースには、アーキテクチャの違いが若干見られました。 プロジェクト構成 Cline + Amazon Bedrock 環境 ├── terraform/ # Terraformインフラコード │ ├── main.tf # メイン設定 │ ├── variables.tf # 変数定義 │ ├── outputs.tf # 出力値 │ └── versions.tf # バージョン設定 ├── lambda/ │ ├── sales_processor/ # メイン処理Lambda関数 │ │ ├── lambda_function.py │ │ ├── processor.py │ │ └── requirements.txt │ └── slack_notifier/ # Slack通知Lambda関数 │ ├── lambda_function.py │ └── requirements.txt ├── docs/ # ドキュメント └── legacy_process.py # 元のレガシースクリプト Amazon Q Developer 環境 ├── lambda/ │ └── sales_processor.py # Lambda関数コード ├── terraform/ │ ├── main.tf # プロバイダー設定 │ ├── variables.tf # 変数定義 │ ├── s3.tf # S3バケット設定 │ ├── lambda.tf # Lambda関数設定 │ ├── iam.tf # IAMロール・ポリシー │ ├── sns.tf # SNSトピック設定 │ └── cloudwatch.tf # CloudWatch Logs設定 ├── legacy_process.py # 元のレガシースクリプト └── README.md # READMEファイル リソースまとめ リソースタイプ Cline Amazon Q Developer 備考 S3バケット 3個 1個(プレフィックスで分離) Clineは個別バケット、Q Devは単一バケット Lambda関数 2個 1個 Clineはメイン処理とSlack通知を分離 IAMロール 2個 1個 Lambda関数数に対応 SNSトピック 1個 1個 同じ CloudWatch Logs グループ 2個 1個 Lambda関数数に対応 どちらが良いか？ Clineの構成は、Slack通知機能を別Lambdaとして分離しており、後々の修正や拡張がしやすそうだと感じました。また、S3バケットを機能ごと(入力用、出力用、アーカイブ用)に分けることで、それぞれに異なるライフサイクルポリシーやアクセス制御を柔軟に設定しやすくなっています。 一方、Amazon Q Developerの構成は、よりシンプルで管理対象のリソース数が少ないというメリットがあります。小規模なシステムや、迅速なプロトタイプ開発によっては、こちらのシンプルなアプローチの方が適している場面もありそうです。 個人的には、将来的な拡張性やメンテナンス性を考慮すると、Clineが提案したアーキテクチャの方が優れていると感じました。 4. コスト面での比較 Cline + Amazon Bedrock:   約10ドル弱 (今回のチャットでのやり取り) Amazon Q Developer:   Pro Tierのサブスクリプション費用 (月額$19/ユーザー ※2025年10月時点) Clineは使用量に応じた従量課金のため、今回のような短期的な検証には向いているかと思います。一方、Amazon Q Developerは定額制のため、継続的に開発を行うチームにとってはコスト管理がしやすいというメリットがあります。 Cline のような従量課金の場合はコスト面にも意識を向ける必要があり、精神的な負担もかかることから、コスト面では Amazon Q Developer の方が大きなアドバンテージがあると感じました。 ブラックボックスシステムの移行での使い分け Clineを選ぶべきケース： 仕様が不明で、AIと対話しながら要件を掘り起こす必要がある場合 複数の代替案を検討し、アーキテクチャ図を見ながら判断したい場合 Amazon Q Developerを選ぶべきケース： ある程度仕様が分かっており、実装を加速させたい場合 継続的に使用するため、コストを固定したい場合 実際の移行プロジェクトでは、両方を併用するのも有効です。例えば、初期の調査・設計フェーズはClineで丁寧に進め、実装フェーズはAmazon Q Developerでチーム全体が使う、といった使い分けが考えられます。 AI導入によるシステム品質の向上 今回の移行は、単に古いコードを新しい環境に移しただけではなく、AIを活用したことで、システム全体の品質が向上しました。 1. セキュリティと拡張性   TerraformによるIaC(Infrastructure as Code)でインフラがコード化され、Lambdaベースのサーバーレスアーキテクチャになったことで、システムの拡張性が向上しました。 ​2. 保守性(脱ブラックボックス) AIを使う大きなメリットは、仕様調査やドキュメント作成といった手間のかかる作業を一気に効率化できる点です。今回の検証でも、AIとの対話を通じて以下の設計図や計画書が自動的に生成されました。 ​ 設計図： Mermaid形式のアーキテクチャ図や、各コンポーネントの役割分担 ​ 実装計画書： 具体的な作業タスクと、それぞれの完了条件 ただし、仕様調査の工数を削減できる点は大きなメリットですが、本番環境の様な複雑な環境においても同様の効果が見込めるとは限らないため、あくまでたたき台として活用するのがよいかと思います。 今回の検証における工数について ​今回AIが行った「既存コードの分析」から「コード実装」、「ドキュメント作成」までの一連の作業を、もし人間がすべて手作業で行った場合、およそ3〜5営業日(約17〜38時間)程度の工数が見込まれます。 (個人のスキルに依存して変動するかと思いますので範囲での内訳になりますが、以下の想定です) ​ 分析・要件定義・設計・計画： 5〜12時間 ​ コード実装 (Lambda + Terraform)： 10〜20時間 ​デプロイと動作確認： 2〜4時間 ​今回の検証では、AIとの対話や試行錯誤を含めても、これらの作業を半日程度で完了させることができました。もちろん、これは単純な比較であり、AIが生成したコードのレビューには別途工数が必要ですが、開発の初期段階における時間短縮の効果は大きいと言えると思います。 3. 追加機能による運用性の向上 元のスクリプトは、エラーが発生してもコンソールにログを出力するだけでしたが、新しいアーキテクチャには、Amazon SNSを利用したエラー通知の仕組みが組み込まれています。これにより、処理が失敗した際には即座にアラートが送信され、これにより、問題が起きてもすぐに対応できます。 さいごに ​今回の検証を通して、AI開発支援ツールがレガシーシステムの移行やブラックボックスの解消に一定の効果を発揮してくれる可能性があると感じました。 AIは、システムの仕様調査やドキュメント作成の時間を大幅に短縮し、開発効率を加速する強力なツールとなり得ます。ただし、そのコードや成果物の妥当性や、品質を保証するには人間の最終判断が不可欠だと思います。 この記事が、同じようにレガシーシステムの移行で悩んでいる方の参考になれば幸いです。

ニフティの主力事業はインターネット回線を提供することですが、そのインターネットを快適かつ安全に使っていただくためのオプションサービスも充実しています。たとえば、ネット詐欺専用のセキュリティサービスや、有害な広告をブロックするスマートフォンアプリなど。既存のサービスに加え、インターネットユーザーのニーズをふまえた新規サービスの開発にも日々尽力しています。 これらの開発を手掛けるのが、オプションチーム。 前編 では日々の業務について、仕事の楽しさなどについてメンバーに語ってもらいました。後編ではニフティという会社の良いところ、各々が描く今後のキャリア、さらには「どんな人と一緒に働きたいか」について聞きました。 挑戦や新しい技術導入に対する障壁が低い みなさんが思う「ニフティの良いところ」を教えてください。 加藤さん 私は2つあって、1つ目は経験のないことでも本人がやりたいと言えばトライさせてもらえる風土があること。2つ目は、ビジネス側と開発側の垣根があまりなく、エンジニアが実際の開発だけでなく、ビジネスに近いところから関われることですね。特にオプションチームはサービスを立ち上げる初期段階から企画や営業と一緒にディスカッションをしたり、意見を言ったりできる場があって、そこは大きな魅力だと感じます。 ただ、そうなるとエンジニアにも技術だけでなく、ビジネスに関する知識が求められますね。 加藤さん そうですね。ミーティングの場では売上などの数字の話だったり、販売戦略に関する話だったり、かなり細かく突っ込んだ話が出ます。もちろん、エンジニアとして開発に集中したいという人もいますのでマストではないのですが、ある程度のことは分かっていたほうがやりやすいのは確かだと思います。 エンジニアとして技術を極めていくにしても、ビジネスの視点を持っておくに越したことはないというか、無駄にはならない気がします。 加藤さん そう思います。それに、本人がその気になれば、学ぶ機会も用意されています。つい最近も、エンジニア向けに「自分でサービスを創出するならどう考えるか？」みたいな勉強会がありましたし、企画と開発の距離が近いのでビジネスサイドの考え方を気軽に聞くこともできるんです。ビジネスに興味があるエンジニアにとっては恵まれた環境だと思います。 高田さん、三浦さんはいかがですか？ 高田さん 加藤さんと同じ答えになってしまいますが、やはり挑戦だとか、新しい技術を導入することに対しての障壁が低いのはニフティの良さであり強みだと思います。もちろん、新しいことをやるとなると調整が必要になったり、大変なことも多いのですが、それを支えてくれたり、受け入れてくれたりする人が多い気がしますね。ですから、新しいサービスに携わりたい人、触ったことのない技術に挑戦したい人にとっては、動きやすい環境ではないかなと。 三浦さん ニフティは、とにかくオープンな会社だと思います。上司との壁があるとか、隣の席の人と会話がないとか、そういう話は全く聞きませんから。私自身も席の対面に所属長がいて、左側に統括部長がいるのですが、何を気兼ねすることもなくオープンにコミュニケーションをとることができます。他部署の人間とコミュニケーションしたい時もわざわざメールでアポを取らず、パッと行って軽く要件を話したりできる。それはすごく良いところだと感じますね。 技術のスペシャリストかマネジメントか。 若手エンジニアが描くキャリアは？ みなさんの今後のキャリアの展望や、挑戦してみたいことを教えてください。 加藤さん 私はおそらく技術よりはコミュニケーション能力を評価されて入社できたと思っていて、業務知識や技術はまだまだ足りていないところがあると自覚しています。当面は、そのあたりをしっかりキャッチアップしていくので手一杯かなと思いますが、少しずつコミュニケーション能力を活かしてチームや会社の力になりたいですね。ビジネス側と開発側をうまくつなげる潤滑油になって、新しいサービスを作っていけるようなエンジニアになりたいと思います。 高田さん 今後については正直、少し揺らいでいますね。ぼんやりとイメージしている選択肢は2つあって、1つ目はエンジニアとして技術を突き詰めていくスペシャリスト路線。2つ目は技術の知見もありながら、リーダーとしてメンバーを引っ張っていくマネージャー路線。一時期はスペシャリスト寄りの思考でしたが、最近はリーダー的なポジションで新しいプロジェクトを引っ張っていく役割を与えられたりもしていて、そっちでもやりがいや適正を感じています。色んな経験を重ねながら、自分がどういう人間になっていきたいかをじっくり考えたいですね。 ちなみに、社内にお手本になるような存在はいますか？ 高田さん それこそ、三浦さんですね。三浦さんがチームを引っ張っていく姿や仕事のやり方を見ていて、マネージャー路線も悪くないなと思えたところもあるので。 ありがとうございます。では、その三浦さんはご自身のキャリアについてどう考えていますか？ 三浦さん もともとは僕もスペシャリスト思考ではありましたが、性格的に飽きっぽいところもあるので、何か一つを探究していくというよりは手広く色んなことをやりつつ、チームを引っ張っていくような方向性なのかなと思っています。最近はコーチングみたいなことにも取り組み始めてはいるので、単にチームをまとめるだけじゃなく、メンバーの人生にも良い影響を与えられるような人間になれたらいいなと思いますね。 「お客様に喜んでもらいたい」そんな気持ちを持った人と一緒に働きたい 最後に、みなさんのチームにはどんな人がフィットすると思いますか？　あるいは「こんな人と働きたい」といった人物像があれば教えてください。 高田さん 個人的には、新しい技術をどんどんチームに提案してくれる人がいいですね。ITの世界は技術のトレンドの移り変わりが早いので、自分で積極的にキャッチアップしてくれる人がいると、開発者としてもすごくありがたいです。 加藤さん コミュニケーションを取りながら仕事をするのが好きな人ですかね。オプションチームはスクラム開発を取り入れていて、毎朝、仕事前にデイリースクラムをやったりと、みんなで積極的に意見を交わしながら開発しています。少なくとも、チームとしてプロジェクトを進めていくのが苦ではない人の方が向いていると思います。 三浦さんはいかがでしょう。リーダーの立場として、どんなメンバーに来て欲しいですか？ 三浦さん やはり、「サービスをお客様に届ける」という視点を持った人や、お客様に喜んでもらうことに対してモチベーションを感じられる人ですね。特に我々が手掛けているオプションサービスは、お客様に使ってもらって、改善要望などを頂戴しながらサービスを良くすることがメインの仕事ですので、そこにやりがいを見出せる人が向いていると思います。もちろん技術も必要なのですが、それ以上にサービスを良くしようと一生懸命になれること、自分ごと化できることが大事だと考えていますし、そういう人と働けたら嬉しいです。 前編もご覧ください！ 今回はニフティのオプションチームのインタビューの様子をお届けしました。あわせて前編もご覧ください。 【インタビュー】インターネットを快適かつ安全に使ってもらうために。日々新たなサービスを考え、生み出していく【ニフティオプションサービス前編】 ニフティでは、さまざまなプロダクトへ挑戦するエンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトよりお気軽にご連絡ください！ このインタビューに関する求人情報/ブログ記事 ニフティ株式会社 求人情報

はじめに こんにちは！ 2025年にニフティへ中途入社した寺島です。 マイ ニフティチームで、モバイルアプリの開発に励んでいます。 前々職は訪問修理、前職はモバイルアプリの開発に携わっており、ニフティがキャリア3社目となります。 今回は、私がどのような想いでニフティに入社したのか、そして実際に働いてみて何を感じているのかを、お伝えできればと思います！ ニフティってどんなところなんだろうと気になっている方の参考に、少しでもなれば嬉しいです。 自己紹介 30代前半で、2歳の子供が一人います。 趣味は、子供ができてからは控え気味ですが、ボードゲーム開発とボルダリングとフットサルです！ 映像作品はジャンル問わずなんでも見てます。 直近だと、ガリレオ→ゴールデンカムイ→踊る大捜査線→エコーの順で見ています。 転職で意識したこと 子育てに参加ができることをかなり重視しました。 その上で自身のキャリアを諦めないような環境があれば良いなと思っていました。 技術としては、前職から携わっているiOSの開発に携わりたいと思っていました。 選考 転職活動でいくつかの企業と接点を持つ中で、ニフティの選考は特に印象的でした。 第一印象は、月並みの表現になってしまいますが、真面目で優しいです。 オンラインでの選考でしたが、人柄の良さが画面越しでも伝わってきました。 楽しく仕事しているんだろうなというのが強く伝わってきました。 子育てについても理解のある会社で、時短勤務やFXの活用、産休育休に看護休暇等も利用できる制度が整っていました。 ポジションもモバイルアプリのエンジニアを用意していただきました。 さまざまな魅力がありましたが、 ニフティに決めた1番の要因は、面接に携わってくれた方の人柄に魅力を感じたことです。 入社後に感じたニフティの魅力 コミュニケーション 週5出社のスタイルなのでみんなでワイワイと開発や会議など行っています。 元々リアルで人と関わる仕事が長かったこともあり、対面のコミュニケーションは個人的にすごく落ち着きます。 Slackの活用も活発で、対面と画面越し両方とも楽しめます！ もちろん一人でモクモク作業スペースも用意されていますので、集中タイムでは篭っている人が多いです。 開発 まず、役割分担はありません。 iOSのアプリをSwiftで書いた直後に、KotlinでAndroidの開発を行ったりします。 それだけにはとどまらず、AWSでインフラの構築やGoでAPIの開発も行います。 社内活用ツールをNext.jsで書くこともあります。 モバイルアプリ開発に関わる全ての技術に携われます！ 文化 好奇心が強い方が多く、何にでも積極的に参加・挑戦する文化があると感じています。 新しいことや初めて挑戦することなど前向きに取り組む姿勢は会社全体に感じることができます。 また、さまざまなイベントを開催していてとても盛り上がりを感じます。 特に、社内LT大会は人気で私も毎回楽しみにしてます。 休暇 子供の発熱等で突発的にお休みをいただくことがありますが、優しく送り出していただいています。 挑戦 入社してすぐにエンジニアブログ運営チームに参加させていただきました。 年次関係なく、挑戦したいと手を挙げればいつでも誰でも挑戦できる環境が整っています。 全社で挑戦に対して肯定的で、さまざまな方が自分のチーム以外の、プロジェクトに参加してます。 これからの挑戦 私の実力不足もあり、インフラ方面は日々勉強です。 弊社では、書籍補助や、Udemyの会社アカウントの払出しやAWSの月額$100までのクレジットの提供など学習に対しての環境が整っていますので、毎日コツコツ頑張っています！ おわりに ニフティは、個人の「やりたい」という気持ちを尊重し、大きな裁量を与えてくれる会社です。 もし、 「自社サービスを自分の手で成長させたい」 「新しい技術に挑戦しながら、ワークライフバランスも大切にしたい」 と考えているなら、ニフティは最高の環境だと思います。 自分のやりたいことが明確になっている方、自分の力でサービスを動かしていきたいという熱意のある方、ぜひ一度、カジュアル面談でお話ししてみませんか？ 皆さんと一緒に働ける日を楽しみにしています！

ニフティの主力事業はインターネット回線を提供することですが、そのインターネットを快適かつ安全に使っていただくためのオプションサービスも充実しています。たとえば、ネット詐欺専用のセキュリティサービスや、有害な広告をブロックするスマートフォンアプリなど。既存のサービスに加え、インターネットユーザーのニーズをふまえた新規サービスの開発にも日々尽力しています。 これらの開発を手掛けるのが、オプションチーム。海外の外部パートナーとのやりとり、企画や営業チームとともにサービスの上流から携わるなど、他の開発チームにはあまりない動きができるのも大きな特徴です。そんなオプションチームのメンバーに日々の業務のことや、仕事のやりがいについて聞きました。 自己紹介 三浦 拓実さん 2019年4月‬入社。メイン業務はオプションサービス（セキュリティサービスなど）の開発、運用。‬趣味‬‬は最近始めたギターの練習とスノボ。‬‬ 高田 優一‬‬さん 2023年4月入社。メイン業務はオプションサービス（セキュリティサービスなど）の開発、運用‬‬。趣味‬は週末のランニングと飲食店巡り。‬ 加藤 里奈さん 2025年5月入社。メイン業務はオプションサービス（セキュリティサービスなど）の開発、運用‬‬。最近の楽しみは、退勤後に西新宿や中野坂上周辺を散策すること。 快適なインターネット生活を守る「オプションサービス」とは？ みなさんはニフティの「オプションサービス」の開発チームということですが、具体的にどんなサービスを手がけているのでしょうか？ 三浦さん ニフティのメイン事業はインターネット回線をお客様に提供することですが、回線に付帯するサービスや、より便利に安全にインターネットをお使いいただくためのウェブサービス、アプリなども提供しています。それらを総称しオプションサービスと呼んでいて、私たちのチームでは既存のオプションサービスの改善から新規サービスの開発まで、幅広く担っています。 具体的なサービスの例を一つ挙げていただけますか？ 三浦さん たとえば、2023年秋から受付を開始した「@nifty ADクリーナー」という、スマートフォン向けの広告ブロックアプリがあります。スマホにアプリを入れて設定をするだけで、ウェブ画面などに表示される不要な動画広告やバナー広告を消すことができます。 高田さん 広告の表示を減らすことでスマホの通信量を節約できるだけでなく、詐欺広告や闇バイトの広告、あるいは子供にとって有害な広告など、インターネット上の脅威といえる広告をブロックし、どなたにも安心してご利用いただけるようにしたい。そんな思いもあって、このアプリを開発しました。 加藤さんは2025年5月に前職のSlerから中途入社して3ヶ月目ということですが（取材時点）、普段はどんな業務に携わっていますか？ 加藤さん 現在は@nifty ADクリーナーの運用や、サービスのための環境構築、システム間連携など、様々なことを担当させてもらいながら、オプションチームの業務を一つひとつ覚えているところです。 手掛けるサービスが幅広いだけに、覚えることも多そうです。 加藤さん そうですね。たとえば、「セキュリティ」と名前が付くサービスが複数あったりしますので、最初は各サービスの名前や特徴を把握するだけでも大変でした。担当プロダクトの多さはオプションチームの特徴の一つですが、そのぶん様々な経験を積めるのはありがたいですね。 海外出張や新規開発に携われるチャンスも多い オプションチームの業務の特色を、もう少し詳しく教えてください。他チームと比べて、仕事の進め方などで大きく異なる点はありますか？ 三浦さん しいて言えば、外部の開発会社と連携しながら仕事をする機会が多いこと、海外とのやりとりが多いことですね。たとえば、提供サービスの一つに「常時安全セキュリティ24」というセキュリティソフトがあるのですが、セキュリティソフトってそれを作るために会社が一つ立ち上がるくらい大掛かりなプロジェクトですし、専門の技術者も必要になってくる。社内だけでやり切ることは難しいため、フィンランドにある会社のセキュリティサービスをニフティとして提供しています。 国内外を問わず、ニフティのお客様にフィットしそうな色んなサービスを吟味し、導入を目指すということを普段からやっていて、他チームに比べると海外ベンダーとのミーティングや、海外出張の機会も多いと思います。私自身も、最近はオランダ、ローマなどに行きました。そういう動きができるのは、オプションチームならではかもしれませんね。ちなみに、ミーティングなどは通訳の方を介して行うこともできますので、英語が必須というわけではありません。 海外のパートナーと仕事をするうえで意識していること、注意しなければいけないことはありますか？ 高田さん 一番は文化の違い、たとえば「休暇」に対する考え方ですかね。バカンスの期間などは完全に向こうの業務がストップして、どの担当者とも全く連絡がつかないみたいなことがあるので、事前の確認や調整が必要です。あとは時差を考慮するくらいで、海外だからといって特別にやることは変わりません。 国内外問わず、外部のパートナーと仕事をするときに大事なのは、ニフティの取り組みや「目指したいこと」をしっかり伝えること。場合によっては強く改善を要望しなくてはいけないこともあるので、そこは強い意志とコミュニケーションの力が問われるところかもしれません。 ちなみに、既存サービスの改善だけでなく新規サービスの開発も行うということでしたが、新規の案件というのはどれくらいの頻度で発生するものなのでしょうか？ 三浦さん わりと頻繁にというか、企画サイドから月に1件以上は新規案件の相談をもらいますね。もちろん、その全てが実際に開発まで進むわけではなくて、なかには「まだ形になるかどうかは分からないけど、こんなことできないかな？」といった、ぼんやりとした話もあります。 高田さん そういう場合は、私たち開発チームも企画や営業と一緒になって、具体的にどんなサービスにするのがいいのか、どんなことを考慮すべきか、どうすれば実現できるかなど、要件の部分から固めていくこともあります。そこも他の開発チームにはあまりない特色といえるかもしれません。 加藤さんは今のところ既存サービスの業務を覚えている段階かと思いますが、いずれは新規サービスに携わりたいという思いもありますか？ 加藤さん そうですね。前職では「お客さんから言われたもの」を作る業務がメインで、もっと上流工程というか、「自分たちがどういうものを作りたいか」を考えるフェーズから関わりたいという思いでニフティに転職したので、チャレンジしたい気持ちは強いです。私がこのチームに入って2ヶ月の間でも、すでにかなりの件数の相談が来ているので、そのうちチャンスがあるんじゃないかなと思います。 ニフティに根付く、挑戦を歓迎する風土 みなさんが仕事をしていて、喜びや楽しさ、達成感を感じるのはどんな時ですか？ 高田さん 仕事をしていて楽しいと感じるのは、新しい技術にトライできている時です。このオプションチームは特に、新しいものに対して抵抗がないメンバーが多くて。たとえば、「このシステム少し古くなっているから、新しいものに変えませんか？」みたいな提案もすんなりと受け入れてもらえますし、最近でいうとAIをどんどん開発に取り入れていこうといった動きも活発だったりします。エンジニアとしては、とても良い経験が積める環境だと感じますね。 加藤さん 高田さんがおっしゃる通り、色々なことに挑戦させてもらえる環境だなというのは、入社2ヶ月にして早くも感じています。たとえば、前職では全く携わったことのないインフラ構築を「いい機会だからやってみなよ」と、いきなり任せてもらえて。もちろん、分からない部分はサポートしてもらえますし、経験のないことにもトライできて、新しい知識がどんどん身に付く感覚がありますね。 それはリーダーの三浦さんがそうした雰囲気を作っているのか、それともニフティという会社自体に挑戦しやすい風土があるのか、どちらだと思いますか？ 加藤さん 三浦さんは特に「どんどんやってみなよ」と後押ししてくれるタイプですが、会社自体にも挑戦を歓迎する風土があるように感じます。私がニフティに入ったのが5月で、4月入社の新入社員が技術研修をしているタイミングだったんです。「中途入社なんですけど、一緒に受けてもいいですか？」と言ったら、「全然いいよ」と。研修の講師も2〜3年目の若手がやっていたりして、すごく丁寧に教えてくれましたし、知らないことを学ぼうとすること、新しい技術を知ろうとすることに対して本当にウェルカムな雰囲気を感じましたね。 三浦さんはいかがでしょうか？ 三浦さん 個人的な喜びとチームリーダーとしての喜びの両方があるのですが、個人でいうと、シンプルにサービスがヒットした時ですね。@nifty ADクリーナーもリリース当初は本当に売れるのか不安でしたが、おかげさまで多くのお客様にご愛顧いただき、社内でも記録的な数字を叩き出すことができました。 三浦さん チームリーダーとしては、むしろ自分が不在にしている時でもチームがしっかり回っていた時に、喜びを感じます。たとえば、僕が1週間ぶりに出張から帰ってきた時に、メンバーが「リーダーがいなくても回るフロー」を自分たちで考えてプロジェクトを前に進めていたことがありました。チームとしては非常に良いことですし、それからはより「いかに自分抜きでも回る環境を作れるか」ということを意識するようになりましたね。 後編に続きます！ 今回はニフティのオプションチームのインタビューの様子をお届けしました。続きは近日公開予定の後編の記事をご覧ください。 このインタビューに関する求人情報 /ブログ記事 ニフティ株式会社 求人情報