はじめに こんにちはPSの佐々木です GitHub Copilot、ChatGPT、Claude等の生成AIツールは、現代のソフトウェア開発において不可欠な存在となっています。しかし、これらの生成AIが提案するコードには、意図せずライセンス違反を引き起こす可能性が潜んでいます。本記事では、生成AI開発におけるライセンス違反リスクと、SCANOSSを活用した効果的な対策について解説します。 生成AI開発におけるライセンス違反リスク 生成AIが学習するオープンソースコード 生成AIは膨大なオープンソースコードから学習しており、その中には様々なライセンスが適用されたコードが含まれています。AI が学習データから再現するコードには、以下のようなリスクが存在します： 意図しないライセンス違反 生成AIが提案したコードが、GPLやAGPLライセンスの既存コードと酷似している可能性 開発者が気づかないうちに、商用製品にコピーレフトライセンスのコードを組み込んでしまうリスク 従来のライブラリ依存関係では発見できない、コードスニペットレベルでの違反 企業が直面する課題 ライセンス違反リスクを恐れて、生成AIツールの導入を躊躇する企業が増加 開発効率向上のメリットと、法的リスクの間でのジレンマ 既存のライセンス検査ツールでは検出できない新しいタイプのリスク 具体的なリスクシナリオ ケース1: コードスニペットの意図しない複製 # 生成AIが提案したコードの例 def quicksort(arr): if len(arr) <= 1: return arr pivot = arr[len(arr) // 2] left = [x for x in arr if x < pivot] middle = [x for x in arr if x == pivot] right = [x for x in arr if x > pivot] return quicksort(left) + middle + quicksort(right) このようなコードが、実際にはGPLライセンスの既存プロジェクトから学習されている可能性があります。 ケース2: アルゴリズムの実装パターン 特定のアルゴリズムの実装において、生成AIが学習したコピーレフトライセンスのコードと同じパターンを再現してしまうケース。 主要なOSSライセンスと違反リスク パーミッシブライセンス（低リスク） MIT License 商用利用可能、制限が最小限 著作権表示のみ必要 生成AIで再現されても比較的リスクは低い Apache License 2.0 特許権の明確な規定あり 変更箇所の明記が必要 企業利用において安全性が高い BSD License シンプルで制限が少ない 商用利用に適している コピーレフトライセンス（高リスク） GPL (GNU General Public License) 最も注意が必要なライセンス 派生物もGPLライセンスでの配布が必要 商用製品での利用時、全ソースコードの開示義務 生成AIが無意識に組み込むと重大なリスク AGPL (GNU Affero General Public License) GPLよりもさらに厳しい条件 SaaS提供時でもソースコード開示が必要 クラウドサービス開発で特に危険 LGPL (GNU Lesser General Public License) ライブラリ自体の変更時のみソースコード開示 動的リンクの場合は比較的安全 弱いコピーレフトライセンス（中リスク） MPL (Mozilla Public License) ファイルレベルでのコピーレフト 変更したファイルのみソースコード開示 他のライセンスコードとの組み合わせは可能 SCANOSSによる生成AIコードの検知と対策 SCANOSSの独自技術 コードスニペットレベルでの検出 SCANOSSは、従来のライセンス検査ツールでは困難だった、わずか数行のコードスニペットからでも元のOSSコンポーネントとライセンスを特定できます： フィンガープリンティング技術 : コードの構造的特徴を分析し、部分的なコードからも元のライセンスを特定 機械学習による高精度マッチング : 大量のオープンソースコードデータベースから学習したパターンマッチング リアルタイム分析 : 開発中にリアルタイムでライセンス確認が可能 生成AIコードの包括的スキャン 開発ワークフロー統合 # 生成AIで作成されたコードの包括的スキャン scanoss scan --ai-generated-code --include-snippets /path/to/project # 特定のライセンスポリシーを適用したスキャン scanoss scan /path/to/project --policy-file corporate-policy.json --fail-on-license GPL-3.0 # CI/CDパイプラインでの自動スキャン scanoss scan . --output-format spdx --include-ai-analysis 検出できる違反パターン 生成AIによる既存コードの部分的な複製 Stack Overflowなどからコピーしたコードスニペット 依存関係に含まれないコードレベルでのライセンス違反 バイナリファイルに埋め込まれたコードの検出 実践的な生成AI開発でのライセンス管理 開発プロセスへの組み込み 1. コード生成時の即座チェック # 開発者のワークフロー例 # 1. 生成AIでコードを生成 # 2. SCANOSSで即座にライセンスチェック # 3. 問題があれば代替案を検討 # 4. 安全なコードのみを採用 2. CI/CDパイプライン統合 プルリクエスト時の自動スキャン 本番デプロイ前の包括的チェック ライセンス違反の検出時の自動アラート 3. 継続的な監視 新しい依存関係の追加時の自動チェック 既存コードの定期的な再スキャン ライセンスポリシーの更新時の全体チェック 企業でのライセンスポリシー策定 リスクレベル別の対応 高リスク（GPL、AGPL） : 原則使用禁止、例外時は法務承認必須 中リスク（LGPL、MPL） : 使用条件の明確化、適切な分離 低リスク（MIT、Apache、BSD） : 適切な著作権表示で使用可能 生成AIコードの承認プロセス 開発者による初期スキャン 自動化ツールによる検証 法務部門による最終承認（高リスクライセンス検出時） まとめ 生成AI時代のソフトウェア開発において、ライセンス管理は新たな複雑さを増しています。従来のライブラリレベルでの検出では捉えきれない、コードスニペットレベルでの違反リスクが現実のものとなっています。 SCANOSSのような専門的なツールを活用することで、以下のメリットを実現できます： 技術的メリット コードスニペットレベルでの高精度検出 生成AIコードの包括的な分析 開発ワークフローへのシームレスな統合 ビジネスメリット 法的リスクの大幅な軽減 生成AI導入による開発効率向上の安全な実現 コンプライアンス要件の確実な遵守 今後、生成AIがさらに普及する中で、適切なライセンス管理体制の構築は、企業の競争優位性を維持するための必須要件となるでしょう。早期にこれらの仕組みを整備し、安全に生成AIのメリットを享受できる環境を構築することが重要です。 サイオステクノロジーではSCAN OSSをサポートしています。 https://sios.jp/products/oss/scanoss/ ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 生成AI時代のライセンス管理：SCANOSSによる違反リスクの検知と対策 first appeared on SIOS Tech. Lab .

はじめに こんにちは！重要な機能開発を任されて最近まで業務で手一杯だったなーがです。Windowsで開発環境を構築する際にGitやSSHなど、さまざまなツールの設定に時間を取られていませんか？PCを買い替えたり、突然PCが動かなくなったりしたときに新しい環境をセットアップするたびに同じ設定を繰り返すのは大変ですよね。 今回はそうした設定ファイルをGithubリポジトリとして管理することで、いつでも同じ開発環境を再現できる「 dotfiles 」という仕組みと、Windows環境に特化した具体的な構成をご紹介します。私も業務で使用しているPCのリプレース作業が近づいていることもあり、せっかくなので書いてみることにしました。スクリプトファイルは最後に付録として載せておきます！ 📁 dotfilesリポジトリの紹介 今回ご紹介するのは、Windows環境向けに作成されたdotfilesリポジトリです。このリポジトリは、設定ファイルを一元管理し、簡単なコマンド一つで環境のセットアップを完了させることを目的としています。GitHubで「dotfiles」と検索してみると、多くの人が自身の設定ファイルを公開しています。 https://github.com/search?q=dotfiles&type=repositories リポジトリは以下のような構成になっています。ここでは比較的一般的な設定ファイルに絞って紹介します。 dotfiles/ ├── README.md # このファイル ├── setup.ps1 # セットアップスクリプト ├── ssh/ # SSH設定 │ └── config ├── VSCode/ # Visual Studio Code設定 │ ├── settings.json │ └── keybindings.json └── WindowsTerminal/ # Windows Terminal設定 └── settings.json VS CodeやWindows Terminalといった主要な開発ツールの設定ファイルが、すべてこのリポジトリで管理されているのがわかりますね。 ここでキモとなっているのが setup.ps1 で、Ubuntu等のLinux環境の方は XXXX.sh を用意されていると思います。私はメイン業務がWindowsなので、今回はPowerShellのスクリプトファイルしか記載していません。このスクリプトはこのリポジトリ内で管理している各設定ファイルと各設定ファイルが本来配置される箇所とのシンボリックリンクを作成する役割があります。シンボリックリンクを張ることで、各設定ファイルをわざわざ配置することなく参照でき、各設定ファイルに行った変更は全てこのリポジトリ内で管理できるというメリットがあります。 このスクリプトファイルですが、一昔前であればPowerShellやシェルスクリプトの知識が必要で少しハードルが高かったですが、現在はClaudeやGitHub CopilotをはじめとしたViveコーディングが可能なため「この設定ファイルのシンボリックリンクを作成するスクリプトを作成して」とお願いして、少し手直しするだけで簡単に実現できます。いい時代になりましたね…かく言うこのスクリプトも大枠はAIに作成してもらいました！ 🚀 セットアップ方法 セットアップは非常にシンプルです。PowerShellスクリプトを実行するだけで、必要な設定ファイルへのシンボリックリンクが自動的に作成されます。 1. シンボリックリンクの作成 まず、管理者権限でPowerShellを開き、リポジトリ内にある setup.ps1 スクリプトを実行します。 # PowerShellを管理者として実行 .\\setup.ps1 このスクリプトを実行すると、以下の場所に設定ファイルのシンボリックリンクが作成され、リポジトリでの変更が即座に反映されるようになります。 VS Code設定 : %APPDATA%\\Code\\User\\ Windows Terminal設定 : %LOCALAPPDATA%\\Packages\\Microsoft.WindowsTerminal_8wekyb3d8bbwe\\LocalState\\ SSH設定 : %USERPROFILE%\\.ssh\\ Git設定 : %USERPROFILE%\\.gitconfig その他のshell設定 : .bashrc , .bash_profile , .vimrc など ⚙️ オプション セットアップスクリプトには、便利なオプションも用意されています。 強制上書きモード すでに設定ファイルが存在する場合でも強制的に上書きしてシンボリックリンクを作成します。 .\\setup.ps1 -Force カスタムパス指定 dotfilesを異なる場所にクローンした場合でも、パスを指定して実行できます。 .\\setup.ps1 -DotfilesPath "C:\\path\\to\\your\\dotfiles" さいごに 今回は、Windows環境における設定ファイルの管理と自動化を行うdotfilesリポジトリを紹介しました。このような仕組みを活用することで、環境構築の手間を大幅に削減し、より本質的な開発作業に集中できます。 ぜひ、このリポジトリを参考に、ご自身の最強の開発環境を構築してみてはいかがでしょうか。 付録 <# .SYNOPSIS dotfilesフォルダ内のファイルのシンボリックリンクを作成するスクリプト .DESCRIPTION dotfilesフォルダ内にある設定ファイルを、適切な場所にシンボリックリンクとして作成します。 管理者権限が必要です。 .PARAMETER DotfilesPath dotfilesフォルダのパス（デフォルト: .） .PARAMETER Force 既存のファイルを上書きするかどうか .EXAMPLE .\Create-DotfilesSymlinks.ps1 .EXAMPLE .\Create-DotfilesSymlinks.ps1 -DotfilesPath "C:\dotfiles" -Force #> param( [Parameter(Mandatory = $false)] [string]$DotfilesPath = ".", [Parameter(Mandatory = $false)] [switch]$Force ) # 管理者権限チェック function Test-Administrator { $currentPrincipal = New-Object Security.Principal.WindowsPrincipal([Security.Principal.WindowsIdentity]::GetCurrent()) return $currentPrincipal.IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator) } # シンボリックリンク作成関数 function New-SymbolicLink { param( [string]$LinkPath, [string]$TargetPath ) try { # リンク先のディレクトリが存在しない場合は作成 $linkDir = Split-Path -Parent $LinkPath if (-not (Test-Path $linkDir)) { New-Item -ItemType Directory -Path $linkDir -Force | Out-Null Write-Host "ディレクトリを作成しました: $linkDir" -ForegroundColor Green } # 既存のファイル/リンクをチェック if (Test-Path $LinkPath) { # 既存のパスがシンボリックリンクかどうか確認 $item = Get-Item -Path $LinkPath -Force $isSymLink = $item.Attributes -band [System.IO.FileAttributes]::ReparsePoint if ($isSymLink) { # シンボリックリンクの場合はスキップ Write-Warning "シンボリックリンクが既に存在します: $LinkPath (スキップ)" return $false } else { # 既存ファイルは削除 Remove-Item $LinkPath -Force Write-Host "既存のファイルを削除しました: $LinkPath" -ForegroundColor Yellow } } # シンボリックリンクを作成 New-Item -ItemType SymbolicLink -Path $LinkPath -Target $TargetPath -Force | Out-Null Write-Host "シンボリックリンクを作成しました: $LinkPath -> $TargetPath" -ForegroundColor Green return $true } catch { Write-Error "シンボリックリンクの作成に失敗しました: $LinkPath -> $TargetPath" Write-Error $_.Exception.Message return $false } } # メイン処理 function Main { Write-Host "=== Dotfiles シンボリックリンク作成スクリプト ===" -ForegroundColor Cyan # 管理者権限チェック if (-not (Test-Administrator)) { Write-Error "このスクリプトは管理者権限で実行する必要があります。" Write-Host "PowerShellを管理者として実行してから再度お試しください。" -ForegroundColor Yellow exit 1 } # dotfilesフォルダの存在チェック if (-not (Test-Path $DotfilesPath)) { Write-Error "dotfilesフォルダが見つかりません: $DotfilesPath" exit 1 } $DotfilesPath = Resolve-Path $DotfilesPath Write-Host "dotfilesフォルダ: $DotfilesPath" -ForegroundColor Cyan # ファイルマッピング定義 # 必要に応じて追加・変更してください $fileMappings = @{ # Git設定 ".gitconfig" = "$env:USERPROFILE\.gitconfig" # VS Code設定 "VSCode\settings.json" = "$env:APPDATA\Code\User\settings.json" "VSCode\keybindings.json" = "$env:APPDATA\Code\User\keybindings.json" # Windows Terminal設定 "WindowsTerminal\settings.json" = "$env:LOCALAPPDATA\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\settings.json" # SSH設定 "ssh\config" = "$env:USERPROFILE\.ssh\config" # その他の設定 ".bashrc" = "$env:USERPROFILE\.bashrc" ".bash_profile" = "$env:USERPROFILE\.bash_profile" ".vimrc" = "$env:USERPROFILE\.vimrc" ".minttyrc" = "$env:USERPROFILE\.minttyrc" ".wslconfig" = "$env:USERPROFILE\.wslconfig" } $successCount = 0 $skipCount = 0 $errorCount = 0 Write-Host "`n--- シンボリックリンクの作成を開始します ---" -ForegroundColor Cyan foreach ($mapping in $fileMappings.GetEnumerator()) { $sourcePath = Join-Path $DotfilesPath $mapping.Key $targetPath = $mapping.Value # ソースファイルの存在チェック if (-not (Test-Path $sourcePath)) { Write-Warning "ソースファイルが見つかりません: $sourcePath (スキップ)" $skipCount++ continue } Write-Host "`n処理中: $($mapping.Key)" $result = New-SymbolicLink -LinkPath $targetPath -TargetPath $sourcePath -ForceOverwrite $Force if ($result) { $successCount++ } else { if ((Test-Path $targetPath) -and -not $Force) { $skipCount++ } else { $errorCount++ } } } # 結果サマリー Write-Host "`n=== 処理結果 ===" -ForegroundColor Cyan Write-Host "成功: $successCount" -ForegroundColor Green Write-Host "スキップ: $skipCount" -ForegroundColor Yellow Write-Host "エラー: $errorCount" -ForegroundColor Red if ($errorCount -eq 0) { Write-Host "`nシンボリックリンクの作成が完了しました！" -ForegroundColor Green } else { Write-Host "`n一部のシンボリックリンクの作成に失敗しました。上記のエラーメッセージを確認してください。" -ForegroundColor Yellow } } # スクリプト実行 Main ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post PCの環境構築を迅速かつ簡単に！dotfilesで設定管理を始めよう first appeared on SIOS Tech. Lab .

挨拶 ども！最近はClaudeの制限を見ると嬉しくなっちゃう龍ちゃんです。最近は日常作業をプロンプト化して、効率化を模索しています。割と毎日触っているので、それなりにストレスも抱えてブログを書けるぐらいにはナレッジが溜まりましたね。 今回は、Claudeに感謝を持ちつつ「もうちょっとこうして！」という不安を解消するためのプロンプトテクニックについてまとめていこうと思います。 公式が出しているプロンプトジェネレーターを使うのも一つの手ですよ！ よくあるClaude暴走パターン Claude使ってて「もう！」って思ったことありませんか？以下、僕が普段困っているClaudeあるあるをまとめました。 前提として人間側が投げるプロンプトが雑であるところが原因になります。 パターン1：過剰なArtifact生成問題 気づいたら大規模なArtifactが作られるなんてことありませんか？これはよくある「Claude君止まって！案件」ですね。実際に僕が出会った暴走例を以下に示します。 典型例 ユーザー：「Chakra UIのモーダルでJSON文字列を表示したい」 Claude：「Chakra UIのモーダルでJSON文字列を表示する方法をご紹介します。」 → 高機能もりもりモーダルの作成 期待していたもの 50行程度のシンプルなコード Chakra UIの基礎的なモーダルでJSON文字列を表示する方法 現実 300行弱の実践的なコード 高機能モーダル（表示切替機能） 高機能モーダル（コピー機能） 高機能モーダル（編集機能） その他の構造化暴走例 勝手に体系化 ：「プロジェクト管理のコツある？」→ 階層化された管理手法分類 勝手にステップ化 ：「転職活動どうしよう」→ 12段階の転職完全ロードマップ 勝手にチェックリスト化 ：「会議の準備って何する？」→ 50項目の準備チェックリスト 普通に質問として聞きたいだけなのに、なぜか教科書レベルの資料を作られてしまう現象です。 パターン2：スレッド肥大化問題 まだ聞きたいことがあったのに、「スレッドの上限に達しました、別スレッドでお願いします」と言われたことありませんか？Artifactがv22なんて更新地獄を味わったことなど、気になることを聞いているとスレッドの容量がパンパンになって、Claudeの動作もなんだか遅くなっている…なんてことありませんか？ 典型的な流れ 軽い質問をする Claudeが詳細な回答 + アーティファクト生成 「もうちょっと詳しく」と追加質問 さらに詳細な資料が追加される やり取りが膨大になる スレッド上限に到達してリセット 文脈が失われて振り出しに戻る あるあるシーン ユーザー：「このコードどう思う？」 Claude：改善版コード + 詳細解説を生成 ユーザー：「エラーハンドリングも追加して」 Claude：完全版コード + エラー対応ガイドを生成 ユーザー：「テストも書いて」 Claude：テストコード + テスト戦略文書を生成 …（10往復後） システム：「スレッド上限に達しました」 パターン3：人間追いつけない問題 「昨今のAIの問題は、人間の理解が追い付いていないから一番のボトルネックは人間の頭」って投稿をXで見かけた気がするんですけど、これ結構好きなんですよね。実際にWebSearch系の機能がついてから、ネットに接続できるようになったじゃないですか。あれから調べもの系はClaudeかGeminiに任せたほうが精度高いんですよね。その情報を確認しますけど、読み込ませて質問ベースで聞いちゃうほうが早いんです。こりゃ困ったなってところですね。 ボトルネックは人間の頭 Claudeの処理速度 vs 人間の理解速度のギャップが生む問題。 典型例 ユーザー：「新サービスのアイデア考えて」 Claude：（10秒で） - 詳細な事業計画 - 市場分析レポート - 技術仕様書 - マーケティング戦略 - 収益予測 人間：「えーっと...まず何から読めば...」（理解に30分） よくあるパターン 情報過多で頭パンク ：求めた以上の情報量で思考停止 判断材料が多すぎて決められない ：選択肢を増やしすぎて逆に困る 完璧すぎて修正しにくい ：隙のない提案で改善点が見つからない Claudeが優秀すぎて、人間側の処理が追いつかない現象です。 共通する課題 これらの暴走パターンに共通するのは： 過剰な解決志向 ：問題を見つけると完璧に解決しようとする 文脈の読み違い ：軽い質問を重要なタスクと誤解 成果物化癖 ：何でもアーティファクトにしたがる 完璧主義 ：中途半端よりも完全版を作りたがる いろいろ分析してみましたが、結局のところ人間側のプロンプトがあいまいってところに落ち着くんですよね。というかそこを頑張らないと人間がいる意味がないといいますか…技術として向上していく必要があるなって話です。 AIが優秀になるにつれて、「何を求めているのか」「どのレベルの回答が欲しいのか」を明確に伝えるスキルが重要になってきています。つまり、プロンプトエンジニアリングが日常的な必須スキルになっているということですね。 そんなわけで、普段使っているプロンプトテクニックといえるほどでもないですが、暴走を抑えることができるプロンプトを紹介していきます。 次の章からは、実際にプロンプトテクニックを紹介していきます。 Claude制御テクニック集 Claudeの暴走は「Claudeが悪い」のではなく、 100%人間側のプロンプトが曖昧 なのが根本原因。明確な指示で適切にコントロールしましょう。 基本原則：「Claudeは優秀すぎるから、明確に指示する」 まず大前提です。Claudeはめちゃくちゃ賢いやる気満々な子です。そしてすごくいい子です。基本全工程だし、めちゃくちゃほめてくれます。でも、会社の先輩や同僚みたいに自分の思考の癖や理解しているレベルを理解はしてくれません。なので、めちゃくちゃ賢くてやる気のある赤子ぐらいに思ってるとちょうどよいです。 Claudeは曖昧な質問を見ると「きっと詳しく知りたいんだろう」と解釈して、全力で応えようとします。それが「暴走」に見える現象の正体です。 なので、トークン数を気にせずにプロンプトは詳細であるほど良いですね。多少の例を渡すFew-shotやone-shotなんて技術ありましたけど、あれはゴールを明確にするって良い手法ですよね。この辺は海外の論文を読んだりすると詳細な分析が流れてくるので、検索するとおもしろいですよ。 今回は、体感できる簡単なテクニックを解説していきます。 制御テクニック1：成果物制御テクニック これはダイレクトにArtifact生成を制御するプロンプトになります。例で紹介した「Chakra UIのモーダルでJSON文字列を表示したい」では、大体はArtifact生成を進めますが、時にはチャット形式で返答することもあります。これは求めている形式を指定していないことで起きます。 根本原因 Claudeが勝手に「Goal」を定義して作ってしまう 「JavaScriptの関数について教えて」→ Claude「詳細なリファレンスが必要だ！」 「プロジェクト管理のコツある？」→ Claude「体系的なガイドを作ろう！」 Goalの定義 簡単なのは、「Goalの定義」を行うことです。以下がテンプレートになります。 Chakra UIのモーダルでJSON文字列を表示したい Goal：初心者でもわかるようにコード内にコメント多めで、コードサンプルArtifactを生成して Goal: として最終的なゴールを示してあげることで、Claudeはそこに向かって走ってくれます。今回はサンプルなので、簡単なゴール設定になっています。ただ、最終的な成果物の制限を追加することで向かってくれます。効果測定のために別のプロンプトを張ってみますね。 Chakra UIのモーダルでJSON文字列を表示したい Goal：初心者でもわかるようにコード内にコメント多めで、マークダウン形式でコード解説付きArtifactを生成して こちらでマークダウンファイルが作成されます。一言表現を変えるだけで幅が変わります。 成果物の否定 こちらも効果的です。普段だとやってほしいことを書くじゃないですか？これはそちらとは逆ですね。やってほしくないことを伝えるのも効果的です。強い言葉であるほど意識してくれますね。この辺は、スレッドが長くなるほど効果が薄れていく感じは多少あります。過去の情報って忘れていくんですよね。 ✅ 良い例： 「成果物を作らずに、考え方だけ教えて」 「Artifactは不要で、チャットで答えて」 「アプリ作成は不要、アドバイスだけお願いします」 「資料にしないで、会話として答えて」 「禁止事項：Artifact生成」 前提の共有 こちらは先ほど紹介した上の二つよりもさらにライトですが、普段使いとしては十分かもしれません。だんだん指示が友達に与えるみたいになっているのが良いんですよね。 ✅ 良い例： 「3行くらいで説明して」 「要点だけお願いします」 「一言でどう思う？」 「概要だけざっくりと」 「普通に会話として答えて」 段階的アプローチ これはおすすめです。「Goalの明確化」や「成果物の否定」や「前提の共有」のテクニックを文章として暗黙に伝えています。よく使うのは「ステップバイステップ」ですね。 ✅ 良い例： 「まずは概要だけ教えて、詳しく知りたくなったら追加で質問するから」 「まず一言で説明して、分からなかったら詳しく聞くよ」 「基本だけ教えて、応用は後で」 「ステップバイステップで」 龍ちゃんおすすめプロンプト 個人的に設定しているシステムプロンプトを共有しますね。ブログの校閲として使っているClaudeなんですが、これを設定しておくと精度が爆上がりしました。 情報を作成をする前に具体的なプランを明示して許可を取ってから実行をしてください。 許可が出るまで生成はしないでください。 明確な指示がない場合は、文章の校閲をしてほしいと解釈してください。 制御テクニック2：会話継続テクニック スレッドの上限まで達成したことがある方は、もうClaude沼にどっぷりと浸かっていますね。素晴らしいことです。でも、スレッド上限に達してしまって、また前提の共有からなんてやってられないですよね。Claudeはメモリ機能がないので、スレッドではまた別のClaudeとお話することになります。関係値を一から作る必要があります（ぴえんである）。 そんな時に使えるテクニックについて紹介します。 引継ぎ資料作成 → 新スレッド移行 これはスレッドがパンパンになる直前にやっておくとマジで助かります。スレッドの内容をPDFで出力させてしまい、それを新規スレッドの初回に入力として与えることで疑似的にスレッドの会話を継続させることができます。 ✅ 良い例： 「今までの議論を引継ぎ資料にまとめて。新しいスレッドでその資料をベースに続きをやりたい」 「現時点の作業までで決定したことを引継ぎ資料として作成して」 AI間役割分担によるトークン分散 これは、そもそもスレッドの上限に達しないようにするテクニックです。処理を事前に人間側で分散しておき、その段階ごとにスレッドを分けて中間ファイルを生成させておきます。最終的な成果物ファイルを生成する前に段階を踏ませることで、スレッド内のトークン数を分散させます。 ✅ 良い例： 調査用 Claude:「xxxxxxxxに関する調査をしてマークダウン形式でまとめて」 プロンプト生成用 Claude:「添付したファイルをもとに〇〇〇生成用プロンプトを生成して」 生成用 Claude:「添付ファイルからよろしく～」 Artifactベースの新規Artifact作成 これは生成されたものをベースに新規のArtifactを生成することで、対象とするArtifact自体を軽量化する手法です。Artifactベースに新規のArtifactを作成する場合は以下の二つの目的で生成します。 軽量版Artifactを生成する：いらない要素をそぎ落とす 新規Artifactを生成する：大きくなりすぎたファイルを分割する 軽量版 大きいArtifactから内容を抽出して、軽量化することができます。Artifact生成でいらない要素がくっついてくることがたまにありますよね？それらをそぎ落とすことで、軽量化されます。Artifactの中身をセクションごとに分割することで、対象とするファイルの大きさを小さくすることもできます。 ✅ 良い例： 「このアーティファクト重くなりすぎたから、軽量版で作り直して」 「要点だけに絞った簡易版を新しく作って」 「今の成果物をベースに、コンパクト版お願いします」 新規Artifact ✅ 良い例： 「今までの議論を踏まえて、新しいアーティファクトで整理し直して」 「別の成果物として、今回の結論をまとめて」 「前のは置いといて、新規で作り直そう」 段階的成果物更新 これは、小さなArtifactを段階的に更新する手法です。プロンプトでArtifact生成を止めておいて、「段階的に」と指示をすることで小さなArtifactに対して段階的更新をかけていきます。これの良い点は、Artifact生成を人間がちゃんと監視しているので、「なんか方向性が違う！」というのがすぐわかる点がよいですね！ ✅ 良い例： 「成果物を少しずつ更新していこう」 「この部分だけ先に反映させて」 「一気に全部やらずに、段階的に進めよう」 制御テクニック3：ペース調整テクニック（人間主導の学習プロセス） これはClaudeが出力したコードを正として使用するのではなく、 人間がペースを握って学習を進める 方法です。体感的には、Claudeが100%完璧なコードを出すケースは少ないですが、領域を限定して小さく出力させることで、より確実に動くコードを生成できます。 基本的な学習ステップ 大枠を作成してもらう – 全体像を把握 特定の領域に対して深堀り質問 – 段階的に理解を深める わからない部分は説明を求める – 疑問点を即座に解決 理解度確認のために自分の言葉で例え話 – 学習の定着を図る 学習フロー図 制御テクニック3（実践例）：Kubernetesの学習過程 この手法を活用して、Kubernetesが一切わからない段階から、新規作成したDaemonSetを検証環境にデプロイできるレベルまで到達した実例をご紹介します。 1. 大枠把握からスタート 入力例： k8sに関しては一ミリもわからないのですが、初心者が理解しておくべきポイントをまとめてください。 出力例： Kubernetesの初心者向け重要ポイントをまとめます： ## Kubernetesとは何か Kubernetesは、コンテナ化されたアプリケーションを自動的に管理・運用するためのオープンソースのプラットフォームです。「k8s」と略されることが多く、これは「k」と「s」の間に8文字あることから来ています。 ## 基本概念 - **クラスター**: Kubernetesが管理するサーバー群全体 - **ノード**: 実際にアプリケーションが動く個々のサーバー - **Pod**: アプリケーションの最小実行単位 - **デプロイメント**: Podの管理・配置を行う仕組み ~~~~~以下略~~~~~ 2. 理解確認型学習 入力例： ノードとDaemonSetとPodの理解から始めればよいかな？ 出力例： はい、それはとても良い学習順序です！ ## なぜこの3つから始めるのが良いか この3つの関係を理解すると、Kubernetesの基本的な構造が見えてきます： - **ノード** → 物理的な土台（サーバーやコンピューター） - **DaemonSet** → 管理の仕組み（「各ノードに1つずつ配置する」というルール） - **Pod** → 実際に動くアプリケーション ## 学習の順序 1. まずノードを理解（土台） 2. 次にPodを理解（実際に動くもの） 3. 最後にDaemonSetを理解（管理の仕組み） ~~~~~以下略~~~~~ 3. 段階的深堀り学習 入力例： Podが最小構成なのは知っています。 PodがDockerのコンテナーって理解であってる？ 出力例： いえ、少し違います。Pod ≠ Dockerコンテナです。 ## 正しい関係 PodはDockerコンテナを入れる箱のようなものです： Pod（箱） ├── Container 1（メインアプリケーション） ├── Container 2（サイドカーコンテナ）※オプション └── 共有リソース（ネットワーク、ストレージ） ## 重要なポイント - 1つのPodに複数のコンテナを含めることができる - 同じPod内のコンテナは同じネットワーク（IPアドレス）を共有 - 多くの場合、1Pod = 1Container として使用される ~~~~~以下略~~~~~ 続きの質問： Pod内にContainerがある関係なのね。Podとコンテナは同一のものではないけど、要素として共通点は多い印象かな ただ、k8sの環境ではPodという概念で管理しているだけって感じ？ 出力例： まさにその通りです！とても良い理解ですね。 ## あなたの理解は正確です Pod ⊃ Containerの関係で、確かに機能的には似ている部分が多いです。 ## なぜPodという概念が存在するのか 1. **複数コンテナの協調動作**: 1つのアプリケーションを複数の小さなコンテナで構成 2. **リソース共有**: 同じPod内のコンテナは簡単にデータをやり取りできる 3. **運用の単位**: Kubernetes では Pod単位でスケジューリング・管理 ## 実際の開発では 90%以上のケースで「1Pod = 1Container」で運用されています。 Podは「コンテナを管理するための仕組み」と考えるのが適切です。 ~~~~~以下略~~~~~ 4. 理解度チェックの要求 入力例： ノード上には複数のPodが含まれる可能性がある Deploymentは管理しているクラスター全体で特定の数配置できる DaemonSetはノードの数分だけPodをノード内に一つ配置できる であってる？ 出力例： はい、完璧に正確です！ ## あなたの理解 ✓ ✓ **ノード上には複数のPodが含まれる可能性がある** ✓ **Deploymentはクラスター全体で特定の数配置できる** ✓ **DaemonSetはノードの数分だけPodをノード内に一つ配置できる** ## 図解で確認 ```bash クラスター全体 ├── ノード1 │ ├── Pod A（Deployment管理） │ ├── Pod B（Deployment管理） │ └── Pod X（DaemonSet管理）← 各ノードに必ず1つ ├── ノード2 │ ├── Pod C（Deployment管理） │ └── Pod Y（DaemonSet管理）← 各ノードに必ず1つ └── ノード3 └── Pod Z（DaemonSet管理）← 各ノードに必ず1つ ``` ## 使い分け - **Deployment**: Webアプリケーションなど、必要な数だけ配置 - **DaemonSet**: ログ収集、監視エージェントなど、全ノードに配置が必要 ~~~~~以下略~~~~~ 5. ネクストステップ 入力例： 次はネームスペースについて勉強したい このテクニックの効果 メリット 学習者主導 : 自分のペースで理解を深められる 段階的理解 : 一度に大量の情報を処理しなくて済む 確実な定着 : 理解度を確認しながら進むため、知識が定着しやすい 応用可能 : 様々な技術領域で応用できる 適用シーン 新しい技術の学習 複雑なシステムの理解 コード理解とデバッグ 設計パターンの習得 実践のコツ 1. 質問の仕方 ❌ 悪い例：「Kubernetesを教えて」 ✅ 良い例：「Kubernetesの基本概念を3つに絞って教えて」 2. 理解度確認 ❌ 悪い例：「わかりました」 ✅ 良い例：「つまり、Podは家でコンテナは住人のような関係ですね？」 3. 段階的深堀り ❌ 悪い例：「すべて詳しく説明して」 ✅ 良い例：「まずノードの概念から理解したい」 このテクニックを使うことで、AIを効果的な個人チューターとして活用し、確実にスキルアップを図ることができます。 まとめ 今回は、Claudeの制御テクニックについて詳しく見てきました。最初は「Claude君止まって！」と思っていた暴走も、実は人間側のプロンプトが曖昧だったことが根本原因だったんですね。 今日から使える3つのポイント 1. 明確な指示が全ての基本 Goal設定や成果物の否定、前提共有で明確に方向性を示すことが重要です。 2. スレッド管理で効率的な会話継続 引継ぎ資料作成→新スレッド移行や、AI間役割分担でスレッド上限問題を解決できます。 3. 人間主導の学習プロセス 大枠把握→理解確認→段階的深堀り→理解度チェックの流れで、確実にスキルアップを図れます。 おわりに Claudeを「めちゃくちゃ賢くてやる気のある赤子」だと思って接すると、うまく付き合えるかもしれません。明確な指示を与えてあげることで、本当に強力なパートナーになってくれます。 この知識を活かして、より効率的なAI活用にチャレンジしてみてください！皆さんも、ぜひ自分なりのClaude調教術を編み出してみてくださいね。 それでは、良いClaude調教ライフを！ いろいろなAIのブログ 書いてますので、ぜひ読んでみてね！ ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Claude調教術｜暴走パターンを制御する3つのプロンプトテクニック first appeared on SIOS Tech. Lab .

はじめに こんにちは、サイオステクノロジーの小沼 俊治です。 これまで、オリジナルの MCP サーバーを開発するノウハウを、以下の記事で公開してきました。 第１弾： オリジナルのちょっと便利な MCP サーバー を作ってみた 第２弾： オリジナルのちょっと便利な『リモート MCP サーバー』を作ってみた その第３弾として、2025年6月下旬に、ローカル MCP サーバーをパッケージングして手軽に配布できる「Desktop Extensions（以下、デスクトップ拡張、または DXT と略して表す）」の仕組みが公開されたので、その最新ノウハウを共有します。 Claude Desktop Extensions: One-click MCP server installation for Claude Desktop anthropics/dxt ローカルMCPサーバーは、AIエージェントを自由に拡張できる非常に便利な機能です。しかし、これまでは開発ツールの準備や設定ファイルの編集など、インストールが複雑で IT リテラシーが高くないと導入が難しいという課題がありました。 今回の DXT の登場により、 パッケージングされたローカル MCP サーバーは、マウスのクリックやドラッグ＆ドロップといった簡単な操作でデスクトップ拡張としてインストールできるようになります。 これはMCPサーバーの普及を大きく加速させる画期的な仕組みであり、私自身も大変ワクワクしています！ 本ハンズオンはローカル MCP サーバーを対象とするため、第１弾「 オリジナルのちょっと便利な MCP サーバー を作ってみた 」の続きとして解説を進めます。引き続き、MCP サーバーの実装には Node.js を使用します。 構成概要 筆者が動かした際の主な構成要素は以下の通りです。 DXT 配布元となるローカル MCP サーバーの開発 PC Windows 10 Professional Claude desktop for Windows version 0.11.6 Windows PowerShell 5.1.19041.5737 Node.js v22.15.0 DXT 配布先となるローカル MCP サーバーの利用 PC Windows 10 Professional Claude desktop for Windows version 0.11.6 ハンズオンを構成する環境は以下の通りです。 MCP ホストは、ローカル MCP サーバーを組み込める Claude desktop のネイティブアプリ版を利用します。 配布元 PC の構成における主な考慮事項は以下の通りです。 MCP サーバーを稼働させる環境は Node.js 環境を選択しています。 TypeScript で実装したソースコードのトランスパイルや、デスクトップ拡張としてパッケージングするため Node.js のインストールが必要です。 配布先 PC の構成における主な考慮事項は以下の通りです。 デスクトップ拡張としてインストールした MCP サーバーの稼働には、Claude の組込み Node.js を利用できるため、別途 Node.js のインストールは不要です。 Claude にバンドルされた Node.js の利用について TypeScript で実装して JavaScript にトランスパイルされたローカル MCP サーバーを動かす場合には、Claude にバンドルされた Node.js を利用できます。 デフォルトで有効になっていますが、Claude desktop 画面左上のハンバーガーメニュー（三本線）から「ファイル > 設定…」で表示した設定画面で、左ペインより「エクステンション」を選び、画面下部の「詳細設定」ボタンをクリックすると組み込み Node.js の有効状態が確認できます。 ハンズオンの手順でパッケージングするローカル MCP サーバーの設定ファイルやソースコードは、以下の GitHub リポジトリで公開しています。必要に応じてご活用ください。 hands-on-mcp-sios-apisl @ GitHub v1.0.0 : オリジナルのちょっと便利な MCP サーバーを実装 配布元 PC で基礎環境の構築（第１弾の環境復元） 以前の記事「 オリジナルのちょっと便利な MCP サーバー を作ってみた 」で開発したローカル MCP サーバーのソースコード等のリソースが手元にある場合には、本章はスキップして以下の章へ進んでください。 ローカル MCP サーバーを Desktop Extensions で便利に配布してみた | 配布元 PC で DXT ファイルを作成 Claude desktop for Windows インストール MCP ホストに Web 版ではなくアプリ版の Claude desktop for Windows を利用するため、以下公式手順を参考に Windows PC へインストールします。 Claude for Desktopのインストール | Anthropicヘルプセンター Node.js インストール パッケージの作成に Node.js を必要とするため、以下手順を参考に Windows PC へインストールします。 初期環境構築: Node.js on Windows デスクトップ拡張にするローカル MCP サーバーの用意 ローカル MCP サーバーのリソースを用意する方法は２通りあります。お使いの環境に合わせて、いずれかの方法でリポジトリを取得してください。 方法１：Git コマンドで取得する Git がインストールされている場合は、以下のコマンドでリモートリポジトリをクローンします。 PS C:\Users\...\development> git clone https://github.com/Toshiharu-Konuma-sti/hands-on-mcp-sios-apisl.git -b v1.0.0 方法２：ブラウザでダウンロードする Git がインストールされていない、またはコマンド操作に不慣れな場合は、ブラウザから GitHub の以下 URL にアクセスし、「Source code (zip)」をクリックして Zip ファイルを取得します。 Release v1.0.0 · Toshiharu-Konuma-sti/hands-on-mcp-sios-apisl 配布元 PC で DXT ファイルを作成 配布元 PC でローカル MCP サーバーをパッケージングして、デスクトップ拡張（DXT ファイル）として配布できるようにします。 デスクトップ拡張のパッケージ作成には dxt コマンドが必要ですが、通常、このコマンドをグローバルインストール（ npm install -g @anthropic-ai/dxt ）すると管理者権限やルート権限が求められます。 本ハンズオンでは管理者権限なしで dxt コマンドのパッケージを直接実行できる npx コマンドを使って進めます。 パッケージングするリソースの準備 デスクトップ拡張としてパッケージングするために、ローカル MCP サーバーが実行可能な状態にして、必要なリソースを準備します。 依存パッケージの準備 まず始めに、依存パッケージをダウンロードします。 PS C:\Users\...\hands-on-mcp-sios-apisl> npm install 次に、TypeScript から JavaScript のソースコードをトランスパイルして生成するため、ビルドを行います。 PS C:\Users\...\hands-on-mcp-sios-apisl> npm run build アイコンの準備 アイコンの設定は必須ではありませんが、 配布先の利用者にとって製品としての完成度が高まるため、設定をお勧めします。 今回は「 FLAT ICON DESIGN -フラットアイコンデザイン- 」様より、ローカル MCP サーバーの機能（天気予報）にちなんだアイコンを使用させていただきます。 天気のアイコン素材 用意したアイコンは、プロジェクトリポジトリの直下に image\ フォルダを作成し、その中に PNG 形式の画像ファイルとして保存します。 準備できた構成 ここまでの手順で、パッケージングに必要なソースコードや画像などのリソースが以下の構成で準備できたことを確認してください。これが整っていれば、いよいよデスクトップ拡張（DXT）を作成するパッケージング手順に進めます。 PS C:\Users\...\hands-on-mcp-sios-apisl> tree /f C:. │ .gitignore │ LICENSE │ package-lock.json │ package.json │ README.md │ tsconfig.json │ ├─build │ │ index.js │ ├─interfaces │ │ areaApi.js │ └─services │ areaWeatherForecast.js ├─image │ f_f_traffic_4_s512_f_traffic_4_0bg.png ├─node_modules │ ： │ （省略） │ └─src │ index.ts ├─interfaces │ areaApi.ts └─services areaWeatherForecast.ts マニフェストの新規作成 dxt init コマンドを使うと、デスクトップ拡張のパッケージングに必要な manifest.json ファイルを対話形式で簡単に作成できます。以下のコマンドを実行してください。 PS C:\Users\...\hands-on-mcp-sios-apisl> npx @anthropic-ai/dxt init This utility will help you create a manifest.json file for your DXT extension. Press ^C at any time to quit. ✔ Extension name: hands-on-mcp-sios-apisl ✔ Author name: SIOS Technology, Inc. API Solution Service Line Devision. ✔ Display name (optional): The hands-on local MCP server ✔ Version: 1.0.0 ✔ Description: A bit useful locat MCP server to check a weather! ✔ Add a detailed long description? no ✔ Author email (optional): ✔ Author URL (optional): https://api-ecosystem.sios.jp ✔ Homepage URL (optional): ✔ Documentation URL (optional): https://tech-lab.sios.jp/archives/48129 ✔ Support URL (optional): ✔ Icon file path (optional, relative to manifest): image/f_f_traffic_4_s512_f_traffic_4_0bg.png ✔ Add screenshots? no ✔ Server type: Node.js ✔ Entry point: build/index.js ✔ Does your MCP Server provide tools you want to advertise (optional)? no ✔ Does your MCP Server provide prompts you want to advertise (optional)? no ✔ Add compatibility constraints? no ✔ Add user-configurable options? no ✔ Keywords (comma-separated, optional): ✔ License: MIT ✔ Add repository information? yes ✔ Repository URL: git+https://github.com/Toshiharu-Konuma-sti/hands-on-mcp-sios-apisl.git Created manifest.json at /home/hoge/handson/hands-on-mcp-sios-apisl/manifest.json Next steps: 1. Ensure all your production dependencies are in this directory 2. Run 'dxt pack' to create your .dxt file 対話形式で入力する主要な項目とその内容は以下の通りです。 Extension name: DXT のファイル名になります。 Author name: 作成者名を入力します。 Display name: デスクトップ拡張として表示される名称です。 Description: 入力すると、デスクトップ拡張の名称の下に説明文として表示されます。 Author URL: 入力すると、作成者が該当 URL へのリンクとなります。 Icon file path: PNG 画像ファイルのパスを入力すると、デスクトップ拡張のアイコンを設定できます。 Entry point: ローカル MCP サーバーのスクリプトファイルパスを入力します。 対話形式での入力が完了したら、 manifest.json ファイルができあがったことを確認します。 PS C:\Users\...\hands-on-mcp-sios-apisl> ls Mode LastWriteTime Length Name ---- ------------- ------ ---- : -a---- 2025/07/01 10:47 705 manifest.json : DXT ファイルの作成 いよいよ、ローカルMCPサーバーをパッケージ形式のデスクトップ拡張として作成します。プロジェクトのルートディレクトリで、以下のコマンドを実行します。 PS C:\Users\...\hands-on-mcp-sios-apisl> npx @anthropic-ai/dxt pack Validating manifest... Manifest is valid! 📦 hands-on-mcp-sios-apisl@1.0.0 Archive Contents 27B BUILD.bat 2.1kB build/index.js : 110.9kB node_modules/zod-to-json-schema/dist/ [and 78 more files] 509.2kB node_modules/zod/lib/ [and 25 more files] Archive Details name: hands-on-mcp-sios-apisl version: 1.0.0 filename: hands-on-mcp-sios-apisl-1.0.0.dxt package size: 5.0MB unpacked size: 22.8MB shasum: 04fc9aff3e343e1e0fa2afaf3a537ed51a71a09a total files: 817 ignored (.dxtignore) files: 692 Output: C:\Users\...\hands-on-mcp-sios-apisl\hands-on-mcp-sios-apisl.dxt コマンドの実行が成功したら、デスクトップ拡張ができあがったことを確認します。 PS C:\Users\...\hands-on-mcp-sios-apisl> ls Mode LastWriteTime Length Name ---- ------------- ------ ---- : -a---- 2025/07/01 10:56 5282475 hands-on-mcp-sios-apisl.dxt : できあがったパッケージ形式のデスクトップ拡張は、ウェブサイトで公開やクラウドのファイルサーバーで共有などを活用して利用者に配布します。 配布先 PC で DXT ファイルからインストール ここからは、配布された DXT ファイルを使って 配布先 PC でローカル MCP サーバーをインストールし、利用可能にするまでの手順 を説明します。 DXT ファイルの入手 まず、インストールしたいローカル MCP サーバーのパッケージ形式のデスクトップ拡張を、開発者からウェブ経由などで事前に受け取ってください。 DXT ファイルからインストール Windows のスタートメニューから Claude desktop を起動します。プロンプトの入力ボックス左下部にある「検索とツール」ボタンをクリックしても、オリジナルのデスクトップ拡張（オリジナルの MCP サーバー）がリストに無いため、まだインストールされていないことが確認できます。 Claude desktop 画面の左上にある三本線のハンバーガーメニューから「ファイル ＞ 設定…」メニューを選択して設定画面を表示し、左ペインから「エクステンション」を選びます。 エクステンション画面が表示されている状態で、エクスプローラーを起動します。事前に入手した DXT ファイルをエクスプローラーから Claude desktop のエクステンション画面へドラッグアンドドロップします。 エクステンション画面上で DXT ファイルをドロップすると、オリジナルのローカル MCP サーバーのインストール画面に切り替わり、内容を確認したうえで「インストール」ボタンをクリックしてインストールします。 インストールが終わったら設定画面の上部にある「< すべての拡張機能」を選択して戻ります。 エクステンション画面にオリジナルのローカル MCP サーバーが追加されていることが確認できたら、設定画面の右上の×ボタンをクリックして画面を閉じます。 プロンプトの入力ボックス左下部にある「検索とツール」ボタンをクリックすると、今度はオリジナルの MCP サーバーがリスト存在することが確認できます。 これで、デスクトップ拡張のインストール手順は完了です。インストールしたローカルMCPサーバーでどのようなことができるかについては、「 オリジナルのちょっと便利な MCP サーバー を作ってみた 」で紹介している動画をご覧ください。 まとめ Desktop Extensions（デスクトップ拡張）は、いかがでしたでしょうか？ 今回の記事では、この Desktop Extensions がローカル MCP サーバーの配布をいかに容易にするか、そして MCP サーバーの普及にどう貢献するかについてご紹介しました。 ぜひ、皆さんも一度試して、その便利さを実感してみてください。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post ローカル MCP サーバーを Desktop Extensions で便利に配布してみた first appeared on SIOS Tech. Lab .

挨拶 ども！6/25にGemini CLIがリリースされて、7月に入ってから気づいて出遅れてしまった龍ちゃんです。Xでだいぶ話題になっていますね。noteの「 プログラミング1ミリも分からない人がGemini CLI始めるまでの全手順（Win篇） 」を見て、Gemini CLIがリリースを知りました。まぁ私はエンジニアなので、エンジニア目線で使い方を模索していこうと思っています。Gemini CLIだと、いろいろとカスタマイズができそうってことで、入門していきます。 弊社では、Geminiをワークスペースで契約をしているので普段から使えています。（生成AIサービスも福利厚生という時代になりましたね…） 今回は「DevContianerでGemini CLIを使うことができる環境をセットアップし、システムプロンプトを設定してURLからXの投稿文を生成」を目標として環境構築からセットアップまで行っていきます。 それでは始めましょう。 1. はじめに – なぜDevContainer × Gemini CLIなのか 皆さんは、AI開発環境の「汚染問題」に悩まされていませんか？ 今回DevContainer×Gemini CLIの環境を構築した背景は、 チーム開発での環境差異を根本的に解決したい からです。個人利用なら全く問題ないのですが、チーム開発となると話は別ですよね。 グローバルインストールでホスト側に設定ファイルをゴリゴリ書き込んでいると、「なんで俺のGeminiとお前のGeminiは違うんや！」という環境差異が必ず発生します。開発者は自由に自分の環境を作ってしまう自由人ですからね。新卒や別担当者が参画した際に「あれ？このコマンド入ってない」で一日潰れる光景、想像に難くないでしょう。 そこで注目したいのが、 2025年6月にGoogle公式リリースされたGemini CLI です。無料枠が1日1000回と太っ腹で、実用性は十分。DevContainerと組み合わせることで、 安全で再現可能な開発環境 が実現できます。 実践的な検証として、普段Claude Projectで使用しているプロンプトを使って「雑プロンプト」「Claude Project」「Gemini CLI」の3パターンで品質比較も行います。 今回の記事で学べること： DevContainerでGemini CLIを安全に動かす設定方法 GEMINI.mdによるプロジェクト固有カスタマイズ システムプロンプトの効果的な設定テクニック 実践：URLからテック系ブログのX投稿文を生成してdocs配下に自動保存 それでは、チーム開発を前提とした「Geminiの回答品質担保」環境を一緒に構築していきましょう！ 2. Gemini CLIとDevContainerの基礎知識（800文字） 2.1 Gemini CLIとは Gemini CLIは、2025年6月にGoogleが公式リリースしたオープンソースAIエージェントです。Apache 2.0ライセンスで提供されており、企業利用も安心ですね。 主要機能として以下が挙げられます： ファイル操作 : プロジェクトファイルの読み書き・編集 コマンド実行 : シェルコマンドの実行とレスポンス取得 Web検索 : リアルタイム情報収集 MCP対応 : Model Context Protocolによる拡張性 特に注目したいのが サンドボックス機能 です。これは、AI実行環境を隔離することで、予期しないシステム変更を防ぐGemini CLI独自の安全機能となります。 2.2 DevContainerとは DevContainerは、VS Code DevContainersの略称で、 コンテナベースの開発環境 を提供する技術 です。従来の「俺の環境では動くんだけどなあ」問題を根本的に解決してくれます。 AI開発における特有のメリットとして、 環境破壊防止 が挙げられます。AIエージェントが予期しないパッケージインストールやシステム変更を行っても、ホスト環境は完全に保護されるわけです。 コンテナ化により、チームメンバー全員が 同一の実行環境 を共有できるため、「なんで俺の環境だと動かないんだ」という状況を回避できます。これは、特に新卒研修や外部パートナーとの協業において威力を発揮しますね。 2.3 組み合わせの利点 DevContainer × Gemini CLIの組み合わせには、4つの主要メリットがあります。 安全性 : Gemini CLIのサンドボックス機能とDevContainerの隔離環境により、 二重の安全保障 が実現されます。AIが暴走してもホスト環境への影響は皆無です。 再現性 : 環境設定が .devcontainer/devcontainer.json としてコード化されるため、 誰でも同じ環境を瞬時に再現 できます。チーム間での環境差異によるトラブルが根絶されますね。 拡張性 : MCP対応により、プロジェクト固有の機能追加が容易です。継続的な改善と標準化が可能で、 組織全体での知見蓄積 に貢献します。 コスト効率 : Google Workspace統合により、既存の企業インフラとシームレスに連携できます。新たなライセンス購入や複雑な導入プロセスが不要で、 企業導入のハードルが格段に下がります 。 実際のプロジェクトでどちらを選ぶべきか、迷うところですが、チーム開発を前提とするなら、この組み合わせが現時点での個人的ベストプラクティスと言えるでしょう。 3. 環境準備と前提条件 3.1 必要なツール 今回の検証はGoogle Workspace環境で行っています。@google.comではなく@<自社ドメイン>.comアカウントでの検証ですが、認証方法が若干異なるだけなので、あまり気にしなくて大丈夫です。 Docker環境については、今回WSL2にDocker Engineを直接インストールして検証しています。ただし、 個人利用の方はMicrosoft公式が推奨している Docker Desktop の構築 をお勧めします。 企業でお使いの方、特に新人・若手の皆さんへ : Docker Desktopには商用利用時のライセンス制約があります。必ず上長または情報システム部門（最低でも同僚）に確認を取ってください。ライセンス問題は最悪の場合、訴訟に発展するリスクがあるため、慎重に対応しましょう。 3.2 Google Workspace環境の設定 Google Workspace環境では、 Gemini for Google Cloud API が有効化されたプロジェクトが必要になります。このAPIが有効になっていない場合、Gemini CLIの認証段階でエラーが発生します。 Google Cloud Consoleでプロジェクトを作成し、以下の手順でAPIを有効化してください： Google Cloud Console → APIとサービス → ライブラリ “Gemini API”で検索 Gemini for Google Cloud APIを選択して「有効にする」 3.3 DevContainer環境の準備 DevContainerを使用するため、以下のツールが必要です： VS Code : 最新版を推奨 DevContainers拡張機能 : Microsoft公式の拡張機能 Docker環境 : Docker DesktopまたはDocker Engine VS Codeの拡張機能タブで「DevContainers」を検索してインストールしてください。この拡張機能により、コンテナ内での開発が可能になります。 3.4 事前確認チェックリスト 作業を始める前に、以下の項目を確認してください： Docker環境の動作確認 : docker --version でバージョンが表示される VS Code + DevContainers拡張機能 : 正常にインストール済み Google Workspace アカウント : 組織アカウントでのログインが可能 Google Cloud プロジェクト : Gemini APIが有効化済み ネットワーク環境 : Google APIsへのアクセスが可能（企業ファイアウォール確認） これらの準備が整ったら、実際の環境構築に進むことができます。次のセクションでは、DevContainerの設定ファイル作成から始めていきましょう！ 4. DevContainer設定 4.1 プロジェクト構造の作成 それでは、今回作成するプロジェクトのディレクトリ構成から見ていきます。 . ├── .devcontainer │ └── devcontainer.json # DevContainer設定の心臓部 ├── docs # 作業結果を保存するディレクトリ ├── .gemini # Gemini CLI設定ディレクトリ │ └── settings.json # API Key等の設定 ├── GEMINI.md # システムプロンプト設定ファイル ├── .gitignore └── README.md ここがポイント！ 特に注目していただきたいのが** GEMINI.md **です。このファイルがシステムプロンプトを保存する重要な役割を担います。作業ディレクトリ内に配置することで、Gemini CLIが自動的に検出してシステムプロンプトを読み込んでくれる仕組みになっています。 docs ディレクトリは、Gemini CLIが生成した成果物を整理して保存するためのディレクトリです。チーム開発では、生成された結果を適切に管理することで、ナレッジの蓄積と共有が可能になります。これは、私の検証環境でも非常に重宝している構成ですね。 4.2 devcontainer.jsonの詳細設定 続いて、DevContainerの設定で最も重要な devcontainer.json の内容を詳しく見ていきます。WSL環境での動作を想定した設定になっています。 設定項目は公式リファレンス にまとまっています。 { "name": "Gemini CLI Development (DinD)", "image": "mcr.microsoft.com/devcontainers/javascript-node:1-20-bullseye", "features": {}, "postCreateCommand": "npm install -g npm@11.4.2 @google/gemini-cli ", "workspaceFolder": "/workspaces/${localWorkspaceFolderBasename}", "remoteUser": "node", "customizations": { "vscode": { "extensions": [ "ms-vscode-remote.remote-containers", "ms-vscode-remote.remote-wsl" ], "settings": { "terminal.integrated.defaultProfile.linux": "bash" } } } } 4.3 設定項目の詳細解説 ベースイメージの選択理由 Microsoft公式の javascript-node イメージを採用した理由は、DevContainer環境に最適化されており、セットアップが簡単だからです。このイメージでは UID:1000 が node ユーザーとして事前設定されており、権限管理がスムーズに行えます。 他のDevContainerイメージでは vscode ユーザーが使われることが多いですが、Node.js環境では node ユーザーが標準的です。これは、npmのグローバルインストール時の権限問題を回避するためでもあります。 拡張機能について DevContainer環境では、リモート開発に必要な拡張機能を事前にインストールしておくと作業効率が向上します。特に remote-containers と remote-wsl は、環境切り替えやデバッグ作業で重宝します。 皆さんも、普段使っている拡張機能がある場合は、ここに追加しておくと良いでしょう。 postCreateCommand こちらでGemini CLIのインストールを行っています。 インストール方法に関しては公式リファレンス の情報を参考に行っています。 4.4 環境起動と動作確認 この設定により、チーム全体で一貫したGemini CLI開発環境を構築できます。実際にこの環境を起動して動作確認を行っていきます！ 起動手順 Windows環境の場合 : F1 を押してコマンドパレットを開く 「DevContainers: Reopen in Container」を選択 コンテナのビルドが開始されます 4.5 Sandbox環境を使わない設計判断 Gemini CLIには Sandbox という便利機能が目玉の一つとしてあります。こちらは、ファイルに直接変更を加える前にDocker内のSandboxでプレビューとして変更をシミュレートしてくれる便利機能です。 今回は生成をメインに扱うので、そもそもファイル新規作成が目的なため、軽量化とDevContainerの複雑な設定を回避するために使わないと判断しました。 シンプル構成を選択した背景 ： 新規生成がメイン : 既存ファイル変更ではなく新規作成が目的 環境構築の簡素化 : DonDやDinDの複雑な設定を回避 軽量化 : 不要な機能を削ることでセットアップを高速化 必要な場合は DooD か DinD （DevContainer内でDockerを使用する）で組み込んで使用できますが、そこまで本格的に使うなら、WSLにNode.jsを直接インストールする方が簡単かもしれませんね。そこはプロジェクトの要件に応じて判断していただければと思います。 5. Gemini CLI基本セットアップ まず初めに Gemini CLIのトラブルシューティングのリンク を載せておきます。 5.1 認証設定 それでは、ターミナルを開いて以下のコマンドを実行してください。 # Google Cloud プロジェクトIDの設定（必須） export GOOGLE_CLOUD_PROJECT=your-project-id # Gemini CLI初回実行 gemini おそらくですが、以下のような画面が出てきて設定が始まります。 選択すると次は認証方式の設定ですね。 初回実行の場合は、認証方式を聞かれます。 Login with Google Gemini API Key (AI Studio) Vertex AI 多くの方は「Login with Google」を選択して、よく見慣れたGoogle認証画面でログインするでしょう。 設定項目をつらつらと答えていけば、認証設定は完了です。 5.2 基本設定ファイル（settings.json） { "sandbox": false, "theme": "GitHub", "model": "gemini-2.0-flash-exp", "contextFileName": [ "GEMINI.md" ] } 次に設定ファイルです。 プロジェクトルートに .gemini ディレクトリを作成 して settings.json ファイルを作成してください。 今回は sandbox を使わないためfalseに設定しています。もしここをtrueにすると、Dockerコマンドが使えないとのことでエラーが発生します。 theme に関しては初回に答えた内容ですね。Gemini CLIのコード部分の装飾に関わります。 model はデフォルトで選択するモデルですね。最後に contextFileName はシステムプロンプトとして認識するファイル名になります。この配列に追加していくと好きなファイルをシステムプロンプトとしてぶち込むことが可能になります。 設定の反映には一度Gemini CLIを抜けて再度入りなおす必要があります。自動反映はしてくれないですね。 動作的にまだ安定していない部分もありますが、その辺はこれからってところですね。 モデル設定のトラブルシューティング モデル設定が無視される場合（ GitHub Issue #2205 ）： export GEMINI_MODEL="gemini-2.0-flash-exp" gemini --model gemini-2.0-flash-exp 5.3 動作確認 設定が完了したら、適当に質問してみてください。 # 基本的な動作確認 現在のプロジェクト構造を教えてください # ファイル操作の確認 docs/test.md に今日の日付と動作確認結果を記録してください 普段のGeminiとあんまり使用感は変わらないですね。ローディングがGUIと違ってプログラミングチックで見慣れた光景だなって感じです。 正常に動作していれば、質問に対する回答が返ってきて、 docs ディレクトリにファイルが作成されるはずです。これで基本的なセットアップは完了です！ 6. GEMINI.mdによるプロジェクト固有設定 6.1 GEMINI.mdの役割と重要性 待望のシステムプロンプトを設定していきましょう！これは先ほどのCLI設定ファイルで指定したファイル名「 GEMINI.md 」をプロジェクトルートに作成すればOKです。 このファイルの面白いところは、 階層構造に応じた柔軟なプロンプト管理 が可能な点です。プロジェクトルートに作成すればプロジェクト全体のシステムプロンプトとして機能し、特定のディレクトリ（例：docs階層）に配置すれば、そのディレクトリ内での作業時のみ有効なシステムプロンプトになります。 これは、実際のコーディング作業で威力を発揮します。ディレクトリごとに異なるシステムプロンプトを作成することで、命名規則やコーディング規約をルールとして定義でき、プロジェクトが変わっても同一品質を担保できるわけです。ただし、作成と管理は相当大変そうですが…この ディレクトリ単位でのプロンプト分割機能はGemini CLI の魅力的な機能ですね。 6.2 実用的なGEMINI.md設定例 では、実践的なプロンプトを設定していきます。普段は300行のプロンプトを使用しているのですが、ファイルサイズも大きいので軽量版を用意しました。以下をプロジェクトルートに作成した GEMINI.md に挿入してください。 # 軽量版 エンジニア向けX投稿自動生成システム ## 🎯 概要 URLのみの入力で、記事品質評価からA/Bテスト用投稿文まで自動生成する包括的システム。 ## 🔄 自動実行プロセス ### Phase 1: 記事分析・品質評価 - web_fetchで記事の完全コンテンツ取得・構造解析 - 技術的正確性評価（技術スタック正確性、実装レベル、対象読者レベル） - 評価結果：A（高品質）/ B（標準）/ C（要注意） - 記事価値・差別化ポイント抽出 ### Phase 2: ハッシュタグ効果分析 - 2-3回のweb_searchで技術分野別調査・6個以内で選定 ### Phase 3: A/Bテスト版投稿文作成（2種類） **タイプA: 効果重視・数値訴求型** - 具体的な数値効果・Before/After型アピール **タイプB: 課題共感・解決提案型** - エンジニアの「あるある」課題→解決策への流れ ### Phase 4: 最適化・検証 - 280バイト制限内最大化・品質評価連動調整 ## 📊 最終出力フォーマット ### 1. 記事品質評価レポート 📋 記事品質評価結果 【総合評価】A / B / C 【技術的正確性】⭐⭐⭐⭐⭐ (5点満点) 【実装レベル】プロトタイプ / 基本実装 / 本格実装 / 企業レベル 【対象読者】初級者 / 中級者 / 上級者 / 専門家 【実用性】⭐⭐⭐⭐⭐ (5点満点) 【主要な技術要素】・【注意事項・制限】 ### 2. A/Bテスト投稿文（2種類） 各タイプごとに以下を含む： - 280バイト以内の最適化投稿文 - バイト数詳細（本文・絵文字・URL・ハッシュタグ・合計） - 特徴・ターゲット ### 3. 投稿タイミング戦略 - 最優先推奨・代替オプション ### 4. 最適化効果サマリー - 技術用語最適化効果・A/Bテスト推奨順位 ## 🔧 実行トリガー URLのみ入力時に自動実行 6.3 システムプロンプトの動作確認 正しくGemini CLIに認識されているか確認しましょう。Gemini CLIを起動した状態で以下のコマンドを入力して表示されれば成功です。 # 現在認識しているシステムプロンプトを表示 /memory show # システムプロンプトを更新したので再読み込み /memory refresh 6.4 実際の動作テスト この状態で以下のプロンプトを入力すれば、自動実行されてdocsディレクトリに結果が出力されるはずです。 https://tech-lab.sios.jp/archives/48061 > @docs/に出力したコンテンツを保存して 一定時間経過後にdocsディレクトリにファイルが作成されていると思います。私の検証環境では以下のような結果が出力されました： 出力例 ： URLを分析し、指定されたフォーマットでX（旧Twitter）への投稿案を作成しました。 ### 1. 記事品質評価レポート 📋 **記事品質評価結果** 【総合評価】A 【技術的正確性】⭐⭐⭐⭐⭐ 【実装レベル】本格実装 【対象読者】中級者 【実用性】⭐⭐⭐⭐⭐ 【主要な技術要素】 ・Azure Static Web Apps ・Bicep (Infrastructure as Code) ・Azure CLI ・SWA CLI ・Bash Scripting 【注意事項・制限】 ・提示されているスクリプトはローカル開発用です。 ・デプロイトークンなどの機密情報はGitで管理しないよう注意が必要です。 ### 2. A/Bテスト投稿文（2種類） --- **【タイプA：効果重視・数値訴求型】** **テキスト案** Azure SWAの構築、手作業で時間かかっていませんか？🤔 Bicepを使った自動化で、作業時間を70%も短縮！🚀 この記事のスクリプトをコピペするだけで、ローカル開発環境のデプロイが数分で完了します。 `https://tech-lab.sios.jp/archives/48061` #Azure #Bicep #IaC #DevOps #自動化 **バイト数詳細** ・本文: 1[1]57 ・絵文字: 8 ・URL: 23 ・ハッシュタグ: 41 ・合計: 229 バイト **特徴・ターゲット** 「70%削減」という具体的な数値を提示し、即時的な効果を求めるエンジニアにアピールします[1]。多忙な開発者や、すぐに導入できる解決策を探している層がターゲットです。 --- **【タイプB：課題共感・解決提案型】** **テキスト案** 「またこの手作業か…」Azure SWAのデプロイ、面倒に感じていませんか？ Bicepと自動化スクリプトで、その悩みを解決！✨ リソース作成からデプロイまでを完全自動化する具体的な手法を解説。もう手動管理には戻れません。 `https://tech-lab.sios.jp/archives/48061` #Azure #Bicep #StaticWebApps #IaC **バイト数詳細** ・本文: 151 ・絵文字: 4 ・URL: 23 ・ハッシュタグ: 36 ・合計: 214 バイト **特徴・ターゲット** 開発者が共感しやすい「手作業の煩わしさ」という課題から入り、記事がその解決策であることを提示します。手動でのインフラ管理に課題を感じている、より丁寧な解説を求めるエンジニア層に響きやすい投稿です。 --- ### 3. 投稿タイミング戦略 * **最優先推奨:** 平日の業務時間中（10:00〜18:00）。技術情報に関心のあるエンジニアがアクティブな時間帯です。特に昼休み（12:00-13:00）や、業務が一段落する夕方（17:00-18:00）が効果的です。 * **代替オプション:** 平日の夜（21:00〜23:00）。自己学習や情報収集を行うエンジニアにリーチできる可能性があります。 ### 4. 最適化効果サマリー * **技術用語最適化:** 記事の核心技術である「Bicep」「Azure Static Web Apps」「IaC」をハッシュタグに含めることで、これ らの技術に関心を持つターゲット層へのリーチを最大化しました。 * **A/Bテスト推奨順位:** 1. **タイプA**を先に試すことを推奨します。「70%削減」という強いインパクトを持つ数値は、クリック率を高める可能性が最も高いです。 2. 次に、より丁寧な課題解決アプローチである**タイプB**を投稿し、エンゲージメントの違いを比較します。 Sources: [1] 作業時間を70%短縮！BicepによるAzure Static Web Apps自動構築 | (https://tech-lab.sios.jp/archives/48061) この結果が正常に出力されれば、システムプロンプトの設定は完了です！ 7. 実践的な運用とチーム活用 7.1 チーム開発での管理手法 今回のシステムは生成に主軸を置いているため、 作成した成果物をGitHub上で体系的に管理できる という大きな利点があります。従来は、Geminiで出力したものをSlackに都度コピー＆ペーストで移行していましたが、この方法では過去の生成結果の検索や再利用が困難でした。 Git管理による品質保証プロセス では、プロンプトの品質はプロンプト自体に依存するため、 PRベースでの変更管理 が理想的です。生成されたドキュメントをベースに運用を行い、定期的な改修判断を行うプロセスが重要になります。 GitHubの利点である バージョン管理機能 により、プロンプトの変遷を追跡できるのは非常に価値があります。ソースコードと同様に、プロンプトも技術資産として体系的に管理すべき時代になってきました。LLMのバージョンアップによって相性の良し悪しが変わる世界では、PRでの管理ができることは大変重要ですね。 7.2 GEMINI.mdの実用的活用パターン 6章で解説した ディレクトリ単位でのGEMINI.md配置機能 は、業務フローの最適化において強力な武器となります。作業内容ごとにプロンプトをカスタマイズできることで、業務効率の大幅な向上が期待できます。 具体的な活用例 ： プロジェクト構成での使い分け project-root/ ├── GEMINI.md # プロジェクト全体の基本プロンプト ├── docs/ │ └── GEMINI.md # ドキュメント生成専用プロンプト ├── src/ │ └── GEMINI.md # コード生成・レビュー専用プロンプト └── tests/ └── GEMINI.md # テストコード生成専用プロンプト 7.3 A/Bテスト戦略の実装 今回の検証では、プロンプト内部でA/Bテストを実装しましたが、 長期的な効果測定 であればディレクトリ単位での分離がより効果的です。 ディレクトリベースA/Bテスト例 ： social-media-posts/ ├── strategy-a/ │ ├── GEMINI.md # 数値重視アプローチ │ └── generated/ # 生成結果保存 └── strategy-b/ ├── GEMINI.md # 課題共感アプローチ └── generated/ # 生成結果保存 この構成により、 期間を区切った戦略比較 や チーム内での並行テスト が可能になります。 7.4 プロンプトの継続的改善 プロンプトエンジニアリングは試行錯誤の連続です。一度の修正で完璧になることは稀なので、 定期的にレビューを重ねてプロンプトを一歩ずつ改善していく必要があります 。（というか一度で完璧なプロンプトって絶対作れないですよね…） 生成結果の品質に課題を感じた際は、どの部分が期待と異なるのかを具体的に特定し、プロンプトの該当箇所を少しずつ調整していくアプローチが必要です。 7.5 組織展開での考慮事項 チーム全体でDevContainer × Gemini CLI環境を導入する際は、以下の点に注意が必要です： 技術的制約事項 Docker環境の組織統一 Google Workspace認証の権限設定 ファイアウォール設定の調整 運用ルールの策定 プロンプト変更権限の明確化 生成コンテンツの品質基準定義 セキュリティガイドラインの整備 特にコーディングに活用するのであれば、今回はそぎ落としたsandboxに関しては必須レベルです。コードはすでに元のものがある前提なので、sandboxなしの場合であればgitコマンドで戻すしか選択肢がなくなってしまいます。 この環境が組織に定着すれば、 AI活用による生産性向上 と 品質の標準化 が同時に実現できるでしょう。皆さんも、ぜひプロジェクトの要件に応じてカスタマイズしてみてください！ まとめ 今回は、DevContainer × Gemini CLIを組み合わせた安全で再現可能な開発環境の構築方法について詳しく解説してきました。 この環境構築で実現できたこと は以下の通りです： チーム開発の課題解決 : 「なんで俺のGeminiとお前のGeminiは違うんや！」という環境差異問題を根本的に解決し、誰でも同じ環境を瞬時に再現できるようになりました。DevContainerによるコンテナ化で、新卒や別担当者が参画してもスムーズに開発に参加できる環境が整います。 安全性の確保 : Gemini CLIのサンドボックス機能とDevContainerの隔離環境による二重の安全保障で、AIが暴走してもホスト環境への影響は皆無です。企業レベルでの導入も安心して行えます。 プロジェクト固有のカスタマイズ : GEMINI.mdによるディレクトリ単位でのシステムプロンプト管理により、作業内容に応じた最適化が可能になりました。コーディング、ドキュメント生成、テスト作成など、用途別にプロンプトを使い分けることで業務効率が大幅に向上します。 Git管理によるプロンプト資産化 : プロンプトもソースコードと同様にバージョン管理できるため、PRベースでの品質管理と継続的改善が実現できます。LLMのバージョンアップに対応した管理も可能になりますね。 この環境が組織に定着すれば、 AI活用による生産性向上と品質の標準化 が同時に実現できるでしょう。特に、従来Slackにコピー＆ペーストしていた生成結果を体系的に管理できるようになったのは大きな進歩です。 皆さんも、ぜひプロジェクトの要件に応じてカスタマイズしてみてください！定期的にレビューを重ねてプロンプトを一歩ずつ改善していくことで、さらに高度な自動化システムへと発展させていけるはずです。 付録：強化版プロンプト # 強化版 エンジニア向けX投稿自動生成システム ## 🎯 概要 URLのみの入力で、記事品質評価からA/Bテスト用投稿文まで自動生成する包括的システム。技術的正確性の評価と異なるアプローチでの複数投稿文を同時作成。 --- ## 🔄 自動実行プロセス（強化版） ### **Phase 1: 記事分析・品質評価** #### **Step 1-1: 記事内容完全取得** ``` 実行内容： - web_fetchでブログ記事の完全コンテンツ取得 - 記事構造の解析（見出し、コードブロック、図表等） - 文字数・技術密度の測定 ``` #### **Step 1-2: 技術的正確性評価** ``` 評価項目： 【技術スタック正確性】 - 使用技術の最新性（2024-2025年基準） - 技術的実装の適切性 - セキュリティ・ベストプラクティスの考慮 【実装レベル判定】 - プロトタイプ / 基本実装 / 本格実装 / 企業レベル - コードの完成度・品質 - エラーハンドリング・例外処理の有無 【対象読者レベル】 - 初級者（学習中・1-2年目） - 中級者（実務経験3-5年） - 上級者（リーダー・アーキテクト級） - 専門家（特定分野のエキスパート） 評価結果：A（高品質）/ B（標準）/ C（要注意） ``` #### **Step 1-3: 記事価値・差別化ポイント抽出** ``` 分析内容： - 解決する具体的課題 - 既存解決策との違い・優位性 - 実用性・再現性の程度 - 学習コスト・導入難易度 - ビジネス価値・ROI ``` ### **Phase 2: ハッシュタグ効果分析** #### **Step 2-1: 技術分野別ハッシュタグ調査** ``` 検索戦略（2-4回のweb_search実行）： 検索1: "[主要技術名] ハッシュタグ 効果的 X Twitter 2025" 例："NestJS ハッシュタグ 効果的 X Twitter 2025" 検索2: "[技術領域] エンジニア ハッシュタグ トレンド 2025" 例："Web開発 エンジニア ハッシュタグ トレンド 2025" 検索3: "[解決課題] 自動化 効率化 ハッシュタグ X" 例："Slack Bot 自動化 効率化 ハッシュタグ X" 検索4: "[関連ツール] [技術スタック] ハッシュタグ 人気" 例："Google Docs API NotebookLM ハッシュタグ 人気" ``` #### **Step 2-2: ハッシュタグ効果性評価・選定** ``` 評価基準： - トレンド性（2024-2025年の話題性） - 技術特化度（エンジニアの検索意図との一致） - 関連性（記事内容との直接的関連度） - バイト効率（半角英語活用による節約効果） 選定ルール： - 6個以内 - 合計30-40バイト以内 - 半角英語優先（#Azure, #API, #OSS等） ``` ### **Phase 3: A/Bテスト版投稿文作成（3種類）** #### **投稿文タイプ A: 効果重視・数値訴求型** ``` 【特徴】 - 具体的な数値効果を最前面に配置 - Before/After型の劇的改善アピール - 実用性・効率化を強調 【構成テンプレート】 🚀 [劇的効果の数値]で[技術課題]を解決！ 📝 [具体的解決手法]で[時間短縮・効率化]を実現 ⚡ 技術スタック: [半角英語技術名] 🔧 [実装詳細・注意点] 詳細→ [URL] #ハッシュタグ 【表現例】 - "30分→3分に短縮！" - "90%の作業削減を実現" - "チーム全体で月40時間節約" ``` #### **投稿文タイプ B: 課題共感・解決提案型** ``` 【特徴】 - エンジニアの「あるある」課題から開始 - 共感を呼ぶ問題提起 - 解決策への自然な流れ 【構成テンプレート】 😰 [多くのエンジニアが抱える課題]で困ってませんか？ 💡 [技術手法]を使えば[解決方法]で楽になります ⚡ [具体的技術スタック]で実装 🎯 [期待効果・メリット] 解決方法→ [URL] #ハッシュタグ 【表現例】 - "まだ手動でSlack通知作ってるの？" - "Google Docsの更新確認、毎回開いてチェックしてる？" - "同じようなレポート作成に毎週2時間かけてませんか？" ``` #### **投稿文タイプ C: 技術トレンド・学習促進型** ``` 【特徴】 - 最新技術動向・トレンドに言及 - スキルアップ・学習意欲を刺激 - 将来性・キャリア価値をアピール 【構成テンプレート】 🔥 2025年注目の[技術分野]トレンド 📚 [技術手法・ツール]の実装方法を解説 ⭐ [学習メリット・キャリア価値] 🚀 [実際の活用場面・ビジネス価値] 詳細ガイド→ [URL] #ハッシュタグ 【表現例】 - "2025年のAI活用はここまで進化" - "NotebookLMとSlack連携がゲームチェンジャー" - "この技術知ってるかで来年の評価が変わる" ``` ### **Phase 4: 最適化・検証** #### **Step 4-1: バイト数計算・最適化** ``` 各投稿文について： - 全角・半角混在でのバイト数正確計算 - 280バイト制限内での情報量最大化 - 技術用語の半角化による節約効果測定 - URL（23バイト）・絵文字・ハッシュタグ含めた総計算 ``` #### **Step 4-2: 品質評価連動調整** ``` 記事品質評価結果に基づく調整： 【A評価（高品質）記事】 - より技術的権威性を強調 - 上級者向けの詳細情報を含める - 業界標準・ベストプラクティスをアピール 【B評価（標準）記事】 - 実用性・学習効果を前面に - 初中級者向けの親しみやすい表現 - 「試してみる価値あり」感を演出 【C評価（要注意）記事】 - 学習・実験的価値をアピール - 制限事項・注意点を適切に含める - 過度な効果アピールを避ける ``` --- ## 📊 最終出力フォーマット ### **1. 記事品質評価レポート** ``` 📋 記事品質評価結果 【総合評価】A / B / C 【技術的正確性】⭐⭐⭐⭐⭐ (5点満点) 【実装レベル】プロトタイプ / 基本実装 / 本格実装 / 企業レベル 【対象読者】初級者 / 中級者 / 上級者 / 専門家 【実用性】⭐⭐⭐⭐⭐ (5点満点) 【主要な技術要素】 - [抽出された技術スタック] - [解決する課題] - [提供価値・効果] 【注意事項・制限】 - [記事内で言及されている制限事項] - [実装時の注意点] ``` ### **2. A/Bテスト投稿文（3種類）** #### **🚀 タイプA: 効果重視型** ``` [280バイト以内の最適化投稿文A] 📊 バイト数詳細: - 本文: [X]バイト - 絵文字: [X]バイト - URL: 23バイト - ハッシュタグ: [X]バイト - 合計: [X]/280バイト 💡 特徴: 数値効果重視、劇的改善アピール 🎯 ターゲット: 効率化重視のエンジニア ``` #### **💡 タイプB: 課題共感型** ``` [280バイト以内の最適化投稿文B] 📊 バイト数詳細: - 本文: [X]バイト - 絵文字: [X]バイト - URL: 23バイト - ハッシュタグ: [X]バイト - 合計: [X]/280バイト 💡 特徴: 共感重視、問題解決提案 🎯 ターゲット: 課題を抱えるエンジニア ``` #### **📚 タイプC: 学習促進型** ``` [280バイト以内の最適化投稿文C] 📊 バイト数詳細: - 本文: [X]バイト - 絵文字: [X]バイト - URL: 23バイト - ハッシュタグ: [X]バイト - 合計: [X]/280バイト 💡 特徴: トレンド重視、スキルアップ促進 🎯 ターゲット: 学習意欲の高いエンジニア ``` ### **3. 投稿タイミング戦略** #### **🥇 最優先推奨（記事品質・内容連動）** ``` 推奨投稿タイプ: [A/B/C] 推奨日時: [具体的日時] 理由: [記事品質・対象読者・技術分野に基づく根拠] 期待効果: [エンゲージメント予測] ``` #### **🥈 代替オプション** ``` 代替投稿タイプ: [A/B/C] 代替日時: [具体的日時] 理由: [異なるアプローチでの訴求理由] 期待効果: [別ターゲット層への効果] ``` #### **🥉 実験的選択肢** ``` 実験投稿タイプ: [A/B/C] 実験日時: [具体的日時] 理由: [新しいパターンのテスト目的] 期待効果: [データ収集・学習効果] ``` ### **4. 最適化効果サマリー** ``` 💡 技術用語最適化効果: - 半角英語化: [具体例] → [X]バイト節約 - 半角数値化: [具体例] → [X]バイト節約 - 半角記号化: [具体例] → [X]バイト節約 - 総節約効果: [X]バイト 🎯 A/Bテスト推奨順位: 1位: タイプ[A/B/C] - [選定理由] 2位: タイプ[A/B/C] - [選定理由] 3位: タイプ[A/B/C] - [選定理由] 📈 期待エンゲージメント予測: - タイプA: [予測値・根拠] - タイプB: [予測値・根拠] - タイプC: [予測値・根拠] ``` --- ## 🔧 実行トリガー ### **自動実行条件** ``` 以下の場合に自動的にこの強化版プロセスを実行： 1. URLのみが入力された場合 2. "記事品質評価付きで"等の指示がある場合 3. "A/Bテスト版で"等の指示がある場合 4. "完全版で"等の包括的分析要求がある場合 ``` ### **プロンプト例** ``` 【基本実行】 https://tech-blog.example.com/article-url 【明示的実行】 以下の記事で記事品質評価とA/Bテスト版投稿文を作成してください： https://tech-blog.example.com/article-url 【カスタム実行】 記事品質評価A評価想定、上級者向けでA/Bテスト版作成： https://tech-blog.example.com/article-url ``` --- ## 📋 品質保証チェックリスト（強化版） ### **記事品質評価の正確性** - [ ] 技術的事実の正確性検証 - [ ] 実装レベルの適切な判定 - [ ] 対象読者レベルの妥当性確認 - [ ] 制限事項・注意点の適切な反映 ### **A/Bテスト版の差別化** - [ ] 3つのアプローチが明確に異なる - [ ] 各タイプのターゲット読者が明確 - [ ] バイト数最適化が各版で実現 - [ ] 品質評価結果が適切に反映 ### **全体的最適化** - [ ] ハッシュタグ効果分析の妥当性 - [ ] 投稿タイミング戦略の論理性 - [ ] バイト数計算の正確性 - [ ] エンゲージメント予測の根拠明確性 --- この強化版システムにより、URLひとつで記事の技術的品質から複数の投稿戦略まで包括的に分析・生成できます！ ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post DevContainerでGemini CLIセットアップ！チーム開発環境差異を解決する実践ガイド first appeared on SIOS Tech. Lab .

こんにちは、伊藤です。 パスワードハッシュを使用したシステムを開発する際、プログラムが生成したパスワードハッシュが正しいかどうかテストすることがあります。この記事では、そのような場面で役立つ openssl コマンドを使い、手軽にパスワードハッシュを生成・確認する方法を紹介します。 検証環境 検証で使用したOSとOpenSSLのバージョンは以下のとおりです。 OS Rocky Linux OS 9.2 OpenSSLのバージョン $ openssl version OpenSSL 3.0.7 1 Nov 2022 (Library: OpenSSL 3.0.7 1 Nov 2022) パスワードハッシュの出力 使用できるパスワードハッシュアルゴリズムを確認します。 openssl コマンドをそのまま入力すると、helpが表示されます。 $ openssl help: Standard commands asn1parse ca ciphers cmp cms crl crl2pkcs7 dgst dhparam dsa dsaparam ec ecparam enc engine errstr fipsinstall gendsa genpkey genrsa help info kdf list mac nseq ocsp passwd pkcs12 pkcs7 pkcs8 pkey pkeyparam pkeyutl prime rand rehash req rsa rsautl s_client s_server s_time sess_id smime speed spkac srp storeutl ts verify version x509 Message Digest commands (see the `dgst' command for more details) blake2b512 blake2s256 md2 md4 md5 rmd160 sha1 sha224 sha256 sha3-224 sha3-256 sha3-384 sha3-512 sha384 sha512 sha512-224 sha512-256 shake128 shake256 sm3 Cipher commands (see the `enc' command for more details) aes-128-cbc aes-128-ecb aes-192-cbc aes-192-ecb aes-256-cbc aes-256-ecb aria-128-cbc aria-128-cfb aria-128-cfb1 aria-128-cfb8 aria-128-ctr aria-128-ecb aria-128-ofb aria-192-cbc aria-192-cfb aria-192-cfb1 aria-192-cfb8 aria-192-ctr aria-192-ecb aria-192-ofb aria-256-cbc aria-256-cfb aria-256-cfb1 aria-256-cfb8 aria-256-ctr aria-256-ecb aria-256-ofb base64 bf bf-cbc bf-cfb bf-ecb bf-ofb camellia-128-cbc camellia-128-ecb camellia-192-cbc camellia-192-ecb camellia-256-cbc camellia-256-ecb cast cast-cbc cast5-cbc cast5-cfb cast5-ecb cast5-ofb des des-cbc des-cfb des-ecb des-ede des-ede-cbc des-ede-cfb des-ede-ofb des-ede3 des-ede3-cbc des-ede3-cfb des-ede3-ofb des-ofb des3 desx idea idea-cbc idea-cfb idea-ecb idea-ofb rc2 rc2-40-cbc rc2-64-cbc rc2-cbc rc2-cfb rc2-ecb rc2-ofb rc4 rc4-40 rc5 rc5-cbc rc5-cfb rc5-ecb rc5-ofb seed seed-cbc seed-cfb seed-ecb seed-ofb パスワードハッシュアルゴリズムとして、 Message Digest commands に表示されているアルゴリズムが使用できます。 例：MD5 $ echo 'password' | openssl md5 MD5(stdin)= 286755fad04869ca523320acce0dc6a4 ※パスワードハッシュのみを表示したい場合 $ echo 'password' | openssl md5 | awk '{print $2}' 286755fad04869ca523320acce0dc6a4 ソルトを使用するパスワードハッシュの出力 ソルトを使用するパスワードハッシュアルゴリズムを使用したい場合は openssl passwd コマンドを使用します。 openssl passwd で使用できるパスワードハッシュアルゴリズムを確認します。 Cryptographic options の部分が使用できるパスワードハッシュアルゴリズムです。 $ openssl passwd --help Usage: passwd [options] [password] General options: -help Display this summary Input options: -in infile Read passwords from file -noverify Never verify when reading password from terminal -stdin Read passwords from stdin Output options: -quiet No warnings -table Format output as table -reverse Switch table columns Cryptographic options: -salt val Use provided salt -6 SHA512-based password algorithm -5 SHA256-based password algorithm -apr1 MD5-based password algorithm, Apache variant -1 MD5-based password algorithm -aixmd5 AIX MD5-based password algorithm Random state options: -rand val Load the given file(s) into the random number generator -writerand outfile Write random data to the specified file Provider options: -provider-path val Provider load path (must be before 'provider' argument if required) -provider val Provider to load (can be specified multiple times) -propquery val Property query used when fetching algorithms Parameters: password Password text to digest (optional) パスワードハッシュアルゴリズムを使用してみます。 例：MD5Crypt $ openssl passwd -1 -salt 'salt' 'password' $1$salt$qJH7.N4xYta3aEG/dfqo/0 まとめ 今回は openssl コマンドを使い、パスワードハッシュを生成する方法を紹介しました。 開発中のテストや検証で、ぜひ活用してみてください。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post opensslコマンドでパスワードハッシュを出力する first appeared on SIOS Tech. Lab .

はじめに こんにちはサイオステクノロジーの小野です。今回はRancherを構築後にWebUIにアクセスしたらリダイレクトが繰り返されるエラーが発生して解決に時間がかかったので、その解決方法を共有します。 今回の構成 前提条件 OS：Ubuntu 24.04.2 LTS Rancher：v2.11.1 RKE2：v1.32.3+rke2r1 HAProxy：2.8.5-1ubuntu3.3 構成 今回構築したRancherの構成は以下になります。 今回構築したRancherの構成 RKE2クラスタを3台冗長構成で構築して、これをRancherのRMSクラスタとして利用します。 また、外部にLBサーバー（HAProxy）を置いて、それによってRMSクラスタをロードバランスします。その際にRancherへのアクセス時のTLS終端をHAProxyで行います。 TLS終端はopensslによって自己署名証明書を発行して、それを利用します。 HAProxyの設定ファイルは以下のように設定しました。LBサーバーにHTTPSアクセス（Port：443）を行ったら、RMSノードにHTTPアクセス（Port：80）を行うようにロードバランスします。 frontend rancher_front bind *:443 ssl crt <TLS終端の証明書> mode http option forwardfor http-request add-header X-Forwarded-Proto https if { ssl_fc } default_backend rancher_back backend rancher_back mode http balance roundrobin server cp_node1 <CPノード1のIPアドレス>:80 check server cp_node2 <CPノード2のIPアドレス>:80 check server cp_node3 <CPノード3のIPアドレス>:80 check HAProxy設定後、RKE2クラスタに以下のようにHelmでRancherをインストールしました。 helm install rancher rancher-latest/rancher \ --namespace cattle-system \ --set hostname= <LBサーバーのドメイン> \ --set replicas=3 \ --set bootstrapPassword=<初期パスワード> \ --set tls=external 問題点 Rancherインストール後、RancherWebUIにアクセスするとリダイレクトし続けて、アクセスできません。 RancherWebUIを開くとリダイレクトし続けてエラーが出る RancherのGithubのIssusesでも関連した問題が報告されています： https://github.com/rancher/rancher/issues/35088 解決方法 公式ドキュメントに解決方法が載っていました。 Rancher Helm Chart Options > External TLS Termination 外部でTLS終端する場合は、Nginx ingressに「use-forwarded-headers」というオプションを有効にする必要があります。したがって、RancherをHelmでインストールする前に以下のようなyamlをRancherをインストールするRKE2クラスタにapplyする、もしくは同様のリソースを編集してconfigに「use-forwarded-headers: “true”」を追加してください。 apiVersion: helm.cattle.io/v1 kind: HelmChartConfig metadata: name: rke2-ingress-nginx namespace: kube-system spec: valuesContent: |- controller: config: use-forwarded-headers: "true" 問題の原因 問題が発生する流れは以下になります。 ユーザーがLBにHTTPSアクセスする LBでTLS終端する LBからRancherにHTTPアクセスする RancherがHTTPアクセスを安全でないと判断して、HTTPSアクセスするようにLBにリダイレクトする LBはRancherからのリダイレクトをユーザーに転送する 1に戻る このような処理が繰り返されることでリダイレクトの無限ループが発生します。 通常、TLS終端を行ったHTTPアクセスのヘッダーには、ユーザーがLBに接続するために使用したプロトコル（HTTP、HTTPS）の情報が含まれています。Nginx ingressに設定した「use-forwarded-headers: “true”」とは、Rancherがそのヘッダー情報を参照する設定になります。 これによってLBからRancherへHTTPアクセスしても、ヘッダー情報を基にユーザーのリクエスト元がHTTPSアクセスであったことを認識できるようになります。その結果、Rancherはリダイレクトを行わなくなり、無限ループが解消されます。 終わりに コンテナプラットフォームを構築する際に、外部サーバーでLBを設定して、TLS終端することはごく一般的な構成になります。しかし、今回構築を行って、細かい部分でたくさんのエラーに遭遇してとても苦労しました。公式ドキュメントはしっかりと読むことを心掛けたいと思います。 参考 Rancher公式ドキュメント： https://ranchermanager.docs.rancher.com/ ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 外部TLS終端のRancher構築におけるリダイレクト問題の解決法 first appeared on SIOS Tech. Lab .

概要 こんにちは。サイオステクノロジーの塙です。 今回は、閉域網環境のOpenShift(以下、OCP)で、ミラーレジストリーの構成について説明したいと思います。 OpenShiftの詳細については、本ブログでは省略しています。OpenShiftに関する内容についてはサイオスの他ブログ等をご参照下さい。 SIOS Tech. Lab – OpenShift ミラーレジストリーの概要 ミラーレジストリー OCPを構築する際には、外部のQuay等のリポジトリからOCPやOperatorのイメージを取得して構築を行います。 閉域網環境のOCPでは、ノードからインターネットに接続出来ない環境のためミラーレジストリーを作成して対応します。 ミラーレジストリーでOCPやOperatorのイメージを取得して、OCPの構築時にミラーレジストリーのイメージを利用するという流れで構築を行います。 ミラーレジストリーは、OCPサブスクリプションに含まれているため、特に追加費用なく利用できます。 また、既に環境内でRed Hat Quay, Artifactory, NexusリポジトリなどDockerv2-2 をサポートする任意のコンテナーレジストリーを使用している場合は、ミラーレジストリーの代わりに使用することができます。 ミラーレジストリー利用のシナリオ ミラーレジストリーを利用する場合、以下の２つのシナリオで利用できます。 ミラーレジストリーを導入するノードが、インターネットとOCPノードに接続できるパターン ミラーレジストリーを導入するノードが、インターネット非接続であり、OCPノードと接続できるパターン 1. の場合だと、イメージをインターネットから直接ミラーレジストリーにミラーすることができます。 2. の場合だと、インターネット接続可能なノードでイメージを取得してから、リムーバブルメディア経由で転送してミラーレジストリーにミラーする方法になります。 これらのシナリオは主に完全な閉域網環境として構築するかといった要件で方式が変わってくる部分となります。 それぞれのシナリオでは、イメージのミラーリング方法について少し手順が異なってくるので注意が必要になります。 今回は、2.の場合の内容は扱いません。 参考： ・ OpenShift Container Platform – 2.1. ミラーレジストリーについて 事前準備 ミラーレジストリーを導入するノードを用意します。 今回は、AWS環境のベアメタルインスタンスでKVMを構築して、KVM上のVMでノードを準備します。 VMの用意までの手順はここでは割愛します。 ミラーレジストリーの前提条件 に従って、VMのリソースは以下で用意をします。 vCPU： 2コア メモリ：８GB ストレージ：500GB   また参考の資料に従って、VMにインストールするRHEL OSを用意しておきます。 Web上からRHEL ISOイメージをダウンロードする手順に則り、KVMホスト上に展開します。 インストール手順としてカスタマーポータルからダウンロードする手順と、curlを用いてダウンロードする手順がありますのでどちらかの手順を用いて下さい。 参考： ・ 2.2. RHEL インストール ISO イメージのダウンロード 事前準備手順 VMの用意までが出来たら、VMにSSHで接続して事前準備を行います。 OCコマンドをインストールします。 インストールするバージョンを確認して、それに合わせる形でURLにバージョンを記載します。 $ curl -L -o - "https://mirror.openshift.com/pub/openshift-v4/$(uname -m)/clients/ocp/4.xx.xx/openshift-client-linux.tar.gz" | sudo tar -C /usr/local/bin -xvzf - oc $ oc version 必要なパッケージをインストールします。 インストールするバージョンを確認して、それに合わせる形でURLにバージョンを記載します。 # podmanのインストール $ sudo dnf install podman -y # oc-mirrorのインストール $ curl -LO https://mirror.openshift.com/pub/openshift-v4/x86_64/clients/ocp/4.xx.xx/oc-mirror.rhel9.tar.gz $ tar xvzf oc-mirror.rhel9.tar.gz $ chmod +x oc-mirror $ sudo mv oc-mirror /usr/local/bin/ $ oc mirror --v2 --help ミラーレジストリーのインストール 次に、ミラーレジストリーをインストールします。 インストールでは、mirror-registry コマンドを使用してインストール作業を行います。 mirror-registry install コマンドでは、ミラーレジストリーの初期ユーザー名とパスワードが出力されますので、このタイミングで保存をしておきます。 ミラーレジストリーのインストールパラメータ： quayHostname：クライアントがミラーレジストリーへの接続に使用するドメイン名を決定します。 quayRoot：ミラーレジストリーのルートディレクトリを決定します。該当ディレクトリ上にデータの保存等が行われます。 $ curl -LO https://mirror.openshift.com/pub/cgw/mirror-registry/2.0.6/mirror-registry-amd64.tar.gz $ tar xf mirror-registry-amd64.tar.gz $ sudo ./mirror-registry install --quayHostname $(hostname -f) --quayRoot /var/lib/quay ミラーレジストリーのCA証明書をOSに登録します。CA証明書はインストール時に指定したquayRootのディレクトリ配下に保存されています。 $ sudo cp /var/lib/quay/quay-rootCA/rootCA.pem /etc/pki/ca-trust/source/anchors/ $ sudo update-ca-trust ミラー用の認証情報を作成 ミラーレジストリーのプルシークレットと、外部レジストリのプルシークレットの情報を持ったミラー用の認証情報（以下、Authファイル）を作成していきます。 ユーザー名とパスワードを用いて、ミラーレジストリーにログインを行います。この時authfileにミラーレジストリーへのアクセス情報としてプルシークレットを生成するようにします。 $ podman login -u init \ -p <password> \ --authfile ./mirror-pull-secret.txt \ <quayHostname>:8443 \ --tls-verify=false Authファイルのディレクトリを作成します。 $ mkdir -p $XDG_RUNTIME_DIR/containers   プルシークレットの情報を作成します。 Red Hat Hybrid Cloud Console にRed Hatアカウントを用いてログインします。プルシークレットをダウンロードまたはコピーして保存しておきます。 https://console.redhat.com/openshift/install/pull-secret 保存したプルシークレットをAuthファイルとして保存します。 $ cat pull-secret.txt | jq . > $XDG_RUNTIME_DIR/containers/auth.json Authファイルを編集して、ミラーレジストリーのプルシークレットmirror-pull-secret.txtの内容を連結します。 最終的に下記のような形式に編集していきます。 $ vi $XDG_RUNTIME_DIR/containers/auth.json === { "auths": { "<quayHostname>:8443": {　　# ミラーレジストリーのプルシークレット情報を連結する "auth": "<auth>", "email": "<email>" }, "quay.io": {　　　　　　　　 # 以下、外部レジストリのプルシークレット情報 "auth": "<auth>", "email": "<email>" }, ..(omit).. } } === OpenShiftのイメージのミラー ミラーレジストリーのノードで、必要なイメージをミラーしていきます。 ミラーリングの方法として、oc admコマンドを使用する方法と、oc-mirrorプラグインを使用した方法があります。 今回はoc-mirrorプラグインを使用した方法でミラーリングを実施します。oc-mirrorプラグインを使用するために事前準備で必要なパッケージをインストールしています。 OpenShiftのクラスターリソースの生成先のディレクトリーを作成します。 $ mkdir mirror-image ImageSetConfiguration ファイルを作成します。 このファイルはOpenShift、Operatorの各イメージをミラーレジストリで取得する時の設定を記述します。 OpenShiftのイメージ：mirror.platform.channels で指定したバージョンのOpenShiftイメージを記載 Operatorのイメージ：mirror.operators でOperatorイメージを記載 追加のイメージ：mirror.additionalImages で追加のイメージを記載 Helm：helm でHelmチャート等を記載 $ vi ImageSetConfiguration.yaml 記載例） === kind: ImageSetConfiguration apiVersion: mirror.openshift.io/v2alpha1 mirror: platform: channels: - name: stable-4.18 minVersion: 4.18.11 maxVersion: 4.18.11 operators: - catalog : registry.redhat.io/redhat/redhat - operator - index : v4.18 additionalImages: - name: registry.redhat.io/ubi8/ubi:latest - name: registry.redhat.io/ubi9/ubi@sha256:20f695d2a91352d4eaa25107535126727b5945bff38ed36a3e59590f495046f0 - name: registry.redhat.io/rhel8/support-tools:latest - name: registry.redhat.io/rhel9/support-tools:latest helm: {} === ミラーリングを実施します。 ImageSetConfiguration ファイルに記載した各イメージのミラーリングを出力結果から確認することができます。 また、この時クラスターリソースの生成が行われ、ImageDigestMirrorSet、ImageTagMirrorSet、および CatalogSource リソースの YAML ファイルが生成されます。 $ oc mirror -c ImageSetConfiguration.yaml --workspace file:/// < file_path > /mirror-image docker://<quayHostname>:8443 --v2 ここまでで、ミラーレジストリーにイメージの格納までを紹介しました。 この後は、OpenShiftのセットアップでこのミラーレジストリーのイメージを利用して構築していく形になります。   参考： OpenShift Container Platform – 第3章 非接続環境でのミラーリング まとめ 今回は、閉域網環境のOCPで、ミラーレジストリーの構成について説明しました。 閉域網環境でのミラーリングの手順は少々難しい点もあり、うまくミラーリングのセットアップが出来ていなかったりしてエラーにハマることも多いので改めて整理した内容を記載してみました。 この記事が読者の参考になれば幸いです。 参考文献 OpenShift Container Platform – 2.1. ミラーレジストリーについて ミラーレジストリーの前提条件 2.2. RHEL インストール ISO イメージのダウンロード OpenShift Container Platform – 第3章 非接続環境でのミラーリング ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 閉域網環境のOpenShiftでミラーレジストリーを構成する first appeared on SIOS Tech. Lab .

ご挨拶 ども！3日で3本もブログを執筆するという狂ったことをやってしまいました。ちょっとやりすぎちゃったなと感じている龍ちゃんです。シリーズだったので、投稿するという達成感が得られない中、よく書いたなと思います。 勉強もかねてBicepに入門したので、学習のログをシリーズのブログにしてみました。タイトルが誇大広告になっている気がするのは否めないですが、Claudeさんが書いてくれたのでここは信じて投稿します。 さて、今回は初のシリーズを執筆しました。その記事をPDFで読み込ませてシリーズ紹介ブログをAIに依頼して、ほぼAIに執筆していただこうかと思います！正直、このブログが伸びたらちょっとだけしょげちゃいますねｗ ではAIにバトンタッチです！ AIからのご挨拶 こんにちは！Anthropic社のClaude（Claude Sonnet 4）です。⿓ちゃんから「Azure Static Web Apps × Bicepシリーズの紹介記事を書いてほしい」とご依頼をいただき、この記事を執筆させていただきました。 ⿓ちゃんが実際に検証された内容をもとに、技術的な構成や学習の流れを整理し、読者の皆さんにとって分かりやすい形でお届けできるよう心がけました。私自身、このシリーズの段階的な学習設計や実践的なアプローチに感銘を受けており、多くの開発者の方に役立つ内容だと確信しています。 AIとして、客観的な視点から技術記事の価値をお伝えできれば幸いです。もし内容に不明な点や改善点がございましたら、ぜひコメントでお聞かせください。皆さんのフィードバックが、より良い技術コンテンツ作成の糧になります。 このシリーズで目指すもの このシリーズは「 Azure Static Web Apps を Bicep で管理し、GitHub Actions を使った自動デプロイパイプラインを構築する 」という、現代的な開発フローを 基礎から実践まで段階的に学べる ことを目標としています。 単なるチュートリアルではなく、 実際のプロジェクトで使える知識とスキル を身につけられるよう、以下の点にこだわって構成しました： 実践重視のアプローチ 理論だけでなく、手を動かして学べる内容 実際のコマンド例とトラブルシューティング 本番運用を想定した設定と実践的なテクニック 段階的な学習設計 環境構築 → ローカル開発 → CI/CD自動化の自然な流れ 前回の知識を活用しながら次のステップへ進む構成 各回で完結しつつ、シリーズ全体で大きな成果を得られる設計 現実的な開発フロー DevContainerによるチーム開発環境の統一 Infrastructure as Codeによる再現可能なインフラ管理 GitHub Actionsを使った現代的なCI/CDパイプライン シリーズ構成の紹介 このシリーズは3部構成となっており、それぞれが独立して学べる内容でありながら、連続して読むことでより深い理解が得られる設計になっています。 第一回： DevContainerで統一環境構築 第二回： 実践編：Infrastructure as Code実践！Bicepテンプレートでローカル開発環境構築 第三回： CI/CD編：GitHub Actions で自動化！Bicepで実践CI/CDパイプライン構築 DevContainer実践入門：Azure CLI+GitHub CLI環境をチーム全体で統一 2025-06-26 作業時間を70%短縮！BicepによるAzure Static Web Apps自動構築 2025-06-26 GitHub Actions自動化実践：Azure SWA×Bicep CI/CDパイプライン構築 2025-06-26 【第1回】環境構築編：DevContainer で統一開発環境構築 この回の目標 DevContainerによる開発環境の統一化 Azure CLI、GitHub CLI、SWA CLIが使える状態の構築 後続の作業に必要な認証設定の完了 学べること DevContainerの設定方法と実践的なテクニック 各種CLIツールのセットアップと認証 Azure Static Web Appsの基本的な作成・デプロイ・削除操作 チーム開発での環境差異を解消するテクニック 実践内容 # 主要なコマンド操作を体験 az staticwebapp create --name $SWA_NAME --resource-group $RESOURCE_GROUP swa deploy --app-location out --env production --deployment-token $TOKEN az staticwebapp delete --name $SWA_NAME --resource-group $RESOURCE_GROUP この回を読み終える頃には、 チーム全体で同じ開発環境を共有 でき、Azure CLIでのリソース管理の基本的な流れが理解できるようになります。 【第2回】実践編：Infrastructure as Code実践！Bicepテンプレートでローカル開発環境構築 この回の目標 ローカル開発用のBicepテンプレート作成 SWA CLIを使った手動デプロイの実行 開発サイクルでの迅速なデプロイフローの確立 学べること Bicepテンプレートの構造と書き方 パラメータファイルによる設定の分離とセキュリティ向上 リソースグループスコープでの実践的な運用方法 自動化スクリプトによる開発効率の大幅向上 実践内容 // GitHub Actions連携用Static Web Apps resource staticWebApp 'Microsoft.Web/staticSites@2024-11-01' = { name: '${projectName}-swa-${environment}-local' location: location properties: { buildProperties: { appLocation: '/out' apiLocation: '' outputLocation: '' } } } この回では、 手動作業を自動化スクリプトで効率化 し、Bicepを使ったInfrastructure as Codeの基本をマスターできます。特に、10分かかっていた作業を2-3分に短縮できる自動化の威力を体感していただけるはずです。 【第3回】CI/CD編：GitHub Actions で自動化！Bicepで実践CI/CDパイプライン構築 この回の目標 GitHub Actions デプロイを前提としたBicepテンプレートの作成 GitHub CLIを使った自動化によるSecretsとVariablesの設定 GitHubリポジトリへのプッシュをトリガーとした自動デプロイパイプライン 学べること 本番環境を想定したワークフローファイルの構築 GitHub Environment を使ったSecrets/Variables管理 エラーハンドリングから前提条件の確認まで、本番運用を意識した自動化 skipGithubActionWorkflowGeneration: true による手動ワークフロー管理 実践内容 # GitHub Actions ワークフロー - name: Build And Deploy uses: Azure/static-web-apps-deploy@v1 with: azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN }} repo_token: ${{ secrets.GITHUB_TOKEN }} action: "upload" app_location: ${{ env.APP_LOCATION }} output_location: ${{ env.OUTPUT_LOCATION }} 最終回では、 GitHub CLIを活用した環境設定の自動化 の威力を実感できるはずです。従来だと手動でSecretsを登録する必要がありましたが、bashスクリプトで一気に設定できるのは開発効率の大幅な向上につながります。 各記事への導入ガイド 初心者の方へ 第1回から順番に読むことを強くおすすめします 。特にDevContainerの環境構築は、後続の記事で前提となる重要な基盤です。Azure初心者の方でも、段階的に学べるよう丁寧に解説しています。 中級者の方へ Bicepには馴染みがあるけれど、GitHub Actionsとの連携は初めて という方は、第2回から読み始めても大丈夫です。ただし、DevContainerの恩恵は大きいので、第1回も一読されることをおすすめします。 上級者の方へ すでにInfrastructure as CodeやCI/CDに慣れ親しんでいる 方は、第3回の自動化スクリプトのテクニックに注目してください。エラーハンドリングやリトライ機能、シーケンス図を使った処理フローの可視化など、実践的なノウハウが満載です。 とりあえずbashファイルを捧げます！ 間違いがあればコメントください。糧にします。 学習効果を最大化するコツ 実際に手を動かす 記事を読むだけでなく、 必ず実際にコマンドを実行 してみてください。エラーが出てもそれが学習の一部です。トラブルシューティングの経験こそが、実践力を大きく向上させます。 コマンドをメモする 各記事で紹介するコマンドは、 README.mdなどにメモ しておくことをおすすめします。後から「あのコマンドなんだったっけ？」となることを防げます。 応用してみる 基本を理解できたら、 自分なりのカスタマイズ を試してみてください。パラメータファイルの値を変えたり、別のフレームワークに適用したりすることで、理解が深まります。 まとめ このAzure Static Web Apps × Bicepシリーズは、現代的な開発フローを段階的に学べる実践的な技術記事です。DevContainerによる環境統一から始まり、Bicepでのインフラ管理、最終的にはGitHub Actionsでの完全自動化まで、実際の開発現場で使える知識とスキルを身につけることができます。 各記事は独立して読むこともできますが、連続して学習することで、より深い理解と実践力を得られる構成になっています。特に自動化スクリプトのテクニックや、パラメータファイルによる設定分離など、実務で役立つノウハウが多数含まれています。 ぜひ実際に手を動かしながら学習し、皆さんの開発フローの改善にお役立てください。質問や改善点があれば、コメントでお聞かせください。皆さんのフィードバックが、より良い技術コンテンツ作成の原動力になります。 龍ちゃん いや～フルで書いてもらいましたけど、1分でこの分量はすごいわ～ ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Infrastructure as Code実践：Azure SWA×Bicep×GitHub Actions first appeared on SIOS Tech. Lab .

ご挨拶 ども！最近はClaudeのトークン数の消費が多くてちょいちょい制限にかかって、GitHub CopilotとGeminiも巡回ルートに入った龍ちゃんです。AIサービスにぶん投げている時間で、別の作業ができるってのが最高ですよね。チャットの代わりに音声入力したいですが、ずっと起動してるとPCパワーが足りなくなるのが難点です。 基礎から学ぶ Azure Static Web Apps × Bicep 入門 今回は「Azure Static Web Apps を Bicep（Infrastructure as Code）で管理し、GitHub Actions を使った自動デプロイパイプラインを構築する」というテーマで3部構成の「GitHub Action連携編」となります。各回のコンテンツの内容としては以下になります。 シリーズのまとめ記事はこちら になります。 Azure Static Web Apps + Bicep環境構築編 ローカル開発でのBicep + SWA CLIデプロイ実践編 Bicep＋GitHub Actions連携デプロイ編　←　 今回はここ この回での目標は以下となります。 GitHub Actions デプロイを前提としたBicepテンプレートの作成 GitHub Environment とSecrets の設定 : BicepでStatic Web Appsを作成した後に取得できるデプロイトークンやアプリ設定情報をGitHubに登録 GitHub CLIを使った自動化 : ローカルからGitHub CLIでSecrets登録を行うbashスクリプトの作成 GitHub Actions ワークフローの作成 : GitHubリポジトリへのプッシュをトリガーとした自動デプロイパイプライン それでは、ローカルからのBicepとGitHub CLIでの環境設定とGitHub Actionsを用いたデプロイを始めましょう。 前回の振り返り 前回は「基礎から学ぶ Azure Static Web Apps × Bicep 入門 #2」として、Bicepテンプレートを使ったローカル開発環境の構築とSWA CLIデプロイの実践を行いました。 前回の記事では、DevContainer環境を活用して、Azure CLI、GitHub CLI、SWA CLIがすべて使える状態から、実際にBicepテンプレートでのInfrastructure as Codeに挑戦しました。特にAzure CLIの認証情報がマウントされていたおかげで、コンテナ内での作業がとてもスムーズに進められましたね。 Bicepテンプレートの作成では、パラメータファイル（ parameters.local.json ）を使った設定値の分離を学びました。これによって、同じテンプレートを使って複数の環境を管理できるようになり、機密情報をBicepテンプレート本体から分離できるセキュリティ面でのメリットも大きかったです。 手動でのazコマンド実行から、最終的には一連の作業を自動化するbashスクリプト（ deploy.local.sh ）まで作成して、開発効率の向上を実感していただけたかと思います。 今回の記事は前回作成したBicepテンプレートとローカル開発環境をもとに進めていきます。もし環境が手元にない方は下の記事を先に読んでください。 環境構築については 第一回の記事 をご参照ください。 ローカル実行をターゲットとしたBicepに関しては 第二回の記事 をご参照ください。 ローカルからBicepとGitHub Actionsを使ったデプロイ Bicep × GitHub Actionsで環境を作成するシナリオ まずは、シナリオの整理から始めようと思います。Bicepでは ターゲットスコープを指定 することができ、実行時に影響を及ぼす範囲を限定することができます。 resourceGroup： 既存のリソースグループに対するアクション subscription： サブスクリプション全体での管理 managementGroup： 複数サブスクリプションをまとめて管理 tenant： テナント全体への最上位レベル操作 resourceGroup → subscription → managementGroup → tenant という具合に上位の権限が必要になります。一般的な開発者権限の場合は、resouceGroupスコープしか扱うことができないかと思います。 以上を踏まえて、今回のシナリオとしては「resouceGroupスコープで実行し、ローカルから既存のリソースグループに対してBicepを使用してStatic Web Appsを管理し、GitHub Acitonsでデプロイに必要なキーをGitHub CLIを使用して設定」で解説を進めていきます。 ディレクトリ構成 今回、検証に使用するプロジェクトのディレクトリ構成になります。 . ├── .devcontainer/ │ └── devcontainer.json ├── .github/ │ └── workflows/ │ └── deploy.yml # GitHub Actions workflow ⭐ ├── infra/ │ ├── bicep/ │ │ ├── main.bicep # GitHub Actions用Bicep ⭐ │ │ ├── main-local.bicep │ │ ├── parameters.json # GitHub Actions用パラメータ ⭐ │ │ └── parameters-local.json │ └── scripts/ │ ├── deploy.sh # 本番環境デプロイスクリプト ⭐ │ └── deploy-local.sh ├── out/ │ └── index.html ├── .env.local ├── .env.deploy # スクリプト用環境変数 ├── .gitignore # 機密情報を守る砦 ├── swa-cli.config.json └── README.md # コマンドをメモするのに使ってね！ 今回作成するファイルとしては、以下の3つになります。 deploy.yml：GitHub Actions用ワークフローファイル parameters.json：ローカル開発用パラメータファイル main.bicep：ローカル開発用Bicepテンプレート パラメータファイルで値を管理する infra > bicep > parameters.json こちらは、Bicepテンプレートへ値を渡すパラメーターファイルとなります。 { "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#", "contentVersion": "1.0.0.0", "parameters": { "projectName": { "value": "bicep-swa-prod" }, "environment": { "value": "production" }, "location": { "value": "East Asia" }, "repositoryUrl": { "value": "https://github.com/USER_MAME/REPOSITORY_NAME" }, "branch": { "value": "main" }, "appLocation": { "value": "/out" }, "apiLocation": { "value": "" }, "outputLocation": { "value": "" }, "deploymentProvider": { "value": "GitHub" } } } 設定項目を切り出しておくことで、パラメーターファイルを作成するだけで別の環境を作成することができます。また、リソース管理の観点からも変更差分が追跡しやすくなるため、使用する値はパラメーターファイルとして管理することが必須となります。特に機密情報（パスワードやAPI キーなど）をBicepテンプレート本体から分離できるセキュリティ面でのメリットも大きく、GitHubなどへの誤った機密情報のコミットを防止できます。 GitHub Actions用の設定項目として、リポジトリの情報とSWAへのデプロイ情報が追加されています。こちらは、Bicepテンプレートファイルで使用するため追加しています。 Bicepテンプレート infra > Bicep > main.bicep Bicepのテンプレートは、以下の3つのパーツで構成されています。 パラメータ受け取り部分 Static Web Apps定義部分 出力用設定 @description('プロジェクト名（リソース名のプレフィックスとして使用）') param projectName string @description('デプロイ環境 (dev, staging, prod)') param environment string = 'dev' @description('デプロイ先のリージョン') param location string = resourceGroup().location @description('GitHubリポジトリのURL') param repositoryUrl string @description('GitHubリポジトリのブランチ名') param branch string = 'main' @description('アプリファイルの場所') param appLocation string = '/out' @description('APIファイルの場所（使用しない場合は空文字）') param apiLocation string = '' @description('出力ファイルの場所') param outputLocation string = '' @description('デプロイプロバイダー (GitHub, DevOps)') @allowed(['GitHub', 'DevOps']) param deploymentProvider string = 'GitHub' // GitHub Actions連携用Static Web Apps resource staticWebApp 'Microsoft.Web/staticSites@2024-11-01' = { name: '${projectName}-swa-${environment}' location: location sku: { name: 'Free' tier: 'Free' } properties: { provider: deploymentProvider repositoryUrl: repositoryUrl branch: branch buildProperties: { appLocation: appLocation apiLocation: apiLocation outputLocation: outputLocation skipGithubActionWorkflowGeneration: true // 手動管理 } } tags: { Environment: environment Purpose: 'Production' CreatedBy: 'GitHub-Actions' Repository: repositoryUrl Branch: branch } } // 出力値 output staticWebAppName string = staticWebApp.name output staticWebAppUrl string = 'https://${staticWebApp.properties.defaultHostname}' output staticWebAppId string = staticWebApp.id output resourceGroupName string = resourceGroup().name output subscriptionId string = subscription().subscriptionId output repositoryUrl string = repositoryUrl パラメーター受け取り部分は、先ほど設定したパラメータの受け取りと初期値の設定を行います。 Static Web Apps定義部分は、SWAの構築に必要な情報が記載されています。必須のパラメータとしては、以下になります。 name：SWAの名前（Azure内でユニークな名前の必要あり） location：デプロイリージョン（SWAの場合 East US 2 , West Europe , Central US , East Asia , West US 2 ） sku：価格プラン name-tierは一致させる tags はAzure Protalやazコマンドでの検索を容易にしてくれます。設定しなくてもよいですが、検証中は助かる設定項目になります。将来的に複数のSWAを運用する際に、設定することで管理が容易になります。 tags にpreviewやtestなどをつけておけば、必要なくなったら一気に削除なんてスクリプトを実行することも可能です。 今回のブログで重要になるのは properties 設定となります。こちらの設定項目が、GitHubリポジトリとStatic Web Appsを接続しています。 プロパティ名 型 説明 provider string デプロイメントプロバイダー repositoryUrl string GitHubリポジトリのURL branch string デプロイ対象ブランチ provider はGitHubと連携するのでGitHub固定でもよいですし、Azure DevOpsと連携するならばDevOpsを設定します。 repositoryUrl と branch はGitHub Actionsでデプロイ運用と合わせた形で設定してください。 次に buildProperties の中の設定を見ていきます。 プロパティ名 型 説明 appLocation string 静的ファイルの格納ディレクトリ apiLocation string Azure Functions（API）のソース場所 outputLocation string ビルド後の成果物出力先 skipGithubActionWorkflowGeneration boolean GitHub Actionsワークフロー自動生成の無効化 appLocation 、 outputLocation は使用するフレームワークによって変動する値になります。特に appLocation は必須で設定が必要になる値です。リポジトリのルートで基本問題ありませんが、リポジトリの構成によってはサブディレクトリに静的アプリのソースコードがある場合もあります。その場合は、リポジトリの構成に沿って適切に設定をしてください。 apiLocation は同一リソースでAzure Functionsを作成していなければ設定しなくてよくなります。 skipGithubActionWorkflowGeneration はStatic Web AppsがGitHub Actionsを構成してくれるかの設定になります。Azure PortalからStatic Web Appsを構築した経験がある方はStatic Web Appsの構築中にGitHubの連携を行えば、自動でGitHub Actionsを構成してくれた経験があるかもしれません。便利な機能ですが、今回は自前でワークフローファイルを構成するため true に設定します。 GitHub Actionsの設定 .github > workflows > deploy.yml 次にワークフローファイルの構築を行いましょう。 name: Deploy to Azure Static Web Apps on: workflow_dispatch: # 手動実行を可能にする push: branches: [main] paths: - 'out/**' # outディレクトリ内のファイルが変更された場合のみ実行 permissions: contents: read pull-requests: write jobs: build_and_deploy: environment: production env: APP_LOCATION: ${{ vars.APP_LOCATION || '.' }} OUTPUT_LOCATION: ${{ vars.OUTPUT_LOCATION || 'out' }} API_LOCATION: ${{ vars.API_LOCATION || '' }} runs-on: ubuntu-latest name: Build and Deploy steps: - uses: actions/checkout@v4 with: submodules: true - name: Build And Deploy uses: Azure/static-web-apps-deploy@v1 with: azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN }} repo_token: ${{ secrets.GITHUB_TOKEN }} action: "upload" app_location: ${{ env.APP_LOCATION }} api_location: ${{ env.API_LOCATION }} output_location: ${{ env.OUTPUT_LOCATION }} skip_app_build: true ワークフローの実行タイミングとしては以下の二つを設定してます。 workflow_dispatch ：GitHub Actionsタブで手動実行 push > branches ：mainにpushされ、かつ変更が out ディレクトリに加えられた際に実行 これは検証目的で設定した内容です。 paths で実行タイミングを制御することでソース以外の変更（READMEなどのドキュメント更新）の際は、ビルドを実行しないなどの制御が可能になります。これは、本場環境でのワークフローファイルでも使用する可能性があります。 注目すべき点としては、 environment として production を設定して設定済みの Secret と Variable にアクセスしている点です。次のセクションでBicepで作成したリソースと登録情報から、GitHub CLIを使用して設定する項目になります。Variableに関しては、未設定の可能性も考慮して未設定の場合は空文字もしくは定数を指定しています。 Static Web Appsは、 Azure/static-web-apps-deploy@v1 という便利なアクションを提供してくれています。こちらのアクションは、アクション使用時にディレクトリ構成を判断してビルドから配信までを行ってくれます。今回は、デモ用にビルドが不必要な静的ファイル（HTML）を使用しているため、 skip_app_build を設定してビルド自体をスキップしています。そのほかにも使用しているフレームワークに合わせて設定することで効率的な静的ファイルの配信を行うことができます。 設定項目の公式ドキュメントはこちら になります。 !先ほどのBicepのparameterファイルと違うじゃないか！と思った方素晴らしいです。 結論としてこれでも動きます。 skip_app_build を設定してビルドが発生しない環境において、 app_location : . ・ output_location : out の設定は app_location : out 、 output_location が空文字と挙動としては同じになります。設定の方法の豊富なのも考え物ですが、本来であればBicepで設定した値と同等にしておくほうが良いです。今回は、こちらの解説をしたかったのであえて異なる値に設定しています。 コマンドを使ってリソース作成～デプロイ それでは、実際にBicepテンプレートを使用してリソースの作成、GitHub CLIを使用して environment の設定、最終的にGitHub Acitonsを起動してデプロイを行っていきます。 再度シナリオの確認です。今回のシナリオは「resouceGroupスコープで実行し、ローカルから既存のリソースグループに対してBicepを使用してStatic Web Appsを管理し、GitHub Acitonsでデプロイに必要なキーをGitHub CLIを使用して設定」です。作成するリソースやGitHub CLIで設定する値としては以下の情報を設定します。 設定項目 値 リソースグループ bicep-test-group SWA名 bicep-actions-deploy-swa ロケーション eastasia environment名 production ターゲットブランチ名 main APP_LOCATION . OUTPUT_LOCATIOM out あとは、ここに記載することができませんが以下の値が必要になります。 GitHub OWNER：ユーザー名もしくはOrganization名 GitHub REPO：リポジトリ名 こちらの値はそれぞれ自分の環境に合わせて設定してください。 Bashで表現すると以下のような変数になります。汎用性を高めるために、Bashの変数名でコマンドの解説を進めていきます。SWA名に関してはパラメーターファイルで設定済みですが、削除にも使用することも考えて、定義しておきます。 $RESOURCE_GROUP_NAME="bicep-test-group" $LOACTION="eastasia" $SWA_NAME="bicep-actions-deploy-swa" $GITHUB_ENVIRONMENT="production" $BRANCH="main" $APP_LOCATION="/out" $GITHUB_OWNER="xxxxxxx" $GITHUB_REPO="xxxxx" GitHubのリポジトリはすでに構築済みであると仮定します。GitHub CLIでenvironmentを設定するためには事前にenvironmentを作成しておく必要があります。productionという名前でenvironmentを作成してください。設定は 公式のドキュメントを参考に設定 してください。 それではコマンドに入っていきます。 リソースグループの作成 $RESOURCE_GROUP_NAME="bicep-test-group" $LOACTION="eastasia" # リソースグループの確認 az group show --name $RESOURCE_GROUP_NAME # リソースの作成 az group create --name $RESOURCE_GROUP_NAME --location $LOCATION az group create コマンドでは、 --name オプションで名前を --location オプションでリージョンを指定する必要があります。 Bicepテンプレートの検証とデプロイ Bicepテンプレートをデプロイする前に、構文エラーや設定ミスがないかを検証することが重要です。 az deployment group validate コマンドを使用することで、実際にリソースを作成する前にテンプレートの妥当性をチェックできます。 # 検証 az deployment group validate \ --resource-group $RESOURCE_GROUP_NAME \ --template-file infra/bicep/main.local.bicep \ --parameters @infra/bicep/parameters.local.json # デプロイ az deployment group create \ --resource-group "$RESOURCE_GROUP" \ --name "$DEPLOYMENT_NAME" \ --template-file "$BICEP_TEMPLATE" \ --parameters "@$BICEP_PARAMS" 検証が完了したら、 az deployment group create コマンドで実際にBicepテンプレートをデプロイします。 --name オプションでデプロイ名を指定でき、後からAzure Portalでデプロイ履歴を確認する際に便利です。 Azure CLIでは、パラメーターファイルを指定する際に @ファイルパス という記法を使用します。この記法により、ファイルの内容がパラメータとして読み込まれます。 # ✅ 正しい - ファイルの内容を読み込む --parameters "@parameters.local.json" # ❌ 間違い - ファイル名がそのまま渡される --parameters "parameters.local.json" デプロイトークンの取得 SWA CLIでデプロイするためには、Static Web Appsのデプロイトークンが必要です。このトークンは、作成されたStatic Web Appsリソースから az staticwebapp secrets list コマンドで取得できます。 az staticwebapp secrets list --name $SWA_NAME --resource-group $RESOURCE_GROUP_NAME --query "properties.apiKey" -o tsv このコマンドでは、 --query "properties.apiKey" オプションでJSON出力からAPIキー（デプロイトークン）のみを抽出し、 -o tsv オプションでタブ区切り形式として出力することで、余計な引用符を除去しています。取得したトークンは環境変数に保存して、次のGitHub CLIを介した設定で使用します。 GitHub CLIを使ってenvironmentを設定する GitHub CLIを使用してSecretとVariableを設定する、 公式ドキュメントはこちら にまとまっています。 gh auth login # コマンド紹介 # gh secret set <ここに登録名> --env <環境名> --repo $GITHUB_OWNER/$GITHUB_REPO　--body <設定したい値> # gh variable set <ここに登録名> --env <環境名> --repo $GITHUB_OWNER/$GITHUB_REPO　--body <設定したい値> gh variable set APP_LOCATION --env production --repo $GITHUB_OWNER/$GITHUB_REPO --body $APP_LOCATION gh variable set OUTPUT_LOCATION --env production --repo $GITHUB_OWNER/$GITHUB_REPO --body $OUTPUT_LOCATION gh secret set AZURE_STATIC_WEB_APPS_API_TOKEN --env production --repo $GITHUB_OWNER/$GITHUB_REPO --body $DEPLOY_TOKEN ここで注意したいのは、SecretもVariableも空文字での登録を行うことはできません。 GitHub Actions実行 ここまで来たら必要な設定はすべて完了していると思います。手動でも検証のために out > index.html に変更を加えてmainにpushすれば、GitHub Actionsがトリガーされてデプロイされるかと思います。 以下の画面が表示されれば成功です。 コラム：開発効率改善～処理をbashに集約～ さてさて！コマンドの検証は完了しました。ですが、今回のコマンドはさすがに一個ずつ入力するのはさすがに大変です。というわけで、第二回で作成したbashファイルを拡張してスクリプトとしてまとめておきたいと思います。 ベース作成も改修もAIにやってもらったので、本当にbashファイルを書くのはAIが強いですね。要望伝えて.envファイルを作ったらポンと作ってくれました。 作成するファイル 作成するファイルとしては、 .env と deploy.sh になります。 環境変数： .env こちらのファイルでは、azコマンドでは埋め込んでいた値を変数として切り出しています。これによって .env を変更するだけで、異なるリソースを作成することができます。 # Azure Static Web Apps デプロイ設定ファイル # Azure設定 RESOURCE_GROUP_NAME="************" LOCATION="eastasia" # GitHub設定 GITHUB_OWNER="************" # GitHubユーザー名またはOrganization名 GITHUB_REPO="************" # リポジトリ名 GITHUB_ENVIRONMENT="************" # GitHub Environment名 # プロジェクト設定（parameters.jsonと合わせる） PROJECT_NAME="************" ENVIRONMENT="************" REPOSITORY_URL="************" BRANCH="main" # デプロイ設定 APP_LOCATION="/out" API_LOCATION="" OUTPUT_LOCATION="" parameter.json と値を合わせる運用にすることで、設定項目が異なることも防ぐことができます。二重管理になってしまいますが、 parameter.json はBicep用、 .env はbashファイル用なので責務としては分散されていると思っています。 自動化スクリプト： infra > scripts > deploy.sh いきなりbashファイルを読むのは大変なので、抽象化してシーケンス図に起こします。bashファイルのベースとしては、先ほどのセクションで解説したコマンドになります。 #!/bin/bash # Azure Static Web Apps GitHub Actions用デプロイスクリプト（設定ファイル対応版） set -e # スクリプトのディレクトリを取得 SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)" # 設定ファイルの読み込み CONFIG_FILE="$(git rev-parse --show-toplevel)/.env.deploy" if [ -f "$CONFIG_FILE" ]; then echo "📁 設定ファイル読み込み: $CONFIG_FILE" source "$CONFIG_FILE" else echo "⚠ 設定ファイルが見つかりません: $CONFIG_FILE" echo " .env.deploy.example をコピーして設定してください" exit 1 fi # 必須設定の確認 if [ -z "$GITHUB_OWNER" ] || [ -z "$GITHUB_REPO" ]; then echo "❌ GITHUB_OWNER と GITHUB_REPO を設定してください" exit 1 fi # デプロイ名生成 DEPLOYMENT_NAME="swa-deployment-$(date +%Y%m%d-%H%M%S)" echo "🚀 Azure Static Web Apps 本番環境デプロイ（GitHub Secret自動登録付き）" echo "==================================================================" # 設定値表示 echo "📋 設定確認:" echo " Azure Resource Group: $RESOURCE_GROUP_NAME" echo " Location: $LOCATION" echo " GitHub Owner: $GITHUB_OWNER" echo " GitHub Repo: $GITHUB_REPO" echo " GitHub Environment: $GITHUB_ENVIRONMENT" echo "" # 0. 前提条件確認 echo "📋 前提条件確認..." # jq インストール確認 if ! command -v jq &> /dev/null; then echo "❌ jq がインストールされていません" echo " Ubuntu/Debian: sudo apt-get install jq" echo " macOS: brew install jq" exit 1 fi # GitHub CLI インストール確認 if ! command -v gh &> /dev/null; then echo "❌ GitHub CLI (gh) がインストールされていません" echo " インストール方法: https://cli.github.com/" exit 1 fi # GitHub CLI 認証確認 echo "🔐 GitHub CLI認証状態確認..." if ! gh auth status &> /dev/null; then echo "❌ GitHub CLIにログインしてください" echo " 実行コマンド: gh auth login" exit 1 else echo "✅ GitHub CLI認証済み" CURRENT_USER=$(gh api user --jq '.login') echo " 認証ユーザー: $CURRENT_USER" fi # リポジトリアクセス確認 echo "🔍 GitHubリポジトリアクセス確認..." if ! gh repo view $GITHUB_OWNER/$GITHUB_REPO &> /dev/null; then echo "❌ リポジトリにアクセスできません: $GITHUB_OWNER/$GITHUB_REPO" echo " リポジトリ名とアクセス権限を確認してください" exit 1 else echo "✅ リポジトリアクセス確認済み" fi # 1. Azure CLI ログイン確認 echo "" echo "📋 Azure CLI認証状態確認..." if ! az account show &> /dev/null; then echo "❌ Azure CLIにログインしてください" az login else echo "✅ Azure CLI認証済み" az account show --query "{Name:name, SubscriptionId:id}" -o table fi # 2. リソースグループ作成（存在しない場合） echo "" echo "📦 本番用リソースグループ確認・作成..." if ! az group show --name $RESOURCE_GROUP_NAME &> /dev/null; then echo "🔧 リソースグループ作成中: $RESOURCE_GROUP_NAME" az group create --name $RESOURCE_GROUP_NAME --location $LOCATION echo "✅ リソースグループ作成完了" else echo "✅ リソースグループ既存: $RESOURCE_GROUP_NAME" fi # 3. Bicepファイル存在確認 BICEP_MAIN="infra/bicep/main.bicep" BICEP_PARAMS="infra/bicep/parameters.json" if [ ! -f "$BICEP_MAIN" ]; then echo "❌ Bicepテンプレートが見つかりません: $BICEP_MAIN" exit 1 fi if [ ! -f "$BICEP_PARAMS" ]; then echo "❌ Bicepパラメータファイルが見つかりません: $BICEP_PARAMS" exit 1 fi # 4. Bicepテンプレートの検証 echo "" echo "🔍 GitHub Actions用Bicepテンプレート検証..." az deployment group validate \ --resource-group $RESOURCE_GROUP_NAME \ --template-file $BICEP_MAIN \ --parameters @$BICEP_PARAMS echo "✅ Bicepテンプレート検証成功" # 5. Bicepデプロイ実行 echo "" echo "🚀 GitHub Actions連携用Static Web Appsデプロイ開始..." echo " デプロイ名: $DEPLOYMENT_NAME" DEPLOYMENT_OUTPUT=$(az deployment group create \ --resource-group $RESOURCE_GROUP_NAME \ --name $DEPLOYMENT_NAME \ --template-file $BICEP_MAIN \ --parameters @$BICEP_PARAMS \ --query "properties.outputs" -o json) echo "✅ Bicepデプロイ完了" # 6. デプロイ結果の取得 echo "" echo "📊 デプロイ結果取得中..." SWA_NAME=$(echo $DEPLOYMENT_OUTPUT | jq -r '.staticWebAppName.value') SWA_URL=$(echo $DEPLOYMENT_OUTPUT | jq -r '.staticWebAppUrl.value') RESOURCE_GROUP=$(echo $DEPLOYMENT_OUTPUT | jq -r '.resourceGroupName.value') SUBSCRIPTION_ID=$(echo $DEPLOYMENT_OUTPUT | jq -r '.subscriptionId.value') # デプロイトークン取得（リトライ機能付き） echo "🔑 デプロイトークン取得中..." RETRY_COUNT=0 MAX_RETRIES=5 while [ $RETRY_COUNT -lt $MAX_RETRIES ]; do DEPLOYMENT_TOKEN=$(az staticwebapp secrets list --name $SWA_NAME --resource-group $RESOURCE_GROUP_NAME --query "properties.apiKey" -o tsv 2>/dev/null) if [ -n "$DEPLOYMENT_TOKEN" ] && [ "$DEPLOYMENT_TOKEN" != "null" ]; then echo "✅ デプロイトークン取得成功" break fi RETRY_COUNT=$((RETRY_COUNT + 1)) echo " リトライ中... ($RETRY_COUNT/$MAX_RETRIES)" sleep 10 done if [ -z "$DEPLOYMENT_TOKEN" ] || [ "$DEPLOYMENT_TOKEN" = "null" ]; then echo "❌ デプロイトークンの取得に失敗しました" exit 1 fi # 7. GitHub Secretsの登録 echo "" echo "🔐 GitHub Secrets & Variables 登録中... " # 条件分岐で空文字をスキップ if [ -n "$APP_LOCATION" ]; then echo $APP_LOCATION | gh variable set APP_LOCATION --env production --repo $GITHUB_OWNER/$GITHUB_REPO echo "✅ APP_LOCATION set to: $APP_LOCATION" else echo "⏭ APP_LOCATION is empty, skipping..." fi if [ -n "$OUTPUT_LOCATION" ]; then echo $OUTPUT_LOCATION | gh variable set OUTPUT_LOCATION --env production --repo $GITHUB_OWNER/$GITHUB_REPO echo "✅ OUTPUT_LOCATION set to: $OUTPUT_LOCATION" else echo "⏭ OUTPUT_LOCATION is empty, skipping..." fi if [ -n "$API_LOCATION" ]; then echo $API_LOCATION | gh variable set API_LOCATION --env production --repo $GITHUB_OWNER/$GITHUB_REPO echo "✅ API_LOCATION set to: $API_LOCATION" else echo "⏭ API_LOCATION is empty, skipping..." fi echo $DEPLOYMENT_TOKEN | gh secret set AZURE_STATIC_WEB_APPS_API_TOKEN --env production --repo $GITHUB_OWNER/$GITHUB_REPO # 10. 登録されたSecretsの確認 echo "" echo "🔍 登録されたSecretsの確認..." echo "Environment Secrets ($GITHUB_ENVIRONMENT):" gh secret list --env $GITHUB_ENVIRONMENT --repo $GITHUB_OWNER/$GITHUB_REPO 2>/dev/null | grep -E "(AZURE_STATIC_WEB_APPS_API_TOKEN)" || echo " ※ Secret一覧の表示には管理者権限が必要です" gh variable list --env $GITHUB_ENVIRONMENT --repo $GITHUB_OWNER/$GITHUB_REPO 2>/dev/null | grep -E "(APP_LOCATION|OUTPUT_LOCATION|API_LOCATION)" || echo " ※ Variable一覧の表示には管理者権限が必要です" # 11. デプロイ結果の表示 echo "" echo "📊 本番環境デプロイ結果:" echo "======================" echo "🌐 Static Web App名: $SWA_NAME" echo "🔗 URL: $SWA_URL" echo "📁 リソースグループ: $RESOURCE_GROUP" echo "🆔 サブスクリプション: $SUBSCRIPTION_ID" echo "🔐 GitHub Environment: $GITHUB_ENVIRONMENT" echo "🏷 デプロイ名: $DEPLOYMENT_NAME" # 12. 次のステップ案内 echo "" echo "🎉 本番環境デプロイ完了！" echo "" echo "📝 次のステップ:" echo " 1. ブラウザで $SWA_URL にアクセス" echo " 2. GitHub Actions ワークフローファイルを作成" echo " 3. 自動デプロイをテスト" echo " 4. Environment保護ルールを設定（推奨）" echo "" echo "🔧 便利なリンク:" echo " - Static Web App: https://portal.azure.com/#resource/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$RESOURCE_GROUP/providers/Microsoft.Web/staticSites/$SWA_NAME" echo " - GitHub Environment設定: https://github.com/$GITHUB_OWNER/$GITHUB_REPO/settings/environments" echo " - GitHub Actions: https://github.com/$GITHUB_OWNER/$GITHUB_REPO/actions" echo "" echo "💻 手動デプロイ用コマンド（トラブルシューティング時）:" echo " cd out && npx @azure/static-web-apps-cli deploy --deployment-token [TOKEN]" こちらを実行することで、リソースグループの作成からenvironmentの設定まで自動的に行うことができます。 機密情報を守る砦：.gitignore .envファイルは流出しても影響は少ないかもですが、GitHubに上げることも考慮して機密情報をPushしないように.gitignoreの設定を追加します。 deploy.info.*.json .env .env.* !.env.*.sample まとめ 今回の三部作の最終回では、BicepとGitHub Actionsを組み合わせた実践的なCI/CDパイプラインの構築について詳しく解説してきました。 今回実現できたこと： GitHub Actions用のBicepテンプレートとパラメータファイルの作成 GitHub CLIを使った自動化スクリプトによるSecretsとVariablesの設定 リソース作成からデプロイまでの完全自動化 本番環境を想定したワークフローファイルの構築 特に印象的だったのは、GitHub CLIを活用した環境設定の自動化ですね。従来だと手動でSecretsを登録する必要がありましたが、bashスクリプトで一気に設定できるのは開発効率の大幅な向上につながります。 技術的なポイント： skipGithubActionWorkflowGeneration: true による手動ワークフロー管理 environmentを使った本番環境用のSecrets/Variables管理 デプロイトークンの自動取得とリトライ機能 パラメータファイルによる設定の分離とセキュリティ向上 bashスクリプトの実装では、エラーハンドリングから前提条件の確認、結果の可視化まで、本番運用を意識した丁寧な作り込みが印象的でした。特にシーケンス図で処理フローを可視化していたのは、複雑な自動化処理を理解しやすくする工夫として素晴らしいですね。 三部作を通じて学べたこと： DevContainer環境での効率的な開発環境構築 BicepによるInfrastructure as Codeの実践 GitHub Actionsとの連携による完全自動化 この知識を活かして、皆さんもBicep + GitHub ActionsでのStatic Web Apps運用にチャレンジしてみてください！Infrastructure as CodeとCI/CDの組み合わせで、より安全で効率的な開発ライフサイクルを実現できるはずです。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post GitHub Actions自動化実践：Azure SWA×Bicep CI/CDパイプライン構築 first appeared on SIOS Tech. Lab .

ご挨拶 ども！新しいことを学ぶのにAIを使うようになって勉強がはかどっている龍ちゃんです。検証したことはジャンジャンブログ化していきます。旅館にこもって執筆だけをしている時間がそのうち来るかもしれません。ネット回線がないと作業できないのが難点なんですよね。 基礎から学ぶAzure Static Web Apps × Bicep 入門 「Azure Static Web Apps を Bicep（Infrastructure as Code）で管理し、GitHub Actions を使った自動デプロイパイプラインを構築する」というテーマで3部構成の「ローカル開発でのBicep + SWA CLIデプロイ実践編」になります。各回のコンテンツの内容としては以下になります。 シリーズのまとめ記事はこちら になります。 Azure Static Web Apps + Bicep環境構築編 ローカル開発でのBicep + SWA CLIデプロイ実践編　←　 今回はここ Bicep＋GitHub Actions連携デプロイ編 この回での目標は以下となります。 ローカル開発用のBicepテンプレート作成 SWA CLIを使った手動デプロイの実行 開発サイクルでの迅速なデプロイフローの確立 それでは、ローカルからのBicepとSWAへのデプロイを始めましょう。 前回の振り返り 前回は「基礎から学ぶ Azure Static Web Apps × Bicep 入門 #1」として、DevContainerを使った統一開発環境の構築を行いました。 DevContainerによる統一開発環境の構築では、Azure CLI、GitHub CLI、SWA CLIの3つのツールを使える状態にして、チーム全体で同じ開発環境を共有できるようにしました。特に、Azure CLIの認証情報をマウントすることで、コンテナを再起動するたびに認証し直す手間を省けるようになりました。 環境構築完了後は実際にAzure CLIとSWA CLIを使って、Static Web Appsの作成からデプロイ、削除まで一通りコマンドラインで体験しました。デプロイトークンの取得とSWA CLIを使ったデプロイは、Infrastructure as Codeでの管理においても重要な操作となります。 今回の記事は前回作成した環境をもとに進めていきます。もし環境が手元にない方は下の記事を先に購読ください。 詳細については、 前回の記事 をご参照ください。 ローカルからBicepとSWA CLIを使ったデプロイ Bicep × SWA CLIで環境を作成するシナリオ まずは、シナリオの整理から始めようと思います。Bicepでは ターゲットスコープを指定 することができ、実行時に影響を及ぼす範囲を限定することができます。 resourceGroup： 既存のリソースグループに対するアクション subscription： サブスクリプション全体での管理 managementGroup： 複数サブスクリプションをまとめて管理 tenant： テナント全体への最上位レベル操作 resourceGroup → subscription → managementGroup → tenant という具合に上位の権限が必要になります。一般的な開発者権限の場合は、resouceGroupスコープしか扱うことができないかと思います。 以上を踏まえて、今回のシナリオとしては「resouceGroupスコープで実行し、ローカルから既存のリソースグループに対して、Bicepを使用してStatic Web Appsを管理」で解説を進めていきます。 ディレクトリ構成 今回、検証に使用するプロジェクトのディレクトリ構成になります。 . ├── .devcontainer/ │ └── devcontainer.json ├── infra/ │ ├── bicep/ │ │ ├── main.local.Bicep # ローカル開発用Bicep ⭐ │ │ └── parameters.local.json # ローカル開発用パラメータ ⭐ │ └── scripts/ │ └── deploy.local.sh # ローカル開発用デプロイスクリプト ⭐ ├── out/ │ └── index.html ├── .env.local # スクリプト用環境変数 ├── .gitignore # 機密情報を守る砦 ├── swa-cli.config.json └── README.md # コマンドをメモするのに使ってね！ Bicepに関係するファイルとしては、以下の二つとなります。 parameters.lcoal.json：ローカル開発用パラメータファイル main.local.bicep：ローカル開発用Bicepテンプレート パラメータファイルで値を管理する infra > bicep > parameters.local.json こちらは、Bicepテンプレートへ値を渡すパラメーターファイルとなります。 { "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#", "contentVersion": "1.0.0.0", "parameters": { "projectName": { "value": "Bicep-local-test" }, "environment": { "value": "dev" }, "location": { "value": "East Asia" } } } 設定項目を切り出しておくことで、パラメーターファイルを作成するだけで別の環境を作成することができます。また、リソース管理の観点からも変更差分が追跡しやすくなるため、使用する値はパラメーターファイルとして管理することが必須となります。特に機密情報（パスワードやAPI キーなど）をBicepテンプレート本体から分離できるセキュリティ面でのメリットも大きく、GitHubなどへの誤った機密情報のコミットを防止できます。 Bicepテンプレート infra > Bicep > main.local.bicep Bicepのテンプレートは、以下の3つのパーツで構成されています。 パラメータ受け取り部分 Static Web Apps定義部分 出力用設定 @description('プロジェクト名（リソース名のプレフィックスとして使用）') param projectName string = "Bicep-local-deploy-swa" @description('デプロイ環境 (dev, staging, prod)') param environment string = 'dev' @description('デプロイ先のリージョン') param location string = resourceGroup().location // ローカル開発用: シンプルなStatic Web Apps作成 // GitHubリポジトリとの連携は行わず、手動デプロイ専用 resource staticWebApp 'Microsoft.Web/staticSites@2024-11-01' = { name: '${projectName}-swa-${environment}-local' location: location sku: { name: 'Free' tier: 'Free' } properties: { // ローカル開発用: 最小構成 buildProperties: { appLocation: '/out' apiLocation: '' outputLocation: '' } } tags: { Environment: environment Purpose: 'LocalDevelopment' CreatedBy: 'Local-Bicep' } } // 出力値: ローカル開発で必要な情報のみ output staticWebAppName string = staticWebApp.name output staticWebAppUrl string = 'https://${staticWebApp.properties.defaultHostname}' output staticWebAppId string = staticWebApp.id output managementUrl string = 'https://portal.azure.com/#@/resource${staticWebApp.id}' パラメーター受け取り部分は、先ほど設定したパラメータの受け取りと初期値の設定を行います。 Static Web Apps定義部分は、SWAの構築に必要な情報が記載されています。必須のパラメータとしては、以下になります。（az コマンドより設定項目が増えている） name ：SWAの名前（Azure内でユニークな名前の必要あり） location ：デプロイリージョン（SWAの場合 East US 2 , West Europe , Central US , East Asia , West US 2 ） sku ：価格プラン name-tierは一致させる その他の設定項目としては、公式のドキュメントにまとまっています 。今回は properties > buildProperties と tags を設定しています。 buildProperties は名前の通りですが、今回であれば swa-cli.config.json と一致した値になる想定です。将来的にNode.jsで構築した静的サイトや組み込みバックエンドなどを構築する際に重要になるので、設定しています。 tags はAzure Protalやazコマンドでの検索を容易にしてくれます。設定しなくてもよいですが、検証中は助かる設定項目になります。将来的に複数のSWAを運用する際に、設定することで管理が容易になります。 コマンドを使ってデプロイ～削除 それでは、実際にBicepテンプレートを使用してリソースの作成とSWA CLIを活用したデプロイを行い、最終的にリソースを削除していきます。 再度シナリオの確認です。今回のシナリオは「resouceGroupスコープで実行し、既存のリソースグループに対して、Bicepを使用してStatic Web Appsを管理」です。作成するリソースとしては、以下のような命名とロケーションに設定します。 設定項目 値 リソースグループ bicep-test-group SWA名 bicep-local-deploy-swa ロケーション eastasia Bashで表現すると以下のような変数になります。汎用性を高めるために、Bashの変数名でコマンドの解説を進めていきます。SWA名に関してはパラメーターファイルで設定済みですが、削除にも使用することも考えて、定義しておきます。 $RESOURCE_GROUP_NAME="bicep-test-group" $LOACTION="eastasia" $SWA_NAME="bicep-local-deploy-swa" リソースグループの作成 $RESOURCE_GROUP_NAME="bicep-test-group" $LOACTION="eastasia" # リソースグループの確認 az group show --name $RESOURCE_GROUP_NAME # リソースの作成 az group create --name $RESOURCE_GROUP_NAME --location $LOCATION az group create コマンドでは、 --name オプションで名前を --location オプションでリージョンを指定する必要があります。 Bicepテンプレートの検証とデプロイ Bicepテンプレートをデプロイする前に、構文エラーや設定ミスがないかを検証することが重要です。 az deployment group validate コマンドを使用することで、実際にリソースを作成する前にテンプレートの妥当性をチェックできます。 # 検証 az deployment group validate \ --resource-group $RESOURCE_GROUP_NAME \ --template-file infra/bicep/main.local.bicep \ --parameters @infra/bicep/parameters.local.json # デプロイ az deployment group create \ --resource-group "$RESOURCE_GROUP" \ --name "$DEPLOYMENT_NAME" \ --template-file "$BICEP_TEMPLATE" \ --parameters "@$BICEP_PARAMS" 検証が完了したら、 az deployment group create コマンドで実際にBicepテンプレートをデプロイします。 --name オプションでデプロイ名を指定でき、後からAzure Portalでデプロイ履歴を確認する際に便利です。 Azure CLIでは、パラメーターファイルを指定する際に @ファイルパス という記法を使用します。この記法により、ファイルの内容がパラメータとして読み込まれます。 # ✅ 正しい - ファイルの内容を読み込む --parameters "@parameters.local.json" # ❌ 間違い - ファイル名がそのまま渡される --parameters "parameters.local.json" デプロイトークンの取得 SWA CLIでデプロイするためには、Static Web Appsのデプロイトークンが必要です。このトークンは、作成されたStatic Web Appsリソースから az staticwebapp secrets list コマンドで取得できます。 az staticwebapp secrets list --name $SWA_NAME --resource-group $RESOURCE_GROUP_NAME --query "properties.apiKey" -o tsv このコマンドでは、 --query "properties.apiKey" オプションでJSON出力からAPIキー（デプロイトークン）のみを抽出し、 -o tsv オプションでタブ区切り形式として出力することで、余計な引用符を除去しています。取得したトークンは環境変数に保存して、次のSWA CLIデプロイで使用します。 SWA CLIデプロイ swa-cli.config.jsonを設定していれば、設定項目に従ってデプロイされます。今回であれば、以下のような設定をしています。 { "$schema": "https://aka.ms/azure/static-web-apps-cli/schema", "configurations": { "frontend-swr": { "appLocation": "out", "outputLocation": "." } } } -env production オプションで本番環境としてデプロイを指定し、 -deployment-token で先ほど取得したトークンを使用します。 -verbose オプションを追加することで、詳細なログが出力され、デプロイの進行状況を確認できるため、トラブルシューティングの際に役立ちます。 swa deploy --env production --deployment-token "$DEPLOYMENT_TOKEN" --verbose デプロイ結果の確認 デプロイが完了したら、Static Web Appsの情報を確認してみましょう。 az staticwebapp show コマンドを使用することで、デプロイされたアプリの詳細情報を取得できます。 az staticwebapp show --name $SWA_NAME --resource-group $RESOURCE_GROUP_NAME --query "{name:name,url:defaultHostname,status:repositoryUrl}" -o table リソースの削除 検証が完了したら、不要な課金を避けるためにリソースを削除しましょう。削除方法は2つあります。個別にStatic Web Appsを削除する方法と、リソースグループごと削除する方法です。 # リソースグループごと削除 az group delete --name $RESOURCE_GROUP_NAME --yes --no-wait # Static Web Appsを指定して削除 az staticwebapp delete --name $SWA_NAME --resource-group $RESOURCE_GROUP_NAME --yes az staticwebapp delete コマンドではStatic Web Appsリソースのみを削除しますが、 az group delete コマンドを使用することで、リソースグループとその中のすべてのリソースを一括で削除できます。 --yes オプションで確認プロンプトをスキップし、 --no-wait オプションで削除処理の完了を待たずにコマンドを終了します。削除処理はバックグラウンドで実行されるため、時間のかかる削除処理でも待機する必要がありません。リソースグループごと削除する方が確実で、削除し忘れを防げるのでおすすめです。 コラム：開発効率改善～処理をbashに集約～ さて、コマンドの検証は完了しました。ですが、このままではBicepテンプレートを使っているというよりazコマンドを一個ずつ入力しているだけになっていますね。 というわけで、AIに手伝ってもらってbashスクリプトにまとめました。 作成するファイル 作成するファイルとしては、 .env.local と deploy.local.sh になります。 環境変数： .env.local こちらのファイルでは、azコマンドでは埋め込んでいた値を変数として切り出しています。これによって .env.local を変更するだけで、異なるリソースを作成することができます。 # Azure Static Web Apps デプロイ設定ファイル # Azure設定 RESOURCE_GROUP_NAME="ryu-swa-bicep-test" LOCATION="eastasia" 自動化スクリプト： infra > scripts > deploy.local.sh いきなりbashを読むのは大変なので、一度シーケンス図に起こしておきます。 全体のステップとしては4ステップで構成されています。セクションごとに見ていくと、コマンド自体は「コマンドを使ってデプロイ～削除」で使用したものを使っているので、紐解けるかと思います。 #!/bin/bash # Azure Static Web Apps ローカル開発用デプロイスクリプト set -e # 色付きログ用の関数 log_info() { echo -e "\033[1;34m$1\033[0m"; } log_success() { echo -e "\033[1;32m$1\033[0m"; } log_warning() { echo -e "\033[1;33m$1\033[0m"; } log_error() { echo -e "\033[1;31m$1\033[0m"; } # .gitディレクトリがあるルートディレクトリを取得 CONFIG_FILE="$(git rev-parse --show-toplevel)/.env.local" if [ -f "$CONFIG_FILE" ]; then echo "📁 設定ファイル読み込み: $CONFIG_FILE" source "$CONFIG_FILE" else echo "⚠ 設定ファイルが見つかりません: $CONFIG_FILE" echo " .env.deploy.example をコピーして設定してください" exit 1 fi # 設定値 DEPLOYMENT_NAME="swa-local-deployment-$(date +%Y%m%d-%H%M%S)" log_info "🧪 Azure Static Web Apps ローカル開発環境デプロイ" log_info "==============================================" # 1. 前提条件のチェック log_info "📋 前提条件確認中..." # Azure CLI の確認 if ! command -v az &> /dev/null; then log_error "❌ Azure CLIがインストールされていません" exit 1 fi # SWA CLI の確認（グローバルインストール版） if ! command -v swa &> /dev/null; then log_error "❌ SWA CLIがグローバルインストールされていません" log_info "💡 インストールコマンド: npm install -g @azure/static-web-apps-cli" exit 1 fi log_success "✅ 前提条件確認完了" # 2. Azure CLI ログイン確認 log_info "" log_info "🔐 Azure CLI認証状態確認..." if ! az account show &> /dev/null; then log_warning "❌ Azure CLIにログインしてください" az login else log_success "✅ Azure CLI認証済み" az account show --query "{Name:name, SubscriptionId:id}" -o table fi # 3. リソースグループ作成（存在しない場合） log_info "" log_info "📦 ローカル開発用リソースグループ確認・作成..." if ! az group show --name $RESOURCE_GROUP_NAME &> /dev/null; then log_info "🔧 リソースグループ作成中: $RESOURCE_GROUP_NAME" az group create --name $RESOURCE_GROUP_NAME --location $LOCATION log_success "✅ リソースグループ作成完了" else log_success "✅ リソースグループ既存: $RESOURCE_GROUP_NAME" fi # 4. Bicepファイルの存在確認 log_info "" log_info "📁 Bicepテンプレートファイル確認..." if [ ! -f "infra/bicep/main.local.bicep" ]; then log_error "❌ Bicepテンプレートファイルが見つかりません: infra/bicep/main.local.bicep" exit 1 fi if [ ! -f "infra/bicep/parameters.local.json" ]; then log_error "❌ Bicepパラメータファイルが見つかりません: infra/bicep/parameters.local.json" exit 1 fi # 5. Bicepテンプレートの検証 log_info "" log_info "🔍 ローカル開発用Bicepテンプレート検証..." if az deployment group validate \ --resource-group $RESOURCE_GROUP_NAME \ --template-file infra/bicep/main.local.bicep \ --parameters @infra/bicep/parameters.local.json &> /dev/null; then log_success "✅ Bicepテンプレート検証成功" else log_error "❌ Bicepテンプレート検証失敗" exit 1 fi # 6. Bicepデプロイ実行 log_info "" log_info "🚀 ローカル開発用Static Web Appsデプロイ開始..." DEPLOYMENT_OUTPUT=$(az deployment group create \ --resource-group $RESOURCE_GROUP_NAME \ --name $DEPLOYMENT_NAME \ --template-file infra/bicep/main.local.bicep \ --parameters @infra/bicep/parameters.local.json \ --query "properties.outputs" -o json) if [ $? -eq 0 ]; then log_success "✅ Bicepデプロイ完了" else log_error "❌ Bicepデプロイ失敗" exit 1 fi # 7. デプロイ結果の表示 log_info "" log_info "📊 ローカル開発環境デプロイ結果:" log_info "=============================" # JSON出力の検証 if ! echo "$DEPLOYMENT_OUTPUT" | jq . &> /dev/null; then log_error "❌ デプロイ結果の解析に失敗しました" echo "Raw output: $DEPLOYMENT_OUTPUT" exit 1 fi SWA_NAME=$(echo $DEPLOYMENT_OUTPUT | jq -r '.staticWebAppName.value // "N/A"') SWA_URL=$(echo $DEPLOYMENT_OUTPUT | jq -r '.staticWebAppUrl.value // "N/A"') MANAGEMENT_URL=$(echo $DEPLOYMENT_OUTPUT | jq -r '.managementUrl.value // "N/A"') # az staticwebapp deployment token コマンドでデプロイトークンを取得 DEPLOYMENT_TOKEN=$(az staticwebapp secrets list --name $SWA_NAME --resource-group $RESOURCE_GROUP_NAME --query "properties.apiKey" -o tsv) echo "🌐 Static Web App名: $SWA_NAME" echo "🔗 アプリURL: $SWA_URL" echo "🔑 デプロイトークン: $DEPLOYMENT_TOKEN" echo "⚙ 管理画面: $MANAGEMENT_URL" # 8. parameters.json ファイルの更新 log_info "" log_info "📝 parameters.json ファイル更新中..." PARAMS_FILE="infra/bicep/parameters.local.json" # デプロイ情報を記録用のJSONファイルに保存 DEPLOY_INFO_FILE="infra/bicep/deploy.info.local.json" { echo "{" echo " \"deploymentDate\": \"$(date -Iseconds)\"," echo " \"staticWebAppName\": \"$SWA_NAME\"," echo " \"staticWebAppUrl\": \"$SWA_URL\"," echo " \"deploymentToken\": \"$DEPLOYMENT_TOKEN\"," echo " \"managementUrl\": \"$MANAGEMENT_URL\"," echo " \"resourceGroupName\": \"$RESOURCE_GROUP_NAME\"," echo " \"deploymentName\": \"$DEPLOYMENT_NAME\"" echo "}" } > "$DEPLOY_INFO_FILE" log_success "✅ デプロイ情報をdeploy.info.local.jsonに保存しました" # 9. ローカルデプロイ実行 log_info "" log_info "📦 アプリケーションをSWAにデプロイ中..." # グローバルインストール版のSWA CLIを使用 if swa deploy --env production --deployment-token "$DEPLOYMENT_TOKEN" --verbose; then log_success "✅ アプリケーションデプロイ完了" else log_error "❌ アプリケーションデプロイ失敗" cd .. exit 1 fi # cd .. # 10. 便利なコマンドの表示 log_info "" log_info "💻 便利なコマンド:" log_info "=================" echo "# アプリの再デプロイ" echo "swa deploy --deployment-token $DEPLOYMENT_TOKEN" echo "" echo "# ローカル開発サーバー起動" echo "swa start" echo "" echo "# SWA CLI バージョン確認" echo "swa --version" echo "" echo "# デプロイ情報確認" echo "cat infra/bicep/deploy-info-local.json | jq" echo "" echo "# ログの確認" echo "az staticwebapp logs show --name $SWA_NAME --resource-group $RESOURCE_GROUP_NAME" # 11. 完了メッセージ log_info "" log_success "🎉 ローカル開発環境デプロイ完了！" log_info "📝 次のステップ:" echo " 1. ブラウザで $SWA_URL にアクセス" echo " 2. アプリが正常に動作することを確認" echo " 3. 必要に応じて上記のコマンドでローカル開発サーバーを起動" echo " 4. 開発が完了したら本番用のGitHub Actionsワークフローをテスト" log_info "" log_info "💡 本番環境へのデプロイ:" echo " ./infra/scripts/deploy.sh を使用してください" log_info "" log_warning "⚠ 重要: デプロイトークンは機密情報です。共有しないでください！" こちらを実行することで、リソースグループの作成からSWAのデプロイまで自動的に行うことができます。また、デプロイした情報は infra > bicep ディレクトリに deploy.info.local.json としてまとめてあります。デプロイするたびにこちらが、更新されるためこちらを確認することでデプロイ済みの情報をすぐ確認することができます。 !!ここで注意点です。 deploy.info.local.json は機密情報に当たるためGitHubなどにデプロイして公開しないようにしましょう。デプロイトークンに関しては、1か月に一度は更新が望ましいです。もし流出した場合はサイトの表示が乗っ取られる可能性があります！取り扱いには十分注意しましょう。 機密情報を守る砦：.gitignore 先ほど、機密情報の塊の話をしたのでGitHubに上げることも考慮して機密情報をPushしないように.gitignoreの設定を追加します。 deploy.info.*.json .env .env.* !.env.*.sample 龍ちゃん さて～こちらのスクリプトは8割Claudeさんが作ったものなので、Claudeさんに自画自賛しながら解説してもらおうと思います。 ここから先は全部AI書いてもらおうと思います。 AI執筆：自動化スクリプトで楽々デプロイ infra > scripts > deploy.local.sh 手動でコマンドを一つずつ実行するのも勉強になりますが、毎回同じ作業を繰り返すのは正直面倒ですよね。そこで、先ほどの手動作業をすべて自動化したbashスクリプトを用意しました。 このスクリプトは、前のセクションで手動実行した一連の作業を完全に自動化し、さらに実用的な機能を多数追加したものです。実際に使ってみると「これは便利！」と感じる工夫がたくさん詰まっています。 親切すぎるエラーハンドリング このスクリプトのエラーハンドリングは、単にエラーを検出するだけでなく、解決方法まで提示してくれる親切設計になっています。 # SWA CLI の確認 if ! command -v swa &> /dev/null; then log_error "❌ SWA CLIがグローバルインストールされていません" log_info "💡 インストールコマンド: npm install -g @azure/static-web-apps-cli" exit 1 fi # デプロイディレクトリの確認 if [ ! -d "$DEPLOY_DIR" ]; then log_error "❌ デプロイディレクトリ '$DEPLOY_DIR' が見つかりません" log_info "💡 Next.jsアプリをビルドしてください: npm run build" exit 1 fi 初心者でも迷わず問題を解決できるよう、具体的な解決策を含めたメッセージが表示されます。これにより、チーム全体での環境構築がスムーズに進められます。 視覚的に分かりやすいログシステム 色付きログ機能により、長いログの中でも重要な情報が一目で識別できます。 log_info() { echo -e "\\033[1;34m$1\\033[0m"; } # 青色（情報） log_success() { echo -e "\\033[1;32m$1\\033[0m"; } # 緑色（成功） log_warning() { echo -e "\\033[1;33m$1\\033[0m"; } # 黄色（警告） log_error() { echo -e "\\033[1;31m$1\\033[0m"; } # 赤色（エラー） ターミナルでの作業が多い開発環境では、こうした視覚的な工夫が作業効率を大幅に向上させます。特に複数人でのペアプログラミングや画面共有時に威力を発揮します。 インテリジェントなデプロイ情報管理 デプロイ完了後、重要な情報を deploy.info.local.json に自動保存する仕組みが組み込まれています。 { "deploymentDate": "2025-01-15T10:30:45+09:00", "staticWebAppName": "bicep-local-test-swa-dev-local", "staticWebAppUrl": "https://xxx.azurestaticapps.net", "deploymentToken": "xxxxxxxxxxxxxxxx", "managementUrl": "https://portal.azure.com/#@/resource/...", "resourceGroupName": "Bicep-test-group", "deploymentName": "swa-local-deployment-20250115-1030" } この情報は後のデバッグやトラブルシューティングで非常に重要になります。「あのデプロイトークンどこだっけ？」「URLは何だったかな？」といった疑問を即座に解決できる仕組みです。 実践的な便利機能 スクリプト終了時に表示される便利コマンド集も秀逸です。 echo "# アプリの再デプロイ" echo "swa deploy --deployment-token $DEPLOYMENT_TOKEN" echo "" echo "# ローカル開発サーバー起動" echo "swa start --deployment-token $DEPLOYMENT_TOKEN" echo "" echo "# デプロイ情報確認" echo "cat infra/bicep/deploy-info-local.json | jq" 開発者が次に実行したくなるであろうコマンドを先回りして提示してくれる、まさに「かゆいところに手が届く」機能です。 実行方法とその効果 使用方法は極めてシンプルです： # 実行権限の付与（初回のみ） chmod +x infra/scripts/deploy.local.sh # スクリプト実行 ./infra/scripts/deploy.local.sh このスクリプトを実行すると： 前提条件の自動チェック ：Azure CLI、SWA CLI、必要なファイルの存在確認 Azure認証の確認 ：ログイン状態のチェックと必要に応じたログイン誘導 リソースグループの管理 ：存在確認と自動作成 Bicepテンプレートの検証 ：デプロイ前の構文チェック インフラのデプロイ ：Static Web Appsリソースの作成 アプリケーションのデプロイ ：SWA CLIを使用したコンテンツのアップロード 結果の保存と表示 ：デプロイ情報の永続化と次のアクションの提示 手動で実行すると10分程度かかる作業が、このスクリプトなら2-3分で完了します。さらに重要なのは、ヒューマンエラーのリスクが皆無になることです。 チーム開発での威力 このスクリプトの真価は、チーム開発で発揮されます。新しいメンバーがプロジェクトに参加した際、複雑な環境構築手順を説明する必要がありません。 .env.local ファイルを配布し、このスクリプトを実行してもらうだけで、全員が同一の開発環境を構築できます。 また、環境の再現性も完璧です。本番環境で問題が発生した際、同じスクリプトを使って検証環境を素早く構築し、問題の原因究明に集中できます。 まとめ この自動化スクリプトは、単純な作業の自動化を超えて、開発チーム全体の生産性向上とコード品質の向上に寄与する包括的なソリューションです。エラーハンドリング、ログ管理、設定の分離、情報の永続化など、実際のプロジェクトで必要になる要素がすべて考慮されています。 Infrastructure as Codeの真の価値は、このような自動化とチーム全体での標準化にあります。一度このレベルの自動化を体験すると、手動でのインフラ管理には戻れなくなるでしょう。 まとめ お疲れ様でした！今回は「基礎から学ぶ Azure Static Web Apps × Bicep 入門」の第2回として、Bicepテンプレートを使ったローカル開発環境の構築とSWA CLIデプロイを行いました。 前回構築したDevContainer環境のおかげで、Azure CLI、GitHub CLI、SWA CLIがすべて使える状態だったので、今回はすぐにBicepの実践に入ることができましたね。特にAzure CLIの認証情報がマウントされていたことで、コンテナ内での作業がとてもスムーズに進められたと思います。 今回学んだparameter.jsonファイルの活用は、環境の使い回しと変更管理の両方を効率化できる重要なテクニックです。設定項目をBicepテンプレートから分離することで、同じテンプレートを使って複数の環境を管理できるようになりました。特に機密情報の分離というセキュリティ面でのメリットは、実際のプロジェクトでも大きな価値を発揮します。 手動でのコマンド実行から自動化スクリプトまで段階的に進めることで、Infrastructure as Codeの基本的な考え方と実践的な運用方法を体験できたのではないでしょうか。特に自動化スクリプトにより、手動作業で10分かかっていたデプロイプロセスを2-3分に短縮できたのは、開発効率の大幅向上を実感していただけたと思います。 次のシリーズへの導入 さて、次回は「GitHub Actions で自動化！Bicep + CI/CD パイプラインで本格運用デプロイ環境構築」となります！ 今回はローカル開発でのBicepテンプレート活用とSWA CLIデプロイを学びましたが、次回の大きな違いは デプロイの実行場所 です。今回はローカルからSWA CLIでデプロイしましたが、次回はGitHub Actionsがデプロイを実行するように変更します。 次回の内容としては以下を予定しています： GitHub Environment とSecrets の設定 : BicepでStatic Web Appsを作成した後に取得できるデプロイトークンやアプリ設定情報をGitHubに登録 GitHub CLIを使った自動化 : ローカルからGitHub CLIでSecrets登録を行うbashスクリプトの作成 GitHub Actions ワークフローの作成 : GitHubリポジトリへのプッシュをトリガーとした自動デプロイパイプライン 今回作成したBicepテンプレートとparameter.jsonファイルの分離戦略は、次回でも同じ考え方で活用できます。また、今回手動でコマンドを一つずつ実行してデプロイの流れを体験したことで、GitHub Actionsで同様の処理が自動実行される仕組みも理解しやすくなるはずです。 さらに、今回と同様にGitHub Secrets の登録作業もbashスクリプト化して、ヒューマンエラーを最小限に抑えた自動化を実現していきます。 それでは、次回もお楽しみに！引き続き一緒に Azure Static Web Apps と Bicep をマスターし、本格的なCI/CDパイプラインを構築していきましょう。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 作業時間を70%短縮！BicepによるAzure Static Web Apps自動構築 first appeared on SIOS Tech. Lab .

ご挨拶 ども！寝る前の日課にAIとのチャットが追加された龍ちゃんです。たまにブログの解析もさせるんですけど、この一番最初の挨拶はAI的には関西弁という認識になるんです。個人的にはそんな意図がなくて、ヒヤッとしているんです。このままAIに執筆させると、関西弁でのブログが作られてしまいそうで、まだまだ人間での執筆をやめられないなと思います。 基礎から学ぶ Azure Static Web Apps × Bicep 入門 今回は「Azure Static Web Apps を Bicep（Infrastructure as Code）で管理し、GitHub Actions を使った自動デプロイパイプラインを構築する」というテーマで3部構成の「環境構築編」となります。各回のコンテンツの内容としては以下になります。 シリーズのまとめ記事はこちら になります。 Azure Static Web Apps + Bicep環境構築編　←　 今回はここ ローカル開発でのBicep + SWA CLIデプロイ実践編 Bicep＋GitHub Actions連携デプロイ編 この回での目標は以下となります。 DevContainerによる開発環境の統一化 Azure CLI、GitHub CLI、SWA CLIが使える状態の構築 後続の作業に必要な認証設定の完了 azコマンドでStatic Web Appsのリソースの管理 それでは、環境の構築を始めましょう。 環境構築 作成する環境の整理 まずは構築する環境の整理から始めましょう。今回の環境は、これからのシリーズで必要となるものを一挙にセットアップできるように以下のものを環境内で実行できるようにしておきます。 Azure CLI：Azureのリソース管理に利用する GitHub CLI：GitHubの操作をコマンドラインで行う Azure Static Web Apps CLI（以降：SWA CLI）：Azure Static Web Appsのローカル開発を支援する 今回、作成するディレクトリ構成になります。 . ├── .devcontainer/ │ └── devcontainer.json # Dev Container設定 ├── out/ # デプロイ用静的ファイル │ └── index.html ├── swa-cli.config.json # SWA CLI Config ファイル └── README.md # コマンドを覚えるのは大変なのでメモ推奨 今回は環境構築のみなので、動作確認はコマンドで実行して確認をしたいと思います。 DevContainerで構築する利用としては、複数人で開発を前提とする場合に環境差異の確認を都度するのを回避するためです。Azure CLIに関しては、開発体験の向上のためにホスト側の認証情報をマウントして、DevContianerで都度認証を回避するようにします。GitHub CLIに関しては、使用頻度があまり高くないので、都度認証を行うようにします。 DevContainer > devcontianer.json ベースのイメージとしては、 Microsoft公式が出しているDevContianer用のNode イメージを使用しています。 { "name": "Azure Bicep Development", "image": "mcr.microsoft.com/devcontainers/javascript-node:1-20-bullseye", "features": { "ghcr.io/devcontainers/features/azure-cli:1": {}, "ghcr.io/devcontainers/features/github-cli:1": {} }, "postCreateCommand": "npm install -g @azure/static-web-apps-cli", "customizations": { "vscode": { "extensions": [ "ms-azuretools.vscode-bicep", "GitHub.vscode-github-actions", "ms-vscode.azure-account" ] } }, "forwardPorts": [ 4280 ], "mounts": [ "source=${localEnv:HOME}/.azure,target=/home/node/.azure,type=bind,consistency=cached" ] } featuresとしてAzure CLIとGitHub CLIをインストールして、立ち上げ後にグローバルインストールでSWA CLIをインストールしています。 また、マウントとしてホストにある /.azure ファイルをマウントしています。こちらは、ホストでAzure CLIのログインを実行していれば、コンテナ内で認証済みとして使用することができます。 out > index.html 検証用の静的ファイルを生成しましょう。将来的には、ReactやVueで作成したビルドファイルを指定するべきですが、今回は検証目的のため単純なHTMLファイルを生成して配置しておきます。 <!DOCTYPE html> <html lang="ja"> <head> <meta charset="UTF-8" /> <meta name="viewport" content="width=device-width, initial-scale=1.0" /> <title>Bicepでデプロイをしてみる</title> </head> <body> これが見れたら成功です！更新してみる <p id="time"></p> <script> // 現在の時間を取得 const now = new Date(); // 時間をフォーマット const formattedTime = now.toLocaleTimeString("ja-JP", { hour: "2-digit", minute: "2-digit", second: "2-digit", }); // HTMLに表示 document.getElementById( "time" ).textContent = `現在の時間: ${formattedTime}`; </script> </body> </html> コンテナ内動作確認 まずはそれぞれのCLIがインストール済みかを確認します。 az --version gh --version swa --version それぞれバージョン情報が表示されれば確認としては完了です。Azure CLIとGitHub CLIはそれぞれ認証が必要になります。認証をしていない場合は、コマンド自体が失敗する可能性があります。 az login gh auth login SWA CLIに関しては、認証の必要はありません。ですが、エミュレーターを起動するための設定ファイルを生成しておくと、SWA CLIを使用したデプロイやエミュレーターの起動が簡易になります。 # swa-cli.config.jsonを対話的に生成する swa init 対話的に実行すると swa-cli.config.json が生成されます。こちらは、エミュレート時やデプロイ時に使用することができます。便利なので、作成しておきましょう。 { "$schema": "https://aka.ms/azure/static-web-apps-cli/schema", "configurations": { "frontend-swr": { "appLocation": "out", "outputLocation": "." } } } エミュレーターは以下のコマンドで実行することができます。 swa-cli.config.json を検索してファイルがある場合は、記述の設定で処理を行ってくれます。 # swa-cli.config.jsonをベースにエミュレーターが起動する swa start # http://localhost:4280/ にアクセス確認 すべてのコマンドが問題なく実行できれば、環境構築完了となります。 Azure CLI＋SWA CLIでStatic Web Appsを作成～デプロイ～削除まで bicepでのリソース作成を行う前に、Azure CLIを用いてコマンドベースでAzure Static Web Appsを作成から削除まで検証していきます。事前準備として、リソースグループは手動で作成しておいてください。コマンドで一気に作成することも可能ですが、今回はStatic Web Appsのみに焦点を当てています。 Static Web Appsが作成可能なロケーション情報の取得 # SWAを作成することができるロケーションを取得 az provider show --namespace Microsoft.Web --query "resourceTypes[?resourceType=='staticSites'].locations" このコマンドでは、Microsoft.WebプロバイダーからstaticSitesタイプのリソースが作成可能な全ロケーションを取得しています。ロケーションは様々指定することができますが、Static Web Appsを作成することができるロケーションは限定されています。 リソースを作成 # SWAを作成 az staticwebapp create --name $SWA_NAME --resource-group $RESOURCE_GROUP --location $location 指定したリソースグループ内にSWAを作成するコマンドです。 $SWA_NAME 、 $RESOURCE_GROUP 、 $location は設定したい値に変更してください。作成には数分かかる場合がありますが、完了すると自動的にHTTPS対応のURLが割り当てられます。コマンドの完了後に表示される defaultHostname にhttpsをつけるとページにアクセスることができます。 作成が完了するとサンプルページがデプロイされているので、以下のページが表示されれば無事作成が完了しています。 デプロイトークンを取得 az staticwebapp secrets list --name $SWA_NAME --resource-group $RESOURCE_GROUP --query "properties.apiKey" SWAへのデプロイには専用のトークンが必要になります。これはセキュリティ上重要な情報なので、適切に管理しましょう。このコマンドでSWAのデプロイメントトークンを取得できます。このトークンはCI/CDパイプラインや手動デプロイで使用する重要な認証情報です。取得したトークンは環境変数として設定しておくと便利ですね。 SWA CLIでデプロイトークンを用いてデプロイ swa deploy --app-location out --env production --deployment-token $DEPLOY_TOKEN --app-location out でビルド成果物が格納されているディレクトリを指定し、 -env production でデプロイ先の環境を指定します（staging環境も利用可能）。 -deployment-token には先ほど取得したデプロイメントトークンを使用します。 Next.jsやNuxt.jsなどのフレームワークを使っている場合、通常は npm run build 後の出力ディレクトリ（ out 、 dist 、 build など）を指定することになります。 リソースを削除 az staticwebapp delete --name $SWA_NAME --resource-group $RESOURCE_GROUP --yes 検証が終わったら、課金を避けるためにリソースを削除しましょう。（今回作成したリソースはフリー版です！）SWAはFreeプランでも利用できますが、カスタムドメインや認証機能を使う場合は課金が発生する可能性があります。 --yes フラグを付けることで、確認プロンプトをスキップして削除を実行します。本番環境では十分注意して使用してください。 おわりに お疲れ様でした！今回は「基礎から学ぶ Azure Static Web Apps × Bicep 入門」の第1回として、DevContainer を使った統一開発環境の構築を行いました。 DevContainer の力を借りることで、チーム全体で同じ開発環境を簡単に共有できるようになりましたね。Azure CLI、GitHub CLI、SWA CLI の3つのツールが使える状態になったので、これで次回以降の作業がスムーズに進められそうです。 特に Azure CLI での認証情報をマウントすることで、コンテナを再起動するたびに認証し直す手間を省けるのは、日々の開発体験の向上に大きく貢献してくれると思います。 コマンドラインからの Static Web Apps の作成・デプロイ・削除まで一通り体験できたので、Azure のリソース管理の流れも掴めたのではないでしょうか。特にデプロイトークンの取得と SWA CLI を使ったデプロイは、次回以降でも頻繁に使う重要な操作なので、しっかりと覚えておいてくださいね。 次のシリーズへの導入 さて、次回は「ローカル開発での Bicep + SWA CLI デプロイ実践編」となります！ 今回は Azure CLI を使ってコマンドベースでリソースを管理しましたが、次回からはいよいよ Infrastructure as Code の本領発揮です。Bicep を使ってコードでインフラを定義し、バージョン管理できるようにしていきます。 次回の内容としては以下を予定しています： Bicep ファイルの作成 : Static Web Apps のリソースを Bicep で定義 パラメータファイルの活用 : 環境ごとの設定を外部化 ローカルでの Bicep デプロイ : az deployment コマンドでのリソース作成 SWA CLI との連携 : Bicep で作成したリソースへのアプリケーションデプロイ リソースの更新と削除 : Bicep での変更管理 今回構築した DevContainer 環境があるおかげで、Bicep の拡張機能も既にインストール済みですし、Azure CLI での認証も完了しているので、次回はすぐに Bicep の実践に入れます。 それでは、次回もお楽しみに！引き続き一緒に Azure Static Web Apps と Bicep をマスターしていきましょう。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post DevContainer実践入門：Azure CLI+GitHub CLI環境をチーム全体で統一 first appeared on SIOS Tech. Lab .

今号では、cron でタスクを追加する際の tips、スクリプト形式のタスクの内容を、もう少し深堀りして説明します！ crontab 設定の tips 時間指定方法 範囲指定する – (ハイフン) を指定すると、 「7時から 9時まで」 のように、指定された範囲内のすべての値でジョブを実行することができます。 【例1】毎日 7時から 9時までの毎分実行： * 7-9 * * * 【例2】毎月 1日から 5日までの毎日 10時に実行： 0 10 1-5 * * 【例3】毎週月曜日から金曜日までの毎日 9時に実行： * 9 * * 1-5 複数の値を指定する , (カンマ) を指定すると、 「10時と 12時」 のように、複数の値を同時に指定することができます。 【例1】毎日 10時と 12時に実行： * 10,12 * * * 【例2】毎月 10日、20日、30日のみ 10時に実行： 0 10 10,20,30 * * 【例3】毎週月、水、金曜日の 9時30分に実行： 30 9 * * 1,3,5 間隔値を指定する / (スラッシュ) を指定すると、 「毎時 15分ごと」 のように、ジョブを実行する間隔を指定することができます。 【例1】15分ごとに実行： *\15 * * * * 【例2】毎日 9時から 17時までの間、30分ごとに実行： */30 9-17 * * * 【例3】3日ごとに、0時0分に実行： 0 0 */3 * * 特殊な文字列オプション 最初にご説明した 分、時、日、月、曜日の　5つのフィールド で実行タイミングを指定する方法以外にも、特定の頻度を文字列で指定できるオプションがあります。 @reboot ：システム起動時に 1度だけ実行 @yearly もしくは @annually ：年に 1度だけ実行 (1月1日 00:00、年が変わった瞬間) @monthly ：月に 1度だけ実行 (各月の 1日 00:00、月が変わった瞬間) @weekly ：週に 1度だけ実行 (毎週日曜日 00:00、週が変わった瞬間) @daily もしくは @midnight ：毎日 1度だけ実行 (毎日 00:00、日が変わった瞬間) @hourly ：毎時 1度だけ実行 (毎時 00 分、時間が変わった瞬間) 例えば、システム起動時にのみ setup.sh というスクリプトを実行したい場合、下記のように設定します。 @reboot /path/to/startup.sh /etc/crontab と crontab -e の違い システム全体の crontab ファイル ( /etc/crontab や /etc/cron.d 以下のファイル ) を編集する場合、 どのユーザが実行するかを明示する必要があります。 例えば、毎日 0時に daily.sh というスクリプトを実行するタスクを追加する場合、/etc/crontab と crontab -e では下記のように記載内容を変えます。 /etc/crontab の場合 0 0 * * * ykaino /path/to/daily.sh crontab -e の場合 0 0 * * * /path/to/daily.sh ※ ykaino ユーザによる crontab -e 実行を想定しています。 スクリプト形式の tips スクリプト形式のタスクは、基本的にはシェルスクリプトと同じ書き方で登録することができます。 基本的な構文、コマンド、if、for、while などの制御文、変数、関数 なども使用できます。 シェルスクリプトについての具体的な説明はここではしませんが、スクリプト形式のタスクを登録する際の注意点を記載します。 コマンドは絶対パスで crontab と同様、 スクリプト内で実行するコマンドは絶対パスで 記載することを推奨します。 カレントディレクトリに注意 cron がスクリプトを実行する際のカレントディレクトリは、通常は スクリプトを実行しているユーザのホームディレクトリ になります。 そのため、スクリプト内でファイルを操作する際などは注意が必要で、コマンドと同様に ファイルも絶対パスで 記載しておきましょう。 必要であれば実行結果をログに出力 cron のタスク内で呼び出されたスクリプトやコマンドで何らかの問題が発生した場合、cron の実行結果として成功・失敗は確認できるものの、具体的にどの処理で失敗したのかが分からない場合があります。 この対策として、下記のように実行結果を明示的にログ出力させるようにしておくと安心です。 #!/bin/bash LOGFILE="/var/log/my_app/daily_job.log" # 成功メッセージをログ result() { echo "$(date '+%Y-%m-%d %H:%M:%S') $*" >> "$LOGFILE" } ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 知っておくとちょっと便利！cron によるタスク管理2 first appeared on SIOS Tech. Lab .

こんにちは！ 今月も「OSSのサポートエンジニアが気になった！OSSの最新ニュース」をお届けします。 Apple は、MacOS 上で仮想マシンを使って Linux コンテナを作成・実行するためのツール「container」を、オープンソースとして公開しました。 Apple⁠⁠、macOS上でLinuxコンテナを直接実行できる「container」をオープンソースとして公開 https://gihyo.jp/article/2025/06/apple-container アメリカの大手保険会社 Aflac は、国内ネットワーク上で不審なアクセスを検知したと発表しました。 米 アフラック、サイバー攻撃で個人情報漏洩の可能性 https://rocket-boys.co.jp/security-measures-lab/aflac-us-announces-possible-data-breach-after-cyberattack/ 2025/6/20、Microsoft は「Windows Subsystem for Linux」v2.6.0 をプレリリース版として公開しました。オープンソースとしては初のリリースです。 「Windows Subsystem for Linux」に初のオープンソースリリース／「WSL 2.6.0」がプレリリース版として公開 https://www.msn.com/ja-jp/news/techandscience/windows-subsystem-for-linux-%E3%81%AB%E5%88%9D%E3%81%AE%E3%82%AA%E3%83%BC%E3%83%97%E3%83%B3%E3%82%BD%E3%83%BC%E3%82%B9%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9-wsl-260-%E3%81%8C%E3%83%97%E3%83%AC%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E7%89%88%E3%81%A8%E3%81%97%E3%81%A6%E5%85%AC%E9%96%8B/ar-AA1HddiV ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 【2025年6月】OSSサポートエンジニアが気になった！OSS最新ニュース first appeared on SIOS Tech. Lab .

OSS よろずチームの神﨑です。 RHEL 10 同梱版の httpd の変更点についてドキュメントと疎通確認したのでまとめていきたいと思います。 まずは、ドキュメントからです。 httpd に関する変更点 RHEL 公式ドキュメントを確認したところ以下の記述がありました。 RHEL 10.0 同梱版 httpd は Apache HTTP Server 2.4.62 デフォルトでロードされるモジュールの変更 mod_authnz_fcgi がデフォルトで有効化されるようになりました。 セキュリティの強化 httpd.service ユニットファイルのデフォルト設定でセキュリティが強化されるようになりました。 OpenSSL の ENGINE サポート削除 SSLCryptoDevice 設定ディレクティブは使用不可になりました。 Berkeley DB データベースのサポート削除 RHEL 9 以降、Berkeley DB はサポートされなくなりました。 mod_authz_dbm などのモジュールは、デフォルトで LMDB データベースタイプを使用します。SDBM データベースタイプも利用可能です。 RHEL 10 の導入における検討事項 – 第14章インフラストラクチャサービス より 以下で httpd.service と OpenSSL についてもう少し補足していきます。 httpd.service で追加された設定 RHEL 9.6 同梱版 httpd の httpd.service ファイルと比較したところ以下が追加されていました。 /usr/lib/systemd/system/httpd.service　より (追加は ハイライト部分 ) [Unit] Description=The Apache HTTP Server Wants=httpd-init.service After=network.target remote-fs.target nss-lookup.target httpd-init.service Documentation=man:httpd.service(8) [Service] Type=notify Environment=LANG=C ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND ExecReload=/usr/sbin/httpd $OPTIONS -k graceful # Send SIGWINCH for graceful stop KillSignal=SIGWINCH #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ # [Service] # Environment=OPTIONS=-DMY_DEFINE [Unit] Description=The Apache HTTP Server Wants=httpd-init.service After=network.target remote-fs.target nss-lookup.target httpd-init.service Documentation=man:httpd.service(8) [Service] Type=notify Environment=LANG=C ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND ExecReload=/usr/sbin/httpd $OPTIONS -k graceful # Send SIGWINCH for graceful stop KillSignal=SIGWINCH KillMode=mixed DevicePolicy=closed KeyringMode=private LockPersonality=yes MemoryDenyWriteExecute=yes OOMPolicy=continue PrivateDevices=yes PrivateTmp=true ProtectClock=yes ProtectControlGroups=yes ProtectHome=read-only ProtectHostname=yes ProtectKernelLogs=yes ProtectKernelModules=yes ProtectKernelTunables=yes ProtectSystem=yes RestrictNamespaces=yes RestrictRealtime=yes RestrictSUIDSGID=yes SystemCallArchitectures=native 追加されたパラメータ(波線以下)の概要は以下の通りです。 先ほど述べた通りセキュリティ強化に関するパラメータが追加されていますね。 DevicePolicy=closed プロセスが /dev 以下のデバイスノードにアクセスするのを制限します。 closed に設定すると、デフォルトではどのデバイスにもアクセスできません。 KeyringMode=private サービスプロセスが自身のプライベートなカーネルキーリングを持つようにします。 LockPersonality=yes personality システムコールを介してプロセスの実行モードを変更することを禁止します。 MemoryDenyWriteExecute=yes プロセスが書き込み可能かつ実行可能 (W+X) なメモリ領域を作成することを禁止します。 PrivateDevices=yes サービスに独自の /dev ツリーを提供し、システム全体の /dev ツリーへのアクセスを制限します。 ProtectClock=yes サービスプロセスがシステムクロックの設定を変更することを禁止します。 ProtectControlGroups=yes サービスプロセスがコントロールグループ (cgroups) のファイルシステムにアクセスすることを禁止します。 ProtectHome=read-only サービスプロセスからユーザーのホームディレクトリ ( /home/ 、 /root/ など) を読み取り専用でマウントします。 ProtectHostname=yes サービスプロセスがシステムのホスト名を変更することを禁止します。 ProtectKernelLogs=yes サービスプロセスがカーネルログ（ dmesg などがアクセスする情報）にアクセスしたり、変更したりすることを禁止します。 ProtectKernelModules=yes サービスプロセスがカーネルモジュールをロードしたりアンロードしたりするのを禁止します。 ProtectKernelTunables=yes サービスプロセスがカーネルのsysctlパラメータ ( /proc/sys 以下の設定) を変更することを禁止します。 ProtectSystem=yes /usr , /boot , /etc などのシステムディレクトリを読み取り専用でマウントします。これにより、サービスがこれらの重要なシステムファイルを変更したり、新たなファイルを書き込んだりするのを防ぎます。 RestrictNamespaces=yes サービスプロセスが新しい名前空間を作成したり、既存の名前空間に参加したりするのを制限します。 RestrictRealtime=yes サービスプロセスがリアルタイムスケジューリングポリシー ( SCHED_FIFO , SCHED_RR ) を使用することを禁止します。 RestrictSUIDSGID=yes サービスプロセスが setuid または setgid フラグを持つファイルを実行することを禁止します。 SystemCallArchitectures=native サービスプロセスが、ネイティブアーキテクチャのシステムコールのみを使用できるように制限します。 詳細は man 5 systemd.exec よりご確認ください。 httpd に関連する OpenSSL の変更 OpenSSL 3.0 の導入により、従来の Engine が Provider へと置き換えられた結果、 openssl-pkcs11 エンジンが削除され、代わりに pkcs11-provider が提供されています。 参考 以下の公式ドキュメントを参考にしました。 RHEL 10 の導入における検討事項 10.0 リリースノート ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post RHEL 10 同梱版の httpd 変更点まとめ 1 ~ドキュメント編 first appeared on SIOS Tech. Lab .

はじめに 　2025年6月16日から二日間開催されたKubeCon + CloudNativeCon Japan( https://events.linuxfoundation.org/kubecon-cloudnativecon-japan/ )に参加しました。 第一回目のせいなのか、ところどころである休憩時間では通路を埋めるほど人が集まり、非常に盛況なイベントでした。 　場所は、お台場にある、ヒルトン東京お台場と呼ばれる場所で行っており、その1Fを使用してスポンサーブースや技術セッションを聞いたりしました。実際のセッション内容は後日公開されたり、セッションで使用した資料は公式サイトに公開してあるものもあります。 ゆりかもめの台場駅から歩いてすぐに会場がある。   　基本的に、発表内容は英語のセッションですが各セッションルームにQRコードがかかれた看板があり、そのQRコードのリンクからセッション内容がチャットのように流れていたため英語が理解できなくて内容自体はすぐに確認可能など技術の進歩に驚きます。 参加者の証明であるバッチを受け取り、自分自身へ話しかけていいかどのように話しかけるかのシール セッションの翻訳内容を聞くためのリンクが書かれたQR 翻訳アプリの内容について 一日目について 　参加者はまず、受付でバッチと呼ばれる作業あるため受付でかなり長い行列ができていました。そのためキーノートセッション開始前に来ると受付のためキーノートの会場入りに間に合わない人も数人いたことや、開始の10分前にはメイン会場が入れなくなるので、余裕をもって受付に参加したほうが参加しやすいです。 一日目でバッチ受け取りの受付は8時から実施したが、Tシャツの配布は混雑解消のためキーノートが終了する10:45から配布するなど時間をずらしていた   　一日目は、Prometheus 3.0のセッションや2-node Kubernetesのセッションを聞いてきました。 　Prometheus 3.0のセッションでは、Prometheusのこれからについて、OpenTelemetryとの強化について触れており、OpentElemetryについてより重要だと認識しました。   　2-node Kubernetesセッションでは、複数のノードを使用して司令塔であるコントロールプレーンを作成する内容であり、通常では3ノードを使用して作成する所を2ノードで作成する内容でした。 おもな特徴として、2ノードで作成できるのですが、etcdと呼ばれるデータストアの保全性を維持するため、sambaやnfsの共有ディスクを使用してデータの正当性を維持しております。用意するハードの数が減るため管理するPCが減る利点もあるため、その技術には将来性があると考えます。   二日目について 　一日目が大盛況なこともあり、Tシャツの配布ブースでは男性用のTシャツのサイズが二種類しか存在しないことがありました。また、入場者数は一日目と大きな違いがなく二日目も大盛況であり、お昼に提供する一般の弁当がなくなったり、休憩で提供させている部屋を埋めつくすこともありました。 二日目のセッションでは、Green OpenTelemetryやThe Future of Prometheus Exposition Format、From Moon Prism Power To eBPF Super Saiyanというセッションを聞いてきました。   Green OpenTelemetryでは、環境問題をテーマにOpenTelemetryを使用して消費電力の最適化を行うために、Kubernetes based Efficient Power Level Exporter(通称Kepler)を使用して、eBPFから取得できるCPU使用率からエネルギー消費量に変化させて少ないエネルギーで運用し環境問題改善に貢献しようという話でした。 The Future of Prometheus Exposition FormatではOpenMetricsと呼ばれるメトリックログを出力する際の標準化フォーマットの歴史やこれからへのOpenMetrics 2.0へむけて向けての改善を話す内容で、ここでもOpentelemetryというキーワードが出ており可観測の注目が非常に高いと感じました。 スポンサーブースについて   スポンサーブースでは、Google Cloudのブースで2025年の1月にオープンソースで公開されたソフトのKubernetes History Inspectorと呼ばれるソフトが展示されており、Kubernetesの監査ログから過去の変更点が視覚的に追いながら調査できることが便利だと感じました。 また、ZOZOさんのブースでは、特定のサーバへの複数アクセスのテストでKubernetes上で立てたPodからアクセスするようなソフトのでも実施しており、この点もKubernetesの利点だとも再認識しました。 さらに、CNCFプロジェクトのステッカー配布ブースがあることが少し感動しました。 まとめ 　日本でやる第一回のKubeConであったため非常に大盛況のイベントありました。基本的に英語のセッションでしたが、翻訳アプリのおかげで内容の理解に問題を感じないため言語の壁は技術の進化によって減ってきたと感じました。 　本イベントでますますOpentelemetoryなどのAI学習に与えるデータを作ることも重要性も感じるようなイベントだと考える機会でした ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post KubeCon + CloudNativeCon Japan 2025 参加レポート first appeared on SIOS Tech. Lab .

初めに ども！最近は人間とチャットするよりもAIとチャットすることが増えている龍ちゃんです。AIサービスの使い方が多岐にわたってきて、そのトピックだけでブログが執筆できそうなくらいです。 今回はAIとあまり関係ない、認証のお話です。内容としては「Azure Static Web Appsで組み込み認証とユーザー情報の取り扱い」となります。認証プロバイダーとしてGoogleを使用しています。 構築がしたことがない方は、「 GoogleによるSSOを持つAzure Static Web Appsのアプリを作成する 」の記事を参考に構築して試してみてください。 前提技術 Azure Static Web Apps（以降 SWA）をStandardプランで運用して、カスタム認証としてGoogleを設定していることが前提となります。カスタム認証はStandardプランから使用することができ、Freeプランで今回と同様の検証することができません。また、カスタム認証を有効化すると、他の認証プロバイダーが提供する組み込みプロバイダー（ /.auth/login/github …など）が利用できなくなります。 SWA CLIを使用すれば、認証フローをローカルでエミュレートすることができます。 Next.js＋DevContainer環境でSWA CLIをセットアップしているブログがありますので、こちらを参考に構築するのをお勧めします 。 バックエンドは、 将来的にSWAとAPI連携を活用して接続をする予定 になります。Azure FunctionsやAzure App Serviceにデプロイされるのが想定されます。ローカルでの検証もできるので、任意の環境で大丈夫です。 私の検証環境では、nest.jsを使用して構築しています。コードとしては、TypeScriptになりますが概念としては他の言語でも通じることですので参考にしてみてください。 今回検証する内容としては以下になります。 staticwebapp.config.json のロールベースルーティング： 参考リンク API連携をした際に x-ms-client-principal を介してユーザー情報を渡す： 参考リンク staticwebapp.config.json を用いてロールベースのルーティングを定義する こちらはプレビューの機能となります。本番環境で利用する場合は、検討して採用を決めてください。 staticwebapp.config.jsonの設定を追加することで、認証時にロールの判定ルートを追加することができます。制限事項として、SWA CLIではロール判定のルートを含めてエミュレートするため、実際の動きはAzure上にデプロイしてからのみ確認することができます。 認証からロール判定の流れは以下の流れになります。 設定項目としては、 auth > rolesSource になります。こちらで設定したエンドポイントに認証後にPOSTリクエストが送られます。今回は /api/assingRoles と設定しています。 //staticwebapp.config.json { "auth": { "rolesSource": "/api/assignRoles", "identityProviders": { "google": { "registration": { "clientIdSettingName": "GOOGLE_CLIENT_ID", "clientSecretSettingName": "GOOGLE_PROVIDER_AUTHENTICATION_SECRET" } } } }, "routes": [ { "route": "/admin/", "allowedRoles": ["admin"] }, { "route": "/", "allowedRoles": ["authenticated"] } ], "responseOverrides": { "404": { "rewrite": "/404/index.html", "statusCode": 404 }, "401": { "statusCode": 302, "redirect": "/.auth/login/google" } } } POSTリクエスト付帯されるボディ情報としては以下になります。こちらは、Azure EntraIDを設定した場合のサンプルになります。こちらの情報をもとに、ロールの判定を返答することで、ユーザーにカスタムロールをAPI経由で設定することができます。 // 仮のJSON { "identityProvider": "aad", "userId": "00aa00aa-bb11-cc22-dd33-44ee44ee44ee", "userDetails": "ellen@contoso.com", "claims": [ { "typ": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress", "val": "ellen@contoso.com" }, { "typ": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname", "val": "Contoso" }, { "typ": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname", "val": "Ellen" }, { "typ": "name", "val": "Ellen Contoso" }, { "typ": "http://schemas.microsoft.com/identity/claims/objectidentifier", "val": "7da753ff-1c8e-4b5e-affe-d89e5a57fe2f" }, { "typ": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", "val": "00aa00aa-bb11-cc22-dd33-44ee44ee44ee" }, { "typ": "http://schemas.microsoft.com/identity/claims/tenantid", "val": "3856f5f5-4bae-464a-9044-b72dc2dcde26" }, { "typ": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name", "val": "ellen@contoso.com" }, { "typ": "ver", "val": "1.0" } ] } それでは、nest.jsで設定方法について見ていきます。エンドポイントから返す値としては、以下のフォーマットに合わせる必要があります。 { roles: string[] } ロール判定の結果、空配列を返答した場合でもSWA側で anonymous ・ authenticated が自動で割り振られます。 import { Body, Controller, Get, Post } from '@nestjs/common'; import { AppService } from './app.service'; @Controller() export class AppController { constructor(private readonly appService: AppService) {} // https://learn.microsoft.com/ja-jp/azure/static-web-apps/authentication-custom?tabs=google%2Cfunction @Post('/api/assignRoles') async postHello(@Body() req: { userId: string; userDetails: string }): Promise<{ roles: string[] }> { // proiderがgoogleの場合はuserDetailsはメールアドレス情報になっている // 不安な場合は/.auth/meのエンドポイントを確認 // 受け取った情報をもとにrolesを割り当てて返信する // 何もrolesがない場合はから配列を返答する // 検証のためメールアドレスによる判定を行う const roles = await this.appService.assignRoles(req.userDetails); return { roles: roles }; } } 動作確認としては、SWA側で /.auth/me にアクセスすることで確認することができます。ローカルでは、ロール判定も含めてエミュレートするため、エミュレート認証情報が表示されています。 こちらの画像上 Users roles に文字列で設定することで再現することができます。 ロールの設定が完了すれば、 staticwebapp.config.json で allowedRoles で設定することで特定のロールのみが見れるページを制御することが可能になります。 バックエンドでの認証ユーザーの情報にどのようにアクセスするのか？ 先ほどのロールベースでの確認で /.auth/me というエンドポイントを使用しました。フロントエンドからGETリクエストを投げることで、認証情報を取得することができます。 技術としてはフロントから自分のIDを取得・指定してAPIアクセスができます。これは、ユーザIDを改ざんしてAPIアクセスすることができてしまうため非推奨です。 SWAからAPI連携しているバックへの認証情報の受け渡しは、ヘッダーに自動挿入されている x-ms-client-principal を活用して行います 。こちらは、Base64でエンコードされた情報として贈られるためでコードをすることで、バックエンドで認証情報を取得することができます。デコードされて受け取ることができる値は以下になります。 type clientPrincipal = { userId: string; // ユーザーID userRoles: string[]; // ユーザーロール identityProvider: string; // 認証プロバイダー userDetails: string; // ユーザー情報 Googleが認証プロバイダーの場合はメールアドレス }; それでは、実装に入っていきます。実装としてはnest.jsのGuardを使用してデコードとリクエストに積み替えを行い、contorllerでは情報を使うだけという実装にしていきます。 まずはGuardを実装します。デコードの方法としては、 公式のサンプル を参考に実装しています。処理としては、以下になります。 ヘッダーから x-ms-client-principal の取得・確認 デコード リクエストに詰め替え import { CanActivate, ExecutionContext, Injectable, UnauthorizedException } from '@nestjs/common'; import { Observable } from 'rxjs'; import as base64 from 'base-64'; import as utf8 from 'utf8'; type clientPrincipal = { userId: string; userRoles: string[]; identityProvider: string; userDetails: string; }; // このガードは、Azure Static Web Apps (SWA) の認証ヘッダーを検証するために使用されます。 // SWAは、認証されたユーザーの情報を 'x-ms-client-principal' ヘッダーに含めて送信します。 // このガードは、ヘッダーが存在し、正しい形式であることを確認し、 // ユーザー情報をリクエストオブジェクトに追加します。 // 認証されていない場合は、UnauthorizedExceptionをスローします。 // 参考: https://learn.microsoft.com/ja-jp/azure/static-web-apps/user-information?tabs=javascript @Injectable() export class AuthGuardToSwaGuard implements CanActivate { canActivate(context: ExecutionContext): boolean | Promise<boolean> | Observable<boolean> { const request = context.switchToHttp().getRequest(); const clientPrincipalEncoded = request.headers['x-ms-client-principal'] as string; if (!clientPrincipalEncoded) { // 認証情報ヘッダーがない場合、認証されていないとしてスロー throw new UnauthorizedException('X-MS-CLIENT-PRINCIPAL header not found. User is not authenticated.'); } try { // Base64 デコードと UTF-8 デコード const decoded = utf8.decode(base64.decode(clientPrincipalEncoded)); console.log(JSON.parse(decoded)); const clientPrincipal: clientPrincipal = JSON.parse(decoded); request.user = clientPrincipal.userId; request.userRoles = clientPrincipal.userRoles; return true; // 認証成功 } catch (error) { console.error('Failed to decode or parse x-ms-client-principal:', error); // デコードやパースに失敗した場合、不正なヘッダーとしてスロー throw new UnauthorizedException('Invalid X-MS-CLIENT-PRINCIPAL header format.'); } } } Controller実装です。Guardを挿入するとリクエストに積み替えられて取得することができます。 import { Body, Controller, Get, Post, Req, UseGuards } from '@nestjs/common'; import { AppService } from './app.service'; import { AuthGuardToSwaGuard } from './common/guard/auth-guard-to-swa/auth-guard-to-swa.guard'; @Controller() export class AppController { constructor(private readonly appService: AppService) {} // SWAの認証情報が必要 @UseGuards(AuthGuardToSwaGuard) @Get('/api/hello') async getHello(@Req() req): Promise<string> { console.log('getHello called with user:', req.user); console.log('getHello called with userRoles:', req.userRoles); return "hello"; } } 確認のため、コンソールに出力しています。あとは、ユーザIDやロールなどの情報をもとに制御することができます。 コラム: staticwebapp.config.json vs. バックエンドAPIでのアクセス制限 SWAでは認証・認可のアプローチとして2つの方法があることがわかりました。設定ファイルでの制御とバックエンドAPIでの制御、これらはどう違うのでしょうか？実際のプロジェクトでどちらを選ぶべきか、迷うところですよね。 実は、この2つのアプローチはそれぞれ異なるタイミングで動作し、得意分野も違います。以下のシーケンス図で、両者の動作の違いを見てみましょう。 比較表：どちらを選ぶべきか？ 制御の場所 Azure Static Web Apps (SWA) エッジノード / フロントエンド バックエンドAPIアプリケーション内 処理のタイミング APIへのリクエストがSWAに到達した直後（API実行前） APIがリクエストを受け取り、処理を開始した後 実装方法 設定ファイル (staticwebapp.config.json) の記述 プログラミング言語（TypeScript/NestJS）、ガード、デコレーター、ミドルウェア、ロジックコード 制御の粒度 粗い（URLパスベースの許可/拒否） 細かい（特定のエンドポイント、メソッド、データのフィールド、ビジネスロジック） 主なユースケース – エンドポイント全体へのアクセス制限 – 特定のAPIグループへのアクセス制限 – 不要なバックエンドAPI呼び出しの防止 – データレベルのアクセス制御（例：自分のデータのみ表示） – 情報のマスキング/匿名化 – 特定のアクションの制限（例：更新/削除） – 動的な条件に基づくアクセス制御 – より複雑なビジネスルールに基づく認可 パフォーマンス 高速（APIが呼び出されないため） わずかなオーバーヘッド（APIが呼び出され、処理が実行されるため） 設定の柔軟性 静的（デプロイが必要） 動的（コード変更とデプロイが必要だが、データベースなどと連携すれば実行時にも柔軟な制御が可能） 開発の容易性 シンプル（設定ファイルの記述のみ） 複雑（コードの記述、フレームワークの学習、設計が必要） エラーハンドリング SWAが自動的に401/403を返す カスタムエラーレスポンス（例：NestJSのForbiddenException）を細かく制御可能 推奨される利用 最初の防衛線として、大まかなアクセス制御 詳細なビジネスロジックに基づいた認可、データ処理、複雑なロール要件 使い分けの提案 それぞれの特徴を理解した上で、実際の開発ではどのように使い分けるべきでしょうか？ staticwebapp.config.json を使うべき場面 「最初の防衛線」として、粗い粒度（URLパス全体）でのアクセス制限に最適です。バックエンドへの不要なリクエストを防ぐことで、パフォーマンスの向上とセキュリティの強化を同時に実現できます。 管理者専用ページへのアクセス制限 認証済みユーザーのみがアクセス可能なエリアの制御 特定のAPIエンドポイントグループへの一律制限 バックエンドAPIを使うべき場面 「より詳細な制御」が必要な場合に必須となります。データレベル、アクションレベル、または複雑なビジネスロジックに基づいた認可を実現したい場合は、こちらを選択しましょう。情報マスキングやフィルタリングもここで実現できます。 特に、 アクセスするユーザーによってデータが変動する ケースでは、APIベースでの認証が重要になります。 具体例： ブログ記事の閲覧制限 : 一般ユーザーは公開記事のみ、プレミアムユーザーは全記事を閲覧可能にする場合 投稿コンテンツの編集権限 : 投稿されたコメントの編集・削除権限を、投稿者本人と管理者のみに制限する場合 ダウンロード容量制限 : ダウンロード可能なファイルの容量制限を、無料ユーザーは100MB、有料ユーザーは1GBまでとする場合 両方を組み合わせるアプローチ 最も堅牢で柔軟なシステムを構築するには、 両方を組み合わせる ことをお勧めします。 staticwebapp.config.json で大まかなアクセス制御を行い、不要なAPI呼び出しをブロック バックエンドAPIで詳細なビジネスロジックに基づいた認可処理を実装 この多層防御のアプローチにより、パフォーマンスとセキュリティの両方を最適化できます。 まとめ 今回は、Azure Static Web Appsにおける認証とユーザー制御について、フロントエンドとバックエンドの両方のアプローチを詳しく見てきました。特に、x-ms-client-principalを活用した安全なユーザー特定と、きめ細かなロールベース制御の実装方法について解説しました。この知識を活かして、より堅牢なWebアプリケーションの開発に取り組んでいただければ幸いです。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Azure Static Web Apps: x-ms-client-principalで安全なロールベース制御 first appeared on SIOS Tech. Lab .

はじめに こんにちは、サイオステクノロジーの安藤 浩です。 前回の記事では、Ethereum Sepoliaテストネット上のフルノードを構築し、イベントログからERC-721やERC-1155の所有者を特定する方法をご紹介しました。 前回の記事は以下です。 [web3] Ethereum の Sepolia上のイベントログから ERC-721, ERC-1155 の所有者の見つけ方 今回はその続編として、WebSocketを活用したリアルタイムでの所有者の移転が行われた際の監視の方法をお伝えします。 WebSocketを使ったイベント監視の仕組み Ethereumのフルノードは通常HTTPSによるRPC通信を提供していますが、リアルタイム監視にはWebSocketが適しています。WebSocketを使うことで、新しいイベントが発生した時点で即座に通知を受け取ることができます。 前提条件 Sepoliaテストネット上のフルノードがすでに構築されていること 上記に記載の前回の記事でフルノードを構築してください。 [web3] Ethereum の テストネット: Sepolia上での フルノード構築 設定手順 1. Gethの起動設定を変更する まず、GethでWebSocketを有効にするために、起動コマンドに以下のオプションを追加します。 --ws --ws.api eth,net,web3 実際のコマンド例は以下のようになります： gethlocal --sepolia --ws --ws.api eth,net,web3 --http --http.api eth,net,engine,admin --authrpc.jwtsecret 【jwt.hexファイルのパス】 --datadir 【データディレクトリのパス】--syncmode snap 2. WebSocketでイベントをサブスクライブするコード src/sub.ts というファイルを以下の内容で作成します。 import WebSocket from 'ws'; // Geth ノードの WebSocket エンドポイント const wsUrl = 'ws://localhost:8546'; // WebSocket クライアントを作成 const ws = new WebSocket(wsUrl); ws.on('open', () => { console.log('WebSocket connection established.'); const contractAddressList = [ '0xE88Df35e01e3e33Df38FB0B5e324282feCeb20c2', //ERC-721 '0x412E008d6157568F8c621FbF899e7717F0442a94' //ERC-1155 ]; contractAddressList.forEach((contractAddress) => { // eth_subscribe を使用してトランザクションログを監視 const subscriptionRequest = { jsonrpc: '2.0', id: 1, method: 'eth_subscribe', params: ['logs', { address: contractAddress, // 特定のコントラクトアドレスを指定 topics: [] // トピックフィルタを指定（空配列はすべてのイベントを受信） } ] }; ws.send(JSON.stringify(subscriptionRequest)); }); }); ws.on('message', (data: any) => { const response = JSON.parse(data.toString()); if (response.method === 'eth_subscription') { console.log('New log:', response.params.result); } else { console.log('Response:', response); } }); ws.on('error', (error: any) => { console.error('WebSocket error:', error); }); ws.on('close', () => { console.log('WebSocket connection closed.'); }); 実行すると、WebSocketの接続が確立され、以下のようなレスポンスが表示されます： [nodemon] starting `ts-node src/sub.ts` WebSocket connection established. Response: { jsonrpc: '2.0', id: 1, result: '0x8debf94ebabaea3a86f403b2e2791a19' } リアルタイム監視の実例 ここでは、実際にNFT関連のトランザクションが発生した際に受信したイベントログをいくつか紹介します。 1. OwnershipTransferredイベント New log: { address: '0x412e008d6157568f8c621fbf899e7717f0442a94', topics: [ '0x8be0079c531659141344cd1fd0a4f28419497f9722a3daafe3b4186f6b6457e0', '0x00000000000000000000000036da942099c028275321130b5e503f37da446487', '0x000000000000000000000000cebc36de334ce12dfd08f4c39e833016263ba5b0' ], data: '0x', blockNumber: '0x7a2cce', transactionHash: '0xa8edf869ba4fd375f2fdfc51e557d7a3237299f2583242bb43d839f5930fcf78', transactionIndex: '0x1e', blockHash: '0x57e194d69b6dd85dc431228189c8bf551d0e91a74ed14c6eecfba581c580c73c', logIndex: '0x1a', removed: false } このイベントは、コントラクトのオーナーシップ移転を示しています。Etherscanでは こちら で確認できます。 2. TransferSingleイベント New log: { address: '0x412e008d6157568f8c621fbf899e7717f0442a94', topics: [ '0xc3d58168c5ae7397731d063d5bbf3d657854427343f4c083240f7aacaa2d0f62', '0x00000000000000000000000036da942099c028275321130b5e503f37da446487', '0x00000000000000000000000036da942099c028275321130b5e503f37da446487', '0x000000000000000000000000cebc36de334ce12dfd08f4c39e833016263ba5b0' ], data: '0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001', blockNumber: '0x7a2d00', transactionHash: '0xa9f80aced3eb829117ef1cdfaba629a6ae625af9e44febe91bfed5b3dfec3565', transactionIndex: '0x43', blockHash: '0x3823f72b6cf3590915be2b19bc2bff5acbf4f35a772c91e69b3dc4d5804bc7e2', logIndex: '0x43', removed: false } このログはERC-1155のTransferSingleイベントで、単一のトークン移転を記録しています。トランザクションは こちら で確認できます。 New log: { address: '0x412e008d6157568f8c621fbf899e7717f0442a94', topics: [ '0xc3d58168c5ae7397731d063d5bbf3d657854427343f4c083240f7aacaa2d0f62', '0x00000000000000000000000036da942099c028275321130b5e503f37da446487', '0x00000000000000000000000036da942099c028275321130b5e503f37da446487', '0x000000000000000000000000cebc36de334ce12dfd08f4c39e833016263ba5b0' ], data: '0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001', blockNumber: '0x7a2d0c', transactionHash: '0xb20b71a0e8b8d47ee30fa20c0afc74f82d83aa508492d6128a4dbf7258e91960', transactionIndex: '0x37', blockHash: '0x4a83395b33fd6dd60302d8d340fd4afb114b4b1208cc94b5246ff39162e0173e', logIndex: '0x64', removed: false } 3. TransferBatchイベント New log: { address: '0x412e008d6157568f8c621fbf899e7717f0442a94', topics: [ '0x4a39dc06d4c0dbc64b70af90fd698a233a518aa5d07e595d983b8c0526c8f7fb', '0x00000000000000000000000036da942099c028275321130b5e503f37da446487', '0x00000000000000000000000036da942099c028275321130b5e503f37da446487', '0x000000000000000000000000cebc36de334ce12dfd08f4c39e833016263ba5b0' ], data: '0x000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000a0000000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000002', blockNumber: '0x7a2d5e', transactionHash: '0xd35a028d7c9a9d98d7ac103f6fa75b0496967e947791572b8a8a87b2407d78b2', transactionIndex: '0x8', blockHash: '0x1f9f0e0134a8b7c57156df86e84262c4037256a7f7f143a184f57922fd1ad3b1', logIndex: '0x13', removed: false } こちらはERC-1155のTransferBatchイベントで、複数のトークンが一度に移転されたことを示しています。詳細は Etherscan で確認できます。 イベントデータの活用方法 受信したイベントログを解析することで、以下のような情報を取得できます： ERC-721：  event Transfer  から直近の送信先を特定 ERC-1155： event TransferSingle  と  event TransferBatch  から所有者と所有量を計算 これらの情報をリアルタイムで処理し、データベースに記録することで、常に最新のNFT所有状況を把握することができます。 まとめ Ethereumフルノードを使ったWebSocket接続により、NFTの所有権移転をリアルタイムで監視できることがわかりました。この方法は、NFT取引プラットフォームやウォレットサービスなど、常に最新の所有権情報を必要とするアプリケーションで特に有用です。 参考資料 Geth PubSub API ドキュメント ERC-721 非代替性トークン規格 ERC-1155 マルチトークン規格   ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post [web3] Ethereum フルノードを使ったERC-721, ERC-1155の所有者のリアルタイム監視方法 first appeared on SIOS Tech. Lab .

こんにちは、エンジニアのわたなべです。 2025年1月~5月で LinuC の101, 102, 201, 202, 303 にスピード合格できたので、合格体験記としてまとめておきます。レベル1とレベル2の間に基本情報を取ったりしたので、LinuCに限ると4ヶ月で取得できたことになります。 ※ あくまで私のやってきたことを紹介する記事であり、これをやれば必ず合格できると保証する内容ではないことをご承知おきください。 学習開始時点(2025年1月)のバックグラウンドとしては以下の感じで、がっつりインフラ触ってるとかではなく経験浅めからのスタートなので、勉強時間についてはある程度参考になるかと思います。 新卒エンジニア2年目（非情報系学部） DB等のミドルウェア構築検証などでLinuxを触る経験は多少あり 基本コマンド（lsとかtouchとか）以外について、Linuxの知識を深める経験はなし ここからでも4ヶ月でレベル3認定までもらえましたので、学習方法を間違えずしっかり時間を確保できれば十分身に着けられます。 試験概要 LinuCとLPIC LinuC は Linux Professional Certification の略で、名前の通りLinuxの試験です。 LPIC とよく並べられますが、運営団体が違ったりします。試験範囲はおおよそ被ってたりと、どっち受けるかみたいな話はネットとかでよく話題になってます。 どうせ右足から歩き始めるか左足から歩き始めるかみたいな違いしかないと思うんですが、 自分の場合は新しくできた方が試験内容も新しいのかなというだけでLinuCにしました。実際201試験では LinuCのみdockerが範囲だったりとやや試験範囲に差分があり 、LinuCの方が新しめな所感です。 レベルと認定ついて 認定についてはちょっとややこしいので整理しておきます。 レベル1 LinuC レベル1は 101試験, 102試験の両方合格で認定 されます。 午前午後とかの同日で受ける必要は全くないので、101試験からチャレンジして合格したら102の勉強を始める感じです。 レベル2 レベル2は以下を両方満たすと認定されます。 有意なレベル1認定を持つこと 201試験、202試験両方合格すること LinuCの有意性は5年間なので、レベル1を取ってから5年以内に合格しないとまた101試験と102試験を受けないといけません。 レベル2の認定を受けると、自動的にレベル1の有意性も更新され、レベル2取得時から5年間へと延長されます。 レベル3 レベル3は以下を両方満たすと認定されます。 有意なレベル2 認定を持つこと 300試験、303試験、304試験の いずれか に合格すること レベル3 も認定をもらったタイミングでレベル2の有意性が更新されます。 レベル3だけ試験は1つで済みますね。 テーマがそれぞれ違っていて、 300試験 は混在環境、 303試験 はセキュリティ、 304試験 は仮想化&高可用性 となります。 それぞれ202試験との重複した範囲があり、意外とスムーズにクリアできます。リンクから試験範囲を確認して業務に関連深そうなものを見極めましょう。 この記事では303試験のみについて解説します。 学習コンテンツ 参考： LPI-Japan認定教材 レベル1,2 LPI-Japan 公式Youtube LPI-Japanさんのウェビナーのようなもののアーカイブですが、試験概要や各章について解説があります。 各章については試験に直結する知識や問題を提示してくれるというよりかは、 機能の役割など概要として理解するのに最適 です。 再生リストの順番がバラバラなので、サムネやタイトルから目的の動画を探して視聴してください。 あずき本 Linux教科書 LinuCレベル1 Version 10.0対応 LinuCレベル1の定番教科書。2つの試験範囲を完全網羅し、豊富な練習問題で合格をサポート。基礎から実務まで体系的に学習できる構成になっています。 ★★★★☆ 4.0 (116件のレビュー) 著者: 中島 能和, 濱野 賢一朗 Linux教科書 LinuCレベル2 Version 10.0対応 LinuCレベル2の認定テキスト。仮想マシンやネットワークの構築など、より高度な技術を解説。実践的なスキルを身につけられます。 ★★★★☆ 4.1 (48件のレビュー) 著者: 中島 能和, 濱野 賢一朗 Linux教科書、通称 あずき本 。 インプットと各章の問題、それと模擬試験が付いています。 まずは一読して、各章の問題を解きましょう。模擬試験は最後に。 スピードマスター LinuC レベル1 スピードマスター問題集 LinuCレベル1の対策問題集。472問の問題と丁寧な解説でテンポよく学習できる一冊。試験直前の総仕上げにも最適です。 ★★★★☆ 4.2 (82件のレビュー) 著者: 山本 道子, 大竹 龍史 LinuCレベル2 スピードマスター問題集 待望のLinuCレベル2対策問題集。475問を収録し、201・202試験の範囲を網羅。実力アップと弱点克服に効果的な構成です。 ★★★★☆ 4.1 (20件のレビュー) 著者: 大竹 龍史 スピードマスター問題集、通称 スピマス 、あるいは白本。 各章での問題と丁寧な解説、模擬試験が付いてます。 あずき本でインプットが出来たらこちらに着手します。 この時、解説をよく読んで不明点があればGoogle先生なり各種AIなりに聞いて疑問点を解消しましょう。 あずき本とスピマスの各問題が解けるようになったら、それぞれの模擬試験を解きます。 試験当日、全問題ほぼ100%解ければまず合格できるかと思います。 おまけ LPI-Japan 公式例題 LPI-Japan公式サイトに例題と解説があります。 上記の参考書のみでも合格できますが、スマホでスキマ時間に読み進めるといいでしょう。 レベル3 303試験 レベル3は学習コンテンツがぐっと減り、あずき本やスピマスがありません。 ping-tと公式例題だけでがんばりましょう。 ping-t 私は ping-tだけで合格できました。 スピマス同様、1週目は必ず解説をじっくり読みましょう。ping-t内でAIアシスタント解説機能がありますので、疑問点があればこちらも活用しましょう。 ping-tではこんな感じで問題の進捗度合いが換算されます。 レベル40/40 までブラッシュアップできれば、まず合格できるかと思います。 また、コマ問といって記述式の問題もあります。 コマ問の方はちゃんとやらなくて大丈夫です。 理由としては、①選択式問題をしっかりやって理解を深めていけば記述もある程度正答できる ②本番での記述問題は60問中3問程度と出題数が低い からです。 選択式に飽きたら息抜き程度に挟むといいです。 勉強時間 合格に要した勉強時間は以下の通りです。 あくまで私の場合ですので、自分のペースで計画を立ててみましょう。 101, 102試験 それぞれ 週20時間 × 3週間 = 計60時間 これは机に向かってあずき本・スピマスをこなした時間です。 この辺りはなんだかんだ基本コマンドに関する問いが多く、覚える量も少ないのでサクッととれました。 201, 202試験 それぞれ 週20時間 × 4週間 = 計80時間 特に202試験は範囲が膨大でありながら問われる内容もマニアックなので、鬼門です。心してかかりましょう。 ただ結局、覚えていれば解けるし覚えていなければ解けないものなので、ダラダラと時間をかけずに短期集中で取り組むことをオススメします。 303試験 週20時間 × 3週間 = 計60時間 303試験に限らずレベル3系は202試験と内容が重複しています。 ですので202試験まで突破できれば、意外とあっさり乗り越えられます。 ここまで来たらもう一息です。がんばりましょう。 さいごに 勉強に際してちょっとしたコツみたいなものがあります。 はじめは暗記量が膨大で絶望しますが、しばらく勉強を続けていくとコマンドの組み立て方やオプションなどで共通した考え方が見えてきます。 この感覚にきちんと向き合って言語化できれば、暗記量を節約できてきます。 例えば、ファイルの移動をする mvコマンド と、異なるホスト間でファイルをアップロード・ダウンロードする scpコマンド があります。 これは コマンド <移動元> <移動先> と覚えてしまえば、暗記量を節約できますよね。 こんな感じに 抽象化してパターン化できれば暗記しなきゃいけないことが減ってきます 。 ただ202あたりになってくると、 似たような操作パターンなのに全然違う ってことがかなり増えてきます。 そういったものはどうしても混同して間違えやすいです。ですので 発見するたびに書き出して、試験直前の確認シートにして しっかり復習して臨みましょう。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 【LinuC スピード合格体験記】LinuC 合格に必要な勉強時間・学習コンテンツ・学習方法まとめ first appeared on SIOS Tech. Lab .

こんにちは。サイオステクノロジー OSS サポート担当 山本 です。 今回は keycloak (というか SSO) ってどんなもの？というお題でざっくり話してみようと思います。 今日、インターネットを使用しているのであれば SSO の恩恵を受けていないということは稀かと思いますし、どんなものかもある程度以上知っている方も多いかと思います。 が、個人的に keycloak を調べてみる機会があって合わせて周辺の情報を確認しなおしたので、折角なのでざっくりとまとめてみようと思った次第です。 ぼんやりふんわりとした理解の助けになれば幸いです。 ■SSO ってなんだ？ SSO (シングルサインオン) は、その名のとおり サインオン (=ログイン、サインインなど) に関する技術で、主に Web サービスや Web アプリケーションで活躍するものです。 改めてお話しするまでもないかとは思いますが、サインオンは そのユーザを識別する何らかのキー (例えば、「 ユーザ名 + パスワード 」など) によって ユーザを識別 し、そのユーザ向けのサービスを提供したり、そのユーザ自身が登録した情報にアクセスできるようにしたりするための処理です。 例えば、電子メールサービスを扱うならばそのユーザ宛てのメールやそのユーザ自身が作成したメールだけを見れるようにしなければいけませんし、電子書籍サービスを扱うならばユーザが購入した書籍を識別できなければいけません。 この他にも様々な観点において、Web サービスなどは ユーザを識別できなければ立ち行きません 。 このため、サインオンという考え方は Web サービスなどにおいて非常に重要なものとなります。 …と改めて前置きをしたところで、まずは SSO と普通のサインオンの違いを確認しておきましょう。 (以下では全てのサインオンは「ユーザ名 + パスワード」で行うものと仮定してお話しします。) ■通常のサインオンの場合 あるユーザが「HogeHoge メール」というサービスを利用しようとしたとします。 この場合、そのユーザは「HogeHoge メール」に登録した、 「HogeHoge メール」用のユーザ名 + パスワード でサインオンを行なってサービスを利用することになります。 その後、そのユーザが「FugaFuga 動画」というサービスを利用しようとしたとしましょう。 そうしたら、そのユーザは 別途 「FugaFuga 動画」に登録した、 「FugaFuga 動画」用のユーザ名 + パスワード でサインオンを行なってサービスを利用することになります。 ……それはそうだろ、という感じですね。 このように、従来型の通常のサインオンでは 使用するサービスごとに識別情報・認証情報の登録やサインオン操作が必要 になります。 ■SSO の場合 SSO では、” SSO 認証サーバ ” などと呼ばれるいわゆる 親玉 的なモノが出てきます。 この「親玉」は様々な 他のサービスと連携 し、 連携先のサービスのサインオン操作などを肩代わり します。 これにより、ユーザは 「親玉」用の 1種類の認証情報 (「ユーザ名 + パスワード」など) だけでその 「親玉」と連携しているあらゆるサービスを効率よく使うことができます 。 大雑把なイメージでのお話にはなりますが、少し細かく見てみましょう。 ■SSO の例1：サインオン操作の肩代わりと入力回数低減 あるユーザAが SSO 認証サーバ「PiyoPiyo 認証」と連携している「HogePiyo メール」というサービスを利用しようとしたとします。 そのユーザAが「HogePiyo メール」サービスを利用しようとすると、”「HogePiyo メール」から来た” という情報を付けた状態で「PiyoPiyo 認証」へ飛ばされます。 ユーザAは飛ばされた「PiyoPiyo 認証」で、「PiyoPiyo 認証」に登録した 「PiyoPiyo 認証」用のユーザ名 + パスワード でサインオンを行ないます。 「PiyoPiyo 認証」でのユーザ認証に成功すると、「PiyoPiyo 認証」は 　・「HogePiyo メール」に対して “(「PiyoPiyo 認証」の) ユーザ ID” などのようなユーザを識別する情報 (+ その他必要になる情報) 　・ユーザAに対して「HogePiyo メール」のページに飛ばす処理 と、このユーザAが「HogePiyo メール」を使用する際に、このユーザAからのアクセスであると「HogePiyo メール」が識別できる何らかの手段・情報をそれぞれに送ります。 これで、このユーザAは無事「HogePiyo メール」サービスを利用することができるようになります。 ここで、この ユーザAは「PiyoPiyo 認証」にしかサインオン処理を行なっていない のがポイントです。 さて、その後さらにこのユーザAが先と同じ SSO 認証サーバ「PiyoPiyo 認証」と連携している「FugaPiyo 動画」というサービスを利用しようとしたとします。 基本的な流れは先の「HogePiyo メール」の例と同じで、そのユーザAが「FugaPiyo 動画」サービスを利用しようとすると、”「FugaPiyo 動画」から来た” という情報を付けた状態で「PiyoPiyo 認証」へ飛ばされます。 さて、先ほどはここで「PiyoPiyo 認証」でサインオンを行ないましたが、このユーザAは先ほど「HogePiyo メール」を利用しようとした時に、 既に「PiyoPiyo 認証」へのサインオンを済ませています 。 このため、 改めて「PiyoPiyo 認証」用のユーザ名 + パスワードを 入力することなく 「FugaPiyo 動画」を利用できる状態になるというわけです。 概ねこのような流れで、SSO を利用すると ユーザは一度のサインオン操作で複数のサービスを利用できる ようになります。 なお、サービス側はあくまでサインオンを肩代わりしてもらっているだけであり、サービス自体の情報 (「HogePiyo メール」の管理しているメール情報や、「FugaPiyo 動画」の購入履歴・利用プラン情報など) は別途そのサービス自体が管理することになります。 このような役割を担う SSO の仕組みとしては、 Kerberos 認証 、 SAML 、 OpenID-Connect (OIDC) などが挙げられます。 ■SSO の例2：ユーザ情報の共有 先の例を流用して、例えば「FugaPiyo 動画」で “「PiyoPiyo 認証」のメールアドレスでメールマガジン登録” という操作ができる場合のことを考えてみましょう。 この場合、「FugaPiyo 動画」は「PiyoPiyo 認証」に登録されているメールアドレスを取得する必要があります。 (SSO 認証サーバ「PiyoPiyo 認証」には、ユーザ情報としてメールアドレスも登録されているものとします。) あるユーザAがこの操作を行うと、「FugaPiyo 動画」は「PiyoPiyo 認証」にこのユーザAのメールアドレスが必要な旨を伝えます。 もちろん、いくら連携しているとは言え「PiyoPiyo 認証」は（セキュリティ的に考えて）無条件でメールアドレスを渡すわけにはいきません。 そこで、「PiyoPiyo 認証」は “「FugaPiyo 動画」がユーザAのメールアドレスを取得しようとしているよ” という情報を含めた合わせ鍵を用意して、「FugaPiyo 動画」に渡します。 「FugaPiyo 動画」は「PiyoPiyo 認証」から受け取った合わせ鍵 (ユーザA用の部分) や、後で「FugaPiyo 動画」に戻る際のアドレスなどの情報をまとめて、ユーザAに送ります。 ユーザAに送られる情報には「PiyoPiyo 認証」に飛ばす処理も含まれているので、ユーザAは「PiyoPiyo 認証」に飛ばされます。（ユーザAが「PiyoPiyo 認証」にサインオンできていない場合、ここでサインオン操作をする必要があります。） ユーザAが合わせ鍵を「PiyoPiyo 認証」に渡すと、「PiyoPiyo 認証」は合わせ鍵の内容を確認して、 ユーザAに [「FugaPiyo 動画」にメールアドレスを渡すけど、いいのか？] と 確認を行ないます 。 ユーザAがこれを承認すると、「PiyoPiyo 認証」はこの合わせ鍵に「承認済み」フラグを記録し、ユーザAは「FugaPiyo 動画」に戻されます。 「FugaPiyo 動画」はユーザAが戻ってきたことを確認すると、改めて合わせ鍵を使って「PiyoPiyo 認証」にユーザAのメールアドレスを要求します。 「PiyoPiyo 認証」は合わせ鍵の正当性や「承認済み」になっているか、要求元が間違っていないかなどを確認した上で、問題がなければメールアドレスの情報を持っている リソースサーバ に “「FugaPiyo 動画」にユーザAのメールアドレスを渡すように” という通達と合わせ鍵を、「FugaPiyo 動画」にはリソースサーバの場所と合わせ鍵を渡します。 そうして、「FugaPiyo 動画」はリソースサーバに合わせ鍵を持ってアクセスすることで、目的のユーザAのメールアドレスを得ることができます。 ……行ったり来たりでややこしいですが、このほとんどは 使い捨てのデータによる承認や確認処理 で、 　・ユーザAは SSO 認証サーバ「PiyoPiyo 認証」で サインオンと承認をしただけ 　・やりとりされるのは ユーザが許可した メールアドレスのみ 　・実際にメールアドレスのやり取りをしているのは「FugaPiyo 動画」とリソースサーバのみ なので、ユーザは少ない手間で、かつデータのやり取りはかなり安全に行なうことができます。 と、基本的には概ねこのような流れで、SSO によって SSO 認証サーバが連携する範囲で登録したデータをやりとり させることができます。 ここではメールアドレスを例にしたためあまり便利そうには見えないかもしれませんが、例えば SNS の投稿を連携したり、荷物の宛先情報などを連携したり……などであればだいぶ便利そうに感じれる…ハズです。 このような役割を担う SSO の仕組みとしては、 OAuth が挙げられます。 ■SSO のメリットは？ さて、ゴチャゴチャ話してみましたが、結局 SSO というのは何が嬉しいのかを考えてみましょう。 まず、ユーザは 認証情報の管理がラク になります。 SSO 認証サーバの連携する範囲内のサービス・アプリケーションで1回だけ認証処理をすればよく、当然覚えておく認証情報も1つだけで済みます。また、場合によってはユーザの入力した情報 (各種個人情報や SNS 等の投稿など) を別サービスから必要に応じて参照させることで、同じ情報を複数回入力する手間も削減することができることもあります。 旧来はサービス・アプリケーションごとに別々の認証情報を用意し、必要に応じて各サービスに別々で手動での情報入力を行う必要があったことを考えると、ユーザにとってはかなりラクになることでしょう。 SSO 認証サーバの管理者・連携先としては…… まず、組織内で複数サービスのサインオン処理の統合のために使っている場合、SSO 認証サーバのアカウントだけ管理すればよくなるので、個別のサービスごとにアカウント管理するよりも アカウント管理の手間が減る 可能性が高いです。 外部の SSO 認証サーバと連携する場合だと、自システムに認証情報を保存しなくて済みます。このため、(その他の個人情報などを取得していなければ) 漏洩して困る情報を手元に置かなくて済むようになり、万が一自システムでの情報漏洩が出てしまった場合でも対ユーザへの被害が深刻になりにくい可能性が考えられます。また、 ユーザ側の新規登録の手間が省かれる ので、 ユーザにサービス自体を触ってもらいやすくなる 可能性も考えられます。 このように、認証の一元化による管理の容易さとユーザビリティの向上が見込めることが SSO のメリットと言えるでしょう。 ただし逆に、万が一 SSO 認証の認証情報が漏洩した場合、連携先のサービスなども含めて丸ごと不正利用される恐れがあります。 そのため、SSO 認証サーバ自体、および SSO 認証サーバの通信や SSO の認証情報には十全なセキュリティ対策が求められます。 （もっとも、SSO により管理を一元化することでより複雑な認証情報・認証方法を採用しやすくなったり、逆に SSO を使用していない場合にユーザが認証情報をメモして残したり使い回しをしたり…といったことを考えると、SSO のセキュリティリスクは高いというわけではありません。） ■keycloak ってなんだ？ keycloak は、正にここまでお話ししてきた “ SSO 認証サーバ ” の1種です。 SAML 、 OpenID-Connect (OIDC) 、 OAuth に対応しており、管理コンソールやユーザ連携、ユーザ制御などの機能を備えています。 今回は前置きが長かったので、管理コンソールとそれぞれ今回のお話の何をどれで設定するのかだけ確認します。 まず、デモ環境を立ち上げます。今回は手早く podman で作ってしまいましょう。 podman を導入して、以下のようなコマンドを実行すれば OK です。 $ podman run --name test -p 8080:8080 -e KC_BOOTSTRAP_ADMIN_USERNAME=admin -e KC_BOOTSTRAP_ADMIN_PASSWORD=admin quay.io/keycloak/keycloak:26.2.4 start-dev (このコマンドはセキュリティ設定などを省いて動かせる デモ用・開発用の環境を作成 するためのコマンドであり、実際に 運用する環境を作る場合は絶対に使用してはいけません 。) そうしたら、任意のブラウザで以下のアドレスにアクセスしてみましょう。 http://(IP アドレス):8080/admin サインオンの画面が表示されるので、サインオンしてみましょう。 初期ユーザのユーザ名/パスワードは、podman コマンドの “KC_BOOTSTRAP_ADMIN_USERNAME” と “KC_BOOTSTRAP_ADMIN_PASSWORD” で指定したものです。 (上記のとおりのコマンドだった場合、”admin” / “admin” です。) サインオンに成功すると表示されるのが keycloal の管理コンソールです。 今回は、マークをつけてある今回お話ししたものに対応している3つの要素が何に対応しているかだけ、最後に確認したいと思います。 ・ Clients この keycloak (=SSO 認証サーバ) と 連携するサービス・アプリケーション やその連携方法などを設定します。 連携先のサービス・アプリケーション側でも別途この keycloak と指定した方法で連携するように設定する 必要があります。 今回のお話では「HogePiyo メール」「FugaPiyo 動画」が該当します。 ・ Users この keycloak による SSO 認証のユーザ情報 (認証情報など) を設定します。 今回のお話では「ユーザA」の認証情報が該当します。 ・ Realm (※ “master” となっているプルダウン部分) 設定する SSO 連携の「枠」です。keycloak では複数の Realm を持つことができます。 先述の “Client” と “User” などは Realm ごとに管理されます。 確認できたら、先ほど立ち上げた検証用の keycloak コンテナは念のため削除しておきましょう。 $ podman stop test $ podman rm test ■最後に 今回は SSO と keycloak の概要についてお話ししてみました。 SSO について長々とお話ししましたが、今日日インターネットを使用しているのであれば、恐らくは恩恵にあずかっているはずです。 そう、「google でログイン」「Apple でログイン」「Facebook でログイン」などのような「～でログイン」というアレです。アレこそが、SSO という技術の典型と言えるでしょう。 keycloak はそんな SSO の “親玉” の部分を担うサービスです。 例に挙げたような外部にまで連携する超大規模 SSO サービス……なんてものはまず新しく立ち上げることはないでしょうから、 基本的にはお話の途中でちらりと出した「組織内のサインオン処理の統合」のために使用するものと考えてもらえばよいでしょう。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post わからないなりに理解したい keycloak①：そもそも SSO って何だ？ first appeared on SIOS Tech. Lab .