「最新版を使えばいい」は本当に正しい？Dependabotを使って“pin + 自動更新”にする理由

依存ライブラリやGitHub Actions、Terraform Providerのバージョン管理をしていると、よく出てくるのが次の考え方です。 新しいバージョンが出たら、常に最新版へ上げればいいのでは？ 一見すると合理的です。 実際、古いバージョンを長期間使い続けるより、継続的にアップデートした方が、脆弱性や非互換の問題を後回しにしにくくなります。 ただし、実際の開発運用では、 「バージョンを固定しない」ことと「常に新しい状態を保つ」ことは別です。 むしろ、 バージョンは固定し、Dependabotで自動的に更新PRを作る という運用の方が、安全性と更新頻度を両立しやすくなります。 今回は、実際の開発チームで出た「pinするべきか、しないべきか」という議論をベースに、Dependabotをどう使うべきか整理します。 きっかけは「そもそもpinしなくていいのでは？」という疑問 あるプロジェクトで、GitHub ActionsやTerraform Providerのバージョンを更新する話が出ました。 その中で、 理想的には何もpinしない方がいい。新しいバージョンが出たら常にアップグレードすればいいのでは？ という意見が出ました。 この考え方自体は間違っていません。 目標としては、 依存関係を古いまま放置しない というのが正しいです。 ただし、その目標を実現する方法として「pinしない」を選ぶと、別の問題が出てきます。 そこで出てきたのが、 「pinしない」のではなく、「pin + automated bumps」にしよう という考え方です。 つまり、 バージョンは固定する。しかし、更新作業は自動化する。 これがDependabotを使う理由です。 GitHub Actionsでは、floating tagがリスクになる たとえばGitHub Actionsでは、次のような指定をすることがあります。 これは分かりやすく、一般的な書き方です。 ただし、v4 のようなタグは、厳密には「特定のコードそのもの」を表しているわけではありません。 タグが別のコミットを指すように変更されれば、同じ @v4 という記述でも、実際に実行されるコードが変わる可能性があります。 CI/CDで実行されるActionは、ビルド環境やデプロイ権限にアクセスすることがあります。 そのため、これはサプライチェーンセキュリティの観点でも重要です。 より厳密に管理するなら、特定のコミットSHAに固定します。 こうすると、同じ設定から実行されるコードが勝手に変わることはありません。 ただし問題があります。 固定しただけでは、そのバージョンは永遠に古くなっていきます。 そこでDependabotを使います。 新しいバージョンが出たら、 という流れにします。 つまり、 固定することで再現性を確保し、Dependabotで鮮度を維持する […]

GMKtec EVO-X2にUbuntuを入れたら有線LANが認識されなかった話

オンプレミスAIサーバー(ローカルLLM + 社内文書RAG)の構築を始めました。機材はGMKtec EVO-X2、AMD Ryzen AI Max+ 395搭載のミニPCです。128GBのユニファイドメモリをGPUに大きく割り当てられるので、ローカルLLM用途では今いちばん面白いマシンだと思っています。 この記事は初日の作業ログです。結論から言うと「インストールUSBが起動しない」「有線LANが認識されない」という2つの罠を踏んだので、同じ構成を組む方のために記録しておきます。 OSはLinuxかWindowsか 最初に迷うのがここですが、サーバー用途ならUbuntu Server一択でした。 日常操作はすべてブラウザ(Open WebUI)経由なので、サーバーOSにGUIは不要です。管理画面が欲しければCockpitを入れれば、Webブラウザからメトリクス確認・サービス再起動・ターミナルまで使えます。「CUIのサーバー + Web管理画面」が現代の標準形だと思います。 BIOS設定 ― EVO-X2で一番大事なのはVRAM割り当て 電源ON直後にDel連打でBIOS(AMI)へ入ります。設定したのは3つです。 罠その1: インストールUSBが起動しない Ubuntu Server 24.04のISOをMacから dd でUSBメモリに書き込み、いざブート……しません。Boot Overrideに出てくる「UEFI OS」を選んでもWindowsが立ち上がってしまいます。 切り分けの過程が学びでした。 原因はおそらく、dd の書き込みが完全に終わる前に抜いてしまったことです。dd は進捗表示が止まってからもバッファの書き出しが続くので、完了統計が表示されるまで待たなければいけません。パーティションテーブルはディスク先頭に書かれるため、途中で切れていても一見正常に見えるのが厄介なところです。 教訓: インストールUSB作成はbalenaEtcherを使いましょう。 書き込み後に自動でベリファイ(照合)まで走るので、「書けたつもり」が原理的に起きません。Etcherで書き直したら一発で起動しました。 インストール時の選択 罠その2: 有線LANが認識されない インストール完了、ログイン成功。しかし ip a を見ると有線LANにIPがありません。それどころか、よく見ると有線のインターフェース自体が存在しません。 カーネルログを見て原因が確定しました。 EVO-X2の2.5GbEチップ(Realtek RTL8125D)が新しすぎて、Ubuntu 24.04の標準カーネル6.8のドライバが知らないチップだったのです。インストール中にネットに繋がらなかったのもこれが原因でした。ケーブルを何度挿し直しても無駄だったわけです。 教訓: 「繋がらない」時はケーブルを疑う前に dmesg を読みましょう。 カーネルログには大抵、答えがそのまま書いてあります。 解決: HWEカーネル 新しいチップに対応するには、新しいカーネルを入れれば解決します。Ubuntuには**HWE(Hardware […]

FSD v2.1 Feature-Sliced Design を導入する

この記事は何？ 公式のドキュメントやチュートリアル、exsample を読んで理解するのが一番いいですが、備忘録として残しておきます。特に後述の Skills, Steiger については開発する際にあった方が便利なので、それについても記事にします。 FSDとは？ FSD (Feature-Sliced Design) はフロントエンドのアーキテクチャの一つです。 FSDとは責務で分けていくアーキテクチャと違い、ページやエンティティで分けていくアーキテクチャというとわかりやすいと思います。 コードの分離の仕方について話す前に、FSDで前提となる この３つについて理解する必要があります。 レイヤー より細かく分けていく方法がありますが、この記事では導入だけ触れたいので、３つのレイヤーのみ説明します。 です。この流れは上（app）に向かえば向かうほどアプリケーション固有、下（shared）に向かうほど汎用的になります。 原則として上位レイヤーは下位レイヤーを利用できるが、下位レイヤーから上位レイヤーへ依存できません。 始め方としては小さく初めて、必要になったらレイヤーを増やしてくようです。 スライス ブログアプリであればレイヤーの pages には といったページに分けられるため、このような構成になります。このblog-list, blog-detail, user がスライスです。これらはページやエンティティによって分けられます。 セグメント これらのmodel, ui といった部分がエンティティです。これらは責務にあたります。sharedに関しては直下にスライスではなくセグメントが入ります。 FSD 2.1 で重要なのは Pages First です。とにかくPagesから作って、細分化の必要ができたら、下位レイヤーに抽出します。 Steiger Steiger とはアーキテクチャリンターです。以下でインストールできます。 AIコーディングのために Claude Skills https://github.com/feature-sliced/skills?utm_source=chatgpt.com このリポジトリが公式に公開されています。 これで Skills を追加できるので、claude にFSDの設計知識を共有できます。

フロントエンドのアーキテクチャについて最初から考える

これは何？ この記事は基本に立ち戻りアーキテクチャの選定を試みた際の備忘録です。Feature-Sliced Design（FSD）や Vertical Slice Architecture など、モダンなアーキテクチャがありますが、どのような判断をもとに選定するのかを考え直します。 アーキテクチャの地図 アーキテクチャを理解するために、以下のような学習のための地図を作りました。設計原則、アーキテクチャ、個別の設計パターンへと詳細になっていきます。 そもそも、、、 このコードは何を担当しているのかを考えるのが最初の問です。 商品一覧画面を作るときに といったタスクを書き出します。 これら全てを一つの巨大なコンポーネントとして作ることもできますが、管理が大変になるのは皆さんもお分かりだと思います。参考：https://blog.cleancoder.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html?utm_source=chatgpt.com ここからどこまでを同じモジュールとして管理するのか？という設計の問題が始まります。 Cohesion と Coupling CohesionとCouplingはそれぞれ、凝集度、結合度というようです。https://qiita.com/dsudo/items/ee3fee1f558c7f1b359f Cohesionは関係するコードがまとまっているか？ Couplingは別のコードにどれだけ依存しているか？ です。 例えば以下のようなコードがあります。 技術的な種類ごとに整理されていますが、商品一覧のコーディングをするのにそれぞれ別のディレクトリを行き来する必要があります。一方で、以下のように書いた場合はどうでしょうか？ この書き方なら、商品に依存するコードがまとまっています。 この書き方が Feature-based Architecture, Vertical Slice Architecture に繋がっていきます。 コロケーションについて colocation Place code as close to where it’s relevant as possible 同じ種類のコードを集めることではなく、一緒に変更されるコードを近くに置くことです。 https://kentcdodds.com/blog/colocation?utm_source=chatgpt.com Layered Architecture について ここからアーキテクチャの話です。 Layered Architectureでは、技術的責務でアプリケーションを分離します。 これのメリットは責務がわかりやすいところです。 しかし、この方法では前述までとは変わり、機能を変更するときに、横断して変更する可能性があります。 つまり、技術的には分かれている一方で、機能は複数に分散するわけです。 […]

【WSL入門】Ubuntu on WSL2 に開発ツールを一式そろえる — Git / nvm / pnpm / AWS CLI / Terraform

前回の記事では、Windows に WSL2 を導入して Ubuntu が動くところまでを扱いました。ただ、素の Ubuntu はあくまで「まっさらな Linux」です。ここから実際に開発を始めるには、バージョン管理・ランタイム・クラウド操作のツールを自分で入れていく必要があります。 この記事では、すべて公式ドキュメントに載っている手順だけを使って、次のツールを順番にセットアップします。 各セクションの末尾に出典 URL を置いてあるので、手順が古くなったと感じたらそこを見に行ってください。記事末尾には出典一覧もまとめています。 検証環境Windows 11 / WSL2 / Ubuntu 24.04 LTS（x86_64）確認日：2026年7月28日 バージョン番号は執筆時点のものです。インストールコマンド自体は基本的に「常に最新を取ってくる」形になっているので、そのまま実行して問題ありません。 はじめに：WSL開発の大原則 コマンドに入る前に、ひとつだけ。Microsoft の公式ドキュメントが繰り返し書いている重要な原則があります。 使う予定のツールと同じ OS 側にファイルを置く。Linux ツールで Linux コマンドラインから作業しているなら、最速のパフォーマンスを出すためにファイルは WSL ファイルシステムに格納します。 具体的には、プロジェクトは次の場所に置きます。 /mnt/c/ 配下はファイルシステムをまたぐため、npm install や git status が体感でわかるほど遅くなります。第2弾でこれから入れるツールも、すべて Linux 側のホームディレクトリを前提に使ってください。 出典：WSL 開発環境を設定する — Microsoft Learn 1. まずは基本ツール Ubuntu を起動したら、最初にやることはパッケージの更新です。Microsoft の公式ドキュメントにもこう書かれています。 ディストリビューションの優先パッケージ マネージャーを使用して、パッケージを定期的に更新およびアップグレードすることをお勧めします。Windows […]

WindowsでWSL2をセットアップしてUbuntuを使えるようにする

TerraformやAWS CLI、Dockerを快適に使うために、WindowsにWSL2を導入しました。 この記事では、実際に行ったセットアップ手順と、途中で遭遇したエラーへの対処方法をまとめます。 なぜWSLを使うのか？ WSL（Windows Subsystem for Linux）は、Windows上でLinux環境を動かすための仕組みです。 AWSやTerraform、Dockerなど、多くの開発ツールはLinux環境との相性が良いため、Windowsで開発する場合でもWSL2を利用するのが一般的です。 今回の開発環境では以下のような構成を想定しています。 1. WSLをインストール PowerShell（管理者）を開き、以下を実行します。 2. Ubuntuの初回セットアップ Ubuntuを起動すると、Linuxユーザー名とパスワードの設定を求められます。 例 好きなユーザー名を入力します。 続いてパスワードを設定します。 ※入力中は文字が表示されませんが正常な動作です。 3. パッケージを更新 Ubuntuを起動したら、まず最新状態へ更新します。 4. エラーが表示された アップグレード中に次のようなメッセージが表示されました。 一見エラーに見えますが、今回は最後まで と表示され、更新自体は正常に完了していました。 WSLではsystemd関連の処理で、このような警告が表示されることがあります。 5. WSLの状態を確認 PowerShellで以下を実行します。 今回は となっていました。 6. Docker DesktopとUbuntuの違い ここで少し混乱しやすいポイントがあります。 Docker Desktopをインストールすると、docker-desktopというWSLディストリビューションが作成されます。 しかし、これはDockerが内部で利用するためのもので、普段の開発を行う場所ではありません。 おすすめの構成は次の通りです。 開発はUbuntuで行い、Docker Desktopはコンテナ実行基盤として利用します。 7. Ubuntuを既定のディストリビューションに変更 現在登録されているWSLを確認します。 Ubuntuがインストールされていることを確認したら、 を実行します。 これで だけでUbuntuが起動するようになります。 今後インストール予定 WSL環境では今後以下を導入していきます。 この環境をベースに、AWS Organizations、IAM […]

AWS CLIでIAM Identity Center（AWS SSO）を設定する

これまでの記事で、 まで構築しました。 今回は、ローカルPCからAWSを操作するために、AWS CLIをIAM Identity Center（AWS SSO）へ接続します。 これにより、長期アクセスキーを発行せず、安全にAWS CLIやTerraformを利用できるようになります。 なぜアクセスキーを使わないのか 以前はAWS CLIを利用する際、IAM Userを作成し、 を発行していました。 しかし、この方法にはいくつかの課題があります。 現在AWSでは、人によるAWSへのアクセスには**IAM Identity Center（旧AWS SSO）**を利用することが推奨されています。 IAM Identity CenterとAWS CLIの仕組み AWS CLIは、IAM Identity Centerへログインし、一時的な認証情報（Temporary Credentials）を取得します。 つまり、 という、安全性の高い認証方式になります。 aws configure sso を実行 まずAWS CLI v2をインストールします。 インストール後、次のコマンドを実行します。 すると、対話形式で設定が始まります。 SSO Session Name ここはローカルPC上だけで利用する設定名です。 今回は としました。 好きな名前で問題ありません。 SSO Start URL IAM Identity CenterのアクセスポータルURLを入力します。 例 このURLは IAM […]

AWS IAM Identity Centerとは？IAM Userを使わないAWS認証・権限管理のベストプラクティス

AWS Organizationsによるマルチアカウント環境を構築した後、次に設定したのがAWS IAM Identity Centerです。 以前はAWSへログインするためにIAM Userを作成することが一般的でしたが、現在AWSでは、人がAWSへログインする場合はIAM Identity Centerの利用を推奨しています。 今回は、IAM Identity Centerを導入した理由と、実際の設定内容についてまとめます。 IAM Identity Centerとは IAM Identity Center（旧 AWS Single Sign-On）は、複数のAWSアカウントやAWSアプリケーションへの認証・認可を一元管理するサービスです。 従来のように各AWSアカウントへIAM Userを作成する必要はなく、 というメリットがあります。 AWS Organizationsと組み合わせることで、マルチアカウント環境の運用が大幅に容易になります。 なぜIAM UserではなくIdentity Centerなのか 以前は、このような構成が一般的でした。 しかし、この方法では といった課題があります。 Identity Centerを利用すると、ユーザー情報は一元管理され、各AWSアカウントには必要な権限だけを割り当てる運用になります。 AWS Well-Architected Frameworkでも、人によるアクセスにはフェデレーション認証を利用し、長期認証情報（IAM Userのアクセスキーなど）をできる限り利用しないことが推奨されています。 今回の構成 今回は次のようなシンプルな構成にしました。 グループ Administrators AWS環境全体を管理するメンバーです。 現在は を所属させる予定です。 Developers アプリケーションやインフラ開発を行うメンバー向けです。 今回はまだ利用していませんが、開発メンバーが増えた際に使用します。 将来的には などを割り当てる予定です。 ReadOnly 閲覧専用グループです。 監査やレビュー、外部アドバイザー向けとして利用します。 今回は技術メンターにReadOnly権限を付与することを想定しています。 Permission […]

AWS Organizationsで始めるマルチアカウント設計 ― 小規模開発チーム向けのベストプラクティス

サービスの開発を進めるにあたり、AWSの初期構築を行いました。 今回は、AWS Organizationsを利用してマルチアカウント環境を構築し、今後TerraformによるIaC（Infrastructure as Code）やGitHub Actionsを利用したCI/CDを前提とした設計を採用しています。 この記事では、実際に構築した構成と、その設計意図をまとめます。 なぜ最初にAWS Organizationsを導入するのか AWSでは1つのアカウントにすべてのリソースを作成することもできます。 しかし、開発が進むにつれて次のような問題が発生します。 AWSではこのような課題に対応するため、マルチアカウント構成を推奨しています。AWS Organizations ユーザーガイド Organizationsとは AWS Organizationsは、複数のAWSアカウントをまとめて管理するためのサービスです。 OrganizationsにはOU（Organizational Unit）という概念があります。 OUはEC2やS3を配置する場所ではなく、AWSアカウントを整理するためのフォルダのような存在です。 例えば、 というようにOUを作成し、その中へAWSアカウントを配置していきます。 OUを利用することで、将来的にSCP（Service Control Policies）などのポリシーをまとめて適用できるようになります。AWS Organizations のベストプラクティス 今回採用した構成 今回はAWS Security Reference Architecture（AWS SRA）の考え方を参考にしつつ、小〜中規模の開発チーム向けにシンプルな構成を採用しました。AWS Security Reference Architecture (AWS SRA) Infrastructure OU インフラ運用に必要なAWSアカウントを配置します。 Log CloudTrailをはじめとする監査ログを集約するためのアカウントです。 AWSではCloudTrailのイベント履歴は標準で90日間参照できますが、長期間保持する場合はS3へ保存する構成が推奨されています。 さらに、一定期間経過後はS3 Glacierへ移行することで保管コストを抑えることができます。 今後はCloudTrailだけでなく、各種監査ログもこのアカウントへ集約する予定です。 Security Security HubやGuardDuty、AWS Configなどのセキュリティサービスを配置するためのアカウントです。 今回はまだ構築していませんが、 を集約する予定です。 AWS SRAでも、ログ管理アカウントとセキュリティアカウントを分離する構成が推奨されています。 […]

.env ファイルをやめて Bitwarden Secrets Manager に移行した話

この記事はなに？ 私たちcoiaiはモックアップの作成業務がメインで今までの開発は１－２名程度でした。しかし、６名以上で開発を進めていく案件が増えてきたため、開発環境を見直す必要に迫られました。 今まで環境変数は .env ファイルで管理していました。しかしこれからは、平文として秘密情報が確認できない状態にすること、チームで環境変数の共有の際にセキュアな共有方法を確保することを目的とし、環境整備を行いました。 Bitwarden 導入の目的と意義 背景: .env の何が問題か ローカル開発の秘密情報は .env + .gitignore が定番だが、いくつか弱点がある。 1 と 2 を解決するのがシークレット管理サービスで、Bitwarden Secrets Manager はその中でも安価(Password Manager とは別契約)かつ CLI が単体バイナリで導入が軽い。 Bitwarden Secrets Manager で抑えて起きたい概念 注意点としてPassword Manager(個人のパスワード保管)とは別プロダクトです！Password Manager は弊社でも利用していますが、今回Secret Manager を追加で契約した形になります。 概念は3つだけです。 概念 役割 プロジェクト シークレットの入れ物。今回は 1 リポジトリ = 1 プロジェクト シークレット KEY / VALUE / メモ の3つ組。.env の 1 […]