MENU

Azure FunctionsでPowerShell 7.6を試す方法｜ローカル開発からPreview環境へのデプロイ手順

Azure

Azure FunctionsでPowerShell 7.6を実行するには、Windows環境でローカルプロジェクトを作成し、Azure側もWindowsのConsumption、Premium、またはDedicatedプランを選択する必要があります。ローカルでは.NET 10とAzure Functions Core Tools v4を用意し、local.settings.jsonにPowerShell 7.6を明示します。Azure側では、Function AppのpowerShellVersionを7.6に設定してからデプロイします。

PowerShell 7.6のAzure Functions対応はPublic Previewです。Microsoftの定義上、Previewは非本番環境での利用とテストを目的とする段階であり、本番システムへ直接適用するのではなく、独立した検証用Function Appで試すのが基本です。(Microsoft Learn)

ITtripTOOLS
その「面倒」、無料で解決。 ITtripがつくる、6つの道具。 無料ツール一覧へ すべて無料・追加課金なし
先頭0を守るCSV編集こわさないCSV PDFに直接書き込みかけるPDF 写真＋説明をPDFに写レポ スマホ⇄PCで共有コピペ便 · 文章・写真 みんなの日程を調整日程Fit 匿名質問・投票を集めるKOEQ
目次

Azure FunctionsにおけるPowerShell 7.6の対応条件

PowerShell 7.6を試す前に、対応するランタイム、OS、ホスティングプランを確認しておきましょう。

項目PowerShell 7.6の条件実務上の判断
サポート状態Public Preview非本番環境で検証する
Azure FunctionsランタイムFunctions 4.xFUNCTIONS_EXTENSION_VERSIONを~4にする
必要な.NET.NET 10ローカルに.NET 10 SDKまたはRuntimeを用意する
OSWindowsのみLinuxのFunction Appにはデプロイしない
対応プランWindows Consumption、Premium、Dedicated小規模な検証ならWindows Consumptionが扱いやすい
ローカルツールAzure Functions Core Tools v4Azure Functions CLI v5は使用しない
比較対象PowerShell 7.4はGA、.NET 8Previewを許容できない場合の選択肢

Microsoft公式ドキュメントでは、PowerShell 7.6はFunctions 4.x上で動作し、.NET 10を必要とします。また、対応先はWindowsのPremium、Dedicated、Consumptionプランに限られます。PowerShell 7.4はGAですが、PowerShell 7.6はPreviewとして扱われています。(Microsoft Learn)

重要: 一般的なAzure Functionsの最新クイックスタートでは、LinuxのFlex Consumptionプランを作成する手順が案内されることがあります。しかし、PowerShell 7.6 PreviewはWindows専用です。本手順では--flexconsumption-locationではなく、Windows Consumptionを作成する--consumption-plan-locationを使用します。(Microsoft Learn)

Linux Consumptionで利用できるPowerShellは7.4までです。PowerShell 7.6を試すために、既存のLinux Function Appの設定だけを変更しても対応環境にはなりません。Windows Function Appを別途作成してください。(Microsoft Learn)

今回作成する検証環境

本記事では、次の構成でPowerShell 7.6を検証します。

領域構成
ローカルOSWindows
ローカルPowerShellPowerShell 7.6
ローカル.NET.NET 10
Functions開発ツールAzure Functions Core Tools v4
Azureリソース新規の検証用リソースグループ
ホスティングプランWindows Consumption
Functionsランタイム4.x
PowerShellランタイム7.6 Preview
トリガーHTTPトリガー
認証レベルFunctionキー

既存の本番Function Appを7.6へ切り替えるのではなく、新しいFunction Appを作成します。これにより、ランタイム変更、モジュール互換性、JSON出力などに問題があっても、本番処理へ影響させずに検証できます。

PowerShell 7.6対応のローカル環境を準備する

PowerShell 7.6と.NET 10をインストールする

Windows TerminalまたはPowerShellを開き、PowerShellと.NET 10 SDKをインストールします。

winget install --id Microsoft.PowerShell --source winget
winget install Microsoft.DotNet.SDK.10

PowerShellパッケージの最新版が将来7.6以外になる可能性もあるため、インストール後は必ず実際のバージョンを確認してください。7.6以外が表示された場合は、winget show --id Microsoft.PowerShell --versionsで利用可能な7.6系を確認し、--versionを付けてインストールします。

.NET SDKには対応する.NET Runtimeも含まれるため、SDKをインストールすれば別途同じバージョンのRuntimeを入れる必要はありません。(Microsoft Learn)

Azure CLIをインストールする

Azureリソースの作成と設定にはAzure CLIを使用します。

winget install --exact --id Microsoft.AzureCLI

インストール直後は、開いているターミナルをいったん閉じてから再度起動します。Azure CLIはPATHの更新を反映するため、ターミナルの再起動が必要になる場合があります。(Microsoft Learn)

Azure Functions Core Tools v4をインストールする

Node.jsとnpmを利用している環境では、次のコマンドでCore Tools v4をインストールできます。

npm i -g azure-functions-core-tools@4 --unsafe-perm true

Node.jsを利用しない場合は、Microsoftが提供する64ビット版MSIを使用します。MSI版とnpm版を同時にインストールすると、PATH上で古いfunc.exeが優先されることがあります。どちらか一方に統一してください。(Microsoft Learn)

Azure Functions CLI v5はPreviewであり、現時点ではPowerShellをサポートしていません。PowerShell Functionsのローカル開発には、引き続きCore Tools v4を使用します。(Microsoft Learn)

インストール結果を確認する

新しくPowerShell 7.6を起動し、各ツールを確認します。

$PSVersionTable.PSVersion
dotnet --list-sdks
dotnet --list-runtimes
func --version
where.exe func
az version

確認するポイントは次のとおりです。

  • $PSVersionTable.PSVersionが7.6.x
  • .NET SDKまたはRuntimeの一覧に10.0.x
  • func --versionが4.x
  • where.exe funcで意図したCore Toolsが選ばれている
  • az versionが正常に表示される

where.exe funcにMSI版とnpm版の複数パスが表示される場合は、使わない方をアンインストールしてからターミナルを再起動します。

PowerShell 7.6のFunctionプロジェクトを作成する

HTTPトリガーを作成する

作業用フォルダーを作成し、PowerShellのFunctionプロジェクトとHTTPトリガーを生成します。

New-Item -ItemType Directory -Path .\func-ps76-preview | Out-Null
Set-Location .\func-ps76-preview

func init --worker-runtime powershell

func new `
  --name HttpExample `
  --template "HTTP trigger" `
  --authlevel "function"

func initによってプロジェクト共通のhost.jsonやlocal.settings.jsonが作成され、func newによってHttpExampleフォルダー、run.ps1、function.jsonが追加されます。(Microsoft Learn)

作成後の主な構成は次のようになります。

func-ps76-preview
├─ HttpExample
│  ├─ function.json
│  └─ run.ps1
├─ host.json
├─ local.settings.json
├─ profile.ps1
└─ requirements.psd1

local.settings.jsonでPowerShell 7.6を指定する

local.settings.jsonを開き、FUNCTIONS_WORKER_RUNTIME_VERSIONに7.6を設定します。

{
  "IsEncrypted": false,
  "Values": {
    "AzureWebJobsStorage": "",
    "FUNCTIONS_WORKER_RUNTIME": "powershell",
    "FUNCTIONS_WORKER_RUNTIME_VERSION": "7.6"
  }
}

ここでは、"~7"ではなく"7.6"と明示することが重要です。PowerShell Functionsでは~7が7.0系を意味し、7.4や7.6へ自動的に切り替わる設定ではありません。PowerShell 7.6を選ぶ場合は、メジャー番号とマイナー番号の両方を指定します。(Microsoft Learn)

今回のような単純なHTTPトリガーでは、ローカルのAzureWebJobsStorageを空にしたまま検証できます。Queue、Blob、Durable Functionsなど、Storageを利用するトリガーやバインディングを試す場合は、Azuriteを起動して次のように変更します。

"AzureWebJobsStorage": "UseDevelopmentStorage=true"

local.settings.jsonには接続文字列やAPIキーが入る可能性があります。通常は.gitignoreで除外されますが、リポジトリへコミットされていないことを必ず確認してください。(Microsoft Learn)

実際のランタイムを返す関数に変更する

PowerShell 7.6と.NET 10で実行されていることを確認できるように、HttpExample/run.ps1を次の内容へ置き換えます。

using namespace System.Net

param($Request, $TriggerMetadata)

$body = [ordered]@{
    message           = "Azure Functions PowerShell runtime check"
    powershellVersion = $PSVersionTable.PSVersion.ToString()
    psEdition         = $PSVersionTable.PSEdition
    dotnetVersion     = [System.Runtime.InteropServices.RuntimeInformation]::FrameworkDescription
    operatingSystem   = [System.Runtime.InteropServices.RuntimeInformation]::OSDescription
} | ConvertTo-Json

Push-OutputBinding -Name Response -Value ([HttpResponseContext]@{
    StatusCode = [HttpStatusCode]::OK
    Headers    = @{
        "Content-Type" = "application/json; charset=utf-8"
    }
    Body       = $body
})

Azure Functionsでは、設定画面に表示されるバージョンだけでなく、関数内から$PSVersionTableを出力することで実際のPowerShellバージョンを確認できます。(Microsoft Learn)

この診断用レスポンスは、検証が完了したら削除してください。ランタイムやOSの詳細を恒常的に外部へ返す設計は避けます。

PowerShell 7.6のFunctionをローカル実行する

プロジェクトのルート、つまりhost.jsonがあるフォルダーで次のコマンドを実行します。

func start

正常に起動すると、HTTPトリガーのURLが表示されます。

HttpExample: [GET,POST] http://localhost:7071/api/HttpExample

別のPowerShellターミナルから呼び出します。

Invoke-RestMethod `
  -Uri "http://localhost:7071/api/HttpExample" `
  -Method Get |
  ConvertTo-Json

出力は次のようになります。パッチ番号はインストールされているワーカーによって異なります。

{
  "message": "Azure Functions PowerShell runtime check",
  "powershellVersion": "7.6.x",
  "psEdition": "Core",
  "dotnetVersion": ".NET 10.0.x",
  "operatingSystem": "Microsoft Windows ..."
}

func startは、ローカルのFunctionsホストを起動する基本コマンドです。(Microsoft Learn)

powershellVersionが7.4になっている場合は、次の順番で確認します。

  1. local.settings.jsonのキー名に誤字がないか
  2. 値が7.6になっているか
  3. func startを実行していたプロセスを再起動したか
  4. func --versionが4.xか
  5. where.exe funcで古いCore Toolsが選ばれていないか
  6. .NET 10がインストールされているか

AzureにWindowsのFunction Appを作成する

サインイン先のサブスクリプションを確認する

Azure CLIでサインインし、使用するサブスクリプションを明示します。

az login
az account show -o table

az account set `
  --subscription "<サブスクリプション名またはID>"

複数のAzureテナントやサブスクリプションを利用している場合は、リソース作成前にaz account showで対象を確認してください。

対応リージョンとランタイムを確認する

Windows Consumptionを作成できるリージョンを確認します。

az functionapp list-consumption-locations -o table

続いて、Azure CLIが認識しているWindows向けランタイムを確認します。

az functionapp list-runtimes `
  --os-type windows `
  -o table

az functionapp list-runtimesは、Function App作成時に指定できるランタイムとバージョンを確認するためのコマンドです。Previewの展開状況やAzure CLIのバージョンによって表示が異なる可能性があるため、作成前に確認するのが安全です。(Microsoft Learn)

リソース名を準備する

以下ではjapaneastを例にしています。先ほどのリージョン一覧に表示されない場合は、利用可能なリージョンへ変更してください。

$location = "japaneast"
$suffix   = ([guid]::NewGuid().ToString("N")).Substring(0, 8)

$rg      = "rg-func-ps76-preview"
$storage = "stfuncps76$suffix"
$app     = "func-ps76-$suffix"

$rg
$storage
$app

ストレージアカウント名には小文字英数字のみを使用でき、Azure全体で一意でなければなりません。Function App名も既定のホスト名に使われるため、一意である必要があります。

リソースグループとストレージアカウントを作成する

az group create `
  --name $rg `
  --location $location

az storage account create `
  --name $storage `
  --resource-group $rg `
  --location $location `
  --sku Standard_LRS `
  --allow-blob-public-access false

本番環境では、ストレージへの接続にマネージドIDを使用する構成も検討すべきです。ただし、今回はPowerShell 7.6 Previewの動作確認に目的を絞り、検証終了後にリソースグループごと削除できる構成とします。

Windows ConsumptionのFunction Appを作成する

次のコマンドでは、--os-type Windowsと--consumption-plan-locationを明示しています。

az functionapp create `
  --name $app `
  --resource-group $rg `
  --storage-account $storage `
  --consumption-plan-location $location `
  --os-type Windows `
  --runtime powershell `
  --functions-version 4 `
  --https-only true

--functions-version 4はAzure Functionsランタイム4.x、--runtime powershellは言語ワーカーとしてPowerShellを選択する指定です。--https-only trueを付けると、HTTPアクセスがHTTPSへリダイレクトされます。(Microsoft Learn)

ここではFunction Appの作成とPowerShell 7.6への切り替えを分けています。これにより、Azure CLIのFunction App作成処理がPreview版の--runtime-version 7.6をまだ受け付けない環境でも、既存のPowerShell Function Appを作成した後にサイト設定を変更できます。

Azure側のランタイムをPowerShell 7.6へ変更する

Functions 4.xとPowerShellワーカーを確認する

作成時に設定されますが、検証環境では値を明示しておくと構成を確認しやすくなります。

az functionapp config appsettings set `
  --name $app `
  --resource-group $rg `
  --settings `
    "FUNCTIONS_WORKER_RUNTIME=powershell" `
    "FUNCTIONS_EXTENSION_VERSION=~4"

powerShellVersionを7.6に変更する

Azure側のPowerShellバージョンは、Function Appのサイト構成にあるpowerShellVersionで選択します。

az functionapp config set `
  --name $app `
  --resource-group $rg `
  --powershell-version 7.6

Azure CLIのaz functionapp config setには、PowerShell Function Appの実行バージョンを設定する--powershell-versionオプションがあります。設定変更後はFunction Appが再起動します。(Microsoft Learn)

Azureポータルから設定する場合は、Function Appを開き、次の順番で操作します。

  1. Settings
  2. Configuration
  3. General settings
  4. PowerShell version
  5. 7.6
  6. Save

保存するとFunction Appが再起動します。(Microsoft Learn)

Azure側の設定値を確認する

az functionapp config show `
  --name $app `
  --resource-group $rg `
  --query "{powerShellVersion:powerShellVersion}" `
  -o table

期待する表示は次のとおりです。

PowerShellVersion
-----------------
7.6

アプリケーション設定も確認します。

az functionapp config appsettings list `
  --name $app `
  --resource-group $rg `
  -o table

少なくとも次の値を確認してください。

FUNCTIONS_WORKER_RUNTIME      powershell
FUNCTIONS_EXTENSION_VERSION  ~4

ローカルとAzureではバージョン設定の場所が異なる

PowerShell 7.6の設定で最も間違えやすいのは、ローカルとAzureで設定箇所が異なる点です。

実行場所PowerShell 7.6の指定方法
ローカルlocal.settings.jsonのFUNCTIONS_WORKER_RUNTIME_VERSION
AzureFunction Appのサイト構成powerShellVersion

local.settings.jsonはローカル実行用のファイルです。通常のデプロイでは、その内容が自動的にAzure側のアプリケーション設定へ反映されるわけではありません。(Microsoft Learn)

そのため、Azure側で次の設定だけを追加しても、確実なランタイム切り替えにはなりません。

FUNCTIONS_WORKER_RUNTIME_VERSION=7.6

Azure上では、az functionapp config set --powershell-version 7.6またはポータルのPowerShell version設定を使用してください。

PowerShell 7.6のFunctionをAzureへデプロイする

プロジェクトのルートフォルダーで、次のコマンドを実行します。

func azure functionapp publish $app

func azure functionapp publishは、現在のFunctionsプロジェクトを既存のFunction Appへデプロイします。別のFunction App名を指定すると意図しない環境を上書きする可能性があるため、実行前に$appの値を確認してください。(Microsoft Learn)

$app
az account show -o table

デプロイが成功すると、出力に次のような情報が表示されます。

Deployment successful.
Syncing triggers...
Functions in func-ps76-xxxxxxxx:
    HttpExample - [httpTrigger]

Functionキーを含むURLを取得する

今回のHTTPトリガーはauthlevelをfunctionにしているため、Azure上ではFunctionキーが必要です。

func azure functionapp list-functions `
  $app `
  --show-keys

出力されるURLは次のような形式です。

https://func-ps76-xxxxxxxx.azurewebsites.net/api/HttpExample?code=...

Core Toolsのlist-functionsコマンドでは、--show-keysを付けることでFunctionキーを含む呼び出しURLを取得できます。(Microsoft Learn)

Azure上で実際のランタイムを確認する

取得したURLを使って関数を呼び出します。

$endpoint = "<Functionキーを含むURL>"

Invoke-RestMethod `
  -Uri $endpoint `
  -Method Get |
  ConvertTo-Json

次の内容が確認できれば、PowerShell 7.6 Preview環境へのデプロイは完了です。

{
  "message": "Azure Functions PowerShell runtime check",
  "powershellVersion": "7.6.x",
  "psEdition": "Core",
  "dotnetVersion": ".NET 10.0.x",
  "operatingSystem": "Microsoft Windows ..."
}

デプロイ後は3段階で確認する

設定画面に7.6と表示されるだけでは、デプロイ結果の確認としては不十分です。次の3段階を確認します。

確認段階確認方法成功条件
構成az functionapp config showpowerShellVersionが7.6
関数の登録func azure functionapp list-functionsHttpExampleが表示される
実行HTTPエンドポイントを呼び出すPowerShell 7.6、.NET 10、Windowsが返る

この確認方法なら、「設定変更は成功したが関数が登録されていない」「関数は登録されたが古いランタイムで動いている」といった問題を切り分けられます。

PowerShell 7.6で失敗するときの確認ポイント

症状主な原因対処
funcでPowerShellプロジェクトを作れないAzure Functions CLI v5を使用しているCore Tools v4をインストールし、where.exe funcを確認する
ローカル実行がPowerShell 7.4になるFUNCTIONS_WORKER_RUNTIME_VERSIONがない、または~7になっている値を7.6に変更し、func startを再起動する
.NET関連のエラーで起動しない.NET 10が未導入dotnet --list-runtimesを確認し、.NET 10 SDKをインストールする
Function App作成時に7.6を受け付けない作成コマンドのPreviewランタイム情報が未反映--runtime-version 7.6を外して作成し、後から--powershell-version 7.6を設定する
ポータルに7.6が表示されないAzure CLIやポータル表示、リージョン展開の差Azure CLIを更新し、Windows対応リージョンとlist-runtimesを確認する
Azureで401になるFunctionキーを付けていないlist-functions --show-keysで取得したURLを使う
Azureで404になるURLや関数名が違う、関数が登録されていないlist-functionsで実際のURLを確認する
デプロイ後に関数が表示されないhost.jsonのない階層からデプロイしたプロジェクトルートへ移動して再デプロイする
モジュール読み込みで500になるPowerShell 7.6または.NET 10との互換性問題requirements.psd1の依存関係を確認し、モジュールを個別に検証する
ローカルでは動くがAzureで失敗するローカル設定がAzureへ反映されていないAzure側のアプリケーション設定とサイト構成を個別に確認する

Core Tools v5はPowerShellをまだサポートしていないため、func --versionが5.xの場合は最初にツールを入れ替えます。(Microsoft Learn)

また、Functions 4.xの既存プロジェクトを移行する場合は、host.jsonのExtension Bundleが古くないか確認します。現行の推奨範囲は次の形式です。

{
  "version": "2.0",
  "extensionBundle": {
    "id": "Microsoft.Azure.Functions.ExtensionBundle",
    "version": "[4.0.0, 5.0.0)"
  }
}

古いExtension Bundleを使用したままランタイムだけを変更すると、トリガーやバインディングの読み込みで問題が発生する可能性があります。(Microsoft Learn)

Preview環境で重点的に検証する項目

PowerShellモジュールの互換性

PowerShell Functionsでは、requirements.psd1によるManaged Dependenciesか、プロジェクト内のModulesフォルダーへモジュールを同梱する方法を利用できます。(Microsoft Learn)

PowerShell 7.6へ移行するときは、少なくとも次を確認します。

  • requirements.psd1で指定したモジュールをすべてImportできるか
  • バイナリモジュールが.NET 10上で動作するか
  • profile.ps1がコールドスタート時にエラーにならないか
  • Azureへの認証処理が従来どおり動作するか
  • モジュール更新後も入力値と出力値の形式が変わらないか

Preview検証中は、依存モジュールのバージョン範囲を広くしすぎない方が再現性を保ちやすくなります。ローカルとAzureで同じrequirements.psd1を使い、検証結果と使用したモジュールバージョンを記録してください。

JSON出力とThreadJobを使う処理

Azure Functions PowerShell Workerの公式リポジトリでは、PowerShell 7.6で影響する可能性がある項目として、JSONシリアライズの変更やThreadJob関連の変更が調査されています。これらを利用する関数では、単に「エラーが出ない」ことだけでなく、戻り値の型やJSONの値が従来と一致するかも確認します。(GitHub)

特にAPIとして利用しているFunctionでは、次の比較が重要です。

  • プロパティ名
  • 数値が文字列へ変わっていないか
  • 大きな整数の表現
  • 日付とタイムゾーン
  • 配列が単一要素になった場合の形式
  • nullと空文字列の扱い
  • HTTPステータスコードとレスポンスヘッダー

PowerShell 7.4環境と7.6環境へ同じテストデータを送り、レスポンスを差分比較すると変更を見つけやすくなります。

タイマーやStorageトリガーも実環境で確認する

HTTPトリガーだけで正常に動作しても、Timer、Queue、Blob、Service Bus、Event Hubなどのトリガーが同じように動くとは限りません。

実際に移行予定のFunction Appで使っているトリガーごとに、次を確認します。

  • トリガーが正しく登録されるか
  • 入力バインディングが期待する型で渡されるか
  • 出力バインディングへ書き込めるか
  • リトライ処理が機能するか
  • Application Insightsへ例外が記録されるか
  • コールドスタート後の初回実行に失敗しないか

PowerShell 7.4へ戻す方法

PowerShell 7.6で互換性問題が見つかった場合は、検証用Function Appを7.4へ戻せます。

az functionapp config set `
  --name $app `
  --resource-group $rg `
  --powershell-version 7.4

設定を確認します。

az functionapp config show `
  --name $app `
  --resource-group $rg `
  --query "powerShellVersion" `
  -o tsv

ランタイム変更だけでなく、PowerShell 7.4で動作確認済みのコードとrequirements.psd1も再デプロイします。

func azure functionapp publish $app

PowerShellバージョンを変更するとFunction Appは再起動します。また、バージョン変更に伴って破壊的変更が入る可能性があるため、Microsoftも移行前の互換性確認を推奨しています。(Microsoft Learn)

検証後にAzureリソースを削除する

検証が完了し、リソースを残す必要がなければ、リソースグループごと削除します。

az group delete `
  --name $rg `
  --yes

この操作により、Function App、ストレージアカウント、Application Insightsなど、リソースグループ内のリソースがまとめて削除されます。削除前に、必要なログや検証結果を保存してください。(Microsoft Learn)

PowerShell 7.6を試すときの最終チェック

Azure FunctionsでPowerShell 7.6を検証する流れは、次の順番で進めます。

  1. WindowsにPowerShell 7.6と.NET 10を用意する
  2. Azure Functions Core Tools v4を使用する
  3. local.settings.jsonにFUNCTIONS_WORKER_RUNTIME_VERSION=7.6を設定する
  4. $PSVersionTableを返す関数をローカルで実行する
  5. Windows Consumption、Premium、またはDedicatedの検証用Function Appを作成する
  6. Functionsランタイムを4.xにする
  7. Azure側のpowerShellVersionを7.6にする
  8. func azure functionapp publishでデプロイする
  9. 設定、関数登録、実際の実行結果の3段階で確認する
  10. 問題があればPowerShell 7.4へ戻すか、検証用リソースを削除する

最初に取り組むべきなのは、本番コードの移行ではありません。まず独立したWindows Function Appへ診断用HTTPトリガーをデプロイし、PowerShell 7.6、.NET 10、Windowsの組み合わせで実行できることを確認します。その後、実際に使用しているモジュール、トリガー、JSON入出力を段階的に追加することで、Previewランタイム固有の問題を切り分けやすくなります。

Azure
Azure Functions Azure CLI PowerShell 7.6 Azure Functions Core Tools

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次