はじめに

本記事では、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（表形式） などは使用可能です。

サンプル紹介

Python in Excel を使うことで、Excelよりも効率的に操作できる例を2つ紹介します。

・要約統計量取得

※要約統計量…データ分析に必要な「平均値、中央値、四分位範囲」などの統計情報

例 : ある店の2025年5月の売上が、日単位で表にまとめられています。
このデータから、PythonとExcel関数を使って、それぞれ要約統計量を取得してみます。

・Python
Pythonなら、たった1セルに2行のコードを記述するだけで要約統計量が取得できます。

df = xl("B1:B32", headers=True)   #←売上データを取得
df.describe()                     #←要約統計量を取得するdescribe()メソッドを実行

また、データ範囲が変更された場合も修正が容易です。

・Excel
Excelで同様の要約統計量を取得するには、各項目に対応した関数を個別に用意する必要があります。
また、データ範囲が変更された場合すべてのExcel関数を修正する必要があります。

count  : =COUNTA(B2:B32)                   ←件数
mean  : =AVERAGE(B2:B32)                  ←平均値
std      : =STDEV.S(B2:B32)                    ←標準偏差
min     : =MIN(B2:B32)                            ←最小値
25%    : =QUARTILE.INC(B2:B32,1)      ←第一四分位
50%    : =MEDIAN(B2:B32)                   ←第二四分位
75%    : =QUARTILE.INC(B2:B32, 3)    ←第三四分位
max    : =MAX(B2:B32)                          ←最大値

・折れ線グラフ

前項で使用したデータを使い、「売上と7日移動平均」の折れ線グラフを作成します。
ここでもPythonとExcelの両方で比較します。

・Python

import matplotlib.pyplot as plt

plt.rcParams['font.family'] = 'Meiryo'        # フォント設定
df = xl("B1:B32", headers=True)               # データ取得
df['移動平均'] = df['売上'].rolling(7).mean()  # 移動平均を計算

# グラフ表示用の設定
fig, ax = plt.subplots()                      
ax.plot(df['日付'], df['売上'], label="売上", marker="o")
ax.plot(df['日付'], df['移動平均'], label="7日移動平均", linestyle="--")
ax.set_title("売上と7日移動平均")
ax.legend() 
plt.xticks(rotation=45) 
plt.tight_layout() 

ややコード量は増えますが、「移動平均」の計算もグラフの描画もすべてPython内で完結します。
グラフの装飾も柔軟に設定可能です。

・Excel

Excelのグラフ機能は直感的で操作しやすいですが、
「移動平均」列を手動で追加する必要があり、操作ミスや調整の手間が発生します。
また、装飾や自由なカスタマイズにも限界があります。

課題と今後の展望

Python in Excel を使うことでデータ操作、グラフ生成などが効率的に行えることがわかりました。
一方で、冒頭で述べたように機能に制限があるため、Excel機能の方が適している場面もあると感じます。
今後、使用可能なライブラリの拡充や、複雑なデータ型への対応が進めば、
さらに活用の幅が広がると考えられます。

さいごに

まだリリースされて間もない機能ですが、今後のアップデート次第では、Excelの主要機能の一つとして定着する可能性も十分あると考えています。
興味があれば導入して使用してみることをおすすめします。

ご覧いただきありがとうございました。

はじめに

システムの内部連携のためにJWTトークンによる認証を行う必要があるとのことで、その導入をおこないました。
その経緯や技術選定の際に考慮した点について共有したいと思います。

そもそもJWTトークンとは?

エンジニアの方ならすでにご存じの方が多いと思います。
ただ、前置きとして簡潔に概要を振り返りたいと思います。

よくあるログインの認証の仕組み

JWT以外の認証だとセッションベースの認証が多いかと思います。
セッションベースはユーザーがログインした場合アプリケーション側がログイン状態を覚えておき、再度サイトに訪れたときは、ログイン処理をスキップするというものです。
ユーザー(ブラウザ)にはアプリケーションから発行されたセッション変数がCookieとして格納され、ユーザーがサイト訪問した際にそのCookieをアプリケーションに渡してもらうことで アプリケーションはそのユーザーがログインした状態なのかをRedisなどのミドルウェアに格納された値を参照してチェックします。

JWTは何が違うか?

セッションベースと大きく異なるのは、アプリケーション側がユーザーのログイン状態を保持しないことです。
どういうことか?
ユーザー(ブラウザ)から渡されたCookieのトークンを検証して、問題なければ認証するというところは同じですが、保持しないという点に注目してください。
まずログイン認証が行われた際アプリケーション側の秘密鍵で生成された「トークン」をユーザーに返します（CookieやHTTPヘッダに格納されるケースが多いです）。
このときアプリケーションはその値をサーバー側に保持しません（ただし、ログアウトや失効管理のために保持する実装もあります）。
次にユーザーが再度訪問した際は、Cookieに格納されたJWTトークンが正常のものかを検証します。
具体的には、JWTトークンに含まれる署名をサーバー側の秘密鍵（または公開鍵）で検証できるため、Redisなどを参照する必要がありません。、Redisなどを参照する必要はないのです。
(もちろん、各システムの実装によりますので参考程度に。)

JWTトークンの構成

3つのパーツからできております。

• ヘッダ
• ペイロード
• 署名

上記要素を下記のように「.」で繋いだものがJWTトークンとなります。
それぞれのパーツが各自base64エンコードされてます。

{hogehoge}.{fugaguga}.{hogefuga}
//ヘッダ    //ペイロード  //署名

ヘッダ
alg: 署名のアルゴリズム
typ: トークンタイプで「JWT」固定
下記jsonをbase64エンコードする

{
  "alg": "HS256",
  "typ": "JWT"
}

署名
上記2つ(ヘッダ&ペイロード)がエンコードされた文字列({xxxx}.{xxxxx})をヘッダのアルゴリズムと秘密鍵で署名し、さらにエンコードを行います。

JWTトークンをLaravelに導入する

ここまででカンの良い方なら分かると思いますが、そこまで複雑ではなく自前で実装できる範囲です。
ただし、JWTはインターネット標準仕様（RFC 7519）で定義されています。
この仕様を遵守できるようにするため、ライブラリ(tymon/jwt-auth)を選択しました。
今回はJWTトークンの生成と検証を実装範囲として、ミドルウェアでの認証への導入までは行いません。

パッケージ導入 & 設定ファイルの生成

composer require tymon/jwt-auth
php artisan vendor:publish --provider="PHPOpenSourceSaver\JWTAuth\Providers\LaravelServiceProvider"
php artisan jwt:secret
# .envにJWT_SECRETが生成されます。config/jwt.phpを編集すれば別の環境変数に設定することも可能です。

サンプルコード

JWTトークンの生成

    public function create(array $param): string
    {
        try {
            $customClaims = [
                'param01' => $param[0],
                'param02' => $param[1],
            ];

            $payload = JWTFactory::customClaims($customClaims)->make();
            $manager = $this->jwtAuth->manager();
            return $manager->encode($payload);

        } catch (\Exception $e) {
            // エラーハンドリング
        }
    }

JWTトークンの検証 ※booleanで判定結果を返す

    public function verify(
        string $token,
        array $param
    ): bool {
        try {
            $payload = $this->jwtAuth->setToken($token)->getPayload();

            if ((int) $payload->get('param01') !== $param[0]) {
                // 値が一致しない場合は無効とみなす
                return false;
            }
            if ((int) $payload->get('param02') !== $param[1]) {
                // 値が一致しない場合は無効とみなす
                return false;
            }

            return true;
        } catch (\Exception $e) {
            // エラーハンドリング
        }
    }

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には以下のような特徴があります。

• React単体では難しい、ルーティングの機能を搭載している
• CSR/SSR/SSGをページごとに柔軟に使い分けることができる。
• プリレンダリングによって表示速度やSEOのメリットを得ることができる。
• SSGによって静的ファイルを生成すれば、Node.jsがない環境でもサイトを公開できる。

興味のある方はぜひご自身でもNext.jsを触ってみてください✨️
この記事を読んでなにか皆さんの役に立てると嬉しいです..!

では!