はじめに 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週間ぶりに出張から帰ってきた時に、メンバーが「リーダーがいなくても回るフロー」を自分たちで考えてプロジェクトを前に進めていたことがありました。チームとしては非常に良いことですし、それからはより「いかに自分抜きでも回る環境を作れるか」ということを意識するようになりましたね。 後編に続きます！ 今回はニフティのオプションチームのインタビューの様子をお届けしました。続きは近日公開予定の後編の記事をご覧ください。 このインタビューに関する求人情報 /ブログ記事 ニフティ株式会社 求人情報

Make with Notion 2025で、かなり多くの新機能が発表されましたね！ Notion AIが新しくなりました | Notion AIエージェントは登場すると予想していましたが、実際には期待以上の機能が発表されたと思います。ただ、AI系サービスは実際に使ってみないとわからない部分も多いので、新機能をいくつか試してみた感想を書いていこうと思います。 Notion AIのパーソナライズ Notion AIエージェント 実験：Slackのチャンネル情報からFAQデータベースを作る 実験：今週の予定やタスクを調べてタスクリストを作ってもらう Custom Agents その他 データベースの行権限 実現できるようになったユースケース: まだ実現できないユースケース 検索から除外する権限設定 People Profiles Notion AIのパーソナライズ 「アイコン」「名前」「Instruction(指示)」を変更できます。 Instruction は AGENTS.md と役割はほぼ一緒です。 思い出（メモリー）部分の記述は、AIとのやりとりで恒久的に指示したものが自動的に書き込まれるようです。AIの回答の下にあるGood/Badフィードバックボタンは、Notion社側へのフィードバックだと思うので送っても追記されなかったです。 パーソナライズしたAIを複数持てるようには現状なっていないですが、Instructionを変更してもプライベートセクションにページとして残るので、手動切り替えもできなくはないです。 カスタムエージェント機能がリリースされれば、複数エージェントを使い分けできるはずです。 Notion AIエージェント Notion AIによる長め＆マルチステップ処理ができるようになりました。 いままでのNotion AIでできていた「データベースをAIで構築」「ページ内の文言の追加・修正」これらが単タスク処理ではなく一気にやってくれます。 実験：Slackのチャンネル情報からFAQデータベースを作る API使うにしても面倒な「Slackの情報を抜き出してNotionにまとめる」地味な作業を、Notion AIでパッとやってみます。 Slack の #qa_notion チャンネルに投稿された過去3ヶ月分の情報を遡り、FAQを作成してください。 #qa_notion チャンネル以外の情報は参考にしないでください。 FAQはNotionデータベースとして作成し、各ページに質問の詳細と回答を記載してください。 これだけでFAQデータベースが作成できました。すばらしい！ 気軽にデータベース内の複数ページへの一括編集ができるようになりましたが、大勢が使っている共有データベースで使うには怖い機能です。Undo機能はありますがまず個人管理のデータベースで慣らしてから行うほうがいいでしょう。 実験：今週の予定やタスクを調べてタスクリストを作ってもらう AIに不慣れな方だと、「今週の予定やタスクをAIに自動生成してもらえる」という期待を持ちやすいので、実際に実現可能かどうか検証してみます。 @自分のアカウント の今週の予定とタスクを教えてください これだけでは他人の予定やタスクが混在してしまい、うまくいきませんでした。 🔺 Notion データベースを指定しないと他人のタスクが混ざることが多い 日常的に使うならInstructionでのデータベース指定は必須 ⭕️ Slack 未対応項目をうまく抜き出してくれる 🔺 Gmail メーリングリストやDMの情報も自身のタスクとしてみてしまう Instructionに条件を書けば除外できる 🔺 GitHub 参照リソースとしてメールが使われることが多い GitHubリソース単体で探す場合、GitHub IDだと見つからないため表示名で探させる必要がある InstructionでSaaSごとの検索方法を設定することで、かなり良好な結果が得られました。 - 今週の予定を調べるときの方法 - Notion - [掲示板] と [カレンダー] で締め切りの近いものや自分に関連する項目を確認 - [タスク管理DB] で対応が必要なタスクがないか確認 - Slack - 直近1週間で [Slackの表示名] 宛ての未返信メッセージを確認 - スレッド内で未完了の会話も確認 - Gmail - 未回答の個人宛てメッセージを確認 - メーリングリストやダイレクトメールは対象外としてください - GitHub - [GitHubの表示名] がレビュワーに指定されているPull Requestの確認 - [GitHubの表示名] が作成したPull RequestとIssueの状況確認 情報セキュリティの観点から共有できないデータが含まれているため、Notion AIで内容を匿名化したサンプルレスポンス↓ 今後、Notion AIがNotionカレンダーやGoogleカレンダーと連携できるようになれば、さらに精度が向上するため、そのような連携機能の実装が望まれますね。 Custom Agents Waitlist登録はしましたが待ちの状態です。 そのため Make with Notion のデモから得られた情報だけ一旦まとめます。 サイドバーにAgentセクションが追加されていたので、特定ツールや社内業務用のAgentを複数作成して、質問対応や業務処理をさせる使い方ができるようになりそうです。 Slackからの質問に対する一次回答として、カスタムエージェントへのリンクが提供されていました。Slackに直接AIが回答してくれるのが理想ですが、権限管理の問題があるため、このフローが落とし所なのでしょう。 その他 データベースの行権限 データベースの人物プロパティに登録されているユーザーに特定の権限を付与できる機能です。この機能により、ユーザーはページやデータベース全体へのアクセス権がなくても、設定された権限を得ることができます。 個人的に期待していた機能なのですが、もう一息といった印象です。 実現できるようになったユースケース: 共同編集者を簡単に追加できる 条件：データベース(読み取り権限)＋行(編集権限以上) 例：Slackからの問い合わせが自動的にNotionデータベースに登録されるワークフローがあったとして、問い合わせた人への編集権限付与が自動化できる まだ実現できないユースケース 権限のあるページだけが一覧表示されるデータベース 現状の問題：データベース自体の権限がないとページを一覧で見ることができない。かといってデータベースに権限を与えるとフィルターでビューを制御しても検索から見えてしまう。 理想条件：データベース(ページに権限のあるものだけ読み取り可能)＋行(編集権限) 検索から除外する権限設定 共有 > 一般的なアクセス の権限設定にて設定可能。 検索避けしてアーカイブ化したいページ向けだと思ったんですが、ページの権限を持っているユーザーからは非表示にならない仕様なのでちょっと使いづらかったです。 権限があっても検索結果には出ないようにして、検索オプションとして「非表示ページも表示する」項目を追加する形式がいいとは思うのでフィードバックしておこうと思います。 People Profiles Workspaceの設定から有効化することができます。 現時点ではPeopleの親ページを確認することができず。 デモでは 表示されていたので 将来的に一覧表示もできるようになると思われます。 Peopleの個人ページには、人物プロパティやユーザーアイコンからアクセスできます。 いまはその人のアクティビティ情報と所属チームスペースしか表示されないため、実用性は限られています。自分でプロフィールページをカスタマイズできるようになってからが本番でしょう。

ニフティの主力サービスの一つ「ニフティポイントクラブ」。もともとは「ライフメディア」の名称で20年以上運用されてきましたが、2021年に現在のニフティポイントクラブへ名称を変更し、お客様にさらに寄り添ったサービスへと生まれ変わっています。 その開発や運用、刷新を担うチームのメンバーに業務について語ってもらった前編に続き、後編ではニフティという会社のこと、自身のキャリアのことを深掘り。若手社員が感じる会社の良さ、思い描くキャリアビジョンとは？ チームに迎えたい人 ポイントチームに新たなメンバーを迎えるとしたら、どんな人がいいと思いますか？　現場視点の意見を聞かせてください。 西根さん 「 前編 」で関さんたちが言っていた通り、複雑度が高いシステムを扱うので、自分からどんどん情報を取りにいける人がいいと思います。古いプログラムでコードを読んでも分からない部分が多いと思いますが、その場合は社内で知見を持った人を探して相談するなど、能動的に動ける人が来てくれたら嬉しいです。 あとは、ポイントチームはニフティのなかではわりと騒がしいというか、おしゃべりなメンバーが多いです。活発なコミュニケーションから得られる情報もあるので、個人的にはとても良いことだと思っていますが、ガヤガヤした雰囲気が苦手じゃない人の方がフィットする気がします。 関さん 人柄については、僕も西根さんが言ってくれたようなタイプが合っていると思います。スキルに関しては、旧システムの刷新を進めている時期でもあるため、大規模サービスでシステムの移行を経験したことがある人や、関連する知見を持った人が来てくれるとありがたいですね。 細野さん 二人とほぼ同じですが、リーダーポジションだとアーキテクトの経験がある人が理想ですね。今後クラウド移行を加速させるにあたって、我々にはない視点でアドバイスをしてほしいです。メンバーポジションでは、西根さんが言ってくれたように能動的に動ける人に来てもらいたいと思います。 ニフティの良さ 率直に、みなさんが思う「ニフティの良さ」を教えてください。 細野さん まず思い浮かぶのは「良い人」が多いこと……なのですが、それは別チームへのインタビューでも語られていると思うので、あえて別のことで言うとプライベートの時間は確保しやすいです。休みも取りやすいし、業務に支障がなければ当日に「今日は午後休にします」と言っても通るくらい柔軟な職場だと思います。今日も、チームのメンバーの一人が15時でフレックス退勤をするんですけど、みんな誰に気を遣うこともなく休んだり半休を取ったりしていますね。仕事だけでなくプライベートの時間も充実させたい人にとっては良い環境なのかなと。 細野さん自身も、仕事とプライベートのバランスはうまくとれていますか？ 細野さん そうですね。会社のテニス部に入っているのですが、仕事が終わった後に部活へ行くと帰宅が遅くなるので、次の日に特に予定がなくても休みを入れたりすることはあります。 西根さん 確かに休みは取りやすいですね。この3人のなかで休暇制度を一番多く使っているのは私だと思いますが、おかげでプライベートは充実しています。 西根さんは音楽ライブに行くのが趣味だそうですね。 西根さん はい。平日のライブもフレックスで早めに退勤すれば参加できますし、先月だけでも4回行きました。11月には有給を取って、愛媛まで遠征します。ちなみに、今年は年30回のライブ参加を目標にしていましたが、無事に達成できそうです。 あとは、スキルアップに関する制度も充実していると思います。業務時間を使って外部のセミナーやイベントに参加できますし、書籍の購入補助や資格取得の支援もあります。個人的にはUdemyというオンライン学習サービスが会社の補助で見放題なのが嬉しいですね。 関さん エンジニア視点でいうと、技術に関するキャッチアップを怠らない人が多いと感じます。たとえば生成AIに関しても、ChatGPTが話題になり始めた頃には、Slack上でAIに質問できるシステムを社内の誰かが作っていました。Svelteという新しいフレームワークが出た時も、気づいたら導入されていましたね。新しい技術に対して日頃からアンテナを張り積極的に業務に取り入れたり、周りに広めたりする人が多いので、すごく学びやすい環境だと思います。 今後のキャリアについて 最後に、みなさんの今後のキャリアの展望や、挑戦してみたいことを教えてください。 西根さん 私はまだエンジニアとしての実務経験が少ないので、まずは多くの案件を任されるようになりたいです。ある程度の経験を積んだ上で、将来的には少しずつマネジメント寄りに軸足を移していけるといいですね。 社内にお手本になるような先輩はいますか？ 西根さん ポイントチームのリーダーが、私が描いている将来像に近いです。いわゆるソフトスキルに長けた方で、私もどちらかというとそうした部分を伸ばしていきたい。技術のこともちゃんと分かった上でマネジメントができるようなポジションを目指したいです。 他のみなさんはいかがですか？ 細野さん 直近の話でいうと、前職ではアプリケーションの開発業務がメインで、ニフティに入るまでインフラを手がける機会がなかったので、当面はそのスキルを上げていきたいと思っています。引き続きキャッチアップを続けて、チーム内でもインフラの部分については自分が牽引できるようなポジションを目指したいですね。今後のキャリアについては、まだ自分のなかで明確にコレというものはありません。技術をさらに磨くのか、マネジメントのスキルを習得していくのか、そこはまだ悩み中です。 一方で、いずれ自分でイチからアプリを開発したいという思いはずっと持っています。個人でやるのか、会社の事業としてやるのかは分かりませんが、いずれにせよ収益化するには技術だけではなく、顧客価値やビジネス的な観点も必要になります。自分に不足している部分を補いながら、やりたいことを一つずつ実現させていきたいです。 ニフティでそうしたアプリ開発や新規サービスに携われるチャンスはありそうですか？ 細野さん そうですね。最近は「新しいサービスを作っていこう」という機運も少しずつ高まっているように感じるので、チャンスはあると思います。 関さん じつは、最近も社内で新規事業関連のハッカソンがありました。エンジニアが作りたいものを作るといった内容で、細野さんと一緒に私も参加しました。 関さんも、ご自身で新規サービスを手掛けてみたいという思いがあるのでしょうか？ 関さん 新規事業というよりも、私はグロースエンジニアという職種に興味があって。施策の実行にあたり、技術だけではなく、分析から仕様策定、開発、リリース、評価までエンジニアが手がける職種で、将来的にはそっちの方向に進むのもいいのかなと。そのためには、細野さんが言うようにビジネス的な観点やお客様視点も必要になる。まだまだ学ばないといけないことがたくさんありますね。 前編もご覧ください！ 今回はニフティのポイントチームのインタビューの様子をお届けしました。あわせて前編もご覧ください。 【インタビュー】20年の“技術的負債”を解消し、よりよいお客様体験を生み出す【ニフティポイントクラブ前編】 ニフティでは、さまざまなプロダクトへ挑戦するエンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトよりお気軽にご連絡ください！ このインタビューに関する求人情報/ブログ記事 ポイントチーム 求人情報 ポイントチーム 求人情報（リードエンジニア候補） ニフティポイントクラブ AWS移行プロジェクト（Amazon Web Services ブログ掲載記事）

この度、私たちニフティ株式会社（以下ニフティ）は、10月4日、10月5日に開催される日本最大級のものづくりの祭典「Maker Faire Tokyo 2025」に、Goldsmithスポンサーとして協賛し、ブースを出展する運びとなりましたことをお知らせいたします。 ニフティ株式会社 テクノロジーとクリエイティビティが交差するこの素晴らしいイベントに、初めて参加できることを、メンバー一同、心より楽しみにしております。 Maker Faireとは？ Maker Faireは、地上最大のDIYの展示発表会。家族で楽しめる、発明と創造が一杯で機知に富む人々が集うメイカームーブメントのお祭りです。 その一部はサイエンスフェアのようであり、一部はカントリーフェアのようでもあり、そしてまったく新しい何かでもあるMaker Faireは、あらゆる年齢の技術愛好家、クラフト作家、教育者、物をいじくりまわすのが好きなティンカラー、ホビースト、エンジニア、サイエンスクラブのメンバー、作家、アーティスト、学生、そしてビジネスを行う出展者が参加します。彼らは、自分が作った物を見せるために、そして自分が学んだことをシェアするためにMaker Faire に参加します。 https://makezine.jp/event/mfk2024/aboutmake/ ニフティの出展ブースについて 今年のニフティブースでは、「 AIで絵本を作ろう！ 」をメインテーマに、ご来場の皆さまに楽しんでいただける3つの特別なコンテンツをご用意しました。AIと会話してオリジナル絵本を創作・印刷できる「 AI絵本をつくろう 」はもちろん、ネットワークの知識を楽しく深める「 ネットワーク管理ゲーム 」、ご自宅のWi-Fi速度変化を体験できる「 おうちのWi-Fiを見直そう 」など、盛りだくさんの内容でお待ちしております。 ■ コンテンツ1：ニフティキッズ 「AIで絵本を作ろう！」 AI絵本制作ワークショップ AIを使って自分だけのオリジナル絵本を作りながら、楽しくAIを学ぶワークショップを提供します。 タブレットを使ってAIに指示し、生成されたストーリーとイラストを使って絵本を作成します。 完成した絵本は持って帰って楽しんでいただけます。 https://kids.nifty.com/event_info/mft2025/ 【お知らせ】 10/4・5に実施されるMaker Faire Tokyo 2025で、AI絵本作成ワークショップを開催！ ぜひご参加ください！ スペシャルプレゼントとして、9/21までにワークショップのお申し込みいただいた方に、Maker Faire Tokyoチケットをプレゼントします https://t.co/GxKv6tArgc pic.twitter.com/PgpCoyQXaT — ひよりん【ニフティキッズ公式キャラクター】 (@kids_nifty) September 16, 2025 ■ コンテンツ2：ネットワーク管理ゲーム ※カードゲーム（通信パンク） ニフティボドゲ部社員の有志で作成した、ネットワーク題材のカードゲームを展示します。 実際に遊ぶことも出来ますので、是非お越しください！ ■ コンテンツ3：Wi-Fi速度低下についての実演展示 無線ルータの設定（2.4GHz/5GHzの周波数帯の違い）で速度変化する様子を実演展示いたします。 快適にインターネットを利用するためのテクニックを伝授いたします！ ぜひブースへお立ち寄りください！ イベント当日は、ぜひニフティブースへお立ち寄りください。メンバー一同、皆さまと会場でお会いし、ものづくりの楽しさや新しいテクノロジーの可能性について語り合えることを心待ちにしております！ 開催概要 イベント名 Maker Faire Tokyo 2025 開催日時 2025年10月4日(土) , 10月5日(日) ※詳細は公式サイトをご確認ください 会場 東京ビッグサイト ブース番号 SP-03-03 ニフティ株式会社 公式サイト https://makezine.jp/event/mft2025/

はじめに こんにちは、サービスシステムグループの佐々木です。 最近、多くの開発チームでマイクロサービスアーキテクチャが話題になっていますが、実際に導入してみると「思ってたより大変だった…」という声もよく聞きます。そんな中で注目されているのが「 モジュラーモノリス 」という考え方。今回は勉強会や自主学習で学んだことをまとめてみました。 モジュラーモノリスとは モジュラーモノリスは、ソフトウェアアーキテクチャの一つのアプローチです。 従来のモノリシックアーキテクチャとマイクロサービスアーキテクチャの中間的な位置づけとして考えられていて、 マイクロサービスを取り入れる上で課題があるのでモジュラーモノリスからはじめようといった選択肢 でもあります。 まずは、マイクロサービス導入にあたっての課題について触れたいと思います。 マイクロサービスの現実：理想と現実のギャップ マイクロサービスが解決してくれること マイクロサービスアーキテクチャには確かに魅力的な利点があります。 スケーラビリティ : サービスごとに必要な分だけスケールできる 技術の自由度 : サービスに最適な技術を選べる チームの独立性 : 各チームが自分のペースで開発・デプロイできる ですが、新しい悩みも生まれてきます… 分散システムならではの難しさ ネットワーク通信による複雑さ マイクロサービスでは各サービス間の通信がネットワークを介して行われるため、モノリスにはない課題が生まれます。 ネットワーク障害への対応 : 通信エラー、タイムアウト、パケットロスなどへの対処が必要 レイテンシの増加 : サービス間の呼び出しにネットワーク遅延が発生 障害の波及 : 1つのサービスの障害が他のサービスに連鎖的に影響する可能性 トランザクション管理の複雑さ モノリスでは簡単だった処理も、マイクロサービスだと途端に複雑に。 【モノリスの場合】 注文確定 → 在庫確保 → 決済 → ✗（失敗） → ロールバックしてリトライすればOK 【マイクロサービスの場合】 注文確定 → 在庫確保 → ✗（失敗） → 決済 → 単純なロールバックができない、専用のリカバリ処理が必要 マイクロサービス導入前には目的を明確に   こんな理由はちょっと危険 「最新技術を使ってみたいから」 「他の会社もやってるから」   こんな目的なら良さそう 機能ごとに独立してスケールしたい チーム間の開発サイクルを独立させたい 特定の技術要件に対応したい マイクロサービスが向かない場面もある こんな状況だと、マイクロサービス導入は慎重に考えた方が良さそうです。 スタートアップの初期段階 システムがまだシンプルな時期は、マイクロサービスの運用コストの方が重い 要件がコロコロ変わる時期には、サービス境界の設計が難しい ドメインがまだ曖昧な時 サービスの境界が不明確だと、頻繁に境界を変更することになる ネットワーク通信でパフォーマンスが悪くなるだけになりがち モジュラーモノリス：いいとこ取りのアプローチ モジュラーモノリスは、マイクロサービスとモノリスの「いいとこ取り」を目指したアプローチです。 こんな特徴があります: 同じアプリケーションの中でモジュールとして分割 サービス間の通信はネットワークを使わない 各モジュールの独立性は保ちつつ、分散システムの複雑さは避けられる 基本的な考え方: DDD（ドメイン駆動設計）と相性が良い サービス・ドメインをきちんと分離 高凝集・疎結合を目指す モジュラーモノリスの良いところ・気になるところ 良いところ   開発の独立性が保てる モジュール境界がはっきりしていれば、独立した開発ができる 将来マイクロサービスにしたくなった時の土台にもなる   運用がシンプル ネットワーク通信のエラー処理で悩まなくて済む 単一DBなので、データの整合性確保が楽   段階的に進められる 必要に応じて個別モジュールをマイクロサービス化できる 気になるところ   スケーリングに制約がある リソースを共有するので、個別モジュールだけスケールするのは難しい 全体のスケーラビリティには限界がある   技術スタックが統一される モジュール間で同じ技術を使う必要がある 実際にやってみるとしたら？移行戦略を考える（例） 段階的に進めるのがポイント フェーズ1: まずは大きく分ける 1. フロントエンド バックエンドで分離 2. 技術レイヤー別に分離（Java/PHP等） 3. セキュリティレベルで分離 フェーズ2: ドメインで分ける 1. ビジネスドメインを整理 2. モジュール境界を設計 3. インターフェースを定義 フェーズ3: データベースも分けるかどうか検討 1. モジュールの利用状況を分析 2. パフォーマンス要件を評価 3. 必要に応じてDB分割を実施 分割の順序：コードから？DBから？ おすすめは「コードから」のアプローチ なぜコードからが良いの？ 実際の利用状況を見てからDB分割を判断できる 失敗した時に元に戻しやすい リスクを段階的に管理できる 進め方のイメージ: 1. ビジネスロジックをモジュールに分割 2. インターフェースを定義して実装 3. 運用状況を監視・評価 4. 必要があればDB分割も実施 DB先行はちょっとリスキー 適用できそうなケース: 単一テーブルだけ参照する場合 明確にパフォーマンスが改善しそうな場合 注意したいこと: 短期的なメリットは少ない 複雑性が増すリスクがある どこから手をつける？優先順位の考え方 効果的に進めるには、こんな優先順位で考えてみると良さそうです。 1. 【最優先】分けやすい × メリットが大きい箇所 2. 分けにくい × メリットが大きい箇所 3. 分けやすい × メリットが小さい箇所 4. 分けにくい × メリットが小さい箇所 やっぱり「簡単で効果の高いところ」から始めるのが鉄則ですね。 モジュラーモノリスを学んでのまとめと今後の展望 データベース分割への新しい視点 従来、マイクロサービス化における最大の懸念はデータベース分割でした。しかし、モジュラーモノリスアプローチにより、この課題を段階的に解決できる選択肢があることを学びました。 アーキテクチャ選択の判断基準 学びを通じて各アプローチの適用場面が明確になりました。 マイクロサービス : 大量リクエスト処理、水平スケーリングが主目的の場合 モジュラーモノリス : 開発の独立性確保、段階的移行を検討する場合 モノリス : シンプルなシステム、明確な分割メリットがない場合 次のステップとして考えられること 実際に導入するとなったら以下のことから始めてみようと思いました。 今のシステムを整理してみる ドメイン境界の候補を洗い出してみる 今困っていることを整理する 小さく試してみる 影響の少ない部分から実験的に導入 効果を測る指標を決めておく チームのスキルアップ DDD（ドメイン駆動設計）について学んでみる モジュール設計のパターンを勉強してみる 参考資料 CloudNative Days 2024: モジュラーモノリス関連講演 Modular Monoliths (Simon Brown) MonolithFirst (Martin Fowler) Microservice Premium (Martin Fowler) StranglerFigApplication Pattern Monolith vs Microservices (InfoQ) この記事は実際の勉強会や自身の学びを基に、モジュラーモノリスという選択肢について整理したものです。実際の導入検討時には、各プロジェクトの特性や制約を十分に考慮することが大切です。

こんにちは。ニフティの おおい です。 今回はAmazon ECSの組み込みBlue/Greenデプロイ機能を活用して、AWS Lambdaによる自動テストを実施することで、安心してAPIをリリースできるようにしてみました。 はじめに 2025/7/17にリリースされたECSの組み込みBlue/Greenデプロイですが、デプロイの途中で自前のLambda関数を実行することができ、この関数が特定の値 ( SUCCESSFUL 、 FAILED 、 IN_PROGRESS のいずれか) を返すことでデプロイの制御をすることができます。 この機能を使ってLambda関数による自動テストを組み込むことにより、安心してAPIをリリースできるようにしてみましたのでその事例をご紹介します。 アーキテクチャ概要 今回構築したものは以下の要素で構成されています： ECSサービス：Blue/Greenデプロイメント戦略を設定 Application Load Balancer：本番用とテスト用のリスナーをポート違いで設定 ターゲットグループ：メイン用と代替用の2つを用意 Lambda関数：テストトラフィック移行後の自動テスト実行処理 S3バケット：テストケースの定義ファイルを格納 ポイント 今回のキモとなるのは Lambda関数 とS3バケットに格納される テストケースの定義ファイル の2つです。 またテスト用のフレームワークは利用せず、なるべくシンプルにテストができるようにしました。 テストケースの定義ファイル 今回はtomlで記述しました。tomlを選んだ理由は下記2点です。 後述のLambda関数をPythonで書いたので特別なライブラリ無しでパースができるため 可読性が高く人間が定義するのに難儀しないため 例) [general] base_url = "https://api.example.com:8443/v1" charset = "UTF-8" [[test_cases]] title = "特定ユーザの情報を参照できること" target_endpoint = "/users/existent-user-id" [[test_cases.assertions]] target = "resultCode" expected = "0" [[test_cases.assertions]] target = "courseId" expected = "1" [[test_cases]] title = "存在しないユーザの情報でエラーになること" target_endpoint = "/users/inexistent-user-id" [[test_cases.assertions]] target = "resultCode" expected = "1" [[test_cases.assertions]] target = "message" expected = "該当するユーザ情報データが存在しませんでした" [general] ブロックにはテスト全体で利用する基本的な設定を、 [[test_cases]] ブロックにはタイトルとテスト対象のエンドポイントを、 [[test_cases.assertions]] ブロックにはどの項目(→ target )がどういう値であることを期待するか(→ expected )の設定を書いています。 Lambda関数 この関数はECSの組み込みBlue/Greenデプロイ中、テストトラフィック移行後に実行するように設定します。 内容としても特別なことをしておらず、 S3バケットからテストケースの定義ファイルを持ってくる ファイルの内容を読み取る テストケースの数だけAPIリクエストを実行→アサーションを繰り返す と処理するように書いています。 ただこの関数実行後にデプロイをどうするべきかを決めなければいけませんので、失敗したテストケースのタイトルを配列として持っておいて、最終的にその配列が空であれば {"hookStatus": "SUCCEEDED"} を返して本番トラフィックをGreen環境に流すように、配列に要素があれば {"hookStatus": "FAILED"} を返してデプロイをロールバックするようにしました。 さらに失敗したテストケースのタイトルを持つようにしたので、ログ出力によって失敗したテストが何なのかをCloudWatch Logsから確認でき、次に何をすべきかがわかるようになるのがうれしいポイントです。 CI/CDとの連携 GitHub Actionsの中で テストケースの定義ファイルをS3バケットにコピー ECSサービスの更新 の2点を行うように実装すれば、ワークフローを起動するだけで安心してデプロイができるようになります。 さいごに ECSの組み込みBlue/GreenデプロイとLambda関数による自動テストの組み合わせによりこれまでよりも楽なAPIのリリースを実現できます。特に、テストトラフィック移行後にLambda関数を実行することで、本番影響を与えないで新バージョンの品質を確保できる点が大きなメリットです。 ECSの組み込みBlue/Greenデプロイはリリースされてから時間がたっておらず、手探りの状態で構築してみました。数ある事例の一つとして参考にしていただけたら嬉しいです。

ニフティの主力サービスの一つ「ニフティポイントクラブ」。もともとは「ライフメディア」の名称で20年以上運用されてきましたが、2021年に現在のニフティポイントクラブへ名称を変更し、お客様にさらに寄り添ったサービスへと生まれ変わっています。 とはいえ、20年続くサービスだけに、古いシステムの刷新は急務。技術的な負債を解消し、よりよい顧客体験を実現するために奮闘しているのがポイントチームの若きエンジニアたちです。主力サービスの刷新という重要な役割を担うメンバーたちに業務内容や現状の課題、仕事の喜びなどについて聞きました。 自己紹介 細野 俊平さん 2023年9月に中途入社。‬メイン業務はニフティポイントクラブ（lifemedia.jp）の開発、運用、刷新。休日の楽しみはテニス、愛犬のミニチュアダックスと遊ぶこと。 西根 千晴さん 2023年4月‬入社。メイン業務はニフティポイントクラブ（lifemedia.jp）の開発、運用、刷新。‬趣味は旅行とライブとボードゲーム。‬‬ 関 歩武さん 2021年4月‬に新卒入社。メイン業務はニフティポイントクラブ（lifemedia.jp）の開発、運用、刷新。趣味は色々なコーヒー豆を試したり、ハンバーガー屋を巡ること。最近はサウナ巡りも。 20年続くポイントサイトの先駆け「ニフティポイントクラブ」 みなさんが開発、運用、刷新を担当している「ニフティポイントクラブ」は、どのようなサービスなのでしょうか？ 細野さん 20年以上の運営実績があるポイントサービスです。お客様がニフティポイントクラブ提携企業のサービスを利用したり、無料ゲームやアンケートに答えることでポイントが付与されます。貯めたポイントは1P＝1円で、現金や電子マネーに交換できるほか、@niftyの利用料金に使うことも可能です。 また、今後のビジョンとしてはニフティポイントを基盤にして、ニフティの各サービスをもっと多くの人に活用してもらえるような状態をつくりたいと考えています。ニフティ経済圏とまではいかなくても、ポイントが潤滑油になってニフティのサービス全体をうまくつないでいきたい。今はそのための施策をチームで検討しています。 ニフティポイント自体は20年以上続くサービスということですが、みなさんはどのタイミング、どんな経緯でポイントチームにアサインされましたか？　また、それぞれの役割も教えてください。 細野さん 僕は2023年の9月にニフティに中途入社し、ポイントチームに配属されました。それからは主に、旧来のクラウドサービスに置かれているデータベースなどのインフラの一部をAWSへ移行するプロジェクトに携わっています。 関さん 2021年に新卒でニフティに入社して、複数のサービスでフロントエンド、バックエンドの開発を経験した後に、2年前からポイントチームに入りました。ポイントチームでの役割は開発、運用、刷新で、具体的にはお客様を対象にポイントの還元を拡大するための開発や、細野さんと同じAWSへの移行プロジェクトなどに携わっています。 ※2人が関わったAWS移行プロジェクトの概要 https://aws.amazon.com/jp/blogs/news/amazon-aurora-migration-nifty/ 西根さん 私は2023年に新卒でニフティに入り、1年間の研修とジョブローテーションを経て、最終的にポイントチームに配属されました。現在の主な役割は開発と運用です。 3人のなかでは西根さんが最も後輩にあたると。西根さんにとって、細野さんと関さんはどんな先輩ですか？ 西根さん それはもう、偉大な先輩です。 関さん 嘘っぽい（笑）。 西根さん いや、本当に。二人はAWSへの移行という負荷の大きいプロジェクトを担っていて、苦労しながらもやり切る姿を近くで見ていましたから。スケジュールもタイトななかで大変な業務だったと思いますが、いつも2人で意見を交わしながら、仲良く、前向きに取り組まれていた印象がありますね。 関さん 確かに、あの時期は本当に大変でしたが、細野さんと一緒になんとか乗り越えました。細野さんのほうが業界歴は長いのですが、僕は勝手に戦友だと思っています。 4000ファイルにも及ぶ“膿”を出し切る、途方もない作業 AWSへの移行にあたり、特に苦労した点を教えてください。 関さん 20年続くニフティポイントは会社にとって財産ともいえるサービスですが、一方で技術的には“20年分の負債”が蓄積している状態でした。たとえば、データベースを以前のクラウドからAWSに移行するにあたって、新しいシステムに影響が出ないよう中身を全て洗い出す必要があったんです。4000ファイルにも及ぶ“膿”を綺麗に出し切るのは、なかなか大変な作業でしたね。 細野さん おまけに、旧来のデーターベースで使われているシステムはかなり古いもので、プログラムもチームのメンバーはほぼ触ったことがないC言語が使われていました。そんな状態で負債を全て洗い出し、仮に漏れたまま移行してしまった場合でもお客様に影響が出ないようにしなければいけない。スケジュール的にもあまり余裕はなかったので、AIを活用するなどして知識不足を補いながら進めていきました。 その洗い出しというのは、関さんと細野さんのお二人でやられていたのでしょうか？ 関さん そうですね。ただ、途中からは知見を持った別チームの方がプロジェクトに入ってくれました。そのあたりの動きは、ポイントチームに限らずわりと柔軟ですね。プロジェクトに必要な人材を助っ人のような形で補充してくれることは珍しくありません。 西根さんはいかがでしょうか？　ポイントチームの業務で特に苦労したことを教えてください。 西根さん ポイントチームに配属されて半年ほど経った頃に、たまたま先輩の異動や転職が重なって、私1人で運用を担っていた時期がありました。まだ分からないことも多かったですし、当時は不安でしたね。 ただ、運用担当が1人になることが分かったタイミングで上司が面談の機会をつくってくれました。人の補充について私の意見も聞いてくれて、その後すぐに派遣社員の方がアサインされたので、早い段階で不安な状態は解消されましたね。 負荷がかかった時に、上長に対してアラートを出せる機会があるのはいいですね。 西根さん そうですね。面談の機会も多いですし、折に触れて「大丈夫？」と聞いてくれるので、相談しやすい環境ではあると思います。 エンジニアの醍醐味は、大きなプロジェクトを乗り切った時の達成感 仕事をしていて喜びや達成感を感じるのはどんな時ですか？ 関さん 今回のAWS移行もそうですが、大きなプロジェクトが一区切りついた時ですね。達成感というより、開放感に近いかもしれませんが（笑）。 特に、細野さんと2人でやってきたプロジェクトに関しては、リリース後に何かしら障害が発生するだろうと思っていたんです。でも、数ヶ月経ってもこれといった問題は起こらなくて。 細野さん じつは、ひとつ前にリリースした案件で障害が頻発してしまったこともあって、同じ轍を踏まないように進めてきました。より難易度の高い案件で、障害を出さないという目標をクリアできたのは大きな自信になりましたね。 西根さん 私は2人ほど負荷の大きいプロジェクトに携わった経験は、まだありません。ただ、以前に企画側から急ぎの開発依頼を受けて、約1ヶ月で調査から企画との調整、リリースまで主導したことがありました。無事にリリースできた時は喜びと同時に、「エンジニアになったんだな」という気持ちが芽生えたのを覚えています。 難易度の高いミッションだけに、やり切れば必ず力が付く ポイントチームの現状の課題があれば教えてください。 関さん 業務に関しては、先ほどもお話しした20年の負債ですね。未だに解消できていない部分も多く、引き続き着手していく必要があります。現状はシステムが古く、なおかつ複雑なため、「ここを変更すると、どこに影響が出るか分からない」という懸念から開発に踏み切れないケースもあるんです。余計な会議も増えて、開発のスピードも落ちてしまう。そうした複雑性をなくしていけば、よりお客様向けの開発に注力できるのではないかと思います。 細野さんはいかがですか？ 細野さん 同じですね。古くからの負債があることで、本来なら自動アップデートで事足りるような作業でも、メンバーが個別にサーバーの管理をしてアップデートをしなければいけないような状況が発生しています。それ以外にも問題が山積みで、早急に負債の解消とクラウド移行を進めていかなくてはいけません。 ただ、それをやるにも今は人員が不足していて、なかなか着手できていない。技術的負債が解消されず、色んな開発のボトルネックになってしまっているのが現状ですね。あまりにも課題が多いため、まずは全体像を把握し優先順位を決めて着手していく必要があると思います。 お話を伺っているだけで、かなり難易度の高いミッションであることが分かります。 細野さん ただ、これをしっかりやり切ることができれば、個人としてもかなり力が付くはず。20年の技術的負債に挑むなんてミッションは、そうそう与えられるものじゃない。エンジニアとして、かなり貴重な経験ができていると思います。今は大変ですが、後で振り返った時に必ずよかったと思えるはずです。 それに、関さんが話してくれたように、この大きな課題をクリアできれば、お客様に新しい価値を届けるような開発にも着手できます。そのステージに到達するためにも、できることから確実に進めていきたいですね。 後編に続きます！ 今回はニフティのポイントチームのインタビューの様子をお届けしました。続きは近日公開予定の後編の記事をご覧ください。 このインタビューに関する求人情報 /ブログ記事 ポイントチーム 求人情報 ポイントチーム 求人情報（リードエンジニア候補） ニフティポイントクラブ AWS移行プロジェクト（Amazon Web Services ブログ掲載記事）

はじめに こんにちは。瀧山・添野です。 本記事は、InnerSource Commonsが、9/12に主催したInnerSource Gathering Tokyo 2025の参加レポートになります。 InnerSource Gathering Tokyo 2025とは InnerSource Commonsというインナーソースに関するナレッジの創出と共有に特化したコミュニティがあり、そのコミュニティの日本支部が9/12にdocomo R&D OPEN LAB ODAIBAで実施したイベントになります。 弊社のメンバーがInnerSource Commonsに所属しており、本イベントでは運営や配信機器に関わるスタッフとしても参加いたしました。 イベントのHPはこちら https://gatherings.innersourcecommons.org/tokyo-2025/ 配信機器に関わるスタッフはこちら これがニフティの機材、配信班です！ 今回のイベントの裏方で活躍してくれた人たちです！感謝！ #ISGT2025 pic.twitter.com/UnJWtdZ9sf — rashikawat (@ryo19790510) September 12, 2025 なぜ参加したのか 瀧山：私はまだインナーソースを実践できていないので、インナーソースのベストプラクティスに興味がありました。また、ニフティを退職された方が一般参加されていたので、単純にその方に会いたいという理由もありました。 添野：私は、現在社内でインナーソースを推進するメンバーの一人で、本イベントのスタッフであった上司や同僚からも誘われて参加いたしました。 本題 イベント参加特典 本イベントに参加したところ、以下のものをいただきました。 インナーソースヒーローのステッカー×2 インナーソースヒーローのハンカチ InnerSource Commonsのロゴステッカー×2 水 ※インナーソースヒーローとは、InnerSource Commons Japanで生まれたキャラクターです。 詳細は、昨年のこちらのセッションをご確認ください。 https://youtu.be/ynlGpNnTCkc?si=K5nXXPnOwaKvB5Mi セッション Welcome to InnerSource Gathering Tokyo 2025 イオンスマートテクノロジー株式会社 / InnerSource Commons Foundation 久保 翔馬 (Shoma Kubo) 様 「インナーソースとはなにか」や「チャタムハウスルール※」の説明がありました。 ※チャタムハウスルールとは、会議で得た情報を自由に利用できるが、発言者の身元や所属、参加者の身元を明らかにすることはできないという、議論の自由な参加を促すための会議ルールです。 会場ご案内 [会場スポンサー] 株式会社NTTドコモ 本イベントの会場であるdocomo R&D OPEN LAB ODAIBAについての説明がありました。 本会場は、執筆時点（2025年9月）では、ドコモグループ社員と一緒であれば、今回のようなオープンなイベントを平日に実施できるイベント会場とのことでした。 また非イベント時では、コワーキングスペースとしても利用できるようです。 詳しくはHPをご確認ください。 https://docomo-openlab.jp/about/ 本イベントを実施したエリアでは、壁一面にディスプレイがあり、また座席の上部数カ所にもモニターが用意されており、非常に見やすい会場でした。 インナーソースで未来を築こう ワイクル株式会社 代表取締役 角 征典 (Masanori Kado) 様 資料 ： https://kdmsnr.com/slides/20250912_innersource/ インナーソースへの認識合わせから始まり、インナーソースに参加する動機や、組織に効果的に普及させるための実践的なアプローチについて解説されました。 インナーソースへの認識合わせのパートでは、ファイルを触らない貢献の例が話されており、貢献のレビュー、貢献のテスト、イシューのトリアージを例として出ていました。 ※登壇者の角さんの書籍はこちらになります。 感想 瀧山： OSSからインナーソースへと繋がる歴史が興味深かったです。 参考文献も多数紹介されており、OSSやインナーソース関連の書籍で勉強してみたいと思いました。 添野： 貢献のレビューで出ていた「送信は厳密に、受信は寛容に」というポステルの法則が響きました。 またイシューのトリアージは、普段コードを触らない方でも簡単に実践できそうでしたので、社内でも実践してみようと思います。 組織に効果的に普及させるための実践的なアプローチについて話されていた体験談では、感情も含めた共有が良いという内容で、参考になりました。 InnerSource活動『xPalette（クロスパレット）』が解き放つエンジニアの創造性と主体性 野村総合研究所 生産革新センター プラットフォームサービス開発二部 昼間 貴宏 (Takahiro HIRUMA) 様 xPaletteは、開発現場を業務ロジックの開発に集中できる快適な環境にすることを目的とした開発コミュニティです。立ち上げ時1人から16人まで成長した過程で培った、エンジニアの主体性を引き出すコミュニティ運営の工夫や、インセプションデッキを活用した共鳴の強化などの実践的な取り組みが紹介されました。 感想 瀧山： 社内の複数プロジェクトで使うガイドラインや共通テンプレートのようなものがインナーソースに合っているのかなと感じました。 添野： 主体的に活動したくなるコミュニティを目指すという方向性は非常に理にかなっていると感じました。 また、インセプションデッキを定期的に実施されているのも素晴らしい取り組みだと思いました。 三菱電気が推進するInnerSourceの未来 三菱電機株式会社 設計技術開発センター オープンソース共創推進部 部長 追立 真吾 (Shingo Oidate) 様 三菱電機では、OSSの開発や利用などを管理・推進する組織を2025年4月に新設されたとのことでした。オープンソースとインナーソースの両方を推進することで相乗効果を目指されているそうです。 また社内では、次のセッションでご登壇された小林様や、InnerSource Commons japanの服部様をゲストにお招きし、インナーソースDayを開催されたということでした。 感想 瀧山： OSSやインナーソースを推進する専門の部署があるのはすごいと感じました。なかなかここまでやっている会社はないと思います。 添野： オープンソースとインナーソースの両方を推進するアプローチは非常に興味深いと感じました。 また外部のゲストをお招きして社内でインナーソースのイベントを開催してみるのも良いアイデアだと思いました。 InnerSource対談 ican.lab代表 (品質管理エキスパート) 熊川 一平 (Ippei Kumagawa) 様 株式会社 東芝 デジタルイノベーション技術センター 小林 良岳 (Yoshitake Kobayashi) 様 大企業でインナーソースを推進した経験とその活用方法について、対談形式で語られたセッションでした。 熊川様からは、どのようにしてインナーソースの考え方に辿り着いたのかという経緯が紹介されました。開発標準やビジネス標準などの規程類のドキュメント作成において、インナーソースの知見を活用した改善事例についてもお話しされていました。 また、品質の観点から見たインナーソースの効果についても言及されていました。 感想 瀧山： 開発標準や規定のようなものはみんな嫌い、だから利用者自身が使いやすいようにコントリビュートするというのは面白かったです。 添野： 規程類は確かにインナーソースの手法が効果的だと感じました。 ファーストペンギンだけでなく、ファーストフォロワー（活動に賛同してくれる最初の人）も大切にしようという考え方に深く共感しました。 インナーソースヒーローからのメッセージ KDDIアジャイル開発センター インナーソースヒーロー / 中島 智弘 様 インナーソースヒーローからビデオメッセージが届き、それを視聴するセッションでした。 一人ひとりが所属組織を選択する時代に“われわれはなぜここにいるのか“その表現へのこだわりとプロセス KDDIアジャイル開発センター株式会社スクラムマスター 泉本 優輝 (Yuki Izumoto) 様 登壇資料 ： KAGreementとは、KAG（KDDIアジャイル開発センター）が憲章を社員それぞれで分解・解釈し、自分たちの働き方として再定義していく取り組みで、この手法を「KAG + Working Agreement」、略して「KAGreement」と呼んでいるそうです。 このKAGreementにおけるプロセスと、インナーソースのパターンを比べてみた際に、意外と共通点があったらしいです。 感想 瀧山： 社訓や行動指針のようなものは形骸化してしまうことも多いですが、全社員が取り組めるような仕組みができているのがすごいと感じました。 添野： 透明性を高く保ち、オープンなコミュニケーションの文化を築いている点が素晴らしいと感じました。 スケールする組織の実現に向けたインナーソース育成術 チームラボ株式会社 パッケージチームエンジニア 松本 玲音奈 (Leona Matsumoto) 様 登壇資料 ： 登壇者の自社のチームラボでのインナーソース活動を例にして、社内でどのようなSTEPでインナーソースを広めていく方法を紹介したセッションでした。 感想 瀧山： これまでは既存リポジトリをインナーソース化するパターンが多いかと思っていましたが、新規の便利ツールのようなものをインナーソース化するのはいいなと感じました。 添野： 「このツールを利用中のリポジトリ」のリンクを設けるのは、非常に効果的だと思いました。どのように利用されているかは、コントリビューター目線では気になるポイントであるため、こうした可視化により貢献へのモチベーション向上に繋がると感じます。 次のOSTの前に本イベントでのベストスピーカー賞の投票がありました。 ベストスピーカー賞の賞品としてウィンナーとマスタードソースが贈られていました。 InnerSource OST (Open Space Technology) 参加者から「このテーマについて他の人の意見を聞いてみたい」「本イベントでもっと深く話し合いたい」「次回のイベントで取り扱ってほしい」といった8つのテーマを募集し、それぞれのテーマごとに会場を分けてOSTの原則に従ったディスカッションセッションを実施しました。 また「チャタムハウスルール」が適用されているため、議論の場では自由に発言ができます。 感想 瀧山： 私はまだインナーソースを実践できていませんが、すでにかなり実践されている方の話を聞くのは面白かったです。初心者の疑問も話題にすることができました。 添野： OSTは初めて参加しましたが、色々とテーマについて他の会社の状況なども交えながら話せてとても楽しく良い経験になりました。 全体を通しての感想・学び・気付き 瀧山： 社外イベントに参加するのは久しぶりでしたが、熱量を感じるセッションばかりでとても刺激を受けました。社内で気になるインナーソースのリポジトリを見つけて、実際にコントリビュートしてみたいと思いました。 添野： イベントに参加してみて、インナーソース活動の新しい観点での気付きがあったり、会場の雰囲気自体もとても雰囲気が良かったため、次回開催されるのであれば、ぜひおすすめのイベントです。 終わりに 弊社では、外部のイベントやセミナーで学びを得られ、得た学びを持ち帰って周囲に共有できるのであれば上司の許可のもと自由に参加することができます。

はじめに こんにちは。基幹システムグループの瀧山です。 AWSは新規アカウント作成から1年間特定のサービスで利用できる無料枠がありますが、絶対に課金されないという設定はできません。 そこで私が実際に遭遇した落とし穴について解説したいと思います。 無課金で使えるはずが課金された！ EC2+RDSというシンプルな構成は、AWSアカウント作成から1年間利用できる無料枠内でも構築できます。 本当の最小構成だと1台のEC2にアプリとDBを相乗りさせる方法ですが、本番運用を視野に入れるならアプリとDBは分けた方がよいかと思います。 私も学習目的でEC2+RDS構成を個人アカウントで作っていたのですが、0.10ドルというわずかな金額ではありますが、意図しない課金が発生してしまいました。 課金の原因と対処方法 AWSコンソールの「Billing and Cost Management」（請求とコスト管理）を確認すると、課金されていたサービスはRDSでした。 具体的には、 「Amazon Relational Database Service Backup Storage – $0.095 per additional GB-month of backup storage exceeding free allocation running PostgreSQL」 という項目で課金されていました。 原因：バックアップ期間の設定 原因は、RDSのバックアップ期間が7日に設定されていたことです。 データベース作成方法を「簡単に作成」オプションにすると、バックアップ期間が7日で作成されてしまいます。 これはDBインスタンスサイズを「無料利用枠」に設定しても変わりませんでした。 データ量はかなり少なかったのですが、バックアップ期間の長さにより無料のストレージサイズを超過してしまうようです。 対処方法：バックアップ期間の変更 このバックアップ期間を1日にすると、課金は止まりました。 DB作成段階でこれを防ぐためには、データベース作成方法を「標準作成」オプションにし、バックアップ期間を1日または0日に設定する必要があります。 おわりに RDSを無料枠で利用する際には、RDSのバックアップ期間に注意が必要です。 意図しない課金が発生しないように、「Billing and Cost Management」はこまめにチェックすることをおすすめします。 また今回は個人アカウントでの話ですが、ニフティでは実弾演習場という制度があり、学習目的で自分用のAWSアカウントを作成して月100ドルまでを目安に使えます。（私有PCでも使えます！） その他に、私が所属している基幹システムグループでは独自にAWSのPoC（概念実証）用アカウントがあり、業務で新技術を採用する前の検証ができます。 AWSは手を動かしてリソースを作ることで理解が進む面も大きいかと思いますので、個人/会社アカウント問わず実際に触ってみるのがよいかと思います。

はじめに こんにちは!新卒1年目の高垣、なべしま、パクパクです。 新人研修の一環としてニフティ2025年度新卒入社の9名がAWS JumpStart2025に参加してきました!この記事では 2日間のプログラム内容に加えて、学んだAWSサービスやグループワークで作成したアーキテクチャ設計図を紹介します! AWS JumpStartとは AWS初学者のエンジニアを対象とした実践的な研修プログラム。事前学習動画と2日間の集中的なオンラインワークショップを通じて、AWSへの理解を深める。 単なるAWSサービスの学習だけでなく、要件に合わせてアーキテクチャを検討・設計することも行う。 本プログラムのゴール 一般的なリファレンスアーキテクチャの理解 AWSのコアサービスの概要とその選定基準の理解 AWSのアーキテクチャ図を作成するまでの流れを知る 実施日時 各回2日間(9:00~18:00) 2025 年 3 月 13 日（木）~ 3 月 14 日（金） 2025 年 5 月 27 日（火）~ 5 月 28 日（水） 2025 年 8 月 27 日（水）~ 8 月 28 日（木）(私たちが参加した日時) 2025 年 10 月 23 日（木）~ 10 月 24 日（金） スケジュール 1日目 1日目は、Webアプリケーションについての講義と、実際にWebアプリケーションを構築する実践的なハンズオンを行いました。ハンズオンでは、午前にEC2とAmplify、午後にECS + ALB + RDSといったAWSサービスを使用し、2～4人チームでのモブプログラミング形式で取り組みました。 午前 AWS体験ハンズオン( EC2 ) 最初のステップとして、ユーザ数が100人以下のような小規模なサービスを構築するハンズオンを体験しました。 このフェーズの目標は、 「とにかくシンプルに、そして安価に!」 サービスを立ち上げることでした。ここで利用する主なサービスは以下の通りです。 EC2 (Amazon Elastic Compute Cloud): クラウド上で仮想サーバをレンタルできるサービスです。 VPC (Virtual Private Cloud): AWSアカウント専用の論理的に分離された仮想ネットワーク空間を提供するサービスです。サーバを直接インターネットに公開しないように、「VPC」というプライベートな「柵」を設けるイメージです。 これらのサービスを実際に使って、シンプルなWebアプリケーションを作成するハンズオンを行いました。なお、今回のハンズオンでは1つのEC2インスタンスのみを立ち上げました。そのため、もしこのEC2インスタンスに障害が発生すると、サービス全体が停止してしまうという問題があります。このような弱点のことを 「単一障害点」 と呼び、実際のサービスでは避けなければならない構成です。 AWS体験ハンズオン( Amplify ) EC2とVPCの構成では、仮想サーバの管理やOS・ミドルウェアの設定といった、人による「構築作業」の負荷が高いという課題があります。この課題を解決し、より手軽にサービスを立ち上げる選択肢が Amplify です。 Amplifyには、主に次のような特徴があります。 手軽なデプロイ Webサイトのソースコードなどをアップロードするだけで、デプロイから公開までが自動的に行われます。 高速なグローバル配信 Amazon CloudFrontが自動で設定され、世界中のユーザへWebコンテンツを低遅延で高速に配信します。 自動スケーリング トラフィックの増減に応じてリソースが自動的に拡張・縮小されるため、急なアクセス増にも耐えられ、高い可用性を維持します。 Amplifyのハンズオンでも、シンプルなWebアプリケーションを作成しました。EC2のハンズオンとは異なり、OSやネットワークの設定をすることなくアプリケーションを立ち上げることができました。 このように、Amplifyはサーバレスでインフラ管理が不要という大きなメリットがあります。その一方で、EC2と比べてAWS構成の決定には制限があるため、用途に応じて使い分けることが重要です。 午後 AWS体験ハンズオン( ECS + ALB + RDS ) サービスが成長しユーザ数が増えてくると、次に重要になるのが 「アプリケーションの可用性や拡張性」 です。これを実現するための具体的な手法として、ECS+ALB+RDSといった組み合わせが考えられます。 ECS(Elastic Container Service): Dockerなどのコンテナを簡単に実行・管理できるサービスです。 ALB(Application Load Balancer): サーバへ来るアクセス（トラフィック）を、複数のサーバに自動で振り分けてくれるサービスです。 RDS (Amazon Relational Database Service): クラウド上でリレーショナルデータベースを簡単にセットアップ・運用できるサービスです。 このように、3つのサービスを組み合わせることで、アクセス数の増減に柔軟に対応できる、可用性・拡張性の高いシステムを構築することができます。具体的には、ALBがトラフィックを複数のコンテナ（ECSタスク）へ自動で分散させ、障害が起きたコンテナを切り離してくれるため、サービス全体が停止するリスクを低減し、柔軟な拡張も可能になります。 1日目の午後では、この構成を目指して、チーム全員でToDoアプリを構築するハンズオンに取り組みました。構築したアプリは以下のような感じです! 2日目 アーキテクティング 2日目は、1日目の講義の復習クイズと、AWS構成図を作成する（アーキテクチャ検討）ワークショップを行いました。 復習クイズでは、1日目に学んだサービスの特徴を確認する問題や、AWS認定資格の試験の対策になるようなクイズが出題されました。クイズ後の丁寧な解説が印象的でした。 アーキテクチャ検討ワークショップでは、「AWSを使ってWebサービスをリリースしたい」という課題に沿って設計に取り組みました。AWSの社員の方が今回の要件をロールプレイングで説明してくださったので、ワークショップも楽しく和やかな雰囲気で行うことができました。午前中は個人で設計図を考え、午後はそれぞれの設計図を持ち寄り、5〜8人のグループで協力してAWSシステムの設計に取り組みました。 成果 高垣チーム 私たちのチームは、以下の構成図を作成しました。 私たちのチームでは、月間1万人程度のアクセスを想定し、可用性を最大限高めたいと考えました。そこで、ECSとRDSを使って2つのアベイラビリティーゾーン(AZ: Availability Zone)に配置する構成にしました。 ユーザからのアクセスはCloudFrontを経由し、WAFでセキュリティを高めています。フロントエンド・バックエンド層はECS上でコンテナとして稼働し、これらへのトラフィックはALBを使って分散するようにしました。認証が必要な操作については、Cognitoを使って一元的に管理しています。データベースはRDSを採用して、こちらも2AZ構成にすることでデータベースの可用性を確保しています。また、Redshiftを使って蓄積される購買データなどを分析できるようにしています。 チーム内にAWSについて詳しい方はいなかったのですが、全員で調べたり、質問したりして協力しながら構築することができました。 なべしまチーム なべしまチームでは、複数AZにリソースを分散配置し、DBを冗長化するという高可用性の構成を基本として、次の2つの点を重視して設計を行いました。 1つ目は高いパフォーマンスです。Auroraをメインのデータベースとしながら、一時的に利用されるデータは高速なDynamoDBで管理するよう設計しました。また、Webサービスへの再アクセス時にAuroraの処理負荷を軽減するため、ElastiCacheを導入しました。 2つ目はセキュリティです。外部からのアクセスはCloudFrontを経由させ、WAFによってセキュリティを強化しました。課題のWebサービスでは、ユーザが個別アカウントを持ってサービスを利用することを想定したため、アカウント管理にはCognitoを採用し、高度なセキュリティの実現を目指しました。 「このAWSサービスで実現したいことは何か」を意識して議論することで、チームで納得できる設計ができ、理解をより深めることができました。 パクパクチーム パクパクチームはユーザが増える場合の可用性と拡張性を意識して、以下の構成図を作成しました。 この構成図で特に工夫したポイントは下記の3つです。 1. セキュリティ（Security） サービスで利用されるデータとリソースを保護するため、多層的なセキュリティ対策を実装しました。 WAF: SQLインジェクションやクロスサイトスクリプティング（XSS）のような一般的なWeb攻撃の パターンをトラフィックがサーバに到達する前にフィルタリングします。 AWS Shield: DDoS（分散型サービス妨害）攻撃からシステムを保護するマネージドサービスです。サービスを麻痺させるような悪意のある大量のトラフィックを検知します。 Amazon Cognito: ユーザのサインアップ、サインイン、アクセスコントロールを担う認証サービスです。これにより、認証システムを自前で構築する複雑さを軽減し、セキュリティを強化することができます。 VPC: ネットワークをパブリックサブネットとプライベートサブネットに分離しました。パブリックサブネットには、外部インターネットとの直接通信が必要なウェブサーバやロードバランサーなど、最小限のリソースのみを配置し、データベースや主要なアプリケーションサーバはプライベートサブネットに配置しました。この構成により、データベースが外部から直接アクセスされるリスクを大幅に低減し、リソースへのアクセスを厳格に制御することができます。 2. 可用性（High Availability） ウェブサーバ、アプリケーションサーバ、データベースを含む全く同じシステムを 2つのアベイラビリティーゾーン で構築しました。もし片方の「AZ1」に問題が発生しサーバダウンしても、正常に動いているもう一方の「AZ2」へ自動的にトラフィックが切り替わるように構成し、サービスが停止しない設計しました。 3. 拡張性（Scalability） ユーザ数（トラフィック）は状況によって変わります。イベントや時間帯によって増えることもあれば、減少することもあります。このようなトラフィックの変動に効率的に対応するため 「Auto Scaling」 を導入しました。 これにより、トラフィックが通常時よりも増加した際には自動でECSタスクを追加してサーバの負荷を分散します。逆にトラフィックが少ない時間帯には不要なECSタスクを自動で終了させ、コストを最適化します。 感想 高垣 2日間を通して、クラウドインフラ設計の基礎から実践まで幅広く学ぶことができました。1日目の講義では、単にシステムを構築するだけでなく、安定稼働のための運用面についても詳細な解説があり、実務に直結する知識を深めることができました。2日目では、アーキテクチャを設計しつつ、これまで詳しく知らなかったAWSサービスについての理解を深めることができたのは大きな収穫だと思います。 短い期間でしたが、非常に学びが多い研修でした。 なべしま AWS JumpStartでは、実践的なワークに取り組むことができました。「なぜこのような設定をするのか」「このサービスで実現したいことは何か」など、AWSサービスの深掘りをすることで、より理解が深まったと感じています。 グループワークでは、課題に取り組む中で社外の方との交流がありました。AWSの勉強の進め方や、クラウドサービス・AIの活用についてお話をすることができました。JumpStartのコンテンツ外でも学びを得る、貴重な機会となりました。 パクパク 学生時代は名前しか知らなかったAWSをニフティに入社してから、AWS Summit、そして今回のAWS JumpStartと、直接体験できる貴重な機会をいただきました。 前回のAWS Summitがクラウドへの興味が湧くきっかけになった時間だとしたら、今回のAWS JumpStartは、様々なサービスを組み合わせて一つのアプリケーションを構築する具体的な方法を学んだ時間でした。 特に初心者向けのイベントだったので、AWSが初めての参加者も多く、気軽な雰囲気で質問しながら協力しました。困ったことはチームメンバーと一緒に工夫しながらハンズオンを進めることができました。 以前は複雑な絵にしか見えなかったアーキテクチャ図から、今では各サービスの役割やデータの流れを読み取れるようになりました。今回のAWS JumpStartは今後の業務でAWSの技術やアーキテクチャに向き合う際に「自分も応用できる」という自信を与えてくれた、貴重な経験でした。 AWS JumpStartのページ https://aws.amazon.com/jp/blogs/news/aws-jumpstart-2025/

はじめに はじめまして。2025年5月にニフティへ入社しました、サービスシステムグループのkatrinaです。 趣味でオーケストラサークルに所属しており、コントラバスを弾いています。休日はもちろん平日夜にも練習をしていて、少しでも練習時間を確保したいという思いが仕事のモチベーションにもなってます！ これまでの経歴と転職のきっかけ 前職ではSIerとして約9年間、主にお客様先に常駐しながらシステム開発に携わってきました。 多くのプロジェクトを経験する中で、次第に「もっと上流の工程から開発に関わりたい」「サービスそのものの成長を考えられるエンジニアになりたい」という想いが強くなり、転職を決意しました。 転職活動を通じて、ニフティの面接が最も印象的でした。多くの企業で技術的なスキルに関する質問が中心だったのに対し、ニフティでは技術の話はもちろんのこと、私のキャリアプランや仕事に対する価値観といったパーソナルな部分についても質問してもらいました。 自分のやりたいことや価値観を尊重してもらえる雰囲気があると感じられ、入社を決めました。 入社して感じたこと 応募した職種はフルスタックエンジニアでした。前職ではWebアプリケーション開発をメインで行っており、フロントエンドとバックエンドどちらも経験があったので、いずれのスキルも活かしたいと思い応募をしました。 入社して感じた大きなギャップは、アプリケーションの開発だけでなく、インフラ構築や運用など、プロダクトに関わる全てのシステム周りの作業を担うということでした。これが内製化か！と思いました。 特にインフラ領域にはこれまで携わったことがなかったのですが、AWSはもともと個人的に勉強していたので実践の場を得ることができ、やりがいを感じています。 コミュニケーションが活発なチーム 私のチームではスクラムでの開発をおこなっています。スクラムイベントによってコミュニケーションが発生することはもちろんですが、気軽にSlackで質問をしたり、直接声をかけられる雰囲気があります。チームだけではなく社内全体でそういった雰囲気があるように思います。 前職は黙々と作業をすることが多かったのですが、もともとコミュニケーションを取りながら作業を進めて行くことが好きだったので、とても居心地がよいです。 スキルを広げられる環境 入社して初めて担当した作業が、Terraformを使ってのAWS環境の構築でした。 前述の通り、実務でのAWS操作の経験も乏しい中、Terraformは全く初めて触るという状況でしたが、ぜひやってみたいと思い挑戦させてもらいました。「開発環境なら何かあっても戻せばいいからどんどんやってみて」というチームの後押しがとても心強かったです。こういった挑戦しやすい環境があるのは、自分たちで環境を管理しているからこそなのかと思います。 また、社内ではAIを活用できる環境も整っており、有識者による勉強会も頻繁に開かれています。前職では触れる機会がなかったのですが、現在では3ヶ月前の自分では想像できないくらい活用しています。 今後の目標・抱負 まだ経験は少ないですが、ビジネス部門のメンバーと一緒に、新サービスについて検討する打合わせに参加したことがあります。もともと転職のきっかけとなった上流に携わるという環境に身を置くことができているので、エンジニアとしての意見を伝えられるよう、まずはドメイン知識や技術スキルをしっかり身に着けていきたいです。 最後に 私の経験から、ニフティは以下のような方に特におすすめできる会社だと感じています！ 工程にとらわれず、担当システムの全てに関わってみたい方 未経験の技術、新しい技術にも主体的に挑戦したい方 チームメンバーと積極的にコミュニケーションを取りながら開発を進めたい方 少しでもご興味をお持ちいただけましたら、まずはカジュアル面談でお話ししませんか？ご連絡をお待ちしております！

はじめに こんにちは。ニフティの山田です。 意外と知らない方が多そうだったので、今回はPATを使わないGitHubのアクセス方法について紹介します。 前提 GitHubではHTTP経由でのID/パスワード認証が廃止され、現在は許可されていません。 このため、 git clone などの際にID・パスワードを入力しても弾かれてしまいます。(ブラウザと同様です) なので、 HTTP Personal Access Token(PAT) OAuth認証 SSH の3通りの接続方法から選ぶことになります。 SSHが使える環境ではSSHを使えばよいのですが、環境によってはSSHを通せず、HTTPを使用する必要がある場合もあります。 PAT PATは古くからある方法であり、Personalの文字通り、個人に紐づくトークンを手動で発行・管理します。 手動管理する鍵であり、管理の漏れや漏洩の可能性がある 用途ごとに鍵を分けるのか使い回すのか…など、鍵管理を考える必要がある というように管理負担もセキュリティリスクもあり、なるべく使いたくない選択肢です。 OAuth認証 前提で記載した2つ目の選択肢です。OAuth認証後に発行されるトークンでもGitHubへのアクセスが可能となります。 OAuthなのでブラウザが必要ですが、Git実行PCと別のPCでも問題ありません。 GitHub Desktopを使う方法 Download GitHub Desktop インストール・起動して指示通りに進めばGitHubへOAuth認証を促されます。 GitHub Desktopがログインできている状態であればOAuthトークンが有効なので、gitコマンドでの操作でも認証が通ります。 GitHub CLIを使う方法 GitHub CLI コマンドライン上で完結させたい場合はGitHub CLIをインストールします。 macOSであればhomebrewから brew install gh でのインストールも可能です。 インストール後 gh auth login でログインできます。あとは普通にgitコマンドを叩けば完了です。 操作 $ gh auth login ? Where do you use GitHub? GitHub.com ? What is your preferred protocol for Git operations on this host? HTTPS ? Authenticate Git with your GitHub credentials? Yes ? How would you like to authenticate GitHub CLI? Login with a web browser ! First copy your one-time code: XXXX-XXXX Press Enter to open <https://github.com/login/device> in your browser... ✓ Authentication complete. - gh config set -h github.com git_protocol https ✓ Configured git protocol ! Authentication credentials saved in plain text ✓ Logged in as xxxxxx 途中の「Press Enter to~」でEnterを押すとブラザが開くので、ブラウザ側でログインしてコードを入力します。 なおブラウザでのコード入力を要求されますが、この操作は別マシンのブラウザで行っても問題ありません。なのでサーバ上でも問題なくログインが可能です。 制約 PATと異なり、 有効期限がない(設定もできない) GitHub画面上から無効化しない限り、無期限にずっと使えてしまう 短期にしてほしいというissueはある https://github.com/cli/cli/issues/5924 PATと異なり、権限制御はできない 自動化目的であればPATを使う おわりに 今回はPATを使わないGitHubのアクセス方法について紹介しました。 この機会にPATの管理負担なども考慮して、OAuth認証でのGitHubアクセスを試してみるのはいかがでしょうか。