September 19, 2025

はじめに 本記事では、2024年10月に一般ユーザ向けに正式リリースされた、Excel上でPythonを実行できる機能「Python in Excel」を実際に導入して触ってみたので、導入方法や使い方をサンプルを交えながら紹介します。 Python in Excelとは 名前の通り、Excel上でPythonを実行できる機能です。セルに直接Pythonコードを記述することができ、Microsoftクラウド上で実行され、結果がワークシートに返されます。Excel操作の自動化ではなく、データ分析に重点を置いた機能です。 導入方法 導入はとても簡単です。 ・必要な設定 特にありません。Python in Excel 機能が提供されている契約プランに登録するだけで利用できます。 ・対応プラン 「Microsoft 365 Business Standard / Premium」や、「Microsoft 365 E3 / E5」などです。※2025/5 時点では「Microsoft 365 Personal」では利用不可でした。公式ホームページ（※筆者はホームページをちゃんと確認せずに「Microsoft 365 Personal」を契約してしまいました……） 使い方 ・数式タブからPython挿入 数式タブから「Pythonの挿入」を選択すると、セル内に直接コードを記述できます。 ・セルに「=PY()」記述 セルに「=PY()」と記述することで、Pythonコードを簡単に開始できます。 ・コードエディタ使用 コードエディタを使用して、より複雑なPythonコードを記述することができます。 制限 導入が簡単で、使い始めるまでのハードルが低いPython in Excel ですが、使用できる機能に制限があります。 ・ライブラリ 使用できるライブラリに制限があります。Python in Excelでは、 Anaconda※1 によって提供されている標準ライブラリのみを使用することができます。ユーザが、外部ライブラリをインストールすることはできません。 ※1 Anaconda…データサイエンスや機械学習に関する作業を効率的に行うためのPythonディストリビューション。 ・Webアクセス 外部APIや、Webサイトへのアクセスができません。インターネット経由でデータを取得するようなプログラムには不向きです。 ・戻り値 セルに記述したPythonコードの戻り値は、単純な構造に限られます。3次元配列やクラスインスタンスなどは使用できませんが、数値・文字列・DataFrame（表形式） などは使用可能です。

はじめに システムの内部連携のためにJWTトークンによる認証を行う必要があるとのことで、その導入をおこないました。その経緯や技術選定の際に考慮した点について共有したいと思います。 そもそもJWTトークンとは? エンジニアの方ならすでにご存じの方が多いと思います。ただ、前置きとして簡潔に概要を振り返りたいと思います。 よくあるログインの認証の仕組み JWT以外の認証だとセッションベースの認証が多いかと思います。セッションベースはユーザーがログインした場合アプリケーション側がログイン状態を覚えておき、再度サイトに訪れたときは、ログイン処理をスキップするというものです。ユーザー(ブラウザ)にはアプリケーションから発行されたセッション変数がCookieとして格納され、ユーザーがサイト訪問した際にそのCookieをアプリケーションに渡してもらうことで アプリケーションはそのユーザーがログインした状態なのかをRedisなどのミドルウェアに格納された値を参照してチェックします。 JWTは何が違うか? セッションベースと大きく異なるのは、アプリケーション側がユーザーのログイン状態を保持しないことです。どういうことか?ユーザー(ブラウザ)から渡されたCookieのトークンを検証して、問題なければ認証するというところは同じですが、保持しないという点に注目してください。まずログイン認証が行われた際アプリケーション側の秘密鍵で生成された「トークン」をユーザーに返します（CookieやHTTPヘッダに格納されるケースが多いです）。このときアプリケーションはその値をサーバー側に保持しません（ただし、ログアウトや失効管理のために保持する実装もあります）。次にユーザーが再度訪問した際は、Cookieに格納されたJWTトークンが正常のものかを検証します。具体的には、JWTトークンに含まれる署名をサーバー側の秘密鍵（または公開鍵）で検証できるため、Redisなどを参照する必要がありません。、Redisなどを参照する必要はないのです。(もちろん、各システムの実装によりますので参考程度に。) JWTトークンの構成 3つのパーツからできております。 上記要素を下記のように「.」で繋いだものがJWTトークンとなります。それぞれのパーツが各自base64エンコードされてます。 ヘッダalg: 署名のアルゴリズムtyp: トークンタイプで「JWT」固定下記jsonをbase64エンコードする 署名上記2つ(ヘッダ&ペイロード)がエンコードされた文字列({xxxx}.{xxxxx})をヘッダのアルゴリズムと秘密鍵で署名し、さらにエンコードを行います。 JWTトークンをLaravelに導入する ここまででカンの良い方なら分かると思いますが、そこまで複雑ではなく自前で実装できる範囲です。ただし、JWTはインターネット標準仕様（RFC 7519）で定義されています。この仕様を遵守できるようにするため、ライブラリ(tymon/jwt-auth)を選択しました。今回はJWTトークンの生成と検証を実装範囲として、ミドルウェアでの認証への導入までは行いません。 パッケージ導入 & 設定ファイルの生成 サンプルコード JWTトークンの生成 JWTトークンの検証 ※booleanで判定結果を返す JWTトークンの生成、復号化してのチェックなら上記のように簡潔に実装することが可能です。 まとめ 今はJWTトークンが使われることが多くなってきています。知識はあるけれど、実装したことが無いという方にとって本記事が参考になれば幸いです。自分の場合は、理解しながら進めたため実装に数日かかりました。自前で実装するもライブラリ使うのもどっちでも良いかと思いますが、意外とtymon/jwt-authで生成&検証するだけのサンプルコードがなかったので、用意してみました。またなにか発見があれば、引き続き執筆しようと思います。

はじめに 開発者なら言わずもがなReactは知っている方がほとんどかと思います。Stateで直感的かつ簡潔に状態管理を行うことができ、その際のDOMの更新もReactがよしなにやってくれます。開発者はdocument.getElementById(xxx)などを使って冗長なHTMLの取得・更新・削除まで気にかける必要はありません。外部APIの呼び出しといった副作用もReactのuseEffectを使えば、開発環境では二回呼び出し(間にクリーンアップ関数実行)までデフォルトで確認できるなど使いやすさも素晴らしいです。しかしながら、なぜNext.jsが登場し、それが多くの開発者に親しまれているのでしょうか?今回はReactとNext.jsを比較し、Next.jsのメリットを簡潔におさらいしようかと思います。 ReactとNext.jsのちがい Reactは基本的にCSR(Client-Side Rendering)のみ ReactはCSRのみです。これはつまりブラウザ側でJavaScriptを実行し、DOMを生成するため その処理はすべてユーザー側(ブラウザ)の負担となり表示速度にも課題が残ります。そして何より、ブラウザでJavaScriptをOFFにしていたら、何も表示されません。。。(あるサイトで調べたところ1%ほどはJavaScript無効でブラウザを利用しているユーザーが居るようです。)また、React単体だとSPAとしては勝手が良いのですがルーティングに課題があります。 Next.jsはルーティング機能にCSR&SSR&SSGにも対応 ルーティング Next.jsはルーティング機能を提供しています。src/app/{xxx}/page.tsx を生成するだけで、http://domain.com/{xxx} へのルーティングの設定は完了します。また、動的ルーティングにも対応しており ブログ記事など 動的コンテンツも簡単に実装することができます。 プリレンダリング Next.jsはReactの速度面でのデメリットを解決するため、基本的にページのプリレンダリングを実行します。これはあらかじめ最小限のHTMLを作っておき、その後JavaScriptが読み込まれて、ボタンの押下や送信といった操作できる状態となります。速度改善だけではなく、SEOにもメリットがあります。 CSR (Client-Side Rendering) Reactと同じ動きです。ユーザーのブラウザでのみ処理が行われ、初回表示は遅いのですがその後は高速に動作します。 SSR (Server-Side Rendering) これはサーバーサイドでHTMLをレンダリングすることです。Nodeが実行できる環境のみ可能です。サーバーサイドで処理してからクライアントへ返すのでオーバーヘッドが発生しますが、それでも最新の情報を常に返すようなページに向いてます。 SSG (Static Site Generation） 静的なページであれば、予めHTMLを生成しておくことで速度をかなり向上させることができます。SSGでビルド後に生成されるのは静的なHTML/CSS/JavaScriptファイルなので、Node.jsが使えないサーバー環境でもそのまま公開できます。例えば、日本で人気のレンタルサーバーであるXserverではnodeがサポートされていません。そのようなケースでも使えるのは大きな強みですね。 SSGとCSRを組み合わせるメリット 上述したSSGとCSRを組み合わせることでページごとに戦略を選べることが大きなメリットになります。例えば、コーポレートサイトを考えたとき TOPページや会社概要のページは静的なページですのでSSGが選択できます。これによって表示速度の恩恵を受けることができ、SEO的な観点でもメリットがあります。そして、コーポレートサイトの管理画面ではSSRを採用することで、記事投稿といった機能において最新の情報の取得や更新処理などを実装できます。このように一つのフレームワークで複数のレンダリング戦略を選択できるのはNext.jsのとても強力なメリットとなってます。 まとめ 今まで紹介した通り、Next.jsには以下のような特徴があります。 興味のある方はぜひご自身でもNext.jsを触ってみてください✨️この記事を読んでなにか皆さんの役に立てると嬉しいです..! では!