不安だ

Windows Defender フルスキャンが使用不可になる原因と対処法｜実行できない時の確認ポイント

2026-10-04T23:47:31.946+09:00

Windows Defenderでフルスキャンを実行しようとしたところ、「使用不可」と表示されたり、フルスキャンを選択できなかったりして困っていませんか？

パソコンがウイルスに感染していないか確認したい時にフルスキャンが利用できないと、不安になります。

私も以前、「最後に実行したスキャン使用不可」という表示について調べたことがありましたが、Windows Defenderでは設定や状態によってスキャン機能が正常に利用できなくなることがあります。

この記事では、Windows Defenderのフルスキャンが使用不可になる主な原因と対処法をまとめます。

フルスキャンが使用不可になる主な原因

原因1：Windows Securityアプリの一時的な不具合

Windows Security（Windows セキュリティ）はWindows Updateや定義ファイル更新の影響で、一時的に正常な状態を表示できなくなることがあります。

症状としては、

・フルスキャンのボタンが押せない

・スキャンオプションが表示されない

・「使用不可」と表示される

といったケースがあります。

まずはパソコンを再起動し、再度Windows Securityを開いて確認してみましょう。

原因2：Microsoft Defender関連サービスが停止している

Windows Defenderは複数のサービスによって動作しています。

何らかの理由でサービスが停止している場合、スキャン機能が正常に利用できなくなることがあります。

確認方法

1. Windowsキー＋R

2. services.msc を入力

3. Microsoft Defender関連サービスを確認

通常は自動起動になっています。

原因3：他社製セキュリティソフトとの競合

Norton、ウイルスバスター、ESETなどのセキュリティソフトをインストールしている場合、Microsoft Defenderが自動的に無効化されることがあります。

その結果、

・クイックスキャンが使えない

・フルスキャンが選択できない

・Windows Securityの一部機能が利用できない

という状態になる場合があります。

まずは現在どのセキュリティソフトが有効になっているか確認してみましょう。

原因4：別のスキャンが実行中

実はユーザーが気付かないうちにスキャンが実行されているケースがあります。

例えば、

・定期スキャン

・定義ファイル更新後の自動スキャン

・バックグラウンドスキャン

などです。

この場合、一時的にフルスキャンが選択できなくなることがあります。

数分待ってから再度確認してみましょう。

原因5：Windows Updateや定義ファイルが古い

Windows Defenderは最新の定義ファイルを利用して動作しています。

更新が失敗している場合、スキャン機能に影響が出ることがあります。

確認方法

設定

↓

Windows Update

↓

更新プログラムの確認

最新状態まで更新した後、再起動して再度試してみてください。

原因6：スキャンが途中で中断された

フルスキャンはパソコン内のすべてのファイルを確認するため、環境によっては数十分から数時間かかることがあります。

途中で

・再起動

・強制終了

・スリープ

などが発生すると正常に完了できない場合があります。

フルスキャン実行中は電源設定にも注意しましょう。

まず試したい対処法

フルスキャンが使用不可になった場合は、次の順番で確認することをおすすめします。

1. パソコンを再起動する

2. Windows Updateを実行する

3. Defenderの定義ファイルを更新する

4. 他社製セキュリティソフトを確認する

5. 数分待って再度確認する

多くの場合はこれだけで改善することがあります。

原因7：実はフルスキャンが完了していた、または別スキャンと見間違えていた

私が調査した際に気一番になったのは、「Windows Securityの画面だけで判断して良いのか」という点でした。

会社PCでは毎日クイックスキャンが実行される設定になっており、フルスキャン実行後にクイックスキャンが動作していた可能性があります。

その場合、

・フルスキャンは正常完了

・その後クイックスキャン実行

という流れだったとしても、Windows Security画面だけでは正確な実行履歴を判断しづらい場合があります。

実際、Microsoft Defenderではイベントログにスキャン開始・完了・中断が記録されます。

確認方法

イベントビューアー

↓

アプリケーションとサービスログ

↓

Microsoft

↓

Windows

↓

Windows Defender

↓

Operational

ここで以下のイベントを確認できます。

・1000：スキャン開始

・1001：スキャン完了

・1002：スキャン中断

さらにイベント詳細には、

・クイックスキャン

・フルスキャン

などのスキャン種別も記録されます。

そのため、

「フルスキャンが使用不可になった」

と思った場合でも、

まずはイベントログで

1000 → 1001

が記録されていないか確認することをおすすめします。

Windows Securityの画面だけではなく、イベントログまで確認することで、実際には正常終了していたケースや、途中でキャンセルされたケースを切り分けできます。

まとめ

Windows Defenderのフルスキャンが使用不可になる原因としては、

・Windows Securityの一時的不具合

・Defenderサービス停止

・他社製セキュリティソフトとの競合

・別スキャンの実行中

・Windows Update未適用

・スキャン中断

などが考えられます。

まずは再起動とWindows Updateを試し、それでも改善しない場合はサービス状態やセキュリティソフトの競合を確認してみてください。

現在の脅威はありません。最後に実行したスキャン：使用不可

脅威のサービスが停止しました。今すぐ再起動してください。

親のLINE引き継ぎができない理由｜高齢者サポートで分かった5つの落とし穴

2026-09-16T23:57:04.870+09:00

先日、実家の父と母のスマホ機種変更を遠隔サポートしていました。

若い人なら30分もあれば終わるようなLINEの引き継ぎ作業。

ところが、何時間もかかります。

最初は、

「スマホの操作に慣れていないから」

だと思っていました。

でも何度もサポートしていて気づいたのです。

高齢者がLINEの引き継ぎで困る本当の理由は、スマホ操作そのものではありません。

本人確認の仕組みが分からないのです。

例えばLINEの引き継ぎ。

現在は、

・SMS認証

・メール認証

・QRコード認証

・Apple ID認証

・Googleアカウント認証

など、複数の方法があります。LINE公式ヘルプでも、状況によって認証方法が分かれています。 (LINEヘルプセンター)

私たちは、

「本人しか操作できないようにしているんだな」

と自然に理解できます。

だから、

SMSが届く

↓

本人確認

メールにURLが届く

↓

本人確認

QRコードを読む

↓

旧端末を持っている本人確認

という流れが分かります。

しかし親世代は違います。

なぜSMSが届くのか。

なぜメールのURLを押すのか。

なぜQRコードを読むのか。

そもそも何を確認されているのか。

そこが分かりません。

だから画面に表示される指示が理解できないのです。

もっと分かりやすい例があります。

機種変更中、突然こんな画面が表示されました。

「パスワードを入力」

すると父は聞きます。

「どのパスワード？」

確かに考えてみると当然です。

スマホにはたくさんのパスワードがあります。

・スマホの画面ロック解除番号

・Apple IDのパスワード

・Googleアカウントのパスワード

・LINEのパスワード

・メールのパスワード

私たちは画面の雰囲気や前後の流れから、

「ああ、これはiPhoneのロック解除だな」

「ああ、これはGoogleアカウントだな」

と推測しています。

でも初めて見る人には、

「パスワードを入力してください」

だけでは何のことか分からないのです。

実際、LINEヘルプでも「画面ロック解除を求められた場合はLINEのパスワードではなく端末のパスコードや生体認証を使用する」と説明されています。つまり同じ”パスワード”でも意味が違います。 (LINEヘルプセンター)

私は今回の件で、

高齢者はスマホが使えないのではなく、

スマホの中で行われている本人確認の仕組みが見えていないのだと感じました。

だから親のスマホサポートでは、

「何を押してください」

ではなく、

「今は本人確認をしています」

「これはスマホの持ち主か確認しています」

と理由から説明した方がうまくいきます。

そして何より大切なのは、

『そんなことも分からないの？』

と思わないこと。

私たちが当たり前だと思っている認証の仕組みは、実は長年スマホを使ってきた経験によって身についた知識なのですから。

親のスマホ相談あるある。「押してない」はだいたい押してる

2026-09-16T23:34:28.701+09:00

離れて暮らす親のスマホサポートをしていると、たまに予想の斜め上を行く出来事が起こります。

先日、父からこんなLINEが届きました。

「どこかに触れたためか、突然ロックされました。アプリが画面に表示されていません。今、画面に表示されているのは、緊急通報、パスワードを入力、です。ロック解除方法を教えて下さい。」

どうやらスマホが壊れたと思っている様子。

私は返信しました。

「多分、電源ボタン長押しとかしたのかも。スマホに設定しているパスワードはある？それを入れたらどうかな」

すると父から返事。

「ダメみたい。電話のキーボードが出て、どこかに通報するようになっている。」

嫌な予感がしました。

画面の写真を送ってもらうと、確かに緊急通報のダイヤル画面。

これはロック画面から緊急通報に入ってしまっている状態です。

「一度戻ってみて」

と伝えると、再びパスワード入力画面へ。

私は聞きました。

「ここでパスワード入れたらどうなる？」

父。

「さっきの電話キーボードの画面になる。」

おかしい。

パスワードを入れれば普通はロック解除されるはず。

何か話が噛み合っていない。

私はさらに聞きました。

「ああ、パスワードを入力したあと、緊急通報ボタン押した？」

父。

「通報ボタンは押してない。」

なるほど。

押していないのか。

では別の原因かもしれない。

そう思いながら送られてきた画面をもう一度確認。

画面には、

・パスワード入力欄

・緊急通報ボタン

しかありません。

そこで私は聞きました。

「パスワード入力したあと、決定するとき何を押したの？」

父。

「緊急通報。」

私。

「緊急通報押してるじゃん！」

どうやら父は、

パスワードを入力

↓

決定ボタンが見当たらない

↓

画面にある唯一のボタンを押す

↓

緊急通報画面になる

↓

『どこかに通報されそうだ！』

という流れだったようです。

本人の中では、

「通報するつもりはなかった」

ので、

「通報ボタンは押していない」

という認識だったのでしょう。

確かに気持ちは分かります。

でも押したのは事実です。

離れて暮らす親のスマホサポートをしていると、技術知識よりも事情聴取能力が鍛えられます。

「何を押した？」

「押してない」

「本当に？」

「押してない」

「その後どうなった？」

「そのボタンを押したら変な画面になった」

「そのボタンって何？」

「緊急通報」

犯人は最初から現場にいました。

親のスマホ相談は、サポートというより推理ゲームなのかもしれません。

遠方の70代の親のスマホ設定をLINEだけでサポートした話

2026-09-16T08:42:47.785+09:00

先日、70代の父がスマホを機種変更した。

実家は離れているため、私は現地に行くことができない。

電話をしながら設定を進めることになったが、すぐに限界を感じた。

「画面の右上にあるボタンを押して」

そう伝えても、

「どれ？」

となる。

こちらには画面が見えない。

父には見えている。

しかし同じ画面を見ていない以上、言葉だけで説明するのは難しい。

そこで父に画面の写真を撮ってLINEで送ってもらった。

すると状況が一気に分かるようになった。

私は送られてきた画面をスマホで編集し、

押してほしいボタンを赤線で囲んだ。

そしてその画像をLINEで送り返した。

「この赤で囲ったところを押してみて」

すると父も迷わない。

言葉で説明するより何倍も早かった。

今回のサポートで気付いたのは、高齢者がスマホを使えないのではないということだ。

父はLINEで写真を送れる。

テレビ電話もできる。

メッセージも送れる。

しかし設定画面になると、どのボタンを押せば良いのか判断できなくなる。

これは能力の問題ではなく経験の問題だと思う。

若い世代は何百回も見ている設定画面だが、高齢者は数年に一度しか触れない。

だから迷うのは当然だ。

遠方の親のスマホサポートで私が一番効果的だと思った方法は、

「電話で説明する」

ではなく、

「画面を送ってもらう」

ことだった。

さらに、

「押してほしい場所を赤線で囲んで送り返す」

これだけで解決できることが驚くほど多い。

もし離れて暮らす親のスマホサポートで困っているなら、一度試してみてほしい。

電話で10分説明するより、赤丸を付けた画像1枚の方が伝わることがある。

ちなみに緊急通報画面になったときに、戻れない、となった時は焦った。なにか変なところに掛けてしまわないか。

ちなみにその時は以下の画面で無事解決。考えてみると、これが戻るボタンとは初見だときついかも。

iPhone7からAndroidへLINE引き継ぎできない原因｜古いiOSとLINE仕様変更に注意

2026-09-12T01:58:31.874+09:00

はじめに

親のスマホ乗り換え（旧型のiPhone 7から新しいAndroidスマホ）に伴い、LINEの引き継ぎサポートを実施しました。「直近14日間のトークは自動移行できる」「QRコードを使えば一発」と思って進めたものの、旧端末のOSサポート終了やアプリのバージョン制限、登録情報の不足が重なり、画面がループして引き継ぎが完了できない事態となりました。

同じように「親の古いiPhoneから新しいAndroidスマホへ乗り換える」方の参考になればと思い、実際に発生した事象と注意点をまとめます。

実際に確認できた事象と発生原因

今回のトラブルは、単一の操作ミスではなく「古い環境の制限」と「登録情報の不足」が同時に発生したことが原因でした。

1. 「かんたん転送QRコード」が出ない・画面が真っ白になる

確認できた現象：旧iPhone 7側で「かんたん転送QRコード」のメニューを探しても見当たらない、または進めても画面が真っ白のまま読み込まない。
原因：iPhone 7はiOS 15までしかアップデートできません。LINEアプリも最新版に更新できないため、機能自体が存在しないか、アプリが正しく処理を実行できませんでした。

2. 「この端末をメイン端末として使用しますか」で進むとパスワードで詰む

確認できた現象：新しいAndroid側で電話番号認証を進めると「この端末をメイン端末として使用しますか？旧端末からはログアウトされます」と表示。画面通り「はい」で進めたが、最後の段階でパスワード入力を求められた。
原因：LINEの仕様上、異OS間（iOS ➔ Android）の引き継ぎかつQRコードを使わない場合、電話番号認証＋パスワード（または旧端末での承認）が必須となります。パスワードが分からないため、ここで進行不能となりました。

3. パスワード再設定・アプリアップデートの画面ループ

確認できた現象：

パスワードを再設定しようとすると「メールアドレスの登録が必要」と表示。
メールアドレスを入力して「次へ」を押しても、設定が完了せず同じ画面に戻ってしまう。
LINEアプリをアップデートしようとすると「新しい旧バージョンをダウンロードしますか」と表示され、OKを押しても再度同じ確認メッセージが出続ける。

原因：旧端末（iPhone 7）のアプリおよびOSバージョンが古すぎる状態では、画面上の指示に従って操作しても登録処理やダウンロード処理が正常に完了せず、同じ画面を繰り返す状態になっていました。

今回のケースにおける引き継ぎ条件の整理

項目	今回の状態	影響
旧端末	iPhone 7 (iOS 15)	アプリの更新・画面操作が正常に完了しない
移行先	新しいAndroidスマホ	異OS間移行（iOS ➔ Android）
登録情報	電話番号のみ（メール未登録・パスワード失念）	パスワード再設定や画面遷移が不可
トークバックアップ	なし（消えても可）	トーク保持は不要だったがログイン自体が完了せず

古いiPhoneからAndroidへ移行する際のアドバイス（まとめ）

親御様のスマホがiPhone 7などの古い世代である場合、乗り換え作業（回線切替や旧端末操作）を行う前に必ず旧端末側で以下の準備ができているか確認することをおすすめします。

機種変更の「前」にLINEにメールアドレスとパスワードを登録しておく

アプリが正常に動いているうちに、旧端末上でメールアドレス登録とパスワード設定を済ませておくことが最重要です。

パスワードをノート等に手書きでメモしておく

異OS間の引き継ぎでは電話番号認証だけでは完結せず、パスワードの入力が求められます。

「アカウント引き継ぎ」設定をONにしておく

旧端末の [設定] ＞ [アカウント引き継ぎ] をONにしておくことで、スムーズに認証を通すことができます。

旧端末での設定変更がループして進まない場合は、遠隔や自力での対応が難しいため、「ショップの有料データ移行サポート」を利用するか、最終手段として「アカウントの新規作成（友達の再登録）」を検討する必要があります。

楽天モバイルの子供回線を親名義へ変更する方法｜UQ乗り換え時の無限ループ対処法

2026-08-26T22:57:42.050+09:00

子供の成長やスマホ料金の見直しに伴い、「楽天モバイルを使っている子供の回線を、UQ mobileなどの格安SIMへ乗り換えさせたい」と考える親御さんは多いのではないでしょうか？

しかし、ここで最初の大きな壁が立ちはだかります。

実は UQ mobileをはじめとする多くの格安SIMは、18歳未満（または中学生以下）を「契約者」として申し込むことができません。

そのため、【子供名義の楽天モバイル】を【一旦、親名義へ変更（譲渡）】し、その上で【親名義としてUQ mobileへ乗り換える】という手順を踏む必要があります。

今回は、この「楽天モバイルでの親子間名義変更」の最中に発生した「アプリの無限ループ」と「iPhone SE2では画面すら起動しないトラブル」、そしてそれをカメラ撮影なし（6桁の暗証番号）で一発突破した実体験を詳しくまとめました！

1. iPhone SE2の罠：WebとアプリのIDを揃えても「eKYCが起動しない」

まず最初につまずいたのが、我が家のiPhone SE（第2世代）での挙動でした。

楽天モバイルの名義変更（譲渡）は、以下の手順で進めます。

1. 子供の「my 楽天モバイル」から譲渡申請を出し、譲渡用URLを発行する。

2. 親のスマホでそのURLを開き、親の楽天IDでログインして「スマホでかんたん本人確認（eKYC）」を進める。

この際、アプリとブラウザのログインIDが異なるとエラーになると聞いていたため、あらかじめ親のスマホの「Rakuten Link」アプリも親の楽天IDでログインし直して準備万端で挑みました。

しかし…… iPhone SE2のブラウザ（Safari）で「ICチップを読み取る」を押すと、Rakuten Linkアプリが起動してトップ画面が開くだけで、本人確認画面へ一切進まない！

何度試してもアプリが開くだけの「無限ループ」です。

近年のアプリ統合に伴い、ブラウザからアプリへ処理を引き継ぐ仕様（ディープリンク）に変わりましたが、iPhone SE2などの旧世代端末では処理やメモリ制限の影響でこの連携が正しく動作しない可能性があります。

IDを正しく一致させていても進まない場合は、端末側の互換性問題を疑うのが賢明です。

2. iPhone 14へ変更！…しかし次は「カメラ撮影でフリーズ」

「端末が古いのが原因か？」と考え、端末を iPhone 14 に変更して再度チャレンジしました。

すると、先ほどまでのループが嘘のように「マイナンバーカード読み取り画面」までスムーズに進むことができました！やはり端末の世代によって動作に明確な差が出るようです。

「これで解決！」と思ったのも束の間、次に第2の罠が待っていました。

マイナンバーカードを読み取った後に行う「厚みや顔写真のカメラ撮影」の途中で、画面に「読み込み中…」と表示されたまま完全に固まってしまったのです。

iPhone 14などの高精度カメラを搭載した端末だと、ブラウザ上の撮影システムへ送信する画像データ量が大きくなり、リアルタイム送信の処理でフリーズを起こしてしまうケースがあります。通信をWi-Fiからモバイル回線（4G/5G）に切り替えても、一度固まったカメラは復帰してくれませんでした。

3. 【最終解決策】カメラ撮影不要！「6桁以上の暗証番号」で一発突破

「SE2では起動せず、iPhone 14ではカメラ送信で固まる」という絶望的な状況を救ってくれたのが、「マイナンバーカードの署名用電子証明書（英数字6桁以上の暗証番号）」を使った本人確認でした。

この方法を選択すると、エラーが起きやすい「顔写真や書類のカメラ撮影」プロセスを完全にスキップできます！

実際に成功した手順

1. アプリのログイン確認

親のスマホの「Rakuten Link」アプリを開き、親（受取人）の楽天IDでログインされているか確認する。

2. 通常モードのブラウザでアクセス

譲渡URLを Safari（通常のタブ。プライベートモードはNG）で開き、親の楽天IDでログイン。

3. 認証方式の選択

「スマホでかんたん本人確認」を進める際、認証方式で「署名用電子証明書（英数字6桁以上のパスワード）」を入力するタイプを選択する。

4. 暗証番号入力とカード読み取り

6桁以上の暗証番号を入力後、iPhoneの上部（背面のカメラ横あたり）にマイナンバーカードをピッタリあててICチップを読み取らせる。

カメラ撮影が発生しないため、通信エラーでフリーズすることもなく一瞬で本人確認が完了しました！

4. 名義変更（譲渡）が完了した後の注意点とまとめ

無事に名義変更の手続きが完了したら、いよいよ他社（UQ mobile等）への乗り換えに移りますが、スムーズに開通させるために以下の注意点も押さえておきましょう。

名義反映のタイミングを確認する

Web上で完了しても、システム上の契約者情報が親名義に完全に切り替わるまで少し時間がかかる場合があります。⁠my 楽天モバイル⁠ の契約者情報が親の名義に更新されているのを確認してから、MNP予約番号を発行してください。

Rakuten Linkアプリの再ログイン

手続きのために一時的に親のIDへ切り替えた場合は、必要に応じて元のログイン状態に戻しておきましょう。

どうしてもWeb上でエラーが解消しない場合の最終手段

古い端末しか手元にない場合やeKYCのループが抜けない場合は、無理にオンラインで粘らず「受取人確認配達（自宅で配送員にマイナンバーカードを提示する方式）」にするか、楽天モバイルショップ（店舗）へ来店予約をして親子で手続きに行くのが確実です。

まとめ

子供の楽天モバイル回線を親名義に変えて他社へ乗り換える際、エラーで進まなくなったら以下の2点をチェックしてみてください。

iPhone SE2などの旧端末だとeKYC自体が起動しない場合がある（動作確認済みの端末に変えて試す）

カメラ撮影で固まるなら「6桁以上の暗証番号（署名用電子証明書）」を使った認証に切り替える

同じ症状で名義変更が進まず困っている方の参考になれば幸いです！

【復活】iPhoneのOSアプデ中に電源を切ったら無限ループに！「0x80090326エラー」を乗り越えて復旧させた全手順

2026-07-18T12:07:28.786+09:00

先日、iPhone（SE第3世代）のOSアップデートが終わらないことに焦り、途中で電源を落としてしまうという大失敗をやらかしました。

再度電源を入れたところ、「ホームボタンを押すと一瞬だけパスコード入力画面が出るが、1秒未満ですぐに消えて最初の画面に戻る」という絶望的な無限ループに突入。指紋認証（Touch ID）も全く受け付けません。

ネットで調べてもなかなか同じ症状が見つからず、かなり冷や汗をかきましたが、紆余曲折を経て無事に自力で復元（初期化）に成功しました！

今回は、この絶望ループから脱出した手順と、途中で遭遇したiTunesの謎のエラーの回避方法をまとめます。同じ症状で困っている方の参考になれば幸いです。

結論：何が起きていたのか？

OSアップデート中に強制終了したことで、認証系や画面描画を管理する内部システムファイルが破損し、「クラッシュ→自動再起動」の無限ループに陥っていたようです。

端末単体での強制再起動は効果がなく、パソコン（iTunes）に接続して「リカバリーモード」からシステムを入れ直す（復元・初期化）ことでしか解決できませんでした。

復旧へのロードマップ

ステップ1：iPhoneを「リカバリーモード」に入れる（超重要・タイミングがシビア）

端末のシステムが暴走しているため、普通に繋ぐだけではパソコンがiPhoneを認識してくれません。強制的にパソコンと通信させる「リカバリーモード」に入れます。

【iPhone SE第3世代での手順】

パソコンとiPhoneをUSBケーブルで繋ぐ。

音量を上げるボタンをポンと押してすぐ離す。

音量を下げるボタンをポンと押してすぐ離す。

電源ボタン（サイドボタン）を「これでもか」というくらいずっと長押しする。

💡 ポイント

途中で「電源オフスライダ」や「Appleのリンゴマーク」が出ても、絶対にボタンを離してはいけません。画面に「パソコンとケーブルのイラスト」が出るまで押し続けるのが成功のコツです（15秒以上かかります）。

成功すると、パソコン（iTunes）側に「アップデートまたは復元」のダイアログが表示されます。今回は移行先にデータがあったため、確実性を重視して「復元（初期化）」を選択しました。

ステップ2：iTunesエラー「0x80090326」への対策

ここで次の壁が立ちはだかりました。

iTunesが復元用のファームウェアをダウンロードしている最中に、「不明なエラーが発生しました (0x80090326)。ネットワークの設定を確認してください」と出て中断されてしまうのです。

このエラーはiPhoneの故障ではなく、「Windows（iTunes）とAppleのサーバー間の暗号化通信がうまく確立できていない」ときに出るエラーです。

OS標準のセキュリティソフトを疑いましたが、我が家の環境で一発解決した対策は「ネットワークの切り替え（テザリング）」でした。

対策：パソコンのWi-Fi接続先を、別のスマホの「テザリング（インターネット共有）」に切り替える。

ルーターのセキュリティフィルターやプロバイダの制限が原因だったようで、テザリングに変えた途端、エラーが出ずにダウンロードが進むようになりました。

ステップ3：「15分の壁」と格闘しながらダウンロード完了を待つ

iPhoneのリカバリーモードは、安全のために15分経つと自動で解除され、元の不具合画面に戻ってしまう仕様になっています。

ファームウェアのダウンロード（数GBあります）には30分以上かかるため、途中でiPhoneが通常画面に戻ってしまいますが、これは正常な挙動なので焦らなくて大丈夫です。

パソコン側でダウンロードが進んでいるのを確認したら、iPhoneを一度PCから外してコンセントでしっかり充電しておく（充電切れ対策）。

パソコン側のダウンロードが完了したら、iPhoneをPCに繋ぎ直す。

もう一度だけ「ステップ1」のボタン操作を行い、iPhoneを2回目のリカバリーモードに入れる。

これで、すでにダウンロード済みのデータを使って、待たされることなく一気に「復元（初期化）」が始まります！

※注意

リカバリーモードの実行や数GBに及ぶデータ転送は、途中で接続が切れると完全に端末が文鎮化するリスクがあります。百均などの充電専用ケーブルではなく、必ずデータ転送に対応した信頼できるケーブルを使いましょう。

リンク

まとめ

無事に復元が終わり、画面に「こんにちは」が表示されたときは本当にホッとしました。

今回学んだ教訓は以下の3つです。

OSアップデート中の電源オフは絶対にダメ（システムが消滅する）

リカバリーモードの電源ボタンはリンゴマークが出ても離さない

iTunesのエラー 0x80090326 が出たらテザリングを試す

もし同じように「パスコード画面が一瞬で消えて詰んだ！」という状態になっている方がいたら、まずはパソコンに繋いでテザリング環境でのリカバリーモードを試してみてください！

パソコンが突然地球儀マークになりネット接続できない｜Wi-Fiがオフだった実家の事例

2026-04-30T23:09:42.659+09:00

先日、遠方に住む父から「朝は普通に使えていたのに、急にインターネットができなくなった」と連絡がありました。

すぐに駆けつけられない距離。電話越しに状況を聞き出し、原因を特定して解決に導く……。まさにエンジニアとしての腕が試される「遠隔トラブルシューティング」の始まりです。

結果から言うと、原因は拍子抜けするほど単純なものでしたが、そこに辿り着くまでには「実家サポート特有の罠」が潜んでいました。

罠1：「スマホは使える」という証言の盲点

まず状況を切り分けるため、父に「スマホでネットは見られる？」と確認しました。

返ってきたのは「スマホは普通に使えるよ」という力強い言葉。

ここで私は、「親機（ルーター）や回線自体は生きている。パソコン側の個別の問題だな」と推測しました。……が、これこそが最初の罠です。

スマホは、Wi-Fiが死んでいても「4G/5G（携帯回線）」で繋がってしまいます。

親世代にとって「ネットが繋がる」という状態はひとつ。それがWi-Fiなのか、キャリアの電波なのかを区別していないケースが非常に多いのです。「スマホが繋がる＝家のWi-Fiが正常」という証明にはならない。この意識が、遠隔サポートでは生死を分けます。

罠2：「いつもと違う」を見逃さない

次に、パソコン画面の右下にあるネットワークアイコンを確認してもらいました。

「いつもの扇形のマーク（Wi-Fi）が出ている？」と聞くと、返ってきた答えは「見たこともない『地球儀』みたいなマークになっている」とのこと。

Windowsユーザーにはお馴染みの、インターネット未接続を示すあのマークです。

さらにその場所をクリックしてもらうと、画面には非情なメッセージが出ていました。

「Wi-Fiがオフです」

原因が確定した瞬間でした。ルーターの故障でも、回線の切断でもなく、パソコン自身のWi-Fi機能が眠っていただけだったのです。

### 罠3：「知らないうちに」が起きるキーボードの魔法

対応は簡単でした。

1. 右下の「地球マーク」をクリック

2. 「Wi-Fi」のボタンをポチッと押してオンにする

3. 自宅のネットワーク名を選んで接続

これだけで、実家のネット世界は無事に復旧しました。

しかし、なぜ勝手にオフになったのか？おそらく、キーボードの「Fn（ファンクション）キー」と「Wi-Fiマークの付いたキー」を無意識に同時押ししてしまったのでしょう。

ノートパソコンには物理的に通信を遮断する「飛行機モード」や「Wi-Fiオンオフ」のショートカットが存在します。本人にその気がなくても、掃除中や入力ミスで「魔法」はかかってしまうのです。

遠隔サポートで大事だと思ったこと

今回、改めて痛感したのは「事実の切り分け」をいかに丁寧に行うかという重要性です。

家族が相手だと、どうしても

* 本人の説明が主観的（「何もしてないのに壊れた」など）

* 専門用語が噛み合わない

* 「スマホが繋がるから回線は大丈夫」という思い込み

といった壁にぶつかります。確認を一つずつ、できれば「言葉」ではなく「アイコンの形」や「画面の色」といった、目に見える事実ベースで進めるのが解決への近道だと再認識しました。

もし、皆さんのご実家から「ネットが繋がらない！」とSOSが来たら、まずはルーターを疑う前に「右下に地球儀が出ていないか」をチェックしてもらうことをおすすめします。

意外と、世界を救う（ネットを直す）のは、ボタンひとつかもしれません。

【AI-900合格】実質2週間！最新Udemy問題集×Geminiを「相棒」にした最短攻略法

2026-04-18T17:59:00.002+09:00

4月からの大規模プロジェクトを控え、「今のうちにAIの基礎を固めておきたい」と考え、Microsoftの認定試験 AI-900（Azure AI Fundamentals）を受験しました。

結果、ちょっと危ないカテゴリもありましたが、実質2週間足らずの独学で一発合格。

今回は、あえて「動画学習」を捨て、「最新のUdemy問題集」と「AI（Gemini）」を相棒にして最短ルートで合格した勉強法を公開します。

なぜ「動画学習」をやめたのか？

最近は動画教材が人気ですが、多忙なマネージャー職にとって動画には3つの弱点がありました。

1. スピードが遅い: 理解している部分を飛ばしにくい。

2. 場所を選ぶ: 電車内や家族がいるリビングで、音声を出しながら集中するのは重い。

3. 検索性が低い: 「あの用語、なんだっけ？」と戻るのに時間がかかる。

そこで今回は、「テキストベースの模擬試験」と「AIへの質問」に絞った、徹底的な隙間時間活用スタイルを選択しました。

合格へ導いた「最強の相棒」教材3選

私が実際に使用した、2026年最新版対応の教材をご紹介します。

【基礎固め】Microsoft公式学習ガイド（無料）

まずは公式の学習ガイドで全体像を把握しました。

* 感想: 無料で網羅性は高いですが、日本語が少し機械翻訳的で、これだけで「腹落ち」させるのは少し大変かもしれません。

【土台作り】Udemy：対策テスト4回＋用語問題集

AI-900 / Microsoft Azure AI Fundamentals 対策テスト4回＋用語問題集

* 感想: 「まずは用語から」という初学者に最適。4回分のテストがあり、コストパフォーマンス抜群です。基礎体力をつけるのに最適でした。

③ 【総仕上げ】2026年版模擬問題集（全6回）

【2026年版】AI-900 模擬問題集｜生成AI・Copilot・Foundry完全対応｜全問丁寧な日本語解説付き

* 感想: 生成AI、Copilot、Azure AI Foundryといった最新範囲をがっつりカバー。本番に近い「手応え」のある問題が多く、仕上げにはこれ一択です。

【本命】Geminiを「最強の家庭教師」にする勉強法

今回、私が最も強調したいのが、「Udemyで問題を解き、Geminiと議論する」というハイブリッド学習法です。

正直に言うと、Udemyの模擬試験の解説だけでは、「なぜこれが正解なのか？」がスッキリしない瞬間もありました。そんな時、私は Gemini にこう投げかけました。

プロンプト例:

「この問題の正解が『回帰』で、なぜ『分類』ではないのか。わかりやすく教えて。」

もっとわからないときは、udemy の問題自体をコピペして、

「以下はどう考れば良いか教えて

（問題文）」

として聞いていました。

Geminiは、私が納得するまで何度でも、時には表やコードを交えて解説してくれます。

この「相棒」がいたからこそ、2週間という短期間で深い理解を得ることができました。

本番の試験はどうだったか？

万全を期して挑みましたが、実際の試験では「初見の表現」もいくつか出現しました。

しかし、Geminiとの「対話」を通じてAIの設計思想（ロジック）が頭に入っていたため、慌てることなく消去法で正解を導き出すことができました。

単なる丸暗記ではなく、「なぜそうなるのか」をAIと一緒に突き止めるプロセスが、合格への一番の近道だったと確信しています。

最後に

AI-900の合格後、バッジがCredly（デジタル証明プラットフォーム）に並んだときは、やはり嬉しいものです。

「AIを学ぶために、AIを使い倒す」。

この楽しさを、ぜひ皆さんにも体験してほしいと思います！

【Azure】接続文字列をコードに書かない！App Service環境変数とKey Vaultの使い分け

2026-04-04T10:50:00.000+09:00

はじめに

AzureでWebアプリを開発している際、DBの接続文字列やAPIキーなどの「機密情報」をどう扱うべきか悩んだことはありませんか？

「ソースコードに直書きするのはNG」というのは共通認識ですが、いざAzureで管理しようとすると「App Serviceの環境変数（構成）」と「Azure Key Vault」のどちらを使うべきか、その境界線が分かりにくいものです。

今回は、私が実際に開発で「Key Vaultを使いたかったけれど、結局環境変数で対応した」という経験をベースに、それぞれの違いと使い分けのポイントを整理しました。

なぜソースコードに「機密情報」を書いてはいけないのか？

まず大前提として、パスワードや接続文字列をソースコードや appsettings.json にハードコーディングしてはいけません。

• GitHubなどのリポジトリ経由で漏洩するリスク

• 環境（開発・本番）ごとの切り替えが困難になる

この対策として、Azureには主に2つの逃げ道があります。

1. App Serviceの「環境変数（構成）」による管理

今回私が採用したのが、Azure App Serviceのメニューにある「構成（環境変数）」に値を設定する方法です。

メリット

• 設定が非常に簡単： Azureポータルからポチポチ入力するだけで即反映されます。

• コードの修正が最小限： .NETであれば Configuration["Key名"] で読み取る標準的な手法がそのまま使えます。

デメリット

• 閲覧権限の問題： Azureポータルの該当リソースにアクセスできる人なら、誰でも値が見えてしまいます。

• 共有ができない：別のApp ServiceやFunctionsでも同じ値を使いたい場合、それぞれにコピーする必要があります。

2. Azure Key Vaultによる管理

本来、より高いセキュリティを求めるならこちらが本命です。

メリット

• 最高レベルの機密性：値そのものを隠蔽でき、誰がいつアクセスしたかのログも残ります。

• 一元管理：複数のサービスで一つのパスワードを使い回す場合、Key Vault側を更新するだけで全サービスに反映されます。

デメリット

• 設定のハードル：「マネージドID（Managed Identity）」の設定や、アクセス権限（RBAC）の付与など、初見では少し難解な概念が登場します。

結局、どう使い分けるのが正解？

結論から言うと、以下のような基準で使い分けるのがスムーズです。

• App Serviceの環境変数（構成）で管理すべきもの

• アプリの動作設定（例：ログレベル、デバッグモードのON/OFF）

• 頻繁に変更する非機密なパラメータ（例：表示件数の上限、外部APIのベースURL）

• Azure Key Vaultで管理すべきもの

• 機密情報（例：データベースの接続パスワード、外部サービスのAPIキー）

• 証明書や暗号化キー（例：SSL証明書、署名用秘密鍵）

【Tips】「とりあえず動かす」から「理想」へのステップアップ

もし私のように「Key Vaultは難しそうで、今回は環境変数で済ませた」という場合でも、実は「Key Vault参照」という機能を使えば、後から簡単に移行できます。

App Serviceの環境変数に、直接値を入れるのではなく以下のような形式で記述します。

@Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/mysecret/)

これなら、アプリのコードは1行も変えずに、裏側の保存先だけをKey Vaultに格上げすることができるのです。

まとめ：まずは「外に出す」ことが第一歩

Azure開発において、「Key Vaultを使いこなせなかった」というのは決して失敗ではありません。「ソースコードから機密情報を追い出した」という時点で、セキュリティレベルは大きく向上しているからです。

1. まずはApp Serviceの環境変数で「外出し」に慣れる。

2. 余裕が出てきたら「Key Vault参照」に挑戦してみる。

このステップで進めるのが、挫折しないAzure運用のコツだと感じました。

Azure DevOpsの無料枠「5人の壁」とは？知人のリーダーが悩んでいたコストと権限の話

2026-03-29T18:46:00.000+09:00

1. 導入（設定の提示）

先日、別会社でチームリーダーをしている知人のエンジニアから相談を受けました。

『Azure DevOpsを使ってReposでソース管理を始めようとしたら、インフラ担当から開発メンバーは5人まで、管理者は1人という制限を言い渡された。これってAzureの仕様なの？それともうちの会社のケチなルール？』

という内容です。

2. 「5人制限」の正体は、Azure DevOpsのBasicプラン

結論から言うと、これは会社のケチなルールではなく、Azure DevOpsの標準的なライセンス仕様（Basicプラン）によるものです。

• 5人まで： Basicユーザーは5人まで無料。

• 6人目から：月額料金（約$6〜/人）が発生。

知人のチームも、最初は『無料の範囲内でスモールスタートしたい』というインフラ側の意向があったようです。

こちらに詳しく書かられていました。

Azure DevOps の料金

3. 「管理者は1人」という運用の背景

さらに彼を悩ませていたのが『管理者は1人』という制約。

これはシステム上の制限というより、ガバナンス（統制）の側面が強いとアドバイスしました。

• Organization Ownerは1人。

• マスターへのマージやデプロイ権限を絞ることで、事故を防ぐ運用。

• ただし、リーダーとしてコード管理をスムーズにしたいなら、権限（Project Administratorsなど）を適切に切り分けてもらう交渉が必要かもしれません。

4. 解決策として提示したアドバイス

相談に来た彼には、以下の3つのチェックポイントを伝えました。

1. Stakeholder（ステークホルダー）の活用: コードを見ないメンバー（進捗確認のみのPMなど）は、無料枠の5人にカウントされず無制限に招待できる。

2. Visual Studio サブスクリプションの確認: もし既にVSのライセンスを持っていれば、その人は5人の枠を使わずにBasic機能が使える。

3. 役割の明確化: 誰がマージ権限を持ち、誰がリリースを承認するか。人数を増やす前に、この『交通整理』をインフラチームと握っておくことが重要。

5. まとめ

クラウドサービスは便利ですが、こうした『人数の壁』が突然現れます。

実体験（相談）を通じて感じたのは、開発効率とライセンス費用のバランスを、リーダーがいかに把握しておくかという大切さでした。

【Azure】Azure App ServiceやDBを夜間停止してコスト削減！Azure AutomationとPython SDKで自動化する方法

2026-03-22T10:17:08.655+09:00

個人開発や検証環境でAzureを使っていると、気になるのが「コスト」ですよね。

特に Application Gateway (Agw) や App Service、PostgreSQL は、動かしっぱなしにすると地味に費用が嵩みます。

これまでは「使う時だけポータルから手動で起動・停止」していましたが、ついつい消し忘れて翌朝絶望することも…。そこで、Azure Automation を使って、これらをスマートに自動管理する仕組みを調べて実装してみました。

1. なぜ「手動」から「自動化」へ？

手動運用の課題は、単に「面倒」なだけではありません。

• 消し忘れリスク: 24時間稼働による無駄な課金。

• 依存関係の複雑さ: App Serviceだけ起動しても、Agwが止まっているとサイトにアクセスできないといった「起動順序」のミス。

• デプロイ時の手間: 開発のたびにポータルを開くスイッチ作業のロス。

これらを解決するのが Azure Automation です。

2. Azure Automationによる自動化の仕組み

今回採用したのは、Azure Automationの「Runbook」機能です。

PythonのSDKを使用して、複数のリソースを一括でコントロールします。

構成のポイント

• Managed Identity: Automationアカウントに権限を付与し、パスワードレスで操作。

• Automation 変数: サブスクリプションIDやリソースグループ名をコードに直書きせず、変数として管理。

3. 【実践】Python SDKでリソースを制御するコード

実際のコードの肝となる部分を解説します。

GetAutomationVariable を使い、動的にリソースを特定して操作する流れです。

# イメージとしてのコード例

from azure.mgmt.web import WebSiteManagementClient

from azure.mgmt.rdbms.postgresql_flexibleservers import PostgreSQLManagementClient

# (中略) 認証処理など

# Automation変数から情報を取得

rg_name = get_automation_variable("ResourceGroupName")

# App Serviceの起動例

for app in web_client.web_apps.list_by_resource_group(rg_name):

if app.name == "対象のサービス名":

web_client.web_apps.start(rg_name, app.name)

print(f"{app.name} を起動しました。")

このように、xxxManagementClient を使って、リソースを探索し、start() や stop() を呼び出すだけでOKです。

4. ハマったポイント：サイトにアクセスできない！？

自動化を実装した際、App ServiceとDBを起動したのに「このサイトにアクセスできません」となることがありました。原因は Application Gateway (Agw)。

Agwはポータルに停止ボタンがないため見落としがちですが、SDK経由で停止されている場合、ここも明示的に start させる必要があります。

5. まとめと今後の展望

Azure Automationを設定すれば、スケジュール機能（Schedule）を使って「平日の夜間だけ止める」といった運用が数クリックで実現します。

• メリット: 確実なコスト削減と、ポータル操作からの解放。

• 次の一歩: 今後は「デプロイ時だけ一時的に起動し、終わったら自動で閉じる」といったGitHub Actionsとの連携も試してみたいと思います。

【2026年最新】AZ-900合格体験記！Udemyの的中率は？初見問題3割を突破した最短攻略法

2026-03-08T17:45:00.000+09:00

■ はじめに

本日、Microsoft Azure Fundamentals（AZ-900）に無事合格しました！

実務でAzureに触れる機会が増えたため受験しましたが、効率的な学習のおかげで短期間でパスすることができました。今回は私が活用した教材と、本番で焦らないための対策を共有します。

■ 使用した教材：Udemy「これだけで合格！AZ-900 模擬試験問題集」

私が活用したのは、Udemyの人気講座です。

講座リンク

この問題集のおかげで、基本的な知識の土台を固めることができました。特におすすめしたいポイントは以下の2点です。

1. 更新日時が新しく、2026年最新版に対応

Azureはアップデートが激しいですが、この講座は2026年1月更新と非常に新しいため、安心して取り組めました。

2. 「高度な模擬試験」が2回分付いている

基本レベルだけでなく、少しひねった「高度な模擬試験」が2回分含まれています。これが本番の「初見問題」への対応力を養ってくれました。

■ 本番のリアル：3割は見たことのない問題！？

正直に言うと、模擬試験を完璧にしても、本番では約3割ほど「見たことがない問題」が出て焦りました。

しかし、この問題集の解説を読み込み、「なぜこれが正解なのか」「似たサービスとの境界線はどこか」という本質を理解していたため、消去法や論理的思考で正解を導き出すことができました。

■ 私が実践した「直前仕上げ」のコツ

試験直前、完成度を一気に高めたのはこの方法です。

「模擬試験で間違えた問題だけを、繰り返し見直す」

正解した問題に時間をかけず、不正解だった選択肢の「なぜ間違えたか」の解説を読み込む。これを徹底することで、自分の弱点を完全に潰した状態で本番に挑めました。

■ まとめ

AZ-900は、しっかりとした土台があれば怖くありません。これから受験される方は、ぜひ最新の情報を反映したこのUdemy教材を活用してみてください！

【最短合格を狙うならこちら】

Azure DevOps障害に翻弄された月曜日

2026-03-05T23:05:00.003+09:00

■ はじめに

知り合い数人と進めている共同開発プロジェクト。3月に入った途端、メンバーの一人から「Gitのpushで認証エラーが出るようになった」と連絡が。

「あぁ、またPAT（アクセストークン）の期限切れか、月替わりの認証情報の更新かな」なんて、この時はまだ高を括っていた。

■ 迷走の始まり：自分だけ「成功」するという罠

まずは状況の切り分け。

「こっちでは普通にpullもpushもできるよ」

この一言が、原因特定を遅らせる最大のフラグになった。

自分ができる以上、プロジェクトの設定やAzure側の障害ではないはず。メンバーのローカル環境の問題だと断定し、以下の指示を飛ばした。

• 資格情報マネージャーの古い情報を消してみて

• git config --global credential.useHttpPath true を試して

• ブラウザのキャッシュをクリアして……

しかし、返ってくるのは「全部ダメだった」という絶望のレスポンス。

■ エラーメッセージとの格闘

送られてきた画面には、無慈悲なメッセージ。

TF10216: Azure DevOps services are currently unavailable.

Activity Id: 35b9da34...

Activity IDまで出ているのに、Azure DevOpsのStatus Portal（稼働状況）は「All Green」。アジアリージョンも正常。

「Activity IDまで出てるんだから、そっち（Azure）のせいだろう」と思いつつも、公式が「正常」と言い張る以上、こちら側の設定（認証ポリシーの変更など）を疑わざるを得ない。

■ 衝撃の結末

数時間が経過し、再度Status Portalをリロードしてみると……。

さっきまで鮮やかな緑色だった「Asia」のアイコンが、真っ赤な「Unhealthy」に変わっていた。

結局、Microsoft側の認証基盤の障害。

私がpushできていたのは、たまたま認証セッションが有効なサーバーに繋がっていたか、キャッシュが生きていただけだった。時間が経てば、いずれ私の環境でもエラーが出ていたはず。

■ 今回の教訓：ステータスサイトは「後出しジャンケン」

今回の件で学んだ教訓は3つ。

1. 「自分だけ動く」は環境が正常な証拠にはならない。（運がいいだけの場合がある）

2. 公式ステータスの「All Green」は、リアルタイムとは限らない。（反映にラグがある）

3. Activity IDが出たら、それはもう自分たちの範疇を超えている。

特に月替わりのタイミングは「自分のミス」を疑いがちだが、メンバー全員で一斉に起きた時は、公式ステータスが緑でも「コーヒーを飲んで1時間待つ」のが、精神衛生上もっとも正しいエンジニアの振る舞いかもしれない。

締めの一言

「Activity IDを必死にググっていたあの時間を返してほしい……（笑）」

Azure Database for PostgreSQLで突然の504。ログから遅延SQLを特定して改善するまで

2026-03-02T00:37:00.001+09:00

はじめに

自習環境でPDF出力機能を検証していたときのことです。

ある日、突然処理が終わらなくなりました。

しばらく待っていると、画面には 504 Gateway Timeout。

「メモリが足りないのか？」

最初はそう思いました。

メモリを疑う

Azure App Service のメトリクスを確認。

メモリ使用率はおよそ45％。

上限に張り付いているわけではありません。

念のため、コンテナ内でも確認しました。

cat /sys/fs/cgroup/memory/memory.limit_in_bytes

表示された値は、実質無制限に近い数字。

少なくとも、メモリ制限で落ちているわけではなさそうでした。

ではなぜ504が出るのか。

「タイムアウトかもしれない」

処理時間を見直す

ログを丁寧に追っていくと、リクエストが300秒以上かかっていることが分かりました。

これなら504になってもおかしくありません。

問題はメモリではなく、単純に「遅い」ということでした。

SQLを疑う

PDF出力処理では、データを取得してループしながら帳票を組み立てています。

もしかして、特定のSQLが遅いのでは？

そう思ってAzure Database for PostgreSQLを確認しました。

しかし、Query Storeは無効。

さらにサーバーパラメータを見ると、

log_min_duration_statement = -1

遅いSQLは一切ログに出力されていませんでした。

見えないものは、直せない。

まずは可視化から

log_min_duration_statement を 1000 に変更しました。

これで1秒以上かかったSQLがログに出ます。

その状態で、問題のPDF出力をもう一度実行。

Azureポータルのログを開き、息を詰めて確認しました。

出てきました。

duration: xxxx ms

同じSELECT文が何度も並んでいます。

そして、1回あたりも決して軽くない。

ようやく、ボトルネックが見えました。

インデックス不足

検索条件に使っているいくつかの列があります。

しかし、それらをまとめてカバーするインデックスはありませんでした。

複合インデックスを追加しました。

ロック影響を避けるため CONCURRENTLY を使用。

そして再度実行。

結果は

約10秒 → 約2秒。

はっきり分かる改善でした。

学び

今回の一件で感じたことがあります。

最初にメモリを疑ったのは、完全に思い込みでした。

504が出ると「リソース不足」と考えてしまう。

でも実際は、単純なインデックス不足。

そして何より大きかったのは、

推測ではなく、ログで確認したこと。

log_min_duration_statement が -1 のままだと、何も見えません。

見えないまま議論しても前に進みません。

まずは可視化。

そこからボトルネックを特定し、最小限の対処をする。

遠回りに見えて、それが一番早いと感じました。

おわりに

今回の問題はインデックスで改善しました。

ただし、ループ内でのクエリ実行は構造的な負荷を生みやすい部分でもあります。

N+1の可能性も含め、設計レベルでの見直しも今後の課題です。

それでも、504の正体を一つずつ剥がしていく過程は、とても良い学びになりました。

エラーの裏には、必ず理由がある。

焦らず、数字を見て、順番に潰す。

改めてその大切さを実感した出来事でした。

夜間はタダ！？Azure Container Apps vs App Service 料金比較と使い分けのポイント

2026-02-17T23:11:00.003+09:00

1.Azure App serviceが最高だと思ってました

「誰も使っていない夜中のサーバー代、もったいないな…」と思ったことはありませんか？

開発した社内ツールや個人開発のアプリ。便利に使っているけれど、ふとコスト画面を見ると、誰もアクセスしていない深夜や休日も律儀に課金が続いている。Azure App Serviceを使っていると、これは「当たり前」の光景ですよね。

でも、AZ-900の勉強をしていたら見つけてしまったんです。「リクエストがない時は料金をタダにできる」という、魔法のようなサービスを。

今回は、App ServiceからAzure Container Appsに乗り換えるだけで、どれだけコストが浮くのか、その衝撃の事実をまとめました。

2. 詳細な料金計算の比較

※ 料金は目安（東日本リージョン、2024年現在の概算）としてご覧ください。

前提条件

• アプリのスペック: 1 vCPU / 2GB RAM 相当

• 稼働状況: 平日9:00〜18:00（月20日）だけリクエストがあり、それ以外はアクセスゼロ。

• 月間稼働時間: * 稼働中：9時間 × 20日 = 180時間

• アイドル中（夜間・休日）：550時間

A. Azure App Service (Basic B1プラン)

App Serviceは、アクセスがなくてもサーバーを維持するため、730時間フルで課金されます。

• 計算: 月額固定約 $13.00〜$15.00

• 特徴: アクセスがなくても、常にこの金額が発生。

B. Azure Container Apps (消費プラン)

アクセスがない時間は「0」にスケールアウト（停止）させると仮定します。

• 稼働中の料金: * vCPU: $0.000024/秒 × 3,600秒 × 180時間 ≒ $15.55

• メモリ: $0.000003/秒 × 3,600秒 × 180時間 ≒ $1.94

• 停止中（夜間・休日）の料金: $0

• 合計: 約 $17.49 > あれ？高くなった？と思われるかもしれませんが、ここがポイントです！実はContainer Appsには、毎月の「無料枠」があります。

C. Container Apps（無料枠適用後）

Container Appsには、毎月以下の無料枠がついてきます。

• 無料枠: 最初の180,000 vCPU秒、360,000 GiB秒

• 実質コスト: このシミュレーションの規模（月180時間稼働）だと、無料枠を差し引くと月額数ドル（約$2〜$5程度）まで抑えられるケースが多いです。

3. 比較まとめ表

• Azure App Service (PaaS)

• Cost Model: Fixed Monthly Fee (固定料金)

• Nighttime Cost: Always On (夜間も課金継続)

• Key Strength: Easy setup for Web Apps (Webアプリ特化で管理が楽)

• Best For: High-traffic sites (24時間安定稼働が必要なサイト)

• Azure Container Apps (Serverless)

• Cost Model: Pay-per-use (使った分だけ秒単位課金)

• Nighttime Cost: Zero / Free (夜間停止で0円が可能)

• Key Strength: Scale-to-Zero (リクエストがなければ自動停止)

• Best For: Internal tools & Dev environments (社内ツールや検証環境)

補足:

App Serviceも手動やスクリプトで停止（Stop）できますが、プラン自体の料金（インスタンス予約代）は発生し続けるため、Container Appsのように「動いていない時は本当にタダ」というレベルにするには、プランの削除・再作成が必要で手間がかかります。

まとめ

個人でやる分にはコスパ最高のContainer Appsなのですが、お客様向けには、Webサイトを安全に運用するための機能が全部入りのApp serviceが良さそうです。そんなに甘くはなかったか、、、。でも、要件によっては使えそうなサービスと感じました。

Azure DevOpsで「Invalid clientid or client secret」エラーが出た時の解決策！Workload Identity Federationへの移行手順

2026-02-14T19:23:00.003+09:00

Azure DevOpsからApp ServiceへDockerイメージをデプロイしようとしたら、突然のエラー。

Invalid clientid or client secret.

昨日まで動いていたのになぜ？

原因はサービス接続（Service Connection）の裏側にある「アプリの登録」の有効期限切れでした。

今回は、今後二度と期限切れに悩まされない「Workload Identity Federation」を使った最新の修正方法をまとめます。

1. 発生したエラー：Build and Push Web Imageで失敗

まずは、私が発生したエラーログを共有します。

• ##[error]error from registry: Invalid clientid or client secret.

• ##[error]The process '/usr/bin/docker' failed with exit code 1

一見するとApp Service側の問題に見えますが、実はAzure Container Registry (ACR) へのログイン失敗が原因でした。

2. 原因：サービス接続（サービスプリンシパル）の有効期限切れ

Azure DevOpsの「サービス接続」は、裏側でAzure Entra ID（旧Azure AD）の「アプリの登録」を利用しています。

インフラ管理画面（Entra ID > アプリの登録 > 証明書とシークレット）を確認したところ、シークレットの有効期限がバッチリ切れていました。

3. 解決策：Workload Identity Federation (automatic) で再作成

シークレットを更新しても直りますが、また数年後に同じエラーが起きます。

今回は、Microsoftが推奨している「パスワードレス」な方式、Workload Identity Federation を使って作り直しました。

設定の手順：

• Project Settings > Service connections > New service connection

• Azure Resource Manager > Workload Identity Federation (automatic) を選択

• 対象のサブスクリプションとリソースを選択して保存

4. YAMLファイルの修正と承認（Permit）

接続を新しく作った後は、azure-pipelines.yml の containerRegistry や azureSubscription の名前を新しいものに書き換えます。

初回実行時は、パイプライン画面で「Permit（許可）」ボタンを押すのを忘れないようにしましょう。

※パイプライン実行した後、しばらくしてサイト見てみたら表示できなくて、焦ってパイプライン状況をみたら途中で止まっててびっくりしました。許可が必要だなんて知らなかった、、、

Excelマクロの呪縛を解く。20年目のエンジニアがkintone集計ツールにkrewDataを選んだ理由

2026-02-08T10:35:00.002+09:00

1. はじめに：エンジニアがkintoneに触れる

ずっとスクラッチのシステム開発（フルスクラッチでの設計・実装）を主戦場としてきた私ですが、最近はお客様から「開発コストを抑えたい」「導入後、自分たちで保守・運用できる仕組みにしたい（ノーコード）」という切実な声を多く聞くようになりました。

そこで数あるノーコードツールの中から、特にカスタマイズ性の高いkintoneに着目しました。

背景にあるのは、多くの現場で「負の遺産」となっている「Excelマクロのブラックボックス化」という普遍的な課題です。これをkintoneという近代的なプラットフォームで、いかに「持続可能な形」に再構築できるか。そこがエンジニアとしての私の挑戦の始まりでした。

2. 直面した課題：標準機能だけでは超えられない「集計の壁」

RDB（リレーショナルデータベース）でいう「テーブル」を、kintoneでは「アプリ」という単位で扱います。

「社員マスタ」「サービスマスタ」といったマスタデータを参照し、日々の活動を記録する「トランザクションアプリ」を作ること自体は、kintoneの標準機能で驚くほどスムーズに実現できました。

しかし、大きな壁となったのが「複雑な集計ロジック」です。

単なる数値の足し算ではなく、以下のようなビジネスルールが絡む場合、標準機能だけでは対応が難しくなります。

• 「利用開始月は無料にする」

• 「解約日が15日以前なら当月分は0円、16日以降なら満額請求」

これをノーコードで、かつ誰が触っても壊れない「堅牢なシステム」として実装するには、標準機能の枠を超える必要がありました。

3. 解決策の比較：DataCollect vs krewData

この「標準機能の限界」を突破するための外部サービスとして、市場で圧倒的なシェアを持つのが、トヨクモ社の『DataCollect（データコレクト）』と、メシウス社の『krewData（クルーデータ）』です。

■ DataCollect（関数型・リアルタイム集計）

アプリの画面上で、Excelのように数式（SUMやIFなど）を直接入力して計算させるツールです。

• メリット： Excelの延長線上で設定できる手軽さがある。

• 懸念点：数式の中にロジックが隠蔽されがち。数が増えると「どのフィールドにどんな式があるか」の把握が難しく、スクラッチ開発でいう「スパゲッティコード」に近い状態になるリスクを感じました。

■ krewData（ETL型・バッチ処理集計）

複数のアプリからデータを吸い上げ、工場のライン（フローチャート）のように加工して、別のアプリへ一括で書き出すツールです。

• メリット：データの結合（JOIN）やフィルタリングの流れが視覚的に固定される。

• エンジニア視点：データフローが可視化されているため、不具合時の切り分けが容易で、構造が非常に直感的です。冒頭にフローイメージも作ってみました。

4. 決め手は「3年後のメンテナンス性」と「デバッグ」

システムは「動く」のは当たり前です。本当に大切なのは「3年後に自分以外の誰かがメンテナンスできるか」という点です。

お客様の中にはExcelに詳しい方もいらっしゃいます。しかし、なまじExcelが使えてしまうと、複雑な数式を無理やり組み込んでしまい、結局「作った本人しか直せない」状態に戻ってしまう危険性があります。

その点、krewDataは「数式を意識させすぎない」UIです。集計や条件分岐がノード（図）として表現されるため、エンジニアも非エンジニアも同じ土俵で「データの流れ」を理解できます。結果的に、これが「お客様自身で運用を回せる」という真のノーコードの価値に繋がると確信しました。

5. まとめ：エンジニアがノーコードを扱う「真の価値」

Excelで実現されている現行業務には、必ずといっていいほど「泥臭く複雑な条件」が潜んでいます。

その要件をただツールに詰め込むのではなく、いかにシンプルで安定した「データのパイプライン」に落とし込めるか。そこがエンジニアの腕の見せ所です。

道具が変わっても、設計思想の重要性は変わらない。そう感じたツール選定でした。

マクドナルドの闇！？フィレオフィッシュのチーズが「半分」なのは、実は計算し尽くされた戦略だった件

2026-02-01T21:28:00.000+09:00

1. 衝撃の発見：その時、事件は起きた

マクドナルドで不動の人気を誇る「フィレオフィッシュ」。

ホカホカのバンズを何気なくめくってみたら……

「えっ、チーズが半分しかない！？」

これ、マック好きなら一度は経験したことがある「フィレオフィッシュあるある」かもしれません。私も最初は「バイトの店員さん、忙しくてちぎれちゃったのかな？」と、クレームを入れる寸前までいきました。

2. 発覚した衝撃の事実：ミスじゃなかった！

怒りに震えながら（？）念のためネットで調べてみると、Yahoo!知恵袋や元店員さんの証言で驚愕の事実が判明。

「フィレオフィッシュのチーズは、最初から半分（1/2枚）が正規のレシピです」

なんと、入れ忘れでも手抜きでもなく、マクドナルドの厳格なルールだったのです。

3. なぜ「半分」なのか？マックのこだわり（という名の正当化？）

なぜ、わざわざ1枚を半分にする手間をかけてまで「半分」にこだわるのか。そこには深い（？）理由があるようです。

• 味のバランス：白身魚の繊細な味を殺さないよう、チーズの主張を抑えるため。

• コスト管理： …という側面も否定はできませんが、公式には「最高の味のバランス」を追求した結果だとか。

ちなみに、ダブルチーズバーガーにはあんなにチーズが入っているのに、フィレオフィッシュだけがこの扱い。まさに「選ばれし半分の美学」ですね。

4. まとめ：知らぬは客ばかりなり

「チーズ半分」を知らずに食べ続けている人は意外と多いはず。

次からフィレオフィッシュを食べる時は、そっとバンズをめくって「今日も正しく半分だな」と、職人のこだわりを確認してみてください。

【失敗談】3COINSタブレット（2525/PRE-GHTB）をドアベル専用モニターにする計画が崩壊した話。CloudEdgeは動くのか？

2026-02-01T20:48:00.000+09:00

1. 導入：完璧な計画だった。

「玄関のインターホン（CloudEdge）を、キッチンで座ったまま確認したい。」

そんな願いを叶えるべく、3COINS（スリコ）で1万円のタブレット（2525/PRE-GHTB）を購入。

「Android 15だし、アプリの要求はAndroid 5.0（Lollipop）以上。勝ったな。」

そう確信してレジへ向かったあの時の自分に、今の私は言いたい。「ちょっと待て」と。

2. 期待に胸膨らむ「開封の儀」

• パッケージを開けると、1万円とは思えない綺麗な大画面。

• 「これがサブ機として動けばコスパ最強伝説の始まりだ」とワクワクしながら電源をON。

3. スムーズなセットアップ

• 初期設定はいたって順調。Android 15 (Go Edition) の軽快な動きに、「お、意外とイケるかも？」と期待値は最高潮に。

4. 運命の瞬間：Google Playストアの無慈悲

いよいよ本命のアプリ「CloudEdge」をインストールしようと検索バーに打ち込みます。検索結果に出てきたアイコンをタップした瞬間、目に飛び込んできたのは……

「……えっ？」

アプリ名で検索はできるのに、、、

OSのバージョンは足りているはずなのに、、、なぜ？

5. なぜ拒絶されたのか？（技術的な考察）

調べたところ、原因はおそらくこれです。

• Android Go Editionの制限: 低スペック端末向けの「軽量版Android」であるため、特定の高度な機能やハードウェア要件（映像のエンコード/デコード等）を必要とするアプリが制限されることがある。

• カメラ・マイクの権限や解像度: ドアベルという「リアルタイム映像」を扱う特性上、このタブレットのチップセット（Allwinner A333）がサポート対象外と判断された可能性。

6. まとめ：1万5000円の勉強代

今回の教訓。

「Androidのバージョンが最新でも、Go Editionには見えない壁がある。」

CloudEdgeをタブレットで使おうと思っている皆さん、安物買いの銭失いにならないよう、せめて「Go Edition」ではない普通のAndroidタブレットを選ぶことを強くおすすめします……。

【Azure】WAFとの死闘168時間。ASP.NET CoreアプリをAzure WAFで守ろうとして学んだこと

2026-01-28T23:36:00.002+09:00

1. イントロダクション

Azureを勉強して、ASP.NET Coreでポートフォリオ兼用のWebアプリを公開してみた。

「せっかくなら実戦的に」とAzure Web Application Firewall (WAF) を導入したが、ここからが本当の戦いの始まりだった……。

2. 最初の壁：ログインできない！

公開直後、ログインしようとすると謎の403エラー。ログを確認すると……

Restricted SQL Character Anomaly Detection (args): # of special characters exceeded (12)

何が起きていたのか？

ASP.NETの認証用Cookieに含まれる記号の多さが、「攻撃用コードを隠している」と判定されていた。

• 原因: WAFの「異常検知ルール（942450など）」。

• 気づき: セキュリティを強くしすぎると、標準的なフレームワークの挙動すら「悪」とみなされる。

3. 第二の壁：いたちごっこの泥沼

特定のCookieを除外設定（Exclusion）して「勝った！」と思ったのも束の間。今度は別のログが。

• SQL Injection Attack: SQL Tautology Detected（1=1攻撃の誤認）

• Multiple URL Encoding Detected（二重エンコードの誤認）

しかも、よく見るとCookieだけでなく、URLの引数（ARGS）でも発生している。

ここで私は、「1つ1つ除外設定を書いていたら、いつまでもアプリがまともに動かない」という現実に直面した。

4. 決戦：ログから読み解く「真犯人」

WAFのログに記録された detail_message_s をデコードして、じっくり眺めてみた。

そこには、攻撃コードではなく、ただの「日付データ」や「パスワードの記号」があった。

今回の学び（技術的な急所）

1. 多重エンコードの正体: URLの中にURLを入れる（ReturnUrl）際、記号が %252F のように多重変換される。これはモダンなWebフレームワークの「標準仕様」であって攻撃ではない。

2. パスワードの宿命: 強力なパスワードには記号が必須。これをWAFのSQLIルールで検査すること自体が、実はアンチパターン。

5. 解決策：多層防御の再設計

「WAFの設定をいじり続ける」のをやめ、「どこをWAFに任せ、どこをアプリに任せるか」の役割分担を見直した。

• WAF側: パスワードやReturnUrlなど、正規の処理で記号が入り混じる箇所は、勇気を持って「検査除外」または「特定ルールの無効化」を行う。

• アプリ側: ASP.NET Core Identityを正しく使い、「パラメータ化クエリ（静的プレースホルダ）」と「アカウントロック機能」を有効にする。

6. おわりに：本当のセキュリティとは

WAFは「魔法の杖」ではなかった。

ただボタンをポチポチして「最強」に設定するのではなく、「自分のアプリがどういうURLを吐き出し、どういうCookieを使うのか」を理解して、初めて正しく運用できる。

「いたちごっこ」を終わらせたのは、WAFの知識ではなく、自作したASP.NET Coreのソースコードの中にあった一行のエビデンスだった。

【Azure】 ASP.NETアプリを公開したら、正常な通信がブロックされまくった話（解決編）

2026-01-25T14:51:00.002+09:00

Azureを勉強して、ASP.NETでWebアプリを作ってみました。

Application Gateway（WAF）も立てて、セキュリティは万全！……のはずが、いざ公開してみると、自分や友人のログインが突然ブロックされるという謎の現象に遭遇しました。

今回は、初心者がハマりがちな「WAF運用いたちごっこ」の正体と、スマートな解決策を共有します。

1. 犯人は「ランダムすぎるCookie」

ASP.NET（特にCore）には、セキュリティを守るための仕組みが標準で備わっています。

その代表格が、以下のようなCookieやトークンです。

• .AspNetCore.Mvc.CookieTempDataProvider

• .AspNetCore.Antiforgery

これらの中身は、セキュリティのために「推測不可能なランダム文字列」になっています。

ところが、このランダムな文字列の中に、たまたまSQLインジェクション攻撃に似たパターン（-- など）が紛れ込んでしまうことがあるのです。

2. 初心者が陥る「ID除外の罠」

WAFのログ（Log Analytics）を見ると、「ルールID: 942440 でブロック」と出ます。

そこで「よし、この 942440 を許可リストに入れよう！」と設定するのが、最初の落とし穴です。

実は、Cookieの中身は毎回変わるため、「昨日は 942440 だったけど、今日は 942441 でブロックされる」という現象が起きます。これが「いたちごっこ」の始まりです。

3. 正解は「変数のグローバル除外」

特定のルール番号を許可するのではなく、「この名前のCookieについては、WAFの全検査をスキップしていいよ」という設定をするのが正解です。

設定のコツ（Azureポータル）

WAFポリシーの「管理ルール」→「除外」設定で、以下のように登録します。

• 一致変数：要求のCookieの名前

• セレクター： .AspNetCore.Mvc.CookieTempDataProvider

• ルールセット：ここを特定のIDにせず、全体（Global）にするのがポイント！

これで、どんなランダムな値が入ってきても、WAFが「あ、このCookieは安全な枠組みのやつだね」とスルーしてくれるようになります。

4. もっと安心するために：Azure Advisorを活用しよう

「除外設定を増やすとセキュリティが弱くならない？」と不安になるかもしれません。

そんな時は、Azure Advisor や Microsoft Defender for Cloud の「セキュリティ態勢」をチェックしましょう。

「基盤となる CSPM（無料版）」を有効にするだけで、Azureが「他にも設定ミス（暗号化漏れなど）はない？」と自動で診断してくれます。今回のWAF設定だけでなく、サイト全体の健康診断をセットで行うのが、モダンなクラウド運用のコツです。

最後に

WAFは「ただ置くだけ」では、時に味方を攻撃してしまうことがあります。

「いたちごっこ」に疲れたら、ぜひ除外設定の「範囲（スコープ）」を見直してみてください。

「ログを見て、原因を突き止め、ベストプラクティスを適用する」。この流れを一度経験すると、クラウドのセキュリティがぐっと身近に感じられるようになりますよ！

【おまけ】WAFのブロック理由を特定するKQLクエリ

Azure WAFが「何を」「どのルールで」ブロックしたのかを調べるためのクエリです。

Azure Portalの Log Analytics で実行してください。

1. 直近のブロック履歴を一覧表示する

まずは「何が起きているか」の全体像を把握するクエリです。

// WAFのブロックログを新しい順に100件表示

AzureDiagnostics

| where ResourceProvider == "MICROSOFT.NETWORK"

| where Category == "ApplicationGatewayFirewallLog"

| where action_s == "Blocked"

| project TimeGenerated, clientIp_s, requestUri_s, ruleId_s, Message, details_data_s

| order by TimeGenerated desc

| take 100

2. 特定のCookieが原因でブロックされているか特定する

今回の「犯人（Cookie）」を追い詰めるためのクエリです。

// 特定のCookie名が含まれるブロックログを抽出

AzureDiagnostics

| where ResourceProvider == "MICROSOFT.NETWORK"

| where Category == "ApplicationGatewayFirewallLog"

| where action_s == "Blocked"

// ↓ここに調べたいCookie名（.AspNetCore.Mvc.CookieTempDataProviderなど）を入れます

| where details_data_s contains "CookieTempDataProvider"

| project TimeGenerated, clientIp_s, ruleId_s, details_data_s, details_message_s

| order by TimeGenerated desc

3. どのルールIDによく引っかかっているか集計する

「いたちごっこ」が起きていることを証明するためのクエリです。

// ブロックされたルールIDのランキングを表示

AzureDiagnostics

| where ResourceProvider == "MICROSOFT.NETWORK"

| where Category == "ApplicationGatewayFirewallLog"

| where action_s == "Blocked"

| summarize Count = count() by ruleId_s, Message

| order by Count desc

ワンポイントチェック

ruleId_s: どのルールに触れたかがわかります。

details_data_s: Cookieやリクエストの中身の「どの文字列」がダメだったのか、具体的な中身が表示されます。ここを見て Password=... ではなく、ランダムな英数字の羅列であれば、誤検知の可能性大です！

【解決】Azure VMで「The target machine has denied access」エラー！原因はパスワード間違いによるロックアウト？（0xC0000234）

2026-01-02T12:54:00.001+09:00

Azureの仮想マシン（VM）に突然RDP接続できなくなったことはありませんか？

「The target machine has denied access to this connection」というエラーが表示された場合、原因はネットワーク設定ではなく、パスワードの入力ミスによる「アカウントロックアウト」かもしれません。

本記事では、シリアルコンソールを使った原因特定方法から、具体的な復旧手順までを解説します。

1. 発生した事象とエラーメッセージ

まずは、どのような状況で接続できなくなったのかを記載します。

• 現象: RDP（リモートデスクトップ）接続時に拒否される。

• エラー文: The target machine has denied access to this connection.

• 心当たり: パスワードを数回間違えて入力した。

2. 原因の特定：シリアルコンソールでログを確認する

「本当にパスワード間違いが原因か？」を外側から特定する方法を紹介します。

手順:

Azureポータルから対象VMの「シリアルコンソール」を開く。

cmd → ch -si 1 でコマンドプロンプトを起動。

以下のコマンドでイベントログを確認。

wevtutil qe Security /q:"*[System[(EventID=4625)]]" /c:5 /f:text /rd:true

特定ポイント:

ログの中に以下の情報があれば、ロックアウトが確定です。

• 失敗の原因: アカウントのロックアウト

• 状態コード: 0xC0000234

3. 解決策：アカウントロックを解除する方法

ロックアウトされた場合の対処法は3つあります。

① 自動解除を待つ（30分〜1時間）

多くの設定では、一定時間経過するとロックが自動解除されます。急ぎでない場合は、「一切の操作をせず待つ」のが最も安全です。

② Azureポータルからパスワードをリセット（即時）

急ぎの場合は、Azureポータルの「パスワードのリセット」機能を使います。

Tips: 既存のパスワード（チームで共有しているもの等）を変えたくない場合は、一度「別パスワード」に変更してログインした後、OS内部の設定から元のパスワードに戻すのがコツです。

③ ネットワーク設定（NSG）の確認

もし上記でもダメな場合は、念のためNSG（ファイアウォール）でRDPポート（3389）が開放されているか、自分のIPアドレスが許可されているかを確認しましょう。

まとめ：予防策

• パスワード管理ツールを使用し、打ち間違いを防ぐ。

• 踏み台サーバー（Bastion）の利用を検討する。

Azure Pipelinesで.NET Coreビルドが失敗する原因と解決策｜デフォルトYAMLの修正ポイント

2025-12-31T22:16:00.003+09:00

以前書こうと思っていたのですが、バタバタしていてまとめる機会がなかなか無く、やっと時間が取れたので、昔を思い出しながら書いてみます。

1. はじめに：Azure Pipelinesは「おまかせ」で動かない？

Azure DevOpsを使い始めたばかりの頃、私は感動しました。

「.NET Core」というテンプレートを選ぶだけで、勝手にYAMLファイルが生成され、あとは実行ボタンを押すだけ。

「これでCI/CD対応完了だ！」と意気揚々と実行した結果、画面に表示されたのは無情な赤いバツ印（Failed）でした。

なぜ、Microsoft純正のテンプレートなのにそのままでは動かないのか？

今回は、初心者が必ずハマる「デフォルトYAMLの落とし穴」と、その修正ポイントをまとめます。

2. 【罠1】SDKのバージョンが合っていない

デフォルトのYAMLには、多くの場合「どのバージョンの.NET SDKを使うか」という指定が抜けています。その結果、Agent（ビルド用マシン）にインストールされている最新バージョンが使われ、古いプロジェクトや新しすぎるプロジェクトがビルドエラーになります。

解決策：UseDotNet@2 タスクを最初に追加する

ビルド（Build）タスクの前に、明示的にバージョンを指定するタスクを差し込みます。

steps:

- task: UseDotNet@2

displayName: 'Install .NET SDK 8.x'

inputs:

packageType: 'sdk'

version: '8.x' # 自分のプロジェクトのバージョンに合わせる

3. 【罠2】プロジェクトファイルが見つからない

デフォルトでは、リポジトリのルート（一番上の階層）に .csproj や .sln があることを想定しています。しかし、実際の開発では src/ フォルダの中にコードをまとめていることが多いはずです。

解決策：projects プロパティを書き換える

テンプレートのままだと、以下のようなエラーで止まります。

##[error]Project file(s) matching the specified pattern were not found.

これを防ぐために、ワイルドカードを使ってプロジェクトファイルを指定します。

修正前（デフォルト）:

- task: DotNetCoreCLI@2

inputs:

command: 'build'

arguments: '--configuration $(buildConfiguration)'

修正後：

- task: DotNetCoreCLI@2

inputs:

command: 'build'

# リポジトリ全体から.csprojを探すように指定

projects: '**/*.csproj'

arguments: '--configuration $(buildConfiguration)'

4. 【罠3】NuGetリストアの失敗

「ビルドタスクの中で一緒にリストア（ライブラリの復元）もやってくれるだろう」と思いがちですが、ここでも認証エラーやパスの問題が起きることがあります。

解決策：Restoreタスクを分離して明示する

ビルドとは別に restore コマンドを明示的に実行するのが、安定させるコツです。

- task: DotNetCoreCLI@2

displayName: 'Restore NuGet Packages'

inputs:

command: 'restore'

projects: '**/*.csproj'

5. まとめ：デフォルトは「完成品」ではなく「下書き」

Azure Pipelinesが用意してくれるデフォルトのスクリプトは、あくまで「最低限の構成案」です。

1. SDKバージョンを指定する

2. プロジェクトの階層（パス）を正しく伝える

3. リストア、ビルド、テストを順序よく構成する

この3点を意識するだけで、あの赤いエラー画面から卒業できるはずです。

【Azure】App ServiceのIP制限でハマった話。「確認くん」と違うIPが届く原因と調査法

2025-12-29T17:13:00.002+09:00

Azure App Serviceで特定の拠点のみアクセスを許可しようと「アクセス制限」を設定したのに、なぜか自分すら弾かれる……。

「ログストリームを見れば原因がわかるはず」と思いきや、実はここには大きな罠があります。

今回は、App Service（特にLinuxベース）を使い始めたばかりの人が必ずハマる「IP制限の正体」と、正しいトラブルシューティング術について実体験を元に解説します。

1. 罠：403エラーのログは「ログストリーム」には出ない

ApacheやNginxの感覚でいると、「アクセス拒否（403エラー）されたならログが出るはず」と考えがちです。しかし、App Serviceのログストリームをどれだけ眺めても、IP制限で拒否されたログは1行も流れてきません。

なぜ出ないのか？

App ServiceのIP制限は、アプリに届く前の「Azureのプラットフォーム階層」で遮断されるからです。

• アプリ側のログ: アプリまで到達したリクエストの記録。

• IP制限: アプリに届く前に門前払いするため、アプリ側は「アクセスがあったこと」すら知りません。

2. 解決策A：ログが見れないなら「外側」から叩く

App Service側のログが見れない状況で、私が「真の接続元IP」を特定した方法が curl や tcpping です。

「確認くん」などのWebサービスで見えるIPは、ブラウザ（プロキシ経由）のIPに過ぎません。実際の通信がどう見えているかを直接叩いて確認します。

• curlで叩く: curl -v https://your-app.azurewebsites.net

• tcpping / pspingで叩く: ポート443に対して直接疎通を確認。

私のケースでは、これらを試す中で「確認くん」とは別のIPがゲートウェイとして使われていることが判明し、そのIPを許可することで解決しました。

3. 解決策B：どうしてもログを見たいなら「診断設定」

「どうしてもAzure側で拒否されたIPの履歴を特定したい」という場合は、診断設定（AzureAppServiceHTTPLogs）を有効にする必要があります。

ただし、ここで注意したいのがコストです。

インフラチームから「Log Analyticsは高額になりがち」と釘を刺されることがありますが、これは大量のログを溜め続けると課金が膨らむためです。

• 賢い使い方: 調査時だけ有効にし、接続元IPが特定できたらすぐにオフにする。

これでコストを最小限に抑えつつ、確実に「Azureが拒否したIP」をあぶり出せます。

4. まとめ：クラウドを使いこなす「引き出し」を持とう

今回の教訓は以下の3点です。

1. IP制限のログは、アプリのログストリームには出ない。

2. Web用のIPと通信用のIPが違う可能性を疑い、curl等で直接叩く。

3. 診断設定は強力だが、コストを意識して「使い終わったら消す」のがプロの作法。

「設定したのに動かない、ログも出ない」と焦る前に、この構造を知っていれば数分で解決できます。プログラムのコードだけでなく、こうした「クラウドの仕様」を知ることこそが、開発をスムーズに進める鍵となります。